From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:04:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:04:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379703.1624120 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxD1-00079x-AF; Sat, 01 Aug 2026 00:04:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379703.1624120; Sat, 01 Aug 2026 00:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxD1-00079q-6P; Sat, 01 Aug 2026 00:04:11 +0000
Received: by outflank-mailman (input) for mailman id 1379703;
 Sat, 01 Aug 2026 00:04:09 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxCy-00079R-TG
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:04:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxCy-00Fh5s-6F
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:04:08 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d37c7-2eae-0a2a0a5409dd-0a2a45089e78-22
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:04:03 +0200
Received: from [98.137.64.84] (helo=sonic305-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d37f2-f659-0a2a45080019-628940548152-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:04:03 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:04:01 +0000
Received: by hermes--production-ne1-6f6bdbdd7c-rppmz (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID c7608ec2cac0a95d3d8faa6ec551e65c; 
 Sat, 01 Aug 2026 00:03:55 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785542641; bh=ScxuLdCEEpt8xcvaZGVm8pblnaaeCXt2k3SUmUrCDDQ=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=BtZRziS2ygv2KGOSQFkP5aQBWo2876ju/GKwUxZmxJTPJzhXRwNiuHImAyZgXwr0xAKYD5SgYEx2SKUniLfHDuEPLuswLJCTtCpA2i0PkkN1YbiqxMgFRUe6uNN3bXxEnKaDsIHFIGBtHkvRLqpkyElptwGfyuJd0mrUHfnXUUum2hx5WYpn3bQSaVteWEtDq+wn8rmytq9M2Vf868PZ9j56hWV63DTEFHR4kyell+yDUqCjgXdFubYwUFQkwstPp1aB+/LzsUVWzKItZwT4yTzH077oVan8MvwF8yHMao5zvFqfvJC/zPA1hRrF9gxtfxCGthCf+aAANbBzTZtoYA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785542641; bh=EgevDvieZTrS5c5/q5o0sA8ls7qQ9KS6Qjw0ldsYmTK=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=QUuOUFJzgLja2jgoY0vvNkPuDILYmIpoA6zBTStqTSto/kWhVNX5D+bDyPDneyzeprvmya4CFPG16NDKtATHvw50bgwwVglJQKP+WW5JwT43JLCrdf6B4lnpxQItjso2UxoW8XNiumXHIlK80Y0pFD8a9nUAH/c5yOBDlL4sjEl+GKFOCt7m5+VEpYCk4b4qQIy+a0VGNeTsZLiISJZkeOEFSsBxMX4eChN5SUYoDqNEX1Xly18Tem0RoZCrBWcdO+3PDgb1wxt21dPPzhJIJjuUTea8R6bm6xEwCFV7PMDZxuk7aJCQMc/kt7jkBPwSq7AfOLDNPpP5mMcFytORRQ==
X-YMail-OSG: NZZFObAVM1mQ8GuUv0FKMv9ixWb._8avAcvTzthF8BSuwGKlf2uXznS9QLs4qHu
 cNSuiCa1BGPlLlHPquwa8hkq.Svb8y21.sX5taYNKrwxdRfi1nMpGGeik8E3mDKIBrw5qm3yhp7N
 JwylAqzYZfc7.i67ygWf27FZ_BCi6BYNSENdrXEtrxfUmuFD2QGpCr2JhDDiS8IIEHBee4qBibkG
 qmeDyvAJou8JGl39oNojjw6tJ3oWma3PWSl8JsknF4HOd6hVmDBu8qznZlxGJdTvdwry4xssFuvz
 AMuv3jNMkOYxaXmaT1Jis1ANyveIEArGN_QvsMMaqKcSdTTuDwD.94C_2D1k9Xxt9zUXi5VT2hub
 XBmQceX6E6X4IEncTk3Lv7X246HrGPdeeu0BbVoSVnPoso_7xM_NsPrV1PTu5pZWZnnXX2nFuq2K
 8kRZfSfuBtK2vc4hIhu.rFOdrP50kZ0lAH8ieip29_Cwallgo5aHpabQUfpKf.WyhM4UQnFXiqTj
 GoZjF_S3eVSL9f4OBS3_JKiAOujJD6BVoY7AqaeQD8omDQMpT6klqGmQPT_3MCJ35ddSKLip0guO
 Ot6J2NDn4LqHt94gJX22A9cbAECN1NkgIB_l1zchHbPjmqTHxDxCQs0nVb3QUWDzwRvjrX3ytXYF
 nfOFmY2Jb8Nmd191LbSmUSRLe0tXxZZ915repd.4_pUUIW3SCN3tFKK2IwfxQQ_8XCJezkNLksFn
 TBu2AIgzCd22pMALioITJmEQQz_2xTlutcgdy.1w7XofZlI6pnlZxNmZR_psdJObbAKTB34gNqFz
 .TqzvO4R0NCvLps1zTV3PVVoV2hbUq69ezRuWYssjzlsnaE2a9r43Uk1on2aFUsBGd5a71mKFkXv
 81RoL20olZdxyX.Xq.5vpF68KIWifctNXs9ErAkakdLCJ911KeYSnlE8QPkP6QogBH3IU0VYwoIR
 bLaIDLI7p_wJU8cuAhl_PHq.6WW15baogYVq7.kjuvz7e4xevteZXJGXPPhn1NcZZL3d7he9EmX.
 VesxsFK.4X4MEFdU8fv27Cm4hqMXVRJK7a8mCxqxOd9UnUHkH_thy8HzVEnuCBc4FL90oBAx_7.F
 xtYFaMQvYRfdzxdFh0XR5L4lnQDc9__WC_uIZ9vg4R9KwDYLyssCAWbPzKTCOX5MyErv.KTGMAI7
 Ok8yrG9Lz5fdB3Qj.oZh.QqrUoS.5XnuQcM2.hiUnI8khOq9xuM5fJgEBhOlU2.Z3GmXmsCpRdcs
 G2T0o5YjXwcmNL7WN4_aHqdhp4sGgE4Ei_TzpQOf9wpio2kRJE8xOMPSNVMpfigE39tDuARi_l_I
 6vT.yFuugjxncpY_FFk3sftXGu5.pVfkhZWD9KN1PIJ.5NaQy898Qqf4OVlGrQ2PlgkXGdLWHNlt
 WCZ0CTk3ibM3qeDfnnYCuiIPoQKVnEpNXkEhSJFCrPoa6c2164tkOm58gyMgRTXSqAIvVupMj7i1
 5xkJtCW5r1k4NxY8qcW3zl_MPBlxNA98Df2Pttk8Q.oVXmuzUtqC04jFeVPjVXC7iFN50k1xIRr0
 4n0BoAs2HW7v5IY69MfAkGpscSvhj2BEv0ioCCSLH0msIeGmyVneSwUsvU7POwf1W9xt2LADJGIr
 RzFs16RbnydAQL39dDzo1bVqhsCqUjWRI5HbiOVOjG.8v5RjXbtqXsLPWRKvMdhboA96gcyCL3_r
 XOS4Z11jeCFvdl_gzMoO4NXDMux9sRVjOu1C3B3vlpSJDlSHTrCIbT..S7qZIsroYDQyjBW_na9q
 kOmjygO2ayYw6ReN1dP7U8ma3FW_jkAM1C.Q6tm622SOGSmA10y3vyhE6AQEwAIxZyIodwJiwzp0
 9JOElHyeWEp6AEb.1win1FYbiQSjxME6WC0ZBxGwcSy8lFty6uFmOMJyF59j8lIUcogCNF2nngDI
 .5Qe3fjO._cM.qwqWc84V1fZJ4qsJ04yFE.7.EAwmTn_OVkcCHZepP9se_nCGUkwxQOWKJlVsp4S
 Js05WxoHo2uFx4Whomomp7v1pQ8gfuL4mE58KgYEq2n4x0geIIt_dmuWTuPKVlp0rlOQbJUElHwy
 8R.UK8mhEfrHlf7fRmhL.0CMaWWiWdQIMvceRNyZ6e3Dr72hWv5VXdL7JqJFzK2SsQrgfm_amXSc
 l4po3C_DjBMPqC24wlaCc1XO4CqIQ6c9RrKu6LPHE.gyz291mZyCSD76NvNsqXQcyNXSpEkQbub9
 jQLAXPt4_E4mSjfoR9h22fhzeaEvMStYKbQs4hr1q
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 81e8e4b2-3141-45c8-9bab-4fa037b5cbfb
From: Chuck Zmudzinski <brchuckz@aol.com>
To: xen-devel@lists.xenproject.org
Cc: qemu-devel@nongnu.org,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH] tools/hvmloader: implement Intel IGD extended VBT support
Date: Fri, 31 Jul 2026 20:03:45 -0400
Message-ID: <20260801000354.16446-1-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
References: <20260801000354.16446-1-brchuckz.ref@aol.com>
Content-Length: 19725
X-purgate-ID: tlsNG-c1860d/1785542643-CE14687B-AF569FAE/0/0
X-purgate-type: clean
X-purgate-size: 20214

Modern Intel IGD devices do not work well with the current
implementation of support for the Intel IGD in hvmloader because
it lacks support for an extended video bios table (VBT).

Code 43 errors in Windows guests and failure of the guest screen
to light up are some of the problems that occur with the
current implementation.

To address this problem, this patch implements support for
Intel IGD devices with an extended VBT and OpRegion version 2
and higher which is required for most modern Intel IGD devices.

This patch also depends on compatible support in the device
model. If hvmloader detects the device model lacks such support,
it will fall back to the currently implemented protocol for
configuring the OpRegion to provide backward compatibiltiy for
systems that lack a device model with support for an extended VBT.

Support for an extended VBT is implemented in the newly introduced
function opregion_setup() which is implemented in the new file
intel_opregion.c.

Major differences between this implementation and the current
implemntation that only supports older devices without an
extended VBT:

1. The current implemntation reserves a constant number of
   pages (3) in the E820 map for the OpRegion which is set by
   the IGD_OPREGION_PAGES macro in the current implementation.
   With OpRegion 2 and higher, the OpRegion can have an
   extended VBT that must be provided to the guest with the
   OpRegion. This means the size of the region is not fixed,
   so in this new implementation the IGD_OPREGION_PAGES constant
   is changed to a variable in e820.c, igd_opregion_e820_pages,
   that is set to its proper value based on the the size of the
   VBT. In this new implemntation, the size of the ACPI NVS region
   reserved for the OpRegion in the E820 map is equal to the value
   of the igd_opregion_e820_pages variable instead of being set
   to the constant value determined by IGD_OPREGION_PAGES.

2. The current implemntation provides the guest with access
   to the unmodified OpRegion on the host via memory mapping
   from the host to the guest. This is insufficient for
   OpRegion 2 and higher because some devices will require
   modifications to the OpRegion for proper operation in the
   guest. So this new implementation provides hvmloader with a
   copy of the host's OpRegion that hvmloader can modify as
   needed for proper operation. Mapping the OpRegion from the
   host to the guest is only used temporarily during setup of
   the OpRegion by hvmloader and once hvmloader has a copy of
   the OpRegion and the extended VBT, the device model removes
   the host mapping and hvmloader configures the guest to use
   the guest's possibly modified copy of the OpRegion instead.

3. The current implementation lacks useful debugging information
   for the more recent devices. This new implementation provides
   useful debugging output from hvmloader, such as the detected
   host OpRegion version and address, the values for rvda, rvds,
   and the guest OpRegion address when the guest_loglvl is set
   to all/all.

Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Later versions of this patch will provide a link to the compatible patch
for extended VBT support in the device model which will be posted to
the qemu-devel and xen-devel mailing lists and Cc'd to the appropriate
maintainers and reviewers soon.

The compatible patch for the device model is part of a larger patchset
that fixes many of the problems that currently affect the feature of
Intel IGD passthrough to Xen HVM guests. This patch should be considered
as a companion patch to that patchset for the device model. Do not try
to test this patch with a real Intel IGD device without also applying
the patchset for the device model because without those patches, the
guest will most likely fail to start if an Intel IGD is passed through
to the guest.

There are different requirements to support OpRegion version 2.0
and OpRegion version 2.1+, with support for OpRegion 2 the more
difficult case because it always requires modifications to the OpRegion
for proper operation in the guest. For some details about OpRegion
2 and higher and the extended VBT, see the links in the commit message.

 tools/firmware/hvmloader/Makefile         |   1 +
 tools/firmware/hvmloader/config.h         |  15 +-
 tools/firmware/hvmloader/e820.c           |   4 +-
 tools/firmware/hvmloader/intel_opregion.c | 297 ++++++++++++++++++++++
 tools/firmware/hvmloader/pci.c            |  10 +-
 5 files changed, 313 insertions(+), 14 deletions(-)
 create mode 100644 tools/firmware/hvmloader/intel_opregion.c

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 21de721..ed42915 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -35,6 +35,7 @@ OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
 OBJS += ovmf.o seabios.o
+OBJS += intel_opregion.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index c159db3..bd3c0f9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -7,9 +7,6 @@
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
 
-extern unsigned long igd_opregion_pgbase;
-#define IGD_OPREGION_PAGES 3
-
 struct bios_config {
     const char *name;
 
@@ -43,6 +40,18 @@ extern struct bios_config ovmf_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
+#define IGD_OPREGION_PAGES 3
+#define IGD_OPREGION_SIZE ((IGD_OPREGION_PAGES - 1) << PAGE_SHIFT)
+#define IGD_OPREGION_RVDA 0x3ba
+#define IGD_OPREGION_RVDS 0x3c2
+#define IGD_OPREGION_VERSION 0x16
+#define IGD_OPREGION_MASK 0xfff
+#define IGD_OPREGION2_SUPPORT_MASK 0x1
+#define IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
+#define IGD_VBT_SIGNATURE "$VBT"
+extern unsigned long igd_opregion_pgbase;
+extern uint32_t igd_opregion_e820_pages;
+void intel_opregion_setup(uint32_t vga_devfn);
 
 extern uint8_t ioapic_version;
 
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 86d3954..97a234e 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -243,11 +243,11 @@ int build_e820_table(struct e820entry *e820,
         nr++;
 
         e820[nr].addr = igd_opregion_base;
-        e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE;
+        e820[nr].size = igd_opregion_e820_pages * PAGE_SIZE;
         e820[nr].type = E820_NVS;
         nr++;
 
-        e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE;
+        e820[nr].addr = igd_opregion_base + igd_opregion_e820_pages * PAGE_SIZE;
         e820[nr].size = (uint32_t)-e820[nr].addr;
         e820[nr].type = E820_RESERVED;
         nr++;
diff --git a/tools/firmware/hvmloader/intel_opregion.c b/tools/firmware/hvmloader/intel_opregion.c
new file mode 100644
index 0000000..59cb2c3
--- /dev/null
+++ b/tools/firmware/hvmloader/intel_opregion.c
@@ -0,0 +1,297 @@
+/*
+ * intel_opregion.c: HVM Intel OpRegion setup.
+ *
+ * Leendert van Doorn, leendert@watson.ibm.com
+ * Copyright (c) 2005, International Business Machines Corporation.
+ *
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ *
+ * Copyright (c) 2026, Charles Zmudzinski.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "util.h"
+#include "config.h"
+#include "pci_regs.h"
+
+unsigned long igd_opregion_pgbase = 0;
+uint32_t igd_opregion_e820_pages = IGD_OPREGION_PAGES;
+
+static bool verify_opregion(const uint32_t addr)
+{
+    const char *opregion_signature = IGD_OPREGION_SIGNATURE;
+    if ( memcmp((const void *)addr, (const void *)opregion_signature, 16) )
+        return false;
+    return true;
+}
+
+static bool verify_vbt(const uint32_t addr)
+{
+    const char *vbt_signature = IGD_VBT_SIGNATURE;
+    if ( memcmp((const void *)addr, (const void *)vbt_signature, 4) )
+        return false;
+    return true;
+}
+
+void intel_opregion_setup(uint32_t vga_devfn)
+{
+    uint32_t igd_guest_opregion;
+    uint32_t pages_needed; /* for OpRegion + VBT */
+    void *opregion_scratch;
+    void *vbt_scratch;
+    void *vbt_source;
+    /*
+     * absolute value in the host/guest except
+     * as noted in the comments
+     */
+    static unsigned long rvda_host;
+    static unsigned long rvda_guest;
+
+    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
+    /*
+     * Tentative value for the number of pages to reserve
+     * in the E820 map for the OpRegion and VBT.
+     *
+     * This will be the final value for the E820 map if
+     * the device model lacks support for OpRegion 2 or
+     * if the host OpRegion version is < 2 or if we never
+     * allocate more pages in the E820 map for the VBT.
+     */
+    igd_opregion_e820_pages = IGD_OPREGION_PAGES;
+
+    /*
+     * Read the value the device model is initialized with.
+     * If the device model supports OpRegion 2, it will
+     * return the host IGD OpRegion address. If not, it
+     * will return 0. If the device model does not support
+     * OpRegion 2, the device model expects us to give it
+     * the address to which it will map the OpRegion in the
+     * guest and then expects us to do nothing more to setup
+     * the OpRegion, so that is all we will do in that case.
+     */
+    const uint32_t igd_host_opregion = pci_readl(vga_devfn,
+                                                 PCI_INTEL_OPREGION);
+    if ( !igd_host_opregion ) {
+        printf("device model lacks extended VBT "
+               "support. Continuing with legacy support only\n");
+        /*
+         * Write the the OpRegion offset to give the OpRegion
+         * address to the device model. The device model will trap
+         * and map the OpRegion at the give address.
+         */
+        pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                   igd_opregion_pgbase << PAGE_SHIFT);
+        return;
+    } else {
+        printf("host OpRegion address: 0x%x\n",
+               igd_host_opregion);
+    }
+
+    const uint32_t igd_host_opregion_page_offset =
+                   igd_host_opregion & IGD_OPREGION_MASK;
+    igd_guest_opregion = (igd_opregion_pgbase << PAGE_SHIFT) |
+                          igd_host_opregion_page_offset;
+
+    /*
+     * We know at this point the device model supports
+     * OpRegion 2.
+     *
+     * Indicate to the device model that we support
+     * OpRegion 2 by setting the least significant bit
+     * of the address we give to the device model.
+     * The device model will notice this bit set and
+     * respond appropriately to our writes to the
+     * register where the OpRegion address is stored.
+     */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               (igd_opregion_pgbase << PAGE_SHIFT) |
+                IGD_OPREGION2_SUPPORT_MASK);
+
+    printf("guest OpRegion tentative "
+           "address: 0x%x\n", igd_guest_opregion);
+
+    if ( !verify_opregion(igd_guest_opregion) ) {
+        printf("error: IGD OpRegion signature "
+               "not found.\n");
+        BUG();
+    }
+
+    opregion_scratch = scratch_alloc(IGD_OPREGION_SIZE, 0);
+    memcpy(opregion_scratch, (const void *)igd_guest_opregion,
+           IGD_OPREGION_SIZE);
+
+    /* Read OpRegion version, rvda_host, and rvds */
+    const uint16_t version = *(uint16_t *)(opregion_scratch +
+                                           IGD_OPREGION_VERSION);
+    printf("OpRegion version: 0x%x\n", version);
+    if ( version >= 0x0200 ) {
+        rvda_host = *(unsigned long *)(opregion_scratch +
+                                       IGD_OPREGION_RVDA);
+        /* It is convenient to make rvda_host absolute */
+        if ( version > 0x0200 )
+            rvda_host += igd_host_opregion;
+        printf("host VBT address: 0x%lx\n", rvda_host);
+    } else {
+        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
+        rvda_host = 0;
+    }
+    const uint32_t rvda_host_page_offset = rvda_host &
+                                           IGD_OPREGION_MASK;
+    const uint32_t rvds = *(uint32_t *)(opregion_scratch +
+                                        IGD_OPREGION_RVDS);
+    const uint32_t rvds_page_offset = rvds & IGD_OPREGION_MASK;
+    printf("VBT size: 0x%x\n", rvds);
+
+    if ( !rvds || !rvda_host ) {
+        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
+        rvda_host = 0;
+    }
+    /*
+     * Write rvda_host as 2 successive 32-bit values
+     * to communicate location of the VBT to the device
+     * model. If rvda_host is not 0, The device model
+     * unmaps the OpRegion and eventually maps the VBT
+     * after we also write the guest address where the
+     * VBT will be mapped.
+     *
+     * If we send rvda_host = 0 to the device model, it
+     * will assume we do not need OpRegion 2 support and
+     * it will not unmap the OpRegion.
+     */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               (uint32_t)(rvda_host & 0xfffffffful));
+    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               (uint32_t)rvda_host_upper_32);
+
+    /* In this case, we use the mapped OpRegion */
+    if ( !rvda_host )
+        return;
+
+    /*
+     * Update the number of pages the device model
+     * needs to map for us to get a copy of the VBT.
+     *
+     * N.B.: Here, igd_opregion_pgbase is really the page
+     * base of the location where the device model will
+     * map the VBT.
+     */
+    uint32_t vbt_pages_needed = rvds >> PAGE_SHIFT;
+    if ( rvds & IGD_OPREGION_MASK )
+        vbt_pages_needed++;
+    if ( vbt_pages_needed > igd_opregion_e820_pages ) {
+        igd_opregion_pgbase = mem_hole_alloc
+                              (vbt_pages_needed - igd_opregion_e820_pages);
+        igd_opregion_e820_pages = vbt_pages_needed;
+    }
+
+    /*
+     * Write the location where the device model is to
+     * map the VBT in the guest with the 12 least
+     * significant bits encoded as the number of pages
+     * for the device model to map (vbt_pages_needed).
+     */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               ((igd_opregion_pgbase << PAGE_SHIFT) | vbt_pages_needed));
+
+    /*
+     * When the VBT is mapped from the host, the page offset
+     * of the VBT will be the same as on the host
+     */
+    rvda_guest = (igd_opregion_pgbase << PAGE_SHIFT) |
+                  rvda_host_page_offset;
+    if ( !verify_vbt(rvda_guest) ) {
+        printf("error: VBT signature not found.\n");
+        BUG();
+    }
+
+    vbt_source = (void *)rvda_guest;
+    vbt_scratch = scratch_alloc(rvds, 0);
+    memcpy(vbt_scratch, vbt_source, rvds);
+
+    /* Compute how many pages we need for OpRegion + VBT */
+    pages_needed = (IGD_OPREGION_SIZE + rvds) >> PAGE_SHIFT;
+    if ( (IGD_OPREGION_SIZE + rvds) & IGD_OPREGION_MASK )
+        pages_needed++;
+
+    /* Update the number of pages we need for the E820 map */
+    igd_opregion_e820_pages = pages_needed;
+
+    /*
+     * So far we have allocated vbt_pages_needed
+     * and we will likely need to allocate more
+     * pages to fully contain OpRegion + VBT.
+     */
+    if ( pages_needed > vbt_pages_needed )
+        igd_opregion_pgbase = mem_hole_alloc
+                              (pages_needed - vbt_pages_needed);
+
+    /*
+     * Compute the final igd_guest_opregion value and
+     * keep the same offset as on the host if doing so
+     * will not push us across another page boundary.
+     */
+    igd_guest_opregion = igd_opregion_pgbase << PAGE_SHIFT;
+    if ( (igd_host_opregion_page_offset + rvds_page_offset) <= PAGE_SIZE )
+        igd_guest_opregion |= igd_host_opregion_page_offset;
+    printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
+
+    /* The device model will unmap the VBT */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_guest_opregion);
+
+    /*
+     * After unmapping we need to populate the memory hole.
+     * If the unmapping failed this will crash the guest.
+     *
+     * We could try to use the mapped VBT with our copy of the
+     * OpRegion, but it is probably better to BUG() if the
+     * device model failed to unmap the VBT.
+     */
+    if ( verify_vbt(rvda_guest) )
+        BUG();
+    mem_hole_populate_ram(igd_opregion_pgbase,
+                          igd_opregion_e820_pages);
+
+    /*
+     * After unmapping we are free to shift the VBT by
+     * an arbitrary number of bytes. For efficient use
+     * of memory and to keep the memory map simple,
+     * place the VBT contiguous after the OpRegion.
+     */
+    rvda_guest = igd_guest_opregion + IGD_OPREGION_SIZE;
+    printf("guest VBT address: 0x%lx\n", rvda_guest);
+
+    /*
+     * Until now, rvda_guest has been an absolute address
+     * in the guest. We need to translate it to a relative
+     * address if OpRegion version > 0x0200 and in that case
+     * we also verify it is contiguous with the OpRegion.
+     */
+    if ( version > 0x0200 ) {
+        rvda_guest -= igd_guest_opregion;
+        printf("guest rvda (relative): 0x%lx\n", rvda_guest);
+        BUG_ON(rvda_guest != IGD_OPREGION_SIZE);
+    }
+
+    /*
+     * Write the correct rvda_guest value to the
+     * guest copy of the OpRegion and copy the scratch
+     * buffers to the correct address in our E820 region.
+     */
+    *(unsigned long *)(opregion_scratch + IGD_OPREGION_RVDA) = rvda_guest;
+    memcpy((void *)(igd_guest_opregion + IGD_OPREGION_SIZE),
+           (const void *)vbt_scratch, rvds);
+    memcpy((void *)igd_guest_opregion,
+           (const void *)opregion_scratch, IGD_OPREGION_SIZE);
+}
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c41c8d9..07a37e5 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -43,7 +43,6 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 #define BAR_RELOC_THRESH GB(1)
 
 enum virtual_vga virtual_vga = VGA_none;
-unsigned long igd_opregion_pgbase = 0;
 
 /* Check if the specified range conflicts with any reserved device memory. */
 static bool check_overlap_all(uint64_t start, uint64_t size)
@@ -190,14 +189,7 @@ void pci_setup(void)
                 virtual_vga = VGA_pt;
                 if ( vendor_id == 0x8086 )
                 {
-                    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
-                    /*
-                     * Write the the OpRegion offset to give the opregion
-                     * address to the device model. The device model will trap 
-                     * and map the OpRegion at the give address.
-                     */
-                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
-                               igd_opregion_pgbase << PAGE_SHIFT);
+                    intel_opregion_setup(vga_devfn);
                 }
             }
             break;
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:17:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:17:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379719.1624134 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQF-0000ym-Tu; Sat, 01 Aug 2026 00:17:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379719.1624134; Sat, 01 Aug 2026 00:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQF-0000xZ-PV; Sat, 01 Aug 2026 00:17:51 +0000
Received: by outflank-mailman (input) for mailman id 1379719;
 Sat, 01 Aug 2026 00:17:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQE-0000rr-3E
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQD-00AjZN-Cv
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:49 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3a84-e002-0a2a0a5209dd-0a2a4501e7a8-40
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:48 +0200
Received: from [98.137.68.206] (helo=sonic304-25.consmr.mail.gq1.yahoo.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b2b-5984-0a2a45010019-628944ce9cb4-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:48 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:46 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:41 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543466; bh=aPSDtc80QxBay9GHhGU8jyIiLkLfb59Aeoc3NEAiIBw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=odcmwXJKuXz0mR8QwvIHWS5CWZdlP4zmZcTbRTSPwnxtghiNAD6/TQex0uG1kZ6c87VlVa0VXjbadj8/iDFtpe6am+9BQCY6jN5mUEMv3s50T+5AhJWeLNjG1hZWpM0D7iYXuYsKvJkdVmMAejowRt3d2fAi/cRXbJC5B5AliX8vVu4fnumhfjXsP4Nk+/MxQwJaf1gchf77Pv+ncoOpGJD5hyhuIs7sy8pF7dkl6zZs9gNwEzz90cd3udKQxc/uZNP5sh7ONYhA/JqjTV0a0qESReB/8TRfHGLNu7msiJotCM9HBwgALv/mWip+ppAN6SfwFMkBhvNID11aZQ6M8A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543466; bh=g9vcxOFW9WO8GJRAE0inlaJ0qmxWPRXJTYNL6abXrOx=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=agPsYFLa4qHJiBe2k21l+dYlmkBwUxm3cth0vIKcnMgRADMnduqqybndvN3sbVV7rTsnaakIBjTg0ZH9f3DXHi3JwzXl7yVQrCGq2O6q4dJfr+K2cAaZEnY3nk4+47osWt8xfWk3xIH36lr6iJHMQcQPzaq7IvgSLioTr6eOoX3rZ4d7T4godBmJiaR4RxARMWDUMxbxqcoX96VcvZJUK9pfeUpGlGp6kP82m+oeH0fnfM2ez1oHpsz71N9SFYNMnTNuEneNkX9v2FS4C/2xlgUS6RaFZsIgorT8PPZZYw7bFXiqdBEcgu2AN1oyDM0wQAEBkRTSMdfbaYwNlPW8Dg==
X-YMail-OSG: CkDsvboVM1kpbg5Mpy3X92H1oMm50miAqVpeWOVcuRiuxh_RK79p5J0uCxvsOMJ
 lbN0Xkg_ZmQlffZEgrgyNzczcHf4ojzXZEIKIgXEHRFED5hbuPP8SWYc2ZVppvdPF9XQxWEK8iO8
 FTti4rEn_IsrYEcNIL3FuZSKUJwRwqol8LHse2H6cntOuDDeHekD6J.XRnkRnONzVvFQ6ebYvSLA
 TATGSvRF5.PATQtkaUET0OzuZHS2Mv5F5TcCqgB2lczBmaFxH3ssVTE_8t09utRPKXa_eqN1ubB2
 IOeD7nU6xYoIoO258hw4A_WJp1PXh.F7QyFeRgLllVAM6uIxtcoAF1tM6QXnQHHUA0ULM6bVs.OB
 zJc3Y_OdfORvvOJqEMfpcVyMVvrs5XOUjm3qmVO0kS_Q_0BBg2zZ8.ZziYJojLuh1Ij2jrwgt4i9
 kDh1ohA9yz03DbzRAfrwCuHoVVXrOrpNYapw6ejRLf_9xG6Ii0Qdwei43V0Nf0hWKzUbfCXUbU9Z
 Ef0HZYaZ3bPTQlkdwlzWiSB95SU.YeDS3EcSn9yLQdQsoBbDbG0JkSqQX81B0KwYdluNjOfwekDN
 GSjZZrgeS8kOaTYeTUwXT0Er5XH_5YGQJlG8htPCh4u_wWkIvf4irB23rH_zSBWKiNv22.0f7NHX
 YOVlx1up6bqbUG7kFpFbhUCgtw2nZomdClWU78utA2Cd2Sflnm3R7g8O8b42A2q8FVRAcvLHgy.i
 McxX9GlONL0urFahnON8lQuy_qUjfuAQUTDfDF_aPWRD9xIPQ6FUC9EwA54GWPW8ivHIlOfZEkZI
 Fcb6Bf4hhQ7mDoNv8m.O1LD3NFCZ00oAhcN2xTjgbzFwiQElHfR_v_Jl7jJPpuD_nHLh0r7_qPoG
 uybctR3S8aQYk8Rh08zqKzypkTMSqtatAiGW12lmqVePQYhyDtHDAGJ9CHHwg5ryBIVorc5osJ9V
 TBa2A8oyhEqMGXXMJr6tE8XArxfGRxj.qw6vezPcQ6gj8xl5udluiuuIgs3q74pIwQtzf8QJxixM
 l9phMgmnPB547YBFj392s7fW07rRzc_x2odOS49UyIWUFKhWR8ypZNdAB.b1A7_1d8e_fOM03s4d
 cpUW2h1l.Sy.CtQaWhTcfoaypOTYDssw5ahUSpIL05S.BFHLDZ__4gcs24fO6fdA2dOUS_3VlMJO
 qy.xLAHsoVktnlb8ZKBuwV2w8JiA2xKwyIpovXvKezptAsg4gAdjO80yCqPtiEsg.a7CnEIGwiXp
 S7.N2Rl6Bhl0uLGGo36ZoWD0yPuCK4xkiP6qBecZmBO_M4.MrZe5LBC_8BpoAFwBhhlshrgV4ieZ
 H.1pDRcSEp0pYMunfbk3nmOQw3zIbMiqL1SZDTpH0fH8TYC_bKTUaQ0JK88vzzPXKrgaY.Wgu1z7
 RsTkD00elxcuICbY6dSukKYGDA5vojeYFe8zLmYCIqfqnwK3V09eYQb9sxTPDV3K0UIc6empwZFy
 _lGfOBxlHdJgzpCeKkvLqXU03zqGrLQXqeA98m1uoPx1LFG9GSyA5UeZmWlN9Ij3QMmTVX_aHC86
 qA6sXis3XKVd2NssjA8VPLKCv.Ft_Tu5vhm6vZi5KgB4n8tTU_VHBnAW3sJNh44fI5lOteLoJWkM
 FD78mKumArUBLsW.sbiMqXmOytSgkbdKqrVK6XU0aygkaJFVMj7Igb2Fbn5UoCdRYhVJVrlOJCVU
 AxldNt56XZmnMBhixdaIyRWlGl018ishkFtbwoEIKAJ5a_2GoX51ETJcCnjE3LdJA8HHJZUS03WN
 tjJo4YxwUTSKFu8mE_zLT3KeZ6qVhQ7T4R96syRMQSB48R9qlLIz9naubkd55wThHWlYUCKYskIp
 pb1jafOcyykirr0hNpXJkKr82Pvezh5lsswAbaNENX7dFcNKFKGvyzOktOUOTymmxixGO0RFHsXc
 OMfwTGk3sU6_gs_PBmuurRxosChZkvb16bXNx3NXs1mo6HOsWSp_ZYzWewn5cSXdf50o20QUEbNo
 9_.BJhAXVrhI7cZtuhb9AC7IZNGx_X7.4zButAgEFLzVBnbpR.vj7lAvssDPohKsN11N2QmnSTsM
 YafAcaGuu0cYUoCZDC2OJstesALPInKyJwTG7QAxyzuK738Spt_zuXmk.KWA_fCCy6DasO2AxkUt
 wVNIXxvJbrp9bqROng.XPyyY3NFhkqLhPWlcEJ0L4B5p0l2HhEhcdrcyMt4TveGUKcS44WoJMDsF
 dfJ.VpvUc1CxkAX5_aHBtYgrRrhs_CJ_m3Y77ESLdUzBlOwFc
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 19268ac6-fb05-4394-9e7e-926ddebd28c2
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 1/6] xen/igd: get PCH info from host sysfs
Date: Fri, 31 Jul 2026 20:17:25 -0400
Message-ID: <20260801001737.16509-2-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 5699
X-purgate-ID: tlsNG-d62444/1785543468-BDC79757-73620B74/0/0
X-purgate-type: clean
X-purgate-size: 5851

The igd_combo_id_infos[] data is out of date with many
devices missing from igd_combo_id_infos[]. For newer
devices not in igd_combo_id_infos[], get the infos from
the host sysfs. If logging is configured, print log
messages displaying the PCH info used for the guest.

Introduce helper function xen_pt_get_host_pch_info() to
facilitate getting the necessary information from sysfs.
Treat failure to get the host PCH device id as an unrecoverable
error that causes guest creation to fail. If access to the host
PCH device revision id fails, print a warning message and use
a default value of 0x1 in that case.

Also, use errp in xen_igd_passthrough_isa_bridge_create()
to set errors from xen_pt_get_host_pch_info() and cleanup
on error path with xen_host_pci_device_put(&s->real_device)
and object_unparent(OBJECT(&d->rom)) for errors when creating
creating the IGD PCH bridge.

Add cleanup with object_unparent(OBJECT(&d->rom)) for errors
when setting up VGA BIOS for GFX passthrough.

Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - re-wrote xen_pt_get_host_pch_info() using functions from
    xen-host-pci-device.h
  - add more error handling to clean up better after if errors occur
  - don't consider failure to get the PCH device revision id a fatal
    error but instead print a warning message and use a default value
    of 0x1

 hw/xen/xen_pt.c          | 10 +++++++++-
 hw/xen/xen_pt_graphics.c | 39 +++++++++++++++++++++++++++++++++++++--
 include/hw/xen/xen_igd.h |  3 ++-
 3 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 0fe9c0a..c8f08b5 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -862,12 +862,20 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
         if (*errp) {
             error_append_hint(errp, "Setup VGA BIOS of passthrough"
                               " GFX failed");
+            object_unparent(OBJECT(&d->rom));
             xen_host_pci_device_put(&s->real_device);
             return;
         }
 
         /* Register ISA bridge for passthrough GFX. */
-        xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
+        xen_igd_passthrough_isa_bridge_create(s, &s->real_device, errp);
+        if (*errp) {
+            error_append_hint(errp, "Failed to create PCH bridge"
+                              " for passthrough GFX");
+            object_unparent(OBJECT(&d->rom));
+            xen_host_pci_device_put(&s->real_device);
+            return;
+        }
     }
 
     /* Handle real device's MMIO/PIO BARs */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 7df9344..b37f9b7 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -2,6 +2,7 @@
  * graphics passthrough
  */
 #include "qemu/osdep.h"
+#include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "hw/xen/xen_pt.h"
 #include "hw/xen/xen_igd.h"
@@ -376,8 +377,33 @@ static void pt_graphics_register_types(void)
 }
 type_init(pt_graphics_register_types)
 
+static void xen_pt_get_host_pch_info(uint16_t *pch_dev_id, uint8_t *pch_rev_id,
+                                     Error **errp)
+{
+    g_autofree XenHostPCIDevice *pch_dev = g_new(XenHostPCIDevice, 1);
+
+    xen_host_pci_device_get(pch_dev, 0, 0, 0x1f, 0, errp);
+    if (*errp) {
+        goto error;
+    }
+
+    *pch_dev_id = pch_dev->device_id;
+
+    if (xen_host_pci_get_byte(pch_dev, PCI_REVISION_ID, pch_rev_id)) {
+        *pch_rev_id = 0x1;
+        warn_report("failed to get host PCH revision for Intel IGD, setting it to 0x1");
+    }
+
+    xen_host_pci_device_put(pch_dev);
+    return;
+
+error:
+    error_append_hint(errp, "failed to get host PCH device for Intel IGD");
+}
+
 void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
-                                           XenHostPCIDevice *dev)
+                                           XenHostPCIDevice *dev,
+                                           Error **errp)
 {
     PCIBus *bus = pci_get_bus(&s->dev);
     struct PCIDevice *bridge_dev;
@@ -394,7 +420,16 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
         }
     }
 
+    /* Newer devices get PCH infos from host sysfs */
+    if ((pch_dev_id == 0xffff) || !pch_rev_id) {
+        xen_pt_get_host_pch_info(&pch_dev_id, &pch_rev_id, errp);
+    }
+
+    XEN_PT_LOG(&s->dev, "PCH device id: 0x%x\n", pch_dev_id);
+    XEN_PT_LOG(&s->dev, "PCH revision: 0x%x\n", pch_rev_id);
+
     if (pch_dev_id == 0xffff) {
+        error_setg(errp, "failed to get PCH device id");
         return;
     }
 
@@ -406,7 +441,7 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
      * Note that vendor id is always PCI_VENDOR_ID_INTEL.
      */
     if (!bridge_dev) {
-        fprintf(stderr, "set igd-passthrough-isa-bridge failed!\n");
+        error_setg(errp, "set igd-passthrough-isa-bridge failed!");
         return;
     }
     pci_config_set_device_id(bridge_dev->config, pch_dev_id);
diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h
index 7ffca06..da51f09 100644
--- a/include/hw/xen/xen_igd.h
+++ b/include/hw/xen/xen_igd.h
@@ -22,7 +22,8 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s);
 void xen_igd_reserve_slot(PCIBus *pci_bus);
 void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
 void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
-                                           XenHostPCIDevice *dev);
+                                           XenHostPCIDevice *dev,
+                                           Error **errp);
 
 static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
 {
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:17:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:17:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379718.1624130 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQF-0000v2-M4; Sat, 01 Aug 2026 00:17:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379718.1624130; Sat, 01 Aug 2026 00:17:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQF-0000uu-Ho; Sat, 01 Aug 2026 00:17:51 +0000
Received: by outflank-mailman (input) for mailman id 1379718;
 Sat, 01 Aug 2026 00:17:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQE-0000rs-2x
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQD-00Firx-DI
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:49 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3ae6-bab6-0a2a0a5309dd-0a2a4506dbea-24
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:48 +0200
Received: from [98.137.69.83] (helo=sonic314-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b2b-195a-0a2a45060019-628945539ebc-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:48 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:46 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543466; bh=MtlsR1zLIBzo7DokWP/PBZ1CtP2Neyt/oQv1hSzEZAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=l2NAnr2ZeOl00G7zLAfZYUgGGgl3bASj4jRKmAak+9N9/hG24pcUM/LzEn1xl4fJMjpfmcW4O10lvFpATFzfX9CpSfIxtRInzt+3HuBZgIclDqkLODwk2pyWHNVYX8+90vj2YMDizy7uAq4+8YT8E+L2LsbsA4zCApdIWya8uXQV7SXi6LiOzWpYAkul/mTRfIIfjducGFC2IwrAvlqgsviu77t5dtvaEjydWtiMDY/SFD10L5fq9wfzVPmpwSymGDgqyVAVC1NkefvikFb7qmsxJGz7dIwosXSVTfZz2nnjp2n1LIDoYf9SETOVXytPLvpYKgBL8ziU2Ib9lpG//A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543466; bh=5ahFWUv8lvDNModk7E2uOFUzvRNOZLW3kzh0fNuw3rd=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=jO+g+4wGJ7JwN/G8/5y3TWUhOu2HKR7nJQIFCXXO393SFuJqbxDeBBqXBqrGsrFqwWdQOFyUupbAHB1smtjynyOEMHFUJDHF8fAi3ToXpWO1MWY2CfKSXylgzU80L2OjI5f5sf2I3iscHYz6y06UZ7q841cp9qKyA+xxUy4EDnCjOCmS9DSwOU6xwdg6lCzQbjxD3wWJAeJGryRhxTXUVF++gV8j8vAOBYDFKbMAbyQhB45w9AFcnBvkRNgtwPvtn/+TuRte86J35QG2Se41UmlkR5NxJOn92kuXBWh32mlbWr+ZSBjiSoae3gY1JjBsm7HQI1yfNsRLS342FASJtQ==
X-YMail-OSG: gT3lLSsVM1lm2IGDDEANNWhuhXhBu9oXnaJGyZ28aKnJKr8IBok0tFrcXySMacJ
 Wpy9JYTmVsUvpQ8aYqe2.J23IobED.xdg1MZV3gvbzI1KpvLzxoLL4mCVb4DKGv7KSXc8gnChmPu
 1lxcASxzyA0sPTMnFzfYpjWszTKVYJMFikJE8SgHKd8KjX4w8YrZNDSqOqqQhldD41rTH1WabT8k
 rAwvc5yDLXQrpLi3W6SmZIXE0vk_MKoeofkUxq.2lweeWKh0nPMHaNpaLWa_4Q454aeKTHcJfFpB
 ttWNOc8zROh4OpEcIpBnk8KUO15Wnrfh.mKGQygjM4OibeXITow7gQLMBCIFSE7HQ_qXThG27F1j
 nauoZnIdGYzGDbfiWn4_cXwiaY_pS1BlUdc.NXkxFKEaxNvr6K56RCTvbusyfCjb8dRTHf9OJ4_j
 cTFTLyl8Sqh0FkILwA6h_Vk2BsLfolO7GKt9ByLNiEMGbSvt_A3KjxK7kWIJYtCBu5GCGuosbIpN
 gmj53mxvsUy9W2DCTwZX34NhoFPd3eJHqngAz63f0Dr3BPSszz09c5IlJhwBAx9I2itH8IwCnRcv
 yZRMmBEc55yUd3EfmOI2VvY547FoZM78Z6zNrMrJKQUjIagiDwecjcJGzVt8eMvFw2m4aHYT1lyC
 aBJEGVA0Qjml7LbSX0yOh7sT_5posDSWxWXF0c9cip4UrBTHZl1WBWYobgSnMkoqtOQ24D7HWL3t
 1Om7bSfxfTR3yrQmcnfxJdgPsrRRxSTzbMf9sFtiIUJ_flzInYb8QkJPpoc7WIqoSBHVSsFVoqRo
 O2a0hT09iMgfD6MOpDRnUt4RPLL44TbKGk8XQuJkNRKeN799Nc_bVbjFLy5rKGMm_1Wh7RodGwxu
 rN1EyHu.rr8O1INZHiByuGvABdCX4vilBQoMv4vChG38Eq7lm6SYdGh2R13AqxZDI9Gx1DGXEdon
 hwd4LYsQdPd5dF_fpAyDNCVYFkWaPqafaU_Vz_wuWXelKMLenYKPOpD40Ja1tSibmKQE9ZIjZSW2
 FsapOInc3CvAZ2U2asC_5lZ1DWTR9DyWaUjXFz07U9_2EugKeWUhbgRHJCtorumWZ_KdYhTH4OYL
 .YbsxA9o2UNkf1.Y2ujdYftI9HXIjBYMwhB.C2KkrWP.KeC4DAoX1Gx1KndPHdBqnKal9w0KaS1I
 7pf4ci95rtbrbPZI7pZG.0nie7xzsqRiCz4INP9QZvuDPZ4v8f2ih2bvgF79UrJAGCJxtafsTqaB
 JD94VsldUt7F5vmmJ0iI9izuhKDIwz3Zkyd7Vpv8gy2kXa3MssR_ug5AZXejSTJgk4Pk1N3plAlA
 z9u4x7IkIBC7EegRl.Ui194iSJyTIPXbsHcwX5X_hgl8rXLXf0eBlsqyu4ImHJdHEXAP9Qpdkk17
 hVxhgafEeea9ezfJp_mg_ZMj816YlzYRy5q0HcNxE4eCEsvCVBafjwUntw57jRRnVN8UncBaUuK0
 Q6WlHBUf9mmdic4kMNsUeJp1jfyuGzBVRBTDBRgPsffORyY9bdULEzDk6gWp2UGEMZH13i.lBGn.
 YD_weV7zsyPqLvIRT5.OZlw1nJhsEMdW_INz6Ac84UfkDiLiWwOXJ.EQQDDVvFyE_ENEs3YeJ4jh
 PmSeGB5Mv7.Tk27.g5.3jifhDFqD.I_ZEXb7NOnhb1h1Y6cuK23b7UOFbKIOVPDV4.bctL3g1aS8
 2U.bHN12X78Dd9jJbRZPIDpk1CLbHct3s07fNRsstwCzM5xLi4UDq5MIhybwcbaEKyGJ7ymjLpNR
 uUCg3w_yavzfJhp093mXaYFc87rsElWqoHj1DVD9LIwVMjZgz8p7UUbiCzFmgt.Z.UNAN8Kf89Uy
 YVwu.jSF6yfBGNtT787dxQ.cQ1JnZQzp3rXVWg9QdV_HctWMub5SaxImA4P7Lu_KuNNoFCMjKMWR
 0y1ISuOnqP..R7qlIxm8epK5vevI6tTZAINDhOrYuCGyBB3TX1PlUT_v_a.HbbdT7ET2YQ64xHsO
 _4XrEdrpRwLGZ1fn75OR6fYIFKA2f7Thgg06Pd1DDCjZ_CWOOrRp8oFWal5HzwFoK4msQUpsf2H7
 u3dg03h1mBhoh4QCl5LhvdD6dSDTvZnGj3Q79HX63z28mbEbQTdO2o7WnE7d3uGv928dKV_xq95.
 UW6ecAcVE8OJPpxL5F46pheb8Y6wWfl3ZXqh5ujcRDNBhu6ZCsf6a2PyfWQf3R799tN1uKX9WNki
 oO2sif9h.FexmR388UyMb3axdpXNZg1WOlfx9F4KxaIgOlb8n
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 6e72e470-4730-41e5-b846-8856782acdd4
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 3/6] xen/igd: fixup device id before registering rom
Date: Fri, 31 Jul 2026 20:17:27 -0400
Message-ID: <20260801001737.16509-4-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 3165
X-purgate-ID: tlsNG-16d1c6/1785543468-F6C7777B-A84B88A1/0/0
X-purgate-type: clean
X-purgate-size: 3246

With the current implementation, Seabios does not see the fixup of
the device id done here and consequently Seabios does not load the
VGA bios and the guest screen does not light up until the guest OS
graphics driver is loaded. So there is no VGA output from the passed
through Intel IGD from either Seabios or the guest bootloader with
the current implementation in cases when the device id needs fixing.

Fix this by waiting until after doing fixup of the device id before
registering the option ROM. With this patch, Seabios sees the fixup
done here and loads the VGA bios, and both Seabios and the guest
bootloader light up the guest screen in cases when fixup of the
device id is needed.

Also, remove unused header hw/core/loader.h.

Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work")
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - Add a Fixes tag

 hw/xen/xen_pt_graphics.c |  3 +++
 hw/xen/xen_pt_load_rom.c | 18 ++++++++++++------
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index b37f9b7..0ae95cc 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -223,6 +223,9 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
         }
     }
 
+    pci_register_bar(&s->dev, PCI_ROM_SLOT, 0, &s->dev.rom);
+    s->dev.has_rom = true;
+
     /* Currently we fixed this address as a primary for legacy BIOS. */
     physical_memory_write(0xc0000, bios, bios_size);
 }
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 319efca..407b630 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -4,14 +4,22 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
-#include "hw/core/loader.h"
 #include "hw/pci/pci.h"
 #include "xen_pt.h"
 
 /*
- * Scan the assigned devices for the devices that have an option ROM, and then
- * load the corresponding ROM data to RAM. If an error occurs while loading an
- * option ROM, we just ignore that option ROM and continue with the next one.
+ * Normally xen_pt_register_regions will handle loading the option ROM,
+ * but in some cases, such as for the Intel IGD, the option ROM might
+ * need to be modified.
+ *
+ * For such cases, use this function to get a pointer to the option ROM
+ * from sysfs. Caller has the responsibility to edit the option ROM as
+ * needed, call pci_register_bar to register the modified option ROM,
+ * and set has_rom to true for the PCI device.
+ *
+ * This function must be called before xen_pt_register_regions is called
+ * because if xen_pt_register_regions is called first, it will register
+ * the option ROM and any attempt to register it again will fail.
  */
 void *pci_assign_dev_load_option_rom(PCIDevice *dev,
                                      int *size, unsigned int domain,
@@ -76,8 +84,6 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
         goto close_rom;
     }
 
-    pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom);
-    dev->has_rom = true;
     *size = st.st_size;
 close_rom:
     /* Write "0" to disable ROM */
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:17:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:17:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379720.1624140 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQG-00013f-7C; Sat, 01 Aug 2026 00:17:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379720.1624140; Sat, 01 Aug 2026 00:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQG-000124-0h; Sat, 01 Aug 2026 00:17:52 +0000
Received: by outflank-mailman (input) for mailman id 1379720;
 Sat, 01 Aug 2026 00:17:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQE-0000rq-2x
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQD-00Firx-CP
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:49 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b0f-bab6-0a2a0a5309dd-0a2a4507c094-8
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:44 +0200
Received: from [98.137.65.83] (helo=sonic313-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b27-b4ea-0a2a45070019-6289415393ab-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:44 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:42 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:38 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543462; bh=HIdr9C+lQ6Jo7WCNlxAtCo2E+oJ9NtzQ6wQnEjmdA0c=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=HJyFvByv/JaHrQ8YDyLQg80tGhOCl+wqOV2V/fp5Rp13BcrSKyY4seukQgb7gjr8GKUf2vOyfArtokuWAa9w3xBLT1o2klLyJ+ww0Hl2lk5cc1stBxr7t1XKYhBsiI4V2mV+Uax96Kyl4ilSS4gmWHZh258zNkPzd48vVypwoZr/WUSc+hHyUtpR1HskiqZJcQ2Zc70T4YVFGHuQGwG6i5xlIM9mXGvihloc/Jhf6ax+QYmLdyScDH1Q9dUPYH3h6ptGxvkQIl3dxJSmpHex0tOvrKrTDjnzlbzAwdF4WM3N+SUUMmrGR6HYZVbawRQ4/K86uCG1TBKaiIms8C3mjQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543462; bh=y3QEujPX9kE448RVtEETa7Ed9ZNYf7OrJSkBxZtAVNF=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=A1oMkOHopeoIOr1bQdvA/KSB64iT2kiPxX/YdvrXBQ2R3hkwxyoEVbCKZPxHf4JKlwt2BzCny+furZZlYEUzD5uECZY1BFs3nOlaMn+il98pu2TdryHXn99NrOJP+a328b9jd35Fmyl1RaPdGtq+pM+ELPr7gSyprQNKkZ9Wkf4ULgFz7gz9A/javO6KMkCPl2DiTjAOc+PJDeqlhfO2Zj4fcIBjZXXCBTcWl0a1DxxtG5Zl+1aSmD52hajQXi0DUH9XydMaAprtxTmRMvtiPtAsWPMCWCREeRfTM2bHgPQrgouaL5Wt94okqHI032dzQN7+tPQXwajJzFu5zuxeSg==
X-YMail-OSG: ne4VrocVM1lH1iDmo0cvieuzMkAyBDUp_2QC5WjVPFKC7wyOU4sJPUOTcIIAxxg
 338sot0z0Y1Fof4BGUYmZna9OAzYkZRPFVpoLX5AiPjhv_H6ecp_SsW2w9LRtjszqkt59Y801rtX
 1.0fFCoUqluAOLY76W80DXouX36JeJtCo51Lf6R3jBHk79e6J_ErzFxZcQGumxa85BPx8YJ1sYG5
 jsdf4UFrSFjey9BAWK2pslNofS0SOzeno_9cqVIoID86ME1ZTvsR8RFDFid.bSNnQmXnz_SaioG5
 9OZ1k0OhvXrQ7kzP0SsIC4s19xSNB8kBCIOOPWBl4By.nkEMDueI54AEgQD1I.m8toj1Rl_8cVFV
 AOALx_1FaWC.ieOBLhVrogDqChUOMwXLPzVh.bs2anRs34RIXNQ6mPSLW5csIit5ghl.hisUIjU2
 F4VTL.QKKJ8yg4aw1FAM1doE8ir52C9BpyXDZbNmqSC14cu26j5OUubcb2ja8w7WBK9GT9UB9tgL
 QFUrJ2YQp2oifXsum90lODu30FXTy0VvUg.pm64_E2RN1rIWq4TzHcNDF.QlNB_IdmP8t247phAK
 SdRbfwjA9SYYnZqzoKnQRuJVyp3ersT1WvLod8jH6D5OuWLNh1bwLiDLBK69yS3uWaocO9DGeNGc
 ELXH16cz4lsH.PCR.VCMHyR2vJklTaQ5c0u1MFStg2rd5N.EYDU4V2vi1zyQ_NBb1BpwqxLmx448
 B7M5e1RvhZSB2GflTlRsd6lc3vkX6vWTvXBXRGzHi5JKdbzrTDflcMEma_PEekVbHDntiURYg2Dv
 pAK1YbWGMJpbiEfe.7SiGNlO_wyNtFwG.McndWCDRvFcgp2kIHoAaqEiowLTL3ExQ3IMti0hD4HB
 p896PSUFQDHgVDbzp5DDppVpEkm04pYKMxCpSA_tPYFayUO5TjX9txo0OQs4CJZypSFgwEAS5faN
 g2exS44QG7NZLAo7TFklWpjcpr86UY6cqYN.mw1fRkDyUMSjtOjR1J2Qplraxaf._kzL7v1RBC8Y
 ewsZ0QywF_beCnK7RmYoGMeABYmVcYj_3Li6oExpiMbG3N3at9Fn0BnFxefy4rawWrUfD2bGPK.I
 scr3zbtEYLm6gGJHNIccKPltdC4.qJNbRVIAypA0SZVYmKjUVE.tQeDTfHqoPQH6OSB1Upb9lLYL
 5AQwNWAOg7.n8YXsmo3dhIuppfT5UsQMTt5i3qwYowebrmZtkDI19lLQrHM89N54125QxPXlGq.Z
 lM_5Bu3K7iV47EUTp2JH1B0tixmq.RQo_18lxQ4I957jGa3uZCXHrTkHMfj7ayLsTf838DrW04Eu
 Zb72det6Zc8zxuY2rr9Fm69wTnkxfsBQtskbhiYdZHyLDVvHj_6o8dIp8.9VgJrizVzN.IYVTLvN
 g4z0PuLREHE0mTQlqppajrZON2Bv64eUAAJiQm7CMnFKNPQu07GcHkgnWGbuTaEnkyLO5AkrmJ9q
 Nzo7lhRKrvyLDLTX9KgNsTyq1wCo0ZAhXHmAK58jZK79fJif.hbOtOd66YknW5QsOEIiU7wrpEgX
 6y7cF4uGOV.jtpzDJYiANr2016YbkO9jmlEKKDL23Fz4wXVZjZpz6vey2AJAxMO3vhqO65bQqz13
 w9Lg6KuBTRovKMEva_di1epZIczKriME3M9viLOCw0NMu57RsGXmfZpT7OPFHuPtYywScFxVjkAB
 FQIBAwjnO5U2W.rKUrVxoTCd33ATdH.3gIFcw_ZpXXG_gS8DbowKZwEba75TGLe5M5vrLiN2bfAH
 cxMKRE0AcG08MN1Z7T6DAqimA81PIDqrdspqP0lIbLP8ha1HeyxgDf26mZ5jQiNnntMCntRu0TkH
 drqZw0yHNPGOP4uNGh8AIaoWypfA0tCe.ejSeK8GleGy7I5WEqX29OPsWRG2g3YHO9Pj40S4KHlN
 vZZAbkaT0D_kcfIHF2cS60lK2kZ4UUhr5efiKBw3TTSIA8or8fn7.OyI7JwmmSb8llc1SuSfhtJA
 kV5Glli_h69vrhDq2uaFzkZA.UNA6YP8o6781GfUStYSgH0XK.HgKV3AAMH_ntEMDW3H8sYXB2kW
 YcWj9LHGlrKd0UFgoY3ktHkXl0xOaHvpEvHmS_MlaeaHb1INzoqBQzI.obXpwnl0CqanjI86eb_k
 2fM44zyewmB2U5BZUg617YFFJs70yWOc_jr_RFBPIH0IpPwQyeIhequLxFS7oa4qfoiGxmesdIrE
 61Wx.Q74lD5vkJPJJwS1Rj4cC7B_QQkALde94XHiFmpK.pA--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 32995032-351f-4f3d-b1f3-2db34182d857
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 0/6] xen/igd: fixes for Intel IGD passthrough
Date: Fri, 31 Jul 2026 20:17:24 -0400
Message-ID: <20260801001737.16509-1-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
References: <20260801001737.16509-1-brchuckz.ref@aol.com>
Content-Length: 4795
X-purgate-ID: tlsNG-ef75cf/1785543464-A72DCAE4-5A5895D7/0/0
X-purgate-type: clean
X-purgate-size: 4902

Please note that Patch 5 of this series also requires a patch
to hvmloader of Xen for the new support to take effect that
is available here:

https://lore.kernel.org/qemu-devel/20260801000354.16446-1-brchuckz@aol.com/

This patch series aims to fix long-standing bugs that need
to be backported to all currently supported stable versions
in order to support passthrough of both older and modern
Intel IGD devices to Xen HVM guests. Note that previous
versions of this patch series only fixed the bugs
affecting older devices and the patches needed for newer
devices were not included, so this is the first version
of this patch series that is suitable for use and testing
with newer devices that, for example, are designed by the
manufacturer to only work with UEFI firmware.

These patches fix several bugs that cause problems
ranging from a dark screen in the guest until the guest OS
graphics are loaded to an assert failure or other failures
in newer devices that in many cases prevent guest creation
from succeeding or cause other problems such as code 43
errors in Windows guests.

To test the the third patch and verify it fixes the bug of
no video output from Seabios, it is necessary to test
with older Intel IGD devices that have support for legacy
VGA bios (Seabios) because the newer devices, as far as I
can tell, are not compatible with legacy VGA BIOS.

The first three patches have been tested using Xen 4.21 and
Seabios 1.17 on Fedora 44 using an older Intel NUC7i5BNK with
an i5-7260U processor and have been verified to fix the bugs
described in the individual patches. This device is compatible
with legacy VGA BIOS and Seabios.

With the fourth through sixth patches applied, it is possible to
use/test with newer devices since, with those patches applied, the
bugs that prevent guest creation from succeeding with many newer
devices are fixed. All six patches have been tested on both the
older Intel NUC7i5BNK mentioned above and a newer 14th Gen i5-14500
Raptor Lake processor in an ASRock board that, as far as I can
tell, is not compatible with legacy VGA BIOS and Seabios, which
means that, although one can successfully create a guest with
Seabios for the guest with the newer device, there will be no
graphics output from the guest until the guest OS loads the
graphics drivers when using the newer device with Seabios.

The sixth patch is provided for use with newer devices that require
an EFI graphics output protocol (GOP) driver for graphics output
during early boot. For more details, read the commit message and
the accompanying notes in Patch 6.

Two hints to help configuring Xen HVM guests with Intel IGD passthrough:

  - Increase the value of mmio_hole from its default value of
    256 to at least 512 using the mmio_hole setting in the guest
    config. The value of 512 works well when the stolen memory is
    256 MiB. If more stolen memory is used, the mmio_hole may need
    to be increased even more.

  - If there are rdm conflicts, lower the rdm_mem_boundary setting
    in the guest config from its default value of 2048 to a
    value at which all rdm conflicts are resolved. I have discovered
    that lowering it in 128 MiB increments works well. With the older
    device I needed to lower it to 1792 and with the newer one I
    needed to lower it to 1664. See the description of the rdm_mem_boundary
    setting in the xl.cfg(5) man page for more details.

Changes in v2:
  - close open files before setting errp
  - improvements to readability and style
  - small corrections to the commit messages
  - add stable to Cc list

Changes in v3:
  - whitespace fix in first patch
  - fix Cc address for qemu-stable

Changes in v4:
  - add three patches to provide support for newer Intel IGD devices
  - edit the commit messages for better consistency of style
  - use 12 digits instead of 7 when referencing commit hashes
  - re-write xen_pt_get_host_pch_info() in patch 1 using the
    functions declared in xen-host-pci-device.h
  - handle errors in patch 1 that in previous versions of that
    patch were not handled
  - add a Fixes tag to the third patch
  - add two hints in the cover letter to help those who are trying
    to configure Xen HVM guests with an Intel IGD passed through

Chuck Zmudzinski (6):
  xen/igd: get PCH info from host sysfs
  xen/igd: don't register rom bar twice
  xen/igd: fixup device id before registering rom
  xen/igd: enable guest creation when ROM read fails
  xen/igd: implement support for extended VBT
  xen/igd: use custom option ROM if provided

 hw/xen/xen_pt.c          |  13 +-
 hw/xen/xen_pt_graphics.c | 280 +++++++++++++++++++++++++++++++++++++--
 hw/xen/xen_pt_load_rom.c |  64 ++++++---
 include/hw/xen/xen_igd.h |   3 +-
 4 files changed, 325 insertions(+), 35 deletions(-)

-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:17:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:17:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379721.1624156 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQH-0001XR-Hr; Sat, 01 Aug 2026 00:17:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379721.1624156; Sat, 01 Aug 2026 00:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQH-0001XK-EH; Sat, 01 Aug 2026 00:17:53 +0000
Received: by outflank-mailman (input) for mailman id 1379721;
 Sat, 01 Aug 2026 00:17:52 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQF-0000ut-Ts
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQE-00FX1B-Pu
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:50 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3ada-2eae-0a2a0a5409dd-0a2a450bdfc6-30
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:50 +0200
Received: from [98.137.65.31] (helo=sonic315-55.consmr.mail.gq1.yahoo.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b2c-b7e8-0a2a450b0019-6289411f9269-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:50 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:48 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:42 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543468; bh=e+hFrPKjm/qktFvrEGDQAvmP2RXLyh9VDR7iL4Z1uvE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=YTkrELbZWKdR6MlF3on4FPg7soY/Dc92529AE8IAES+R9eHjMSTIQtUmJV53clCHzIxdW1PBg8jCqy/IkNylsIIMjLLgzJhXKYTzoaafStyZThLBKnOc8WILBxLgWjCp/Yqx0e9Fv4xFldUN+8xYuFOfh2zU1bVivDxgPZ5JkLm9Zv/pWJiw9TbHdqja/TFS0frXbaJbCmrYiJjfaw/R5PW+0Dr9aqLa38J3PvIslk6IFXq+f+nn8jR4MuSMj7sk3joDSqxLF9bUfgJjVV1qzCtugdHqfjN4PwxmLwBrEzhB7Wu4sJPL9HaQp+n2gCV29kv/W3J1uBsL8QGI4tSTfg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543468; bh=ND82rFy7/zOVwXsz/RHMs6SkJ7Wu+/qRU6xlDEOWfxF=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=snGXE5kMidyeL6q2BmQQrjYREoQyr3mCUngVDBAvmhtBzHxCg8kFonZhm82Ct97clMwTGmSdSCk+gEAGVsqcPMrctnZnyxtWgQgTKrrFod3gS5vorxHpY2xmQeldjcD2/CqycytY7jYZwnOCM8M7Rmlw3/W88L21/x9WfCVoT27gcHrDAWosXTZ9Ky1TILj3dAjt2/3u8bObwGIOcMfo4OhJUs5p3OrqLR4igQ+c80V7RbM89wZ9wa5mvGCpLLuverQbqMt+N8OYfCh91Jw5DhFnwWirfRNF1WUpVRwKH1/seKW2/2Fzl0A4HhvTVND08QGsWpa421eDO/eNCQYzSg==
X-YMail-OSG: DO9eCQQVM1kM2YtzD1yVaZ6ZUBpRnIAxSCKVSwdHs7_TF8pvf6vHY8nncsOK5c9
 nm7l2gzBy71iJPUHoF1UJEQXM2gAyrmK3.fVq0m19RSPW6i7ghwnotPYWE9oUMdTfqWA5w8sqLwu
 cS0MZD4zMSREe6ZnYmzXk3Z.wDo5bO0UIDHFD49VtrfHEh9m6a2d8DmVKOS2cSDXYC3LZnQa7B60
 OinNH4CJ68t8C9GpxeEMKsIOpdzlAl1wfVQa6elCfo9asebZobxeAtMHu9mjKhJ0g87jEago.KJd
 GliNj2g9WG02NHVie51Den6jKehkK616TYLPxc1qn7GPFw3ekwY81.mP61.UcXGmMT0S2bxOD0q1
 oGYt393F4hvoAlLWT1c4_h1PVxKq97radMKhEP7Eq8er.t3smg118OFQ2dhJGcqf3DyT780oMPsX
 3zYYqI2st3NoCgdBSvzN2BE7Kn9HRpDhdDewAFazL3Bpe3OfiQWIWsXiJINzRsd56KMyEfIUvS29
 cX08sTJrcliVQtPWBaoZAWzrqLl6MD5SqoiaQ6J4CmwRmWfJcNe8VTqiHsbcgfFjKTK5x7oZQOEw
 iULHNJ2UnfxfMVKrQoYl1OIcPKyQK8x11c4zml3WJ4SVHA2KuFCqfjo3ih9fbz8mNO8HJkVQugQ2
 iGztX0lwG_GuBAzZ99awjIIhcRLLddIgVnqec_sv3C2P.JN.kPS6cBl5nQK11q4t9XeWyLrTXVBp
 seO5KajhlyRZjSRzOQO3.Mz_xwbV0KOS2P6eSx1RAtcNSgD7.le8BLSgfGFb3dkP1ncMejQN7_Wi
 G0p_hBfUFLX0.tbduCD6ydK_Bs0bqyth0PLVEL1zPkPoHQzjekPWMHbQr3b0na47Yi70rf8kusla
 FpG9yJ619HS5uClZeIfL1hILR25jfeGDUBbB4F8.PmQmDIF5FqzD.vqDgS6zbnhipPbkAlO_aZPt
 g0YLm1vZDakTnMiADxiqhoq_edlWU19pHzidiHs6HhDKJNIxFefzXrRnPz_8TXvs.wOVSaJILEtV
 fwvZCPlbSLzr8AZKTenQu5eEy1BHjAT205yA0AD_DAbneHqOGUKPuzLHRsNJZkXI_LdC7.StCO7a
 G2XCP1JDcAH9YaYEsavjx_wFpwPVx.88DY9HE4u8kPN48l95p_yVRMRI_lwWZvjvsYgbuUD.kYY9
 vn4F6DNvmEfNKPVqBl0w..usKwaI6tsJgUylmkrGaohSyb23svwN3CtW8elWWsWRGjn_SErqNYWJ
 FmDoWts7FKkoLi7tapxrlY9ULZSftmFlIUQe_dQIi5C79QXHlMixwJRmTsae8_u0txkL5Au31Etj
 w3OBLOqW5KTTEPMhrNgNysVuS6t1wmcNCJpgxhjAYoehEBGWeHamfG96xYNlIfPF6KGO9TntH8oT
 _F3ErcVKpJpvKsAUn8rPNtpYaH25xQwbBXR8fF6tngzdt4woa43H2QzLww_Uejq_IdTYelviiQjE
 YAxn8FHweY53AiVuSAplB1Y3hF_c.hYntBQdeDkxnSt3ZLkdPa7jRz1e457jl4.Cqai4lIBwygfS
 LFV_vOa4ojrJCTt.gLdiCjNyetJgIGIYsGyAY0FtCUOiZYm6KuPrGA2hYx0_8fXCMczZc_aER.jv
 MxLRpzXq_ZSGZGcYa70fA8gyiIPFCdk2PBAprUAWWWjdBNSy8pMBHTjjQc7RjhKdZ.wBJQ7ZQrNy
 6wr9lEG331x_kBpL53uFTLpyZQeHXSuPDw6T6zfa5QOKNDlCLWlH7KQwwa3MPWTPJZdTnYc.eVnm
 pP21mfpuMizuG7gn9bSpkPGT7paL_bvbR9wpnq4ZUrMUOLcqelltsLL47gIkR9aklUNRvQP9QHR8
 3Inud10EKm1qS5AewB1nL7KgR0LPKtnQPV6Wp7lIkUlFrvzDwn4850jA_E3Rp5BMB1aM5ahXlURX
 yoZv1hv1UqKFhqV18f2KLSzP1uFWC1UfzycfhPkNrk6_uq27bBbcE4zrMKrXqeCICMqGFkVdZzOv
 RZiE_Wjwmux3REQgiXSqzwubTOixMLdlhrJgutvA_utRTRed6VZvTY08df0PauK4V4IiSLSmrf7.
 peCrAcEVTPs0TI9pwUfr4rBx0kiD2PVeEf_La2_810yj3yjJ7JV1k1Zr.UoD629GBTWokb7IIIZg
 LJ_qLeyMWKHtUdwM.kIzlX02aKzPpeJBPcBWML9iyo6oLAMBDCsmWGNL2_UUJhRQdHpB.j6fvYpq
 0050.U8NXXacnZfDFs3sVPNZ0QnTYgCPPQVLT7kl9xAMe99VpMQ--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: e5ab0868-b2cf-4cbb-9ca7-34935d8b786d
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 2/6] xen/igd: don't register rom bar twice
Date: Fri, 31 Jul 2026 20:17:26 -0400
Message-ID: <20260801001737.16509-3-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 1267
X-purgate-ID: tlsNG-42698a/1785543470-1BAD09EA-624BBA8F/0/0
X-purgate-type: clean
X-purgate-size: 1305

This also fixes a failed assertion in pci [1] for Qemu
version 10 and higher when passing through an Intel
IGD with an option ROM to the guest.

[1] f6fc01c78666 ("hw/pci: Assert a bar is not registered multiple times")

Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work")
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - Use 12 digits for commit hashes

 hw/xen/xen_pt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c8f08b5..4d159a2 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -459,6 +459,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
 {
     int i = 0;
     XenHostPCIDevice *d = &s->real_device;
+    const pcibus_t romsize = s->dev.io_regions[PCI_ROM_SLOT].size;
 
     /* Register PIO/MMIO BARs */
     for (i = 0; i < PCI_ROM_SLOT; i++) {
@@ -495,7 +496,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
     }
 
     /* Register expansion ROM address */
-    if (d->rom.base_addr && d->rom.size) {
+    if (!romsize && d->rom.base_addr && d->rom.size) {
         uint32_t bar_data = 0;
 
         /* Re-set BAR reported by OS, otherwise ROM can't be read. */
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:17:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:17:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379722.1624165 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQK-0001ob-Pw; Sat, 01 Aug 2026 00:17:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379722.1624165; Sat, 01 Aug 2026 00:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQK-0001oU-Mc; Sat, 01 Aug 2026 00:17:56 +0000
Received: by outflank-mailman (input) for mailman id 1379722;
 Sat, 01 Aug 2026 00:17:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQJ-0001mv-Oj
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQJ-00AjYh-5k
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3ac2-5cb7-0a2a0a5109dd-0a2a4508975c-34
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:55 +0200
Received: from [98.137.65.31] (helo=sonic315-55.consmr.mail.gq1.yahoo.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b31-f659-0a2a45080019-6289411f9b38-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:54 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:53 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:48 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543473; bh=ffO8qrCy0LABWluXubgddMD+88wzPHM657OWh8V4ys8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=jBEsPlsKDZ9k3OFUK2pNIuuFEyLSfjnjdOdeflcM4v+Iuc+0ClVkgXoYY/svRgtXdwNMMOj5MxOZzCh8OmgbY05QVK7S0EQVGjXbA/z0TYifQ6HcBjHU7kgvrYZlcXXUgcasTrSMBef8IPLNQJzA1c3dZrOwwfT1GUOxrxpIcdH68v/rVwh3X5dg2DoRJ0B5ELph6O7Xw/uWzQnlZhJCUP57DHZOhKlwU2ZBnNVw54WnfS/rG6B0KSefzZ1+LQpi19a8OptFY2UaizDVK2r97xYvtolsNxAvwQSgzXcTksXj6WSi89UqeAOw+Je11P3+Sn5RlyEgAWTRoMOXhhcYAA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543473; bh=kuDA4OeFX9PVEeDeut7LzAaV7cmzKLjJEjtDq8yrl7C=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=ah8qZSRF+83WizDbIeD1p/nOf1ufgUYy9ODrru1BhoHk1bID+XlbapZJlK3nbaEjkGYa2JYpJIwmpq9KS64VbJ/kRqruWPxXwU4P+SEaNXeBgQ+4ujW25yJyAZo2Las9zn+Gv7l9naY5dgBtpGhC45RjRiQcyEeASAkrn0bBPySmU4VARCFcruGUBwELyWmhgZkAcp9Bm0ms3qFO5tGQWGildXOTgCOnvgNsSA0rRYoFR8t86XxCI5elBvaGeb4Q1ccTAbd9eMk6gWXZoQQwvYUTx4udbL6DgKjwCX6WbogjCfnmMo79/UF67QimBgljSOZVEJuypPLTvnrpRK9oCQ==
X-YMail-OSG: .NpycOsVM1n53CI.4.B7xsmBIgwyCi_2EPd5rWydy.y4Jx4SOCYE2eEJ5PUQZ3k
 yPsyl_7JvTWTXRpTdq4LYYGUNXjMQfAv4eKdwrpnKtHYCo9PNJntOrIFdkkgXGsJtYUHf_EFo4Wg
 t6_b.9REPKN9Hm8ov46q5b584SuQyo8V38u.VHTBAZ3sNd6Lsv32a2e_N9gmiap71hcSlLyPZRVD
 LdR5O6wdUt8cYkVbHcwLOO2ql6UXi0E3ecZ_4VPh1IS708crJmcrx3_4H9Zqx0Er5q6ypDOdoy6a
 aB4De4X7.PzHhxyLJwAB4D1oDsZkpppMk34TXVQXj7XsD0NZSQSTBAg7fdHAVMHMUYiWTtD1aay1
 _Z.Inm.TPl60eZ5wWeiIgkUtHe666jIny9S0LE6yB0X35ItXpNdJtbopxSh3wOp8Hzlw32vbrOCi
 Gr0O6QCHO4oEVKigOtlnOPuGYPuKAyYT9VQgZl3qzPcZBQFzpqdNXrx_8Uuy00TwSaav9RDQCG6N
 48m6jAN8aO2lzlYf6Nh62C9N3WeR78QfkOEuNFGEkIeHAn3hi3Sm2Q100c0.tm11pVQZ09c7UB40
 _YTZ5r2xqzelhc9iuNUXCQYCJWdSWQgrK4.SODSIRj5eeeW5jB9R2MC7CuVuEHRGp0BUqC1MFKgc
 eBULYVninRRrVEfHDzm8hU7TBPWoYB4ymiaW6RTPBegJpUH_nTvnNFrII2hi8ueffnmYmNzdivVU
 qA4TyibE0TGsUrDZImr6iGUwDqLFXuZHHdllEadGvzviJ2TDKgzhRy.L9UFzfXa65caBkZ6C6OfS
 lWtNV0ffqmVniZm8X3kh7JrZaenOVtYzE0u9SI8NZJd9QNFLiO3Fvw1OLXaV1RSc8tGcuDb4R.AH
 nfmmyIuUyMiTzUmHPhn4s3ila.2ot0DURu264JPjWLml2UL6p2XBJ1RvgHeTPErCiX8._cMVQHfb
 MBQQljgrx1dSJHxiMwqQWaC.8QKbUm1lYSm7Vh50bACkhzRiN.JOCaM5PhLxhKjjJ4Ovgbk.mJUu
 PtyobS.4uknqGkrFWSuQakYOtqcMxw2oxYaM5bp5auSwk7ExnLjSfB_RYp2CxeK3wQwlDKWYXfLT
 v8iiCd67R2vGvmu.f166JZqfHc3H4OE9Ua8yfmchOC8liPHIPBC6BrunMUh59oRphcDWfuKk4CLS
 ZONTkXuq.XcUoxVEj2TpZT.3WMvu2Sg3S2qfAs4U6oPkuZRK0UQL5KzsTPd99c8mgbLlBAp0K80E
 0k.LoaSq_sAvOXmBg.XNgRlKL2eVIih2lLaduFxuSnGrH9mLF5yRWqP21gIkZIS_JMQkln1E91aa
 nO8J6qUi5B3ZttmOcfniCcGld1Liwpjv6UZpeDNRBMg5IMM.iCZGGEEdr2w8pWtcALGTPo_goGEy
 UzIPXclVB3DRKqykBe0uJ6IEJauEGYpXj2CRww33kMFdSDvwriLv_iTZviDcHNTmyUyKJyDNUaQW
 X0OUJtLngRa04ZxAv4hQdTFqptK2TC2AAT9YKvPFFQATKbrgkY7QQq.EAGLnNazUJ.m37uk75DNY
 Gox2hTs2DiaD2RoDYYF1KmNUuKfu39Wy6oD_.rFp6lqXzx.n0QA.x6pVw7.CzirBwsjzYx2x4fxK
 TzPnMTcgZ2MqCJsGY.uqXi1RiuGuaqR53dglmzCnPKUM9KLkGBSHGWN9tKzcYAP3BaqDXffHMTIl
 RLxHrI9OJ3f1OYSYXPf2qIHEZIwPAFkikqhQRJNu04VvZV4PHdnFT2KA6gmRe4YApZbqP1w2TQAJ
 oOotujPdAIY4S.Mu6v6ojACnWD1o4iSlt.ATJkQMZm9pED4Vqm.SoZs4c_sWNhDckPfHJi8ZdR_K
 7KowPOpIlyz.vCu49qlDW6PWXl2iZkgsQQVprcFk03OgBldqz9EG6sc3btedLB2opDobiBH4aDx_
 gbWOOCXYEr9MmkbU9KZ60_5tuVxx7y79oR3Kua6giOCegMdtbd9YYLOuRFkg.UStCnnlyuSZgcZy
 vvIakHp9bk7rndw7SC9Y44sI.2HibJATn1Je6GSJfE5BEUSVmNtWsyqV83rqBcBPm9Dzj2oEkpdh
 _7E_mFC4M0xtu7U01UdOSHT0Dj5aqXBzK8N3KeQUD7ORBN3HptKdarioYdt5grFMFdfHdcfsm.o_
 uFz9HFDHN0X8bbi8t4wUYXn0GzUbbROQZgCUYerUBa6dzOQWPh3UA9dTyc8ksssz_h20Fpa_ZIzd
 lEwaKmNTiKXf.GliX5Y4OCHMCKabx_u3I482.U2XSexQKndZxRw--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 8c31a32f-648a-4935-9991-1504277b6dc1
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 5/6] xen/igd: implement support for extended VBT
Date: Fri, 31 Jul 2026 20:17:29 -0400
Message-ID: <20260801001737.16509-6-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 14630
X-purgate-ID: tlsNG-c1860d/1785543475-D457487B-AEE13D86/0/0
X-purgate-type: clean
X-purgate-size: 14963

Newer devices with versions of the OpRegion >= 2 require an
extended bios table (VBT) in some cases and also in some cases
require modifications to the OpRegion for proper operation in
the guest. This is in contrast to legacy devices in which the
VBT is always embedded within the OpRegion.

This makes the current approach of providing only the unmodified
host OpRegion to the guest with no guest access to the VBT
insufficient for proper support of devices with OpRegion version
2 or higher and an extended VBT.

Support for extended VBT also depends on compatible support in
hvmloader. If such support is lacking in hvmloader, fall back to
the current protocol that does not provide support for extended VBT.

To implement support for extended VBT:

Instead of configuring the guest with access to the unmodified
host OpRegion via hypervisor mapping of the OpRegion from
the host to the guest, temporarily map the host OpRegion and
VBT into the guest, allowing the guest (hvmloader) to get copies
of the host OpRegion and VBT which hvmloader can modify as needed
to support cases that require modifications to the OpRegion.

In xen_pt_unregister_vga_regions(), do not try to unmap the OpRegion
in cases when the OpRegion is not mapped during normal operation of
the guest, and replace the constant '3' with the macro
XEN_PCI_INTEL_OPREGION_PAGES which is defined to be 3.
To implement this:

Use 'done = true' to end further processing when the OpRegion does
not need to be unmapped in xen_pt_unregister_vga_regions(), and use
'guest_supports_opregion2 = false' to end further processing when the
OpRegion does need to be unmapped in xen_pt_unregister_vga_regions().

The OpRegion 2+ support that can be provided by this patch and a
compatible patch to hvmloader is required to fix code 43 errors in
Windows guests that have an Intel IGD with extended VBT passed
through to the guest.

Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - v4 is the first version of the series that has this patch

The companion patch to hvmloader that is needed to make this patch take
effect is available here:

https://lore.kernel.org/qemu-devel/20260801000354.16446-1-brchuckz@aol.com/

 hw/xen/xen_pt_graphics.c | 231 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 223 insertions(+), 8 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index a124233..3d2a94c 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -12,7 +12,26 @@
 static unsigned long igd_guest_opregion;
 static unsigned long igd_host_opregion;
 
+/*
+ * These are true until they are set to false when the guest first
+ * accesses the OpRegion address register for a read or write,
+ * respectively.
+ */
+static bool first_guest_opregion_read = true;
+static bool first_guest_opregion_write = true;
+
+static uint32_t guest_opregion_extra_writes;
+static bool guest_supports_opregion2 = false;
+static bool done = false;
+static unsigned long rvda; /* absolute host VBT address */
+static unsigned long vbt_guest_pgbase;
+static uint32_t vbt_nr_pages;
+
 #define XEN_PCI_INTEL_OPREGION_MASK 0xfff
+#define XEN_PCI_INTEL_OPREGION_PAGES 0x3
+#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
+#define XEN_PCI_INTEL_OPREGION_DISABLE_ACCESS 0x0
+#define XEN_PCI_INTEL_OPREGION2_SUPPORT_MASK 0x1
 
 typedef struct VGARegion {
     int type;           /* Memory or port I/O */
@@ -117,11 +136,11 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
         }
     }
 
-    if (igd_guest_opregion) {
+    if (!guest_supports_opregion2 && igd_guest_opregion) {
         ret = xc_domain_memory_mapping(xen_xc, xen_domid,
                 (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
                 (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
-                3,
+                XEN_PCI_INTEL_OPREGION_PAGES,
                 DPCI_REMOVE_MAPPING);
         if (ret) {
             return ret;
@@ -239,7 +258,30 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
 
 uint32_t igd_read_opregion(XenPCIPassthroughState *s)
 {
+    if (!igd_host_opregion)
+        /* We just work with LE. */
+        xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
+                               (uint8_t *)&igd_host_opregion, 4);
+
+    /*
+     * By returning igd_host_opregion here instead of 0, we can
+     * indicate to hvmloader that we support OpRegion 2.
+     *
+     * The conditions are there to prevent returning igd_host_opregion
+     * to guests that have a version of hvmloader that lacks support
+     * for OpRegion 2. We do this to maintain backward compatibility for
+     * guests with earlier versions of hvmloader that always expect us
+     * to return 0 instead of igd_host_opregion when igd_guest_opregion
+     * is not yet set to a non-zero value.
+     */
+    if (first_guest_opregion_read && !igd_guest_opregion &&
+        first_guest_opregion_write) {
+        first_guest_opregion_read = false;
+        return igd_host_opregion;
+    }
+
     uint32_t val = 0;
+    first_guest_opregion_read = false;
 
     if (!igd_guest_opregion) {
         return val;
@@ -251,21 +293,194 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s)
     return val;
 }
 
-#define XEN_PCI_INTEL_OPREGION_PAGES 0x3
-#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
 void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
 {
     int ret;
 
-    if (igd_guest_opregion) {
+    /* hvmloader with OpRegion 2 support uses lsb of val to indicate support */
+    if ((val & XEN_PCI_INTEL_OPREGION2_SUPPORT_MASK) &&
+        first_guest_opregion_write) {
+        guest_supports_opregion2 = true;
+    } else if (first_guest_opregion_write) {
+        XEN_PT_LOG(&s->dev, "hvmloader lacks extended VBT support, "
+                   "continuing with legacy support only\n");
+    }
+
+    if ((!guest_supports_opregion2 && igd_guest_opregion) || done) {
         XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
                    val);
         return;
     }
 
-    /* We just work with LE. */
-    xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
-            (uint8_t *)&igd_host_opregion, 4);
+    if (guest_supports_opregion2 && !first_guest_opregion_write) {
+        /*
+         * OpRegion 2 is supported and we are processing
+         * additional writes that the legacy protocol ignores.
+         *
+         * We should always return from this if block to prevent
+         * executing code below which is only for the first write
+         * when we map the host OpRegion into the guest.
+         */
+        guest_opregion_extra_writes++;
+        switch (guest_opregion_extra_writes) {
+        case 1:
+            /*
+             * Hvmloader expects us to store the value as the least
+             * significant DWORD of rvda.
+             */
+            rvda = (unsigned long)val;
+            break;
+        case 2:
+            /*
+             * Hvmloader expects us to store the value as the most
+             * significant DWORD of rvda and unmap the OpRegion if
+             * rvda is not equal to zero.
+             *
+             * If the unmapping fails, hvmloader will fall back to the
+             * behavior of older versions which simply map the OpRegion
+             * from the host to the guest without trying to configure
+             * the guest with OpRegion 2 with extended VBT support.
+             */
+            rvda |= (unsigned long)(val) << 32;
+            if (rvda) {
+                ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                               (unsigned long)
+                                               (igd_guest_opregion >> XC_PAGE_SHIFT),
+                                               (unsigned long)
+                                               (igd_host_opregion >> XC_PAGE_SHIFT),
+                                               XEN_PCI_INTEL_OPREGION_PAGES,
+                                               DPCI_REMOVE_MAPPING);
+                if (ret) {
+                    XEN_PT_ERR(&s->dev, "[%d]:Can't unmap IGD host opregion:0x%lx"
+                               " from guest opregion:0x%lx.\n", ret,
+                               (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                               (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
+                    rvda = 0;
+                    guest_supports_opregion2 = false;
+                }
+                ret = xc_domain_iomem_permission(xen_xc, xen_domid,
+                                                 (unsigned long)
+                                                 (igd_host_opregion >> XC_PAGE_SHIFT),
+                                                 XEN_PCI_INTEL_OPREGION_PAGES,
+                                                 XEN_PCI_INTEL_OPREGION_DISABLE_ACCESS);
+                if (ret) {
+                    XEN_PT_WARN(&s->dev, "[%d]:Can't disable access to IGD host"
+                                " OpRegion: 0x%x.\n", ret,
+                                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT));
+                }
+            } else {
+                guest_supports_opregion2 = false;
+            }
+            break;
+        case 3:
+            /*
+             * Hvmloader expects us to store the value as the address
+             * to map the VBT to in the guest and to map the VBT at the
+             * provided address in the guest. Hvmloader encodes the number
+             * of pages to map in the least significant 12 bits of the
+             * provided address.
+             *
+             * If VBT verification fails, hvmloader can't determine if the
+             * VBT is mapped but corrupted or unmapped, so it crashes the
+             * guest as an unrecoverable error.
+             */
+
+            /* address (gfn) to map VBT to in the guest */
+            vbt_guest_pgbase = val >> XC_PAGE_SHIFT;
+            vbt_nr_pages = val & XEN_PCI_INTEL_OPREGION_MASK;
+            ret = xc_domain_iomem_permission(xen_xc, xen_domid,
+                                             (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                             vbt_nr_pages,
+                                             XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "[%d]:Can't enable access to IGD host VBT:"
+                           " 0x%lx.\n", ret,
+                           (unsigned long)(rvda >> XC_PAGE_SHIFT)),
+                rvda = 0;
+                vbt_guest_pgbase = 0;
+                vbt_nr_pages = 0;
+                done = true;
+                break;
+            }
+            ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                           (unsigned long)vbt_guest_pgbase,
+                                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                           vbt_nr_pages, DPCI_ADD_MAPPING);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host VBT:0x%lx to"
+                           " guest VBT:0x%lx.\n", ret,
+                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                           (unsigned long)vbt_guest_pgbase);
+                rvda = 0;
+                vbt_guest_pgbase = 0;
+                vbt_nr_pages = 0;
+                done = true;
+                break;
+            }
+            XEN_PT_LOG(&s->dev, "Map VBT: 0x%lx -> 0x%lx\n",
+                       (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                       (unsigned long)vbt_guest_pgbase);
+            XEN_PT_LOG(&s->dev, "VBT host address: 0x%lx\n", rvda);
+            break;
+        case 4:
+            /*
+             * Hvmloader expects us to store the given value as the
+             * final value for the register that stores the OpRegion
+             * address in the guest. We also unmap the VBT since the
+             * guest now has its own copy of both it and the OpRegion.
+             *
+             * If the unmapping fails the VBT will be mapped where
+             * hvmloader needs to place the OpRegion plus VBT in the
+             * guest E820 map. In this case, hvmloader will crash with
+             * BUG() rather than try to use the mapped VBT with the
+             * guest's copy of the OpRegion.
+             */
+            igd_guest_opregion = val;
+            ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                           (unsigned long)vbt_guest_pgbase,
+                                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                           vbt_nr_pages, DPCI_REMOVE_MAPPING);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "[%d]:Can't unmap IGD host VBT:0x%lx from"
+                           " guest VBT:0x%lx.\n", ret,
+                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                           (unsigned long)vbt_guest_pgbase);
+                rvda = 0;
+                done = true;
+                break;
+            }
+
+            ret = xc_domain_iomem_permission(xen_xc, xen_domid,
+                                             (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                             vbt_nr_pages,
+                                             XEN_PCI_INTEL_OPREGION_DISABLE_ACCESS);
+            if (ret) {
+                XEN_PT_WARN(&s->dev, "[%d]:Can't disable access to IGD host"
+                            " VBT: 0x%x.\n", ret,
+                            (unsigned long)(rvda >> XC_PAGE_SHIFT));
+            }
+
+            done = true;
+            break;
+        default:
+            break;
+        }
+        return;
+    }
+
+    /*
+     * This code handles the first write to the register from the guest.
+     * It maps the host OpRegion into the guest.
+     *
+     * Set first_guest_opregion_write to false to enable more writes
+     * if OpRegion 2 is supported.
+     */
+    first_guest_opregion_write = false;
+
+    if (!igd_host_opregion)
+        /* We just work with LE. */
+        xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
+                               (uint8_t *)&igd_host_opregion, 4);
     igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
                             | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK);
 
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:17:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:17:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379723.1624170 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQL-0001rl-3t; Sat, 01 Aug 2026 00:17:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379723.1624170; Sat, 01 Aug 2026 00:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQK-0001rK-Ts; Sat, 01 Aug 2026 00:17:56 +0000
Received: by outflank-mailman (input) for mailman id 1379723;
 Sat, 01 Aug 2026 00:17:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQJ-0001n2-St
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQJ-00AjYh-9m
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:55 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b2e-5cb7-0a2a0a5109dd-0a2a4504e2b2-2
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:54 +0200
Received: from [98.137.65.83] (helo=sonic313-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b31-b57f-0a2a45040019-628941538f8a-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:54 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:52 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543472; bh=em0LfYUuUVS4dEN9yvrJ5cV2XhQB99q5Rt9+dzqOtV8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=doRUbXE9lp7Rw1ayMqIEmMaOq61ZZ18P651yd9qLvqvHwwgEheT9s29kPcvdAeSzqcBy6E8q64wx5G5tndqx9taq34l+lIRQwVh6qnZDj/lM4u9Ld0DtB4WOY/ECilS30+DLMbC7kWpPRX5oWH+pkwTiG6QxiZU4kJz/0S4nCa44WZ0GwmuXqUGIsboRXuSc02t1bkqmzaTrhVa6l5rS5560B6VgTwIlYLZy7F+jPmBT3AAZ9Xo+loKmx/aYQG4/yzHHiFt8scqNqhVbCTB9ag3jA98bEEZHFwTqpem7kSeb15QrFszZ3jhRCyT10JkxnR6DkHxC5pNSdORxBPOkwg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543472; bh=yestQipyg8w6O7Lx6tHhvERxFQ0+EPj6fbFiGqFivaC=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=DTmMbpPHouEZffyYD8i9ETwRQGkBBS3lYG+EYg4WLNsBbUmCKx7dDieFyKWDTVTv2ZQr7+BovBgUXBxANgLu6pCmhha7XO38MurgyOGerYQbngzK9BVo8dhW37UX4pRfnKeYcWww8c5YNZGzk3hctyE3ffiDS5DLKUYkt+VbuY22X3yAJ6bn6DAOo1vVE1Q5Bax+QzIuGHNCalgMdNHMyiwe4L1OkOEZ6NY5JeXS/5MDXQnCOhen6UwzcwQKoI2/abeGb3iU2EEGH0+iAgq2pf+ixr13WwMdPP8jJ53daEMJalERFLwhm3ftGOGlLWb5Ccgud9ccq/ObmL6UmyJ4Dg==
X-YMail-OSG: ZBJJFDUVM1lYaflSIDnAPpefQzBjC4MCmcdUwDWYRCTlsqVtBUN8I3KXRUt7uwI
 _o4JXcUdynTxGYpD0TiJttBaPsU_GzIRhTB1wLEe2QaVIxdAu9l9STMG2Z1IJ3TSDlROqk7kwN16
 JtKWp68X16juyC.0rrf1wsK8xzlRAgE_hCR_TQUTVY8pv_Efo4B6HRuv6kHabfUBbH8k3204IAHL
 Cj3oK2qEcz8FiooQeLJWzHtVS8l.anoCfh5ln6uKgp01GArbjTRSJzoQJJTUpNPVSB_wwpC3le_g
 eQ1GKRYu_uDTT5k_XSICpSVlF3I5a6u9q3BZSiRZgKk_.MTmpFj0GTPhAxcflKfrK3WiToTmHCzX
 B9bvu3HZYjMmAiigmEj2GADLKskO2NRxO5TWYMJiWgHpwX8URruzNCuMulKfqWYG.sK7tt4dg1JT
 fUDhQhoQ6Dvk.HRKKyzjSvY_ZiNtMX1B94oueWt9PK.hKcmXsxxx3a54LH_tDpiEXLhUIvNB7hQN
 8eypeFZDIzUk1ChUmNWKp69KNNaHOf7dnB21Nmocr8vq855JFf.qoZ7pwQhtIu1kArw4Wl39eiIq
 rU.YIsEOfUkX_FbqMy2Ms_FGXMrtea122Z4Nz31bXsWE7.uObJ9WfBYUQHMcbB5.fwLulmeN5aPL
 KC_3HWLYLIw3AkjB5v8WHiOwCG4vzPm4GGV3xb8WCTVsmqVdVh2tXs8P.RKrjdSTIyfEQ6iHqxvU
 RlDmAabVweD5RlyfudSK7Az7ScWSTQKyytzQknB0bEeZLo2lYVTFNO9s5Weqxzbxz.8moPuS8.GP
 nbWqfYo0f1cSAkFRFPEL7rQf61B.kblH.6emi0IABxaxgpLzY4zeWmHU6WS8ZzJuie2LI83U1g25
 HUpa68WQC1XKpFm4wJDkb8ZHYB1b.S7AdrJkmHBRqdyq4nyi60KnLYSsJvIFgTqZv9aE6kpa.HCG
 n8l0wX8m5Prsg6Ft6UARtQKwUSjUM7gl0X0qEhFxAbkWdsmNc9NQQSSOfF83FQytVvRf7xlj5WPm
 G_sMbnLvkec7xseQ3w_fx97BbAkjgUgB06BqdvJpnUevZjiKA3AsXJb.bC0ehYnIAUCJccp9JIVX
 fESuncfIaoqdox8NDaGuoN9JlAzaVPXyMzAf4zT2TEDOahj6nthRmV2sNU_gdywJOiBprSxtF93N
 PDkSpcfb71ejOuzoIsypf7j..31h48pv1yvIIRfXgxEm_uSgWUDK4q2Vtniav7jwzgBayXvVSzAE
 5FwBEJCbrXNso2uWlpzeqWKhM.xU83jX6d98QXQI2bXjzpxx7V3CbjOazm2BdHDus9nONyLikHQA
 _e.7ZP8QMdssc0y4PoPNQPrzvLw8pHtNqtupbjCRNd9aTw7l9oENEAa2cvKa93T8YCAt9AgGiF17
 31Qu8vRvkrE2wOsenoJWGaCfcgVGyGDM._HoxaE47A8QJurAImSBcpVzy_XaLBBjOF3z5TQwvBW0
 a6vLYSvD3jVk9M5D.GsThs3R3_Cxe2Wa4dqPUd4_3NxiArQi8apD7PZWd1MtxflBbd8vTLokKbYT
 LfM0EBzVcMEVh8hAMd88I0qF3VOGFmerdA6aAJlDX2zHtQK7jCknrgKxbnYkVoZf_mxyBUsmF9gf
 bVU7kyspB3vjjAggfIw6Uwrdx2zuWnWcwz7ro3PHV7lxO4kbF.UQ8lp3jyZ9kCUJrPN2DigiZxMO
 CM5XKGIehm2d6nPi8anaRc1lqvWNoHkL64PXXLJU8WKriO3VITE13CmsywIT6aoBiz_jQS1cZGAs
 eETHs997pF_RXMPNkHh73JYq749g7v_EZsskKlZhSbXYYBwzNyUyDQCNwenpSZcEdkXMnLKMKA8h
 IVn_lFBSvaGXEeSJXinIrBetw7PGjXfCvKn_fBC4ZWyOmnn5N.2fuH4PlttdNkzA89Ua6DQvfSOq
 WRD1q35q3kM7bjPqG3DxAt8_hGdflXBG8Mi7YeTjij14kzr7czxyCgjMc9mOkguEJ2Y4QVwJlDWG
 12uXZAR_0EMafDOYNTy.X.iWDC.mJD0jYcISkAHk12zPIXmBNF92n.91OsI_XnBW9CQoLcBiqSRO
 Hr92UI4itq08LYLbjah0vdv6v3zYndoXg1jMClUmCQM6Qef9RqnmXPLmXLiiHmNgkx5agREnPAPR
 pFmM4XOO4Ms0jS9U0uoR4qSJK3geka0zvQXsTocst6puucZLXoyWYBezv63Q.Ovu6Cgu8No2hTsj
 dqrp5z65dUz6QAisb5jkubRhabtev1kG2Bxun.bAAfP3vR75XZw--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 66360c73-547b-4fd8-8909-7c15d88570af
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 6/6] xen/igd: use custom option ROM if provided
Date: Fri, 31 Jul 2026 20:17:30 -0400
Message-ID: <20260801001737.16509-7-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 8793
X-purgate-ID: tlsNG-ebf023/1785543474-C24CBB50-C52C0853/0/0
X-purgate-type: clean
X-purgate-size: 9003

Since in some cases the option ROM is not readable from sysfs
on the host, provide the option to use a custom option ROM file
instead that, for example, could be extracted from BIOS or UEFI
firmware and modified as needed for use with a particular Intel
IGD device.

The file must be named "igd.rom" and be located in a directory
configured at build time as a Qemu firmware directory and its
size should be a power of two, and it must be compatible with
the particular Intel IGD device being passed through.

If provided, the "igd.rom" file will be used as the option ROM
instead of the option ROM file epxosed in the host sysfs.

If no "igd.rom" file is provided, this patch has no effect.

Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - v4 is the first version of the series that has this patch

Sorry for the length of these notes but there are many things
to say about this patch that are not obvious to persons without
some experience of actually trying to use the option ROM of an
Intel IGD when it is passed through to a Xen HVM guest.

This patch is primarily for providing a way to add Intel IGD
support for the OvmfXen platform to get graphics output during
early boot from modern Intel IGD devices that are only compatible
with UEFI for graphics output during early boot.

Note this patch is not necessary for successful operation of the
Intel IGD in the guest once the guest OS drivers have loaded. It
is only needed as part of the patchset necessary to provide
graphics output from the Intel IGD in the guest during early
boot when using newer devices that are only compatible with UEFI
for graphics output during early boot. Most older devices that are
compatible with legacy VGA BIOS will work with Seabios without
this patch, but they will need Patch 3 of this patchset to work
with Seabios.

Some notes on adding Intel IGD support for the OvmfXen platform:

It is necessary to provide an EFI graphics output protocol (GOP)
driver to the guest to get output from the Intel IGD before the
guest OS loads the graphics drivers when the guest uses UEFI.
This GOP driver is essentially the replacement of the VBIOS
driver that applied to older devices that use legacy bios, as
described here:

https://www.intel.com/content/www/us/en/support/articles/000005749/graphics.html

Unfortunately, with modern Intel IGD devices, the EFI GOP driver
is not provided to the guest in the usual way of providing firmware
for a PCI device in the option ROM of the real PCI device. So I
included this patch in this patchset to provide a way to expose
the EFI GOP driver to the guest. I was able to extract the
GOP driver for my device using the UEFI bios update file from
the motherboard manufacturer and the UEFITool available here:

https://github.com/longsoft/uefitool

That EFI driver can be wrapped into an option ROM using the
EfiRom bin wrapper that is part of the edk2 project:

https://github.com/tianocore/edk2/blob/master/BaseTools/BinWrappers/PosixLike/EfiRom

I tried setting the 'romfile' member of the PCIDevice struct that
is used by KVM/VFIO Qemu devices and emulated Qemu PCI devices, but
that did not work with Xen PCI passthrough devices. Neither Seabios
nor the OvmfXen platform could detect the option ROM in the guest
with that method of exposing an option ROM to the guest. So I
implemented this approach of substituting the 'rom' file exposed by
sysfs with an administrator-provided file instead of using 'romfile'.

In the commit message I mentioned the size of the rom file "should"
be a power of two. I mentioned this because the code in pci.c that
handles the 'romfile' setting for PCI devices enforces this
requirement strictly on the romfile that Qemu emulated or VFIO
devices use. However, I do not know for sure whether or not the rom 
file is strictly required to have a size of a power of two, so that
is why I say it should be a power of two. In my testing, I zero pad
the "igd.rom" file so it has a size of a power of two. I will accept
the suggestions of experts on this question about the appropriate size
of the option ROM file (I am not such an expert!).

As mentioned in the message accompanying Patch 4 of this patchset,
the official edk2 project does not provide support for the Intel
IGD, but some OVMF patches for Intel IGD support are available
online for KVM/VFIO guests, such as at the links below (they apply
to the OvmfPkgX64 platform):

https://github.com/cmd2001/build-edk2-gvtd
https://eci.intel.com/docs/3.3/components/kvm-hypervisor.html#build-ovmf-fd-for-kvm
https://github.com/LongQT-sea/intel-igpu-passthru

With such patches it is reported that the passed through Intel
IGD device lights up the display during early boot from OVMF
and the guest bootloader in KVM/VFIO guests provided that the
administrator provides the correct ROM file via the 'romfile'
setting for the passed thorugh Intel iGD device and applies
appropriate patches to the OvmfPkgX64 platform.

It should also be possible to add Intel IGD support for the OvmfXen
platform also but I have not seen any such patches online for OvmfXen
and if anyone knows of such patches online I would be interested to
be informed about them. I am also working on my own patches to
add Intel IGD support to the OvmfXen platform, in private for now.
If anyone is interested, I can make the work I have done so far
toward this goal avalable online.

 hw/xen/xen_pt_load_rom.c | 47 +++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index eaf0ae1..6c2aa8f 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -2,6 +2,7 @@
  * This is splited from hw/i386/kvm/pci-assign.c
  */
 #include "qemu/osdep.h"
+#include "qemu/datadir.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "hw/pci/pci.h"
@@ -13,9 +14,9 @@
  * need to be modified.
  *
  * For such cases, use this function to get a pointer to the option ROM
- * from sysfs. Caller has the responsibility to edit the option ROM as
- * needed, call pci_register_bar to register the modified option ROM,
- * and set has_rom to true for the PCI device.
+ * from a user provided romfile or sysfs. Caller has the responsibility
+ * to edit the option ROM as needed, call pci_register_bar to register
+ * the modified option ROM, and set has_rom to true for the PCI device.
  *
  * This function must be called before xen_pt_register_regions is called
  * because if xen_pt_register_regions is called first, it will register
@@ -32,17 +33,27 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     struct stat st;
     void *ptr = NULL;
     Object *owner = OBJECT(dev);
+    g_autofree const char *fname = g_strdup("igd.rom");
+    g_autofree const char *path = qemu_find_file(QEMU_FILE_TYPE_BIOS, fname);
+    bool sysfs = false;
 
     /* If loading ROM from file, pci handles it */
     if (dev->romfile || !dev->rom_bar) {
         return NULL;
     }
 
-    snprintf(rom_file, sizeof(rom_file),
-             "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
-             domain, bus, slot, function);
+    if (path) {
+        snprintf(rom_file, sizeof(rom_file), "%s", path);
+        XEN_PT_LOG(dev, "Using Intel IGD romfile %s "
+                   "(administratior provided)\n", path);
+    } else {
+        snprintf(rom_file, sizeof(rom_file),
+                 "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
+                 domain, bus, slot, function);
+        sysfs = true;
+        XEN_PT_LOG(dev, "Using Intel IGD romfile from host sysfs\n");
+    }
 
-    /* Write "1" to the ROM file to enable it */
     fp = fopen(rom_file, "r+");
     if (fp == NULL) {
         if (errno != ENOENT) {
@@ -55,10 +66,14 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
         goto close_rom;
     }
 
-    val = 1;
-    if (fwrite(&val, 1, 1, fp) != 1) {
-        goto close_rom;
+    /* Write "1" to the ROM file to enable it if using ROM from sysfs */
+    if (sysfs) {
+       val = 1;
+       if (fwrite(&val, 1, 1, fp) != 1) {
+           goto close_rom;
+       }
     }
+
     fseek(fp, 0, SEEK_SET);
 
     if (dev->romsize != UINT_MAX) {
@@ -83,11 +98,13 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
 
     *size = st.st_size;
 close_rom:
-    /* Write "0" to disable ROM */
-    fseek(fp, 0, SEEK_SET);
-    val = 0;
-    if (!fwrite(&val, 1, 1, fp)) {
-        XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
+    /* Write "0" to disable ROM if using ROM from sysfs */
+    if (sysfs) {
+        fseek(fp, 0, SEEK_SET);
+        val = 0;
+        if (!fwrite(&val, 1, 1, fp)) {
+            XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
+        }
     }
     fclose(fp);
 
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 00:18:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 00:18:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379725.1624183 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQO-0002Mw-F4; Sat, 01 Aug 2026 00:18:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379725.1624183; Sat, 01 Aug 2026 00:18:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpxQO-0002Mm-9x; Sat, 01 Aug 2026 00:18:00 +0000
Received: by outflank-mailman (input) for mailman id 1379725;
 Sat, 01 Aug 2026 00:17:58 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wpxQM-0002CL-6m
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 00:17:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpxQL-00FX1B-K0
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:57 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3a86-2eae-0a2a0a5409dd-0a2a450cce78-44
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:54 +0200
Received: from [98.137.64.206] (helo=sonic303-25.consmr.mail.gq1.yahoo.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6d3b30-f479-0a2a450c0019-628940ceb171-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 02:17:53 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 00:17:52 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 655a093bcead2c5289eeab02aa189b76; 
 Sat, 01 Aug 2026 00:17:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785543472; bh=dt4PNu6AZ8WmochcJSUTO58mxubi+byKBAAny8f1ZfI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=N9WwHxoB+cf3cO+Co06Yt+h8kaZi09MEcr8dsgrkRZjvSYks/E2U/RUsfSCMDCJ5EbQq8bFpRiSj4z8sM2XsEk7e/+RNQINe24YUDWi2aVVHHbCBz95r387g4xUXOW9Vlod5CgXmMmAAmzIgA96GbeEozdnNmXgfFrzINvsyQg5Y1bHhWxPhOTLXynFGFOZPcAFBSK6GhQrCzg1T/2kNDLCeAVfhr1Qpg3zGO7PPnXf6SYD+v972nBg/D/eeIDZTC7rK3hBX66P/ByxvhAMAkOCfjUbLCmZtG4fmLURSn5bCAtjIaOoVGQ4sHiNuF23oXREJBoLidNXBluGgN/ktgg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785543472; bh=uijYDbf63QNZRyqSO+BcjNAdvkUvYboCyFEczonTTzC=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=r/iLX5neOxLm1Hizrb85XBD85w5EzXJZZ8eub5uQw6xuLCA59zaDclf6AFPv8uY8IoMeT0kvgb+jB6m0hxfYoGaNbrOoiAwhLZJ0WyWrGxsRlldsu2vqjT2iF7r5DMCgvVhmPwJrM7Aobh9xl5M7otYR4T19PQEiE5EmN5hsoD4ozilwGGCKcpqthlTeCRaaJmEJZwFM0NuL6Qq2WneLEkNl/luUHL/f807PPj5xpwPTItm4lS27aVlCnItQx9I9BmRZlXYZ4nh6a1DucfEZrpGdIwmkAp1nJuAyntHllEmCKok7+xSAD+XRNyv9M83FRQ9HZJw4gnnjj6aFZT0eQA==
X-YMail-OSG: OB._0IMVM1mru75Egk5pnS7mtmdxlDFp2MywWseBRLa7DWCM3r2ltqo3uqt6Lyd
 Rt6xkeJS27P0r8Cq9siuuneSs9DQEtjumqKQ7oSfJP8gBtQ5hHZpkRl_KbOsVhoDKSlom8eoCXk9
 JjHDjqTOSzaRqfLbPNESGpRwHWksXrNIHZlhkDUUmMFutW.2LZ8OCiNPEFln2gALzKvPxvqylyDN
 A64ZIaHkUfyEkQNxs1DM8flmn0ffPHLyPfkcl7eaOtOcUHbt0JlSuUklWSz5SZfUaDQQWOWNiUuf
 ydP9LfQ3xYGgYr7KwBqvU9X9IWpDYW9.WrGii5uPQ9HgcuS32UX0Az_t76hE_G2MCFiteoTBYqJ3
 gO2JhwkRLQtVvUeoBmd0dyjzON7NCN5VoqINBBwULMJh1.LRezBmCysQMlq_urADxbeYkRenKlSM
 VAim1BV3a7EDH_T2zCTvXrB2vvY2dSDCH61a7.QQNWUrXwlDWHzSQqVm5cOO5o4LdZ3ZzSnQWJk1
 zEyUHzw4h_M_7qtNpRNQUdhFxVZE5s8P4JsMiGwggyfL8Mp5Xn5G2ZK5JqJirNWSsXIwQrDomOqz
 MKRQT3JOHBlihZvTUurD0k0W1NzLdhlvWnIiKWtcPY.exoLeDU_H3jC_2TI.W1HWxWDYjU2EUk4Q
 qde8I9juKv7Bz3YJZTJSu0UBQK2gdk0IQ593t5_EKQCGicz7aQVoIlbUtj3fptqrYxQJwaJXndVl
 roGCqXppEdlq4ZOishAOVtEMklUj32gRPDhgVb5edvwlOtIZ.NJEb8u1vKJzgzZFDLjn2g.QPHtF
 7QMslpSYIrysjLpMVv9eQ3Fa2S.IP0.OPH3zSiUTZu6bPFdxLqmPmoMYc2rS_CY7IV4XkEwC7lZK
 xVPYDwytZphPJw5ZAi05DXHVtaqQZxNkDb3_5CYfloqCCpbPob2t0GATkhSY3U9LWMltNlcZ6U0Q
 4fBOVSINurtn11QitxYCFr4WHAVqhs2sSaOgTkKQXaMifuHyx7kbzMQauQvgNiSplzYD4ZGdFBBO
 .1VY8EBlvsSEDhGwBDDM5fkRFip6dmzegTzdVbmxNx3QdyoD0JDt0PpYXQ01F2Igehn9FDwp9QLB
 Bml8OdklLIxPkOOnWCetld7UM2.9WD_mdXZD8g8TBKhlRCrSg0Nql67T5AaWKEkjYhEZDZbxqBPO
 GgWKypu7Klzo3l_y6Q_HXpi7BI8vmJaA65nm8CCwB5axK7iD_7dyqGjheHasTKLSHkdIBeF4UCaH
 UkDLwuoAMbWNLb7fMUwFxv0DTdZX0CIw9K0ouP9WnXioFium_U1pjC3vqIhkkgNsQAqceziWFAiz
 etyzoFqTmd2nz81SrTVGIgGIc5_OTPKbW84Umg_mDLfddrDXjiCwkAZ8iw180wWjJ.apfEiLPdaT
 y.Xfgbp2blqyDCBpAEFcEVMRHnm1xR6Aiucqi4DpYtmnyhaEM_nycUDv4hT3fFpCjQICTx8.rrHA
 lbXBnhe8VIddi9bvxPoi7NRr7k6kYPn2sKOnSyv9f_A.ZCrMnqr2C9afaRzW47BMDk8BSXG2RgZU
 _LoUHFazGGVf3gT3j1Js5JGisHskglTYXC_FohCPrLg51G_KgIXOrptXU.W0fmkmw1NtfIGpSk5r
 N05d1xpYhlQMLuwN3_q0XhbFbnFpT1F0iGfdhdEQAwPl5yvCCTVI0HLl4baoxwRxs0TEo1eSJwqf
 DUpikmUktwPHd6DjjSW1dpfVkae_uWupiZvJbeJ22YCl0aeQFoW.l_70f3jwYBzdczzh73nOkzFl
 WvzGwkNbXpxvX6JrNrWb9AbpgqYvj.5kZI9poCc.c6FuO5n_vmdm1XhmtG2jczhbrYB.bHvr1z7w
 lRBEA.CUOHl9dH3TY8v36HscptEguga4ggzGTPM6I_obHCxUERH7KvqHLND8j0aquqZxcgh0r2It
 XI_95HG_RMDAxh95F6zw5nPkRLLR4FBY7qMHSSdPiG4DTLrIk0aJFaPkllXhhxKDn7INc60jIhbU
 JUsuuIZU1W2ZBLixsXeV583GXc7tJgfMwtLl4.nn6JLm5xi8NNei4bKIUHeY4XBlq8_dsahsEjyJ
 8BB9M9uVlNvlK31Nl9wNoNOArKQT_oNbPdxx7xTXuaM_WX5KU9WAoJjjEt5TdpO4GhrPE8lEbDb2
 O7qxsO9vYc.gBTyHmwg__.QdRz.fHIsn9AC.kop66w.LeJbK4vrF2AKivfAprBdQFk8UM3o8F20T
 r87KSJZ6c5tp3msZ2VRwI_fIpIYm1ujTHSmn4WTVtrSV512mc5A--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 4ab60735-23cf-4f17-a1e3-b99ab0ce6955
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v4 4/6] xen/igd: enable guest creation when ROM read fails
Date: Fri, 31 Jul 2026 20:17:28 -0400
Message-ID: <20260801001737.16509-5-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 4799
X-purgate-ID: tlsNG-d25034/1785543474-776D6A5B-17B7CE2F/0/0
X-purgate-type: clean
X-purgate-size: 4906

For newer IGD devices, the host option ROM is not readable from sysfs
and this results in a call to error_fail() that causes Qemu to
exit(1) so guest creation fails with the current implementation for
many newer IGD devices. But this read failure need not be a fatal
error causing guest creation to fail because the guest does not need
the option ROM to successfully boot and run. The guest only needs the
option ROM for getting graphics output from the guest during early
boot before the guest OS loads the Intel IGD graphics drivers.

To fix this, allow guest creation to continue by avoiding setting errp
if the attempt to read the host ROM file from sysfs fails. In this case,
the memory for the guest option ROM has been allocated so free that
memory by calling object_unparent(OBJECT(&s->dev.rom)) before
continuing.

Replace the error_report() and error_printf() messages for this case
when the option ROM cannot be read via sysfs with a suitable
info_report() message.

In the case when the host option ROM cannot be read via the sysfs
interface, xen_pt_register_regions() will attempt to setup the option
ROM for the guest the same way it would for any other Xen passthrough
PCI device that has an option ROM.

Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - v4 is the first version of the series that has this patch

This patch provides initial support for many newer Intel IGD devices
so, at least, guest creation will not fail if such newer Intel
IGD devices are passed through to a Xen HVM guest. But this patch
alone is not sufficient for proper operation of the Intel IGD
for many, if not all, of the newer Intel IGD devices when passed
through to a Xen HVM guest.

There are two main problems with more recent, modern devices:

1. The newer divices might require patches to the Intel OpRegion
   and also an extended video bios table (VBT). Without support
   for these aspects of the newer devices, the experience will
   not be great and in many cases the Intel IGD still will not
   function properly in the guest.

2. The newer devices only work with UEFI AFAICT, and the Ovmf*
   platforms provided by the upsream edk2 project do not provide
   support for the Intel IGD. It appears the problem is that the
   ekd2 project deems the fact that the hardware manufacturer does
   not provide the necessary firmware, the EFI graphics output
   protocol (GOP) driver, in the ordinary way by making the EFI
   GOP driver accessible in virtual environments via the option
   ROM of the real PCI device, to be a reason to reject patches
   that add support for the Intel IGD. This, however, is not a
   fatal problem since it only affects the guest during early boot
   when OVMF or the bootloader is running and the guest OS
   graphics drivers have not yet been loaded. Lack of support
   for the Intel IGD in OVMF does not seem to affect the experience
   negatively once the guest OS graphics drivers have been loaded.
   So efforts to address this problem are only important in cases
   when it is necessary to get graphics output from OVMF and/or
   the guest bootloader.

The next two patches in this patchset address these two problems.
Of those two patches, the first one is more necessary, and the
second of those two patches is only needed to provide graphics output
from the guest during early boot.

 hw/xen/xen_pt_graphics.c | 7 +++++++
 hw/xen/xen_pt_load_rom.c | 5 +----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 0ae95cc..a124233 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -187,6 +187,13 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
         return;
     }
 
+    /* Case when the host ROM file from sysfs could not be read */
+    if (!bios_size) {
+        object_unparent(OBJECT(&s->dev.rom));
+        bios = NULL;
+        return;
+    }
+
     if (bios_size < sizeof(struct rom_header)) {
         error_setg(errp, "VGA: VBIOS image corrupt (too small)");
         return;
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 407b630..eaf0ae1 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -77,10 +77,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     memset(ptr, 0xff, dev->romsize);
 
     if (!fread(ptr, 1, st.st_size, fp)) {
-        error_report("pci-assign: Cannot read from host %s", rom_file);
-        error_printf("Device option ROM contents are probably invalid "
-                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
-                     "or load from file with romfile=\n");
+        info_report("pci-assign: Cannot read Option ROM %s from host", rom_file);
         goto close_rom;
     }
 
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 02:17:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 02:17:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379779.1624192 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpzHd-0003EN-NL; Sat, 01 Aug 2026 02:17:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379779.1624192; Sat, 01 Aug 2026 02:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpzHd-0003EF-IR; Sat, 01 Aug 2026 02:17:05 +0000
Received: by outflank-mailman (input) for mailman id 1379779;
 Sat, 01 Aug 2026 02:17:04 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ziy@nvidia.com>) id 1wpzHc-0003E8-Ds
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpzHb-00Aunc-NM
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 04:17:03 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a6d56d1-e002-0a2a0a5209dd-0a2a4501e050-26
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 04:17:03 +0200
Received: from [52.101.201.44]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a6d571d-5984-0a2a45010019-3465c92c65c2-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 04:17:02 +0200
Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7)
 by PH8PR12MB7373.namprd12.prod.outlook.com (2603:10b6:510:217::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.16; Sat, 1 Aug
 2026 02:16:57 +0000
Received: from IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0270.015; Sat, 1 Aug 2026
 02:16:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=u44/GoQAKEfhaTFN0cACyRuDUN/qFmU5KeNVe6H4h01LG6EoPe6fnBbXHMpvBNCKR52tlotyqMT1TD+lPynBXR7ecEjwk9SwoKLVYcpaosIDc3Lle0tXrynJpIK5XMVquvSoVXzKBgMRiAioSWi1+iRpJWbhwvOlk1cL6tMUJWO1yxS3fYGbhJPSRk7accS5G0CpIoZmpF3syHO/VbBkMGuA4/8iNx0iOU0QdbDUtOkYbKMMuUGe0XZCPBphpGdWG/oPchow0KvvOymP03pXnUH488q+GcGkdbCmmqiCjYUBV4qFMl0kKjjo8/v2T0ILSe5qr1KuaNr3lS/v7Rf0CA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+rDyjehUqENheZn7IayeoBu38MNxc8V2l1+M+P1R5Kk=;
 b=hwVTZ+ZIjCwu3z85up7B78kt4GgN1SRYJ4xJQBqvlw09N6Wglz5dChzfwRxpQqoTp7FM3aZJQtI2bzzxGXyz/3D+koJsURiylUVybKgN8FLaLR5SISJPjx6rQVPujnnul2Q8RVnfeUs4ztAKbicL/xDLFDDoBzC7g1jAwHYVWYygHtXxJPbImAb/86Fe+WqZUoKJC7f7MQcPVwj/MZrj127Wo5Gpt/52C2Zt08Qe6cDjNrsGfk8UwPmZNAaX3e5U3SfBEDsHCQdQPBDDaexxDAwR9YmegDaFSk83NBV7ts1q11N7iFtizZROOnUZo//tuHsyE6ItZ5lnvPBPs6OVYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+rDyjehUqENheZn7IayeoBu38MNxc8V2l1+M+P1R5Kk=;
 b=ePN9dqmfoYRJWyt+gF6Y5HNX/2lKdq/3QAwQGnIf1SuYpRtE+2818HFICgLZOh55zQgQTBPJqmUGxUi+H3HTnAeoRuNIhTs/jW+23ZCRLBO3VozrMONGv/22ouJTIjTgX/tMDZvLVgfYPgx5Pta7xjaNt/IELhyG1gZ22FBg8AzVWlMnnKBO89zlcqtCYmaflDHjUTMExcMiwJ+QEw5pLigscriXqhULeqgV36s1134mntTwKv3qXhIr1X6nRn0gWJFlPYGyxCTsBH2qwPmXvv/YK0ihraVvrqbccSlb2pvjP4+522DVyksA5wm3ebQrfYwNoEYfTxi9LUyGBzOU6A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
From: Zi Yan <ziy@nvidia.com>
Date: Fri, 31 Jul 2026 22:13:26 -0400
Subject: [PATCH RFC 03/14] xen/grant-table: stop setting PG_private on
 pages for grant mapping
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260731-remove-pg_private-v1-3-142c97ba3562@nvidia.com>
References: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
In-Reply-To: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
To: David Hildenbrand <david@kernel.org>, 
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, 
 Andrew Morton <akpm@linux-foundation.org>, 
 Muchun Song <muchun.song@linux.dev>, Lorenzo Stoakes <ljs@kernel.org>, 
 "Liam R. Howlett" <liam@infradead.org>, Vlastimil Babka <vbabka@kernel.org>, 
 Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan <surenb@google.com>, 
 Michal Hocko <mhocko@suse.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, 
 Nico Pache <nico.pache@linux.dev>, Ryan Roberts <ryan.roberts@arm.com>, 
 Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>, 
 Lance Yang <lance.yang@linux.dev>, Usama Arif <usama.arif@linux.dev>, 
 Gregory Price <gourry@gourry.net>, 
 Ying Huang <ying.huang@linux.alibaba.com>, 
 Alistair Popple <apopple@nvidia.com>, Johannes Weiner <hannes@cmpxchg.org>, 
 Qi Zheng <qi.zheng@linux.dev>, Shakeel Butt <shakeel.butt@linux.dev>, 
 Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
 Zi Yan <ziy@nvidia.com>, Juergen Gross <jgross@suse.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>, 
 xen-devel@lists.xenproject.org
X-Mailer: b4 0.14.3
X-ClientProxiedBy: BL1PR13CA0203.namprd13.prod.outlook.com
 (2603:10b6:208:2be::28) To IA0PR12MB8374.namprd12.prod.outlook.com
 (2603:10b6:208:40e::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|PH8PR12MB7373:EE_
X-MS-Office365-Filtering-Correlation-Id: 223addd4-bae0-41ab-437c-08deef72f65e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|366016|11063799006|56012099006|10067099003|18002099003|22082099003|921020;
X-Microsoft-Antispam-Message-Info:
	ScYFd10qX5KaVaxBZiEZeesmoY/e1LTIdd+/y8YBpOBMf9QvAl1vdS9Q/+G1U4IRvoHJ6DrxRAKPmOTw6YTWWYVC9x1QfPVLI3U820TfHWdxwQDgEbeIUonNa5lXhCYqZ3ap0EJsOS2wuz3xf119PDTJdKJvFjktQXZUWAthEpZ3bUYXkzaAIqEdaM+8LoCMnXh1uF5QDXpHYHIHUEM+qiiWagwFth0NjBSAFuw8U0eLpn8AnSwIyZ/J8vJUuyL1tG4e7jWVgPDgYPHz/k0cxUpF2Xwj0fIWtQnAEATw4TnzCS90UCFnSH3fykkBQbqz3E6ehvfvsWMrkFjWJAqn9cXRST3IBXOFqBI0H34Z9D7jmLUXGyFPRFSaUj6qlgoBx66DmcHYqLXJo2FW4/WNcdkRRI7ugwvo7fWm0QPbEVV/zN79nPw/vJw5OADRYOoRsC/P8GJDodWiva3y/n+zAkv4Dyo8R7FQwZ4yuHJjSlhTiuY8OXtfXuZkSWFxTu/qCnpheTNxYDJXyBnOZkFenmpLxtoh2idPUog7PQyhHcb5Jf89LlOtcngAZxlceBI5aKXsx4tRLm33pDCCZPjqArSUZj7HnyDjM74734bJQs2m2tXIV2T5OfhBayjiAylA72D8l6+1lchkNDDNC3DddJgFDkXeeKHFEB46sxE6NfshlqoWesXTsBy9X2sFPwsrcQrD35UhG5kZOik+VQavYw==
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(23010399003)(366016)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bnc3RzZqWExLeER3a0R2VGJvZXB1a21Kb3kzTXN0a1F2RUF6elFjRzhrRXBQ?=
 =?utf-8?B?M0pGUEFRRzRRVmZka1Z5YytZL01mSU9ka1QyZ0VsYjdPWWxVTVRzZ005dnl0?=
 =?utf-8?B?L015NlZuVm1PeXN0ajhVdW9SM0hieEViYjd3THcyL29mcVE3UmhFTWl1MzVU?=
 =?utf-8?B?ajMxQWM5dFZ4bXVlcFNCTEx6MEtIS0diSElkVWlhM3MvOFV3UE9zY3BWcWtr?=
 =?utf-8?B?czkxQ1VWVVptZUU5UnZ5UkVpYWw3SUtXSmtWYlhGaitzbVhtWTFxeTE4cmlh?=
 =?utf-8?B?cGVJd1pXM3h1T2tnSDYwN3VFbkt6MTlBMzlnSTdOeHV0RVNUTll3MGh1eGJu?=
 =?utf-8?B?d0NlV3VvSWhOS0xKTG5SWnE0cmNRTk1IUGYwZnhyb1M5MHBYcjRGMytHU0hG?=
 =?utf-8?B?UkkzK1R5NWZWRU0rRDgxeks4MzFncmMxRUJkTE1xQTJCTkczMUlyNTNWb3NB?=
 =?utf-8?B?WGpvTkk5OG5KQWtRaXI2cUI1cXk2NXBWS1hZN1NUakd0Rnp3YTU4K1d1SE5O?=
 =?utf-8?B?dldRZmJtRHllRldnalFyY3JWV1lwdnVnZGJnN01rNEJWWllxV2Z5Rnp5L1ZG?=
 =?utf-8?B?ajBLcS9aanYzTHA3V1VPWXVoYjBUYkpYbEVWMzVhTlNzV1B1SEZkdmx3V2Ni?=
 =?utf-8?B?ZzNiNjFYYWloektvK2hqWE8yMjMxTW96RURjWmdnUXBUVUo4REgwS3dCQ1dX?=
 =?utf-8?B?WWVFVG9IK0tqWWFkNUlMMFUwenJmZ3hFNitNUU5JdngvbUN2eGxXY2RQTUd4?=
 =?utf-8?B?dlo0VUlNWnBYRVlTdFgwcDJaZHJtaWQ1d1ZteU9zbVhtaWJlMnY1cU9haUhy?=
 =?utf-8?B?RHNDSmpJK3gvbW4xQXJyamZPeUxzMWRmSXVHTG9nUU5STkNqelhZYS9GOUdS?=
 =?utf-8?B?SWJ1cmdvKzkvT0pDaE1BYkNxL3ByMmc5RDg5c3owQlc3NmZBUS9HRHFvbEkv?=
 =?utf-8?B?dGpZQ3lKSjFyc0p0a2E0b2JxWXdyUXFNTkNXQW5XN2k2WDgvdXFXN2p1YU5E?=
 =?utf-8?B?TnNRbC9hWjdmUWlkeGJhYWY5bXRXSzZZR2hXTSthdlJrUHdaQVRpTlQyOFli?=
 =?utf-8?B?YXAvS3NIQlRhN3ZxK3ZqVVY4WkRxcEYzTnlORXRQOVdaRG15QVNqbFFZWUtw?=
 =?utf-8?B?eFExaHREbVl1Z3BKaVZacHVUS3dBb0RKSFhtVUFTNWRBSjQ2UXBHbEV6WVo3?=
 =?utf-8?B?YjA3YVg5VnZvakJsMjdsQWZ1azlaVGl1K05YWVRoVWp3ckJuaCtIR0hFVjQv?=
 =?utf-8?B?RWhjNkgySExPeVVpYlJNcXQxdlZiOVU2cHZONmZHdDF6VmVsM1pXNGVuNFF2?=
 =?utf-8?B?MlNHQVNCYUkvOEExc2R2VWxyTmJJOHNMdlJkb2M2VEFhdWdWbkxyUTR6UXVW?=
 =?utf-8?B?RFhiTmtNOHJ0NjZyWUFMbW1DVWdkc0FScmZjWmdFbzlGeXBzNzFtM2ZlQ2VV?=
 =?utf-8?B?RDBqek8wVkdZZ3NUWWVmbDZqNDNiRU1TeHM4WTRRWTIxbGlaN1UzM1RlRTZL?=
 =?utf-8?B?bWFNQ0pBdFZlb0NBSWFpMEtoa2pjNEZxeXBUWU81eGlPT0ZkaWhJTmwyK1V0?=
 =?utf-8?B?di9BRzJrY3RqbkZZc0pWdGZFRytReGRPeU0wdjJ2RThIQlZVMnlKZTFtelhr?=
 =?utf-8?B?eVQxaU41UnVZREY1ZENqVG9qdTVWcjJVTE16NUN0RFBUZ2JGQ25yZXFhQnFP?=
 =?utf-8?B?d2NLU1pweWp6OWFRaEF5UW9FdFdlbHBTeHJWdUZha2tZWjJyVDNVNGVXSVEv?=
 =?utf-8?B?WjNWd2VDNlE5bkcyb3VSRFpEQVdGQlBkUjJDSXNWY0o5NEFCNVVCVnBjZVV4?=
 =?utf-8?B?OVhra3p1ODlvbTlBeWsrd1VVNklaaWdackQrL2RZcXpxNm1OeWVXSGUxVFND?=
 =?utf-8?B?Znh5ZjhsVmsrTFh1eWt2b2JtVmpiTjd5WjhMQTkxSVZ1ZWxwWE8yOWpKdE92?=
 =?utf-8?B?N0xIYllFVWMzUVFqTHlZU0d6YXZFSkdRZ1JieC9Gb0pCelRpaUsxTFljQzhi?=
 =?utf-8?B?bjZaNXpxQTgrOEthMjZjVmdUbWlKcXlPa1FGUU83Qi9nbXIxakpUclB6RHEx?=
 =?utf-8?B?b1RDUVlHN2xqL05qaG9DY3Y1K3R2SFd0Vkd0MUs4M2Vtbi95eWYwRnZiWTZJ?=
 =?utf-8?B?OXVmVUs0M21Cc3NVVnc4ZExaN3RISWg3MEpFNDhnVjNjaHNaYUVqbjRWNDkx?=
 =?utf-8?B?Q2JvYTg1aE9zaGxrYmo5bzd4RHlubUtiem9JTGZFdHlhWStsMTl2QWlod2wy?=
 =?utf-8?B?K1gvaElhOE43UjgramV3L0lPaDlrWjJEeXRnWkhJWml6WGhlRjBhQmpxYmk2?=
 =?utf-8?Q?ITaq4Fubij1f0izSo5?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 223addd4-bae0-41ab-437c-08deef72f65e
X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2026 02:16:57.2721
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: l0Am5J63xefsnsrMlCk7fC0Wd3OeYNH67IOGu5z5PLPygKkzgKEkQimaGrjMNeEp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7373
X-purgate-ID: tlsNG-d62444/1785550623-BF46D757-6BC18A1D/0/0
X-purgate-type: clean
X-purgate-size: 2244

gnttab_alloc_pages() stores xen_page_foreign in allocated page->private.
On 32-bit, a pointer to xen_page_foreign is stored; on 64-bit,
xen_page_foreign is stored inline. Checking page->private != NULL is enough
to tell whether a xen_page_foreign needs to be freed on 32-bit and
page->private is zeroed unconditionally on 64-bit.

It prepares for a future commit that remove PG_private.

No funtional change intended.

Assisted-by: Claude:claude-opus-4-8
Assisted-by: Codex:gpt-5
Signed-off-by: Zi Yan <ziy@nvidia.com>
To: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/xen/balloon.c     | 5 +++++
 drivers/xen/grant-table.c | 7 +++----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e7f1d4ca6d753..7f47b0ad05607 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_lowmem)
 
 	__ClearPageOffline(page);
 	dec_node_page_state(page, NR_BALLOON_PAGES);
+	/*
+	 * clear page->private before giving it out, since it might be used to
+	 * store xen_page_foreign info.
+	 */
+	set_page_private(page, 0);
 
 	return page;
 }
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 35f879dc5dfb8..cc348ba2e0786 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -875,7 +875,7 @@ int gnttab_pages_set_private(int nr_pages, struct page **pages)
 
 		set_page_private(pages[i], (unsigned long)foreign);
 #endif
-		SetPagePrivate(pages[i]);
+		/* Data is stored in page->private on 64-bit */
 	}
 
 	return 0;
@@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, struct page **pages)
 	int i;
 
 	for (i = 0; i < nr_pages; i++) {
-		if (PagePrivate(pages[i])) {
 #if BITS_PER_LONG < 64
+		if (page_private(pages[i]))
 			kfree((void *)page_private(pages[i]));
 #endif
-			ClearPagePrivate(pages[i]);
-		}
+		set_page_private(pages[i], 0);
 	}
 }
 EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);

-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 02:17:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 02:17:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379780.1624202 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpzHf-0003R5-Sh; Sat, 01 Aug 2026 02:17:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379780.1624202; Sat, 01 Aug 2026 02:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wpzHf-0003Qy-P8; Sat, 01 Aug 2026 02:17:07 +0000
Received: by outflank-mailman (input) for mailman id 1379780;
 Sat, 01 Aug 2026 02:17:05 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ziy@nvidia.com>) id 1wpzHd-0003EE-L1
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 02:17:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wpzHd-00Aunc-1z
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 04:17:05 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a6d56d1-e002-0a2a0a5209dd-0a2a4501e050-28
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 04:17:04 +0200
Received: from [52.101.201.44]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a6d571d-5984-0a2a45010019-3465c92c65c2-4
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 04:17:04 +0200
Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7)
 by PH8PR12MB7373.namprd12.prod.outlook.com (2603:10b6:510:217::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.16; Sat, 1 Aug
 2026 02:16:55 +0000
Received: from IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0270.015; Sat, 1 Aug 2026
 02:16:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=juOG2d/steEklncNOvTy2HvMCzBRsBGtDaBigF+Zw99wCtxthKH9xaGYT9qWEVMP8Q76Iov7fdZDUGjwHlvM66fNmEIIPjId1D7gZZLIViWJAtaPlxuhcb7/aCtyiXWtwjSDdkuhSj4uxmaU6voqSMzVv+wLCaZdEpm1UniIM6XXr/y08d3cNmlDzA37/s+JyM+lKktnI+pPDcw4LcroYMhMWSlFXabL9JX7qqq2G9GkbyzxNZZdBfDXhiVcwodCDaUwfV4RLlUop1Vjl3p2ixOvETBfmnPpPYyDCHPwUZ6z8D4R4UBbp3gbajUber9EYwmfNycR/9reTyem8JAXug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1Dj2NYUyQZvuonVfcvoKoW2H3adtSVWranxYgEi8YQU=;
 b=nS22Y21LUCkU9rE1tarBHVVoAOS6WoqXifPtaQIE8OYP/CiU7e1kuVgaMB8YfpBfwoWAzik518UdioQWoZmjgtRvCkiZoV18o6PNnRTVj6ggOgtj6OEdb9s9LF2yhoqyLMGg1EJ5eSVv4eBT1+JcD+3kJZrBt9FU0cKgRk9BBrqrjgM5c0KkO59dyK/lRP96h2SLx1wu57lFNzyM/iAKasNf3twQFbmJao0qMCbFWmBjeHqehUINFK536hvgVac4mYp2NrOIMZcRh5B4mo81JHleaUmUx1urY27cvvzQgM2iZgZQWkKx38i1rxQ8hux3PaeLK5OtUsv35myLt1YIAw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1Dj2NYUyQZvuonVfcvoKoW2H3adtSVWranxYgEi8YQU=;
 b=FB5Uzv+jjIOz2Gqd5kNRUmj0oMIAGc13ZaO7PxN87N2Vsm1h2AmI6UBCGxbiU8v7rBmpSk66cpyjk9doS0l2Cwug3L6tWxa7EnpwkUAI8obSHPvyEZtRmsQRP4Ad/qzEarvlDy1s6rnXeWJmaBg7+kXQP80MMmTUTKKx60Kkrzh78dZdHaCQVnN4Ent82GUKgm+hwh7r8TitUV618trGITHpcjPjn9zyBwtkgbG20BWoOZwi5n1SC1ZzVLkEqAMp7SKzKMlAu2o6c8XmMv0HO0zTS1DVdv1s4GB47p2UxxkBgmCmVu6y6Mvahl6HousWTQ32VDFXU9udlm0xGrD9Mg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
From: Zi Yan <ziy@nvidia.com>
Subject: [PATCH RFC 00/14] Remove PG_private by using page/folio->private
 checks instead
Date: Fri, 31 Jul 2026 22:13:23 -0400
Message-Id: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-B4-Tracking: v=1; b=H4sIAENWbWoC/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyDHUUlJIzE
 vPSU3UzU4B8JSMDIzMDcyML3aLU3PyyVN2C9PiCosyyxJJU3eS0VEsjs2TzNAvjZCWgvoKi1LT
 MCrCZ0UpBbs5KsbW1AC4r+oRoAAAA
X-Change-ID: 20260728-remove-pg_private-cfe926c7f83c
To: David Hildenbrand <david@kernel.org>, 
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, 
 Andrew Morton <akpm@linux-foundation.org>, 
 Muchun Song <muchun.song@linux.dev>, Lorenzo Stoakes <ljs@kernel.org>, 
 "Liam R. Howlett" <liam@infradead.org>, Vlastimil Babka <vbabka@kernel.org>, 
 Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan <surenb@google.com>, 
 Michal Hocko <mhocko@suse.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, 
 Nico Pache <nico.pache@linux.dev>, Ryan Roberts <ryan.roberts@arm.com>, 
 Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>, 
 Lance Yang <lance.yang@linux.dev>, Usama Arif <usama.arif@linux.dev>, 
 Gregory Price <gourry@gourry.net>, 
 Ying Huang <ying.huang@linux.alibaba.com>, 
 Alistair Popple <apopple@nvidia.com>, Johannes Weiner <hannes@cmpxchg.org>, 
 Qi Zheng <qi.zheng@linux.dev>, Shakeel Butt <shakeel.butt@linux.dev>, 
 Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
 Zi Yan <ziy@nvidia.com>, Minchan Kim <minchan@kernel.org>, 
 Sergey Senozhatsky <senozhatsky@chromium.org>, 
 Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, 
 Arnaldo Carvalho de Melo <acme@kernel.org>, 
 Namhyung Kim <namhyung@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, Mark Rutland <mark.rutland@arm.com>, 
 Alexander Shishkin <alexander.shishkin@linux.intel.com>, 
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, 
 Adrian Hunter <adrian.hunter@intel.com>, 
 James Clark <james.clark@linaro.org>, "H. Peter Anvin" <hpa@zytor.com>, 
 linux-perf-users@vger.kernel.org, Juergen Gross <jgross@suse.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>, 
 xen-devel@lists.xenproject.org, Eric Biggers <ebiggers@kernel.org>, 
 "Theodore Y. Ts'o" <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>, 
 linux-fscrypt@vger.kernel.org, Oscar Salvador <osalvador@suse.de>, 
 Chao Yu <chao@kernel.org>, linux-f2fs-devel@lists.sourceforge.net, 
 Gao Xiang <xiang@kernel.org>, Jan Kara <jack@suse.cz>, 
 Yue Hu <zbestahu@gmail.com>, Jeffle Xu <jefflexu@linux.alibaba.com>, 
 Sandeep Dhavale <dhavale@google.com>, Hongbo Li <hongbohbli@tencent.com>, 
 Chunhai Guo <guochunhai@vivo.com>, linux-erofs@lists.ozlabs.org, 
 linux-fsdevel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, 
 Masami Hiramatsu <mhiramat@kernel.org>, 
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
 Matthew Brost <matthew.brost@intel.com>, 
 Joshua Hahn <joshua.hahnjy@gmail.com>, Rakie Kim <rakie.kim@sk.com>, 
 Byungchul Park <byungchul@sk.com>, 
 Axel Rasmussen <axelrasmussen@google.com>, Yuanchu Xie <yuanchu@google.com>, 
 Wei Xu <weixugc@google.com>, linux-trace-kernel@vger.kernel.org, 
 Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>, 
 linux-nfs@vger.kernel.org, Song Liu <song@kernel.org>, 
 Yu Kuai <yukuai@fygo.io>, Ilya Dryomov <idryomov@gmail.com>, 
 Alex Markuze <amarkuze@redhat.com>, Viacheslav Dubeyko <slava@dubeyko.com>, 
 Li Nan <magiclinan@didiglobal.com>, Xiao Ni <xiao@kernel.org>, 
 linux-raid@vger.kernel.org, ceph-devel@vger.kernel.org, 
 Richard Weinberger <richard@nod.at>, Zhihao Cheng <chengzhihao1@huawei.com>, 
 linux-mtd@lists.infradead.org, Baoquan He <baoquan.he@linux.dev>, 
 Pasha Tatashin <pasha.tatashin@soleen.com>, 
 Pratyush Yadav <pratyush@kernel.org>, Jonathan Corbet <corbet@lwn.net>, 
 Dave Young <ruirui.yang@linux.dev>, Shuah Khan <skhan@linuxfoundation.org>, 
 kexec@lists.infradead.org, linux-doc@vger.kernel.org
X-Mailer: b4 0.14.3
X-ClientProxiedBy: BL1PR13CA0208.namprd13.prod.outlook.com
 (2603:10b6:208:2be::33) To IA0PR12MB8374.namprd12.prod.outlook.com
 (2603:10b6:208:40e::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|PH8PR12MB7373:EE_
X-MS-Office365-Filtering-Correlation-Id: 8049e82e-f2ed-4234-27b6-08deef72f511
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|366016|5023799004|11063799006|56012099006|10067099003|18002099003|3023799007|6133799003|921020;
X-Microsoft-Antispam-Message-Info:
	pNDbTnWlggYMSHNy6jsULJFDGtRzmhD27769oJzJU2pngka0LaGEKVpniUoUJ3CQmbg9xv959+2z+JRtqFf67HdU+qB4JaCwRrXHvxitHS4+X0w1LJjCqx7wSOTmTpy3XxuOd9+f8rK/oQHRePQKndJw/6mlHZZMRqE9wjM6o1AKyiS+KOoN9AwCyphX8Vge1MTQ4lDkgWBEWecQpXPpnk0UVsgsZQXPhDQPsCCipKZBMP4VxfsQyzGYHKkCHv+pjywEZE4DEG6l+4rl5dqSNtc7Qp/DQhsoH47boah3/NyuS1fH0f4kWHFAY6G6Uc40wwSbnwNwgs+WyRKk+i8gXQhhXxEgFiKIttIR6DzHA+ZDDvqLRYbRPY4/hfrCcr7v8m7gnFeK1A/TZtrfpXTX8OQHDcrLTPwZSWiqO7CgFcVOlcx6g3XcpK6DY058ctzvMykbyqZaT3/MipYsv6FlMBL6ObuDgleNuUqlH1qFmIrE1zerLMArOoouhPo7b0s2r8t/oX7VceX7KaXz8dR06EcgNpjyds4vn+pl4J9+JGfO801D7wUbLE0kNRfs3NfM96JMpb8PT2+Pv0dezg5+fDtkUnY8TRZh/pSBDuNLl0m7gAChrxtLbAkf1kt7TaGiF4i0NjEzc+x2hdxLFU5P8kIq8nFhZ6pjA5bStDcTp7wi6cPDfsKsUTMx1/68zgx1mYhoWmcx/XO8OqmYGdg28g==
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(23010399003)(366016)(5023799004)(11063799006)(56012099006)(10067099003)(18002099003)(3023799007)(6133799003)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?S0xSZ2tsSUJ1YURzL2lvL2tRdmRuVEFFNFlkQnBtd1dkOG4vbTg2cHFsVnRG?=
 =?utf-8?B?VFNoYzN2cXdwK3picTlObkZKZGdHYTMxUjNlR0xycFB4WXUycHhxeEhYOHd3?=
 =?utf-8?B?K0J2Uk9rVk1WUkZOVEFtd2ZwNWdOZ2QxekZNTEphRWh5L2NxRlFZZFlVUXZB?=
 =?utf-8?B?K3NxZWdPQ0lyVThKaFZBelNPV1EzOVl5VEhQaFZydTRzblRDNDY1U01mQnhD?=
 =?utf-8?B?NDhiU1dKdE5SWXVoSjkvdDc0dnNUSzdoVjdSQnordHV1Tk0zSFZwaS9EUGto?=
 =?utf-8?B?aEtpY2ExQzM3T1VTbWEycmdiT1hzSTVFclVkMXg0eWJhWDI5WmhtL1duV0Z2?=
 =?utf-8?B?SlNBK1lYUCtaVkFtdFdRZ2RuQVZuTGdoVjl4V2xmVTBTRmhZQ2JYUDBORDJH?=
 =?utf-8?B?QnV2b2RvbnVFRUtOcnZHcTlRQlZMaWtzMXFyWnk5OXpvd1Vib0ZkSUdJZWdP?=
 =?utf-8?B?UDJ3Y2xwTmtNRVdYR1JJeTgvMXNOTERXcDFRaDBiQlpHOThGTnFQR1RCNnRr?=
 =?utf-8?B?SHE4M1BFZXBFTW9BbXExQWJYNEZsNTl6WkRtd1NMU08ycU5wRVFnWHlxb05L?=
 =?utf-8?B?a1pFT2h1VW9BdDlrYnBCNExFdWRTYnNmbVk4UEdaYnJyL0pueVZJczJ1MC85?=
 =?utf-8?B?RlJhcnRCbkl2SzZuV3ovN01xcjhkcWVNSVJqZHp1akNhUDA2b2Q1YWY5RkNa?=
 =?utf-8?B?TVpvUG9tSG5mcm0xMG9mTHFwZnVMYjBrdVRleG5UcmlXSVlnWGs5eWQ0Kzll?=
 =?utf-8?B?RDBSMlFuL3JucEFxeHRGYURTOERQdkxmYWMrWEFLak0xZVZ2RGVqUWZieFBu?=
 =?utf-8?B?NmhZMk9yci9URFpuaHUwQVpGa2p3VnJFK2pNRjduanF2Lys0Z0JDMTBkblBp?=
 =?utf-8?B?L3dQd2hhTC9PSkZhY09neFIxWEo1d2Q2UmJQQWdyMkF0aGQwWVprQ1hJTVcv?=
 =?utf-8?B?RTl0Z25ZM2J5SW8rMkMrblhROS9vZFZNTHIzY1BjKzFlTEZOTGd6ckozVmhY?=
 =?utf-8?B?YXBPdHVMRjgzNHgra3VibnRFbkdScXNjVkdFQ2pIdVJBRE81OWlsaS9IL01R?=
 =?utf-8?B?L25MZE92SFBFVFd6TFpEdG4wZ1JlRVdxS2x3WE5JbVViOXFsdU92eVN1TFdE?=
 =?utf-8?B?ak1UUjRUak5tVVh4MzFqdVpUT3BNbFNVRFBPUDc3d1ZXSlV6Nktoa0RhSjlW?=
 =?utf-8?B?UDlpRlViYzJaM09aY1lEYjVOOVNpWExmVFo1cFNSaXB3WGRKWlNaUGt1WkVv?=
 =?utf-8?B?bVp5QTFDM1BHZWZqZGQzbjFRMC8zM1I1Q1VtZWVhZWp5Ull6T2hJMmszTGFl?=
 =?utf-8?B?eXo5V0RMQWFUVHFMMG1ZQThHVW1nMDVIaEVKOEc5djY0TFIvNEpKVnJPM093?=
 =?utf-8?B?MHh4NmdhV0dERDZYTE5RdGF6OURVRThnUko4aDBsTmppSVRyb0pMYkV3b05u?=
 =?utf-8?B?UUVaNkxQNlp0NHRCWkFlVHhiR3hRZDF0RHMvcjFnelhHZU1peEpqYlNyLzlY?=
 =?utf-8?B?c1VsL1lNbHBEYk12cDkxZHJHM3Q2eS82UnZmT00vY0p2eWlwelRpeXc0cWxM?=
 =?utf-8?B?cVRpVExMSXdEQk1LUllBQ3RmOW02S0lOWDRqMFhoL2JTSkh0SnFhcGNzZWpC?=
 =?utf-8?B?eDYwR05Xbmg1WVhybkRrWW1sRTJZM1NENjlUNkM4RzdEWVZBSHN4NlcyRFdP?=
 =?utf-8?B?UUxDOEVZTXFsQVk1dCtmQ2Z0THZHTlRGdzlwV0FkTU5wdVdzZ3VncFNweEVH?=
 =?utf-8?B?WHBvSGUwcG5qVU10ZVBGYitrSkc2aUQvdzZaZXFKdzh5SjFHemVMTkhtSEhi?=
 =?utf-8?B?Slo0ZE9Cdjk4UkdVZ3I5dXhoNzlqdGE3c0xkOFM3clRCSDlnN2puNnFDWlhw?=
 =?utf-8?B?ZDZyTXNEQXBKdGc2LzhUSzNTVmYvOGZ0WEpxQXptbTA0ME5KWTQ5cHVybGov?=
 =?utf-8?B?SWNYYnJ3QVJlaW91d3VvMjFEcGl3R0RWemdqM1hYTHAxak5wL1VQeUo0TFdY?=
 =?utf-8?B?RDdmS3kxSUYwMlBwN01CTmlZMlpvQlg5Mkp0SWxzZTFMY3BrcEpqMHdGZ2Fy?=
 =?utf-8?B?Y0g3eWE3UlRuUmkrTnVnc29adHdwM3J2V3VrS21NUU92T3dBVHkwcThlbWJh?=
 =?utf-8?B?UkRmUDYwdy95cVByVklSRHpXenhpdHNORWJKdTNFaFV6WjNsbmZpaFRvM052?=
 =?utf-8?B?clUzczgvaXVmaWZjamxqNDVqQTRHR2M4MzFUQmN0Z2NkUjVROHJvakFZVlhD?=
 =?utf-8?B?TWRpYnhlNU5ZMjFXZDFzellUTlloTDMwZE1aTkxWYi8rM0xCbmpuM3JabDVp?=
 =?utf-8?Q?rIlyagVXs903sFdXgk?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8049e82e-f2ed-4234-27b6-08deef72f511
X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2026 02:16:55.1454
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dHRY+Bi+1YHiBNSqzAr7tvYfQ+7uKeAf5TdP84c5qEpoH6FkhhVKrN9emBFarEQs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7373
X-purgate-ID: tlsNG-d62444/1785550624-BC558757-8DBA9948/0/0
X-purgate-type: clean
X-purgate-size: 8724

Hi all,

This patchset removes PG_private to make space for upcoming PG_folio
(reserved as __PG_folio) for identifying pages from a folio (more details
in Note below). Instead of checking PG_private, all code is changed to
check page/folio->private != NULL instead.

MM people are cc'd on all patches and subsystem people are cc'd on the
cover letter and corresponding patches.

Overview
===
Most code uses folio_attach/detach/change_private() functions, so folio
refcount is increased and decreased when folio->private is set and reset,
respectively. There is no need to change them.

Changes are needed for exceptional users:
1. zsmalloc uses PG_private to indicate first component zpdesc page and
   page->private is used to store zspage in zpdesc. To remove PG_private,
   is_first_zpdesc() is changed to zpdesc->zspage->first_zpdesc == zpdesc
   instead of checking PG_private.

2. kernel/events/ring_buffer.c stores page order in page->private.
   Replacing PG_private with page->private != NULL works.

3. drivers/xen/grant-table.c stores xen_page_foreign in page->private,
   where on 32-bit, a pointer to xen_page_foreign is stored; on 64-bit,
   page->private is used as xen_page_foreign. PG_private check is replaced
   by page->private != NULL on 32-bit for xen_page_foreign deallocation.
   On 64-bit, page->private is cleared unconditionally since {domid=0,
   gref=0} (xen_page_foreign can be 0) is valid.

4. fs/crypto/crypto.c stores a folio pointer in page->private, PG_private
   checks are replaced by page->private != NULL.

5. fs/erofs has two different uses:

    5a. folio->private is used to form a reversed list of
    the outputs of readahead_folio(). readahead_folio_reverse() is added to
    output folios in reversed order, so that ->private is no longer needed.

    5b. folio->private is used as an in-flight I/O counter. Convert the
    code to use folio_attach/detach/get_private().

6. fs/nfs/write.c: folio refcount maintenance is in a bigger scope than
   folio->private. So folio_attach/detach/get_private() is not used.
   Nothing to change.

7. fs/f2fs uses attach_page_private() to first reset folio->private then
   immediately sets PAGE_PRIVATE_NOT_POINTER bit on it. Change it to use
   attach_page_private() to set PAGE_PRIVATE_NOT_POINTER bit directly to
   avoid folio->private == NULL gap inside set_page_private_##name().

8. hugetlb uses folio_change_private(folio, NULL) without folio refcount
   maintenance. Change it to folio->private = NULL.

After the above changes, PG_private ops are converted to
page/folio->private ops.

folio_test_fs_private() is added to check filesystem-only private data by
excluding swapcache and hugetlb folios, because swapcache folios overlap
swp_entry_t swap with ->private and hugetlb sets its own flags in
->private.

Note
===
1. KPF_PRIVATE has a minor semantic change. Since PG_private will be
   removed, KPF_PRIVATE represents pagecache folios whose ->mapping is not
   NULL and with ->private set. Currently KPF_PRIVATE can be set for
   orphaned pagecache folios with ->mapping == NULL.

2. Documentation/mm/hugetlbfs_reserv.rst is outdated, so I did not remove
   PG_private related text. It should be rewritten.

3. PG_folio is planned to be set on every page from a folio in
   page_rmappable_folio(), so folios with any order (currently
   PG_large_rmappable is used to identify >0 order folios) can be
   identified, vm_insert_*() can correctly reject all folios, and rmap code
   can accept only folios. Eventually, page_folio() will return NULL for
   non-folio pages.

Tests
===
1. allmodconfig build passed.

2. zsmalloc is tested using ext4 on a 1GB lz4 zram:
    2a. zram load + zsmalloc compaction;
    2b. concurrent zspage migration via memory compaction;
    2c. confirmed that multi-page zspages actually formed.

    Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_zsmalloc.md

3. erofs is tested on images created with -C4096 and lz4hc, lzma,
   deflate, and zstd algorithms:
   3a. cold read of all files, verify checksums match source;
   3b. readahead + reclaim/migration race.

   Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_erofs.md

4. fscrypt is tested on software-encrypted ext4 with writes to exercise
   bounce pages.

   Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_fscrypt.md

5. f2fs is tested on an image with inline_data,compress_algorithm=lz4:
    5a. INLINE_INODE — lots of tiny files;
    5b. REF_RESOURCE + general writeback — buffered write churn with fsync;
    5c. ONGOING_MIGRATION — force GC / page migration;
    5d. ATOMIC_WRITE — atomic-write ioctl path.

    Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_f2fs.md
    (I did not run xfstests)

6. MM selftests passed.

LLM use
===
Claude was used to form a concrete plan on what code needs to be changed
and how to change them. The plan was reviewed by Codex until no issue was
spotted.

Plan is at: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/plan.md

I then followed the plan to make code changes. I did bounce ideas with
Claude how to change fs/erofs, since I did not like the original idea.
After each change, I asked Claude to review my code and git commit message.
I also asked Claude to give me test plans (see above).

At last, Codex was used to review all patches.

Comments and suggestions are welcome. Thanks.

Assisted-by: Claude:claude-opus-4-8
Assisted-by: Codex:gpt-5
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
Zi Yan (14):
      mm/zsmalloc: replace PG_private with pointer comparison
      perf/ring_buffer: stop using PG_private as AUX page high-order marker
      xen/grant-table: stop setting PG_private on pages for grant mapping
      fs/crypto: stop setting PG_private on bounce page
      mm/hugetlb: use direct assignment instead of folio_change_private()
      fs/f2fs: stop using PG_private
      fs/erofs: mm/pagemap: add readahead_folio_reverse() to avoid folio->private
      fs/erofs: use folio_attach/detach_private() instead of direct assignment
      mm/page-flags: check page/folio->private instead of PG_private
      mm/page-flags: introduce folio_test_fs_private()
      treewide: remove folio_set/clear_private()
      treewide: replace PagePrivate() with page_private()
      treewide: adjust comments on PagePrivate and PG_private
      mm/page-flags: remove PG_private

 Documentation/admin-guide/kdump/vmcoreinfo.rst |  2 +-
 Documentation/filesystems/vfs.rst              |  6 ++--
 arch/x86/events/intel/bts.c                    |  3 --
 arch/x86/events/intel/pt.c                     |  6 ++--
 drivers/md/md-bitmap.c                         |  6 ++--
 drivers/xen/balloon.c                          |  5 ++++
 drivers/xen/grant-table.c                      |  7 ++---
 fs/ceph/addr.c                                 |  8 ++----
 fs/crypto/crypto.c                             |  2 --
 fs/erofs/data.c                                |  5 ++--
 fs/erofs/zdata.c                               | 11 ++------
 fs/f2fs/f2fs.h                                 |  8 +++---
 fs/nfs/file.c                                  |  4 +--
 fs/nfs/write.c                                 |  2 --
 fs/proc/page.c                                 |  5 +++-
 fs/ubifs/file.c                                |  6 ++--
 include/linux/buffer_head.h                    |  6 ----
 include/linux/mm.h                             | 16 +++++------
 include/linux/mm_types.h                       |  4 +--
 include/linux/page-flags.h                     | 38 ++++++++++++++++++--------
 include/linux/pagemap.h                        | 35 ++++++++++++++++++++++--
 include/trace/events/mmflags.h                 |  2 +-
 include/trace/events/pagemap.h                 |  2 +-
 kernel/events/ring_buffer.c                    |  7 ++---
 kernel/vmcore_info.c                           |  1 -
 mm/huge_memory.c                               |  2 +-
 mm/hugetlb.c                                   |  6 ++--
 mm/migrate.c                                   |  3 +-
 mm/page-writeback.c                            |  5 +++-
 mm/vmscan.c                                    |  3 +-
 mm/zpdesc.h                                    |  2 +-
 mm/zsmalloc.c                                  | 15 ++--------
 32 files changed, 127 insertions(+), 106 deletions(-)
---
base-commit: bcd5eb68a6a189497eb26c1b9f622538aa48895d
change-id: 20260728-remove-pg_private-cfe926c7f83c

Best regards,
-- 
Yan, Zi



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 03:21:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 03:21:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379799.1624211 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq0I5-00054d-EL; Sat, 01 Aug 2026 03:21:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379799.1624211; Sat, 01 Aug 2026 03:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq0I5-00054W-Aq; Sat, 01 Aug 2026 03:21:37 +0000
Received: by outflank-mailman (input) for mailman id 1379799;
 Sat, 01 Aug 2026 03:21:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wq0I3-00054Q-9y
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 03:21:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wq0I0-000uL9-3s
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 05:21:32 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a6d65b6-5cb7-0a2a0a5109dd-0a2a4503b7d6-30
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 05:21:32 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a6d6637-fae8-0a2a45030019-94a38ff1754c-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 05:21:28 +0200
Received: from pps.filterd (m0367128.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 66VLw8RS2091199
 for <xen-devel@lists.xenproject.org>; Sat, 1 Aug 2026 03:21:27 GMT
Received: from mw6pr02cu001.outbound.protection.outlook.com
 (mail-westus2azon11012011.outbound.protection.outlook.com [52.101.48.11])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4fs2jn9yfv-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 03:21:26 +0000 (GMT)
Received: from SJ0PR03CA0275.namprd03.prod.outlook.com (2603:10b6:a03:39e::10)
 by PH0PR16MB4782.namprd16.prod.outlook.com (2603:10b6:510:145::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.15; Sat, 1 Aug
 2026 03:21:20 +0000
Received: from SJ5PEPF000001EC.namprd05.prod.outlook.com
 (2603:10b6:a03:39e:cafe::67) by SJ0PR03CA0275.outlook.office365.com
 (2603:10b6:a03:39e::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.270.16 via Frontend Transport; Sat, 1
 Aug 2026 03:21:20 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SJ5PEPF000001EC.mail.protection.outlook.com (10.167.242.200) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.8
 via Frontend Transport; Sat, 1 Aug 2026 03:21:19 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6713C6XZ3235982
 for <xen-devel@lists.xenproject.org>; Fri, 31 Jul 2026 23:21:18 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [44.208.76.22])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fs8pg80bv-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Fri, 31 Jul 2026 23:21:18 -0400 (EDT)
Received: from localhost ([19.12.92.221]) by cmsmtp with ESMTPSA
 id q0HkwQP2q1Fglq0Hlw8Pe8; Sat, 01 Aug 2026 03:21:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=nrHVQBAOvOe4C0Nray242Rigc
	P7NARuM6TjGSPzA8es=; b=uABiRfb9JIwVr1pAabS0UeLxee6O2exoGE48yprwl
	HnRl1QoKhtYFym6V/rQy5zLtbPR2RdGalujEfAc25j/SuQdsAJs5VZq1u/Qdgopk
	qWC1/xkdHtEp0fc/0u+4RNf7ZNbi4zqAQjQlY8Cwp6L0CXFDJf3Vot3Ao0LIbtJi
	+MvyilWS7GO3rRogHu9WeHbpYlx24/5LrDR7QxAe9IS8o4VT+eZkjr/XGu74rktq
	P5XfguTjQgmR0Fx4+7nGt7CL2Yn+90VtXIr55WlKgggRPs9awPVhbDOeWveTRezX
	smChVQZyG/uXiGIbtFkwcRNMVW03bVJMp3ojJQ6ca7FbQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sKNrmUDWnHWZWY1i0KjLBXn7dAZpWbL815JlQaaAWjU2Bphph7GgqNvyk/PhE5ranw3Mdae+ouvvSuURwDaBlY6XgBd+HWfE0wkA8j6KiIElxmHBqNS0IkdhSCvsZel1Lk+H36NgPo503vNn9g/zuN53R1uYp4+8+L4snbbc3s/oEaMQDs4JOPM4bkCs5Dfzap0AwWrzvz+CudbIaR/ZC83a0YXFl2y6bR09ADvXh/Db2I0wDNBCpPBLkzocwonSNUAISw21ZUtoMgdKUkL36xb4uTtLLKA6iojd0bpoLuZPIleKlxudtv1/SqgfX4Hkq+5h/BsmiIriYzxyzekDzQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nrHVQBAOvOe4C0Nray242RigcP7NARuM6TjGSPzA8es=;
 b=oHPXv3Az1goPHoM8LrJizYDOOobRa6XT7AruZ106zkSbk0CRp9nH68piXBO+p0RTzwaDBCwxmc5maeLiUFu/fa7CgFHUJxKvxBhbieKj4+VvJcec+hW7hc9jPCYiJs4XBzM0K9d/Xx+FsQ3IMCAM720z+0ZGxuMrxaiqF7iQVeGkahB3soR9+5WQAfllLlef2HYvKglSejUZSeCatVqK81Z72zG3vbzvGENGPuxCmQXk7m8i/TgX38BMflbDjzo2UC1MWt0t5rrbWmZvtXYrJ0NZi86hb0IPZcPHci4qTr00I5IyRLA3MuJegdnzYU1vHeDMJeaMYx0WuvywcX7U/A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nrHVQBAOvOe4C0Nray242RigcP7NARuM6TjGSPzA8es=;
 b=fKQb1gWqG2S9r+wsv8swqaBMOL/dHOA/Tcy2Fgm12+GOK0zqYW0YM4mR1Xkh52GI6f2F/sHX/FAj0/PdMNeV3ZZ0RerrJhAqHEJc4oQZbqdNGogm3hswf7iK+Vn2EApXzCTi0pmmFTzGfL0rE9mhDhNnVuq17jEYCxqH/rcbnTI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=nrHVQBA
	OvOe4C0Nray242RigcP7NARuM6TjGSPzA8es=; b=QXa/gMgulDaXr4eEI75f+ym
	cSxjQN2MhBM3RQ4y9ZBmzpKweOCX+4459FKvoCCrG1MQtbO98sEVJVKCdpXQg/tn
	m1B+uqEbGcTV3R0c9QwpZRh6GKp3pGLLhaOtkLUlWFzn8g2kwf2Q/q6TqHoVWM9h
	oxjno9aHfA/XHoKBqsEHcHYMAovNyEEJlY273zyfV+fnErJmP36DQcu7u0lWAjJN
	9YTducqBnPZOF6unOk7vKxuiSkKVpMyjxzwIDXLQsFbOWSWj8uw9iowsTMRASA65
	kKHhap1llF3Wj6Jufduw4XjdCXd/5lDveRTKH7vba9t3LD4oDEpHXe59hhtlO1g=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=nrHVQBAOvOe4C0Nray242RigcP7NARu
	M6TjGSPzA8es=; b=NQgAzBjKWopmvc8JxNdwdtbC+ZSaYrw2aju79mcVh4nuNg4
	oHsKUy0zHP9KHant0JnxRjL+gdHIR7/Aiwg5JbskBNA/xuMn/o7pxwO6kZMBmmnn
	HxwL0iheVFMPoeQUlO9xl7J5mvJbBqbpEHPxdDjYm325WLyVM6VzEphOb6F6SIZy
	L325SdabhttyEpXcu+9zv9JzUvutui/ygHROEb0XvLGreGNH6KF4eqFQjmsa/yA2
	BJ1g4eV90QCyfDYYq26ggM3JO25CqTejknrz1yusWM5nXZJAnnFylO2ckZJS2GVk
	2gkaShuQs6Ur3bM87NjSeUI6eMWkE+sIvfDWIzA==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: q0HkwQP2q1Fglq0Hlw8Pe8
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2] acpi: reboot: log reset parameters
Date: Fri, 31 Jul 2026 20:17:39 -0700
Message-ID: <20260801031737.344756-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-07-31_07,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 bulkscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 phishscore=0
 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608010018
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001EC:EE_|PH0PR16MB4782:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 33f6b6e5-277b-471a-8af7-08deef7bf49e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|23010399003|36860700016|10067099003|11063799006|56012099006|18002099003|13003099007;
X-Microsoft-Antispam-Message-Info:
	qvu/pqhS2hy2e4uK3sTgFYnuHcN0WuE/iUoFY7wnLjtHV7lds8kuK7Bvzz7C62LLNtqD9+egSBMnVAoHynoAIN5TXq4Muq3Lv3N7QNqDUH66xKiiOW6G1U1TEIQTP+65asGOoOo9QgRnBdPVplebEFt1Y1s+lRu+AyntcXW6KSiW211RlQHeNpazJz1q70e+NNn/z5/uA7bS8iBjVlamaTIsOGH+UX9733jD2tbqCQleRKhnWUJ9GoY/tqyCWETRldELVNVlzLgXEBPoHotjsM41wEj6+3KMgdxP72e1+WndwviNYrCiuGsOF4cp2EPKlgS1wvqzkGNg29PVQaF0g2izIDqMcAZ8KwFSuRO86M1Bu+ROeyLKN829o8D/n2Hoikp/BcqGHAvsj06JAtK7TfCeX/EpkbNMJMLjq/dmANrOa2v46eVgccgUj1UrpbNj6XVSQdZ84z3A746CiGV7JT3/hrNBbQe5D99f/rS/ouOjQlGS80KZclHmkFloPE3N88Ra4DsfMVf09BixmSM+NdV8ZrRlLybEtMxrmPAZRJHV8tSrAm3F8E53xdkPKq/QZv+WJ1PJ3i7rxfmAI4hp6E9GKgATX8flDgnhwWXRWuXlyt9qxsNJL93+k9mZsVAZvSEVUSF5MMOPpI6i7y+32lc/69Yr/owaP1+iKMNcprXksbgmtUIjKk+g7usEkYRQrnTyOuIBnLd529JAAuutMQ==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(23010399003)(36860700016)(10067099003)(11063799006)(56012099006)(18002099003)(13003099007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	/sQyepu2/mDB9xWS/B/6Fj/Cep1DZS5IKomMSnUJbc6SOvYC6de3fu8esqafp3z5xN4SRhuCdDn0SjjFhdkgLbo/VyDnTlw4gYJkpwS3F0JmPLrrP7IVcZYVGgxKqzch0SrT99kf2TUeRasyDDpyce9LVe9v4rYQCVoAkaWSg6X0KadwxZlHm52QAv5sGrTf7G/ns2B2s2m6zrR9Omr5aja8ivz4ajoJ+d1Gm+F/hrbznFCXzQ4RU3CpyY76KpiZHsbbVwYpY2s9HBKoDVUkfdE8+Y+vRTdzMBPHaRBoD94q7XVgW5bQ2HR4TUBC8x+dAUu2sxlPRlwTC/sEQUKeR3uz2QuPhJ6hlUIiS25Kg0uCaBsI54uyqq3syypgF7Wz/s/rl4Wk4IN8PctZE8YBsSTdPBEQ7Xd+s7zrmeCWe5rJa4ysL65kd4UauUU06tGP
X-Exchange-RoutingPolicyChecked:
	DNiIyGVjEqRPhVA9RQaBYILh7s4oufPpsmc86GUjybemmsKUUEDnXhPH8u3U3WhFxrXJ7TShgoFNlALQho/Ek2XsqoRG/sAux9QiixsySp9pCc8j6ZaRgw3MS9IlerPxuSzrRz8+rANBZuULt1NvMtcdm0C9TfXGBIMNP1WsldjRi7U4KClfnzhsT7+04F8DPTHWdr1jin5noWY1bNd+bhzyHIwXiSnm+qq0t/pjwz1Mdoce5WyS0mj+V5pIx8f9tY0sNwzrK62jsM1kOZBKfoLzz+8msblv9sb5Sc7VkuRc4yQyB1+eU05UqzHkySRDP7nIpvDo5XgeK2PeJ0JQUA==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	LPE6jDTwxRcWrqX9PavanlZWmCQB1gHgnMQUENITdTipweBo0a+UzEF/ZPYTHwOsb6tyNGUrnKDACwsQFenGYL8869cQu1sjZnQt9hCoJEAe1v06Qky2gZ69ViWFsiCBwnSmPf85/uOWErlTWqYifmDBVSkaDDdh2TCrZgoipnbzVYMEv6vlUMULkHKeNgCrJxzXoiqTVOIWWzap4R8J/8RMD79mY33jWV+PAXfSR81FkU9QuEIMsdVOUUHjmpihDvg60n/LPjpXF9RGOeT7/hVAQT2V+pohhl4H6QCNUruH0y3+qF2JKik98X45CItLmKyU7VX+PUR1GkMLdfO1Fxw9azGLMbvUzWP5TlHyDgMP3TbsnOQ8MSsBnkqCE7MoILnQAfU+JcwDQJUDjp3Sz0UHBSOASTHeGl7kQSDuFdnHijEyHi6cANJiPOGSbXmgPViypqfzZLDxPqBioSolZe9upfmmeffQVri7638bpBIOgnXHIe83iA3j6eviGirsotTfWoubCcNw7hd/ZHW+LRUfPi/EafQd5DeIjRcB7mA9FBBAoo7DuzTSGSoSEaEZnWFGUGs5cQWUTGP3/GgvnVU0E24v1zA2n/benHj81Ygcu++sCt3MsdnBnjd/LMcI
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2026 03:21:19.4573
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 33f6b6e5-277b-471a-8af7-08deef7bf49e
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001EC.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR16MB4782
X-Authority-Analysis: v=2.4 cv=JKELdcKb c=1 sm=1 tr=0 ts=6a6d6636 cx=c_pps
 a=AgKHDJP192gAOy1PpHj/Qg==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=WER9OelvoqQQjwJToBYG:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=g95BRj5zbggsEhE0B_YA:9
 a=3whSkbs7g9Me0DR5EJEX:22
X-Proofpoint-Spam-Info: AW1haW4tMjYwODAxMDAxOCBTYWx0ZWRfXy3WZPTpyA8e4
 j2uy1w2Wtuw1UsVDMePp4gSNiJfUjXdT3ZW73Txw2EdkXt+XGXxq1soymtEBFXcrZ/t9FasS2Wr
 0Spw2YYqD1Z5pxTKUsPt57L+RMSLUPQHA7jzECtZKa4rdPIqFl/T
X-Proofpoint-GUID: HBOzySsYY6Ko4OLg-HpNQ99jWO0CiZ6g
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODAxMDAxOCBTYWx0ZWRfX2xf5fNI4rdu3
 8NNTu0b3BOofrFJorjh7c1Y+5jaBJm7EMgI0xaSXQWdv5QuVauQOOqoSnG6AX/HRKicc8Xs+J12
 ZNktjbci6F05Q1XrFtwiMSmlsv2i/nVU4ixCnXSzHBPaDD0IFQNcvu8adKmobq6HfPk4MBHiiJm
 aUXB4I4R8OUE+poH8oaabnpqa7a5ASw73yWyei2uRTH71JtvsqvZG4s2K4nE9AEfsFheliQdxiU
 tLwmnX+yjHKi5+JC3bX7qJndtU8Ybcpc2srw77ILTrZuSlkNH4otgsMbGcLPAAXVWXoYWNhFioF
 uHE7hfxA7G/8DvF6pxTssW8iqVxOmMeM+Cmk20Gv56083iytIfvblC3Ed7DdyOzL82/RuGk+vPI
 1WsRqYxailJNw0/9axn5MyntrMYAwtkrMw9dONFdfS8to80Ij5I1PzIhYOzrxlSmZSBB5xDDiO/
 xzcZO31w2gXv/k9bsqA==
X-Proofpoint-ORIG-GUID: HBOzySsYY6Ko4OLg-HpNQ99jWO0CiZ6g
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-07-31_07,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 priorityscore=1501 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0
 suspectscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 clxscore=1015
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608010018
X-purgate-ID: tlsNG-33051d/1785554488-6D4D74E9-B2CCC98C/0/0
X-purgate-type: clean
X-purgate-size: 2418

From: Denis Mukhin <dmukhin@ford.com> 

Xen does not provide much details for system reset debugging in case
system reset happens via ACPI subsystem.

Log reset I/O address and reset value.

While here, add the missing default case, add breaks between case
statements and drop full stops in the loglines.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
- v1: https://lore.kernel.org/xen-devel/20260730001854.905354-2-dmukhin@ford.com/ 
- CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2723268852

Changes since v1:
- removed wrong ASSERT_UNREACHABLE()
- switched formatting to %#x
- fixed indentation
---
 xen/drivers/acpi/reboot.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/acpi/reboot.c b/xen/drivers/acpi/reboot.c
index f6345be8749f..dc5671f9b42a 100644
--- a/xen/drivers/acpi/reboot.c
+++ b/xen/drivers/acpi/reboot.c
@@ -6,6 +6,7 @@ void acpi_reboot(void)
 {
 	struct acpi_generic_address *rr;
 	u8 reset_value;
+	pci_sbdf_t sbdf;
 
 	rr = &acpi_gbl_FADT.reset_register;
 
@@ -21,17 +22,30 @@ void acpi_reboot(void)
 	 * on a device on bus 0. */
 	switch (rr->space_id) {
 	case ACPI_ADR_SPACE_PCI_CONFIG:
-		printk("Resetting with ACPI PCI RESET_REG.\n");
+		sbdf = PCI_SBDF(0, 0, rr->address >> 32, rr->address >> 16);
+		printk("Resetting with ACPI PCI %pp RESET_REG at %#lx (%#x)\n",
+		       &sbdf, rr->address & 0xff, reset_value);
 		/* Write the value that resets us. */
-		pci_conf_write8(PCI_SBDF(0, 0, rr->address >> 32,
-					 rr->address >> 16),
-				(rr->address & 255),
-				reset_value);
+		pci_conf_write8(sbdf, rr->address & 0xff, reset_value);
 		break;
+
 	case ACPI_ADR_SPACE_SYSTEM_MEMORY:
-	case ACPI_ADR_SPACE_SYSTEM_IO:
-		printk("Resetting with ACPI MEMORY or I/O RESET_REG.\n");
+		printk("Resetting with ACPI MEMORY at %#lx (%#x)\n",
+		       rr->address, reset_value);
 		acpi_hw_low_level_write(8, reset_value, rr);
 		break;
+
+	case ACPI_ADR_SPACE_SYSTEM_IO:
+		printk("Resetting with I/O RESET_REG at %#lx (%#x)\n",
+		       rr->address, reset_value);
+		acpi_hw_low_level_write(8, reset_value, rr);
+		break;
+
+	default:
+		/* Fallback to alternative reboot methods */
+		printk(XENLOG_WARNING
+		       "Resetting with ACPI method failed: bad ADR %#x\n",
+		       rr->space_id);
+		break;
 	}
 }
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Sat Aug 01 08:08:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 08:08:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379842.1624218 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq4lK-0001nz-ND; Sat, 01 Aug 2026 08:08:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379842.1624218; Sat, 01 Aug 2026 08:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq4lK-0001ns-Kb; Sat, 01 Aug 2026 08:08:06 +0000
Received: by outflank-mailman (input) for mailman id 1379842;
 Sat, 01 Aug 2026 08:08:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+2cc0adfa51115fa75613+8378+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wq4lH-0001nm-MI
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 08:08:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wq4lG-008eqK-PU; Sat, 01 Aug 2026 10:08:02 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+2cc0adfa51115fa75613+8378+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a6da934-bab6-0a2a0a5309dd-0a2a450a816a-34
 for <multiple-recipients>; Sat, 01 Aug 2026 10:08:02 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+2cc0adfa51115fa75613+8378+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a6da961-f2d2-0a2a450a0019-5a9b322283d6-3
 for <multiple-recipients>; Sat, 01 Aug 2026 10:08:01 +0200
Received: from [2001:8b0:10b:5:784e:4057:b43d:bb6b]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wq4l0-00000003hNc-3Aw4; Sat, 01 Aug 2026 08:07:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=18bIdcOeGSTwG3qH9s4I6NnzfHA4VI/ZEO9zsxictiQ=; b=keOR5QrpcT3tMBAohjjaUZz9So
	2846u95schqlk5LuRQutlcPQXxNmIrUE0JXY0TCc36e/2lGCX737H+8lis2ylsMEcjBN6wGLjSTCc
	0El67Eyc8eR0xLVlj2nt/Arft+RO0sfAttqftRvlrdcGvsvlk5s7kznZo6DMJIRdhmIaXZMMtOglg
	DKyWmovB9dCR7acS4cD8Gd0TMLMgUEFFDfwswlxFakYgWXgZuVAREXhXjY/iQZ+lH94yu45PqBChE
	HQwrWXJJAC2mRlKWeXXr02DmHShTFiM1hMmpT5tR8H2j9dcsOehYbCuKXkjA1u/ZPQVKrijIpAFS3
	eVFs87qg==;
Message-ID: <d2d98dd31718eb925ae44b0eceb325538a8174ae.camel@infradead.org>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Sat, 01 Aug 2026 09:07:46 +0100
In-Reply-To: <am0upFND1r93HPxq@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-32-dwmw2@infradead.org>
	 <am0upFND1r93HPxq@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-hhE/NFLqzUIzrpVlTdn+"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-4011c0/1785571682-510C9CFC-EB7B0D2C/0/0
X-purgate-type: clean
X-purgate-size: 9637


--=-hhE/NFLqzUIzrpVlTdn+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2026-07-31 at 16:24 -0700, Sean Christopherson wrote:
>=20
> > +	/*
> > +	 * Allow for a discrepancy of 1 kHz either way between the TSC
> > +	 * frequency used to generate the user's pvclock and the current
> > +	 * host's measured frequency, since they may not precisely match.
> > +	 */
> > +	if (user_tsc_hz < curr_tsc_hz - 1000 ||
> > +	=C2=A0=C2=A0=C2=A0 user_tsc_hz > curr_tsc_hz + 1000) {
>=20
> I don't follow, why is KVM restricting what frequency userspace can set?

Userspace actually sets the frequency with KVM_SET_TSC_KHZ. What KVM is
insisting upon here is that the input to KVM_SET_CLOCK_GUEST is
*consistent* with the guest's TSC frequency (within a little slop
caused by different host TSCs).

I think the comment above it is fairly badly worded though ("host's
measured frequency"), so I'll fix that.

--=-hhE/NFLqzUIzrpVlTdn+
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDEwODA3NDZaMC8GCSqGSIb3DQEJBDEiBCCx6LFSi3mTZHte3UKbr1SYwMC+1Sbx
fqXVt8jJ3ebHRDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAYgstmq2fylz6eE4M82Uj4rzKYdzkSNcnWI+4Sk7ckLcTx+hEckGL
lcM2Pd04AVNbB/iuyw87C+1kW/34wEBPZ6DdFE96NDTX0Vfd01vAhmASua0Os46qt7kNcAgQ696R
HQZstzHuiZ8V8cnIR4tpaVtOXV9hsKhkbSC/1WZCTH+zgeMHwzYgq81HiD1sOmwWeq3LZsoggZF5
MciAGdU3DfY5QTXzXX3inwM8/6HSfjDeSTnEj8duWYQ+p2CwNuahtFGlECr5offONE1+RJV2EsXz
vJTTqwNWuJXuf9enthTtTuLLIhi93LyLKJzUzarGQcyHgjWUfLCn0YGLAapZlF6gFjZdp+PSObD3
oa8jwHXK+kp1YIEyBmwPpDNRs7RQvkCe65lv+CVd2HzHNCjDrL1MWzqBog4dALOrdhZhLsZ1e48t
lQJvp04HDSRCwrLsizwDEf+eGjQnc72V6zowxgZLhyXJoq4pISKTsWHqGww/KyD0VqkYuNxkQ98M
sdd2FIN9NV7tqDAxLt8L9NiY06n0plgyk95JgtGOtevUoD/0itCiUUJ9qSGx6oQ6g55RTuws2HhH
Ijwxk6xZgxdWCb6Pmr2EQnOe/E5djI2HIMPjRtag03cXP2pAW344YBQvSkQRWfiEGdFk7kU+3qRc
H5lnUq64/yTq6jmeC4zkY2MAAAAAAAA=


--=-hhE/NFLqzUIzrpVlTdn+--


From xen-devel-bounces@lists.xenproject.org Sat Aug 01 08:39:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 08:39:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379857.1624227 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq5FC-0006QO-Bt; Sat, 01 Aug 2026 08:38:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379857.1624227; Sat, 01 Aug 2026 08:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq5FC-0006QH-8X; Sat, 01 Aug 2026 08:38:58 +0000
Received: by outflank-mailman (input) for mailman id 1379857;
 Sat, 01 Aug 2026 08:38:57 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+2cc0adfa51115fa75613+8378+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wq5FB-0006Q8-1s
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 08:38:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wq5F9-001UbZ-TY; Sat, 01 Aug 2026 10:38:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+2cc0adfa51115fa75613+8378+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a6db04f-2eae-0a2a0a5409dd-0a2a4508de7e-34
 for <multiple-recipients>; Sat, 01 Aug 2026 10:38:55 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+2cc0adfa51115fa75613+8378+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a6db09e-f659-0a2a45080019-5a9b3222ddfc-3
 for <multiple-recipients>; Sat, 01 Aug 2026 10:38:54 +0200
Received: from [2001:8b0:10b:5:784e:4057:b43d:bb6b]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wq5Ey-00000003jTv-3gah; Sat, 01 Aug 2026 08:38:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=RmaoA/bE6iZHtJ0us23hNByggU40JWjLRZegqTIvQPI=; b=vQasd3OR46RhN5KQUpGQADF6bW
	+2c2nY5mmQ1ulxEFUgciJnHuT+vVqELlROSkKpdtnyAVQXispOa7zBqnCRAHCARNVKsSBI8q4cDD+
	q06S0c/9hrZ1sFmFB52Ppd6cgwderqAXpGFQh+o5oE0hkb5JpUcQPMBZOr+uJvIamKup99id/gis3
	2xav0+WJIn+qUmtpTrGUsGU1xCgc/k3m7pdakbOJapFPtJptJ4Y7ERj662DVDQmiFMDrX0mn+QcmO
	EbCNQuEfDPviupojz10DBBKE9qABvEjYNZT6YS0ZifMB+3jJFF1hptMLxOXK1XZw6Pvd3nlS7i+kf
	RRwqHUlA==;
Message-ID: <8b90851f38ef5b10cdcdc70e7543bd6b0b5e2773.camel@infradead.org>
Subject: Re: [PATCH v6 00/36] Cleaning up the KVM clock mess
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Sat, 01 Aug 2026 09:38:44 +0100
In-Reply-To: <178552799129.2700794.10181439022561913222.b4-ty@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-n8Rk3MbvUbHa+AO2Y0Ay"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-c1860d/1785573535-CEB4187B-CC5963C1/0/0
X-purgate-type: clean
X-purgate-size: 9868


--=-n8Rk3MbvUbHa+AO2Y0Ay
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2026-07-31 at 13:09 -0700, Sean Christopherson wrote:
> Applied patch 1 to kvm-x86 clocks.
>
> [01/36] KVM: x86/xen: Do not corrupt KVM clock in kvm_xen_shared_info_ini=
t()
>         https://github.com/kvm-x86/linux/commit/3d4b20b5a7df

Thanks. Could the clocks branch be based on something that includes the
timekeeping work from the timers-ptp-2026-06-13 merge (in v7.2-rc1)?

The later parts of the series depend on ktime_get_snapshot_id() and the
reworked struct system_time_snapshot from there. Your kvm-x86/next
branch does have it; I'll keep my WIP kvmclock8 branch based on that
for now as I address the other comments.


*   2d6d57f889f3 Merge tag 'timers-ptp-2026-06-13' of tip
|\
| * bc484a509673 ptp: vmclock: Use hw_cycles from snapshot for precise TSC =
pairing
| ...
| * ca1ec8bfac8c timekeeping: Add clocksource read_snapshot() method and hw=
_cycles to snapshot
| ...
| * ef22786707e3 timekeeping: Use system_time_snapshot::systime/monoraw ins=
tead of ::real/raw
| * eba302268a01 timekeeping: Provide ktime_get_snapshot_id()

--=-n8Rk3MbvUbHa+AO2Y0Ay
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDEwODM4NDRaMC8GCSqGSIb3DQEJBDEiBCAso9YgR/k05/yJ8iZRqVjWS7kJsmyC
4WAIPhpvsss2dTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAdAvGOIdR3Jym1MBnTKyIkb7N1sSz5Vej8AU3UrA7wQyFFV+xxt+W
U4+JFtZ/Fi5klcY9EzNDudfDBWhyon49IkXMD+S7082yR4+xOttX/b1DnZDcgkppOpUUjl3LbTeB
TyDLay066nD7PRf+LbW4aQJq/8o6ZAP0toivg2yaJlOPSBtqXkgCbUSAWvXwM0N4f02Gfc7AS32K
6xGoc7OkcR3HVB/v11ESFFstkri9pIkxTlqKUeTu042PvM8aYc0I48LdzjbnxgpA/FoJ3OBqb9WK
nPc8jYH6Vna1CKV012j2/vMsCBKaxflX7LoCSL9o80CfJ1TN/RRst8IUBScdH0PfLKs1L6Ueun3+
1lE+TR4+lSJH1hMcq/MUB0cKpdhY45b2CV63E7jgvEzvY2UpJpTv9vQ+faTcsO7cWQ+yWPf8LZqJ
Lpt6CFDkb96sBQTo1KuSWBsrqcixjynHePxls5aJRN62LJpi3gAR85/caH53Cr/jVj51/p0a86ga
U11YtBGy1lkCecUfGiftwY0FQyXcyEqTbl829EhxNQhZOvGUKBAWf9Wt8AQOBrj1d8gNKTazslyN
nAvZhMNEbG3c4G6IqJOy1JT/LjRRpwwQlYmaBgG5EFLhQgtiHuxdyB4ZEFT033Rj0JaWnRf2q/lZ
DDryVrM9D3j/jkMsEszYe1MAAAAAAAA=


--=-n8Rk3MbvUbHa+AO2Y0Ay--


From xen-devel-bounces@lists.xenproject.org Sat Aug 01 11:51:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 11:51:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379955.1624238 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq8FW-0008Jt-Od; Sat, 01 Aug 2026 11:51:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379955.1624238; Sat, 01 Aug 2026 11:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq8FW-0008Jl-Im; Sat, 01 Aug 2026 11:51:30 +0000
Received: by outflank-mailman (input) for mailman id 1379955;
 Sat, 01 Aug 2026 11:51:28 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@netscape.net>) id 1wq8FU-0008Je-DX
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 11:51:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wq8FT-00EecW-QQ
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 13:51:27 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6ddd84-bab6-0a2a0a5309dd-0a2a4503971c-28
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 13:51:26 +0200
Received: from [98.137.64.82] (helo=sonic305-19.consmr.mail.gq1.yahoo.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6dddbd-fae8-0a2a45030019-628940528cad-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 13:51:26 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 11:51:24 +0000
Received: by hermes--production-ne1-6f6bdbdd7c-jtc22 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 2c6e9c6518a5b71581c74d9ac6047a6d; 
 Sat, 01 Aug 2026 11:51:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=netscape.net header.i="@netscape.net" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1785585084; bh=fuiv5o+ZM6uC/qcEX+Tzmuq7yIkIt71ND7aoktB7eoE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=RzrSTEwcS6DdKfMZCyRalp4+SYc+zLSn8i0BDw8EJ+IqKSwtQ1YC+E0i6jvhUQoITreHxMMhubTFv4mH2Ap8VX9CbBDfZ8NXyBRuoneFABkpJc1reVMd58iEZhNqnRaCczrNAsZtt8y/9qGKxgvfyix0Eoq+rF/553X9Xro36R6GtG0EQs4Pk0Sr+HpKaRBMHd5ejBk5I0Z6BXRzF3CR7IeWCOM1z59aMWsBuXmNtZ5vFFyTqivcQ+zUChOpac12c+UqItZv1Fq5D++lAGwk+9PolsLHWhBq6sgc2nTkiy6EmfoCV9EWxlJhBUnZVMwYaJIfcEQ/JDf0UX5IQ0V6TQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785585084; bh=N1KTBtU3ESCjUWEFdgsobkxQoc0Bd7zyUuVx50lfR4k=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=tCOVNGsXenhDGDx13ti0hjjT5Fs2Z6Mksu2Gftu24N4xBrQi5XSgDRMFcvp//TNG7iGPuWZd2P3RwTUOAZAqtjBa2X2NHEBr7YVLCeH2nkOYsTswBZ1353sjNFHKefJ2dBelpLB+tDIT1P8s/IbC+hXJRG2jYxsU//oyovSNKCsBQCELHot33BAUB7bXG42NwR/Wze15/sVLeWL1qSLUwPXrZ8To8kp6f5k1QBdmofIE5sAvTLTky4woa7a3vzxJiIxNygE70jwUCZPhkojEUH4DFPWsqirUqPhYlSjsYsDs1re1oKjFxpL50dihFJ4KarLybkbkm1cIIch5L1L7uA==
X-YMail-OSG: aKsnXoYVM1msTfRexnj39EqPGrx117cWtsOWgBMvH8i.wtCxTTdrSq.xKjIGhhO
 8lTaENnx.Xo71QG6aCfadwl10j5BWRCUFbZEmBK8nYFnJZPGqjzykIdoVlFJkhPgS7dO63IARVSe
 hnMAnDINxz9zG8vu7rUw2QIK9Xf7AcWXeuAMA7bSoKauxYxW9lii_CUX5t887g_wPE_dQo9SKXBF
 Yg3DWRVLAGXozWK4kXSr1OeSkNQGesu4y9tQ1YPKzy.lah4ydU7YYJ0Qzw7nRRHAT955kteiHpJB
 O2J3Wdd3ZzPsS1WgFA9rU7cq8UUSEdVv_0UCbxFlb_6Phzqa52c8Rd8w4zka8TQhirkXjxeqWGgC
 PfDVuu21XHzEoClVppiJdeYPi4oymsTjEbCuWpsuTkY8DDLuN5KBX9YZC28PsDniiiip1NoH5a4_
 NBiVYKNq7yRvnNLGiEbKdzeZ4u.6A1oDK25PH0AxbntTQisb8B10lp3j02Df_E6xp4N8Qzwa72jY
 duJZv14j_26ufz6sYMbknq8HfAjdXna9sd7W.ezfzqx7Np574d76tdlESBD7xIBdCSMV8hR7b70k
 qaSYI2HWBozE9Lt0DvXBm0AK6eVeGn1u9BVcxBiKE4emHqSvdtO4AELZEpLksHCIb7WzGWyipR2J
 1Nm4gRF6IFyyLBxLK94NbZA_Vfs.KJSkL_AMpj3eAK.lBnvDcU1zqVrmyBCG2Mjgkn2UggHHyhaR
 4RXSjRYc.R8194Q9N3_Fnk5PFJh9wv_A41hE3FgWG0LcN8CJR_YsqquLMfz9xEm7IcKqmylpoK33
 AHXzR5nSsR.0xsC.A9McnS79jd2X77yu0zX5rhec5oSjxR9eS46lZJ3Rtxpi8mvRnHskGfKCkER1
 drpBotZBSKUy911Q81Yf4YHRF.KSIa68On7FVAJGyGlIzGRoRsUbJnjXeZqxnIE7vOaNHo8uf_QQ
 xIgtGyDAPe2hSf6OEUhUDVL0lpIxOsSQ70cI2PfYNezQ1KHk3.HGH6shG3rZWZ6mn0IYRtqPktFF
 LgFFwwwK7FmobjmNT19pvsUv8C0EJ_588HWu38pBwSesiDWM.Rja_m4CHfNVBDTE9xj06yW.GfjF
 8WZf.HwaSVvE4C_MpYKm4DIURVWq44GwjYJzwgiLCQKlKhFfzXKVAnsQgKCr9gdg7NlHifqve6h_
 MtOlBADM9Lawz0A9XYGhQ9vwvZjkIe.ae_s6nDqYMNi2AwOpLgrPTDgvukQmexdym3tx7Elpz9vF
 qtiQUpOarTaXtGaec3879KS.e.CoD3LkwWX28b1sEuwuxQOX1GCaiJYgV9hRIXrK9xZ56iV7MciI
 ORNQUdBt27x2zjlwwhyYCBRgLw7tTG61fGj8y9OQmfLskMi8nwtzDyH4M_eLLPgXC6TdvhC3ACbf
 ohN05lM.10W.u5mVmnUopLpl.8z33pOLEqqaQYIfQcIuS4TEuDCbY9z.qBvhfRBvH11EjtG77n6T
 D5Tt0iAMyw4MyvzgYri3ffFMG_sSzgBPAAlx85U7jcDooFaUiMFajhiBnlXPqhAYgpsEQnkudmJ6
 VKV4a6T9m0Fzr.CEII_QtUOJC9vTNly3zXYz2sdkMeJtcgOQv64hurf4qbsv0SZBF.ohrzBziImy
 RcfHR2oY9fnTxuRzZMtjZonw9uaTfXkmnwFMZ1d2Ln.K7OHrFo3J0ZbrTQzpH1ODkudlLkO6yfLM
 0W1nIl470Fyl1oLUajyErKVDdp5wg47TzCmtqgrNotvvrl.IDEP3BBFvI.4iyQdSbMH.1f7rjKtt
 ELkUF4MQ3Ey_4Jw7dtJFwtJ1iSdbk_3hENT7LcrJKztteNQREAr5PEJwPx2mQDHaOX28y8Q7X1mR
 2nHLW8oeNxwKD8wNhM1BxLNJ1fysYkWDMVGjCd3u0K2kpYvuCEkyJCnmIofToOvHHhoK0TXXIIXc
 0scGm5z2JvQCXTZpG75wKaFd71l4ykoyNdK7tbs8BqL2F0_lEv0gxnhgxoeyuHh.hjqv5ncyunKT
 JyDOuGV_Ze2_sPIcQJUSIj7EHOiKOxK5C1pE..VP9gE28WCkTapNCpmxgU5mf1yxmD53OAazKudJ
 R753iIExk0QwgcKhQL8YyX1q2vFoHOeiXpPAH6RemvB9XQ26Pzwmo8R23nkVhD7GW9ntvJ2wJabJ
 IT7vxFkCTAlqVQq.PWsw8MO6Zsr3M6g65YYrKD2yARUoymbqYhHYK9ohd0_RhF9GzXDSeIhhkcwE
 oYn6aytZTzy2z1Yivb0zaqBfRGbEBlbHYxM3hIA1D0wHq0EdXJgc.G4CjL_YVO_h5
X-Sonic-MF: <brchuckz@netscape.net>
X-Sonic-ID: cf8f62cc-639d-4ae9-8f4f-fa4e168ee8ab
Message-ID: <1418735a-2ed4-4f89-a9e4-631f5423608d@netscape.net>
Date: Sat, 1 Aug 2026 07:51:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 6/6] xen/igd: use custom option ROM if provided
To: Chuck Zmudzinski <brchuckz@aol.com>, qemu-devel@nongnu.org,
 Tomita Moeko <tomitamoeko@gmail.com>
Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony@xenproject.org>,
 "Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
References: <20260801001737.16509-1-brchuckz@aol.com>
 <20260801001737.16509-7-brchuckz@aol.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@netscape.net>
In-Reply-To: <20260801001737.16509-7-brchuckz@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26215 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 1447
X-purgate-ID: tlsNG-33051d/1785585086-770F64E9-F4A491CD/0/0
X-purgate-type: clean
X-purgate-size: 1481

On 7/31/2026 8:17 PM, Chuck Zmudzinski wrote:

> 
> As mentioned in the message accompanying Patch 4 of this patchset,
> the official edk2 project does not provide support for the Intel
> IGD, but some OVMF patches for Intel IGD support are available
> online for KVM/VFIO guests, such as at the links below (they apply
> to the OvmfPkgX64 platform):
> 
> https://github.com/cmd2001/build-edk2-gvtd
> https://eci.intel.com/docs/3.3/components/kvm-hypervisor.html#build-ovmf-fd-for-kvm
> https://github.com/LongQT-sea/intel-igpu-passthru

And also from Tomita:

https://github.com/tomitamoeko/VfioIgdPkg

Thanks, Tomita!

> 
> With such patches it is reported that the passed through Intel
> IGD device lights up the display during early boot from OVMF
> and the guest bootloader in KVM/VFIO guests provided that the
> administrator provides the correct ROM file via the 'romfile'
> setting for the passed thorugh Intel iGD device and applies
> appropriate patches to the OvmfPkgX64 platform.
> 
> It should also be possible to add Intel IGD support for the OvmfXen
> platform also but I have not seen any such patches online for OvmfXen
> and if anyone knows of such patches online I would be interested to
> be informed about them. I am also working on my own patches to
> add Intel IGD support to the OvmfXen platform, in private for now.
> If anyone is interested, I can make the work I have done so far
> toward this goal avalable online.
> 


From xen-devel-bounces@lists.xenproject.org Sat Aug 01 12:03:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 12:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1379972.1624246 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq8RA-0001tf-ST; Sat, 01 Aug 2026 12:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1379972.1624246; Sat, 01 Aug 2026 12:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wq8RA-0001tY-PH; Sat, 01 Aug 2026 12:03:32 +0000
Received: by outflank-mailman (input) for mailman id 1379972;
 Sat, 01 Aug 2026 12:03:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@netscape.net>) id 1wq8R9-0001tQ-BB
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 12:03:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wq8R8-005qb0-OK
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 14:03:30 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6de084-2eae-0a2a0a5409dd-0a2a4501e058-24
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 14:03:30 +0200
Received: from [98.137.64.147] (helo=sonic301-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6de090-5984-0a2a45010019-628940938312-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 14:03:29 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Aug 2026 12:03:28 +0000
Received: by hermes--production-ne1-6f6bdbdd7c-w9xxm (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID ad3319020c74423f6b69925ddd631e52; 
 Sat, 01 Aug 2026 12:03:23 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=netscape.net header.i="@netscape.net" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1785585808; bh=W0MydP2oUX8/HYVYaoYYc6r8/esVa87AQ2CEiLLTU1E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=ffC9Ik3graT2CJhW++p7INhiiZEAHJIgo3bsG+g/reKKr7HZ/P4uyycCyMpDguWtYS38lLy9zPVLhB5RVYfHLQn86SacE1qCWbjmrdRH8H6NYE3iBqQ8Mhjc0U/LfNXdXuTs/ks5LYZLgOUfFWCNudc/Fh5Ad6OOLDgm/jv8KtOS26ttk2qzBI59+N4gCbbc48i3vJ/dKAcNmgMxKrjImk8jDZlxMjTKo3FU080qFYj/++60OOF1u19i6DIQRIsQ6zEk91nOnfXRB+8FToYJdsPktyZnxKiwwXBf3s5h4tHzHv7mPsy5WZN6SOUlX7goBlGWRpj6g88Rf8HF5lptVA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785585808; bh=VA3wADtmLWVH2/OEkFO9nIiNxhVsfZRpcgwrie4z1wo=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=TumVOIKNKpXhAVJmMPra0bLYp46neYIUct0hSGptSSiiP03izywkag8iVlv7cvg64oh9NqVpbsTq1SbDqSHaM/rnZy7u+/GFbqgAV46CpILoy8iwNNB1U/3znf0vQIYT1dGIlVGqgk2Lq5JndZfo1kd05515Sm/1iZMPXutm+g2RZH0yiYwjc3RLbJ2uXs0OJJ3VtGKqqDREuhijI0lc9BnavX5jCQLmeYhGgrxQP2fjo3schk4JrS9Jm55fkUZ7q4dU0feMwExuLWdd9HoYa6TQXb83wewLZw0LP/7fulU//MmRM8yrh/haRHjUH4zvwC8UsEmEU0xHmZTQJj657w==
X-YMail-OSG: 7AOkLyYVM1nc0L2KIboVCyc2u3fUpk01ULdAuHHVXgEIrgHjs_utYiXQ7Qhf420
 VT5ESB0Y6XHjA0QySs7e_CVe7JDA8XhV8k0EyCXUUDWHIEsvHsSzeajILGXneruw_uOJc_KgGol_
 7kyGnFb.8NtPYUWKyISUYzLSklmnE8pkyNgwODg0QdjVcDQD4LLGHVEGLpnRdGlxO0OWrJHG9bWA
 MfOID75l5SZ7QYmQvviM38Xx2jrjcPzqtG.LRZRsGdST.nTLnAkmf0J2tZkUfcL.qyHJXGHqeHT0
 DS6RG1elXwk.VYT1TyxR94EIqfwhcXST5HVjEv2azWmcQ10Z.q.EZ1nyAIa8dJ0YPSfr9HHS4R0K
 bX9MEEPiUUFd.Bb6Ba8LmSGpnZ0g3zke7Sp0dtX0p7jn3KBUxrdo89331srrIz.JhSdSJLdw9_0h
 DRn1bD3C3XySL0Hr.8rGMcOnBXJ6LSBYXYJTynxmOlmO_3JOFJ2ZsrasmqFxKl_6xHjUDCvRskm9
 zbwA_bLtxZUcw4F.4TSJrEsAuupNxqBu1IFIpl_SUDAAXvbk9FeAhAiHronBFsykkvr0RTlKsPSj
 h1OnB3xmCY_uhIyrznnyf9GX_gABBChwlX2wfr9s2ycJ8xNPAwLLVtONMNx5wD9E3S7jmTeEK6P5
 5mTvNr4qMBpCnGnBCvmlADi9Aong2W4lTkCBEU7vUiMfQPzu4QanDZfNJ_fDdospmBGNol3aKc_3
 Z9nacZUYws1q1R3GRsDfgBYLcKsjdNYxiFw42kfQFcDfz.GFCqpVNIOZtYrlVQqKCOZUkvNWJAdC
 and42_N3cqaddYlOuYWMYF0_7SC1aGA1UvH6k7MX1edgDOj1kK8Ue7SB1P90UEKXIXlfqzx8Gd5o
 SmC.Z2kWbzKrfojIOswLtDzRvJneint46VOsuhqLa_sODPQ3INjBzvHXfykwjhJ.I2Cp4A2MyQ7L
 Rvdm3HjHd4wLEeamS9TXJ8rVfLV8bMYYJ2t2RxHus_nELfQpvgu9s_2F8C5n6EftOwtU3SbmSIxm
 Mr1U6Ug6pAnR8N6hRFRBrK3Q9fYD8i5yJzTnq2ZPLwcs1kOPagQE31QWVfGz6ZmBw4kphSM2MG48
 S4Ja40GRmTfKYvNZIQzIlnM03HHw3kB99nk07qTDtn4v0lN4mlUMnJAOc2sIO00c4jZ0zC_lVP.x
 HlUrEb6PI8H.jDPXfKRXCB1.hsDQBti4pfK1.3KoGZXjyryBr8r7EknKFzL_EWNcme2toBjP8W8Y
 2qPYWnV_RofGLsIUtbWwIkWLZU5pvNjEIbkDXBhqp7jBR5_Rb2O90Cvqa5Zshq4loupZa8P_Vt7_
 vee549jbJ0OTVf2.D8gnRPdBrouQ5vR6paWvYNJt5R7YeojbZXC3HmahVClWcgjcqoZH.Ew4lLAM
 YslY7bjVWhne0HqbAOhltpVgtc60dvBMhupgUgEoa7PkgUtUPSqtl6H5J9XPqGZyFm95cg0IGb36
 FGxSBesQKzm4NCD6wWRujxR8taVaIg7YID6nrjlM3aQCElD4E8cvKns1eqWR1sKPeg0NdHA5nog6
 SQyi5gPmDyDG1C9h1cq3LEghD9neV0yJ.sFILIifGsLVIrvDAuVhk61PNArv7J26fOQJl166IaUo
 lW7waRJlvMEnQ0ZdcJByL683UlNSLltQ72bIaxs3wPg4iywosj1o9yXd7Ve1j1_OA7o0mo.fV3AH
 jU_4JnOOLMIbwIEzr3Qg01wC8sUZkLl9GL27Ef5bYAcf5PRtu5tD4cTRRamLBjPIjAl8iK0pAfKu
 NbJMB93KLenZRQ5KYqqEH2KBEEBLG5zsT6regLwEFrs81wrYm_WcohyQf9hJmRJv82DL6SNzXbCi
 E9yGmtHUIKvfGwbQJezNDdXwnoiYE5mnpkFJEqlBMjuiW61rAFRePEJqgVK0SZs2UzZlUDrubnge
 ._sszneJ7fX2LIf42Mx9mOG7BaLPUPelWDcyZFO3RkicjEtU092GENvuXqH2kUmhcCjxZRudSaKs
 6DidXiKiR8tDe9ZIsGdJcW8ppLOM...vpipu3sL7SUkGlxAfQKF.wvstak8WnZV9MHBIfvgxqQI0
 WBYuEjB5C9IU_088XSD2tMGI2YUEHU3vetkXbewC6jvgjadaSu426Q4p9NGKi2_zxe6z7NegCAPV
 TEZ9HDGDXVNM1FnjUNNvGkf_ZAyxMattWPy3d0LBVTlM1D8hzR3wtiACeNtbAgkaMtTdAOtqVfhx
 qsZPZOeRuobdkp6rLtMe1.Ff.19IsqWMq4ekCGo78EvpfZYDNpo.Axw--
X-Sonic-MF: <brchuckz@netscape.net>
X-Sonic-ID: c0652755-41f1-40de-b129-bf55e3b14eed
Message-ID: <7e4719b8-7396-4daa-aa8e-4c4836951de9@netscape.net>
Date: Sat, 1 Aug 2026 08:03:23 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/hvmloader: implement Intel IGD extended VBT support
To: xen-devel@lists.xenproject.org
Cc: qemu-devel@nongnu.org, Jan Beulich <jbeulich@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>
References: <20260801000354.16446-1-brchuckz.ref@aol.com>
 <20260801000354.16446-1-brchuckz@aol.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@netscape.net>
In-Reply-To: <20260801000354.16446-1-brchuckz@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26215 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 5398
X-purgate-ID: tlsNG-d62444/1785585810-BDA7E757-ED7C9CD1/0/0
X-purgate-type: clean
X-purgate-size: 5498

On 7/31/2026 8:03 PM, Chuck Zmudzinski wrote:
> Modern Intel IGD devices do not work well with the current
> implementation of support for the Intel IGD in hvmloader because
> it lacks support for an extended video bios table (VBT).
> 
> Code 43 errors in Windows guests and failure of the guest screen
> to light up are some of the problems that occur with the
> current implementation.
> 
> To address this problem, this patch implements support for
> Intel IGD devices with an extended VBT and OpRegion version 2
> and higher which is required for most modern Intel IGD devices.
> 
> This patch also depends on compatible support in the device
> model. If hvmloader detects the device model lacks such support,
> it will fall back to the currently implemented protocol for
> configuring the OpRegion to provide backward compatibiltiy for
> systems that lack a device model with support for an extended VBT.
> 
> Support for an extended VBT is implemented in the newly introduced
> function opregion_setup() which is implemented in the new file
> intel_opregion.c.
> 
> Major differences between this implementation and the current
> implemntation that only supports older devices without an
> extended VBT:
> 
> 1. The current implemntation reserves a constant number of
>    pages (3) in the E820 map for the OpRegion which is set by
>    the IGD_OPREGION_PAGES macro in the current implementation.
>    With OpRegion 2 and higher, the OpRegion can have an
>    extended VBT that must be provided to the guest with the
>    OpRegion. This means the size of the region is not fixed,
>    so in this new implementation the IGD_OPREGION_PAGES constant
>    is changed to a variable in e820.c, igd_opregion_e820_pages,
>    that is set to its proper value based on the the size of the
>    VBT. In this new implemntation, the size of the ACPI NVS region
>    reserved for the OpRegion in the E820 map is equal to the value
>    of the igd_opregion_e820_pages variable instead of being set
>    to the constant value determined by IGD_OPREGION_PAGES.
> 
> 2. The current implemntation provides the guest with access
>    to the unmodified OpRegion on the host via memory mapping
>    from the host to the guest. This is insufficient for
>    OpRegion 2 and higher because some devices will require
>    modifications to the OpRegion for proper operation in the
>    guest. So this new implementation provides hvmloader with a
>    copy of the host's OpRegion that hvmloader can modify as
>    needed for proper operation. Mapping the OpRegion from the
>    host to the guest is only used temporarily during setup of
>    the OpRegion by hvmloader and once hvmloader has a copy of
>    the OpRegion and the extended VBT, the device model removes
>    the host mapping and hvmloader configures the guest to use
>    the guest's possibly modified copy of the OpRegion instead.
> 
> 3. The current implementation lacks useful debugging information
>    for the more recent devices. This new implementation provides
>    useful debugging output from hvmloader, such as the detected
>    host OpRegion version and address, the values for rvda, rvds,
>    and the guest OpRegion address when the guest_loglvl is set
>    to all/all.
> 
> Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
> Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
> Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
> ---
> Later versions of this patch will provide a link to the compatible patch
> for extended VBT support in the device model which will be posted to
> the qemu-devel and xen-devel mailing lists and Cc'd to the appropriate
> maintainers and reviewers soon.

I forgot to mention that there is an undocumented setting that works in
the xl.cfg(5) domain configuration file, firmware_override, that makes it
possible to use a patched version of hvmloader alongside an installation
of unpatched upstream Xen or a version of Xen packaged by a distro. So
one can download the source for one's installed version of Xen, apply this
patch and build just hvmloader and then install the patched version of
hvmloader with a different filename, such as hvmloader-igd-testing, into
the same directory where hvmloader is installed (usually something like
/usr/libexec/xen/boot) and then one can configure a guest to use the patched
version of hvmloader with one's installed version of Xen by adding a line
like this to the domain xl.cfg file:

firmware_override = 'hvmloader-igd-testing'

> 
> The compatible patch for the device model is part of a larger patchset
> that fixes many of the problems that currently affect the feature of
> Intel IGD passthrough to Xen HVM guests. This patch should be considered
> as a companion patch to that patchset for the device model. Do not try
> to test this patch with a real Intel IGD device without also applying
> the patchset for the device model because without those patches, the
> guest will most likely fail to start if an Intel IGD is passed through
> to the guest.
> 
> There are different requirements to support OpRegion version 2.0
> and OpRegion version 2.1+, with support for OpRegion 2 the more
> difficult case because it always requires modifications to the OpRegion
> for proper operation in the guest. For some details about OpRegion
> 2 and higher and the extended VBT, see the links in the commit message.
> 


From xen-devel-bounces@lists.xenproject.org Sat Aug 01 14:42:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Aug 2026 14:42:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380254.1624255 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqAv8-0005Se-Lr; Sat, 01 Aug 2026 14:42:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380254.1624255; Sat, 01 Aug 2026 14:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqAv8-0005SX-Ij; Sat, 01 Aug 2026 14:42:38 +0000
Received: by outflank-mailman (input) for mailman id 1380254;
 Sat, 01 Aug 2026 14:42:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.arif@linux.dev>) id 1wqAv6-0005SR-8R
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 14:42:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqAv4-009QRQ-BF
 for xen-devel@lists.xenproject.org; Sat, 01 Aug 2026 16:42:35 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.arif@linux.dev>)
 id 6a6e05b7-e002-0a2a0a5209dd-0a2a450ba9c2-20
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 16:42:33 +0200
Received: from [91.218.175.185] (helo=out-185.mta0.migadu.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <usama.arif@linux.dev>)
 id 6a6e05d8-b7e8-0a2a450b0019-5bdaafb99398-3
 for <xen-devel@lists.xenproject.org>; Sat, 01 Aug 2026 16:42:32 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=key1 header.d=linux.dev header.i="@linux.dev" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1785595351;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=9bAGXb0quOYyJBifFj3CMsobl7Wj528s8Q4pbvQG4r8=;
	b=NEVhQSZZKi4DShjfGxrZuPRqNtphOqe5pi5nbT5xk6bKbRruhnX8733czhr713IWW5JtNX
	lBIXPePnqdQ4ryvX+Ui/oO5FEIW8RXuUpYzDAhh8N6HVjtmRQGHRB2ii5QDX7Pypq+cifn
	JH9gGi4r4HorTfPR/8XI8D8vS+iUZ30=
From: Usama Arif <usama.arif@linux.dev>
To: Zi Yan <ziy@nvidia.com>
Cc: Usama Arif <usama.arif@linux.dev>,
	David Hildenbrand <david@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Muchun Song <muchun.song@linux.dev>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Nico Pache <nico.pache@linux.dev>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Dev Jain <dev.jain@arm.com>,
	Barry Song <baohua@kernel.org>,
	Lance Yang <lance.yang@linux.dev>,
	Gregory Price <gourry@gourry.net>,
	Ying Huang <ying.huang@linux.alibaba.com>,
	Alistair Popple <apopple@nvidia.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Kairui Song <kasong@tencent.com>,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH RFC 03/14] xen/grant-table: stop setting PG_private on pages for grant mapping
Date: Sat,  1 Aug 2026 07:42:19 -0700
Message-ID: <20260801144223.1599317-1-usama.arif@linux.dev>
In-Reply-To: <20260731-remove-pg_private-v1-3-142c97ba3562@nvidia.com>
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Migadu-Flow: FLOW_OUT
X-purgate-ID: tlsNG-42698a/1785595353-1AEDE9EA-5B6B8159/0/0
X-purgate-type: clean
X-purgate-size: 2611

On Fri, 31 Jul 2026 22:13:26 -0400 Zi Yan <ziy@nvidia.com> wrote:

> gnttab_alloc_pages() stores xen_page_foreign in allocated page->private.

in allocated page->private "for 32-bit only".

> On 32-bit, a pointer to xen_page_foreign is stored; on 64-bit,
> xen_page_foreign is stored inline. Checking page->private != NULL is enough
> to tell whether a xen_page_foreign needs to be freed on 32-bit and
> page->private is zeroed unconditionally on 64-bit.
> 
> It prepares for a future commit that remove PG_private.
> 
> No funtional change intended.
> 
> Assisted-by: Claude:claude-opus-4-8
> Assisted-by: Codex:gpt-5
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> To: Juergen Gross <jgross@suse.com>
> To: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Cc: xen-devel@lists.xenproject.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/xen/balloon.c     | 5 +++++
>  drivers/xen/grant-table.c | 7 +++----
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index e7f1d4ca6d753..7f47b0ad05607 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_lowmem)
>  
>  	__ClearPageOffline(page);
>  	dec_node_page_state(page, NR_BALLOON_PAGES);
> +	/*
> +	 * clear page->private before giving it out, since it might be used to
> +	 * store xen_page_foreign info.
> +	 */
> +	set_page_private(page, 0);
>  
>  	return page;
>  }
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 35f879dc5dfb8..cc348ba2e0786 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -875,7 +875,7 @@ int gnttab_pages_set_private(int nr_pages, struct page **pages)
>  
>  		set_page_private(pages[i], (unsigned long)foreign);
>  #endif
> -		SetPagePrivate(pages[i]);
> +		/* Data is stored in page->private on 64-bit */

On 64-bit arch you just iterate an empty for loop. Cleaner to put the
whole for loop in ifdef?

>  	}
>  
>  	return 0;
> @@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, struct page **pages)
>  	int i;
>  
>  	for (i = 0; i < nr_pages; i++) {
> -		if (PagePrivate(pages[i])) {
>  #if BITS_PER_LONG < 64
> +		if (page_private(pages[i]))
>  			kfree((void *)page_private(pages[i]));
>  #endif
> -			ClearPagePrivate(pages[i]);
> -		}
> +		set_page_private(pages[i], 0);
>  	}
>  }
>  EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);
> 
> -- 
> 2.53.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 01:24:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 01:24:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380446.1624265 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqKwO-0000If-3A; Sun, 02 Aug 2026 01:24:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380446.1624265; Sun, 02 Aug 2026 01:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqKwN-0000IX-T6; Sun, 02 Aug 2026 01:24:35 +0000
Received: by outflank-mailman (input) for mailman id 1380446;
 Sun, 02 Aug 2026 01:24:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ziy@nvidia.com>) id 1wqKwL-0000IR-KE
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 01:24:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqKwK-00ATml-Az
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 03:24:32 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a6e9bb8-e002-0a2a0a5209dd-0a2a4506a6b2-42
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 03:24:31 +0200
Received: from [40.93.194.35]
 (helo=SN4PR0501CU005.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a6e9c4e-195a-0a2a45060019-285dc223a853-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 03:24:31 +0200
Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7)
 by CH3PR12MB7497.namprd12.prod.outlook.com (2603:10b6:610:153::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.17; Sun, 2 Aug
 2026 01:24:23 +0000
Received: from IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0270.016; Sun, 2 Aug 2026
 01:24:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XEVNIPKAqOIV9mPMnFjfnpvdbGwMTKWLPGO4LhReL0tHq6mHWSYYwVUOKL8Miz2KQabLfSzuwh7A6EMZiHGn3VvwqGf766VePfoiuI/g/oKJVDp9pZmVESwcX0NBOrgPCLgigBadgLDjXdjrnl/NFqOIAFnHso/2V1pps7CAPKCBj2G+T+Txmny9FXuRXGl5toLLV3EyvVtl63qwEf0+7AGS1fPJw5B+qJtJz7wXisSPJDvO54/BU3g56B4fSzJm5tnm7w0CD7d/jw7XkNolMG2OMszhjm4xZtyfEWqZ/G/wh6os5B81D5b7aphTRjP5lKp+3ke+PPDKPPb2r5MkUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/dve184dRKBcdbil6sKtCHstimONll/8S0M0bj98lGU=;
 b=IfsnNxhPaKZ4h/3EheHQka7tTyLaXbLejvGPfd0WdpLGo4KRkor9h/8i7l+AVoaUOiGNOWe4u9jQbEMX9fiyohSUz0RgVNKf+HdJ3sMRvCSw5w5glbmZo+Ig1AE3kWJQwmNG85/qvo6TICRoC5ROaA4l13JXfSLoUXrnISAoDPYaSWPRkhJ2KQQzSn9a4vOqGJkYonPji2IgGOaa0Q+DL0M1fPE1DZCK6UHxmFk9rzROT++LG+pRTZNbenlDrLRcd1B5RiCvx9KFTSrV8JRj/BYuor/Bx8OAk5d5q03WRIl67ZsPst+ch3Q++BuK5vSZHMG0dDRIBdpeyrV3uxAZIw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/dve184dRKBcdbil6sKtCHstimONll/8S0M0bj98lGU=;
 b=pztXLPe5k9J0syXAUdpvNVHcnb2ztarvoesmwJ6WM/kxSKfqrt2MxPh46o9fw8cgcElsRWhqFZGP7oyorkoTByeuqciSZfFxc5Wtf1GhFsiUh2+bEIqrk8sqeNa6g32yhL48WgBy+Csd78vi4YiK5ay7GAdJwWJIwAKIKFkApzAnslJnEPfTqPdQfJXHyGEC7QWXvHj+f4nTRVDjmiXRWS6lZy8LHTzv3lGc7qWBKGWr/anfciJ635RHNjqEZDAM0bW+KK60Hwb2tzOQpK9l6ZJY2JNR5r/WkEgBBgLPZ/fnEd1G4rGAsRNNRJKX6rT8HHIw8IwznMLWwslBSw9EuQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Sat, 01 Aug 2026 21:24:18 -0400
Message-Id: <DKE2DI3F363X.EBNM12BH5C46@nvidia.com>
Subject: Re: [PATCH RFC 03/14] xen/grant-table: stop setting PG_private on
 pages for grant mapping
Cc: "David Hildenbrand" <david@kernel.org>, "Matthew Wilcox (Oracle)"
 <willy@infradead.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Muchun
 Song" <muchun.song@linux.dev>, "Lorenzo Stoakes" <ljs@kernel.org>, "Liam R.
 Howlett" <liam@infradead.org>, "Vlastimil Babka" <vbabka@kernel.org>, "Mike
 Rapoport" <rppt@kernel.org>, "Suren Baghdasaryan" <surenb@google.com>,
 "Michal Hocko" <mhocko@suse.com>, "Baolin Wang"
 <baolin.wang@linux.alibaba.com>, "Nico Pache" <nico.pache@linux.dev>, "Ryan
 Roberts" <ryan.roberts@arm.com>, "Dev Jain" <dev.jain@arm.com>, "Barry
 Song" <baohua@kernel.org>, "Lance Yang" <lance.yang@linux.dev>, "Gregory
 Price" <gourry@gourry.net>, "Ying Huang" <ying.huang@linux.alibaba.com>,
 "Alistair Popple" <apopple@nvidia.com>, "Johannes Weiner"
 <hannes@cmpxchg.org>, "Qi Zheng" <qi.zheng@linux.dev>, "Shakeel Butt"
 <shakeel.butt@linux.dev>, "Kairui Song" <kasong@tencent.com>,
 <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, "Juergen Gross"
 <jgross@suse.com>, "Stefano Stabellini" <sstabellini@kernel.org>,
 "Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
 <xen-devel@lists.xenproject.org>
To: "Usama Arif" <usama.arif@linux.dev>
From: "Zi Yan" <ziy@nvidia.com>
X-Mailer: aerc 0.21.0
References: <20260731-remove-pg_private-v1-3-142c97ba3562@nvidia.com>
 <20260801144223.1599317-1-usama.arif@linux.dev>
In-Reply-To: <20260801144223.1599317-1-usama.arif@linux.dev>
X-ClientProxiedBy: CY5P220CA0011.NAMP220.PROD.OUTLOOK.COM
 (2603:10b6:930:ed::14) To IA0PR12MB8374.namprd12.prod.outlook.com
 (2603:10b6:208:40e::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|CH3PR12MB7497:EE_
X-MS-Office365-Filtering-Correlation-Id: 4b51436f-178d-4c7f-8d75-08def034c8d1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|366016|11063799006|4143699003|56012099006|10067099003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	GTL9MuIyFml9pJZkxR0sjs63KiJ3J+8GxVms+5aX0KtiKCEf+rQ5nG4tkJfvp3E7quVqmCgj0IKvlia372YhviX9j8HIRIrDOeC0Mborl8eTLQbGn1CRGcDRGZhFwR22XgQrg5sTQsnzRabvETE68xcsgu3d+AU3hUrW3HFiGR6Id0BRsiXVuQ6jCnBqdGdkxkn0kVyAhXID7YiUAyij1VWUHcZ6so3tbtC9sS4et4CYdlgkCRdjVXQj/9A8T9YNMEHYGwoBm2DIttalgxf3TjLQQ1AAM/wDTQWLPJIV2FppBfOnu4ooyC8INrfddZUsretpTCxy/Lh+GTlYl8/+dnvhsPFphs1XEpg02TblypTdKLyiTdLSCIZ64VWaMsDyHab5IPJG35XWoBTHMwjQvc2ghW7iRXzzL6sr7P86amfCZWqiDEXUZRPtu8lO8na2Prg+C7v6KKXqxA4s3fStYA4C88zZT9oh5tzTJYcimKzqb5XFQYAiRaWVuT4HZwf+Pc97yTJy+DBiad86t86VWi5Cs9VSTNolGB7HE1S0cqE6/OSgT9rtJZCMfqaEqT6MAEZYxdLBvyfxYEMpASB3saK/wLtxieDYhZ+Ztd83KZOlzEM250hUXF63m3miyX1XvK3LhFRhgkjPPfBwtyf6UNh2ArldG9LlBh5OJeyt41Q=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(23010399003)(366016)(11063799006)(4143699003)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YStDN1BLV2tpdk9Kc0ZORFJCK1o4eVhZdDdzN2VrQ1o2RzdxUTFuTG9QMGJP?=
 =?utf-8?B?VHFUbVN2SFJOYmFmbEhURWM0QTlsSHRQRWtRRTAwdUphbjI4YlF1L20xcTda?=
 =?utf-8?B?bmwxb1NKSWYwSXRXdFRsRDk0b2twZEhYQkVZTU5pVExOZ0JwU0s3amtrWTd2?=
 =?utf-8?B?cVQ1UEZmbDM3Z3IzTVA2aWtOVVVxdzJDNG1QS1BrRFNUVUorTEhrYmtxWUlX?=
 =?utf-8?B?Ty8wa2VVM1hnOC9nVW9PRmgwOTJvRHdsMndXZkNKeDdSaUd1MjlmTTRLS29t?=
 =?utf-8?B?czlRYjZJM2tWaEQrMk92RktmbU5OSFBqQ2JSUk42T0FFcGhwN3ZPdWhybWY4?=
 =?utf-8?B?bmh5SklIRXJKME5ocVlyU2tHaWNJYjg2MWFYaUc2Kys4aUJMK1dMWW5KUzNs?=
 =?utf-8?B?NmxOcUZsK2orcFhrMEZYdE8ySWZXVGo2TGM5dkZsdmp3Ti83ZmpIVm80T0o4?=
 =?utf-8?B?MCtyWFlQaWNaMFk3ZEZsaXFkTVZ0Y0RCekx2STdHOEV5Mk5CeFQyRmxlS1VZ?=
 =?utf-8?B?Q0NycW1zUUM3MEptTXA1N2Y2K3p1U2dydWluZXNyQnVHZUUycEwzN2ovQVpp?=
 =?utf-8?B?REZHYWllRzBDOVRBTExlRmgySXdYUjdmYzZaMlJ1TTF6eUtidGQ5L1IxQmpr?=
 =?utf-8?B?NzgyZ1RqK1NKUGRPeHZJblRkNkpsN0NaZkV6TEJRQjFibHltTHlJOHptQVB2?=
 =?utf-8?B?SElhN1JIT2s0SkkrR3lpY1dQczJzVGk1T29XMEdKaUFJb0wwN0dTRzArTnlZ?=
 =?utf-8?B?a204TnkxcVNsaGNMbEhwbUxkbnIwU2k5U1JMZWNlZ1NudUxTQmQ0QkpJVmN4?=
 =?utf-8?B?a2tPK3ZTZHI3R1pXWkF3dkN2dWFpdDlFVjZDUWRxVG1xYUdtMithUXh1bXFD?=
 =?utf-8?B?Y1FIYlFZdVJSVmE4bEZoeGdLWmlvZlVkQTBNMjNQa3BHMExTZ2N2NmdiaWFn?=
 =?utf-8?B?RXF1MkE1K1ltSlVqZEZ5QzBNV0tWQVh1ekNFeVppNjRhTFZxUXQ3UC80OFVa?=
 =?utf-8?B?MGlQb3lJS2VUSTBiRXhSc0o0NG9sbHNrUENCTUVKU1dhUEtqSUtlY1MwVWtQ?=
 =?utf-8?B?U1ZlbjE5NVE1N201cHNGajk5eGxza2YzMmppNHRsMzN5OHVheHljNUlseWZU?=
 =?utf-8?B?RnEzS3FXRE5TV2pnMnovQ05qc3ZWaDluUmhYVktBSGxpOG5Bai9jZHRuRTVQ?=
 =?utf-8?B?UURib2c1VGRiNG1hdE9vNzgzMVJvdnd3TTFGd0I5TG9hR0hPenBoTUo2OWh4?=
 =?utf-8?B?V3hmTHpzVlc5WmdFQlpKZkNjbGE4MERyRlg0TDh2bGkyNlR2a0FkQjZqZ2k0?=
 =?utf-8?B?eWltM1NSbEZTWGRObFk2QWxrdytxOG43ZENESkRiUmVSWkdQNlBZK1hHamJG?=
 =?utf-8?B?SlhWRG0wdXJ0aTJ3eUdKT0cxSVFVanFKRGlOb1ozaTVmVUtYREcvbnFUL210?=
 =?utf-8?B?SmhhOHdrdUZqOXRoWnNDOVAyVmtUTng2cEFSNVprQzRBeGp2RTl5VVFEWW91?=
 =?utf-8?B?ZmZUTlV3Zk9DaW9JYlBwa3krUzc2N1U2VVFpYkVQRGVOM1k0TkFOMy9RY1FU?=
 =?utf-8?B?Tmp4M3lUN0NEUXZQWCt4YUxsZXhNYm9ucjdkclBHY1V3M0pqYkFST3VKbHdq?=
 =?utf-8?B?dUJEU2s2aHU3akEwVVhUemloVzg0R05SYUx0LzExdzIwdmd3WUdHUnZjVE5E?=
 =?utf-8?B?UVhIT2pObmhvZGhmMFpMVDBsWWptTzhZd0VyeWpJd0xlcDllV3k1NG1rRElS?=
 =?utf-8?B?T0dyMmVwaXJNbEhlNlhNUUxuV0dEMVg1OWR6K2thRmFIV1dlSDJEVm93R2o0?=
 =?utf-8?B?ZDkvSTJUL0lwemFuTU9TRFN1MGY1ejdlUkxPdzRwS3gxZnZLSlBZNjFsR3k2?=
 =?utf-8?B?bmlUL1A3WEFPa3E4U0VHQlhRTVFxYTkyeTliUEFqdjBUT0ZrOUVLVUVtT2N1?=
 =?utf-8?B?ajFHakF0SWxKalE3dHZSUCtjNm0zOGhYWStZMk8yc0NWUERYZWlUMEZRd1lu?=
 =?utf-8?B?MWJ2b2xTS1YyTkhHaDdQZHR2eXdaK2M4Y3RYRzdYYWZoaFZveEw4cFIrUE4z?=
 =?utf-8?B?RWdkbkRJUTJWSVdEL1I2SHJPSjJMbnNyVkE0Q0RJRndjOGFTekNTWERzZjU2?=
 =?utf-8?B?eWwxVzhKcVFCNnZmRUY1VHNFV3c4Y3BBMzZsVU1nczFpQ3hGYnNCZmlUMU16?=
 =?utf-8?B?ZnBzRldxbVJ1ZmxVT0pSNHpadHRzVHRJWFAvSWhVUVZhcHdCSkpJb29sOUYr?=
 =?utf-8?B?SEFTN1VzNDM0ZlorVCtoSXZhMkhQQXpZT0kyT2dkckhaVEFudmRXVjF5K3hV?=
 =?utf-8?Q?5vUglnHOG7PTctab9d?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b51436f-178d-4c7f-8d75-08def034c8d1
X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2026 01:24:23.2424
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3PUHSVb9kPk6/DlsZk4L3x3wkLtYhelcslgc595NElzHQWP4c3rG3dXU7IPovngI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7497
X-purgate-ID: tlsNG-16d1c6/1785633871-FCE0677B-C4497805/0/0
X-purgate-type: clean
X-purgate-size: 2954

On Sat Aug 1, 2026 at 10:42 AM EDT, Usama Arif wrote:
> On Fri, 31 Jul 2026 22:13:26 -0400 Zi Yan <ziy@nvidia.com> wrote:
>
>> gnttab_alloc_pages() stores xen_page_foreign in allocated page->private.
>
> in allocated page->private "for 32-bit only".

I will remove "allocated" in the sentence. That should cover both 32-bit
and 64-bit cases.

>
>> On 32-bit, a pointer to xen_page_foreign is stored; on 64-bit,
>> xen_page_foreign is stored inline. Checking page->private !=3D NULL is e=
nough
>> to tell whether a xen_page_foreign needs to be freed on 32-bit and
>> page->private is zeroed unconditionally on 64-bit.
>>=20
>> It prepares for a future commit that remove PG_private.
>>=20
>> No funtional change intended.
>>=20
>> Assisted-by: Claude:claude-opus-4-8
>> Assisted-by: Codex:gpt-5
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> To: Juergen Gross <jgross@suse.com>
>> To: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> Cc: xen-devel@lists.xenproject.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  drivers/xen/balloon.c     | 5 +++++
>>  drivers/xen/grant-table.c | 7 +++----
>>  2 files changed, 8 insertions(+), 4 deletions(-)
>>=20
>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>> index e7f1d4ca6d753..7f47b0ad05607 100644
>> --- a/drivers/xen/balloon.c
>> +++ b/drivers/xen/balloon.c
>> @@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_l=
owmem)
>> =20
>>  	__ClearPageOffline(page);
>>  	dec_node_page_state(page, NR_BALLOON_PAGES);
>> +	/*
>> +	 * clear page->private before giving it out, since it might be used to
>> +	 * store xen_page_foreign info.
>> +	 */
>> +	set_page_private(page, 0);
>> =20
>>  	return page;
>>  }
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index 35f879dc5dfb8..cc348ba2e0786 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -875,7 +875,7 @@ int gnttab_pages_set_private(int nr_pages, struct pa=
ge **pages)
>> =20
>>  		set_page_private(pages[i], (unsigned long)foreign);
>>  #endif
>> -		SetPagePrivate(pages[i]);
>> +		/* Data is stored in page->private on 64-bit */
>
> On 64-bit arch you just iterate an empty for loop. Cleaner to put the
> whole for loop in ifdef?

Sure. Will do that.
>
>>  	}
>> =20
>>  	return 0;
>> @@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, st=
ruct page **pages)
>>  	int i;
>> =20
>>  	for (i =3D 0; i < nr_pages; i++) {
>> -		if (PagePrivate(pages[i])) {
>>  #if BITS_PER_LONG < 64
>> +		if (page_private(pages[i]))
>>  			kfree((void *)page_private(pages[i]));
>>  #endif
>> -			ClearPagePrivate(pages[i]);
>> -		}
>> +		set_page_private(pages[i], 0);
>>  	}
>>  }
>>  EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);
>>=20
>> --=20
>> 2.53.0
>>=20
>>=20




--=20
Best Regards,
Yan, Zi



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 05:08:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 05:08:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380488.1624278 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqOR8-0003Dj-HI; Sun, 02 Aug 2026 05:08:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380488.1624278; Sun, 02 Aug 2026 05:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqOR8-0003Da-Ci; Sun, 02 Aug 2026 05:08:34 +0000
Received: by outflank-mailman (input) for mailman id 1380488;
 Sun, 02 Aug 2026 05:08:33 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wqOR7-0003DU-4a
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 05:08:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqOR5-003hFc-Rf
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 07:08:31 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6ed0c5-e002-0a2a0a5209dd-0a2a4505806a-4
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 07:08:30 +0200
Received: from [98.137.65.32] (helo=sonic315-8.consmr.mail.gq1.yahoo.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a6ed0cd-4cb1-0a2a45050019-62894120a298-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 07:08:30 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Aug 2026 05:08:28 +0000
Received: by hermes--production-ne1-6f6bdbdd7c-6qsrs (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 38873ceacd7487424d36cd594a4ef84d; 
 Sun, 02 Aug 2026 05:08:26 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785647308; bh=qI3cvxJkB0wST2pLg+kJk+H1/7OsJAYv2EoXvyMCIBI=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=dT0rXBUgs0mgBPCg8e+PeGnZbTqg7eRBYBxXIk10d911DXOTsGqOt4TVAEErMU3TKiNtcmSe/hmug7qGSBqMhId+lUbg1fhmYIOcKzTWw6jQfNuewFWvSLdc4rQe2Mk6lzIpkutmP0j3pxbydnUvXaxKdFO61ocJS9EGi3qnn6hb2o88hRQ18m1vHuxTT2o0AJ6SSVdjxas9OCj1ua8ajOp17zq18UIijLOnwZSkxZ1p2bXnbPsa01OIb8PqIMA3W6DNGn7eMNVsVZQLEFMH+eSnFQuNnSikHAnCB/k//h7Su8H/5YB9g8/EuhCuJ5SKJwNWbbols0a0LAw37sR+2A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785647308; bh=55uMRXMxddGSCqkDCycETdUXDjoHOP1zl/jTH9nPnTt=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=BWVg2F3ISOn9a+MnZ7gd1DX/vCZGKt50+SzK17C4QUBrjBODaLUBSHqzdvGqMRwh0fnbnhqkjuxo8Duou9AeAJu3dwtbPOvxAiAPdc/T6dbDYFx8qWThgnUhMoF4A1HsN+SsZJWyfNYQnh6Durf3XwcS0zO2/RyQdubS+62U4T87tmO9h7vF7vkBGWcz9nwlS0yS47U/xlCD3H+eWsa+VL7ESTg++kgAK15YixDUxvNX8aBCvFBaOguX/SUxiWItc9wrbKCKw8qSdxsE9JD2VxBtn3P0Ix8jqb4rX2XlbHI+ghcH0I4v/dDqufOIsQy/BD4rf7l2Lp1YqrMkmoHnfA==
X-YMail-OSG: KwRT3NkVM1npbbUkdnGcr_aHoBT436ZNTELI4trj0hzZgfcNEtANa_UFL9s26Lj
 7fmfhx3YG6uGFZ2tShgSUBAjckUWfJzo8MXPckMbLGfzAUrpl60Kxy6fENxqUOOLrhFW7AzHGfAs
 nyfr30VnnVFwsyClZPVDhFQcCorqlkom_vpX9OSdFYtRQfOGBdSdTDHZat5NWUwd361HhcQRPtnK
 i3CK5VMOtqwhoLsIncOBUgpxPeoil_y2Pf9WRHNe7rAPLIn0QB4LIu94fLwhKntnGpL0Vlv.DD..
 3LmL2QrT.h_KIxXlq07ufwHYe6isKly654swXs4GCSdD9OxE_pgjUOf4hkA4fH5cefr_VoMTbHj0
 Esa9aydO8CrE52wVGSfRNX_QwgIuOqyYCbn.B9505U8Jq_1vNxQnPHXzlkgl.nAoadbfF0wn5dqK
 3nVmdRW0WrJG4ztjFNS5UWR7Cc5IRp3wSZd823N0uZK914Q6.8DZMNHGbmSfaOfXav6uAOJlGhZg
 0dvM3MQXobpcX6QpmWNrLYUuGJXvL6totqmqtghxH1MStD2C6zVGsmDbEJ_DLBhVv1TWz94dVUEJ
 _2_mCaXeh_CepKFIkh94hH2bGkyO25KaLUK6hp9zXHXoVTLP2NZ6SvUJAdiHCBJWhZqiH6YV1U98
 hd85CSdyZtMKfhQsPkSMZp8Dq1bmyxmnY7pAsFg.2PKZ8vBPugibTesKOEK5n153X6dDBd6Ytkm6
 .tTBu9sL3lMQWVO5h_DMtdnvC3kM84DAEnrl0sCg8nDn58XOk7o4cre_kiClCxyhLlAnT5a67rlD
 R9PoeXeh0Co_pzDKCWHugjob2asMQgoGI1qg4_pZmVKksAzAUGEE8l_ncdu.9npX4Cc5pSj5nfKx
 m8__ZhWVpDGfbwvt5zSZgWXzz7_syHU4kRZqW3P7gNeGY3x8l2dVRiKLRoEa.C0HkBbGyDEQVrSV
 x7JaYO9HVVRKG6qQHrUncL7NimDpjaz0hJk7qlBZUZBzh.xL5LF3uz0tnNf2vxRt6t.y0YjjwtQ1
 PYiaL8IaKxeUpc44wDydcDYh_0J6rX_DFCXMSU4Rk7O33jRxHBkuKWbV60bGCxBLM5lOe.P_wGIZ
 jVITAM1UnItQ2KOZFeDvjK7nR45S7_ZZWPBl4JW3kHdrfzDswjGQ8LbmlJZwb3ewLjtRzsikx3TW
 BCxjzN7M2.x.OvN2WYVxX8mtAWcPNF8e731Ob1ADKak29X_scdRWxxwGytfmhJvsK29nNDTayhlE
 4uuJVb.OfFRrTudknVNgT1L8jqDePs1jivsxui32zmtjUW9R9rT87FrKyJgeXUK3CyUi_OWEUV6c
 IOHu4Q4CDEC7a1NRvQ5Ifr0p7uAh_drMzHWUYECaOu4C894.h75huHzBYc969x5h128NahwGi9XD
 mS3DpOZ1EYK1UN5PmwHStXa6mi69FkcpWjWQRviMweXQxK4J_Ek3StkRiCFWiOUlE5747ItHF1hP
 ThKfH7mGCvhNxshxhfr7AlqL3Ngixkqa6xQpUQNvZWKU8bo3MxSd_s80tuJpsFimPKXtVbM2LgCG
 oNrRKChYqHepvX8SyZonU0jz.90ieAq.mU9yAL2q9gosx4UgsKk7BBiMrCHqvTwL3wnQHiVdUEVg
 knMdwcacNS0PI.f8APr4NGbBJhMuUgUr1m.yFMjA.mybqKHYqP8bzeEBuByV12K0ULqVnnq.AUoj
 1d25kHVN3IZ_CZcA0a6VcJUzkEbgt6NI.nYxyrL9Nx4CUW0a_yc_xMu4MFYshyoChyHEL8nuaBQX
 bLhJvwuWYFcowUxhP4MJcZ34R7z5FGquqgUJh7qzJyWNePo.Ey.JaNrtkH96XOvuM30OiWrb1Fvk
 csU8UxS6CYlLG896VmE6kk3deZHMq32g48JkF_TEvwaJXpPxgGiHS6m3VvLLoKrYPQu0hYKgyI.K
 ISDGQnwgKxREOIfFZfDRV4HVQJHntNG6SpWKlnOkZ1e.klDDdiRmNu7WpoPfMw5MsJOKpERfc4Dn
 EtOmj631iW_As7dXP_LrfOrt3ebAzPSu9QvgmtfcwwyCAaH10pOeAtloJf74ZkJjhLcLxX_9_JEk
 gR._XNKQ25kzUWLmh_XUx074ift5LfdhDj3RaE.WZlVWPzzyCGbarfVR.3tf4wK5CdHTSDm3cB9m
 L70llLWtuPn0MhQO9J2PfuG7.X23GeDMbsxkQLvDSb5Qbgq7oc5NRMWSzi5dwUMMjDG0ib1Im8Bo
 P4h1bsZgsK.Nx_PDuimzvrP3Bdav1xVmQl1xV9ZKFHIgpKw--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 102b02d6-5502-4279-a553-a5f20c7f39e4
From: Chuck Zmudzinski <brchuckz@aol.com>
To: xen-devel@lists.xenproject.org
Cc: qemu-devel@nongnu.org,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT support
Date: Sun,  2 Aug 2026 01:08:10 -0400
Message-ID: <20260802050824.10554-1-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
Content-Length: 21848
X-purgate-ID: tlsNG-c201ff/1785647310-714AC2A1-F72EF1AD/0/0
X-purgate-type: clean
X-purgate-size: 22391

Modern Intel IGD devices do not work well with the current
implementation of support for the Intel IGD in hvmloader because
it lacks support for an extended video bios table (VBT).

Code 43 errors in Windows guests and failure of the guest screen
to light up are some of the problems that occur with the
current implementation.

To address this problem, this patch implements support for
Intel IGD devices with an extended VBT and OpRegion version 2
and higher which is required for most modern Intel IGD devices.

This patch also depends on compatible support in the device
model. If hvmloader detects the device model lacks such support,
it will fall back to the currently implemented protocol for
configuring the OpRegion to provide backward compatibiltiy for
systems that lack a device model with support for an extended VBT.

Support for an extended VBT is implemented in the newly introduced
function intel_opregion_setup() which is implemented in the new
file intel_opregion.c.

Major differences between this implementation and the current
implemntation that only supports older devices without an
extended VBT:

1. The current implemntation reserves a constant number of
   pages (3) in the E820 map for the OpRegion which is set by
   the IGD_OPREGION_PAGES macro in the current implementation.
   With OpRegion 2 and higher, the OpRegion can have an
   extended VBT that must be provided to the guest with the
   OpRegion. This means the size of the region is not fixed,
   so in this new implementation the IGD_OPREGION_PAGES constant
   is changed to a variable in e820.c, igd_opregion_e820_pages,
   that is set to its proper value based on the the size of the
   VBT. In this new implemntation, the size of the ACPI NVS region
   reserved for the OpRegion in the E820 map is equal to the value
   of the igd_opregion_e820_pages variable instead of being set
   to the constant value determined by IGD_OPREGION_PAGES.

2. The current implemntation provides the guest with access
   to the unmodified OpRegion on the host via memory mapping
   from the host to the guest. This is insufficient for
   OpRegion 2 and higher because some devices will require
   modifications to the OpRegion for proper operation in the
   guest. So this new implementation provides hvmloader with a
   copy of the host's OpRegion that hvmloader can modify as
   needed for proper operation. Mapping the OpRegion from the
   host to the guest is only used temporarily during setup of
   the OpRegion by hvmloader and once hvmloader has a copy of
   the OpRegion and the extended VBT, the device model removes
   the host mapping and hvmloader configures the guest to use
   the guest's possibly modified copy of the OpRegion instead.

3. The current implementation lacks useful debugging information
   for the more recent devices. This new implementation provides
   useful debugging output from hvmloader, such as the detected
   host OpRegion version and address, the values for rvda, rvds,
   and the guest OpRegion address when the guest_loglvl is set
   to all/all.

Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
The companion patchset for the device model is available here:

https://lore.kernel.org/xen-devel/20260801001737.16509-1-brchuckz@aol.com/

There is an undocumented setting that works in the xl.cfg(5) domain
configuration file, firmware_override, that makes it possible to use
a patched version of hvmloader alongside an installation of unpatched
upstream Xen or a version of Xen packaged by a distro. So one can
download the source for one's installed version of Xen, apply this
patch and build just hvmloader and then install the patched version of
hvmloader with a different filename, such as hvmloader-igd-testing, into
the same directory where hvmloader is installed (usually something like
/usr/libexec/xen/boot) and then one can configure a guest to use the patched
version of hvmloader with one's installed version of Xen by adding a line
like this to the domain xl.cfg file:

firmware_override = 'hvmloader-igd-testing'

The compatible patch for the device model is part of a larger patchset
that fixes many of the problems that currently affect the feature of
Intel IGD passthrough to Xen HVM guests. This patch should be considered
as a companion patch to that patchset for the device model. Do not try
to test this patch with a real Intel IGD device without also applying
the patchset for the device model because without those patches, the
guest will most likely fail to start if an Intel IGD is passed through
to the guest.

There are different requirements to support OpRegion version 2.0
and OpRegion version 2.1+, with support for OpRegion 2 the more
difficult case because it always requires modifications to the OpRegion
for proper operation in the guest. For some details about OpRegion
2 and higher and the extended VBT, see the links in the commit message.

Changes in v2:
  - Correct the name of the new function in the commit message
    opregion_setup() -> intel_opregion_setup()

  - Add a link to the companion patchset for the device model

  - Describe how to use the firmware_override setting in xl.cfg(5)
    to simplify testing of this patch.

  - Correct a logical flaw that in case the size of the extended VBT
    is <= 2 pages, an extra, unnecessary page would be allocated in
    the memory hole. This correction is in the intel_opregion.c file.

    This code:

    /* Update the number of pages we need for the E820 map */
    igd_opregion_e820_pages = pages_needed;

    /*
     * So far we have allocated vbt_pages_needed
     * and we will likely need to allocate more
     * pages to fully contain OpRegion + VBT.
     */
    if ( pages_needed > vbt_pages_needed )
        igd_opregion_pgbase = mem_hole_alloc
                              (pages_needed - vbt_pages_needed);

    Is replaced with this code:

    /*
     * So far we have allocated igd_opregion_e820_pages
     * and we will likely need to allocate more
     * pages to fully contain OpRegion + VBT.
     */
    if ( pages_needed > igd_opregion_e820_pages )
        igd_opregion_pgbase = mem_hole_alloc
                              (pages_needed - igd_opregion_e820_pages);

    /* Update the number of pages we need for the E820 map */
    igd_opregion_e820_pages = pages_needed;

 tools/firmware/hvmloader/Makefile         |   1 +
 tools/firmware/hvmloader/config.h         |  15 +-
 tools/firmware/hvmloader/e820.c           |   4 +-
 tools/firmware/hvmloader/intel_opregion.c | 297 ++++++++++++++++++++++
 tools/firmware/hvmloader/pci.c            |  10 +-
 5 files changed, 313 insertions(+), 14 deletions(-)
 create mode 100644 tools/firmware/hvmloader/intel_opregion.c

diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 21de721..ed42915 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -35,6 +35,7 @@ OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
 OBJS += ovmf.o seabios.o
+OBJS += intel_opregion.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index c159db3..bd3c0f9 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -7,9 +7,6 @@
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
 
-extern unsigned long igd_opregion_pgbase;
-#define IGD_OPREGION_PAGES 3
-
 struct bios_config {
     const char *name;
 
@@ -43,6 +40,18 @@ extern struct bios_config ovmf_config;
 
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
+#define IGD_OPREGION_PAGES 3
+#define IGD_OPREGION_SIZE ((IGD_OPREGION_PAGES - 1) << PAGE_SHIFT)
+#define IGD_OPREGION_RVDA 0x3ba
+#define IGD_OPREGION_RVDS 0x3c2
+#define IGD_OPREGION_VERSION 0x16
+#define IGD_OPREGION_MASK 0xfff
+#define IGD_OPREGION2_SUPPORT_MASK 0x1
+#define IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
+#define IGD_VBT_SIGNATURE "$VBT"
+extern unsigned long igd_opregion_pgbase;
+extern uint32_t igd_opregion_e820_pages;
+void intel_opregion_setup(uint32_t vga_devfn);
 
 extern uint8_t ioapic_version;
 
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 86d3954..97a234e 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -243,11 +243,11 @@ int build_e820_table(struct e820entry *e820,
         nr++;
 
         e820[nr].addr = igd_opregion_base;
-        e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE;
+        e820[nr].size = igd_opregion_e820_pages * PAGE_SIZE;
         e820[nr].type = E820_NVS;
         nr++;
 
-        e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE;
+        e820[nr].addr = igd_opregion_base + igd_opregion_e820_pages * PAGE_SIZE;
         e820[nr].size = (uint32_t)-e820[nr].addr;
         e820[nr].type = E820_RESERVED;
         nr++;
diff --git a/tools/firmware/hvmloader/intel_opregion.c b/tools/firmware/hvmloader/intel_opregion.c
new file mode 100644
index 0000000..59cb2c3
--- /dev/null
+++ b/tools/firmware/hvmloader/intel_opregion.c
@@ -0,0 +1,297 @@
+/*
+ * intel_opregion.c: HVM Intel OpRegion setup.
+ *
+ * Leendert van Doorn, leendert@watson.ibm.com
+ * Copyright (c) 2005, International Business Machines Corporation.
+ *
+ * Copyright (c) 2006, Keir Fraser, XenSource Inc.
+ *
+ * Copyright (c) 2026, Charles Zmudzinski.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "util.h"
+#include "config.h"
+#include "pci_regs.h"
+
+unsigned long igd_opregion_pgbase = 0;
+uint32_t igd_opregion_e820_pages = IGD_OPREGION_PAGES;
+
+static bool verify_opregion(const uint32_t addr)
+{
+    const char *opregion_signature = IGD_OPREGION_SIGNATURE;
+    if ( memcmp((const void *)addr, (const void *)opregion_signature, 16) )
+        return false;
+    return true;
+}
+
+static bool verify_vbt(const uint32_t addr)
+{
+    const char *vbt_signature = IGD_VBT_SIGNATURE;
+    if ( memcmp((const void *)addr, (const void *)vbt_signature, 4) )
+        return false;
+    return true;
+}
+
+void intel_opregion_setup(uint32_t vga_devfn)
+{
+    uint32_t igd_guest_opregion;
+    uint32_t pages_needed; /* for OpRegion + VBT */
+    void *opregion_scratch;
+    void *vbt_scratch;
+    void *vbt_source;
+    /*
+     * absolute value in the host/guest except
+     * as noted in the comments
+     */
+    static unsigned long rvda_host;
+    static unsigned long rvda_guest;
+
+    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
+    /*
+     * Tentative value for the number of pages to reserve
+     * in the E820 map for the OpRegion and VBT.
+     *
+     * This will be the final value for the E820 map if
+     * the device model lacks support for OpRegion 2 or
+     * if the host OpRegion version is < 2 or if we never
+     * allocate more pages in the E820 map for the VBT.
+     */
+    igd_opregion_e820_pages = IGD_OPREGION_PAGES;
+
+    /*
+     * Read the value the device model is initialized with.
+     * If the device model supports OpRegion 2, it will
+     * return the host IGD OpRegion address. If not, it
+     * will return 0. If the device model does not support
+     * OpRegion 2, the device model expects us to give it
+     * the address to which it will map the OpRegion in the
+     * guest and then expects us to do nothing more to setup
+     * the OpRegion, so that is all we will do in that case.
+     */
+    const uint32_t igd_host_opregion = pci_readl(vga_devfn,
+                                                 PCI_INTEL_OPREGION);
+    if ( !igd_host_opregion ) {
+        printf("device model lacks extended VBT "
+               "support. Continuing with legacy support only\n");
+        /*
+         * Write the the OpRegion offset to give the OpRegion
+         * address to the device model. The device model will trap
+         * and map the OpRegion at the give address.
+         */
+        pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                   igd_opregion_pgbase << PAGE_SHIFT);
+        return;
+    } else {
+        printf("host OpRegion address: 0x%x\n",
+               igd_host_opregion);
+    }
+
+    const uint32_t igd_host_opregion_page_offset =
+                   igd_host_opregion & IGD_OPREGION_MASK;
+    igd_guest_opregion = (igd_opregion_pgbase << PAGE_SHIFT) |
+                          igd_host_opregion_page_offset;
+
+    /*
+     * We know at this point the device model supports
+     * OpRegion 2.
+     *
+     * Indicate to the device model that we support
+     * OpRegion 2 by setting the least significant bit
+     * of the address we give to the device model.
+     * The device model will notice this bit set and
+     * respond appropriately to our writes to the
+     * register where the OpRegion address is stored.
+     */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               (igd_opregion_pgbase << PAGE_SHIFT) |
+                IGD_OPREGION2_SUPPORT_MASK);
+
+    printf("guest OpRegion tentative "
+           "address: 0x%x\n", igd_guest_opregion);
+
+    if ( !verify_opregion(igd_guest_opregion) ) {
+        printf("error: IGD OpRegion signature "
+               "not found.\n");
+        BUG();
+    }
+
+    opregion_scratch = scratch_alloc(IGD_OPREGION_SIZE, 0);
+    memcpy(opregion_scratch, (const void *)igd_guest_opregion,
+           IGD_OPREGION_SIZE);
+
+    /* Read OpRegion version, rvda_host, and rvds */
+    const uint16_t version = *(uint16_t *)(opregion_scratch +
+                                           IGD_OPREGION_VERSION);
+    printf("OpRegion version: 0x%x\n", version);
+    if ( version >= 0x0200 ) {
+        rvda_host = *(unsigned long *)(opregion_scratch +
+                                       IGD_OPREGION_RVDA);
+        /* It is convenient to make rvda_host absolute */
+        if ( version > 0x0200 )
+            rvda_host += igd_host_opregion;
+        printf("host VBT address: 0x%lx\n", rvda_host);
+    } else {
+        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
+        rvda_host = 0;
+    }
+    const uint32_t rvda_host_page_offset = rvda_host &
+                                           IGD_OPREGION_MASK;
+    const uint32_t rvds = *(uint32_t *)(opregion_scratch +
+                                        IGD_OPREGION_RVDS);
+    const uint32_t rvds_page_offset = rvds & IGD_OPREGION_MASK;
+    printf("VBT size: 0x%x\n", rvds);
+
+    if ( !rvds || !rvda_host ) {
+        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
+        rvda_host = 0;
+    }
+    /*
+     * Write rvda_host as 2 successive 32-bit values
+     * to communicate location of the VBT to the device
+     * model. If rvda_host is not 0, The device model
+     * unmaps the OpRegion and eventually maps the VBT
+     * after we also write the guest address where the
+     * VBT will be mapped.
+     *
+     * If we send rvda_host = 0 to the device model, it
+     * will assume we do not need OpRegion 2 support and
+     * it will not unmap the OpRegion.
+     */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               (uint32_t)(rvda_host & 0xfffffffful));
+    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               (uint32_t)rvda_host_upper_32);
+
+    /* In this case, we use the mapped OpRegion */
+    if ( !rvda_host )
+        return;
+
+    /*
+     * Update the number of pages the device model
+     * needs to map for us to get a copy of the VBT.
+     *
+     * N.B.: Here, igd_opregion_pgbase is really the page
+     * base of the location where the device model will
+     * map the VBT.
+     */
+    uint32_t vbt_pages_needed = rvds >> PAGE_SHIFT;
+    if ( rvds & IGD_OPREGION_MASK )
+        vbt_pages_needed++;
+    if ( vbt_pages_needed > igd_opregion_e820_pages ) {
+        igd_opregion_pgbase = mem_hole_alloc
+                              (vbt_pages_needed - igd_opregion_e820_pages);
+        igd_opregion_e820_pages = vbt_pages_needed;
+    }
+
+    /*
+     * Write the location where the device model is to
+     * map the VBT in the guest with the 12 least
+     * significant bits encoded as the number of pages
+     * for the device model to map (vbt_pages_needed).
+     */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+               ((igd_opregion_pgbase << PAGE_SHIFT) | vbt_pages_needed));
+
+    /*
+     * When the VBT is mapped from the host, the page offset
+     * of the VBT will be the same as on the host
+     */
+    rvda_guest = (igd_opregion_pgbase << PAGE_SHIFT) |
+                  rvda_host_page_offset;
+    if ( !verify_vbt(rvda_guest) ) {
+        printf("error: VBT signature not found.\n");
+        BUG();
+    }
+
+    vbt_source = (void *)rvda_guest;
+    vbt_scratch = scratch_alloc(rvds, 0);
+    memcpy(vbt_scratch, vbt_source, rvds);
+
+    /* Compute how many pages we need for OpRegion + VBT */
+    pages_needed = (IGD_OPREGION_SIZE + rvds) >> PAGE_SHIFT;
+    if ( (IGD_OPREGION_SIZE + rvds) & IGD_OPREGION_MASK )
+        pages_needed++;
+
+    /*
+     * So far we have allocated igd_opregion_e820_pages
+     * and we will likely need to allocate more
+     * pages to fully contain OpRegion + VBT.
+     */
+    if ( pages_needed > igd_opregion_e820_pages )
+        igd_opregion_pgbase = mem_hole_alloc
+                              (pages_needed - igd_opregion_e820_pages);
+
+    /* Update the number of pages we need for the E820 map */
+    igd_opregion_e820_pages = pages_needed;
+
+    /*
+     * Compute the final igd_guest_opregion value and
+     * keep the same offset as on the host if doing so
+     * will not push us across another page boundary.
+     */
+    igd_guest_opregion = igd_opregion_pgbase << PAGE_SHIFT;
+    if ( (igd_host_opregion_page_offset + rvds_page_offset) <= PAGE_SIZE )
+        igd_guest_opregion |= igd_host_opregion_page_offset;
+    printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
+
+    /* The device model will unmap the VBT */
+    pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_guest_opregion);
+
+    /*
+     * After unmapping we need to populate the memory hole.
+     * If the unmapping failed this will crash the guest.
+     *
+     * We could try to use the mapped VBT with our copy of the
+     * OpRegion, but it is probably better to BUG() if the
+     * device model failed to unmap the VBT.
+     */
+    if ( verify_vbt(rvda_guest) )
+        BUG();
+    mem_hole_populate_ram(igd_opregion_pgbase,
+                          igd_opregion_e820_pages);
+
+    /*
+     * After unmapping we are free to shift the VBT by
+     * an arbitrary number of bytes. For efficient use
+     * of memory and to keep the memory map simple,
+     * place the VBT contiguous after the OpRegion.
+     */
+    rvda_guest = igd_guest_opregion + IGD_OPREGION_SIZE;
+    printf("guest VBT address: 0x%lx\n", rvda_guest);
+
+    /*
+     * Until now, rvda_guest has been an absolute address
+     * in the guest. We need to translate it to a relative
+     * address if OpRegion version > 0x0200 and in that case
+     * we also verify it is contiguous with the OpRegion.
+     */
+    if ( version > 0x0200 ) {
+        rvda_guest -= igd_guest_opregion;
+        printf("guest rvda (relative): 0x%lx\n", rvda_guest);
+        BUG_ON(rvda_guest != IGD_OPREGION_SIZE);
+    }
+
+    /*
+     * Write the correct rvda_guest value to the
+     * guest copy of the OpRegion and copy the scratch
+     * buffers to the correct address in our E820 region.
+     */
+    *(unsigned long *)(opregion_scratch + IGD_OPREGION_RVDA) = rvda_guest;
+    memcpy((void *)(igd_guest_opregion + IGD_OPREGION_SIZE),
+           (const void *)vbt_scratch, rvds);
+    memcpy((void *)igd_guest_opregion,
+           (const void *)opregion_scratch, IGD_OPREGION_SIZE);
+}
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c41c8d9..07a37e5 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -43,7 +43,6 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 #define BAR_RELOC_THRESH GB(1)
 
 enum virtual_vga virtual_vga = VGA_none;
-unsigned long igd_opregion_pgbase = 0;
 
 /* Check if the specified range conflicts with any reserved device memory. */
 static bool check_overlap_all(uint64_t start, uint64_t size)
@@ -190,14 +189,7 @@ void pci_setup(void)
                 virtual_vga = VGA_pt;
                 if ( vendor_id == 0x8086 )
                 {
-                    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
-                    /*
-                     * Write the the OpRegion offset to give the opregion
-                     * address to the device model. The device model will trap 
-                     * and map the OpRegion at the give address.
-                     */
-                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
-                               igd_opregion_pgbase << PAGE_SHIFT);
+                    intel_opregion_setup(vga_devfn);
                 }
             }
             break;
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 05:21:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 05:21:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380496.1624286 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqOdO-0005rZ-IR; Sun, 02 Aug 2026 05:21:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380496.1624286; Sun, 02 Aug 2026 05:21:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqOdO-0005rS-Eo; Sun, 02 Aug 2026 05:21:14 +0000
Received: by outflank-mailman (input) for mailman id 1380496;
 Sun, 02 Aug 2026 05:21:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@netscape.net>) id 1wqOdM-0005rM-LP
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 05:21:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqOdM-007bSz-2L
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 07:21:12 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6ed3a3-2eae-0a2a0a5409dd-0a2a4502a064-24
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 07:21:11 +0200
Received: from [98.137.65.84] (helo=sonic313-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6ed3c1-6ca4-0a2a45020019-62894154a0ab-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 07:21:06 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Aug 2026 05:21:04 +0000
Received: by hermes--production-ne1-6f6bdbdd7c-6qsrs (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 5835b75ab342781156a842e5dbde47e3; 
 Sun, 02 Aug 2026 05:20:59 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=netscape.net header.i="@netscape.net" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1785648064; bh=tj8RIhqOXdYnx1HcBJgeOZ7JZFvUwTdqF2qHquu6/eY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=uM+GbcJXRELucFBpSuvdtKd651VUtycEdshz8fG/EiRQTobl81p0wUbTNIH/94GfkzLtYIOSgWp6md5FHLZWigqffnUQf16VyoV59oa9u+VpeDvmQI8qiIAW7IzLVpFYYjWj0hF2Hh6UPqCWArNlfOzHbPfP6BLcU1Oe7lBGPkTEgpe7p+dntSLfOxKOomM6kYxy0GReFSzIWGk6uLllg96poEFKHd8OW0w0eqZ7aSyFR1Bw6xgWiQVjSvPa3e3C328KSCIPg4r2rUZN9ybWRobWvNTach37Tz2HUSxKAqH331w8P9Ppaj2S+z7diZMN9Yo4YW94q8JtOA1JIUuQTw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785648064; bh=t8hnSLzTo5kXfTM5hXR5EvB4kIcyJhJM2cMOg/DaYOH=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=q9XFzQB+uRnY/8nG1EyN6FiEDVpjw3CtgJBtwvV3xt4i7eFoPpLfhFN1xdCcGwJ1XDYR5/uVkOXQgMOa6ODDU7PSQmtGq4Do8JWB6NgOV/m9LU4c1WI+ANcTuPysyfCIHVUC9vKqb3b59Ule5q+Q8FrB0DNIg/KExaZt+YTo8UqmYI4H0xFPnVn3+PN36cRTxMOn8InpWrFhc+m1hJQ7oNeK8qCxqNjxK5Y+w5pvX8m6VcJj/ee7+AOnnVqND3ulvYP1ctCwKLs2frVwW8vsmw4wHIiUnmvWu11XMcPdrnwXfu+WPa6bM7xH/G19ry/kOtb9ECxE2ZJzNDyOeE5HIg==
X-YMail-OSG: B20biegVM1m4M_E0_N8TgVHgJZVXgPEFW.EPK7OG2ck_G.8tS3APhCpKfINB4BR
 iNfxePBW22b.pAV8RV1jE61zJLRWwLB3fgxSkSA3Rua3bGZnezUxc4ThKkm8_JhG8e.ZYztgiHEE
 1qqvfCsm7bq4A_bfai3i.SvQ4q7donDdGwRd828_V2j7ZrSlaR40tFc_7gbM8lD1APqJKYkKyTXj
 0JRG9_vxgj.4mYuY2X_BJwa.x93P553TsyJ2Hw_0V3v0Ihg_OkcIcXi4Y3SL0wSOFAVDJlXIx0qz
 U6RRgk6fRIftJZD4MpOYVSI7QulxWb3VTQLEBJWG8VQs_jw7toL9ncE2U6CyZOvnH6f_3SidGIe9
 XscUkOMgCZTuA0CN5_3G46qA1yiga9Bwl0G7Qrjg3WTIeQk0g6HLUJmhNbCvmTaNtVxLMNCwh4UM
 UNm1dQYPR.U83X_zGHeJJ9xRLd2ZVT6EviMeXoFo2yNDzzKXVk0irlzxLRvlDajnnOG_oemKpdae
 DsHjdAKn2yKa57WN3k_nf5nMQ2BalpXLiS8lcNHekwWbK3mmAqx37oJtNkqKlMTc2Uhx6YHWRY8o
 efxOgBKhF.VRc9lOJHgDKRfzZ9bB0qvMQyy_JOouP5kFc_CMwZUtvDBmmLo7PT90VeududwI80fx
 UDd06PbEwkVUOZDAFs9EyDyMzRtlTsaDhkuFqLwpXoDGzoiZbfecZ8BmV2ss1sb5URIeP9gS51Ul
 p76kAClPUP4iWVjq5C5lZYe5PH4NCBPsp72b9NK1N5XI_XxIRdVqgrSOHrAivwBMnNEEDr3uLc2M
 bpO8DcFlT71UqgJC9euVBqY4PVQdYd2W4s9RWkJZJNcjlGZZYR7_.hnwJB8oDS3aXbM2Lxd5tvXQ
 9Tw2TZ7zlxIrp_9qWZucCRWsYpyoonZ8Ko9CkpUqASOXQZSJLG1Ai3SzsZFqFywFlYYTAKsLGAVO
 Bw8Lji5QlOKmuuaXA368eSzt9kitbpy7H8GMa8YlGlVGW8CUQQ.b5HeiJFSx2C7Go6nQ2Ujj4c48
 2hQGvVxHXZ8NLawhIcz_onMH628gjjkxzhlpet_aEGNUNjuFv8FfB8hSJJtqqY_0GSrCqHHR0M3G
 JtI1ypRF6ty4mk7Upkv2Zpo_8WbR1Tttni5Ag_kPlY00Fo8tH2Vy6VjIvb6znRvwc7fIcUXWjctK
 TRXqOngvpIZTl4BWVHXurAUgq._bS0YWASxuqm5j1V0eDQCEfelSC4.M7hZcGewWyrtkpmfce7jL
 X2Vq08vfQhuN69egjkJdXEz7p7FTlK8docrjeVJ_iu2YRyFPHa.f0sfd8Wu.XsIGRsSxI3WLVvc3
 yk4h.0whU4e2n15r7JooWOIwB6BVBEiEiQYiW2erV8aiHw2y_Ny1xokZRboUFNw7hBE6oG8MhdvW
 XxmhINjJZsov012WaqUMI7gcnd03au52YBg5lX177k9pGsXBo53UNaO_oTjGm._paLVpKV0jNlmP
 NIzKrwSbujZrIJliKbFU.PxRErl3v.sD0ytrNWl7TpW5u2TMf1p7eh5J_CMv_FfZix9vkNpAyPY6
 jwglvLaJAEWlwT6Fli1.bX3JfuHt7tF.2bx4kflHRAQOk55f7aDfuE.w_0VSb3IeQo9uLfSuT2ZM
 NVkIJ6Dx5OgIzNhqlnXYQLVySZpoAucJATkeDpDNYmj9IRUTTuDdijGUEh7b5tcKxrxL7Mi8_xMl
 K6TulRyRn3933ydvBnQ7QX605_jM0NVsBQ563lwZvm.UR.BweH2IcqWANrC6_ME7rCIZ.rneMCB0
 kCqjJhqlxzUqDWRudre5WfFCYIdizhMtoDGS_KJcAKsFKQBsZv2LWhUhIODE3KMSwew73dSJ1r0S
 4ZXyLKxwjfoVGm8Xxl8NJuV0_dJ1WU4yCLVied4OB0Vu0SG3jVilMxzjRHmlrX2vgLlLR8Q6u8kw
 gvyJ3tdP_QVt2zrMGyVC9QbWz8rEdDhKNDsGgjcFTnJmpRIu.h7C.5JRmBRLAgzV3JxK4iywNf7r
 nbt4jia3is41lqIZ.j1WZ_bhr4qJhi0WDaEr5brB.p__FT1jcyY1k8KUbSvlWFWd99Dn0nAgY65V
 KYkaie6JQ0DvkwQsVYEVGqH.5h7xDE5NDf6OrorVqjRgGCIPqZ2jJGRveUxj_ahe9nooHR8ad.E6
 x8X.5VUsTTN8W.L.Fj0P7fVPxS2j7cOdGLJCpyKISGHgZdQm7LB4uQwaVJDYBLkPXo9rRhrab0gP
 6_KHg3VKhh8Qa0do8eQFV4m3ArFa5ug5MwjlzaRUd
X-Sonic-MF: <brchuckz@netscape.net>
X-Sonic-ID: d6e338b6-534f-401f-a6d0-d7bde3049c82
Message-ID: <60f1e89b-f0a7-41b8-a9b2-e0ae97b69b36@netscape.net>
Date: Sun, 2 Aug 2026 01:20:57 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 0/6] xen/igd: fixes for Intel IGD passthrough
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony@xenproject.org>,
 "Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>
References: <20260801001737.16509-1-brchuckz.ref@aol.com>
 <20260801001737.16509-1-brchuckz@aol.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@netscape.net>
In-Reply-To: <20260801001737.16509-1-brchuckz@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26215 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 539
X-purgate-ID: tlsNG-720697/1785648071-F2EB32AC-7212A09B/0/0
X-purgate-type: clean
X-purgate-size: 555

On 7/31/26 8:17 PM, Chuck Zmudzinski wrote:
> Please note that Patch 5 of this series also requires a patch
> to hvmloader of Xen for the new support to take effect that
> is available here:
> 
> https://lore.kernel.org/qemu-devel/20260801000354.16446-1-brchuckz@aol.com/
> 

The patch to hvmloader of Xen that is required for the new support added in
Patch 5 of this patchset to take effect has been updated to version 2 and is
available here:

https://lore.kernel.org/qemu-devel/20260802050824.10554-1-brchuckz@aol.com/

Thanks,

Chuck


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 05:26:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 05:26:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380505.1624295 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqOil-0006Tq-7b; Sun, 02 Aug 2026 05:26:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380505.1624295; Sun, 02 Aug 2026 05:26:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqOil-0006Tj-4d; Sun, 02 Aug 2026 05:26:47 +0000
Received: by outflank-mailman (input) for mailman id 1380505;
 Sun, 02 Aug 2026 05:26:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@netscape.net>) id 1wqOij-0006Td-GQ
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 05:26:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqOii-0016Gv-PJ
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 07:26:44 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6ed4fc-2eae-0a2a0a5409dd-0a2a45099800-12
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 07:26:44 +0200
Received: from [98.137.68.204] (helo=sonic304-23.consmr.mail.gq1.yahoo.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a6ed512-be1a-0a2a45090019-628944ccb192-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 07:26:44 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Aug 2026 05:26:42 +0000
Received: by hermes--production-ne1-6f6bdbdd7c-dvlsw (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 11499ee497b205444310b641ae38b9f1; 
 Sun, 02 Aug 2026 05:26:40 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=netscape.net header.i="@netscape.net" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1785648402; bh=LH/ftC7GkUWQq6FB6XQBny4DcVZLjeM6/HaeFg9bv3w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=Yah76xINiQI8Aa5SpWbJzbbV8erP/BHCmrBwMDQXSzEc7PeE2PEnVpsAOQfTCNRFRH4wCbkqgbQwZvmVX//B9xURciuDHjCwLUrgXK3YdfR/RGmvWRcHZxP8vxfUmrFfbabWwuE9nACL5iZbREkYmoOitTQkYoxGVKo2FrLGPUM2wjk3f9JaTP6IjE0T4SmD2VKwrdyS0p4khaKvIDPstYPu2IrefrijQBWe/CeB2RrmocuhP/ksBoV5HCexU7Qsiow54+gCOHzMz6YjUrTFOvd+oGPxAkafQldFBBFEWrWj6KkISpPvqEtORDLXxt2mwGMJj+1kAapcE88Rl0UxzQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785648402; bh=MAFVCLLvA0klvEZcVA5etVjnRgqlL0lGl7k0CnhiFb3=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=nZk8q/7/fq/CD2AbOuARFOh3y0FI79kWvSlWMiRySvCh+pk07CQulJKMf9NCanDCKaXxzg1iK9MAeMftQ6A1YvkprwdaGFQVxRt77vA0tTC1xd6Z0wJyey1zowSDO5dtF0mpYkoZ4dw1NVAVBTH3idmmEvFDrE9uEQ98VBXwRkk6RCLmeFIX+wBqFRNm7Sr5OuTExy+rznYmCzsfUPoLpCI9O0dYsV/7HJmkidt9CK9FIcp7lyjiiQk3SV6vPiHRCBOJV2ctb5FVkpht34zhs7txDE6+GFzErfEgK5OcJka4YEkQiYxBGzw6Jx4CCY2pMzHFtFaYc6ONpa3BN3H4pA==
X-YMail-OSG: IUYVv7QVM1ksrzGFnH34ZNa9tFKOa0UEiqQf8uWRUH518rC13_b5BhBg10Hv8aS
 FU.tLcrzA6dcAldNQwxkdReWoWUrWqmbk1yPxUno_wB92sn8NFLXp3rMXiUWrp.Jwr_wIk6a05ct
 mDVueUgAnXuOd_IHHGLcyuxG8BaGg29WaFAwd8Wt3CkCQYEb_46ks0Y3o34FB1NJtV.7yUAcgDLX
 hCuHV6LGD6.l6_fQrNVr.tLgfRWe20MPYRxtxEbwiKnHYsCmzxh2pD2y6W1YZdOCOE5WFNLV1tXg
 OgHQFfmIbAUSdURf6fjDV1u29yv8Af8OIj5tYTiLkYvFKe2aeseKsKDc4Qx41uyXaP60_JiQunqp
 PI8v_hSfVibZ65RTO5YM2DNm7dD9VWbl8ZZ5zM24Doiu.VQqNqrknB89wmYYN9AEOepTaefP7BeJ
 i6_AUqPY.te8V3OvI7OgXIYYXNNVKIQf_OsubclGSyXmUIAaMoJ7Kxm5xoxZNs1dq00pBSp9dV1C
 Jioq0Mg_HghYB6iJq5BzQ4GB3drAPwnUEJVSpxNKAbrMJj3HyF3s0gk_zGzA9y6etqbaIk9EfuSs
 uDeFvKVgxNrOnPCaFluN0lSKk6tC2srKBc5qoiU1.Gfx8jrT.wFa1plpNsOlEskrsm6tz.uogNR3
 ZWpUGpoxscWgBPDOqtR5dt5cggZ49CLyV1S.JalcD_HNDbfio7JGD0BP_WuEGGQRsOPMWbNlCtjp
 4mGDqg1iKqWpM.HuSOsbek4mDKfZHbLLWYQHNgXUDwliTzFgPPBg.nb2RpjhQ8yxe4NE06upj4S9
 OHRhMyugeqIGPmdH6To0wIXdGZXZIC6FmFDDUPehbtL5Luv8I3VbuACP1GrWvxttds8S8dRGFrWj
 Yr4W0IPeqdVmVrsJbuUOdW8vyQNRNnSJf3cUn027m2vY0g6u9LzsgSmMbJz1MuaKj_LzXX_98uV.
 m8XbzpSkuvjkTtpLr9gRFbEYZKOqDVrk72YDuF43jSCWQ1pM1sbhL4Qc9J3sHxhai6IloRQLLTcP
 lAjshWJ0RWbBIl5U1ut2tM0_7jCj3Ci0jbW.3V9x648RDarmxbWK0s5OOcWbYD9cxur8vpv0mBnl
 6LIt81l.a8261OM_S1o6Erh8yNzFcxNzrJsCkDEvPwqRadClrzzmCxEVywO2LFKoeItpWvxXGJkP
 sb1VgYRzAA_9o8rswI3I6utxqNbGhnUMmqBwwK0nWU52nqb2i5qvRNzKdhRJD2QmdXvdR4HSZLq_
 pkpegqCUaixQSQdQwN8mH8zUzoaKvVEccrzU7KsUcIfpcwbzei0MWx3Mca5Su_3UzD5HS.aIte9Y
 aEXw1NEObI1Dt_EZ94wZIr4fwJcafoOkHCkgXa8yxbWFCA__17aHCSEbE9laLwrRkaYhJrObrOGE
 Q2Y10r7wfdxhOsQ4u0okTzplvnSLkHHrDu6wZlvTrpgsYodk3f3g48vteAorOOP73MRQBaQZovhR
 NnqXxc9lPAnu1Gooy.G3D2H.XSGPCGy748JEEfzKc8lZgc6UEeqBhRjQgUh8N6pZ3NZLD5j7qDCH
 uBggtT983z95bZb4v6X.l8NuEzgutHRNw_u0DsXWTlQunY9kDqjTh1Q25rlRiAdx0R23ZmZTd1yK
 paQSaX0Bgjj8QNdrNAF6f2voB4qew9AVALIel07ru7rRu9Px9gax0l39SDgQe2eGLfYkN8uOEyIB
 94FcytGQAjyF1_fWNwAud5fn4Q785HkLI6r7mvydaXGFBs3afHf3bitJmpkOGDheEZ.rzcsKJ8uq
 tf86tKay6tUd4WAq9YOrBqwmrdVW1P8ndt4x9y4xZo07L5GUrfSpmbAfD7gEzjpxVOagIvPrmAF5
 YenGnj51OQe0QuKcJSYvusVbtl7Dzpwd574bfqO77owdnoCZB7xtjgSawIiH.T62Cj85c4uA8co9
 4qCCJqKCzRWERd8ZqghJFHomwUUzie0GEVfUpTeH73iiS_m5Iz9dmtsZTdaHiPTSq9q8s9eqgsn4
 hxd9GMlkEwXQcpgNIkH0bThGhoVpg2XQCdJtKSskJmyY0XbLEdgSygX1fouKklBqT7.Q4UGfUPi1
 8GHbAEsQ5wkAArOMjx0sG8.Pi.qToLk58dEMPasVQw_UbHZpNCNYBoqdtZRnwooll3GdaL3yNSko
 jG9BRCYlb4MJszbc84BKqpWBIXMO_HDNalw1T3yXH27DK8QODIvT4lmo_nTDlC0mNdq8Om0JBO19
 zeMOgC1NLmMtsm9lr0mNgYCAFD7Iy.Ols2GQ0z.w2p.q4qMo-
X-Sonic-MF: <brchuckz@netscape.net>
X-Sonic-ID: 9ef0d839-c41c-43b5-90aa-8784cfba1c62
Message-ID: <236b6db6-ddb2-4f60-935e-fcb153c1ab38@netscape.net>
Date: Sun, 2 Aug 2026 01:26:38 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/6] xen/igd: implement support for extended VBT
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony@xenproject.org>,
 "Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>
References: <20260801001737.16509-1-brchuckz@aol.com>
 <20260801001737.16509-6-brchuckz@aol.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@netscape.net>
In-Reply-To: <20260801001737.16509-6-brchuckz@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26215 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 389
X-purgate-ID: tlsNG-bad1c0/1785648404-BCCCF034-8C7A4A98/0/0
X-purgate-type: clean
X-purgate-size: 403

On 7/31/26 8:17 PM, Chuck Zmudzinski wrote:

> 
> The companion patch to hvmloader that is needed to make this patch take
> effect is available here:
> 
> https://lore.kernel.org/qemu-devel/20260801000354.16446-1-brchuckz@aol.com/

This patch has been update to version 2 and is available here:

https://lore.kernel.org/qemu-devel/20260802050824.10554-1-brchuckz@aol.com/

Thanks,

Chuck


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380622.1624358 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVx7-0004Nq-HK; Sun, 02 Aug 2026 13:10:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380622.1624358; Sun, 02 Aug 2026 13:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVx7-0004ND-DE; Sun, 02 Aug 2026 13:10:05 +0000
Received: by outflank-mailman (input) for mailman id 1380622;
 Sun, 02 Aug 2026 13:10:03 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVx5-0003vX-AA
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVx4-004d7k-NN
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:02 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f417e-2eae-0a2a0a5409dd-0a2a4502c3a4-28
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:02 +0200
Received: from [46.105.56.78] (helo=9.mo576.mail-out.ovh.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41a9-6ca4-0a2a45020019-2e69384ec885-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:02 +0200
Received: from director9.ghost.mail-out.ovh.net (unknown [10.110.43.163])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBx55Tjz5xWk
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:01 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-6sth2 (unknown [10.111.174.161])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id F1CB180F81;
 Sun,  2 Aug 2026 13:09:59 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-7d8d68f679-6sth2 with ESMTPSA
 id ljuXJadBb2qpHhgAK5rK4A
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-101G00462dcfbc5-c94d-471e-95e6-b257f1962b5d,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= <mateusz.mowka@intel.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 06/23] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap
Date: Sun,  2 Aug 2026 16:09:22 +0300
Message-ID: <15fc3a65709a6f132018589891d2de1602267f75.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4731312883743139260
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTFZ8AtnZpIyl6ET+v3fHmA+uYUkMD3DwZB0P07GRr8J86P8aEK0TrIgvEmvMk2UMHLQcrPmKka+msSt/0TaecPfdcx6Ctkzl/IQTPxfVtaP4//uOPzb7zuNCMwkPc0Fz4/OS0qT7MhCIRPFyW6pdcu9LLnVzpKpLjrKi5cvgJCqGdBXnNZmrQH54omClw/hNP24rkF6xCI8byjkJYQhTq3hW/2iAafs5tP1aMfaMB2SAbmrJsBH59VjqPkxz7VyIrdiwsxnEq+nYIOXwOIC83XPRbw8D2/WH8A/IIXngJ3UMgzTCeGDTtAXEJQRbBSYtkkUlETXIFPtHwFUuu0Mcfe4o1t6vxp/IU/vmFieuOyt8qybimr01gORxexKfJyCbeB7Yj/gnZsdUmouEAFzAvi3Po41psvqOoUGIAR7HZljOzTxLBWaxuw6Gl256ZBmLwbe2LlX9tgJFSRrro8rR9ANq31dTUndUnLQ9FGyyqTouFBLjEtcgT6v3m390YbGEG3TC3h6a5YoykNHwLORe+lqMFyuiu2QHakD5u8uhYJoTGFUZSv1uuHQYfELt2y96i9FK4SHjvLNroQKG9NtYhmuPgD1CQ9Tb/Lw5v8H/nCyUyskvp3wqUMlhixD8KeR2TzB3R2YDjigaghEKoNwvyxrakoecd2NmZFUmpdU9IUCEw
DKIM-Signature: a=rsa-sha256; bh=37ueSWxMjwvM39AlgHrUkrBrOhrpGYPMLbYZOxLndJg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676201; v=1;
 b=k2XQD9wrIIJggfjdTty2IWYNP5q/KXJVHy+FRX85kFtXtUmJOlensOjWMyAXWS9U6K65ZZPh
 SAAHGIMJ+fBY1HI3b6lo8ID2JOrjZHzh7O9X0RcfT3vjpBat0vrzZ8vdz2jMyJ+2gUIOSvKCu1R
 t11sSPD9uFQ0NRZZNllWxB7osBdUcMeEELHSvpKHfe2MbPfs97IyokpfLdTKLXsH9s3+xLfMjA2
 Kzqghv1po+zrmsoPRKoOUq0lbKjPTJnQR1suZsmnsg+bxpASfl6ozXXn7RkfRnWST+g4E8YaXAm
 Vp4yhuyTiCYkpD5fSzmkooQQkSDsUdAgZ4f3mNGx9MsAw==
X-purgate-ID: tlsNG-720697/1785676202-664B62AC-D71ACAD6/0/0
X-purgate-type: clean
X-purgate-size: 11357

From: Krystian Hebel <krystian.hebel@3mdeb.com>

The file contains base address of TXT register spaces, offsets of
registers within them, error codes and inline functions for accessing
structures stored on TXT heap.

xen/arch/x86/tboot.c is updated to use definitions from this new header
instead of duplicating them.  The change in tboot_protect_mem_regions()
there is caused by going from NR_TXT_CONFIG_PAGES to
TXT_CONFIG_SPACE_SIZE which avoids multiplying number of pages by page
size on every use.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: removed unused SLAUNCH_ERROR_* #defines
    v4: __ASSEMBLY__ => __ASSEMBLER__
    v4: added back halt() loop before unreachable() in txt_reset() as reset is apparently asynchronous
    v4: replaced txt_*_{start,size}() with an enumeration and txt_{start,size}() that iterate over entries
    v4: NR_TXT_CONFIG_SIZE => TXT_CONFIG_SPACE_SIZE in one place (this was renamed but one use remained unchanged)

 xen/arch/x86/include/asm/intel-txt.h | 250 +++++++++++++++++++++++++++
 xen/arch/x86/tboot.c                 |  20 +--
 2 files changed, 252 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/intel-txt.h

diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
new file mode 100644
index 0000000000..15d474f002
--- /dev/null
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -0,0 +1,250 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Intel TXT is an implementation of DRTM in CPUs made by Intel (although CPU
+ * alone isn't enough, chipset must support TXT as well).
+ *
+ * Overview:
+ *   https://www.intel.com/content/www/us/en/support/articles/000025873/processors.html
+ * Software Development Guide (SDG):
+ *   https://www.intel.com/content/www/us/en/content-details/315168/
+ */
+
+#ifndef X86_INTEL_TXT_H
+#define X86_INTEL_TXT_H
+
+/*
+ * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
+ */
+#define TXT_PUB_CONFIG_REGS_BASE        0xfed30000U
+#define TXT_PRIV_CONFIG_REGS_BASE       0xfed20000U
+
+/*
+ * The same set of registers is exposed twice (with different permissions) and
+ * they are allocated continuously with page alignment.
+ */
+#define TXT_CONFIG_SPACE_SIZE \
+    (TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE)
+
+/* Offsets from pub/priv config space. */
+#define TXTCR_STS                       0x0000
+#define TXTCR_ESTS                      0x0008
+#define TXTCR_ERRORCODE                 0x0030
+#define TXTCR_CMD_RESET                 0x0038
+#define TXTCR_CMD_CLOSE_PRIVATE         0x0048
+#define TXTCR_DIDVID                    0x0110
+#define TXTCR_VER_EMIF                  0x0200
+#define TXTCR_CMD_UNLOCK_MEM_CONFIG     0x0218
+#define TXTCR_SINIT_BASE                0x0270
+#define TXTCR_SINIT_SIZE                0x0278
+#define TXTCR_MLE_JOIN                  0x0290
+#define TXTCR_HEAP_BASE                 0x0300
+#define TXTCR_HEAP_SIZE                 0x0308
+#define TXTCR_SCRATCHPAD                0x0378
+#define TXTCR_CMD_OPEN_LOCALITY1        0x0380
+#define TXTCR_CMD_CLOSE_LOCALITY1       0x0388
+#define TXTCR_CMD_OPEN_LOCALITY2        0x0390
+#define TXTCR_CMD_CLOSE_LOCALITY2       0x0398
+#define TXTCR_CMD_SECRETS               0x08e0
+#define TXTCR_CMD_NO_SECRETS            0x08e8
+#define TXTCR_E2STS                     0x08f0
+
+/*
+ * Secure Launch Defined Error Codes used in MLE-initiated TXT resets.
+ *
+ * TXT Specification
+ * Appendix I ACM Error Codes
+ */
+#define SLAUNCH_ERROR_INTEGER_OVERFLOW  0xc0008001U
+#define SLAUNCH_ERROR_HI_PMR_BASE       0xc0008002U
+#define SLAUNCH_ERROR_LO_PMR_BASE       0xc0008003U
+#define SLAUNCH_ERROR_LO_PMR_SIZE       0xc0008004U
+#define SLAUNCH_ERROR_LO_PMR_MLE        0xc0008005U
+#define SLAUNCH_ERROR_BUFFER_BEYOND_PMR 0xc0008006U
+#define SLAUNCH_ERROR_HEAP_BAD_OS2MLE   0xc0008007U
+#define SLAUNCH_ERROR_HEAP_BAD_OS2SINIT 0xc0008008U
+
+#ifndef __ASSEMBLER__
+
+/* Need to differentiate between pre- and post paging enabled. */
+#ifdef __EARLY_SLAUNCH__
+#include <xen/macros.h>
+#define _txt(x) _p(x)
+#else
+#include <xen/types.h>
+#include <asm/page.h>   /* __va() */
+#define _txt(x) __va(x)
+#endif
+
+/*
+ * Always use private space as some of registers are either read-only or not
+ * present in public space.
+ */
+static inline uint64_t txt_read(unsigned int reg_no)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    return *reg;
+}
+
+static inline void txt_write(unsigned int reg_no, uint64_t val)
+{
+    volatile uint64_t *reg = _txt(TXT_PRIV_CONFIG_REGS_BASE + reg_no);
+    *reg = val;
+}
+
+static inline void noreturn txt_reset(uint32_t error)
+{
+    txt_write(TXTCR_ERRORCODE, error);
+    txt_write(TXTCR_CMD_NO_SECRETS, 1);
+    txt_write(TXTCR_CMD_UNLOCK_MEM_CONFIG, 1);
+    /*
+     * Ignoring the result as this serves as a TXT register barrier after
+     * writing to TXTCR_CMD_UNLOCK_MEM_CONFIG. Must be done to ensure that any
+     * future chipset operations see the write.
+     */
+    txt_read(TXTCR_ESTS);
+    txt_write(TXTCR_CMD_RESET, 1);
+
+    while (true)
+    {
+        /*
+         * This is halt() from <asm/system.h>.  Can't include the file as it
+         * breaks early code compilation.
+         */
+        asm volatile ( "hlt" : : : "memory" );
+    }
+    unreachable();
+}
+
+/*
+ * Secure Launch defined OS/MLE TXT Heap table
+ */
+struct txt_os_mle_data {
+    uint32_t version;
+    uint32_t reserved;
+    uint64_t slrt;
+    uint64_t txt_info;
+    uint32_t ap_wake_block;
+    uint32_t ap_wake_block_size;
+    uint8_t mle_scratch[64];
+} __packed;
+
+/*
+ * TXT specification defined BIOS data TXT Heap table
+ */
+struct txt_bios_data {
+    uint32_t version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */
+    uint32_t bios_sinit_size;
+    uint64_t reserved1;
+    uint64_t reserved2;
+    uint32_t num_logical_procs;
+    /* Versions >= 3 && < 5 */
+    uint32_t sinit_flags;
+    /* Versions >= 5 with updates in version 6 */
+    uint32_t mle_flags;
+    /* Versions >= 4 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * TXT specification defined OS/SINIT TXT Heap table
+ */
+struct txt_os_sinit_data {
+    uint32_t version;       /* Currently 6 for TPM 1.2 and 7 for TPM 2.0 */
+    uint32_t flags;         /* Reserved in version 6 */
+    uint64_t mle_ptab;
+    uint64_t mle_size;
+    uint64_t mle_hdr_base;
+    uint64_t vtd_pmr_lo_base;
+    uint64_t vtd_pmr_lo_size;
+    uint64_t vtd_pmr_hi_base;
+    uint64_t vtd_pmr_hi_size;
+    uint64_t lcp_po_base;
+    uint64_t lcp_po_size;
+    uint32_t capabilities;
+    /* Version = 5 */
+    uint64_t efi_rsdt_ptr;  /* RSD*P* in versions >= 6 */
+    /* Versions >= 6 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * TXT specification defined SINIT/MLE TXT Heap table
+ */
+struct txt_sinit_mle_data {
+    uint32_t version;  /* Current values are 6 through 9 */
+    /* Versions <= 8, fields until lcp_policy_control must be 0 for >= 9 */
+    uint8_t bios_acm_id[20];
+    uint32_t edx_senter_flags;
+    uint64_t mseg_valid;
+    uint8_t sinit_hash[20];
+    uint8_t mle_hash[20];
+    uint8_t stm_hash[20];
+    uint8_t lcp_policy_hash[20];
+    uint32_t lcp_policy_control;
+    /* Versions >= 7 */
+    uint32_t rlp_wakeup_addr;
+    uint32_t reserved;
+    uint32_t num_of_sinit_mdrs;
+    uint32_t sinit_mdrs_table_offset;
+    uint32_t sinit_vtd_dmar_table_size;
+    uint32_t sinit_vtd_dmar_table_offset;
+    /* Versions >= 8 */
+    uint32_t processor_scrtm_status;
+    /* Versions >= 9 */
+    /* Ext Data Elements */
+} __packed;
+
+/*
+ * Functions to extract data from the Intel TXT Heap Memory.
+ *
+ * The layout of the heap is dictated by TXT. It's a set of variable-sized
+ * tables that appear in pre-defined order:
+ *
+ *   +------------------------------------+
+ *   | Size of Bios Data table (uint64_t) |
+ *   +------------------------------------+
+ *   | Bios Data table                    |
+ *   +------------------------------------+
+ *   | Size of OS MLE table (uint64_t)    |
+ *   +------------------------------------+
+ *   | OS MLE table                       |
+ *   +--------------------------------    +
+ *   | Size of OS SINIT table (uint64_t)  |
+ *   +------------------------------------+
+ *   | OS SINIT table                     |
+ *   +------------------------------------+
+ *   | Size of SINIT MLE table (uint64_t) |
+ *   +------------------------------------+
+ *   | SINIT MLE table                    |
+ *   +------------------------------------+
+ *
+ * NOTE: the table size fields include the 8 byte size field itself.
+ *
+ * NOTE: despite SDG mentioning 8-byte alignment, at least some BIOS ACM modules
+ *       were observed to violate this requirement for Bios Data table, so not
+ *       enforcing any alignment.
+ */
+enum {
+    TXT_BIOS,
+    TXT_OS2MLE,
+    TXT_OS2SINIT,
+    TXT_SINIT2MLE,
+};
+static inline uint64_t txt_size(const void *heap, int table_index)
+{
+    int i;
+    for (i = 0; i < table_index; ++i)
+        heap += *(const uint64_t *)heap;
+    return *(const uint64_t *)heap - sizeof(uint64_t);
+}
+static inline void *txt_start(void *heap, int table_index)
+{
+    int i;
+    for (i = 0; i < table_index; ++i)
+        heap += *(const uint64_t *)heap;
+    return heap + sizeof(uint64_t);
+}
+
+#endif /* !__ASSEMBLER__ */
+
+#endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index 5ae27f481f..e914177689 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -17,6 +17,7 @@
 #include <asm/setup.h>
 #include <asm/tboot.h>
 #include <asm/trampoline.h>
+#include <asm/intel-txt.h>
 
 #include <crypto/vmac.h>
 
@@ -37,23 +38,6 @@ static uint64_t __initdata sinit_base, __initdata sinit_size;
 
 static bool __ro_after_init is_vtd;
 
-/*
- * TXT configuration registers (offsets from TXT_{PUB, PRIV}_CONFIG_REGS_BASE)
- */
-
-#define TXT_PUB_CONFIG_REGS_BASE       0xfed30000U
-#define TXT_PRIV_CONFIG_REGS_BASE      0xfed20000U
-
-/* # pages for each config regs space - used by fixmap */
-#define NR_TXT_CONFIG_PAGES     ((TXT_PUB_CONFIG_REGS_BASE -                \
-                                  TXT_PRIV_CONFIG_REGS_BASE) >> PAGE_SHIFT)
-
-/* offsets from pub/priv config space */
-#define TXTCR_SINIT_BASE            0x0270
-#define TXTCR_SINIT_SIZE            0x0278
-#define TXTCR_HEAP_BASE             0x0300
-#define TXTCR_HEAP_SIZE             0x0308
-
 #define SHA1_SIZE      20
 typedef uint8_t   sha1_hash_t[SHA1_SIZE];
 
@@ -411,7 +395,7 @@ int __init tboot_protect_mem_regions(void)
 
     /* TXT Private Space */
     rc = e820_change_range_type(&e820, TXT_PRIV_CONFIG_REGS_BASE,
-                 TXT_PRIV_CONFIG_REGS_BASE + NR_TXT_CONFIG_PAGES * PAGE_SIZE,
+                 TXT_PRIV_CONFIG_REGS_BASE + TXT_CONFIG_SPACE_SIZE,
                  E820_RESERVED, E820_UNUSABLE);
     if ( !rc )
         return 0;
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380619.1624340 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVwz-0003Dr-TK; Sun, 02 Aug 2026 13:09:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380619.1624340; Sun, 02 Aug 2026 13:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVwz-0003Dk-Q7; Sun, 02 Aug 2026 13:09:57 +0000
Received: by outflank-mailman (input) for mailman id 1380619;
 Sun, 02 Aug 2026 13:09:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVwy-0003CL-Iy
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:09:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVwx-004d7k-W6
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:09:56 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4195-2eae-0a2a0a5409dd-0a2a4507dfe0-20
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:55 +0200
Received: from [188.165.52.147] (helo=8.mo560.mail-out.ovh.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41a3-b4ea-0a2a45070019-bca53493ae4b-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:55 +0200
Received: from director5.ghost.mail-out.ovh.net (unknown [10.109.249.22])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBp6RdjzB4vx
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:09:54 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-vd989 (unknown [10.110.178.131])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 22D9610014F;
 Sun,  2 Aug 2026 13:09:53 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.114])
 by ghost-submission-7d8d68f679-vd989 with ESMTPSA
 id TPz6M6FBb2qoXxsAp+IlDQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-114S008a36bb849-095f-4e42-92f9-3b91a7ad8aa0,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 04/23] x86/tpm.c: support extending PCRs of TPM2.0 via TIS
Date: Sun,  2 Aug 2026 16:09:20 +0300
Message-ID: <037a0134f174f76a28754848446430eca1ad0e36.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4729342561658414524
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTFiq8m7bQTuMp+kHfkzWccLWGLiQDKFabJ2RhDT9kfSCdofJQR0IvQFrevpmIyB+jnOmWgMITL1LVlUdujF/88Dy35XfmsnynnsdO5Xa4QZ6Gc6PwZL/w0OaybZqkAliIuAt3zKOqs8qNDyeged1T+HCIn38vZ4164Thxki6LcZk2mWbVf0lh3liuwuFkaWODA5MvDecSoe9+O3Y32ZXF0UgxCi2WcxOeNMSvMwvsFTMPUzkDUeexFvnw7jvdCv07SWscXglPm5ceMWU9Pt/FCybH4TixDs6/CyEmv3wohSL4ZxKHESdLK6bja1pMVMnC16ZdsXken8EiAcdvwD4XzyXGPFS3hYmeie7FdIUOE5QWBGgI95OgiDchtHk8AWo+2oI3iXP1bWpFiBpfjFw7XkwiCcsmMpd5JGWoCTO9ln1V3GOHKQ+3v/z2vrxr5TrzGXksBG88OrnF3qxHU9gZMYG4ZmzXbhW0q3dbiWb5AmmlJ6n8+XBeXQQQU4mbTLv0c20a2oOwJeOt0yVTAPwWic/jlpb4N/4sGPhKDX4aV+uncP6S58hM+JhJpW4P+WYRRr5xuJuhw6Ek0eucXCSKTp/XsBh6keFof4XswHBt5G3VlzuLjEy6B003jcLtTOE3soSRxoEcrlmo98eKZ0n1wyCke1EXI7fxmj9C5SdoKVAQ
DKIM-Signature: a=rsa-sha256; bh=q07hwwp6TmxzYBwgs2/61Pp5yrXD10YTmVaY8Lj0LRA=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676194; v=1;
 b=B1bFU+rM3wmZemXNRXx2RIohYao53dWNzs6q6/3wtafTHe3NHNX+J9csV299VomLkesyt2Zw
 chWnf94Gfs6/j1kG6/q50GbOPXhWAhlFYcmZPrGF7Ya63s/FR1+pi8AR+VJoLAeMB4BEF00/Llf
 GwfKT+3YX64sUB1yWyRBO4UtCKW+GMY20cL358rG4CZwWncgKC/ugvb7zyKEPuAFmisdaHTOYk7
 fWe/TahHE+DxHI+6kT5NZHCAyfevLMKeKS0F2InKPBQ2HZ7PDWtLmCc5jCj7S21aJcI//YKyznn
 EQyjRxFePqfxKZWHyhZRfCOkLfZw+1DlKLOq4tRHFCElA==
X-purgate-ID: tlsNG-ef75cf/1785676195-A6CDFAE4-5AFFB8EE/0/0
X-purgate-type: clean
X-purgate-size: 18905

SHA1 and SHA256 are hard-coded here, but their support by the TPM is
checked.

CRB isn't supported, only TPM1.2-like TIS interface is (data is passed
via writes and reads to/from a single-byte FIFO register).

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Szymon Acedański <accek@invisiblethingslab.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: was called "x86/tpm.c: support extending PCRs of TPM2.0"
    v4: adds xen/arch/x86/include/asm/tpm2.h with TPM2.0 declarations by TCG
    v4: detect CRB and do nothing (implemented separately)
    v4: put SPDX license comment on its own line
    v4: `unsigned` => `unsigned int`
    v4: replace uses of `swap16()` and `swap32()`
    v4: more error checks when parsing TPM responses
    v4: style fixes for `goto` labels and spacing

 xen/arch/x86/include/asm/tpm.h  |   5 +
 xen/arch/x86/include/asm/tpm2.h | 150 ++++++++++++++
 xen/arch/x86/tpm.c              | 340 +++++++++++++++++++++++++++++++-
 3 files changed, 489 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/tpm2.h

diff --git a/xen/arch/x86/include/asm/tpm.h b/xen/arch/x86/include/asm/tpm.h
index 06b54fb786..5fa883dad8 100644
--- a/xen/arch/x86/include/asm/tpm.h
+++ b/xen/arch/x86/include/asm/tpm.h
@@ -57,6 +57,11 @@ bool tpm_is_tpm1(void);
  * The list of hashes must either be empty or contain nothing but SHA1 hash when
  * tpm_is_tpm1() returns true.
  *
+ * When tpm_is_tpm1() returns false, the list of digests can also be used to
+ * determine which hashes to extend.  The only hashes that are guaranteed to be
+ * supported are SHA1 and SHA256, all other digests need to be pre-filled by
+ * the caller with some placeholder value.
+ *
  * Returns:
  *  - TPM error code when < 4096 (0 means success)
  *  - TPM_INTERNAL_ERROR on invalid invocation or a failure to communicate with
diff --git a/xen/arch/x86/include/asm/tpm2.h b/xen/arch/x86/include/asm/tpm2.h
new file mode 100644
index 0000000000..4565d302f3
--- /dev/null
+++ b/xen/arch/x86/include/asm/tpm2.h
@@ -0,0 +1,150 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * TPM2.0-related definitions defined by Trusted Computing Group (TCG).
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#ifndef X86_TPM2_H
+#define X86_TPM2_H
+
+#include <xen/inttypes.h>
+
+#include <asm/tpm.h>
+
+/*
+ * These constants are for TPM2.0 but don't have a distinct prefix to match
+ * names in the specification.
+ */
+
+#define TPM_HT_PCR   0x00
+
+#define TPM_RH_NULL  0x40000007
+#define TPM_RS_PW    0x40000009
+
+#define HR_SHIFT     24
+#define HR_PCR       (TPM_HT_PCR << HR_SHIFT)
+
+#define TPM_ST_NO_SESSIONS  0x8001
+#define TPM_ST_SESSIONS     0x8002
+
+#define TPM2_PCR_Extend                 0x00000182
+#define TPM2_PCR_HashSequenceStart      0x00000186
+#define TPM2_PCR_SequenceUpdate         0x0000015C
+#define TPM2_PCR_EventSequenceComplete  0x00000185
+
+/* All fields of the following structs are big endian. */
+
+struct tpm2_session_header {
+    uint32_t handle;
+    uint16_t nonceSize;
+    uint8_t nonce[0];
+    uint8_t attrs;
+    uint16_t hmacSize;
+    uint8_t hmac[0];
+} __packed;
+
+struct tpm2_extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header pcrSession;
+    uint32_t hashCount;
+    uint8_t hashes[0];
+} __packed;
+
+struct tpm2_extend_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct tpm2_sequence_start_cmd {
+    struct tpm_cmd_hdr h;
+    uint16_t hmacSize;
+    uint8_t hmac[0];
+    uint16_t hashAlg;
+} __packed;
+
+struct tpm2_sequence_start_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t sequenceHandle;
+} __packed;
+
+struct tpm2_sequence_update_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t sequenceHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header session;
+    uint16_t dataSize;
+    uint8_t data[0];
+} __packed;
+
+struct tpm2_sequence_update_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct tpm2_sequence_complete_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrHandle;
+    uint32_t sequenceHandle;
+    uint32_t sessionHdrSize;
+    struct tpm2_session_header pcrSession;
+    struct tpm2_session_header sequenceSession;
+    uint16_t dataSize;
+    uint8_t data[0];
+} __packed;
+
+struct tpm2_sequence_complete_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t paramSize;
+    uint32_t hashCount;
+    uint8_t hashes[0];
+    /*
+     * Each hash is represented as:
+     * struct {
+     *     uint16_t hashAlg;
+     *     uint8_t hash[size of hashAlg];
+     * };
+     */
+} __packed;
+
+/* The structures below are for TPM event log and these are in little-endian. */
+
+struct tpm2_pcr_event_header {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint32_t digestCount;
+    uint8_t digests[0];
+    /*
+     * Each hash is represented as:
+     * struct {
+     *     uint16_t hashAlg;
+     *     uint8_t hash[size of hashAlg];
+     * };
+     */
+    /* uint32_t eventSize; */
+    /* uint8_t event[0]; */
+} __packed;
+
+struct tpm2_digest_sizes {
+    uint16_t algId;
+    uint16_t digestSize;
+} __packed;
+
+struct tpm2_spec_id_event {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint8_t digest[20];
+    uint32_t eventSize;
+    uint8_t signature[16];
+    uint32_t platformClass;
+    uint8_t specVersionMinor;
+    uint8_t specVersionMajor;
+    uint8_t specErrata;
+    uint8_t uintnSize;
+    uint32_t digestCount;
+    struct tpm2_digest_sizes digestSizes[0]; /* variable number of members */
+    /* uint8_t vendorInfoSize; */
+    /* uint8_t vendorInfo[vendorInfoSize]; */
+} __packed;
+
+#endif /* X86_TPM2_H */
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index 9efaf75440..59bb1ff2c4 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -12,11 +12,13 @@
 
 #include <xen/byteorder.h>
 #include <xen/sha1.h>
+#include <xen/sha2.h>
 #include <xen/string.h>
 #include <xen/types.h>
 
 #include <asm/tpm.h>
 #include <asm/tpm1.h>
+#include <asm/tpm2.h>
 
 #ifdef __EARLY_TPM__
 
@@ -75,6 +77,22 @@ static void tpm_write8(unsigned int reg, uint8_t val)
     *(volatile uint8_t *)__va(TPM_MMIO_BASE + reg) = val;
 }
 
+/************************** Interface detection *******************************/
+
+#define TPM_INTF_ID_(x)         TPM_LOC_REG(x, 0x30)
+#define INTF_TYPE_MASK           0x0000000fU
+#define INTF_TYPE_TIS            0x00
+#define INTF_TYPE_CRB            0x01
+
+/*
+ * No static caching: the early 32-bit binary (tpm_early.bin) is built with
+ * "objcopy -j .text", which omits .bss/.data.
+ */
+static bool tpm_is_crb(void)
+{
+    return (tpm_read32(TPM_INTF_ID_(0)) & INTF_TYPE_MASK) == INTF_TYPE_CRB;
+}
+
 /************************** TIS register definitions **************************/
 
 #define TIS_ACCESS_(x)          TPM_LOC_REG(x, 0x00)
@@ -181,24 +199,37 @@ static void tis_send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
 
 static void request_locality(unsigned int loc)
 {
-    tis_request_locality(loc);
+    if ( tpm_is_crb() )
+        return;
+    else
+        tis_request_locality(loc);
 }
 
 static void relinquish_locality(unsigned int loc)
 {
-    tis_relinquish_locality(loc);
+    if ( tpm_is_crb() )
+        return;
+    else
+        tis_relinquish_locality(loc);
 }
 
 static void send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
                      unsigned int *o_size)
 {
-    tis_send_cmd(loc, buf, i_size, o_size);
+    if ( tpm_is_crb() )
+        *o_size = 0;
+    else
+        tis_send_cmd(loc, buf, i_size, o_size);
 }
 
 bool tpm_is_tpm1(void)
 {
     uint32_t intf_version;
 
+    /* CRB interface is always TPM 2.0. */
+    if ( tpm_is_crb() )
+        return false;
+
     /*
      * If one of these conditions is true:
      *  - INTF_CAPABILITY_x.interfaceVersion is 0 (TIS <= 1.21)
@@ -211,14 +242,19 @@ bool tpm_is_tpm1(void)
             !(tpm_read32(TIS_STS_(0)) & STS_FAMILY_MASK));
 }
 
-/****************************** TPM1.2 specific *******************************/
+/****************************** TPM1.2 & TPM2.0 *******************************/
 
-#ifdef __EARLY_TPM__
 /*
  * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
  * go above that. Limit maximum size of block of data to be hashed to 1024.
+ *
+ * TPM2.0 should support hashing of at least 1024 bytes.
  */
 #define MAX_HASH_BLOCK      1024
+
+/****************************** TPM1.2 specific *******************************/
+
+#ifdef __EARLY_TPM__
 #define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
 
 union cmd_rsp {
@@ -382,6 +418,298 @@ static uint32_t tpm12_hash_extend(unsigned int loc, const uint8_t *buf,
 
 /************************** end of TPM1.2 specific ****************************/
 
+/****************************** TPM2.0 specific *******************************/
+
+#ifdef __EARLY_TPM__
+
+union tpm2_cmd_rsp {
+    uint8_t b[sizeof(struct tpm2_sequence_update_cmd) + MAX_HASH_BLOCK];
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct tpm2_sequence_start_cmd start_c;
+    struct tpm2_sequence_start_rsp start_r;
+    struct tpm2_sequence_update_cmd update_c;
+    struct tpm2_sequence_update_rsp update_r;
+    struct tpm2_sequence_complete_cmd finish_c;
+    struct tpm2_sequence_complete_rsp finish_r;
+};
+
+static uint32_t tpm2_hash_extend(unsigned int loc, const uint8_t *buf,
+                                 unsigned int size, unsigned int pcr,
+                                 const struct tpm_log_hashes *log_hashes)
+{
+    uint32_t seq_handle;
+    unsigned int max_bytes = MAX_HASH_BLOCK;
+
+    union tpm2_cmd_rsp cmd_rsp;
+    unsigned int o_size;
+    unsigned int i;
+    uint8_t *p;
+    uint32_t rc;
+
+    cmd_rsp.start_c = (struct tpm2_sequence_start_cmd) {
+        .h.tag = cpu_to_be16(TPM_ST_NO_SESSIONS),
+        .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.start_c)),
+        .h.ordinal = cpu_to_be32(TPM2_PCR_HashSequenceStart),
+        /* Compute all supported hashes. */
+        .hashAlg = cpu_to_be16(TPM_ALG_NULL),
+    };
+
+    request_locality(loc);
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+
+    if ( o_size < sizeof(struct tpm_rsp_hdr) )
+    {
+        rc = TPM_INTERNAL_ERROR;
+        goto error;
+    }
+    rc = be32_to_cpu(cmd_rsp.r.returnCode);
+    if ( rc != 0 )
+        goto error;
+
+    seq_handle = be32_to_cpu(cmd_rsp.start_r.sequenceHandle);
+
+    while ( size > 64 )
+    {
+        if ( size < max_bytes )
+            max_bytes = ROUNDDOWN(size, 64);
+
+        cmd_rsp.update_c = (struct tpm2_sequence_update_cmd) {
+            .h.tag = cpu_to_be16(TPM_ST_SESSIONS),
+            .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.update_c) + max_bytes),
+            .h.ordinal = cpu_to_be32(TPM2_PCR_SequenceUpdate),
+            .sequenceHandle = cpu_to_be32(seq_handle),
+            .sessionHdrSize = cpu_to_be32(sizeof(struct tpm2_session_header)),
+            .session.handle = cpu_to_be32(TPM_RS_PW),
+            .dataSize = cpu_to_be16(max_bytes),
+        };
+
+        memcpy(cmd_rsp.update_c.data, buf, max_bytes);
+
+        o_size = sizeof(cmd_rsp);
+        send_cmd(loc, cmd_rsp.b, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+
+        if ( o_size < sizeof(struct tpm_rsp_hdr) )
+        {
+            rc = TPM_INTERNAL_ERROR;
+            goto error;
+        }
+        rc = be32_to_cpu(cmd_rsp.r.returnCode);
+        if ( rc != 0 )
+            goto error;
+
+        size -= max_bytes;
+        buf += max_bytes;
+    }
+
+    cmd_rsp.finish_c = (struct tpm2_sequence_complete_cmd) {
+        .h.tag = cpu_to_be16(TPM_ST_SESSIONS),
+        .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.finish_c) + size),
+        .h.ordinal = cpu_to_be32(TPM2_PCR_EventSequenceComplete),
+        .pcrHandle = cpu_to_be32(HR_PCR + pcr),
+        .sequenceHandle = cpu_to_be32(seq_handle),
+        .sessionHdrSize = cpu_to_be32(sizeof(struct tpm2_session_header) * 2),
+        .pcrSession.handle = cpu_to_be32(TPM_RS_PW),
+        .sequenceSession.handle = cpu_to_be32(TPM_RS_PW),
+        .dataSize = cpu_to_be16(size),
+    };
+
+    memcpy(cmd_rsp.finish_c.data, buf, size);
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+
+    if ( o_size < sizeof(struct tpm_rsp_hdr) )
+    {
+        rc = TPM_INTERNAL_ERROR;
+        goto error;
+    }
+    rc = be32_to_cpu(cmd_rsp.r.returnCode);
+    if ( rc != 0 )
+        goto error;
+
+    if ( o_size < sizeof(cmd_rsp.finish_r) )
+    {
+        rc = TPM_INTERNAL_ERROR;
+        goto error;
+    }
+
+    p = cmd_rsp.finish_r.hashes;
+    for ( i = 0; i < be32_to_cpu(cmd_rsp.finish_r.hashCount); ++i )
+    {
+        unsigned int j;
+        uint16_t hash_type;
+
+        if ( p + sizeof(uint16_t) > cmd_rsp.b + o_size )
+        {
+            rc = TPM_INTERNAL_ERROR;
+            goto error;
+        }
+        hash_type = be16_to_cpu(*(uint16_t *)p);
+        p += sizeof(uint16_t);
+
+        for ( j = 0; j < log_hashes->count; ++j )
+        {
+            const struct tpm_log_hash *hash = &log_hashes->hashes[j];
+            if ( hash->alg == hash_type )
+            {
+                if ( p + hash->size > cmd_rsp.b + o_size )
+                {
+                    rc = TPM_INTERNAL_ERROR;
+                    goto error;
+                }
+                memcpy(hash->data, p, hash->size);
+                p += hash->size;
+                break;
+            }
+        }
+
+        if ( j == log_hashes->count )
+            /* Can't continue parsing without knowing hash size. */
+            break;
+    }
+
+    rc = 0;
+
+ error:
+    relinquish_locality(loc);
+    return rc;
+}
+
+#else
+
+union tpm2_cmd_rsp {
+    /* Enough space for multiple hashes. */
+    uint8_t b[sizeof(struct tpm2_extend_cmd) + 1024];
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct tpm2_extend_cmd extend_c;
+    struct tpm2_extend_rsp extend_r;
+};
+
+static uint32_t tpm20_pcr_extend(unsigned int loc, uint32_t pcr_handle,
+                                 const struct tpm_log_hashes *log_hashes)
+{
+    union tpm2_cmd_rsp cmd_rsp;
+    unsigned int o_size;
+    unsigned int i;
+    uint8_t *p;
+
+    cmd_rsp.extend_c = (struct tpm2_extend_cmd) {
+        .h.tag = cpu_to_be16(TPM_ST_SESSIONS),
+        .h.ordinal = cpu_to_be32(TPM2_PCR_Extend),
+        .pcrHandle = cpu_to_be32(pcr_handle),
+        .sessionHdrSize = cpu_to_be32(sizeof(struct tpm2_session_header)),
+        .pcrSession.handle = cpu_to_be32(TPM_RS_PW),
+        .hashCount = cpu_to_be32(log_hashes->count),
+    };
+
+    p = cmd_rsp.extend_c.hashes;
+    for ( i = 0; i < log_hashes->count; ++i )
+    {
+        const struct tpm_log_hash *hash = &log_hashes->hashes[i];
+
+        if ( p + sizeof(uint16_t) + hash->size > &cmd_rsp.b[sizeof(cmd_rsp)] )
+        {
+            printk(XENLOG_ERR "Hit TPM message size implementation limit: %ld\n",
+                   sizeof(cmd_rsp));
+            return TPM_INTERNAL_ERROR;
+        }
+
+        *(uint16_t *)p = cpu_to_be16(hash->alg);
+        p += sizeof(uint16_t);
+
+        memcpy(p, hash->data, hash->size);
+        p += hash->size;
+    }
+
+    /* Fill in command size (size of the whole buffer). */
+    cmd_rsp.c.paramSize = cpu_to_be32(sizeof(cmd_rsp.extend_c) +
+                                      (p - cmd_rsp.extend_c.hashes));
+
+    o_size = sizeof(cmd_rsp);
+    send_cmd(loc, cmd_rsp.b, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+
+    return be32_to_cpu(cmd_rsp.r.returnCode);
+}
+
+static bool tpm2_supports_hash(unsigned int loc,
+                               const struct tpm_log_hash *hash)
+{
+    uint32_t rc;
+    struct tpm_log_hashes hashes = {
+        .count = 1,
+        .hashes[0] = *hash,
+    };
+
+    /*
+     * This is a valid way of checking hash support, using it to not implement
+     * TPM2_GetCapability().
+     */
+    rc = tpm20_pcr_extend(loc, /*pcr_handle=*/TPM_RH_NULL, &hashes);
+
+    return rc == 0;
+}
+
+static uint32_t tpm2_hash_extend(unsigned int loc, const uint8_t *buf,
+                                 unsigned int size, unsigned int pcr,
+                                 const struct tpm_log_hashes *log_hashes)
+{
+    uint32_t rc;
+    unsigned int i;
+    struct tpm_log_hashes supported_hashes = {0};
+
+    request_locality(loc);
+
+    for ( i = 0; i < log_hashes->count; ++i )
+    {
+        const struct tpm_log_hash *hash = &log_hashes->hashes[i];
+        if ( !tpm2_supports_hash(loc, hash) )
+        {
+            printk(XENLOG_WARNING "Skipped hash unsupported by TPM: %d\n",
+                   hash->alg);
+            continue;
+        }
+
+        if ( hash->alg == TPM_ALG_SHA1 )
+        {
+            sha1(hash->data, buf, size);
+        }
+        else if ( hash->alg == TPM_ALG_SHA256 )
+        {
+            sha2_256(hash->data, buf, size);
+        }
+        else
+        {
+            /*
+             * Assuming the caller has initialized the digest with some
+             * pattern.
+             */
+        }
+
+        if ( supported_hashes.count == MAX_TPM_HASH_COUNT )
+        {
+            printk(XENLOG_ERR "Hit hash count implementation limit: %d\n",
+                   MAX_TPM_HASH_COUNT);
+            return TPM_INTERNAL_ERROR;
+        }
+
+        supported_hashes.hashes[supported_hashes.count] = *hash;
+        ++supported_hashes.count;
+    }
+
+    rc = tpm20_pcr_extend(loc, HR_PCR + pcr, &supported_hashes);
+    relinquish_locality(loc);
+
+    return rc;
+}
+
+#endif /* __EARLY_TPM__ */
+
+/************************** end of TPM2.0 specific ****************************/
+
 uint32_t tpm_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
                          unsigned int size,
                          const struct tpm_log_hashes *log_hashes)
@@ -402,5 +730,5 @@ uint32_t tpm_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
         return tpm12_hash_extend(loc, buf, size, pcr, log_hashes);
     }
 
-    return TPM_INTERNAL_ERROR;
+    return tpm2_hash_extend(loc, buf, size, pcr, log_hashes);
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380617.1624318 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVwu-0002bT-BN; Sun, 02 Aug 2026 13:09:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380617.1624318; Sun, 02 Aug 2026 13:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVwu-0002ah-7a; Sun, 02 Aug 2026 13:09:52 +0000
Received: by outflank-mailman (input) for mailman id 1380617;
 Sun, 02 Aug 2026 13:09:51 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVws-0002Lt-W5
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:09:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVws-001l71-1i
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:09:50 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4184-e002-0a2a0a5209dd-0a2a4509b098-12
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:49 +0200
Received: from [46.105.40.108] (helo=3.mo583.mail-out.ovh.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f419d-be1a-0a2a45090019-2e69286cbf7b-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:49 +0200
Received: from director11.ghost.mail-out.ovh.net (unknown [10.110.37.89])
 by mo583.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBj0K6Wz5yKg
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:09:48 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-94gmt (unknown [10.110.113.120])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5580EC28DA;
 Sun,  2 Aug 2026 13:09:48 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-7d8d68f679-94gmt with ESMTPSA
 id NPxXBZxBb2p7shoA8/69sg
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-101G004d28b9708-d722-46a0-b753-19657ed76a3a,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
Date: Sun,  2 Aug 2026 16:09:18 +0300
Message-ID: <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4727653710698587580
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEO37Lm1soAj3J6HJwxZueJ91jNrKiCMD9VOxO+7S6oZcwX5ZhHy/rf+u1q3gsSFBR0MQ0G/W66mTSt5xumJoxY/EyDpxdVBT5aAA1fHupbW88f/IumzeClwwf3PGe5NCfIC4rAkaw9D49zl0L3FOqYw1yebY9XQZPEoEgqOhxU7iAITzoi4rSZJugXTxFrfgz5z3QYtYzrLSr0w464iDE2Jv+mfsQyDLbPqlC9XEGpFu9KBxFx07+KPXWsR6kr02Tgk2fJ3ulvjdiKijPJd2EPMcqID96OcOqj/uCF/V+6MYDFkW6NlVR5eWMFf+caoPBoCiQxHguJ/BWn2Nt+/d7LNllcVQgdmgcry5NN7wS+7P244IVm1i3hxWTS0fY6l0mLmTrBdYMSj1l2MPXzfgrzKe+RwmeSG1PQWIXYbI81FBT96hhatZiup856cK5HOUf8jO43hH6Pam7Rb/cvxoRnQ189n0TR2SsNPS1cxZSJfG85p4aqQ61kgp59XqEL9nYtCPpVz0amvbk20nzSS6OIulbeXySnAFJAzehqeShpvFZ5FI2mFTvLc/rxG5Lgqfv02DJJ+HsLt4SETJwrMLt0L/KbPvgMIWS5lQQmVLxOofSfw0XSP0l/0tqgdtE0POhVRwEKgTJ54tR66Y6E2i0sC1FqUKF8QYD5nMk8jkj9JQ
DKIM-Signature: a=rsa-sha256; bh=guK4ex2HH/E4mH457QyNnqirM8tblzphlMNWG1MrUQs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676189; v=1;
 b=ad4fknva8ekoVibK/O1uF7vEnWMXYQS4A8+qPP4vzp/vKVYUudVIhuUQzYx1wxUsjQxy+vQg
 YbweWI0bsr05oWQ5Mfk8c03cDWsdhZmJapciYcaRneWnNcgESaKlreYlH/yS+vuWxwrTo8un1br
 +LXKI7Z0LaSJj49ZGr1ZhpezOPzRYZrzo3BdoIh93I3wGjlzRtZfTLEvQ1TifMy0RxI2XM+PTgV
 FZvdGLFSwnjGeO9+yOVffVjzCibhxeoDboO8n/jkrX/VsjqsM/4XRuL2cYJyQIXbbqgIT/rslYE
 4DKxlImaRh8A09Qn5wTAQuU+P8v05sEJEHuUtF9tAwghQ==
X-purgate-ID: tlsNG-bad1c0/1785676189-FC817034-625FF1C6/0/0
X-purgate-type: clean
X-purgate-size: 5038

From: Michał Żygowski <michal.zygowski@3mdeb.com>

Report TXT capabilities so that dom0 can query the Intel TXT or AMD
SKINIT support information using xl dmesg.

Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: fixed conditions for not reporting capabilities (match correct comments)
    v4: define GETSEC_* macros used only by xen/arch/x86/cpu/intel.c in the file itself (to not depend on Slaunch)
    v4: don't postpone restoring state of X86_CR4_SMXE, do it before printing test results

 xen/arch/x86/cpu/amd.c   | 16 +++++++++++++
 xen/arch/x86/cpu/cpu.h   |  1 +
 xen/arch/x86/cpu/hygon.c |  1 +
 xen/arch/x86/cpu/intel.c | 50 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 68 insertions(+)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 70783c9a0a..5ea16ad8a8 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -617,6 +617,21 @@ void amd_process_freq(const struct cpuinfo_x86 *c,
 		*low_mhz = amd_parse_freq(c->family, lo);
 }
 
+void amd_log_skinit(const struct cpuinfo_x86 *c)
+{
+    /*
+     * Run only on BSP and not during resume to report the capability only once.
+     */
+    if ( system_state == SYS_STATE_resume || smp_processor_id() )
+        return;
+
+    printk("CPU: SKINIT capability ");
+    if ( !test_bit(X86_FEATURE_SKINIT, &boot_cpu_data.x86_capability) )
+        printk("not supported\n");
+    else
+        printk("supported\n");
+}
+
 void cf_check early_init_amd(struct cpuinfo_x86 *c)
 {
 	if (c == &boot_cpu_data)
@@ -1325,6 +1340,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 		setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
 
 	amd_log_freq(c);
+	amd_log_skinit(c);
 }
 
 const struct cpu_dev __initconst_cf_clobber amd_cpu_dev = {
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index bbede57ab0..17935190b7 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -21,6 +21,7 @@ extern bool detect_extended_topology(struct cpuinfo_x86 *c);
 
 void cf_check early_init_amd(struct cpuinfo_x86 *c);
 void amd_log_freq(const struct cpuinfo_x86 *c);
+void amd_log_skinit(const struct cpuinfo_x86 *c);
 void amd_init_de_cfg(const struct cpuinfo_x86 *c);
 void amd_init_lfence_dispatch(void);
 void amd_init_ssbd(const struct cpuinfo_x86 *c);
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
index 7a9fc25d31..608a7c4319 100644
--- a/xen/arch/x86/cpu/hygon.c
+++ b/xen/arch/x86/cpu/hygon.c
@@ -90,6 +90,7 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c)
 	}
 
 	amd_log_freq(c);
+	amd_log_skinit(c);
 }
 
 const struct cpu_dev __initconst_cf_clobber hygon_cpu_dev = {
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 90c9d36186..ddb34c0c02 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -14,6 +14,11 @@
 
 #include "cpu.h"
 
+/* EAX value for GETSEC leaf functions. Intel SDM: GETSEC[CAPABILITIES] */
+#define GETSEC_CAPABILITIES             0
+/* Intel SDM: GETSEC Capability Result Encoding */
+#define GETSEC_CAP_TXT_CHIPSET          1
+
 /*
  * MSR_MCU_OPT_CTRL is a collection of unrelated functionality, with separate
  * enablement requirements, but which want to be consistent across the system.
@@ -620,6 +625,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
     }
 }
 
+/*
+ * Print out the SMX and TXT capabilties, so that dom0 can determine if the
+ * system is DRTM-capable.
+ */
+static void intel_log_smx_txt(void)
+{
+    unsigned long cr4_val, getsec_caps;
+
+    /*
+     * Run only on BSP and not during resume to report the capability only once.
+     */
+    if ( system_state == SYS_STATE_resume || smp_processor_id() )
+        return;
+
+    printk("CPU: SMX capability ");
+    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
+    {
+        printk("not supported\n");
+        return;
+    }
+    printk("supported\n");
+
+    /* Can't run GETSEC without VMX and SMX */
+    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
+        return;
+
+    cr4_val = read_cr4();
+    if ( !(cr4_val & X86_CR4_SMXE) )
+        write_cr4(cr4_val | X86_CR4_SMXE);
+
+    asm volatile ("getsec\n"
+        : "=a" (getsec_caps)
+        : "a" (GETSEC_CAPABILITIES), "b" (0) :);
+
+    if ( !(cr4_val & X86_CR4_SMXE) )
+        write_cr4(cr4_val & ~X86_CR4_SMXE);
+
+    if ( getsec_caps & GETSEC_CAP_TXT_CHIPSET )
+        printk("Chipset supports TXT\n");
+    else
+        printk("Chipset does not support TXT\n");
+}
+
 static void cf_check init_intel(struct cpuinfo_x86 *c)
 {
 	/* Detect the extended topology information if available */
@@ -634,6 +682,8 @@ static void cf_check init_intel(struct cpuinfo_x86 *c)
 		detect_ht(c);
 	}
 
+	intel_log_smx_txt();
+
 	/* Work around errata */
 	Intel_errata_workarounds(c);
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380620.1624349 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVx3-0003Ux-A0; Sun, 02 Aug 2026 13:10:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380620.1624349; Sun, 02 Aug 2026 13:10:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVx3-0003Un-5Q; Sun, 02 Aug 2026 13:10:01 +0000
Received: by outflank-mailman (input) for mailman id 1380620;
 Sun, 02 Aug 2026 13:09:59 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVx1-0003SZ-OU
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:09:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVx1-004d7k-5L
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:09:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4195-2eae-0a2a0a5409dd-0a2a4507dfe0-26
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:58 +0200
Received: from [188.165.39.161] (helo=15.mo582.mail-out.ovh.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41a6-b4ea-0a2a45070019-bca527a1b141-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:58 +0200
Received: from director5.ghost.mail-out.ovh.net (unknown [10.110.43.253])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBs6hNwz5xnH
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:09:57 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-z8rfb (unknown [10.110.178.126])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 115A5100161;
 Sun,  2 Aug 2026 13:09:57 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.95])
 by ghost-submission-7d8d68f679-z8rfb with ESMTPSA
 id 5ylFN6RBb2rsZRYAaLQSgA
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-95G0018acbab62-8b0a-4aab-827c-72b2fa275ecb,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 05/23] x86/tpm.c: add CRB interface support
Date: Sun,  2 Aug 2026 16:09:21 +0300
Message-ID: <5d71b306b8b6162cc434e8bfe16ed5dd1da068e8.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4730186985154487740
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEO37Lm1soAj3J6HJwxZueJ91jNrKiCMD9VOxO+7S6oZcwX5ZhHy/rf+u1q3gsSFBR0MQ0G/W66mTSt5xumJoxY/EyDpxdVBT5aAA1fHupbW88f/IumzeClwwf3PGe5NCfIC4rAkaw9D49zl0L3FOqYw1yebY9XQZPEoEgqOhxU7iAITzoi4rSZJugXTxFrfgz5z3QYtYzrLSr0w464iDE2Jv+mfsQyDLbPqlC9XEGpFu9KBxFx07+KPXWsR6kr02Tgk2fJ3ulvjdiKijPJd2EPMcqID96OcOqj/uCF/V+6MYDFkW6NlVR5eWMFf+caoPBoCiQxHguJ/BWn2Nt+/d7LIegd+W1HbJziGmUkNlCXhtzzh8HFSxQegASwemNchOJ3BdFA6NU/4EVQ6NTYL5e7Ey8YL1XyK6rItWnm1ifNg8olZjXM/sdiZFU7hWXSnAcleF0ugP7hWh9YMLoZKt3VU86pK5q81+ombrJ7OPetYH7fY+t3rbw/Jhf5Wv83Om4S1dmHgmtZqwbsUU0WOuoZka2cCqGYKQj95R7eLHEadAPWPErFtoSxe/DqQGlVxCkTNJxPW54bS6YywVOBrLhPp0WqOjYusmxpja7d2qS6Qz9xPDhxddyzZbWfAChxAYyfYUwcPOMXOM9M4msoqRwjdLhCFiFXeInLQDMwBhZoJg
DKIM-Signature: a=rsa-sha256; bh=BhGw1vM0t4hYsGT8oICAVoewzT6l4ZY+UO8jUoK1vZ0=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676198; v=1;
 b=Fj/EKOsqTK9/FmUtMRYQH++TVyOAB2/XJP5qoITerU7RU7h1mJBVrgjrmqJTyRdNFRw+fngG
 6JDaEBOnSjtG3GUiD4Pf/S6Ta5cLXgIvqeJk3hGVlEOfIR2hkU/jMli936A6KhN+JJ7lUmnIcJR
 r/HSlWEoyZLppwcLjzA0I4VF33zX8516OObJT6BRnPgeZWo9dsKOImSl/Q8d15R1/B3PGHrBTtQ
 Wh87/I2OQ/vgJuA1cbCVDOCMBHU3qAJokzQsPMlof8PT4e90s6iWTWVxldP6vTgoUNx2/NzAJJW
 29ilNPj2WE4ddpfYs6vsXdB3/scPaVhd+cqp86/yeSi/Q==
X-purgate-ID: tlsNG-ef75cf/1785676198-A72DCAE4-33145081/0/0
X-purgate-type: clean
X-purgate-size: 6771

From: Szymon Acedański <accek@mimuw.edu.pl>

TIS is an older and slower byte-oriented TPM interface that gets
replaced by CRB on modern systems.

Signed-off-by: Szymon Acedański <accek@invisiblethingslab.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: new commit to support CRB interface of TPM2.0

 xen/arch/x86/tpm.c | 134 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 131 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
index 59bb1ff2c4..a3d9a0d3e5 100644
--- a/xen/arch/x86/tpm.c
+++ b/xen/arch/x86/tpm.c
@@ -72,6 +72,11 @@ static uint8_t tpm_read8(unsigned int reg)
     return *(volatile uint8_t *)__va(TPM_MMIO_BASE + reg);
 }
 
+static void tpm_write32(unsigned int reg, uint32_t val)
+{
+    *(volatile uint32_t *)__va(TPM_MMIO_BASE + reg) = val;
+}
+
 static void tpm_write8(unsigned int reg, uint8_t val)
 {
     *(volatile uint8_t *)__va(TPM_MMIO_BASE + reg) = val;
@@ -110,6 +115,31 @@ static bool tpm_is_crb(void)
 #define TIS_BURST_COUNT_(x)     TPM_LOC_REG(x, 0x19)  /* the middle of STS */
 #define TIS_DATA_FIFO_(x)       TPM_LOC_REG(x, 0x24)
 
+/************************** CRB register definitions **************************/
+
+#define CRB_LOC_STATE_(x)       TPM_LOC_REG(x, 0x00)
+#define CRB_LOC_STATE_LOC_ASSIGNED   (1 << 1)
+#define CRB_LOC_STATE_REG_VALID_STS  (1 << 7)
+#define CRB_LOC_CTRL_(x)        TPM_LOC_REG(x, 0x08)
+#define CRB_LOC_CTRL_REQUEST_ACCESS  (1 << 0)
+#define CRB_LOC_CTRL_RELINQUISH      (1 << 1)
+#define CRB_CTRL_REQ_(x)        TPM_LOC_REG(x, 0x40)
+#define CRB_CTRL_REQ_CMD_READY       (1 << 0)
+#define CRB_CTRL_REQ_GO_IDLE         (1 << 1)
+#define CRB_CTRL_STS_(x)        TPM_LOC_REG(x, 0x44)
+#define CRB_CTRL_STS_ERROR           (1 << 0)
+#define CRB_CTRL_CANCEL_(x)     TPM_LOC_REG(x, 0x48)
+#define CRB_CTRL_CANCEL_INVOKE       (1 << 0)
+#define CRB_CTRL_START_(x)      TPM_LOC_REG(x, 0x4C)
+#define CRB_CTRL_START_INVOKE        (1 << 0)
+#define CRB_CTRL_CMD_SIZE_(x)   TPM_LOC_REG(x, 0x58)
+#define CRB_CTRL_CMD_LADDR_(x)  TPM_LOC_REG(x, 0x5C)
+#define CRB_CTRL_CMD_HADDR_(x)  TPM_LOC_REG(x, 0x60)
+#define CRB_CTRL_RSP_SIZE_(x)   TPM_LOC_REG(x, 0x64)
+#define CRB_CTRL_RSP_ADDR_(x)   TPM_LOC_REG(x, 0x68)
+#define CRB_DATA_BUFFER_(x)     TPM_LOC_REG(x, 0x80)
+#define CRB_DATA_BUFFER_SIZE    0x0F80
+
 /************************** TIS locality & command ****************************/
 
 static void tis_request_locality(unsigned int loc)
@@ -195,12 +225,110 @@ static void tis_send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
     tpm_write8(TIS_STS_(loc), STS_COMMAND_READY);
 }
 
+/************************** CRB locality & command ****************************/
+
+static void crb_request_locality(unsigned int loc)
+{
+    const uint32_t mask = CRB_LOC_STATE_LOC_ASSIGNED |
+                          CRB_LOC_STATE_REG_VALID_STS;
+
+    tpm_write32(CRB_LOC_CTRL_(loc), CRB_LOC_CTRL_REQUEST_ACCESS);
+    while ( (tpm_read32(CRB_LOC_STATE_(loc)) & mask) != mask )
+        ;
+}
+
+static void crb_relinquish_locality(unsigned int loc)
+{
+    tpm_write32(CRB_LOC_CTRL_(loc), CRB_LOC_CTRL_RELINQUISH);
+    while ( tpm_read32(CRB_LOC_STATE_(loc)) & CRB_LOC_STATE_LOC_ASSIGNED )
+        ;
+}
+
+static void crb_cmd_ready(unsigned int loc)
+{
+    tpm_write32(CRB_CTRL_REQ_(loc), CRB_CTRL_REQ_CMD_READY);
+    while ( tpm_read32(CRB_CTRL_REQ_(loc)) & CRB_CTRL_REQ_CMD_READY )
+        ;
+}
+
+static void crb_go_idle(unsigned int loc)
+{
+    tpm_write32(CRB_CTRL_REQ_(loc), CRB_CTRL_REQ_GO_IDLE);
+    while ( tpm_read32(CRB_CTRL_REQ_(loc)) & CRB_CTRL_REQ_GO_IDLE )
+        ;
+}
+
+static void crb_send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
+                         unsigned int *o_size)
+{
+    paddr_t data_buf_pa = TPM_MMIO_BASE + CRB_DATA_BUFFER_(loc);
+    unsigned int expected;
+
+    if ( i_size > CRB_DATA_BUFFER_SIZE || *o_size < sizeof(struct tpm_rsp_hdr) )
+    {
+        *o_size = 0;
+        return;
+    }
+
+    /* Out of caution, make sure no previous command is still executing. */
+    while ( tpm_read32(CRB_CTRL_START_(loc)) & CRB_CTRL_START_INVOKE )
+        ;
+
+    crb_cmd_ready(loc);
+
+    /* In an unlikely event that TPM signals irrecoverable error here,
+     * better bail out than hang in infinite loop waiting for the
+     * start condition later. */
+    if ( tpm_read32(CRB_CTRL_STS_(loc)) & CRB_CTRL_STS_ERROR )
+    {
+        *o_size = 0;
+        crb_go_idle(loc);
+        return;
+    }
+
+    tpm_write32(CRB_CTRL_CANCEL_(loc), 0);
+
+    tpm_write32(CRB_CTRL_CMD_LADDR_(loc), data_buf_pa);
+    tpm_write32(CRB_CTRL_CMD_HADDR_(loc), 0);
+    tpm_write32(CRB_CTRL_CMD_SIZE_(loc), CRB_DATA_BUFFER_SIZE);
+    tpm_write32(CRB_CTRL_RSP_SIZE_(loc), CRB_DATA_BUFFER_SIZE);
+    /* RSP_ADDR is 64-bit. */
+    tpm_write32(CRB_CTRL_RSP_ADDR_(loc), data_buf_pa);
+    tpm_write32(CRB_CTRL_RSP_ADDR_(loc) + 4, 0);
+
+    memcpy(__va(data_buf_pa), buf, i_size);
+
+    tpm_write32(CRB_CTRL_START_(loc), CRB_CTRL_START_INVOKE);
+    while ( tpm_read32(CRB_CTRL_START_(loc)) & CRB_CTRL_START_INVOKE )
+        ;
+
+    if ( tpm_read32(CRB_CTRL_STS_(loc)) & CRB_CTRL_STS_ERROR )
+    {
+        *o_size = 0;
+        crb_go_idle(loc);
+        return;
+    }
+
+    /* Read header to learn the response length. */
+    memcpy(buf, __va(data_buf_pa), sizeof(struct tpm_rsp_hdr));
+    expected = be32_to_cpu(((struct tpm_rsp_hdr *)buf)->paramSize);
+    if ( expected > *o_size )
+        expected = *o_size;
+    if ( expected > CRB_DATA_BUFFER_SIZE )
+        expected = CRB_DATA_BUFFER_SIZE;
+
+    memcpy(buf, __va(data_buf_pa), expected);
+
+    *o_size = expected;
+    crb_go_idle(loc);
+}
+
 /************************** Interface dispatch ********************************/
 
 static void request_locality(unsigned int loc)
 {
     if ( tpm_is_crb() )
-        return;
+        crb_request_locality(loc);
     else
         tis_request_locality(loc);
 }
@@ -208,7 +336,7 @@ static void request_locality(unsigned int loc)
 static void relinquish_locality(unsigned int loc)
 {
     if ( tpm_is_crb() )
-        return;
+        crb_relinquish_locality(loc);
     else
         tis_relinquish_locality(loc);
 }
@@ -217,7 +345,7 @@ static void send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
                      unsigned int *o_size)
 {
     if ( tpm_is_crb() )
-        *o_size = 0;
+        crb_send_cmd(loc, buf, i_size, o_size);
     else
         tis_send_cmd(loc, buf, i_size, o_size);
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380616.1624312 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVwu-0002XC-3R; Sun, 02 Aug 2026 13:09:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380616.1624312; Sun, 02 Aug 2026 13:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVwt-0002Ww-VX; Sun, 02 Aug 2026 13:09:51 +0000
Received: by outflank-mailman (input) for mailman id 1380616;
 Sun, 02 Aug 2026 13:09:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVws-0002Ls-Rc
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:09:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVwr-004d0q-Mc
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:09:49 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f417e-2eae-0a2a0a5409dd-0a2a4502c3a4-18
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:49 +0200
Received: from [87.98.181.248] (helo=5.mo560.mail-out.ovh.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4197-6ca4-0a2a45020019-5762b5f89245-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:44 +0200
Received: from director10.ghost.mail-out.ovh.net (unknown [10.110.37.197])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBb5RkDzB5lq
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:09:43 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-xdn7l (unknown [10.110.96.89])
 by director10.ghost.mail-out.ovh.net (Postfix) with ESMTPS id AA4E2C0F4F;
 Sun,  2 Aug 2026 13:09:41 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.96])
 by ghost-submission-7d8d68f679-xdn7l with ESMTPSA
 id 2ctPGpVBb2ofBBsATjhwOw
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-96R0016b89e747-1785-4152-95ae-486e00688f50,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Lukasz Hawrylko <lukasz@hawrylko.pl>,
	=?UTF-8?q?Mateusz=20M=C3=B3wka?= <mateusz.mowka@intel.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 00/23] x86: Trenchboot Secure Launch DRTM (Xen)
Date: Sun,  2 Aug 2026 16:09:16 +0300
Message-ID: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4726246333962331580
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -51
X-VR-SPAMCAUSE: dmFkZTFdXTrARFACQ6m9P7gTxX0PekKK8WeIVA15uE+Q8jnwA9gEyJa7xjXxo5vANI53/0+D44IJm6ZWpxAtd4w3ij7mPxMHSgilLVIAbFfDh74rWf79n1eaYlmPcZv5e6jI+mYGSty3r03VTenwEhPzEEAFz6EhCwT2dGzWQhDVwl7Wvgr5EyDql+zuQNMTRf0D8nzyFZGp15N6IkYLAr7uLr2cUucu71/cfXLIz/4eakvJn7uag/1v5Pka9Gi+tIHo0NtqsYPZIVphzck04C9GB6uAf2dfA8R8ZCdxSLdLJLip4cwRyE5bwLdAwax0O1xBzxePGB2TbRYRKAiiU/R9VFwcmJFnFqemLxjevb6bqC3OcwQg3SqHW2QNlhG0XgELBicbjxtMdkPA7T9MMgGaOmTZi+54x63HT3yvj+kLO6jmxmQxgDq5vJHm4U6fnVEf4hupdi4mg6ImUsJAb/16BOkq/SmCA6zb98joQZtJpiqYtz1ZOry7gpZSC8ZlfdpAAejx5FqdltDSrGM1e3LRoSxFCJziHrcGuKTiSGapnoCOLPVbkXMcx4RVTTvyv+LavBs8GkpYomQHQjrKYm2H3jDDZNRHCPloGrHv9Ndvv7kohZbstOpKU6A2nHx25hBWQdmBv5aC2gyCA4qJ6fJc3/ZzxP8sUaCsCzWkpNK6rBJDNg
DKIM-Signature: a=rsa-sha256; bh=qHXC8mHNWg/aZvJUsYG80TVBq7kbjbeH1mde4zTkom8=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676183; v=1;
 b=TRXyQY/eSHLhVvcblvdDseI8wit6I9NXOVUiHWc9PbvJDgJ5L3XPgXviZ4mQcCzoDvOKmvww
 JX3w35rxT4hSszEayPR1PoruXap/gmtTGFeJZqaQrWS1nBdOo/OGcROqjFLuuW4ZwrfcNMi8uS1
 Mktf0Bm6FqEe7UZfuO9OBjx9hg767448xVz9fhAiBkErQ1VeSqq5Md4Ln1MAHNduTjdJAIokOTg
 w850fbkIqb0zauwsJegtUXYtXQZvno6t9P3HaKKhwNRwgFgqKEVyjNTuvil3RwvpVKag6TP6a/F
 XubtPBpo+3dj78TZ4rC3rmu338U7cNkCSIzZm3hu4ddxA==
X-purgate-ID: tlsNG-720697/1785676189-66EB32AC-0E948AD1/0/0
X-purgate-type: clean
X-purgate-size: 10266

The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
 - Intel TXT and AMD SKINIT on x86 CPUs
 - legacy and UEFI boot
 - TPM1.2 and TPM2.0 (TIS and CRB)
 - (in the future) DRTM on Arm CPUs

DRTM is a version of a measured launch that starts on request rather
than at the start of a boot cycle.  One of its advantages is in not
including the firmware in the chain of trust.

Xen already supports DRTM via [tboot] which targets Intel TXT only.
tboot encapsulates some of the DRTM details within itself while with
TrenchBoot Xen (or Linux) is meant to be a self-contained payload for a
TrenchBoot-enabled bootloader (think GRUB).  The one exception is that
UEFI case requires calling back into bootloader to initiate DRTM, which
is necessary to give Xen a chance of querying all the information it
needs from the firmware before performing DRTM start.

>From reading the above tboot might seem like a more abstracted, but the
reality is that the payload needs to have DRTM-specific knowledge
either way.  In principle, TrenchBoot, allows coming up with
independent implementations of bootloaders and payloads that are
compatible with each other.

The "x86/boot: choose AP stack based on APIC ID" patch is shared with
[Parallelize AP bring-up] series and is required here because Intel TXT
always releases all APs simultaneously.  The rest of the patches are
unique.

This version of the patches corresponds to this branch:
  https://github.com/TrenchBoot/xen/compare/7c77acd452fb...tb-staging-2026-07-31-v4

-----

[TrenchBoot]: https://trenchboot.org/
[tboot]: https://sourceforge.net/p/tboot/wiki/Home/
[Parallelize AP bring-up]: https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/
[v1]: https://lore.kernel.org/xen-devel/cover.1745172094.git.sergii.dmytruk@3mdeb.com/
[v2]: https://lore.kernel.org/xen-devel/cover.1747155790.git.sergii.dmytruk@3mdeb.com/
[v3]: https://lore.kernel.org/xen-devel/cover.1748611041.git.sergii.dmytruk@3mdeb.com/

-----

Changes in v4:
 - added notes to individial commits, the notes below cover some of
   more generic changes or those spanning multiple commits
 - dropped SHA-1 changes (was committed independently of this patchset)
 - added CONFIG_SLAUNCH Kconfig option
 - TPM driver changes have been moved to the front and are now
   independent from TPM event log and the rest of this patchset in
   general
 - a few commits were split, joined and/or renamed to make changes more
   independent, see notes in individual patches
 - added support for communicating with TPM2.0 via CRB and memory
   protection using TPR to support newer handware
 - moved UEFI_SLR_TABLE_GUID from xen/include/xen/slr-table.h to
   xen/common/efi/boot.c
 - changed the code for dealing with tables in TXT heap to be iterative
 - added more implementation-specific error codes and removed unused
   ones
 - extracted declarations from tpm.c into headers for TPM1.2 and TPM2.0
 - return EACCES instead of EPERM when refusing to go into S3 state
 - moved SLAUNCH_BOOTLOADER_MAGIC from x86/asm/intel-txt.h to
   x86/boot/head.S
 - moved making MTRR-related functions public to commit which uses them
 - use container_of() after slr_next_entry_by_tag() instead of a cast
 - made more code that deals with SLRT const-correct (including adding
   const to the parameter of dl_handler_func)
 - absent TPM event log is now consistently allowed by both TPM1.2 and
   TPM2.0 implementations

Changes in [v3]:
 - sorted `F:` entries in MAINTAINERS file
 - made sha1 implementation more similar to sha256
 - dropped unused parameter from
   xen/arch/x86/cpu/intel.c:intel_log_smx_txt()
 - updated header guards according to new style
 - xen/arch/x86/include/asm/intel-txt.h:
   + briefly explained what TXT is
   + renamed: NR_TXT_CONFIG_SIZE -> TXT_CONFIG_SPACE_SIZE
   + renamed: read_txt_reg() -> txt_read()
   + renamed: write_txt_reg() -> txt_write()
   + marked txt_reset() as noreturn and used unreacheable() instead of
     while(1)
   + explained a bit more about TXT Heap
 - xen/include/xen/slr-table.h:
   + briefly explained what SLRT is
   + fixed checks in slr_next_entry()
 - SPDX-License-Identifier: GPL-2.0 -> GPL-2.0-only
 - made more code const-correct
 - use arithmetic on pointers to `void` instead of pointers to
   `uint8_t`

Changes in [v2]:
 - using dashes instead of underscores in the names of new files
 - dropping of an extra sha256 implementation
 - rewriting sha1 implementation to be in line with already present
   sha256 implementation (simplifying it and getting rid of macros)
 - correct placement of new lines in Makefile
 - add header guards to all new files
 - use correct names for header guards in new files
 - update license of xen/include/xen/slr-table.h
 - changed fixmlehdr to search for header within 8 instead of 4 KiB
   file prefix
 - don't print DRTM-related capabilities when resuming from S3
 - forbade S3 in case of Secure Launch
 - fixed an issue with resuming from S3 caused by inappropriate use of
   __initdata
 - added a new section to MAINTAINERS
 - improved commit messages
 - fixed MISRA C violations:
   + shadowing of e820 global
   + missing U literal suffixes
   + use of ull literal suffix
   + excluded fixmlehdr from analysis (similar to other build tools)
   + use of 0 instead of NULL in one place
   + provided declarations for some definitions
   + marked asm-invoked functions with `asmlinkage`

-----

Kacper Stojek (2):
  x86/boot: add CONFIG_SLAUNCH, MLE header and Secure Launch entry point
  xen/arch/x86: reserve TXT memory during Slaunch

Krystian Hebel (7):
  x86/tpm.c: hashing and extending PCRs for TPM1.2
  x86/include/asm/intel-txt.h: constants and accessors for TXT registers
    and heap
  x86/boot/slaunch-early: early Intel TXT sanity checks
  x86/slaunch: restore boot MTRRs after Intel TXT DRTM
  x86/slaunch: measure MBI into TPM
  x86/boot: choose AP stack based on APIC ID
  x86/smpboot.c: TXT AP bringup

Michał Żygowski (2):
  x86/cpu: report SMX, TXT and SKINIT capabilities
  x86/hvm: check for VMX in SMX if Slaunch is active

Sergii Dmytruk (10):
  x86/mtrr: get rid of a static variable on pause/restore
  x86/tpm.c: support extending PCRs of TPM2.0 via TIS
  include/xen/slr-table.h: Secure Launch Resource Table definitions
  x86/boot/slaunch-early: implement early initialization
  x86/slaunch: update TPM event log (TPM1.2 or TPM2.0)
  x86/slaunch: process DRTM policy
  x86/acpi: disallow S3 on Secure Launch boot
  x86/slaunch: support AMD CPUs
  x86/slaunch: support EFI boot
  MAINTAINERS: add a section for TrenchBoot Slaunch

Szymon Acedański (2):
  x86/tpm.c: add CRB interface support
  xen/arch/x86: add TPR (TXT Protected Range) DMA protection support

 .gitignore                                    |   1 +
 MAINTAINERS                                   |  19 +
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   |   1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst   |  12 +
 xen/arch/x86/Kconfig                          |   8 +
 xen/arch/x86/Makefile                         |  16 +-
 xen/arch/x86/acpi/power.c                     |   8 +
 xen/arch/x86/boot/Makefile                    |  22 +-
 xen/arch/x86/boot/head.S                      | 267 ++++++
 xen/arch/x86/boot/slaunch-early.c             | 104 +++
 xen/arch/x86/boot/trampoline.S                |  42 +-
 xen/arch/x86/boot/x86_64.S                    |  67 +-
 xen/arch/x86/cpu/amd.c                        |  16 +
 xen/arch/x86/cpu/cpu.h                        |   1 +
 xen/arch/x86/cpu/hygon.c                      |   1 +
 xen/arch/x86/cpu/intel.c                      |  50 +
 xen/arch/x86/cpu/mtrr/generic.c               |  50 +-
 xen/arch/x86/e820.c                           |   5 +
 xen/arch/x86/efi/efi-boot.h                   |  95 +-
 xen/arch/x86/efi/fixmlehdr.c                  | 127 +++
 xen/arch/x86/hvm/vmx/vmcs.c                   |   3 +-
 xen/arch/x86/include/asm/apicdef.h            |   4 +
 xen/arch/x86/include/asm/intel-txt.h          | 573 ++++++++++++
 xen/arch/x86/include/asm/msr-index.h          |   3 +
 xen/arch/x86/include/asm/mtrr.h               |   8 +
 xen/arch/x86/include/asm/processor.h          |   1 +
 xen/arch/x86/include/asm/setup.h              |   3 +
 xen/arch/x86/include/asm/slaunch-tpm.h        |  26 +
 xen/arch/x86/include/asm/slaunch.h            | 128 +++
 xen/arch/x86/include/asm/tpm.h                |  74 ++
 xen/arch/x86/include/asm/tpm1.h               |  94 ++
 xen/arch/x86/include/asm/tpm2.h               | 150 +++
 xen/arch/x86/intel-txt.c                      | 197 ++++
 xen/arch/x86/setup.c                          |  32 +-
 xen/arch/x86/slaunch-tpm.c                    | 312 +++++++
 xen/arch/x86/slaunch.c                        | 478 ++++++++++
 xen/arch/x86/smpboot.c                        |  75 ++
 xen/arch/x86/tboot.c                          |  20 +-
 xen/arch/x86/tpm.c                            | 862 ++++++++++++++++++
 xen/arch/x86/x86_64/asm-offsets.c             |  13 +
 xen/common/efi/boot.c                         |   6 +
 xen/common/efi/runtime.c                      |   1 +
 xen/include/xen/efi.h                         |   1 +
 xen/include/xen/slr-table.h                   | 272 ++++++
 44 files changed, 4191 insertions(+), 57 deletions(-)
 create mode 100644 xen/arch/x86/boot/slaunch-early.c
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c
 create mode 100644 xen/arch/x86/include/asm/intel-txt.h
 create mode 100644 xen/arch/x86/include/asm/slaunch-tpm.h
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/include/asm/tpm1.h
 create mode 100644 xen/arch/x86/include/asm/tpm2.h
 create mode 100644 xen/arch/x86/intel-txt.c
 create mode 100644 xen/arch/x86/slaunch-tpm.c
 create mode 100644 xen/arch/x86/slaunch.c
 create mode 100644 xen/arch/x86/tpm.c
 create mode 100644 xen/include/xen/slr-table.h


base-commit: 7c77acd452fb6a3079661e75ebb5cf23ed985cc7
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380618.1624331 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVww-0002yk-Lw; Sun, 02 Aug 2026 13:09:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380618.1624331; Sun, 02 Aug 2026 13:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVww-0002yd-Iv; Sun, 02 Aug 2026 13:09:54 +0000
Received: by outflank-mailman (input) for mailman id 1380618;
 Sun, 02 Aug 2026 13:09:54 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVwv-0002y1-Ud
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:09:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVwv-00Beoh-Bb
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:09:53 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4173-bab6-0a2a0a5309dd-0a2a450c9222-34
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:53 +0200
Received: from [46.105.63.230] (helo=7.mo575.mail-out.ovh.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41a0-f479-0a2a450c0019-2e693fe6ac23-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:52 +0200
Received: from director1.ghost.mail-out.ovh.net (unknown [10.110.58.50])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBm1jnpz5xm0
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:09:51 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-57pcc (unknown [10.110.164.236])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 21241C0F98;
 Sun,  2 Aug 2026 13:09:50 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-7d8d68f679-57pcc with ESMTPSA
 id VxU1NJ5Bb2oLoxsA/StGhg
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-101G004acb215d6-7df5-4471-9e04-20cb55976478,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 03/23] x86/tpm.c: hashing and extending PCRs for TPM1.2
Date: Sun,  2 Aug 2026 16:09:19 +0300
Message-ID: <d073552c7ae0ac84bbd178237421d5d497d19f77.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4728498136041268668
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEtK5p0SNYtBef44Zaajhk33i63wmjVwNNhJ4YROChk7mhZcpyT3bd5ACP3F2TkAykP416Z/qj7tU2KxG1rTRS8MypF1KRhaA/AvmFdmp6hM2n75hgvTPUkRMkZtHtCy5BQJTDAa5dye2uRhTva5lFRUMRQoQfXqDmPkoEsCcMiOXhj8LDb8bxT7fPbPw+L6oM3Ib4+Crk5z3znR8b12WvIauAwvZwi4TwyXrVt8t5cjjf6p6tk/jAP3JPPWAt8lJLbOqKqZPj2dLVv8AcggN/kQjhcbgaHkG9r5s4innAGR9o3gaGzW+PeUVjPnviytxFmoTk+gQnhQiwpJq7s595nro3dDeuJs3r7PQx7V1K5fDPxkXiSwZe2lpVbkaWyv2p59iz/SIXjpugOQqVbJPoyrz7LbnDBWXKS66PYZWt87iuau+QRV23XF3bPbO94TTOakCioNXrOvJoPu9PMtSMMbW3YdbI5o5UqzbO8YWccAbk8u+SYUA/6uc3oa/lV0FtXaaJ5xC/ERvxf3WNKd69NprOiXi6+whRVw4SZxeQvgnTLw0OsL65npUEtg8SMe3ZurJxyTwkqdtRFyNkYKaQbCsZQqwxivk0/snc2zf0vOS5BEafSj0PpsmTzt2HJ44FVbdFCYICCD6GbBvPFX/y6i2sn8twpHhGY/qQuos83Tg
DKIM-Signature: a=rsa-sha256; bh=6hGSZXXcE+GcwWq+O2X1Dm5dHBDi/Fx386sIY1IuUps=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676192; v=1;
 b=I3zkZcWyzoVDVVQltodqnln/Uu0EsD3B6Wrjf4RDsJo5q1sTiAtbx/TrkxdIZ+8pAiMS5Ckm
 crNZo/3wIfpYqfwNm6s/pFKkQeLRZnXLxngR/jPg4rYV+FBxMt8zYFquw1FecesQHmOx0cRrkOK
 wtUD9SKCbn1jTtaOL371f/ivcx7fnKb1tERIZC0KuJ1L4VS4NM8wsetRhcSgp5vAi4PtHDjGlbB
 nqRV3TiHRThvtwov0Dp6lXf1xP+JZE/zMas3oM6YNT3AYObc+Hg+rEbzRJMRymkyNRmjorGK/Ln
 w6hTkj8Id5yz5OMtLkZEpRltCUHirQtMQ+APDjUHQWQiQ==
X-purgate-ID: tlsNG-d25034/1785676192-52530A5B-7756090D/0/0
X-purgate-type: clean
X-purgate-size: 20343

From: Krystian Hebel <krystian.hebel@3mdeb.com>

This file is built twice: for early 32b mode without paging and for 64b
code.  The expectation is that the data that's measured early is small
and thus sending it to TPM to do the hashing is viable.  Version with
paging computes digests and only sends their values to TPM, thus
permitting hashing of large chunks of data like dom0's kernel and
initrd (sending them to TPM would take multiple minutes).

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: renamed from "x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)"
    v4: no longer depends on Slaunch
    v4: __EARLY_SLAUNCH__ got replaced with __EARLY_TPM__
    v4: fixed SPDX license comments
    v4: added short description at the top
    v4: TPM_TIS_* => TPM_MMIO_*
    v4: tpm_hash_extend() now returns an error code
    v4: tpm_hash_extend() now accepts list of hashes like TPM2 but expects at most SHA1
    v4: turned is_tpm12() into public tpm_is_tpm1() function (to be used for event log)
    v4: added xen/arch/x86/include/asm/tpm1.h with TPM1.2 TCG declarations
    v4: removed swap16() and swap32() macros to use macros from <xen/byteorder.h>
    v4: no more `static inline` in tpm.c, it's pointless there
    v4: style fixes for empty loops, operator placement on wrapped lines, checking for unset bits
    v4: take TPM burst count into account
    v4: fixed incorrect check for `data_avail` when communicating with TPM
    v4: internal functions return TPM error code instead of `bool`
    v4: added command and response fields to `union cmd_rsp` to make using it easier
    v4: `unsigned` => `unsigned int`
    v4: not opencoding ROUNDDOWN() macro
    v4: digest storage became optional
    v4: returns TPM_INTERNAL_ERROR if not dealing with TPM1.2 or on communication error
    v4: the code is written for TIS, but has room for other TPM interfaces

 xen/arch/x86/Makefile           |   1 +
 xen/arch/x86/boot/Makefile      |   5 +
 xen/arch/x86/include/asm/tpm.h  |  69 ++++++
 xen/arch/x86/include/asm/tpm1.h |  79 +++++++
 xen/arch/x86/tpm.c              | 406 ++++++++++++++++++++++++++++++++
 5 files changed, 560 insertions(+)
 create mode 100644 xen/arch/x86/include/asm/tpm.h
 create mode 100644 xen/arch/x86/include/asm/tpm1.h
 create mode 100644 xen/arch/x86/tpm.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b14eca98bf..293f3bee35 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -68,6 +68,7 @@ obj-y += string.o
 obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += time.o
+obj-y += tpm.o
 obj-y += traps-setup.o
 obj-y += traps.o
 obj-$(CONFIG_INTEL) += tsx.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index ff0d61d7ac..feae17c14a 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -5,6 +5,7 @@ obj-bin-y += $(obj64)
 obj32 := cmdline.32.o
 obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
+obj32 += tpm-early.32.o
 
 obj64 := reloc-trampoline.o
 
@@ -28,6 +29,10 @@ $(obj32): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
 $(obj)/%.32.o: $(src)/%.c FORCE
 	$(call if_changed_rule,cc_o_c)
 
+$(obj)/tpm-early.32.o: XEN_CFLAGS += -D__EARLY_TPM__
+$(obj)/tpm-early.32.o: $(src)/../tpm.c FORCE
+	$(call if_changed_rule,cc_o_c)
+
 orphan-handling-$(call ld-option,--orphan-handling=error) := --orphan-handling=error
 LDFLAGS_DIRECT-$(call ld-option,--warn-rwx-segments) := --no-warn-rwx-segments
 LDFLAGS_DIRECT += $(LDFLAGS_DIRECT-y)
diff --git a/xen/arch/x86/include/asm/tpm.h b/xen/arch/x86/include/asm/tpm.h
new file mode 100644
index 0000000000..06b54fb786
--- /dev/null
+++ b/xen/arch/x86/include/asm/tpm.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * A TPM driver for both normal and early boot environments.
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#ifndef X86_TPM_H
+#define X86_TPM_H
+
+#include <xen/types.h>
+
+#define TPM_INTERNAL_ERROR  0xffffffffU
+
+#define TPM_MMIO_BASE  0xfed40000U
+#define TPM_MMIO_SIZE  0x00010000U
+
+/* These are defined for TPM2, but they are used by generic API. */
+#define TPM_ALG_SHA1    0x0004
+#define TPM_ALG_SHA256  0x000b
+#define TPM_ALG_NULL    0x0010
+
+/*
+ * These two structures are for convenience, they don't correspond to anything
+ * in any specification.
+ */
+struct tpm_log_hash {
+    uint16_t alg;  /* TPM_ALG_* */
+    uint16_t size;
+    uint8_t *data; /* Non-owning reference to a buffer inside log entry. */
+};
+/* Should be more than enough for now and awhile in the future. */
+#define MAX_TPM_HASH_COUNT 8
+struct tpm_log_hashes {
+    uint32_t count;
+    struct tpm_log_hash hashes[MAX_TPM_HASH_COUNT];
+};
+
+/* All fields of the following structs are big endian. */
+
+struct tpm_cmd_hdr {
+    uint16_t tag;
+    uint32_t paramSize;
+    uint32_t ordinal;
+} __packed;
+
+struct tpm_rsp_hdr {
+    uint16_t tag;
+    uint32_t paramSize;
+    uint32_t returnCode;
+} __packed;
+
+/* Checks whether TPM belongs to TPM 1 family, the only alternative is TPM 2. */
+bool tpm_is_tpm1(void);
+
+/*
+ * The list of hashes must either be empty or contain nothing but SHA1 hash when
+ * tpm_is_tpm1() returns true.
+ *
+ * Returns:
+ *  - TPM error code when < 4096 (0 means success)
+ *  - TPM_INTERNAL_ERROR on invalid invocation or a failure to communicate with
+ *    a TPM device
+ */
+uint32_t tpm_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
+                         unsigned int size,
+                         const struct tpm_log_hashes *log_hashes);
+
+#endif /* X86_TPM_H */
diff --git a/xen/arch/x86/include/asm/tpm1.h b/xen/arch/x86/include/asm/tpm1.h
new file mode 100644
index 0000000000..d1cb2cc041
--- /dev/null
+++ b/xen/arch/x86/include/asm/tpm1.h
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * TPM1.2-related declarations defined by Trusted Computing Group (TCG).
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#ifndef X86_TPM1_H
+#define X86_TPM1_H
+
+#include <xen/inttypes.h>
+#include <xen/sha1.h>
+
+#include <asm/tpm.h>
+
+#define TPM_ORD_Extend              0x00000014
+#define TPM_ORD_SHA1Start           0x000000A0
+#define TPM_ORD_SHA1Update          0x000000A1
+#define TPM_ORD_SHA1CompleteExtend  0x000000A3
+
+#define TPM_TAG_RQU_COMMAND         0x00C1
+#define TPM_TAG_RSP_COMMAND         0x00C4
+
+/* All fields of the following structs are big endian. */
+
+struct extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrNum;
+    uint8_t inDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct extend_rsp {
+    struct tpm_rsp_hdr h;
+    uint8_t outDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+struct sha1_start_cmd {
+    struct tpm_cmd_hdr h;
+} __packed;
+
+struct sha1_start_rsp {
+    struct tpm_rsp_hdr h;
+    uint32_t maxNumBytes;
+} __packed;
+
+struct sha1_update_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t numBytes;          /* Must be a multiple of 64 */
+    uint8_t hashData[];
+} __packed;
+
+struct sha1_update_rsp {
+    struct tpm_rsp_hdr h;
+} __packed;
+
+struct sha1_complete_extend_cmd {
+    struct tpm_cmd_hdr h;
+    uint32_t pcrNum;
+    uint32_t hashDataSize;      /* 0-64, inclusive */
+    uint8_t hashData[];
+} __packed;
+
+struct sha1_complete_extend_rsp {
+    struct tpm_rsp_hdr h;
+    uint8_t hashValue[SHA1_DIGEST_SIZE];
+    uint8_t outDigest[SHA1_DIGEST_SIZE];
+} __packed;
+
+/* The structures below are for TPM event log and these are in little-endian. */
+
+struct TPM12_PCREvent {
+    uint32_t PCRIndex;
+    uint32_t Type;
+    uint8_t Digest[SHA1_DIGEST_SIZE];
+    uint32_t Size;
+    uint8_t Data[];
+};
+
+#endif /* X86_TPM1_H */
diff --git a/xen/arch/x86/tpm.c b/xen/arch/x86/tpm.c
new file mode 100644
index 0000000000..9efaf75440
--- /dev/null
+++ b/xen/arch/x86/tpm.c
@@ -0,0 +1,406 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * TPM driver for extending PCRs.
+ *
+ * This file is built twice:
+ *  1. For early 32b mode without paging the code sends data to be hashed to
+ *     TPM.
+ *  2. For 64b code which computes hashes and only extends them into PCRs.
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#include <xen/byteorder.h>
+#include <xen/sha1.h>
+#include <xen/string.h>
+#include <xen/types.h>
+
+#include <asm/tpm.h>
+#include <asm/tpm1.h>
+
+#ifdef __EARLY_TPM__
+
+#include <xen/macros.h>
+
+#ifdef __va
+#error "__va defined in non-paged mode!"
+#endif
+
+#define __va(x)     _p(x)
+
+/*
+ * The code is being compiled as a standalone binary without linking to any
+ * other part of Xen.  Providing implementation of builtin functions in this
+ * case is necessary if compiler chooses to not use an inline builtin.
+ */
+void *(memcpy)(void *dest, const void *src, size_t n)
+{
+    const uint8_t *s = src;
+    uint8_t *d = dest;
+
+    while ( n-- )
+        *d++ = *s++;
+
+    return dest;
+}
+
+#else   /* __EARLY_TPM__ */
+
+#include <xen/mm.h>
+#include <xen/pfn.h>
+
+#endif  /* __EARLY_TPM__ */
+
+#define TPM_LOC_REG(loc, reg)   (0x1000 * (loc) + (reg))
+
+/******************************** MMIO helpers ********************************/
+
+static uint32_t tpm_read32(unsigned int reg)
+{
+    return *(volatile uint32_t *)__va(TPM_MMIO_BASE + reg);
+}
+
+static uint16_t tpm_read16(unsigned int reg)
+{
+    return *(volatile uint16_t *)__va(TPM_MMIO_BASE + reg);
+}
+
+static uint8_t tpm_read8(unsigned int reg)
+{
+    return *(volatile uint8_t *)__va(TPM_MMIO_BASE + reg);
+}
+
+static void tpm_write8(unsigned int reg, uint8_t val)
+{
+    *(volatile uint8_t *)__va(TPM_MMIO_BASE + reg) = val;
+}
+
+/************************** TIS register definitions **************************/
+
+#define TIS_ACCESS_(x)          TPM_LOC_REG(x, 0x00)
+#define ACCESS_REQUEST_USE       (1 << 1)
+#define ACCESS_ACTIVE_LOCALITY   (1 << 5)
+#define TIS_INTF_CAPABILITY_(x) TPM_LOC_REG(x, 0x14)
+#define INTF_VERSION_MASK        0x70000000
+#define TIS_STS_(x)             TPM_LOC_REG(x, 0x18)
+#define STS_FAMILY_MASK          0x0C000000
+#define STS_EXPECT_DATA          (1 << 3)
+#define STS_DATA_AVAIL           (1 << 4)
+#define STS_TPM_GO               (1 << 5)
+#define STS_COMMAND_READY        (1 << 6)
+#define STS_VALID                (1 << 7)
+#define TIS_BURST_COUNT_(x)     TPM_LOC_REG(x, 0x19)  /* the middle of STS */
+#define TIS_DATA_FIFO_(x)       TPM_LOC_REG(x, 0x24)
+
+/************************** TIS locality & command ****************************/
+
+static void tis_request_locality(unsigned int loc)
+{
+    tpm_write8(TIS_ACCESS_(loc), ACCESS_REQUEST_USE);
+    /* Check that locality was actually activated. */
+    while ( !(tpm_read8(TIS_ACCESS_(loc)) & ACCESS_ACTIVE_LOCALITY) )
+        ;
+}
+
+static void tis_relinquish_locality(unsigned int loc)
+{
+    tpm_write8(TIS_ACCESS_(loc), ACCESS_ACTIVE_LOCALITY);
+}
+
+static uint16_t tis_get_burst_count(unsigned int loc)
+{
+    return tpm_read16(TIS_BURST_COUNT_(loc));
+}
+
+static void tis_send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
+                         unsigned int *o_size)
+{
+    /*
+     * Values of "expect data" and "data available" bits count only when "valid"
+     * field is set as well.
+     */
+    const unsigned int expect_data = STS_VALID | STS_EXPECT_DATA;
+    const unsigned int data_avail = STS_VALID | STS_DATA_AVAIL;
+
+    unsigned int i;
+    unsigned int burst_count;
+
+    /* Make sure TPM can accept a command. */
+    if ( !(tpm_read8(TIS_STS_(loc)) & STS_COMMAND_READY) )
+    {
+        /* Abort current command. */
+        tpm_write8(TIS_STS_(loc), STS_COMMAND_READY);
+        /* Wait until TPM is ready for a new one. */
+        while ( !(tpm_read8(TIS_STS_(loc)) & STS_COMMAND_READY) )
+            ;
+    }
+
+    i = 0;
+    while ( i < i_size )
+    {
+        do
+            burst_count = tis_get_burst_count(loc);
+        while ( burst_count == 0 );
+
+        while ( burst_count-- > 0 && i < i_size )
+            tpm_write8(TIS_DATA_FIFO_(loc), buf[i++]);
+
+        if ( i < i_size )
+        {
+            while ( (tpm_read8(TIS_STS_(loc)) & expect_data) != expect_data )
+                ;
+        }
+    }
+
+    tpm_write8(TIS_STS_(loc), STS_TPM_GO);
+
+    /* Wait for the first byte of response. */
+    while ( (tpm_read8(TIS_STS_(loc)) & data_avail) != data_avail )
+        ;
+
+    i = 0;
+    do {
+        do
+            burst_count = tis_get_burst_count(loc);
+        while ( burst_count == 0 );
+
+        while ( burst_count-- > 0 && i < *o_size)
+            buf[i++] = tpm_read8(TIS_DATA_FIFO_(loc));
+
+        while ( !(tpm_read8(TIS_STS_(loc)) & STS_VALID) )
+            ;
+    } while ( i < *o_size &&
+              (tpm_read8(TIS_STS_(loc)) & data_avail) == data_avail );
+
+    *o_size = i;
+
+    tpm_write8(TIS_STS_(loc), STS_COMMAND_READY);
+}
+
+/************************** Interface dispatch ********************************/
+
+static void request_locality(unsigned int loc)
+{
+    tis_request_locality(loc);
+}
+
+static void relinquish_locality(unsigned int loc)
+{
+    tis_relinquish_locality(loc);
+}
+
+static void send_cmd(unsigned int loc, uint8_t *buf, unsigned int i_size,
+                     unsigned int *o_size)
+{
+    tis_send_cmd(loc, buf, i_size, o_size);
+}
+
+bool tpm_is_tpm1(void)
+{
+    uint32_t intf_version;
+
+    /*
+     * If one of these conditions is true:
+     *  - INTF_CAPABILITY_x.interfaceVersion is 0 (TIS <= 1.21)
+     *  - INTF_CAPABILITY_x.interfaceVersion is 2 (TIS == 1.3)
+     *  - STS_x.tpmFamily is 0
+     * we're dealing with TPM1.2.
+     */
+    intf_version = tpm_read32(TIS_INTF_CAPABILITY_(0)) & INTF_VERSION_MASK;
+    return (intf_version == 0x00000000 || intf_version == 0x20000000 ||
+            !(tpm_read32(TIS_STS_(0)) & STS_FAMILY_MASK));
+}
+
+/****************************** TPM1.2 specific *******************************/
+
+#ifdef __EARLY_TPM__
+/*
+ * TPM1.2 is required to support commands of up to 1101 bytes, vendors rarely
+ * go above that. Limit maximum size of block of data to be hashed to 1024.
+ */
+#define MAX_HASH_BLOCK      1024
+#define CMD_RSP_BUF_SIZE    (sizeof(struct sha1_update_cmd) + MAX_HASH_BLOCK)
+
+union cmd_rsp {
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct sha1_start_cmd start_c;
+    struct sha1_start_rsp start_r;
+    struct sha1_update_cmd update_c;
+    struct sha1_update_rsp update_r;
+    struct sha1_complete_extend_cmd finish_c;
+    struct sha1_complete_extend_rsp finish_r;
+    uint8_t buf[CMD_RSP_BUF_SIZE];
+};
+
+static uint32_t tpm12_hash_extend(unsigned int loc, const uint8_t *buf,
+                                  unsigned int size, unsigned int pcr,
+                                  const struct tpm_log_hashes *log_hashes)
+{
+    union cmd_rsp cmd_rsp;
+    unsigned int max_bytes = MAX_HASH_BLOCK;
+    unsigned int o_size = sizeof(cmd_rsp);
+    uint32_t rc;
+
+    request_locality(loc);
+
+    cmd_rsp.start_c = (struct sha1_start_cmd) {
+        .h.tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.start_c)),
+        .h.ordinal = cpu_to_be32(TPM_ORD_SHA1Start),
+    };
+
+    send_cmd(loc, cmd_rsp.buf, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+    if ( o_size < sizeof(cmd_rsp.start_r) )
+    {
+        rc = TPM_INTERNAL_ERROR;
+        goto error;
+    }
+    rc = be32_to_cpu(cmd_rsp.r.returnCode);
+    if ( rc != 0 )
+        goto error;
+
+    if ( max_bytes > be32_to_cpu(cmd_rsp.start_r.maxNumBytes) )
+        max_bytes = be32_to_cpu(cmd_rsp.start_r.maxNumBytes);
+
+    while ( size > 64 )
+    {
+        if ( size < max_bytes )
+            max_bytes = ROUNDDOWN(size, 64);
+
+        o_size = sizeof(cmd_rsp);
+
+        cmd_rsp.update_c = (struct sha1_update_cmd) {
+            .h.tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
+            .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.update_c) + max_bytes),
+            .h.ordinal = cpu_to_be32(TPM_ORD_SHA1Update),
+            .numBytes = cpu_to_be32(max_bytes),
+        };
+        memcpy(cmd_rsp.update_c.hashData, buf, max_bytes);
+
+        send_cmd(loc, cmd_rsp.buf, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+        if ( o_size < sizeof(cmd_rsp.update_r) )
+        {
+            rc = TPM_INTERNAL_ERROR;
+            goto error;
+        }
+        rc = be32_to_cpu(cmd_rsp.r.returnCode);
+        if ( rc != 0 )
+            goto error;
+
+        size -= max_bytes;
+        buf += max_bytes;
+    }
+
+    o_size = sizeof(cmd_rsp);
+
+    cmd_rsp.finish_c = (struct sha1_complete_extend_cmd) {
+        .h.tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.finish_c) + size),
+        .h.ordinal = cpu_to_be32(TPM_ORD_SHA1CompleteExtend),
+        .pcrNum = cpu_to_be32(pcr),
+        .hashDataSize = cpu_to_be32(size),
+    };
+    memcpy(cmd_rsp.finish_c.hashData, buf, size);
+
+    send_cmd(loc, cmd_rsp.buf, be32_to_cpu(cmd_rsp.c.paramSize), &o_size);
+    if ( o_size < sizeof(cmd_rsp.finish_r) )
+    {
+        rc = TPM_INTERNAL_ERROR;
+        goto error;
+    }
+    rc = be32_to_cpu(cmd_rsp.r.returnCode);
+    if ( rc != 0 )
+        goto error;
+
+    if ( log_hashes->count != 0 )
+    {
+        memcpy(log_hashes->hashes[0].data, cmd_rsp.finish_r.hashValue,
+               SHA1_DIGEST_SIZE);
+    }
+
+    rc = 0;
+
+ error:
+    relinquish_locality(loc);
+    return rc;
+}
+
+#else
+
+union cmd_rsp {
+    struct tpm_cmd_hdr c;
+    struct tpm_rsp_hdr r;
+    struct extend_cmd extend_c;
+    struct extend_rsp extend_r;
+};
+
+static uint32_t tpm12_hash_extend(unsigned int loc, const uint8_t *buf,
+                                  unsigned int size, unsigned int pcr,
+                                  const struct tpm_log_hashes *log_hashes)
+{
+    union cmd_rsp cmd_rsp;
+    unsigned int o_size = sizeof(cmd_rsp);
+    uint32_t rc;
+
+    request_locality(loc);
+
+    cmd_rsp.extend_c = (struct extend_cmd) {
+        .h.tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
+        .h.paramSize = cpu_to_be32(sizeof(cmd_rsp.extend_c)),
+        .h.ordinal = cpu_to_be32(TPM_ORD_Extend),
+        .pcrNum = cpu_to_be32(pcr),
+    };
+
+    sha1(cmd_rsp.extend_c.inDigest, buf, size);
+    if ( log_hashes->count != 0 )
+    {
+        memcpy(log_hashes->hashes[0].data, cmd_rsp.extend_c.inDigest,
+               SHA1_DIGEST_SIZE);
+    }
+
+    send_cmd(loc, (uint8_t *)&cmd_rsp, be32_to_cpu(cmd_rsp.c.paramSize),
+             &o_size);
+    if ( o_size < sizeof(cmd_rsp.extend_r) )
+    {
+        rc = TPM_INTERNAL_ERROR;
+        goto error;
+    }
+    rc = be32_to_cpu(cmd_rsp.r.returnCode);
+    if ( rc != 0 )
+        goto error;
+
+    relinquish_locality(loc);
+
+    rc = 0;
+
+ error:
+    return rc;
+}
+
+#endif /* __EARLY_TPM__ */
+
+/************************** end of TPM1.2 specific ****************************/
+
+uint32_t tpm_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
+                         unsigned int size,
+                         const struct tpm_log_hashes *log_hashes)
+{
+    if ( tpm_is_tpm1() )
+    {
+        if (log_hashes->count != 0 &&
+            !(log_hashes->count == 1 &&
+              log_hashes->hashes[0].alg == TPM_ALG_SHA1 &&
+              log_hashes->hashes[0].size == SHA1_DIGEST_SIZE))
+        {
+#ifndef __EARLY_TPM__
+            printk(XENLOG_ERR "Bad TPM1 log hash for PCR-%u\n", pcr);
+#endif
+            return TPM_INTERNAL_ERROR;
+        }
+
+        return tpm12_hash_extend(loc, buf, size, pcr, log_hashes);
+    }
+
+    return TPM_INTERNAL_ERROR;
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380615.1624304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVws-0002M2-S3; Sun, 02 Aug 2026 13:09:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380615.1624304; Sun, 02 Aug 2026 13:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVws-0002Lu-O5; Sun, 02 Aug 2026 13:09:50 +0000
Received: by outflank-mailman (input) for mailman id 1380615;
 Sun, 02 Aug 2026 13:09:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVwq-0002Lk-AX
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:09:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVwp-001xPK-IM
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:09:47 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4195-5cb7-0a2a0a5109dd-0a2a4506dd12-8
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:46 +0200
Received: from [178.33.46.10] (helo=4.mo561.mail-out.ovh.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f419a-195a-0a2a45060019-b2212e0aa901-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:09:46 +0200
Received: from director7.ghost.mail-out.ovh.net (unknown [10.110.54.182])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hCgBf2cWyz5wxV
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:09:46 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-tcfrn (unknown [10.111.174.62])
 by director7.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 84B5BC00F3;
 Sun,  2 Aug 2026 13:09:45 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.112])
 by ghost-submission-7d8d68f679-tcfrn with ESMTPSA
 id 9Lx+DJlBb2rrfyEAU3TobQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:09:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-112S0067dc25300-a989-4a04-944e-3b51f6587265,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 01/23] x86/mtrr: get rid of a static variable on pause/restore
Date: Sun,  2 Aug 2026 16:09:17 +0300
Message-ID: <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4727090759001843132
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEtK5p0SNYtBef44Zaajhk33i63wmjVwNNhJ4YROChk7mhZcpyT3bd5ACP3F2TkAykP416Z/qj7tU2KxG1rTRS8MypF1KRhaA/AvmFdmp6hM2n75hgvTPUkRMkZtHtCy5BQJTDAa5dye2uRhTva5lFRUMRQoQfXqDmPkoEsCcMiOXhj8LDb8bxT7fPbPw+L6oM3Ib4+Crk5z3znR8b12WvIauAwvZwi4TwyXrVt8t5cjjf6p6tk/jAP3JPPWAt8lJLbOqKqZPj2dLVv8AcggN/kQjhcbgaHkG9r5s4innAGR9o3gaGzW+PeUVjPnviytxFmoTk+gQnhQiwpJq7s595nq0/dNHg0K5j2/u4togUta8cK/sYD5KBkNvqDKDkP2Mqf4xYNTNh5h0uvCo6u6RAiqKqjL4e/nWsAkN1HVqW7sIR+iMygbzv7AJlPA8cxp2kX69Aw+9xSEw4ne+98yONw9skyGEdzNUs5erSqMJWK+0O3epc5lpnqvRdzUJgb8EZdM7Cj9hXLgC8cB1ndL6HKAHXj/w4ela7PY6shb+FWKaaYztmGPyQyPRNz595AZhT890rNV64MLH8m5m7wkb7aRz5vB7zsXcll1SY3nMQH850SCLiHYo879ix6XTKada1yIneAP3BkZliSYtaUIhs1I/4u3jxLPAyGYlJOtawbAg
DKIM-Signature: a=rsa-sha256; bh=45a6v7qxNqaXiQeBDtCOedZ5o8Tq5ypxyrPqCVlyc0I=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676186; v=1;
 b=J+JpuW0eGrX+12iBiIP2laX8HNfi1XKqWNFnPsu8IXbjqRPbqG9YMw2BQBBiFVZjeVwyUGBM
 b4/A5yC7Qby8LzofkxEQL1YWPJLqVqZgxrCtxnmuq26Cb1d0twC/1TsMnu8q6KKc1J+H8x3TQDE
 4GRy3tXPK+YN41rISv5V1FmA6VaON3Gvszfj+Lh7rSIe0xzOMLhhP3aPKu0NbTrRNmG2VuE99e/
 FW4VNGWEn/zGpucfksvt80mBuipCcQadptfdlXWLBUcgeDJPcufB+TIMjVexocUiRaecM3J/E70
 LxTzG8efeyM6LTzTAE6AvRjqUW8tEcReZlH2ZlfXzRsdg==
X-purgate-ID: tlsNG-16d1c6/1785676186-F420077B-D5098E62/0/0
X-purgate-type: clean
X-purgate-size: 5288

In addition to keeping the state in one place instead of on stack and in
a static variable, this enables exposing this functionality to other
units in the future.

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: was called "x86/mtrr: expose functions for pausing caching"
    v4: no longer makes anything public, just updates implementation
    v4: the state structure is now an output parameter instead of a return value
    v4: switches from rdmsrl() to rdmsr() on one line that's updated anyway

 xen/arch/x86/cpu/mtrr/generic.c | 55 +++++++++++++++++----------------
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 23c279eb9a..86eb0f405b 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -14,6 +14,11 @@
 #include <asm/cpufeature.h>
 #include "mtrr.h"
 
+struct mtrr_pausing_state {
+	bool pge;
+	uint64_t def_type;
+};
+
 static const struct fixed_range_block {
 	uint32_t base_msr;   /* start address of an MTRR block */
 	unsigned int ranges; /* number of MTRRs in this block  */
@@ -395,9 +400,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 	return changed;
 }
 
-static uint64_t deftype;
-
-static unsigned long set_mtrr_state(void)
+static unsigned long set_mtrr_state(uint64_t *deftype)
 /*  [SUMMARY] Set the MTRR state for this CPU.
     <state> The MTRR state information to read.
     <ctxt> Some relevant CPU context.
@@ -415,14 +418,12 @@ static unsigned long set_mtrr_state(void)
 	if (mtrr_state.have_fixed && set_fixed_ranges(mtrr_state.fixed_ranges))
 		change_mask |= MTRR_CHANGE_MASK_FIXED;
 
-	/*  Set_mtrr_restore restores the old value of MTRRdefType,
-	   so to set it we fiddle with the saved value  */
-	if ((deftype & 0xff) != mtrr_state.def_type
-	    || MASK_EXTR(deftype, MTRRdefType_E) != mtrr_state.enabled
-	    || MASK_EXTR(deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
-		deftype = (deftype & ~0xcff) | mtrr_state.def_type |
-		          MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
-		          MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
+	if ((*deftype & 0xff) != mtrr_state.def_type
+	    || MASK_EXTR(*deftype, MTRRdefType_E) != mtrr_state.enabled
+	    || MASK_EXTR(*deftype, MTRRdefType_FE) != mtrr_state.fixed_enabled) {
+		*deftype = (*deftype & ~0xcff) | mtrr_state.def_type |
+		           MASK_INSR(mtrr_state.enabled, MTRRdefType_E) |
+		           MASK_INSR(mtrr_state.fixed_enabled, MTRRdefType_FE);
 		change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
 	}
 
@@ -439,7 +440,7 @@ static DEFINE_SPINLOCK(set_atomicity_lock);
  * has been called.
  */
 
-static bool prepare_set(void)
+static void mtrr_pause_caching(struct mtrr_pausing_state *state)
 {
 	unsigned long cr4;
 
@@ -461,7 +462,9 @@ static bool prepare_set(void)
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
 
 	cr4 = read_cr4();
-	if (cr4 & X86_CR4_PGE)
+	state->pge = cr4 & X86_CR4_PGE;
+
+	if (state->pge)
 		write_cr4(cr4 & ~X86_CR4_PGE);
 	else if (use_invpcid)
 		invpcid_flush_all();
@@ -469,27 +472,25 @@ static bool prepare_set(void)
 		write_cr3(read_cr3());
 
 	/*  Save MTRR state */
-	rdmsrl(MSR_MTRRdefType, deftype);
+	state->def_type = rdmsr(MSR_MTRRdefType);
 
 	/*  Disable MTRRs, and set the default type to uncached  */
-	mtrr_wrmsr(MSR_MTRRdefType, deftype & ~0xcff);
+	mtrr_wrmsr(MSR_MTRRdefType, state->def_type & ~0xcff);
 
 	/* Again, only flush caches if we have to. */
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
-
-	return cr4 & X86_CR4_PGE;
 }
 
-static void post_set(bool pge)
+static void mtrr_resume_caching(struct mtrr_pausing_state state)
 {
 	/* Intel (P6) standard MTRRs */
-	mtrr_wrmsr(MSR_MTRRdefType, deftype);
+	mtrr_wrmsr(MSR_MTRRdefType, state.def_type);
 
 	/*  Enable caches  */
 	write_cr0(read_cr0() & ~X86_CR0_CD);
 
 	/*  Reenable CR4.PGE (also flushes the TLB) */
-	if (pge)
+	if (state.pge)
 		write_cr4(read_cr4() | X86_CR4_PGE);
 	else if (use_invpcid)
 		invpcid_flush_all();
@@ -503,15 +504,15 @@ void mtrr_set_all(void)
 {
 	unsigned long mask, count;
 	unsigned long flags;
-	bool pge;
+	struct mtrr_pausing_state pausing_state;
 
 	local_irq_save(flags);
-	pge = prepare_set();
+	mtrr_pause_caching(&pausing_state);
 
 	/* Actually set the state */
-	mask = set_mtrr_state();
+	mask = set_mtrr_state(&pausing_state.def_type);
 
-	post_set(pge);
+	mtrr_resume_caching(pausing_state);
 	local_irq_restore(flags);
 
 	/*  Use the atomic bitops to update the global mask  */
@@ -536,12 +537,12 @@ void mtrr_set(
 {
 	unsigned long flags;
 	struct mtrr_var_range *vr;
-	bool pge;
+	struct mtrr_pausing_state pausing_state;
 
 	vr = &mtrr_state.var_ranges[reg];
 
 	local_irq_save(flags);
-	pge = prepare_set();
+	mtrr_pause_caching(&pausing_state);
 
 	if (size == 0) {
 		/* The invalid bit is kept in the mask, so we simply clear the
@@ -562,7 +563,7 @@ void mtrr_set(
 		mtrr_wrmsr(MSR_IA32_MTRR_PHYSMASK(reg), vr->mask);
 	}
 
-	post_set(pge);
+	mtrr_resume_caching(pausing_state);
 	local_irq_restore(flags);
 }
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380626.1624367 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxA-00054p-RL; Sun, 02 Aug 2026 13:10:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380626.1624367; Sun, 02 Aug 2026 13:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxA-00054D-Lm; Sun, 02 Aug 2026 13:10:08 +0000
Received: by outflank-mailman (input) for mailman id 1380626;
 Sun, 02 Aug 2026 13:10:06 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVx8-0004bl-Bq
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVx7-001xPK-OX
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:05 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4195-5cb7-0a2a0a5109dd-0a2a4506dd12-16
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:05 +0200
Received: from [87.98.179.142] (helo=17.mo550.mail-out.ovh.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41ad-195a-0a2a45060019-5762b38eedc5-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:05 +0200
Received: from director3.ghost.mail-out.ovh.net (unknown [10.110.58.156])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4hCgC10RDWz5yR7
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:04 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-lkzsb (unknown [10.110.178.46])
 by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id F1632C0A40;
 Sun,  2 Aug 2026 13:10:03 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.100])
 by ghost-submission-7d8d68f679-lkzsb with ESMTPSA
 id MaIRK6tBb2rqGBgA1y1k7A
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-100R003147be42b-89d9-414b-ba50-7c1feb6d7b6d,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 07/23] x86/boot: add CONFIG_SLAUNCH, MLE header and Secure Launch entry point
Date: Sun,  2 Aug 2026 16:09:23 +0300
Message-ID: <18917d8a445748ba8e997ef71f3172e8f96ed173.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4732157311134148028
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTGce0r1ej7YhDvQcoqZzEJUtCQawdbz8FQcTUZWO9brC0fe8AmOsukA+lpn9eiuqako/+9EHlgkoenIYWl357JWwxZOYEqD7LgSB99mM+zUZBiC7QnYK6FiDOBKtL9EXtmHdYOKWcos3vmqFqx4iL/JYXlSeHTzjkKOlsOppKzx/OjSnRSPfqZj0haS76+HPBGMt4m9UNntAG8pd1aw7UmCIs68THN1JZzkevU8BOUWLkPp7zSSYrTQoWq+4FNfY85nWoc+NuYU0vsYmLoQ/W/xvsOsp1BFgfhCXbO5dG2+akiMePW94isPsGmNCVi75YOYndcrS2F/rDTAxq8iT2SlplevNjvkj9ERWKOYBz3pR+l3PibRWrN+TamsRsDuT41truaT1bY/63Wshns5HHYig9FakelyGKvVyT4loq4LCsm0x2fjWun6wZ0BF7Ce5Ka/7QrRWs/Cjj0VP7UmomxPBa9IMvGoIG+shwW33VPCKjijK8UsTF0Y6lMwucph3JrTIQDLAHHNzvdHPE1qqQ1s39EHC4plsQqZp30WupmrIUK6hqHAnb29G2CzAWCUo+MxeLLAhsCiNLk9dXeNm/uNHQcHUm+c+Hz784luCrLvBIBTe0cf76KO6AC2VjMLVIX1Ji4EMCq/qflLs2E2RwytP1trb8WQxuda1ajVsAZItQ
DKIM-Signature: a=rsa-sha256; bh=cFSKQz8f5JDd+KNHvqLRMdQrdK9DDxsbcV/OttzdZYs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676205; v=1;
 b=eZSWfAGwHvJHU0enPhMtKBrUHdn0qyBiqANe+N1MybITDguAyRHv+5uxShTp6TtH6jZwOkH9
 kyzVzyVJ37yOxVKRiNM1rdz2MES/w1Svxl+imVnC2mpS7egIIDzWVXFYB0Wje0QlcWzv86xy6aj
 v12D8mGjCqBBDlUOuXxxEJzeNNb6k3N3zKtu9iKz++VMVoxOEu/rHkigTVXHqxNB8HMXcuAB05N
 sLslbO0iw/Kz0lWG7fwok3e3G2mI9FfuQtrbObZ2H2aH6jx+l79jfzzqI2zG/0csU3cnqMvY2B0
 3NaGucJSP9tyEoTqSEZ9xwKTZBwkJ/vHkfqxcYCtcOzkw==
X-purgate-ID: tlsNG-16d1c6/1785676205-FDA0C77B-A49DB105/0/0
X-purgate-type: clean
X-purgate-size: 8714

From: Kacper Stojek <kacper.stojek@3mdeb.com>

Measured Launched Environment (MLE) is Intel TXT specific term for DLME
(Dynamic Launch Measured Environment) which is whatever gets control
after DRTM (Dynamic Root of Trust for Measurement) is initiated.

DRTM is a way to establish hardware root of trust which excludes
firmware and is not directly tied to hardware's boot process (in
contrast to static RTM, or SRTM).  A bootloader compatible with Secure
Launch specification [1] parses MLE header to know how to invoke Xen as
MLE/DLME.  The header is also processed by SINIT ACM.

The new entry point is called `slaunch_stub_entry` and is used mainly to
differentiate from other kinds of boots.  It moves a magic number to
`EAX` before jumping into common startup code.

[1]: https://trenchboot.org/specifications/Secure_Launch/

Signed-off-by: Kacper Stojek <kacper.stojek@3mdeb.com>
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: was "x86/boot: add MLE header and Secure Launch entry point"
    v4: added CONFIG_SLAUNCH Kconfig option
    v4: expanded commit message significantly
    v4: expanded the paragraph added to the documentation
    v4: SLAUNCH_BOOTLOADER_MAGIC now lives here
    v4: MLE header size is now computed from labels
    v4: provided more details in the comment on slaunch_stub_entry
    v4: handle Slaunch bootloader by just hanging (wasn't handled here in v3)
    v4: use __base_reloc_end as an end of image instead of _end

 docs/hypervisor-guide/x86/how-xen-boots.rst | 10 +++
 xen/arch/x86/Kconfig                        |  8 +++
 xen/arch/x86/boot/head.S                    | 76 +++++++++++++++++++++
 3 files changed, 94 insertions(+)

diff --git a/docs/hypervisor-guide/x86/how-xen-boots.rst b/docs/hypervisor-guide/x86/how-xen-boots.rst
index 8b3229005c..a841d1e9f8 100644
--- a/docs/hypervisor-guide/x86/how-xen-boots.rst
+++ b/docs/hypervisor-guide/x86/how-xen-boots.rst
@@ -55,6 +55,16 @@ If ``CONFIG_PVH_GUEST`` was selected at build time, an Elf note is included
 which indicates the ability to use the PVH boot protocol, and registers
 ``__pvh_start`` as the entrypoint, entered in 32bit mode.
 
+A combination of Multiboot 2 and Measured Launched Environment (MLE) headers
+is used to support Dynamic Root of Trust for Measurement (DRTM) for legacy
+(BIOS) boot.  DRTM is a way to establish hardware root of trust which
+excludes firmware and is not directly tied to hardware's boot process.  The
+separate entry point called ``slaunch_stub_entry`` is used mainly to
+differentiate from other kinds of boots.  It moves a magic number to ``EAX``
+before jumping into common startup code.  More details about Secure Launch
+data structures processed by Xen in this boot mode can be found in
+`<https://trenchboot.org/specifications/Secure_Launch/>`_.
+
 
 xen.gz
 ~~~~~~
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3ce0774b8d..d8dac2dcfa 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -187,6 +187,14 @@ config TBOOT
 
 	  If unsure, stay with the default.
 
+config SLAUNCH
+	bool "DRTM via Secure Launch support"
+	depends on INTEL
+	default y
+	help
+	  Allows support for Secure Launch DRTM boot.  This is a boot in a
+	  measured environment which requires a compatible bootloader.
+
 config X86_PSR
 	bool "Platform Shared Resource support" if EXPERT
 	default INTEL
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 68b963ce6f..cbf91b23c9 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -4,6 +4,7 @@
 #include <public/xen.h>
 #include <asm/asm_defns.h>
 #include <asm/fixmap.h>
+#include <asm/intel-txt.h>
 #include <asm/page.h>
 #include <asm/processor.h>
 #include <asm/msr-index.h>
@@ -36,6 +37,7 @@
 #define MB2_TT(name)      (MULTIBOOT2_TAG_TYPE_##name)
 
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
+#define SLAUNCH_BOOTLOADER_MAGIC  0x4c534254
 
         .macro mb2ht_args arg:req, args:vararg
         .long \arg
@@ -126,6 +128,25 @@ multiboot2_header:
         .size multiboot2_header, . - multiboot2_header
         .type multiboot2_header, @object
 
+#if CONFIG_SLAUNCH
+SYM(mle_header, DATA, LOCAL, 16)
+        .long   0x9082ac5a  /* UUID0 */
+        .long   0x74a7476f  /* UUID1 */
+        .long   0xa2555c0f  /* UUID2 */
+        .long   0x42b651cb  /* UUID3 */
+        .long   (.Lmle_header_end - mle_header)  /* MLE header size */
+        .long   0x00020002  /* MLE version 2.2 */
+        .long   (slaunch_stub_entry - start)  /* Linear entry point of MLE (SINIT virt. address) */
+        .long   0x00000000  /* First valid page of MLE */
+        .long   0x00000000  /* Offset within binary of first byte of MLE */
+        .long   (__base_relocs_end - start)  /* Offset within binary of last byte + 1 of MLE */
+        .long   0x00000723  /* Bit vector of MLE-supported capabilities */
+        .long   0x00000000  /* Starting linear address of command line (unused) */
+        .long   0x00000000  /* Ending linear address of command line (unused) */
+.Lmle_header_end:
+        END(mle_header)
+#endif
+
         .section .init.rodata, "a", @progbits
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
@@ -334,6 +355,43 @@ cs32_switch:
         /* Jump to earlier loaded address. */
         jmp     *%edi
 
+#if CONFIG_SLAUNCH
+        /*
+         * Entry point for TrenchBoot Secure Launch on Intel TXT platforms.
+         *
+         * CPU is in 32b protected mode with paging disabled. On entry:
+         * - %ebx = %eip = MLE entry point,
+         * - stack pointer is undefined,
+         * - CS is flat 4GB code segment,
+         * - DS, ES, SS, FS and GS are undefined according to TXT SDG, but this
+         *   would make it impossible to initialize GDTR, because GDT base must
+         *   be relocated in the descriptor, which requires write access that
+         *   CS doesn't provide. Instead we have to assume that some data
+         *   segment register is set by SINIT ACM as flat 4GB data segment and
+         *   choose DS as that register (LGDT instruction uses it by default).
+         *
+         * Additional restrictions:
+         * - some MSRs are partially cleared, among them IA32_MISC_ENABLE, so
+         *   some capabilities might be reported as disabled even if they are
+         *   supported by CPU
+         * - interrupts (including NMIs and SMIs) are disabled and must be
+         *   enabled later
+         * - trying to enter real mode results in reset
+         * - APs are in a special SENTER sleep state and must be woken up by
+         *   writing a non-zero value at a MONITORed address or via
+         *   GETSEC[WAKEUP] instruction, depending on which is supported by a
+         *   given SINIT ACM
+         */
+slaunch_stub_entry:
+        /* Calculate the load base address. */
+        mov     %ebx, %esi
+        sub     $sym_offs(slaunch_stub_entry), %esi
+
+        /* Mark Secure Launch boot protocol and jump to common entry. */
+        mov     $SLAUNCH_BOOTLOADER_MAGIC, %eax
+        jmp     .Lset_stack
+#endif /* CONFIG_SLAUNCH */
+
 #ifdef CONFIG_PVH_GUEST
 ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long sym_offs(__pvh_start))
 
@@ -373,6 +431,7 @@ __start:
         /* Restore the clobbered field. */
         mov     %edx, (%ebx)
 
+.Lset_stack:
         /* Set up stack. */
         lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
 
@@ -421,6 +480,12 @@ __start:
         /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
         xor     %edx,%edx
 
+#if CONFIG_SLAUNCH
+        /* Check for TrenchBoot slaunch bootloader. */
+        cmp     $SLAUNCH_BOOTLOADER_MAGIC, %eax
+        je      .Lslaunch_proto
+#endif
+
         /* Check for Multiboot2 bootloader. */
         cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
         je      .Lmultiboot2_proto
@@ -436,6 +501,17 @@ __start:
         cmovnz  MB_mem_lower(%ebx),%edx
         jmp     trampoline_bios_setup
 
+#if CONFIG_SLAUNCH
+.Lslaunch_proto:
+        /*
+         * Upon reaching here, CPU state mostly matches the one set up by the
+         * bootloader with ESP, ESI and EDX being clobbered above.
+         */
+
+        /* Hang as this boot path is yet to be implemented. */
+        jmp     .Lslaunch_proto
+#endif
+
 .Lmultiboot2_proto:
         /* Skip Multiboot2 information fixed part. */
         lea     (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380628.1624376 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxD-0005OU-B2; Sun, 02 Aug 2026 13:10:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380628.1624376; Sun, 02 Aug 2026 13:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxD-0005OJ-71; Sun, 02 Aug 2026 13:10:11 +0000
Received: by outflank-mailman (input) for mailman id 1380628;
 Sun, 02 Aug 2026 13:10:09 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxB-0005C8-Cx
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxA-001xPK-PV
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:08 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f417c-5cb7-0a2a0a5109dd-0a2a450494b6-24
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:08 +0200
Received: from [178.33.45.107] (helo=5.mo550.mail-out.ovh.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41b0-b57f-0a2a45040019-b2212d6ba827-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:08 +0200
Received: from director3.ghost.mail-out.ovh.net (unknown [10.110.58.129])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4hCgC407Bjz5vcd
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:08 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-l27qx (unknown [10.110.164.150])
 by director3.ghost.mail-out.ovh.net (Postfix) with ESMTPS id EA6A8C087F;
 Sun,  2 Aug 2026 13:10:06 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.110])
 by ghost-submission-7d8d68f679-l27qx with ESMTPSA
 id FEktLq5Bb2p4JBgA8jA8Vg
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-110S004cfa44f52-636f-4fe7-84b6-ee1fcc9c9fc6,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 08/23] include/xen/slr-table.h: Secure Launch Resource Table definitions
Date: Sun,  2 Aug 2026 16:09:24 +0300
Message-ID: <afce12141f0226db49d8826f58c1c8e73e04e2f8.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4733283212314486204
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTFEt9rkYLpJL+cl3MFrtmBH26QPTyhYi9qHrkoiTnaMUtlAY1lwR47UkZfGh/N3kIbPRaT084rWyyj0f2JMoiTIuWk88tOTpqbWD+8hC3sHFIeAIaNwLpfieKAV/oDZeA5fXzWkJ+PufWeKVey7XV+t3gagU0FfqS1GnJw40TdHOt9/zZxCNeNQ1xYrZZk/z9lKt/ZR+fPeb9MX9yw4ylL4i/KvelA7NBtfHURXKRRWfvSctzDm5GYKINzIihhhpAfGKHWkvGkxr+CkOAum/IrGBwxh70xS05ddTJiHy3ZOkrjwYsxmq0h2G1Y4kO2Ig3vOYJzBfxgIKmGVLc7ZkHqbf2qsPN5Rb1vFTaQ5BtV2MoJGLFnn2L/b21tdnnRYR2y7jQOjzFOQ4s1ru9pOgslOIHfSiApTAEuLR+/5XYWGS77z2uSu3JUZrG3CGuGTNWD2PDDLoE3uFtvwUVhICtF1OGUKgVpF5jhXlTUNcQEpcjCy5yrL0z2ppJc+spZybrMTTxK6XgM1UTIkaB9OZiQjBe65tgN8O6j9WCD+1FhVQ8cRQ+lLjLQCVZfRh0hJaadSOGPv2M0r6MSXs14NbcDaO+OYA6TmF+Qpv0YqQJiJVfE9Jwt3GDvNJBfhyctHW+p/5YlLMGzGdOd5T3/SmyUP/obKA5yhXYoMTgnmHA64PA
DKIM-Signature: a=rsa-sha256; bh=iSnIQz4NjR9M23iyGWMbP2PkGPiuWCB32F9e/qscvEE=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676208; v=1;
 b=VRPFLOY95wvJxvGOtSy5r5WNPBoBKAaoYamtPZLswuVOxgHXFbdno3tUHgT6PqCNHuSgb6k9
 +5Bo3IXFi7Tdo4ftzm7xqImwreLqKEr4ay33bAI/1SxAx4FmpWtqmV8Ng0ep9li/5GGkoIYRmka
 9f4xjSRDZMQDkKzc03b0t06Y4bvcjoo3yuRghUmY+3WEPxptxLzuyDE9QwXNBzjjpKyvyMdKVAH
 caEmiHsJHO/nYt9JakkZXzqHYc+B3mZrb21TUv6/yo2eiZr+0zjOdjwkcbW6fQeJ0JYUblgS8B9
 DonZxSImz7ztBgQZqZDx00BZCOs5LKoQ7N3qd9mVTInVw==
X-purgate-ID: tlsNG-ebf023/1785676208-C26CAB50-7D5768F5/0/0
X-purgate-type: clean
X-purgate-size: 7668

The file provides constants, structures and several helper functions for
parsing SLRT.

The data described by the structures is passed to Xen by a bootloader
which initiated DRTM.

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: don't define UEFI_SLR_TABLE_GUID here, it's specific to UEFI support
    v4: made pointer parameter of dl_handler_func() constant

 xen/include/xen/slr-table.h | 272 ++++++++++++++++++++++++++++++++++++
 1 file changed, 272 insertions(+)
 create mode 100644 xen/include/xen/slr-table.h

diff --git a/xen/include/xen/slr-table.h b/xen/include/xen/slr-table.h
new file mode 100644
index 0000000000..e3e5eb75f2
--- /dev/null
+++ b/xen/include/xen/slr-table.h
@@ -0,0 +1,272 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *  Secure Launch Resource Table definitions.  This table is passed to Xen by
+ *  a bootloader and contains information about pre-DRTM state necessary to
+ *  restore hardware configuration, where to find TPM event log, how to call
+ *  back into the bootloader (for EFI case) and what needs to be measured by
+ *  Xen.  In other words, this is similar to MBI in Multiboot Specification.
+ *
+ *  Specification:
+ *    https://trenchboot.org/specifications/Secure_Launch/
+ *
+ *  Copyright (c) 2025 Apertus Solutions, LLC
+ *  Copyright (c) 2025 Oracle and/or its affiliates.
+ *  Copyright (c) 2026 3mdeb Sp. z o.o
+ */
+
+#ifndef XEN_SLR_TABLE_H
+#define XEN_SLR_TABLE_H
+
+#include <xen/types.h>
+
+/* SLR table header values */
+#define SLR_TABLE_MAGIC         0x4452544d
+#define SLR_TABLE_REVISION      1
+
+/* Current revisions for the policy and UEFI config */
+#define SLR_POLICY_REVISION         1
+#define SLR_UEFI_CONFIG_REVISION    1
+
+/* SLR defined architectures */
+#define SLR_INTEL_TXT   1
+#define SLR_AMD_SKINIT  2
+
+/* SLR defined bootloaders */
+#define SLR_BOOTLOADER_INVALID  0
+#define SLR_BOOTLOADER_GRUB     1
+
+/* Log formats */
+#define SLR_DRTM_TPM12_LOG      1
+#define SLR_DRTM_TPM20_LOG      2
+
+/* DRTM Policy Entry Flags */
+#define SLR_POLICY_FLAG_MEASURED    0x1
+#define SLR_POLICY_IMPLICIT_SIZE    0x2
+
+/* Array Lengths */
+#define TPM_EVENT_INFO_LENGTH       32
+#define TXT_VARIABLE_MTRRS_LENGTH   32
+
+/* Tags */
+#define SLR_ENTRY_INVALID       0x0000
+#define SLR_ENTRY_DL_INFO       0x0001
+#define SLR_ENTRY_LOG_INFO      0x0002
+#define SLR_ENTRY_DRTM_POLICY   0x0003
+#define SLR_ENTRY_INTEL_INFO    0x0004
+#define SLR_ENTRY_AMD_INFO      0x0005
+#define SLR_ENTRY_ARM_INFO      0x0006
+#define SLR_ENTRY_UEFI_INFO     0x0007
+#define SLR_ENTRY_UEFI_CONFIG   0x0008
+#define SLR_ENTRY_END           0xffff
+
+/* Entity Types */
+#define SLR_ET_UNSPECIFIED        0x0000
+#define SLR_ET_SLRT               0x0001
+#define SLR_ET_BOOT_PARAMS        0x0002
+#define SLR_ET_SETUP_DATA         0x0003
+#define SLR_ET_CMDLINE            0x0004
+#define SLR_ET_UEFI_MEMMAP        0x0005
+#define SLR_ET_RAMDISK            0x0006
+#define SLR_ET_MULTIBOOT2_INFO    0x0007
+#define SLR_ET_MULTIBOOT2_MODULE  0x0008
+#define SLR_ET_TXT_OS2MLE         0x0010
+#define SLR_ET_UNUSED             0xffff
+
+/*
+ * Primary SLR Table Header
+ */
+struct slr_table
+{
+    uint32_t magic;
+    uint16_t revision;
+    uint16_t architecture;
+    uint32_t size;
+    uint32_t max_size;
+    /* entries[] */
+} __packed;
+
+/*
+ * Common SLRT Table Header
+ */
+struct slr_entry_hdr
+{
+    uint32_t tag;
+    uint32_t size;
+} __packed;
+
+/*
+ * Boot loader context
+ */
+struct slr_bl_context
+{
+    uint16_t bootloader;
+    uint16_t reserved[3];
+    uint64_t context;
+} __packed;
+
+/*
+ * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
+ */
+typedef void (*dl_handler_func)(const struct slr_bl_context *bl_context);
+
+/*
+ * DRTM Dynamic Launch Configuration
+ */
+struct slr_entry_dl_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t dce_size;
+    uint64_t dce_base;
+    uint64_t dlme_size;
+    uint64_t dlme_base;
+    uint64_t dlme_entry;
+    struct slr_bl_context bl_context;
+    uint64_t dl_handler;
+} __packed;
+
+/*
+ * TPM Log Information
+ */
+struct slr_entry_log_info
+{
+    struct slr_entry_hdr hdr;
+    uint16_t format;
+    uint16_t reserved;
+    uint32_t size;
+    uint64_t addr;
+} __packed;
+
+/*
+ * DRTM Measurement Entry
+ */
+struct slr_policy_entry
+{
+    uint16_t pcr;
+    uint16_t entity_type;
+    uint16_t flags;
+    uint16_t reserved;
+    uint64_t size;
+    uint64_t entity;
+    char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+/*
+ * DRTM Measurement Policy
+ */
+struct slr_entry_policy
+{
+    struct slr_entry_hdr hdr;
+    uint16_t reserved[2];
+    uint16_t revision;
+    uint16_t nr_entries;
+    struct slr_policy_entry policy_entries[];
+} __packed;
+
+/*
+ * Secure Launch defined MTRR saving structures
+ */
+struct slr_txt_mtrr_pair
+{
+    uint64_t mtrr_physbase;
+    uint64_t mtrr_physmask;
+} __packed;
+
+struct slr_txt_mtrr_state
+{
+    uint64_t default_mem_type;
+    uint64_t mtrr_vcnt;
+    struct slr_txt_mtrr_pair mtrr_pair[TXT_VARIABLE_MTRRS_LENGTH];
+} __packed;
+
+/*
+ * Intel TXT Info table
+ */
+struct slr_entry_intel_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t boot_params_base;
+    uint64_t txt_heap;
+    uint64_t saved_misc_enable_msr;
+    struct slr_txt_mtrr_state saved_bsp_mtrrs;
+} __packed;
+
+/*
+ * AMD SKINIT Info table
+ */
+struct slr_entry_amd_info
+{
+    struct slr_entry_hdr hdr;
+    uint64_t next;
+    uint32_t type;
+    uint32_t len;
+    uint64_t slrt_size;
+    uint64_t slrt_base;
+    uint64_t boot_params_base;
+    uint16_t psp_version;
+    uint16_t reserved[3];
+} __packed;
+
+/*
+ * UEFI config measurement entry
+ */
+struct slr_uefi_cfg_entry
+{
+    uint16_t pcr;
+    uint16_t reserved;
+    uint32_t size;
+    uint64_t cfg; /* address or value */
+    char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+struct slr_entry_uefi_config
+{
+    struct slr_entry_hdr hdr;
+    uint16_t reserved[2];
+    uint16_t revision;
+    uint16_t nr_entries;
+    struct slr_uefi_cfg_entry uefi_cfg_entries[];
+} __packed;
+
+static inline const void *
+slr_end_of_entries(const struct slr_table *table)
+{
+    return (const void *)table + table->size;
+}
+
+static inline const struct slr_entry_hdr *
+slr_next_entry(const struct slr_table *table, const struct slr_entry_hdr *curr)
+{
+    const struct slr_entry_hdr *next = (void *)curr + curr->size;
+
+    if ( (void *)next + sizeof(*next) > slr_end_of_entries(table) )
+        return NULL;
+    if ( next->tag == SLR_ENTRY_END )
+        return NULL;
+    if ( (void *)next + next->size > slr_end_of_entries(table) )
+        return NULL;
+
+    return next;
+}
+
+static inline const struct slr_entry_hdr *
+slr_next_entry_by_tag(const struct slr_table *table,
+                      const struct slr_entry_hdr *entry,
+                      uint16_t tag)
+{
+    if ( !entry ) /* Start from the beginning */
+        entry = (void *)table + sizeof(*table);
+
+    for ( ; ; )
+    {
+        if ( entry->tag == tag )
+            return entry;
+
+        entry = slr_next_entry(table, entry);
+        if ( !entry )
+            return NULL;
+    }
+
+    return NULL;
+}
+
+#endif /* XEN_SLR_TABLE_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380631.1624386 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxF-0005hG-Kp; Sun, 02 Aug 2026 13:10:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380631.1624386; Sun, 02 Aug 2026 13:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxF-0005gv-Fd; Sun, 02 Aug 2026 13:10:13 +0000
Received: by outflank-mailman (input) for mailman id 1380631;
 Sun, 02 Aug 2026 13:10:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxE-0005Z5-6e
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxD-001xPK-Jl
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:11 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4195-5cb7-0a2a0a5109dd-0a2a4506dd12-22
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:11 +0200
Received: from [46.105.41.146] (helo=1.mo575.mail-out.ovh.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41b3-195a-0a2a45060019-2e69299290d5-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:11 +0200
Received: from director10.ghost.mail-out.ovh.net (unknown [10.110.43.150])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4hCgC66llDz5xLM
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:10 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-z97vt (unknown [10.108.42.126])
 by director10.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 1481DC0F52;
 Sun,  2 Aug 2026 13:10:09 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.97])
 by ghost-submission-7d8d68f679-z97vt with ESMTPSA
 id HOPCMbFBb2qckyEA8OaJdQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-97G002759774ff-67e2-4e88-897e-e4d797b01b88,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 09/23] x86/boot/slaunch-early: implement early initialization
Date: Sun,  2 Aug 2026 16:09:25 +0300
Message-ID: <d454fcaf31f09b36610b8d5e60ff04c1ca60c4fc.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4733846160438273468
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTGsfQl4qlsgd+N+wAzPmNJTn57cp9N+xnwwaaRrUX/V6epLRbAkTLzIb7MrZYzAgV1mXqxto38PVOV8M1gCRAWNqYLO/9D/7ThxqhtJqfPGAKmZVxIjAM5yEQUhCC6dFnujA3MWREnZFdoQzTCxfJojxKdW5ZChWkOJ9AUQ25O/ECkniAmAiMyzFAzvJZDzqhq14vVGsj761l+whWE5dDh9InBX3k6L+BJwmxnLWn+XkNLVJdB0+nUqxAu4mV0REM3RkTdxePykHWGme39HCkYRWu0q6kGsSu5zbfL/bw71j8mrKZtU3nfWKi+AH44O8zieSUy8MIUD+q1k8bB7ssEPhNfj9OEi9xLqa1+Xt1VA4rfkgRYFTniRTP5m3YgRi0tMQ/SNdSCUr3aq50yJ1wsUWvD3ZP9ohRYBdJdqovqMMY5V7LdxGscZKk+tDmygUb4FRl14qXnTpQIoWchT08ATCom1yDdxGg7+9QrdBEpVKwRmhSj9btO681DQ9bjopyjb33Yy1YMVcbH63TRixsnjW2o15ZxIEIQqKyvJ99fYP40fp0/o60xgFE0KN9l4KWt+qSXagZM76FNocYylod5B3KXJtnH6GBiLeFbYOQ4sRpNZDHYZa9idwh4OnR/w3oaseQKlvT0wxKrXNvPF2PboKj6aiZs1ELlWKcWH393A4A
DKIM-Signature: a=rsa-sha256; bh=XpO21I90FRNGjruF0bFEEp2uwv0PGytNt88X2ZMCmZo=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676211; v=1;
 b=AXUCSSpG9s/N0sPc/aP7QeTc8dNX+hcQaMGZcUZX//cS8twv9vc8pEv+cEqzA7jHbkfTWhan
 aEUAFbjtMhyuG877a0hfYsoeJ0XfXpji5l0EoVMjYno3TgMNJxdGTIbv0v2RdFJ6ywBUJxhvJiY
 666+bupgb1KBT8Ri/szwp8D1DrNMO2qMvoZMzeE458XkNTdQ/aiPyjfH7HmMGvjx6sHu5LRHNbb
 S6m3EyRTFCIzTLzlttcsMU7HXW7WUKS75kYREyssDywY5fy6fyMgQpCac7nc0jg0OLGYnOv9Kj6
 7C6/3aAEVIpNnmiTjXaqjq7G//nVL5sz5mtEJoAQAGBvw==
X-purgate-ID: tlsNG-16d1c6/1785676211-1F2C677B-AA1B2DB9/0/0
X-purgate-type: clean
X-purgate-size: 11362

Make head.S invoke a C function to retrieve MBI and SLRT addresses in a
platform-specific way.  This is also the place to perform sanity checks
of DRTM.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: use CONFIG_SLAUNCH
    v4: expose slaunch_early_init_results via asm-offsets.c to not hard-code its size
    v4: use `mov` instead of `lea` in head.S
    v4: put SPDX license comment on its own line
    v4: check that SLRT address is below 4 GiB
    v4: perform a TXT reset with specific error codes if data doesn't meet expectations
    v4: replace SLAUNCH_ERROR_GENERIC with specific error codes
    v4: removed declaration and a reference to otherwise unused slaunch_get_slrt()
    v4: mark `slaunch_active` variable with `__ro_after_init`
    v4: updates to the handling of TXT heap sections due to different API

 xen/arch/x86/Makefile                |  1 +
 xen/arch/x86/boot/Makefile           | 12 +++++++-
 xen/arch/x86/boot/head.S             | 35 +++++++++++++++++++--
 xen/arch/x86/boot/slaunch-early.c    | 46 ++++++++++++++++++++++++++++
 xen/arch/x86/include/asm/intel-txt.h | 20 ++++++++++++
 xen/arch/x86/include/asm/slaunch.h   | 30 ++++++++++++++++++
 xen/arch/x86/slaunch.c               | 32 +++++++++++++++++++
 xen/arch/x86/x86_64/asm-offsets.c    | 10 ++++++
 8 files changed, 183 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/boot/slaunch-early.c
 create mode 100644 xen/arch/x86/include/asm/slaunch.h
 create mode 100644 xen/arch/x86/slaunch.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 293f3bee35..a03f5a91ef 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_COMPAT) += x86_64/physdev.o
 obj-$(CONFIG_X86_PSR) += psr.o
 obj-y += setup.o
 obj-y += shutdown.o
+obj-$(CONFIG_SLAUNCH) += slaunch.o
 obj-y += smp.o
 obj-y += smpboot.o
 obj-y += spec_ctrl.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index feae17c14a..02f690d34a 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -5,10 +5,18 @@ obj-bin-y += $(obj64)
 obj32 := cmdline.32.o
 obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
+ifeq ($(CONFIG_SLAUNCH),y)
+obj32 += slaunch-early.32.o
+endif
 obj32 += tpm-early.32.o
 
 obj64 := reloc-trampoline.o
 
+exports := cmdline_parse_early,reloc,reloc_trampoline32
+ifeq ($(CONFIG_SLAUNCH),y)
+exports := $(exports),slaunch_early_init
+endif
+
 nocov-y   += $(obj32) $(obj64)
 noubsan-y += $(obj32) $(obj64)
 targets   += $(obj32)
@@ -29,6 +37,8 @@ $(obj32): XEN_CFLAGS := $(CFLAGS_x86_32) -fpic
 $(obj)/%.32.o: $(src)/%.c FORCE
 	$(call if_changed_rule,cc_o_c)
 
+$(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
+
 $(obj)/tpm-early.32.o: XEN_CFLAGS += -D__EARLY_TPM__
 $(obj)/tpm-early.32.o: $(src)/../tpm.c FORCE
 	$(call if_changed_rule,cc_o_c)
@@ -86,7 +96,7 @@ cmd_combine = \
               --bin1      $(obj)/built-in-32.base.bin \
               --bin2      $(obj)/built-in-32.offset.bin \
               --map       $(obj)/built-in-32.base.map \
-              --exports   cmdline_parse_early,reloc,reloc_trampoline32 \
+              --exports   $(exports) \
               --output    $@
 
 targets += built-in-32.S
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index cbf91b23c9..700d1d850e 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -508,8 +508,39 @@ __start:
          * bootloader with ESP, ESI and EDX being clobbered above.
          */
 
-        /* Hang as this boot path is yet to be implemented. */
-        jmp     .Lslaunch_proto
+        /* Save information that TrenchBoot slaunch was used. */
+        movb    $1, sym_esi(slaunch_active)
+
+        /*
+         * Prepare space for output parameter of slaunch_early_init(), which is
+         * the following structure:
+         *   struct slaunch_early_init_results
+         *   {
+         *       uint32_t mbi_pa;
+         *       uint32_t slrt_pa;
+         *   } __packed;
+         */
+        sub     $SL_EIR_size, %esp
+
+        push    %esp                              /* pointer to output structure */
+        mov     $sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
+        mov     $sym_offs(_start), %edx           /* target base address */
+        mov     %esi, %eax                        /* load base address */
+        /*
+         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
+         * fastcall calling convention.
+         */
+        call    slaunch_early_init
+        add     $4, %esp                         /* pop the fourth parameter */
+
+        /* Move outputs of slaunch_early_init() from the stack. */
+        pop     %ebx                  /* store physical MBI address in EBX where
+                                         MB2 code expects it */
+        pop     sym_esi(slaunch_slrt) /* save physical address of SLRT for C
+                                         code */
+
+        /* Move magic number expected by Multiboot 2 to EAX and fall through. */
+        movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
 #endif
 
 .Lmultiboot2_proto:
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
new file mode 100644
index 0000000000..35992cb9b3
--- /dev/null
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Early Slaunch initialization code responsible for determining location of
+ * MBI and SLRT and enforcing basic conditions.
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#include <xen/kernel.h>
+#include <xen/slr-table.h>
+#include <xen/types.h>
+
+#include <asm/intel-txt.h>
+#include <asm/slaunch.h>
+
+void asmlinkage slaunch_early_init(uint32_t load_base_addr,
+                                   uint32_t tgt_base_addr,
+                                   uint32_t tgt_end_addr,
+                                   struct slaunch_early_init_results *result)
+{
+    void *txt_heap;
+    const struct txt_os_mle_data *os_mle;
+    const struct slr_table *slrt;
+    const struct slr_entry_hdr *entry;
+    const struct slr_entry_intel_info *intel_info;
+
+    txt_heap = txt_init();
+    os_mle = txt_start(txt_heap, TXT_OS2MLE);
+
+    if ( os_mle->slrt & ~0xffffffffULL )
+        txt_reset(SLAUNCH_ERROR_BAD_SLRT_ADDRESS);
+
+    result->slrt_pa = os_mle->slrt;
+
+    slrt = (const struct slr_table *)result->slrt_pa;
+
+    entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+    if ( entry == NULL )
+        txt_reset(SLAUNCH_ERROR_NO_VENDOR_INFO);
+
+    intel_info = container_of(entry, const struct slr_entry_intel_info, hdr);
+    if ( intel_info->hdr.size != sizeof(*intel_info) )
+        txt_reset(SLAUNCH_ERROR_BAD_VENDOR_INFO);
+
+    result->mbi_pa = intel_info->boot_params_base;
+}
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 15d474f002..dc6c689f1a 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -62,6 +62,9 @@
 #define SLAUNCH_ERROR_BUFFER_BEYOND_PMR 0xc0008006U
 #define SLAUNCH_ERROR_HEAP_BAD_OS2MLE   0xc0008007U
 #define SLAUNCH_ERROR_HEAP_BAD_OS2SINIT 0xc0008008U
+#define SLAUNCH_ERROR_NO_VENDOR_INFO    0xc0008009U
+#define SLAUNCH_ERROR_BAD_VENDOR_INFO   0xc000800AU
+#define SLAUNCH_ERROR_BAD_SLRT_ADDRESS  0xc000800BU
 
 #ifndef __ASSEMBLER__
 
@@ -245,6 +248,23 @@ static inline void *txt_start(void *heap, int table_index)
     return heap + sizeof(uint64_t);
 }
 
+static inline void *txt_init(void)
+{
+    void *txt_heap;
+
+    /* Clear the TXT error register for a clean start of the day. */
+    txt_write(TXTCR_ERRORCODE, 0);
+
+    txt_heap = _p(txt_read(TXTCR_HEAP_BASE));
+
+    if ( txt_size(txt_heap, TXT_OS2MLE) < sizeof(struct txt_os_mle_data) )
+        txt_reset(SLAUNCH_ERROR_HEAP_BAD_OS2MLE);
+    if ( txt_size(txt_heap, TXT_OS2SINIT) < sizeof(struct txt_os_sinit_data) )
+        txt_reset(SLAUNCH_ERROR_HEAP_BAD_OS2SINIT);
+
+    return txt_heap;
+}
+
 #endif /* !__ASSEMBLER__ */
 
 #endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
new file mode 100644
index 0000000000..24ba164c0a
--- /dev/null
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Declarations related to Slaunch (an implementation of a DRTM launch).  This
+ * header is consumed by both normal and early boot code and has to take the
+ * two environments into account.
+ *
+ * More details about Slaunch are available at:
+ *   https://trenchboot.org/specifications/Secure_Launch/
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#ifndef X86_SLAUNCH_H
+#define X86_SLAUNCH_H
+
+#include <xen/types.h>
+
+struct slaunch_early_init_results
+{
+    uint32_t mbi_pa;
+    uint32_t slrt_pa;
+} __packed;
+
+/* Indicates an active Secure Launch boot. */
+extern bool slaunch_active;
+
+/* Holds physical address of SLRT. */
+extern uint32_t slaunch_slrt;
+
+#endif /* X86_SLAUNCH_H */
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
new file mode 100644
index 0000000000..acf751804f
--- /dev/null
+++ b/xen/arch/x86/slaunch.c
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Main Slaunch code used during boot process.
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#include <xen/compiler.h>
+#include <xen/init.h>
+#include <xen/inttypes.h>
+#include <xen/macros.h>
+#include <xen/sections.h>
+
+#include <asm/slaunch.h>
+
+/*
+ * These variables are assigned to by the code near Xen's entry point.
+ *
+ * slaunch_active is not __initdata to allow checking for an active Secure
+ * Launch boot at any point.
+ */
+bool __ro_after_init slaunch_active;
+uint32_t __initdata slaunch_slrt; /* physical address */
+
+/*
+ * Using slaunch_active in head.S assumes it's a single byte in size, so enforce
+ * this assumption.
+ */
+static void __maybe_unused compile_time_checks(void)
+{
+    BUILD_BUG_ON(sizeof(slaunch_active) != 1);
+}
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index baf266ab80..f0aaf0f4ba 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -16,6 +16,9 @@
 #include <xen/multiboot.h>
 #include <xen/multiboot2.h>
 #include <asm/guest-msr.h>
+#ifdef CONFIG_SLAUNCH
+#include <asm/slaunch.h>
+#endif
 
 #ifdef CONFIG_VIDEO
 # include "../boot/video.h"
@@ -236,4 +239,11 @@ void __dummy__(void)
     DEFINE(BVI_size,            sizeof(struct boot_video_info));
     BLANK();
 #endif /* CONFIG_VIDEO */
+
+#ifdef CONFIG_SLAUNCH
+    OFFSET(SL_EIR_mbi_pa,   struct slaunch_early_init_results, mbi_pa);
+    OFFSET(SL_EIR_slrt_pa,  struct slaunch_early_init_results, slrt_pa);
+    DEFINE(SL_EIR_size,     sizeof(struct slaunch_early_init_results));
+    BLANK();
+#endif
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380634.1624394 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxI-0006Bx-Uh; Sun, 02 Aug 2026 13:10:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380634.1624394; Sun, 02 Aug 2026 13:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxI-0006Bl-RA; Sun, 02 Aug 2026 13:10:16 +0000
Received: by outflank-mailman (input) for mailman id 1380634;
 Sun, 02 Aug 2026 13:10:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxH-0005zZ-B3
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxG-001lF1-OE
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:14 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4178-e002-0a2a0a5209dd-0a2a450adcca-20
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:14 +0200
Received: from [178.33.253.128] (helo=13.mo550.mail-out.ovh.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41b6-f2d2-0a2a450a0019-b221fd8086dd-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:14 +0200
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.249.53])
 by mo550.mail-out.ovh.net (Postfix) with ESMTP id 4hCgC96FF6z5vqC
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:13 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-fpgjl (unknown [10.110.188.109])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 21233C0C02;
 Sun,  2 Aug 2026 13:10:12 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.110])
 by ghost-submission-7d8d68f679-fpgjl with ESMTPSA
 id 3QscMLRBb2oQFhcAmIgvlw
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-110S00492330883-8e1e-4041-880f-17e41b1ce3ec,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 10/23] x86/boot/slaunch-early: early Intel TXT sanity checks
Date: Sun,  2 Aug 2026 16:09:26 +0300
Message-ID: <474ab4540b1b78a818f873e77b29e586c37cedfd.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4734690583935657404
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEtK5p0SNYtBef44Zaajhk33i63wmjVwNNhJ4YROChk7mhZcpyT3bd5ACP3F2TkAykP416Z/qj7tU2KxG1rTRS8MypF1KRhaA/AvmFdmp6hM2n75hgvTPUkRMkZtHtCy5BQJTDAa5dye2uRhTva5lFRUMRQoQfXqDmPkoEsCcMiOXhj8LDb8bxT7fPbPw+L6oM3Ib4+Crk5z3znR8b12WvIauAwvZwi4TwyXrVt8t5cjjf6p6tk/jAP3JPPWAt8lJLbOqKqZPj2dLVv8AcggN/kQjhcbgaHkG9r5s4innAGR9o3gaGzW+PeUVjPnviytxFmoTk+gQnhQiwpJq7s595nR3i4f5Pd9uZjZZwp5dja8ThsJAWAqSi0Ji08ZzRSfvsKevsf4lI4r3AceU0+TOjsi8cfX9Ebz4U0JdUYHwuqIjjMujsfCM+CX3cvqBTAbRdRyYCD/REj1KlkgZzpr6PNcpnwBs/LOoWYORw4Z8m2KbbvJzyNsm49G9kv8LDYod6P9Tz6d3frSOvoD11isMQR94DHI8J0bdj/w01vBfslM8X2Z1FiphvHWr0lNUC/9fLVawzXhoaLkn9H6Z/SPWG6PTjnKx4TBwruKEnmHdzSjgOB3YOwi5RRvh1zWQGOH71mFymbSEgJG0UmOh6cw2ozzDu2itvychXQUm0N0LyHzw
DKIM-Signature: a=rsa-sha256; bh=PcPWVqGwirde0tITg3pYCTNlAzedu0RLv0kvrhdujRg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676213; v=1;
 b=ZQnx8jMMOt5aRGygMY3FWyn00QnqOqGrQv503Y2hK16qP/Fb8WVYwjf4y6LRjEgRlgVZsJA7
 uVI3jjkOFa/vbo/lATiX9Kjlvjl4F7S1hCmxTbWlyFJyN13dzrGz+IIqvFZxHjXefRIsj+slQwR
 JNWkvoscfZSgiPBEYR1xfIWxk+79Q43LH1HDiAOHB8bGKN0mjxLl9/SPPGbv2XXTu/aXG8w67IE
 CQbNbNRwS2ueSJFLejAd8lWkXmSf85FRfRSpxbI9Ro7Q0tPoBbz6RA4QNSyDvELly0guOYLAGri
 bGq8gGyZfrxK3yT9O0pIZKHdOp/5Yv3Izd0ofv9pE0l/Q==
X-purgate-ID: tlsNG-4011c0/1785676214-599C1CFC-519EFD12/0/0
X-purgate-type: clean
X-purgate-size: 8036

From: Krystian Hebel <krystian.hebel@3mdeb.com>

The tests validate that important parts of memory are protected against
DMA attacks, including Xen and MBI. Modules can be tested later, when it
is possible to report issues to a user before invoking TXT reset.

The protection used here is Protected Memory Regions (PMRs), which is
not available on modern hardware like MeteorLake that uses TXT DMA
Protection Ranges (TPR) and is to be added separately.

TPM event log validation is temporarily disabled due to an issue with
its allocation by bootloader (GRUB) which will need to be modified to
address this. Ultimately event log will also have to be validated early
as it is used immediately after these tests to hold MBI measurements.
See larger comment in txt_verify_pmr_ranges().

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: was "x86/boot/slaunch-early: early TXT checks and boot data retrieval"
    v4: updates to the handling of TXT heap sections due to different API
    v4: use `bool` instead of `int` in two places
    v4: don't use low range in is_in_pmr(), it must be zero
    v4: use `struct multiboot2_fixed_t` instead of casting and dereferencing `uint32_t *`
    v4: TPM event log check being covered by PMR can't be safely uncommented without constraining where TPM event log is allocated

 xen/arch/x86/boot/slaunch-early.c    |   6 ++
 xen/arch/x86/include/asm/intel-txt.h | 118 +++++++++++++++++++++++++++
 2 files changed, 124 insertions(+)

diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index 35992cb9b3..00c772cfdf 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -21,11 +21,14 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     void *txt_heap;
     const struct txt_os_mle_data *os_mle;
     const struct slr_table *slrt;
+    const struct txt_os_sinit_data *os_sinit;
     const struct slr_entry_hdr *entry;
     const struct slr_entry_intel_info *intel_info;
+    uint32_t size = tgt_end_addr - tgt_base_addr;
 
     txt_heap = txt_init();
     os_mle = txt_start(txt_heap, TXT_OS2MLE);
+    os_sinit = txt_start(txt_heap, TXT_OS2SINIT);
 
     if ( os_mle->slrt & ~0xffffffffULL )
         txt_reset(SLAUNCH_ERROR_BAD_SLRT_ADDRESS);
@@ -43,4 +46,7 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
         txt_reset(SLAUNCH_ERROR_BAD_VENDOR_INFO);
 
     result->mbi_pa = intel_info->boot_params_base;
+
+    txt_verify_pmr_ranges(os_mle, os_sinit, intel_info,
+                          load_base_addr, tgt_base_addr, size);
 }
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index dc6c689f1a..66039dbeee 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -68,6 +68,9 @@
 
 #ifndef __ASSEMBLER__
 
+#include <xen/multiboot2.h>
+#include <xen/slr-table.h>
+
 /* Need to differentiate between pre- and post paging enabled. */
 #ifdef __EARLY_SLAUNCH__
 #include <xen/macros.h>
@@ -265,6 +268,121 @@ static inline void *txt_init(void)
     return txt_heap;
 }
 
+static inline bool is_in_pmr(const struct txt_os_sinit_data *os_sinit,
+                             uint64_t base, uint32_t size, bool check_high)
+{
+    /* Check for size overflow. */
+    if ( base + size < base )
+        txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+
+    /*
+     * txt_verify_pmr_ranges() makes sure the low range always starts at 0, so
+     * its size is also end address.
+     */
+    if ( base + size <= os_sinit->vtd_pmr_lo_size )
+        return true;
+
+    if ( check_high && os_sinit->vtd_pmr_hi_size != 0 )
+    {
+        if ( base >= os_sinit->vtd_pmr_hi_base &&
+             base + size <= os_sinit->vtd_pmr_hi_base +
+                            os_sinit->vtd_pmr_hi_size )
+            return true;
+    }
+
+    return false;
+}
+
+static inline void txt_verify_pmr_ranges(
+    const struct txt_os_mle_data *os_mle,
+    const struct txt_os_sinit_data *os_sinit,
+    const struct slr_entry_intel_info *info,
+    uint32_t load_base_addr,
+    uint32_t tgt_base_addr,
+    uint32_t xen_size)
+{
+    bool check_high_pmr = false;
+
+    /* Verify the value of the low PMR base. It should always be 0. */
+    if ( os_sinit->vtd_pmr_lo_base != 0 )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
+
+    /*
+     * Low PMR size should not be 0 on current platforms. There is an ongoing
+     * transition to TPR-based DMA protection instead of PMR-based; this is not
+     * yet supported by the code.
+     */
+    if ( os_sinit->vtd_pmr_lo_size == 0 )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_SIZE);
+
+    /* Check if regions overlap. Treat regions with no hole between as error. */
+    if ( os_sinit->vtd_pmr_hi_size != 0 &&
+         os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size )
+        txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
+
+    /* Check for size overflow. */
+    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <
+         os_sinit->vtd_pmr_hi_size )
+        txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+
+    /* All regions accessed by 32b code must be below 4G. */
+    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <=
+         0x100000000ULL )
+        check_high_pmr = true;
+
+    /*
+     * ACM checks that TXT heap and MLE memory is protected against DMA. We have
+     * to check if MBI and whole Xen memory is protected. The latter is done in
+     * case bootloader failed to set whole image as MLE and to make sure that
+     * both pre- and post-relocation code is protected.
+     */
+
+    /* Check if all of Xen before relocation is protected. */
+    if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+    /* Check if all of Xen after relocation is protected. */
+    if ( load_base_addr != tgt_base_addr &&
+         !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
+
+    /* If present, check that MBI is protected. */
+    if ( info->boot_params_base != 0 )
+    {
+        const multiboot2_fixed_t *mbi =
+            (const multiboot2_fixed_t *)(uintptr_t)info->boot_params_base;
+
+        if ( !is_in_pmr(os_sinit, info->boot_params_base, mbi->total_size,
+                        check_high_pmr) )
+            txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+    }
+
+    /* Check if TPM event log (if present) is protected. */
+    /*
+     * FIXME: currently commented out as GRUB allocates it in a hole between
+     * PMR and reserved RAM, due to 2MB resolution of PMR. There are no other
+     * easy-to-use DMA protection mechanisms that would allow to protect that
+     * part of memory. TPR (TXT DMA Protection Range) gives 1MB resolution, but
+     * it still wouldn't be enough.
+     *
+     * One possible solution would be for GRUB to allocate log at lower address,
+     * but this would further increase memory space fragmentation. Another
+     * option is to align PMR up instead of down, making PMR cover part of
+     * reserved region, but it is unclear what the consequences may be.
+     *
+     * In tboot this issue was resolved by reserving leftover chunks of memory
+     * in e820 and/or UEFI memory map. This is also a valid solution, but would
+     * require more changes to GRUB than the ones listed above, as event log is
+     * allocated much earlier than PMRs.
+     */
+    /*
+    if ( os_mle->evtlog_addr != 0 && os_mle->evtlog_size != 0 &&
+         !is_in_pmr(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
+                    check_high_pmr) )
+        txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
+    */
+}
+
 #endif /* !__ASSEMBLER__ */
 
 #endif /* X86_INTEL_TXT_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380641.1624402 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxL-0006by-Cu; Sun, 02 Aug 2026 13:10:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380641.1624402; Sun, 02 Aug 2026 13:10:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxL-0006bP-6z; Sun, 02 Aug 2026 13:10:19 +0000
Received: by outflank-mailman (input) for mailman id 1380641;
 Sun, 02 Aug 2026 13:10:18 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxK-0006RK-2p
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxJ-004d7k-Fw
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:17 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41b9-2eae-0a2a0a5409dd-0a2a450c80ea-0
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:17 +0200
Received: from [46.105.74.219] (helo=8.mo575.mail-out.ovh.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41b8-f479-0a2a450c0019-2e694adbc0eb-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:17 +0200
Received: from director5.ghost.mail-out.ovh.net (unknown [10.110.43.172])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCD45f2z5xnT
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:16 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-8bsrl (unknown [10.110.168.242])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id CDFA1100020;
 Sun,  2 Aug 2026 13:10:15 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.103])
 by ghost-submission-7d8d68f679-8bsrl with ESMTPSA
 id KMrpJ7dBb2ovoRcAxLjVHw
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-103G0052a2b29ed-d934-4988-9f63-b340be87dd25,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 11/23] xen/arch/x86: reserve TXT memory during Slaunch
Date: Sun,  2 Aug 2026 16:09:27 +0300
Message-ID: <e9c888f8356e967d77a43ba5459d5c0a95c65347.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4735535011450856892
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEO37Lm1soAj3J6HJwxZueJ91jNrKiCMD9VOxO+7S6oZcwX5ZhHy/rf+u1q3gsSFBR0MQ0G/W66mTSt5xumJoxY/EyDpxdVBT5aAA1fHupbW88f/IumzeClwwf3PGe5NCfIC4rAkaw9D49zl0L3FOqYw1yebY9XQZPEoEgqOhxU7iAITzoi4rSZJugXTxFrfgz5z3QYtYzrLSr0w464iDE2Jv+mfsQyDLbPqlC9XEGpFu9KBxFx07+KPXWsR6kr02Tgk2fJ3ulvjdiKijPJd2EPMcqID96OcOqj/uCF/V+6MYDFkW6NlVR5eWMFf+caoPBoCiQxHguJ/BWn2Nt+/d7LCTI8eZJ2PVPqJ7R8r1mCMC874y8TvUY4M3E5jUoLAVE92BrDMfCwD48x3utzTTcexOR9Bx9x4MyG58wNKd5h8O8hWBBDpa8KSJLI0wXoyZHNC6pc/ie7fI+F2C3sxjR+KTuQikp/85T6/dq1yLgeBQidpuPF2pETuFe98x0fjC/ChtI1BR+vPxkotFj4rn09yBLXYsTnJra1sfkfpZC4sVDaBw+bAtvAz3yLuk6LDSjyqziy3R1rxorXgxTV38bZnkZ4cktHL0GOqNKMo5QZddfKRMnJrujEzRCHegUa1ARbvEMYx1244SmrQErwTYH0WxDfg0O+0SFfGgWZWqnIwQ
DKIM-Signature: a=rsa-sha256; bh=iPbTspJ5mXNctv1oIOt0yeLZOD025ha+qDyeKfpyWXs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676216; v=1;
 b=I4i+fsJg33Yz99ooQCcPzl3BDXMYnweU+/4I/SsQhJ13lbeMvHXtnDVEgSP0JIWCwUCvVZDb
 7No1vFQL/kz2gsw8Nt5iuUun/kc/DCzaJWQ6+IjCtbQJsCqKRLz1k9Hop6ymCVIbmnpNo+8jmo8
 A0f2Cu+5vFyF1xJsH5/SDx8LzKa8LSrFncJ+ZrMg70ZkV4YXCAPIzTaLGVAe8IBJ0xVdFv9fEld
 7S5um5rFb4DbUSryB9S4A9s9HFHFct7JvO579pIV/BuiE7zMxNvNHfhPMn7HsCGr/3sVXCQR1Bd
 eW8bhkNik8f/VpJlRlGLP1XWmC5i6oWmCS6iwOAyBLkWQ==
X-purgate-ID: tlsNG-d25034/1785676217-774D7A5B-FE099550/0/0
X-purgate-type: clean
X-purgate-size: 16017

From: Kacper Stojek <kacper.stojek@3mdeb.com>

TXT heap, SINIT and TXT private space are marked as reserved or unused
in e820 to protect from unintended uses.

Signed-off-by: Kacper Stojek <kacper.stojek@3mdeb.com>
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: use CONFIG_SLAUNCH
    v4: use unsigned long constant in PREBUILT_MAP_LIMIT #define
    v4: add slaunch-tpm unit for TPM-related code specific to Slaunch (builds as normal and early code)
    v4: slaunch_get_slrt() now makes its first appearance in this commit
    v4: slaunch_find_log() is now defined in slaunch-tpm.c
    v4: improved signature and comment for slaunch_map_l2()
    v4: moved SPDX license comments to their own lines
    v4: reduced txt_heap_base and txt_heap_size from 64-bit to 32-bit
    v4: changed reserve_ram() to return bool and not take type (it's always the same) and skip already reserved memory
    v4: switch from "(from - to)" ranges to "[from, to)" in prints
    v4: verify that slaunch_map_l2() was passed a range below 4 GiB
    v4: move PREBUILT_MAP_LIMIT from asm/mm.h to asm/setup.h

 xen/arch/x86/Makefile                  |   2 +
 xen/arch/x86/include/asm/intel-txt.h   |   6 ++
 xen/arch/x86/include/asm/setup.h       |   3 +
 xen/arch/x86/include/asm/slaunch-tpm.h |  19 +++++
 xen/arch/x86/include/asm/slaunch.h     |  34 +++++++-
 xen/arch/x86/intel-txt.c               | 113 +++++++++++++++++++++++++
 xen/arch/x86/setup.c                   |  10 ++-
 xen/arch/x86/slaunch-tpm.c             |  36 ++++++++
 xen/arch/x86/slaunch.c                 | 105 ++++++++++++++++++++++-
 9 files changed, 323 insertions(+), 5 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/slaunch-tpm.h
 create mode 100644 xen/arch/x86/intel-txt.c
 create mode 100644 xen/arch/x86/slaunch-tpm.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a03f5a91ef..8dbb76a3a0 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -42,6 +42,7 @@ obj-y += i387.o
 obj-y += i8259.o
 obj-$(CONFIG_INDIRECT_THUNK) += indirect-thunk.o
 obj-$(CONFIG_RETURN_THUNK) += indirect-thunk.o
+obj-$(CONFIG_SLAUNCH) += intel-txt.o
 obj-$(CONFIG_PV) += ioport_emulate.o
 obj-y += io_apic.o
 obj-y += irq.o
@@ -61,6 +62,7 @@ obj-$(CONFIG_X86_PSR) += psr.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-$(CONFIG_SLAUNCH) += slaunch.o
+obj-$(CONFIG_SLAUNCH) += slaunch-tpm.o
 obj-y += smp.o
 obj-y += smpboot.o
 obj-y += spec_ctrl.o
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 66039dbeee..db6b0defd0 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -383,6 +383,12 @@ static inline void txt_verify_pmr_ranges(
     */
 }
 
+/* Prepares for accesses to TXT-specific memory. */
+void txt_map_mem_regions(void);
+
+/* Marks TXT-specific memory as used to avoid its corruption. */
+void txt_reserve_mem_regions(void);
+
 #endif /* !__ASSEMBLER__ */
 
 #endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index b01e83a8ed..431c0a26b5 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -4,6 +4,9 @@
 #include <xen/multiboot.h>
 #include <asm/numa.h>
 
+/* How much of the directmap is prebuilt at compile time. */
+#define PREBUILT_MAP_LIMIT (1UL << L2_PAGETABLE_SHIFT)
+
 extern const char __2M_text_start[], __2M_text_end[];
 extern const char __2M_rodata_start[], __2M_rodata_end[];
 extern char __2M_init_start[], __2M_init_end[];
diff --git a/xen/arch/x86/include/asm/slaunch-tpm.h b/xen/arch/x86/include/asm/slaunch-tpm.h
new file mode 100644
index 0000000000..68e9c8358a
--- /dev/null
+++ b/xen/arch/x86/include/asm/slaunch-tpm.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * TPM-related functions of Slaunch.  Can be used in both normal and early boot
+ * environments.
+ *
+ * Copyright (c) 2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#ifndef X86_SLAUNCH_TPM_H
+#define X86_SLAUNCH_TPM_H
+
+#include <xen/types.h>
+
+struct slr_table;
+
+void slaunch_find_log(const struct slr_table *slrt, paddr_t *evt_log,
+                      uint32_t *evt_log_size);
+
+#endif /* X86_SLAUNCH_TPM_H */
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 24ba164c0a..3df7174b4b 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -13,6 +13,8 @@
 #ifndef X86_SLAUNCH_H
 #define X86_SLAUNCH_H
 
+#include <xen/kernel.h>
+#include <xen/slr-table.h>
 #include <xen/types.h>
 
 struct slaunch_early_init_results
@@ -24,7 +26,37 @@ struct slaunch_early_init_results
 /* Indicates an active Secure Launch boot. */
 extern bool slaunch_active;
 
-/* Holds physical address of SLRT. */
+/*
+ * Holds physical address of SLRT.  Use slaunch_get_slrt() to access SLRT
+ * instead of mapping where this points to.
+ */
 extern uint32_t slaunch_slrt;
 
+/*
+ * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
+ */
+struct slr_table *slaunch_get_slrt(void);
+
+/*
+ * Prepares for accesses to essential data structures setup by boot environment.
+ */
+void slaunch_map_mem_regions(void);
+
+/* Marks regions of memory as used to avoid their corruption. */
+void slaunch_reserve_mem_regions(void);
+
+/*
+ * This helper function is used to map memory below 4 GiB using L2 page tables
+ * by aligning mapped regions to 2MB. This way page allocator (which at this
+ * point isn't yet initialized) isn't needed for creating new L1 mappings. The
+ * function also checks and skips memory already mapped by the prebuilt tables.
+ *
+ * There is no unmap_l2() because the function is meant to be used by the code
+ * that accesses DRTM-related memory soon after which Xen rebuilds memory maps,
+ * effectively dropping all existing mappings.
+ *
+ * Returns zero on success.
+ */
+int slaunch_map_l2(paddr_t paddr, size_t size);
+
 #endif /* X86_SLAUNCH_H */
diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
new file mode 100644
index 0000000000..4a42abf8df
--- /dev/null
+++ b/xen/arch/x86/intel-txt.c
@@ -0,0 +1,113 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Functions related to DRTM on Intel using its TXT (Trusted eXecution
+ * Technology).
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#include <xen/bug.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/types.h>
+#include <asm/e820.h>
+#include <asm/intel-txt.h>
+#include <asm/slaunch.h>
+
+/*
+ * Corresponding TXT registers seem to have 64-bits allocated for them, yet the
+ * actual values are 32-bit long, so using the latter.
+ */
+static uint32_t __initdata txt_heap_base, txt_heap_size;
+
+void __init txt_map_mem_regions(void)
+{
+    int rc;
+
+    rc = slaunch_map_l2(TXT_PRIV_CONFIG_REGS_BASE, TXT_CONFIG_SPACE_SIZE);
+    BUG_ON(rc != 0);
+
+    txt_heap_base = txt_read(TXTCR_HEAP_BASE);
+    BUG_ON(txt_heap_base == 0);
+
+    txt_heap_size = txt_read(TXTCR_HEAP_SIZE);
+    BUG_ON(txt_heap_size == 0);
+
+    rc = slaunch_map_l2(txt_heap_base, txt_heap_size);
+    BUG_ON(rc != 0);
+}
+
+/* Mark a RAM region as reserved if it isn't marked that way already. */
+static bool __init reserve_ram(struct e820map *map, uint64_t start,
+                               uint64_t end)
+{
+    unsigned int i;
+
+    for ( i = 0; i < map->nr_map; i++ )
+    {
+        uint64_t rs = map->map[i].addr;
+        uint64_t re = rs + map->map[i].size;
+
+        /* The entry includes the range. */
+        if ( start >= rs && end <= re )
+            break;
+
+        /* The entry intersects the range. */
+        if ( end > rs && start < re )
+        {
+            /* Fatal failure. */
+            return false;
+        }
+    }
+
+    /*
+     * If the range is not included by any entry and no entry intersects it,
+     * then it's not listed in the memory map.  Consider this case as a success
+     * since we're only preventing RAM from being used and unlisted range should
+     * not be used.
+     */
+    if ( i == map->nr_map )
+        return true;
+
+    /*
+     * e820_change_range_type() fails if the range is already marked with the
+     * desired type.  Don't consider it an error if firmware has done it for us.
+     */
+    if ( map->map[i].type == E820_RESERVED )
+        return true;
+
+    return e820_change_range_type(map, start, end, E820_RAM, E820_RESERVED);
+}
+
+void __init txt_reserve_mem_regions(void)
+{
+    bool ok;
+    uint32_t sinit_base, sinit_size;
+
+    /* TXT Heap */
+    BUG_ON(txt_heap_base == 0);
+    printk("SLAUNCH: reserving TXT heap range [%#x, %#x)\n", txt_heap_base,
+           txt_heap_base + txt_heap_size);
+    ok = reserve_ram(&e820_raw, txt_heap_base, txt_heap_base + txt_heap_size);
+    BUG_ON(!ok);
+
+    sinit_base = txt_read(TXTCR_SINIT_BASE);
+    BUG_ON(sinit_base == 0);
+
+    sinit_size = txt_read(TXTCR_SINIT_SIZE);
+    BUG_ON(sinit_size == 0);
+
+    /* SINIT */
+    printk("SLAUNCH: reserving SINIT memory range [%#x, %#x)\n", sinit_base,
+           sinit_base + sinit_size);
+    ok = reserve_ram(&e820_raw, sinit_base, sinit_base + sinit_size);
+    BUG_ON(!ok);
+
+    /* TXT Private Space */
+    printk("SLAUNCH: reserving private TXT registers range [%#x, %#x)\n",
+           TXT_PRIV_CONFIG_REGS_BASE,
+           TXT_PRIV_CONFIG_REGS_BASE + TXT_CONFIG_SPACE_SIZE);
+    ok = reserve_ram(&e820_raw, TXT_PRIV_CONFIG_REGS_BASE,
+                     TXT_PRIV_CONFIG_REGS_BASE + TXT_CONFIG_SPACE_SIZE);
+    BUG_ON(!ok);
+}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7d71fea6c0..5494fa1621 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -50,6 +50,7 @@
 #include <asm/pv/domain.h>
 #include <asm/setup.h>
 #include <asm/shstk.h>
+#include <asm/slaunch.h>
 #include <asm/smp.h>
 #include <asm/spec_ctrl.h>
 #include <asm/stubs.h>
@@ -1128,9 +1129,6 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     return d;
 }
 
-/* How much of the directmap is prebuilt at compile time. */
-#define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
-
 void asmlinkage __init noreturn __start_xen(void)
 {
     const char *memmap_type = NULL;
@@ -1472,6 +1470,12 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
+    if ( slaunch_active )
+    {
+        slaunch_map_mem_regions();
+        slaunch_reserve_mem_regions();
+    }
+
     /* Sanitise the raw E820 map to produce a final clean version. */
     max_page = raw_max_page = init_e820(memmap_type, &e820_raw);
 
diff --git a/xen/arch/x86/slaunch-tpm.c b/xen/arch/x86/slaunch-tpm.c
new file mode 100644
index 0000000000..f59170594d
--- /dev/null
+++ b/xen/arch/x86/slaunch-tpm.c
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Slaunch functions related to TPM.
+ *
+ * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
+ */
+
+#include <xen/macros.h>
+#include <xen/slr-table.h>
+#include <xen/types.h>
+
+void slaunch_find_log(const struct slr_table *slrt, paddr_t *evt_log,
+                      uint32_t *evt_log_size)
+{
+    const struct slr_entry_hdr *hdr;
+
+    hdr = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_LOG_INFO);
+    if ( hdr != NULL )
+    {
+        const struct slr_entry_log_info *log_info;
+        log_info = container_of(hdr, const struct slr_entry_log_info, hdr);
+
+        *evt_log = (uintptr_t)_p(log_info->addr);
+        *evt_log_size = log_info->size;
+    }
+    else
+    {
+        /*
+         * Event log is used to verify measurements, but values of PCRs is the
+         * real authoritative source of information, so keep going if there is
+         * no log as secrets may still be correctly unsealed by TPM.
+         */
+        *evt_log = 0;
+        *evt_log_size = 0;
+    }
+}
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index acf751804f..ba1ba61c47 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -7,11 +7,17 @@
 
 #include <xen/compiler.h>
 #include <xen/init.h>
-#include <xen/inttypes.h>
 #include <xen/macros.h>
+#include <xen/mm.h>
 #include <xen/sections.h>
+#include <xen/types.h>
 
+#include <asm/e820.h>
+#include <asm/intel-txt.h>
+#include <asm/page.h>
+#include <asm/setup.h>
 #include <asm/slaunch.h>
+#include <asm/slaunch-tpm.h>
 
 /*
  * These variables are assigned to by the code near Xen's entry point.
@@ -30,3 +36,100 @@ static void __maybe_unused compile_time_checks(void)
 {
     BUILD_BUG_ON(sizeof(slaunch_active) != 1);
 }
+
+struct slr_table *__init slaunch_get_slrt(void)
+{
+    static struct slr_table *__initdata slrt;
+
+    if ( slrt == NULL )
+    {
+        int rc;
+
+        slrt = __va(slaunch_slrt);
+
+        rc = slaunch_map_l2(slaunch_slrt, PAGE_SIZE);
+        BUG_ON(rc != 0);
+
+        if ( slrt->magic != SLR_TABLE_MAGIC )
+            panic("SLRT has invalid magic value: %#x!\n", slrt->magic);
+        /* XXX: are newer revisions allowed? */
+        if ( slrt->revision != SLR_TABLE_REVISION )
+            panic("SLRT is of unsupported revision: %#x!\n", slrt->revision);
+        if ( slrt->architecture != SLR_INTEL_TXT )
+            panic("SLRT is for unexpected architecture: %#x!\n",
+                  slrt->architecture);
+        if ( slrt->size > slrt->max_size )
+            panic("SLRT is larger than its max size: %#x > %#x!\n",
+                  slrt->size, slrt->max_size);
+
+        if ( slrt->size > PAGE_SIZE )
+        {
+            rc = slaunch_map_l2(slaunch_slrt, slrt->size);
+            BUG_ON(rc != 0);
+        }
+    }
+
+    return slrt;
+}
+
+void __init slaunch_map_mem_regions(void)
+{
+    int rc;
+    paddr_t evt_log_addr;
+    uint32_t evt_log_size;
+
+    /* Vendor-specific part. */
+    txt_map_mem_regions();
+
+    slaunch_find_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    if ( evt_log_addr != 0 )
+    {
+        rc = slaunch_map_l2(evt_log_addr, evt_log_size);
+        BUG_ON(rc != 0);
+    }
+}
+
+void __init slaunch_reserve_mem_regions(void)
+{
+    paddr_t evt_log_addr;
+    uint32_t evt_log_size;
+
+    /* Vendor-specific part. */
+    txt_reserve_mem_regions();
+
+    slaunch_find_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
+    if ( evt_log_addr != 0 )
+    {
+        int ok;
+
+        printk("SLAUNCH: reserving event log [%#lx, %#lx)\n", evt_log_addr,
+               evt_log_addr + evt_log_size);
+        ok = reserve_e820_ram(&e820_raw, evt_log_addr,
+                              evt_log_addr + evt_log_size);
+        BUG_ON(!ok);
+    }
+}
+
+int __init slaunch_map_l2(paddr_t paddr, size_t size)
+{
+    unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
+    unsigned long pages = ((paddr + size) - aligned_paddr);
+
+    pages = ROUNDUP(pages, 1ULL << L2_PAGETABLE_SHIFT) >> PAGE_SHIFT;
+
+    BUG_ON(paddr >= (1ULL << 32));
+    BUG_ON(paddr + pages * PAGE_SIZE >= (1ULL << 32));
+
+    if ( aligned_paddr + pages * PAGE_SIZE <= PREBUILT_MAP_LIMIT )
+        return 0;
+
+    if ( aligned_paddr < PREBUILT_MAP_LIMIT )
+    {
+        pages -= (PREBUILT_MAP_LIMIT - aligned_paddr) >> PAGE_SHIFT;
+        aligned_paddr = PREBUILT_MAP_LIMIT;
+    }
+
+    return map_pages_to_xen((uintptr_t)__va(aligned_paddr),
+                            maddr_to_mfn(aligned_paddr),
+                            pages, PAGE_HYPERVISOR);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380649.1624412 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxO-00073e-Ls; Sun, 02 Aug 2026 13:10:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380649.1624412; Sun, 02 Aug 2026 13:10:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxO-00072q-Gf; Sun, 02 Aug 2026 13:10:22 +0000
Received: by outflank-mailman (input) for mailman id 1380649;
 Sun, 02 Aug 2026 13:10:21 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxN-0006yB-3h
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxM-001lF1-Gh
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:20 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41a9-e002-0a2a0a5209dd-0a2a4505e158-16
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:20 +0200
Received: from [87.98.181.248] (helo=5.mo560.mail-out.ovh.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41bb-4cb1-0a2a45050019-5762b5f8891f-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:20 +0200
Received: from director8.ghost.mail-out.ovh.net (unknown [10.110.43.172])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCH5LSBzB5rZ
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:19 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-mzsh5 (unknown [10.110.113.68])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id E6D71C0120;
 Sun,  2 Aug 2026 13:10:18 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.105])
 by ghost-submission-7d8d68f679-mzsh5 with ESMTPSA
 id fXhJKLpBb2pj5QUAuSgMJA
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-105G0066ba2b957-759b-4dab-a1b9-b171d58bcbdf,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 12/23] x86/slaunch: restore boot MTRRs after Intel TXT DRTM
Date: Sun,  2 Aug 2026 16:09:28 +0300
Message-ID: <c0fa37704bd04e6e2a1ac4351e95ee3db0245de7.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4736379434136577468
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEO37Lm1soAj3J6HJwxZueJ91jNrKiCMD9VOxO+7S6oZcwX5ZhHy/rf+u1q3gsSFBR0MQ0G/W66mTSt5xumJoxY/EyDpxdVBT5aAA1fHupbW88f/IumzeClwwf3PGe5NCfIC4rAkaw9D49zl0L3FOqYw1yebY9XQZPEoEgqOhxU7iAITzoi4rSZJugXTxFrfgz5z3QYtYzrLSr0w464iDE2Jv+mfsQyDLbPqlC9XEGpFu9KBxFx07+KPXWsR6kr02Tgk2fJ3ulvjdiKijPJd2EPMcqID96OcOqj/uCF/V+6MYDFkW6NlVR5eWMFf+caoPBoCiQxHguJ/BWn2Nt+/d7LjfFvrcZF/8u8Q0n3PRHV4r3WKIwqRJzxJHPFSQxIKbl3XKNnFvBMXLOpuFHhZH23vljAyKNWXhmDAuNjJx+48Xd79wb1kFhk4s4YAFiFF/CVJN2Zsd6Gpz9N2JkkrsrlXnt3OHFvS8MHgPe6pYWDNjrhVTKEFh1bdt4tWvVVIZ+8woEhh6YA1yerfSR6yGkZEMy4A2UTcafcpvD2uDfNKO9Y5/nle0Uw/V9ra7AnWQwHcMv3n76VKKlBUNHLO4sKlPa1oupiaIcxzn7yOQZWEygxdQF5fsa33PPA/dvi89nZzUt4xXZ20devYMkWwQoLGOCH9fpurC4Yr9x5I7VD7w
DKIM-Signature: a=rsa-sha256; bh=+7PqKj5rgs6xrE/At11/PBfNJMiWB0u0NPN3/ZI5tEc=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676219; v=1;
 b=ZiBwsSJKedYzeY7PbMzMY/56bIkaFnx4nGmP5x7pJ99HTIhHDEfiJxpXvWPTdojoG1f8STrF
 6r9KQx0Un0fxHb3PIfDmsI65gi9VAYMbHAyUuK2lrhAfO+WcSea57kcYl/CB1CoQpzvXwkkahWM
 kAAIEhElCVL3uvBsZc+a7rfX0VRKDbRiWrN1oCS5HA59+b1ehsp8GQ2fnp0Cq3yMUYmGQdz5pG4
 KHsZ5RTDOiIFf63ZHzujLfbL5bn5UZzj9SCfzRPwDBUcTqcmVsnkCVkP2lo25Hp3U4fvSQcvg7K
 m9RkXEjA4AgayF4WoQoORDnXUk9oln9P4lr2gLWhjrdyg==
X-purgate-ID: tlsNG-c201ff/1785676220-F74BC2A1-6258F757/0/0
X-purgate-type: clean
X-purgate-size: 8515

From: Krystian Hebel <krystian.hebel@3mdeb.com>

In preparation for TXT SENTER call, GRUB had to modify MTRR settings
to be UC for everything except SINIT ACM. Old values are restored
from SLRT where they were saved by the bootloader.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: now this commit makes two functions of mtrr/generic.c public
    v4: take CONFIG_SLAUNCH into account
    v4: restore MTRRs earlier: move from mtrr_top_of_ram() to machine_specific_memory_setup()
    v4: renamed parameter of txt_restore_mtrrs(): e820_verbose => verbose
    v4: don't use rdmsrl() and wrmsrl()
    v4: extract part of an integer consistently (`mtrr_cap` in txt_restore_mtrrs(), was a mix of `(uint8_t)` cast and `& 0xff`)
    v4: use container_of()
    v4: manage MTRR count in txt_restore_mtrrs() better (separate variable, no weird ?: operator)

 xen/arch/x86/cpu/mtrr/generic.c      |  9 +--
 xen/arch/x86/e820.c                  |  5 ++
 xen/arch/x86/include/asm/intel-txt.h |  3 +
 xen/arch/x86/include/asm/mtrr.h      |  8 +++
 xen/arch/x86/include/asm/slaunch.h   |  8 +++
 xen/arch/x86/intel-txt.c             | 84 ++++++++++++++++++++++++++++
 6 files changed, 110 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 86eb0f405b..c179935dd3 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -14,11 +14,6 @@
 #include <asm/cpufeature.h>
 #include "mtrr.h"
 
-struct mtrr_pausing_state {
-	bool pge;
-	uint64_t def_type;
-};
-
 static const struct fixed_range_block {
 	uint32_t base_msr;   /* start address of an MTRR block */
 	unsigned int ranges; /* number of MTRRs in this block  */
@@ -440,7 +435,7 @@ static DEFINE_SPINLOCK(set_atomicity_lock);
  * has been called.
  */
 
-static void mtrr_pause_caching(struct mtrr_pausing_state *state)
+void mtrr_pause_caching(struct mtrr_pausing_state *state)
 {
 	unsigned long cr4;
 
@@ -481,7 +476,7 @@ static void mtrr_pause_caching(struct mtrr_pausing_state *state)
 	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);
 }
 
-static void mtrr_resume_caching(struct mtrr_pausing_state state)
+void mtrr_resume_caching(struct mtrr_pausing_state state)
 {
 	/* Intel (P6) standard MTRRs */
 	mtrr_wrmsr(MSR_MTRRdefType, state.def_type);
diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 872208ab37..c63b0b12cc 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -11,6 +11,8 @@
 #include <asm/mtrr.h>
 #include <asm/msr.h>
 #include <asm/guest.h>
+#include <asm/intel-txt.h>
+#include <asm/slaunch.h>
 
 /*
  * opt_mem: Limit maximum address of physical RAM.
@@ -499,6 +501,9 @@ static void __init machine_specific_memory_setup(struct e820map *raw)
     uint64_t top_of_ram, size;
     unsigned int i;
 
+    if ( slaunch_active )
+        txt_restore_mtrrs(e820_verbose);
+
     sanitize_e820_map(raw->map, &raw->nr_map);
     copy_e820_map(raw->map, raw->nr_map);
 
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index db6b0defd0..406929fac2 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -389,6 +389,9 @@ void txt_map_mem_regions(void);
 /* Marks TXT-specific memory as used to avoid its corruption. */
 void txt_reserve_mem_regions(void);
 
+/* Restores original MTRR values saved by a bootloader before starting DRTM. */
+void txt_restore_mtrrs(bool verbose);
+
 #endif /* !__ASSEMBLER__ */
 
 #endif /* X86_INTEL_TXT_H */
diff --git a/xen/arch/x86/include/asm/mtrr.h b/xen/arch/x86/include/asm/mtrr.h
index 3a5b4f5b6e..bf82af8c47 100644
--- a/xen/arch/x86/include/asm/mtrr.h
+++ b/xen/arch/x86/include/asm/mtrr.h
@@ -63,6 +63,14 @@ extern uint8_t pat_type_2_pte_flags(uint8_t pat_type);
 extern void mtrr_aps_sync_begin(void);
 extern void mtrr_aps_sync_end(void);
 
+struct mtrr_pausing_state {
+	bool pge;
+	uint64_t def_type;
+};
+
+extern void mtrr_pause_caching(struct mtrr_pausing_state *state);
+extern void mtrr_resume_caching(struct mtrr_pausing_state state);
+
 extern bool mtrr_var_range_msr_set(struct domain *d, struct mtrr_state *m,
                                    uint32_t msr, uint64_t msr_content);
 extern bool mtrr_fix_range_msr_set(struct domain *d, struct mtrr_state *m,
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 3df7174b4b..459fc83388 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -23,8 +23,16 @@ struct slaunch_early_init_results
     uint32_t slrt_pa;
 } __packed;
 
+#ifdef CONFIG_SLAUNCH
 /* Indicates an active Secure Launch boot. */
 extern bool slaunch_active;
+#else
+/*
+ * This avoids `#ifdef CONFIG_SLAUNCH` around `if ( slaunch_active )` thanks to
+ * dead code elimination.
+ */
+static bool slaunch_active = false;
+#endif
 
 /*
  * Holds physical address of SLRT.  Use slaunch_get_slrt() to access SLRT
diff --git a/xen/arch/x86/intel-txt.c b/xen/arch/x86/intel-txt.c
index 4a42abf8df..e0344d3421 100644
--- a/xen/arch/x86/intel-txt.c
+++ b/xen/arch/x86/intel-txt.c
@@ -8,10 +8,13 @@
 
 #include <xen/bug.h>
 #include <xen/init.h>
+#include <xen/kernel.h>
 #include <xen/lib.h>
 #include <xen/types.h>
 #include <asm/e820.h>
 #include <asm/intel-txt.h>
+#include <asm/msr.h>
+#include <asm/mtrr.h>
 #include <asm/slaunch.h>
 
 /*
@@ -111,3 +114,84 @@ void __init txt_reserve_mem_regions(void)
                      TXT_PRIV_CONFIG_REGS_BASE + TXT_CONFIG_SPACE_SIZE);
     BUG_ON(!ok);
 }
+
+void __init txt_restore_mtrrs(bool verbose)
+{
+    const struct slr_entry_hdr *entry;
+    const struct slr_entry_intel_info *intel_info;
+    uint64_t mtrr_cap, mtrr_def, base, mask;
+    unsigned int i;
+    unsigned int vcnt;
+    uint64_t def_type;
+    struct mtrr_pausing_state pausing_state;
+
+    mtrr_cap = rdmsr(MSR_MTRRcap);
+    mtrr_def = rdmsr(MSR_MTRRdefType);
+
+    vcnt = mtrr_cap & 0xFF;
+
+    if ( verbose )
+    {
+        printk("MTRRs set previously for SINIT ACM:\n");
+        printk(" MTRR cap: %"PRIx64" type: %"PRIx64"\n", mtrr_cap, mtrr_def);
+
+        for ( i = 0; i < vcnt; i++ )
+        {
+            base = rdmsr(MSR_IA32_MTRR_PHYSBASE(i));
+            mask = rdmsr(MSR_IA32_MTRR_PHYSMASK(i));
+
+            printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
+                   i, base, mask);
+        }
+    }
+
+    entry =
+        slr_next_entry_by_tag(slaunch_get_slrt(), NULL, SLR_ENTRY_INTEL_INFO);
+    intel_info = container_of(entry, const struct slr_entry_intel_info, hdr);
+
+    if ( vcnt != intel_info->saved_bsp_mtrrs.mtrr_vcnt )
+    {
+        printk("Bootloader saved %ld MTRR values, but there should be %d\n",
+               intel_info->saved_bsp_mtrrs.mtrr_vcnt, vcnt);
+        /* Choose the smaller one to be on the safe side. */
+        if ( intel_info->saved_bsp_mtrrs.mtrr_vcnt < vcnt )
+            vcnt = intel_info->saved_bsp_mtrrs.mtrr_vcnt;
+    }
+
+    def_type = intel_info->saved_bsp_mtrrs.default_mem_type;
+    mtrr_pause_caching(&pausing_state);
+
+    for ( i = 0; i < vcnt; i++ )
+    {
+        base = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physbase;
+        mask = intel_info->saved_bsp_mtrrs.mtrr_pair[i].mtrr_physmask;
+        wrmsr(MSR_IA32_MTRR_PHYSBASE(i), base);
+        wrmsr(MSR_IA32_MTRR_PHYSMASK(i), mask);
+    }
+
+    pausing_state.def_type = def_type;
+    mtrr_resume_caching(pausing_state);
+
+    if ( verbose )
+    {
+        printk("Restored MTRRs:\n");
+
+        /*
+         * If MTRRs are not enabled or WB is not the default, MTRRs won't be
+         * printed.
+         */
+        if ( !test_bit(11, &def_type) || (def_type & 0x7) == X86_MT_WB )
+        {
+            for ( i = 0; i < vcnt; i++ )
+            {
+                base = rdmsr(MSR_IA32_MTRR_PHYSBASE(i));
+                mask = rdmsr(MSR_IA32_MTRR_PHYSMASK(i));
+                printk(" MTRR[%d]: base %"PRIx64" mask %"PRIx64"\n",
+                       i, base, mask);
+            }
+        }
+    }
+
+    /* Restore IA32_MISC_ENABLES */
+    wrmsr(MSR_IA32_MISC_ENABLE, intel_info->saved_misc_enable_msr);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380655.1624421 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxS-0007a7-52; Sun, 02 Aug 2026 13:10:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380655.1624421; Sun, 02 Aug 2026 13:10:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxR-0007Zy-Vt; Sun, 02 Aug 2026 13:10:25 +0000
Received: by outflank-mailman (input) for mailman id 1380655;
 Sun, 02 Aug 2026 13:10:24 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxQ-0007Lq-1f
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxP-001lF1-Ew
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:23 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4178-e002-0a2a0a5209dd-0a2a450adcca-26
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:23 +0200
Received: from [46.105.63.121] (helo=1.mo560.mail-out.ovh.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41be-f2d2-0a2a450a0019-2e693f79a513-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:23 +0200
Received: from director5.ghost.mail-out.ovh.net (unknown [10.110.58.120])
 by mo560.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCL66r7zB5rw
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:22 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-m4frt (unknown [10.111.174.155])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id EE3FC100020;
 Sun,  2 Aug 2026 13:10:21 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.105])
 by ghost-submission-7d8d68f679-m4frt with ESMTPSA
 id +ukvK71Bb2oAsRcAXQcPeQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-105G0063c3aa204-ba72-4722-ade4-19b5dcf0e5f5,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 13/23] x86/slaunch: measure MBI into TPM
Date: Sun,  2 Aug 2026 16:09:29 +0300
Message-ID: <8e971b5b87d6b5dd7aebba55a40ddaeed7b97616.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4737223860187702716
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTErXTMJAFd1A/dXmS31doF3eHiFwFavtbE0IdxSAxcjBkbm/Y2r8C0ugmNxHgh0ttjc9HcWB48DtmHsboYn+R8rGouoQtvWBvuW7UoEIxsUWbq/tHAG5l0RfFjNSyhC5/+eLgR0uRIXbClVnnLU0J/e2MH+H41gFQHMN7aHv5oF4XCxU6iBwYAbzZv3Yhh++GCTcK0XOcSHoKOpYkiLjzaWT2sDXaneeSXeAAfPIRWbR3tUvr9IWTEkcXdO9/v8flsgALJWAnTuyhJyR7xa7rElw4l9ZKZPp4F7IlSUp4UkO78BMUlmU3YvvPg7A/cDjWsr7oy1auF5nv72TyzhOj1kihXXkuJHUxuhH70tfkuXm5adpj7kYIq40ucJWy4eC8j4fd5KD8Rjrj+faMOgHhQfHMXHXc/D+vxjCPoiXhdVJyUP1hH3j+BXHyKw9Tm0xzuxJs/dEVF0AWE6Y8pzOWujbxug4nS1eBH11qnIpTz4s9R8aGzvTzhCgv94NwckC+ebxuOt/l2btFhWFQHAoiqdtUsXR/i/4pBjb6y9MWckygLMxPIOgsvDY5lH16jia9YFKUGoEIfy7eaWSjXfgvkVWqQa/ykLH0W2krnjwb2FiHZynPwGWkL/fRdSDP/svwT+IR+/3WdSNXTDQirQHtqd04KTIx+HNfdXzKcP7YYOJA
DKIM-Signature: a=rsa-sha256; bh=NTPb66lzSKmerltG0bBqdXZxKAyljMiz3zhpakFzmRs=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676222; v=1;
 b=Fj/IJVW2RxfGpPoBj7h4FcE+jcamEVbzMgjD/1vmGj7QEjOOJpDXyz3s7Ap8y0V5pHVqNkUL
 i/5vI/j3deL8KfzJRVwmfjqMG0I6y6qRc2nDZsDCwZ9Ig63GJwWTxb6X/d1Qpd3yspWcnnmig5M
 +fxKrqhGE/x8rcn/gRAtyt47+nvFCUyrIomu2EDu8g9GfRJmJJMzE80hs+pFl2n3o45VbluBr9Q
 uvnU5dq04MW7WBUZqERGAPUs2FFw7OfTAGA6ssfG30NCWPObMDQg9FC8czVLq/+33qIB05qemH6
 SYa6p36J/gNsIiNxe2vSOqttchdEH8UlAtEnofT4LfVOA==
X-purgate-ID: tlsNG-4011c0/1785676223-4ABD8CFC-00CF7C25/0/0
X-purgate-type: clean
X-purgate-size: 8972

From: Krystian Hebel <krystian.hebel@3mdeb.com>

Make slaunch-tpm.c compile in early boot environment use it to measure
MBI in early 32b code without paging (gets triggered from head.S).

The fact of the measurement is not yet stored anywhere as there is no
code for TPM event log discovery and modification.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: was part of "x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)"
    v4: tpm_extend_mbi => slaunch_measure_mbi
    v4: doesn't touch tpm.c, uses slaunch-tpm.c instead
    v4: use `const multiboot2_fixed_t *` instead of `uint32_t *` for MBI

 xen/arch/x86/boot/Makefile             |   7 +-
 xen/arch/x86/boot/head.S               |   5 ++
 xen/arch/x86/include/asm/slaunch-tpm.h |   7 ++
 xen/arch/x86/include/asm/slaunch.h     |  14 ++++
 xen/arch/x86/slaunch-tpm.c             | 112 +++++++++++++++++++++++++
 xen/arch/x86/slaunch.c                 |   4 +
 6 files changed, 148 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 02f690d34a..b31c96be18 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -7,6 +7,7 @@ obj32 += reloc.32.o
 obj32 += reloc-trampoline.32.o
 ifeq ($(CONFIG_SLAUNCH),y)
 obj32 += slaunch-early.32.o
+obj32 += slaunch-tpm-early.32.o
 endif
 obj32 += tpm-early.32.o
 
@@ -14,7 +15,7 @@ obj64 := reloc-trampoline.o
 
 exports := cmdline_parse_early,reloc,reloc_trampoline32
 ifeq ($(CONFIG_SLAUNCH),y)
-exports := $(exports),slaunch_early_init
+exports := $(exports),slaunch_early_init,slaunch_measure_mbi
 endif
 
 nocov-y   += $(obj32) $(obj64)
@@ -39,6 +40,10 @@ $(obj)/%.32.o: $(src)/%.c FORCE
 
 $(obj)/slaunch-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
 
+$(obj)/slaunch-tpm-early.32.o: XEN_CFLAGS += -D__EARLY_SLAUNCH__
+$(obj)/slaunch-tpm-early.32.o: $(src)/../slaunch-tpm.c FORCE
+	$(call if_changed_rule,cc_o_c)
+
 $(obj)/tpm-early.32.o: XEN_CFLAGS += -D__EARLY_TPM__
 $(obj)/tpm-early.32.o: $(src)/../tpm.c FORCE
 	$(call if_changed_rule,cc_o_c)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 700d1d850e..2c1a0f6306 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -539,6 +539,11 @@ __start:
         pop     sym_esi(slaunch_slrt) /* save physical address of SLRT for C
                                          code */
 
+        mov     sym_esi(slaunch_slrt), %edx /* physical SLRT address */
+        mov     %ebx, %eax                  /* physical MBI address */
+        /* slaunch_measure_mbi(mbi/eax, slrt/edx) using fastcall. */
+        call    slaunch_measure_mbi
+
         /* Move magic number expected by Multiboot 2 to EAX and fall through. */
         movl    $MULTIBOOT2_BOOTLOADER_MAGIC, %eax
 #endif
diff --git a/xen/arch/x86/include/asm/slaunch-tpm.h b/xen/arch/x86/include/asm/slaunch-tpm.h
index 68e9c8358a..79154f505b 100644
--- a/xen/arch/x86/include/asm/slaunch-tpm.h
+++ b/xen/arch/x86/include/asm/slaunch-tpm.h
@@ -16,4 +16,11 @@ struct slr_table;
 void slaunch_find_log(const struct slr_table *slrt, paddr_t *evt_log,
                       uint32_t *evt_log_size);
 
+/*
+ * Log data is optional (pass in NULL and/or zero size to indicate its absence).
+ */
+void slaunch_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
+                         unsigned int size, uint32_t type,
+                         const uint8_t *log_data, unsigned int log_data_size);
+
 #endif /* X86_SLAUNCH_TPM_H */
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 459fc83388..65aab01f04 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -17,6 +17,20 @@
 #include <xen/slr-table.h>
 #include <xen/types.h>
 
+#define DRTM_LOC                   2
+#define DRTM_CODE_PCR              17
+#define DRTM_DATA_PCR              18
+
+/*
+ * Secure Launch event log entry types. The TXT specification defines the base
+ * event value as 0x400 for DRTM values, use it regardless of the DRTM for
+ * consistency.
+ */
+#define DLE_EVTYPE_BASE            0x400
+#define DLE_EVTYPE_SLAUNCH         (DLE_EVTYPE_BASE + 0x102)
+#define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
+#define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
+
 struct slaunch_early_init_results
 {
     uint32_t mbi_pa;
diff --git a/xen/arch/x86/slaunch-tpm.c b/xen/arch/x86/slaunch-tpm.c
index f59170594d..21dec67dca 100644
--- a/xen/arch/x86/slaunch-tpm.c
+++ b/xen/arch/x86/slaunch-tpm.c
@@ -2,13 +2,71 @@
 /*
  * Slaunch functions related to TPM.
  *
+ * This file is built twice:
+ *  1. For early 32b mode without paging when it also provides
+ *     slaunch_measure_mbi() to be called from assembly.
+ *  2. For 64b code.
+ *
  * Copyright (c) 2022-2026 3mdeb Sp. z o.o.  All rights reserved.
  */
 
+#include <xen/compiler.h>
+#include <xen/lib.h>
 #include <xen/macros.h>
+#include <xen/multiboot2.h>
+#include <xen/sha1.h>
+#include <xen/sha2.h>
 #include <xen/slr-table.h>
 #include <xen/types.h>
 
+#include <asm/intel-txt.h>
+#include <asm/slaunch.h>
+#include <asm/slaunch-tpm.h>
+#include <asm/tpm.h>
+#include <asm/tpm2.h>
+
+#ifdef __EARLY_SLAUNCH__
+
+#ifdef __va
+#error "__va defined in non-paged mode!"
+#endif
+
+#define __va(x)  _p(x)
+
+static uint32_t slrt_location;
+
+/*
+ * The code is being compiled as a standalone binary without linking to any
+ * other part of Xen.  Providing implementation of builtin functions in this
+ * case is necessary if compiler chooses to not use an inline builtin.
+ */
+void *(memset)(void *s, int c, size_t n)
+{
+    uint8_t *d = s;
+
+    while ( n-- )
+        *d++ = c;
+
+    return s;
+}
+
+struct slr_table *slaunch_get_slrt(void)
+{
+    return _p(slrt_location);
+}
+
+void asmlinkage slaunch_measure_mbi(const multiboot2_fixed_t *mbi,
+                                    uint32_t slrt_pa)
+{
+    /* Need this to implement slaunch_get_slrt() for early TPM code. */
+    slrt_location = slrt_pa;
+
+    slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (const uint8_t *)mbi,
+                        mbi->total_size, DLE_EVTYPE_SLAUNCH, NULL, 0);
+}
+
+#endif  /* __EARLY_SLAUNCH__ */
+
 void slaunch_find_log(const struct slr_table *slrt, paddr_t *evt_log,
                       uint32_t *evt_log_size)
 {
@@ -34,3 +92,57 @@ void slaunch_find_log(const struct slr_table *slrt, paddr_t *evt_log,
         *evt_log_size = 0;
     }
 }
+
+void slaunch_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
+                         unsigned int size, uint32_t type,
+                         const uint8_t *log_data, unsigned int log_data_size)
+{
+    paddr_t evt_log_paddr;
+    uint32_t evt_log_size;
+    struct tpm_log_hashes log_hashes;
+    uint8_t discarded_digests[SHA2_256_DIGEST_SIZE];
+    uint32_t rc;
+
+    slaunch_find_log(slaunch_get_slrt(), &evt_log_paddr, &evt_log_size);
+
+    if ( tpm_is_tpm1() )
+    {
+        log_hashes = (struct tpm_log_hashes) {
+            .count = 1,
+            .hashes = {
+                {
+                    .alg = TPM_ALG_SHA1,
+                    .size = SHA1_DIGEST_SIZE,
+                    .data = discarded_digests,
+                },
+            },
+        };
+    }
+    else
+    {
+        log_hashes = (struct tpm_log_hashes) {
+            .count = 2,
+            .hashes = {
+                {
+                    .alg = TPM_ALG_SHA1,
+                    .size = SHA1_DIGEST_SIZE,
+                    .data = discarded_digests,
+                },
+                {
+                    .alg = TPM_ALG_SHA256,
+                    .size = SHA2_256_DIGEST_SIZE,
+                    .data = discarded_digests,
+                },
+            },
+        };
+    }
+
+    rc = tpm_hash_extend(loc, pcr, buf, size, &log_hashes);
+    if (rc != 0)
+    {
+#ifndef __EARLY_SLAUNCH__
+        printk(XENLOG_ERR "Extending PCR-%u failed with an error: 0x%08x\n",
+               pcr, rc);
+#endif
+    }
+}
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index ba1ba61c47..83dce3d57d 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -18,6 +18,7 @@
 #include <asm/setup.h>
 #include <asm/slaunch.h>
 #include <asm/slaunch-tpm.h>
+#include <asm/tpm.h>
 
 /*
  * These variables are assigned to by the code near Xen's entry point.
@@ -78,6 +79,9 @@ void __init slaunch_map_mem_regions(void)
     paddr_t evt_log_addr;
     uint32_t evt_log_size;
 
+    rc = slaunch_map_l2(TPM_MMIO_BASE, TPM_MMIO_SIZE);
+    BUG_ON(rc != 0);
+
     /* Vendor-specific part. */
     txt_map_mem_regions();
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380663.1624430 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxU-0007yK-D3; Sun, 02 Aug 2026 13:10:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380663.1624430; Sun, 02 Aug 2026 13:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxU-0007y8-9V; Sun, 02 Aug 2026 13:10:28 +0000
Received: by outflank-mailman (input) for mailman id 1380663;
 Sun, 02 Aug 2026 13:10:27 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxS-0007he-S4
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxS-001lF1-90
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:26 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4184-e002-0a2a0a5209dd-0a2a4509b098-38
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:26 +0200
Received: from [87.98.165.232] (helo=10.mo561.mail-out.ovh.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41c1-be1a-0a2a45090019-5762a5e89cdd-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:25 +0200
Received: from director1.ghost.mail-out.ovh.net (unknown [10.109.231.50])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCP3tlTz5xsS
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:25 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-zxq5n (unknown [10.110.96.50])
 by director1.ghost.mail-out.ovh.net (Postfix) with ESMTPS id DC9B3C0F9B;
 Sun,  2 Aug 2026 13:10:24 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-7d8d68f679-zxq5n with ESMTPSA
 id ABhuKMBBb2rQIhgAgBBa5Q
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-106R0065f936387-df7e-49bc-bd38-eb12fb54b197,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 14/23] x86/slaunch: update TPM event log (TPM1.2 or TPM2.0)
Date: Sun,  2 Aug 2026 16:09:30 +0300
Message-ID: <76a5865c29f948838db879e60d3c0bc3dfc58de1.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4738068283416716732
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEO37Lm1soAj3J6HJwxZueJ91jNrKiCMD9VOxO+7S6oZcwX5ZhHy/rf+u1q3gsSFBR0MQ0G/W66mTSt5xumJoxY/EyDpxdVBT5aAA1fHupbW88f/IumzeClwwf3PGe5NCfIC4rAkaw9D49zl0L3FOqYw1yebY9XQZPEoEgqOhxU7iAITzoi4rSZJugXTxFrfgz5z3QYtYzrLSr0w464iDE2Jv+mfsQyDLbPqlC9XEGpFu9KBxFx07+KPXWsR6kr02Tgk2fJ3ulvjdiKijPJd2EPMcqID96OcOqj/uCF/V+6MYDFkW6NlVR5eWMFf+caoPBoCiQxHguJ/BWn2Nt+/d7LHwk69zDTIzqt35GmMuoaho7idYrBzTS7yFU7rRghw3pVL5X4c9i4LE2QS5r59QBm8FJTtOqdwzRrju4/cPXmMV65S054EmWWTBKFXMIClT7YPWN3N9hAaNB8S3Cc6sHWyA+COP8gR6nuxyfLjGl7d4aCpJbIJUbT8WJx64Q0sKD4cjoPWtWHheWmfy/pMY9rDumd5/Vq/OaOAQAQVqboCfFeqi5NdrKe2LQXSW4/u/51iqfceb77TgBWerQHjS457dejEfH7mAwgRjTpMAGsnxoTI9wdoNaHmSI94dNWH2IH9GcA2PbvS5JKqgVrQOAAJ6RVb3/NApTuHM0BM9mXvQ
DKIM-Signature: a=rsa-sha256; bh=BH2ypaGIGioPbhMgOZFVFcYuPiFMRNHbe3vWB1O+qXM=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676225; v=1;
 b=CY6zFFJe3hvmPSrE8bM27jiwPLc6d37prIdu0KWicm39eJmTCtEBCsbBjWr55aUlrBxUaNcQ
 XsI7nr1GJR63LKicVE1hbMMv/bkD8riaYGQb0KJqUJYD45Lp9oTg61UTbuOorLxZ60xuOOD5wuH
 WIkkZk4TdQrfwc3qYRY4xZujO+edPo7YAjyK3AHaiMHT9E/p9ltO6SZACTgvi7CJb95xw7eiCXT
 Bft1M06d6nF10IwaAv6xA1TS1/CNpI5Bm/ACU79HzdUTWIP3Fk2RPFHHTyP3Mb+aPRkZNnBMAN/
 3pdDHlG28jtqA9fmEGYgvaHjJnuW/v13ss3TrQINZaTdA==
X-purgate-ID: tlsNG-bad1c0/1785676226-BCECE034-12BB87FE/0/0
X-purgate-type: clean
X-purgate-size: 11676

Instead of storing hashing result to stack variables, a TPM event log is discovered in an Slaunch-specific way, extended with an additional entry and that entry is filled with digests.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Szymon Acedański <accek@invisiblethingslab.com>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: was "x86/tpm.c: implement event log for TPM2.0"
    v4: part of it as in "x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2)"
    v4: TPM event log code was part of tpm.c changes, now in slaunch-tpm.c
    v4: fixed comment on txt_ext_data_element::size and finding log element (worked because it was first)
    v4: provide list of hashes even in the absence of event log to extend PCRs

 xen/arch/x86/include/asm/intel-txt.h |  69 ++++++++++
 xen/arch/x86/slaunch-tpm.c           | 188 +++++++++++++++++++++++----
 2 files changed, 232 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 406929fac2..8bcca20d6e 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -71,6 +71,8 @@
 #include <xen/multiboot2.h>
 #include <xen/slr-table.h>
 
+#include <asm/tpm1.h>
+
 /* Need to differentiate between pre- and post paging enabled. */
 #ifdef __EARLY_SLAUNCH__
 #include <xen/macros.h>
@@ -200,6 +202,52 @@ struct txt_sinit_mle_data {
     /* Ext Data Elements */
 } __packed;
 
+struct txt_ev_log_container_12 {
+    char        Signature[20];      /* "TXT Event Container", null-terminated */
+    uint8_t     Reserved[12];
+    uint8_t     ContainerVerMajor;
+    uint8_t     ContainerVerMinor;
+    uint8_t     PCREventVerMajor;
+    uint8_t     PCREventVerMinor;
+    uint32_t    ContainerSize;      /* Allocated size */
+    uint32_t    PCREventsOffset;
+    uint32_t    NextEventOffset;
+    struct TPM12_PCREvent   PCREvents[];
+};
+
+/* Types of extended data. */
+#define TXT_HEAP_EXTDATA_TYPE_END                    0
+#define TXT_HEAP_EXTDATA_TYPE_BIOS_SPEC_VER          1
+#define TXT_HEAP_EXTDATA_TYPE_ACM                    2
+#define TXT_HEAP_EXTDATA_TYPE_STM                    3
+#define TXT_HEAP_EXTDATA_TYPE_CUSTOM                 4
+#define TXT_HEAP_EXTDATA_TYPE_MADT                   6
+#define TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1   8
+#define TXT_HEAP_EXTDATA_TYPE_MCFG                   9
+#define TXT_HEAP_EXTDATA_TYPE_TPR_REQ               13
+#define TXT_HEAP_EXTDATA_TYPE_DTPR                  14
+#define TXT_HEAP_EXTDATA_TYPE_CEDT                  15
+
+/*
+ * Self-describing data structure that is used for extensions to TXT heap
+ * tables.
+ */
+struct txt_ext_data_element {
+    uint32_t type;   /* One of TXT_HEAP_EXTDATA_TYPE_*. */
+    uint32_t size;   /* Size of the whole element (header + data), in bytes. */
+    uint8_t data[0];
+} __packed;
+
+/*
+ * Extended data describing TPM 2.0 log.
+ */
+struct heap_event_log_pointer_element2_1 {
+    uint64_t physical_address;
+    uint32_t allocated_event_container_size;
+    uint32_t first_record_offset;
+    uint32_t next_record_offset;
+} __packed;
+
 /*
  * Functions to extract data from the Intel TXT Heap Memory.
  *
@@ -268,6 +316,27 @@ static inline void *txt_init(void)
     return txt_heap;
 }
 
+/*
+ * Find the given element in the TXT heap extended data.
+ */
+static inline struct txt_ext_data_element *
+txt_find_ext_data_element(struct txt_os_sinit_data *os_sinit, uint32_t type)
+{
+    struct txt_ext_data_element *ext_elem;
+
+    ext_elem = (void *)os_sinit + sizeof(struct txt_os_sinit_data);
+
+    while ( ext_elem->type != TXT_HEAP_EXTDATA_TYPE_END )
+    {
+        if ( ext_elem->type == type )
+            return ext_elem;
+
+        ext_elem = (void *)ext_elem + ext_elem->size;
+    }
+
+    return NULL;
+}
+
 static inline bool is_in_pmr(const struct txt_os_sinit_data *os_sinit,
                              uint64_t base, uint32_t size, bool check_high)
 {
diff --git a/xen/arch/x86/slaunch-tpm.c b/xen/arch/x86/slaunch-tpm.c
index 21dec67dca..e3b7341cc5 100644
--- a/xen/arch/x86/slaunch-tpm.c
+++ b/xen/arch/x86/slaunch-tpm.c
@@ -67,6 +67,136 @@ void asmlinkage slaunch_measure_mbi(const multiboot2_fixed_t *mbi,
 
 #endif  /* __EARLY_SLAUNCH__ */
 
+static struct tpm_log_hashes
+create_log_event12(struct txt_ev_log_container_12 *evt_log,
+                   uint32_t evt_log_size, uint32_t pcr, uint32_t type,
+                   const uint8_t *data, unsigned data_size)
+{
+    struct tpm_log_hashes log_hashes = {0};
+
+    struct TPM12_PCREvent *new_entry;
+
+    if (evt_log == NULL)
+        return log_hashes;
+
+    new_entry = (void *)evt_log + evt_log->NextEventOffset;
+
+    /*
+     * Check if there is enough space left for new entry.
+     * Note: it is possible to introduce a gap in event log if entry with big
+     * data_size is followed by another entry with smaller data. Maybe we should
+     * cap the event log size in such case?
+     */
+    if ( evt_log->NextEventOffset + sizeof(struct TPM12_PCREvent) + data_size >
+         evt_log_size )
+        return log_hashes;
+
+    evt_log->NextEventOffset += sizeof(struct TPM12_PCREvent) + data_size;
+
+    new_entry->PCRIndex = pcr;
+    new_entry->Type = type;
+    new_entry->Size = data_size;
+
+    if ( data != NULL && data_size > 0 )
+        memcpy(new_entry->Data, data, data_size);
+
+    log_hashes.count = 1;
+    log_hashes.hashes[0].alg = TPM_ALG_SHA1;
+    log_hashes.hashes[0].size = SHA1_DIGEST_SIZE;
+    log_hashes.hashes[0].data = new_entry->Digest;
+
+    return log_hashes;
+}
+
+static struct heap_event_log_pointer_element2_1 *
+find_evt_log_ext_data(struct tpm2_spec_id_event *evt_log)
+{
+    struct txt_os_sinit_data *os_sinit;
+    struct txt_ext_data_element *ext_data;
+
+    os_sinit = txt_start(__va(txt_read(TXTCR_HEAP_BASE)), TXT_OS2SINIT);
+    ext_data = txt_find_ext_data_element(os_sinit,
+                                         TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1);
+    if ( ext_data == NULL )
+        return NULL;
+
+    return (struct heap_event_log_pointer_element2_1 *)ext_data->data;
+}
+
+static struct tpm_log_hashes
+create_log_event20(struct tpm2_spec_id_event *evt_log, uint32_t evt_log_size,
+                   uint32_t pcr, uint32_t type, const uint8_t *data,
+                   unsigned data_size)
+{
+    struct tpm_log_hashes log_hashes = {0};
+
+    struct heap_event_log_pointer_element2_1 *log_ext_data;
+    struct tpm2_pcr_event_header *new_entry;
+    uint32_t entry_size;
+    unsigned i;
+    uint8_t *p;
+
+    if (evt_log == NULL)
+        return log_hashes;
+
+    log_ext_data = find_evt_log_ext_data(evt_log);
+    if ( log_ext_data == NULL )
+        return log_hashes;
+
+    entry_size = sizeof(*new_entry);
+    for ( i = 0; i < evt_log->digestCount; ++i )
+    {
+        entry_size += sizeof(uint16_t); /* hash type */
+        entry_size += evt_log->digestSizes[i].digestSize;
+    }
+    entry_size += sizeof(uint32_t); /* data size field */
+    entry_size += data_size;
+
+    /*
+     * Check if there is enough space left for new entry.
+     * Note: it is possible to introduce a gap in event log if entry with big
+     * data_size is followed by another entry with smaller data. Maybe we should
+     * cap the event log size in such case?
+     */
+    if ( log_ext_data->next_record_offset + entry_size > evt_log_size )
+        return log_hashes;
+
+    new_entry = (void *)evt_log + log_ext_data->next_record_offset;
+    log_ext_data->next_record_offset += entry_size;
+
+    new_entry->pcrIndex = pcr;
+    new_entry->eventType = type;
+    new_entry->digestCount = evt_log->digestCount;
+
+    p = &new_entry->digests[0];
+    for ( i = 0; i < evt_log->digestCount; ++i )
+    {
+        uint16_t alg = evt_log->digestSizes[i].algId;
+        uint16_t size = evt_log->digestSizes[i].digestSize;
+
+        *(uint16_t *)p = alg;
+        p += sizeof(uint16_t);
+
+        log_hashes.hashes[i].alg = alg;
+        log_hashes.hashes[i].size = size;
+        log_hashes.hashes[i].data = p;
+        p += size;
+
+        /* This is called "OneDigest" in TXT Software Development Guide. */
+        memset(log_hashes.hashes[i].data, 0, size);
+        log_hashes.hashes[i].data[0] = 1;
+    }
+    log_hashes.count = evt_log->digestCount;
+
+    *(uint32_t *)p = data_size;
+    p += sizeof(uint32_t);
+
+    if ( data != NULL && data_size > 0 )
+        memcpy(p, data, data_size);
+
+    return log_hashes;
+}
+
 void slaunch_find_log(const struct slr_table *slrt, paddr_t *evt_log,
                       uint32_t *evt_log_size)
 {
@@ -99,42 +229,50 @@ void slaunch_hash_extend(unsigned int loc, unsigned int pcr, const uint8_t *buf,
 {
     paddr_t evt_log_paddr;
     uint32_t evt_log_size;
-    struct tpm_log_hashes log_hashes;
     uint8_t discarded_digests[SHA2_256_DIGEST_SIZE];
+    struct tpm_log_hashes log_hashes;
     uint32_t rc;
 
     slaunch_find_log(slaunch_get_slrt(), &evt_log_paddr, &evt_log_size);
 
     if ( tpm_is_tpm1() )
     {
-        log_hashes = (struct tpm_log_hashes) {
-            .count = 1,
-            .hashes = {
-                {
-                    .alg = TPM_ALG_SHA1,
-                    .size = SHA1_DIGEST_SIZE,
-                    .data = discarded_digests,
-                },
-            },
-        };
+        struct txt_ev_log_container_12 *evt_log = __va(evt_log_paddr);
+
+        log_hashes = create_log_event12(evt_log, evt_log_size, pcr, type,
+                                        log_data, log_data_size);
     }
     else
     {
-        log_hashes = (struct tpm_log_hashes) {
-            .count = 2,
-            .hashes = {
-                {
-                    .alg = TPM_ALG_SHA1,
-                    .size = SHA1_DIGEST_SIZE,
-                    .data = discarded_digests,
-                },
-                {
-                    .alg = TPM_ALG_SHA256,
-                    .size = SHA2_256_DIGEST_SIZE,
-                    .data = discarded_digests,
+        struct tpm2_spec_id_event *evt_log = __va(evt_log_paddr);
+
+        log_hashes = create_log_event20(evt_log, evt_log_size, pcr, type,
+                                        log_data, log_data_size);
+
+        if ( log_hashes.count == 0 )
+        {
+            /*
+             * Because TPM2 supports multiple PCR banks, the list of digests is
+             * also used to indicate which banks to extend.  Thus avoid passing
+             * an empty list of digests to have a chance of something being
+             * extended even without event log.
+             */
+            log_hashes = (struct tpm_log_hashes) {
+                .count = 2,
+                .hashes = {
+                    {
+                        .alg = TPM_ALG_SHA1,
+                        .size = SHA1_DIGEST_SIZE,
+                        .data = discarded_digests,
+                    },
+                    {
+                        .alg = TPM_ALG_SHA256,
+                        .size = SHA2_256_DIGEST_SIZE,
+                        .data = discarded_digests,
+                    },
                 },
-            },
-        };
+            };
+        }
     }
 
     rc = tpm_hash_extend(loc, pcr, buf, size, &log_hashes);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380680.1624439 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxZ-0000Eg-Ne; Sun, 02 Aug 2026 13:10:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380680.1624439; Sun, 02 Aug 2026 13:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxZ-0000EQ-IL; Sun, 02 Aug 2026 13:10:33 +0000
Received: by outflank-mailman (input) for mailman id 1380680;
 Sun, 02 Aug 2026 13:10:32 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxY-00007z-GC
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxX-001lF1-TF
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:31 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4184-e002-0a2a0a5209dd-0a2a4509b098-44
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:31 +0200
Received: from [87.98.184.158] (helo=11.mo561.mail-out.ovh.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41c7-be1a-0a2a45090019-5762b89ebacd-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:31 +0200
Received: from director9.ghost.mail-out.ovh.net (unknown [10.109.231.47])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCW0pGXz5wv5
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:31 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-qqknf (unknown [10.110.118.7])
 by director9.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 8D24180CB8;
 Sun,  2 Aug 2026 13:10:30 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.107])
 by ghost-submission-7d8d68f679-qqknf with ESMTPSA
 id imrrGcZBb2r/DwMAM9HtzQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-107S001a797ad44-ff3d-4c1b-8922-8d72a027f86c,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 16/23] x86/boot: choose AP stack based on APIC ID
Date: Sun,  2 Aug 2026 16:09:32 +0300
Message-ID: <d10e07140ac056f714d5c0544814da16d53793ff.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4739757135520277948
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTGLHzKh4/yJ/9rf7CVt2QjsLwpvIpIsbu5Q2ifTmTa4q+eoHsA7x5p9tsU480lKc7avA4p9mQWidCaEagfwmOhbXstCvypZ5scXYG1ng5ZFn9DnZ/N4oJIyWEurvQROCl2S2LjSwQS4U9WsDPZlCH4wDQNquTzOHj3nCzD461Ug0y82B4dSkV4Qd6i3fTBEb7a9savBPVAJgImDz1yOc6e/MZXaSIBshKtsS6bpgI45CY1MGNOZLKz09EiRFzZT/TqOcaDeccgXEqV2zkykSmXX8x9Rj5Vs78IZmjlqU3jZjyxS/HGi3JQdQKPhStYb42CxYmmlD99lDVIwqt02Eg61lKPUSgxiC3YPZU5EOM9qZgJJDIvxKa/27X25R8OtxF+YZxXiSazSGf/tGvBabHCGft3wtC0/wejVTmTfsbwZK3I4ZGECc/2eSuWJ9DWM5KwmSHZZzDNcGWqsu+fauCQYbzRJNhzlDjDLHXRKFXl3fWOzuaHGVrdQNkb/3meb4lAfZz3eBo2I9cM29P6RaLUfPWDlC9oAUcWxEXgPHopmiqnrIhGSyQj5G+7Ky6YGBOZVt8t3o6NW4JVr7p96F6LEHAP1WOkX/798e630MFicSIWZW2tsrrY2P/huNH8FtUEchedmL8mI1pqPfdm2nHPPYuEMn8ycVI3g0kb7Cxc4vg
DKIM-Signature: a=rsa-sha256; bh=Eqi6HL4ViPn3eSFszDe1Rd+g0+twCZr1xKGba49FCiw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676231; v=1;
 b=Rqvv9Dkk75QS2x6loJ83clBTdNzE068Uah/YFdh7olIMBCN946tKIl9gcRBYq151d6p0ThRI
 nKyGSrvxZsY7GX92OvhHfFX2GSCWPeqmG+tbel6ESa2aCJdfHQ6cyUH5+mqplNSEgBa5jA+rhJ9
 0izzWE+jbeykLm2IQkR9zM04K8cco3UK4MbIWfNyEDmtavxSOIMQS7XbmIUhmM1Q+12cMHBollB
 UCIfGuhTn+Tj1cEeg7wCGuRg2n2a3qkTEOEknUWz4JKrFPb8yiliYV5ploUSGwFH4EqVA9A8gPH
 Y5QMIRIPVDmeQHt4Eju0RaGI5L0yf3TXE3hJqhos899jw==
X-purgate-ID: tlsNG-bad1c0/1785676231-3A4DB034-558501BB/0/0
X-purgate-type: clean
X-purgate-size: 6017

From: Krystian Hebel <krystian.hebel@3mdeb.com>

This is made as the first step of making parallel AP bring-up possible.
It should be enough for pre-C code.

Parallel AP bring-up is necessary because TXT by design releases all APs
at once. In addition to that it reduces number of IPIs (and more
importantly, delays between them) required to start all logical
processors. This results in significant reduction of boot time, even
when DRTM is not used, with performance gain growing with the number of
logical CPUs.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: better comments in boot/trampoline.S
    v4: use %ebp instead of %esp to pass data to boot/x86_64.S
    v4: use `nr_cpu_ids(%rip)` instead of `$NR_CPUS` in boot/x86_64.S
    v4: L_stack_set => L_after_stack_setup
    v4: __ASSEMBLY__ => __ASSEMBLER__

 xen/arch/x86/boot/head.S             |  1 +
 xen/arch/x86/boot/trampoline.S       | 23 +++++++++++++++++++++
 xen/arch/x86/boot/x86_64.S           | 31 +++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/apicdef.h   |  4 ++++
 xen/arch/x86/include/asm/msr-index.h |  3 +++
 xen/arch/x86/setup.c                 |  7 +++++++
 6 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 2c1a0f6306..ff46579904 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -8,6 +8,7 @@
 #include <asm/page.h>
 #include <asm/processor.h>
 #include <asm/msr-index.h>
+#include <asm/apicdef.h>
 #include <asm/cpufeature.h>
 #include <asm/trampoline.h>
 
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index a92e399fbe..9306c1bb76 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -71,6 +71,29 @@ trampoline_protmode_entry:
         mov     $X86_CR4_PAE,%ecx
         mov     %ecx,%cr4
 
+        /*
+         * Get APIC ID while we're in non-paged mode to later derive Xen CPU
+         * index and determine CPU-specific stack. Start by checking if x2APIC
+         * is enabled.
+         */
+        mov     $MSR_APIC_BASE, %ecx
+        rdmsr
+        test    $APIC_BASE_EXTD, %eax
+        jnz     .Lx2apic
+
+        /* Not x2APIC, read APIC ID from MMIO. */
+        and     $APIC_BASE_ADDR_MASK, %eax
+        mov     APIC_ID(%eax), %eax
+        shr     $24, %eax
+        jmp     1f
+
+.Lx2apic:
+        mov     $(MSR_X2APIC_FIRST + (APIC_ID >> MSR_X2APIC_SHIFT)), %ecx
+        rdmsr
+1:
+        /* The value of the APIC ID will be consumed in __high_start. */
+        mov     %eax, %ebp
+
         /* Load pagetable base register. */
         mov     $sym_offs(idle_pg_table),%eax
         add     bootsym_rel(trampoline_xen_phys_start,4,%eax)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 9705d03f84..19f3062a7b 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -11,7 +11,36 @@ ENTRY(__high_start)
         mov     %ecx,%gs
         mov     %ecx,%ss
 
-        mov     stack_start(%rip),%rsp
+        /* %ebx is set to non-zero in trampoline.S to indicate an AP. */
+        test    %ebx, %ebx
+        cmovz   stack_start(%rip), %rsp
+        jz      .L_after_stack_setup
+
+        /*
+         * APs only: get stack base from APIC ID saved to %ebp in trampoline.S.
+         */
+        mov     $-1, %rax
+        lea     x86_cpu_to_apicid(%rip), %rcx
+1:
+        inc     %rax
+        cmp     nr_cpu_ids(%rip), %eax
+        jb      2f
+        hlt
+2:
+        cmp     %ebp, (%rcx, %rax, 4)
+        jne     1b
+
+        /* %eax is now Xen CPU index. */
+        lea     stack_base(%rip), %rcx
+        mov     (%rcx, %rax, 8), %rsp
+
+        test    %rsp, %rsp
+        jnz     1f
+        hlt
+1:
+        add     $(STACK_SIZE - CPUINFO_sizeof), %rsp
+
+.L_after_stack_setup:
 
         /* Reset EFLAGS (subsumes CLI and CLD). */
         pushq   $0
diff --git a/xen/arch/x86/include/asm/apicdef.h b/xen/arch/x86/include/asm/apicdef.h
index 112c1dc613..7a09d08b91 100644
--- a/xen/arch/x86/include/asm/apicdef.h
+++ b/xen/arch/x86/include/asm/apicdef.h
@@ -120,6 +120,10 @@
 
 #define MAX_IO_APICS 128
 
+#ifndef __ASSEMBLER__
+
 extern bool x2apic_enabled;
 
+#endif /* !__ASSEMBLER__ */
+
 #endif
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index ad1c6c97f8..0900e21811 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -186,6 +186,9 @@
 #define MSR_X2APIC_FIRST                    0x00000800
 #define MSR_X2APIC_LAST                     0x000008ff
 
+/* MSR offset can be obtained by shifting MMIO offset this number of bits to the right. */
+#define MSR_X2APIC_SHIFT                    4
+
 #define MSR_X2APIC_TPR                      0x00000808
 #define MSR_X2APIC_PPR                      0x0000080a
 #define MSR_X2APIC_EOI                      0x0000080b
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 5494fa1621..fbc44b0174 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2141,6 +2141,7 @@ void asmlinkage __init noreturn __start_xen(void)
      */
     if ( !pv_shim )
     {
+        /* Separate loop to make parallel AP bringup possible. */
         for_each_present_cpu ( i )
         {
             /* Set up cpu_to_node[]. */
@@ -2148,6 +2149,12 @@ void asmlinkage __init noreturn __start_xen(void)
             /* Set up node_to_cpumask based on cpu_to_node[]. */
             numa_add_cpu(i);
 
+            if ( stack_base[i] == NULL )
+                stack_base[i] = cpu_alloc_stack(i);
+        }
+
+        for_each_present_cpu ( i )
+        {
             if ( (park_offline_cpus || num_online_cpus() < max_cpus) &&
                  !cpu_online(i) )
             {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:10:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:10:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380720.1624447 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxv-0001tL-76; Sun, 02 Aug 2026 13:10:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380720.1624447; Sun, 02 Aug 2026 13:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqVxv-0001tB-40; Sun, 02 Aug 2026 13:10:55 +0000
Received: by outflank-mailman (input) for mailman id 1380720;
 Sun, 02 Aug 2026 13:10:53 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqVxt-0001mb-5Z
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:10:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqVxs-001xWz-IX
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:10:52 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f417c-5cb7-0a2a0a5109dd-0a2a450494b6-38
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:52 +0200
Received: from [46.105.78.111] (helo=9.mo575.mail-out.ovh.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41db-b57f-0a2a45040019-2e694e6fce07-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:52 +0200
Received: from director4.ghost.mail-out.ovh.net (unknown [10.110.0.25])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCv5gCvz5yC5
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:51 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-mmdjj (unknown [10.111.174.62])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id CE7D3C21CD;
 Sun,  2 Aug 2026 13:10:50 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.107])
 by ghost-submission-7d8d68f679-mmdjj with ESMTPSA
 id 3kn8ItpBb2ouQCEAuGTBVw
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-107S00173adc3a6-1efd-427d-a375-044976d73348,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 22/23] xen/arch/x86: add TPR (TXT Protected Range) DMA protection support
Date: Sun,  2 Aug 2026 16:09:38 +0300
Message-ID: <8ed1f7368cee0cff23a58307e57cc7674ac33f3f.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4745386632626185660
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTE33bHOuRYjR55j3c0aKJq9LyUAb/VEqKPzbbnohVyg0sOzvTcGgEpNupkNpT0kA5RkCIYWacPED1f5CRgYm6QYZs34c8QczK9TFMGKFcrxaX4rGTDwIGsX2VV0UOdEb3kMbe0OGNl1im0yNBFiDgox63+E3E8fd2OAuJbMS1O4xwld9YJ8XPGcIIH1nNDgFE7Fl6ZKuahgLIsF2gye04vdnhGmKcdC30OZEE6Qh2AGE2vwZgyGoqcrUOVY+fOYmZC3joypOFUGhebsnPOQewACpCWZtmWpz4NqsbMeBA08IBf/10rJZlXY2/jCGwiJRxwa1XYsjVMTivuwcBl6mQPTBA4AjdY5/vlPIkPy495Y9wvlhkevDpwzeUMZ0b5t/BE5NDPsOhOvv+JEjKc6r3MieiWIHtLq5zf5mnjmSlI+BlY2pJIHFtYJGfdurc78OF3KiUN58+xe8RO4TAznmjW3iUAfcR3d4f8k2R9H3eRoZr82CNEDrhZ6I7Im7yJcMvbp9IJFc2xb7x1OvgO0Izsdsa8uCd5ZsaXtbv5zDL0WvQX9AHReLVmyXkihfbvt96xzd39f27OYLH5DKqhs5Q1Gfj4n1HxRaQhpxykFmHNNPeytF3RArwQavj/OK2rxi2TUlxeQqJ8orf8HlZ46g7RPslh6lr565p/2Il4Y7GOg0Q
DKIM-Signature: a=rsa-sha256; bh=XRhIvLHiIGKrJOYDdY+rnVnbW5lLaGsiIQXQluDbzAI=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676251; v=1;
 b=hzOmIa+43lNKkFP7PxEwBlHTNgZInsK1BZTLBg6jOdx4wHgDB8EEuP0lJEfQsjw7u9s3ya5y
 GVioZfZv1Y8WEZpRdqYZZQfIjtz09Ty8AxKXPAEXiDOCsU6gpjYZ3C0daASWrP/6fiPX/4SOgP7
 IHhtVFjw40B/fg0JHHoa4UBiX2TwSTHlWn1+swqZJQmQqeUdAY2DKaYad+IuPGRCXH8vGw0z1L+
 YbBklA7ZtKn71tWupNjNV6wEMDHM2I4mNM8XwLhJIOgvOBIn7RUzjFV0zK4mPHcF0RH4wWPd2KR
 EcHLzhuQJl+pylnvCmhJfGlqLzQCUf5F+7UgNMcrg6kiw==
X-purgate-ID: tlsNG-ebf023/1785676252-51CD7B50-5F158D66/0/0
X-purgate-type: clean
X-purgate-size: 14489

From: Szymon Acedański <accek@invisiblethingslab.com>

Pointer to txt_os_sinit_data variables lost constness due to the use of
txt_find_ext_data_element() which needs to work in a non-const context
as well for its other use.

This is required for modern Intel CPUs (at least LunarLake) that no
longer support PMR (Protected Memory Regions) protection mechanism.
Unlike PMR, TPR is not related to Intel VT-d, independent from IOMMU
and, despite its name, is not tied to TXT.

The next generation (PantherLake) similarly supports only PMR but seems
to have an undocumented requirement that TPR protection must be disabled
or device initialization fails (NVMe/USB/NIC).  This is not done by this
patch.

Signed-off-by: Szymon Acedański <accek@invisiblethingslab.com>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: new commit in this version, needed for modern devices

 xen/arch/x86/boot/head.S             |   4 +-
 xen/arch/x86/boot/slaunch-early.c    |   6 +-
 xen/arch/x86/efi/efi-boot.h          |   7 +-
 xen/arch/x86/include/asm/intel-txt.h | 182 +++++++++++++++++++++------
 4 files changed, 151 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 22b331a45c..ac177839d1 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -136,12 +136,12 @@ SYM(mle_header, DATA, LOCAL, 16)
         .long   0xa2555c0f  /* UUID2 */
         .long   0x42b651cb  /* UUID3 */
         .long   (.Lmle_header_end - mle_header)  /* MLE header size */
-        .long   0x00020002  /* MLE version 2.2 */
+        .long   0x00020003  /* MLE version 2.3 */
         .long   (slaunch_stub_entry - start)  /* Linear entry point of MLE (SINIT virt. address) */
         .long   0x00000000  /* First valid page of MLE */
         .long   0x00000000  /* Offset within binary of first byte of MLE */
         .long   (__base_relocs_end - start)  /* Offset within binary of last byte + 1 of MLE */
-        .long   0x00000723  /* Bit vector of MLE-supported capabilities */
+        .long   0x00004723  /* Bit vector of MLE-supported capabilities */
         .long   0x00000000  /* Starting linear address of command line (unused) */
         .long   0x00000000  /* Ending linear address of command line (unused) */
 .Lmle_header_end:
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index 9b16602ac8..7348a3d156 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -35,7 +35,7 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     void *txt_heap;
     const struct txt_os_mle_data *os_mle;
     const struct slr_table *slrt;
-    const struct txt_os_sinit_data *os_sinit;
+    struct txt_os_sinit_data *os_sinit;
     const struct slr_entry_hdr *entry;
     const struct slr_entry_intel_info *intel_info;
     uint32_t size = tgt_end_addr - tgt_base_addr;
@@ -99,6 +99,6 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
 
     result->mbi_pa = intel_info->boot_params_base;
 
-    txt_verify_pmr_ranges(os_mle, os_sinit, intel_info,
-                          load_base_addr, tgt_base_addr, size);
+    txt_verify_dma_protection(os_mle, os_sinit, intel_info,
+                              load_base_addr, tgt_base_addr, size);
 }
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 9653de4ca9..573d1938c6 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -261,11 +261,12 @@ void __init asmlinkage noreturn start_xen_from_efi(void)
             void *txt_heap = txt_init();
             const struct txt_os_mle_data *os_mle =
                 txt_start(txt_heap, TXT_OS2MLE);
-            const struct txt_os_sinit_data *os_sinit =
+            struct txt_os_sinit_data *os_sinit =
                 txt_start(txt_heap, TXT_OS2SINIT);
 
-            txt_verify_pmr_ranges(os_mle, os_sinit, intel_info, xen_phys_start,
-                                  xen_phys_start, xen_image_size);
+            txt_verify_dma_protection(os_mle, os_sinit, intel_info,
+                                      xen_phys_start, xen_phys_start,
+                                      xen_image_size);
         }
     }
 
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index eb15bf68ad..0fd2fb6fdd 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -65,6 +65,12 @@
 #define SLAUNCH_ERROR_NO_VENDOR_INFO    0xc0008009U
 #define SLAUNCH_ERROR_BAD_VENDOR_INFO   0xc000800AU
 #define SLAUNCH_ERROR_BAD_SLRT_ADDRESS  0xc000800BU
+#define SLAUNCH_ERROR_TPR_INVALID       0xc000800CU
+#define SLAUNCH_ERROR_TPR_UNSUPPORTED   0xc000800DU
+#define SLAUNCH_ERROR_TPR_NOT_FOUND     0xc000800EU
+
+/* SINIT/MLE capability bit for TPR (TXT Protected Range) DMA protection. */
+#define TXT_SINIT_MLE_CAP_TPR_SUPPORT   14
 
 #ifndef __ASSEMBLER__
 
@@ -253,6 +259,19 @@ struct heap_event_log_pointer_element2_1 {
     uint32_t next_record_offset;
 } __packed;
 
+/*
+ * Extended data describing TPR (TXT Protected Range) DMA protection ranges.
+ */
+struct txt_heap_tpr_range {
+    uint64_t base;
+    uint64_t size;
+} __packed;
+
+struct txt_heap_tpr_req_element {
+    uint32_t count;
+    struct txt_heap_tpr_range ranges[0];
+} __packed;
+
 /*
  * Functions to extract data from the Intel TXT Heap Memory.
  *
@@ -342,67 +361,150 @@ txt_find_ext_data_element(struct txt_os_sinit_data *os_sinit, uint32_t type)
     return NULL;
 }
 
-static inline bool is_in_pmr(const struct txt_os_sinit_data *os_sinit,
-                             uint64_t base, uint32_t size, bool check_high)
+static inline bool is_in_dma_prot(struct txt_os_sinit_data *os_sinit,
+                                  uint64_t base, uint32_t size, bool check_high)
 {
+    uint64_t lo_size, hi_base, hi_size;
+
     /* Check for size overflow. */
     if ( base + size < base )
         txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
 
+    if ( os_sinit->capabilities & (1u << TXT_SINIT_MLE_CAP_TPR_SUPPORT) )
+    {
+        /*
+         * txt_verify_dma_protection() has already validated presence and contents
+         * of the TPR_REQ element.
+         */
+        const struct txt_heap_tpr_req_element *tpr_req = (const struct txt_heap_tpr_req_element *)
+            txt_find_ext_data_element(os_sinit, TXT_HEAP_EXTDATA_TYPE_TPR_REQ)->data;
+
+        lo_size = tpr_req->ranges[0].size;
+        if ( tpr_req->count > 1 )
+        {
+            hi_base = tpr_req->ranges[1].base;
+            hi_size = tpr_req->ranges[1].size;
+        }
+        else
+        {
+            hi_base = 0;
+            hi_size = 0;
+        }
+    }
+    else
+    {
+        lo_size = os_sinit->vtd_pmr_lo_size;
+        hi_base = os_sinit->vtd_pmr_hi_base;
+        hi_size = os_sinit->vtd_pmr_hi_size;
+    }
+
     /*
-     * txt_verify_pmr_ranges() makes sure the low range always starts at 0, so
-     * its size is also end address.
+     * txt_verify_dma_protection() makes sure the low range always starts at
+     * 0, so its size is also end address.
      */
-    if ( base + size <= os_sinit->vtd_pmr_lo_size )
+    if ( base + size <= lo_size )
         return true;
 
-    if ( check_high && os_sinit->vtd_pmr_hi_size != 0 )
+    if ( check_high && hi_size != 0 )
     {
-        if ( base >= os_sinit->vtd_pmr_hi_base &&
-             base + size <= os_sinit->vtd_pmr_hi_base +
-                            os_sinit->vtd_pmr_hi_size )
+        if ( base >= hi_base && base + size <= hi_base + hi_size )
             return true;
     }
 
     return false;
 }
 
-static inline void txt_verify_pmr_ranges(
+static inline void txt_verify_dma_protection(
     const struct txt_os_mle_data *os_mle,
-    const struct txt_os_sinit_data *os_sinit,
+    struct txt_os_sinit_data *os_sinit,
     const struct slr_entry_intel_info *info,
     uint32_t load_base_addr,
     uint32_t tgt_base_addr,
     uint32_t xen_size)
 {
-    bool check_high_pmr = false;
+    bool check_high = false;
 
-    /* Verify the value of the low PMR base. It should always be 0. */
-    if ( os_sinit->vtd_pmr_lo_base != 0 )
-        txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
+    if ( os_sinit->capabilities & (1u << TXT_SINIT_MLE_CAP_TPR_SUPPORT) )
+    {
+        const struct txt_ext_data_element *tpr_req_data_element;
+        const struct txt_heap_tpr_req_element *tpr_req;
 
-    /*
-     * Low PMR size should not be 0 on current platforms. There is an ongoing
-     * transition to TPR-based DMA protection instead of PMR-based; this is not
-     * yet supported by the code.
-     */
-    if ( os_sinit->vtd_pmr_lo_size == 0 )
-        txt_reset(SLAUNCH_ERROR_LO_PMR_SIZE);
+        /*
+         * For TPR-based DMA protection, it's not specified that the low
+         * range must begin at address 0. For now though, we support only
+         * 1- and 2-range configurations with the low range starting at 0.
+         */
 
-    /* Check if regions overlap. Treat regions with no hole between as error. */
-    if ( os_sinit->vtd_pmr_hi_size != 0 &&
-         os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size )
-        txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
+        tpr_req_data_element = txt_find_ext_data_element(os_sinit, TXT_HEAP_EXTDATA_TYPE_TPR_REQ);
+        if ( tpr_req_data_element == NULL )
+            txt_reset(SLAUNCH_ERROR_TPR_NOT_FOUND);
+        if ( tpr_req_data_element->size < sizeof(struct txt_heap_tpr_req_element) )
+            txt_reset(SLAUNCH_ERROR_TPR_INVALID);
+        tpr_req = (const struct txt_heap_tpr_req_element *)tpr_req_data_element->data;
+        if ( tpr_req->count < 1 )
+            txt_reset(SLAUNCH_ERROR_TPR_INVALID);
+        if ( tpr_req->count > 2 )
+            txt_reset(SLAUNCH_ERROR_TPR_UNSUPPORTED);
+
+        /* Low range must start at 0. */
+        if ( tpr_req->ranges[0].base != 0 )
+            txt_reset(SLAUNCH_ERROR_TPR_UNSUPPORTED);
+
+        /* Size must not be 0. */
+        if ( tpr_req->ranges[0].size == 0 )
+            txt_reset(SLAUNCH_ERROR_TPR_INVALID);
+
+        if ( tpr_req->count > 1 )
+        {
+            /* Size must not be 0. */
+            if ( tpr_req->ranges[1].size == 0 )
+                txt_reset(SLAUNCH_ERROR_TPR_INVALID);
+
+            /* Ranges must not overlap. */
+            if ( tpr_req->ranges[0].size > tpr_req->ranges[1].base )
+                txt_reset(SLAUNCH_ERROR_TPR_INVALID);
+
+            /* Overflow check. */
+            if ( tpr_req->ranges[1].base + tpr_req->ranges[1].size < tpr_req->ranges[1].size )
+                txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+
+            /* All regions accessed by 32b code must be below 4G. */
+            if ( tpr_req->ranges[1].base + tpr_req->ranges[1].size <=
+                 0x100000000ULL )
+                check_high = true;
+        }
+    }
+    else
+    {
+        /* Verify the value of the low PMR base. It should always be 0. */
+        if ( os_sinit->vtd_pmr_lo_base != 0 )
+            txt_reset(SLAUNCH_ERROR_LO_PMR_BASE);
 
-    /* Check for size overflow. */
-    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <
-         os_sinit->vtd_pmr_hi_size )
-        txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+        /*
+         * Low PMR size should not be 0 on current platforms when PMR mode is
+         * in use.
+         */
+        if ( os_sinit->vtd_pmr_lo_size == 0 )
+            txt_reset(SLAUNCH_ERROR_LO_PMR_SIZE);
 
-    /* All regions accessed by 32b code must be below 4G. */
-    if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <=
-         0x100000000ULL )
-        check_high_pmr = true;
+        /*
+         * Check if regions overlap. Treat regions with no hole between as
+         * error.
+         */
+        if ( os_sinit->vtd_pmr_hi_size != 0 &&
+             os_sinit->vtd_pmr_hi_base <= os_sinit->vtd_pmr_lo_size )
+            txt_reset(SLAUNCH_ERROR_HI_PMR_BASE);
+
+        /* Check for size overflow. */
+        if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <
+             os_sinit->vtd_pmr_hi_size )
+            txt_reset(SLAUNCH_ERROR_INTEGER_OVERFLOW);
+
+        /* All regions accessed by 32b code must be below 4G. */
+        if ( os_sinit->vtd_pmr_hi_base + os_sinit->vtd_pmr_hi_size <=
+             0x100000000ULL )
+            check_high = true;
+    }
 
     /*
      * ACM checks that TXT heap and MLE memory is protected against DMA. We have
@@ -412,12 +514,12 @@ static inline void txt_verify_pmr_ranges(
      */
 
     /* Check if all of Xen before relocation is protected. */
-    if ( !is_in_pmr(os_sinit, load_base_addr, xen_size, check_high_pmr) )
+    if ( !is_in_dma_prot(os_sinit, load_base_addr, xen_size, check_high) )
         txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
 
     /* Check if all of Xen after relocation is protected. */
     if ( load_base_addr != tgt_base_addr &&
-         !is_in_pmr(os_sinit, tgt_base_addr, xen_size, check_high_pmr) )
+         !is_in_dma_prot(os_sinit, tgt_base_addr, xen_size, check_high) )
         txt_reset(SLAUNCH_ERROR_LO_PMR_MLE);
 
     /* If present, check that MBI is protected. */
@@ -426,8 +528,8 @@ static inline void txt_verify_pmr_ranges(
         const multiboot2_fixed_t *mbi =
             (const multiboot2_fixed_t *)(uintptr_t)info->boot_params_base;
 
-        if ( !is_in_pmr(os_sinit, info->boot_params_base, mbi->total_size,
-                        check_high_pmr) )
+        if ( !is_in_dma_prot(os_sinit, info->boot_params_base, mbi->total_size,
+                             check_high) )
             txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
     }
 
@@ -451,8 +553,8 @@ static inline void txt_verify_pmr_ranges(
      */
     /*
     if ( os_mle->evtlog_addr != 0 && os_mle->evtlog_size != 0 &&
-         !is_in_pmr(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
-                    check_high_pmr) )
+         !is_in_dma_prot(os_sinit, os_mle->evtlog_addr, os_mle->evtlog_size,
+                         check_high) )
         txt_reset(SLAUNCH_ERROR_BUFFER_BEYOND_PMR);
     */
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380749.1624457 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4J-0003Qe-Su; Sun, 02 Aug 2026 13:17:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380749.1624457; Sun, 02 Aug 2026 13:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4J-0003QX-P6; Sun, 02 Aug 2026 13:17:31 +0000
Received: by outflank-mailman (input) for mailman id 1380749;
 Sun, 02 Aug 2026 13:17:30 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4I-0003QO-FV
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4H-0084CP-Kx
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:29 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4336-2eae-0a2a0a5409dd-0a2a450ce7a6-36
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:29 +0200
Received: from [46.105.63.230] (helo=7.mo575.mail-out.ovh.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41c4-f479-0a2a450c0019-2e693fe6d995-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:28 +0200
Received: from director2.ghost.mail-out.ovh.net (unknown [10.109.231.104])
 by mo575.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCS41Xgz5x9r
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:28 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-4j9th (unknown [10.110.164.1])
 by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id D7F99C076B;
 Sun,  2 Aug 2026 13:10:27 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.106])
 by ghost-submission-7d8d68f679-4j9th with ESMTPSA
 id uj/0KMNBb2pAxRsAfFlxhA
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-106R00637ba2a53-4aa7-4a04-ab4f-2f442dba9a54,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 15/23] x86/hvm: check for VMX in SMX if Slaunch is active
Date: Sun,  2 Aug 2026 16:09:31 +0300
Message-ID: <239c0018e4c51a00bf4134971d3e15bf73947042.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4738912709584758204
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEO37Lm1soAj3J6HJwxZueJ91jNrKiCMD9VOxO+7S6oZcwX5ZhHy/rf+u1q3gsSFBR0MQ0G/W66mTSt5xumJoxY/EyDpxdVBT5aAA1fHupbW88f/IumzeClwwf3PGe5NCfIC4rAkaw9D49zl0L3FOqYw1yebY9XQZPEoEgqOhxU7iAITzoi4rSZJugXTxFrfgz5z3QYtYzrLSr0w464iDE2Jv+mfsQyDLbPqlC9XEGpFu9KBxFx07+KPXWsR6kr02Tgk2fJ3ulvjdiKijPJd2EPMcqID96OcOqj/uCF/V+6MYDFkW6NlVR5eWMFf+caoPBoCiQxHguJ/BWn2Nt+/d7LATLWy5uqTTYj8J0/VIlB7Zr0UhD/TGfijKUeNyIPDm3FNpzp7pAf5HCApOpKHKQAb3AHHyNlWfRyCdBrl2KexZBO+lUhUJhvSDWOvNVAM86kgUGxIbclAGz/zqAY8mQPB9gRquoFl/TJil04BBnx7enN7C2vdr+VA815b7S7rnOfIG1HRCwa53xu7oq5j8Jrk6vjnkxNemCkv1uxLGicCXcqfnOKl7UWejOh2fCFkM3x91o+8ufujVu7FXL6cKL0E5t+EbdHc11s/FCv80dpUD+DaiQWKUwGAij4tcrP/hC6VUH4U7N30B6kSSAEkw8VGa5RLTdAF0hBUqrFdxCBnw
DKIM-Signature: a=rsa-sha256; bh=CxIu903ncrohvbZGr5K789lKkzZuj0GGkRH1KVPxQwk=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676228; v=1;
 b=M/JtvsIAXXQ+z1xjEV7S+QcPMQ8cv+B9mCdM49UNJ7PO3qHZsIsQf5hIP8CkEQuh6tx0mJMp
 iPEH7wt3pzETmgdpBwSDECGzxOfXdGB9pp6CrHN9q8y9xCiZ/w7y6D46uPDgmTcDcYrKiUhqs85
 rYqHpuazZgH7ocDhT+dOWgj/3+o9q+R+I7pVjsZQEYEFpjRXICz6jxPbmjIZZCzPRWTDopqAGM4
 r1Wbaf+jncSkp/xPV+3PNIQSCUwRS5lby1+R9RtrO0nYnXyatw2lSrnm71ztFCkA/6An7qkYDr7
 LOWRPHpotE5JwY/jdO1Ll5JLIwZBq8wgxZPGvzZPgewVg==
X-purgate-ID: tlsNG-d25034/1785676229-766DEA5B-9E11368F/0/0
X-purgate-type: clean
X-purgate-size: 1271

From: Michał Żygowski <michal.zygowski@3mdeb.com>

Check whther IA32_FEATURE_CONTROL has the proper bits enabled to run
VMX in SMX when slaunch is active.

Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---

Notes:
    v4: added Acked-by

 xen/arch/x86/hvm/vmx/vmcs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 8e52ef4d49..3c5dfd7c1b 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -30,6 +30,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/shadow.h>
+#include <asm/slaunch.h>
 #include <asm/spec_ctrl.h>
 #include <asm/tboot.h>
 #include <asm/xstate.h>
@@ -742,7 +743,7 @@ static int _vmx_cpu_up(bool bsp)
     bios_locked = !!(eax & IA32_FEATURE_CONTROL_LOCK);
     if ( bios_locked )
     {
-        if ( !(eax & (tboot_in_measured_env()
+        if ( !(eax & (tboot_in_measured_env() || slaunch_active
                       ? IA32_FEATURE_CONTROL_ENABLE_VMXON_INSIDE_SMX
                       : IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX)) )
         {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380750.1624466 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4P-0003g4-3B; Sun, 02 Aug 2026 13:17:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380750.1624466; Sun, 02 Aug 2026 13:17:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4P-0003ft-0J; Sun, 02 Aug 2026 13:17:37 +0000
Received: by outflank-mailman (input) for mailman id 1380750;
 Sun, 02 Aug 2026 13:17:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4O-0003eV-9Q
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4N-00Bn6b-Mh
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:35 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f432c-bab6-0a2a0a5309dd-0a2a450aad66-34
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:35 +0200
Received: from [87.98.178.36] (helo=5.mo561.mail-out.ovh.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41ca-f2d2-0a2a450a0019-5762b224da49-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:34 +0200
Received: from director8.ghost.mail-out.ovh.net (unknown [10.109.231.242])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCZ1mvPz5xXb
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:34 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-7fkfz (unknown [10.110.178.196])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5D638C011C;
 Sun,  2 Aug 2026 13:10:33 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.95])
 by ghost-submission-7d8d68f679-7fkfz with ESMTPSA
 id ySKADMlBb2rUsRoA5cIDVQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-95G0019eb63cc7-1ece-468f-9b24-b7232bc7e4f6,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 17/23] x86/smpboot.c: TXT AP bringup
Date: Sun,  2 Aug 2026 16:09:33 +0300
Message-ID: <7e23a48a8de4d6784c084f679c1362fdab22dd13.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4740601558912869820
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEV0zrRFI+8lKEQL+a1JI/7/0OrRJXjCVgGfW7fQN9qAaB9I3Brjm6G89cK6Ny30hIcTAKPzAOTqm+s8tXkHnzgivH613CtFsQhOqga+yav7fPvP7w6BCXsI971V+GKiHDssWsfTkzH71jEMdFAbdaH1gcYdPIddXko9jx50f4vfKOvZlTEh3piMuIRXjgxOe4w13mGdXJsWHKUemKBTBOZDknXtV88Avn3A1+DntFDWTSNHai88JS8wTtwj8VGV6geimdMBGQm1RTU996cjVSnv+0TRVzyqsv/449ido10EPKQw0SJ1AFr+cl9aJ11yniAGMNpIunYYGM5DWILNH39oDlve2TeG2GhFL7Lzvl0aTgC88dJTCVYLbM30HO/PwjqXw9lYNyERtOUR2eMMlRBrbhG7FZp/iW1wpbir5tOO2/Q4/ZPug0ZYEuQJpGDSUQgr9cLECPD9BqGKtjPm0/Aif96FIl4HMPh5rGrBYa3GpfTCRyhbCNX+QpfIq/4epOpj9zb4ZectFM8nnHPb1RTnRNL8jBQrZAlVpoKZwEBsQzW4BMvL2mceMEjPz/viZXi/rksmq63v8bVsCSEx+wVVRvbZtk8Q6P0nkPYSupO5+Wi3EkredGszkN2KkixYJHcFkwSscEYN9IIteCJJQjveh8EkoKBNHVEfh/o1nEqYg
DKIM-Signature: a=rsa-sha256; bh=qgxp9JUvBhn9rB5VsxLIqx1c2ElEewxhPrQYLLC8PSg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676234; v=1;
 b=QTX+L5oUiDz9fb6Pfi/gnCfeez8Gvj68o6IEsQp0gGLKnC06viyyM9sRs3awrFezjZGW8ODu
 CL6hSgjAQxGRyAPPdb7Kd57oJYNXtAd3JlIQLMJC75N4bqVCSm26w8nOZJd2fP+QNDm9PgXIkLl
 lqVY+iilQ9x0s+JNUlxyigFe0MBxaMSzoVVWQtLOyuMjsYx/hvKApwxrHdahMotmVPisqxh71fj
 /u0VJ7eCXZDc/ovVU1Km4VKLqPgiMWUgDyVf3FF1DN1mhxa4Eo3N1Eb5fAg1eJTTT6tAzRAeE6q
 jLl9ExmUj3jqGCpDrLt77RmBECHeRyhBr9TJdNMJ4SJbg==
X-purgate-ID: tlsNG-4011c0/1785676234-5A5DBCFC-C1D39C19/0/0
X-purgate-type: clean
X-purgate-size: 11255

From: Krystian Hebel <krystian.hebel@3mdeb.com>

On Intel TXT, APs are started in one of two ways, depending on ACM
which reports it in its information table. In both cases, all APs are
started simultaneously after BSP requests them to do so. Two possible
ways are:
- GETSEC[WAKEUP] instruction,
- MONITOR address.

GETSEC[WAKEUP] requires versions >= 7 of SINIT to MLE Data, but there is
no clear mapping of that version with regard to processor family and
it's not known which CPUs actually use it. It could have been designed
for TXT support on CPUs that lack MONITOR/MWAIT, because GETSEC[WAKEUP]
seems to be more complicated, in software and hardware alike.

This patch implements only MONITOR approach, GETSEC[WAKEUP] support will
be added later once more details and means of testing are available and
if there is a practical need for it.

With this patch, every AP goes through assembly part, and only when in
start_secondary() in C they re-enter MONITOR/MWAIT iff they are not the
AP that was asked to boot. The same address is reused for simplicity,
and on next wakeup call APs don't have to go through assembly part
again (GDT, paging, stack setting).

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Szymon Acedański <accek@invisiblethingslab.com>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Michał Iwanicki <michal.iwanicki@3mdeb.com>
---

Notes:
    v4: replace TXT_AP_BOOT_CS and TXT_AP_BOOT_DS with trampoline_gdt_txt and computing CS
    v4: make APs call C from __high_start to synchronize with BSP
    v4: recheck condition between `monitor` and `mwait` instructions
    v4: write to wakeup address only once (all APs are woken up at once)
    v4: make JOIN variable static as it's not read synchronously
    v4: when an AP waits for a wakeup, monitor the variable that's expected to change

 xen/arch/x86/boot/trampoline.S       | 19 ++++++-
 xen/arch/x86/boot/x86_64.S           | 24 ++++++++-
 xen/arch/x86/include/asm/intel-txt.h |  5 ++
 xen/arch/x86/include/asm/processor.h |  1 +
 xen/arch/x86/smpboot.c               | 75 ++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/asm-offsets.c    |  3 ++
 6 files changed, 125 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 9306c1bb76..4208bd75b8 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -58,6 +58,16 @@ GLOBAL(entry_SIPI16)
         ljmpl   $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6)
 
         .code32
+GLOBAL(txt_ap_entry)
+        /*
+         * APs enter here in protected mode without paging. GDT is set in JOIN
+         * structure, it points to trampoline_gdt. Interrupts are disabled by
+         * TXT (including NMI and SMI), so IDT doesn't matter at this point.
+         * The only missing point is telling that we are AP by saving non-zero
+         * value in EBX.
+         */
+        mov     $1, %ebx
+
 trampoline_protmode_entry:
         /* Set up a few descriptors: on entry only CS is guaranteed good. */
         mov     $BOOT_DS,%eax
@@ -145,7 +155,7 @@ start64:
         .word   0
 idt_48: .word   0, 0, 0 # base = limit = 0
 
-trampoline_gdt:
+GLOBAL(trampoline_gdt)
         .word   0                  /* 0x0000: unused (reused for GDTR) */
 gdt_48:
         .word   .Ltrampoline_gdt_end - trampoline_gdt - 1
@@ -156,6 +166,13 @@ gdt_48:
         .quad   0x00cf93000000ffff /* 0x0018: ring 0 data */
         .quad   0x00009b000000ffff /* 0x0020: real-mode code @ BOOT_TRAMPOLINE */
         .quad   0x000093000000ffff /* 0x0028: real-mode data @ BOOT_TRAMPOLINE */
+        /*
+         * Intel TXT requires these two in exact order. This isn't compatible
+         * with the order required by syscall, so we have duplicated entries...
+         */
+GLOBAL(trampoline_gdt_txt)
+        .quad   0x00cf9b000000ffff /* 0x0030: ring 0 code, 32-bit mode */
+        .quad   0x00cf93000000ffff /* 0x0038: ring 0 data */
 .Ltrampoline_gdt_end:
 
         /* Relocations for trampoline Real Mode segments. */
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 19f3062a7b..886960c22f 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -30,7 +30,10 @@ ENTRY(__high_start)
         cmp     %ebp, (%rcx, %rax, 4)
         jne     1b
 
-        /* %eax is now Xen CPU index. */
+        mov     %ebp, %edx
+
+        /* %eax is now Xen CPU index, %edx is APIC ID. */
+
         lea     stack_base(%rip), %rcx
         mov     (%rcx, %rax, 8), %rsp
 
@@ -40,6 +43,25 @@ ENTRY(__high_start)
 1:
         add     $(STACK_SIZE - CPUINFO_sizeof), %rsp
 
+        /*
+         * TXT AP gate.
+         *
+         * In TXT boot, SINIT releases all APs at once and they race into
+         * __high_start in parallel. We serialize APs initialization here
+         * to force them waking up in order expected by the BSP.
+         *
+         * The gate must be placed before STACK_CPUINFO_FIELD(cr4) is written
+         * below: for each AP, the BSP memsets that AP's cpu_info struct in
+         * cpu_smpboot_alloc() just before releasing it through the gate, so
+         * anything written earlier would be clobbered.
+         *
+         * In non-TXT boot, APs wake one-by-one via SIPI.
+         */
+        cmpl    $ASM_AP_BOOT_TXT, ap_boot_method(%rip)
+        jne     .L_after_stack_setup
+        mov     %edx, %edi
+        call    txt_ap_gate
+
 .L_after_stack_setup:
 
         /* Reset EFLAGS (subsumes CLI and CLD). */
diff --git a/xen/arch/x86/include/asm/intel-txt.h b/xen/arch/x86/include/asm/intel-txt.h
index 8bcca20d6e..eb15bf68ad 100644
--- a/xen/arch/x86/include/asm/intel-txt.h
+++ b/xen/arch/x86/include/asm/intel-txt.h
@@ -83,6 +83,11 @@
 #define _txt(x) __va(x)
 #endif
 
+extern char txt_ap_entry[];
+extern uint64_t trampoline_gdt[];
+/* Points at CS selector for TXT, DS selector follows. */
+extern uint64_t trampoline_gdt_txt[];
+
 /*
  * Always use private space as some of registers are either read-only or not
  * present in public space.
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 8ca6799a81..2c6e7b772f 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -436,6 +436,7 @@ void set_in_pb_opt_ctrl(uint32_t mask, uint32_t val);
 enum ap_boot_method {
     AP_BOOT_NORMAL,
     AP_BOOT_SKINIT,
+    AP_BOOT_TXT,
 };
 extern enum ap_boot_method ap_boot_method;
 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 84e9e4beed..cdad60d5e4 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -30,6 +30,7 @@
 #include <asm/flushtlb.h>
 #include <asm/guest.h>
 #include <asm/idt.h>
+#include <asm/intel-txt.h>
 #include <asm/io_apic.h>
 #include <asm/irq-vectors.h>
 #include <asm/mc146818rtc.h>
@@ -38,6 +39,7 @@
 #include <asm/mtrr.h>
 #include <asm/prot-key.h>
 #include <asm/setup.h>
+#include <asm/slaunch.h>
 #include <asm/spec_ctrl.h>
 #include <asm/stubs.h>
 #include <asm/tboot.h>
@@ -239,6 +241,32 @@ static void smp_callin(void)
         cpu_relax();
 }
 
+/*
+ * ACPI ID of the AP to be released by txt_ap_gate() next.  Gets set in
+ * wake_ap_in_txt() after which do_boot_cpu() waits for the AP to initialize
+ * itself.
+ */
+static int txt_booting_apicid;
+
+void asmlinkage txt_ap_gate(int apicid)
+{
+    uint64_t misc_enable;
+
+    /* TXT released us with MONITOR disabled in IA32_MISC_ENABLE. */
+    misc_enable = rdmsr(MSR_IA32_MISC_ENABLE);
+    wrmsr(MSR_IA32_MISC_ENABLE,
+          misc_enable | MSR_IA32_MISC_ENABLE_MONITOR_ENABLE);
+
+    while ( txt_booting_apicid != apicid )
+    {
+        asm volatile ( "monitor"
+                       :: "a"(&txt_booting_apicid), "c"(0), "d"(0) : "memory" );
+        if ( txt_booting_apicid == apicid )
+            break;
+        asm volatile ( "mwait" :: "a"(0), "c"(0) );
+    }
+}
+
 /* CPUs for which sibling maps can be computed. */
 static cpumask_t cpu_sibling_setup_map;
 
@@ -417,6 +445,37 @@ void asmlinkage start_secondary(void)
     startup_cpu_idle_loop();
 }
 
+static int wake_ap_in_txt(int phys_apicid)
+{
+    static uint32_t join[4];
+
+    txt_booting_apicid = phys_apicid;
+    smp_mb();
+
+    /*
+     * All APs are released at the same time on the first write to wakeup
+     * address, which happens on the first invocation.  Because the write isn't
+     * handled synchronously, the JOIN structure must outlive this function.
+     */
+    if (join[0] == 0)
+    {
+        const struct txt_sinit_mle_data *sinit_mle =
+            txt_start(__va(txt_read(TXTCR_HEAP_BASE)), TXT_SINIT2MLE);
+        uint32_t *wakeup_addr = __va(sinit_mle->rlp_wakeup_addr);
+
+        join[0] = trampoline_gdt[0] >> 32;                   /* GDT limit */
+        join[1] = bootsym_phys(trampoline_gdt);              /* GDT base */
+        join[2] = (trampoline_gdt_txt - trampoline_gdt) * 8; /* CS selector */
+                                                             /* DS = CS + 8 */
+        join[3] = bootsym_phys(txt_ap_entry);                /* EIP */
+
+        txt_write(TXTCR_MLE_JOIN, __pa(join));
+        *wakeup_addr = 1;
+    }
+
+    return 0;
+}
+
 static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
 {
     unsigned long send_status = 0, accept_status = 0;
@@ -439,6 +498,9 @@ static int wakeup_secondary_cpu(int phys_apicid, unsigned long start_eip)
     if ( tboot_in_measured_env() && !tboot_wake_ap(phys_apicid, start_eip) )
         return 0;
 
+    if ( ap_boot_method == AP_BOOT_TXT )
+        return wake_ap_in_txt(phys_apicid);
+
     /*
      * Be paranoid about clearing APIC errors.
      */
@@ -1165,6 +1227,13 @@ static struct notifier_block cpu_smpboot_nfb = {
 
 void __init smp_prepare_cpus(void)
 {
+    /*
+     * If the platform is performing a Secure Launch via TXT, secondary
+     * CPUs (APs) will need to be woken up in a TXT-specific way.
+     */
+    if ( slaunch_active && boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        ap_boot_method = AP_BOOT_TXT;
+
     register_cpu_notifier(&cpu_smpboot_nfb);
 
     mtrr_aps_sync_begin();
@@ -1454,6 +1523,12 @@ void __init smp_cpus_done(void)
 
     mtrr_save_state();
     mtrr_aps_sync_end();
+
+    /*
+     * After the initial startup the DRTM-specific method for booting APs
+     * should no longer be used unless DRTM sequence is started again.
+     */
+    ap_boot_method = AP_BOOT_NORMAL;
 }
 
 void __init smp_intr_init(void)
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index f0aaf0f4ba..94f2995fff 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -246,4 +246,7 @@ void __dummy__(void)
     DEFINE(SL_EIR_size,     sizeof(struct slaunch_early_init_results));
     BLANK();
 #endif
+
+    DEFINE(ASM_AP_BOOT_TXT, AP_BOOT_TXT);
+    BLANK();
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380752.1624475 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4S-0003ww-Dp; Sun, 02 Aug 2026 13:17:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380752.1624475; Sun, 02 Aug 2026 13:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4S-0003wo-AS; Sun, 02 Aug 2026 13:17:40 +0000
Received: by outflank-mailman (input) for mailman id 1380752;
 Sun, 02 Aug 2026 13:17:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4R-0003uD-0U
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4Q-001yKT-DN
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:38 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4331-5cb7-0a2a0a5109dd-0a2a45099578-26
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:38 +0200
Received: from [46.105.50.107] (helo=6.mo576.mail-out.ovh.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41cc-be1a-0a2a45090019-2e69326b862f-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:37 +0200
Received: from director8.ghost.mail-out.ovh.net (unknown [10.110.58.216])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCc5yvcz5wtD
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:36 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-j8ww2 (unknown [10.110.178.62])
 by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 35CFAC011C;
 Sun,  2 Aug 2026 13:10:36 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-7d8d68f679-j8ww2 with ESMTPSA
 id EbDxBMxBb2oerBcAMfbduw
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-101G0047759a04e-fb70-40cd-9ab5-d3d0ce46f05c,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 18/23] x86/slaunch: process DRTM policy
Date: Sun,  2 Aug 2026 16:09:34 +0300
Message-ID: <61c6b09b209572b5db6d8a17cf050f68a19b7ebe.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4741164507921524156
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEtK5p0SNYtBef44Zaajhk33i63wmjVwNNhJ4YROChk7mhZcpyT3bd5ACP3F2TkAykP416Z/qj7tU2KxG1rTRS8MypF1KRhaA/AvmFdmp6hM2n75hgvTPUkRMkZtHtCy5BQJTDAa5dye2uRhTva5lFRUMRQoQfXqDmPkoEsCcMiOXhj8LDb8bxT7fPbPw+L6oM3Ib4+Crk5z3znR8b12WvIauAwvZwi4TwyXrVt8t5cjjf6p6tk/jAP3JPPWAt8lJLbOqKqZPj2dLVv8AcggN/kQjhcbgaHkG9r5s4innAGR9o3gaGzW+PeUVjPnviytxFmoTk+gQnhQiwpJq7s595nY/XulObR4LpT8CCnpFEKUXa8Q3HNZgL1ABzJpjIi1J6AUI57hEg5iL0XtsQM1M+2lwUzz8WW8LK669P7w3SID8V/gy/GOVLQWv88pspKZVplcVpcw/OCEK21n1+RL2t3IPTGZl78dGk0Htq+5ZfF7n4xhyrK4aAg/Vd7dWF4m2RJsQDJQnJAvAhWs4FxAd3pjzjuzmMB5u+AF7fvUu5R+z0lmqSHRdb0GqFkFVeKvRpRvcUzamB/r6Jl4+/tzbTTC/r97Sfvu7DdVAKge/g72zDlT0RAfnvTa4D+hshw3iWYXAw2IsinFQ1BTuG8KcwyXlH+MuaardKsCrc0TihXkQ
DKIM-Signature: a=rsa-sha256; bh=sgRLfUyi0AEtYRpb6nOFpLTPu2chdJ1AVrx0RK+bMno=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676236; v=1;
 b=WrKYoVoD8NTgJd2b0KnhR1cP1AyahlmdQGt5/3qbSXT0R91MCJa5rJqxSNy2vqrasIkV+IgL
 +3G1s+2hX50sa1/gdsaB6o4XfeP63a9W64gZa6ytyFSDZih9HHfZ8RSDHi2gZb8oDOpWeOu4NPM
 uaC/f3qAWqpYBiw7aQyyjEVsM80ElMWUtQAuUKsYSiJ0xkZbCKWtbzYW5vLeOfnBIQ2kiL7n1O6
 3fHMOYdq5Hya6OcQcgP3bKRKzV/iRCw97UKggyQTCp0JhmaTQPL/doZZ5GyZxra0FAMLIQg0GNb
 8zKNDCOT71xRgp7189A9Ncci8RhAKHtaGUNDuTkloO8EA==
X-purgate-ID: tlsNG-bad1c0/1785676237-3AAD8034-8AF45364/0/0
X-purgate-type: clean
X-purgate-size: 11877

Go through entires in the DRTM policy of SLRT to hash and extend data
that they describe into corresponding PCRs.

Addresses are being zeroed on measuring platform-specific data to
prevent measurements from changing when the only thing that has changed
is an address.  Addresses can vary due to bootloader, firmware or user
doing something differently or just if GRUB gets bigger in size due to
inclusion of more modules and ends up offsetting newly allocated memory.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: use SLR_TABLE_REVISION in slaunch_measure_slrt()
    v4: don't cast away const of slr_next_entry_by_tag()
    v4: use container_of()
    v4: take changes of `struct boot_module` into account

 xen/arch/x86/include/asm/slaunch.h |  14 ++
 xen/arch/x86/setup.c               |  15 ++
 xen/arch/x86/slaunch.c             | 217 +++++++++++++++++++++++++++++
 3 files changed, 246 insertions(+)

diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 65aab01f04..1b2c5957e4 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -31,6 +31,8 @@
 #define DLE_EVTYPE_SLAUNCH_START   (DLE_EVTYPE_BASE + 0x103)
 #define DLE_EVTYPE_SLAUNCH_END     (DLE_EVTYPE_BASE + 0x104)
 
+struct boot_info;
+
 struct slaunch_early_init_results
 {
     uint32_t mbi_pa;
@@ -67,6 +69,18 @@ void slaunch_map_mem_regions(void);
 /* Marks regions of memory as used to avoid their corruption. */
 void slaunch_reserve_mem_regions(void);
 
+/* Measures essential parts of SLR table before making use of them. */
+void slaunch_measure_slrt(void);
+
+/*
+ * Takes measurements of DRTM policy entries except for MBI and SLRT which
+ * should have been measured by the time this is called. Also performs sanity
+ * checks of the policy and panics on failure. In particular, the function
+ * verifies that DRTM is consistent with modules obtained from MultibootInfo
+ * (MBI) and written to struct boot_info in setup.c.
+ */
+void slaunch_process_drtm_policy(const struct boot_info *bi);
+
 /*
  * This helper function is used to map memory below 4 GiB using L2 page tables
  * by aligning mapped regions to 2MB. This way page allocator (which at this
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index fbc44b0174..fd712d69e3 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1473,6 +1473,13 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( slaunch_active )
     {
         slaunch_map_mem_regions();
+
+        /*
+         * SLRT needs to be measured here because it is used by init_e820(), the
+         * rest is measured slightly below by slaunch_process_drtm_policy().
+         */
+        slaunch_measure_slrt();
+
         slaunch_reserve_mem_regions();
     }
 
@@ -1494,6 +1501,14 @@ void asmlinkage __init noreturn __start_xen(void)
     /* Create a temporary copy of the E820 map. */
     memcpy(&boot_e820, &e820, sizeof(e820));
 
+    /*
+     * Process all yet unmeasured DRTM entries after E820 initialization to not
+     * do this while memory is uncached (too slow). This must also happen before
+     * modules are relocated or used.
+     */
+    if ( slaunch_active )
+        slaunch_process_drtm_policy(bi);
+
     /* Early kexec reservation (explicit static start address). */
     nr_pages = 0;
     for ( i = 0; i < e820.nr_map; i++ )
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index 83dce3d57d..ac62301f93 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -7,14 +7,17 @@
 
 #include <xen/compiler.h>
 #include <xen/init.h>
+#include <xen/kernel.h>
 #include <xen/macros.h>
 #include <xen/mm.h>
 #include <xen/sections.h>
 #include <xen/types.h>
 
+#include <asm/bootinfo.h>
 #include <asm/e820.h>
 #include <asm/intel-txt.h>
 #include <asm/page.h>
+#include <asm/processor.h>
 #include <asm/setup.h>
 #include <asm/slaunch.h>
 #include <asm/slaunch-tpm.h>
@@ -114,6 +117,220 @@ void __init slaunch_reserve_mem_regions(void)
     }
 }
 
+void __init slaunch_measure_slrt(void)
+{
+    struct slr_table *slrt = slaunch_get_slrt();
+
+    if ( slrt->revision == SLR_TABLE_REVISION )
+    {
+        const struct slr_entry_hdr *entry;
+
+        /*
+         * In revision one of the SLRT, only platform-specific info table is
+         * measured.
+         */
+        struct slr_entry_intel_info tmp;
+
+        entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+        if ( entry == NULL )
+            panic("SLRT is missing Intel-specific information!\n");
+
+        tmp = *container_of(entry, const struct slr_entry_intel_info, hdr);
+        tmp.boot_params_base = 0;
+        tmp.txt_heap = 0;
+
+        slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                            sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+    }
+    else
+    {
+        /*
+         * slaunch_get_slrt() checks that the revision is valid, so we must not
+         * get here unless the code is wrong.
+         */
+        panic("Unhandled SLRT revision: %d!\n", slrt->revision);
+    }
+}
+
+static const struct slr_entry_policy *__init
+slr_get_policy(const struct slr_table *slrt)
+{
+    const struct slr_entry_hdr *entry;
+    const struct slr_entry_policy *policy;
+
+    entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DRTM_POLICY);
+    if (entry == NULL)
+        panic("SLRT is missing DRTM policy!\n");
+
+    policy = container_of(entry, const struct slr_entry_policy, hdr);
+
+    /* XXX: are newer revisions allowed? */
+    if ( policy->revision != SLR_POLICY_REVISION )
+        panic("DRTM policy in SLRT is of unsupported revision: %#04x!\n",
+              slrt->revision);
+
+    return policy;
+}
+
+static void __init
+check_slrt_policy_entry(struct slr_policy_entry *policy_entry,
+                        int idx,
+                        const struct slr_table *slrt)
+{
+    if ( policy_entry->entity_type != SLR_ET_SLRT )
+        panic("Expected DRTM policy entry #%d to describe SLRT, got %#04x!\n",
+              idx, policy_entry->entity_type);
+    if ( policy_entry->pcr != DRTM_DATA_PCR )
+        panic("SLRT was measured to PCR-%d instead of PCR-%d!\n", DRTM_DATA_PCR,
+              policy_entry->pcr);
+    if ( policy_entry->entity != (uint64_t)__pa(slrt) )
+        panic("SLRT address (%#08lx) differs from its DRTM entry (%#08lx)\n",
+              __pa(slrt), policy_entry->entity);
+}
+
+/* Returns number of policy entries that were already measured. */
+static unsigned int __init
+check_drtm_policy(const struct slr_table *slrt,
+                  const struct slr_entry_policy *policy,
+                  struct slr_policy_entry *policy_entry,
+                  const struct boot_info *bi)
+{
+    uint32_t i;
+    uint32_t num_mod_entries;
+
+    if ( policy->nr_entries < 2 )
+        panic("DRTM policy in SLRT contains less than 2 entries (%d)!\n",
+              policy->nr_entries);
+
+    /*
+     * MBI policy entry must be the first one, so that measuring order matches
+     * policy order.
+     */
+    if ( policy_entry[0].entity_type != SLR_ET_MULTIBOOT2_INFO )
+        panic("First entry of DRTM policy in SLRT is not MBI: %#04x!\n",
+              policy_entry[0].entity_type);
+    if ( policy_entry[0].pcr != DRTM_DATA_PCR )
+        panic("MBI was measured to %d instead of %d PCR!\n", DRTM_DATA_PCR,
+              policy_entry[0].pcr);
+
+    /* SLRT policy entry must be the second one. */
+    check_slrt_policy_entry(&policy_entry[1], 1, slrt);
+
+    for ( i = 0; i < bi->nr_modules; i++ )
+    {
+        uint16_t j;
+        const struct boot_module *mod = &bi->mods[i];
+
+        if (mod->arch.relocated || mod->arch.released)
+        {
+            panic("Multiboot module \"%s\" (at %d) was consumed before measurement\n",
+                  (const char *)__va(mod->arch.cmdline_pa), i);
+        }
+
+        for ( j = 2; j < policy->nr_entries; j++ )
+        {
+            if ( policy_entry[j].entity_type != SLR_ET_MULTIBOOT2_MODULE )
+                continue;
+
+            if ( policy_entry[j].entity == mod->start &&
+                 policy_entry[j].size == mod->size )
+                break;
+        }
+
+        if ( j >= policy->nr_entries )
+        {
+            panic("Couldn't find Multiboot module \"%s\" (at %d) in DRTM of Secure Launch\n",
+                  (const char *)__va(mod->arch.cmdline_pa), i);
+        }
+    }
+
+    num_mod_entries = 0;
+    for ( i = 0; i < policy->nr_entries; i++ )
+    {
+        if ( policy_entry[i].entity_type == SLR_ET_MULTIBOOT2_MODULE )
+            num_mod_entries++;
+    }
+
+    if ( bi->nr_modules != num_mod_entries )
+    {
+        panic("Unexpected number of Multiboot modules: %d instead of %d\n",
+              (int)bi->nr_modules, (int)num_mod_entries);
+    }
+
+    /*
+     * MBI was measured in slaunch_measure_mbi().
+     * SLRT was measured in slaunch_measure_slrt().
+     */
+    return 2;
+}
+
+void __init slaunch_process_drtm_policy(const struct boot_info *bi)
+{
+    const struct slr_table *slrt;
+    const struct slr_entry_policy *policy;
+    struct slr_policy_entry *policy_entry;
+    uint16_t i;
+    unsigned int measured;
+
+    slrt = slaunch_get_slrt();
+
+    policy = slr_get_policy(slrt);
+    policy_entry = (void *)policy + sizeof(*policy);
+
+    measured = check_drtm_policy(slrt, policy, policy_entry, bi);
+    for ( i = 0; i < measured; i++ )
+        policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
+
+    for ( i = measured; i < policy->nr_entries; i++ )
+    {
+        int rc;
+        uint64_t start = policy_entry[i].entity;
+        uint64_t size = policy_entry[i].size;
+
+        /* No already measured entries are expected here. */
+        if ( policy_entry[i].flags & SLR_POLICY_FLAG_MEASURED )
+            panic("DRTM entry at %d was measured out of order!\n", i);
+
+        switch ( policy_entry[i].entity_type )
+        {
+        case SLR_ET_MULTIBOOT2_INFO:
+            panic("Duplicated MBI entry in DRTM of Secure Launch at %d\n", i);
+        case SLR_ET_SLRT:
+            panic("Duplicated SLRT entry in DRTM of Secure Launch at %d\n", i);
+
+        case SLR_ET_UNSPECIFIED:
+        case SLR_ET_BOOT_PARAMS:
+        case SLR_ET_SETUP_DATA:
+        case SLR_ET_CMDLINE:
+        case SLR_ET_UEFI_MEMMAP:
+        case SLR_ET_RAMDISK:
+        case SLR_ET_MULTIBOOT2_MODULE:
+        case SLR_ET_TXT_OS2MLE:
+            /* Measure this entry below. */
+            break;
+
+        case SLR_ET_UNUSED:
+            /* Skip this entry. */
+            continue;
+        }
+
+        if ( policy_entry[i].flags & SLR_POLICY_IMPLICIT_SIZE )
+            panic("Unexpected implicitly-sized DRTM entry of Secure Launch at %d (type %d, info: %s)\n",
+                  i, policy_entry[i].entity_type, policy_entry[i].evt_info);
+
+        rc = slaunch_map_l2(start, size);
+        BUG_ON(rc != 0);
+
+        slaunch_hash_extend(DRTM_LOC, policy_entry[i].pcr, __va(start), size,
+                            DLE_EVTYPE_SLAUNCH,
+                            (uint8_t *)policy_entry[i].evt_info,
+                            strnlen(policy_entry[i].evt_info,
+                                    TPM_EVENT_INFO_LENGTH));
+
+        policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
+    }
+}
+
 int __init slaunch_map_l2(paddr_t paddr, size_t size)
 {
     unsigned long aligned_paddr = paddr & ~((1ULL << L2_PAGETABLE_SHIFT) - 1);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380753.1624485 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4U-0004DF-NA; Sun, 02 Aug 2026 13:17:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380753.1624485; Sun, 02 Aug 2026 13:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4U-0004D6-Ig; Sun, 02 Aug 2026 13:17:42 +0000
Received: by outflank-mailman (input) for mailman id 1380753;
 Sun, 02 Aug 2026 13:17:41 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4T-0004AU-Mx
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4T-00Bn6b-3r
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:41 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f431e-bab6-0a2a0a5309dd-0a2a4505b1b4-44
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:40 +0200
Received: from [178.33.253.26] (helo=3.mo582.mail-out.ovh.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41cf-4cb1-0a2a45050019-b221fd1ab33f-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:40 +0200
Received: from director11.ghost.mail-out.ovh.net (unknown [10.110.43.238])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCg58b5z5yC2
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:39 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-t7wcg (unknown [10.108.42.75])
 by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 13768C28DA;
 Sun,  2 Aug 2026 13:10:38 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.100])
 by ghost-submission-7d8d68f679-t7wcg with ESMTPSA
 id 2d6ZLs5Bb2o8SwgAPH/TWw
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-100R00335e8ac6c-444d-4ca3-86c0-9dcadff2c860,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 19/23] x86/acpi: disallow S3 on Secure Launch boot
Date: Sun,  2 Aug 2026 16:09:35 +0300
Message-ID: <92105cb825fd258f9236291c3dadb64a20c8e325.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4742008934594782652
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTF70AoUNTuq0lE163/HHHmITb2k71K2uLoI2ZNhSgyl66wu8n/QJYzc+NLLaUb0uP1TrkyCR/9L8Ilu8caNGFiWNKPhk8LryKkv9xxZSrEN1zqyUGrQN6nXky3jMJxzdN9g/O0CtTLwNhHfleReQxYNqzRPBHWIFmbNp+cZCBU9E3JqDvY2G2n8Fq8vuRNzFdlGIcwMaDxCbm3ZzhQ1uRn2km7gAWfvABUN0yPDoQrFrCjLaFwKnQdy3a/cfWa0gHDTshjKSe3BdNtt7392P9RjMTs2j3tG0nmovZ410v/2dE5urrhoo3isYDb0H1B5YfdyZsu/PJWc0DbUySgFmJKBWyyZ4p7OpoRv65vjlPO59tPusQpx1aMuOo83eyN3/z2B2mBiu7FmwCv1GODqRHfVtGZspfbAWPCRt62XbVidum0ZJIV0fYl/IHNBD8BUtjMSCMxbE8xP+IoIAB6AEBNnCJpQ8Reiks6gAi4SokCBCRjJAL8Ju7Z+ZniFrpo8t3NQwgY5XgQW+2XwxfGK9/D/OQMB9UIgonZzSfT00gHF/Mq1II2sJU7M79UXISx7I+ivnTh/ezcYTErqNAmQ4cRQUijC/g5UXHPihvDoRinLYRWPkve8j9wxolh7pjw7M3oq2pNO0quutIfljaMyHE+i04tIHFhyIQ+1NyntYDA96w
DKIM-Signature: a=rsa-sha256; bh=6fGDnMoWwU0eNwEZq3/rY7JMw/amuue+vbvojSoNGps=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676239; v=1;
 b=XAVgBwBn3mcCQLaaRUrWtcsnk5+PL7bcDzCnNyqRC689m+c5P7ieywqkIr0HVV/dsZAUgBqQ
 qDYeyZOSagve3H1tNTRoqk4TBiw0HK0yEhpcuX+u78mbPiMdX7TrThipYiBWstS3KN/zjcXNPdR
 w/l8MBPeItTfYAUYt/zEWBtUmDyGfWhbHRoKPgH4Mqno3EyXG3cxf4csjSjF+J+2dkcEcoH86RH
 24vCj06k8NAHiRTXEgDITKI2lgTlFu5KxPsZwzxZ++M20RG8sAX6mbm7vZEkcR83XwTyn4gb20h
 GFhbEYemj1iQpYISq4nbLEDlRAgHa+CDkAL3cF/2yyPZg==
X-purgate-ID: tlsNG-c201ff/1785676240-72AB72A1-BA984278/0/0
X-purgate-type: clean
X-purgate-size: 1335

Secure Launch won't initiate DRTM on S3 resume (the code for starting
DRTM is not part of Xen), so abort a request to perform S3 suspend to
not lose the state of DRTM PCRs.

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: return EACCES instead of EPERM

 xen/arch/x86/acpi/power.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 3452650a61..8428766f82 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -30,6 +30,7 @@
 #include <asm/microcode.h>
 #include <asm/mwait.h>
 #include <asm/prot-key.h>
+#include <asm/slaunch.h>
 #include <asm/spec_ctrl.h>
 #include <asm/tboot.h>
 #include <asm/trampoline.h>
@@ -335,6 +336,13 @@ int acpi_enter_sleep(const struct xenpf_enter_acpi_sleep *sleep)
            PAGE_SIZE - acpi_sinfo.vector_width / 8)) )
         return -EOPNOTSUPP;
 
+    /* Secure Launch won't initiate DRTM on S3 resume, so abort S3 suspend. */
+    if ( sleep->sleep_state == ACPI_STATE_S3 && slaunch_active )
+    {
+        printk(XENLOG_INFO "SLAUNCH: refusing switching into ACPI S3 state.\n");
+        return -EACCES;
+    }
+
     if ( sleep->flags & XENPF_ACPI_SLEEP_EXTENDED )
     {
         if ( !acpi_sinfo.sleep_control.address ||
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380754.1624492 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4X-0004W5-Sx; Sun, 02 Aug 2026 13:17:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380754.1624492; Sun, 02 Aug 2026 13:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4X-0004Vt-PY; Sun, 02 Aug 2026 13:17:45 +0000
Received: by outflank-mailman (input) for mailman id 1380754;
 Sun, 02 Aug 2026 13:17:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4W-0004SK-HG
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4V-0084CP-UZ
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:43 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4326-2eae-0a2a0a5409dd-0a2a4502a226-20
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:43 +0200
Received: from [46.105.50.32] (helo=7.mo576.mail-out.ovh.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41d2-6ca4-0a2a45020019-2e69322087e5-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:43 +0200
Received: from director4.ghost.mail-out.ovh.net (unknown [10.110.37.160])
 by mo576.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCk4CqMz5xWq
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:42 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-vv62g (unknown [10.110.101.105])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id BB4C4C21CD;
 Sun,  2 Aug 2026 13:10:41 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.98])
 by ghost-submission-7d8d68f679-vv62g with ESMTPSA
 id TOywHtFBb2rWuxsAGKqLvg
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-98R002ed3048ef-d622-49d2-a4d0-e16ccb5bdd2c,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 20/23] x86/slaunch: support AMD CPUs
Date: Sun,  2 Aug 2026 16:09:36 +0300
Message-ID: <280c41d0b12c3b218d8e70d830bafdfb64229468.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4742853359210603964
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTErXTMJAFd1A/dXmS31doF3eHiFwFavtbE0IdxSAxcjBkbm/Y2r8C0ugmNxHgh0ttjc9HcWB48DtmHsboYn+R8rGouoQtvWBvuW7UoEIxsUWbq/tHAG5l0RfFjNSyhC5/+eLgR0uRIXbClVnnLU0J/e2MH+H41gFQHMN7aHv5oF4XCxU6iBwYAbzZv3Yhh++GCTcK0XOcSHoKOpYkiLjzaWT2sDXaneeSXeAAfPIRWbR3tUvr9IWTEkcXdO9/v8flsgALJWAnTuyhJyR7xa7rElw4l9ZKZPp4F7IlSUp4UkO78BMUlmU3YvvPg7A/cDjWsr7oy1auF5nv72TyzhOj1kDLdIeqJa7OzYeh91R/AocqDNmP5GASH8TFSHubE5VjyP9gMe4ZKnoHLpohQNQN2MHYJ1BuQVvUrb1hUQ4RDRfY6CGUtI1G07rhyLjykDaObJxD+JHh8JfAZkQkVrOH0OsNzG8P2+vBLXnSDHOnTIfcnUcR3Nur9/0aWKN9W29FAibtNgB96b+HwuTsB1M0XywD/ifhwZV5EfClFdqOOqql/pWPtrM/TN9g8f1WAkumTfEG//+bvzGto2Qyfe+a8hEQI9jiFC3J9zIRp9MJmXt04vs9MvIlD1tXWhM/3Pdp9now7DMQLQ+kM0W7bHhdqx6RcdLSqoAMuo6YybFJdxKw
DKIM-Signature: a=rsa-sha256; bh=NfKcGkd1fR1dcujpVOqhBYksRyhPEk+hlTYRJTUqPB0=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676242; v=1;
 b=cRFZV7xP76j7mOSRdfaC+q0j4Ue9TjdvQpcImSOiE70/uQ2hIS9GJH9/F47tEaReBnyKtxnL
 7gsk2jFPTa7YjnmNJazmDmGlq+GjX4wju02AMFoAB93TxtQIzbvmQ/g2A1nwDqKB59ODCYlVshr
 bt7Txs62NiS1/RyJGoep5ZWfNvxgQZqkXCRlqOAeRWP8uRGFrAZh2SZTbrfnJqwlunrf/dxNqp8
 zh2bPm/g6Zi67UrzFRWrsjcoOsHQTzfV/HiO84MHALbuRSrTEuAwOfM7t9Cxhl/RG1Ul4Agrl8E
 cm66mRTuSzs3qW6SXpeOXh5W+oQg8/yRi43PSgsBGSXlA==
X-purgate-ID: tlsNG-720697/1785676243-666B72AC-238E9B3C/0/0
X-purgate-type: clean
X-purgate-size: 17780

Handle the state after secure-kernel-loader (SKL) in boot/head.S.

Use slr_entry_amd_info::boot_params_base on AMD with SKINIT to get MBI
location.

Locate SLRT which is bootloader's data after SKL on AMD.

Measure AMD-specific data in slaunch_measure_slrt().

Find Intel-compatible TPM event log structure within vendor data of
TCG-compliant event logs.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: squashed "x86/slaunch: support AMD SKINIT" and "x86/boot/slaunch-early: find MBI and SLRT on AMD"
    v4: use CONFIG_SLAUNCH
    v4: update large comment in head.S
    v4: define slaunch_is_amd_drtm() in a header and use twice to avoid duplication
    v4: %#04x => %#x in panic("SLRT is for unexpected architecture ...")
    v4: use container_of()
    v4: don't drop `const` from the result of `slr_next_entry_by_tag()`

 xen/arch/x86/boot/head.S           | 42 ++++++++++++---
 xen/arch/x86/boot/slaunch-early.c  | 52 ++++++++++++++++++
 xen/arch/x86/e820.c                |  2 +-
 xen/arch/x86/include/asm/slaunch.h | 30 +++++++++++
 xen/arch/x86/include/asm/tpm1.h    | 15 ++++++
 xen/arch/x86/slaunch-tpm.c         | 26 +++++++++
 xen/arch/x86/slaunch.c             | 87 ++++++++++++++++++++++++------
 7 files changed, 231 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index ff46579904..bf38aef21c 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -358,10 +358,14 @@ cs32_switch:
 
 #if CONFIG_SLAUNCH
         /*
-         * Entry point for TrenchBoot Secure Launch on Intel TXT platforms.
+         * Entry point for TrenchBoot Secure Launch, common for Intel TXT and
+         * AMD Secure Startup, but state is slightly different.
+         *
+         * On Intel
+         * --------
          *
          * CPU is in 32b protected mode with paging disabled. On entry:
-         * - %ebx = %eip = MLE entry point,
+         * - %ebx = %eip = this entry point,
          * - stack pointer is undefined,
          * - CS is flat 4GB code segment,
          * - DS, ES, SS, FS and GS are undefined according to TXT SDG, but this
@@ -382,13 +386,36 @@ cs32_switch:
          *   writing a non-zero value at a MONITORed address or via
          *   GETSEC[WAKEUP] instruction, depending on which is supported by a
          *   given SINIT ACM
+         *
+         * On AMD (as implemented by TrenchBoot's secure-kernel-loader or SKL)
+         * -------------------------------------------------------------------
+         *
+         * CPU is in 32b protected mode with paging disabled. On entry:
+         * - %ebx = %eip = this entry point,
+         * - %ebp holds base address of SKL
+         * - stack pointer is treated as undefined for parity with TXT,
+         * - CS is flat 4GB code segment,
+         * - DS, ES, SS are flat 4GB data segments, but treated as undefined for
+         *   parity with TXT.
+         *
+         * Additional restrictions:
+         * - interrupts (including NMIs and SMIs) are disabled and must be
+         *   enabled later
+         * - APs must be brought up by SIPI without an INIT
          */
 slaunch_stub_entry:
         /* Calculate the load base address. */
         mov     %ebx, %esi
         sub     $sym_offs(slaunch_stub_entry), %esi
 
-        /* Mark Secure Launch boot protocol and jump to common entry. */
+        /* On AMD, %ebp holds the base address of SLB, save it for later. */
+        mov     %ebp, %ebx
+
+        /*
+         * Mark Secure Launch boot protocol and jump to common entry. Note that
+         * all general purpose registers except %ebx and %esi are clobbered
+         * between here and .Lslaunch_proto.
+         */
         mov     $SLAUNCH_BOOTLOADER_MAGIC, %eax
         jmp     .Lset_stack
 #endif /* CONFIG_SLAUNCH */
@@ -524,15 +551,18 @@ __start:
         sub     $SL_EIR_size, %esp
 
         push    %esp                              /* pointer to output structure */
+        push    %ebx                              /* Slaunch parameter on AMD */
         mov     $sym_offs(__2M_rwdata_end), %ecx  /* end of target image */
         mov     $sym_offs(_start), %edx           /* target base address */
         mov     %esi, %eax                        /* load base address */
         /*
-         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx, ret/stk) using
-         * fastcall calling convention.
+         * slaunch_early_init(load/eax, tgt/edx, tgt_end/ecx,
+         *                    slaunch/stk, ret/stk)
+         *
+         * Uses fastcall calling convention.
          */
         call    slaunch_early_init
-        add     $4, %esp                         /* pop the fourth parameter */
+        add     $8, %esp                         /* pop last two parameters */
 
         /* Move outputs of slaunch_early_init() from the stack. */
         pop     %ebx                  /* store physical MBI address in EBX where
diff --git a/xen/arch/x86/boot/slaunch-early.c b/xen/arch/x86/boot/slaunch-early.c
index 00c772cfdf..9b16602ac8 100644
--- a/xen/arch/x86/boot/slaunch-early.c
+++ b/xen/arch/x86/boot/slaunch-early.c
@@ -13,9 +13,23 @@
 #include <asm/intel-txt.h>
 #include <asm/slaunch.h>
 
+/*
+ * The AMD-defined structure layout for the SLB. The last two fields are
+ * SL-specific.
+ */
+struct skinit_sl_header
+{
+    uint16_t skl_entry_point;
+    uint16_t length;
+    uint8_t reserved[62];
+    uint16_t skl_info_offset;
+    uint16_t bootloader_data_offset;
+} __packed;
+
 void asmlinkage slaunch_early_init(uint32_t load_base_addr,
                                    uint32_t tgt_base_addr,
                                    uint32_t tgt_end_addr,
+                                   uint32_t slaunch_param,
                                    struct slaunch_early_init_results *result)
 {
     void *txt_heap;
@@ -26,6 +40,44 @@ void asmlinkage slaunch_early_init(uint32_t load_base_addr,
     const struct slr_entry_intel_info *intel_info;
     uint32_t size = tgt_end_addr - tgt_base_addr;
 
+    if ( slaunch_is_amd_drtm() )
+    {
+        /*
+         * Not an Intel CPU. Currently the only other option is AMD with SKINIT
+         * and secure-kernel-loader (SKL).
+         */
+        const struct slr_entry_amd_info *amd_info;
+        const struct skinit_sl_header *sl_header = (void *)slaunch_param;
+
+        /*
+         * slaunch_param holds a physical address of SLB.
+         * Bootloader's data is SLRT.
+         */
+        result->slrt_pa = slaunch_param + sl_header->bootloader_data_offset;
+
+        slrt = (struct slr_table *)(uintptr_t)result->slrt_pa;
+
+        entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_AMD_INFO);
+        if ( entry == NULL )
+        {
+            /* No reset mechanism or an error register on AMD. */
+            asm volatile ("ud2");
+            unreachable();
+        }
+
+        amd_info = container_of(entry, const struct slr_entry_amd_info, hdr);
+        /* Basic checks only, SKL checked and consumed the rest. */
+        if ( amd_info->hdr.size != sizeof(*amd_info) )
+        {
+            /* No reset mechanism or an error register on AMD. */
+            asm volatile ("ud2");
+            unreachable();
+        }
+
+        result->mbi_pa = amd_info->boot_params_base;
+        return;
+    }
+
     txt_heap = txt_init();
     os_mle = txt_start(txt_heap, TXT_OS2MLE);
     os_sinit = txt_start(txt_heap, TXT_OS2SINIT);
diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index c63b0b12cc..964a02384d 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -501,7 +501,7 @@ static void __init machine_specific_memory_setup(struct e820map *raw)
     uint64_t top_of_ram, size;
     unsigned int i;
 
-    if ( slaunch_active )
+    if ( slaunch_active && boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
         txt_restore_mtrrs(e820_verbose);
 
     sanitize_e820_map(raw->map, &raw->nr_map);
diff --git a/xen/arch/x86/include/asm/slaunch.h b/xen/arch/x86/include/asm/slaunch.h
index 1b2c5957e4..a9c009fa96 100644
--- a/xen/arch/x86/include/asm/slaunch.h
+++ b/xen/arch/x86/include/asm/slaunch.h
@@ -17,6 +17,8 @@
 #include <xen/slr-table.h>
 #include <xen/types.h>
 
+#include <asm/x86-vendors.h>
+
 #define DRTM_LOC                   2
 #define DRTM_CODE_PCR              17
 #define DRTM_DATA_PCR              18
@@ -56,6 +58,34 @@ static bool slaunch_active = false;
  */
 extern uint32_t slaunch_slrt;
 
+#ifdef __EARLY_SLAUNCH__
+
+static inline bool slaunch_is_amd_drtm(void)
+{
+    /*
+     * asm/processor.h can't be included in early code, which means neither
+     * cpuid() function nor boot_cpu_data can be used here.
+     */
+    uint32_t eax, ebx, ecx, edx;
+    asm volatile ( "cpuid"
+          : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
+          : "0" (0), "c" (0) );
+    return ebx == X86_VENDOR_AMD_EBX
+        && ecx == X86_VENDOR_AMD_ECX
+        && edx == X86_VENDOR_AMD_EDX;
+}
+
+#else   /* __EARLY_SLAUNCH__ */
+
+#include <asm/cpufeature.h>
+
+static inline bool slaunch_is_amd_drtm(void)
+{
+    return boot_cpu_data.x86_vendor == X86_VENDOR_AMD;
+}
+
+#endif  /* __EARLY_SLAUNCH__ */
+
 /*
  * Retrieves pointer to SLRT.  Checks table's validity and maps it as necessary.
  */
diff --git a/xen/arch/x86/include/asm/tpm1.h b/xen/arch/x86/include/asm/tpm1.h
index d1cb2cc041..57a60223ba 100644
--- a/xen/arch/x86/include/asm/tpm1.h
+++ b/xen/arch/x86/include/asm/tpm1.h
@@ -76,4 +76,19 @@ struct TPM12_PCREvent {
     uint8_t Data[];
 };
 
+struct tpm1_spec_id_event {
+    uint32_t pcrIndex;
+    uint32_t eventType;
+    uint8_t digest[20];
+    uint32_t eventSize;
+    uint8_t signature[16];
+    uint32_t platformClass;
+    uint8_t specVersionMinor;
+    uint8_t specVersionMajor;
+    uint8_t specErrata;
+    uint8_t uintnSize;
+    uint8_t vendorInfoSize;
+    uint8_t vendorInfo[0];  /* variable number of members */
+} __packed;
+
 #endif /* X86_TPM1_H */
diff --git a/xen/arch/x86/slaunch-tpm.c b/xen/arch/x86/slaunch-tpm.c
index e3b7341cc5..2f8e598706 100644
--- a/xen/arch/x86/slaunch-tpm.c
+++ b/xen/arch/x86/slaunch-tpm.c
@@ -79,6 +79,16 @@ create_log_event12(struct txt_ev_log_container_12 *evt_log,
     if (evt_log == NULL)
         return log_hashes;
 
+    if ( slaunch_is_amd_drtm() )
+    {
+        /*
+         * On AMD, TXT-compatible structure is stored as vendor data of
+         * TCG-defined event log header.
+         */
+        struct tpm1_spec_id_event *spec_id = (void *)evt_log;
+        evt_log = (struct txt_ev_log_container_12 *)&spec_id->vendorInfo[0];
+    }
+
     new_entry = (void *)evt_log + evt_log->NextEventOffset;
 
     /*
@@ -114,6 +124,22 @@ find_evt_log_ext_data(struct tpm2_spec_id_event *evt_log)
     struct txt_os_sinit_data *os_sinit;
     struct txt_ext_data_element *ext_data;
 
+    if ( slaunch_is_amd_drtm() )
+    {
+        /*
+         * Event log pointer is defined by TXT specification, but
+         * secure-kernel-loader provides a compatible structure in vendor data
+         * of the log.
+         */
+        uint8_t *data_size =
+            (uint8_t *)&evt_log->digestSizes[evt_log->digestCount];
+        if ( *data_size != sizeof(struct heap_event_log_pointer_element2_1) )
+            return NULL;
+
+        /* Vendor data directly follows a single-byte size. */
+        return (struct heap_event_log_pointer_element2_1 *)(data_size + 1);
+    }
+
     os_sinit = txt_start(__va(txt_read(TXTCR_HEAP_BASE)), TXT_OS2SINIT);
     ext_data = txt_find_ext_data_element(os_sinit,
                                          TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1);
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index ac62301f93..af88ca9caa 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -23,6 +23,10 @@
 #include <asm/slaunch-tpm.h>
 #include <asm/tpm.h>
 
+/* SLB is 64k, 64k-aligned */
+#define SKINIT_SLB_SIZE   0x10000
+#define SKINIT_SLB_ALIGN  0x10000
+
 /*
  * These variables are assigned to by the code near Xen's entry point.
  *
@@ -48,6 +52,8 @@ struct slr_table *__init slaunch_get_slrt(void)
     if ( slrt == NULL )
     {
         int rc;
+        bool intel_cpu = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL);
+        uint16_t slrt_architecture = intel_cpu ? SLR_INTEL_TXT : SLR_AMD_SKINIT;
 
         slrt = __va(slaunch_slrt);
 
@@ -59,9 +65,9 @@ struct slr_table *__init slaunch_get_slrt(void)
         /* XXX: are newer revisions allowed? */
         if ( slrt->revision != SLR_TABLE_REVISION )
             panic("SLRT is of unsupported revision: %#x!\n", slrt->revision);
-        if ( slrt->architecture != SLR_INTEL_TXT )
-            panic("SLRT is for unexpected architecture: %#x!\n",
-                  slrt->architecture);
+        if ( slrt->architecture != slrt_architecture )
+            panic("SLRT is for unexpected architecture: %#x != %#x!\n",
+                  slrt->architecture, slrt_architecture);
         if ( slrt->size > slrt->max_size )
             panic("SLRT is larger than its max size: %#x > %#x!\n",
                   slrt->size, slrt->max_size);
@@ -76,6 +82,23 @@ struct slr_table *__init slaunch_get_slrt(void)
     return slrt;
 }
 
+static uint32_t __init get_slb_start(void)
+{
+    /*
+     * The runtime computation relies on size being a power of 2 and equal to
+     * alignment. Make sure these assumptions hold.
+     */
+    BUILD_BUG_ON(SKINIT_SLB_SIZE != SKINIT_SLB_ALIGN);
+    BUILD_BUG_ON(SKINIT_SLB_SIZE == 0);
+    BUILD_BUG_ON((SKINIT_SLB_SIZE & (SKINIT_SLB_SIZE - 1)) != 0);
+
+    /*
+     * Rounding any address within SLB down to alignment gives SLB base and
+     * SLRT is inside SLB on AMD.
+     */
+    return slaunch_slrt & ~(SKINIT_SLB_SIZE - 1);
+}
+
 void __init slaunch_map_mem_regions(void)
 {
     int rc;
@@ -86,7 +109,10 @@ void __init slaunch_map_mem_regions(void)
     BUG_ON(rc != 0);
 
     /* Vendor-specific part. */
-    txt_map_mem_regions();
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        txt_map_mem_regions();
+    else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+        slaunch_map_l2(get_slb_start(), SKINIT_SLB_SIZE);
 
     slaunch_find_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != 0 )
@@ -98,17 +124,27 @@ void __init slaunch_map_mem_regions(void)
 
 void __init slaunch_reserve_mem_regions(void)
 {
+    int ok;
     paddr_t evt_log_addr;
     uint32_t evt_log_size;
 
     /* Vendor-specific part. */
-    txt_reserve_mem_regions();
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+    {
+        txt_reserve_mem_regions();
+    }
+    else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+    {
+        uint64_t slb_start = get_slb_start();
+        uint64_t slb_end = slb_start + SKINIT_SLB_SIZE;
+        printk("SLAUNCH: reserving SLB [%#lx, %#lx)\n", slb_start, slb_end);
+        ok = reserve_e820_ram(&e820_raw, slb_start, slb_end);
+        BUG_ON(!ok);
+    }
 
     slaunch_find_log(slaunch_get_slrt(), &evt_log_addr, &evt_log_size);
     if ( evt_log_addr != 0 )
     {
-        int ok;
-
         printk("SLAUNCH: reserving event log [%#lx, %#lx)\n", evt_log_addr,
                evt_log_addr + evt_log_size);
         ok = reserve_e820_ram(&e820_raw, evt_log_addr,
@@ -129,18 +165,37 @@ void __init slaunch_measure_slrt(void)
          * In revision one of the SLRT, only platform-specific info table is
          * measured.
          */
-        struct slr_entry_intel_info tmp;
+        if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+        {
+            struct slr_entry_intel_info tmp;
 
-        entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
-        if ( entry == NULL )
-            panic("SLRT is missing Intel-specific information!\n");
+            entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+            if ( entry == NULL )
+                panic("SLRT is missing Intel-specific information!\n");
 
-        tmp = *container_of(entry, const struct slr_entry_intel_info, hdr);
-        tmp.boot_params_base = 0;
-        tmp.txt_heap = 0;
+            tmp = *container_of(entry, const struct slr_entry_intel_info, hdr);
+            tmp.boot_params_base = 0;
+            tmp.txt_heap = 0;
 
-        slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
-                            sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+            slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                                sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+        }
+        else if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+        {
+            struct slr_entry_amd_info tmp;
+
+            entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_AMD_INFO);
+            if ( entry == NULL )
+                panic("SLRT is missing AMD-specific information!\n");
+
+            tmp = *container_of(entry, const struct slr_entry_amd_info, hdr);
+            tmp.next = 0;
+            tmp.slrt_base = 0;
+            tmp.boot_params_base = 0;
+
+            slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR, (uint8_t *)&tmp,
+                                sizeof(tmp), DLE_EVTYPE_SLAUNCH, NULL, 0);
+        }
     }
     else
     {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380758.1624502 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4c-0004tc-B7; Sun, 02 Aug 2026 13:17:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380758.1624502; Sun, 02 Aug 2026 13:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4c-0004tT-7i; Sun, 02 Aug 2026 13:17:50 +0000
Received: by outflank-mailman (input) for mailman id 1380758;
 Sun, 02 Aug 2026 13:17:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4a-0004pR-RA
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4a-00Bn6b-7p
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:48 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f436e-bab6-0a2a0a5309dd-0a2a4501cdb6-12
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:48 +0200
Received: from [87.98.178.58] (helo=17.mo561.mail-out.ovh.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41d6-5984-0a2a45010019-5762b23adae3-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:47 +0200
Received: from director4.ghost.mail-out.ovh.net (unknown [10.110.0.178])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCp55tjz5xsS
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:46 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-m4frt (unknown [10.111.174.132])
 by director4.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 9E9E0C2306;
 Sun,  2 Aug 2026 13:10:44 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.101])
 by ghost-submission-7d8d68f679-m4frt with ESMTPSA
 id A262F9RBb2oNsRcAXQcPeQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-101G004633ecb7a-a591-49b8-960a-955f05690000,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Ross Philipson <ross.philipson@gmail.com>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 21/23] x86/slaunch: support EFI boot
Date: Sun,  2 Aug 2026 16:09:37 +0300
Message-ID: <e29edd81eeb55927fef2c56b7493a8db65edfc90.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4743979258418570684
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTFkIVM66t9WfxMA1MBLamLRI1g7isw4fvjTq42J16AnGGiVkfZZz7RNohO0DVzuB6p7ByU2jpbyNpeFSmhxy18LKLUp8eoLMQd6SniSDWM2cNrBr0In5AXWUClj6LSw0UENmYdxRZSA2740zY8xbtv3e0tQCOijX5z+87X8/lqG082kExyxNnnNomzq4n6JxeS+9hUWvV3ncL+A/VeP2cvLfZQ+CqbSooIUmTa+tUTJpOYsWTKV07AKa/rJsi+zSktpNOwqnqM3QkFMTTxnOM0YJkWFFta90JnAtJgk2pNma17wsGvogAUiRHEWxKZPCW0f+1LBF9pVpiXy5iPezXU8d1hce61Aoq+F+RzUjso/AXwTe0q1s2f/fih1X+6DUmvool3KHQypNF8upsQVo+IBvC2Yjz4usFTJs0tU4CdieQIpWWA+M+WIP+3VvProtgPGB3V4I4TbBITe+5ww3KdQ8QBD+dIYUR2xsf46qGgJSHLLpxdbWpOAu39N4u/DbhJX9frf5n4MqugzsU42SlsfG2vroQwvKy7w8DgmCWSTGHyQhyOcU+pLZkvhAT0wCJmieOYIYVupe4kEpmCKcjFt2VY2EJrP6cQdkcw/LQXt7Tohx2E2u94aF3cgH6K1clYyYmuTm0lRXH1R/nT51K2vCRskrU0ONuM6EwWrUzRcBg
DKIM-Signature: a=rsa-sha256; bh=eiitqsXzV8CcZOdxpmTe8+PK7v6PihsQTS4KVdOMirw=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676246; v=1;
 b=bEcHWuwNfJrOBZFyHuWhXz1RxNezZ6yFLALj21FFaaEJAWE7ZLWFAeEMcrhuLSh2ypaOGZmv
 t9Fqt54R3YaMwodm1CDuHXVh2DmQmbOF8g71SUrcNgTs9KrVQjcst7TSY8rwlEZ+rVVi7ZWYEWn
 PDZtjstZVDn3d39MnFpRHiTaiCFIrfRUEm3OWEI69gyKi70n234sbiyOk3M6lRdzhZbi0vx5OyT
 +TqMUX7emXKimOEWzXIGkFK46X96uRKRJr/v2p+N7/owZ0Gv+z/qjuCjiN1HoOeYnt+GT7tY6+M
 iCEw7vao67lmk3Q2iGbS/YgcXudK7cpvmr3ofs8f9Bmeg==
X-purgate-ID: tlsNG-d62444/1785676247-C5146757-84F0834B/0/0
X-purgate-type: clean
X-purgate-size: 27035

When running on an EFI-enabled system, Xen needs to have access to Boot
Services in order to initialize itself properly and reach a state in
which a dom0 kernel can operate without issues.

This means that DRTM must be started in the middle of Xen's
initialization process.  This effect is achieved via a callback into
a TrenchBoot-enabled bootloader (GRUB) which is responsible for
initiating DRTM and continuing Xen's initialization process.  The latter
is done by branching in Slaunch entry point on a flag to switch back
into long mode before calling the same function which Xen would execute
as the next step without DRTM.

Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: -DXEN_BUILD_EFI => -DXEN_BUILD_EFI=1
    v4: use CONFIG_SLAUNCH
    v4: use pointers to `const` SLRT and TXT heap data
    v4: use container_of()
    v4: take updates to `struct boot_module` into account
    v4: now UEFI_SLR_TABLE_GUID is defined here in efi/boot.c

 .gitignore                                    |   1 +
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   |   1 +
 docs/hypervisor-guide/x86/how-xen-boots.rst   |  14 +-
 xen/arch/x86/Makefile                         |  12 +-
 xen/arch/x86/boot/head.S                      | 124 +++++++++++++++++
 xen/arch/x86/boot/x86_64.S                    |  14 +-
 xen/arch/x86/efi/efi-boot.h                   |  94 ++++++++++++-
 xen/arch/x86/efi/fixmlehdr.c                  | 127 ++++++++++++++++++
 xen/arch/x86/slaunch.c                        |  75 ++++++++++-
 xen/common/efi/boot.c                         |   6 +
 xen/common/efi/runtime.c                      |   1 +
 xen/include/xen/efi.h                         |   1 +
 12 files changed, 455 insertions(+), 15 deletions(-)
 create mode 100644 xen/arch/x86/efi/fixmlehdr.c

diff --git a/.gitignore b/.gitignore
index bfc7bdf043..76bc97d5ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -177,6 +177,7 @@ xen/.xen.elf32
 xen/System.map
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
+xen/arch/x86/efi/fixmlehdr
 xen/arch/x86/efi/mkreloc
 xen/arch/x86/include/asm/asm-macros.h
 xen/arch/*/xen.lds
diff --git a/automation/eclair_analysis/ECLAIR/out_of_scope.ecl b/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
index 9bcec4c69d..a09cf5442c 100644
--- a/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
+++ b/automation/eclair_analysis/ECLAIR/out_of_scope.ecl
@@ -19,6 +19,7 @@
 
 -doc_begin="Build tools are out of scope."
 -file_tag+={out_of_scope_tools,"^xen/tools/.*$"}
+-file_tag+={out_of_scope_tools,"^xen/arch/x86/efi/fixmlehdr\\.c$"}
 -file_tag+={out_of_scope_tools,"^xen/arch/x86/efi/mkreloc\\.c$"}
 -file_tag+={out_of_scope_tools,"^xen/arch/x86/boot/mkelf32\\.c$"}
 -doc_end
diff --git a/docs/hypervisor-guide/x86/how-xen-boots.rst b/docs/hypervisor-guide/x86/how-xen-boots.rst
index a841d1e9f8..0b1b62971f 100644
--- a/docs/hypervisor-guide/x86/how-xen-boots.rst
+++ b/docs/hypervisor-guide/x86/how-xen-boots.rst
@@ -56,12 +56,14 @@ which indicates the ability to use the PVH boot protocol, and registers
 ``__pvh_start`` as the entrypoint, entered in 32bit mode.
 
 A combination of Multiboot 2 and Measured Launched Environment (MLE) headers
-is used to support Dynamic Root of Trust for Measurement (DRTM) for legacy
-(BIOS) boot.  DRTM is a way to establish hardware root of trust which
-excludes firmware and is not directly tied to hardware's boot process.  The
-separate entry point called ``slaunch_stub_entry`` is used mainly to
-differentiate from other kinds of boots.  It moves a magic number to ``EAX``
-before jumping into common startup code.  More details about Secure Launch
+is used to support Dynamic Root of Trust for Measurement (DRTM).  DRTM is a
+way to establish hardware root of trust which excludes firmware and is not
+directly tied to hardware's boot process.  The separate entry point called
+``slaunch_stub_entry`` is used mainly to differentiate from other kinds of
+boots.  For a legacy (BIOS) boot, it moves a magic number to ``EAX`` before
+jumping into common startup code.  For a EFI boot, it resumes execution of
+Xen.efi which was paused by handing control to a part of a bootloader
+responsible for initiating DRTM sequence.  More details about Secure Launch
 data structures processed by Xen in this boot mode can be found in
 `<https://trenchboot.org/specifications/Secure_Launch/>`_.
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 8dbb76a3a0..4f7db9420e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -89,6 +89,7 @@ extra-y += xen.lds
 
 hostprogs-y += boot/mkelf32
 hostprogs-y += efi/mkreloc
+hostprogs-y += efi/fixmlehdr
 
 $(obj)/efi/mkreloc: HOSTCFLAGS += -I$(srctree)/include
 
@@ -123,6 +124,11 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
+# Expose this build flag as a macro when compiling assembly files.
+ifeq ($(XEN_BUILD_EFI),y)
+XEN_AFLAGS += -DXEN_BUILD_EFI=1
+endif
+
 $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
 	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
 	$(MAKE) $(build)=$(@D) $(dot-target).0.o
@@ -196,7 +202,7 @@ note_file_option ?= $(note_file)
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
 $(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds
+$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds $(obj)/efi/fixmlehdr
 ifeq ($(CONFIG_DEBUG_INFO),y)
 	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
 endif
@@ -230,6 +236,10 @@ endif
 	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \
 	      $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \
 	      $(note_file_option) -o $@
+ifeq ($(CONFIG_SLAUNCH),y)
+	# update entry point's address by taking image offset into account
+	$(obj)/efi/fixmlehdr $@ $(XEN_IMG_OFFSET)
+endif
 	$(NM) -pa --format=sysv $@ \
 		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
 		> $@.map
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index bf38aef21c..22b331a45c 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -408,6 +408,12 @@ slaunch_stub_entry:
         mov     %ebx, %esi
         sub     $sym_offs(slaunch_stub_entry), %esi
 
+#if XEN_BUILD_EFI
+        /* If the flag is already set, then Xen should continue execution. */
+        cmpb    $0, sym_esi(slaunch_active)
+        jne     slaunch_efi_jumpback
+#endif
+
         /* On AMD, %ebp holds the base address of SLB, save it for later. */
         mov     %ebp, %ebx
 
@@ -855,6 +861,124 @@ trampoline_setup:
         /* Jump into the relocated trampoline. */
         lret
 
+#if XEN_BUILD_EFI && CONFIG_SLAUNCH
+
+        /*
+         * The state matches that of slaunch_stub_entry above, but with %esi
+         * already initialized.
+         */
+slaunch_efi_jumpback:
+        lea     STACK_SIZE - CPUINFO_sizeof + sym_esi(cpu0_stack), %esp
+
+        /* Prepare gdt and segments. */
+        add     %esi, sym_esi(gdt_boot_base)
+        lgdt    sym_esi(gdt_boot_descr)
+
+        mov     $BOOT_DS, %ecx
+        mov     %ecx, %ds
+        mov     %ecx, %es
+        mov     %ecx, %ss
+
+        push    $BOOT_CS32
+        lea     sym_esi(.Lgdt_is_set),%edx
+        push    %edx
+        lret
+.Lgdt_is_set:
+
+        /*
+         * Stash TSC as above because it was zeroed on jumping into bootloader
+         * to not interfere with measurements.
+         */
+        rdtsc
+        mov     %eax,     sym_esi(boot_tsc_stamp)
+        mov     %edx, 4 + sym_esi(boot_tsc_stamp)
+
+        /*
+         * Clear the pagetables before the use. We are loaded below 4GiB and
+         * this avoids the need for writing to higher dword of each entry.
+         * Additionally, this ensures those dwords are actually zero and the
+         * mappings aren't manipulated from outside.
+         */
+        lea     sym_esi(bootmap_start), %edi
+        lea     sym_esi(bootmap_end), %ecx
+        sub     %edi, %ecx
+        xor     %eax, %eax
+        shr     $2, %ecx
+        rep stosl
+
+        /* 1x L1 page, 512 entries mapping total of 2M. */
+        lea     sym_esi(l1_bootmap), %edi
+        mov     $512, %ecx
+        mov     $(__PAGE_HYPERVISOR + 512 * PAGE_SIZE), %edx
+.Lfill_l1_identmap:
+        sub     $PAGE_SIZE, %edx
+        /* Loop runs for ecx=[512..1] for entries [511..0], hence -8. */
+        mov     %edx, -8(%edi,%ecx,8)
+        loop    .Lfill_l1_identmap
+
+        /* 4x L2 pages, each page mapping 1G of RAM. */
+        lea     sym_esi(l2_bootmap), %edi
+        /* 1st entry points to L1. */
+        lea     (sym_offs(l1_bootmap) + __PAGE_HYPERVISOR)(%esi), %edx
+        mov     %edx, (%edi)
+        /* Other entries are 2MB pages. */
+        mov     $(4 * 512 - 1), %ecx
+        /*
+         * Value below should be 4GB + flags, which wouldn't fit in 32b
+         * register. To avoid warning from the assembler, 4GB is skipped here.
+         * Substitution in first iteration makes the value roll over and point
+         * to 4GB - 2MB + flags.
+         */
+        mov     $(_PAGE_PSE + __PAGE_HYPERVISOR), %edx
+.Lfill_l2_identmap:
+        sub     $(1 << L2_PAGETABLE_SHIFT), %edx
+        /* Loop runs for ecx=[2047..1] for entries [2047..1]. */
+        mov     %edx, (%edi,%ecx,8)
+        loop    .Lfill_l2_identmap
+
+        /* 1x L3 page, mapping the 4x L2 pages. */
+        lea     sym_esi(l3_bootmap), %edi
+        mov     $4, %ecx
+        lea     (sym_offs(l2_bootmap) + 4 * PAGE_SIZE + __PAGE_HYPERVISOR)(%esi), %edx
+.Lfill_l3_identmap:
+        sub     $PAGE_SIZE, %edx
+        /* Loop runs for ecx=[4..1] for entries [3..0], hence -8. */
+        mov     %edx, -8(%edi,%ecx,8)
+        loop    .Lfill_l3_identmap
+
+        /* 1x L4 page, mapping the L3 page. */
+        lea     (sym_offs(l3_bootmap) + __PAGE_HYPERVISOR)(%esi), %edx
+        mov     %edx, sym_esi(l4_bootmap)
+
+        /* Restore CR4, PAE must be enabled before IA-32e mode */
+        mov     %cr4, %ecx
+        or      $X86_CR4_PAE, %ecx
+        mov     %ecx, %cr4
+
+        /* Load PML4 table location into PT base register */
+        lea     sym_esi(l4_bootmap), %eax
+        mov     %eax, %cr3
+
+        /* Enable IA-32e mode and paging */
+        mov     $MSR_EFER, %ecx
+        rdmsr
+        or      $EFER_LME >> 8, %ah
+        wrmsr
+
+        mov     %cr0, %eax
+        or      $X86_CR0_PG | X86_CR0_NE | X86_CR0_TS | X86_CR0_MP, %eax
+        mov     %eax, %cr0
+
+        /* Now in IA-32e compatibility mode, use lret to jump to 64b mode */
+        lea     sym_esi(start_xen_from_efi), %ecx
+        push    $BOOT_CS64
+        push    %ecx
+        lret
+
+.global start_xen_from_efi
+
+#endif /* XEN_BUILD_EFI && CONFIG_SLAUNCH */
+
 ENTRY(trampoline_start)
 #include "trampoline.S"
 ENTRY(trampoline_end)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 886960c22f..d23cfebdb6 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -267,14 +267,22 @@ GLOBAL(__page_tables_end)
 /* Init pagetables. Enough page directories to map into 4GB. */
         .section .init.data.page_aligned, "aw", @progbits
 
-DATA_LOCAL(l1_bootmap, PAGE_SIZE)
+bootmap_start:
+
+DATA_LOCAL(l1_bootmap, PAGE_SIZE) /* 1x L1 page, mapping 2M of RAM. */
         .fill L1_PAGETABLE_ENTRIES, 8, 0
 END(l1_bootmap)
 
-DATA(l2_bootmap, PAGE_SIZE)
+DATA(l2_bootmap, PAGE_SIZE) /* 4x L2 pages, each mapping 1G of RAM. */
         .fill 4 * L2_PAGETABLE_ENTRIES, 8, 0
 END(l2_bootmap)
 
-DATA(l3_bootmap, PAGE_SIZE)
+DATA(l3_bootmap, PAGE_SIZE) /* 1x L3 page, mapping the 4x L2 pages. */
         .fill L3_PAGETABLE_ENTRIES, 8, 0
 END(l3_bootmap)
+
+DATA_LOCAL(l4_bootmap, PAGE_SIZE) /* 1x L4 page, mapping the L3 page. */
+        .fill L4_PAGETABLE_ENTRIES, 8, 0
+END(l4_bootmap)
+
+bootmap_end:
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index d738b839ee..9653de4ca9 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -7,8 +7,15 @@
 #ifndef X86_EFI_EFI_BOOT_H
 #define X86_EFI_EFI_BOOT_H
 
+#include <xen/kernel.h>
 #include <xen/vga.h>
 
+/*
+ * Tell <asm/intel-txt.h> to access TXT registers without address translation
+ * which has not yet been set up.
+ */
+#define __EARLY_SLAUNCH__
+
 #include <asm/boot-helpers.h>
 #include <asm/e820.h>
 #include <asm/edd.h>
@@ -17,8 +24,11 @@
 #include <asm/setup.h>
 #include <asm/trampoline.h>
 #include <asm/efi.h>
+#include <asm/intel-txt.h>
+#include <asm/slaunch.h>
 
 static struct file __initdata ucode;
+static uint64_t __initdata xen_image_size;
 static multiboot_info_t __initdata mbi = {
     .flags = MBI_MODULES | MBI_LOADERNAME
 };
@@ -234,10 +244,31 @@ static void __init efi_arch_pre_exit_boot(void)
     }
 }
 
-static void __init noreturn efi_arch_post_exit_boot(void)
+void __init asmlinkage noreturn start_xen_from_efi(void)
 {
     u64 cr4 = XEN_MINIMAL_CR4 & ~X86_CR4_PGE, efer;
 
+    if ( slaunch_active )
+    {
+        const struct slr_table *slrt = (const struct slr_table *)efi.slr;
+        const struct slr_entry_hdr *entry;
+
+        entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO);
+        if ( entry != NULL )
+        {
+            const struct slr_entry_intel_info *intel_info =
+                container_of(entry, const struct slr_entry_intel_info, hdr);
+            void *txt_heap = txt_init();
+            const struct txt_os_mle_data *os_mle =
+                txt_start(txt_heap, TXT_OS2MLE);
+            const struct txt_os_sinit_data *os_sinit =
+                txt_start(txt_heap, TXT_OS2SINIT);
+
+            txt_verify_pmr_ranges(os_mle, os_sinit, intel_info, xen_phys_start,
+                                  xen_phys_start, xen_image_size);
+        }
+    }
+
     efi_arch_relocate_image(__XEN_VIRT_START - xen_phys_start);
     memcpy(_p(trampoline_phys), trampoline_start, cfg.size);
 
@@ -283,6 +314,66 @@ static void __init noreturn efi_arch_post_exit_boot(void)
     unreachable();
 }
 
+static void __init attempt_secure_launch(void)
+{
+#ifdef CONFIG_SLAUNCH
+    const struct slr_table *slrt;
+    const struct slr_entry_hdr *entry;
+    const struct slr_entry_dl_info *dlinfo;
+    dl_handler_func handler_callback;
+
+    /* The presence of this table indicates a Secure Launch boot. */
+    slrt = (const struct slr_table *)efi.slr;
+    if ( efi.slr == EFI_INVALID_TABLE_ADDR || slrt->magic != SLR_TABLE_MAGIC ||
+         slrt->revision != SLR_TABLE_REVISION )
+        return;
+
+    /* Avoid calls into firmware after DRTM. */
+    __clear_bit(EFI_RS, &efi_flags);
+
+    /*
+     * Make measurements less sensitive to hardware-specific details.
+     *
+     * Intentionally leaving efi_ct and efi_num_ct intact.
+     */
+    efi_ih = NULL;
+    efi_bs = NULL;
+    efi_bs_revision = 0;
+    efi_rs = NULL;
+    efi_version = 0;
+    efi_fw_vendor = NULL;
+    efi_fw_revision = 0;
+    StdOut = NULL;
+    StdErr = NULL;
+    boot_tsc_stamp = 0;
+
+    slaunch_active = true;
+    slaunch_slrt = efi.slr;
+
+    /* Jump through DL stub to initiate Secure Launch. */
+    entry = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO);
+    dlinfo = container_of(entry, const struct slr_entry_dl_info, hdr);
+
+    handler_callback = (dl_handler_func)dlinfo->dl_handler;
+    handler_callback(&dlinfo->bl_context);
+
+    unreachable();
+#endif
+}
+
+static void __init noreturn efi_arch_post_exit_boot(void)
+{
+    /*
+     * If Secure Launch happens, attempt_secure_launch() doesn't return and
+     * start_xen_from_efi() is invoked after DRTM has been initiated.
+     * Otherwise, attempt_secure_launch() returns and execution continues as
+     * usual.
+     */
+    attempt_secure_launch();
+
+    start_xen_from_efi();
+}
+
 static void __init efi_arch_cfg_file_early(const EFI_LOADED_IMAGE *image,
                                            EFI_FILE_HANDLE *dir_handle,
                                            const char *section)
@@ -783,6 +874,7 @@ static void noreturn __init efi_arch_halt(void)
 static void __init efi_arch_load_addr_check(const EFI_LOADED_IMAGE *loaded_image)
 {
     xen_phys_start = (UINTN)loaded_image->ImageBase;
+    xen_image_size = loaded_image->ImageSize;
     if ( (xen_phys_start + loaded_image->ImageSize - 1) >> 32 )
         blexit(L"Xen must be loaded below 4Gb.");
     if ( xen_phys_start & ((1 << L2_PAGETABLE_SHIFT) - 1) )
diff --git a/xen/arch/x86/efi/fixmlehdr.c b/xen/arch/x86/efi/fixmlehdr.c
new file mode 100644
index 0000000000..60a91c6b73
--- /dev/null
+++ b/xen/arch/x86/efi/fixmlehdr.c
@@ -0,0 +1,127 @@
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+/*
+ * Depending on the toolchain and its configuration the header can end up quite
+ * far from the start of the file.
+ */
+#define PREFIX_SIZE (8*1024)
+
+struct mle_header
+{
+    uint8_t uuid[16];
+    uint32_t header_len;
+    uint32_t version;
+    uint32_t entry_point;
+    uint32_t first_valid_page;
+    uint32_t mle_start;
+    uint32_t mle_end;
+    uint32_t capabilities;
+    uint32_t cmdline_start;
+    uint32_t cmdline_end;
+} __attribute__ ((packed));
+
+static const uint8_t MLE_HEADER_UUID[] = {
+    0x5a, 0xac, 0x82, 0x90, 0x6f, 0x47, 0xa7, 0x74,
+    0x0f, 0x5c, 0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42
+};
+
+int main(int argc, char *argv[])
+{
+    FILE *fp;
+    struct mle_header header;
+    int i;
+    char *end_ptr;
+    long long correction;
+    const char *file_path;
+
+    if ( argc != 3 )
+    {
+        fprintf(stderr, "Usage: %s <xen.efi> <entry-correction>\n", argv[0]);
+        return 1;
+    }
+
+    correction = strtoll(argv[2], &end_ptr, 0);
+    if ( *end_ptr != '\0' )
+    {
+        fprintf(stderr, "Failed to parse '%s' as a number\n", argv[2]);
+        return 1;
+    }
+    if ( correction < INT32_MIN  )
+    {
+        fprintf(stderr, "Correction '%s' is too small\n", argv[2]);
+        return 1;
+    }
+    if ( correction > INT32_MAX  )
+    {
+        fprintf(stderr, "Correction '%s' is too large\n", argv[2]);
+        return 1;
+    }
+
+    file_path = argv[1];
+
+    fp = fopen(file_path, "r+");
+    if ( fp == NULL )
+    {
+        fprintf(stderr, "Failed to open %s\n", file_path);
+        return 1;
+    }
+
+    for ( i = 0; i < PREFIX_SIZE; i += 16 )
+    {
+        uint8_t bytes[16];
+
+        if ( fread(bytes, sizeof(bytes), 1, fp) != 1 )
+        {
+            fprintf(stderr, "Failed to find MLE header in %s\n", file_path);
+            goto fail;
+        }
+
+        if ( memcmp(bytes, MLE_HEADER_UUID, 16) == 0 )
+        {
+            break;
+        }
+    }
+
+    if ( i >= PREFIX_SIZE )
+    {
+        fprintf(stderr, "Failed to find MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fseek(fp, -16, SEEK_CUR) )
+    {
+        fprintf(stderr, "Failed to seek back to MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fread(&header, sizeof(header), 1, fp) != 1 )
+    {
+        fprintf(stderr, "Failed to read MLE header from %s\n", file_path);
+        goto fail;
+    }
+
+    if ( fseek(fp, -(int)sizeof(header), SEEK_CUR) )
+    {
+        fprintf(stderr, "Failed to seek back again to MLE header in %s\n",
+                file_path);
+        goto fail;
+    }
+
+    header.entry_point += correction;
+
+    if ( fwrite(&header, sizeof(header), 1, fp) != 1 )
+    {
+        fprintf(stderr, "Failed to write MLE header in %s\n", file_path);
+        goto fail;
+    }
+
+    fclose(fp);
+    return 0;
+
+fail:
+    fclose(fp);
+    return 1;
+}
diff --git a/xen/arch/x86/slaunch.c b/xen/arch/x86/slaunch.c
index af88ca9caa..e506fb4293 100644
--- a/xen/arch/x86/slaunch.c
+++ b/xen/arch/x86/slaunch.c
@@ -6,6 +6,7 @@
  */
 
 #include <xen/compiler.h>
+#include <xen/efi.h>
 #include <xen/init.h>
 #include <xen/kernel.h>
 #include <xen/macros.h>
@@ -252,10 +253,23 @@ check_drtm_policy(const struct slr_table *slrt,
 {
     uint32_t i;
     uint32_t num_mod_entries;
+    int min_entries;
 
-    if ( policy->nr_entries < 2 )
-        panic("DRTM policy in SLRT contains less than 2 entries (%d)!\n",
-              policy->nr_entries);
+    min_entries = efi_enabled(EFI_BOOT) ? 1 : 2;
+    if ( policy->nr_entries < min_entries )
+    {
+        panic("DRTM policy in SLRT contains less than %d entries (%d)!\n",
+              min_entries, policy->nr_entries);
+    }
+
+    if ( efi_enabled(EFI_BOOT) )
+    {
+        check_slrt_policy_entry(&policy_entry[0], 0, slrt);
+        /* SLRT was measured in slaunch_measure_slrt(). */
+        return 1;
+    }
+
+    /* This must be legacy MultiBoot2 boot. */
 
     /*
      * MBI policy entry must be the first one, so that measuring order matches
@@ -324,6 +338,7 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
     const struct slr_table *slrt;
     const struct slr_entry_policy *policy;
     struct slr_policy_entry *policy_entry;
+    int rc;
     uint16_t i;
     unsigned int measured;
 
@@ -338,7 +353,6 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
 
     for ( i = measured; i < policy->nr_entries; i++ )
     {
-        int rc;
         uint64_t start = policy_entry[i].entity;
         uint64_t size = policy_entry[i].size;
 
@@ -384,6 +398,59 @@ void __init slaunch_process_drtm_policy(const struct boot_info *bi)
 
         policy_entry[i].flags |= SLR_POLICY_FLAG_MEASURED;
     }
+
+    /*
+     * On x86 EFI platforms Xen reads its command-line options and kernel/initrd
+     * from configuration files (several can be chained). Bootloader can't know
+     * contents of the configuration beforehand without parsing it, so there
+     * will be no corresponding policy entries. Instead, measure command-line
+     * and all modules here.
+     */
+    if ( efi_enabled(EFI_BOOT) )
+    {
+#define LOG_DATA(str) (uint8_t *)(str), (sizeof(str) - 1)
+
+        slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR,
+                            (const uint8_t *)bi->cmdline, strlen(bi->cmdline),
+                            DLE_EVTYPE_SLAUNCH, LOG_DATA("Xen's command line"));
+
+        for ( i = 0; i < bi->nr_modules; i++ )
+        {
+            const struct boot_module *mod = &bi->mods[i];
+
+            paddr_t string = mod->arch.cmdline_pa;
+            paddr_t start = mod->start;
+            size_t size = mod->size;
+
+            if ( mod->arch.relocated || mod->arch.released )
+            {
+                panic("A module \"%s\" (#%d) was consumed before measurement\n",
+                      (const char *)__va(string), i);
+            }
+
+            /*
+             * Measuring module's name separately because module's command-line
+             * parameters are appended to its name when present.
+             *
+             * 2 MiB is minimally mapped size and it should more than suffice.
+             */
+            rc = slaunch_map_l2(string, 2 * 1024 * 1024);
+            BUG_ON(rc != 0);
+
+            slaunch_hash_extend(DRTM_LOC, DRTM_DATA_PCR,
+                                __va(string), strlen(__va(string)),
+                                DLE_EVTYPE_SLAUNCH,
+                                LOG_DATA("MB module string"));
+
+            rc = slaunch_map_l2(start, size);
+            BUG_ON(rc != 0);
+
+            slaunch_hash_extend(DRTM_LOC, DRTM_CODE_PCR, __va(start), size,
+                                DLE_EVTYPE_SLAUNCH, LOG_DATA("MB module"));
+        }
+
+#undef LOG_DATA
+    }
 }
 
 int __init slaunch_map_l2(paddr_t paddr, size_t size)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 8f24df9bc2..41ccc6dcd3 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -19,6 +19,7 @@
 #if EFI_PAGE_SIZE != PAGE_SIZE
 # error Cannot use xen/pfn.h here!
 #endif
+#include <xen/slr-table.h>
 #include <xen/string.h>
 #include <xen/stringify.h>
 #ifdef CONFIG_X86
@@ -45,6 +46,8 @@
 #define EFI_SYSTEM_RESOURCE_TABLE_GUID    \
   { 0xb122a263U, 0x3661, 0x4f68, {0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 0x80} }
 #define EFI_SYSTEM_RESOURCE_TABLE_FIRMWARE_RESOURCE_VERSION 1
+#define UEFI_SLR_TABLE_GUID \
+  { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }
 
 typedef struct {
     EFI_GUID FwClass;
@@ -1154,6 +1157,7 @@ static void __init efi_tables(void)
         static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
         static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
         static EFI_GUID __initdata smbios3_guid = SMBIOS3_TABLE_GUID;
+        static EFI_GUID __initdata slr_guid = UEFI_SLR_TABLE_GUID;
 
         if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
             efi.acpi20 = (unsigned long)efi_ct[i].VendorTable;
@@ -1165,6 +1169,8 @@ static void __init efi_tables(void)
             efi.smbios = (unsigned long)efi_ct[i].VendorTable;
         if ( match_guid(&smbios3_guid, &efi_ct[i].VendorGuid) )
             efi.smbios3 = (unsigned long)efi_ct[i].VendorTable;
+        if ( match_guid(&slr_guid, &efi_ct[i].VendorGuid) )
+            efi.slr = (unsigned long)efi_ct[i].VendorTable;
         if ( match_guid(&esrt_guid, &efi_ct[i].VendorGuid) )
             esrt = (UINTN)efi_ct[i].VendorTable;
     }
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 596f2710fb..b2cebaad02 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -72,6 +72,7 @@ struct efi __read_mostly efi = {
 	.mps    = EFI_INVALID_TABLE_ADDR,
 	.smbios = EFI_INVALID_TABLE_ADDR,
 	.smbios3 = EFI_INVALID_TABLE_ADDR,
+	.slr    = EFI_INVALID_TABLE_ADDR,
 };
 
 const struct efi_pci_rom *__read_mostly efi_pci_roms;
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 87146172ad..37d016d885 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -17,6 +17,7 @@ struct efi {
     unsigned long acpi20;       /* ACPI table (ACPI 2.0) */
     unsigned long smbios;       /* SM BIOS table */
     unsigned long smbios3;      /* SMBIOS v3 table */
+    unsigned long slr;          /* SLR table */
 };
 
 extern struct efi efi;
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 13:17:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 13:17:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380765.1624510 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4k-0005ZC-Mm; Sun, 02 Aug 2026 13:17:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380765.1624510; Sun, 02 Aug 2026 13:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqW4k-0005Z5-In; Sun, 02 Aug 2026 13:17:58 +0000
Received: by outflank-mailman (input) for mailman id 1380765;
 Sun, 02 Aug 2026 13:17:57 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wqW4j-0005S2-7S
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 13:17:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqW4i-004dxe-Kg
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:17:56 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f4339-e002-0a2a0a5209dd-0a2a45049482-46
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:17:56 +0200
Received: from [188.165.56.177] (helo=19.mo582.mail-out.ovh.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a6f41df-b57f-0a2a45040019-bca538b1e9cd-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 15:10:55 +0200
Received: from director10.ghost.mail-out.ovh.net (unknown [10.109.231.29])
 by mo582.mail-out.ovh.net (Postfix) with ESMTP id 4hCgCy6f3Lz5yDC
 for <xen-devel@lists.xenproject.org>; Sun,  2 Aug 2026 13:10:54 +0000 (UTC)
Received: from ghost-submission-7d8d68f679-zgxq6 (unknown [10.110.178.25])
 by director10.ghost.mail-out.ovh.net (Postfix) with ESMTPS id F0D1BC0F59;
 Sun,  2 Aug 2026 13:10:53 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.98])
 by ghost-submission-7d8d68f679-zgxq6 with ESMTPSA
 id uCqTMN1Bb2oVAxsAmLjjbA
 (envelope-from <sergii.dmytruk@3mdeb.com>); Sun, 02 Aug 2026 13:10:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-98R002ead41966-a0ae-48e8-ac73-de1d09aa3230,
                    A7BD45287BC66A7121136900083CD01C39616B1D) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	trenchboot-devel@googlegroups.com
Subject: [PATCH v4 23/23] MAINTAINERS: add a section for TrenchBoot Slaunch
Date: Sun,  2 Aug 2026 16:09:39 +0300
Message-ID: <f73cbcb2df9a00b8a281d8c75526e8a92213380e.1785668458.git.sergii.dmytruk@3mdeb.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
x-ovh-tracer-id: 4746231058255652284
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTF70AoUNTuq0lE163/HHHmITb2k71K2uLoI2ZNhSgyl66wu8n/QJYzc+NLLaUb0uP1TrkyCR/9L8Ilu8caNGFiWNKPhk8LryKkv9xxZSrEN1zqyUGrQN6nXky3jMJxzdN9g/O0CtTLwNhHfleReQxYNqzRPBHWIFmbNp+cZCBU9E3JqDvY2G2n8Fq8vuRNzFdlGIcwMaDxCbm3ZzhQ1uRn2km7gAWfvABUN0yPDoQrFrCjLaFwKnQdy3a/cfWa0gHDTshjKSe3BdNtt7392P9RjMTs2j3tG0nmovZ410v/2dE5urrhoo3isYDb0H1B5YfdyZsu/PJWc0DbUySgFmJKBTwglKriq0gRMo1PkDd+xpWGLikl+rCGY83aL//Ruy+v/Mbj+0ZQsS8vdQI51LmzJzowkH1FGK9Z/4lYtIhngAxkTZCHoLGrmjs6snH8aiEvzdH3eGN/lNIqA4na2G+WgTW6ogNPO38BfcpkFZW1g9nmrbYYZ94Ah1ERH3PwZuFNYG/O1viBVOjdlrbn08mtWY9cFI2Ip+UV3QOWEvXvmV9rVR9CGSKGI3lBu76WftB73RKTJFT9HXgsnN0EeP/3/Wz/Zw1Q4jjyp9RXGBzAuAjIaBxP0asvu0zNdezWDGFBBZHDV56W2fOUJ1ZciSUxT/veWKpAUrtOhunw4sZRMEQ
DKIM-Signature: a=rsa-sha256; bh=v4IOVEJofe0j1YxPJgQI553fOjaIdjsxp1gURHV2leg=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1785676254; v=1;
 b=GYK1oxgVKJNi1aeOLTTwHscO9lEmKDNgG+soSTQH+gPXT52aNsi2DEneiC9mNWTL95wnDy0T
 KaczshOcgzqWDw2NEdT7uwFFiFODqT0vWAQUwiA2/6uf7bMZW+LRIB+h8CaEr9wTnA0kfGxDYp8
 /4vtboAgGX7aVCfkyHCxlVmX9OgUHsKZUw3i0zGxTScB8L4XsbZIUq45Xn8oMCLqpr6F61M4pr0
 8sQXivfjcuT0XgY7W6qOPdnDblMp4FMLw+uJSbPwKm4Nu9LAHyBCc+0J8BmhSzTzCx7ze3/UXpp
 DX7HNqDkM4hZGjn1L2+V73m0MTYy1puGBGS+VGwXz2MZA==
X-purgate-ID: tlsNG-ebf023/1785676255-522D4B50-F23E0C30/0/0
X-purgate-type: clean
X-purgate-size: 1139

Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
---

Notes:
    v4: updated list of files to match this patchset

 MAINTAINERS | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ed0ffa608f..54c0428f8d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -565,6 +565,25 @@ F:	*/configure
 F:	*/*.ac
 F:	tools/
 
+TRENCHBOOT SECURE LAUNCH
+R:	Daniel P. Smith <dpsmith@apertussolutions.com>
+R:	Ross Philipson <ross.philipson@gmail.com>
+R:	Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
+S:	Supported
+F:	xen/arch/x86/boot/slaunch-early.c
+F:	xen/arch/x86/efi/fixmlehdr.c
+F:	xen/arch/x86/include/asm/intel-txt.h
+F:	xen/arch/x86/include/asm/slaunch-tpm.h
+F:	xen/arch/x86/include/asm/slaunch.h
+F:	xen/arch/x86/include/asm/tpm.h
+F:	xen/arch/x86/include/asm/tpm1.h
+F:	xen/arch/x86/include/asm/tpm2.h
+F:	xen/arch/x86/intel-txt.c
+F:	xen/arch/x86/slaunch-tpm.c
+F:	xen/arch/x86/slaunch.c
+F:	xen/arch/x86/tpm.c
+F:	xen/include/xen/slr-table.h
+
 VM EVENT, MEM ACCESS and MONITOR
 M:	Tamas K Lengyel <tamas@tklengyel.com>
 S:	Supported
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:46:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:46:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380828.1624520 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXSI-00034v-Rc; Sun, 02 Aug 2026 14:46:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380828.1624520; Sun, 02 Aug 2026 14:46:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXSI-00034o-Oq; Sun, 02 Aug 2026 14:46:22 +0000
Received: by outflank-mailman (input) for mailman id 1380828;
 Sun, 02 Aug 2026 14:46:21 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXSG-00034i-Uw
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:46:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXSG-00Bx6q-5q
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:46:20 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5830-bab6-0a2a0a5309dd-0a2a450bc278-8
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:46:19 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5839-b7e8-0a2a450b0019-888fbc33527e-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:46:19 +0200
Received: by mx.zohomail.com with SMTPS id 1785681972445252.2089444850145;
 Sun, 2 Aug 2026 07:46:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785681976; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=HRDJ5TU4A/2Q+ugBz1yN3EHE5j2GRSNS/7EVriDnj+UeFvsH0y5Y8lyneUxhVwAN3v10S2v0Gg8q/ORNriJ3S7+e1xyUkjD4k3GmQGHSgdeHtR/IRdEz36nVIt7w1SfmUMdEaRrowdjC+OfVwDUgoLb633hDf4YKMVnsB+hE1yI=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785681976; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=kzbKdiqKfTJpZx1LkDJ90vqeYWH3KR+8s82icRqzEnw=; 
	b=BK4MqGoQVy07at+Ah2nTYuVntosF2cvhw/jT4RvmmIXiNXBfoSQmcKbFf+amG2IXDBxa5CrZs2EQeMmdkcle0BP59sFjZMFxRY8sblJmaig8V7DapFIG/9qFrEk1sHAm8zf4FNBxs+nwZHrxbII5QM6QpZDLSRCsgZvrKmtq1kw=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785681976;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=kzbKdiqKfTJpZx1LkDJ90vqeYWH3KR+8s82icRqzEnw=;
	b=tAJgAZScKoeyvnl5f7/f+E4z8skg8wsJntAfaO7HHZWXvlS9lv9+K1J81sMxKaF5
	LEeMd6+xnaYtFcYIzjAX69Sfi6n++EoknqOjudo2Pb0WQla1u/XuSFI9yMtn0F8rMqZ
	iuk+WFWRFXm50qjF2py3MpUYGCDWKXpYZj0suDGI=
Message-ID: <7a406302-5b29-4b21-8a00-12bcae460c74@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:46:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 01/24] XSM: reduce redundancy in hook machinery
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <7487f138-e5e9-41d6-9291-f5eef42d09a1@suse.com>
 <62738b20-ef4b-47ac-832c-5c5fe353e56f@apertussolutions.com>
 <8030ff8e-ed83-46c4-ba69-4954ee645c38@suse.com>
 <19775f5b-e458-4336-92a3-8f8103708564@apertussolutions.com>
 <8b4568ef-1fe7-4a3f-b1b4-a3175ebe62d9@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <8b4568ef-1fe7-4a3f-b1b4-a3175ebe62d9@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-42698a/1785681979-1B4D39EA-85CB4AC8/0/0
X-purgate-type: clean
X-purgate-size: 1614



On 7/31/26 4:03 AM, Jan Beulich wrote:
> On 30.07.2026 20:21, Daniel P. Smith wrote:
>> On 7/30/26 11:18 AM, Jan Beulich wrote:
>>> On 30.07.2026 17:05, Daniel P. Smith wrote:
>>>> On 7/28/26 9:13 AM, Jan Beulich wrote:
>>>>> Hooks not taking xsm_default_t as first argument could of course be
>>>>> adjusted to take one, at which point they could be covered here as well.
>>>>> Question is why there is this difference in the first place.
>>>>
>>>> I have a theory but I am not confident to write it down. I can see if I
>>>> can confirm with DDG if you really care that much to know the why.
>>>> Personally having a consistent hook interface convention would provide a
>>>> simpler pattern for people to follow if they are having to introdcue a
>>>> new hook.
>>>
>>> Well, I don't really need to know the reason. If you agree that making
>>> things uniform is a good move, I can simply stick a few more patches at
>>> the end of this series.
>>
>> Correct me if I am wrong, but we would be introducing an unused
>> parameter in exchange for uniform interfaces that can be generated with
>> machinery reducing hook maintenance overhead. IMHO I feel from a
>> security standpoint this would be a win. Would you disagree?
> 
> Definitely not. What I'm unsure is whether I'd call this a security related
> win. To me it's more a win in maintainability in general. Which of course
> (typically) also helps security of the resulting code.

That's what I was intending in that statement, Reducing fragility in 
code/maintenance increases stability and thus security.

v//r,
dps



From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:50:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:50:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380835.1624528 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXWV-0006Ge-AZ; Sun, 02 Aug 2026 14:50:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380835.1624528; Sun, 02 Aug 2026 14:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXWV-0006GX-7p; Sun, 02 Aug 2026 14:50:43 +0000
Received: by outflank-mailman (input) for mailman id 1380835;
 Sun, 02 Aug 2026 14:50:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXWU-0006GR-Rm
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:50:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXWU-00BxXT-8h
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:50:42 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f58e6-e002-0a2a0a5209dd-0a2a4503c7d6-42
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:50:41 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f593f-fae8-0a2a45030019-888fbc335281-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:50:41 +0200
Received: by mx.zohomail.com with SMTPS id 1785682235119466.7755168004719;
 Sun, 2 Aug 2026 07:50:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785682237; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=BjJvg9Ur3O4HJe/WTBimbNZYGF8Cq7NcfHKEaHEXLkbVWTnOT+A/KzPVTYUT1i+Hv7fW94VSMXONHgr78zK3QejinALH/X8dvIeZgbOfCknOzpe9BiwOZF9MBT2sfszSu6yNcLdByXet3m+vv88VuM2JuD7oECwf6NV16fLOpc0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785682237; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=ISvWVng+FYKzx5n50hE5vRcVh5WIYwczRj0Moy6WDrY=; 
	b=TXiza9+cibhr+Q3vJN7h6Ai3c2NdqlnGZM5uj2qf/cHtFLcL5QfRTZWKXa8UKnPNeYGmuS7TvUKnuG/jFEEFoUBy8+I3gciUzBJF3L8/NaRCDaqjosGitA88VHkfMU42f9Gv5eJU9pvwnhTAqEVeHbKcdSIXob2hTwoUTKV4fQo=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785682237;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=ISvWVng+FYKzx5n50hE5vRcVh5WIYwczRj0Moy6WDrY=;
	b=P7UmLbn7Svay2k+rGOTlKbmhyPGt54da8NGrdKnKmhz/ouGVpwqlxUVCbvbbNmAa
	rz3F7oa1Nx9Sv+g4I2iSZyUcOFDKkQQYEc0SQjwXsyhUYSrns0o4CUkm7dxaQ7w6ora
	l3eMz6ajRMjMboQzuQyw6MfayWJbRaDj4CjpshI4=
Message-ID: <a82166c8-8e7e-449b-aac1-6395eb3bd574@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:50:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/24] XSM: make .{,un}map_domain_pirq() hooks dependent
 upon HAS_PIRQ=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <9a0a1494-1357-43d2-ba6b-532fc01b703e@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <9a0a1494-1357-43d2-ba6b-532fc01b703e@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1785682241-77AC44E9-E6498643/0/0
X-purgate-type: clean
X-purgate-size: 3272

On 7/28/26 9:14 AM, Jan Beulich wrote:
> They're unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -450,6 +450,8 @@ static XSM_INLINE char *cf_check xsm_sho
>       return NULL;
>   }
>   
> +#ifdef CONFIG_HAS_PIRQ
> +
>   static XSM_INLINE int cf_check xsm_map_domain_pirq(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
> @@ -457,17 +459,19 @@ static XSM_INLINE int cf_check xsm_map_d
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_map_domain_irq(
> -    XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
> +static XSM_INLINE int cf_check xsm_unmap_domain_pirq(
> +    XSM_DEFAULT_ARG struct domain *d)
>   {
> -    XSM_ASSERT_ACTION(XSM_HOOK);
> +    XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_unmap_domain_pirq(
> -    XSM_DEFAULT_ARG struct domain *d)
> +#endif /* CONFIG_HAS_PIRQ */
> +
> +static XSM_INLINE int cf_check xsm_map_domain_irq(
> +    XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
>   {
> -    XSM_ASSERT_ACTION(XSM_DM_PRIV);
> +    XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -65,9 +65,12 @@ XSM_HOOK(int, kexec)
>   
>   XSM_HOOK(int, schedop_shutdown, struct domain *, struct domain *)
>   
> +#ifdef CONFIG_HAS_PIRQ
>   XSM_HOOK(int, map_domain_pirq, struct domain *)
> -XSM_HOOK(int, map_domain_irq, struct domain *, int, const void *)
>   XSM_HOOK(int, unmap_domain_pirq, struct domain *)
> +#endif
> +
> +XSM_HOOK(int, map_domain_irq, struct domain *, int, const void *)
>   XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const void *)
>   XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1018,11 +1018,20 @@ static char *cf_check flask_show_irq_sid
>       return ctx;
>   }
>   
> +#ifdef CONFIG_HAS_PIRQ
> +
>   static int cf_check flask_map_domain_pirq(struct domain *d)
>   {
>       return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
>   }
>   
> +static int cf_check flask_unmap_domain_pirq(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
> +}
> +
> +#endif /* CONFIG_HAS_PIRQ */
> +
>   static int flask_map_domain_msi (
>       struct domain *d, int irq, const void *data, uint32_t *sid,
>       struct avc_audit_data *ad)
> @@ -1085,11 +1094,6 @@ static int cf_check flask_map_domain_irq
>       return rc;
>   }
>   
> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
> -{
> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
> -}
> -
>   static int flask_unmap_domain_msi (
>       struct domain *d, int irq, const void *data, uint32_t *sid,
>       struct avc_audit_data *ad)
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:53:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:53:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380843.1624537 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXZ2-0007MU-MH; Sun, 02 Aug 2026 14:53:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380843.1624537; Sun, 02 Aug 2026 14:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXZ2-0007MN-Ja; Sun, 02 Aug 2026 14:53:20 +0000
Received: by outflank-mailman (input) for mailman id 1380843;
 Sun, 02 Aug 2026 14:53:20 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXZ1-0007MG-UM
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:53:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXZ1-00EjZv-BK
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:53:19 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5987-2eae-0a2a0a5409dd-0a2a4503c360-28
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:53:19 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f59dd-fae8-0a2a45030019-888fbc335283-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:53:19 +0200
Received: by mx.zohomail.com with SMTPS id 1785682393099230.6498974128616;
 Sun, 2 Aug 2026 07:53:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785682396; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=d/jEvwgzygpDUKscEvTENnwbGeqEQppbGQTHYTeGMeY/NizadalW2yDr3q8DWD/lY28Walnr+qoebhsijUXfBBIeEGVvjJJg38I2EeUa0ewVthp70/MWEDwWAXpq6DB6Kx1lAodH7HGOoQ0NjYu7cNwqi5M26GgzqOQ7q4wCo+w=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785682396; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=MVNr6pdZlz2IwSoh48lq1aj/GJU09fj8XWglhHdstE4=; 
	b=OY5ygUpYC9t6cHdP2W1/ZdZpp9S2CFVfQTQ8r2wlMGwIl7irgEnw+WMZ8LKl0E/oiQKcLpcgHFpwF4d6horV+UaJJ5vsNkp6QkeXsMZBtngchMmbA3oQ1CeP1JIYRcDFdyTMZa9VjfarU/QN/6UnZKLLR04TADOIgtfiJBZ9AzA=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785682396;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=MVNr6pdZlz2IwSoh48lq1aj/GJU09fj8XWglhHdstE4=;
	b=sdbVph9I/B6/a5Akzpjkd3Ey13f8D7tQFqHbksBzLvdUw/eJuPrjhETnY5QJju0G
	bvmGRyoFjjugEwGKsvKVpZ36SMi2GhoJJTNAtc003LrJxLM6RIYx34CHIbzxBHBP8zE
	zIAxrcO0TU82o640sy0768xuZnmuYjBguHWfvH/A=
Message-ID: <68ebf12b-453c-490e-a9a3-87aa64693183@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:53:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 04/24] XSM: make PCI hooks dependent upon HAS_PCI=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <03267655-2c62-459a-abef-6a0a85a9fa44@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <03267655-2c62-459a-abef-6a0a85a9fa44@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1785682399-6D2D84E9-A018125A/0/0
X-purgate-type: clean
X-purgate-size: 4988

On 7/28/26 9:14 AM, Jan Beulich wrote:
> They're unreachable / dead otherwise. Really resource_{,un}plug_pci() is
> further limited to PCI pass-through.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -394,6 +394,8 @@ static XSM_INLINE int cf_check xsm_get_d
>   }
>   #endif /* HAS_PASSTHROUGH && HAS_PCI */
>   
> +#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
> +
>   static XSM_INLINE int cf_check xsm_resource_plug_pci(
>       XSM_DEFAULT_ARG uint32_t machine_bdf)
>   {
> @@ -408,6 +410,10 @@ static XSM_INLINE int cf_check xsm_resou
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> +#endif /* CONFIG_HAS_PASSTHROUGH && CONFIG_HAS_PCI */
> +
> +#ifdef CONFIG_HAS_PCI
> +
>   static XSM_INLINE int cf_check xsm_resource_setup_pci(
>       XSM_DEFAULT_ARG uint32_t machine_bdf)
>   {
> @@ -421,6 +427,8 @@ static XSM_INLINE int cf_check xsm_resou
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> +#endif /* CONFIG_HAS_PCI */
> +
>   static XSM_INLINE int cf_check xsm_resource_setup_misc(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> @@ -524,6 +532,7 @@ static XSM_INLINE int cf_check xsm_iomem
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> +#ifdef CONFIG_HAS_PCI
>   static XSM_INLINE int cf_check xsm_pci_config_permission(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t machine_bdf, uint16_t start,
>       uint16_t end, uint8_t access)
> @@ -531,6 +540,7 @@ static XSM_INLINE int cf_check xsm_pci_c
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
> +#endif /* CONFIG_HAS_PCI */
>   
>   static XSM_INLINE int cf_check xsm_add_to_physmap(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -77,21 +77,24 @@ XSM_HOOK(int, unbind_pt_irq, struct doma
>   
>   XSM_HOOK(int, irq_permission, struct domain *, int, uint8_t)
>   XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, uint8_t)
> -XSM_HOOK(int, pci_config_permission, struct domain *, uint32_t, uint16_t,
> -                                     uint16_t, uint8_t)
>   
>   XSM_HOOK(int, iomem_mapping, struct domain *, uint64_t, uint64_t, uint8_t)
>   XSM_HOOK(int, iomem_mapping_vpci, struct domain *, uint64_t, uint64_t, uint8_t)
>   
>   #if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
> +XSM_HOOK(int, resource_plug_pci, uint32_t)
> +XSM_HOOK(int, resource_unplug_pci, uint32_t)
>   XSM_HOOK(int, get_device_group, uint32_t)
>   #endif
>   
> -XSM_HOOK(int, resource_plug_pci, uint32_t)
> -XSM_HOOK(int, resource_unplug_pci, uint32_t)
> +XSM_HOOK(int, resource_setup_misc)
> +
> +#ifdef CONFIG_HAS_PCI
>   XSM_HOOK(int, resource_setup_pci, uint32_t)
>   XSM_HOOK(int, resource_setup_gsi, int)
> -XSM_HOOK(int, resource_setup_misc)
> +XSM_HOOK(int, pci_config_permission, struct domain *, uint32_t, uint16_t,
> +                                     uint16_t, uint8_t)
> +#endif
>   
>   XSM_HOOK(int, hypfs_op)
>   
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1225,6 +1225,7 @@ static int cf_check flask_iomem_mapping(
>   }
>   #define flask_iomem_mapping_vpci flask_iomem_mapping
>   
> +#ifdef CONFIG_HAS_PCI
>   static int cf_check flask_pci_config_permission(
>       struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end,
>       uint8_t access)
> @@ -1250,6 +1251,7 @@ static int cf_check flask_pci_config_per
>       return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
>   
>   }
> +#endif /* CONFIG_HAS_PCI */
>   
>   #if defined(CONFIG_SYSCTL) || defined(CONFIG_X86)
>   static int flask_resource_plug_core(void)
> @@ -1270,6 +1272,8 @@ static int flask_resource_use_core(void)
>   }
>   #endif /* CONFIG_SYSCTL */
>   
> +#if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
> +
>   static int cf_check flask_resource_plug_pci(uint32_t machine_bdf)
>   {
>       uint32_t rsid;
> @@ -1300,6 +1304,10 @@ static int cf_check flask_resource_unplu
>       return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
>   }
>   
> +#endif /* CONFIG_HAS_PASSTHROUGH && CONFIG_HAS_PCI */
> +
> +#ifdef CONFIG_HAS_PCI
> +
>   static int cf_check flask_resource_setup_pci(uint32_t machine_bdf)
>   {
>       uint32_t rsid;
> @@ -1328,6 +1336,8 @@ static int cf_check flask_resource_setup
>       return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
>   }
>   
> +#endif /* CONFIG_HAS_PCI */
> +
>   static int cf_check flask_resource_setup_misc(void)
>   {
>       return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:56:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380850.1624548 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXbj-0007sh-3f; Sun, 02 Aug 2026 14:56:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380850.1624548; Sun, 02 Aug 2026 14:56:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXbj-0007sZ-09; Sun, 02 Aug 2026 14:56:07 +0000
Received: by outflank-mailman (input) for mailman id 1380850;
 Sun, 02 Aug 2026 14:56:05 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXbh-0007sQ-HI
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:56:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXbg-008Ecu-AZ
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:56:04 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5a74-bab6-0a2a0a5309dd-0a2a4507d39a-24
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:56:03 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5a82-b4ea-0a2a45070019-888fbc335287-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:56:03 +0200
Received: by mx.zohomail.com with SMTPS id 178568255845463.554231152630905;
 Sun, 2 Aug 2026 07:55:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785682560; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=VAz/p1RK69xgKt3N5Ueaeb2Ye60bKh3LCyM31UCMlhV3/EhyHrwa+u5FIDhPVeXRm6dR/YlYaMMi0DqBOu88sFQBTn2Q9PDn1QDWLr9bYL4rAWHAUr24JjkTBvuBQNPcsSkcAtvwpuS/Vq8hWA1R4BGjlkkg2enbhVxwwvvVDVg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785682560; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=nEk+EQeINCftDeVHUH0EflRmlpsWdGR8Goc03eXOtm0=; 
	b=DzWgvtMCbIMrAI7krK0TgLj/r+L9h6CeLRPVbR7bkiJ4jptPtMV1IrRFkBXY7zzq9SvAOlU27qq0lGtndIc1iwKLXH3rC/D/mLof8pAr+SLQyjLwtWkz5Ue/vFStz2mF9VMA3Q+60ujCon8uLil0zEMw0FpzU5/kRdg41leRgOg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785682560;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=nEk+EQeINCftDeVHUH0EflRmlpsWdGR8Goc03eXOtm0=;
	b=ZlnuS17pnusfi7K+aUQ9fGKYWiiwOroh508btkj3cng82X4QCfyJdqYN0HhPsTAY
	3mIUcBVDT/2tPaHSFGaRXOoLXOj8dxNpoOoBSG2ztJv7Rsann6JeXdOu9KbIvOa6VVR
	RjlkxNs2GeAQcUTaE+/qULGsKm9rkWwbc8fpsT0I=
Message-ID: <d705cdeb-5f00-432d-9363-648287988a99@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:56:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 05/24] XSM: make .iomem_mapping_vcpi() hook dependent upon
 HAS_VPCI=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <d466a04f-8151-4b83-972b-3525eaa39bd5@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <d466a04f-8151-4b83-972b-3525eaa39bd5@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-ef75cf/1785682563-36AD8AE4-51E90D11/0/0
X-purgate-type: clean
X-purgate-size: 1435

nit: typo in subject, .iomem_mapping_vcpi --> .iomem_mapping_vpci

On 7/28/26 9:15 AM, Jan Beulich wrote:
> It's unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -525,12 +525,14 @@ static XSM_INLINE int cf_check xsm_iomem
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> +#ifdef CONFIG_HAS_VPCI
>   static XSM_INLINE int cf_check xsm_iomem_mapping_vpci(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
> +#endif
>   
>   #ifdef CONFIG_HAS_PCI
>   static XSM_INLINE int cf_check xsm_pci_config_permission(
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -79,7 +79,9 @@ XSM_HOOK(int, irq_permission, struct dom
>   XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, uint8_t)
>   
>   XSM_HOOK(int, iomem_mapping, struct domain *, uint64_t, uint64_t, uint8_t)
> +#ifdef CONFIG_HAS_VPCI
>   XSM_HOOK(int, iomem_mapping_vpci, struct domain *, uint64_t, uint64_t, uint8_t)
> +#endif
>   
>   #if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
>   XSM_HOOK(int, resource_plug_pci, uint32_t)
> 

Outside of the typo,

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:57:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:57:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380858.1624557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXd6-0008PI-Gg; Sun, 02 Aug 2026 14:57:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380858.1624557; Sun, 02 Aug 2026 14:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXd6-0008PB-DC; Sun, 02 Aug 2026 14:57:32 +0000
Received: by outflank-mailman (input) for mailman id 1380858;
 Sun, 02 Aug 2026 14:57:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXd5-0008P0-6w
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:57:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXd4-004pUG-GT
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:57:30 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5a86-5cb7-0a2a0a5109dd-0a2a450ce622-34
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:57:30 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5ad8-f479-0a2a450c0019-888fbc335289-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:57:29 +0200
Received: by mx.zohomail.com with SMTPS id 1785682644042977.50931892548;
 Sun, 2 Aug 2026 07:57:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785682646; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=MfQVxdtrEo3vzcogysJ0n6twxCqO81WwpEAuGkVDaySx6pheZmMYgX2dUMFT5tNpA7I46D8mXFYbFZOpTcjOQaun6Fki3xcKRGE67cOdIYYNpUUL7pu0PK2J+S/0o8aA9sVSGF5OSqVSV6stGg2Xc0g1vcNBzHDVtVeWXck0f6s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785682646; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=jAIVKTmnx4gCtqOEaDrwuXQfRKpW+w0HA/n4qqJv41k=; 
	b=mOxqlThpBeNpX6kbJvmyOetTyvzTA0WBJliiwFyczpceyWhBt0I/ZIC+YRBOXZJvJWR3BsidYDp11l8LX8zglElUsJphRJVGVOsADa0LMPm05RiLJX18+BDxMjGhEB6IWrvl36BjbjE8D93UfSrjbgHHTSAlvhUsCUztbnqqsSE=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785682646;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=jAIVKTmnx4gCtqOEaDrwuXQfRKpW+w0HA/n4qqJv41k=;
	b=OXLjjLBHGad9mwdDElfcYTGIBu4oJvYh2GB1ocCq3kvjyjsJVG0u5irLRa7w8Dvn
	vRk4sBl/6guFSmop6QjQab/rs/4MkjjQySsHkCDva3YoBxhMQpwJwmgRXg/GGIvOrcJ
	zIfF5kAydkviuAYdZLaRHD5xY2UFZavw0qfdK3q8=
Message-ID: <d35acf97-aa64-4c08-a6f7-ab682db6ab9c@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:57:30 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/24] XSM: make .kexec() hook dependent upon KEXEC=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <2916d9d7-9a9f-4e1f-9202-628532abe35f@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <2916d9d7-9a9f-4e1f-9202-628532abe35f@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-d25034/1785682650-5113AA5B-96141E13/0/0
X-purgate-type: clean
X-purgate-size: 1516

On 7/28/26 9:15 AM, Jan Beulich wrote:
> It's unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -271,11 +271,13 @@ static XSM_INLINE int cf_check xsm_conso
>       return xsm_default_action(XSM_PRIV, d, NULL);
>   }
>   
> +#ifdef CONFIG_KEXEC
>   static XSM_INLINE int cf_check xsm_kexec(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
> +#endif
>   
>   static XSM_INLINE int cf_check xsm_schedop_shutdown(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -61,7 +61,9 @@ XSM_HOOK(int, claim_pages, struct domain
>   
>   XSM_HOOK(int, console_io, struct domain *, int)
>   
> +#ifdef CONFIG_KEXEC
>   XSM_HOOK(int, kexec)
> +#endif
>   
>   XSM_HOOK(int, schedop_shutdown, struct domain *, struct domain *)
>   
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -536,10 +536,12 @@ static int cf_check flask_console_io(str
>       return domain_has_xen(d, perm);
>   }
>   
> +#ifdef CONFIG_KEXEC
>   static int cf_check flask_kexec(void)
>   {
>       return domain_has_xen(current->domain, XEN__KEXEC);
>   }
> +#endif
>   
>   static int cf_check flask_schedop_shutdown(struct domain *d1, struct domain *d2)
>   {
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:58:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:58:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380865.1624564 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXde-0000uk-N9; Sun, 02 Aug 2026 14:58:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380865.1624564; Sun, 02 Aug 2026 14:58:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXde-0000ud-K3; Sun, 02 Aug 2026 14:58:06 +0000
Received: by outflank-mailman (input) for mailman id 1380865;
 Sun, 02 Aug 2026 14:58:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXdc-0000t9-RP
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:58:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXdc-008duG-8E
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:58:04 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5a82-e002-0a2a0a5209dd-0a2a4502b080-44
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:58:04 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5afa-6ca4-0a2a45020019-888fbc33528b-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:58:03 +0200
Received: by mx.zohomail.com with SMTPS id 1785682678158727.6091595839646;
 Sun, 2 Aug 2026 07:57:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785682680; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=l93sO3TQy5KsKGpBeegk8uZbkDc3HHjNFOP7L/lE5pT9B5le7PNaCRl/xc5DtWIMrQCEiD79IjiUnpIqyZXNJ2w6cyO110xl45PZN6sWlIiBRZB1hq+g5oZbRw2T1fO93esQhNukfA9mAKbzFDdSj7Nf1oXJ0toNhQF+WOaXUbk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785682680; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=BwGvxoIih3661XeJf2rM9xF1BG7ESvF8oCZ8jkGkMck=; 
	b=Ls/iWKGc5ghTQSB6AnUc/V7+VIBBfO83yeEO8SZFp2Zfsl4LunjtcWKqe0Rdq9utlUqjQCmUNm8l3W7JbrLwL+T83W4EFNmAOwHIMIFyn+lJdZ3fxdTALLDRv9JMzbN6mh5PLaQXUasnMzOKpaVrbCWcoNu2WcgaGRusKF0YZKs=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785682680;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=BwGvxoIih3661XeJf2rM9xF1BG7ESvF8oCZ8jkGkMck=;
	b=bfJ1m9c53Ek8zCJBV/ThB8bSFPLfARVVHg4+fj+mNoz3zNG7JsDighoVvz9T50nD
	fznLZtWDTreVRBKlbaVjc8Az6d0v63mWj+71Z1g9buwNzimdsPll1fTVh1twdu2Hup6
	Yrno74Nd0FxB+dNvMXMW2I3AQg6vzAB3v+FxCNyU=
Message-ID: <d34d4534-3bce-4792-ade4-6b69d3d4b030@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:58:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/24] XSM: make .hypfs() hook dependent upon HYPFS=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4efdae21-c8be-4fa0-825f-6369ed5d0b90@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <4efdae21-c8be-4fa0-825f-6369ed5d0b90@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-720697/1785682684-F22A92AC-E5AF4DEF/0/0
X-purgate-type: clean
X-purgate-size: 1632

On 7/28/26 9:15 AM, Jan Beulich wrote:
> It's unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -437,11 +437,13 @@ static XSM_INLINE int cf_check xsm_resou
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> +#ifdef CONFIG_HYPFS
>   static XSM_INLINE int cf_check xsm_hypfs_op(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
> +#endif
>   
>   static XSM_INLINE long cf_check xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -100,7 +100,9 @@ XSM_HOOK(int, pci_config_permission, str
>                                        uint16_t, uint8_t)
>   #endif
>   
> +#ifdef CONFIG_HYPFS
>   XSM_HOOK(int, hypfs_op)
> +#endif
>   
>   XSM_HOOK(int, hvm_param, struct domain *, unsigned long)
>   XSM_HOOK(int, hvm_param_altp2mhvm, struct domain *)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1345,10 +1345,12 @@ static int cf_check flask_resource_setup
>       return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
>   }
>   
> +#ifdef CONFIG_HYPFS
>   static inline int cf_check flask_hypfs_op(void)
>   {
>       return domain_has_xen(current->domain, XEN__HYPFS_OP);
>   }
> +#endif
>   
>   static int cf_check flask_add_to_physmap(struct domain *d1, struct domain *d2)
>   {
> 


Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 14:58:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 14:58:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380872.1624574 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXeQ-0001lo-UU; Sun, 02 Aug 2026 14:58:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380872.1624574; Sun, 02 Aug 2026 14:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXeQ-0001lf-RQ; Sun, 02 Aug 2026 14:58:54 +0000
Received: by outflank-mailman (input) for mailman id 1380872;
 Sun, 02 Aug 2026 14:58:52 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXeO-0001kH-OI
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 14:58:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXeO-00EkCO-3x
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 16:58:52 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5aa6-e002-0a2a0a5209dd-0a2a4504e618-40
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:58:52 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5b2a-b57f-0a2a45040019-888fbc33528f-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 16:58:51 +0200
Received: by mx.zohomail.com with SMTPS id 1785682725347102.55751453144865;
 Sun, 2 Aug 2026 07:58:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785682729; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=B19UDRc0SzbXVQDRZUNSVL4UsnJxj34lfr68VKa7JyhXd0TNQYun/s3jYF4VXnpKTCQ298mxoh8s7PhIhI0vfl/zOLSDJA0m5/LPjdAJyhSrMsAIEN2+LujRCZfUg+6j7xCHEekoLHi8sCvKI9aJ6inRlwihu7h1z2NAf/r3uOw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785682729; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=REvUedEfGalwFIovbtEDV+JDqejvcYhtg35ytkXdVpc=; 
	b=iut2fLazBw/vKWIM5I+TY18Yoy84paB96TVtRakN770ciFdsypzWbjrbJTc9DdrZ29G+tN/ruASZ1B6el+fpfddG8oxGDmDhu6/AXFvW9eD3mVY72QgXnDMUHjfZiRFcgPfgAlaWACDLcJxuhpp6eZpMpAHofQBOpXT8ulQIJMw=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785682729;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=REvUedEfGalwFIovbtEDV+JDqejvcYhtg35ytkXdVpc=;
	b=fTt9kgy9TUpKvDiOzOYS6va+k7lu7zY6vL+qX4HSNeajG6dip+6qDbayCJjkAG32
	BJuY/aoKYYHZaosQgYn744Vh/LVtlOVVqV9suqMpZuUH5rmySNQyRGNb775jlDJ7WVl
	PZeWxb+6z15ZYjbdm1htD5VnScTqrrSD10PLnNaA=
Message-ID: <2eb2dc6c-6a12-4f62-9966-2945c7468ad8@apertussolutions.com>
Date: Sun, 2 Aug 2026 10:58:51 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 08/24] XSM: make .hvm_altp2mhvm_op() hook dependent upon
 ALTP2M=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <5250093e-174f-4d2d-b19b-95a314b38469@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <5250093e-174f-4d2d-b19b-95a314b38469@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-ebf023/1785682732-51ED6B50-40D95FD7/0/0
X-purgate-type: clean
X-purgate-size: 1892

On 7/28/26 9:16 AM, Jan Beulich wrote:
> It's unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -583,6 +583,7 @@ static XSM_INLINE int cf_check xsm_hvm_p
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> +#ifdef CONFIG_ALTP2M
>   static XSM_INLINE int cf_check xsm_hvm_altp2mhvm_op(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t mode, uint32_t op)
>   {
> @@ -602,6 +603,7 @@ static XSM_INLINE int cf_check xsm_hvm_a
>           return -EPERM;
>       }
>   }
> +#endif /* CONFIG_ALTP2M */
>   
>   #ifdef CONFIG_VM_EVENT
>   static XSM_INLINE int cf_check xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -106,7 +106,11 @@ XSM_HOOK(int, hypfs_op)
>   
>   XSM_HOOK(int, hvm_param, struct domain *, unsigned long)
>   XSM_HOOK(int, hvm_param_altp2mhvm, struct domain *)
> +
> +#ifdef CONFIG_ALTP2M
>   XSM_HOOK(int, hvm_altp2mhvm_op, struct domain *, uint64_t, uint32_t)
> +#endif
> +
>   XSM_HOOK(int, get_vnumainfo, struct domain *)
>   
>   #ifdef CONFIG_VM_EVENT
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1393,6 +1393,7 @@ static int cf_check flask_hvm_param_altp
>       return current_has_perm(d, SECCLASS_HVM, HVM__ALTP2MHVM);
>   }
>   
> +#ifdef CONFIG_ALTP2M
>   static int cf_check flask_hvm_altp2mhvm_op(struct domain *d, uint64_t mode, uint32_t op)
>   {
>       /*
> @@ -1416,6 +1417,7 @@ static int cf_check flask_hvm_altp2mhvm_
>   
>       return current_has_perm(d, SECCLASS_HVM, HVM__ALTP2MHVM_OP);
>   }
> +#endif /* CONFIG_ALTP2M */
>   
>   #ifdef CONFIG_VM_EVENT
>   static int cf_check flask_mem_access(struct domain *d)
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 15:05:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 15:05:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380883.1624582 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXka-0005Fg-K3; Sun, 02 Aug 2026 15:05:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380883.1624582; Sun, 02 Aug 2026 15:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXka-0005FZ-HP; Sun, 02 Aug 2026 15:05:16 +0000
Received: by outflank-mailman (input) for mailman id 1380883;
 Sun, 02 Aug 2026 15:05:16 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXka-0005FT-1W
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:05:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXkZ-00BrS3-En
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 17:05:15 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5c72-bab6-0a2a0a5309dd-0a2a450bd02a-48
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:05:14 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5ca8-b7e8-0a2a450b0019-888fbc33529e-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:05:14 +0200
Received: by mx.zohomail.com with SMTPS id 1785683108310689.3839985231745;
 Sun, 2 Aug 2026 08:05:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785683110; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=kJGfvfFGGUdVCpdJp0jQBcqrzBM3AF3QTRgXkCiwTAlasW1Tz/uqmlaXNDeR8aPGmBUVQc6dht9ugFn4P4PoEjJa4FqyiWLVpkvpnkIhE74NSsq7ZBZfloe/b8XwdxOBbVpv4ulNO/HqFWsL4z84pelKjgimt+Vc3QrzjtmAseI=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785683110; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=kjBmZcGw1BB42KQvYs/PpCClxsoGAWvtXvcmYYyz9s0=; 
	b=XRWg9THcX6KTmkb5++uWQkMaduSCGYjCm9jhlicmqS2JCG9RuufQLpCT41D4lgsb9Puu7xl+8qVTeTwMWcF3AjuZ4cyvtUsk21OwwtBYOjIn4hPrF/T4B/vQF18mvvuXMty7jGUM7TyOeXKWLo08I4e9dz7cuLkfJEM3Yb6YFCU=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785683110;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=kjBmZcGw1BB42KQvYs/PpCClxsoGAWvtXvcmYYyz9s0=;
	b=pvZDpAi7RQVMdnqXLKQdxQbBukZYsZdO21SMZWPQBygNQjcwomaL1cBtc4NO2nJV
	Cqhhg5b8rM6oo+RFbaq7Zk85KcsswOss0rcvD9hssAbj2JggIOeCI9Fl09zDycSUnQ6
	y5GxxKBxECXzCMa0Rs0s7ZzUG07IB7XL5kulZvUc=
Message-ID: <1b4d5a82-bdc4-460d-a5a4-59e788fe1c3f@apertussolutions.com>
Date: Sun, 2 Aug 2026 11:05:14 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 09/24] XSM: make .hvm_param*() hooks dependent upon HVM=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <7947b62f-6763-4561-b3aa-c451cfa3dacb@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <7947b62f-6763-4561-b3aa-c451cfa3dacb@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-42698a/1785683114-19AC09EA-985CE3FF/0/0
X-purgate-type: clean
X-purgate-size: 2234



On 7/28/26 9:17 AM, Jan Beulich wrote:
> They're unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Strictly speaking .hvm_param_altp2mhvm() is dependent upon X86=y as well
> (but oddly not dependent upon ALTP2M=y).
> 

At a minimum, would it be worth at least adding a comment about the 
dependency? Note, this is just a question/suggestion.

> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -569,6 +569,8 @@ static XSM_INLINE int cf_check xsm_map_g
>       return xsm_default_action(action, d, t);
>   }
>   
> +#ifdef CONFIG_HVM
> +
>   static XSM_INLINE int cf_check xsm_hvm_param(
>       XSM_DEFAULT_ARG struct domain *d, unsigned long op)
>   {
> @@ -583,6 +585,8 @@ static XSM_INLINE int cf_check xsm_hvm_p
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> +#endif /* CONFIG_HVM */
> +
>   #ifdef CONFIG_ALTP2M
>   static XSM_INLINE int cf_check xsm_hvm_altp2mhvm_op(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t mode, uint32_t op)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -104,8 +104,10 @@ XSM_HOOK(int, pci_config_permission, str
>   XSM_HOOK(int, hypfs_op)
>   #endif
>   
> +#ifdef CONFIG_HVM
>   XSM_HOOK(int, hvm_param, struct domain *, unsigned long)
>   XSM_HOOK(int, hvm_param_altp2mhvm, struct domain *)
> +#endif
>   
>   #ifdef CONFIG_ALTP2M
>   XSM_HOOK(int, hvm_altp2mhvm_op, struct domain *, uint64_t, uint32_t)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1368,6 +1368,8 @@ static int cf_check flask_map_gmfn_forei
>       return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
>   }
>   
> +#ifdef CONFIG_HVM
> +
>   static int cf_check flask_hvm_param(struct domain *d, unsigned long op)
>   {
>       uint32_t perm;
> @@ -1393,6 +1395,8 @@ static int cf_check flask_hvm_param_altp
>       return current_has_perm(d, SECCLASS_HVM, HVM__ALTP2MHVM);
>   }
>   
> +#endif /* CONFIG_HVM */
> +
>   #ifdef CONFIG_ALTP2M
>   static int cf_check flask_hvm_altp2mhvm_op(struct domain *d, uint64_t mode, uint32_t op)
>   {
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 15:05:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 15:05:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380885.1624592 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXkv-0005ap-S4; Sun, 02 Aug 2026 15:05:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380885.1624592; Sun, 02 Aug 2026 15:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXkv-0005ai-OX; Sun, 02 Aug 2026 15:05:37 +0000
Received: by outflank-mailman (input) for mailman id 1380885;
 Sun, 02 Aug 2026 15:05:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXkv-0005aO-7U
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:05:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXku-001xcr-KX
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 17:05:36 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5cad-5cb7-0a2a0a5109dd-0a2a450aaae0-14
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:05:36 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5cbe-f2d2-0a2a450a0019-888fbc3352a0-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:05:36 +0200
Received: by mx.zohomail.com with SMTPS id 17856831301261005.6998583405325;
 Sun, 2 Aug 2026 08:05:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785683132; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ZqRPG8fvxCgZkK6LfxcjzyLWWaAJMA0zF2gyrQYLnCF5YUoYJ3JZbEhgIBp0Fm+EjJlstpnaOPFEIUG2/nr9RH6xEvr7Zz5A/oFqUwsd2/bZPs4bewecFkTABqk3zlVo7mkYXOqAn3hHfeIu8d6K5rraOSYcOLwj2Ns9IHu9dnQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785683132; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=kjBmZcGw1BB42KQvYs/PpCClxsoGAWvtXvcmYYyz9s0=; 
	b=VVFMidnOq0R+4tZfTf65HbPRZ4tF8Q3bVxzyQBgU+MoqUBIBzmXw9ibdzmBqR+wNQeOqqLBsAw2hAi55Q+pWUYgnnunDjq3/GuDrpd46qxvERVoM3uE/v5Xix0kLTmQxuWymRRccbAds3rGSHjL9gGvt/uE5oh6KnYPzrVGNPMw=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785683132;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=kjBmZcGw1BB42KQvYs/PpCClxsoGAWvtXvcmYYyz9s0=;
	b=PUryuzvMSDtOuPz3h8gCgH52EVpu9tTiXPdUIY5g0IrYApwwtw7Tr02a2IYu3MTX
	MGp5W9WsIfvahnjtuyfpHThEX/cAcEKzgVWncSBBK17L7nMC0p4XTticL4KZabSY8yK
	pLs3QFtrb52qJTEiG6BBlOgxmqpLG4BlXfSU7qSk=
Message-ID: <fd247260-8bad-44f1-adf4-5bae43a1e55b@apertussolutions.com>
Date: Sun, 2 Aug 2026 11:05:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 09/24] XSM: make .hvm_param*() hooks dependent upon HVM=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <7947b62f-6763-4561-b3aa-c451cfa3dacb@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <7947b62f-6763-4561-b3aa-c451cfa3dacb@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-4011c0/1785683136-59DDFCFC-E3355295/0/0
X-purgate-type: clean
X-purgate-size: 2234



On 7/28/26 9:17 AM, Jan Beulich wrote:
> They're unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Strictly speaking .hvm_param_altp2mhvm() is dependent upon X86=y as well
> (but oddly not dependent upon ALTP2M=y).
> 

At a minimum, would it be worth at least adding a comment about the 
dependency? Note, this is just a question/suggestion.

> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -569,6 +569,8 @@ static XSM_INLINE int cf_check xsm_map_g
>       return xsm_default_action(action, d, t);
>   }
>   
> +#ifdef CONFIG_HVM
> +
>   static XSM_INLINE int cf_check xsm_hvm_param(
>       XSM_DEFAULT_ARG struct domain *d, unsigned long op)
>   {
> @@ -583,6 +585,8 @@ static XSM_INLINE int cf_check xsm_hvm_p
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> +#endif /* CONFIG_HVM */
> +
>   #ifdef CONFIG_ALTP2M
>   static XSM_INLINE int cf_check xsm_hvm_altp2mhvm_op(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t mode, uint32_t op)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -104,8 +104,10 @@ XSM_HOOK(int, pci_config_permission, str
>   XSM_HOOK(int, hypfs_op)
>   #endif
>   
> +#ifdef CONFIG_HVM
>   XSM_HOOK(int, hvm_param, struct domain *, unsigned long)
>   XSM_HOOK(int, hvm_param_altp2mhvm, struct domain *)
> +#endif
>   
>   #ifdef CONFIG_ALTP2M
>   XSM_HOOK(int, hvm_altp2mhvm_op, struct domain *, uint64_t, uint32_t)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1368,6 +1368,8 @@ static int cf_check flask_map_gmfn_forei
>       return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
>   }
>   
> +#ifdef CONFIG_HVM
> +
>   static int cf_check flask_hvm_param(struct domain *d, unsigned long op)
>   {
>       uint32_t perm;
> @@ -1393,6 +1395,8 @@ static int cf_check flask_hvm_param_altp
>       return current_has_perm(d, SECCLASS_HVM, HVM__ALTP2MHVM);
>   }
>   
> +#endif /* CONFIG_HVM */
> +
>   #ifdef CONFIG_ALTP2M
>   static int cf_check flask_hvm_altp2mhvm_op(struct domain *d, uint64_t mode, uint32_t op)
>   {
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 15:07:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 15:07:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380898.1624600 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXmt-0006lc-Bk; Sun, 02 Aug 2026 15:07:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380898.1624600; Sun, 02 Aug 2026 15:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXmt-0006lV-98; Sun, 02 Aug 2026 15:07:39 +0000
Received: by outflank-mailman (input) for mailman id 1380898;
 Sun, 02 Aug 2026 15:07:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXmr-0006jH-Qa
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:07:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXmq-008fFA-F7
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 17:07:36 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5d37-bab6-0a2a0a5309dd-0a2a450ac334-2
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:07:36 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5d36-f2d2-0a2a450a0019-888fbc3352a2-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:07:36 +0200
Received: by mx.zohomail.com with SMTPS id 1785683251443735.8930538915141;
 Sun, 2 Aug 2026 08:07:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785683253; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=F8rudERShobwyQAzml22u79eQoqJpuYeUFVBRoRrGH3/Akju7tILgCxvOuoUzZroUFWD0JCFs+mdW/Vc6z+ogRGH8zHv0/XQlWoOTdWeIF/gOMyQaNp29GLe4y2Z9tWMJ/75+LAAZZ3gCd8GutjY2lUbrw1BnH2HV3cEpsPpI1s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785683253; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=oGbJXX1sOwuN6ygD60/WQFIBvc8kIT+FhnM8E4QOS08=; 
	b=nkP994rG7e6bybsqEwslBt8M0JIQ4NEgVCNF41IGBBiWFLg4UwyX2bodRnkLKo7iQY0ie4Y9SBq0xA4OIVll7iQ9LSrdjHsgYCXY61H+srAuPR5ZwzdDntLtbZmV2hxG59hASpq/ykjER/8eooW6616p7/2M3aIyPx1jPO+oO7k=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785683253;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=oGbJXX1sOwuN6ygD60/WQFIBvc8kIT+FhnM8E4QOS08=;
	b=ZhbzfgLWaZ9qftjnBy9vtDV3G3twPnOqdJ6iVrfqSh4f4eeejQn484ergTjW7o3m
	F3F4KmRUq+JUXCOPBE1jDmimPzyTEQBpcuC4gW/7Ci13E7XbhRwd/IowmZBRor2lD1a
	vvNGD2x6tztEOIWboXMr89cnaNiQWk747ZKUGYhs=
Message-ID: <821c7414-f0fc-4f18-88e7-294e8e5d78c7@apertussolutions.com>
Date: Sun, 2 Aug 2026 11:07:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/24] XSM: make .dm_op() hook dependent upon
 IOREQ_SERVER=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <9ecda750-f0b5-49ad-9f6b-892a045b3b66@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <9ecda750-f0b5-49ad-9f6b-892a045b3b66@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-4011c0/1785683256-52CDBCFC-606E0E30/0/0
X-purgate-type: clean
X-purgate-size: 1550

On 7/28/26 9:17 AM, Jan Beulich wrote:
> It's unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -739,11 +739,13 @@ static XSM_INLINE int cf_check xsm_pmu_o
>   
>   #endif /* CONFIG_X86 */
>   
> +#ifdef CONFIG_IOREQ_SERVER
>   static XSM_INLINE int cf_check xsm_dm_op(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
> +#endif
>   
>   #ifdef CONFIG_ARGO
>   static XSM_INLINE int cf_check xsm_argo_enable(const struct domain *d)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -145,7 +145,10 @@ XSM_HOOK(int, ioport_mapping, struct dom
>   XSM_HOOK(int, pmu_op, struct domain *, unsigned int)
>   #endif /* CONFIG_X86 */
>   
> +#ifdef CONFIG_IOREQ_SERVER
>   XSM_HOOK(int, dm_op, struct domain *)
> +#endif
> +
>   XSM_HOOK(int, xen_version, uint32_t)
>   XSM_HOOK(int, domain_resource_map, struct domain *)
>   
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1852,10 +1852,12 @@ static int cf_check flask_pmu_op(struct
>   }
>   #endif /* CONFIG_X86 */
>   
> +#ifdef CONFIG_IOREQ_SERVER
>   static int cf_check flask_dm_op(struct domain *d)
>   {
>       return current_has_perm(d, SECCLASS_HVM, HVM__DM);
>   }
> +#endif
>   
>   static int cf_check flask_xen_version(uint32_t op)
>   {
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 15:08:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 15:08:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380905.1624610 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXo9-0007tN-MQ; Sun, 02 Aug 2026 15:08:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380905.1624610; Sun, 02 Aug 2026 15:08:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqXo9-0007tG-Ie; Sun, 02 Aug 2026 15:08:57 +0000
Received: by outflank-mailman (input) for mailman id 1380905;
 Sun, 02 Aug 2026 15:08:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqXo7-0007t4-Qi
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:08:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqXo7-008fpt-7T
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 17:08:55 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5d46-bab6-0a2a0a5309dd-0a2a4509a026-46
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:08:54 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f5d84-be1a-0a2a45090019-888fbc3352a5-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:08:54 +0200
Received: by mx.zohomail.com with SMTPS id 1785683328710862.2007758395154;
 Sun, 2 Aug 2026 08:08:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785683331; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=gkAqGa9mq9pC4fe6AcmrOrsZOfqoSQDpY3E+Ku9Xb8nAwFuD4kMkC62nUfpSL4cS0hJVpO8KTPxr2UMbZ4Wdg63nsPL7BRyw6YkijqiXQcSqC82E5/LtZnKjlVikYnEP5bnsbo10cRM2tdW/+XFWgnUcPKYlQCRHegAIbM+NcU4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785683331; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=VmVxueIYKCLre29nUNWrpK8gnn6byJI0KMoNwXHmXbQ=; 
	b=j6gyWH4cPkZtqkqC2N2kHUSJjZ+7dcnaTRlL9WsXUidQ1kQ8Lj8pWs7COkKetGxQohnpeGHC+z+fgpeQdGK6p07vU1ADPt3W192g0PnRmPtA581yW6g9SBFywICJlghNZQ/HmXs+woiDSMd6Zpj0c9/4O7BsYkATZsIqhwMIQMk=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785683331;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=VmVxueIYKCLre29nUNWrpK8gnn6byJI0KMoNwXHmXbQ=;
	b=tRzJkfX4BLAucN9+kOWarZnM4vcrESq8Kj0tzWAqNV4oLFf9dkRk+MBA3TyNV3HD
	vbrV7XbDCywF30sgBs7duBTM6YmVPiKWxhvouAELuuOVbau+Ehb2lSXyJxBZa9/2Zej
	YO74KH+vpRqwvF5kzjy+elktfNHKmTXbeMXdJpXE=
Message-ID: <611d7bf0-94c4-4743-8d95-437d1729b9e4@apertussolutions.com>
Date: Sun, 2 Aug 2026 11:08:55 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/24] XSM: make certain x86-specific hooks dependent upon
 PV=y
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <73257c34-3a86-46a2-b327-f35bff69399d@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <73257c34-3a86-46a2-b327-f35bff69399d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-bad1c0/1785683334-3A2C4034-07BDC739/0/0
X-purgate-type: clean
X-purgate-size: 3541

On 7/28/26 9:18 AM, Jan Beulich wrote:
> They're unreachable / dead otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -640,11 +640,6 @@ static XSM_INLINE int cf_check xsm_platf
>   }
>   
>   #ifdef CONFIG_X86
> -static XSM_INLINE int cf_check xsm_do_mca(XSM_DEFAULT_VOID)
> -{
> -    XSM_ASSERT_ACTION(XSM_PRIV);
> -    return xsm_default_action(action, current->domain, NULL);
> -}
>   
>   static XSM_INLINE int cf_check xsm_mem_sharing_op(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *cd, int op)
> @@ -673,6 +668,14 @@ static XSM_INLINE int cf_check xsm_domai
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> +#ifdef CONFIG_PV
> +
> +static XSM_INLINE int cf_check xsm_do_mca(XSM_DEFAULT_VOID)
> +{
> +    XSM_ASSERT_ACTION(XSM_PRIV);
> +    return xsm_default_action(action, current->domain, NULL);
> +}
> +
>   static XSM_INLINE int cf_check xsm_mmu_update(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *t, struct domain *f,
>       uint32_t flags)
> @@ -700,6 +703,8 @@ static XSM_INLINE int cf_check xsm_updat
>       return xsm_default_action(action, d, f);
>   }
>   
> +#endif /* CONFIG_PV */
> +
>   static XSM_INLINE int cf_check xsm_priv_mapping(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>   {
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -131,14 +131,16 @@ XSM_HOOK(int, mem_sharing_op, struct dom
>   XSM_HOOK(int, platform_op, uint32_t)
>   
>   #ifdef CONFIG_X86
> -XSM_HOOK(int, do_mca)
>   XSM_HOOK(int, apic, struct domain *, int)
>   XSM_HOOK(int, machine_memory_map)
>   XSM_HOOK(int, domain_memory_map, struct domain *)
> +#ifdef CONFIG_PV
> +XSM_HOOK(int, do_mca)
>   XSM_HOOK(int, mmu_update, struct domain *, struct domain *, struct domain *,
>                             uint32_t)
>   XSM_HOOK(int, mmuext_op, struct domain *, struct domain *)
>   XSM_HOOK(int, update_va_mapping, struct domain *, struct domain *, l1_pgentry_t)
> +#endif /* CONFIG_PV */
>   XSM_HOOK(int, priv_mapping, struct domain *, struct domain *)
>   XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, uint8_t)
>   XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, uint8_t)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1654,10 +1654,6 @@ static int cf_check flask_platform_op(ui
>   }
>   
>   #ifdef CONFIG_X86
> -static int cf_check flask_do_mca(void)
> -{
> -    return domain_has_xen(current->domain, XEN__MCA_OP);
> -}
>   
>   static int flask_shadow_control(struct domain *d, unsigned int op)
>   {
> @@ -1783,6 +1779,13 @@ static int cf_check flask_domain_memory_
>       return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
>   }
>   
> +#ifdef CONFIG_PV
> +
> +static int cf_check flask_do_mca(void)
> +{
> +    return domain_has_xen(current->domain, XEN__MCA_OP);
> +}
> +
>   static int cf_check flask_mmu_update(
>       struct domain *d, struct domain *t, struct domain *f, uint32_t flags)
>   {
> @@ -1823,6 +1826,8 @@ static int cf_check flask_update_va_mapp
>       return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
>   }
>   
> +#endif /* CONFIG_PV */
> +
>   static int cf_check flask_priv_mapping(struct domain *d, struct domain *t)
>   {
>       return domain_has_perm(d, t, SECCLASS_MMU, MMU__TARGET_HACK);
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Sun Aug 02 15:55:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Aug 2026 15:55:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1380929.1624618 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqYXP-0004Xw-0z; Sun, 02 Aug 2026 15:55:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1380929.1624618; Sun, 02 Aug 2026 15:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqYXO-0004Xp-Ud; Sun, 02 Aug 2026 15:55:42 +0000
Received: by outflank-mailman (input) for mailman id 1380929;
 Sun, 02 Aug 2026 15:55:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wqYXN-0004Xi-4d
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 15:55:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqYXM-004wkr-31
 for xen-devel@lists.xenproject.org; Sun, 02 Aug 2026 17:55:40 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f6811-2eae-0a2a0a5409dd-0a2a4502e798-20
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:55:40 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a6f687a-6ca4-0a2a45020019-888fbc3352c0-3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 17:55:39 +0200
Received: by mx.zohomail.com with SMTPS id 1785686126692449.7937048040851;
 Sun, 2 Aug 2026 08:55:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785686130; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=femSRGpdtG1BdsSysSvXCjllA1p3DfbD2+gwqZf5uNIuoycZlm3/bX3TcQC2dW3bokA0PEsssCvVjtVFi+0YzXjzqSym8rCp/sMbg36e7LwZu4QXwuGG42TFBtOCPA+OkCcC1AJdWrFnX3ynRJbge2zfjCClHkqa059l7s6yH6w=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785686130; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=Ei3nv7dzYgzxJ0zw1X14Ri/+yYhgMiX6VePRG6aHTzo=; 
	b=YXmRxHxjFX8ACwZRrOppyKhrHb5RXSLVz3XMS/RLtI2Z7Nd5IK5RuHpwhp6KWU6oW93gaiFMDei2nyk/nSmBpjIU8n48v14GoDorIaN3B3Y//LT86boQQBI7z8zRIuIl9UJ+f8zJdDWUAoY/unbJds5DIPk0VTyEqc5M+YtI9Xc=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785686130;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Ei3nv7dzYgzxJ0zw1X14Ri/+yYhgMiX6VePRG6aHTzo=;
	b=AohwUeyxTP2qY3/F4Xuw5AfjejshtKyhD3UD33nc4WVw73Dj/lTaG9dN8jkzo8Qm
	naXs7+2VDhJMw4WqNpPRjM0Jl9wiSFObQzum9X+dDROOZhreHilrrY6Tq+Ses/h9Ksz
	bmDeejVIsYQ3GnHLeiJ+xcI/u5TnPtcp8IQ5LVNA=
Message-ID: <4531d02a-3a37-4c57-ba17-32034ba08cf9@apertussolutions.com>
Date: Sun, 2 Aug 2026 11:55:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <07e90200-95b5-413f-9259-7f0481d36521@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <07e90200-95b5-413f-9259-7f0481d36521@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-720697/1785686140-F34BE2AC-A92D1B94/0/0
X-purgate-type: clean
X-purgate-size: 3700

On 7/28/26 9:18 AM, Jan Beulich wrote:
> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
> With the function compiled out, its dedicated XSM hook also becomes
> unreachable, so it is similarly guarded.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> It feels suspicious that the .priv_mapping() check is used for HVM guests
> in shadow mode, but not for ones in HAP mode.
> 


I believe a hint to it is laying in the comment,

  /*
   * Let privileged domains transfer the right to map their target
   * domain's pages. This is used to allow stub-domain pvfb export to
   * dom0, until pvfb supports granted mappings. At that time this
   * minor hack can go away.
   */

Correct me if I am wrong, but get_page_from_l1e() is only used by PV and 
HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done 
through p2m_get_foreign() which will then be covered by 
xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check.

I think the question is how to address the TARGET_HACK situation.

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -837,6 +837,8 @@ static int cf_check print_mmio_emul_rang
>   }
>   #endif
>   
> +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
> +
>   /*
>    * get_page_from_l1e returns:
>    *   0  => success (page not present also counts as such)
> @@ -1038,6 +1040,8 @@ get_page_from_l1e(
>       return -EBUSY;
>   }
>   
> +#endif /* CONFIG_PV || CONFIG_SHADOW_PAGING */
> +

Would it also not be prudent to #ifdef out the declaration in asm/mm.h?

>   /*
>    * The following flags are used to specify behavior of various get and
>    * put commands.  The first is also stored in page->partial_flags to
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -705,12 +705,14 @@ static XSM_INLINE int cf_check xsm_updat
>   
>   #endif /* CONFIG_PV */
>   
> +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
>   static XSM_INLINE int cf_check xsm_priv_mapping(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d, t);
>   }
> +#endif
>   
>   static XSM_INLINE int cf_check xsm_ioport_permission(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -141,7 +141,9 @@ XSM_HOOK(int, mmu_update, struct domain
>   XSM_HOOK(int, mmuext_op, struct domain *, struct domain *)
>   XSM_HOOK(int, update_va_mapping, struct domain *, struct domain *, l1_pgentry_t)
>   #endif /* CONFIG_PV */
> +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
>   XSM_HOOK(int, priv_mapping, struct domain *, struct domain *)
> +#endif
>   XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, uint8_t)
>   XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, uint8_t)
>   XSM_HOOK(int, pmu_op, struct domain *, unsigned int)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1828,10 +1828,12 @@ static int cf_check flask_update_va_mapp
>   
>   #endif /* CONFIG_PV */
>   
> +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
>   static int cf_check flask_priv_mapping(struct domain *d, struct domain *t)
>   {
>       return domain_has_perm(d, t, SECCLASS_MMU, MMU__TARGET_HACK);
>   }
> +#endif
>   
>   static int cf_check flask_pmu_op(struct domain *d, unsigned int op)
>   {
> 

I think it would be a good defensive approach to condition out the 
header declaration. Otherwise,

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 00:43:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 00:43:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381047.1624628 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqgmM-0003qU-V6; Mon, 03 Aug 2026 00:43:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381047.1624628; Mon, 03 Aug 2026 00:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqgmM-0003qN-SH; Mon, 03 Aug 2026 00:43:42 +0000
Received: by outflank-mailman (input) for mailman id 1381047;
 Mon, 03 Aug 2026 00:43:40 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wqgmJ-0003ot-Ob
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 00:43:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqgmI-005yV6-J9
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 02:43:38 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a6fe3ef-5cb7-0a2a0a5109dd-0a2a4503c442-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 02:43:37 +0200
Received: from [52.101.229.77]
 (helo=TY3P286CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a6fe435-fae8-0a2a45030019-3465e54d30cb-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 02:43:36 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by TY4P286MB6832.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:33d::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.17; Mon, 3 Aug
 2026 00:43:30 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0270.016; Mon, 3 Aug 2026
 00:43:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rA9hT+sa4szRgERS2SV9xt8KlQK4HrAtCc12HvBmBsd+xR1ziyBGdy5+juifdkwoC/rn8d7sNz3sLiePjoC+mDo+gDhr6sLeL3mqRhYuv0c8+KwtUbFV5vD8LW41ZbOpXAsIo1yO8x35X2m4kcKUiMzEfuaFixET8hivp0+G9AGsZXVHUbiCCXQwrpVzFkg0t9BrVfKxxXoolggyBzbeNILXtMGw3l+b9MT5uh7fVs8xkC+OgS+Ytx7xtUN1Ku1mDW217AcBF2quRhZRAlZGrH8yExXDpXcRyS8ml/3grW6o6COno6jmo51YrHSDhShEHDItuUrlv7XkIo2opa/JWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kvw2bZDRO4ch9uDZj3X9HF2N3NA+5bsuvObC4KDg1bg=;
 b=OyaU3Idm/mIEq8WjM7GGtuFtkSqMx38BRcMowGSYXY71wp0yOmA8+dWXgHKkiv3FYF71WalwGslaWYhMx+EZ56wVM5pPZ5wHVKa3pN2JxLWD7nIe/SabsZeCrAr9CJO2df7c4gEiIW9MxKlVifu3xDRKRyFtb9MsAoCuuqBIzVB0gvl5kA5NEbXIP1z7/JjJp2tdGOKust5FwZoZbz0Fun1dPXKzOe7LcAy01+IjWG3IGBI73ht8we5O4Rp7vuXxgf5GctFVB3RPWgGaafuvLEjkfGpy5z8YOh0mzP2nFBm+Tlv3YpeRyanjBr9V+yEzi/DtmGeW+3g5AWWvOpKdLQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kvw2bZDRO4ch9uDZj3X9HF2N3NA+5bsuvObC4KDg1bg=;
 b=fMOdVn+7tR9FGFOg918I/2afUpjc9XopkmsicTAgSnw1sh6dZQrgjvR9q3aU8jfDGrUNLS5eiDu8re6SmO4a25XKGGZaytopZjJ58Z64zxOixq8bOxqSs5Mz+KjHZYQQ2xLqONyxHz7IhiT7fz3AzeiyR9w7eo9TjuOUjoi39io=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: xen-devel@lists.xenproject.org
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH] xen/arm: Hide PMU feature
Date: Mon,  3 Aug 2026 09:42:45 +0900
Message-ID: <20260803004245.693844-1-taka@valinux.co.jp>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TYCP301CA0088.JPNP301.PROD.OUTLOOK.COM
 (2603:1096:405:7b::16) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:458::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TY4P286MB6832:EE_
X-MS-Office365-Filtering-Correlation-Id: fcb177a8-fa86-4813-bddb-08def0f83ce4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10070799003|6133799003|56012099006|10067099003|3023799007|18002099003;
X-Microsoft-Antispam-Message-Info:
	T1GUEAOioOQ92ui6AMagEoTbboKNSNDbtEH8F/93oLwArBS8b4hicyNl/yizmOHyekSn/cuSJCQ+RMmhjS6RiZmxuFobYIED3P0sGzXyvobOsrSiCt+mgLYfGOQ0PE+90nEWNrTAAF1eS6SGfjKWvAUKF+RnBUvZAQG7uT9sIG8uuDNi7yY8dTdhVfVITzVU8EE3ka2pPcan1YeCuB1Ndy2D08uughljFtNUPCQwmtiSWlElv+siU/AwpnUyiwh2Nz8P7vklVHzY5mGXfJS2f0wZx5YNZZcxkWjCbnbT1u6GY/2wteWfR2oKc57NwwIj66sJafnW5PE8SA1h7colV/AMTBX3de2jZ+1n+6Fdd20BIP4+pZE9Enq/pIaCLTglpv58Qhv2v0LDWBQZGkoEugOMmQhSUiuZj+PPPJIoY0MV8S00LbHWI2BjEZa9WAL8XyfDfBHTxK9gVAv0I28WHOdGeUe5RWE6unOkXaZ7NTrAxacEKNzWX6CEVL4IgqhYcKtj6D6kTCLjk3L7KyzMUjPirh0F/YKZaokuO/Zq5vG/fWzdEn+pkibesCt7XRpJ2zX2vDt8n2svBiDJPzbVk8GSf6W9vKPx66OkRgIdkBWqlMXsKwJT+Emr+a3qGwJz7f7dhNGiT8r9kpfnxrtN7i0j7tg0WSMknrv95iM/sQk=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10070799003)(6133799003)(56012099006)(10067099003)(3023799007)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?UhLnIU58IMMx34DuAEHo6WrkDvlLgpd30l0emMyayayhCx6u9O+BbHlbB4KU?=
 =?us-ascii?Q?WqYxxr73TU3HKhGdXXdjFtasOkGZ2pYGQRusUWatgwBkwWjE7lG9Xo/mpdnX?=
 =?us-ascii?Q?kBXpQ22mdTfKdrrg6Go0xRsUDs3QYWSE8Pgtc0Zny+tHznnqiuYwLPXC/Tgr?=
 =?us-ascii?Q?2vM4GkM19xX7tO3Xo9nllXq9yn0++EN0taLWikliwetVg76aRj5UIZTNV2tq?=
 =?us-ascii?Q?ysPCa9EATIkQ8T5e//2Hn+zo3QnhsHaSpxF/tML0mpTLsicM+bcdIzEu8HuA?=
 =?us-ascii?Q?aiB3O9xCCEhZNg3LkgemmcoqXGaGHkh8wxurlmsgvaNkrAa5QOSyde3YE/p0?=
 =?us-ascii?Q?mu2kH/gJcWgV2eiWFoPi+fIOEsUEHV6FGNSxx+aPuoubaqQGBT6MXcPtlOOB?=
 =?us-ascii?Q?7TpP1dFygU1Ndgbgv/6zfhJsOfLDqjrqiayu3vFktvaMvWsW1/ZCk6Wyd7SO?=
 =?us-ascii?Q?QWrtr3Zl5cHjq7HrERBvlvE97xyv/quZH5FxJSGWRStexkMI3bBSSWtQALmy?=
 =?us-ascii?Q?nq61COAKDqnOYyBK1Ga1lmHnizmGOCM2QhDwZlPDIk7sw8nai9mTmXWxy+zF?=
 =?us-ascii?Q?Qt+64WGRuUrHw9xk7Nh09KgYQDoC1LV+H0XUWmNDPy+hbsRA5+yj1KGPJ90j?=
 =?us-ascii?Q?CWn6JUCy7HTq7weMcWkGh5JzuyuQHLn1P/5Xm233qe2tBWtKXmklH424UFPt?=
 =?us-ascii?Q?1talkQyfqWSrwSQFwOLraBI1ugS0WYZt6AD5X0SlAtpUK8hFNsDu1rJWLRmf?=
 =?us-ascii?Q?D4HC27U3r5RLDZHTGulXX9I2BpvS8e/x0QGeorwa71WO6DX+V8ZyrwXMudPY?=
 =?us-ascii?Q?AcZo0M6RnvcVJrv7L+w/C9zAJx7Rh7CtejnLxJIHg9DJWVVVmb8u2FAcmAyp?=
 =?us-ascii?Q?T05C2WWNTxx5y1mpWTtlvyJ2zw+IIsIZjTlOq61Hh1YAWRNPggn16yZQnN4O?=
 =?us-ascii?Q?RlQu1nsYPnsIVVTcj0DuXV7qBL8NX6G9jDGUIYqpjyGdjts9/UgFV+Y5Fq1K?=
 =?us-ascii?Q?UBQJzDk+0JQw+/ZO329gb5Uc6hSAml2hsAVAIfbYEdWssLx/HCCshMMft8GL?=
 =?us-ascii?Q?Ek0MN31bw6exGx3/hFxfsq1JKpkzMo9T99Xuq5DZSA9VcZRN0xg0YhE3HGOp?=
 =?us-ascii?Q?urtbCztm5P9+qxZbwx86L/9daBvqTeQwPaiSJwn3gXxiaJ2ykIlrQcQpYaOS?=
 =?us-ascii?Q?biCEgpluiIlk70OrdXWUOpkdVYk3q9ggU2D3EfXt/H2Uf+5QgAR6rgfeNC0S?=
 =?us-ascii?Q?kdCQAIN0gKwCxkctA+7yDxfN77QxrUDIZjVThsMMrmrYu2GCMWAD+vX1BS4Q?=
 =?us-ascii?Q?AkD/hgY+XkgvwzXA07Pp9hd9ipbNPceGQIXkkGWW4Bz57eIhac6neBT5gVe+?=
 =?us-ascii?Q?Msm/wLv5t2jgO/uyE20lMfgTLF+iLFqHhj+SajhTTwyUYpr6AclIX/vs3FAQ?=
 =?us-ascii?Q?OIHKX2pTXt68QNgBe7oW/nAWI0aVv/KTr5WDQjF9xt6SIPSUVM8IM2xMQ7AH?=
 =?us-ascii?Q?fUBJIF11G70MtgAANSMUL+JtTPdA4KUHuegJ49I9KOAWrFcB2XtddrnBdYSe?=
 =?us-ascii?Q?LPe9GOuExarVrZQPrEsiathAWUAO+Amvk8y2LHxePi1ud005mzjhsKauesug?=
 =?us-ascii?Q?58E1xueE4jNv4aQwfxrSyZpN0zvKfSrfyg0CgR0dfVuqRivGijwykdqnKAae?=
 =?us-ascii?Q?4fKARNmzCGtXsi0xFtagQj9uEq9sLMxcetEdpcvv5/yWsEcLo9Ehlp5FdAIW?=
 =?us-ascii?Q?hHOYEvC5jMdBgeA1YufaiPFIf7jq8LlJogUPG9iSPuArBXpVpyEwc3ABib2h?=
X-MS-Exchange-AntiSpam-MessageData-1: b2bE5gGc3lAy5A==
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: fcb177a8-fa86-4813-bddb-08def0f83ce4
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 00:43:30.0171
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gOdmSPcxDyK0PnSaP+QFHQPocYBGPNVA6OVABotbqZlWQNI/KVED28E4U4sWbuwegml4kw2+bY4AzswB+flOfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY4P286MB6832
X-purgate-ID: tlsNG-33051d/1785717817-762FD4E9-C3C8A53F/0/0
X-purgate-type: clean
X-purgate-size: 3049

On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
causes the domain to probe advanced PMU feature based on system ID
register ID_AA64DFR0_EL1.

During this probe, Linux accesses PMMIR_EL1, which causes unhandled
register traps and crashes the domain. Merely adding emulation code
for PMMIR_EL1 in Xen is insufficient to fix the issue, as the guest
PMU driver subsequently stalls during its initialization sequence.

Fix this by explicitly masking PMU capability fields in
create_domain_cpuinfo(). Additionally, preemptively mask other
capability fields to prevent similar potential issues.

Fixes: 3669a1cb9598 "xen/arm: create a cpuinfo structure for guest"
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
---
 xen/arch/arm/cpufeature.c             | 16 ++++++++++++++++
 xen/arch/arm/include/asm/cpufeature.h | 10 ++++++----
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 94d14fb6a9..71d745d3cb 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -219,8 +219,24 @@ static int __init create_domain_cpuinfo(void)
     domain_cpuinfo.isa64.api = 0;
     domain_cpuinfo.isa64.gpa = 0;
     domain_cpuinfo.isa64.gpi = 0;
+
+    /* Hide PMUv3 support as Xen does not support it */
+    domain_cpuinfo.dbg64.pmu_ver = 0;
+    domain_cpuinfo.dbg64.mtpmu = 0;
+    domain_cpuinfo.dbg64.pmss = 0;
+
+    /* Hide SPE, TRBE, BRBE, and Trace Extensions */
+    domain_cpuinfo.dbg64.pms_ver = 0;
+    domain_cpuinfo.dbg64.trace_ver = 0;
+    domain_cpuinfo.dbg64.trace_filt = 0;
+    domain_cpuinfo.dbg64.trace_buffer = 0;
+    domain_cpuinfo.dbg64.ext_trc_buff = 0;
+    domain_cpuinfo.dbg64.brbe = 0;
 #endif
 
+    /* Hide PMUv1,v2 support as Xen does not support it */
+    domain_cpuinfo.dbg32.perfmon = 0;
+
     /* Hide AMU support */
 #ifdef CONFIG_ARM_64
     domain_cpuinfo.pfr64.amu = 0;
diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index bf902a3970..c92b2651c7 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -216,16 +216,18 @@ struct cpuinfo_arm {
             unsigned long trace_ver:4;
             unsigned long pmu_ver:4;
             unsigned long brps:4;
-            unsigned long __res0:4;
+            unsigned long pmss:4;
             unsigned long wrps:4;
-            unsigned long __res1:4;
+            unsigned long sebep:4;
             unsigned long ctx_cmps:4;
             unsigned long pms_ver:4;
             unsigned long double_lock:4;
             unsigned long trace_filt:4;
-            unsigned long __res2:4;
+            unsigned long trace_buffer:4;
             unsigned long mtpmu:4;
-            unsigned long __res3:12;
+            unsigned long brbe:4;
+            unsigned long ext_trc_buff:4;
+            unsigned long hpmn0:4;
 
             /* DFR1 */
             unsigned long __res4:64;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 03:09:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 03:09:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381075.1624645 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqj35-0005Rc-T1; Mon, 03 Aug 2026 03:09:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381075.1624645; Mon, 03 Aug 2026 03:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqj35-0005RV-QO; Mon, 03 Aug 2026 03:09:07 +0000
Received: by outflank-mailman (input) for mailman id 1381075;
 Mon, 03 Aug 2026 03:09:06 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wqj34-0005R7-Fq
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 03:09:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqj33-00D8Rb-PG
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:09:05 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a700643-5cb7-0a2a0a5109dd-0a2a4502d598-10
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:09:05 +0200
Received: from [202.12.124.155] (helo=fhigh-b4-smtp.messagingengine.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a70064c-6ca4-0a2a45020019-ca0c7c9bcf03-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:09:01 +0200
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49])
 by mailfhigh.stl.internal (Postfix) with ESMTP id E0F677A0019;
 Sun,  2 Aug 2026 23:08:59 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Sun, 02 Aug 2026 23:09:00 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 2 Aug 2026 23:08:58 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785726539; x=1785812939; bh=AIC4GBmoae
	3FANeCYGGjXR4JXRqPhRLZ84Tvuc7wIyc=; b=qADUq64WMQ6gOVvlQdtk46guUw
	v0PecpGJCe3nkB3nFGQgFPz+QiJJZM0O7/2s3KoUBKcSto0fveiOROO0EyM42SSv
	NdgC2ZlGSZ0MSEXSKBBzZ+TDaDZGHfGOqxtD4yH0tM7fuiBRWCS+7t+Tho/GIMFK
	KZ/5oK/zPKLBWNgRxxAhxt5upwJmEhXzt4CvyrdxtqHkPzIbsow/tDltMZ1uiWan
	3Zu96q5dTVh9eZHuT22sl4eeyPIYwbWYiHZz+53mNdtMeGEDi9i4rQiVZcf7eII+
	Tb4PwB1pi5jo2CyHDjj5kIttGlp2tdyr6/6bCTkkAlsqeFUOL9meU9I8sNvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785726539; x=
	1785812939; bh=AIC4GBmoae3FANeCYGGjXR4JXRqPhRLZ84Tvuc7wIyc=; b=N
	TXgAljfpkzLzcsvsNA4Lu6G31VOi9xdy7uz7UHl0uGl1ZBbeDBgdb5GbkfCnWjou
	rPfvxp/sLYtQSTCETk8p7euz9EcdDpiQxoDRrX7uKPXXtIutQL8PlTN9ECy54VuU
	/pkuLs2sguLFYI67yXxXd025Ob4/sV3JpDjGiNazl7soJspz7pEQxxxnmKOAnf1T
	3ivRZ/I6swvGlWhaw+R4E5zxOTpWII9LXjYzl8oXWGOOUa3z7CLCJXNeEGE+bwHz
	iJ6RTc7WXwlUe5Jd81sh3rTIF1UWZyxIUQ4mFp0eTFsv03DrTBn3Old80FS+k9n9
	hpXakhMKTVTX8RCDfca5Q==
X-ME-Sender: <xms:SwZwakASJ0v1LtvRlN90wrzwAYmS62AhnfKKYvBTaCRv4U7_Rpe2hg>
    <xme:SwZwarf6lHqbogcLX8ObeBznwHKOBdg9mZZOG81APkO4XPr-weRjLqFYi-zon1_oE
    6hYxLEA0tnLfBW3XEEBAP6hKCTLGUFiXOqnH_aGUOBa5Hr7WkI>
X-ME-Received: <xmr:SwZwar1Z414lLLUVQxyQoQkXXAw87Zm_5hQKUF6W3GETGbPOGvXXWlAOGN-pHlVvQXjLXfyzly7_vz0a-E-pWxKqaZ1hLeg8pfSVDnCyBUc>
X-ME-Proxy-Cause: dmFkZTEwpDv/j60enwUL1UJovK5tXTOpuP+SK+CoSIq7LCkDblI6JGegUQoofHbAEAnGvT
    2WgLVckyPV5XFdyrVGVi3zRzttftvmTIpNXgwaCsmZQyy1Wq7AB80KuvWdz3HtjWBznKRO
    YqTXcyPTyrHDVVGYGYghLb9BlPINpgvfXxzBZdPROfUvA73iNoabD243iDQ2cJWJDYfwKf
    cs0XhU98QyiD/M/DY4Hz5Qiy7lZbhW3z8Ghs5pp3buJQxpFWdXvrT6ihLuxgnW4MXHWeZp
    Iwb8mvIC+LpEp990itYR+WCOpa25DzleigSNBpi7g4oWNLjklt/yhTSI+TyFh5I71gvcmk
    cp1Er+LY2bnKbm+qs7+wYqoMRneVGehuZ98opHpijgTvP+pCAhSw/EQF+QQSQP1wUS7Yt/
    iS6nS5GOwroOq/D9PBp7gj5axk3u0qIp/R9c6nWq0AkStvabjylE6Q7yANzBUxlQyM3vPY
    Al2c0QpMZ4e5Mj4Sj2QhFM0wJy5NMEbhuf9i648MpFv5nsGOwG6f76VZMH0ICRW4m7i+Ve
    h86JsDfdI3eEpvK959vJWqNOs1IDPfhx8Pd1kpDJmGaQQo/JEvNKk3ZPEg1ht48yqGaHxu
    DIKXsY1ZVX0h6V80SBOGxYXyGmNIzK5VI28oKxLJ1R9+ZW6oApulf1tyCH8w
X-ME-Proxy: <xmx:SwZwaqi5Slvuhh4CLrh2idc0Jcl8lIa_kttR42Q_n_HyeX1bvV3AVw>
    <xmx:SwZwasn4hKHJaZ20zppsI2cK4MioKTrgpcc9yj6qKf6r3FB5xWG7Tw>
    <xmx:SwZwaoZqOlwHpq345LhfOOC2yWMJT74tjUzMcfxnsT0qtechvVxHKQ>
    <xmx:SwZwavH3wZuzZlfs8I-S9fqrSBEiHnGWB_UcTZ3WHdFv2P4veotDSg>
    <xmx:SwZwalE1BjGN0WpDpAqSLALWrFJ16HH5Hyoe3WuIopffelWnQIL9wOgv>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: linux-kernel@vger.kernel.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Jason Andryuk <jason.andryuk@amd.com>,
	xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
Subject: [PATCH 2/2] xen/xenbus: check otherend_id only after it has been initialized
Date: Mon,  3 Aug 2026 05:08:02 +0200
Message-ID: <20260803030822.4104093-2-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
References: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785726541-30DC12AC-AA6F7039/0/0
X-purgate-type: clean
X-purgate-size: 1641

When device just got initialized (for example on module load), the
otherend_id field is initialized only after
xenbus_read_otherend_details() gets called. If xenstore watch triggers
xenbus_dev_changed() before that, it might consider still zeroed
otherend_id field (not matching actual xenstore content) as a sign of
device state reset. It can happen because xenstore watch are handled in
another thread (xenwatch), which can run in parallel to the initial
device probe running at module load. In that case, it would call
device_unregister(), which would deadlock against device probe from
module init.

Fix this by considering dev->otherend_id change only after dev->otherend
is set (which happen after otherend_id is initialized).

Fixes: e2dcf9065536 "xen/xenbus: better handle backend crash"
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 drivers/xen/xenbus/xenbus_probe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index a259c8f0fff4..b42d8d2e5a33 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -680,7 +680,8 @@ void xenbus_dev_changed(const char *node, struct xen_bus_type *bus)
 							    dev->otherend_id);
 
 		if (state == XenbusStateInitialising &&
-		    (state != dev->state || backend != dev->otherend_id)) {
+		    (state != dev->state ||
+		     (dev->otherend && backend != dev->otherend_id))) {
 			/*
 			 * State has been reset, assume the old one vanished
 			 * and new one needs to be probed.
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 03:09:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 03:09:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381074.1624637 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqj2y-0005EM-Nd; Mon, 03 Aug 2026 03:09:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381074.1624637; Mon, 03 Aug 2026 03:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqj2y-0005EB-JT; Mon, 03 Aug 2026 03:09:00 +0000
Received: by outflank-mailman (input) for mailman id 1381074;
 Mon, 03 Aug 2026 03:09:00 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wqj2x-0005E5-Tm
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 03:09:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqj2w-00D8Rb-V0
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:08:59 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a700618-5cb7-0a2a0a5109dd-0a2a450181ca-24
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:08:58 +0200
Received: from [202.12.124.155] (helo=fhigh-b4-smtp.messagingengine.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a700649-5984-0a2a45010019-ca0c7c9baba9-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:08:58 +0200
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49])
 by mailfhigh.stl.internal (Postfix) with ESMTP id DC1E47A0069;
 Sun,  2 Aug 2026 23:08:56 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-09.internal (MEProxy); Sun, 02 Aug 2026 23:08:57 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 2 Aug 2026 23:08:54 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:Message-ID:MIME-Version:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm2;
	 t=1785726536; x=1785812936; bh=8Y5zAgxEseAiRyIU5rtwLgzJrStxXeP9
	ashJGawv7H0=; b=cwrN4W3qSRGAz02qkHf106xji4HXsY+mJ11SnCpqTkQr9Jy2
	ia+Uzp1M76hvgJc6tQq6lGcEbuMJ7/tmPh+/tZ6PTfkjTSfcFM6jGXjVozR19Spb
	fNVM86f2Yuk9LCwaSEllQybZBuVVlPePBbedmzbFTt6Mlne8zbrN9610ya2gTa8W
	UvMBWG7+B1bBAiE38/VkfN/DDKPw/bWwQ3M4DGBxZWdA7w/0b7V95FFKirwm+A+a
	uYpfvdMrnRF2xJ9Kdkk5xwBhjdCToAxWQ40PWNxj8wtu2PuhHvRo8ccytUVrkoJ/
	X3GvI3lsHiPTJkFD5RLDTm2YJevJQMb3HotH3g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1785726536; x=1785812936; bh=8Y5zAgxEseAiRyIU5rtwLgzJrStx
	XeP9ashJGawv7H0=; b=W+x+6oHjtmnxSqC6fy0cGeFuYANhlnZvW4gGOwhZE8xW
	yeWr/IhWZhrktMTJnvWUTue0ATJ/Olg5qsAhklfnSQW8ow985bisgXHPgnMFIaJr
	+KTlrFQUg5TBxIszm93t5bcAceg+GZBFG/nPYs05gOpZH0rtO69Ah93l1eqBNJuz
	e+xYR+fIxn3JLba1nO4RGRagDC69hHCxzBUaYrlZhFBdMTBmnqGPo6Jtegb37rEW
	sxU4ZH4a03qqvS0kXIial2kLxk9xVJ/SlG9f9mO4x6HCykfDz+rTFDW3JXWoHTYt
	mEqJnfnae6rPCLPSgB/CVf5fcAGFRLGaXsQw5iKBCg==
X-ME-Sender: <xms:SAZwaiPtZBcdMRc1ZsSKm8WA3Mi2YZLP0mryzWv7QnOvDhCay6gaaA>
    <xme:SAZwal4f16ZkW771hswkno4821dFVwzsvVL6OFjkN7FKH5b_7lFjonUH2ttm2TI0v
    ikXdChO6sW2GA9WvU9n1YAF5KhEAyaGo0Z1d5DSVmBKgfwwKxM>
X-ME-Received: <xmr:SAZwatj-7j-5ZofF-m4NpkceNVU4mLPNm82gpTuzcOzjbMsqRpzlopiaLeziwEEC7uSsQF6oWLmfpR2lvU5UfSgGf_I8rQezE3ekQUBssfk>
X-ME-Proxy-Cause: dmFkZTEFiahVVmp40OOwjwusbdef2xUVvLhYW9x1MdKYU/g1FneGLwTqoe+iWVZNousYSB
    QeW1rFANIP0uiYR5no31tqR+Qrhe4OBqGcoAmgZ6bpVK02LmGHYiUJhTlNsGgb+7HvGr8F
    9x7ntapEphoghzsjaBvY++MRaQ60rOQ+pX/demLbBt8Jh20rMqojqse1WPeutn/PMC2DNb
    LfennEkKTRolsDMx6QQd1tZr1pa1L6r31pPNHg3GQnpnn467R5VE1qNrmjSWrQpCw0JtdZ
    0QjxpcHGItqsJLJcVsZUWVGtIZG1elGeW1G3m8pnXGp2Y2PDALndgoplbX6JkvQd6/OBrR
    V0yjyiSbeM1Y1vrrCe3mSZM3p82eNt9ZU321CKJCvqAbdKuEmbylSzNU7oDFnoaQU+sTfb
    VpMNI+LfvklywtexxgVCqcV/NzYfmoAoq0eSAoulg3ozQvrZBsKfZirHQYorJovRz11n+2
    o7cPh9iSJWWAkYdAGrYVtr006wgH7qAYnoKvEyhDv8GXd7ZR6rVIBuKZQEdMahTyh/0EwF
    5nrZst20hm9LrQ2gcBclrFV3jrbzs+37VHgaioNDXxUa7nhO+xtM1FtGj33CVcqhheiMOE
    /bpoUFaB+B0WeQphy100c2jtdZntrMUXjeit500SdSTjLbYGak0TIuJGmttA
X-ME-Proxy: <xmx:SAZwaidIekINY9yRkJGQj2ZI_M0zCBif10x6Alk7_jkuPKKTuGNGsg>
    <xmx:SAZwaty-3kkg0M4w-hy6QbJbcaeB8HRTyWagZO0oruBdAoAwLbnyxA>
    <xmx:SAZwap3S7MXccM__kLtMoEuJb42g1fr8OUNfbRWtotf9b6SaCTmTsg>
    <xmx:SAZwarzzcM1nHUZ9IQ4TdctWJ6W8YnTtwzRT7jsOmgVNhOYa9oB7eA>
    <xmx:SAZwallPxEMdIM-byb-E77FlDR8toO9MpHvakYVwdr46R0ryx6VcxkUm>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: linux-kernel@vger.kernel.org
Cc: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Jason Andryuk <jason.andryuk@amd.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Jakub Kicinski <kuba@kernel.org>,
	xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
Subject: [PATCH 1/2] xen/xenbus: log more information when device state got reset
Date: Mon,  3 Aug 2026 05:08:01 +0200
Message-ID: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785726538-C5341757-6C0E60A0/0/0
X-purgate-type: clean
X-purgate-size: 887

Ease diagnosing what actually changed.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 drivers/xen/xenbus/xenbus_probe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index eb260eceb4d2..a259c8f0fff4 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -686,7 +686,8 @@ void xenbus_dev_changed(const char *node, struct xen_bus_type *bus)
 			 * and new one needs to be probed.
 			 */
 			dev_warn(&dev->dev,
-				 "state reset occurred, reconnecting\n");
+				 "state reset occurred (xenstore state %u, local state %u, xenstore backend %u, local backend %u), reconnecting\n",
+				 state, dev->state, backend, dev->otherend_id);
 			dev->vanished = true;
 		}
 		if (dev->vanished) {
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381102.1624673 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktT-0002mf-GK; Mon, 03 Aug 2026 05:07:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381102.1624673; Mon, 03 Aug 2026 05:07:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktT-0002mY-Cq; Mon, 03 Aug 2026 05:07:19 +0000
Received: by outflank-mailman (input) for mailman id 1381102;
 Mon, 03 Aug 2026 05:07:18 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqktS-0002lj-F3
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqktR-006WBT-S7
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:17 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702204-e002-0a2a0a5209dd-0a2a4509bd80-8
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:17 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702205-be1a-0a2a45090019-d1558031f053-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:17 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so17071495e9.2
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:17 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733637; x=1786338437; 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=kwX99bHKclxWTYHmK+vhBg0zTegHyj1b3u5g7DqxgOA=;
        b=LrHtOCDS+2rHTuc7JUfMY4RT1XOTojHFP/DhHx0KMvxPPdZmBC76FNYOGKU5Y0KRIT
         7Ah6KBAqy3j9I/9QtNE6n3T+BYXUMISDF2OEcscLEetdbqSsas3y5O8+//MYUYzxTl1c
         MbfqZB0PSvEyNlhxuO9AWufa5SuNnWJ7bgSK/hWojq/6aJJTC9X1YQa8UNXXmq3Nczz9
         KhXJ9BjYHi8Cy4+D1GUalz/zJyB2yn6YqoD/3m9ONfgMOgxHQiw5mvNFaGS1nW7ZJKDe
         F2QNsPRE/bCcM2RgNEerocFDvkZVyX5/ilI1C89ojVrLebK78cHJ2sf+ZoBXOZP4e0Wl
         s4eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733637; x=1786338437;
        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=kwX99bHKclxWTYHmK+vhBg0zTegHyj1b3u5g7DqxgOA=;
        b=JnvgHv9TRh9pXg/DK6oJU2eRMa4bAs3kavudTCKrZ/OPsPRsO+xUNW+vt4YvfIZhdN
         0MnFunzUFKj0gvhfqFfARMJ9aSCJloLHh7A1UhmjbjIHVMSASlTe98c8g4qXYRjd5qTy
         84IVe6dFowLXhDu0fNgzNUgscvjaKx7/2HJYyxb4Gp4euM3eiXOaCAkYq13E7jVsZCoT
         OvsqwsPg3ndy5m/bopXE8VynJYE5E/g4zZfv9YzPiJVDIDZh6U2EDWkQZKkhpCy4ari+
         a3ZQ+xpy8r4YvSdQwxGxNZr3KSSjQeArunWC4iNF/Sp/zV+cykCTXS9Uih4/ESA2+Z/Z
         Y6Dg==
X-Gm-Message-State: AOJu0Yy3Ac26CAHGq3zr8sJbyM2D1zJd8X0jyGHpYcEaw0Om/SYT3/pj
	34dG5Qu6PSU2nROdGE/oXyn/a02GBvtMnLWB6Sx0AD35C7EsS7wjqOrNTUr3uQ==
X-Gm-Gg: AR+sD11x6ITQ8aCGR2NQmLtepzSY+/ZON2Y3igv/AsIXGI110mszaIKKib2lUpWv+ym
	yUfhZpS5fzlIwNs+cjWc/ohJ7Kr3wS6zbFkrsp2QcW3CLXsw5cLE7mN7BH5FcPB7g8mFRl4BjSA
	WVMLLQxTn3S8yFNJBN1NYnSjDUVVNzq1xA3oajykug4+gASORNnnygJ/j6ANnNqCRtg5MQR78QQ
	P7F4nagNWytlq0zSCigG7XwyRl4WWJububb3lcU54fwL7brlKEW/95QRMifsJwhsSA4D+Q2cqDu
	IJCx2R92GUpkZRKMnrmeijCGYi/HsfnJ1VnI9hQ4UDU2gjf1/Y5BFuBD4COWsccDfqb8wn1lxOC
	Z5u522tToFeKMiN7bOdQhg7hq4AqpMIzbZ4840Dcl4f5ueGwUEn7dnPT8mvvV4XXi0InJf4VVEp
	LnmQNMFLRRNBgZT3+53jrGrtGt7xnngb8a/CSzfOKIQwUiq5InNp1sE/P4bDhTEQ==
X-Received: by 2002:a05:600c:8b33:b0:495:779a:ed33 with SMTP id 5b1f17b1804b1-4980c66c798mr200299205e9.7.1785733637288;
        Sun, 02 Aug 2026 22:07:17 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 2/7] xen/sched: credit: migrate to new sched_ops
Date: Mon,  3 Aug 2026 08:06:09 +0300
Message-Id: <20260803050614.5222-3-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785733637-FCA16034-6DD59F6E/0/0
X-purgate-type: clean
X-purgate-size: 1237

Declare sched_credit_def as a struct sched_ops instead of a struct
scheduler, dropping the .sched_data field, and register it with
REGISTER_SCHED_OPS() so it is found through sched_ops_array[]
instead of schedulers[].

This moves the credit scheduler onto the new sched_ops
registration path.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/credit.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 328c802d0c..d8c949af11 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -2273,11 +2273,10 @@ csched_deinit(struct scheduler *ops)
     }
 }
 
-static const struct scheduler sched_credit_def = {
+static const struct sched_ops sched_credit_def = {
     .name           = "SMP Credit Scheduler",
     .opt_name       = "credit",
     .sched_id       = XEN_SCHEDULER_CREDIT,
-    .sched_data     = NULL,
 
     .global_init    = csched_global_init,
 
@@ -2312,4 +2311,4 @@ static const struct scheduler sched_credit_def = {
     .move_timers    = csched_move_timers,
 };
 
-REGISTER_SCHEDULER(sched_credit_def);
+REGISTER_SCHED_OPS(sched_credit_def);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381101.1624663 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktP-0002Wc-4c; Mon, 03 Aug 2026 05:07:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381101.1624663; Mon, 03 Aug 2026 05:07:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktP-0002WV-1X; Mon, 03 Aug 2026 05:07:15 +0000
Received: by outflank-mailman (input) for mailman id 1381101;
 Mon, 03 Aug 2026 05:07:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqktN-0002WF-9G
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqktM-006W6b-MN
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:12 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a7021f8-e002-0a2a0a5209dd-0a2a450bce68-26
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:12 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702200-b7e8-0a2a450b0019-d1558030e5e9-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:12 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4957eefd361so10928575e9.1
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:12 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733632; x=1786338432; 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=CvaIgsy1tiLeOz4+v4UxZSpgWz1oDHV9WwaN0mMyibY=;
        b=cc22UMfISvV5CaIzWCq7K3UvrVbWjWfqhCwBmSL2Vg+vj74LKVQiWgm4WJpaulmkPG
         7Z80AZuFhud6WEyVe7rEBIGSD50YavcpACKE4XHzr7tEcNGjcit8stY9Y2tLJ+CUXNuY
         PUGYUBGsUvCblQNxIz4Midvrig5vc0Uq9CpRACVbQhFgdnKhdp2abdMAKc6zo9y/apH4
         MYn2QP2WHzk4+wJEoyvRXQxmIJY85GPpUabJ5o/Tv8iw/Syc//+GiSQk8mxFSlYKRdKg
         BZNbzqWpYscQjoLKFjikO62uRHGSY2H1uJ0a/VmN1AqY3voZG+hO+2WLYTWz3xAGaWqi
         fjWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733632; x=1786338432;
        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=CvaIgsy1tiLeOz4+v4UxZSpgWz1oDHV9WwaN0mMyibY=;
        b=IDOmF5USp6N6m1dqs3//GUxOv7HIDxyNEm8/+QDuBwciyop6eexd85Rs4/aCUUsAEB
         fIMZG3QVImAtVYVB+05j/PV4TAWyog6i4R3Iy/l97gxDqvjWZxLTUN1NGqvcdyJw2eAE
         ZgGtQ74wQpbK/uroyFeAwGrVPhmvc/bwTLgM/QPsC/6UnD0j9hjXY11dbe2aGlRVb3Ox
         /pR3xITQYOZCUAGIhT61WJzdWNwRKNj+KDoj9afjom1w6Sdz49TLA+kZ8X8W4WuuL2CD
         dn9VIECZeWPB5GWrATXB6QLK1NmLaAdgOWK+H6WNM2NLiAG5J0ejK3n2X6CkCU/SIE14
         t6EA==
X-Gm-Message-State: AOJu0Yyk44rjQLsRn4poS2hlDRy7R+Csaoso/WVjCg3fSF5gFcW3Sl9C
	MLDOjmz39knM23YcxVe9ab4BVVKcLG0kvWJEuobQVZqAm2J86S2/CPqBueJysj5I
X-Gm-Gg: AR+sD126IXl6KTmLV6TU60bo2mUI9gSxXLRM366vlfbSOITgvpCx3X3//wdBiSh7jq7
	E3i1i88vBtuI9gFHmoYfAmT9A3r5fPmSuzsx7EEU2Rv8MNnFBt6ffca2lwhoh443Fi50L9C9o2W
	ucIBfbHIc/6vlbzvD3AG+5581A6C9k290ve3f9/vRVP3rNJEq6L1hcr6d28QVZRZ1nWnFFJjAFj
	JzDEDZ9kzCp6Pd52rkNKmZP8tZd7p4DNWMzr2mw2Lusk0xhwVutnQDfX9dso3umHXmqIhgmLiHJ
	3pJ/CaW++gvf+wHpmRbt4GDXkoW6cYzqVD5KxeQHetNs1z7vCq+dZHwerf9e9X3JdpZyCg3kA/t
	IrEDoKXsOzdEL5mXR0A5Xc74AUdCcQjg8JL0f/FWy7xdo7HsEYcwnPTfrFMW7wNPozQ/UX0jNxU
	44Y/BAnlZU3Io3ib+9jVNQHaoJsK0BKZiRUOLwPtv7CpxGRSHz/t93NhbeW9Fs4g==
X-Received: by 2002:a05:600c:8489:b0:495:495b:9248 with SMTP id 5b1f17b1804b1-4980c64b73emr200743855e9.4.1785733631883;
        Sun, 02 Aug 2026 22:07:11 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 1/7] xen/sched: introduce struct sched_ops as a shared scheduler vtable
Date: Mon,  3 Aug 2026 08:06:08 +0300
Message-Id: <20260803050614.5222-2-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785733632-1A2C49EA-B54E27DF/0/0
X-purgate-type: clean
X-purgate-size: 14848

struct scheduler currently serves two purposes: it is the static
vtable a scheduler backend defines (name, opt_name, sched_id, and
all its function pointers), and it is also the per-cpupool runtime
object scheduler_alloc() allocates. Being the same type forces
scheduler_alloc() to memcpy() the whole vtable into a fresh
allocation per cpupool, duplicating identical function pointers
across every cpupool using the same scheduler.

Introduce struct sched_ops to hold just the compile-time-constant
identity and dispatch table, with no per-cpupool state, plus
REGISTER_SCHED_OPS() and a sched_ops_array[] alongside the
existing schedulers[]. scheduler_alloc(), sched_get_by_name(), and
scheduler_init() are extended to also search sched_ops_array[],
using a new sched_ops_to_scheduler() helper to build an identical
flat struct scheduler regardless of which array a match came from.

struct scheduler itself is left untouched for now and still
duplicates every field sched_ops holds - this commit only lays the
groundwork. Once every backend registers through sched_ops, struct
scheduler will be shrunk to its genuinely per-cpupool fields (a
pointer to a shared sched_ops instance, plus instance data), and
the flattening copy, schedulers[], and REGISTER_SCHEDULER() will be
removed. That is what actually removes the duplication; this
commit does not yet change any behavior, since sched_ops_array[] is
still empty.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/arch/arm/xen.lds.S     |   1 +
 xen/arch/ppc/xen.lds.S     |   1 +
 xen/arch/riscv/xen.lds.S   |   1 +
 xen/arch/x86/xen.lds.S     |   1 +
 xen/common/sched/core.c    | 118 +++++++++++++++++++++++++++++++++++--
 xen/common/sched/private.h |  73 +++++++++++++++++++++++
 xen/include/xen/xen.lds.h  |   6 ++
 7 files changed, 196 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2d5f1c516d..9a63fa36a0 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -94,6 +94,7 @@ SECTIONS
        *(.data.page_aligned)
 
        SCHEDULER_ARRAY
+       SCHED_OPS_ARRAY
        HYPFS_PARAM
 
        *(.data .data.*)
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index d0f2ed43f1..da8f73d85b 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -85,6 +85,7 @@ SECTIONS
         *(.data.page_aligned)
 
         SCHEDULER_ARRAY
+        SCHED_OPS_ARRAY
         HYPFS_PARAM
 
         *(.data .data.*)
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 65f136dce9..01f202e504 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -90,6 +90,7 @@ SECTIONS
         *(.data.page_aligned)
 
         SCHEDULER_ARRAY
+        SCHED_OPS_ARRAY
         HYPFS_PARAM
 
         *(.data .data.*)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index b9e888e596..d128a30440 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -307,6 +307,7 @@ SECTIONS
        *(.data.read_mostly)
 
        SCHEDULER_ARRAY
+       SCHED_OPS_ARRAY
        HYPFS_PARAM
   } PHDR(text)
 
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 3609721426..fb2d1d5314 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -91,6 +91,10 @@ extern const struct scheduler *__start_schedulers_array[], *__end_schedulers_arr
 #define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
 #define schedulers __start_schedulers_array
 
+extern const struct sched_ops *__start_sched_ops_array[], *__end_sched_ops_array[];
+#define NUM_SCHED_OPS (__end_sched_ops_array - __start_sched_ops_array)
+#define sched_ops_array __start_sched_ops_array
+
 static struct scheduler __read_mostly operations;
 
 static bool scheduler_active;
@@ -98,6 +102,43 @@ static bool scheduler_active;
 static void sched_set_affinity(
     struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
 
+
+static void sched_ops_to_scheduler(
+        struct scheduler *sched, const struct sched_ops *ops)
+{
+    sched->name            = ops->name;
+    sched->opt_name        = ops->opt_name;
+    sched->sched_id        = ops->sched_id;
+    sched->global_init     = ops->global_init;
+    sched->init            = ops->init;
+    sched->deinit          = ops->deinit;
+    sched->free_udata      = ops->free_udata;
+    sched->alloc_udata     = ops->alloc_udata;
+    sched->free_pdata      = ops->free_pdata;
+    sched->alloc_pdata     = ops->alloc_pdata;
+    sched->deinit_pdata    = ops->deinit_pdata;
+    sched->alloc_domdata   = ops->alloc_domdata;
+    sched->free_domdata    = ops->free_domdata;
+    sched->switch_sched    = ops->switch_sched;
+    sched->insert_unit     = ops->insert_unit;
+    sched->remove_unit     = ops->remove_unit;
+    sched->sleep           = ops->sleep;
+    sched->wake            = ops->wake;
+    sched->yield           = ops->yield;
+    sched->context_saved   = ops->context_saved;
+    sched->do_schedule     = ops->do_schedule;
+    sched->pick_resource   = ops->pick_resource;
+    sched->migrate         = ops->migrate;
+    sched->adjust          = ops->adjust;
+    sched->adjust_affinity = ops->adjust_affinity;
+#ifdef CONFIG_SYSCTL
+    sched->adjust_global   = ops->adjust_global;
+#endif
+    sched->dump_settings   = ops->dump_settings;
+    sched->dump_cpu_state  = ops->dump_cpu_state;
+    sched->move_timers     = ops->move_timers;
+}
+
 static struct sched_resource *cf_check
 sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit *unit)
 {
@@ -3004,11 +3045,27 @@ const struct scheduler *__init sched_get_by_name(const char *sched_name)
     return NULL;
 }
 
+static inline
+const struct sched_ops *__init sched_ops_get_by_name(const char* sched_name)
+{
+    unsigned int i;
+    for ( i = 0; i < NUM_SCHED_OPS; i++)
+        if ( sched_ops_array[i] && !strcmp(sched_ops_array[i]->opt_name, sched_name) )
+            return sched_ops_array[i];
+
+    return NULL;
+}
+
 int __init sched_get_id_by_name(const char *sched_name)
 {
     const struct scheduler *scheduler = sched_get_by_name(sched_name);
+    const struct sched_ops *ops;
+
+    if ( scheduler )
+        return scheduler->sched_id;
 
-    return scheduler ? scheduler->sched_id : -1;
+    ops = sched_ops_get_by_name(sched_name);
+    return ops ? ops->sched_id : -1;
 }
 
 /* Initialise the data structures. */
@@ -3016,6 +3073,7 @@ void __init scheduler_init(void)
 {
     struct domain *idle_domain;
     const struct scheduler *scheduler;
+    const struct sched_ops *ops;
     int i;
 
     scheduler_enable();
@@ -3048,15 +3106,52 @@ void __init scheduler_init(void)
         }
     }
 
+    for ( i = 0; i < NUM_SCHED_OPS; i++)
+    {
+#define sched_test_func(f)                               \
+        if ( !sched_ops_array[i]->f )                         \
+        {                                                \
+            printk("scheduler %s misses .%s, dropped\n", \
+                   sched_ops_array[i]->opt_name, #f);         \
+            sched_ops_array[i] = NULL;                        \
+        }
+
+        sched_test_func(init);
+        sched_test_func(deinit);
+        sched_test_func(pick_resource);
+        sched_test_func(alloc_udata);
+        sched_test_func(free_udata);
+        sched_test_func(switch_sched);
+        sched_test_func(do_schedule);
+
+#undef sched_test_func
+
+        if ( sched_ops_array[i]->global_init && sched_ops_array[i]->global_init() < 0)
+        {
+            printk("scheduler %s failed initialization, dropped\n",
+                    sched_ops_array[i]->opt_name);
+            sched_ops_array[i] = NULL;
+        }
+    }
+
     scheduler = sched_get_by_name(opt_sched);
-    if ( !scheduler )
+    ops = scheduler ? NULL : sched_ops_get_by_name(opt_sched);
+    if ( !scheduler && !ops )
     {
         printk("Could not find scheduler: %s\n", opt_sched);
         scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
-        BUG_ON(!scheduler);
-        printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
+        ops = scheduler ? NULL : sched_ops_get_by_name(CONFIG_SCHED_DEFAULT);
+        BUG_ON(!scheduler && !ops);
+        if ( scheduler )
+            printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
+        else
+            printk("Using '%s' (%s)\n", ops->name, ops->opt_name);
     }
-    operations = *scheduler;
+
+    if ( scheduler )
+        operations = *scheduler;
+    else
+        sched_ops_to_scheduler(&operations, ops);
 
     if ( cpu_schedule_up(0) )
         BUG();
@@ -3415,12 +3510,25 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
     for ( i = 0; i < NUM_SCHEDULERS; i++ )
         if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
             goto found;
+
+    for ( i = 0; i < NUM_SCHED_OPS; i++ )
+        if ( sched_ops_array[i] && sched_ops_array[i]->sched_id == sched_id )
+            goto found_new;
+
     return ERR_PTR(-ENOENT);
 
  found:
     if ( (sched = xmalloc(struct scheduler)) == NULL )
         return ERR_PTR(-ENOMEM);
     memcpy(sched, schedulers[i], sizeof(*sched));
+    goto init;
+
+ found_new:
+    if ( (sched = xzalloc(struct scheduler)) == NULL )
+        return ERR_PTR(-ENOMEM);
+    sched_ops_to_scheduler(sched, sched_ops_array[i]);
+
+ init:
     if ( (ret = sched_init(sched)) != 0 )
     {
         xfree(sched);
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index d6884550cd..4dd5c99b87 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -294,6 +294,76 @@ static inline spinlock_t *pcpu_schedule_trylock(unsigned int cpu)
     return NULL;
 }
 
+struct sched_ops {
+    const char *name;       /* full name for this sched_ops      */
+    const char *opt_name;   /* option name for this sched_ops    */
+    unsigned int sched_id;  /* ID for this sched_ops             */
+
+    int          (*global_init)    (void);
+
+    int          (*init)           (struct scheduler *ops);
+    void         (*deinit)         (struct scheduler *ops);
+
+    void         (*free_udata)     (const struct scheduler *ops, void *priv);
+    void *       (*alloc_udata)    (const struct scheduler *ops,
+                                    struct sched_unit *unit, void *dd);
+
+    void         (*free_pdata)     (const struct scheduler *ops,
+                                    void *pcpu, int cpu);
+    void *       (*alloc_pdata)    (const struct scheduler *ops, int cpu);
+    void         (*deinit_pdata)   (const struct scheduler *ops,
+                                    void *pcpu, int cpu);
+
+    /* Returns ERR_PTR(-err) for error, NULL for 'nothing needed'. */
+    void *       (*alloc_domdata)  (const struct scheduler *ops,
+                                    struct domain *dom);
+    /* Idempotent. */
+    void         (*free_domdata)   (const struct scheduler *ops, void *data);
+
+    spinlock_t * (*switch_sched)   (struct scheduler *new_ops, unsigned int cpu,
+                                    void *pdata, void *vdata);
+
+    /* Activate / deactivate units in a cpu pool */
+    void         (*insert_unit)    (const struct scheduler *ops,
+                                    struct sched_unit *unit);
+    void         (*remove_unit)    (const struct scheduler *ops,
+                                    struct sched_unit *unit);
+
+    void         (*sleep)          (const struct scheduler *ops,
+                                    struct sched_unit *unit);
+    void         (*wake)           (const struct scheduler *ops,
+                                    struct sched_unit *unit);
+    void         (*yield)          (const struct scheduler *ops,
+                                    struct sched_unit *unit);
+    void         (*context_saved)  (const struct scheduler *ops,
+                                    struct sched_unit *unit);
+
+    void         (*do_schedule)    (const struct scheduler *ops,
+                                    struct sched_unit *currunit, s_time_t now,
+                                    bool tasklet_work_scheduled);
+
+    struct sched_resource *(*pick_resource)(const struct scheduler *ops,
+                                            const struct sched_unit *unit);
+    void         (*migrate)        (const struct scheduler *ops,
+                                    struct sched_unit *unit,
+                                    unsigned int new_cpu);
+    int          (*adjust)         (const struct scheduler *ops,
+                                    struct domain *d,
+                                    struct xen_domctl_scheduler_op *op);
+    void         (*adjust_affinity)(const struct scheduler *ops,
+                                    struct sched_unit *unit,
+                                    const struct cpumask *hard,
+                                    const struct cpumask *soft);
+#ifdef CONFIG_SYSCTL
+    int          (*adjust_global)  (const struct scheduler *ops,
+                                    struct xen_sysctl_scheduler_op *sc);
+#endif
+    void         (*dump_settings)  (const struct scheduler *ops);
+    void         (*dump_cpu_state) (const struct scheduler *ops, int cpu);
+    void         (*move_timers)    (const struct scheduler *ops,
+                                    struct sched_resource *sr);
+};
+
 struct scheduler {
     const char *name;       /* full name for this scheduler      */
     const char *opt_name;   /* option name for this scheduler    */
@@ -546,6 +616,9 @@ static inline void sched_unit_unpause(const struct sched_unit *unit)
 #define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
   __used_section(".data.schedulers") = &(x)
 
+#define REGISTER_SCHED_OPS(x) static const struct sched_ops *x##_entry \
+  __used_section(".data.sched_ops") = &(x)
+
 struct cpupool
 {
     unsigned int     cpupool_id;
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index ea11e3fb62..157d48eabd 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -179,6 +179,12 @@
        *(.data.schedulers)           \
        __end_schedulers_array = .;
 
+#define SCHED_OPS_ARRAY              \
+       . = ALIGN(POINTER_ALIGN);     \
+       __start_sched_ops_array = .;  \
+       *(.data.sched_ops)            \
+       __end_sched_ops_array = .;
+
 #ifdef CONFIG_HYPFS
 #define HYPFS_PARAM              \
        . = ALIGN(POINTER_ALIGN); \
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381100.1624655 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktK-0002Jr-Ue; Mon, 03 Aug 2026 05:07:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381100.1624655; Mon, 03 Aug 2026 05:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktK-0002Jk-RP; Mon, 03 Aug 2026 05:07:10 +0000
Received: by outflank-mailman (input) for mailman id 1381100;
 Mon, 03 Aug 2026 05:07:09 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqktJ-0002Je-0J
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqktI-006W4Q-9B
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:08 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a7021f1-2eae-0a2a0a5409dd-0a2a450aec7a-16
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:08 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a7021f7-f2d2-0a2a450a0019-d1558034a963-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:03 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4954a9e8490so12548335e9.1
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:03 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.06.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785733623; x=1786338423; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=s6Me0Ii/wXFwxSrXThVMvIBe3ZtEiu+nF8ISBnVnumA=;
        b=TvvRn6N8Uu/7wT3XircOrT7N5ZR/TOSYrtP4rmx0A6Dh3t3WDZsna9qkRSD3yh/Pll
         ySrCaSjpvOryge5UBNmTF2bqQ722VduUeh+K0fJ5G18/yJMsK3q/ANW2MfagOWQAQqM7
         e6q6nJCoh7BxLlV/+4DXm8aziTg3hLOsmcV2crz5AgJFGNHEha4OB/xYOFR8B3lAYQbz
         4DkMtOT4OGXMo8+TZybU9Hwqq/iVkPIGW2KRGneaL1O2cMTmKoifX8tQZocp0IiB92O0
         QZD/JbwISVJ11HqMPo1zOxXW+3+Fm5SDanQPvoTMkpXNa9p2ZchiGU5bmjZQyojVREQG
         vHfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733623; x=1786338423;
        h=content-transfer-encoding:mime-version: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=s6Me0Ii/wXFwxSrXThVMvIBe3ZtEiu+nF8ISBnVnumA=;
        b=FJsLRt0JWpcdGoluDVGZ+t8koiXVjZ1JdyFX0IZsvlgPwU82YHG6XtdXft0+nr/TsK
         wJCmNWbzPrhU/nkHOOlW2C/HabZo9oj4P4DFD/ESnRlDhJkT0UX6qXrbm5DIOTIvsgGu
         umxKKoOnJVXN/WSRokqNHGFKCrpfMRXJgF2dvMOib+fbY1hJwjM6ESncEUZ20kYgEt66
         iSRFZE5/XcL8LApw8tf5eqVLupEFYWVHuMIM7tTcCo193LI4hgSc+DrAln0WbRhXoOSS
         3H4X4k02G3Mp3+SLeN2/nu+XlJSLCm2YZaJfZSuZCQbTOsJzIQhZst3N0V5aIedqUAk7
         hvtA==
X-Gm-Message-State: AOJu0YyKK236k3ImJEdOyfvnL4GTtFQrRZLCpcfSt3QWU0dCpHim3xSS
	No90cRgmzc90/ERYJfdCDvOi1a/Za5v0GyTcCmhT7QhSn19G7qcNfJ/Q09eM0eDa
X-Gm-Gg: AR+sD13gATuO4maEAT1wp5B/smYPG4qx5LzQLhVR1y+oXpYrCNn8mgGiVmZubfvnkQS
	XRKoRGBIsXg7/6hyFEdLt6npa+I0peNKbHg72wk/JS+dxQgUlfvtVpby8lZy70tKVpD5gZxwxy6
	Ew8AGtFxKskJkBM05KnEJ5BMl4QNOGzePaNgAT6px9DiYsjrSrIFovftT2qIqh3qO32zG3Z5Z1p
	sO2zqUvtdrK5bYAPzt4EYZMsk8MdoI//Acociv67C1DfqTXQhBjP37vhOjkzq0vKKxWWjZ+jhAh
	T4Ap4vs1lTPDBl/ot0ch4kyaw2ITXCFRx8Y/fvf4CmwqcQzanGFVrsvIZd3A6U7YDVd/bol2fK9
	l3syFpkvxHb94XWPEeq9147g/TDlZo00Elzh75D/GrjeNpZxtGrH8yEzQMYV2kUJcHP+bfY4jkA
	O5ZUIrsZOOAGSdE0ry+SMuCoAyuFNd3V1foM2hBWuJKgvmj1eGoC8ROjvwBVcZo8I/vsaJ0Wv1k
	w==
X-Received: by 2002:a05:600c:a42:b0:495:69eb:27d3 with SMTP id 5b1f17b1804b1-4980eba0a6fmr164772565e9.8.1785733623067;
        Sun, 02 Aug 2026 22:07:03 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 0/7] xen/sched: split scheduler vtable from scheduler 
Date: Mon,  3 Aug 2026 08:06:07 +0300
Message-Id: <20260803050614.5222-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785733623-591C5CFC-7CDF42AE/0/0
X-purgate-type: clean
X-purgate-size: 3004

Each struct scheduler currently doubles as both a scheduler 
backend's static vtable (name, opt_name, sched_id and every 
function pointer) and the per-cpupool runtime object that 
scheduler_alloc() allocates. Because these are the same type, 
scheduler_alloc() memcpy()s the entire vtable into a fresh heap 
allocation for every cpupool it creates. With N cpupools running 
the same scheduler, this duplicates N copies of identical function 
pointers and identifying fields that never differ between 
instances - the only fields that are genuinely per-cpupool are 
sched_data and cpupool.

This series splits the vtable out into its own type, struct 
sched_ops, so it can be shared by every cpupool using a given 
scheduler instead of copied per cpupool. struct scheduler is left 
holding only what is actually per-instance: a pointer to the 
shared sched_ops, plus sched_data and cpupool.

The series is structured as introduce/migrate/remove, so that 
every commit builds and boots on its own:

  - The first patch adds struct sched_ops, REGISTER_SCHED_OPS(), 
    and a sched_ops_array[] alongside the existing schedulers[], 
    extending every lookup path (scheduler_alloc(), 
    sched_get_by_name(), scheduler_init()) to search both arrays. 
    This is purely additive - no scheduler uses it yet. 

  - The next five patches each migrate one scheduler backend 
    (credit, credit2, rtds, arinc653, null) from struct scheduler 
    to struct sched_ops. Each is small, mechanical, and 
    independently bisectable, with no behavioral difference, since 
    scheduler_alloc() builds an identical runtime struct scheduler 
    regardless of which array a match is found in. 

  - The final patch removes the old schedulers[] and 
    REGISTER_SCHEDULER() path now that nothing uses it, shrinks 
    struct scheduler down to { ops, sched_data, cpupool }, and 
    updates every accessor in private.h accordingly.

Furkan Caliskan (7):
  xen/sched: introduce struct sched_ops as a shared scheduler vtable
  xen/sched: credit: migrate to new sched_ops
  xen/sched: credit2: migrate to new sched_ops
  xen/sched: rtds: migrate to new sched_ops
  xen/sched: arinc653: migrate to new sched_ops
  xen/sched: null: migrate to new sched_ops
  xen/sched: remove old scheduler registration, shrink struct scheduler

 xen/arch/arm/xen.lds.S      |   2 +-
 xen/arch/ppc/xen.lds.S      |   2 +-
 xen/arch/riscv/xen.lds.S    |   2 +-
 xen/arch/x86/xen.lds.S      |   2 +-
 xen/common/sched/arinc653.c |  11 +---
 xen/common/sched/core.c     |  80 ++++++++++++++++-------------
 xen/common/sched/cpupool.c  |   6 +--
 xen/common/sched/credit.c   |   5 +-
 xen/common/sched/credit2.c  |   5 +-
 xen/common/sched/null.c     |   5 +-
 xen/common/sched/private.h  | 100 +++++++++++++++++++-----------------
 xen/common/sched/rt.c       |   5 +-
 xen/include/xen/xen.lds.h   |   8 +--
 13 files changed, 116 insertions(+), 117 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381103.1624682 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktY-00034s-NP; Mon, 03 Aug 2026 05:07:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381103.1624682; Mon, 03 Aug 2026 05:07:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktY-00034h-Jp; Mon, 03 Aug 2026 05:07:24 +0000
Received: by outflank-mailman (input) for mailman id 1381103;
 Mon, 03 Aug 2026 05:07:23 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqktX-00032f-Bx
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqktW-006W8q-P2
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:22 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a7021f1-2eae-0a2a0a5409dd-0a2a450aec7a-34
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:22 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702209-f2d2-0a2a450a0019-d1558034b5d3-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:21 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49557167508so14758105e9.1
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:21 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733641; x=1786338441; 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=CM+qUXy25CRFKkF1HaPx8PYdTauLZnNcJY3C0JI+/Dc=;
        b=TCB+1OEl9u/sNipcbKczY61o/1VCQ2cKvMu9vCsZxuZYjSCIC+lbD8uxSbSpA9hMkf
         C7RQvNNHKu1AeZr7jHTyvZ0GTYURSf5ewWYa40W3s/rvl0zZHrmfpRUpMcfk3T6qIJxS
         UzX283JLA7W1WpQ5ZGqvrKiFpJJlANnjnM/5bWXahjGJQpFHelDaDU+10i3Q0KtwFmeD
         XCDCORthkgSwR+UJZGrqJiuhFDGqYr6WCTeMIXZx5xkqbMYfcnIU13FQStaHIIo98LLG
         YvKwaXeNDJbk+yqv5oKVsQl1MQaA8WCQukDhTDGSgeqQ48uYdsOGE4ZfD2Tgel6ch8Jb
         pmxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733641; x=1786338441;
        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=CM+qUXy25CRFKkF1HaPx8PYdTauLZnNcJY3C0JI+/Dc=;
        b=Fi5ahYbfUudRk+xY9zKdsQ0TGMN478GrmrMx6lq/NEkpj79j07uuU0Hx7Uy/ne+1DL
         YH8CKQnaGUwR1P6HUQteaotZn5pP7uhnvkxDSSMfcUA/MjYhQQnEXBzEHHUwA1drh5Fe
         4eZu6HG+lcnjVA7vUFZzlOyInGhKs75rFMdoCfsy/lCR1Wtcze9sWgHGEIPhgUm7TxMW
         Hh7neA1W2sECaUVKct+SqDNW3sWBRzgYiII3FgNjP4gloKKdZcQxMB6zEP6uya2UUHeS
         1WdwePmLn9sLwo5URu9didSk6H6msYxZ2HtK2/hGvraFZMRVJOoo6QKBlWm09+B7NTIp
         fXeQ==
X-Gm-Message-State: AOJu0YwYSU7n/hbCFNjkpvnZDMsooeCFb8MlOj5O+1HQUOBjeo3ZY5tU
	gfNGqZyo8J8NBJOXPGS5rc4EdoUX+NzktkvZiRUtyM8P/t2AQoECaX33pmuz3w==
X-Gm-Gg: AR+sD10wWtpzyABgA4Jnl+/5ppJRow5vpdjy958Co3o8wtwM6j0Y6xILBUX+nlN3c7u
	sLMxRWd4GW9mgjrR+cLFajVryYHbu2yTuMoNYcjEdT98XAJxEg1gaW+/QODyAswv8D/KAxG9sO/
	FaasbhF568aBSc/xZnkPykGkJAXhKBalS2G+YCD2qSXDLNdOl/S9CsfgjOl5s7tLRKZt8Q5ZZni
	M/XdGKgKeTAInx0lMjWXo2Cu6USCUfKxd0yq7Z83oIPzLHlZkwHdHPBV5K4qofDPrHgduTlCsKe
	uOemx92QnEe1v6hDL1CoWZxSK3o66xnqzDc/031W7CjRn3EgoZoW2lnOCyMvGNiVVV6HyQMLzjp
	mKUv2HpaBR0kyc7Rx0aWOnDtkdDFCqcrAJJWASRKCoHdirdv+KAwQG2c6PT6d197MKtFe6vTYB6
	Nvs+i4JyHCYsANXWexr92N0TsrW1dgYPgPb+xiKeNGbFVuVRyypVkZ4NYqLSqI0mA=
X-Received: by 2002:a05:600c:354a:b0:490:b8c0:d470 with SMTP id 5b1f17b1804b1-4980c67d71emr173613755e9.19.1785733640879;
        Sun, 02 Aug 2026 22:07:20 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 3/7] xen/sched: credit2: migrate to new sched_ops
Date: Mon,  3 Aug 2026 08:06:10 +0300
Message-Id: <20260803050614.5222-4-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785733641-518C5CFC-88A0B142/0/0
X-purgate-type: clean
X-purgate-size: 1270

Declare sched_credit2_def as a struct sched_ops instead of a struct
scheduler, dropping the .sched_data field, and register it with
REGISTER_SCHED_OPS() so it is found through sched_ops_array[]
instead of schedulers[].

This moves the credit2 scheduler onto the new sched_ops
registration path.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/credit2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 95946634d1..9bcc90004a 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -4230,11 +4230,10 @@ csched2_deinit(struct scheduler *ops)
     xfree(prv);
 }
 
-static const struct scheduler sched_credit2_def = {
+static const struct sched_ops sched_credit2_def = {
     .name           = "SMP Credit Scheduler rev2",
     .opt_name       = "credit2",
     .sched_id       = XEN_SCHEDULER_CREDIT2,
-    .sched_data     = NULL,
 
     .global_init    = csched2_global_init,
 
@@ -4269,4 +4268,4 @@ static const struct scheduler sched_credit2_def = {
     .free_domdata   = csched2_free_domdata,
 };
 
-REGISTER_SCHEDULER(sched_credit2_def);
+REGISTER_SCHED_OPS(sched_credit2_def);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381105.1624690 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktc-0003Ly-0E; Mon, 03 Aug 2026 05:07:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381105.1624690; Mon, 03 Aug 2026 05:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktb-0003Lr-TR; Mon, 03 Aug 2026 05:07:27 +0000
Received: by outflank-mailman (input) for mailman id 1381105;
 Mon, 03 Aug 2026 05:07:26 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqkta-0003Jz-Rr
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqkta-006WBT-8p
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:26 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702204-e002-0a2a0a5209dd-0a2a4509bd80-24
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:26 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a70220e-be1a-0a2a45090019-d1558035bc4b-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:26 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so8338955e9.0
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:26 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733646; x=1786338446; 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=21wuOD8HUjAVDqLCXgTFbv9BZRqUOWoQ8lloGzNNeyI=;
        b=W23IIMugZihv/E9MpUAS+BTshG2DONDxQU8e4HBIv7F9awZTjnUrciiIjKI3ytTOnN
         S0SjitHls5jaJ3iGwOoptFw48jeG+IFzMTJ3fNS4utYyMK301Qsdm2L+rTbuPkdpg2He
         6mGb6YUZyMQb2vGgetwGTWEY5TK2CD8ql7twP7st9E1DhwQpQlKliJc8v3Dib8W/UXZy
         tYxstGgejFRbfeMVT7tdP24aTyxh8YC07bohejlLN34exn+XLfl5pRuumumHokirBeTS
         sOYUeRjQ+nSj+w+R0q2kw7CYY5z9grp1KPBFjl1Z1ivcHNvRx8eMjoJr1ftZY5nB3gB3
         40mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733646; x=1786338446;
        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=21wuOD8HUjAVDqLCXgTFbv9BZRqUOWoQ8lloGzNNeyI=;
        b=H6oHgdCZgrsk4H6axV3roDcSR8/qykmtAYGjLFZJCVaTntmtSdewUWGR1Sfc0rvV2a
         8TNiVMkm1ls9e20kAZ8+emvtuQjD2nlc/26XS9kHkqxMryVOKtDnHgP+gmVCAync6Hg7
         2tcUEz2hbpg5rvCuiSX/fITi+iYsHvhhDW6RHZlk8AF9iWvwhoXghntsuj2FLqTdNfrc
         XlxTJfSxxRO+5co28p4lsdsizPYq2V1Bals+b67D3kl4dtMgo4hYJA+CvfBAtQzsoxIi
         uHlVAu7krYkeKjmf69ZXBVQIhmcWqnnQ10kAvHFiRO4AyQAlQtNbnxAohgONlktxDgql
         ns+Q==
X-Gm-Message-State: AOJu0YysNBoDhQ6/kWHS+H9elxYcqZs47xGn4j3EJkCn1uODDuo4+5Wk
	3hWyPN3BpunpOA1T4y40QXkDAI7gG7wTWIh2k6C+zVDW7fYrs+zDQnX4WCl0fw==
X-Gm-Gg: AR+sD13NVLoLS3Axl+d/RuimuCzfkWglb0hAOt/C604Hr9ndJUgY8Tuk0Vr4Lv4KROJ
	mjqsnV7OrewQxl3O+wofqVpjIn+NcIiVUVsfwWzHtJa/+Rjk41ntLvPrFFt4oybv9nuooi8LyTA
	V08aIKfwbRnT5hsdbPboAKyOl70PusSAmOSQ5LjAlO2RXnSmgdvGVYy3j0yuqjcj2RtuzX0o/9A
	WjuPdNZyRLzHmukNf+mGjpagRRLrvBk3ybJ/FtxmHWjdV+NdDF9xm+6+tfIMdFLVaLCbWFSFpOw
	Cre4nIF/FECs/gDUsT1Y/8IE60Ne6+mwmUTvnlugFZUPyr0kgx0RjgoWADEvko4bOpKh37TAmp9
	osE9ITBLFAp6rdaEMIbVd1KiuDUeTLeuXiJl2at4yrSVSxYSt57Xtlx2uXAVBJF4M7bIu2R3TOH
	7M9xgBLtauuGnMZxlnTqRDhDdTfLDVRd4JxvUl3jpI/Vfbbh6JIK4HZLN9pew6+w==
X-Received: by 2002:a05:600d:8498:20b0:497:fecd:5b00 with SMTP id 5b1f17b1804b1-4980c673230mr145973255e9.9.1785733645587;
        Sun, 02 Aug 2026 22:07:25 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 4/7] xen/sched: rtds: migrate to new sched_ops
Date: Mon,  3 Aug 2026 08:06:11 +0300
Message-Id: <20260803050614.5222-5-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785733646-FDC6D034-B5E3BD18/0/0
X-purgate-type: clean
X-purgate-size: 1259

Declare sched_rtds_def as a struct sched_ops instead of a struct
scheduler, dropping the .sched_data field, and register it with
REGISTER_SCHED_OPS() so it is found through sched_ops_array[]
instead of schedulers[].

This moves the rtds scheduler onto the new sched_ops
registration path.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/rt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 744f214173..8b4f05e2d1 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1617,11 +1617,10 @@ static void cf_check repl_timer_handler(void *data)
     spin_unlock_irq(&prv->lock);
 }
 
-static const struct scheduler sched_rtds_def = {
+static const struct sched_ops sched_rtds_def = {
     .name           = "SMP RTDS Scheduler",
     .opt_name       = "rtds",
     .sched_id       = XEN_SCHEDULER_RTDS,
-    .sched_data     = NULL,
 
     .dump_cpu_state = rt_dump_pcpu,
     .dump_settings  = rt_dump,
@@ -1646,4 +1645,4 @@ static const struct scheduler sched_rtds_def = {
     .move_timers    = rt_move_timers,
 };
 
-REGISTER_SCHEDULER(sched_rtds_def);
+REGISTER_SCHED_OPS(sched_rtds_def);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381107.1624700 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktg-0003mE-6J; Mon, 03 Aug 2026 05:07:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381107.1624700; Mon, 03 Aug 2026 05:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktg-0003m5-3J; Mon, 03 Aug 2026 05:07:32 +0000
Received: by outflank-mailman (input) for mailman id 1381107;
 Mon, 03 Aug 2026 05:07:31 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqktf-0003fS-4Y
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqkte-00DMN1-Hk
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:30 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702203-bab6-0a2a0a5309dd-0a2a450b8eae-44
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:30 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702212-b7e8-0a2a450b0019-d1558034e9ac-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:30 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4955de8797cso9107745e9.3
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:30 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733650; x=1786338450; 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=JMMpBw4vbiYd/isxZEkW0aMhzAaKpMobKqilYthaK3Q=;
        b=Wp06fp7foYAnABLEJc4NYwHmXkWBaExspDvCGo4STNyI6Tf8//6mewsVoCIMZn9bFm
         NQHJg/VFr2XVPQdKPrOclQrQIiqp7BixscQAS0eYURiFTv00ZGHrab/r3KJIbmVVlAFg
         wN5RTLVk6rhyGnvRjjkwZxeF2msgaAwHML3QWOQ+E+NmDVsiWr/a0J0q5maq2EfL0+XL
         HRdLLinvJPmowhPUt/Ixxu4Jgvqu97BD1RoG8qFDqGWgMh5B4cyO/QjC4mm4/n3KwMvN
         al5GvX0AnFc+A0xHN2alfvrEdCSz75Lc+ZshthfjmNxX85SEo4mTkHczDmdnbooy9Wr5
         9daQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733650; x=1786338450;
        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=JMMpBw4vbiYd/isxZEkW0aMhzAaKpMobKqilYthaK3Q=;
        b=J2DHJ5nJNcsuQ7WPmDVjO3I1+/wi0ee5GmwNpC41pRUuIEmskffz+gMyLbzaL9JyFN
         /IYwqSrmyeUrOeklk2BYNd06xYaHKqdBwlAS9iSFohF1zSmEfpifXXyBGB1kXx3Fg6SO
         eiLSPXokXGgontFm8L8GUTwHHek6y+SE3ZYIJVMxhqGDg5lwkboOUYz5YgKkYmir+bNp
         DWZsoGcHkqDscG0jDjCpHu+56dHfvx4j3H6RP4DbEJUbETBxJaanDicuX6jGAVh4uic+
         ymETxyks/hdL3jawjxt7O4fHGVuHZIz5gbVfDHWcah/AmDWceIHe/uVrCvEEghuIuC3+
         Mhcw==
X-Gm-Message-State: AOJu0Ywftkr+24lSEORak2pvgnutdQOb0UILBO/THiyk6WH3vS93ZYfp
	6lLJtNfNOs+45O12X1MGrg1jS+EcLz3zxdUdPMRrsYofUDuyvg6T/5cgJcoQig==
X-Gm-Gg: AR+sD10d+tkzIz7FUfNLEyV+NgiNVZ3DgfuFrxUtv8btQDCXyvDWdfJYTUp/+rcffi8
	5AnNReXsa7Q4Oq2Bnhfh71np9omhVPoOhnWoNgAOhtvmcNR1/p3UhSAYEn7eG8uE8BXc2Mo/Xt/
	sL3Q62cU233aVS1HeU0iej5tDkXYr8eWA5VzCmdQp+MzjXnKxIiL34z7O1LD6DEXoqnU16DyOne
	IEkkjSpRCbbTVlhPgeW1Blclvm02y0+XuHcyZ90M9iDE3wud4fxjc4zVS6TXPxFvg2BiQ6xUswg
	Mb4Q0b/tX8fRy44Bgco+7S4dbOhYbiPnOsmvd/VV7TRHUHeCSko8SM4NNyN8mEAZUE/non9FX5S
	yXD17u+Bs2Pf4zWDcXgUazJe0Xd1TSgKA3GLxqS4VYMzLEqGkv8nd+Sxqxa5NgEK1W+2sNaxTMk
	w6Og8Th/Si64l7Slvb9XvDJxpdPsDgDn9k9zwrd/zFjKaueUtu8gApLfu76WYhRw==
X-Received: by 2002:a05:600c:3488:b0:493:e6f7:ad75 with SMTP id 5b1f17b1804b1-4980c653e15mr179910915e9.11.1785733649963;
        Sun, 02 Aug 2026 22:07:29 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 5/7] xen/sched: arinc653: migrate to new sched_ops
Date: Mon,  3 Aug 2026 08:06:12 +0300
Message-Id: <20260803050614.5222-6-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785733650-1B8D19EA-0CF7C641/0/0
X-purgate-type: clean
X-purgate-size: 1571

Declare sched_arinc653_def as a struct sched_ops instead of a struct
scheduler, dropping the .sched_data field, and register it with
REGISTER_SCHED_OPS() so it is found through sched_ops_array[]
instead of schedulers[].

This moves the arinc653 scheduler onto the new sched_ops
registration path.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/arinc653.c | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 32c596a23c..efcaa44089 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -702,17 +702,10 @@ a653sched_adjust_global(const struct scheduler *ops,
 }
 #endif /* CONFIG_SYSCTL */
 
-/**
- * This structure defines our scheduler for Xen.
- * The entries tell Xen where to find our scheduler-specific
- * callback functions.
- * The symbol must be visible to the rest of Xen at link time.
- */
-static const struct scheduler sched_arinc653_def = {
+static const struct sched_ops sched_arinc653_def = {
     .name           = "ARINC 653 Scheduler",
     .opt_name       = "arinc653",
     .sched_id       = XEN_SCHEDULER_ARINC653,
-    .sched_data     = NULL,
 
     .init           = a653sched_init,
     .deinit         = a653sched_deinit,
@@ -743,7 +736,7 @@ static const struct scheduler sched_arinc653_def = {
     .dump_cpu_state = NULL,
 };
 
-REGISTER_SCHEDULER(sched_arinc653_def);
+REGISTER_SCHED_OPS(sched_arinc653_def);
 
 /*
  * Local variables:
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:07:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:07:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381131.1624709 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktu-0005Mh-EJ; Mon, 03 Aug 2026 05:07:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381131.1624709; Mon, 03 Aug 2026 05:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqktu-0005Ll-BI; Mon, 03 Aug 2026 05:07:46 +0000
Received: by outflank-mailman (input) for mailman id 1381131;
 Mon, 03 Aug 2026 05:07:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqkts-0005Gb-Lx
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:07:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqkts-003lut-2o
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:07:44 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702215-2eae-0a2a0a5409dd-0a2a45028d14-18
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:44 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a70221f-6ca4-0a2a45020019-d1558034ccc0-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:43 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4955aa106b1so15227285e9.0
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:43 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733663; x=1786338463; 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=Dfo9WveiLxrAqqO79sjLeKOkwe8r7c3VXRClpdMKLaI=;
        b=WnxsgV08P7pAvLdbzi4gu2aO28A/JQqERE42GrWvurPzt1MRNFhXrWPd179i44dp39
         GP/QTO1QU2dMnO6cqsTCl+sbZnm1IW4SmwRkEXLPTDAQffANuDjMNn4DRJR/PsChQPi6
         X/ZfRbik6/ahzjhKWw7qkKeLB81KOK6Kh3mV302zJOMB1eK6c8f+ShgwPFt0+A6bqpwz
         asov8DtioNL4tH6dCN7+O8DuzfpqY89a33Ld6b9m9OgpI4c25F27uO29ygx0ffWAmJGP
         ib2o6qsSR10zdQ1OzY/bVk8AtTUuWVjLo1pv9j/O21usoLk00JTLVFUTygDrzbgUfl4h
         dyVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733663; x=1786338463;
        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=Dfo9WveiLxrAqqO79sjLeKOkwe8r7c3VXRClpdMKLaI=;
        b=BHB4UvxOXoezvnogpZjXoeuGBae0dyiMr9j6SjEPBe6dc4rmzm3Crk/JSxR6OWIiBD
         V560phCi7MujTWFZNdMUYeuSFJx8icu4Uzgws7p/G+nqZNDRNQhuxnnXL3eTP9zEjwl2
         sHkugO3B9EWoR0U8QZtctW8W7Aa23AKiJIaoLFOrnt1vCPsceSfjqbIgVcszhbsXU2dr
         2IAzFV2lKzvlwolFoj+LciNkKB9speTTju6Gl3VxCkFuWbwbRQZtzpsvGyfs/g78A/X1
         t2jzyQGwxvpM2lJyVRJcnZOsNjYB1TKKNNg1BHD02ljcLjoq4hSvG7yhlaarrbc78hx0
         Bi6g==
X-Gm-Message-State: AOJu0Yzpo2IBp14364b0Cy8P4uJds3/WhzqDLWaKhFMMaViHfABw+sZO
	YSHfZaZbWUVeCvftd/UgRtIquJzVtN/bpm0sw4Ef4j8yU1G6lN3shaCzmRWKkQ==
X-Gm-Gg: AR+sD1292SEmgbWgb49iGWx5xy9mfyDPIFYySsqFy6WYPYYr+gZUkNDNdmU0fMjIcEY
	0rhBqeQC4E6NmEAxFwdBGGSZjzrF/cwk22o6APdw2qnWxJ+Ofn614+Dq7ZH6p5wgY7cczliAsYg
	Nlwlun3tzKy5KlHP5g5zNQNAmF11g3I+JhLPEPpxqM21ZcXVTLOPBrkOWU6cnosDmGhRmwuNqhO
	pVHelQGsVaJLkAOxS3TopyD1TT7IAtha8yb4AnvNfs2nmAbSM/5CQx8JzMQhq5/T9Q5U9WF4n3z
	4/ElqbEaCJR8eKMMz/pI7b4I9inqff3htCZBqcd2MaivFKHsqH2WDuz8mtQNuBFh+Kfh3KOk8PV
	XT5+AxJpaG/LAs5TO5wqBZh24bcPpyAqfsK6Jq3b2U9WCl5SYh9XJ89Veb4Nu0hV7kDYuuWEIMm
	GlUxAR2Qopzo6WOY6xSIJ6dUMvxSseIVz2JxjvkZxB3ycNWrYoYE6iizjAkxWJtg==
X-Received: by 2002:a05:600c:8b14:b0:495:4cb8:42b9 with SMTP id 5b1f17b1804b1-4980c66d8cemr193280875e9.4.1785733663338;
        Sun, 02 Aug 2026 22:07:43 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 7/7] xen/sched: remove old scheduler registration, shrink struct scheduler
Date: Mon,  3 Aug 2026 08:06:14 +0300
Message-Id: <20260803050614.5222-8-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785733664-662A92AC-64EF8C7C/0/0
X-purgate-type: clean
X-purgate-size: 25587

Every in-tree scheduler now registers through sched_ops instead of
the original struct-scheduler-as-vtable path, so schedulers[],
REGISTER_SCHEDULER() and NUM_SCHEDULERS have no remaining users.
Remove them and finish the change struct sched_ops was introduced
for: struct scheduler is shrunk down to just its per-cpupool
fields - a pointer to a shared sched_ops, plus sched_data and
cpupool.

scheduler_alloc() now stores a pointer to the matching sched_ops
instance instead of copying every field into a fresh allocation.
Cpupools sharing a scheduler type now share one dispatch table
instead of each holding a private copy of it.

Every accessor in private.h is updated from s->field to
s->ops->field to match. sched_idle_ops is split the same way
every other scheduler was.

A handful of call sites elsewhere read a scheduler's name,
opt_name or sched_id directly and are updated to go through
->ops as well.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/arch/arm/xen.lds.S     |   1 -
 xen/arch/ppc/xen.lds.S     |   1 -
 xen/arch/riscv/xen.lds.S   |   1 -
 xen/arch/x86/xen.lds.S     |   1 -
 xen/common/sched/core.c    | 144 +++++-----------------------------
 xen/common/sched/cpupool.c |   6 +-
 xen/common/sched/private.h | 155 ++++++++++---------------------------
 xen/include/xen/xen.lds.h  |   6 --
 8 files changed, 67 insertions(+), 248 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9a63fa36a0..07bf875599 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -93,7 +93,6 @@ SECTIONS
   .data : {                    /* Data */
        *(.data.page_aligned)
 
-       SCHEDULER_ARRAY
        SCHED_OPS_ARRAY
        HYPFS_PARAM
 
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index da8f73d85b..1f4e200693 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -84,7 +84,6 @@ SECTIONS
     DECL_SECTION(.data) {                    /* Data */
         *(.data.page_aligned)
 
-        SCHEDULER_ARRAY
         SCHED_OPS_ARRAY
         HYPFS_PARAM
 
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 01f202e504..97f2db1dfd 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -89,7 +89,6 @@ SECTIONS
     .data : {                    /* Data */
         *(.data.page_aligned)
 
-        SCHEDULER_ARRAY
         SCHED_OPS_ARRAY
         HYPFS_PARAM
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d128a30440..0f506ff1f6 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -306,7 +306,6 @@ SECTIONS
   DECL_SECTION(.data.read_mostly) {
        *(.data.read_mostly)
 
-       SCHEDULER_ARRAY
        SCHED_OPS_ARRAY
        HYPFS_PARAM
   } PHDR(text)
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index fb2d1d5314..4e5f78e84d 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -87,10 +87,6 @@ DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
 /* How many urgent vcpus. */
 DEFINE_PER_CPU(atomic_t, sched_urgent_count);
 
-extern const struct scheduler *__start_schedulers_array[], *__end_schedulers_array[];
-#define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
-#define schedulers __start_schedulers_array
-
 extern const struct sched_ops *__start_sched_ops_array[], *__end_sched_ops_array[];
 #define NUM_SCHED_OPS (__end_sched_ops_array - __start_sched_ops_array)
 #define sched_ops_array __start_sched_ops_array
@@ -103,42 +99,6 @@ static void sched_set_affinity(
     struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
 
 
-static void sched_ops_to_scheduler(
-        struct scheduler *sched, const struct sched_ops *ops)
-{
-    sched->name            = ops->name;
-    sched->opt_name        = ops->opt_name;
-    sched->sched_id        = ops->sched_id;
-    sched->global_init     = ops->global_init;
-    sched->init            = ops->init;
-    sched->deinit          = ops->deinit;
-    sched->free_udata      = ops->free_udata;
-    sched->alloc_udata     = ops->alloc_udata;
-    sched->free_pdata      = ops->free_pdata;
-    sched->alloc_pdata     = ops->alloc_pdata;
-    sched->deinit_pdata    = ops->deinit_pdata;
-    sched->alloc_domdata   = ops->alloc_domdata;
-    sched->free_domdata    = ops->free_domdata;
-    sched->switch_sched    = ops->switch_sched;
-    sched->insert_unit     = ops->insert_unit;
-    sched->remove_unit     = ops->remove_unit;
-    sched->sleep           = ops->sleep;
-    sched->wake            = ops->wake;
-    sched->yield           = ops->yield;
-    sched->context_saved   = ops->context_saved;
-    sched->do_schedule     = ops->do_schedule;
-    sched->pick_resource   = ops->pick_resource;
-    sched->migrate         = ops->migrate;
-    sched->adjust          = ops->adjust;
-    sched->adjust_affinity = ops->adjust_affinity;
-#ifdef CONFIG_SYSCTL
-    sched->adjust_global   = ops->adjust_global;
-#endif
-    sched->dump_settings   = ops->dump_settings;
-    sched->dump_cpu_state  = ops->dump_cpu_state;
-    sched->move_timers     = ops->move_timers;
-}
-
 static struct sched_resource *cf_check
 sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit *unit)
 {
@@ -168,10 +128,9 @@ static void cf_check sched_idle_schedule(
     unit->next_task = sched_idle_unit(cpu);
 }
 
-static struct scheduler sched_idle_ops = {
+static struct sched_ops sched_idle_sched_ops = {
     .name           = "Idle Scheduler",
     .opt_name       = "idle",
-    .sched_data     = NULL,
 
     .pick_resource  = sched_idle_res_pick,
     .do_schedule    = sched_idle_schedule,
@@ -180,6 +139,11 @@ static struct scheduler sched_idle_ops = {
     .free_udata     = sched_idle_free_udata,
 };
 
+static struct scheduler sched_idle_ops = {
+    .ops         = &sched_idle_sched_ops,
+    .sched_data = NULL,
+};
+
 static inline struct vcpu *unit2vcpu_cpu(const struct sched_unit *unit,
                                          unsigned int cpu)
 {
@@ -2122,7 +2086,7 @@ long do_set_timer_op(s_time_t timeout)
 /* scheduler_id - fetch ID of current scheduler */
 int scheduler_id(void)
 {
-    return operations.sched_id;
+    return operations.ops->sched_id;
 }
 #endif
 
@@ -2131,7 +2095,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
     long ret;
 
-    if ( op->sched_id != dom_scheduler(d)->sched_id )
+    if ( op->sched_id != dom_scheduler(d)->ops->sched_id )
         return -EINVAL;
 
     switch ( op->cmd )
@@ -2177,7 +2141,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 
     rcu_read_lock(&sched_res_rculock);
 
-    rc = ((op->sched_id == pool->sched->sched_id)
+    rc = ((op->sched_id == pool->sched->ops->sched_id)
           ? sched_adjust_cpupool(pool->sched, op) : -EINVAL);
 
     rcu_read_unlock(&sched_res_rculock);
@@ -2344,7 +2308,7 @@ static struct sched_unit *do_schedule(struct sched_unit *prev, s_time_t now,
     struct sched_unit *next;
 
     /* get policy-specific decision on scheduling... */
-    sched->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
+    sched->ops->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
 
     next = prev->next_task;
 
@@ -3033,18 +2997,6 @@ void scheduler_enable(void)
     scheduler_active = true;
 }
 
-static inline
-const struct scheduler *__init sched_get_by_name(const char *sched_name)
-{
-    unsigned int i;
-
-    for ( i = 0; i < NUM_SCHEDULERS; i++ )
-        if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
-            return schedulers[i];
-
-    return NULL;
-}
-
 static inline
 const struct sched_ops *__init sched_ops_get_by_name(const char* sched_name)
 {
@@ -3058,13 +3010,7 @@ const struct sched_ops *__init sched_ops_get_by_name(const char* sched_name)
 
 int __init sched_get_id_by_name(const char *sched_name)
 {
-    const struct scheduler *scheduler = sched_get_by_name(sched_name);
-    const struct sched_ops *ops;
-
-    if ( scheduler )
-        return scheduler->sched_id;
-
-    ops = sched_ops_get_by_name(sched_name);
+    const struct sched_ops *ops = sched_ops_get_by_name(sched_name);
     return ops ? ops->sched_id : -1;
 }
 
@@ -3072,40 +3018,11 @@ int __init sched_get_id_by_name(const char *sched_name)
 void __init scheduler_init(void)
 {
     struct domain *idle_domain;
-    const struct scheduler *scheduler;
     const struct sched_ops *ops;
     int i;
 
     scheduler_enable();
 
-    for ( i = 0; i < NUM_SCHEDULERS; i++)
-    {
-#define sched_test_func(f)                               \
-        if ( !schedulers[i]->f )                         \
-        {                                                \
-            printk("scheduler %s misses .%s, dropped\n", \
-                   schedulers[i]->opt_name, #f);         \
-            schedulers[i] = NULL;                        \
-        }
-
-        sched_test_func(init);
-        sched_test_func(deinit);
-        sched_test_func(pick_resource);
-        sched_test_func(alloc_udata);
-        sched_test_func(free_udata);
-        sched_test_func(switch_sched);
-        sched_test_func(do_schedule);
-
-#undef sched_test_func
-
-        if ( schedulers[i]->global_init && schedulers[i]->global_init() < 0 )
-        {
-            printk("scheduler %s failed initialization, dropped\n",
-                   schedulers[i]->opt_name);
-            schedulers[i] = NULL;
-        }
-    }
-
     for ( i = 0; i < NUM_SCHED_OPS; i++)
     {
 #define sched_test_func(f)                               \
@@ -3134,30 +3051,22 @@ void __init scheduler_init(void)
         }
     }
 
-    scheduler = sched_get_by_name(opt_sched);
-    ops = scheduler ? NULL : sched_ops_get_by_name(opt_sched);
-    if ( !scheduler && !ops )
+    ops = sched_ops_get_by_name(opt_sched);
+    if ( !ops )
     {
         printk("Could not find scheduler: %s\n", opt_sched);
-        scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
-        ops = scheduler ? NULL : sched_ops_get_by_name(CONFIG_SCHED_DEFAULT);
-        BUG_ON(!scheduler && !ops);
-        if ( scheduler )
-            printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
-        else
-            printk("Using '%s' (%s)\n", ops->name, ops->opt_name);
+        ops = sched_ops_get_by_name(CONFIG_SCHED_DEFAULT);
+        BUG_ON(!ops);
+        printk("Using '%s' (%s)\n", ops->name, ops->opt_name);
     }
 
-    if ( scheduler )
-        operations = *scheduler;
-    else
-        sched_ops_to_scheduler(&operations, ops);
+    operations.ops = ops;
 
     if ( cpu_schedule_up(0) )
         BUG();
     register_cpu_notifier(&cpu_schedule_nfb);
 
-    printk("Using scheduler: %s (%s)\n", operations.name, operations.opt_name);
+    printk("Using scheduler: %s (%s)\n", operations.ops->name, operations.ops->opt_name);
     if ( sched_init(&operations) )
         panic("scheduler returned error on init\n");
 
@@ -3507,28 +3416,17 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
     int ret;
     struct scheduler *sched;
 
-    for ( i = 0; i < NUM_SCHEDULERS; i++ )
-        if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
-            goto found;
-
     for ( i = 0; i < NUM_SCHED_OPS; i++ )
         if ( sched_ops_array[i] && sched_ops_array[i]->sched_id == sched_id )
-            goto found_new;
+            goto found;
 
     return ERR_PTR(-ENOENT);
 
  found:
-    if ( (sched = xmalloc(struct scheduler)) == NULL )
-        return ERR_PTR(-ENOMEM);
-    memcpy(sched, schedulers[i], sizeof(*sched));
-    goto init;
-
- found_new:
     if ( (sched = xzalloc(struct scheduler)) == NULL )
         return ERR_PTR(-ENOMEM);
-    sched_ops_to_scheduler(sched, sched_ops_array[i]);
+    sched->ops = sched_ops_array[i];
 
- init:
     if ( (ret = sched_init(sched)) != 0 )
     {
         xfree(sched);
@@ -3559,7 +3457,7 @@ void schedule_dump(struct cpupool *c)
     {
         sched = c->sched;
         cpus = c->res_valid;
-        printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
+        printk("Scheduler: %s (%s)\n", sched->ops->name, sched->ops->opt_name);
         sched_dump_settings(sched);
     }
     else
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 081e1053eb..1c70b58409 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -338,7 +338,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
     spin_unlock(&cpupool_lock);
 
     debugtrace_printk("Created cpupool %u with scheduler %s (%s)\n",
-                      c->cpupool_id, c->sched->name, c->sched->opt_name);
+                      c->cpupool_id, c->sched->ops->name, c->sched->ops->opt_name);
 
     return c;
 
@@ -862,7 +862,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
         if ( c == NULL )
             break;
         op->cpupool_id = c->cpupool_id;
-        op->sched_id = c->sched->sched_id;
+        op->sched_id = c->sched->ops->sched_id;
         op->n_dom = c->n_dom;
         ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
         cpupool_put(c);
@@ -1294,7 +1294,7 @@ struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
     struct cpupool *pool;
 
     if ( sched_id < 0 )
-        sched_id = scheduler_get_default()->sched_id;
+        sched_id = scheduler_get_default()->ops->sched_id;
 
     pool = cpupool_create(pool_id, sched_id);
 
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 4dd5c99b87..c03063befe 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -365,198 +365,132 @@ struct sched_ops {
 };
 
 struct scheduler {
-    const char *name;       /* full name for this scheduler      */
-    const char *opt_name;   /* option name for this scheduler    */
-    unsigned int sched_id;  /* ID for this scheduler             */
-    void *sched_data;       /* global data pointer               */
-    struct cpupool *cpupool;/* points to this scheduler's pool   */
-
-    int          (*global_init)    (void);
-
-    int          (*init)           (struct scheduler *ops);
-    void         (*deinit)         (struct scheduler *ops);
-
-    void         (*free_udata)     (const struct scheduler *ops, void *priv);
-    void *       (*alloc_udata)    (const struct scheduler *ops,
-                                    struct sched_unit *unit, void *dd);
-
-    void         (*free_pdata)     (const struct scheduler *ops,
-                                    void *pcpu, int cpu);
-    void *       (*alloc_pdata)    (const struct scheduler *ops, int cpu);
-    void         (*deinit_pdata)   (const struct scheduler *ops,
-                                    void *pcpu, int cpu);
-
-    /* Returns ERR_PTR(-err) for error, NULL for 'nothing needed'. */
-    void *       (*alloc_domdata)  (const struct scheduler *ops,
-                                    struct domain *dom);
-    /* Idempotent. */
-    void         (*free_domdata)   (const struct scheduler *ops, void *data);
-
-    spinlock_t * (*switch_sched)   (struct scheduler *new_ops, unsigned int cpu,
-                                    void *pdata, void *vdata);
-
-    /* Activate / deactivate units in a cpu pool */
-    void         (*insert_unit)    (const struct scheduler *ops,
-                                    struct sched_unit *unit);
-    void         (*remove_unit)    (const struct scheduler *ops,
-                                    struct sched_unit *unit);
-
-    void         (*sleep)          (const struct scheduler *ops,
-                                    struct sched_unit *unit);
-    void         (*wake)           (const struct scheduler *ops,
-                                    struct sched_unit *unit);
-    void         (*yield)          (const struct scheduler *ops,
-                                    struct sched_unit *unit);
-    void         (*context_saved)  (const struct scheduler *ops,
-                                    struct sched_unit *unit);
-
-    void         (*do_schedule)    (const struct scheduler *ops,
-                                    struct sched_unit *currunit, s_time_t now,
-                                    bool tasklet_work_scheduled);
-
-    struct sched_resource *(*pick_resource)(const struct scheduler *ops,
-                                            const struct sched_unit *unit);
-    void         (*migrate)        (const struct scheduler *ops,
-                                    struct sched_unit *unit,
-                                    unsigned int new_cpu);
-    int          (*adjust)         (const struct scheduler *ops,
-                                    struct domain *d,
-                                    struct xen_domctl_scheduler_op *op);
-    void         (*adjust_affinity)(const struct scheduler *ops,
-                                    struct sched_unit *unit,
-                                    const struct cpumask *hard,
-                                    const struct cpumask *soft);
-#ifdef CONFIG_SYSCTL
-    int          (*adjust_global)  (const struct scheduler *ops,
-                                    struct xen_sysctl_scheduler_op *sc);
-#endif
-    void         (*dump_settings)  (const struct scheduler *ops);
-    void         (*dump_cpu_state) (const struct scheduler *ops, int cpu);
-    void         (*move_timers)    (const struct scheduler *ops,
-                                    struct sched_resource *sr);
+    const struct sched_ops *ops; /* shared, read-only dispatch table */
+    void *sched_data;            /* global data pointer               */
+    struct cpupool *cpupool;     /* points to this scheduler's pool   */
 };
 
 static inline int sched_init(struct scheduler *s)
 {
-    return s->init(s);
+    return s->ops->init(s);
 }
 
 static inline void sched_deinit(struct scheduler *s)
 {
-    s->deinit(s);
+    s->ops->deinit(s);
 }
 
 static inline spinlock_t *sched_switch_sched(struct scheduler *s,
                                              unsigned int cpu,
                                              void *pdata, void *vdata)
 {
-    return s->switch_sched(s, cpu, pdata, vdata);
+    return s->ops->switch_sched(s, cpu, pdata, vdata);
 }
 
 static inline void sched_dump_settings(const struct scheduler *s)
 {
-    if ( s->dump_settings )
-        s->dump_settings(s);
+    if ( s->ops->dump_settings )
+        s->ops->dump_settings(s);
 }
 
 static inline void sched_dump_cpu_state(const struct scheduler *s, int cpu)
 {
-    if ( s->dump_cpu_state )
-        s->dump_cpu_state(s, cpu);
+    if ( s->ops->dump_cpu_state )
+        s->ops->dump_cpu_state(s, cpu);
 }
 
 static inline void *sched_alloc_domdata(const struct scheduler *s,
                                         struct domain *d)
 {
-    return s->alloc_domdata ? s->alloc_domdata(s, d) : NULL;
+    return s->ops->alloc_domdata ? s->ops->alloc_domdata(s, d) : NULL;
 }
 
 static inline void sched_free_domdata(const struct scheduler *s,
                                       void *data)
 {
-    ASSERT(s->free_domdata || !data);
-    if ( s->free_domdata )
-        s->free_domdata(s, data);
+    ASSERT(s->ops->free_domdata || !data);
+    if ( s->ops->free_domdata )
+        s->ops->free_domdata(s, data);
 }
 
 static inline void *sched_alloc_pdata(const struct scheduler *s, int cpu)
 {
-    return s->alloc_pdata ? s->alloc_pdata(s, cpu) : NULL;
+    return s->ops->alloc_pdata ? s->ops->alloc_pdata(s, cpu) : NULL;
 }
 
 static inline void sched_free_pdata(const struct scheduler *s, void *data,
                                     int cpu)
 {
-    ASSERT(s->free_pdata || !data);
-    if ( s->free_pdata )
-        s->free_pdata(s, data, cpu);
+    ASSERT(s->ops->free_pdata || !data);
+    if ( s->ops->free_pdata )
+        s->ops->free_pdata(s, data, cpu);
 }
 
 static inline void sched_deinit_pdata(const struct scheduler *s, void *data,
                                       int cpu)
 {
-    if ( s->deinit_pdata )
-        s->deinit_pdata(s, data, cpu);
+    if ( s->ops->deinit_pdata )
+        s->ops->deinit_pdata(s, data, cpu);
 }
 
 static inline void *sched_alloc_udata(const struct scheduler *s,
                                       struct sched_unit *unit, void *dom_data)
 {
-    return s->alloc_udata(s, unit, dom_data);
+    return s->ops->alloc_udata(s, unit, dom_data);
 }
 
 static inline void sched_free_udata(const struct scheduler *s, void *data)
 {
-    s->free_udata(s, data);
+    s->ops->free_udata(s, data);
 }
 
 static inline void sched_insert_unit(const struct scheduler *s,
                                      struct sched_unit *unit)
 {
-    if ( s->insert_unit )
-        s->insert_unit(s, unit);
+    if ( s->ops->insert_unit )
+        s->ops->insert_unit(s, unit);
 }
 
 static inline void sched_remove_unit(const struct scheduler *s,
                                      struct sched_unit *unit)
 {
-    if ( s->remove_unit )
-        s->remove_unit(s, unit);
+    if ( s->ops->remove_unit )
+        s->ops->remove_unit(s, unit);
 }
 
 static inline void sched_sleep(const struct scheduler *s,
                                struct sched_unit *unit)
 {
-    if ( s->sleep )
-        s->sleep(s, unit);
+    if ( s->ops->sleep )
+        s->ops->sleep(s, unit);
 }
 
 static inline void sched_wake(const struct scheduler *s,
                               struct sched_unit *unit)
 {
-    if ( s->wake )
-        s->wake(s, unit);
+    if ( s->ops->wake )
+        s->ops->wake(s, unit);
 }
 
 static inline void sched_yield(const struct scheduler *s,
                                struct sched_unit *unit)
 {
-    if ( s->yield )
-        s->yield(s, unit);
+    if ( s->ops->yield )
+        s->ops->yield(s, unit);
 }
 
 static inline void sched_context_saved(const struct scheduler *s,
                                        struct sched_unit *unit)
 {
-    if ( s->context_saved )
-        s->context_saved(s, unit);
+    if ( s->ops->context_saved )
+        s->ops->context_saved(s, unit);
 }
 
 static inline void sched_migrate(const struct scheduler *s,
                                  struct sched_unit *unit, unsigned int cpu)
 {
-    if ( s->migrate )
-        s->migrate(s, unit, cpu);
+    if ( s->ops->migrate )
+        s->ops->migrate(s, unit, cpu);
     else
         sched_set_res(unit, get_sched_res(cpu));
 }
@@ -564,7 +498,7 @@ static inline void sched_migrate(const struct scheduler *s,
 static inline struct sched_resource *sched_pick_resource(
     const struct scheduler *s, const struct sched_unit *unit)
 {
-    return s->pick_resource(s, unit);
+    return s->ops->pick_resource(s, unit);
 }
 
 static inline void sched_adjust_affinity(const struct scheduler *s,
@@ -572,29 +506,29 @@ static inline void sched_adjust_affinity(const struct scheduler *s,
                                          const cpumask_t *hard,
                                          const cpumask_t *soft)
 {
-    if ( s->adjust_affinity )
-        s->adjust_affinity(s, unit, hard, soft);
+    if ( s->ops->adjust_affinity )
+        s->ops->adjust_affinity(s, unit, hard, soft);
 }
 
 static inline int sched_adjust_dom(const struct scheduler *s, struct domain *d,
                                    struct xen_domctl_scheduler_op *op)
 {
-    return s->adjust ? s->adjust(s, d, op) : 0;
+    return s->ops->adjust ? s->ops->adjust(s, d, op) : 0;
 }
 
 #ifdef CONFIG_SYSCTL
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
-    return s->adjust_global ? s->adjust_global(s, op) : 0;
+    return s->ops->adjust_global ? s->ops->adjust_global(s, op) : 0;
 }
 #endif
 
 static inline void sched_move_timers(const struct scheduler *s,
                                      struct sched_resource *sr)
 {
-    if ( s->move_timers )
-        s->move_timers(s, sr);
+    if ( s->ops->move_timers )
+        s->ops->move_timers(s, sr);
 }
 
 static inline void sched_unit_pause_nosync(const struct sched_unit *unit)
@@ -613,9 +547,6 @@ static inline void sched_unit_unpause(const struct sched_unit *unit)
         vcpu_unpause(v);
 }
 
-#define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
-  __used_section(".data.schedulers") = &(x)
-
 #define REGISTER_SCHED_OPS(x) static const struct sched_ops *x##_entry \
   __used_section(".data.sched_ops") = &(x)
 
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index 157d48eabd..0005c38486 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -173,12 +173,6 @@
        _edevice = .;        \
   } :text
 
-#define SCHEDULER_ARRAY              \
-       . = ALIGN(POINTER_ALIGN);     \
-       __start_schedulers_array = .; \
-       *(.data.schedulers)           \
-       __end_schedulers_array = .;
-
 #define SCHED_OPS_ARRAY              \
        . = ALIGN(POINTER_ALIGN);     \
        __start_sched_ops_array = .;  \
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 05:08:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 05:08:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381153.1624718 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqkuj-0006JV-RV; Mon, 03 Aug 2026 05:08:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381153.1624718; Mon, 03 Aug 2026 05:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqkuj-0006JM-Oo; Mon, 03 Aug 2026 05:08:37 +0000
Received: by outflank-mailman (input) for mailman id 1381153;
 Mon, 03 Aug 2026 05:08:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqkuj-0006JC-7e
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 05:08:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqkui-00Dbdy-KR
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:08:36 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702231-bab6-0a2a0a5309dd-0a2a4502e77e-34
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:08:36 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a702218-6ca4-0a2a45020019-d1558030c85d-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:07:36 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4956869750eso9792965e9.2
 for <xen-devel@lists.xenproject.org>; Sun, 02 Aug 2026 22:07:36 -0700 (PDT)
Received: from notebook.. ([78.173.117.153]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b917efsm310345185e9.11.2026.08.02.22.07.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 02 Aug 2026 22:07:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785733656; x=1786338456; 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=V6MENfzpjRK8Go/oREv4Ua4C28lp8j5eDhquh247IHI=;
        b=i41N1IpN0Z9IJSaLvE/8GYPpXT/XvvfNg8xaQinM5VqeJSOVqNfO+EcoekSzHmOQVt
         xSseD0QqkF4Cp47yp8ExeX/kN6rpv0sElVHhNabXkqSw7BoyuCf4r7oU/z2HjsRUCJe7
         cxqryWYe4VAIWiRDiR/J1buM4MU5V7BnZ4rNY7IkrrNPUHUhfgcd04+cXL4Hd6WNw1pV
         ZWec+hQCLJHN2ORGGmoxVIVT7hT+ddecyhfrsWYbOaBkeNPOQ8oNGjVVtLZitCO/nj6X
         h3YRlMMUJPJ+szQ91DR9JnO8dLjkeJljlZ8GcvHTy1UHtAdSPB9xkiMOmdLzkpFGznzr
         qjSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785733656; x=1786338456;
        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=V6MENfzpjRK8Go/oREv4Ua4C28lp8j5eDhquh247IHI=;
        b=TOLtUlTQYR9cmjfTctILigprQJiyydl9Ix4RMkLVQKTFhL7/Cva9wAMT7ZQigInnT5
         nmvGRBtNQOZnm3O7S0/skAOX48VVzsqnsFk5n1QIE0PHN/xeGCvcmzgquLcuP1S6q6jq
         PHiTFo+xdfUJ40IyPcGPOJu+u0rH3mYS7L3K0kEzDx3bdcfscQxSSmYizs3w2SybKRVg
         Pu+SNBUfPuE6wUtY2EWP+KaspMS83fQwrJ/gvYK2eq5c7zBBW3y8FEEd1tCjsGBXsNAT
         RS9j5ArWYi3BqxkcUmEAY9lCbdjOOFAsjxk+viDH1g3yHe8/RcHZ2sY11HgCuEr0hCmO
         1I/A==
X-Gm-Message-State: AOJu0Yw5buLPzuADYNh+TI71tAUvkq9wP2QqPrbLlkRUCcRq0Z5G2m4a
	rM900uVKxUjZoI/jKy6qs/v7QwCP2d/YSYBv+94HnBeXvJ24hsO4QyuEaXUtaQ==
X-Gm-Gg: AR+sD13ioTfCJEMjRb8hkWhKhav6RM2eVVPPEMuJIOtJEwa5uPDbYw1DFmCX7nzk3O4
	Nca0SNIAVkWp+A1YT5RxXb7GwvChT9TgBUHdg+8+L1zBZCeJdnrr18h7keZ9juv3p4Ie5wDstpD
	aTVCLM1mNdpBDU0xNd3ULiAd1c2kyp0wCBBWtignRc1mhKYJwdHsfDdSe47QctuZitXd7TwgCgW
	eboz1K3sgpMkfxdj6D0Z2ma2KTClcztMmf2R4sQPXdU6x7owjkvQtxjjvAuRiN2/3+E6Kl+kAFU
	+waKzdvKLgnAQKDZatx7Ws+e433+4+Tga6ddebxJpKvoVR5xJHPb6JBZLDpK2Ib3t1GuGrHBdfx
	2OQpyqKNazOYOdE8R63XnkbIo5sq4zOO1rn/dI6vFXCps8aN9IrzwTB637neASoJg5syxw4Z86R
	W1yP4NN0Cyf449HfYpKT9hAWd1BwvrvOwsM7s/8mSvA0GaHeuaTDurFrWpL7kwyYZJJgcj463+
X-Received: by 2002:a05:600c:548d:b0:495:6134:6d61 with SMTP id 5b1f17b1804b1-4980c674de0mr196641985e9.19.1785733656026;
        Sun, 02 Aug 2026 22:07:36 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	oleksii.kurochko@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 6/7] xen/sched: null: migrate to new sched_ops
Date: Mon,  3 Aug 2026 08:06:13 +0300
Message-Id: <20260803050614.5222-7-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785733656-F1CAA2AC-CC47DECB/0/0
X-purgate-type: clean
X-purgate-size: 1283

Declare sched_null_def as a struct sched_ops instead of a struct
scheduler, dropping the .sched_data field, and register it with
REGISTER_SCHED_OPS() so it is found through sched_ops_array[]
instead of schedulers[].

This moves the null scheduler onto the new sched_ops
registration path.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/null.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched/null.c b/xen/common/sched/null.c
index 952bb47444..5194c8216c 100644
--- a/xen/common/sched/null.c
+++ b/xen/common/sched/null.c
@@ -1037,11 +1037,10 @@ static void cf_check null_dump(const struct scheduler *ops)
     spin_unlock_irqrestore(&prv->lock, flags);
 }
 
-static const struct scheduler sched_null_def = {
+static const struct sched_ops sched_null_def = {
     .name           = "null Scheduler",
     .opt_name       = "null",
     .sched_id       = XEN_SCHEDULER_NULL,
-    .sched_data     = NULL,
 
     .init           = null_init,
     .deinit         = null_deinit,
@@ -1068,4 +1067,4 @@ static const struct scheduler sched_null_def = {
     .dump_settings  = null_dump,
 };
 
-REGISTER_SCHEDULER(sched_null_def);
+REGISTER_SCHED_OPS(sched_null_def);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:01:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:01:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381175.1624745 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmfd-0003WX-0G; Mon, 03 Aug 2026 07:01:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381175.1624745; Mon, 03 Aug 2026 07:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmfc-0003WQ-TG; Mon, 03 Aug 2026 07:01:08 +0000
Received: by outflank-mailman (input) for mailman id 1381175;
 Mon, 03 Aug 2026 07:01:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wqmfa-0003Lf-VJ
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:01:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmfa-00Dx4z-Al
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:01:06 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a703ca5-2eae-0a2a0a5409dd-0a2a450cb79a-48
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:01:06 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a703cb0-f479-0a2a450c0019-94a38ff19176-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:01:06 +0200
Received: from pps.filterd (m0384717.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6733QgDQ149478
 for <xen-devel@lists.xenproject.org>; Mon, 3 Aug 2026 07:01:04 GMT
Received: from dm5pr21cu001.outbound.protection.outlook.com
 (mail-centralusazon11011051.outbound.protection.outlook.com [52.101.62.51])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4ftk39s1na-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:01:04 +0000 (GMT)
Received: from SA9P221CA0011.NAMP221.PROD.OUTLOOK.COM (2603:10b6:806:25::16)
 by LV8PR16MB5909.namprd16.prod.outlook.com (2603:10b6:408:1e9::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.17; Mon, 3 Aug
 2026 07:00:56 +0000
Received: from SN1PEPF000252A3.namprd05.prod.outlook.com
 (2603:10b6:806:25:cafe::9b) by SA9P221CA0011.outlook.office365.com
 (2603:10b6:806:25::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.223.10 via Frontend Transport; Mon, 3
 Aug 2026 07:00:56 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SN1PEPF000252A3.mail.protection.outlook.com (10.167.242.10) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.8
 via Frontend Transport; Mon, 3 Aug 2026 07:00:56 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6736OAVX3620404
 for <xen-devel@lists.xenproject.org>; Mon, 3 Aug 2026 03:00:55 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fsyuch9af-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:00:55 -0400 (EDT)
Received: from localhost ([19.12.76.221]) by cmsmtp with ESMTPSA
 id qmfMwSXbfJrM7qmfNwfg4Z; Mon, 03 Aug 2026 07:00:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=dlZ
	MsMtUd8O/k0DHPgYEcJOApxOGUU7AlcWmznVSQRk=; b=l9Ejmnvy32myzL7JYQL
	nNDSxKy4iNteJtSOZvZIDrmlM6LRdjcJ164ajuYJTdlkFBMbZdkUuokFrAJ7CbUd
	Oh7ccpWSCKLcE2hPDUmRnautalwuaxjMAgWS4w6TWRXup2CpRkyw/iLGe3FX/fj5
	NwC87HijT8z4n8D5qtmvYlTeOMouzHqc+rTszSORd50V4Kw8P2aD7g28zgzGeToi
	Rth2Dh5Z74c2NubOcaMhLiScJ721KlItO0uMuxaarTdf0pG/u1R9+YmdtjHy2xB/
	dKOQ6PMwvCBcQ1xpoTyr5Pe47KDilm3bSXttAf5U3zO7lAATo4G6lVm5z+uXy4mr
	1Uw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=H+c+IdYWAjKx16L3JnxhYktEPqSXgYX4bwvKb5LCN74wtCtvqU4WGUvcjKEGmgxtb5FBzsm9ERPiLByFdk9XWnejbqHztdTfagk3fFKe/OQ394Hux8NQyBq6lY2BLX6PfAFJampJ1r8PstCrbKNeAOpkILhw59TYsqMI+UZm6tEcJbpxSRGNn1iWh5cI6lXRMx06QRZn+8hIV+YYwO9/v3P1I3FjWuVK3Ak8ixSJPJpRVZvI/nQcR74ES/DFTVwO7ihanay8o844zL8ozzrmSWPfP1sdi6toUQ/JYhFgeXgt8xcpCrSJPPzy14wi2vvprXSVG5/dVb+sbBjbb4tXAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dlZMsMtUd8O/k0DHPgYEcJOApxOGUU7AlcWmznVSQRk=;
 b=QY4CCa/feMtP83h5EbfInZmQDjWin+9DhLtUgEMWSZzhCqPvyQS3tYSCk9l8a0B96HXHDxv3rTJhfN7Gh6DNFf7GSjwScHUTnScNkNxwH53wQsXErJhaarDy0E3YWlQJ46xVwoydpUKVbgw9roNWyF89lLlwHbK6PStIFJ09AOrP0KUhWUPTTQnPS249YBHX6xyEztmB+3n4gIX6ycdkoQuv9+WelvH+/NCEYOYj2Pu3mHinVkqvQGg2Ok7tTkNUBRk+3ZKynBq+xwuIrFAo+icXIpdVjWb7U5twzDKlBX5vQNBio3tnjhUeVcm3GnHFi3JLIPT+Kv1YmyOKpxIbPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dlZMsMtUd8O/k0DHPgYEcJOApxOGUU7AlcWmznVSQRk=;
 b=PQVr/tF7IWf/jLJbNSjNrE6j90QZW/hQcFTyHH40CUcBzcp8+RFwbTHncoyWulee+Gwh9Yu9EULpxCH3rTMavzAEd6Y1Ojcxb6t8dOwVe+9tDhPpnwId1BkjQC8fnMTUW56vGzP0rxSXYS/K4Qavl7ZsyLrhJvhQ7gSPWmu+03c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:in-reply-to:message-id:mime-version:references:subject:to; s=
	ppserprodsaar; bh=dlZMsMtUd8O/k0DHPgYEcJOApxOGUU7AlcWmznVSQRk=; b=
	AoLbcI7ROBr3tWuDESzxC8wCnrPWm/3VOivZenSqhvgtLgfCuADy3vFGC/kN8E7l
	UVLH4dbMbrmjwrzfppm/RFf8JSNDAdJ6Zceb+5J/hHWA/2GMSQNxy7c/8xApvVky
	kPrs3otByXZyhvS3xA4gMIDw7oNh2fjwJ7qmBy3M3xssKgZvCOBHuu9PYZMGeHKx
	dLK80Wp796nhghwVpPOXK4zFCbmigwHKd9Z4LUkK47xPhExvlzQch+ON6P4gqdt1
	300tSzZdtEHqnIv5/7rqUlJGcJ6AYaJJRkSAVlNajs+iE1hG49OKpHuMqICKGT5R
	LQlx9KZs+0CqnxtLkidSmQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=ppfserpocford; bh=dlZMsMt
	Ud8O/k0DHPgYEcJOApxOGUU7AlcWmznVSQRk=; b=pU2dHdnKv3d+j6pxCJ5HxFY
	FqeNt/YBPTpl9j/e2lO0zqIeR3n6hg22nNaJI/WX5ZcMhVZUD3rd0t4ATSEEWBNz
	woCg4SueWH/76msf4noJhZTHBY9RkpQKnWOegi9XazklHc8FCUxxBTdHoJokXCQD
	PitXHlgu7ZuMfwbwQgdxP5tprj3bsrn7GoNghFbi3gCkf2B0bGADsMfXArZRmdj/
	CJMVyZ7WHMEsOXJGHlDXh+Kf+gChDn5N2Okevn/GOhZUSGgY15wU2sb5AyaxV9/O
	onmNQIc/t9WkRF+mMJqqPLvdSMcHKrHM/29Dk0Yh7ptn6QTp+HAjRbCwCojX23A=
	=
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: qmfMwSXbfJrM7qmfNwfg4Z
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 1/2] xen/common: annotate saved_cmdline with __ro_after_init
Date: Mon,  3 Aug 2026 00:00:46 -0700
Message-ID: <20260803070047.3097846-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260803070047.3097846-1-dmukhin@ford.com>
References: <20260803070047.3097846-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-02_06,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 phishscore=0 adultscore=0 lowpriorityscore=0 spamscore=0 suspectscore=0
 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound
 adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608030060
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A3:EE_|LV8PR16MB5909:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 825b73d9-e5c0-4f17-eb24-08def12cf75e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700016|82310400026|23010399003|22082099003|18002099003|6133799003|10067099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	43+gtYv8ZGfgHWK6sPhM5Ck2V+wGDsyYWmiaK1LQJLccCPgR0KIs6hahnIqtXszGQSrtTH57dEGssvl2atdan6M+5KtK/7pmRi5Z189kKwjPwVmwLiaYpmwRAAtpqirSaOeix5TgDnw9DROkyuv+yS1MyH5I6nYD7qvUypmBXufOfn9w6rXNIPchgWtkiaUsGpu6W2Q03lz2rviqdHDvuNhedOIc/T6eYDJDNi9kQ/8itVW5fefy45pdViL7eOtvUtGLgMH62Tidhd/jrGJAYEwRt0GS7QPLtmh3eYp81E18IyjQVVikd27Jc+YXJS009WiHscHSF4LN1vahyUt73qqiNOyhl8eKKhep3EXqnTivuaBpohlET3J37W/wGYeOVtt4DSeNxZocOBKpJHSs1ibfOfOs9yi5PhZct1kJtK3mnItOPbbbDr+CYBsKcVBKPmJ8bUnCZwxrhGW85O9370wdvdQhF0mzNzb27JY//jh59UnurXj55+7gYw03wror0LUCUqtu+jiIHhLhIx9NENQYqk45/7YyfoAG0JHYD+xql4TA+JNGWN/riu2ROuoBm/c7EQtCk540VcGYjJ+QuXtv9uraW1mKZ1yJOzYkiy8JmOFuiRJmSoXnGWWMQtjhqr63HXmE4uyChyu+eBfYxuuFzYj2XGoO3zy34/Yszrp2oZGZ0fheabzESVlLzY689e2HYwtqanGl+eSECOTFkw==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700016)(82310400026)(23010399003)(22082099003)(18002099003)(6133799003)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	CBDoDr/LahqAqadldgtjIrGrexhjkBehQw7Zv1zmA3EPaGA61Zx4oMyxbtYwqSIB3zRE5LMJw63hGHyGavLFcl5NDeOU2v2V0xnLlSDlTrCFAFkQnl6QFg91AZHrCPU003norlf0dq/ulc2sAhWgh9SjbbUo6jTGUYQQ/kaqZaorqUy0oviwydIRqS3HMHP7BR4OYysPPFrkwctlrzEiLM+ykarqUiu5gOJtHjGBP824p6qzzBwDxDVkMwHikiSqnTvn/8LArnBZ37Qhn3nny4VrGy2dk1XxeqPT5K14Qgbp3slaadi04h7EogdhyUbwbiG3wlk10SFN7i2zX3J80OTycCrcEd7l1Qn1TsgJXTDiVCXWhpSF7kqnb39unIVkfv6pXZ5J4gi+5BOmrDoKQkePFcBV8YRfE2wuMaoJqFnOPQWISqtuQcfELriW8nzn
X-Exchange-RoutingPolicyChecked:
	qpUYF49fGlPh3fEyP5XAcUW9Wrau1rXP89G15qqKALdGD6gmAJG0yAgJRuA0B7QgKxGeX8gXv7kSx6cPN/s4pQzTkKqc5ULk78QxoAQrZAcEs2ANqKqQIwPqvRezCCUVNXfgYEr+uJ+zgERHxxJZH17l2cTJrKGwaxe1cLF+7M0K8n2J8OEM4rby+e0g3boXgI0OC4Y1g8GsmEIEQ+wUGX3rGoTRe4oIGvONk6NtpfIbFcXrDpd3Shuefoy9hEraNqj2jctgRl2aevdmjF2z+4AGNXBI50NlwlVpyHuVknEExa0BxwmJTdDyi7q4NMNhVIAwJwRjTlNpP1Z4mw5hhw==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	/yyqXSja/+MdHqdwABC3LLhHN8KMiQascLVGao0vTuwBJDHn2agkLTPVH2Cx/NkGzyIEeEmt7Xb3woXok/Km0ZlmhWEbYz6K9hBVFeIZBh9+0mhhYyYDNKAk47h7IyzAygRxbuwUP3+jR+tSf5c9gIMrrO+dDFwEDZpojJUiBo44/s/Gd8oPsMQPNOYPhGIV25V0E7uvEPAr7iwTYqtKt42mndfBIidK22j5oB0Dho2UtbQE2ntXumZxWtk6XK4G/awLZLnn0c9/ewzSRk9LI/1y/8Q0ErS8wY7x10z6K62yV9oSguODAuZutj0xEerYeyEUttZYj5Rj1+M62rN3COCL1ph/YUldLRjy/rtn1q9UumZrRBd6yan+IdQZk7XEgQxZVFC+Rd4wEogmhHlpd0iNAqfXVhef13Gf+4b3REp0+5Fm06+3m6jxHMq59CI5q7NyEYlz22APGWwmHpomceu2Uh4sKrps84Ao/In7/0ZY7NKZ6QqBSlHueMEkC06CMDuxBrzt65gO/TR4w4Hkob8o11lx/51Ip0mZB/LBg7dZN9sIatqjZdxroTIiLt/BdKOzvZRxLrd9hjJRWrYGHcon3pYsYk+T9lhiSOpW5/wZHEcZ3s/efr+acwab5x0g
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 07:00:56.2117
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 825b73d9-e5c0-4f17-eb24-08def12cf75e
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A3.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR16MB5909
X-Proofpoint-GUID: pvtjZgQwcI_eWl9TBq7J50Wys0Ft6DPv
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODAzMDA2MCBTYWx0ZWRfX2ExiIPB5yj91
 vlGuMp0GCiKpZWCoFx9yRvwk+TXBgwH6pxGgj7RpIgn5392V6pggkuWEe27xQR4FLUIqmyoIK52
 MsXoY5Vi/BjagaWaxHFTk8Pyfbg2FlL3PJxi87arPK6PNO1fF2a1XMPKu4pcimG/HoJaFJfH0Iz
 igM1MwHvspTVcRaW5ii8MwoOl7fsi702PAwoejPpQaQI7+ZxQuXHg2R5cBYHSjAPbOqonY1sBYq
 cL2NU6ByGtW13a6k9i35Ca6g8exIolVhBVM2ubR5kpkkUWZerx2mQIO5ijRWK4/d6/wMeddmE/J
 w+ZpPJrOQFYl7xQR7i3fUj5IZCDb2fXxqFy/WWKSgmm3UWFxzKZw7Sl+riW+YPVtBmb17pvnc/X
 LUfvRVmhVaQ7sFhm/sw/qe6B6F9Yvvto9jGLAS1KcKH+h149VBzVXrkFHmCgDXYPgiIz1xDMX3N
 noUDGbkyohNVBTOAukw==
X-Proofpoint-ORIG-GUID: pvtjZgQwcI_eWl9TBq7J50Wys0Ft6DPv
X-Proofpoint-Spam-Info: AW1haW4tMjYwODAzMDA2MCBTYWx0ZWRfX0M1M0ZaywzAl
 RTIBj8mmEjjmsfgqbweY1y+OKXU4VchlsbdUm4KKC8R3ZD45s412n9/fv8DfeivJTc+Mr6euQDS
 jqVkyhQTSWkKwReYZXg0cyOHAmV2X1EZHgG5dp/TinqHcBPdVbf+
X-Authority-Analysis: v=2.4 cv=doPrzVg4 c=1 sm=1 tr=0 ts=6a703cb0 cx=c_pps
 a=qX5DP9EEIf1faxnBSU0rOg==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=AHe91QgOk3R4nFVtG5At:22 a=cbNQJ9GKAAAA:8
 a=iox4zFpeAAAA:8 a=SOBqYn4TATFuCMYqiXgA:9 a=DqJYxgmhk6moR-_7_KoZ:22
 a=WzC6qhA0u3u7Ye7llzcV:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-02_06,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 impostorscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0
 adultscore=0 suspectscore=0 bulkscore=0 clxscore=1015 phishscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608030060
X-purgate-ID: tlsNG-d25034/1785740466-76EDAA5B-3175B481/0/0
X-purgate-type: clean
X-purgate-size: 942

From: Denis Mukhin <dmukhin@ford.com> 

The hypervisor command line is not modified after initialization.
Annotate saved_cmdline with __ro_after_init to place it in the
dedicated read-only-after-init section.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v1:
- new patch
---
 xen/common/kernel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index fb45f8139995..d1bef9ac2b2b 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -34,7 +34,7 @@ bool __ro_after_init opt_dit = IS_ENABLED(CONFIG_DIT_DEFAULT);
 boolean_param("dit", opt_dit);
 #endif
 
-static xen_commandline_t saved_cmdline;
+static xen_commandline_t __ro_after_init saved_cmdline;
 static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
 char __ro_after_init xen_cap_info[128];
 
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:01:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:01:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381173.1624728 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmfV-00033O-Fp; Mon, 03 Aug 2026 07:01:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381173.1624728; Mon, 03 Aug 2026 07:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmfV-00033H-AH; Mon, 03 Aug 2026 07:01:01 +0000
Received: by outflank-mailman (input) for mailman id 1381173;
 Mon, 03 Aug 2026 07:01:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wqmfT-00033B-UE
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:01:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmfS-00Dx1a-QZ
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:00:58 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a703caa-2eae-0a2a0a5409dd-0a2a450adc84-0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:00:58 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a703ca9-f2d2-0a2a450a0019-94a38ff133c2-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:00:58 +0200
Received: from pps.filterd (m0384717.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6733QXrI149205
 for <xen-devel@lists.xenproject.org>; Mon, 3 Aug 2026 07:00:57 GMT
Received: from sn4pr0501cu005.outbound.protection.outlook.com
 (mail-southcentralusazon11011054.outbound.protection.outlook.com
 [40.93.194.54])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4ftk39s1kx-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:00:56 +0000 (GMT)
Received: from SJ0PR05CA0088.namprd05.prod.outlook.com (2603:10b6:a03:332::33)
 by BLAPR16MB3841.namprd16.prod.outlook.com (2603:10b6:208:273::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.245.11; Mon, 3 Aug
 2026 07:00:53 +0000
Received: from SJ5PEPF00000209.namprd05.prod.outlook.com
 (2603:10b6:a03:332:cafe::1c) by SJ0PR05CA0088.outlook.office365.com
 (2603:10b6:a03:332::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.15 via Frontend Transport; Mon, 3
 Aug 2026 07:00:52 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 SJ5PEPF00000209.mail.protection.outlook.com (10.167.244.42) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.8
 via Frontend Transport; Mon, 3 Aug 2026 07:00:52 +0000
Received: from pps.filterd (m0373460.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6736LXdY2591096
 for <xen-devel@lists.xenproject.org>; Mon, 3 Aug 2026 03:00:52 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [34.209.42.160])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4ft1nxh7qg-32
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:00:51 -0400 (EDT)
Received: from localhost ([19.12.76.221]) by cmsmtp with ESMTPSA
 id qmfJwsqcfRF75qmfKwf87h; Mon, 03 Aug 2026 07:00:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=637qawqkKAH9vcNugWaXYQ4sA
	GQBt8YEUgWFoGQ/vj0=; b=qMnSivLpmkhYDuJeVtC3MCiryoFEoDpkmcUUJ5Pb8
	X+lYoE80E5albeoEcF1qBrTwtNAQLypYK9g15oqa6XxKu2r0Xbgnn6h+XpibwHBl
	4hYgZ1lejTbFETQPQ+zqlHnqMRlm5C/zlIiHS3+DMeE/13zlfpfKuAns2Uzs/3SZ
	iKullN9I+Mt2zeRRhURZ6Zpt5im/cQkqTTRjWj8rJyv65PTazjYIcKJFQjq6Oovk
	NQ0aOCpspD7F/xRvOO05eBUu8eTuGDCiFQl34RsW5ZghhetVUeF4Bgr8Ae85Tb7h
	C4e/NPN37BQYVFTOMeI43h5Q1pBD154hGn640e1YxXiww==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LWz2JGHfO8Ch4PUezlPkNu8kcyAj7DiwwSFA5zDRQdVtHPOdo7q9RhCZ4h2keAwU/HgFQiBG0aqwPobBa/zW3tsfYutHy2Nbz8vdeVL8o62WaVKWyJ2vgduCDHsSt9X0eaLxzlsbLYuhWgj/9jFAN+uGkTCo2Sn8ewruVLDmL8aA1EYqI5KRCuWJ9hr0Nu57faDMPArfMb2yvsGmyOyY6TohCGc4TkqCZM3hAdBObn2LA4lZmCSq020g06vg8aHCAkeSUIg+KIVYDe12H5FNJagEuoDCHEqfpdbHPHpvH4J4jomtuLBQflmDo/JuKmMa8Y9BjuNW4BXRkpPl+wkZIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=637qawqkKAH9vcNugWaXYQ4sAGQBt8YEUgWFoGQ/vj0=;
 b=VTr64Or6ziZvxdfHLdiAuro/t15yEAH/yexB5cu9OfBO9lc1xK3a/aDQBEb5aSDT7L6XfbFIx81gtwYqNcRxzvjurm1W1jS7MMP5je5JFsFFEZy+qfJ68BfMznNccA1QC8A+JLTmwinLVR5RmdyJLYJhPrVPx7UOWnsm1Ds7mHB/KIB+1jMTnwEFbV4cLXBLOv94rEGY8eTYw1m6mc3l8Hs6dcmLUEpEu9FEVS9nbU/Cvxny/ECKQfPvI4YOvj8l5DBgg2FKU5X7mVBxVlJ9jcr91JT9U99OV1UwhozvWY0t5A13ohlSAyCUVu67TNcmsMndGo3Ttsuf+0nuyNsdWg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=637qawqkKAH9vcNugWaXYQ4sAGQBt8YEUgWFoGQ/vj0=;
 b=VKgg6OQZ0FepEyu0Wmy0yD9Lnn8Mv5HnEJ7Ggnh13cuXynTJX76IoLKJy37jIyaGglWWCw951p7H9Ky90uk1BrIkJgO/B1y9pux/Xyr/34qoKdIdIrLt76UW98LbJeZT3iwZV3ZgdAhGdrCL1cDMkwLAdRqJC3Blta0atiChPRs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=637qawq
	kKAH9vcNugWaXYQ4sAGQBt8YEUgWFoGQ/vj0=; b=QEb/6HrS3F/91wV1tyGLW7z
	kxGwSUq2LYtN4ozp8tTpRRJ4aycbRTjPQkntHN6ht7POhLA7NiEQkErDovJ6v2iV
	MejAOobu9GC2CARydr6Q67edVS9wxvD717HA9aMwUGSRgxB9nqJtgk5OOw5Nq8Ab
	XqV91BgJVusHonmENFYyY2UrhME/VO2vqmwpWVWpZWaiYmjnFLqEQjzBjfKzc9bH
	O7LPnL5+CTKLj5vxzNzZm4EPQQAuy8ml6QwHDJuyrJsPVgb4OZ4mdenW66NGcwZq
	JxT7Qbw72ZKlpCvRrD5W/4WehGAWP5ECkZ0lwUViQ+ehJRX/JuTGFfqUJqjftJg=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=637qawqkKAH9vcNugWaXYQ4sAGQBt8Y
	EUgWFoGQ/vj0=; b=MH/V7hm1Zpwy6YelsOGX0bznw8yN54ZqYTUcq+KwVxR93k8
	cqIVMZnxrmNJgKCYHqYCvyEQKAnJCRhDAYA5y1pS2eGZhWQCz2K0n61juVeG8R/r
	gGVCarTSum9ill0rUWQLe/1dSvSyctyo8jzbxueapO8TB781tkqBL50cF5k//RRY
	8lkcP55Lxaj1sTqt+cv1x0O3d+i2FwjtmzITD7X7LKWRb+X/hAdjrJLo1dAHHTBn
	Oqu4Fb5vpAW5y5dSLPS3tUqU3FLxTUIjmfOPiElhmpiy49s3bd5r2moAefua3GTB
	7OKre2CVKsH6TtKLqMfulHDzU83NwCMu756sOFA==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: qmfJwsqcfRF75qmfKwf87h
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 0/2] keyhandler to show Xen command line
Date: Mon,  3 Aug 2026 00:00:45 -0700
Message-ID: <20260803070047.3097846-1-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-02_06,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 bulkscore=0 adultscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0
 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608030060
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF00000209:EE_|BLAPR16MB3841:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 54a73456-2eab-4627-333d-08def12cf4f6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|23010399003|376014|36860700016|56012099006|11063799006|10067099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	sU0HEe6X2AcWxJgu2JgvLTZKpfyrhBmbsfmLj34c/W6NVBSpW44PlfuQkP2dYeKbFXJ8KhYqWPB3D+Em04rEsn84XvFWSK3KWRAB3+JZyiYNDSe07BEy1SRB4jWUF9d+a4Sbjb0Ztm/JR/xSUXWRD6a2nMOhtCYNW/iTVCoFCW5RwGBma7A1M/dGQijhbHahWn8dVij10M/MQgEWxh/urXzH0vDZs+30roZMR+Ej7dtoRKcVzJZXrfR3Y9dSu/zrVQoVdCX3RSYaaTP/Ka/J9yTCigOQWbXRsjvNiPMAvX0Va7j3WOx59Uy9+Lbu12ZKXCGTehM/9Xk1Dpi8l0HHWXOwjFyj0rIImTDfa0B+bU5V9bG+BuKUIAMMElWCoSeat1mQGqQtWPK2UScZJrdmeoenU/cXYV0CzNcCV6FkjDqNK/ODNokAc6xU2OD98XG0PGOPRyQJQKn/F+85YyXvL9/QLEBWQtkiOtc0hKor3oESLPVfy8fp/SN35JrIe3E9xsVuwsn7tFr86jNIZ+4VhB17D/njK4SUTUs/omYvxl3dQ27QyGGL34oOV72hLu1W7z62K4aJdKxegmOfsrxkhvB9bshGRarNppG03bcni+/0XaqUaJfObLd+9yqID71eilUcAwQPtvfjhELzd8yME71qv1zaiBr0gPkCEO8ymlTfJoETENEEP8NHj7uuZ2VzvjjHzrhxBUUSRMzJpXW8DQ==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(23010399003)(376014)(36860700016)(56012099006)(11063799006)(10067099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	kG0WTJ1Kbk+sHDq+xXUFc7Eyqj8LddjDgg487DMaqgJTmalkyTPhwnKta2CQrRbaEwRYXx13JfBxj9JsJ8OiN/O+DGJ9Lul5hDyjTqd6T+Q+iJn594A/RdPT7dO3wMXlAisE0YnzTYERUJZxA6w8Y0Gg0xIepvuCgoYwiCuGEqv1M/5faC/mmbYSMLUSZq4fuEuZOkOz2GYaAoJSAM9bq/NSONa63CQMftN+q4yw6YUZDDgpKYttLulhq8R/LWPXZP6kVhsrK/98QYCdgrY71J76ACKncw/ifXdb/MApkDOscrjLcPyF3VCRL+FgSBbNNdiH9BBpYgM76cczvFs/NL51xruiHOUOYEMx2bBgkTQi2tuDDasz603yFEfJGH0y65HvEecKatX2cYU5b1lplNNHwFni7Q6ZC/+I3+DkVKcLsUtnOs69lRAY0ZCjLPvy
X-Exchange-RoutingPolicyChecked:
	d7YCDhtlYw58/DBF8AvJ9H5GxXUVKvU9G2e0mD/JB0wfbnuk+yPXxziTAxkq9qSB+jZKFFANe750TGvzJS8rIkOpllCrgSTw5ojbr7cG1COpotiBalCk8byG55w3BssWlGZjvawjKmdWN+TqXY5PUQGYDpHSvGnMkuupU9NHwXEYpwLCSu0ZVvRaZv4/pIwHxrqgGOTftRqB2M151epclYlQFn6Dca7DBzYM7O+qgQwtgaRBux8syG5PdXApVZs+JM+VJtcOXck/yJZ0szp+bwur2kcWd/84Wz/Un/ZYdZ/I54mIvftq9uZtm3QyLjDAKcFgC6U/VlVK2nwAzvPiaQ==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	Z1SFw6rNL/S/uQ2IjjYv4d3xL5U90U9eZv/LdKf9H3cR+NNiOsb2SOrZa7n2Ap5xnRXgbJEkD/krlURBRjiBsyT3tQXEP7+xtAx+O0aIcR4vR8npPEEryWPdprh9TfF2c1IYCUYIUiz9JhUtjaSUH2MzsugxkdKL9X8Njoszbf2opLm+BwNQvW7Xs/VwBAt3hKcBo0Hpfj9JQyuxs5tLd9YEbk4e7c8bhbjSKsI5yDSOUxgRdtR67Rk6Mal5n24W1GqZMD7Is6yzj9t9FfJkuAeoioswoApr5V+44jhLx1MKqwr6vOVEbuuo1/w/MIx1IdkBl69rpJnCxih7lIYcsPTYCjhzreZ9mS9LCkDfBqtQGX3y7YeScdn87C6tNYUCBXVcm81oBOnoknGBNKMk4UkAPJO6h5A/ad8zGWeK+OcKookY5/flfDV2SdiTogD8qcpKi60I3BdRO1G4pkJefoSJ0I02op3TuLAwLvEeRmsCb66Da0nvGK53oDvmUeX2nbKUIh1KoDRAjgGqp5s1zlDUlhfZy6rwAlbQhabqV1xW45JSDn3w//y9oQs5IUCXPimFeVK8lgLhobZYwV3B6iu2fuqtw1a9szSBdEWAuWzCifb9fuMuqFkPDYTudxel
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 07:00:52.2902
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 54a73456-2eab-4627-333d-08def12cf4f6
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF00000209.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR16MB3841
X-Proofpoint-GUID: MJKzfB-LFmGf4YebNhJXxBzE8pdONy7D
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODAzMDA2MCBTYWx0ZWRfX2YAVF98R3+s0
 TUSHxVZsuMCAfKHW6jNkRwofe5NnDjkDAlXLf/Z6ufFn5Ck0ri+0laY/BqtF27iJ3Rw5C+XR/yK
 LgfLd0ykOpD7eTV3rQcgYrEDjdP+UBWSNbduuNRveodDiuH5tVwUPkLAqjGmTPxU6siwlmHinzc
 S9lLEvVkidjmywH1xnVHI5fVBj6qZK3W+VkwWbOLFTON2WmAQrGiBSHWNDxr76fRuDihXtzJBTm
 57sdW86PZEe2IxX01CocymsqGiTu68vbvfRsQE/QKwD0PkZis2mlmbjJ8qqIn+z5elLO8WcqtGX
 +sVYdFBEyGCb+AEH7ieOqd80OF4q3DJJFnP1njtr53sQqQJCVBIpzj7IdySCmx29Sm0tNrLW0Ff
 RPd3PEqM+pyIpXsoVaLj+vcBtImTzaBJ4SdIG7V1NwmjKZm/mfDpK9j0StcFhm/yH1vW6F/6tZL
 cP0gmOWp4kQAhMiye8Q==
X-Proofpoint-ORIG-GUID: MJKzfB-LFmGf4YebNhJXxBzE8pdONy7D
X-Proofpoint-Spam-Info: AW1haW4tMjYwODAzMDA2MCBTYWx0ZWRfX158QcP5YM1Zq
 62lZdoM8UVyzklKqXrqL/0cMympt531OeGeGMD0MIfPYHzHgN+InD7kRek6W/B190m+WnOLfHea
 H07xRLr7I5qVfDsfYzKmQMLdL9ad00yN8ubmcRjzNVVP45zst6yO
X-Authority-Analysis: v=2.4 cv=doPrzVg4 c=1 sm=1 tr=0 ts=6a703ca8 cx=c_pps
 a=cVuenkWoTzwZy9czxFkdkA==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=AHe91QgOk3R4nFVtG5At:22 a=p0WdMEafAAAA:8
 a=Xf6Qf7mQbR-3ao5nFTAA:9 a=P0bj-C3X3jJDpopQwM1U:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-02_06,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 impostorscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0
 adultscore=0 suspectscore=0 bulkscore=0 clxscore=1015 phishscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608030060
X-purgate-ID: tlsNG-4011c0/1785740458-518C5CFC-B72DB72C/0/0
X-purgate-type: clean
X-purgate-size: 429

Tiny series which adds new 'X' keyhandler to show Xen command
line to help debugging the system.

CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2723312941

Denis Mukhin (2):
  xen/common: annotate saved_cmdline with __ro_after_init
  xen/common: add keyhandler to show Xen command line

 xen/common/kernel.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:01:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:01:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381174.1624737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmfa-0003Iz-Lm; Mon, 03 Aug 2026 07:01:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381174.1624737; Mon, 03 Aug 2026 07:01:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmfa-0003Is-I7; Mon, 03 Aug 2026 07:01:06 +0000
Received: by outflank-mailman (input) for mailman id 1381174;
 Mon, 03 Aug 2026 07:01:05 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wqmfZ-0003Ic-EB
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:01:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmfY-00A7ql-Qq
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:01:04 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a703caa-e002-0a2a0a5209dd-0a2a4503be26-28
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:01:04 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a703caf-fae8-0a2a45030019-94a392174b60-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:01:04 +0200
Received: from pps.filterd (m0367123.ppops.net [127.0.0.1])
 by mx0a-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6736XQ1h3932701
 for <xen-devel@lists.xenproject.org>; Mon, 3 Aug 2026 07:01:02 GMT
Received: from mw6pr02cu001.outbound.protection.outlook.com
 (mail-westus2azon11012012.outbound.protection.outlook.com [52.101.48.12])
 by mx0a-00498f03.pphosted.com (PPS) with ESMTPS id 4fswuhw3xk-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:01:02 +0000 (GMT)
Received: from CH2PR11CA0030.namprd11.prod.outlook.com (2603:10b6:610:54::40)
 by IA0PR16MB5548.namprd16.prod.outlook.com (2603:10b6:208:493::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.17; Mon, 3 Aug
 2026 07:00:59 +0000
Received: from DS3PEPF000099DB.namprd04.prod.outlook.com
 (2603:10b6:610:54:cafe::e) by CH2PR11CA0030.outlook.office365.com
 (2603:10b6:610:54::40) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.270.18 via Frontend Transport; Mon, 3
 Aug 2026 07:00:59 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 DS3PEPF000099DB.mail.protection.outlook.com (10.167.17.197) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.8
 via Frontend Transport; Mon, 3 Aug 2026 07:00:58 +0000
Received: from pps.filterd (m0426315.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6736xJfM3670003
 for <xen-devel@lists.xenproject.org>; Mon, 3 Aug 2026 03:00:58 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4ft2pt14kv-2
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:00:57 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id qmfPwSXo1JrM7qmfPwfgOJ; Mon, 03 Aug 2026 07:00:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=vzj
	SlYxWBpGdDqVv+pIg3kuEssbNQ05qwEZxS4CT5kE=; b=OHMoeNqraqd7gRDrOY/
	hxnKpNCBlqzMbxHTCg7nx8WZisTuddCc/mUOkzCqVIhhKeGyG0dgl48pPQSBJrdJ
	1uO6kKT8JMr4DzNBdAYjfQdWkmDoajU+UAIZjUNV3kJF4ETX04ocgn/5imcNcpsv
	XKoQ+S88Ok051ZsWaEobTHa4h0kr3hld2HBvJyRfRNeVnxIxbzsgJQxoy+NU67x+
	O1opqEUSnIF43zv9uAMdjoS/z0u5Y6p5+mwNLIU6DhOV+J+KWD5PIW1tSmsxIJ5V
	X5B3LLDlOPXDT4rXaYOKv3GxLUJl+q7UbBvqudfiNUZhYtl1lq+3AOfnyHTbyMWB
	/Jg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GUIo7bdY1qQ6YbZCsZDxT97QMhOqYo1bj9krhD9KGh0I2AZ1F1PTqSAQwpAOQ/9F5lJTP1cDTQOhCdb2fA4xlnxdQLRSXhcfn3OJ0d4BIJkNvAXXAQ1CX/oO6awOL5nFMOB0X9UhxNAOpNCuTcO5SR5wFrsrSPxKevmdXfKpGavH71RilHBzCkVdwCuAREINfaJslyFGUaRic9xnsfqjqo5eMCHrcT8/DbjEL1Z8VfwbYi3vK+4kE+UA7xAKK0h60JWrlbJ0YZlG16s5JOTiZr/f0j+5WITiAd2khiItL7zuQQAqpBpfNDmXVYkFLS8aUs4Q2DK4BBQDO4vdTfuSFw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vzjSlYxWBpGdDqVv+pIg3kuEssbNQ05qwEZxS4CT5kE=;
 b=hfXziwWO6rJx8Vnujfghd8Fqqr3+XnPN2jd3F7RVlB0tQ1CkdeZYSe4ZMruHbCho3U5MDRxQWnSPzAu6hzdpXm5xTe8lJzljD0uctuG2xDLFLIyopXPGVDh+jNlGVjdWOOryYV1kDfMNTYRjwy2t/Yfi6F8+dEX3KzuTPgBVX+FxRccU/on4pG4HSwyg/sKkKZb4Y++GWjWE1arviU1UGgchnRPEn3seqdZyfDWrdbT8fQlBvapbG/fZI3lFckx3/Y3JPTicMw+uxIthcta7YB0tfzdPiCY65SAAYT4rKDhy9audRN5EJFNA6x9k/Ogi1Hqqrk7E/M7ca0ESNlrd6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vzjSlYxWBpGdDqVv+pIg3kuEssbNQ05qwEZxS4CT5kE=;
 b=DvYPBylp+/VmyURyxRA0CfuiuGfvDVj3rTDwbBM6JSJpF4UPVgk/9/DaIUHL1Qb3ahdQqmc3J7T4IjvYBZufEiFNnGdk9SiMZC/E6hvMY09mzo8TCF4oO/y3zaOMkmTWshCxa4Z5Feq1tDugKhjpGQOsg40HtBxGCjs4SN9VAAU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:in-reply-to:message-id:mime-version:references:subject:to; s=
	ppserprodsaar; bh=vzjSlYxWBpGdDqVv+pIg3kuEssbNQ05qwEZxS4CT5kE=; b=
	B8d03+LmESuJ0GwIXspIFyq5kuqgY712rNetCPjKqvMRZWLVziUbiAaYD24z+HzG
	zndul9XuXKoC+mOh3wDcaxOmXvlQGFXCL9GuRjd8p1sVXtXRMCRFeVfY20UweLFD
	MSAX9+97hF+goyqHr+FwhovQnActH66hvm4jlt09yEQ2vbuDx03qwRXVi8D+Rmtv
	cUXzOr3WoRfL7QQYczFGUkdLyitZGLWshzY4VMyYIodOzGkWDVHXcs74g94ojq7z
	ouD9v7wpwAZy01San1XAya7FaM4Ln2PlYjljYQrtE9fSvqaDx1DY7Z2Wlo+BuRRK
	OYpLYaNUTKP41MdQirwyEg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=ppfserpocford; bh=vzjSlYx
	WBpGdDqVv+pIg3kuEssbNQ05qwEZxS4CT5kE=; b=eTsLJq/kLbM4E9hrm5eq+09
	q9osCTtjIN2pxRfQtiRNazGYUvZMnzufkk2WvZxzGoycOqIlJ15gqb2Oi+bbDxiq
	tvly12/sGQXp5ZmA4Aw6CqTvXhmWTUlzDHyam2uAPLRPZ4ykDGUI71K7miOJEo0f
	Df0MdR7vDzju0Ys9UvzVGGnrsGpbcg8KfRz3rhW9+d97kRpTRdOtkoqeeTXSrbtU
	0p4lssNih7ePFSTgb46vqnEBm036SwLNs2JlgqLpjG3Ae/Mf9jDtZmjeOww5VUQh
	HTNKFtlTuXGqqMx48ufW3o/F/SJwZlStYIS2fzmoszJSv05grD0fvAxnqrmw5bQ=
	=
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: qmfPwSXo1JrM7qmfPwfgOJ
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v2 2/2] xen/common: add keyhandler to show Xen command line
Date: Mon,  3 Aug 2026 00:00:47 -0700
Message-ID: <20260803070047.3097846-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260803070047.3097846-1-dmukhin@ford.com>
References: <20260803070047.3097846-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-02_06,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 adultscore=0
 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608030060
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099DB:EE_|IA0PR16MB5548:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: ecedcf11-c9e6-481c-0823-08def12cf8f0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|36860700016|376014|1800799024|82310400026|10067099003|11063799006|56012099006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	TzGJhZT0cGIVequW9NT2Lhf7qdE41ImTRKgT5boIV9tAG8sYu0MdePzqYs19FGfYyVa6AYZO2haZXP78Sa5yVt3FNTYqYzhmvGrvYgVYzNTjSqj+59IoW1/EOQ/QUZVgVTjKpjnwy40F3OO4555hJXUBjUVtCoITbv3Rnq1nRhaDtyqtIt6SqtcVax1nOugvpD/FPnEMB2vwvdLqY2bCzNAIs8YSu783FgRsdVZs6IFZg5tMBu5lQv4Cxa9LSKPl8L9rhT6Rov3Ass2QgFuG268XIEC9NpwwjCk5P/vhAfBKYogjW8gLJl3gsRAJskcvSyGYV9EK8YyM8PId0pDxlKJOgSqgAjeFjrOPipyQsZDyQyfVD6+DD92YfLHEBaAVieJYH5qlr0GtCoiWYIbbB0AMtX/5j/VoBm+R2kQtNWzSwSxy88Q9U3MDuxDKkp03h4xp6CYk2niC18v1i7KFjA1D+sSbD6UtvPYsKmrDSeNznQpEv9QE4KduyUMhQYx2GSAiNHhYf4l1gNSIreB369Fv9bA/aCwivWHzSZ87JhBB2g71wywY1XI/4WH+OGGO/a/mw6XBm2uuKakltPoRR/P/hUyeL0k1IKE+uAhLo0jBZ6yGIYXbfnuUVchhWwJDLE7lhdqqV0INNjT5OYeu8SKycE/EyKNVCU8shugPe+cpPdEiiy+w2jISBq0IgMTUiMhyU2NfvfOiSCrTIsuDKQ==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(376014)(1800799024)(82310400026)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Jg8zgoch5brPANMZ3XuHzNy1fLpUReZIYCbON75pDa+W+HPbWRM9rnI+Z3C9BUVfwDL8fIWazA+zzYORYZhyMmQdPluhXWrseZjtojZUU3hb3QGkLNqYOTo9V4yAQaGCs+gDG0ZkRUR1aZ3PNnqQzcniuLdye8keYuecFTbYVIFCPysjHvzyhwANEQ/X2Pju2PNvA4JxB3LA2SR9xk3kj9/LChMLzVAKvZOCDCnguqX1mP7yhSzcNRr4LoA13mZxhCUmGO9lwSNGCwW/pSiNrndAgeF/BWRYP0m+N8gSovdBZDEik8JuBElKw9tFvER+dmDStYTjNDwCTZhflLFcEZFRqtlErs3hr+jz67fZ5ZmjKdUKDAkaUF0BEnqx481dJcd5sHTOFNlCtXqaFy0v0Da7DfO2Sea0jDtmcQ8F6pohd7itooqrHT4NNm9Bv+9+
X-Exchange-RoutingPolicyChecked:
	PgP1uXEapN1K7iST7kgOhCdbzU3LvVjL22K5HRD1tNSWcb0revrySQGjYNpHB+KoMQmrgufvy1XCvdCs0PfkNuqmFeWoZI2iKNQxtNg5VfjrETMetc2wd3ItJ1MquwppgSmbd7Igz5VEA89WEnQGQZRIlTd37J9cVnFqwidN/HQM3WkSEiQpciMKY1JZUguZ8RJlh+dUeELp4fCC5hu785aBIdlThi2z3hMrNOmi5MgQJJd8bgtE+R8syIszyIVFNUQokWor3kpFZg5bLbE2iFJnMmm9ysIB5kCU7S+ucl0h5hxXKIbICnwfHO6cDu26BfOzAZcM0EpJygJqzxZ07w==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	bQugfy34CCvY/z/PRfFDCGp1Mnuqq45wm0MhWgxF/62ue7675Sd+CApshGWEqiRLr4ou0BBZv29Z3zB6t4hGAMylNVY9yWKgJwnQU6poWEkFgX65A3JVndB3eVEa0hxwa+aqaoxpoL4M0QS+zrPeosYrjM6TfSVALSnrYKFcG2AAHDMVMgBtjVc9NJwqrhEylpWZ58bbLyn8fJyaI2ACp7mSLXdpAaSUuK9V58Gv4DmCNT90eBqVZo5tjryEzfVXUaBwlPOVk+2R4QUeR5an3pEmHAGWQw+KzHevpfNbFa++Kwyg5xmO7AMCbrgzFJ30nb8ILP/GcIlEb3yO1oJFkVziwMkcvHNSM+RwoYWOJFE5JPOJ7v8AUfWS/wTzHoPSebBRcvvYuJycjFOL2XSb/i7Ylbzwe/70QmxuO7LZlcl3Nmc+MIB8r1lHlhBurXZwe+kM1hzB1JP1HXtRBX7UOrMujShaH8nPUh46i+Y0K67jg7EnT96UAoFYQ3MFPspNjlIx16dThjIX8OIHBtY925nWbd8KgbK57Os8k25LbfJXkWuXvKB7WYoZykBroKYyDBD9B3dZu+o4M8q8E2BMHxEUcOsMfkj+vWz8NpBOLeGR02XSf1T1EhiJpxihaZQ2
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 07:00:58.8743
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ecedcf11-c9e6-481c-0823-08def12cf8f0
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099DB.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR16MB5548
X-Proofpoint-Spam-Info: AW1haW4tMjYwODAzMDA2MCBTYWx0ZWRfX3CT1Q6fNnpM5
 i6KkieIYKoTkv4RO/mgjrg2xy7JCJ+sYOFs3rqOEMRqYNQEUbCejiVNR66JWPKchda8f9SNKblf
 x/SxsQYUm3sUlG6wldqSmDpxjYDt4MbRkSImuVc5B7qJOPb9MWiO
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODAzMDA2MCBTYWx0ZWRfX08XMUj3yLEy0
 i2LShH2g74tJSN6f876g5O+iUiEDDF+QcwKoVH8i4NnsEZHE4/MqHVMXNXQH0t8QNquw6bBBlWn
 Urz4P+NCgE1N4Mj4MjQku35+E5Snv3DgiBUHwy3i8SqwptOJBXLm3MgYZshaq+RYYvTNaf1Evnv
 /Z8t/ME42yexzPIj2zHLul1X3YeOeUTl6GF+z0aS26A8pK+P1Mv1xemofv7ibMmy0s9b9uZgxqW
 Sp6Gx2CbUGYVMP/9ct2/hj6emH4yKluTO9hHz4doc+NFDzgWO0hsduqThULawP7T7XCMYFem8ka
 xWkUrMmjFqqvkeaszsXXR8NuFWidQUqiQYFzR97JugxfSRRNnrcMSk0vOv3ROwWEtWRlBEBo9iU
 T5+OXANSX82Tj0rSv1v9Cd32mbxi/LEK0M3N3FTqgssjFRj0Xnekfnvn4jGN61fn5mWaP/4TcMc
 HHhGc7LpqWfB+bSvB8Q==
X-Proofpoint-GUID: 2Ke1h0DB-RlHEMINttMYzlXeUG1ejo9J
X-Proofpoint-ORIG-GUID: 2Ke1h0DB-RlHEMINttMYzlXeUG1ejo9J
X-Authority-Analysis: v=2.4 cv=Xc25Co55 c=1 sm=1 tr=0 ts=6a703cae cx=c_pps
 a=TVJYqPbIpBJCeYGeirASbA==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=N9_n2FxmZfwfyRXvS9-E:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=IgJ0wlFFhhnA7GDi3u4A:9 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-02_06,2026-07-30_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 suspectscore=0 adultscore=0 priorityscore=1501 clxscore=1015 impostorscore=0
 lowpriorityscore=0 phishscore=0 bulkscore=0 spamscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608030060
X-purgate-ID: tlsNG-33051d/1785740464-6E0D14E9-684B3292/0/0
X-purgate-type: clean
X-purgate-size: 1462

From: Denis Mukhin <dmukhin@ford.com> 

Currently there's no way to print Xen command line on the emergency
console for debugging purposes (e.g. 'xl' is not available in dom0).

Add new keyhander 'X' to do command line printout.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
v1: https://lore.kernel.org/xen-devel/20260730061459.2702672-2-dmukhin@ford.com/

Changes since v1:
- moved implementation into kernel.c
---
 xen/common/kernel.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d1bef9ac2b2b..9f334c92e3ab 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -5,6 +5,7 @@
  */
 
 #include <xen/init.h>
+#include <xen/keyhandler.h>
 #include <xen/lib.h>
 #include <xen/errno.h>
 #include <xen/param.h>
@@ -505,6 +506,21 @@ static int __init cf_check param_init(void)
 __initcall(param_init);
 #endif
 
+static void cf_check show_hypervisor_info(unsigned char key)
+{
+    printk("'%c' pressed -> showing hypervisor information\n", key);
+    printk("Command line: %s\n", saved_cmdline);
+}
+
+static int __init cf_check misc_init(void)
+{
+    register_keyhandler('X', show_hypervisor_info,
+                        "show hypervisor information", 0);
+
+    return 0;
+}
+__initcall(misc_init);
+
 static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xen_varbuf user_str;
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:03:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:03:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381197.1624755 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmiF-0004Xu-F5; Mon, 03 Aug 2026 07:03:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381197.1624755; Mon, 03 Aug 2026 07:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmiF-0004Xn-AN; Mon, 03 Aug 2026 07:03:51 +0000
Received: by outflank-mailman (input) for mailman id 1381197;
 Mon, 03 Aug 2026 07:03:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqmiD-0004Xh-RK
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:03:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmiD-00Dxvj-4A
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:03:49 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a703d4a-bab6-0a2a0a5309dd-0a2a45059f20-38
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:03:48 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a703d54-4cb1-0a2a45050019-d155dd2fc4e5-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:03:48 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-4728c12ba97so1523518f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:03:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd41d17f2sm33644859f8f.2.2026.08.03.00.03.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 00:03:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785740628; x=1786345428; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=QKOmY2KE6KPejC5HiiQ7SG5gdG6x5qoQ/fhwL1B51YE=;
        b=M44zeSMqprEQeZ21Eom2rgZ62YOmWYCX7nAAPzLJ27aC9FMcs0qAsaOw8+/Ygq4zmh
         yzOtLnOL3MsUQgYKoeFN3XBsk/edniqZriAG1FqdXd9FHPK+EE+oJR5oRlF5Q0wdiapF
         ZMx2Id8StPsFL90hSiosHKSzLtpcCid8p+VDKaGadObDHdfz6aD42fTy3C3GnzpgnLAb
         WFhyZqG5ky3D6ffBkFfP8yS22C36fmKbGoTsVP6CYfPxmC2/3JgurENeltB8gblYaiiS
         bECsqMitb81Za3kkFLLhhsan6Wp+IaJtOucoHC8usa0PTm/pVhWrtelxyYExLUsi7OID
         AbKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785740628; x=1786345428;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=QKOmY2KE6KPejC5HiiQ7SG5gdG6x5qoQ/fhwL1B51YE=;
        b=d0m531XCsdzfIv9JPiSXwRpBrp+lxUh3uCROUBZ4mcpJlw1ItMVaGMANLgkt2pG6MO
         i90lUI3zowXYxCIXrg5Ovz+WehL6/72fO50NTigfjl2Dtkc+ROjBZiggPnNPYWuE662e
         NtKH6vRckscnNLY2IzKTo2yiF3FymMlOkjydwnDgSkr764YdNg/HarDVjGrtxdHdan1+
         CUwOU9hRzOjl7P5g3USit0kPLAho5GSX2UQRFGLWWHNwb3b/wnB6rLC4ClO5X7e9Iyjc
         F32fvZfp/Yws2GhgfhmkY/izoVmvJddUd7Q3ce7k8QnvDIJLK1sLr2Em1ChPbWzRRfU7
         46yg==
X-Forwarded-Encrypted: i=1; AHgh+Rrpqdnl2d73ppgBT4OhYNW7qxtzg3uLLKneLOIw3+6HMsnMRdZ15/TmnHM/Tr2DK+RILdr8+QIQdPc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzMb/NMyjioAYoaOi6ujsfkB0RXH2xVXVfTQ5wTb7RO1XsQAM/p
	9D7mL5L7rnno8Qcl3aXwVy1YtJLHJEX/gteScafpqra5oU5hSHXfm3al39jCQpAOHQ==
X-Gm-Gg: AR+sD12N+hXUw3f+pBLN1f0uiWUFNn865OR07lwFqXW/nm2FPghCdLdlaedZqNL9XFq
	3WQknL7hXd2lPdH/38P7ox+P1NWf32R0sr900ICf7LBNtbDSUkAUtHHze8cA+GumIn/v9wbQu49
	a7ufwNFBnEPy6lZDNRKPxbTsXN72T9GIKiaVRcZ35HoXiShVpH7InQMIZyN9SKb1By19RwYg1ef
	YqV2c1hZ1745QcLxiPEFQkfFEAAx0zCzWrM3bxf34dj2/nMEjWdqdWUIH9LNvHi5/8R5FiXDb7N
	gNDiwMU2aBIjuk4BQ3/m9+Pj/G7j0GCyhF59N1rfVak76lggX02J5gjr8CeHJmzq8VnKfxzw0U8
	VB8H1ZxeVa2g3kyW6LqEOjkD1oKrJDIUfSBuD+HqhALqfgRdc4pxbCCxW51xxwb8msaPUzWpUzA
	sVTgswqoNusByXS/2GAAZLlrPSrZfUwp5SMi8+i6Yx0smcIV9/LlfHP2LicMTdeSF9mYrTvfvSU
	GIj3HWx8Qba2qCf4aIjYgPQMKGDWu+6Lc5k51jnfNEX9yDN0jbIGXHC+phDrwYB
X-Received: by 2002:a05:6000:2a8a:b0:47f:95e8:2ebf with SMTP id ffacd0b85a97d-47fd72a5db8mr18316947f8f.12.1785740628030;
        Mon, 03 Aug 2026 00:03:48 -0700 (PDT)
Message-ID: <9d594e54-6409-4554-b555-d6de55e85840@suse.com>
Date: Mon, 3 Aug 2026 09:03:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/common: annotate saved_cmdline with
 __ro_after_init
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260803070047.3097846-1-dmukhin@ford.com>
 <20260803070047.3097846-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260803070047.3097846-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1785740628-722AB2A1-183040C2/0/0
X-purgate-type: clean
X-purgate-size: 420

On 03.08.2026 09:00, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> The hypervisor command line is not modified after initialization.
> Annotate saved_cmdline with __ro_after_init to place it in the
> dedicated read-only-after-init section.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:05:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381204.1624763 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmjP-00052l-MY; Mon, 03 Aug 2026 07:05:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381204.1624763; Mon, 03 Aug 2026 07:05:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmjP-00052d-JE; Mon, 03 Aug 2026 07:05:03 +0000
Received: by outflank-mailman (input) for mailman id 1381204;
 Mon, 03 Aug 2026 07:05:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>) id 1wqmjO-00052T-Is
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:05:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <julien@xen.org>) id 1wqmjO-0035os-0W;
 Mon, 03 Aug 2026 07:05:01 +0000
Received: from [2a02:8012:3a1:0:1c3d:3a3f:6f77:bb54]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <julien@xen.org>) id 1wqmjN-00Gr4G-21;
 Mon, 03 Aug 2026 07:05:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=GRSGqypqbk2k3z4aWHq7GUzYwzK35klZeVSvhyZvPNc=; b=Ty9zn0siBEbLWY4HQB7ljilVUl
	zaTS8dQlcQcmNOVcT03q9Zo+W48o68nZdie7p112YRjVx8/sKwa4iuxtvG924gZSDD6MwyQfHmurv
	rmKNrgJKxb8oWIYflUGpsAj/n/3eGYWzbDNvjMtXEZI0xuQ7wJf3efNjahI6vN3H9vWY=;
Message-ID: <dbb32862-b3d2-4fb5-b4ef-49675fa243b2@xen.org>
Date: Mon, 3 Aug 2026 08:04:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Hide PMU feature
To: Hirokazu Takahashi <taka@valinux.co.jp>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260803004245.693844-1-taka@valinux.co.jp>
Content-Language: en-GB
From: Julien Grall <julien@xen.org>
In-Reply-To: <20260803004245.693844-1-taka@valinux.co.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 03/08/2026 01:42, Hirokazu Takahashi wrote:
> On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
> causes the domain to probe advanced PMU feature based on system ID
> register ID_AA64DFR0_EL1.
> 
> During this probe, Linux accesses PMMIR_EL1, which causes unhandled
> register traps and crashes the domain. Merely adding emulation code
> for PMMIR_EL1 in Xen is insufficient to fix the issue, as the guest
> PMU driver subsequently stalls during its initialization sequence.
> 
> Fix this by explicitly masking PMU capability fields in
> create_domain_cpuinfo(). Additionally, preemptively mask other
> capability fields to prevent similar potential issues.

While I agree Xen doesn't support PMU capability for every guest, I 
believe we are still allowing to expose the PMU in some cases (see 
commit dbb948110a "xen: Expose the PMU to the guests"). So we can't 
simply mask the features. So I think ...

> 
> Fixes: 3669a1cb9598 "xen/arm: create a cpuinfo structure for guest"
> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
> ---
>   xen/arch/arm/cpufeature.c             | 16 ++++++++++++++++
>   xen/arch/arm/include/asm/cpufeature.h | 10 ++++++----
>   2 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 94d14fb6a9..71d745d3cb 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -219,8 +219,24 @@ static int __init create_domain_cpuinfo(void)
>       domain_cpuinfo.isa64.api = 0;
>       domain_cpuinfo.isa64.gpa = 0;
>       domain_cpuinfo.isa64.gpi = 0;
> +
> +    /* Hide PMUv3 support as Xen does not support it */
> +    domain_cpuinfo.dbg64.pmu_ver = 0;
> +    domain_cpuinfo.dbg64.mtpmu = 0;
> +    domain_cpuinfo.dbg64.pmss = 0;

... this section needs to be conditional.

> +
> +    /* Hide SPE, TRBE, BRBE, and Trace Extensions */
> +    domain_cpuinfo.dbg64.pms_ver = 0;
> +    domain_cpuinfo.dbg64.trace_ver = 0;
> +    domain_cpuinfo.dbg64.trace_filt = 0;
> +    domain_cpuinfo.dbg64.trace_buffer = 0;
> +    domain_cpuinfo.dbg64.ext_trc_buff = 0;
> +    domain_cpuinfo.dbg64.brbe = 0;

This section should be fine to unconditionally mask.

>   #endif
>   
> +    /* Hide PMUv1,v2 support as Xen does not support it */
> +    domain_cpuinfo.dbg32.perfmon = 0;
> +
>       /* Hide AMU support */
>   #ifdef CONFIG_ARM_64
>       domain_cpuinfo.pfr64.amu = 0;
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index bf902a3970..c92b2651c7 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -216,16 +216,18 @@ struct cpuinfo_arm {
>               unsigned long trace_ver:4;
>               unsigned long pmu_ver:4;
>               unsigned long brps:4;
> -            unsigned long __res0:4;
> +            unsigned long pmss:4;
>               unsigned long wrps:4;
> -            unsigned long __res1:4;
> +            unsigned long sebep:4;
>               unsigned long ctx_cmps:4;
>               unsigned long pms_ver:4;
>               unsigned long double_lock:4;
>               unsigned long trace_filt:4;
> -            unsigned long __res2:4;
> +            unsigned long trace_buffer:4;
>               unsigned long mtpmu:4;
> -            unsigned long __res3:12;
> +            unsigned long brbe:4;
> +            unsigned long ext_trc_buff:4;
> +            unsigned long hpmn0:4;
>   
>               /* DFR1 */
>               unsigned long __res4:64;

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:12:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:12:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381214.1624772 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmqJ-0007i6-Ew; Mon, 03 Aug 2026 07:12:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381214.1624772; Mon, 03 Aug 2026 07:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmqJ-0007hz-C9; Mon, 03 Aug 2026 07:12:11 +0000
Received: by outflank-mailman (input) for mailman id 1381214;
 Mon, 03 Aug 2026 07:12:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqmqH-0007ht-Q3
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:12:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmqG-001kEi-Lu
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:12:08 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a703f3f-e002-0a2a0a5209dd-0a2a4508a91e-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:12:08 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a703f47-f659-0a2a45080019-d1558033b8a7-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:12:07 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so17468615e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:12:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-498081a12a3sm304521125e9.8.2026.08.03.00.12.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 00:12:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785741127; x=1786345927; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=dYttu9GmNTW+Yd8Ey/akGPCigADcH3aBDJw1ZLxxrHs=;
        b=Gkh25rRhQDVtyeaJEojMLsDL0BUz1YdhWf7qnOu+u8UJMuhAvWvXbV56DqPY7nujJG
         Z3xPu0zfS5Vt9Slc7aUO3fPzLmABcKvY4xqq8hb93Rs/TA2I90zSRgKq3BC9ExpzFqgz
         hsiGuyk6+a6catWjXHaDfRbuGKQP9HYpUyjADlvEOVSec4D/8SXc3Sj0A1oLxc4hYYW6
         sGc+qRQuQ0bCGSrhIiuwpweiWBdqrcVVA4hnv1xfAxfD8arKVVMtdt6yziTzGNyoSpbl
         0LTC8h2DWIZRDJv/zP+fSwx8bFc/FBR3n9YXuZHFY2BvTqiyTaKP6Y3Via+/2EGCRsfy
         tmzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741127; x=1786345927;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=dYttu9GmNTW+Yd8Ey/akGPCigADcH3aBDJw1ZLxxrHs=;
        b=HGty45UN0qOIzCsgZM/fGF8s002igdS6Gao7k92H9A0vvd57ZesIcIQTgnyW1SAOrM
         CBH2c49h7ZWgNFNIspq2UosOcdfur+q75vRq5fWl2WcJ4Ev6XECKQgpgzwkAuaJExunu
         qJSv8XVRvkB5FBTLvj+R+5v913rkOp1zRWAdl/l8Xc2HfgK5sppkeU2Tr3W05f8yXD/I
         g1JODBCk9pGouAVQ4ppDMCD6ez4XwOIySpu2Whu5B4f5iucHCJqnUqimRKZhrdinKrq+
         yPa2mtsWJj5Kb0b6JocN1iA/4qq9L8a7yU+wJATNj2tBfFTWGF3VL1b5jIocYp7ESp4M
         M/gw==
X-Forwarded-Encrypted: i=1; AHgh+Rre1dCb8IiaJ72qBD/7luuJTvaogJ52eLe0ivrT+LS0s6nyerQx3BhwqSXyktg5Xe0fD4IAkJYHdxg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywi0f2NaL1sv7rsZ8fAERWySrbdT3iSDXpbLlm7rei/PUjvLBco
	tlcnVL9CbV5GosAz5JZ25xAMNPkCpuwR4UWS0MpjQXHbBXS3y0DHIEXMqPKCQbLLrA==
X-Gm-Gg: AR+sD11M9TdU+HI72Fx0q48/cpebJ8C0IgiNZyTBoTpxnGSt1VQPG+4C4cJ2LYuL0Go
	JcgPLpfDpindFTm7r7K8i9mJdiwL6t2yz3jvmf+iIhBFXIifpPjUk7TYmDKoMIZZlMPd1hznG2W
	iVB5rS5QRM0Iff+og1wIlTzfLGJz7+oq+Fo/zExcKzb5bBZLNqUUq9S0PeMItQz6HIsiCAFOQJC
	M2Y14iLxWDzwpXAyHNSRakA/WhxOS/UpumPMGa9YbJ4hbkGLJULA3TRgSO4Yaof+3W0j7IFVMV8
	Kn+lyQC8UbjVqsDExJyg9gwnBvmndlanpe2/o6bJ5aEbp8nM1Dp+vJBPwKPznbXX2sT6tqdht1G
	ffi9iAtMcR/1mF9M3qMG/LDp/RwZKlYCMw+j0rnWMr3G7npOzJNI6yjpraoejxmIlkQtpx3uJUn
	eddbiRFuylGq9iixxguRXjwfZeS9Etl7bKF0W408L6HB7f9Whc1smC18hnWX0wxANspI7ncxuDD
	zUsD8IPJHkeUxlEzrr+K+5DxadVAQT27JEF6U2qvgA8JK3MiadG
X-Received: by 2002:a05:600c:8711:b0:495:52a5:8829 with SMTP id 5b1f17b1804b1-4980c652515mr233174835e9.11.1785741127248;
        Mon, 03 Aug 2026 00:12:07 -0700 (PDT)
Message-ID: <c99c9645-4ffe-43e3-a56e-1a0c6efc006e@suse.com>
Date: Mon, 3 Aug 2026 09:12:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] nSVM: Check injected event consistency
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, jason.andryuk@amd.com,
 xen-devel@lists.xenproject.org, teddy.astie@vates.tech
References: <1785247466.8631fc262581453bbf619ec5b2062170.19fa90a823a000e099@vates.tech>
 <20260731142700.2207713-1-abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260731142700.2207713-1-abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785741127-CC37587B-7C1ABA6A/0/0
X-purgate-type: clean
X-purgate-size: 2052

On 31.07.2026 16:26, Abdelkareem Abdelsaamad wrote:
> On 28.07.2026 14:04, Teddy Astie wrote:
>> On 16.07.2026 17:41, Abdelkareem Abdelsaamad wrote:
>>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>>> @@ -320,6 +320,31 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
>>>       svm_dump_sel("  TR", &vmcb->tr);
>>>   }
>>>   
>>> +static bool is_valid_svm_vmcb_injected_exception_vector(
>>> +    const struct vmcb_struct *vmcb, uint8_t vmcb_injected_vector)
>>> +{
>>> +    return ( (vmcb_injected_vector == X86_EXC_DE) ||
>>> +             (vmcb_injected_vector == X86_EXC_DB) ||
>>> +             (vmcb_injected_vector == X86_EXC_BP) ||
>>> +             (vmcb_injected_vector == X86_EXC_OF) ||
>>> +             (vmcb_injected_vector == X86_EXC_BR) ||
>>
>> This particular exception is special. AMD APM states that this event is 
>> "impossible" if the guest is in 64-bit mode and will cause 
>> VMEXIT_INVALID in such case.
>>
>>> If the VMM attempts to inject an event that is impossible for the 
>> guest mode (e.g., a #BR exception when the guest is in 64-bit mode), the 
>> event injection will fail and no guest state instructions will be 
>> executed; VMRUN will immediately exit with an error code of VMEXIT_INVALID.
>>
>> So this one likely want a additional check for hvm_guest_x86_mode() != 
>> X86_MODE_64BIT.
>>
>> It looks like #OF has the same quirk (invalid in 64-bits mode).
>>
> I agree your point is valid. I will address in V3.
>> Though I don't know if any other exception has a similar behavior though.
> I have double-checked the APM vOL3(24594—Rev. 3.37—jULY 2025) regarding the
> other exception vectors and instructions. Vector 4 (#OF) and vector 5 (#BR) are
> unique because their triggering instructions BOUND and INTO are invalid and
> disabled in 64-bit mode, making them structurally invalid. Other vectors remain
> legal across the other modes.

#BR is also used by MPX insns, which are usable from 64-bit mode.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:20:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381227.1624802 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy8-000254-3m; Mon, 03 Aug 2026 07:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381227.1624802; Mon, 03 Aug 2026 07:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy7-000241-PW; Mon, 03 Aug 2026 07:20:15 +0000
Received: by outflank-mailman (input) for mailman id 1381227;
 Mon, 03 Aug 2026 07:20:14 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqmy6-0001jg-4z
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:20:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmy5-003y8B-Hf
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:20:13 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a704126-bab6-0a2a0a5309dd-0a2a4503b0a8-16
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:13 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70412d-fae8-0a2a45030019-d1558030ec2b-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:13 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4954dff6536so11880315e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:20:13 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm254687935e9.2.2026.08.03.00.20.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 00:20:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785741613; x=1786346413; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=gMKVONwVKWbxkNk3T1xy4QQFBmudUjsDlfFhaJQN3QA=;
        b=OW9ILTgoJECRpkGok21bENgd6gRtTiP29It/wLi0XXLv8hGTGSnZirCFtqhHFvnKr8
         EupYblfooM4MTINs46ZYNObtZXSIhpTsjIrlZ3tgAsfodMB8JM+UXfzSB+iDneJVS2AM
         M93cM4peIfJya3p0K81xcpq1livvj7GBjRfQM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741613; x=1786346413;
        h=content-transfer-encoding:content-type: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=gMKVONwVKWbxkNk3T1xy4QQFBmudUjsDlfFhaJQN3QA=;
        b=lZ6oifkWx02Z7Vp6prfMaz/xnlwf0N7uL63aeLzfmL/g0zVhYce+5lmbOoU9okP03d
         q+UWENdFw01N1m6h3V2tIBItG69jf2v8eqE/s9quZ+y8pQFG6wITTtAzthu7ilaAta53
         CIe34WFxqgVwCfE8kXWJJVYd7rnzz4DCJTtd3zsOb5ZzguG11Q7FgZhDgMVhMEmdbVIH
         Jw9JAHpAVbpP6qUUB7rT+peq13zVoVs84SXt/o0vsjispVRO+jjsJa4kBXo2A26kNOcz
         pAL8aUBX/qua9ZSeLptj3/qT7C2om4DZDUw59qtrdCK1HSSAeT/xw7jm9PJqR8VvV5oA
         f2dQ==
X-Gm-Message-State: AOJu0YxLOTmWAVCAh1jXcuhHdWir2pKL/ozh2S4fN30u3Y+s2tNFa2UX
	vprwfJWDHCEU1kpmn59d+UtepYmUkXA4GF5ban2p+Zx5j5neQS91X/6Ccc/yq3luTS0hR+V/Aix
	LvMfH
X-Gm-Gg: AR+sD11U+JuzZDDXeYaFRe1xeh98XKKkcaEYejJ5kG6YSrItCCrL9wV/WzchxelvL13
	vcVSf59s37YxNy1oPdHvVPiMJ7yNDsTXXVIbGlpkF9Y4ZsCGs5CoD2Chsn8XqBCAonBglgXPKhj
	Ikg1WQd9/S/yiuZ9fEPvVKaRJ0eoNcWwgXhTBkTl1oL0FLgu0utln94AWdAxZ6Kbg8iUiJyjjMd
	k9MTpEo1ckEk/y1yz5a28q1bWcigwBOTm6D7FMnnpdfmLCfPEYumOhSIQVycqd09SjoJBaIcCWc
	ZlE5+gOwgXQhC7O1H6ArBcjqvQkAyF8c5bnBVxB1bDDStnYJjxGo2m20kSKw5Jc9qRhMQbH5qKy
	h925xNP85fxpbXdmep0hLFupnqA1KEY2mOnBacW5vihgEXRjGr7EI793xCY8SLnztkar+LO2j4y
	p3LKiQDCS7hOVmEf+LX0zcaD69tP726JyOfPIvrkOiVAT/ntcW2kgEgfEKdfbFeOXhDifmgZJnp
	ArfmmjGmG6CaAU56cAxoNGVJNUIYI9PTeyn8wc=
X-Received: by 2002:a05:600c:4ec9:b0:495:62bc:a022 with SMTP id 5b1f17b1804b1-4980c67474amr156128365e9.13.1785741612311;
        Mon, 03 Aug 2026 00:20:12 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v3 2/5] tests/x86: Introduce a userspace test harness for x86_decode_lite()
Date: Mon,  3 Aug 2026 08:20:03 +0100
Message-Id: <20260803072006.9678-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803072006.9678-1-andrew.cooper3@citrix.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785741613-6F0C94E9-0D410C2D/0/0
X-purgate-type: clean
X-purgate-size: 30806

All the interesting behaviour is in insns.S.

There are 4 interesting cases; "not an instruction we tolerate", and one we do
tolerate, split by no relation, disp8 or disp32.  The DECL()/END() macros
start and terminate the tests_*[] arrays used by C.

Between DECL()/END(), a macro named _ adds an entry into the array, including
a name and the length of the instruction according to the assembler, while
being as visually unintrusive as possible.

Plain labels are ad-hoc and there to aid legibility during disassembly.  In a
couple of cases, the macro named n (for name) allows for choosing a name
manually, and is used for cases where the assembler doesn't like the mnemonic.

Clang IAS doesn't like the convience macro, and Binutils of around 2.30 don't
like sysexitl or movsxd with a 32bit operand.  As it's only Ubuntu 18.04
affected by this, skip building the harness in old environments.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

v3:
 * Force disable Clang IAS.  It doesn't like the _ macro.
 * Support 32bit builds

v2:
 * New
---
 tools/tests/Makefile                      |   1 +
 tools/tests/x86-decode-lite/.gitignore    |   1 +
 tools/tests/x86-decode-lite/Makefile      |  56 ++
 tools/tests/x86-decode-lite/insns.S       | 703 ++++++++++++++++++++++
 tools/tests/x86-decode-lite/macro-magic.h |  62 ++
 tools/tests/x86-decode-lite/main.c        | 111 ++++
 tools/tests/x86-decode-lite/x86-emulate.h |  27 +
 7 files changed, 961 insertions(+)
 create mode 100644 tools/tests/x86-decode-lite/.gitignore
 create mode 100644 tools/tests/x86-decode-lite/Makefile
 create mode 100644 tools/tests/x86-decode-lite/insns.S
 create mode 100644 tools/tests/x86-decode-lite/macro-magic.h
 create mode 100644 tools/tests/x86-decode-lite/main.c
 create mode 100644 tools/tests/x86-decode-lite/x86-emulate.h

diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index fc0ed8091510..ca4f0c707638 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -14,6 +14,7 @@ SUBDIRS-y += xenstore
 
 SUBDIRS-$(CONFIG_X86) += cpu-policy
 SUBDIRS-$(CONFIG_X86) += tsx
+SUBDIRS-$(CONFIG_X86) += x86-decode-lite
 ifneq ($(clang),y)
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 endif
diff --git a/tools/tests/x86-decode-lite/.gitignore b/tools/tests/x86-decode-lite/.gitignore
new file mode 100644
index 000000000000..e726b493c993
--- /dev/null
+++ b/tools/tests/x86-decode-lite/.gitignore
@@ -0,0 +1 @@
+test-x86-decode-lite
diff --git a/tools/tests/x86-decode-lite/Makefile b/tools/tests/x86-decode-lite/Makefile
new file mode 100644
index 000000000000..dc33d5fd173a
--- /dev/null
+++ b/tools/tests/x86-decode-lite/Makefile
@@ -0,0 +1,56 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+TARGET :=
+
+# Clang IAS doesn't like the convenience macros we use
+$(call cc-option-add,CFLAGS,CC,-no-integrated-as)
+
+# Binutils around 2.30 have mutually exclusive expectations of instruction
+# suffix validities compared to later versions.  Among the distro we test,
+# this only excludes Ubuntu 18.04.
+ifeq ($(shell echo 'asm(".code64;sysexitl");' | $(CC) -x c -c -o /dev/null 2>/dev/null - && echo y),y)
+TARGET += test-x86-decode-lite
+endif
+
+.PHONY: all
+all: $(TARGET)
+
+.PHONY: run
+run: $(TARGET)
+	./$<
+
+.PHONY: clean
+clean:
+	$(RM) -- *.o $(TARGET) $(DEPS_RM)
+
+.PHONY: distclean
+distclean: clean
+	$(RM) -- *~
+
+.PHONY: install
+install: all
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)/tests
+	$(if $(TARGET),$(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC_BIN)/tests)
+
+.PHONY: uninstall
+uninstall:
+	$(RM) -- $(DESTDIR)$(LIBEXEC_BIN)/$(TARGET)
+
+.PHONY: uninstall
+uninstall:
+
+vpath decode-lite.c $(XEN_ROOT)/xen/arch/x86/x86_emulate
+
+CFLAGS += $(CFLAGS_xeninclude) -I. -I$(XEN_ROOT)/xen/arch/x86
+CFLAGS += $(APPEND_CFLAGS)
+
+
+LDFLAGS += $(APPEND_LDFLAGS)
+
+%.o: Makefile
+
+$(TARGET): main.o insns.o decode-lite.o
+	$(CC) -o $@ $^ $(LDFLAGS)
+
+-include $(DEPS_INCLUDE)
diff --git a/tools/tests/x86-decode-lite/insns.S b/tools/tests/x86-decode-lite/insns.S
new file mode 100644
index 000000000000..8b299cfb594e
--- /dev/null
+++ b/tools/tests/x86-decode-lite/insns.S
@@ -0,0 +1,703 @@
+#include "macro-magic.h"
+
+        .code64
+
+        .allow_index_reg
+
+        .text
+
+DECL(tests_rel0)
+modrm:
+        /* Mod=0, Reg=0, RM {0..f} */
+        _ add %al, (%rax)
+        _ add %al, (%rcx)
+        _ add %al, (%rdx)
+        _ add %al, (%rbx)
+        _ add %al, (%rsp) /* SIB */
+        /*add %al, (%rbp)    RIP --> tests_rel4 */
+        _ add %al, (%rsi)
+        _ add %al, (%rdi)
+        _ add %al, (%r8)
+        _ add %al, (%r9)
+        _ add %al, (%r10)
+        _ add %al, (%r11)
+        _ add %al, (%r12) /* SIB */
+        /*add %al, (%r13)    RIP --> tests_rel4 */
+        _ add %al, (%r14)
+        _ add %al, (%r15)
+
+        /* Mod=1, Reg=0, RM {0..f} */
+        _ add %al, 0x01(%rax)
+        _ add %al, 0x01(%rcx)
+        _ add %al, 0x01(%rdx)
+        _ add %al, 0x01(%rbx)
+        _ add %al, 0x01(%rsp) /* SIB */
+        _ add %al, 0x01(%rbp)
+        _ add %al, 0x01(%rsi)
+        _ add %al, 0x01(%rdi)
+        _ add %al, 0x01(%r8)
+        _ add %al, 0x01(%r9)
+        _ add %al, 0x01(%r10)
+        _ add %al, 0x01(%r11)
+        _ add %al, 0x01(%r12) /* SIB */
+        _ add %al, 0x01(%r13)
+        _ add %al, 0x01(%r14)
+        _ add %al, 0x01(%r15)
+
+        /* Mod=2, Reg=0, RM {0..f} */
+        _ add %al, 0x7f000001(%rax)
+        _ add %al, 0x7f000001(%rcx)
+        _ add %al, 0x7f000001(%rdx)
+        _ add %al, 0x7f000001(%rbx)
+        _ add %al, 0x7f000001(%rsp) /* SIB */
+        _ add %al, 0x7f000001(%rbp)
+        _ add %al, 0x7f000001(%rsi)
+        _ add %al, 0x7f000001(%rdi)
+        _ add %al, 0x7f000001(%r8)
+        _ add %al, 0x7f000001(%r9)
+        _ add %al, 0x7f000001(%r10)
+        _ add %al, 0x7f000001(%r11)
+        _ add %al, 0x7f000001(%r12) /* SIB */
+        _ add %al, 0x7f000001(%r13)
+        _ add %al, 0x7f000001(%r14)
+        _ add %al, 0x7f000001(%r15)
+
+        /* Mod=3, Reg=0, RM {0..f} */
+        _ add %al, %al
+        _ add %al, %cl
+        _ add %al, %dl
+        _ add %al, %bl
+        _ add %al, %ah
+        _ add %al, %ch
+        _ add %al, %dh
+        _ add %al, %dl
+        _ add %al, %r8b
+        _ add %al, %r9b
+        _ add %al, %r10b
+        _ add %al, %r11b
+        _ add %al, %r12b
+        _ add %al, %r13b
+        _ add %al, %r14b
+        _ add %al, %r15b
+
+sib:
+        /* Mod=0, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */
+        _ add %al, (%rax, %rax, 8)
+        _ add %al, (%rcx, %rax, 8)
+        _ add %al, (%rdx, %rax, 8)
+        _ add %al, (%rbx, %rax, 8)
+        _ add %al, (%rsp, %rax, 8)
+        _ add %al, (    , %rax, 8) /* "none", %rbp encoded with mod=1/2 */
+        _ add %al, (%rsi, %rax, 8)
+        _ add %al, (%rdi, %rax, 8)
+        _ add %al, (%r8,  %rax, 8)
+        _ add %al, (%r9,  %rax, 8)
+        _ add %al, (%r10, %rax, 8)
+        _ add %al, (%r11, %rax, 8)
+        _ add %al, (%r12, %rax, 8)
+        _ rex.b add %al,(,%rax, 8) /* "none", %r13 encoded with mod=1/2 */
+        _ add %al, (%r14, %rax, 8)
+        _ add %al, (%r15, %rax, 8)
+
+        /* Mod=1, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */
+        _ add %al, 0x01(%rax, %rax, 8)
+        _ add %al, 0x01(%rcx, %rax, 8)
+        _ add %al, 0x01(%rdx, %rax, 8)
+        _ add %al, 0x01(%rbx, %rax, 8)
+        _ add %al, 0x01(%rsp, %rax, 8)
+        _ add %al, 0x01(%rbp, %rax, 8)
+        _ add %al, 0x01(%rsi, %rax, 8)
+        _ add %al, 0x01(%rdi, %rax, 8)
+        _ add %al, 0x01(%r8,  %rax, 8)
+        _ add %al, 0x01(%r9,  %rax, 8)
+        _ add %al, 0x01(%r10, %rax, 8)
+        _ add %al, 0x01(%r11, %rax, 8)
+        _ add %al, 0x01(%r12, %rax, 8)
+        _ add %al, 0x01(%r13, %rax, 8)
+        _ add %al, 0x01(%r14, %rax, 8)
+        _ add %al, 0x01(%r15, %rax, 8)
+
+        /* Mod=2, Reg=0, RM=4, SIB S=3, I=0, B {0..f} */
+        _ add %al, 0x7f000001(%rax, %rax, 8)
+        _ add %al, 0x7f000001(%rcx, %rax, 8)
+        _ add %al, 0x7f000001(%rdx, %rax, 8)
+        _ add %al, 0x7f000001(%rbx, %rax, 8)
+        _ add %al, 0x7f000001(%rsp, %rax, 8)
+        _ add %al, 0x7f000001(%rbp, %rax, 8)
+        _ add %al, 0x7f000001(%rsi, %rax, 8)
+        _ add %al, 0x7f000001(%rdi, %rax, 8)
+        _ add %al, 0x7f000001(%r8,  %rax, 8)
+        _ add %al, 0x7f000001(%r9,  %rax, 8)
+        _ add %al, 0x7f000001(%r10, %rax, 8)
+        _ add %al, 0x7f000001(%r11, %rax, 8)
+        _ add %al, 0x7f000001(%r12, %rax, 8)
+        _ add %al, 0x7f000001(%r13, %rax, 8)
+        _ add %al, 0x7f000001(%r14, %rax, 8)
+        _ add %al, 0x7f000001(%r15, %rax, 8)
+
+        /* Mod=0, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */
+        _ add %al, (%rax, %riz, 8)
+        _ add %al, (%rcx, %riz, 8)
+        _ add %al, (%rdx, %riz, 8)
+        _ add %al, (%rbx, %riz, 8)
+        _ add %al, (%rsp, %riz, 8)
+        _ add %al, (    , %riz, 8) /* %rbp encoded with mod=1/2 */
+        _ add %al, (%rsi, %riz, 8)
+        _ add %al, (%rdi, %riz, 8)
+        _ add %al, (%r8,  %riz, 8)
+        _ add %al, (%r9,  %riz, 8)
+        _ add %al, (%r10, %riz, 8)
+        _ add %al, (%r11, %riz, 8)
+        _ add %al, (%r12, %riz, 8)
+        _ rex.b add %al,(,%riz, 8) /* %r13 encoded with mod=1/2 */
+        _ add %al, (%r14, %riz, 8)
+        _ add %al, (%r15, %riz, 8)
+
+        /* Mod=1, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */
+        _ add %al, 0x01(%rax, %riz, 8)
+        _ add %al, 0x01(%rcx, %riz, 8)
+        _ add %al, 0x01(%rdx, %riz, 8)
+        _ add %al, 0x01(%rbx, %riz, 8)
+        _ add %al, 0x01(%rsp, %riz, 8)
+        _ add %al, 0x01(%rbp, %riz, 8)
+        _ add %al, 0x01(%rsi, %riz, 8)
+        _ add %al, 0x01(%rdi, %riz, 8)
+        _ add %al, 0x01(%r8,  %riz, 8)
+        _ add %al, 0x01(%r9,  %riz, 8)
+        _ add %al, 0x01(%r10, %riz, 8)
+        _ add %al, 0x01(%r11, %riz, 8)
+        _ add %al, 0x01(%r12, %riz, 8)
+        _ add %al, 0x01(%r13, %riz, 8)
+        _ add %al, 0x01(%r14, %riz, 8)
+        _ add %al, 0x01(%r15, %riz, 8)
+
+        /* Mod=2, Reg=0, RM=4, SIB S=3, I=4, B {0..f} */
+        _ add %al, 0x7f000001(%rax, %riz, 8)
+        _ add %al, 0x7f000001(%rcx, %riz, 8)
+        _ add %al, 0x7f000001(%rdx, %riz, 8)
+        _ add %al, 0x7f000001(%rbx, %riz, 8)
+        _ add %al, 0x7f000001(%rsp, %riz, 8)
+        _ add %al, 0x7f000001(%rbp, %riz, 8)
+        _ add %al, 0x7f000001(%rsi, %riz, 8)
+        _ add %al, 0x7f000001(%rdi, %riz, 8)
+        _ add %al, 0x7f000001(%r8,  %riz, 8)
+        _ add %al, 0x7f000001(%r9,  %riz, 8)
+        _ add %al, 0x7f000001(%r10, %riz, 8)
+        _ add %al, 0x7f000001(%r11, %riz, 8)
+        _ add %al, 0x7f000001(%r12, %riz, 8)
+        _ add %al, 0x7f000001(%r13, %riz, 8)
+        _ add %al, 0x7f000001(%r14, %riz, 8)
+        _ add %al, 0x7f000001(%r15, %riz, 8)
+
+        .macro alu_ops op
+        _ \op %al, (%rax)
+        _ \op %eax, (%rax)
+        _ \op (%rax), %al
+        _ \op (%rax), %eax
+        _ \op $1, %al
+        _ \op $0x7f000001, %eax
+
+        /* Vary osize on imm fields */
+        _ data16 \op $1, %al
+        _ rex.w \op $1, %al
+        _ data16 rex.w \op $1, %al
+
+        _ \op $0x7f01, %ax
+        _ \op $0x7f000001, %rax
+        _ data16 \op $0x7f000001, %rax
+        .endm
+
+onebyte_row_0x:
+        alu_ops add
+        alu_ops or
+
+onebyte_row_1x:
+        alu_ops adc
+        alu_ops sbb
+
+onebyte_row_2x:
+        alu_ops and
+        .code32
+        _ es nop
+        .code64
+        alu_ops sub
+        _ cs nop
+
+onebyte_row_3x:
+        alu_ops xor
+        .code32
+        _ ss nop
+        .code64
+        alu_ops cmp
+        _ ds nop
+
+/* onebyte_row_4x --> rex prefixes */
+
+onebyte_row_5x:
+        _ push %rax
+        _ push %rcx
+        _ push %rdx
+        _ push %rbx
+        _ push %rsp
+        _ push %rbp
+        _ push %rsi
+        _ push %rdi
+        _ pop %rax
+        _ pop %rcx
+        _ pop %rdx
+        _ pop %rbx
+        _ pop %rsp
+        _ pop %rbp
+        _ pop %rsi
+        _ pop %rdi
+
+onebyte_row_6x:
+        /*pusha,popa,bound --> not supported */
+        _ movsxd (%rax), %eax
+        _ movslq (%rax), %rax
+        _ fs nop
+        _ gs nop
+        _ data16 nop
+        /* addr32 --> not supported */
+        _ pushq $0x7f000001
+        _ pushw $0x7f01
+        _ rex.w pushq $0x7f000001
+        _ imul $0x7f01, %ax, %ax
+        _ imul $0x7f000001, %eax, %eax
+        _ imul $0x7f000001, %rax, %rax
+        _ pushq $0
+        _ pushw $0
+        _ rex.w pushq $0
+        _ imul $0, %ax, %ax
+        _ imul $0, %eax, %eax
+        _ imul $0, %rax, %rax
+        _ insb
+        _ insw
+        _ insl
+        _ outsb
+        _ outsw
+        _ outsl
+
+/* onebyte_row_7x: --> Jcc disp8 */
+
+onebyte_row_8x:
+        _ add $0, %cl /* Grp1 */
+        _ data16 add $0, %cl
+        _ rex.w add $0, %cl
+        _ add $0x7f01, %cx
+        _ add $0x7f000001, %ecx
+        _ add $0x7f000001, %rcx
+        _ add $0, %cx
+        _ add $0, %ecx
+        _ add $0, %rcx
+        _ test %cl, %cl
+        _ test %ecx, %ecx
+        _ xchg %cl, %cl
+        _ xchg %ecx, %ecx
+        _ mov %cl, (%rax)
+        _ mov %ecx, (%rax)
+        _ mov (%rax), %cl
+        _ mov (%rax), %ecx
+        _ mov %cs, (%rax)
+        _ lea (%rax), %eax
+        _ mov (%rax), %cs
+        /*pop mem --> Grp1a, Not supported (XOP prefix adjacent) */
+
+onebyte_row_9x:
+        _ nop
+        _ pause
+        _ xchg %ax, %ax
+        _ xchg %eax, %eax
+        _ xchg %rax, %rax
+        _ rex.w xchg %rax, %rax
+        _ cltq
+        _ cqto
+        _ wait
+        _ pushf
+        _ popf
+        _ sahf
+        _ lahf
+
+onebyte_row_ax:
+        _ mov 0x8000000000000001, %al
+        _ mov 0x8000000000000001, %ax
+        _ mov 0x8000000000000001, %eax
+        _ mov 0x8000000000000001, %rax
+        _ mov %al,  0x8000000000000001
+        _ mov %ax,  0x8000000000000001
+        _ mov %eax, 0x8000000000000001
+        _ mov %rax, 0x8000000000000001
+        _ movsb
+        _ movsl
+        _ cmpsb
+        _ cmpsl
+        _ test $0, %al
+        _ test $0x80000001, %eax
+        _ test $0x7f000001, %rax
+        _ stosb
+        _ stosl
+        _ lodsb
+        _ lodsl
+        _ scasb
+        _ scasl
+
+onebyte_row_bx:
+        _ mov $0, %al
+        _ mov $0, %cl
+        _ mov $0x7f01, %ax
+        _ mov $0x7f01, %cx
+        _ mov $0x7f000001, %eax
+        _ mov $0x7f000001, %ecx
+        _ mov $0x7f00000000000001, %rax
+        _ mov $0x7f00000000000001, %rcx
+
+onebyte_row_cx:
+        _ rol $0, %al /* Grp2 */
+        _ rol $0, %ax
+        _ rol $0, %eax
+        _ rol $0, %rax
+        /*ret $0 --> not supported */
+        _ ret
+        /*les,lds --> not supported */
+        _ movb $0, (%rax) /* Grp11 */
+        _ movw $0, (%rax)
+        _ movl $0, (%rax)
+        _ movq $0, (%rax)
+        /*xbegin (Grp11) --> disp32 */
+        /*enter,leave,lretq $0 --> not supported */
+        _ lretq
+        _ int3
+        _ int $0
+        /*into,iret --> not supported */
+
+onebyte_row_dx:
+        _ rol $1, %al /* Grp2 */
+        _ rol $1, %ax
+        _ rol $1, %eax
+        _ rol $1, %rax
+        _ rol %cl, %al
+        _ rol %cl, %ax
+        _ rol %cl, %eax
+        _ rol %cl, %rax
+        /*aam,aad --> not supported */
+        n "udb" .byte 0xd6
+        /*xlat,d8...df --> not supported */
+
+onebyte_row_ex:
+        /*loop{ne,e,},jrcxz --> not supported */
+        _ in $0, %al
+        _ in $0, %eax
+        _ out %al,  $0
+        _ out %eax, $0
+        /*call,jmp --> disp32 */
+        /*ljmp --> not supported */
+        /*jmp --> disp8 */
+        _ in %dx, %al
+        _ in %dx, %eax
+        _ out %al,  %dx
+        _ out %eax, %dx
+
+onebyte_row_fx:
+        _ lock addb $0, (%rax)
+        n "icebp" .byte 0xf1 /* icebp */
+        _ repne nop
+        _ repe nop
+        _ hlt
+        _ cmc
+        _ test $0, %cl /* Grp3, /0 has extra Imm{8,} */
+        _ not %cl
+        _ test $0x7f01, %cx
+        _ not %cx
+        _ test $0x7f000001, %ecx
+        _ not %ecx
+        _ test $0x7f000001, %rcx
+        _ not %rcx
+        _ clc
+        _ stc
+        _ cli
+        _ sti
+        _ cld
+        _ std
+        _ inc %cl /* Grp4 */
+        _ dec %cl
+        _ inc %ecx /* Grp5 */
+        _ dec %ecx
+        _ call *(%rax)
+        _ lcall *(%rax)
+        _ jmp *(%rax)
+        _ ljmp *(%rax)
+        _ push (%rax)
+
+twobyte_row_0x:
+        _ sldt (%rax) /* Grp6 */
+        _ sgdt (%rax) /* Grp7 */
+        _ lar (%rax), %eax
+        _ lsl (%rax), %eax
+        _ ud2a
+
+twobyte_row_1x:
+        _ prefetchnta (%rax) /* Grp16 (Hint Nop) */
+        _ nopl (%rax)
+
+twobyte_row_2x:
+        _ mov %cr0, %rax
+        _ mov %dr0, %rax
+        _ mov %rax, %cr0
+        _ mov %rax, %dr0
+
+twobyte_row_3x:
+        _ wrmsr
+        _ rdtsc
+        _ rdmsr
+        _ rdpmc
+
+twobyte_row_4x:
+        _ cmovo (%rax), %eax
+        _ cmovg (%rax), %eax
+
+/* twobyte_row_8x: --> Jcc disp32 */
+
+twobyte_row_9x:
+        _ seto (%rax)
+        _ setg (%rax)
+
+twobyte_row_ax:
+        _ push %fs
+        _ pop %fs
+        _ cpuid
+        _ bt %eax, (%rax)
+        _ shld $0, %ax, (%rax)
+        _ shld $0, %eax, (%rax)
+        _ shld $0, %rax, (%rax)
+        _ shld %cl, %ax, (%rax)
+        _ shld %cl, %eax, (%rax)
+        _ shld %cl, %rax, (%rax)
+        _ push %gs
+        _ pop %gs
+        /*rsm --> not supported */
+        _ bts %eax, (%rax)
+        _ shrd $0, %ax, (%rax)
+        _ shrd $0, %eax, (%rax)
+        _ shrd $0, %rax, (%rax)
+        _ shrd %cl, %ax, (%rax)
+        _ shrd %cl, %eax, (%rax)
+        _ shrd %cl, %rax, (%rax)
+        _ fxsave (%rax) /* Grp15 */
+        _ imul (%rax), %eax
+
+twobyte_row_bx:
+        _ cmpxchg %al, (%rax)
+        _ cmpxchg %eax, (%rax)
+        _ lss (%rax), %eax
+        _ btr %eax, (%rax)
+        _ lfs (%rax), %eax
+        _ lgs (%rax), %eax
+        _ movzbl (%rax), %eax
+        _ movzwl (%rax), %eax
+        _ popcnt (%rax), %eax
+        _ ud1 (%rax), %eax /* Grp10 */
+        _ bt $0, %ax /* Grp8 */
+        _ bt $0, %eax
+        _ bt $0, %rax
+        _ btc %eax, (%rax)
+        _ bsf (%rax), %eax
+        _ bsr (%rax), %eax
+        _ movsbl (%rax), %eax
+        _ movswl (%rax), %eax
+
+twobyte_row_cx:
+        _ xadd %al, (%rax)
+        _ xadd %eax, (%rax)
+        _ cmpxchg8b (%rax) /* Grp9 */
+        _ bswap %eax
+        _ bswap %edi
+
+END(tests_rel0)
+
+DECL(tests_rel1)
+disp8:
+1:
+        _ jo   1b
+        _ jno  1b
+        _ jb   1b
+        _ jae  1b
+        _ je   1b
+        _ jne  1b
+        _ jbe  1b
+        _ ja   1b
+        _ js   1b
+        _ jns  1b
+        _ jp   1b
+        _ jnp  1b
+        _ jl   1b
+        _ jge  1b
+        _ jle  1b
+        _ jg   1b
+        _ jmp  1b
+
+disp8_rex:
+        _ rex.w jo   1b
+        _ rex.w jno  1b
+        _ rex.w jb   1b
+        _ rex.w jae  1b
+        _ rex.w je   1b
+        _ rex.w jne  1b
+        _ rex.w jbe  1b
+        _ rex.w ja   1b
+        _ rex.w js   1b
+        _ rex.w jns  1b
+        _ rex.w jp   1b
+        _ rex.w jnp  1b
+        _ rex.w jl   1b
+        _ rex.w jge  1b
+        _ rex.w jle  1b
+        _ rex.w jg   1b
+        _ rex.w jmp  1b
+END(tests_rel1)
+
+DECL(tests_rel4)
+disp32:
+        _ call   other_section
+        _ jmp    other_section
+        _ jo     other_section
+        _ jno    other_section
+        _ jb     other_section
+        _ jae    other_section
+        _ je     other_section
+        _ jne    other_section
+        _ jbe    other_section
+        _ ja     other_section
+        _ js     other_section
+        _ jns    other_section
+        _ jp     other_section
+        _ jnp    other_section
+        _ jl     other_section
+        _ jge    other_section
+        _ jle    other_section
+        _ jg     other_section
+        _ xbegin other_section
+
+disp32_rex:
+        _ rex.w call   other_section
+        _ rex.w jmp    other_section
+        _ rex.w jo     other_section
+        _ rex.w jno    other_section
+        _ rex.w jb     other_section
+        _ rex.w jae    other_section
+        _ rex.w je     other_section
+        _ rex.w jne    other_section
+        _ rex.w jbe    other_section
+        _ rex.w ja     other_section
+        _ rex.w js     other_section
+        _ rex.w jns    other_section
+        _ rex.w jp     other_section
+        _ rex.w jnp    other_section
+        _ rex.w jl     other_section
+        _ rex.w jge    other_section
+        _ rex.w jle    other_section
+        _ rex.w jg     other_section
+        _ rex.w xbegin other_section
+
+riprel:
+        _ add %al, 0(%rip)
+        _ rex.b add %al, 0(%rip)
+
+        _ addb $1, 0(%rip)
+        _ rex.b addb $1, 0(%rip)
+
+        _ addl $0x7f000001, 0(%rip)
+        _ rex.b addl $0x7f000001, 0(%rip)
+END(tests_rel4)
+
+DECL(tests_unsup)
+
+unsup_prefix: /* Prefixes unimplemented for simplicity. */
+        _ vaddpd %zmm0, %zmm0, %zmm0 /* 0x62 EVEX */
+        _ addr32 nop                 /* 0x67 Address size override */
+        _ bextr $0, %eax, %eax       /* 0x8f XOP */
+        _ bextr %eax, %eax, %eax     /* 0xc4 VEX3 */
+        _ vaddpd %ymm0, %ymm0, %ymm0 /* 0xc5 VEX2 */
+        n "jmpabs 0" .byte 0xd5, 0x00, 0xa1, 0x01, 0, 0, 0, 0, 0, 0, 0x80 /* 0xd5 REX2 */
+        _ fadds (%rax)               /* 0xd8 ... 0xdf ESCAPE (x87) */
+        _ femms                      /* 0x0f,0x0e ... 0x0f 3DNOW */
+
+unsup_branch:
+1:
+        _ loopne 1b
+        _ loope  1b
+        _ loop   1b
+        _ jrcxz  1b
+
+opsize_branch: /* 66-prefixed branches are decoded differently by vendors */
+        _ data16 call   other_section
+        _ data16 jmp    other_section
+        _ data16 jo     other_section
+        _ data16 jno    other_section
+        _ data16 jb     other_section
+        _ data16 jae    other_section
+        _ data16 je     other_section
+        _ data16 jne    other_section
+        _ data16 jbe    other_section
+        _ data16 ja     other_section
+        _ data16 js     other_section
+        _ data16 jns    other_section
+        _ data16 jp     other_section
+        _ data16 jnp    other_section
+        _ data16 jl     other_section
+        _ data16 jge    other_section
+        _ data16 jle    other_section
+        _ data16 jg     other_section
+        _ data16 xbegin other_section
+
+not_64bit: /* Not valid/encodable in 64bit mode */
+        .code32
+        _ push %es
+        _ pop %es
+        _ push %cs
+        _ push %ss
+        _ pop %ss
+        _ push %ds
+        _ pop %ds
+        _ daa
+        _ das
+        _ aaa
+        _ aas
+        _ pusha
+        _ popa
+        _ bound %eax, (%eax)
+        /*arpl %ax, %ax --> movsxd in 64bit mode */
+        /* Grp1 */
+        _ lcall $-1, $-1
+        _ les (%eax), %eax
+        _ lds (%eax), %eax
+        _ into
+        _ aam $0
+        _ aad $0 /* Also REX2, also not supported */
+        _ ljmp $-1, $-1
+        .code64
+
+unsup_insn: /* Instructions that would complicated decode, or shouldn't be used */
+        _ ret $0
+        _ enter $0, $0
+        _ leave
+        _ lretq $0
+        _ iretq
+        _ xlat
+        _ clts
+        _ wbinvd
+        _ syscall
+        _ sysretl
+        _ invd
+        _ sysenter
+        _ sysexitl
+        _ rsm
+
+END(tests_unsup)
+
+        /* This is here to cause jmps to use their disp32 form. */
+        .section .text.other_section, "ax", @progbits
+other_section:
+        int3
+
+        /* Mark this file as not needing executable stacks. */
+        .section  .note.GNU-stack, "", @progbits
diff --git a/tools/tests/x86-decode-lite/macro-magic.h b/tools/tests/x86-decode-lite/macro-magic.h
new file mode 100644
index 000000000000..b3c8aae39acd
--- /dev/null
+++ b/tools/tests/x86-decode-lite/macro-magic.h
@@ -0,0 +1,62 @@
+#ifndef X86_DECODE_LITE_LINKAGE_H
+#define X86_DECODE_LITE_LINKAGE_H
+
+#ifdef __i386__
+# define PTR_ALIGN 4
+# define PTR .long
+#else
+# define PTR_ALIGN 8
+# define PTR .quad
+#endif
+
+
+/* Start a 'struct test' array */
+.macro start_arr aname
+    .pushsection .data.rel.ro.\aname, "aw", @progbits
+    .globl \aname
+    .align PTR_ALIGN
+    .type \aname, STT_OBJECT
+\aname:
+    .popsection
+
+    /* Declare a macro wrapping \aname */
+    .macro pushsection_arr
+    .pushsection .data.rel.ro.\aname, "aw", @progbits
+    .endm
+.endm
+
+/* Macro 'n' to wrap the metadata of an instruction.  Name can be different. */
+.macro n name:req insn:vararg
+    /* Emit the instruction, with start & end markers. */
+.Ls\@: \insn
+.Le\@:
+
+    /* Emit \name as a string. */
+    .pushsection .rodata.str1, "aMS", @progbits, 1
+.Ln\@: .asciz "\name"
+    .popsection
+
+    /* Emit an entry into the array. */
+    pushsection_arr
+    PTR .Ln\@, .Ls\@, .Le\@ - .Ls\@
+    .popsection
+.endm
+
+/* Macro '_' where the name is the instruction itself. */
+.macro _ insn:vararg
+    n "\insn" \insn
+.endm
+
+/* Finish a 'struct test' array */
+.macro finish_arr aname
+    pushsection_arr
+    PTR 0, 0, 0
+    .size \aname, . - \aname
+    .popsection
+    .purgem pushsection_arr
+.endm
+
+#define DECL(aname) start_arr aname
+#define END(aname) finish_arr aname
+
+#endif /* X86_DECODE_LITE_LINKAGE_H */
diff --git a/tools/tests/x86-decode-lite/main.c b/tools/tests/x86-decode-lite/main.c
new file mode 100644
index 000000000000..cdae7de8e90e
--- /dev/null
+++ b/tools/tests/x86-decode-lite/main.c
@@ -0,0 +1,111 @@
+/*
+ * Userspace test harness for x86_decode_lite().
+ */
+#include <stdio.h>
+
+#include "x86-emulate.h"
+
+static unsigned int nr_failures;
+#define fail(t, fmt, ...)                                       \
+({                                                              \
+    const unsigned char *insn = (t)->ip;                        \
+                                                                \
+    nr_failures++;                                              \
+                                                                \
+    (void)printf("  Fail '%s' [%02x", (t)->name, *insn);        \
+    for ( unsigned int i = 1; i < (t)->len; i++ )               \
+        printf(" %02x", insn[i]);                               \
+    printf("]\n");                                              \
+                                                                \
+    (void)printf(fmt, ##__VA_ARGS__);                           \
+})
+
+struct test {
+    const char *name;
+    void *ip;
+    unsigned long len;
+};
+
+extern const struct test
+/* Defined in insns.S, ends with sentinel */
+    tests_rel0[], /* No relocatable entry */
+    tests_rel1[], /* disp8 */
+    tests_rel4[], /* disp32 or RIP-relative */
+    tests_unsup[]; /* Unsupported instructions */
+
+static inline void run_tests(const struct test *tests, unsigned int rel_sz)
+{
+    printf("Test rel%u\n", rel_sz);
+
+    for ( unsigned int i = 0; tests[i].name; ++i )
+    {
+        const struct test *t = &tests[i];
+        x86_decode_lite_t r;
+
+        /*
+         * Don't end strictly at t->len.  This provides better diagnostics if
+         * too many bytes end up getting consumed.
+         */
+        r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
+
+        if ( r.len == 0 )
+        {
+            fail(t, "    Failed to decode instruction\n");
+
+            if ( r.rel_sz != 0 || r.rel )
+                fail(t, "    Rel/sz despite no decode\n");
+
+            continue;
+        }
+
+        if ( r.len != t->len )
+        {
+            fail(t, "    Expected length %lu, got %u\n",
+                 t->len, r.len);
+            continue;
+        }
+
+        if ( r.rel_sz != rel_sz )
+        {
+            fail(t, "    Expected relocation size %u, got %u\n",
+                 rel_sz, r.rel_sz);
+            continue;
+        }
+
+        if ( r.rel_sz &&
+             (r.rel < t->ip ||
+              r.rel > t->ip + t->len ||
+              r.rel + r.rel_sz > t->ip + t->len) )
+        {
+            fail(t, "    Rel [%p,+%u) outside insn [%p,+%lu)\n",
+                 r.rel, r.rel_sz, t->ip, t->len);
+            continue;
+        }
+    }
+}
+
+static void run_tests_unsup(const struct test *tests)
+{
+    printf("Test unsup\n");
+
+    for ( unsigned int i = 0; tests[i].name; ++i )
+    {
+        const struct test *t = &tests[i];
+        x86_decode_lite_t r = x86_decode_lite(t->ip, t->ip + t->len);
+
+        if ( r.len )
+            fail(t, "    Got len %u\n", r.len);
+    }
+}
+
+int main(int argc, char **argv)
+{
+    printf("Tests for x86_decode_lite()\n");
+
+    run_tests(tests_rel0, 0);
+    run_tests(tests_rel1, 1);
+    run_tests(tests_rel4, 4);
+    run_tests_unsup(tests_unsup);
+
+    return !!nr_failures;
+}
diff --git a/tools/tests/x86-decode-lite/x86-emulate.h b/tools/tests/x86-decode-lite/x86-emulate.h
new file mode 100644
index 000000000000..558dab1b768e
--- /dev/null
+++ b/tools/tests/x86-decode-lite/x86-emulate.h
@@ -0,0 +1,27 @@
+#ifndef X86_EMULATE_H
+#define X86_EMULATE_H
+
+#include <assert.h>
+#include <stdbool.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include <xen/asm/x86-defns.h>
+#include <xen/asm/x86-vendors.h>
+
+#include <xen-tools/common-macros.h>
+
+#define ASSERT assert
+
+#define printk(...)
+
+#define likely
+#define unlikely
+#define cf_check
+#define init_or_livepatch
+#define init_or_livepatch_const
+
+#include "x86_emulate/x86_emulate.h"
+
+#endif /* X86_EMULATE_H */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:20:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381226.1624795 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy7-0001zI-Ld; Mon, 03 Aug 2026 07:20:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381226.1624795; Mon, 03 Aug 2026 07:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy7-0001yY-Fr; Mon, 03 Aug 2026 07:20:15 +0000
Received: by outflank-mailman (input) for mailman id 1381226;
 Mon, 03 Aug 2026 07:20:14 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqmy6-0001jl-7i
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:20:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmy5-003y8B-Km
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:20:13 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a704126-bab6-0a2a0a5309dd-0a2a4503b0a8-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:13 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70412d-fae8-0a2a45030019-d1558034ac3f-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:13 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-495590dde14so16957645e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:20:13 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm254687935e9.2.2026.08.03.00.20.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 00:20:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785741613; x=1786346413; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=9oalEqncjdi9YKb26F6ASg1uy+nWQGozZLeLwjudyuk=;
        b=nXQToXflDY+GL0UfpGRRGa/mTaF3lJrALlJSTIj5pJJp4E1rr6etPaNvXifQYZvDBO
         pkleLegLT8CnonqfpLkYcpZ3BYoQQ3EFuN34omNUNeG+Y5tmArhhQJK3pdcuB9dBy3L4
         +azacdKjGK6mWIgxSvTdUkTfG8dprXzaxbA68=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741613; x=1786346413;
        h=content-transfer-encoding:content-type: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=9oalEqncjdi9YKb26F6ASg1uy+nWQGozZLeLwjudyuk=;
        b=Zv8366P381RA65Bu5vAzw4Il85qRvCGOqGNyPNtZkvJpgpq43aAHWyCAQliUVh7Sni
         YhuD16OLAXaeRfYXpJi0WlHj5uEII/ygZUp1DHoLVNS6wghot1QdjuwMBsyplwpM0kgN
         M29Qy6JRAGGX1Pi8/368UmaJWjVbbi2ubMFYf5qjmQO1J7C+25y1V5t8LIpKLPB1CM67
         Pnl1phN59vpfq1tJG4Jp0c7AqOi5XP9s+zwRNbMjg7RvlncvVMw6/s5XcZl1LZC8v8/q
         ceCqrxrgLygKwebPjFK50VNJ1l/wyBgbZarSJuzjsqs9MBosPpPBA/2PS9tJQA/ypPUs
         akdA==
X-Gm-Message-State: AOJu0YzSPvBBCyMuGX1etuv3N23UqWGaEigdgUPhjLFOZJtarKJlcbzU
	fUZ2PaFfwGFX5fsuvo+wVHoAIUA3KCVSupudGZ2/QcBLdMCOieX4bswIWmrjFoOs0FSle6jwI19
	+v+lU9mU=
X-Gm-Gg: AR+sD10/X+cB1tbPIjI8aiP1eTsAzEY3/BzenZ9AV72bJ1wgtMyHZVOczP9RDOrDQAN
	ax36zRNRYhL9SqJHYBXWhav8es2hzVk/znrlrEAFM7zy8Sw3C7FXLZZGPojNfH+U9r7LiroTH5c
	wKKXG/zlJnpEUHcDMpyY51xK7H+QBF6qE9HBSIumuLQzPdlzY2xnf55iiR2dWIwZawYr6rB9t4v
	EKOyTOqXUdwIt0kProMIrml0/8I+PFQHnnQvk7+lY2BJnX0u80CQoAANrW3D/RhvDtPXcmPxwDh
	YJG3Lr0O8OT4Q3O92DQ5iPWh53IMktsSYudVBrLNQbF3PB2wY5KB2Oqt7NO0z0uvsPMmGREsBm8
	aMvSkIys8v6Wokhkg+FXr9n2h9IElM29EAzp0/ZA1pBzFrdldTsNy14ERprdhrJNd673UREg5JM
	bu/JJu0emVB0hNZ5RbGz0SrVexZ6Uh2I7iNPfwrEu8ExeirnES+Bj6LP1Cfx5Ph2bFrPYSD3qyY
	Yla8wm7LLmkxbPTq0E53vKIvTaKeqQ/o+FghKo=
X-Received: by 2002:a05:600c:4685:b0:493:e365:7630 with SMTP id 5b1f17b1804b1-4980eb66053mr147150085e9.14.1785741612890;
        Mon, 03 Aug 2026 00:20:12 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v3 3/5] x86/alternative: Walk all replacements during self tests
Date: Mon,  3 Aug 2026 08:20:04 +0100
Message-Id: <20260803072006.9678-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803072006.9678-1-andrew.cooper3@citrix.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785741613-758824E9-8A49664C/0/0
X-purgate-type: clean
X-purgate-size: 2998

When self tests are active, walk all alternative replacements with
x86_decode_lite().

This checks that we can decode all instructions, and also lets us check that
disp8's don't leave the replacement block as such a case will definitely
malfunction.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

v2:
 * Rebase over API changes in patch 1
 * Use +%lu and drop casts
 * Swap to CONFIG_SELF_TESTS
---
 xen/arch/x86/alternative.c | 52 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 5ed0c2672589..fd03147bdd12 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -16,6 +16,7 @@
 #include <asm/traps.h>
 #include <asm/nmi.h>
 #include <asm/nops.h>
+#include <asm/x86_emulate.h>
 #include <xen/livepatch.h>
 
 #define MAX_PATCH_LEN (255-1)
@@ -586,6 +587,57 @@ static void __init _alternative_instructions(unsigned int what)
 void __init alternative_instructions(void)
 {
     arch_init_ideal_nops();
+
+    /*
+     * Walk all replacement instructions with x86_decode_lite().  This checks
+     * both that we can decode all instructions within the replacement, and
+     * that any near branch with a disp8 stays within the alternative itself.
+     */
+    if ( IS_ENABLED(CONFIG_SELF_TESTS) )
+    {
+        struct alt_instr *a;
+
+        for ( a = __alt_instructions;
+              a < __alt_instructions_end; ++a )
+        {
+            void *repl = ALT_REPL_PTR(a);
+            void *ip = repl, *end = ip + a->repl_len;
+
+            if ( !a->repl_len )
+                continue;
+
+            for ( x86_decode_lite_t res; ip < end; ip += res.len )
+            {
+                const int8_t *d8;
+                const void *target;
+
+                res = x86_decode_lite(ip, end);
+
+                if ( res.len == 0 )
+                {
+                    printk("Alt for %ps [%*ph]\n",
+                           ALT_ORIG_PTR(a), a->repl_len, repl);
+                    panic("  Unable to decode instruction at +%lu in alternative\n",
+                          ip - repl);
+                }
+
+                if ( res.rel_sz != 1 )
+                    continue;
+
+                d8 = res.rel;
+                target = ip + res.len + *d8;
+
+                if ( target < repl || target > end )
+                {
+                    printk("Alt for %ps [%*ph]\n",
+                           ALT_ORIG_PTR(a), a->repl_len, repl);
+                    panic("  'JMP/Jcc disp8' at +%lu leaves alternative block\n",
+                          ip - repl);
+                }
+            }
+        }
+    }
+
     _alternative_instructions(ALT_INSNS);
 }
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:20:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381228.1624812 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy8-0002KN-OB; Mon, 03 Aug 2026 07:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381228.1624812; Mon, 03 Aug 2026 07:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy8-0002Jr-F9; Mon, 03 Aug 2026 07:20:16 +0000
Received: by outflank-mailman (input) for mailman id 1381228;
 Mon, 03 Aug 2026 07:20:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqmy7-0001uR-3K
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:20:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmy6-00Dk99-GY
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:20:14 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70412d-5cb7-0a2a0a5109dd-0a2a45088d92-8
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:14 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70412e-f659-0a2a45080019-d155dd2ed828-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:14 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47fd4ee0b01so1842141f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:20:14 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm254687935e9.2.2026.08.03.00.20.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 00:20:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785741614; x=1786346414; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=HxkChm6nTI+5JRyuyWipeFtEAkEUxs5crJhjhmOkg8A=;
        b=mtnOI27/DhL8W/LMMi5Pb25C2MuCzmwBVCnj/1A8w/74wMnlI9QJRLIKuWjdOtDNWZ
         TpvdMA1Ym0MHFBtW/rvUl1SxJa5nIx2tiF9ekqXmp+mZIuFhlyTZBZyJJ1BWyX9oi8Yj
         wQcnOdcJPyUdtCM6FuvQqaxMyPWf68EcwkkfU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741614; x=1786346414;
        h=content-transfer-encoding:content-type: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=HxkChm6nTI+5JRyuyWipeFtEAkEUxs5crJhjhmOkg8A=;
        b=XLy0A+Sd02KCgevNr01X8f4FkldYQoAQvhHMiiOlvz6OHzk99IBKBu8Ib6kr66StV5
         fvi6L1Rm2DCLt6LBciNRjHDrUDo4Gehe3pE2vuH7u5Ls4t1KZgPHv/LvC+fTrb7NIRmC
         wsMyiA+rCPEEEvMSmt3NvUCgwpeeLh7cvM89MfjKaMMnr4G4eEV4ipHICx9PEpc/Se0Y
         ft8Cp+1JrqA9SP/3QyiEI73PQdHi1uTuWlgEVj8b45huy/6aiDDFn+dZC6aa0hXkK7K1
         SnxDP5QbBtoNQye4Co5lA52i13hpP1uN4o1Cx5u9dJyD3vZVGEl69F9tgRjF83fdBIut
         WjJw==
X-Gm-Message-State: AOJu0Yy9hUPVbCXrQ0JISwRLcwanYAyCQ+G//JOXwCS/FzVeucm3m2j/
	nH7m90Qo4Lol2bzs8ToPU8KYfUeGEEvRKLRK8k0cBiYutqKarrhTlp7/hS50KEXOsGlRn2wE6PR
	a0X77oYA=
X-Gm-Gg: AR+sD1152/KSo7BQDIqyw2hsgFwZNFwjeI5l3md4uiwfYhmfk7hNODRRRPWcZ/4JLRP
	oqhvwub9Dkbhs6aCJNoRYb/4zjM3xUCzfVaWDOVXXTESxN4byi7vkhus6yTU9ZleAFwjGEhtQQw
	v6Z0R+caXC/Xlw7Iwb1lqed/TfDxqp5p9HGH6mscr9zgKKTGK5hzN6/llgWbBLOmPbCTRU8mWF6
	QBATqGZJgIaHqtt2gcXxI9mncRNGqmO2MqRxb/P0sueUlVXdIztt+3FT1JRo0rwbx9czoVGnEft
	2+1vDXHvV5fqy1ArgaophwS4tEDvMU9bDt7elWIesCCIlvaHSiZvol2bduFQpHM6yqxLhYQHSS+
	TpSSc4XF2fj9mu7MyS15V2jrvk2RAF5OhW48cYPhpMVS6s6e+S/uUSR0BvR23mYYTPTOU5uDnEp
	+N9z693E4LMo2glLveZi7aZR4+JsHd7fpJUiqln24rrFz0yOTYaAlwGgw36C6gUtebyDIxElbPJ
	3Fd8OhPnBtQRbeqIhJeNrQuBaOD/eSXSC77WBs=
X-Received: by 2002:a05:600d:640f:20b0:495:503f:cf9a with SMTP id 5b1f17b1804b1-4980c672adbmr145404915e9.9.1785741613604;
        Mon, 03 Aug 2026 00:20:13 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v3 4/5] x86/alternative: Relocate all insn-relative fields
Date: Mon,  3 Aug 2026 08:20:05 +0100
Message-Id: <20260803072006.9678-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803072006.9678-1-andrew.cooper3@citrix.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785741614-CD54C87B-DC0C22F6/0/0
X-purgate-type: clean
X-purgate-size: 3035

Right now, relocation of displacements is restricted to finding 0xe8/e9 as the
first byte of the replacement, but this is overly restrictive.

Use x86_decode_lite() to find and adjust all insn-relative fields.

As with disp8's not leaving the replacemnet block, some disp32's don't either.
e.g. the RSB stuffing loop.  These stay unmodified.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

v3:
 * Rebase over the split-out of altcall.  Substantially simpler.
---
 xen/arch/x86/alternative.c | 50 +++++++++++++++++++++++++++++++-------
 1 file changed, 41 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index fd03147bdd12..a4a65597b2fc 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -349,15 +349,47 @@ static int init_or_livepatch _apply_alternatives(struct alt_instr *start,
 
         memcpy(buf, repl, a->repl_len);
 
-        /* 0xe8/0xe9 are relative branches; fix the offset. */
-        if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
-            *(int32_t *)(buf + 1) += repl - orig;
-        else if ( IS_ENABLED(CONFIG_RETURN_THUNK) &&
-                  a->repl_len > 5 && buf[a->repl_len - 5] == 0xe9 &&
-                  ((long)repl + a->repl_len +
-                   *(int32_t *)(buf + a->repl_len - 4) ==
-                   (long)__x86_return_thunk) )
-            *(int32_t *)(buf + a->repl_len - 4) += repl - orig;
+        /*
+         * Walk buf[] and adjust any insn-relative operands which leave the
+         * replacement block.
+         */
+        if ( a->repl_len )
+        {
+            uint8_t *ip = buf, *repl_end = ip + a->repl_len;
+
+            for ( x86_decode_lite_t res; ip < repl_end; ip += res.len )
+            {
+                int32_t *d32;
+                const uint8_t *target;
+
+                res = x86_decode_lite(ip, repl_end);
+
+                if ( res.len == 0 )
+                {
+                    printk("Alt for %ps [%*ph]\n"
+                           "  Unable to decode instruction at +%lu in alternative\n",
+                           ALT_ORIG_PTR(a), a->repl_len, repl, ip - repl);
+                    return -EINVAL;
+                }
+
+                if ( res.rel_sz != 4 )
+                    continue;
+
+                d32 = res.rel;
+                target = ip + res.len + *d32;
+
+                if ( target >= buf && target <= repl_end )
+                {
+                    /*
+                     * Target doesn't leave the replacement block.  e.g. RSB
+                     * stuffing.  Leave it unmodified.
+                     */
+                    continue;
+                }
+
+                *d32 += repl - orig;
+            }
+        }
 
         a->priv = 1;
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:20:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381225.1624789 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy7-0001wj-C9; Mon, 03 Aug 2026 07:20:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381225.1624789; Mon, 03 Aug 2026 07:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy7-0001wb-9I; Mon, 03 Aug 2026 07:20:15 +0000
Received: by outflank-mailman (input) for mailman id 1381225;
 Mon, 03 Aug 2026 07:20:14 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqmy5-0001jf-Q6
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:20:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmy5-001lnU-6i
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:20:13 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70411b-2eae-0a2a0a5409dd-0a2a4509eaca-46
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:13 +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 <andrew.cooper3@citrix.com>)
 id 6a70412c-be1a-0a2a45090019-d1558036d87d-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:12 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-496b7622a83so10889715e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:20:12 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm254687935e9.2.2026.08.03.00.20.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 00:20:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785741612; x=1786346412; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=ub/V0kRy79kgAjDqq6A4lupnXHVPDMBJb38IyKztucA=;
        b=m/LZlSJ73th47EW3aq+8u7uO4RvAinRPHAuSrcmRmu/VIojsArSoAzHjkOkq+woFyb
         bxzaZjEWUUgNl0UDJx9WAwo04WZ2zWpYjz+CPWH+RuEjXUeBAyQvLHnURVTdVuiFYJ9+
         iUyhdT7kCCT9n4MEBMGLzTtxr++iPB67FZmaU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741612; x=1786346412;
        h=content-transfer-encoding:content-type: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=ub/V0kRy79kgAjDqq6A4lupnXHVPDMBJb38IyKztucA=;
        b=G7N9oMEKzwoxTXakgiFH+y3bXAu6dZbMLbW3LqaIUJUARQm53445XXYSp/VVrnAB8p
         7tVs4sYR83X9/oPCDBWdplFEpv6fxoVOAQdXFF+2HnH6KnnszWgafAFYA7+FUWAYK6ZP
         in6i+1NdCxToL3tMc2gQ72eiobPATjRRFDMLdRqp7uBVyC7jlxEjfxJp3B81BcRm3hJO
         OlMoVfRY2bm52UmpLuCID1Jx5tOcbxw4Orc87eouuCJSo8Vwx5z0h6Wy3EvIzHGIGM+V
         mcjgn6TjxuU+/ga8PmzfEZrfLB3iExlJ3EVwHkl7uO7UpQiCEJQOHG81EL4Oau8YxkVO
         1nzw==
X-Gm-Message-State: AOJu0YxSsbC62vZxHBECrOAZZ94UXEdxQUMX/y0H7uX0HWjAdVHIgwA3
	HdmmU7Ul/0t0baoUIK9QUv5Vlg9BFLB42dd3kc5FfLe24LMwZX+rCL51HNaK0Fzvl3taDo8GQYh
	3ppEq
X-Gm-Gg: AR+sD11ScO9Q6cCqHtxDNsg+20OL1sYXYsUc41L55IVxh4O5b05G+jolDSUmZg61dRR
	6ay9VnXYPLJN9cMI2DvsSjrtyF4V/Peoeny7lnyWr9XhUQfkHtsIoDfgk9dP/+Ia8X6sfAz87Lv
	cWPFp+dbKcMi+IJoqeKmG7enkqJIfGCFSF5pwAvHQfRE2qjkq9Bm74S1Jg6483q8kJgr/lKWCyp
	yeILcsX3fHDgW1QrYqwBF4IM4gZ3TTy2p7WSm2FudbSTQmApDVbyaS4c6jPJUrBClNKe1qx/LLZ
	x5xuN/QBNp9/L35lOECIXgVLFi8BzcCj03Peuunh+jY2A5LnP761VzRecaVyFLf1Hmc9/pc8Y7P
	wStYONuZsFlnFAT7KGXyY9aZ8qtk96orKyFUhVQcL8bJDsIffG2eEiBVa/5eSKi2KMBq6E6CzIf
	t9ihKPqGIY6pS9bdo8PK9qwOgt39St0Vd4JBcDDMth4ZIlSr0fWX3W2ERC5FRlU6JqpfWDEaodW
	nfOlq1HdE7H0R+AiwUHtGt6RPardryfnxUA6CANBdJgbG9C5g==
X-Received: by 2002:a05:600c:19cf:b0:498:2b1f:e0c6 with SMTP id 5b1f17b1804b1-4982b1fe255mr23440215e9.18.1785741611381;
        Mon, 03 Aug 2026 00:20:11 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v3 1/5] x86/emul: Introduce x86_decode_lite()
Date: Mon,  3 Aug 2026 08:20:02 +0100
Message-Id: <20260803072006.9678-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803072006.9678-1-andrew.cooper3@citrix.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785741612-3B4D3034-D2B7BA1C/0/0
X-purgate-type: clean
X-purgate-size: 14873

In order to relocate all IP-relative fields in an alternative replacement
block, we need to decode the instructions enough to obtain their length and
any relative fields.

Full x86_decode() is far too heavyweight, so introduce a minimal form which
can make several simplifying assumptions.

This a mostly-complete decoder for integer instruction in the onebyte and
twobyte maps.  Some instructions are intentionally unrecognised, as finding
them in an alternative is more likely to be a bug than intentional.  Some
instruction groups and prefixes are unimplemented to reduce decode complexity.

This logic can decode all alternative blocks that exist in Xen right now.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

v3:
 * Rearrange decode tables to satisfy comment requests without splitting
 * Recognise UDB now it's used by Xen
 * Fix MISRA violations
 * Misc other changes

v2:
 * Switch to 0 on failure, rel_sz in bytes
 * Mostly complete the integer instructions; paird with userspace harness
 * Put in .init when !CONFIG_LIVEPATCH
---
 xen/arch/x86/x86_emulate/Makefile      |   6 +
 xen/arch/x86/x86_emulate/decode-lite.c | 330 +++++++++++++++++++++++++
 xen/arch/x86/x86_emulate/x86_emulate.h |  14 ++
 3 files changed, 350 insertions(+)
 create mode 100644 xen/arch/x86/x86_emulate/decode-lite.c

diff --git a/xen/arch/x86/x86_emulate/Makefile b/xen/arch/x86/x86_emulate/Makefile
index 295e602f6b86..679bddbb1584 100644
--- a/xen/arch/x86/x86_emulate/Makefile
+++ b/xen/arch/x86/x86_emulate/Makefile
@@ -17,3 +17,9 @@ obj-y += decode.o
 obj-$(CONFIG_HVM) += fpu.o
 obj-y += util.o
 obj-y += util-xen.o
+
+ifeq ($(CONFIG_LIVEPATCH),y)
+obj-y += decode-lite.o
+else
+obj-bin-y += decode-lite.init.o
+endif
diff --git a/xen/arch/x86/x86_emulate/decode-lite.c b/xen/arch/x86/x86_emulate/decode-lite.c
new file mode 100644
index 000000000000..131cc07d5516
--- /dev/null
+++ b/xen/arch/x86/x86_emulate/decode-lite.c
@@ -0,0 +1,330 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifdef __XEN__
+# include <xen/init.h>
+# include <xen/livepatch.h>
+#endif
+
+#include "private.h"
+
+#undef ModRM
+
+/*
+ * Bare minimum x86 instruction decoder to parse the alternative replacement
+ * instructions and locate the IP-relative references that may need updating.
+ *
+ * These are:
+ *  - disp8/32 from near direct branches
+ *  - RIP-relative memory references
+ *
+ * The following simplifications are used:
+ *  - All code is 64bit, the instruction stream is well formed and safe to
+ *    read.
+ *  - Instruction groups and prefixes not used by Xen's current alternatives
+ *    are not implemented in order to reduce the decode complexity.
+ *  - Certain instructions are intentionally not recognised, when it is more
+ *    likely for their presence to be an error than intentional.
+ *
+ * Inputs:
+ *  @ip  The position to start decoding from.
+ *  @end End of the replacement block.  Exceeding this is considered an error.
+ *
+ * Returns: x86_decode_lite_t
+ *  - On failure, length of 0.
+ *  - On success, length > 0.  For rel_sz > 0, rel points at the relative
+ *    field in the instruction stream.
+ */
+x86_decode_lite_t init_or_livepatch x86_decode_lite(void *ip, void *end)
+{
+#define Imm8   (1 << 0)
+#define Imm    (1 << 1)
+#define Moffs  (1 << 2)
+#define Branch (1 << 5) /* Near direct branches, which have a displacement */
+#define ModRM  (1 << 6)
+#define Known  (1 << 7)
+
+    static const uint8_t init_or_livepatch_const onebyte[256] = {
+
+#define ALU_OPS(x)                              \
+        [(x) + 0] = (Known|ModRM),              \
+        [(x) + 1] = (Known|ModRM),              \
+        [(x) + 2] = (Known|ModRM),              \
+        [(x) + 3] = (Known|ModRM),              \
+        [(x) + 4] = (Known|Imm8),               \
+        [(x) + 5] = (Known|Imm)
+
+        ALU_OPS(0x00) /* ADD */, ALU_OPS(0x08) /* OR  */,
+        ALU_OPS(0x10) /* ADC */, ALU_OPS(0x18) /* SBB */,
+        ALU_OPS(0x20) /* AND */, ALU_OPS(0x28) /* SUB */,
+        ALU_OPS(0x30) /* XOR */, ALU_OPS(0x38) /* CMP */,
+
+#undef ALU_OPS
+
+        [0x50 ... 0x5f] = (Known),             /* PUSH/POP %reg */
+
+        [0x62]          = 0,                   /* BOUND, but also EVEX prefix, not implemented. */
+        [0x63]          = (Known|ModRM),       /* MOVSxd */
+
+        [0x68]          = (Known|Imm),         /* PUSH $imm */
+        [0x69]          = (Known|ModRM|Imm),   /* IMUL $imm */
+        [0x6a]          = (Known|Imm8),        /* PUSH $imm8 */
+        [0x6b]          = (Known|ModRM|Imm8),  /* PUSH $imm8 */
+        [0x6c ... 0x6f] = (Known),             /* INS/OUTS */
+        [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */
+        [0x80]          = (Known|ModRM|Imm8),  /* Grp1 */
+        [0x81]          = (Known|ModRM|Imm),   /* Grp1 */
+
+        [0x83]          = (Known|ModRM|Imm8),  /* Grp1 */
+        [0x84 ... 0x8e] = (Known|ModRM),       /* TEST/XCHG/MOV/MOV-SREG/LEA */
+        [0x8f]          = 0,                   /* Grp1A - POP but also XOP prefix, not implemented. */
+        [0x90 ... 0x99] = (Known),             /* NOP/XCHG %rAX/CLTQ/CQTO */
+
+        [0x9b ... 0x9f] = (Known),             /* FWAIT/PUSHF/POPF/SAHF/LAHF */
+        [0xa0 ... 0xa3] = (Known|Moffs),       /* MOVABS */
+        [0xa4 ... 0xa7] = (Known),             /* MOVS/CMPS */
+        [0xa8]          = (Known|Imm8),        /* TEST %al */
+        [0xa9]          = (Known|Imm),         /* TEST %rAX */
+        [0xaa ... 0xaf] = (Known),             /* STOS/LODS/SCAS */
+        [0xb0 ... 0xb7] = (Known|Imm8),        /* MOV $imm8, %reg */
+        [0xb8 ... 0xbf] = (Known|Imm),         /* MOV $imm{16,32,64}, %reg */
+        [0xc0 ... 0xc1] = (Known|ModRM|Imm8),  /* Grp2 (ROL..SAR $imm8, %reg) */
+
+        [0xc3]          = (Known),             /* RET */
+        [0xc4 ... 0xc5] = 0,                   /* LES/LDS but also VEX prefixes, not implemented. */
+        [0xc6]          = (Known|ModRM|Imm8),  /* Grp11, Further ModRM decode */
+        [0xc7]          = (Known|ModRM|Imm),   /* Grp11, Further ModRM decode */
+
+        [0xcb ... 0xcc] = (Known),             /* LRET/INT3 */
+        [0xcd]          = (Known|Imm8),        /* INT $imm8 */
+
+        [0xd0 ... 0xd3] = (Known|ModRM),       /* Grp2 (ROL..SAR {$1,%cl}, %reg) */
+
+        [0xd6]          = (Known),             /* UDB */
+
+        [0xe4 ... 0xe7] = (Known|Imm8),        /* IN/OUT $imm8 */
+        [0xe8 ... 0xe9] = (Known|Branch|Imm),  /* CALL/JMP disp32 */
+
+        [0xeb]          = (Known|Branch|Imm8), /* JMP disp8 */
+        [0xec ... 0xef] = (Known),             /* IN/OUT %dx */
+
+        [0xf1]          = (Known),             /* ICEBP */
+
+        [0xf4]          = (Known),             /* HLT */
+        [0xf5]          = (Known),             /* CMC */
+        [0xf6 ... 0xf7] = (Known|ModRM),       /* Grp3, Further ModRM decode */
+        [0xf8 ... 0xfd] = (Known),             /* CLC ... STD */
+        [0xfe ... 0xff] = (Known|ModRM),       /* Grp4 */
+    };
+    static const uint8_t init_or_livepatch_const twobyte[256] = {
+        [0x00 ... 0x03] = (Known|ModRM),       /* Grp6/Grp7/LAR/LSL */
+
+        [0x0b]          = (Known),             /* UD2 */
+
+        [0x18 ... 0x1f] = (Known|ModRM),       /* Grp16 (Hint Nop) */
+        [0x20 ... 0x23] = (Known|ModRM),       /* MOV %cr/%dr */
+
+        [0x30 ... 0x33] = (Known),             /* WRMSR/RDTSC/RDMSR/RDPMC */
+
+        [0x40 ... 0x4f] = (Known|ModRM),       /* CMOVcc */
+
+        [0x80 ... 0x8f] = (Known|Branch|Imm),  /* Jcc disp32 */
+        [0x90 ... 0x9f] = (Known|ModRM),       /* SETcc */
+
+        [0xa0 ... 0xa2] = (Known),             /* PUSH/POP %fs/CPUID */
+        [0xa3]          = (Known|ModRM),       /* BT */
+        [0xa4]          = (Known|ModRM|Imm8),  /* SHLD $imm8 */
+        [0xa5]          = (Known|ModRM),       /* SHLD %cl */
+
+        [0xa8 ... 0xa9] = (Known),             /* PUSH/POP %gs */
+
+        [0xab]          = (Known|ModRM),       /* BTS */
+        [0xac]          = (Known|ModRM|Imm8),  /* SHRD $imm8 */
+        [0xad ... 0xaf] = (Known|ModRM),       /* SHRD %cl/Grp15/IMUL */
+
+        [0xb0 ... 0xb9] = (Known|ModRM),       /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */
+        [0xba]          = (Known|ModRM|Imm8),  /* Grp8 */
+        [0xbb ... 0xbf] = (Known|ModRM),       /* BTC/BSF/BSR/MOVSX */
+        [0xc0 ... 0xc1] = (Known|ModRM),       /* XADD */
+        [0xc7]          = (Known|ModRM),       /* Grp9 */
+        [0xc8 ... 0xcf] = (Known),             /* BSWAP */
+    };
+
+    void *start = ip, *rel = NULL;
+    unsigned int opc, rel_sz = 0;
+    uint8_t b, d, rex = 0, osize = 4;
+
+#define OPC_TWOBYTE (1 << 8)
+
+    /* Mutates IP, uses END. */
+#define FETCH(ty)                                       \
+    ({                                                  \
+        ty _val;                                        \
+                                                        \
+        if ( (ip + sizeof(ty)) > end )                  \
+            goto overrun;                               \
+        _val = *(ty *)ip;                               \
+        ip += sizeof(ty);                               \
+        _val;                                           \
+    })
+
+    for ( ;; ) /* Prefixes */
+    {
+        switch ( b = FETCH(uint8_t) )
+        {
+        case 0x26: /* ES override */
+        case 0x2e: /* CS override */
+        case 0x36: /* DS override */
+        case 0x3e: /* SS override */
+        case 0x64: /* FS override */
+        case 0x65: /* GS override */
+        case 0xf0: /* LOCK */
+        case 0xf2: /* REPNE */
+        case 0xf3: /* REP */
+            break;
+
+        case 0x66: /* Operand size override */
+            osize = 2;
+            break;
+
+        /* case 0x67: Address size override, not implemented */
+
+        case 0x40 ... 0x4f: /* REX */
+            rex = b;
+            continue;
+
+        default:
+            goto prefixes_done;
+        }
+        rex = 0; /* REX cancelled by subsequent legacy prefix. */
+    }
+ prefixes_done:
+
+    if ( rex & REX_W )
+        osize = 8;
+
+    /* Fetch the main opcode byte(s) */
+    if ( b == 0x0f )
+    {
+        b = FETCH(uint8_t);
+        opc = OPC_TWOBYTE | b;
+
+        d = twobyte[b];
+    }
+    else
+    {
+        opc = b;
+        d = onebyte[b];
+    }
+
+    if ( unlikely(!(d & Known)) )
+        goto unknown;
+
+    if ( d & ModRM )
+    {
+        uint8_t modrm = FETCH(uint8_t);
+        uint8_t mod = modrm >> 6;
+        uint8_t reg = (modrm >> 3) & 7;
+        uint8_t rm = modrm & 7;
+
+        /* ModRM/SIB decode */
+        if ( mod == 0 && rm == 5 ) /* RIP relative */
+        {
+            rel = ip;
+            rel_sz = 4;
+            FETCH(int32_t);
+        }
+        else if ( mod != 3 && rm == 4 ) /* SIB */
+        {
+            uint8_t sib = FETCH(uint8_t);
+            uint8_t base = sib & 7;
+
+            if ( mod == 0 && base == 5 )
+                goto disp32;
+        }
+
+        if ( mod == 1 ) /* disp8 */
+            FETCH(int8_t);
+        else if ( mod == 2 ) /* disp32 */
+        {
+        disp32:
+            FETCH(int32_t);
+        }
+
+        /* ModRM based decode adjustements */
+        switch ( opc )
+        {
+        case 0xc7: /* Grp11 XBEGIN is a near direct branch. */
+            if ( modrm == 0xf8 )
+                d |= Branch;
+            break;
+
+        case 0xf6: /* Grp3 TEST(s) have extra Imm8 */
+            if ( reg == 0 || reg == 1 )
+                d |= Imm8;
+            break;
+
+        case 0xf7: /* Grp3 TEST(s) have extra Imm */
+            if ( reg == 0 || reg == 1 )
+                d |= Imm;
+            break;
+        }
+    }
+
+    if ( d & Branch )
+    {
+        /*
+         * We don't tolerate 66-prefixed call/jmp in alternatives.  Some are
+         * genuinely decoded differently between Intel and AMD CPUs.
+         *
+         * We also don't implement APX instructions, so don't have to cope
+         * with JMPABS which is the first branch to have an 8-byte immediate.
+         */
+        if ( osize < 4 )
+            goto bad_osize;
+
+        rel = ip;
+        rel_sz = (d & Imm8) ? 1 : 4;
+    }
+
+    if ( d & (Imm | Imm8 | Moffs) )
+    {
+        if ( d & Imm8 )
+            osize = 1;
+        else if ( d & Moffs )
+            osize = 8;
+        else if ( osize == 8 && !(opc >= 0xb8 && opc <= 0xbf) )
+            osize = 4;
+
+        switch ( osize )
+        {
+        case 1: FETCH(uint8_t);  break;
+        case 2: FETCH(uint16_t); break;
+        case 4: FETCH(uint32_t); break;
+        case 8: FETCH(uint64_t); break;
+        default: goto bad_osize;
+        }
+    }
+
+    return (x86_decode_lite_t){ ip - start, rel_sz, rel };
+
+ bad_osize:
+    printk(XENLOG_ERR "%s() Bad osize %u in %*ph\n",
+           __func__, osize,
+           (int)(unsigned long)(end - start), start);
+    return (x86_decode_lite_t){ 0, 0, NULL };
+
+ unknown:
+    printk(XENLOG_ERR "%s() Unknown opcode in %*ph <%02x> %*ph\n",
+           __func__,
+           (int)(unsigned long)(ip - 1 - start), start, b,
+           (int)(unsigned long)(end - ip), ip);
+    return (x86_decode_lite_t){ 0, 0, NULL };
+
+ overrun:
+    printk(XENLOG_ERR "%s() Decode overrun, got %*ph\n",
+           __func__,
+           (int)(unsigned long)(end - start), start);
+    return (x86_decode_lite_t){ 0, 0, NULL };
+
+#undef FETCH
+}
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h b/xen/arch/x86/x86_emulate/x86_emulate.h
index 0fd20747dc43..566a8297d8a5 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -835,4 +835,18 @@ static inline void x86_emul_reset_event(struct x86_emulate_ctxt *ctxt)
     ctxt->event = (struct x86_event){};
 }
 
+/*
+ * x86_decode_lite().  Very minimal decoder for managing alternatives.
+ *
+ * @len is 0 on error, or nonzero on success.  If the instruction has a
+ * relative field, @rel_sz is nonzero, and @rel points at the field.
+ */
+typedef struct {
+    uint8_t len;
+    uint8_t rel_sz; /* bytes: 0, 1 or 4 */
+    void *rel;
+} x86_decode_lite_t;
+
+x86_decode_lite_t x86_decode_lite(void *ip, void *end);
+
 #endif /* __X86_EMULATE_H__ */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:20:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381224.1624781 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy6-0001jt-6s; Mon, 03 Aug 2026 07:20:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381224.1624781; Mon, 03 Aug 2026 07:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy6-0001jm-39; Mon, 03 Aug 2026 07:20:14 +0000
Received: by outflank-mailman (input) for mailman id 1381224;
 Mon, 03 Aug 2026 07:20:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqmy4-0001jZ-Sq
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:20:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmy3-00Dk9I-RV
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:20:11 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70412b-e002-0a2a0a5209dd-0a2a450bb788-0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:11 +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 <andrew.cooper3@citrix.com>)
 id 6a70412b-b7e8-0a2a450b0019-d1558032e956-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:11 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4955de8797cso9803985e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:20:11 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm254687935e9.2.2026.08.03.00.20.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 00:20:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785741611; x=1786346411; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Vn4hYT6+TtjuUJM3snHYvQUurh//1CWbljHmLcAATKw=;
        b=KsLvh5lyyn7oCgi26jrcq3NPMa2gHS12AWLM6hL5DVKPxrwb1cv5+gLXkgYwcLvu/o
         z8ulse263sFtKOBLfQXuVKPFqLrs7iulylpQQndrliRZLAoiSxsufSV992V9ex77W5bx
         6i8JMcgKC2P+f5RTX6CzTj0PxeiCjRseWUKE8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741611; x=1786346411;
        h=content-transfer-encoding:content-type:mime-version: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=Vn4hYT6+TtjuUJM3snHYvQUurh//1CWbljHmLcAATKw=;
        b=qgoGVNHHQgveS1ZQIpxRaxj0MxO6yWI4R0zpNxLyZPKM6jJsYhMHKB3NgmRmgceHeq
         EuHQI7HJs+tfhemw72/8tgPV1WIPANasjPm4xfecZnx5TteC81KzoWCfPVqEK6W6lZ7N
         rq5Jq3FV1uxY7a55tV1FLWT4v3DF5nLMs68FUD72bxqsr/CYH9ujoQ4LBvcZ85naioUF
         k+EeJ3ZavaRGvkVjcinUi8nX6FazhgeKwPQsXkeeIMTT2xHIYzJ+B6pF9NxyHg8LefDi
         ZCRQJ9/7pdW+WGkHuVIbAGP/g3oXCkU+FaQRjTFAu0csatIOGlVIQpwSRNI2FCUHaQhx
         DahQ==
X-Gm-Message-State: AOJu0Yw0ajfmlq7aynMU6uubSYZ6rtsZlTF15S+7/bGBY/eBM34xtA+O
	pvD8OmzWmEHiOwRw5V3+BSEfWlyfNLRI9wwUfGLNWqgH457jOODskdsKgoz2Q7C6x3yPrY12KUw
	9Kh4v7TE=
X-Gm-Gg: AR+sD13uDVgrHDW7GBtbkiO0HeCr+mSz9B0Gk1Ve9lfRfSw5G0PCqTLKHVzr0v8MJaN
	QOJS3De4fEdLPTtELb/XOvUZn0mLdVz96D8RROVAEDRewVszJKEv3DAJMOm/pyGx0X0MDzp2JeN
	BrDWCvMld3CoA4rvARJhwb3cEdPI+0iZg34LHGWPyRS69Ap1hmyRNoJrHJCV/Kef41NvtdjXcmm
	vSdgq+3j2a1FhAj1acDrzljUvEArHCLFm5+g/rClP+e26YLXu2wDfsjfu1j/SNpKVmmjabYzsM9
	ptt6+Z1fe+4TSzOrqDIvILpvaqIsvr+/IQBWfqf6IdfKFQzDrl50IweazRPJ4f9qxFWR9zfE+rI
	ziwqoOA9JnkRAtqBhERfQc30PqUVZoradorSXxOTinBrCaFQI+JcM+WhjfuLvcXn3ofUxeG4SHL
	m3UGFg+ckd6LWay11buZ9oI2wbCXOKIBEllPSa2ElmeFzBDqnxgMijy0n4Ii0bEfW9LVJKjXzvR
	X/KyHJYKKDZXEXOOG5UgYFo6fa91IY0iIKv62w=
X-Received: by 2002:a05:600c:8b13:b0:498:8e6:d464 with SMTP id 5b1f17b1804b1-4980c65cd2fmr198611065e9.14.1785741610768;
        Mon, 03 Aug 2026 00:20:10 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v3 0/5] x86/alternatives: Adjust all insn-relative fields
Date: Mon,  3 Aug 2026 08:20:01 +0100
Message-Id: <20260803072006.9678-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785741611-188C99EA-C3D7F43C/0/0
X-purgate-type: clean
X-purgate-size: 1886

Alternatives have had a reasonably severe restriction since their
introduction.  This has been the source of several bugs, and several
inefficiencies particularly in the speculative safety paths.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2724019865

v3:
 * Run through Gitlab CI.
 * Fix up Eclair issues, Clang issues, and older-binutils issues.

Andrew Cooper (5):
  x86/emul: Introduce x86_decode_lite()
  tests/x86: Introduce a userspace test harness for x86_decode_lite()
  x86/alternative: Walk all replacements during self tests
  x86/alternative: Relocate all insn-relative fields
  x86/spec-ctrl: Introduce and use DO_COND_BHB_SEQ

 tools/tests/Makefile                      |   1 +
 tools/tests/x86-decode-lite/.gitignore    |   1 +
 tools/tests/x86-decode-lite/Makefile      |  56 ++
 tools/tests/x86-decode-lite/insns.S       | 703 ++++++++++++++++++++++
 tools/tests/x86-decode-lite/macro-magic.h |  62 ++
 tools/tests/x86-decode-lite/main.c        | 111 ++++
 tools/tests/x86-decode-lite/x86-emulate.h |  27 +
 xen/arch/x86/alternative.c                | 102 +++-
 xen/arch/x86/hvm/vmx/entry.S              |  12 +-
 xen/arch/x86/include/asm/spec_ctrl_asm.h  |  43 +-
 xen/arch/x86/x86_emulate/Makefile         |   6 +
 xen/arch/x86/x86_emulate/decode-lite.c    | 330 ++++++++++
 xen/arch/x86/x86_emulate/x86_emulate.h    |  14 +
 13 files changed, 1434 insertions(+), 34 deletions(-)
 create mode 100644 tools/tests/x86-decode-lite/.gitignore
 create mode 100644 tools/tests/x86-decode-lite/Makefile
 create mode 100644 tools/tests/x86-decode-lite/insns.S
 create mode 100644 tools/tests/x86-decode-lite/macro-magic.h
 create mode 100644 tools/tests/x86-decode-lite/main.c
 create mode 100644 tools/tests/x86-decode-lite/x86-emulate.h
 create mode 100644 xen/arch/x86/x86_emulate/decode-lite.c

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 07:20:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 07:20:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381229.1624825 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy9-0002mb-TG; Mon, 03 Aug 2026 07:20:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381229.1624825; Mon, 03 Aug 2026 07:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqmy9-0002lb-Of; Mon, 03 Aug 2026 07:20:17 +0000
Received: by outflank-mailman (input) for mailman id 1381229;
 Mon, 03 Aug 2026 07:20:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqmy7-0001yA-Lc
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 07:20:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqmy7-00Dk9I-23
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:20:15 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a704119-e002-0a2a0a5209dd-0a2a4501c310-46
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:15 +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 <andrew.cooper3@citrix.com>)
 id 6a70412e-5984-0a2a45010019-d1558030c113-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:20:15 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4954aff6088so14417695e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 00:20:14 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm254687935e9.2.2026.08.03.00.20.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 00:20:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785741614; x=1786346414; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=SjwuBsICIK/H/Y6+HpcAgCloLVRbw36ixgETurBOkCw=;
        b=X2RSM6EpKUZkN34/3ySIiuU+Be1QmfqrwwfUVPWZ3s24nv2ra0DGlD0MV2Z0rWLA5F
         8FyIsGAPcKW4KxrrXu+PNjSM5KA71DU1h9Xh/qSwZFER6W/IpHENQHSSqfXLLHDpYlY9
         RWi7WF30Y2N870dZ6G5cEpjGExOVfm6elTg28=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785741614; x=1786346414;
        h=content-transfer-encoding:content-type: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=SjwuBsICIK/H/Y6+HpcAgCloLVRbw36ixgETurBOkCw=;
        b=HM1Wr4qoYrwPRDFJ0vxYxD2hgXFUQ31CCdmJE3e0WC9Ba6iYTQ1PIWwL7oFnguO56J
         y4XxO2HEWEgHx4Ijr7WvX553VjhA3YFN6bKnXztKyHHTHrpEIRaouQ0HuZPD9hAMQUXa
         mFBc4MYxVgfVjYBEcmChKExa88VWdMe9gbBShvGNVtIVwB9+R8KYh4+nOiuaJx4pxeCG
         2Cx1XNQLzMOpo2cO2YE/hVdMUEK1p2+QZYqLCRd/J8+Doh5IOo4tT1qzloQJ66nYRT49
         sufWzkM5iCg1AhMajv2UCubqRI/LYHEiNeVRMDp63M2Mdx1Z6CXA63rLJ1jUzD/0cJbJ
         AIqQ==
X-Gm-Message-State: AOJu0YyqiVH55tJzQXze4wBFNo0qhRTF8T+jKJRhVrtMXUtteJylnMlj
	LwTHNlD3V28FCxU3xMvCHBe8POQKj0LrVvV823yT4381vDrv3oLQFZYeTEAG7V3RrPloA0IIaMM
	Lf9lHHZM=
X-Gm-Gg: AR+sD13ElKyup0+QIQBgDZFOpoxm0WmK72UFcy0yVjnvjh1tmiQv1S3i+lba7LP2XRf
	hIjARuioRldmO6+X+tvb4sJNjC8PnR/mdj3xWRcytEgKPQYmydsmGhBEKFFaiiiOhYxa7tyJBcL
	rIpz/WqpGWkOglA+FBKViW9EN9h7Pa+NWtrw9tl8vSBP0esDJgalqiB6w0ydFsrc+G5sGyt9+r7
	Gs/cgF7XsJ8uKGywYIeBuLhfhBNQVE35lU5klpyzo1HISZL2xiBVfnVuAvHQ4d2rsQ5LTDh52Kt
	sotDY1UApmrSpILPiJMDWtt5p9PivWxYWfmpFkfZnvlw7rCHj1g1V44geQCNbFyUQ4arXkvgxpi
	w9VQnzNN0x+a+vzWtqfEWj8Aqli0caTfx7YlT9sE+/aJMfqiNxJou9ytBDlm02fuHjYCem95mYr
	JHOEywkzNc8ifaWgEBkvZT42bw4OutYWGhuZ4xtRBJ3NgAlMj90FX9Ye+qjUHVJUHlUMHGDVYUw
	iZcxjTkyUb9nGUBlrAd9eSDyLFRW80br6Gg328=
X-Received: by 2002:a05:600c:4504:b0:493:c194:4e7a with SMTP id 5b1f17b1804b1-4980c66c9a8mr181514035e9.3.1785741614271;
        Mon, 03 Aug 2026 00:20:14 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v3 5/5] x86/spec-ctrl: Introduce and use DO_COND_BHB_SEQ
Date: Mon,  3 Aug 2026 08:20:06 +0100
Message-Id: <20260803072006.9678-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803072006.9678-1-andrew.cooper3@citrix.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785741615-C5540757-3BC6C667/0/0
X-purgate-type: clean
X-purgate-size: 4495

Now that alternatives can fix up call displacements even when they're not the
first instruction of the replacement, move the SCF_entry_bhb conditional
inside the replacement block.

This removes a conditional branch from the fastpaths of BHI-unaffected
hardware.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/hvm/vmx/entry.S             | 12 +++----
 xen/arch/x86/include/asm/spec_ctrl_asm.h | 43 +++++++++++++-----------
 2 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index cebc70064048..76508c0de2f3 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -59,12 +59,12 @@ FUNC(vmx_asm_vmexit_handler)
          * Clear the BHB to mitigate BHI.  Used on eIBRS parts, and uses RETs
          * itself so must be after we've perfomed all the RET-safety we can.
          */
-        testb $SCF_entry_bhb, CPUINFO_scf(%rsp)
-        jz .L_skip_bhb
-        ALTERNATIVE_2 "",                                    \
-            "call clear_bhb_loops", X86_SPEC_BHB_LOOPS,      \
-            "call clear_bhb_tsx", X86_SPEC_BHB_TSX
-.L_skip_bhb:
+        .macro VMX_BHB_SEQ fn:req
+            DO_COND_BHB_SEQ \fn scf=CPUINFO_scf(%rsp)
+        .endm
+        ALTERNATIVE_2 "",                                         \
+            "VMX_BHB_SEQ fn=clear_bhb_loops", X86_SPEC_BHB_LOOPS, \
+            "VMX_BHB_SEQ fn=clear_bhb_tsx",   X86_SPEC_BHB_TSX
 
         ALTERNATIVE "lfence", "", X86_SPEC_NO_LFENCE_ENTRY_VMX
         /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
diff --git a/xen/arch/x86/include/asm/spec_ctrl_asm.h b/xen/arch/x86/include/asm/spec_ctrl_asm.h
index abb64ad2b7f9..780ec57f4553 100644
--- a/xen/arch/x86/include/asm/spec_ctrl_asm.h
+++ b/xen/arch/x86/include/asm/spec_ctrl_asm.h
@@ -92,6 +92,21 @@
 .L\@_skip:
 .endm
 
+.macro DO_COND_BHB_SEQ fn:req, scf=%bl
+/*
+ * Requires SCF (defaults to %rbx), fn=clear_bhb_{loops,tsx}
+ * Clobbers %rax, %rcx
+ *
+ * Conditionally use a BHB clearing software sequence.
+ */
+    testb  $SCF_entry_bhb, \scf
+    jz     .L\@_skip_bhb
+
+    call   \fn
+
+.L\@_skip_bhb:
+.endm
+
 .macro DO_OVERWRITE_RSB tmp=rax, xu
 /*
  * Requires nothing
@@ -277,12 +292,9 @@
      * Clear the BHB to mitigate BHI.  Used on eIBRS parts, and uses RETs
      * itself so must be after we've perfomed all the RET-safety we can.
      */
-    testb $SCF_entry_bhb, %bl
-    jz .L\@_skip_bhb
-    ALTERNATIVE_2 "",                                    \
-        "call clear_bhb_loops", X86_SPEC_BHB_LOOPS,      \
-        "call clear_bhb_tsx", X86_SPEC_BHB_TSX
-.L\@_skip_bhb:
+    ALTERNATIVE_2 "",                                          \
+        "DO_COND_BHB_SEQ clear_bhb_loops", X86_SPEC_BHB_LOOPS, \
+        "DO_COND_BHB_SEQ clear_bhb_tsx",   X86_SPEC_BHB_TSX
 
     ALTERNATIVE "lfence", "", X86_SPEC_NO_LFENCE_ENTRY_PV
 .endm
@@ -322,12 +334,9 @@
     ALTERNATIVE "", __stringify(DO_SPEC_CTRL_ENTRY maybexen=1),         \
         X86_FEATURE_SC_MSR_PV
 
-    testb $SCF_entry_bhb, %bl
-    jz .L\@_skip_bhb
-    ALTERNATIVE_2 "",                                    \
-        "call clear_bhb_loops", X86_SPEC_BHB_LOOPS,      \
-        "call clear_bhb_tsx", X86_SPEC_BHB_TSX
-.L\@_skip_bhb:
+    ALTERNATIVE_2 "",                                          \
+        "DO_COND_BHB_SEQ clear_bhb_loops", X86_SPEC_BHB_LOOPS, \
+        "DO_COND_BHB_SEQ clear_bhb_tsx",   X86_SPEC_BHB_TSX
 
     ALTERNATIVE "lfence", "", X86_SPEC_NO_LFENCE_ENTRY_INTR
 .endm
@@ -433,13 +442,9 @@
      * Clear the BHB to mitigate BHI.  Used on eIBRS parts, and uses RETs
      * itself so must be after we've perfomed all the RET-safety we can.
      */
-    testb $SCF_entry_bhb, %bl
-    jz .L\@_skip_bhb
-
-    ALTERNATIVE_2 "",                                    \
-        "call clear_bhb_loops", X86_SPEC_BHB_LOOPS,      \
-        "call clear_bhb_tsx", X86_SPEC_BHB_TSX
-.L\@_skip_bhb:
+    ALTERNATIVE_2 "",                                          \
+        "DO_COND_BHB_SEQ clear_bhb_loops", X86_SPEC_BHB_LOOPS, \
+        "DO_COND_BHB_SEQ clear_bhb_tsx",   X86_SPEC_BHB_TSX
 
     lfence
 .endm
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 09:07:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 09:07:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381303.1624867 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqoe9-0007k2-6G; Mon, 03 Aug 2026 09:07:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381303.1624867; Mon, 03 Aug 2026 09:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqoe9-0007ju-2G; Mon, 03 Aug 2026 09:07:45 +0000
Received: by outflank-mailman (input) for mailman id 1381303;
 Mon, 03 Aug 2026 09:07:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqoe7-0007h7-Ev
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:07:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqoe6-00B0Hb-RS
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 11:07:42 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a705a4e-e002-0a2a0a5209dd-0a2a4502ccc4-42
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 11:07:42 +0200
Received: from [209.85.218.45] (helo=mail-ej1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a705a5e-6ca4-0a2a45020019-d155da2de4ef-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 11:07:42 +0200
Received: by mail-ej1-f45.google.com with SMTP id
 a640c23a62f3a-c197eaaab00so507729266b.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 02:07:42 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd445432dsm507440166b.41.2026.08.03.02.07.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 02:07:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785748061; x=1786352861; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=b16T4GW68hAFFc0osm9lAVRPnORne6TE2Xjz+8jsFek=;
        b=P4olmWH6CfUDmU6sM4CVU3NrsiKSkPP3TmVonoy+u/7NAxj8/7GLjG0GJ2I2eDr/+1
         yfrMYnGJsMvdFm3gt5gAKc5VHd+nD1acJsSgSwiAnI1k+rvKnY9vjgvSCKX6/x+j24XT
         c4vsYFCtcFgVPg+5CVPLIplJh9NWLys5e2YGgHcmswsB8gW4l4HyQL2g3fGvWw6ydyEu
         OU1VuhGR8alKr4tdubmSSEeEo0NZqk6ndKycC28AFXpry3/cCzxSpyAf0d5+ef0hi6vV
         FM0r547H28TWnG6Up/lrl+3s4UYj6CsN1IW3xa2hBpzumPyRb/5BW6hwuaNNBkdWTwdZ
         bNrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785748061; x=1786352861;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=b16T4GW68hAFFc0osm9lAVRPnORne6TE2Xjz+8jsFek=;
        b=aBBUangYoOBq4g2ONO89D1ccSNnQajzVHDzMd4SPdW4D+HkthU6cibehhuLmt26v0I
         ffczWzsxeXmpdQF1vuCqA+nPif6hYfK9kzxHUARwuU/2cQ3yMT67lNpHZXIPj4x8P9sR
         87c/pzF+fx2ykls2NJz7WHSQfUZUpYVexeykQ5lZAwS3ekOqi8VAiygKtMCUe0Q0wQLt
         b5W2O0z7/7nQiXgdOETH8B8HiBtsNPYomBZ+0wpO0UmjW0OrapZj466Q0of9M+4b4Hhx
         TW9yngllSNesYnZon28NQ6tp7mEdOkZ0omBRMvF7bv99DWQ7pGnoWXkCqdBkhXmX/+IA
         IcgQ==
X-Forwarded-Encrypted: i=1; AHgh+RpRJxQJSetZ/eFih7ubzb0p1V8RvgioGEbElKOKt+JgUroUO+ZlJMPk+xw72HUTKJX4s5+b/SXQeQ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1OL1SF0Nmx9odq5mv/krUED7bRisrJEcwoa4h97XqveQEjiwJ
	vOm6QPTilgQuqsxRZzqRvl5TLRlqiDeAyR8mYOKH06fPLbgZicWWg4ys+k8BEjJSvr4=
X-Gm-Gg: AR+sD11TtPEj5JUgZyi79HKVreDduPB2ihWRwzkphy38mrsL1khHXy2WDR45x7iGCCl
	H19zaNQSnMe4T2TlHB61dGlfQGXxglXvlsEOa/Lv/N3R7dCQJzy9GA67V14TrM2jwOPI8jnAO+h
	95Gw1dHQ8hX20FEalPlobdYylRzT7ue6U/rhIIkrE9TGQUY3y4Va+f1476Yk+wQWJhfG851Z8s7
	p7lIRtl9kW225/vbSoI24GzTA9EskyIP9zkomH/Vvez2h3vBEhSfKYAF1EmdYZopdbD8eRw6c8B
	9rvkxoAEv2BbB6qtkb7o35GzLaq1dSUpEcz6+Y8GwNtCNeqB4CBJRw/UdlbpBjGQ/Z/68t4IBgJ
	6l7aPjams0TYu1d3jd9kElfzebtN7zADH1bYNRjsmN4jb3cSnxqNzzgc0dee0bAYMKWoy/fPu76
	41Wi0y8fiScCXnZgvyS71uxdz8Nn9N/7n/mM0ZZRyK6KXhtoUS0riCesiAHm7Kk8cB7AFo2BPFS
	1fLgi7Ii7s3lUAmoabK93YSshFHLONnKwi6uz9LWl+4Cj4dSz+p+ylcfOHTbDmVLEVD4IZPj6Pj
	ihHukk1uiZkerVQ=
X-Received: by 2002:a17:907:76fa:b0:c19:fb6e:5ff0 with SMTP id a640c23a62f3a-c1fe81a5d9fmr582774266b.15.1785748061532;
        Mon, 03 Aug 2026 02:07:41 -0700 (PDT)
Message-ID: <5ca4d0e4-1747-45a7-a916-a7516bb1692b@suse.com>
Date: Mon, 3 Aug 2026 11:07:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH RFC 00/14] Remove PG_private by using page/folio->private
 checks instead
To: Zi Yan <ziy@nvidia.com>, David Hildenbrand <david@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>,
 Andrew Morton <akpm@linux-foundation.org>,
 Muchun Song <muchun.song@linux.dev>, Lorenzo Stoakes <ljs@kernel.org>,
 "Liam R. Howlett" <liam@infradead.org>, Vlastimil Babka <vbabka@kernel.org>,
 Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan <surenb@google.com>,
 Michal Hocko <mhocko@suse.com>, Baolin Wang <baolin.wang@linux.alibaba.com>,
 Nico Pache <nico.pache@linux.dev>, Ryan Roberts <ryan.roberts@arm.com>,
 Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>,
 Lance Yang <lance.yang@linux.dev>, Usama Arif <usama.arif@linux.dev>,
 Gregory Price <gourry@gourry.net>, Ying Huang
 <ying.huang@linux.alibaba.com>, Alistair Popple <apopple@nvidia.com>,
 Johannes Weiner <hannes@cmpxchg.org>, Qi Zheng <qi.zheng@linux.dev>,
 Shakeel Butt <shakeel.butt@linux.dev>, Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Minchan Kim <minchan@kernel.org>,
 Sergey Senozhatsky <senozhatsky@chromium.org>,
 Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Thomas Gleixner <tglx@kernel.org>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "H. Peter Anvin" <hpa@zytor.com>,
 linux-perf-users@vger.kernel.org, Stefano Stabellini
 <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org, Eric Biggers <ebiggers@kernel.org>,
 "Theodore Y. Ts'o" <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>,
 linux-fscrypt@vger.kernel.org, Oscar Salvador <osalvador@suse.de>,
 Chao Yu <chao@kernel.org>, linux-f2fs-devel@lists.sourceforge.net,
 Gao Xiang <xiang@kernel.org>, Jan Kara <jack@suse.cz>,
 Yue Hu <zbestahu@gmail.com>, Jeffle Xu <jefflexu@linux.alibaba.com>,
 Sandeep Dhavale <dhavale@google.com>, Hongbo Li <hongbohbli@tencent.com>,
 Chunhai Guo <guochunhai@vivo.com>, linux-erofs@lists.ozlabs.org,
 linux-fsdevel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
 Masami Hiramatsu <mhiramat@kernel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
 Matthew Brost <matthew.brost@intel.com>,
 Joshua Hahn <joshua.hahnjy@gmail.com>, Rakie Kim <rakie.kim@sk.com>,
 Byungchul Park <byungchul@sk.com>, Axel Rasmussen
 <axelrasmussen@google.com>, Yuanchu Xie <yuanchu@google.com>,
 Wei Xu <weixugc@google.com>, linux-trace-kernel@vger.kernel.org,
 Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>,
 linux-nfs@vger.kernel.org, Song Liu <song@kernel.org>,
 Yu Kuai <yukuai@fygo.io>, Ilya Dryomov <idryomov@gmail.com>,
 Alex Markuze <amarkuze@redhat.com>, Viacheslav Dubeyko <slava@dubeyko.com>,
 Li Nan <magiclinan@didiglobal.com>, Xiao Ni <xiao@kernel.org>,
 linux-raid@vger.kernel.org, ceph-devel@vger.kernel.org,
 Richard Weinberger <richard@nod.at>, Zhihao Cheng <chengzhihao1@huawei.com>,
 linux-mtd@lists.infradead.org, Baoquan He <baoquan.he@linux.dev>,
 Pasha Tatashin <pasha.tatashin@soleen.com>,
 Pratyush Yadav <pratyush@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
 Dave Young <ruirui.yang@linux.dev>, Shuah Khan <skhan@linuxfoundation.org>,
 kexec@lists.infradead.org, linux-doc@vger.kernel.org
References: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Vg9NJvq3ine0Gyx1IX0BEzQC"
X-purgate-ID: tlsNG-720697/1785748062-305C52AC-89ECAC62/0/0
X-purgate-type: clean
X-purgate-size: 10188

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Vg9NJvq3ine0Gyx1IX0BEzQC
Content-Type: multipart/mixed; boundary="------------1XNOHvG0ftKOzuceeKWaT2Id";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Zi Yan <ziy@nvidia.com>, David Hildenbrand <david@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>,
 Andrew Morton <akpm@linux-foundation.org>,
 Muchun Song <muchun.song@linux.dev>, Lorenzo Stoakes <ljs@kernel.org>,
 "Liam R. Howlett" <liam@infradead.org>, Vlastimil Babka <vbabka@kernel.org>,
 Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan <surenb@google.com>,
 Michal Hocko <mhocko@suse.com>, Baolin Wang <baolin.wang@linux.alibaba.com>,
 Nico Pache <nico.pache@linux.dev>, Ryan Roberts <ryan.roberts@arm.com>,
 Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>,
 Lance Yang <lance.yang@linux.dev>, Usama Arif <usama.arif@linux.dev>,
 Gregory Price <gourry@gourry.net>, Ying Huang
 <ying.huang@linux.alibaba.com>, Alistair Popple <apopple@nvidia.com>,
 Johannes Weiner <hannes@cmpxchg.org>, Qi Zheng <qi.zheng@linux.dev>,
 Shakeel Butt <shakeel.butt@linux.dev>, Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 Minchan Kim <minchan@kernel.org>,
 Sergey Senozhatsky <senozhatsky@chromium.org>,
 Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Thomas Gleixner <tglx@kernel.org>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "H. Peter Anvin" <hpa@zytor.com>,
 linux-perf-users@vger.kernel.org, Stefano Stabellini
 <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org, Eric Biggers <ebiggers@kernel.org>,
 "Theodore Y. Ts'o" <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>,
 linux-fscrypt@vger.kernel.org, Oscar Salvador <osalvador@suse.de>,
 Chao Yu <chao@kernel.org>, linux-f2fs-devel@lists.sourceforge.net,
 Gao Xiang <xiang@kernel.org>, Jan Kara <jack@suse.cz>,
 Yue Hu <zbestahu@gmail.com>, Jeffle Xu <jefflexu@linux.alibaba.com>,
 Sandeep Dhavale <dhavale@google.com>, Hongbo Li <hongbohbli@tencent.com>,
 Chunhai Guo <guochunhai@vivo.com>, linux-erofs@lists.ozlabs.org,
 linux-fsdevel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
 Masami Hiramatsu <mhiramat@kernel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
 Matthew Brost <matthew.brost@intel.com>,
 Joshua Hahn <joshua.hahnjy@gmail.com>, Rakie Kim <rakie.kim@sk.com>,
 Byungchul Park <byungchul@sk.com>, Axel Rasmussen
 <axelrasmussen@google.com>, Yuanchu Xie <yuanchu@google.com>,
 Wei Xu <weixugc@google.com>, linux-trace-kernel@vger.kernel.org,
 Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>,
 linux-nfs@vger.kernel.org, Song Liu <song@kernel.org>,
 Yu Kuai <yukuai@fygo.io>, Ilya Dryomov <idryomov@gmail.com>,
 Alex Markuze <amarkuze@redhat.com>, Viacheslav Dubeyko <slava@dubeyko.com>,
 Li Nan <magiclinan@didiglobal.com>, Xiao Ni <xiao@kernel.org>,
 linux-raid@vger.kernel.org, ceph-devel@vger.kernel.org,
 Richard Weinberger <richard@nod.at>, Zhihao Cheng <chengzhihao1@huawei.com>,
 linux-mtd@lists.infradead.org, Baoquan He <baoquan.he@linux.dev>,
 Pasha Tatashin <pasha.tatashin@soleen.com>,
 Pratyush Yadav <pratyush@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
 Dave Young <ruirui.yang@linux.dev>, Shuah Khan <skhan@linuxfoundation.org>,
 kexec@lists.infradead.org, linux-doc@vger.kernel.org
Message-ID: <5ca4d0e4-1747-45a7-a916-a7516bb1692b@suse.com>
Subject: Re: [PATCH RFC 00/14] Remove PG_private by using page/folio->private
 checks instead
References: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
In-Reply-To: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>

--------------1XNOHvG0ftKOzuceeKWaT2Id
Content-Type: multipart/mixed; boundary="------------emnYBJyIfA0mAuf1FBk0JrWD"

--------------emnYBJyIfA0mAuf1FBk0JrWD
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDEuMDguMjYgMDQ6MTMsIFppIFlhbiB3cm90ZToNCj4gSGkgYWxsLA0KPiANCj4gVGhp
cyBwYXRjaHNldCByZW1vdmVzIFBHX3ByaXZhdGUgdG8gbWFrZSBzcGFjZSBmb3IgdXBjb21p
bmcgUEdfZm9saW8NCj4gKHJlc2VydmVkIGFzIF9fUEdfZm9saW8pIGZvciBpZGVudGlmeWlu
ZyBwYWdlcyBmcm9tIGEgZm9saW8gKG1vcmUgZGV0YWlscw0KPiBpbiBOb3RlIGJlbG93KS4g
SW5zdGVhZCBvZiBjaGVja2luZyBQR19wcml2YXRlLCBhbGwgY29kZSBpcyBjaGFuZ2VkIHRv
DQo+IGNoZWNrIHBhZ2UvZm9saW8tPnByaXZhdGUgIT0gTlVMTCBpbnN0ZWFkLg0KDQpJJ20g
YSBsaXR0bGUgYml0IHdvcnJpZWQgdGhhdCBwYWdlL2ZvbGlvLT5wcml2YXRlIGlzIGluIGEg
dW5pb24sIHNvIHRvZGF5DQppdCBjb3VsZCAoaW4gdGhlb3J5KSBiZSAhPSBOVUxMIHdoaWxl
IFBHX3ByaXZhdGUgaXNuJ3Qgc2V0Lg0KDQpJcyBpdCByZWFsbHkgbm90IHBvc3NpYmxlIHRv
IGVudGVyIGEgcGF0aCB3aGVyZSBQR19wcml2YXRlIGlzIHRlc3RlZCB3aGlsZQ0KcGFnZS9m
b2xpby0+cHJpdmF0ZSAhPSBOVUxMIGR1ZSB0byB0aGUgdW5pb24gYmVpbmcgdXNlZCBvdGhl
cndpc2UgKFBHX3ByaXZhdGUNCm5vdCBzZXQpPw0KDQoNCkp1ZXJnZW4NCg==
--------------emnYBJyIfA0mAuf1FBk0JrWD
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------emnYBJyIfA0mAuf1FBk0JrWD--

--------------1XNOHvG0ftKOzuceeKWaT2Id--

--------------Vg9NJvq3ine0Gyx1IX0BEzQC
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwWlsFAwAAAAAACgkQsN6d1ii/Ey/i
jgf/ZwJPxlL37xKWgHvTpcOyxx9OjPwR5NnmxhKYC+qK1G+dCKRR2aNsNRd92IvtuR/zlwoSK3Bz
7Knn/QAX+Sr8+MzzkoSZZy4464mITxuVnjBsYOy1wmVfTRA9xJ5kPDsLcow9h9fba5YWY5JKjJEr
fuIk59vC3iZC8TXbrwFnUB118QfIzPMfnHvl18ioDjqN/X6ooFJudXLB3hTrlpzsxtdu1OFI+TsY
0FUiNapbbcLYtM5X9v/bo7LSqQNdjZKmfV2DVQHs8Vj2bH/TyrIG+SvEggEztdqBgec9T7Ix66uU
FOasApx6jWOz0UmYAKKBF0iBOhSZaPnQhSA6xqkzCw==
=lraB
-----END PGP SIGNATURE-----

--------------Vg9NJvq3ine0Gyx1IX0BEzQC--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 09:14:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 09:14:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381313.1624876 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqoko-0001bJ-U3; Mon, 03 Aug 2026 09:14:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381313.1624876; Mon, 03 Aug 2026 09:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqoko-0001bC-Qy; Mon, 03 Aug 2026 09:14:38 +0000
Received: by outflank-mailman (input) for mailman id 1381313;
 Mon, 03 Aug 2026 09:14:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wqokn-0001b4-H0
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:14:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqokm-00E9gR-Tk
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 11:14:36 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a705bfa-5cb7-0a2a0a5109dd-0a2a450296ec-4
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 11:14:36 +0200
Received: from [40.107.200.51]
 (helo=CH5PR02CU005.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a705bfb-6ca4-0a2a45020019-286bc8334d66-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 11:14:36 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BN9PR03MB5964.namprd03.prod.outlook.com (2603:10b6:408:135::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Mon, 3 Aug
 2026 09:14:33 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0270.017; Mon, 3 Aug 2026
 09:14:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JxaNim8YFCvhgZdYlREAR01MiL/ri+NfUnf2921a675RKSIQz5BwvTjRG1dLy/Bz55MntAYlFdjnSHIHsIR6EbB8O+O1fDrNdYEq8OE3Sxq1FRnT6bt6N5Y6b8w8jS8JLoA1iIYEaFQIqAonm/nPXsgqTcg4Q2Iy60HfslwPHrl361IisN3YMwrcWMoW0gCtYPhmR7MsbR/Y0Q3XT/CuTUz8NFEJ/nURXoJnDcfCEnxN1410qdCZ3nFdFKZ5pzdvsWMhxuKkdkUilt+ETtqiXf9sIc/SdA5ydEuBuV/E2EqgoRD5Zqx85B30F/dWUtcaM0IUSs9JMqqHqR7I1aCNAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cQe3jkA8rX/YsH8gkWg7TjQ13snFQ+1/VGMhIr9kwU4=;
 b=EY68H5IbfDmFpx0uEOQYNK/oNt5uI4fdC7pC69KgiFA9HyQqftJPygKn4mGI3k1ST3pCjzMZvc+HF/xUfVfwMAg/qSzq43J67E/vXlX82vPl7893XReVR12/8YkBJ5W7P2IfG3kiSBziW4WujQNO9iFpUa259HUCouTD5R7giuszwQ6syhn2BzLVJdN/2XxQUCJvzf4zwUIeHLNfAfczFdDp8gAh9oTw1y1P75vZsEGHsYkvLyjxtb+9qQAMsyl8Tp4XbMnl+iz/InX618bVtNMdR4y+q7VIG/icRthElt6es7XElrG6VVnB7xSstSeZZKaBqh6cc+pLoHD3mux0lQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=cQe3jkA8rX/YsH8gkWg7TjQ13snFQ+1/VGMhIr9kwU4=;
 b=jgnr28Hngb4wyyORZVRHjkhTAKusZhHeSyPXF0j/WkeTlVJPhZ3LM3Y74cuRg2Zv0JOMGFyWwhIx4lwx9p1+Kg7+BSKS1DlM4KglM7+pej2acJTMio133+ztpUnk+NYtqKNJVFwKiVqrMHwtj35pp2qvnaTK1U/JtU99I+wlKbo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <c97a44db-bf91-4d22-b775-190e69741dae@citrix.com>
Date: Mon, 3 Aug 2026 10:14:29 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich
 <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v3 1/5] x86/emul: Introduce x86_decode_lite()
To: Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-2-andrew.cooper3@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260803072006.9678-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0699.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:37b::6) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN9PR03MB5964:EE_
X-MS-Office365-Filtering-Correlation-Id: e09100be-83fc-4536-b6b7-08def13fa14a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|56012099006|10067099003|11063799006|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	3KeHgKs3cFMRuOxCct5/itLB517SBhAFWCuoxGKRRCFuxbiDZEOTDLD5+JC1rLQxvAY7bBZnzugits30ajjQLfuRceUghWGAOiBK06IYhtqa9u36zkVamR3n2EkNMTQtXXVmElb6pOQaq3MSeic40qaNAO7wEWVkuW96Y2Voa1IP40nFJoXqCk+lDIgW0zfC5JNr8qtHoVYO0i3/mARhVHse/UA3hzsUVaHZuNEPyCpS+9Xv46rNzPIA0Ap+0t0yyJN+0zxPq5HZwWJHPuevemj6WDNYpxQxCASdozXAAz2xkjm7fo/oHy+esC8g03Bpc5OYp8NGorK8oMdaN7eVjtxrxcuquo1k7DL6r7QZegVrzefg2HNwv3lktfGn79kk7mFGaOxf/cblS/TnLpqRO/xKUvRjA3qPNPm+rhuCqFZ51zHxtN3ndKtA4LlWOYXfdaP3zOdLMbQo7BHkrNSVgiGH7A45OaiYNeXSJJyGL2kh+SIGvtmrptX0V31ZoS3ARqBWTpEJtsJpoVhZM93gpLbWAVJXRhotOWfPVmxFz0l8lyCTnEJlTvR+rQc6fRihLocJshtXG1uE+a5q+mJQZhBNSoRKtlve1TaagGT3ijVwhoSza9t7PxNo1+wZ1JqNFXxhkEtgjlG0fyFlGeEyS3/8XrKeC8RvaWcbhweJfUA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(56012099006)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VkYwOVNGa1Zwb0tCN0ljZng2bDFGOWdvQzNpNm5rMkMrRFk5Ti96YmhkbWh0?=
 =?utf-8?B?cm4wSFVhK3FvWDkwZTBYczgrU2VCdXpKSGJlWlI1TVpiYVNUWkJaQ3dvMFd0?=
 =?utf-8?B?ZmZ1Ny96NmNtd3JZZUpKU3Y0MGZ3ZmFNMUxRWlUyQlFZY2l1bWNneTVQV3M4?=
 =?utf-8?B?a0ZNdHRHY25DKzlsRmd0bEFGaFJub2phdDZCNXdKK0xIWHZucGdPTmFMNFBt?=
 =?utf-8?B?MUN3VEErVkd2ZTBJVmpVOUJOVk1uSnRkdEkyaFBPMXVkNXEzSFZTYkFQMXJC?=
 =?utf-8?B?bi9nbFZIWjBQR3gzaEpla1RxSG5aRDIrYktqOXd1UXlmSE9CWWFUVjVpM0lO?=
 =?utf-8?B?czg3V2gwQlRRVmUwWVlzVWdyYUFlK3hyd2hiYVZpb1FueEN4VkFBL1RaTEcr?=
 =?utf-8?B?b1FIYzNwRTJaWWM4OXhtRVpZVVNqWEZqSEFDMVAvemdYT2NISldmUTZrQnBD?=
 =?utf-8?B?dDY0bzZRUk9GU0tLa05yRVd1MTdBdG5CVkVWZVBrS1ZHeVdiQWJUSWZINEk1?=
 =?utf-8?B?cThTa01lN25zbEcyTVhpUWRyQlh4eXZGdit2OGRVOW9OcVhZa0t0VHh3Z2oy?=
 =?utf-8?B?ZWNJMFJmSU91cUZSY0dYNFZpKzBTK0xWK2wwQkRDMlhXSkxtcG1SeG12VW02?=
 =?utf-8?B?MkJFcHRVSkRyRld5VHdiYXFIVDlxZzdTZ09zckY0T2plVnRZV0JQWklkeVNP?=
 =?utf-8?B?enBtNlczd21WTlgyNnFtZXA5MVBPK2g2VGxrVS9TVzcyTTE0cFlTdkkyb0Q0?=
 =?utf-8?B?SFJVWU9saHp6T3lzeFhRY3VPVXV5V3BGMEtOOHkyQm9zSnowZzJXU1VkYU9X?=
 =?utf-8?B?cmkya1RKTVd6bUFyRkNDU1FiV1lzdlFrdTc0UjN0UzBFZDd6VkRQVWo2bzJR?=
 =?utf-8?B?R1cwYzFvQXBMWi9MUERUU3dCNWFDaDZrb0g3WE1EL25CbGxwWUMybEMyVTMx?=
 =?utf-8?B?aVVIOHNTV1BKbGNTNnYzMkR3SnJXYXJtRW55eXRJMldKOCsvZFhkR0JmeFd3?=
 =?utf-8?B?WlBYMnZWdEFzWUlkc0lvTDF1MUhjeDhMT3lxbGN4QlE1NnFvUUdLM3YvRUln?=
 =?utf-8?B?eCszYytWWThwc29jS2NINllxN3p1UUx2VkFwZ01yRlBVc0FuNlJsZTVzR1Bx?=
 =?utf-8?B?YUxkZzgvSWUwU0JOdWYwNjFQSmRGeXlrMHlJbVpuU0VjUm9RV1VKajJrOHdH?=
 =?utf-8?B?a2dzVFlNaXh2UGtSMVBNNmJpdWZEcE4wUURjaFNzejZyNFh4RW10Y1U4TXpB?=
 =?utf-8?B?ZXdreTJ3RFZhdXRHdHNlVUVGVFpGellaZkkycStGNDZzTTVaNi9IdTdvTFZP?=
 =?utf-8?B?MUdzeWs4QmRUVVZZd1V1cit2bEQ5SHhNc1A5Y0JHUGtNMmpRZVhuQUZZUXNF?=
 =?utf-8?B?U0w5NkI0MGVIWHJjV2l5UUxQYlhCc2JPZVBjZVFtZUp6SE1DU0hjM1ZZL2FH?=
 =?utf-8?B?UjgzSWpHYjZqdVdjT2VOay9GaXMxQytweUdRcGljL0VBdzg3RDdsVU4zWFhX?=
 =?utf-8?B?c251TFBpY2xzM1JXaENZY09DWlFYNmh3cm1KS2lKVHN3ZlBIemlDRG8xVlBa?=
 =?utf-8?B?a0I5OFkzTUU4TVNnRTI4KzVrRUhrRks1WExyWGNRa3gvR1JRRGQxR0UxTmZo?=
 =?utf-8?B?RVhFdktGVmxuQ2tlVGF0Vk1TK2dCNExaSDE5Qm9TUUIzeUMya25BSWRJSFlE?=
 =?utf-8?B?T0lrZFBrQkVqY1YxUXJpL3NOZExwc1JZaWJ1RFFodGRDK1FERXJ4TjR4bzRJ?=
 =?utf-8?B?MUEyUzlHWTVxd2lzanRYNnlIcjBibXdQblY5c0lxRWJRNmpTaVNpMTRySWE0?=
 =?utf-8?B?dmJPNW00cHFsZWROS0tZd3hQRmJ4aUhUS3pWN1ZWQVBoSEFtTklkSDJsRDZw?=
 =?utf-8?B?NVNHUU14T3M0R3orbnFSVmY0Zjk5aTZ3UzBsdTFmbmlRNTlSN290TU9uOVA5?=
 =?utf-8?B?UlJWbEF6cDc5UU9SdlVjckNabXpDaXllNnpWN21rK01sUUswVE9qTHVUcEQz?=
 =?utf-8?B?aURncHA4M0ZudlhzUWlPa2lPaXBSZ2I5ZlNOd0owYzJqVUN5Vmg3NHloZkpN?=
 =?utf-8?B?OGVvV1RyZGN0dXJWN0ZrMDhFUXF5cjVMUzVLLzNhd1NXWWpaUXRrWHdRMVRF?=
 =?utf-8?B?d1c1c3NUQkg5Tyt5YXluSGNZMmJlUlI1ODFsTU1NWWo4UXRZeVFHUUUzSjNM?=
 =?utf-8?B?b1BPVTh2dy82ajRQcTlRNllDem9TS01PcHFIak1hRGpNOUpMd3ovRFdVS1NM?=
 =?utf-8?B?M1hZWmlkNjNJZ3JZYUtRb2NTRDhKbDZPdThlWDlQRmxFSTBMbmN4cnJ2cllz?=
 =?utf-8?B?VzFOKzc3MndHU3lLQTVRQmltbS8wVVdBRkU1cjJFWkN4SGRLaFJhUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e09100be-83fc-4536-b6b7-08def13fa14a
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 09:14:32.5341
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9yMmWBsBBn9yOgLW3WjATjIusFKoo3jox6QQgGRpLLF2h0NRH4zp/jKeeBemqA4y0FqptvuVNiqE6EKW8yrLxAQl6qCOeMP2/ynNi3agj7s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB5964
X-purgate-ID: tlsNG-720697/1785748476-319CB2AC-6A2C863C/0/0
X-purgate-type: clean
X-purgate-size: 2256

On 03/08/2026 8:20 am, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/x86_emulate/decode-lite.c b/xen/arch/x86/x86_emulate/decode-lite.c
> new file mode 100644
> index 000000000000..131cc07d5516
> --- /dev/null
> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
> @@ -0,0 +1,330 @@
> +
> +    if ( d & (Imm | Imm8 | Moffs) )
> +    {
> +        if ( d & Imm8 )
> +            osize = 1;
> +        else if ( d & Moffs )
> +            osize = 8;
> +        else if ( osize == 8 && !(opc >= 0xb8 && opc <= 0xbf) )
> +            osize = 4;

GCC 12 does transform this into sub $0xb8; cmp $7.

> +
> +        switch ( osize )
> +        {
> +        case 1: FETCH(uint8_t);  break;
> +        case 2: FETCH(uint16_t); break;
> +        case 4: FETCH(uint32_t); break;
> +        case 8: FETCH(uint64_t); break;
> +        default: goto bad_osize;
> +        }

On further consideration:

        switch ( osize )
        {
        case 1:
        case 2:
        case 4:
        case 8:
            if ( ip + osize > end )
                goto overrun;
            ip += osize;
            break;

        default: goto bad_osize;
        }

drops nearly 10% of the function:

    add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-91 (-91)
    Function                                     old     new   delta
    x86_decode_lite                              972     881     -91

GCC clearly can't reason about the relationship between osize and
sizeof(type), and needs the help.


I also tried the further simplification:

        if ( osize > 8 || (osize & (osize - 1)) != 0 )
            goto bad_osize;
        if ( ip + osize > end )
            goto overrun;

        ip += osize;

but interestingly this delta grows the function by 30 bytes.  It only
seems to add the block checking osize, meaning that GCC managed to
optimise away all of the switch dispatch previously.  In hindsight this
is probably quite easy; because we're 64bit only, osize only ever has
constant values that GCC can see.

Anyway, I've folded in the first optimisation.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 09:55:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 09:55:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381331.1624905 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqpOk-0001X6-1l; Mon, 03 Aug 2026 09:55:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381331.1624905; Mon, 03 Aug 2026 09:55:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqpOj-0001Wz-UO; Mon, 03 Aug 2026 09:55:53 +0000
Received: by outflank-mailman (input) for mailman id 1381331;
 Mon, 03 Aug 2026 09:55:52 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqpOi-0001Wm-A2
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 09:55:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqpOh-00B9i8-MV
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 11:55:51 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7065a7-bab6-0a2a0a5309dd-0a2a4503b012-2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 11:55:51 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7065a5-fae8-0a2a45030019-d1558033c915-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 11:55:49 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so10010125e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 02:55:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4980878dcb4sm353186965e9.13.2026.08.03.02.55.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 02:55:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785750949; x=1786355749; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qmDsnUCui8sqdr2eheUQXwVu5kWQQnxMMLiHzaFa0lM=;
        b=Iu4/DQI+Dj9lmfWj8bgpE6L/mSD60x+hXjta65RMiYGMnMiJZZ3haLyGeP5NEaM0LR
         Xgmmf30AhvFlCPcH3X4oRJ4lk+duFOTIUmI675QzRjxrKo6KsCNzhgsthr2COtZJ0Q1/
         MI76b/yBIXkhaVKZ313ACr/CiuBdgs+GvQpcbZ4nmOkCBVO8I8/YvE8fokBwgv7FZMEi
         T8MSUVmi0KA7+ZzwbPq8F5B97jpKQeqo4Qczf8wlSremYwIKe3I4wtiOinVWUKsHMIbD
         9TXAk6cEMs1nidGy9ZwLrf/vh3SjiIAC4v6meCMgOqynnZ9GvAYQbxMcoOh6WrU4t1Tr
         /BPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785750949; x=1786355749;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=qmDsnUCui8sqdr2eheUQXwVu5kWQQnxMMLiHzaFa0lM=;
        b=T2EhND8y7nUjwBJlHr3FekB2ZAf60W+UnpoBytKpR28N6nb1xPfDH3z3VsOGtPsp/J
         1fZt4nE4ktlsTlGmL+YEaYJbXwZTEaanVWp8gOM0X0c4zNesleFf0tTG+jEW4+YP2Y0Y
         P//WV1LLrJrnhEwtd2N9XoBuKAuX32D6x/ZlNxPZUJMQ+rPJH+DmLUfd6PUnT+dOgc0k
         AbnaJ9VUe55msyxeGwb4CEHumjNnbNsf6PItZavDNXruk6nLpsHoKb2cNT9NQ2Uo8M+C
         zfo3VlUZrOTO0ER+S5SdC7cQqDBz9t47bUoFwWz8z1Ntl30T0BNlDLp9QLbvqyFhGNi/
         6acw==
X-Gm-Message-State: AOJu0YzsRo9EmBdXS4ll8txE/YoAqPxbOGS4huDENyxzd6UN4IDmVDd5
	eKlnIoK1fCwSRx4GHcvGyIYtGbFU0lqFatWIxxmF77Q//ggibspHrSyX3xMxx5am70joWYo3zwd
	7x63v9g==
X-Gm-Gg: AR+sD10Eqmuq1f3T2j1bGHWNzZjBix1lx337T1zopHBVlzwgfY5pN/uVefgx9OmbBVM
	4THIbBl6rCjLhEC983hByu1NA0+c6TypPPcmLqRpEjJQ31za+NUDi3JEAQ/UFjTG0d8poZ2wYss
	8Gmwq+VKSpjpFq9W7qVB3wayPMQx549DhLfwPsHnssTenaPwQVISLkGpVSR/mChNvfTyKEsUPs0
	LZsDmtFjkz6nBdX9jzwYfgUgYQ+pPpJI25E1Buj5bQaJq5hkI0DBpczvaQsIws/+RWoNSRFBUxZ
	Cc5gRf+7R8DignfN/zpgVCnP/S8OWDPoMVUR6JzNuTRsWZbBEMQ7kpH6KbN5l4DbJDggvY2fPM+
	H3CF586N6UvR6Qm52Oho2AJppWSd7oKPPxtplIYwG1dn4+e3TwrdFjfaS6uwkGDFbmd+CWYqjdX
	1LSvZXilaMsvh3HAcxeiXCWgAsG7967TNIW72i2FhGr4zSfltBdqlTx97c0Y0eFLPPEv5RL6/lk
	eDs5gT/Legifb+qq+jQSZNyR454+W4uNMUneBl0I2zwA5AaQc09
X-Received: by 2002:a05:600d:8443:20b0:493:e974:41ac with SMTP id 5b1f17b1804b1-4980c6562c5mr157611345e9.16.1785750949416;
        Mon, 03 Aug 2026 02:55:49 -0700 (PDT)
Message-ID: <7e9c755a-0cbd-45f3-9683-069627e540eb@suse.com>
Date: Mon, 3 Aug 2026 11:55:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 09/24] XSM: make .hvm_param*() hooks dependent upon HVM=y
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <7947b62f-6763-4561-b3aa-c451cfa3dacb@suse.com>
 <1b4d5a82-bdc4-460d-a5a4-59e788fe1c3f@apertussolutions.com>
Content-Language: en-US
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1b4d5a82-bdc4-460d-a5a4-59e788fe1c3f@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1785750949-76CF84E9-1CF67549/0/0
X-purgate-type: clean
X-purgate-size: 835

On 02.08.2026 17:05, Daniel P. Smith wrote:
> On 7/28/26 9:17 AM, Jan Beulich wrote:
>> They're unreachable / dead otherwise.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Strictly speaking .hvm_param_altp2mhvm() is dependent upon X86=y as well
>> (but oddly not dependent upon ALTP2M=y).
> 
> At a minimum, would it be worth at least adding a comment about the 
> dependency? Note, this is just a question/suggestion.

Just a comment would be too little imo. One way or another we want to sort
this properly. With the first question being - why a separate hook, and
hence why the double checking for HVM_PARAM_ALTP2M? With further data
passed into the hook, the Flask case can easily be dealt with using just a
single hook. The XSM_TARGET vs XSM_PRIV makes this a little less nice for
dummy.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 10:11:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 10:11:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381345.1624933 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqpdn-0005x6-I9; Mon, 03 Aug 2026 10:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381345.1624933; Mon, 03 Aug 2026 10:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqpdn-0005wz-FG; Mon, 03 Aug 2026 10:11:27 +0000
Received: by outflank-mailman (input) for mailman id 1381345;
 Mon, 03 Aug 2026 10:11:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqpdl-0005wt-Mw
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 10:11:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqpdk-00EdkD-4a
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:11:24 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a706948-bab6-0a2a0a5309dd-0a2a4508b0ea-18
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:11:24 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70694b-f659-0a2a45080019-d155802ced93-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:11:23 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-49553515a8bso30564155e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:11:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b4bdc7sm130641945e9.0.2026.08.03.03.11.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 03:11:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785751883; x=1786356683; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=gnOva0LMcogndW3IgqX95g4dwlTyOBKUvXh5mUS4hXs=;
        b=VOZmgU0D6QdELjqCTXzGwQsX9GLPRegp3YOcTZG9OcDNevvC3L5JvvMjBqxF4jTWHR
         5j9Fyf8QdyJlTiWAsWSKUKZkF0E1qwTSZlLOrUNsS5glvvx2WqHvh3lOcnKZdLL9aGoW
         bVwrp+iUeW5eYPRqc5p4U523wHxb5gEyPzUc0xqmGxLihHRrSGMtyqU2KJBe98LwARiE
         uPLdOzzEiwi3+4LDmeUx670/uKA0zQS14A7IO7cWcEDUXrzJVmMIIy7VMaQgHdw4B9gA
         DoMqEqMzO6BRw/w41SY6IXf7O8OgijoRkzZ9J05Uzm+qEWfdKRqvVapXRQwwREuhdH6S
         P9Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785751883; x=1786356683;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=gnOva0LMcogndW3IgqX95g4dwlTyOBKUvXh5mUS4hXs=;
        b=g1fkTWnxdpVjgX/3nqdrWF9u3unhh3K8tv/P9+ukEAwP2DScJX9Oy6u7XQa9gmZw2Y
         7D+1aMOjt35n3kP79ckNToNexYDu1QdCU11kp/5pwAiP1SZQpa20VtQKDfhVNvhdvLvB
         0ZrpTGl9rsTMqk4dYR6EUeEvDrUkFnxheCTkew1vPqFRJC9kjyCw6sA+o7odNIrMMecW
         KeFWjMhBT9wRxgxxZ/w7nhQOTTnIR7WVZNGqJh79mbIkSENvawg0O+0h6prCBlw9oCTq
         o3f53nrTMtXqcYZDFMNaxAH3b8TKird64BHR7uyj6myuqFFp7sbX8gGApXPsZPPx5ht+
         zYXA==
X-Forwarded-Encrypted: i=1; AHgh+Rqzn1WGT/5i7heShEnhubFRJzDHpboFEzWbsr+UL6ac7DlyukozXdNP4I7G18hoWWJws5Jy/QM1glM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwCDvMRT0M6InV4iBVSKNr1PwVxbvRlOa7ukke8WBJ7KO4UOGjA
	xloEhFkz6l1RNTS0aR8xmnSFSzBQX1TPHJPcSNbi0YOvQk4QdnppwJrD1o/3bRnm6w==
X-Gm-Gg: AR+sD11VdvfprLKYaUpMLZObDFAY0ghScY6IpbjBZZ6JlPDaXpGerv9tn33zOsLONfl
	nm/TJi2eweCRjuh5H//F6j7CxaG4widF4YI3lZQct79cSdj3OQK116mOKroFb0QgQ+bMT0kOTiU
	zyAC/h6hHtINW9I5a75f5Nj9rtrbdPpBKo4DfLT29ztloQ1yM/FVYLKK+gRWhYOgDw5Q7l/2wlb
	e+gSepUjr1lyo7yHCD7FyII6iKgvwZuGIbWq4yd3vxHsxvanNV2oxSjqiCKs3Ph/11xxCBipBK2
	c2c71VPBWZbJEL7Ntm7vtnROmlDuhjCkI1DJh4uKHEze360dJPeVy1emnHimweASpGfQI2mYH3d
	ufTQkKPUDX+3BZ2SW6RnDAxPE1FZcRsRwC7snrwOtjcG1Gv4p5Yl5zQLfFbS5vtIiVjoKYOssI1
	oVpxMQ17lruaIwiLZ3luSOheuZ1x1sDPeBqb9PBTAREdodyMBcLCvoarJmwSJX+5XBQZLEm0Wk/
	XfrxGGnvpdNawV7ibRnWMqTqJRBaOSRF9Fgk/5cKb0APNam4Ka6nDYduIYkhSU=
X-Received: by 2002:a05:600d:849c:10b0:499:48bb:417e with SMTP id 5b1f17b1804b1-49948bb41d5mr5396535e9.2.1785751882919;
        Mon, 03 Aug 2026 03:11:22 -0700 (PDT)
Message-ID: <b742fec6-730a-4138-b5f5-7197f24df247@suse.com>
Date: Mon, 3 Aug 2026 12:11:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <07e90200-95b5-413f-9259-7f0481d36521@suse.com>
 <4531d02a-3a37-4c57-ba17-32034ba08cf9@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <4531d02a-3a37-4c57-ba17-32034ba08cf9@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1785751883-CD34D87B-CF92F006/0/0
X-purgate-type: clean
X-purgate-size: 2352

On 02.08.2026 17:55, Daniel P. Smith wrote:
> On 7/28/26 9:18 AM, Jan Beulich wrote:
>> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
>> With the function compiled out, its dedicated XSM hook also becomes
>> unreachable, so it is similarly guarded.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> It feels suspicious that the .priv_mapping() check is used for HVM guests
>> in shadow mode, but not for ones in HAP mode.
> 
> I believe a hint to it is laying in the comment,
> 
>   /*
>    * Let privileged domains transfer the right to map their target
>    * domain's pages. This is used to allow stub-domain pvfb export to
>    * dom0, until pvfb supports granted mappings. At that time this
>    * minor hack can go away.
>    */
> 
> Correct me if I am wrong, but get_page_from_l1e() is only used by PV and 
> HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done 
> through p2m_get_foreign() which will then be covered by 
> xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check.

Yes, sure; that wasn't the point of my comment. The point was that I'd
expect _the same_ hook to be used by the other path. Aiui if you make a
policy, you want same situations dealt with the same. Hence there shouldn't
be a need to express the same thing two ways.

> I think the question is how to address the TARGET_HACK situation.

I fear I don't really know what exactly you mean here.

>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -837,6 +837,8 @@ static int cf_check print_mmio_emul_rang
>>   }
>>   #endif
>>   
>> +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
>> +
>>   /*
>>    * get_page_from_l1e returns:
>>    *   0  => success (page not present also counts as such)
>> @@ -1038,6 +1040,8 @@ get_page_from_l1e(
>>       return -EBUSY;
>>   }
>>   
>> +#endif /* CONFIG_PV || CONFIG_SHADOW_PAGING */
>> +
> 
> Would it also not be prudent to #ifdef out the declaration in asm/mm.h?

Ah, yes, this looks possible for this function - the decl isn't needed for any
DCE-ing by the compiler.

> I think it would be a good defensive approach to condition out the 
> header declaration. Otherwise,
> 
> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Thanks, also for all the others.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 10:34:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 10:34:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381356.1624942 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqpzz-0001ji-Ck; Mon, 03 Aug 2026 10:34:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381356.1624942; Mon, 03 Aug 2026 10:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqpzz-0001jb-A7; Mon, 03 Aug 2026 10:34:23 +0000
Received: by outflank-mailman (input) for mailman id 1381356;
 Mon, 03 Aug 2026 10:34:23 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqpzy-0001jU-RW
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 10:34:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqpzy-007cMG-84
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:34:22 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a706ea6-5cb7-0a2a0a5109dd-0a2a450a85da-28
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:34:22 +0200
Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a706ead-f2d2-0a2a450a0019-d155da29c161-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:34:22 +0200
Received: by mail-ej1-f41.google.com with SMTP id
 a640c23a62f3a-c1c4c7ddaf6so490500366b.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:34:22 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd450d731sm524364066b.47.2026.08.03.03.34.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 03:34:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785753261; x=1786358061; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=RW+5JNTzwVuFTHOA2ETGOuWyQINN5n5cjuH4cgKFvXg=;
        b=YtYEbHloRzvkzvnlBgxOR8SFEHBvgvWfjXG1CRsL39XTeAyQXNrUgocv2ZPYw45i6s
         gY51SbXHuxi9JzlkXJcCvup+j0dafxkcrwZOm6eVaHsX5fn7WQgvf+dIy5GlloExvxMO
         MuOJTFGJK++mKnv2wvGojhAK3x9taC0JF3dCiYYWnYsM6yqPz/lCfeBXmcO9iGXkyasp
         hAIvO/m6whunp1D44/gir+u3phPLwqSppz4lF3VFBNGjqtM+26XwL/X0oUjY5UmtMFtP
         xF+V8gV+6ZfQ38S8QptYOHb7Wh1jDzuKAl9sBKb8Wyj+i17Dh/v3Ycq6WnxOeXL+NOCy
         cXdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785753261; x=1786358061;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=RW+5JNTzwVuFTHOA2ETGOuWyQINN5n5cjuH4cgKFvXg=;
        b=Ulnffc7cuJ4LCy0X00lj1gUS+rFCdVuVxniRJj8rn4Fwe+1OQ5qciZy4iidS4dm2+E
         dLFacrxsgIZzCWUSiyBl7iA8a2j8OjYeWypspEx2a49K+/TEe0gjCaPXRbYKM6Dwlthc
         qQYXKXXgbhOc1HouGXzZJBN4T51SWutyPBRTI0eDiNbZlA9TNOBmcXRoMmjKbxk015Ka
         xZ+qIpOdRoYQeMlvGQzIaAJr1xOYKY5ktXN03JHWPGD6zi2DpjIS+P06qtlsy9Znx9rM
         p98r/9MZEaJWbzt5a9OhkVys+8goXpA6nQ8cvA+iYJ9rqbx37+Rq/4QAdGMcvhx2+lXC
         a/dQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr6SHqBAMJkbwb6MeXI0gAjWoe80/jrRP7+fi9N7oH/mZsmJxZbITM593kkjcZy3QFxM9vUprk6vCs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhqL4vJobiTjanPvMQjJGTIIgFCQBuws+p1fNKxQUqRSfJneEZ
	JE3lbuI6//b6+JTVvvO1cSUfT1MIJQ+jGvt6yQVYIoPplp1ZsK+6q1TympWSMBnGyi0=
X-Gm-Gg: AR+sD12bVu1BksX/3+bWRGae4K3JC6zSf4u/jM4OFFjYR4qrFVK/OqMvBZWisEcKNPs
	F6PyeRs4yziB1Hs8IAqk/ZEUPDl+mdf8UPg6OpTFeNjP1dMzO/vy15/5DyqOArNp78gU77qtVD4
	flmpw7s27kHkh6q1AOv2FdrIX86VQ18+VDE/F9FMMYbGkzIIkOcErPR4pCmDha9pT3mMRQd1pN2
	J0RBgN2OKqo30mwPc9ToqkDlXbCnjSsGsi0OSpfm+UxhXEy343GE5AV1OvNp3eu1nLwmbmvv/lx
	yyQtdm0DoYkoKAFgd8JFb9P3T1XEyMIRkOHh8bu/uWnp9qj2B4mztkRhesZ9EOUmRVH+MVM8dtG
	rrNXajw3fq7hl0ZyIH20b21LXzPipiEFjBCqQ2Ni4IDpwNRKYsh0RKLEqOke7VXybF04xPX3Jv/
	3hd4t7j8MfCEuqJL8luJ6+IvEfYOYD8pBPpVsG5CkxetXDwr5wSNs9XYCTcwAWhOyTWtLNyN8w/
	mkpox4uslS6hcCK01fQpWdLkXro1vDCr3ZsbCBB6wYwtgObCTyRmqcYim0O6wyjm1xDyXZUlj9S
	2m73LlJliH9VTFE=
X-Received: by 2002:a17:907:c318:b0:c1f:b883:ed3b with SMTP id a640c23a62f3a-c1ff13e1e3cmr705662966b.4.1785753261255;
        Mon, 03 Aug 2026 03:34:21 -0700 (PDT)
Message-ID: <b90e2fa6-0725-4f39-8a5f-31b02c8aef72@suse.com>
Date: Mon, 3 Aug 2026 12:34:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] xen/sched: split scheduler vtable from scheduler
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com, oleksii.kurochko@gmail.com
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------NhSDnOO0pxwLPqjEg1D6vQsE"
X-purgate-ID: tlsNG-4011c0/1785753262-53ED2CFC-E433D674/0/0
X-purgate-type: clean
X-purgate-size: 13198

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------NhSDnOO0pxwLPqjEg1D6vQsE
Content-Type: multipart/mixed; boundary="------------0wFAAmCsdOzQMaRLESNA7cV0";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com, oleksii.kurochko@gmail.com
Message-ID: <b90e2fa6-0725-4f39-8a5f-31b02c8aef72@suse.com>
Subject: Re: [PATCH 0/7] xen/sched: split scheduler vtable from scheduler
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
In-Reply-To: <20260803050614.5222-1-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------0wFAAmCsdOzQMaRLESNA7cV0
Content-Type: multipart/mixed; boundary="------------CBTZ4VXU29aSPHmdICCq7QhP"

--------------CBTZ4VXU29aSPHmdICCq7QhP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDMuMDguMjYgMDc6MDYsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gRWFjaCBzdHJ1
Y3Qgc2NoZWR1bGVyIGN1cnJlbnRseSBkb3VibGVzIGFzIGJvdGggYSBzY2hlZHVsZXINCj4g
YmFja2VuZCdzIHN0YXRpYyB2dGFibGUgKG5hbWUsIG9wdF9uYW1lLCBzY2hlZF9pZCBhbmQg
ZXZlcnkNCj4gZnVuY3Rpb24gcG9pbnRlcikgYW5kIHRoZSBwZXItY3B1cG9vbCBydW50aW1l
IG9iamVjdCB0aGF0DQo+IHNjaGVkdWxlcl9hbGxvYygpIGFsbG9jYXRlcy4gQmVjYXVzZSB0
aGVzZSBhcmUgdGhlIHNhbWUgdHlwZSwNCj4gc2NoZWR1bGVyX2FsbG9jKCkgbWVtY3B5KClz
IHRoZSBlbnRpcmUgdnRhYmxlIGludG8gYSBmcmVzaCBoZWFwDQo+IGFsbG9jYXRpb24gZm9y
IGV2ZXJ5IGNwdXBvb2wgaXQgY3JlYXRlcy4gV2l0aCBOIGNwdXBvb2xzIHJ1bm5pbmcNCj4g
dGhlIHNhbWUgc2NoZWR1bGVyLCB0aGlzIGR1cGxpY2F0ZXMgTiBjb3BpZXMgb2YgaWRlbnRp
Y2FsIGZ1bmN0aW9uDQo+IHBvaW50ZXJzIGFuZCBpZGVudGlmeWluZyBmaWVsZHMgdGhhdCBu
ZXZlciBkaWZmZXIgYmV0d2Vlbg0KPiBpbnN0YW5jZXMgLSB0aGUgb25seSBmaWVsZHMgdGhh
dCBhcmUgZ2VudWluZWx5IHBlci1jcHVwb29sIGFyZQ0KPiBzY2hlZF9kYXRhIGFuZCBjcHVw
b29sLg0KPiANCj4gVGhpcyBzZXJpZXMgc3BsaXRzIHRoZSB2dGFibGUgb3V0IGludG8gaXRz
IG93biB0eXBlLCBzdHJ1Y3QNCj4gc2NoZWRfb3BzLCBzbyBpdCBjYW4gYmUgc2hhcmVkIGJ5
IGV2ZXJ5IGNwdXBvb2wgdXNpbmcgYSBnaXZlbg0KPiBzY2hlZHVsZXIgaW5zdGVhZCBvZiBj
b3BpZWQgcGVyIGNwdXBvb2wuIHN0cnVjdCBzY2hlZHVsZXIgaXMgbGVmdA0KPiBob2xkaW5n
IG9ubHkgd2hhdCBpcyBhY3R1YWxseSBwZXItaW5zdGFuY2U6IGEgcG9pbnRlciB0byB0aGUN
Cj4gc2hhcmVkIHNjaGVkX29wcywgcGx1cyBzY2hlZF9kYXRhIGFuZCBjcHVwb29sLg0KPiAN
Cj4gVGhlIHNlcmllcyBpcyBzdHJ1Y3R1cmVkIGFzIGludHJvZHVjZS9taWdyYXRlL3JlbW92
ZSwgc28gdGhhdA0KPiBldmVyeSBjb21taXQgYnVpbGRzIGFuZCBib290cyBvbiBpdHMgb3du
Og0KPiANCj4gICAgLSBUaGUgZmlyc3QgcGF0Y2ggYWRkcyBzdHJ1Y3Qgc2NoZWRfb3BzLCBS
RUdJU1RFUl9TQ0hFRF9PUFMoKSwNCj4gICAgICBhbmQgYSBzY2hlZF9vcHNfYXJyYXlbXSBh
bG9uZ3NpZGUgdGhlIGV4aXN0aW5nIHNjaGVkdWxlcnNbXSwNCj4gICAgICBleHRlbmRpbmcg
ZXZlcnkgbG9va3VwIHBhdGggKHNjaGVkdWxlcl9hbGxvYygpLA0KPiAgICAgIHNjaGVkX2dl
dF9ieV9uYW1lKCksIHNjaGVkdWxlcl9pbml0KCkpIHRvIHNlYXJjaCBib3RoIGFycmF5cy4N
Cj4gICAgICBUaGlzIGlzIHB1cmVseSBhZGRpdGl2ZSAtIG5vIHNjaGVkdWxlciB1c2VzIGl0
IHlldC4NCj4gDQo+ICAgIC0gVGhlIG5leHQgZml2ZSBwYXRjaGVzIGVhY2ggbWlncmF0ZSBv
bmUgc2NoZWR1bGVyIGJhY2tlbmQNCj4gICAgICAoY3JlZGl0LCBjcmVkaXQyLCBydGRzLCBh
cmluYzY1MywgbnVsbCkgZnJvbSBzdHJ1Y3Qgc2NoZWR1bGVyDQo+ICAgICAgdG8gc3RydWN0
IHNjaGVkX29wcy4gRWFjaCBpcyBzbWFsbCwgbWVjaGFuaWNhbCwgYW5kDQo+ICAgICAgaW5k
ZXBlbmRlbnRseSBiaXNlY3RhYmxlLCB3aXRoIG5vIGJlaGF2aW9yYWwgZGlmZmVyZW5jZSwg
c2luY2UNCj4gICAgICBzY2hlZHVsZXJfYWxsb2MoKSBidWlsZHMgYW4gaWRlbnRpY2FsIHJ1
bnRpbWUgc3RydWN0IHNjaGVkdWxlcg0KPiAgICAgIHJlZ2FyZGxlc3Mgb2Ygd2hpY2ggYXJy
YXkgYSBtYXRjaCBpcyBmb3VuZCBpbi4NCj4gDQo+ICAgIC0gVGhlIGZpbmFsIHBhdGNoIHJl
bW92ZXMgdGhlIG9sZCBzY2hlZHVsZXJzW10gYW5kDQo+ICAgICAgUkVHSVNURVJfU0NIRURV
TEVSKCkgcGF0aCBub3cgdGhhdCBub3RoaW5nIHVzZXMgaXQsIHNocmlua3MNCj4gICAgICBz
dHJ1Y3Qgc2NoZWR1bGVyIGRvd24gdG8geyBvcHMsIHNjaGVkX2RhdGEsIGNwdXBvb2wgfSwg
YW5kDQo+ICAgICAgdXBkYXRlcyBldmVyeSBhY2Nlc3NvciBpbiBwcml2YXRlLmggYWNjb3Jk
aW5nbHkuDQo+IA0KPiBGdXJrYW4gQ2FsaXNrYW4gKDcpOg0KPiAgICB4ZW4vc2NoZWQ6IGlu
dHJvZHVjZSBzdHJ1Y3Qgc2NoZWRfb3BzIGFzIGEgc2hhcmVkIHNjaGVkdWxlciB2dGFibGUN
Cj4gICAgeGVuL3NjaGVkOiBjcmVkaXQ6IG1pZ3JhdGUgdG8gbmV3IHNjaGVkX29wcw0KPiAg
ICB4ZW4vc2NoZWQ6IGNyZWRpdDI6IG1pZ3JhdGUgdG8gbmV3IHNjaGVkX29wcw0KPiAgICB4
ZW4vc2NoZWQ6IHJ0ZHM6IG1pZ3JhdGUgdG8gbmV3IHNjaGVkX29wcw0KPiAgICB4ZW4vc2No
ZWQ6IGFyaW5jNjUzOiBtaWdyYXRlIHRvIG5ldyBzY2hlZF9vcHMNCj4gICAgeGVuL3NjaGVk
OiBudWxsOiBtaWdyYXRlIHRvIG5ldyBzY2hlZF9vcHMNCj4gICAgeGVuL3NjaGVkOiByZW1v
dmUgb2xkIHNjaGVkdWxlciByZWdpc3RyYXRpb24sIHNocmluayBzdHJ1Y3Qgc2NoZWR1bGVy
DQo+IA0KPiAgIHhlbi9hcmNoL2FybS94ZW4ubGRzLlMgICAgICB8ICAgMiArLQ0KPiAgIHhl
bi9hcmNoL3BwYy94ZW4ubGRzLlMgICAgICB8ICAgMiArLQ0KPiAgIHhlbi9hcmNoL3Jpc2N2
L3hlbi5sZHMuUyAgICB8ICAgMiArLQ0KPiAgIHhlbi9hcmNoL3g4Ni94ZW4ubGRzLlMgICAg
ICB8ICAgMiArLQ0KPiAgIHhlbi9jb21tb24vc2NoZWQvYXJpbmM2NTMuYyB8ICAxMSArLS0t
DQo+ICAgeGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMgICAgIHwgIDgwICsrKysrKysrKysrKysr
KystLS0tLS0tLS0tLS0tDQo+ICAgeGVuL2NvbW1vbi9zY2hlZC9jcHVwb29sLmMgIHwgICA2
ICstLQ0KPiAgIHhlbi9jb21tb24vc2NoZWQvY3JlZGl0LmMgICB8ICAgNSArLQ0KPiAgIHhl
bi9jb21tb24vc2NoZWQvY3JlZGl0Mi5jICB8ICAgNSArLQ0KPiAgIHhlbi9jb21tb24vc2No
ZWQvbnVsbC5jICAgICB8ICAgNSArLQ0KPiAgIHhlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5o
ICB8IDEwMCArKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0NCj4gICB4ZW4v
Y29tbW9uL3NjaGVkL3J0LmMgICAgICAgfCAgIDUgKy0NCj4gICB4ZW4vaW5jbHVkZS94ZW4v
eGVuLmxkcy5oICAgfCAgIDggKy0tDQo+ICAgMTMgZmlsZXMgY2hhbmdlZCwgMTE2IGluc2Vy
dGlvbnMoKyksIDExNyBkZWxldGlvbnMoLSkNCj4gDQoNCllvdSBoYXZlIGEgc2VyaWVzIGhl
cmUgd2hpY2ggaXMgYWRkaW5nIDExNiBsaW5lcyBhbmQgcmVtb3ZpbmcgMTE3Lg0KDQpQYXRj
aCA3IGFsb25lIGlzIHJlbW92aW5nIDI0OCBsaW5lcyB3aGlsZSBhZGRpbmcgNjcgbGluZXMu
DQoNClNvIGluIHRoZSBlbmQgdGhlcmUgaXMgYSBzaW5nbGUgcGF0Y2ggaW4gdGhpcyBzZXJp
ZXMgd2hpY2ggaGFzIG1vcmUgY29kZQ0KY2h1cm4gdGhhbiB0aGUgY29tcGxldGUgc2VyaWVz
IHdoZW4gYWRkZWQgaW4gb25lIGdvLg0KDQpJT1c6IG1ha2luZyB0aGlzIGp1c3QgYSBzaW5n
bGUgcGF0Y2ggd291bGQgYmUgZWFzaWVyIHRvIHJldmlldyB0aGFuIHRoZQ0KbGFzdCBwYXRj
aCBhbG9uZSwgbGV0IGFsb25lIGFsbCB0aGUgdGVtcG9yYXJ5IG1vZGlmaWNhdGlvbnMgd2hp
Y2ggd291bGQNCmJlIGdvbmUgd2hlbiBtZXJnaW5nIGFsbCBwYXRjaGVzIGludG8gb25lLiBB
bmQgd2l0aCB0aGF0IHlvdSBjb3VsZCBldmVuDQpkcm9wIHNvbWUgb2YgdGhlIHJlbmFtaW5n
IHlvdSBkaWQgKGUuZy4gaW4gdGhlIGxpbmtlciBmaWxlKSwgbWFraW5nIHRoZQ0KZGlmZiBl
dmVuIHNtYWxsZXIuDQoNCkkgYWdyZWUgd2l0aCB0aGUgb3ZlcmFsbCBnb2FsLCBidXQgSSdt
IHNwYXJpbmcgbXkgdGltZSBkb2luZyBhIHRob3JvdWdoDQpyZXZpZXcgb2YgdGhlIHNlcmll
cyBpbiB0aGlzIHNoYXBlLg0KDQoNCkp1ZXJnZW4NCg==
--------------CBTZ4VXU29aSPHmdICCq7QhP
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------CBTZ4VXU29aSPHmdICCq7QhP--

--------------0wFAAmCsdOzQMaRLESNA7cV0--

--------------NhSDnOO0pxwLPqjEg1D6vQsE
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwbqwFAwAAAAAACgkQsN6d1ii/Ey9T
wwgAjxhwwwWWs686CCBFHwePzXm29voDe8LchNCVr02zbdtFKaSEqU1rGaMJl39LT4pgr8CHOnFy
KIijRAkVwI5TgcFoPamVfWN3WJ56teAzVjEC7thKFi/StkbxvrXYJa6TIrTUzBnsLl96HNPQJMGh
izbuaoyhOgw3IUSd2hF1RTYf6gVF8cLEX8ZHlL/q1jYH5Qx1+hJvKc1esPqobcaMOzQP2wWPaNb3
xL+b219muAc1khjAS9GGVnUIeV9w2ErJcPM7moAZHc8oDpX+yNEgk5Vq+XiZ8pJYCOGj9fuBBcXS
ieQz+a0t0jjLwMPuvGzMtMytV2ew4zn8cCVUXe++TA==
=r5DE
-----END PGP SIGNATURE-----

--------------NhSDnOO0pxwLPqjEg1D6vQsE--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 10:37:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 10:37:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381363.1624953 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqq2k-0002MZ-QM; Mon, 03 Aug 2026 10:37:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381363.1624953; Mon, 03 Aug 2026 10:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqq2k-0002MS-Mp; Mon, 03 Aug 2026 10:37:14 +0000
Received: by outflank-mailman (input) for mailman id 1381363;
 Mon, 03 Aug 2026 10:37:14 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqq2k-0002MH-07
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 10:37:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqq2i-004fKp-Hp
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:37:12 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a706f4f-e002-0a2a0a5209dd-0a2a4507ca84-28
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:37:12 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a706f58-b4ea-0a2a45070019-d1558034ccd5-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:37:12 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4955aa106b1so17849745e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:37:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd456a6besm30189824f8f.22.2026.08.03.03.37.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 03:37:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785753432; x=1786358232; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=W1YOnSiXDFhTOBMMsgIEia7N6LZYw+jLgptOHs4zxWg=;
        b=SLbETNjhWzYILVPBwHWG9/LWpor6ZsSC+L3Ij5OuOnMstXU9AbD2yJ9S4Xv7Da2bbT
         3Ba7cX8McoVO/106neU8za4wQZpgtHn2RhBLetPp+zmTutlKJQZyP+P4Mw+azdldW2vi
         q9ISdK58wP3Ov7kBQ4g0iaha73BD3zsjj5qU8xJphQRNOWLf9cDK42TnHm8Zt4Lhm5ab
         Ky9h2+lagY3nQLia2L1E2FHNHdfIFjksV81NTsZgriri1wODHAR4hYHYHutrDtJAbKMl
         lDy6dfBK3KJWPepPhFXsIIXVdR6rPsdWB4ja2oxdmdz/8nZX3oZ7yuMXzCYAyh0vmyt3
         Xz+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785753432; x=1786358232;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=W1YOnSiXDFhTOBMMsgIEia7N6LZYw+jLgptOHs4zxWg=;
        b=Y6+qaMlarSGQ5OIkQzAz3r+qhhus5Nn6QacZ4sbxgkf4wcznlk0DfdsOcjN60zN/Wj
         B2JInbWW8nuDX7Wd+hhK85rNbbCBUMM/GBZxg7PWny6N8g4zoHgmN5HXxSIOSHMWd3i2
         RhEGs/3XBYGTAL2vBGeYTXEhLFeowPSa2hZfszsWSF5scYEsTN6wRa5MPeCr18Xx0Th0
         3rXhVXFmcjqqRRdm0j5k2s5K/FWkw4OYckkpGsekxv4JC5+6nHHRUITIpYaeXglSk2EQ
         pGTUBOjygxkej5sqEjQw5p1iw/llx2eM2A8vEInVUsrg9pyRJ7s4nYCnOGhENTQjvKvh
         ODwQ==
X-Forwarded-Encrypted: i=1; AHgh+RrtJYP9kuDP+tg8mYKQhgC6X6/IF9lcZLpfO+nrRkt1dAJdJsx+QmZNokZ3RROXWefLEaTX1K0Eja8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7cbB3wzL4M+MVl/oWBQJJ0R5ppfr6wi0SYPSG1dANnPFlhT3j
	f7dODg13Mxf/1bnAkz8oY7+7E5A/Tvh1fecMyuwwjVymNVYp3JVf/4OdtzNJCegdrA==
X-Gm-Gg: AR+sD13dvl2i3fKIxyiDUo7thAupV5mdVfn8bRs875jEdf0LNakXRN5T5IE02ijJC9R
	lNzRdzi+TlOkBHLaTzk/EC9zENRrSjf7XMPwqwgL/CR6yv2OdwnPB6qbFWNACSxE6++DDhAOYQd
	/O7g3WibB4bdl4+y8hV+WkX+ipgGn5SEgCsEDsSG9rzDfeYdTRfJPbAD/FoJmGe1otonUQpH/4c
	1jsEXKFmWwJ4+v8XmQfa18J1oyd+L68xbz80979pzOlEVt2OkUsJIYI0gqd7rz+NCgepIYEWpR6
	OEovdaLZp2pwslmCD1WCBuxOKtQaJyKWRCdQmu9lmKc6Z6fO6plsRPWDwFLLguheOyxGKm+BsMX
	MZxpIGLRaO6qgShQAwp6VrmpeoLxxcndd8xMcsEyZ1W0GsXPkwGyjLUhSIPwuO9kzgrynZT6acd
	oti57ypbrwPrPh4wT+pgA6yzYcfsIct14Evm5c90zE+yqVO3/Bsnek/p0fQCnxUgu1bwKm/1hOl
	Ija2LB8/K5ZozRyI48dN1/QDR6yIFcRkIVgcP0+CuogqIYcJgSF
X-Received: by 2002:a05:600c:2294:b0:492:4e09:9fc1 with SMTP id 5b1f17b1804b1-4980c67af97mr170252525e9.15.1785753431921;
        Mon, 03 Aug 2026 03:37:11 -0700 (PDT)
Message-ID: <3b1e19f9-ed72-4898-aa1a-f9f43c1700a0@suse.com>
Date: Mon, 3 Aug 2026 12:37:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 02/17] xen/riscv: add basic VGEIN management for AIA
 guests
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b141b8d976719bb9b76147cacfd5842fb7aac74e.1784560663.git.oleksii.kurochko@gmail.com>
 <6501f040-ea59-4e78-8854-030f786dbcf7@suse.com>
 <191a9ddc-9f37-4d26-9141-7dfaf88cb26c@gmail.com>
 <489a1b05-4ae5-44ac-a73b-485669190b59@suse.com>
 <aca9e72d-ff6d-49e0-b128-6675c5521493@gmail.com>
 <79ea95df-29bf-4c9e-8097-2c2b991f27bf@suse.com>
 <39aa93bb-edb8-4f05-8b62-c2677d12fb0b@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <39aa93bb-edb8-4f05-8b62-c2677d12fb0b@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1785753432-A68D9AE4-5E3DCEC8/0/0
X-purgate-type: clean
X-purgate-size: 3987

On 31.07.2026 16:59, Oleksii Kurochko wrote:
> 
> 
> On 7/30/26 6:03 PM, Jan Beulich wrote:
>> On 30.07.2026 17:46, Oleksii Kurochko wrote:
>>> On 7/30/26 9:42 AM, Jan Beulich wrote:
>>>> On 29.07.2026 16:55, Oleksii Kurochko wrote:
>>>>> On 7/27/26 5:41 PM, Jan Beulich wrote:
>>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>>> It was decided to add support for IMSIC from the start instead of having APLIC
>>>>>>> operate in direct delivery mode, as it requires a trap-and-emulation approach,
>>>>>>> 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.
>>>>>>>
>>>>>>> Add 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. When assigning a VGEIN, the corresponding value
>>>>>>> is written to the VGEIN field of the guest hstatus register so that
>>>>>>> VS-level external interrupts are delivered from the selected interrupt
>>>>>>> file.
>>>>>>
>>>>>> And when exactly is this "assignment" intended to occur? vgein_assign() and
>>>>>> vgein_release() have no callers here, so this remains entirely unclear.
>>>>>
>>>>> [A] Agreed, I should have added that information to the commit message:
>>>>>
>>>>> VGEIN is assigned (via vgein_assign()) before jumping to the new vCPU
>>>>> execution context (in continue_new_vcpu()) and is re-assigned during
>>>>> vCPU migration from one pCPU to another.
>>>>>
>>>>> VGEIN is released (via vgein_release()) on the old pCPU during migration.
>>>>
>>>> That is, state of that vCPU is held in hardware for perhaps an extended
>>>> period of time after the vCPU was last de-scheduled. That's a fair
>>>> optimization (we do something similar on x86, albeit that has been
>>>> increasingly under question lately). However, doesn't this then require
>>>> sync_local_execstate() to become non-empty?
>>>
>>> IIUC, sync_local_execstate() is needed for the lazy context switch case
>>> when switching from vCPUA to the idle vCPU.
>>
>> Or when full state is to be obtained for a vCPU, for example.
> 
> I assume you're referring to XEN_DOMCTL_getvcpucontext, right?

Yes.

> In general, it seems that sync_local_execstate() is primarily an 
> optimization. If lazy switching isn't supported, then every time a vCPU 
> is de-scheduled, its state must be fully saved to memory. My 
> understanding is that everything will still work correctly, just less 
> efficiently.

The lazy switching is an optimization, yes. If any state is kept in
hardware, sync_local_execstate() has to be used when full state of a
vCPU is to be obtained. Supplying back stale state of "guest interrupt
files" can't be correct. (Of course you can also arrange to obtain
up-to-date state by custom means, but imo that's likely less desirable.)

> I'm curious how much this optimization actually helps. How often does it 
> happen that a vCPU is de-scheduled from a pCPU and then immediately 
> scheduled back onto the same pCPU without any other vCPU being scheduled 
> in between?

That heavily depends on overall load of the system. When pCPU-s aren't
over-subscribed, a HVM vCPU getting de-scheduled to wait for qemu to
handle a certain operation may very well be able to resume on the same
pCPU after completion of the ioreq. The less overhead there, the better.
(Just to give an example.)

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 10:41:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 10:41:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381373.1624960 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqq6c-0004f4-CZ; Mon, 03 Aug 2026 10:41:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381373.1624960; Mon, 03 Aug 2026 10:41:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqq6c-0004ex-9Y; Mon, 03 Aug 2026 10:41:14 +0000
Received: by outflank-mailman (input) for mailman id 1381373;
 Mon, 03 Aug 2026 10:41:13 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqq6b-0004er-6Z
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 10:41:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqq6a-004uuD-JD
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:41:12 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70703b-5cb7-0a2a0a5109dd-0a2a450885bc-28
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:41:08 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a707044-f659-0a2a45080019-d155dd33a93f-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 12:41:08 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-4720f3bf164so2502575f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 03:41:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd41e2cf1sm31636029f8f.10.2026.08.03.03.41.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 03:41:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785753668; x=1786358468; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=IawgCP+jZFb3uk7JaxA8OP7ijbXNyIydlK45oaJI28w=;
        b=STED+EnLx9pXeJULZgrne/eA/TX8R8pIn5YHWvk9navYUEXXSaNKjlpEd+77MeXKZV
         ZFjfKhxpiyCO5wwMPkMZO7M8vElV9o0uXE6IHEIuUpkwPPJ0+4mDftcUD9pKqech4NNp
         TTfV1/xEL3hMSF8f0ncKZq1bxq50zRhjmv2cWNaNK0D5aRcFPDpnoLBbYvVPy68DRks3
         /jKJOyt1MpGSee22NY0dnb/6dwG7R/mu6C1xicaBHzNFni6gbaykiWvEX/qLw4DGEBcO
         4Kpmmwn8qvo1cF1zlbChWBqi14VPivgNeXe0IcQ1tlEBNMKYAE8hQCtlOnlJmoC8G77C
         Cc0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785753668; x=1786358468;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=IawgCP+jZFb3uk7JaxA8OP7ijbXNyIydlK45oaJI28w=;
        b=DsnKHt0/fRC5P+gpTIyAceYkxwv4XeHwP99aceA/Ix6+yYmCc6t26mZHEYLR9tWmzH
         1MYVFR7x7LAdLkNbYFQLYeK1qSoaPQDSHpZFwRvYtSN3UKvmO4ZxVXBNX+JIdGfQxEb6
         b/PmlGoRCwl8nMx/KzAdv2Bn/Ixr4f6d71OpciHpDejYiwD7UM6uAZkvquB5xaXt3R6U
         LHhFfleyPRAb1nGkjbn4s8h3RbJr2L3LToguhTKC4aCCtdOFp8eFDpNjJINvKSFhhOAM
         HcZE3M3Qpb314M0BZnQYuTEUncpjWA75qjfk+CdWpSSDmH4wU5ba9Bej4vLwgsT3QbmV
         nhMw==
X-Forwarded-Encrypted: i=1; AHgh+RqEB+Ykttz3QTAhFRcVEGJQBu454CeNlE+ls1Huhv/XOwrc8/2UEd30LxuHW0T/ZxuRCGp99EEH3Og=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzfw1u38NhetE1znUqNwgG9ONhKlG8R057YnVPmh4Qm3DLZLQEk
	LahmILfzWDVQDqrLaCWzTI7PD3u4RpE8YRak0dasB+aCdhnIZ9nfQv0/7sJb18OpnA==
X-Gm-Gg: AR+sD12oJYUH2A7sgtvG8lfSuTh1i7JYgbgD/OLGGiPGu1pwRqiytlouu8ikWTwVPP3
	yY0uamUvy/4I9NYXXE141iOXgJxPzyQ85ObFOP+E49xqFcuRqxJqUC1T3MoKdmQ9xjpwzWSbh8Z
	mkGPlap9Ku/nHk6kr+NEHJAXfek9od/zJDvuD8AiY/WmIrsVBCriHlyTKaUcMy7Ts37HkSVY+xA
	ziow4IBDYztJB78lnJdhhrvwmvMCCghM1hpupm9r2s0Ntj9gASvC25F+RFF4AsNiFopXT9ZlgtV
	67JUtNsQLB8KvhTAHVkkrMWDZFtwTrFuigYpVi2llCXaN5Jw57cqObVD+Pwyc+OFIWjuxe9PVxk
	6msopjkE+oXOzDTlxOPDfJxfeBchyskaXTCUgBm1DMCb/xMTInPJvRjzWePzI2RcnRU7WjSiy0A
	GQkQBE1LWOKz3lJ7gXyziuxDsXpJwhMZ6h2xP96+qGzezOA4IH2ZslXLDpjj16bg/p0Sbo7YAgU
	FvnB8VClRH+73aa0wVhAPxxyflNQO1xRdAtrADlpx5AZbHvOqoP
X-Received: by 2002:a05:6000:18a6:b0:47f:7fe0:a287 with SMTP id ffacd0b85a97d-47fd725b307mr23032494f8f.2.1785753667898;
        Mon, 03 Aug 2026 03:41:07 -0700 (PDT)
Message-ID: <51e537a4-f568-458d-9625-ada7fbebd842@suse.com>
Date: Mon, 3 Aug 2026 12:41:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <704870c1-18ec-4c7b-873c-e07e77ae0d39@suse.com>
 <d5867843-802d-493f-a535-1f40d9337b63@gmail.com>
 <2ef6b295-862b-40be-a7d2-c94a6378126b@suse.com>
 <636a6183-8c66-41b2-b820-6a02098fd33d@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <636a6183-8c66-41b2-b820-6a02098fd33d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785753668-D6D4087B-0EB09F8A/0/0
X-purgate-type: clean
X-purgate-size: 3188

On 31.07.2026 17:24, Oleksii Kurochko wrote:
> On 7/30/26 6:09 PM, Jan Beulich wrote:
>> On 30.07.2026 18:03, Oleksii Kurochko wrote:
>>> On 7/28/26 2:23 PM, Jan Beulich wrote:
>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/riscv/mmio.c
>>>>> @@ -0,0 +1,145 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>>>> +/*
>>>>> + * Copyright (C) Vates
>>>>> + */
>>>>> +
>>>>> +#include <xen/bsearch.h>
>>>>> +#include <xen/lib.h>
>>>>> +#include <xen/rwlock.h>
>>>>> +#include <xen/sched.h>
>>>>> +#include <xen/sort.h>
>>>>> +#include <xen/xvmalloc.h>
>>>>> +
>>>>> +#include <asm/current.h>
>>>>> +#include <asm/mmio.h>
>>>>> +
>>>>> +static enum io_state handle_read(const struct mmio_handler *handler,
>>>>> +                                 struct vcpu *v,
>>>>> +                                 mmio_info_t *info)
>>>>> +{
>>>>> +    register_t r = 0;
>>>>> +    enum io_state rc;
>>>>> +
>>>>> +    rc = handler->ops->read(v, info, &r);
>>>>> +    if ( rc == IO_HANDLED )
>>>>> +        info->data = r;
>>>>
>>>> Extending my earlier comment: Why could ->read() not put the value directly
>>>> into info->data? And why ...
>>>>
>>>>> +static enum io_state handle_write(const struct mmio_handler *handler,
>>>>> +                                  struct vcpu *v,
>>>>> +                                  mmio_info_t *info)
>>>>> +{
>>>>> +    return handler->ops->write(v, info, info->data);
>>>>
>>>> ... can't write take the value directly from info->data?
>>>
>>> I totally agree, it can. Do you think it is better to keep ->data and
>>> drop an argument 'r' or vice versa?
>>
>> How can I know? You know future plans you have.
>>
>>>>> +}
>>>>> +
>>>>> +/* Assumes mmio regions are not overlapping. */
>>>>
>>>> Are you guaranteeing this anywhere?
>>>
>>> There is no such guarantee. register_mmio_handler() simply adds the
>>> handler to the handlers array without performing any checks. I can add
>>> such a check. The only question is whether it should be enabled only in
>>> debug builds or in all builds.
>>
>> Depends on what other badness can happen when this is violated. My gut
>> feeling is that checking in debug builds may be enough.
> 
> Overlapping regions would be a Xen bug rather than something a guest can 
> trigger — register_mmio_handler() is only called from Xen's own emulated 
> device code, so the layout isn't under guest control.
> 
> The badness is worse than just mis-emulating one device though: 
> cmp_mmio_handler() is used both by bsearch() and by sort(). With 
> overlapping regions it's no longer a consistent ordering, so sort() may 
> produce an arbitrary order and lookups can then fail (or match the wrong 
> handler) even for regions which don't overlap themselves. That would 
> show up as a spurious fault injected into the guest, which is quite hard 
> to debug.

Didn't you say you'd get rid of the use of sort()?

> So I agree a check is worthwhile; I'll add one under CONFIG_DEBUG in 
> register_mmio_handler().

Some assertion then hopefully, rather than an open-coded use of CONFIG_DEBUG.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 11:13:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 11:13:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381383.1624978 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqqbP-0002XC-NQ; Mon, 03 Aug 2026 11:13:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381383.1624978; Mon, 03 Aug 2026 11:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqqbP-0002X4-KF; Mon, 03 Aug 2026 11:13:03 +0000
Received: by outflank-mailman (input) for mailman id 1381383;
 Mon, 03 Aug 2026 11:13:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wqqbO-0002Wy-32
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 11:13:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqqbM-00EqOR-UG
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 13:13:00 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a7077b7-2eae-0a2a0a5409dd-0a2a4501d6f4-0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 13:12:55 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a7077b7-5984-0a2a45010019-d155802ee440-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 13:12:55 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso12807485e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 04:12:55 -0700 (PDT)
Received: from [192.168.1.109] ([78.173.117.153])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49808199a5csm317148575e9.4.2026.08.03.04.12.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 04:12:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785755575; x=1786360375; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=n15kLGrJ+FWpwmzVHEDI31BEOzMm4iFVML/1saYo8ro=;
        b=r/j3k3rL3Ndi8EtK411WXb2szOgSQ/bhwXJPWLxZz+CsXK8XvyRW6ETJ7eMFeo/F9r
         5S8EV2i2HpWy8vm4Ne9bQKiI6AR6fPUPaO67PKh0HP4S45EiRiKK78qlNKXIK11/t5gG
         VGOGqpZWZeeO+N3yeEuZwc1L6ZuS7XWBH4jC9JqZ6f3BOGP8I3/4EnL2CPMJY21iB5Ik
         h+4gz7dtbgpzGw+r2dFF3qp/TMkxo+TcdCGbOnMiShnj0F60kS4yVjwB3GuDzZEu7ZCI
         i/1Y1h2taYvPXjWvRA0jvRBs4Sp2kzywBKNMIUXVKA+V5NXqgjMqlHvHYkAD7h6rerwK
         iyfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785755575; x=1786360375;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=n15kLGrJ+FWpwmzVHEDI31BEOzMm4iFVML/1saYo8ro=;
        b=fCBUDRDWKPoKrS21NUdkCIxtuvz1QvwwPjrAkNmpckCR/p+ljgMcpTNLcgFqSTQmVA
         QE11iEzMDF+4VS4slEU6j2vedrpFb7ZpT9EJAnAolFzJjMOJPocRQ6d0vb2NzGpz/Fy1
         Bb2Mv9gNK+K5Knrx4jTBvnKmXGZKy7iD++1yZpKGnqFnZBU5+oQXZ29FhHSA1+xL4Yxt
         SOsUiRbEO3YYdSSlQIKehD/aTjn/WjRaatvDAMKqWti0y6mtSDTefdXf5CLgMPXKCuqd
         28hXqR2lnSUJGdAOCoP+6dfcSZIfcFgMfO5qM1On0zvWEVLKFu0DOr5DLEZlOIXUPLDQ
         vRQw==
X-Forwarded-Encrypted: i=1; AHgh+RrwqVaptoUzrKAy05aFLeTUoYjNQmZd61C7WPPt7VerfxjtwCc9NXYus35OEWjSyHrnuQetzFriD6E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGoMpQIcH2GhoaDmVKCblaK83IalHZi+1EOYHZr4Bz1rJq+qAd
	qbUsvTa/N4Djd6hyOE7cZGRhM4ehTBekhJfwSCbUt6iJSewKQ8XPvPIo
X-Gm-Gg: AR+sD12u0ClY4xO7CnKSZU7x6gob4laFzZIn4Z2Cnq8SHmAIwYYHCzRejtKQMz0tczu
	JFMuIGbAOi18MwAdPoo/VP093kWTa6EgYJ2s+UXMQ7YcMIlUPyfT4I65cIeOcHbD6UeGzg/3pCN
	fNaroslCTit4RvToz47xyXGWvDM4Jd0TqJHVb965bk6Tjg5QOs5jdFUwo+9hykzErJHcoDNSdfi
	m37Gtz04IT/50irEfG+ucu7hwfD85EUD1VmaZGcju8mZnubYXInvKp97ldKeXlHNho0VV6l0qei
	e9KhF1lM8GrT9T4BkZhaCwnr0BI2iGrGKN//kUvOsTEUN56ElKf+iwdHpKZT4FUXIqWWDDQU7pm
	/5TMq+7R8h7uNF/dZeZPYGbJPK7miLpLAB5Rlr2BVM65IiSKbmDyIi96Rgwz1V+yG7bV24LbAR3
	oYpmHsTyFJAPariC+Z3/4RsQBMvatYSa4pI6d8YObe2fAys6AlX3AUW0QLsusc5m1NemkSgi/0Z
	q9sFUw=
X-Received: by 2002:a05:600c:628c:b0:496:c0f6:78d6 with SMTP id 5b1f17b1804b1-4980c64b5a7mr227722965e9.2.1785755574994;
        Mon, 03 Aug 2026 04:12:54 -0700 (PDT)
Message-ID: <6a6a04dc-0d8c-4b7a-a190-09113b3b68cd@gmail.com>
Date: Mon, 3 Aug 2026 14:12:48 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] xen/sched: split scheduler vtable from scheduler
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com, oleksii.kurochko@gmail.com
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
 <b90e2fa6-0725-4f39-8a5f-31b02c8aef72@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <b90e2fa6-0725-4f39-8a5f-31b02c8aef72@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785755575-BC75B757-76A94DF6/0/0
X-purgate-type: clean
X-purgate-size: 4743

Hi Jürgen,

On 8/3/26 13:34, Jürgen Groß wrote:
> On 03.08.26 07:06, Furkan Caliskan wrote:
>> Each struct scheduler currently doubles as both a scheduler
>> backend's static vtable (name, opt_name, sched_id and every
>> function pointer) and the per-cpupool runtime object that
>> scheduler_alloc() allocates. Because these are the same type,
>> scheduler_alloc() memcpy()s the entire vtable into a fresh heap
>> allocation for every cpupool it creates. With N cpupools running
>> the same scheduler, this duplicates N copies of identical function
>> pointers and identifying fields that never differ between
>> instances - the only fields that are genuinely per-cpupool are
>> sched_data and cpupool.
>>
>> This series splits the vtable out into its own type, struct
>> sched_ops, so it can be shared by every cpupool using a given
>> scheduler instead of copied per cpupool. struct scheduler is left
>> holding only what is actually per-instance: a pointer to the
>> shared sched_ops, plus sched_data and cpupool.
>>
>> The series is structured as introduce/migrate/remove, so that
>> every commit builds and boots on its own:
>>
>>    - The first patch adds struct sched_ops, REGISTER_SCHED_OPS(),
>>      and a sched_ops_array[] alongside the existing schedulers[],
>>      extending every lookup path (scheduler_alloc(),
>>      sched_get_by_name(), scheduler_init()) to search both arrays.
>>      This is purely additive - no scheduler uses it yet.
>>
>>    - The next five patches each migrate one scheduler backend
>>      (credit, credit2, rtds, arinc653, null) from struct scheduler
>>      to struct sched_ops. Each is small, mechanical, and
>>      independently bisectable, with no behavioral difference, since
>>      scheduler_alloc() builds an identical runtime struct scheduler
>>      regardless of which array a match is found in.
>>
>>    - The final patch removes the old schedulers[] and
>>      REGISTER_SCHEDULER() path now that nothing uses it, shrinks
>>      struct scheduler down to { ops, sched_data, cpupool }, and
>>      updates every accessor in private.h accordingly.
>>
>> Furkan Caliskan (7):
>>    xen/sched: introduce struct sched_ops as a shared scheduler vtable
>>    xen/sched: credit: migrate to new sched_ops
>>    xen/sched: credit2: migrate to new sched_ops
>>    xen/sched: rtds: migrate to new sched_ops
>>    xen/sched: arinc653: migrate to new sched_ops
>>    xen/sched: null: migrate to new sched_ops
>>    xen/sched: remove old scheduler registration, shrink struct scheduler
>>
>>   xen/arch/arm/xen.lds.S      |   2 +-
>>   xen/arch/ppc/xen.lds.S      |   2 +-
>>   xen/arch/riscv/xen.lds.S    |   2 +-
>>   xen/arch/x86/xen.lds.S      |   2 +-
>>   xen/common/sched/arinc653.c |  11 +---
>>   xen/common/sched/core.c     |  80 ++++++++++++++++-------------
>>   xen/common/sched/cpupool.c  |   6 +--
>>   xen/common/sched/credit.c   |   5 +-
>>   xen/common/sched/credit2.c  |   5 +-
>>   xen/common/sched/null.c     |   5 +-
>>   xen/common/sched/private.h  | 100 +++++++++++++++++++-----------------
>>   xen/common/sched/rt.c       |   5 +-
>>   xen/include/xen/xen.lds.h   |   8 +--
>>   13 files changed, 116 insertions(+), 117 deletions(-)
>>
> 
> You have a series here which is adding 116 lines and removing 117.
> 
> Patch 7 alone is removing 248 lines while adding 67 lines.
> 
> So in the end there is a single patch in this series which has more code
> churn than the complete series when added in one go.
> 
> IOW: making this just a single patch would be easier to review than the
> last patch alone, let alone all the temporary modifications which would
> be gone when merging all patches into one. And with that you could even
> drop some of the renaming you did (e.g. in the linker file), making the
> diff even smaller.
> 
> I agree with the overall goal, but I'm sparing my time doing a thorough
> review of the series in this shape.
> 
> 
> Juergen

My first instinct was actually to just send this as one patch. I split 
it up because I wanted each scheduler's conversion to be its own small, 
bisectable commit, but you're right that it's not worth it here. 

I will squash it into a single patch and resend. But I would still like 
to rename SCHEDULER_ARRAY to SCHED_OPS_ARRAY in the per-arch linker files 
and other related variable names in other files, since they now hold 
sched_ops entries rather than struct scheduler ones, and I think the name 
should reflect that. 

Thanks for the feedback,

Furkan Caliskan



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 11:19:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 11:19:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381391.1624987 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqqhw-0003qh-C2; Mon, 03 Aug 2026 11:19:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381391.1624987; Mon, 03 Aug 2026 11:19:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqqhw-0003qa-92; Mon, 03 Aug 2026 11:19:48 +0000
Received: by outflank-mailman (input) for mailman id 1381391;
 Mon, 03 Aug 2026 11:19:46 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqqhu-0003qB-Ba
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 11:19:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqqht-00EYud-62
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 13:19:45 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a707948-2eae-0a2a0a5409dd-0a2a45049896-34
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 13:19:45 +0200
Received: from [209.85.218.46] (helo=mail-ej1-f46.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a707950-b57f-0a2a45040019-d155da2eb020-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 13:19:44 +0200
Received: by mail-ej1-f46.google.com with SMTP id
 a640c23a62f3a-c16794450aeso457755166b.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 04:19:44 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd44e9ff0sm486592866b.42.2026.08.03.04.19.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 04:19:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785755984; x=1786360784; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Y6ZiLzDwyrefHpHNId0SfIDP7KVAik7WooDx4DLjY7M=;
        b=TcXCcNKeKOr4GXR4qbdD+NAvgMD4FP+ZLkB6uKPfqHQgFf7rakqprMST7qhcmL2ksK
         nwF8YOqAGNyrdCRV1dd22meAJoJE26qAsgkaJ8RHluB8uZNcr3tpgiXvumLnynqhpmAs
         /GY16HawYCPZ1IVTqE71MA6yRGAErzIpEJ5TBGJO8qY8yPOgQP8Wud2Zq9S6qw/bnIHU
         eaQ34OoG9LBkcovu4WhatA2L5W2PmFd4tmqeh+c9MtfyRZ7Bk0CEOvCwCRBivlC3G9H7
         Pp2+Gn9ci9yr+k/14Jk3s7YkozBVUO0k/1ra6UH8um6AejBLkvGSOUdhX5qygA9HJ/AA
         CAvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785755984; x=1786360784;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Y6ZiLzDwyrefHpHNId0SfIDP7KVAik7WooDx4DLjY7M=;
        b=p0s34uawrylsQ+kYk0Pf6TqfTJZ3t+ydoFXVBlSxiQ/Yy1xG90drYxmxhPaSuHT4nI
         GhOcb2yLyB9hECKXnoKvbyfr03mgtlp19PJu5EtM12Nq9eNwz6jb7hGDDqUJMeQ7qWY+
         BX6YGU0/Bwjzxvxb8Tr80ckM6cEWUFBLNNtgdCVMMyvCg9qZWhGloKXScDD+O6mDfi4T
         Qeo2YRSNmevtnrcuL+8wzsZP7Bcd7ubNNLyZKXCwTZPOcDUy6J5mo7EzJuchVVeWEfi7
         Yu17JP+/51DAM4AbT42faG5HCxJuowZtq4n3dNgknBD3NgO80kvKnJ/cqaIR5dKtSrpF
         LqPg==
X-Forwarded-Encrypted: i=1; AHgh+RqoxNoetnh7LxLDeIRFPOhfTelrWfLbhOGxguLWRXmmPU4yMQzzaTe3NsBpdzfhHrPSdquEg8Bl3II=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyF5xZ9uJ2G8JZd+fyZY4mZerMY7Ia3SFdn7qgMRcniWQJAQdR
	qFp7MvN6wpB3mXQTtPDYYLCsiHOnUXm1Be4NViJS0/4XzUHpjPUjvQ44demHS+XKOoo=
X-Gm-Gg: AR+sD131fi2nSO4QYMUUHzBa3Lfz5zjaSv3w/ULyilfdVBKdoElBEfpWog8GXZHann6
	FdccfbF7k+kSZpbK3+cv57KWkQz2UEmp/UvxTHqGa5aVKV+8NT8/FZF0TbBYKXI1Xg+SEfr5ZW0
	XWHlWitY1JKEqUiw0SvtBBW2FLCcjUoHwv3Cwm3fvuamLWHrHFPPx1NgFht+Qn3t+rZ48CcEaBS
	JiJySkiB9vQ9uuokR/I3p0W5XgwM4pZjVshvWHIzTXZ0Qa4Z1auQiBSPRlzCcdUQEo8tgZD5Cg4
	GszfF+vVH/I6fQDB8zBT5HDavU8KWxA+Nfn8r1pnT7iu61RTlmHY/xYyupwW/ib9chO+1tndg1w
	CBM7JG0jjVD8i1Q4uTQRL+4Wx4lCwQZ2491eTGj2udBx6v49qic1o8Tb1ek6/LrGKBjpyJt2VpF
	sQMrSOcbhW2jqcGPorlYqL39kGLfQY9Ey85gkwsn8CEMB/rVFXzv66WUZuIRGHieGmiKC2BDZQ5
	N1OgvJ+1JIKO1pl3gWk2UGIzlP0vdBCXSncDyEmW0XwtYywMMpZsk2AIqi9qdl6HsuOrSqYdxPC
	saLDtezhLRbz09g=
X-Received: by 2002:a17:906:99c2:b0:c20:1db7:f486 with SMTP id a640c23a62f3a-c201db7f6d5mr51425966b.4.1785755984414;
        Mon, 03 Aug 2026 04:19:44 -0700 (PDT)
Message-ID: <cc3e2b95-5b3d-422b-999f-e3f798687e8a@suse.com>
Date: Mon, 3 Aug 2026 13:19:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] xen/sched: split scheduler vtable from scheduler
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com, oleksii.kurochko@gmail.com
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
 <b90e2fa6-0725-4f39-8a5f-31b02c8aef72@suse.com>
 <6a6a04dc-0d8c-4b7a-a190-09113b3b68cd@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <6a6a04dc-0d8c-4b7a-a190-09113b3b68cd@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Jb0N41yXYZfVlxU4E0wzd6Gy"
X-purgate-ID: tlsNG-ebf023/1785755985-C22D4B50-A11A547A/0/0
X-purgate-type: clean
X-purgate-size: 14780

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Jb0N41yXYZfVlxU4E0wzd6Gy
Content-Type: multipart/mixed; boundary="------------e0KE3W7ckWjUDvsdlmgZxEAX";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com, oleksii.kurochko@gmail.com
Message-ID: <cc3e2b95-5b3d-422b-999f-e3f798687e8a@suse.com>
Subject: Re: [PATCH 0/7] xen/sched: split scheduler vtable from scheduler
References: <20260803050614.5222-1-frn1furkan10@gmail.com>
 <b90e2fa6-0725-4f39-8a5f-31b02c8aef72@suse.com>
 <6a6a04dc-0d8c-4b7a-a190-09113b3b68cd@gmail.com>
In-Reply-To: <6a6a04dc-0d8c-4b7a-a190-09113b3b68cd@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------e0KE3W7ckWjUDvsdlmgZxEAX
Content-Type: multipart/mixed; boundary="------------rgestBAm8DxHNbbDoJMPTflu"

--------------rgestBAm8DxHNbbDoJMPTflu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDMuMDguMjYgMTM6MTIsIEZ1cmthbiDDh2FsxLHFn2thbiB3cm90ZToNCj4gSGkgSsO8
cmdlbiwNCj4gDQo+IE9uIDgvMy8yNiAxMzozNCwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+
IE9uIDAzLjA4LjI2IDA3OjA2LCBGdXJrYW4gQ2FsaXNrYW4gd3JvdGU6DQo+Pj4gRWFjaCBz
dHJ1Y3Qgc2NoZWR1bGVyIGN1cnJlbnRseSBkb3VibGVzIGFzIGJvdGggYSBzY2hlZHVsZXIN
Cj4+PiBiYWNrZW5kJ3Mgc3RhdGljIHZ0YWJsZSAobmFtZSwgb3B0X25hbWUsIHNjaGVkX2lk
IGFuZCBldmVyeQ0KPj4+IGZ1bmN0aW9uIHBvaW50ZXIpIGFuZCB0aGUgcGVyLWNwdXBvb2wg
cnVudGltZSBvYmplY3QgdGhhdA0KPj4+IHNjaGVkdWxlcl9hbGxvYygpIGFsbG9jYXRlcy4g
QmVjYXVzZSB0aGVzZSBhcmUgdGhlIHNhbWUgdHlwZSwNCj4+PiBzY2hlZHVsZXJfYWxsb2Mo
KSBtZW1jcHkoKXMgdGhlIGVudGlyZSB2dGFibGUgaW50byBhIGZyZXNoIGhlYXANCj4+PiBh
bGxvY2F0aW9uIGZvciBldmVyeSBjcHVwb29sIGl0IGNyZWF0ZXMuIFdpdGggTiBjcHVwb29s
cyBydW5uaW5nDQo+Pj4gdGhlIHNhbWUgc2NoZWR1bGVyLCB0aGlzIGR1cGxpY2F0ZXMgTiBj
b3BpZXMgb2YgaWRlbnRpY2FsIGZ1bmN0aW9uDQo+Pj4gcG9pbnRlcnMgYW5kIGlkZW50aWZ5
aW5nIGZpZWxkcyB0aGF0IG5ldmVyIGRpZmZlciBiZXR3ZWVuDQo+Pj4gaW5zdGFuY2VzIC0g
dGhlIG9ubHkgZmllbGRzIHRoYXQgYXJlIGdlbnVpbmVseSBwZXItY3B1cG9vbCBhcmUNCj4+
PiBzY2hlZF9kYXRhIGFuZCBjcHVwb29sLg0KPj4+DQo+Pj4gVGhpcyBzZXJpZXMgc3BsaXRz
IHRoZSB2dGFibGUgb3V0IGludG8gaXRzIG93biB0eXBlLCBzdHJ1Y3QNCj4+PiBzY2hlZF9v
cHMsIHNvIGl0IGNhbiBiZSBzaGFyZWQgYnkgZXZlcnkgY3B1cG9vbCB1c2luZyBhIGdpdmVu
DQo+Pj4gc2NoZWR1bGVyIGluc3RlYWQgb2YgY29waWVkIHBlciBjcHVwb29sLiBzdHJ1Y3Qg
c2NoZWR1bGVyIGlzIGxlZnQNCj4+PiBob2xkaW5nIG9ubHkgd2hhdCBpcyBhY3R1YWxseSBw
ZXItaW5zdGFuY2U6IGEgcG9pbnRlciB0byB0aGUNCj4+PiBzaGFyZWQgc2NoZWRfb3BzLCBw
bHVzIHNjaGVkX2RhdGEgYW5kIGNwdXBvb2wuDQo+Pj4NCj4+PiBUaGUgc2VyaWVzIGlzIHN0
cnVjdHVyZWQgYXMgaW50cm9kdWNlL21pZ3JhdGUvcmVtb3ZlLCBzbyB0aGF0DQo+Pj4gZXZl
cnkgY29tbWl0IGJ1aWxkcyBhbmQgYm9vdHMgb24gaXRzIG93bjoNCj4+Pg0KPj4+ICDCoMKg
IC0gVGhlIGZpcnN0IHBhdGNoIGFkZHMgc3RydWN0IHNjaGVkX29wcywgUkVHSVNURVJfU0NI
RURfT1BTKCksDQo+Pj4gIMKgwqDCoMKgIGFuZCBhIHNjaGVkX29wc19hcnJheVtdIGFsb25n
c2lkZSB0aGUgZXhpc3Rpbmcgc2NoZWR1bGVyc1tdLA0KPj4+ICDCoMKgwqDCoCBleHRlbmRp
bmcgZXZlcnkgbG9va3VwIHBhdGggKHNjaGVkdWxlcl9hbGxvYygpLA0KPj4+ICDCoMKgwqDC
oCBzY2hlZF9nZXRfYnlfbmFtZSgpLCBzY2hlZHVsZXJfaW5pdCgpKSB0byBzZWFyY2ggYm90
aCBhcnJheXMuDQo+Pj4gIMKgwqDCoMKgIFRoaXMgaXMgcHVyZWx5IGFkZGl0aXZlIC0gbm8g
c2NoZWR1bGVyIHVzZXMgaXQgeWV0Lg0KPj4+DQo+Pj4gIMKgwqAgLSBUaGUgbmV4dCBmaXZl
IHBhdGNoZXMgZWFjaCBtaWdyYXRlIG9uZSBzY2hlZHVsZXIgYmFja2VuZA0KPj4+ICDCoMKg
wqDCoCAoY3JlZGl0LCBjcmVkaXQyLCBydGRzLCBhcmluYzY1MywgbnVsbCkgZnJvbSBzdHJ1
Y3Qgc2NoZWR1bGVyDQo+Pj4gIMKgwqDCoMKgIHRvIHN0cnVjdCBzY2hlZF9vcHMuIEVhY2gg
aXMgc21hbGwsIG1lY2hhbmljYWwsIGFuZA0KPj4+ICDCoMKgwqDCoCBpbmRlcGVuZGVudGx5
IGJpc2VjdGFibGUsIHdpdGggbm8gYmVoYXZpb3JhbCBkaWZmZXJlbmNlLCBzaW5jZQ0KPj4+
ICDCoMKgwqDCoCBzY2hlZHVsZXJfYWxsb2MoKSBidWlsZHMgYW4gaWRlbnRpY2FsIHJ1bnRp
bWUgc3RydWN0IHNjaGVkdWxlcg0KPj4+ICDCoMKgwqDCoCByZWdhcmRsZXNzIG9mIHdoaWNo
IGFycmF5IGEgbWF0Y2ggaXMgZm91bmQgaW4uDQo+Pj4NCj4+PiAgwqDCoCAtIFRoZSBmaW5h
bCBwYXRjaCByZW1vdmVzIHRoZSBvbGQgc2NoZWR1bGVyc1tdIGFuZA0KPj4+ICDCoMKgwqDC
oCBSRUdJU1RFUl9TQ0hFRFVMRVIoKSBwYXRoIG5vdyB0aGF0IG5vdGhpbmcgdXNlcyBpdCwg
c2hyaW5rcw0KPj4+ICDCoMKgwqDCoCBzdHJ1Y3Qgc2NoZWR1bGVyIGRvd24gdG8geyBvcHMs
IHNjaGVkX2RhdGEsIGNwdXBvb2wgfSwgYW5kDQo+Pj4gIMKgwqDCoMKgIHVwZGF0ZXMgZXZl
cnkgYWNjZXNzb3IgaW4gcHJpdmF0ZS5oIGFjY29yZGluZ2x5Lg0KPj4+DQo+Pj4gRnVya2Fu
IENhbGlza2FuICg3KToNCj4+PiAgwqDCoCB4ZW4vc2NoZWQ6IGludHJvZHVjZSBzdHJ1Y3Qg
c2NoZWRfb3BzIGFzIGEgc2hhcmVkIHNjaGVkdWxlciB2dGFibGUNCj4+PiAgwqDCoCB4ZW4v
c2NoZWQ6IGNyZWRpdDogbWlncmF0ZSB0byBuZXcgc2NoZWRfb3BzDQo+Pj4gIMKgwqAgeGVu
L3NjaGVkOiBjcmVkaXQyOiBtaWdyYXRlIHRvIG5ldyBzY2hlZF9vcHMNCj4+PiAgwqDCoCB4
ZW4vc2NoZWQ6IHJ0ZHM6IG1pZ3JhdGUgdG8gbmV3IHNjaGVkX29wcw0KPj4+ICDCoMKgIHhl
bi9zY2hlZDogYXJpbmM2NTM6IG1pZ3JhdGUgdG8gbmV3IHNjaGVkX29wcw0KPj4+ICDCoMKg
IHhlbi9zY2hlZDogbnVsbDogbWlncmF0ZSB0byBuZXcgc2NoZWRfb3BzDQo+Pj4gIMKgwqAg
eGVuL3NjaGVkOiByZW1vdmUgb2xkIHNjaGVkdWxlciByZWdpc3RyYXRpb24sIHNocmluayBz
dHJ1Y3Qgc2NoZWR1bGVyDQo+Pj4NCj4+PiAgwqAgeGVuL2FyY2gvYXJtL3hlbi5sZHMuU8Kg
wqDCoMKgwqAgfMKgwqAgMiArLQ0KPj4+ICDCoCB4ZW4vYXJjaC9wcGMveGVuLmxkcy5TwqDC
oMKgwqDCoCB8wqDCoCAyICstDQo+Pj4gIMKgIHhlbi9hcmNoL3Jpc2N2L3hlbi5sZHMuU8Kg
wqDCoCB8wqDCoCAyICstDQo+Pj4gIMKgIHhlbi9hcmNoL3g4Ni94ZW4ubGRzLlPCoMKgwqDC
oMKgIHzCoMKgIDIgKy0NCj4+PiAgwqAgeGVuL2NvbW1vbi9zY2hlZC9hcmluYzY1My5jIHzC
oCAxMSArLS0tDQo+Pj4gIMKgIHhlbi9jb21tb24vc2NoZWQvY29yZS5jwqDCoMKgwqAgfMKg
IDgwICsrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tDQo+Pj4gIMKgIHhlbi9jb21tb24v
c2NoZWQvY3B1cG9vbC5jwqAgfMKgwqAgNiArLS0NCj4+PiAgwqAgeGVuL2NvbW1vbi9zY2hl
ZC9jcmVkaXQuY8KgwqAgfMKgwqAgNSArLQ0KPj4+ICDCoCB4ZW4vY29tbW9uL3NjaGVkL2Ny
ZWRpdDIuY8KgIHzCoMKgIDUgKy0NCj4+PiAgwqAgeGVuL2NvbW1vbi9zY2hlZC9udWxsLmPC
oMKgwqDCoCB8wqDCoCA1ICstDQo+Pj4gIMKgIHhlbi9jb21tb24vc2NoZWQvcHJpdmF0ZS5o
wqAgfCAxMDAgKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gIMKg
IHhlbi9jb21tb24vc2NoZWQvcnQuY8KgwqDCoMKgwqDCoCB8wqDCoCA1ICstDQo+Pj4gIMKg
IHhlbi9pbmNsdWRlL3hlbi94ZW4ubGRzLmjCoMKgIHzCoMKgIDggKy0tDQo+Pj4gIMKgIDEz
IGZpbGVzIGNoYW5nZWQsIDExNiBpbnNlcnRpb25zKCspLCAxMTcgZGVsZXRpb25zKC0pDQo+
Pj4NCj4+DQo+PiBZb3UgaGF2ZSBhIHNlcmllcyBoZXJlIHdoaWNoIGlzIGFkZGluZyAxMTYg
bGluZXMgYW5kIHJlbW92aW5nIDExNy4NCj4+DQo+PiBQYXRjaCA3IGFsb25lIGlzIHJlbW92
aW5nIDI0OCBsaW5lcyB3aGlsZSBhZGRpbmcgNjcgbGluZXMuDQo+Pg0KPj4gU28gaW4gdGhl
IGVuZCB0aGVyZSBpcyBhIHNpbmdsZSBwYXRjaCBpbiB0aGlzIHNlcmllcyB3aGljaCBoYXMg
bW9yZSBjb2RlDQo+PiBjaHVybiB0aGFuIHRoZSBjb21wbGV0ZSBzZXJpZXMgd2hlbiBhZGRl
ZCBpbiBvbmUgZ28uDQo+Pg0KPj4gSU9XOiBtYWtpbmcgdGhpcyBqdXN0IGEgc2luZ2xlIHBh
dGNoIHdvdWxkIGJlIGVhc2llciB0byByZXZpZXcgdGhhbiB0aGUNCj4+IGxhc3QgcGF0Y2gg
YWxvbmUsIGxldCBhbG9uZSBhbGwgdGhlIHRlbXBvcmFyeSBtb2RpZmljYXRpb25zIHdoaWNo
IHdvdWxkDQo+PiBiZSBnb25lIHdoZW4gbWVyZ2luZyBhbGwgcGF0Y2hlcyBpbnRvIG9uZS4g
QW5kIHdpdGggdGhhdCB5b3UgY291bGQgZXZlbg0KPj4gZHJvcCBzb21lIG9mIHRoZSByZW5h
bWluZyB5b3UgZGlkIChlLmcuIGluIHRoZSBsaW5rZXIgZmlsZSksIG1ha2luZyB0aGUNCj4+
IGRpZmYgZXZlbiBzbWFsbGVyLg0KPj4NCj4+IEkgYWdyZWUgd2l0aCB0aGUgb3ZlcmFsbCBn
b2FsLCBidXQgSSdtIHNwYXJpbmcgbXkgdGltZSBkb2luZyBhIHRob3JvdWdoDQo+PiByZXZp
ZXcgb2YgdGhlIHNlcmllcyBpbiB0aGlzIHNoYXBlLg0KPj4NCj4+DQo+PiBKdWVyZ2VuDQo+
IA0KPiBNeSBmaXJzdCBpbnN0aW5jdCB3YXMgYWN0dWFsbHkgdG8ganVzdCBzZW5kIHRoaXMg
YXMgb25lIHBhdGNoLiBJIHNwbGl0DQo+IGl0IHVwIGJlY2F1c2UgSSB3YW50ZWQgZWFjaCBz
Y2hlZHVsZXIncyBjb252ZXJzaW9uIHRvIGJlIGl0cyBvd24gc21hbGwsDQo+IGJpc2VjdGFi
bGUgY29tbWl0LCBidXQgeW91J3JlIHJpZ2h0IHRoYXQgaXQncyBub3Qgd29ydGggaXQgaGVy
ZS4NCj4gDQo+IEkgd2lsbCBzcXVhc2ggaXQgaW50byBhIHNpbmdsZSBwYXRjaCBhbmQgcmVz
ZW5kLiBCdXQgSSB3b3VsZCBzdGlsbCBsaWtlDQo+IHRvIHJlbmFtZSBTQ0hFRFVMRVJfQVJS
QVkgdG8gU0NIRURfT1BTX0FSUkFZIGluIHRoZSBwZXItYXJjaCBsaW5rZXIgZmlsZXMNCj4g
YW5kIG90aGVyIHJlbGF0ZWQgdmFyaWFibGUgbmFtZXMgaW4gb3RoZXIgZmlsZXMsIHNpbmNl
IHRoZXkgbm93IGhvbGQNCj4gc2NoZWRfb3BzIGVudHJpZXMgcmF0aGVyIHRoYW4gc3RydWN0
IHNjaGVkdWxlciBvbmVzLCBhbmQgSSB0aGluayB0aGUgbmFtZQ0KPiBzaG91bGQgcmVmbGVj
dCB0aGF0Lg0KDQpOb3cgVEhJUyBjb3VsZCBiZSBkb25lIGluIGEgc2VwYXJhdGUgcGF0Y2gu
DQoNCg0KSnVlcmdlbg0K
--------------rgestBAm8DxHNbbDoJMPTflu
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------rgestBAm8DxHNbbDoJMPTflu--

--------------e0KE3W7ckWjUDvsdlmgZxEAX--

--------------Jb0N41yXYZfVlxU4E0wzd6Gy
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpweU8FAwAAAAAACgkQsN6d1ii/Ey9v
gAf/ebSttKyOOXGrxS8t9W57Mu9fpoIa9l8Fmo6ofdzBSz/oLEvB+xg/Fp0XbM0z/JrBaugLGBHu
dvHnZktv5eUt7ERxaIf9UELJz3PhnXvbspGTZs0xOmmTLmMBWmUB5ckIliuWvNId+j4zSx/NlJHt
JHAQrreqjKm/3vnReccxQDnDz4w8b+VnE8ecOu7+tZIMNJLzFZhZ6uBWxpbEoisQ8rU/eOi9ScKx
5Tn990svnq6o5NZLzFpamQcrekfH23JYTtmm2IsmCeYnSA19jTOW8n7DP6dZH78Wri4ApGIVjRy6
qrhf39cFiZ1ijNANeK5W7VFifhev5ClbgTjlxODxwA==
=z37H
-----END PGP SIGNATURE-----

--------------Jb0N41yXYZfVlxU4E0wzd6Gy--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 12:17:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 12:17:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381420.1625000 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrc5-0007AZ-L2; Mon, 03 Aug 2026 12:17:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381420.1625000; Mon, 03 Aug 2026 12:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrc5-00079X-GY; Mon, 03 Aug 2026 12:17:49 +0000
Received: by outflank-mailman (input) for mailman id 1381420;
 Mon, 03 Aug 2026 12:17:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqrc4-00077T-4Z
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:17:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqrc3-007wIE-3l
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:17:47 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7086e5-e002-0a2a0a5209dd-0a2a45059236-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:17:47 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7086ea-4cb1-0a2a45050019-d155802ca8e8-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:17:47 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-4980fe6b3beso9420535e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:17:47 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4980878dbaesm385075295e9.12.2026.08.03.05.17.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 05:17:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785759466; x=1786364266; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=set/tVnmTwyRXbbS2/hm5WA+Lv6/Z4na9/ek1L2Zqls=;
        b=cH/Iy6UsSU6DHVKYmaFEcS/x2i5uL7oEnjKgilZ36XcHrzdGQNn6JXdrGAYSL8Zfra
         2X/xzUiwLWy3dacdLCoBfhZZuZvfgU2xz5XRaLINNqB82QkTmOw4ZDwI3AHjNwNT51ns
         +8GuAXCKwoF1EeQ2Ed3SVdz/QWrirsaY8RMTw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785759466; x=1786364266;
        h=content-transfer-encoding:content-type: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=set/tVnmTwyRXbbS2/hm5WA+Lv6/Z4na9/ek1L2Zqls=;
        b=CkIKgvgU69wmdzcqfOU0ITV//v6z4rdurkyW4+jzrFRz+2TGv3HTpeB1jsRaz32KAF
         lDthXnEL0cJ3jdc+MntOjMOp0oYVYBUGZjcU6MyZeJRlOrhmykUuI7TBe1j3/QhtepYR
         80MTZCwzhUER58cIb0LoftfZ88Vl2shkbWzJr6F471X6k7dfNqwLqKflhG87qf1bWd7w
         /ImoeVkX0jCsQH3wjZnAwpIDRyaKfYK7FrA/xKWRa/aPBX/oelDDx20+XQKM0GjuJldi
         4Y/y0CfTb5EcjMf60MYSNl2PyNOH7FNKeW5ZBWoWrVjxSJZIGvC8IC4Ys8y2jyndbTGi
         COqw==
X-Gm-Message-State: AOJu0Yyy40q3dtH51z8lOshCm+xBfLz/D2q/KRcE6+Lu8Yq8r/b1mGQT
	uiqoZNgwXgCBW8R87bcVTmRKh7C+bGQ4G/tMlsXV8mt9KqUdTh4PoQawSBgseqRUOD01cJu6Fc1
	P3VWL
X-Gm-Gg: AR+sD11Ienn+VMFqdTwDkUhqKpSgwJoZ1vMBIi7T1LRYF9GkYTPOGjd+ylsR5kEzpJz
	66s+5S2/DANnkAirjaq+/WDp8WyyMw9PmL9Wpw1PKlhBYIt7080nMm9eqHiao8vIINjsYcRtsT0
	2gALCWlw8rJVbVpkAxLFs3xeTxNpdNLvZOZKQv6rKQVuR85/EgW1LAX1Kl/h5Ko0zrghyrHRmQp
	JgsjKQsVTHyYSgGEM+4dntQ4wtUvqqLQcgPieAelEG+78p2iqe7mM225a+dpVY9uAmh6lo5EDDJ
	BOllFZ45TGChLD33UkivzMn4pgfESowxYfO/n7+E4HqdoXH0YTwWRF5rZv8cGRqY3d1fXs5xfHA
	iQuDgpebdbX3yMocFajI1zJ7iHahTFfVBkKUH4+NERMdnUziXsuTdkZSUO8l1jjVNQOiyK70hQA
	GVMaytQXxp52Z1vczQ4jYpayCG0Lh+dqkGNQ1PxbgrvAybpMrgjUBwk2jOyHiRnoZ2qvvc/tBOs
	XinsxHN6atfFho2W6DPMkZVjOZURyuVYa49pik=
X-Received: by 2002:a05:600c:5249:b0:495:3a52:71b1 with SMTP id 5b1f17b1804b1-4980eb9b2eemr144134715e9.5.1785759465972;
        Mon, 03 Aug 2026 05:17:45 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bernhard Kaindl <bernhard.kaindl@citrix.com>
Subject: [PATCH 1/2] xen/mm: Alter get_outstanding_claims() to return information by value
Date: Mon,  3 Aug 2026 13:17:38 +0100
Message-Id: <20260803121739.370951-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803121739.370951-1-andrew.cooper3@citrix.com>
References: <20260803121739.370951-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785759467-F429B2A1-838194D7/0/0
X-purgate-type: clean
X-purgate-size: 3474

A void function with two output parameters is a weird choice.  Instead, return
a two-element structure.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Bernhard Kaindl <bernhard.kaindl@citrix.com>

Slightly RFC.  claim_info_t name subject to improvement, but see next patch.

This is to help unwedge the XenServer patchqueue following commit
44adbac3c7a6 ("xen/mm: Introduce per-node free page counter").
---
 xen/common/page_alloc.c | 10 +++++++---
 xen/common/sysctl.c     |  8 ++++++--
 xen/include/xen/mm.h    |  6 +++++-
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 598222e2c2e1..900fcf5755c1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -582,12 +582,16 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages)
 }
 
 #ifdef CONFIG_SYSCTL
-void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages)
+claim_info_t get_outstanding_claims(void)
 {
+    claim_info_t info;
+
     spin_lock(&heap_lock);
-    *outstanding_pages = outstanding_claims;
-    *free_pages = avail_heap_pages(MEMZONE_XEN + 1, NR_ZONES - 1, -1);
+    info.avail   = avail_heap_pages(MEMZONE_XEN + 1, NR_ZONES - 1, -1);
+    info.claimed = outstanding_claims;
     spin_unlock(&heap_lock);
+
+    return info;
 }
 #endif /* CONFIG_SYSCTL */
 
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 8fb5ff0af317..35c132564ef1 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -248,6 +248,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
     case XEN_SYSCTL_physinfo:
     {
         struct xen_sysctl_physinfo *pi = &op->u.physinfo;
+        claim_info_t claim_info;
 
         memset(pi, 0, sizeof(*pi));
         pi->threads_per_core =
@@ -259,8 +260,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
         pi->max_node_id = MAX_NUMNODES-1;
         pi->max_cpu_id = nr_cpu_ids - 1;
         pi->total_pages = total_pages;
-        /* Protected by lock */
-        get_outstanding_claims(&pi->free_pages, &pi->outstanding_pages);
+
+        claim_info = get_outstanding_claims();
+        pi->free_pages = claim_info.avail;
+        pi->outstanding_pages = claim_info.claimed;
+
         pi->scrub_pages = 0;
         pi->cpu_khz = cpu_khz;
         pi->max_mfn = get_upper_mfn_bound();
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index b80bec00c124..74d28d2a1b7a 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -132,7 +132,11 @@ int populate_pt_range(unsigned long virt, unsigned long nr_mfns);
 unsigned long __must_check domain_adjust_tot_pages(struct domain *d,
     long pages);
 int domain_set_outstanding_pages(struct domain *d, unsigned long pages);
-void get_outstanding_claims(uint64_t *free_pages, uint64_t *outstanding_pages);
+
+typedef struct {
+    unsigned long avail, claimed;
+} claim_info_t;
+claim_info_t get_outstanding_claims(void);
 
 /* Domain suballocator. These functions are *not* interrupt-safe.*/
 void init_domheap_pages(paddr_t ps, paddr_t pe);
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 12:17:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 12:17:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381421.1625007 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrc5-0007HC-UF; Mon, 03 Aug 2026 12:17:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381421.1625007; Mon, 03 Aug 2026 12:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrc5-0007Gb-QY; Mon, 03 Aug 2026 12:17:49 +0000
Received: by outflank-mailman (input) for mailman id 1381421;
 Mon, 03 Aug 2026 12:17:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqrc4-00077Z-88
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:17:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqrc3-007wIE-KV
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:17:47 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7086e0-e002-0a2a0a5209dd-0a2a450ce7d8-8
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:17:47 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7086eb-f479-0a2a450c0019-d155802da8b9-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:17:47 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4980fe6b3beso9420635e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:17:47 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4980878dbaesm385075295e9.12.2026.08.03.05.17.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 05:17:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785759467; x=1786364267; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=6JCAOMMwTyxZkSFy3FwTezM7XZSAFX+kgUtlaig++k8=;
        b=mOkAGSdoBYNCkt5FcZovfp+J1gfWzFXJU/bFm5A3NDlOJ0Bglg0BItrHzw6M8GCBfJ
         WjW+sgALauKbsozsD1zwZXf9QY4b6EIiyXC/ONgpiduR3E+B/bk8xYfgQ0ROFX/GnfKH
         5j2O75qojRgZGKjUAv401lGyBXhyzbkEcpinw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785759467; x=1786364267;
        h=content-transfer-encoding:content-type: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=6JCAOMMwTyxZkSFy3FwTezM7XZSAFX+kgUtlaig++k8=;
        b=W2WTESaWD3x3bIU1KHb4yvjT8X7SXhEo2TNHCTt7bpXOfyo3imDiqiKUSFnQOcFTiN
         N9yq0a/Pp/F2nbIvRAXu7Z8bt0AXN3gkK5Vwg9O5McDBjR+3vSfwlWV6PnOIaC197zww
         QdOLFt7QLQC2BWPaKrfJjKDBUqQd5DaliTnkuJiwGa81VtZM29FGWlKTTw3wzS0zmkA8
         /34gb7+DpYfNTR5jQ3D4tjbN17s09N3mm8U5mgTiJHqEdEGxARDbpLxghKLW5tdD5dEj
         gWQaUvle9G7NGSniDq8nEwMDTpq+9HFzWafR72r6IJj9iSzDmBH89x9qkPG4rhc0psme
         XhDw==
X-Gm-Message-State: AOJu0YwcwqvvcIfe7Wb6DSNbvohOx8ce+zf9q87uJ74BkyNAoQv6XDtG
	weDEW5fuyMHRazZlOFkMW15mvNZy+fKnfsVAmKL7hIbYdSD36wVwhoA9vqZc21oclMxW4VCxgOA
	CvM8BJKQ=
X-Gm-Gg: AR+sD12NxoAIjhFCiIfuH7QEEjjAssJVsFK+DCiPaoXyUsjcSm7FFoFU8Y5nWwaJcUo
	1471nLt8l+TdD9Ohh70CPVYf6kngBu+oQ0kVXN5bybY5v7TwMHuAYfDHeBNIfLhibBzKT7yJguW
	TKnN/bzPrmsEf/P/2jjvyWdXOaEhosMKLPfWZwfwMdKCKgvd4+V6vxqXkM81a0o/iB4OB39PLWp
	BDC50JPvEMtFa9HQ/uI/zg6nWluOYj9gJjahq/A9lJ6S3+Pj9IzSjKVnHLZF1BoeE0rFBbvo2f/
	L82hJOjSXjoLG7uPMOeGT7U9EZvvrxTfM3660eZ/BqgfVmcRhCojejpxVhVVq6nqKbGcypQLcHl
	YD0Fqp/z8+fZPpsQepco29RZH/kHSc4r18W5XJBTUwSElp68etNHkNzKYJpvq9MANXz6OaALyrF
	B8u5y4MxFS68vymQwGos27+WJIaFCUCXZ83KFUzslE/ZHrabCQv8gBwS1KaUnzUltlIppoNRJzq
	xiz6/YWqa7vWNuQPuSIQwtHhzdfd249DIpOPxrc+ic0Yyx5cg==
X-Received: by 2002:a05:600c:3150:b0:495:3c6f:7c18 with SMTP id 5b1f17b1804b1-4980eb8c4c9mr154961375e9.3.1785759466769;
        Mon, 03 Aug 2026 05:17:46 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bernhard Kaindl <bernhard.kaindl@citrix.com>
Subject: [PATCH RFC 2/2] xen/mm: Return claim information from avail_node_heap_pages()
Date: Mon,  3 Aug 2026 13:17:39 +0100
Message-Id: <20260803121739.370951-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260803121739.370951-1-andrew.cooper3@citrix.com>
References: <20260803121739.370951-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1785759467-01AC4A5B-269A8F01/0/0
X-purgate-type: clean
X-purgate-size: 4060

Fully RFC.

With per-node claims, avail_node_heap_pages() becomes:

    claim_info_t avail_node_heap_pages(unsigned int nodeid)
    {
        claim_info_t info = {};

        if ( nodeid < MAX_NUMNODES && node_online(nodeid) )
        {
            spin_lock(&heap_lock);
            info.avail   = node_avail_pages[nodeid];
            info.claimed = node_outstanding_claims[nodeid];
            spin_unlock(&heap_lock);
        }

        return info;
    }

along with modifications to the callers.  I'm not intending to submit this
patch as-is, but it is present to help judge the naming.

Not-Really-Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Bernhard Kaindl <bernhard.kaindl@citrix.com>
---
 xen/common/numa.c       | 2 +-
 xen/common/page_alloc.c | 8 +++++---
 xen/common/sysctl.c     | 2 +-
 xen/include/xen/mm.h    | 2 +-
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/common/numa.c b/xen/common/numa.c
index 92f8f1cedce1..eef8be06944e 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -713,7 +713,7 @@ static void cf_check dump_numa(unsigned char key)
 
         printk("NODE%u start->%lu size->%lu free->%lu\n",
                i, node_start_pfn(i), node_spanned_pages(i),
-               avail_node_heap_pages(i));
+               avail_node_heap_pages(i).avail);
         /* Sanity check mfn_to_nid() */
         if ( node_spanned_pages(i) > 1 && mfn_to_nid(mfn) != i )
             printk("mfn_to_nid(%"PRI_mfn") -> %d should be %u\n",
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 900fcf5755c1..0b0f2033e738 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2852,12 +2852,14 @@ unsigned long avail_domheap_pages_region(
     return avail_heap_pages(zone_lo, zone_hi, node);
 }
 
-unsigned long avail_node_heap_pages(unsigned int nodeid)
+claim_info_t avail_node_heap_pages(unsigned int nodeid)
 {
+    claim_info_t info = {};
+
     if ( nodeid < MAX_NUMNODES && node_online(nodeid) )
-        return node_avail_pages[nodeid];
+        info.avail = node_avail_pages[nodeid];
 
-    return 0;
+    return info;
 }
 
 
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 35c132564ef1..4d8dba51eb63 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -315,7 +315,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
                     if ( node_online(i) )
                     {
                         meminfo.memsize = node_spanned_pages(i) << PAGE_SHIFT;
-                        meminfo.memfree = avail_node_heap_pages(i) << PAGE_SHIFT;
+                        meminfo.memfree = avail_node_heap_pages(i).avail << PAGE_SHIFT;
                     }
                     else
                         meminfo.memsize = meminfo.memfree = XEN_INVALID_MEM_SZ;
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 74d28d2a1b7a..e8b81c0f1fc6 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -137,6 +137,7 @@ typedef struct {
     unsigned long avail, claimed;
 } claim_info_t;
 claim_info_t get_outstanding_claims(void);
+claim_info_t avail_node_heap_pages(unsigned int nodeid);
 
 /* Domain suballocator. These functions are *not* interrupt-safe.*/
 void init_domheap_pages(paddr_t ps, paddr_t pe);
@@ -145,7 +146,6 @@ struct page_info *alloc_domheap_pages(
 void free_domheap_pages(struct page_info *pg, unsigned int order);
 unsigned long avail_domheap_pages_region(
     unsigned int node, unsigned int min_width, unsigned int max_width);
-unsigned long avail_node_heap_pages(unsigned int nodeid);
 #define alloc_domheap_page(d,f) (alloc_domheap_pages(d,0,f))
 #define free_domheap_page(p)  (free_domheap_pages(p,0))
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 12:17:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 12:17:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381419.1624996 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrc5-00078D-CY; Mon, 03 Aug 2026 12:17:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381419.1624996; Mon, 03 Aug 2026 12:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrc5-000786-9j; Mon, 03 Aug 2026 12:17:49 +0000
Received: by outflank-mailman (input) for mailman id 1381419;
 Mon, 03 Aug 2026 12:17:47 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wqrc3-00077S-IK
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:17:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqrc2-00EkFX-6l
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:17:46 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7086e5-5cb7-0a2a0a5109dd-0a2a4504b816-24
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:17:46 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7086e9-b57f-0a2a45040019-d1558035bc43-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:17:45 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so10913155e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:17:45 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4980878dbaesm385075295e9.12.2026.08.03.05.17.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 05:17:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785759465; x=1786364265; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=gkyO29GJSH16hZeyxTwBRFcZE8QggRPa17kg4rPW+xA=;
        b=VnRBB3Aw1q5+bxfBTzXuCAS3UuYSMOALweyDCRorryARCf5PFFwMNgJ8STKlhlDFBw
         ys4D2hQkRh+ilxRhZTbog021Ngx7t14B/qFOa9QohCmmMRBMNhSmhRFp0I1srIwL22kw
         C6ijzoeGRjvRip1I4yGFm6JvgDaDugWkXx7Gc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785759465; x=1786364265;
        h=content-transfer-encoding:content-type:mime-version: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=gkyO29GJSH16hZeyxTwBRFcZE8QggRPa17kg4rPW+xA=;
        b=UD76hbY5kQ6D3H59pO5+RcBFzsUUPpyy5JsCWdkB2HPcGizBfhiYLGmMiMZzGyOse2
         oqNTOCUOuXpKH4rdGcwhg17D4W2Wc75/4AuFJb4oDiWFzFeFRGgAsPnxWk1NQmtpCzSa
         axuBMyY2HnQ2rP0K3+NUKHTqheLjrLZiBgrUJUWlVSbdcTwKTATKumD/tX1QzNIMIJfi
         ne3CddUK51FwAfPXrJkQanZ6gzfmq09dDA8XgbEZxRMzaIH8S01kLcJoeGxT343m4TD2
         KUm7g+shc+ALINi7jpEnLm0GIiwbtiH1GCsB/wSFl51XaasU7maAc4RqUmIctdFZF+kv
         7NDQ==
X-Gm-Message-State: AOJu0Yy0XgPAF0j0w73OwHdJGi/YRAF6IbzDtc5ocsDPHLmQjn26AgYY
	7xbrvGqANCppfXn342NFwEH2fVe2pAn2poox7eMrzMBuT+J6W8evMzubA8uhCEna1FZh56st7pg
	BD8OlTFQ=
X-Gm-Gg: AR+sD134GkHR6FYjeFExSMcoMc7+8BrE/6CI9FCLLTlkanJpS8Lg32aBjGQre+6WNBs
	zw+8cMUcDVxy7P3NBcRb/fUEDLlBFGavb9zpGWqIIYHZ/VWOKGgR6wQk8vbHAZOupVtbhKZ3mzB
	aH5AlcQnSK/GT/UQugRuxGA6El45h7s6BIuYQEsz7BxIQAcJdw2rMEDtE+5YYTM7TE+9vhC8wp+
	sczBbYaKe7qCQvSIgRzIgLub+CGGxOJSXRws/qAzfDJDzjzsDZ8ha4ylV3tmhvddNqaeeSFKkHg
	mrnYp+fMwOvagQs7GMB8pXBQsCFEnG+h7FaSGii6GHPMsYgRXpWSo2hRmlOEFn8WUTiJYkWqnv9
	9abaKGFikzbfS5bugOvb6Wzu7sA1LqnhynOVSqW/o6Eo9CJtynnHD/lKwkCqJRA66+/HjINg5vY
	jpknSjQOA4aK9SCNZe9klYGw1jP2Sp5iKvCTcrb4Gx7SIlzp3jmm1/9lIEzXaU0GhVmBzMEZTuK
	Wce8r+t7eRqbi4qMVUCfi02yNXKxb4Jh67tumc=
X-Received: by 2002:a05:600c:4e94:b0:493:e365:ace9 with SMTP id 5b1f17b1804b1-4980ee9ce83mr174598615e9.11.1785759465068;
        Mon, 03 Aug 2026 05:17:45 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Bernhard Kaindl <bernhard.kaindl@citrix.com>
Subject: [PATCH 0/2] xen/mm: Alter get_outstanding_claims() to return information by value
Date: Mon,  3 Aug 2026 13:17:37 +0100
Message-Id: <20260803121739.370951-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1785759465-50AD8B50-06B1DC1C/0/0
X-purgate-type: clean
X-purgate-size: 529

Changes to help unwedge the XenServer patchqueue following commit 44adbac3c7a6
("xen/mm: Introduce per-node free page counter").

Andrew Cooper (2):
  xen/mm: Alter get_outstanding_claims() to return information by value
  xen/mm: Return claim information from avail_node_heap_pages()

 xen/common/numa.c       |  2 +-
 xen/common/page_alloc.c | 18 ++++++++++++------
 xen/common/sysctl.c     | 10 +++++++---
 xen/include/xen/mm.h    |  8 ++++++--
 4 files changed, 26 insertions(+), 12 deletions(-)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 12:35:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 12:35:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381444.1625022 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrsi-0003Oj-AD; Mon, 03 Aug 2026 12:35:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381444.1625022; Mon, 03 Aug 2026 12:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrsi-0003Oc-7B; Mon, 03 Aug 2026 12:35:00 +0000
Received: by outflank-mailman (input) for mailman id 1381444;
 Mon, 03 Aug 2026 12:34:59 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqrsh-0003NR-9R
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:34:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqrsg-005IeJ-M2
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:34:58 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a708aef-2eae-0a2a0a5409dd-0a2a450cc58e-22
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:34:58 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a708af2-f479-0a2a450c0019-d155802fe025-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:34:58 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4956242332dso18003175e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:34:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49808690ffbsm256801355e9.10.2026.08.03.05.34.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 05:34:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785760498; x=1786365298; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=69n3Og5xkKdvFQyeK95WwlJPqVsgYp8WOb8rfW4Bplc=;
        b=HP9ThGxsiSh1MYpFH8qbApBaNOIDJhCPrw+KQn5N2x6QWQZF4EmzDdt7CftEohtDF5
         VRPbOJfgPjGR7oNe3TgIqqPYXoiDPdO9JSXBrqHxVSbkQBHdZL27jTU2tg5IA+KSqSZb
         FGbz2TGtQ3+6tAQ+yN9L8awbGYUznmtgyLSlmFvJE2+ERfpGdugS7K5/S1qPdF3v8B91
         KsynlmmVtgVW6HcaYGjuLv1djOOWiHHoeqqzePEF5DeMNWLdkGR50ADWY28DveAVOyEU
         oniI173F+Oj2pErDJRyu3vO0MYRoPkVntEJi+r5bGElKJJIWkVQFoQld/+Diy9kI4hj8
         tQEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785760498; x=1786365298;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=69n3Og5xkKdvFQyeK95WwlJPqVsgYp8WOb8rfW4Bplc=;
        b=oTVzMY4k7ck0FiNo57VHVAF5GQnnBkj+L1pBtUaJUJWNynsUc17gATXw0NkNrChLl5
         ukPn/Y5a7YJvX/FFdzFy2T9OnXDMx2cqHGb2v3QLNX25dmNqCv993j3atO6PKD33yZvW
         eyyT/nlWMtjR8pgi9W6f4tylgQhtLjgjMEIXsEA4m0lvkaFoAFR/oVlNzkD5BKjUoZQW
         DcIkZad9dSQOhKKDbKVCAf5cRRzxh+nvcIEhKIJuHf9x4z9uUUkjvvnVx0PupUXnqzJw
         zqP6d3rHOeENx4H2hjHyvZ+qWyLRtM3u4K0Y9k0l9wXWMs3JcDfC4tJf2QFKBKHx+YhZ
         G2Sw==
X-Forwarded-Encrypted: i=1; AHgh+Rr3SaOuIywit3c2maQE/rlUEwIcbgGUx7mP0TJaojdx3IEfp02TnR/biJmzBMYJWYEMc8xDZuK09p8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw11lWxIroyrVad8wqTAcEZmq1PRyo5ZJrvWh9jV8sw9gxG/R/8
	LTfgiS44X6qxNboSemBbVKZr+xI1kKhvBhso1NK/p4qPbkpllHfQURvOW94oQYKvo0IOL9+buhF
	PWG/AvA==
X-Gm-Gg: AR+sD11OmaNxhZQ65FY6V34LBNj21A99Jdk+kIMiiSMZNZXJegNq/djxOAVLcC408pz
	XSOXoEc4175Pj3aiLF891qZu/BO2O2yFwRWW/BPh+SkBqZPVK9HIiFt2g+9ho3Axsa+WB5AAcyS
	/HwMiHGYFdFzb4DJM1XfEi+l0Aaiav3fWn4sWm92ddLo/SDVjTHGJAL1pBhPDqZMtglIrPxP3Pq
	ETzxKq43EnSQao4AT4S548RBv37dJBW3tCxbAcTm50g8fxZU9SQiCNkBjyg6PV0dmLwxAet2LaJ
	aZiPGico3stNhH5OAHfXfOM1S286eJJgqqCLcMojWciz196btEXRJA1oKPZGIMOOyqH275BBpfW
	H6zbgd9kO/W7akIQAI7v1t7ED5GP4Nf/xu5qRYfLxX7ZI/NNEp0O7E/g7vxp36GS7GgTaCMNot3
	3hZ61Iq78wprAMV37iCQeY0P9/KgaB3ezzIqCKySGy25D2BiNcx61F2t5inBDyxQ6aULfulmsGD
	mVtdyXtCCwu8/nq9cihWVMx9Mp+F6jJfqjswkC5sJfHuLhdRX9p
X-Received: by 2002:a05:600c:840f:b0:493:c42e:5be0 with SMTP id 5b1f17b1804b1-4980c60705amr202123705e9.0.1785760497947;
        Mon, 03 Aug 2026 05:34:57 -0700 (PDT)
Message-ID: <9ad2867a-3d01-4ff3-bb9f-d89cf9d4e96c@suse.com>
Date: Mon, 3 Aug 2026 14:34:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/mm: Alter get_outstanding_claims() to return
 information by value
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bernhard Kaindl <bernhard.kaindl@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803121739.370951-1-andrew.cooper3@citrix.com>
 <20260803121739.370951-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260803121739.370951-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1785760498-004CFA5B-D56C6D9E/0/0
X-purgate-type: clean
X-purgate-size: 1281

On 03.08.2026 14:17, Andrew Cooper wrote:
> A void function with two output parameters is a weird choice.  Instead, return
> a two-element structure.

Hmm. Generally in reviews I'm trying to recommend against returning of structures
by value. I don't like this very much here either, and it is (slightly) harder to
use ...

> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -248,6 +248,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>      case XEN_SYSCTL_physinfo:
>      {
>          struct xen_sysctl_physinfo *pi = &op->u.physinfo;
> +        claim_info_t claim_info;
>  
>          memset(pi, 0, sizeof(*pi));
>          pi->threads_per_core =
> @@ -259,8 +260,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>          pi->max_node_id = MAX_NUMNODES-1;
>          pi->max_cpu_id = nr_cpu_ids - 1;
>          pi->total_pages = total_pages;
> -        /* Protected by lock */
> -        get_outstanding_claims(&pi->free_pages, &pi->outstanding_pages);
> +
> +        claim_info = get_outstanding_claims();
> +        pi->free_pages = claim_info.avail;
> +        pi->outstanding_pages = claim_info.claimed;

... here. If others think this is the way to go, so be it. But I'm not in favor.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 12:40:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 12:40:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381453.1625032 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrxd-0005Wo-0D; Mon, 03 Aug 2026 12:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381453.1625032; Mon, 03 Aug 2026 12:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqrxc-0005Vy-S5; Mon, 03 Aug 2026 12:40:04 +0000
Received: by outflank-mailman (input) for mailman id 1381453;
 Mon, 03 Aug 2026 12:40:03 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqrxb-00056b-B4
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 12:40:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqrxa-005Jvb-Fl
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:40:02 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a708c1d-bab6-0a2a0a5309dd-0a2a4506e340-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:40:02 +0200
Received: from [209.85.218.50] (helo=mail-ej1-f50.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a708c22-195a-0a2a45060019-d155da32a49f-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 14:40:02 +0200
Received: by mail-ej1-f50.google.com with SMTP id
 a640c23a62f3a-c15e03c2763so621708866b.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 05:40:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd4662727sm496448466b.59.2026.08.03.05.40.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 05:40:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785760802; x=1786365602; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1Rv9ekgCqFE0xkNpyFLzSLNtbTIiyypWYXYLZoy/njo=;
        b=HgLZAaryCEs0vSZSyglCCysp5cBn168Ke+IThMbuhFHaqCwCgn4BPGsGjsukMRq8Cm
         T0HD1a6TZJexssHtahpC/MyFShAJD9OJJWE58vW3QgPJ/uXTtVzsYLfe1v1bvz+Y62yQ
         guUEG10MYkCi3Zp3uGIRZAT1ik+WgyRJg7Pg/y0k/Xbv6oWZjIktOW/paAEKT0PXs1Op
         CI17u0CAVye8rf4MywTfsTRJ4AqWrZd82BBT7/JUxhYTPuLBG9S8h55hoedyw7BUDrRR
         +kmVKS7agMmopXuDg7KOCt9mzKBZr3UoRVR/Y9EtItPWSBTxjLnWO1dOZfcBs2T0PXYk
         akrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785760802; x=1786365602;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=1Rv9ekgCqFE0xkNpyFLzSLNtbTIiyypWYXYLZoy/njo=;
        b=dK/BK3m+JZrtOhS1IAElgT7JsaTiIuYJFzuwBoWgJyn6Y+jE8sF130LxWGsN+GKKke
         ce1wrZGbg5HfsbS08YS+UflW/HWNy7SfZD6QasL97n7egz4a+GDFrHq8lfWYsRntyt35
         N9NwsFaYAvu5Y4akPswGw5/YoFWvzAcScoGtTy39Wx5VnCrrdlGfPzTs771StAmr6mWV
         zOb37H34AvLccym5jdLMWCi9PYeaSc9fIR2z4/4+q46bgHBUnry3bDWv/bRwHsHL5/o2
         u01+y16hLHh9kvJ51UC1R/5HjS/lD41APe2i+WcB9Jen80vpiF/jXEUijXlao4Hb7ulN
         sCmg==
X-Forwarded-Encrypted: i=1; AHgh+RpiUqqHy7pXL6MEq4XVp+qgzjShbbU3tmCpmFqjopk+SPOMIMs/862HjZJ+WFtlx/t3DeyvE6u3gvM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvGQA+egGcyiyg7bjYVOsj+XqtYHjCNzPWFGzuVQWwonoP0OB7
	m3fUWYGK0ChNSU+PcvD5cGDjfpmmVilDebZ7lWXHIJDkrqKUMC+DZ0X08p6WtSo4YQ==
X-Gm-Gg: AR+sD13grdeFxoSsMN765r7+DQtGx3RiROd+afMgpUe6lBtBxn4XZupF43BJeYW2U+F
	ztjEOiMZtzUhE4wda5TvpPEsAVYk/GMkhxzwMm9nA25yK/eXsmeteYlY8k6A/a12TwUVTjIXdBy
	TOOgOSLP0I3xnPyElNYlvXs9dSeS23ePO7xMxZMkR1ttDxib7VF5BC0DUPXuuSGcTUPXAYRO5bZ
	pmC+XWi2lr3bv/WdKFrWy18UKe2pqySFA2tYAc9mTk2niO6KFfJSONmTWuP3VxtiFjBFrXJ+b+0
	bOb0R8WGxGedhWtJ7vS1TRv9rzpOkoCtfdQejY2KTU+EoKJ5AS5M+BDrPjFd9GT8MVi0xthZUz6
	gDbcM/orftdTSlPRMoBu6IpL4/a0kaDwWy52DwyJq1JLFayfz64cONWIfdSJk1aQ3SS2MMj2Nyx
	beHmDTcYNHSzdxoB7N6IsKCBELpRIKQ4JGL43nutWDtu108dKdluLGw/Gv0ZiJ9WHwofBTvK4OS
	OS8RtIan9vLGSG8Np0oVs2I1I4OnOqr0Fy2pJBiIDXNMgk5PBvianUeEeHyeP6N
X-Received: by 2002:a17:906:9c96:b0:c19:7908:c67e with SMTP id a640c23a62f3a-c1fd316d26bmr966117266b.4.1785760801966;
        Mon, 03 Aug 2026 05:40:01 -0700 (PDT)
Message-ID: <166491d8-70f2-4250-9212-e86b002d877a@suse.com>
Date: Mon, 3 Aug 2026 14:40:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH RFC 2/2] xen/mm: Return claim information from
 avail_node_heap_pages()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bernhard Kaindl <bernhard.kaindl@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803121739.370951-1-andrew.cooper3@citrix.com>
 <20260803121739.370951-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260803121739.370951-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1785760802-F5C0F77B-AA87A6BB/0/0
X-purgate-type: clean
X-purgate-size: 1024

On 03.08.2026 14:17, Andrew Cooper wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2852,12 +2852,14 @@ unsigned long avail_domheap_pages_region(
>      return avail_heap_pages(zone_lo, zone_hi, node);
>  }
>  
> -unsigned long avail_node_heap_pages(unsigned int nodeid)
> +claim_info_t avail_node_heap_pages(unsigned int nodeid)
>  {
> +    claim_info_t info = {};
> +
>      if ( nodeid < MAX_NUMNODES && node_online(nodeid) )
> -        return node_avail_pages[nodeid];
> +        info.avail = node_avail_pages[nodeid];
>  
> -    return 0;
> +    return info;
>  }

Why would this be? What use is a compound return value consisting of two
pieces, only one of which is ever going to be non-zero? In the form
shown for per-node claims that effect goes away, yet at that point the
function name doesn't really reflect its purpose anymore.

As to the naming of claim_info_t - that's perhaps good enough if really
we want to go with the return-by-value approach.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:06:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:06:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381489.1625042 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtIc-00053R-T6; Mon, 03 Aug 2026 14:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381489.1625042; Mon, 03 Aug 2026 14:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtIc-00053K-On; Mon, 03 Aug 2026 14:05:50 +0000
Received: by outflank-mailman (input) for mailman id 1381489;
 Mon, 03 Aug 2026 14:05:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqtIb-00052v-Nw
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:05:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqtIa-000TjP-Pi
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:05:48 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a036-e002-0a2a0a5209dd-0a2a4503cfa0-32
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:05:48 +0200
Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a03c-fae8-0a2a45030019-d155da2be131-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:05:48 +0200
Received: by mail-ej1-f43.google.com with SMTP id
 a640c23a62f3a-c1c50c1e29bso484054066b.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:05:48 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd44541fbsm550119266b.39.2026.08.03.07.05.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 07:05:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785765948; x=1786370748; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=6cbka/s3gspot+G9lavFH5bjpkJkKfJrehNnhrK+WT8=;
        b=HvMNk+ofziRczVbAvUa066mltEf+V7dIhZWe2mQXh3Y8JX95S1uQdi6Xdr13f6DKmQ
         v2rp6Wee91Q8m4QhcO8tOfgYPCthIx5Yi+jIGNQZPOsP2C00NTt4zmj1ByfmhoYtyb5g
         +N/0CGx+TimO3g28RA9Z2U167mE200VCL5/xCQf1X3y8fgGrv52P4z3GJq+7LEqFTthE
         xCEqsBs1KzIdIcIrcdbBJdjBcZDnzXXqWPmfTjrvq7ID+ak3Zn6bUwYX01fWX44dJxlY
         qE1JMfDLc+K4/RtwuqFDBWCGD300vW8NnIxAGuxWmb9ig4BbRbuKyc0vDAw49SliWtGO
         nTPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785765948; x=1786370748;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=6cbka/s3gspot+G9lavFH5bjpkJkKfJrehNnhrK+WT8=;
        b=IqxDXYRxds6v5I1+ShYjgKCibH6W74iX+4RaH+WTz4rojBPRiTl6maS4ilnjRgjF6G
         As6E73w1dg3xoFyGKj4WcKwoVMn5oW6Ozf0IH6oaRoz6TOk3YA94A9qcN5Qd5JHz5mWY
         aQQ5atyoRNC37LE0xLtDhF5X+KMTrlqtzyF+EZhp6Ob9CnvN4oh+EtEIB2zdW9jRyHIY
         WNwMijb3P2rSKYKgmF6SOaBq1sWrAYhf4DlxR1mJ/wspHyw3l7zT7lW6SmxTSh5Z0d9o
         ljfdTHCNnQTM++G04KP8u9vlNljQw0empVLgBOAr3h7vPXlp9iTR+rGLW1WwOP9V/xrj
         fkWQ==
X-Forwarded-Encrypted: i=1; AHgh+Ron92sfcg9x+xvpLMTbVeXvsWfvy3e5nxWVUoSii4h0TVoilLt+sHzPQFA0pUZ8BLXxn5VMfmHXLQ4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwOGRx6MAJgL1lVH1MekBKqxzYHqqej5CQDwrQ1GFpSGOgbIDI1
	Rm4s53ndAuT1wQiLnS1Ilwz24stRSLsCMf4niFQxZt6THWGJdC4XBxiQ6c6pm91USt0=
X-Gm-Gg: AR+sD1370hpOr6IwOH7iS+zd59G0jsk9WA32nDFLTmP8vV0hYq2CDIGQTwZ73oFaHjv
	ajn2AENbVKu2AsoJqkisPjD1wM+/UhACRnqFECu9lZl5WFlCoNYGqfDeMrYYQvHT1+w2jmEoNzr
	67RZEBeqssFiGmhCfvzylJrZ8/OEDgsZZyZP9CQGNrdrdIHDpVpQgmCrmuhYpDLQnhUsqm4mjwI
	sVTrNnI+vVNmBm2p/DDpN5h7CD5f4Nx05hK7JLYDtLQr1/CDhZ3ltnsmOYMH14GgFoeq6MpvmTt
	8n2Ivam5pVmP4uVN9REOtvPvvXZVwE2Z3li0iByDXvFUhulFPqLD8qLthimP52+PGTW70sDCUYg
	dskr8sk/+Pni/dtPC9yIF0StfoqLhjcuu1AU5cBnxTxLWfUo8JSmHjgFLovnCrsK5Hm4N+0iQw5
	V4/3phSjlrCLeaff7CoLR31npuXNvgIvxB13Rq1fT054Am8Y8Jdg6EdoXC0cNXEngJEgWbiIsJh
	rUGsdWn/LFKsn5klPUnNjmj+lacU8eMtmKzWTZd3ElntPVUAQz1wGp0cl+xwKnA0R7wrjgd0guS
	pr4SFkKrKXNocpo=
X-Received: by 2002:a17:907:c28:b0:c1c:3b06:ed19 with SMTP id a640c23a62f3a-c1fe82058dbmr830741166b.31.1785765947878;
        Mon, 03 Aug 2026 07:05:47 -0700 (PDT)
Message-ID: <439c2740-fb84-42cb-b001-cb290684a583@suse.com>
Date: Mon, 3 Aug 2026 16:05:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH Linux v6 16/16] xen/privcmd: Add new ABI to allow copying
 foreign memory
To: Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <20260619130501.272832-1-frediano.ziglio@citrix.com>
 <20260619130501.272832-17-frediano.ziglio@citrix.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260619130501.272832-17-frediano.ziglio@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------eViDH0Q70fvb6ZFclS200RM0"
X-purgate-ID: tlsNG-33051d/1785765948-752854E9-EB66C591/0/0
X-purgate-type: clean
X-purgate-size: 9769

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------eViDH0Q70fvb6ZFclS200RM0
Content-Type: multipart/mixed; boundary="------------jJl2wII0I5iZYAc7xTzCv0ty";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>
Message-ID: <439c2740-fb84-42cb-b001-cb290684a583@suse.com>
Subject: Re: [PATCH Linux v6 16/16] xen/privcmd: Add new ABI to allow copying
 foreign memory
References: <20260619130501.272832-1-frediano.ziglio@citrix.com>
 <20260619130501.272832-17-frediano.ziglio@citrix.com>
In-Reply-To: <20260619130501.272832-17-frediano.ziglio@citrix.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------jJl2wII0I5iZYAc7xTzCv0ty
Content-Type: multipart/mixed; boundary="------------mDmQSlGNimUUgFFkZKGULTvo"

--------------mDmQSlGNimUUgFFkZKGULTvo
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTkuMDYuMjYgMTU6MDUsIEZyZWRpYW5vIFppZ2xpbyB3cm90ZToNCj4gVGhpcyBuZXcg
QUJJIGFsbG93cyB0byBjb3B5IGZvcmVpZ24gZG9tYWluIG1lbW9yeSB0by9mcm9tIGEgYnVm
ZmVyLg0KPiBUaGlzIGF2b2lkcyBoYXZpbmcgdG8gbWFwL2NvcHkvdW5tYXAgZm9yZWlnbiBt
ZW1vcnkgd2hpY2ggaXMNCj4gZXhwZW5zaXZlLg0KPiBUaGlzIG9wZXJhdGlvbiBpcyBkb25l
IHBhcnRpY3VsYXJseSB3aGVuIG1pZ3JhdGluZyBWTXMuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5
OiBGcmVkaWFubyBaaWdsaW8gPGZyZWRpYW5vLnppZ2xpb0BjaXRyaXguY29tPg0KDQpXaGls
ZSBkb2luZyBhIHRlc3QgYnVpbGQgSSBnb3QgdGhlIGZvbGxvd2luZyBidWlsZCBmYWlsdXJl
cyBmb3IgMzItYml0IGFybToNCg0KICAgQ0MgICAgICBhcmNoL2FybS94ZW4vZW5saWdodGVu
Lm8NCkluIGZpbGUgaW5jbHVkZWQgZnJvbSAvaG9tZS9ncm9zcy9rb3JnL3NyYy9hcmNoL2Fy
bS9pbmNsdWRlL2FzbS94ZW4vaW50ZXJmYWNlLmg6MSwNCiAgICAgICAgICAgICAgICAgIGZy
b20gL2hvbWUvZ3Jvc3Mva29yZy9zcmMvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oOjEz
LA0KICAgICAgICAgICAgICAgICAgZnJvbSAvaG9tZS9ncm9zcy9rb3JnL3NyYy9pbmNsdWRl
L3hlbi94ZW4uaDo1MiwNCiAgICAgICAgICAgICAgICAgIGZyb20gL2hvbWUvZ3Jvc3Mva29y
Zy9zcmMvYXJjaC9hcm0veGVuL2VubGlnaHRlbi5jOjI6DQovaG9tZS9ncm9zcy9rb3JnL3Ny
Yy9pbmNsdWRlL3hlbi9hcm0vaW50ZXJmYWNlLmg6MjI6MzU6IGVycm9yOiB1bmtub3duIHR5
cGUgbmFtZSANCidfX2d1ZXN0X2hhbmRsZV91aW50OF90Jw0KICAgIDIyIHwgI2RlZmluZSBH
VUVTVF9IQU5ETEUobmFtZSkgICAgICAgIF9fZ3Vlc3RfaGFuZGxlXyAjIyBuYW1lDQogICAg
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXn5+fn5+fn5+fn5+fn5+
DQovaG9tZS9ncm9zcy9rb3JnL3NyYy9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5Lmg6
MzYxOjU6IG5vdGU6IGluIGV4cGFuc2lvbiBvZiANCm1hY3JvICdHVUVTVF9IQU5ETEUnDQog
ICAzNjEgfCAgICAgR1VFU1RfSEFORExFKHVpbnQ4X3QpIGJ1ZmZlcjsNCiAgICAgICB8ICAg
ICBefn5+fn5+fn5+fn4NCm1ha2VbNV06ICoqKiBbL2hvbWUvZ3Jvc3Mva29yZy9zcmMvc2Ny
aXB0cy9NYWtlZmlsZS5idWlsZDoyODk6IA0KYXJjaC9hcm0veGVuL2VubGlnaHRlbi5vXSBF
cnJvciAxDQptYWtlWzRdOiAqKiogWy9ob21lL2dyb3NzL2tvcmcvc3JjL3NjcmlwdHMvTWFr
ZWZpbGUuYnVpbGQ6NTQ5OiBhcmNoL2FybS94ZW5dIEVycm9yIDINCm1ha2VbM106ICoqKiBb
L2hvbWUvZ3Jvc3Mva29yZy9zcmMvc2NyaXB0cy9NYWtlZmlsZS5idWlsZDo1NDk6IGFyY2gv
YXJtXSBFcnJvciAyDQoNCg0KUGxlYXNlIGZpeCB0aG9zZS4NCg0KDQpKdWVyZ2VuDQo=
--------------mDmQSlGNimUUgFFkZKGULTvo
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------mDmQSlGNimUUgFFkZKGULTvo--

--------------jJl2wII0I5iZYAc7xTzCv0ty--

--------------eViDH0Q70fvb6ZFclS200RM0
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB4BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwoDoFAwAAAAAACgkQsN6d1ii/Ey/M
Tgf2LlOj7QPEdjOxIk0ADPK+S55E6zaoy/XQvnR76J84IZnusmHhUR+Z28kG9H3O90OuKl2AFbE+
Xjr0gJjZwWqoDgrc8RR42AXoH0JjCy6EkiE0s5yZ7NRtXhwW1DFZb956Ptn96laOeRj99x3+eUJR
9DuUXt1wCVuvBp/xeXqLDIlHbi0CTxW6bKi+HE/MJzgYfnFKRuSwf1opduOXS8ilVyc9Y4y+b4SY
r7DiplwBdueMiSqsb9ZQqneT64l62dzMlWAwIwlFT7yg6eLH6k11TG2Kr/pbYDYU2lHDMJq/tKYu
i8iDNfNEZHqo8yal1x6QedRjpNp8G8NpKUEFybYd
=wTnP
-----END PGP SIGNATURE-----

--------------eViDH0Q70fvb6ZFclS200RM0--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:11:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:11:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381498.1625049 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtNn-0007Mf-Dy; Mon, 03 Aug 2026 14:11:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381498.1625049; Mon, 03 Aug 2026 14:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtNn-0007MY-BL; Mon, 03 Aug 2026 14:11:11 +0000
Received: by outflank-mailman (input) for mailman id 1381498;
 Mon, 03 Aug 2026 14:11:09 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqtNl-0007MS-Qq
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:11:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqtNl-00F6Hu-7R
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:11:09 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a170-e002-0a2a0a5209dd-0a2a4501c246-30
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:11:09 +0200
Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a17d-5984-0a2a45010019-d155da29d80f-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:11:09 +0200
Received: by mail-ej1-f41.google.com with SMTP id
 a640c23a62f3a-c197e7e4e94so600011466b.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:11:09 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd466271csm586500966b.60.2026.08.03.07.11.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 07:11:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785766268; x=1786371068; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=uuFRCL7uyGFk+NUBtcHerZxA349KsV1wcoysKkIK15g=;
        b=NCWJEphprSXKrxPagfR0bqFkw0oH4KIU1/aDqptyB+Wzyh9Q+Bp2p6ilBwNix/N6QG
         ukouWCirGkSDueieU9Bp56N/45xyrG5N36IpwAt9IRsYGLk8Ib/7TX5vUqHlPOGIbPp9
         a3rrUHU3uZ2iGBGG/KZSTTrGmOeL7rVqEITCS+RW8o696PpLeYS7MZFm9waVBqbWN/W/
         dnvdlBO3U4Hr3sy2pSxZwL0Lfu2dWFmweHZd4iPaChHJFTTOPA+bdgNFQlJ4L1tdaTMr
         ANJJw/Ewk1cx9melKvSaEHa0jWjxfK9ThRDNWI3+wWqRNEqntKESSD5BD0OfJ+0PI5O+
         9wHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785766268; x=1786371068;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=uuFRCL7uyGFk+NUBtcHerZxA349KsV1wcoysKkIK15g=;
        b=fgc18GCG1UyQxAu/wQHTe7SOwC+X5vQuHf19+OWjcpHmcvCox/766LrzxdwWvMnTRK
         Ks0ONiqZZPrxvZYvsMcO+z0iOpiGR5xBuIES0bm0hMM1ejaiijEXOiJf5eTbYG8pK4Sf
         HL67hgNhhqsDYUr7xrJA/JjUQp1rU7Korb8p7htAUevxHfZKQA3n0ZT+0CQm/NkRVfEz
         H3HFAIBoUchhztESkHQi3VeCqvDBQ4f4TwY4eLn+AVc+p0XeKTR1h6G6VSW2rCA5Z5VU
         kNRAdH/bmpNnIV90YYhE9K9AVO7E9bL+Khme8GzZcdVCkG1ctcrxuI9+7x3MIPvmAZ4E
         ZOiA==
X-Forwarded-Encrypted: i=1; AHgh+Ro+9LViEgAyWRI4CeZemqBetx8AYGhN7I55H18VhhXqu5FEpS5r9miBFIcYQ0BvBl/aGtOzt8MhaHg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzakfviNKMvYJ9yFG/jIp82Po3SmMhh94Xxth/sOvitq+0NsbIN
	0QLaLXW199tXbuyk9oKj3QNR0iHm8ZuqGe2mSPcwOQI85rybgqL5Ak3cXIPoJP2CEr4=
X-Gm-Gg: AR+sD1114PC0Jw+VRaRMKvC081/PU555AKEWInJeQkQB+lS+LUIg7dUDftrY6vuPmFa
	IYg4wFH8CDFR7+pHsik5pJdAOM6sFo9SDHeCuWg9Y3Pbp3iN8vr4asOcUwX43E8mmkIcObDPd5b
	b/nndL9G9BIYAe8XK4eB05HvjILKYVFYAuaFUAEnVmFarpaq6oO4MPLjNJWZup7nLCGCB4yPzG0
	t4dQ6XobLlry6rdtp9gZ2ehGA2CEFykgLe2oSR7TQ8wQ9+s1y29cq9190cnaAOB68zNe2BHH/fC
	LtfOti87yvBfgZCupbUnib7JNjGUPhEokcIoJuJ9eblYYjVZA04IwyUz3JrkcHNDM3CyWHmVSf0
	xf8C/JhM/zsRikGjJbpp7uVAVjiBJHTmOBPVKMtji2QS8RStr8rX7i87Yyna7vBGPvOuZvQCALW
	q7+oHI48AyoUThaqPt19/v+mBno/Znc3PdIdU+B2rdw8TBp++ljFOxoX2c/tf+DF4++dy5uSsuI
	hVK1ZObUcgwFCeh5qdnozHw19Dw87Cw/bL2YeEfj9nkw9Y+JCflD/8/uUDb/qTc427lq0vTOjgw
	YIZvA/xSeJCRavXh2JratB//dA==
X-Received: by 2002:a17:907:da15:b0:c16:2dc0:e1ef with SMTP id a640c23a62f3a-c1fe7ee26f5mr869611266b.14.1785766268469;
        Mon, 03 Aug 2026 07:11:08 -0700 (PDT)
Message-ID: <8b5d403c-e77a-45cb-9e3c-d6ccc8ea7a20@suse.com>
Date: Mon, 3 Aug 2026 16:11:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: privcmd: fix ioeventfd crash under PV domain
To: Val Packett <val@invisiblethingslab.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux.dev
References: <20260708082934.16038-1-val@invisiblethingslab.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260708082934.16038-1-val@invisiblethingslab.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------1AXnnEZdKSQIDXhChQCpZZ8V"
X-purgate-ID: tlsNG-d62444/1785766269-BDE78757-0F716071/0/0
X-purgate-type: clean
X-purgate-size: 6791

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------1AXnnEZdKSQIDXhChQCpZZ8V
Content-Type: multipart/mixed; boundary="------------jjPFIGwq8ny90GlEvD0bObib";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Val Packett <val@invisiblethingslab.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, virtualization@lists.linux.dev
Message-ID: <8b5d403c-e77a-45cb-9e3c-d6ccc8ea7a20@suse.com>
Subject: Re: [PATCH] xen: privcmd: fix ioeventfd crash under PV domain
References: <20260708082934.16038-1-val@invisiblethingslab.com>
In-Reply-To: <20260708082934.16038-1-val@invisiblethingslab.com>

--------------jjPFIGwq8ny90GlEvD0bObib
Content-Type: multipart/mixed; boundary="------------3t26jS1XeIREdEEEzFWgOEUG"

--------------3t26jS1XeIREdEEEzFWgOEUG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDguMDcuMjYgMTA6MTgsIFZhbCBQYWNrZXR0IHdyb3RlOg0KPiBTdGFydGluZyBhIHZp
cnRpbyBiYWNrZW5kIGluIGEgUFYgZG9tYWluIHdvdWxkIHBhbmljIHRoZSBrZXJuZWwgaW4N
Cj4gYWxsb2NfaW9yZXEsIHRyeWluZyB0byBkZXJlZmVyZW5jZSB2bWEtPnZtX3ByaXZhdGVf
ZGF0YSBhcyBhIHBhZ2VzDQo+IHBvaW50ZXIgd2hlbiBpbiByZWFsaXR5IGl0IHN0YXllZCBh
cyBQUklWX1ZNQV9MT0NLRUQuDQo+IA0KPiBBdm9pZCBjcmFzaGluZyBieSBoYW5kbGluZyB0
aGUgUFJJVl9WTUFfTE9DS0VEIGNhc2UgaW4gYWxsb2NfaW9yZXEuDQo+IFBWIHN1cHBvcnQg
cmVxdWlyZXMgbWFwcGluZyB0aGUgdmlydGlvIGlvcmVxIHBhZ2UgZXhwbGljaXRseSBpbnRv
DQo+IHRoZSBrZXJuZWwncyBwYWdlIHRhYmxlcywgc28gZG8gaXQgb24tZGVtYW5kIHdoZW4g
UFJJVl9WTUFfTE9DS0VEDQo+IGlzIHNlZW4uDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBWYWwg
UGFja2V0dCA8dmFsQGludmlzaWJsZXRoaW5nc2xhYi5jb20+DQoNClJldmlld2VkLWJ5OiBK
dWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K
--------------3t26jS1XeIREdEEEzFWgOEUG
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------3t26jS1XeIREdEEEzFWgOEUG--

--------------jjPFIGwq8ny90GlEvD0bObib--

--------------1AXnnEZdKSQIDXhChQCpZZ8V
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwoXsFAwAAAAAACgkQsN6d1ii/Ey/U
DAgAmd+R/wiU6Lccg8jX9tw5WrYHgjVRd99YLcspiEseAHZsU4BLHRyV8hSKHyR/ATE6m4shUuly
OsgYSf32bvicsIHYOiDbJ4XGkF8w7KItltBOv9QUYImxtaT5iQ/FkC2vuGEzkbubqXPQ9glUnK3K
7Kbh2+FzdkDLPJi12zgYaUWh43Hcqs0vbx/3uYjU0Vv0TVSVoUUx+dbA4R2j7qQUK11hRY0PfpX3
8JErwCCGhoxGQrYQFSKRf/Cjjx1Ki9NGOpfGDSWmVYRnRgKFeGZG0ClYO5e4GPbRg+BeP3xCH5tQ
N9AAdG7HnOPj8UGJulZGa4TGD8X6BS8/fjE+hhKd1w==
=xYVH
-----END PGP SIGNATURE-----

--------------1AXnnEZdKSQIDXhChQCpZZ8V--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:12:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:12:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381508.1625059 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtOi-0007ti-R8; Mon, 03 Aug 2026 14:12:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381508.1625059; Mon, 03 Aug 2026 14:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtOi-0007tb-OH; Mon, 03 Aug 2026 14:12:08 +0000
Received: by outflank-mailman (input) for mailman id 1381508;
 Mon, 03 Aug 2026 14:12:07 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqtOh-0007tR-Kt
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:12:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqtOh-00F6UV-1Z
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:12:07 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a1ab-e002-0a2a0a5209dd-0a2a450a9fe8-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:12:06 +0200
Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a1b6-f2d2-0a2a450a0019-d155da30b5e3-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:12:06 +0200
Received: by mail-ej1-f48.google.com with SMTP id
 a640c23a62f3a-c15f020a223so518366366b.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:12:06 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd44542d2sm589170266b.35.2026.08.03.07.12.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 07:12:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785766326; x=1786371126; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=MS/I3nwa6tPsNEN+LIrocgCk6NLiF+ItW1O5FQY1Gfw=;
        b=NBugHU9fLau0W+HlgVet7pRCEz4Tu5GN9MTbCGc6wGuMBzkFZyRMWawVlep5QAUdLG
         fDx9/HqlZ4rJiaU1JodrPqx3FlBsH/tbGJVEjw8EBKdBCgC8/qE0dcf/ub1HAdDxPprD
         gv74BaXEMXmK0nTkO3y79aybqW/3vaHdkfFD7Kn0422h6z8yon19RL+ZlWE07GDpXEOS
         HDHM9mTDUOwR1jxsOaWS3mkD7n99Awo1oDKYnHHFjvs+sEGQUG4k9EW7aBO7VlNz6JvQ
         /la2xKc63a0VUBggGhP2DZ2EHYkUuNkGuIMEp84/ETfJZTqlwJEPyfNJp0+zjA3n26C1
         L84g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785766326; x=1786371126;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=MS/I3nwa6tPsNEN+LIrocgCk6NLiF+ItW1O5FQY1Gfw=;
        b=S/dwACj/YuvSW18qZ2bMku2GPZ9FoA5jMRw/Gmv9TaO6Y7wa2gv2MzuAqCDEKGty9v
         MgSHUxnG6lAURNd4uU15kcL3jKuWW5nARrrBkY0FjlHN8B+lP1gQyMXxLuh1cvoaiHxZ
         cMJDz+dHZl842TAyxr4EksqDCoWwDUWx4HFJkckmW+NiPw3mfi/jpEMSq6/GedGyOzot
         XPGfMANUG4hUbGRY5XNB5E/XJPsveqr+DwbJsQnSzXuf5yoBrDk1Lijn08hxzRiFOJFG
         sKGOD860L5GY91nZWTlvNW0zVvZdFiJc4qeF0qt91I8glVoVj+WW6ORniZ8vquMqsFLc
         ec/A==
X-Forwarded-Encrypted: i=1; AHgh+RqAWSgD8mbrZkaeVtiZkApcvosTw4Ux1fbnq9lvDYD8hlUy1ssoMGMXk4ycIZ7XrnS4bxFSBZV2j9s=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy56miseFDdeuxcqoppfMmJm5ztb3AZ7lSU5jDzuo3pW0JUKCDV
	cOTT1O96wdWb2iLIsf5s5BSB8foKS3JCBxvs3Tmvlc6M8sA8pSDdvzUVhjrUT/olYqQ=
X-Gm-Gg: AR+sD13y7LVrDBIUs293mVr0um3WFrJdle4Qap+Iss+EoeO9zKjLWtEi6xgVdgJhytf
	jYzDpJBkqEZ3NJGKdqLLVJItUJDzZPTEUZxsNdYzgddNcvlINlWjrJZyGFk/fkWIJp12wy43mGI
	x68yXdEmKQbtXaoLzJfmrLN6kctsLsJCgp6ia+5DDx2kBXeTg27lhbnh7ebcDEJZXdAaFKU1LRw
	sWopoJIk60qlV0+23n+/rhIHg9IZXn13VF/7Px0K5ijfjNt1nciGU2e+kYTbBaJiGWPTxckBfWV
	Rxj/vQDbSd/x8cpx4wulqHXIN+tD1XqivZ20wTiY7pUaDLmNZJUgCrF/dvZS847N1Wx46HktCLh
	smhz4kLYsxrzt9IcJzVkWwWAKqB3zVGx/6A5zYso7sjPepSe9n43RnFH7A9/6wLdqa6/Q/mfM8H
	lI1Q/0cr6BORIeB+J7EARukMKX3wbpOCS6iPUNdC5NRCYWKuLQEy9oj9og/kgrZ0PGGnsZVUp3Q
	+2tcrgGU3KiykiSqGhZ2wEE4XnVycvTHuQwUcEr1ca8lmRrQCTO1Ej29fIRcKXSrzPt/Xj2fsHU
	zzkGTn3b6Wv2bzE=
X-Received: by 2002:a17:907:d28:b0:c20:1bc5:7002 with SMTP id a640c23a62f3a-c201bc577a6mr147988666b.3.1785766325454;
        Mon, 03 Aug 2026 07:12:05 -0700 (PDT)
Message-ID: <2d4b7ec8-7900-433a-a3b4-a5b043e55ca8@suse.com>
Date: Mon, 3 Aug 2026 16:12:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xen: fix init of balloon stats for PV guests with
 memory != maxmem
To: Roger Pau Monne <roger@xenproject.org>,
 Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: Yannick Martin <yannick.martin@okazoo.eu>,
 Thorsten Leemhuis <regressions@leemhuis.info>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
References: <20260730143548.39320-1-roger@xenproject.org>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260730143548.39320-1-roger@xenproject.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------102FQPugHI0qaeHSeczrm1XT"
X-purgate-ID: tlsNG-4011c0/1785766326-518C5CFC-65CB5895/0/0
X-purgate-type: clean
X-purgate-size: 7035

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------102FQPugHI0qaeHSeczrm1XT
Content-Type: multipart/mixed; boundary="------------JqWSU2jrs0iCl3o7E0OAmZf5";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Roger Pau Monne <roger@xenproject.org>,
 Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: Yannick Martin <yannick.martin@okazoo.eu>,
 Thorsten Leemhuis <regressions@leemhuis.info>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Message-ID: <2d4b7ec8-7900-433a-a3b4-a5b043e55ca8@suse.com>
Subject: Re: [PATCH] x86/xen: fix init of balloon stats for PV guests with
 memory != maxmem
References: <20260730143548.39320-1-roger@xenproject.org>
In-Reply-To: <20260730143548.39320-1-roger@xenproject.org>

--------------JqWSU2jrs0iCl3o7E0OAmZf5
Content-Type: multipart/mixed; boundary="------------wDZ9xUzZMQeFCoQUHq4De83r"

--------------wDZ9xUzZMQeFCoQUHq4De83r
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMzAuMDcuMjYgMTY6MzUsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gVGhlIGhhbmRs
aW5nIG9mIGV4dHJhIG1lbW9yeSByZWdpb25zIGRvbmUgaW4gYmFsbG9vbl9hZGRfcmVnaW9u
cygpIGlzIG5vdA0KPiBjb3JyZWN0IGZvciBQViBndWVzdHMsIHNpbmNlIHRoZSBpbml0aWFs
IHRhcmdldCBpcyBzZXQgdG8gcmVmbGVjdCB0aGUgcmVhbA0KPiBtZW1vcnkgdGhlIHN5c3Rl
bSBoYXMsIG5vdCB3aGF0J3MgZGVzY3JpYmVkIG9uIHRoZSBtZW1vcnkgbWFwLCB3aGljaCBj
YW4gYmUNCj4gaGlnaGVyIGlmIG1lbW9yeSAhPSBtYXhtZW0uDQo+IA0KPiBJbnRyb2R1Y2Ug
c2VwYXJhdGUgbG9naWMgZm9yIFBWIHZzIEhWTSBpbiBiYWxsb29uX2FkZF9yZWdpb25zKCkg
YW5kIGhhbmRsZQ0KPiB0aGUgZXh0cmEgcmVnaW9uIGNvcnJlY3RseSBieSBhZGRpbmcgdGhl
bSB0byB0aGUgdG90YWwgYW1vdW50IG9mIHBhZ2VzLA0KPiBpbnN0ZWFkIG9mIHN1YnRyYWN0
aW5nIGZyb20gdGhlIGN1cnJlbnQgYW5kIHRhcmdldCBwYWdlcyBhbW91bnRzLg0KPiANCj4g
Rml4ZXM6IDg3YWY2MzM2ODljZSAoIng4Ni94ZW46IGZpeCBiYWxsb29uIHRhcmdldCBpbml0
aWFsaXphdGlvbiBmb3IgUFZIIGRvbTAiKQ0KPiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg
TW9ubsOpIDxyb2dlckB4ZW5wcm9qZWN0Lm9yZz4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4g
R3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------wDZ9xUzZMQeFCoQUHq4De83r
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------wDZ9xUzZMQeFCoQUHq4De83r--

--------------JqWSU2jrs0iCl3o7E0OAmZf5--

--------------102FQPugHI0qaeHSeczrm1XT
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwobQFAwAAAAAACgkQsN6d1ii/Ey9J
Bgf9HymnFMUKn+2bsmwaBf5rACLUjwPLhafp6AAAf7Qw6kTOJcJpM6xq0xqTcvHevmuXlXsGC09c
3/RvrZQD4dLA1yzEx5sueDYxhhcRl7H4cm2R+jVw+QJzmtc+5Nu+KlK4bhcBED/+wuYxiuGofABq
s9zCbpVKlh0lhd1jPE8bTts7AXJ2y3gVyURfJud7xHe0OiI+Cz19TypkzEoIr/0FkgJtOABVFmQ8
oLBLsVFijdd2EW4vLC97sXkffzv6VXsTfGZKonC5dlcI378QvCbjRyMyikTzd5eZJDHhBmLYVruh
O3KAw+pZ8dbAET5Q0hqCMFePMYSQJSfowAYAIBO8Yw==
=HiJW
-----END PGP SIGNATURE-----

--------------102FQPugHI0qaeHSeczrm1XT--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:16:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:16:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381516.1625067 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtSv-0008VG-Ac; Mon, 03 Aug 2026 14:16:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381516.1625067; Mon, 03 Aug 2026 14:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtSv-0008V9-7W; Mon, 03 Aug 2026 14:16:29 +0000
Received: by outflank-mailman (input) for mailman id 1381516;
 Mon, 03 Aug 2026 14:16:27 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqtSt-0008V3-Ft
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:16:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqtSs-000Vfj-Ft
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:16:26 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a2ab-5cb7-0a2a0a5109dd-0a2a450bce52-36
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:16:26 +0200
Received: from [209.85.208.52] (helo=mail-ed1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a2ba-b7e8-0a2a450b0019-d155d034d556-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:16:26 +0200
Received: by mail-ed1-f52.google.com with SMTP id
 4fb4d7f45d1cf-6984169c126so5837989a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:16:26 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd455ab7dsm554385966b.58.2026.08.03.07.16.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 07:16:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785766586; x=1786371386; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=9zmKpIRJOfwxhVT7o5SfsschrPF9Vp2UNHR3Vo7J7+8=;
        b=G29KKn78HpxbUgJFLcTuU/G9ezHarDKKGzPoZ2GGXzTa2c1AA+pIBPbf5P6X4e6hr1
         VfaphAP0Az8ah/pWfebawQ1DUQ9jCvg9j7kMa/WiPTi+t9ktHX19UDJLxksPf/ETAQhx
         BfxvJooVgCx1QYSkldMxKd1+i2c8PD9cc3MG7ZwLGPcd2oOIJ/ke5R+wc7m1FuCV6pyQ
         ZlJ0u4vOj5JJqPXjgI+XplRunvjZkWjP57IPpIc/xeZgMo5opzgM0/GXPgW5h2eH0yTL
         0tt8oeFDwvErgXgji8DniGc3WUkWxs5fBBo4JnYVh34gGNQxApoPaOyBjBR8axEA6AgU
         SV8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785766586; x=1786371386;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=9zmKpIRJOfwxhVT7o5SfsschrPF9Vp2UNHR3Vo7J7+8=;
        b=dQgnvOV2FfOBU2XySuH7WnY9wjsxEV6okKq+dTBs6f+bQecwjXTD5YWy4QPE2U0IDy
         Kvy9A8ea2xyoQ6ilToR0ngG3tTwGsz3854PTW9OCjRFoD6Cnmw9D+4ichE5ffm5TsgGr
         Wpxy3P53Ol25IgpCHnpNT+2k13XylxhKGK1dur0kY0FbFeh0gQv/cUu1iBuk/qHdx6XN
         SZCX305UuWoDCKi+B7JiLfRM2WY9+FHxw1822nMsru1bt70FYsYD23uqImw26Kx1rFf6
         lKa4n75OaKzViIaxJNSoh9cBILm4v3kEJA7074m9RwkDlEbVzynbQdCVor4RkFfyCJju
         U2/Q==
X-Forwarded-Encrypted: i=1; AHgh+Roydl6Jkt1QmKb2O2TqKNATIAvqnuqZwui2jXXMFpuC5va86jXGuxMdJud7qKZLX8BAZoup4eazd0U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyb/JlisrugPBJ/Y5E6JNYiaptP5MT5xE6pzWMgPYVBHzo2vr/L
	6De6zYc5clJn2sQZr1dwAGC7xP1Px/yUSuBgTzT4adm1bPl/Fj+CrhyaKba1o3N7fEY=
X-Gm-Gg: AR+sD13VZqLcbt4JTJo0VQsolFhK+6nzYGsCdrMdgXuo6mcrCult9z+p68gvg9Yl0kK
	AMcs8o765zDG5ZuCNz69pmY3EDZExrejNZCTdN0yOOIY23Z7/c3t0VmNHY9yReVwiqKR5cTmqzC
	xHcXPTUbEkey4jCEuLoVZHhcG63uHexO0Qb2S8QlRuIipYuT/x3ongo7wotmcJm8zdRll1lbXpn
	/jHhdD31TuW7tBgEZtH2x76Ub5QRgpJabLunJCC3n/GcPbu1/Xkhn2kcsY/sahnp7toFY7vWQ/a
	Qd8QFDlJhCoIcSHRNt1+gD9lMY9Aa5ykqx1rKhfETuPIPyobkpiLPH6mhzWL2PkVz+AaQxBi0Sf
	whHhzB07mMIlUQe3fKBf96ZCslIed67SGvcL0m58NffsQfzC77hmi0WwjtN//d5G9BXPCRCkRR2
	OqujY2PVCITGhxkQQRHPLjp07WbWIeSZMrfDCELyIro6DW39l57EJV8BgVx2bK1xG7CkXSIa9Ma
	VU5yGmkzf6li0uUbvDeY7fIYB/lysvg5ZxwrtOuY90HENm6fr1zZZ0seJJCxALszIx3ICi52f/y
	kT4IpCXBkU/KdGs=
X-Received: by 2002:a17:907:db01:b0:c15:cfb4:6a6 with SMTP id a640c23a62f3a-c1fe816c171mr848842166b.30.1785766585905;
        Mon, 03 Aug 2026 07:16:25 -0700 (PDT)
Message-ID: <862428ae-e706-4300-9eff-d55db42e841b@suse.com>
Date: Mon, 3 Aug 2026 16:16:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/xenbus: log more information when device state
 got reset
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, linux-kernel@vger.kernel.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Jason Andryuk <jason.andryuk@amd.com>,
 "Martin K. Petersen" <martin.petersen@oracle.com>,
 Jakub Kicinski <kuba@kernel.org>,
 "moderated list:XEN HYPERVISOR INTERFACE" <xen-devel@lists.xenproject.org>
References: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------4RlqZjK6tRdeNjWmWmqFkmOH"
X-purgate-ID: tlsNG-42698a/1785766586-18CCF9EA-48D2CD05/0/0
X-purgate-type: clean
X-purgate-size: 6452

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------4RlqZjK6tRdeNjWmWmqFkmOH
Content-Type: multipart/mixed; boundary="------------M8zyK6hx8ej1F0xDZaNfD0nJ";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, linux-kernel@vger.kernel.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Jason Andryuk <jason.andryuk@amd.com>,
 "Martin K. Petersen" <martin.petersen@oracle.com>,
 Jakub Kicinski <kuba@kernel.org>,
 "moderated list:XEN HYPERVISOR INTERFACE" <xen-devel@lists.xenproject.org>
Message-ID: <862428ae-e706-4300-9eff-d55db42e841b@suse.com>
Subject: Re: [PATCH 1/2] xen/xenbus: log more information when device state
 got reset
References: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
In-Reply-To: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>

--------------M8zyK6hx8ej1F0xDZaNfD0nJ
Content-Type: multipart/mixed; boundary="------------1FvQFrZLlUfEjHgTmLcxY5wr"

--------------1FvQFrZLlUfEjHgTmLcxY5wr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDMuMDguMjYgMDU6MDgsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN
Cj4gRWFzZSBkaWFnbm9zaW5nIHdoYXQgYWN0dWFsbHkgY2hhbmdlZC4NCj4gDQo+IFNpZ25l
ZC1vZmYtYnk6IE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNp
YmxldGhpbmdzbGFiLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9z
c0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------1FvQFrZLlUfEjHgTmLcxY5wr
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------1FvQFrZLlUfEjHgTmLcxY5wr--

--------------M8zyK6hx8ej1F0xDZaNfD0nJ--

--------------4RlqZjK6tRdeNjWmWmqFkmOH
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpworkFAwAAAAAACgkQsN6d1ii/Ey9s
Kgf/V4G7MjXBhRqRA7cRQIYPI151zhTJOQc1Q7MZzibRI5Nb6tN+diWzCGnEoCXOJ9fHUKppBtzt
w9BgEYrmWtMRG+jM1itBKMdC83vOX5ik0WJumFNlntYHBNV55D2aQSwNt6xpq4XfKcEafYjvQi2a
cNuxv5ex8NK8/9UFpifeOAFqouarh02Qf95WmXX7JcsHKUUpcI/LHXqfoK6Y9BS5gieTFTAp3a8P
sy2cZG/soaRTkQ9junw5Z3Yl7aOPITi+zE1xDK/r1afxEwCmUHx+zPv3C0DyjP0z/kRsZ4YV2GD9
xn9lQ68FslYXfponE8FIKuAk27Mo8FC5xUDXq5T/Xg==
=vh3K
-----END PGP SIGNATURE-----

--------------4RlqZjK6tRdeNjWmWmqFkmOH--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:16:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:16:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381521.1625076 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtTL-0000RV-H6; Mon, 03 Aug 2026 14:16:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381521.1625076; Mon, 03 Aug 2026 14:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqtTL-0000RO-ED; Mon, 03 Aug 2026 14:16:55 +0000
Received: by outflank-mailman (input) for mailman id 1381521;
 Mon, 03 Aug 2026 14:16:54 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqtTJ-0000R3-Sj
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:16:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqtTI-005cGg-TQ
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:16:52 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a2c5-2eae-0a2a0a5409dd-0a2a4507bab2-44
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:16:52 +0200
Received: from [209.85.218.44] (helo=mail-ej1-f44.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a70a2d4-b4ea-0a2a45070019-d155da2ced76-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:16:52 +0200
Received: by mail-ej1-f44.google.com with SMTP id
 a640c23a62f3a-c15cf78d1a2so407034366b.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:16:52 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd4454321sm537745666b.31.2026.08.03.07.16.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 07:16:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785766612; x=1786371412; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=2tPYjDuAYCYdNaJq4I9qGJyfSrpnRvk91bWPEkVR1nk=;
        b=EDgd2SrWvzhq8buZhuYuzrEiEmbwfvaWd2Zq0jIzm8nFrMd5/YJsB52bUoqbwXacuU
         0aWXppOqzq8nSbDF6ZrVvWkfnAkkonh2Arj+Xd/mj8dp48DTFlNHi0GbCSgiY/FrSI6L
         ATMxmgOAgES8H9JapvlKAyb/TCkdOeAQdGCi1w8abU0732iPT3jrAV4hI5hxzOG12Be9
         bO0bz7gfyP9f78VOWZkzTZj7uGBWVDx7F9yVVg8otAUV3nP6/fPK3daA9HAEQPti8p+O
         4e1iJQGO5nf08he24e7EL8ndlQ3AuOYXn/gCqOvtmJxMW74saUmTIuoU3fp9PAEjvpC2
         KB1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785766612; x=1786371412;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=2tPYjDuAYCYdNaJq4I9qGJyfSrpnRvk91bWPEkVR1nk=;
        b=E4zKDGrJA/8BFMyE1eg1gdp35ExkwQUyUsAqKXCQTyJ+2UTopF7Q9MnZhTbq7Lyhac
         8XhYDVlc3bv0sAhW5jOZ1UMrEmuypbTZSkfuwrf96MU7M2tVmETd2bNemHKjxL/djJwf
         bXLuqXXB5zdJRh5mIl3z2u7Dz7s+nwkf52qkT4Z8kxVmpVDNyQjbd5LL9Je0WiAGQnVa
         T5WSQ9tihXVGzi5GG67JSWOM8O+aThKzBHzmx2vtwteEI4SLamNzobfGc1bHPYYv5MeW
         wEln+TCrF4/0q8exMOarWDDE+k3xyLTwyF767iN+I/sFCuCiKROsyFrbF8+4edsZsZ9L
         PDQg==
X-Forwarded-Encrypted: i=1; AHgh+RoHKdWNxQvacuQIIRdciCeNDjzD2pUO05PKfJxetdGFC9UwqrEAGxyKUa2kO1dJOAYpj98K5JTKCUA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzup9LZT27UezuhOacVFG5AgxMcxw/XcUD4K1ZYmGcDQTZrGuzO
	EC/MSlS6IlhtSk2Ku1YXTzb483YF2vJ7W05ltte7R29E6dS/tXgsCmQCfzaOF9MTFMY=
X-Gm-Gg: AR+sD12wAS/tPVRG0vqcqwR+8i5q8CN3jfuJMGSIOJFwOP810OaGRInKhPKSzZKw6ud
	psjBlHThcYs3ajvSm0t3NGzFYHJYH5HqwZ2skSAXD9Sot9QMhXb2ACKZ+ZnJKf94iKyz5i5U/4E
	R+tlaTBbo80+uK0HDiSsKALfKpnaNjJlFVAeLyCdcOJ9RYp1hh2sKbYlI5paemuGrRT/jO5ZUvR
	eoQ7r6PSjd1FI4EvhgbUNYn7AGZNRzzRThqnc9QIM3MUh/DEWnkFBVH+RJpC4Ff6lXolSXSrHRG
	Nr81SnGAoOcoqkVO7jSGNDX2HXhvKfEXMXmB1CliIpBpnN29vQO1UxilC0gxfQ7g1/WyT1iVXhP
	rI6qVd5eeq/kaW1qkZIOwCaRDgAMCrGStmWuNH4eGkThV7j+HsegPQ+vD4zjZb7sYkVAKw7jmIC
	wmvbSF9QGGlU3RvsTtEqalVrG1HTHqh35KCiQl3Qn7iTaGrv7KvVUvaiubDQqpoldA2PQv1P8PT
	FOxz4wLvZP/clgtHuBtIHCr3AswssiNWqzOvGGbYPJLfOOz/SNqeQzjfoahEDHGXTyPOqEZGEZj
	kS+AuED4svNHa5A=
X-Received: by 2002:a17:907:3e24:b0:c16:1a00:3feb with SMTP id a640c23a62f3a-c1fe7eec66dmr989728066b.15.1785766612172;
        Mon, 03 Aug 2026 07:16:52 -0700 (PDT)
Message-ID: <68379ceb-85a7-4d86-aa05-00766b4d6da3@suse.com>
Date: Mon, 3 Aug 2026 16:16:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen/xenbus: check otherend_id only after it has been
 initialized
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, linux-kernel@vger.kernel.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Jakub Kicinski <kuba@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
 Jason Andryuk <jason.andryuk@amd.com>,
 "moderated list:XEN HYPERVISOR INTERFACE" <xen-devel@lists.xenproject.org>
References: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
 <20260803030822.4104093-2-marmarek@invisiblethingslab.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260803030822.4104093-2-marmarek@invisiblethingslab.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Np676FD9hdO4V5vtfRruHXLO"
X-purgate-ID: tlsNG-ef75cf/1785766612-A66DAAE4-D371476D/0/0
X-purgate-type: clean
X-purgate-size: 7591

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Np676FD9hdO4V5vtfRruHXLO
Content-Type: multipart/mixed; boundary="------------HYR8tqeqAMQWvqblcxL6iSaN";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, linux-kernel@vger.kernel.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Jakub Kicinski <kuba@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
 Jason Andryuk <jason.andryuk@amd.com>,
 "moderated list:XEN HYPERVISOR INTERFACE" <xen-devel@lists.xenproject.org>
Message-ID: <68379ceb-85a7-4d86-aa05-00766b4d6da3@suse.com>
Subject: Re: [PATCH 2/2] xen/xenbus: check otherend_id only after it has been
 initialized
References: <20260803030822.4104093-1-marmarek@invisiblethingslab.com>
 <20260803030822.4104093-2-marmarek@invisiblethingslab.com>
In-Reply-To: <20260803030822.4104093-2-marmarek@invisiblethingslab.com>

--------------HYR8tqeqAMQWvqblcxL6iSaN
Content-Type: multipart/mixed; boundary="------------xBoTws2zYZvW03IxmXVfJFNO"

--------------xBoTws2zYZvW03IxmXVfJFNO
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDMuMDguMjYgMDU6MDgsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN
Cj4gV2hlbiBkZXZpY2UganVzdCBnb3QgaW5pdGlhbGl6ZWQgKGZvciBleGFtcGxlIG9uIG1v
ZHVsZSBsb2FkKSwgdGhlDQo+IG90aGVyZW5kX2lkIGZpZWxkIGlzIGluaXRpYWxpemVkIG9u
bHkgYWZ0ZXINCj4geGVuYnVzX3JlYWRfb3RoZXJlbmRfZGV0YWlscygpIGdldHMgY2FsbGVk
LiBJZiB4ZW5zdG9yZSB3YXRjaCB0cmlnZ2Vycw0KPiB4ZW5idXNfZGV2X2NoYW5nZWQoKSBi
ZWZvcmUgdGhhdCwgaXQgbWlnaHQgY29uc2lkZXIgc3RpbGwgemVyb2VkDQo+IG90aGVyZW5k
X2lkIGZpZWxkIChub3QgbWF0Y2hpbmcgYWN0dWFsIHhlbnN0b3JlIGNvbnRlbnQpIGFzIGEg
c2lnbiBvZg0KPiBkZXZpY2Ugc3RhdGUgcmVzZXQuIEl0IGNhbiBoYXBwZW4gYmVjYXVzZSB4
ZW5zdG9yZSB3YXRjaCBhcmUgaGFuZGxlZCBpbg0KPiBhbm90aGVyIHRocmVhZCAoeGVud2F0
Y2gpLCB3aGljaCBjYW4gcnVuIGluIHBhcmFsbGVsIHRvIHRoZSBpbml0aWFsDQo+IGRldmlj
ZSBwcm9iZSBydW5uaW5nIGF0IG1vZHVsZSBsb2FkLiBJbiB0aGF0IGNhc2UsIGl0IHdvdWxk
IGNhbGwNCj4gZGV2aWNlX3VucmVnaXN0ZXIoKSwgd2hpY2ggd291bGQgZGVhZGxvY2sgYWdh
aW5zdCBkZXZpY2UgcHJvYmUgZnJvbQ0KPiBtb2R1bGUgaW5pdC4NCj4gDQo+IEZpeCB0aGlz
IGJ5IGNvbnNpZGVyaW5nIGRldi0+b3RoZXJlbmRfaWQgY2hhbmdlIG9ubHkgYWZ0ZXIgZGV2
LT5vdGhlcmVuZA0KPiBpcyBzZXQgKHdoaWNoIGhhcHBlbiBhZnRlciBvdGhlcmVuZF9pZCBp
cyBpbml0aWFsaXplZCkuDQo+IA0KPiBGaXhlczogZTJkY2Y5MDY1NTM2ICJ4ZW4veGVuYnVz
OiBiZXR0ZXIgaGFuZGxlIGJhY2tlbmQgY3Jhc2giDQo+IFNpZ25lZC1vZmYtYnk6IE1hcmVr
IE1hcmN6eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhpbmdzbGFiLmNv
bT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0K
DQpKdWVyZ2VuDQo=
--------------xBoTws2zYZvW03IxmXVfJFNO
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------xBoTws2zYZvW03IxmXVfJFNO--

--------------HYR8tqeqAMQWvqblcxL6iSaN--

--------------Np676FD9hdO4V5vtfRruHXLO
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwotMFAwAAAAAACgkQsN6d1ii/Ey//
HggAmKerqd0ZKg0S7g5eb6J9TTXeuOhucdi85EdBRUmVgzfUGSpehy8fMSuix01V9s4AWmbFwBu0
Wjs5pu2Z1W2J6m5kduTsNqU7S5hQ8Hkpuk5obLb18yg6o4aMR4ZzC1dlHV0uWmmfLr6yoEssvY7K
P5Fp5Cys4xAi0Q6gi0MCC/9gkbDR4Ykm4vmN1Tl2E4PCe+WbPwogtjIj9LunF0sk1AsOOXduqhFW
tqz2B1cwu+u/qhQRgwR+qXenip25ScMAtl9nZKNqo/BZwHRCbnf4dP+2cvi0dd6FUXaQn69F/slW
v4DBcz9e9wBxykk4gQRmzZcsffCcyrwdl25tSduAlw==
=Gvk9
-----END PGP SIGNATURE-----

--------------Np676FD9hdO4V5vtfRruHXLO--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:23:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:23:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381532.1625085 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqta0-0002yd-9K; Mon, 03 Aug 2026 14:23:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381532.1625085; Mon, 03 Aug 2026 14:23:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqta0-0002yW-6K; Mon, 03 Aug 2026 14:23:48 +0000
Received: by outflank-mailman (input) for mailman id 1381532;
 Mon, 03 Aug 2026 14:23:46 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wqtZy-0002yQ-P7
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:23:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqtZy-008Lpw-0e
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:23:46 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a70a471-e002-0a2a0a5209dd-0a2a4508c968-0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:23:45 +0200
Received: from [74.125.224.52] (helo=mail-yx1-f52.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a70a470-f659-0a2a45080019-4a7de034a98b-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:23:45 +0200
Received: by mail-yx1-f52.google.com with SMTP id
 956f58d0204a3-664e3ed58bcso5999374d50.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:23:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1785767024; cv=none;
        d=google.com; s=arc-20260327;
        b=qUgfs/2xcuc0cfk1lvM/KQlm+bowFUjBSiFvMt74wYIpCRUiQZiNthI6OlRbtdFPjh
         J7AmKf+MwiQvyXwd3ktWF4CuEgQB8k03W32FyQMVY6GEOG3tWWT/KIhrA9x8B0rNEDjt
         tObewF0j42Tu9dt3DElY09zBfFLZ9JV6vzUhQ1rY6IFDVdgTHabqkWl+We89m4KjslS1
         eB68oACSbiSK5FhYBjItZTaqYQh2/cKYny+ZjzynzAsPY74/q1VajhEU3cPK+UMhkFCq
         XNAWyXG7e1OzK/lOABLQZWuvm6q9wcMvj5X76L859TUJwYBtpXZwllJrbUHle64LOloj
         RBiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=wJiMbpzbgvUxnGJ9663a2S4Y/6f0ltDGF8OXt0DNfUo=;
        fh=5u7kHD1b/hNtHHJofCBl7jWiqXiR32ui2YCHFqJNZUo=;
        b=hTPn/K9KCAfKPpXLlfaaOjpJ3Ctps0Fk1s42Lm3Unt2ZHHMJQTDWAV2LfGZrcYV7mF
         VBImqNmYAzZmB/4RWOdwgcVGji3Hqxj7XN9HRhPgspZjiowRnjB09BicZvVL5nKIu+ix
         amItkki+1rrSkkI4+sq504Te8gsksS4YD3f8ZLpH0hnmx+H7kYaWYijLOD27u3W1piSN
         mWcCc6NFzfped0Bbj7fVrHfdeExbwbdWgqiLYuKL8A6umqNBGsha2hxsG/+uVt5byXzj
         zJQkwgTsBdMlgn+gOmOVOzIVLpPf2/Pyt6iG4x5fyHDsZW0ToD5M+T+I7VQzOh8gT8tE
         5rCw==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785767024; x=1786371824; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wJiMbpzbgvUxnGJ9663a2S4Y/6f0ltDGF8OXt0DNfUo=;
        b=aKDIFLikEEU2Z3SXKAP059KDA9JCtI0RNdzpcsqmnkElrwe6eKDx5QKpbVV0AYEeXv
         UfHWojekrSMwbwwo8UPjEj/b970kvK/AsjY97ImRPm1adBNzT02NYVsslxJgVLXfqzjx
         ClZx4pOW1SV7AIU+5Z6xxZPa3njzw9RYjzr2g7nTMNCPry7CoH4xm4XDrFHaZb+kYLaM
         UmEBFEPwijgUrCiFT6Mo47Kfaut+Bw8hZEpNilA7mr4awr/elAKqNM0T7k+cu5K7wym6
         7VpZ6Ywd6ogyManzO0PT8SgdO+1oob6hduZ4NTPQXspxghh0dft8NbwqXyiE/XA4VmgP
         RjEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785767024; x=1786371824;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=wJiMbpzbgvUxnGJ9663a2S4Y/6f0ltDGF8OXt0DNfUo=;
        b=ZSrTt5ZjUsGYgHbdpZHWMvSW+jojiFjUIBeIhIVFsp2soBl9Ttjx8Y1ANFffuNucCj
         tu0D1Jtjq03OR2ccXrZli8n4rkfaCZKB4YprBbAo8AY6gP7eqhWtrh48qjdj4FM8NavS
         zIVrx+g/aNGyI2Ig4jfth8t1kAaaZkBmCUwaBTaUv9H+nLERIQbdKKCZSGTzXSX+DOth
         9iPMQRkm3GtwbEwolEoPfDA/bxB1xkJbwYou3AcFGD2DfaRoA+QgOAea/SVffR/zMYXH
         3c1ONMeUHkIF0Hx9udRPVzxOyMeiBUnowWQLyDntm41/bzgl0rYHhbejBFbnd/ammlIp
         JkBw==
X-Gm-Message-State: AOJu0YwSMtqBa3Kpvs1VVW8GyHUZ+vQHJfIxurRqFABBtcOT+BZyZGtq
	+2mPfDfjrOhx8vgvEw7hNfDPoBERjAhs3bbhkmAytrdusbbYmqRmngTN9flDekLGGixrgndg9C7
	82gvoGe27sm6m2QRKjf49AC/Rpp8gQTCirTvuio8=
X-Gm-Gg: AR+sD12DWmm08ldELLKSfRdBxXmJwXaWk6mq16wUyUHlkbZv8jPZVmTlFEtD+Jsgjju
	nGVWKOtYaYsjlrVZ7xvXU7q1ft20UPFYpDws/gff5pH7Ft38n9gd4LtqF5MPVewkMaxDbW/7rDp
	V0Vl9OMaXC35JSkuLXiCFE/Tqf2mXMBPJAG/L0FKHEH9AeI23fFxwmqfmvWZdo4QSnsiSo122Xx
	MLSEm6hAnrtikRsJqgSjV5zxo6YMx2906jWcRtn9Fz1tKGU/MiwAreZPZ+taD2/UOca6nyuRMkF
	2QdOZfGoAFrsQELPQW9t5tsidkbMRtTrx3WErlpoyUpqyO9wzpITDHxEXhHwNI+qxNKWQCUwmHn
	u
X-Received: by 2002:a05:690e:2506:20b0:665:2045:fe47 with SMTP id
 956f58d0204a3-66945bea125mr10911877d50.7.1785767024406; Mon, 03 Aug 2026
 07:23:44 -0700 (PDT)
MIME-Version: 1.0
References: <20260619130501.272832-1-frediano.ziglio@citrix.com>
 <20260619130501.272832-17-frediano.ziglio@citrix.com> <439c2740-fb84-42cb-b001-cb290684a583@suse.com>
In-Reply-To: <439c2740-fb84-42cb-b001-cb290684a583@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Mon, 3 Aug 2026 15:23:33 +0100
X-Gm-Features: AUfX_mz0p6FBcsbJBhjjFHmdqxj5qR1izMtTAZfJP_Yflmxkjgdnunb1POk8ZYU
Message-ID: <CAHt6W4dMZtyvMuAfFVG36z53b=a5m6P5gQ4HONGO3WzOBUJ-qw@mail.gmail.com>
Subject: Re: [PATCH Linux v6 16/16] xen/privcmd: Add new ABI to allow copying
 foreign memory
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c1860d/1785767025-D5D4887B-6A09A46B/0/0
X-purgate-type: clean
X-purgate-size: 2065

On Mon, 3 Aug 2026 at 15:05, Juergen Gross <jgross@suse.com> wrote:
>
> On 19.06.26 15:05, Frediano Ziglio wrote:
> > This new ABI allows to copy foreign domain memory to/from a buffer.
> > This avoids having to map/copy/unmap foreign memory which is
> > expensive.
> > This operation is done particularly when migrating VMs.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>
> While doing a test build I got the following build failures for 32-bit arm:
>
>    CC      arch/arm/xen/enlighten.o
> In file included from /home/gross/korg/src/arch/arm/include/asm/xen/interface.h:1,
>                   from /home/gross/korg/src/include/xen/interface/xen.h:13,
>                   from /home/gross/korg/src/include/xen/xen.h:52,
>                   from /home/gross/korg/src/arch/arm/xen/enlighten.c:2:
> /home/gross/korg/src/include/xen/arm/interface.h:22:35: error: unknown type name
> '__guest_handle_uint8_t'
>     22 | #define GUEST_HANDLE(name)        __guest_handle_ ## name
>        |                                   ^~~~~~~~~~~~~~~
> /home/gross/korg/src/include/xen/interface/memory.h:361:5: note: in expansion of
> macro 'GUEST_HANDLE'
>    361 |     GUEST_HANDLE(uint8_t) buffer;
>        |     ^~~~~~~~~~~~
> make[5]: *** [/home/gross/korg/src/scripts/Makefile.build:289:
> arch/arm/xen/enlighten.o] Error 1
> make[4]: *** [/home/gross/korg/src/scripts/Makefile.build:549: arch/arm/xen] Error 2
> make[3]: *** [/home/gross/korg/src/scripts/Makefile.build:549: arch/arm] Error 2
>
>
> Please fix those.
>
>
> Juergen

Mumble...

I suppose this would fix it

diff --git a/include/xen/arm/interface.h b/include/xen/arm/interface.h
index c3eada2642aa..7e79853b188d 100644
--- a/include/xen/arm/interface.h
+++ b/include/xen/arm/interface.h
@@ -53,6 +53,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);

Frediano


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:52:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:52:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381549.1625101 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqu19-0001TE-Ee; Mon, 03 Aug 2026 14:51:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381549.1625101; Mon, 03 Aug 2026 14:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqu19-0001T7-B9; Mon, 03 Aug 2026 14:51:51 +0000
Received: by outflank-mailman (input) for mailman id 1381549;
 Mon, 03 Aug 2026 14:51:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wqu17-0001Si-MV
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:51:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqu16-005i0I-E9
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:51:48 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a70aaea-e002-0a2a0a5209dd-0a2a4503e5a6-42
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:51:48 +0200
Received: from [74.125.224.44] (helo=mail-yx1-f44.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a70ab03-fae8-0a2a45030019-4a7de02cd8fb-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:51:48 +0200
Received: by mail-yx1-f44.google.com with SMTP id
 956f58d0204a3-668c1b780e5so5314004d50.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:51:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1785768707; cv=none;
        d=google.com; s=arc-20260327;
        b=e0td3MPQbXv/HxNE6lcBu/VK6RXHrwrLYuQ9fkQjIjYvktd9UP8S48TSjWfVp6GR0E
         hD9PasHOvFMEqLl9BQxCC/X7eOlcrlIIzqjZMbkn+aG68V7IgXS2Uf5p7N61z2pHx5wS
         F3myns0I+o8LTOp9T3BjlZpuXT4rQ4bQhr5v1d6W6IlAOTUWDG0v+ef61o0ktaZ52k52
         n7dlCwoX1MHdyCmY+ijfzX5fIUa693A9BHnUNpXjcu64cf5Twt4ISiLDPAtHsCKu0EqZ
         E+NfRlM9nl0WSUSt4uSiPHmf5Nrz+u0CSr9GI3Oqef8pwovp7jxugOpLjanGFJsx4gI4
         aJfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=D9ggXvuJw0OfV/7DwKJBrE2gM6POgD68kCOokV6rNFg=;
        fh=wWTf0SxaJts9rmPnRaimTcgF13vS7beuyeD2+6KhZkk=;
        b=RTgI8l67HilPsDjihHeO69y/3NEc4fwBC5lkIf0sLdVgxMWxsfuBLNRUa6XIRfLXq4
         sCCHjJMGZHSAtPwZdpXbt393je1JVvL1ommbkGIVwo0Vhfsv7MFL1yeq7Ki1FFRwmTkH
         +dL73V+2lNHQyYPyb7BTYXaPnkDLSrb5+QAZ8QtdJUnOTpbEDKZlDwMbxCWLJqOWi43w
         QvPlxAw1f95P9Cf03wAFpMf4ILbtrvbM/SzWYl5/9uqzHlcpg6KlCTyuEMO6CV/GGy7g
         gIq74r+N3qISH0Ck536u2uVAX0dPlTh75xw1/0kzTYAMw1oXvGQpAjHD3WBfp9o1U8+X
         3xRg==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785768707; x=1786373507; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=D9ggXvuJw0OfV/7DwKJBrE2gM6POgD68kCOokV6rNFg=;
        b=ICyiP5ifAHUUGf/3s9QWw1rwd0ifC1e9FWWH+J4UY9SiDSsavcIvGsAsbd4MlTJIMF
         LTmbL5EYYHixm1WNTXjsNz2EQx6rlxa/ZXWhMtE10g6GSVHdVXOaX3zBw8ZldeD9/1OF
         q4jr1iWb+0QrIVYA8fANUIENP5me9CN82jCjw+1BD/AFwzVttS/HAQiYph4XqvftzkI8
         ahdxr/Eqteq0oN04iCDPVHkG0nBFxbtOYACoGPV7HIaRtWhKolZWlNE0fv3Tcx1n8tlf
         InXCoa2t0D4NWu+YPHd8CAVnJMDtFgZKJH+JPc90iYeUgIg2ribCyKFGyL7cFQK1+n72
         DHBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785768707; x=1786373507;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=D9ggXvuJw0OfV/7DwKJBrE2gM6POgD68kCOokV6rNFg=;
        b=IjKB6DtOEbSrqU6Pzqi1d9vxIBDO2w469UN5KA0KBA6TNc/ylYCkolfyF+Hk3gC70T
         PGfKyReHOi2ty9ERKnLNnfRgEMX0CAwjjr/OEXsWb0BG+uBPhzAirKLDm3iYGq64pfcN
         4OYWCj4XaoKxH5o8cR2Z815sohqTwByQ86R+jWvd8+/nZbqY+b0Ob+Hn07X1g2eWf1Hr
         KQg3P7dAZoT3xM5Jg/kVN2Pbvdl0w04grcHtCxVLwMeG2u78l1zaHSIKNA2vUWF1/fnN
         dgVbTuEgyofTvefeDp85RdyFoKkO5TNkxaNNzVFIDC8bw3nWv4ea39pkxspGqZ360Ugz
         JJjw==
X-Forwarded-Encrypted: i=1; AHgh+RpMocEp5rzUBiPECuRjpwor1k2Hlweo7VRU6Z2PKHYneDFV8O4KnSC2BTBpZVW/NR5jraMDLJNwcg4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVpXpxZQqaxA/i0j89x/GWB6uBfNdqMn0FwjnsdjJou0k+DE+G
	9EW9Y5dLKhPnUiVDX4me6OiSIXLxql4/hawaYRBQMG10n8mCl9XgwtRvJB7MayWFUw6Cjx4jGeJ
	/I8CRSYIq5QJgM6gcH18kJWj3wpJrcHE=
X-Gm-Gg: AR+sD10qE6DSMgDXy/kkswYnM353wzBGZOK3DBBh8uTXRZ05eyKhRXHYz1MSicqG/5F
	gpgxW4snF7ZtWiaPU0COnz1ls6OzVMpbeImkTOXRjiTXL2RT96EF/8WW3VC8X+TxNL2Rjjj1qLG
	rVLTqaeSJVp14LZuupxP/XCj7ky3c91LUYhDpwW3pip3KYLcDbTmV1UZcNDJcnQVaFiKxkzC+zE
	0Zs7XePrquOxaHq83G7L+6eKO17pvBC7NQFh8NKGhryloBZEuhwku0EG5FkTgfcwqf8AZNk0dzX
	VvER93Za7ewG1rtT8enS3L/DRxtVYs/45tKV+MaIfOBRQgLIjCIXZyRD2ZAayOekPmZOGSJwUls
	j
X-Received: by 2002:a53:ca4f:0:b0:667:a025:89a4 with SMTP id
 956f58d0204a3-6694f08334emr9042125d50.18.1785768706580; Mon, 03 Aug 2026
 07:51:46 -0700 (PDT)
MIME-Version: 1.0
References: <20260619130501.272832-1-frediano.ziglio@citrix.com>
 <20260619130501.272832-13-frediano.ziglio@citrix.com> <c5f00fa4-4d9e-4227-87a0-6e657fd523e9@suse.com>
 <CAHt6W4c0FDaMZK-4-7CReG_PdV+L=HNxVGNjV5vUjDkKq3EMBA@mail.gmail.com>
 <2889dc4e-33ec-4d8f-b01d-026506a39cbf@suse.com> <CAHt6W4cghz1Rh=MXqmx6ZHA0iOz9xTBDNhFWaqtZ=npd4Hb=GQ@mail.gmail.com>
 <07b3bbb6-ef62-419c-b708-1b9ae2774462@suse.com> <CAHt6W4ckkQOKn9jvNpMG5meFeagY8uFZJsC6CEUsu9tfc17cHQ@mail.gmail.com>
 <46b70e9d-1ade-4ba6-ad5f-87d2c9652a7b@suse.com>
In-Reply-To: <46b70e9d-1ade-4ba6-ad5f-87d2c9652a7b@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Mon, 3 Aug 2026 15:51:34 +0100
X-Gm-Features: AUfX_mzy7nANcnwN3EGkyMZENWLyCWbjND7mD9ySmJskC8tgrgPc-DcdzJDw84U
Message-ID: <CAHt6W4dq+FzgMzC+dU0C4K76X1Pmsf+vEc=P7Htg=jJXDPvRHw@mail.gmail.com>
Subject: Re: [PATCH v6 12/16] xen: implement new foreign copy hypercall
To: Jan Beulich <jbeulich@suse.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>, "Daniel P . Smith" <dpsmith@apertussolutions.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-33051d/1785768708-76AF94E9-CBE7C056/0/0
X-purgate-type: clean
X-purgate-size: 8625

On Mon, 29 Jun 2026 at 07:59, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 26.06.2026 16:14, Frediano Ziglio wrote:
> > On Wed, 24 Jun 2026 at 07:44, Jan Beulich <jbeulich@suse.com> wrote:
> >> On 23.06.2026 23:18, Frediano Ziglio wrote:
> >>> On Tue, 23 Jun 2026 at 14:21, Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 23.06.2026 12:55, Frediano Ziglio wrote:
> >>>>> On Mon, 22 Jun 2026 at 11:34, Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>> On 19.06.2026 15:04, Frediano Ziglio wrote:
> >>>>>>> --- a/xen/common/memory.c
> >>>>>>> +++ b/xen/common/memory.c
> >>>>>>> @@ -1545,6 +1545,139 @@ static int acquire_resource(
> >>>>>>>      return rc;
> >>>>>>>  }
> >>>>>>>
> >>>>>>> +/*
> >>>>>>> + * The "noinline" qualifier avoids the compiler to create a large function
> >>>>>>> + * consuming quite a lot of stack.
> >>>>>>> + */
> >>>>>>> +static int noinline mem_foreigncopy(
> >>>>>>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
> >>>>>>> +{
> >>>>>>> +    struct domain *d, *const currd = current->domain;
> >>>>>>> +    xen_foreigncopy_t copy;
> >>>>>>> +    int rc, direction;
> >>>>>>> +
> >>>>>>> +    if ( copy_from_guest(&copy, arg, 1) )
> >>>>>>> +        return -EFAULT;
> >>>>>>> +
> >>>>>>> +    if ( copy.flags & ~XENMEM_foreigncopy_direction )
> >>>>>>> +        return -EINVAL;
> >>>>>>> +
> >>>>>>> +    direction = copy.flags & XENMEM_foreigncopy_direction;
> >>>>>>> +
> >>>>>>> +    rc = rcu_lock_remote_domain_by_id(copy.domid, &d);
> >>>>>>
> >>>>>> Iirc I did ask before why this isn't ..._by_any_id().
> >>>>>
> >>>>> I probably was confused by the question about MMUEXT and the 2 domains.
> >>>>> There are different similar hypercalls (like the mentioned MMUEXT but
> >>>>> also hypercalls to map foreign domain memory) that have this check
> >>>>> (not the same domain). Any domain has, obviously, access to its own
> >>>>> memory, so it should not have to use hypercall to access its own
> >>>>> memory. If it does it looks like a mistake causing performance issues
> >>>>> or an attempt to circumvent security; in either case you would like to
> >>>>> avoid it.
> >>>>
> >>>> No. Self-grants are possible as well, for example, and for a good reason.
> >>>> Allowing normally-remote operations on oneself helps with testing, for
> >>>> example. It may also help avoid needing to special-case "self" in code
> >>>> which needs to cover both cases.
> >>>
> >>> But this is not a grant, it's a copy.
> >>
> >> Sure, but the underlying principle is what matters. Plus you don't prevent
> >> self-copy by using ..._by_id(), you only preclude the use of DOMID_SELF.
> >
> > Sure about this?
>
> No, I'm sorry: I (repeatedly) managed to ignore the "remote" in the function
> called. That said, my request stands: No arbitrary restrictions please. If
> you can properly justify a restriction, that's a different thing.
>

Not strong about it.
I'll change to rcu_lock_domain_by_any_id.

> >>>>>>> +    XEN_GUEST_HANDLE(uint8) buffer;
> >>>>>>> +};
> >>>>>>
> >>>>>> What was (again) left unaddressed is the question towards using GFNs on both
> >>>>>> sides of the copy. This would eliminate the need for the flags field, taken
> >>>>>> by a 2nd domid_t one then.
> >>>>>>
> >>>>>
> >>>>> This was addressed in
> >>>>> https://lists.xenproject.org/archives/html/xen-devel/2026-06/msg00567.html
> >>>>
> >>>> Well, yes, but not in a satisfactory way. Back channels tell me that you
> >>>> actually got the same feedback already on internal review. Which makes it
> >>>> all the more puzzling that you insist on doing it differently. Multiple
> >>>> maintainers asking for the same thing may be an indication of something.
> >>>
> >>> Not needing to have backchannel feedback, I already wrote that a
> >>> similar approach was tried and made the code more complicated.
> >>
> >> Even if indeed so: Yet at the same time more flexible.
> >>
> >>> Both maintainers didn't comment on my replies so I assume they were
> >>> fine with it.
> >>> And you are failing to provide positive feedback.
> >>> I asked (that one internally) for examples of guest buffers provided
> >>> as frame numbers but I got no answer (or better the answer was more
> >>> "currently there are not").
> >>> Also note that the location of xen_foreigncopy_t structure is also
> >>> provided using a guest pointer.
> >>> I remember there were some discussions about ABI changes (2/3 years
> >>> ago) to address this and other issues but I cannot see much progress.
> >>
> >> And it's that (very slowly progressing effort) which made me ask. The
> >> fewer virtual addresses we bake into new sub-ops, the better for that
> >> effort. And no, that doesn't go as far as completely eliminating
> >> handles (presently representing virtual addresses) - that needs to be
> >> part of the new ABI.
> >
> > In other words, you want me to code something temporary that you
> > already know that needs to be changed.
>
> What do you mean by "temporary"? We will need to live with the present
> ABI for the foreseeable future. The new ABI's requirements haven't even
> been spelled out yet. Patches to allow use of physical addresses in
> place of virtual ones were actually turned down on the grounds of there
> not having been a write-down of all requirements.
>

Temporary in the sense that there will be new ABIs to deal with not
using virtual addresses.
The second sentence is a bit contradictory. You want me to address the
virtual address complaint but you are telling me that the change will
be turned down if I don't address everything. And this is why this is
out of scope here.

> >> To preempt the argument towards "fewer virtual addresses" not really
> >> being true when changing from handle-to-uint8 to handle-to-pfn: The
> >> former won't be able to express a buffer mapped contiguously in VA
> >> space, but discontiguous in PA space. The latter will, simply be
> >> avoiding buffer VAs in the first place (the array of frame numbers
> >> can e.g. be placed in a dedicated hypercall argument area known to be
> >> physically contiguous).
> >
> > If it's mapped continuously in VA and you pass the VA I don't
> > understand the problem. From the way I see it's more the latter that's
> > the problem.
>
> I'm talking of the future, where VAs wouldn't be used anymore. The
> buffer you use couldn't be described by a single PA, unless the caller
> took specific measures up front.
>

If you read my reply I suggested a way to avoid virtual addresses completely.

> Jan

About the P2M type check it turned out that I was wrong with the
checking. The MMAP way use MMU_UPDATE calls which do not care about
P2M type at all. Changing the code to

...
        for ( unsigned int i = 0; i < todo; i++ )
        {
            struct page_info *foreign_page;
            mfn_t foreign_mfn;
            void *foreign;
            p2m_type_t p2mt;
            p2m_query_t q = (direction == XENMEM_foreigncopy_to) ?
                            P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;

            foreign_page = get_page_from_gfn(d, gfn_list[i], &p2mt, q);

            if ( unlikely(p2m_is_paged(p2mt)) )
            {
                if ( foreign_page )
                    put_page(foreign_page);
                p2m_mem_paging_populate(d, _gfn(gfn_list[i]));
                p2mt = p2m_ram_paging_in;
                foreign_page = NULL;
            }

            if ( unlikely(!foreign_page) )
            {
                rc = -ENOENT;
                if ( p2mt != p2m_ram_paging_in )
                {
                    gdprintk(XENLOG_WARNING,
                             "Error accessing foreign gfn %" PRI_gfn "\n",
                             gfn_list[i]);
                    rc = -EINVAL;
                }
                copy.nr_frames -= i;
                guest_handle_add_offset(copy.frame_list, i);
                goto out;
            }
...

About the XSM part I have now

...
    /*
     * Check we are allowed to map and access these foreign pages.
     */
    if ( direction == XENMEM_foreigncopy_from )
        rc = xsm_foreigncopy_from(XSM_TARGET, currd, d);
    else
        rc = xsm_foreigncopy_to(XSM_TARGET, currd, d);
    if ( rc )
        goto out;
...

I wrote some code for the compat mode but I need to test it.
Still I think that adding it it's a mistake, it's just a new, probably
unused, ABI that must be maintained till a probable "no virtual
address" ABI will replace it.

Frediano


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 14:52:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 14:52:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381550.1625108 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqu1d-0001mH-M3; Mon, 03 Aug 2026 14:52:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381550.1625108; Mon, 03 Aug 2026 14:52:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqu1d-0001mA-Iw; Mon, 03 Aug 2026 14:52:21 +0000
Received: by outflank-mailman (input) for mailman id 1381550;
 Mon, 03 Aug 2026 14:52:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wqu1c-0001kH-4b
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 14:52:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqu1b-00FD5N-5f
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:52:19 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a70ab1c-bab6-0a2a0a5309dd-0a2a4506e79a-10
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:52:19 +0200
Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a70ab22-195a-0a2a45060019-d155da2fadae-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 16:52:19 +0200
Received: by mail-ej1-f47.google.com with SMTP id
 a640c23a62f3a-c15ba3a2b4bso416268466b.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 07:52:19 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c1fd466271csm594663266b.60.2026.08.03.07.52.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 07:52:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785768738; x=1786373538; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0qKWJoSCqTs9s/h/TtgzhU/DUhBV122CIkFwWPBNBUk=;
        b=LwjccAjQtHAZ8Zh414NvjqxLsqVx6vNReCA+vPZxFgtkIMaMDiK2TSCssTIYfl9qsL
         a/OPYH3M3rO2iVuu66FAbDeU8v93FRK0GQPwatktAshZAESevBzIuYui0I761XiRf/oJ
         rtFu0UfkeNdCFfoXgsR87u1qpx7s2w2kVTEjWEJ9YCwQKNHxn9yUWOBahLPlxv/JqNbW
         8CA37OZrW3x/tz4WOpgRs0PFrzMcTXVN+4r46A/mRdtUKsBL60h/FKfOK0RriEXCutTm
         ac+CbNlpdi3AMGCfoEfkCNe+QDkIFc+ZDrGcid2CvBVB8k8cXw5hItU70uPGBY3OMK4b
         94pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785768738; x=1786373538;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0qKWJoSCqTs9s/h/TtgzhU/DUhBV122CIkFwWPBNBUk=;
        b=tIpPifRccrh56eyICJ0hLPcoJ5T/bEOznNyynB5Jr9KfR2iMUTP63jv2qKB+goJKBw
         CLo+9Gdrs1EwWQtHmYKOp3T6qf0Bgv14+DfEIYBkQ3fpuLOmYTMXjh3MML3YKvfttd7m
         dAjmffDeqroWe1j0Zj/PO/rGTy2SHQRwfDaeooJ5Za6a5U+naWcsi7JKtXK/QDbrUM/z
         gNFEPYVv0ELPMyqSZ+JK/T+JQcKv5wF9wNKHXk9P7zXn7d6EfKh/pK+MPwkZ2H++TSew
         6VLcpnEKjnNR5TayLYFLi4rWKhoYnD2aBSh1LMR3DcuIukYCQT6snsyEKTQVsRxKNEz5
         5n/g==
X-Gm-Message-State: AOJu0YxV5TiGDLqBZmO92M9zpi6vCmGP9HAunSRClFk1mgbBPteCqwFa
	7N9oKbIcvnnzT2SXtO6cnB385vwl1qssF36ca1jloxw/6Pme6iZMZBOW8et3R5LjyBM=
X-Gm-Gg: AR+sD10qb8XRIOQhRmuZY+sGJqfVeaSLEWcBnWbnAKkTr9OIRfZTS/Ta4DjR8KCiDBK
	kHjUEKtmTJcAajKMA8eaIdpIM62eJFr6UqIooLLZ8F0cdXcX3BOhLl61R2+kmvTfE1EtsPTauPz
	KHPEF0AMO2GyBwI9Obqe078cptTMqFbblyW/HvrHEgNzQomify3Xm1qTbT5xlDIQGuVsoGt6ULy
	fvN86J5yBVzpfbbrBhFpgY+/uE+ijcc/wVjoyoTnfpABz5xeZFA0t19ZznT8sDXUZH5MzQ6lbVR
	iPDikeKhvZr8qE6939s/86VpnJ5bZzXHr1V3wp+vihrkTF4Pw7zbtVcyasrFBGHnwdufk+GvUdS
	TAFbORF/7yFZDIHxSGm8J9iaN6nWl3m94wVmFOk/cbbZushyeQg64WPPHqMV2LfYi3irOsanJgU
	c+Qt/vrsymlvFylsF0Ffw5qVucNqTq+yeDx48yDrae0DNCwCx2FNzmXCiTVbgOL1NuOnUCcb1QH
	lIEy4TO7PNpAjCvoMdRs6NI2A1coh0aIAf5hjuO4/LpfxMVTR4aQW2O2jGCPU/J3EJcvRv0PPCt
	on+AvV/y2SAzCaYUenMMH3L0MA==
X-Received: by 2002:a17:907:da15:b0:c15:cac2:1ec4 with SMTP id a640c23a62f3a-c1fe7ecaf45mr867318666b.1.1785768738422;
        Mon, 03 Aug 2026 07:52:18 -0700 (PDT)
Message-ID: <2f1348d8-c175-42e5-9b33-bdca19bde734@suse.com>
Date: Mon, 3 Aug 2026 16:52:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH Linux v6 16/16] xen/privcmd: Add new ABI to allow copying
 foreign memory
To: Frediano Ziglio <freddy77@gmail.com>
Cc: xen-devel@lists.xenproject.org,
 Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich
 <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <20260619130501.272832-1-frediano.ziglio@citrix.com>
 <20260619130501.272832-17-frediano.ziglio@citrix.com>
 <439c2740-fb84-42cb-b001-cb290684a583@suse.com>
 <CAHt6W4dMZtyvMuAfFVG36z53b=a5m6P5gQ4HONGO3WzOBUJ-qw@mail.gmail.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <CAHt6W4dMZtyvMuAfFVG36z53b=a5m6P5gQ4HONGO3WzOBUJ-qw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------pU6AunD4X9CW20zewjSsZ2ob"
X-purgate-ID: tlsNG-16d1c6/1785768739-F7ACA77B-DB8132FD/0/0
X-purgate-type: clean
X-purgate-size: 11849

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------pU6AunD4X9CW20zewjSsZ2ob
Content-Type: multipart/mixed; boundary="------------lQhl9a0UTJFXvMiSh6rfC5yO";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: xen-devel@lists.xenproject.org,
 Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich
 <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>
Message-ID: <2f1348d8-c175-42e5-9b33-bdca19bde734@suse.com>
Subject: Re: [PATCH Linux v6 16/16] xen/privcmd: Add new ABI to allow copying
 foreign memory
References: <20260619130501.272832-1-frediano.ziglio@citrix.com>
 <20260619130501.272832-17-frediano.ziglio@citrix.com>
 <439c2740-fb84-42cb-b001-cb290684a583@suse.com>
 <CAHt6W4dMZtyvMuAfFVG36z53b=a5m6P5gQ4HONGO3WzOBUJ-qw@mail.gmail.com>
In-Reply-To: <CAHt6W4dMZtyvMuAfFVG36z53b=a5m6P5gQ4HONGO3WzOBUJ-qw@mail.gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------lQhl9a0UTJFXvMiSh6rfC5yO
Content-Type: multipart/mixed; boundary="------------I41cUVayIIqMBA0WgqbDouAc"

--------------I41cUVayIIqMBA0WgqbDouAc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDMuMDguMjYgMTY6MjMsIEZyZWRpYW5vIFppZ2xpbyB3cm90ZToNCj4gT24gTW9uLCAz
IEF1ZyAyMDI2IGF0IDE1OjA1LCBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+IHdy
b3RlOg0KPj4NCj4+IE9uIDE5LjA2LjI2IDE1OjA1LCBGcmVkaWFubyBaaWdsaW8gd3JvdGU6
DQo+Pj4gVGhpcyBuZXcgQUJJIGFsbG93cyB0byBjb3B5IGZvcmVpZ24gZG9tYWluIG1lbW9y
eSB0by9mcm9tIGEgYnVmZmVyLg0KPj4+IFRoaXMgYXZvaWRzIGhhdmluZyB0byBtYXAvY29w
eS91bm1hcCBmb3JlaWduIG1lbW9yeSB3aGljaCBpcw0KPj4+IGV4cGVuc2l2ZS4NCj4+PiBU
aGlzIG9wZXJhdGlvbiBpcyBkb25lIHBhcnRpY3VsYXJseSB3aGVuIG1pZ3JhdGluZyBWTXMu
DQo+Pj4NCj4+PiBTaWduZWQtb2ZmLWJ5OiBGcmVkaWFubyBaaWdsaW8gPGZyZWRpYW5vLnpp
Z2xpb0BjaXRyaXguY29tPg0KPj4NCj4+IFdoaWxlIGRvaW5nIGEgdGVzdCBidWlsZCBJIGdv
dCB0aGUgZm9sbG93aW5nIGJ1aWxkIGZhaWx1cmVzIGZvciAzMi1iaXQgYXJtOg0KPj4NCj4+
ICAgICBDQyAgICAgIGFyY2gvYXJtL3hlbi9lbmxpZ2h0ZW4ubw0KPj4gSW4gZmlsZSBpbmNs
dWRlZCBmcm9tIC9ob21lL2dyb3NzL2tvcmcvc3JjL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3hl
bi9pbnRlcmZhY2UuaDoxLA0KPj4gICAgICAgICAgICAgICAgICAgIGZyb20gL2hvbWUvZ3Jv
c3Mva29yZy9zcmMvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hlbi5oOjEzLA0KPj4gICAgICAg
ICAgICAgICAgICAgIGZyb20gL2hvbWUvZ3Jvc3Mva29yZy9zcmMvaW5jbHVkZS94ZW4veGVu
Lmg6NTIsDQo+PiAgICAgICAgICAgICAgICAgICAgZnJvbSAvaG9tZS9ncm9zcy9rb3JnL3Ny
Yy9hcmNoL2FybS94ZW4vZW5saWdodGVuLmM6MjoNCj4+IC9ob21lL2dyb3NzL2tvcmcvc3Jj
L2luY2x1ZGUveGVuL2FybS9pbnRlcmZhY2UuaDoyMjozNTogZXJyb3I6IHVua25vd24gdHlw
ZSBuYW1lDQo+PiAnX19ndWVzdF9oYW5kbGVfdWludDhfdCcNCj4+ICAgICAgMjIgfCAjZGVm
aW5lIEdVRVNUX0hBTkRMRShuYW1lKSAgICAgICAgX19ndWVzdF9oYW5kbGVfICMjIG5hbWUN
Cj4+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXn5+fn5+
fn5+fn5+fn5+DQo+PiAvaG9tZS9ncm9zcy9rb3JnL3NyYy9pbmNsdWRlL3hlbi9pbnRlcmZh
Y2UvbWVtb3J5Lmg6MzYxOjU6IG5vdGU6IGluIGV4cGFuc2lvbiBvZg0KPj4gbWFjcm8gJ0dV
RVNUX0hBTkRMRScNCj4+ICAgICAzNjEgfCAgICAgR1VFU1RfSEFORExFKHVpbnQ4X3QpIGJ1
ZmZlcjsNCj4+ICAgICAgICAgfCAgICAgXn5+fn5+fn5+fn5+DQo+PiBtYWtlWzVdOiAqKiog
Wy9ob21lL2dyb3NzL2tvcmcvc3JjL3NjcmlwdHMvTWFrZWZpbGUuYnVpbGQ6Mjg5Og0KPj4g
YXJjaC9hcm0veGVuL2VubGlnaHRlbi5vXSBFcnJvciAxDQo+PiBtYWtlWzRdOiAqKiogWy9o
b21lL2dyb3NzL2tvcmcvc3JjL3NjcmlwdHMvTWFrZWZpbGUuYnVpbGQ6NTQ5OiBhcmNoL2Fy
bS94ZW5dIEVycm9yIDINCj4+IG1ha2VbM106ICoqKiBbL2hvbWUvZ3Jvc3Mva29yZy9zcmMv
c2NyaXB0cy9NYWtlZmlsZS5idWlsZDo1NDk6IGFyY2gvYXJtXSBFcnJvciAyDQo+Pg0KPj4N
Cj4+IFBsZWFzZSBmaXggdGhvc2UuDQo+Pg0KPj4NCj4+IEp1ZXJnZW4NCj4gDQo+IE11bWJs
ZS4uLg0KPiANCj4gSSBzdXBwb3NlIHRoaXMgd291bGQgZml4IGl0DQo+IA0KPiBkaWZmIC0t
Z2l0IGEvaW5jbHVkZS94ZW4vYXJtL2ludGVyZmFjZS5oIGIvaW5jbHVkZS94ZW4vYXJtL2lu
dGVyZmFjZS5oDQo+IGluZGV4IGMzZWFkYTI2NDJhYS4uN2U3OTg1M2IxODhkIDEwMDY0NA0K
PiAtLS0gYS9pbmNsdWRlL3hlbi9hcm0vaW50ZXJmYWNlLmgNCj4gKysrIGIvaW5jbHVkZS94
ZW4vYXJtL2ludGVyZmFjZS5oDQo+IEBAIC01Myw2ICs1Myw3IEBAIERFRklORV9HVUVTVF9I
QU5ETEUoaW50KTsNCj4gICBERUZJTkVfR1VFU1RfSEFORExFKHZvaWQpOw0KPiAgIERFRklO
RV9HVUVTVF9IQU5ETEUodWludDY0X3QpOw0KPiAgIERFRklORV9HVUVTVF9IQU5ETEUodWlu
dDMyX3QpOw0KPiArREVGSU5FX0dVRVNUX0hBTkRMRSh1aW50OF90KTsNCj4gICBERUZJTkVf
R1VFU1RfSEFORExFKHhlbl9wZm5fdCk7DQo+ICAgREVGSU5FX0dVRVNUX0hBTkRMRSh4ZW5f
dWxvbmdfdCk7DQo+IA0KPiBGcmVkaWFubw0KPiANCg0KQW5kIG5vdyBhbm90aGVyIG9uZToN
Cg0KL2hvbWUvZ3Jvc3Mva29yZy9zcmMvZHJpdmVycy94ZW4vcHJpdmNtZC5jOiBJbiBmdW5j
dGlvbiAncHJpdmNtZF9pb2N0bF9mb3JlaWduY29weSc6DQovaG9tZS9ncm9zcy9rb3JnL3Ny
Yy9kcml2ZXJzL3hlbi9wcml2Y21kLmM6MTU5MToyOTogZXJyb3I6IGluY29tcGF0aWJsZSB0
eXBlcyANCndoZW4gYXNzaWduaW5nIHRvIHR5cGUgJ2NvbnN0IHhlbl9wZm5fdCAqJyB7YWth
ICdjb25zdCBsb25nIGxvbmcgdW5zaWduZWQgaW50IA0KKid9IGZyb20gdHlwZSAnX19ndWVz
dF9oYW5kbGVfeGVuX3Bmbl90Jw0KICAxNTkxIHwgICAgICAgICAgICAgICAgIGNvcHkucGZu
cyA9IHhjb3B5LmZyYW1lX2xpc3Q7DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgXn5+fn4NCi9ob21lL2dyb3NzL2tvcmcvc3JjL2RyaXZlcnMveGVuL3ByaXZjbWQu
YzoxNTkyOjMxOiBlcnJvcjogaW5jb21wYXRpYmxlIHR5cGVzIA0Kd2hlbiBhc3NpZ25pbmcg
dG8gdHlwZSAndm9pZCAqJyBmcm9tIHR5cGUgJ19fZ3Vlc3RfaGFuZGxlX3VpbnQ4X3QnDQog
IDE1OTIgfCAgICAgICAgICAgICAgICAgY29weS5idWZmZXIgPSB4Y29weS5idWZmZXI7DQog
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBefn5+fg0KDQoNCkp1ZXJn
ZW4NCg==
--------------I41cUVayIIqMBA0WgqbDouAc
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------I41cUVayIIqMBA0WgqbDouAc--

--------------lQhl9a0UTJFXvMiSh6rfC5yO--

--------------pU6AunD4X9CW20zewjSsZ2ob
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpwqyEFAwAAAAAACgkQsN6d1ii/Ey+X
awf8DEKzTmCk+s5KRL6C70aTw6kpX+aMhkz2Mlnu1Hy2zzzb9abqos+57esHSIuvUCgJfhpbaKfI
NKkrfLpt63PBmUBUfpO6g2lLqKcpPwBnlyTkmkLM8RkQ4ZO6kcB9iuwMvDuAkgeeJC5eFRPf9PPj
zvkY/9nk1qjjLf/6GUqxspczKK5ti1CS5XtLHYPQwALl2Y4DGTMFggnQaEr41q3OlUvsqs5Pyno8
5d5IEwu9xGRRpmm3VaIV/NTsNdH8eQO3QN/nVMyCUB/R06mq1o3f84Oq2+IlAaUP1rPX+f2LZ3/K
A31Q/nSO0OPhail0y3iE3vvXcH59RnHfvp6DBg2YwA==
=h9ye
-----END PGP SIGNATURE-----

--------------pU6AunD4X9CW20zewjSsZ2ob--


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 15:05:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 15:05:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381571.1625117 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wquEg-0004Xm-Ty; Mon, 03 Aug 2026 15:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381571.1625117; Mon, 03 Aug 2026 15:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wquEg-0004Xf-R0; Mon, 03 Aug 2026 15:05:50 +0000
Received: by outflank-mailman (input) for mailman id 1381571;
 Mon, 03 Aug 2026 15:05:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wquEf-0004XG-9r
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 15:05:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wquEe-00C4tH-58
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 17:05:48 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a70ae3b-bab6-0a2a0a5309dd-0a2a4509e122-22
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:05:48 +0200
Received: from [40.93.196.34]
 (helo=SA9PR02CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a70ae46-be1a-0a2a45090019-285dc4226f70-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:05:43 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by CH2PR03MB5237.namprd03.prod.outlook.com (2603:10b6:610:9c::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.15; Mon, 3 Aug
 2026 15:05:39 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0270.017; Mon, 3 Aug 2026
 15:05:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=E95kQb54/Up4zQNpaK2mkQPBjjPUTJKxWMfkPGvedy5hkuh4ZaEM79QZsq1e0xojCTuHDQuc2+CE1cgSVN914XR4hNvFL3j2NhSj1GqGqdP8Z8PKLP7+zVL5a1m44ba+azxb38Ceei9ITGeDOJh5eixA2muBWOlsz8RxLc+S7WF93BydMtKwZV+4ZTuJgZLV5OTeOkxak9utxnTmJUev9pqFwcMlVna1Zcpr9CZhDIrfw6K6732BZqeJOiFn0WkCXS0LgxrELdEN1kdT7njQxCw+ZsUzk6AWBtuVdXxUu8oOn/1og+fKlLY6jL863SPs1pCFKRLSxdBX9DLRCmjleA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dQhPrpdiWnaSoeNcNnfROBr+QPpTBnQIhAoLCjbz3l4=;
 b=R8Qlc3CZbKbCUWeHtkmzJue6ngci5xUrkSN20Km0BT/1YnQRYUPF8pxM/jfFnLAaYovCgxv4eqd0GbhSuNmRFNIL+I2ARRw0l3Km7p7e7DhQhWCekJfRm5njS/j2fMDCg6/4YSBMU4WzkMUdwLqkFsRhp6BSJQsTXsuwwWVL7EfS+49c7ZmfQoHevwqHKitvLbp/w+TFT9eW96Udfkvjhqd8OxyyMOj6G50PVC+If+XE2jXzjrDpK9KNIbOH1r+MN+YMHqJFthr6Agu6FQFbprBOTS2ghe34czD32SwRQ7WCGS84kDckjMZyxV31yw7sH+bfSAIABiOyWRisoEN7Tg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dQhPrpdiWnaSoeNcNnfROBr+QPpTBnQIhAoLCjbz3l4=;
 b=OgknMIp4lqkzxUxDuwHMe2cJvErdytH8BcEkxsqBrJP7Yj76RSX1Pu1xyurgyGhhMJqJiptWqRsWM5YYme4pSPpT4IEfjJBUOXVYQiHrLTI/iOQch/n5dJZ7DTkn4jutUg56RaTp956XNk9ijr+0KBR3a1pmECPXqdQo1uhqZM4=
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel
	<xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Michal Orzel
	<michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Bertrand Marquis <bertrand.marquis@arm.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v3 2/3] xen/livepatch: Fix include hierarchy
Thread-Topic: [PATCH v3 2/3] xen/livepatch: Fix include hierarchy
Thread-Index: AQHdIQOIBBx6uSDlKEqW+113k5excraMcI6S
Date: Mon, 3 Aug 2026 15:05:38 +0000
Message-ID:
 <CH8PR03MB82743C6A6E8BA056E17D4BC1F0D52@CH8PR03MB8274.namprd03.prod.outlook.com>
References: <20250509163212.2948359-3-andrew.cooper3@citrix.com>
 <20260731154447.436019-1-andrew.cooper3@citrix.com>
In-Reply-To: <20260731154447.436019-1-andrew.cooper3@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH8PR03MB8274:EE_|CH2PR03MB5237:EE_
x-ms-office365-filtering-correlation-id: 5de7c475-6062-4b3a-5f55-08def170aded
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|23010399003|366016|1800799024|38070700021|56012099006|4143699003|10067099003|11063799006|18002099003|22082099003;
x-microsoft-antispam-message-info:
 qXEQmdSh8d1NRfnJEZ3a3PfDWNJ42M/Xjs6z2hiymcLT2PGzzmulK441LqcCBPZXLHkzAXcKgi4i022z7l9DCBV7WPgOKXYTLhFd+GaRkJ2YdKxFIzdxBaga/63v7OEow97pPFFMegha3yXwwVp/YhhuoojCGywuF3c5vU58vEBi1QRvqAiWl2K6sd3Vmb7Wa5F4V1Tn9JswO/hxnkxbGk1gGvGBQIi60NlhOITmb4vVsaSg+XAZiTtVAJuP4gsQ+rlmdtoVkc7wbVOFAtdT8BaxjpdZLRGWcwNCy3hqUUrJy9WcXWSyOgWlIlpFhYpClNVXVB7Se4yaG4lZtSTSDvJ7L4shM5wTbyklas4e21wNd64sPLgHEcJCHf09zq729TRf4/A74Okz6C9ZOJ3XAgR6t3EXutjHV5FXr1FycW0CWpSIRIP7pwuK5sEB4PPbvEbngYyBlq6G9oaw4RXYj2fVPo1t1fY35vlOX9RxQmyWs9bT/wJzv4wuJDEwu9VkYZchxfV3byIJksou+aIGuT9e1TvnqcpWO8OY12bDf+SHr+xWvVe7/U1fmtYApIG8cd/ftCFavpwlEv3fjKdSC60vqtNJTJkP5YyAbKh3mH0WErTsPnYsXZZlSo+8ytxds0zOIrfewYjlc2X5YjdwLTGJms9rWMl4fT0TS8daAsQovwHk+nkpXhZdc16lzR7Pg2Y+vCnbSDN/tamGqfFzMTT50P2dfNPmuFm9I6a0Cmw=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(23010399003)(366016)(1800799024)(38070700021)(56012099006)(4143699003)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?ADouJoRp4rHWRrRdvY6mwBF3NQqcDvds3/9lMmltsL+03BGLsFtlgeEuyT?=
 =?iso-8859-1?Q?hRO4NVwuUOQ3HweveH2ELcOWIQdfJB7++Vv/mIXmy3D8Wfl7Df8r/fGfU+?=
 =?iso-8859-1?Q?L4MKaNk36DR7R9FK4NeCLGhpO13iY0V/Q7F1sjQhFthCt9tXgyNlc+Oe4B?=
 =?iso-8859-1?Q?m+EDri7iwo/WhqxcjNYYQlVqTfnQ7ni+iOQw0CED40wbGmbl3Wfuri9UCy?=
 =?iso-8859-1?Q?kunlp4wuTWFSgLES7qaSeITVDfjuzgglVx7zWJUcD/4yaY1Z3ZWdIEYZKH?=
 =?iso-8859-1?Q?IXFHcVgq8dpzCtD4CC1PUQ8NolzoDoSdnKZnfc2trcyyFvVFCyUzuEfzNu?=
 =?iso-8859-1?Q?Kfj2WTNgkmyV09v8A0S4JIUpNySSBp8zsJJ7nsV6/wsMtEgsNWwYMxp5uB?=
 =?iso-8859-1?Q?hu5MVVlHvAb8DwvHNyDuR+YLRa8SVAX65f+0r5Zplmt71jmGpqQstRDtjB?=
 =?iso-8859-1?Q?7RQb6uYG75Nan1Py/98EhXXb/cAZbxz0uTlHC4Oz8y8AzN/4eR6zZeAxGY?=
 =?iso-8859-1?Q?6wq97bG0n2XKqy/tmencgoWOWaGUZlDauGV+wZsf9yXFMPIn/MlXQYpmyh?=
 =?iso-8859-1?Q?xzqFMWnmCGLt8q5fjdpxj8lmcEXSl67dJso9+OO2V2kB/CkCXhfIBSJJug?=
 =?iso-8859-1?Q?fQXgJoe8fhZekHV6XtzkGO35XlEFR7Fnr3YAe6LUdvP/FK/tSYgE2JFY6b?=
 =?iso-8859-1?Q?fNHpo7P122r6TshYCTT3/4ITNvG+WcqYqwpJrisO6AJfdEKxS0KDcBt0+f?=
 =?iso-8859-1?Q?klnTH5a9Ghwzdt6jDXm5hRF8a1awifTW3ZYOmh0h5itzFBO0c/8XDHLpMQ?=
 =?iso-8859-1?Q?jj57/Z8PlNhAyrgAbOSpjBr0IE9ci2hIExKYBE+XEzb5BIKGw6Wtguqrem?=
 =?iso-8859-1?Q?8CL7M5iGzg++BdWyEiROaIIannFnmMGVHLChEctQmRevwW8zHttsWaDzxo?=
 =?iso-8859-1?Q?eTpI0snQhT/fcrPhkpYRnecjxQRoiUUwb3St/twthn+4VePa4QbHUPoyGY?=
 =?iso-8859-1?Q?os0WyYri8Wn9hRQhFVBpYpKamX+KaHSJ3oFfa/PhmersF/iVIUm+9cyCYh?=
 =?iso-8859-1?Q?Iudnr3FpHOhhg8kU11X1+bPpyjWOp1Dq/IxGNU/1Ao9SEC+POCK7juZ+4+?=
 =?iso-8859-1?Q?AQYS9DpfRdxPgJvXFgWjUWDZrn0Jsv8V+woNCrGst2Ybq41tAqfvRe5qWU?=
 =?iso-8859-1?Q?ORCxev2GiAIz5fPQ3CfImSTDXxO5C9LwTGOlVTE5CVcKVlqdW9iPqnRD+4?=
 =?iso-8859-1?Q?d06il8Cg00KN91v02kLnYG4BMIvKXWF0aTnRS8A1bRPoJ9krfySs0t5dsu?=
 =?iso-8859-1?Q?ESag7/Rx1MCKEMu1WqgNnt0BSRJrquWOjRYSBHSHls66nasVPmLrYCtA+i?=
 =?iso-8859-1?Q?fNswKPzgp0NjJhYgNYtNGhPgejyx5LeyPeKk3wd8R3HN1WvAweci+/vQ2V?=
 =?iso-8859-1?Q?bKlm0qslnQEafCM1GzVIpf2jBoyJoQ4BZ0Qn32s//NczCP8+9WDpl7yXFF?=
 =?iso-8859-1?Q?XdYPYMsF6jO4S4VLZc4NyZN30pUMIf79pzw3dYi4z/l/gfQEG2HvYXOxKr?=
 =?iso-8859-1?Q?sD/BLZ0V9NLiXh6YyaGHRnyttxxP08VI5IjTpyR5nSbKeQpAjEJ1baDWio?=
 =?iso-8859-1?Q?J9PJdT2vsgoaffgWK4k0kQ4kWOSRc8bBHkQeXECzCoFnhDMjXG9w2a9F1F?=
 =?iso-8859-1?Q?+M66UlVmRSH0IYsDqBtp7GgtBlFYise0S+qUIiyfPEh3BtRyq0a8NNtnUK?=
 =?iso-8859-1?Q?5PZx470mU2fhS4zixlFMMXDtBZkaWtlAmGsb/P2OGbyGJiSCBOVL2wDf2q?=
 =?iso-8859-1?Q?i/etsI5+hQ=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5de7c475-6062-4b3a-5f55-08def170aded
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2026 15:05:38.9750
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rgO7HR7Lx9DwX9eRF35xCNin+Pc3FYVmQC3lpd7f2EwsW9npgwtddVUFoMUQcZBM/4ZyepAl73wwkf3cvEdTZ9tlDB7bOxaQWpSnxCzm9kY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5237
X-purgate-ID: tlsNG-bad1c0/1785769544-39AC0034-D83E6303/0/0
X-purgate-type: clean
X-purgate-size: 808

> From: Andrew Cooper <andrew.cooper3@citrix.com>=0A=
> Sent: Friday, July 31, 2026 4:44 PM=0A=
> To: Xen-devel=0A=
> Cc: Andrew Cooper; Anthony PERARD; Michal Orzel; Jan Beulich; Julien Gral=
l; Roger Pau Monn=E9; Stefano Stabellini; Volodymyr Babchuk; Bertrand Marqu=
is; Oleksii Kurochko; Ross Lagerwall=0A=
> Subject: [PATCH v3 2/3] xen/livepatch: Fix include hierarchy=0A=
> =0A=
> xen/livepatch.h includes public/sysctl.h twice, which can be deduplicated=
, and=0A=
> includes asm/livepatch.h meaning that each livepatch.c does not need to=
=0A=
> include both.=0A=
> =0A=
> Comment the #else and #endif cases to aid legibility.=0A=
> =0A=
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>=0A=
=0A=
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>=0A=
=0A=
Thanks=


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 15:09:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 15:09:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381578.1625127 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wquII-0005mS-Db; Mon, 03 Aug 2026 15:09:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381578.1625127; Mon, 03 Aug 2026 15:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wquII-0005mL-AP; Mon, 03 Aug 2026 15:09:34 +0000
Received: by outflank-mailman (input) for mailman id 1381578;
 Mon, 03 Aug 2026 15:09:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wquIG-0005mF-Rz
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 15:09:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wquIG-00FGFk-8j
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 17:09:32 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a70af1d-2eae-0a2a0a5409dd-0a2a450ab052-46
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:09:32 +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 <andrew.cooper3@citrix.com>)
 id 6a70af2b-f2d2-0a2a450a0019-d155802dc807-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:09:32 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4956869750eso14065385e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 08:09:31 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49808199a5csm338284985e9.4.2026.08.03.08.09.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 08:09:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785769771; x=1786374571; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7+c+qq8EM5bi4ZLYwjWJgiPT8GJ9IUzuXDiF/Sbo//g=;
        b=Yj8X+y/hJOoaEuHg6yKICKLzdp67EgMAbtwYvddARVOoG44yPx1r0W+H72rKZo9E4W
         IcwPO2wxeUKfx/MM+FaA+aDPeMeyamvWu64A9nrMwYBNjI7E3A0eOPsY5nJi1vorG2A1
         7Ib7Nu3FJ1Hj6UTMWN/rFZvRPU7nKcf0ZUhwA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785769771; x=1786374571;
        h=content-transfer-encoding:content-type:mime-version: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=7+c+qq8EM5bi4ZLYwjWJgiPT8GJ9IUzuXDiF/Sbo//g=;
        b=YaILgg3WJlQRFC97R3g/BZMqnVNt1uUFqVHvP4D+4L93X+pNQUdBSKsiucKcvjHypl
         IV+li88wvDKqWlqFhMr1zOjSqYIBpd2tSQGoS5K34CYz6ftUI8bXu+lw8c2A/oFaxLZ0
         PbQexOREDH9Swiqc8Si7RTXBHmhaDMa/r+GyRewW3seMfK2Pjxf0RLkEKaaNx4ycB3Kp
         k5gljyJ+xkfBw41YkyBJsvHMvpUS7OInoniLe/tH91Zy2aR6IbFi1cUW0pphVngh1mow
         Tvbuof9qZbSYS0dkeijfoZpyYnb9oqqXdaGme/M7fQy+U/JBlnHrwHIXA5/IG5n4TXG6
         CyPA==
X-Gm-Message-State: AOJu0YyE/4KmoynY3o695fCtfj+pmu/558trPWAG/c4VVAeGrxhxtOUF
	zOr6tVd+hIqaMqVscIJ/gkFizMkhVxSX4TYfUq9CY6TnjqaDj4sUWVsE/azJRacSuJ3tH6BMnk+
	3aVBOvls=
X-Gm-Gg: AR+sD10LsyvWXxGM/IdzgaMY6y580pCyc1GO9uiX1FyYdAzpJwwo7bkHnqdFjJsNMB5
	OtAUNQeWD8eZ374zx0SDAa6YHvIInMOQJKJajcKnZSCUHz6iVrnY01cuC5yV8zr3Oh15eWUQhM1
	+HCt7Mcj6pWtfhWKTgVjjvjn9K9pDdUygPSWhh/iarAQwqiZCJl5P+M3qKjfvvkfzWAHzFOOosY
	q6jqbNAsIZb4htP21xcKKRS865YZOqG6USr4q8ZwkYQDjkq8cDN0v3LYk+3YLGtG6AJK4Uyihig
	HWTqtNRCHuteB8VsOzeXs31Wr3iKB8rnI0afyHt9gIaqViXDZX6BBtA679+ISkMNWEc7DDhPUDG
	bq2gOdYuAEPeYZZNDznQ5prtI3M3lDLbOyQLNh0xNTehHUo33Dihw89WO6Hd94WjOBIWI9v4o5E
	mAkj773q3CbCkvIqzBtwxROmnctVVaF1M9pgqV15i1K96VR5IXMDaZH3s//2wIZk8je3Da52ytb
	WavgYvwNGf34kemFKkdCNIDw0HU9Yu5ZYqui3GMyxQa/ooZcg==
X-Received: by 2002:a05:600c:628d:b0:490:e5c1:b8bf with SMTP id 5b1f17b1804b1-4980c64e4c8mr248831955e9.13.1785769771272;
        Mon, 03 Aug 2026 08:09:31 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: [PATCH] xen/livepatch: Move init_or_livepatch_* into xen/init.h
Date: Mon,  3 Aug 2026 16:09:25 +0100
Message-Id: <20260803150925.408857-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785769772-532D8CFC-79776C13/10/73395122804
X-purgate-type: spam
X-purgate-size: 5701

xen/livepatch.h is a fairly heavyweight header pulling in public/sysctl.h, and
a reasonable number of users care only for the init_or_livepatch_* tags only.

They're arguably more init than livepatch anyway, and by moving them to
init.h, we can remove a number of includes.

The include in vsprintf was leftover from early versions of the work.  In the
version committed, d5ccf4482e4f ("x86, xsplice: Print payload's symbol name
and payload name in backtraces"), symbol_lookup() had been adjusted to handle
the livepatch symbol names properly.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Ross Lagerwall <ross.lagerwall@citrix.com>
---
 xen/arch/riscv/extable.c    |  1 -
 xen/arch/x86/alternative.c  |  1 -
 xen/arch/x86/extable.c      |  1 -
 xen/arch/x86/mm.c           |  1 -
 xen/common/vsprintf.c       |  1 -
 xen/include/xen/init.h      | 19 +++++++++++++++++++
 xen/include/xen/livepatch.h | 21 ---------------------
 7 files changed, 19 insertions(+), 26 deletions(-)

diff --git a/xen/arch/riscv/extable.c b/xen/arch/riscv/extable.c
index 77e5e9e89439..5b89c4278c65 100644
--- a/xen/arch/riscv/extable.c
+++ b/xen/arch/riscv/extable.c
@@ -3,7 +3,6 @@
 #include <xen/init.h>
 #include <xen/bsearch.h>
 #include <xen/lib.h>
-#include <xen/livepatch.h>
 #include <xen/sort.h>
 #include <xen/virtual_region.h>
 
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 5ed0c2672589..4c09dc55c684 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -16,7 +16,6 @@
 #include <asm/traps.h>
 #include <asm/nmi.h>
 #include <asm/nops.h>
-#include <xen/livepatch.h>
 
 #define MAX_PATCH_LEN (255-1)
 
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index e1c8c9fab811..1425ea176570 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -2,7 +2,6 @@
 #include <xen/domain_page.h>
 #include <xen/init.h>
 #include <xen/list.h>
-#include <xen/livepatch.h>
 #include <xen/perfc.h>
 #include <xen/rcupdate.h>
 #include <xen/sort.h>
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 511de4cc38a8..b158742408f9 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -101,7 +101,6 @@
 #include <xen/irq.h>
 #include <xen/kernel.h>
 #include <xen/lib.h>
-#include <xen/livepatch.h>
 #include <xen/mm.h>
 #include <xen/param.h>
 #include <xen/perfc.h>
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 612751c90f43..90192fd9e8b9 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -20,7 +20,6 @@
 #include <xen/symbols.h>
 #include <xen/lib.h>
 #include <xen/sched.h>
-#include <xen/livepatch.h>
 #include <asm/div64.h>
 #include <asm/page.h>
 
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index 0c921672c196..2e5bea2bff93 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -19,6 +19,25 @@
 #define __initdata_cf_clobber  __section(".init.data.cf_clobber")
 #define __initconst_cf_clobber __section(".init.rodata.cf_clobber")
 
+/*
+ * Various pieces of functionality are needed at runtime only if livepatching
+ * is enabled.  Provide tags which resolve to the appropriate section
+ * annotation in either configuration.
+ */
+#ifdef CONFIG_LIVEPATCH
+# define init_or_livepatch_const
+# define init_or_livepatch_constrel
+# define init_or_livepatch_data
+# define init_or_livepatch_read_mostly __read_mostly
+# define init_or_livepatch
+#else /* !CONFIG_LIVEPATCH */
+# define init_or_livepatch_const       __initconst
+# define init_or_livepatch_constrel    __initconstrel
+# define init_or_livepatch_data        __initdata
+# define init_or_livepatch_read_mostly __initdata
+# define init_or_livepatch             __init
+#endif /* !CONFIG_LIVEPATCH */
+
 /* These macros are used to mark some functions or 
  * initialized data (doesn't apply to uninitialized data)
  * as `initialization' functions. The kernel can take this
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 45c8924f3412..416eecb70045 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -20,17 +20,6 @@ struct xen_sysctl_livepatch_op;
 
 #include <xen/lib.h>
 
-/*
- * We use alternative and exception table code - which by default are __init
- * only, however we need them during runtime. These macros allows us to build
- * the image with these functions built-in. (See the #else below).
- */
-#define init_or_livepatch_const
-#define init_or_livepatch_constrel
-#define init_or_livepatch_data
-#define init_or_livepatch_read_mostly __read_mostly
-#define init_or_livepatch
-
 /* Convenience define for printk. */
 #define LIVEPATCH             "livepatch: "
 /* ELF payload special section names. */
@@ -145,16 +134,6 @@ void revert_payload_tail(struct payload *data);
 
 #else
 
-/*
- * If not compiling with Live Patch certain functionality should stay as
- * __init.
- */
-#define init_or_livepatch_const       __initconst
-#define init_or_livepatch_constrel    __initconstrel
-#define init_or_livepatch_data        __initdata
-#define init_or_livepatch_read_mostly __initdata
-#define init_or_livepatch             __init
-
 static inline int livepatch_op(struct xen_sysctl_livepatch_op *op)
 {
     return -ENOSYS;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 15:26:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 15:26:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381608.1625140 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wquZ0-0000wy-SA; Mon, 03 Aug 2026 15:26:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381608.1625140; Mon, 03 Aug 2026 15:26:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wquZ0-0000wr-P9; Mon, 03 Aug 2026 15:26:50 +0000
Received: by outflank-mailman (input) for mailman id 1381608;
 Mon, 03 Aug 2026 15:26:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wquYz-0000wV-Q2
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 15:26:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wquYz-00C8Z0-6b
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 17:26:49 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70b325-5cb7-0a2a0a5109dd-0a2a450b990c-18
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:26:49 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70b334-b7e8-0a2a450b0019-d155dd29dc98-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:26:44 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47f92e3c14bso2492538f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 08:26:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd41e2484sm35099096f8f.11.2026.08.03.08.26.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 08:26:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785770804; x=1786375604; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=mmwVO0GCSPE8S03FffRhOAtiOUMzJODrygXLq0JIkfA=;
        b=IDR/rD/DpKn7sHMysRmuOz1IL35d6BM1/tYTxgxC4ubpAn+6diYiV/F1FXZaaSJmlp
         KmqH5QwOfkVJwXEUpjb5fLlzBCUlrb0XPQJCyYK/rW3LEAFEhXvrj5dXswTn2mIjKMLq
         cceeliPG92uENlJNphnY7JGXvNQQ0JLQ3JpEm0x0BE4saIpOaQoptDp+NS6FBukEhNDJ
         tpD7N4sKcOsDoOpiQa+8LU38zSL1CRjnSfFRR/lAfrkeRGDxQXcgQ1zYBPHtrrZa0Qnh
         Y/HtC62i7BWb4iR1OmZrw/7scPjpUV7c9BHNxCWYr/rcdXjJoPWhjhXNwK14E4g3MR01
         RFEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785770804; x=1786375604;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=mmwVO0GCSPE8S03FffRhOAtiOUMzJODrygXLq0JIkfA=;
        b=q6EX9ZwuqBDI08yjtd+eGn1gA5sAO1tw+IdN+IAQxElDNgF3OROhs3jDOONzRWMeoy
         vxat+7OAaX5DoYzis3Ntoc1p9aVMQq1M3XGSxSgseTQPpItCibz9YmR+xM3FVnnFdXVl
         71H1cNJaIHG/D2/asDgDVFr4ZK3BCqqfm4VoqSHh5rm6QsvWnDlQNtxSP4sH9KEUvlhP
         lcv97pWFK6PKWM/dWxwfWy9+/I34vu72vAoGHPgNHKXfFGMI+fp0uTqzJ24yaDB1yE5Q
         E1g8JTXqhPaUxr/a7fHORngiNwdPNq2y6skfw4LJtwhIjZt77A9pSzelUAPscaP+Dziy
         5VPQ==
X-Forwarded-Encrypted: i=1; AHgh+Ro3poHwx76+vI8eXQaVJvr/Uu1EJnL3pipfg4rD82HqISdgEyVX/ZzKl5mukBoR1TLc9MXPvtENpLY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwCo5njVOjMKcBSkiAk4KY7mXyKNSQO4fQjBq2pVkEUTR60+LOc
	xc6rAivQaPvCBeglh7x2XLyz9NKnp8xrtRowrmv8jamEHX11GxclA/lNkLpxbVINDw==
X-Gm-Gg: AR+sD11zlCpvalFNLhF8OrFIoGAnimO9FkWIYFZ4vG/nu9PW95c63aFk2m1RlfIAaZn
	W7l5STuGxTyh6qRt+q5ZPaDt6ptxhjtwMpwzeTojiux81HHRJVMhksa0AEhUiLkIddjLD0q+6iX
	K9GbpXlSAqUo5s0H6EsZyI2o6/Sdf9K5L6tRMoC25xo7MA2WTCeN7Adib+nW3itJ0DCDaBR1ms0
	3VjhkX9F0gcbDcGfqGB3rOdAnYY/9XWDbZjUEYOQqRouS6YV++yZwp8uJPm3sdc7T10AAnF1kls
	/LSbRwLPNyusDJjL2O9WtzZHqBL60uW9t7YYCQXcwxxDW9u8aDARNm7UWiQDYnuLd2cM/PIhioY
	98brod6B1Q66QnGz9kGoIHRX/BeidZZ61FZ3RGG2jqO5od8u9NSyDAGKW9M8grUau2waXLco5F/
	UXqduwpLHLzYSJisOwi9LWFCNzCi+WChoQLeOYMx0Vbdn+6w41wO69i3D18ezfw8GbmM1Dab8f1
	/ge7MdlDq/eNir1wJseSjZAt4AZblenY/V1wcaER8upi1jPAzMv
X-Received: by 2002:a05:6000:3102:b0:47f:5a97:2a63 with SMTP id ffacd0b85a97d-47fd729fce9mr29683590f8f.9.1785770803801;
        Mon, 03 Aug 2026 08:26:43 -0700 (PDT)
Message-ID: <01b27228-fdc0-4546-aa23-2bcdafb22727@suse.com>
Date: Mon, 3 Aug 2026 17:26:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/5] x86/emul: Introduce x86_decode_lite()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260803072006.9678-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1785770804-1A8D99EA-4B094D6B/0/0
X-purgate-type: clean
X-purgate-size: 12314

> --- /dev/null
> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
> @@ -0,0 +1,330 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifdef __XEN__
> +# include <xen/init.h>
> +# include <xen/livepatch.h>
> +#endif
> +
> +#include "private.h"
> +
> +#undef ModRM
> +
> +/*
> + * Bare minimum x86 instruction decoder to parse the alternative replacement
> + * instructions and locate the IP-relative references that may need updating.
> + *
> + * These are:
> + *  - disp8/32 from near direct branches
> + *  - RIP-relative memory references
> + *
> + * The following simplifications are used:
> + *  - All code is 64bit, the instruction stream is well formed and safe to
> + *    read.
> + *  - Instruction groups and prefixes not used by Xen's current alternatives
> + *    are not implemented in order to reduce the decode complexity.
> + *  - Certain instructions are intentionally not recognised, when it is more
> + *    likely for their presence to be an error than intentional.
> + *
> + * Inputs:
> + *  @ip  The position to start decoding from.
> + *  @end End of the replacement block.  Exceeding this is considered an error.

Why do you mention replacement blocks here? Are we entirely set on this
code not possibly gaining any purpose beyond the scanning of those?

> + * Returns: x86_decode_lite_t
> + *  - On failure, length of 0.
> + *  - On success, length > 0.  For rel_sz > 0, rel points at the relative
> + *    field in the instruction stream.
> + */
> +x86_decode_lite_t init_or_livepatch x86_decode_lite(void *ip, void *end)

Is there a reason the parameters can't be pointer-to-const? Hmm,
apparently for x86_decode_lite_t's "rel" field not be plaing void *, "ip"
needs to be this way as well. But not "end", I don't think.

> +{
> +#define Imm8   (1 << 0)
> +#define Imm    (1 << 1)
> +#define Moffs  (1 << 2)
> +#define Branch (1 << 5) /* Near direct branches, which have a displacement */
> +#define ModRM  (1 << 6)
> +#define Known  (1 << 7)
> +
> +    static const uint8_t init_or_livepatch_const onebyte[256] = {
> +
> +#define ALU_OPS(x)                              \
> +        [(x) + 0] = (Known|ModRM),              \
> +        [(x) + 1] = (Known|ModRM),              \
> +        [(x) + 2] = (Known|ModRM),              \
> +        [(x) + 3] = (Known|ModRM),              \
> +        [(x) + 4] = (Known|Imm8),               \
> +        [(x) + 5] = (Known|Imm)
> +
> +        ALU_OPS(0x00) /* ADD */, ALU_OPS(0x08) /* OR  */,
> +        ALU_OPS(0x10) /* ADC */, ALU_OPS(0x18) /* SBB */,
> +        ALU_OPS(0x20) /* AND */, ALU_OPS(0x28) /* SUB */,
> +        ALU_OPS(0x30) /* XOR */, ALU_OPS(0x38) /* CMP */,
> +
> +#undef ALU_OPS
> +
> +        [0x50 ... 0x5f] = (Known),             /* PUSH/POP %reg */
> +
> +        [0x62]          = 0,                   /* BOUND, but also EVEX prefix, not implemented. */
> +        [0x63]          = (Known|ModRM),       /* MOVSxd */
> +
> +        [0x68]          = (Known|Imm),         /* PUSH $imm */
> +        [0x69]          = (Known|ModRM|Imm),   /* IMUL $imm */
> +        [0x6a]          = (Known|Imm8),        /* PUSH $imm8 */
> +        [0x6b]          = (Known|ModRM|Imm8),  /* PUSH $imm8 */
> +        [0x6c ... 0x6f] = (Known),             /* INS/OUTS */
> +        [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */
> +        [0x80]          = (Known|ModRM|Imm8),  /* Grp1 */
> +        [0x81]          = (Known|ModRM|Imm),   /* Grp1 */
> +
> +        [0x83]          = (Known|ModRM|Imm8),  /* Grp1 */
> +        [0x84 ... 0x8e] = (Known|ModRM),       /* TEST/XCHG/MOV/MOV-SREG/LEA */
> +        [0x8f]          = 0,                   /* Grp1A - POP but also XOP prefix, not implemented. */

POP doesn't look all that unlikely to be used in inline assembly, and
hence in alternatives. That said, of course using it with a memory
operand requires quite a bit of care. I don't see you excluding the
PUSH counterpart, though - being consistent for any such pairs would
seem somewhat desirable.

> +        [0x90 ... 0x99] = (Known),             /* NOP/XCHG %rAX/CLTQ/CQTO */
> +
> +        [0x9b ... 0x9f] = (Known),             /* FWAIT/PUSHF/POPF/SAHF/LAHF */
> +        [0xa0 ... 0xa3] = (Known|Moffs),       /* MOVABS */
> +        [0xa4 ... 0xa7] = (Known),             /* MOVS/CMPS */
> +        [0xa8]          = (Known|Imm8),        /* TEST %al */
> +        [0xa9]          = (Known|Imm),         /* TEST %rAX */
> +        [0xaa ... 0xaf] = (Known),             /* STOS/LODS/SCAS */
> +        [0xb0 ... 0xb7] = (Known|Imm8),        /* MOV $imm8, %reg */
> +        [0xb8 ... 0xbf] = (Known|Imm),         /* MOV $imm{16,32,64}, %reg */
> +        [0xc0 ... 0xc1] = (Known|ModRM|Imm8),  /* Grp2 (ROL..SAR $imm8, %reg) */
> +
> +        [0xc3]          = (Known),             /* RET */
> +        [0xc4 ... 0xc5] = 0,                   /* LES/LDS but also VEX prefixes, not implemented. */

This may bite us sooner or later, due to the VEX-encoded integer insns
that there are. Of course as long as we don't use this function on
compiled code, and as long as my "x86: allow Kconfig control over psABI
level" doesn't come close to going in, that's merely a theoretical
concern.

Same goes for not supporting the 3-byte opcodes, which also encode
certain integer insns.

> +        [0xc6]          = (Known|ModRM|Imm8),  /* Grp11, Further ModRM decode */
> +        [0xc7]          = (Known|ModRM|Imm),   /* Grp11, Further ModRM decode */
> +
> +        [0xcb ... 0xcc] = (Known),             /* LRET/INT3 */
> +        [0xcd]          = (Known|Imm8),        /* INT $imm8 */
> +
> +        [0xd0 ... 0xd3] = (Known|ModRM),       /* Grp2 (ROL..SAR {$1,%cl}, %reg) */
> +
> +        [0xd6]          = (Known),             /* UDB */

I guess you consider XLAT, LOOP*, and J*CXZ as too odd to use in alternatives?
Decoding-wise they're rather easy to implement.

> +        [0xe4 ... 0xe7] = (Known|Imm8),        /* IN/OUT $imm8 */
> +        [0xe8 ... 0xe9] = (Known|Branch|Imm),  /* CALL/JMP disp32 */
> +
> +        [0xeb]          = (Known|Branch|Imm8), /* JMP disp8 */
> +        [0xec ... 0xef] = (Known),             /* IN/OUT %dx */
> +
> +        [0xf1]          = (Known),             /* ICEBP */
> +
> +        [0xf4]          = (Known),             /* HLT */
> +        [0xf5]          = (Known),             /* CMC */
> +        [0xf6 ... 0xf7] = (Known|ModRM),       /* Grp3, Further ModRM decode */
> +        [0xf8 ... 0xfd] = (Known),             /* CLC ... STD */
> +        [0xfe ... 0xff] = (Known|ModRM),       /* Grp4 */
> +    };
> +    static const uint8_t init_or_livepatch_const twobyte[256] = {
> +        [0x00 ... 0x03] = (Known|ModRM),       /* Grp6/Grp7/LAR/LSL */

Leaving out INVD is surely find, but WBINVD?

> +        [0x0b]          = (Known),             /* UD2 */
> +
> +        [0x18 ... 0x1f] = (Known|ModRM),       /* Grp16 (Hint Nop) */
> +        [0x20 ... 0x23] = (Known|ModRM),       /* MOV %cr/%dr */
> +
> +        [0x30 ... 0x33] = (Known),             /* WRMSR/RDTSC/RDMSR/RDPMC */
> +
> +        [0x40 ... 0x4f] = (Known|ModRM),       /* CMOVcc */
> +
> +        [0x80 ... 0x8f] = (Known|Branch|Imm),  /* Jcc disp32 */
> +        [0x90 ... 0x9f] = (Known|ModRM),       /* SETcc */
> +
> +        [0xa0 ... 0xa2] = (Known),             /* PUSH/POP %fs/CPUID */
> +        [0xa3]          = (Known|ModRM),       /* BT */
> +        [0xa4]          = (Known|ModRM|Imm8),  /* SHLD $imm8 */
> +        [0xa5]          = (Known|ModRM),       /* SHLD %cl */
> +
> +        [0xa8 ... 0xa9] = (Known),             /* PUSH/POP %gs */
> +
> +        [0xab]          = (Known|ModRM),       /* BTS */
> +        [0xac]          = (Known|ModRM|Imm8),  /* SHRD $imm8 */
> +        [0xad ... 0xaf] = (Known|ModRM),       /* SHRD %cl/Grp15/IMUL */
> +
> +        [0xb0 ... 0xb9] = (Known|ModRM),       /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */
> +        [0xba]          = (Known|ModRM|Imm8),  /* Grp8 */
> +        [0xbb ... 0xbf] = (Known|ModRM),       /* BTC/BSF/BSR/MOVSX */
> +        [0xc0 ... 0xc1] = (Known|ModRM),       /* XADD */

What about MOVNTI?

> +        [0xc7]          = (Known|ModRM),       /* Grp9 */
> +        [0xc8 ... 0xcf] = (Known),             /* BSWAP */
> +    };

What about UD0?

> +    void *start = ip, *rel = NULL;
> +    unsigned int opc, rel_sz = 0;
> +    uint8_t b, d, rex = 0, osize = 4;
> +
> +#define OPC_TWOBYTE (1 << 8)
> +
> +    /* Mutates IP, uses END. */
> +#define FETCH(ty)                                       \
> +    ({                                                  \
> +        ty _val;                                        \
> +                                                        \
> +        if ( (ip + sizeof(ty)) > end )                  \
> +            goto overrun;                               \
> +        _val = *(ty *)ip;                               \
> +        ip += sizeof(ty);                               \
> +        _val;                                           \
> +    })
> +
> +    for ( ;; ) /* Prefixes */
> +    {
> +        switch ( b = FETCH(uint8_t) )
> +        {
> +        case 0x26: /* ES override */
> +        case 0x2e: /* CS override */
> +        case 0x36: /* DS override */
> +        case 0x3e: /* SS override */
> +        case 0x64: /* FS override */
> +        case 0x65: /* GS override */
> +        case 0xf0: /* LOCK */
> +        case 0xf2: /* REPNE */
> +        case 0xf3: /* REP */
> +            break;
> +
> +        case 0x66: /* Operand size override */
> +            osize = 2;
> +            break;
> +
> +        /* case 0x67: Address size override, not implemented */
> +
> +        case 0x40 ... 0x4f: /* REX */
> +            rex = b;
> +            continue;
> +
> +        default:
> +            goto prefixes_done;
> +        }
> +        rex = 0; /* REX cancelled by subsequent legacy prefix. */
> +    }
> + prefixes_done:
> +
> +    if ( rex & REX_W )
> +        osize = 8;
> +
> +    /* Fetch the main opcode byte(s) */
> +    if ( b == 0x0f )
> +    {
> +        b = FETCH(uint8_t);
> +        opc = OPC_TWOBYTE | b;
> +
> +        d = twobyte[b];
> +    }
> +    else
> +    {
> +        opc = b;
> +        d = onebyte[b];
> +    }
> +
> +    if ( unlikely(!(d & Known)) )
> +        goto unknown;
> +
> +    if ( d & ModRM )
> +    {
> +        uint8_t modrm = FETCH(uint8_t);
> +        uint8_t mod = modrm >> 6;
> +        uint8_t reg = (modrm >> 3) & 7;
> +        uint8_t rm = modrm & 7;
> +
> +        /* ModRM/SIB decode */
> +        if ( mod == 0 && rm == 5 ) /* RIP relative */
> +        {
> +            rel = ip;
> +            rel_sz = 4;
> +            FETCH(int32_t);

FETCH() here but ...

> +        }
> +        else if ( mod != 3 && rm == 4 ) /* SIB */
> +        {
> +            uint8_t sib = FETCH(uint8_t);
> +            uint8_t base = sib & 7;
> +
> +            if ( mod == 0 && base == 5 )
> +                goto disp32;

... goto here?

> +        }
> +
> +        if ( mod == 1 ) /* disp8 */
> +            FETCH(int8_t);
> +        else if ( mod == 2 ) /* disp32 */
> +        {
> +        disp32:
> +            FETCH(int32_t);
> +        }

In several cases the FETCH()ed value isn't used. Compilers as well as Eclair
(and alike) are happy with that? And compilers also manage to eliminate the
memory accesses then?

> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -835,4 +835,18 @@ static inline void x86_emul_reset_event(struct x86_emulate_ctxt *ctxt)
>      ctxt->event = (struct x86_event){};
>  }
>  
> +/*
> + * x86_decode_lite().  Very minimal decoder for managing alternatives.
> + *
> + * @len is 0 on error, or nonzero on success.  If the instruction has a
> + * relative field, @rel_sz is nonzero, and @rel points at the field.
> + */
> +typedef struct {
> +    uint8_t len;
> +    uint8_t rel_sz; /* bytes: 0, 1 or 4 */

Perhaps use bitfields in favor of fixed-width integers, seeing what
./CODING_STYLE says?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 15:28:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 15:28:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381617.1625150 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqub3-0001z9-C3; Mon, 03 Aug 2026 15:28:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381617.1625150; Mon, 03 Aug 2026 15:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqub3-0001z2-87; Mon, 03 Aug 2026 15:28:57 +0000
Received: by outflank-mailman (input) for mailman id 1381617;
 Mon, 03 Aug 2026 15:28:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqub2-0001yw-2x
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 15:28:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqub1-005nvY-FN
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 17:28:55 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70b3ad-bab6-0a2a0a5309dd-0a2a4503dc86-10
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:28:55 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70b3b7-fae8-0a2a45030019-d155dd2bad51-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:28:55 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47fe377a217so625398f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 08:28:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd458bf7csm35270409f8f.32.2026.08.03.08.28.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 08:28:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785770935; x=1786375735; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=9hbDzSn/VBQV83BOzqY8ZJiuJKORLuI5AlvgJfHJbW8=;
        b=bOc5b96NREoydI5ejd95ickBbT6J8mxyULCOOu0kN9YLYSh0v/pljueNfQEjGYhzL+
         EyY3ck2qvCcRcBCA9+UegMh8NyyAJYd72WeNDntTruhwZMMFI0vHvw/xZAgJcU3fjphu
         vfa8c9K41nst/wTPbglZj6mh8YLpH2bcsDV2ojBe3MkOfuRNuHOM7WyS1ami8fPA+C1c
         sQacar4ppodbo5YuUCBgY19lojaO/5v2UjL5VlWqaRE8SHx+dnasBEzPk/14PrW01v4I
         m+EW0X3QkEZWNT54nkDUzuFaGJKB2PFSCHSSBdgyUe0jDcMe0rsjNULhJ5TviPGm5FG6
         y6Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785770935; x=1786375735;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=9hbDzSn/VBQV83BOzqY8ZJiuJKORLuI5AlvgJfHJbW8=;
        b=r0k0DGOwTSaPtDfj5EQKcHf4p7TtaWS120Q3YmqTzv1BIPAMRHLk5e8dDvnuXoa+jN
         ExSnnX7rqqJbUh9aaNSOXksX4FQ7FftWmYYr+jLUh5ZLJk2TZyh0KZHG0IP6HyF7tImM
         GvEsGnAfvaDKxyhxunO5YzNLN34BHa4bZxCwGsU5rzRZ+da0oJ5zVSlGEz5wvmubu9/2
         h3YFvx1Wu1knPN8KPU2fnMda2TClMihv5rA3oRHhmu5TkaEur/SrlLIVlsY2rmLBCRvJ
         9g3hpCPhgoSe+5iMAXMKYiDx9+DIzkm61FxLw5Jm4v45VjhFIINpblwkKyaNx36LRdem
         CyWA==
X-Forwarded-Encrypted: i=1; AHgh+RrUKxQO5PZ9cWRWLyde+0HHxCWm9H3HPd81CkVAsL1t3WcapJLh8LluhcatIjnwsi3sQwwgEduXvAU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6wHWC3BjU5LsJwFBO59fuXmJe9W3hHAG1LjNpslHUySBQZiVP
	A4TFfNlc9vIfSen93TfeFynw8eH2VGEf6ugMIMsX28gzbqAOyuLLsR/J9ziyz0cREg==
X-Gm-Gg: AR+sD11UMmErqHIppuLVpzfoF22NGNPmsWS4pb767guyHwO4h9PkVgUUFE2jW7DLcpc
	IBBtFYg5oQ45pZdSIYUi/AKO4T6KuPkfXWc2/IZIl28a92sBTCb9p9WdVY56e0bkavV1fNvPBT0
	De3Eilsgj/sbbsLA3vxJfPBQ2udv02zpLI+7W1QeZ+Au38lyL0m+loGrBDp0id4hsz6Z9H5ac7x
	iKsN4Qfj/M+oPZtUFHL9xPNLlPylwqBQF01ISIJO/rcEuQG1+VJzhq15Y/5iMWzxncr1J/7VFwu
	fMkvrr4AcTqRU5zRL7KXiEB44c5NZeeVEtIULJ7quGIgOYT27GAy0QSGiONqBXvQpHZxJ41KAwe
	Vs35yiCtvEbgzzn+WOKVBeXSTKVjh5w0+rhad8OkZgIr2vkc1rJ2Ca9Os8uure0baNl5PLlggST
	+BCSBtQLjii1na3fXYmRDAntW59f9XxT1ETx6lFLCTeHjcO73/y7HLuOvVPhaiJzvqLC1vR2wll
	JqZNCnA/9BkMKonsoTFEW3eXOhBqb35eiAn8pup5u/U6Mg7jpjyE55MwPN4bBw=
X-Received: by 2002:a05:6000:1864:b0:477:47c6:36e5 with SMTP id ffacd0b85a97d-47fd72d2db0mr30889443f8f.25.1785770934785;
        Mon, 03 Aug 2026 08:28:54 -0700 (PDT)
Message-ID: <edb2ef15-a9c1-4dea-ad34-8eb96c2af4d3@suse.com>
Date: Mon, 3 Aug 2026 17:28:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/livepatch: Move init_or_livepatch_* into xen/init.h
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Ross Lagerwall <ross.lagerwall@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803150925.408857-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260803150925.408857-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1785770935-6CCDB4E9-EBE93D33/0/0
X-purgate-type: clean
X-purgate-size: 760

On 03.08.2026 17:09, Andrew Cooper wrote:
> xen/livepatch.h is a fairly heavyweight header pulling in public/sysctl.h, and
> a reasonable number of users care only for the init_or_livepatch_* tags only.
> 
> They're arguably more init than livepatch anyway, and by moving them to
> init.h, we can remove a number of includes.
> 
> The include in vsprintf was leftover from early versions of the work.  In the
> version committed, d5ccf4482e4f ("x86, xsplice: Print payload's symbol name
> and payload name in backtraces"), symbol_lookup() had been adjusted to handle
> the livepatch symbol names properly.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 15:38:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 15:38:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381639.1625163 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqukI-0004KZ-9p; Mon, 03 Aug 2026 15:38:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381639.1625163; Mon, 03 Aug 2026 15:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqukI-0004KS-6y; Mon, 03 Aug 2026 15:38:30 +0000
Received: by outflank-mailman (input) for mailman id 1381639;
 Mon, 03 Aug 2026 15:38:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wqukG-0004KM-AI
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 15:38:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqukF-000inF-G6
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 17:38:27 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a70b5db-e002-0a2a0a5209dd-0a2a4507de56-38
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:38:27 +0200
Received: from [40.107.208.43]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a70b5ef-b4ea-0a2a45070019-286bd02b57bd-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:38:26 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by LV3PR03MB8003.namprd03.prod.outlook.com (2603:10b6:408:282::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Mon, 3 Aug
 2026 15:38:21 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0270.017; Mon, 3 Aug 2026
 15:38:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TT8lmlup7esX4SPiDBkwiikbYYEsjqPWeQW5PnoZupzLOnDt3eJAg4ff/3eEap6AhiAUW6X8aSryB7zmkW133NPShedIn6MwbXf6uPrAITyY/JLuC6wfM1Bs0Td2cVxOQdoeIEk81vUrHYbZICXv3WM1uTwVypi8wrY86NOVax8DS+c3NADmjOdE3WIwATwCv3ZCRIVi6N3AHICbH1hbr9MLJv+YMhvzXtyiKx5siLXWImLvYyPuqIj9pUBaEUonEeg1JQ3Z/gfp3WTkhVgTvFquQsprXS6GcyGRBDUNC8tk1dG7RZHP98XVNuEI60zqLZXofpa8Gz9KmDIEiuGT8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5DJbWVherjg++BqI272ogCa9VbVUtKcQHwb55KAWEL4=;
 b=Sm42Q9yFlFu6P5GN06KyorwMXdqR4yjwwNkoJVE6FsN2ZLCRGf3BzP4icFTd+l98ZqqAVXETllNrc5rgWbxmWRHDnObxk6kC4phmHXL247+43YyR0Ks00CrGZsJHR/eFk5KWI8fLb/ZW2P5R1gvwj4lOlsK7whHGVTzgtXNDjTUvTBmlFGhhhEc4EhxCMyJ8O7+a5jrYjqNDSOXNCPdGK07l60wMaDa2nW9uHgqfrWG3r9L7gK4uXc63JzihDtL+45dxacqneucuKFAwRwpEtj8KrMo7GOlE9qm8bDYb2ED6BMf1u9MHTxwQ46wUObYlUZTGerb9G4/Er2AOf6DBZg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=5DJbWVherjg++BqI272ogCa9VbVUtKcQHwb55KAWEL4=;
 b=Ne/MlHL2p/qCK0Qo+DnHoB1fiqcWH5F+BAHayQN+NaO4SXSbC4EANh5R+S5rarEdcJ2gPPT9Car4b1Iy0SXJSW0it6SKIDHXp/b7E1BcOaVU2PW9Hl4jYJ7rHtnfQfYEn4KwcCY/H7amb0w4sZvt43PLTM7q2dbfkcfDlk3Vxto=
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel
	<xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Michal Orzel
	<michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Oleksii Kurochko
	<oleksii.kurochko@gmail.com>
Subject: Re: [PATCH] xen/livepatch: Move init_or_livepatch_* into xen/init.h
Thread-Topic: [PATCH] xen/livepatch: Move init_or_livepatch_* into xen/init.h
Thread-Index: AQHdI1oaaSQdYQmCuk+Kogsfl3eCaraMcIo9
Date: Mon, 3 Aug 2026 15:38:21 +0000
Message-ID:
 <CH8PR03MB8274CA3275B26577BCB2109FF0D52@CH8PR03MB8274.namprd03.prod.outlook.com>
References: <20260803150925.408857-1-andrew.cooper3@citrix.com>
In-Reply-To: <20260803150925.408857-1-andrew.cooper3@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH8PR03MB8274:EE_|LV3PR03MB8003:EE_
x-ms-office365-filtering-correlation-id: 5443ff49-ad3c-450c-0f4b-08def1753f9a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|38070700021|56012099006|11063799006|10067099003|18002099003|22082099003;
x-microsoft-antispam-message-info:
 +4ZIJoUPZdU0hOhLuhzP0EkCUhEuosfm33phJD29kf+RArB72pV6XccpzBMcBW4jBLzbZb8cATdFpjUUey5XA+/1+FgjWKC99DKqSU8gpnxb7IkM6DeVnG2IpKNyxJovNk/qC49RwCxAVMi52fo3zLncZZkzjLwgx7kRBi/cSDoJ9hqYgryLRSDRkNgdVj2FAjJ2T6HZDgnhUu7RTdZFCqzbxWXtvsr0LBu50Ow+YU9whopZy/gYKJI6Z8DErvRAAzzSQWjmxXkyd7Cq2RInimcqqvbs1o7G95o7rB5btFXQG+au4UO+LfGkds+ha1+ciwD/erdQXPg1TOh6sXnbI5CG8xlBG5liIkA5U/fx2lxe0qs8MH989tNxBZLVrbt/2oquXXTNFmcd9VwWHHF/MOkv/zeSyjUbJpQJRad1WDSjhP6F7Pmeo26bb1pngSgLiUKNsd0+5XIkkEKpIAA31tqaTsThmKepbfsUdzbn3UEzaftaBrlgaBpklXuBGjmWfMDYBR0dj0Hs9GszWYaYHipeuTs5GFjLzzwPbrt0ZgqNAaBcg77jcRxt1v5rCpstiFYiuKSoA01Yq3TUcio8N3KLvB/Gg7ZpgJTGRx84bT+ER7GOxUQ9rZjHWsfaINZAebZOwUEN4u3nF35txeuJrlYdDuWRIY7NnGzVM73jcOI0/o1EQ348wJuKALpD9o90y+pqasF71rlfyK/RCsKF77atfGv3wNziPMsZN5I9ekE=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(38070700021)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?37fWiSXoY/o85LOSLk0ki7kzDkzIUELShyFjzyC6JKXbizvSrUhTiuKEV2?=
 =?iso-8859-1?Q?ultEjHhQjuwGjN2kZmQnR7fMohNVWuSvKtxZ+UxLcdJ0oWmXBpxO29TRbB?=
 =?iso-8859-1?Q?sxhGWydkBipezyhofHfKJHFqBIU5RKkprIWmnawKVgQB75ipwNSq4ohPDu?=
 =?iso-8859-1?Q?RRUIDctOXy/07Y3oBpxUOr3NRMktrjZnvKZpVIRszRQeK5w4wpMAu2ubie?=
 =?iso-8859-1?Q?ocfGSTf63O1DfkNknRdwBUQvCSqY+iMcVorSH5p7jyL4ozZ38v7h5kiMUl?=
 =?iso-8859-1?Q?5OfSFj//CoREBXK4RIYm08eVktpN1/B8pyd2GxeUFRtBiYDqZWozW1WFDo?=
 =?iso-8859-1?Q?DPikRR7IMqTnF1YhU1cu52zPSLPcIQYIWE+1lpfZMaaV1cxok4vBZCmN8r?=
 =?iso-8859-1?Q?GqguDxpZVNn/COB6vs1Tp6WXUXgLKqacoJwgCQLrwREzu8Y2hcc+XBerIi?=
 =?iso-8859-1?Q?2Q+wPqOegWy+ml6OMnUH9dbxaFpBh/EIKNMkOPBclFcT7hO+6lluLQW9YW?=
 =?iso-8859-1?Q?BEnXcaBCvcNQdH036AKpkhv7g9ZpQI/sex4pDNfVbcTcZjNGTlCFccF+XH?=
 =?iso-8859-1?Q?calPOaSjAH7y05SwdSpIabiB3lre23njHmDVLJeR/vFDUJZSKm65urNizn?=
 =?iso-8859-1?Q?swZJiyiJf7koXUm3S8kj36N7AaF5eMs26XoQz6GyDj54UVyhcDtMouYuMw?=
 =?iso-8859-1?Q?9jHYJVye32rl0K5fzQLgYt1tW2yDgUy5lGNFhhRBgjJTRiZ8dVoahXGjRD?=
 =?iso-8859-1?Q?S2PrN9yCQmkRIB3ON0igXykLeEs7YfL0LW36Xx4tvFubA2KbOfK+B/n35s?=
 =?iso-8859-1?Q?cDVQ09c5qc7qwlsa/zQNSc5YZC5t6YbpuR5Cqhm+gPbb2oRqG8ECUd+W41?=
 =?iso-8859-1?Q?bDXq6nY06U8QVgpt1HsPju0ZT0GQ14KqktwkIr7hpTApkpuIU1KrN7oixE?=
 =?iso-8859-1?Q?3mwAqN+2nHgWzUFpU9D/DveuoK5WS+ezwq7tAcrzT1xVkdut+NmOPp6dGa?=
 =?iso-8859-1?Q?uAWHv16KWvWlOsROGgTOGNuXwJxtftw2HQHP+CIJzBQt4qmks18oQqU0KJ?=
 =?iso-8859-1?Q?YJ1fNGox/w1CY9bcIzoMxP81ltLdG1bxbdmFb+bBb/toYxMhLp3UPG8qFy?=
 =?iso-8859-1?Q?4CeR69Ucz0jX0Fm+h9QDrdEym++pX3mBYLTEgkqbKPLkucvQZWq7f1EGeC?=
 =?iso-8859-1?Q?6gFct8RboNVIlSeJQFL6D89efk7c7b3xE+lnrUO2UeasbXrcFglObAorky?=
 =?iso-8859-1?Q?l9l6KAOdyjTwYsvRoIVx7bOtuDw8CdIe9w3vmCv5n1+ZEDl/GRPSLuSWUD?=
 =?iso-8859-1?Q?lc7Uxwm9QHyYxNgX/P6h9UvJPB4ZoVlS7x+EtXIdl2NtEvxSDYwuGbL4TU?=
 =?iso-8859-1?Q?JHuKWQ8yr9sMzuwBfVNBmHMr9DEXaeOB5idDWZBPqcy0Uk16YpeedKCFqE?=
 =?iso-8859-1?Q?k1oMwHbyzMOMeXHpkZqC82otyp15maszBmfjKsn38YSnP2WXmZ1HaGgOdw?=
 =?iso-8859-1?Q?WVplkXcRc0wGISHpwbTxM+vL133DJxrjlmI4sjqbmZyITt4GHX3QeVf7Js?=
 =?iso-8859-1?Q?hu0+t76YmbRISRPg5cC9F25PaRVcOns2MTNKxhO5HhqzdbNt0+0krM5YX7?=
 =?iso-8859-1?Q?XW593Pi5N/iQgS11ViPU/LvVvgVzXaeFslccs9VXrYXpVf7Kn2FfJ7VHVk?=
 =?iso-8859-1?Q?tXqcK8xW+3Yxq1p+ir4CMYg6utQuDDGh4sf5I8sqw1kVhxrxQV+rOBGjey?=
 =?iso-8859-1?Q?WMK9bc44/zjKotWEwX5OrZFBKPd5wdg0pGGGYEtk++Eo1kCow9+xJcuo9x?=
 =?iso-8859-1?Q?gRKV4m6IKA=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5443ff49-ad3c-450c-0f4b-08def1753f9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2026 15:38:21.3417
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IyerVeoGFlk3geEim036Oivshq0RIfo9DWtCMQpWsfrGr6U/0SmpOhWvE9Brq6Tj839xWThD69iEVxfrjhh/2KrJzqRJH2gkJE5BU/r/qYw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB8003
X-purgate-ID: tlsNG-ef75cf/1785771506-344CBAE4-87ADAC26/0/0
X-purgate-type: clean
X-purgate-size: 1198

> From: Andrew Cooper <andrew.cooper3@citrix.com>=0A=
> Sent: Monday, August 3, 2026 4:09 PM=0A=
> To: Xen-devel=0A=
> Cc: Andrew Cooper; Anthony PERARD; Michal Orzel; Jan Beulich; Julien Gral=
l; Roger Pau Monn=E9; Stefano Stabellini; Oleksii Kurochko; Ross Lagerwall=
=0A=
> Subject: [PATCH] xen/livepatch: Move init_or_livepatch_* into xen/init.h=
=0A=
> =0A=
> xen/livepatch.h is a fairly heavyweight header pulling in public/sysctl.h=
, and=0A=
> a reasonable number of users care only for the init_or_livepatch_* tags o=
nly.=0A=
> =0A=
> They're arguably more init than livepatch anyway, and by moving them to=
=0A=
> init.h, we can remove a number of includes.=0A=
> =0A=
> The include in vsprintf was leftover from early versions of the work.  In=
 the=0A=
> version committed, d5ccf4482e4f ("x86, xsplice: Print payload's symbol na=
me=0A=
> and payload name in backtraces"), symbol_lookup() had been adjusted to ha=
ndle=0A=
> the livepatch symbol names properly.=0A=
> =0A=
> No functional change.=0A=
> =0A=
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>=0A=
=0A=
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>=0A=
=0A=
Thanks=0A=


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 16:03:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 16:03:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381670.1625217 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqv8V-0001k2-Kx; Mon, 03 Aug 2026 16:03:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381670.1625217; Mon, 03 Aug 2026 16:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqv8V-0001jv-Hc; Mon, 03 Aug 2026 16:03:31 +0000
Received: by outflank-mailman (input) for mailman id 1381670;
 Mon, 03 Aug 2026 16:03:30 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wqv8U-0001jo-5Y
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 16:03:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqv8T-00FOCh-IM
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 18:03:29 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70bbcb-2eae-0a2a0a5409dd-0a2a4507cde2-20
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 18:03:29 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a70bbd1-b4ea-0a2a45070019-d155dd2fb0a4-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 18:03:29 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-472326ca506so2510721f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 09:03:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd42d91bfsm36196367f8f.15.2026.08.03.09.03.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 03 Aug 2026 09:03:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785773009; x=1786377809; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=gR6EXUyY3JxG4Cgz9uSawE1d5EoxywOylNGrSFbS9E4=;
        b=I+Rc1G573QadXwAZiWQGAtm7nbIA8lpokPQ+FVQC5hWxSe+pCJzlduhCK1/AEyNZxY
         Ysw2klLoZYHcP68WjCctYP+XdBHqwfm9CTOjzfAI2ndPuRxiPDiwuEoElsh84TV78Ubl
         F9h36sRP/HCTBJ1ci/KeiB2wE1St1CAESTXGOhwl5NRLJjmJU6wxek5JRkyqiPLEk+py
         TYaSE2iFL1spzBzl+67G3bMa1KXKAZmfZ4rwJrBJcs7A+FZPKikJNWb4WdnyajiKWW2R
         cqJSl9gyyAXER4UGOskKWcyDzj/NE8fHbAw2iM2x3o3KJ9ka7zxb0EjzWZmNFrDX5iOC
         DEGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785773009; x=1786377809;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=gR6EXUyY3JxG4Cgz9uSawE1d5EoxywOylNGrSFbS9E4=;
        b=kYCv+2kDgr9Iy6TtNmP34vRMRuI6bY0/h3Olz2AelzX/SqvgkowgUBmZc3++e5aovO
         3ODKO09gcws4Jx5XckspxXZP8Yo+CyiV9w3ko0kOP/syEOaVHDX7QHJ6gPxGx24/tjfw
         B0ijkUpnzHzyTJsRYwNZawAAAHmLMjnQD8iEPmC0e1Cr3fiQ4O0/zrNoUw/CWz+jALeD
         zHsTbKYFT4wNPMWz7Erqc7C7TqTeiTEXNcjb8nkcjYVEGCdU5vcCRYAAlW8D4PaRmQut
         fA5sCBpANY1y8aILxSu/1h3sXdSi2ry5MKhqXSeLo1QMF2Ddf0f0lwnMYCzP7Fm33xCP
         Hq0w==
X-Forwarded-Encrypted: i=1; AHgh+RptA5Sgl5eAk13m3oJv1A3Vu8xw6An+Ex6AQu474paulYWHgH6xQTVonqWXOlVzgWI3ThOoxHdhtuY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJ1OcGzIqWsh0sTYM71DMtCjJbCa2fZUFFZh43mjmhcJ0T01te
	miloh6o6po2n1dfTMfj+cr69LXIjU9e6+anv34RGUM//bpQHWUpRjhtTNbrkLh4BZA==
X-Gm-Gg: AR+sD11Qp3EGvQpUkWm8MpX53QkbamvgwUkjZqiJNN9vRW0Ymni9nwtc6VVw+euege9
	jGrl+XEfdItHmy8lmr+oxiUkS/Gxb3W7DfW1f9NvEBBojA2z6j4nnm/8GIn4acSVP2/RipASD6i
	5MiEpBMsLwPx/TyotStpD2/bl9KJUhrMZ4E4DyssYx+biNO20/KGvkO+gmwraY9NPM1C2UIimrc
	Abm1N6ntox4cy/qO0SSAII49VTiZx2JXUMuCQyPvfN9oUJH/Rprc4RjfMvBqng2RUpQnATZmc8G
	MelQ25AWeW1kcUsHT37UaEoGLdiOlXEI2c5JNNY3gVDGznycwaoE4qseH3/8ay0O2rpE2nwMt2I
	oIHSaqV6/H75zaX8/T3wfMeN402IxIS02kN6vL13jX43ukDVuCllEfD22zVax5CVAbXyhZVJrjT
	NphJqmhz4bMpADAup8PSGDd4rMR2GCjxwIR2rndFfswzjOVJdZznoX/AVxhyLfIdFkCULHehwfc
	pqNvzAD9t0Oh3fXNKGJvRkuK52XBmitdIqWhjoKPb6BLJJ0oMvk
X-Received: by 2002:a05:6000:1a87:b0:47a:b86f:3ed1 with SMTP id ffacd0b85a97d-47fd72c6dacmr26654371f8f.21.1785773008460;
        Mon, 03 Aug 2026 09:03:28 -0700 (PDT)
Message-ID: <dd065a33-0105-4527-92f5-f3f127422ee6@suse.com>
Date: Mon, 3 Aug 2026 18:03:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] tests/x86: Introduce a userspace test harness for
 x86_decode_lite()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260803072006.9678-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1785773009-3C411AE4-B99B1469/0/0
X-purgate-type: clean
X-purgate-size: 9440

On 03.08.2026 09:20, Andrew Cooper wrote:
> --- /dev/null
> +++ b/tools/tests/x86-decode-lite/insns.S
> @@ -0,0 +1,703 @@
> +#include "macro-magic.h"
> +
> +        .code64
> +
> +        .allow_index_reg
> +
> +        .text
> +
> +DECL(tests_rel0)
> +modrm:
> +        /* Mod=0, Reg=0, RM {0..f} */
> +        _ add %al, (%rax)
> +        _ add %al, (%rcx)
> +        _ add %al, (%rdx)
> +        _ add %al, (%rbx)
> +        _ add %al, (%rsp) /* SIB */
> +        /*add %al, (%rbp)    RIP --> tests_rel4 */
> +        _ add %al, (%rsi)
> +        _ add %al, (%rdi)
> +        _ add %al, (%r8)
> +        _ add %al, (%r9)
> +        _ add %al, (%r10)
> +        _ add %al, (%r11)
> +        _ add %al, (%r12) /* SIB */
> +        /*add %al, (%r13)    RIP --> tests_rel4 */
> +        _ add %al, (%r14)
> +        _ add %al, (%r15)
> +
> +        /* Mod=1, Reg=0, RM {0..f} */
> +        _ add %al, 0x01(%rax)
> +        _ add %al, 0x01(%rcx)
> +        _ add %al, 0x01(%rdx)
> +        _ add %al, 0x01(%rbx)
> +        _ add %al, 0x01(%rsp) /* SIB */
> +        _ add %al, 0x01(%rbp)
> +        _ add %al, 0x01(%rsi)
> +        _ add %al, 0x01(%rdi)
> +        _ add %al, 0x01(%r8)
> +        _ add %al, 0x01(%r9)
> +        _ add %al, 0x01(%r10)
> +        _ add %al, 0x01(%r11)
> +        _ add %al, 0x01(%r12) /* SIB */
> +        _ add %al, 0x01(%r13)
> +        _ add %al, 0x01(%r14)
> +        _ add %al, 0x01(%r15)
> +
> +        /* Mod=2, Reg=0, RM {0..f} */
> +        _ add %al, 0x7f000001(%rax)
> +        _ add %al, 0x7f000001(%rcx)
> +        _ add %al, 0x7f000001(%rdx)
> +        _ add %al, 0x7f000001(%rbx)
> +        _ add %al, 0x7f000001(%rsp) /* SIB */
> +        _ add %al, 0x7f000001(%rbp)
> +        _ add %al, 0x7f000001(%rsi)
> +        _ add %al, 0x7f000001(%rdi)
> +        _ add %al, 0x7f000001(%r8)
> +        _ add %al, 0x7f000001(%r9)
> +        _ add %al, 0x7f000001(%r10)
> +        _ add %al, 0x7f000001(%r11)
> +        _ add %al, 0x7f000001(%r12) /* SIB */
> +        _ add %al, 0x7f000001(%r13)
> +        _ add %al, 0x7f000001(%r14)
> +        _ add %al, 0x7f000001(%r15)
> +
> +        /* Mod=3, Reg=0, RM {0..f} */
> +        _ add %al, %al
> +        _ add %al, %cl
> +        _ add %al, %dl
> +        _ add %al, %bl
> +        _ add %al, %ah
> +        _ add %al, %ch
> +        _ add %al, %dh
> +        _ add %al, %dl

Perhaps also include %bpl, %sil, and %dil?

> +onebyte_row_9x:
> +        _ nop
> +        _ pause
> +        _ xchg %ax, %ax
> +        _ xchg %eax, %eax
> +        _ xchg %rax, %rax
> +        _ rex.w xchg %rax, %rax
> +        _ cltq
> +        _ cqto
> +        _ wait
> +        _ pushf
> +        _ popf
> +        _ sahf
> +        _ lahf
> +
> +onebyte_row_ax:

May I suggest onebyte_row_Ax?

> +DECL(tests_rel1)
> +disp8:
> +1:
> +        _ jo   1b
> +        _ jno  1b
> +        _ jb   1b
> +        _ jae  1b
> +        _ je   1b
> +        _ jne  1b
> +        _ jbe  1b
> +        _ ja   1b
> +        _ js   1b
> +        _ jns  1b
> +        _ jp   1b
> +        _ jnp  1b
> +        _ jl   1b
> +        _ jge  1b
> +        _ jle  1b
> +        _ jg   1b
> +        _ jmp  1b
> +
> +disp8_rex:
> +        _ rex.w jo   1b
> +        _ rex.w jno  1b
> +        _ rex.w jb   1b
> +        _ rex.w jae  1b
> +        _ rex.w je   1b
> +        _ rex.w jne  1b
> +        _ rex.w jbe  1b
> +        _ rex.w ja   1b
> +        _ rex.w js   1b
> +        _ rex.w jns  1b
> +        _ rex.w jp   1b
> +        _ rex.w jnp  1b
> +        _ rex.w jl   1b
> +        _ rex.w jge  1b
> +        _ rex.w jle  1b
> +        _ rex.w jg   1b
> +        _ rex.w jmp  1b
> +END(tests_rel1)

What's the idea behind the separate REX.W testing? It almost suggests that
tests with an operand size prefix also may want adding. Except that's
difficult, because of ...

> +DECL(tests_rel4)
> +disp32:
> +        _ call   other_section
> +        _ jmp    other_section
> +        _ jo     other_section
> +        _ jno    other_section
> +        _ jb     other_section
> +        _ jae    other_section
> +        _ je     other_section
> +        _ jne    other_section
> +        _ jbe    other_section
> +        _ ja     other_section
> +        _ js     other_section
> +        _ jns    other_section
> +        _ jp     other_section
> +        _ jnp    other_section
> +        _ jl     other_section
> +        _ jge    other_section
> +        _ jle    other_section
> +        _ jg     other_section
> +        _ xbegin other_section
> +
> +disp32_rex:
> +        _ rex.w call   other_section
> +        _ rex.w jmp    other_section
> +        _ rex.w jo     other_section
> +        _ rex.w jno    other_section
> +        _ rex.w jb     other_section
> +        _ rex.w jae    other_section
> +        _ rex.w je     other_section
> +        _ rex.w jne    other_section
> +        _ rex.w jbe    other_section
> +        _ rex.w ja     other_section
> +        _ rex.w js     other_section
> +        _ rex.w jns    other_section
> +        _ rex.w jp     other_section
> +        _ rex.w jnp    other_section
> +        _ rex.w jl     other_section
> +        _ rex.w jge    other_section
> +        _ rex.w jle    other_section
> +        _ rex.w jg     other_section
> +        _ rex.w xbegin other_section

... vendor differences here. Perhaps the decoder itself would better
reject handling of operand-size-prefixed branches.

> +opsize_branch: /* 66-prefixed branches are decoded differently by vendors */
> +        _ data16 call   other_section
> +        _ data16 jmp    other_section
> +        _ data16 jo     other_section
> +        _ data16 jno    other_section
> +        _ data16 jb     other_section
> +        _ data16 jae    other_section
> +        _ data16 je     other_section
> +        _ data16 jne    other_section
> +        _ data16 jbe    other_section
> +        _ data16 ja     other_section
> +        _ data16 js     other_section
> +        _ data16 jns    other_section
> +        _ data16 jp     other_section
> +        _ data16 jnp    other_section
> +        _ data16 jl     other_section
> +        _ data16 jge    other_section
> +        _ data16 jle    other_section
> +        _ data16 jg     other_section
> +        _ data16 xbegin other_section

Oh, you even cover the case here. For XBEGIN, however, this can only be pure
guesswork as to AMD behavior, I suppose.

I also don't see how you force which form you want.

> --- /dev/null
> +++ b/tools/tests/x86-decode-lite/main.c
> @@ -0,0 +1,111 @@
> +/*
> + * Userspace test harness for x86_decode_lite().
> + */
> +#include <stdio.h>
> +
> +#include "x86-emulate.h"
> +
> +static unsigned int nr_failures;
> +#define fail(t, fmt, ...)                                       \
> +({                                                              \
> +    const unsigned char *insn = (t)->ip;                        \
> +                                                                \
> +    nr_failures++;                                              \
> +                                                                \
> +    (void)printf("  Fail '%s' [%02x", (t)->name, *insn);        \
> +    for ( unsigned int i = 1; i < (t)->len; i++ )               \
> +        printf(" %02x", insn[i]);                               \
> +    printf("]\n");                                              \
> +                                                                \
> +    (void)printf(fmt, ##__VA_ARGS__);                           \
> +})
> +
> +struct test {
> +    const char *name;
> +    void *ip;
> +    unsigned long len;
> +};
> +
> +extern const struct test
> +/* Defined in insns.S, ends with sentinel */
> +    tests_rel0[], /* No relocatable entry */
> +    tests_rel1[], /* disp8 */
> +    tests_rel4[], /* disp32 or RIP-relative */
> +    tests_unsup[]; /* Unsupported instructions */
> +
> +static inline void run_tests(const struct test *tests, unsigned int rel_sz)
> +{
> +    printf("Test rel%u\n", rel_sz);
> +
> +    for ( unsigned int i = 0; tests[i].name; ++i )
> +    {
> +        const struct test *t = &tests[i];
> +        x86_decode_lite_t r;
> +
> +        /*
> +         * Don't end strictly at t->len.  This provides better diagnostics if
> +         * too many bytes end up getting consumed.
> +         */
> +        r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);

For the excess bytes to at least be legitimate to access (not causing UB),
shouldn't finish_arr emit enough filler bytes?

> --- /dev/null
> +++ b/tools/tests/x86-decode-lite/x86-emulate.h
> @@ -0,0 +1,27 @@
> +#ifndef X86_EMULATE_H
> +#define X86_EMULATE_H
> +
> +#include <assert.h>
> +#include <stdbool.h>
> +#include <stdint.h>
> +#include <stdlib.h>
> +#include <string.h>
> +
> +#include <xen/asm/x86-defns.h>
> +#include <xen/asm/x86-vendors.h>
> +
> +#include <xen-tools/common-macros.h>
> +
> +#define ASSERT assert
> +
> +#define printk(...)
> +
> +#define likely
> +#define unlikely
> +#define cf_check
> +#define init_or_livepatch
> +#define init_or_livepatch_const
> +
> +#include "x86_emulate/x86_emulate.h"

Why does this end up being needed?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 17:20:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 17:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381727.1625269 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqwLA-0006pL-F3; Mon, 03 Aug 2026 17:20:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381727.1625269; Mon, 03 Aug 2026 17:20:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqwLA-0006pE-CV; Mon, 03 Aug 2026 17:20:40 +0000
Received: by outflank-mailman (input) for mailman id 1381727;
 Mon, 03 Aug 2026 17:20:39 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcus.granado@citrix.com>) id 1wqwL9-0006p7-IB
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 17:20:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqwL8-005wQt-Io
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 19:20:38 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcus.granado@citrix.com>)
 id 6a70cdd2-5cb7-0a2a0a5109dd-0a2a450aaf30-18
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 19:20:38 +0200
Received: from [52.101.201.67]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcus.granado@citrix.com>)
 id 6a70cde4-f2d2-0a2a450a0019-3465c94312ce-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 19:20:38 +0200
Received: from LV4PR03MB8234.namprd03.prod.outlook.com (2603:10b6:408:2e3::8)
 by CO1PR03MB7844.namprd03.prod.outlook.com (2603:10b6:303:271::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Mon, 3 Aug
 2026 17:20:34 +0000
Received: from LV4PR03MB8234.namprd03.prod.outlook.com
 ([fe80::264a:2e82:2064:7fab]) by LV4PR03MB8234.namprd03.prod.outlook.com
 ([fe80::264a:2e82:2064:7fab%4]) with mapi id 15.21.0270.017; Mon, 3 Aug 2026
 17:20:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sQDUWfgloOuBhgGFHAs9LKFSjxN5m3HrWFN/rrazmfKbR4zEKz33sQw+g+lTc7+4BNE07lOE8qyr6DRlGsIG9oIZ2X63NoeoD8+NlfuOThUy2nXcIEk1X97e9sjjGPMqUGuTBdwqA0s+WmQdfFQJpr6Zno8QBx7iBS1wAt5hGThUpn5o7664OnVAmYnf99/rsawE3njOxlv0/zHpRUAeMR2vJscCZbs+JyJECxJQUsdtthIVvseNR1/E8sZct+YnM5GuUh7XfZDxQTOumnYPPTS8Qme7h/DjCXwFXIa5nHi4lPHb01LYSxQbaxb85FE0Kq9PGbKpd97gs+SI2gyEZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=McJSzCrEOR2LSblxBLAbR8WL/F8VFRGO8LEK1pbv4AY=;
 b=ksvdd48KX+t0nZiRJRkz5W2sKjJLt+Z5r+yPUJaeo6yuquLM+QgW5fI/KVwq+E4/QsB6wBrnQBXG29WrhEK/72uoNJObp3/4bht3GwaDy8Jm8aFObWXYPsfVQBrrXEbiLpdcGzfupGuVq6+9P5K5AqowY96421l0jN/wZnm6kG3fNGbe+KRYL6mQgSMvU4cCJf6l2eFHWXykWjC+gUJ248CuCc/moJoxcuUvV2ShiEbIipdx86EPrY4X6rHzpEhxjXRh9PlxJLm4ihCzdW/3gz5gA07i8xSsTX01PBlZultik1oocLpJHOPMTCi8FdbrQqUCSqOSuu3hYRPge3rBew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=McJSzCrEOR2LSblxBLAbR8WL/F8VFRGO8LEK1pbv4AY=;
 b=X4ff/j7m0B/uOn3cOa7vwuvZjoZRR8QlkQkDZ/A0Bj8zSHFzVWOkvKcqOmf04KFW6MtA6ylZxAAApsh1mxk15ff23uInBMz1oT7kWtzosZL5Dch6jozapfaXK2pXgihpMy/vyAw9GC6dgoetNK0f7Qn+MCX999TDW9gpL+xbo4g=
From: Marcus Granado <marcus.granado@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Andrew
 Cooper <andrew.cooper3@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	=?iso-8859-1?Q?Marek_Marczykowski-G=F3recki?=
	<marmarek@invisiblethingslab.com>
Subject: Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
Thread-Topic: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
Thread-Index: AQHdGF9mhIhyvqGSRUyPVZ4Z3HHB7rZ3oucAgAJQsgCAAB5PgIAKMo6AgAhhrfE=
Date: Mon, 3 Aug 2026 17:20:34 +0000
Message-ID:
 <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>
References: <20260720154832.1907401-1-marcus.granado@citrix.com>
 <20260720154832.1907401-2-marcus.granado@citrix.com>
 <1784622046.8631fc262581453bbf619ec5b2062170.19f83c35cd4000edb5@vates.tech>
 <CAHt6W4erBfB+H_0d+2rQ0apz9Jt6ex+WVjEjyPm6EApoHVJgmg@mail.gmail.com>
 <1784755834.8631fc262581453bbf619ec5b2062170.19f8bbccffd000edb5@vates.tech>
 <CAHt6W4cWLfSVoCSgr-YsQb1Mv=VZek0CakTBwK7tx_n9RkeiUg@mail.gmail.com>
In-Reply-To:
 <CAHt6W4cWLfSVoCSgr-YsQb1Mv=VZek0CakTBwK7tx_n9RkeiUg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV4PR03MB8234:EE_|CO1PR03MB7844:EE_
x-ms-office365-filtering-correlation-id: 2dc8adee-03c6-4607-bde3-08def183870d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|10070799003|23010399003|376014|1800799024|366016|38070700021|6133799003|56012099006|4143699003|11063799006|5023799004|10067099003|18002099003|22082099003;
x-microsoft-antispam-message-info:
 ai83XngNyv26uaWP2TIu1i2LXQtZvSNRXXPDdBMeALD85fvLZDdLgnTCikrFrmhUnOl0lTW52P5IVVYrIEaGbivG3ipOkpA3Ua1EJR0bjJKOnGV4/6teqrQpzADymFu2pbtrYy3smjFb/qRNh3mJOKPeFd/gslvVPEpJKrbtfs2zhzVOizesBMmV1/UKc5xM1CqPBnjYO4ZtUfDrEuvzUwKwQ43BlbpT5x/OTZiJYzp102X8hrWhiT2FuYn4mEcop1EoVaEIfNd4SzKETLUJvMS7ZxDzdMFXPqTlFh2dHzERQkRFgDD55pk/7sGGYTOTo5jT6cqG+kQy/0On0+P/GzJRxqn3ty27m37VXmXCPRgul5KuKmqlMdr9k70Oq08TuA0mTd7n9Kimkcg/PFAmSz4/ZlYI2WraLKOydWJUeSY03RxY+nqvQ6wfTWNJK0HjlaDb8L/3AOrvPPkQqSK6oTXHJDT3KqSVp56KwX3juhnXiRl84H9tqHDTp4rUcpG8dyIHBzw4hvWAuxQ2zoI+SCTb+YAlGgsCKOwTVXvVX2jXCqq6ZT6q4gR/bfYacdB0vgfThTFOT85YX9hEr023jtXbw4PpgeUAN4OnQlxHi+Qtl+iV4zgaPa0WnkX5sVLEkkDQUUgQn5xG4CaKd+lc4oHOhHANCz2AiBB5Ir2xVXOs200fCfhgZxYz7lp0Hqb4cMuwOGCn+m6DvX69/2/hOHWkeh2mTSFC8cBwyd5QFKo=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV4PR03MB8234.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(23010399003)(376014)(1800799024)(366016)(38070700021)(6133799003)(56012099006)(4143699003)(11063799006)(5023799004)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?CV1LCZhFdxcJxtW4v20HQ03VEW6Lm19DNNJez83YIu9AWHLB4L37QYh8d7?=
 =?iso-8859-1?Q?Brp59IqJl6QmzyPhpWC0ehZNbsZRhA1gA/BnAFQ7/lcbRbs3+CfStRvh96?=
 =?iso-8859-1?Q?H4ItjBlcn6nHGeK6x9HH9DYI1yRCKYlXddGy2VhfyxmsVIxGTdF6JdIteH?=
 =?iso-8859-1?Q?JzPQnMzvdgmcx615T50cvwKcUP2rLtGiEhD4qMRRI5NXK5DOHeemJSTiZ/?=
 =?iso-8859-1?Q?vhEHLE2kg/1e/H3Q4i9T34Jraa9XKNeTPZw4bNvaEo7BlbcGk6XkmP1q/c?=
 =?iso-8859-1?Q?BNIaTHnUm2488/Q5FZSBzfNtACkFJ8wh7mPstPtmOFv6+XHskicITYZjmL?=
 =?iso-8859-1?Q?lFHoUTYPsuw+LguZf+wOta+5crV1FMf9ke7DR05xbSFL5T0Kq76O+RzrBB?=
 =?iso-8859-1?Q?ZqcAUB1loIeHdnwvqCOHiF5VpQIlWy3w4163FV3brVK+bC7K3CJ3iLHw2b?=
 =?iso-8859-1?Q?KT6aEv17UeVLq++uB6dPVVdDfaZFMuvKpiVmGt+dKXD4Y3DrSvZN7e+eCb?=
 =?iso-8859-1?Q?19ctMu3td2WZT8ytZ/5fWCTVa3IpJbuwSW+89hy2/UoEg8Wf5c2zf9gFKc?=
 =?iso-8859-1?Q?jEjcnOOpa44XKfOJaYNV6b1VHw0C0gjfpzFvH9B+wepvMeVl1ZEMLJRxft?=
 =?iso-8859-1?Q?whONMBUuKFjXUf7Xi+3h6do1qv2ooYxytbegePOEQ+VmoiKRLlQjM0JxEQ?=
 =?iso-8859-1?Q?RHKL+W4DLwlNFqwf7+X8aKKsltd8zdK6Nb/Ck22lziE7m47+UPOX136tYE?=
 =?iso-8859-1?Q?OB3zE4BbZHw9l3RPPj7xhq/qWHlLZWUXGo2Yh3DKckoRTZqJ4TWjzMJ+8E?=
 =?iso-8859-1?Q?iuU9iD5pL76xzZpLJmuLGkK40RqvH6issF3abrnfP+4PIhSZS9znbVW18Y?=
 =?iso-8859-1?Q?rKruGvUqJ4vEA7Asedwu5JWxyWdZ1DpbOH1pfvBAZKRrqSvqSvyMQ34ZqP?=
 =?iso-8859-1?Q?OKJQJEvS1EigWGnmezKlCdEm+rvcLi2G8VgWqXBDmR1eyOKpdPxL8ewsq+?=
 =?iso-8859-1?Q?COKmbJ1joV9M6iPtLqVK/tNpiptLLlF93D/w0V/VD0dBLIDb8BeFlNLpL3?=
 =?iso-8859-1?Q?MQIwGeZmWpwCieG9hH++VfrCGtjPdlBVaaZC8X1U18sqZeIiiQs+SXhjyd?=
 =?iso-8859-1?Q?vITmrZND5ImxtHMAIMEu7N047XhROrwo63OiWbyGFvQYQ5+USQnyCYtP+F?=
 =?iso-8859-1?Q?rf4fuAWev4vxVk/qz1eUCEhE/0lzGuKzkvHEx1HnBiEBQHglehgTKLCNBd?=
 =?iso-8859-1?Q?3lJFpSvxZHE+Fzz5i8v8GQbb+9WFJFdEZ9/IXrNsL6/1toE+uFgGHpsaRe?=
 =?iso-8859-1?Q?0CFGhmev089GTmdqm0lUiUq0MZdkV3b6nOno+F7Qxrl37ooVQ790LmpAky?=
 =?iso-8859-1?Q?4BWlRJMwmBKESZf3u2Xd2VxflQhypzj8JVh0joKQV99TwGPKDK2CNwtbTs?=
 =?iso-8859-1?Q?Dacq6h+gTn/Gzwl3v+kRKiYV1zhuNzgiJOI+Cm9tp1MTJBzwoRd8WltaUi?=
 =?iso-8859-1?Q?I3AKlMC0huEAu/Bu3NIwqohOMDZ8qtP1EUPxTZqH5JxZNWZxQBZj03lzjr?=
 =?iso-8859-1?Q?XsCspqAufJSHgEXx7MQRwEF3QHJCB4H9hNQyJRMcC1/Zxm1IeWExxwAKUV?=
 =?iso-8859-1?Q?+R/Mb5wj5Vc+g/mFfxNDSrEbAMvVGcEgIVqlo8YRXPAdYtrf93zpMLJCxG?=
 =?iso-8859-1?Q?e/JrcVjj5MbhRZE7TbaAA/kfnLjn2PgQlskKGTdkdi2Rnu4M6vwUT3UlIG?=
 =?iso-8859-1?Q?0U8C9QqgBY4qEaCeOxRh2PPjUg6j4EWuBmRy2c26i+4u1LJdqG2LLt8Jga?=
 =?iso-8859-1?Q?9uG54wwtB6b34tlGBhTzLgM66iEbswFEe+sATmRYRHPcbYA5ypnJfKTrdI?=
 =?iso-8859-1?Q?6X?=
x-ms-exchange-antispam-messagedata-1: oNOkn+7hI2Z4EA==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV4PR03MB8234.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2dc8adee-03c6-4607-bde3-08def183870d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2026 17:20:34.1814
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hMB8AhLHGpRApPy1gWhSVIu3USMA/kkE1siULy1+gj5XYHCR2TW+QuRwFF4MyrmPLz0n6MJ5Gw8nZxvS/qSzqFBoxTdSXjjStSzdPi0Pu4U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7844
X-purgate-ID: tlsNG-4011c0/1785777638-5ABD8CFC-6497A97C/0/0
X-purgate-type: clean
X-purgate-size: 6810

On Wed, 29 Jul 2026 at 10:14, Frediano Ziglio <freddy77@gmail.com> wrote:=
=0A=
> About compressing all together and considering also the issue of=0A=
> memory changing while sending I would vote to copy the memory in a=0A=
> temporary buffer to avoid this. One advantage is that it simplified=0A=
> the format. The current LZ4 implementation seems to cope with data=0A=
> changes but nothing guarantees it in the future, the buffer you are=0A=
> passing is not supposed to change while you compress it.=0A=
=0A=
=0A=
Agreed. Frediano and I discussed this further, including simplifications on=
=0A=
the compression record for v2 so that the page data compression:=0A=
* compresses the whole batch together=0A=
* and uses a staged copy for it as you and Teddy suggested (so that we do=
=0A=
not need to worry about mutating buffers affecting LZ4 or other algorithms)=
.=0A=
=0A=
Once there's exactly one compressed blob per record, there's no need for=0A=
extra fields to describe the compressed data, as the uncompressed batch=0A=
size is known (and bounded by MAX_BATCH_SIZE * page_size), and its=0A=
compressed size can be inferred from the size of the emitted compressed=0A=
record without a need for an explicit field for clen or a field with the=0A=
number of raw compressed blobs. This means the separate PAGE_DATA_LZ4=0A=
record type is not needed, and the proposal for v2 compression record could=
=0A=
simplify to reusing PAGE_DATA and spending one octet of its reserved word=
=0A=
as follows:=0A=
=0A=
=0A=
     0     1     2     3     4     5     6     7 octet=0A=
    +-----------------------+-----+-------------------+=0A=
    | count (C)             | comp| (reserved)        |=0A=
    +-----------------------+-----+-------------------+=0A=
    | pfn[0]                                          |=0A=
    +-------------------------------------------------+=0A=
    ...=0A=
    +-------------------------------------------------+=0A=
    | pfn[C-1]                                        |=0A=
    +-------------------------------------------------+=0A=
    | page_data[0..N-1] if comp =3D=3D 0                  |=0A=
    | or page_cdata     if comp !=3D 0                  |=0A=
    +-------------------------------------------------+=0A=
=0A=
with two new entries in the field table:=0A=
=0A=
comp        Compression algorithm applied to the page contents. 0=0A=
            means none, and the record is exactly as it is today. 1=0A=
            means LZ4 block format. Other values are reserved for=0A=
            other future formats like ZSTD etc. A comp !=3D 0 can only=0A=
            be emitted if 0 < len(page_cdata) < N * page_size. An=0A=
            unknown comp must cause the receiver to fail with a=0A=
            "Compression algorithm <value> not handled" error.=0A=
=0A=
page_cdata  Present instead of page_data when comp is non-zero. A=0A=
            single compressed object holding the concatenation of the=0A=
            N page_data entries. The receiver must verify that=0A=
            0 < count <=3D MAX_BATCH_SIZE.=0A=
=0A=
=0A=
Teddy, I hope this format covers your points: it's no longer LZ4 specific,=
=0A=
the inline clen inconsistency in libxenguest record disappears, it's one=0A=
block over an immutable copy of the batch instead of one per page, the=0A=
decompressed size is known up front, and the allocation derived from count=
=0A=
is bounded on the receiver.=0A=
=0A=
=0A=
This simplification is also forward-compatible in two different ways: your=
=0A=
64KB chunking for cache locality doesn't depend on the format, as the=0A=
staging copy can be done in chunks while still making a single compress=0A=
call over the whole batch. And if we find benefits in splitting the payload=
=0A=
into several compressed units, that can be implemented as a new comp value=
=0A=
using a self-delimiting format like zstd or lz4f frames, which report the=
=0A=
consumed bytes without a need to specify clen or extra framing fields at th=
e=0A=
record level.=0A=
=0A=
=0A=
On Wed, 22 Jul 2026 at 20:42, Frediano Ziglio <freddy77@gmail.com> wrote:=
=0A=
> Don't we need to bump the version number while we add a new mandatory rec=
ord?=0A=
=0A=
I believe we may avoid having to do a version bump if we adopt the property=
=0A=
that 0 < len(page_cdata) < N * page_size when comp !=3D 0, as in this case=
=0A=
the compressed data sent to an old receiver would fail in handle_page_data(=
)=0A=
with "PAGE_DATA record wrong size". Bumping the version would make=0A=
uncompressed migrations fail if they are sent to old receivers that also=0A=
understand uncompressed migration, so avoiding if possible would be good.=
=0A=
The spec says migration tools "shall always save images using version V",=
=0A=
so it doesn't seem like we could bump the version only when compression is =
on.=0A=
=0A=
=0A=
> Is there no kind of dialog about the supported version?=0A=
=0A=
There is no in-stream negotiation, and this proposal does not add one.=0A=
Compression is opt-in at the sender via xl migrate --compress, so an operat=
or=0A=
who enables it against an old receiver gets a clean failure rather than=0A=
corruption.=0A=
=0A=
> Why not extending the generalization compressing all payload of=0A=
> uncompressed packets (type+body),=0A=
=0A=
A composable wrapper would be a clean generic mechanism, but I think there=
=0A=
are two reasons not to go that way in v2: PAGE_DATA is effectively all of t=
he=0A=
stream bytes, so compressing the other record types would not show up in a=
=0A=
measurement. And the no-extra-fields property above depends on PAGE_DATA=0A=
specifically: a generic wrapper has no pfn array from where we can derive=
=0A=
the uncompressed size, so it would need explicit algorithm, compressed=0A=
size and uncompressed size fields on every record, which re-adds the fields=
=0A=
that this proposal tries to avoid.=0A=
=0A=
=0A=
Please let me know if the ideas above capture what you had in mind in terms=
 of=0A=
suggestions to improve v1.=0A=
=0A=
In particular, I wonder what the maintainers think of the use of one of the=
=0A=
octets of the PAGE_DATA reserved field for the purpose of indicating the da=
ta=0A=
is compressed, or is it preferable to use a new PAGE_DATA_COMPRESSED (0x13)=
=0A=
type record as a mandatory record so that an old receiver fails more cleanl=
y=0A=
when it doesn't understand compression "Mandatory record <name> not handled=
"=0A=
(caused by the specification of mandatory records) instead of with a generi=
c=0A=
error "PAGE_DATA record wrong size" (caused by the current safety=0A=
implementation that rejects unexpected record sizes)?=0A=
=0A=
=0A=
Marcus=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 18:13:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 18:13:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381746.1625279 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqxAK-0006sb-5r; Mon, 03 Aug 2026 18:13:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381746.1625279; Mon, 03 Aug 2026 18:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqxAK-0006sU-2q; Mon, 03 Aug 2026 18:13:32 +0000
Received: by outflank-mailman (input) for mailman id 1381746;
 Mon, 03 Aug 2026 18:13:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ziy@nvidia.com>) id 1wqxAJ-0006sN-0v
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 18:13:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqxAI-00CW6Z-5z
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 20:13:30 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a70da46-e002-0a2a0a5209dd-0a2a4503978a-8
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 20:13:29 +0200
Received: from [52.101.61.9]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a70da47-fae8-0a2a45030019-34653d097a90-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 20:13:28 +0200
Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7)
 by PH7PR12MB6935.namprd12.prod.outlook.com (2603:10b6:510:1b9::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Mon, 3 Aug
 2026 18:13:18 +0000
Received: from IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0270.017; Mon, 3 Aug 2026
 18:13:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WD6ZOUp+WnBpKUL/Z/T7kHJS3gdbMiHPaDWLnG+FW2Ughc5kivpbHAl9m7v4kZtUlwne3dtTcxUKM7WrJyBjIzNunVwJE8YCw5xf460FYDTOx6lI06pdu9THT47XqNLtDLCdzux8qTLf/nbRDsOOv/8gNbNU4E2T2QAuULs2fA5qQHbM4xHgZv2o0OOWsIgB9IrcShazm0DicLCB2r0EQKH4D6YFHM6X6V09ySI5OEc6n7D3GLeeZQVOXqxWW+VbyMV7HL3rN70ZTujV0k0q4aAXFKUkqMGPn1t6bGDJN5lRp550zxCce4yQxpsqpaiJjD8UiJnfV95Vbq8C+ISS6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eRjbsBRIUTAFpugKKLOjSbZ6YnFTaZPMTTSy9l9apTE=;
 b=axI4QwD0gDNm37sbZwPepJqFwCIiAQLsRb16JqMJC18kzIbTrEGCymZhb+s+VT3do6EhX/NunZoNzoqNMzdrVPiKGAHzZxXxgE3R9xuo+1Gti7a03F9fRjGK5P50Lt8AxaBXztxd5r9zFCY/UqUcakRm4oUcNJdIAnG/3xc01xoOvlR1WiMD7tpFinSy/n/j8hqvWefCeMnzCgHYzYcPJ8uU/jJoPnMGHd/+YZPkn0JJ2U3O95hflOwGfyepG+2jZsgsMfbSa132CavPOtTL6zLMDpd6I+fzR/hlKcTK94MwK5Xl/bUCYD9mr9kjrEYXGsa4Ph7cigPFSjEaaRhp/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eRjbsBRIUTAFpugKKLOjSbZ6YnFTaZPMTTSy9l9apTE=;
 b=gxRy5BNSr6u+YqAfadGamez0ES69ulGmVjdQ7wL80choytSsnxQAlwikJcKnY7d7Uw564V87JyMSSqEMqm6I3eyQ8hHwQgGFREoi4hLHlGzS9JCT9FEDSrgt5yoHWS9vKZEID6DWzvgO/uM68mWZ19n7kvMB+gzmij0pdwS5RPmRbSJIRi0JMJdUya8s9PYMz1a0gliFwwRvb7ymFruUVGm7IrQhIxbKxZt2k3pI13FRQ2A68aYiDbfeVVWpfh3Mmt76rm/50mIM4i03A/9AFOI/h98bANBM9Ic5xWGJvoXq7pwmi/JlRG0WcTtM7QctGHIP3ZNoYVG8sNcqXB0SMA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 03 Aug 2026 14:13:13 -0400
Message-Id: <DKFIGJBRSDB1.O204NIB7HZMR@nvidia.com>
Subject: Re: [PATCH RFC 00/14] Remove PG_private by using
 page/folio->private checks instead
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, "Minchan Kim"
 <minchan@kernel.org>, "Sergey Senozhatsky" <senozhatsky@chromium.org>,
 "Peter Zijlstra" <peterz@infradead.org>, "Ingo Molnar" <mingo@redhat.com>,
 "Arnaldo Carvalho de Melo" <acme@kernel.org>, "Namhyung Kim"
 <namhyung@kernel.org>, "Thomas Gleixner" <tglx@kernel.org>, "Borislav
 Petkov" <bp@alien8.de>, "Dave Hansen" <dave.hansen@linux.intel.com>,
 <x86@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Alexander
 Shishkin" <alexander.shishkin@linux.intel.com>, "Jiri Olsa"
 <jolsa@kernel.org>, "Ian Rogers" <irogers@google.com>, "Adrian Hunter"
 <adrian.hunter@intel.com>, "James Clark" <james.clark@linaro.org>, "H.
 Peter Anvin" <hpa@zytor.com>, <linux-perf-users@vger.kernel.org>, "Stefano
 Stabellini" <sstabellini@kernel.org>, "Oleksandr Tyshchenko"
 <oleksandr_tyshchenko@epam.com>, <xen-devel@lists.xenproject.org>, "Eric
 Biggers" <ebiggers@kernel.org>, "Theodore Y. Ts'o" <tytso@mit.edu>,
 "Jaegeuk Kim" <jaegeuk@kernel.org>, <linux-fscrypt@vger.kernel.org>, "Oscar
 Salvador" <osalvador@suse.de>, "Chao Yu" <chao@kernel.org>,
 <linux-f2fs-devel@lists.sourceforge.net>, "Gao Xiang" <xiang@kernel.org>,
 "Jan Kara" <jack@suse.cz>, "Yue Hu" <zbestahu@gmail.com>, "Jeffle Xu"
 <jefflexu@linux.alibaba.com>, "Sandeep Dhavale" <dhavale@google.com>,
 "Hongbo Li" <hongbohbli@tencent.com>, "Chunhai Guo" <guochunhai@vivo.com>,
 <linux-erofs@lists.ozlabs.org>, <linux-fsdevel@vger.kernel.org>, "Steven
 Rostedt" <rostedt@goodmis.org>, "Masami Hiramatsu" <mhiramat@kernel.org>,
 "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>, "Matthew Brost"
 <matthew.brost@intel.com>, "Joshua Hahn" <joshua.hahnjy@gmail.com>, "Rakie
 Kim" <rakie.kim@sk.com>, "Byungchul Park" <byungchul@sk.com>, "Axel
 Rasmussen" <axelrasmussen@google.com>, "Yuanchu Xie" <yuanchu@google.com>,
 "Wei Xu" <weixugc@google.com>, <linux-trace-kernel@vger.kernel.org>, "Trond
 Myklebust" <trondmy@kernel.org>, "Anna Schumaker" <anna@kernel.org>,
 <linux-nfs@vger.kernel.org>, "Song Liu" <song@kernel.org>, "Yu Kuai"
 <yukuai@fygo.io>, "Ilya Dryomov" <idryomov@gmail.com>, "Alex Markuze"
 <amarkuze@redhat.com>, "Viacheslav Dubeyko" <slava@dubeyko.com>, "Li Nan"
 <magiclinan@didiglobal.com>, "Xiao Ni" <xiao@kernel.org>,
 <linux-raid@vger.kernel.org>, <ceph-devel@vger.kernel.org>, "Richard
 Weinberger" <richard@nod.at>, "Zhihao Cheng" <chengzhihao1@huawei.com>,
 <linux-mtd@lists.infradead.org>, "Baoquan He" <baoquan.he@linux.dev>,
 "Pasha Tatashin" <pasha.tatashin@soleen.com>, "Pratyush Yadav"
 <pratyush@kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, "Dave Young"
 <ruirui.yang@linux.dev>, "Shuah Khan" <skhan@linuxfoundation.org>,
 <kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>
To: =?utf-8?q?J=C3=BCrgen_Gro=C3=9F?= <jgross@suse.com>, "David Hildenbrand"
 <david@kernel.org>, "Matthew Wilcox (Oracle)" <willy@infradead.org>,
 "Andrew Morton" <akpm@linux-foundation.org>, "Muchun Song"
 <muchun.song@linux.dev>, "Lorenzo Stoakes" <ljs@kernel.org>, "Liam R.
 Howlett" <liam@infradead.org>, "Vlastimil Babka" <vbabka@kernel.org>, "Mike
 Rapoport" <rppt@kernel.org>, "Suren Baghdasaryan" <surenb@google.com>,
 "Michal Hocko" <mhocko@suse.com>, "Baolin Wang"
 <baolin.wang@linux.alibaba.com>, "Nico Pache" <nico.pache@linux.dev>, "Ryan
 Roberts" <ryan.roberts@arm.com>, "Dev Jain" <dev.jain@arm.com>, "Barry
 Song" <baohua@kernel.org>, "Lance Yang" <lance.yang@linux.dev>, "Usama
 Arif" <usama.arif@linux.dev>, "Gregory Price" <gourry@gourry.net>, "Ying
 Huang" <ying.huang@linux.alibaba.com>, "Alistair Popple"
 <apopple@nvidia.com>, "Johannes Weiner" <hannes@cmpxchg.org>, "Qi Zheng"
 <qi.zheng@linux.dev>, "Shakeel Butt" <shakeel.butt@linux.dev>, "Kairui
 Song" <kasong@tencent.com>
From: "Zi Yan" <ziy@nvidia.com>
X-Mailer: aerc 0.21.0
References: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com>
 <5ca4d0e4-1747-45a7-a916-a7516bb1692b@suse.com>
In-Reply-To: <5ca4d0e4-1747-45a7-a916-a7516bb1692b@suse.com>
X-ClientProxiedBy: BN1PR13CA0008.namprd13.prod.outlook.com
 (2603:10b6:408:e2::13) To IA0PR12MB8374.namprd12.prod.outlook.com
 (2603:10b6:208:40e::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|PH7PR12MB6935:EE_
X-MS-Office365-Filtering-Correlation-Id: 22480e3c-b594-45b3-2d38-08def18ae4af
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|23010399003|1800799024|7416014|376014|56012099006|10067099003|11063799006|4143699003|22082099003|18002099003|921020;
X-Microsoft-Antispam-Message-Info:
	FGtzsi0Ff3pxghP3lc/P1ddrXZKj3w8+yJGJxor6kKDLvhXg+qE0BqULU2Yo4OHklIfrWOBiiWaCcUZnd8ysXvfpjMQVyqBTVvH/b0Q17IDGUvQ8gt4J4mT1pT8nL+gY1FWLJGaajKiB9bLXL2OjTnlzpUnhjYKRFUTTC7RGTKyqFnabJILfF0z8AU4m783vOuMWi1tH6BS67AbjJ4dVCwGPtnKldp5SDaCm2TxXxeP2ZK6wfMDiS18Gr47k19fmlmm0ZUGj0jp67G22umHBdhIuM/sszkroYKwIza/1o1owYO9aVUG8Kv5LLxa3I2WUu8Ak6QcEoCd3A2d3jHYGJW/+RNZgWm8LAjH1uSwDiuMBOFm3gYnB13ZB1YWOVqPwQNKUBqw2XePEUHqKE4fOH9Olf52EBU/o/jip+pXcqLAnmKr38c1u8C6/5d3be9P/UcA7qVZ6LQVHh1HhK+V2a0F4TWz2ERZK7VcaT0nO+9jiux83RgoLv9ibtvBSCrNZX0SkURZ0XZaQ0oYH8g5uGiBx9GzWnhS4/uZIqjBS3kSthtIogVRo5UtaDQmHcm2QBw0H8x81CRrgqFRLK1h46fKWbpTQB7QQyeITnN19I+9mhcOVt1PKHVji0hhO+J6TgRKcsFzS5/DlUr/Fqyiazhpd1b+TgYpo1iieuX06GMveH1pyl1ECk5P3tuqWv1WNYZcGmnoPQLT79hKI5uGaSg==
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(7416014)(376014)(56012099006)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TXNoMVUva1pWRkd1aHNpSk54cGxMMXZJTnFmUUFPbkhLbnlRdVFGRC9Ueks3?=
 =?utf-8?B?aUZnZGZMSDNWdS96ZWJFRUNiQzRtejhxdjRJKzRyaGxHUVcwMy82UDRMWUhm?=
 =?utf-8?B?Q1VCeGJNT1YrbjFDa3pMRFp3WE9VekNKMG5TbXBaejhIK05pbXZwcEVjZjdr?=
 =?utf-8?B?TlRyV2JuRFZ6QVlaSm9iRWlPUjBTN1ZsTkwrcVcvdURjSXFlcXVHdm5rYVBy?=
 =?utf-8?B?cTYxazVUcVFFR3NvZU5jQUdjUEhHWVoyQzFvUTRUZDZJdjhRL0hPQ0llVnoy?=
 =?utf-8?B?ZXRCMzBQbWNteVRPemNMQ3hyTDNzN3UxU3ZkM3h3Rk9BQ1N3TTl1Zzl3NzE5?=
 =?utf-8?B?SHNIcDZ2S0RVRzNjVENoUVdWZzVXUDJpNzRockZoZjhzT1ROWXhxQjJtc0Nj?=
 =?utf-8?B?QTRHTTh4a1E5eGJuMWpwLzY3cko0bSs2WUlTQklTekE1Tm9qRVA3dFRmbmRS?=
 =?utf-8?B?d1Z1eUtZNmJ6aWlJbDBGNVVOb0JNMXdqbEg5eVZlYmJyakxzenB6cEt1OVA5?=
 =?utf-8?B?SFVBYTllZkhOQXlwU3JZend2NjNLVGxVWmt6b3FlandDdHJrZ3R1Y3N4RVNt?=
 =?utf-8?B?MHdCTmpsNTc3b3lLYnkySXlhZDVaQVZZQmZFTElscUdhakFGd2xibS9NajVV?=
 =?utf-8?B?TmxCYzk2bmIwLzZXWnF6NFhsMUFHTUZMMGN0R25vaFllczhkVXFaSVdtZyt3?=
 =?utf-8?B?MlJ4NXA4VFVaWUw5c1FvMXg0UWdLUkxKUk8vMWlBeUJ1M2k2NjlFcGc2RDc3?=
 =?utf-8?B?aGk1em1DbnFlSUN4b3Z0S2p0UlQ2dEdhRXJaZ0FhLzVkN2MxQS9tekRKS1ZR?=
 =?utf-8?B?Vy9tRkpMWmdaZ3hUcGtDL2lPTHN5YUFpa1JJY0N1Q2RCWVUvSXlCRFJpOEEy?=
 =?utf-8?B?YVFkb1RHaVVCcm9oNU1wTmp0ZHZDazQ3QkRoTDRwR2gvT1gwUW1VUzd1MTR3?=
 =?utf-8?B?dHBzZXdWOTkrck81QXRjUDVHOFo2ZUUvazRpc0xYSDd3MUg3V1FGZjV6dVA2?=
 =?utf-8?B?VlhRUHRaOGJ5SnlTT1d6WUV2TG5VdHA2R296TW5KZ2pnWGtxbFpqSTZDeC9p?=
 =?utf-8?B?TDE4TFRzMkwrMmhrR2h6dTZwb3hXYkxTMkl0Z0dtRmE1RFNtZDZ3eHpGdDVG?=
 =?utf-8?B?N1Q1SWRvQlZEQzhlUHhzSFMvc3JkaVliZG5OZlZySGkrYXl2UVlJZENtR2NX?=
 =?utf-8?B?dUc1cWNRYjhidlNzN0VOTFBwYUpwMytFRmJQejc4MXUxNnNWaTA0MytrYm1W?=
 =?utf-8?B?U0NCM0gxSlNZd0tiTnJoeTIzZGlxYmdVajdqeTFOYVdKcEYxQXhqdU9aVVVK?=
 =?utf-8?B?NDM0U0xSaTdBT3NrTWpxdTFldTdJblVLbGFvanBSTW92cVhBYmhINnFlNDY2?=
 =?utf-8?B?WWRPSGIrVUh6Mm5sY1RBS2huYkwxZlJnMkNmQ3pFUitwYUg5K2drOGhMZEJH?=
 =?utf-8?B?VFpldlFLdzN3NXJYNDVWa0hSaGxiaHpQWjJlTFcwNTVxbG1uWXdlcm1HS3dj?=
 =?utf-8?B?RXhNdkRSTGNxdUVhSENVeHB4eGZZeWFRbnZFczdZbFNNMkl6b3pjT2tiK01u?=
 =?utf-8?B?TGtwQXlxN3lIWitmTUpiL3Vyckw5cHdHQTZwT3NrR0t5ZEYxRERQZVZqd0hX?=
 =?utf-8?B?MlFiUTFCNkJ1UTJPTTl5MEkrS1d3U2hTQnN0TExUdUxodVVvelJ2VFFDb1ZH?=
 =?utf-8?B?cEJ2YnhIZGtRSVVSZjRoWFU3V1o3NytYOW5COXJ2dVR2aUNQMmVoaHg4ZEFy?=
 =?utf-8?B?TDhGTXpYUEZTVUM3dHA4SzhKYjR0ZVVVbEROa3BrR3VHYmRVRlVHYS9yU0xl?=
 =?utf-8?B?dzc5bUlPWjM2R0Yvdm4rc0xLRnZZd3hYbnFDVG9BeEN6b2dqa3dQVDlHV3g1?=
 =?utf-8?B?dTBhWGpyVStjODlOYmJlUkJjVVM3WS8yaUtpaGhDN2M5UjhlR01qZGdVdmRZ?=
 =?utf-8?B?RHVuZHB2K2FFQ0tPSXFLdW10cVZsQ3ljSGNIbm9GaGlzb0lETi9WcmZ0ZHZC?=
 =?utf-8?B?cGJpQnpFUmpLc3UrRDNMVi9kaHloUUVhdjhTb2I5dUNWVFc3MlZkbmk0Z012?=
 =?utf-8?B?MmtxVUJOSnRBTElMVGNQeUJaOXhDbGNrSElrdFQ5VnAycDRrS1c5QVZ3VXF2?=
 =?utf-8?B?NGd2TXhnK25kNFhtdUwzU3RoWE1BaHpnNzYwVW9nek93dXJNaHhNMEo1QlFz?=
 =?utf-8?B?Q3haWDFpZkhkL0FXRlpsQzFLUzZiSHRYYTlvUWRXbmRVY0tpRDFORG9CaDBj?=
 =?utf-8?B?OE9CVlZrcFRhWDhTQlZ6c0Fnc3BRdmRZeHZQcWhDbFJaZlFrcUxFZTRtVVJl?=
 =?utf-8?Q?vOMDLuS+uZ6B+uZb7U?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22480e3c-b594-45b3-2d38-08def18ae4af
X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 18:13:17.9727
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: P4jLnqIwTNmEW1LtTpM+2MhjKsFG8QpvIYdQ6DM5UZU3RRUlEMTS746tqky9GXuA
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6935
X-purgate-ID: tlsNG-33051d/1785780808-6C2E04E9-3D22F222/0/0
X-purgate-type: clean
X-purgate-size: 1339

On Mon Aug 3, 2026 at 5:07 AM EDT, J=C3=BCrgen Gro=C3=9F wrote:
> On 01.08.26 04:13, Zi Yan wrote:
>> Hi all,
>>=20
>> This patchset removes PG_private to make space for upcoming PG_folio
>> (reserved as __PG_folio) for identifying pages from a folio (more detail=
s
>> in Note below). Instead of checking PG_private, all code is changed to
>> check page/folio->private !=3D NULL instead.
>
> I'm a little bit worried that page/folio->private is in a union, so today
> it could (in theory) be !=3D NULL while PG_private isn't set.
>
> Is it really not possible to enter a path where PG_private is tested whil=
e
> page/folio->private !=3D NULL due to the union being used otherwise (PG_p=
rivate
> not set)?

Yes, it is possible. See: #5 in the exceptional users: erofs uses
->private for reverse linked list and in-flight counters without setting
PG_private. I get rid of the first one and converted the second one to
use folio_attach/detach/get_private() to follow the general ->private
use pattern..

For non file system folios, anon swapcache puts swap_entry_t in
->private and hugetlb puts its flags in ->private. I added
folio_test_fs_private() to exclude them, but this helper is planned to
be used by core MM, since filesystem code should not encounter these
two.


--=20
Best Regards,
Yan, Zi



From xen-devel-bounces@lists.xenproject.org Mon Aug 03 18:47:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 18:47:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381762.1625287 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqxh3-0003pK-My; Mon, 03 Aug 2026 18:47:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381762.1625287; Mon, 03 Aug 2026 18:47:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqxh3-0003pD-KQ; Mon, 03 Aug 2026 18:47:21 +0000
Received: by outflank-mailman (input) for mailman id 1381762;
 Mon, 03 Aug 2026 18:47:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wqxh2-0003p7-85
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 18:47:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqxh0-00Fim2-BI
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 20:47:18 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a70e22d-5cb7-0a2a0a5109dd-0a2a45038af8-6
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 20:47:18 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a70e235-fae8-0a2a45030019-a0658308bfc6-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 20:47:18 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id EE4E9440E018;
 Mon,  3 Aug 2026 14:45:39 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	jason.andryuk@amd.com,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: Re: [PATCH v2] nSVM: Check injected event consistency 
Date: Mon,  3 Aug 2026 19:44:09 +0100
Message-ID: <20260803184412.2323732-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <c99c9645-4ffe-43e3-a56e-1a0c6efc006e@suse.com>
References: <c99c9645-4ffe-43e3-a56e-1a0c6efc006e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785782838-6ECCB4E9-95CB2077/0/0
X-purgate-type: clean
X-purgate-size: 2194

On 03.08.2026 07:12, Jan Beulich wrote:
>On 31.07.2026 16:26, Abdelkareem Abdelsaamad wrote:
>> On 28.07.2026 14:04, Teddy Astie wrote:
>>> On 16.07.2026 17:41, Abdelkareem Abdelsaamad wrote:
>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c
>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c
>>>> @@ -320,6 +320,31 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
>>>>       svm_dump_sel("  TR", &vmcb->tr);
>>>>   }
>>>>   
>>>> +static bool is_valid_svm_vmcb_injected_exception_vector(
>>>> +    const struct vmcb_struct *vmcb, uint8_t vmcb_injected_vector)
>>>> +{
>>>> +    return ( (vmcb_injected_vector == X86_EXC_DE) ||
>>>> +             (vmcb_injected_vector == X86_EXC_DB) ||
>>>> +             (vmcb_injected_vector == X86_EXC_BP) ||
>>>> +             (vmcb_injected_vector == X86_EXC_OF) ||
>>>> +             (vmcb_injected_vector == X86_EXC_BR) ||
>>>
>>> This particular exception is special. AMD APM states that this event is 
>>> "impossible" if the guest is in 64-bit mode and will cause 
>>> VMEXIT_INVALID in such case.
>>>
>>>> If the VMM attempts to inject an event that is impossible for the 
>>> guest mode (e.g., a #BR exception when the guest is in 64-bit mode), the 
>>> event injection will fail and no guest state instructions will be 
>>> executed; VMRUN will immediately exit with an error code of VMEXIT_INVALID.
>>>
>>> So this one likely want a additional check for hvm_guest_x86_mode() != 
>>> X86_MODE_64BIT.
>>>
>>> It looks like #OF has the same quirk (invalid in 64-bits mode).
>>>
>> I agree your point is valid. I will address in V3.
>>> Though I don't know if any other exception has a similar behavior though.
>> I have double-checked the APM vOL3(24594—Rev. 3.37—jULY 2025) regarding the
>> other exception vectors and instructions. Vector 4 (#OF) and vector 5 (#BR) are
>> unique because their triggering instructions BOUND and INTO are invalid and
>> disabled in 64-bit mode, making them structurally invalid. Other vectors remain
>> legal across the other modes.

>#BR is also used by MPX insns, which are usable from 64-bit mode.
I think this is only relevant to Intel's VMX, not AMD's SVM.
>Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 03 21:02:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Aug 2026 21:02:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381811.1625297 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqznJ-0000sm-S6; Mon, 03 Aug 2026 21:01:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381811.1625297; Mon, 03 Aug 2026 21:01:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wqznJ-0000sf-PQ; Mon, 03 Aug 2026 21:01:57 +0000
Received: by outflank-mailman (input) for mailman id 1381811;
 Mon, 03 Aug 2026 21:01:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wqznH-0000sD-Gl
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 21:01:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wqznF-001NVQ-Q0
 for xen-devel@lists.xenproject.org; Mon, 03 Aug 2026 23:01:53 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a71019e-2eae-0a2a0a5409dd-0a2a450cb198-44
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 23:01:53 +0200
Received: from [52.101.57.43]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a7101bf-f479-0a2a450c0019-3465392b139c-3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 23:01:52 +0200
Received: from CH0PR03CA0205.namprd03.prod.outlook.com (2603:10b6:610:e4::30)
 by SJ0PR12MB8140.namprd12.prod.outlook.com (2603:10b6:a03:4e3::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Mon, 3 Aug
 2026 21:01:44 +0000
Received: from CH3PEPF00000013.namprd21.prod.outlook.com
 (2603:10b6:610:e4:cafe::d) by CH0PR03CA0205.outlook.office365.com
 (2603:10b6:610:e4::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.270.18 via Frontend Transport; Mon, 3
 Aug 2026 21:01:44 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH3PEPF00000013.mail.protection.outlook.com (10.167.244.118) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.0 via Frontend Transport; Mon, 3 Aug 2026 21:01:44 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Mon, 3 Aug
 2026 16:01:44 -0500
Received: from [172.19.79.34] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Mon, 3 Aug 2026 16:01:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iTyKZXx5jeJeCIi21orKLBttZSXFVh0ZEMjO0I+DB6YmoLYd6LMI8tVdAhZxRvNsv/EGXNeQ0Gj9H11Q+3nRYo5IwgyRqRFPa7GMSwEbcxOHgbCgZbI7mBEA43mUrQHYofkxt+npcB+zezD6Z+bvzO9WiHtpoFVObp5nqCa1oZg5nD8vtdowIy4lAkTslVCBiEElcwQ8iU0Pl1qUns8dfadfyG1JZzHCFsIYC1X1nlFl8GSNhNYBAL6vIyARdC+sfU+EotK03WTPNVZZzrNpC48uf9OYhkRScD4PYN3RIPk33IxiSTwC8GA/LfCK1Pj4jEBEzqF5LV/KFVuTZKaBUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8aPzKaT4Ch3aMYTEO4glCQqrnHCy3HTBrxMY75ZeYh0=;
 b=e7mlNv3pYLMg2wFj7zcCh5jn4eznJPSXZOO8lZrtixXJXfpv9NXrCxoSjhgFJMxCkGoEkhM+D1F1KIBqtS74pbXZeZUb0BGxnuF6O5VYoweDP+vyXZVxiLVLyhsf63NTR+LSJFlXeX9cbD7ZryVCAeGV9uzyseO+ITNO8VH6N1Rth6+YABxqM4BZlsrTu0+BUjdElKwVZLY7yGi79HIKBWOeVXxa4PxWZfxg9mfv27KtiZGJ1pwGXN6/Bswqg/6cQjd3nRL/XST8WPriUsTWApdGU27ZXHZUnC4FWL7zgUXSOnA8QxjujGfOxHF4QPu1dZfuDUYozTV02166hWsKeQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8aPzKaT4Ch3aMYTEO4glCQqrnHCy3HTBrxMY75ZeYh0=;
 b=2kEkQtYQXO5+nEB8js2YM3LTGgVD244sIbWyTHVhDnBBl7FGt0eB2tEEZ08xgLufigu0O7lhLo10ej2/VfY/kMFtnj1g9HzqPcokmfyCEpI4HRzm52ymLBVJZv2AhuoOGtvYLDF4txDLsIiWjBldVyLqLLiPhzYuiG7XYa450Jc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <bbc2fb48-d79e-4f00-81b4-0170dd910aaa@amd.com>
Date: Mon, 3 Aug 2026 17:01:43 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Daniel Smith <dpsmith@apertussolutions.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF00000013:EE_|SJ0PR12MB8140:EE_
X-MS-Office365-Filtering-Correlation-Id: af729bf2-2f5f-4cdd-3855-08def1a26cb1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700016|23010399003|376014|4143699003|56012099006|11063799006|10067099003|18002099003|22082099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	t1fDly2XTT0moDZX478LchSyX7SBgmm3cYknyOLVHAAfgXbCkTnAZfNLtY2gOtxp3wxrTuN7r44Zn9e+Ct+jOWN1df1SkbxUZJZ879k6QP27JT3ZdjUgSQoK5nzSShh1vu7W5Zo+xQnbQ5fpS58R2YAhE+UiMXRVV+tJgEdLonrqaBR9+3nKD65LmLf4k50P1ctmFhIXp28j0dj98cW6hYOtjMAUs+ID6sP32HzEAQNTqQL6utoTZWSoXMMcU2rjP2gJ2xc9lVUQkvI7qh907SVJmqTXCNMMrikF8GSQdlj/CNbms3oWu7js/vgndSblPoqv2R7IQc4YNPjFeVCCGQH9ONw3oGleOpb7adHvPYYbGtkm+voZSg0AIpW26Z5HnLb+ICQ2JhDbZcQOSyKVoyuw7LFYo3xr1j3VHseXwA131g5HttQd2VN6Zm0ufKXQu+J2ZqhtqffO4ZDO6eN3AgVlwrr8RhP9YMGzTfEEBRiDmALX2csFUucFWsLjrDFe4iRG3PSUu+xDH97YOU+ggAlo/Vyt5+CsOtALAduGeRuYijlHS3jgDftAxT9FMyFvbYwzS0gVu0jlmj0DA2oJXuwFEJRi3jJeo1SubPR0Jbu2DKtz/oHsw0sqyZBjMaGGQfHe7OpHI/mGN8Dq2oX7kCkkxT9iQV044rYTPJZo4LMHilNF8JGbs77gCfyeXdE/9df+kQELy0WoFHLaQsitQQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(23010399003)(376014)(4143699003)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	lx8CjabBpQ9+DPM4RDKSkLBF+bih6AFioW/MOTJtFRMkdRCdZFJPYIeldvHZYU/Q6UEHuGTKZXy1hRxUeVkSRFjuH6yPuFKvQQL4FdFMCrBAZ8IiCKl8xF1B8Cy/gsKvPZ6NGJ7/kF9cA6M4NqemhThOStWj9F5OoEDQkCf1jpO1an3yrYhHbyQGrsBYglan2uGijgJzDai9SKxnvfC5KlhnWFmbiVfMpQN9y6qZofYFNFqwvxVbufpYGe8kIFWiAYL23a+PCY7mMTZq5+0mVYlkrxF3574TtW4pMrXRfRlU/l1ExLcnL3kZjVjYDAYQMz5YiMigCBdVrcjdYqhbWQ0nfSZFpVKUQ8s74a/I6X3ptvYpaHUYMRCOu/PVETmKvBhWKyXx8yfXEiNwo3g0MV8zBBs1CMe9dBGCewJFRr42rZWsXQ8/cScmaiWsPfAE
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2026 21:01:44.3467
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: af729bf2-2f5f-4cdd-3855-08def1a26cb1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF00000013.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8140
X-purgate-ID: tlsNG-d25034/1785790913-77ED2A5B-A1409A0E/0/0
X-purgate-type: clean
X-purgate-size: 2449

On 2026-07-28 09:22, Jan Beulich wrote:
> For whatever reason they didn't have an xsm_default_t first argument (to
> cope with XSM=n mode), making it impossible to (easily) cover them in
> xsm/hooks.h.
> 
> To be able to retain the const on their function parameters, adjust
> xsm_default_action() accordingly.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h

> @@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
>   #endif
>   
>   #ifdef CONFIG_ARGO
> -static XSM_INLINE int xsm_argo_enable(const struct domain *d)
> +
> +static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, current->domain, d);

This one I think should be
     return xsm_default_action(action, d, NULL);

Usually current is passed in for the check, but for domain_create() -> 
argo_init() it is the under-construction domain.
>   }
>   
>   static XSM_INLINE int xsm_argo_register_single_source(
> -    const struct domain *d, const struct domain *t)
> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, d, t);
>   }
>   
>   static XSM_INLINE int xsm_argo_register_any_source(
> -    const struct domain *d)
> +    XSM_DEFAULT_ARG const struct domain *d)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, current->domain, d);

Similarly:
     return xsm_default_action(action, d, NULL);

The single call is:
xsm_argo_register_any_source(currd);

These argo hooks all pass in their arguments explicitly, so I think we 
should do that and not use current.  (The send and register hooks could 
use current, and that could make sense as those map to hypercalls.  But 
it is correct today with the explicit arguments.)

With the changes:
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks,
Jason

>   }
>   
>   static XSM_INLINE int xsm_argo_send(
> -    const struct domain *d, const struct domain *t)
> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, d, t);
>   }
>   
>   #endif /* CONFIG_ARGO */


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 00:54:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 00:54:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381834.1625307 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr3Pk-0004J7-5y; Tue, 04 Aug 2026 00:53:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381834.1625307; Tue, 04 Aug 2026 00:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr3Pj-0004Iz-Vu; Tue, 04 Aug 2026 00:53:51 +0000
Received: by outflank-mailman (input) for mailman id 1381834;
 Tue, 04 Aug 2026 00:53:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3GzhxagYKCaocOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@flex--seanjc.bounces.google.com>)
 id 1wr3Pj-0004It-Lk
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 00:53:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr3Pi-001mWE-5c
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 02:53:50 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3GzhxagYKCaocOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@flex--seanjc.bounces.google.com>)
 id 6a713812-2eae-0a2a0a5409dd-0a2a45098ad0-14
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 02:53:50 +0200
Received: from [209.85.215.199] (helo=mail-pg1-f199.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3GzhxagYKCaocOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@flex--seanjc.bounces.google.com>)
 id 6a71381c-be1a-0a2a45090019-d155d7c7d942-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 02:53:49 +0200
Received: by mail-pg1-f199.google.com with SMTP id
 41be03b00d2f7-cb4bd11ddf8so4700936a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 17:53:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1785804828; x=1786409628; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=KFqZcLCrY5f3+v3uGjD/c1GxsX1WczytwYYei8eRc4I=;
        b=DTnJdb9gae+0dN3jsn5oTQ3E3AxFA628rxnLCUMIiK8+IaZHNvxiQXiFQeNiVHhYE2
         OhRuw1tvmfhlI1LCFqPPBWvhe2VLiJSi8Xhgtsp9PRuJ0sOS53kuIEpPUR2m0RrNYOOF
         5RsVSlelNxwEfgEQlIMqRMvfd//SZAkJF67Dm/N/L6Nr9XTBY0mfKgv6G0dLlq6h5Fnv
         S+kV7bD/EQTDaIPLT/oNi99wbOSKGvJ3J3DomB6omQu9WxBAJlUdn3IT9Oh7iM1V5INp
         G0CbyaMd7brI4VrDNBxDXgu7vRNQsjo2hgYM607edcFCrcK3sbPKhy0LpPKRvKpoR88j
         cMdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785804828; x=1786409628;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=KFqZcLCrY5f3+v3uGjD/c1GxsX1WczytwYYei8eRc4I=;
        b=eurGQBdyhYZ9u3J2Rl7d3Ln6Z+FwLbE0yvwZzw1SYwfnFoc7JopJxdmUEfzvO2929Z
         6M+r4Aq7/O3ZakPtVcv8EBwK/9APnz1XLwyBwrSL5ouORwpwhUPjbFwNy5t5XPW6ERN1
         iHTLhlhKmRNbE01XXp5V9Hiu4v0Htj9Eg2RXLKv7yzONRO6dlrn7GY5sycgjLAg3C9bK
         +4tjeAyIzBaIGPNTL6W1IJoZbo22stLRZeXjxZUCcCgXbgDAn9aln9twuKdE7lduKWQh
         ttxVMsEl9aOGW6pfHGmiOeFuDhpB6KjVoezdT0seHbHOWKK/wZjtHsHvnJyDp28h/Rt5
         t3oQ==
X-Forwarded-Encrypted: i=1; AHgh+RpkvQwrVHLLLWD2Yb8FGplbz22fU8B6SXi/+wywrYuppUCq+G30WUqk6UXYanABMytsqiFNMefe5Mw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw4cLgI6bz88oBQp0/ektlHLPW96LcN3cn14C4LfgjJWPLjFHa8
	BE3zlOBDV7c26HS3Popw8fByd7zP+Y7enxuUbsMG7D/ZLGSE5d6cpsiPN3ExZu+BqPK5vk0zvUb
	aMaq5WA==
X-Received: from pgke23.prod.google.com ([2002:a63:f557:0:b0:c85:98b1:c613])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:3397:b0:3c3:a140:9392
 with SMTP id adf61e73a8af0-3c92a28f176mr12976405637.0.1785804827335; Mon, 03
 Aug 2026 17:53:47 -0700 (PDT)
Date: Mon, 3 Aug 2026 17:53:46 -0700
In-Reply-To: <8b90851f38ef5b10cdcdc70e7543bd6b0b5e2773.camel@infradead.org>
Mime-Version: 1.0
References: <178552799129.2700794.10181439022561913222.b4-ty@google.com> <8b90851f38ef5b10cdcdc70e7543bd6b0b5e2773.camel@infradead.org>
Message-ID: <anE4GtMa33nz7qdK@google.com>
Subject: Re: [PATCH v6 00/36] Cleaning up the KVM clock mess
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-bad1c0/1785804830-BCECE034-7A1A16D9/0/0
X-purgate-type: clean
X-purgate-size: 1522

On Sat, Aug 01, 2026, David Woodhouse wrote:
> On Fri, 2026-07-31 at 13:09 -0700, Sean Christopherson wrote:
> > Applied patch 1 to kvm-x86 clocks.
> >
> > [01/36] KVM: x86/xen: Do not corrupt KVM clock in kvm_xen_shared_info_init()
> >         https://github.com/kvm-x86/linux/commit/3d4b20b5a7df
> 
> Thanks. Could the clocks branch be based on something that includes the
> timekeeping work from the timers-ptp-2026-06-13 merge (in v7.2-rc1)?

Yeah, I can rebase onto a 7.2-rcN.  Y'all are likely the only people that care
about the above commit, so a late rebase isn't a big deal.

There's basically zero chance I'll get the entire series applied for 7.3, but
"Use ktime_get_snapshot_id() for master clock" is at least in striking distance,
so there's no reason not to allow for the possibility.

> The later parts of the series depend on ktime_get_snapshot_id() and the
> reworked struct system_time_snapshot from there. Your kvm-x86/next
> branch does have it; I'll keep my WIP kvmclock8 branch based on that
> for now as I address the other comments.
> 
> 
> *   2d6d57f889f3 Merge tag 'timers-ptp-2026-06-13' of tip
> |\
> | * bc484a509673 ptp: vmclock: Use hw_cycles from snapshot for precise TSC pairing
> | ...
> | * ca1ec8bfac8c timekeeping: Add clocksource read_snapshot() method and hw_cycles to snapshot
> | ...
> | * ef22786707e3 timekeeping: Use system_time_snapshot::systime/monoraw instead of ::real/raw
> | * eba302268a01 timekeeping: Provide ktime_get_snapshot_id()




From xen-devel-bounces@lists.xenproject.org Tue Aug 04 01:26:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 01:26:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381844.1625314 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr3v3-0000X4-FM; Tue, 04 Aug 2026 01:26:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381844.1625314; Tue, 04 Aug 2026 01:26:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr3v3-0000Ww-C0; Tue, 04 Aug 2026 01:26:13 +0000
Received: by outflank-mailman (input) for mailman id 1381844;
 Tue, 04 Aug 2026 01:26:12 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3sD9xagYKCU89vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--seanjc.bounces.google.com>)
 id 1wr3v2-0000Wq-He
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 01:26:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr3v1-00CvVm-7u
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 03:26:11 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3sD9xagYKCU89vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--seanjc.bounces.google.com>)
 id 6a713f9c-bab6-0a2a0a5309dd-0a2a4502e7c8-16
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 03:26:11 +0200
Received: from [209.85.215.198] (helo=mail-pg1-f198.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3sD9xagYKCU89vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--seanjc.bounces.google.com>)
 id 6a713fb1-6ca4-0a2a45020019-d155d7c6c1e2-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 03:26:11 +0200
Received: by mail-pg1-f198.google.com with SMTP id
 41be03b00d2f7-cbb6433e9d4so5366091a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 18:26:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1785806769; x=1786411569; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=6RexsWdhj3mVsIfZtSBkyTeZ2lUaorlH2urK3kzEKiI=;
        b=LQ5wEqUBm3MDYN6aB73gurgjp8JaXG4ZJ2nvHxYEF9wurXESSukvRYuRg2Lsjq9f1D
         iYAodCQaNtVIQTBRVjdpNX/Vm60uiYIkObBVyF0rzG/3L9ZyDut5IxcfLB+NEE1iEw4n
         JRPCgEn48zeysyOCWuR6hHd05E+wA26w3rOk+GHlcLFSIFo2qCJPD0KX2l1r5B4Wca6j
         VXvXUPNojf9AVnduoyfSngUBimCGQieyR0CfUi5q7h/8YXU6H4akzMa78z5UOjOC6O57
         1Fx8GxHCSMnw31VBCpoJx7dg0pdYYgKn+fFK77M4ZKB4P/y7aQRS8wRJ0oYL9HEs0sUD
         tHGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785806769; x=1786411569;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=6RexsWdhj3mVsIfZtSBkyTeZ2lUaorlH2urK3kzEKiI=;
        b=lEkAI3boh2PF0SO7aliqQazqZZ+8tz10XGXFQZARKttHXIQ5uXq27WSW/Mn7LUKfN1
         UuM8HBW4cnfhzmaahotC3gSO6H6x4BJaTPAKItezGoK4xqtqEbLMqoLXdPWDnEsic0rB
         GvjHT1CdVT4xL4r0ohfNIdtHJ46YybmbTaL7hBPa6+RdMMUdkdCIEzYD5wkMOVb/nDJj
         pxBB7W4+xa6vZbN58FJ6aauMoxujOcVR4UzvlPf5Y8BujZQaONjLPdY1Kii8pbYGpiiw
         wnvBrWnMz1mDiu2Dy8J1Tit3gPgQj8aJRz06LS67iCefK17z2fJXpxpT1sMIID9rs4YP
         JtxQ==
X-Forwarded-Encrypted: i=1; AHgh+RpRy4DpdcLATkPmfEs++AwTppcQcfNyiuXsQXRgmOu/2vY701zUz/eqqBtf4WD4NgB6Qtgtubvt9AU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfsZQox8P32pPgS9WS0Gf6mAHWNEi2Jnx3frCkxznz/L0bFMxS
	Fx7v7zLkNidP0dRg2lxno3ks7r1u8ek9s3zGJ4ilGn9tJTRbWntGO6YN6BPoy61p7VP2V6Pt8N6
	W2+f3Gg==
X-Received: from pgvt1.prod.google.com ([2002:a65:64c1:0:b0:c9e:63b8:11b5])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:6cc4:b0:3b4:61f:1fec
 with SMTP id adf61e73a8af0-3c92a4c4549mr11840955637.2.1785806768677; Mon, 03
 Aug 2026 18:26:08 -0700 (PDT)
Date: Mon, 3 Aug 2026 18:26:08 -0700
In-Reply-To: <20260728144954.355376-12-dwmw2@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-12-dwmw2@infradead.org>
Message-ID: <anE_sD1a0ycJBAEv@google.com>
Subject: Re: [PATCH v7 11/36] KVM: x86: Restructure kvm_guest_time_update()
 for TSC upscaling
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-720697/1785806771-319CB2AC-62EB56ED/0/0
X-purgate-type: clean
X-purgate-size: 7127

On Tue, Jul 28, 2026, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Restructure kvm_guest_time_update() so that kernel_ns/host_tsc are
> always "now" when doing TSC catchup, then swap in the master clock
> reference values afterward for the hv_clock.
> 
> This makes the TSC upscaling code considerably simpler: the catchup
> adjustment is computed as the delta between what the guest TSC *should*
> be at "now" and what it actually is, rather than mixing "now" and
> "master clock reference" timestamps.
> 
> The seqcount loop now also contains the kvm_get_time_and_clockread()
> call (matching get_kvmclock's pattern).
> 
> Based on a suggestion by Sean Christopherson.

Looking at this with fresh eyes, it wasn't a very good suggestion.  In addition
to the goof Sashiko reported, propagating master_host_tsc/master_kernel_ns to
host_tsc/kernel_ns is completely unnecessary and convoluted, it's much easier to
simply use master_{host_tsc,kernel_ns} when stuffing hv_clock.

> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
>  arch/x86/kvm/x86.c | 78 ++++++++++++++++++++++++++++++++--------------
>  1 file changed, 54 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 52c9268007f8..12c3d7d503ca 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1793,45 +1793,60 @@ static void kvm_setup_guest_pvclock(struct pvclock_vcpu_time_info *ref_hv_clock,
>  int kvm_guest_time_update(struct kvm_vcpu *v)
>  {
>  	struct pvclock_vcpu_time_info hv_clock = {};
> -	unsigned long flags;
>  	u64 tgt_tsc_hz;
>  	unsigned seq;
>  	struct kvm_vcpu_arch *vcpu = &v->arch;
>  	struct kvm_arch *ka = &v->kvm->arch;
>  	s64 kernel_ns;
>  	u64 tsc_timestamp, host_tsc;
> +	u64 master_host_tsc = 0;
> +	s64 master_kernel_ns = 0;
> +	s64 kvmclock_offset = 0;
>  	bool use_master_clock;
>  
> -	kernel_ns = 0;
> -	host_tsc = 0;
> -
>  	/*
>  	 * If the host uses TSC clock, then passthrough TSC as stable
>  	 * to the guest.
>  	 */
>  	do {
>  		seq = read_seqcount_begin(&ka->pvclock_sc);
> +
>  		use_master_clock = ka->use_master_clock;
> +
> +		/*
> +		 * The TSC read and the call to get_cpu_tsc_khz() must happen
> +		 * on the same CPU.
> +		 */
> +		get_cpu();
> +
> +		tgt_tsc_hz = (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
> +
> +#ifdef CONFIG_X86_64
> +		if (use_master_clock &&
> +		    !kvm_get_time_and_clockread(&kernel_ns, &host_tsc) &&
> +		    !read_seqcount_retry(&ka->pvclock_sc, seq))
> +			use_master_clock = false;
> +#endif

Actually, the entire use_master_clock code can be thrown under CONFIG_X86_64=y
(in a separate prep patch).

> @@ -1841,17 +1856,32 @@ int kvm_guest_time_update(struct kvm_vcpu *v)
>  	 *      entry to avoid unknown leaps of TSC even when running
>  	 *      again on the same CPU.  This may cause apparent elapsed
>  	 *      time to disappear, and the guest to stand still or run
> -	 *	very slowly.
> +	 *      very slowly.
>  	 */
>  	if (vcpu->tsc_catchup) {
> -		u64 tsc = compute_guest_tsc(v, kernel_ns);
> -		if (tsc > tsc_timestamp) {
> -			adjust_tsc_offset_guest(v, tsc - tsc_timestamp);
> -			tsc_timestamp = tsc;
> -		}
> +		s64 adjustment;
> +
> +		/*
> +		 * Calculate the delta between what the guest TSC *should* be
> +		 * and what it actually is according to kvm_read_l1_tsc().
> +		 */
> +		adjustment = compute_guest_tsc(v, kernel_ns) -
> +			     kvm_read_l1_tsc(v, host_tsc);
> +		if (adjustment > 0)
> +			adjust_tsc_offset_guest(v, adjustment);
>  	}
>  
> -	local_irq_restore(flags);
> +	/*
> +	 * Now that TSC upscaling is out of the way, the remaining calculations
> +	 * are all relative to the reference time that's placed in hv_clock.
> +	 * If the master clock is NOT in use, the reference time is "now".  If
> +	 * master clock is in use, the reference time comes from there.
> +	 */
> +	if (use_master_clock) {
> +		host_tsc = master_host_tsc;
> +		kernel_ns = master_kernel_ns;
> +	}
> +	tsc_timestamp = kvm_read_l1_tsc(v, host_tsc);

And the big reason my suggestion was bad: this is wrong for vcpu->last_guest_tsc,
because vcpu->last_guest_tsc needs to be updated to "now" (it's the same TSC
that's shoved into TSC_OFFSET in the tsc_catchup path).

This is what I have locally for the change this patch really cares about.  This,
and several prep cleanup patches, pass your selftests with the rest of the series
piled on top.

Assuming my other testing doesn't explode, I'll get a sub-series through
"KVM: x86: Remove implicit rdtsc() from kvm_compute_l1_tsc_offset()" posted
tomorrow, with the plan of landing all of that in 7.3.  That'd leave about half
the patches for 7.4, which certainly isn't ideal, but it's not too shabby either.

---
 arch/x86/kvm/x86.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 793340292d39..e826d1f8cabe 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1796,12 +1796,11 @@ static void kvm_setup_guest_pvclock(struct pvclock_vcpu_time_info *ref_hv_clock,
 
 int kvm_guest_time_update(struct kvm_vcpu *v)
 {
+	u64 tgt_tsc_hz, tsc_timestamp, host_tsc, master_tsc, master_ns;
 	struct kvm_arch *ka __maybe_unused = &v->kvm->arch;
 	struct pvclock_vcpu_time_info hv_clock = {};
-	u64 tgt_tsc_hz;
 	struct kvm_vcpu_arch *vcpu = &v->arch;
 	s64 kernel_ns;
-	u64 tsc_timestamp, host_tsc;
 
 	/*
 	 * If the host uses TSC clock, then passthrough TSC as stable
@@ -1814,10 +1813,16 @@ int kvm_guest_time_update(struct kvm_vcpu *v)
 	do {
 		seq = read_seqcount_begin(&ka->pvclock_sc);
 		use_master_clock = ka->use_master_clock;
-		if (use_master_clock) {
-			host_tsc = ka->master_cycle_now;
-			kernel_ns = ka->master_kernel_ns;
+		if (!use_master_clock)
+			continue;
+
+		if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) {
+			use_master_clock = false;
+			continue;
 		}
+
+		master_tsc = ka->master_cycle_now;
+		master_ns = ka->master_kernel_ns;
 	} while (read_seqcount_retry(&ka->pvclock_sc, seq));
 #else
 	const bool use_master_clock = false;
@@ -1883,8 +1888,18 @@ int kvm_guest_time_update(struct kvm_vcpu *v)
 
 	hv_clock.tsc_shift = vcpu->pvclock_tsc_shift;
 	hv_clock.tsc_to_system_mul = vcpu->pvclock_tsc_mul;
-	hv_clock.tsc_timestamp = tsc_timestamp;
-	hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
+	/*
+	 * If the master clock is NOT in use, the reference time placed in the
+	 * hv_clock is "now".  If master clock is in use, the reference time is
+	 * the master clock's snapshot from some time in the past, not "now".
+	 */
+	if (use_master_clock) {
+		hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, master_tsc);
+		hv_clock.system_time = master_ns + v->kvm->arch.kvmclock_offset;
+	} else {
+		hv_clock.tsc_timestamp = tsc_timestamp;
+		hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
+	}
 
 	/* If the host uses TSC clocksource, then it is stable */
 	hv_clock.flags = 0;
-- 


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 05:54:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 05:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381882.1625324 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr86n-00007I-KZ; Tue, 04 Aug 2026 05:54:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381882.1625324; Tue, 04 Aug 2026 05:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr86n-000078-Ga; Tue, 04 Aug 2026 05:54:37 +0000
Received: by outflank-mailman (input) for mailman id 1381882;
 Tue, 04 Aug 2026 05:54:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wr86m-000072-8i
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 05:54:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr86k-00DoFh-Vo
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:54:34 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a717e9a-5cb7-0a2a0a5109dd-0a2a4506a80c-4
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:54:34 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a717e9a-195a-0a2a45060019-d155dd36b8d1-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:54:34 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-47362928f65so3965165f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 22:54:34 -0700 (PDT)
Received: from notebook.. ([78.173.117.189]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a100e14sm55453775e9.14.2026.08.03.22.54.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 22:54:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785822874; x=1786427674; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=0vVyXrNs9xN2FQ9GoJBozZev2DVipZjRBvvshex9mY0=;
        b=fM+wfhklcbhwjMZpKXXkcO4EN89o4knpSzTw5uZMu34KsJ3nettbBIvsx555K0URED
         WkSA4SyvM+6xXGg55f4BMDCOpHG6uBmJqdEQm1u7AodoM2cip9tT7WK3DWF0I1GxXtVM
         Mrf4P0eTyVWh90lgmsQMrBJaH/WbT+/mqSpD5QTqsEcimzF7J3xwjBNb+S57n/o11H8q
         zZHlvGfB4vDsdgbcALuEEHqe6Y2Alq+wcHxqGBXc/KQu1BmaYjacpbX7B9gN/aTPf1ch
         YYZsyaLgPHhgaFXdWiKqi21LCOh1aqEWydtMEFrXbldWlGJhW7/6ox460CgWVzCAJADC
         YyNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785822874; x=1786427674;
        h=content-transfer-encoding:mime-version: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=0vVyXrNs9xN2FQ9GoJBozZev2DVipZjRBvvshex9mY0=;
        b=SnlUlAQUVSrPPi3eC20QKIu+4tCOGrnVWrNLPUr0+ErSvufTmbKj8keHensrL2xPRc
         PVQcMMrtAFbxRYBtVZFDeB2p+dN6/cB75G+gXNGhFAuEnVPkrs4WbzUX5nqeFNIjEU+5
         GYcqqyroSKyGv6eX0jpCDIyZA/yv8EFdebPM2JDZ475/+pb/717yfJvWyGSE0tfR9eaT
         1XltuxN76fsruk7QSW3Biaf2erJtfbS1uldCABKy8OfCoE4qRNx2Efi79osu33cXE1WL
         6vnzSieorMret515CqvmLV+869H51MVzAkLG5XGBbhfEbtLkFPHO+uEQYFLSl3ksmQky
         ziXw==
X-Gm-Message-State: AOJu0YwNTyYxp7WEdSZee6GlufbjbtvGSTZ4Mwu4xq9ParEoVqY8ocIt
	uHR6L84ZBqXBq/nGFZx1bFC6qbdO7aQqGWAUov6LjkP3QNKc5sHexsLS5/L37g==
X-Gm-Gg: AR+sD13ee9ssu1CZdR2nL+8uYgv7Moz+aNEWOZx4OjfD0zEQZU6fl1O7EntqSI1LTSj
	1dBxSt4FgZCHwznd+IGSXqkc4JCk+agBUGP/rxTE0AU64iGTe78hBcktgFjDT7REi9pVxyx+r+V
	OsxqBLnPt8fgcXdfEptOnCNf7Bs89ALkjSJLTcSpjJv0iIKAvxDxpflH1zirF/WbHA8KY1GnWb6
	pLYS4VwFzuOu2Z3W+Z3kUAOHmQPFm+vEB8jARWxxfnfK569rEoxuvjch2vSPQQcJZ5lGs+Pv81n
	zjS673r5GlwRefFhu56ZdPNPVP8Za5PCPJOxEgOgSMIhcuW0336ymG4P2uJqCg4JsBlBDFedvmn
	WH6RafYSAXlAiSPPp/cWmcPRRA+JmRk+8FOIIeoFUJOnrJP+4/bJTX1WMwE7xumK01D5nf75JYS
	c8/5D7nVTX8cP1rT6LBmFzQlvEQWCIgUELv0G9xoPvG/FZu82JWS1i66tBDzl9Ew==
X-Received: by 2002:a05:600c:1908:b0:495:7838:7e25 with SMTP id 5b1f17b1804b1-4980ee9f00fmr276868105e9.15.1785822874289;
        Mon, 03 Aug 2026 22:54:34 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v2 0/2] xen/sched: split scheduler vtable from scheduler
Date: Tue,  4 Aug 2026 08:53:25 +0300
Message-Id: <20260804055327.22119-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785822874-F4E0677B-0796F279/0/0
X-purgate-type: clean
X-purgate-size: 2000

Each struct scheduler currently doubles as both a scheduler 
backend's static vtable (name, opt_name, sched_id and every 
function pointer) and the per-cpupool runtime object that 
scheduler_alloc() allocates. Because these are the same type, 
scheduler_alloc() memcpy()s the entire vtable into a fresh heap 
allocation for every cpupool it creates. With N cpupools running 
the same scheduler, this duplicates N copies of identical function 
pointers and identifying fields that never differ between 
instances - the only fields that are genuinely per-cpupool are 
sched_data and cpupool.

This series splits the vtable out into its own type, struct 
sched_ops, so it can be shared by every cpupool using a given 
scheduler instead of copied per cpupool. struct scheduler is left 
holding only what is actually per-instance: a pointer to the 
shared sched_ops, plus sched_data and cpupool.

Patch 1 contains the whole functional change: struct sched_ops is 
introduced, every in-tree scheduler backend is converted to it, 
and struct scheduler is shrunk accordingly.
Patch 2 is a pure rename of the symbols to match the new sched_ops.

v2: folded the previous 7-patch series into two patches.

Furkan Caliskan (2):
  xen/sched: split scheduler vtable from struct scheduler
  xen/sched: rename scheduler registration symbols

 xen/arch/arm/xen.lds.S      |   2 +-
 xen/arch/ppc/xen.lds.S      |   2 +-
 xen/arch/riscv/xen.lds.S    |   2 +-
 xen/arch/x86/xen.lds.S      |   2 +-
 xen/common/sched/arinc653.c |  11 +---
 xen/common/sched/core.c     |  81 ++++++++++++++++-------------
 xen/common/sched/cpupool.c  |   7 +--
 xen/common/sched/credit.c   |   5 +-
 xen/common/sched/credit2.c  |   5 +-
 xen/common/sched/null.c     |   5 +-
 xen/common/sched/private.h  | 100 +++++++++++++++++++-----------------
 xen/common/sched/rt.c       |   5 +-
 xen/include/xen/xen.lds.h   |  10 ++--
 13 files changed, 119 insertions(+), 118 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 05:54:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 05:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381883.1625333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr86w-0000M4-RW; Tue, 04 Aug 2026 05:54:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381883.1625333; Tue, 04 Aug 2026 05:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr86w-0000Lv-Nl; Tue, 04 Aug 2026 05:54:46 +0000
Received: by outflank-mailman (input) for mailman id 1381883;
 Tue, 04 Aug 2026 05:54:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wr86v-0000LU-71
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 05:54:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr86u-00DoJM-Gc
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:54:44 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a717e93-2eae-0a2a0a5409dd-0a2a4504e2c6-20
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:54:44 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a717ea4-b57f-0a2a45040019-d155802cb57b-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:54:44 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-49557167508so25172265e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 22:54:44 -0700 (PDT)
Received: from notebook.. ([78.173.117.189]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a100e14sm55453775e9.14.2026.08.03.22.54.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 22:54:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785822884; x=1786427684; 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=8ggoOmXMwyCogxzBnBzSfIP7aGxj9wPFdRUdL5Ji3Ko=;
        b=G60Am7tK6ST+k+DGPtB7LfQROY7sRE6nvpaBiOv67VWd3KMROhxZMNVQ6dlYOY/ufm
         AqYJIWfXpIuLlljql9PNPGQkP2QIzL1o8gqa0wwCnTgBmZoLy49nA4rLbjmzvQjeb4Fl
         KcuxSG+qYL/yuadwdFgOpa1LLW/J39l8XgkbItr/Qx8QNDhpNJBL7spssCHmqbDPFNRK
         DVOx6jXRiFd2YNCr2XVvwI5UIHgClQOECpx1/aPJqCe6mbwIqyjQw3msfjd/SzVLX0j6
         1meQz0fNF0Ggwg5h4AXaZq7Vv/qvVpqR4w1gzPwg2Ml/PqSJBuH/skgfL3eq4jROm/gI
         5bRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785822884; x=1786427684;
        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=8ggoOmXMwyCogxzBnBzSfIP7aGxj9wPFdRUdL5Ji3Ko=;
        b=UY9UZuzQpzpV2+IMrjvPme7UR8i2jHA67YRWtVgcgEmqFs9Zsmx6epWmjxcbMc2AGe
         qKF3aAmjjCvAZPwMRPZ6B9kr9LPdDTiB5tg9UM76RUjVFE7WQSF2VtU9TRmGxjfVMbjk
         V+JSXY3glQVzFd87qxMsnA+mhrWMvl/0SJH6RrfhxRoM7tTracXKHXYfCobcRNLbd9X0
         /V2s0hUS7uAVYvn5/zhNSLee0gA4j/rlTXrLBd1sbDFtzOPgPqdv8p/UyLD/jZ/gQUAv
         TH/rWgRCskyStS5AAw5OoQttoqI8O1Uw8+Fey2CccAfgoaVYfcLO2OidOLdG2Xwc4yqJ
         OEuA==
X-Gm-Message-State: AOJu0Yw+zNhkp8LJw9CfChYbnJhIZ5S7j7MpPLfu3bka3vxhTMD8Nzeb
	0LE/wRkqr+FQASy2txUEPLtryEbF06310ZjSnTnzHLoT8qZE5cQ6r0lS4H+O1g==
X-Gm-Gg: AR+sD10Tg/Z4ddVzvSDYH8ti//09EmoXLg7h0XMKPxEiBOSBoQQaD8al6GCmGxEYm5A
	3MoMkADvwqow6xrihmQhhmtLO3vAwFy1K/VEgDvx/FIVQhUMLPxSBu/pEEFOf3SQHPUgQ6xYb86
	xNs65kIi/zajKcDxXc5FLPd3L0k8dstX55eVTg1RNKRFt5Yo0ZI5l9nGiwneAVJLsi8Wmqi/KLz
	WF54RJpfcY4wVWbp7vEYBdv2ZszNx2hyfumgM0q4URvE6S0ga9pSPgu6S0HENtI2jtUJwniKOFO
	drFof1mCOHQS2r9KcWo/dX2pnvTX7pp5/wm501pzBDccmHRbAiGvbdBNHaePnEY4i+pwOM23K2c
	G9cn/jPF/XPhziPAfko5AaohXUpS+Xo3WuuMipRV3cgjqfsU07EsmCMBUu9w9gs5zDcAMNbEmhd
	gv4SrvBYC3wc/5t5/eAafAP/6Y93khyStEeOU30Mwj95GuOjJ+5rRVoqYHQVXVt9+4OHaGL2ka
X-Received: by 2002:a05:600c:4453:b0:495:6274:56c2 with SMTP id 5b1f17b1804b1-4980c649c6emr272532265e9.2.1785822883826;
        Mon, 03 Aug 2026 22:54:43 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v2 1/2] xen/sched: split scheduler vtable from struct scheduler
Date: Tue,  4 Aug 2026 08:53:26 +0300
Message-Id: <20260804055327.22119-2-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260804055327.22119-1-frn1furkan10@gmail.com>
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1785822884-506DAB50-A98A8F2D/0/0
X-purgate-type: clean
X-purgate-size: 20100

struct scheduler currently serves two purposes: it is the static
vtable a scheduler backend defines (name, opt_name, sched_id, and
all its function pointers), and it is also the per-cpupool runtime
object scheduler_alloc() allocates. Being the same type forces
scheduler_alloc() to memcpy() the whole vtable into a fresh
allocation per cpupool, duplicating identical function pointers
across every cpupool using the same scheduler.

Split the vtable out into its own type, struct sched_ops, so it
can be shared by every cpupool using a given scheduler instead of
copied per cpupool. struct scheduler is left holding only what is
actually per-instance: a pointer to the shared sched_ops, plus
sched_data and cpupool. scheduler_alloc() now stores a pointer to
the matching sched_ops instance instead of copying its fields, and
every accessor in private.h is updated from s->field to
s->ops->field to match.

Every in-tree scheduler backend (credit, credit2, rtds, arinc653,
null) is converted from struct scheduler to struct sched_ops.

A handful of call sites elsewhere read a scheduler's name,
opt_name or sched_id directly and are updated to go through
->ops as well.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/arinc653.c |  9 +---
 xen/common/sched/core.c     | 52 +++++++++++---------
 xen/common/sched/cpupool.c  |  7 +--
 xen/common/sched/credit.c   |  3 +-
 xen/common/sched/credit2.c  |  3 +-
 xen/common/sched/null.c     |  3 +-
 xen/common/sched/private.h  | 98 +++++++++++++++++++------------------
 xen/common/sched/rt.c       |  3 +-
 8 files changed, 89 insertions(+), 89 deletions(-)

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 32c596a23c..746963806e 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -702,17 +702,10 @@ a653sched_adjust_global(const struct scheduler *ops,
 }
 #endif /* CONFIG_SYSCTL */
 
-/**
- * This structure defines our scheduler for Xen.
- * The entries tell Xen where to find our scheduler-specific
- * callback functions.
- * The symbol must be visible to the rest of Xen at link time.
- */
-static const struct scheduler sched_arinc653_def = {
+static const struct sched_ops sched_arinc653_def = {
     .name           = "ARINC 653 Scheduler",
     .opt_name       = "arinc653",
     .sched_id       = XEN_SCHEDULER_ARINC653,
-    .sched_data     = NULL,
 
     .init           = a653sched_init,
     .deinit         = a653sched_deinit,
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9ccf5811bf..5cdae0415c 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -87,7 +87,7 @@ DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
 /* How many urgent vcpus. */
 DEFINE_PER_CPU(atomic_t, sched_urgent_count);
 
-extern const struct scheduler *__start_schedulers_array[], *__end_schedulers_array[];
+extern const struct sched_ops *__start_schedulers_array[], *__end_schedulers_array[];
 #define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
 #define schedulers __start_schedulers_array
 
@@ -127,10 +127,9 @@ static void cf_check sched_idle_schedule(
     unit->next_task = sched_idle_unit(cpu);
 }
 
-static struct scheduler sched_idle_ops = {
+static struct sched_ops sched_idle_sched_ops = {
     .name           = "Idle Scheduler",
     .opt_name       = "idle",
-    .sched_data     = NULL,
 
     .pick_resource  = sched_idle_res_pick,
     .do_schedule    = sched_idle_schedule,
@@ -139,6 +138,11 @@ static struct scheduler sched_idle_ops = {
     .free_udata     = sched_idle_free_udata,
 };
 
+static struct scheduler sched_idle_ops = {
+    .ops        = &sched_idle_sched_ops,
+    .sched_data = NULL,
+};
+
 static inline struct vcpu *unit2vcpu_cpu(const struct sched_unit *unit,
                                          unsigned int cpu)
 {
@@ -2081,7 +2085,7 @@ long do_set_timer_op(s_time_t timeout)
 /* scheduler_id - fetch ID of current scheduler */
 int scheduler_id(void)
 {
-    return operations.sched_id;
+    return operations.ops->sched_id;
 }
 #endif
 
@@ -2090,7 +2094,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
     long ret;
 
-    if ( op->sched_id != dom_scheduler(d)->sched_id )
+    if ( op->sched_id != dom_scheduler(d)->ops->sched_id )
         return -EINVAL;
 
     switch ( op->cmd )
@@ -2132,7 +2136,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 
     rcu_read_lock(&sched_res_rculock);
 
-    rc = ((op->sched_id == pool->sched->sched_id)
+    rc = ((op->sched_id == pool->sched->ops->sched_id)
           ? sched_adjust_cpupool(pool->sched, op) : -EINVAL);
 
     rcu_read_unlock(&sched_res_rculock);
@@ -2299,7 +2303,7 @@ static struct sched_unit *do_schedule(struct sched_unit *prev, s_time_t now,
     struct sched_unit *next;
 
     /* get policy-specific decision on scheduling... */
-    sched->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
+    sched->ops->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
 
     next = prev->next_task;
 
@@ -2989,10 +2993,9 @@ void scheduler_enable(void)
 }
 
 static inline
-const struct scheduler *__init sched_get_by_name(const char *sched_name)
+const struct sched_ops *__init sched_ops_get_by_name(const char* sched_name)
 {
     unsigned int i;
-
     for ( i = 0; i < NUM_SCHEDULERS; i++ )
         if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
             return schedulers[i];
@@ -3002,16 +3005,15 @@ const struct scheduler *__init sched_get_by_name(const char *sched_name)
 
 int __init sched_get_id_by_name(const char *sched_name)
 {
-    const struct scheduler *scheduler = sched_get_by_name(sched_name);
-
-    return scheduler ? scheduler->sched_id : -1;
+    const struct sched_ops *ops = sched_ops_get_by_name(sched_name);
+    return ops ? ops->sched_id : -1;
 }
 
 /* Initialise the data structures. */
 void __init scheduler_init(void)
 {
     struct domain *idle_domain;
-    const struct scheduler *scheduler;
+    const struct sched_ops *ops;
     int i;
 
     scheduler_enable();
@@ -3044,21 +3046,23 @@ void __init scheduler_init(void)
         }
     }
 
-    scheduler = sched_get_by_name(opt_sched);
-    if ( !scheduler )
+    ops = sched_ops_get_by_name(opt_sched);
+    if ( !ops )
     {
         printk("Could not find scheduler: %s\n", opt_sched);
-        scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
-        BUG_ON(!scheduler);
-        printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
+        ops = sched_ops_get_by_name(CONFIG_SCHED_DEFAULT);
+        BUG_ON(!ops);
+        printk("Using '%s' (%s)\n", ops->name, ops->opt_name);
     }
-    operations = *scheduler;
+
+    operations.ops = ops;
 
     if ( cpu_schedule_up(0) )
         BUG();
     register_cpu_notifier(&cpu_schedule_nfb);
 
-    printk("Using scheduler: %s (%s)\n", operations.name, operations.opt_name);
+    printk("Using scheduler: %s (%s)\n",
+           operations.ops->name, operations.ops->opt_name);
     if ( sched_init(&operations) )
         panic("scheduler returned error on init\n");
 
@@ -3411,12 +3415,14 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
     for ( i = 0; i < NUM_SCHEDULERS; i++ )
         if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
             goto found;
+
     return ERR_PTR(-ENOENT);
 
  found:
-    if ( (sched = xmalloc(struct scheduler)) == NULL )
+    if ( (sched = xzalloc(struct scheduler)) == NULL )
         return ERR_PTR(-ENOMEM);
-    memcpy(sched, schedulers[i], sizeof(*sched));
+    sched->ops = schedulers[i];
+
     if ( (ret = sched_init(sched)) != 0 )
     {
         xfree(sched);
@@ -3447,7 +3453,7 @@ void schedule_dump(struct cpupool *c)
     {
         sched = c->sched;
         cpus = c->res_valid;
-        printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
+        printk("Scheduler: %s (%s)\n", sched->ops->name, sched->ops->opt_name);
         sched_dump_settings(sched);
     }
     else
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 081e1053eb..640578201f 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -338,7 +338,8 @@ static struct cpupool *cpupool_create(unsigned int poolid,
     spin_unlock(&cpupool_lock);
 
     debugtrace_printk("Created cpupool %u with scheduler %s (%s)\n",
-                      c->cpupool_id, c->sched->name, c->sched->opt_name);
+                      c->cpupool_id, c->sched->ops->name,
+                      c->sched->ops->opt_name);
 
     return c;
 
@@ -862,7 +863,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
         if ( c == NULL )
             break;
         op->cpupool_id = c->cpupool_id;
-        op->sched_id = c->sched->sched_id;
+        op->sched_id = c->sched->ops->sched_id;
         op->n_dom = c->n_dom;
         ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
         cpupool_put(c);
@@ -1294,7 +1295,7 @@ struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
     struct cpupool *pool;
 
     if ( sched_id < 0 )
-        sched_id = scheduler_get_default()->sched_id;
+        sched_id = scheduler_get_default()->ops->sched_id;
 
     pool = cpupool_create(pool_id, sched_id);
 
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 4dde2ede12..8df746bf6b 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -2277,11 +2277,10 @@ csched_deinit(struct scheduler *ops)
     }
 }
 
-static const struct scheduler sched_credit_def = {
+static const struct sched_ops sched_credit_def = {
     .name           = "SMP Credit Scheduler",
     .opt_name       = "credit",
     .sched_id       = XEN_SCHEDULER_CREDIT,
-    .sched_data     = NULL,
 
     .global_init    = csched_global_init,
 
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 95946634d1..4949606881 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -4230,11 +4230,10 @@ csched2_deinit(struct scheduler *ops)
     xfree(prv);
 }
 
-static const struct scheduler sched_credit2_def = {
+static const struct sched_ops sched_credit2_def = {
     .name           = "SMP Credit Scheduler rev2",
     .opt_name       = "credit2",
     .sched_id       = XEN_SCHEDULER_CREDIT2,
-    .sched_data     = NULL,
 
     .global_init    = csched2_global_init,
 
diff --git a/xen/common/sched/null.c b/xen/common/sched/null.c
index 952bb47444..b3c6651fb1 100644
--- a/xen/common/sched/null.c
+++ b/xen/common/sched/null.c
@@ -1037,11 +1037,10 @@ static void cf_check null_dump(const struct scheduler *ops)
     spin_unlock_irqrestore(&prv->lock, flags);
 }
 
-static const struct scheduler sched_null_def = {
+static const struct sched_ops sched_null_def = {
     .name           = "null Scheduler",
     .opt_name       = "null",
     .sched_id       = XEN_SCHEDULER_NULL,
-    .sched_data     = NULL,
 
     .init           = null_init,
     .deinit         = null_deinit,
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index d6884550cd..0c5181891c 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -294,12 +294,10 @@ static inline spinlock_t *pcpu_schedule_trylock(unsigned int cpu)
     return NULL;
 }
 
-struct scheduler {
-    const char *name;       /* full name for this scheduler      */
-    const char *opt_name;   /* option name for this scheduler    */
-    unsigned int sched_id;  /* ID for this scheduler             */
-    void *sched_data;       /* global data pointer               */
-    struct cpupool *cpupool;/* points to this scheduler's pool   */
+struct sched_ops {
+    const char *name;       /* full name for this sched_ops      */
+    const char *opt_name;   /* option name for this sched_ops    */
+    unsigned int sched_id;  /* ID for this sched_ops             */
 
     int          (*global_init)    (void);
 
@@ -366,127 +364,133 @@ struct scheduler {
                                     struct sched_resource *sr);
 };
 
+struct scheduler {
+    const struct sched_ops *ops; /* shared, read-only dispatch table */
+    void *sched_data;            /* global data pointer               */
+    struct cpupool *cpupool;     /* points to this scheduler's pool   */
+};
+
 static inline int sched_init(struct scheduler *s)
 {
-    return s->init(s);
+    return s->ops->init(s);
 }
 
 static inline void sched_deinit(struct scheduler *s)
 {
-    s->deinit(s);
+    s->ops->deinit(s);
 }
 
 static inline spinlock_t *sched_switch_sched(struct scheduler *s,
                                              unsigned int cpu,
                                              void *pdata, void *vdata)
 {
-    return s->switch_sched(s, cpu, pdata, vdata);
+    return s->ops->switch_sched(s, cpu, pdata, vdata);
 }
 
 static inline void sched_dump_settings(const struct scheduler *s)
 {
-    if ( s->dump_settings )
-        s->dump_settings(s);
+    if ( s->ops->dump_settings )
+        s->ops->dump_settings(s);
 }
 
 static inline void sched_dump_cpu_state(const struct scheduler *s, int cpu)
 {
-    if ( s->dump_cpu_state )
-        s->dump_cpu_state(s, cpu);
+    if ( s->ops->dump_cpu_state )
+        s->ops->dump_cpu_state(s, cpu);
 }
 
 static inline void *sched_alloc_domdata(const struct scheduler *s,
                                         struct domain *d)
 {
-    return s->alloc_domdata ? s->alloc_domdata(s, d) : NULL;
+    return s->ops->alloc_domdata ? s->ops->alloc_domdata(s, d) : NULL;
 }
 
 static inline void sched_free_domdata(const struct scheduler *s,
                                       void *data)
 {
-    ASSERT(s->free_domdata || !data);
-    if ( s->free_domdata )
-        s->free_domdata(s, data);
+    ASSERT(s->ops->free_domdata || !data);
+    if ( s->ops->free_domdata )
+        s->ops->free_domdata(s, data);
 }
 
 static inline void *sched_alloc_pdata(const struct scheduler *s, int cpu)
 {
-    return s->alloc_pdata ? s->alloc_pdata(s, cpu) : NULL;
+    return s->ops->alloc_pdata ? s->ops->alloc_pdata(s, cpu) : NULL;
 }
 
 static inline void sched_free_pdata(const struct scheduler *s, void *data,
                                     int cpu)
 {
-    ASSERT(s->free_pdata || !data);
-    if ( s->free_pdata )
-        s->free_pdata(s, data, cpu);
+    ASSERT(s->ops->free_pdata || !data);
+    if ( s->ops->free_pdata )
+        s->ops->free_pdata(s, data, cpu);
 }
 
 static inline void sched_deinit_pdata(const struct scheduler *s, void *data,
                                       int cpu)
 {
-    if ( s->deinit_pdata )
-        s->deinit_pdata(s, data, cpu);
+    if ( s->ops->deinit_pdata )
+        s->ops->deinit_pdata(s, data, cpu);
 }
 
 static inline void *sched_alloc_udata(const struct scheduler *s,
                                       struct sched_unit *unit, void *dom_data)
 {
-    return s->alloc_udata(s, unit, dom_data);
+    return s->ops->alloc_udata(s, unit, dom_data);
 }
 
 static inline void sched_free_udata(const struct scheduler *s, void *data)
 {
-    s->free_udata(s, data);
+    s->ops->free_udata(s, data);
 }
 
 static inline void sched_insert_unit(const struct scheduler *s,
                                      struct sched_unit *unit)
 {
-    if ( s->insert_unit )
-        s->insert_unit(s, unit);
+    if ( s->ops->insert_unit )
+        s->ops->insert_unit(s, unit);
 }
 
 static inline void sched_remove_unit(const struct scheduler *s,
                                      struct sched_unit *unit)
 {
-    if ( s->remove_unit )
-        s->remove_unit(s, unit);
+    if ( s->ops->remove_unit )
+        s->ops->remove_unit(s, unit);
 }
 
 static inline void sched_sleep(const struct scheduler *s,
                                struct sched_unit *unit)
 {
-    if ( s->sleep )
-        s->sleep(s, unit);
+    if ( s->ops->sleep )
+        s->ops->sleep(s, unit);
 }
 
 static inline void sched_wake(const struct scheduler *s,
                               struct sched_unit *unit)
 {
-    if ( s->wake )
-        s->wake(s, unit);
+    if ( s->ops->wake )
+        s->ops->wake(s, unit);
 }
 
 static inline void sched_yield(const struct scheduler *s,
                                struct sched_unit *unit)
 {
-    if ( s->yield )
-        s->yield(s, unit);
+    if ( s->ops->yield )
+        s->ops->yield(s, unit);
 }
 
 static inline void sched_context_saved(const struct scheduler *s,
                                        struct sched_unit *unit)
 {
-    if ( s->context_saved )
-        s->context_saved(s, unit);
+    if ( s->ops->context_saved )
+        s->ops->context_saved(s, unit);
 }
 
 static inline void sched_migrate(const struct scheduler *s,
                                  struct sched_unit *unit, unsigned int cpu)
 {
-    if ( s->migrate )
-        s->migrate(s, unit, cpu);
+    if ( s->ops->migrate )
+        s->ops->migrate(s, unit, cpu);
     else
         sched_set_res(unit, get_sched_res(cpu));
 }
@@ -494,7 +498,7 @@ static inline void sched_migrate(const struct scheduler *s,
 static inline struct sched_resource *sched_pick_resource(
     const struct scheduler *s, const struct sched_unit *unit)
 {
-    return s->pick_resource(s, unit);
+    return s->ops->pick_resource(s, unit);
 }
 
 static inline void sched_adjust_affinity(const struct scheduler *s,
@@ -502,29 +506,29 @@ static inline void sched_adjust_affinity(const struct scheduler *s,
                                          const cpumask_t *hard,
                                          const cpumask_t *soft)
 {
-    if ( s->adjust_affinity )
-        s->adjust_affinity(s, unit, hard, soft);
+    if ( s->ops->adjust_affinity )
+        s->ops->adjust_affinity(s, unit, hard, soft);
 }
 
 static inline int sched_adjust_dom(const struct scheduler *s, struct domain *d,
                                    struct xen_domctl_scheduler_op *op)
 {
-    return s->adjust ? s->adjust(s, d, op) : 0;
+    return s->ops->adjust ? s->ops->adjust(s, d, op) : 0;
 }
 
 #ifdef CONFIG_SYSCTL
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
-    return s->adjust_global ? s->adjust_global(s, op) : 0;
+    return s->ops->adjust_global ? s->ops->adjust_global(s, op) : 0;
 }
 #endif
 
 static inline void sched_move_timers(const struct scheduler *s,
                                      struct sched_resource *sr)
 {
-    if ( s->move_timers )
-        s->move_timers(s, sr);
+    if ( s->ops->move_timers )
+        s->ops->move_timers(s, sr);
 }
 
 static inline void sched_unit_pause_nosync(const struct sched_unit *unit)
@@ -543,7 +547,7 @@ static inline void sched_unit_unpause(const struct sched_unit *unit)
         vcpu_unpause(v);
 }
 
-#define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
+#define REGISTER_SCHEDULER(x) static const struct sched_ops *x##_entry \
   __used_section(".data.schedulers") = &(x)
 
 struct cpupool
diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 744f214173..0e9f04ea72 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1617,11 +1617,10 @@ static void cf_check repl_timer_handler(void *data)
     spin_unlock_irq(&prv->lock);
 }
 
-static const struct scheduler sched_rtds_def = {
+static const struct sched_ops sched_rtds_def = {
     .name           = "SMP RTDS Scheduler",
     .opt_name       = "rtds",
     .sched_id       = XEN_SCHEDULER_RTDS,
-    .sched_data     = NULL,
 
     .dump_cpu_state = rt_dump_pcpu,
     .dump_settings  = rt_dump,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 05:54:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 05:54:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381885.1625342 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr873-0000dG-6H; Tue, 04 Aug 2026 05:54:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381885.1625342; Tue, 04 Aug 2026 05:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr873-0000d9-3K; Tue, 04 Aug 2026 05:54:53 +0000
Received: by outflank-mailman (input) for mailman id 1381885;
 Tue, 04 Aug 2026 05:54:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wr871-0000bZ-Iw
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 05:54:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr870-00DRnB-Vx
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:54:50 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a717e95-e002-0a2a0a5209dd-0a2a4503adec-46
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:54:50 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a717eaa-fae8-0a2a45030019-d155802cdded-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:54:50 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so23317355e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 22:54:50 -0700 (PDT)
Received: from notebook.. ([78.173.117.189]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a100e14sm55453775e9.14.2026.08.03.22.54.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 03 Aug 2026 22:54:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785822890; x=1786427690; 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=p6vxw/6ES4G2VqIbltqaKS0hNP1qFgjai3ORZHffXN8=;
        b=JRBVpzyToFDKUCnkHaEdrbYtw2LlbHqHuWQW1LM5y+CIthEEkEEjCzBkK6ji57okMt
         KQNGM3ErzhXq4yuErKRTCtkpeozvPF1ShGjtis0vxvYq3+H8xj+ZYvh4Do0jfbWKJWjN
         BuzdQiQpzH3l1X01MBs4+/qUKjXbNEh2rLdQNFbQcrb8aVbV4AUvDXheMdb+3Dh9RARv
         LhCTNt7me8MIKwKYvxPeJb67t8papaSyNN196lS2E98/nI9Sz4ScGvfbK6ySL0tEsjM/
         NS7icNZf8qEJV/ou7vjnL80GFc1O8+zNX45LqY0e70etuOd723n7uhCQ4nCNAXJ3b5sm
         VgvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785822890; x=1786427690;
        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=p6vxw/6ES4G2VqIbltqaKS0hNP1qFgjai3ORZHffXN8=;
        b=n+ZvlSwGEIrF1sXYq0VRCVWYnJwTuXcq6YMB676sYVzzJ1U+ZkzDyzREEaiZ0GZJp2
         M7Eu7LZDCO0KRfryhmmU9MvphuJwziy9w0EuHkQb+5tkmt2eo9SirDE+Xh9P4n31nSU3
         RhQIhjM8coKcFb+N+i62qnDtLR+HORibcQS6m5mUWO5Ovf+IRHr+cuJjRq3CeWXvnVrL
         7hH3vsB90/nm5qgEfGfuYGE0yRy7uVTrPeB3aW9t+3AKcGjFFXSGi3xB1aVECE60WNGJ
         4L8aSLI1P7ApHZG4wMsYCabJnXqjG88W8VdGrvGhuyzdIQ6LAtwMDBOwgsUiWJArH8zm
         QdPw==
X-Gm-Message-State: AOJu0YyF4MoeD3DmTAHai04i5LGibHLZU4tYSJr34JjYvw6+KIoF+ANC
	zgvvN+x2sAZqXZVn2mGdAt5u3I1VeaDJIq6CqRIVBYBDMIORi2p1I6M7HXyoqQ==
X-Gm-Gg: AR+sD10gX4sCWXbh4QV61VrRnBSLQRH3Vk9f0yds9SCvzcy3avC3CR2E5dtS9vwpvl/
	rYt1voidGkF7wyl3+K4uMDeopUTYc0YnsRtPAxQrmWsNYeM9fGsRPnvERESCXSMRY8vhAYMfCN2
	wWbYrR6kzyaCJ+7kSu99jFKQNQNl94wJ1aGX2BRQXor4GkvH0v/Wg12KWPMDYkLGpcYtskPe/ny
	qvSyTqJe+t64YAPdwkx1l4GrGeL7yO3MN7AelRPhi6+mrWJdsokhzYcMXMgRw1rFsROUw2b/Mkz
	OTtYGbzODqw+lWDDp7mLdvbbUiVug4Mx4KHQUD5HEnJoAhyTBhphtFQVknjPSJ/fcyDMWcPKRfy
	avoHK2TVkm4W6cVIBWtBiZcHygbV8DDK/T78iLJc2D1+5x5uolEFotaOH+H5KLly/haZqOdyLT9
	8RY6drQpnreqqe6xF4Ye3PjR9G7CD2ovlksh7ZL9AUBINAbJeLnMmcTvlaLTtN2w==
X-Received: by 2002:a05:600c:840f:b0:493:c42e:5be0 with SMTP id 5b1f17b1804b1-4980c60705amr267135705e9.0.1785822890072;
        Mon, 03 Aug 2026 22:54:50 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	tpearson@raptorengineering.com,
	alistair.francis@wdc.com,
	connojdavis@gmail.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v2 2/2] xen/sched: rename scheduler registration symbols
Date: Tue,  4 Aug 2026 08:53:27 +0300
Message-Id: <20260804055327.22119-3-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260804055327.22119-1-frn1furkan10@gmail.com>
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785822890-6E8CD4E9-A21BE1E6/0/0
X-purgate-type: clean
X-purgate-size: 8916

REGISTER_SCHEDULER(), schedulers[], NUM_SCHEDULERS, and the
per-arch SCHEDULER_ARRAY linker macro now register and hold
struct sched_ops instances rather than struct scheduler ones,
but still carry names describing the old type.

Rename them to match the current behaviour.
No functional change.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/arch/arm/xen.lds.S      |  2 +-
 xen/arch/ppc/xen.lds.S      |  2 +-
 xen/arch/riscv/xen.lds.S    |  2 +-
 xen/arch/x86/xen.lds.S      |  2 +-
 xen/common/sched/arinc653.c |  2 +-
 xen/common/sched/core.c     | 33 +++++++++++++++++----------------
 xen/common/sched/credit.c   |  2 +-
 xen/common/sched/credit2.c  |  2 +-
 xen/common/sched/null.c     |  2 +-
 xen/common/sched/private.h  |  4 ++--
 xen/common/sched/rt.c       |  2 +-
 xen/include/xen/xen.lds.h   | 10 +++++-----
 12 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2d5f1c516d..07bf875599 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -93,7 +93,7 @@ SECTIONS
   .data : {                    /* Data */
        *(.data.page_aligned)
 
-       SCHEDULER_ARRAY
+       SCHED_OPS_ARRAY
        HYPFS_PARAM
 
        *(.data .data.*)
diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S
index d0f2ed43f1..1f4e200693 100644
--- a/xen/arch/ppc/xen.lds.S
+++ b/xen/arch/ppc/xen.lds.S
@@ -84,7 +84,7 @@ SECTIONS
     DECL_SECTION(.data) {                    /* Data */
         *(.data.page_aligned)
 
-        SCHEDULER_ARRAY
+        SCHED_OPS_ARRAY
         HYPFS_PARAM
 
         *(.data .data.*)
diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S
index 65f136dce9..97f2db1dfd 100644
--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -89,7 +89,7 @@ SECTIONS
     .data : {                    /* Data */
         *(.data.page_aligned)
 
-        SCHEDULER_ARRAY
+        SCHED_OPS_ARRAY
         HYPFS_PARAM
 
         *(.data .data.*)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index b9e888e596..0f506ff1f6 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -306,7 +306,7 @@ SECTIONS
   DECL_SECTION(.data.read_mostly) {
        *(.data.read_mostly)
 
-       SCHEDULER_ARRAY
+       SCHED_OPS_ARRAY
        HYPFS_PARAM
   } PHDR(text)
 
diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 746963806e..efcaa44089 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -736,7 +736,7 @@ static const struct sched_ops sched_arinc653_def = {
     .dump_cpu_state = NULL,
 };
 
-REGISTER_SCHEDULER(sched_arinc653_def);
+REGISTER_SCHED_OPS(sched_arinc653_def);
 
 /*
  * Local variables:
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 5cdae0415c..8e938a3810 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -87,9 +87,9 @@ DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
 /* How many urgent vcpus. */
 DEFINE_PER_CPU(atomic_t, sched_urgent_count);
 
-extern const struct sched_ops *__start_schedulers_array[], *__end_schedulers_array[];
-#define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
-#define schedulers __start_schedulers_array
+extern const struct sched_ops *__start_sched_ops_array[], *__end_sched_ops_array[];
+#define NUM_SCHED_OPS (__end_sched_ops_array - __start_sched_ops_array)
+#define sched_ops_array __start_sched_ops_array
 
 static struct scheduler __read_mostly operations;
 
@@ -2996,9 +2996,9 @@ static inline
 const struct sched_ops *__init sched_ops_get_by_name(const char* sched_name)
 {
     unsigned int i;
-    for ( i = 0; i < NUM_SCHEDULERS; i++ )
-        if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
-            return schedulers[i];
+    for ( i = 0; i < NUM_SCHED_OPS; i++ )
+        if ( sched_ops_array[i] && !strcmp(sched_ops_array[i]->opt_name, sched_name) )
+            return sched_ops_array[i];
 
     return NULL;
 }
@@ -3018,14 +3018,14 @@ void __init scheduler_init(void)
 
     scheduler_enable();
 
-    for ( i = 0; i < NUM_SCHEDULERS; i++)
+    for ( i = 0; i < NUM_SCHED_OPS; i++)
     {
 #define sched_test_func(f)                               \
-        if ( !schedulers[i]->f )                         \
+        if ( !sched_ops_array[i]->f )                    \
         {                                                \
             printk("scheduler %s misses .%s, dropped\n", \
-                   schedulers[i]->opt_name, #f);         \
-            schedulers[i] = NULL;                        \
+                   sched_ops_array[i]->opt_name, #f);    \
+            sched_ops_array[i] = NULL;                   \
         }
 
         sched_test_func(init);
@@ -3038,11 +3038,12 @@ void __init scheduler_init(void)
 
 #undef sched_test_func
 
-        if ( schedulers[i]->global_init && schedulers[i]->global_init() < 0 )
+        if ( sched_ops_array[i]->global_init &&
+             sched_ops_array[i]->global_init() < 0 )
         {
             printk("scheduler %s failed initialization, dropped\n",
-                   schedulers[i]->opt_name);
-            schedulers[i] = NULL;
+                   sched_ops_array[i]->opt_name);
+            sched_ops_array[i] = NULL;
         }
     }
 
@@ -3412,8 +3413,8 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
     int ret;
     struct scheduler *sched;
 
-    for ( i = 0; i < NUM_SCHEDULERS; i++ )
-        if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
+    for ( i = 0; i < NUM_SCHED_OPS; i++ )
+        if ( sched_ops_array[i] && sched_ops_array[i]->sched_id == sched_id )
             goto found;
 
     return ERR_PTR(-ENOENT);
@@ -3421,7 +3422,7 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
  found:
     if ( (sched = xzalloc(struct scheduler)) == NULL )
         return ERR_PTR(-ENOMEM);
-    sched->ops = schedulers[i];
+    sched->ops = sched_ops_array[i];
 
     if ( (ret = sched_init(sched)) != 0 )
     {
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 8df746bf6b..995cf097b5 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -2315,4 +2315,4 @@ static const struct sched_ops sched_credit_def = {
     .move_timers    = csched_move_timers,
 };
 
-REGISTER_SCHEDULER(sched_credit_def);
+REGISTER_SCHED_OPS(sched_credit_def);
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 4949606881..9bcc90004a 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -4268,4 +4268,4 @@ static const struct sched_ops sched_credit2_def = {
     .free_domdata   = csched2_free_domdata,
 };
 
-REGISTER_SCHEDULER(sched_credit2_def);
+REGISTER_SCHED_OPS(sched_credit2_def);
diff --git a/xen/common/sched/null.c b/xen/common/sched/null.c
index b3c6651fb1..5194c8216c 100644
--- a/xen/common/sched/null.c
+++ b/xen/common/sched/null.c
@@ -1067,4 +1067,4 @@ static const struct sched_ops sched_null_def = {
     .dump_settings  = null_dump,
 };
 
-REGISTER_SCHEDULER(sched_null_def);
+REGISTER_SCHED_OPS(sched_null_def);
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index 0c5181891c..c03063befe 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -547,8 +547,8 @@ static inline void sched_unit_unpause(const struct sched_unit *unit)
         vcpu_unpause(v);
 }
 
-#define REGISTER_SCHEDULER(x) static const struct sched_ops *x##_entry \
-  __used_section(".data.schedulers") = &(x)
+#define REGISTER_SCHED_OPS(x) static const struct sched_ops *x##_entry \
+  __used_section(".data.sched_ops") = &(x)
 
 struct cpupool
 {
diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 0e9f04ea72..8b4f05e2d1 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1645,4 +1645,4 @@ static const struct sched_ops sched_rtds_def = {
     .move_timers    = rt_move_timers,
 };
 
-REGISTER_SCHEDULER(sched_rtds_def);
+REGISTER_SCHED_OPS(sched_rtds_def);
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
index ea11e3fb62..fc44d28734 100644
--- a/xen/include/xen/xen.lds.h
+++ b/xen/include/xen/xen.lds.h
@@ -173,11 +173,11 @@
        _edevice = .;        \
   } :text
 
-#define SCHEDULER_ARRAY              \
-       . = ALIGN(POINTER_ALIGN);     \
-       __start_schedulers_array = .; \
-       *(.data.schedulers)           \
-       __end_schedulers_array = .;
+#define SCHED_OPS_ARRAY             \
+       . = ALIGN(POINTER_ALIGN);    \
+       __start_sched_ops_array = .; \
+       *(.data.sched_ops)           \
+       __end_sched_ops_array = .;
 
 #ifdef CONFIG_HYPFS
 #define HYPFS_PARAM              \
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 06:22:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 06:22:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381912.1625352 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr8Y9-0006fB-A6; Tue, 04 Aug 2026 06:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381912.1625352; Tue, 04 Aug 2026 06: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wr8Y9-0006f4-75; Tue, 04 Aug 2026 06:22:53 +0000
Received: by outflank-mailman (input) for mailman id 1381912;
 Tue, 04 Aug 2026 06:12:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wr8O8-00053K-MO
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 06:12:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wr8O8-004eM8-2Q
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 06:12:32 +0000
Received: from mail-lf1-f44.google.com ([209.85.167.44])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wr8O8-007Sib-1I
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 06:12:32 +0000
Received: by mail-lf1-f44.google.com with SMTP id
 2adb3069b0e04-5b28c91fba5so796609e87.1
 for <xen-devel@lists.xenproject.org>; Mon, 03 Aug 2026 23:12:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:Cc:To:Subject:Message-ID:
	Date:From:MIME-Version; bh=cKkt4ers6CnESh/Dtqx6JQgb2hU5RYPlj5ywtje48gQ=; b=XW
	Om9dgoOSHjstj0vCbZKxisMZjdrjcjdIJCNfwuqPvWnsUbqXHYMZUgUmJsOY6QMpMDiFQGpJkpWdp
	xleOagT6oy4aGlaatSzN6XsrXiwQcwTAEvpb8h6WeUnJc0DjhGnv6ySyzPPg7UP+1wLhJKefdmvr0
	7sQeT4Xe7OcIRt0=;
X-Gm-Message-State: AOJu0Yy0pKT+rtsymcU7kSDuvD+G1AWNnDaZEskXDZFv/7aezmnY9rjX
	u4ufOyw/voCEBekVFBMGDShDWCFbr6zlnsU+YWOv1Zd7Pqzsop202dNVG115fqy6z3hhlrQglh0
	nZytjer51jGMZ16IuzVD5bzZxtqZPh9o=
X-Received: by 2002:a05:6512:3e23:b0:5b2:aa73:ea6a with SMTP id
 2adb3069b0e04-5b2f281bc1emr276587e87.10.1785823951299; Mon, 03 Aug 2026
 23:12:31 -0700 (PDT)
MIME-Version: 1.0
From: George Dunlap <gwd@xenproject.org>
Date: Tue, 4 Aug 2026 16:12:17 +1000
X-Gmail-Original-Message-ID: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
X-Gm-Features: AUfX_mw6ehuTpnm2xYeSM80RlQxvsXMGAHoaDwR3g3EL7lt0OIExqIqZbAwNxk8
Message-ID: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
Subject: Linux PV domU with >1 vCPU never resumes after xl save/restore
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Juergen Gross <jgross@suse.com>
Content-Type: multipart/alternative; boundary="0000000000003fa71a0658328abf"

--0000000000003fa71a0658328abf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

Saving and restoring a multi-vcpu PV guest appears to have been broken in
Linux for some time (observed 6.6.56 and 6.12.86).  Report below from
Claude Fable; I've independently verified the behavior on vanilla Linux
6.6.56.  Claude seems to think it's a bug in Linux.

Gitlab CI seems to only run with vcpus=3D1, which is why it didn't notice.

George Dunlap
Freelance Xen consultant
https://www.laleolanguage.com/consulting

8<----

A PV guest with more than one vCPU survives `xl save`, but after
`xl restore` it never comes back: the kernel wedges mid-resume, before
xenbus reconnect, so all frontends stay disconnected (netfront frontend
state remains XenbusStateInitialising, backend InitWait; vif shows
NO-CARRIER in dom0) and the guest is unreachable indefinitely. With
vcpus=3D1 the same guest/image/kernel resumes cleanly, PVH SMP
save/restore is fine, and the suspend-cancel path (a failed `xl save`
resuming the domain in place) is also fine.

Reproduced with:
 - Debian trixie kernel 6.12.86+deb13-amd64
 - the Xen-project CI test-artifacts kernel, vanilla 6.6.56
 (identical signature on both, so not a 6.12 regression; at least the
 6.6..6.12 LTS span is affected)
Host: x86-64, Xen master/staging (4.23-unstable); also reproduced on an
older commit, so the Xen version does not appear relevant. Plain
`xl save` + `xl restore` of an idle 4-vCPU, 2G PV domU, direct kernel
boot, xvda file-backed disk, one vif. 100% reproducible.

What the resume looks like (full logs available):

 - Capturing the console across a paused restore (`xl restore -p`,
   attach console, unpause) shows all secondary vCPUs immediately
   splatting:

     WARNING: CPU: 1 PID: 0 at kernel/time/timekeeping.c:747
ktime_get+0xa9/0xd0
     ...
      tick_nohz_idle_enter
      do_idle
      cpu_startup_entry
      cpu_bringup_and_idle
      asm_cpu_bringup_and_idle

   i.e. the idle task entering nohz while timekeeping is still
   suspended =E2=80=94 with printk timestamps taken from the *uncorrected*
   clock (pre-suspend time + the save/restore wall-clock gap), while
   CPU0's own subsequent resume messages ("Grant tables using version 1
   layout", from gnttab_resume() inside xen_suspend()) carry the
   *corrected*, earlier timestamp. The secondaries therefore left the
   stop_machine corral before CPU0's post-suspend work inside
   xen_suspend() had run, which the multi_cpu_stop state machine is
   supposed to make impossible.

 - xenctx on the restored-but-still-paused domain shows the vCPU
   contexts are restored faithfully (RIP-for-RIP identical to a probe
   taken at the suspend point: vCPU0 inside the suspend hypercall stub,
   the secondaries inside the multi_cpu_stop corral loop). The
   toolstack is delivering exactly what was saved; the wedge develops
   after unpause, guest-side.

 - End state, stable forever after: vCPU0 spins at 100% inside the
   multi_cpu_stop corral code (per xenctx; `xl vcpu-list` shows r--
   accumulating time), while the secondary vCPUs sit blocked in
   SCHED_block on their idle-task stacks. Because stop_machine() never
   completes, do_suspend() never reaches xen_arch_resume() (so the
   secondaries' local ticks, suspended by xen_arch_suspend() before the
   corral, are never resumed =E2=80=94 nothing will ever wake them) nor
   xs_resume()/dpm_resume_*() (so xenbus frontends never reconnect).

A speculative note on the trigger, from reading the 6.12 code =E2=80=94 tre=
at
as unverified: xen_vcpu_restore() (called from xen_pv_post_suspend()
while the secondaries are mid-corral with virtual interrupts masked)
does VCPUOP_down, re-registers vcpu_info via xen_vcpu_setup_restore(),
then VCPUOP_up on each secondary. If the re-registration ends up with
evtchn_upcall_mask clear in the newly registered vcpu_info, the vCPU
comes back up with an unexpected upcall window mid-corral; stray
exc_xen_hypervisor_callback frames in the secondaries' backtraces are
consistent with that. I stopped root-causing at this point.

Happy to provide the full console logs, xenctx dumps at
suspend/restored-paused/wedged, and the reproduction scripts, or to
test patches.

--0000000000003fa71a0658328abf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>Saving and restoring a multi-vcp=
u PV guest appears to have been broken in Linux for some time (observed 6.6=
.56 and 6.12.86).=C2=A0 Report below from Claude Fable; I&#39;ve independen=
tly verified the behavior on vanilla Linux 6.6.56.=C2=A0 Claude seems to th=
ink it&#39;s a bug in Linux.</div><div><br></div><div>Gitlab CI seems to on=
ly run with vcpus=3D1, which is why it didn&#39;t notice.</div><div><br></d=
iv><div>George Dunlap</div><div>Freelance Xen consultant</div><div><a href=
=3D"https://www.laleolanguage.com/consulting">https://www.laleolanguage.com=
/consulting</a></div><div><br></div><div>8&lt;----</div><div><br></div><div=
>A PV guest with more than one vCPU survives `xl save`, but after<br>`xl re=
store` it never comes back: the kernel wedges mid-resume, before<br>xenbus =
reconnect, so all frontends stay disconnected (netfront frontend<br>state r=
emains XenbusStateInitialising, backend InitWait; vif shows<br>NO-CARRIER i=
n dom0) and the guest is unreachable indefinitely. With<br>vcpus=3D1 the sa=
me guest/image/kernel resumes cleanly, PVH SMP<br>save/restore is fine, and=
 the suspend-cancel path (a failed `xl save`<br>resuming the domain in plac=
e) is also fine.<br><br>Reproduced with:<br>=C2=A0- Debian trixie kernel 6.=
12.86+deb13-amd64<br>=C2=A0- the Xen-project CI test-artifacts kernel, vani=
lla 6.6.56<br>=C2=A0(identical signature on both, so not a 6.12 regression;=
 at least the<br>=C2=A06.6..6.12 LTS span is affected)<br>Host: x86-64, Xen=
 master/staging (4.23-unstable); also reproduced on an<br>older commit, so =
the Xen version does not appear relevant. Plain<br>`xl save` + `xl restore`=
 of an idle 4-vCPU, 2G PV domU, direct kernel<br>boot, xvda file-backed dis=
k, one vif. 100% reproducible.<br><br>What the resume looks like (full logs=
 available):<br><br>=C2=A0- Capturing the console across a paused restore (=
`xl restore -p`,<br>=C2=A0 =C2=A0attach console, unpause) shows all seconda=
ry vCPUs immediately<br>=C2=A0 =C2=A0splatting:<br><br>=C2=A0 =C2=A0 =C2=A0=
WARNING: CPU: 1 PID: 0 at kernel/time/timekeeping.c:747 ktime_get+0xa9/0xd0=
<br>=C2=A0 =C2=A0 =C2=A0...<br>=C2=A0 =C2=A0 =C2=A0 tick_nohz_idle_enter<br=
>=C2=A0 =C2=A0 =C2=A0 do_idle<br>=C2=A0 =C2=A0 =C2=A0 cpu_startup_entry<br>=
=C2=A0 =C2=A0 =C2=A0 cpu_bringup_and_idle<br>=C2=A0 =C2=A0 =C2=A0 asm_cpu_b=
ringup_and_idle<br><br>=C2=A0 =C2=A0i.e. the idle task entering nohz while =
timekeeping is still<br>=C2=A0 =C2=A0suspended =E2=80=94 with printk timest=
amps taken from the *uncorrected*<br>=C2=A0 =C2=A0clock (pre-suspend time +=
 the save/restore wall-clock gap), while<br>=C2=A0 =C2=A0CPU0&#39;s own sub=
sequent resume messages (&quot;Grant tables using version 1<br>=C2=A0 =C2=
=A0layout&quot;, from gnttab_resume() inside xen_suspend()) carry the<br>=
=C2=A0 =C2=A0*corrected*, earlier timestamp. The secondaries therefore left=
 the<br>=C2=A0 =C2=A0stop_machine corral before CPU0&#39;s post-suspend wor=
k inside<br>=C2=A0 =C2=A0xen_suspend() had run, which the multi_cpu_stop st=
ate machine is<br>=C2=A0 =C2=A0supposed to make impossible.<br><br>=C2=A0- =
xenctx on the restored-but-still-paused domain shows the vCPU<br>=C2=A0 =C2=
=A0contexts are restored faithfully (RIP-for-RIP identical to a probe<br>=
=C2=A0 =C2=A0taken at the suspend point: vCPU0 inside the suspend hypercall=
 stub,<br>=C2=A0 =C2=A0the secondaries inside the multi_cpu_stop corral loo=
p). The<br>=C2=A0 =C2=A0toolstack is delivering exactly what was saved; the=
 wedge develops<br>=C2=A0 =C2=A0after unpause, guest-side.<br><br>=C2=A0- E=
nd state, stable forever after: vCPU0 spins at 100% inside the<br>=C2=A0 =
=C2=A0multi_cpu_stop corral code (per xenctx; `xl vcpu-list` shows r--<br>=
=C2=A0 =C2=A0accumulating time), while the secondary vCPUs sit blocked in<b=
r>=C2=A0 =C2=A0SCHED_block on their idle-task stacks. Because stop_machine(=
) never<br>=C2=A0 =C2=A0completes, do_suspend() never reaches xen_arch_resu=
me() (so the<br>=C2=A0 =C2=A0secondaries&#39; local ticks, suspended by xen=
_arch_suspend() before the<br>=C2=A0 =C2=A0corral, are never resumed =E2=80=
=94 nothing will ever wake them) nor<br>=C2=A0 =C2=A0xs_resume()/dpm_resume=
_*() (so xenbus frontends never reconnect).<br><br>A speculative note on th=
e trigger, from reading the 6.12 code =E2=80=94 treat<br>as unverified: xen=
_vcpu_restore() (called from xen_pv_post_suspend()<br>while the secondaries=
 are mid-corral with virtual interrupts masked)<br>does VCPUOP_down, re-reg=
isters vcpu_info via xen_vcpu_setup_restore(),<br>then VCPUOP_up on each se=
condary. If the re-registration ends up with<br>evtchn_upcall_mask clear in=
 the newly registered vcpu_info, the vCPU<br>comes back up with an unexpect=
ed upcall window mid-corral; stray<br>exc_xen_hypervisor_callback frames in=
 the secondaries&#39; backtraces are<br>consistent with that. I stopped roo=
t-causing at this point.<br><br>Happy to provide the full console logs, xen=
ctx dumps at<br>suspend/restored-paused/wedged, and the reproduction script=
s, or to<br>test patches.<br></div></div>

--0000000000003fa71a0658328abf--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:19:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381933.1625361 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007Oj-Fb; Tue, 04 Aug 2026 07:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381933.1625361; Tue, 04 Aug 2026 07:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007Oc-Ca; Tue, 04 Aug 2026 07:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1381933;
 Tue, 04 Aug 2026 07:16:11 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <d@ilvokhin.com>) id 1wr9Nj-0006yt-Gn
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:16:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9Ni-007h56-TR
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:16:10 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191ba-2eae-0a2a0a5409dd-0a2a4506dbb6-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:10 +0200
Received: from [178.62.254.231] (helo=mail.ilvokhin.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191ba-195a-0a2a45060019-b23efee78ee2-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:10 +0200
Received: from localhost.localdomain (shell.ilvokhin.com [138.68.190.75])
 (Authenticated sender: d@ilvokhin.com)
 by mail.ilvokhin.com (Postfix) with ESMTPSA id 24FC1E16D4;
 Tue, 04 Aug 2026 07:16:09 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail header.d=ilvokhin.com header.i="@ilvokhin.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com;
	s=mail; t=1785827769;
	bh=WuLqet5KqDLEqzcC11hIv1M/iVcVPFYVpjgSQGthfWs=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=wuKIY1D4nBbR5uq8gfZNxdmHgxtiW+Zwfk36Z3rrQRTooGhRRML5EXyzobMw0uJxv
	 5P/K81r2u82h7iiaVnYm4EpGO+40bXq+eTassRL9b5566xMP0Fz5dav+H08KKCBg4i
	 JYRM7O6cFcYUV5X3SXyn9SghO75pg22YrPEy33FY=
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Dmitry Ilvokhin <d@ilvokhin.com>
Subject: [PATCH 2/5] locking: Factor out queued_spin_release()
Date: Tue,  4 Aug 2026 07:15:42 +0000
Message-ID: <b8daabae6469ad72cc784a911f6cc43a6d45df3a.1785778551.git.d@ilvokhin.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
References: <cover.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785827770-F78CB77B-E9ACA1BD/0/0
X-purgate-type: clean
X-purgate-size: 2814

The contended_release tracepoint needs to hook queued_spin_unlock(), but
architectures with a custom unlock define queued_spin_unlock() directly,
leaving no single generic place to add the tracing.

Introduce queued_spin_release() as the arch-overridable release
primitive and make queued_spin_unlock() a generic wrapper around it.
An architecture that only customizes the release can then override
queued_spin_release() and inherit the generic wrapper.

Rename the MIPS override to queued_spin_release() accordingly. x86
paravirt overrides queued_spin_unlock() directly and is left unchanged.

No functional change intended.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 arch/mips/include/asm/spinlock.h |  6 +++---
 include/asm-generic/qspinlock.h  | 17 ++++++++++++++---
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/mips/include/asm/spinlock.h b/arch/mips/include/asm/spinlock.h
index 6ce2117e49f6..c349162f15eb 100644
--- a/arch/mips/include/asm/spinlock.h
+++ b/arch/mips/include/asm/spinlock.h
@@ -13,12 +13,12 @@
 
 #include <asm-generic/qspinlock_types.h>
 
-#define	queued_spin_unlock queued_spin_unlock
+#define	queued_spin_release queued_spin_release
 /**
- * queued_spin_unlock - release a queued spinlock
+ * queued_spin_release - release a queued spinlock
  * @lock : Pointer to queued spinlock structure
  */
-static inline void queued_spin_unlock(struct qspinlock *lock)
+static inline void queued_spin_release(struct qspinlock *lock)
 {
 	/* This could be optimised with ARCH_HAS_MMIOWB */
 	mmiowb();
diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index bf47cca2c375..ae45289e8ec7 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -115,12 +115,12 @@ static __always_inline void queued_spin_lock(struct qspinlock *lock)
 }
 #endif
 
-#ifndef queued_spin_unlock
+#ifndef queued_spin_release
 /**
- * queued_spin_unlock - release a queued spinlock
+ * queued_spin_release - release a queued spinlock
  * @lock : Pointer to queued spinlock structure
  */
-static __always_inline void queued_spin_unlock(struct qspinlock *lock)
+static __always_inline void queued_spin_release(struct qspinlock *lock)
 {
 	/*
 	 * unlock() needs release semantics:
@@ -129,6 +129,17 @@ static __always_inline void queued_spin_unlock(struct qspinlock *lock)
 }
 #endif
 
+#ifndef queued_spin_unlock
+/**
+ * queued_spin_unlock - unlock a queued spinlock
+ * @lock : Pointer to queued spinlock structure
+ */
+static __always_inline void queued_spin_unlock(struct qspinlock *lock)
+{
+	queued_spin_release(lock);
+}
+#endif
+
 #ifndef virt_spin_lock
 static __always_inline bool virt_spin_lock(struct qspinlock *lock)
 {
-- 
2.53.0-Meta



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:19:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381937.1625378 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R8-0007ZN-7c; Tue, 04 Aug 2026 07:19:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381937.1625378; Tue, 04 Aug 2026 07:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007Wz-Vh; Tue, 04 Aug 2026 07:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1381937;
 Tue, 04 Aug 2026 07:16:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <d@ilvokhin.com>) id 1wr9Nl-0006z6-2A
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:16:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9Nk-00AVMl-1r
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:16:12 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191b9-bab6-0a2a0a5309dd-0a2a45039b3a-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:12 +0200
Received: from [178.62.254.231] (helo=mail.ilvokhin.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191ba-fae8-0a2a45030019-b23efee7ec10-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:11 +0200
Received: from localhost.localdomain (shell.ilvokhin.com [138.68.190.75])
 (Authenticated sender: d@ilvokhin.com)
 by mail.ilvokhin.com (Postfix) with ESMTPSA id 8F84BE16D9;
 Tue, 04 Aug 2026 07:16:09 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail header.d=ilvokhin.com header.i="@ilvokhin.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com;
	s=mail; t=1785827769;
	bh=fHFQBsOvzK2/mUZmCSCVwo8JOcS+aODOMFtgBaMfo18=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=0OMfUdlqT7tXp+xgFH8Lqhq8QKQ7xel10QLPov1Fj6BEEyus3KjXzGsZvJvOoCmFc
	 HoubPtrG0hOfQ94rwZ6ss/UcnbQNjRe7uPtfYREtEbeVVgOyI7BCepcQi8X/rHThP1
	 7w23gEsazcnNYc12vfymcaG7+J/NylkdvJYVuzVs=
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Dmitry Ilvokhin <d@ilvokhin.com>
Subject: [PATCH 3/5] locking/qspinlock: Add contended_release tracepoint
Date: Tue,  4 Aug 2026 07:15:43 +0000
Message-ID: <0d998e22a0c595f670cfc6725bb683323aced5cb.1785778551.git.d@ilvokhin.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
References: <cover.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785827771-76EF74E9-2C1F7D91/0/0
X-purgate-type: clean
X-purgate-size: 7845

Unlike mutex and rw_semaphore, qspinlock has no owner field, so "perf
lock contention --lock-owner" cannot attribute a contended spinlock to
its holder. The waiter-side contention_begin event records that a
spinlock is contended, but not by whom. Firing contended_release in the
holder's context at unlock is the only way to capture the holder of a
contended spinlock.

Combine the contention check, trace call and release in an out-of-line
queued_spin_release_traced() so the compiler need not preserve the lock
pointer in a callee-saved register across the call.

The check in queued_spin_unlock() is paid on every unlock, even while
the tracepoint is disabled: a static-branch NOP on x86_64, and a few
more instructions to manage a stack frame elsewhere. Gate it behind
CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE (default n) so nobody
pays for a tracepoint they do not use. Sleeping locks fire
contended_release regardless.

On x86 this generic path is used only with PARAVIRT_SPINLOCKS=n (e.g.
defconfig). PARAVIRT_SPINLOCKS=y kernels keep the paravirt static_call
unlock and are wired up separately.

All below are with the QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE option
enabled.

_raw_spin_unlock(), x86_64 defconfig, GCC 11, tracepoint compiled in but
disabled. The unlock is the single 'movb'. The only instruction added to
the executed path is the 2-byte static-branch NOP. The CALL to the
traced helper and the JMP back are emitted out of line and are reached
only once the static branch is patched on:

          endbr64                            ; 4 bytes
          xchg   %ax,%ax                     ; 2 static-branch NOP
                                             ;   (added)
          movb   $0x0,(%rdi)                 ; 3 unlock (single store)
       A: decl   %gs:__preempt_count         ; 7
          je     B                           ; 2
          jmp    __x86_return_thunk          ; 5
          call   queued_spin_release_traced  ; 5 out of line, reached
                                             ;   only when the
                                             ;   tracepoint is on
          jmp    A                           ; 2 (added)
       B: call   __SCT__preempt_schedule     ; 5
          jmp    __x86_return_thunk          ; 5

Baseline is the same stream without the NOP and the out-of-line
CALL/JMP: 31 bytes vs 40 (+9 bytes).

Binary size impact on x86_64, defconfig: +680 bytes (+0.00%), since all
standard configs out-of-line unlock. Architectures with inlined unlock
(s390 (always), csky and loongarch (both when !PREEMPTION)) will see a
bigger increase in binary size.

On the same path (x86_64, PARAVIRT_SPINLOCKS=n) with the tracepoint
disabled, a _raw_spin_unlock()-heavy nginx workload [1] shows no
measurable difference between baseline and patched kernels in
throughput, latency, cycles, instructions, IPC, or L1 instruction-cache
misses (kernel and total): all deltas stay within run-to-run noise.

Unlike x86, on arm64 the frame setup code (STP, MOV and LDP) lands on
the executed path in addition to static-branch NOP. Binary size impact
on arm64, defconfig: +932 bytes (+0.00%).

The _raw_spin_unlock()-heavy nginx workload reflects the larger hot
path: L1 instruction-cache misses rise ~1.4% (kernel and total) and
instruction count ~0.4%, consistent with the per-unlock frame.
cpu_cycles, throughput and latency show no measurable change and are
within run-to-run noise.

Architectures with fully custom qspinlock implementations (e.g.
PowerPC) are not covered by this change.

[1]: https://lore.kernel.org/all/aiphFXe_TPNPxZ_n@shell.ilvokhin.com/

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 include/asm-generic/qspinlock.h | 21 +++++++++++++++++++++
 kernel/Kconfig.locks            | 20 ++++++++++++++++++++
 kernel/locking/qspinlock.c      | 22 ++++++++++++++++++++++
 3 files changed, 63 insertions(+)

diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index ae45289e8ec7..2ca94e41823b 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -41,6 +41,7 @@
 
 #include <asm-generic/qspinlock_types.h>
 #include <linux/atomic.h>
+#include <linux/tracepoint-defs.h>
 
 #ifndef queued_spin_is_locked
 /**
@@ -130,12 +131,32 @@ static __always_inline void queued_spin_release(struct qspinlock *lock)
 #endif
 
 #ifndef queued_spin_unlock
+
+DECLARE_TRACEPOINT(contended_release);
+
+extern void queued_spin_release_traced(struct qspinlock *lock);
+
 /**
  * queued_spin_unlock - unlock a queued spinlock
  * @lock : Pointer to queued spinlock structure
+ *
+ * Generic tracing wrapper around the arch-overridable
+ * queued_spin_release().
  */
 static __always_inline void queued_spin_unlock(struct qspinlock *lock)
 {
+	/*
+	 * Trace and release are combined in queued_spin_release_traced() so
+	 * the compiler does not need to preserve the lock pointer across the
+	 * function call, avoiding callee-saved register save/restore on the
+	 * hot path. queued_spin_release() is therefore called both here and in
+	 * queued_spin_release_traced(). Keep the two in sync.
+	 */
+	if (IS_ENABLED(CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE) &&
+	    tracepoint_enabled(contended_release)) {
+		queued_spin_release_traced(lock);
+		return;
+	}
 	queued_spin_release(lock);
 }
 #endif
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index 4198f0273ecd..1c6423aafcd4 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -243,6 +243,26 @@ config QUEUED_SPINLOCKS
 	def_bool y if ARCH_USE_QUEUED_SPINLOCKS
 	depends on SMP
 
+config QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE
+	bool "Trace contended_release on queued spinlocks"
+	depends on QUEUED_SPINLOCKS && TRACEPOINTS
+	help
+	  Fire the lock:contended_release tracepoint when a contended queued
+	  spinlock is released, so it is possible to attribute a contended
+	  spinlock to its holder.
+
+	  Architectures that can patch the unlock site do this at no cost and
+	  do not need this option.
+
+	  Everywhere else the check is compiled into queued_spin_unlock() and
+	  a small cost is paid on every unlock even when the tracepoint is
+	  disabled: a static-branch NOP and possibly a few more instructions
+	  to manage a stack frame.
+
+	  Sleeping locks fire lock:contended_release regardless of this option.
+
+	  If unsure, say N.
+
 config BPF_ARCH_SPINLOCK
 	bool
 
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index af8d122bb649..33fe6d437c8f 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -104,6 +104,28 @@ static __always_inline u32  __pv_wait_head_or_lock(struct qspinlock *lock,
 #define queued_spin_lock_slowpath	native_queued_spin_lock_slowpath
 #endif
 
+#if !defined(queued_spin_unlock) && \
+	IS_ENABLED(CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE)
+/*
+ * Out-of-line trace-and-release path for queued_spin_unlock(), used when
+ * the contended_release tracepoint is enabled.
+ *
+ * queued_spin_release() is duplicated here on purpose: doing the release
+ * in this function (rather than tracing here and releasing in the caller)
+ * lets queued_spin_unlock() return right after the call, so the
+ * tracepoint-disabled hot path never has to keep lock live across a call
+ * in a callee-saved register. Keep this release in sync with the one in
+ * queued_spin_unlock().
+ */
+void __lockfunc queued_spin_release_traced(struct qspinlock *lock)
+{
+	if (queued_spin_is_contended(lock))
+		trace_call__contended_release(lock);
+	queued_spin_release(lock);
+}
+EXPORT_SYMBOL(queued_spin_release_traced);
+#endif
+
 #endif /* _GEN_PV_LOCK_SLOWPATH */
 
 /**
-- 
2.53.0-Meta



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:19:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381934.1625367 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007RK-NL; Tue, 04 Aug 2026 07:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381934.1625367; Tue, 04 Aug 2026 07:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007Qr-IG; Tue, 04 Aug 2026 07:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1381934;
 Tue, 04 Aug 2026 07:16:12 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <d@ilvokhin.com>) id 1wr9Nk-0006yz-1Z
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:16:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9Nj-005IZo-EK
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:16:11 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191b8-e002-0a2a0a5209dd-0a2a4509d848-18
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:11 +0200
Received: from [178.62.254.231] (helo=mail.ilvokhin.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191bb-be1a-0a2a45090019-b23efee783a0-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:11 +0200
Received: from localhost.localdomain (shell.ilvokhin.com [138.68.190.75])
 (Authenticated sender: d@ilvokhin.com)
 by mail.ilvokhin.com (Postfix) with ESMTPSA id 05AB4E16DC;
 Tue, 04 Aug 2026 07:16:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail header.d=ilvokhin.com header.i="@ilvokhin.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com;
	s=mail; t=1785827770;
	bh=Bz2CpdeYvHJ4wdtpHF06PqmuJczwotX2rk+VZpOkhHc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=pap3mJ3/HxJEJFDk1E9V+MfQ4ojuK31y3RhNzciiECTAVYuygUg+AAUpw8Vg2iPD9
	 bo0bIm+yzmE6QIWLIch8VLiCc2NJUocvXXQ2cbg2o8M207KKA1P5DizNPLx/31xYgC
	 RZ1Z6my1XJzOWuENeYHFx8DmI08HwyPl+3SWt/mM=
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Dmitry Ilvokhin <d@ilvokhin.com>
Subject: [PATCH 4/5] tracing/lock: Use TRACE_EVENT_FN() for contended_release
Date: Tue,  4 Aug 2026 07:15:44 +0000
Message-ID: <1c2fcccfb584c075c02890c484f22c76a1948bf1.1785778551.git.d@ilvokhin.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
References: <cover.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785827771-3ACDF034-F8BD3241/0/0
X-purgate-type: clean
X-purgate-size: 2205

queued_spin_unlock() gates its contended_release trace call behind a
static branch, so a NOP sits on the unlock path even while the
tracepoint is disabled. Removing that requires replacing the unlock
implementation only while contended_release is enabled, which needs a
callback when the tracepoint is toggled.

Convert contended_release to TRACE_EVENT_FN() and add weak no-op
arch_contended_release_trace_reg()/arch_contended_release_trace_unreg()
hooks.

The default hooks are empty, so this is a no-op until an architecture
overrides them.

No functional change intended.

Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 include/trace/events/lock.h | 10 ++++++++--
 kernel/locking/mutex.c      |  4 ++++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/lock.h b/include/trace/events/lock.h
index 1ded869cd619..b1d5b18c4514 100644
--- a/include/trace/events/lock.h
+++ b/include/trace/events/lock.h
@@ -137,7 +137,11 @@ TRACE_EVENT(contention_end,
 	TP_printk("%p (ret=%d)", __entry->lock_addr, __entry->ret)
 );
 
-TRACE_EVENT(contended_release,
+/* kernel/locking/mutex.c */
+int arch_contended_release_trace_reg(void);
+void arch_contended_release_trace_unreg(void);
+
+TRACE_EVENT_FN(contended_release,
 
 	TP_PROTO(void *lock),
 
@@ -151,7 +155,9 @@ TRACE_EVENT(contended_release,
 		__entry->lock_addr = lock;
 	),
 
-	TP_printk("%p", __entry->lock_addr)
+	TP_printk("%p", __entry->lock_addr),
+
+	arch_contended_release_trace_reg, arch_contended_release_trace_unreg
 );
 
 #endif /* _TRACE_LOCK_H */
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 8a85912d7ee6..942a939cee95 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -1272,6 +1272,10 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(contention_begin);
 EXPORT_TRACEPOINT_SYMBOL_GPL(contention_end);
 EXPORT_TRACEPOINT_SYMBOL_GPL(contended_release);
 
+__weak int arch_contended_release_trace_reg(void) { return 0; }
+
+__weak void arch_contended_release_trace_unreg(void) { }
+
 /**
  * atomic_dec_and_mutex_lock - return holding mutex if we dec to 0
  * @cnt: the atomic which we are to dec
-- 
2.53.0-Meta



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:19:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381935.1625374 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007UM-VY; Tue, 04 Aug 2026 07:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381935.1625374; Tue, 04 Aug 2026 07:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9R7-0007TL-OR; Tue, 04 Aug 2026 07:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1381935;
 Tue, 04 Aug 2026 07:16:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <d@ilvokhin.com>) id 1wr9Nk-0006z4-Bz
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:16:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9Nj-007h56-P3
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:16:11 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191b0-2eae-0a2a0a5409dd-0a2a450781e2-34
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:11 +0200
Received: from [178.62.254.231] (helo=mail.ilvokhin.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191bb-b4ea-0a2a45070019-b23efee7e7da-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:11 +0200
Received: from localhost.localdomain (shell.ilvokhin.com [138.68.190.75])
 (Authenticated sender: d@ilvokhin.com)
 by mail.ilvokhin.com (Postfix) with ESMTPSA id 77194E16E0;
 Tue, 04 Aug 2026 07:16:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail header.d=ilvokhin.com header.i="@ilvokhin.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com;
	s=mail; t=1785827770;
	bh=MJXFdixHataYYt87xEtn0QdfMJOi3nH/EXHHrFBbQBU=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=YCa2mhDCHjFFX0O6d3S1tYEYBR/Jb4ai4lQlH0qCvYfntcHb1/+MEaIyrBX3QT0u1
	 jViT9cjtE41ag6sP28YwsfmBHSjMYS3PwUlLcqd8dqfNVR1ReEl98E/Q9nIoYF3BTz
	 G+fzkT2LOVauhNUbkR9kOT4y87KoehBEuITFVAbI=
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Dmitry Ilvokhin <d@ilvokhin.com>
Subject: [PATCH 5/5] x86/paravirt: Trace contended_release on unlock
Date: Tue,  4 Aug 2026 07:15:45 +0000
Message-ID: <17fa67f9fa4cf93f1150725e89f5f916e41a9b6f.1785778551.git.d@ilvokhin.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
References: <cover.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785827771-A60C5AE4-2400FED8/0/0
X-purgate-type: clean
X-purgate-size: 4667

On PARAVIRT_SPINLOCKS=y kernels queued_spin_unlock() is dispatched
through a static_call(). Those PARAVIRT_SPINLOCKS=y kernels are quite
popular. Gating contended_release behind a static branch would leave a
NOP on the unlock hot path even, when the tracepoint is disabled.

Since the static_call() is already present, swap its target to a traced
unlock, when the tracepoint is enabled instead. When contended_release
tracepoint is disabled the target is the plain unlock (an inline store
on native x86_64), so the unlock path is unchanged and the tracepoint is
truly zero-cost.

Provide two traced variants, native_queued_spin_unlock_traced() and
pv_queued_spin_unlock_traced(), so each tail-calls its own base unlock
directly rather than recursing through the now-traced static_call().

Teach pv_is_native_spin_unlock() that the traced native variant still
counts as native.

Only PARAVIRT_SPINLOCKS=y is affected. PARAVIRT_SPINLOCKS=n keeps the
generic static-branch path.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 arch/x86/include/asm/paravirt-spinlock.h |  2 +
 arch/x86/kernel/paravirt-spinlocks.c     | 53 +++++++++++++++++++++++-
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt-spinlock.h b/arch/x86/include/asm/paravirt-spinlock.h
index ff735830de4a..302bc2ba3a75 100644
--- a/arch/x86/include/asm/paravirt-spinlock.h
+++ b/arch/x86/include/asm/paravirt-spinlock.h
@@ -99,6 +99,8 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
 
 void __init native_pv_lock_init(void);
 __visible void __native_queued_spin_unlock(struct qspinlock *lock);
+__visible void native_queued_spin_unlock_traced(struct qspinlock *lock);
+__visible void pv_queued_spin_unlock_traced(struct qspinlock *lock);
 bool pv_is_native_spin_unlock(void);
 __visible bool __native_vcpu_is_preempted(long cpu);
 bool pv_is_native_vcpu_is_preempted(void);
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index ddc19dc28ba1..ca12b3655307 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -7,6 +7,7 @@
 #include <linux/spinlock.h>
 #include <linux/export.h>
 #include <linux/jump_label.h>
+#include <trace/events/lock.h>
 
 DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
 
@@ -30,10 +31,58 @@ EXPORT_STATIC_CALL_TRAMP(queued_spin_lock_slowpath);
 DEFINE_STATIC_CALL(queued_spin_unlock, __raw_callee_save___native_queued_spin_unlock);
 EXPORT_STATIC_CALL_TRAMP(queued_spin_unlock);
 
+/*
+ * Traced unlock variants, swapped in via static_call while the
+ * contended_release tracepoint is enabled. Two of them, so each tail calls its
+ * own base directly.
+ */
+__visible void native_queued_spin_unlock_traced(struct qspinlock *lock)
+{
+	if (queued_spin_is_contended(lock))
+		trace_call__contended_release(lock);
+	native_queued_spin_unlock(lock);
+}
+PV_CALLEE_SAVE_REGS_THUNK(native_queued_spin_unlock_traced);
+
+__visible void pv_queued_spin_unlock_traced(struct qspinlock *lock)
+{
+	if (queued_spin_is_contended(lock))
+		trace_call__contended_release(lock);
+	__raw_callee_save___pv_queued_spin_unlock(lock);
+}
+PV_CALLEE_SAVE_REGS_THUNK(pv_queued_spin_unlock_traced);
+
 bool pv_is_native_spin_unlock(void)
 {
-	return static_call_query(queued_spin_unlock) ==
-		__raw_callee_save___native_queued_spin_unlock;
+	void *unlock = static_call_query(queued_spin_unlock);
+
+	return unlock == __raw_callee_save___native_queued_spin_unlock ||
+	       unlock == __raw_callee_save_native_queued_spin_unlock_traced;
+}
+
+int arch_contended_release_trace_reg(void)
+{
+	void *cur = static_call_query(queued_spin_unlock);
+
+	if (cur == __raw_callee_save___native_queued_spin_unlock)
+		static_call_update(queued_spin_unlock,
+				   __raw_callee_save_native_queued_spin_unlock_traced);
+	else if (cur == __raw_callee_save___pv_queued_spin_unlock)
+		static_call_update(queued_spin_unlock,
+				   __raw_callee_save_pv_queued_spin_unlock_traced);
+	return 0;
+}
+
+void arch_contended_release_trace_unreg(void)
+{
+	void *cur = static_call_query(queued_spin_unlock);
+
+	if (cur == __raw_callee_save_native_queued_spin_unlock_traced)
+		static_call_update(queued_spin_unlock,
+				   __raw_callee_save___native_queued_spin_unlock);
+	else if (cur == __raw_callee_save_pv_queued_spin_unlock_traced)
+		static_call_update(queued_spin_unlock,
+				   __raw_callee_save___pv_queued_spin_unlock);
 }
 
 __visible bool __native_vcpu_is_preempted(long cpu)
-- 
2.53.0-Meta



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:25:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:25:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381968.1625398 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9WS-000278-Pc; Tue, 04 Aug 2026 07:25:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381968.1625398; Tue, 04 Aug 2026 07:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9WS-000271-Mv; Tue, 04 Aug 2026 07:25:12 +0000
Received: by outflank-mailman (input) for mailman id 1381968;
 Tue, 04 Aug 2026 07:25:11 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <d@ilvokhin.com>) id 1wr9WR-00026p-4O
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:25:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9WQ-007it1-Cm
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:25:10 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7193c6-2eae-0a2a0a5409dd-0a2a4501af2e-40
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:25:10 +0200
Received: from [178.62.254.231] (helo=mail.ilvokhin.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191b9-5984-0a2a45010019-b23efee7b86e-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:09 +0200
Received: from localhost.localdomain (shell.ilvokhin.com [138.68.190.75])
 (Authenticated sender: d@ilvokhin.com)
 by mail.ilvokhin.com (Postfix) with ESMTPSA id 48833E16CF;
 Tue, 04 Aug 2026 07:16:08 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail header.d=ilvokhin.com header.i="@ilvokhin.com" header.h="From:To:Cc:Subject:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com;
	s=mail; t=1785827768;
	bh=C36dNKMErd6fEDuyOzYmXnXLzsDFA2rEQeKm0PrIEwU=;
	h=From:To:Cc:Subject:Date;
	b=zuuQlk9HFx1s4aMIaXtgkNF/m3YJ86B2QbZ83bIHeVzXGJfBm3WQ9v5qi06ycUsSA
	 y8MsnTc4o0Lw3f7cazZ6t3ZC6FpEzOcBi4/n2bvgLJMepXG/4Pg6/7hQIy/DJBPKo1
	 3AcjhlumYX+Odef7Y8fxkp0G8LLBWqmj0Tg/agbQ=
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Dmitry Ilvokhin <d@ilvokhin.com>
Subject: [PATCH 0/5] locking/qspinlock: Add contended_release tracepoint
Date: Tue,  4 Aug 2026 07:15:40 +0000
Message-ID: <cover.1785778551.git.d@ilvokhin.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785827769-C4558757-279072D9/13/0
X-purgate-type: clean
X-purgate-size: 4019

The contended_release tracepoint landed in v7.2-rc2 for sleeping locks
(4f070ccb4dc4 "locking: Add contended_release tracepoint to sleepable
locks"). Spinlock support was dropped from that series. This one adds it
for queued spinlocks.

The existing contention_begin/contention_end tracepoints fire on the
waiter side. The holder's identity and stack can be captured at
contention_begin time (e.g. perf lock contention --lock-owner), but only
for locks with an owner field to read: mutex and rwsem. qspinlock has
none, so a contended spinlock cannot be attributed to its holder at all.
Even where the owner can be read, it reflects the holder's state when a
waiter arrives, not when the lock is released.

This series adds a contended_release tracepoint to qspinlock that fires
on the holder side when a lock with waiters is released. This provides:

- Hold time estimation: when the holder's own acquisition was
  contended, its contention_end (acquisition) and contended_release
  can be correlated to measure how long the lock was held under
  contention.

- The holder's stack at release time, which for spinlocks is not
  available by any other means.

The unlock path might be quite hot, so the tracepoint is made as cheap
as possible, to keep it usable in production:

- x86 with PARAVIRT_SPINLOCKS=y, which is what distributions ship, swaps
  the unlock implementation via static_call() when the tracepoint is
  enabled. The disabled path is byte-identical to today's: the same
  inline movb, no NOP and no call.

- Everywhere else a static-branch check is compiled into
  queued_spin_unlock(). On x86_64 that is a single NOP on the executed
  path, with the call to the traced helper emitted out of line and
  unreachable while the tracepoint is off. On other architectures a few
  more instructions to manage a stack frame land on the executed path
  too, so the generic path sits behind
  CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE (default n).

Costs and measurements are in the individual changelogs. Briefly, no
throughput or latency change is measurable on either x86_64 or arm64
with QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE=y.

Tested: x86_64 with PARAVIRT_SPINLOCKS=y and =n, arm64, tracepoint on
and off, disassembly checked in both states, locktorture with tracepoint
on and off.

Not covered: qrwlock, and architectures with fully custom qspinlock
implementations (e.g. PowerPC). The stack frame managing instructions on
arm64 should be avoidable, but that is not done in this patchset.

Patch 1 is Peter's draft from [1] and is missing his Signed-off-by.
Peter, please add it if you are happy with the patch.

[1]: https://lore.kernel.org/all/20260603120811.GW3493090@noisy.programming.kicks-ass.net/

Dmitry Ilvokhin (4):
  locking: Factor out queued_spin_release()
  locking/qspinlock: Add contended_release tracepoint
  tracing/lock: Use TRACE_EVENT_FN() for contended_release
  x86/paravirt: Trace contended_release on unlock

Peter Zijlstra (1):
  x86/paravirt: Use static_call() for the paravirt spinlock ops

 arch/mips/include/asm/spinlock.h         |  6 +--
 arch/x86/hyperv/hv_spinlock.c            |  4 +-
 arch/x86/include/asm/cpufeatures.h       |  1 -
 arch/x86/include/asm/paravirt-spinlock.h | 21 +++++---
 arch/x86/kernel/kvm.c                    |  5 +-
 arch/x86/kernel/paravirt-spinlocks.c     | 63 +++++++++++++++++++++---
 arch/x86/kernel/static_call.c            | 27 ++++++++++
 arch/x86/xen/spinlock.c                  |  5 +-
 include/asm-generic/qspinlock.h          | 38 ++++++++++++--
 include/trace/events/lock.h              | 10 +++-
 kernel/Kconfig.locks                     | 20 ++++++++
 kernel/locking/mutex.c                   |  4 ++
 kernel/locking/qspinlock.c               | 22 +++++++++
 tools/arch/x86/include/asm/cpufeatures.h |  1 -
 14 files changed, 195 insertions(+), 32 deletions(-)


base-commit: 5e601ab3615c86be7c4068ce992f94654693a032
-- 
2.53.0-Meta



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:25:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:25:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381969.1625402 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9WT-00028s-04; Tue, 04 Aug 2026 07:25:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381969.1625402; Tue, 04 Aug 2026 07:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9WS-00028U-TB; Tue, 04 Aug 2026 07:25:12 +0000
Received: by outflank-mailman (input) for mailman id 1381969;
 Tue, 04 Aug 2026 07:25:11 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <d@ilvokhin.com>) id 1wr9WR-00026v-Hg
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:25:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9WQ-007nMH-R7
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:25:10 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7193c6-2eae-0a2a0a5409dd-0a2a4501af2e-44
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:25:10 +0200
Received: from [178.62.254.231] (helo=mail.ilvokhin.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <d@ilvokhin.com>)
 id 6a7191b9-5984-0a2a45010019-b23efee7e792-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:16:09 +0200
Received: from localhost.localdomain (shell.ilvokhin.com [138.68.190.75])
 (Authenticated sender: d@ilvokhin.com)
 by mail.ilvokhin.com (Postfix) with ESMTPSA id AF538E16D0;
 Tue, 04 Aug 2026 07:16:08 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail header.d=ilvokhin.com header.i="@ilvokhin.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com;
	s=mail; t=1785827769;
	bh=Hgqlc//hwpz+K1crcBkrYPgGS5kJOu9yEyqJUnHTuno=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=FVNDO3r4J4MOXT5qmRaXYUu2pNzl9ZurajzLzmFoGAVSzfbChQnc8xUZc5dM6cHjl
	 dl4A/X2nBgfn5GZv2d97IF3LH92AggOHh7cpwlOahEJLSUKNdgOV9q4kQ+BBqIcgV2
	 hjQ84vsVQbCOHXjwIMxPrXZCCUeUGcpJzNJ/G9uA=
From: Dmitry Ilvokhin <d@ilvokhin.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org,
	linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	virtualization@lists.linux.dev,
	kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com,
	Dmitry Ilvokhin <d@ilvokhin.com>
Subject: [PATCH 1/5] x86/paravirt: Use static_call() for the paravirt spinlock ops
Date: Tue,  4 Aug 2026 07:15:41 +0000
Message-ID: <9a32ae399eb804a02a31af04dcabe7e7ee4f3fdf.1785778551.git.d@ilvokhin.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
References: <cover.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785827769-BF262757-BC7EE8D0/13/0
X-purgate-type: clean
X-purgate-size: 10838

From: Peter Zijlstra <peterz@infradead.org>

queued_spin_lock_slowpath() and queued_spin_unlock() are dispatched
through pv_ops_lock via the paravirt-ops ALTERNATIVE machinery, which
picks the target (native inline store / hypervisor call) once at boot
and cannot change at runtime.

Convert both to static_call(). The site becomes a direct call patched in
place (one byte smaller), and on native the unlock still collapses to
the inline "movb $0, (%rdi)" store, so the fast path is unchanged.

Unlike the ALTERNATIVE mechanism, a static_call() target can also be
updated at runtime via static_call_update(). This is a prerequisite for
the contended_release tracepoint, which has to swap in a traced unlock
while the system is running.

[ ilvokhin: commit message; fix PARAVIRT_SPINLOCKS=n build; teach
  __static_call_validate() about the inline unlock insn; make the
  slowpath site module-safe: static_call_mod() +
  EXPORT_STATIC_CALL_TRAMP(); pass @lock to the callee-save unlock,
  fixing a boot hang under CALL_DEPTH_TRACKING. Boot tested native + KVM
  PV guest. ]

Link: https://lore.kernel.org/all/20260603120811.GW3493090@noisy.programming.kicks-ass.net/
Co-developed-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
---
 arch/x86/hyperv/hv_spinlock.c            |  4 ++--
 arch/x86/include/asm/cpufeatures.h       |  1 -
 arch/x86/include/asm/paravirt-spinlock.h | 19 +++++++++++------
 arch/x86/kernel/kvm.c                    |  5 ++---
 arch/x86/kernel/paravirt-spinlocks.c     | 12 +++++------
 arch/x86/kernel/static_call.c            | 27 ++++++++++++++++++++++++
 arch/x86/xen/spinlock.c                  |  5 ++---
 tools/arch/x86/include/asm/cpufeatures.h |  1 -
 8 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 210b494e4de0..6b4bdea18218 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -78,8 +78,8 @@ void __init hv_init_spinlocks(void)
 	pr_info("PV spinlocks enabled\n");
 
 	__pv_init_lock_hash();
-	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops_lock.queued_spin_unlock = PV_CALLEE_SAVE(__pv_queued_spin_unlock);
+	static_call_update(queued_spin_lock_slowpath, __pv_queued_spin_lock_slowpath);
+	static_call_update(queued_spin_unlock, __raw_callee_save___pv_queued_spin_unlock);
 	pv_ops_lock.wait = hv_qlock_wait;
 	pv_ops_lock.kick = hv_qlock_kick;
 	pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(hv_vcpu_is_preempted);
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 1b4a48bff18f..e41fe5c24841 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -225,7 +225,6 @@
 #define X86_FEATURE_EPT_AD		( 8*32+17) /* "ept_ad" Intel Extended Page Table access-dirty bit */
 #define X86_FEATURE_VMCALL		( 8*32+18) /* Hypervisor supports the VMCALL instruction */
 #define X86_FEATURE_VMW_VMMCALL		( 8*32+19) /* VMware prefers VMMCALL hypercall instruction */
-#define X86_FEATURE_PVUNLOCK		( 8*32+20) /* PV unlock function */
 #define X86_FEATURE_VCPUPREEMPT		( 8*32+21) /* PV vcpu_is_preempted function */
 #define X86_FEATURE_TDX_GUEST		( 8*32+22) /* "tdx_guest" Intel Trust Domain Extensions Guest */
 
diff --git a/arch/x86/include/asm/paravirt-spinlock.h b/arch/x86/include/asm/paravirt-spinlock.h
index 7beffcb08ed6..ff735830de4a 100644
--- a/arch/x86/include/asm/paravirt-spinlock.h
+++ b/arch/x86/include/asm/paravirt-spinlock.h
@@ -3,6 +3,7 @@
 #define _ASM_X86_PARAVIRT_SPINLOCK_H
 
 #include <asm/paravirt_types.h>
+#include <linux/static_call_types.h>
 
 #ifdef CONFIG_SMP
 #include <asm/spinlock_types.h>
@@ -11,9 +12,6 @@
 struct qspinlock;
 
 struct pv_lock_ops {
-	void (*queued_spin_lock_slowpath)(struct qspinlock *lock, u32 val);
-	struct paravirt_callee_save queued_spin_unlock;
-
 	void (*wait)(u8 *ptr, u8 val);
 	void (*kick)(int cpu);
 
@@ -26,20 +24,27 @@ extern struct pv_lock_ops pv_ops_lock;
 extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
 extern void __pv_init_lock_hash(void);
 extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __raw_callee_save___native_queued_spin_unlock(struct qspinlock *lock);
 extern void __raw_callee_save___pv_queued_spin_unlock(struct qspinlock *lock);
 extern bool nopvspin;
 
+DECLARE_STATIC_CALL(queued_spin_lock_slowpath, native_queued_spin_lock_slowpath);
+DECLARE_STATIC_CALL(queued_spin_unlock, __raw_callee_save___native_queued_spin_unlock);
+
 static __always_inline void pv_queued_spin_lock_slowpath(struct qspinlock *lock,
 							 u32 val)
 {
-	PVOP_VCALL2(pv_ops_lock, queued_spin_lock_slowpath, lock, val);
+	static_call_mod(queued_spin_lock_slowpath)(lock, val);
 }
 
 static __always_inline void pv_queued_spin_unlock(struct qspinlock *lock)
 {
-	PVOP_ALT_VCALLEE1(pv_ops_lock, queued_spin_unlock, lock,
-			  "movb $0, (%%" _ASM_ARG1 ")",
-			  ALT_NOT(X86_FEATURE_PVUNLOCK));
+	PVOP_CALL_ARGS;
+	__STATIC_CALL_MOD_ADDRESSABLE(queued_spin_unlock);
+	asm volatile ("call " STATIC_CALL_TRAMP_STR(queued_spin_unlock)
+		      : PVOP_VCALLEE_CLOBBERS, ASM_CALL_CONSTRAINT
+		      : PVOP_CALL_ARG1(lock)
+		      : "memory", "cc");
 }
 
 static __always_inline bool pv_vcpu_is_preempted(long cpu)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index dcef84da304b..253c159c4abe 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -1136,9 +1136,8 @@ void __init kvm_spinlock_init(void)
 	pr_info("PV spinlocks enabled\n");
 
 	__pv_init_lock_hash();
-	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops_lock.queued_spin_unlock =
-		PV_CALLEE_SAVE(__pv_queued_spin_unlock);
+	static_call_update(queued_spin_lock_slowpath, __pv_queued_spin_lock_slowpath);
+	static_call_update(queued_spin_unlock, __raw_callee_save___pv_queued_spin_unlock);
 	pv_ops_lock.wait = kvm_wait;
 	pv_ops_lock.kick = kvm_kick_cpu;
 
diff --git a/arch/x86/kernel/paravirt-spinlocks.c b/arch/x86/kernel/paravirt-spinlocks.c
index 95452444868f..ddc19dc28ba1 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -25,9 +25,14 @@ __visible void __native_queued_spin_unlock(struct qspinlock *lock)
 }
 PV_CALLEE_SAVE_REGS_THUNK(__native_queued_spin_unlock);
 
+DEFINE_STATIC_CALL(queued_spin_lock_slowpath, native_queued_spin_lock_slowpath);
+EXPORT_STATIC_CALL_TRAMP(queued_spin_lock_slowpath);
+DEFINE_STATIC_CALL(queued_spin_unlock, __raw_callee_save___native_queued_spin_unlock);
+EXPORT_STATIC_CALL_TRAMP(queued_spin_unlock);
+
 bool pv_is_native_spin_unlock(void)
 {
-	return pv_ops_lock.queued_spin_unlock.func ==
+	return static_call_query(queued_spin_unlock) ==
 		__raw_callee_save___native_queued_spin_unlock;
 }
 
@@ -45,16 +50,11 @@ bool pv_is_native_vcpu_is_preempted(void)
 
 void __init paravirt_set_cap(void)
 {
-	if (!pv_is_native_spin_unlock())
-		setup_force_cpu_cap(X86_FEATURE_PVUNLOCK);
-
 	if (!pv_is_native_vcpu_is_preempted())
 		setup_force_cpu_cap(X86_FEATURE_VCPUPREEMPT);
 }
 
 struct pv_lock_ops pv_ops_lock = {
-	.queued_spin_lock_slowpath	= native_queued_spin_lock_slowpath,
-	.queued_spin_unlock		= PV_CALLEE_SAVE(__native_queued_spin_unlock),
 	.wait				= paravirt_nop,
 	.kick				= paravirt_nop,
 	.vcpu_is_preempted		= PV_CALLEE_SAVE(__native_vcpu_is_preempted),
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index 61592e41a6b1..bab9406e6d6a 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -4,6 +4,12 @@
 #include <linux/bug.h>
 #include <asm/text-patching.h>
 
+/* Declared locally to avoid pulling asm/paravirt-spinlock.h header. */
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+struct qspinlock;
+void __raw_callee_save___native_queued_spin_unlock(struct qspinlock *lock);
+#endif
+
 enum insn_type {
 	CALL = 0, /* site call */
 	NOP = 1,  /* site cond-call */
@@ -31,6 +37,17 @@ static const u8 retinsn[] = { RET_INSN_OPCODE, 0xcc, 0xcc, 0xcc, 0xcc };
  */
 static const u8 warninsn[] = { 0x67, 0x48, 0x0f, 0xb9, 0x3a };
 
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+/*
+ * ds ds movb $0, (_ASM_ARG1)
+ */
+#ifdef CONFIG_64BIT
+static const u8 unlockinsn[] = { 0x3e, 0x3e, 0xc6, 0x07, 0x00 };
+#else
+static const u8 unlockinsn[] = { 0x3e, 0x3e, 0xc6, 0x00, 0x00 };
+#endif
+#endif
+
 static u8 __is_Jcc(u8 *insn) /* Jcc.d32 */
 {
 	u8 ret = 0;
@@ -78,6 +95,12 @@ static void __ref __static_call_transform(void *insn, enum insn_type type,
 			emulate = code;
 			code = &warninsn;
 		}
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+		if (func == &__raw_callee_save___native_queued_spin_unlock) {
+			emulate = code;
+			code = &unlockinsn;
+		}
+#endif
 		break;
 
 	case NOP:
@@ -139,6 +162,10 @@ static void __static_call_validate(u8 *insn, bool tail, bool tramp)
 		    !memcmp(insn, xor5rax, 5) ||
 		    !memcmp(insn, warninsn, 5))
 			return;
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+		if (!memcmp(insn, unlockinsn, 5))
+			return;
+#endif
 	}
 
 	/*
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83ac24ead289..f718e535ea7c 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -134,9 +134,8 @@ void __init xen_init_spinlocks(void)
 	printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
 
 	__pv_init_lock_hash();
-	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
-	pv_ops_lock.queued_spin_unlock =
-		PV_CALLEE_SAVE(__pv_queued_spin_unlock);
+	static_call_update(queued_spin_lock_slowpath, __pv_queued_spin_lock_slowpath);
+	static_call_update(queued_spin_unlock, __raw_callee_save___pv_queued_spin_unlock);
 	pv_ops_lock.wait = xen_qlock_wait;
 	pv_ops_lock.kick = xen_qlock_kick;
 	pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen);
diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/include/asm/cpufeatures.h
index 86d17b195e79..61541f042f74 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -225,7 +225,6 @@
 #define X86_FEATURE_EPT_AD		( 8*32+17) /* "ept_ad" Intel Extended Page Table access-dirty bit */
 #define X86_FEATURE_VMCALL		( 8*32+18) /* Hypervisor supports the VMCALL instruction */
 #define X86_FEATURE_VMW_VMMCALL		( 8*32+19) /* VMware prefers VMMCALL hypercall instruction */
-#define X86_FEATURE_PVUNLOCK		( 8*32+20) /* PV unlock function */
 #define X86_FEATURE_VCPUPREEMPT		( 8*32+21) /* PV vcpu_is_preempted function */
 #define X86_FEATURE_TDX_GUEST		( 8*32+22) /* "tdx_guest" Intel Trust Domain Extensions Guest */
 
-- 
2.53.0-Meta



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 07:53:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 07:53:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1381986.1625416 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9y5-00082X-6Y; Tue, 04 Aug 2026 07:53:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1381986.1625416; Tue, 04 Aug 2026 07:53:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wr9y5-00082Q-3d; Tue, 04 Aug 2026 07:53:45 +0000
Received: by outflank-mailman (input) for mailman id 1381986;
 Tue, 04 Aug 2026 07:53:44 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wr9y4-00082K-GR
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 07:53:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wr9y3-007p01-Q2
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:53:43 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a719a7f-5cb7-0a2a0a5109dd-0a2a450ab1ae-28
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:53:43 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a719a86-f2d2-0a2a450a0019-d1558032b9f6-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:53:42 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4954a2e73a9so17436055e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 00:53:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b8d04fsm424536895e9.3.2026.08.04.00.53.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 00:53:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785830022; x=1786434822; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0V9nSUKv/Tdm/jG0nL5ZJn57YHMdk7QgzcpAmuCQNyo=;
        b=K/y+m01L4Os4X++fxrQPHHrAn63rJOE/hDKd//miu/Z6Z+koPq4DKVLCEQcFCe6CAV
         LNzbG7IfSbAH0ZhheDm5rqip4kVn0Ylnq5aGDRTWT/q2J96TG3oTlpePLX4txnapWvkm
         NYqobRceDdcLIIP+aRVJS0wj7Jc99CvWfPHlkEu8Yab0YWh4iDaqsFKtdlTyI88BBuRw
         66y2gUAeKaVJuEgeegysb6MNXNwrcZ1S3N7AeQVAlYTy2V0aCd6CG6548laakxL38npq
         4qcySbVRIqZnAO33RZgzj3n0kStyApH463CjU626CgAJsVcP13ZnBKFspNUCbS5mJerU
         aDdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785830022; x=1786434822;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=0V9nSUKv/Tdm/jG0nL5ZJn57YHMdk7QgzcpAmuCQNyo=;
        b=fU8rcQaqtTPiSJ3cAEBhNzaAY53pul6UxTNS8dirRU0lSQZ7r8RQTv9O1JeAPH7aCt
         towK0zs2sNfzShcdpZlWVVSf1lGTBzSHdHeIZSNrBxxfXjsk8h3/sTWVuZVw1eb/lx05
         c9nN7itkBWq2bkyVkJX4jov5TcpO7p37whP6AoCHClmjyebMIOhQtoeG9OrUKe2tdnCi
         1KPPlWnUt/fgLQKjW+6EbVU42zfP4u93vmwIvA0UQn8gbvFBNaGDGCmn6rcB5L/djnyW
         Sj6W88Rbq8Ueq7nMz3eejOXw9ekzB980CItj981Pe8mS3hl6KA71rjaTp9fmYuQxgFSL
         Y2Sg==
X-Forwarded-Encrypted: i=1; AHgh+Rp7KYS7DdjiJBP/tm/l+RnboQ9o0+ZWeljva5uJZXef1lrjLkUCCCzJdsjYhqhU1NwbpKbAF+PdH7k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxkR7v6C4U0v/8vX7h04l9U/jtjP0OxbLCqEeR/QfgCvJ1EtEzg
	qoIUi/meaN4Sy0UoLwG7VHGXnrTNF6PGg/TTURDRKREaJZ65/jB1yrfEF4T3mcMe5I6wLv1CDM4
	RA3gR7Q==
X-Gm-Gg: AR+sD10wl9RXer50s3HmQBJxFlbDiz3p6a0fKL5BKyBF4rrK155lSYkFXUO568CknG3
	ZI1Fdtg7M5HMqTpu0dM+Zyjq4eVRhIZOyxbOa3obRNfc/8fTy6BDMOF7ULfCj5ea8TdqlIySGE7
	2ronKopNksA61ueEt+YaCFPNXp8lrQQ7rMnks8CEs4Nm9rzYm50llv/pPR5b/OMe/A/1buFVuwJ
	yXU0wkOyuq9Qow6TKbHnRjERrSFi15W/tEpVDTPE7845yBbbKWB9T8jyuldi7MXHTXD+SYJtEw9
	ZWR3/zvOJdKrESMm/w9mO71YmQVrCKs9NF2YvkMnlZmBQmGcp6mzFAWjMy/mJpwwgTiS4biYzvH
	I6a9WCUpn1qrInq2LBFLrWNgCwmn5RX0ak7++fNQGo6vZYURwSbKTvOK3jylsXPPdICSGy1KwuZ
	paqAffgAfqhpG8xQCfBN4WqV1R6teRUm5tn5Grg1rBeb/SBK1QLMcLq9NqNM0htk7a0IZyRb7ze
	udx2ct1fLv2b2O3fL+ThhGWAeCjwLUqsIamJY9a2CPrbAdPLNms
X-Received: by 2002:a05:600c:6209:b0:495:6396:8b67 with SMTP id 5b1f17b1804b1-4980c649f67mr323207235e9.4.1785830022317;
        Tue, 04 Aug 2026 00:53:42 -0700 (PDT)
Message-ID: <8097d8e8-42ec-463a-8247-56c9e4d834cd@suse.com>
Date: Tue, 4 Aug 2026 09:53:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jason Andryuk <jason.andryuk@amd.com>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <bbc2fb48-d79e-4f00-81b4-0170dd910aaa@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <bbc2fb48-d79e-4f00-81b4-0170dd910aaa@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1785830022-589C9CFC-5C6B7CF0/0/0
X-purgate-type: clean
X-purgate-size: 2399

On 03.08.2026 23:01, Jason Andryuk wrote:
> On 2026-07-28 09:22, Jan Beulich wrote:
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
> 
>> @@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
>>   #endif
>>   
>>   #ifdef CONFIG_ARGO
>> -static XSM_INLINE int xsm_argo_enable(const struct domain *d)
>> +
>> +static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
>>   {
>> -    return 0;
>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>> +    return xsm_default_action(action, current->domain, d);
> 
> This one I think should be
>      return xsm_default_action(action, d, NULL);
> 
> Usually current is passed in for the check, but for domain_create() -> 
> argo_init() it is the under-construction domain.

And in that case we want to make sure that current->domain may enable Argo
for d.

>>   }
>>   
>>   static XSM_INLINE int xsm_argo_register_single_source(
>> -    const struct domain *d, const struct domain *t)
>> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>>   {
>> -    return 0;
>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>> +    return xsm_default_action(action, d, t);
>>   }
>>   
>>   static XSM_INLINE int xsm_argo_register_any_source(
>> -    const struct domain *d)
>> +    XSM_DEFAULT_ARG const struct domain *d)
>>   {
>> -    return 0;
>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>> +    return xsm_default_action(action, current->domain, d);
> 
> Similarly:
>      return xsm_default_action(action, d, NULL);
> 
> The single call is:
> xsm_argo_register_any_source(currd);

There being just a single call puts this on the edge. If there was another
one not passing current->domain, I think the same argument as above would
hold here. And the general concept is what I think should matter when
writing the dummy implementations.

> These argo hooks all pass in their arguments explicitly, so I think we 
> should do that and not use current.  (The send and register hooks could 
> use current, and that could make sense as those map to hypercalls.  But 
> it is correct today with the explicit arguments.)
> 
> With the changes:
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks, but no - unless I misunderstand how permissions are intended to
work here, I don't think I can make the changes requested, and hence I
can't apply the R-b.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 08:01:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 08:01:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382005.1625425 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrA5a-0002Ew-BY; Tue, 04 Aug 2026 08:01:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382005.1625425; Tue, 04 Aug 2026 08:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrA5a-0002Ep-8h; Tue, 04 Aug 2026 08:01:30 +0000
Received: by outflank-mailman (input) for mailman id 1382005;
 Tue, 04 Aug 2026 08:01:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrA5Y-0002Ej-7j
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 08:01:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrA5W-00AeaW-HW
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:01:26 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a719c54-5cb7-0a2a0a5109dd-0a2a45058332-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:01:26 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a719b65-4cb1-0a2a45050019-d155802ab00d-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:57:25 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-4954d29264cso14977445e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 00:57:25 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a0f7b86sm64048765e9.10.2026.08.04.00.57.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 00:57:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785830245; x=1786435045; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=qVb1MOqU1bZoDcbi0BZfBIW2AUDTbUQ2MWUzyPm0KVs=;
        b=eAXU2M2hR7Tqlw2as0AJ0rgcNhxjvmJ4Of+krK7As4LAHjta+CmzkqrY7nGR6X6Spn
         uoWowMEevbS/AX2pzUt73pYX8trxIwH0Nd95iJIt/l6F8bJFe8Ie6NzNrLWf9HdW6N8w
         RzcGyeL5K0NSsJCuXVCbrFtmefrIpmBKeqnNH3dbdn6h1voXLs/EFIOV6IFEAC3u7k6m
         JIivVHuVagOwAXA9OGore8iUg6AH+CsNzA0pfy9BGCA5tXYLtaqqBq7HZl0VjkTWTsms
         qIbjUTcxneACK75tV87oc2Ruq+kd7QSEXdE8+C2Tn8UlWrrQ1FGvZUEWGQlLWXbWVcdA
         bH1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785830245; x=1786435045;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qVb1MOqU1bZoDcbi0BZfBIW2AUDTbUQ2MWUzyPm0KVs=;
        b=sAHGx1pS31AdMZupi3Te0bKa2A0TVx2nIlGJQAt7VhvupWppImpTMgtGomEkSgFMeh
         HeWz0j1Ugv0l9uDwUlY97w5ff/SFtuKTPL6R+lLItivFeOtSck/IEW0P/vfw/6Hlpxbt
         r5w+nqvtr9H9MbBXa2uv6P8TQcH5kSeKsOaWnLl0fYs4cdKHADiC2bAnzBPWOlOOZx3f
         MKzJD9o1p1pZfe8GuoKG701vMxPKwC84IPUAfVH4mh3S0yODgHHfGMJXhCamwBRrgxSY
         YEhYE4FC9skDSLA2NPoCLLT363XC8RFllhratkbDjtLF4cLJmiILWB3dnQAEIR2WaIee
         pmxw==
X-Forwarded-Encrypted: i=1; AHgh+Rq6hqZUwg6VgqvqV95I/Bskdaj5xTCtXpPjmmgqtO+KEMae1RK0X/IAC1A16jfO6CvOz9No0dfYxgY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yybbcd+AzivJ0dTIQMxz0CyB11VFebv3JnXYppGhv9h6WsWE6dV
	3Ia6jc+gW6I8swstzcioVEHkx3fLNnufWnvzbG43eqKgIs+hg/sVDB1bxafzFOHFCTc=
X-Gm-Gg: AR+sD11Qg2sOKuoz7AjboZdtaF3YKo/2mKGfK4E9OzAgRuMTm7Qeltay9cX5G3EMfdt
	SHa8VSWhf7DoZYIx6m2TdO2hoHezk2WJ9o17lA+sZFZSdeyGLPDIIZuXghsES4gPHoBpaeffvLr
	g0FSOwTi/3PtCgrsatBw4QCd82D4fsWz800pDWRgXsUi7rBHmlUVRGpPnp7q+6IJJ/A9fKG19el
	49Uy8pOFInUhKF3y7swDOmxA500nMpOkMbfJGYZdD5T7YqgaK1KzNmDk+2WZdXX7xpSPF1ur1B5
	hhoEvcCKDgsXIbi4TS5o1Kyzy6Z1vlK1WWbVTNB2oIce3cJ5TmrRdExhIevnk7HtYbwt8GyWa4n
	hcQIJEUfGbLgHBtwjqtA1LsWjTG2QWwple0XUYw2MForSy/bhuDgyyoY2zcXs2tzXEAhIktKjlN
	wgii9pkZ6BaTERTXV13X0YkySgJHgiN5VoC4qK0w2lXRjDt42KiHpi7kvPt8fW3ggvJUsV4kM2u
	QMXmpvzCWWFvzBDmqV5yijuYNT3m8ukIuk54qA70gNQoKyq6gnNr4tDhGuTYn1/q6pfpfwtkAd2
	5WmjkWx0pJoPzV4=
X-Received: by 2002:a05:600c:8b54:b0:495:4859:8f9b with SMTP id 5b1f17b1804b1-4980c674f25mr345983915e9.9.1785830245215;
        Tue, 04 Aug 2026 00:57:25 -0700 (PDT)
Message-ID: <627c59ee-54b1-4f37-b849-c331a9d01618@suse.com>
Date: Tue, 4 Aug 2026 09:57:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/5] locking/qspinlock: Add contended_release tracepoint
To: Dmitry Ilvokhin <d@ilvokhin.com>, Peter Zijlstra <peterz@infradead.org>,
 Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
 Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
 Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Thomas Gleixner <tglx@kernel.org>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>,
 Josh Poimboeuf <jpoimboe@kernel.org>, Jason Baron <jbaron@akamai.com>,
 Alice Ryhl <aliceryhl@google.com>, Steven Rostedt <rostedt@goodmis.org>,
 Ard Biesheuvel <ardb@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Arnd Bergmann <arnd@arndb.de>,
 Masami Hiramatsu <mhiramat@kernel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 kvm@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
 kernel-team@meta.com
References: <cover.1785778551.git.d@ilvokhin.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------AEfGGk6p5V0hCBAWv3tcK3FA"
X-purgate-ID: tlsNG-c201ff/1785830245-716AD2A1-F4F27DED/13/0
X-purgate-type: clean
X-purgate-size: 13448

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------AEfGGk6p5V0hCBAWv3tcK3FA
Content-Type: multipart/mixed; boundary="------------HRWVg0V4yc1LTGims01Et589";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Dmitry Ilvokhin <d@ilvokhin.com>, Peter Zijlstra <peterz@infradead.org>,
 Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
 Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
 Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
 "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Thomas Gleixner <tglx@kernel.org>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>,
 Josh Poimboeuf <jpoimboe@kernel.org>, Jason Baron <jbaron@akamai.com>,
 Alice Ryhl <aliceryhl@google.com>, Steven Rostedt <rostedt@goodmis.org>,
 Ard Biesheuvel <ardb@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Arnd Bergmann <arnd@arndb.de>,
 Masami Hiramatsu <mhiramat@kernel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 kvm@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
 kernel-team@meta.com
Message-ID: <627c59ee-54b1-4f37-b849-c331a9d01618@suse.com>
Subject: Re: [PATCH 0/5] locking/qspinlock: Add contended_release tracepoint
References: <cover.1785778551.git.d@ilvokhin.com>
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>

--------------HRWVg0V4yc1LTGims01Et589
Content-Type: multipart/mixed; boundary="------------33sYuJhXGYzE04xG2wTAikO4"

--------------33sYuJhXGYzE04xG2wTAikO4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDQuMDguMjYgMDk6MTUsIERtaXRyeSBJbHZva2hpbiB3cm90ZToNCj4gVGhlIGNvbnRl
bmRlZF9yZWxlYXNlIHRyYWNlcG9pbnQgbGFuZGVkIGluIHY3LjItcmMyIGZvciBzbGVlcGlu
ZyBsb2Nrcw0KPiAoNGYwNzBjY2I0ZGM0ICJsb2NraW5nOiBBZGQgY29udGVuZGVkX3JlbGVh
c2UgdHJhY2Vwb2ludCB0byBzbGVlcGFibGUNCj4gbG9ja3MiKS4gU3BpbmxvY2sgc3VwcG9y
dCB3YXMgZHJvcHBlZCBmcm9tIHRoYXQgc2VyaWVzLiBUaGlzIG9uZSBhZGRzIGl0DQo+IGZv
ciBxdWV1ZWQgc3BpbmxvY2tzLg0KPiANCj4gVGhlIGV4aXN0aW5nIGNvbnRlbnRpb25fYmVn
aW4vY29udGVudGlvbl9lbmQgdHJhY2Vwb2ludHMgZmlyZSBvbiB0aGUNCj4gd2FpdGVyIHNp
ZGUuIFRoZSBob2xkZXIncyBpZGVudGl0eSBhbmQgc3RhY2sgY2FuIGJlIGNhcHR1cmVkIGF0
DQo+IGNvbnRlbnRpb25fYmVnaW4gdGltZSAoZS5nLiBwZXJmIGxvY2sgY29udGVudGlvbiAt
LWxvY2stb3duZXIpLCBidXQgb25seQ0KPiBmb3IgbG9ja3Mgd2l0aCBhbiBvd25lciBmaWVs
ZCB0byByZWFkOiBtdXRleCBhbmQgcndzZW0uIHFzcGlubG9jayBoYXMNCj4gbm9uZSwgc28g
YSBjb250ZW5kZWQgc3BpbmxvY2sgY2Fubm90IGJlIGF0dHJpYnV0ZWQgdG8gaXRzIGhvbGRl
ciBhdCBhbGwuDQo+IEV2ZW4gd2hlcmUgdGhlIG93bmVyIGNhbiBiZSByZWFkLCBpdCByZWZs
ZWN0cyB0aGUgaG9sZGVyJ3Mgc3RhdGUgd2hlbiBhDQo+IHdhaXRlciBhcnJpdmVzLCBub3Qg
d2hlbiB0aGUgbG9jayBpcyByZWxlYXNlZC4NCj4gDQo+IFRoaXMgc2VyaWVzIGFkZHMgYSBj
b250ZW5kZWRfcmVsZWFzZSB0cmFjZXBvaW50IHRvIHFzcGlubG9jayB0aGF0IGZpcmVzDQo+
IG9uIHRoZSBob2xkZXIgc2lkZSB3aGVuIGEgbG9jayB3aXRoIHdhaXRlcnMgaXMgcmVsZWFz
ZWQuIFRoaXMgcHJvdmlkZXM6DQo+IA0KPiAtIEhvbGQgdGltZSBlc3RpbWF0aW9uOiB3aGVu
IHRoZSBob2xkZXIncyBvd24gYWNxdWlzaXRpb24gd2FzDQo+ICAgIGNvbnRlbmRlZCwgaXRz
IGNvbnRlbnRpb25fZW5kIChhY3F1aXNpdGlvbikgYW5kIGNvbnRlbmRlZF9yZWxlYXNlDQo+
ICAgIGNhbiBiZSBjb3JyZWxhdGVkIHRvIG1lYXN1cmUgaG93IGxvbmcgdGhlIGxvY2sgd2Fz
IGhlbGQgdW5kZXINCj4gICAgY29udGVudGlvbi4NCj4gDQo+IC0gVGhlIGhvbGRlcidzIHN0
YWNrIGF0IHJlbGVhc2UgdGltZSwgd2hpY2ggZm9yIHNwaW5sb2NrcyBpcyBub3QNCj4gICAg
YXZhaWxhYmxlIGJ5IGFueSBvdGhlciBtZWFucy4NCj4gDQo+IFRoZSB1bmxvY2sgcGF0aCBt
aWdodCBiZSBxdWl0ZSBob3QsIHNvIHRoZSB0cmFjZXBvaW50IGlzIG1hZGUgYXMgY2hlYXAN
Cj4gYXMgcG9zc2libGUsIHRvIGtlZXAgaXQgdXNhYmxlIGluIHByb2R1Y3Rpb246DQo+IA0K
PiAtIHg4NiB3aXRoIFBBUkFWSVJUX1NQSU5MT0NLUz15LCB3aGljaCBpcyB3aGF0IGRpc3Ry
aWJ1dGlvbnMgc2hpcCwgc3dhcHMNCj4gICAgdGhlIHVubG9jayBpbXBsZW1lbnRhdGlvbiB2
aWEgc3RhdGljX2NhbGwoKSB3aGVuIHRoZSB0cmFjZXBvaW50IGlzDQo+ICAgIGVuYWJsZWQu
IFRoZSBkaXNhYmxlZCBwYXRoIGlzIGJ5dGUtaWRlbnRpY2FsIHRvIHRvZGF5J3M6IHRoZSBz
YW1lDQo+ICAgIGlubGluZSBtb3ZiLCBubyBOT1AgYW5kIG5vIGNhbGwuDQo+IA0KPiAtIEV2
ZXJ5d2hlcmUgZWxzZSBhIHN0YXRpYy1icmFuY2ggY2hlY2sgaXMgY29tcGlsZWQgaW50bw0K
PiAgICBxdWV1ZWRfc3Bpbl91bmxvY2soKS4gT24geDg2XzY0IHRoYXQgaXMgYSBzaW5nbGUg
Tk9QIG9uIHRoZSBleGVjdXRlZA0KPiAgICBwYXRoLCB3aXRoIHRoZSBjYWxsIHRvIHRoZSB0
cmFjZWQgaGVscGVyIGVtaXR0ZWQgb3V0IG9mIGxpbmUgYW5kDQo+ICAgIHVucmVhY2hhYmxl
IHdoaWxlIHRoZSB0cmFjZXBvaW50IGlzIG9mZi4gT24gb3RoZXIgYXJjaGl0ZWN0dXJlcyBh
IGZldw0KPiAgICBtb3JlIGluc3RydWN0aW9ucyB0byBtYW5hZ2UgYSBzdGFjayBmcmFtZSBs
YW5kIG9uIHRoZSBleGVjdXRlZCBwYXRoDQo+ICAgIHRvbywgc28gdGhlIGdlbmVyaWMgcGF0
aCBzaXRzIGJlaGluZA0KPiAgICBDT05GSUdfUVVFVUVEX1NQSU5MT0NLU19UUkFDRV9DT05U
RU5ERURfUkVMRUFTRSAoZGVmYXVsdCBuKS4NCj4gDQo+IENvc3RzIGFuZCBtZWFzdXJlbWVu
dHMgYXJlIGluIHRoZSBpbmRpdmlkdWFsIGNoYW5nZWxvZ3MuIEJyaWVmbHksIG5vDQo+IHRo
cm91Z2hwdXQgb3IgbGF0ZW5jeSBjaGFuZ2UgaXMgbWVhc3VyYWJsZSBvbiBlaXRoZXIgeDg2
XzY0IG9yIGFybTY0DQo+IHdpdGggUVVFVUVEX1NQSU5MT0NLU19UUkFDRV9DT05URU5ERURf
UkVMRUFTRT15Lg0KPiANCj4gVGVzdGVkOiB4ODZfNjQgd2l0aCBQQVJBVklSVF9TUElOTE9D
S1M9eSBhbmQgPW4sIGFybTY0LCB0cmFjZXBvaW50IG9uDQo+IGFuZCBvZmYsIGRpc2Fzc2Vt
Ymx5IGNoZWNrZWQgaW4gYm90aCBzdGF0ZXMsIGxvY2t0b3J0dXJlIHdpdGggdHJhY2Vwb2lu
dA0KPiBvbiBhbmQgb2ZmLg0KPiANCj4gTm90IGNvdmVyZWQ6IHFyd2xvY2ssIGFuZCBhcmNo
aXRlY3R1cmVzIHdpdGggZnVsbHkgY3VzdG9tIHFzcGlubG9jaw0KPiBpbXBsZW1lbnRhdGlv
bnMgKGUuZy4gUG93ZXJQQykuIFRoZSBzdGFjayBmcmFtZSBtYW5hZ2luZyBpbnN0cnVjdGlv
bnMgb24NCj4gYXJtNjQgc2hvdWxkIGJlIGF2b2lkYWJsZSwgYnV0IHRoYXQgaXMgbm90IGRv
bmUgaW4gdGhpcyBwYXRjaHNldC4NCj4gDQo+IFBhdGNoIDEgaXMgUGV0ZXIncyBkcmFmdCBm
cm9tIFsxXSBhbmQgaXMgbWlzc2luZyBoaXMgU2lnbmVkLW9mZi1ieS4NCj4gUGV0ZXIsIHBs
ZWFzZSBhZGQgaXQgaWYgeW91IGFyZSBoYXBweSB3aXRoIHRoZSBwYXRjaC4NCj4gDQo+IFsx
XTogaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvYWxsLzIwMjYwNjAzMTIwODExLkdXMzQ5MzA5
MEBub2lzeS5wcm9ncmFtbWluZy5raWNrcy1hc3MubmV0Lw0KPiANCj4gRG1pdHJ5IElsdm9r
aGluICg0KToNCj4gICAgbG9ja2luZzogRmFjdG9yIG91dCBxdWV1ZWRfc3Bpbl9yZWxlYXNl
KCkNCj4gICAgbG9ja2luZy9xc3BpbmxvY2s6IEFkZCBjb250ZW5kZWRfcmVsZWFzZSB0cmFj
ZXBvaW50DQo+ICAgIHRyYWNpbmcvbG9jazogVXNlIFRSQUNFX0VWRU5UX0ZOKCkgZm9yIGNv
bnRlbmRlZF9yZWxlYXNlDQo+ICAgIHg4Ni9wYXJhdmlydDogVHJhY2UgY29udGVuZGVkX3Jl
bGVhc2Ugb24gdW5sb2NrDQo+IA0KPiBQZXRlciBaaWpsc3RyYSAoMSk6DQo+ICAgIHg4Ni9w
YXJhdmlydDogVXNlIHN0YXRpY19jYWxsKCkgZm9yIHRoZSBwYXJhdmlydCBzcGlubG9jayBv
cHMNCj4gDQo+ICAgYXJjaC9taXBzL2luY2x1ZGUvYXNtL3NwaW5sb2NrLmggICAgICAgICB8
ICA2ICstLQ0KPiAgIGFyY2gveDg2L2h5cGVydi9odl9zcGlubG9jay5jICAgICAgICAgICAg
fCAgNCArLQ0KPiAgIGFyY2gveDg2L2luY2x1ZGUvYXNtL2NwdWZlYXR1cmVzLmggICAgICAg
fCAgMSAtDQo+ICAgYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQtc3BpbmxvY2suaCB8
IDIxICsrKysrLS0tDQo+ICAgYXJjaC94ODYva2VybmVsL2t2bS5jICAgICAgICAgICAgICAg
ICAgICB8ICA1ICstDQo+ICAgYXJjaC94ODYva2VybmVsL3BhcmF2aXJ0LXNwaW5sb2Nrcy5j
ICAgICB8IDYzICsrKysrKysrKysrKysrKysrKysrKy0tLQ0KPiAgIGFyY2gveDg2L2tlcm5l
bC9zdGF0aWNfY2FsbC5jICAgICAgICAgICAgfCAyNyArKysrKysrKysrDQo+ICAgYXJjaC94
ODYveGVuL3NwaW5sb2NrLmMgICAgICAgICAgICAgICAgICB8ICA1ICstDQo+ICAgaW5jbHVk
ZS9hc20tZ2VuZXJpYy9xc3BpbmxvY2suaCAgICAgICAgICB8IDM4ICsrKysrKysrKysrKy0t
DQo+ICAgaW5jbHVkZS90cmFjZS9ldmVudHMvbG9jay5oICAgICAgICAgICAgICB8IDEwICsr
Ky0NCj4gICBrZXJuZWwvS2NvbmZpZy5sb2NrcyAgICAgICAgICAgICAgICAgICAgIHwgMjAg
KysrKysrKysNCj4gICBrZXJuZWwvbG9ja2luZy9tdXRleC5jICAgICAgICAgICAgICAgICAg
IHwgIDQgKysNCj4gICBrZXJuZWwvbG9ja2luZy9xc3BpbmxvY2suYyAgICAgICAgICAgICAg
IHwgMjIgKysrKysrKysrDQo+ICAgdG9vbHMvYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVh
dHVyZXMuaCB8ICAxIC0NCj4gICAxNCBmaWxlcyBjaGFuZ2VkLCAxOTUgaW5zZXJ0aW9ucygr
KSwgMzIgZGVsZXRpb25zKC0pDQo+IA0KPiANCj4gYmFzZS1jb21taXQ6IDVlNjAxYWIzNjE1
Yzg2YmU3YzQwNjhjZTk5MmY5NDY1NDY5M2EwMzINCg0KRm9yIHRoZSB3aG9sZSBzZXJpZXM6
DQoNCkFja2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCkknbSBj
b25zaWRlcmluZyBzb21lIGZvbGxvd3VwIHBhdGNoZXMgcmVwbGFjaW5nIHRoZSByZW1haW5p
bmcgcGFyYXZpcnQNCmNhc2VzIG5vdCBjb3ZlcmVkIGJ5IENPTkZJR19QQVJBVklSVF9YWEwg
d2l0aCBzdGF0aWNfY2FsbCgpLCB0b28uDQoNClRoaXMgd2lsbCBhbGxvdyB0byBkcm9wIHRo
ZSAzMi1iaXQgcGFyYXZpcnQgcGF0Y2hpbmcgY29tcGxldGVseS4gOi0pDQoNClRoZSBxdWV1
ZWRfc3Bpbl91bmxvY2soKSBob29rIHdhcyB0aGUgbWFpbiByZWFzb24gSSBkaWRuJ3QgZG8g
dGhhdCB5ZXQuDQoNCg0KSnVlcmdlbg0K
--------------33sYuJhXGYzE04xG2wTAikO4
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------33sYuJhXGYzE04xG2wTAikO4--

--------------HRWVg0V4yc1LTGims01Et589--

--------------AEfGGk6p5V0hCBAWv3tcK3FA
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpxm2MFAwAAAAAACgkQsN6d1ii/Ey+9
Agf+IWx5eXJ7mO6oP+n4rxGw46J5o8kxhJQXckuPe4UqJ4KZp2eDhMwkS/QfmUPt+V4ojeOdZa1V
t5qalPRfTCjVf4ZjarkTErmzJEGtvM5UFOPA1nJBFIGlV8VkDzRzYXof0c0ySuzecPKbh7pY3vUz
VAUq0Q4EI6/WZY9jlKSQPoVjFFnIaWF5MoA2mGETIaZNXIBKSb/JmKfyRKxoY+u6IIeXrzl3wnIp
VRnKsfQY36idWLXCtgq72WaTEl8HBUfpg0cTNGX0Fs6DZ4wH41e/KenwyCtV/RoC9vMyVKhvshqA
JQOnAn0AVEbRYSsu6FmlqT/H4mCv6HrNanDhE76nUA==
=gT7a
-----END PGP SIGNATURE-----

--------------AEfGGk6p5V0hCBAWv3tcK3FA--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 08:02:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 08:02:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382013.1625435 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrA6p-0002m6-Q1; Tue, 04 Aug 2026 08:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382013.1625435; Tue, 04 Aug 2026 08:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrA6p-0002lz-Lq; Tue, 04 Aug 2026 08:02:47 +0000
Received: by outflank-mailman (input) for mailman id 1382013;
 Tue, 04 Aug 2026 08:02:46 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrA6o-0002lq-EL
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 08:02:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrA6n-002m56-RE
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:02:45 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a719c9e-e002-0a2a0a5209dd-0a2a45079228-22
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:02:45 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a719ca5-b4ea-0a2a45070019-d1558032e8bc-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:02:45 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4954f5e8020so14270615e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 01:02:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49949fc2ff6sm61006725e9.1.2026.08.04.01.02.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 01:02:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785830565; x=1786435365; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=86lG+DPRfxOIdxiwMYJYnP52hG1gKOaF+TCIcTnAaM4=;
        b=c+gtxNu+6XbnY0AxLVpUXJqa7TV2MYxdLzhgmRBFc8Endh5EhJonFkI6Y99Zo3bEbB
         X1skoq6n2HdGVHE2s7EjSRANeEj50qUIvFzCPrvslI/UZfM6qZ0J4QLIawmcyiBUQDXI
         9So/Uo3mHnBN58c1SeXNa6iHT3hMSw9MJIXoP9M23dYKJPFg9asPG9g6XeILoAEJTQO0
         82zIOYv5HWCBvWhMO+4ybTMY2nSA6THgTnr/khkAZSWim9oGo+20itt9AwUqFpreo1Nw
         J9+nR9LEy0A6fZMM7rFG9IR2FDnQ+RACDbiTzcgBo9CFSIo3zp3qe6SpWVJE2yyoGgfZ
         idfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785830565; x=1786435365;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=86lG+DPRfxOIdxiwMYJYnP52hG1gKOaF+TCIcTnAaM4=;
        b=C44G0LOvpuLJ0USwq/D7PHsD2Ozz/wQARwJUV9fRrBVl6wsRJvsRIbHZ6iAQZeZGr9
         M0ksIX9u/DWeiPtl+P8/l0MevVTVGEEw+lw3BNAJtsjjZQIcKLjdp1DggUp1j6SygNfM
         1XS5vF/cIE8Vcl3naEGqFC24ZuhV+LAGoTxUn3gkJfaR7mv4Sk1/Iv4dTfl3O8SzFVD1
         sHLmfMyFsCtYcDCCjLfRRilRbn662PsaZQgd/BTCZ5zGVL0Ibdie3ev/aBi4Soycwh53
         gdWaawCgGCTesL4OVRz+LhBrWY9UfCHiaWvo9XusygGLzQ0MKQf1vnOSmYcj2gMsyqFc
         WUrw==
X-Forwarded-Encrypted: i=1; AHgh+Rr72PA0ckmkBVCecEXb+cN/qOO07zO6W3lneeMiUhY7LSUjmv4EDrJqQ2JQ7cF2vzVwGC9ex/sA2Vg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4PYJzuW9sGAQvKlYUvNFSxaezY2BGrdIGq78udGpzolInFALT
	1/C8BSkw6elPOZpP6ophfP3wjFsZECkFtkh4+ZXJg0uPtU+kIvRNky/XXzgo9eYYNYy7qJlQoUl
	c+H9vnw==
X-Gm-Gg: AR+sD119J6OocNKKv/jwuNRpJ0T79+P64jFppCsW83VySyCflMTlu43EBYhActpBKav
	jHRpQaEZjmH6+Kjs2YXvzi5GxqHrAYqUKBgWN5AHS4vQ0QeWX8ymyByQz39N4RfMlJYQKKQL5sT
	NJ1jcMc/ocJ1EQo2sy9GhmxrIDCa4uJXAHDNa22OmsaR0HwN6DE75LvoN9JVH16eHD9Lj4FyoRl
	umAM90a3Opvii6Bqc3d405lRBDUpoovXhr3lPq1DCLAcsh62Cf1HsR8X4nuaevz8cSXxo1vAYcc
	nt8j9Ue65pZ9I6ZmSLO3nEXZW92hfr/QPyXRk5EOLmqblZh0XLcml0dXuEcs3iftBZsPLeuWM+C
	kJk1UkWEYbtmaXRdO9G5ZoMVYa8DASL0v8/RyGQdK1HOhgY4ozYs+ucH1kpYwzWaeinM/gweEoP
	h0yn09jPc2JAGVomSWaEGo3lJObdqZwk34J6748NONbPI61VSz5k3thuL6eI2IT9aKfBkMiDvjk
	yijcSwS0bN525lBwZZHaZ6MQ7qztY70YnSazmWBtwcN8I+IwMyNqptGECqzXlQ=
X-Received: by 2002:a05:600c:e557:10b0:495:5890:8f6c with SMTP id 5b1f17b1804b1-4980c64b824mr211207245e9.7.1785830564585;
        Tue, 04 Aug 2026 01:02:44 -0700 (PDT)
Message-ID: <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
Date: Tue, 4 Aug 2026 10:02:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux PV domU with >1 vCPU never resumes after xl save/restore
To: George Dunlap <gwd@xenproject.org>
Cc: Juergen Gross <jgross@suse.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1785830565-374D3AE4-8F51320E/0/0
X-purgate-type: clean
X-purgate-size: 512

On 04.08.2026 08:12, George Dunlap wrote:
> Saving and restoring a multi-vcpu PV guest appears to have been broken in
> Linux for some time (observed 6.6.56 and 6.12.86).  Report below from
> Claude Fable; I've independently verified the behavior on vanilla Linux
> 6.6.56.  Claude seems to think it's a bug in Linux.

Just to double check, as there was a crucial fix there recently: This is with
a Xen including bedbc17d8407 ("x86/domctl: restore all registers in
arch_{get,set}_info_guest()")?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 08:45:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 08:45:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382033.1625444 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrAln-0001AD-Qe; Tue, 04 Aug 2026 08:45:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382033.1625444; Tue, 04 Aug 2026 08:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrAln-0001A6-MO; Tue, 04 Aug 2026 08:45:07 +0000
Received: by outflank-mailman (input) for mailman id 1382033;
 Tue, 04 Aug 2026 08:45:07 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrAln-0001A0-18
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 08:45:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrAlm-00E1pE-4h
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:45:06 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a71a691-2eae-0a2a0a5409dd-0a2a4504ec10-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:45:05 +0200
Received: from [209.85.208.44] (helo=mail-ed1-f44.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a71a691-b57f-0a2a45040019-d155d02ca540-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:45:05 +0200
Received: by mail-ed1-f44.google.com with SMTP id
 4fb4d7f45d1cf-6a08a2b7e5bso1531887a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 01:45:05 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a0d0ed21aesm3184111a12.5.2026.08.04.01.45.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 01:45:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785833105; x=1786437905; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=iaU3/gpq/3H9J2szYrRVZY+0G842nsPIgdgjVJmjc6g=;
        b=IB7LSZDeQyhNCxoJZ0zsfv+t9ssHCXs8r1LqgyDKauvVJ1Q0TtcahKQnuGR+BMuqN7
         vGKe/iFphg7+WEbvVQLVDuti3kkhPMeYRxmlOKWNOZYNGbXm4hp3+1XlMJcJLhKXbh08
         Af/BtjcSD5Lxwax2JcjX2fNQ2tLryfKDZoJtdqvdQZFh48j85V/HR6VV0IYNckc0Mbuk
         waFeMwRW+5mXtP+fWBSdX2B/fcwc4EzikUda6jp4H15MARGqFE6NcKJxoKSA/sMbW8S/
         8M+xTTHCoRWz94Dve61yqFGfP6ugxsdZH6Xg0jr6SI6rtbJ6tVLM+CXvG6u/ElnaZwiU
         fCKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785833105; x=1786437905;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=iaU3/gpq/3H9J2szYrRVZY+0G842nsPIgdgjVJmjc6g=;
        b=hRaOP3z80UpKOIDO3/+g+URvi+0CMikCHCCuPS3ddybAmxA6ykau1AGcaFzrSpBoGX
         STN6D0DtfEIkeNe1Vni65hjnTqHNpM660AmrinXNRqzZBvxWMfk6Q1WPyEA6RhO2d/QH
         aRXKhCi2G6uidKQFMA4tzB60PqlKStOM9EpZmFgi3lDzmVBxtntfobyYTaOiGPiisOsK
         p5jrNZ5ECg85xCmRchZIkC+dV/BL+5KYxhIYiETAWmDVMmPGfWwJb7P385sL7D/v+2OC
         ezz/PvL3sHKccf1P5T2aBOPfWyyY+5MPee7GxaZA8jZ1VtmnUWUjTI1KP6oeoZfJ7AwG
         RKOg==
X-Gm-Message-State: AOJu0YyxWcj+JO+H48lH27K1Gtg1JclwRh/686RUv03t2nC5RP9ZdLbu
	mr0Vj6TBY/iVulp1JdO5iuGU3SyKiYPR37sB4oVlBIZrk63/VJXLswyxPo1jO2L7xoY=
X-Gm-Gg: AR+sD13G1ccHXpUf9AWGqt7dWBt1Tq7V6d87dKz8x1sddKpnMD6F0TsFYDFeGe35aWt
	HUiFqJot+hAJjwQghTu+f4u8p5esJMsL9vkeMKe+tqlew8bQ53g8XHdehbDpsOyH+tkSiuq7ESO
	7cTgzQyaESFNNV/qDrMvIZP9HfSYJwTz4XxbOdmTmKAQUCsTT+bMP7AaU7HWaeMxfsz+1JtkHfi
	5+/KE9WqRYtKeyt9Kob4ZMRH00/C5eLOfO5oUWFwofG4mlNKBVhviP+OGs2yUUVAKfXpndJ8B57
	EIJ8cYQidb11aUps83RF4RzGmVVJP9f00fQSH0i+VUnJ2Y83yLBsz91Rfs5JIK37dx9qP2EetVG
	nNqsEUaImO2PGR+RF5mQsrtYVB7ighUzz2k54bCih/3+m0QEb6pH1dRbLCZV0pdGqUh3F2V5+7q
	OjQydKWT1bOVoWUac2h/TzHtFwChsVY7wsTMsPWZn14DexwifcvpZGhVRn43a5mKsypadXp7ix/
	BtPh17mcW8FrTKvc8/xSheLpEJsnWfB8+fTIs4Iuq5aRxfRMIXuaPTGlfaBSpcIWVcNDrvmv2HP
	PnTcC2vJgYW0fSY=
X-Received: by 2002:a05:6402:11cb:b0:69e:14ab:5966 with SMTP id 4fb4d7f45d1cf-6a12319f03amr2901669a12.8.1785833105429;
        Tue, 04 Aug 2026 01:45:05 -0700 (PDT)
Message-ID: <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
Date: Tue, 4 Aug 2026 10:45:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Linux PV domU with >1 vCPU never resumes after xl save/restore
To: Jan Beulich <jbeulich@suse.com>, George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------WVRzwMQeY23S5wu1WdvhUDd2"
X-purgate-ID: tlsNG-ebf023/1785833105-516D2B50-64075477/0/0
X-purgate-type: clean
X-purgate-size: 8837

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------WVRzwMQeY23S5wu1WdvhUDd2
Content-Type: multipart/mixed; boundary="------------pa0cUgpdHzoVvd7rAPNWfrwC";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>, George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
Subject: Re: Linux PV domU with >1 vCPU never resumes after xl save/restore
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
In-Reply-To: <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------pa0cUgpdHzoVvd7rAPNWfrwC
Content-Type: multipart/mixed; boundary="------------WTP03W800uCAC6gjMvuPYlYZ"

--------------WTP03W800uCAC6gjMvuPYlYZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDQuMDguMjYgMTA6MDIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNC4wOC4yMDI2
IDA4OjEyLCBHZW9yZ2UgRHVubGFwIHdyb3RlOg0KPj4gU2F2aW5nIGFuZCByZXN0b3Jpbmcg
YSBtdWx0aS12Y3B1IFBWIGd1ZXN0IGFwcGVhcnMgdG8gaGF2ZSBiZWVuIGJyb2tlbiBpbg0K
Pj4gTGludXggZm9yIHNvbWUgdGltZSAob2JzZXJ2ZWQgNi42LjU2IGFuZCA2LjEyLjg2KS4g
IFJlcG9ydCBiZWxvdyBmcm9tDQo+PiBDbGF1ZGUgRmFibGU7IEkndmUgaW5kZXBlbmRlbnRs
eSB2ZXJpZmllZCB0aGUgYmVoYXZpb3Igb24gdmFuaWxsYSBMaW51eA0KPj4gNi42LjU2LiAg
Q2xhdWRlIHNlZW1zIHRvIHRoaW5rIGl0J3MgYSBidWcgaW4gTGludXguDQo+IA0KPiBKdXN0
IHRvIGRvdWJsZSBjaGVjaywgYXMgdGhlcmUgd2FzIGEgY3J1Y2lhbCBmaXggdGhlcmUgcmVj
ZW50bHk6IFRoaXMgaXMgd2l0aA0KPiBhIFhlbiBpbmNsdWRpbmcgYmVkYmMxN2Q4NDA3ICgi
eDg2L2RvbWN0bDogcmVzdG9yZSBhbGwgcmVnaXN0ZXJzIGluDQo+IGFyY2hfe2dldCxzZXR9
X2luZm9fZ3Vlc3QoKSIpPw0KDQpUaGFua3MgZm9yIGJyaW5naW5nIHRoaXMgdXAuDQoNCkkg
anVzdCB3YW50ZWQgdG8gc3RhcnQgaW52ZXN0aWdhdGlvbiwgYXMgeGwgc2F2ZS9yZXN0b3Jl
IGRpZG4ndCB3b3JrIGZvciBtZQ0KZWl0aGVyIHVzaW5nIGFuIHVwc3RyZWFtIDcuMSBrZXJu
ZWwuDQoNClVzaW5nIGFuIHVwLXRvLWRhdGUgWGVuIG1hZGUgdGhlIGRpZmZlcmVuY2UgKEkg
aGFkIGEgb25lIG1vbnRoIG9sZCBYZW4gb24gbXkNCnRlc3Qgc3lzdGVtIGZvciB0aGUgaW5p
dGlhbCB0ZXN0KS4NCg0KDQpKdWVyZ2VuDQoNClAuUy46IEdlb3JnZSwgd291bGQgaXQgYmUg
cG9zc2libGUgdG8gdHVybiBvZmYgSFRNTCBtYWlscyB3aGVuIHNlbmRpbmcgdG8NCiAgICAg
ICB4ZW4tZGV2ZWw/DQo=
--------------WTP03W800uCAC6gjMvuPYlYZ
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------WTP03W800uCAC6gjMvuPYlYZ--

--------------pa0cUgpdHzoVvd7rAPNWfrwC--

--------------WVRzwMQeY23S5wu1WdvhUDd2
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpxppAFAwAAAAAACgkQsN6d1ii/Ey8y
2gf9G2gLNc5IG8tJ5It/UYmwD3CJz+8fX1u5OgApne08uKg7Jms0cBlNyaVpN5eegCEUV8XRfRUs
Avz1BpSJ2yKeTEoV7Tsk+B75wwsVZOd7cSf7J9c9EQA3RzROfq41boOl5H2vSKlrpWhhyxQvIPgD
TOHX4yrTnaxXNuRIKBxEt4LpQ+I5cKeSvAd9Zy+S/tddoUo690OjiyGCfYeMIIeF+Qrg1+6E2BqF
LmyalCNQoS01ZjPScAeNKkArgsWsm70n2F50HLsWFtQCvHytKZ1vVgDKQc8zb7a4EpPz0RZQ11dA
GUvBosyR/gxFzkVnZK3yey0XeTsx+8vKPS5UrdxAHA==
=LQ7a
-----END PGP SIGNATURE-----

--------------WVRzwMQeY23S5wu1WdvhUDd2--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 09:15:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 09:15:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382048.1625454 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrBEw-0006NU-2K; Tue, 04 Aug 2026 09:15:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382048.1625454; Tue, 04 Aug 2026 09:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrBEv-0006NN-Vi; Tue, 04 Aug 2026 09:15:13 +0000
Received: by outflank-mailman (input) for mailman id 1382048;
 Tue, 04 Aug 2026 09:15:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@swg.vates.tech>)
 id 1wrBEt-0006NF-TI
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:15:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrBEr-00878h-EL
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 11:15:09 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@swg.vates.tech>)
 id 6a71ad8d-e002-0a2a0a5209dd-0a2a450a89e8-40
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 11:15:09 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@swg.vates.tech>)
 id 6a71ad9a-f2d2-0a2a450a0019-b9ff1c2291e9-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 11:15:06 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fcc0e18f8000e099.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 04 Aug 2026 09:15:03 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id B5BD38340E;
 Tue,  4 Aug 2026 11:15:02 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=2V3Tn92zkbXcZR5dja6Se9zC0FVeI7Mgv3coqMu/3jk=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=sS5NoJqNKu33dP57KnbE6DYZUxHwjO97bSL0lzRo8wA99xNA0LSPNC5M/0ls7evQrTvC7s3t6
 wPINYChgw1EuGTdRJBmQ4NaEJgsrzRGpn+KD75mPVA2y61zP58w4Mx0zEEcN6hz2vNWrEnqm9IW
 1t2HJv94v5A/OPNdpP+Nepmht1cDeYSrnp6y7+Sa1oYWstUB7jKvHuA0sOC8UXV5BGhs7MfOsNn
 EFYkIxZ8Hkjx1Ncaz6AyqlEmm6auQzaelucEuCu0WMFEC0JpCxzWwzJ/+cg3OYZ+gz+kSy4clsW
 +nNpE4Q/7c/U90XZAcDtF1TgtZDWtQp5tl9Fbskro8BQ==
X-Zone-Loop: be9c5299de486e907cd307ba575e68146a1c6b48d74b
x-campaign-type: default
x-transaction-id: 12649b57-dd6f-4ceb-8776-fd8eac736d34
x-swg-uid: 01-42eff819-3e4a-43cb-959f-933edb5dd093
X-Mailer: Sweego
Message-ID:
 <1785834903.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@vates.tech>
x-swg-bid: 1785834903.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Tue, 4 Aug 2026 11:15:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
To: Marcus Granado <marcus.granado@citrix.com>,
 Frediano Ziglio <freddy77@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Roger Pau Monne <roger.pau@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
References: <20260720154832.1907401-1-marcus.granado@citrix.com>
 <20260720154832.1907401-2-marcus.granado@citrix.com>
 <1784622046.8631fc262581453bbf619ec5b2062170.19f83c35cd4000edb5@vates.tech>
 <CAHt6W4erBfB+H_0d+2rQ0apz9Jt6ex+WVjEjyPm6EApoHVJgmg@mail.gmail.com>
 <1784755834.8631fc262581453bbf619ec5b2062170.19f8bbccffd000edb5@vates.tech>
 <CAHt6W4cWLfSVoCSgr-YsQb1Mv=VZek0CakTBwK7tx_n9RkeiUg@mail.gmail.com>
 <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------tLoy9wFY8vD4kZQNnvXo5qTt"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1785834902930
X-purgate-ID: tlsNG-4011c0/1785834907-53AD4CFC-CEFE82DC/0/0
X-purgate-type: clean
X-purgate-size: 14900

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------tLoy9wFY8vD4kZQNnvXo5qTt
Content-Type: multipart/mixed; boundary="------------hNQ5LyUMizokDAxHrKBPhLw7";
 protected-headers="v1"
From: Teddy Astie <teddy.astie@vates.tech>
To: Marcus Granado <marcus.granado@citrix.com>,
 Frediano Ziglio <freddy77@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Roger Pau Monne <roger.pau@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Message-ID: <473315c8-6e90-4921-ac2b-e22ba3332f69@vates.tech>
Subject: Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
References: <20260720154832.1907401-1-marcus.granado@citrix.com>
 <20260720154832.1907401-2-marcus.granado@citrix.com>
 <1784622046.8631fc262581453bbf619ec5b2062170.19f83c35cd4000edb5@vates.tech>
 <CAHt6W4erBfB+H_0d+2rQ0apz9Jt6ex+WVjEjyPm6EApoHVJgmg@mail.gmail.com>
 <1784755834.8631fc262581453bbf619ec5b2062170.19f8bbccffd000edb5@vates.tech>
 <CAHt6W4cWLfSVoCSgr-YsQb1Mv=VZek0CakTBwK7tx_n9RkeiUg@mail.gmail.com>
 <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>
In-Reply-To: <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>

--------------hNQ5LyUMizokDAxHrKBPhLw7
Content-Type: multipart/mixed; boundary="------------qL9BXv60iFiNIQQzDu3jqzUh"

--------------qL9BXv60iFiNIQQzDu3jqzUh
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDMvMDgvMjAyNiDDoCAxOToyMywgTWFyY3VzIEdyYW5hZG8gYSDDqWNyaXTCoDoNCj4g
T24gV2VkLCAyOSBKdWwgMjAyNiBhdCAxMDoxNCwgRnJlZGlhbm8gWmlnbGlvIDxmcmVkZHk3
N0BnbWFpbC5jb20+IHdyb3RlOg0KPj4gQWJvdXQgY29tcHJlc3NpbmcgYWxsIHRvZ2V0aGVy
IGFuZCBjb25zaWRlcmluZyBhbHNvIHRoZSBpc3N1ZSBvZg0KPj4gbWVtb3J5IGNoYW5naW5n
IHdoaWxlIHNlbmRpbmcgSSB3b3VsZCB2b3RlIHRvIGNvcHkgdGhlIG1lbW9yeSBpbiBhDQo+
PiB0ZW1wb3JhcnkgYnVmZmVyIHRvIGF2b2lkIHRoaXMuIE9uZSBhZHZhbnRhZ2UgaXMgdGhh
dCBpdCBzaW1wbGlmaWVkDQo+PiB0aGUgZm9ybWF0LiBUaGUgY3VycmVudCBMWjQgaW1wbGVt
ZW50YXRpb24gc2VlbXMgdG8gY29wZSB3aXRoIGRhdGENCj4+IGNoYW5nZXMgYnV0IG5vdGhp
bmcgZ3VhcmFudGVlcyBpdCBpbiB0aGUgZnV0dXJlLCB0aGUgYnVmZmVyIHlvdSBhcmUNCj4+
IHBhc3NpbmcgaXMgbm90IHN1cHBvc2VkIHRvIGNoYW5nZSB3aGlsZSB5b3UgY29tcHJlc3Mg
aXQuDQo+IA0KPiANCj4gQWdyZWVkLiBGcmVkaWFubyBhbmQgSSBkaXNjdXNzZWQgdGhpcyBm
dXJ0aGVyLCBpbmNsdWRpbmcgc2ltcGxpZmljYXRpb25zIG9uDQo+IHRoZSBjb21wcmVzc2lv
biByZWNvcmQgZm9yIHYyIHNvIHRoYXQgdGhlIHBhZ2UgZGF0YSBjb21wcmVzc2lvbjoNCj4g
KiBjb21wcmVzc2VzIHRoZSB3aG9sZSBiYXRjaCB0b2dldGhlcg0KPiAqIGFuZCB1c2VzIGEg
c3RhZ2VkIGNvcHkgZm9yIGl0IGFzIHlvdSBhbmQgVGVkZHkgc3VnZ2VzdGVkIChzbyB0aGF0
IHdlIGRvDQo+IG5vdCBuZWVkIHRvIHdvcnJ5IGFib3V0IG11dGF0aW5nIGJ1ZmZlcnMgYWZm
ZWN0aW5nIExaNCBvciBvdGhlciBhbGdvcml0aG1zKS4NCj4gDQo+IE9uY2UgdGhlcmUncyBl
eGFjdGx5IG9uZSBjb21wcmVzc2VkIGJsb2IgcGVyIHJlY29yZCwgdGhlcmUncyBubyBuZWVk
IGZvcg0KPiBleHRyYSBmaWVsZHMgdG8gZGVzY3JpYmUgdGhlIGNvbXByZXNzZWQgZGF0YSwg
YXMgdGhlIHVuY29tcHJlc3NlZCBiYXRjaA0KPiBzaXplIGlzIGtub3duIChhbmQgYm91bmRl
ZCBieSBNQVhfQkFUQ0hfU0laRSAqIHBhZ2Vfc2l6ZSksIGFuZCBpdHMNCj4gY29tcHJlc3Nl
ZCBzaXplIGNhbiBiZSBpbmZlcnJlZCBmcm9tIHRoZSBzaXplIG9mIHRoZSBlbWl0dGVkIGNv
bXByZXNzZWQNCj4gcmVjb3JkIHdpdGhvdXQgYSBuZWVkIGZvciBhbiBleHBsaWNpdCBmaWVs
ZCBmb3IgY2xlbiBvciBhIGZpZWxkIHdpdGggdGhlDQo+IG51bWJlciBvZiByYXcgY29tcHJl
c3NlZCBibG9icy4gVGhpcyBtZWFucyB0aGUgc2VwYXJhdGUgUEFHRV9EQVRBX0xaNA0KPiBy
ZWNvcmQgdHlwZSBpcyBub3QgbmVlZGVkLCBhbmQgdGhlIHByb3Bvc2FsIGZvciB2MiBjb21w
cmVzc2lvbiByZWNvcmQgY291bGQNCj4gc2ltcGxpZnkgdG8gcmV1c2luZyBQQUdFX0RBVEEg
YW5kIHNwZW5kaW5nIG9uZSBvY3RldCBvZiBpdHMgcmVzZXJ2ZWQgd29yZA0KPiBhcyBmb2xs
b3dzOg0KPiANCj4gDQo+ICAgICAgIDAgICAgIDEgICAgIDIgICAgIDMgICAgIDQgICAgIDUg
ICAgIDYgICAgIDcgb2N0ZXQNCj4gICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t
LS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICB8IGNvdW50IChDKSAgICAgICAgICAg
ICB8IGNvbXB8IChyZXNlcnZlZCkgICAgICAgIHwNCj4gICAgICArLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0rLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICB8IHBmblswXSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICArLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAg
ICAuLi4NCj4gICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSsNCj4gICAgICB8IHBmbltDLTFdICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwNCj4gICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICAgICB8IHBhZ2VfZGF0YVswLi5OLTFdIGlm
IGNvbXAgPT0gMCAgICAgICAgICAgICAgICAgIHwNCj4gICAgICB8IG9yIHBhZ2VfY2RhdGEg
ICAgIGlmIGNvbXAgIT0gMCAgICAgICAgICAgICAgICAgIHwNCj4gICAgICArLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gDQo+IHdpdGgg
dHdvIG5ldyBlbnRyaWVzIGluIHRoZSBmaWVsZCB0YWJsZToNCj4gDQo+IGNvbXAgICAgICAg
IENvbXByZXNzaW9uIGFsZ29yaXRobSBhcHBsaWVkIHRvIHRoZSBwYWdlIGNvbnRlbnRzLiAw
DQo+ICAgICAgICAgICAgICBtZWFucyBub25lLCBhbmQgdGhlIHJlY29yZCBpcyBleGFjdGx5
IGFzIGl0IGlzIHRvZGF5LiAxDQo+ICAgICAgICAgICAgICBtZWFucyBMWjQgYmxvY2sgZm9y
bWF0LiBPdGhlciB2YWx1ZXMgYXJlIHJlc2VydmVkIGZvcg0KPiAgICAgICAgICAgICAgb3Ro
ZXIgZnV0dXJlIGZvcm1hdHMgbGlrZSBaU1REIGV0Yy4gQSBjb21wICE9IDAgY2FuIG9ubHkN
Cj4gICAgICAgICAgICAgIGJlIGVtaXR0ZWQgaWYgMCA8IGxlbihwYWdlX2NkYXRhKSA8IE4g
KiBwYWdlX3NpemUuIEFuDQo+ICAgICAgICAgICAgICB1bmtub3duIGNvbXAgbXVzdCBjYXVz
ZSB0aGUgcmVjZWl2ZXIgdG8gZmFpbCB3aXRoIGENCj4gICAgICAgICAgICAgICJDb21wcmVz
c2lvbiBhbGdvcml0aG0gPHZhbHVlPiBub3QgaGFuZGxlZCIgZXJyb3IuDQo+IA0KPiBwYWdl
X2NkYXRhICBQcmVzZW50IGluc3RlYWQgb2YgcGFnZV9kYXRhIHdoZW4gY29tcCBpcyBub24t
emVyby4gQQ0KPiAgICAgICAgICAgICAgc2luZ2xlIGNvbXByZXNzZWQgb2JqZWN0IGhvbGRp
bmcgdGhlIGNvbmNhdGVuYXRpb24gb2YgdGhlDQo+ICAgICAgICAgICAgICBOIHBhZ2VfZGF0
YSBlbnRyaWVzLiBUaGUgcmVjZWl2ZXIgbXVzdCB2ZXJpZnkgdGhhdA0KPiAgICAgICAgICAg
ICAgMCA8IGNvdW50IDw9IE1BWF9CQVRDSF9TSVpFLg0KPiANCj4gDQo+IFRlZGR5LCBJIGhv
cGUgdGhpcyBmb3JtYXQgY292ZXJzIHlvdXIgcG9pbnRzOiBpdCdzIG5vIGxvbmdlciBMWjQg
c3BlY2lmaWMsDQo+IHRoZSBpbmxpbmUgY2xlbiBpbmNvbnNpc3RlbmN5IGluIGxpYnhlbmd1
ZXN0IHJlY29yZCBkaXNhcHBlYXJzLCBpdCdzIG9uZQ0KPiBibG9jayBvdmVyIGFuIGltbXV0
YWJsZSBjb3B5IG9mIHRoZSBiYXRjaCBpbnN0ZWFkIG9mIG9uZSBwZXIgcGFnZSwgdGhlDQo+
IGRlY29tcHJlc3NlZCBzaXplIGlzIGtub3duIHVwIGZyb250LCBhbmQgdGhlIGFsbG9jYXRp
b24gZGVyaXZlZCBmcm9tIGNvdW50DQo+IGlzIGJvdW5kZWQgb24gdGhlIHJlY2VpdmVyLg0K
PiANCg0KTG9va3MgZ29vZCB0byBtZS4NCg0KPiANCj4gVGhpcyBzaW1wbGlmaWNhdGlvbiBp
cyBhbHNvIGZvcndhcmQtY29tcGF0aWJsZSBpbiB0d28gZGlmZmVyZW50IHdheXM6IHlvdXIN
Cj4gNjRLQiBjaHVua2luZyBmb3IgY2FjaGUgbG9jYWxpdHkgZG9lc24ndCBkZXBlbmQgb24g
dGhlIGZvcm1hdCwgYXMgdGhlDQo+IHN0YWdpbmcgY29weSBjYW4gYmUgZG9uZSBpbiBjaHVu
a3Mgd2hpbGUgc3RpbGwgbWFraW5nIGEgc2luZ2xlIGNvbXByZXNzDQo+IGNhbGwgb3ZlciB0
aGUgd2hvbGUgYmF0Y2guIEFuZCBpZiB3ZSBmaW5kIGJlbmVmaXRzIGluIHNwbGl0dGluZyB0
aGUgcGF5bG9hZA0KPiBpbnRvIHNldmVyYWwgY29tcHJlc3NlZCB1bml0cywgdGhhdCBjYW4g
YmUgaW1wbGVtZW50ZWQgYXMgYSBuZXcgY29tcCB2YWx1ZQ0KPiB1c2luZyBhIHNlbGYtZGVs
aW1pdGluZyBmb3JtYXQgbGlrZSB6c3RkIG9yIGx6NGYgZnJhbWVzLCB3aGljaCByZXBvcnQg
dGhlDQo+IGNvbnN1bWVkIGJ5dGVzIHdpdGhvdXQgYSBuZWVkIHRvIHNwZWNpZnkgY2xlbiBv
ciBleHRyYSBmcmFtaW5nIGZpZWxkcyBhdCB0aGUNCj4gcmVjb3JkIGxldmVsLg0KPiANCj4g
DQo+IE9uIFdlZCwgMjIgSnVsIDIwMjYgYXQgMjA6NDIsIEZyZWRpYW5vIFppZ2xpbyA8ZnJl
ZGR5NzdAZ21haWwuY29tPiB3cm90ZToNCj4+IERvbid0IHdlIG5lZWQgdG8gYnVtcCB0aGUg
dmVyc2lvbiBudW1iZXIgd2hpbGUgd2UgYWRkIGEgbmV3IG1hbmRhdG9yeSByZWNvcmQ/DQo+
IA0KPiBJIGJlbGlldmUgd2UgbWF5IGF2b2lkIGhhdmluZyB0byBkbyBhIHZlcnNpb24gYnVt
cCBpZiB3ZSBhZG9wdCB0aGUgcHJvcGVydHkNCj4gdGhhdCAwIDwgbGVuKHBhZ2VfY2RhdGEp
IDwgTiAqIHBhZ2Vfc2l6ZSB3aGVuIGNvbXAgIT0gMCwgYXMgaW4gdGhpcyBjYXNlDQo+IHRo
ZSBjb21wcmVzc2VkIGRhdGEgc2VudCB0byBhbiBvbGQgcmVjZWl2ZXIgd291bGQgZmFpbCBp
biBoYW5kbGVfcGFnZV9kYXRhKCkNCj4gd2l0aCAiUEFHRV9EQVRBIHJlY29yZCB3cm9uZyBz
aXplIi4gQnVtcGluZyB0aGUgdmVyc2lvbiB3b3VsZCBtYWtlDQo+IHVuY29tcHJlc3NlZCBt
aWdyYXRpb25zIGZhaWwgaWYgdGhleSBhcmUgc2VudCB0byBvbGQgcmVjZWl2ZXJzIHRoYXQg
YWxzbw0KPiB1bmRlcnN0YW5kIHVuY29tcHJlc3NlZCBtaWdyYXRpb24sIHNvIGF2b2lkaW5n
IGlmIHBvc3NpYmxlIHdvdWxkIGJlIGdvb2QuDQo+IFRoZSBzcGVjIHNheXMgbWlncmF0aW9u
IHRvb2xzICJzaGFsbCBhbHdheXMgc2F2ZSBpbWFnZXMgdXNpbmcgdmVyc2lvbiBWIiwNCj4g
c28gaXQgZG9lc24ndCBzZWVtIGxpa2Ugd2UgY291bGQgYnVtcCB0aGUgdmVyc2lvbiBvbmx5
IHdoZW4gY29tcHJlc3Npb24gaXMgb24uDQo+IA0KPiANCj4+IElzIHRoZXJlIG5vIGtpbmQg
b2YgZGlhbG9nIGFib3V0IHRoZSBzdXBwb3J0ZWQgdmVyc2lvbj8NCj4gDQo+IFRoZXJlIGlz
IG5vIGluLXN0cmVhbSBuZWdvdGlhdGlvbiwgYW5kIHRoaXMgcHJvcG9zYWwgZG9lcyBub3Qg
YWRkIG9uZS4NCj4gQ29tcHJlc3Npb24gaXMgb3B0LWluIGF0IHRoZSBzZW5kZXIgdmlhIHhs
IG1pZ3JhdGUgLS1jb21wcmVzcywgc28gYW4gb3BlcmF0b3INCj4gd2hvIGVuYWJsZXMgaXQg
YWdhaW5zdCBhbiBvbGQgcmVjZWl2ZXIgZ2V0cyBhIGNsZWFuIGZhaWx1cmUgcmF0aGVyIHRo
YW4NCj4gY29ycnVwdGlvbi4NCj4gDQo+PiBXaHkgbm90IGV4dGVuZGluZyB0aGUgZ2VuZXJh
bGl6YXRpb24gY29tcHJlc3NpbmcgYWxsIHBheWxvYWQgb2YNCj4+IHVuY29tcHJlc3NlZCBw
YWNrZXRzICh0eXBlK2JvZHkpLA0KPiANCj4gQSBjb21wb3NhYmxlIHdyYXBwZXIgd291bGQg
YmUgYSBjbGVhbiBnZW5lcmljIG1lY2hhbmlzbSwgYnV0IEkgdGhpbmsgdGhlcmUNCj4gYXJl
IHR3byByZWFzb25zIG5vdCB0byBnbyB0aGF0IHdheSBpbiB2MjogUEFHRV9EQVRBIGlzIGVm
ZmVjdGl2ZWx5IGFsbCBvZiB0aGUNCj4gc3RyZWFtIGJ5dGVzLCBzbyBjb21wcmVzc2luZyB0
aGUgb3RoZXIgcmVjb3JkIHR5cGVzIHdvdWxkIG5vdCBzaG93IHVwIGluIGENCj4gbWVhc3Vy
ZW1lbnQuIEFuZCB0aGUgbm8tZXh0cmEtZmllbGRzIHByb3BlcnR5IGFib3ZlIGRlcGVuZHMg
b24gUEFHRV9EQVRBDQo+IHNwZWNpZmljYWxseTogYSBnZW5lcmljIHdyYXBwZXIgaGFzIG5v
IHBmbiBhcnJheSBmcm9tIHdoZXJlIHdlIGNhbiBkZXJpdmUNCj4gdGhlIHVuY29tcHJlc3Nl
ZCBzaXplLCBzbyBpdCB3b3VsZCBuZWVkIGV4cGxpY2l0IGFsZ29yaXRobSwgY29tcHJlc3Nl
ZA0KPiBzaXplIGFuZCB1bmNvbXByZXNzZWQgc2l6ZSBmaWVsZHMgb24gZXZlcnkgcmVjb3Jk
LCB3aGljaCByZS1hZGRzIHRoZSBmaWVsZHMNCj4gdGhhdCB0aGlzIHByb3Bvc2FsIHRyaWVz
IHRvIGF2b2lkLg0KPiANCj4gDQo+IFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGUgaWRlYXMg
YWJvdmUgY2FwdHVyZSB3aGF0IHlvdSBoYWQgaW4gbWluZCBpbiB0ZXJtcyBvZg0KPiBzdWdn
ZXN0aW9ucyB0byBpbXByb3ZlIHYxLg0KPiANCj4gSW4gcGFydGljdWxhciwgSSB3b25kZXIg
d2hhdCB0aGUgbWFpbnRhaW5lcnMgdGhpbmsgb2YgdGhlIHVzZSBvZiBvbmUgb2YgdGhlDQo+
IG9jdGV0cyBvZiB0aGUgUEFHRV9EQVRBIHJlc2VydmVkIGZpZWxkIGZvciB0aGUgcHVycG9z
ZSBvZiBpbmRpY2F0aW5nIHRoZSBkYXRhDQo+IGlzIGNvbXByZXNzZWQsIG9yIGlzIGl0IHBy
ZWZlcmFibGUgdG8gdXNlIGEgbmV3IFBBR0VfREFUQV9DT01QUkVTU0VEICgweDEzKQ0KPiB0
eXBlIHJlY29yZCBhcyBhIG1hbmRhdG9yeSByZWNvcmQgc28gdGhhdCBhbiBvbGQgcmVjZWl2
ZXIgZmFpbHMgbW9yZSBjbGVhbmx5DQo+IHdoZW4gaXQgZG9lc24ndCB1bmRlcnN0YW5kIGNv
bXByZXNzaW9uICJNYW5kYXRvcnkgcmVjb3JkIDxuYW1lPiBub3QgaGFuZGxlZCINCj4gKGNh
dXNlZCBieSB0aGUgc3BlY2lmaWNhdGlvbiBvZiBtYW5kYXRvcnkgcmVjb3JkcykgaW5zdGVh
ZCBvZiB3aXRoIGEgZ2VuZXJpYw0KPiBlcnJvciAiUEFHRV9EQVRBIHJlY29yZCB3cm9uZyBz
aXplIiAoY2F1c2VkIGJ5IHRoZSBjdXJyZW50IHNhZmV0eQ0KPiBpbXBsZW1lbnRhdGlvbiB0
aGF0IHJlamVjdHMgdW5leHBlY3RlZCByZWNvcmQgc2l6ZXMpPw0KPiANCg0KVGhlIHNwZWNp
ZmljYXRpb24gc2F5cw0KDQogPiBQYWRkaW5nIGFuZCByZXNlcnZlZCBmaWVsZHMgYXJlIHNl
dCB0byB6ZXJvIG9uIHNhdmUgYW5kIG11c3QgYmUNCmlnbm9yZWQgZHVyaW5nIHJlc3RvcmUu
DQoNCldoaWNoIGlzIG5vdCByZWFsbHkgZ29pbmcgdG8gaGVscCBpZiB3ZSBhZGQgYSBuZXcg
ZmllbGQgdGhhdCBtYXR0ZXJzIG9uIA0KaG93IHRoZSBjb250ZW50IGlzIG9yZ2FuaXplZC4N
Cg0KVG8gYXZvaWQgY29uZnVzaW9uLCBpdCBtYXkgYmUgZGVzaXJhYmxlIHRvIGFkZCBhIG5l
dyB0eXBlIA0KKFBBR0VfREFUQV9DT01QUkVTU0VEKSwgYnV0IEknbSBub3QgZnVsbHkgc29s
ZCBvbiBpdC4NCg0KPiANCj4gTWFyY3VzDQo+IA0KPiANCg0KVGVkZHkNCg==
--------------qL9BXv60iFiNIQQzDu3jqzUh
Content-Type: application/pgp-keys; name="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Disposition: attachment; filename="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7L
TBVHV/XOZw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJ
T4ny+OGntnJntUoRKRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJA
WicutjkkUgd28Bh6HV9EIumHtCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO
8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaTVqMdqul07o72m3eA2mf+LMu9a04FX/d4
wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/EoucejoZ5SH49ksmVAmKOLkt
OaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+SPhHar7TPKjFz0G3D
PNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89MXfQXZ3q
t1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWj
moACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNz
uyOVCskwfUZPla6Zpd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp
0x0HfuhcYfAYPR46XHTvjaJEv99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuR
OxdK8G+YHccJY8PvWSq2K2yiae2KGiAv1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50
wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhPeP3IdpfWc8cyRLXF06Rk46YM
YCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcTUwgnYlFRk2FLq0Qe
KEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9Egr/Wmu3
MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEM
AKiQiZa3yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ
3DbVf+en3/FvdVZg2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTm
etSG5/52AjtmPFtlXAk0NmLvfJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0
s3109sJeXT5ImVdphFs9cvyZyBT9t1PbRowv58EgV0zE4hbAeVkULAbxFV5b/ExT
jjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKbYu6NCfiHfEyB3Xyg9hfdrRgj
MRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ovXoK4jm+Py0FiUGUa
A6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/eVtR2Q1w
ZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWj
moACGwwACgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiV
oUiHYN5QwhnbZnsaJDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764Qxy
X6rld2f2RcWkDuBHun55ZWXjby8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk
/dS0XTOQi2wVUb17sW/+ybCEokdVacZGzOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fu
oGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+lOWSvdNHgoEkWR0RXBPQjnGm
LKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/OffO485NOTKwGOxyWb0
06cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR8ULR9nX0
LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
x9fhaZEsniw8/bYgC3igkk5YJiOa
=3DlUIA
-----END PGP PUBLIC KEY BLOCK-----

--------------qL9BXv60iFiNIQQzDu3jqzUh--

--------------hNQ5LyUMizokDAxHrKBPhLw7--

--------------tLoy9wFY8vD4kZQNnvXo5qTt
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmpxrZYFAwAAAAAACgkQZg+p0QLLz9CC
EAwAqmEMd1SikFOClTEEjZw+ESDICB9UuEyhrZ5LK4CaAQsO3HxMYwfN7st4RyL/PBHy4CbyddvQ
hu1HS0T3XyU2WjiahkSx9IhrEYjAU1B89bsNi5hpofhgGpBi4qCocQ6iJgpBWg9z6bPUhDCKC2qs
tWg0wndY7ZwFqx/PiE1vPTpp1FRntQQwS+o9JlsUKuNlk8stMvrQz1j+vyaZlDBKbLZ+j76QrNti
drccO+ikWGn4mAQWqfEdDhkRorR3hYrffs1bRT+/wy6BeoxGzUEPH+JnMY1kB5JohrwKKv0fNqwm
oYj1XVInPKZXAnjMQqoVf/Ykm8xIAtPkWap4Cu9CteUQKe67Jg+wwURzN5HqV4GRFhPvBsRDptom
TVsHe+ZDIQEJ1b73oVJEZzqx60Vq5Ws9ehvWMi0l8lfrwgDZKFu/6hibl5RSfX7YR0BQI+X0Io1/
jFxYTrJjOwF7huiDb9TBj9eVSslKNLS1h0nUvMCFDuN7OAFD+r47h+m0y8Vk
=gycT
-----END PGP SIGNATURE-----

--------------tLoy9wFY8vD4kZQNnvXo5qTt--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 09:28:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 09:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382061.1625464 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrBRI-0000MA-9c; Tue, 04 Aug 2026 09:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382061.1625464; Tue, 04 Aug 2026 09:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrBRI-0000M2-4T; Tue, 04 Aug 2026 09:28:00 +0000
Received: by outflank-mailman (input) for mailman id 1382061;
 Tue, 04 Aug 2026 09:27:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrBRG-0000Lv-K0
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 09:27:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrBRG-00EZdy-0g
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 11:27:58 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a71b08e-5cb7-0a2a0a5109dd-0a2a4508ec64-38
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 11:27:57 +0200
Received: from [74.125.224.47] (helo=mail-yx1-f47.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a71b09c-f659-0a2a45080019-4a7de02fb8ed-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 11:27:56 +0200
Received: by mail-yx1-f47.google.com with SMTP id
 956f58d0204a3-66892c81725so5920962d50.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 02:27:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1785835675; cv=none;
        d=google.com; s=arc-20260327;
        b=gTdAkbaR+cuCBKZz+pwgrlCYUatnChk+MfwON2JuZqM5KIsOGuC6q15YEc2z4VElQy
         xAnwsy+YVmqAlFohDqtzOAWaq4hC1zB+y8hOGXxzYg/xA83Mssap6qD2I0q0neFV/qbY
         WX2EzeTGPD8v78cLhq5e5kgiN2phQGl6uCGb3bn+sJV0Vnzme7yVbDTVCp2hLKvww8Tt
         /frNv0qbLJdhvojVFld1Dm7rhU5ryx9ykQmZcDlsPJ9+qiqR1aCQCmQtyJ1zEGu06bZj
         WRj5zi3kqeXwt6MKBQYr0Ij+1tw1sRMUuzM5M6w/IO1cZE3yzqFG323//3tqOkl3RaLN
         75sg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=fQwOQ6fPXMYo5N5tkHcaXYRfhVBL6xu1DTd6Y7Q0NLk=;
        fh=xbnCk1fMGZS2xoJIy7HSNqzoA8cI7GtUsg/C2XqwZXc=;
        b=MIP+Gd68Sh39DtvaKeT4HMDX6FG26t23LCc9ZRrfLBJyiXJzsjibkosV0LnFZ9I9ms
         Hmf5B7NNHO1piJ80Md5OLCTvtN2qLbjtL51LiH+WBj4vxbxcTtoauhX+Ualb2+A97dmy
         RBr25WssZwOCvdwel1KuxfKo/ns0B7w1G7wqcChOmF+Jk9JObWvWOzmRab2VU5q99RO/
         tSa6CjqTMT8R5pMWIACLUdYLE34vhkj9zlbkg3/CIfVsdwB4xaYyY3uwFmJyhx6qvKWy
         VPFX7ekhbsZrUNpQ1L206SnGWf0dodFp1PZJ5ZugCQvQCbbskQArcjTTicxnuAS0gnyo
         8drQ==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785835675; x=1786440475; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=fQwOQ6fPXMYo5N5tkHcaXYRfhVBL6xu1DTd6Y7Q0NLk=;
        b=DPEi/Kw/47tQGcGPnT9oS8L8/7/ebuWSHR4vS2bv/927yBTY92ltjUSEonyN06e4lJ
         aDNDEbLEv1troLte9ri/HW3Vy6rvSQBNj7VlEx+w10m/YY/y/zqP9rOx9g93ODaBELgk
         mbcLwACyDtdCsRgCIAC3Tgzne6kw6jcv7PUzzC220mxCXnQPivcmCK0cvk4eHJkeHncv
         tytgk5vbg560mjBqmhQZgnxfhetvYwZIAUNhPR9tY7C0YpArlovgLbngKCXRCHdnHgZq
         Ggcz03QLtVLonqKzYLV1GJEaVabyq90Fba1nLIPrqVtY73Uj2YY5rvunCrxSQOupHT7T
         049Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785835675; x=1786440475;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=fQwOQ6fPXMYo5N5tkHcaXYRfhVBL6xu1DTd6Y7Q0NLk=;
        b=hePIj4v+OHppFsq/ti80oyXNRX8gAbncwMH0lQ1WIPvuDcAc0f5D/pIYinOH1atPWm
         ewgyjNuGn/3N57+kGo/Z6okBQFHJ0VJaELLq9faUR82lw1EopZ+Vweu678sf6eJTteYx
         v1xOyumfYLc78S0qUB23DBK7wAxlE7XKFCdBzXVVN0follQd+Eu5nCe2FoYBrDlP908m
         XTWDNc5ZZusAq2bemn5VVoG34G6QYv0f99uV7xYPN2CeqHdQkFYp7gHTWbyrfGM1348G
         7/n5EjPnRXyGoGmD9aCdTWJ5eGOvZ3qALEFtk8g7OyqC3WRaXbLenIje0zxAABczQxw5
         98sA==
X-Forwarded-Encrypted: i=1; AHgh+RpWPlOZhsUxa+SZ9lXDlkFLhBOiC/Y79KVU7JY+gKHW1xW5wBwwCVWQaj8l+04Z5zXKa/0E6piCo94=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwS8OhoLTzDCqIhMqeH96VkuqMHm7WjA5+KOyqCeK2P56Mj3zWK
	zXKkqBv61zRbn/ycBmagpzLJXATw7uUEnx9I/cqLwWYyz6gw0xep8/SjGmvKv9poFKcLS1PDFgG
	euR1VgMmq0XFjRLPOQrznAXhWERXi+e8=
X-Gm-Gg: AR+sD11i/EsstZcBcM2WEpIQD6utFlwDOU8HXtjYn9LEJQo6ttJoN2TC31KrvAaCEMM
	pDP3KwaLV79GtMz2y9DWjB60C97y99RAnl5q2UUebm1M3AKjRXCBDz++f5+grQxoKDYNfAdMdO9
	Tax3wbEnuETRpD7zBzLjDIiDssWwp3tQCGjp81n5hDrWB67vKAf3XZ7jlutXsVmDCzv76iJzSc6
	ARIBDpUHLBWLPH9mVaehO2QvMk1IwxUeDVskByW2aJgGHliAjoHyWTxzVz2eTEEQebxwh2LO9Fe
	xRt/gu/QlWktntDUMfsqHLTER6FB31C+ZHz+YvrBBCsxURhipIwXzHJYUWiRhaGHKEU9M5XCHsK
	Q
X-Received: by 2002:a53:c48e:0:b0:668:43ff:265d with SMTP id
 956f58d0204a3-6694f17589cmr12645410d50.33.1785835675350; Tue, 04 Aug 2026
 02:27:55 -0700 (PDT)
MIME-Version: 1.0
References: <20260720154832.1907401-1-marcus.granado@citrix.com>
 <20260720154832.1907401-2-marcus.granado@citrix.com> <1784622046.8631fc262581453bbf619ec5b2062170.19f83c35cd4000edb5@vates.tech>
 <CAHt6W4erBfB+H_0d+2rQ0apz9Jt6ex+WVjEjyPm6EApoHVJgmg@mail.gmail.com>
 <1784755834.8631fc262581453bbf619ec5b2062170.19f8bbccffd000edb5@vates.tech>
 <CAHt6W4cWLfSVoCSgr-YsQb1Mv=VZek0CakTBwK7tx_n9RkeiUg@mail.gmail.com>
 <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>
 <1785834903.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@vates.tech>
In-Reply-To: <1785834903.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@vates.tech>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 4 Aug 2026 10:27:44 +0100
X-Gm-Features: AUfX_myRCQgeCxpioVZftRZlPcB9bBWODlwGQuWLd2QIALmUwjZBZ_LIOFxb_iU
Message-ID: <CAHt6W4dHih5z1LpRpdRiU_CC0dCQTF=324=KM6QJbUHS1xQ1GQ@mail.gmail.com>
Subject: Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Marcus Granado <marcus.granado@citrix.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Roger Pau Monne <roger.pau@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-c1860d/1785835677-CEF5F87B-66FF65BF/0/0
X-purgate-type: clean
X-purgate-size: 8056

On Tue, 4 Aug 2026 at 10:15, Teddy Astie <teddy.astie@vates.tech> wrote:
>
> Le 03/08/2026 =C3=A0 19:23, Marcus Granado a =C3=A9crit :
> > On Wed, 29 Jul 2026 at 10:14, Frediano Ziglio <freddy77@gmail.com> wrot=
e:
> >> About compressing all together and considering also the issue of
> >> memory changing while sending I would vote to copy the memory in a
> >> temporary buffer to avoid this. One advantage is that it simplified
> >> the format. The current LZ4 implementation seems to cope with data
> >> changes but nothing guarantees it in the future, the buffer you are
> >> passing is not supposed to change while you compress it.
> >
> >
> > Agreed. Frediano and I discussed this further, including simplification=
s on
> > the compression record for v2 so that the page data compression:
> > * compresses the whole batch together
> > * and uses a staged copy for it as you and Teddy suggested (so that we =
do
> > not need to worry about mutating buffers affecting LZ4 or other algorit=
hms).
> >
> > Once there's exactly one compressed blob per record, there's no need fo=
r
> > extra fields to describe the compressed data, as the uncompressed batch
> > size is known (and bounded by MAX_BATCH_SIZE * page_size), and its
> > compressed size can be inferred from the size of the emitted compressed
> > record without a need for an explicit field for clen or a field with th=
e
> > number of raw compressed blobs. This means the separate PAGE_DATA_LZ4
> > record type is not needed, and the proposal for v2 compression record c=
ould
> > simplify to reusing PAGE_DATA and spending one octet of its reserved wo=
rd
> > as follows:
> >
> >
> >       0     1     2     3     4     5     6     7 octet
> >      +-----------------------+-----+-------------------+
> >      | count (C)             | comp| (reserved)        |
> >      +-----------------------+-----+-------------------+
> >      | pfn[0]                                          |
> >      +-------------------------------------------------+
> >      ...
> >      +-------------------------------------------------+
> >      | pfn[C-1]                                        |
> >      +-------------------------------------------------+
> >      | page_data[0..N-1] if comp =3D=3D 0                  |
> >      | or page_cdata     if comp !=3D 0                  |
> >      +-------------------------------------------------+
> >
> > with two new entries in the field table:
> >
> > comp        Compression algorithm applied to the page contents. 0
> >              means none, and the record is exactly as it is today. 1
> >              means LZ4 block format. Other values are reserved for
> >              other future formats like ZSTD etc. A comp !=3D 0 can only
> >              be emitted if 0 < len(page_cdata) < N * page_size. An
> >              unknown comp must cause the receiver to fail with a
> >              "Compression algorithm <value> not handled" error.
> >
> > page_cdata  Present instead of page_data when comp is non-zero. A
> >              single compressed object holding the concatenation of the
> >              N page_data entries. The receiver must verify that
> >              0 < count <=3D MAX_BATCH_SIZE.
> >
> >
> > Teddy, I hope this format covers your points: it's no longer LZ4 specif=
ic,
> > the inline clen inconsistency in libxenguest record disappears, it's on=
e
> > block over an immutable copy of the batch instead of one per page, the
> > decompressed size is known up front, and the allocation derived from co=
unt
> > is bounded on the receiver.
> >
>
> Looks good to me.
>
> >
> > This simplification is also forward-compatible in two different ways: y=
our
> > 64KB chunking for cache locality doesn't depend on the format, as the
> > staging copy can be done in chunks while still making a single compress
> > call over the whole batch. And if we find benefits in splitting the pay=
load
> > into several compressed units, that can be implemented as a new comp va=
lue
> > using a self-delimiting format like zstd or lz4f frames, which report t=
he
> > consumed bytes without a need to specify clen or extra framing fields a=
t the
> > record level.
> >
> >
> > On Wed, 22 Jul 2026 at 20:42, Frediano Ziglio <freddy77@gmail.com> wrot=
e:
> >> Don't we need to bump the version number while we add a new mandatory =
record?
> >
> > I believe we may avoid having to do a version bump if we adopt the prop=
erty
> > that 0 < len(page_cdata) < N * page_size when comp !=3D 0, as in this c=
ase
> > the compressed data sent to an old receiver would fail in handle_page_d=
ata()
> > with "PAGE_DATA record wrong size". Bumping the version would make
> > uncompressed migrations fail if they are sent to old receivers that als=
o
> > understand uncompressed migration, so avoiding if possible would be goo=
d.
> > The spec says migration tools "shall always save images using version V=
",
> > so it doesn't seem like we could bump the version only when compression=
 is on.
> >
> >
> >> Is there no kind of dialog about the supported version?
> >
> > There is no in-stream negotiation, and this proposal does not add one.
> > Compression is opt-in at the sender via xl migrate --compress, so an op=
erator
> > who enables it against an old receiver gets a clean failure rather than
> > corruption.
> >
> >> Why not extending the generalization compressing all payload of
> >> uncompressed packets (type+body),
> >
> > A composable wrapper would be a clean generic mechanism, but I think th=
ere
> > are two reasons not to go that way in v2: PAGE_DATA is effectively all =
of the
> > stream bytes, so compressing the other record types would not show up i=
n a
> > measurement. And the no-extra-fields property above depends on PAGE_DAT=
A
> > specifically: a generic wrapper has no pfn array from where we can deri=
ve
> > the uncompressed size, so it would need explicit algorithm, compressed
> > size and uncompressed size fields on every record, which re-adds the fi=
elds
> > that this proposal tries to avoid.
> >
> >
> > Please let me know if the ideas above capture what you had in mind in t=
erms of
> > suggestions to improve v1.
> >
> > In particular, I wonder what the maintainers think of the use of one of=
 the
> > octets of the PAGE_DATA reserved field for the purpose of indicating th=
e data
> > is compressed, or is it preferable to use a new PAGE_DATA_COMPRESSED (0=
x13)
> > type record as a mandatory record so that an old receiver fails more cl=
eanly
> > when it doesn't understand compression "Mandatory record <name> not han=
dled"
> > (caused by the specification of mandatory records) instead of with a ge=
neric
> > error "PAGE_DATA record wrong size" (caused by the current safety
> > implementation that rejects unexpected record sizes)?
> >
>
> The specification says
>
>  > Padding and reserved fields are set to zero on save and must be
> ignored during restore.
>
> Which is not really going to help if we add a new field that matters on
> how the content is organized.
>

Yes, there's no check for "_res1" being 0, however there's this check:

    if ( rec->length !=3D (sizeof(*pages) +
                         (sizeof(uint64_t) * pages->count) +
                         (PAGE_SIZE * pages_of_data)) )
    {
        ERROR("PAGE_DATA record wrong size: length %u, expected "
              "%zu + %zu + %lu", rec->length, sizeof(*pages),
              (sizeof(uint64_t) * pages->count), (PAGE_SIZE * pages_of_data=
));
        goto err;
    }

so, as long as we require that the compressed data is less than the
uncompressed one (we should) it's fine.


> To avoid confusion, it may be desirable to add a new type
> (PAGE_DATA_COMPRESSED), but I'm not fully sold on it.
>

Not strong but if I could vote I would just use part of "_res1" as proposed=
.

> >
> > Marcus
> >
> >
>
> Teddy

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 10:08:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 10:08:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382072.1625471 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrC3p-0006nT-0Y; Tue, 04 Aug 2026 10:07:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382072.1625471; Tue, 04 Aug 2026 10:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrC3o-0006nM-To; Tue, 04 Aug 2026 10:07:48 +0000
Received: by outflank-mailman (input) for mailman id 1382072;
 Tue, 04 Aug 2026 10:07:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrC3n-0006m1-BM
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:07:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrC3n-004jQy-12
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:07:47 +0000
Received: from mail-lf1-f52.google.com ([209.85.167.52])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrC3m-008pHX-3C
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:07:47 +0000
Received: by mail-lf1-f52.google.com with SMTP id
 2adb3069b0e04-5b0115b9e17so4162282e87.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 03:07:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:Cc:To:Subject:Message-ID:
	Date:From:In-Reply-To:References:MIME-Version;
	bh=7lDpe5KpYW9iI4a2Xe0Pg6NsMRjTcXcMnAiS1mu0Vls=; b=JbwKGZd17ljrw8I//uuoj7CGRE
	KdEOaH78F3fFlhf6k2ZK1BfNh8OlYw0JcGQyk+Chrhw2zEZKZxKl21d64OgNM96QefI9UtbGyhK6f
	cJnlP4PGcgQfsdi+gl1z+vY28zm/X83YMzlCjv8vGUV3FtJq3ukiAUvCtXmvwfLLyPrE=;
X-Forwarded-Encrypted: i=1; AHgh+Ro0+x7AwDURAINbyKABqtZ6Y+8yIBR+L8UBhJ+jq8/jcKUEVcyet+0yxkDbI9j4ENaE9IxIGPhXc5k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YweBcrIgDyxzRZ5V6pw9buCDKIHueRAELl39n5tXTcjX029yauT
	ow1AEOamgRcsyaJzeJssi+reaV7DQfG82bdyKKo5OP09hN7+3V7U0wauGNLV9jlw1jM/rTcyjdt
	zEB/8S8hGtFALesqnbVLJ3XUKP/aLUOY=
X-Received: by 2002:a05:6512:3ba3:b0:5ae:b36d:bb1 with SMTP id
 2adb3069b0e04-5b2e4f1a62cmr3090684e87.4.1785838065938; Tue, 04 Aug 2026
 03:07:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
In-Reply-To: <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Tue, 4 Aug 2026 20:07:33 +1000
X-Gmail-Original-Message-ID: <CAFLBxZacKKXosB3D5V0ahVWCWm76pkQBE6j80_UV--YHt44M8w@mail.gmail.com>
X-Gm-Features: AUfX_mzEH8wS0lJD_7rm_YVid-q_Smc21r0QSHW0rIMTEvJCLS_nLYGxc5SGcCQ
Message-ID: <CAFLBxZacKKXosB3D5V0ahVWCWm76pkQBE6j80_UV--YHt44M8w@mail.gmail.com>
Subject: Re: Linux PV domU with >1 vCPU never resumes after xl save/restore
To: Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Content-Type: multipart/alternative; boundary="0000000000008bf724065835d353"

--0000000000008bf724065835d353
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 4, 2026 at 6:02=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrot=
e:

> On 04.08.2026 08:12, George Dunlap wrote:
> > Saving and restoring a multi-vcpu PV guest appears to have been broken =
in
> > Linux for some time (observed 6.6.56 and 6.12.86).  Report below from
> > Claude Fable; I've independently verified the behavior on vanilla Linux
> > 6.6.56.  Claude seems to think it's a bug in Linux.
>
> Just to double check, as there was a crucial fix there recently: This is
> with
> a Xen including bedbc17d8407 ("x86/domctl: restore all registers in
> arch_{get,set}_info_guest()")?
>

Ah, yes, that seems to have done the trick.  Sorry for he noise.

 -George

--0000000000008bf724065835d353
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 4, =
2026 at 6:02=E2=80=AFPM Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.com=
">jbeulich@suse.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">On 04.08.2026 08:12, George Dunlap wrote:<br>
&gt; Saving and restoring a multi-vcpu PV guest appears to have been broken=
 in<br>
&gt; Linux for some time (observed 6.6.56 and 6.12.86).=C2=A0 Report below =
from<br>
&gt; Claude Fable; I&#39;ve independently verified the behavior on vanilla =
Linux<br>
&gt; 6.6.56.=C2=A0 Claude seems to think it&#39;s a bug in Linux.<br>
<br>
Just to double check, as there was a crucial fix there recently: This is wi=
th<br>
a Xen including bedbc17d8407 (&quot;x86/domctl: restore all registers in<br=
>
arch_{get,set}_info_guest()&quot;)?<br></blockquote><div><br></div><div><sp=
an style=3D"background-color:transparent">Ah, yes, that seems to have done =
the trick.=C2=A0 Sorry for he noise.</span></div><div><span style=3D"backgr=
ound-color:transparent"><br></span></div><div><span style=3D"background-col=
or:transparent">=C2=A0-George=C2=A0</span></div></div></div>

--0000000000008bf724065835d353--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 10:26:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 10:26:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382082.1625481 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrCMD-0001iy-Fn; Tue, 04 Aug 2026 10:26:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382082.1625481; Tue, 04 Aug 2026 10:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrCMD-0001iq-CE; Tue, 04 Aug 2026 10:26:49 +0000
Received: by outflank-mailman (input) for mailman id 1382082;
 Tue, 04 Aug 2026 10:26:47 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrCMB-0001ik-Qt
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:26:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrCM8-000Epx-OT
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 12:26:44 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a71be44-5cb7-0a2a0a5109dd-0a2a450693e8-42
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 12:26:44 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a71be64-195a-0a2a45060019-d1558029dd44-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 12:26:44 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so25572265e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 03:26:44 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b85be7sm395082985e9.2.2026.08.04.03.26.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 03:26:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785839204; x=1786444004; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=H6sw/ezMudW4mMwFYZn+KvA6eMQevSBKyPZciC7qYM4=;
        b=X0S2to+ZltJ/iKhreWlAIWe663vrfpc6Z5nrqQSXFX/Og6t0wGARC4sOAbATzhY8r2
         IBYlUzHCB4do/w+5Q3eISCzOCxr8Xyts1wQONNeUz/lQ+BsfaHjksZKcIhDFYSanoSer
         GCXyxap4DtkL5ODH+kTmzPDS0pqBjhha7y5mK6enPqAkN15CJsIzSqzNYKErIRxq/1mn
         fe/Xidia8IRtGNmuCZK3k6Baj+nY3rwy/IZs+FsW0lLXOi8yGde6KcQTSPL8Z1upwUXs
         E71jkss631U8Kt4v8Tma0fRbfqUqt2rmVLNaPBkIfm6cM66L59Bg1rlIguuUBPS45Pee
         2uHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785839204; x=1786444004;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=H6sw/ezMudW4mMwFYZn+KvA6eMQevSBKyPZciC7qYM4=;
        b=oabTn5iDoLI8961hLtjznoSwv23YPO3q/Of65aCBMyJyiOEFmehlexKINUtvBj0GuN
         loKoOQLtHTMEkNxTrDjdlAk+O3emDYRMbIjpMf8P4D2RvBNIkicJbsxnEae8TjAwFrlo
         v9EQE9EG2E5LjUmWcTggvXTHvhxPCRooezLiShbR3x/A0wionYzeoJUSKVAyjOsCjSnL
         DoekLkXJl1MM7hGfXKtwrtPd5V74c1k0tzjRwuoyxBQdEuWnUnfLKbij+IWU0r8RFwcY
         USDKM/wpXUeogcAIyGXSrdyLzyrZW/763h1rOzpsVzF5GedktNlSRrXFBjKzPitDxo+/
         OSsA==
X-Forwarded-Encrypted: i=1; AHgh+RqXWkih57W8G5Mx/Ytb1x2qhK5TxTEVe0m2VLI0mT+EmDcVWcakXi9MiyTwXj29VDtAxoktq1gb8Cs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxK0rCuPH0YJ3VbKeDeF8MD8nndxIbfodi0HotPKNbIXso/t/YW
	/QZT0U9xKda8xuTS67V6oDZcz+6J81c4znqgT+XbBnJI5DCwiHHqu0iA
X-Gm-Gg: AR+sD10pjhikCG0Q0JGECgRY6vnrunwnKOYyGmuHDGqalgKPLnmID0zz/9771iveQYs
	GMi4HeBdYk8MRUN9GcSMdrKFKOco81GqHI4L95xiss637+76ZsDAAzQN3OY8LDBwHFi13xxZPsK
	VfOXswl2kiixvTSgS2A6qmZ1907qAjPpoG2K8iOVxxqJzcnPG+36Eg20w90xG8HBe6m794npLPe
	j9TMu3vKWPOhunqcmCms7oTn0bjCbSj1zR7MmYif0w+ibdYm24xG3WpFPaOh5umH2DFLKW5rqmH
	I63QoxiOCtCSIoKeQsYmLEaGxNGaWvY47BB1xmqz2+kJ5exZj1kR7jTJ66HHOMLeVbkI/+lsdOX
	Ar0T7bL8yCnde0MpPyagaa+l0BlLNagMNy0FFzPiagZ7NJinyQpS32zFxWSclYb+DJfRmA0+cRu
	FfTgM+W4mxr8M5QwdpZLpchrbL/Lr2V8GWQXBx9NuIHpj+Jkxx+cEG/u785bc3ikFvltwIkEcVC
	5ow9rHW0W0T1jortO3SiK0bFVH6yDDw+HvlUvWr+XQ=
X-Received: by 2002:a05:600c:8b17:b0:495:4491:b8c2 with SMTP id 5b1f17b1804b1-4980c66c926mr305125115e9.3.1785839202753;
        Tue, 04 Aug 2026 03:26:42 -0700 (PDT)
Message-ID: <24351c43-0b41-45f9-8d57-e88308edd5db@gmail.com>
Date: Tue, 4 Aug 2026 12:26:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <704870c1-18ec-4c7b-873c-e07e77ae0d39@suse.com>
 <d5867843-802d-493f-a535-1f40d9337b63@gmail.com>
 <2ef6b295-862b-40be-a7d2-c94a6378126b@suse.com>
 <636a6183-8c66-41b2-b820-6a02098fd33d@gmail.com>
 <51e537a4-f568-458d-9625-ada7fbebd842@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <51e537a4-f568-458d-9625-ada7fbebd842@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785839204-FC20077B-8F76657E/10/73395122804
X-purgate-type: spam
X-purgate-size: 3203



On 8/3/26 12:41 PM, Jan Beulich wrote:
> On 31.07.2026 17:24, Oleksii Kurochko wrote:
>> On 7/30/26 6:09 PM, Jan Beulich wrote:
>>> On 30.07.2026 18:03, Oleksii Kurochko wrote:
>>>> On 7/28/26 2:23 PM, Jan Beulich wrote:
>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>> --- /dev/null
>>>>>> +++ b/xen/arch/riscv/mmio.c
>>>>>> @@ -0,0 +1,145 @@
>>>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>>>>> +/*
>>>>>> + * Copyright (C) Vates
>>>>>> + */
>>>>>> +
>>>>>> +#include <xen/bsearch.h>
>>>>>> +#include <xen/lib.h>
>>>>>> +#include <xen/rwlock.h>
>>>>>> +#include <xen/sched.h>
>>>>>> +#include <xen/sort.h>
>>>>>> +#include <xen/xvmalloc.h>
>>>>>> +
>>>>>> +#include <asm/current.h>
>>>>>> +#include <asm/mmio.h>
>>>>>> +
>>>>>> +static enum io_state handle_read(const struct mmio_handler *handler,
>>>>>> +                                 struct vcpu *v,
>>>>>> +                                 mmio_info_t *info)
>>>>>> +{
>>>>>> +    register_t r = 0;
>>>>>> +    enum io_state rc;
>>>>>> +
>>>>>> +    rc = handler->ops->read(v, info, &r);
>>>>>> +    if ( rc == IO_HANDLED )
>>>>>> +        info->data = r;
>>>>>
>>>>> Extending my earlier comment: Why could ->read() not put the value directly
>>>>> into info->data? And why ...
>>>>>
>>>>>> +static enum io_state handle_write(const struct mmio_handler *handler,
>>>>>> +                                  struct vcpu *v,
>>>>>> +                                  mmio_info_t *info)
>>>>>> +{
>>>>>> +    return handler->ops->write(v, info, info->data);
>>>>>
>>>>> ... can't write take the value directly from info->data?
>>>>
>>>> I totally agree, it can. Do you think it is better to keep ->data and
>>>> drop an argument 'r' or vice versa?
>>>
>>> How can I know? You know future plans you have.
>>>
>>>>>> +}
>>>>>> +
>>>>>> +/* Assumes mmio regions are not overlapping. */
>>>>>
>>>>> Are you guaranteeing this anywhere?
>>>>
>>>> There is no such guarantee. register_mmio_handler() simply adds the
>>>> handler to the handlers array without performing any checks. I can add
>>>> such a check. The only question is whether it should be enabled only in
>>>> debug builds or in all builds.
>>>
>>> Depends on what other badness can happen when this is violated. My gut
>>> feeling is that checking in debug builds may be enough.
>>
>> Overlapping regions would be a Xen bug rather than something a guest can
>> trigger — register_mmio_handler() is only called from Xen's own emulated
>> device code, so the layout isn't under guest control.
>>
>> The badness is worse than just mis-emulating one device though:
>> cmp_mmio_handler() is used both by bsearch() and by sort(). With
>> overlapping regions it's no longer a consistent ordering, so sort() may
>> produce an arbitrary order and lookups can then fail (or match the wrong
>> handler) even for regions which don't overlap themselves. That would
>> show up as a spurious fault injected into the guest, which is quite hard
>> to debug.
> 
> Didn't you say you'd get rid of the use of sort()?
> 
Yes, I will. I just wrote that for the case if sort() will still present.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 10:30:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 10:30:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382090.1625490 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrCPy-0003dJ-Tc; Tue, 04 Aug 2026 10:30:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382090.1625490; Tue, 04 Aug 2026 10:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrCPy-0003dC-R9; Tue, 04 Aug 2026 10:30:42 +0000
Received: by outflank-mailman (input) for mailman id 1382090;
 Tue, 04 Aug 2026 10:30:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fcc534b55000e099@swg.vates.tech>)
 id 1wrCPx-0003d6-U4
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:30:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrCPx-008S8k-1s
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 12:30:41 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fcc534b55000e099@swg.vates.tech>)
 id 6a71bf48-bab6-0a2a0a5309dd-0a2a45018890-20
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 12:30:40 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fcc534b55000e099@swg.vates.tech>)
 id 6a71bf50-5984-0a2a45010019-b9ff1c2392cb-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 12:30:40 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fcc534b55000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 04 Aug 2026 10:30:38 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id D5A9882B38;
 Tue,  4 Aug 2026 12:30:37 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=zZvTd+A2AJmp5zfcAxTGKFv6JW42t67YlT7CJlkzJ2E=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=ZfxHyD/dqMUR8OdMZ1EmSMLVn4gFHSliuuXtCc059BdXuDkOfYQ1VIEvVMaWvXGEOM2jj+GEf
 bQBpVmZ0EH4ELE4HECdtF8YeoNkW976m7WHGx/HthPbuR/biF2pZXNOGW+kw/jQXdesMjMZBiqY
 oRzvl9YFbHASRL8r3lFLGi3X3gmk9LedHc2lSVUGDDvich9KFo4rpID+j4q/+LzDFHO3HeZhM/x
 atuzuw1ALtCfa65IJEWOZOg1nPauCooWEdKi7ULAMOevxSp5IZgz9DpxIpkxVdD6e0tsjKNON3k
 mHI3I6fDwne0d1R5Ki5eT2w6BPo5BXBd061a66gQR8mw==
X-Zone-Loop: 5a14cca138ed5b2c24699c48932ac69c099221f97f91
x-campaign-type: default
x-transaction-id: b87eefd5-552d-4b01-b45d-3aa199a70e53
x-swg-uid: 01-d2f83eec-1717-4f12-9172-00c1fd93b1e0
X-Mailer: Sweego
Message-ID:
 <1785839438.8631fc262581453bbf619ec5b2062170.19fcc534b55000e099@vates.tech>
x-swg-bid: 1785839438.8631fc262581453bbf619ec5b2062170.19fcc534b55000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Tue, 4 Aug 2026 12:30:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH 4/4] x86: add new pte_get_and_clear hypercall
To: Kevin Lampis <kevin.lampis@citrix.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com
References: <20260727150615.1373200-1-kevin.lampis@citrix.com>
 <20260727150615.1373200-5-kevin.lampis@citrix.com>
Content-Language: en-US
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <20260727150615.1373200-5-kevin.lampis@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------MxACY9YVHgqPACfBH3sKssh2"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1785839437997
X-purgate-ID: tlsNG-d62444/1785839440-1F262757-D7B2A83C/0/0
X-purgate-type: clean
X-purgate-size: 10018

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------MxACY9YVHgqPACfBH3sKssh2
Content-Type: multipart/mixed; boundary="------------Lj3c0HMPasC8mjY3UC1lTLsW";
 protected-headers="v1"
From: Teddy Astie <teddy.astie@vates.tech>
To: Kevin Lampis <kevin.lampis@citrix.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com
Message-ID: <515e7c68-19a0-4d8c-815c-ca062a1aad04@vates.tech>
Subject: Re: [PATCH 4/4] x86: add new pte_get_and_clear hypercall
References: <20260727150615.1373200-1-kevin.lampis@citrix.com>
 <20260727150615.1373200-5-kevin.lampis@citrix.com>
In-Reply-To: <20260727150615.1373200-5-kevin.lampis@citrix.com>

--------------Lj3c0HMPasC8mjY3UC1lTLsW
Content-Type: multipart/mixed; boundary="------------IFX40LrLar5N7Oq0qB0i5dsL"

--------------IFX40LrLar5N7Oq0qB0i5dsL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMjcvMDcvMjAyNiDDoCAxNzowNywgS2V2aW4gTGFtcGlzIGEgw6ljcml0wqA6DQo+IFRo
aXMgbmV3IGh5cGVyY2FsbCB1c2VzIHRoZSBzYW1lIGludGVyZmFjZSBhcyB0aGUgbW11X3Vw
ZGF0ZSBoeXBlcmNhbGwgZXhjZXB0DQo+IHRoZSBvbGQgUFRFIHZhbHVlIGlzIHJldHVybmVk
IGluIHRoZSBtbXVfdXBkYXRlX3QtPnZhbCBmaWVsZC4NCj4gDQo+IFRoZSBwdXJwb3NlIG9m
IHRoaXMgbmV3IGh5cGVyY2FsbCBpcyB0byBpbXByb3ZlIHBlcmZvcm1hbmNlIG92ZXIgdGhl
IGN1cnJlbnQNCj4gdHJhcCBhbmQgZW11bGF0ZSBiZWhhdmlvci4gT25seSBsMSBQVEVzIGFy
ZSBzdXBwb3J0ZWQgYmVjYXVzZSB0aGV5IGhhdmUgdGhlDQo+IGJpZ2dlc3QgcGVyZm9ybWFu
Y2UgaW1wYWN0Lg0KPiANCj4gU2lnbmVkLW9mZi1ieTogS2V2aW4gTGFtcGlzIDxrZXZpbi5s
YW1waXNAY2l0cml4LmNvbT4NCj4gLS0tDQo+ICAgeGVuL2FyY2gveDg2L21tLmMgICAgICAg
ICAgICB8IDI0ICsrKysrKysrKysrKysrKysrLS0tLS0tLQ0KPiAgIHhlbi9pbmNsdWRlL2h5
cGVyY2FsbC1kZWZzLmMgfCAgMiArKw0KPiAgIHhlbi9pbmNsdWRlL3B1YmxpYy94ZW4uaCAg
ICAgfCAgMSArDQo+ICAgMyBmaWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspLCA3IGRl
bGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS5jIGIveGVu
L2FyY2gveDg2L21tLmMNCj4gaW5kZXggMjc4Yjk5MmFjYTVjLi5lNWZkZmM2NjA4MWEgMTAw
NjQ0DQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9tbS5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9t
bS5jDQo+IEBAIC0zOTkzLDYgKzM5OTMsNyBAQCBzdGF0aWMgbG9uZyBfX2RvX21tdV91cGRh
dGUoDQo+ICAgICAgIHVuc2lnbmVkIGludCBjb3VudCwNCg0KLi4uDQoNCj4gICAjZW5kaWYg
LyogQ09ORklHX1BWICovDQo+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9oeXBlcmNhbGwt
ZGVmcy5jIGIveGVuL2luY2x1ZGUvaHlwZXJjYWxsLWRlZnMuYw0KPiBpbmRleCBhNjI1ZDYz
NGI2OTQuLjA1NTJlOTNhYjU2MCAxMDA2NDQNCj4gLS0tIGEveGVuL2luY2x1ZGUvaHlwZXJj
YWxsLWRlZnMuYw0KPiArKysgYi94ZW4vaW5jbHVkZS9oeXBlcmNhbGwtZGVmcy5jDQo+IEBA
IC0xNzQsNiArMTc0LDcgQEAgbXVsdGljYWxsKG11bHRpY2FsbF9lbnRyeV90ICpjYWxsX2xp
c3QsIHVuc2lnbmVkIGxvbmcgbnJfY2FsbHMpDQo+ICAgI2lmZGVmIENPTkZJR19QVg0KPiAg
IG1tdWV4dF9vcChtbXVleHRfb3BfdCAqdW9wcywgdW5zaWduZWQgaW50IGNvdW50LCB1bnNp
Z25lZCBpbnQgKnBkb25lLCB1bnNpZ25lZCBpbnQgZm9yZWlnbmRvbSkNCj4gICBtbXVfdXBk
YXRlKG1tdV91cGRhdGVfdCAqdXJlcXMsIHVuc2lnbmVkIGludCBjb3VudCwgdW5zaWduZWQg
aW50ICpwZG9uZSwgdW5zaWduZWQgaW50IGZvcmVpZ25kb20pDQo+ICtwdGVfZ2V0X2FuZF9j
bGVhcihtbXVfdXBkYXRlX3QgKnVyZXFzLCB1bnNpZ25lZCBpbnQgY291bnQsIHVuc2lnbmVk
IGludCAqcGRvbmUsIHVuc2lnbmVkIGludCBmb3JlaWduZG9tKQ0KPiAgIHN0YWNrX3N3aXRj
aCh1bnNpZ25lZCBsb25nIHNzLCB1bnNpZ25lZCBsb25nIGVzcCkNCj4gICBmcHVfdGFza3N3
aXRjaChpbnQgc2V0KQ0KPiAgIHNldF9kZWJ1Z3JlZyhpbnQgcmVnLCB1bnNpZ25lZCBsb25n
IHZhbHVlKQ0KPiBAQCAtMjMyLDYgKzIzMyw3IEBAIGNhbGxlcjogYXJtDQo+ICAgdGFibGU6
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwdjMyICAgICBwdjY0ICAgICBodm0zMiAg
ICBodm02NCAgICBhcm0NCj4gICBzZXRfdHJhcF90YWJsZSAgICAgICAgICAgICAgICAgICAg
IGNvbXBhdCAgIGRvICAgICAgIC0gICAgICAgIC0gICAgICAgIC0NCj4gICBtbXVfdXBkYXRl
ICAgICAgICAgICAgICAgICAgICAgICAgIGRvOjEgICAgIGRvOjEgICAgIC0gICAgICAgIC0g
ICAgICAgIC0NCj4gK3B0ZV9nZXRfYW5kX2NsZWFyICAgICAgICAgICAgICAgICAgZG86MSAg
ICAgZG86MSAgICAgLSAgICAgICAgLSAgICAgICAgLQ0KPiAgIHNldF9nZHQgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29tcGF0ICAgZG8gICAgICAgLSAgICAgICAgLSAgICAgICAg
LQ0KPiAgIHN0YWNrX3N3aXRjaCAgICAgICAgICAgICAgICAgICAgICAgZG86MiAgICAgZG86
MiAgICAgLSAgICAgICAgLSAgICAgICAgLQ0KPiAgIHNldF9jYWxsYmFja3MgICAgICAgICAg
ICAgICAgICAgICAgY29tcGF0ICAgZG8gICAgICAgLSAgICAgICAgLSAgICAgICAgLQ0KPiBk
aWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvcHVibGljL3hlbi5oIGIveGVuL2luY2x1ZGUvcHVi
bGljL3hlbi5oDQo+IGluZGV4IDIxNDliOGRkMzgwOC4uOWUyYmEwMTA3ZDNiIDEwMDY0NA0K
PiAtLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCj4gKysrIGIveGVuL2luY2x1ZGUv
cHVibGljL3hlbi5oDQo+IEBAIC0xMTgsNiArMTE4LDcgQEAgREVGSU5FX1hFTl9HVUVTVF9I
QU5ETEUoeGVuX3Vsb25nX3QpOw0KPiAgICNkZWZpbmUgX19IWVBFUlZJU09SX3hlbnBtdV9v
cCAgICAgICAgICAgIDQwDQo+ICAgI2RlZmluZSBfX0hZUEVSVklTT1JfZG1fb3AgICAgICAg
ICAgICAgICAgNDENCj4gICAjZGVmaW5lIF9fSFlQRVJWSVNPUl9oeXBmc19vcCAgICAgICAg
ICAgICA0Mg0KPiArI2RlZmluZSBfX0hZUEVSVklTT1JfcHRlX2dldF9hbmRfY2xlYXIgICAg
NDMNCj4gICANCg0KSSdtIG5vdCBzdXJlIF9fSFlQRVJWSVNPUl9wdGVfZ2V0X2FuZF9jbGVh
ciBpcyBhIGdyZWF0IG5hbWUsIGFzIEkgDQp1bmRlcnN0YW5kIGl0LCBpdCdzIG1vcmUgdGhh
dCBpdCdzIGRvaW5nIChtb3JlIGdlbmVyYWwpIENNUFhDSEcgDQpvcGVyYXRpb24gYW5kIHJl
dHVybmluZyB0aGUgb2xkIHZhbHVlIHRoYW4gc3RyaWN0bHkgZG9pbmcgYSANCmdldF9hbmRf
Y2xlYXIgb25lICh3aGljaCBpcyB0aGUgbWFpbiBpbnRlbnQgZm9yIExpbnV4KS4NCg0KSSBh
bHNvIHRoaW5rIHdlIGNhbiBmaW5kIGEgd2F5IHRvIGV4cGFuZCBIWVBFUlZJU09SX21tdV91
cGRhdGUgaW5zdGVhZCANCm9mIGludHJvZHVjaW5nIGEgbmV3IGh5cGVyY2FsbC4NCg0KSFlQ
RVJWSVNPUl9tbXVfdXBkYXRlIGFjdHVhbGx5IGhhcyBhIHVuZG9jdW1lbnRlZCAiYWN0dWFs
bHkgcmVzZXJ2ZWQgDQpiaXQiIChhdCBsZWFzdCwgZm9yIFBWMzItcGFlIGFuZCBQVjY0IGd1
ZXN0cykgd2hpY2ggY3VycmVudGx5IG11c3QgYmUgDQp6ZXJvIChvdGhlcndpc2UsIGh5cGVy
Y2FsbCBmYWlscyk7IGJ1dCB3ZSBjYW4gcmVwdXJwb3NlIGl0IHRvIGV4cGFuZCANCmF2YWls
YWJsZSBjb21tYW5kIGNvdW50IHRvIGFkZCAiY21weGNoZyBzZW1hbnRpY3MiIHZhcmlhbnRz
LiBUaGF0IHdvdWxkIA0KZ3JlYXRseSBzaW1wbGlmeSB0aGUgaW1wbGVtZW50YXRpb24gYXMg
d2Ugd29uJ3QgaGF2ZSB0byBpbnRyb2R1Y2UgYSBuZXcgDQpzZXBhcmF0ZSBoeXBlcmNhbGwg
anVzdCBmb3IgdGhpcy4NCihJIHdpbGwgc2VuZCBhIHBhdGNoIHJlZ2FyZGluZyB0aGlzIGlu
IHBhcnRpY3VsYXIpDQoNCi0tLQ0KDQpBc2lkZSB0aGF0LCBuZXcgZmVhdHVyZXMgd2FudHMg
dG8gYmUgZW51bWVyYXRlZCBzbyB0aGF0IHRoZSBrZXJuZWwga25vd3MgDQp0aGF0IGl0J3Mg
c3VwcG9ydGVkIGJlZm9yZSB0cnlpbmcgdG8gdXNlIGl0LiBXZSBjYW4gZXhwYW5kIGZlYXR1
cmVzLmggDQp3aXRoIGEgbmV3IGZsYWcgZm9yIHRoaXMuDQoNCj4gICAvKiBBcmNoaXRlY3R1
cmUtc3BlY2lmaWMgaHlwZXJjYWxsIGRlZmluaXRpb25zLiAqLw0KPiAgICNkZWZpbmUgX19I
WVBFUlZJU09SX2FyY2hfMCAgICAgICAgICAgICAgIDQ4DQoNClRlZGR5DQo=
--------------IFX40LrLar5N7Oq0qB0i5dsL
Content-Type: application/pgp-keys; name="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Disposition: attachment; filename="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7L
TBVHV/XOZw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJ
T4ny+OGntnJntUoRKRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJA
WicutjkkUgd28Bh6HV9EIumHtCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO
8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaTVqMdqul07o72m3eA2mf+LMu9a04FX/d4
wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/EoucejoZ5SH49ksmVAmKOLkt
OaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+SPhHar7TPKjFz0G3D
PNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89MXfQXZ3q
t1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWj
moACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNz
uyOVCskwfUZPla6Zpd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp
0x0HfuhcYfAYPR46XHTvjaJEv99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuR
OxdK8G+YHccJY8PvWSq2K2yiae2KGiAv1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50
wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhPeP3IdpfWc8cyRLXF06Rk46YM
YCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcTUwgnYlFRk2FLq0Qe
KEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9Egr/Wmu3
MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEM
AKiQiZa3yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ
3DbVf+en3/FvdVZg2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTm
etSG5/52AjtmPFtlXAk0NmLvfJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0
s3109sJeXT5ImVdphFs9cvyZyBT9t1PbRowv58EgV0zE4hbAeVkULAbxFV5b/ExT
jjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKbYu6NCfiHfEyB3Xyg9hfdrRgj
MRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ovXoK4jm+Py0FiUGUa
A6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/eVtR2Q1w
ZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWj
moACGwwACgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiV
oUiHYN5QwhnbZnsaJDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764Qxy
X6rld2f2RcWkDuBHun55ZWXjby8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk
/dS0XTOQi2wVUb17sW/+ybCEokdVacZGzOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fu
oGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+lOWSvdNHgoEkWR0RXBPQjnGm
LKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/OffO485NOTKwGOxyWb0
06cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR8ULR9nX0
LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
x9fhaZEsniw8/bYgC3igkk5YJiOa
=3DlUIA
-----END PGP PUBLIC KEY BLOCK-----

--------------IFX40LrLar5N7Oq0qB0i5dsL--

--------------Lj3c0HMPasC8mjY3UC1lTLsW--

--------------MxACY9YVHgqPACfBH3sKssh2
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmpxv00FAwAAAAAACgkQZg+p0QLLz9Ci
nQv/VvGFEbUTC5o7Bn7nY5jNoQgfXOeAu582//4PlPlCGmptOeSCXWRNBe148Yrbjsf89bQSYC9J
CuzJ2RSb2FFbRoHoTflR1biBJp22ptSnbi0mPMXKWODfGkNH6F8gmo045StniJr7TfVtu8PnIhXz
nZc0BUAmOG+Swq6/Udwl23VgG1qNXvCQRXQeWsyrEoNCTo8FM2LjTY5vEOaBU/iHkiFgHoblP7gS
wn4NUaqiK1aTZSxW4qhw29y8N2PVfXTKTbx+lfLZT2BRAqvKXXrkh54TI1HdzOmcRv11rhQPHzj4
p3qylNA3Fd7RwF61DAXDCux9J1MsAc8aYmkaEhxl1pgh2GiwOGFkHqbYmAJBqDVJXynTAutl4Djg
lGvwG75wVHGENZs2PfKJUmps55zIK2wCjs5hG7QU7EiUayHPyosiq3ozz6u2nCQZWvZJdaYukxjt
tidgAqN6/7yNqqREPTQKI+pVcIeEvNUV3pjrQiPbpHJQnER2d5jjp+K2vBET
=hjVR
-----END PGP SIGNATURE-----

--------------MxACY9YVHgqPACfBH3sKssh2--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 10:40:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 10:40:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382101.1625500 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrCZ2-0005Kc-St; Tue, 04 Aug 2026 10:40:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382101.1625500; Tue, 04 Aug 2026 10:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrCZ2-0005K6-Of; Tue, 04 Aug 2026 10:40:04 +0000
Received: by outflank-mailman (input) for mailman id 1382101;
 Tue, 04 Aug 2026 10:40:03 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <peterz@infradead.org>) id 1wrCYy-0004g3-Bt
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 10:40:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrCYx-000HMQ-AZ
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 12:39:59 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <peterz@infradead.org>)
 id 6a71c16e-5cb7-0a2a0a5109dd-0a2a450cd6bc-34
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 12:39:57 +0200
Received: from [90.155.92.199] (helo=desiato.infradead.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <peterz@infradead.org>)
 id 6a71c17c-f479-0a2a450c0019-5a9b5cc7e060-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 12:39:57 +0200
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]
 helo=noisy.programming.kicks-ass.net)
 by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux))
 id 1wrCYe-00000009nOq-2bzw; Tue, 04 Aug 2026 10:39:40 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
 id 5984030045A; Tue, 04 Aug 2026 12:39:38 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=desiato.20200630 header.d=infradead.org header.i="@infradead.org" header.h="In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=MsldYqnXOycsS4y2/7KD3GU//XDAu63pq55swDGd2xw=; b=LGA1lkkRQbVX1KW9YPvaAmrSjX
	iVDDDoXj/8hc/CzXkHA5ffJ8pRRD8pKaS0GgylshFZGV1Gt51cxqLuoVgYiuV2+ASvLqawoyP37O2
	ta0OHhxCiAPtEM7zdUElmcx4T8aqOOi6F0Y2q+lPdg8ionsZP3yHhQDAZ8wcCfqcYRJN5+hEbCGN8
	sfZ+ukTa3ier64oRKtJsK+zhxdviWmRFE/G+2nNfwhkLzN58M0Lmk13/TM+rpL52AWovHxCh20cap
	NFJT1Jbuiblfw8ziL76Tp7Ia//DA11YVN9uCIT6u7MxpE8hBCpXj1BKi8NhSEyEoqHzzQKtxscgCI
	IVoTVISw==;
Date: Tue, 4 Aug 2026 12:39:38 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Dmitry Ilvokhin <d@ilvokhin.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>, Thomas Gleixner <tglx@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>, Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
	kvm@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH 0/5] locking/qspinlock: Add contended_release tracepoint
Message-ID: <20260804103938.GH776954@noisy.programming.kicks-ass.net>
References: <cover.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1785778551.git.d@ilvokhin.com>
X-purgate-ID: tlsNG-d25034/1785839997-016C6A5B-6B0A1322/0/0
X-purgate-type: clean
X-purgate-size: 616

On Tue, Aug 04, 2026 at 07:15:40AM +0000, Dmitry Ilvokhin wrote:

> Patch 1 is Peter's draft from [1] and is missing his Signed-off-by.
> Peter, please add it if you are happy with the patch.
> 
> Dmitry Ilvokhin (4):
>   locking: Factor out queued_spin_release()
>   locking/qspinlock: Add contended_release tracepoint
>   tracing/lock: Use TRACE_EVENT_FN() for contended_release
>   x86/paravirt: Trace contended_release on unlock
> 
> Peter Zijlstra (1):
>   x86/paravirt: Use static_call() for the paravirt spinlock ops

Right, this all looks nice. Let me go queue this for the robots.

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 12:31:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 12:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382130.1625508 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrEI7-0005n1-Gy; Tue, 04 Aug 2026 12:30:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382130.1625508; Tue, 04 Aug 2026 12:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrEI7-0005mu-E6; Tue, 04 Aug 2026 12:30:43 +0000
Received: by outflank-mailman (input) for mailman id 1382130;
 Tue, 04 Aug 2026 12:30:42 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrEI6-0005mo-2o
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 12:30:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrEI5-000bEY-7M
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 14:30:41 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71db67-e002-0a2a0a5209dd-0a2a450ad7ea-44
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:30:40 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71db70-f2d2-0a2a450a0019-d1558035b139-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:30:40 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-49545ba3d4eso15440815e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 05:30:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd41d17f2sm47140603f8f.2.2026.08.04.05.30.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 05:30:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785846640; x=1786451440; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=tD8l2te+mjYfra2fISPdgTAYo6a1/PWVUQZcpuPMPqA=;
        b=GRMig7i9cvXEeMTERAjZw7i0Xy1md4hJ1cqzuCYxEEnjE4wazw2+FaHjVjaLNvrR3h
         x14i/RGxZ8tPrHLiy3/+0/byV5hnFq5qdO57gGcd1TwoudZ85vT9JTVaNCnH54XeGv1/
         KtZlmflXNZ/0ARDb5DY1KnyXa1BbRYhmp2WB6xbVL8G0hKuopvOqki19KdYTP3v1Y5dt
         P2PKyrFwjEaHX78El86fPFUDgm2DkB/I+T13P6/0Yz9IbIksQnv2Rhyv2cyteof+mqrL
         Dz8n8XaMzj3jQHe1hFG5Jt9LJ6aEhws8UhZXN5d7E4qn44naQhkZ/uKp3XUY2uSVaAv7
         rj6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785846640; x=1786451440;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=tD8l2te+mjYfra2fISPdgTAYo6a1/PWVUQZcpuPMPqA=;
        b=oryiNJbpmMIpKNgdyoBWNrJs94JC5yAq0S9XhoWaSUKZ9pvXGon46AMOL6qS75aII5
         zikzJ1ACnjunhTeajbgfwg2yZtzoApR3GH85IG4/pRab6xPFOodV+lptfaxgDbqRZa+n
         A+/XzE5QgaJKJlHZlzOE6apfqQwo3q95u65kUliTdJmsOCiVJcuaxJP8H2/iGE1VD0m1
         2azRRO14oEiy4BEv/NbI0A1VSgwVe9DuKUEZ+lWAhrIqevoeBUUNHAE3TdWWu0HX0aYV
         AmM+zGXk1yYcWx+dgu1qCZYDMctdnVBYv1U2fOVDh0r/LraaJmxdO+hTRrN8JisCLW6i
         WdNg==
X-Gm-Message-State: AOJu0YzhqzkVq+B5W0HeQsWdVIPRdJM45KHEgctoT7kj/dfGWRxSUXlo
	sFV/NLFgURpJMY561Opy/XuZCNPsScxOAAu+/JSvl/RGI9lx5R7pdU589OhrBwcBgTsu3jRl/19
	CZfr8lA==
X-Gm-Gg: AR+sD11JEqq1FKUgMOFjmczTvDUAuqtTu1lGRRB6D72JkdmXCOsr4RFgodn0bXXdipe
	HjT6xf5+tofz1GeW6lCFelsk48ZTl3tSfpo2zCrZX8D/vz8AAIVmhOyRD5JpaVI+6F5DyiGp7Az
	b0EsQl5OuTPJWv+k3+B5ZVl/9OCoPvjhO4f2FO80A+kk9UI3GBkl77Cbj+UqiaYyNB+qJVigHUX
	SfLnFaX+iO39mx17UV1Odrf3ZP1SrP6kL0tz+qBBFsP1Xrft01I3tbjTMQV9p9NM6Xrm5Em8wmq
	jHeVDT6zLOtlT2cWfFAnw+nEIHHt54XGqWw4OKOWfM8sf9RBEIuahIcBelrOQ/V13s6vFcFXiL5
	jcQO2Dj1rCCXdYukZfZeZT8w9qIteHvpXH3r4tUDNpRvUvphQLJUax6Fs9w+91BC0FkHr+syGaH
	P6iDb0430mN2b/79zMaO8MusCdktUKIWblOVq4jZBsuuneoaoI0MvXEPi+i87HiI861cq6CcHyh
	dwt0XNQ6LlNtvqqsP0MaM9LgwMca2upKSXwPSA2N4YeXzXZa5C+
X-Received: by 2002:a05:600c:6d03:b0:495:7a23:1eee with SMTP id 5b1f17b1804b1-4980c674f32mr243964825e9.12.1785846640329;
        Tue, 04 Aug 2026 05:30:40 -0700 (PDT)
Message-ID: <25cf9c88-7589-4a5d-994d-45f488a3e00b@suse.com>
Date: Tue, 4 Aug 2026 14:30:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] radix-tree: drop radix_tree_init_maxindex()
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1785846640-4A9D9CFC-F5BD7A87/0/0
X-purgate-type: clean
X-purgate-size: 2590

Radix trees are in principle usable as soon as memory allocation works.
(Radix trees with only index 0 populated are usable even earlier.) If only
there wasn't height_to_maxindex[], which is filled only by a pre-SMP
initcall. The benefit of this array is rather limited - the calculations
done by __maxindex() can as well be done by radix_tree_maxindex(); the
overhead isn't all this high.

Fixes: 21844b0e32e7 ("PCI multi-seg: introduce notion of PCI segments")
Fixes: 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux to gain RCU awareness")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Two Fixes: tags because the use of a pre-SMP initcall was clearly setting
up a trap for later code to fall into.

I know for certain that I've seen logs of Xen running on multi-segment
systems. I can't quite explain how that ended up working.

--- a/xen/common/radix-tree.c
+++ b/xen/common/radix-tree.c
@@ -32,12 +32,6 @@ struct radix_tree_path {
 #define RADIX_TREE_MAX_PATH (DIV_ROUND_UP(RADIX_TREE_INDEX_BITS, \
 					  RADIX_TREE_MAP_SHIFT))
 
-/*
- * The height_to_maxindex array needs to be one deeper than the maximum
- * path as height 0 holds only 1 entry.
- */
-static unsigned long height_to_maxindex[RADIX_TREE_MAX_PATH + 1] __read_mostly;
-
 static inline void *ptr_to_indirect(void *ptr)
 {
 	return (void *)((unsigned long)ptr | RADIX_TREE_INDIRECT_PTR);
@@ -80,7 +74,16 @@ static void radix_tree_node_free(struct
  */
 static inline unsigned long radix_tree_maxindex(unsigned int height)
 {
-	return height_to_maxindex[height];
+	unsigned int width = height * RADIX_TREE_MAP_SHIFT;
+	int shift = RADIX_TREE_INDEX_BITS - width;
+
+	if (shift < 0)
+		return ~0UL;
+
+	if (shift >= BITS_PER_LONG)
+		return 0UL;
+
+	return ~0UL >> shift;
 }
 
 /*
@@ -705,27 +708,3 @@ void radix_tree_init(struct radix_tree_r
 {
 	*root = (struct radix_tree_root)RADIX_TREE_INIT();
 }
-
-static __init unsigned long __maxindex(unsigned int height)
-{
-	unsigned int width = height * RADIX_TREE_MAP_SHIFT;
-	int shift = RADIX_TREE_INDEX_BITS - width;
-
-	if (shift < 0)
-		return ~0UL;
-	if (shift >= BITS_PER_LONG)
-		return 0UL;
-	return ~0UL >> shift;
-}
-
-static int __init cf_check radix_tree_init_maxindex(void)
-{
-	unsigned int i;
-
-	for (i = 0; i < ARRAY_SIZE(height_to_maxindex); i++)
-		height_to_maxindex[i] = __maxindex(i);
-
-	return 0;
-}
-/* pre-SMP just so it runs before 'normal' initcalls */
-presmp_initcall(radix_tree_init_maxindex);


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 12:59:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 12:59:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382142.1625518 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrEja-0001B0-Lx; Tue, 04 Aug 2026 12:59:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382142.1625518; Tue, 04 Aug 2026 12:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrEja-0001Ar-Ht; Tue, 04 Aug 2026 12:59:06 +0000
Received: by outflank-mailman (input) for mailman id 1382142;
 Tue, 04 Aug 2026 12:59:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrEjY-0001AU-Cn
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 12:59:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrEjX-00FGT8-3H
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 14:59:03 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a71e214-bab6-0a2a0a5309dd-0a2a45059f44-6
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:59:02 +0200
Received: from [52.101.43.66]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a71e215-4cb1-0a2a45050019-34652b422d9c-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:59:02 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DS3PR03MB989170.namprd03.prod.outlook.com (2603:10b6:8:39b::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Tue, 4 Aug
 2026 12:58:59 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Tue, 4 Aug 2026
 12:58:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Cht8kZ5bmVpp+Rqysj++EissTq5dQVrnbp7T9FRAPVdTp9YkLgvsP1W6E7R0cs4/JweBEhZsuMNGKVqyhubFF04ApOHFFVPLDy1eQjf/Hq3GynZKrVmFjDPkLmFrOAPBlRdLV9iPG2GiREctRN4B7ZHOK0snQV4g5IC5uE7BnPWqQcgXlT6iQ4H2pHmMbPeZ6RilreSUcUl9nCh1YK8Zuc6HMloPIQJ0jVNjoBB3H8f8M9B/bNO4uT6/UIzbl9ajfGrxcfqjBDClchFJkHmQMXQfI5AM3HeOAJ4kri1/mzuGa3Qiy03h0D9vMUhmKUzCwYGqI2GwiZqtQwxX5fPSqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xlZhJWvCveYBdustcfvWoJPNK1wtPBpfURVhKnBVXaw=;
 b=udiL+63e3Ubs7nTOy3WtTIBQdf8lIe7D9LKlMfzwWvRKiF9utrCdX36Je1yF0tcz4V9RxVU/ZCa/IwM/C9JmCqm6tUBcLvmz4JWU4HxkAyoy8izJfUj6JCcoaiy9Lytln60bHHEjDlRRGt8IjAoIYCoIfGF3J93cEWWN2Wz5KrAJ3DUAwkSoc5I8hzqklNyBKFVOTzWOhGRVuLb03ZPz+Nnszeo6O/EGvl+AZ4owJtPx1z+xiYRGyqsNkyU1HNI9BsBdOekk4GwFLDIQYhDBR4lDCx1B4yAaHLEl+2ZqgyrKQKa5Kr4ecNW04TLKiF+TBAeWokOlIEuIODXP7YqurQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xlZhJWvCveYBdustcfvWoJPNK1wtPBpfURVhKnBVXaw=;
 b=ilhfrZGW0Mjum8m4ZXBNqZoZjc6QdDIKQjRQ6ijPgIYbe1jbKJAz1bQ5Ay75YQUAKKzJfjDez44CLH1huGmffV0tPPxvUp8gz1owO8Epo/aqfUHwtkp7HvZknj9IM8Rv12xQQeGjhYyQx6k1c/X4EIBfGSjL1B0yJZ43O1MMD2w=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <c00db623-82bc-4d7f-924f-25f35f8e057e@citrix.com>
Date: Tue, 4 Aug 2026 13:58:55 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] radix-tree: drop radix_tree_init_maxindex()
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <25cf9c88-7589-4a5d-994d-45f488a3e00b@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <25cf9c88-7589-4a5d-994d-45f488a3e00b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0137.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2c4::15) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS3PR03MB989170:EE_
X-MS-Office365-Filtering-Correlation-Id: 3cd4c0ac-9034-4c97-f87b-08def2282648
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|10067099003|56012099006|22082099003|18002099003|11063799006;
X-Microsoft-Antispam-Message-Info:
	4K91DknpsGFmMfiNF/wGPEDlIw7taLyfZ0Jj9R2gkybEkkh6psadKfxla5iqMpy9AUIqtc97ow0sTpQOEmOqBCRlkV8KUDbRycD4FEZuYa/wDoh0X/OL8JC/epfPDyz4FbDDWPyMZ9qmyqo8h3NCF33ix3DhWtw+GBQ9jBl0s2VTkoyjM0i/MmKWiMaPyhu0VzAs8DQvSiMlKCrnols6IfBOG7SOqbXIAT84ctaUuPNAd3Epsos1aHgtxH1xf2dF1FcUhT3HzlxtIRbhRpedoYyXQ1OyntQPgd1x7RRsGFgEV3PRt/Yt0rU/OMaQcxnG44SrIcLTPmhcafEpIlucawGSZJgFVqZRmI5DYAzJT4U8MaCQuFC/wKo/NsnSalcZBNMmMlxpoIF0DvBxskANe6pKDNfUTrT2B3pof0fO2QZnUL+k4J2W28hT4kuS3wL++ahsT3mcniIn+89SbgYI/EN9pmtWuIiEizpPpgLNQNjexH1G3k115wCk9RsOUwFZ5E76QxmyVfcd0aK9Zi9GrO4nm3bhLshDyAOBCECDvoIAg10Sj2K7wh07dA5wE1zjgBpy0g3yeN7eKEnPwBxDj7Lh+ffakpGAn5W4i48q1FEFKbXcNSOPKG9ffV843EmPK2ylhWUhfgDdGlPdzD30KwfVAzqRB7RllDSxx1c/AqM=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(10067099003)(56012099006)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aGQ5dm5lUzdXOWJnT2RONzV0MFRwRXlmQytrb3NtY3dXU3pwd2VCcjNMYTVn?=
 =?utf-8?B?UFpVa0tGU09ZUGwxYndYNjBieXZWeXlad1hQdEdONGtiVVF1N0RnTXVwVTRs?=
 =?utf-8?B?akVjbjhLSkhiNlBzRG9CV3lkNFZUdmpWTE5FYVdXSmZLdFpUVitYL0lHMGNt?=
 =?utf-8?B?Y05qS0xoNUpjaldEb3dWbEQ3OGhiMzNDYks0YWtVMngyS2M3SG1kdXhyRmVh?=
 =?utf-8?B?dDZKSDVTYlJCOWFkTmlaT0syTXBIMHZJL1dzb0N6STR1RFVveS8vQnczZWFM?=
 =?utf-8?B?SHNQMmpiT2RyRXN0cFhmODMrSlh1VzJEM2FUVjRET01OaGt1UnF2aSswbzM0?=
 =?utf-8?B?WU9WS3d3YmNLbDF1ekVGYWExWCtXa1lmdDE3Z1l4d0ZDYUl3L0hvQjhQaUNr?=
 =?utf-8?B?ZGhGejRZTDFBaDZ5QzJ0d016QkpsWEhTSmFvVFVRT1JPSzU4WlFjbGt5amMw?=
 =?utf-8?B?aU4xWCttSkJKZ01OcjZiV3drWkhBM3hsMFJxVmdRVVJkdEpQUjJUeXFOS2h4?=
 =?utf-8?B?bStoVCtTcEF5YUxDWXJ5djdGY0poRlorT0J5d0d2Ui9oTlQyc1dDMmlibmkz?=
 =?utf-8?B?ZTVRMFA5b2VVRC9BZTJTMWlvMTAyMHhVb0g3b2p1WXRVZzZvL1hRdWtqaysw?=
 =?utf-8?B?N0F4S1p2RHhZbUdmUlZVVm1tOEN3TnN5akMweUU3bTF3cjJUcW1LSmljbmho?=
 =?utf-8?B?bjlCaXdocE8xeWlPR3hlOGxpdlFWeldzSzBZZEVLR2FLdGJJQ2VQb3FvVWE1?=
 =?utf-8?B?b3B2OVlsVVJOTnZ0MGQvYWtBaDUrRVllbkNDS2hVY1JjVVpLTmVrN1YySCtw?=
 =?utf-8?B?cXFGSlI2QnFXMGJxNE9QS2xVTDNLTHQvWGd1WjlDL2JUS2Z4RGdRbUJRL2c2?=
 =?utf-8?B?OWdBU0V4N0ZmT09XMlZLeTJzNmI1ZnBhVXo5M3p2SE1tb29DSVR2R2JFRUZw?=
 =?utf-8?B?WmJvaC9laE95aHc0cE8vdkpqcG1jOUx2anFySDk1MTVaNVNLak5vTUhrZ2VL?=
 =?utf-8?B?OVQ3c3hXdk1DRGRBcWZyK1pSbzRzQjV3b3R6QTlEYkFXVlROeTZFRE9JUE15?=
 =?utf-8?B?S3hOUFd2bk44VmRQNTNKQmVlNTZhcm9KQktycEMxdzdWWGd6RG5WU21xMnpL?=
 =?utf-8?B?eU5xZDFpVmZ1M0t5bU50YWRVQTZmY0JIcGc2TE9Uaml4QjVWVExDM1daUE81?=
 =?utf-8?B?MEFMc016NURReGFwWTljN1NLcitDcFJtcHo5Mnh2RStxVnV5aVpLNW5QOXNn?=
 =?utf-8?B?bjdSVmIrZkpCdkhJUHVGQUtPK0E2ejRBSnpVL0Q5SUVMYzN6cW81aG9oR3NL?=
 =?utf-8?B?b0FseVhGTFVuSERWamNMdWx6eVRPWW0zbG1KYXplVEorVHEwUGpCUmJ6N1NJ?=
 =?utf-8?B?QmdzQld1U1NoRHNUa0VRSjlzcWVzMjlET01nc2lkcXArTk9aR3M0Ynowb0FP?=
 =?utf-8?B?dDlzcTJLU3pQdHVraG82bXpGeEtuTVBFNXZFU3V6MGNFNmVCTmZzYnVZOU8y?=
 =?utf-8?B?RXlzUDRSOE9JK1F5aW1STkRsc0lEem43T1p1L3JnMTBDdkp0bEhsUVBSMmFW?=
 =?utf-8?B?akFtSjAzM2l5Yk4xV0FTeWlmNXk5aHJuWTJyaEZJL3FiazZJT2kwZEI2ZTRt?=
 =?utf-8?B?NWxqUTJLTkJXdCthMEwweGRRYmlNVjJ3YVIvY3RsbHAvYTdtNHVrTTBkWFUy?=
 =?utf-8?B?YzNrenQ0WmVST1B0c20vcExicEtJYmt2QmZDZ1RJUVZBZUwzNnFxbHpuSEdP?=
 =?utf-8?B?dU9tc3I0dUpReHZZeU0zSWJnblBnNkFCbU1JOFZLdDJUMGw5U3VsYWtlYWsy?=
 =?utf-8?B?TW9iQ1pONDJYelExQk43N1NtOTdnTXNISXlUeHhsV0dDa3c0VUJuRHZ6ZFdM?=
 =?utf-8?B?Y1dCVm5La1dIZmtPcnBXdjJoMGE5U1dIQXdVYUc2WEltS0VJcVJoeStwNjFj?=
 =?utf-8?B?SnBLcm5VRCtrNE1EdDhLWGV1Z3d3YzAyZFJ6eDQrbWZQYUJUd010dWFwMFpO?=
 =?utf-8?B?WjNScDZFTWUrQ2tUa3hzWXlKUDlvK2xPYjkyNTZiZ1lPOVpFTFdXRGwyOWwz?=
 =?utf-8?B?QUZiSUtVbTROUi9pekY0MUt3L0tBTFcrWDNMWllHUUU3ZElQb3JUaXVQY0JD?=
 =?utf-8?B?Wm53MU5XODdjRlJDMnNGR3BXQXBDMHRLYXYydjZSYVNWVVVUVytzdGcyejVQ?=
 =?utf-8?B?Wmk0cGh5YkJaU0o5K0JmdFNUTHUzUXd6enlUb01ocVp5T3JhSzAzSkYzV3Fv?=
 =?utf-8?B?eFF4Nk9zNEE0QnJwT1RuMGRsbzFCZHVzeEVqQzd3eE1DTXF6RXFMRXdqSk5Z?=
 =?utf-8?B?M0haN3NWSkFjclBhZ1lXZi9iOTE4L2ZSQ1FndVkwd2RKazY2T3NGMUtGdXhQ?=
 =?utf-8?Q?wsVzOesj6cSlTu2g=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3cd4c0ac-9034-4c97-f87b-08def2282648
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 12:58:58.9147
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bOi4JPLFHhqtp1O8gmwwcw1scPGQzz5EinEF3rb6E2xRvmevhcBM0AOL5MYM/YecbYLR2/8yhugKt1VTxQjUB1dfxB/hug0wir//AUXzztY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS3PR03MB989170
X-purgate-ID: tlsNG-c201ff/1785848342-F66B52A1-4DD798D3/0/0
X-purgate-type: clean
X-purgate-size: 3046

On 04/08/2026 1:30 pm, Jan Beulich wrote:
> Radix trees are in principle usable as soon as memory allocation works.
> (Radix trees with only index 0 populated are usable even earlier.) If only
> there wasn't height_to_maxindex[], which is filled only by a pre-SMP
> initcall. The benefit of this array is rather limited - the calculations
> done by __maxindex() can as well be done by radix_tree_maxindex(); the
> overhead isn't all this high.

It's quite possibly lower overhead.  Some simple integer arithmetic vs a
memory read.

I think it's worth noting that this was found by UBSAN on a
multi-segment system:

(XEN) UBSAN: Undefined behaviour in common/radix-tree.c:83:27
(XEN) index 12 is out of range for type 'long unsigned int [12]'
...
(XEN) Xen call trace:
(XEN)    [<ffff82d040323f9c>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd5
(XEN)    [<ffff82d040324d91>] F __ubsan_handle_out_of_bounds+0x9d/0xd4
(XEN)    [<ffff82d04029265a>] F radix_tree_insert+0x24d/0x570
(XEN)    [<ffff82d04037ac3e>] F drivers/passthrough/pci.c#alloc_pseg+0xc4/0x165
(XEN)    [<ffff82d040a3b526>] F pci_add_segment+0xc/0x1b
(XEN)    [<ffff82d040a5ad1b>] F acpi_parse_mcfg+0x29b/0x344
(XEN)    [<ffff82d040a3f612>] F acpi_table_parse+0x5d/0x92
(XEN)    [<ffff82d040a5bf55>] F acpi_mmcfg_init+0x3a2/0x71d
(XEN)    [<ffff82d040a71ba6>] F pci_setup+0x17/0x29
(XEN)    [<ffff82d040a784d0>] F __start_xen+0x394c/0x4ed8
(XEN)    [<ffff82d040423057>] F __high_start+0xb7/0xb8



>
> Fixes: 21844b0e32e7 ("PCI multi-seg: introduce notion of PCI segments")
> Fixes: 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux to gain RCU awareness")
> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

All the UBSAN violations are gone.

> ---
> Two Fixes: tags because the use of a pre-SMP initcall was clearly setting
> up a trap for later code to fall into.
>
> I know for certain that I've seen logs of Xen running on multi-segment
> systems. I can't quite explain how that ended up working.

At a guess, we limp along with only segment 0 until dom0 reports the
other segments.

This particular system is set up for GPU testing and the GPU is in
segment 1, so something was working well enough for that to function.


FWIW, there are still issues on this box, even after the fix:

(XEN) setup 0000:fe:00.0 for d0 failed (-19)
(XEN) setup 0000:fe:00.1 for d0 failed (-19)
...
(XEN) setup 0000:ff:19.0 for d0 failed (-19)
(XEN) setup 0000:ff:1a.0 for d0 failed (-19)
(XEN) setup 0001:fe:00.0 for d0 failed (-19)
(XEN) setup 0001:fe:00.1 for d0 failed (-19)
...
(XEN) setup 0001:ff:19.0 for d0 failed (-19)
(XEN) setup 0001:ff:1a.0 for d0 failed (-19)

These are the PCI devices for aspects of the uncore, mostly performance
counters it seems.  Despite the lack of information, I think the
complaint is about setting up the IOMMU context for them.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 13:26:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 13:26:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382155.1625526 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrF9o-0005lo-M0; Tue, 04 Aug 2026 13:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382155.1625526; Tue, 04 Aug 2026 13:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrF9o-0005lg-IU; Tue, 04 Aug 2026 13:26:12 +0000
Received: by outflank-mailman (input) for mailman id 1382155;
 Tue, 04 Aug 2026 13:26:11 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcus.granado@citrix.com>) id 1wrF9n-0005lZ-GX
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 13:26:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrF9j-00EwWZ-LD
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:26:07 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcus.granado@citrix.com>)
 id 6a71e865-bab6-0a2a0a5309dd-0a2a45049eec-22
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:26:07 +0200
Received: from [52.101.193.39]
 (helo=CH1PR05CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcus.granado@citrix.com>)
 id 6a71e869-b57f-0a2a45040019-3465c1270510-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:26:04 +0200
Received: from LV4PR03MB8234.namprd03.prod.outlook.com (2603:10b6:408:2e3::8)
 by CH4PR03MB7650.namprd03.prod.outlook.com (2603:10b6:610:235::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Tue, 4 Aug
 2026 13:25:59 +0000
Received: from LV4PR03MB8234.namprd03.prod.outlook.com
 ([fe80::264a:2e82:2064:7fab]) by LV4PR03MB8234.namprd03.prod.outlook.com
 ([fe80::264a:2e82:2064:7fab%4]) with mapi id 15.21.0292.015; Tue, 4 Aug 2026
 13:25:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qQce9i+beoT6Sz0IVgC6nTOtXRH08LaAU6TN99Zp6jSivd5TcGZuw1aCNQ3ZMJ192e4XemDu74Wp6lk4olG6oWacohmcu6VtnqM7tOpxCJ80ElC1XsBhDCaAinyB6LnwFGVQWrSXhKz1rvbQlCQ7z1bxd/YZhXUwXdxE7EY9PQjI4CjJHPeL+nkFhFObp4c70XN4wMM7qssl1uxa+KGrbDyjSYQXTso99D5c3bTP0KHlGS57HY8PjlvvwxyEjmksUrWiYXC/zwAeAujGIaALaf3+3ynlEm/SrSAW+Odpqb8jJCG3+9or99waMX6aItkZBsi+afcD6T3vf2aJYmmkEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oiW6mLdAAoCz8vBWUjYfWULIRb0u3XW6lB+9qHUuNCQ=;
 b=lEbH41CRA+BuhA+EtS0EWIDpngY8wWksYmrfQxy2D6ZSULGwSYSypcS4t2qvj9WRsj2T4jh5pmsKViTc6L9FC1NEy1ANuM2QxL6Et9+sCTiCJhGFbx28khx1L4ScNO68ISi2B4YmfKIFT6qXKr3VmBx6Zm9Z8BOYEW9LjDqheEF0rjjsuUaaMXy21nqwvIUts+U3BnuXUpJvRaswI87xu5O8B3iWWH1M88KjqOP5d9BQlhhEoN0/HSif5NVujinlWntSoL9DUAR6geyYwzQNHs/8xlyY5lNBOV9KFhcVCEbxGKB5ri3mWvRSfBNoGex9QYkOZbWJAVcsNFq9hPLAng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=oiW6mLdAAoCz8vBWUjYfWULIRb0u3XW6lB+9qHUuNCQ=;
 b=eq4TI9tggU+2MqOlJgRn6vK/6U5s8Y8AJaRp5sOomWJLwuNn1Q7az+7KxT78cJ0EcvLHvy8vLsjJHDOwbJDREqVRfAyc061p01daPboeG6zbRe/p1zslY2PRA/kUg9eXKeECWotTF4pwjXF7z1G9di/wpbOEkLsRxVQkBvNbQiI=
From: Marcus Granado <marcus.granado@citrix.com>
To: Frediano Ziglio <freddy77@gmail.com>, Teddy Astie
	<teddy.astie@vates.tech>, Andrew Cooper <andrew.cooper@citrix.com>, Roger Pau
 Monne <roger.pau@citrix.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Anthony
 PERARD <anthony.perard@vates.tech>,
	=?iso-8859-1?Q?Marek_Marczykowski-G=F3recki?=
	<marmarek@invisiblethingslab.com>
Subject: Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
Thread-Topic: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
Thread-Index:
 AQHdGF9mhIhyvqGSRUyPVZ4Z3HHB7rZ3oucAgAJQsgCAAB5PgIAKMo6AgAhhrfGAAQyTAIAAA40AgAA+3Ks=
Date: Tue, 4 Aug 2026 13:25:59 +0000
Message-ID:
 <LV4PR03MB823492BF26528F6FAC11CC3AEDD42@LV4PR03MB8234.namprd03.prod.outlook.com>
References: <20260720154832.1907401-1-marcus.granado@citrix.com>
 <20260720154832.1907401-2-marcus.granado@citrix.com>
 <1784622046.8631fc262581453bbf619ec5b2062170.19f83c35cd4000edb5@vates.tech>
 <CAHt6W4erBfB+H_0d+2rQ0apz9Jt6ex+WVjEjyPm6EApoHVJgmg@mail.gmail.com>
 <1784755834.8631fc262581453bbf619ec5b2062170.19f8bbccffd000edb5@vates.tech>
 <CAHt6W4cWLfSVoCSgr-YsQb1Mv=VZek0CakTBwK7tx_n9RkeiUg@mail.gmail.com>
 <LV4PR03MB8234F0C54B63FABE4D749FBBEDD52@LV4PR03MB8234.namprd03.prod.outlook.com>
 <1785834903.8631fc262581453bbf619ec5b2062170.19fcc0e18f8000e099@vates.tech>
 <CAHt6W4dHih5z1LpRpdRiU_CC0dCQTF=324=KM6QJbUHS1xQ1GQ@mail.gmail.com>
In-Reply-To:
 <CAHt6W4dHih5z1LpRpdRiU_CC0dCQTF=324=KM6QJbUHS1xQ1GQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV4PR03MB8234:EE_|CH4PR03MB7650:EE_
x-ms-office365-filtering-correlation-id: 14ed79d3-2558-43c8-7ca9-08def22bec68
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|10070799003|23010399003|366016|376014|1800799024|38070700021|56012099006|6133799003|10067099003|4143699003|11063799006|5023799004|22082099003|18002099003;
x-microsoft-antispam-message-info:
 9cMZ06eFEkIr4hMVI+ljPo08HkzJ0tUkZK4Ake+Zwb7GA7pcDF/fBk1Srj6P7Sq6KP4LqnJVtuoOAd5y9yTgutE4y2uuDRM0Z1hrVp/cjOB6GIDIW2ENqAhT8+7zykPj0mcUn8ybVKPXI4g2FRPTIzwYMpVRvn6nrssd2I2oxuGdXcU2c7n194ZH6utRXUvDt40HpeAlbhMaQ1ATrffpJsyMrezmjW37HQyDoPaDqx5Gsdvu3z90wL004FZ+67moAUrhi3PSlevtClUdyg68kYSyHN0gOqRTuLdQb9vOEBIYEUndAGo+tJm1dqO5vy0EWUGTvyzlMXLKq815EH5NHHjZW/bJbKT1v5PUtzMuTEozYeXelzBg0f86/q1jFzRNSGQLS4Rnfiofm3c+Jj0oKTBk1lMGmNIgCUcz0J5iQMHtsw6JJ0PLxlBks35bnHAj+rL8oAqD5CxZgDaSYoYBlINcgt9fQbFzIxDfRJJ4scfBVJr9rWnDZgU6d1FNJqaZlW+KiGd77dgFErImKMHShTnVJJUQDfR+O7XlLOAzniU+GI5JbzQttXo+XaSjEV6yCVtiCW9m95+oEOAEthFGnYHX8HOninNBi1muGAS94YWuygrS9atUssa5tXaasqh936XGmTI+iorDORCb60s+1voOz1c9NtUzxw/KAD5GSFrsOijzkw6Iax/zwxU7H4+6v8WIeNqdleea0q6Qq0Ow0K+SuBUoLifV5Pvun5Weyuc=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV4PR03MB8234.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(23010399003)(366016)(376014)(1800799024)(38070700021)(56012099006)(6133799003)(10067099003)(4143699003)(11063799006)(5023799004)(22082099003)(18002099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?rFqBhGpF3XwwZDp4wqSseYm0EKVdGrmgXONwwYb3EK4YGGE/uR64qoDJfl?=
 =?iso-8859-1?Q?4SaceeTVBGKrcrfbdPP5fi2yrKZiaSmkAd0wVWnscCMHym6nyhEiP4neME?=
 =?iso-8859-1?Q?v5t3SXQVPLMqJE+aF361I6xhfqZYk26z9RoTCoIqCIvq/YwYOg0yeBRe/P?=
 =?iso-8859-1?Q?4SOKET1cYkZDnGpMqqpCCWj2bG59L44EB+WCOWKysbHuVrZl33C1P3FhHT?=
 =?iso-8859-1?Q?OJLBUxqHyjafVFgBxOu+whBR3jM+p0cwMIfpMOs1oIn+Tlhb1Gb0LSc5T6?=
 =?iso-8859-1?Q?l5Wcg4Bx0drSZl4p5U+YFjmhu3exBJaM5MlTmQhgUgzhNqD2296Q75QU88?=
 =?iso-8859-1?Q?TD9uetCuDscqQksFPF4certwjS/UAfdfxlbHVA7KG4BkBpc+3QXP4NyrKu?=
 =?iso-8859-1?Q?fvMxxgjvHGVlYjgen/XhEDzZo91kwPkHogyw0CHOCo876gU92Q27GCzGpI?=
 =?iso-8859-1?Q?2HHqDcsnKtPmH/FMdgmPYjbhpq2u3CcM4gFTCwBtoEijTmxQDAcYKjv1ww?=
 =?iso-8859-1?Q?wtHv33ZrzzuKJ5JoglNNe/NxMkB+utFTcvz5Z61b0/HyFehH/GYy6mdIQB?=
 =?iso-8859-1?Q?zm8xLQ5ubYhuqo93qR53bnaxl7282DppHA6NpKVqGK8eCEfNntkOBicyLY?=
 =?iso-8859-1?Q?Oi0owwZNv0bRUsU9i8Np+VkXU4F1eG73MiQn3FqXyogt5C8atc9L1upTVJ?=
 =?iso-8859-1?Q?bGGJeBqsgu9OYWImTEaKU8Jlk+Im6IDj5ywqLEcVDm+QqXhSBTNmmU3TwF?=
 =?iso-8859-1?Q?RUM+md6Yg09/v2//goa4IjKXkh+IMMgMVtoCrtQB1z103rKUSDZyv3Vi5M?=
 =?iso-8859-1?Q?21z4zqMgVlj5NVylt6crFmY+j5MLGOzjZz5eI6xa8B3NZnO7EgbZvgjYxt?=
 =?iso-8859-1?Q?ISoRI3mO66x6IvY5zEIA2lnL4u4gRdMa0Vk7xnjx2X1SeMYHnO2nv25oI/?=
 =?iso-8859-1?Q?tiwD4oMb9Wgbgf9oxgd6W9nZ3sA8HRo7Bi8aAjkYQ92V+lyWKUeMyFOKXf?=
 =?iso-8859-1?Q?bWPZd6aSfaDHSvi4qLW+VuqIIlbbqOvosIJqKf4fkCNFHSm2XINb0+n8pm?=
 =?iso-8859-1?Q?o8N5W+2BL/pBUegKhvRYmearsUzjrDeg61LoFRLNaRlMC9yaxYjxhN+lQi?=
 =?iso-8859-1?Q?psSqLmwQYOWAvh29DC6uxKJTHcWQrzdG/xMj9pM+slQTwWFLHQvz8it3Mv?=
 =?iso-8859-1?Q?9ZMeosQLF7GOSvA8QHEGzbab3cdqrH2ZZYO0Dehi9/3rRINu+qNy261nxr?=
 =?iso-8859-1?Q?oLve5gKY5nFNwQ6N8Rzg3A7SkZECly9EI4R9rezvnuaMIxscXhK7hnm2BI?=
 =?iso-8859-1?Q?pdmW4Aht5241TSozsvf8o/aSBsSvxE+IPOXbRzizhaYX2PDtyWfVgeBXVd?=
 =?iso-8859-1?Q?JS/dDs+OmxFQ4w3ptlaLrjiNZ2vPojYQrNlkDenGsrfW1VRSvULJvwnbkJ?=
 =?iso-8859-1?Q?2sKA+O3EkTcoR0PLlcJ2NdBJFtpfOQwAHGzwWvnUVsVrgF7kunAlmM2Rit?=
 =?iso-8859-1?Q?SIuloSFe3RaWbwOo09eW7yO0Sy38E10Z9EJ+SB8gtxEL2Wk2Uf1AKadxbm?=
 =?iso-8859-1?Q?X44NT2RL7CqgcV9QuU2r5p+yavW2ZUMVmhdt51NWGdURalxefJG+M7r7yA?=
 =?iso-8859-1?Q?ejN0ykZe1+SgrlHQ4bmfcn1oWG8cEREOLlHLNMsZYgty/tPc1k62I3TH36?=
 =?iso-8859-1?Q?ShEtQ3dYxFBxLLqI4MzFtu0rdQwZ/FaUXDjLukMNSLHv+TwiUW1IF9zUK/?=
 =?iso-8859-1?Q?y9K9Q/AOCyY1ENDH70xLUZWgt/fANbDKjwdjOfPKkOI7BeQifqUJ9LCMLh?=
 =?iso-8859-1?Q?I8PFF+2FTzOIegPpbjSssyPbms939mjIDF9Vxd0EmKbnzjz5knt+eoaNnv?=
 =?iso-8859-1?Q?Zb?=
x-ms-exchange-antispam-messagedata-1: MdL7AZZ066Q20g==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV4PR03MB8234.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14ed79d3-2558-43c8-7ca9-08def22bec68
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2026 13:25:59.6436
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ggaNSiIXgARp+KVX8hqCBhDHuB6FKUsYRxTrVaaFPv9DeNUqG67+0qErW9EdCJzM92mWya6Lt5JTQY/Wim4e86QJlh8bfSqGTr832a9rdMA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7650
X-purgate-ID: tlsNG-ebf023/1785849964-51ED6B50-92D0355F/0/0
X-purgate-type: clean
X-purgate-size: 6230

On Tue, 4 Aug 2026 at 10:27, Frediano Ziglio <freddy77@gmail.com> wrote:=0A=
> On Tue, 4 Aug 2026 at 10:15, Teddy Astie <teddy.astie@vates.tech> wrote:=
=0A=
>>=0A=
>> Le 03/08/2026 =E0 19:23, Marcus Granado a =E9crit :=0A=
>>> simplify to reusing PAGE_DATA and spending one octet of its reserved wo=
rd=0A=
>>> as follows:=0A=
>>>=0A=
>>>=0A=
>>>       0     1     2     3     4     5     6     7 octet=0A=
>>>      +-----------------------+-----+-------------------+=0A=
>>>      | count (C)             | comp| (reserved)        |=0A=
>>>      +-----------------------+-----+-------------------+=0A=
>>>      | pfn[0]                                          |=0A=
>>>      +-------------------------------------------------+=0A=
>>>      ...=0A=
>>>      +-------------------------------------------------+=0A=
>>>      | pfn[C-1]                                        |=0A=
>>>      +-------------------------------------------------+=0A=
>>>      | page_data[0..N-1] if comp =3D=3D 0                  |=0A=
>>>      | or page_cdata     if comp !=3D 0                  |=0A=
>>>      +-------------------------------------------------+=0A=
>>>=0A=
>>> with two new entries in the field table:=0A=
>>>=0A=
>>> comp        Compression algorithm applied to the page contents. 0=0A=
>>>              means none, and the record is exactly as it is today. 1=0A=
>>>              means LZ4 block format. Other values are reserved for=0A=
>>>              other future formats like ZSTD etc. A comp !=3D 0 can only=
=0A=
>>>              be emitted if 0 < len(page_cdata) < N * page_size. An=0A=
>>>              unknown comp must cause the receiver to fail with a=0A=
>>>              "Compression algorithm <value> not handled" error.=0A=
>>>=0A=
>>> page_cdata  Present instead of page_data when comp is non-zero. A=0A=
>>>              single compressed object holding the concatenation of the=
=0A=
>>>              N page_data entries. The receiver must verify that=0A=
>>>              0 < count <=3D MAX_BATCH_SIZE.=0A=
>>>=0A=
>>>=0A=
>>> Teddy, I hope this format covers your points: it's no longer LZ4 specif=
ic,=0A=
>>> the inline clen inconsistency in libxenguest record disappears, it's on=
e=0A=
>>> block over an immutable copy of the batch instead of one per page, the=
=0A=
>>> decompressed size is known up front, and the allocation derived from co=
unt=0A=
>>> is bounded on the receiver.=0A=
>>>=0A=
>>=0A=
>> Looks good to me.=0A=
>>=0A=
>>> On Wed, 22 Jul 2026 at 20:42, Frediano Ziglio <freddy77@gmail.com> wrot=
e:=0A=
>>>> Don't we need to bump the version number while we add a new mandatory=
=0A=
>>>> record?=0A=
>>>=0A=
>>> I believe we may avoid having to do a version bump if we adopt the prop=
erty=0A=
>>> that 0 < len(page_cdata) < N * page_size when comp !=3D 0, as in this c=
ase=0A=
>>> the compressed data sent to an old receiver would fail in handle_page_d=
ata()=0A=
>>> with "PAGE_DATA record wrong size". Bumping the version would make=0A=
>>> uncompressed migrations fail if they are sent to old receivers that als=
o=0A=
>>> understand uncompressed migration, so avoiding if possible would be goo=
d.=0A=
>>> The spec says migration tools "shall always save images using version V=
",=0A=
>>> so it doesn't seem like we could bump the version only when compression=
 is=0A=
>>> on.=0A=
=0A=
=0A=
Thanks. I will take the discussion so far as the record format above being=
=0A=
agreed, so the only open point is how it is carried.=0A=
=0A=
>> The specification says=0A=
>>=0A=
>>  > Padding and reserved fields are set to zero on save and must be=0A=
>> ignored during restore.=0A=
>>=0A=
>> Which is not really going to help if we add a new field that matters on=
=0A=
>> how the content is organized.=0A=
=0A=
Agreed that the sentence as it stands does not cover it, but I think that=
=0A=
is a documentation problem rather than a format problem: once the octet is=
=0A=
given a meaning by the specification it is no longer a reserved field, so=
=0A=
the rule stops applying to it. The v2 spec patch would define comp in the=
=0A=
PAGE_DATA field table alongside count and pfn, and leave the remaining=0A=
three octets reserved and required to be zero.=0A=
=0A=
To make the compatibility argument rest on the specification rather than on=
=0A=
one implementation, I would also add these rules to it in the same patch:=
=0A=
=0A=
* a saver may only emit comp !=3D 0 when 0 < len(page_cdata) < N * page_siz=
e=0A=
* a restoring side must reject a PAGE_DATA record whose length is not=0A=
  exactly sizeof(hdr) + C * 8 + N * page_size when comp =3D=3D 0=0A=
* a restoring side must reject a record with count > MAX_BATCH_SIZE, and=0A=
  must fail on a comp value it does not implement=0A=
=0A=
The second is what handle_page_data() already does today, so writing it=0A=
down in the specification is easy and turns the PAGE_DATA argument below=0A=
into a guarantee rather than an observation about the current code.=0A=
=0A=
> Yes, there's no check for "_res1" being 0, however there's this check:=0A=
>    if ( rec->length !=3D (sizeof(*pages) +  ...=0A=
> so, as long as we require that the compressed data is less than the=0A=
> uncompressed one (we should) it's fine.=0A=
=0A=
> Not strong but if I could vote I would just use part of "_res1" as=0A=
> proposed.=0A=
=0A=
I would vote the same way. To be explicit about it: an old receiver=0A=
will reject a compressed record through the length check rather than=0A=
through the mandatory record rule, so the diagnostic is "PAGE_DATA record=
=0A=
wrong size" rather than one naming the unsupported compression. I think=0A=
that is an acceptable price for not adding a record type, given the strict=
=0A=
inequality above makes the rejection guaranteed rather than incidental.=0A=
=0A=
Andrew, Roger, the one open point is whether to carry this in a PAGE_DATA=
=0A=
reserved octet or in a separate PAGE_DATA_COMPRESSED mandatory record.=0A=
Unless a maintainer prefers the latter, I will implement v2 with the comp=
=0A=
octet in PAGE_DATA and the three rules above.=0A=
=0A=
Marcus=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 13:38:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 13:38:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382167.1625535 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFLp-0008GG-RU; Tue, 04 Aug 2026 13:38:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382167.1625535; Tue, 04 Aug 2026 13:38:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFLp-0008G9-Ny; Tue, 04 Aug 2026 13:38:37 +0000
Received: by outflank-mailman (input) for mailman id 1382167;
 Tue, 04 Aug 2026 13:38:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Christian.Koenig@amd.com>) id 1wrFLn-0008G3-W7
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 13:38:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrFLm-00FOA0-U1
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:38:35 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Christian.Koenig@amd.com>)
 id 6a71eb54-2eae-0a2a0a5409dd-0a2a450ac004-10
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:38:34 +0200
Received: from [52.101.85.5]
 (helo=BYAPR05CU005.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Christian.Koenig@amd.com>)
 id 6a71eb58-f2d2-0a2a450a0019-346555052edd-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:38:33 +0200
Received: from PH7PR12MB5685.namprd12.prod.outlook.com (2603:10b6:510:13c::22)
 by CH2PR12MB4136.namprd12.prod.outlook.com (2603:10b6:610:a4::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Tue, 4 Aug
 2026 13:38:24 +0000
Received: from PH7PR12MB5685.namprd12.prod.outlook.com
 ([fe80::ce69:cfae:774d:a65c]) by PH7PR12MB5685.namprd12.prod.outlook.com
 ([fe80::ce69:cfae:774d:a65c%5]) with mapi id 15.21.0270.017; Tue, 4 Aug 2026
 13:38:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=r96iwnW/WdZ0/lPjKFvwKw53/13qLfA16D1uNcB2DA0clOWwAeWTPfFnfjrCWtAawlPifegi/Gk/O2ayEk1eejGP05KurD/x0Qzl/qgbxapFcQLJSuVd+F4UgeWYGT5buh1V9peObL1naEzQ8xEsepGmFWLYVeMEbJXgJPAjb+mGtHgUVioCh78OU+vKe0R8nWjmTmccxh8zcHU3kUPfhVSNhkjwc2UMlvW6DDgSw2JyAQZBewuCpqJr9bmHmejs5PkY2LmrLsBl0MifGE7Kj7o5+QFeimAc4/StyHcIk8jHDL4Ww0GKcD+M7kq85++0zdai8zILvBi9sZeOi+3Iow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6OiQ8taLrghruyRg4YmHgzFRo6wnNdajhJXdo46Fzaw=;
 b=gNY3covjJM0tESQcEQF6Gd6SDeI23uRb0Wxce+6EBk1c6KAS3ztIFMrZUp1uYFUMiA2OqLPu5xe2sPxkswv8EpEx1DltdihiPU53+/RRVOaWl38ZxdFrOflQQYo34GCUJ/D5BkxnyB0IiF6DuBNvaa1Eb/m5cuxn12cdqj8MVcnVXoVLuCEPqi923tsjcr0pwLZpDkGmE9DazKGXXIrY2vGO2w3VhQfw35vYW9Ic5UD2zuwlewQDQq8pTHpN7EDbiQADaZWYKiYZo114YAWhQBfyQ4FU+x08L14TFA4WAlN20en14x89bkXvVH3EFXpmuT36oEFjOwNW7J/uwb3TfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6OiQ8taLrghruyRg4YmHgzFRo6wnNdajhJXdo46Fzaw=;
 b=jaCEfpeiA5AbrFWyKXDrHdyR9N++a+e8dvGtDEniOIwhVfg2/+TnZfgftFG7O9yPye7Pr6FH64RIN8d8HHceYZcWLw0gUjLEL9blul6pH6DLQ6s+ysexnP00vkrW+FfUsBDkNkN6/1A64ksqP7uXQVmekpaEfS8cALyAxuVWVIc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <1e65ec27-372e-45bc-8c44-99ca2bc97a30@amd.com>
Date: Tue, 4 Aug 2026 15:38:09 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] drm/gem: Move pages_to_sg helper into drm_gem.c
To: =?UTF-8?Q?Adri=C3=A1n_Larumbe?= <adrian.larumbe@collabora.com>,
 Alex Deucher <alexander.deucher@amd.com>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>,
 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
 Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>,
 Lucas Stach <l.stach@pengutronix.de>,
 Russell King <linux+etnaviv@armlinux.org.uk>,
 Christian Gmeiner <christian.gmeiner@gmail.com>,
 Jianmin Lv <lvjianmin@loongson.cn>, Qianhai Wu <wuqianhai@loongson.cn>,
 Huacai Chen <chenhuacai@kernel.org>, Mingcong Bai <jeffbai@aosc.io>,
 Xi Ruoyao <xry111@xry111.site>, Icenowy Zheng <zhengxingda@iscas.ac.cn>,
 Rob Clark <robin.clark@oss.qualcomm.com>, Dmitry Baryshkov
 <lumag@kernel.org>, Abhinav Kumar <abhinav.kumar@linux.dev>,
 Jessica Zhang <jesszhan0024@gmail.com>, Sean Paul <sean@poorly.run>,
 Marijn Suijten <marijn.suijten@somainline.org>, Lyude Paul
 <lyude@redhat.com>, Danilo Krummrich <dakr@kernel.org>,
 Boris Brezillon <boris.brezillon@collabora.com>,
 Steven Price <steven.price@arm.com>, Liviu Dudau <liviu.dudau@arm.com>,
 Sandy Huang <hjc@rock-chips.com>, =?UTF-8?Q?Heiko_St=C3=BCbner?=
 <heiko@sntech.de>, Andy Yan <andy.yan@rock-chips.com>,
 Thierry Reding <thierry.reding@kernel.org>,
 Mikko Perttunen <mperttunen@nvidia.com>,
 Jonathan Hunter <jonathanh@nvidia.com>, Zack Rusin
 <zack.rusin@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>,
 Matthew Brost <matthew.brost@intel.com>,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>,
 Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
 Sumit Semwal <sumit.semwal@linaro.org>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
 linux-kernel@vger.kernel.org, etnaviv@lists.freedesktop.org,
 linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
 nouveau@lists.freedesktop.org, linux-rockchip@lists.infradead.org,
 linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
 intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
 linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
References: <20260724-get_pages-v1-1-b10e5d65628e@collabora.com>
Content-Language: en-US
From: =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
In-Reply-To: <20260724-get_pages-v1-1-b10e5d65628e@collabora.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR4P281CA0137.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:b8::17) To PH7PR12MB5685.namprd12.prod.outlook.com
 (2603:10b6:510:13c::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB5685:EE_|CH2PR12MB4136:EE_
X-MS-Office365-Filtering-Correlation-Id: 0147a598-a9d1-4a3b-efc5-08def22da7f1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|23010399003|366016|1800799024|921020|56012099006|10067099003|11063799006|5023799004|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	R1TpWk3vilOh0hB5JVbEo/bifnhNrQ8r79onpBBFKV5TcudcA8OnR2sxyj8OQ/Ge2XchKLsxXVpGO2VKlOdbQC3xNPfxJrHEUvhVDbXGbgB+yFOZQZWaJGVO8NLJaw3+Ke28xn1g9vEcWtBGD99stLP92Z5wS3LCjN56h79mEQ41m5XHg6ZY84myeGhgQrblxG2naiIsfrAw/5R3o1kmKTsAOstxaGLisuwl91I59F44nfXAiSskpI2EzCcvQES64hh86SJ0dCMz2LEFb+LU7hiLTyejEq5ui3od9Mq5ovBFocOVGneHOppuF7rdsyMl6kYCXvrFTVm6gxXXgizuKzHOu+peq/6EJFUyIf5042AhtpA64WD6ANFeXWz1WqDn83N+Ef1D2eH0Ful/czzXIi6rFVarIb13NEbHQS7C7mMdLDLsNZDtoz5IYiCsP9Vg7aCuG8tl24RUuRG8Ebw73XA/700jGjNdNr1cGrakyi46FplZhJrmq17+jBMKKjP1tTF+nVSfJbF6Xmv3n3i1d5ajgYi4ItYJdpQgZ/RQIndAK7fGB/ryj/9QZgKuqyDw0qS9sbOdbirG0RSVxyCWKVBKiTz7FuPnRFvmYhYw8oGmAORzpz6tosLWESIClimLvTavkVGNilMdMvwawP1UU24o8JQ8s6tISyoTWK7i9l2y0piUv4bV3hbch8AxxVLvpWgosni7vtZk/PDYvJHjcA==
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5685.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(366016)(1800799024)(921020)(56012099006)(10067099003)(11063799006)(5023799004)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?djEyZXZZVWxvNHJOcXYyYlQzRWVKTW9naGp2VDZwNmdrQW96RENpc25SejR0?=
 =?utf-8?B?N1YzQWpJS1djMU9CUmNlZTUyenFZaDArMnpmV1BwS1p2c2xsTEZaemxzSmZy?=
 =?utf-8?B?RHgrMm1DNjZBS2xOQzhhR0M3Z1FLY0E1b3IrYVZaWFU4R0srMzF1UnM0dVdT?=
 =?utf-8?B?R2loT05LODUzaVVObVpJZ1hHNlNRLzNiTXp0T21XaXhjeTBLc1lIYVo5WWhr?=
 =?utf-8?B?dzVNUU5JMXhNdU01cGhFamFXUEFUSFg3djNCTEpGcXozMmdrbzFoV1VOOEoz?=
 =?utf-8?B?YUR1KytCUFJpaDVOUGFtREVRS1dvbit4QjQ1SkthSUtnTlBDSlR4cmlTbHNt?=
 =?utf-8?B?R2piMHFhcmE3RGhBYlBjM2RYN0RNUXpiN2RNWnJZSWF1dGZ6UjBNMG1MeTU3?=
 =?utf-8?B?cXdrbTZObHd6ZUxmbElqdXdTZzFNY2lxdU1KVlB4NDBNeTNCWEZKaTJaRCtJ?=
 =?utf-8?B?ZGJxTDV1cjN5SmRiOFV0OW1pdUkyVHFNVjc1bGZ2eDVmQVNrczhJUTU3ejdT?=
 =?utf-8?B?RDNvTExUWEhIS05hMUZ4Mm95WE9LcXNiTFNYY3lkNUxKWGFxRGlPRk94cXpy?=
 =?utf-8?B?a0F1dEp4Znp6c05BRjNCSTk1dHRmMTIweTBPZU1KbkcwTGFnbVpBWXkzcmJC?=
 =?utf-8?B?NnlyS3RCd01uN3VpOGErUiszME9Qem42N3d3OGtjbmhLUzRlSUxWTW8rM2Ry?=
 =?utf-8?B?bkIzZU9BZXg1VGkwRzNnR3lWNmRFZGc1VjZyemltWUExTmZlUllBYzRHM0FO?=
 =?utf-8?B?NWFCbUxRVm5BdWo0bW5KTGZ1TUVBWTEvSzM0d0dlS1BXY0lwUGdhcWFFVm5J?=
 =?utf-8?B?eVFFYXkyTTNkUEx4bkp5TExQSEdVd0U0T3dZWG5rcnZySzYvc3NJTmhaVktp?=
 =?utf-8?B?cUlXUFc4ZUt1aW8wS25NTVdyQnZMVVd2U0RTYUhYRUdBU010RkkxVnZuMENC?=
 =?utf-8?B?WFc5Y1d6UUxMdnUzb0hTdUZUQmRUQXdsMVZObEE0Sk9TeUFiYVI2cGhXcTZU?=
 =?utf-8?B?SzdjUEpyYWxLakt2a2JDamk3L2ZweWVYTWRSTmp0eHdFb0NPbHU2NXIzRExO?=
 =?utf-8?B?a3pkcEtNNitJa3oyYU9xOGJLTldnQWNqOW4xYmlweUdpVFRyQVg1NDlzWFNy?=
 =?utf-8?B?SzBweE1Na3JHbkdMVDlVVFhxeWFsUFovemFLYkQ4cU5tdmNuV3liU2xrTW5l?=
 =?utf-8?B?REVxSTU0MzdkRmtOUVA2Q1kvTzhjRlhlbjMxSnNtMGZWcXJaMVdOVHVybVlH?=
 =?utf-8?B?VE5jVVQydHpXWVZUdlo3NEVHa29JTUNTMEt0ekd3T3hka2FtTkhYQklJSlVR?=
 =?utf-8?B?cHRoMHFOYlNzdW1HK2pOb0tOd0c1VzJiMEdLNWFHQWRmK1FpR0hOR2p6Unpy?=
 =?utf-8?B?c3dTcXB1N3VGb3lGcjJtWmFwcmpYWGhzeVVMdFpxUXJrZUtyOEhIU2NYcVRj?=
 =?utf-8?B?WnQ4K1BHV1Yra0pnVHpKdjNGWHdBMEgwZ1NDdlovVm5MTklYVjRpY051VXNL?=
 =?utf-8?B?c0NNM2orVmZnb1MweHROd3paMDQ0ZEl0MjY1ODNRWkJmVGw2Vk0rTlN1MnA2?=
 =?utf-8?B?ZVpwd2d0Sk55bzYvMTlybHVLcFJldVZwQ3JHQy9iK0NkbERLcFhVaDh1Wk40?=
 =?utf-8?B?L2xoYmVzTjl6bk1QWEp4dFROQzQ0RDI0Rml3ZHJTdStabE1DUlphR0xvUUZI?=
 =?utf-8?B?dG16Z0laT0pvNTBaL0NVWWw1djFqVnUzTmQzMDJDYnRIYzJPOXFjbmtrbk42?=
 =?utf-8?B?K0QwTUdqakp2b0JFRldycWNYbDNSRVg3Z0srQ3NoNHBEZHBwUzlMdkgzSHVx?=
 =?utf-8?B?b1JWekJzd0lhRGFiM2JKNlBtcHUyTFoxWDJjNWsvcGRGdDVNYkNlcXVTbjh0?=
 =?utf-8?B?aXJZWHFhbXl5ZDB4UEFZbEsycGJXbEluVFMxL2ZCWENPS1AyN28zdTVKYUJO?=
 =?utf-8?B?SitocldLUlpjSmZMdVZXZDRKSjBLdnkxVTlzQVVvN1JuOWNiZzhmU1JGR0du?=
 =?utf-8?B?N1o3NGdERUlac01teFppK2YyVjRJRGJwazl4aTg4SmFxVHdjL051T25ZNGpp?=
 =?utf-8?B?ZHd2THBCZUtjTnBIdFJWMHhweExBeGQ1Q2dOV3dBb2tiSlJ3UW9pR1pwb2lo?=
 =?utf-8?B?S00vSnUvZlpQbmVXNEhkdUVnVUQxK2F0V2tVRFVIL2IwV2NvcG5WeDZrY3Rm?=
 =?utf-8?B?U3J3MlROYTR2b3RubUtUR1dSTEg4SkNNVHlLaW5iZ0ZhL3pUSjJtRllSajlP?=
 =?utf-8?B?dWFvNkFlYlpqUTdmMUVVT3hjNlF4UTBjMDYwR3VJbmFFdURHVEJwZWppejB6?=
 =?utf-8?Q?N5jlV4ACThTJGiJhD/?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0147a598-a9d1-4a3b-efc5-08def22da7f1
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5685.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 13:38:24.2839
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: T1we7gz+msqYs5BOViZcVvxzazHnyiEcfi4bcJzi5rasJ0vTAGg2bjyYN9IeDyOl
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4136
X-purgate-ID: tlsNG-4011c0/1785850714-59BC0CFC-E6B74832/0/0
X-purgate-type: clean
X-purgate-size: 18956

On 7/24/26 14:08, Adrián Larumbe wrote:
> None of the semantics of the function tell of it being a PRIME-exclusive
> entry point. In fact, most drivers seem to be using it to translate a list
> of pages into an sg table that can be used for GPU mapping later on, rather
> than just for sharing an object's pages with another driver.
> 
> Move it across files and rename accordingly.
> 
> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> ---
> drm_prime_pages_to_sg() has no real dependency on PRIME/dma-buf interfaces.
> It is a generic helper that converts a page array into a scatter/gather
> table via dma_map_sg_attrs. Nothing in its implementation touches struct
> dma_buf or import/export logic.

It is correct that this helper is not DMA-buf dependent, but DMA-buf should be the only case when a DRM driver needs to convert an array of pages into an SG table.

The background is that we want to discourage people from using SG tables because it was a rather bad design choice to have pages mangled with the DMA addresses in one structure in the first place.

So question is why do you want to do this?

Regards,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |  6 ++---
>  drivers/gpu/drm/drm_gem.c                   | 35 ++++++++++++++++++++++++++
>  drivers/gpu/drm/drm_gem_shmem_helper.c      |  2 +-
>  drivers/gpu/drm/drm_prime.c                 | 38 -----------------------------
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c       |  3 +--
>  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |  3 ++-
>  drivers/gpu/drm/loongson/lsdc_gem.c         |  3 +--
>  drivers/gpu/drm/msm/msm_gem.c               |  2 +-
>  drivers/gpu/drm/msm/msm_gem_prime.c         |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_prime.c     |  4 +--
>  drivers/gpu/drm/panthor/panthor_gem.c       |  6 ++---
>  drivers/gpu/drm/radeon/radeon_prime.c       |  5 ++--
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  6 ++---
>  drivers/gpu/drm/tegra/gem.c                 |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c         |  4 +--
>  drivers/gpu/drm/xe/xe_dma_buf.c             |  6 ++---
>  drivers/gpu/drm/xen/xen_drm_front_gem.c     |  2 +-
>  include/drm/drm_gem.h                       |  5 +++-
>  include/drm/drm_prime.h                     |  2 --
>  19 files changed, 68 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index b33c300e26e2..c9a98aec7eb6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -203,9 +203,9 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach,
>  
>  	switch (bo->tbo.resource->mem_type) {
>  	case TTM_PL_TT:
> -		sgt = drm_prime_pages_to_sg(obj->dev,
> -					    bo->tbo.ttm->pages,
> -					    bo->tbo.ttm->num_pages);
> +		sgt = drm_pages_to_sg(obj->dev,
> +				      bo->tbo.ttm->pages,
> +				      bo->tbo.ttm->num_pages);
>  		if (IS_ERR(sgt))
>  			return sgt;
>  
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 018df97d590d..22c8a3b5f667 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -780,6 +780,41 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
>  }
>  EXPORT_SYMBOL(drm_gem_put_pages);
>  
> +/**
> + * drm_pages_to_sg - converts a page array into an sg list
> + * @dev: DRM device
> + * @pages: pointer to the array of page pointers to convert
> + * @nr_pages: length of the page vector
> + *
> + * This helper creates an sg table object from a set of pages.
> + * This is useful for implementing &drm_gem_object_funcs.get_sg_table.
> + */
> +struct sg_table *drm_pages_to_sg(struct drm_device *dev,
> +				 struct page **pages, unsigned int nr_pages)
> +{
> +	struct sg_table *sg;
> +	size_t max_segment = 0;
> +	int err;
> +
> +	sg = kmalloc_obj(struct sg_table);
> +	if (!sg)
> +		return ERR_PTR(-ENOMEM);
> +
> +	if (dev)
> +		max_segment = dma_max_mapping_size(drm_dev_dma_dev(dev));
> +	if (max_segment == 0)
> +		max_segment = UINT_MAX;
> +	err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0,
> +						(unsigned long)nr_pages << PAGE_SHIFT,
> +						max_segment, GFP_KERNEL);
> +	if (err) {
> +		kfree(sg);
> +		sg = ERR_PTR(err);
> +	}
> +	return sg;
> +}
> +EXPORT_SYMBOL(drm_pages_to_sg);
> +
>  static int objects_lookup(struct drm_file *filp, u32 *handle, int count,
>  			  struct drm_gem_object **objs)
>  {
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 22ec52e2ffb8..144d088a477f 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -825,7 +825,7 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct drm_gem_shmem_object *shmem)
>  
>  	drm_WARN_ON(obj->dev, drm_gem_is_imported(obj));
>  
> -	return drm_prime_pages_to_sg(obj->dev, shmem->pages, obj->size >> PAGE_SHIFT);
> +	return drm_pages_to_sg(obj->dev, shmem->pages, obj->size >> PAGE_SHIFT);
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
>  
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 9b44c78cd77f..54539a8929c1 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -835,44 +835,6 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  {
>  	.vunmap = drm_gem_dmabuf_vunmap,
>  };
>  
> -/**
> - * drm_prime_pages_to_sg - converts a page array into an sg list
> - * @dev: DRM device
> - * @pages: pointer to the array of page pointers to convert
> - * @nr_pages: length of the page vector
> - *
> - * This helper creates an sg table object from a set of pages
> - * the driver is responsible for mapping the pages into the
> - * importers address space for use with dma_buf itself.
> - *
> - * This is useful for implementing &drm_gem_object_funcs.get_sg_table.
> - */
> -struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
> -				       struct page **pages, unsigned int nr_pages)
> -{
> -	struct sg_table *sg;
> -	size_t max_segment = 0;
> -	int err;
> -
> -	sg = kmalloc_obj(struct sg_table);
> -	if (!sg)
> -		return ERR_PTR(-ENOMEM);
> -
> -	if (dev)
> -		max_segment = dma_max_mapping_size(drm_dev_dma_dev(dev));
> -	if (max_segment == 0)
> -		max_segment = UINT_MAX;
> -	err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0,
> -						(unsigned long)nr_pages << PAGE_SHIFT,
> -						max_segment, GFP_KERNEL);
> -	if (err) {
> -		kfree(sg);
> -		sg = ERR_PTR(err);
> -	}
> -	return sg;
> -}
> -EXPORT_SYMBOL(drm_prime_pages_to_sg);
> -
>  /**
>   * drm_prime_get_contiguous_size - returns the contiguous size of the buffer
>   * @sgt: sg_table describing the buffer to check
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index b0436a1e103f..a8e8614f8210 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -3,7 +3,6 @@
>   * Copyright (C) 2015-2018 Etnaviv Project
>   */
>  
> -#include <drm/drm_prime.h>
>  #include <drm/drm_print.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/shmem_fs.h>
> @@ -104,7 +103,7 @@ struct page **etnaviv_gem_get_pages(struct etnaviv_gem_object *etnaviv_obj)
>  		unsigned int npages = etnaviv_obj->base.size >> PAGE_SHIFT;
>  		struct sg_table *sgt;
>  
> -		sgt = drm_prime_pages_to_sg(dev, etnaviv_obj->pages, npages);
> +		sgt = drm_pages_to_sg(dev, etnaviv_obj->pages, npages);
>  		if (IS_ERR(sgt)) {
>  			dev_err(dev->dev, "failed to allocate sgt: %ld\n",
>  				PTR_ERR(sgt));
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> index 6757ae6ec304..f44484325ddb 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> @@ -3,6 +3,7 @@
>   * Copyright (C) 2014-2018 Etnaviv Project
>   */
>  
> +#include <drm/drm_gem.h>
>  #include <drm/drm_prime.h>
>  #include <linux/dma-buf.h>
>  #include <linux/module.h>
> @@ -22,7 +23,7 @@ struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  	if (WARN_ON(!etnaviv_obj->pages))  /* should have already pinned! */
>  		return ERR_PTR(-EINVAL);
>  
> -	return drm_prime_pages_to_sg(obj->dev, etnaviv_obj->pages, npages);
> +	return drm_pages_to_sg(obj->dev, etnaviv_obj->pages, npages);
>  }
>  
>  int etnaviv_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
> diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c b/drivers/gpu/drm/loongson/lsdc_gem.c
> index 2fb03487c983..37160228244c 100644
> --- a/drivers/gpu/drm/loongson/lsdc_gem.c
> +++ b/drivers/gpu/drm/loongson/lsdc_gem.c
> @@ -9,7 +9,6 @@
>  #include <drm/drm_dumb_buffers.h>
>  #include <drm/drm_file.h>
>  #include <drm/drm_gem.h>
> -#include <drm/drm_prime.h>
>  #include <drm/drm_print.h>
>  
>  #include "lsdc_drv.h"
> @@ -51,7 +50,7 @@ static struct sg_table *lsdc_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  		return ERR_PTR(-ENOMEM);
>  	}
>  
> -	return drm_prime_pages_to_sg(obj->dev, tt->pages, tt->num_pages);
> +	return drm_pages_to_sg(obj->dev, tt->pages, tt->num_pages);
>  }
>  
>  static void lsdc_gem_object_free(struct drm_gem_object *obj)
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index efd3d3c9a449..7e3418290c22 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -207,7 +207,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
>  
>  		msm_obj->pages = p;
>  
> -		msm_obj->sgt = drm_prime_pages_to_sg(obj->dev, p, npages);
> +		msm_obj->sgt = drm_pages_to_sg(obj->dev, p, npages);
>  		if (IS_ERR(msm_obj->sgt)) {
>  			void *ptr = ERR_CAST(msm_obj->sgt);
>  
> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c b/drivers/gpu/drm/msm/msm_gem_prime.c
> index 036d34c674d9..d25393a9e549 100644
> --- a/drivers/gpu/drm/msm/msm_gem_prime.c
> +++ b/drivers/gpu/drm/msm/msm_gem_prime.c
> @@ -23,7 +23,7 @@ struct sg_table *msm_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  	if (WARN_ON(!msm_obj->pages))  /* should have already pinned! */
>  		return ERR_PTR(-ENOMEM);
>  
> -	return drm_prime_pages_to_sg(obj->dev, msm_obj->pages, npages);
> +	return drm_pages_to_sg(obj->dev, msm_obj->pages, npages);
>  }
>  
>  int msm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c
> index caab60fc62f6..b95f2f07df74 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> @@ -32,8 +32,8 @@ struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  {
>  	struct nouveau_bo *nvbo = nouveau_gem_object(obj);
>  
> -	return drm_prime_pages_to_sg(obj->dev, nvbo->bo.ttm->pages,
> -				     nvbo->bo.ttm->num_pages);
> +	return drm_pages_to_sg(obj->dev, nvbo->bo.ttm->pages,
> +			       nvbo->bo.ttm->num_pages);
>  }
>  
>  struct drm_gem_object *nouveau_gem_prime_import_sg_table(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
> index 9855df738194..ec530d254fa4 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -321,8 +321,8 @@ panthor_gem_dev_map_get_sgt_locked(struct panthor_gem_object *bo)
>  	if (ret)
>  		return ERR_PTR(ret);
>  
> -	sgt = drm_prime_pages_to_sg(bo->base.dev, bo->backing.pages,
> -				    bo->base.size >> PAGE_SHIFT);
> +	sgt = drm_pages_to_sg(bo->base.dev, bo->backing.pages,
> +			      bo->base.size >> PAGE_SHIFT);
>  	if (IS_ERR(sgt))
>  		return sgt;
>  
> @@ -702,7 +702,7 @@ static struct sg_table *panthor_gem_get_sg_table(struct drm_gem_object *obj)
>  	drm_WARN_ON_ONCE(obj->dev, !bo->backing.pages);
>  	drm_WARN_ON_ONCE(obj->dev, !refcount_read(&bo->backing.pin_count));
>  
> -	return drm_prime_pages_to_sg(obj->dev, bo->backing.pages, obj->size >> PAGE_SHIFT);
> +	return drm_pages_to_sg(obj->dev, bo->backing.pages, obj->size >> PAGE_SHIFT);
>  }
>  
>  static int panthor_gem_vmap_locked(struct drm_gem_object *obj,
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c
> index a77881f035e7..4cfc4282a59c 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -26,6 +26,7 @@
>  
>  #include <linux/dma-buf.h>
>  
> +#include <drm/drm_gem.h>
>  #include <drm/drm_prime.h>
>  #include <drm/radeon_drm.h>
>  
> @@ -38,8 +39,8 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  {
>  	struct radeon_bo *bo = gem_to_radeon_bo(obj);
>  
> -	return drm_prime_pages_to_sg(obj->dev, bo->tbo.ttm->pages,
> -				     bo->tbo.ttm->num_pages);
> +	return drm_pages_to_sg(obj->dev, bo->tbo.ttm->pages,
> +			       bo->tbo.ttm->num_pages);
>  }
>  
>  struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index b188539dca0b..7897da0becf4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -89,8 +89,8 @@ static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
>  
>  	rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
>  
> -	rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->base.dev,
> -					    rk_obj->pages, rk_obj->num_pages);
> +	rk_obj->sgt = drm_pages_to_sg(rk_obj->base.dev,
> +				      rk_obj->pages, rk_obj->num_pages);
>  	if (IS_ERR(rk_obj->sgt)) {
>  		ret = PTR_ERR(rk_obj->sgt);
>  		goto err_put_pages;
> @@ -432,7 +432,7 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct drm_gem_object *obj)
>  	int ret;
>  
>  	if (rk_obj->pages)
> -		return drm_prime_pages_to_sg(obj->dev, rk_obj->pages, rk_obj->num_pages);
> +		return drm_pages_to_sg(obj->dev, rk_obj->pages, rk_obj->num_pages);
>  
>  	sgt = kzalloc_obj(*sgt);
>  	if (!sgt)
> diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> index 436394e04812..701af672b4e5 100644
> --- a/drivers/gpu/drm/tegra/gem.c
> +++ b/drivers/gpu/drm/tegra/gem.c
> @@ -17,7 +17,7 @@
>  
>  #include <drm/drm_drv.h>
>  #include <drm/drm_dumb_buffers.h>
> -#include <drm/drm_prime.h>
> +#include <drm/drm_gem.h>
>  
>  #include "drm.h"
>  #include "gem.h"
> @@ -352,7 +352,7 @@ static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo)
>  
>  	bo->num_pages = bo->gem.size >> PAGE_SHIFT;
>  
> -	bo->sgt = drm_prime_pages_to_sg(bo->gem.dev, bo->pages, bo->num_pages);
> +	bo->sgt = drm_pages_to_sg(bo->gem.dev, bo->pages, bo->num_pages);
>  	if (IS_ERR(bo->sgt)) {
>  		err = PTR_ERR(bo->sgt);
>  		goto put_pages;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> index 39f8c46550c2..c9e7f2e3668c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> @@ -28,7 +28,7 @@
>  #include "vmwgfx_bo.h"
>  #include "vmwgfx_drv.h"
>  
> -#include "drm/drm_prime.h"
> +#include "drm/drm_gem.h"
>  #include "drm/drm_gem_ttm_helper.h"
>  
>  #include <linux/debugfs.h>
> @@ -76,7 +76,7 @@ static struct sg_table *vmw_gem_object_get_sg_table(struct drm_gem_object *obj)
>  	if (vmw_tt->vsgt.sgt)
>  		return vmw_tt->vsgt.sgt;
>  
> -	return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages, vmw_tt->dma_ttm.num_pages);
> +	return drm_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages, vmw_tt->dma_ttm.num_pages);
>  }
>  
>  static int vmw_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map)
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
> index 8a920e58245c..f0fe80706b79 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -118,9 +118,9 @@ static struct sg_table *xe_dma_buf_map(struct dma_buf_attachment *attach,
>  
>  	switch (bo->ttm.resource->mem_type) {
>  	case XE_PL_TT:
> -		sgt = drm_prime_pages_to_sg(obj->dev,
> -					    bo->ttm.ttm->pages,
> -					    obj->size >> PAGE_SHIFT);
> +		sgt = drm_pages_to_sg(obj->dev,
> +				      bo->ttm.ttm->pages,
> +				      obj->size >> PAGE_SHIFT);
>  		if (IS_ERR(sgt))
>  			return sgt;
>  
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> index eec4c1da3f9e..a4a7c7f2c91c 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> @@ -236,7 +236,7 @@ struct sg_table *xen_drm_front_gem_get_sg_table(struct drm_gem_object *gem_obj)
>  	if (!xen_obj->pages)
>  		return ERR_PTR(-ENOMEM);
>  
> -	return drm_prime_pages_to_sg(gem_obj->dev,
> +	return drm_pages_to_sg(gem_obj->dev,
>  				     xen_obj->pages, xen_obj->num_pages);
>  }
>  
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 885244e375d3..7b9cc6335689 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -155,7 +155,7 @@ struct drm_gem_object_funcs {
>  	 * here cannot be used for sg tables pointing at driver private memory
>  	 * ranges.
>  	 *
> -	 * See also drm_prime_pages_to_sg().
> +	 * See also drm_pages_to_sg().
>  	 */
>  	struct sg_table *(*get_sg_table)(struct drm_gem_object *obj);
>  
> @@ -589,6 +589,9 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj);
>  void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
>  		bool dirty, bool accessed);
>  
> +struct sg_table *drm_pages_to_sg(struct drm_device *dev,
> +				 struct page **pages, unsigned int nr_pages);
> +
>  void drm_gem_lock(struct drm_gem_object *obj);
>  void drm_gem_unlock(struct drm_gem_object *obj);
>  
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index f50f862f0d8b..603e16a40ae7 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -92,8 +92,6 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, struct iosys_map *map);
>  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
>  int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
>  
> -struct sg_table *drm_prime_pages_to_sg(struct drm_device *dev,
> -				       struct page **pages, unsigned int nr_pages);
>  struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
>  				     int flags);
>  
> 
> ---
> base-commit: 48dd37d1fef33fbf42f1d6887c61e242fd21d00d
> change-id: 20260724-get_pages-e2e91c53eaa3
> 
> Best regards,
> --  
> Adrián Larumbe <adrian.larumbe@collabora.com>
> 



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 13:41:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 13:41:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382174.1625544 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFO7-0001JG-6C; Tue, 04 Aug 2026 13:40:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382174.1625544; Tue, 04 Aug 2026 13:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFO7-0001J9-3T; Tue, 04 Aug 2026 13:40:59 +0000
Received: by outflank-mailman (input) for mailman id 1382174;
 Tue, 04 Aug 2026 13:40:57 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrFO5-0001J2-DR
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 13:40:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrFO4-00EzIj-AN
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:40:56 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71ebdc-5cb7-0a2a0a5109dd-0a2a4507af8a-44
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:40:56 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71ebe7-b4ea-0a2a45070019-d1558029e403-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:40:56 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso22305565e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 06:40:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49949fc6f16sm159359965e9.2.2026.08.04.06.40.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 06:40:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785850855; x=1786455655; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=OJJQReJUi7fUzVzzuopy47u3RxzqcfK1FXi07EBFiFs=;
        b=FzxPh1Hb5Zc+wY9VXIP0tz/nNr41bOv0/pEnbRWvFou+uHatSd3K2TspxcTqxL4yco
         WJ66jnjO7EfbdH6zKB1Hgx22lYDBYO+LQYKdcGwjzMaW6LhOBYqKZkHiPjoyppHpZvzZ
         TV7N5vqUuodoS9yIHh+S+oYSJj8cMEE9X730LYcPe1cysKYExCaBw6oTPgXqbfB/tAlx
         TG+/yiEP2DFPkvWhLK+bFuPwG8Sp+GqeIRi9eVdCdwWXVmq47wtlJj2or1ahaT+7l+Fq
         Np2k3N+wFYtXpc8RK+DhMFz/opAWa8sx29NBeDRMHD5IA5uJe5Xp4wS+tUTRqzYTlNqK
         fyrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785850855; x=1786455655;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=OJJQReJUi7fUzVzzuopy47u3RxzqcfK1FXi07EBFiFs=;
        b=IwQ9ss10WD4Xfid07yrdpzX6Ej8bCpSv4x4VsyFbz/A+Uh9ARjFtbZSAMOnnQwuJWQ
         Cs1vMTKfl+1Ng6n9M+4ETz07xwhlqZVqKU5T1QrzLdaHsCDRNbbKimTCKctNMZMRoIDL
         VnQWpKAorY17WXPO4fqzAktk8eFTBVSn4ESp160lyql5P6xPiU3YsY9dkgENXXrb92A6
         eK5SJzjxEKZVCQkppNSw2eofAbSj3JUu2Uhn2HGdCxCi5DK9FAvcixR3ivWllivg9IvQ
         Qm2P2laX+F6bDzyA4Dflfypx/g0Ru+yWYDL+QCwCUXpCgoCY6PsiKTrzTYep486GHPRa
         Lycg==
X-Forwarded-Encrypted: i=1; AHgh+RqjJBSr9eqVphtdrOaZyZTjNIjaQ6cvvC2XKEWKHBF0OUhrGy3BgIq1LGq8U8bE8StTwDEKByc8zNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzw0ZbPpfkovqGlqDyXNNpJfV6IEHSKGkD8CXJV7cjWLwgQJGLa
	ocJ0tA1KP3DkFHhLeUeeJ4tTnJGl3liKnRbdIXkTYM+z/YfD43jbkz03aDKtoO7+ow==
X-Gm-Gg: AR+sD11LgpZ7BPZjRdnb27UwUQXh4WLsE9q1GR46dRHHEqr9GwQr4rqLhXyph6tx5RX
	UT79dPUhb1KGBDLIBPabPbUkO+A51hYYdqKgQHz1lOViXbWgLEofJE6gy6l7e4YuLC3utehoebj
	9VDw3oWyzS8yxB+usZMMVIZKGimDSFSE4svBjlSCYAiIb7/9Ey3CDVnYpAO+X/biuAzLEs2RDE/
	gx8vR5ROowwlDITAT4z6eP2w7p46jYlxX3jRUabnsIslyskiahsWBt9/p1ARrZ01lta+9JJa3hr
	pJCFh7QAKXw2OLIU0h4WUaAL8z7HL7fWUTnFqTb/pBoPzdOB2D0l+C1P7i+U2KJP+FUv9MM570o
	alpYPiv5hl6pVaPmoXwzdbOmWS/4OrqTRmDb41Ot/i1olss/s8w+m+5WrkNCIW4k05DMsLXDDol
	bYP+tj7ZCnlmgb8isgcgKCsuzpUs5LuqgoJnuDA1KfNdoSTvjZudCNELc41T5XvHq6fGRaLxGFk
	cv7TJlBwwqC4XL4jiR664i25GAZrDbNlSmG0RGer2pGB8Vft5ni
X-Received: by 2002:a05:600c:840f:b0:495:5fdf:2075 with SMTP id 5b1f17b1804b1-4980c5fa29amr299658695e9.0.1785850852314;
        Tue, 04 Aug 2026 06:40:52 -0700 (PDT)
Message-ID: <2c012213-0fd0-40f8-8806-0096040370aa@suse.com>
Date: Tue, 4 Aug 2026 15:40:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] x86: introduce "brk" allocator
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <31ba7ff2-a42d-44aa-976c-17fbff44a56f@suse.com>
 <f7e3cd68-f6de-4ada-87d9-1a5dff277b2f@suse.com>
 <91bdef16-2da7-49e7-af5a-e395da533330@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <91bdef16-2da7-49e7-af5a-e395da533330@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785850856-36CDFAE4-6EA4D02B/0/0
X-purgate-type: clean
X-purgate-size: 4240

On 30.07.2026 19:59, Andrew Cooper wrote:
> On 27/07/2026 11:19 am, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/boot/brk.c
> 
> While brk.c has x86 specifics, I'm not sure it's worthy if being in
> boot/, rather than simply in x86/.  It's used until mid way through
> __start_xen().

As discussed, I'll move this to common/brk.c right away, abstracting out
the x86 specifics.

>> @@ -0,0 +1,72 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +
>> +#include <xen/efi.h>
>> +#include <xen/lib.h>
>> +#include <xen/mm.h>
>> +#include <xen/page-defs.h>
>> +
>> +#include <asm/brk.h>
>> +
>> +extern char __brk_start[];
>> +extern const char __bss_end[];
>> +
>> +static unsigned long __initdata allocated;
>> +static bool __initdata finished;
>> +
>> +void *__init brk_alloc(size_t size)
>> +{
>> +    void *ptr = __brk_start + allocated;
>> +
>> +    if ( finished )
>> +        return NULL;
>> +
>> +    /* Allocations PAGE_SIZE and up will be page-aligned. */
>> +    if ( size >= PAGE_SIZE )
>> +        allocated = ROUNDUP(allocated, PAGE_SIZE);
>> +
>> +    allocated += ROUNDUP(size, sizeof(void *));
>> +
>> +    if ( allocated > __bss_end - __brk_start )
>> +        return NULL;
> 
> This means one (or more) subsystem has brk_alloc()'d more than they
> reserved.
> 
> While returning NULL is probably the best action, I think a
> printk_once() is also warranted.

Hmm, yes, just that there's a quirk to work around: The static that
printk_once() uses gets in the way of the file getting compiled into
brk.init.o.

>> +
>> +    return ptr;
>> +}
>> +
>> +unsigned long __init brk_get_unused_start(void)
>> +{
>> +    finished = true;
> 
> This doesn't get the unused start.  It also terminates the allocator,
> and the name needs to reflect that.

brk_cease() then.

> But combined with brk_end in the next patch, it's really quite a mess. 
> Integrating brk_end properly simplifies this patch too.

No, brk_end really is an x86-specific helper variable. I'd like to keep
that as it is.

>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/brk.h
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +
>> +#include <xen/types.h>
>> +
>> +void *brk_alloc(size_t size);
>> +unsigned long brk_get_unused_start(void);
>> +void brk_free_unused(void);
> 
> It's inevitable that brk is going to be used in other architectures, and
> none of this is x86 specific.
> 
> This should be xen/include/brk.h right from the outset, even if that's
> all we do in the way of making it generic.
> 
> Except, brk_end in patch 2 really needs to live in common/brk.c so it's
> probably easier to go in arch-neutral right from the outset and use
> "select ARCH_HAS_BRK" or so to allow the arches to opt into using it.
> 
> Furthermore, this header needs some commentary.  To do this nicely,
> DEFINE_BRK() needs to be introduced here so the comment makes sense.

Sure, I can move introduction of the macro here.

Jan

> -----
> Early Boot memory allocator.
> 
> Subsystems which conditionally need memory prior to the main heap being
> set up should use DEFINE_BRK() to reserve BSS space in Xen.
> 
> During boot, brk_alloc() allocates memory from the reserved space.  Such
> allocations are good for the lifetime of Xen.  Subsystems MUST NOT
> brk_alloc() more memory than they reserved.
> 
> When the main heap is set up, brk allocations become unavailable. 
> Reserved but unallocated space is handed to the main heap, so it doesn't
> go to waste.
> -----
> 
> 
> With just a few sentences, it's now far clearer what brk is and how to
> use it.
> 
> 
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -321,7 +321,11 @@ SECTIONS
>>         __bss_start = .;
>>         *(.bss.page_aligned*)
>>         PERCPU_BSS
>> -       *(.bss .bss.*)
>> +       *(.bss .bss.[a-zA-Z0-9_]*)
>> +       . = ALIGN(PAGE_SIZE);
>> +       __brk_start = .;
>> +       *(.bss..brk.page_aligned*)
>> +       *(.bss..brk*)
>>         . = ALIGN(POINTER_ALIGN);
> 
> This looks fine, but if it's becoming common then it wants to be a macro
> in xen.lds.h
> 
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 13:56:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 13:56:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382183.1625554 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFcg-0003Sz-Gi; Tue, 04 Aug 2026 13:56:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382183.1625554; Tue, 04 Aug 2026 13:56:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFcg-0003Ss-D9; Tue, 04 Aug 2026 13:56:02 +0000
Received: by outflank-mailman (input) for mailman id 1382183;
 Tue, 04 Aug 2026 13:56:00 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrFce-0003Sm-CX
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 13:56:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrFca-00Box7-1L
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:55:56 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71ef6a-e002-0a2a0a5209dd-0a2a45028796-10
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:55:55 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71ef6b-6ca4-0a2a45020019-d155dd2dd0cd-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 15:55:55 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-4799b3f7c83so3027752f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 06:55:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd41e2484sm45261033f8f.11.2026.08.04.06.55.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 06:55:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785851755; x=1786456555; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=9h9+fq6Jp77OyWF1yf/69cNg6J6mI+PxR6Z5EORHM/I=;
        b=A6DwsTGd+HY+bgcER38rKTb3mqFqy4B1SUT2vBjqc1s7KIBepArPAEuFmHczZJD/c7
         Dd5g2TBrnKpGi/F+ljRnIeII4+gwmxoFVkJy3g6gucuKlOyCP/ETCULht0IiUmidG0jR
         w4nyPinBtSgZ+lmfSF7vNdYsSi49JvdyTpAIWd58hLS3ob/4j0rY2wg1YIpzWEFLjZGY
         XLKzcQktBgZVYUWwBf5HH+q/JbJB85Sls8Y5BVhyO2JZdyOBS1pVB3QVP2Y42ych/ehB
         VasmNbstisrQ+FAKwO8T5wOTn3QhbhUpaq6YRlm3lSeDKbyTUiPk6vs57ljVE2Ee8e7T
         WRfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785851755; x=1786456555;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=9h9+fq6Jp77OyWF1yf/69cNg6J6mI+PxR6Z5EORHM/I=;
        b=TG4K0Mtc0xfoEwnit0Kv6gXkXfGQ57M/72TuL/YmIkmiyT8Gamg/E5FVgFLjWtMuTQ
         wPxnFQ30EAiEe5HggbtYRcUceGZkRv/wb8Tj9CVhOj7QstW2FWBZXs4jvEatbQJ9P59u
         N8IrY0p0vUFU6E6sqf6FeARft4nnS2C/DMV+fIBAcdwP9H69PTfkHjbH/p28EY9ElohH
         NxHBXKpM2G1v7C8dbza0uiIOHTRkYgbvpmlsAt782ZJZ/D/dCNY5O7MKLezfbF5NRSCE
         7d/sJeOW8bpXocmNxuW1RSq52r3ytWjKWZ4VwYvMu/G6Q7aPttVRSI2alcF4e/f2qOx6
         QP7g==
X-Forwarded-Encrypted: i=1; AHgh+Rrwrtpq96DvpN+k7nh0fYx0juU2E7BUNoqBJsxE4ul9IjyJNTewi2VL8XdF3TRrQ555yT3jaCYNP7Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxg27Qluu0/SHAXTHKkKClfSP9yGvE7Cb0ItdytH7/7aHAQ3cAx
	EWrgjIbbwttXxcA9U+SfpOEp4YDP5QdsvggUupdgOjqOQ/S2j5V93ZCecjhFTRungw==
X-Gm-Gg: AR+sD13rYj3EYIna8iuXLThwAUzFUUlo9oVEY6J/h0cmEx+GeCqWIXmVo9DSz2nwQFn
	UJ6hNgwmXlESDdiXIYaH/eh4xqcCIgUYM1YdVHP9QY4Yc+nosbbFbzXUV4mEW/5U6sPcjVdLfz5
	yDWV2fL732FHFv9Bef0FOJcdH8P1XlmKr6NrK7xZAfrDHEMnglCCKUV1z3giqLhgdJe2zF9I3oy
	U1E0q6VSTL06bylr3GZ12mwNDlcr4qFAotHE1Ax66uyYCUW6IWmFw00RREiBA3l5uhP6ajpppMB
	fCYaYCPIMl58ve4GBpdjzPmqSSmHfgwIH6vjfVthDOruy+ruMP2UnYru+m08tcxRE+0Pb4/NjAp
	aV0LEPHP0vI1tZKnWXtA5njV5rx6UJTbro5DaShmpNLIjrvU5aE4g0a2igyc40+7AD3zZurioXQ
	6MA5F24OShkPvLXCh5uTwr7/ReQOT+/y4dAgyjG4NiAQz5sH8aZ5IknWYVBr1q2/mbGUHLD/e/I
	c7X2kgTkm77eDSKNJjWL7xVvhZei+IeyjD8i7l5PN+MYdlWRrJu
X-Received: by 2002:a05:6000:40e1:b0:47f:8b1f:efa2 with SMTP id ffacd0b85a97d-47fd729e88bmr37834347f8f.8.1785851755310;
        Tue, 04 Aug 2026 06:55:55 -0700 (PDT)
Message-ID: <28d4e98a-2fd2-41fb-9f1c-c5f4768989f9@suse.com>
Date: Tue, 4 Aug 2026 15:55:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] radix-tree: drop radix_tree_init_maxindex()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <25cf9c88-7589-4a5d-994d-45f488a3e00b@suse.com>
 <c00db623-82bc-4d7f-924f-25f35f8e057e@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <c00db623-82bc-4d7f-924f-25f35f8e057e@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785851755-F0AA52AC-0FF330C8/0/0
X-purgate-type: clean
X-purgate-size: 2864

On 04.08.2026 14:58, Andrew Cooper wrote:
> On 04/08/2026 1:30 pm, Jan Beulich wrote:
>> Radix trees are in principle usable as soon as memory allocation works.
>> (Radix trees with only index 0 populated are usable even earlier.) If only
>> there wasn't height_to_maxindex[], which is filled only by a pre-SMP
>> initcall. The benefit of this array is rather limited - the calculations
>> done by __maxindex() can as well be done by radix_tree_maxindex(); the
>> overhead isn't all this high.
> 
> It's quite possibly lower overhead.  Some simple integer arithmetic vs a
> memory read.
> 
> I think it's worth noting that this was found by UBSAN on a
> multi-segment system:
> 
> (XEN) UBSAN: Undefined behaviour in common/radix-tree.c:83:27
> (XEN) index 12 is out of range for type 'long unsigned int [12]'
> ...
> (XEN) Xen call trace:
> (XEN)    [<ffff82d040323f9c>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd5
> (XEN)    [<ffff82d040324d91>] F __ubsan_handle_out_of_bounds+0x9d/0xd4
> (XEN)    [<ffff82d04029265a>] F radix_tree_insert+0x24d/0x570
> (XEN)    [<ffff82d04037ac3e>] F drivers/passthrough/pci.c#alloc_pseg+0xc4/0x165
> (XEN)    [<ffff82d040a3b526>] F pci_add_segment+0xc/0x1b
> (XEN)    [<ffff82d040a5ad1b>] F acpi_parse_mcfg+0x29b/0x344
> (XEN)    [<ffff82d040a3f612>] F acpi_table_parse+0x5d/0x92
> (XEN)    [<ffff82d040a5bf55>] F acpi_mmcfg_init+0x3a2/0x71d
> (XEN)    [<ffff82d040a71ba6>] F pci_setup+0x17/0x29
> (XEN)    [<ffff82d040a784d0>] F __start_xen+0x394c/0x4ed8
> (XEN)    [<ffff82d040423057>] F __high_start+0xb7/0xb8

Added in.

>> Fixes: 21844b0e32e7 ("PCI multi-seg: introduce notion of PCI segments")
>> Fixes: 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux to gain RCU awareness")
>> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

> All the UBSAN violations are gone.

Good.

> FWIW, there are still issues on this box, even after the fix:
> 
> (XEN) setup 0000:fe:00.0 for d0 failed (-19)
> (XEN) setup 0000:fe:00.1 for d0 failed (-19)
> ...
> (XEN) setup 0000:ff:19.0 for d0 failed (-19)
> (XEN) setup 0000:ff:1a.0 for d0 failed (-19)
> (XEN) setup 0001:fe:00.0 for d0 failed (-19)
> (XEN) setup 0001:fe:00.1 for d0 failed (-19)
> ...
> (XEN) setup 0001:ff:19.0 for d0 failed (-19)
> (XEN) setup 0001:ff:1a.0 for d0 failed (-19)
> 
> These are the PCI devices for aspects of the uncore, mostly performance
> counters it seems.  Despite the lack of information, I think the
> complaint is about setting up the IOMMU context for them.

This looks vaguely familiar. Are these devices properly covered by the ACPI
DMAR table? (In the instance where I think I saw such before, they weren't.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 14:01:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 14:01:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382191.1625561 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFhx-0005UV-1r; Tue, 04 Aug 2026 14:01:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382191.1625561; Tue, 04 Aug 2026 14:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFhw-0005UO-Va; Tue, 04 Aug 2026 14:01:28 +0000
Received: by outflank-mailman (input) for mailman id 1382191;
 Tue, 04 Aug 2026 14:01:28 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrFhw-0005UI-4o
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 14:01:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrFhv-00FSWu-Dv
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 16:01:27 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71f0b3-e002-0a2a0a5209dd-0a2a4508a3de-14
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:01:27 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71f0b6-f659-0a2a45080019-d155dd31c9dc-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:01:27 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47fd4531020so2742052f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:01:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fd41e296csm40257775f8f.12.2026.08.04.07.01.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 07:01:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785852086; x=1786456886; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=e+v4psFhaswe/NmQm5nAjbAZqqFxseEEVmVnupeklQA=;
        b=TYGfdWIkMvqm6NE7yO2gK5ZmNBEE3/BcvPAUKy5TzB/2Ap90shveyA7Nf5Oxo6q0HC
         LzxK2t8MlzC134M156a23XoWCvCQAhHHRDxWThdx5yhHX2K208DH0nqjehIzMJoW3eo+
         A2MeYssxCTqjP3KW58XPOXYhSK1HgFbWlB5BCgBbg/6CSG69kEHwl/yZFiQJWCF0kOJf
         mk2bVFN5d+Ewdkp7Ar8ODPh3ppG9W8AwQvriG4m7gppLlypOSivXsCwAQlXDzuJHOP5s
         tTaALoaAEE310eJGhQbV8geT1yXED5tQWq4/R0Bpu7H87SO+z4XZ78OwQKrf7TaoVs1e
         rEAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785852086; x=1786456886;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=e+v4psFhaswe/NmQm5nAjbAZqqFxseEEVmVnupeklQA=;
        b=jEqkcZCCQRqwcsrPMnU9ugR2V2hmf8oxB5lPG3+0+1EtfAGVWjRjI0tFjmnZFUgsmX
         INNXNpSL8qwa0Omx6GNMSg7X4hNpmJ9LazBklVjoAgstvjhdmVl5HugvgWBFmD+rZ206
         /L+V+L+ekbXKlPEF06Y0uE6serN3cD8Pwfor/kJhz40hVc9P+MMGDtjEHp5ixmhZP6x+
         v7Eg5yf69yY9WbpJnf7dpCmPYscMeCuF38Mm0Zx8MyZhKIz4iLuxDK0fdP6/Ebtg0NCP
         bqOABq8ZDu8dBkweohU+g/AU9gov8OvkynRFkUsSDux2dxsp8uUDtTaz0GKrfVui6ShK
         W2RQ==
X-Forwarded-Encrypted: i=1; AHgh+RrOtQ89je6tsQ0RWiH/F+46IwacaP7GVZbVHy2FPXeTofxBZFQxAGzNpakRxu8ceFsn+xM3VUYuBqI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz/RCQlNpC5tvLi745iIXW6sQJeDNwDgvqjKV77lV6KMvRQvmtR
	h/2aJr/AOnxAKis/YGm4G/BVL0k754k+qcdlFzvaGbombd7WBMMZ/Ihra8udX2wjjQ==
X-Gm-Gg: AR+sD11vkbcVgEPyC1mCG0YAWteq0vAUROBj95+R+O9MgAUdVG1MqxXhMkRZErB0FwL
	iDqOJrZNNPUu1i/Fwn5XRQIF+lR3HRnJwNz0q6y96MDDH4rwibciPSPT7xnd0E8BEhv07DuR+y3
	+nyeflosWtwrW0WDdTHKL/JXUYhnUfg9huPBMalOULlaEcS0R/f/rC2W72pvLPldTnHiXRggEyZ
	cDAc9dzeBg+nLV12BHkyi6oqLBIqmd7ARr8aPjv0lJFGqH7fvN6Ci/IB20ZBI8fK09HKheKgYHr
	EPzqy0cJ8jBbMJ2sI4F7PFfX0Y8M7jR7zX+1LPcMkbiO29COTVHbhVW1HUYrnauy0djfY2gJTKz
	fEmCybN0gMlcxePDAAjdhTx7a6oZ/t2pX02wkH3HpVgh7tOa7065Ow46hLDwVJLAobyAuA2AxQg
	UNcDpQ1vbRC1Z6LPKfgFNyVspC63IaDhU3isf5gIC+pMvFodQ2L6lTVt/fS6NoAjb/DdDjzU6k1
	k+WW0uIq4iR/JmvAYMLtIEdIJcMYSRT8ikdjn1GcqKsxG4cTQSC
X-Received: by 2002:a05:6000:b48:b0:47f:91e3:3cbf with SMTP id ffacd0b85a97d-47fd72b0a3dmr30401083f8f.19.1785852086379;
        Tue, 04 Aug 2026 07:01:26 -0700 (PDT)
Message-ID: <d12a6815-612d-4cf6-af50-8370d1ff4108@suse.com>
Date: Tue, 4 Aug 2026 16:01:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] x86/EFI: replace ebmalloc()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Teddy Astie <teddy.astie@vates.tech>,
 Marek Marczykowski <marmarek@invisiblethingslab.com>,
 Daniel Smith <dpsmith@apertussolutions.com>
References: <31ba7ff2-a42d-44aa-976c-17fbff44a56f@suse.com>
 <98388998-c5c6-4991-8662-2b4bf25188f2@suse.com>
 <2eb924b2-11fd-45be-b933-c6352fb2dfe0@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2eb924b2-11fd-45be-b933-c6352fb2dfe0@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785852087-CD74B87B-96CF44F6/0/0
X-purgate-type: clean
X-purgate-size: 3321

On 30.07.2026 20:08, Andrew Cooper wrote:
> On 27/07/2026 11:20 am, Jan Beulich wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -31,6 +31,7 @@
>>  #include <asm/alternative.h>
>>  #include <asm/apic.h>
>>  #include <asm/bootinfo.h>
>> +#include <asm/brk.h>
>>  #include <asm/bzimage.h>
>>  #include <asm/cpu-policy.h>
>>  #include <asm/e820.h>
>> @@ -164,6 +165,8 @@ cpumask_t __read_mostly cpu_present_map;
>>  
>>  unsigned long __read_mostly xen_phys_start;
>>  
>> +unsigned long __ro_after_init brk_end;
>> +
>>  /* Only used in asm code and within this source file */
>>  char asmlinkage __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
>>      cpu0_stack[STACK_SIZE];
>> @@ -1141,7 +1144,6 @@ void asmlinkage __init noreturn __start_
>>      struct boot_info *bi;
>>      unsigned long nr_pages, raw_max_page;
>>      int i, j, bytes = 0;
>> -    unsigned long eb_start, eb_end;
>>      bool acpi_boot_table_init_done = false, relocated = false;
>>      bool vm_init_done = false;
>>      int ret;
>> @@ -1511,7 +1513,7 @@ void asmlinkage __init noreturn __start_
>>          /*
>>           * This needs to remain in sync with remove_xen_ranges() and the
>>           * respective reserve_e820_ram() invocation below. No need to
>> -         * query efi_boot_mem_unused() here, though.
>> +         * query brk_get_unused_start() here, though.
>>           */
>>          xen->start = virt_to_maddr(_stext);
>>          xen->size  = __2M_rwdata_end - _stext;
>> @@ -1654,18 +1656,11 @@ void asmlinkage __init noreturn __start_
>>      if ( !xen_phys_start )
>>          panic("Not enough memory to relocate Xen\n");
>>  
>> -    /* FIXME: Putting a hole in .bss would shatter the large page mapping. */
>> -    if ( using_2M_mapping() )
>> -        efi_boot_mem_unused(NULL, NULL);
>> -
>>      /* This needs to remain in sync with remove_xen_ranges(). */
>> -    if ( efi_boot_mem_unused(&eb_start, &eb_end) )
>> -    {
>> -        reserve_e820_ram(&boot_e820, __pa(_stext), __pa(eb_start));
>> -        reserve_e820_ram(&boot_e820, __pa(eb_end), __pa(__2M_rwdata_end));
>> -    }
>> -    else
>> -        reserve_e820_ram(&boot_e820, __pa(_stext), __pa(__2M_rwdata_end));
>> +    brk_end = brk_get_unused_start();
>> +    if ( using_2M_mapping() )
>> +        brk_end = PAGE_ALIGN_2M(brk_end);
>> +    reserve_e820_ram(&boot_e820, __pa(_stext), __pa(brk_end));
> 
> Hiding brk_end in setup.c like this is quite rude.  I guess it's because
> you want to have brk.c be brk.init.o, but it really does live with the
> other brk functions.

As said in reply to you comments on patch 1 - brk_end is purely an x86
helper variable. I don't want it to move to common code.

> Furthermore, having brk_end right from the outset fixes the fact that
> brk_get_unused_start() is doing things beyond retrieving a value.
> 
> With brk_end being the real bump pointer the allocator uses,

Hmm, no - I don't view the variable as fulfilling that purpose.

Jan

> then the
> only function you need is brk_finish() (name subject to improvement)
> which is now very clear about the point at which brk allocations cease
> working.
> 
> The rest, dropping EFI's current ebmalloc() all looks fine now.
> 
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 14:04:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 14:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382197.1625571 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFkR-0005yu-EQ; Tue, 04 Aug 2026 14:04:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382197.1625571; Tue, 04 Aug 2026 14:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrFkR-0005yn-BL; Tue, 04 Aug 2026 14:04:03 +0000
Received: by outflank-mailman (input) for mailman id 1382197;
 Tue, 04 Aug 2026 14:04:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrFkQ-0005yh-A7
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 14:04:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrFkP-001Ss4-Mw
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 16:04:01 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71f133-e002-0a2a0a5209dd-0a2a4504ce8e-24
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:04:01 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a71f151-b57f-0a2a45040019-d1558029a5ee-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:04:01 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-495437bb891so9046985e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 07:04:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b4bdc7sm199977865e9.0.2026.08.04.07.03.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 07:04:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785852241; x=1786457041; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=AK/eiZ5xlog3jlcYi/mBuAqCNsuak+f8+DnZSCJJgmE=;
        b=AsYxcn3atE77CQUSyAgY7ox4yngG2SLKc026pY1kHAQS9c17bkO+VBdlb2wS+rrkDq
         odpxhq9dWqwq01AZ4+5yxsB3QMyQ7ZDRfnkyWtCbsRRUsVhaoEIltkjW2WvzJ6vj0qL7
         ifmIBMBmHlcblItHz9/kXzL1zfqjuboGJdfAAmIlRWYPtOus2/4Uk6POSJjq+RU1mIkx
         AgsINOt25+hJAGjbnRO5ELOjO7wQ+CRmagI9isFBhPYBpUQxqOBEMogQU4RKGVM9tHTC
         tV11CpIm0UwBkTTjMN0SU16wDvZHQzpPIg3q0a9bpW9Vx4LhFNJe8G27O+7WeA8ma0oh
         6bWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785852241; x=1786457041;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=AK/eiZ5xlog3jlcYi/mBuAqCNsuak+f8+DnZSCJJgmE=;
        b=NDmExA5CmsBroUQ7/zXCohYOu2e//n8b2ehmm2TJGia5xHWUnblsuU5/m7SH1htCfC
         E68m7SG7J0yYE6CrtPQC6iz3eKfDQ2Zt7aPicdXjL6G6PRs/bN6JEZczw1tiQWZzMsGt
         W81Cxl8jbGmhwOwl1PHLAb2WF0MAukNDRGhif8uGWD6/UAiffsdheqxOjR/+RSPLELw2
         EYNXrM958exHfGpthSnKZ6TZ2cCQ9vKBkI1aLTHWMWiqcFGukSLOSjITg4tng/r/BrKu
         l5twmYPTuDrW9s5cWCWn09dF5FI9LoHXPnq5pySdoPa455h/2/5KpFYuCTPXCS55Qyg/
         ptiw==
X-Forwarded-Encrypted: i=1; AHgh+RpWpslPWCtnRJJP810r6CtWHShp2P3f2JpLXiC00LTBuqBP8WmfEnWaYdKrJxTFpsAcypqJsEYGPiw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwI1jIThXmv9/sMiXVkoZTO+UqCYnF6QgwoTHRN0GiFfMAmNs2R
	EyrQnxUgR5Vo8a8UAwAbJwRuTfBtoC9Zcy6Kv+TwJ57kOY8GSYpZKdbz4A3tgj3Xuw==
X-Gm-Gg: AR+sD13Fj+lTWadIxO/jwVcIAKOxheX5RRTCBqFBze2scjKHgvIpmpEe93hnd3iApkS
	Q8fWlw3KGj25cuutkzB05iZf6C5ueYPBJBwZmR81MJETIkCFg3gTaN+9ug6tsWKewQdtE1Fg+eY
	/4JlWMPLu1TEiNommKVCtt7pM72RjiyPv+lwp4uPMQqAXOXjaeZIToHACldm7MfmiRvEoNGWkV/
	eUlxEAiD24t9vYM1HE8vrbdKNZjkjqB+GrrB0aMtKPmKIWLtbPS4plzMyp9pZDMNYR1JSsPHiYi
	FevlUINGWj7EJHvecj4AFgWMRqc/yRdFWVmtDq7+jMFDLeZ5pjUe7kUYgSe28tY+o9VD1//EkQz
	PnZUirjJKgauMfWq85dcfNaDmmmxz1RE2ANYanXFeJDPlsVCAIwaK7nC6Qjwa2Yz+bsp8QHc190
	jvuIb54d5o/dPBW1rBKtu5M5aJzuSGUa1nYdrX9F4kOosoCzRRSv1GUNpBF0t575eSPJueijEtU
	fhXDvJxG0NiICwYGc4eP76kiGlAYLxLIMmBdfJL/3cl0fHToF+db0PRXl7RI3g=
X-Received: by 2002:a05:600c:1987:b0:495:69eb:27d3 with SMTP id 5b1f17b1804b1-4994a101e6cmr70831905e9.8.1785852240938;
        Tue, 04 Aug 2026 07:04:00 -0700 (PDT)
Message-ID: <36859779-a6c1-448b-91ae-511ada7260fe@suse.com>
Date: Tue, 4 Aug 2026 16:03:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] x86/EFI: replace ebmalloc()
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Julien Grall <julien@xen.org>, Stefano Stabellini
 <sstabellini@kernel.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Teddy Astie <teddy.astie@vates.tech>,
 Marek Marczykowski <marmarek@invisiblethingslab.com>,
 Daniel Smith <dpsmith@apertussolutions.com>
References: <31ba7ff2-a42d-44aa-976c-17fbff44a56f@suse.com>
 <98388998-c5c6-4991-8662-2b4bf25188f2@suse.com>
 <2eb924b2-11fd-45be-b933-c6352fb2dfe0@citrix.com>
 <d12a6815-612d-4cf6-af50-8370d1ff4108@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <d12a6815-612d-4cf6-af50-8370d1ff4108@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1785852241-506DAB50-DB12CCA5/0/0
X-purgate-type: clean
X-purgate-size: 3429

On 04.08.2026 16:01, Jan Beulich wrote:
> On 30.07.2026 20:08, Andrew Cooper wrote:
>> On 27/07/2026 11:20 am, Jan Beulich wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -31,6 +31,7 @@
>>>  #include <asm/alternative.h>
>>>  #include <asm/apic.h>
>>>  #include <asm/bootinfo.h>
>>> +#include <asm/brk.h>
>>>  #include <asm/bzimage.h>
>>>  #include <asm/cpu-policy.h>
>>>  #include <asm/e820.h>
>>> @@ -164,6 +165,8 @@ cpumask_t __read_mostly cpu_present_map;
>>>  
>>>  unsigned long __read_mostly xen_phys_start;
>>>  
>>> +unsigned long __ro_after_init brk_end;
>>> +
>>>  /* Only used in asm code and within this source file */
>>>  char asmlinkage __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
>>>      cpu0_stack[STACK_SIZE];
>>> @@ -1141,7 +1144,6 @@ void asmlinkage __init noreturn __start_
>>>      struct boot_info *bi;
>>>      unsigned long nr_pages, raw_max_page;
>>>      int i, j, bytes = 0;
>>> -    unsigned long eb_start, eb_end;
>>>      bool acpi_boot_table_init_done = false, relocated = false;
>>>      bool vm_init_done = false;
>>>      int ret;
>>> @@ -1511,7 +1513,7 @@ void asmlinkage __init noreturn __start_
>>>          /*
>>>           * This needs to remain in sync with remove_xen_ranges() and the
>>>           * respective reserve_e820_ram() invocation below. No need to
>>> -         * query efi_boot_mem_unused() here, though.
>>> +         * query brk_get_unused_start() here, though.
>>>           */
>>>          xen->start = virt_to_maddr(_stext);
>>>          xen->size  = __2M_rwdata_end - _stext;
>>> @@ -1654,18 +1656,11 @@ void asmlinkage __init noreturn __start_
>>>      if ( !xen_phys_start )
>>>          panic("Not enough memory to relocate Xen\n");
>>>  
>>> -    /* FIXME: Putting a hole in .bss would shatter the large page mapping. */
>>> -    if ( using_2M_mapping() )
>>> -        efi_boot_mem_unused(NULL, NULL);
>>> -
>>>      /* This needs to remain in sync with remove_xen_ranges(). */
>>> -    if ( efi_boot_mem_unused(&eb_start, &eb_end) )
>>> -    {
>>> -        reserve_e820_ram(&boot_e820, __pa(_stext), __pa(eb_start));
>>> -        reserve_e820_ram(&boot_e820, __pa(eb_end), __pa(__2M_rwdata_end));
>>> -    }
>>> -    else
>>> -        reserve_e820_ram(&boot_e820, __pa(_stext), __pa(__2M_rwdata_end));
>>> +    brk_end = brk_get_unused_start();
>>> +    if ( using_2M_mapping() )
>>> +        brk_end = PAGE_ALIGN_2M(brk_end);
>>> +    reserve_e820_ram(&boot_e820, __pa(_stext), __pa(brk_end));
>>
>> Hiding brk_end in setup.c like this is quite rude.  I guess it's because
>> you want to have brk.c be brk.init.o, but it really does live with the
>> other brk functions.
> 
> As said in reply to you comments on patch 1 - brk_end is purely an x86
> helper variable. I don't want it to move to common code.
> 
>> Furthermore, having brk_end right from the outset fixes the fact that
>> brk_get_unused_start() is doing things beyond retrieving a value.
>>
>> With brk_end being the real bump pointer the allocator uses,
> 
> Hmm, no - I don't view the variable as fulfilling that purpose.

In fact, to add to this, originally I had a variable of this purpose. It
simply didn't work out nicely, in particular because of the page alignment
which may need enforcing. (Surely it could be done like you say, but I'd
really prefer not to.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 14:27:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 14:27:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382214.1625581 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrG75-0001N6-Ci; Tue, 04 Aug 2026 14:27:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382214.1625581; Tue, 04 Aug 2026 14:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrG75-0001My-9C; Tue, 04 Aug 2026 14:27:27 +0000
Received: by outflank-mailman (input) for mailman id 1382214;
 Tue, 04 Aug 2026 14:27:26 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrG73-0001Ms-W0
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 14:27:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrG72-00Bvym-Fx
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 16:27:24 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a71f6c0-5cb7-0a2a0a5109dd-0a2a4504d054-40
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:27:23 +0200
Received: from [52.101.52.70]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a71f6ca-b57f-0a2a45040019-3465344686da-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:27:23 +0200
Received: from BLAP220CA0004.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:32c::9)
 by DM6PR12MB4217.namprd12.prod.outlook.com (2603:10b6:5:219::24) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Tue, 4 Aug
 2026 14:27:19 +0000
Received: from BL02EPF00029928.namprd02.prod.outlook.com
 (2603:10b6:208:32c:cafe::84) by BLAP220CA0004.outlook.office365.com
 (2603:10b6:208:32c::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.16 via Frontend Transport; Tue, 4
 Aug 2026 14:27:19 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BL02EPF00029928.mail.protection.outlook.com (10.167.249.53) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.292.8 via Frontend Transport; Tue, 4 Aug 2026 14:27:19 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Tue, 4 Aug
 2026 09:27:19 -0500
Received: from [172.19.79.34] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Tue, 4 Aug 2026 09:27:18 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DdejiW88sNJhAhZbXKWD0EyYZGNDAcuFlEfel4t62wJgjJ5gAu3tjUxfQjiluWWqUuIYdQzdBuuIpm5MXADKCQ+eWeNGCYw+VnoRLU2faqh4jJGur8Kh8Fps5o/HbKYonR0LdlwaVZzKsKEdVe1E8MLBNF2hEdFqPWPh3i1p1I055Me0nk1k8sYw7J92eiwWDlmGK3NNkgClV+vqFIY/TLyDCusNwlpsRPdx0hg4zgsJvjMrHINnWBOpl0H2g587sDqbIddFVVRG9SYQ6uZqm2+ckjLymP0uEvcOfgeXyaLftkqY82EXzYr/ftC9Pwg1t8vI5T2lnVBRpsmfVoeCEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nR4Is8OyR6I08GeGM3t3zaSmggdBeboOOSXRsCXiuVk=;
 b=NtR4D2chpsbSQNxJQIVU2OnNc6q7AAzDkyL7XMYVTj4XEmvpWE5AcMlT19WboYKnUWSf3xKi0fMgzjMIeAWszu18NR8GXd7K6zjJLXZ4Ul1dXel+JUPu2Rpxj1JndVMjVjNk8kcU4FmhkRSLr6w23eIQXgEjMmYZRrMD6oF84rS57edea8GK9WYU56y+Tghw+7zZ4Zmj0pBq+9V4aXXWZUCwzOdHYQMiJZNkts6i5Mzu2xGOOuL80xFCoc7yAr9y4sfckhlHxBpfBvspxBx+XSDIejFwS3nS5s4uKr0rGv9HIu9jZxP5IMJna8FD+MxoG/nVx7h2W831iUukVQfW3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nR4Is8OyR6I08GeGM3t3zaSmggdBeboOOSXRsCXiuVk=;
 b=vHikyjsjeR3BqxkivlzyWm4/uVVwGdnxTqPo9MC+VXy2wEZoWvkeT6sQKGpYfTLLBaWElJ1jogP255iNb3jsGVE2QiX94VAN7r91D5XFZyH5UvDs6FMT2MUWm7gLPKiZBHvBm/eyWFlhlUbjgadOWSsGrzZW3Oa9yA7XCKj98sc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <57bb7281-5898-4243-837a-1236b25e761e@amd.com>
Date: Tue, 4 Aug 2026 10:27:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>
CC: Daniel Smith <dpsmith@apertussolutions.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <bbc2fb48-d79e-4f00-81b4-0170dd910aaa@amd.com>
 <8097d8e8-42ec-463a-8247-56c9e4d834cd@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <8097d8e8-42ec-463a-8247-56c9e4d834cd@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF00029928:EE_|DM6PR12MB4217:EE_
X-MS-Office365-Filtering-Correlation-Id: cd2c43c3-4fbc-4524-3cc8-08def2347de7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|23010399003|376014|82310400026|1800799024|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	Gb+sXQlU8KCyB1mqweNeyt/qVLzsprrW7ckV3dZ4Rk54zeQBqjRzvkYZ5ovxHl0K2kb66SbZ08ewI3VJOq9KZFuAX2hXWxo/R7iOOu8iemw3uTstmAbfNLhoZd6TF+Kz+yTn+LGpOe5MeQ0/nEJbGwUA+l6riNOF89Ge6jmID3IwOQ3hNa4hU4LJ+tnZc6NFpBSq0rrO9lHOi8LPStD0meqaEGslYSg8EBlgAizNPXJ4VrdBjJmZexb/iMFWSG+UKYUz55AWiw6Ek9utGMWGaCEwMVCRe52InwhI9/SvyjW+qrD70tLkA2tAzR9pT+ahIVC9TOsEAjKV1Bj2PC0O++QBOJDoz1TM0TIA03j+ITDI8rheTYv+RkNfCQVjF6IVlnV/gIC/gk32RF02xD7hmr3yKeNoMQCsm3n8Z7H5/70Oyw4rLdPmYQmh/ggHJ1GCAcoZxb9V7etuSdFo4Z/2tz94zz8t0VmhlBa3ZvSCXexyEsXK4WWguzNVZQHq1UysfAZrbSEHBiSasyk/keU1QvXEOTaAt4eFFuD1DYrjYqcXXSEpwY7k9LKZb71Guok2q8P0M2EuF+85evkFvMkPYMCA12Qo6hoJnirP6OUTL+Whh+nIktll/PfHfSh9D15OhtwiiKpgqvOAW2eBAxHJOFML99ydPCowGYM3g5vXVSmlyscQO9gGHeohnhN0Kr1SQmug2Xl5ln0nn93KMbW5Iw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(376014)(82310400026)(1800799024)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	5GY+wQCayyJvmwVn4l5h/PIAoNhagbDpleGfOu/s/REXN4AwNoY1CeV3rB3UGNSDoEDJwOKSWCn0by4yq4I6OOxqUUNpriHUP66NinIWZhF+wk50TNa7qeLwtr3CCuTPgbJ2ZV+0CkwAAcIk7HoHsGXVr5rJXhydvKjIntZC1lMJdhNAN50OGM0iSSmjC9j4fRoiU3WTyAAfeGWpOfWamFgso5yigc/NpshFtAN06XExaPW1xEd222cb231T/FZ6mkAciEgLaOyYhF01zLwPk9z9X/lv9c4g9Pc5f1DC0qg8jRZK8AhzyrY6GfGbmuLaDTb4NIWvQ32+WIlhhAMNrXhOrMNF5CSp315zUxW+0ucIQbCBtvNxz6ZxJ/yUc/7wFNSYvTdxdo3ve9BBrXyPPw6FWtRr6vFbbzJqSrsW29S0Arb/2wTEazhiwEncUb1/
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 14:27:19.7286
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cd2c43c3-4fbc-4524-3cc8-08def2347de7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF00029928.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4217
X-purgate-ID: tlsNG-ebf023/1785853643-514D3B50-7B3FA852/0/0
X-purgate-type: clean
X-purgate-size: 3406

On 2026-08-04 03:53, Jan Beulich wrote:
> On 03.08.2026 23:01, Jason Andryuk wrote:
>> On 2026-07-28 09:22, Jan Beulich wrote:
>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>
>>> @@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
>>>    #endif
>>>    
>>>    #ifdef CONFIG_ARGO
>>> -static XSM_INLINE int xsm_argo_enable(const struct domain *d)
>>> +
>>> +static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
>>>    {
>>> -    return 0;
>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>> +    return xsm_default_action(action, current->domain, d);
>>
>> This one I think should be
>>       return xsm_default_action(action, d, NULL);
>>
>> Usually current is passed in for the check, but for domain_create() ->
>> argo_init() it is the under-construction domain.
> 
> And in that case we want to make sure that current->domain may enable Argo
> for d.

It's not a hook for current to enable for d, but more of a hook "is d 
allowed to use argo."

In the hypercall entry path, it use is clear - "is this domain allowed 
to make argo hypercalls."

In argo_init(), it is more of an optimization.  Only initialize if d is 
allowed to use argo.  I think this use is questionable, but it is the 
current code.

In flask, the source is d, the target is xen_t:
     allow domain_type xen_t:argo enable

So it is not an operation between domains.

>>>    }
>>>    
>>>    static XSM_INLINE int xsm_argo_register_single_source(
>>> -    const struct domain *d, const struct domain *t)
>>> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>>>    {
>>> -    return 0;
>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>> +    return xsm_default_action(action, d, t);
>>>    }
>>>    
>>>    static XSM_INLINE int xsm_argo_register_any_source(
>>> -    const struct domain *d)
>>> +    XSM_DEFAULT_ARG const struct domain *d)
>>>    {
>>> -    return 0;
>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>> +    return xsm_default_action(action, current->domain, d);
>>
>> Similarly:
>>       return xsm_default_action(action, d, NULL);
>>
>> The single call is:
>> xsm_argo_register_any_source(currd);
> 
> There being just a single call puts this on the edge. If there was another
> one not passing current->domain, I think the same argument as above would
> hold here. And the general concept is what I think should matter when
> writing the dummy implementations.

For flask, we have xen as the target again:
     allow domain_type xen_t:argo register_any_source;

... since a wildcard ring doesn't have a known target domain.

>> These argo hooks all pass in their arguments explicitly, so I think we
>> should do that and not use current.  (The send and register hooks could
>> use current, and that could make sense as those map to hypercalls.  But
>> it is correct today with the explicit arguments.)
>>
>> With the changes:
>> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> 
> Thanks, but no - unless I misunderstand how permissions are intended to
> work here, I don't think I can make the changes requested, and hence I
> can't apply the R-b.
Understandable.

It seems to me that the XSM hooks have two styles.  Either implicit args 
(using current) or explicit args.  Today, the argo hooks take explicit 
like the grant hooks for instance.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:31:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:31:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382237.1625588 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrH6e-00043a-Q2; Tue, 04 Aug 2026 15:31:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382237.1625588; Tue, 04 Aug 2026 15:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrH6e-00043T-Mh; Tue, 04 Aug 2026 15:31:04 +0000
Received: by outflank-mailman (input) for mailman id 1382237;
 Tue, 04 Aug 2026 15:31:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <cody.zuschlag@xenproject.org>) id 1wrH6d-00043N-P7
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:31:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <cody.zuschlag@xenproject.org>) id 1wrH6d-004pGb-2q
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:31:03 +0000
Received: from mail-lf1-f42.google.com ([209.85.167.42])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <cody.zuschlag@xenproject.org>) id 1wrH6d-00AukV-1u
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:31:03 +0000
Received: by mail-lf1-f42.google.com with SMTP id
 2adb3069b0e04-5b013aa02b2so1298592e87.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:31:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:To:Subject:Message-ID:Date:
	From:MIME-Version; bh=wUnWfLwtyqKHjxc5MZcvpzA2F49Qe7vEZ46gubm6ZLI=; b=0UzYp0W
	OJVmRrw3XaohqaeIDfpxYTdqiMx/jYZxPmQgvohnJMlghlOx8oar0Pjm4ZB+1N+ulPQnS8Oz1DEtc
	JegPQ/l5Om4AiEoHEU/S2SENKfVDHq8HTaZUah0EjTb4IFI/O6Mia3kxevCO2MnYUWb5x0widSwFc
	Ec9TIvYFU4=;
X-Gm-Message-State: AOJu0Yxap6+y+HvC260fpNqEBXBFd+91DRr27+E/aMSm6so7sKPXsv8J
	RDFMggEggYJiyE/J9PqN23K2te8hF3M/TaCvZHbFF2VMkTkteyVqhVgI/28OLu9IcPbI/5ZlbzO
	wfZi5MULUTX28OFUhpqvgfAizM+g5Fbg=
X-Received: by 2002:a05:6512:3b90:b0:5b0:1e26:7751 with SMTP id
 2adb3069b0e04-5b2ee5e4dbbmr1249418e87.8.1785857462436; Tue, 04 Aug 2026
 08:31:02 -0700 (PDT)
MIME-Version: 1.0
From: Cody Zuschlag <cody.zuschlag@xenproject.org>
Date: Tue, 4 Aug 2026 17:30:50 +0200
X-Gmail-Original-Message-ID: <CAJbE=KznNsrNRN=pUaDj7-TVW4uCMVBdrPpei_z5nBdjdHnVag@mail.gmail.com>
X-Gm-Features: AUfX_mz1wVMRUzsBvMVX98GLu2pW70C6sFQH8l8wnmnEUy5iBrUe5l1BBD3W3oM
Message-ID: <CAJbE=KznNsrNRN=pUaDj7-TVW4uCMVBdrPpei_z5nBdjdHnVag@mail.gmail.com>
Subject: [ANNOUNCE] - Call for agenda items for August 6 Xen Community Call @
 15:00 UTC
To: xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="000000000000ab072206583a57bb"

--000000000000ab072206583a57bb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

It's time for the August Xen Project Community Call, happening this
Thursday, 6 August at 15:00 UTC.

Whether you have updates to share or just want to listen in, we'd love to
have you join. It's a great opportunity to hear what the community has been
working on, discuss ongoing project activities, and catch up on recent
developments.

*Preparation*

=F0=9F=91=89 Please take a few minutes to review and update the agenda befo=
re the
call:

https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/

Feel free to:
- Add topics or project updates
- Suggest anything we can drop or defer
- Include links to patches, mailing list threads, or documentation where
helpful

The agenda also includes the meeting link and a link to find your local
meeting time.


*Call Details*
Date: Thursday, 6 August 2026
Time: 15:00 UTC (agenda starts at 15:05 UTC)
Join: https://meet.jit.si/XenProjectCommunityCall

We'll open the room at 15:00 UTC and begin the agenda at 15:05 UTC to give
everyone a few minutes to join.

Want to be CC'd on future community call announcements?

Add or remove yourself from our sign-up sheet:
https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/

See you on Thursday!

Best regards,

Cody Zuschlag
Xen Project - Community Manager

--000000000000ab072206583a57bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi everyone,<br><br>It&#39;s time for the August Xen =
Project Community Call, happening this Thursday, 6 August at 15:00 UTC.<br>=
<br>Whether you have updates to share or just want to listen in, we&#39;d l=
ove to have you join. It&#39;s a great opportunity to hear what the communi=
ty has been working on, discuss ongoing project activities, and catch up on=
 recent developments.<br><br><b>Preparation</b><br><br>=F0=9F=91=89 Please =
take a few minutes to review and update the agenda before the call:<br><br>=
<a href=3D"https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/">=
https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/<br></a><br>F=
eel free to:<br>- Add topics or project updates<br>- Suggest anything we ca=
n drop or defer<br>- Include links to patches, mailing list threads, or doc=
umentation where helpful<br><br>The agenda also includes the meeting link a=
nd a link to find your local meeting time.<br><br><b>Call Details<br></b><b=
r></div><div>Date: Thursday, 6 August 2026<br>Time: 15:00 UTC (agenda start=
s at 15:05 UTC)<br>Join: <a href=3D"https://meet.jit.si/XenProjectCommunity=
Call">https://meet.jit.si/XenProjectCommunityCall</a><br><br>We&#39;ll open=
 the room at 15:00 UTC and begin the agenda at 15:05 UTC to give everyone a=
 few minutes to join.<br><br>Want to be CC&#39;d on future community call a=
nnouncements?<br><br>Add or remove yourself from our sign-up sheet:<br><a h=
ref=3D"https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/">http=
s://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/</a><br><br>See y=
ou on Thursday!<br><br>Best regards,<br><br></div><div><img src=3D"https://=
ci3.googleusercontent.com/mail-sig/AIorK4x5nkRDCOFJDJAv9aMXdZ0mghItsp3D36Jr=
wBCQtitBSW_0NeDS6mBmJ2F4vZVE2oBOqnY6IaJUrl12" style=3D"background-color: tr=
ansparent;"></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smar=
tmail=3D"gmail_signature"><div dir=3D"ltr"><div>Cody Zuschlag</div><div>Xen=
 Project - Community Manager</div></div></div></div></div>

--000000000000ab072206583a57bb--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:39:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:39:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382248.1625598 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHF5-00053D-Fc; Tue, 04 Aug 2026 15:39:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382248.1625598; Tue, 04 Aug 2026 15:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHF5-000536-Cv; Tue, 04 Aug 2026 15:39:47 +0000
Received: by outflank-mailman (input) for mailman id 1382248;
 Tue, 04 Aug 2026 15:39:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrHF3-000530-Nq
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:39:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHF3-00FjQT-1K
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:39:45 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72079c-bab6-0a2a0a5309dd-0a2a45048a62-44
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:39:44 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7207c0-b57f-0a2a45040019-d155dd36b9c3-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:39:44 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-47f84023916so4588659f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:39:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23ec3asm551990f8f.31.2026.08.04.08.39.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 08:39:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785857984; x=1786462784; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=2toUDhZyEbbG0kKRohXauBWdzsUJgpoNHOwbrQ7ecrY=;
        b=M9BRdTf5M3TFz626lH0amRKEftLvy7JVlaGDDh563EyJBgyJtqJVRpcoCPQpkjUltx
         AGK/PEQSL2vFZ5/fkVm1H2wKz0qnSdzt85ngwNvBsulyodKDEfwsoUQlgS+jorOfep3v
         iE4xLQ3VK/SHrldhqzUNXbjWHH1v7QLgTlWm3OYJCbbSVyYBi9R+WluTh8NouBL0or1u
         xxRVY3y909A8UoA0bzl7Eu79c2GI8A9iQ5cY0GHuD0GPo79Ap5SBDefztlAudftVYhqh
         q1xQrV6JoDl4JHvAo/LaUJkfgJk+UUbjPVvZey858VNRWP4ofS/NMdETyC/qobg7JZKp
         gNMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785857984; x=1786462784;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=2toUDhZyEbbG0kKRohXauBWdzsUJgpoNHOwbrQ7ecrY=;
        b=HCVGrLg343fnvOtFK7X3Igtr9WRpVgqSl7THz67kLAYasI2F5qI1tonEpobMAXzgp/
         oTvDvHy1z41IqRqLOSOXFjG3vsHDw39oJZRhnqXnYKJdz+3IQI2QQHj9lo9ZS1EFPXam
         V1XjN0uFZDa/EIKk5z1U9wzkDOaj7ZsLowz5k6CDzniB7BEyInAcpA2Ai8xLqqyhFxpF
         HuVo2omTbkuWfJ35/zz5m0zTghrvMROA/GUg9yEsobm/3AJXoBFZftcKjV1RByImw8vo
         ND6nMY0PCIM17d9fx/jEMchqxDrBi81K9KJDrNbHN0WXW4X0GzRQ2tS1/WyRKC6fei1n
         55Vg==
X-Forwarded-Encrypted: i=1; AHgh+RqTIIwAEgcHBusoK7XsLmPyEyJSx3Dv1gCmfBPUol/jqGZLdVgDGeo189Zj8EQwD7sEokFzTlzPw7o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZQlX+CFJLp7bCCy3C+3kSfiqIbnLZ6bS3mTVniQNDs4TBJ2N1
	IVGTZPSpAo44BbUeGZvway7i+kny2yTzi67kX2MZ5+ZlBv4zuMwnAtSHTc4EUT4zcA==
X-Gm-Gg: AR+sD10ptemqVp5oEzIwu29sf7+23L1gXDX9Mjq2T0m5L5Z/B/C3/8SD7kEOIJsyc1N
	rfMluDtNIchAjxc3Gkra2WnNE0oC1KxvyiMGkmaKcMvHgkJiPZMwrV9Vqwi6KbTQizGWzzegkcl
	Nzvt9ApJnEoF/+x+oZG7Qy5Kg+5hS73Mg1aihHtUW6AvvJdvuMQf6MpPhfnIoeN8ZtezaWSvlyx
	iIqLAMFSYLSI4QBrstzwL2Iqg/n208g6+wcea6/2MRv/AR1iMpyS+U137LB099Kqdbnmx50AIjJ
	JJ8t64AE8EsYHfJ+JOQBpl996MGOouKsD4KpcWj+WdwCzhvlaCDuhhA4pwhSE15pg6s9Zc2v7OO
	AXpzwZXA4sQftIwrlCGhdpJs9u4kb1cVCOlUaNbi3+cZYOBijHk7yPzAuTIQVJeCJimCmKg8Y37
	nkGqjbrMMIH3WszaDlVtHWgNqAIFwwS0GjdW92rxoJCg8TBP6hVu+IQ1JOnlNvwbPAo/iXxc8k/
	aJEmqE0iY4ZexljztdNs83EMOcJmWo8t1+IJtbDIlrSmpLVxqX2
X-Received: by 2002:adf:fec7:0:b0:47e:81aa:3832 with SMTP id ffacd0b85a97d-47fec519ff8mr221710f8f.16.1785857984304;
        Tue, 04 Aug 2026 08:39:44 -0700 (PDT)
Message-ID: <0b892cfe-0a7d-4e7f-b7f6-4fc2575762ac@suse.com>
Date: Tue, 4 Aug 2026 17:39:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/5] x86/emul: Introduce x86_decode_lite()
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-2-andrew.cooper3@citrix.com>
 <01b27228-fdc0-4546-aa23-2bcdafb22727@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <01b27228-fdc0-4546-aa23-2bcdafb22727@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1785857984-528C9B50-3F73523E/0/0
X-purgate-type: clean
X-purgate-size: 5585

On 03.08.2026 17:26, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
>> @@ -0,0 +1,330 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#ifdef __XEN__
>> +# include <xen/init.h>
>> +# include <xen/livepatch.h>
>> +#endif
>> +
>> +#include "private.h"
>> +
>> +#undef ModRM
>> +
>> +/*
>> + * Bare minimum x86 instruction decoder to parse the alternative replacement
>> + * instructions and locate the IP-relative references that may need updating.
>> + *
>> + * These are:
>> + *  - disp8/32 from near direct branches
>> + *  - RIP-relative memory references
>> + *
>> + * The following simplifications are used:
>> + *  - All code is 64bit, the instruction stream is well formed and safe to
>> + *    read.
>> + *  - Instruction groups and prefixes not used by Xen's current alternatives
>> + *    are not implemented in order to reduce the decode complexity.
>> + *  - Certain instructions are intentionally not recognised, when it is more
>> + *    likely for their presence to be an error than intentional.
>> + *
>> + * Inputs:
>> + *  @ip  The position to start decoding from.
>> + *  @end End of the replacement block.  Exceeding this is considered an error.
> 
> Why do you mention replacement blocks here? Are we entirely set on this
> code not possibly gaining any purpose beyond the scanning of those?
> 
>> + * Returns: x86_decode_lite_t
>> + *  - On failure, length of 0.
>> + *  - On success, length > 0.  For rel_sz > 0, rel points at the relative
>> + *    field in the instruction stream.
>> + */
>> +x86_decode_lite_t init_or_livepatch x86_decode_lite(void *ip, void *end)
> 
> Is there a reason the parameters can't be pointer-to-const? Hmm,
> apparently for x86_decode_lite_t's "rel" field not be plaing void *, "ip"
> needs to be this way as well. But not "end", I don't think.
> 
>> +{
>> +#define Imm8   (1 << 0)
>> +#define Imm    (1 << 1)
>> +#define Moffs  (1 << 2)
>> +#define Branch (1 << 5) /* Near direct branches, which have a displacement */
>> +#define ModRM  (1 << 6)
>> +#define Known  (1 << 7)
>> +
>> +    static const uint8_t init_or_livepatch_const onebyte[256] = {
>> +
>> +#define ALU_OPS(x)                              \
>> +        [(x) + 0] = (Known|ModRM),              \
>> +        [(x) + 1] = (Known|ModRM),              \
>> +        [(x) + 2] = (Known|ModRM),              \
>> +        [(x) + 3] = (Known|ModRM),              \
>> +        [(x) + 4] = (Known|Imm8),               \
>> +        [(x) + 5] = (Known|Imm)
>> +
>> +        ALU_OPS(0x00) /* ADD */, ALU_OPS(0x08) /* OR  */,
>> +        ALU_OPS(0x10) /* ADC */, ALU_OPS(0x18) /* SBB */,
>> +        ALU_OPS(0x20) /* AND */, ALU_OPS(0x28) /* SUB */,
>> +        ALU_OPS(0x30) /* XOR */, ALU_OPS(0x38) /* CMP */,
>> +
>> +#undef ALU_OPS
>> +
>> +        [0x50 ... 0x5f] = (Known),             /* PUSH/POP %reg */
>> +
>> +        [0x62]          = 0,                   /* BOUND, but also EVEX prefix, not implemented. */
>> +        [0x63]          = (Known|ModRM),       /* MOVSxd */
>> +
>> +        [0x68]          = (Known|Imm),         /* PUSH $imm */
>> +        [0x69]          = (Known|ModRM|Imm),   /* IMUL $imm */
>> +        [0x6a]          = (Known|Imm8),        /* PUSH $imm8 */
>> +        [0x6b]          = (Known|ModRM|Imm8),  /* PUSH $imm8 */
>> +        [0x6c ... 0x6f] = (Known),             /* INS/OUTS */
>> +        [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */
>> +        [0x80]          = (Known|ModRM|Imm8),  /* Grp1 */
>> +        [0x81]          = (Known|ModRM|Imm),   /* Grp1 */
>> +
>> +        [0x83]          = (Known|ModRM|Imm8),  /* Grp1 */
>> +        [0x84 ... 0x8e] = (Known|ModRM),       /* TEST/XCHG/MOV/MOV-SREG/LEA */
>> +        [0x8f]          = 0,                   /* Grp1A - POP but also XOP prefix, not implemented. */
> 
> POP doesn't look all that unlikely to be used in inline assembly, and
> hence in alternatives. That said, of course using it with a memory
> operand requires quite a bit of care. I don't see you excluding the
> PUSH counterpart, though - being consistent for any such pairs would
> seem somewhat desirable.
> 
>> +        [0x90 ... 0x99] = (Known),             /* NOP/XCHG %rAX/CLTQ/CQTO */
>> +
>> +        [0x9b ... 0x9f] = (Known),             /* FWAIT/PUSHF/POPF/SAHF/LAHF */
>> +        [0xa0 ... 0xa3] = (Known|Moffs),       /* MOVABS */
>> +        [0xa4 ... 0xa7] = (Known),             /* MOVS/CMPS */
>> +        [0xa8]          = (Known|Imm8),        /* TEST %al */
>> +        [0xa9]          = (Known|Imm),         /* TEST %rAX */
>> +        [0xaa ... 0xaf] = (Known),             /* STOS/LODS/SCAS */
>> +        [0xb0 ... 0xb7] = (Known|Imm8),        /* MOV $imm8, %reg */
>> +        [0xb8 ... 0xbf] = (Known|Imm),         /* MOV $imm{16,32,64}, %reg */
>> +        [0xc0 ... 0xc1] = (Known|ModRM|Imm8),  /* Grp2 (ROL..SAR $imm8, %reg) */
>> +
>> +        [0xc3]          = (Known),             /* RET */
>> +        [0xc4 ... 0xc5] = 0,                   /* LES/LDS but also VEX prefixes, not implemented. */
> 
> This may bite us sooner or later, due to the VEX-encoded integer insns
> that there are. Of course as long as we don't use this function on
> compiled code, and as long as my "x86: allow Kconfig control over psABI
> level" doesn't come close to going in, that's merely a theoretical
> concern.

Actually perhaps sooner - we're meaning to use MSR-IMM insns after all, if
I'm not mistaken.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382262.1625614 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNP-0006xa-Mz; Tue, 04 Aug 2026 15:48:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382262.1625614; Tue, 04 Aug 2026 15:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNP-0006x3-GR; Tue, 04 Aug 2026 15:48:23 +0000
Received: by outflank-mailman (input) for mailman id 1382262;
 Tue, 04 Aug 2026 15:48:23 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNO-0006uJ-Sj
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNO-009Gcw-9m
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:22 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c5-bab6-0a2a0a5309dd-0a2a4509cbee-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:22 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c6-be1a-0a2a45090019-d155802ba947-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:22 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-4954a9e8490so6653095e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858502; x=1786463302; 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=eQRAf5Du6pYWboeiDXqOeIZI6NQJ2iFJlkGQQHsxk/w=;
        b=M4Hnq68nWPuVsC7lwgbAoKk1HmzP+ekLiazSJ9amNCGZrUyd5PPFNyX4ZACZhyInPB
         +FPOcowBJDZvRU6z43RqtTb8wOZXe1LM685hOsXwkbT6xY329trAZuihjeobWc6m3MKW
         y3QQYIN+8S937Xn7IVM/4lUsRywVLRPxXl7PaFtb90k3zIrs2eqS2MCghJKQZtfQzK3c
         sIVnSqsCnz0bqNndrHGG4sPNpli+AFMnZORD2ylnLg6jpT0QWLHZ0IOWfq7NWPceq+0t
         N7jG/aj0tUDzTPm8Y0hKHUMJAzZimT2lDxACqPjtA1z4cMgBY8VSfTZpB9UyXDo/nxHc
         JNLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858502; x=1786463302;
        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=eQRAf5Du6pYWboeiDXqOeIZI6NQJ2iFJlkGQQHsxk/w=;
        b=oIekdbC+hCOxA0FU1+lFisS8TfuYcEW3ikZSnXYdJmsbl9rWolqudbhAmXWGMBx3Bm
         IrR9k4U2EweMJ73p5qg1XCe4y6aWpeNibKE/GIGOQO1M/AUYh8JXnePYqwYjhVc2ZaMw
         rujDOie4q+83coloujMuHnAtOjaS8zLJJ9pCrI7qnRNsP34IQADK8G6GlIDJOHVBeRaF
         Rfgn8tw5hYfGMo61rJYbaEqOoxn3LuqOlQqA1iKBuLEnbRrgkCnlRXmSeI3Bnoebbf0O
         XCpsW4/L1mDP6Jl95qkh7O6f9Z8oACi5FiG3K0f0OsL3Xp40BQvW/2BopPzEPFt4dCVq
         kVeQ==
X-Gm-Message-State: AOJu0Yzo339f+YbOXfILuBoS12MiOE/viBqYPXB71j9zMh7aj+ky2JY6
	fN2UiHKXahhUzozcqbWnnF51XDwAl485uvoguhLk+Ywz4EQxTU8HS1VUXKrVjQ==
X-Gm-Gg: AR+sD100IJ8y2i4hca2J14u2pOK/D7zXXYUqTTQNuqtmEsyGitmNSSIsWe1nMjC+K5A
	VxPFDRxjIUoK12QeTltI43lg3wvWiBrfoGUK2puunVJkRdMkSKMemUlJX1vpKrXd8B/DWwqQh1e
	aA8czR96T+f09XUbP5kgq2cLk2LsX0s6KD1Ar2JrZ3zSEl2ZLHCF9QPAF+KVUQQPTZe4TE/ZuWZ
	7L+yx0gsdVlVeKkwPHeY0SE0/+/ALW2yuhB3jydRpk/uO+wUariM2JBpqsWc3GTqzK0gm8lACy2
	OjsPPhS/iwatyvc1ImUiv8dKoGVN++a41NCtkFLTwWh5gM43roQkYfF6DqcNfVE0sgzcMMVtkhw
	rRwlmDUdQ42FCNzYGnrrzHfN6+sQYC/UScNIqZOxMxXYg56sXXgS1QIYzzyVLGoxvxPdvH+WsBR
	rJxf1TT2/7ylNlo8xnU1hGLGspKJKwePDy0ZAo0RDuGYsOFrQ3r1jGGlTmRDBTRkj0xIEFiXSio
	I6UZmZU5Q19aHIVRImmTZzCatp2tj+FWw==
X-Received: by 2002:a05:600c:3ba6:b0:495:3a52:71b1 with SMTP id 5b1f17b1804b1-4994e374ad3mr1342475e9.5.1785858501675;
        Tue, 04 Aug 2026 08:48:21 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v7 02/20] xen/dom0less: turn max_init_domid into a common variable
Date: Tue,  4 Aug 2026 17:47:52 +0200
Message-ID: <6cd23822f5427a67f8f77300b09bc78d65a1d317.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785858502-BE6DA034-95C89CCA/10/73395122804
X-purgate-type: spam
X-purgate-size: 5825

Until now every architecture carried its own notion of max_init_domid:
Arm defined a real variable (declared in asm/setup.h, defined in
setup.c), while ppc, riscv and x86 each provided a "#define
max_init_domid (0)" stub in their asm/setup.h. This duplicated the same
declaration across all arches and placed a purely dom0less concept in
arch setup headers.

Now that the dom0less build code lives in common (xen/common/
device-tree/dom0less-build.c sets max_init_domid, and the console
serial-input switcher reads it), there is no reason for the symbol to be
per-arch. Provide a single declaration in <xen/dom0less-build.h>, with
the !CONFIG_DOM0LESS_BOOT stub kept there as well, so there is one source
of truth and the arch headers no longer need to mention it. Update
console.c to include <xen/dom0less-build.h> for the declaration instead
of relying on asm/setup.h.

Place the definition in xen/common/domid.c rather than in dom0less-
build.c. The latter is built as dom0less-build.init.o, i.e. the whole
object is relocated into the .init.* sections and freed after boot,
whereas max_init_domid must outlive boot because it is read at runtime
by the console serial-input switcher. domid.c is always linked (obj-y)
and resides in regular (non-init) sections, so it is a correct home for
the variable. It is marked __ro_after_init since it is only updated
while creating boot-time domains and read-only afterwards, and guarded
by CONFIG_DOM0LESS_BOOT as domid.c itself is unconditional.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Add Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v4:
 - New patch.
---
---
 xen/arch/arm/include/asm/setup.h   | 2 --
 xen/arch/arm/setup.c               | 2 --
 xen/arch/ppc/include/asm/setup.h   | 2 --
 xen/arch/riscv/include/asm/setup.h | 2 --
 xen/arch/x86/include/asm/setup.h   | 2 --
 xen/common/domid.c                 | 5 +++++
 xen/drivers/char/console.c         | 1 +
 xen/include/xen/dom0less-build.h   | 7 +++++++
 8 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 0adfa4993a8f..2af780512540 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
     struct rangeset *irq_ranges;
 };
 
-extern domid_t max_init_domid;
-
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
 
 size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6310a47d68b6..86532d0a35b6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -62,8 +62,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
 bool __read_mostly acpi_disabled;
 #endif
 
-domid_t __read_mostly max_init_domid;
-
 static __used void noreturn init_done(void)
 {
     /* Must be done past setting system_state. */
diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
index e4f64879b68c..956fa6985adb 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
 #ifndef __ASM_PPC_SETUP_H__
 #define __ASM_PPC_SETUP_H__
 
-#define max_init_domid (0)
-
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
index 2215894cfbb1..73ce2f293348 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,8 +5,6 @@
 
 #include <xen/types.h>
 
-#define max_init_domid (0)
-
 void setup_mm(void);
 
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index b01e83a8ed9f..5925c5f39cff 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -68,6 +68,4 @@ extern bool opt_dom0_verbose;
 extern bool opt_dom0_cpuid_faulting;
 extern bool opt_dom0_msr_relaxed;
 
-#define max_init_domid (0)
-
 #endif
diff --git a/xen/common/domid.c b/xen/common/domid.c
index b0258e477c1a..cd46cf952be6 100644
--- a/xen/common/domid.c
+++ b/xen/common/domid.c
@@ -9,6 +9,11 @@
  */
 
 #include <xen/domain.h>
+#include <xen/dom0less-build.h>
+
+#ifdef CONFIG_DOM0LESS_BOOT
+domid_t __ro_after_init max_init_domid;
+#endif
 
 static DEFINE_SPINLOCK(domid_lock);
 static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ea4e3ff34178..4c735cc04c67 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,6 +31,7 @@
 #include <xen/warning.h>
 #include <xen/pv_console.h>
 #include <asm/setup.h>
+#include <xen/dom0less-build.h>
 #include <xen/sections.h>
 #include <xen/consoled.h>
 
diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-build.h
index 4118dec76c0a..8d4da16d1f0a 100644
--- a/xen/include/xen/dom0less-build.h
+++ b/xen/include/xen/dom0less-build.h
@@ -5,6 +5,8 @@
 
 #include <xen/stdbool.h>
 
+#include <public/xen.h>
+
 struct domain;
 
 #ifdef CONFIG_DOM0LESS_BOOT
@@ -13,6 +15,9 @@ struct boot_domain;
 struct dt_device_node;
 struct kernel_info;
 
+/* Highest domain ID assigned to a boot-time (dom0less) domain. */
+extern domid_t max_init_domid;
+
 /*
  * List of possible features for dom0less domUs
  *
@@ -72,6 +77,8 @@ static inline bool is_dom0less_mode(void)
 }
 static inline void set_xs_domain(struct domain *d) {}
 
+#define max_init_domid 0
+
 #endif /* CONFIG_DOM0LESS_BOOT */
 
 #endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382264.1625629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNT-0007OD-8s; Tue, 04 Aug 2026 15:48:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382264.1625629; Tue, 04 Aug 2026 15:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNT-0007Nn-3o; Tue, 04 Aug 2026 15:48:27 +0000
Received: by outflank-mailman (input) for mailman id 1382264;
 Tue, 04 Aug 2026 15:48:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNR-0007Jx-N4
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNR-009QIN-3r
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:25 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209be-e002-0a2a0a5209dd-0a2a45019e90-12
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:24 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c3-5984-0a2a45010019-d155802eb5f8-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:19 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49557167508so30589855e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785858499; x=1786463299; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=o7cNA0aHmLQVev9D/olk7PT2DhodkPFOY5f8VX+59pM=;
        b=dmWnQZo5Or7MRVLwxgJ/DupYW4q392r8kLcL0g+zRkYKBeA/WkUkZu1VcF13TLyg3D
         g5CIOvYcgXHUpgQKZPXoJgQ7VEM5nMAsIvOsBG074qIw74WEdcixztfOCaBsWXj+IYWv
         qjnaq502QKcPJ9UebV7hTwptKZj2GdII3evo1cHTdePmSaxRxUin8+E9DU4Z1Tgv/s8f
         ps9JBPczNom4ckhMXRzVrWPUSWiJUiDI4RlJxcRMxnLkDpuOJblOPND26E5zIUeN4VN7
         W44xCwVD998BcorEvVtwoG38kcQCy7yFTG6aiELDRBLg41+Cq5SDzSP6VDg4ud79L5zf
         shuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858499; x=1786463299;
        h=content-transfer-encoding:content-type:mime-version: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=o7cNA0aHmLQVev9D/olk7PT2DhodkPFOY5f8VX+59pM=;
        b=WLrLQlW/7QB0TiX+TE0VyfVj4x1XLVwQTxiZc3WD+F6lKMgvg0kgQMzZkQJDcDLxBG
         AEpCLfEDqTbGZwi7BPgaa4O2fVgiDdqQddLtSs7I3G8+fiTLmkW4VRWCUs/uPSKm09/H
         /2sp7e17bPOvAwB3Cg2xkz2p7DRtsjtTpu3E/brokcCxDQlLwEDex37b7E4k1KjhFV/1
         2nBqRKkTzETOj7rh9w7tHQY90IxJhwNdE7Ye3APT2f+fh07F2WEeyTmuaEi+tdXU9Ux8
         uLunV7wkIA3jF3zeeV3Pp1vWmXiszA29S6JI626WEWNn/Rfo64UBu+upyABOMeTa97xj
         HBPw==
X-Gm-Message-State: AOJu0YzMJ2q1W+qodhMz6llCNWMoYFI8AJni4Fm/dVF86vSqk6ZkSqF/
	SYbaFoGBH7WSUD/gux+iK/Bl4liV88KaYmkHBAGObG2ePXxuUa+GTUw+UN1dFw==
X-Gm-Gg: AR+sD11MA3lz9Fmicg/476+ZAqJbU4m2t/Br7vj0jnAC8heiUBBxWMuMWUf07QFfQPS
	dzYJ6CB50ZEyEP+MftDSHfM02gJjsPDx890qmXeRjioRfssBqtnfoATsVDik2sV8y6ma5oK17GA
	liW/j7ULqX9lx6MkBepla15RK+TzNhh9vcrWiIAvs+C9o8/pZ+3Lw9joMwTAhhT6wpg7nQwnjyw
	U8YW5poRvevG8v0xP0Tr/VZXc5bIEEGJw4wMl7EDogJgLOZHerh3BYRydQ8Ks4F+8zjgdZkx/5u
	hPNLys6intytTJ2rwO0VC08a46j8FBvjImPC5CQyoOQCIELSMukJcF88lMFesFWLxnXIFY/nJ80
	so4oMU1wi1Qve900QfrhShjNksadjrR9LBD7StPmBLXZhU9+j3BqgH0VxzObP4FLriNv73W49Qm
	cu9TzFhqQx37lT1ImKFRdHMwE2OXjgkcZZp4R/QNZPcicipz/21ELzh6DZWY4TM3RlHIXMv983m
	lqr3CWPLyM3Ju4pdIeUJnmFhrZf+QrrAhjEFaLlrB8q
X-Received: by 2002:a05:600c:c8c:b0:495:5045:39e6 with SMTP id 5b1f17b1804b1-4980c664d68mr287612735e9.17.1785858499102;
        Tue, 04 Aug 2026 08:48:19 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: [PATCH v7 00/20]  Introduce enablemenant of dom0less
Date: Tue,  4 Aug 2026 17:47:50 +0200
Message-ID: <cover.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785858499-1D073757-18158D8C/10/73395122804
X-purgate-type: spam
X-purgate-size: 6195

This patch series reprensent a bunch of patches necessary to enable common part
of Dom0less.
The stuff necessary to start/launch domains will be introduced separately.

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2729854543

---
Changes in v7:
 - Merged to upstream/staging:
   - xen/riscv: Implement ARCH_PAGING_MEMPOOL
   - xen: arm: update p2m_set_allocation() prototype
   - xen/riscv: do a 4th linking pass if necessary
 - Address the comments from ML.
---
Changes in v6:
 - Merged to upstream/staging:
   - xen: arm: move declaration of map_device_irqs_to_domain() to common header
   - xen/Kconfig: introduce HAS_STATIC_MEMORY
   - xen/riscv: rename enum intc_version to intc_variant
   - xen/riscv: implement prerequisites for domain_create()
 - Move UBSAN fix ("xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page")
   to this patch series as it is connected to "xen/Kconfig: introduce HAS_STATIC_MEMORY".
 - Address the comments from ML.
---
Changes in v5:
 - Add new patch (xen/riscv: do a 4th linking pass if necessary) which fixes
   randconfig job issue.
 - Address comments from ML.
---
Changes in v4:
 - Address comments from ML.
---
Changes in v3:
 - Drop dependency from other patch series
   ([1] https://lore.kernel.org/xen-devel/cover.1778140240.git.oleksii.kurochko@gmail.com/T/#t)
   as it was merged.
 - Reorder patches:
   - move common patches to the start.
   - Move some patches to separate patch series (will be introduced later)
 - Address comments from ML.
---
Changes in v2:
 - Move patch "[PATCH v1 04/27] xen/riscv: rework G-stage mode handling" to
   patch series [1]
 - Address the comments from ML.
 - The following patches were folded into one:
   # xen/riscv: implement init_intc_phandle()
   # xen/riscv: call do_initcalls() in start_xen()
   # xen/riscv: setup system domains
 - The following patch were folded into one:
   # xen/riscv: add vaplic access check
   # xen/riscv: emulate guest writes to virtual APLIC MMIO
   # xen/riscv: emulate guest reads from virtual APLIC MMIO
 - Add new bug fix, not really necessary to this patch series:
   xen/riscv: manage IRQ_DISABLED flag in APLIC irq enable/disable callbacks
---

Oleksii Kurochko (20):
  xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page
  xen/dom0less: turn max_init_domid into a common variable
  xen/riscv: Implement construct_domain()
  xen/riscv: introduce guest riscv,isa string
  xen/riscv: implement make_cpus_node()
  xen/riscv: implement make_timer_node()
  xen/riscv: implement make_arch_nodes()
  xen/riscv: introduce init interrupt controller operations
  xen/riscv: implement make_intc_domU_node()
  xen/riscv: introduce aia_init() and aia_usable()
  xen/riscv: introduce per-vCPU IMSIC state
  xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure
  xen/riscv: introduce (de)initialization helpers for vINTC
  xen/riscv: generate IMSIC DT node for guest domains
  xen/riscv: create APLIC DT node for guest domains
  xen/riscv: implement IRQ routing for device passthrough
  xen/riscv: implement init_intc_phandle()
  xen/riscv: initialize RCU, scheduler, and system domains in
    start_xen()
  xen/riscv: provide init_vuart()
  xen/riscv: add initial dom0less infrastructure support

 xen/arch/arm/Kconfig                      |   1 +
 xen/arch/arm/include/asm/setup.h          |   2 -
 xen/arch/arm/setup.c                      |   2 -
 xen/arch/ppc/include/asm/setup.h          |   2 -
 xen/arch/riscv/Kconfig                    |   2 +
 xen/arch/riscv/Makefile                   |   4 +
 xen/arch/riscv/aia.c                      |  23 +++
 xen/arch/riscv/aplic-priv.h               |  13 ++
 xen/arch/riscv/aplic.c                    |  14 +-
 xen/arch/riscv/cpufeature.c               | 171 +++++++++++++---
 xen/arch/riscv/device.c                   |  94 +++++++++
 xen/arch/riscv/dom0less-build.c           |  40 ++++
 xen/arch/riscv/domain-build.c             | 192 ++++++++++++++++++
 xen/arch/riscv/domain.c                   |  16 +-
 xen/arch/riscv/imsic.c                    | 178 ++++++++++++++++-
 xen/arch/riscv/include/asm/aia.h          |  10 +
 xen/arch/riscv/include/asm/aplic.h        |  15 ++
 xen/arch/riscv/include/asm/cpufeature.h   |   5 +
 xen/arch/riscv/include/asm/domain.h       |   7 +
 xen/arch/riscv/include/asm/guest-layout.h |  24 +++
 xen/arch/riscv/include/asm/imsic.h        |  25 +++
 xen/arch/riscv/include/asm/intc.h         |  44 ++++-
 xen/arch/riscv/include/asm/irq.h          |   5 +
 xen/arch/riscv/include/asm/setup.h        |   2 -
 xen/arch/riscv/include/asm/vaplic.h       |  34 ++++
 xen/arch/riscv/intc.c                     | 102 +++++++++-
 xen/arch/riscv/irq.c                      | 226 ++++++++++++++++++++++
 xen/arch/riscv/setup.c                    |  12 ++
 xen/arch/riscv/vaplic.c                   | 148 ++++++++++++++
 xen/arch/x86/Kconfig                      |   1 +
 xen/arch/x86/include/asm/setup.h          |   2 -
 xen/common/Kconfig                        |   3 +
 xen/common/Makefile                       |   2 +-
 xen/common/domain.c                       |   6 +-
 xen/common/domctl.c                       |   4 +
 xen/common/domid.c                        |   5 +
 xen/common/event_channel.c                |  53 ++++-
 xen/common/event_channel.h                |   6 +
 xen/common/event_fifo.c                   |  19 +-
 xen/common/time.c                         |   2 +
 xen/drivers/char/console.c                |   1 +
 xen/include/xen/dom0less-build.h          |   7 +
 xen/include/xen/sched.h                   |   2 +
 xen/include/xen/shared.h                  |   8 +-
 xen/include/xen/time.h                    |   4 +
 45 files changed, 1478 insertions(+), 60 deletions(-)
 create mode 100644 xen/arch/riscv/aia.c
 create mode 100644 xen/arch/riscv/device.c
 create mode 100644 xen/arch/riscv/domain-build.c
 create mode 100644 xen/arch/riscv/include/asm/aia.h
 create mode 100644 xen/arch/riscv/include/asm/vaplic.h
 create mode 100644 xen/arch/riscv/vaplic.c

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382261.1625607 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNP-0006uX-Bk; Tue, 04 Aug 2026 15:48:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382261.1625607; Tue, 04 Aug 2026 15:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNP-0006uP-8L; Tue, 04 Aug 2026 15:48:23 +0000
Received: by outflank-mailman (input) for mailman id 1382261;
 Tue, 04 Aug 2026 15:48:22 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNO-0006uD-8C
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNN-009Gcw-9j
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:21 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209b7-bab6-0a2a0a5309dd-0a2a4505e25a-20
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:21 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c5-4cb1-0a2a45050019-d155802cd0a8-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:21 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-495757ccbc1so33610805e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858501; x=1786463301; 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=s2giNu/4S6jw/BG8lbsrBR4JasbJ4ALaPWnt21NbdkI=;
        b=WATOEZxONXg73Qtji13WhyZ7hCo7PQR4uWDhWB3FgXl2npZw1+dwocSRcNPOzoGwak
         a4IsN9RQemtkaLND9SVcpV24XmtvxYaCccrqzNOS9sF7HgFYrvckN3zSS+XsCh8oVjSo
         /82VrDQTviISxVytTN5GBk7taRFhtuv6dClyFKnt18qj6MLwiL3F0qI3Dsv0KLdIZanY
         iIPy1pl3/HYyoKNeHqY7ueyTWyWiLm6IJQAqG/fN/kPl/kAOYKZ9QD7f8ajFIXciwPxv
         rW2sGPwFVoLTVQqLv7gj9pdaBg7LRy9T+Xyo952v9TKyq4rrTlL/+wofYqEtBa/grcHe
         g55A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858501; x=1786463301;
        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=s2giNu/4S6jw/BG8lbsrBR4JasbJ4ALaPWnt21NbdkI=;
        b=XTFRYRP228BZSGpG+DKz/TNVMrKRPU6NerRmmpGxfIWpGAyMcgU0yQkNveaNcse3jZ
         OUjsyo/+/HpJZGJnEC/4wkozKN0F7mRxnJq5cDOdHVutt5kWO34+s2Gb1i3hMD6CkVjl
         DvkEi10P7LVy2iNH0bW8p3e/luPwltEONZiQcKK3s2YxqBRKS19DhYzuYsYH9c/VKz7m
         uavlZBybHQevH7qXc31QZc6CJpL0wLYdmsDhA9bhgY1Epsqx69V1ngZtMLdM36A2Hxm1
         0oa/+r4lgex/NinKfZqXiZx+wmTbF5w0o4d9IfSTkcoCyWNYQEdaHCFO5xjDtJlX97Dl
         0ZTQ==
X-Gm-Message-State: AOJu0YzY1GbxvjYC9nl0eA03fAYLJmB4dO8hOI+dJ+u8NLr71vURgiIG
	b4KWOY/nIK0aPuolW1xl1MwzfXtcaCcAb+U1wBbZSI3luLvbAw6+a2ym/vFoOA==
X-Gm-Gg: AR+sD13F9ihAZu4St0THtNU/pJ1ZIkHjFWPefAF40o/Iqkx2IgmRQSoHmLgRS2+9+bD
	i2CtgKNqga/cNTwPV0ogbdwg14hF9p57NxU7aCLvATyzpSqwIEV+YMv6yl+zvKB6s/N1zCSdzWA
	3FTK1TZ7i4OZNxw5lEabRgq1HSmNN/MwhANcq9FZRQ+IY84bI20l/Os+KJT634udbRTNBoTeMg6
	RUe58tUDV1LkDhY9cqa5bzpmQ4Q7YOPitgyzOwvpZV2XaQP5do09+BQ468Hxwwct9O4cUBDAwZe
	eXKeM7+aEPfcMawFugBUWIL85pL7PWjUROU7S4PAa1/fzWxUcl5oPXsl7khSpnTUUNW7uZZOOSb
	8PnyjdG3vZFyKFtB3L8EbS33IuouNS5EpVoJWUvIzrNmDBo2TrL96fn4Ih+iP+JgXrvj2sKM3Wf
	Vv5w1UaHQISSsToB2bnZ19gDfkxP4HIdiUfpGBKQLjqImOIIQEFuVwbbd36BZD1zsG8gmz7Q8UN
	x1OC+2TORrM5rwfaQKmqLwFKxYbyM2jlw==
X-Received: by 2002:a05:600c:840f:b0:496:c379:b2a1 with SMTP id 5b1f17b1804b1-4980c66d7bbmr299592255e9.2.1785858500271;
        Tue, 04 Aug 2026 08:48:20 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v7 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page
Date: Tue,  4 Aug 2026 17:47:51 +0200
Message-ID: <ed247fcc594346ad20a3d12e5d49c8f48ba6792a.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785858501-F68B62A1-243AE8C1/10/73395122804
X-purgate-type: spam
X-purgate-size: 18652

On architectures that run guests in dom0less mode without the PV ABI
(currently RISC-V), no shared_info page is allocated and d->shared_info
remains NULL throughout the domain lifetime. Several places in common
code access d->shared_info through the shared_info() macro or directly,
causing UBSAN null-pointer errors on such architectures.

Rather than adding runtime NULL guards that are logically unreachable
on x86 and Arm (where shared_info is always allocated), introduce a new
Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm.

On !HAS_SHARED_INFO the shared_info() macro expands to a dereference
of shared_info_absent, an extern pointer that is declared but
intentionally never defined.  Any use of shared_info() that is not
dead-code-eliminated will therefore cause a link-time failure, making
missed guards impossible to overlook.

The 2L event-channel ops call shared_info() and must not be compiled on
architectures without a shared_info page, so event_2l.o is gated on
CONFIG_HAS_SHARED_INFO. On such architectures evtchn_init() installs the
FIFO ops as a placeholder instead, so that a later guest opt-in to the
FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO
support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated
no-op evtchn_port_ops_none table is installed instead, so that
d->evtchn_port_ops is never NULL. evtchn_fifo_word_from_port() is
guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe
before evtchn_fifo_init_control() is called by the guest.

With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global
dummy_vcpu_info, so writes through vcpu_info() could leak data between
vCPUs. Reviewing the write paths in common code: the write in
map_guest_area() stores the constant ~0 so nothing serious would happen
if it were leaked; the event_2l.c paths are not compiled on
!HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the
write in vcpu_info_populate() targets the new mapping buffer, not
dummy_vcpu_info.

Outside common code, the remaining writes are x86 PV-specific, for which
CONFIG_HAS_SHARED_INFO=y. No code changes are needed.

Finally, struct domain's shared_info field itself is gated on
CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL
pointer: every user of it is either arch code for an architecture that
selects HAS_SHARED_INFO, or common code already guarded by the same
Kconfig symbol.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v7:
 - domctl.c: use a plain #ifdef CONFIG_HAS_SHARED_INFO / #else instead of
   the IS_ENABLED() if/else in getdomaininfo(), and set
   info->shared_info_frame to ~0 in the !HAS_SHARED_INFO case.
 - sched.h: drop struct domain's shared_info field when !HAS_SHARED_INFO,
   rather than keeping a field that can only ever be NULL there. All of
   its users are either in arch code selecting HAS_SHARED_INFO or already
   guarded by CONFIG_HAS_SHARED_INFO, so no further changes are needed.
   Update the commit message accordingly.
---
Changes in v6:
 - s/INVALID_GFN_RAW/gfn_x(INVALID_GFN) as INVALID_GFN_RAW was dropped.
 - event_channel.c: make evtchn_none_init() static, moving the
   evtchn_port_ops_none table and its definition above evtchn_reset(),
   their first caller; move the leftover prototype into the #else arm
   of the same #ifndef guard instead of leaving it as a free-standing
   non-static declaration.
 - event_channel.c: evtchn_reset() now follows the same
   IS_ENABLED(CONFIG_HAS_SHARED_INFO) / IS_ENABLED(CONFIG_EVTCHN_FIFO) /
   else cascade already used by evtchn_init(), rather than assuming the
   FIFO ABI is unconditionally available whenever d->evtchn_fifo was set.
 - event_channel.c: narrow the evtchn_port_ops_none / evtchn_none_init
   guard from !CONFIG_HAS_SHARED_INFO to
   !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO, so the placeholder
   cf_check functions are only built for the one combination that
   actually needs them.
 - event_channel.c: fix the evtchn_port_ops_none comment, which claimed
   the ops were never reachable in practice; they are reached whenever
   an event is delivered to (or queried on) a
   !HAS_SHARED_INFO && !EVTCHN_FIFO domain, they just have no ABI to
   record it in and discard it.
 - event_channel.h / event_fifo.c: drop the static inline
   evtchn_fifo_init_ops() stub for !CONFIG_EVTCHN_FIFO; a plain
   declaration outside the #ifdef/#else is enough, matching the
   treatment already given to evtchn_2l_init() and evtchn_none_init().
   Update the "only call site" comment in event_fifo.c to mention both
   evtchn_init() and evtchn_reset().
---
Changes in v5:
 - drop the static inline evtchn_2l_init() stub for !HAS_SHARED_INFO;
   a plain declaration is enough since the only call sites are guarded by
   IS_ENABLED(CONFIG_HAS_SHARED_INFO) and the dead call is eliminated
   before linking.
 - fix a NULL d->evtchn_port_ops dereference when CONFIG_HAS_SHARED_INFO=n
   and CONFIG_EVTCHN_FIFO=n: evtchn_init() was unconditionally calling
   evtchn_fifo_init_ops(), whose !EVTCHN_FIFO stub leaves d->evtchn_port_ops
   unset.  Gate the FIFO branch on IS_ENABLED(CONFIG_EVTCHN_FIFO) and add
   a dedicated evtchn_port_ops_none table for the remaining case. Stubs
   are shared where signatures permit: evtchn_none_noop covers both
   clear_pending and unmask; evtchn_none_false covers both is_pending and
   is_masked. evtchn_none_init() is called only from event_channel.c, so its
   declaration is kept there rather than in event_channel.h.
 - gate evtchn_fifo_init_ops() on !CONFIG_HAS_SHARED_INFO;
   its only call site is in the IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branch
   of evtchn_init(), which is never reached on HAS_SHARED_INFO=y builds.
---
Changes in v4:
 - event_channel.c: drop the redundant evtchn_fifo_init_ops() in the
   else branch of evtchn_reset(); evtchn_fifo_destroy() does not undo the
   ops installed by evtchn_init(), so only the switch back to 2-level ABI
   needs an explicit call.
 - shared.h: simplify the !HAS_SHARED_INFO shared_info() definition to use
   an undefined "extern struct shared_info *shared_info_absent" instead of
   shared_info_absent() with a typeof cast.
 - Extend the commit description to note that vcpu_info()/__vcpu_info()
   uses were also audited: on !HAS_SHARED_INFO vcpu_info_area.map points at
   dummy_vcpu_info, reads are harmless, and writes in common code do not
   open a cross-domain info-leak side channel, so no code changes are
   needed on that path.
---
Changes in v3:
 - Introduce CONFIG_HAS_SHARED_INFO Kconfig symbol selected by x86
   and Arm; RISC-V does not select it.
 - Gate shared_info() macro on CONFIG_HAS_SHARED_INFO; on
   !HAS_SHARED_INFO it calls shared_info_absent() (declared, never
   defined) so any unguarded use produces a link-time error.
 - Replace runtime if (!d->shared_info) guards with IS_ENABLED() at
   call sites so both branches type-check and dead code is eliminated.
 - Guard shared_info_frame assignment in domctl.c.
 - Gate event_2l.o on CONFIG_HAS_SHARED_INFO; use FIFO ops as
   placeholder on !HAS_SHARED_INFO archs instead of dedicated stub
   ops; guard evtchn_fifo_word_from_port() against uninitialised
   d->evtchn_fifo.
 - Add static inline stubs for evtchn_2l_init() (!HAS_SHARED_INFO)
   and evtchn_fifo_init_ops() (!EVTCHN_FIFO) so call sites can use
   IS_ENABLED() without #ifdef.
 - Drop inaccurate changelog entry about "only FIFO ABI" migration.
 - Update the commit message.
 - Drop R-by: Baptiste ... as some extra checks are added.
---
Changes in v2:
 - Update commit message + subject.
 - Drop Fixes tag.
---
 xen/arch/arm/Kconfig       |  1 +
 xen/arch/x86/Kconfig       |  1 +
 xen/common/Kconfig         |  3 +++
 xen/common/Makefile        |  2 +-
 xen/common/domain.c        |  6 ++---
 xen/common/domctl.c        |  4 +++
 xen/common/event_channel.c | 53 +++++++++++++++++++++++++++++++++++---
 xen/common/event_channel.h |  6 +++++
 xen/common/event_fifo.c    | 19 +++++++++++++-
 xen/common/time.c          |  2 ++
 xen/include/xen/sched.h    |  2 ++
 xen/include/xen/shared.h   |  8 +++++-
 xen/include/xen/time.h     |  4 +++
 13 files changed, 102 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 843a43897e7b..d748404e82da 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -20,6 +20,7 @@ config ARM
 	select HAS_DEVICE_TREE_DISCOVERY
 	select HAS_DOM0LESS
 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
+	select HAS_SHARED_INFO
 	select HAS_STACK_PROTECTOR
 	select HAS_STATIC_MEMORY
 	select HAS_UBSAN
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3ce0774b8d76..e5535ac48467 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -29,6 +29,7 @@ config X86
 	select HAS_PCI_MSI
 	select HAS_PIRQ
 	select HAS_SCHED_GRANULARITY
+	select HAS_SHARED_INFO
 	imply HAS_SOFT_RESET
 	select HAS_UBSAN
 	select HAS_VMAP
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index da80fdba8469..5b289e444fa5 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -158,6 +158,9 @@ config HAS_PMAP
 config HAS_SCHED_GRANULARITY
 	bool
 
+config HAS_SHARED_INFO
+	bool
+
 config HAS_STATIC_MEMORY
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 6018e256147f..f69d47d18934 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += domid.o
-obj-y += event_2l.o
+obj-$(CONFIG_HAS_SHARED_INFO) += event_2l.o
 obj-y += event_channel.o
 obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o
 obj-$(CONFIG_GRANT_TABLE) += grant_table.o
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e16f1ac38396..6b52713518da 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -316,9 +316,9 @@ void vcpu_info_reset(struct vcpu *v)
     struct domain *d = v->domain;
 
     v->vcpu_info_area.map =
-        ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS)
-         ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
-         : &dummy_vcpu_info);
+        IS_ENABLED(CONFIG_HAS_SHARED_INFO) && v->vcpu_id < XEN_LEGACY_MAX_VCPUS
+        ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
+        : &dummy_vcpu_info;
 }
 
 static struct domain *alloc_domain_struct(void)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a6210db4fb97..83405a766a54 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -102,9 +102,13 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
 #ifdef CONFIG_MEM_PAGING
     info->paged_pages       = atomic_read(&d->paged_pages);
 #endif
+#ifdef CONFIG_HAS_SHARED_INFO
     info->shared_info_frame =
         gfn_x(mfn_to_gfn(d, _mfn(virt_to_mfn(d->shared_info))));
     BUG_ON(SHARED_M2P(info->shared_info_frame));
+#else
+    info->shared_info_frame = ~0;
+#endif
 
     info->cpupool = cpupool_get_id(d);
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a7f9cc5fe0ac..0911808fe861 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -40,6 +40,41 @@
 
 #define consumer_is_xen(e) (!!(e)->xen_consumer)
 
+#if !defined(CONFIG_HAS_SHARED_INFO) && !defined(CONFIG_EVTCHN_FIFO)
+/*
+ * Placeholder ops for domains with neither a shared_info page nor a FIFO
+ * control block (CONFIG_HAS_SHARED_INFO=n and CONFIG_EVTCHN_FIFO=n). Such
+ * a domain has no ABI to record event state in, so these are reachable
+ * whenever an event is delivered to (or queried on) one of its ports; they
+ * just discard/no-op it.  They exist to keep d->evtchn_port_ops non-NULL.
+ */
+static void cf_check evtchn_none_set_pending(
+    struct vcpu *v, struct evtchn *evtchn) {}
+static void cf_check evtchn_none_noop(
+    struct domain *d, struct evtchn *evtchn) {}
+static bool cf_check evtchn_none_false(
+    const struct domain *d, const struct evtchn *evtchn) { return false; }
+static void cf_check evtchn_none_print_state(
+    struct domain *d, const struct evtchn *evtchn) {}
+
+static const struct evtchn_port_ops evtchn_port_ops_none = {
+    .set_pending   = evtchn_none_set_pending,
+    .clear_pending = evtchn_none_noop,
+    .unmask        = evtchn_none_noop,
+    .is_pending    = evtchn_none_false,
+    .is_masked     = evtchn_none_false,
+    .print_state   = evtchn_none_print_state,
+};
+
+static void evtchn_none_init(struct domain *d)
+{
+    d->evtchn_port_ops = &evtchn_port_ops_none;
+}
+#else
+/* Declaration only; the calls below are DCE'd unless both configs are off. */
+void evtchn_none_init(struct domain *d);
+#endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */
+
 /*
  * Lock an event channel exclusively. This is allowed only when the channel is
  * free or unbound either when taking or when releasing the lock, as any
@@ -1324,9 +1359,15 @@ int evtchn_reset(struct domain *d, bool resuming)
         rc = -EAGAIN;
     else if ( d->evtchn_fifo )
     {
-        /* Switching back to 2-level ABI. */
         evtchn_fifo_destroy(d);
-        evtchn_2l_init(d);
+
+        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
+            /* Switching back to 2-level ABI. */
+            evtchn_2l_init(d);
+        else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
+            evtchn_fifo_init_ops(d);
+        else
+            evtchn_none_init(d);
     }
 
     write_unlock(&d->event_lock);
@@ -1625,7 +1666,13 @@ void evtchn_check_pollers(struct domain *d, unsigned int port)
 
 int evtchn_init(struct domain *d, unsigned int max_port)
 {
-    evtchn_2l_init(d);
+    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
+        evtchn_2l_init(d);
+    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
+        evtchn_fifo_init_ops(d);
+    else
+        evtchn_none_init(d);
+
     d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX);
 
     d->evtchn = alloc_evtchn_bucket(d, 0);
diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h
index dc94a43cc2dd..c8ee09807008 100644
--- a/xen/common/event_channel.h
+++ b/xen/common/event_channel.h
@@ -70,6 +70,12 @@ static inline void evtchn_fifo_destroy(struct domain *d)
 }
 #endif /* CONFIG_EVTCHN_FIFO */
 
+/*
+ * Declaration only when !CONFIG_EVTCHN_FIFO; the (dead) calls in
+ * evtchn_init() and evtchn_reset() are DCE'd in that case.
+ */
+void evtchn_fifo_init_ops(struct domain *d);
+
 #endif /* EVENT_CHANNEL_H */
 
 /*
diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
index 611bf8a78801..3b6e619c5278 100644
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -62,6 +62,9 @@ static inline event_word_t *evtchn_fifo_word_from_port(const struct domain *d,
      */
     smp_rmb();
 
+    if ( unlikely(!d->evtchn_fifo) )
+        return NULL;
+
     if ( unlikely(port >= d->evtchn_fifo->num_evtchns) )
         return NULL;
 
@@ -419,6 +422,19 @@ static const struct evtchn_port_ops evtchn_port_ops_fifo =
     .print_state   = evtchn_fifo_print_state,
 };
 
+/*
+ * evtchn_fifo_init_ops()'s only call sites are in the
+ * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branches of evtchn_init() and
+ * evtchn_reset(), which are never reached on HAS_SHARED_INFO=y builds
+ * because of DCE.
+ */
+#ifndef CONFIG_HAS_SHARED_INFO
+void evtchn_fifo_init_ops(struct domain *d)
+{
+    d->evtchn_port_ops = &evtchn_port_ops_fifo;
+}
+#endif
+
 static int map_guest_page(struct domain *d, uint64_t gfn, void **virt)
 {
     struct page_info *p;
@@ -561,7 +577,8 @@ static void setup_ports(struct domain *d, unsigned int prev_evtchns)
 
         evtchn = evtchn_from_port(d, port);
 
-        if ( guest_test_bit(d, port, &shared_info(d, evtchn_pending)) )
+        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) &&
+             guest_test_bit(d, port, &shared_info(d, evtchn_pending)) )
             evtchn->pending = true;
 
         evtchn_fifo_set_priority(d, evtchn, EVTCHN_FIFO_PRIORITY_DEFAULT);
diff --git a/xen/common/time.c b/xen/common/time.c
index 04a65f00b35c..cdfdc53b6a17 100644
--- a/xen/common/time.c
+++ b/xen/common/time.c
@@ -89,6 +89,7 @@ struct tm gmtime(unsigned long t)
     return tbuf;
 }
 
+#ifdef CONFIG_HAS_SHARED_INFO
 void update_domain_wallclock_time(struct domain *d)
 {
     uint32_t *wc_version;
@@ -117,6 +118,7 @@ void update_domain_wallclock_time(struct domain *d)
 
     spin_unlock(&wc_lock);
 }
+#endif /* CONFIG_HAS_SHARED_INFO */
 
 /* Set clock to <secs,usecs> after 00:00:00 UTC, 1 January, 1970. */
 void do_settime(u64 secs, unsigned int nsecs, u64 system_time_base)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index eef10c2ea2c0..53ba5ed8c257 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -404,7 +404,9 @@ struct domain
 
     struct vcpu    **vcpu;
 
+#ifdef CONFIG_HAS_SHARED_INFO
     shared_info_t   *shared_info;     /* shared data area */
+#endif
 
     rcu_read_lock_t  rcu_lock;
 
diff --git a/xen/include/xen/shared.h b/xen/include/xen/shared.h
index 5b71342cab32..f20a46801181 100644
--- a/xen/include/xen/shared.h
+++ b/xen/include/xen/shared.h
@@ -43,7 +43,13 @@ typedef struct vcpu_info vcpu_info_t;
 
 extern vcpu_info_t dummy_vcpu_info;
 
-#define shared_info(d, field)      __shared_info(d, (d)->shared_info, field)
+#ifdef CONFIG_HAS_SHARED_INFO
+#define shared_info(d, field) __shared_info(d, (d)->shared_info, field)
+#else
+extern struct shared_info *shared_info_absent;
+#define shared_info(d, field) (((void)(d), shared_info_absent)->field)
+#endif /* CONFIG_HAS_SHARED_INFO */
+
 #define vcpu_info(v, field)        \
         __vcpu_info(v, (vcpu_info_t *)(v)->vcpu_info_area.map, field)
 
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index e9c0822e6f31..2f872f580ffc 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -66,7 +66,11 @@ struct tm wallclock_time(uint64_t *ns);
 #define version_update_begin(v) (((v) + 1) | 1)
 #define version_update_end(v)   ((v) + 1)
 extern void update_vcpu_system_time(struct vcpu *v);
+#ifdef CONFIG_HAS_SHARED_INFO
 extern void update_domain_wallclock_time(struct domain *d);
+#else
+static inline void update_domain_wallclock_time(struct domain *d) {}
+#endif
 
 extern void do_settime(
     u64 secs, unsigned int nsecs, u64 system_time_base);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382265.1625636 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNT-0007TP-Md; Tue, 04 Aug 2026 15:48:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382265.1625636; Tue, 04 Aug 2026 15:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNT-0007Qz-DD; Tue, 04 Aug 2026 15:48:27 +0000
Received: by outflank-mailman (input) for mailman id 1382265;
 Tue, 04 Aug 2026 15:48:26 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNS-0007KG-25
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNR-009GfZ-F6
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:25 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209b0-2eae-0a2a0a5409dd-0a2a450cd344-36
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:25 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c9-f479-0a2a450c0019-d1558032ad18-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:25 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49558ce01afso26773375e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858505; x=1786463305; 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=OtCr8wU2t2GJWhHJ8VA4gfjPYB+rOSURYzxYVnJJT30=;
        b=Ks6kTuoOKfbkOPaqFnIMGRYHtWGNOL5PZdg9hLvfUylqpaC5qVz3RP2x4Z42TI875k
         Tr0fppbdAUwUVq4zU186c3UBIfmr4SfvtbkEYhW9i747ytaEDADTB3Zrm0uX9QqBxaOZ
         03sLgVZuj/bpLyFtHA4anvYHeScykWsh3YyHFBERcd8qvkn7+F59tg8yEbu3r0f34wcj
         jyi44PjNxZ6aTLVLMes5P8HFOt17xBJAzdA8S/BfmcsWiO8ZpWDEB7gkl0rxb31P6KW/
         X85B3RHKeeCywUnzwLGwOuoc4Ag8rz0ARrhERHOg/vMEZyR5E99XyHkhkfwZ0dfyypPW
         pLRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858505; x=1786463305;
        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=OtCr8wU2t2GJWhHJ8VA4gfjPYB+rOSURYzxYVnJJT30=;
        b=Z2H/rPGbEDzOAUDuI2mdcOsL4DJyIPkD5lctirG02Rk5I9n539aV8sTYVXdBoraehx
         9S3JyQQ2J+x9UpMpe2gPv8rd3Ii6IKj3Iye3HJxi9kJpN3iHu5uBl27vaQzMSFwKI0ED
         DiaS1KcuaSJf1NkB3l1uufHvNIfSxx5g7c/P49v0azjwPYmwm1NB83uxLL/aEL3mocCV
         pzytKDBf0dMnhZr1sq2kBp5TN8xVsJUaUqnHjc3XM+Uw3Zmn4ySeDlVm4e6JYH87rg3z
         2gPPskBjM8rczrGqBJiV6qo93DdCXWj0jHdCHCIPJ+kvkys3tVIiBxhuJ7QDMr+txKQI
         WM+Q==
X-Gm-Message-State: AOJu0YytdCqg9lxqVpAh8z0XXoYkBMByw/6oD6rhUKmVu81A+fXbJk2t
	BQHggT7S+Pbu6I/UY2lJiCakSZ4jmIB+jQMSJjCoEVp5xjTJ11I8Y/wZ556TmQ==
X-Gm-Gg: AR+sD13GTTpOQ+AB0R1mea0O2+WUoMpx23LnsfC5CO0iKl9rC5aFhnGebZtxaKEEO5+
	ArByreEMrbs6kpgn7UGY7Tfa9g2mYCWzStFEhNlv+qUzfMyIVOCgIiD23/p3pm850tSUZbBov5V
	Kv0VnoXSm05yPd/9VP9JKoRu21M9wtdCD115d2cf5hHz/+s+agMLsdEJkIX4hWfYP44d2SiohVW
	H6XLbRxHiDSXQVJwafpoeUFK13zPRWRQu5ksZg5J5UlI6jB2p1DI7sqyqb0d/TamCS2suscZ/qn
	qgMNqqV4Ol1V+xjy9qOnFy5FYOPsdl7s3Rz0ONLABPKMwGqJR8btPw070jdzd7ZpR9eebYE3aLc
	c2JgsJEv9Xp64uG+cb0RRZ4XrfESKCEJUEANotnBM7t4Yc7jW7jpFSb9GeVTSaQjxA4ZX1iV4Gd
	s5o9U0X0YEUIC2A20fmngOHjAx1Hb4k9ccFEm+JoC2qEEIIh2VNk9qCKZOvXUZvbcFdV3N3QOv6
	StonN0onK+o+/1gZ/OCwPFxIXOsRaP72Q==
X-Received: by 2002:a05:600c:c490:b0:494:596e:e8c4 with SMTP id 5b1f17b1804b1-4980c67d1cbmr317723855e9.17.1785858504857;
        Tue, 04 Aug 2026 08:48:24 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 05/20] xen/riscv: implement make_cpus_node()
Date: Tue,  4 Aug 2026 17:47:55 +0200
Message-ID: <4df84f91703588ca55c2c0fa73cadb9f94437571.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1785858505-02CDBA5B-A8231C93/10/73395122804
X-purgate-type: spam
X-purgate-size: 6049

Implement make_cpus_node() to create cpus node for a guest domain.

This function is going to be use by common dom0less code during
construction domain.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v7:
- use get_guest_isa_str() for the "riscv,isa" property instead of building
  the string per domain.
- as a consequence, drop the isa_str/len local variables, the
  xvmalloc_array()/xvfree() pair and the <xen/xvmalloc.h> inclusion; with no
  resource left to release, the error paths now return res directly and the
  "out" label is gone.
- s/sizeof/ARRAY_SIZE for snprintf's argument.
- Drop Acked-by: Jan B. as some changes were done so it would be nice if
  Jan B. will review them again.
---
Changes in v6:
 - Update the two build_guest_isa_str() call sites for its new
  `const struct domain *d` signature.
 - Drop build/tools/fixdep from the patch.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v5:
- Drop Acked-by: Jan Beulich <jbeulich@suse.com> as extra changes were done
  because of the changed in prev. patch.
- Move isa_str allocation and construction out of arch_domain_create() and
  into make_cpus_node() as a local variable, since the string is only
  needed during FDT generation. Use a two-call build_guest_isa_str()
  pattern (size probe, then fill) with xvmalloc_array, and convert all
  post-allocation error returns to goto out so xvfree() runs on every path.
---
Changes in v4:
 - Update the comment in make_cpus_node() to match code style.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v3:
 - Add blank line above make_cpus_node() function definition.
 - Move 'unsigned int cpu' from function-level declarations into the for loop.
 - Drop 'uint32_t reg = cpu_to_fdt32(cpu)'; use fdt_property_cell(fdt, "reg", cpu)
   instead of fdt_property(fdt, "reg", &reg, sizeof(reg)) so byte-order adjustment
   is handled internally.
 - Add matching /* interrupt-controller */ start comment; fix end comment to
   /* end interrupt-controller */.
 - Update d->arch.guest_isa_str to ->isa_str in make_cpus_node() function.
---
Changes in v2:
 - s/u32/uint32_t for timebase_frequency local variable.
 - Drop +1 from BUILD_BUG_ON().
 - return fdt_end_node(fdt); instead of res at the end of the function.
---
---
 xen/arch/riscv/domain-build.c | 106 ++++++++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)

diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
index 5f6f4b6248a5..1af4c48fb30c 100644
--- a/xen/arch/riscv/domain-build.c
+++ b/xen/arch/riscv/domain-build.c
@@ -3,8 +3,10 @@
 #include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/sched.h>
 
+#include <asm/cpufeature.h>
 #include <asm/current.h>
 #include <asm/guest_access.h>
 
@@ -48,3 +50,107 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 
     return 0;
 }
+
+int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
+{
+    int res;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    uint32_t timebase_frequency;
+    bool frequency_valid;
+    void *fdt = kinfo->fdt;
+
+    dt_dprintk("Create cpus node\n");
+
+    if ( !cpus )
+    {
+        dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n");
+        return -ENOENT;
+    }
+
+    frequency_valid = dt_property_read_u32(cpus, "timebase-frequency",
+                                           &timebase_frequency);
+
+    res = fdt_begin_node(fdt, "cpus");
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", 1);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#size-cells", 0);
+    if ( res )
+        return res;
+
+    if ( frequency_valid )
+        res = fdt_property_cell(fdt, "timebase-frequency", timebase_frequency);
+
+    for ( unsigned int cpu = 0; cpu < d->max_vcpus; cpu++ )
+    {
+        char buf[64];
+
+        snprintf(buf, ARRAY_SIZE(buf), "cpu@%u", cpu);
+        res = fdt_begin_node(fdt, buf);
+        if ( res )
+            return res;
+
+        res = fdt_property_cell(fdt, "reg", cpu);
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "status", "okay");
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "compatible", "riscv");
+        if ( res )
+            return res;
+
+        BUILD_BUG_ON((sizeof("riscv,") +
+                      sizeof_field(struct gstage_mode_desc, name)) >= sizeof(buf));
+        snprintf(buf, ARRAY_SIZE(buf), "riscv,%s", max_gstage_mode->name);
+        res = fdt_property_string(fdt, "mmu-type", buf);
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "riscv,isa", get_guest_isa_str());
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "device_type", "cpu");
+        if ( res )
+            return res;
+
+        /* Start of interrupt-controller */
+        res = fdt_begin_node(fdt, "interrupt-controller");
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "compatible", "riscv,cpu-intc");
+        if ( res )
+            return res;
+
+        res = fdt_property_cell(fdt, "#interrupt-cells", 1);
+        if ( res )
+            return res;
+
+        res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+        if ( res )
+            return res;
+
+        res = fdt_property_u32(fdt, "phandle", alloc_phandle(kinfo));
+        if ( res )
+            return res;
+
+        /* End of interrupt-controller */
+        res = fdt_end_node(fdt);
+        if ( res )
+            return res;
+
+        res = fdt_end_node(fdt);
+        if ( res )
+            return res;
+    }
+
+    return fdt_end_node(fdt);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382263.1625625 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNS-0007L9-Ue; Tue, 04 Aug 2026 15:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382263.1625625; Tue, 04 Aug 2026 15:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNS-0007L2-Rt; Tue, 04 Aug 2026 15:48:26 +0000
Received: by outflank-mailman (input) for mailman id 1382263;
 Tue, 04 Aug 2026 15:48:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNR-0007Jq-FB
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNQ-009GfZ-SJ
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:24 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209a3-2eae-0a2a0a5409dd-0a2a450b975e-48
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:24 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c8-b7e8-0a2a450b0019-d155802ca8ce-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:24 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-4980fe6b3beso8471115e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48:24 -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-49949fcb46esm116430355e9.5.2026.08.04.08.48.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858504; x=1786463304; 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=oqMXCnK01BlYFZDe0+XHyH0PuzocnmSdtMYh4s8i6/I=;
        b=NrCqbKI/e42GXKnbhw/FVaj72OlfJPNqbFXidSkQs8p6efGG4TnQfNIrf6X3s80Vfe
         xDTRcvGW+wJeUwL0a76tdMkEAvk4NHC7HdQ41ozE/7gi+uTM9gkynlAsZ0CFpUe00vl+
         dc+BDeKdRmMGSdW4gBNyBs+zT6Tz8Ooa1WdSn9+dI2YMIGBMYcashyEwqYOuD/090orW
         pY0xqGF5ZNfcFEn93izd2EB7nrlJogsfBdzbFzGbXv3AcIwZ8pCUaQ5MNQD9jB5VqHHy
         jnelwbZILQPwFTZNzU1zVWRz8fG04F5BqsvJEPCVns1mOM+l3SA/r5SJ+SmO+uK1Ea5v
         REGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858504; x=1786463304;
        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=oqMXCnK01BlYFZDe0+XHyH0PuzocnmSdtMYh4s8i6/I=;
        b=LGg99nNJygfUDPjrnxNDkDgGAujrS2ZyCvGimevc9DqA1vTl0X9+SoDB2tyhM8ttAa
         kmuDJ7mgUHogn3CnEd6UaUm+gPpzcehBD1f8yQRTsm+9CFm7Dgalm1Vh195T63FoAlUN
         2ifg2+jBarurpXzaq2Vq8L6Swq2tVb6lrXQJPgyszx0CAU3I9bOBZfCkr3OIbYdpCA/R
         OT8ss7j7IUwdcLXtOpY30nTWDzHO4yz5uZ+Rjn5F5wWq9HK0Uh+pWbYcNyeUPmw3pluu
         eUV9mS7Tv3YPmkrsg63WJSP+YKIJIgq45XPowUdHmqKzqCKwDfl/yrNpbjNfPpTlKLAM
         3pzA==
X-Gm-Message-State: AOJu0YyI936rsMG3YtpYZWzmSYJi95fCPTYnM1TeanV8dD1bXI6/QyVx
	Y7wZgreNmXVa3Xv7oH7GJluJ5XFgqP1P74Hjmj2Pgd0pw192GCT9GjC3TD9zow==
X-Gm-Gg: AR+sD12ssa4QbH03qv+JiPSZM0buAJomrIIdPs/nCVVBWgtN/mYHlRdNJjarIfo4nK4
	K9qPP59137iLQyv4guJWVWTUomKEQt7mWptqq7yot7xB4daJjLk3/ymgbQbFJ6Z7WlSvuRkrsBU
	Td9W2qMTfzryEsbjoL167RYLWRB4nccg3z8/4NFDluxs5NNxNvmGXfJJlrHWRaeNmr6ViEh6hle
	Y1yDY1m81HgK78p2g0+xMA2VqUvUdt96Cck+jbM7nu/gAKy7KAru1bYgpeV+FHQnuu+340stpXU
	zhT1VfbTvvR73DGw61tm9FL8OxIUY8lctpEL9CH3XgF/nfH5o3183SLX0wt2RqTg0FUiE2PJcVQ
	9ut0QaOLygHTWpglGd9PchQCRUDIlmLq77CTxhulALWFio0728Kv8HzBJUFp25XfM+OUSsYOk3b
	8Y8G5jxTi93PacA8DOd2dKyu1Bk802DNgdz/pdn+8dDMEXzKiWo1az79HNAdHQdiUWloIoAJYM/
	15O6ZY07Yek3jcBndR8pvg6vZbVDhmGhw==
X-Received: by 2002:a05:600c:468d:b0:493:f478:4c71 with SMTP id 5b1f17b1804b1-4994e382cacmr889265e9.7.1785858503857;
        Tue, 04 Aug 2026 08:48:23 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 04/20] xen/riscv: introduce guest riscv,isa string
Date: Tue,  4 Aug 2026 17:47:54 +0200
Message-ID: <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785858504-1BED69EA-756EA657/10/73395122804
X-purgate-type: spam
X-purgate-size: 14745

Introduce build_guest_isa_str() to generate the riscv,isa string to be
passed to the guest via the Device Tree riscv,isa property.

Introduce the per-domain guest ISA bitmap, populated during domain
creation by calling init_guest_isa().

Introduce struct riscv_isa_ext_entry with a new guest_supported field
to filter out ISA extensions that should not be exposed to guests:

- f/d/q/v: FPU and vector context save/restore are not yet implemented
  for guests.
- Z*inx are not exposed either: they aren't in riscv_isa_ext[], so they
  can never be set in riscv_isa and thus never reach a guest, and no
  current hardware/guest-OS advertises or expects them. Supporting them
  would be cheaper than F/D/Q (FP values stay in integer registers Xen
  already context-switches), but is left as future work.
- h: Nested virtualisation is not supported.
- sstc: Xen owns the supervisor timer; guests must use SBI.
- svade: Xen manages hardware A/D bit updates in stage-2 page tables.
- svpbmt: Page-based memory types are not yet wired up in stage-2 code.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v7:
- build_guest_isa_str(): drop the struct domain argument and work directly on
  the guest_isa bitmap; make the function static as it has no external users
  anymore.
- build the guest "riscv,isa" string only once, in compute_guest_isa(), and
  store it in an __ro_after_init pointer, instead of rebuilding it for every
  domain: all domains are currently given the same guest ISA, so apply here
  the same reasoning as for the guest_isa bitmap.
- panic() on length calculation, allocation or formatting failure, in line
  with the rest of riscv_fill_hwcap() initialization.
- introduce get_guest_isa_str() accessor and expose it in asm/cpufeature.h
  instead of build_guest_isa_str().
---
Changes in v6:
- build_guest_isa_str() now takes a `const struct domain *d` instead of a
  raw `const unsigned long *isa_bitmap`, to leave room for using more than
  just the bitmap in the future.
- Compute the guest-visible ISA bitmap once at boot, into a new
  __ro_after_init `guest_isa` bitmap (compute_guest_isa(), called at the
  end of riscv_fill_hwcap()), instead of re-deriving it from
  riscv_isa_ext[] on every domain creation in init_guest_isa(). All guests
  currently get the same extension set, so this avoids repeating
  identical work per domain; will need revisiting if/when per-domain ISA
  policy is introduced.
- struct arch_domain's `isa` field is now `const unsigned long *isa`
  instead of an embedded bitmap; init_guest_isa() just points it at the
  shared `guest_isa` bitmap rather than copying bits into a per-domain
  array.
- Mark riscv_isa_ext[] __initconstrel, since its entries hold name pointers
  and the need for relocations requires that the compiler emit the data to
  a writable section.
- Make build_guest_isa_str() __init as it is called during make_cpus_node()
  which is used only (at least, for now) in build time of domain.
---
Changes in v5:
- Introduce struct riscv_isa_ext_entry with a guest_supported field and
  RISCV_ISA_EXT_ENTRY(name, guest_supp) macro for riscv_isa_ext[],
  replacing the ad-hoc guest_unsupp bitmap and init_guest_unsupp().
  Every entry now carries an explicit true/false decision, enforced at
  compile time.
- init_guest_isa() builds d->arch.isa by iterating riscv_isa_ext[]
  directly instead of using bitmap_andnot() against guest_unsupp.
- init_guest_isa() changed to void as it can no longer fail.
- Drop isa_str from struct arch_domain; the ISA string does not need to
  persist over the domain lifetime. build_guest_isa_str() is made
  non-static and declared in cpufeature.h for use when building the
  guest device tree.
- Updated the fix of underflow in build_guest_isa_str().
- Drop unnecessary empty line in cpufeature.h before enum riscv_isa_ext_id.
---
Changes in v4:
 - Add an explicit overflow guard in build_guest_isa_str(): return
   -ENOSPC when buf is non-NULL and total >= size, to avoid the
   size - total underflow being passed to snprintf().
 - Expand the commit message to explain why Zfinx/Zdinx/Zqinx are not
   added to guest_unsupp (not in riscv_isa_ext[], so never set in
   riscv_isa nor exposed to a guest; left as future work)
---
Changes in v3:
 - s/set_bit/__set_bit in init_guest_unsupp() as atomicity isn't needed at
   init time.
 - Drop RISCV_GUEST_ISA_STR_MAX; allocate isa_str dynamically with
   xvmalloc_array().
 - Drop "guest" prefix from d->arch.guest_isa and d->arch.guest_isa_str.
 - Introduce build_guest_isa_str() using snprintf(NULL, 0, ...) to determine
   the needed buffer size; init_guest_isa() calls it once for sizing and once
   to fill, keeping both in a single function so they can't go out of sync.
 - Scope ret inside the loop; initialize total directly from the prefix
   snprintf().
 - Merge "_" separator and extension name into a single snprintf() with
   "%s%s".
 - Replace ASSERT with an explicit error check: if the fill call returns a
   different length, free isa_str and return -EINVAL.
---
Changes in v2:
 - s/guest_unsupp_bmp/guest_unsupp.
 - Drop guest_isa_str.
 - Provide init_guest_isa() instead of polluting match_isa_ext().
 - Drop xlen.
 - Add the comment about guest_unsupp.
 - Update the way how guest_unsupp is init-ed.
 - Drop __initconst for riscv_isa_ext[] as it is used in init_guest_isa()
   which isn't marked as __init as it could be used after init stage.
---
---
 xen/arch/riscv/cpufeature.c             | 171 ++++++++++++++++++++----
 xen/arch/riscv/domain.c                 |   2 +
 xen/arch/riscv/include/asm/cpufeature.h |   5 +
 xen/arch/riscv/include/asm/domain.h     |   3 +
 4 files changed, 157 insertions(+), 24 deletions(-)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 92235fdfd5ab..c963c3d556b4 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -14,7 +14,9 @@
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <xen/sections.h>
+#include <xen/xvmalloc.h>
 
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
@@ -34,9 +36,35 @@ struct riscv_isa_ext_data {
     .name = #ext_name,                          \
 }
 
+struct riscv_isa_ext_entry {
+    unsigned int id;
+    const char *name;
+    bool guest_supported;
+};
+
+#define RISCV_ISA_EXT_ENTRY(ext_name, guest_supp)       \
+{                                                       \
+    .id              = RISCV_ISA_EXT_ ## ext_name,      \
+    .name            = #ext_name,                       \
+    .guest_supported = guest_supp,                      \
+}
+
 /* Host ISA bitmap */
 static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
 
+/*
+ * ISA bitmap handed out to every guest.
+ *
+ * All guests are given the same extensions for the time being, so this is
+ * computed once out of riscv_isa_ext[] and riscv_isa, rather than redoing
+ * the walk for every domain created.  Should per-domain ISA policy ever be
+ * introduced, this will need to become per-domain again.
+ */
+static __ro_after_init DECLARE_BITMAP(guest_isa, RISCV_ISA_EXT_MAX);
+
+/* "riscv,isa" string corresponding to guest_isa, shared by all domains. */
+static char *__ro_after_init guest_isa_str;
+
 static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
                                          unsigned long *dt_cpuid)
 {
@@ -120,29 +148,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
  * and strncmp() is used in match_isa_ext() to compare extension names instead
  * of strncasecmp().
  */
-const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
-    RISCV_ISA_EXT_DATA(i),
-    RISCV_ISA_EXT_DATA(m),
-    RISCV_ISA_EXT_DATA(a),
-    RISCV_ISA_EXT_DATA(f),
-    RISCV_ISA_EXT_DATA(d),
-    RISCV_ISA_EXT_DATA(q),
-    RISCV_ISA_EXT_DATA(c),
-    RISCV_ISA_EXT_DATA(h),
-    RISCV_ISA_EXT_DATA(zicntr),
-    RISCV_ISA_EXT_DATA(zicsr),
-    RISCV_ISA_EXT_DATA(zifencei),
-    RISCV_ISA_EXT_DATA(zihintpause),
-    RISCV_ISA_EXT_DATA(zihpm),
-    RISCV_ISA_EXT_DATA(zba),
-    RISCV_ISA_EXT_DATA(zbb),
-    RISCV_ISA_EXT_DATA(zbs),
-    RISCV_ISA_EXT_DATA(smaia),
-    RISCV_ISA_EXT_DATA(smstateen),
-    RISCV_ISA_EXT_DATA(ssaia),
-    RISCV_ISA_EXT_DATA(sstc),
-    RISCV_ISA_EXT_DATA(svade),
-    RISCV_ISA_EXT_DATA(svpbmt),
+static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
+    RISCV_ISA_EXT_ENTRY(i,            true),
+    RISCV_ISA_EXT_ENTRY(m,            true),
+    RISCV_ISA_EXT_ENTRY(a,            true),
+    RISCV_ISA_EXT_ENTRY(f,            false),
+    RISCV_ISA_EXT_ENTRY(d,            false),
+    RISCV_ISA_EXT_ENTRY(q,            false),
+    RISCV_ISA_EXT_ENTRY(c,            true),
+    RISCV_ISA_EXT_ENTRY(v,            false),
+    RISCV_ISA_EXT_ENTRY(h,            false),
+    RISCV_ISA_EXT_ENTRY(zicntr,       true),
+    RISCV_ISA_EXT_ENTRY(zicsr,        true),
+    RISCV_ISA_EXT_ENTRY(zifencei,     true),
+    RISCV_ISA_EXT_ENTRY(zihintpause,  true),
+    RISCV_ISA_EXT_ENTRY(zihpm,        true),
+    RISCV_ISA_EXT_ENTRY(zba,          true),
+    RISCV_ISA_EXT_ENTRY(zbb,          true),
+    RISCV_ISA_EXT_ENTRY(zbs,          true),
+    RISCV_ISA_EXT_ENTRY(smaia,        true),
+    RISCV_ISA_EXT_ENTRY(smstateen,    true),
+    RISCV_ISA_EXT_ENTRY(ssaia,        true),
+    RISCV_ISA_EXT_ENTRY(sstc,         false),
+    RISCV_ISA_EXT_ENTRY(svade,        false),
+    RISCV_ISA_EXT_ENTRY(svpbmt,       false),
 };
 
 static const struct riscv_isa_ext_data __initconst required_extensions[] = {
@@ -181,7 +210,7 @@ static void __init match_isa_ext(const char *name, const char *name_end,
 
     for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ )
     {
-        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
+        const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];
 
         /*
          * `ext->name` (according to initialization of riscv_isa_ext[]
@@ -480,6 +509,98 @@ bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
     return test_bit(id, isa_bitmap);
 }
 
+static int __init build_guest_isa_str(char *buf, size_t size)
+{
+    char *p = buf;
+    size_t left = size;
+    int total;
+
+#if defined(CONFIG_RISCV_32)
+    total = snprintf(p, left, "rv32");
+#elif defined(CONFIG_RISCV_64)
+    total = snprintf(p, left, "rv64");
+#else
+# error "Unsupported RISC-V bitness"
+#endif
+
+    if ( total < 0 )
+        return total;
+
+    if ( buf )
+    {
+        if ( (size_t)total >= left )
+            return -ENOSPC;
+
+        p += total;
+        left -= total;
+    }
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(riscv_isa_ext); i++ )
+    {
+        const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];
+        int ret;
+
+        if ( !riscv_isa_extension_available(guest_isa, ext->id) )
+            continue;
+
+        ret = snprintf(p, left, "%s%s",
+                       ext->id >= RISCV_ISA_EXT_BASE ? "_" : "",
+                       ext->name);
+        if ( ret < 0 )
+            return ret;
+
+        total += ret;
+
+        if ( buf )
+        {
+            if ( (size_t)ret >= left )
+                return -ENOSPC;
+
+            p += ret;
+            left -= ret;
+        }
+    }
+
+    return total;
+}
+
+static void __init compute_guest_isa(void)
+{
+    int len;
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(riscv_isa_ext); i++ )
+    {
+        const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];
+
+        if ( ext->guest_supported &&
+             riscv_isa_extension_available(NULL, ext->id) )
+            __set_bit(ext->id, guest_isa);
+    }
+
+    /*
+     * All domains are given the same guest ISA, so the "riscv,isa" string
+     * is built only once here and then shared by all of them.
+     */
+    if ( (len = build_guest_isa_str(NULL, 0)) < 0 )
+        panic("Failed to calculate guest \"riscv,isa\" length: %d\n", len);
+
+    if ( !(guest_isa_str = xvmalloc_array(char, len + 1)) )
+        panic("Failed to allocate guest \"riscv,isa\" string\n");
+
+    if ( build_guest_isa_str(guest_isa_str, len + 1) != len )
+        panic("Failed to build guest \"riscv,isa\" string\n");
+}
+
+void init_guest_isa(struct domain *d)
+{
+    d->arch.isa = guest_isa;
+}
+
+const char *get_guest_isa_str(void)
+{
+    return guest_isa_str;
+}
+
 void __init riscv_fill_hwcap(void)
 {
     unsigned int i;
@@ -527,4 +648,6 @@ void __init riscv_fill_hwcap(void)
     if ( !all_extns_available )
         panic("Look why the extensions above are needed in "
               "https://xenbits.xenproject.org/docs/unstable/misc/riscv/booting.txt\n");
+
+    compute_guest_isa();
 }
diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c
index 2819ff4e7c92..c9933147595e 100644
--- a/xen/arch/riscv/domain.c
+++ b/xen/arch/riscv/domain.c
@@ -308,6 +308,8 @@ int arch_domain_create(struct domain *d,
     if ( is_idle_domain(d) )
         return 0;
 
+    init_guest_isa(d);
+
     if ( (rc = p2m_init(d, config)) != 0)
         goto fail;
 
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
index 0c48d57a03bb..2973eb13a513 100644
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -5,6 +5,7 @@
 #ifndef __ASSEMBLER__
 
 #include <xen/stdbool.h>
+#include <xen/types.h>
 
 /*
  * These macros represent the logical IDs of each multi-letter RISC-V ISA
@@ -44,7 +45,11 @@ enum riscv_isa_ext_id {
     RISCV_ISA_EXT_MAX
 };
 
+struct domain;
+
 void riscv_fill_hwcap(void);
+void init_guest_isa(struct domain *d);
+const char *get_guest_isa_str(void);
 
 bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
                                    enum riscv_isa_ext_id id);
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index 6044ce0feee0..8ae01a5e4dcc 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -7,6 +7,7 @@
 #include <xen/xmalloc.h>
 #include <public/hvm/params.h>
 
+#include <asm/cpufeature.h>
 #include <asm/guest-layout.h>
 #include <asm/p2m.h>
 #include <asm/vtimer.h>
@@ -94,6 +95,8 @@ struct arch_domain {
     struct p2m_domain p2m;
 
     struct paging_domain paging;
+
+    const unsigned long *isa;
 };
 
 #include <xen/sched.h>
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382266.1625638 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNT-0007YY-UJ; Tue, 04 Aug 2026 15:48:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382266.1625638; Tue, 04 Aug 2026 15:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNT-0007WN-PR; Tue, 04 Aug 2026 15:48:27 +0000
Received: by outflank-mailman (input) for mailman id 1382266;
 Tue, 04 Aug 2026 15:48:26 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNS-0007KO-6m
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNR-009GfZ-Jj
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:25 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c9-2eae-0a2a0a5409dd-0a2a4507c9be-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:25 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c7-b4ea-0a2a45070019-d155802eb8ac-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:23 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so36540035e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858503; x=1786463303; 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=MP/1zoasJWckGByg7jAKnBbEmQnEEwAq1X/Es6dlPOM=;
        b=SP+gnfjuQEudbjUeaC+DElxqkKK4NHG/SdzMh13jcpTvcHHZ4Nk3C1G8WBcR0nzBJ1
         xfGBsC327fKshsOVjXV0oCwymy+cnOGB0IxZzZ1GPuzFZhvz+Dby16YDyveAAsbCyck+
         7mPOlJe7Oug+dRbyZmkLZP8onBSp0JH3Z0mJdF/LXW0mgfuFYRJNQR3R4nS94Ms0ODHT
         lx7vGsNY1p5Vq61TUWPdKjgTk3QFolBqC/l3jdJipkByuZK5C6yyATZSttIuJnjo0D7T
         B3KDwavPa940NO8DwvtdUkYnkY8P0Jo73+oJQQe0NvR6QnHmVsFibSCd+ho9+UOYtztc
         w4DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858503; x=1786463303;
        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=MP/1zoasJWckGByg7jAKnBbEmQnEEwAq1X/Es6dlPOM=;
        b=Z39tjLd/JiwA9UVlluN6d5LoJyh/VJnMmKP0Q8f9rQP8sGkhUuNC9VStR3Syv8LLpd
         qwrm0IpcbvBwA9ateLRL6j+k6th44NK5M96mPNvjFxZabwxW0g5jZVCTTOCqwd2+4QS7
         ahjrMUaMYRaIxFtznjIez+2wQkd/LgDjgIEpTMMvzXdkzLE2JVnMFcwwq4WYyhT0QWDq
         w0XqfA0w3VWeMu1UTRXZbwb3o0YkbKCVkwi/d26cdvkqbSqnFOzuSJ/mAMESiA5ILaSF
         hyd3lwxF24wOt2CL7ofKNSTk4OAzT3TeTmYONPpQBmcbudW31v+QyZM4/lU3mFkj4h5W
         OGFg==
X-Gm-Message-State: AOJu0YyHZb4byQWXealrac2AEDbxmmGAQgAqktdcqjyZZNs9vNPaojpU
	pgmLy4Lry8MAk0Dx8EtzGDyF7NLPPVJ8HMbijqg6deu7B6pj5VUHzlcbpwmEzQ==
X-Gm-Gg: AR+sD13+U1ZsVOZJ3y6gdcxaN9RoZxTGKhnpcHdf2uIiM9iM2NAv7FeF1J7aWsYGIzJ
	+GSQmYWnrEyc9dC4O+wiGeMPZsrSYnIjziBdeAoU/UA49TMso3lcQiXWNdwAMCUl4Lywv2LT0xm
	tMLObZVM4wKOc70u/3r1kP2xU3tL91XJI512qHhnVoDw3DiZQAB5lknko/bhfTdSx8qKZetrmt9
	S1giWJcl56/MKIKo8Mc0fFu/lG0DSJj8OxN/zr+LqWYNo6hREjOJ1pOZ2eh7PxHa8R1Kk4xGner
	7JfDNZNwJT7CB2dgyCL7yniPiSpzrqX3yHNsHkx/v8X4gcPDqA+efMRk/DwRGrnJRJ6y8lHIUdD
	2PNF1UogGvPeW56cX0U4FwdeTVTeKQQ5J+KmlQquhbKeqsJ8gGSaX/ZOC02tqwrsqoVHB2lBlBJ
	PeefhtqOZcxdOZ9Qnr45HKLfRfcb44v1KEi28xaXD5XGoXu86uwS2nW+YKlv/GzxboQQPmyn16n
	dWsW4k3APnuWhme2CfLX0n29u6f9uztBg==
X-Received: by 2002:a05:600c:8711:b0:495:52a5:8829 with SMTP id 5b1f17b1804b1-4980c652515mr416359285e9.11.1785858502781;
        Tue, 04 Aug 2026 08:48:22 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 03/20] xen/riscv: Implement construct_domain()
Date: Tue,  4 Aug 2026 17:47:53 +0200
Message-ID: <f8fab37699ea2cb9eb8cba6414ada57f9f0d0c15.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785858503-3C610AE4-0BE0FE40/10/73395122804
X-purgate-type: spam
X-purgate-size: 3117

Implement construct_domain() function for RISC-V, which performs initial setup
for the domain's first vCPU, loads the kernel, initrd, and device tree,
and sets up guest CPU registers for boot.

It also creates additional vCPUs up to max_vcpus and assigns the device tree
address and boot cpuid in registers.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v5-v7:
 - Only rebase. Nothing changed.
---
Changes in v4:
 - Drop the blank before v%u in the printk() failure message so the output
   matches that of %pv.
 - Restore Acked-by that was lost in v3.
---
Changes in v3:
 - s/%d/%u for printing vCPU index in the failure message.
 - Drop dprintk() for successful vCPU creation.
---
Changes in v2:
 - Rework construct_domain() to print that vCPU1...n are created using %pv.
 - Use true instead of 1 for initialization of v->is_initialised.
 - Drop unnessary BUG_ON() in construct_domain().
 - Add TODO comment above *_load() functions.
---
---
 xen/arch/riscv/Makefile       |  1 +
 xen/arch/riscv/domain-build.c | 50 +++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+)
 create mode 100644 xen/arch/riscv/domain-build.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 4fcdcf9e24de..2d24670dfc74 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,6 +1,7 @@
 obj-y += aplic.o
 obj-y += cpufeature.o
 obj-y += domain.o
+obj-y += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
new file mode 100644
index 000000000000..5f6f4b6248a5
--- /dev/null
+++ b/xen/arch/riscv/domain-build.c
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include <xen/fdt-domain-build.h>
+#include <xen/fdt-kernel.h>
+#include <xen/init.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+#include <asm/guest_access.h>
+
+int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
+{
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(v);
+
+    BUG_ON(v->is_initialised);
+
+    /*
+     * At the moment *_load() don't return value and will just panic()
+     * inside.
+     * TODO: it will be good to change that.
+     */
+    kernel_load(kinfo);
+    initrd_load(kinfo, copy_to_guest_phys);
+    dtb_load(kinfo, copy_to_guest_phys);
+
+    regs->sepc = kinfo->entry;
+
+    /* Guest boot cpuid = 0 */
+    regs->a0 = 0;
+    regs->a1 = kinfo->dtb_paddr;
+
+    for ( unsigned int i = 1; i < d->max_vcpus; i++ )
+    {
+        const struct vcpu *tmp_v = vcpu_create(d, i);
+
+        if ( !tmp_v )
+        {
+            printk("Failed to allocate %pdv%u\n", d, i);
+            break;
+        }
+    }
+
+    domain_update_node_affinity(d);
+
+    v->is_initialised = true;
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382267.1625658 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNV-00089I-Fq; Tue, 04 Aug 2026 15:48:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382267.1625658; Tue, 04 Aug 2026 15:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNV-00086R-AR; Tue, 04 Aug 2026 15:48:29 +0000
Received: by outflank-mailman (input) for mailman id 1382267;
 Tue, 04 Aug 2026 15:48:27 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNT-0007LB-3D
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNS-009Gcw-Fw
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:26 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209b7-bab6-0a2a0a5309dd-0a2a4505e25a-32
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:26 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209ca-4cb1-0a2a45050019-d1558032b837-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:26 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so36541325e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858506; x=1786463306; 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=xLkIYss1rW/F2qb2oVl9fc594E2EtP3QPXzs49dm0sw=;
        b=b1BwFxD+XbEtmhYCLlAGre2G5NtvTNmLE/etUJpULzhzJ5NMPdu155LyF9YV/4UmiR
         YvJGsloZRiWGva+hUIod38oQU9jhjMnw8eGG4PcpVPuqHx1FaClOuiDTTixUVv/eFcdh
         V0iBVwRgkhA7wWs9l/AMAumpWHJOIY23h1CLTfm3tg5XRMclK9sGinXCn6GVIXLwJ/4L
         a/3skOBNozAyO2/RWQNPQTHWN+0fcPw/xiQ53znripQVoCicQOMwgexvLWUMH5p2euNO
         zNjXJXT773I9hQ/5HxGkHjs8ieAIPnSQDmaoYaLtcFEvh9RUuvdcBOqqt3noUAwGWE4e
         51ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858506; x=1786463306;
        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=xLkIYss1rW/F2qb2oVl9fc594E2EtP3QPXzs49dm0sw=;
        b=Aa/7UgDDBtsYoJRu9aGDYTVPVMCq37DwsWYZTEXEsb4opUKAHJNHp6mvLIzOFUIMcG
         LeZIyooLZB1DTeCSdMxI2goyhCMJt2jNSWQKwYe4+laL9vx/Mzp8b8wUbCfixUcVj/c5
         j6cFzSN5wcYIqrEU/O6qUm0BKRcBZV4LKfd7q43z1iKWZD4swonOoWI+kZuW1KuOsYsy
         Di8C/cLWEn+YWav1oqHagicGMPkQcNjzkLubcTc/5Ow5EhW9Kalw8PTCqkQANogwOuI5
         JuoqLq+51szPP+zdvc8CWKS54a4gfPpCaYbDHYXlN4dyI/FVBCfYvPcJ+XOJ/wVlQXoc
         CuWg==
X-Gm-Message-State: AOJu0YyM7ELom/nPK28YLj84L73fuMdP7esJ8ztLWZNMxNgBLI6+oLqY
	TtyYQqY+G3MDYG3yivLxabqmYyB8FJeKkAEpcICLt9vjrC3qcjHglqBGPmjW8g==
X-Gm-Gg: AR+sD11romr588/THHmwTkR4eqgZ9YBFx987Ug1ZOiVKJgRKK0qijA1d1TISxijSXg/
	Ev/8nelQGW8J2fm3SUYECz25X1gFIydoImSs9o96VTaraxPo5lhAyrX1UeKRpWHS2rySm7LwKjt
	/IGBLgZUzD6Fz6ZQZWLsWWHGBHh3QMR8rl8vefkRkpBAM21N/zZsWTTBxcWLsiFvKIhRaXVCG0O
	5IJpgiwO0SKurNilZQkpK9jrlDZZrFL2uz1cEqXXC94oonRCdRPx/YgblHHR6GY4J4ouic7ziQx
	k22pSjsgY5biaAa+5hwlnOsawtr3GgRVzkQ3na+LxqNp1LORBrxYkJp2S7Q25Pp0itpkBiOEx14
	alZKNEBJotskajiWTXAwsxFyM5UOWYqrMLQ8U2Q+B7y8V67NirMsIQpxc1AqR8GfvOYgLX/x6Up
	3bc+YVM13QO9TnXz/YdL2fI6sIGeX+CcnBqOu5uy65UODTYCmlyjEtkHKXx4keN8suV2T1P1CyW
	l00DSRPIbWtctT/yXX8FavyxLHgH3GYTw==
X-Received: by 2002:a05:600c:1d0a:b0:495:5dcc:52b4 with SMTP id 5b1f17b1804b1-4994d9ef0b5mr33072185e9.3.1785858505967;
        Tue, 04 Aug 2026 08:48:25 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 06/20] xen/riscv: implement make_timer_node()
Date: Tue,  4 Aug 2026 17:47:56 +0200
Message-ID: <c5c21c800c0649af283955abc56126d93a463741.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785858506-F60AA2A1-EB1945B8/10/73395122804
X-purgate-type: spam
X-purgate-size: 1618

Generally, in DT for RISC-V there is a document which describes a timer
node (riscv,timer.yaml or sifive,clint.yaml), but the Linux timer driver
is declared with TIMER_OF_DECLARE(riscv_timer, "riscv", ...).
It matches the CPU node (compatible "riscv"), not the timer node itself.
It then calls of_find_compatible_node(NULL, NULL, "riscv,timer") only to
read the optional riscv,timer-cannot-wake-cpu property.

Since Xen does not care about that property for now, make_timer_node() is
implemented to return 0, as no timer node needs to be created for RISC-V
guests.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3-7:
 - Nothing changed. Only rebase.
---
Changes in v2:
 - Acked-by: Jan Beulich <jbeulich@suse.com>
 - Update the commit message.
---
---
 xen/arch/riscv/domain-build.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
index 1af4c48fb30c..d7613721db95 100644
--- a/xen/arch/riscv/domain-build.c
+++ b/xen/arch/riscv/domain-build.c
@@ -3,6 +3,7 @@
 #include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/fdt-kernel.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/sched.h>
 
@@ -154,3 +155,10 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
 
     return fdt_end_node(fdt);
 }
+
+int __init make_timer_node(const struct kernel_info *kinfo)
+{
+    /* There is no need for timer node for RISC-V. */
+
+    return 0;
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382268.1625670 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNW-0008Rt-RS; Tue, 04 Aug 2026 15:48:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382268.1625670; Tue, 04 Aug 2026 15:48:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNW-0008RZ-Kq; Tue, 04 Aug 2026 15:48:30 +0000
Received: by outflank-mailman (input) for mailman id 1382268;
 Tue, 04 Aug 2026 15:48:28 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNU-0007gh-Fy
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNT-009QHz-SM
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:27 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c8-5cb7-0a2a0a5109dd-0a2a450bdaba-8
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:27 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209cb-b7e8-0a2a450b0019-d1558031e9ac-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:27 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4955de8797cso21143195e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858507; x=1786463307; 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=Rya0M33QFFZ2ZUtKRPpGLKlS3qYbQXw2r8chWSRTMZ4=;
        b=cfbY1msnd39EcO4GDxFdxC01xMFVr7SpVkJ9oPRgn9rDEu0Cs1AAcORr697/qthwfS
         nK+Psr0OIwV8BnvvKdbgAy7PEO2+YjBl2WluLDu1/EgUtV9BQPHBe6dqYg7kXv+4W6j3
         Y1U1YarQO7ErvGXTMsd17ZmCXCNMCjB5n84gMnP2F1uPtcksmv8bjE4JR9N0zIdJ1Ug4
         QzsG35CQHq/a4F9iK3eqe0ARfjcTzOpcqYGrP6IrODKuZpkul19gPekabLR32XZogGco
         Gwp5pZ9bwic/nJH/wLpQ1hoSJW/Sz7mo7Kan9B46jMS11iMCNx6Z2MzYgLBvRWpOFOdj
         WLmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858507; x=1786463307;
        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=Rya0M33QFFZ2ZUtKRPpGLKlS3qYbQXw2r8chWSRTMZ4=;
        b=c4vIKlqb2vTmWvbRmZqp1m7JrQkHMktXnl8+6v82Q+OeRKe44Bv6MyJ2odXdfAWjZl
         T1gk7ihyd5fSl4a87IfOBNAoYA8WAoPbM+13TerULaUXtatckW68JH3vXCJ8EExffZTD
         +QJepOeKGSetkvM951kuqRo7Ummt+cvj3e65/Pqd4DyjltOvqChK/f31xiHQXoHHUL41
         mtj5Eyo/F8GTwdMWtaBlaZHdHO5ARCsqkTJKzGu4rH4SWkwb3+yix5Mn2Um/ZyA84sT3
         jW77PfbVgJb7ApFwOcy24KGrau43YZuek5wiTkeZ9TdDihNvAvRBln+HnGzu18xCxUge
         MH3g==
X-Gm-Message-State: AOJu0Yw3/UQ/yX2fzcWfoe05vvPKoXu57eIUo5kLIIK+mw5Cdhv+nE0p
	zzsNj+x0+GAn0/h6Vmjg4jiYnQ//nxHWp4r7bcF4EWSktIai1M0VjEhpUfyVZw==
X-Gm-Gg: AR+sD11jhv3dpsW+6gC1PElWwURVzh75OCjffG6yt4ek0Yv2qONMNCt4um4fm1+sVS1
	SxWpmXz0gkrZHG+GqAFB3djXqACBhLZbDhSqqpqJpgkCvZUFEPZSg04lbz2+Po+iMmvZ6EtPTQs
	EzW4pvdQPJ19d9+UXNZNDu/7y5P4XbELCpltwWZ0zZ3ORVW7keBJHoAReF/06Shxp/GwzFSODve
	FMpP+yugC2IDPRBHXArfrk8s3do251ajHdhZKgqa6+hX4qWClPBM1U92efraxwX41CGwadTtZT8
	fQgAA4jPiK+UAQhiGcOL7TZMiKeq4kFx849a+8OC9IS/vH1UAwuWy0ObfewBfRWGNWT9p3lM9lN
	GKFb5AZPs+TVyEUIF4eae3wXtv0pqLnXNhUHPhUDFeQeYH7WO+ZVVNfynCdjvzeWOiy9ouCfJzl
	no+C8NjLeDdSA3CbznM4gRbTImwnsJm08K5oAbbXcetKmAhKzfYkPT4Mqmn7+Ji8AkoLPO1CAtC
	w3xMCy0iFDT3JwXL0UzcmCwjHozrVsF2WlZHrnnGMkC
X-Received: by 2002:a05:600c:628c:b0:496:c0f6:78d6 with SMTP id 5b1f17b1804b1-4980c64b5a7mr388460645e9.2.1785858506985;
        Tue, 04 Aug 2026 08:48:26 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 07/20] xen/riscv: implement make_arch_nodes()
Date: Tue,  4 Aug 2026 17:47:57 +0200
Message-ID: <6bc1edc29160d7758d71402632309aeb7029d7fa.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785858507-AB8D19EA-DE3A0F14/10/73395122804
X-purgate-type: spam
X-purgate-size: 1444

No RISC-V-specific nodes need to be created at the moment,
so make_arch_nodes() is implemented to simply return 0.

It is placed in dom0less-build.c as make_arch_nodes() is
only used in the dom0less code path. In the future, it will
be extended to create an emulated UART node.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-v7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Drop "Add" before Acked-by above the footer.
---
Change in v4:
 - Add lost Acked-by.
---
Changes in v3:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v2:
 - Update the commit message.
---
---
 xen/arch/riscv/dom0less-build.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index a683972e9235..4cc00012aa8d 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -2,10 +2,18 @@
 
 #include <xen/bootfdt.h>
 #include <xen/device_tree.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
 
 #include <asm/p2m.h>
 
+int __init make_arch_nodes(struct kernel_info *kinfo)
+{
+    /* No RISC-V specific nodes need to be made, at the moment. */
+
+    return 0;
+}
+
 int __init arch_parse_dom0less_node(struct dt_device_node *node,
                                     struct boot_domain *bd)
 {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382269.1625676 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNX-00005D-Iv; Tue, 04 Aug 2026 15:48:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382269.1625676; Tue, 04 Aug 2026 15:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNX-0008VU-7C; Tue, 04 Aug 2026 15:48:31 +0000
Received: by outflank-mailman (input) for mailman id 1382269;
 Tue, 04 Aug 2026 15:48:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNV-000889-ID
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNU-009QHz-UW
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:28 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c8-5cb7-0a2a0a5109dd-0a2a450bdaba-10
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:28 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209cc-b7e8-0a2a450b0019-d1558033b807-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:28 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so36542205e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48:28 -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-49949fcb46esm116430355e9.5.2026.08.04.08.48.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858508; x=1786463308; 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=ebyF9U3D/MvFmcX3JXdHMfkwonGwN8CEi9ANlVWdpho=;
        b=cX/6V6ybntMPMEf/atcWFMKZPIuvZ6LUlu0I1s+X/rguGNPs9RXhaj5p189ilgD6e/
         Eh5UpzFMd8lKbZPqDxOFidX7Ztta4TMjtUy+PwnY8LmYV/3919QN4dIR6YyOFpAJyq5H
         K7cO11KxobVpW90IqXXGHmPnx8CW4Lzq6uYpbe1JobY5QrHE/BPYvmEMDkCoUTABZhal
         Z67JsxG/5Pjru1A9cOy83Liku4fd7UYUdR2sjvxeTeJSXxgljbOMIHije/CdWNRBKJJq
         nXmofN0yjhAlgJwyCOYsvdXmsRzk+H62Psfs8bwfvxyZYh2BTy0I3EX295B95GOqaiQO
         N/Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858508; x=1786463308;
        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=ebyF9U3D/MvFmcX3JXdHMfkwonGwN8CEi9ANlVWdpho=;
        b=LE/pIyY1ZHKPYxDnpqWVqvsG90Rw1BpHkFHJ0nZFM2sQACak9E2b+SewmFMdmArPM8
         pkMfcieZnUpHeMjK0GeQ5X9IQRccYhIMXIrRkTs22UC0LkRl51vaI57EcYST/ybOpIXW
         aolHhr5sxPxYOcVjEmAX48KpjAj+vLre8SGLV9v/fC2t9IXxGvjzi7okdk6Nt2Pgjfac
         a8hiJhqHXtp7aOzeE/0j1bEJ8brXsDTxEfbQcr21b4ecLnBRD3l2WwzbIgsbpdRN6MtG
         0wq2COXQQeDPg++wzqVfEXOXToEuM0yndZtF8Fzola3MYQDq9X3z8HkJBlV2w9rAPxA0
         rM5g==
X-Gm-Message-State: AOJu0YywabMODMY7xeBJtxvhNfHwz0QDs5jSviSkSVrOB+SIyr1tl1QJ
	nyWRg+3Oc59MavNqaukYlxyqDWFULjNJmOpsTtX3oBO/vrDWc4HK+85cmdyCLw==
X-Gm-Gg: AR+sD11H9xPPpHxSA1ubHCEqpFM/tQZJo+kxEwQpBoV84ES+B1Iv4ezvoY1ZQm0yLGB
	uCwGvM2GdrWx4S8h5YRVCrwh87wTfzzPK7PE18gLYrw91Bd++OEKl5/uqGYmodWDkyyleC6zZHJ
	Aww7RPjdV3ayyBTBtWY2RWq5nEFH9EzNzNVDFVnnOYnlayFt2sH7sxb0wzxYys9VolueZ5nS5ux
	laB88PpSGjuKXnY17JXrM2QuboZgODj1HCApUnoPwBArIzRvQrEdTJpbF28jNs+dtmwyBQF0+Pr
	rHo2mEkybMmu1J6yOEQyVQ5GG/XA3bbq31bZd7ulOYElUZf6pt94UGiPUFm72/ILnkmna9cG7RU
	ZruROax/qm0YkKehHrdf+mdkXCSS+pbjH/yI6IksLgx91bakzLG37Nox5qYcGUP0CLVQ81tlpoZ
	+UzXleOA4A+x7D8ucI4yJkrPkY+boSlfLfezD/UFn0aPpp+/O8sn7N5VSxc4QVC3e/YcZMcIXcw
	wmWUUkOAEDPMDGt9g8RPWvBQ8XvJ1EPdg==
X-Received: by 2002:a05:600c:a016:b0:495:573e:1c54 with SMTP id 5b1f17b1804b1-4980c6523bamr409034915e9.9.1785858508247;
        Tue, 04 Aug 2026 08:48:28 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 08/20] xen/riscv: introduce init interrupt controller operations
Date: Tue,  4 Aug 2026 17:47:58 +0200
Message-ID: <370ce245e6974650bd6efab9a4eba841f14552d5.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785858508-18ECE9EA-DC2254E9/10/73395122804
X-purgate-type: spam
X-purgate-size: 4032

Introduce intc_hw_init_ops structure to avoid risky mix of init
function and non-init function.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v5-7:
 - Nothin changed. Only rebase.
---
Changes in v4:
 - Use __initconstrel instead of __initconst for aplic_init_ops as both
   initialized fields incur a relocation.
 - Add Acked-by: ... .
---
Changes in v3:
 - Use __initconst instead of __initdata for const intc_hw_init_ops.
 - Embed const struct intc_hw_operations *ops into intc_hw_init_ops so
   register_intc_ops() takes a single pointer argument.
---
Changes in v2:
 - New patch.
---
---
 xen/arch/riscv/aplic.c            |  8 ++++++--
 xen/arch/riscv/include/asm/intc.h | 10 +++++++---
 xen/arch/riscv/intc.c             | 11 ++++++++---
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 9f023db5d525..d08401db46b3 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -325,12 +325,16 @@ static const hw_irq_controller aplic_xen_irq_type = {
 
 static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
-    .init                = aplic_init,
     .host_irq_type       = &aplic_xen_irq_type,
     .handle_interrupt    = aplic_handle_interrupt,
     .set_irq_type        = aplic_set_irq_type,
 };
 
+static const struct intc_hw_init_ops __initconstrel aplic_init_ops = {
+    .ops                 = &aplic_ops,
+    .init                = aplic_init,
+};
+
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
                                     unsigned int intsize,
                                     unsigned int *out_hwirq,
@@ -366,7 +370,7 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     dt_irq_xlate = aplic_irq_xlate;
 
-    register_intc_ops(&aplic_ops);
+    register_intc_ops(&aplic_init_ops);
 
     /* Enable supervisor external interrupt */
     csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 675f703ec97f..d7b34fc15ad1 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -28,8 +28,6 @@ struct intc_info {
 struct intc_hw_operations {
     /* Hold intc hw information */
     const struct intc_info *info;
-    /* Initialize the intc and the boot CPU */
-    int (*init)(void);
 
     /* hw_irq_controller to enable/disable/eoi host irq */
     const struct hw_interrupt_type *host_irq_type;
@@ -43,9 +41,15 @@ struct intc_hw_operations {
     void (*handle_interrupt)(struct cpu_user_regs *regs);
 };
 
+struct intc_hw_init_ops {
+    const struct intc_hw_operations *ops;
+    /* Initialize the intc and the boot CPU */
+    int (*init)(void);
+};
+
 void intc_preinit(void);
 
-void register_intc_ops(const struct intc_hw_operations *ops);
+void register_intc_ops(const struct intc_hw_init_ops *init_ops);
 
 void intc_init(void);
 
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index ea317aea5ad8..3600d23bdb5b 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -12,9 +12,12 @@
 
 static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
 
-void __init register_intc_ops(const struct intc_hw_operations *ops)
+static const struct intc_hw_init_ops *__initdata intc_hw_init_ops;
+
+void __init register_intc_ops(const struct intc_hw_init_ops *init_ops)
 {
-    intc_hw_ops = ops;
+    intc_hw_ops = init_ops->ops;
+    intc_hw_init_ops = init_ops;
 }
 
 void __init intc_preinit(void)
@@ -27,7 +30,9 @@ void __init intc_preinit(void)
 
 void __init intc_init(void)
 {
-    if ( intc_hw_ops->init() )
+    ASSERT(intc_hw_init_ops && intc_hw_init_ops->init);
+
+    if ( intc_hw_init_ops->init() )
         panic("Failed to initialize the interrupt controller drivers\n");
 }
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382271.1625688 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNZ-0000XC-0j; Tue, 04 Aug 2026 15:48:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382271.1625688; Tue, 04 Aug 2026 15:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNY-0000VR-Oq; Tue, 04 Aug 2026 15:48:32 +0000
Received: by outflank-mailman (input) for mailman id 1382271;
 Tue, 04 Aug 2026 15:48:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNX-0008SN-08
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNW-009QHz-CE
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:30 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c8-5cb7-0a2a0a5109dd-0a2a450bdaba-14
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:30 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209ce-b7e8-0a2a450b0019-d155802cd52a-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:30 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so21020405e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48:30 -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-49949fcb46esm116430355e9.5.2026.08.04.08.48.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858509; x=1786463309; 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=ER+uu35/NuCBQKkMFT6UQDxN44ZmROCjZqSQxG2REVI=;
        b=F54137HGfFFkXinnUZXnS7aXsO5/c6pfNP0uqQi3BtZ/TxB4/ncciWBE/X9lnMeKvB
         aMkKUTdvllYkgyFLEBUQoyEcv9SAqEab47Ltz6PwZklfEU+Gh5WGm4xpOjU6Riqi92/Y
         lzdAPinMymdF8+Ol5l3B4QI4OSu/5tFPFTb7/zti6Lgkb7CJVFpynTuDfWJvXRJtJpPT
         EpbQ3hzv3uHF6liBeGRaQMwS3NoYM927o/RMhg7NPddHzBWX/6GQ8bcxxOTdeea7RZQR
         cwQpCfHM5iyA5YyoYiE/PXceSrNvhNjWE7IaalLFjcTW2PPt4ZrSD6fN37j/RQ6zrBL4
         UZjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858509; x=1786463309;
        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=ER+uu35/NuCBQKkMFT6UQDxN44ZmROCjZqSQxG2REVI=;
        b=esN7SLpwAfrVa+6ydYijbtIrQ18+8cAZ3pVvoQqqiw2rLb1oKedSHz3YyuEtV5MkxN
         LCc+jtLi08PcD1qersDP0irsbMxbfVZFWmbf2XjkjoAxtl+KZmlhrhmJodoLIBUVAuQt
         QxhBSn9Zj40IoASGll/9Am8QDQYhXo8H3ic6K6KXJ0SkCP5MFNGGiWbCyQF6JDZFKHEn
         H8rsE2nzBz1C6xDldz2u7jL8gfKZlzuSgfpADnNOBSX7QscaVHSf8nnBiEsS4MDb8Z81
         wHM0JH5nTrQqTJzzBQW6NpqMq7vlG3hXz3EsqRXTtLG+o0d+UaCHHwWUJDScJmCy/hNn
         t2AQ==
X-Gm-Message-State: AOJu0Yy/fUALqaYi7mZNFBz0hkhqbnNnHvdkLQIhNfbvbSHu2mDd8hgl
	szYiFtQ5ykDmDs1P6USpfgaDPdbtmY3o6qrECDo6MTjaduNitfKwkarqhUIyXQ==
X-Gm-Gg: AR+sD10yWPMyOlfN3rVnNMaO1XZl2aCyosP5EsIdAXwb4kXBvuTHFmxnv/9nMEwXfoP
	jP/6mYYmjMZm7sxIvrKfcDIeRa10D5kRXwr/yAqMEdaU6r5i2wWJUN6iBDZHlmplMvZ6rGN+wUE
	kozU7YyEfrcVJ/c5BpG3czrqX0fjCn4QFBPRofQQYRmj2Yya9bTyRwgGbesdanajBGGxPdpXYVN
	PwAE57cEpP/vzvIo7cjcf2gJRJAfIX1e6b2FZds5V9D5O3B1qpXjhzAzup5FGYVH7oGgyKcvBj9
	bxOXJ9yrfjzxKxoGc9RK3E8o5old9Q70FB1MmeA5nA5WajwpTRSYcl+FxoDwsIONphTv79QHDod
	eZb5+gaQXRoHwin38+JgRYtJrlVinUod+Abmo52KtHpg9MXhELqoNYzkOmg851WcWtn6daTwmJd
	g7sXrLuWlya+j2VYCJF/A/VHkO3y8pjpFoPTicK9e0Y3+lSVW40T9xJYl7e4vid2cMRGDOky4EO
	eYFg7rb1tfAZmO8sRzOMox77RkIOrbaUD5h2Hbh1qOn
X-Received: by 2002:a05:600c:3550:b0:495:607e:5ee7 with SMTP id 5b1f17b1804b1-4980c679513mr352247215e9.17.1785858509525;
        Tue, 04 Aug 2026 08:48:29 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 09/20] xen/riscv: implement make_intc_domU_node()
Date: Tue,  4 Aug 2026 17:47:59 +0200
Message-ID: <17901dd6707a12daef4aa1200c01fc1e0a754f63.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785858510-AA2C49EA-10D82817/10/73395122804
X-purgate-type: spam
X-purgate-size: 3439

Introduce a RISC-V specific function to create an interrupt controller
Device Tree node for DomU domains during dom0less build.

Add make_intc_domU_node() to the dom0less build path and wire it to
a new generic helper, intc_make_domu_dt_node(), which delegates DT
node creation to the active interrupt controller implementation via
vintc_init_ops.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v5-7:
 - Nothing changed. Onlye rebase.
---
Change in v4:
 - Made local variable vintc pointer-to-const.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3:
 - Use const struct vintc_init_ops *init_ops in struct vintc.
 - Drop redundant intc_hw_ops check in make_intc_domU_node().
 - Drop NULL pointer checks in make_intc_domU_node() as we can't start domU
   without properly created interrupt contoller node.
---
Changes in v2:
 - s/intc_make_domu_dt_node/make_intc_domU_node.
 - introduce separate intc_hw_init_ops structure for init operations.
 - Return -EOPNOTSUPP instead of -ENOSYS.
 - Drop const for kinfo argument as it could be changed by interrupt
   controller node creation code.
 - Refactor make_domu_dt_node().
 - Make make_domu_dt_node part of vintc structure as it looks more logical to be
   there.
---
---
 xen/arch/riscv/include/asm/domain.h |  2 ++
 xen/arch/riscv/include/asm/intc.h   | 10 ++++++++++
 xen/arch/riscv/intc.c               |  8 ++++++++
 3 files changed, 20 insertions(+)

diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index 8ae01a5e4dcc..bd43ed08c22c 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -97,6 +97,8 @@ struct arch_domain {
     struct paging_domain paging;
 
     const unsigned long *isa;
+
+    struct vintc *vintc;
 };
 
 #include <xen/sched.h>
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index d7b34fc15ad1..a4e678fad90b 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -16,6 +16,7 @@ enum intc_variant {
 
 struct cpu_user_regs;
 struct irq_desc;
+struct kernel_info;
 
 struct intc_info {
     enum intc_variant hw_variant;
@@ -47,6 +48,15 @@ struct intc_hw_init_ops {
     int (*init)(void);
 };
 
+struct vintc_init_ops {
+    /* Create interrupt controller node for domain */
+    int (*make_domu_dt_node)(struct kernel_info *kinfo);
+};
+
+struct vintc {
+    const struct vintc_init_ops *init_ops;
+};
+
 void intc_preinit(void);
 
 void register_intc_ops(const struct intc_hw_init_ops *init_ops);
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 3600d23bdb5b..e63da5e22efc 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -3,6 +3,7 @@
 #include <xen/acpi.h>
 #include <xen/bug.h>
 #include <xen/device_tree.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/lib.h>
@@ -72,3 +73,10 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
     intc_set_irq_type(desc, desc->arch.type);
     intc_set_irq_priority(desc, priority);
 }
+
+int __init make_intc_domU_node(struct kernel_info *kinfo)
+{
+    const struct vintc *vintc = kinfo->bd.d->arch.vintc;
+
+    return vintc->init_ops->make_domu_dt_node(kinfo);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382272.1625693 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNZ-0000du-Kx; Tue, 04 Aug 2026 15:48:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382272.1625693; Tue, 04 Aug 2026 15:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNZ-0000cn-9P; Tue, 04 Aug 2026 15:48:33 +0000
Received: by outflank-mailman (input) for mailman id 1382272;
 Tue, 04 Aug 2026 15:48:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNY-0000H8-3W
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNX-009QIN-GW
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:31 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209ce-e002-0a2a0a5209dd-0a2a45039d84-4
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:31 +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 <oleksii.kurochko@gmail.com>)
 id 6a7209cf-fae8-0a2a45030019-d155802ae1c7-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:31 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49554ebb87dso29813805e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858511; x=1786463311; 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=SDS5pojmUe3g07xF2AfnOz4IjY2ac3KvA+3GWL6CRYM=;
        b=rExF+rEmSxmns9/JGLQkUQ/vd3TB1JZ/fiz/f0i6v57laz3Eo2/o6P2J8Ai8sYqJab
         funUWIHDqSm7j13kM/9dIwfSEDDaZR2uCtmBxJQckmsZ6hvjwSSN0nMgOBl53b2IGyuS
         GKazF+Hu/fXgjq80QIzzVhXm1WeZ9X1vHJEakIwsiPSNCeyJPM/nghtm3lNkDo1qe10e
         sKzHWjDcPR868Gv+An6oy2S7VF75dIl7agVir5I0L2K1DH1Yg8H5OzxFZ4CDiRGCuRCb
         fngfvjNkq9EBNkvq2R2r9fAFLy78ikkcbzTx3XtG2Ht04fgZqyofxViGeCC7Xd/k6Hxu
         Ytag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858511; x=1786463311;
        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=SDS5pojmUe3g07xF2AfnOz4IjY2ac3KvA+3GWL6CRYM=;
        b=hvGvTRD1j69g6jn+fcki4wxQAkwAGySkgNnayD6Pk6pbn1VeskE2z3IvkG8bc/Fa/1
         oCDBdFXoQiU8va9deZD53x5SwHtTHHbF9DBoj4+Nm77sBi/PWzE0lH3SAp+MDdZsaLX9
         DqfmEIXb1JiYq4l07WNYRH0aoe3Gdr+IqqA89LUU66dCzulgDzo3UFZlhvmnHD6Xm4WA
         W4Wn5VIlCl93SgeBdnPXcslW3jpxcwhilYyPwTXRNv1WMpaH8bNl4w48tXVqc+z7Or7l
         e04/PkQ8X+BIf20qBSrpynJ7576g4pToJ1gZmvgICMQpEIJMpOZbTphk8f6O5qi8dSp6
         /bWQ==
X-Gm-Message-State: AOJu0Yy1EUTNMZXnBF2Pk/yVSTHrq5hzXwlOmEbOjUqHJjdIxySXx+BG
	wznDGUHlF4ddRwGylHR60is+ph6j3menmBvWZKCHAA58uEXuc8rn8QqkfEghhg==
X-Gm-Gg: AR+sD12w+X8tMWLBs1apKm3jEYuUWdXswNGYhL3W4jaox5pHAVwVJZ3eF9Y2ZBUKHIP
	Na0RDHBP5HcSr+lwo0BfqxvNTltS0/BCLJyPm5wq3SIjrjKULbq+vaMoYGLaFXbtf42Z49gzqtV
	u02crfHxtWUvWQ/L2TCadeKqiiHwKq3UsZNM1z8EfjziQJUtpjC/WQSGI1/boIPdbIuccvkZmWa
	T395fqhdtKhmI95F34eEID0IlRsKTO/JKyjsbD8qKc892wtMgOJxynGDbG7O6+lY2fRip14TEfI
	329Y8Wse/cQd5fzp+5s0vCS7XIx+ae0dq1zv4RGQZoJoZ38Y5L7R3iba855w2lLlHSkAqHsRPdl
	96Ugtx8aMNAqFtZfxdcqZuRyXZ2D3LbNfyyiO+GHRrY17vCLQgh+f9lgX1cScQkB30QZeM46k4b
	FOmcVIyIOvdIZ6jHq+iBcK3/CtifmheEY5xGIbsepB0+lAuXNVJvDXWnc1RelPdTDjnXUv5PR4A
	YEJNamdxcBwxWcF6MTKe2RULa/6WnbAnkU++nCiAP4JEw==
X-Received: by 2002:a05:600c:6990:b0:495:4d00:2fc0 with SMTP id 5b1f17b1804b1-4980c673907mr369134765e9.12.1785858510888;
        Tue, 04 Aug 2026 08:48:30 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 10/20] xen/riscv: introduce aia_init() and aia_usable()
Date: Tue,  4 Aug 2026 17:48:00 +0200
Message-ID: <a2d2d30d0810a1ed2c129a35b90898884d262486.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785858511-6E6CE4E9-47FC6A01/10/73395122804
X-purgate-type: spam
X-purgate-size: 3240

aia_init() is going to contain all the logic related to AIA initialization.

At the moment, it only checks whether the SSAIA extension is available,
and if so, sets is_aia_usable (which  indicates more than just the
availability of the extension) to true; it also signifies that the necessary
components (to be introduced in follow-up patches) have been initialized.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Update the guards in asm/aia.h according to CODING_STYLE:
   s/ASM__RISCV__AIA_H/RISCV_AIA_H.
---
Changes in v4:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3:
 - s/is_aia_usable/_aia_usable to drop the is_ prefix while avoiding
   conflict with the aia_usable() function name.
---
Changes in v2:
 - s/is_aia_available/is_aia_usable.
 - Drop return value for aia_init().
 - s/aia_available()/aia_usable().
---
---
 xen/arch/riscv/Makefile          |  1 +
 xen/arch/riscv/aia.c             | 23 +++++++++++++++++++++++
 xen/arch/riscv/include/asm/aia.h | 10 ++++++++++
 xen/arch/riscv/intc.c            |  3 +++
 4 files changed, 37 insertions(+)
 create mode 100644 xen/arch/riscv/aia.c
 create mode 100644 xen/arch/riscv/include/asm/aia.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 2d24670dfc74..8e7a6370eee2 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,3 +1,4 @@
+obj-y += aia.o
 obj-y += aplic.o
 obj-y += cpufeature.o
 obj-y += domain.o
diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c
new file mode 100644
index 000000000000..e31c9c2d24b6
--- /dev/null
+++ b/xen/arch/riscv/aia.c
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/sections.h>
+#include <xen/types.h>
+
+#include <asm/cpufeature.h>
+
+static bool __ro_after_init _aia_usable;
+
+bool aia_usable(void)
+{
+    return _aia_usable;
+}
+
+void __init aia_init(void)
+{
+    if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) )
+        return;
+
+    _aia_usable = true;
+}
diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h
new file mode 100644
index 000000000000..aaa4bf91fc75
--- /dev/null
+++ b/xen/arch/riscv/include/asm/aia.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef RISCV_AIA_H
+#define RISCV_AIA_H
+
+bool aia_usable(void);
+
+void aia_init(void);
+
+#endif /* RISCV_AIA_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index e63da5e22efc..2864a896b677 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -9,6 +9,7 @@
 #include <xen/lib.h>
 #include <xen/spinlock.h>
 
+#include <asm/aia.h>
 #include <asm/intc.h>
 
 static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
@@ -33,6 +34,8 @@ void __init intc_init(void)
 {
     ASSERT(intc_hw_init_ops && intc_hw_init_ops->init);
 
+    aia_init();
+
     if ( intc_hw_init_ops->init() )
         panic("Failed to initialize the interrupt controller drivers\n");
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382273.1625702 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNb-0000xj-0v; Tue, 04 Aug 2026 15:48:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382273.1625702; Tue, 04 Aug 2026 15:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNa-0000xH-Pk; Tue, 04 Aug 2026 15:48:34 +0000
Received: by outflank-mailman (input) for mailman id 1382273;
 Tue, 04 Aug 2026 15:48:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNZ-0000bs-Bx
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNY-009QNa-Oj
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:32 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c8-5cb7-0a2a0a5109dd-0a2a450bdaba-22
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:32 +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 <oleksii.kurochko@gmail.com>)
 id 6a7209d0-b7e8-0a2a450b0019-d155802ee5bf-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:32 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4957eefd361so24591975e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858512; x=1786463312; 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=JS4Pww1oLiCPhcc0rWFj9bF1S4Vy0n1GnD6OKYVDJuA=;
        b=GxGg0aJjEi0m0SDLi8hUlSnkPYL7fkDsdYH5sUjZYE9DPYOUVk92VETxiGbwsEJzZ4
         N9yjlkiCGRDgM2PBvw0yo67d0v5olYejPsCrVQjyYtvu8nX5SLZKHIkqbH52KDHt8JLf
         ZQvMsLybG00c21voFJrp8UCwgy3zDR7dyo9rOV72Tt0DdAuvOS26mRFcertf8Qj4xcKV
         ao/7e7ktoJSnjcoTSCLOwvXTJDfS/NgTB5GfrFqzS7ZSIbesexKjpJo2pprtAAJXUT0d
         xkUO90/Sqt8PuoYKMajMSHwnyNLaXiYl4VCSiJz12IZdLPfAg93z8fHfeddPg5sWrwmZ
         Ms3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858512; x=1786463312;
        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=JS4Pww1oLiCPhcc0rWFj9bF1S4Vy0n1GnD6OKYVDJuA=;
        b=eXXVUQP4ITueUjVnKTuLWh7/HkgS54/mEmKqyK+KYNODb9iMOMvDsB7oSTBUhcopJ4
         /2CG8XanovWRAcpwhdon4//8grM3q1qUsquViMBIEkdXf1S0cQg/mXZMu+VXukjqHTnf
         C/yjkD903RBbDR4Y8tuYkD7yyZsjoYYxwHIeNgqiSc/L8ww0bnok8AhAxx2ujwibAgX0
         9QU5atu3XNsbA5iizkyVm78PvW3hYbV2BMePlcdowXdL4XdXbyAehh2QptnlhMVzrarJ
         N7NbjGgnwWrNTD6ZyCX7JbUgjKib+3YWB6f8a6/Cahuehx+ey8p24bjYZmcL2YM5GZc0
         n+rQ==
X-Gm-Message-State: AOJu0YwDIhOowEV22sQhG8gziZBZ5ioC546q2hXafGGhdWZ0tUFXI910
	cyGKY+Zs+NlYHvGWeto3DrAPesMw27e7lhVbpupCzitvRi2taIBDE4lg+MoDDQ==
X-Gm-Gg: AR+sD10KKuSCcPtxPd0eS455nQJ4Mj3rd+CzQoxv1eRJrzvSlm5TLHkme/+U5iHE5Pq
	0lV89gsNeymYzRM1p/IJMfcKumwUrlsUIRFHOj2/Y93exiffhnHaZ8rMkz6dRMlJkxPqPMMfI8Z
	KndRIjdXMNrGo7WS4XBUmBUsosiC1iF07rATXJDYlJ1eXZRrJ97nfhfjJVLRCLT3j5qjx0nYVhs
	2q6tUFwCS1MyoGbW6jbERGJJD+sudbcDU3LoxjE8jNSROKBOR8fQmHWlkJv9TKNNmsvcVnSbgp7
	7HSfxYcpi0iEmX7HD7U5ib/K/fzVY8ulJ52ACxIuRdhX2+fXArJpnb6k0Gi+aaYzrUqaPU4Rl71
	ceepsywiz1ou6ZBV6vUlA7qCfzbhuNwyKJsujRofLS1f4nY9zA0X62blet1CHHC1LvqaxHiTPcq
	paawXl37CFwXntOIAac117B3ogdnnKpsWl948WrF2EZQp2yU3f5ewF7H0OLBAHTfoQc4J/LC12M
	bb1FtUeqHZByqLOWez97Lps0gM+7yWMLb0RTJmcw72l
X-Received: by 2002:a7b:cd93:0:b0:495:3de8:33a6 with SMTP id 5b1f17b1804b1-4980c65ed1bmr280281485e9.16.1785858512100;
        Tue, 04 Aug 2026 08:48:32 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 11/20] xen/riscv: introduce per-vCPU IMSIC state
Date: Tue,  4 Aug 2026 17:48:01 +0200
Message-ID: <d78555b8b7b683f72a2668d8d2e2da3f89a4fc06.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785858512-A86CA9EA-71F21E10/10/73395122804
X-purgate-type: spam
X-purgate-size: 6490

Each vCPU interacting with the IMSIC requires state to track the
associated guest interrupt file and its backing context.

Introduce a per-vCPU structure to hold IMSIC-related state, including
the guest interrupt file identifier and the CPU providing the backing
VS-file. Access to the guest file identifier is protected by a lock.

Initialize this structure during vCPU setup and store it in arch_vcpu.
The initial state marks the VS-file as software-backed until it becomes
associated with a physical CPU.

Add helper to retrieve the guest interrupt file identifier:
- vcpu_guest_file_id() is going to be used during update of APLIC's
  target register with the pair of information <guest_file_id, cpu_id>
  (to have MSI delivery mode work properly) when guest is trying to
  access vAPLIC's target register.
It will be used in the follow up patches.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Move v->arch.vimsic_state = imsic_state; after full initialization of
   the struct, so the pointer only becomes globally visible once all
   fields are set up.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v4:
-  s/w vs h/w IMSIC VS-file commentary for struct vimsic_state:
   - fix the vsfile_pcpu h/w condition:
     "vsfile_pcpu >= 0" -> "vsfile_pcpu < NR_CPUS"
     (the old wording conflicted with the s/w "== NR_CPUS" case).
   - reorder both comment blocks to the "s/w ... / h/w ..." form for readability.
 - drop IMPOSSIBLE_GUEST_FILE_ID: the s/w IMSIC VS-file is always available
   and corresponds to guest_file_id == 0, which xvzalloc() already provides,
   so the explicit initializer in vcpu_imsic_init() and the macro itself
   are unneeded.
---
Changes in v3:
 - Drop const from imsic_set_guest_file_id() and vcpu_imsic_deinit() as
   it only works due to vimsic_state being a pointer member.
 - Use XVFREE() in vcpu_imsic_deinit() to make it idempotent.
 - Fix SW-file typo in struct vimsic_state comments; should be VS-file.
 - Drop imsic_set_guest_file_id() here, it will be added later when it
   will be nessary to initialise guest file id as the correspondendt code
   in this patch series was reworked and there is no need to use this
   function in arch_vcpu_create().
 - Introduce IMPOSSIBLE_GUEST_FILE_ID and init with it ->guest_file_id.
---
Changes in v2:
 - Rename imsic_state to vimsic_state.
 - Use 'unsigned int' for vsfile_pcpu.
 - Drop initialzation of ->guest_file_id as it will be by default zero.
 - Add the comment about ->guest_file_id field.
 - Drop __init for vcpu_imsic_init() as it could be used during post-boot
   vCPU creation.
 - Update the commit message.
 - Drop locks around ->guest_file_id() in  vcpu_guest_file_id() and imsic_set_guest_file_id().
---
---
 xen/arch/riscv/imsic.c              | 35 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/domain.h |  2 ++
 xen/arch/riscv/include/asm/imsic.h  | 22 ++++++++++++++++++
 3 files changed, 59 insertions(+)

diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index f7b70a8da09e..5a5758e45dc2 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -16,6 +16,7 @@
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/macros.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/spinlock.h>
 #include <xen/xvmalloc.h>
@@ -56,6 +57,11 @@ do {                            \
     csr_clear(CSR_SIREG, v);    \
 } while (0)
 
+unsigned int vcpu_guest_file_id(const struct vcpu *v)
+{
+    return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id);
+}
+
 void __init imsic_ids_local_delivery(bool enable)
 {
     if ( enable )
@@ -312,6 +318,35 @@ static int imsic_parse_node(const struct dt_device_node *node,
     return 0;
 }
 
+int vcpu_imsic_init(struct vcpu *v)
+{
+    struct vimsic_state *imsic_state;
+
+    /* Allocate IMSIC context */
+    imsic_state = xvzalloc(struct vimsic_state);
+    if ( !imsic_state )
+        return -ENOMEM;
+
+    /* Setup IMSIC context  */
+    rwlock_init(&imsic_state->vsfile_lock);
+
+    /*
+     * xvzalloc() already cleared the context, so guest_file_id == 0, i.e. the
+     * always-available s/w IMSIC VS-file. Only vsfile_pcpu needs an explicit
+     * initializer as its s/w VS-file value is NR_CPUS rather than 0.
+     */
+    imsic_state->vsfile_pcpu = NR_CPUS;
+
+    v->arch.vimsic_state = imsic_state;
+
+    return 0;
+}
+
+void vcpu_imsic_deinit(struct vcpu *v)
+{
+    XVFREE(v->arch.vimsic_state);
+}
+
 /*
  * Initialize the imsic_cfg structure based on the IMSIC DT node.
  *
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index bd43ed08c22c..e035b33ddfdc 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -54,6 +54,8 @@ struct arch_vcpu {
 
     struct vtimer vtimer;
 
+    struct vimsic_state *vimsic_state;
+
     register_t hcounteren;
     register_t hedeleg;
     register_t hideleg;
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index c6c59215df20..e2c413487d24 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -11,6 +11,7 @@
 #ifndef ASM_RISCV_IMSIC_H
 #define ASM_RISCV_IMSIC_H
 
+#include <xen/rwlock.h>
 #include <xen/spinlock.h>
 #include <xen/stdbool.h>
 #include <xen/types.h>
@@ -61,7 +62,24 @@ struct imsic_config {
     spinlock_t lock;
 };
 
+struct vimsic_state {
+    /* IMSIC VS-file */
+    rwlock_t vsfile_lock;
+    /*
+     * s/w IMSIC VS-file -> guest_file_id == 0
+     * h/w IMSIC VS-file -> guest_file_id > 0
+     */
+    unsigned int guest_file_id;
+    /*
+     * s/w IMSIC VS-file -> vsfile_pcpu == NR_CPUS
+     * h/w IMSIC VS-file -> vsfile_pcpu < NR_CPUS
+     */
+    unsigned int vsfile_pcpu;
+};
+
 struct dt_device_node;
+struct vcpu;
+
 int imsic_init(const struct dt_device_node *node);
 
 const struct imsic_config *imsic_get_config(void);
@@ -71,4 +89,8 @@ void imsic_irq_disable(unsigned int hwirq);
 
 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);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382277.1625713 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNd-0001MP-04; Tue, 04 Aug 2026 15:48:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382277.1625713; Tue, 04 Aug 2026 15:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNc-0001KD-Nc; Tue, 04 Aug 2026 15:48:36 +0000
Received: by outflank-mailman (input) for mailman id 1382277;
 Tue, 04 Aug 2026 15:48:34 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNa-0000sO-GY
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNZ-009QNa-T6
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:33 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c8-5cb7-0a2a0a5109dd-0a2a450bdaba-26
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:33 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d1-b7e8-0a2a450b0019-d1558030a46a-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:33 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so545515e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858513; x=1786463313; 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=yz5kOHNRF0KkwzsTFaIMw1rEUEyM76GxO23CT2jclP4=;
        b=Tvvh/o2fIIsOxbOs2SpkVCmn09HO2alCl9520s1PtkvRUkLSkPYcf0K0DfO6AD8Xm0
         SKObNcqVl1LUlaRYc1h5PK45h8tl76FJ7x0smlvHFsU+KqU/fnGx/B/JQuiuHrx7cUXe
         p7BjeUdaQ6ld1JLAIAvE0D+9OZeG0NsEulO8ZhQjnbKS4VEPeaN0jCJ75AMxyhJLvyf7
         FlSK9pGSpvRwb0UvQcpaoh39/0CWfVHsqIAJuaxPvthN8IVe6uldzTo4xL9s57u6nyQK
         Z/6W492qUgVjSZaHV/RNq4/Yp3/FqY7grg2B5ePEmAx8Zfau21i7oH32uL+DvtMGNo6G
         hF8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858513; x=1786463313;
        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=yz5kOHNRF0KkwzsTFaIMw1rEUEyM76GxO23CT2jclP4=;
        b=SjEAAWK/kV+pPXx8djLzuhekMbub36j/x5ISTc+jhbX9RjH/1KhCQHzmdJbIw1BVpa
         4L1GpftR0selvYIATuZxwVJ9IJKszbM7VPP0ElmfEzk4ZBqj8kys7VUBM/hSyivREPP1
         VZq5xCH4fQugJPYsRWOWRx91afAjeIxP00LqLFgyEtT7wDTqVtrabvPjS/9LtFqgZ1jI
         MmQ0YAaYE1zPHHSdCGd8qRlV3miEwsBuJz/CbNErTa7I6bFD5l0JNhTKyXG/y0AP+pFO
         JS7n2+1PwTVgWBblKmmfBC47teoC2xWo4P7M5cEmaaRCa2nssL36vdC6NKYshkDI4xAj
         fFAw==
X-Gm-Message-State: AOJu0Yw3S8WxZWaWaDyl6WXmT+F+8kShUCBd9DVahoT3q3TKo1oPk/+6
	k+ksuX0e9GlTDVNm0EycgEYbUU1TFJcoh0z1igDTeFpU/r0sqcd52BLQoZCOWA==
X-Gm-Gg: AR+sD10CiLcnlPOZWrgVFekWp49QrRr89PSEtPhGFOZiGsZaIOpyYcJ7D+RehsDgo2A
	f30Fm25lLFhGfuF1d82XLgE6xm6bwCrX1hbwts747vX81+lbbJYr3OJp5n1+z36sgx+nd2zpWul
	TMA2cWvCX20tDGYOq/A9PKKE4zpUu1zaIYpCHJvOYsAkxPIyhIiQ9lOiedN3Ud7IFy3GWua3rq2
	sdR3RfNLyj5qd+f4mFgAChMgNtKtU5fg8dQ0HpFTT0iWk0gPIbpQ5U3VIJr22I7hsnCigmgJrLS
	SBCQyIT9N6ZtQNGOtQSjrgvXK5Y3l04DTLx8vy4jx+O/IC+Cwd9faFOJPGIcQvU1P/NwY/huAWS
	dZOmPbSziGE46QGpr6pMQXfiFn18o4sx6t9Kd1NiuwU5k7NGZZpUvDpkHeRl2cvjkOpfpzoMwD0
	Uo40g7Snfl86fWf+FymPt2va2yumILGJWxWVnaY+kfRQfDDAmoIkX4f6fNMUuKPsIoFoZhn37ez
	EJDfHeVyioXr8FsMRWfBrX3WNyaN7fjIw==
X-Received: by 2002:a05:600c:1d1f:b0:497:ff5a:38b9 with SMTP id 5b1f17b1804b1-4994e39509emr554855e9.9.1785858513177;
        Tue, 04 Aug 2026 08:48:33 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure
Date: Tue,  4 Aug 2026 17:48:02 +0200
Message-ID: <7a592e36adcb805d87cb0d4c41f3aa96d7eb88e0.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785858513-A9CC79EA-2B2B96C7/10/73395122804
X-purgate-type: spam
X-purgate-size: 9625

At the current development stage, only domain vINTC init and deinit
operations are required, so implement those first.

Initialize vAPLIC's domaincfg to with the interrupt-enable bit set and
MSI delivery mode selected as the current solution is exepcted to have
always IMSIC, and initialize vintc->ops.

Other operations such as emulate_load(), emulate_store(), and is_access()
will be needed once guests are running and MMIO accesses to APLIC MMIO
range must be handled. These will be introduced separately later.

Introduce a structure to describe a virtual interrupt controller (vINTC)
and a vintc_ops structure, which provides operations to emulate load and
store accesses to interrupt controller MMIOs and to check whether a given
address falls within the MMIO range of a specific virtual interrupt
controller.
Note that already existed init_ops field in struct vintc will be init-ed
for APLIC in the follow up patch.

The vAPLIC implementation of these operations will be provided later
once guests can be run and these operations are actually needed.

Introduce these structures here as they are required for the implementation
of domain_vaplic_init() and domain_vaplic_alloc(). Also, introduce
vaplic_init() and init vintc_ops->vcpu_init() with it.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v7:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
 - Update the comment above init_ops member of vintc structure.
---
Changes in v6:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Add explanational comments for fields in struct vintc.
 - Drop unnessary empty line in asm/aplic.h.
 - Update the commit message to tell that init_ops will be init-ed later
   in follow up patch.
 - Init. .domaincfg with only APLIC_DOMAINCFG_RO.
 - Update the comment above APLIC_DOMAINCFG_RO.
 - Add defintion for APLIC_DOMAINCFG_BE.
---
Changes in v4:
 - Change subject of the commit.
 - s/APLIC_DOMAINCFG_RO80/APLIC_DOMAINCFG_RO + added a comment above definition.
 - Drop unnessary blank lines.
---
Changes in v3:
 - Drop ASSERT() before vintc->ops->vcpu_init() in arch_vcpu_create(); a
   NULL deref already produces a sufficient backtrace.
 - Parenthesize macro argument in to_vaplic().
 - Drop __init from domain_vaplic_init() and domain_vaplic_deinit() since
   the caller domain_vintc_init() (follow-up patch) is not __init.
 - Remove pointless zero-initializer for rc in vcpu_vaplic_init().
 - Fix domain_vaplic_deinit() to null d->arch.vintc before freeing, making
   the function idempotent.
 - Drop intc_irq_nums(), (*nr_irqs)(void) hook from intc_hw_operations,
   aplic_nr_irqs(), and vintc->nr_irqs field entirely.
 - Rename vcpu_vaplic_init() to vaplic_init() and drop vgein_assign() and
   imsic_set_guest_file_id() calls; those will be introduced/called later,
   where for sure we will know on which pCPU vCPU as it is required for
   proper h/w IMSIC interrupt file calculation, to have this initialization
   in one place.
 - Introduce vaplic_deinit().
---
Changes in v2:
 - s/vcpu/v for function arguments in struct vintc_ops().
 - Update the comment above is_access() and drop const for addr argument.
 - Update to_vaplic() to work with 'struct domain *'.
 - Drop smsiaddrcfg{h} from vaplic_regs struct as they aren't used for now.
 - Drop inclusion of xen/schec.h from intc.c.
 - use result of xvzalloc() as initializer in vpalic_alloc().
 - Drop goto in domain_vaplic_init().
 - s/XVFREE/xvfree.
 - s/aplic/vintc.
 - Drop __init for vcpu_vaplic_init() as it could be called for secondary CPU bring up.
 - Drop vaplic_alloc().
 - Drop vintc_ops struct, embed callbacks iniside struct vintc.
 - Introduce and init vintc irqs for vAPLIC.
 - Introduce intc_irq_nums() to properly initialize number of vAPLIC's irqs.
---
---
 xen/arch/riscv/Makefile             |  1 +
 xen/arch/riscv/domain.c             | 11 ++---
 xen/arch/riscv/include/asm/aplic.h  |  7 ++++
 xen/arch/riscv/include/asm/intc.h   | 12 ++++++
 xen/arch/riscv/include/asm/vaplic.h | 34 ++++++++++++++++
 xen/arch/riscv/vaplic.c             | 62 +++++++++++++++++++++++++++++
 6 files changed, 119 insertions(+), 8 deletions(-)
 create mode 100644 xen/arch/riscv/include/asm/vaplic.h
 create mode 100644 xen/arch/riscv/vaplic.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 8e7a6370eee2..fcd73c7a2dd5 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -25,6 +25,7 @@ obj-y += smpboot.o
 obj-y += stubs.o
 obj-y += time.o
 obj-y += traps.o
+obj-y += vaplic.o
 obj-y += vmid.o
 obj-y += vm_event.o
 obj-y += vsbi/
diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c
index c9933147595e..45712d305975 100644
--- a/xen/arch/riscv/domain.c
+++ b/xen/arch/riscv/domain.c
@@ -11,6 +11,7 @@
 #include <asm/bitops.h>
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
+#include <asm/intc.h>
 #include <asm/riscv_encoding.h>
 #include <asm/vtimer.h>
 
@@ -155,14 +156,8 @@ int arch_vcpu_create(struct vcpu *v)
     if ( (rc = vcpu_vtimer_init(v)) )
         goto fail;
 
-    /*
-     * As interrupt controller (IC) is not yet implemented,
-     * return an error.
-     *
-     * TODO: Drop this once IC is implemented.
-     */
-    rc = -EOPNOTSUPP;
-    goto fail;
+    if ( (rc = v->domain->arch.vintc->ops->vcpu_init(v)) )
+        goto fail;
 
     return rc;
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index b0724fe6f360..5a7fcb6ec4f1 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -15,8 +15,15 @@
 
 #include <asm/imsic.h>
 
+/*
+ * 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_SOURCECFG_SM_INACTIVE     0x0
 #define APLIC_SOURCECFG_SM_DETACH       0x1
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index a4e678fad90b..875728885292 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -17,6 +17,7 @@ enum intc_variant {
 struct cpu_user_regs;
 struct irq_desc;
 struct kernel_info;
+struct vcpu;
 
 struct intc_info {
     enum intc_variant hw_variant;
@@ -53,8 +54,19 @@ struct vintc_init_ops {
     int (*make_domu_dt_node)(struct kernel_info *kinfo);
 };
 
+struct vintc_ops {
+    /* Initialize some vINTC-related stuff for a vCPU */
+    int (*vcpu_init)(struct vcpu *v);
+
+    /* Deinitialize some vINTC-related stuff for a vCPU */
+    void (*vcpu_deinit)(struct vcpu *v);
+};
+
 struct vintc {
+    /* Callbacks invoked during domain construction only. */
     const struct vintc_init_ops *init_ops;
+    /* Runtime callbacks used for the lifetime of the guest. */
+    const struct vintc_ops *ops;
 };
 
 void intc_preinit(void);
diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h
new file mode 100644
index 000000000000..96080bfbc23b
--- /dev/null
+++ b/xen/arch/riscv/include/asm/vaplic.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * xen/arch/riscv/vaplic.c
+ *
+ * Virtual RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM__RISCV__VAPLIC_H
+#define ASM__RISCV__VAPLIC_H
+
+#include <xen/kernel.h>
+#include <xen/types.h>
+
+#include <asm/intc.h>
+
+struct domain;
+
+#define to_vaplic(d) container_of((d)->arch.vintc, struct vaplic, vintc)
+
+struct vaplic_regs {
+    uint32_t domaincfg;
+};
+
+struct vaplic {
+    struct vintc vintc;
+    struct vaplic_regs regs;
+};
+
+int domain_vaplic_init(struct domain *d);
+void domain_vaplic_deinit(struct domain *d);
+
+#endif /* ASM__RISCV__VAPLIC_H */
diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
new file mode 100644
index 000000000000..c813979a2ecb
--- /dev/null
+++ b/xen/arch/riscv/vaplic.c
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * xen/arch/riscv/vaplic.c
+ *
+ * Virtual RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ * Copyright (c) Vates
+ */
+
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/aia.h>
+#include <asm/imsic.h>
+#include <asm/intc.h>
+#include <asm/vaplic.h>
+
+#include "aplic-priv.h"
+
+static int cf_check vaplic_init(struct vcpu *v)
+{
+    return vcpu_imsic_init(v);
+}
+
+static void cf_check vaplic_deinit(struct vcpu *v)
+{
+    return vcpu_imsic_deinit(v);
+}
+
+static const struct vintc_ops vintc_ops = {
+    .vcpu_init = vaplic_init,
+    .vcpu_deinit = vaplic_deinit,
+};
+
+int domain_vaplic_init(struct domain *d)
+{
+    struct vaplic *vaplic = xvzalloc(struct vaplic);
+
+    if ( !vaplic )
+        return -ENOMEM;
+
+    d->arch.vintc = &vaplic->vintc;
+    d->arch.vintc->ops = &vintc_ops;
+
+    vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO;
+
+    return 0;
+}
+
+void domain_vaplic_deinit(struct domain *d)
+{
+    struct vaplic *vaplic;
+
+    if ( !d->arch.vintc )
+        return;
+
+    vaplic = to_vaplic(d);
+    d->arch.vintc = NULL;
+    xvfree(vaplic);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382279.1625719 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNd-0001U4-QT; Tue, 04 Aug 2026 15:48:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382279.1625719; Tue, 04 Aug 2026 15:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNd-0001SR-Cl; Tue, 04 Aug 2026 15:48:37 +0000
Received: by outflank-mailman (input) for mailman id 1382279;
 Tue, 04 Aug 2026 15:48:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNb-00010v-Fh
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNa-009Gcw-SF
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:34 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c5-bab6-0a2a0a5309dd-0a2a4509cbee-26
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:34 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d2-be1a-0a2a45090019-d1558031d14e-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:34 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4955158f26aso23065955e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858514; x=1786463314; 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=pNfWXKz7OiThFTVcFdBZ62/fmTIqtlbdTWRNjBnnGpc=;
        b=Dk6uZXJA6qAlrAEqZEzvjVa6D3gz9tyNKvBzDAAAQgXzM6TrstVeX6i/Kx9Wtd8slt
         wBrXRXMnQ2B13Pu0HJoZhB2VtqgBgIJE81v7HYSoRc07qMi6JG325CgQCJ3G/4tfJKrN
         t7115Sh2s5NnvwkimPGnReFyoFTBguMWT3T+THso8gnCSNKj/FTnijMed0ZTRX9eycV5
         7XvyPUDv/2Fc2JIF6uvwXqKF2sCiK76hrC72/w4uAJ05CVYD1g50Kv8/TgzgB5U9QRsV
         rZz61yeDNVn/rOsD8q3WtFQVU7sJ0niKRxEl5PHsLuJeEHeJDuoWfWY9wMgZ/vtst+Ya
         YbMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858514; x=1786463314;
        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=pNfWXKz7OiThFTVcFdBZ62/fmTIqtlbdTWRNjBnnGpc=;
        b=MhObpbTaYk2WRVx5jlNxzYZs/0plYNqVlwgVwDV4c3VDQcsyXCulswdVzZ/r/YdYpp
         s6GAqCyiBKQI5u2DqC5MzUWLXAbLvNB3F+rFfmgcXzAiwaB/fUvh3e/7g5TufJIhwoWq
         yHP+cKBcPIg9+9d6tOB2zOrGYS9sONw/vRi2e6DsZTBQekkjX9jEqzTnRMaCEQ8DkJvM
         TsFkisdP2VYZMmR+ns4XnjGTyNcE/rR01DaPAD71OwOPfZhWQafUA9MgHZztOUd37ZhI
         IytT0INBabW+9+HSI5rkrsOaIRTHpHKQE8/GDb1wcDvosMoEb33C3pxZBb6m8GJ4/0fd
         w/Mg==
X-Gm-Message-State: AOJu0YzATc0rCfseCtAQKT5WMH+OLSjzsvczPd2qiQCGrd2gG2am8F/3
	gR5/JGurlyDywMau3twEd4dCT5EvOWvBf4KaRbc1ghwrjfvWYiTM72t4AmWOyw==
X-Gm-Gg: AR+sD127y/ABlsbUx3uvRb3z4y9MRGbMBC+31svGRHtDi543iAuj8l27akIMYknTjCm
	5HyGXBcLijvg565hfdsZNxfm3bZOqaCHGu+PA8iROrenPlmtvsFDKXhkKMlx2GXMI1tUdxUaN7B
	HF1/qYwvbTMu7K4PBR76PyWeZEkD11KBVoANxiUIOqAqTa0XKEBHHqyjkw8EIIbXGD2O2WWvq0p
	DM4QRBaxuD8Th0V/kZ3gzcWvUIRxCYN4gA2nYfJvoZ4JUc3j9tEi6e1UShbqOM9u/Le0qaxCV05
	f+0/ixr1K6oGVT5rIGb5zHWvgDFfgqLHb8omPy3Q0rbctSrIFkwaf8POQRs7guoAmL38myJg7Z9
	RFBvNBYBJbw1U/hUrMOHycZFwqLUXVbmog9tG4bL5jU09EscHD+F4iejAWKnpZl5x7MeUGI3Hpi
	FNXt7hbUSv/ZkHDudYEDhnTjP/ydpwCu0wpTHzVCm8R4e+yesBeA0pyKyc4P+sfjI5jcsxEj2JR
	DcYVHK070iqgP6yzxkEF9MBHuRISipnZg==
X-Received: by 2002:a05:600c:c113:b0:495:4689:1e98 with SMTP id 5b1f17b1804b1-4980c674e1dmr306196645e9.10.1785858514288;
        Tue, 04 Aug 2026 08:48:34 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 13/20] xen/riscv: introduce (de)initialization helpers for vINTC
Date: Tue,  4 Aug 2026 17:48:03 +0200
Message-ID: <30c9d0f24a2e9b8ffafebb33a832ff0d61671544.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785858514-FCE14034-DB5ECD08/10/73395122804
X-purgate-type: spam
X-purgate-size: 3635

Add common helpers domain_vintc_init() and domain_vintc_deinit() to
allocate and deallocate a virtual interrupt controller (vINTC)
structure and initialize basic virtual interrupt controller registers.

domain_vintc_deinit() isn't called at the moment as arch_domain_destroy()
is implemented as stub at the moment.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - s/printk/printk_once().
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v4:
 - Drop the comment from domain_vintc_init() about guests receiving a
   virtual interrupt controller that mirrors the host hardware as there
   can (and eventually should) be alternatives.
 - Finish renaming intc_version to intc_variant in domain_vintc_(de)init()
   (enum intc_variant, info->hw_variant, local variable) started in the
   prev patch.
---
Changes in v3:
 - Drop redundant printk() from domain_vintc_deinit()'s default case to
   avoid duplicate messages when init fails.
 - Add a comment to domain_vintc_init() clarifying that guests currently
   receive a virtual interrupt controller that mirrors the host hardware.
---
Changes in v2:
 - Drop __init for domain_vintc_(de)init().
 - Update the commit message.
---
---
 xen/arch/riscv/domain.c           |  3 +++
 xen/arch/riscv/include/asm/intc.h |  3 +++
 xen/arch/riscv/intc.c             | 35 +++++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c
index 45712d305975..4db9c28662c7 100644
--- a/xen/arch/riscv/domain.c
+++ b/xen/arch/riscv/domain.c
@@ -308,6 +308,9 @@ int arch_domain_create(struct domain *d,
     if ( (rc = p2m_init(d, config)) != 0)
         goto fail;
 
+    if ( (rc = domain_vintc_init(d)) )
+        goto fail;
+
     return rc;
 
  fail:
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 875728885292..6fc0e620e937 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -79,4 +79,7 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 
 void intc_handle_external_irqs(struct cpu_user_regs *regs);
 
+int domain_vintc_init(struct domain *d);
+void domain_vintc_deinit(struct domain *d);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 2864a896b677..f5c8af6ddea4 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -11,6 +11,7 @@
 
 #include <asm/aia.h>
 #include <asm/intc.h>
+#include <asm/vaplic.h>
 
 static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
 
@@ -83,3 +84,37 @@ int __init make_intc_domU_node(struct kernel_info *kinfo)
 
     return vintc->init_ops->make_domu_dt_node(kinfo);
 }
+
+int domain_vintc_init(struct domain *d)
+{
+    int ret = -EOPNOTSUPP;
+    const enum intc_variant variant = intc_hw_ops->info->hw_variant;
+
+    switch ( variant )
+    {
+    case INTC_APLIC:
+        ret = domain_vaplic_init(d);
+        break;
+
+    default:
+        printk_once("vintc (variant:%d) isn't implemented\n", variant);
+        break;
+    }
+
+    return ret;
+}
+
+void domain_vintc_deinit(struct domain *d)
+{
+    const enum intc_variant variant = intc_hw_ops->info->hw_variant;
+
+    switch ( variant )
+    {
+    case INTC_APLIC:
+        domain_vaplic_deinit(d);
+        break;
+
+    default:
+        break;
+    }
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382280.1625725 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNf-0001dU-3X; Tue, 04 Aug 2026 15:48:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382280.1625725; Tue, 04 Aug 2026 15:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNe-0001bl-6I; Tue, 04 Aug 2026 15:48:38 +0000
Received: by outflank-mailman (input) for mailman id 1382280;
 Tue, 04 Aug 2026 15:48:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNc-0001I1-LM
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNc-009Gcw-1e
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:36 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c9-bab6-0a2a0a5309dd-0a2a4508eace-12
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:35 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d3-f659-0a2a45080019-d1558033ac15-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:35 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-495590dde14so34298045e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48:35 -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-49949fcb46esm116430355e9.5.2026.08.04.08.48.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type: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=1785858515; x=1786463315; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=l7ZIghm4wlZpqQWikoFDy/4FVF6m3wHWKUUWrNvkWao=;
        b=ZTtd98gIekj8jEQRyKWKcBTNE6Pd8sn+nYTZsJfn9tDcE+mMVW6LsaZUhPpweZEZAV
         37nmU3i9gsPYsg9lbi3vicfBjZ1yy0o2DgdlW3ziIxeg8OHGW1SnmEPCZCMeps6MGIzJ
         2s9h+ueoOnnXUyS7FVarmeF1fUEedBnStMq13Udth8vYkoxRzgdBI5a7tEJuajHUelEU
         dxWJu/sYCvTrRldA3ILn/tQISeAkMw1vm+eGBa4S1fgKMYPJnDD4bAGuX7sNj3wAD445
         nCP9FutvThgjTvJVO5W8HRXYiiA5Y7UZwrVgKQT7mfi3aDf+PiqQf+IcifOCU0twdeH5
         URPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858515; x=1786463315;
        h=content-transfer-encoding:content-type: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=l7ZIghm4wlZpqQWikoFDy/4FVF6m3wHWKUUWrNvkWao=;
        b=CHHoqig/WU5M6+xWzN0oz8sH0uc7pwR/LIXLJeULMxJXPVD90hFIFI80K1Uw6up+SY
         wRGA6UeKqSQkIZ4qpDSY+9k4c39NYhbkrJo7uOpbhesbXQ1PNMwc7ysx68INwZ+uGbt4
         3fNygtA9XMxddfWZO841tsPXfklWoS4Kw61BYh6q+oePcUCuDpBaWXdQOepyuNH78/Ar
         Pi06yfrO0xiv7dUEe724ysWPm1i/Q1NJM3jCrRRt0gkSdyLOcvSlyrQeJ9DlRWUSQvCv
         Bp3Mr7cnlYZ8EoPazIurtFqZRahRDQxiXqpzC0llD7x1KW2cko88v3MCIlMGVcmGQpFC
         HvWA==
X-Gm-Message-State: AOJu0Yx3K58epaimVj6G4JIdnLs6nSZI6ivtF6zoSU7uVkDtE64jlCOy
	lcu1Nlv6IVKPi1pkQ+znmU1NesGgLfJQyg7tOMsA/97zg0gfnN6AdXYMhfMcNg==
X-Gm-Gg: AR+sD11xTBXWCcEWlh0tETy/kgeLuVl8+tE3FbxhpIL9EDM+XVnWvumrff9V1OBv/N5
	icQSGWhuRDodfOotMQs2lnejplhuVD+1GNe5OAWaInX/1O1jpBEpg40o3iiPb14wn4i77wOhyms
	7MUhMRX3VZtlhwwcj4Vn9DDC4tXRJzAmcDdQcgHgHxOvVkwex5XNVMhN27+qReImL7Zzqr+UgqJ
	7uLJmSUx/4lC08hjE8j7O5Sue13H0EOEM3mMC/L4WaSAXvUaFIYRCmOGcX5tMztdFlL/eyRQP8N
	KA9m8qW8/ywWxNDVkBnjNUS4aRznjU/tUzHSskz/z6aXBIqCt0XMktlU+Rb2d22ghQ3kc9hftix
	MFFiDQTxoH4Tu2T1iPHI3sMEAyqJ/bYtZ5I8NDoE6RbEY6qJ0wGdXNB7QNaVBnO0udUhBNlOuzI
	TR1bTRPdCac8L3/N7Y1L4m0UmMpyGaoGlgsKRGinoUNXrCDWijjNES0ZSNcq9/Zl2krVZPypZqi
	J0wVLXV3UkFnyhmgrr++419v1tpYYvKDg==
X-Received: by 2002:a05:600c:8b54:b0:495:4859:8f9b with SMTP id 5b1f17b1804b1-4980c674f25mr402292425e9.9.1785858515349;
        Tue, 04 Aug 2026 08:48:35 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 14/20] xen/riscv: generate IMSIC DT node for guest domains
Date: Tue,  4 Aug 2026 17:48:04 +0200
Message-ID: <c75d73c0153a036b300173ef2d5937d91849b36c.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785858515-D497287B-E186827D/10/73395122804
X-purgate-type: spam
X-purgate-size: 10732

Guests using the IMSIC interrupt controller require a corresponding
Device Tree description.

Add support for generating an IMSIC node when building the guest DT.
This allows guests to discover and use the IMSIC interrupt controller.

The value choosen for GUEST_IMSIC_S_BASE is an address which is typically
used for IMSIC and QEMU.

DT-building functions are marked __init because domain creation happens at
boot time, before the init sections are freed. In a typical deployment
libxl creates the interrupt controller node in userspace and hands the
complete FDT to Xen, so these functions are only called during early
domain construction.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v7:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v6:
 - Simplify initialization of guest_num_msis.
 - s/sizeof(vimsic_name)/ARRAY_SIZE(...).
 - Add empty line between declaration(s) and statement(s) in make_domu_dt_node().
 - define GUEST_IMSIC_MAX_MSIS as 255U to avoid '+0U' when min(...) is used.
---
Changes in v5:
 - s/GUEST_IMSIC_NUM_MSIS/GUEST_IMSIC_MAX_MSIS throughout.
 - Changed __read_mostly → __ro_after_init on guest_num_msis, since the value
   is set once during __init and never again.
 - Made imsic_parse_node() __init.
 - Moved the min(GUEST_IMSIC_MAX_MSIS, ...) cap into imsic_parse_node() right
   after guest_num_msis is assigned, so the bound is applied once at init
   time rather than on every DT node construction call.
 - Removed the now-unnecessary num_msis local variable from
   vimsic_make_domu_dt_node(); guest_num_msis is used directly.
 - s/snprintf(buf, sizeof(buf), ...)/snprintf(buf, ARRAY_SIZE(buf), ...)
   in guest_imsic_set_interrupt_extended_prop().
 - Added decl. of vimsic_make_domu_dt_node() in this patch instead of next.
---
Changes in v4:
 - Add a comment for guest_num_msis explaining that it is host-dependent
   and therefore identical for every domain, which is why a single global
   is used instead of a per-domain value.
 - Reduce vimsic_name[] from 128 to 32 bytes, which is enough to hold
   "/soc/imsic@" plus a 64-bit hex address.
 - Add a comment before GUEST_IMSIC_S_BASE noting that the value is the
   address typically used for IMSIC by QEMU.
 - s/__ULL/_UL for defintion of GUEST_IMSIC_S_BASE.
---
Changes in v3:
 - s/__ro_after_init/__read_mostly for guest_num_msis.
 - Use IMSIC_MAX_ID as default for guest_num_msis instead of imsic_cfg.nr_ids.
 - Drop base_addr local variable in guest_imsic_make_reg_property(); use
   GUEST_IMSIC_S_BASE directly and introduce size to avoid spelling
   IMSIC_MMIO_PAGE_SZ * d->max_vcpus twice.
 - Change irq_ext type from uint32_t * to __be32 * in
   guest_imsic_set_interrupt_extended_prop().
 - Move phandle declaration into the loop body.
 - Extend commit message to explain why __init is used for DT-building
   functions: libxl creates the interrupt controller node before handing
   the FDT to Xen, so these functions are only invoked during boot-time
   domain construction.
 - Re-order patch before APLIC DT node creation patch.
 - Update commit message.
---
Changes in v2:
 - s/imsic_make_reg_property/guest_imsic_make_reg_property.
 - s/imsic_set_interrupt_extended_prop/guest_imsic_set_interrupt_extended_prop.
 - Use initalizer for regs[] array in imsic_make_reg_property().
 - Move buf[] insde the for() loop.
 - Correct check of returned phandle.
 - Drop local variable len.
 - /s/XVFREE/xvfree in imsic_set_interrupt_extended_prop().
 - Drop initializer for local variable data.
 - s/uint32_t/unsinged int for pos and cpu in imsic_set_interrupt_extended_prop().
 - Drop next_phandle as it is now in common code.
 - Introduce vcpu_imsic_deinit.
 - Refactor vimsic_make_domu_dt_node() to avoid usage of host IMSIC dt node.
---
---
 xen/arch/riscv/imsic.c                    | 143 +++++++++++++++++++++-
 xen/arch/riscv/include/asm/guest-layout.h |   6 +
 xen/arch/riscv/include/asm/imsic.h        |   3 +
 3 files changed, 151 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index 5a5758e45dc2..ffce77209c26 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -13,8 +13,12 @@
 #include <xen/const.h>
 #include <xen/cpumask.h>
 #include <xen/device_tree.h>
+#include <xen/domain.h>
 #include <xen/errno.h>
+#include <xen/fdt-domain-build.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/macros.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
@@ -34,6 +38,21 @@ static struct imsic_config imsic_cfg = {
     .lock = SPIN_LOCK_UNLOCKED,
 };
 
+/*
+ * Number of MSIs available to a guest. Determined by the host interrupt
+ * controller, so it is identical for every domain -- hence a single global
+ * rather than a per-domain value.
+ */
+static unsigned int __ro_after_init guest_num_msis;
+
+#define GUEST_IMSIC_COMPATIBLE "riscv,imsics"
+
+/*
+ * Value is inspired by what QEMU is using for riscv,num-ids property for IMSIC
+ * node.
+ */
+#define GUEST_IMSIC_MAX_MSIS 255U
+
 #define IMSIC_DISABLE_EIDELIVERY    0
 #define IMSIC_ENABLE_EIDELIVERY     1
 #define IMSIC_DISABLE_EITHRESHOLD   1
@@ -182,7 +201,7 @@ static int __init imsic_get_parent_hartid(const struct dt_device_node *node,
  * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
  * which should be ignored by the hypervisor.
  */
-static int imsic_parse_node(const struct dt_device_node *node,
+static int __init imsic_parse_node(const struct dt_device_node *node,
                             unsigned int *nr_parent_irqs,
                             unsigned int *nr_mmios)
 {
@@ -285,6 +304,11 @@ static int imsic_parse_node(const struct dt_device_node *node,
         return -ENOENT;
     }
 
+    if ( dt_property_read_u32(node, "riscv,num-guest-ids", &tmp) )
+        guest_num_msis = min(GUEST_IMSIC_MAX_MSIS, tmp);
+    else
+        guest_num_msis = GUEST_IMSIC_MAX_MSIS;
+
     if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
          (imsic_cfg.nr_ids > IMSIC_MAX_ID) )
     {
@@ -522,3 +546,120 @@ int __init imsic_init(const struct dt_device_node *node)
 
     return rc;
 }
+
+static int __init guest_imsic_make_reg_property(struct domain *d, void *fdt)
+{
+    paddr_t size = IMSIC_MMIO_PAGE_SZ * d->max_vcpus;
+    __be32 regs[4] = {
+        cpu_to_be32(GUEST_IMSIC_S_BASE >> 32),
+        cpu_to_be32(GUEST_IMSIC_S_BASE),
+        cpu_to_be32(size >> 32),
+        cpu_to_be32(size),
+    };
+
+    return fdt_property(fdt, "reg", regs, sizeof(regs));
+}
+
+static int __init guest_imsic_set_interrupt_extended_prop(struct domain *d,
+                                                          void *fdt)
+{
+    unsigned int cpu, pos = 0;
+    __be32 *irq_ext;
+    int res;
+
+    irq_ext = xvzalloc_array(__be32, d->max_vcpus * 2);
+    if ( !irq_ext )
+        return -ENOMEM;
+
+    for ( cpu = 0; cpu < d->max_vcpus; cpu++ )
+    {
+        char buf[64];
+        uint32_t phandle;
+
+        snprintf(buf, ARRAY_SIZE(buf), "/cpus/cpu@%u/interrupt-controller", cpu);
+        phandle = fdt_get_phandle(fdt, fdt_path_offset(fdt, buf));
+
+        if ( !phandle )
+        {
+            res = -ENODEV;
+            goto out;
+        }
+
+        irq_ext[pos++] = cpu_to_be32(phandle);
+        irq_ext[pos++] = cpu_to_be32(IRQ_S_EXT);
+    }
+
+    res = fdt_property(fdt, "interrupts-extended", irq_ext,
+                       d->max_vcpus * 2 * sizeof(*irq_ext));
+
+ out:
+    xvfree(irq_ext);
+
+    return res;
+}
+
+int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo,
+                                    unsigned int *phandle)
+{
+    int res;
+    void *fdt = kinfo->fdt;
+    char vimsic_name[32];
+    unsigned int vimsic_phandle;
+
+    res = snprintf(vimsic_name, ARRAY_SIZE(vimsic_name), "/soc/imsic@%lx",
+                   GUEST_IMSIC_S_BASE);
+    if ( res >= ARRAY_SIZE(vimsic_name) )
+    {
+        dprintk(XENLOG_DEBUG, "vimsic name is truncated\n");
+        return -ENOBUFS;
+    }
+
+    res = fdt_begin_node(fdt, vimsic_name);
+    if ( res )
+        return res;
+
+    res = fdt_property_string(fdt, "compatible", GUEST_IMSIC_COMPATIBLE);
+    if ( res )
+        return res;
+
+    res = guest_imsic_make_reg_property(kinfo->bd.d, fdt);
+    if ( res )
+        return res;
+
+    res = guest_imsic_set_interrupt_extended_prop(kinfo->bd.d, fdt);
+    if ( res )
+        return res;
+
+    res = fdt_property_u32(fdt, "riscv,num-ids", guest_num_msis);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "msi-controller", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_u32(fdt, "#msi-cells", 0);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_u32(fdt, "#interrupt-cells", 0);
+    if ( res )
+        return res;
+
+    vimsic_phandle = alloc_phandle(kinfo);
+    if ( !vimsic_phandle )
+        return -EOVERFLOW;
+
+    res = fdt_property_cell(fdt, "phandle", vimsic_phandle);
+    if ( res )
+        return res;
+
+    if ( phandle )
+        *phandle = vimsic_phandle;
+
+    return fdt_end_node(fdt);
+}
diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h
index 68d95a09394c..5e566450bdfa 100644
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -3,6 +3,12 @@
 
 #include <public/xen.h>
 
+/*
+ * Base address of the guest's supervisor-mode IMSIC. The value is the address
+ * typically used for IMSIC by QEMU.
+ */
+#define GUEST_IMSIC_S_BASE _UL(0x28000000)
+
 #define GUEST_RAM_BANKS   2
 
 /*
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index e2c413487d24..e1ec3d03c4e9 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -78,6 +78,7 @@ struct vimsic_state {
 };
 
 struct dt_device_node;
+struct kernel_info;
 struct vcpu;
 
 int imsic_init(const struct dt_device_node *node);
@@ -93,4 +94,6 @@ int vcpu_imsic_init(struct vcpu *v);
 void vcpu_imsic_deinit(struct vcpu *v);
 unsigned int vcpu_guest_file_id(const struct vcpu *v);
 
+int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phandle);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382281.1625732 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNi-00024O-A0; Tue, 04 Aug 2026 15:48:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382281.1625732; Tue, 04 Aug 2026 15:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNh-00020M-7G; Tue, 04 Aug 2026 15:48:41 +0000
Received: by outflank-mailman (input) for mailman id 1382281;
 Tue, 04 Aug 2026 15:48:38 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNd-0001Uq-S6
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNd-009GkK-8R
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:37 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d5-e002-0a2a0a5209dd-0a2a4507cb76-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:37 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d4-b4ea-0a2a45070019-d1558030d9a3-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:37 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4954a32cf1eso16288195e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858516; x=1786463316; 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=lLGWWikfegmq1d6uXZbQV5K+lLsNHD8dZ0j3uuHsqqQ=;
        b=rA8tZNhn33A8EsPIN5q3K4SEIb1pdOnMsx0lSgwwovCe5Ti2znKlsierFNKMYnAWuc
         DpTy42hvPgraFOb748R1Bl2fivVGnA6cj2r32qKW4Gmbg2qb7gRf6B0RlTA0QUj7M4nV
         1IX9Sj4D1EFjnGPbHIlCdetDNqbjq2appRBHUKD0n9ORgBoyFN0kczY/090VhotUqf+C
         YPsuiExbi5WTgM8mSU5F5zWhybVpcLESBrZDtLXBj4RGGeyVJz4OIHcQNLHvEUHkgk9O
         LXonRg5GbFAFjOP6MPbx4HaEHyQaV4VW2hgqenWcmXbXqE5Ffw03LAjqTWqushO2KyS8
         ZLmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858516; x=1786463316;
        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=lLGWWikfegmq1d6uXZbQV5K+lLsNHD8dZ0j3uuHsqqQ=;
        b=FthLbcK+N1WLynPLnxUOfyRGJGTq8FbxzQovsCh/SdSiV7x8j2aNQB6ktMm33VSnPG
         dz8BmlsvvUaXKpnu8T7u7vlnDL1RorZQvjkg1JGAjosv7JAbvMdPGmJ4s/hwxkkJT0Tg
         Tj8qjOgKpfyGa2yUoaLWRXO8wPcgiBfN4LGlDc5AeDwn6Zbpc7rYHBfuh5cnNrRl2cIY
         RjfMzUoVPNGMAauOoTsbDb8NfEA/6ralNKwvFkn2niMjFW3cAfy1UlFufYSbOTq5iGRJ
         rge1x0ysJ+nmy5kFyMu9uf/mQzaNxV/g07WJCiVpWCpElqo6EImYJGYf+VH6MBmeSBUO
         MH4A==
X-Gm-Message-State: AOJu0YzzxLdP7N5iHv99E+t3LVJiMZ2fnUkI9Ka1VGEf6HWa/DmJe00j
	YI+cLdJebG25nNvZvwirYlIAAhpTPNmDy/nmCp4Mk5DyOKt6UApRzKS3dD6nvQ==
X-Gm-Gg: AR+sD13fyewUVOxokvqTyyPw/S12dwQQwaQVnGS2t2H5tWvOEd7FnTxmdxSUoleJeLH
	Bgf4fATc8Dx+LDS+6c/7NkvbZXvLzqDVl188H9qnzpx6s8wzBzXE39RjwJlOYTFR7qur5bg8Wqw
	uKCQR5dYmhAkiPY6AZYnBAWlT4V707mOe7SrL47GfYjcBN4yi7rW7ttKn1s/OOZFeY0mjQ6W7Jz
	D9BE9YdljV4NPmr/ImokTD8Mqd0yRGwKlnll15b+9otVuEovjsge+NqL2A4GIKmhcVur2QBTVM8
	vUBeP2RIcSfk2roZp2AcA1liRLDBmhnTxV5XbhcyrTS2hwJ4i2Mr6h0wUu16I2c5ylmAn0Hpe7q
	ADn0Clf2sN55CL1jY8I2PJQBgSaMu68nlnyg4zg8BbDKRnNGzBKVG15cn3G7/hl7EnjoMPBmW4D
	/1QksUlHdn0/xCZfQfTkEHXBPKymaLvjGcaDG5R1rG4EEmsgVQBJRBbrQKrRHg+HD4Lx1lKhyzk
	m54JY1rRha+H8CEOqLVQCx5npVPvtKVa+hXdSS30h/+
X-Received: by 2002:a05:600c:19cf:b0:498:2b1f:e0c6 with SMTP id 5b1f17b1804b1-4982b1fe255mr170113975e9.18.1785858516531;
        Tue, 04 Aug 2026 08:48:36 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 15/20] xen/riscv: create APLIC DT node for guest domains
Date: Tue,  4 Aug 2026 17:48:05 +0200
Message-ID: <6ecfa02afc7237ee229a1ca2d12369b226ca816f.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785858517-A5CC7AE4-A83E76A3/10/73395122804
X-purgate-type: spam
X-purgate-size: 9020

Guests require a Device Tree description of the interrupt controller
topology. Add support for creating an APLIC node when building the
guest DT.

Provide stub for imsic_make_dt_node() it will be introduced properly
in follow-up patch.

The value chosen for GUEST_APLIC_S_BASE is based on QEMU one.

DT-building functions are marked __init because domain creation happens at
boot time, before the init sections are freed. In a typical deployment
libxl creates the interrupt controller node in userspace and hands the
complete FDT to Xen, so these functions are only called during early
domain construction.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v7:
 - Update the comment for guest_aplic_num_sources: drop "wired" to be less
   confusing, and mention that it is identical for every domain only for
   now.
 - Use ARRAY_SIZE() instead of sizeof() for the size argument of
   snprintf() in vaplic_make_domu_dt_node().
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6:
 - Redefine GUEST_APLIC_MAX_SOURCES as 96U to avoid '+OU' in min(...).
 - s/guest_num_sources/guest_aplic_num_sources.
---
Changes in v5:
 - Drop pointless initializer for local variable res in
   vaplic_make_domu_dt_node().
 - Limit guest_num_sources in the similar way to IMSIC.
 - Rename VAPLIC_NUM_SOURCES to GUEST_APLIC_MAX_SOURCES to be aligned with
   the similar place in vIMSIC related code.
---
Changes in v4:
 - Drop spurious <xen/fdt-kernel.h> and <xen/libfdt/libfdt.h> includes from
   aplic.c (mistakenly added, they belong to vaplic.c).
 - Reduce vaplic_name[] from 128 to 32 bytes in vaplic_make_domu_dt_node().
 - Use __initconstrel (with const) for init_ops instead of __initdata.
 - s/__ULL/_UL for defintion of GUEST_APLIC_S_BASE.
---
Changes in v3:
 - Fix rebase conflicts becuase of this patch is reordered after IMSIC DT
   node creation is intoduced.
 - Update the commit message.
 - Move initialization of domaincfg with APLIC_DOMAINCFG_RO80 from this
   patch to earlier.
 - Change paddr_t aplic_size to unsigned int in vaplic_make_domu_dt_node()
   and replace the UB (after it started to be uint) aplic_size >> 32 with
   an explicit 0 in the DT reg property.
 - Add BUILD_BUG_ON() to be sure that aplic size isn't bigger then
   UINT32_MAX.
---
Changes in v2:
 - Avoid as max as possible of host properties inheritance. Only number of
   APLIC's irqs are checked what leads to an introduction of
   get_aplic_irqs_num().
 - Move this patch earlier what leads to an introduction of
   vimsic_make_domu_dt_node() stub.
 - s/vimsic_make_domu_dt_node/imsic_make_domu_dt_node.
 - Refactor vimsic_make_domu_dt_node() to avoid re-usage of APLIC host
   properties.
 - Drop next_phandle as it is now in common code.
 - Drop const for kinfo argument of vimsic_make_domu_dt_node() is is
   going to be updated inside vimsic_make_domu_dt_node().
 - Use introduced before vintc->num_irqs.
---
---
 xen/arch/riscv/aplic-priv.h               | 13 ++++
 xen/arch/riscv/aplic.c                    |  2 +
 xen/arch/riscv/include/asm/aplic.h        |  8 +++
 xen/arch/riscv/include/asm/guest-layout.h |  6 ++
 xen/arch/riscv/vaplic.c                   | 77 +++++++++++++++++++++++
 5 files changed, 106 insertions(+)

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
index 85e0d028d1ae..35100d3a64fe 100644
--- a/xen/arch/riscv/aplic-priv.h
+++ b/xen/arch/riscv/aplic-priv.h
@@ -34,4 +34,17 @@ struct aplic_priv {
     const struct imsic_config *imsic_cfg;
 };
 
+/*
+ * Value is inspired by what QEMU is using for riscv,num-sources property for
+ * APLIC node.
+ */
+#define GUEST_APLIC_MAX_SOURCES 96U
+
+/*
+ * Specifies the number of interrupt sources supported by guest APLIC domain.
+ * Could be limited by host interrupt controller and is identical for every
+ * domain for now.
+ */
+extern unsigned int guest_aplic_num_sources;
+
 #endif /* ASM_RISCV_APLIC_PRIV_H */
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index d08401db46b3..c2d7183e1852 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -92,6 +92,8 @@ static int __init cf_check aplic_init(void)
         panic("%s: failed to get number of interrupt sources\n",
               node->full_name);
 
+    guest_aplic_num_sources = min(GUEST_APLIC_MAX_SOURCES, aplic_info.num_irqs);
+
     if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) )
         aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index 5a7fcb6ec4f1..07318aaac25d 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -34,6 +34,14 @@
 
 #define APLIC_TARGET_HART_IDX_SHIFT 18
 
+#define APLIC_IDC_SIZE          32
+
+#define APLIC_MIN_SIZE          0x4000
+#define APLIC_SIZE_ALIGN(x)     ROUNDUP(x, APLIC_MIN_SIZE)
+
+#define APLIC_SIZE(nr_cpus)     (APLIC_MIN_SIZE + \
+                                 APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus)))
+
 struct aplic_regs {
     uint32_t domaincfg;         /* 0x0000 */
     uint32_t sourcecfg[1023];   /* 0x0004 */
diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h
index 5e566450bdfa..90603f06bb91 100644
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -3,6 +3,12 @@
 
 #include <public/xen.h>
 
+/*
+ * Base address of the guest's supervisor-mode APLIC. The value is the address
+ * typically used for APLIC by QEMU.
+ */
+#define GUEST_APLIC_S_BASE _UL(0xd000000)
+
 /*
  * Base address of the guest's supervisor-mode IMSIC. The value is the address
  * typically used for IMSIC by QEMU.
diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
index c813979a2ecb..72bb2c4dc3c5 100644
--- a/xen/arch/riscv/vaplic.c
+++ b/xen/arch/riscv/vaplic.c
@@ -9,6 +9,8 @@
  */
 
 #include <xen/errno.h>
+#include <xen/fdt-kernel.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/sched.h>
 #include <xen/xvmalloc.h>
 
@@ -19,6 +21,12 @@
 
 #include "aplic-priv.h"
 
+unsigned int __ro_after_init guest_aplic_num_sources;
+
+#define VAPLIC_COMPATIBLE "riscv,aplic"
+
+#define FDT_VAPLIC_INT_CELLS 2
+
 static int cf_check vaplic_init(struct vcpu *v)
 {
     return vcpu_imsic_init(v);
@@ -29,6 +37,74 @@ static void cf_check vaplic_deinit(struct vcpu *v)
     return vcpu_imsic_deinit(v);
 }
 
+static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *kinfo)
+{
+    struct domain *d = kinfo->bd.d;
+    int res;
+    void *fdt = kinfo->fdt;
+    unsigned int msi_parent_phandle;
+    char vaplic_name[32];
+    unsigned int aplic_size = APLIC_SIZE(d->max_vcpus);
+    const __be32 reg[] = {
+        cpu_to_be32(GUEST_APLIC_S_BASE >> 32),
+        cpu_to_be32(GUEST_APLIC_S_BASE),
+        cpu_to_be32(0),
+        cpu_to_be32(aplic_size),
+    };
+
+    BUILD_BUG_ON(APLIC_SIZE(MAX_VIRT_CPUS) > UINT_MAX);
+
+    res = snprintf(vaplic_name, ARRAY_SIZE(vaplic_name), "/soc/aplic@%lx",
+                   GUEST_APLIC_S_BASE);
+    if ( res >= sizeof(vaplic_name) )
+    {
+        dprintk(XENLOG_DEBUG, "vaplic name is truncated\n");
+        return -ENOBUFS;
+    }
+
+    res = vimsic_make_domu_dt_node(kinfo, &msi_parent_phandle);
+    if ( res )
+        return res;
+
+    res = fdt_begin_node(fdt, vaplic_name);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#interrupt-cells", FDT_VAPLIC_INT_CELLS);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "reg", reg, sizeof(reg));
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "riscv,num-sources", guest_aplic_num_sources);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_string(fdt, "compatible", VAPLIC_COMPATIBLE);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "msi-parent", msi_parent_phandle);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
+    if ( res )
+        return res;
+
+    return fdt_end_node(fdt);
+}
+
+static const struct vintc_init_ops __initconstrel init_ops = {
+    .make_domu_dt_node = vaplic_make_domu_dt_node,
+};
+
 static const struct vintc_ops vintc_ops = {
     .vcpu_init = vaplic_init,
     .vcpu_deinit = vaplic_deinit,
@@ -43,6 +119,7 @@ int domain_vaplic_init(struct domain *d)
 
     d->arch.vintc = &vaplic->vintc;
     d->arch.vintc->ops = &vintc_ops;
+    d->arch.vintc->init_ops = &init_ops;
 
     vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO;
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382283.1625736 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNj-0002CY-34; Tue, 04 Aug 2026 15:48:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382283.1625736; Tue, 04 Aug 2026 15:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNi-0002Af-8q; Tue, 04 Aug 2026 15:48:42 +0000
Received: by outflank-mailman (input) for mailman id 1382283;
 Tue, 04 Aug 2026 15:48:39 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNf-0001hs-7W
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNe-009GkK-I9
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:38 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c7-e002-0a2a0a5209dd-0a2a450a9cf8-22
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:38 +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 <oleksii.kurochko@gmail.com>)
 id 6a7209d6-f2d2-0a2a450a0019-d155802dcd15-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:38 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-498028b3d5eso35007495e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858518; x=1786463318; 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=C5MjzH6tWZC1vulhg4mfpL7kW1xzkWEA9okhBx32l/4=;
        b=BGjXKKHSX+OxGm7JiMS1/+msZoeIiY5qyUFqLHUIdRsrBHFK17RTbIRW95oZ08j2wM
         raXjmOXfF5+GoKrRxvuVNNUo2S6O05ZFoBLEOWJtK3ke3MSbdFYLKqCsEeIv451L5asx
         x2QfIMgkGw9ji3EzMa6XDdijhIx1TC8U4RYdRa0+yI1rRYQxli+Pw5+dDiLqxH1LuUCD
         DnpGO6lkwEOnJPOilk92piO47bMch1/vg5skTT07F2BttPdx0kfkyHok+D9jxLAv/kIB
         qhLV5NaGCk35Un9R16yu/huoV39ChkK1pWHh0i8QBatsvJa6rAfOPCTUph4VUv/g2l6e
         XPTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858518; x=1786463318;
        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=C5MjzH6tWZC1vulhg4mfpL7kW1xzkWEA9okhBx32l/4=;
        b=HwwiqPx+x53H+p9DfMSDj32dUZ3ws/RUQ12d8tIoxRbvn2XL79Gdz7PKPih28nnmZq
         uHfA4EFvn+j8la6no5ByajWzQ5WAGA8R0M25yPJuQ/bFRFKJ0R4Pr32e6N3P0xKbuwHS
         NBJooGSE/AvoLz4xCUmHeZNVqopPQ1hJVXkFv23K1XmdH03te1el0ojFompJsyBIGYcC
         f054z4eWekL/2Dqax4FoSSEIQjHTEtJZMMeASpR5KFI+R7gI7wbgQAIirna8ODr+vOSm
         6mDmlS7bz4Gukn6nZu12H1Co3G3MB7lODWNDXIYVWP8ccpnLdsHbJfZ9WJI2cWq3Y0+G
         pWWQ==
X-Gm-Message-State: AOJu0YzsMnX+dVxDxV8Uk0+RaWj3i3FUzUbOMnC/29kPT425iPnX6x0A
	iC3bAXVFkrF8fOCBLErFe8dHnkM1HmZ4LTnqricVSHoupqMCuPzBUDZXmeS10g==
X-Gm-Gg: AR+sD13F6tuWyjWPuRUWLft3eV6A10hivuEwc+niIlQYm+kfiNBMc2sLG5tr/9wJ8hH
	6NaQqtUFy3OZbTSdJQ/H8KhGzegq5bQErlYpo+1coEWuZIjzLZv40d6JrqcNtly1tfYR/uvUI7c
	CoPeLGotAj05wszCQmvtsIRXsq0C4F1/XgNRlfrt0Hj8awiLExi11TMx5A3KuKmb93tkNNczpBA
	F7+NkwdssCdhZmarneHxaI5DPZ0CPCcmybEbUQ8j4DFV2mBF4HXVxTGwa+A0iUfP2xU667ipPdn
	pDoNo8+Nd0OhZePCdfuCforJYGQ8ARngZr4cAFj588YMNU/XCXAHdiQimUEtbNwz9jbJKboahsY
	o1YOp07vBEsH623eOjzGftuFacblM8HrHKecjd7Q/6LWELj9OMH4SpfUzs4+CV7RX3fsVjdsScG
	MBLwr0mXhERLyHCEasmX5mn72ejHQy4/sLncUMG+w797S4DxDiaM2IAXGVsSJcuvM8go07yF7cx
	J0fTPFjKEEf8PDzg0eVlbjvVhvlEU6VfBbZL0npYlTp
X-Received: by 2002:a05:600c:840f:b0:496:c379:b2a1 with SMTP id 5b1f17b1804b1-4980c66d7bbmr299616715e9.2.1785858517394;
        Tue, 04 Aug 2026 08:48:37 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: [PATCH v7 16/20] xen/riscv: implement IRQ routing for device passthrough
Date: Tue,  4 Aug 2026 17:48:06 +0200
Message-ID: <cbbaea00bd461284f6440dbd11653a64f7434b94.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785858518-508CDCFC-81DEB2F6/10/73395122804
X-purgate-type: spam
X-purgate-size: 25224

dom0less device passthrough requires granting guest domains access to
device interrupts. Introduce map_device_irqs_to_domain() to enumerate
a DT node's interrupt properties, skipping those not owned by
the primary interrupt controller (as at the moment I haven't seen usages
of it), and map_irq_to_domain() to grant domain access and configure
Xen's interrupt descriptor accordingly. Sharing IRQ between domains is
rejected.

Both map_irq_to_domain() and map_device_irqs_to_domain() are marked
__overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to
__init, so the functions are init-only and need no XSM check; with
CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime
entry point is dt_overlay_domctl(), which performs the XSM checks at the
domctl layer.  RISC-V does not wire up DT overlay yet, so today these are
strictly __init; if/when overlay support is added, the domctl-level XSM
gating must be added together with it, as on Arm.

route_irq_to_guest() and release_irq() manage irq_desc ownership for
guest-assigned interrupts. Each assignment carries a small irq_guest
structure as irqaction::dev_id, recording the owning domain and virtual
IRQ number which is 1:1 mapped to physical IRQ number. A per-domain
vIRQ allocation bitmap (used_irqs in struct vintc), managed by
vintc_reserve_virq(), prevents the same vIRQ being claimed twice.

Host and guest interrupts may differ in some operations (EOI timing in
particular, possibly others): a host IRQ is completed once Xen's handler
runs, whereas a passthrough IRQ must defer the physical completion until
the guest issues its own EOI, otherwise a still-asserted level line would
immediately retrigger and storm. This affects only the .end callback;
the rest of hw_interrupt_type is shared, hence the separate host and
guest hw_interrupt_type instances.

With APLIC+IMSIC, guest interrupts are delivered directly by hardware
through the IMSIC, bypassing do_IRQ(). The _IRQ_GUEST branch in
do_IRQ() is therefore left as BUG() until a platform without direct
IMSIC delivery is encountered.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v7:
 - Build device.c as device.init.o: everything it provides is
   __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB
   stays Arm-only.  Unlike Arm, which picks device.o/device.init.o based
   on that config, RISC-V cannot enable it, so the choice is
   unconditional for now.
 - Don't have release_irq() free the guest IRQ info anymore: set
   free_on_release = false and free 'info' explicitly in
   release_guest_irq(), i.e. reinstate the xvfree() dropped in v5. The
   action stays embedded in struct irq_guest, so a single allocation
   still covers both, but it no longer has to be the structure's first
   member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer
   that merely happened to coincide with the allocation base are gone.
   The ->dev_id concern from v5 doesn't apply: release_irq() clears
   desc->action under desc->lock and waits for in-flight handling before
   returning, so nothing can observe ->dev_id once 'info' is freed.
 - Move 'action' to the end of struct irq_guest and reword its comment
   accordingly.
 - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that
   the embedded action is fully initialized (action.handler was left
   uninitialized before).
 - route_irq_to_guest(): free 'info' via the common free_info label when
   intc_route_irq_to_guest() fails, now that release_irq() no longer
   frees it.
 - Drop a stray blank line ahead of release_irq().
---
Changes in v6:
 - size nr_virqs as guest_aplic_num_sources + 1 to reserve APLIC's 1-indexed
   source 0, so the highest source/irq could be reserved.
---
Changes in v5:
 - add early -EINVAL return in route_irq_to_guest() if domain is dying
 - use __clear_bit() instead of clear_bit() in release_guest_irq()
   since desc->lock is already held
 - remove irq_get_domain() wrapper; inline irq_get_guest_info(desc)->d
    at its single call site
 - reword IRQ_GUEST comment in do_IRQ() for clarity
 - move XVFREE(used_irqs) before the switch so it is freed prior to
   variant-specific vintc teardown
 - fix missing space in dt_dprintk() format string split across lines
 - Drop 'inline' for irq_get_guest_info() and leave it only static.
 - Drop xfree(info) from release_guest_irq() to avoid a potential
   dangling-pointer issue with the ->dev_id field. Now that
   'struct irqaction action;' is embedded into 'struct irq_guest',
   'info' will be freed as part of release_irq() at the end.
---
Changes in v4:
 - Update the commit message.
 - Mark map_irq_to_domain() and map_device_irqs_to_domain() as
   __overlay_init (mirroring Arm) and include <xen/dt-overlay.h>.
 - Fix grammar in the controller-skip comment ("IRQ" -> "IRQs").
 - Drop the redundant 'base' local in guest_imsic_make_reg_property();
   use GUEST_IMSIC_S_BASE directly.
 - Rename vintc::irq_nums -> nr_virqs and update all users.
 - Guard domain_vintc_deinit() against a NULL d->arch.vintc.
 - Use smp_rmb() instead of smp_mb() in release_irq()'s wait loop and
   document how it pairs with the spin_unlock() in do_IRQ().
 - In release_guest_irq(), reject live unrouting from a non-dying domain
   (-EBUSY) and clear _IRQ_GUEST under desc->lock so a concurrent
   release for the same IRQ bails out instead of double-freeing 'info'.
 - Tidy spurious whitespace in release_irq()'s spin_lock/unlock calls.
---
Changes in v3:
 - Drop extraneous "to" from "Unable to permit to %pd" message.
 - Move res/irq/rirq to loop scope; use nirq as declaration initializer.
 - Hoist irq_ranges check before the loop (it is loop-invariant).
 - Remove spurious forward declarations (struct dt_device_node, struct
   rangeset) from intc.h; remove all three from setup.h.
 - Use __set_bit() instead of set_bit() in intc_route_irq_to_guest()
   since desc->lock is always held on every write path for desc->status.
 - Use XVFREE() instead of xvfree() in domain_vintc_deinit().
 - Rename allocated_irqs -> used_irqs in struct vintc.
 - Fix dangling desc->action in release_irq()'s !IRQ_HAS_MULTIPLE_ACTION
   path by nulling *action_ptr after saving the action pointer.
 - Use true (not 1) for free_on_release in route_irq_to_guest().
 - Use %pd for domain printing in route_irq_to_guest() error paths.
 - Introduce release_guest_irq() to pair with route_irq_to_guest() and
   plug the irq_guest info leak; call it from domain_vintc_deinit()
   for each vIRQ recorded in used_irqs.
---
Changes in v2:
 - Rework IRQ mapping in more common (similar approach to Arm).
---

Updates

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Changes in v7:
 - Build device.c as device.init.o: everything it provides is
   __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB
   stays Arm-only.  Unlike Arm, which picks device.o/device.init.o based
   on that config, RISC-V cannot enable it, so the choice is
   unconditional for now.
 - Don't have release_irq() free the guest IRQ info anymore: set
   free_on_release = false and free 'info' explicitly in
   release_guest_irq(), i.e. reinstate the xvfree() dropped in v5.  The
   action stays embedded in struct irq_guest, so a single allocation
   still covers both, but it no longer has to be the structure's first
   member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer
   that merely happened to coincide with the allocation base are gone.
   The ->dev_id concern from v5 doesn't apply: release_irq() clears
   desc->action under desc->lock and waits for in-flight handling before
   returning, so nothing can observe ->dev_id once 'info' is freed.
 - Move 'action' to the end of struct irq_guest and reword its comment
   accordingly.
 - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that
   the embedded action is fully initialized (action.handler was left
   uninitialized before).
 - route_irq_to_guest(): free 'info' via the common free_info label when
   intc_route_irq_to_guest() fails, now that release_irq() no longer
   frees it.
 - Drop a stray blank line ahead of release_irq().
---
---
 xen/arch/riscv/Makefile           |   1 +
 xen/arch/riscv/aplic.c            |   4 +
 xen/arch/riscv/device.c           |  94 +++++++++++++
 xen/arch/riscv/include/asm/intc.h |   9 ++
 xen/arch/riscv/include/asm/irq.h  |   5 +
 xen/arch/riscv/intc.c             |  45 ++++++
 xen/arch/riscv/irq.c              | 226 ++++++++++++++++++++++++++++++
 xen/arch/riscv/vaplic.c           |   9 ++
 8 files changed, 393 insertions(+)
 create mode 100644 xen/arch/riscv/device.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index fcd73c7a2dd5..3b948c11dd61 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,6 +1,7 @@
 obj-y += aia.o
 obj-y += aplic.o
 obj-y += cpufeature.o
+obj-y += device.init.o
 obj-y += domain.o
 obj-y += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index c2d7183e1852..3681f0669efb 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -325,9 +325,13 @@ static const hw_irq_controller aplic_xen_irq_type = {
     .set_affinity = aplic_set_irq_affinity,
 };
 
+/* At the moment there is no difference between guest and Xen ops */
+#define aplic_guest_irq_type aplic_xen_irq_type
+
 static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
     .host_irq_type       = &aplic_xen_irq_type,
+    .guest_irq_type      = &aplic_guest_irq_type,
     .handle_interrupt    = aplic_handle_interrupt,
     .set_irq_type        = aplic_set_irq_type,
 };
diff --git a/xen/arch/riscv/device.c b/xen/arch/riscv/device.c
new file mode 100644
index 000000000000..f54d0fdaa7ab
--- /dev/null
+++ b/xen/arch/riscv/device.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include <xen/device_tree.h>
+#include <xen/dt-overlay.h>
+#include <xen/errno.h>
+#include <xen/iocap.h>
+#include <xen/rangeset.h>
+#include <xen/sched.h>
+
+#include <asm/intc.h>
+
+int __overlay_init map_irq_to_domain(struct domain *d, unsigned int irq,
+                                     bool need_mapping, const char *devname)
+{
+    int res;
+
+    res = irq_permit_access(d, irq);
+    if ( res )
+    {
+        printk(XENLOG_ERR "Unable to permit %pd access to IRQ %u\n", d, irq);
+        return res;
+    }
+
+    if ( need_mapping )
+    {
+        /*
+         * Checking the return of vintc_reserve_virq is not
+         * necessary. It should not fail except when we try to map
+         * the IRQ twice. This can legitimately happen if the IRQ is shared.
+         */
+        vintc_reserve_virq(d, irq);
+
+        res = route_irq_to_guest(d, irq, irq, devname);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR "Unable to map IRQ%u to %pd\n", irq, d);
+            return res;
+        }
+    }
+
+    dt_dprintk("  - IRQ: %u\n", irq);
+
+    return 0;
+}
+
+int __overlay_init map_device_irqs_to_domain(struct domain *d,
+                                             struct dt_device_node *dev,
+                                             bool need_mapping,
+                                             struct rangeset *irq_ranges)
+{
+    unsigned int i, nirq = dt_number_of_irq(dev);
+
+    if ( irq_ranges )
+        return -EOPNOTSUPP;
+
+    /* Give permission and map IRQs */
+    for ( i = 0; i < nirq; i++ )
+    {
+        int res, irq;
+        struct dt_raw_irq rirq;
+
+        res = dt_device_get_raw_irq(dev, i, &rirq);
+        if ( res )
+        {
+            printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n",
+                   i, dt_node_full_name(dev));
+            return res;
+        }
+
+        /*
+         * Don't map IRQs that have no physical meaning
+         * ie: IRQs whose controller is not APLIC/IMSIC/PLIC.
+         */
+        if ( rirq.controller != dt_interrupt_controller )
+        {
+            dt_dprintk("irq %u not connected to primary controller. Connected to %s\n",
+                       i, dt_node_full_name(rirq.controller));
+            continue;
+        }
+
+        irq = platform_get_irq(dev, i);
+        if ( irq < 0 )
+        {
+            printk("Unable to get irq %u for %s\n", i, dt_node_full_name(dev));
+            return irq;
+        }
+
+        res = map_irq_to_domain(d, irq, need_mapping, dt_node_name(dev));
+        if ( res )
+            return res;
+    }
+
+    return 0;
+}
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 6fc0e620e937..a9bf909a436e 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -15,6 +15,7 @@ enum intc_variant {
 };
 
 struct cpu_user_regs;
+struct domain;
 struct irq_desc;
 struct kernel_info;
 struct vcpu;
@@ -34,6 +35,9 @@ struct intc_hw_operations {
     /* hw_irq_controller to enable/disable/eoi host irq */
     const struct hw_interrupt_type *host_irq_type;
 
+    /* hw_irq_controller to enable/disable/eoi guest irq */
+    const struct hw_interrupt_type *guest_irq_type;
+
     /* Set IRQ type */
     void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
     /* Set IRQ priority */
@@ -63,6 +67,8 @@ struct vintc_ops {
 };
 
 struct vintc {
+    unsigned int nr_virqs;
+    unsigned long *used_irqs;
     /* Callbacks invoked during domain construction only. */
     const struct vintc_init_ops *init_ops;
     /* Runtime callbacks used for the lifetime of the guest. */
@@ -76,10 +82,13 @@ void register_intc_ops(const struct intc_hw_init_ops *init_ops);
 void intc_init(void);
 
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+int intc_route_irq_to_guest(struct irq_desc *desc, unsigned int priority);
 
 void intc_handle_external_irqs(struct cpu_user_regs *regs);
 
 int domain_vintc_init(struct domain *d);
 void domain_vintc_deinit(struct domain *d);
 
+bool vintc_reserve_virq(const struct domain *d, unsigned int virq);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 62648bdc4252..66067747dc0f 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -52,6 +52,11 @@ void init_IRQ(void);
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq);
 
+int route_irq_to_guest(struct domain *d, unsigned int virq,
+                       unsigned int irq, const char *devname);
+
+int release_guest_irq(struct domain *d, unsigned int virq);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index f5c8af6ddea4..372c8d3a20f9 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -7,7 +7,9 @@
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
 
 #include <asm/aia.h>
 #include <asm/intc.h>
@@ -78,6 +80,22 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
     intc_set_irq_priority(desc, priority);
 }
 
+int intc_route_irq_to_guest(struct irq_desc *desc,
+                            unsigned int priority)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+
+    ASSERT(intc_hw_ops->guest_irq_type);
+
+    desc->handler = intc_hw_ops->guest_irq_type;
+    __set_bit(_IRQ_GUEST, &desc->status);
+
+    intc_set_irq_type(desc, desc->arch.type);
+    intc_set_irq_priority(desc, priority);
+
+    return 0;
+}
+
 int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
     const struct vintc *vintc = kinfo->bd.d->arch.vintc;
@@ -101,12 +119,31 @@ int domain_vintc_init(struct domain *d)
         break;
     }
 
+    if ( !ret )
+    {
+        d->arch.vintc->used_irqs =
+            xvzalloc_array(unsigned long,
+                           BITS_TO_LONGS(d->arch.vintc->nr_virqs));
+        if ( !d->arch.vintc->used_irqs )
+            ret = -ENOMEM;
+    }
+
     return ret;
 }
 
 void domain_vintc_deinit(struct domain *d)
 {
     const enum intc_variant variant = intc_hw_ops->info->hw_variant;
+    unsigned int virq;
+
+    if ( !d->arch.vintc )
+        return;
+
+    for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ )
+        if ( test_bit(virq, d->arch.vintc->used_irqs) )
+            release_guest_irq(d, virq);
+
+    XVFREE(d->arch.vintc->used_irqs);
 
     switch ( variant )
     {
@@ -118,3 +155,11 @@ void domain_vintc_deinit(struct domain *d)
         break;
     }
 }
+
+bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
+{
+    if ( virq >= d->arch.vintc->nr_virqs )
+        return false;
+
+    return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
+}
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index b5066fc3e981..9a8cd013e857 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -12,11 +12,26 @@
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/irq.h>
+#include <xen/sched.h>
 #include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
 
 #include <asm/hardirq.h>
 #include <asm/intc.h>
 
+/* Describe an IRQ assigned to a guest */
+struct irq_guest
+{
+    struct domain *d;
+    unsigned int virq;
+    /*
+     * The action of a guest IRQ has the same lifetime as this structure, so
+     * embed it here to have both covered by a single allocation. Consequently
+     * it must not be freed by release_irq() (see free_on_release below).
+     */
+    struct irqaction action;
+};
+
 static irq_desc_t irq_desc[NR_IRQS];
 
 struct irq_desc *irq_to_desc(unsigned int irq)
@@ -198,6 +213,14 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
     if ( desc->handler->ack )
         desc->handler->ack(desc);
 
+    if ( desc->status & IRQ_GUEST )
+        /*
+         * With APLIC + IMSIC, guest interrupts bypass Xen and are delivered
+         * directly to the guest. Without IMSIC, interrupts would be trapped
+         * by Xen and would need injecting into the guest here.
+         */
+        panic("unimplemented");
+
     if ( desc->status & IRQ_DISABLED )
         goto out;
 
@@ -227,3 +250,206 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
     spin_unlock(&desc->lock);
     irq_exit();
 }
+
+static struct irq_guest *irq_get_guest_info(struct irq_desc *desc)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(test_bit(_IRQ_GUEST, &desc->status));
+    ASSERT(desc->action != NULL);
+
+    return desc->action->dev_id;
+}
+
+void release_irq(unsigned int irq, const void *dev_id)
+{
+    struct irq_desc *desc;
+    unsigned long flags;
+    struct irqaction *action, **action_ptr;
+
+    desc = irq_to_desc(irq);
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    action_ptr = &desc->action;
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    for ( ;; )
+    {
+        action = *action_ptr;
+        if ( !action )
+        {
+            printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", irq);
+            spin_unlock_irqrestore(&desc->lock, flags);
+            return;
+        }
+
+        if ( action->dev_id == dev_id )
+            break;
+
+        action_ptr = &action->next;
+    }
+
+    /* Found it - remove it from the action list */
+    *action_ptr = action->next;
+#else
+    action = *action_ptr;
+    *action_ptr = NULL;
+#endif
+
+    /* If this was the last action, shut down the IRQ */
+    if ( !desc->action )
+    {
+        desc->handler->shutdown(desc);
+        __clear_bit(_IRQ_GUEST, &desc->status);
+    }
+
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    /*
+     * Wait to make sure it's not being used on another CPU.
+     *
+     * The read barrier pairs with the spin_unlock() in do_IRQ(): once we
+     * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the
+     * writes do_IRQ() made to desc (e.g. desc->action) before releasing the
+     * lock, so it is safe to free the action below.
+     */
+    do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) );
+
+    if ( action->free_on_release )
+        xvfree(action);
+}
+
+int release_guest_irq(struct domain *d, unsigned int virq)
+{
+    struct irq_desc *desc = irq_to_desc(virq);
+    struct irq_guest *info;
+    unsigned long flags;
+    int ret = -EINVAL;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    if ( !test_bit(_IRQ_GUEST, &desc->status) )
+        goto unlock_err;
+
+    info = irq_get_guest_info(desc);
+    if ( d != info->d )
+        goto unlock_err;
+
+    /*
+     * Live IRQ unrouting from a running domain is not supported: the tear-down
+     * drops desc->lock across release_irq()/xvfree() and relies on no
+     * concurrent route_irq_to_guest() being issued for this domain. Only permit
+     * it for a dying domain, where assignment is frozen and no new routes can
+     * appear.
+     */
+    if ( !d->is_dying )
+    {
+        ret = -EBUSY;
+        goto unlock_err;
+    }
+
+    /*
+     * Clear _IRQ_GUEST while still holding the lock so that a concurrent
+     * release_guest_irq() for the same IRQ observes it and bails out, rather
+     * than capturing the same 'info' and double-freeing it below.
+     */
+    __clear_bit(_IRQ_GUEST, &desc->status);
+
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    release_irq(desc->irq, info);
+    xvfree(info);
+
+    return 0;
+
+ unlock_err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return ret;
+}
+
+/* Route an IRQ to a specific guest */
+int route_irq_to_guest(struct domain *d, unsigned int virq,
+                       unsigned int irq, const char *devname)
+{
+    struct irq_guest *info;
+    struct irq_desc *desc;
+    unsigned long flags;
+    int retval = 0;
+
+    if ( d->is_dying )
+        return -EINVAL;
+
+    desc = irq_to_desc(irq);
+
+    info = xvzalloc(struct irq_guest);
+    if ( !info )
+        return -ENOMEM;
+
+    info->d = d;
+    info->virq = virq;
+
+    info->action.dev_id = info;
+    info->action.name = devname;
+    /* The action is part of 'info', thus it is freed together with it. */
+    info->action.free_on_release = false;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    /*
+     * If the IRQ is already used by someone
+     *  - If it's the same domain -> Xen doesn't need to update the IRQ desc.
+     *  For safety check if we are not trying to assign the IRQ to a
+     *  different vIRQ.
+     *  - Otherwise -> For now, don't allow the IRQ to be shared between
+     *  Xen and domains.
+     */
+    if ( desc->action != NULL )
+    {
+        if ( test_bit(_IRQ_GUEST, &desc->status) )
+        {
+            struct domain *ad = irq_get_guest_info(desc)->d;
+
+            if ( d != ad )
+            {
+                printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n",
+                       irq, ad);
+                retval = -EBUSY;
+            }
+            else if ( irq_get_guest_info(desc)->virq != virq )
+            {
+                printk(XENLOG_G_ERR
+                       "%pd: IRQ %u is already assigned to vIRQ %u\n",
+                       d, irq, irq_get_guest_info(desc)->virq);
+                retval = -EBUSY;
+            }
+        }
+        else
+        {
+            printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
+            retval = -EBUSY;
+        }
+        goto out;
+    }
+
+    retval = _setup_irq(desc, 0, &info->action);
+    if ( retval )
+        goto out;
+
+    retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY);
+
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    if ( retval )
+    {
+        release_irq(desc->irq, info);
+        goto free_info;
+    }
+
+    return 0;
+
+ out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+ free_info:
+    xvfree(info);
+
+    return retval;
+}
diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
index 72bb2c4dc3c5..8af748b1f1ed 100644
--- a/xen/arch/riscv/vaplic.c
+++ b/xen/arch/riscv/vaplic.c
@@ -123,6 +123,15 @@ int domain_vaplic_init(struct domain *d)
 
     vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO;
 
+    /*
+     * APLIC source 0 is reserved; sources are numbered 1..guest_aplic_num_sources
+     * and used directly as indices into used_irqs. Size the bitmap to
+     * guest_aplic_num_sources + 1 so the highest source has a valid slot
+     * (index 0 stays unused). Without the +1, vintc_reserve_virq() can't record
+     * the top source, so domain_vintc_deinit() never releases it.
+     */
+    d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1;
+
     return 0;
 }
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382284.1625744 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNk-0002Oo-Kn; Tue, 04 Aug 2026 15:48:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382284.1625744; Tue, 04 Aug 2026 15:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNj-0002KO-IX; Tue, 04 Aug 2026 15:48:43 +0000
Received: by outflank-mailman (input) for mailman id 1382284;
 Tue, 04 Aug 2026 15:48:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNf-0001mH-Lq
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNf-009GkK-0p
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:39 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209ce-e002-0a2a0a5209dd-0a2a45039d84-26
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:39 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d6-fae8-0a2a45030019-d155802ead15-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:38 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49558ce01afso26775235e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858518; x=1786463318; 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=fJC5+YtFPL568P1Nwi/6zQXEX1Gc8Q+IUKJN5b49m2w=;
        b=sBzQ2F05A/eqIYdR9SxI/+qK+dW8EEqOZo0y/tYH37zqMKyijk8OoTC/gP4cuHigVs
         AGnVRuoDszt4mAtKovMyIJyCkM1XIyRusfdicgsyUjWUtdlsv1mnzWqvDbAKDeg6+b56
         1a78yp0JkjC+jsavsnbhg4jDUMGBztPYmgCrHOIfZoU1F09CiCyjphO1ti0YqKOk3YRG
         rC6EOcCIsrPk9bvCLRkQV5xaU2yuerBM07oLE3xCUoHCSqY9fmSDLz6F3btw7fw9LIgf
         4vgRvGg35QbbOIjie18hE2n4FTm5XYd03ZleacweTAmrO5a/6rCF6OSK2+Rf72Wb4vHs
         QBOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858518; x=1786463318;
        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=fJC5+YtFPL568P1Nwi/6zQXEX1Gc8Q+IUKJN5b49m2w=;
        b=FS+8oYyR740BMdHP0/OjR2G/Eo74ORp81tk7GXSy17t2Bpze6biN/C3ZtiHuYmayjm
         nuF+R7+8tGihju0vNo6fR9tnFfpR5LJxsPS5kjCFJmwLpaXyOlPOzRJxViBDGkq288JG
         mocWdJWo0EiBnM6+ktyzyCrwOCLQwMAuUa7nCnY2FKBx5wEhNF+NXP8rLHswl+QHwzjp
         W1uLvB+tYYVbrRHdxDVrIa0B3zmNNfdgz8r8u7moTZTsvd+/9exZvLCGbq+gW/7a5PVn
         HSeUPxe/OZ1AySlMmbIelCQgE2Jf1XBitYPOsNvW2LBfj9cQekXrUTi6GC9JbqiMq+9l
         ZBmA==
X-Gm-Message-State: AOJu0YyzSiioIoaG5BD6t9obbgPGcI8xis9s47ebgjUgQYYEDlOJ8fuw
	0rtubE+Zu5OSTz20ZCx/aVSwdM1/Z3ZhSyTlR4OGtNChjhxmPc40nEtevjpK+A==
X-Gm-Gg: AR+sD10AcgyMz4Mgbn0ERB/cQmXyDETfG83fU07f2PXl4wUuuRPKZia4EGxp2mxTFDC
	j03D7gjixuwPiO66ew7B+gfPXZHdX2KJnOudun8XoBerjQZNmwkaGiyeaDMPsc3wyDwQgQ3QdLj
	4Vhns6D8R8dvzVkKgerSiIfJHsxLSpRcJbEf1jRe522HCiwiT4uUo84GGPAYHyTzoFSt1B+MTid
	FPsx10271CLquPc0LLABPvLMeQ7QaKZUmPmbzPPf/M/aqHINYPaeQeazK8e2ZVSUenzNhsALMFs
	Uel1oazAQnJZb2WNQY2xZIMPhaXOSjQ1crTJrVsC+chNjUNehz876c2teUPguA/ZAeNNZMYe97l
	epERil6SXongVd8NnwH6Lo4W1/FJZcnwFzDneavyYfycKUiwhkgogoOGJwe8BVPPiT4zZSX9uzd
	CN5l9oTKbSnROrHtU7FRC/4IwPOs+cmhQFDiKkOYWJW2s42/W5Zw5oTbPAWlUTiFfjlvhLOSRAg
	PwSb3W0t5AHB8r5bri1BowhKiNrpWflFg==
X-Received: by 2002:a05:600c:a45:b0:492:45a0:dcef with SMTP id 5b1f17b1804b1-4980c66d8a5mr305184025e9.5.1785858518366;
        Tue, 04 Aug 2026 08:48:38 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 17/20] xen/riscv: implement init_intc_phandle()
Date: Tue,  4 Aug 2026 17:48:07 +0200
Message-ID: <2cfa77799f1605bbe4f7dc70662e356e52d4581e.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785858518-74A894E9-26B688DB/10/73395122804
X-purgate-type: spam
X-purgate-size: 1378

Implement init_intc_phandle() to read phandle of interrupt controller
node and save it in kernel->phandle_intc for the future usage during
creation of guest interrupt controller node.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v4-7:
 - Nothing changed. Only rebase.
---
---
 xen/arch/riscv/dom0less-build.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index 4cc00012aa8d..a1fa51b996a7 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -4,9 +4,26 @@
 #include <xen/device_tree.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/libfdt/libfdt.h>
 
 #include <asm/p2m.h>
 
+int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                             const int node_next, const void *pfdt)
+{
+    if ( dt_node_cmp(name, "intc") == 0 )
+    {
+        uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
+
+        if ( phandle_intc != 0 )
+            kinfo->phandle_intc = phandle_intc;
+
+        return 0;
+    }
+
+    return 1;
+}
+
 int __init make_arch_nodes(struct kernel_info *kinfo)
 {
     /* No RISC-V specific nodes need to be made, at the moment. */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382288.1625749 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNn-0002wp-2j; Tue, 04 Aug 2026 15:48:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382288.1625749; Tue, 04 Aug 2026 15:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNl-0002qo-U1; Tue, 04 Aug 2026 15:48:45 +0000
Received: by outflank-mailman (input) for mailman id 1382288;
 Tue, 04 Aug 2026 15:48:41 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNg-0001vc-PV
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNg-009Gjx-4P
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:40 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d3-bab6-0a2a0a5309dd-0a2a4505c19c-10
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:40 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d7-4cb1-0a2a45050019-d1558034e023-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:40 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4956242332dso28508505e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48:40 -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-49949fcb46esm116430355e9.5.2026.08.04.08.48.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858519; x=1786463319; 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=DmOaTFmnk9rQJklV5xKX1lfHsimIvxxfep8LTck6j7s=;
        b=Vcc0xrNL6uChNjtytBWRdaeF46dVLqNQD2/9aFisMeGX4xjugFGPUyRwSdjUw9MCfp
         OsmAwT/NoRQpr6mLrrC8ttiVc2VP+YfMt1ch5SQAidObAYJTnWAry8E60z4lezzNlDcf
         bX2iO3ym1gAaq4CfY2din4h0BYmpoiYqek8l6+ve+W42d4JPLDyMBbzQd89DW2It4Lj4
         EMWogMkg+XYDuvzjo7GE6UPeIG0Lgw5UgwUENmYfwitPayjviULd/EoF+CVUDA8aHVFx
         XgUyozznGj3um45vf8V/sm6Tyt7R5KQYy/UXxlLEpkrcejIHYzAs++wuQFSEfPC5CXeA
         Gtfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858519; x=1786463319;
        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=DmOaTFmnk9rQJklV5xKX1lfHsimIvxxfep8LTck6j7s=;
        b=p7bBwazFwzO2N/gMz26ymT7LyC6kRzojuYXrb/eFKsH5ResTkoeMvu993QGwMRHx1V
         zSXvBilq9kZa8g7rmZ204Wk7ahIxgdbyhhyURD2d09sEIOpLo9RXas2rl0lNFDwkWe0B
         4zUW+WGNpm3UWenvO6/u9gC3LECCSFiJRusJpyZHmyz8MGFBIN3qfbiw/c8I/Z38ABv3
         brO2itWZbmT14gr5Ob1ZNr127DQnJOsQI0UFUIFBXYbSzbtQxw0kco9IwVz79eOEQRAo
         ueYhYlp0dZ6SyUP28j/g7+mvrY/wSjc386Xn1wVl97UenZ6eQ0V0sb/sIeGvG09cfHb4
         1a4Q==
X-Gm-Message-State: AOJu0YxNnU4Rdrao2bXen8vI6mFINvuzfwMrmRESUpb22Yqh11MpKsim
	JwAdn59z8gzdKkP68P9TT5qdv6sRsxG++L7mynU+34GB5p8rvvbAVKMh+6rU8A==
X-Gm-Gg: AR+sD107eatE7hEq20e4N3z4ARq9ha12qSeQrnLRub51/G1/FnkIjX6OhqcPbIbRM2K
	cN6mUoQGjcownymnTvIHXFtqhvTvKTgqOdl6F668719V3wcFz/Jl113bnf4i3DZ3zFrFd6uY/7p
	87stRIsgUX2g/rKa3lD+KR6bGm50u3kKHdZzDNFbiMStD+Irjt/2pUv7/Gcz4JHhvSxCICzN2bB
	Ron6SdytYdn0fcXxG0rJyv4gN7SCHC5jcVlRAzB5mHESkVCV3F0TFx5+RDJwRu78+F1Bjs/q5Sb
	fLV+FJDs5TCi3r47yz92EZcomLwDZzPnXPV6yWb7iYKtchcrbRmUmnKJZ8KAtxBcgiY8sJ08MnS
	9cac9jXtrIQD3Ipu2zlO1nFvCu/pn+4HEGIV0qXvIAi+PLGVrzziTqFkUqBHeLw7aTVBuqne5ra
	zTb8w9b1CyuUYeXGuX+paFImAAYO5A/CkxJ/7AFDVwSdwcsgwlMJfQlDyovHJ4W5c9jBBxpaovr
	0qpIzoHrTKI+uN5t2EheUQmK24fZ1AVyUGDWcVUiHPe
X-Received: by 2002:a05:600c:3151:b0:496:c378:6420 with SMTP id 5b1f17b1804b1-4980c66c843mr278491605e9.8.1785858519419;
        Tue, 04 Aug 2026 08:48:39 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 18/20] xen/riscv: initialize RCU, scheduler, and system domains in start_xen()
Date: Tue,  4 Aug 2026 17:48:08 +0200
Message-ID: <d45b0f25082fdb8b595e8c010c575cd4bd6e0d24.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785858520-732B32A1-8BF7E448/10/73395122804
X-purgate-type: spam
X-purgate-size: 1560

Wire up the missing early-boot initialization steps in start_xen().

The scheduler must be initialized prior to do_initcalls() because
cpupool_create_pool() is called during initcalls; without it,
BUG_ON(IS_ERR(pool)) is triggered inside cpupool_create_pool().

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v4-7:
 - Nothing changed. Only rebase.
---
Changes in v3:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v2:
 - New patch. Several patches were folded into one.
---
---
 xen/arch/riscv/setup.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 56a0907a855f..c3e98733ebc3 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -6,9 +6,12 @@
 #include <xen/compile.h>
 #include <xen/console.h>
 #include <xen/device_tree.h>
+#include <xen/domain.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
+#include <xen/rcupdate.h>
+#include <xen/sched.h>
 #include <xen/serial.h>
 #include <xen/shutdown.h>
 #include <xen/smp.h>
@@ -156,12 +159,21 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     timer_init();
 
+    rcu_init();
+
+    setup_system_domains();
+
     local_irq_enable();
 
     console_init_postirq();
 
     guest_mm_init();
 
+    scheduler_init();
+    set_current(idle_vcpu[0]);
+
+    do_initcalls();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382290.1625757 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNo-0003FX-Py; Tue, 04 Aug 2026 15:48:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382290.1625757; Tue, 04 Aug 2026 15:48:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNn-0003BB-DT; Tue, 04 Aug 2026 15:48:47 +0000
Received: by outflank-mailman (input) for mailman id 1382290;
 Tue, 04 Aug 2026 15:48:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNh-00025v-UD
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNh-009QPZ-Ag
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:41 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d6-2eae-0a2a0a5409dd-0a2a4504c160-8
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:41 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209d9-b57f-0a2a45040019-d155dd2ce4e9-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:41 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f703a9d05so2912747f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858521; x=1786463321; 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=GAWkDWNVTDEeajRUovPN0Ndt/ZkdBsFcfwqhXKheFEA=;
        b=BEMNLqjCMBlrrpVC5UiKeqk/4aIGkgCQb/6Xrt/fQ19RHuIQAiohM1nV06FouG1b3u
         t3f43xQPmyICYVF9B1MAfLngQYpKYyPhrqfWPVNOBWv+nrq9oITE0XVad1qMp169z9B1
         eC62Nss6jT6AYgjwl8w96qsnb7P0t9KT2qr+jPmiUmWubexoFPQWe/yJxgfMErFoilGD
         G2Adz9jU30Kxsd7mV+Dbv6Vhome4ZdsU3XNtAkZGyDt/l7VCo7upCHknT6J1sfbSZvmL
         8u650YLPq369RFm7BXCO42oLl6G3h+3MadgJVZvdP1Tj83xQ8/N/Kf4Rf8W+xdTixwWC
         G4HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858521; x=1786463321;
        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=GAWkDWNVTDEeajRUovPN0Ndt/ZkdBsFcfwqhXKheFEA=;
        b=QZ1WqELJczrgF6FpDa3S77hFvXnIfAxeADZ/WwcMPkAKtyMMKrBY6sEJDyvuzFAl4u
         MQUx7ai94/FLvHvmsc+QDtaRJpGIyW58VoH+4PilVDdcOUpW5bBCHjLB9nE9wIsaMGmQ
         DOmlyNfrkg/lLAq3tXZZLikUnaDZVFub391s7g6vDvTYoyBlkODyv7/aM/uduVJ+gywS
         yIqFIZGruXiUe5dEQUNncFJe5VLylNVeXemAjVIZXSoNAcbo5l8bbfaXvpz/HT8Aw/ul
         Ywfyl3kHFY6udHtWeRjFK7P4kIbNZQcTFFy62kRFHywvqZxocjxE5XodIZplwVQNTFRV
         2CPA==
X-Gm-Message-State: AOJu0YxluezbycgJKtFLoVTHwXwSzJuJ5i6kfdNZDD3fX3eG7bgxXDbu
	Dl3EaCPR2qK/R5x1uGIMkOzpOdbVP3Ckq1B5A2y/N0eGHtC7vgjUvi9z3EoZNQ==
X-Gm-Gg: AR+sD111E5mS8nTTEZp0QJGzy8czL4GJs78+0TuUO3tA8HU4HoOcos0SmPJ0v9gJLwr
	x+HLdTP4v+4hmuQuQqZ4M6brb3dKrTPtcHbmI2LbGfCNDKrAHJ0/4EIVPeQud3hClcjD3tihuta
	AFBg202K62NKhRq1j94GYhQG5Qx5nVwN60nA5TXvX3qGmCCv+2vioMYxRdeahQ9Jm9Jj7GW7YIX
	eQ2XBaaLU1bMIx/X9xV0QGQSQ8+CfBuRGTiyTi+BByY9f4iWVLBhoQRQQlOwL3R5Vron6TanL4r
	sqK8yZxbJ5j+ED1pmVXgcJNluwcUzmVHl5eCehPJr37uhFS7ev31OdyGCUR8Q+D6MCCX6yPpEtN
	VPQAd695A3fwtH0v4CnfzLGhqvW5frES7XK2wzVicxdPm6ac3++T1bm6XGOuEUGIMu1OnKIN3NK
	24KQGo1+BC3jbiyNixLGgE9kiH3IxnEMFM1HClJs2HSlmn0fZK7QO+GIX+BlcmESPLTz3W7O0wI
	Zq3jHUxJ51hLrRtruGVWkSRMxLIzZQc+A==
X-Received: by 2002:a05:600c:c8c:b0:493:f318:3bc6 with SMTP id 5b1f17b1804b1-4980c6564d5mr316112725e9.13.1785858520601;
        Tue, 04 Aug 2026 08:48:40 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 19/20] xen/riscv: provide init_vuart()
Date: Tue,  4 Aug 2026 17:48:09 +0200
Message-ID: <41598060f3f96d27da1c90299592bb908edd8910.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1785858521-C0CDFB50-679FDBBD/10/73395122804
X-purgate-type: spam
X-purgate-size: 1391

For debug purpose is enough to have only print messages from guest what is
now implemented in vsbi_legacy_ecall_handler().

For full guesst console support it will better to have something similar to
[1], thereby there is nothing specific should be done, at least, for now
and init_vuart() is provided to make dom0less code buildable.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2602041533440.3175371@ubuntu-linux-20-04-desktop/

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3-v7:
 - Nothing changed. Only rebase.
---
Changes in v2:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
---
 xen/arch/riscv/dom0less-build.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index a1fa51b996a7..d1a51b92936a 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -8,6 +8,14 @@
 
 #include <asm/p2m.h>
 
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
+{
+    /* Nothing to do at the moment */
+
+    return 0;
+}
+
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
                              const int node_next, const void *pfdt)
 {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:48:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:48:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382294.1625766 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNq-0003gc-RC; Tue, 04 Aug 2026 15:48:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382294.1625766; Tue, 04 Aug 2026 15:48:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHNp-0003YL-AF; Tue, 04 Aug 2026 15:48:49 +0000
Received: by outflank-mailman (input) for mailman id 1382294;
 Tue, 04 Aug 2026 15:48:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrHNj-0002FV-1s
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:48:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHNi-00Fkwn-EG
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:48:42 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7209c2-5cb7-0a2a0a5109dd-0a2a4502e47a-46
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:42 +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 <oleksii.kurochko@gmail.com>)
 id 6a7209da-6ca4-0a2a45020019-d1558029dc3a-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:48:42 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4954afac04bso39788275e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:48: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-49949fcb46esm116430355e9.5.2026.08.04.08.48.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 08:48:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785858522; x=1786463322; 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=mU8gqNd7fh25EXrT+sx22hsxtXPyXu1gA9iMQ0AEA40=;
        b=U9uM+0BWUx54E3p3oARTBXFN52DxEUN/nQ3zIv9Qi/sGG4yu3YGGOjsn8ZnKLSBkHq
         0VUtK3r+Bcdf907qUynx/eudQTHTciMwsw+WRiyRFGiZd5ZDY4M5finLD0A3XCIA6wpI
         Tb9kDZUNAgDS9tkYA+xYdUhVmhgflBf03gsfAlSyZnRfSndisXD2Z5f2s9/kiR2hD91V
         rylPyx4ygn6qBh4X9WMLpv7Tlb1o5o++rrxxqdgfgJ18YYgFYX54aeGl4vsTZNjt3KsL
         Q4IYpWLN2T29kSXlgb1eh3xgkB/pxGXolR6ZbfW6C+9ZyaVHsc5lttdCYoVl6ky2ZSyb
         zBMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785858522; x=1786463322;
        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=mU8gqNd7fh25EXrT+sx22hsxtXPyXu1gA9iMQ0AEA40=;
        b=d1zKLDxJ27a2ttg2RLNlZWUbFztuqfXXllnrcL8i8pahY0rX1e00sQIUTOq6H1lOwf
         Bh27/M7jcJOz231Cjve+2hX1GNeOMj5kg0QcTN/SrHRea/sSibYMgdofUzS+8Yf1vP/8
         /l7oowdQ+aMSKSmnkjUaUZRxZlK/jKjkfwL1SbyBjI8B9ez5jLQEyV9SE/KbnF0gxQtP
         aW5qBRhPQ2O5qdrRkIl+UoXxKxE1GSVoT27QtmiQQx0b77my+tcyVbPjuX9bIoQMfS2f
         XQM0jlYnmT7FdhToRj9JqBMnliI6W0msxHjqcTEsdaVinaYoJPoNE2Zt7MhkuTJtAMtZ
         hwKg==
X-Gm-Message-State: AOJu0YwnfU13j8gmnXRv5JQuoq1Cf5jQVZWeOy7M5FnrBfEog2PZ+8ow
	tzFVmVYUM7dt2wc5rFobXcfnTP2nfGJW243wgOQbyV3Lu/Sn7a+2lTW2Ue+3qw==
X-Gm-Gg: AR+sD12JB0smAKeeqOTkDdWc3lSIKDHXoRiyH8Q96NM5B1ufarKfNnKD4GJBQt2fSN/
	/4Dfvwmk/L9vyiC//z2kTKWoZQ7pydgu9DYeNa357MgCZksKaf8UCVb9dA+s031iXaydfuLMi21
	cNmlleQLFuTI/rxkbJir+6aM8iJxlW3KaGRLlO0u0Ma9mIX6wuAGJ7VEYBNjcy9PZg9OzkSFXuu
	fjn1KZ0I+UXLkVTT54G4fOP/TqTrgc6fN+XpRPmZx8TwJc+WNeq8IazzQbrLEaF4HqBIBCj0C77
	nEa+E1rv+66P4RlAvwI6TUMM/Je4cQM4287YGPavEJEyY6UYgt2Vv06Grk40iP7D3R8Tyn+sb83
	iRF/9mWbvtud4k7QwN4/sjJweicZSL5y0kyO9NyrUYZIYeyLnlXmummovAuGOXsk9IcMudumEcV
	STDWajmmKrbO2DYzzJpyjI4XleeXNwtadqeMp0cQk0HuCpU22cX43yFpdz+wwHzA2dNqLPdpZ2M
	lCasJpZLihoBPj+Gurr+5Dtjs9H4IhpBuL8V/0c617x/RDxrfHhNdKd
X-Received: by 2002:a05:600c:6990:b0:495:4d00:2fc0 with SMTP id 5b1f17b1804b1-4980c673907mr369152375e9.12.1785858521751;
        Tue, 04 Aug 2026 08:48:41 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v7 20/20] xen/riscv: add initial dom0less infrastructure support
Date: Tue,  4 Aug 2026 17:48:10 +0200
Message-ID: <f07fa4b45048098e4b98818fedda7b107cca3ae2.1785836421.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1785836421.git.oleksii.kurochko@gmail.com>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785858522-F28B42AC-6F1C9BE7/10/73395122804
X-purgate-type: spam
X-purgate-size: 7342

Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and
providing the minimal architecture hooks required by the common
dom0less infrastructure.

Add stub implementations for architecture-specific helpers used when
building domains from the device tree. These allow the generic
dom0less code to build and let a basic DomU be constructed on RISC-V.
construct_hwdom() and make_hypervisor_node() are still stubs returning
an error: Dom0/hwdom construction isn't supported yet, and the
hypervisor node generation (needed by domains with
DOM0LESS_ENHANCED_NO_XS set) is not implemented. Both are marked with
a TODO and are not reached by the currently supported configurations.

Provide missing helpers and definitions required by the domain
construction code, including domain bitness helpers and the
p2m_set_allocation() prototype.

Additionally define the guest magic memory region (GUEST_MAGIC_BASE /
GUEST_MAGIC_SIZE) in asm/guest-layout.h. The base is arbitrary; the
only constraint is that the region must not overlap guest RAM or the
emulated device regions. It is placed in the unused gap below
GUEST_RAM0_BASE (0x80000000); the constraints are documented next to
the #define-s.

A separate region for grant tables will be introduced at the same time as
the introduction of the grant table for RISC-V.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-7:
 - Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v5:
 - Reword the comment above defintion of GUEST_MAGIC_BASE.
 - Shrunk the size of GUEST_MAGIC_SIZE to 2Mb as looking on the Arm
   only 4 pages are used and there is no technical reason to have 16Mb for
   that region. (Maybe in case of Arm it is connected that Arm has these
   definitions in public header so more space is reserved to not "break"
   public API in future)
 - Update the commit message with a remark about grant table region
   in guest-layout.h.
---
Changes in v4:
  - Reword the description: the stubs do not let dom0less fully "run"
    since construct_hwdom() and make_hypervisor_node() return an error;
    spell out these limitations instead.
  - Add a TODO comment to construct_hwdom() explaining that Dom0/hwdom
    construction isn't supported yet.
  - Add a TODO comment to make_hypervisor_node() explaining that
    returning an error breaks building of domains with
    DOM0LESS_ENHANCED_NO_XS set, and why that is harmless for now.
  - Document the constraints on GUEST_MAGIC_BASE/GUEST_MAGIC_SIZE next
    to the #define-s and drop the QEMU-based justification (QEMU is not
    involved); the base is simply an arbitrary non-overlapping address.
Changes in v3:
  - Add /* Nothing specific to do for now */ comment to
    arch_handle_passthrough_prop().
  - Use _ULL() instead of xen_mk_ullong() for GUEST_MAGIC_BASE and
    GUEST_MAGIC_SIZE (xen_mk_ullong() is intended for public headers only).
  - Fix GUEST_MAGIC_BASE from 0x39000000 to 0x79000000 to avoid the
    QEMU RISC-V virt machine PCIE_ECAM range.
  - Drop CONFIG_STATIC_MEMORY=n from the CI randconfig; now redundant
    since STATIC_MEMORY depends on HAS_STATIC_MEMORY which RISC-V does
    not select.
Changes in v2:
  - Move declaration of p2m_set_allocation() to p2m-common.h.
  - Add __initdata for max_init_domid and drop initalizer for it.
  - Add CONFIG_STATIC_MEMORY=n to CI's randconfig to avoid
    compilation error because of guest_physmap_add_pages()
    isn't provided.
---
 xen/arch/riscv/Kconfig                    |  2 ++
 xen/arch/riscv/dom0less-build.c           |  7 ++++++
 xen/arch/riscv/domain-build.c             | 28 +++++++++++++++++++++++
 xen/arch/riscv/include/asm/guest-layout.h | 12 ++++++++++
 4 files changed, 49 insertions(+)

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 48520588fe40..d8a348c0cf07 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -6,6 +6,8 @@ config RISCV
 	select GENERIC_BUG_FRAME
 	select GENERIC_UART_INIT
 	select HAS_DEVICE_TREE_DISCOVERY
+	select HAS_DOM0LESS
+	select HAS_DOMAIN_TYPE
 	select HAS_EX_TABLE
 	select HAS_PMAP
 	select HAS_UBSAN
diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index d1a51b92936a..0801d7e25059 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -102,3 +102,10 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node,
 
     return 0;
 }
+
+int __init arch_handle_passthrough_prop(struct kernel_info *kinfo,
+                                        struct dt_device_node *node)
+{
+    /* Nothing specific to do for now */
+    return 0;
+}
diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
index d7613721db95..1e3abe259ccd 100644
--- a/xen/arch/riscv/domain-build.c
+++ b/xen/arch/riscv/domain-build.c
@@ -156,9 +156,37 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
     return fdt_end_node(fdt);
 }
 
+int __init construct_hwdom(struct kernel_info *kinfo,
+                           const struct dt_device_node *node)
+{
+    /*
+     * TODO: Dom0/hwdom construction isn't supported on RISC-V yet, so this
+     * is a stub returning an error. It must be implemented before a hardware
+     * domain can be built from the device tree.
+     */
+
+    return -EOPNOTSUPP;
+}
+
 int __init make_timer_node(const struct kernel_info *kinfo)
 {
     /* There is no need for timer node for RISC-V. */
 
     return 0;
 }
+
+int __init make_hypervisor_node(struct domain *d,
+                                const struct kernel_info *kinfo,
+                                int addrcells, int sizecells)
+{
+    /*
+     * TODO: Generating the hypervisor node isn't implemented yet. Returning
+     * an error here breaks building of any domain (DomU included) whose
+     * dom0less_feature has DOM0LESS_ENHANCED_NO_XS set. This is harmless for
+     * now because Dom0/hwdom construction isn't supported on RISC-V yet
+     * either, and no RISC-V DomU sets that flag, so this path is never taken.
+     * It must be implemented before DOM0LESS_ENHANCED_NO_XS is used.
+     */
+
+    return -EOPNOTSUPP;
+}
diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h
index 90603f06bb91..ceed9125e7e2 100644
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -32,4 +32,16 @@
 #define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
 #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
 
+/*
+ * The guest magic region holds the Xen-reserved pages mapped into the
+ * guest's physical address space. The only real constraint on
+ * GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM
+ * (the GUEST_RAMx banks) or the emulated device regions defined above;
+ * the exact base is otherwise arbitrary. Here it is placed in the unused gap
+ * below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank would work
+ * equally well.
+ */
+#define GUEST_MAGIC_BASE  _UL(0x79000000)
+#define GUEST_MAGIC_SIZE  _UL(0x00200000)
+
 #endif /* ASM_RISCV_GUEST_LAYOUT_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 15:58:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 15:58:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382427.1625796 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHXM-0001of-GP; Tue, 04 Aug 2026 15:58:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382427.1625796; Tue, 04 Aug 2026 15:58:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHXM-0001oY-Dg; Tue, 04 Aug 2026 15:58:40 +0000
Received: by outflank-mailman (input) for mailman id 1382427;
 Tue, 04 Aug 2026 15:58:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrHXK-0001oQ-RJ
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 15:58:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHXK-00Fm1T-7v
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:58:38 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a720c02-5cb7-0a2a0a5109dd-0a2a4501dff6-46
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:58:38 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a720c2d-5984-0a2a45010019-d155802bc07b-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 17:58:38 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49555a0e68bso17102085e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 08:58:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49807b8d04fsm477454045e9.3.2026.08.04.08.58.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 08:58:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785859117; x=1786463917; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=uTztnL3YIRuGnJqt6+Zduc6sY+i67CEbHhQ5R6Sx/LA=;
        b=HTtcWdIJyRO8GV8Zf6bncXTfFK6DNLPSkYE53keYPF/9c7tAwHYQkGAHTM9Iktts9s
         RjgRAzdP6+G41Re/nSMXudt81MX0lo+TI4hbifsofAouze6X011y0YzXImbUVqwYNS18
         A1uSOz7yOy621A83nUwBFGmdbBsX0rMgNRmTLH50VTD5lGfaT9Q80ojC4UM4qXZad3Cg
         1kn1hKKzbRGwe+wLXlVk/JUDyr7yk2kXzSVYz5KvA/cJ2Uj3wdskxK/LNoTBzvQ9sVjx
         TC0CSrZ4L8N5o1gabupPdKuL5Pa5fUgjpmurWL2XOePWx7cBGICPfAUT/v6FwqV/JZXX
         AVEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785859117; x=1786463917;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=uTztnL3YIRuGnJqt6+Zduc6sY+i67CEbHhQ5R6Sx/LA=;
        b=MfH/x0NG3T9jkZtUL5VALG43S29Fkjg+XiGX/BrrnCsUdUzPN5Xd9UpjGENBxduSRq
         NmAhJNhPxpZUzdbqq8oxoY5rgsBYqwvU7kw9T/AsXbagJI7HFHRWupzw9n1hX07xbT8f
         jXgVC7mveAPkE4t+cgagsFWV6JIf5413TNvg4vUWEP8Bh2kQlbJ57GSboQ4X80R3+tyh
         IQgZLiVruFJZRJ5kAQcWJFVbSHCH4hD/Qwrvq7DvzBZJn+PC4F6wCjDHDxLPMFQSj2MG
         ljIIIy27X9o2RFWThhAU7LNur8gDfz/HhxipUZT2fO3LAQRcM6sIRqOlZL7jFsQ2jb32
         DnBA==
X-Forwarded-Encrypted: i=1; AHgh+RooVTFQO0UMBwDI6lgHfMWLnIn0u4pteBQbVNJQLFtoWd0wqgRffHUFNT1V0tlCwqQ1gg4OpXO9cAs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztEd1b0P1YokoTUFPlQj6c22254h7MYGrZcFHwYK2p/6M4axkH
	fSZjqon0e0wJ6Zfmxa/keb8y+8dvH9ol2i4mvuJ2sWHT0OTzkIAItMieXHrFPojDdg==
X-Gm-Gg: AR+sD12gqdlgwJMTUI4r+VLgIkYXmA7X7zDrF9/04ie2gtqCQjAMq2G1U8H2MnWFMRC
	jL9hU9nDDbL69Kmqt/538K83GE6sRWy4pRWSFheONm2L0QLeHYx79xmc3/w/MyEW4uEwRi0viOU
	ISju0tnxvzxL2VCf3FLmOYVOA1c1CsBIx0tf28Tuj9oAdEPQAn3zY+tdoYDeBeKjZoVBc7DtMN5
	P9RQHq66pv5EvgaYUCfL/qiZTU+fVXX/bLjq8y4wfNoNJeqjV0xi02yM6byHRQaRHK0kJV4vE7L
	zu4plp+QpqRXLZut0E4g/5QTp8UbJYRNQCkqTNcaKFiDaGiPbYE+JcX67sMymtHfPvE43a2UPkW
	YMof2SGrIzXbu8k9tfFA4IBfI82Lr2fCBGyeF6KsytRB2/lRwnQmMVrdNM89MlPuSe3z6Z4KESE
	Op6NDjD/nPXAHroj/o6/7eOb48RJnlYtQLRsK0euGWFXTWt3gv4g7IJPQ8q7TZqNa+wFX1nSf8q
	Zg/AfJOxYz/hWNxw+ssn3bwqO0yFcUGY2QD/djdhYYA1rwJVVbm
X-Received: by 2002:a05:600c:3b23:b0:493:cc25:9c0e with SMTP id 5b1f17b1804b1-4980c679e43mr371092945e9.14.1785859117612;
        Tue, 04 Aug 2026 08:58:37 -0700 (PDT)
Message-ID: <a10f82fb-c4fa-493a-88cc-0b5d4c8db3ff@suse.com>
Date: Tue, 4 Aug 2026 17:58:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RESEND PATCH 1/5] vtd: Ensure root entry is updated consistently
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319678.8631fc262581453bbf619ec5b2062170.19fad586037000e099@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1785319678.8631fc262581453bbf619ec5b2062170.19fad586037000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1785859118-1FA6E757-878CAEE4/0/0
X-purgate-type: clean
X-purgate-size: 1791

On 29.07.2026 12:05, Teddy Astie wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -281,13 +281,13 @@ void free_pgtable_maddr(u64 maddr)
>  /* context entry handling */
>  static u64 bus_to_context_maddr(struct vtd_iommu *iommu, u8 bus)
>  {
> -    struct root_entry *root, *root_entries;
> +    struct root_entry root, *root_entries;
>      u64 maddr;
>  
>      ASSERT(spin_is_locked(&iommu->lock));
>      root_entries = (struct root_entry *)map_vtd_domain_page(iommu->root_maddr);
> -    root = &root_entries[bus];
> -    if ( !root_present(*root) )
> +    root.val = ACCESS_ONCE(root_entries[bus].val);

I'm pretty concerned about this: You're reading only half of the entry here,
and you're writing only half of it further down. The other half is reserved
right now, but there's not even a comment being added to this effect. (Yet
even with a comment, I'd still be concerned, just not as much.)

> @@ -295,11 +295,12 @@ static u64 bus_to_context_maddr(struct vtd_iommu *iommu, u8 bus)
>              unmap_vtd_domain_page(root_entries);
>              return 0;
>          }
> -        set_root_value(*root, maddr);
> -        set_root_present(*root);
> -        iommu_sync_cache(root, sizeof(struct root_entry));
> +        set_root_value(root, maddr);
> +        set_root_present(root);
> +        ACCESS_ONCE(root_entries[bus].val) = root.val;
> +        iommu_sync_cache(&root_entries[bus], sizeof(struct root_entry));

sizeof(<expression>) please in favor of sizeof(<type>), whenever possible.

>      }
> -    maddr = (u64) get_context_addr(*root);
> +    maddr = (u64) get_context_addr(root);

While there, drop the pointless casts, thus getting rid of two style issues
as well?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 16:04:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 16:04:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382436.1625806 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHcx-0004kD-5w; Tue, 04 Aug 2026 16:04:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382436.1625806; Tue, 04 Aug 2026 16:04:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHcx-0004k5-0D; Tue, 04 Aug 2026 16:04:27 +0000
Received: by outflank-mailman (input) for mailman id 1382436;
 Tue, 04 Aug 2026 16:04:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrHcv-0004jE-WC
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 16:04:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHcu-001mZB-MB
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:04:24 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a720d80-bab6-0a2a0a5309dd-0a2a450b8942-26
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 18:04:24 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a720d88-b7e8-0a2a450b0019-d155dd2fb82f-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 18:04:24 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47362928f65so4540855f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 09:04:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec249a78sm642447f8f.34.2026.08.04.09.04.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 09:04:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785859464; x=1786464264; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=m5PEtzj8mtJe7pFOG8I3FsyiHy4JEbRtR3I88EiU7ZQ=;
        b=MX+irVqJ2dI01rJT/FniLmL2rBtcyz260T6tq4/5aZj2p1153/vecKPbA38XoTdJZ8
         mFAk/ehQBz17WlK5Nl4H2ZTWEXR/JQWE6yJV8YdyTjq9m/7mihOOqLrseD+QFBy8T87M
         e0XYDMhdElNmf482tK4Q54fjx9XSFbT8tvZVd4bD33qiQBP3rtaT7bn9OEDgj8lgr3sI
         oeiTr+fBanIgBFZSUwlTYkhnZJztSC4WGU1myxAnNxRCOAbL6XP4UzabPsXYikGTqONZ
         EpTUWIACb6Hd5V+tYd1HEdz57CSQFXgnagbjyQVw/EeLFPm2cRQgbcRitLD0q5DMxVWt
         NMfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785859464; x=1786464264;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=m5PEtzj8mtJe7pFOG8I3FsyiHy4JEbRtR3I88EiU7ZQ=;
        b=qoj6uvxt+/kdBUbtFyoD6Y2A547hO6XmodhFGHYHEx0LyeuuqKM9SSvIcKl8VY/q1m
         0CoaGPsw7lIzUPuIzJBbNOGfpd/GRbNHS/f9oJwWoBdxmlN0J6mraBKMjXyfjGb6ce3r
         ZMEJp3DBMuyOnUpJ6ENgOtq3dDIZ6CRNjk7j4Ut2lNWtHGBxI87z/A+a7zy3ka5VoiU8
         cx/W5+vNJ4AkFt1p6VQKt2wC+nxFHo484gV5mWPxCfL0CG8HMpTjGdR3Bd7pWey5SyPE
         76D5DHUIfLjPmaIu+DYiuIghEZa6G+aLvT1fp9hGpmsk21veF9lFHfN3UJE7JXljQ3Ws
         ytxw==
X-Forwarded-Encrypted: i=1; AHgh+RrMA5Dee2JgTbQlkFwoQFeFSXCAqzNRs+EsPYemrDLFG8+F612r0BWxTYV/WOxVBDm4GITDO+OWz10=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx29rJVF93B7jRFhha4EAHGsOmS1DLzK1saYs0+LzTQbeoh28zI
	Ogxtzd+nVENqNdMUltgE3bQysGew2XGmT+d+LmMELhOGuPYlNkcDxDccaoMQ004kdpcg/M1B7F0
	2eeH8yQ==
X-Gm-Gg: AR+sD10oo5siioo4NhlsdlYld2CPpMj4H3e2dYCygrE01HVRFC8OEjUg32KxFW8+teW
	lt2gbqHGJ8kl/9Qn/zqrDrOJo06u18BLYR43vjHOH2Wp2yINISHm+wsXONB16h4jR61Z5zZUzxb
	E/NtMJbEJbV9nYb9cN6SVD2Ff/10Rg5eoC2/ZdZ1NpMTCdbriX9FlnC5GlaLkJFF+yQymm6hu4I
	dSU5yW948Ep0YuQArOXPgCFeXfwZMGaq1kB8tA8jpr1fu23qSLNWIObC0C/gP4pISaPSTPf1AS9
	diaKtsyMz1A2kkyP3CGquOA62JhIRRnrREhQCOt8kI3jURISoNOs3qG+R2Jo2ilJFi+fIVRdqwt
	092he3ON0+B4FTZEIyazb4dWjOyYNU8oYN7OHMnS5kBe5ZCebmHENCtjYE4I7+Hbp2tWcsRbGIK
	0KEgQbmmkCpo4hfDvf72NRtpvNaFW7uN6dYClOkLiHTTH2L+W2r+wx2h36eQHI9yEaHYvSETFtN
	EORn2YnGUhsO79Y/gz6D4BjRma14EwItNMfOO7x4Kycd3o7sXPy
X-Received: by 2002:a5d:68c9:0:b0:474:18d9:8371 with SMTP id ffacd0b85a97d-47fec6359c1mr364268f8f.28.1785859464014;
        Tue, 04 Aug 2026 09:04:24 -0700 (PDT)
Message-ID: <55d55c27-a482-4b59-a1f9-1412c91d7835@suse.com>
Date: Tue, 4 Aug 2026 18:04:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/5] vtd: Ensure context entry is cleared properly
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319341.8631fc262581453bbf619ec5b2062170.19fad533bfc000e099@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1785319341.8631fc262581453bbf619ec5b2062170.19fad533bfc000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1785859464-A8AC89EA-A8DC0F50/0/0
X-purgate-type: clean
X-purgate-size: 1931

On 29.07.2026 11:59, Teddy Astie wrote:
> When removing a context entry for a device, the present bit needs to
> be cleared first, then we can clear the rest of the field. In the current
> logic, the compiler is allowed to perform optimizations in a way where high
> is cleared before the present bit (which is in low part) is, leading to a
> window where the context entry is invalid and would make the IOMMU fault
> (as address width would be set to a reserved value).
> 
> Fix the logic by ensuring we clear the low part first (which also clears
> the present bit) then the high part afterward.
> 
> Fixes: cada0c18f8d1 ("vtd: Move dom0 RMRR check to intel_iommu_remove_device()")
> Reported-by: Teddy Astie <teddy.astie@vates.tech>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index c314ce1db8..1005e200c1 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1889,8 +1889,14 @@ int domain_context_unmap_one(
>  
>      iommu_domid = context_domain_id(*context);
>  
> -    context_clear_present(*context);
> -    context_clear_entry(*context);
> +    /*
> +     * Clear the context entry.
> +     *
> +     * As this is performed with two stores, ensure lo (containing the present
> +     * bit) is cleared first.
> +     */
> +    ACCESS_ONCE(context->lo) = 0;
> +    ACCESS_ONCE(context->hi) = 0;

Implying the placement of the present bit is again something I'm a little uneasy
with.

With the uses of context_clear_{present,entry}() dropped, the macros are unused.
I think they would better be dropped right away, to prevent misguided use
elsewhere.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 16:24:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 16:24:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382449.1625814 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHw6-0000LT-LN; Tue, 04 Aug 2026 16:24:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382449.1625814; Tue, 04 Aug 2026 16:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrHw6-0000LL-Hs; Tue, 04 Aug 2026 16:24:14 +0000
Received: by outflank-mailman (input) for mailman id 1382449;
 Tue, 04 Aug 2026 16:24:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrHw5-0000LF-9z
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 16:24:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrHw4-004PPT-94
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:24:12 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a721222-bab6-0a2a0a5309dd-0a2a4507e9c4-14
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 18:24:12 +0200
Received: from [52.101.56.9]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72122a-b4ea-0a2a45070019-346538092921-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 18:24:11 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CY1PR03MB8122.namprd03.prod.outlook.com (2603:10b6:930:106::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Tue, 4 Aug
 2026 16:24:06 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Tue, 4 Aug 2026
 16:24:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=o5HjOoN19iTNgrpzWynhldcyWuud6gq1aKxxzdPOCPQmw/neYkIkwNWTNkQxEbHjbtcSLbvfCYGCfl1i3hkZkanDoLt1Ua95grraSkFtuoyHWPvE1ZdzvmUHhoFsoKLAr7mhatzQWVO4c6H5P9C+qx3eBoY9MDdiTBQXUcVKDEr5qPtEeRi1omcaizTDmaoyddaBLUuUL4HRrna/zHk9FJ5dFgB0tEJhLX2Wyyz9URQ1G/v+m2lKgjB7XkTwUX5MHs53jEhFXXLXJfEydYYCGpR07twuGi0hEiTHF5U7RiblP308D9bREqcdSQkxGfCocdJ1jfdNLTzEsk5jGWuizQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JvSlvUKUmqXgm62iNIgXSG22mwHOiYmM2XvdHRKiLC4=;
 b=xmkZGyiJ+ibdNfbC+CVQhcV6gvlaerMVS/MGGojJ30T1efgIZocG44uG6IWa2JWai+QuW6K6tnCTbNE5sLqgMgrPbYVoUhz721u5jrJWRr17/3TKg6GTsq1VVshxtQ4y9GiU8Q0d9U0XspNQAC7atZTCeXQHfXswKsiLzMSrGpHeNaoDh5VZufMo2RPv9oo95Y9DHAupEUccsCEl4HL5Sj5tvciHjqZFo8RoGZR4l99b53/DELbzhs+5lVBZmg2EDQuEEjqcErBGQaosPrXpT8K5KPjTBHCPPk3m2SdW74a2sMhh4s31/213jbbPxKAy1cX9z735JI7XOdXgzOJBIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JvSlvUKUmqXgm62iNIgXSG22mwHOiYmM2XvdHRKiLC4=;
 b=OaKiMiaay/c7vjseqfCRwwn6Kfnp/fUrAwHIzgwz7vuTRmO2iSNWKR/iSdY9eGBMXnjw7YDnF7kZQKvV6Dk3kvpDJK3epl2O61TuuJv89ER21aWGDbj9iNlstgRkgiKiYhLz0q0iWifv5MQuZdbPwOL6p5UX7nXs/m5Gx/34MBM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <d995b0c4-a916-4470-9aec-aa90087680ad@citrix.com>
Date: Tue, 4 Aug 2026 17:24:02 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Frediano Ziglio <freddy77@gmail.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH v1 1/6] tools/migration: introduce PAGE_DATA_LZ4 stream
 record type
To: Marcus Granado <marcus.granado@citrix.com>, xen-devel@lists.xenproject.org
References: <20260720154832.1907401-1-marcus.granado@citrix.com>
 <20260720154832.1907401-2-marcus.granado@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260720154832.1907401-2-marcus.granado@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO6P123CA0055.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:310::12) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CY1PR03MB8122:EE_
X-MS-Office365-Filtering-Correlation-Id: 623b78f5-6dad-426d-b514-08def244cdc7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|6133799003|11063799006|10067099003|4143699003|56012099006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	DyZzO+oyIP5mfa8/V5cC3JKALHkhSo6pi7YozT8lVN7S3yokXgEXaHQxDucw+y8CpxxjqF+VG6jsdBur6Wb9POAn1c16jZUnjcstu5a+6OV8fg3lFWs2eSoqnleOFbcbklWT97jhuhMN9nS2bjZ12JEZiyEZfgjSi7xm/qfvhHg/gStVPZJw/4SmdhAcDtHZKSzLdxMRsi4Q1oPDUty9p7SV5/PipPT5d4tbbvhh7f80Ky4vzbkX2snZxIWjc6zsq6N9XicSPdN05NR69bUlPl9pG9J3RGssL4nxq2rSw2l2q5H5nLq3ckmHu7of3XCWYACSP5d/IHF1joRTJRdSEbTwCvTPWroqS08OFcRfxd6q+2GwmQYTehLRWECYJWcMCnTYTXlOqw6BcOPpTGbTPfnLop4RNjTNYj9Uy/SwoiZ7ASwLsiJ8zmg2ZgpIsd+LgeLEs75GLOQmFwDkveJkCEeNRp0hTIQoo33hVfiw648KBCn/hUa6Lb21yeXNWU5H+yMCrWaDX2HMHQ7oNbl3EZSA3ul2DkcfA38k5+bAw91dxFStl5HTi1vIcy9AQV9ARuB8o/OQR5EI+3iqWGHlSweybyQwEP3ClbJI3xzXH9GXDVdXKnIETlPm3dnZ+6LRff56AnKm2z4YzIPjdDC9vPrcQgojeqoqgs40grP8zbI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(6133799003)(11063799006)(10067099003)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?K1JHUFlPQ1NTVnU2Y3R2WUsyeVlYSTB0SmF5UlJwYnYvTzdJdHRuNTB5UVoz?=
 =?utf-8?B?L1cyL1NKd243T2JFbEJGS1NPbXZyWmNaaXNreDFPV0R3eFl0OGpMQy9jekZB?=
 =?utf-8?B?OGp1YTdmVFBURGJIbHdOMCs5Vi9oc1VtK0tXZU1FbkI1QTM5dmNTdjkxQ3Rw?=
 =?utf-8?B?ZWJqcWFiTE9wak9qRFNwUWIwdWlPRGkzaU50d2x1Y2hoYVNqRVljV08vaGw2?=
 =?utf-8?B?YWoxNmdUamZqNTBVS3pLMHNBaDAwVFhHcUZzWHM5UTc0WWdoUERWS3NqL25a?=
 =?utf-8?B?Nlk5ekFad1VNUkI4WDBsM2psU1BoZ0c0ODBoU3V5bXVwdEpmUHUwVDFWV0cv?=
 =?utf-8?B?K2xFTGwrU1dvck96VTF1aDZEV0ljcklZUWg3Z0xXN2pMakNBMWR4L3E4Z1VL?=
 =?utf-8?B?VE1FUTYzRWRxNE1LcithNy83N0V4bDhqbnBabXRheWRtTkw2aDlySm4wczhx?=
 =?utf-8?B?RXhtUm1pMnBHTkdyQnVQeHlhaGJqZGwvOEhnWExDQ2tpRmpkeXF1NWJSaFJK?=
 =?utf-8?B?RG5DVjhXZkxDQmU2WkYxNnBwdE1BV2dwM2wxT3FtdVRlQUUzSS8xNWNnS1d2?=
 =?utf-8?B?QXhRbXJTeklMSzhaNG4zeDl6QmF3Y0FYd2Iza2ZCaVVqSzNFYnlwVk9LVzZ2?=
 =?utf-8?B?YlVLb3ZHT0ZFV0hEWjlpQTJDL2JmclNsa3IvZENXTkhzVGpKczBPbFcwblpq?=
 =?utf-8?B?K0R6cFBsYXYzejFOazJuVENzajJpWDByMjFTRERQclNqSE1aY3grTTFXVmY3?=
 =?utf-8?B?NnA5SUVPYzc1aFdoNTRlV3ZJU2Yrc0ducHc0UTNhNHNCK3hCSWFVV1lDNjFU?=
 =?utf-8?B?Sm9Ways5czF2V0N4SDJoWHFrWUJyY0RDU1JZK2grQ011NUJkZWFaYW0yUzdB?=
 =?utf-8?B?MGMwcjhuY3RoV2pLakZMNGdpY2FLanhna09YODd5WjRSd2lLcnFLd202eDZ0?=
 =?utf-8?B?SzMwUjJPaUtEcVh4ZEpRMVVIdlFSMEUwMUFKcXFLRXJMc21McGJSd1lOSWdV?=
 =?utf-8?B?OWtwb3ZoOTdwd0NKc3BsdCtza2hWZ1VoNGpMTXBBbkZxVTF0dTB5UlNsL2pC?=
 =?utf-8?B?Q1c4Wmo4YitFSlBXejBTTW4wL2tHclY2NmpTOVBCL1VKemx4ai9GSjJwYkZx?=
 =?utf-8?B?N0NOdFNmcFRseDNBc0RIUGxVQjVvclZTdHJ4QktmWFVxWEtnQUNVNzJmZVgw?=
 =?utf-8?B?U050dDJGa3RwT3dkR0ZweVM1L0VmYW05L2RJL2wxd0ZlcjlxdFBaeHZZaW1o?=
 =?utf-8?B?QWVySVQzdHFmYlEwZmFtSHdOanVrODhOSkliZUU2VmJtK25jNFo2T1pLa1Bx?=
 =?utf-8?B?ZjhnYWYrZ1dkZHBjaWZOd21VZytUZ3UzOHhURzdoU2s0RkU4UzQ0OWJWQVJt?=
 =?utf-8?B?ZG9kMkJrZzN0aUdmaEVKczNpYmxWVDh2Z1VnVXI4SzVwR0tmdHNGaUFwb2g1?=
 =?utf-8?B?dXNWdzQrN0d5NTh6UG1GYTRpNVRkRjRJN3ZTajhMMkhYaGI2OWJxa0RCbHhG?=
 =?utf-8?B?dmNwbVhrdW1ydGIxK3NtZndFTmNEQlAycjZ1Qm11MjFrQUEwWFFjTUxudjVm?=
 =?utf-8?B?VkRiM2xITzNDS1lKa1lObzRQVG1QV21mWW5rRkJ6akZBN21laXZXWVRWREFj?=
 =?utf-8?B?Z05Vc05PK2hFdjVuRVVMdXZ0Q3dyWmVCUnZPYjVkRjNpNk9rK0diQ3FGUzJC?=
 =?utf-8?B?TllSMUd1b04zNDFyOFYycWhDa0czckFzSEgwNlBqbC9NTDZXYTNwMWthYXJO?=
 =?utf-8?B?QjN1MitFTWRYb0VzNWNWUm1EZ2xJY09MM2duYVZLWjlMeEpUeTUrTU1rZGhn?=
 =?utf-8?B?cmFSTVZOWmlMS21ORUhlUUFtYjd5L2pNNy85UkgxOGp3eDhUWUpNTkZZL3RI?=
 =?utf-8?B?MkRzTXBDaXZ4U2ZPS1lJeDIxOE43dEZBVWg4R3VkSUdVbE5wNlZHS0ZVUitu?=
 =?utf-8?B?TktoNjBUOFNIZ2xUSllhWFFRSWJMc3g0cHNCUlVwbzcyMnNhR0VxUVQrVXAy?=
 =?utf-8?B?Zkg1QnJ4YXE0Yy9YZ2kwWjR1N2RRZGY4VDBJM05sdmpJOVI0OXNVMDFBazcv?=
 =?utf-8?B?NzlvUTVmcHpHMUV5R1Uzcm5nOHAxekNBODRNbUhtdVlENEVOVnlTdUs1VkRL?=
 =?utf-8?B?ZUMvRXNsZCt3UktCNEloQmpNOHFvYkE5TWROU3hBRVIwOUdnM2ViUlFwOEYy?=
 =?utf-8?B?MWZybFV5S3N6TFYzakg2WWFaanlLdTN3MWhvaTNuY1pGQ29KZkNPZTVtSEhp?=
 =?utf-8?B?cCt4T1gycWpQSHJJbURmcEJXd1hnaVE1Q3MyRzVxUG1aRkdHN0s2OFlyaXZv?=
 =?utf-8?B?ajJvcDNVdVNCMHh2cnNRWEpUa3E1NjdlcWFrYXFmc3psRXFFZFdsdz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 623b78f5-6dad-426d-b514-08def244cdc7
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 16:24:05.8860
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZUL+HsUlYKFVgCcvQJnbI07EDNdGByHWMOBYvW7oaqJjJ/toQXvMixsXS50i9bhiSEf2blL/eaQgOFAInm5ys2dpAj3KdDNBBmRMrd5rY1Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB8122
X-purgate-ID: tlsNG-ef75cf/1785860651-366DAAE4-0C74E280/0/0
X-purgate-type: clean
X-purgate-size: 2147

On 20/07/2026 4:48 pm, Marcus Granado wrote:
> diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc
> index 1319ce1f1e..7469c95139 100644
> --- a/docs/specs/libxc-migration-stream.pandoc
> +++ b/docs/specs/libxc-migration-stream.pandoc
> @@ -359,6 +360,68 @@ tail.
>  
>  \clearpage
>  
> +PAGE_DATA_LZ4
> +-------------
> +
> +A PAGE_DATA_LZ4 record carries exactly the same information as a
> +PAGE_DATA record, but with the page contents LZ4-compressed.  The saver
> +may emit it in place of a PAGE_DATA record when LZ4 compression has been
> +requested.
> +
> +     0     1     2     3     4     5     6     7 octet
> +    +-----------------------+-------------------------+
> +    | count (C)             | (reserved)              |
> +    +-----------------------+-------------------------+

This reserved field in the original PAGE_DATA was earmarked for
compression information, but that was on the expectation that we'd be
compressing the whole record in one go.  We're going to need to figure
out that part first.

A complication with compressing in a single block is that we end up with
disjoint ranges for any PV pagetable, and for holes in HVM guests,
although Frediano's foreign-copy work could be adjusted to arrange for
the pagedata to be contiguous.


Another question was about the choice of algorithm.  Yes we could use
any algorithm, but CPU time in dom0 is at a premium and we want to
favour speed over compression ratio.  LZ4 does this.  ZSTD might be
acceptable too.  The others are unlikely to be a win.

While this is going off topic, it's worth at least mentioning.  Another
optimisation I had in mind was to remember the last version of a page
that we sent, and on subsequent iterations, XOR the current contents
with the old contents.  I posit that plenty of dirty pages will only
have a small amount dirty compared to the previous send, meaning the XOR
of the two will be mostly zeroes, and run-length encode very well.  The
downside is extra memory overhead on the source side, so it's not an
automatic win.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 16:28:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 16:28:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382458.1625822 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrI0W-0001HN-63; Tue, 04 Aug 2026 16:28:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382458.1625822; Tue, 04 Aug 2026 16:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrI0W-0001HG-3K; Tue, 04 Aug 2026 16:28:48 +0000
Received: by outflank-mailman (input) for mailman id 1382458;
 Tue, 04 Aug 2026 16:28:46 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <broonie@kernel.org>) id 1wrI0U-0001Fw-IU
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 16:28:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrI0S-00FQlU-7E
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:28:44 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <broonie@kernel.org>)
 id 6a72131d-bab6-0a2a0a5309dd-0a2a450acd8c-36
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 18:28:43 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <broonie@kernel.org>)
 id 6a721339-f2d2-0a2a450a0019-ac6904fee07c-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 18:28:42 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 62FAC600B1;
 Tue,  4 Aug 2026 16:28:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D41C1F000E9;
 Tue,  4 Aug 2026 16:28:39 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1785860921;
	bh=Kdx7GX4k8VWy3HBExGDyAtAIzWicr30iQzQ7BTOYMx0=;
	h=Date:From:To:Cc:Subject;
	b=RfJsSEv+0WQIiqBqX+7JmXsd3Yao6K9YFuLGoKPMZHayEMm6OPcMpVasJ1roiqS5/
	 rH6vRfL086JTj4gCfzn8Jjo83RdWKQsWUouiRq8i462SqUhipclb1katmLwp97Bc/P
	 zuZ6b6Hqfd3w0ZfbHOddHZKjj0qEApyu6Oqo9V5nSD+xHCcujTxvAlDbKd3k+hsLvT
	 gjkmxpVJZSaYLr/LB0CkweTPoFRqZBtr9C45HucfPhBqxlp33OxzgDr8HmAo7TPt/b
	 voYOypuu6WZX1zVakCN7jF8jxsIDZkX25YA8yharns0KvCxx7ERFntRp5KILs+3Ht5
	 tNOTZrdkWJPTQ==
Date: Tue, 4 Aug 2026 17:28:36 +0100
From: Mark Brown <broonie@kernel.org>
To: Val Packett <val@invisiblethingslab.com>,
	Juergen Gross <jgross@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Xen Devel <xen-devel@lists.xenproject.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: linux-next: build failure after merge of the xen-tip tree
Message-ID: <anITNOG1qicdE-TI@sirena.org.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rglbo7ou1xcCVJY2"
Content-Disposition: inline
X-purgate-ID: tlsNG-4011c0/1785860923-4BED2CFC-7A2F5682/0/0
X-purgate-type: clean
X-purgate-size: 1029


--rglbo7ou1xcCVJY2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi all,

After merging the xen-tip tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: modpost: "init_mm" [drivers/xen/xen-privcmd.ko] undefined!

Caused by commit

  64d26fb2ad1f2 (xen: privcmd: fix ioeventfd crash under PV domain)

I have used the tree from next-20260803 instead.

--rglbo7ou1xcCVJY2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmpyEzQACgkQJNaLcl1U
h9DmEgf9GH3biACmWnmq/yNJJWbRBo9ckKis4YF8r9wWF3cUXlbPpFU/onwdiX1R
8niVRJ6do7WpnIleXDsraBsdZT+5A519dVcvwZQTGPZij3w+H6/8kbtSBvDK0hH8
QXNlGwdUHrC4Dmfnn3b7cSHA0kM1u7lkmGwlNjDnDypmVw/tV9KOVRSrFRDk1yax
mjo6dYuai6eYmZ0RwZlX7R1u0BDDnJq0qwuI0Rz88ZvK8YSrE267CSXwQl9sJhzy
S4Jclf7ASn5mR3RiNeI7ad/S8CmWOE4hFQLD/MaWEOFXB1ZkFpM06cRsD/nuSzld
nTl9c3Va63TUmODp3RhIh3aLzwy7Wg==
=/t8B
-----END PGP SIGNATURE-----

--rglbo7ou1xcCVJY2--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 17:14:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 17:14:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382486.1625843 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrIi9-0008QK-E5; Tue, 04 Aug 2026 17:13:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382486.1625843; Tue, 04 Aug 2026 17:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrIi9-0008QD-BC; Tue, 04 Aug 2026 17:13:53 +0000
Received: by outflank-mailman (input) for mailman id 1382486;
 Tue, 04 Aug 2026 17:13:52 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrIi7-0008P2-T1
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:13:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrIi6-0074nb-VO
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:13:50 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a721dcb-bab6-0a2a0a5309dd-0a2a4502d854-4
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:13:50 +0200
Received: from [52.101.56.24]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a721dcd-6ca4-0a2a45020019-34653818a7ab-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:13:50 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by IA3PR03MB7764.namprd03.prod.outlook.com (2603:10b6:208:50c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Tue, 4 Aug
 2026 17:13:48 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Tue, 4 Aug 2026
 17:13:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QGqyhXyIjLDdWAVieG7QobmoigOgx7jcmvd0xhTz+8+AZEF4L39zMbaYEzw2+y1TJnX38zENReqjUONan/go71Ky0mjnoESn6IYDA/i8RhDvT2LQCDKip/8eq2rjrZLsAbWZhwybcO/GhKgcWmOLz0MlYhSp8c1jGBH/lju03M6E/dg5pmC9O/NNURFwbsg8datYFRSgKIcxaVC936lJJmgAtMedfJv2/L3/8Kys/XS2fAgSkPDchKMTIit0XWtIZut8bnNdn9U8NiwAwsIJtgMlLOX90tK2IqxVOaihFEl3O9llijOXxYFq+Bj8/K9ONMceB7QZTvcuYAzExZ/xXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zx1F8nl9j7tXALRL1U17qJhg2+6Ayc3Y9A703hScVhM=;
 b=TPS3ymXgNmt1+AbanbjR7i34cJSGw6Vz8jqtyUk5NRzv/HYUQmEwyYCV0lya8qD2DTphh5Jrlb7UYiYNUTHPVpS7yS1SL1mo/9NzGikfTONHlA7Vad7IdPrhRN6nWibiPawuObQbVm4vW7PkUxWtmY99tQrXE9yWJ+sDOLHbrr5ZaDw+++/nS76DXg6Tr0YyHAWHhnAGJ0FZ/xOcArx+SYKGLz2wuVAZWHx0NX8hy/keibBtcGuqDsOJprO9goVGLoPyu/pq02DfHmu5zTHtLHZdXASWzX761U/xoiczTRysAfqeejBYPEEUk8quUNaq65irqDlsgGr1hg5RWo13Bg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Zx1F8nl9j7tXALRL1U17qJhg2+6Ayc3Y9A703hScVhM=;
 b=s4DfpHnWS4P0kCgHZKBhdNtseIiIh6oGHlo4wUM477JEnnZjtXU+l1qy6elteXMfO52zQRanLy4I4KN05206EBsclnQywr1p+EkIAGxwPqZVb5JIwGvPF+K7D1i1RL3ODofNf3loniyVmX9/MyOOkzNuF2w3AxJ4GmWBhLLi9T0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <f15222a9-1d61-4d9c-b923-8e6ad4994af3@citrix.com>
Date: Tue, 4 Aug 2026 18:13:45 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/3] x86/alternatives: Rework get_ideal_nops()
To: Jan Beulich <jbeulich@suse.com>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
 <20250522150015.555492-3-andrew.cooper3@citrix.com>
 <99a39800-dbba-4d37-afcb-ae041af648f4@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <99a39800-dbba-4d37-afcb-ae041af648f4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0106.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:191::21) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|IA3PR03MB7764:EE_
X-MS-Office365-Filtering-Correlation-Id: 014bdde5-ee34-499e-b69f-08def24bbf2b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	ELexaLCm117iZoWkpMbWEEGFU+12lY+u7pKjX8TUSi9VH+bQXwKhjvfXvmbePfAbxtJc7noRIcvlYJOJiEUJTHUlRTM5Iudv1BbmpvHo1DfTYqIiRdClZUeO2SJiSOqSEngqSq+4oo3i11SA+jFABTMEVQ9OSShF9oMe/6agN8vAEc5R2Uvt7jJhatRapY1+kwnyGvTfWr9ZBemzrZbSrLlPpQDFvZnjGGbiayv7tteQQ/C2KSM7kwTdzVDJ+xy0V7+wf9DTzoI3On7Y6t6CIJMAyLyB0R+8Z1Ipon+LEIKSJ9GtwXDQcopwpkB32NB3JZ/QXPVsKXIv3Yx6RT5tFoZ/CXMuc4GLN+HUeZpEt+uk5MNHmXdU6aZtN54QpgtpYEDbmovoOzCnFJ1rTGi4NPMpbn5GqhvwjP/6X3qJmn0IebMg/tafxLBE3nrxSFTCeUbtikpog7582d2sGoboHex2kHcuZtSZl2mo/TJoslbdTnJuVb1+30ttecHTJpXvxae76C7OeFAjOT4kTuAoxUTmxxexUIoSw236qjzy8ZGM18+Flpa9C+M5Eagxq89katBEj+GEuuDjNUmyuU7mcRCxRJloGS4mAkoBUeMUVLLuWN+HbREijms1SJtbKJhIiWvzCwNYFIYTYDaEjEl3VRoJBavDFmMfh5lt8ZPaYUY=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ckcvdUI0b2xoMUhMVXA3VzhoYnM4OWsrQWZqNzhHazhncTNDUkZSSmQ1bXY4?=
 =?utf-8?B?bnFYYVQxa2djS2J1Ty80WnMrNlU1c0YxQlJJcGNuM1FscHhjTUZrRFAzS1hZ?=
 =?utf-8?B?T2ZnTUZleUtORHBVZFNZenczY01Pa05wWkU2NitGa2tWWmxaa00wNEdEeTBY?=
 =?utf-8?B?M1p2bFhKUksrb0Z6dUJYeHZNOUUxUTNTQ05MblJDUklQZGpHOGp5d2xnQms3?=
 =?utf-8?B?VW96VjFVaXpaeFlmYmNUQ0ZEOW9kVFJKY0Y4TlZIamowYUxsdzJiVTRoVjN1?=
 =?utf-8?B?Y255SnhRRzZ1ckRITE53WFhPQzZPZ0l4b01rSzcyTTAzMHZrVkZSanBwS3Mv?=
 =?utf-8?B?VWJzSjNuUjJGUmlCOEhXWGtzQjlDdWprT0RGS2NOOEZkekFvSlFVeE9lUmpX?=
 =?utf-8?B?bkhvSmlxOHZRZ25sQ3lkdGxFNjgwT0lrSDU4emlGTU5xRHVVQ1pvenQ1bVF1?=
 =?utf-8?B?UFQ1bm9HRUxpRUhReXV1ZXpPZDNERmhTTFR1bTNacHJjK3dKRlp3dlpyVkIx?=
 =?utf-8?B?d2RObVhWUnBGTWJWRUNkWDlBOS9Dbng5UGlaVWYyZ3lUVG9MS2FFOFFhU0tU?=
 =?utf-8?B?QUVEMGdLMkx2TGZYWGZRSW1XcGRabVFDb2k4T3c1VVdQeUVwcHZwNnRBcDhl?=
 =?utf-8?B?Y1gzQ2ttYU16VEFmUFdkYTYzWWs0SFZOZGRJOGt2MGQwaFlBYjg2bVBIbW9W?=
 =?utf-8?B?S3pTdkt1V3l2d1V4RWkzVmljYnJONkRFUmIwOUpoRXJDbW9EV3Z5WDBxNGZ2?=
 =?utf-8?B?TUlVTWc0ZmdsRGhRT3lkZEpOZTVPZDBDUTc1Q0IyUVgvdWJ4MmhDZ1N3S2dq?=
 =?utf-8?B?YVZnb1hWZDlTZXFFcFpPMmQ2M0s1TFVRWFdlN0hKeHh2NkZRdmZWaU5mRXRr?=
 =?utf-8?B?eHpNdlY0Zm1SZzVZelJ3azBuZHJxWlFpc0dTVGtYbTZTM0VQWkJaTlJ0Wk5v?=
 =?utf-8?B?aGN0RkhVUStkOVlEOWpmQzFxWXlWR2RRaDV4ZGkrYXJPdThxcHFqb1N2bnpL?=
 =?utf-8?B?YTNKNk5pSDdrTW9rL1dDY3dEeUx2bWhIREhhYXYyY3Zqc1ZBUGJmTGZObDY3?=
 =?utf-8?B?d1hERUMwbk1iK1RYUlZzcGphcVBldGlaZWw1TXUydFJLSlB5aVVTMDlUdlY5?=
 =?utf-8?B?SDg3SjM4cDBrdlZjMlZUSXU0d1cvL2ZWWDNQbExUZktML1ZJQmhCT0t2U2d0?=
 =?utf-8?B?a1IrR2U0bFlCYkNDazVPUjJZelBoMnkzTnNDTGg1ZWRna3ZXeExST1gwMk96?=
 =?utf-8?B?eHNhWnhPQlNyeUtZSmVHRW56ZDZkRFBrbnBzdGV2UW5IdzFHaVV2VmNvYSto?=
 =?utf-8?B?RkxRTGRiNGR0MkhJQW9GR1FhYWVCWDN1YUg1aklCNFdQT3FJQTNzV2JxbURl?=
 =?utf-8?B?T0o0SzFGRjU0OGE1OFN1NGtleDB1enE1YXRuRzVUdjdFVDMwWDlsWEFvTSta?=
 =?utf-8?B?MGk0SHE1RXhHT0gwWFlSOE5nT0dGRVBDSmREblZqK0ZyY3hyRU5yTUVtWnNB?=
 =?utf-8?B?R0prVkF6RFFkTi8ydjBOanJjVWthRVlaNlpUSGNuR25wbGZxemh3b2haclNa?=
 =?utf-8?B?dUN4V3hJNGdFaTRkdEo5T1RhL2VuOFVKbmo5Y3ZWNnhzQWx0bEphVGl2Z2ZG?=
 =?utf-8?B?K2dKVzdQRC9ra3pDQnV3WlVYSXJ5NmMzQWVPNDVGWGFPK0YyaVBYSjVjV1V1?=
 =?utf-8?B?VFVlWGZlc2Nza1BQY2JjbGZlWU5NWmNaN0w3RjAxSFZoNi8wc0VrMUd1TWEw?=
 =?utf-8?B?bXlXMjhUMGtvbjNSN1F5cE5DekVvNmIrS0lRV0dISE4zbE9HVVVkK2k5ZUZ4?=
 =?utf-8?B?azlMdzlYUHFJSE1keVdZRjJneTBYSTVlZGwzNGNCeERjeXRHSHZWcGo5Z3do?=
 =?utf-8?B?L05SVFdZYkV2dE5oUWlqemRwZWxuWWw2ZTl2czFwci9wQVFWVVVhYlVJdUZz?=
 =?utf-8?B?ZTNjM3ZzR2pMNG9raUlGSTRjU1NzVEVCVUtYRTArRGFkLzQrOWlZaVo2SXh1?=
 =?utf-8?B?UXFuOURKa3N6NWlxcmE1d0RaREx3MFY5ekhzVkV6cHFVbXhsdUZ5MnhBU215?=
 =?utf-8?B?UVBLSkw5eERvRWc3Wk1UNUJ1T05oZjdzVld1dWIrc2d6UWVaMXZ0eHlDUGtJ?=
 =?utf-8?B?MDhKay95bndaWU4vUmV2amdYTi92cTdXaXV3SGNjNkw3V2pOQXJPWlNqblAx?=
 =?utf-8?B?bnJWY3drWEo1ZzBPSEhMNFVtTE1jSGhlWkdYSzdsSHFhMkFrdjMwTmhKOElk?=
 =?utf-8?B?c1hZdGZ0ZXhQTHJ2TFc5NHhFeXJIZDFVYmFjWktaQ3hxSHhCNTlRdTlWVitz?=
 =?utf-8?B?aHZ1QUVoZUN0a3YvS1JVSnFxU0hQdW1maVlYZW5tNXNrVTMxQk5hQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 014bdde5-ee34-499e-b69f-08def24bbf2b
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 17:13:47.9026
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9Bt+f3sgcPHL4C52UO/P9UYPd1D1ZYyYECTrUJA3pWMQiaJ0gcj6MPVypcBfB6DBASI9XG1iJbPArlQttFrxprUeM71WWqkJ+jVIsfZtJfE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB7764
X-purgate-ID: tlsNG-720697/1785863630-31FD62AC-F0D9089F/0/0
X-purgate-type: clean
X-purgate-size: 1662

On 02/06/2025 10:57 am, Jan Beulich wrote:
> On 22.05.2025 17:00, Andrew Cooper wrote:
>> The implemenation of get_ideal_nops() changes from:
>>
>>     mov    0x19bc41(%rip),%rax        # <ideal_nops>
>>     mov    %edi,%edi
>>     mov    (%rax,%rdi,8),%rax
>>     jmp    <__x86_return_thunk>
>>
>> to:
>>
>>     lea    -0x1(%rdi),%eax
>>     imul   %edi,%eax
>>     shr    %eax
>>     add    0x67fc1(%rip),%rax        # <ideal_nops>
>>     jmp    <__x86_return_thunk>
>>
>> The imul has a latency of 3 cycles on all CPUs back to the K8 and Nehalem.
>> It's better than an extra deference on all CPUs, even the older ones.
> While this is all good, what we're losing is ...
>
>> --- a/xen/arch/x86/alternative.c
>> +++ b/xen/arch/x86/alternative.c
>> @@ -20,7 +20,7 @@
>>  #define MAX_PATCH_LEN (255-1)
>>  
>>  #ifdef K8_NOP1
>> -static const unsigned char k8nops[] init_or_livepatch_const = {
>> +static const unsigned char k8_nops[] init_or_livepatch_const = {
>>      K8_NOP1,
>>      K8_NOP2,
>>      K8_NOP3,
>> @@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = {
>>      K8_NOP8,
>>      K8_NOP9,
>>  };
>> -static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
> ... the (at least visual) connection to ASM_NOP_MAX. Could I talk you into
> adding build time array-size checks for both arrays, to restore the
> connection?

Sorry, but I have no idea what you're asking for here.

The use of ASM_NOP_MAX was latently buggy before; it was easy to create
a NULL deference if the initialiser wasn't filled in when ASM_NOP_MAX
changed.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 17:43:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 17:43:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382507.1625854 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJAc-0004HL-JF; Tue, 04 Aug 2026 17:43:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382507.1625854; Tue, 04 Aug 2026 17:43:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJAc-0004HE-FS; Tue, 04 Aug 2026 17:43:18 +0000
Received: by outflank-mailman (input) for mailman id 1382507;
 Tue, 04 Aug 2026 17:43:17 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrJAb-0004H7-CC
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:43:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrJAa-001NYu-PP
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:43:16 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a72247a-bab6-0a2a0a5309dd-0a2a450ab7d0-42
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:43:16 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7224b4-f2d2-0a2a450a0019-d1558031f1b1-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:43:16 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so551155e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:43:16 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994dfe64e0sm17657735e9.6.2026.08.04.10.43.15
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 10:43:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785865396; x=1786470196; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=xhcQEnEut2xAAreQwODiVE7doxB7Jsdq8IAHiAi9kX0=;
        b=bFsJNWfxrZDnotwsthDQHRligR74wV1Yf63ba+bANB2BJMddjVo23AX3Srm1c276pD
         zf4bSmJjoPVhN2I8sQ0FLEcHZk0t/zLqi6b1IwiRfuFEGIghtt7q4WmaeM5FcnIMXDrW
         JFQzQeDprL/u+9VqqjhH6FGUSQLnK73qcVmAp/loTTvtQ70A+21951SvQ1obMt+znAcx
         tZw5ACqXsnZ8t0aBgoB7FyEc3CLQ5uQL635+Qv7Ku2bcrqizWlM5I7QBsW+H+ct5t22g
         ALup4uHxUHksE3BN/U/J5Zbo8k1YsmqTnYBjCiHebhzyi0ZcRWeeIeASA01IPTiI6wFP
         PnTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785865396; x=1786470196;
        h=content-transfer-encoding:mime-version: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=xhcQEnEut2xAAreQwODiVE7doxB7Jsdq8IAHiAi9kX0=;
        b=fHpeYBAUENlJ6kFDLbWHQCIH+7X3iw7g0oD3DqAgOe3zVi38lcsGadycKzD+6LTjsi
         OvdYTQzcS1Jah1EiRfO+8jaXTKggxoVof6e1jKtQrj1bu0667sKTRfoFGpBquiofy9sX
         l4CX2XuZgSqjX0au+F2lMgaEGPDrSxYRJPbTHS8kbOR//dOsWulbpaMs/XD0Qk077q+q
         IVFXtC/kUMGWgbM2Ei8mRAko7COf7WJlqFOJM8uQ4KOk97co+tFVB+rfafmAA2xMyjFs
         ofJj52FtCERHSXPCKhFyEViiaSZZnpm2Pl1VejjIdUHQnmcmQOWg+GhYq0upTMubZKJX
         Ue0g==
X-Gm-Message-State: AOJu0YxYSRNYgvvBYPiXV0WZJAKc2XLhKLajwDfiyO494NhyUfHUw7Hp
	yp7+UqZ5TYjIAB8+oZvMleVBeyA8jIT7SGajqmnG29PLe4qG2tDN9qDCa3TpwZsaviU=
X-Gm-Gg: AR+sD10+avuvoJ2/d+lJfhLeuz7z1bhzY2mz8GEDnxOVNs5n+4qN3LbLD1ZIFjmWf+P
	UWGzkIcSDfvrYxW9o3E+72JDYhOMI6mb0oBrzFiyDFxxsyd4ftzAOrjrshBIPiBTb1mpsAPDpLg
	lAmKTdQ1+xZosZvaTaB+IMTtkTO1eMugUAVwZj8e9QxHe0uwnSHaZcjFvZA0htGe/LEM3IH93BT
	YaGWXlBi0ZneEFWpOm+ri7/Bf/kSr2hfXfrwxzjexwiBHKs6MeG5jKru3Bldy8zgEMbvP+2/yhk
	xkCWs3+yKLUPTShG+LYkmz5TqCMTf2KTLCSlMzUEXmP8+CvA3pUCF259VVORvO/7OC/7EetVcbK
	Od+xJ8aivgKcv87Z4Vr7UISKVE8XUcFV/ZVVeJ/3y1YXX19uIso670jMnRaMd92oTBUNRMypn5Y
	07J4yf5S0OdjyPmDoWai4aynx8VmeJCDY4KATPqXQELIMvQB8o3uivxndQ5Ciam7kd6F4nAYdRI
	2lHjPndiaMGjvvciVatolckoH1lFAjaNewim3U2fNJmEjgI03k=
X-Received: by 2002:a05:600c:e48a:b0:496:ca1f:a428 with SMTP id 5b1f17b1804b1-4980c695d6emr250589315e9.19.1785865395972;
        Tue, 04 Aug 2026 10:43:15 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: [PATCH 0/2] CI: Check save/restore, minor style update
Date: Tue,  4 Aug 2026 18:42:16 +0100
Message-ID: <20260804174219.835096-1-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785865396-530D9CFC-369CA70B/0/0
X-purgate-type: clean
X-purgate-size: 483

Main change is the second commit implementing a test for save and restore.
First commit is just a style change to reduce number of commands (and lines).

Frediano Ziglio (2):
  CI: Simplify directories creation
  CI: Check save/restore of PV domain as part of qemu-alpine-x86_64

 automation/scripts/console.exp           |  8 ++++
 automation/scripts/qemu-alpine-x86_64.sh | 51 ++++++++++++++++++------
 2 files changed, 47 insertions(+), 12 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 17:43:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 17:43:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382508.1625862 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJAe-0004U4-Oh; Tue, 04 Aug 2026 17:43:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382508.1625862; Tue, 04 Aug 2026 17:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJAe-0004Tx-M5; Tue, 04 Aug 2026 17:43:20 +0000
Received: by outflank-mailman (input) for mailman id 1382508;
 Tue, 04 Aug 2026 17:43:19 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrJAd-0004Ti-MG
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:43:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrJAd-001NYu-36
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:43:19 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7224b3-bab6-0a2a0a5309dd-0a2a45098d02-10
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:43:19 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7224b6-be1a-0a2a45090019-d155dd33d504-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:43:19 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47c6e9a694bso51476f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:43:19 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994dfe64e0sm17657735e9.6.2026.08.04.10.43.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 10:43:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785865398; x=1786470198; 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=LJbe7BqS6R6E73aZnDhX1SHtM9ZoBc4H0nu3Jn4E/GA=;
        b=DqYzRCwxbpS0JBRR9yh85QOfeJrEXYjOciB+ggM3H6dy4SEN6CTBXzOLLM05GVPBVQ
         kx4sBSV2nJyNhe8RRvIy1Bh07NytXOofvod+4xnLIOK+zO6v68NVe/ROz/0G0FJdbekH
         zdRLxC2NnWnpUF5EeDvjHwFKT9ZocFWXoBc6+cVA52Tjw3eZJKOnjqXBB+HV8ww4UqZo
         VOO0CMsMbqFHx0xPs/12H3a2Civ//tFz1nDZ8G3PmcZhGIS/18L6msW65rq4Kqju9xnA
         B7ZeZQUp2nadvHVexvxMkZszIYAiBIX7wnfYaKVugxPkdN6BIeVkC4holbRjepveD87w
         vosg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785865398; x=1786470198;
        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=LJbe7BqS6R6E73aZnDhX1SHtM9ZoBc4H0nu3Jn4E/GA=;
        b=HsEmDmuDwxNPHK0ICBO6oDoSYCOGLYtkuuoQh+MOpaZbcQbiYzPqmzTslsiuNRVSF3
         CmTDpspq0Lo+3LvSP2eHOx0FWD7oW0pWjnHsE2VMjbFs6cBHycCheTf4g7Gfu/nFa+lM
         6SzlUy3vuJqigxr4obqOhoX6VuHOgszkTy9wMlY+N5GyXX1tr6yrg+oeBf5dV/dIlrdL
         zxlCVUJpF4gisrOEbVGTgo8HHagOtQL/NPLdeAUXLsaUXRvgrJbscuawIEzx/xmKMGlt
         ++E9WSXO14hsL7B00F8p0iWOKgRCrmnscbEQhB1zsLitTgFHkWx7wAuXnAp0gQUBV9Sy
         8Wnw==
X-Gm-Message-State: AOJu0YwHGndAcSUQM+5ptEgmGIegh6T4Z/TNtcN/aeIPq8vfCp2ZIEXW
	ujujA2HJCTP4MzaOzy0f8Wcy/LiZLzUHxmPITc2Bn934SxW33vEWTXJwvKaQDZqraL0=
X-Gm-Gg: AR+sD12yCGX+3K4nGMTNxNLIgjgm0ds4ti+Egfx93rl4HcHWLtzXkymJL1Z4jy5voYf
	eLdJ4Bm9GLPXf8JPE2bhkwtszYU6QRx7PAHBGLxEtMzcUbWQAhJTUHrsCXorZ6xkN/Wj/BS+Ukx
	JWITU2p9cZf7rU3z2YDVvTw48qFDZNZ68QVDrqbO6/VTsfCIkiWsIiQF54GxtlzXDotZElkyC+H
	6v3aO9qoL5JpDJcyySDl9OXsm6lC2CCxlU0kLoSVKTwTmBW4ISr0vSCq+SmqJGt7uD07r1VA95x
	c+zeKusMU7Y4jORix5zS3ASXoFdwprd3vp44/xyVrcelqaVMPVn02j1ER4hZKTfCR+X+iWz60We
	BoxmM01o9R+W1va+aabcox5uYtd5zyG98ipUK7CSs4M+hEVMVcM+OQgOZ1eEsY+T7OZjzdlGpDG
	H4VHS9utpP56SdSuoa6sohML/Ud6eheSOUa/xIXVn02leUfHhj99oDYpGOWUxouw1yFqnDTQJXi
	H+ZOfYNF0tV1rvZftlQHUL14jHAZpONUb120FNi
X-Received: by 2002:a05:600c:840f:b0:493:bacb:1341 with SMTP id 5b1f17b1804b1-4994e72605emr742705e9.4.1785865398418;
        Tue, 04 Aug 2026 10:43:18 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: [PATCH 2/2] CI: Check save/restore of PV domain as part of qemu-alpine-x86_64
Date: Tue,  4 Aug 2026 18:42:18 +0100
Message-ID: <20260804174219.835096-3-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260804174219.835096-1-frediano.ziglio@citrix.com>
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785865399-FD668034-4C7677C1/0/0
X-purgate-type: clean
X-purgate-size: 2998

Make sure that save/restore continue to work.
The check save and restore twice to check for corrupted status.
Also a command is launched in the guest to make sure that the
machine is not crashed but working.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 automation/scripts/console.exp           |  8 +++++
 automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++++--
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/automation/scripts/console.exp b/automation/scripts/console.exp
index e27886bbef..ff58ed29b8 100755
--- a/automation/scripts/console.exp
+++ b/automation/scripts/console.exp
@@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
     system "$env(WAKEUP_CMD)"
 }
 
+if {[info exists env(EXPECT_TEXTS)]} {
+    set lines [split "$env(EXPECT_TEXTS)" "\n"]
+    foreach {exp snd} $lines {
+        expect -re "$exp"
+        send "$snd\n"
+    }
+}
+
 if {[info exists env(LOG_MSG)]} {
     expect {
         -notransfer -re "$env(PASSED)" {
diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
index 60f5cc49fc..409a601c34 100755
--- a/automation/scripts/qemu-alpine-x86_64.sh
+++ b/automation/scripts/qemu-alpine-x86_64.sh
@@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
 
 " > etc/local.d/xen.start
 chmod +x etc/local.d/xen.start
+
+# Script to test save and restore.
+# It saves and restores domU domain twice to check if the domain was corrupted
+# during the first sequence.
+# At the end open the console to check if the domain is working.
+cat > root/save_restore_test << "EOF"
+#!/bin/sh
+set -ex
+xl list | grep -q domU
+rm -f save.dat
+xl save "$(xl list | awk '$1=="domU" { print $2 }')" save.dat /root/domU.cfg
+xl restore /root/domU.cfg save.dat
+xl list | grep -q domU
+rm -f save.dat
+xl save "$(xl list | awk '$1=="domU" { print $2 }')" save.dat /root/domU.cfg
+xl restore /root/domU.cfg save.dat
+xl list | grep -q domU
+rm -f save.dat
+xl console "$(xl list | awk '$1=="domU" { print $2 }')"
+EOF
+chmod +x root/save_restore_test
+
 find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
 cd ../..
 
@@ -70,9 +92,23 @@ export TEST_CMD="qemu-system-x86_64 \
     -device virtio-net-pci,netdev=n0 \
     -netdev user,id=n0,tftp=binaries,bootfile=/pxelinux.0"
 
+# Sequence of expect/send strings:
+# 1. wait domain start and close console;
+# 2. wait login prompt and login as root
+# 3. wait login and launch save/restore test;
+# 4. wait restore from domain console and send a command.
+gs=$'\x1d'
+export EXPECT_TEXTS="BusyBox
+$gs $gs
+login:
+root
+login on
+/root/save_restore_test
+Restarting tasks
+dmesg | grep suspending | tr o 0"
+
 export TEST_LOG="smoke.serial"
 export BOOT_MSG="Latest ChangeSet: "
-export LOG_MSG="Domain-0"
-export PASSED="BusyBox"
+export PASSED="suspending xenst0re"
 
 ./automation/scripts/console.exp |& sed 's/\r\+$//'
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 17:43:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 17:43:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382509.1625867 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJAf-0004WF-07; Tue, 04 Aug 2026 17:43:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382509.1625867; Tue, 04 Aug 2026 17:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJAe-0004VS-Sn; Tue, 04 Aug 2026 17:43:20 +0000
Received: by outflank-mailman (input) for mailman id 1382509;
 Tue, 04 Aug 2026 17:43:19 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrJAd-0004HD-Nk
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:43:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrJAb-0078XC-I4
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:43:17 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7224b2-2eae-0a2a0a5409dd-0a2a45059d12-6
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:43:17 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7224b5-4cb1-0a2a45050019-d1558036d52b-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:43:17 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so620835e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 10:43:17 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994dfe64e0sm17657735e9.6.2026.08.04.10.43.16
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 10:43:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785865397; x=1786470197; 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=QpDC3I+ovYUvjlP9wcYAb5gWHhSg8anilOmH4yhtzyI=;
        b=ZrmFnrPfXw2bdZcmMrNRblnkq3U51V2RwEUqp1Pd0j2tgWQ/fMXQmHxPhKFZKBlJX0
         VsXsyLT2ANXupm25z55oG1wkYwWj1MFCzrc2Vbmj0aDRmBQnx/CMZvVEyzLhV5gMgJaT
         mng25wzn6bhBCtVFu6X25GdXiFjdR7+3reQAza+gO3+TrbwVf4SawPpCyeECzESTVSRi
         BRCcu4KE60z1DyS2QZSDmTPcX+GOi0N7SPuOyVyuN0wGzORib9aWxxQgXTmIIatk7Ekl
         VFf7N+xewO3jh7LIgmvg633zHLHyq5rp0FHl1xfuSJy2qai13T+Fq3y2w58CIUOLss0L
         4sdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785865397; x=1786470197;
        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=QpDC3I+ovYUvjlP9wcYAb5gWHhSg8anilOmH4yhtzyI=;
        b=FvJkflRghY9sO7ZdcSVPcryvIX2My429yYdun+Scgn0UZ18dOwk3Jq2sTc+WfKVc2D
         08/q1KYvyq6EKMQaq8RrY2W58Bz00kZgKmyWBVep0wXBABXlud2/pyClx2O0rp50ZsiV
         M/4cq0T1FV2dlxRwrzWpxg5r7IebOl6ejuJGCfV3lJZlHr6V+ckvqVFDsfQ/0D/0zzPJ
         orV1UX2DuE52XFJa5BP2kgSuUbf4WJBkuv/32I62F4x3WIZwryIIsDovShuI28AwaKAr
         ZQJMEpTSifyX3uttjDchYd1SdGxSKnRFbMJgIn3K35u3aKzWvwBjqVO40dXPWoL87f63
         czog==
X-Gm-Message-State: AOJu0Yz6GvkKFEyGmDNnNLvnm1eZfZFDFcE+KDzUwYvNtSFG9lwlnIqb
	eUVcA2uIDJQuqQ+d8PwineSr5YZa4ULnRCG0omRVuPfHq1CoUWBNHZ14QMr8t3D86lg=
X-Gm-Gg: AR+sD12X8GU+UbY2kWybEqu2dMdkxBFtjowquJzGC9vYEaWpDcRYukS2bmc1JkEB2ie
	iwWszCgDC6NlZfddbd8g5MUEURi40gB2NO1GzJNx17+tjUAxDrBvYAwnh4p7n5L9DfaZbV6tzmj
	lu7WbTZ3/6i/ilQnNT7p+R4wsZICAEq/SeMMHzX1Vq1A8JFc+vu3RCAjsKUp3a+rinnxO4EBbFh
	qhHkLoZ1L8K+0Pm7va/9X5s4ooyHlaSBHYGpugB/n0DB2n9r07euTLswRYyWWkZW/i6LcEVhYeo
	jeBkoKY7uvoWibcOSWVTmDu91SEpVR74N84KMleuQkCX7J2dQKoHheZYPFwqMaTTJUE5sHRWAS8
	5wQ6z+RMZHzjAGmXqTroQ1WDoP76LEKY9PWe9LkBq1BSCj9LDTbH16bm0zHl+OlFijoWj5ZtBbZ
	axCjgVu7+minBCVKUHkYhxMpEJY+Nl40azKeQiAP10Gfxuyr++h9bhKB9eK09O0CyOpwwaOxQch
	DvzmdoOz/qzOcDyNR+D3PqGi4Uy8J5+O/scAaquYwwzhsTQQns=
X-Received: by 2002:a05:600c:3586:b0:499:49f3:77b1 with SMTP id 5b1f17b1804b1-4994e728283mr695025e9.3.1785865396781;
        Tue, 04 Aug 2026 10:43:16 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: [PATCH 1/2] CI: Simplify directories creation
Date: Tue,  4 Aug 2026 18:42:17 +0100
Message-ID: <20260804174219.835096-2-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260804174219.835096-1-frediano.ziglio@citrix.com>
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785865397-F429B2A1-013AD751/0/0
X-purgate-type: clean
X-purgate-size: 894

Use a single command.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 automation/scripts/qemu-alpine-x86_64.sh | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
index 242ffca693..60f5cc49fc 100755
--- a/automation/scripts/qemu-alpine-x86_64.sh
+++ b/automation/scripts/qemu-alpine-x86_64.sh
@@ -4,16 +4,7 @@ set -ex -o pipefail
 
 # DomU Busybox
 cd binaries
-mkdir -p initrd
-mkdir -p initrd/bin
-mkdir -p initrd/sbin
-mkdir -p initrd/etc
-mkdir -p initrd/dev
-mkdir -p initrd/proc
-mkdir -p initrd/sys
-mkdir -p initrd/lib
-mkdir -p initrd/var
-mkdir -p initrd/mnt
+mkdir -p initrd/{bin,sbin,etc,dev,proc,sys,lib,var,mnt}
 cp /bin/busybox initrd/bin/busybox
 initrd/bin/busybox --install initrd/bin
 echo "#!/bin/sh
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 04 17:57:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 17:57:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382534.1625881 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJO3-00073v-B9; Tue, 04 Aug 2026 17:57:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382534.1625881; Tue, 04 Aug 2026 17:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJO3-00073o-6h; Tue, 04 Aug 2026 17:57:11 +0000
Received: by outflank-mailman (input) for mailman id 1382534;
 Tue, 04 Aug 2026 17:57:09 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrJO1-00073i-4w
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 17:57:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrJNz-004aPi-VW
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:57:08 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a7227ec-bab6-0a2a0a5309dd-0a2a4504d772-4
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:57:07 +0200
Received: from [202.12.124.147] (helo=fout-b4-smtp.messagingengine.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a7227f2-b57f-0a2a45040019-ca0c7c93a625-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 19:57:07 +0200
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42])
 by mailfout.stl.internal (Postfix) with ESMTP id 9BDE81D000D1;
 Tue,  4 Aug 2026 13:57:05 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Tue, 04 Aug 2026 13:57:05 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 4 Aug 2026 13:57:03 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1785866225;
	 x=1785952625; bh=ilvpJNpKGxrxV5kM33ClZ1xTMRTeR1+MX3jPiDtUlC4=; b=
	K2METpv0Gv2Wyb7EmMIj1hF9Orky8caRFzOdiQDv23RBX9ItDXQ9Tg/YiBe0G8C/
	36eJQVyFR/8TkLqn2O+Z08O2dCN2wuRPdwi+DzfaUx1E8YgCWAW81FiMqX68F8gE
	Y5tz0uGe69B26aitB+8ZkC+t0H3YJA1atBI35XJi1TkEasNn60oOVr3RpRw5yBmX
	FpLjua26wZ8qWIXFYNEnJx2i/NsS99idxEOEeIp5Dx1qJRWIanffRroegbXaqJ3b
	5lBzDDH08i7ztpti1/nJ8YGwMh+a8npCEGjW6X+Ggf4VtrBJY+0l1ohtytG94mIb
	YNoHhF59DJvqLRCdb8VXZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1785866225; x=1785952625; bh=ilvpJNpKGxrxV5kM33ClZ1xTMRTeR1+MX3j
	PiDtUlC4=; b=TfFt0xlY436n2kfkobk2xkIQ+/ScVkVZ+KlgO+jTCDv9zG4ARCt
	lruEPNOXon0fRui7dwg5FCJO0yfsPOmahqGlTQ6p/NrWtJLZSk0ZieNb3fENt5t9
	q1URJoOM1dDefmIN8A93F/pTWz1cgEKuFG7XKNiGTtygJvZyCyuncxl5qjFzkpir
	NOLGSJHG42vgX3mTPX9K8TBBgb9wOHhFLswaiIzZ7PVxZnk3DmCLcM3Vd8RSgydx
	glBUn7xX1EA9onJZXDgg+eS6+VfjOsTtnqn+CC/GDWPgOAo719C0nsgQvBbViJpy
	9PHUFlw5nbgGDqsudlIOfYsg3XLaw/8JI8A==
X-ME-Sender: <xms:8SdyaiJIuIo12wWYh6T8GLaWeJN_d4nH9r8IoZKGNdf6u-ImOgmupg>
    <xme:8SdyasZGa5s7k0Pn0p7dMkR-IGHmhA5zzhndG30EkLJWmjqVfXG4tyAvHXl7z-0Hn
    lyqY7HOTmcF4xgWm2yVLg_uNG1aswVxg7xvZb9rBe8Cl5dIplQ>
X-ME-Received: <xmr:8Sdyak_iDmyWR1EIaMQ1M2KRCkzJI1YijUnS63bvtI_25olxcTy44LlHMBkkPStQsqoKvFXlte2L3aFtRhMRMAXMeAQdXKYBXOs>
X-ME-Proxy-Cause: dmFkZTFTQJJq3HwzaBpsrRj+7R0dJX3Gux2GZu8uRmZucoiC10YCI5CaParej3yLyYTTgY
    3YqGdhJwj/V9t8LBWfFJaL6Q3bnm2sWD2nhCeJrWc0ZgocG2yOIt+62/ob58ziD3n6Y7dw
    yH1RupsKh6+yiK003ybzwftZ57tUkSEOZb/6+EsypgeVm1hwwfuP5WTKqL5DW4Z3KzjR4s
    /eGguNpw2ptQB1cGoRddE58w52TCn3p45tGJ9+ggZAikcIjODG0v1gaftQ8FpmVbfIoHlf
    Ux8KD113N3T87GdnjJaD4dpZR2aKHcRwDhC6CQfdWCR8RoYZiIpw+3E1Zw1A57TjSyjvSL
    AWYnQX95ns26OkobKtA5FWQO3XL0bdp4snaILbKRIEKSBI4qL+VsboOnU7QCgLYDkmIAcx
    XS0LAzRezC7thvNf5dlY4StuTOAStjo2deVlIEpbojfOUsmMhj1Efzsiqx2lsCqWnTisuo
    gBCfBW0WlC0o4+Era0pj66QfvoHsjRqAT/B91CWgIrqoyWAub6xNfkJABnhF1GqNeY6DQa
    q46ktbNR3bTZD5R8WXUuECCAIbrSOwVGpwtZBeeld3n1v3rCjnFvnYE67Yxgm+g4SmBRQN
    EgvDQ3cE7wwk/tGrbrNdzJrWDsAwf0iq0o3tUeuMMxJ47Nxs2c6dN6tzWo+A
X-ME-Proxy: <xmx:8SdyatbDLBPXPzyps6VA9IhCkl-MPq8_-v-YjlIpKjTbKwBInDgh4w>
    <xmx:8SdyaoN6_sb4qb8Ro1sR5OWsl-fFGn61_YQOhNCp8fc7lZeyhkb4Ww>
    <xmx:8SdyapA7fTni9-16UOWxyJ0-fpi0Xia-fXM6p_3v9x8XxVTPm7UnNQ>
    <xmx:8SdyavIXcDojc5TPRSvyRylZY6bGBLmLnLCU8Pws9_QvkWgqTeA1rA>
    <xmx:8SdyajRc_ubrMjvb-W2fjDsEyFM-C-OpW6sFI3zfO-8K_ULQQVzzwlb8>
Feedback-ID: i1568416f:Fastmail
Date: Tue, 4 Aug 2026 19:57:01 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64
Message-ID: <anIn7VAt2oQJ90Js@mail-itl>
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-3-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TDtZEqwh2qedq+2U"
Content-Disposition: inline
In-Reply-To: <20260804174219.835096-3-frediano.ziglio@citrix.com>
X-purgate-ID: tlsNG-ebf023/1785866227-C12DCB50-B438CBB6/0/0
X-purgate-type: clean
X-purgate-size: 4831

--TDtZEqwh2qedq+2U
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Aug 2026 19:57:01 +0200
From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= <marmarek@invisiblethingslab.com>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64

On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
> Make sure that save/restore continue to work.
> The check save and restore twice to check for corrupted status.
> Also a command is launched in the guest to make sure that the
> machine is not crashed but working.
>=20
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> ---
>  automation/scripts/console.exp           |  8 +++++
>  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++++--
>  2 files changed, 46 insertions(+), 2 deletions(-)
>=20
> diff --git a/automation/scripts/console.exp b/automation/scripts/console.=
exp
> index e27886bbef..ff58ed29b8 100755
> --- a/automation/scripts/console.exp
> +++ b/automation/scripts/console.exp
> @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
>      system "$env(WAKEUP_CMD)"
>  }
> =20
> +if {[info exists env(EXPECT_TEXTS)]} {
> +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
> +    foreach {exp snd} $lines {
> +        expect -re "$exp"
> +        send "$snd\n"
> +    }
> +}
> +
>  if {[info exists env(LOG_MSG)]} {
>      expect {
>          -notransfer -re "$env(PASSED)" {
> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/script=
s/qemu-alpine-x86_64.sh
> index 60f5cc49fc..409a601c34 100755
> --- a/automation/scripts/qemu-alpine-x86_64.sh
> +++ b/automation/scripts/qemu-alpine-x86_64.sh
> @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
> =20
>  " > etc/local.d/xen.start
>  chmod +x etc/local.d/xen.start
> +
> +# Script to test save and restore.
> +# It saves and restores domU domain twice to check if the domain was cor=
rupted
> +# during the first sequence.
> +# At the end open the console to check if the domain is working.
> +cat > root/save_restore_test << "EOF"
> +#!/bin/sh
> +set -ex
> +xl list | grep -q domU
> +rm -f save.dat
> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat /root/=
domU.cfg
> +xl restore /root/domU.cfg save.dat
> +xl list | grep -q domU
> +rm -f save.dat
> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat /root/=
domU.cfg
> +xl restore /root/domU.cfg save.dat
> +xl list | grep -q domU
> +rm -f save.dat
> +xl console "$(xl list | awk '$1=3D=3D"domU" { print $2 }')"
> +EOF
> +chmod +x root/save_restore_test
> +
>  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
>  cd ../..
> =20
> @@ -70,9 +92,23 @@ export TEST_CMD=3D"qemu-system-x86_64 \
>      -device virtio-net-pci,netdev=3Dn0 \
>      -netdev user,id=3Dn0,tftp=3Dbinaries,bootfile=3D/pxelinux.0"
> =20
> +# Sequence of expect/send strings:
> +# 1. wait domain start and close console;
> +# 2. wait login prompt and login as root
> +# 3. wait login and launch save/restore test;
> +# 4. wait restore from domain console and send a command.

Why doing this interactively over serial, instead of adding to
etc/local.d/xen.start and then printing test result at the end?

> +gs=3D$'\x1d'
> +export EXPECT_TEXTS=3D"BusyBox
> +$gs $gs
> +login:
> +root
> +login on
> +/root/save_restore_test
> +Restarting tasks
> +dmesg | grep suspending | tr o 0"
> +
>  export TEST_LOG=3D"smoke.serial"
>  export BOOT_MSG=3D"Latest ChangeSet: "
> -export LOG_MSG=3D"Domain-0"
> -export PASSED=3D"BusyBox"
> +export PASSED=3D"suspending xenst0re"
> =20
>  ./automation/scripts/console.exp |& sed 's/\r\+$//'
> --=20
> 2.43.0
>=20

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--TDtZEqwh2qedq+2U
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmpyJ+0ACgkQ24/THMrX
1yy04Qf/fuaUVKZY9577YfoGDDwlo7DXrIjWgmukGdGCrtup38i8D6Mu4m0ME0s3
vTO/fPgEzFhH1D3Jeusu8CUA4XBoC3jcQl+4Sq6h9/ESP0qPS95o/jbQVnLA5wt7
qOSgHiaHxBgtkv7w6qFNqEANHuUk0L+8ARi6Yqr2ILhEwyK9Qu7bo+rCpkwVdgmp
mFxyJknlRbmZVumbdEzKHk+C8GDrkZ4SvnQ50U5/xAhIkxu6PJ6uDg4Tv+oDB9tq
0ofwAFVf7NiNqkal8KfkdeiMUNGWD3eiB4kebncPueNSKVh/3GQjERb+XPIInCfF
yMH/UVS0dsAPyFbl2JQrO/JKkzOzkQ==
=qhiS
-----END PGP SIGNATURE-----

--TDtZEqwh2qedq+2U--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 18:00:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 18:00:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382541.1625890 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJRB-0000Mc-Mp; Tue, 04 Aug 2026 18:00:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382541.1625890; Tue, 04 Aug 2026 18:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrJRB-0000MV-Jf; Tue, 04 Aug 2026 18:00:25 +0000
Received: by outflank-mailman (input) for mailman id 1382541;
 Tue, 04 Aug 2026 18:00:23 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <val@invisiblethingslab.com>) id 1wrJR9-0000MP-LW
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:00:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrJR8-009Xhk-Un
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 20:00:22 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <val@invisiblethingslab.com>)
 id 6a7228a7-e002-0a2a0a5209dd-0a2a45089678-28
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:00:22 +0200
Received: from [103.168.172.144] (helo=fout-a1-smtp.messagingengine.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <val@invisiblethingslab.com>)
 id 6a7228b5-f659-0a2a45080019-67a8ac90a46b-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:00:22 +0200
Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 05140EC0112;
 Tue,  4 Aug 2026 14:00:21 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Tue, 04 Aug 2026 14:00:21 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 4 Aug 2026 14:00:19 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="CC:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="CC:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785866421; x=1785952821; bh=LDZ2h2Nlf2
	cEyscx9QKZZfWGeO9IVpeAJYTIBjmBdSk=; b=U8B0xEmo3WYf0NSC7WpdFA5egr
	MMRDKsStHQ/i6/6csGQrbcsvIg0k5nXR3j5yKOH94VMhnau75lSx5HwbEMUwY72V
	CtS/M4su/sX6DFTgwBRLVIGBIHOCm1pvydlRPW7SGM3oKGTeaVi4rYT7nWK1+Ig3
	G1WofNG8buKgAb640Qn4ALaTRuTAuVJ8REMHaSZDOQfaSH5FagD1PJcXLQ/nNA2V
	W6jMlgj74SA87tO3AGFZaDiCozR8frj/elKpm93gi21KfL5TmfdPPIZGOwHftqIc
	uv9e4pRugJeVh4GqCCyyg3BUoV3/4Dz3hUlwSw2UTRdq5kGBtTTbVYqqN0Pg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785866421; x=
	1785952821; bh=LDZ2h2Nlf2cEyscx9QKZZfWGeO9IVpeAJYTIBjmBdSk=; b=D
	UdPhCg0Phe1INlR8RIRVJO+zzXoJhvYpNR1QImC53/SS4hIKbujmXIsDM6cgN9d7
	R3mxMCqjOZwKvk1cRdpEMHR8ZqzbCd36Qwurv6zodpnqLnDd40oVabPhMCWnYFf+
	bdBqjEnvbLSr3X8T5z5W3Hd0/Rmybnpd8UvVPbeWoGk5LdAtUao7E9DoV9Q6uuM2
	dIPX1czvh9pE0iADXbYro5ouJg8od6lXh5uFOP9mHPsmfiqa36h5QpuibgcaXrq0
	TTIypNDASinvzqOpc+OAXdn9K3f9yJkzw44upRVpF+/cwDD8z0zd4LlO2S3tZFBK
	5tY4bpwIzsv/OLSikmcog==
X-ME-Sender: <xms:tChyajvKj3HGorfWZzr7j-uGdm2JK7-2bfjHd3Sacvc0F-NqepT2sA>
    <xme:tChyagcbBgNBLdTfPChPD8CJiD0woC_A3L7VW-brlSaAGywXhLrWEPGPh9cKvVZAQ
    1Yrk7GNLwIUoQmyRczDlfhJE6LG7d2l1c8Iqkp7MmSeBJpaF14>
X-ME-Received: <xmr:tChyao8cGUV_QuEsaP2Gn7cVWNpQVALTBtufgUu1KtMV1MGAh85uDEkWvXMYDdAOy5BiyX98>
X-ME-Proxy-Cause: dmFkZTEy9dbI7dVgmVyTaT5KMPh+I6ZGxOK3AUQTOQS2bIRY0xfX1eIAwzd/CZk9yFoRlO
    Cri2v3V/i1GamfTXF4Mv4XHmUAbgnxwc4BXyQwC+UslzHDz4plo3+nm5ZbJWSR77uA6e+x
    QyOrouw+nm3LsJ+gQ5m2R52NJQCw0vHielvFIhC0lcoQkpiZiVsdAClDG5dL9VTXt+eAQC
    A4lzSc/D45tR8Y5H4pkl73rK6mn6+0ks95z5yk8ssNzEj5Q9q1VvJ+Qj1rzNmhNgFMWZeA
    bKBgaopxeX7O0UrCTf+EADrwtUUR9rjHRxyOIxSMNJ3cL4NkVvRtnLa7Mq4BTBQW4oN2eB
    qqW38IwlcUBx5GF+YZWX1RbS5iQ/h8ZNKLGQb7/vrG07VpH2pTe2xy06c24FxiwGby2sV/
    xC9w0VW5qbbHSDDbo7bo7YIVWGgAhmKzjF9lD94oHrideo3ETE/xX5Ie9YjeOCcGGpYVHJ
    c11oUYpOE9nhCh/bt2kEIVcQaSq41dALy0f1JXwxTvChd2DIgCDYNRm0JwkjVzOTYfldG5
    g1cfdyZWsKiUhgzUM19WGn63AiyfwnckMcz6qx+ujUd2gdEEkV7avQoH+UU5k86T3ZcoNH
    ufBriIRzVnJoofkGLl0+IqtrjH2vv2Yo9OQj1IviIly5yokoSmGI26w8tZfw
X-ME-Proxy: <xmx:tChyajSD4YOfMYzHsLsqoGNJb-BFSdZAq68FlItuAFzHNcoB2kbFNA>
    <xmx:tChyahpq81WSJoXZIZi-geosS_HCbz6MYo_OVGlTDTwJqCbPpygI2g>
    <xmx:tChyaok-fLPCaNdApUfUWf2WZH_RdLmVzwB_Zn2P7BJ7Sop63_Bxww>
    <xmx:tChyaifm4QGvUobBK8dFUJsm_HNZBrbfKA_UEvsl6tQ01tmWM9FH-A>
    <xmx:tShyatOTSDjHa_-fhVEgcKTppK5qb4LXby9zT_TelmPP-VftnGLcRZ28>
Feedback-ID: i001e48d0:Fastmail
Date: Tue, 04 Aug 2026 15:00:13 -0300
From: Val Packett <val@invisiblethingslab.com>
To: Mark Brown <broonie@kernel.org>, Juergen Gross <jgross@suse.com>,
 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Xen Devel <xen-devel@lists.xenproject.org>
CC: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the xen-tip tree
User-Agent: Thunderbird for Android
In-Reply-To: <anITNOG1qicdE-TI@sirena.org.uk>
References: <anITNOG1qicdE-TI@sirena.org.uk>
Message-ID: <E5B27F21-9507-4801-8765-0A83FD8A316E@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-c1860d/1785866422-D514E87B-CA75770F/0/0
X-purgate-type: clean
X-purgate-size: 709



El 4 de agosto de 2026 1:28:36=E2=80=AFp=2E=C2=A0m=2E ART, Mark Brown <bro=
onie@kernel=2Eorg> escribi=C3=B3:
>Hi all,
>
>After merging the xen-tip tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>ERROR: modpost: "init_mm" [drivers/xen/xen-privcmd=2Eko] undefined!
>
>Caused by commit
>
>  64d26fb2ad1f2 (xen: privcmd: fix ioeventfd crash under PV domain)
>
>I have used the tree from next-20260803 instead=2E

Sorry for the trouble! Did not expect that to get applied so quickly=2E=2E=
 I had noticed recently in my own testing that that patch wasn't actually r=
eady to go in due to the symbol visibility issue, right=2E I'll work on res=
olving it=2E
~val


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 18:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 18:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382557.1625909 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKBe-0006Qi-61; Tue, 04 Aug 2026 18:48:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382557.1625909; Tue, 04 Aug 2026 18:48:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKBe-0006Qb-2n; Tue, 04 Aug 2026 18:48:26 +0000
Received: by outflank-mailman (input) for mailman id 1382557;
 Tue, 04 Aug 2026 18:48:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrKBd-0006QU-6k
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:48:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKBc-00282X-JZ
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 20:48:24 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7233db-2eae-0a2a0a5409dd-0a2a4503b71e-30
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:48:24 +0200
Received: from [209.85.128.179] (helo=mail-yw1-f179.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7233f7-fae8-0a2a45030019-d15580b3d0e9-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:48:24 +0200
Received: by mail-yw1-f179.google.com with SMTP id
 00721157ae682-81f36179d72so2831187b3.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 11:48:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1785869303; cv=none;
        d=google.com; s=arc-20260327;
        b=hrB4v5JwrlR1c80ACP0mDU4F2i+vYhy9zmseELS6dFRLXGu5e9NERT6alZDeMut/bq
         4/Pm2mVwADRaAwFfhoSFFiGkz1GbZQot0CtJWmiv168ZC4cHicvJRk8irO9tRfOdlhn4
         X65T8Xd04VNkOkkF/OOAa/MUM/uIivaLkdnSvZr7gmmuOU3IG2pgWQH6lJnf8ABBdlYj
         wRoyMX3VWccLySAVn5oInhYimQ/mP80ibWg11PO1yavWOpr0LluBvfiCUStX9poZLLo7
         UYYQiI8NiVWTrDy7inh4ObKhMQtx5lkt/VhWD7eKC00gjohEbyYnLeiOav71cmhLBUIj
         4Bgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=7hHb7A/iv/3NbWaHGGYKFA8iWxf7Etm7iPDj2vr104Y=;
        fh=RLhUWlRjq6yfpKY+h1JZzBpOTuG/g/EB3etsFhEdDDk=;
        b=IEF0C5x9/Zz10gdP3AGbNue2dEXxOvNVI0CWxFy95hwG0xhgfyCku3fN0lwg0GxN9v
         QHgPcy827tpvkPC9mSTZnV7iYCFO1tjm07FSfZJlPzivdg9oHbuTqInMzTRzr7V/JbGG
         DqCboeKso0bYnxh9z7RRzu2kkye4eCA1iekK+kxuTDjofgcM+hAh5obewWCVtPmD4Rnb
         4u8cBMQdIsDA5pFH0GRjYtYBQzgMqFvkof4grsXqWlkPaq7wLUlq9ODShUiRxuhuSjeg
         23SF/epheUqTV7qqsOXbOAndN5HtN3pD0V/Kh1LgN1pztD/dAJ42cCJZoqKdUiSTPItT
         0uGg==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785869303; x=1786474103; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=7hHb7A/iv/3NbWaHGGYKFA8iWxf7Etm7iPDj2vr104Y=;
        b=kunGUCAKyZS+QhtUN9mIrCYPDBvTVS6nmHFOPrp/pYqWJ6+EXys5Sn5JIiTmFA1+wo
         DVJfk0sFswyd+XSneXSrm+HFNgYo1r7RJnVN8hw34VTRqO4XDP1iBdY5snI9ZxGHMKy6
         6PV5QDTAdIr61JRZYem/Ym0dCYEfHxeRaoIlCD1gZ6OGegxBVRSqC7GQw0i0IvR2qfKn
         uE0ZLhaMm5a4QdXBKU5xHH/XtvyfJC0EG678iZBqLoCALhXXvIko533wfif8T+vrRJNa
         /KvQHYAtdPvR+zGDDhF2N4S/iLtjmQ2FZPZnaHmfkkVuaZHYAfg95u+yee/TwcbUZxRo
         wHYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785869303; x=1786474103;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7hHb7A/iv/3NbWaHGGYKFA8iWxf7Etm7iPDj2vr104Y=;
        b=gaStgkDCYseoJJk9i7Ofh+ASriWFVI+b2xzFSnmP7Zab+NNCYwSRucrbS3fpXTUZCo
         eX4AxRBCqsi/P602o8eBPmwtuBOZbpcr8sG8GQLbG03MH+EbNyjDzDM+VKu9xv4/7dVe
         f0hkLirsDyADC4RYvHSwDNVjkaZykmA3+/Zo0bwenIcQsRByP+ShyE1Rdj70D+bH3OTZ
         ltY8gx/+JbJseC7CcASeuv0OZomqGO7YUhHuPHPzInYxo2WLs6xJUXEEYLWGVcNXtS8z
         AoJBMBYJsMkPxLauHSTRCeeblQxE0n+itxykp2zHYfkdlyFCpj8kBrA138/P27LqT8EY
         n4TA==
X-Gm-Message-State: AOJu0Yx6J6xmWy4FwyYn3PTOMj+JRk55/T3NGgdYCRJDCmyIn4SaWPtv
	j/XyYqtJltACQgGqldPGfXxlDM8rP2YtZUyLf2C2PC3uQKmX8lEpzvfN0b6ShO16IgAc/lwA1+m
	/MuujbwvfjNd5+idwSqzkfBqRtZa/EOo=
X-Gm-Gg: AR+sD10JhUZH2/CJRz1MgZHrxxaY3NIEwYxONXx168cbW7wNkcD92YYgUF56Ts+iztI
	upMgl/Dt3QalhYHoCacaZdbtQG2GAjyMs78WkFEPgrw19etC3ncyu3ow91gl0xq08PoCZXv8mGk
	cC1eW/3T2l/IZEL/mjFkniNpKWUMvaedAC9Oko6R6dEavyKQ5QhpIrmxSXK6OsHNhdwpoUze1f0
	ChWZz/SnC+H1yxdfmekmrPqm/Hg23/pNXy/aDdt8mZea0sV6aocY7HHaCozwaxX+7X9jaqNVG4e
	PiQpO8ssxpHApFt6MI+xQJ7qeOt7TzxHqy59aMnUbJYQ+w37TOsBpY5xia9ZeGqQ673QBJ+q+C7
	V
X-Received: by 2002:a05:690c:c4e9:b0:81e:9b09:7263 with SMTP id
 00721157ae682-820222bbbf6mr4493457b3.10.1785869302838; Tue, 04 Aug 2026
 11:48:22 -0700 (PDT)
MIME-Version: 1.0
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-3-frediano.ziglio@citrix.com> <anIn7VAt2oQJ90Js@mail-itl>
In-Reply-To: <anIn7VAt2oQJ90Js@mail-itl>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 4 Aug 2026 19:48:10 +0100
X-Gm-Features: AUfX_mxZCKZPTK0G0XIsRbFiVIkMddiIg6XauhFcmZwsjjLI9vmE9jxSgwKs0lI
Message-ID: <CAHt6W4eCdqp2NDzjHyQ9vdezJkjVyxTwJH7HuReVxVSihox0Rw@mail.gmail.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of qemu-alpine-x86_64
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: xen-devel@lists.xenproject.org, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Doug Goldstein <cardoe@cardoe.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-33051d/1785869304-6FCC34E9-9D2B3B38/0/0
X-purgate-type: clean
X-purgate-size: 4071

On Tue, 4 Aug 2026 at 18:57, Marek Marczykowski-G=C3=B3recki
<marmarek@invisiblethingslab.com> wrote:
>
> On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
> > Make sure that save/restore continue to work.
> > The check save and restore twice to check for corrupted status.
> > Also a command is launched in the guest to make sure that the
> > machine is not crashed but working.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> > ---
> >  automation/scripts/console.exp           |  8 +++++
> >  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++++--
> >  2 files changed, 46 insertions(+), 2 deletions(-)
> >
> > diff --git a/automation/scripts/console.exp b/automation/scripts/consol=
e.exp
> > index e27886bbef..ff58ed29b8 100755
> > --- a/automation/scripts/console.exp
> > +++ b/automation/scripts/console.exp
> > @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
> >      system "$env(WAKEUP_CMD)"
> >  }
> >
> > +if {[info exists env(EXPECT_TEXTS)]} {
> > +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
> > +    foreach {exp snd} $lines {
> > +        expect -re "$exp"
> > +        send "$snd\n"
> > +    }
> > +}
> > +
> >  if {[info exists env(LOG_MSG)]} {
> >      expect {
> >          -notransfer -re "$env(PASSED)" {
> > diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scri=
pts/qemu-alpine-x86_64.sh
> > index 60f5cc49fc..409a601c34 100755
> > --- a/automation/scripts/qemu-alpine-x86_64.sh
> > +++ b/automation/scripts/qemu-alpine-x86_64.sh
> > @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
> >
> >  " > etc/local.d/xen.start
> >  chmod +x etc/local.d/xen.start
> > +
> > +# Script to test save and restore.
> > +# It saves and restores domU domain twice to check if the domain was c=
orrupted
> > +# during the first sequence.
> > +# At the end open the console to check if the domain is working.
> > +cat > root/save_restore_test << "EOF"
> > +#!/bin/sh
> > +set -ex
> > +xl list | grep -q domU
> > +rm -f save.dat
> > +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat /roo=
t/domU.cfg
> > +xl restore /root/domU.cfg save.dat
> > +xl list | grep -q domU
> > +rm -f save.dat
> > +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat /roo=
t/domU.cfg
> > +xl restore /root/domU.cfg save.dat
> > +xl list | grep -q domU
> > +rm -f save.dat
> > +xl console "$(xl list | awk '$1=3D=3D"domU" { print $2 }')"
> > +EOF
> > +chmod +x root/save_restore_test
> > +
> >  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
> >  cd ../..
> >
> > @@ -70,9 +92,23 @@ export TEST_CMD=3D"qemu-system-x86_64 \
> >      -device virtio-net-pci,netdev=3Dn0 \
> >      -netdev user,id=3Dn0,tftp=3Dbinaries,bootfile=3D/pxelinux.0"
> >
> > +# Sequence of expect/send strings:
> > +# 1. wait domain start and close console;
> > +# 2. wait login prompt and login as root
> > +# 3. wait login and launch save/restore test;
> > +# 4. wait restore from domain console and send a command.
>
> Why doing this interactively over serial, instead of adding to
> etc/local.d/xen.start and then printing test result at the end?
>

I'm using expect to interact with the console. expect is not available
inside the alpine root filesystem.
Some failure I had during migration is that the VM crashed. In the
script I interact with the console to check that the VM is still able
to run commands.

> > +gs=3D$'\x1d'
> > +export EXPECT_TEXTS=3D"BusyBox
> > +$gs $gs
> > +login:
> > +root
> > +login on
> > +/root/save_restore_test
> > +Restarting tasks
> > +dmesg | grep suspending | tr o 0"
> > +
> >  export TEST_LOG=3D"smoke.serial"
> >  export BOOT_MSG=3D"Latest ChangeSet: "
> > -export LOG_MSG=3D"Domain-0"
> > -export PASSED=3D"BusyBox"
> > +export PASSED=3D"suspending xenst0re"
> >
> >  ./automation/scripts/console.exp |& sed 's/\r\+$//'
> > --
> > 2.43.0
> >
>
> --
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 18:55:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 18:55:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382571.1625919 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKIa-00085s-0B; Tue, 04 Aug 2026 18:55:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382571.1625919; Tue, 04 Aug 2026 18:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKIZ-00085l-Tb; Tue, 04 Aug 2026 18:55:35 +0000
Received: by outflank-mailman (input) for mailman id 1382571;
 Tue, 04 Aug 2026 18:55:35 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrKIY-00085f-NK
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:55:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKIX-007HgV-KH
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 20:55:33 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7235a4-bab6-0a2a0a5309dd-0a2a4503eab0-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:55:33 +0200
Received: from [40.107.208.45]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7235a3-fae8-0a2a45030019-286bd02d5678-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:55:33 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BY1PR03MB7995.namprd03.prod.outlook.com (2603:10b6:a03:5b5::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Tue, 4 Aug
 2026 18:55:27 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Tue, 4 Aug 2026
 18:55:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w3tnGWvshcEid+ytbQ85X9gaHqFCrebfv4y3opcmBCyI8jgO6b2jYx5QK6nEC89P0n60+nMRKgHDT12coPNp/ggexLjdLJgyJnNaswjmjebkDoixJSbXrFyC0QXePIxVKvP0rsSgk6Fpdtjj0jXYxRTnlaZEKelR2CByCFMfTkbrP/wD+5f8OGQAtA/6w0OtoYBpBNiv2vjM/dhSdFSzKVjuHpJ+xPiuZzICpS8OHPRgCIrC6gN25fqfx3H/ZHCb49GAoNjNsZLJbLRNmHq3sJEPM7Ipy8st/sGGVCnr52uOzPAgn4FM6wRNwyUCZQee9UvSZtfUxu2mlFowKj1Byw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LHMDwvv46rBKThaqSqCUdebu9WeFZbWgaZ2tLVoLzwA=;
 b=Aq5a7+PewbMth6871HBPSc4V0HyrWU5AdPTQaQZUZQ2UWx0wINRIuXSZq8CDCR5PnOPjKJQ1EPWazNsNz3Yb4hoFtKau1quTzGQfJWRdAA7a46xqVWGiXhRYqmgpDpo1lk+/hheHdgWaPAe2hURykMK+6JV7dP/WX1Pqu4B55j//x/hktWDqR1Cs2zctKWVb10NeJZAu7LDaNmnAcsvT+HBBKW8SBUfrR8I9euOe8PFwPSDKB2vBNTrXTbssk6nIBjK3j3kTrR5pYsIDqqZCWbDxOMBIapSoEOIlOUZ8NoTq8S75US5YhkOneuSwMuBKJaflwNHUM+tbbaYFaJk4lQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LHMDwvv46rBKThaqSqCUdebu9WeFZbWgaZ2tLVoLzwA=;
 b=VbqoHKec+aRXDPyPtUhyVpFhdrkq/6Y1PKITc7G+Qw2HhsnKJGKtLwbCe4eSqjsoVX9rBMINYWPg2Mg/aWipch9ffEOzg/xhRXZGL9PMBidcsrI29VkkbWCtOoO8AyDWTW0jrdPDoSQcWAK8OXDHXJE4M8gmb2Jzi3pXnMkv0Ys=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <9dc1d91c-52e2-4cd9-a234-6d6ca6ecceb8@citrix.com>
Date: Tue, 4 Aug 2026 19:55:24 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, Frediano Ziglio
 <frediano.ziglio@citrix.com>, Doug Goldstein <cardoe@cardoe.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64
To: Frediano Ziglio <freddy77@gmail.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-3-frediano.ziglio@citrix.com>
 <anIn7VAt2oQJ90Js@mail-itl>
 <CAHt6W4eCdqp2NDzjHyQ9vdezJkjVyxTwJH7HuReVxVSihox0Rw@mail.gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <CAHt6W4eCdqp2NDzjHyQ9vdezJkjVyxTwJH7HuReVxVSihox0Rw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0080.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:190::13) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY1PR03MB7995:EE_
X-MS-Office365-Filtering-Correlation-Id: 6e90e035-2a8f-4b54-96b2-08def259f28d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	2d3jkuSSTnxtuym8yOyTGKhGiwR8/uP8JwQ2QQcDJT9v6zWoamsZPrY7yaPsS/snij9W2pvGtjQbL9qeSoLCjnO3yFCDx1nVmgg7wv3EfnmPqKye4eHd8+QwGz7YEVCKOpee/06WJ4adcetwnyAyvmeNO9h53gmDhVNb6R20bHk3yTJ8ZkmMIO+2YtAqyZ8VDtTrdGdDA8bbgjWpp6efkGpXposXXb+QvbVxk5b8YzrcoaJgVxEI2egwcKEInyt+2yDkarWp79xsBTwWrDOtnNcGEitbNCsC0drMnVtxhHrFcFzPT9eVyFWjwav3hoMjxGPQ9LxnTimCUWh/VGSwkaILAmm4G5+uduFie1HaRO/WxGCpnbHx21pDpTcLhxt0NzJdXzLignE3ClXzuJRXrbIkk50J8f4jwqhCxr7dVIbhm8V/nxxJX32HMQFyDMDDOKoN1OuoQHwA8eUY462gCuyat2bxhgxbvUTSQ3mrW33wF3rcwH41eD9r4F8urN2eGQdNiUUwvl2pI+HC1EpaNtG6v0PBqDzWTZANdhnj3k65+ME/dIvLu6Pk0lDrqvbFA9OR/zxdZjiL9y580kMthRlk1updcDX0gRZXmgMoXAp27WQXOa1X2J/q4zuH1yNxbqV0/gOSVo5hwulSJh8D1C/U9xAcJWkugGhw9Fz+0IY=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?cWxuR0hZQk1UZHBHem5odXVEWEdpajA4a3gxUll1WFo0Mzk5V1d5bXl0bEZE?=
 =?utf-8?B?SHdQMWlPakE5aExGeDlkTjRKcDdaaHkzRXpGNGJXdXZFRHN3SWpHb2REaGtS?=
 =?utf-8?B?MWQyV1ljajBmR2hCQkxGeTQwK29VU1hyZGVaSnVWMm9QWXpKQ1c2MmxVMXJp?=
 =?utf-8?B?bTkzaVlNYVUxcXlnak42T1B5YXEvbU9yV1dkcmVLeVo0NCtMcFRhWVlRN0xV?=
 =?utf-8?B?c3MrRWNZWG0wRWFvTkJ1U0FGaVJ6UFozVjZWdUFmdE1NdkNoU2hrSkxramdL?=
 =?utf-8?B?RzRFUHNyQWxYUTlqRVkwMUdRZ0taa21PYVdCS0U5VHB6ZnlINkNSd0RHNUVR?=
 =?utf-8?B?NW5KVDVzVStBeTR6TWtvWFgrTGZwVGtvTUZ3NnFqYVA2Rmxqdk5wMWNTTndF?=
 =?utf-8?B?UzFxeEk5TGgxNE5hTkxUcEtZU1ZNT1J3NmhQcTNSbWlQYUtrK0VhSzhrd1BB?=
 =?utf-8?B?RnhCMXJ3eEJCakV4MkZxeVVrWCswWUhuOUx2SWZObFFLcGpZQ29sOWZ2aEho?=
 =?utf-8?B?WlMvcGcxTTcyUXNVOHV6ZDJGYzV3ZXRmTlZBc1R3a0N3Z0JYbDdGck9tZTg5?=
 =?utf-8?B?RzZ4aFFTdGFXY1I0K3FWbEVzTzk1S2tWVTlyd3Mzd0w5SWNOV1liYmE2akFL?=
 =?utf-8?B?bk1ZU2pjVW9nd1lxbFFIMEVjRC9uQXJTQUc0V1lnS1BDNXkvdWt1NGMyZVNI?=
 =?utf-8?B?NFgwWFlIVXpxSVVOaW5LTE55WG51NXRuSm54Yms5Y2dkUVJZSUxWNzR0SzMy?=
 =?utf-8?B?bW8zeUsyQ3EyTktwZFJOeEUwU1AxYmVNY0pkU0lkTlFaczZJODU5TDVsSzRs?=
 =?utf-8?B?VTl2OHpaaVBMQ1p2VzdBR2hjM2dNMlp4OGtQaGtRR0Fob2J2ZitQbVU2M0VW?=
 =?utf-8?B?VWVCbnVMM3RjdEQzaWZOTm10KytHVVBudEt2dldKTXJqajVWYUR4MEwxWjQ4?=
 =?utf-8?B?aFp6NEE0c0FRMXA5dm02M01PTHBhSTRqTzVzeGd2M3VIMjEyUUE0b2hkdEE2?=
 =?utf-8?B?UDVOU2s5NXM0dXpjZ2txZmRLWWF0UDNBWXV1L1NTTjdHQUw4OW9oL3E0bzN2?=
 =?utf-8?B?TDM5UFNrZkpqY2RZUjArSktHZnI4MTFjVUdLd1BKRU5kdk15QTgxM0JaVmVw?=
 =?utf-8?B?NmYxRmVkZWxGbkQvSWdPNnh1cTRFYUxrU0taQUR1UjRPVVdCK0pTMy9IZ0gv?=
 =?utf-8?B?c1NOLzk0YWpSUnVQdHViOHFWM2IzNThkWE1CQVFoY3hyckF0bXBQN3dwNXVi?=
 =?utf-8?B?UnBWUXlLSzVDMCszRmpqV1lRMHVSOU1jZENTSmRDenB4K3c1MnRLM1NNV2x6?=
 =?utf-8?B?WjRSTldMblRsT2hoNzFYcEhkZHZ4UmRKRS85aC9GRVk2bUdmQ0RtTjF1aHNi?=
 =?utf-8?B?TEFkSW1FcCtTL0UxbW5iOW1GWm5nTGRYMERFVHJSNUhzWUJZS1lnY1N0STc2?=
 =?utf-8?B?S1ZXK1NIRThNdHEySGpwdk40TFJGVHYrMXh4YjVKUTRteHV3ZVBUclZQMCtk?=
 =?utf-8?B?UjJoUiszbllBK0dDdGJGaFZWNmNyREp6Y2MrRExTelplZVJWcHpBRVRnTEFK?=
 =?utf-8?B?L1BDWHlBOFlYUVEvRXhmVWhtNHhmYlIxcWoveUxVbXJLMi9aQ2I5K2ozaVRZ?=
 =?utf-8?B?WDluck4yQTlTbUNlRFZ6ZEVxZWtERS9JTUVWQ3lTZ1FxMW9NdDJRZ2gyM21a?=
 =?utf-8?B?T0ozVDc5Vkw4UFJOb3NiWWxHM29Db0dPSVlxUEtSNkE4Tm1pT2pVb3NtcUFz?=
 =?utf-8?B?QzE5em1GVFphOHBoUENyT1RwVlg2bndRVUt0dGdBd2JCUmUvY24rQmpoQkNT?=
 =?utf-8?B?K3c3K3VhUzN1VW9wUkZMb2tNYlVyTUZuR09pNUJINUhRU3RyRGI2Wjg4alI5?=
 =?utf-8?B?dzhXTnh4YUFhU2hndDRNTFpjVDVUbUI2Y1ZzZEVRcVZROXkybStHQUMrMjdE?=
 =?utf-8?B?eUlrOTNoR3FDaXZXeVpCNE1ZTStLU2puNGU1c2FSTzRPYURVOXFoMmpjSTE1?=
 =?utf-8?B?SzFmczBQZi9tQjU5UVAvdGdGdnpGNXZtd2xIN1NlVit3SmpPTTRidW9EcFJn?=
 =?utf-8?B?RmdjR1lkcFJxRU9NV2k0MHBFUWxVUTgzd2Vza3NvU3VjMmJON3pzaDNMaS8x?=
 =?utf-8?B?dUcwZ0RkMTFxSUkrcFVyUDBFaGhIQmlZaXlDM2Y4NXRFWFQ1aXJ6WklscGhZ?=
 =?utf-8?B?WVBPYkhpc0ZWVlhWcFg3TnRIbmZKN292cDN3TGxWeDRISnpTa3lySGQ4cFBX?=
 =?utf-8?B?d0VzNGdqWW9aY3JZR2RkcXl2YnN0dGwrV1JZR2RvTFZKTG1TQWVBMU5VTjla?=
 =?utf-8?B?T01aaU5UelRvT0hlVmlaK2dISHZPTFRQMVN5VjVwUU9MeGZaVDd2QT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e90e035-2a8f-4b54-96b2-08def259f28d
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 18:55:26.9931
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pE1s3349156D1QcXMj4OXAQiych3b69FZkindCdiL5S+3EC6jNIIK/DQOAgRtJbtgkG7Yy9VC1sB3Av+/MJ54DzsV1k4xOq3G2cFGe6v2cQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB7995
X-purgate-ID: tlsNG-33051d/1785869733-76CF84E9-BF4B4530/0/0
X-purgate-type: clean
X-purgate-size: 3987

On 04/08/2026 7:48 pm, Frediano Ziglio wrote:
> On Tue, 4 Aug 2026 at 18:57, Marek Marczykowski-Górecki
> <marmarek@invisiblethingslab.com> wrote:
>> On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
>>> Make sure that save/restore continue to work.
>>> The check save and restore twice to check for corrupted status.
>>> Also a command is launched in the guest to make sure that the
>>> machine is not crashed but working.
>>>
>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>>> ---
>>>  automation/scripts/console.exp           |  8 +++++
>>>  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++++--
>>>  2 files changed, 46 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/automation/scripts/console.exp b/automation/scripts/console.exp
>>> index e27886bbef..ff58ed29b8 100755
>>> --- a/automation/scripts/console.exp
>>> +++ b/automation/scripts/console.exp
>>> @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
>>>      system "$env(WAKEUP_CMD)"
>>>  }
>>>
>>> +if {[info exists env(EXPECT_TEXTS)]} {
>>> +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
>>> +    foreach {exp snd} $lines {
>>> +        expect -re "$exp"
>>> +        send "$snd\n"
>>> +    }
>>> +}
>>> +
>>>  if {[info exists env(LOG_MSG)]} {
>>>      expect {
>>>          -notransfer -re "$env(PASSED)" {
>>> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
>>> index 60f5cc49fc..409a601c34 100755
>>> --- a/automation/scripts/qemu-alpine-x86_64.sh
>>> +++ b/automation/scripts/qemu-alpine-x86_64.sh
>>> @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
>>>
>>>  " > etc/local.d/xen.start
>>>  chmod +x etc/local.d/xen.start
>>> +
>>> +# Script to test save and restore.
>>> +# It saves and restores domU domain twice to check if the domain was corrupted
>>> +# during the first sequence.
>>> +# At the end open the console to check if the domain is working.
>>> +cat > root/save_restore_test << "EOF"
>>> +#!/bin/sh
>>> +set -ex
>>> +xl list | grep -q domU
>>> +rm -f save.dat
>>> +xl save "$(xl list | awk '$1=="domU" { print $2 }')" save.dat /root/domU.cfg
>>> +xl restore /root/domU.cfg save.dat
>>> +xl list | grep -q domU
>>> +rm -f save.dat
>>> +xl save "$(xl list | awk '$1=="domU" { print $2 }')" save.dat /root/domU.cfg
>>> +xl restore /root/domU.cfg save.dat
>>> +xl list | grep -q domU
>>> +rm -f save.dat
>>> +xl console "$(xl list | awk '$1=="domU" { print $2 }')"
>>> +EOF
>>> +chmod +x root/save_restore_test
>>> +
>>>  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
>>>  cd ../..
>>>
>>> @@ -70,9 +92,23 @@ export TEST_CMD="qemu-system-x86_64 \
>>>      -device virtio-net-pci,netdev=n0 \
>>>      -netdev user,id=n0,tftp=binaries,bootfile=/pxelinux.0"
>>>
>>> +# Sequence of expect/send strings:
>>> +# 1. wait domain start and close console;
>>> +# 2. wait login prompt and login as root
>>> +# 3. wait login and launch save/restore test;
>>> +# 4. wait restore from domain console and send a command.
>> Why doing this interactively over serial, instead of adding to
>> etc/local.d/xen.start and then printing test result at the end?
>>
> I'm using expect to interact with the console. expect is not available
> inside the alpine root filesystem.
> Some failure I had during migration is that the VM crashed. In the
> script I interact with the console to check that the VM is still able
> to run commands.

We can add `expect` to the dom0 root filesystem if we find a need for
it, and it looks like this might be a good enough reason.  You want a
patch to https://gitlab.com/xen-project/hardware/test-artifacts
images/alpine/*-x86_64-base.dockerfile to get it included.

But, for migration testing, this really wants to run on the real
hardware.  Besides the main memory image, there's variations in register
state and validity which will vary between hardware.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 18:57:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 18:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382578.1625927 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKJw-0000DG-A3; Tue, 04 Aug 2026 18:57:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382578.1625927; Tue, 04 Aug 2026 18:57:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKJw-0000D9-74; Tue, 04 Aug 2026 18:57:00 +0000
Received: by outflank-mailman (input) for mailman id 1382578;
 Tue, 04 Aug 2026 18:56:58 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrKJu-0000D1-Fy
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 18:56:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKJt-007Hpb-TJ
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 20:56:57 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7235f7-bab6-0a2a0a5309dd-0a2a4503c0de-2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:56:57 +0200
Received: from [52.101.201.32]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7235f8-fae8-0a2a45030019-3465c920e498-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 20:56:57 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SJ0PR03MB5744.namprd03.prod.outlook.com (2603:10b6:a03:2df::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Tue, 4 Aug
 2026 18:56:54 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Tue, 4 Aug 2026
 18:56:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dZ4zYWrsN8oWBYgoAXI/nKbyFSxWnRUWjohv4CK7Azh4161lnCyI/GgQzhAnH6ImBbcDQyYBjAXPOAYW0Zkgkt8VH0odFDedL2+nMIZylShVf8h+eZsWsIDRSnmjtr9EGSxGiJfCBcNVKZC0dc8KzoUz4fNturTK/koK7/68DRlcUFQATJYqy1gICJmpuIcEG7r0emojqxkaGTViLu+s72Pa+Rq2VKeJ4fEX6d1ow7US/ih1Qpzm1tqV3o3HkDL9iPMR+SSJDXtUlubxvQThJ0g+lVI5NhNMIoJm0wLqHMuP8/1FsSWavJgPHcgJguA3+Y7DGhjvh4YWa9uN+MZwbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1w149KaIoZYVexb5ZFISq+2+xbDLHCF6EYoXbL5OQfo=;
 b=hgNFCYDgDm87wr2soKnPoiGb7mje4DZhBbnWqUhFL1+utAyGU8Lt0aUys2x9/gJZbIJfbr87aQvKp5MIo3LQ/ZPA9XZwlj07M5l3EbV4OKtUsUejt9XH47bYuZPFuBqOPkzgC1hzBTjoTdPNPV3Z39h19mDMsuuRxrSmwVWGAQjGJhGDTl9R8oCJGrozNZ2zp3DRXzIpJmcUMzVK83HJiC1HD9N5sxZan+TF/3Gn0rc6+/nyJZHFXzEfpoN9sdwCOiXwNcAYnGOafW2vRe2GgeDgr5zoceJlLFMYreEI5FBc51drjTPtISjGEMCnDwKWU95vUquvSF1xVUPTxrGkdQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1w149KaIoZYVexb5ZFISq+2+xbDLHCF6EYoXbL5OQfo=;
 b=WPFyTRVB2q89x6G/gG2rRdUMnuizp4PFgw8sZs/VU+8h5iq4PsXK7OB6YTIqprZ1ypAtjBbzBXQUrzd2w9rSKgWsExjZRZMNpD7DGd5dr/tlUJK57O/KYOzK5BN32Gv9ttAqh8Ztvi2SlTXEowMv4gtx4YbgoxH8d0l8KYL3sPE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <1e1a1c4d-5ffc-44b1-b26c-244c9af1f250@citrix.com>
Date: Tue, 4 Aug 2026 19:56:50 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 1/5] x86/emul: Introduce x86_decode_lite()
To: Jan Beulich <jbeulich@suse.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-2-andrew.cooper3@citrix.com>
 <01b27228-fdc0-4546-aa23-2bcdafb22727@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <01b27228-fdc0-4546-aa23-2bcdafb22727@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0076.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:190::9) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5744:EE_
X-MS-Office365-Filtering-Correlation-Id: f3188295-7335-4f44-c169-08def25a267a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|11063799006|10067099003|4143699003|56012099006|3023799007|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	0Wx8Yrry1XeYdH6+UBKnATy523sKY/cOcQOSWSSiuAI+YZKqGmtZUZiKAWGGOxusV6+YFD8k5orfl1ZCeR5LycwXOu8KszZgFyvuSd3+T6XzqetVAIcRn9M+vROELfAdBidhFxqf0GnApojKmvVsuDhL4eElLooH7wr+uDwiwgmkCNkXefEgKhcuVS3nI6a2VqoEM3MbxFPR39/C1n5UsmZMTKo+BPzTZSTAjxj4HviPwK4D/GYGMllxb9FyPVqhcUbXCqsfbXwZrxRBqZ/TBAdGRoTf4JUB+aBSWQd18lsHjJx27Lb6CqqbT8Pd/4gknNVLfaBVXekR/vcjffresJ3aY7P+SxK/eMkL4dW/AZwBfi0BnuQn1VQBOgoEiH7AnCG/8/B70hpJAsIrSxmZefuOtAwsqciIi0JsTZjKyOcpiALnTZTsGtbQt+PXwJUVehRei6KCtukJ7LOyJbJjD1KODGiqm5FYGJR9Vs7mtC4sMaABhYD5t0gI9sUkzilkWUMI2isJBEaoSehb6utloTxCyFbv/p75T3Lq4ZPzucMoNt2qXCzDmfqxleH8auEHs5tkTFs7t0H1Y58UqPRjiOfat/dic+UEQp5J7mBeVL0Swb/25PSJHx6McCKeJa8FRFRB9ikjVpNUDEouoEz+o4PAKOiEGskfMoFN6C9PwDs=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(11063799006)(10067099003)(4143699003)(56012099006)(3023799007)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?K3o1REk1OU9wS1ZUZ2FmeVgvU3lnZGExT1NVR2oybnArR1RlcVIwd2lkdzhL?=
 =?utf-8?B?OFRVWUNwSGh4MnBKL2U0UjB0UkZ6djEyM0NYZmlXTEVqTUEySjNhRWNKUEdi?=
 =?utf-8?B?YmVFN2hJd0pmT0lkMW5aUE9MbkN5eTl0Zk5JcHdTM2JGQnVXaXYzK2ZRcm83?=
 =?utf-8?B?cHY2N29jdU1SbE1tNDhwV0tiUU1NNHFlaDZtS3BnQ2xWRm1mT2lVTnFRbTJj?=
 =?utf-8?B?ODFCL2lCZWhBTmZQaFp0TjdMWkRaMjczWlVJOUordzMwa3JwYzN0R0s0dnZZ?=
 =?utf-8?B?YXBQOU52ZGVXRTRwaGFIVjhQSk9PTkc5aHdXaGJGR2NTSGFTY2tFT1hsTFkw?=
 =?utf-8?B?SEtvcGFRWFhKcmF5ai80RmtzaW9VenpBbGRiYXZWTnQ0U0xYK092anNvWmh0?=
 =?utf-8?B?bUNFeUYxMXBaQ3ZWS2VlUmNMRHpIbDUvaUdiMVVYeE9WWS9QYld6ZjQrMTU2?=
 =?utf-8?B?dCtJQnI2ZUFxVWloN2tlSitNMGU4SWFlYzhva0lzZTZuRy91MC9RK0RiZjlj?=
 =?utf-8?B?ZzBHbUM0UEgzNURHQ21MaWNkWVdXaHlqSkJ6KzRJQVBTdUFtNGkyZTBRK01L?=
 =?utf-8?B?NmtPTEhxdzYwYXJGTUxmV2QxblR6cG9Wa0xLbmNDWGxJM1RLeFFMcyswNm5W?=
 =?utf-8?B?MzUxLy9GVkVKMk40eDJQc1hNRTlENVBuOFFnb2ltSW9EWVpLbmxaUzFXWElw?=
 =?utf-8?B?TDdmR0hGM0Y4V0d6RHY5WCt1eXlFMzJZRzVqck5WSzlzM3p1Vm8xYVlnSm1y?=
 =?utf-8?B?bXZwZzFRbmE3cUxQeEVuaWNxYTF4VWcwVVVaY3JVcExuQkYwT212NVNjcGJH?=
 =?utf-8?B?cmFGS3Zwc0NDNzUrUzlESWVudWxXTnhYam1QT083ODVZeVJTaEsxNHhIQUVy?=
 =?utf-8?B?aElUT0NvSk9FYVorMVNVeGR3dFF6L2xpbHdydmdCL1krQml6NHV3d0JtTGpn?=
 =?utf-8?B?aE1uaUxlTVJ6TGs3bFRrelZIYmhqaDZPS3Bsd2ZjVWdaOGl5Q2xFQ3FZWE9B?=
 =?utf-8?B?Q0FPY0h0ZWEraFhtck9YanRJVkpWN21pQjF1S1NpZHpwbnNOTG4rLzcxeW9u?=
 =?utf-8?B?dUhMQUNvdG1oenBBM2o2NElPQmRBa2FtdFlBcXJhSE9yWGFJdzloNS9yRGZ1?=
 =?utf-8?B?b1VCdnNtMko1SzZodkJzYTJEUjZocC9RNDRpRzBWUDJVMStkRCtVSDNKd0tO?=
 =?utf-8?B?Ly9QYjBLTU4xaXFEeWN3dWhTR1gva21YUlVBNzkrb3l4THU2aUJnUTVkOTNk?=
 =?utf-8?B?ZWN3VVhYQ2E0TXc5NlN5em9ubXBXWWh2OEJDWGd0L0VQcmF2cGF1dVlTZW0x?=
 =?utf-8?B?WTRaQVhKd3ZUMTZna2QweUJOekdETmdYL0lDTDBYQXRXeXBjZTd2NWY0WGFR?=
 =?utf-8?B?WGxra2Y2eDQ1VE5WT3lFbmlSK0pZWnRSaW5FTEN0TEtQTnJlSG9aV1dmMW5o?=
 =?utf-8?B?a05BaU1LNUFncnNUbjdSRGplYXpyK2dWVWJDbFY0N0Zxb2MvOC9lcDhYYmo5?=
 =?utf-8?B?eElyVkFpK0gvRENndFhEQXVxZGt5VDRZOXZKUFFFQjh4eFRMamNsdHo5VVpG?=
 =?utf-8?B?V0I5MEIraW52ZjlZVzdjM1FxR2VyZEFHTlBMeHRUVlZaZi94Vk9KR2xxeTVX?=
 =?utf-8?B?eGpjY1pRTVpxcHN3YVE0YlNLVzFXaTMxY2xqUjRFUWhGaW5SWWIwOWhwL3RP?=
 =?utf-8?B?OUZYT0hzUjlQLzZQNGdxSjhUblB0eTkvNWNuL1VXeTVPYzJhTitzSDFJUGRm?=
 =?utf-8?B?MmR3SlFLZGs0RUs5YTY2R09nbjNQRFNsTkhKSGlaNyt5ZzVEaG9Nd2dhbkdq?=
 =?utf-8?B?djBlbnVGcXY4bElvd25lcEliTi93YWUvMlFpTmxNUFVXTHZTcUtUYkJmaWhW?=
 =?utf-8?B?Sjh3amRqa3FMaGVIRE84MlNsUWNFYWszNnMxbFQwYStKN1U1aGpnazhQTzFh?=
 =?utf-8?B?NzgyblRHeUtFWWpCMEVDU0pFYmVWRmJ0cDdwSEJ1RXMzamNRbnJKUE5uQnRj?=
 =?utf-8?B?VzZkN3FPaTRvZmNaWEptQVNXVEFTWlFrc0FuN3Y0UUlEK2lCL2tQQkJaODlq?=
 =?utf-8?B?OXlQUi9DRTVFK2xGNGI4TFpRZ2NXTHorSnJKcDRCWHBPWm82V1NzYVB0RXlR?=
 =?utf-8?B?V3J6TGRKVngyOXBrNFhaS29PYTR0TkZrNHFVdHJsN0xsVjI4NThtVFJhSEFp?=
 =?utf-8?B?MDlwYkE4QXcvVkQ0dmlCY28wME1Ydms4RXkwSkxETjhPb1IrSVRXbTRHY1Mw?=
 =?utf-8?B?b1p5Wk9JZ0gyY3FiUnJZOTUwTGJJZTN6RE81TlZNeGtxMzZ5cEpNK1JCb1lT?=
 =?utf-8?B?QjZxK0tjR0JjRFRDemRlTEl5VDhUNVdpNWsxQUdkc044dnd0NjdkQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3188295-7335-4f44-c169-08def25a267a
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 18:56:54.0555
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IDqeZjSFeyZG2BCB9U2yZPtuzTcUpGJhwmi+dDRwmWxJtaXJ9iMLGCKm0kfvhYm9MNsAWMZyMx/jEykgN0Z0oGlj9J7uGnCUQUaBty5aJgg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5744
X-purgate-ID: tlsNG-33051d/1785869817-756834E9-7651E4B4/0/0
X-purgate-type: clean
X-purgate-size: 14557

On 03/08/2026 4:26 pm, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
>> @@ -0,0 +1,330 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#ifdef __XEN__
>> +# include <xen/init.h>
>> +# include <xen/livepatch.h>
>> +#endif
>> +
>> +#include "private.h"
>> +
>> +#undef ModRM
>> +
>> +/*
>> + * Bare minimum x86 instruction decoder to parse the alternative replacement
>> + * instructions and locate the IP-relative references that may need updating.
>> + *
>> + * These are:
>> + *  - disp8/32 from near direct branches
>> + *  - RIP-relative memory references
>> + *
>> + * The following simplifications are used:
>> + *  - All code is 64bit, the instruction stream is well formed and safe to
>> + *    read.
>> + *  - Instruction groups and prefixes not used by Xen's current alternatives
>> + *    are not implemented in order to reduce the decode complexity.
>> + *  - Certain instructions are intentionally not recognised, when it is more
>> + *    likely for their presence to be an error than intentional.
>> + *
>> + * Inputs:
>> + *  @ip  The position to start decoding from.
>> + *  @end End of the replacement block.  Exceeding this is considered an error.
> Why do you mention replacement blocks here? Are we entirely set on this
> code not possibly gaining any purpose beyond the scanning of those?

It's just the end of the instruction stream wanting decoding.  I'll
adjust the comment.

>> +{
>> +#define Imm8   (1 << 0)
>> +#define Imm    (1 << 1)
>> +#define Moffs  (1 << 2)
>> +#define Branch (1 << 5) /* Near direct branches, which have a displacement */
>> +#define ModRM  (1 << 6)
>> +#define Known  (1 << 7)
>> +
>> +    static const uint8_t init_or_livepatch_const onebyte[256] = {
>> +
>> +#define ALU_OPS(x)                              \
>> +        [(x) + 0] = (Known|ModRM),              \
>> +        [(x) + 1] = (Known|ModRM),              \
>> +        [(x) + 2] = (Known|ModRM),              \
>> +        [(x) + 3] = (Known|ModRM),              \
>> +        [(x) + 4] = (Known|Imm8),               \
>> +        [(x) + 5] = (Known|Imm)
>> +
>> +        ALU_OPS(0x00) /* ADD */, ALU_OPS(0x08) /* OR  */,
>> +        ALU_OPS(0x10) /* ADC */, ALU_OPS(0x18) /* SBB */,
>> +        ALU_OPS(0x20) /* AND */, ALU_OPS(0x28) /* SUB */,
>> +        ALU_OPS(0x30) /* XOR */, ALU_OPS(0x38) /* CMP */,
>> +
>> +#undef ALU_OPS
>> +
>> +        [0x50 ... 0x5f] = (Known),             /* PUSH/POP %reg */
>> +
>> +        [0x62]          = 0,                   /* BOUND, but also EVEX prefix, not implemented. */
>> +        [0x63]          = (Known|ModRM),       /* MOVSxd */
>> +
>> +        [0x68]          = (Known|Imm),         /* PUSH $imm */
>> +        [0x69]          = (Known|ModRM|Imm),   /* IMUL $imm */
>> +        [0x6a]          = (Known|Imm8),        /* PUSH $imm8 */
>> +        [0x6b]          = (Known|ModRM|Imm8),  /* PUSH $imm8 */
>> +        [0x6c ... 0x6f] = (Known),             /* INS/OUTS */
>> +        [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */
>> +        [0x80]          = (Known|ModRM|Imm8),  /* Grp1 */
>> +        [0x81]          = (Known|ModRM|Imm),   /* Grp1 */
>> +
>> +        [0x83]          = (Known|ModRM|Imm8),  /* Grp1 */
>> +        [0x84 ... 0x8e] = (Known|ModRM),       /* TEST/XCHG/MOV/MOV-SREG/LEA */
>> +        [0x8f]          = 0,                   /* Grp1A - POP but also XOP prefix, not implemented. */
> POP doesn't look all that unlikely to be used in inline assembly, and
> hence in alternatives. That said, of course using it with a memory
> operand requires quite a bit of care.

We have no alternatives playing with the stack (beyond CALL
instructions), and no alternatives which have any net %rsp delta.

PUSH/POP MEM are rare in general and Xen doesn't have any at all.

> I don't see you excluding the
> PUSH counterpart, though - being consistent for any such pairs would
> seem somewhat desirable.

It would be nice to be handled symmetrically, but this *is* an
odd-instruction-out in the x86 encoding space.

It ought to live in Grp5 where the encoding would be 0xff /7 (and beside
it's matching PUSH), except that's that's a rather important binary
pattern and wants to not be considered a valid instruction.

The fact that the group is split like this shows that the mistake was a
late discovery in the development of the 8086, where it was easier to
move the one opcode than the whole group.  (It's likely to have been a
metal-layer fix for the decode PAL, rather than adjusting the
transistors, which is typically an order of magnitude cheaper fix.)


>
>> +        [0x90 ... 0x99] = (Known),             /* NOP/XCHG %rAX/CLTQ/CQTO */
>> +
>> +        [0x9b ... 0x9f] = (Known),             /* FWAIT/PUSHF/POPF/SAHF/LAHF */
>> +        [0xa0 ... 0xa3] = (Known|Moffs),       /* MOVABS */
>> +        [0xa4 ... 0xa7] = (Known),             /* MOVS/CMPS */
>> +        [0xa8]          = (Known|Imm8),        /* TEST %al */
>> +        [0xa9]          = (Known|Imm),         /* TEST %rAX */
>> +        [0xaa ... 0xaf] = (Known),             /* STOS/LODS/SCAS */
>> +        [0xb0 ... 0xb7] = (Known|Imm8),        /* MOV $imm8, %reg */
>> +        [0xb8 ... 0xbf] = (Known|Imm),         /* MOV $imm{16,32,64}, %reg */
>> +        [0xc0 ... 0xc1] = (Known|ModRM|Imm8),  /* Grp2 (ROL..SAR $imm8, %reg) */
>> +
>> +        [0xc3]          = (Known),             /* RET */
>> +        [0xc4 ... 0xc5] = 0,                   /* LES/LDS but also VEX prefixes, not implemented. */
> This may bite us sooner or later, due to the VEX-encoded integer insns
> that there are. Of course as long as we don't use this function on
> compiled code, and as long as my "x86: allow Kconfig control over psABI
> level" doesn't come close to going in, that's merely a theoretical
> concern.
>
> Same goes for not supporting the 3-byte opcodes, which also encode
> certain integer insns.

I have no doubt that we're going to need to add support eventually.

But,
a) I don't have time right now
b) We have real bugs/limitations right now needing this functionality to
address (patch 5, and the xsave fixes, and bus lock trap enablement)
c) GitlabCI will reliably notice any new alternative instructions that
this can't decode (patch 3)
d) This function is a fastpath during the alternatives patching critical
region (patch 4)

Option d alone is a good reason not to decode VEX prefixes yet.


>
>> +        [0xc6]          = (Known|ModRM|Imm8),  /* Grp11, Further ModRM decode */
>> +        [0xc7]          = (Known|ModRM|Imm),   /* Grp11, Further ModRM decode */
>> +
>> +        [0xcb ... 0xcc] = (Known),             /* LRET/INT3 */
>> +        [0xcd]          = (Known|Imm8),        /* INT $imm8 */
>> +
>> +        [0xd0 ... 0xd3] = (Known|ModRM),       /* Grp2 (ROL..SAR {$1,%cl}, %reg) */
>> +
>> +        [0xd6]          = (Known),             /* UDB */
> I guess you consider XLAT, LOOP*, and J*CXZ as too odd to use in alternatives?
> Decoding-wise they're rather easy to implement.

They are easy, but they also shouldn't appear anywhere in Xen.

I know we've got one J*CXZ in the emulator.  I tried quite hard to find
an alternative before deciding it was an acceptable solution given the
constraints, but it's in plain code.

>
>> +        [0xe4 ... 0xe7] = (Known|Imm8),        /* IN/OUT $imm8 */
>> +        [0xe8 ... 0xe9] = (Known|Branch|Imm),  /* CALL/JMP disp32 */
>> +
>> +        [0xeb]          = (Known|Branch|Imm8), /* JMP disp8 */
>> +        [0xec ... 0xef] = (Known),             /* IN/OUT %dx */
>> +
>> +        [0xf1]          = (Known),             /* ICEBP */
>> +
>> +        [0xf4]          = (Known),             /* HLT */
>> +        [0xf5]          = (Known),             /* CMC */
>> +        [0xf6 ... 0xf7] = (Known|ModRM),       /* Grp3, Further ModRM decode */
>> +        [0xf8 ... 0xfd] = (Known),             /* CLC ... STD */
>> +        [0xfe ... 0xff] = (Known|ModRM),       /* Grp4 */
>> +    };
>> +    static const uint8_t init_or_livepatch_const twobyte[256] = {
>> +        [0x00 ... 0x03] = (Known|ModRM),       /* Grp6/Grp7/LAR/LSL */
> Leaving out INVD is surely find, but WBINVD?

Given now expensive WBINVD is, what possible reason can you think for
having it in an alternative ?

>
>> +        [0x0b]          = (Known),             /* UD2 */
>> +
>> +        [0x18 ... 0x1f] = (Known|ModRM),       /* Grp16 (Hint Nop) */
>> +        [0x20 ... 0x23] = (Known|ModRM),       /* MOV %cr/%dr */
>> +
>> +        [0x30 ... 0x33] = (Known),             /* WRMSR/RDTSC/RDMSR/RDPMC */
>> +
>> +        [0x40 ... 0x4f] = (Known|ModRM),       /* CMOVcc */
>> +
>> +        [0x80 ... 0x8f] = (Known|Branch|Imm),  /* Jcc disp32 */
>> +        [0x90 ... 0x9f] = (Known|ModRM),       /* SETcc */
>> +
>> +        [0xa0 ... 0xa2] = (Known),             /* PUSH/POP %fs/CPUID */
>> +        [0xa3]          = (Known|ModRM),       /* BT */
>> +        [0xa4]          = (Known|ModRM|Imm8),  /* SHLD $imm8 */
>> +        [0xa5]          = (Known|ModRM),       /* SHLD %cl */
>> +
>> +        [0xa8 ... 0xa9] = (Known),             /* PUSH/POP %gs */
>> +
>> +        [0xab]          = (Known|ModRM),       /* BTS */
>> +        [0xac]          = (Known|ModRM|Imm8),  /* SHRD $imm8 */
>> +        [0xad ... 0xaf] = (Known|ModRM),       /* SHRD %cl/Grp15/IMUL */
>> +
>> +        [0xb0 ... 0xb9] = (Known|ModRM),       /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */
>> +        [0xba]          = (Known|ModRM|Imm8),  /* Grp8 */
>> +        [0xbb ... 0xbf] = (Known|ModRM),       /* BTC/BSF/BSR/MOVSX */
>> +        [0xc0 ... 0xc1] = (Known|ModRM),       /* XADD */
> What about MOVNTI?

I judged that to be on the unlikely side to be needed.

>
>> +        [0xc7]          = (Known|ModRM),       /* Grp9 */
>> +        [0xc8 ... 0xcf] = (Known),             /* BSWAP */
>> +    };
> What about UD0?

UD0 differs between vendors and product lines from Intel.

>
>> +    void *start = ip, *rel = NULL;
>> +    unsigned int opc, rel_sz = 0;
>> +    uint8_t b, d, rex = 0, osize = 4;
>> +
>> +#define OPC_TWOBYTE (1 << 8)
>> +
>> +    /* Mutates IP, uses END. */
>> +#define FETCH(ty)                                       \
>> +    ({                                                  \
>> +        ty _val;                                        \
>> +                                                        \
>> +        if ( (ip + sizeof(ty)) > end )                  \
>> +            goto overrun;                               \
>> +        _val = *(ty *)ip;                               \
>> +        ip += sizeof(ty);                               \
>> +        _val;                                           \
>> +    })
>> +
>> +    for ( ;; ) /* Prefixes */
>> +    {
>> +        switch ( b = FETCH(uint8_t) )
>> +        {
>> +        case 0x26: /* ES override */
>> +        case 0x2e: /* CS override */
>> +        case 0x36: /* DS override */
>> +        case 0x3e: /* SS override */
>> +        case 0x64: /* FS override */
>> +        case 0x65: /* GS override */
>> +        case 0xf0: /* LOCK */
>> +        case 0xf2: /* REPNE */
>> +        case 0xf3: /* REP */
>> +            break;
>> +
>> +        case 0x66: /* Operand size override */
>> +            osize = 2;
>> +            break;
>> +
>> +        /* case 0x67: Address size override, not implemented */
>> +
>> +        case 0x40 ... 0x4f: /* REX */
>> +            rex = b;
>> +            continue;
>> +
>> +        default:
>> +            goto prefixes_done;
>> +        }
>> +        rex = 0; /* REX cancelled by subsequent legacy prefix. */
>> +    }
>> + prefixes_done:
>> +
>> +    if ( rex & REX_W )
>> +        osize = 8;
>> +
>> +    /* Fetch the main opcode byte(s) */
>> +    if ( b == 0x0f )
>> +    {
>> +        b = FETCH(uint8_t);
>> +        opc = OPC_TWOBYTE | b;
>> +
>> +        d = twobyte[b];
>> +    }
>> +    else
>> +    {
>> +        opc = b;
>> +        d = onebyte[b];
>> +    }
>> +
>> +    if ( unlikely(!(d & Known)) )
>> +        goto unknown;
>> +
>> +    if ( d & ModRM )
>> +    {
>> +        uint8_t modrm = FETCH(uint8_t);
>> +        uint8_t mod = modrm >> 6;
>> +        uint8_t reg = (modrm >> 3) & 7;
>> +        uint8_t rm = modrm & 7;
>> +
>> +        /* ModRM/SIB decode */
>> +        if ( mod == 0 && rm == 5 ) /* RIP relative */
>> +        {
>> +            rel = ip;
>> +            rel_sz = 4;
>> +            FETCH(int32_t);
> FETCH() here but ...
>
>> +        }
>> +        else if ( mod != 3 && rm == 4 ) /* SIB */
>> +        {
>> +            uint8_t sib = FETCH(uint8_t);
>> +            uint8_t base = sib & 7;
>> +
>> +            if ( mod == 0 && base == 5 )
>> +                goto disp32;
> ... goto here?

Hmm.  That's an artefact of how it developed.  Swapping this goto for
FETCH() does drop 20 bytes, but the function is rearranged so much that
it's hard to tell if this is because real logic is getting dropped.


>
>> +        }
>> +
>> +        if ( mod == 1 ) /* disp8 */
>> +            FETCH(int8_t);
>> +        else if ( mod == 2 ) /* disp32 */
>> +        {
>> +        disp32:
>> +            FETCH(int32_t);
>> +        }
> In several cases the FETCH()ed value isn't used. Compilers as well as Eclair
> (and alike) are happy with that?

Yes.  The cover letter has a fully passing pipeline.

> And compilers also manage to eliminate the memory accesses then?

Yes.

>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>> @@ -835,4 +835,18 @@ static inline void x86_emul_reset_event(struct x86_emulate_ctxt *ctxt)
>>      ctxt->event = (struct x86_event){};
>>  }
>>  
>> +/*
>> + * x86_decode_lite().  Very minimal decoder for managing alternatives.
>> + *
>> + * @len is 0 on error, or nonzero on success.  If the instruction has a
>> + * relative field, @rel_sz is nonzero, and @rel points at the field.
>> + */
>> +typedef struct {
>> +    uint8_t len;
>> +    uint8_t rel_sz; /* bytes: 0, 1 or 4 */
> Perhaps use bitfields in favor of fixed-width integers, seeing what
> ./CODING_STYLE says?

No.  That destroys the code generation improvements gained by returning
a pair like this in the first place.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 19:05:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 19:05:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382588.1625937 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKSU-0002hn-5l; Tue, 04 Aug 2026 19:05:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382588.1625937; Tue, 04 Aug 2026 19:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKSU-0002hg-39; Tue, 04 Aug 2026 19:05:50 +0000
Received: by outflank-mailman (input) for mailman id 1382588;
 Tue, 04 Aug 2026 19:05:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <bp@alien8.de>) id 1wrKSR-0002ha-GP
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:05:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKSQ-004j7r-6J
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:05:46 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <bp@alien8.de>)
 id 6a7237eb-e002-0a2a0a5209dd-0a2a4506d856-20
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:05:45 +0200
Received: from [65.109.113.108] (helo=mail.alien8.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <bp@alien8.de>)
 id 6a723719-195a-0a2a45060019-416d716cbea8-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:01:45 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 45BCB40E00C4; 
 Tue,  4 Aug 2026 19:01:44 +0000 (UTC)
Received: from mail.alien8.de ([127.0.0.1])
 by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id AlYW3JH6yZ7B; Tue,  4 Aug 2026 19:01:34 +0000 (UTC)
Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::1b])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest
 SHA256) (No client certificate requested)
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 35E3D40E014A;
 Tue,  4 Aug 2026 19:00:51 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
X-Virus-Scanned: Debian amavisd-new at mail.alien8.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8;
	t=1785870092; bh=jTsy9ZARpgzdc80qYRTp3ZXD5rupzYp290aPlne24Qo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=i0HieeVUumgJVayfbtPXTLtU9jBWToWFEfi863xOYMBKUVkhNQ0/BrVP6oPJRFif1
	 RGcTlXKPfkv3nwc3J6ik7Eoh+noJN7Y/49GURDCHiWmmcvjurYMzUfD5PiEHDk30cJ
	 pRNh4761TsVzHwyED8UB3oOsW/8KQRN3Mx749T5gWDfd00+A8+mFaHrqBYTGTGIryy
	 1YPo/r7tQzScAcbHiBe85j+9dxxQ1Y731eyF2lUw4Sly7Q3WVTpF3AMKJkf1uQzBeb
	 JYieO0HiWqsbzQPpPDzv9bTeOhd9OR72c9RvUYbqA+jOYpkvx07+CUAkReUdW59gi0
	 DEUGAN1LYWIUv6YarDwWUXxZMIEwPcB3vzm2FdFf05VVMvdQylixP4wN45bPVdqxMU
	 Kn3fe9OIqnxcur1gYV2y0vcl5y6+qcZQuCJISJ6PNY7JBIodKNlAd38lRkhXr5dcLn
	 ue0Fz+kQit+Fm1CnjBOmMu8dJCugOFpc7mCGptKUAONYjDfNlE7xcYS3TW8V8TeJ0I
	 otMAHzrkRKiVwHtrfjaDjpwIXwb7+HQ0fvxUrGTFlI1hc5AMrr8BoufCl/Fvn4BE8B
	 iR/+7JkM+My3QbPAtTN6ne7lhMXJnvOUNGV/mcaWods81JxYTbV35yHlLwwgWKwy7S
	 DIyILA9dtJY98R+pyzsu94ok=
Date: Tue, 4 Aug 2026 12:00:48 -0700
From: Borislav Petkov <bp@alien8.de>
To: Dmitry Ilvokhin <d@ilvokhin.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>, Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>, Thomas Gleixner <tglx@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>, Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
	kvm@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH 1/5] x86/paravirt: Use static_call() for the paravirt
 spinlock ops
Message-ID: <20260804190048.GCanI24Hb5P8qAyVZs@fat_crate.local>
References: <cover.1785778551.git.d@ilvokhin.com>
 <9a32ae399eb804a02a31af04dcabe7e7ee4f3fdf.1785778551.git.d@ilvokhin.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9a32ae399eb804a02a31af04dcabe7e7ee4f3fdf.1785778551.git.d@ilvokhin.com>
X-purgate-ID: tlsNG-16d1c6/1785870105-F4C0777B-F4AEA2D4/13/0
X-purgate-type: clean
X-purgate-size: 3813

On Tue, Aug 04, 2026 at 07:15:41AM +0000, Dmitry Ilvokhin wrote:
> From: Peter Zijlstra <peterz@infradead.org>
> 
> queued_spin_lock_slowpath() and queued_spin_unlock() are dispatched
> through pv_ops_lock via the paravirt-ops ALTERNATIVE machinery, which
> picks the target (native inline store / hypervisor call) once at boot
> and cannot change at runtime.
> 
> Convert both to static_call(). The site becomes a direct call patched in
> place (one byte smaller), and on native the unlock still collapses to
> the inline "movb $0, (%rdi)" store, so the fast path is unchanged.
> 
> Unlike the ALTERNATIVE mechanism, a static_call() target can also be
> updated at runtime via static_call_update(). This is a prerequisite for
> the contended_release tracepoint, which has to swap in a traced unlock
> while the system is running.
> 
> [ ilvokhin: commit message; fix PARAVIRT_SPINLOCKS=n build; teach
>   __static_call_validate() about the inline unlock insn; make the
>   slowpath site module-safe: static_call_mod() +
>   EXPORT_STATIC_CALL_TRAMP(); pass @lock to the callee-save unlock,
>   fixing a boot hang under CALL_DEPTH_TRACKING. Boot tested native + KVM
>   PV guest. ]
> 
> Link: https://lore.kernel.org/all/20260603120811.GW3493090@noisy.programming.kicks-ass.net/
> Co-developed-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>

This needs Peter's SOB.

> ---
>  arch/x86/hyperv/hv_spinlock.c            |  4 ++--
>  arch/x86/include/asm/cpufeatures.h       |  1 -
>  arch/x86/include/asm/paravirt-spinlock.h | 19 +++++++++++------
>  arch/x86/kernel/kvm.c                    |  5 ++---
>  arch/x86/kernel/paravirt-spinlocks.c     | 12 +++++------
>  arch/x86/kernel/static_call.c            | 27 ++++++++++++++++++++++++
>  arch/x86/xen/spinlock.c                  |  5 ++---
>  tools/arch/x86/include/asm/cpufeatures.h |  1 -
>  8 files changed, 51 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
> index 210b494e4de0..6b4bdea18218 100644
> --- a/arch/x86/hyperv/hv_spinlock.c
> +++ b/arch/x86/hyperv/hv_spinlock.c
> @@ -78,8 +78,8 @@ void __init hv_init_spinlocks(void)
>  	pr_info("PV spinlocks enabled\n");
>  
>  	__pv_init_lock_hash();
> -	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
> -	pv_ops_lock.queued_spin_unlock = PV_CALLEE_SAVE(__pv_queued_spin_unlock);
> +	static_call_update(queued_spin_lock_slowpath, __pv_queued_spin_lock_slowpath);
> +	static_call_update(queued_spin_unlock, __raw_callee_save___pv_queued_spin_unlock);
>  	pv_ops_lock.wait = hv_qlock_wait;
>  	pv_ops_lock.kick = hv_qlock_kick;
>  	pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(hv_vcpu_is_preempted);
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 1b4a48bff18f..e41fe5c24841 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -225,7 +225,6 @@
>  #define X86_FEATURE_EPT_AD		( 8*32+17) /* "ept_ad" Intel Extended Page Table access-dirty bit */
>  #define X86_FEATURE_VMCALL		( 8*32+18) /* Hypervisor supports the VMCALL instruction */
>  #define X86_FEATURE_VMW_VMMCALL		( 8*32+19) /* VMware prefers VMMCALL hypercall instruction */
> -#define X86_FEATURE_PVUNLOCK		( 8*32+20) /* PV unlock function */

No, do:

/* free: was #define X86_FEATURE_PVUNLOCK		( 8*32+20) /* PV unlock function */

so that we can reuse it by finding it easier.

>  #define X86_FEATURE_VCPUPREEMPT		( 8*32+21) /* PV vcpu_is_preempted function */
>  #define X86_FEATURE_TDX_GUEST		( 8*32+22) /* "tdx_guest" Intel Trust Domain Extensions Guest */

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 19:17:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 19:17:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382596.1625947 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKdx-0004mb-6o; Tue, 04 Aug 2026 19:17:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382596.1625947; Tue, 04 Aug 2026 19:17:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKdx-0004mU-3V; Tue, 04 Aug 2026 19:17:41 +0000
Received: by outflank-mailman (input) for mailman id 1382596;
 Tue, 04 Aug 2026 19:17:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrKdw-0004mO-5i
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:17:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKdu-001ZEk-MB
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:17:38 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a723ac1-5cb7-0a2a0a5109dd-0a2a450991aa-20
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:17:38 +0200
Received: from [103.168.172.155] (helo=fhigh-a4-smtp.messagingengine.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a723ad0-be1a-0a2a45090019-67a8ac9ba8af-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:17:37 +0200
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 99B98140003C;
 Tue,  4 Aug 2026 15:17:36 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163])
 by phl-compute-03.internal (MEProxy); Tue, 04 Aug 2026 15:17:36 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 4 Aug 2026 15:17:34 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1785871056;
	 x=1785957456; bh=M/edlRurpgP0Tl8VkZ8RyPV4qAksso5dpsJdKhGE39U=; b=
	FNN5lzzVzAPEd9kn2HyNaBsujZACMLlDtYxTDQiT0dzZ8awGOz8Rk7+2MIIVbVEj
	Etc0OeMQ21jn8WhCtRBFal3nXbh2ok8LQkCTQjeoQkTpAmPoZf7zuiqsaZV8D4Vi
	/SJy1YqnReOGJIyOR8beaWutZXKI59F4ScfRlzxLytwSz1YiZM+uH4a8n92+krcc
	k0Gzfnk5a64AnGNLW58sbFTLe7QLqJzigZ1jjVtqCiGuhzndludlJ1IBLqZH6OoV
	ruh6zP6f4gRgoU1yntQuNZaq10Qw75UY+ggGIxO8Y89PEZg6IfMlzyXTWQay8hZ+
	5/Ou2AAEHbG1CBoK4eIcSQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1785871056; x=1785957456; bh=M/edlRurpgP0Tl8VkZ8RyPV4qAksso5dpsJ
	dKhGE39U=; b=CTZnioEQ64TFHLcoTa9PVnPoon2QEtDWKqEoTeWDFnDilw8n9fV
	iCCcjaV0D2460aHgi7F8R7P+J6u0zl1NmVGdE10cOswB2Nq7mEsBUKRQjygPwxJL
	Ouo8ak7zvpn/Gqfzchn7oZ/xR9kaqoaUB/JF5lV2+QW5Ltq1iGL/0BGzGMi0QSor
	21EM4zsMwVMxBsMHcQo5cNvZ8kyD+WNOYz90WomAXCnCqfFChL1rQFPmlLFsG4k7
	lsHZLPHAdidjN6v1ysyAFFg0L5QkE1j2EIY9VrYNjA316kuhkAq7JRnGaZCVjqv/
	V64gQhGk8FUM19elq863BhTT7Q+zmEd6UOg==
X-ME-Sender: <xms:0DpyajpA6GbvvawxZLEPAZSOwr55fFGdFwswEy_H4zNiKL2lJ0XQcg>
    <xme:0DpyarNQU-dQNMnkie_eXViWmYLbM2uQiJo8RpBPnUm-1HkDg_pYo78LvqhCbgVB_
    6fYdhor20jpMZD6Ii-mF3Ys9ZmYXaYDgQoTtn0dKXPOrXYfdtk>
X-ME-Received: <xmr:0DpyamqcrYay4ffLWgTMIp2yZX71RkLMExIerdCqhWG90sgzhzprCJS6iXt-qdptjGjEihn9E3_66wUIXcXq7ODaw7uG--wnjTc>
X-ME-Proxy-Cause: dmFkZTFK/HNVRU9POJZ7muAO4IuQz06udRuTBk9a2svdjpaXCu7y0fu4q5+jNf4Nd9PP9u
    lRgIXJzXxCgD1zgHfD3THiV9eLVR4sO9C67JR78Ru9NZIPpKCKDw8WTy/90Z7WV1iiXE71
    xjiU/1XQxW1i/L8o60OFHRBtK5D4JnD84vUO/dE96RWRQCC0WWcjt2VnejpYPo8gbIfa8N
    ZXl+yEcSleJSMgnRQPnAfpIA1vLLQ2xyWFnAiRm0shjcxM/bFYEMJZrPSpl0iimcbyNDxE
    6o30zGwmiPPcYw6UuoZz1zeJxPhlzWODW1uEg/p2tqkImsxEKbG+ueI1T/zOaPTSdd7zFi
    ++gQ3P7Yr7ZusYXFWVv8T52RJB4il8Vm8dgs4OAQTt/Uy82ZWuIcu+Ou0SjUeyorscaso0
    DgtYv/jS5dl3XZep1H0bgNZbJ8ZZLt3vuHnTv0z7a6m8Qq/OTUhLGFIezsF7CeKdIxgCva
    6aLM1Hw05hFKvqR+TPx6UYTZqkx+T9zUrDpwtfMYZMOUTiJHanoILxq+1zvB5Pja0k9aP+
    dQ4wxqv8h51bXjmHyJ00DxKAC0RG5T+KNU1pIeTyg/PUi+kGozK9M2D8H5FdyqdzhqlKvQ
    KaS1OPhBCGsMjWJYHKNPNsiah92uk8uu2RlIbg8TLURWNPyFJ5dvOw4D4vrg
X-ME-Proxy: <xmx:0Dpyaoep37djQena_0-ngkXGj1OaiJ70yWslCsG7TkpxVNseESAG4A>
    <xmx:0DpyakTYS-lYEBaBTPJJLc5lXHdUZyTKe0Cch23V_cy55UogczRDqg>
    <xmx:0DpyapaIIkR98qLn2UNBBdFxpmmYI0DKih2iupL9GATSTgrSFBtpYQ>
    <xmx:0DpyavfmG5Z-9GmTatbcWQLFtD0mvBcGltjlX5vc-bL8wjxChheMBg>
    <xmx:0DpyarFyrgNcNdVOabHI-fAkgos97n6zMXFDn11Ai6et_qoaNYOCGWUx>
Feedback-ID: i1568416f:Fastmail
Date: Tue, 4 Aug 2026 21:17:32 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64
Message-ID: <anI6zLWzX8kDi7oC@mail-itl>
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-3-frediano.ziglio@citrix.com>
 <anIn7VAt2oQJ90Js@mail-itl>
 <CAHt6W4eCdqp2NDzjHyQ9vdezJkjVyxTwJH7HuReVxVSihox0Rw@mail.gmail.com>
 <9dc1d91c-52e2-4cd9-a234-6d6ca6ecceb8@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="hQuFwtfgOO6JM1Yo"
Content-Disposition: inline
In-Reply-To: <9dc1d91c-52e2-4cd9-a234-6d6ca6ecceb8@citrix.com>
X-purgate-ID: tlsNG-bad1c0/1785871058-3AAD8034-BA37ACC5/0/0
X-purgate-type: clean
X-purgate-size: 5921

--hQuFwtfgOO6JM1Yo
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Aug 2026 21:17:32 +0200
From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64

On Tue, Aug 04, 2026 at 07:55:24PM +0100, Andrew Cooper wrote:
> On 04/08/2026 7:48 pm, Frediano Ziglio wrote:
> > On Tue, 4 Aug 2026 at 18:57, Marek Marczykowski-G=C3=B3recki
> > <marmarek@invisiblethingslab.com> wrote:
> >> On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
> >>> Make sure that save/restore continue to work.
> >>> The check save and restore twice to check for corrupted status.
> >>> Also a command is launched in the guest to make sure that the
> >>> machine is not crashed but working.
> >>>
> >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> >>> ---
> >>>  automation/scripts/console.exp           |  8 +++++
> >>>  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++++=
--
> >>>  2 files changed, 46 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/automation/scripts/console.exp b/automation/scripts/cons=
ole.exp
> >>> index e27886bbef..ff58ed29b8 100755
> >>> --- a/automation/scripts/console.exp
> >>> +++ b/automation/scripts/console.exp
> >>> @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
> >>>      system "$env(WAKEUP_CMD)"
> >>>  }
> >>>
> >>> +if {[info exists env(EXPECT_TEXTS)]} {
> >>> +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
> >>> +    foreach {exp snd} $lines {
> >>> +        expect -re "$exp"
> >>> +        send "$snd\n"
> >>> +    }
> >>> +}
> >>> +
> >>>  if {[info exists env(LOG_MSG)]} {
> >>>      expect {
> >>>          -notransfer -re "$env(PASSED)" {
> >>> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/sc=
ripts/qemu-alpine-x86_64.sh
> >>> index 60f5cc49fc..409a601c34 100755
> >>> --- a/automation/scripts/qemu-alpine-x86_64.sh
> >>> +++ b/automation/scripts/qemu-alpine-x86_64.sh
> >>> @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
> >>>
> >>>  " > etc/local.d/xen.start
> >>>  chmod +x etc/local.d/xen.start
> >>> +
> >>> +# Script to test save and restore.
> >>> +# It saves and restores domU domain twice to check if the domain was=
 corrupted
> >>> +# during the first sequence.
> >>> +# At the end open the console to check if the domain is working.
> >>> +cat > root/save_restore_test << "EOF"
> >>> +#!/bin/sh
> >>> +set -ex
> >>> +xl list | grep -q domU
> >>> +rm -f save.dat
> >>> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat /r=
oot/domU.cfg
> >>> +xl restore /root/domU.cfg save.dat
> >>> +xl list | grep -q domU
> >>> +rm -f save.dat
> >>> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat /r=
oot/domU.cfg
> >>> +xl restore /root/domU.cfg save.dat
> >>> +xl list | grep -q domU
> >>> +rm -f save.dat
> >>> +xl console "$(xl list | awk '$1=3D=3D"domU" { print $2 }')"
> >>> +EOF
> >>> +chmod +x root/save_restore_test
> >>> +
> >>>  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
> >>>  cd ../..
> >>>
> >>> @@ -70,9 +92,23 @@ export TEST_CMD=3D"qemu-system-x86_64 \
> >>>      -device virtio-net-pci,netdev=3Dn0 \
> >>>      -netdev user,id=3Dn0,tftp=3Dbinaries,bootfile=3D/pxelinux.0"
> >>>
> >>> +# Sequence of expect/send strings:
> >>> +# 1. wait domain start and close console;
> >>> +# 2. wait login prompt and login as root
> >>> +# 3. wait login and launch save/restore test;
> >>> +# 4. wait restore from domain console and send a command.
> >> Why doing this interactively over serial, instead of adding to
> >> etc/local.d/xen.start and then printing test result at the end?
> >>
> > I'm using expect to interact with the console. expect is not available
> > inside the alpine root filesystem.
> > Some failure I had during migration is that the VM crashed. In the
> > script I interact with the console to check that the VM is still able
> > to run commands.
>=20
> We can add `expect` to the dom0 root filesystem if we find a need for
> it, and it looks like this might be a good enough reason.=C2=A0 You want a
> patch to https://gitlab.com/xen-project/hardware/test-artifacts
> images/alpine/*-x86_64-base.dockerfile to get it included.

FWIW, my suspend test (which tests a similar thing) uses ping to check
if domU is still alive:
https://gitlab.com/xen-project/people/marmarek/xen/-/blob/2184be51d426b60f5=
e1a7e6e891d0f40e9488fc7/automation/scripts/qemu-alpine-domU-suspend-x86_64.=
sh


> But, for migration testing, this really wants to run on the real
> hardware.=C2=A0 Besides the main memory image, there's variations in regi=
ster
> state and validity which will vary between hardware.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--hQuFwtfgOO6JM1Yo
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmpyOswACgkQ24/THMrX
1yyZZwgAk+x0JJUH7L6xO6AueJRPcm/8FB/EEIhmJn9UTrsz/AArwo1pHd24NhAn
vDwM5cw4bkNAo8qqm9wkVI1UctRLdrR1yoj9nebEosm9969h5W8QfqX1BEZfjeB4
FcRVypbfDHXoeWRhA9f/k9Ixz/LAVxRbCmc3steaE8bGnnGH/U2K3zbqWYvXSDSF
yNR2qQizmZpASTAdaeQv8ann8hfz7mqDAYMhfuAQ0iPn8GxzaksoYKlflr68nJd6
ZichuKBc4Vwjtp/8odC1uDEnYEwnbKxmQumnduCUcDi98ZZ8vjy9xOGeTkAzxYS6
fdDSeGVaCnX6PnruOVJtv85ohK9bUg==
=lREV
-----END PGP SIGNATURE-----

--hQuFwtfgOO6JM1Yo--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 19:29:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 19:29:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382611.1625954 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKp8-0006n1-52; Tue, 04 Aug 2026 19:29:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382611.1625954; Tue, 04 Aug 2026 19:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKp8-0006mu-29; Tue, 04 Aug 2026 19:29:14 +0000
Received: by outflank-mailman (input) for mailman id 1382611;
 Tue, 04 Aug 2026 19:29:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099@swg.vates.tech>)
 id 1wrKp6-0006mm-VW
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:29:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKp6-004lvs-0x
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:29:12 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099@swg.vates.tech>)
 id 6a723d79-5cb7-0a2a0a5109dd-0a2a450286d6-16
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:29:11 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099@swg.vates.tech>)
 id 6a723d87-6ca4-0a2a45020019-b9ff1c228979-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:29:11 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fce4038dd000e099.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 04 Aug 2026 19:29:03 +0000
Received: from l14 (82-67-99-167.subs.proxad.net [82.67.99.167])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 2E4F881FA4;
 Tue,  4 Aug 2026 21:29:02 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=kqZ+2ADVwqlVsYaAlIYvrBJpz0kUI7mX5ygvag4vGGo=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=l7LfxUowQGpuaYVgk0GYAZLvihpODE7NqpSuqW8SoV27t+f19jbMnXUyLfYHNncl3O4mGRqmD
 n6edZK/Rguw7bAteIrQVmAZbRlstVguS3jnGl5ehfgcJaixPzdJmV2Y8crufjKPf83wVQe4GcSA
 BPK5XGcwXnl7GiFBKUwdrflnG76quYXw22VM1Ajlqrk1mREJNJ/wM8247PeZ56LsLs2wECTI9E0
 N7G6rLkppa3Q/0fW5OO9ZYf8h0Z73G78bJHDzPOl77R3ZJwXhceiBvmwFY/liO1uwD1O381J812
 MoLr45RgozMx4APrKnUxzlZzrw5YkvVddetT5GSNbjZw==
X-Zone-Loop: 1cc3a5874ce419e693a20bee8b22273485fa0c627fd1
x-campaign-type: default
x-transaction-id: 12587eb6-e6d1-4239-ab16-3a7037affca0
x-swg-uid: 01-e90026e4-62bc-4f4b-8530-1edc21fa8f5d
X-Mailer: Sweego
Message-ID:
 <1785871743.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099@vates.tech>
x-swg-bid: 1785871743.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Tue, 4 Aug 2026 21:29:01 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH 1/2] CI: Simplify directories creation
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-2-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260804174219.835096-2-frediano.ziglio@citrix.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.1c3f.63ba4c08b36f0347.19fce4035b7.9383ca257edc557f=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1785871742391
X-purgate-ID: tlsNG-720697/1785871751-F06A72AC-A2D84C92/0/0
X-purgate-type: clean
X-purgate-size: 1782

---=Part.1c3f.63ba4c08b36f0347.19fce4035b7.9383ca257edc557f=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 04, 2026 at 06:42:17PM +0100, Frediano Ziglio wrote:
> diff --git a/automation/scripts/qemu-alpine-x86_64=2Esh b/automation/scr=
ipts/qemu-alpine-x86_64=2Esh
> index 242ffca693=2E=2E60f5cc49fc 100755
> --- a/automation/scripts/qemu-alpine-x86_64=2Esh
> +++ b/automation/scripts/qemu-alpine-x86_64=2Esh
> @@ -4,16 +4,7 @@ set -ex -o pipefail
> =20
>  # DomU Busybox
>  cd binaries
> -mkdir -p initrd
> -mkdir -p initrd/bin
> -mkdir -p initrd/sbin
> -mkdir -p initrd/etc
> -mkdir -p initrd/dev
> -mkdir -p initrd/proc
> -mkdir -p initrd/sys
> -mkdir -p initrd/lib
> -mkdir -p initrd/var
> -mkdir -p initrd/mnt
> +mkdir -p initrd/{bin,sbin,etc,dev,proc,sys,lib,var,mnt}

This makes it really hard to find out if more directory or less
directory are been created=2E When reviewing a patch, we don't see what
changed in a line without using more complex tools=2E

For this patch, I have now idea at a glimpse if all the directory that
was created before are still created=2E

In the future, we might need to create more directories, this would
change on very long line to another, and make it hard to find out what
was the logical change, by just looking at the output of `diff -u`=2E

So I don't see this patch as an improvement=2E

But that just my opinion, but that would apply equally to other similar
changes, like packing all the variable declaration on a single line in C=
=2E

Cheers,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.1c3f.63ba4c08b36f0347.19fce4035b7.9383ca257edc557f=---


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 19:37:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 19:37:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382618.1625963 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKx4-0008PM-T4; Tue, 04 Aug 2026 19:37:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382618.1625963; Tue, 04 Aug 2026 19:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrKx4-0008PF-QP; Tue, 04 Aug 2026 19:37:26 +0000
Received: by outflank-mailman (input) for mailman id 1382618;
 Tue, 04 Aug 2026 19:37:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrKx3-0008P9-L1
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 19:37:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrKx0-001bId-Qg
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:37:22 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a723f5e-5cb7-0a2a0a5109dd-0a2a4506b5ba-20
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:37:22 +0200
Received: from [52.101.201.25]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a723f70-195a-0a2a45060019-3465c91949ac-4
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:37:22 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by MN7PR03MB283467.namprd03.prod.outlook.com (2603:10b6:208:5f7::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Tue, 4 Aug
 2026 19:37:19 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Tue, 4 Aug 2026
 19:37:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Pz2DT61shBSEzN8w+Gte4E8/Pd/ITPXBVulHj3lEE+fBPfkikKw2loC6poxtEFa57Z2+kjyLZuWdwnIE5f8jU4EE+t02Qq8yCpXBBCd/BLwNJrYg6chF7UqcN08DblvUOJIh9eYIFB0u4RC1w+CcOiT9oP2BV9L5Ik/uICs+NdNHwAan/OApBd2RlH3NzSAVz9bVgodyPxcTZt2ipUnl9ADeMYZQDqkBZIw8iKSXQVKDcwOY6qYQPcwSpGVLdcKm3YnPT6bIbJ0v10TkYkYbtZKCTJvxKYbyDbd04jTU6kiN4q2S5F/S3c+5AiuTMGiSZLdngdV1wEBnFzlZV3Prog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZHm4HRFiqf/aeTm09glhME2FcmaxvO1JNLPRKicy50A=;
 b=QR1X279M1ywxMJXfgThHE10EYi95003jbNHG2g4zSieqAB+hjsj22OnmshUrwkvFJkVpQOHC+eOvhbvUh86aIitifkU1D51UWI2r0R9lvfT+R3Y0OuJfFqavkw1YYBwbYklyG6kbDtPKR+T8B+xeuQPdTrZG1PN7tgnW0Qn25dsTdkOkjvdCE909xoR3s7RjM3bopiVyYOaVPmxArgJ53LdHwCBbVtjD61lZqFuZEguEpZw6Yf0/sSBjn+DHQ/viGnOTJpMHC/k2MCDNVaWGKDyZBMUeJxYse3qF63WgbgoUr9szH5ZsNTOPajUEoN0h1Sz27jNOPUAI6muJoPuHVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZHm4HRFiqf/aeTm09glhME2FcmaxvO1JNLPRKicy50A=;
 b=kQTtaA6y9ktN8sVnn2KOD6Td1oHzs/MExgzizArhbwhOuGrdOJ+DhmCnsPBVMHJghDMoeCtci3ro6OBug+nyvx8lmOq8orugL5cbejiD76gIjACu/aVDiIR1M4BgIyKl4TREwbMhJTmxrIv83mhJtHQipEsbx9wcptY4eVYxzYk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <21d3fae8-e9b0-4c8a-a7b9-483a0257e44e@citrix.com>
Date: Tue, 4 Aug 2026 20:37:15 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 2/5] tests/x86: Introduce a userspace test harness for
 x86_decode_lite()
To: Jan Beulich <jbeulich@suse.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-3-andrew.cooper3@citrix.com>
 <dd065a33-0105-4527-92f5-f3f127422ee6@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <dd065a33-0105-4527-92f5-f3f127422ee6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0317.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:197::16) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN7PR03MB283467:EE_
X-MS-Office365-Filtering-Correlation-Id: ba013c58-5bf0-435c-5976-08def25fcbcf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|10067099003|56012099006|18002099003|6133799003|22082099003|3023799007|11063799006|4143699003;
X-Microsoft-Antispam-Message-Info:
	QhtGUmJutLjS6bN9Hpok97xSpWokAhiELYDrnUpg2drmn8p/vl8xDGm/MVRbOYn3t+GwF6L3n0356RdnyvxYmnC90ZKdzh0aNlMvcg/r2A+wZgeblbaTQwJ/C5v1cPEw8EwKfiO6140TRXNtNSPLRbUCEQ6Te43b+3EPSs3FQGOLeBqwOkUdGwG+aNRzuGnQnKcouO7ClPLhW+OjyPqdC/FLK/X8Se2shmgvQ0IMp/r0LfYtmc+lNZNT5+jKyYKYh4M7//eubOBN9FtDmCFkKSwgYkBFOiaKCxqrkQmHvKZjzFNo53x7xNJXeQSNwRRUTPOS9IbtkivUjeiwOx7cZplESgehe2zPHo7F2DGSOmoklQQokbxGns91olEDlsjO2WpKS5ztM05o/2hMqjjN5/HlHT133ws24Z/TZRA8uh+tcbmlpFVWs6WEBN7kRBt8tf8IKSEA+1eYHzhJsNTtaNVrX5FyqHzyNCrb2I1Abkcc/CHMkFT5M0BZJtuKw+tlQxzuUCqNBcUivhH4cdLeei5xFyLp6Et2iuKPcXulADWHzbNa/mwgcToI39cWu+Mly+wKU7UqSYguHkIcx+7TAjrlNqN5jeGsd5i4KihavosYTavlShbR7M0st52qjulgC/IQzCNMFkfnb8J62kL29wM+AKKlGp0Vw+1Lsmbr8VA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(10067099003)(56012099006)(18002099003)(6133799003)(22082099003)(3023799007)(11063799006)(4143699003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UUloclFlajBPL1JpbENZdytKRFBPZVk2UmR2WjZFRUVwSVowV21pamt2aTJ3?=
 =?utf-8?B?VXFYclROQkNRS0UzeGkzdWZDYWw4bzU2YWlXbUp6WVFuY3VrRWFuSTVwSndr?=
 =?utf-8?B?eFlGMFlwUWNVakhZOHprdUtiUHArVmlHSURPSWxtNnBJOURYb2JJbDBIdWF4?=
 =?utf-8?B?ZDlEcWkvZEdOZjZiMW8rOTlvakJpZkRqK0NjT3VqZGk4dWovYnQ2T2k1WW1I?=
 =?utf-8?B?N2E0MFlHZVZETFFsQmNiTVdFUDVtME8xZHRqMGJzdmo3RnZkSTJoV0tOUHNp?=
 =?utf-8?B?MDNwMmh1YTE1TEt0YTZrTEhnWmdLR1Q4Y2RtcDB3M3MrSTVwREdDdVVnbHFJ?=
 =?utf-8?B?bFVYdklUWnp2RFAza2RVdXNMYllYTHkrWm03NkZWUGdxNjRUdlR5SjJ5Wlk4?=
 =?utf-8?B?UjlLUldEYnVud2EvdG5hY2xxbVEyNUQ1Z0cramg3WjRkeDluQVFyTkZUSW9R?=
 =?utf-8?B?UVhRcCtNeWJRRnhBWGxSMXVFOWJCTHljSjZrYTVMT2NCZUhrY2NLb25jOVB1?=
 =?utf-8?B?SmoxeHltSjZJQk9VRHBOVFg4NFlSVnNXYjBtT2Z4V2I2MUo1MEVGeFNEcTJo?=
 =?utf-8?B?QllFNmNycGg1Rm9GSm5OTjBCU3g3Wk13VFV5ZmVqUGNFTFhQN2NuVmhWN1B4?=
 =?utf-8?B?UCtOOVU0dWJiYnVqVWVLWWI3RXBWNFNERXNuMG42MFBWTWh3dE1zOXp6Ykpw?=
 =?utf-8?B?d2JJd1I3T0pqYXArcTcyUSs2ckxRWVlOOWp0VEZTTTBnRTI5S1BCaFFkQzBK?=
 =?utf-8?B?SWZSWk9zTG1nWkkvajdKWjJMSkRybThLOUZVbDlGTXdmdjVWRW56WCtlVG1K?=
 =?utf-8?B?eVFaVWJaS1Z4MDdETFZVM0pvQlR6dWExQVBzK0gwYTZaSFFqci9panVLOUFt?=
 =?utf-8?B?L3ZidDJyWGVsV2loK2lYVmczRnBHRDFpdVlkdTc0TXR3eUpIV3BGRFRGQS96?=
 =?utf-8?B?ZFhyUVJiUEhVWmpkbUoyTzhWTldPLzJtRU05YzZid3JJdFA4bXNHWVZGeGNL?=
 =?utf-8?B?Ym9Nd0NjRGxUTUgrRGsxQU41NzUwWDJkYXAyN3NkUU5mUDYrdms5TFp2dWNC?=
 =?utf-8?B?VWhLbFhpYU1RYjc3SHRIOVRhbksyQ0FZRTRaUCt2KzBmcFVmK0NuanF5c1Fw?=
 =?utf-8?B?NFM1ZUZ2UTVKOG12N1B2NVFZRSt0VEhIbTAxL1pyd1hWOVhTRzhleUpMdkRl?=
 =?utf-8?B?WW5hbVJWaWJlRm9KYkFmc1cwWnhJNGIyOWxRZXJEd2dWVTluMXVXcnUvS2ta?=
 =?utf-8?B?MktSRGJMRFg3TmRYdUtLYnhwRFdNUkFzUVVRbzdGMGJyTUVxZjlrR0VmU01N?=
 =?utf-8?B?MHAwY2JuWkcxM081ekxsQkVKdzdNc2V0YkJJL0xZZ0x3eURWSC9Gc1B1Wndp?=
 =?utf-8?B?QWpVMUU4YmdVdHFpeG80dXROY0pwVkM0T25ENVZZa3ozK1cwem5yWUNQcmpS?=
 =?utf-8?B?ZkQ1NmJGM2dNNU9lMEpKWStKN3RGMDljTFpKQUtNN3VsWUJwMWE2NzFveUo3?=
 =?utf-8?B?cDBROGRGRGNoR3FaNkphTTVNYitvZ3EzZEwrTVlvZ0xvdFFwRmhZdTVhZkUy?=
 =?utf-8?B?V0FPRmIxRDViWkdrbW1zbHJzeWNRcjNMMjZyS0FJVWx4MkFTMDFsUHRjRXJa?=
 =?utf-8?B?UjRZb1NVaitZMDhOQzMvM0xFNnc2YlNMMGR6R2VQeGI4TXBFcVpPaGh0L3ZD?=
 =?utf-8?B?MitTdHN1K05tK25TbkZFMmNxaWg5d0dYWlRwbjMyS3RlUmw3bHJBRmY3NkFD?=
 =?utf-8?B?Kytock1SSTRZTUlJR0xtM25maVRacEFWd0dNcDFxaTF2YnJEQnc5UHRuZlJG?=
 =?utf-8?B?QVBlenJXd1ZUZUpmVlpoTG1NVE41OG00eFFEN2VGZFdUV1gwcE1aUjBoV0kw?=
 =?utf-8?B?YWJpSGc2Tm40TVVldVpsK0ttc3lXakhBRGR5eFlrQmQ0dFBPdGdwL1AxZDhE?=
 =?utf-8?B?dHJVVk12aEdKd0lSa3dZK0RIaXRGOWFKNmhKemRSRjRkbDBwek9pcXhueVJQ?=
 =?utf-8?B?VWp6NWhBOFhiSU5SWmF1NjFEMmZqeXUyeHg0VGJWRS9BWHFINGg4SUJ0RWFO?=
 =?utf-8?B?cC9GWHFKYm1qZzFrUGcyYU84d2Zsd0ZhVlhoVTlhOVp3V05od3J2Yzg1MXph?=
 =?utf-8?B?T2pRMXVLMHFxYWkwZGR0WWIxNGtNc25YVXRQaHFpanE0dFFzU0o0bFBvQ0o2?=
 =?utf-8?B?SjdZOFhZclEyVVo4THIrYXl1RTRFTzNUaWNHam0wODI3TFlYUWtreW1ZUU9O?=
 =?utf-8?B?UFRtOTRQdmQ0cXpWM2RzTnJaaExDN2J3YWZNTko3QjEwOWplS1RtSy9McGM4?=
 =?utf-8?B?ZFEzMXNRcnhQSGRqSzY0eitaS3hvUU1ZOUl0RWVPSUZlTXdVQXBiZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba013c58-5bf0-435c-5976-08def25fcbcf
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 19:37:18.9686
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4jxL75zvnbgXF/nEZh+ly7yKjUzjrJO30RGES9vgdH+ARu0vC0RO1PoUCI4dfQDiw1WPzY221OWGPL1SmM0UfHzRjgL1BmrcteW/5c1ULeE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN7PR03MB283467
X-purgate-ID: tlsNG-16d1c6/1785872242-FE07177B-45415424/0/0
X-purgate-type: clean
X-purgate-size: 11712

On 03/08/2026 5:03 pm, Jan Beulich wrote:
> On 03.08.2026 09:20, Andrew Cooper wrote:
>> --- /dev/null
>> +++ b/tools/tests/x86-decode-lite/insns.S
>> @@ -0,0 +1,703 @@
>> +#include "macro-magic.h"
>> +
>> +        .code64
>> +
>> +        .allow_index_reg
>> +
>> +        .text
>> +
>> +DECL(tests_rel0)
>> +modrm:
>> +        /* Mod=0, Reg=0, RM {0..f} */
>> +        _ add %al, (%rax)
>> +        _ add %al, (%rcx)
>> +        _ add %al, (%rdx)
>> +        _ add %al, (%rbx)
>> +        _ add %al, (%rsp) /* SIB */
>> +        /*add %al, (%rbp)    RIP --> tests_rel4 */
>> +        _ add %al, (%rsi)
>> +        _ add %al, (%rdi)
>> +        _ add %al, (%r8)
>> +        _ add %al, (%r9)
>> +        _ add %al, (%r10)
>> +        _ add %al, (%r11)
>> +        _ add %al, (%r12) /* SIB */
>> +        /*add %al, (%r13)    RIP --> tests_rel4 */
>> +        _ add %al, (%r14)
>> +        _ add %al, (%r15)
>> +
>> +        /* Mod=1, Reg=0, RM {0..f} */
>> +        _ add %al, 0x01(%rax)
>> +        _ add %al, 0x01(%rcx)
>> +        _ add %al, 0x01(%rdx)
>> +        _ add %al, 0x01(%rbx)
>> +        _ add %al, 0x01(%rsp) /* SIB */
>> +        _ add %al, 0x01(%rbp)
>> +        _ add %al, 0x01(%rsi)
>> +        _ add %al, 0x01(%rdi)
>> +        _ add %al, 0x01(%r8)
>> +        _ add %al, 0x01(%r9)
>> +        _ add %al, 0x01(%r10)
>> +        _ add %al, 0x01(%r11)
>> +        _ add %al, 0x01(%r12) /* SIB */
>> +        _ add %al, 0x01(%r13)
>> +        _ add %al, 0x01(%r14)
>> +        _ add %al, 0x01(%r15)
>> +
>> +        /* Mod=2, Reg=0, RM {0..f} */
>> +        _ add %al, 0x7f000001(%rax)
>> +        _ add %al, 0x7f000001(%rcx)
>> +        _ add %al, 0x7f000001(%rdx)
>> +        _ add %al, 0x7f000001(%rbx)
>> +        _ add %al, 0x7f000001(%rsp) /* SIB */
>> +        _ add %al, 0x7f000001(%rbp)
>> +        _ add %al, 0x7f000001(%rsi)
>> +        _ add %al, 0x7f000001(%rdi)
>> +        _ add %al, 0x7f000001(%r8)
>> +        _ add %al, 0x7f000001(%r9)
>> +        _ add %al, 0x7f000001(%r10)
>> +        _ add %al, 0x7f000001(%r11)
>> +        _ add %al, 0x7f000001(%r12) /* SIB */
>> +        _ add %al, 0x7f000001(%r13)
>> +        _ add %al, 0x7f000001(%r14)
>> +        _ add %al, 0x7f000001(%r15)
>> +
>> +        /* Mod=3, Reg=0, RM {0..f} */
>> +        _ add %al, %al
>> +        _ add %al, %cl
>> +        _ add %al, %dl
>> +        _ add %al, %bl
>> +        _ add %al, %ah
>> +        _ add %al, %ch
>> +        _ add %al, %dh
>> +        _ add %al, %dl
> Perhaps also include %bpl, %sil, and %dil?

They're not relevant to this test, and interfere with the intentional
pattern set up.

>
>> +onebyte_row_9x:
>> +        _ nop
>> +        _ pause
>> +        _ xchg %ax, %ax
>> +        _ xchg %eax, %eax
>> +        _ xchg %rax, %rax
>> +        _ rex.w xchg %rax, %rax
>> +        _ cltq
>> +        _ cqto
>> +        _ wait
>> +        _ pushf
>> +        _ popf
>> +        _ sahf
>> +        _ lahf
>> +
>> +onebyte_row_ax:
> May I suggest onebyte_row_Ax?

Ok.

>
>> +DECL(tests_rel1)
>> +disp8:
>> +1:
>> +        _ jo   1b
>> +        _ jno  1b
>> +        _ jb   1b
>> +        _ jae  1b
>> +        _ je   1b
>> +        _ jne  1b
>> +        _ jbe  1b
>> +        _ ja   1b
>> +        _ js   1b
>> +        _ jns  1b
>> +        _ jp   1b
>> +        _ jnp  1b
>> +        _ jl   1b
>> +        _ jge  1b
>> +        _ jle  1b
>> +        _ jg   1b
>> +        _ jmp  1b
>> +
>> +disp8_rex:
>> +        _ rex.w jo   1b
>> +        _ rex.w jno  1b
>> +        _ rex.w jb   1b
>> +        _ rex.w jae  1b
>> +        _ rex.w je   1b
>> +        _ rex.w jne  1b
>> +        _ rex.w jbe  1b
>> +        _ rex.w ja   1b
>> +        _ rex.w js   1b
>> +        _ rex.w jns  1b
>> +        _ rex.w jp   1b
>> +        _ rex.w jnp  1b
>> +        _ rex.w jl   1b
>> +        _ rex.w jge  1b
>> +        _ rex.w jle  1b
>> +        _ rex.w jg   1b
>> +        _ rex.w jmp  1b
>> +END(tests_rel1)
> What's the idea behind the separate REX.W testing?

Testing osize handling vs Imm8/Imm.

>  It almost suggests that
> tests with an operand size prefix also may want adding. Except that's
> difficult, because of ...
>
>> +DECL(tests_rel4)
>> +disp32:
>> +        _ call   other_section
>> +        _ jmp    other_section
>> +        _ jo     other_section
>> +        _ jno    other_section
>> +        _ jb     other_section
>> +        _ jae    other_section
>> +        _ je     other_section
>> +        _ jne    other_section
>> +        _ jbe    other_section
>> +        _ ja     other_section
>> +        _ js     other_section
>> +        _ jns    other_section
>> +        _ jp     other_section
>> +        _ jnp    other_section
>> +        _ jl     other_section
>> +        _ jge    other_section
>> +        _ jle    other_section
>> +        _ jg     other_section
>> +        _ xbegin other_section
>> +
>> +disp32_rex:
>> +        _ rex.w call   other_section
>> +        _ rex.w jmp    other_section
>> +        _ rex.w jo     other_section
>> +        _ rex.w jno    other_section
>> +        _ rex.w jb     other_section
>> +        _ rex.w jae    other_section
>> +        _ rex.w je     other_section
>> +        _ rex.w jne    other_section
>> +        _ rex.w jbe    other_section
>> +        _ rex.w ja     other_section
>> +        _ rex.w js     other_section
>> +        _ rex.w jns    other_section
>> +        _ rex.w jp     other_section
>> +        _ rex.w jnp    other_section
>> +        _ rex.w jl     other_section
>> +        _ rex.w jge    other_section
>> +        _ rex.w jle    other_section
>> +        _ rex.w jg     other_section
>> +        _ rex.w xbegin other_section
> ... vendor differences here. Perhaps the decoder itself would better
> reject handling of operand-size-prefixed branches.

Excluding 66-prefix is easy, but excluding rex.w on jumps is hard and
would require extra logic.

>> +opsize_branch: /* 66-prefixed branches are decoded differently by vendors */
>> +        _ data16 call   other_section
>> +        _ data16 jmp    other_section
>> +        _ data16 jo     other_section
>> +        _ data16 jno    other_section
>> +        _ data16 jb     other_section
>> +        _ data16 jae    other_section
>> +        _ data16 je     other_section
>> +        _ data16 jne    other_section
>> +        _ data16 jbe    other_section
>> +        _ data16 ja     other_section
>> +        _ data16 js     other_section
>> +        _ data16 jns    other_section
>> +        _ data16 jp     other_section
>> +        _ data16 jnp    other_section
>> +        _ data16 jl     other_section
>> +        _ data16 jge    other_section
>> +        _ data16 jle    other_section
>> +        _ data16 jg     other_section
>> +        _ data16 xbegin other_section
> Oh, you even cover the case here. For XBEGIN, however, this can only be pure
> guesswork as to AMD behavior, I suppose.

Remember that RTM is available on Zen2 if you know which chickenbits to
clobber.

I've not tried.  I expect it's more likely that they behave consistently
than differently.

> I also don't see how you force which form you want.

Binutils always produces AMD behaviour.  (As far as I can see.)

This is in the negative-tests section, which confirms that
x86_decode_lite() rejects the byte pattern.

If Binutils changes behaviour, the test will start failing.

>
>> --- /dev/null
>> +++ b/tools/tests/x86-decode-lite/main.c
>> @@ -0,0 +1,111 @@
>> +/*
>> + * Userspace test harness for x86_decode_lite().
>> + */
>> +#include <stdio.h>
>> +
>> +#include "x86-emulate.h"
>> +
>> +static unsigned int nr_failures;
>> +#define fail(t, fmt, ...)                                       \
>> +({                                                              \
>> +    const unsigned char *insn = (t)->ip;                        \
>> +                                                                \
>> +    nr_failures++;                                              \
>> +                                                                \
>> +    (void)printf("  Fail '%s' [%02x", (t)->name, *insn);        \
>> +    for ( unsigned int i = 1; i < (t)->len; i++ )               \
>> +        printf(" %02x", insn[i]);                               \
>> +    printf("]\n");                                              \
>> +                                                                \
>> +    (void)printf(fmt, ##__VA_ARGS__);                           \
>> +})
>> +
>> +struct test {
>> +    const char *name;
>> +    void *ip;
>> +    unsigned long len;
>> +};
>> +
>> +extern const struct test
>> +/* Defined in insns.S, ends with sentinel */
>> +    tests_rel0[], /* No relocatable entry */
>> +    tests_rel1[], /* disp8 */
>> +    tests_rel4[], /* disp32 or RIP-relative */
>> +    tests_unsup[]; /* Unsupported instructions */
>> +
>> +static inline void run_tests(const struct test *tests, unsigned int rel_sz)
>> +{
>> +    printf("Test rel%u\n", rel_sz);
>> +
>> +    for ( unsigned int i = 0; tests[i].name; ++i )
>> +    {
>> +        const struct test *t = &tests[i];
>> +        x86_decode_lite_t r;
>> +
>> +        /*
>> +         * Don't end strictly at t->len.  This provides better diagnostics if
>> +         * too many bytes end up getting consumed.
>> +         */
>> +        r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
> For the excess bytes to at least be legitimate to access (not causing UB),
> shouldn't finish_arr emit enough filler bytes?

finish_arr is the wrong place, but I've folded in:

diff --git a/tools/tests/x86-decode-lite/insns.S b/tools/tests/x86-decode-lite/insns.S
index e52c2934c8d8..dc017016b2d2 100644
--- a/tools/tests/x86-decode-lite/insns.S
+++ b/tools/tests/x86-decode-lite/insns.S
@@ -695,6 +695,13 @@ unsup_insn: /* Instructions that would complicated decode, or shouldn't be used
 
 END(tests_unsup)
 
+        /*
+         * For improved diagnostics, we allow some overreading of the
+         * instruction under test.  Ensure there are good bytes to read.
+         */
+overread_padding:
+        .skip 20
+
         /* This is here to cause jmps to use their disp32 form. */
         .section .text.other_section, "ax", @progbits
 other_section:



>
>> --- /dev/null
>> +++ b/tools/tests/x86-decode-lite/x86-emulate.h
>> @@ -0,0 +1,27 @@
>> +#ifndef X86_EMULATE_H
>> +#define X86_EMULATE_H
>> +
>> +#include <assert.h>
>> +#include <stdbool.h>
>> +#include <stdint.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +
>> +#include <xen/asm/x86-defns.h>
>> +#include <xen/asm/x86-vendors.h>
>> +
>> +#include <xen-tools/common-macros.h>
>> +
>> +#define ASSERT assert
>> +
>> +#define printk(...)
>> +
>> +#define likely
>> +#define unlikely
>> +#define cf_check
>> +#define init_or_livepatch
>> +#define init_or_livepatch_const
>> +
>> +#include "x86_emulate/x86_emulate.h"
> Why does this end up being needed?

Well, this for starters:

main.c: In function ‘run_tests’:
main.c:43:9: error: unknown type name ‘x86_decode_lite_t’
   43 |         x86_decode_lite_t r;
      |         ^~~~~~~~~~~~~~~~~
main.c:49:13: error: implicit declaration of function ‘x86_decode_lite’ [-Werror=implicit-function-declaration]
   49 |         r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
      |             ^~~~~~~~~~~~~~~



~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 20:06:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 20:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382629.1625973 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrLPI-0004Tg-7H; Tue, 04 Aug 2026 20:06:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382629.1625973; Tue, 04 Aug 2026 20:06:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrLPI-0004TZ-4m; Tue, 04 Aug 2026 20:06:36 +0000
Received: by outflank-mailman (input) for mailman id 1382629;
 Tue, 04 Aug 2026 20:06:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <peterz@infradead.org>) id 1wrLPF-0004TR-8T
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 20:06:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrLPE-001eg9-Lb
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 22:06:32 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <peterz@infradead.org>)
 id 6a72462c-e002-0a2a0a5209dd-0a2a45069ecc-10
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 22:06:31 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <peterz@infradead.org>)
 id 6a724376-195a-0a2a45060019-5a9b3222c75a-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:54:31 +0200
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]
 helo=noisy.programming.kicks-ass.net)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wrLDN-00000004dyG-3Yfn; Tue, 04 Aug 2026 19:54:17 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
 id 0A184300B40; Tue, 04 Aug 2026 21:54:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=+IzxgHirXh8bANHLHHneykwXTiWqinCHzwnsN/D+w1g=; b=cgc/4q5XWxb+9KHledOTiCkjCj
	qq0/2fvaHG7Qp83Vg+3/fUN0X2kukF2LFGusGOYQrH0obYRDUEtgSeWR3tr+4dGHM1+rpu/rLQ1Tk
	0IRno6TRcPM9AAut3SiFQbVeIH55/1SLk/L57s2QIePicpmXv8BSEr/7MiSgs+DW6OKfkUVq4xyWW
	f/Bg3OJHFn/zCKQb5ODfDBLhY5WYJ9QRUlrhLWFVC+XuxtxkMtKKJouvX0pcB5x+VcFKNyhAxS7MJ
	mm2BbOwBUTRRIZYT5+BtfzMIOia+PY04wvaF7AiNa2bNuOBjcNm1RZO5LghLrrQ4rMN1nlxylF5zK
	0KLtQp6A==;
Date: Tue, 4 Aug 2026 21:54:16 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Dmitry Ilvokhin <d@ilvokhin.com>, Ingo Molnar <mingo@redhat.com>,
	Will Deacon <will@kernel.org>, Boqun Feng <boqun@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>, Thomas Gleixner <tglx@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, Juergen Gross <jgross@suse.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jason Baron <jbaron@akamai.com>, Alice Ryhl <aliceryhl@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
	kvm@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH 1/5] x86/paravirt: Use static_call() for the paravirt
 spinlock ops
Message-ID: <20260804195416.GJ776954@noisy.programming.kicks-ass.net>
References: <cover.1785778551.git.d@ilvokhin.com>
 <9a32ae399eb804a02a31af04dcabe7e7ee4f3fdf.1785778551.git.d@ilvokhin.com>
 <20260804190048.GCanI24Hb5P8qAyVZs@fat_crate.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260804190048.GCanI24Hb5P8qAyVZs@fat_crate.local>
X-purgate-ID: tlsNG-16d1c6/1785873271-FEA7477B-2DE99309/13/0
X-purgate-type: clean
X-purgate-size: 3811

On Tue, Aug 04, 2026 at 12:00:48PM -0700, Borislav Petkov wrote:
> On Tue, Aug 04, 2026 at 07:15:41AM +0000, Dmitry Ilvokhin wrote:
> > From: Peter Zijlstra <peterz@infradead.org>
> > 
> > queued_spin_lock_slowpath() and queued_spin_unlock() are dispatched
> > through pv_ops_lock via the paravirt-ops ALTERNATIVE machinery, which
> > picks the target (native inline store / hypervisor call) once at boot
> > and cannot change at runtime.
> > 
> > Convert both to static_call(). The site becomes a direct call patched in
> > place (one byte smaller), and on native the unlock still collapses to
> > the inline "movb $0, (%rdi)" store, so the fast path is unchanged.
> > 
> > Unlike the ALTERNATIVE mechanism, a static_call() target can also be
> > updated at runtime via static_call_update(). This is a prerequisite for
> > the contended_release tracepoint, which has to swap in a traced unlock
> > while the system is running.
> > 
> > [ ilvokhin: commit message; fix PARAVIRT_SPINLOCKS=n build; teach
> >   __static_call_validate() about the inline unlock insn; make the
> >   slowpath site module-safe: static_call_mod() +
> >   EXPORT_STATIC_CALL_TRAMP(); pass @lock to the callee-save unlock,
> >   fixing a boot hang under CALL_DEPTH_TRACKING. Boot tested native + KVM
> >   PV guest. ]
> > 
> > Link: https://lore.kernel.org/all/20260603120811.GW3493090@noisy.programming.kicks-ass.net/
> > Co-developed-by: Dmitry Ilvokhin <d@ilvokhin.com>
> > Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> 
> This needs Peter's SOB.

Yeah, that got fixed when I applied it ;-)

> > ---
> >  arch/x86/hyperv/hv_spinlock.c            |  4 ++--
> >  arch/x86/include/asm/cpufeatures.h       |  1 -
> >  arch/x86/include/asm/paravirt-spinlock.h | 19 +++++++++++------
> >  arch/x86/kernel/kvm.c                    |  5 ++---
> >  arch/x86/kernel/paravirt-spinlocks.c     | 12 +++++------
> >  arch/x86/kernel/static_call.c            | 27 ++++++++++++++++++++++++
> >  arch/x86/xen/spinlock.c                  |  5 ++---
> >  tools/arch/x86/include/asm/cpufeatures.h |  1 -
> >  8 files changed, 51 insertions(+), 23 deletions(-)
> > 
> > diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
> > index 210b494e4de0..6b4bdea18218 100644
> > --- a/arch/x86/hyperv/hv_spinlock.c
> > +++ b/arch/x86/hyperv/hv_spinlock.c
> > @@ -78,8 +78,8 @@ void __init hv_init_spinlocks(void)
> >  	pr_info("PV spinlocks enabled\n");
> >  
> >  	__pv_init_lock_hash();
> > -	pv_ops_lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
> > -	pv_ops_lock.queued_spin_unlock = PV_CALLEE_SAVE(__pv_queued_spin_unlock);
> > +	static_call_update(queued_spin_lock_slowpath, __pv_queued_spin_lock_slowpath);
> > +	static_call_update(queued_spin_unlock, __raw_callee_save___pv_queued_spin_unlock);
> >  	pv_ops_lock.wait = hv_qlock_wait;
> >  	pv_ops_lock.kick = hv_qlock_kick;
> >  	pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(hv_vcpu_is_preempted);
> > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> > index 1b4a48bff18f..e41fe5c24841 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arch/x86/include/asm/cpufeatures.h
> > @@ -225,7 +225,6 @@
> >  #define X86_FEATURE_EPT_AD		( 8*32+17) /* "ept_ad" Intel Extended Page Table access-dirty bit */
> >  #define X86_FEATURE_VMCALL		( 8*32+18) /* Hypervisor supports the VMCALL instruction */
> >  #define X86_FEATURE_VMW_VMMCALL		( 8*32+19) /* VMware prefers VMMCALL hypercall instruction */
> > -#define X86_FEATURE_PVUNLOCK		( 8*32+20) /* PV unlock function */
> 
> No, do:
> 
> /* free: was #define X86_FEATURE_PVUNLOCK		( 8*32+20) /* PV unlock function */
> 
> so that we can reuse it by finding it easier.

Sure, I can do that.


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 21:41:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 21:41:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382653.1625982 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrMsd-0008Ml-PC; Tue, 04 Aug 2026 21:40:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382653.1625982; Tue, 04 Aug 2026 21:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrMsd-0008Me-LE; Tue, 04 Aug 2026 21:40:59 +0000
Received: by outflank-mailman (input) for mailman id 1382653;
 Tue, 04 Aug 2026 21:40:58 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrMsc-0008MY-2z
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:40:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrMsb-001obd-6Z
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 23:40:57 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a725c2a-2eae-0a2a0a5409dd-0a2a450487ba-44
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:40:57 +0200
Received: from [74.125.224.47] (helo=mail-yx1-f47.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a725c68-b57f-0a2a45040019-4a7de02fbd12-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:40:57 +0200
Received: by mail-yx1-f47.google.com with SMTP id
 956f58d0204a3-669944f5ef1so302167d50.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:40:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1785879655; cv=none;
        d=google.com; s=arc-20260327;
        b=g36Z68Wwbq2TXta0huJSzjGl+bhGBcD2EFjefRfbqycj6X6JaZ+yp9QWAxYBJHkW4B
         obuxWqfKz5sMs0hl9/BzcapFVmySqUAbEtO4PQ4EHTMLhQCP2e/DpO8/UyKyU6RFteRY
         MtJXaGw0M4P/xev9yK0KYBj2E6/yAYuC5w8Itdxd2R54YVGdvkH7ysIVaK0Nl2WnSBbb
         ZLhNPiB1FDpC1f7nHlXp5C5HRR7aD2eHsYKFfyQURDM0bGb/64yfLsLck9hPeKN8QVEh
         M9iTHyUnpqG1gGCP02yDnpnaf6/X/k4d7J2lsTuKjfS8Q8FWaIV4mYJHckBvadX9iEnR
         M8QA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=sUP90bFdYVViBJwMVU0ncUeotpyeUeVbV/REZdSDfEg=;
        fh=K9IAd8BUey1PZ/zoeGTbn1ETVLXZhvAgW6PCZb/WSCU=;
        b=PnSMeV0tNNIU72qLKz4gKYb+ihNbTjXp+EBL/BRfoXbrLW1UbeENhZ/8g+Iwuu3pNV
         ZqNJs2SDNse1ED0kCgbSfpHcUC39ScrfeBWHZZI42GdkHoe6bwt8fgev4ZKgkGh2Z2IA
         XBOBv8oOKI+3nDimCzvvn3SLhcyYAV1nlH4V/jTopS/OOdWIbZjOIYIiw/9eFZ5oblMa
         jIoxe7AUUAXdSaAh1LnhU+PscieyXEJbCyV1ElgIKelKDL52OtNUAwyiIfarQm+MQY2H
         fhCP2RY8i4gXtJdriPN5ogCPEflCNPYN9thPnm+dV/MGtVsYvUZPmoZie5wb0m1x0VPw
         BcXA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785879655; x=1786484455; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=sUP90bFdYVViBJwMVU0ncUeotpyeUeVbV/REZdSDfEg=;
        b=HGXP0+GmRqgqY7wih4hjQo0WG8iDs4T+MH/XXM+RgUbbY6jjqne+7KysjimYmi+Peo
         YcFneXnt4HIBBRMx7dRH7awBEiflpVr9MhP7LbPj0jyGi4sOpeCKVd6ATedg5r0BS4bC
         GwG3ukrh8Knae5FYx+Y7peWWofSr5fKaI0/UfPbfxd4aZEt9xjAJj6/TSl/0njLF0r+E
         nBQneR6Ws9jr/qLUqHpQwRucYHC6Nx76/655tYKTJlH6wrEwNdP252GUjcRn+Jc1A3Bf
         +qucN4rOYuBk0WXtkeFC/eCA8B8Wg7gUoD9ESasaFH5XsWvEP7/okuZ79wubqmpuwQxk
         64HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785879655; x=1786484455;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=sUP90bFdYVViBJwMVU0ncUeotpyeUeVbV/REZdSDfEg=;
        b=SQ5zvTDhCZQtGKgJo1wecctnICiZLeZyXiGAXUOoaqGTSQ1KX6CVCf09vYEVe/hfuu
         2qwVf4TqLMRX+zmiv+PO3GtUeMpmUXchcwEU4a14IJG74Heai4aAZjTjEUyhZEiUA893
         vptrSREgSD4ohsZbQqDVBhVLcf7vUnnHuDs086aV+PO2Gi2/8dK16dOO11TrE5qhgWqZ
         wAo/fxGbolL19my4eUWkxjpcJt62IXn1C3g6B8VStYJCt3vFG4HEDDJZXekHMCWuUKFI
         2hwkVa2Uf+YjOJDGXRCioX7efS5jrshMDhczZtKSkaRpQXqGkRpL6/Sr/GqRoxL1P6e8
         w5Eg==
X-Gm-Message-State: AOJu0Ywcd0LZ/KH/S4W7BDyakQdcpesO0A4PYBx9uX5DDKbCc3/JT8J7
	D3JSscn6/w2LKeAjwyBs7J0NDQFa/4M1uw2AOz/Td97DH2Ygby9j+hqrvPTn1SmX+2IfmEL0Gle
	oY7tT2TYVvZ6cw43U/OjBKcNXiYhKBLQ=
X-Gm-Gg: AR+sD13BvMb80n+QmJf+uZZhY08LIZE7iFGsUFJUVDUO0auVvs9I45347W8gFbHjRIM
	I0RiFwqp73YZ5FSkmj1AiwxqfwoqKj1/55jJaFjB8c+a6QlNLa4Amu5wPYy7OWTem/OtC6UoLmn
	ew0Z+a5IeCznAbLXB3bytJOnEMOv93KWG1rSkTmzXv0b1GgpvePbRkxvcGvJBYPn6UjyEcPZomm
	vdx76bpDM5YiwgUhpnzfQlAXNnjd7yihReV58Z7G9iR7oaTGoU/oNi3r49cXaC8EdGq1E9YTZKx
	8Lt2lkqkjED8pnu0IYbV6Nl/t85byOIUUzp42WsY1SfaW0K2mXbda5JMcZGgUXrSppfsWs71GIu
	h
X-Received: by 2002:a53:b543:0:b0:667:e04a:8a3f with SMTP id
 956f58d0204a3-6699a919d86mr969713d50.5.1785879655484; Tue, 04 Aug 2026
 14:40:55 -0700 (PDT)
MIME-Version: 1.0
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-2-frediano.ziglio@citrix.com> <1785871743.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099@vates.tech>
In-Reply-To: <1785871743.8631fc262581453bbf619ec5b2062170.19fce4038dd000e099@vates.tech>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 4 Aug 2026 22:40:44 +0100
X-Gm-Features: AUfX_mxHyihNtyDMkBfWJHdz09e80hO9TOwHB81ucSm2D6hWkksFcqiOiVQvCaw
Message-ID: <CAHt6W4caSVXHx-bdNh0WDTk-K0UXTb0pN75NYuCC+A66woo9Vw@mail.gmail.com>
Subject: Re: [PATCH 1/2] CI: Simplify directories creation
To: Anthony PERARD <anthony.perard@vates.tech>
Cc: xen-devel@lists.xenproject.org, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Doug Goldstein <cardoe@cardoe.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ebf023/1785879657-536C2B50-9A16AF3D/0/0
X-purgate-type: clean
X-purgate-size: 2001

On Tue, 4 Aug 2026 at 20:29, Anthony PERARD <anthony.perard@vates.tech> wrote:
>
> On Tue, Aug 04, 2026 at 06:42:17PM +0100, Frediano Ziglio wrote:
> > diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
> > index 242ffca693..60f5cc49fc 100755
> > --- a/automation/scripts/qemu-alpine-x86_64.sh
> > +++ b/automation/scripts/qemu-alpine-x86_64.sh
> > @@ -4,16 +4,7 @@ set -ex -o pipefail
> >
> >  # DomU Busybox
> >  cd binaries
> > -mkdir -p initrd
> > -mkdir -p initrd/bin
> > -mkdir -p initrd/sbin
> > -mkdir -p initrd/etc
> > -mkdir -p initrd/dev
> > -mkdir -p initrd/proc
> > -mkdir -p initrd/sys
> > -mkdir -p initrd/lib
> > -mkdir -p initrd/var
> > -mkdir -p initrd/mnt
> > +mkdir -p initrd/{bin,sbin,etc,dev,proc,sys,lib,var,mnt}
>
> This makes it really hard to find out if more directory or less
> directory are been created. When reviewing a patch, we don't see what
> changed in a line without using more complex tools.
>
> For this patch, I have now idea at a glimpse if all the directory that
> was created before are still created.
>
> In the future, we might need to create more directories, this would
> change on very long line to another, and make it hard to find out what
> was the logical change, by just looking at the output of `diff -u`.
>
> So I don't see this patch as an improvement.
>
> But that just my opinion, but that would apply equally to other similar
> changes, like packing all the variable declaration on a single line in C.
>
> Cheers,
>

Hi,
   what about putting the directory names in alphabetical order?
Either in multiline or in the concise single line?
In both cases it makes it easier to check if it's already there.

Or something like

mkdir -p binaries/initrd
cd binaries/initrd
mkdir -p \
        bin \
        dev \
        etc \
        lib \
        mnt \
        proc \
        sbin \
        sys \
        var
cd ..

Regards,
   Frediano


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 21:59:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 21:59:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382660.1625990 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrNA7-0001nQ-3T; Tue, 04 Aug 2026 21:59:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382660.1625990; Tue, 04 Aug 2026 21:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrNA7-0001nJ-0x; Tue, 04 Aug 2026 21:59:03 +0000
Received: by outflank-mailman (input) for mailman id 1382660;
 Tue, 04 Aug 2026 21:59:02 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wrNA6-0001nC-DA
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:59:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrNA4-001qb7-7a
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 23:59:00 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7260a4-2eae-0a2a0a5409dd-0a2a4507d66c-0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:59:00 +0200
Received: from [74.125.224.45] (helo=mail-yx1-f45.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7260a3-b4ea-0a2a45070019-4a7de02de46f-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:58:59 +0200
Received: by mail-yx1-f45.google.com with SMTP id
 956f58d0204a3-664ce3000e6so295227d50.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:58:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1785880738; cv=none;
        d=google.com; s=arc-20260327;
        b=ocwEMswJr5/W5jBxixVcX9Vd3b+FhPofoJmEYAiNFQyfGRTh71cegqBR45pfB2aCbs
         Yd3DF+y0uLpYGPXvTnKifMd9Fe2kc1JtpS7lLwflnPcIX9RA8MI+lzmOA6Tb90xqCAyV
         WgwG1dfgZJR6FjsU3ze5MxjQlJccsPpLzD+7aUIpzemPbJQGA69CR4mWAaIIK56JwFoh
         4ym3GMqE14g5gnjiCz9F3Xrrj7kl9XQjDa5TxX7fVx6SOFNVdV2nn3kfQB5Ir4Hx7Q6Q
         pObIl98p/v/FWdGauZbou7ik/vl/wH2k5d3orixcKi3tghSLzp3s1W2dbyCocSEmUmVy
         oFQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=rVNb0qH2KaqSSA1wdzQ35ti5zCobKv53Fc4eqYo5Z2E=;
        fh=S7vaYQF6ldLkXu1uh42X3MXXcRRChuuDlJZSyF3Eswo=;
        b=npzm6QPk7iYEhS0tnki6E4Y6MwXEiwYqwRdGk+cLPOETYv8A8SiqhxfPcM7woiBfE5
         Kbh7ovsCXSd96EgC6Gxy9eWTaEmEhXBpv35PQxXdCkjFoDI6VEcZcoYZd5PmSH2+pGDu
         29phw1nsS4oRPsuKpr27YZ7s0xnujt9vKfXrhCkS534e+nlMlPW12NP8yKQB9sMKba+Q
         oS5oGT6Lc/heUAm19s3zI5qr5mxUKOcEVVwS331OUSF4TYRFq9/nF+vWvXC0Z+Pkvjks
         o5NTaYxss+v3APe5k+gjT8R+RU0jqs3LoCOJdCGl3z4rUcQjUnAyo2f5puJtdWYme+yZ
         p7IQ==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785880738; x=1786485538; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=rVNb0qH2KaqSSA1wdzQ35ti5zCobKv53Fc4eqYo5Z2E=;
        b=lGryzvdd4RipRBZWPyiGBo7dA+b13Z21+Rpdy/LqRqPp5JP+txPJNrPXVnMC6ZCrMf
         lTlqcTy9bdmE9m6vqPXrkFzFYkUcCvc7wuTDL+caPznj2YgjfXDntY1YFmzddkn21xAx
         uyWlnhYkyC4uxEO1XyxvKt2hp5OqL/BL0ytmEROhvnjQ9SBDM2yIg2p8z2+5J6fx/o5/
         qEgu6fmx5a7DSXyV4qRAM5RBRPskeyJx4gqjrvmoa/h3lSYl6lSDEjcpY83RkJSSzvfL
         HfGEEjoDWXDSloBwycLjQtS4EHEUKk3eT7mY+RRC5/BqkJQyIhCxAGxqd5YSlBvk+NHY
         rdIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785880738; x=1786485538;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=rVNb0qH2KaqSSA1wdzQ35ti5zCobKv53Fc4eqYo5Z2E=;
        b=LOSV7/4rwDsR5Q2QPFtCwp0uJMbWcdEk2aki25pVcoEKU2FYKr/d+zZRVRW27C5pEm
         1vLubSNTxL38UcWVRxnEhmQfTFdpXTozXI/UvFjkVgjUcl+iyYGuctInrteAVXklL677
         svJz6rDeiSmKl+D4p82+gNXxrYOBGi1bw1fHJqjuVjDZXU0Xd7xWBPTl4MivT5cQbNvU
         VXzB3c+YiVr4+49EmJWAIxFaUplzek76xlsPBu7gTYM6drnmJJtRH1rKAD+11vnkeOY1
         RcnsfwuvhPr2ssbeCYeY1fa9Xss4SFPPUUBZG2aKFPAM4KxK9SJRd0KxePsILm7q2rSs
         C8GA==
X-Forwarded-Encrypted: i=1; AHgh+RrK1gTr2+xfklulqeShPslptjub+h9S24WhwEATbux6rXUhNzLZ397TB8sGzejQzYVKmWEwKvigGos=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJ3GwHYjinGC59vD8ic0AiMzWJJIU0Phi57lp0F1oHt70999Yp
	oZp/OYzEwPVL9lWYYhi+hUv44vLNZ90e9R8lR7ijYdTTtrdJlL7+MSRZV6o1hn19S9kKxSKbWau
	MEl2km1+SbYuRXqBJh3PUtmnRitFfRFA=
X-Gm-Gg: AR+sD123g1DZ4DR9fcjTs71xkvjwAFnnMYuomTDvQbY3xb1twfxbRvP0YB/KJWTyOTC
	JEW/vg77W5cQP6c5sCI1gkyFE+0q1VD+7pgxWHW/bHTkXZHir2WQAbGfl2SECStHwAEPFuQkEdi
	Q1o07Ehud2HPehwHHG54EMJvU8NTCFzEIiRuMUmUJVyIQtItX3qWIhRaXtpM1jsZK59PDyyNEOz
	/yKaOyJz5xVOctYnbQihIotYTFvSsVTUl6MAEADVVCMS+eevas/NWBSebhmhzQfp2fbsB7uTmry
	D4IVCmpxAJg4VfniMH987VzbymFgz2aZCv9TW4JKJaZX06AWi/fVRc3OieziA/6G7u+Nh3ygjwC
	sHyqJpjKXI3s=
X-Received: by 2002:a05:690e:454b:20b0:667:be4a:4b5f with SMTP id
 956f58d0204a3-6699aa26209mr991834d50.15.1785880738304; Tue, 04 Aug 2026
 14:58:58 -0700 (PDT)
MIME-Version: 1.0
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-3-frediano.ziglio@citrix.com> <anIn7VAt2oQJ90Js@mail-itl>
 <CAHt6W4eCdqp2NDzjHyQ9vdezJkjVyxTwJH7HuReVxVSihox0Rw@mail.gmail.com>
 <9dc1d91c-52e2-4cd9-a234-6d6ca6ecceb8@citrix.com> <anI6zLWzX8kDi7oC@mail-itl>
In-Reply-To: <anI6zLWzX8kDi7oC@mail-itl>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Tue, 4 Aug 2026 22:58:47 +0100
X-Gm-Features: AUfX_mzb93PcOca-QY5WJwRP4CkmwxCGy172nhyS-381muC9Oe8YoQ9qKC2mPWE
Message-ID: <CAHt6W4enqcBQwEzq3w4PyzfUOnfveFa=KGbGfYK92nspf6eH9g@mail.gmail.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of qemu-alpine-x86_64
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Doug Goldstein <cardoe@cardoe.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Jan Beulich <jbeulich@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-ef75cf/1785880740-34AC8AE4-AFEBA6B6/0/0
X-purgate-type: clean
X-purgate-size: 5514

On Tue, 4 Aug 2026 at 20:17, Marek Marczykowski-G=C3=B3recki
<marmarek@invisiblethingslab.com> wrote:
>
> On Tue, Aug 04, 2026 at 07:55:24PM +0100, Andrew Cooper wrote:
> > On 04/08/2026 7:48 pm, Frediano Ziglio wrote:
> > > On Tue, 4 Aug 2026 at 18:57, Marek Marczykowski-G=C3=B3recki
> > > <marmarek@invisiblethingslab.com> wrote:
> > >> On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
> > >>> Make sure that save/restore continue to work.
> > >>> The check save and restore twice to check for corrupted status.
> > >>> Also a command is launched in the guest to make sure that the
> > >>> machine is not crashed but working.
> > >>>
> > >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> > >>> ---
> > >>>  automation/scripts/console.exp           |  8 +++++
> > >>>  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++++=
++--
> > >>>  2 files changed, 46 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/automation/scripts/console.exp b/automation/scripts/co=
nsole.exp
> > >>> index e27886bbef..ff58ed29b8 100755
> > >>> --- a/automation/scripts/console.exp
> > >>> +++ b/automation/scripts/console.exp
> > >>> @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
> > >>>      system "$env(WAKEUP_CMD)"
> > >>>  }
> > >>>
> > >>> +if {[info exists env(EXPECT_TEXTS)]} {
> > >>> +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
> > >>> +    foreach {exp snd} $lines {
> > >>> +        expect -re "$exp"
> > >>> +        send "$snd\n"
> > >>> +    }
> > >>> +}
> > >>> +
> > >>>  if {[info exists env(LOG_MSG)]} {
> > >>>      expect {
> > >>>          -notransfer -re "$env(PASSED)" {
> > >>> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/=
scripts/qemu-alpine-x86_64.sh
> > >>> index 60f5cc49fc..409a601c34 100755
> > >>> --- a/automation/scripts/qemu-alpine-x86_64.sh
> > >>> +++ b/automation/scripts/qemu-alpine-x86_64.sh
> > >>> @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
> > >>>
> > >>>  " > etc/local.d/xen.start
> > >>>  chmod +x etc/local.d/xen.start
> > >>> +
> > >>> +# Script to test save and restore.
> > >>> +# It saves and restores domU domain twice to check if the domain w=
as corrupted
> > >>> +# during the first sequence.
> > >>> +# At the end open the console to check if the domain is working.
> > >>> +cat > root/save_restore_test << "EOF"
> > >>> +#!/bin/sh
> > >>> +set -ex
> > >>> +xl list | grep -q domU
> > >>> +rm -f save.dat
> > >>> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat =
/root/domU.cfg
> > >>> +xl restore /root/domU.cfg save.dat
> > >>> +xl list | grep -q domU
> > >>> +rm -f save.dat
> > >>> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.dat =
/root/domU.cfg
> > >>> +xl restore /root/domU.cfg save.dat
> > >>> +xl list | grep -q domU
> > >>> +rm -f save.dat
> > >>> +xl console "$(xl list | awk '$1=3D=3D"domU" { print $2 }')"
> > >>> +EOF
> > >>> +chmod +x root/save_restore_test
> > >>> +
> > >>>  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
> > >>>  cd ../..
> > >>>
> > >>> @@ -70,9 +92,23 @@ export TEST_CMD=3D"qemu-system-x86_64 \
> > >>>      -device virtio-net-pci,netdev=3Dn0 \
> > >>>      -netdev user,id=3Dn0,tftp=3Dbinaries,bootfile=3D/pxelinux.0"
> > >>>
> > >>> +# Sequence of expect/send strings:
> > >>> +# 1. wait domain start and close console;
> > >>> +# 2. wait login prompt and login as root
> > >>> +# 3. wait login and launch save/restore test;
> > >>> +# 4. wait restore from domain console and send a command.
> > >> Why doing this interactively over serial, instead of adding to
> > >> etc/local.d/xen.start and then printing test result at the end?
> > >>
> > > I'm using expect to interact with the console. expect is not availabl=
e
> > > inside the alpine root filesystem.
> > > Some failure I had during migration is that the VM crashed. In the
> > > script I interact with the console to check that the VM is still able
> > > to run commands.
> >
> > We can add `expect` to the dom0 root filesystem if we find a need for
> > it, and it looks like this might be a good enough reason.  You want a
> > patch to https://gitlab.com/xen-project/hardware/test-artifacts
> > images/alpine/*-x86_64-base.dockerfile to get it included.
>
> FWIW, my suspend test (which tests a similar thing) uses ping to check
> if domU is still alive:
> https://gitlab.com/xen-project/people/marmarek/xen/-/blob/2184be51d426b60=
f5e1a7e6e891d0f40e9488fc7/automation/scripts/qemu-alpine-domU-suspend-x86_6=
4.sh
>

Are you going to upstream the test?
Why sleep between commands? Worrying about possible races? Probably
there should be no race after the command exited so I personally would
remove.

Using the network seems like a good idea. I also discovered that there
is nc and bash installed so something like

    # nc -lk -p 8888 -e sh -c "echo Still alive"

and

    # bash -c 'read -t 1 line < /dev/tcp/localhost/8888; echo $line'
    Still alive

would even test if userspace is still working correctly

>
> > But, for migration testing, this really wants to run on the real
> > hardware.  Besides the main memory image, there's variations in registe=
r
> > state and validity which will vary between hardware.
>

Which scripts/jobs are run on real hardware (well, I suppose all that
starts with zen, kbl, xilink or adl). Are they all run for every
build?
--
Frediano


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 21:59:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 21:59:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382661.1626000 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrNAG-00022P-A8; Tue, 04 Aug 2026 21:59:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382661.1626000; Tue, 04 Aug 2026 21:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrNAG-00022H-7M; Tue, 04 Aug 2026 21:59:12 +0000
Received: by outflank-mailman (input) for mailman id 1382661;
 Tue, 04 Aug 2026 21:59:11 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3q2ByagYKCZACyu73w08805y.w86Hy7-xyFy552CDC.Hy79B83ywD.8B0@flex--seanjc.bounces.google.com>)
 id 1wrNAE-00021L-Uk
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:59:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrNAE-00CrRL-00
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 23:59:10 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3q2ByagYKCZACyu73w08805y.w86Hy7-xyFy552CDC.Hy79B83ywD.8B0@flex--seanjc.bounces.google.com>)
 id 6a726056-bab6-0a2a0a5309dd-0a2a4504cbb2-18
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:59:09 +0200
Received: from [209.85.215.200] (helo=mail-pg1-f200.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3q2ByagYKCZACyu73w08805y.w86Hy7-xyFy552CDC.Hy79B83ywD.8B0@flex--seanjc.bounces.google.com>)
 id 6a7260ac-b57f-0a2a45040019-d155d7c8d157-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:59:09 +0200
Received: by mail-pg1-f200.google.com with SMTP id
 41be03b00d2f7-ca7c1e22995so319660a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:59:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1785880748; x=1786485548; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Dhc7N1hQKet78fMxmoZ11biZ2HS+JiXgm3DEUzu8sT0=;
        b=GZlmgCQRiP6KXQ+vgOxzCfmpjphw57dNbEy14zZh2DGlqG1cuL2aWgJ+yYOjdict+C
         PvSKSWPHOByZPyZ1iluCRTj5Kme8SwkWq0T4ZWOqxc/bMVlDp+iR7oUYIGPe/zrMnKNN
         6zmoQpcf9ZrBgu+bVW0Pbh8dOMJ2ZO/rbWTd8WjSLQyqWi7lefwJXxAj4vDnygjIHgvT
         w/NsqlamcssEibwoKhGE3+Mo/B3Pe4DmpvBypAoUDHqlbXEUanC+QLESYYV34D8iYfJS
         VB4/jhNgC4GwmnJuE5IS9YPugihkZrNpa8tgVxs4fL1BBSRVuDxiF1g/JtA6kHeSluur
         nL7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785880748; x=1786485548;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Dhc7N1hQKet78fMxmoZ11biZ2HS+JiXgm3DEUzu8sT0=;
        b=q8gLO3QgAMiQ0Bh+rrFpw7wovGISnZANjd0eqEqGpzluIiNnc1p3ueMcdo2IvGSIcP
         QLJgLUZa/bxSl0qriAXm5yyLAh/ASbG8MxLbZHvNzdkbl4ZMKdM91GlMoKexdLxBMny6
         Mj/t7Hkh9XKaPe57ne0lRBdQXf2bfxxBL2ogJDFg/3sOtg6cV8tQHClEE+JsNSQplagE
         /bAKtMZPhcQQrLNdUXkgT5MwgP9bT0kA4djJVZBqqhvv7lGt2mGVpYei7byW+u2eYKos
         leWkG1rWE2jyP/u1FVOJHBfAToUZ1k/eIjEvpW/Odjg19gpXTTduioiZUHrkOzdvcpkv
         RjmA==
X-Forwarded-Encrypted: i=1; AHgh+RqAFgfTLFt2F3KezkR9IRkUNwmPHtBl0bU18XkTcLHiQmvBrpAbHwdhYLgC67InEX40vnBUjHtuO3g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQyeh6Q9IXBlCTpfklPWNdbWfalFnIYoQmd+I59UTUEzeqjTOo
	bVwHar7Zz0eFEFOCGIyudbj+bQZC+7TNhOtPtyjln1ZTTQqryzLrUkHj/tbdg1UMPg0u7CV8Feq
	W8ikSOg==
X-Received: from pgbdv13.prod.google.com ([2002:a05:6a02:446d:b0:c9a:3646:2398])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:998c:b0:3ba:cd5b:3dc8
 with SMTP id adf61e73a8af0-3cb8603af30mr1757125637.31.1785880747446; Tue, 04
 Aug 2026 14:59:07 -0700 (PDT)
Date: Tue, 4 Aug 2026 14:59:06 -0700
In-Reply-To: <anE4GtMa33nz7qdK@google.com>
Mime-Version: 1.0
References: <178552799129.2700794.10181439022561913222.b4-ty@google.com>
 <8b90851f38ef5b10cdcdc70e7543bd6b0b5e2773.camel@infradead.org> <anE4GtMa33nz7qdK@google.com>
Message-ID: <anJgqpOJGPjLAqYe@google.com>
Subject: Re: [PATCH v6 00/36] Cleaning up the KVM clock mess
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-ebf023/1785880749-524CBB50-55F4180F/0/0
X-purgate-type: clean
X-purgate-size: 1049

On Mon, Aug 03, 2026, Sean Christopherson wrote:
> On Sat, Aug 01, 2026, David Woodhouse wrote:
> > On Fri, 2026-07-31 at 13:09 -0700, Sean Christopherson wrote:
> > > Applied patch 1 to kvm-x86 clocks.
> > >
> > > [01/36] KVM: x86/xen: Do not corrupt KVM clock in kvm_xen_shared_info_init()
> > >         https://github.com/kvm-x86/linux/commit/3d4b20b5a7df
> > 
> > Thanks. Could the clocks branch be based on something that includes the
> > timekeeping work from the timers-ptp-2026-06-13 merge (in v7.2-rc1)?
> 
> Yeah, I can rebase onto a 7.2-rcN.  Y'all are likely the only people that care
> about the above commit, so a late rebase isn't a big deal.
> 
> There's basically zero chance I'll get the entire series applied for 7.3, but
> "Use ktime_get_snapshot_id() for master clock" is at least in striking distance,
> so there's no reason not to allow for the possibility.

New hash:

[1/1] KVM: x86/xen: Do not corrupt KVM clock in kvm_xen_shared_info_init()
      https://github.com/kvm-x86/linux/commit/633d7652f80f


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 22:44:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 22:44:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382680.1626010 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrNrX-0000eT-Ph; Tue, 04 Aug 2026 22:43:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382680.1626010; Tue, 04 Aug 2026 22:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrNrX-0000eM-L7; Tue, 04 Aug 2026 22:43:55 +0000
Received: by outflank-mailman (input) for mailman id 1382680;
 Tue, 04 Aug 2026 22:43:54 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrNrW-0000eG-HY
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 22:43:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrNrU-001w5C-Lw
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 00:43:53 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a726b1d-5cb7-0a2a0a5109dd-0a2a450882c6-10
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 00:43:52 +0200
Received: from [103.168.172.157] (helo=fhigh-a6-smtp.messagingengine.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a726b26-f659-0a2a45080019-67a8ac9db42f-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 00:43:51 +0200
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 71EA214000ED;
 Tue,  4 Aug 2026 18:43:50 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Tue, 04 Aug 2026 18:43:50 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 4 Aug 2026 18:43:48 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1785883430;
	 x=1785969830; bh=PBhPzA2xvYXBdzZGUAFISn9I3/g+BWXV5uO0PtXXq9g=; b=
	SzCu0Upv6WNBaN9gpFyLomh8ZtqoSP0Ow5OwA6dVxgg/2u2TXQqrcSah9OqPgZSz
	Le0P21RChZI1hVNDF+hxO+1GPNDYP8f8+r8fspubCu5jlgk0K2D/RQcEOHlnvVE7
	MEU3bkTSVGQ88iulAD6tROVIP0eStmQFxta0DyuO5wo60gpV/raIFyxJa6obQyt5
	WF3EHOAInLKcRLiBhjjZLKNX8sN2e8NSBx711pSnhgZHHyLyBXG1ychQWu9iqWvH
	k0vSD8e44l3ON7ggeScmhd3id5qM1GrUqCmMtRBBYjO5CtXOfs13nda7jsp7qxQm
	jOj0pE21kcOOtkK/JcX4eA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1785883430; x=1785969830; bh=PBhPzA2xvYXBdzZGUAFISn9I3/g+BWXV5uO
	0PtXXq9g=; b=eLpaMKTwaDRi72weq/KQQ3cwRTvYsqhRVYIM7JZwqHl3wGIcMwv
	eR3p1XaP6xqJ+5v/WV+cAUY6+CNE5TA4mjJa3bQatEOdFkBOdnVYTOggl60MIYko
	qH0NKMY6PkxYcEOfCbnAFIsHOAtUuH0byXmTcWpWM9pgpA7ICa+nkJVh+vE7y/yD
	YqnFSr3P5M2PlZ6ls/vhQhs35biIcwTwI0rk1WMjK/tY25HujSYD0DT8D6NTVkUz
	4qDCpxMN0aCwf72DIKGn+F40MtU+j42E2zzRU0734TvCQOVcCgl5IQ3fzHRo/A4i
	vZahCw79VB5GkpVZSSZna5xkyMz2scAValw==
X-ME-Sender: <xms:Jmtyambwps3niato23dDY6Zv7e0HhCwqMrIJue2oJ1shVFHFTRLrEA>
    <xme:JmtyaroD5pyJDqIB_JnUtUT0HTkWZD6rUTrpuoBdvhTkR9TnQ_KhB9_-lNjGi4CtQ
    4raP7bYKm_OD7HzG96z5nmSD0wGyJ81NvT9g5uMYqP85wTNpf8>
X-ME-Received: <xmr:JmtyajOOBByPixnWCBCi472lwJx6y-VikbYOUR7JiSKah45tuvl4Oc5oIfi4TGquEFRSM1vBT0JfWTfXIUqmv1HchtptN__SzpU>
X-ME-Proxy-Cause: dmFkZTGpO0qsetRC26UsHWYpTodxhX3ZapQLjdNWY4FX1lbwq3qXfQfO90ne/DfjimpOGF
    xEwN/cIW+oGV9janrS44GhAZhmmbHuMUhPwv1H5hyWbefB7WedltbR92AgzCy4L3IOMGKZ
    3/nj6ZO7Lqh2slbOH5OXawjn5xAio7Msasl5+tpGzP4udQQwva0cK7jvS4N1pW+1PadOGl
    QMOUhKEsVSq4b5+iuWXAHzwXr4BI6TAhieCXnKR/JtoJ0WWeqr8tCa2zicIL4V6AmKC6D7
    PcUtd+vzoYotoIq48t/Bl+Mn/a19HW/BEM8OXTHpB4fLWoS4A3KKwqHY4P0mT7BwhXYxNn
    nmQcGeBVBPkOwg4HyFrBzbu0ZiYGL1YMGB0d1jL1G4KMcI4QisyCOVcMRGidWdJbVo2RrL
    xwn0n3dNCYcTpm5GnB5HHH3qO5gbDEJ72zQp2Deia/42QCnDyvlXecaM9GC0Y7mwV6KzjF
    srfOwOC7x93jzFA3biMO19H+zB++TMT5Lvl/seA4aVDNwQCZ6W4GRZXu0sf/oneuh+oV9/
    OwQoRji45DMVcNxjIBSEYF3LI+bIkD2cxlDoHY7rTw7V9o5ozZxUieAdv0r/UdorOWQaow
    SdmguRWZ57TCKjgxb2wsRnRDK9oqI9Uq2Igf+zuhNgIh8ojuM+FZgGQzhFOw
X-ME-Proxy: <xmx:JmtyaurLZeUI75lrKE1vLcedZb6bhBqqiedaYvKdRlyb9yR9wLze8g>
    <xmx:Jmtyagfj-FAIb_hAzL85LvcarIRDbyWr-m2YPPP6KZQXAomMcs-ppg>
    <xmx:JmtyasRTssR7l7gLx5VWjNhRfJSwGC7PaNllbwat-pvbTKO6DZ2Zjw>
    <xmx:JmtyahYeupvuhPAo-UPOeVSjEWNn8Hxl3GorckrcfFfDuQ038_lfwg>
    <xmx:JmtyamjnaDcphCufIx6oFtOpfBVNr8Vn29tNPOnJJ2XmekZ69PHEVrch>
Feedback-ID: i1568416f:Fastmail
Date: Wed, 5 Aug 2026 00:43:46 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64
Message-ID: <anJrIkkkPqY1bg1J@mail-itl>
References: <20260804174219.835096-1-frediano.ziglio@citrix.com>
 <20260804174219.835096-3-frediano.ziglio@citrix.com>
 <anIn7VAt2oQJ90Js@mail-itl>
 <CAHt6W4eCdqp2NDzjHyQ9vdezJkjVyxTwJH7HuReVxVSihox0Rw@mail.gmail.com>
 <9dc1d91c-52e2-4cd9-a234-6d6ca6ecceb8@citrix.com>
 <anI6zLWzX8kDi7oC@mail-itl>
 <CAHt6W4enqcBQwEzq3w4PyzfUOnfveFa=KGbGfYK92nspf6eH9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="PkvxQL4DZhCcODI5"
Content-Disposition: inline
In-Reply-To: <CAHt6W4enqcBQwEzq3w4PyzfUOnfveFa=KGbGfYK92nspf6eH9g@mail.gmail.com>
X-purgate-ID: tlsNG-c1860d/1785883432-D7B5987B-E0D1FDAD/0/0
X-purgate-type: clean
X-purgate-size: 7789

--PkvxQL4DZhCcODI5
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 5 Aug 2026 00:43:46 +0200
From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= <marmarek@invisiblethingslab.com>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 2/2] CI: Check save/restore of PV domain as part of
 qemu-alpine-x86_64

On Tue, Aug 04, 2026 at 10:58:47PM +0100, Frediano Ziglio wrote:
> On Tue, 4 Aug 2026 at 20:17, Marek Marczykowski-G=C3=B3recki
> <marmarek@invisiblethingslab.com> wrote:
> >
> > On Tue, Aug 04, 2026 at 07:55:24PM +0100, Andrew Cooper wrote:
> > > On 04/08/2026 7:48 pm, Frediano Ziglio wrote:
> > > > On Tue, 4 Aug 2026 at 18:57, Marek Marczykowski-G=C3=B3recki
> > > > <marmarek@invisiblethingslab.com> wrote:
> > > >> On Tue, Aug 04, 2026 at 06:42:18PM +0100, Frediano Ziglio wrote:
> > > >>> Make sure that save/restore continue to work.
> > > >>> The check save and restore twice to check for corrupted status.
> > > >>> Also a command is launched in the guest to make sure that the
> > > >>> machine is not crashed but working.
> > > >>>
> > > >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> > > >>> ---
> > > >>>  automation/scripts/console.exp           |  8 +++++
> > > >>>  automation/scripts/qemu-alpine-x86_64.sh | 40 ++++++++++++++++++=
++++--
> > > >>>  2 files changed, 46 insertions(+), 2 deletions(-)
> > > >>>
> > > >>> diff --git a/automation/scripts/console.exp b/automation/scripts/=
console.exp
> > > >>> index e27886bbef..ff58ed29b8 100755
> > > >>> --- a/automation/scripts/console.exp
> > > >>> +++ b/automation/scripts/console.exp
> > > >>> @@ -58,6 +58,14 @@ if {[info exists env(WAKEUP_CMD)]} {
> > > >>>      system "$env(WAKEUP_CMD)"
> > > >>>  }
> > > >>>
> > > >>> +if {[info exists env(EXPECT_TEXTS)]} {
> > > >>> +    set lines [split "$env(EXPECT_TEXTS)" "\n"]
> > > >>> +    foreach {exp snd} $lines {
> > > >>> +        expect -re "$exp"
> > > >>> +        send "$snd\n"
> > > >>> +    }
> > > >>> +}
> > > >>> +
> > > >>>  if {[info exists env(LOG_MSG)]} {
> > > >>>      expect {
> > > >>>          -notransfer -re "$env(PASSED)" {
> > > >>> diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automatio=
n/scripts/qemu-alpine-x86_64.sh
> > > >>> index 60f5cc49fc..409a601c34 100755
> > > >>> --- a/automation/scripts/qemu-alpine-x86_64.sh
> > > >>> +++ b/automation/scripts/qemu-alpine-x86_64.sh
> > > >>> @@ -48,6 +48,28 @@ xl -vvv create -c /root/domU.cfg
> > > >>>
> > > >>>  " > etc/local.d/xen.start
> > > >>>  chmod +x etc/local.d/xen.start
> > > >>> +
> > > >>> +# Script to test save and restore.
> > > >>> +# It saves and restores domU domain twice to check if the domain=
 was corrupted
> > > >>> +# during the first sequence.
> > > >>> +# At the end open the console to check if the domain is working.
> > > >>> +cat > root/save_restore_test << "EOF"
> > > >>> +#!/bin/sh
> > > >>> +set -ex
> > > >>> +xl list | grep -q domU
> > > >>> +rm -f save.dat
> > > >>> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.da=
t /root/domU.cfg
> > > >>> +xl restore /root/domU.cfg save.dat
> > > >>> +xl list | grep -q domU
> > > >>> +rm -f save.dat
> > > >>> +xl save "$(xl list | awk '$1=3D=3D"domU" { print $2 }')" save.da=
t /root/domU.cfg
> > > >>> +xl restore /root/domU.cfg save.dat
> > > >>> +xl list | grep -q domU
> > > >>> +rm -f save.dat
> > > >>> +xl console "$(xl list | awk '$1=3D=3D"domU" { print $2 }')"
> > > >>> +EOF
> > > >>> +chmod +x root/save_restore_test
> > > >>> +
> > > >>>  find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
> > > >>>  cd ../..
> > > >>>
> > > >>> @@ -70,9 +92,23 @@ export TEST_CMD=3D"qemu-system-x86_64 \
> > > >>>      -device virtio-net-pci,netdev=3Dn0 \
> > > >>>      -netdev user,id=3Dn0,tftp=3Dbinaries,bootfile=3D/pxelinux.0"
> > > >>>
> > > >>> +# Sequence of expect/send strings:
> > > >>> +# 1. wait domain start and close console;
> > > >>> +# 2. wait login prompt and login as root
> > > >>> +# 3. wait login and launch save/restore test;
> > > >>> +# 4. wait restore from domain console and send a command.
> > > >> Why doing this interactively over serial, instead of adding to
> > > >> etc/local.d/xen.start and then printing test result at the end?
> > > >>
> > > > I'm using expect to interact with the console. expect is not availa=
ble
> > > > inside the alpine root filesystem.
> > > > Some failure I had during migration is that the VM crashed. In the
> > > > script I interact with the console to check that the VM is still ab=
le
> > > > to run commands.
> > >
> > > We can add `expect` to the dom0 root filesystem if we find a need for
> > > it, and it looks like this might be a good enough reason.  You want a
> > > patch to https://gitlab.com/xen-project/hardware/test-artifacts
> > > images/alpine/*-x86_64-base.dockerfile to get it included.
> >
> > FWIW, my suspend test (which tests a similar thing) uses ping to check
> > if domU is still alive:
> > https://gitlab.com/xen-project/people/marmarek/xen/-/blob/2184be51d426b=
60f5e1a7e6e891d0f40e9488fc7/automation/scripts/qemu-alpine-domU-suspend-x86=
_64.sh
> >
>=20
> Are you going to upstream the test?

Yes, this branch (including a few more tests) waits for the other series
to test-artifacts (already acked) to be pushed. Otherwise, it needs a
hack with switching to alternative repos to work...
I guess I can post it anyway, just with a disclaimer about pushing
order...

> Why sleep between commands? Worrying about possible races? Probably
> there should be no race after the command exited so I personally would
> remove.

To cover also cases where crash happens only a moment later, not in the
very second it's resumed. I had also a case where only one vcpu crashed,
but otherwise domU appeared functional (this I solved with oops=3Dpanic on
kernel cmdline, added in an earlier commit).

> Using the network seems like a good idea. I also discovered that there
> is nc and bash installed so something like
>=20
>     # nc -lk -p 8888 -e sh -c "echo Still alive"
>=20
> and
>=20
>     # bash -c 'read -t 1 line < /dev/tcp/localhost/8888; echo $line'
>     Still alive
>=20
> would even test if userspace is still working correctly

Looks like a good idea.

> > > But, for migration testing, this really wants to run on the real
> > > hardware.  Besides the main memory image, there's variations in regis=
ter
> > > state and validity which will vary between hardware.
> >
>=20
> Which scripts/jobs are run on real hardware (well, I suppose all that
> starts with zen, kbl, xilink or adl). Are they all run for every
> build?

Yes.

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--PkvxQL4DZhCcODI5
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmpyayIACgkQ24/THMrX
1yzH5wgAmZRzBema58TF1UQ6vJYm2229+7l8+o6tAnn9c2FtTvroOwskei0ZlrHZ
9xs3eaCWVyRIvVWrkl39dXF8CT7lwNa8F1CCJf391DGhwxT5pfwhULi6l6ylW+GM
QpcYn9N3bgEFYdrDxcUeQf+VAOyNcEKutErtaFwb2BIhGbH6iPLQjBuZAm1Np1ZM
GyEgEzKWJN6o4YUJ+NwHUvvV+1c/t+UCVhj9Ac0juGZ519wKOzxrU6XNTwvoW72E
PLpkVL8O+kM4xEk3ICyDoGAkOVUv/W4XJkGyvfA6ut26u05/4gHZYzXvBFzXes3D
TU0fuoxyU5sk57gyL8DtSCK3cCRs6w==
=+wM4
-----END PGP SIGNATURE-----

--PkvxQL4DZhCcODI5--


From xen-devel-bounces@lists.xenproject.org Tue Aug 04 23:38:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Aug 2026 23:38:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382691.1626018 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrOiF-0007QY-HS; Tue, 04 Aug 2026 23:38:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382691.1626018; Tue, 04 Aug 2026 23:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrOiF-0007QR-E0; Tue, 04 Aug 2026 23:38:23 +0000
Received: by outflank-mailman (input) for mailman id 1382691;
 Tue, 04 Aug 2026 23:38:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <36XdyagYKCfwwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 1wrOiE-0007QL-0a
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 23:38:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrOiC-002ejV-4h
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:38:20 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <36XdyagYKCfwwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 6a7277cc-e002-0a2a0a5209dd-0a2a4504d3bc-14
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:38:20 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <36XdyagYKCfwwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 6a7277ea-b57f-0a2a45040019-d155d2c6d0f4-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:38:19 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-8486c3411c8so432403b3a.2
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 16:38:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1785886698; x=1786491498; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=MCQeULnuxyizouUVujp9ZRZMwHTWkFpcMFYeBXRE7J4=;
        b=sYb+VhPgMeKWlobkFKPoJlB0RoNcWw5WMGQzmTEIjs0PvAZG668J1PZAD2XjEUzAbx
         fxy3OSwt63BVb5BJ723myCT9nxtiCjSz7lUi09bg6tT02yjbhkeYQkVXbciDCcnjUBEg
         6e4p1DWCuxB77RDbvybFsMhcF3Gamcb9NTkdBoru/GseYt5FA7Q5I95sDvQ7NWk9+wsH
         CgENSTa0dRvVO9K/yyF+hbt6dRj5XQBV7gV0qjMJcFB/NcST9ABrb19rrbGNx5Se8tN4
         AMjEvyCEcG/kplPqR0Cei3o6baoe8OrO2Ysad/If325tHgte9RIhNEFI8IaJ/fA8VwdA
         ZBiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785886698; x=1786491498;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=MCQeULnuxyizouUVujp9ZRZMwHTWkFpcMFYeBXRE7J4=;
        b=JGPL1G+ive0LS/sx5HVijuswEe0sK1tMzitfR9eNWj7wCPxIiA/k43dNWj6oT20RZY
         cbwipMzhEZkL6kn593/dBbCyAWyKCaRQiV5WqAfEZkf9ae7d775FfZb34k2G8htDfSr/
         kWZYmmG+Up8DV0TeiI0YRfBk1kYxG9Z01lxuhQPJpC3D4jdbbzyAWsx7Q/fLBO7VMHtB
         Rbx6qk6i/aAhq1LqPDOfWVovyXsM8HehJFOrkDYZANM4T1iVmBrUDvrCcCtynxQdacww
         YvYxQT7n/714VRntmfNDwBjj5w0fBA8pZKnvu4+buinoJKmv3z46EA0ZTRIitAEAWPAh
         tyow==
X-Forwarded-Encrypted: i=1; AHgh+Rp0A43ac/WUxOwsaw6gOBNgMkouLk+5TvG5RJBVhSggTkz1yZk9VN1VB5LGn8+QJf4SCfJtpRp8dTc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YytBpQ2fqC/GfWGir/Jh73UnqgJb9uyu1k91L935q53GlnZTxOe
	YG1WSJt/T15d3JXYQ/NEh9nuRwA5FRmMSZJU5kDkkuIPrEOdeJJzsDK3t0EqR7Fz28IHOJsPyHg
	Sj4YK0g==
X-Received: from pgig16.prod.google.com ([2002:a63:f410:0:b0:c92:11a5:bbce])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3a15:b0:84a:60a4:2651
 with SMTP id d2e1a72fcca58-84f2dfc53efmr1961102b3a.6.1785886697620; Tue, 04
 Aug 2026 16:38:17 -0700 (PDT)
Date: Tue, 4 Aug 2026 16:38:17 -0700
In-Reply-To: <d2d98dd31718eb925ae44b0eceb325538a8174ae.camel@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-32-dwmw2@infradead.org>
 <am0upFND1r93HPxq@google.com> <d2d98dd31718eb925ae44b0eceb325538a8174ae.camel@infradead.org>
Message-ID: <anJ36SBzN7HL4A2D@google.com>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-ebf023/1785886699-C0CDFB50-B313748F/0/0
X-purgate-type: clean
X-purgate-size: 1065

On Sat, Aug 01, 2026, David Woodhouse wrote:
> On Fri, 2026-07-31 at 16:24 -0700, Sean Christopherson wrote:
> >=20
> > > +	/*
> > > +	 * Allow for a discrepancy of 1 kHz either way between the TSC
> > > +	 * frequency used to generate the user's pvclock and the current
> > > +	 * host's measured frequency, since they may not precisely match.
> > > +	 */
> > > +	if (user_tsc_hz < curr_tsc_hz - 1000 ||
> > > +	=C2=A0=C2=A0=C2=A0 user_tsc_hz > curr_tsc_hz + 1000) {
> >=20
> > I don't follow, why is KVM restricting what frequency userspace can set=
?
>=20
> Userspace actually sets the frequency with KVM_SET_TSC_KHZ. What KVM is
> insisting upon here is that the input to KVM_SET_CLOCK_GUEST is
> *consistent* with the guest's TSC frequency (within a little slop
> caused by different host TSCs).

Why does KVM care though?  I know some people hate that KVM's uAPI is permi=
ssive
to a fault, but trying to "help" userspace often ends badly for everyone.  =
E.g.
what happens if userspace does KVM_SET_TSC_KHZ after KVM_SET_CLOCK_GUEST?


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 00:07:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 00:07:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382702.1626027 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrP9y-00040f-9S; Wed, 05 Aug 2026 00:07:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382702.1626027; Wed, 05 Aug 2026 00:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrP9y-00040X-6R; Wed, 05 Aug 2026 00:07:02 +0000
Received: by outflank-mailman (input) for mailman id 1382702;
 Wed, 05 Aug 2026 00:07:00 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wrP9w-00040R-73
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 00:07:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrP9v-00AAsM-53
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 02:06:59 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a727e98-2eae-0a2a0a5409dd-0a2a450ce694-6
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:06:58 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a727ea0-f479-0a2a450c0019-aceafc1fe8cc-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:06:57 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id DB19F40AD8;
 Wed,  5 Aug 2026 00:06:55 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38F9A1F00A3D;
 Wed,  5 Aug 2026 00:06:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1785888415;
	bh=fQGXTT1iD4XOXkRDxR3dG4pIjyvECfsrSvRyXf46TZw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=VzgzDjhi9Ja1W5hLt58pREs7AZFSvpvy+GUFRil24u3tV25E8RAAKfLuev7/BOVmP
	 vHrhIqZhEvjxvB+PAVngR+Oc7nuvxKikPu/g+GEGygo4OY3dKClZNCVXwp1HJEleR+
	 vxA09ZFsznPAeqmkWkTOlIEyfzrVBmq3rM33fMghLrZbdudoWcu0Fzdw3HRuXOwX21
	 Goe8hzAwyafEPHVULdX1pg5cN7/3/qGFxy4somCLRZzzRVSSf48H8Le4EmPr1PlG5Y
	 T4jU8POAIlgo2zsnrojq27axy/FhY0EDnxLvcOMc844HsFlT2JPUauNxRn0NyO2qpZ
	 po8godmRCI81g==
Date: Tue, 4 Aug 2026 17:06:53 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Yifei Gao <gyf161023@gmail.com>
cc: Eric Van Hensbergen <ericvh@kernel.org>, 
    Latchesar Ionkov <lucho@ionkov.net>, 
    Dominique Martinet <asmadeus@codewreck.org>, v9fs@lists.linux.dev, 
    Christian Schoenebeck <linux_oss@crudebyte.com>, 
    Juergen Gross <jgross@suse.com>, 
    Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, 
    stable@vger.kernel.org
Subject: Re: [PATCH] 9p/xen: fix refcount leak in p9_xen_response() on wrong
 tag
In-Reply-To: <20260804213550.3409638-1-gyf161023@gmail.com>
Message-ID: <ebcebd30-68e2-1650-f0e6-b69e4239619c@kernel.org>
References: <20260804213550.3409638-1-gyf161023@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-d25034/1785888418-03AD4A5B-1C0A336A/0/0
X-purgate-type: clean
X-purgate-size: 1717

On Tue, 4 Aug 2026, Yifei Gao wrote:
> p9_xen_response() looks up the request for an incoming reply with
> p9_tag_lookup(), which takes a reference on the returned p9_req_t. When
> the tag does not resolve to a request in REQ_STATUS_SENT, the function
> warns and continues the loop without dropping that reference, permanently
> leaking the p9_req_t and its msize buffers. The reply header, including
> the tag, is supplied by the backend, so a malicious or buggy 9P backend
> can leak kernel memory on every crafted response.

Most backend are trusted, including this. So I would avoid "malicious".


> Drop the reference before continuing, mirroring the equivalent path in
> trans_fd.c.
 
It doesn't look like trans_fd.c behaves like this patch?


> Fixes: f66c72bea129 ("xen/9pfs: receive responses")

This should be 728356dedeff

Aside from the above, the code change looks correct

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Yifei Gao <gyf161023@gmail.com>
> ---
>  net/9p/trans_xen.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index f9fb2db7a066..8eea0da8797f 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -203,6 +203,8 @@ static void p9_xen_response(struct work_struct *work)
>  		req = p9_tag_lookup(priv->client, h.tag);
>  		if (!req || req->status != REQ_STATUS_SENT) {
>  			dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag);
> +			if (req)
> +				p9_req_put(priv->client, req);
>  			cons += h.size;
>  			virt_mb();
>  			ring->intf->in_cons = cons;
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 00:27:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 00:27:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382713.1626036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrPTS-0008OT-Pn; Wed, 05 Aug 2026 00:27:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382713.1626036; Wed, 05 Aug 2026 00:27:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrPTS-0008OM-N9; Wed, 05 Aug 2026 00:27:10 +0000
Received: by outflank-mailman (input) for mailman id 1382713;
 Wed, 05 Aug 2026 00:27:09 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wrPTQ-0008OF-Fs
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 00:27:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrPTP-005IWg-Dy
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 02:27:07 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a7282fb-e002-0a2a0a5209dd-0a2a4502b432-30
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:27:06 +0200
Received: from [52.101.125.91]
 (helo=TYVP286CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a728357-6ca4-0a2a45020019-34657d5b7ba0-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:27:05 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by TYCP286MB3435.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:302::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Wed, 5 Aug
 2026 00:26:59 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0270.017; Wed, 5 Aug 2026
 00:26:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=esolb2vq6t57XywXG5KcqiqOkUn1VICFSYPFlFwC2LA/FF0PU0NKYV+k606xZJkIt5AMJ1d/JGYITQpwz2FRRYmBRrsKmuFZ0xWIV9NUceTpH/K5oaGO/a1HnN0lxgPatcWR+u3UBBh5TQBmPIT5ntQ/CJhzkaUJUUwnalhydkzCfMyVL0iy1sqGqHur+MkcZvZOAgn0FiAJyfKyKXT8uTmbAcESP32ictmt0AEl67zR60+EmnJG/oRYXa4bKK/VizkhhIMgxNnX2Q+miIRD//BXpE5g7OWCL2EUsADsZQxcpxYwq014NAQrNt9OnHAxiZAo5jKrETJ8nB3/WTYs9g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VQVNDcQbHIfCeMMPt/2Aw42fIIpin4DpaN8TSJP3ahA=;
 b=LArhckNG8QGOxH49rfjcGkG8dN2CKwMLiM+CFX6AcdG2ZIm8/K9ng6u7U07DzIqlSZIs2F1XiV1kiIVMxTr7FQPMEvP9chUsXHAbxMSLQ9rQ1LZiSmS/bJlrZ80IMPsEDjrl0L/RGu6DKVu6DH+jyo/rJZq+OEXbT5Hv7S7KfDSvmjMfCDrQlHjj+nfqDhGy7RATG3cLI0bMNIzyFvUB3SJ0DbxYREOhUdYG0LwtLANPVotuCeoFwj63BNw6Xd/baZswQrrn45TvLjwNkKDmO/Fw8A6Y4er4cvtFmcHYaadNpI0/H3Kv/j2Lk7dQQlENZ0QKs48WWfbt0K8XjvEQIA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=VQVNDcQbHIfCeMMPt/2Aw42fIIpin4DpaN8TSJP3ahA=;
 b=jh9B9u+St2alfoVDHL8JyVOfMNaS4c9+hIZHks2CRc+B5l2FA5cdedlGaZkAmqOudx6L2Z6d2tK/KD9esNAKAio5WzGC1kuq5elXVUTq6bPFTv5yUQiMZ3PkFsE9tvnegqecICtc7n7/XGXqDV/+hxCAWsal1Q8JAq8a/lFakzU=
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v5 0/4] xen/arm: Device Tree based CPU topology support
Thread-Topic: [PATCH v5 0/4] xen/arm: Device Tree based CPU topology support
Thread-Index: AQHdD+8pDj0XO3cy2kSCxVJYrFPzTbaELD+AgAqVLsA=
Date: Wed, 5 Aug 2026 00:26:59 +0000
Message-ID:
 <OS9P286MB722290CF69591CA6BA3B937F82D32@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
References: <20260709220552.646462-1-taka@valinux.co.jp>
 <07327966-7E81-44CA-A1EA-F227C1C9EA51@arm.com>
In-Reply-To: <07327966-7E81-44CA-A1EA-F227C1C9EA51@arm.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TYCP286MB3435:EE_
x-ms-office365-filtering-correlation-id: f978a03f-c5ea-46c6-a78b-08def288438f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|38070700021|56012099006|4143699003|10067099003|18002099003|22082099003;
x-microsoft-antispam-message-info:
 GU8LUra/Xo+Wk3gHBPN5jFkS/ELuIIGSNHKRfzMKi3dy8BmTEw9W+SmFvF7Yf6ugj5g9z/lFM1Hwe16W2wT4Ln38wjvbEVzy5ltfED4+bU8YWgNOr5yfBD7Xs66o/j9pl2D5yHveJxOzT8jHrSg5HpVno6ky8Y/jvdqBluMUgibxWeV867amnOk7vThpo48Xbtj1gYQFEhs9enQCxfL7K77dTdmeKT8U9XlxPetXqtut1dbgNnTNGi5l41EikhJiY/tY+ck0k7cM7WDWkS8MR8VMAG20i1d7AdLbVPxbRdCxxtP5Rr+axmVQ2efHsCCMvbodhBlY8oZAobLcHVZN8HaSViTvvrj3J4lGoDgf2xuFvO+dkPIvfpysEySHTKMzLQ3nPztqNeJfmWlkESLeD5yxrZlJRBmKWkZ5ubp7jOimstXC4tYLtytoyjMQ3wmqJ0zTuSHuxrEeWFKAOt1dajgZ6dBMzvrAg658w5Bh3VqjFp/sr5lQah73v3Hb8a1zQRHOTcTpPCVLXcJAWZ9ByFqQP75w6D0bpr1Y37qSyoO6hx5NXxIz8WanD4iau3JLlmidby2auz3FTwbOQYSWqoyiMi8sy9eHSekhP34ALJuh9Eko8DtrPVfwNkbNiwAWjBnR0e66DPNizBXlVzKumkceWLPG1L6hV3cR3rMP/V0=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(38070700021)(56012099006)(4143699003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?qdqRQlUW/TH8qXJnoNL7B28qGcyNAdXVJiHtqBg+RP+aXsZD7dyMQt/Txcrt?=
 =?us-ascii?Q?EihGfJ/CwMq8w0I8w+kBZu7BhXZVz4OGiz4KTIoNr1yAOJI1fJTcdytxxMoO?=
 =?us-ascii?Q?u/TcSeLKSGLX70bsW76z539E0HuFn2x5GrPxupTTB3ETzZGA1FWtcxswyn72?=
 =?us-ascii?Q?PyCE2YjmdepAuOVcuDkWCyIQv/5u4WURjZjCkMsezNW8DqKc7CBaMaSCMjYm?=
 =?us-ascii?Q?sAAmQ5cunKMspqBPQyGxiFdhdvIVujDdHEXHiTo2xsfMyuU7XWMy1LyVwNqT?=
 =?us-ascii?Q?0g+UYOq7foVMW7CbXJDzfUagSrW1Ks6MLDZUaKj9hdb58VrTKccZvit9ooEA?=
 =?us-ascii?Q?/LYrWuXuR7X5RXM1NU4o+/6L12xbDYQdH8YVGFXSQ+vfTXKYFqyIS6PvYoTp?=
 =?us-ascii?Q?ETGTwKpgQvTByowu9QkCdsqRmXmDn92gLULh0vg7kMGukIXoDeShZy8W29oE?=
 =?us-ascii?Q?15zE4/yI8AVt0bq5oeH2BeOt9GnvTjhGjvj9FWXbKGZL53uXPf6tzKYvc3cc?=
 =?us-ascii?Q?xGZj+UjpYZ3rTcQf6osYUX7xGM1UX3Qq4LmKIO8V5dYF662WwhLGFusLW4dV?=
 =?us-ascii?Q?3Bu0CNuAk20LxKaD3xcABw3E/hNZ39mpgbEss0hhDSTKSK38xW3HCYKkpc0Z?=
 =?us-ascii?Q?1cWDw4GaYukOkN3vegqhIfhXnFTOcGuerolY2BcvSdR62rjwNAWyu8uHpbiz?=
 =?us-ascii?Q?OfdVaHoNhMVNf33lmHWIekWZj1IcLnij9lGjWWJ55PN0kqfxZDpL2oOLvg52?=
 =?us-ascii?Q?KZRgJNQKuXE+jUqin+PQfI7EFIwPvTyuci2zoXjEr3ELs2nUAbXU2tp9lMdV?=
 =?us-ascii?Q?k4cIgtyNK/2cB/myG4lxVuB8KEhRg/JjqK9feSx/HtUOR/CNe3nHNd1DcBpD?=
 =?us-ascii?Q?+CtG+hGpo2uUT5B7KM3cBChj6cka6gO4diTwdAAoUTLKWk4TNyw1SHUmzWL6?=
 =?us-ascii?Q?XYsBw/RSnJlFOCVxQG2YOYH/osl0q3LWhGDQVKKQepnCDUukoBeJyZpNBJOu?=
 =?us-ascii?Q?dSqd0QSnxkmoprNpFnk4IDK6dXf3d8AJMdDLPnVhDvirHd07zS+vQyC6Pie7?=
 =?us-ascii?Q?PgXR1497oDHnKr1bT5UPndwQnrUSzy/ncLZ2CqPDOU6ga0nrXoxrj5Cktcl7?=
 =?us-ascii?Q?X9fCJbP+Inm3sUIf7fz+wI1II1BZzvJYfzZnBvVxSK3AP3i2t56Xx1uCS4B2?=
 =?us-ascii?Q?mXI0R+dFHwArpCqmDMKp+g9f3XpWFryDOBLDold4JKNKZQMOMZ1NFkZ+6Xp8?=
 =?us-ascii?Q?sfTtrsT8/n+GlmEv6dv4x/6yOGPcrjC87FzPXxKkOEoPOXkTOhPmZhBeaxe9?=
 =?us-ascii?Q?8xzagqHpmtmGY5i52ddmZVe3VojAq42W9p6E5xFHfekKrEvbPgJ4YOLE1Dsc?=
 =?us-ascii?Q?WiiYYs3OzqUqm455RIJnAv0r/l5z8nIULtrXM1yladJ5H2AMKSpKal1DjNTg?=
 =?us-ascii?Q?gk5HLFdENfPN19nHNfvhbY8GOs52gcyiU5amWjI+IfnKWNOogmrw5+cUvXD8?=
 =?us-ascii?Q?nKeY6IP5Da+yEN9mHUvtJSLgv7jLBkDXwHUI7oxSszWffNwHhP/dg7BCULxV?=
 =?us-ascii?Q?AG09HlPGW3yf0gMEvXgneOn6aBzHrtyrIvQnBYBYdiLPrXDTDFgaqQ/59UMP?=
 =?us-ascii?Q?bBdqALEvejyTh5rMr6v+RDOPRGvFnG9fN2gVRFxgnraWCtCbWK+ddNZcMvnO?=
 =?us-ascii?Q?LsWcQ08931GMezdiSSwkKV6k9gDefhaFeHPxUMwKfvOnyUa/?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f978a03f-c5ea-46c6-a78b-08def288438f
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2026 00:26:59.5967
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HGpGs8CsioxzgJG2YnONHamVYg430ui9bbHCkiDkRFUtswFBj7B+IMs0w2WkEmuhMD4yGR4hahtBFyiSKc5byg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB3435
X-purgate-ID: tlsNG-720697/1785889625-F20A82AC-B1588DA5/0/0
X-purgate-type: clean
X-purgate-size: 453

Hi,

> Hi Hirokazu,
>=20
> Please use the add_maintainers.pl script before sending to make sure the =
right maintainers
> are in copy of your patches otherwise some might miss your patches.

Okay, I will make sure to use the add_maintainers.pl script.

> https://xen.readthedocs.io/en/latest/contribute-xen/submit-patch.html#ste=
p-2-use-add-maintainers-pl-or-get-maintainer-pl
>=20
> Cheers
> Bertrand

Thank you,
Hirokazu Takahashi.


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 01:53:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 01:53:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382729.1626044 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQoT-0007Ex-Pr; Wed, 05 Aug 2026 01:52:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382729.1626044; Wed, 05 Aug 2026 01:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQoT-0007Eq-NG; Wed, 05 Aug 2026 01:52:57 +0000
Received: by outflank-mailman (input) for mailman id 1382729;
 Wed, 05 Aug 2026 01:52:56 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrQoS-0007Ek-PD
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:52:56 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoS-0068PF-1k
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:52:56 +0000
Received: from [203.221.94.45] (helo=Mac.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoR-00CujO-2b
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:52:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	Message-ID:Date:Subject:To:From;
	bh=x1Sp3yZQN5Q3kV7fZfg+oIULJI60NzjOq6ViWln5I7o=; b=jdUO+UwKAnwNwdG/itA1p46kMo
	4LAQBfcukIBBnaLSpEiSBkQ5QGa2yHcOf3frP65ZppqANnJCJazsyoH8FfkzYaLEOVAutmdbtI3eo
	+zIQbdwVuVYMI1scogRS8aIg2Y4LrqeJLOg9pRQDV48ku6wzpeJaGbjt09EIva2IAE5Q=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH 0/3] Add compile_commands.json target
Date: Wed,  5 Aug 2026 11:52:37 +1000
Message-ID: <20260805015247.41943-1-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Modern tools like emacs' `eglot` rely on compile_commands.json to
gather information about the project.  Import the build script from Linux,
adapting it to the core Xen binary.



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 01:53:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 01:53:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382730.1626055 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQoZ-0007Rm-23; Wed, 05 Aug 2026 01:53:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382730.1626055; Wed, 05 Aug 2026 01:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQoY-0007Rf-Tc; Wed, 05 Aug 2026 01:53:02 +0000
Received: by outflank-mailman (input) for mailman id 1382730;
 Wed, 05 Aug 2026 01:53:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrQoX-0007RR-1v
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:53:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoV-0068PJ-2h;
 Wed, 05 Aug 2026 01:52:59 +0000
Received: from [203.221.94.45] (helo=Mac.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoU-00CujO-3C;
 Wed, 05 Aug 2026 01:52:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=Lee8YbDbDbQD/PEEAUhgQiCV3VG2M8ylKmtExRHl+xg=; b=IqME4ytnnjn9USk2eu1wJs0TiW
	tVlwldlurKihxRUiDhT/sRbDNyQLAW29RBAymV6JhKTZvKReFxWYB8qdUAS5RwMxJ7MAgPEcZ+iKi
	Wa3Ne1hYbrZAvb8D/GtmLGnoPN1jDeR8tEoQjcpY8o1pm7H18R6xVZKYyMKDVwoIn12A=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 1/3] xen/scripts: import gen_compile_commands.py from Linux
Date: Wed,  5 Aug 2026 11:52:38 +1000
Message-ID: <20260805015247.41943-2-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805015247.41943-1-gwd@xenproject.org>
References: <20260805015247.41943-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Xen's Kbuild-derived build system records the exact command line used
to compile each object in .<target>.o.cmd files.  That is everything
needed to produce a compile_commands.json compilation database, the
format clangd and other tooling consume to provide accurate
cross-referencing (go to definition, find references, call hierarchy)
in LSP-capable editors.

Import scripts/clang-tools/gen_compile_commands.py from the Linux
kernel, unmodified, so that the provenance of the code is easy to
verify (commit 90efe2b9119f, Linux v6.16).

As-is the script produces an empty database on a Xen tree, since
Xen's compile command lines differ slightly from Linux's; the
following patch adapts it.

Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
 xen/scripts/gen_compile_commands.py | 228 ++++++++++++++++++++++++++++
 1 file changed, 228 insertions(+)
 create mode 100755 xen/scripts/gen_compile_commands.py

diff --git a/xen/scripts/gen_compile_commands.py b/xen/scripts/gen_compile_commands.py
new file mode 100755
index 0000000000..96e6e46ad1
--- /dev/null
+++ b/xen/scripts/gen_compile_commands.py
@@ -0,0 +1,228 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) Google LLC, 2018
+#
+# Author: Tom Roeder <tmroeder@google.com>
+#
+"""A tool for generating compile_commands.json in the Linux kernel."""
+
+import argparse
+import json
+import logging
+import os
+import re
+import subprocess
+import sys
+
+_DEFAULT_OUTPUT = 'compile_commands.json'
+_DEFAULT_LOG_LEVEL = 'WARNING'
+
+_FILENAME_PATTERN = r'^\..*\.cmd$'
+_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P<command_prefix>.* )(?P<file_path>[^ ]*\.[cS]) *(;|$)'
+_VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
+# The tools/ directory adopts a different build system, and produces .cmd
+# files in a different format. Do not support it.
+_EXCLUDE_DIRS = ['.git', 'Documentation', 'include', 'tools']
+
+def parse_arguments():
+    """Sets up and parses command-line arguments.
+
+    Returns:
+        log_level: A logging level to filter log output.
+        directory: The work directory where the objects were built.
+        ar: Command used for parsing .a archives.
+        output: Where to write the compile-commands JSON file.
+        paths: The list of files/directories to handle to find .cmd files.
+    """
+    usage = 'Creates a compile_commands.json database from kernel .cmd files'
+    parser = argparse.ArgumentParser(description=usage)
+
+    directory_help = ('specify the output directory used for the kernel build '
+                      '(defaults to the working directory)')
+    parser.add_argument('-d', '--directory', type=str, default='.',
+                        help=directory_help)
+
+    output_help = ('path to the output command database (defaults to ' +
+                   _DEFAULT_OUTPUT + ')')
+    parser.add_argument('-o', '--output', type=str, default=_DEFAULT_OUTPUT,
+                        help=output_help)
+
+    log_level_help = ('the level of log messages to produce (defaults to ' +
+                      _DEFAULT_LOG_LEVEL + ')')
+    parser.add_argument('--log_level', choices=_VALID_LOG_LEVELS,
+                        default=_DEFAULT_LOG_LEVEL, help=log_level_help)
+
+    ar_help = 'command used for parsing .a archives'
+    parser.add_argument('-a', '--ar', type=str, default='llvm-ar', help=ar_help)
+
+    paths_help = ('directories to search or files to parse '
+                  '(files should be *.o, *.a, or modules.order). '
+                  'If nothing is specified, the current directory is searched')
+    parser.add_argument('paths', type=str, nargs='*', help=paths_help)
+
+    args = parser.parse_args()
+
+    return (args.log_level,
+            os.path.realpath(args.directory),
+            args.output,
+            args.ar,
+            args.paths if len(args.paths) > 0 else [args.directory])
+
+
+def cmdfiles_in_dir(directory):
+    """Generate the iterator of .cmd files found under the directory.
+
+    Walk under the given directory, and yield every .cmd file found.
+
+    Args:
+        directory: The directory to search for .cmd files.
+
+    Yields:
+        The path to a .cmd file.
+    """
+
+    filename_matcher = re.compile(_FILENAME_PATTERN)
+    exclude_dirs = [ os.path.join(directory, d) for d in _EXCLUDE_DIRS ]
+
+    for dirpath, dirnames, filenames in os.walk(directory, topdown=True):
+        # Prune unwanted directories.
+        if dirpath in exclude_dirs:
+            dirnames[:] = []
+            continue
+
+        for filename in filenames:
+            if filename_matcher.match(filename):
+                yield os.path.join(dirpath, filename)
+
+
+def to_cmdfile(path):
+    """Return the path of .cmd file used for the given build artifact
+
+    Args:
+        Path: file path
+
+    Returns:
+        The path to .cmd file
+    """
+    dir, base = os.path.split(path)
+    return os.path.join(dir, '.' + base + '.cmd')
+
+
+def cmdfiles_for_a(archive, ar):
+    """Generate the iterator of .cmd files associated with the archive.
+
+    Parse the given archive, and yield every .cmd file used to build it.
+
+    Args:
+        archive: The archive to parse
+
+    Yields:
+        The path to every .cmd file found
+    """
+    for obj in subprocess.check_output([ar, '-t', archive]).decode().split():
+        yield to_cmdfile(obj)
+
+
+def cmdfiles_for_modorder(modorder):
+    """Generate the iterator of .cmd files associated with the modules.order.
+
+    Parse the given modules.order, and yield every .cmd file used to build the
+    contained modules.
+
+    Args:
+        modorder: The modules.order file to parse
+
+    Yields:
+        The path to every .cmd file found
+    """
+    with open(modorder) as f:
+        for line in f:
+            obj = line.rstrip()
+            base, ext = os.path.splitext(obj)
+            if ext != '.o':
+                sys.exit('{}: module path must end with .o'.format(obj))
+            mod = base + '.mod'
+            # Read from *.mod, to get a list of objects that compose the module.
+            with open(mod) as m:
+                for mod_line in m:
+                    yield to_cmdfile(mod_line.rstrip())
+
+
+def process_line(root_directory, command_prefix, file_path):
+    """Extracts information from a .cmd line and creates an entry from it.
+
+    Args:
+        root_directory: The directory that was searched for .cmd files. Usually
+            used directly in the "directory" entry in compile_commands.json.
+        command_prefix: The extracted command line, up to the last element.
+        file_path: The .c file from the end of the extracted command.
+            Usually relative to root_directory, but sometimes absolute.
+
+    Returns:
+        An entry to append to compile_commands.
+
+    Raises:
+        ValueError: Could not find the extracted file based on file_path and
+            root_directory or file_directory.
+    """
+    # The .cmd files are intended to be included directly by Make, so they
+    # escape the pound sign '#' as '$(pound)'. The compile_commands.json file
+    # is not interepreted by Make, so this code replaces the escaped version
+    # with '#'.
+    prefix = command_prefix.replace('$(pound)', '#')
+
+    # Return the canonical path, eliminating any symbolic links encountered in the path.
+    abs_path = os.path.realpath(os.path.join(root_directory, file_path))
+    if not os.path.exists(abs_path):
+        raise ValueError('File %s not found' % abs_path)
+    return {
+        'directory': root_directory,
+        'file': abs_path,
+        'command': prefix + file_path,
+    }
+
+
+def main():
+    """Walks through the directory and finds and parses .cmd files."""
+    log_level, directory, output, ar, paths = parse_arguments()
+
+    level = getattr(logging, log_level)
+    logging.basicConfig(format='%(levelname)s: %(message)s', level=level)
+
+    line_matcher = re.compile(_LINE_PATTERN)
+
+    compile_commands = []
+
+    for path in paths:
+        # If 'path' is a directory, handle all .cmd files under it.
+        # Otherwise, handle .cmd files associated with the file.
+        # built-in objects are linked via vmlinux.a
+        # Modules are listed in modules.order.
+        if os.path.isdir(path):
+            cmdfiles = cmdfiles_in_dir(path)
+        elif path.endswith('.a'):
+            cmdfiles = cmdfiles_for_a(path, ar)
+        elif path.endswith('modules.order'):
+            cmdfiles = cmdfiles_for_modorder(path)
+        else:
+            sys.exit('{}: unknown file type'.format(path))
+
+        for cmdfile in cmdfiles:
+            with open(cmdfile, 'rt') as f:
+                result = line_matcher.match(f.readline())
+                if result:
+                    try:
+                        entry = process_line(directory, result.group('command_prefix'),
+                                             result.group('file_path'))
+                        compile_commands.append(entry)
+                    except ValueError as err:
+                        logging.info('Could not add line from %s: %s',
+                                     cmdfile, err)
+
+    with open(output, 'wt') as f:
+        json.dump(sorted(compile_commands, key=lambda x: x["file"]), f, indent=2, sort_keys=True)
+
+
+if __name__ == '__main__':
+    main()
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 01:53:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 01:53:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382731.1626063 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQob-0007fE-6h; Wed, 05 Aug 2026 01:53:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382731.1626063; Wed, 05 Aug 2026 01:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQob-0007f7-41; Wed, 05 Aug 2026 01:53:05 +0000
Received: by outflank-mailman (input) for mailman id 1382731;
 Wed, 05 Aug 2026 01:53:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrQoZ-0007eX-Sp
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:53:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoY-0068QR-2v;
 Wed, 05 Aug 2026 01:53:02 +0000
Received: from [203.221.94.45] (helo=Mac.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoY-00CujO-0D;
 Wed, 05 Aug 2026 01:53:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=EQ1BgccOExwdWoWHGsLFxtseXR3eMpL+XYbSkxSyAEo=; b=f/HIkpQwJwcgU1rtgixLQ1KwFo
	pv5nECO/LoGehysoJ5oMBZ5X0DQmHceC3R+tDZn+i+ccIf/w9PmcXom0dA8SL2AlyaYhXsQGgRe8r
	KNJk2QtuimWrMjZImPtGV9YYrydccrjp2zE4DAn+Nnug8CbZ/B3OZ5pVXteIEkauUEAU=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 2/3] xen/scripts: adapt gen_compile_commands.py to Xen
Date: Wed,  5 Aug 2026 11:52:39 +1000
Message-ID: <20260805015247.41943-3-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805015247.41943-1-gwd@xenproject.org>
References: <20260805015247.41943-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Two changes from the Linux original:

 - Linux's compiler invocations end with the source file
   ("... -c -o foo.o foo.c"), and the script's line pattern relies
   on that; Xen's cmd_cc_o_c places "-c $<" before "-o" and "-MQ",
   so on a Xen object tree the unmodified script matches nothing and
   produces an empty database.  Adjust _LINE_PATTERN to capture the
   command up to and including "-c" plus the source file, dropping
   the remainder, which database consumers do not need.

 - Reword the docstring and help text to refer to Xen.

The support for reading object lists from archives and modules.order
is unused in Xen but retained to minimise divergence from the
original.

Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
 xen/scripts/gen_compile_commands.py | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/scripts/gen_compile_commands.py b/xen/scripts/gen_compile_commands.py
index 96e6e46ad1..9abc6410c1 100755
--- a/xen/scripts/gen_compile_commands.py
+++ b/xen/scripts/gen_compile_commands.py
@@ -5,7 +5,7 @@
 #
 # Author: Tom Roeder <tmroeder@google.com>
 #
-"""A tool for generating compile_commands.json in the Linux kernel."""
+"""A tool for generating compile_commands.json for the Xen hypervisor."""
 
 import argparse
 import json
@@ -19,7 +19,10 @@ _DEFAULT_OUTPUT = 'compile_commands.json'
 _DEFAULT_LOG_LEVEL = 'WARNING'
 
 _FILENAME_PATTERN = r'^\..*\.cmd$'
-_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P<command_prefix>.* )(?P<file_path>[^ ]*\.[cS]) *(;|$)'
+# Unlike Linux, Xen's compile commands do not end with the source file:
+# cmd_cc_o_c places "-c $<" before "-o" and "-MQ".  Capture the command up
+# to and including "-c" plus the source file, and drop the remainder.
+_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P<command_prefix>.* -c )(?P<file_path>[^ ]*\.[cS])( .*)?$'
 _VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
 # The tools/ directory adopts a different build system, and produces .cmd
 # files in a different format. Do not support it.
@@ -35,10 +38,10 @@ def parse_arguments():
         output: Where to write the compile-commands JSON file.
         paths: The list of files/directories to handle to find .cmd files.
     """
-    usage = 'Creates a compile_commands.json database from kernel .cmd files'
+    usage = 'Creates a compile_commands.json database from Xen .cmd files'
     parser = argparse.ArgumentParser(description=usage)
 
-    directory_help = ('specify the output directory used for the kernel build '
+    directory_help = ('specify the output directory used for the Xen build '
                       '(defaults to the working directory)')
     parser.add_argument('-d', '--directory', type=str, default='.',
                         help=directory_help)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 01:53:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 01:53:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382732.1626071 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQod-0007tg-D5; Wed, 05 Aug 2026 01:53:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382732.1626071; Wed, 05 Aug 2026 01:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrQod-0007tX-9v; Wed, 05 Aug 2026 01:53:07 +0000
Received: by outflank-mailman (input) for mailman id 1382732;
 Wed, 05 Aug 2026 01:53:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrQoc-0007t8-Th
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 01:53:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQoc-0068Ru-0A;
 Wed, 05 Aug 2026 01:53:05 +0000
Received: from [203.221.94.45] (helo=Mac.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrQob-00CujO-0m;
 Wed, 05 Aug 2026 01:53:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=+sgH7buv7ht5eYGRQ/eq/HiItqeiSBS/Osfxgw6BGz4=; b=lQ53XEufoqc9wMSfBo8QJ8NJ+6
	JZSHlHlngaKGMD6BcpyCkI25g8GnpwGo/0lGkxge/wNU06nFkRJQKXgWlz8Td/uUpXpsPqRAqqIKe
	YUuN4jMGpTDetKyG9gZwTJpgyQDWVP54VAQ2p5w8qNuZLPrqc8VajPxFrYRH+sSYm3Pw=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 3/3] build: add compile_commands.json target
Date: Wed,  5 Aug 2026 11:52:40 +1000
Message-ID: <20260805015247.41943-4-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805015247.41943-1-gwd@xenproject.org>
References: <20260805015247.41943-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a phony convenience target generating the compilation database
from a built object tree, alongside the other developer conveniences
(tags, cscope, cloc -- the last of which already walks the same .cmd
files):

    make -C xen compile_commands.json

The output lands in the object tree root, where clangd and other
consumers discover it automatically when opening files from an
in-tree build.

Note the database records the compiler invocations actually used.
With a clang build it is consumable by clangd as-is; for a gcc build,
clang-based tools may need a small .clangd configuration
(CompileFlags: Remove/Add) dropping gcc-only flags.

Also add the generated file to .gitignore.

Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
 .gitignore   | 1 +
 xen/Makefile | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/.gitignore b/.gitignore
index bfc7bdf043..0aa9b801de 100644
--- a/.gitignore
+++ b/.gitignore
@@ -192,6 +192,7 @@ xen/arch/*/include/generated
 xen/build-dir-cppcheck/
 xen/common/config_data.S
 xen/common/config.gz
+xen/compile_commands.json
 xen/cppcheck-htmlreport/
 xen/cppcheck-report/
 xen/cppcheck-misra.*
diff --git a/xen/Makefile b/xen/Makefile
index d39bdfdd53..f87240f33c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -685,6 +685,10 @@ cloc:
 	    done; \
 	done | cloc --list-file=-
 
+.PHONY: compile_commands.json
+compile_commands.json:
+	$(PYTHON) $(srctree)/scripts/gen_compile_commands.py -d $(objtree)
+
 # Target used by xen-analysis.sh script to retrieve Xen build system variables
 export-variable-%:
 	$(info $*=$($*))
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 04:31:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 04:31:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382789.1626080 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrTI7-0004fu-Km; Wed, 05 Aug 2026 04:31:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382789.1626080; Wed, 05 Aug 2026 04:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrTI7-0004fn-I8; Wed, 05 Aug 2026 04:31:43 +0000
Received: by outflank-mailman (input) for mailman id 1382789;
 Wed, 05 Aug 2026 04:31:42 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wrTI5-0004fa-5d
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 04:31:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrTI3-00GgVP-W3
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:31:40 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a72bc93-e002-0a2a0a5209dd-0a2a45068884-24
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:31:39 +0200
Received: from [52.101.228.94]
 (helo=OS0P286CU011.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a72bca8-195a-0a2a45060019-3465e45eb222-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:31:38 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by OS9P286MB4891.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:2c1::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Wed, 5 Aug
 2026 04:31:34 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0270.017; Wed, 5 Aug 2026
 04:31:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kK/iTdvDfV/p3i7iy1AGEslip0Q2W5J5X2MH9DNreQArwXN9JfG5eQSNdnJkNcxjMKOw9NggyD/donfIcAGZTZ8AF8ImE8aS0lIzgRV50nCHROj2Wxc6zUDA1+9lYurAgO/2Ub9DF1jU4WiqgoENluohVrKXuiQK9ZLThg5gVYRVBr3Wk05BwSzCVVtbu8Fk2YDv2ZV/L2ldVMyyqb1j5GXa9s3oXI7lY5kKkmspBs5rgkL6qtSevbud8sLYRJzu0byCg3eZxwjFHuF/pYld+tvL8AIWaZgrGCSUnuWqE+1D6hcJdcAeKFh7HOc/jMwMjhttyajv8apQ529nxpuqew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2Bngy3RvD5jAQEeCq3S+xlBbepXg3MzqbFfz4C23Ujg=;
 b=V/rGH+5eaGcmBXmuKVXUjMG51SfsoZvhxOlEI3ggrOnthAINDDMktTnPrvspxp7nKzmCZSOGL8J7bcETQD5JxQTQTJ5sW98v0z/cJBdfrOKA8LPv0vPjz5r1ldv8zo+rodNsyBcmEL9oLmkamToTeon7d8J+GNrxR5xwsZ2nDrREMqfu3lUhWVmUEIS7VFnl9ko9uu6EcTrVMptw4Tdb5TyycwqofirZMGgnoVvwVUx1vLQa3uKfVBBVUrRsxY/e4lPEYStQ8+9bd/It+mg7MBsvQcRYsTwpiwJa7UIXWQCc8/kz5uWPl4ICnjVeAdAcByJUfZBz4O6Y8Q2/AfdoSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2Bngy3RvD5jAQEeCq3S+xlBbepXg3MzqbFfz4C23Ujg=;
 b=bIleaxANhSNVC1RKDLnV0VFHSZ0JrOCKtaJBVkJY/Xsm8k3X+KCiz4KTRnM/+UYadpOm+JWrT4XeTKG09nwLWMTHaqoB8M4RdvjkMaZUWBQbBTCxnFGmM+3A6z9aKne3lFtdHkvxd1lLziQw/rslxMRwz/HGDnTSzIRv+7rAICQ=
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: Julien Grall <julien@xen.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: RE: [PATCH] xen/arm: Hide PMU feature
Thread-Topic: [PATCH] xen/arm: Hide PMU feature
Thread-Index: AQHdIuEazfVQgCaihUe50qminMMbcraL5wiAgAL2WTA=
Date: Wed, 5 Aug 2026 04:31:33 +0000
Message-ID:
 <OS9P286MB7222D076D36F722B479A549F82D32@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
References: <20260803004245.693844-1-taka@valinux.co.jp>
 <dbb32862-b3d2-4fb5-b4ef-49675fa243b2@xen.org>
In-Reply-To: <dbb32862-b3d2-4fb5-b4ef-49675fa243b2@xen.org>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OS9P286MB7222:EE_|OS9P286MB4891:EE_
x-ms-office365-filtering-correlation-id: 70d199a9-4b35-4d30-096e-08def2aa6e11
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|22082099003|18002099003|4143699003|3023799007|38070700021|6133799003|10067099003|56012099006;
x-microsoft-antispam-message-info:
 SPDwRhCmFzfMpPvKby2NGFECLSxQxNCSDPjgcWNVEm1QkQAUusCkLfvyDWCym2T6YxX7cenwmCA8mCZo4Y1kEekYD9hIJv2PSS4CfAtSQHToVvtoFJVhrwKPuW/SsNI/1gTYtLsqm6pNl2l8MU9TcYmpjDwAiHGsgI7fmad7s9MjH21JqaTpNmYsox0+/+BB6lc+u6RdakJgSEKg+0Q9Nvxnw1mjPKOKgVAgkl1Iokg4X6FiYk7zSjNrRjyYfuYdXHjXCxuy/fnrOwnk4On41V/P9GpSuuEGGDCgj5louaCmt8buzmN1CfwjtLs0UKDfk6tq5VjI84f3nW67GZObY6sT1n8rOe2HWrE3C7RKM8jc5w/xryMSRVwVMj4cCBzbkGG+zyY9iMtNaKCBHmnPQ90e2ckiKAO4UHE7chjAXKUFomHSqt03ghgxykWgueOt0Pj00j+od8XlL5/On4dPJHK2p+vdFmaihwlaihoYrG7YMDw47BX4SGwZORvu1tVZa//qLZBcUszpV4WjYwpqC0aj0e+s1Quqk0fVuzjZYqO/xbsAIMVWKWeZQ3klFz5eYhQiuFRtLZ2MJj+OSxjJ8CMqpTWe/DxQMWUGHC9sniSveuOMyxyplRCysyMHhe8AHUouEzH822oYq8xmIUrg6x87YGoWe7KdVjV3vZutY87KahE5iHPW/M9TTnkO5uLWG5OoAcnSO6GWW2UuKlCi8prXJ804I8XDJI6zf12hoiA=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(22082099003)(18002099003)(4143699003)(3023799007)(38070700021)(6133799003)(10067099003)(56012099006);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?ZEZtdGpGbmpnQUwxSVBDTmRLVjFnUmowU1FHSC9HRi9Lb0lIV0N2QTlmZjJl?=
 =?utf-8?B?eHZBam1nREpBSFBDd1N3bU1Ha3dBczFmTWF5anhUaGMrZW0wMXd6YVl4WURJ?=
 =?utf-8?B?Y2svdGV0VVdMeDBBRnlYV0hkZUlSQVNxS0hqU2dLdS8rMjlBK3BHQ0p3TU5q?=
 =?utf-8?B?M3hpTFFLYTdLRE1Xb1lGYmNzZDF3QW10ZnkvYzJHazY2bVJIVXBTd3hMYU5C?=
 =?utf-8?B?dWk2TEtWZE9QK2ZFcjZGWUN2RnhjWDN2VGp3OEtYalpLeDhSajhLRDZFSFhj?=
 =?utf-8?B?TDNTMkJ5ZGptc25BL2lxZXo5dXZZL1VFcjRjTytHY2ZhRTcwT1BuQ3AzNU9o?=
 =?utf-8?B?dWtlS1RnSVhpRlRBMVpkcUFxMkgwQnlFY2tpdlFncjFBSGFkYzE4TGN5UWdw?=
 =?utf-8?B?SHlYOWJ4blBjWnNPMnAvOVpYMlJiUzhqenRwaXpGUmd1UnZlaGl0NEVrM3g5?=
 =?utf-8?B?TFY5K01sMlZ1WXlUb1BxVTNldXQrNEtnZytnMHdqU1NHTmp1MytLc1hsLzdO?=
 =?utf-8?B?eTE2WDNNaXNuT2IyZlhLWk1zRDJUK1U4UE1yWmJGUFRGNEJuKzZyd09sckZw?=
 =?utf-8?B?TUcrcmhFVEpyQTllemRXTGZEVnhMQlhPV08vSXEzNnh0eDAyaXV1MHJ1SXAy?=
 =?utf-8?B?dzRLaUw2YXBteTRoRVJ5VndEcTdLdVU4TjlXKzJTVFVtQVprOFRReGN5dzIz?=
 =?utf-8?B?MERkaWRNNXZVMVoyRm5CVDBlUFZxT3B3Ung5NkdHcEdRMmk1YVFwVmFMeEJk?=
 =?utf-8?B?aFpRWVBpYUVTemUrd2xCU3Q2MnlkYjNRN01MYytjSlMxc0VoN0MzQzE0dUdC?=
 =?utf-8?B?VWUvakNyOXNMbkV2VklGR3pTN3hENEQxd09LcHYxRml4MHJLYXd0RkwwREw2?=
 =?utf-8?B?Z0dueFBCRmtDWTNSbFlybzZ6ckMyb0dTSGdrc1ZhNjFkZnVHSDdKYVJTMUpD?=
 =?utf-8?B?ZFVwK2t5L1FuK2RQakZkSkZIZEdZamNXTGNxRlpYRlk3eC9WQlZEWEV2WVhR?=
 =?utf-8?B?RjV2amNKa2FrVk5ZSnNrekhhcE01M1dJOU0yWHY4ZzlhaWdWVy9nQU9wVDVt?=
 =?utf-8?B?VHhpbWtrK0FqZGNpVVNiMHZsUyttc0EybkljY2pwWTMxbzN6alM2Vy9nZzBy?=
 =?utf-8?B?cnFhMGkvR2d5cVQzUFJVRzNBYWZzV3dVam00bHpJdkJxaDVhUnF4bEMyZ2F5?=
 =?utf-8?B?WWxPVzVkZ0c1RG8zeFRxbFhhRFZGNkd6Z3phYldHdFg3SGlodW85R0haUjV0?=
 =?utf-8?B?WXJhNVcrQ2tOazc0OU9HU2tlbDZjT2N6TmNjSWEwQTZQRTExRHhIbGllOG51?=
 =?utf-8?B?dlp1SDluMmFnODgweGdIdDBoZHBvNjNFSHB5THBkUGhFSjdabzBTQ3RveUJk?=
 =?utf-8?B?N2YwcU5xanZCcVN1SmMwNVdudlRkSE90TE1UazhMcUc4cFFuUmlXVW5MY0Nw?=
 =?utf-8?B?aE1pYXYxeEZPOXg2dzFyYzYvNzFCcHdtMnhoTmYzQUlObm5PeVZNQ0ZsRlZq?=
 =?utf-8?B?TlduS2lZTWlLM0ordlVLSlYrVFNHNTVUN2pxQmhGWlpjS3hCbk03Tmt3Y2Zr?=
 =?utf-8?B?Qzh0YnBSaDZ1N0pQQXoyY2lGTGR1MXNwVVpPU01Vd3R4djF4OVlyVERFVk5D?=
 =?utf-8?B?RXdMMHJZbk4zTFBuZWJpazd2S24wYkl5andkVFBjekJVVEptV1Z3NHRDOG9V?=
 =?utf-8?B?OHdoalJRdXJSVi83Z0NSL09CMTVVMTBYQjVVbHk3bFV1MGkvL1dKOThPaXV0?=
 =?utf-8?B?eHdUODU4ZWw1UjRCYnF6eVpBQ2IyZytET2ZxVFp6Ykhnb3Q1bmlQcUNqZmxj?=
 =?utf-8?B?dU9oUXVkU3E1UmN5U0hOM1hVMldQd3JEQUd2cmxOL09wc0RrVzhvekJPZXE3?=
 =?utf-8?B?QkZJSDZ6aUgrR3V4eFBMWDhXSUtuNDlHR0xIYWZaYU1ZUEx6K0xwY21aTU5K?=
 =?utf-8?B?NUJNbVc5UHJOMTI1Uis1ZEI3MGtId1d2MGhSR1NjWCtQdDhKdk90QlVUWGc5?=
 =?utf-8?B?YThOS0dBVnExZDNnaGs1Y0VWNW5IamJZVk1vbm5MdUhLOFVsa0JMTnlnM3FG?=
 =?utf-8?B?VUMwaFpLMTBJRG5TSVNkaGh5UjI3bTBNbERSdFZMZXBNRnBNangxdkJYZzNS?=
 =?utf-8?B?LzdmNmdSRVNBdTNjYllVNWEvR0VFTWtqclVJazFDUkJZV3Z2N3RYQUk3ZVMx?=
 =?utf-8?B?M1M1cENHZEVDQUJTNG8wWlhPbzhoNnpBUUR2TWdsMnFHRWEvMmFRVnoreVdH?=
 =?utf-8?B?dEN4eHBKNXAvWGVqL2MvazArMmE5QTMrbUJCMlBjVDZKb3VmcWxHcWdqTmpt?=
 =?utf-8?Q?SA2KdVx/es187graRs?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 70d199a9-4b35-4d30-096e-08def2aa6e11
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2026 04:31:33.7351
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8iiLBt/N6OMrU38Poxvceb4GGtyMcsFdfINBISNiY0mfB8fl1HQVOFw3+rgRdHDuojD1R9THUJ3tCFrygSxZ/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB4891
X-purgate-ID: tlsNG-16d1c6/1785904299-FEA7477B-8D14F3E6/0/0
X-purgate-type: clean
X-purgate-size: 5178

SGksDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLg0KDQo+ID4gRHVyaW5nIHRoaXMgcHJv
YmUsIExpbnV4IGFjY2Vzc2VzIFBNTUlSX0VMMSwgd2hpY2ggY2F1c2VzIHVuaGFuZGxlZA0KPiA+
IHJlZ2lzdGVyIHRyYXBzIGFuZCBjcmFzaGVzIHRoZSBkb21haW4uIE1lcmVseSBhZGRpbmcgZW11
bGF0aW9uIGNvZGUNCj4gPiBmb3IgUE1NSVJfRUwxIGluIFhlbiBpcyBpbnN1ZmZpY2llbnQgdG8g
Zml4IHRoZSBpc3N1ZSwgYXMgdGhlIGd1ZXN0DQo+ID4gUE1VIGRyaXZlciBzdWJzZXF1ZW50bHkg
c3RhbGxzIGR1cmluZyBpdHMgaW5pdGlhbGl6YXRpb24gc2VxdWVuY2UuDQo+ID4NCj4gPiBGaXgg
dGhpcyBieSBleHBsaWNpdGx5IG1hc2tpbmcgUE1VIGNhcGFiaWxpdHkgZmllbGRzIGluDQo+ID4g
Y3JlYXRlX2RvbWFpbl9jcHVpbmZvKCkuIEFkZGl0aW9uYWxseSwgcHJlZW1wdGl2ZWx5IG1hc2sg
b3RoZXINCj4gPiBjYXBhYmlsaXR5IGZpZWxkcyB0byBwcmV2ZW50IHNpbWlsYXIgcG90ZW50aWFs
IGlzc3Vlcy4NCj4gDQo+IFdoaWxlIEkgYWdyZWUgWGVuIGRvZXNuJ3Qgc3VwcG9ydCBQTVUgY2Fw
YWJpbGl0eSBmb3IgZXZlcnkgZ3Vlc3QsIEkNCj4gYmVsaWV2ZSB3ZSBhcmUgc3RpbGwgYWxsb3dp
bmcgdG8gZXhwb3NlIHRoZSBQTVUgaW4gc29tZSBjYXNlcyAoc2VlDQo+IGNvbW1pdCBkYmI5NDgx
MTBhICJ4ZW46IEV4cG9zZSB0aGUgUE1VIHRvIHRoZSBndWVzdHMiKS4gU28gd2UgY2FuJ3QNCj4g
c2ltcGx5IG1hc2sgdGhlIGZlYXR1cmVzLiBTbyBJIHRoaW5rIC4uLg0KDQpJIHdpbGwgbW9kaWZ5
IHRoZSBzeXNyZWcgdHJhcCBoYW5kbGVyIGZvciBJRF9BQTY0REZSMF9FTDEgdG8gZHluYW1pY2Fs
bHkNCm1hc2sgdGhlIGJhc2ljIFBNVSBjYXBhYmlsaXRpZXMgYmFzZWQgb24gdGhlIGRvbWFpbidz
IHZQTVUNCmNvbmZpZ3VyYXRpb24uDQoNCj4gPiBGaXhlczogMzY2OWExY2I5NTk4ICJ4ZW4vYXJt
OiBjcmVhdGUgYSBjcHVpbmZvIHN0cnVjdHVyZSBmb3IgZ3Vlc3QiDQo+ID4gU2lnbmVkLW9mZi1i
eTogSGlyb2thenUgVGFrYWhhc2hpIDx0YWthQHZhbGludXguY28uanA+DQo+ID4gLS0tDQo+ID4g
ICB4ZW4vYXJjaC9hcm0vY3B1ZmVhdHVyZS5jICAgICAgICAgICAgIHwgMTYgKysrKysrKysrKysr
KysrKw0KPiA+ICAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaCB8IDEwICsr
KysrKy0tLS0NCj4gPiAgIDIgZmlsZXMgY2hhbmdlZCwgMjIgaW5zZXJ0aW9ucygrKSwgNCBkZWxl
dGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vY3B1ZmVhdHVyZS5j
IGIveGVuL2FyY2gvYXJtL2NwdWZlYXR1cmUuYw0KPiA+IGluZGV4IDk0ZDE0ZmI2YTkuLjcxZDc0
NWQzY2IgMTAwNjQ0DQo+ID4gLS0tIGEveGVuL2FyY2gvYXJtL2NwdWZlYXR1cmUuYw0KPiA+ICsr
KyBiL3hlbi9hcmNoL2FybS9jcHVmZWF0dXJlLmMNCj4gPiBAQCAtMjE5LDggKzIxOSwyNCBAQCBz
dGF0aWMgaW50IF9faW5pdCBjcmVhdGVfZG9tYWluX2NwdWluZm8odm9pZCkNCj4gPiAgICAgICBk
b21haW5fY3B1aW5mby5pc2E2NC5hcGkgPSAwOw0KPiA+ICAgICAgIGRvbWFpbl9jcHVpbmZvLmlz
YTY0LmdwYSA9IDA7DQo+ID4gICAgICAgZG9tYWluX2NwdWluZm8uaXNhNjQuZ3BpID0gMDsNCj4g
PiArDQo+ID4gKyAgICAvKiBIaWRlIFBNVXYzIHN1cHBvcnQgYXMgWGVuIGRvZXMgbm90IHN1cHBv
cnQgaXQgKi8NCj4gPiArICAgIGRvbWFpbl9jcHVpbmZvLmRiZzY0LnBtdV92ZXIgPSAwOw0KPiA+
ICsgICAgZG9tYWluX2NwdWluZm8uZGJnNjQubXRwbXUgPSAwOw0KPiA+ICsgICAgZG9tYWluX2Nw
dWluZm8uZGJnNjQucG1zcyA9IDA7DQo+IA0KPiAuLi4gdGhpcyBzZWN0aW9uIG5lZWRzIHRvIGJl
IGNvbmRpdGlvbmFsLg0KDQpPa2F5Lg0KIA0KPiA+ICsNCj4gPiArICAgIC8qIEhpZGUgU1BFLCBU
UkJFLCBCUkJFLCBhbmQgVHJhY2UgRXh0ZW5zaW9ucyAqLw0KPiA+ICsgICAgZG9tYWluX2NwdWlu
Zm8uZGJnNjQucG1zX3ZlciA9IDA7DQo+ID4gKyAgICBkb21haW5fY3B1aW5mby5kYmc2NC50cmFj
ZV92ZXIgPSAwOw0KPiA+ICsgICAgZG9tYWluX2NwdWluZm8uZGJnNjQudHJhY2VfZmlsdCA9IDA7
DQo+ID4gKyAgICBkb21haW5fY3B1aW5mby5kYmc2NC50cmFjZV9idWZmZXIgPSAwOw0KPiA+ICsg
ICAgZG9tYWluX2NwdWluZm8uZGJnNjQuZXh0X3RyY19idWZmID0gMDsNCj4gPiArICAgIGRvbWFp
bl9jcHVpbmZvLmRiZzY0LmJyYmUgPSAwOw0KPiANCj4gVGhpcyBzZWN0aW9uIHNob3VsZCBiZSBm
aW5lIHRvIHVuY29uZGl0aW9uYWxseSBtYXNrLg0KDQpPa2F5Lg0KDQo+ID4gICAjZW5kaWYNCj4g
Pg0KPiA+ICsgICAgLyogSGlkZSBQTVV2MSx2MiBzdXBwb3J0IGFzIFhlbiBkb2VzIG5vdCBzdXBw
b3J0IGl0ICovDQo+ID4gKyAgICBkb21haW5fY3B1aW5mby5kYmczMi5wZXJmbW9uID0gMDsNCj4g
PiArDQo+ID4gICAgICAgLyogSGlkZSBBTVUgc3VwcG9ydCAqLw0KPiA+ICAgI2lmZGVmIENPTkZJ
R19BUk1fNjQNCj4gPiAgICAgICBkb21haW5fY3B1aW5mby5wZnI2NC5hbXUgPSAwOw0KPiA+IGRp
ZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vY3B1ZmVhdHVyZS5oDQo+IGIveGVu
L2FyY2gvYXJtL2luY2x1ZGUvYXNtL2NwdWZlYXR1cmUuaA0KPiA+IGluZGV4IGJmOTAyYTM5NzAu
LmM5MmIyNjUxYzcgMTAwNjQ0DQo+ID4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Nw
dWZlYXR1cmUuaA0KPiA+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9jcHVmZWF0dXJl
LmgNCj4gPiBAQCAtMjE2LDE2ICsyMTYsMTggQEAgc3RydWN0IGNwdWluZm9fYXJtIHsNCj4gPiAg
ICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdHJhY2VfdmVyOjQ7DQo+ID4gICAgICAgICAgICAg
ICB1bnNpZ25lZCBsb25nIHBtdV92ZXI6NDsNCj4gPiAgICAgICAgICAgICAgIHVuc2lnbmVkIGxv
bmcgYnJwczo0Ow0KPiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVzMDo0Ow0KPiA+
ICsgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBtc3M6NDsNCj4gPiAgICAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgd3Jwczo0Ow0KPiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVz
MTo0Ow0KPiA+ICsgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHNlYmVwOjQ7DQo+ID4gICAgICAg
ICAgICAgICB1bnNpZ25lZCBsb25nIGN0eF9jbXBzOjQ7DQo+ID4gICAgICAgICAgICAgICB1bnNp
Z25lZCBsb25nIHBtc192ZXI6NDsNCj4gPiAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgZG91
YmxlX2xvY2s6NDsNCj4gPiAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdHJhY2VfZmlsdDo0
Ow0KPiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVzMjo0Ow0KPiA+ICsgICAgICAg
ICAgICB1bnNpZ25lZCBsb25nIHRyYWNlX2J1ZmZlcjo0Ow0KPiA+ICAgICAgICAgICAgICAgdW5z
aWduZWQgbG9uZyBtdHBtdTo0Ow0KPiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVz
MzoxMjsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBicmJlOjQ7DQo+ID4gKyAgICAg
ICAgICAgIHVuc2lnbmVkIGxvbmcgZXh0X3RyY19idWZmOjQ7DQo+ID4gKyAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgaHBtbjA6NDsNCj4gPg0KPiA+ICAgICAgICAgICAgICAgLyogREZSMSAqLw0K
PiA+ICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBfX3JlczQ6NjQ7DQoNClRoYWsgeW91LA0K
SGlyb2thenUgVGFrYWhhc2hpLg0K


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 05:33:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 05:33:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382807.1626090 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrUFs-0006hU-8J; Wed, 05 Aug 2026 05:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382807.1626090; Wed, 05 Aug 2026 05:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrUFs-0006hN-5P; Wed, 05 Aug 2026 05:33:28 +0000
Received: by outflank-mailman (input) for mailman id 1382807;
 Wed, 05 Aug 2026 05:33:27 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrUFr-0006hE-4N
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 05:33:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrUFq-00GpBj-AJ
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 07:33:26 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72cb08-5cb7-0a2a0a5109dd-0a2a45088926-42
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:33:26 +0200
Received: from [209.85.208.54] (helo=mail-ed1-f54.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72cb25-f659-0a2a45080019-d155d036ec62-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:33:25 +0200
Received: by mail-ed1-f54.google.com with SMTP id
 4fb4d7f45d1cf-69fab5a852cso801500a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 22:33:25 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c203612f1d8sm82503166b.3.2026.08.04.22.33.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 22:33:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785908005; x=1786512805; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=tKWy2di21eitj6RpqSuJfccPk2t+roA1WmKtrBhIFN0=;
        b=CM5y9aEgJiOrlP1IRM6t02i393SNm6yo84ZzXyg27w5tEgxBTMHiDvV3elZaoRSrMc
         n5cpssGNH950pzAAXh/Ra8c06cZA431qauzrIJgsk4JoVMZRcRzJmrewS/PtuWzBpDoW
         uWRJ9segEzOavJpkeijXtHz+bao2tBVejf6opCDfcgOxbrhb+4Llkpx9LilnY8AUT+sD
         1iBDLi1lfsn2xtQze9STwUobdmveRqFKCyv3yGOdneLqzx+LAxbusc3ad3fpjttHdoaL
         N++bLpsBZG8Y/OU/Dhy4TH2cEUwsJC/kC1G+VO2vmh3a2tjWHBszHqyMOKhlcJoSTgjV
         RnLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785908005; x=1786512805;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=tKWy2di21eitj6RpqSuJfccPk2t+roA1WmKtrBhIFN0=;
        b=M0rQKiN2eLmhneDrap6e6Ab9bOiilvIB8oVY0NzE/Qq+L1xGug7m4KFKt/aXlsZUJ1
         L2XJhAM7QItxJyUg7Hkj6QfQmFZlWhVh6DiNrSTcivM6BHS96pqBeaqW5ZTcF6ktZri0
         Y443a23ES17tTbmxgGjozLEqSKqfm6K5YZWhfGfskLLjMXvdBxZ5/f9YLsbIA6Yvo+fy
         FhALFWRYfRPnHTJyLHQK8nRTdo6s4fWe+BTIbEMqBQfiS6gUYXNMCqrnVzjAtDuGSoHp
         F91JLrp4LwP8uBchg5qB6hwlPTy2/nt7E7pPM0wEWlGdqrT5jILBKIyYOSStSNwL0hl4
         kWQA==
X-Forwarded-Encrypted: i=1; AHgh+RptpInvHrHJYyjF5gKBhQW/1PXluL92MMD50GoGzUdLpZnRbTJYpQ/s2Oa2A3I5970c0c//JvdB3V8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YygMBxpspL+LnY39ljNdCCiqnGhkJa+/FItRPk2nV/p7ebO+eIY
	DsPkNhuXf2HQ2w255gnccyvurd+7GdDBV9icN0kmQtdnhfVHj/NZuUIZZpQYn0XxJu8=
X-Gm-Gg: AR+sD10wkZYbZyBkmuazzzCrKSEXsTgZ9j0X8qqRsb2SfUc99BgfvG5VjUrvz3ChdeZ
	nFBtDa/a2UPJ0UTI6yWwa/iFP+PYrZma6UpT9i5HAcTa62qM01N50aaV25/iVLjMzsTggyXOp9V
	8WF7Ho8coCbABPAm2zZBrXgY6XEkyY7uSdYFKXx4jxioB2Obq3ADJw4gB+TjzkFgpAcanP6kTMw
	XssPHdEMETSqYeTsEP4rsS1ECcm/W51fpSQtIkQPK8eP+nOjRWVMGy5juBZZHiwCXr8yDCjnn++
	2ksuhyOjxnRX8hxijNvOv3aWRxJbG6T6jwqZGUNTQsh4gI4Jr9n6oTlJ8sSGwCDqK+YisOkAGhl
	A84NtaqVOQuvKGtVl5oA2mFE3HJ/V4ItziZguw9+w4kUsQXoCvvdXfsVWNJWnXsaPQsxCHfUC5I
	d4LxerIJQ95bvtjEuGZRTaldZR9fnSBQd3GAPTLgjhHQmNzvw1N56JlhohHdzKDvrgmkYVWTXBY
	OdaFL2gZdGp+Zw/h/hDROiaSB+kH44Sy0OrfvXWXCVKx8hjT1TefMp+wXAQGkb2CkCA2QCzGp+g
	Gp1QjVrOitDGIqIJd/EPoWMzdw==
X-Received: by 2002:a17:906:9c89:b0:c19:6d4a:425b with SMTP id a640c23a62f3a-c2039ef0f6fmr172073066b.18.1785908002664;
        Tue, 04 Aug 2026 22:33:22 -0700 (PDT)
Message-ID: <fe27f316-2330-4f7b-bcba-c49677eae70b@suse.com>
Date: Wed, 5 Aug 2026 07:33:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: linux-next: build failure after merge of the xen-tip tree
To: Val Packett <val@invisiblethingslab.com>, Mark Brown
 <broonie@kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Xen Devel <xen-devel@lists.xenproject.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Linux Next Mailing List <linux-next@vger.kernel.org>
References: <anITNOG1qicdE-TI@sirena.org.uk>
 <E5B27F21-9507-4801-8765-0A83FD8A316E@invisiblethingslab.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <E5B27F21-9507-4801-8765-0A83FD8A316E@invisiblethingslab.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------JLqJ0jN6d4byD0AanPRr2D3h"
X-purgate-ID: tlsNG-c1860d/1785908006-D674387B-3D79B4D2/0/0
X-purgate-type: clean
X-purgate-size: 7511

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------JLqJ0jN6d4byD0AanPRr2D3h
Content-Type: multipart/mixed; boundary="------------5DURXzF5G0iaAwCQsTZ541UC";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Val Packett <val@invisiblethingslab.com>, Mark Brown
 <broonie@kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Xen Devel <xen-devel@lists.xenproject.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Linux Next Mailing List <linux-next@vger.kernel.org>
Message-ID: <fe27f316-2330-4f7b-bcba-c49677eae70b@suse.com>
Subject: Re: linux-next: build failure after merge of the xen-tip tree
References: <anITNOG1qicdE-TI@sirena.org.uk>
 <E5B27F21-9507-4801-8765-0A83FD8A316E@invisiblethingslab.com>
In-Reply-To: <E5B27F21-9507-4801-8765-0A83FD8A316E@invisiblethingslab.com>

--------------5DURXzF5G0iaAwCQsTZ541UC
Content-Type: multipart/mixed; boundary="------------Kk1bta0bi6MpK8PUQLmt4F5J"

--------------Kk1bta0bi6MpK8PUQLmt4F5J
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDQuMDguMjYgMjA6MDAsIFZhbCBQYWNrZXR0IHdyb3RlOg0KPiANCj4gDQo+IEVsIDQg
ZGUgYWdvc3RvIGRlIDIwMjYgMToyODozNuKAr3AuwqBtLiBBUlQsIE1hcmsgQnJvd24gPGJy
b29uaWVAa2VybmVsLm9yZz4gZXNjcmliacOzOg0KPj4gSGkgYWxsLA0KPj4NCj4+IEFmdGVy
IG1lcmdpbmcgdGhlIHhlbi10aXAgdHJlZSwgdG9kYXkncyBsaW51eC1uZXh0IGJ1aWxkICh4
ODZfNjQNCj4+IGFsbG1vZGNvbmZpZykgZmFpbGVkIGxpa2UgdGhpczoNCj4+DQo+PiBFUlJP
UjogbW9kcG9zdDogImluaXRfbW0iIFtkcml2ZXJzL3hlbi94ZW4tcHJpdmNtZC5rb10gdW5k
ZWZpbmVkIQ0KPj4NCj4+IENhdXNlZCBieSBjb21taXQNCj4+DQo+PiAgIDY0ZDI2ZmIyYWQx
ZjIgKHhlbjogcHJpdmNtZDogZml4IGlvZXZlbnRmZCBjcmFzaCB1bmRlciBQViBkb21haW4p
DQo+Pg0KPj4gSSBoYXZlIHVzZWQgdGhlIHRyZWUgZnJvbSBuZXh0LTIwMjYwODAzIGluc3Rl
YWQuDQo+IA0KPiBTb3JyeSBmb3IgdGhlIHRyb3VibGUhIERpZCBub3QgZXhwZWN0IHRoYXQg
dG8gZ2V0IGFwcGxpZWQgc28gcXVpY2tseS4uIEkgaGFkIG5vdGljZWQgcmVjZW50bHkgaW4g
bXkgb3duIHRlc3RpbmcgdGhhdCB0aGF0IHBhdGNoIHdhc24ndCBhY3R1YWxseSByZWFkeSB0
byBnbyBpbiBkdWUgdG8gdGhlIHN5bWJvbCB2aXNpYmlsaXR5IGlzc3VlLCByaWdodC4gSSds
bCB3b3JrIG9uIHJlc29sdmluZyBpdC4NCj4gfnZhbA0KDQpJJ20gcHJldHR5IHN1cmUgbW0g
bWFpbnRhaW5lcnMgd291bGRuJ3QgbGlrZSBpbml0X21tIHRvIGJlIGV4cG9ydGVkIHRvDQpt
b2R1bGVzLg0KDQpJJ2QgZ28gZm9yIGEgc3BlY2lhbCB2YXJpYW50IG9mIHhlbl9yZW1hcF9k
b21haW5fbWZuX2FycmF5KCkgbWFwcGluZyBqdXN0DQphIHNpbmdsZSBwZm4gaW50byBpbml0
X21tLiBUaGlzIGNvdWxkIGJlIGltcGxlbWVudGVkIGluIG1tdV9wdi5jIGF2b2lkaW5nDQp0
aGUgbmVlZCB0byBleHBvcnQgaW5pdF9tbS4NCg0KDQpKdWVyZ2VuDQo=
--------------Kk1bta0bi6MpK8PUQLmt4F5J
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------Kk1bta0bi6MpK8PUQLmt4F5J--

--------------5DURXzF5G0iaAwCQsTZ541UC--

--------------JLqJ0jN6d4byD0AanPRr2D3h
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpyyyEFAwAAAAAACgkQsN6d1ii/Ey+7
xAf8DyuH/0FYNoBKX08hI0Fj1oCG+R2Wf2mrXSZvz90ygWXQNqMMvQslTAozg4xiNsZ48m+IHLY2
h5ivCHq9s9JsywfRcmADL6GDRkDeePa05Uns5qxeKIiid6XSd8oJG38ykJA/2zGcC8WzfBK86Ug8
VY52lrfzs/qiYs6FnwsoGWyY72wKrpA5gPgIypBGByr7AYhkJgi97gDwWTSF+q1tws7i3LK1TYgG
BBLdfpIvez3xLCTrICIZeJIaNZRAAQnIONISyXi4QfQ/usHkmDSxHGMdpyBli0A6glxH47xZsH5A
gK7ZrcHVogzqSK3E/wfCvlVACTQvzXnH/bJiWzz5wg==
=XVKV
-----END PGP SIGNATURE-----

--------------JLqJ0jN6d4byD0AanPRr2D3h--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 06:04:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 06:04:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382821.1626099 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrUjp-0002WL-M6; Wed, 05 Aug 2026 06:04:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382821.1626099; Wed, 05 Aug 2026 06:04:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrUjp-0002WE-JI; Wed, 05 Aug 2026 06:04:25 +0000
Received: by outflank-mailman (input) for mailman id 1382821;
 Wed, 05 Aug 2026 06:04:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrUjo-0002W7-Ji
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:04:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrUjo-00HIcz-0L
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:04:24 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72d267-5cb7-0a2a0a5109dd-0a2a4502d022-0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:04:23 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72d267-6ca4-0a2a45020019-d155dd2dcd3c-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:04:23 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47c2b362ee2so393889f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:04:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e2e4sm5507675f8f.25.2026.08.04.23.04.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 23:04:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785909863; x=1786514663; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=XBygFyzYJYS5+ICqbXp5tbWEYq5wUoX0qFqph9ian3g=;
        b=IpoICVJ22gglvXwLNqCWPAj/+Ho8PSRUvhaDk7uSNUytl7gFR+g5p172ZHtfz7msrG
         dokWiU8B5bcCz81lgwQFYn1elKRdQOgXkqu/t+71ebuxLDpCMMJmPcE2y3wj/DfbFI2r
         soh5RtuifBrgD1tQ4aGvQFWNiohaTNPgZe3dXnVsU8wWvJHgSYzIZLM7WphjszcmZXGe
         AxM9enOSLl3SbLkL/wLlcx/4WFFxSTWmbxlt6+qs0lDqmlTAFUrzH6RQh7UX6F+0sb+2
         V43w7dx8Jbqapgi3CYEFndtR2Sb3vKQHypfn6pW41nTK4cl2bKeUasVUQukiE++nzVog
         VMWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785909863; x=1786514663;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=XBygFyzYJYS5+ICqbXp5tbWEYq5wUoX0qFqph9ian3g=;
        b=pV8EyPg7NfA9BIAtiim/uVVqZsx5FpankDChlcDXAO+4JgJ95j8vyvLoXQT0sYGhmn
         oPhu7yADvQx/FBhtws63fGMVk8HhROU86gBPA5nmgQQpLf2FOURF+AhRVRs5qnK7w4V2
         2luaayIbCccsBpEX2ThF1k3mIzpLLhjyiLmZeclNAwzShuKAqo6l9z3h5zkjKQg+aNx/
         hZKHN+vJu6b0Qlqg3gtxNVZiJVfva8jfLgrS8AHSsJ+zEjWs+7rrEV8ytuSX85Xq+kcd
         iDUs7qWLDP7dOL7POTYH7e8pwY3Sd8L9dQXvzJa1jIyLydw7Devu8ThRbXirmoPbhLgd
         bPNw==
X-Forwarded-Encrypted: i=1; AHgh+RpptCaLq9A3p7do19SNzy4yIAqkpT3K24r60km1fXqu6JvH98pbtgbnEoGuMUsIBePFac5nj2MW4Qs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBa49D6V47pAphyVzAAtijEBTfOhOoxVXlW08zNH8o77TGXJG7
	dsRm7gBNjzjSrnjATmc82E9y8Fqmaavv4lNLlbu5g+FEUd4FGxe9r/uqtTLnFujWjoF6pF5bB+G
	ex8vbiQ==
X-Gm-Gg: AR+sD10oIyX+jVK0rdX+5yRZiDN+YpuV0RE/1o8SJVc60V0U60XvqceedyD0ScJbVui
	y5vcwm/eoW7hwdut0HvsWCjfRQbr8TmtjOU2X/HleRgdvQ9MggDxsURdkMXp4lDzLLR7XbFZ3EW
	TylAzDW/aWW6TPiDDQY6lvV01WEstqPsSOjoCkhf/Xb0dIOCVDgNoZbM/9XmYOAEqKqrnxCKtTz
	64Va/M+SA21o0k2vZO6XUlxa56x9Zh8dr8I3o/ffirvph31RDBwCE40rvSJfiTVXbGW9Dp3/dT4
	eaCqSq8M8Ggoq8cVI+lxDaexWPuo3Owll1JgtxADoUeMg30VEXPZqZQeEJ78k6alsIloc0+giNd
	3ciDg65lOEnbHRfQLG0QeFN3enS+NcbmSk7QMfUE8n9c1oJQpKFtvM3CL7q4VcU6gRcLFIGauF9
	HgyT2mfRY6+aB/ilWGtyEUbXRZp1K3ivwd6t/ixuc5YIUl6e7Os9HnN9JOKuAxiIvHd4tiG/HeW
	IXtOZVPGzejNX/zwm+tySdYbhove+U/e0LPEBlJj0yiLUm9paU2
X-Received: by 2002:a05:6000:491d:b0:47f:ec8a:214f with SMTP id ffacd0b85a97d-47fec8a2195mr6168363f8f.15.1785909863308;
        Tue, 04 Aug 2026 23:04:23 -0700 (PDT)
Message-ID: <cd877869-3d53-41e4-88b3-df629e4dcbbd@suse.com>
Date: Wed, 5 Aug 2026 08:04:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] x86/alternatives: Rework get_ideal_nops()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
 <20250522150015.555492-3-andrew.cooper3@citrix.com>
 <99a39800-dbba-4d37-afcb-ae041af648f4@suse.com>
 <f15222a9-1d61-4d9c-b923-8e6ad4994af3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <f15222a9-1d61-4d9c-b923-8e6ad4994af3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1785909863-674BE2AC-A40A59FF/0/0
X-purgate-type: clean
X-purgate-size: 1898

On 04.08.2026 19:13, Andrew Cooper wrote:
> On 02/06/2025 10:57 am, Jan Beulich wrote:
>> On 22.05.2025 17:00, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/alternative.c
>>> +++ b/xen/arch/x86/alternative.c
>>> @@ -20,7 +20,7 @@
>>>  #define MAX_PATCH_LEN (255-1)
>>>  
>>>  #ifdef K8_NOP1
>>> -static const unsigned char k8nops[] init_or_livepatch_const = {
>>> +static const unsigned char k8_nops[] init_or_livepatch_const = {
>>>      K8_NOP1,
>>>      K8_NOP2,
>>>      K8_NOP3,
>>> @@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = {
>>>      K8_NOP8,
>>>      K8_NOP9,
>>>  };
>>> -static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
>> ... the (at least visual) connection to ASM_NOP_MAX. Could I talk you into
>> adding build time array-size checks for both arrays, to restore the
>> connection?
> 
> Sorry, but I have no idea what you're asking for here.

    BUILD_BUG_ON(ARRAY_SIZE(k8_nops) != ASM_NOP_MAX);
    BUILD_BUG_ON(ARRAY_SIZE(p6_nops) != ASM_NOP_MAX);

> The use of ASM_NOP_MAX was latently buggy before; it was easy to create
> a NULL deference if the initialiser wasn't filled in when ASM_NOP_MAX
> changed.

Partly, yes. But why make it worse when it can be made at least somewhat
better? Omitted inner entries are reasonably easy to spot. Omitted trailing
entries aren't, hence why even in the original code omitting the array
dimension in the definitions and instead having such BUILD_BUG_ON()s would
have been more robust.

Also note how I said "(at least visual)" - by adding the BUILD_BUG_ON()s,
grep-ing for ASM_NOP_MAX will hit here, providing links to the controlled
arrays. Personally I consider it entirely plausible to possibly bump
ASM_NOP_MAX, as technically we could go up to 15. (Whether going that far
is efficient is a separate question.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 06:24:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 06:24:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382831.1626108 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrV3C-0005kA-8E; Wed, 05 Aug 2026 06:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382831.1626108; Wed, 05 Aug 2026 06:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrV3C-0005k3-4S; Wed, 05 Aug 2026 06:24:26 +0000
Received: by outflank-mailman (input) for mailman id 1382831;
 Wed, 05 Aug 2026 06:24:24 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrV3A-0005jx-R2
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:24:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrV38-005ySU-NT
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:24:22 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72d709-5cb7-0a2a0a5109dd-0a2a4508c4ec-24
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:24:22 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72d716-f659-0a2a45080019-d1558034e9bb-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:24:22 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4955de8797cso3486835e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:24:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994e0356d4sm66585515e9.10.2026.08.04.23.24.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 23:24:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785911062; x=1786515862; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=tYw3nMG1tYUoCk6J6SHQzZAAsmfDb/DNYKs0P2jRYvU=;
        b=BKw+klG0iOZHY7/p6fSGWI9gIoLKUs1y3OmBVDlbHJUKdunninKJRXFF54d7IXhk4X
         nzEQLwUthSQfbUZaNMNHcNVp8BIysHX+gmf1LoxNr4hDCuukfhIr5wn2yPHkqULhGI0H
         HgLzR0UehJaGJS7aPsJElBrSbkMwm9tEOP8TCBgzhaKPb/DRexD4T7dpw2/i3gmoaxnc
         mUDObE5c7rdk5o1w0Pt4V2C+cFg36rgEBFC4Rj4UYFUZx+OySY55yNxR/JFLwB/Cp3X3
         7xNH2FCoxhs8MQu3PY5RhZsn28Kz0GbmNw/S5ZQRjzud1DjHU9zjMFfNfptfOiZoNh/r
         L8UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785911062; x=1786515862;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=tYw3nMG1tYUoCk6J6SHQzZAAsmfDb/DNYKs0P2jRYvU=;
        b=Mtg0wE63BuVG6d8R/+TqaZzrLjVcoYC/WYTiAtAd4LrkHIpZ1Z6TDtMpx7gICsY+bJ
         fdGr1DIAe8/tCDHXgUoEpIhTm5JJYmLpHuCWdu7VIu/JNYL2yeJuAFx0HZDx9+0JzE9/
         ML2eg2zP2bJIww9Ctc+h8+xLJlsFFQJ5TDACJqnfn9h4g22G/9QrDjaKY8L3G8j3jQ6n
         phsVwe65x+lE0tTdCXpioOvOrcHvL9ENcjieySp8Wbaezdrl72nOriDs6rCnUu8hmwaF
         2yLuqSE/rbsxGG/gEizkGalOFoUrM8Ypc7mDnYgxuCFMvaB+c9Zd6CN9tdSDovh3ZMIV
         EsxQ==
X-Forwarded-Encrypted: i=1; AHgh+RrIDiufsIns3wDkRvCO9IiGGj/5jbLs6ZyrqUtq0xZzusMfhS/2BXg9rInQVleeNdVHqmLXczQXsgQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YycAXbT2Vvw+Om3C6awHVdVu0zMXUXZzubJMSOIKCWsTll9uqGn
	TE/V9I8Ikmn1Vl9WXBrkXo3Fdeb5h+NCg1whuKoK9M0ccH4JgJO7j+5MPhBTtejQNA==
X-Gm-Gg: AR+sD1165FJ64qxUhY7ODPgmZmd93tlY2O9wHN88siVX42EhOfNmSjpvWv83PectX0z
	HqAGmmtnhLf4RWeH1AGazWFOYNXnNiB8j6c9dpgFsuvY6zmRTxwcnqF5FRjf+ck4D0fGjgndyIz
	Xy4DeSF9MQheP4ST3AndccJd8n+cBRkanaZy7AAJzqf/poVb66Z5BgyQcgfS6iFtIlX1DTJRAzW
	Qnf32P+ZZ6YdsWqYZyzLuvx7PW6frj+/5ewHPhlPXaRXydub3+bHkvizQ4wH8XAsiY+UMHGIDlI
	VfNUAB3H3qWIeBRnGL5FYgNymciQq/FGNBXd5Wxa+U6fTj7HYvyI56Feu+3d0HwY07xxSZ9M0n/
	hP38PasfYzj1TWO1/bQd9KLrQ9P72oWcn6eTMvRX3PMyWRx0oadDyBZhfPYnkLeC8FRkNHVwdGL
	cgtIRg7+Jd+vUG6MJhIyf+5o1Pr6ygf79vcUFRhoupEZqXoWo86cLLha0DfJNxvDpxIcXiRlCgG
	HV/o1xX11JkPfUiDB9/7XRpLSDl8ytQv4i3pJmz5xJhOHL1OpQyJGyubbcVhyM=
X-Received: by 2002:a05:600c:529b:b0:493:a613:56b2 with SMTP id 5b1f17b1804b1-4994e71d3e5mr47925195e9.8.1785911061197;
        Tue, 04 Aug 2026 23:24:21 -0700 (PDT)
Message-ID: <205b4024-c42f-48b6-a106-913b06485e53@suse.com>
Date: Wed, 5 Aug 2026 08:24:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/5] x86/emul: Introduce x86_decode_lite()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-2-andrew.cooper3@citrix.com>
 <01b27228-fdc0-4546-aa23-2bcdafb22727@suse.com>
 <1e1a1c4d-5ffc-44b1-b26c-244c9af1f250@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1e1a1c4d-5ffc-44b1-b26c-244c9af1f250@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785911062-D6F5F87B-3799B6E3/0/0
X-purgate-type: clean
X-purgate-size: 8566

On 04.08.2026 20:56, Andrew Cooper wrote:
> On 03/08/2026 4:26 pm, Jan Beulich wrote:
>>> +        [0x50 ... 0x5f] = (Known),             /* PUSH/POP %reg */
>>> +
>>> +        [0x62]          = 0,                   /* BOUND, but also EVEX prefix, not implemented. */
>>> +        [0x63]          = (Known|ModRM),       /* MOVSxd */
>>> +
>>> +        [0x68]          = (Known|Imm),         /* PUSH $imm */
>>> +        [0x69]          = (Known|ModRM|Imm),   /* IMUL $imm */
>>> +        [0x6a]          = (Known|Imm8),        /* PUSH $imm8 */
>>> +        [0x6b]          = (Known|ModRM|Imm8),  /* PUSH $imm8 */
>>> +        [0x6c ... 0x6f] = (Known),             /* INS/OUTS */
>>> +        [0x70 ... 0x7f] = (Known|Branch|Imm8), /* Jcc disp8 */
>>> +        [0x80]          = (Known|ModRM|Imm8),  /* Grp1 */
>>> +        [0x81]          = (Known|ModRM|Imm),   /* Grp1 */
>>> +
>>> +        [0x83]          = (Known|ModRM|Imm8),  /* Grp1 */
>>> +        [0x84 ... 0x8e] = (Known|ModRM),       /* TEST/XCHG/MOV/MOV-SREG/LEA */
>>> +        [0x8f]          = 0,                   /* Grp1A - POP but also XOP prefix, not implemented. */
>> POP doesn't look all that unlikely to be used in inline assembly, and
>> hence in alternatives. That said, of course using it with a memory
>> operand requires quite a bit of care.
> 
> We have no alternatives playing with the stack (beyond CALL
> instructions), and no alternatives which have any net %rsp delta.
> 
> PUSH/POP MEM are rare in general and Xen doesn't have any at all.

Well, okay then. Nevertheless I'd like to mention that the encoding can
also be used for REG forms. If needed for size reasons, that may or may
not be more efficient than adding a NOP or no-op prefix.

>>> +        [0x90 ... 0x99] = (Known),             /* NOP/XCHG %rAX/CLTQ/CQTO */
>>> +
>>> +        [0x9b ... 0x9f] = (Known),             /* FWAIT/PUSHF/POPF/SAHF/LAHF */
>>> +        [0xa0 ... 0xa3] = (Known|Moffs),       /* MOVABS */
>>> +        [0xa4 ... 0xa7] = (Known),             /* MOVS/CMPS */
>>> +        [0xa8]          = (Known|Imm8),        /* TEST %al */
>>> +        [0xa9]          = (Known|Imm),         /* TEST %rAX */
>>> +        [0xaa ... 0xaf] = (Known),             /* STOS/LODS/SCAS */
>>> +        [0xb0 ... 0xb7] = (Known|Imm8),        /* MOV $imm8, %reg */
>>> +        [0xb8 ... 0xbf] = (Known|Imm),         /* MOV $imm{16,32,64}, %reg */
>>> +        [0xc0 ... 0xc1] = (Known|ModRM|Imm8),  /* Grp2 (ROL..SAR $imm8, %reg) */
>>> +
>>> +        [0xc3]          = (Known),             /* RET */
>>> +        [0xc4 ... 0xc5] = 0,                   /* LES/LDS but also VEX prefixes, not implemented. */
>> This may bite us sooner or later, due to the VEX-encoded integer insns
>> that there are. Of course as long as we don't use this function on
>> compiled code, and as long as my "x86: allow Kconfig control over psABI
>> level" doesn't come close to going in, that's merely a theoretical
>> concern.
>>
>> Same goes for not supporting the 3-byte opcodes, which also encode
>> certain integer insns.
> 
> I have no doubt that we're going to need to add support eventually.
> 
> But,
> a) I don't have time right now
> b) We have real bugs/limitations right now needing this functionality to
> address (patch 5, and the xsave fixes, and bus lock trap enablement)
> c) GitlabCI will reliably notice any new alternative instructions that
> this can't decode (patch 3)
> d) This function is a fastpath during the alternatives patching critical
> region (patch 4)
> 
> Option d alone is a good reason not to decode VEX prefixes yet.

Personally I think a is most relevant. As said in the later reply, once
we start using MSR-IMM insns, at least VEX3 map 7 will need decoding
anyway.

>>> +        [0xe4 ... 0xe7] = (Known|Imm8),        /* IN/OUT $imm8 */
>>> +        [0xe8 ... 0xe9] = (Known|Branch|Imm),  /* CALL/JMP disp32 */
>>> +
>>> +        [0xeb]          = (Known|Branch|Imm8), /* JMP disp8 */
>>> +        [0xec ... 0xef] = (Known),             /* IN/OUT %dx */
>>> +
>>> +        [0xf1]          = (Known),             /* ICEBP */
>>> +
>>> +        [0xf4]          = (Known),             /* HLT */
>>> +        [0xf5]          = (Known),             /* CMC */
>>> +        [0xf6 ... 0xf7] = (Known|ModRM),       /* Grp3, Further ModRM decode */
>>> +        [0xf8 ... 0xfd] = (Known),             /* CLC ... STD */
>>> +        [0xfe ... 0xff] = (Known|ModRM),       /* Grp4 */
>>> +    };
>>> +    static const uint8_t init_or_livepatch_const twobyte[256] = {
>>> +        [0x00 ... 0x03] = (Known|ModRM),       /* Grp6/Grp7/LAR/LSL */
>> Leaving out INVD is surely find, but WBINVD?
> 
> Given now expensive WBINVD is, what possible reason can you think for
> having it in an alternative ?

It's more like e.g. WBNOINVD, which could appear in an alternative in
principle, if its encoding didn't mean WBINVD anyway on older hardware.

>>> +        [0x0b]          = (Known),             /* UD2 */
>>> +
>>> +        [0x18 ... 0x1f] = (Known|ModRM),       /* Grp16 (Hint Nop) */
>>> +        [0x20 ... 0x23] = (Known|ModRM),       /* MOV %cr/%dr */
>>> +
>>> +        [0x30 ... 0x33] = (Known),             /* WRMSR/RDTSC/RDMSR/RDPMC */
>>> +
>>> +        [0x40 ... 0x4f] = (Known|ModRM),       /* CMOVcc */
>>> +
>>> +        [0x80 ... 0x8f] = (Known|Branch|Imm),  /* Jcc disp32 */
>>> +        [0x90 ... 0x9f] = (Known|ModRM),       /* SETcc */
>>> +
>>> +        [0xa0 ... 0xa2] = (Known),             /* PUSH/POP %fs/CPUID */
>>> +        [0xa3]          = (Known|ModRM),       /* BT */
>>> +        [0xa4]          = (Known|ModRM|Imm8),  /* SHLD $imm8 */
>>> +        [0xa5]          = (Known|ModRM),       /* SHLD %cl */
>>> +
>>> +        [0xa8 ... 0xa9] = (Known),             /* PUSH/POP %gs */
>>> +
>>> +        [0xab]          = (Known|ModRM),       /* BTS */
>>> +        [0xac]          = (Known|ModRM|Imm8),  /* SHRD $imm8 */
>>> +        [0xad ... 0xaf] = (Known|ModRM),       /* SHRD %cl/Grp15/IMUL */
>>> +
>>> +        [0xb0 ... 0xb9] = (Known|ModRM),       /* CMPXCHG/LSS/BTR/LFS/LGS/MOVZxx/POPCNT/UD1 */
>>> +        [0xba]          = (Known|ModRM|Imm8),  /* Grp8 */
>>> +        [0xbb ... 0xbf] = (Known|ModRM),       /* BTC/BSF/BSR/MOVSX */
>>> +        [0xc0 ... 0xc1] = (Known|ModRM),       /* XADD */
>> What about MOVNTI?
> 
> I judged that to be on the unlikely side to be needed.

Hmm, I'm not going to insist, but I think we'd better have it right away.

>>> +        [0xc7]          = (Known|ModRM),       /* Grp9 */
>>> +        [0xc8 ... 0xcf] = (Known),             /* BSWAP */
>>> +    };
>> What about UD0?
> 
> UD0 differs between vendors and product lines from Intel.

Would you mind leaving a commented (to this effect) 0 entry?

>>> +        if ( mod == 1 ) /* disp8 */
>>> +            FETCH(int8_t);
>>> +        else if ( mod == 2 ) /* disp32 */
>>> +        {
>>> +        disp32:
>>> +            FETCH(int32_t);
>>> +        }
>> In several cases the FETCH()ed value isn't used. Compilers as well as Eclair
>> (and alike) are happy with that?
> 
> Yes.  The cover letter has a fully passing pipeline.

Which you know as well as I do, says next to nothing, as we don't even come
close to covering the complete version range. That said, it's likely good
enough. I'm merely surprised no tool has to say anything about these unused
"return" values of the macro.

>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>>> @@ -835,4 +835,18 @@ static inline void x86_emul_reset_event(struct x86_emulate_ctxt *ctxt)
>>>      ctxt->event = (struct x86_event){};
>>>  }
>>>  
>>> +/*
>>> + * x86_decode_lite().  Very minimal decoder for managing alternatives.
>>> + *
>>> + * @len is 0 on error, or nonzero on success.  If the instruction has a
>>> + * relative field, @rel_sz is nonzero, and @rel points at the field.
>>> + */
>>> +typedef struct {
>>> +    uint8_t len;
>>> +    uint8_t rel_sz; /* bytes: 0, 1 or 4 */
>> Perhaps use bitfields in favor of fixed-width integers, seeing what
>> ./CODING_STYLE says?
> 
> No.  That destroys the code generation improvements gained by returning
> a pair like this in the first place.

I was under the pretty clear impression that halfway recent compilers
treat 8-bit bitfields the same as uint8_t ordinary fields. (And no, I
did by no means suggest to shrink the width of the fields.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 06:34:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 06:34:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382842.1626117 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVCl-0007Xk-6z; Wed, 05 Aug 2026 06:34:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382842.1626117; Wed, 05 Aug 2026 06:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVCl-0007Xd-3s; Wed, 05 Aug 2026 06:34:19 +0000
Received: by outflank-mailman (input) for mailman id 1382842;
 Wed, 05 Aug 2026 06:34:17 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrVCj-0007XE-HE
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:34:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrVCi-00Gy9x-5H
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:34:16 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72d95b-e002-0a2a0a5209dd-0a2a4509e9e4-30
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:34:16 +0200
Received: from [40.107.208.18]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72d964-be1a-0a2a45090019-286bd0120776-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:34:13 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SJ0PR03MB5390.namprd03.prod.outlook.com (2603:10b6:a03:283::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Wed, 5 Aug
 2026 06:34:10 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Wed, 5 Aug 2026
 06:34:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lTVC3FtCvy+VigUE4FqzJ62CA+rpBXz039+lraKmhc1s29p/jQz3Ftj8XGNTVaFX2amJFNEuCk0e0SArgENnl9STmUZzUx1Gugk2UNtxBSBwyCW+APthsOP5JmWv5/e6bvGlsQeswgcCsPY16l4s2sG/INW1hVJPBmf1LdhCYjYRmg+bmwtieGhxT+7yRGqcIWiWm7uHkRBDoMhCOxoY+/Bg7teNSLuU45tLXqxJjtF38agDh0rYrJ7Y140eiV/goJ33TwRMTGhV6x07XbaXEplp3IC7ZJK+2MdNRJKfFwUfMjPQXQlyMNv/BG3fPL0p03Jr7Wfmtt+xkf65NGeciA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GLC7heUy9BDy1rqMYEtuJeVL80ZKUo5HkS3gzicNHuc=;
 b=QM6JLM09VXeMnfOnnKXBYi0mnrmDfhExdoDs9xCBFA60XXZcH8KfV1Q01r7MgtPhMp3bdxs28XPSgeg40hOtByZLjggNmJr28uux+mQQBsmOUW/RBtKQdRJmHwOPOgcpAB8cRQiftaJFWO50H2fSNAbxMwZxMcF6RN0bIaqVYGVebti07MMxZvyLAsKtHgBwgJ4K0B2oYIma8qgDUYtZpTeZPs4bhkcjHx7WEu36WWQFk7w9LKsK2+CYw40ltxq1nSyogxRb09M71poufoHv1aJQ3PX013sXbb3BZIal3FKmaX52b6OaNfuG0Y7EAodnhPeK+IBn0lUSGDUE6w099Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GLC7heUy9BDy1rqMYEtuJeVL80ZKUo5HkS3gzicNHuc=;
 b=0ncq+SGxjDYfBQuE17MDuQaFshKpO7Lk2fMqyco+rcVATt7zQy0mGZbm3oywDGj3yKxgklkYbUI1vcyHiom1CGv8VEOb44mTVdR+KABfvwIvtOH14t4d6Tx3VfE5bYDLHKAEkLiSuoHpKFDhTgNt3xaYqQg+lAmQTYzLXsNSzt8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <5d62cfe6-3d97-44f4-9a5f-94b77514b6a3@citrix.com>
Date: Wed, 5 Aug 2026 07:34:07 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/3] x86/alternatives: Rework get_ideal_nops()
To: Jan Beulich <jbeulich@suse.com>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
 <20250522150015.555492-3-andrew.cooper3@citrix.com>
 <99a39800-dbba-4d37-afcb-ae041af648f4@suse.com>
 <f15222a9-1d61-4d9c-b923-8e6ad4994af3@citrix.com>
 <cd877869-3d53-41e4-88b3-df629e4dcbbd@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <cd877869-3d53-41e4-88b3-df629e4dcbbd@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0349.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18d::12) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5390:EE_
X-MS-Office365-Filtering-Correlation-Id: f169db0f-e7c0-4ff6-a43b-08def2bb8ecc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|22082099003|18002099003|4143699003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	UfjzMX1qQVDhLtkP6UitkOyfB46TynpEaxj1ORrxUb0L38i+IPytyCY4glh1y2nA8B9P0BUhYvz8yh0MjFtV9EFZff+zCN5+/j4AgTaWEjSkguxFMdJxT4B2IEGYkx/YlIYwR7lQy987o2kem5kibOrTky3SQGtyjOoHoQhL2VpV1Eoj8X9OAZ+ZErscCfmIYMs8LBU+mYEyYjXnNakbO3mkF6vhTISZunnDJ3458asZiXOPABYKD6Zuor81yZpJXTiMjHAuVvhyYlADr2/yFuG+jMzJkN1cBmxHytaD+yYfcrsYvUgMCrRrODYAgf1ZKEqyzFZToTUTPR3+E/zE/1BG5AHL8eNifx2IEnmcKbEJ0q28iIZwGZWrAKD3Sb7KlyNLrPwOsKhsMcvCwrheZCDtWuqRrvy8Eb+Xx1IKVTTXybW8Wo5b389/4T4D5V7qF7AK78CH8R6hAwgblRc9TXJN/WurUJ5ZhbY44FJkpVOVBOMgpXUFbupfm1SbmaYlcXhxUOGfQCtww9UUdIlF4uOr61Dk6HjG/nxQlB7vF0yxMgJrI18sqbFuh395k21fYOX1b5dGbZxGppWBtig9mifhhxObs3KkVotMObZjFQId+9e1HY03ymUgPLWIQFsmot2l+HDNKSxnupqXLEPV0N6afa6ZXlmuTxymTac5j08=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(22082099003)(18002099003)(4143699003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?U3pyakJHeEE2V2QyU2ZvUzF0cXVYSzREOEpNc1FFcWJRNHhpb3hNdGdQVjAx?=
 =?utf-8?B?NTEwdnNBWE5NbXNWemRud1J5N1ZOb1VmMmhVVEtqdytUaTFlTGFYM1UzdTBJ?=
 =?utf-8?B?ZjIzeHJhaGFUaVlMT3pZSEZUMC9sWm1SWWtkSDFYY2puNFlKcUtBSEtkK3VC?=
 =?utf-8?B?ZE1RZXlXUUZVNFBUSWJWQ0s2K29vN21KeFJGQVROYk5kOHNISnNUQ2IrMXBx?=
 =?utf-8?B?clo1c1g2TmhDdHNkN2tsbnJEZEZKOTZOb213VEdubDlrQWlINmUzOTZwYVVL?=
 =?utf-8?B?TjZYZGRRS2daMEw0K2dFZTU2eWdFWnZWdkJ4RHQ0STNyVVUybEtub3doZmFB?=
 =?utf-8?B?cjZaREVEWHQ4TDhjL1FzR3J2UEpzK2Z1cXdYMGRyK212Z1Y2V01FWjdueVFK?=
 =?utf-8?B?TFVxaVpSaHE2Sk1SY2pURVBOTzhtVGlXQStlZXdTVVMweHhCTnBjcnE4ZVIx?=
 =?utf-8?B?NUlsNm5uTU5uVWJZSllyVG9sWlYwSC91Ym5MN3ZGd2NjTGVSNXAzQkUxL1Rr?=
 =?utf-8?B?dUlGY3NrdzNPVmJ2VDFJUzlNcVkzUnF6OU9tTjh4S0duYW5TRDJZUzFzaXZ4?=
 =?utf-8?B?YlU3TytLZmNKWXpsNGVHRGVVMWYraUFXcDJuR1BvZ3Y4RXNuUmZ4UXZpSnJm?=
 =?utf-8?B?SkpvajZiMWdaRThhREhFd1MyTHQrdlJRRFBBVG5TMU9aRzRoVndWek1IVTdL?=
 =?utf-8?B?Y0lEamw4M3hweUFRWFFPZm5yZnQweURLYnpic3E5b0U1Uzc2MXg2TkZmVXBF?=
 =?utf-8?B?QmNYN2tndDlqb2ZaczdkSld6MGpDa29VSVBuR2x2WWljbGlxYllrOWtjbFFj?=
 =?utf-8?B?dHhYSEFwRFBlZnpPNnlOV0JNRzd3OXpYWVRDZGprWWZNVUVsZms0SENvYU4z?=
 =?utf-8?B?SzVtNTYrUHpuOGlPTkQ3Nm11bGFRNGUvTytRU0tWc0xvVlM2c1BqakJwYity?=
 =?utf-8?B?bWFQUUh3YTRSUnd4V2RFcnFQeVFIcU81R0xOVGZUL1BMM0dCSDVGWkdLL003?=
 =?utf-8?B?aFBkeXNFWFFPOFk2TUYxN2NtV3EycVI4SVF1Vi8zamFmSmd2SVZEeUMwbHJ4?=
 =?utf-8?B?UEdPNnVQZ2Z2UWZSanNsQm9OTks5V0phR0Nuc3V3cVA5ei9hVytMYUd1WVRK?=
 =?utf-8?B?TTBGaGRTdUMwQStxUDlvUllCMmNLbWVLbzNFdDBpUnd6ZUhYWTdVOGwrWm9i?=
 =?utf-8?B?M0l2VVdraHNJSlRWL1JOakFTQXdQdDF5U2RBRG5ORjZkanhzZXZrRU8zMGVn?=
 =?utf-8?B?N09yVk9kaEpsMUFzNmNFTitjbzQ4RmhLUTI3KzJZODd4SjF3eXVDMVRNU2Jo?=
 =?utf-8?B?eW5aLzNDaE9WNThKbnlzck4vNnFlZHI1bFNtSVB0a3BiZ002UUl2bG45aVRu?=
 =?utf-8?B?eFY5bk1laFhZUGFGV2EydmVIZTBQY0E4Tnlpa2VnMndzbFB6TUlvL1RVUW9q?=
 =?utf-8?B?akI3WkY4SUxKMmk0TUplUkFXSjB0RXNjRDdPeHdLSk1zMDFGMW1PNjFneSt5?=
 =?utf-8?B?RCsrMXBnclVrN0dLS2cvZW5TUE5TbU5WKzd5amNGVzFSUE93T2wvOHdHeVpV?=
 =?utf-8?B?eUhMNWEzUEtIc0ZBc2pqRk9CZ2d0NzRQbXFCMFdFVEE0WEw1VTUram5xd1JG?=
 =?utf-8?B?eEszKzUzSmR0K2xqNk5uNUlTL3E4bWhRcUFFemsrWUk1b3U0Z3Z5WFJPdUU4?=
 =?utf-8?B?SzV0VGZkRWlFMC9UYU1aYnVLTjk0OXBLWWw5NHZOYjUvU1BjNElXZlRhYk96?=
 =?utf-8?B?aFA5U1hJVmhHQWEvRElrem5OVXZhNU53cGxObGE0ZzRrNVZub25CTFpubE5L?=
 =?utf-8?B?cnZBcTAvaU56ekEzY2gxVmM2MkZsYWtDUyt4TGpmb1hrQzJmdEZNV3l6NlhE?=
 =?utf-8?B?VmtRWDM1N0pVQlVVNGlVemhuWGRnUmxoYUI3ZktkSFBUekZWNlYyaWVnbE1Y?=
 =?utf-8?B?eElLazhOdnZpVGZxMi84ZEsrN2g4UDhFUlBCMm5PRDFKUlcyZ0EwcjRWN3Nq?=
 =?utf-8?B?d0xGMnJJRHdsK1dYaEdGWTgva25TRmY2RUhUTSs0RCt4V2lpYmx4MURyelAv?=
 =?utf-8?B?NE9KeTdnM3NvVW5mTXdEMlRxd1pwT2RZcUIxSHRDNHhQcVJQb2Z1RnFZbXNQ?=
 =?utf-8?B?VXh1NW0vQ3E4TUZvVTN4RlBkSlRQV0Q2RGdCdkFXeVU3UWNPb0dnbW5RaUpo?=
 =?utf-8?B?RS9FTW94UnpsV2FrNzVURklNaUZXNXBLZVhta3k2Q1NhenZCLzhLVko4Rllk?=
 =?utf-8?B?S0pheUE1YjY4R04wcDQyUk9EVEEyZ2hibnVCcVpUV0d5OTFKMTY0ODRlWW53?=
 =?utf-8?B?ak9Zbk9FK1ZoeE8zbVUvKzRPNldOemVhM0xyVXNZNnNnYStkSkkyYktHKzU3?=
 =?utf-8?Q?Wn3xmJXuw2vPXprI=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f169db0f-e7c0-4ff6-a43b-08def2bb8ecc
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 06:34:10.2548
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: LX3taPssTcnlDsPKLVJpkD5s3NR7FrdXicefjtY4w9Q0he22/nS5r5pb+72k/yFgGovU4rl0DWZMG0Ys2Q5rSB0WPn2RrsbASJ3XDJAFjEg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5390
X-purgate-ID: tlsNG-bad1c0/1785911654-BEEDE034-37D86F9B/0/0
X-purgate-type: clean
X-purgate-size: 1622

On 05/08/2026 7:04 am, Jan Beulich wrote:
> On 04.08.2026 19:13, Andrew Cooper wrote:
>> On 02/06/2025 10:57 am, Jan Beulich wrote:
>>> On 22.05.2025 17:00, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/alternative.c
>>>> +++ b/xen/arch/x86/alternative.c
>>>> @@ -20,7 +20,7 @@
>>>>  #define MAX_PATCH_LEN (255-1)
>>>>  
>>>>  #ifdef K8_NOP1
>>>> -static const unsigned char k8nops[] init_or_livepatch_const = {
>>>> +static const unsigned char k8_nops[] init_or_livepatch_const = {
>>>>      K8_NOP1,
>>>>      K8_NOP2,
>>>>      K8_NOP3,
>>>> @@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = {
>>>>      K8_NOP8,
>>>>      K8_NOP9,
>>>>  };
>>>> -static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
>>> ... the (at least visual) connection to ASM_NOP_MAX. Could I talk you into
>>> adding build time array-size checks for both arrays, to restore the
>>> connection?
>> Sorry, but I have no idea what you're asking for here.
>     BUILD_BUG_ON(ARRAY_SIZE(k8_nops) != ASM_NOP_MAX);
>     BUILD_BUG_ON(ARRAY_SIZE(p6_nops) != ASM_NOP_MAX);

The arrays are 45 bytes (and elements) long.  ASM_NOP_MAX is 9.

>
>> The use of ASM_NOP_MAX was latently buggy before; it was easy to create
>> a NULL deference if the initialiser wasn't filled in when ASM_NOP_MAX
>> changed.
> Partly, yes. But why make it worse when it can be made at least somewhat
> better?

On the contrary, I've removed an incorrect (and ineffective) attempt to
tie to ASM_NOP_MAX, and consider this form better than what was there
before.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 06:45:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 06:45:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382851.1626125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVNe-0000yE-4o; Wed, 05 Aug 2026 06:45:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382851.1626125; Wed, 05 Aug 2026 06:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVNe-0000y7-2C; Wed, 05 Aug 2026 06:45:34 +0000
Received: by outflank-mailman (input) for mailman id 1382851;
 Wed, 05 Aug 2026 06:45:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrVNc-0000y1-8o
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:45:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrVNb-00B8I4-1D
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:45:31 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72dc07-5cb7-0a2a0a5109dd-0a2a450bed12-14
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:45:30 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72dc0a-b7e8-0a2a450b0019-d155dd32f15f-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:45:30 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47f7872abb6so275049f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:45:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfda0d7sm5935370f8f.2.2026.08.04.23.45.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 23:45:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785912330; x=1786517130; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LdT17TjKaxzE87YoDYMRL848nK49edta2evd9yGu/dI=;
        b=YZpqR9qDSxMDRClRcahcKvJSkgQTLv+4UM7S+rCunLQGcVzdaOHlBHpy6gfWJLNB7M
         6m2DSEgBCBYfJYVpIdUOnV95yDIVIMvf9JHmm3eKBPCChabzLAK3Uc3CHuee27bB2fJF
         tM4Fyw+VKSAays2G9cHIWAtw7ddZHIxNzHfdwg6ABk0NEDUowl+uabGAQD5P6ikxrNur
         afb0UwKycuLneVGvyqQaiih1ZWaszGt6LsagXPsuI5F+u+RFHN3Tmnms67OfLVAO0vrt
         PW0uLcH/wjdldv2I6VGgG7X1arMgv8fSpbPWCRJVw7l/8JSlS/b5IFrviUBEaiilbZaJ
         G6yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785912330; x=1786517130;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LdT17TjKaxzE87YoDYMRL848nK49edta2evd9yGu/dI=;
        b=XpoSoBmFKB/wMHgSk4x5QIKma6f7Vle0NdE9eH2k7ww2p1MAeWZYra0+AKzZzE2872
         FgEe2v13JBYr2PNZsXkoQaalL9efNE0YHT4g8W+cycwuwwhAjZdGuzRusL3TfPm+2Qj0
         LmYPHJzNVTxu0qYySiNNJLhqn/iJFDNnGqw+YC20bcnrtJP7IDSleuFTYERjpxglZCMK
         tcFxbsfJ2LIlMxnGiwuyhkosd1wSjBi178YLOGXiVmcVoDFpFx+uBe6lvhmWqfHAAjSh
         iBExTm2eT7igz8XePkiD8on5LzCpduQWSppwWr7Dq8jVsFE9dnkOAtqWJw13BXlxgtKB
         6jTw==
X-Forwarded-Encrypted: i=1; AHgh+RpJ/XkPwCOUKOQV+pgXArRgfXfkwrjgzdIt8SZXCS1bOmZoI6gYIsVF+DuhsN8afeStWYAevEVzwqI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyID3S67iv4nS7YDwHonZjpcXIEvp9nlNTvKw8yJKp9DYoBX2Tu
	z6/0yfkojW09L+li3VSQ3PbtSzoGTNuCWhWbEx1TXmAygECjKn8LVnJ2BnoTvprYVoGLEEu/tiU
	5aJGVfg==
X-Gm-Gg: AR+sD107p/W1NTaZOYaEUU5SogbOtAWzxHDusXVB6/OBfvdXtGa++z5vKh1dvxpzodn
	vsi+Qc9nXf29ySZszhUmURNNSc67npQsnUWqQY3YvPQLkmy1HtFS6MVgZumV47POuKBX+KEogC6
	4qjtN4msCX4gPj8/DrB/O4GW4j+DuMeYuoMWOD3i7gFYkygTObi0YDE8fs2UPYxTkx+mclIIeRv
	Df/aSgSAl2WSoeESlcdJ4vQK+SONtytvY/WSuf3DCBmveWPI1/Zkqp+sNwX4tB75P0kCK2FbhJV
	eFmKxuZEEywwoUcD3PvPWXSJ4n2l7Irj9/4oHIIr54jQS/25zr4VlcPMSGUURh/QfTFE+k0UmIV
	mM1iWH995ZvIhEzsjCUe2hlznBDwmtKvM4j2ab8PVwgN3OaWrMHzYfiGNa6NhPROZzrYB6m+dv0
	YJ+m8lARog3pHYNPTxOXQBVSPlN7lkiQVKxVqKyARiccJGn2PhwU8/1PlKq5kFWu3unA4Ha8Pcj
	exEfbu4QvroZJ6xaolUQQF2D64CcYXdsjLy5s/yhAOMb9GhE4pd
X-Received: by 2002:a05:6000:601:b0:47f:81c4:36b4 with SMTP id ffacd0b85a97d-47fec52172amr6515452f8f.14.1785912330171;
        Tue, 04 Aug 2026 23:45:30 -0700 (PDT)
Message-ID: <b76b3fa9-cac9-401f-adc7-88f6881a64f6@suse.com>
Date: Wed, 5 Aug 2026 08:45:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] tests/x86: Introduce a userspace test harness for
 x86_decode_lite()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-3-andrew.cooper3@citrix.com>
 <dd065a33-0105-4527-92f5-f3f127422ee6@suse.com>
 <21d3fae8-e9b0-4c8a-a7b9-483a0257e44e@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <21d3fae8-e9b0-4c8a-a7b9-483a0257e44e@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785912330-A9EC69EA-AD3522B9/0/0
X-purgate-type: clean
X-purgate-size: 13130

On 04.08.2026 21:37, Andrew Cooper wrote:
> On 03/08/2026 5:03 pm, Jan Beulich wrote:
>> On 03.08.2026 09:20, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/tools/tests/x86-decode-lite/insns.S
>>> @@ -0,0 +1,703 @@
>>> +#include "macro-magic.h"
>>> +
>>> +        .code64
>>> +
>>> +        .allow_index_reg
>>> +
>>> +        .text
>>> +
>>> +DECL(tests_rel0)
>>> +modrm:
>>> +        /* Mod=0, Reg=0, RM {0..f} */
>>> +        _ add %al, (%rax)
>>> +        _ add %al, (%rcx)
>>> +        _ add %al, (%rdx)
>>> +        _ add %al, (%rbx)
>>> +        _ add %al, (%rsp) /* SIB */
>>> +        /*add %al, (%rbp)    RIP --> tests_rel4 */
>>> +        _ add %al, (%rsi)
>>> +        _ add %al, (%rdi)
>>> +        _ add %al, (%r8)
>>> +        _ add %al, (%r9)
>>> +        _ add %al, (%r10)
>>> +        _ add %al, (%r11)
>>> +        _ add %al, (%r12) /* SIB */
>>> +        /*add %al, (%r13)    RIP --> tests_rel4 */
>>> +        _ add %al, (%r14)
>>> +        _ add %al, (%r15)
>>> +
>>> +        /* Mod=1, Reg=0, RM {0..f} */
>>> +        _ add %al, 0x01(%rax)
>>> +        _ add %al, 0x01(%rcx)
>>> +        _ add %al, 0x01(%rdx)
>>> +        _ add %al, 0x01(%rbx)
>>> +        _ add %al, 0x01(%rsp) /* SIB */
>>> +        _ add %al, 0x01(%rbp)
>>> +        _ add %al, 0x01(%rsi)
>>> +        _ add %al, 0x01(%rdi)
>>> +        _ add %al, 0x01(%r8)
>>> +        _ add %al, 0x01(%r9)
>>> +        _ add %al, 0x01(%r10)
>>> +        _ add %al, 0x01(%r11)
>>> +        _ add %al, 0x01(%r12) /* SIB */
>>> +        _ add %al, 0x01(%r13)
>>> +        _ add %al, 0x01(%r14)
>>> +        _ add %al, 0x01(%r15)
>>> +
>>> +        /* Mod=2, Reg=0, RM {0..f} */
>>> +        _ add %al, 0x7f000001(%rax)
>>> +        _ add %al, 0x7f000001(%rcx)
>>> +        _ add %al, 0x7f000001(%rdx)
>>> +        _ add %al, 0x7f000001(%rbx)
>>> +        _ add %al, 0x7f000001(%rsp) /* SIB */
>>> +        _ add %al, 0x7f000001(%rbp)
>>> +        _ add %al, 0x7f000001(%rsi)
>>> +        _ add %al, 0x7f000001(%rdi)
>>> +        _ add %al, 0x7f000001(%r8)
>>> +        _ add %al, 0x7f000001(%r9)
>>> +        _ add %al, 0x7f000001(%r10)
>>> +        _ add %al, 0x7f000001(%r11)
>>> +        _ add %al, 0x7f000001(%r12) /* SIB */
>>> +        _ add %al, 0x7f000001(%r13)
>>> +        _ add %al, 0x7f000001(%r14)
>>> +        _ add %al, 0x7f000001(%r15)
>>> +
>>> +        /* Mod=3, Reg=0, RM {0..f} */
>>> +        _ add %al, %al
>>> +        _ add %al, %cl
>>> +        _ add %al, %dl
>>> +        _ add %al, %bl
>>> +        _ add %al, %ah
>>> +        _ add %al, %ch
>>> +        _ add %al, %dh
>>> +        _ add %al, %dl
>> Perhaps also include %bpl, %sil, and %dil?
> 
> They're not relevant to this test, and interfere with the intentional
> pattern set up.

Hmm, how does a particular pattern matter here? I don't think you test those
cases (or more generally an empty REX prefix) anywhere else.

>>> +DECL(tests_rel1)
>>> +disp8:
>>> +1:
>>> +        _ jo   1b
>>> +        _ jno  1b
>>> +        _ jb   1b
>>> +        _ jae  1b
>>> +        _ je   1b
>>> +        _ jne  1b
>>> +        _ jbe  1b
>>> +        _ ja   1b
>>> +        _ js   1b
>>> +        _ jns  1b
>>> +        _ jp   1b
>>> +        _ jnp  1b
>>> +        _ jl   1b
>>> +        _ jge  1b
>>> +        _ jle  1b
>>> +        _ jg   1b
>>> +        _ jmp  1b
>>> +
>>> +disp8_rex:
>>> +        _ rex.w jo   1b
>>> +        _ rex.w jno  1b
>>> +        _ rex.w jb   1b
>>> +        _ rex.w jae  1b
>>> +        _ rex.w je   1b
>>> +        _ rex.w jne  1b
>>> +        _ rex.w jbe  1b
>>> +        _ rex.w ja   1b
>>> +        _ rex.w js   1b
>>> +        _ rex.w jns  1b
>>> +        _ rex.w jp   1b
>>> +        _ rex.w jnp  1b
>>> +        _ rex.w jl   1b
>>> +        _ rex.w jge  1b
>>> +        _ rex.w jle  1b
>>> +        _ rex.w jg   1b
>>> +        _ rex.w jmp  1b
>>> +END(tests_rel1)
>> What's the idea behind the separate REX.W testing?
> 
> Testing osize handling vs Imm8/Imm.

I see, albeit I very much hope osize would never, ever have an effect on Imm8
encodings, as far as the size of the immediate goes.

>>  It almost suggests that
>> tests with an operand size prefix also may want adding. Except that's
>> difficult, because of ...
>>
>>> +DECL(tests_rel4)
>>> +disp32:
>>> +        _ call   other_section
>>> +        _ jmp    other_section
>>> +        _ jo     other_section
>>> +        _ jno    other_section
>>> +        _ jb     other_section
>>> +        _ jae    other_section
>>> +        _ je     other_section
>>> +        _ jne    other_section
>>> +        _ jbe    other_section
>>> +        _ ja     other_section
>>> +        _ js     other_section
>>> +        _ jns    other_section
>>> +        _ jp     other_section
>>> +        _ jnp    other_section
>>> +        _ jl     other_section
>>> +        _ jge    other_section
>>> +        _ jle    other_section
>>> +        _ jg     other_section
>>> +        _ xbegin other_section
>>> +
>>> +disp32_rex:
>>> +        _ rex.w call   other_section
>>> +        _ rex.w jmp    other_section
>>> +        _ rex.w jo     other_section
>>> +        _ rex.w jno    other_section
>>> +        _ rex.w jb     other_section
>>> +        _ rex.w jae    other_section
>>> +        _ rex.w je     other_section
>>> +        _ rex.w jne    other_section
>>> +        _ rex.w jbe    other_section
>>> +        _ rex.w ja     other_section
>>> +        _ rex.w js     other_section
>>> +        _ rex.w jns    other_section
>>> +        _ rex.w jp     other_section
>>> +        _ rex.w jnp    other_section
>>> +        _ rex.w jl     other_section
>>> +        _ rex.w jge    other_section
>>> +        _ rex.w jle    other_section
>>> +        _ rex.w jg     other_section
>>> +        _ rex.w xbegin other_section
>> ... vendor differences here. Perhaps the decoder itself would better
>> reject handling of operand-size-prefixed branches.
> 
> Excluding 66-prefix is easy, but excluding rex.w on jumps is hard and
> would require extra logic.

To exclude 66 is all I was suggesting. REX.W isn't treated differently by
the vendors, afaik, likely simply because it's meaningless altogether for
these insns.

>>> +opsize_branch: /* 66-prefixed branches are decoded differently by vendors */
>>> +        _ data16 call   other_section
>>> +        _ data16 jmp    other_section
>>> +        _ data16 jo     other_section
>>> +        _ data16 jno    other_section
>>> +        _ data16 jb     other_section
>>> +        _ data16 jae    other_section
>>> +        _ data16 je     other_section
>>> +        _ data16 jne    other_section
>>> +        _ data16 jbe    other_section
>>> +        _ data16 ja     other_section
>>> +        _ data16 js     other_section
>>> +        _ data16 jns    other_section
>>> +        _ data16 jp     other_section
>>> +        _ data16 jnp    other_section
>>> +        _ data16 jl     other_section
>>> +        _ data16 jge    other_section
>>> +        _ data16 jle    other_section
>>> +        _ data16 jg     other_section
>>> +        _ data16 xbegin other_section
>> Oh, you even cover the case here. For XBEGIN, however, this can only be pure
>> guesswork as to AMD behavior, I suppose.
> 
> Remember that RTM is available on Zen2 if you know which chickenbits to
> clobber.
> 
> I've not tried.  I expect it's more likely that they behave consistently
> than differently.
> 
>> I also don't see how you force which form you want.
> 
> Binutils always produces AMD behaviour.  (As far as I can see.)

By default, yes. Quite some time ago CALL and JMP were covered more
correctly, via the -mamd64 / -mintel64 cmdline options. Not very long ago
I realized we had never extended that to Jcc.

> This is in the negative-tests section, which confirms that
> x86_decode_lite() rejects the byte pattern.
> 
> If Binutils changes behaviour, the test will start failing.

Changing the default behavior seems extremely unlikely to me. Changing
the non default behavior, otoh, has happened (and if need be could
happen again).

Anyway, all of this is becoming moot if 66 was rejected on branches.

>>> --- /dev/null
>>> +++ b/tools/tests/x86-decode-lite/main.c
>>> @@ -0,0 +1,111 @@
>>> +/*
>>> + * Userspace test harness for x86_decode_lite().
>>> + */
>>> +#include <stdio.h>
>>> +
>>> +#include "x86-emulate.h"
>>> +
>>> +static unsigned int nr_failures;
>>> +#define fail(t, fmt, ...)                                       \
>>> +({                                                              \
>>> +    const unsigned char *insn = (t)->ip;                        \
>>> +                                                                \
>>> +    nr_failures++;                                              \
>>> +                                                                \
>>> +    (void)printf("  Fail '%s' [%02x", (t)->name, *insn);        \
>>> +    for ( unsigned int i = 1; i < (t)->len; i++ )               \
>>> +        printf(" %02x", insn[i]);                               \
>>> +    printf("]\n");                                              \
>>> +                                                                \
>>> +    (void)printf(fmt, ##__VA_ARGS__);                           \
>>> +})
>>> +
>>> +struct test {
>>> +    const char *name;
>>> +    void *ip;
>>> +    unsigned long len;
>>> +};
>>> +
>>> +extern const struct test
>>> +/* Defined in insns.S, ends with sentinel */
>>> +    tests_rel0[], /* No relocatable entry */
>>> +    tests_rel1[], /* disp8 */
>>> +    tests_rel4[], /* disp32 or RIP-relative */
>>> +    tests_unsup[]; /* Unsupported instructions */
>>> +
>>> +static inline void run_tests(const struct test *tests, unsigned int rel_sz)
>>> +{
>>> +    printf("Test rel%u\n", rel_sz);
>>> +
>>> +    for ( unsigned int i = 0; tests[i].name; ++i )
>>> +    {
>>> +        const struct test *t = &tests[i];
>>> +        x86_decode_lite_t r;
>>> +
>>> +        /*
>>> +         * Don't end strictly at t->len.  This provides better diagnostics if
>>> +         * too many bytes end up getting consumed.
>>> +         */
>>> +        r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
>> For the excess bytes to at least be legitimate to access (not causing UB),
>> shouldn't finish_arr emit enough filler bytes?
> 
> finish_arr is the wrong place, but I've folded in:
> 
> diff --git a/tools/tests/x86-decode-lite/insns.S b/tools/tests/x86-decode-lite/insns.S
> index e52c2934c8d8..dc017016b2d2 100644
> --- a/tools/tests/x86-decode-lite/insns.S
> +++ b/tools/tests/x86-decode-lite/insns.S
> @@ -695,6 +695,13 @@ unsup_insn: /* Instructions that would complicated decode, or shouldn't be used
>  
>  END(tests_unsup)
>  
> +        /*
> +         * For improved diagnostics, we allow some overreading of the
> +         * instruction under test.  Ensure there are good bytes to read.
> +         */
> +overread_padding:
> +        .skip 20
> +
>          /* This is here to cause jmps to use their disp32 form. */
>          .section .text.other_section, "ax", @progbits
>  other_section:

How would this help? run_tests() is never invoked with tests_unsup[] as
argument. And run_tests_unsup() wants to only fetch up to t->len.

>>> --- /dev/null
>>> +++ b/tools/tests/x86-decode-lite/x86-emulate.h
>>> @@ -0,0 +1,27 @@
>>> +#ifndef X86_EMULATE_H
>>> +#define X86_EMULATE_H
>>> +
>>> +#include <assert.h>
>>> +#include <stdbool.h>
>>> +#include <stdint.h>
>>> +#include <stdlib.h>
>>> +#include <string.h>
>>> +
>>> +#include <xen/asm/x86-defns.h>
>>> +#include <xen/asm/x86-vendors.h>
>>> +
>>> +#include <xen-tools/common-macros.h>
>>> +
>>> +#define ASSERT assert
>>> +
>>> +#define printk(...)
>>> +
>>> +#define likely
>>> +#define unlikely
>>> +#define cf_check
>>> +#define init_or_livepatch
>>> +#define init_or_livepatch_const
>>> +
>>> +#include "x86_emulate/x86_emulate.h"
>> Why does this end up being needed?
> 
> Well, this for starters:
> 
> main.c: In function ‘run_tests’:
> main.c:43:9: error: unknown type name ‘x86_decode_lite_t’
>    43 |         x86_decode_lite_t r;
>       |         ^~~~~~~~~~~~~~~~~
> main.c:49:13: error: implicit declaration of function ‘x86_decode_lite’ [-Werror=implicit-function-declaration]
>    49 |         r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
>       |             ^~~~~~~~~~~~~~~

Hmm, yes, that should have been obvious, if only I didn't expect decode-lite
to be largely (up to entirely) independent of the core emulator, irrespective
of its placement in the same dir. x86_emulate/x86_emulate.h is a pretty
involved header, which I think would be nice to avoid growing more
dependencies on. Then again it looks as if about every object file already
depends on it (which imo is bad).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 06:49:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 06:49:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382860.1626134 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVRO-0001fj-Lx; Wed, 05 Aug 2026 06:49:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382860.1626134; Wed, 05 Aug 2026 06:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVRO-0001fc-JN; Wed, 05 Aug 2026 06:49:26 +0000
Received: by outflank-mailman (input) for mailman id 1382860;
 Wed, 05 Aug 2026 06:49:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrVRN-0001fW-Gh
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:49:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrVRM-0063uC-BP
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:49:24 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72dce3-bab6-0a2a0a5309dd-0a2a450cbd62-46
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:49:24 +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 <jbeulich@suse.com>)
 id 6a72dcf4-f479-0a2a450c0019-d1558036b104-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 08:49:24 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-49545ba3d4eso2926475e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:49:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994e9ad922sm24994565e9.4.2026.08.04.23.49.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 04 Aug 2026 23:49:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785912564; x=1786517364; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=5Jhv8pkezYCrgt9JiHXX1n8n4He1/X32jhyGT/X0o+E=;
        b=Sfd40lHvtRhfDwYrXlZw0jnPuVYono3VgNH5zStwyWBfDHbkVX7ht/rlWQ5kyTgwoT
         oJKDPaoBWKgwGAm7qNeLNjYZzN4/qg0gLQYA5ImNWFdgAL5T9td8N48tG5YK8moGvTNH
         uGVQ7DJVSvi/WxXK1VKuf/k7DqQ7G5uI8eEC5mIZtSK2LyUzxYYr5Ma0wostFDjPJoDu
         BUsQgVxekE5xzc7YgZLQigjcnHeVNByLcHEc9Dfzqp0UZ679Kusy64osNT8uraTSJSvl
         WsKyPpiBGhBjm0LBGzQmBS7a8mG1cxtnu9XX7EH5wzMMNN4LETanT3aW85YykRRu/LCI
         e4bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785912564; x=1786517364;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=5Jhv8pkezYCrgt9JiHXX1n8n4He1/X32jhyGT/X0o+E=;
        b=cQXSFmelzG/qLPifqvUEys/cg4WU7TY+RpXO3xqzohRyk3ecxtF8iiIx5uzicNLqjf
         FElksV5sqxsFpHAULmuukvkOupBN235u0npUmv/xNTsmVX2xh11wxn1HCEBOtpLGoduA
         5Hs5pbFmQ2xwUpv5K7Vug07HpHC+N04YvHVi9bykiJgtTgo/HvTyd1k+zbjZSXUnapQO
         kExMElS3Jk0IhkoD6rxQAFQ6iecsLr+8julcWCzt9Jn1EHYDELzwLenZxMMng/ZtPlXv
         xB73PhwhjBVFBb0VwusDZEsoAtfaVbnFq/5k/1aBhZJZ49cSajnHqsW4/nxOKk+/pDJC
         PsdA==
X-Forwarded-Encrypted: i=1; AHgh+RokGE/voe6uD6z8Hc2RQbMpJMUuW7DC56/e7/EqCtO1b7pxpgz3Sn9+GB6OqjUy0mPabkxeb3n5ac0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwR/aCY0zZ9BgghIwFDrQ5wpw9a0x8ECksHVzKXxTuItdw1k2tK
	lko5SQuIzDjhU3EG+oZ5/spMXZirXnL9oDPMrbKrNzezWrpncKk/G4dCDQ9aF37hhA==
X-Gm-Gg: AR+sD108WU3JhUscCWr6153TphdVGQat9eWNmPy69AGa79jFdHT8k/UGZyDUYDExOO9
	7ZXJPpTLnRtFsHzASjRlfDMxrHbEowNQCYRLhQ+j07b8N8a+4l5DmEkysX3A/mM4APk/6httlxE
	GrFOXAS/QHFuhGuO1uMmHwtaglUPTmt+BcYXaUI0iPbagk1aq34tBfuJf6CpgTiAPsaC8n3X5AC
	nqIucmeZyp+6YANIaobiz3Vzz2vJhcdJ7JUwIoAbLQ7ANwMtNmRxUg8iiNKiOgn4TBCynGL2F3e
	wYmbwbEaxIhfVW01EKqua3TucltCptvcEB4GdYWwo/MB2W/F6OTbvU5GQ/DyahONYmFOBq2CLAt
	nuKhKVmednotkw7y261chhirXYKuwr6vetHtMszM48pr6X0nHq1QEYHcqmuxMjMvrb5vQ6xmPp6
	sgzpn5trVKpfnCIV3AMKoryWl3C4IMCB6HKz9JOFAEiwGDt5BxQTFYzN8027DeDIkFwO2z7htXB
	9Fd8/NoeCdHR5+dgw9PfIwy/Y3kdCw0WJvazkd7GfX6VhPUkcGu3X/901w+QD0=
X-Received: by 2002:a05:600c:1d10:b0:495:7a23:1eee with SMTP id 5b1f17b1804b1-4994e7ba86amr37703665e9.12.1785912563813;
        Tue, 04 Aug 2026 23:49:23 -0700 (PDT)
Message-ID: <3ff21b60-fc6a-46f9-94b7-89393cd77933@suse.com>
Date: Wed, 5 Aug 2026 08:49:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] x86/alternatives: Rework get_ideal_nops()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20250522150015.555492-1-andrew.cooper3@citrix.com>
 <20250522150015.555492-3-andrew.cooper3@citrix.com>
 <99a39800-dbba-4d37-afcb-ae041af648f4@suse.com>
 <f15222a9-1d61-4d9c-b923-8e6ad4994af3@citrix.com>
 <cd877869-3d53-41e4-88b3-df629e4dcbbd@suse.com>
 <5d62cfe6-3d97-44f4-9a5f-94b77514b6a3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5d62cfe6-3d97-44f4-9a5f-94b77514b6a3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1785912564-01CC3A5B-E8FA380B/0/0
X-purgate-type: clean
X-purgate-size: 1469

On 05.08.2026 08:34, Andrew Cooper wrote:
> On 05/08/2026 7:04 am, Jan Beulich wrote:
>> On 04.08.2026 19:13, Andrew Cooper wrote:
>>> On 02/06/2025 10:57 am, Jan Beulich wrote:
>>>> On 22.05.2025 17:00, Andrew Cooper wrote:
>>>>> --- a/xen/arch/x86/alternative.c
>>>>> +++ b/xen/arch/x86/alternative.c
>>>>> @@ -20,7 +20,7 @@
>>>>>  #define MAX_PATCH_LEN (255-1)
>>>>>  
>>>>>  #ifdef K8_NOP1
>>>>> -static const unsigned char k8nops[] init_or_livepatch_const = {
>>>>> +static const unsigned char k8_nops[] init_or_livepatch_const = {
>>>>>      K8_NOP1,
>>>>>      K8_NOP2,
>>>>>      K8_NOP3,
>>>>> @@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = {
>>>>>      K8_NOP8,
>>>>>      K8_NOP9,
>>>>>  };
>>>>> -static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
>>>> ... the (at least visual) connection to ASM_NOP_MAX. Could I talk you into
>>>> adding build time array-size checks for both arrays, to restore the
>>>> connection?
>>> Sorry, but I have no idea what you're asking for here.
>>     BUILD_BUG_ON(ARRAY_SIZE(k8_nops) != ASM_NOP_MAX);
>>     BUILD_BUG_ON(ARRAY_SIZE(p6_nops) != ASM_NOP_MAX);
> 
> The arrays are 45 bytes (and elements) long.  ASM_NOP_MAX is 9.

Oh, right, sorry:

     BUILD_BUG_ON(ARRAY_SIZE(k8_nops) != (ASM_NOP_MAX * (ASM_NOP_MAX + 1)) / 2);
     BUILD_BUG_ON(ARRAY_SIZE(p6_nops) != (ASM_NOP_MAX * (ASM_NOP_MAX + 1)) / 2);

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 07:06:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 07:06:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382651.1626144 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVha-0004lJ-1B; Wed, 05 Aug 2026 07:06:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382651.1626144; Wed, 05 Aug 2026 07:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVhZ-0004lC-UP; Wed, 05 Aug 2026 07:06:09 +0000
Received: by outflank-mailman (input) for mailman id 1382651;
 Tue, 04 Aug 2026 21:36:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gyf161023@gmail.com>) id 1wrMnq-0007Ho-H7
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 21:36:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrMno-00A65A-UO
 for xen-devel@lists.xenproject.org; Tue, 04 Aug 2026 23:36:00 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <gyf161023@gmail.com>)
 id 6a725b2c-5cb7-0a2a0a5109dd-0a2a4507af30-18
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:36:00 +0200
Received: from [209.85.216.41] (helo=mail-pj1-f41.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <gyf161023@gmail.com>)
 id 6a725b3f-b4ea-0a2a45070019-d155d829c11a-3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 23:36:00 +0200
Received: by mail-pj1-f41.google.com with SMTP id
 98e67ed59e1d1-3811f512167so293683a91.3
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 14:36:00 -0700 (PDT)
Received: from LAPTOP-DPAKMOI4.it.purdue.edu (pal-210-106-74.itap.purdue.edu.
 [128.210.106.74]) by smtp.gmail.com with ESMTPSA id
 5a478bee46e88-31586447d52sm7628775eec.12.2026.08.04.14.35.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 14:35:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785879358; x=1786484158; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=QH2K5FogbEg2Pu5YlCvSeafRigFtD0Kz01lkbZ2ZcwI=;
        b=e3oalOmoaqQ8EzJ8TAiy6yWYzjW3Zg8NowW2Q502DhBk8Z0pHOxJueLingJBTMFNkc
         WQJxqwhm3BJt4ZGN7EX6zlM4A+dx+mS1FNmxOc+77XOxyjWdCAoRv0gEktWXyL34Punq
         Js6uHyPpPgIgnMbSxOyoUl253h2BNwSRKo76bCr3McFKUJGX9EFEahfRrTAyS4+SSZ04
         OcoKUDScsE9lQBBuFjXq+b9Fn4tPKtX/EZeG/VKt4bM9uw5A5xINGi7J+CZqa7NDw9GE
         fL8fIXbK2DPj9EgvCnvF0W0x51o4n7N8gFpuIy31rFct/Ft8muq8UmaP/gUGchkLJTcW
         1jcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785879358; x=1786484158;
        h=content-transfer-encoding:mime-version: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=QH2K5FogbEg2Pu5YlCvSeafRigFtD0Kz01lkbZ2ZcwI=;
        b=pBIpWKgt5qu0tAnEBsE/+BDWdVnbRRQ9ERKT+0ZTIfWnGZ+H6prRWl33ce4TShNqJA
         CYLkYR7EQWcXEboiKQ4olrBVsOtjpqGWLiAkSsC34ybB9WhkmE/HpBZe9o1W0P8+/4AX
         YH7Pf4i+mXOjgFMSpDWWuge5m4Up3f6weme7+UxO8VD4tbFLAn0NZS84UzxVYo5NlKpH
         x4jXO7R+/w8pc/tzbPaWE0q3bieHXg77n05LBrrbnv6AV29M6Cd4CXWWqlHyV5lq8bdM
         Xpe2OANp7klwXWGeX/B8l1zdXJ86R9qJwHTAzozH+bE1U9tVjVQQuL4wN6CZi6NM/mRk
         egig==
X-Forwarded-Encrypted: i=1; AHgh+RoI3+Dc1AwZ40fF2o6+TJ4Pi2rdBIlDWtLI9K3yA+1m9z4Oo+Z6r9K6nJ9+RBfXPOQRoDV8cNcg2iQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyuqgDbxqNQBMWbz45oVZ0GZtLEStGcH9uh5A9X0yFzzHNIwU9p
	Eigd1qWlmor22Vo0OP0TvCrOym83TInyngumG+8fD/kOosXNuOdNOcHU
X-Gm-Gg: AR+sD13WEgdRQ0BaWHaEf2nkfhhxgHXztkeJDcF/OMPs2dRsIkWfdLkXcFil6ku2meL
	/SrGpOcOAv/OslNsOEkHIGUwfguvaEQDqiksESJCf0cisYyHWHgr2K3a3VvaAR1APNIy2gpQg/p
	nUMFEM3f3VTquatrjrzDyQEV4RNhSvp3okbg7f58RCXQmqBwb0E+7i2mWmozHRjMOZVgTS3mr07
	edeDz7IDNJSg8/h3uwNo+i5MpyeHo0m0JD1vOUMzZ3H/S1onvcVBuFRb/p1lVXhaD1y2za+wxe4
	LUA7zhWYJHq6JWzhdVecpUB9CnhTrfofYzVPnWhgdo39tthu4urcj+fwQ/9lBeUfYpxWVpf7ycf
	6k0wOnsJRp9XMUCS6WJ+XiOUuyTv+Fn3F9ytVXtYdp3KkW1zgvvzeEeS/fw4uJ7JhEfc1nC2E4D
	Ocyq95UqywJePt1FMtNWhg7W9cOxk299PH1m96ZmLRgFnqCOPqzVeNDnh/CJN4cb9TF4F61/VgH
	P3G6A+aNYEtyaZ4nltiU9qbD6FAZRS3Uz+5wP9Bvpg=
X-Received: by 2002:a05:6a21:50b:b0:3c3:8aa8:6caf with SMTP id adf61e73a8af0-3cb85efb72bmr1956240637.27.1785879358555;
        Tue, 04 Aug 2026 14:35:58 -0700 (PDT)
From: Yifei Gao <gyf161023@gmail.com>
To: Eric Van Hensbergen <ericvh@kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>,
	Dominique Martinet <asmadeus@codewreck.org>,
	v9fs@lists.linux.dev
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
	Juergen Gross <jgross@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	Yifei Gao <gyf161023@gmail.com>,
	stable@vger.kernel.org
Subject: [PATCH] 9p/xen: fix refcount leak in p9_xen_response() on wrong tag
Date: Tue,  4 Aug 2026 21:35:49 +0000
Message-ID: <20260804213550.3409638-1-gyf161023@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785879360-A72DCAE4-3827DD67/0/0
X-purgate-type: clean
X-purgate-size: 1323

p9_xen_response() looks up the request for an incoming reply with
p9_tag_lookup(), which takes a reference on the returned p9_req_t. When
the tag does not resolve to a request in REQ_STATUS_SENT, the function
warns and continues the loop without dropping that reference, permanently
leaking the p9_req_t and its msize buffers. The reply header, including
the tag, is supplied by the backend, so a malicious or buggy 9P backend
can leak kernel memory on every crafted response.

Drop the reference before continuing, mirroring the equivalent path in
trans_fd.c.

Fixes: f66c72bea129 ("xen/9pfs: receive responses")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Yifei Gao <gyf161023@gmail.com>
---
 net/9p/trans_xen.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index f9fb2db7a066..8eea0da8797f 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -203,6 +203,8 @@ static void p9_xen_response(struct work_struct *work)
 		req = p9_tag_lookup(priv->client, h.tag);
 		if (!req || req->status != REQ_STATUS_SENT) {
 			dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag);
+			if (req)
+				p9_req_put(priv->client, req);
 			cons += h.size;
 			virt_mb();
 			ring->intf->in_cons = cons;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 07:06:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 07:06:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382798.1626153 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVhl-00050V-8K; Wed, 05 Aug 2026 07:06:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382798.1626153; Wed, 05 Aug 2026 07:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVhl-00050O-5Q; Wed, 05 Aug 2026 07:06:21 +0000
Received: by outflank-mailman (input) for mailman id 1382798;
 Wed, 05 Aug 2026 04:46:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <matthias.goergens@gmail.com>) id 1wrTWE-0006vT-0K
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 04:46:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrTWB-00H8EK-T5
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 06:46:15 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <matthias.goergens@gmail.com>)
 id 6a72c000-bab6-0a2a0a5309dd-0a2a450ca66e-26
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:46:15 +0200
Received: from [209.85.210.181] (helo=mail-pf1-f181.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <matthias.goergens@gmail.com>)
 id 6a72c016-f479-0a2a450c0019-d155d2b5d47c-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:46:15 +0200
Received: by mail-pf1-f181.google.com with SMTP id
 d2e1a72fcca58-84e3007a2b7so519790b3a.0
 for <xen-devel@lists.xenproject.org>; Tue, 04 Aug 2026 21:46:15 -0700 (PDT)
Received: from spider.bream-herring.ts.net ([103.252.203.158])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-cbe707e577bsm617891a12.9.2026.08.04.21.46.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 04 Aug 2026 21:46:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785905174; x=1786509974; 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=pf+KaQef3aLdqIRGS+SN0ScWkjmFB+xo03zP2W7SUl4=;
        b=UwlqUyxkiwWEUbPlhU7mBvpwcUGFC3Ix7CSD44RFzIG2r5HAssgZHVACbxb3Y0qH6s
         qTbReqGpiCrKTOHm+aXomcZ1pgRHERXiIe3u9CGzCJ+Qc5rg+e8CupHirOfCVrO3j1kO
         mI+ieQIvboXDwkJdaQf/WlmnAKSP3xyaYDG07HEwVTRLxDBYq2/uDc/O3ZA7iuk12d+P
         TSABsu/hGvQ5kipKmp5j0/cp6H+aXQL/Lb4vAxgdm2HX+zkqqhvqFXZJI49b2i78p4/5
         UmzDni4hTsAuK8W34PMORTms7+lqYiLKzT81hKMUpWhyWbIUcL0+uIg5qC/izidDl3U6
         Ut9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785905174; x=1786509974;
        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=pf+KaQef3aLdqIRGS+SN0ScWkjmFB+xo03zP2W7SUl4=;
        b=gJLeh5laBebO9TVi2LXAdx23ulY0ZeuyhcNL/CdmRp1Q19Qi6aNRf+TwBOS5UaVIkj
         Uki24OY9xlUPMX32DNLWWU1FC0z+ZKd5KXtdOgP7G9egaFoEx63N3d2wJeAMR2hLkJMy
         UwpK3QbXl5xKYhv4BdvN7pIwMR6MPJTBWLepoiJ4KiGKdsR4iyIKnWcywstg6C/IxkCE
         cZjro3Y9hfELv/Mmc4ugPzlE3Lj4x1VwPieLxiOledrQmlkmo8QbgGnVf3yc5YVqNrtT
         hYZysBZOmDofnVvtMgh0Qp8BF2W33iqMyUO1sg5Ex9AselcyR2edy5KmvwCvAKqutjfF
         Fc+g==
X-Forwarded-Encrypted: i=1; AHgh+RrouvLHK44syrD8y2FN2eQ3pc4qfH3G3xWjrVkCWgnev4tz9ay4MtQZso276O4dOqnCwuDdwwZAj7s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNwgOyqOSV4lCq1sAPbsDDKf1+n1d6zidLscJSLp5FB3cjiBtq
	BqloZ3gHUZWwBZ70m/MaSK4HlMpTsrBjZuIGRNHnF5u/+gIkqV+d5fFN
X-Gm-Gg: AR+sD10QgB+vRNvQGxsVX6jCnH6RmnQSGD4pMMvR/2dCNVDl5LWvsmtzw7D/lo94Fsg
	Y3vtkCdLOvfyfumSrV4lFfUSsEZQqEwiXJrEFfyPxqlByHgPiHifVOZWIeNgAWe0rB27lGpFm0K
	DeP+VmU2BBrrTJ17HRPoW8Hrn30bjsRw24PRmFh4Uqf2ryu5Pln2nC5G82CyaB88lAUthBRU16q
	07xMBzATqYBac/k2RPpUqx7XTY109oXNylZrgzkQqpYYji79qwwCWEn4Byujat9jgK83PJZu5RR
	ilaqxhBqo+mLUL+nNVTN98WYZWMzm6phdsAy4RcdQtNhIEtY+W18OVr0q/0BzuZi5JkDUKeE+zO
	PhIv6Nc/8xjRxtKRnI+SXoWKb6lrWDF6VPJ4r6pb4cM9kSCQUGyShmYGTjznrLdEfxmgoXZedkX
	wRpGva/pzh0dNPZujtnM18nqQM8Uao3qZLRp6juJN4O+GkDXx9mOs1KBgDbWs72L7bbxI/hx5eN
	CFg7neFr7aecAcehJKoTNKFB2XQa48Whji9KFf/RSnf8k/frcY7O/V0b9J9iTj52Y/6YBriEiu3
	bkO4bXzC4Z7Jeslir7LgDMZRGBOJvh7vqRFDVRkWJaQ0CUNmSLZB
X-Received: by 2002:a05:6a00:2d8b:b0:848:3e74:85eb with SMTP id d2e1a72fcca58-84f2e014749mr4032775b3a.1.1785905173552;
        Tue, 04 Aug 2026 21:46:13 -0700 (PDT)
From: Matthias Goergens <matthias.goergens@gmail.com>
To: Roger Pau Monne <roger@xenproject.org>
Cc: Matthias Goergens <matthias.goergens@gmail.com>,
	Juergen Gross <jgross@suse.com>,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	Yannick Martin <yannick.martin@okazoo.eu>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH] x86/xen: fix init of balloon stats for PV guests with memory != maxmem
Date: Wed,  5 Aug 2026 12:46:07 +0800
Message-ID: <20260805044607.2564210-1-matthias.goergens@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260730143548.39320-1-roger@xenproject.org>
References: <20260730143548.39320-1-roger@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1785905175-006CEA5B-EF30FEE9/0/0
X-purgate-type: clean
X-purgate-size: 2111

Hi Roger,

thanks for picking this up, and Juergen, thanks for the quick review.  Two
things I believe are still worth addressing; the Fixes: tag can of course
also be fixed up on application.

I think the Fixes: tag should point to 0949c646d646 ("Partial revert
\"x86/xen: fix balloon target initialization for PVH dom0\"").  Commit
87af633689ce changed the initial-page calculation and the extra-region
subtraction together, so those two operations were coherent: the PV initial
count then came from get_num_physpages(), which includes the extra regions.
0949c646d646 restored the PV start_info->nr_pages calculation, which
excludes the extra regions, but retained the subtraction.  Its 6.12.y
backport is also the reporter's identified regression, first seen in
6.12.75.  Applying this patch in a tree that has 87af633689ce but not
0949c646d646 (for example a 6.17-based distro tree) would double-account
the extra region.  This likely also wants Cc: stable@vger.kernel.org, since
both 6.12.y and 6.18.y carry the 0949c646d646 regression.

Separately, and not something this patch introduces: PVH dom0 has the same
shape of problem on mainline since b13cd24c15d7.  A successful
XENMEM_current_reservation supplies current_pages for both PV and PVH dom0,
and that count excludes the unpopulated xen_extra_mem, so the
xen_pv_domain()-only branch leaves PVH dom0 subtracting those pages again
(-ERANGE, or a silently wrong target, when CONFIG_XEN_UNPOPULATED_ALLOC=n
leaves the regions for the balloon driver).  I am happy to pursue that as
its own thread once this one lands.

Would it be safer to pass balloon_add_regions() an explicit indication of
whether the chosen initial-page count includes the extra physmap regions?
That would cover PV, PVH dom0, and the XENMEM_current_reservation fallback
without deriving the accounting rule solely from the domain type.  On
hypercall failure PVH dom0 falls back to get_num_physpages(), which
includes the extra regions, so keying the accounting on the source of the
count keeps the fallback correct as well.

Thanks,
Matthias


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 07:06:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 07:06:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382805.1626159 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVhl-00053m-Jy; Wed, 05 Aug 2026 07:06:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382805.1626159; Wed, 05 Aug 2026 07:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVhl-000528-DN; Wed, 05 Aug 2026 07:06:21 +0000
Received: by outflank-mailman (input) for mailman id 1382805;
 Wed, 05 Aug 2026 05:27:36 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <neal.frager@amd.com>) id 1wrUAB-0005Uw-Tc
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 05:27:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrUAA-008Ny1-CD
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 07:27:34 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a72c9c0-5cb7-0a2a0a5109dd-0a2a4503deda-14
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:27:33 +0200
Received: from [52.101.56.16]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a72c9c4-fae8-0a2a45030019-346538106acf-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:27:33 +0200
Received: from MW4PR03CA0089.namprd03.prod.outlook.com (2603:10b6:303:b6::34)
 by PH7PR12MB6635.namprd12.prod.outlook.com (2603:10b6:510:210::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Wed, 5 Aug
 2026 05:27:28 +0000
Received: from MWH0EPF000A672F.namprd04.prod.outlook.com
 (2603:10b6:303:b6:cafe::5f) by MW4PR03CA0089.outlook.office365.com
 (2603:10b6:303:b6::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.16 via Frontend Transport; Wed, 5
 Aug 2026 05:27:28 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 MWH0EPF000A672F.mail.protection.outlook.com (10.167.249.21) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.292.8 via Frontend Transport; Wed, 5 Aug 2026 05:27:27 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 00:27:26 -0500
Received: from xirengwts12.xilinx.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Wed, 5 Aug 2026 00:27:25 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vUIhDr0P2zEH7KJpJf3ZDHyc2k84JFqZ6awhZo/Er3VKiNWN1IGJMqTOwyklesbA8bbIKxY5ADhgr9qG3VadNK3ud0DR+o5AqRVt9qxNjbY6a+rEViEgQAhFWHFu2WQVFAoxMvw6uA6KPfXwh7CmdkWPeyb+mliseOaJ5rLmdH70347nNHQ74INjWQpYNuaYZP1vDDnK5rxaWr7gFnyUWH2BPWDiJvshSZ+bmKIDQQcvfsVD0h2W6Xud6IZbiu5cN0vuESC4vQwIm353myIsfapYX5m7XiWvFEy0E3nDJrDlK/gUn2Z10Ib47YN5FlGkeeI3Rz97B22dZ/Zs0PIHhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E/X3j+vLBycBqra0d59r8vxbnNUi3Klkubhz67O4PTY=;
 b=XyEWQaRVR1u68A3e5OviNXFkEtg402ACHSm64CVNrAnI07E01ncctTrzQto/6XL1YnysXR2rWs+XeOxf9qqWVEErC8hmxasJ+lw1j6JCezNz/vlmt/QC/xGbaRbca94nvBrnMX1aNPUrL3Q7NFt6ew9dDSx65JHQY9vl7C8WorR3aoVTmA3X6hcbDL/FlK8k4TlWv6AeXub8EjZCbly85XJTMgzYDl9CEYjMxhBn9vnPPgmmy+8ruvEiw6vfOlExl7uV17xYnlN0FvULI82BaxtTxJuu/3J4lU5EYqHthBahthrmUQ5lMLUGmU7mkWvNxXrXMTH52xJIk6GQlb6Ctw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=nongnu.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=E/X3j+vLBycBqra0d59r8vxbnNUi3Klkubhz67O4PTY=;
 b=je5PJT27QMl0w0JKoAr8eAL8tjMi3WUAe3uWVX3fDK7RqD4GADAXyURUZAfWbesCZRsQJUnbczsKBlJjevkDuwgG3VFjV6yQxTJ31732joPkMtgw34xGyCt0wusLraEmU7GGPQMk+Fx40swkxWByS6GfFk4cvy3naWl4zsDj5K0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Neal Frager <neal.frager@amd.com>
To: <qemu-devel@nongnu.org>
CC: <sstabellini@kernel.org>, <anthony@xenproject.org>,
	<edgar.iglesias@gmail.com>, <xen-devel@lists.xenproject.org>,
	<stefano.stabellini@amd.com>, <micheal.saleab@amd.com>,
	<stewart.hildebrand@amd.com>, <john.ernberg@actia.se>,
	<matthew.l.weber3@boeing.com>, <vincent.stehle@arm.com>, Neal Frager
	<neal.frager@amd.com>
Subject: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade include-order assertion to warning
Date: Wed, 5 Aug 2026 06:27:22 +0100
Message-ID: <20260805052723.2823538-1-neal.frager@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A672F:EE_|PH7PR12MB6635:EE_
X-MS-Office365-Filtering-Correlation-Id: 94bc0f2d-cca2-446a-818b-08def2b23d1e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700016|23010399003|18002099003|11063799006|13003099007|6133799003|10067099003|56012099006;
X-Microsoft-Antispam-Message-Info:
	/Z3P7akN7im+GzxTWp5kAYnL6QyZsZVIz+otKjWhGN4R2w16LIhEReH5uNR9ylFsaJk0eFYoUByBaCShjyv0N9KzbJdjKC6AR2dLUPoocgBLJv7ULlc9e4NBpZ9jqxcZDJH0H9MUP0las13iP0fPvri+lf70uFfvvkESeLTN0JAVMCQmG5R5HoN45tOe2PChyULr2dQ0224CkDWrGqDVt/FSM5g/xjSQw5stAZqb64Z2MxS6KEbqmk2ErtHUYNbUwhxqoHduYxd6fMIhxRmOkqUuKusp2tkkUihpTc5zOGu8219LGathe24rifqnM/MDaUGtFH12VplOmJDvuoApTGQl6esVRP6ecuoJue18CSlWLrsT/YFrM7LgzntQPYCeu9dJo9B3WM6FJKFWXHDeWWVAf/nEOJzSQX2scX7MnrLSsxge4Q2PS5KX2CU6q5l/WytV8OhTTvb13UhzjHHoYfuScmZJQu6SupNHsZAOVdlYgy8wl0Ctdit69pGHD/G7i39c833OGt5IKEkaqyjMKrZL7eBF6mL6d8ePdntEbAExgaKVx+zdkX1i6VWyCo2VSKbOzZBfbse1f2SFPVArYnbw1Ju/yr+vTQhHSTallgldsZB4LNfseGGnlmA2JBE1Ep8RRBrwoACRx2eMpJontEpPkEkeZNOhZiCbFhiVbfDzgYiSWUayxwFrIlaRTEcLGnv8o5U4xgh/oP2GcEXyxw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700016)(23010399003)(18002099003)(11063799006)(13003099007)(6133799003)(10067099003)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	1K/A2tkKp6+CpEoquoBIHfxeiKXkfVqGeCjGN/vbUqV5HAKBcHh3k2Y7FPCZZ3yHyOwpCKuoaEoI7IH3HzJb9op9h9gllhpnznz9x6hz6nb1OOJ0anUmCqKrR/cCcJc9GG2hpW8PsrLaRMBiWbXUnUwvzOE0/pqjhcg0nPurWcfr4efk39Doo8d/N3rxV0krmeqEpEzABSXGf6sF26+rS5gtME3mKjJXA+aiUnXQ41aGPj6EUNOE1qhRrLdGpGw6T7qO621E6vA9ZdFsvqcfgV93OjaaXL4QTRPjTsIDqTHYBmtaB894WongnuDCThZo3W9oN59ayNV/FiPZDX28zR6x/CghuvgJv3nSVzY42Cv1XDCfPOKMNxrmB2D0gpg+4OgIFfEiHjZ9uWMHrMJAUe56FGlFxiN9H33K0ufe+I6gTdzo0BVLzOestAF0cJQA
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 05:27:27.5347
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 94bc0f2d-cca2-446a-818b-08def2b23d1e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000A672F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6635
X-purgate-ID: tlsNG-33051d/1785907653-76EF74E9-4D521809/0/0
X-purgate-type: clean
X-purgate-size: 962

The -I$(XEN_ROOT)/tools/include added to QEMU's extra-cflags causes
__XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included,
triggering an include-order assertion. Downgrade to a warning since the
version is consistent in cross-compile.
Ref: https://github.com/qemu/qemu/commit/e2abfe5ec6

Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
---
 include/hw/xen/xen_native.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/xen/xen_native.h b/include/hw/xen/xen_native.h
index 5caf91a616..3e1137efc1 100644
--- a/include/hw/xen/xen_native.h
+++ b/include/hw/xen/xen_native.h
@@ -2,7 +2,7 @@
 #define QEMU_HW_XEN_NATIVE_H
 
 #ifdef __XEN_INTERFACE_VERSION__
-#error In Xen native files, include xen_native.h before other Xen headers
+#warning In Xen native files, include xen_native.h before other Xen headers
 #endif
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 07:13:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 07:13:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382894.1626171 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVol-0007dV-Eg; Wed, 05 Aug 2026 07:13:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382894.1626171; Wed, 05 Aug 2026 07:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVol-0007dO-Bu; Wed, 05 Aug 2026 07:13:35 +0000
Received: by outflank-mailman (input) for mailman id 1382894;
 Wed, 05 Aug 2026 07:13:34 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrVok-0007dH-Gj
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 07:13:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrVoj-00H5sf-Hg
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:13:33 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72e299-2eae-0a2a0a5409dd-0a2a4507bd98-8
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 09:13:33 +0200
Received: from [209.85.208.45] (helo=mail-ed1-f45.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72e29d-b4ea-0a2a45070019-d155d02db8e6-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 09:13:33 +0200
Received: by mail-ed1-f45.google.com with SMTP id
 4fb4d7f45d1cf-698ae09e356so788350a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 00:13:33 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a145c49044sm1419460a12.9.2026.08.05.00.13.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 00:13:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785914013; x=1786518813; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=drHrC+qdqsi+PR/0lRsf/Ub+SUFkFlPx++QVFcFYlko=;
        b=DghiHlLh9toRgS1ioirUzAyrduOKQSQGfgEEjTdrPeuAXjqjvn/DmUKeadBWJGb+Yg
         yFbruMHZszkAHz1qAoVnrhVULJkUqT1UxqE7IfnQhS0Y4S85ddNYBdZyp1Ev1OW2c9td
         BFHQIXl0bemaS9UKxCw3DqzcPRQi4ru0jNMQOUf5u6R9/FCHu5Twkr1sEqja6eCzIECM
         Nt7yf1Ee3rs0mS1dpi3BznYsUwWnW7wPqTz6EJYcAxwoXe9g9D090hi3lPGVhJQLgTiU
         H4UN9xmHChpwOmHm0QFpYD4WkZb+0f176PI5Zm2xlwW/bRLlRf2ZFsPl8DPRRZ7LCOB3
         TS8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785914013; x=1786518813;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=drHrC+qdqsi+PR/0lRsf/Ub+SUFkFlPx++QVFcFYlko=;
        b=JESnQ44ZLGgwZ41/t9bzuNzUkFmD71eNY08gx+KxFS7BKrTGRW7e/imWGY/PDrU7Zx
         o2A2fvdfn4tbj1EtEzYjyEOYfvH0X0CG/Kli5ReTa0JK2wCd9prG5jIa9OZpzU6NeDQq
         Wl4YSeWiqQPOzAtteEqfcPg6ilZfMyMQNfX2j3nPbUS4ACJ61GV43UGox/Q+YFKgSwI2
         UOovGaULyKvogQwnwYqQQBAfEXNiW18D/sVnyKBKHym7Oi23A2P6i9ONSxKc3wTK5/L7
         2U6IyGn4lUs5emO0Qrf6F+Ht+MWpAyqh3KAN+1tkMa2P5imGAFP5+ocnaH8+2XWQNI0Z
         x1Qw==
X-Forwarded-Encrypted: i=1; AHgh+RrWferFIRVN2GSNXxwNXY/xuZS6bM67NrwfNySOfbOCOZrxkiiwm3CRIR/BQhUXkTAbo189euteaVI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyrSuh2m+CnQTF8D5yFvVM/I0/jmB+0bMst8uRTDMDod9QdV7UI
	eycQDcJwCWb9bjNr+A6/kt1IFR3j1XxhhZCCibG3L/o9VlGWFfTXd+hvAt3nq94rM3g=
X-Gm-Gg: AR+sD12gJXUGVK8rgIuLonF0a1cFjEGga3TVUQUX9kUtFtkq715cdRFgjYscZ0DS3+w
	aCPmJHK0xrDmPmy10T/UG1xbGs1Q/6IuZwgDkU6j18FrAI8exjgorMtPsymNaame8OsB+B1f4b+
	rAWlGAu6BWB4wtndZAvL+a9E8zJ2oEX6ry37W8sh5bEG6s9H9H2tFv6Lp4AWg/Y565C+7RrOLfs
	mYXr14fW/qo+Swytb8BMqnV7kZbDrrjNKJ61Kiqsv3Dke3pTL0cE0+FFV7iJr3L0F80z/rdfVpa
	wjZhcSkMptNW3oYTb4V3xkGIzII273UIQ1Qa2Ot7SI9eVB8I9c0cvwyFo5aWIcV1ylokjD5RNGj
	nYMzhcKMH4MK7fFeZbpIB91gb67VqK8JnBPLZVWgP3Hz8eqUfboberGxUQTjmmXnXLG+z8Nyjrm
	lPy0RTx/g1CzflExrJ+dZfhU4o8lBQ/TF/ntD+dI0Greh7KGpL5VQaOXn4GJcDjSCOTSXXREfTW
	EzJz/nrob64A0PujWai31jBJNCIffg8ZR9B9tCPRo7GXKlkdgsnqXuwSEtk01faJfD7AlvNaDt3
	7eNigp4kThbi+ZGCcpTUPfJUVg==
X-Received: by 2002:a05:6402:1586:b0:6a0:a4be:6ed0 with SMTP id 4fb4d7f45d1cf-6a14f14c601mr2107256a12.17.1785914012808;
        Wed, 05 Aug 2026 00:13:32 -0700 (PDT)
Message-ID: <931b763d-2ee6-4fbf-9222-c5b75f35ec47@suse.com>
Date: Wed, 5 Aug 2026 09:13:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] 9p/xen: fix refcount leak in p9_xen_response() on wrong
 tag
To: Stefano Stabellini <sstabellini@kernel.org>,
 Yifei Gao <gyf161023@gmail.com>
Cc: Eric Van Hensbergen <ericvh@kernel.org>,
 Latchesar Ionkov <lucho@ionkov.net>,
 Dominique Martinet <asmadeus@codewreck.org>, v9fs@lists.linux.dev,
 Christian Schoenebeck <linux_oss@crudebyte.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 stable@vger.kernel.org
References: <20260804213550.3409638-1-gyf161023@gmail.com>
 <ebcebd30-68e2-1650-f0e6-b69e4239619c@kernel.org>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <ebcebd30-68e2-1650-f0e6-b69e4239619c@kernel.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------8si6pc96wSFhwkSY5O2H0kme"
X-purgate-ID: tlsNG-ef75cf/1785914013-35EC6AE4-85C07DC9/0/0
X-purgate-type: clean
X-purgate-size: 7753

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------8si6pc96wSFhwkSY5O2H0kme
Content-Type: multipart/mixed; boundary="------------VvTq5HqiTdsegQZQBXC4lBJZ";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
 Yifei Gao <gyf161023@gmail.com>
Cc: Eric Van Hensbergen <ericvh@kernel.org>,
 Latchesar Ionkov <lucho@ionkov.net>,
 Dominique Martinet <asmadeus@codewreck.org>, v9fs@lists.linux.dev,
 Christian Schoenebeck <linux_oss@crudebyte.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 stable@vger.kernel.org
Message-ID: <931b763d-2ee6-4fbf-9222-c5b75f35ec47@suse.com>
Subject: Re: [PATCH] 9p/xen: fix refcount leak in p9_xen_response() on wrong
 tag
References: <20260804213550.3409638-1-gyf161023@gmail.com>
 <ebcebd30-68e2-1650-f0e6-b69e4239619c@kernel.org>
In-Reply-To: <ebcebd30-68e2-1650-f0e6-b69e4239619c@kernel.org>

--------------VvTq5HqiTdsegQZQBXC4lBJZ
Content-Type: multipart/mixed; boundary="------------292XJsm8x0UioVDewQdpX8cO"

--------------292XJsm8x0UioVDewQdpX8cO
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMDI6MDYsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gT24gVHVl
LCA0IEF1ZyAyMDI2LCBZaWZlaSBHYW8gd3JvdGU6DQo+PiBwOV94ZW5fcmVzcG9uc2UoKSBs
b29rcyB1cCB0aGUgcmVxdWVzdCBmb3IgYW4gaW5jb21pbmcgcmVwbHkgd2l0aA0KPj4gcDlf
dGFnX2xvb2t1cCgpLCB3aGljaCB0YWtlcyBhIHJlZmVyZW5jZSBvbiB0aGUgcmV0dXJuZWQg
cDlfcmVxX3QuIFdoZW4NCj4+IHRoZSB0YWcgZG9lcyBub3QgcmVzb2x2ZSB0byBhIHJlcXVl
c3QgaW4gUkVRX1NUQVRVU19TRU5ULCB0aGUgZnVuY3Rpb24NCj4+IHdhcm5zIGFuZCBjb250
aW51ZXMgdGhlIGxvb3Agd2l0aG91dCBkcm9wcGluZyB0aGF0IHJlZmVyZW5jZSwgcGVybWFu
ZW50bHkNCj4+IGxlYWtpbmcgdGhlIHA5X3JlcV90IGFuZCBpdHMgbXNpemUgYnVmZmVycy4g
VGhlIHJlcGx5IGhlYWRlciwgaW5jbHVkaW5nDQo+PiB0aGUgdGFnLCBpcyBzdXBwbGllZCBi
eSB0aGUgYmFja2VuZCwgc28gYSBtYWxpY2lvdXMgb3IgYnVnZ3kgOVAgYmFja2VuZA0KPj4g
Y2FuIGxlYWsga2VybmVsIG1lbW9yeSBvbiBldmVyeSBjcmFmdGVkIHJlc3BvbnNlLg0KPiAN
Cj4gTW9zdCBiYWNrZW5kIGFyZSB0cnVzdGVkLCBpbmNsdWRpbmcgdGhpcy4gU28gSSB3b3Vs
ZCBhdm9pZCAibWFsaWNpb3VzIi4NCg0KTm8sIEkgdGhpbmsgdGhpcyBpcyBmaW5lLg0KDQpF
c3BlY2lhbGx5IHdpdGggZHJpdmVyIGRvbWFpbnMgbWFsaWNpb3VzIGJhY2tlbmRzIGFyZSBh
IHRoaW5nLiBUaGV5IHNob3VsZA0Kb25seSBiZSBjYXBhYmxlIHRvIGRlbGl2ZXIgd3Jvbmcg
b3Igbm8gZGF0YSB0byB0aGUgZnJvbnRlbmQsIGJ1dCBpZGVhbGx5DQp0aGUgZnJvbnRlbmQg
c2hvdWxkIG5vdCB0cnVzdCB0aGUgYmFja2VuZC4NCg0KQW55IHdvcmsgdG93YXJkcyB0aGF0
IGdvYWwgaXMgdG8gYmUgc3VwcG9ydGVkIElNSE8sIGFuZCB0aGVyZSBhcmUgYWxyZWFkeQ0K
ZnJvbnRlbmRzIGxpc3RlZCBpbiBYZW4ncyBzdXBwb3J0IHN0YXRlbWVudCBmb2xsb3dpbmcg
dGhpcyBydWxlLCBzbyBhbnkNCnZpb2xhdGlvbiBvZiB0aGF0IHByaW5jaXBsZSBpbiB0aG9z
ZSBmcm9udGVuZHMgd2lsbCBiZSByZWdhcmRlZCB0byBiZSBhDQpzZWN1cml0eSBpc3N1ZSB3
b3J0aCBhbiBYU0EuDQoNCg0KSnVlcmdlbg0K
--------------292XJsm8x0UioVDewQdpX8cO
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------292XJsm8x0UioVDewQdpX8cO--

--------------VvTq5HqiTdsegQZQBXC4lBJZ--

--------------8si6pc96wSFhwkSY5O2H0kme
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpy4pwFAwAAAAAACgkQsN6d1ii/Ey+H
KggAg6nytSOOYq8z0ItP8CPzGV2WeFi552GEXsho0t5VEJrJrI24Ujyyy954xFTbzaXtOHsU8fTJ
+URN3WaLFrA8LEz0IzTnDjNdR4sXwJT0QVuBlCzSo/XOKzQXR1xnZVk6rfS2rTy6v0caigYk2MlX
yYU3nUCUsR3IQJYAIY7E6PEM9MGAr9Xk6Vhv8iJHk2twCq5cXqfwSTQowOtgCI9T0HQufnz1wy7Q
cbxZfpclY4ahGtES2b/+saK8J54DPMFr2cwKJ5svBREmlL6o9YO7LWASnFdo9d7MEcP+mWXRq0hl
ZXBWLiXuEZW643jzUprYwwrrojFXqrubr9OIRM+3wA==
=DfBT
-----END PGP SIGNATURE-----

--------------8si6pc96wSFhwkSY5O2H0kme--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 07:18:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 07:18:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382904.1626180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVtX-0008Qe-WE; Wed, 05 Aug 2026 07:18:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382904.1626180; Wed, 05 Aug 2026 07:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrVtX-0008QX-Su; Wed, 05 Aug 2026 07:18:31 +0000
Received: by outflank-mailman (input) for mailman id 1382904;
 Wed, 05 Aug 2026 07:18:30 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrVtW-0008QR-Nn
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 07:18:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrVtV-002tHM-Ls
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:18:29 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72e3bb-5cb7-0a2a0a5109dd-0a2a4509d8b2-24
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 09:18:29 +0200
Received: from [209.85.218.51] (helo=mail-ej1-f51.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72e3c5-be1a-0a2a45090019-d155da33e9ad-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 09:18:29 +0200
Received: by mail-ej1-f51.google.com with SMTP id
 a640c23a62f3a-c1670dad7a8so103074166b.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 00:18:29 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2036276e58sm83701266b.28.2026.08.05.00.18.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 00:18:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785914309; x=1786519109; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=esFyuAFubsfqFMhJEZXWNUGl8u3Au7VYmA42/rCClR8=;
        b=LAnQ3dNRtmsPr7y9exiEhdmXeDktO4PfTS1cAyTXS2iRN83vXxvc+dS0HiBeosItPp
         ztTnD0GhiSAVrZTwENN2vR0uDFMJ0V8Mt0TEkZti+BeU4HmFiwB+z1UKbBDxGdb04WpS
         p8CRTyGo4w8JyYHaQ0cH79b3GDfhPJuVFGlZpjfmbNy7/m5HH/x7Mr+Crl0jGA3MZsL9
         wj9aEVvpwXMCpjpRMq9gMTNNobqh9Or+GdYzhScChR8J6vaqfdwFNpE6+4BP+mCaoJrD
         5/5YtvnxTIripaY5qNwpORQp58u7H3jE5ookrmuEe9h2XUWbjnivM46oO5bAzLma3rED
         YPtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785914309; x=1786519109;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=esFyuAFubsfqFMhJEZXWNUGl8u3Au7VYmA42/rCClR8=;
        b=Kn1IJnZtSPJk2ceJcADVrxewEUHfYU7GpRIGUndtgWFCqjafIgaubwkaWcL6z7KUm6
         gQRmU+f8n5UYroAafoEyYq2cp4MXjk78rUArxyGbAKUN3bfFvwZKLvSQEF3qeEQzCNSH
         xO4qNDkQjLp4my2STmgMsyavnUE25+V689fejWD4jN+YfDTt1B8jbmJvFoGNyFECCHAJ
         J0UuzqHbUP+d+14BOiJ1BrvP9CgwxR0sULUSPPTn/CO/ZZRysj1DtX+uD0m4T4qXqiQ/
         3TR6K/wOFKYne7j8OwUHZthzPk2LoA9GlF0b06d+V9I8WICzvau9kUJJkZIM6CtPCEbU
         +k8w==
X-Forwarded-Encrypted: i=1; AHgh+RpUvL8wNfL58mlCsBEhRFrBK38AhWzguYPbQsA12kWk/Iwf+0foXq01CkN6PlPotS4bqBgRXfvWW6A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEKhSx8wKojE7CXAtmuaOLriBNA0wwBWiMx6bZ/2Hvg/bFFXor
	oF8YdsX8SLhAFuKIpyai5Anfa+ktK93aWdqJXGAzOtHgnxcxWqmVOP91o8dzYPkeqD0=
X-Gm-Gg: AR+sD116znp8lTbs3C4XBqXIZym+u8CVqyi6bFF1rVFFbrTpvX/AlWLRXBfAf6MBOiG
	BUM+P0xK27myszfi3caYutChGzwq900fjxGTxrGmj/t/6/Tvz1mk10aixMefdmVmFUXsicbkmRJ
	ne+Ey7m7LlJ0RkRx2fvcPzNIMA1W1wVkKC7RXy63pmcSdlcKh9/cwFeDTEKGWHQ2ir8DBW3GEN/
	1fd03VrG6pDJPp9ObTO8rVXAwBkqDKDRUs70L6VQRUffTSeO/D1CERd7Z3X0chj/K3I8QSkJHBG
	F6CaGyw6akRTGkUxxXq68r6wQnalEW3J9/rQpWAkcpfWLxJsQmURyMZ2kguTx8GlDFqwUp2eH3f
	RYI64ZXRSoSablD4Z36S3FYUEf1iseMAcrMrpZ4DAWVBwUG16MC2wNZzvc5zQqKjLPBGuAMD9sX
	Vspz7RfijU+J6Y42x7JPVfQw4tEZARvAeJz4S49f1ro2tWyxI4aXWBpXXE0FYOXuP5T8TZfQnvN
	ePR04UF3JZtnsdff/f6TN8Tb0a0o6GDcILHMaa9Zgx4ZKKgvkWE64aiXENJQBgBtXagFWfvCxM9
	rPfbAM1K3uRbLrB++1LF7cGRTA==
X-Received: by 2002:a17:906:eec4:b0:c1c:2ee9:5e6d with SMTP id a640c23a62f3a-c2039c39717mr221970566b.17.1785914308967;
        Wed, 05 Aug 2026 00:18:28 -0700 (PDT)
Message-ID: <affa78c9-4c19-460d-89a1-0e84cada1c52@suse.com>
Date: Wed, 5 Aug 2026 09:18:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: linux-next: build failure after merge of the xen-tip tree
To: Mark Brown <broonie@kernel.org>, Val Packett
 <val@invisiblethingslab.com>, Konrad Rzeszutek Wilk
 <konrad.wilk@oracle.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Xen Devel <xen-devel@lists.xenproject.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Linux Next Mailing List <linux-next@vger.kernel.org>
References: <anITNOG1qicdE-TI@sirena.org.uk>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <anITNOG1qicdE-TI@sirena.org.uk>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------L7qBEoEZ6lPklBnqZkcGdVog"
X-purgate-ID: tlsNG-bad1c0/1785914309-3A8D9034-236C979F/0/0
X-purgate-type: clean
X-purgate-size: 6658

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------L7qBEoEZ6lPklBnqZkcGdVog
Content-Type: multipart/mixed; boundary="------------ZcgnOy51QMT7gJN76OXrlRf3";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Mark Brown <broonie@kernel.org>, Val Packett
 <val@invisiblethingslab.com>, Konrad Rzeszutek Wilk
 <konrad.wilk@oracle.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Xen Devel <xen-devel@lists.xenproject.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 Linux Next Mailing List <linux-next@vger.kernel.org>
Message-ID: <affa78c9-4c19-460d-89a1-0e84cada1c52@suse.com>
Subject: Re: linux-next: build failure after merge of the xen-tip tree
References: <anITNOG1qicdE-TI@sirena.org.uk>
In-Reply-To: <anITNOG1qicdE-TI@sirena.org.uk>

--------------ZcgnOy51QMT7gJN76OXrlRf3
Content-Type: multipart/mixed; boundary="------------qchc6mwxCU6mnmvcmLbmokzs"

--------------qchc6mwxCU6mnmvcmLbmokzs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDQuMDguMjYgMTg6MjgsIE1hcmsgQnJvd24gd3JvdGU6DQo+IEhpIGFsbCwNCj4gDQo+
IEFmdGVyIG1lcmdpbmcgdGhlIHhlbi10aXAgdHJlZSwgdG9kYXkncyBsaW51eC1uZXh0IGJ1
aWxkICh4ODZfNjQNCj4gYWxsbW9kY29uZmlnKSBmYWlsZWQgbGlrZSB0aGlzOg0KPiANCj4g
RVJST1I6IG1vZHBvc3Q6ICJpbml0X21tIiBbZHJpdmVycy94ZW4veGVuLXByaXZjbWQua29d
IHVuZGVmaW5lZCENCj4gDQo+IENhdXNlZCBieSBjb21taXQNCj4gDQo+ICAgIDY0ZDI2ZmIy
YWQxZjIgKHhlbjogcHJpdmNtZDogZml4IGlvZXZlbnRmZCBjcmFzaCB1bmRlciBQViBkb21h
aW4pDQo+IA0KPiBJIGhhdmUgdXNlZCB0aGUgdHJlZSBmcm9tIG5leHQtMjAyNjA4MDMgaW5z
dGVhZC4NCg0KSSBoYXZlIGRyb3BwZWQgdGhlIG9mZmVuZGluZyBwYXRjaCBmcm9tIHRoZSB4
ZW4tdGlwIHRyZWUuDQoNCg0KSnVlcmdlbg0K
--------------qchc6mwxCU6mnmvcmLbmokzs
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------qchc6mwxCU6mnmvcmLbmokzs--

--------------ZcgnOy51QMT7gJN76OXrlRf3--

--------------L7qBEoEZ6lPklBnqZkcGdVog
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpy48MFAwAAAAAACgkQsN6d1ii/Ey9R
7wf9EnPpdhTlTSVTBo1XfcO3WLaKMCfAgydfl0DD0cEZZj9aFaRzq+tF8ImI6z0Fv6wjjacd/uX/
46sX/I8Pe7iLweHDhkW1F5/0TFutOTy8Mi2zQMQ0geK7F8gVHV8Hl/jBpZ2boYlqlMiU0nUzqOYb
YKS9aoqJ3HtholZxj4BoOcigsqojd7912AZ+pEiiEF5OVTyk/QfyunOvXmk3qQ/KjqAdwezEKU3Y
sy9iQABE8SZSwXcQQSn/0Vw4DjlzUk1KwpgMou/VhGKY0Q8Dd3OZdnswMMlggZtjrP6uxnzjaR+w
01iC1kheI/gztx4Hhf6wHFB4dS0888S66aR0QSjw2Q==
=NrhC
-----END PGP SIGNATURE-----

--------------L7qBEoEZ6lPklBnqZkcGdVog--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 07:53:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 07:53:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382922.1626190 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWR6-0005ai-Hg; Wed, 05 Aug 2026 07:53:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382922.1626190; Wed, 05 Aug 2026 07:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWR6-0005ab-DY; Wed, 05 Aug 2026 07:53:12 +0000
Received: by outflank-mailman (input) for mailman id 1382922;
 Wed, 05 Aug 2026 07:53:11 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrWR5-0005aV-EF
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 07:53:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWR4-00E4m8-HD
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:53:10 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a72ebe5-bab6-0a2a0a5309dd-0a2a450c84a8-6
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 09:53:10 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a72ebe6-f479-0a2a450c0019-d1558031eda4-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 09:53:10 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49553515a8bso9179445e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 00:53:10 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a0f7b86sm160254105e9.10.2026.08.05.00.53.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 00:53:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785916390; x=1786521190; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=1VYSxA8qmfZtawmM+q3vCQMEETV4GCOYeujyXp2mk/o=;
        b=qKnCDFfwitDtmsHf4P3URc2QzB2KPb+oV57PtaehctpY1MsxpgY6SKCyPRiFYqgZMY
         jsJHO/WHFC2wUnRX9XTHzDwS61jS2pvV5zPM3mkOKqbqRkpLkvehmSM9f5eCYlM99/Eq
         r7BabXbs2ZhnqLvIft+Bd8BWlpHi3gnjiI9r4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785916390; x=1786521190;
        h=content-transfer-encoding:content-type: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=1VYSxA8qmfZtawmM+q3vCQMEETV4GCOYeujyXp2mk/o=;
        b=Txf7mRBgGzPN7V8aujsne9pgTEnLbu3yXgeCM6/Vy2WSDxQK5V7FVYEj3MWPAfifbp
         toqr4Ff87jmjAuPTu0Lt6+mE3yNRmWZPVEjAGzINJEbBgmLxMShsagipS3pzfWfy8b/z
         xTOPWDyqiVtpBbNpyhFztvVWSrBKJiSauKJ9N7eYHT5F9ZJjUEgUXq1vuS22UhtUBRSa
         hK37AXFaoy+BjeCTXAZvvfde5uSgvwD0e7S5cDOUBu8bHkwpzI/n9QwJ/EYkJ/RqlA8s
         SrF/UDyFlsLrVNSXeWkUo9l1jmh6p0dL5N1YOlX+IHu81NRx/5sVByQD+lYZ3xr6dCLl
         iSmQ==
X-Gm-Message-State: AOJu0Yx5YTz3dPFZ4x3WAcZP6bn+7Dd25ie5Qm/5pJCjXTpm8uLpoxnU
	X7R5EelatuvKGGxrqF6xP90RSrU7S2SYbR7hVbNORDVckvzvcUvwaJKaaYn2y2wFD54+dLDkFS6
	hiawKxz8=
X-Gm-Gg: AR+sD11YCVhhoKIz+84m2sIXX4tX8gco1nxvvj/mbjE9G+9LCljTYTwhZwrkrpQ3Ixh
	4PY4Y6J49adpOSOM8f8U80ToD3bqwUr/qa77e1qCbZHXjUGg0TeAdGnHhQmELbLNHp8YiwE1MyP
	wXrbLYlqDQcWYlmVnEA4xhqRxJVcDJtlvaXGPoLz+cczXoKKIJvniBNzE43gzdSY+t+TplQruOb
	PpKcS3glSVOu0vci1pxyyH3RHrIF3a01oug1/g54HrOntvUvbt3diW81cVl0Kn8otthVTVPANmB
	MKIJDZ+U9O3SNlhwAKFaA5Tpw2nFhrvW1kntbzKwRHygjJK8rGbENuClMLR7P9eiU8CXfx/hW31
	pfGIwpddCBgFU3BTEukIF1bG0jRf0Seu2wfX3rPDfksT6gtyMt1sZIYAcC4mOhDPBSxse8ZO+88
	quy2fzQ7LoC4wGV5vUiRGm/En0VlOMYMGPofumTxyOE3R06YQx8TjEbvCMz5LpZqA7u8MElAXQ
X-Received: by 2002:a05:600c:3150:b0:496:ca1f:a428 with SMTP id 5b1f17b1804b1-4994e7f3562mr41132765e9.19.1785916389368;
        Wed, 05 Aug 2026 00:53:09 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>
Subject: [PATCH v2 2/3] x86/alternatives: Rework get_ideal_nops()
Date: Wed,  5 Aug 2026 08:53:03 +0100
Message-Id: <20260805075303.23105-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20250522150015.555492-3-andrew.cooper3@citrix.com>
References: <20250522150015.555492-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1785916390-01EC2A5B-6928294C/0/0
X-purgate-type: clean
X-purgate-size: 3469

The {k8,p6}_nops[] arrays are both 80-byte structures indexing 45-byte
structures.  Furthermore, perhaps unusually for C, the source layout is an
obvious hint about the triangular nature of the structure.

Therefore, we can replace the pointer chase with some simple arithmetic.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>

v2:
 * Add build assertion.
---
 xen/arch/x86/alternative.c | 48 ++++++++++++++++----------------------
 1 file changed, 20 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index f0644055d3d3..30c5ccaa8b16 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -20,7 +20,7 @@
 #define MAX_PATCH_LEN (255-1)
 
 #ifdef K8_NOP1
-static const unsigned char k8nops[] init_or_livepatch_const = {
+static const unsigned char k8_nops[] init_or_livepatch_const = {
     K8_NOP1,
     K8_NOP2,
     K8_NOP3,
@@ -31,22 +31,10 @@ static const unsigned char k8nops[] init_or_livepatch_const = {
     K8_NOP8,
     K8_NOP9,
 };
-static const unsigned char * const k8_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
-    NULL,
-    k8nops,
-    k8nops + 1,
-    k8nops + 1 + 2,
-    k8nops + 1 + 2 + 3,
-    k8nops + 1 + 2 + 3 + 4,
-    k8nops + 1 + 2 + 3 + 4 + 5,
-    k8nops + 1 + 2 + 3 + 4 + 5 + 6,
-    k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
-    k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
-};
 #endif
 
 #ifdef P6_NOP1
-static const unsigned char p6nops[] init_or_livepatch_const = {
+static const unsigned char p6_nops[] init_or_livepatch_const = {
     P6_NOP1,
     P6_NOP2,
     P6_NOP3,
@@ -57,21 +45,9 @@ static const unsigned char p6nops[] init_or_livepatch_const = {
     P6_NOP8,
     P6_NOP9,
 };
-static const unsigned char * const p6_nops[ASM_NOP_MAX+1] init_or_livepatch_constrel = {
-    NULL,
-    p6nops,
-    p6nops + 1,
-    p6nops + 1 + 2,
-    p6nops + 1 + 2 + 3,
-    p6nops + 1 + 2 + 3 + 4,
-    p6nops + 1 + 2 + 3 + 4 + 5,
-    p6nops + 1 + 2 + 3 + 4 + 5 + 6,
-    p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
-    p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
-};
 #endif
 
-static const unsigned char * const *ideal_nops init_or_livepatch_data = p6_nops;
+static const unsigned char *ideal_nops init_or_livepatch_data = p6_nops;
 
 #ifdef HAVE_AS_NOPS_DIRECTIVE
 
@@ -86,9 +62,19 @@ static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal;
 # define toolchain_nops_are_ideal false
 #endif
 
+#define TRIANGLE(x) (((x) * ((x) + 1)) / 2)
+
+/*
+ * Both k8_nops[] and p6_nops[] are flattened triangular data structures,
+ * making the offsets easy to calculate.
+ *
+ * To get the start of NOP $N, we want to calculate TRIANGLE($N - 1)
+ */
 static const unsigned char *init_or_livepatch get_ideal_nops(unsigned int noplen)
 {
-    return ideal_nops[noplen];
+    unsigned int offset = TRIANGLE(noplen - 1);
+
+    return &ideal_nops[offset];
 }
 
 static void __init arch_init_ideal_nops(void)
@@ -601,3 +587,9 @@ void __init boot_apply_alt_calls(void)
     _alternative_instructions(ALT_CALLS);
     local_irq_enable();
 }
+
+static void __init __maybe_unused build_assertions(void)
+{
+    BUILD_BUG_ON(ARRAY_SIZE(k8_nops) != TRIANGLE(ASM_NOP_MAX));
+    BUILD_BUG_ON(ARRAY_SIZE(p6_nops) != TRIANGLE(ASM_NOP_MAX));
+}
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:21:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382948.1626199 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWsq-0002Jz-AM; Wed, 05 Aug 2026 08:21:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382948.1626199; Wed, 05 Aug 2026 08:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWsq-0002Js-6A; Wed, 05 Aug 2026 08:21:52 +0000
Received: by outflank-mailman (input) for mailman id 1382948;
 Wed, 05 Aug 2026 08:21:50 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrWso-0002Jm-TE
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:21:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWsn-008ug1-L9
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:21:49 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f28e-e002-0a2a0a5209dd-0a2a4507cbc0-22
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:21:49 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f29d-b4ea-0a2a45070019-c387df8296f8-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:21:49 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id E3F857F5C0;
 Wed,  5 Aug 2026 08:21:40 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8EFEB779B6;
 Wed,  5 Aug 2026 08:21:40 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id bGmkIZTycmp4cAAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 05 Aug 2026 08:21:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918105; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=ZlUiHzlOl4D77WVfNuxjUhwnv12jrJ8nA6UzE76W4yk=;
	b=WsxYk3InzEJgbAlhQcGmvBYnUe2QV6mzoQ38UT2XAHuE4I7tDyVj4oQgfJSDfmZcbSGC9j
	UUVJ/UQH5X7YP7oQviFKvGS3ET+q9NRaG8ZerzpxH680VLNQWUfskFQRlzT4XtaPFFzhUU
	5TLpqI+c/bHHwA/9ijuvwIm2vNfmqfU=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918100; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=ZlUiHzlOl4D77WVfNuxjUhwnv12jrJ8nA6UzE76W4yk=;
	b=Vue1K1DGhfIcM6sZ6/HbN2d7OJcgitsjyHaAfuNYZKeSeiHlNrNPo5R0wg2rTYgbm4wwS+
	MMh8k1ywscF/NfCV+iCdDJgGRdX0I+Vqt9mbSEY1QHdvRJdYaJnsnClszaBRU/A4I4fEsp
	3C1qNfq6ssxQG9Moi+JvFJZSCPajJo8=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: [PATCH 0/4] xen: cleanup config files
Date: Wed,  5 Aug 2026 10:21:33 +0200
Message-ID: <20260805082137.1214967-1-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.79 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.19)[-0.954];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWELVE(0.00)[12];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -2.79
X-Spam-Level: 
X-purgate-ID: tlsNG-ef75cf/1785918109-A6CDFAE4-4DA1D8EB/0/0
X-purgate-type: clean
X-purgate-size: 941

Do a cleanup of the Xen related Kconfig entries.

Juergen Gross (4):
  x86/xen: Remove redundant config dependency on X86_LOCAL_APIC
  xen: Drop CONFIG_XEN_PVHVM
  xen: Drop CONFIG_XEN_AUTO_XLATE
  x86/xen: Drop CONFIG_XEN_PVHVM_SMP

 arch/x86/include/asm/idtentry.h   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  |  2 +-
 arch/x86/xen/Kconfig              | 12 ++----------
 arch/x86/xen/Makefile             | 11 +++++------
 arch/x86/xen/time.c               |  2 --
 arch/x86/xen/xen-ops.h            |  4 ----
 drivers/xen/Kconfig               |  6 ------
 drivers/xen/Makefile              |  2 +-
 drivers/xen/events/events_base.c  |  7 -------
 drivers/xen/privcmd.c             |  4 ++--
 drivers/xen/xenbus/xenbus_probe.c |  2 +-
 include/xen/platform_pci.h        |  6 +++---
 include/xen/xen-ops.h             | 22 ----------------------
 13 files changed, 16 insertions(+), 66 deletions(-)

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:21:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382949.1626208 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWsv-0002XA-H9; Wed, 05 Aug 2026 08:21:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382949.1626208; Wed, 05 Aug 2026 08:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWsv-0002X1-D4; Wed, 05 Aug 2026 08:21:57 +0000
Received: by outflank-mailman (input) for mailman id 1382949;
 Wed, 05 Aug 2026 08:21:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrWsu-0002Wa-Fi
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:21:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWst-00BT1X-BI
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:21:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f296-bab6-0a2a0a5309dd-0a2a4508bcde-32
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:21:55 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2a3-f659-0a2a45080019-c387df83d376-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:21:55 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 9A9A03EE8;
 Wed,  5 Aug 2026 08:21:46 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 441B5779C3;
 Wed,  5 Aug 2026 08:21:46 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id iCFSD5rycmoKcQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 05 Aug 2026 08:21:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918110; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=OnKrqMmp33/ctRIhxID+//YqIMVJKj3PyOBSZaP2xuU=;
	b=U0We0YVgtE6Lxr5fhgkZV4EPZV4UcNMdx3VBu/3Izclwsm7Hnj9w7gorTh5rQe13AD+/69
	xXh21lfM+lTYYlEGZH0XpHEhCoLJicV76a8THubZMQ0w7UsuNrynMImvBie915Rl1dzayG
	W50M4W4wCMy1AZoEUW1rFEympNqdWJ8=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918106; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=OnKrqMmp33/ctRIhxID+//YqIMVJKj3PyOBSZaP2xuU=;
	b=d/1ekcpK9nnUZFXy4S14oeT+Xd9XtV0nWExr3VJY/OyzjkbB7z++Xy5zWJxldQAaNRQ6w9
	8lPrfsBJqWdxX4WbBOBk8xqYbHC3PINbhZA+wZLnPIuG0NKpPyx9VrCIjTXAGg7NvTpBfP
	bknonSPBSw93SQAOzDJLLpO+jfnj3Dk=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/4] x86/xen: Remove redundant config dependency on X86_LOCAL_APIC
Date: Wed,  5 Aug 2026 10:21:34 +0200
Message-ID: <20260805082137.1214967-2-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805082137.1214967-1-jgross@suse.com>
References: <20260805082137.1214967-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.79
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-6.79 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.19)[-0.957];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-purgate-ID: tlsNG-c1860d/1785918115-CDD4887B-6AB42BB5/0/0
X-purgate-type: clean
X-purgate-size: 607

CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 99b06f5c47cd..bb420a4cb75f 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -52,7 +52,7 @@ config XEN_PV_DOM0
 
 config XEN_PVHVM
 	def_bool y
-	depends on XEN && X86_LOCAL_APIC
+	depends on XEN
 
 config XEN_PVHVM_SMP
 	def_bool y
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:22:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:22:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382950.1626216 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWt1-0002nQ-NL; Wed, 05 Aug 2026 08:22:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382950.1626216; Wed, 05 Aug 2026 08: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWt1-0002nJ-K6; Wed, 05 Aug 2026 08:22:03 +0000
Received: by outflank-mailman (input) for mailman id 1382950;
 Wed, 05 Aug 2026 08:22:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrWsz-0002mC-Sk
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:22:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWsz-00BT6F-9N
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:22:01 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2a8-bab6-0a2a0a5309dd-0a2a4507c5d6-4
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:22:01 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2a8-b4ea-0a2a45070019-c387df83dff2-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:22:00 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 47C4C3F15;
 Wed,  5 Aug 2026 08:21:52 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EC717779B6;
 Wed,  5 Aug 2026 08:21:51 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id vQ1QOJ/ycmoPcQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 05 Aug 2026 08:21:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918116; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QTV4RA7a/5E53gmfFy4/nD7fff7Xl7GxWpiD9bWHF94=;
	b=Icw1np+Iuhkh3s+vA0MCKTbiRgi95UQZZMNkcXwb1/IcajlD9mm0uNFnpDGWuNBJXGFFkL
	awCxHi8KyyJ2XsACjgHcqjED1D7WAzdZMrROIc2MSOFnpWjRHS2rdnYoMRGJ/392d+4Prk
	r3ZXc5Jl5rjd9iP0PLnUf/sbfjjXmSE=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918112; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QTV4RA7a/5E53gmfFy4/nD7fff7Xl7GxWpiD9bWHF94=;
	b=uagAu9Tw6T6dPEjLyaJcTFNAs5xlAvIeSFOvl1jQwWRVjHj//uFbTJBNd8O9U/pZ8Grgat
	bKfoZSJ8Yo4lMT9NYfMpXjJy9fQmfT2ElgeW41BcReoxF0WdDpAujPkQTibTaONqQmejct
	IIEgjgt6AGcsH3KQnnmLwyOqbMYmUeQ=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM
Date: Wed,  5 Aug 2026 10:21:35 +0200
Message-ID: <20260805082137.1214967-3-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805082137.1214967-1-jgross@suse.com>
References: <20260805082137.1214967-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.79
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-6.79 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.19)[-0.958];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWELVE(0.00)[12];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-purgate-ID: tlsNG-ef75cf/1785918120-A7AD0AE4-5CAD2280/0/0
X-purgate-type: clean
X-purgate-size: 7220

On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.

In Xen specific x86 code it can be just dropped, in non-Xen specific
x86 code it can be replaced with CONFIG_XEN.

In architecture independent code it is used only where CONFIG_XEN is
defined, so it can be replaced with CONFIG_X86 there.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/idtentry.h   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  |  2 +-
 arch/x86/xen/Kconfig              | 10 +++-------
 arch/x86/xen/Makefile             |  9 ++++-----
 arch/x86/xen/time.c               |  2 --
 arch/x86/xen/xen-ops.h            |  4 ----
 drivers/xen/Kconfig               |  2 +-
 drivers/xen/events/events_base.c  |  7 -------
 drivers/xen/xenbus/xenbus_probe.c |  2 +-
 include/xen/platform_pci.h        |  6 +++---
 10 files changed, 14 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 20f548702404..f400cfac69a6 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
 DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
 #endif
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_XEN
 DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
 #endif
 
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index f3e9219845e8..73428afca796 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -31,7 +31,7 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] =
 #ifdef CONFIG_XEN_PV
 	&x86_hyper_xen_pv,
 #endif
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_XEN
 	&x86_hyper_xen_hvm,
 #endif
 	&x86_hyper_vmware,
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index bb420a4cb75f..9e5bb51eecf4 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,24 +50,20 @@ config XEN_PV_DOM0
 	def_bool y
 	depends on XEN_PV && XEN_DOM0
 
-config XEN_PVHVM
-	def_bool y
-	depends on XEN
-
 config XEN_PVHVM_SMP
 	def_bool y
-	depends on XEN_PVHVM && SMP
+	depends on XEN && SMP
 
 config XEN_PVHVM_GUEST
 	bool "Xen PVHVM guest support"
 	default y
-	depends on XEN_PVHVM && PCI
+	depends on XEN && PCI
 	help
 	  Support running as a Xen PVHVM guest.
 
 config XEN_PVH
 	bool "Xen PVH guest support"
-	depends on XEN && XEN_PVHVM && ACPI
+	depends on XEN && ACPI
 	select PVH
 	help
 	  Support for running as a Xen PVH guest.
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 717264ae269b..32d651aa9bc2 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -16,11 +16,10 @@ obj-y				+= mmu.o
 obj-y				+= time.o
 obj-y				+= grant-table.o
 obj-y				+= suspend.o
-
-obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o
-obj-$(CONFIG_XEN_PVHVM)		+= mmu_hvm.o
-obj-$(CONFIG_XEN_PVHVM)		+= suspend_hvm.o
-obj-$(CONFIG_XEN_PVHVM)		+= platform-pci-unplug.o
+obj-y				+= enlighten_hvm.o
+obj-y				+= mmu_hvm.o
+obj-y				+= suspend_hvm.o
+obj-y				+= platform-pci-unplug.o
 
 obj-$(CONFIG_XEN_PV)		+= setup.o
 obj-$(CONFIG_XEN_PV)		+= apic.o
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index d62c14334b35..5c7822254a01 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -586,7 +586,6 @@ void __init xen_init_time_ops(void)
 		x86_platform.set_wallclock = xen_set_wallclock;
 }
 
-#ifdef CONFIG_XEN_PVHVM
 static void xen_hvm_setup_cpu_clockevents(void)
 {
 	int cpu = smp_processor_id();
@@ -643,7 +642,6 @@ void __init xen_hvm_init_time_ops(void)
 
 	hvm_time_initialized = true;
 }
-#endif
 
 /* Kernel parameter to specify Xen timer slop */
 static int __init parse_xen_timer_slop(char *ptr)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index dc265bdda24d..47eebbb3684a 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -236,11 +236,7 @@ void xen_pin_vcpu(int cpu);
 
 void xen_emergency_restart(void);
 
-#ifdef CONFIG_XEN_PVHVM
 void xen_hvm_post_suspend(int suspend_cancelled);
-#else
-static inline void xen_hvm_post_suspend(int suspend_cancelled) {}
-#endif
 
 /*
  * The maximum amount of extra memory compared to the base size.  The
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f9a35ed266ec..cfb517cd77dc 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -311,7 +311,7 @@ config XEN_EFI
 
 config XEN_AUTO_XLATE
 	def_bool y
-	depends on ARM || ARM64 || XEN_PVHVM
+	depends on ARM || ARM64 || X86
 	help
 	  Support for auto-translated physmap guests.
 
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6ea945508a89..fd16d652c81f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2180,7 +2180,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
 };
 
 #ifdef CONFIG_X86
-#ifdef CONFIG_XEN_PVHVM
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -2242,12 +2241,6 @@ static __init void xen_alloc_callback_vector(void)
 	pr_info("Xen HVM callback vector for event delivery is enabled\n");
 	sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_xen_hvm_callback);
 }
-#else
-void xen_setup_callback_vector(void) {}
-static inline void xen_init_setup_upcall_vector(void) {}
-int xen_set_upcall_vector(unsigned int cpu) {}
-static inline void xen_alloc_callback_vector(void) {}
-#endif /* CONFIG_XEN_PVHVM */
 #endif /* CONFIG_X86 */
 
 bool xen_fifo_events = true;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index fafb2b84fa5c..082b8c1fee8e 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -831,7 +831,7 @@ static void xenbus_probe(void)
  */
 static bool xs_hvm_defer_init_for_callback(void)
 {
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 	return xen_store_domain_type == XS_HVM &&
 		!xen_have_vector_callback;
 #else
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
index e51e7cb71a85..267040c1f504 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -30,7 +30,7 @@
 static inline int xen_must_unplug_nics(void) {
 #if (defined(CONFIG_XEN_NETDEV_FRONTEND) || \
 		defined(CONFIG_XEN_NETDEV_FRONTEND_MODULE)) && \
-		defined(CONFIG_XEN_PVHVM)
+		defined(CONFIG_X86)
         return 1;
 #else
         return 0;
@@ -40,14 +40,14 @@ static inline int xen_must_unplug_nics(void) {
 static inline int xen_must_unplug_disks(void) {
 #if (defined(CONFIG_XEN_BLKDEV_FRONTEND) || \
 		defined(CONFIG_XEN_BLKDEV_FRONTEND_MODULE)) && \
-		defined(CONFIG_XEN_PVHVM)
+		defined(CONFIG_X86)
         return 1;
 #else
         return 0;
 #endif
 }
 
-#if defined(CONFIG_XEN_PVHVM)
+#if defined(CONFIG_X86)
 extern bool xen_has_pv_devices(void);
 extern bool xen_has_pv_disk_devices(void);
 extern bool xen_has_pv_nic_devices(void);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:22:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:22:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382952.1626224 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWt6-000379-UM; Wed, 05 Aug 2026 08:22:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382952.1626224; Wed, 05 Aug 2026 08: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWt6-00036y-R4; Wed, 05 Aug 2026 08:22:08 +0000
Received: by outflank-mailman (input) for mailman id 1382952;
 Wed, 05 Aug 2026 08:22:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrWt5-00033d-2w
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:22:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWt4-00BT5q-Fi
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:22:06 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2ac-5cb7-0a2a0a5109dd-0a2a4506c88a-12
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:22:06 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2ae-195a-0a2a45060019-c387df82848e-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:22:06 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id CD87B7FC54;
 Wed,  5 Aug 2026 08:21:57 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A2099779C2;
 Wed,  5 Aug 2026 08:21:57 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id sW4hJqXycmobcQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 05 Aug 2026 08:21:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918121; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=S6wRDsn8zV14CO6Sq0N2+3DPezIzqVg17lA8ie3S0eU=;
	b=Un5S22ckkkMJV+DlydoaTV76Mst3f0Mr745x2lsvZTgHTbZ2DxOFRNna5KaPLtdY/mp+Nh
	vuAyKT3ikDFEgkC40MNnRXHIjTpDf/iCQoa4/rEV+61AKT3jMUoYsL3ZrAmsMqVhORMArP
	Btm09DVWxJzk5PFBlU4wxaBMmsYTWeo=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918117; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=S6wRDsn8zV14CO6Sq0N2+3DPezIzqVg17lA8ie3S0eU=;
	b=aDNX1xHePNwswx+9Pi36xqmHVw1AeMuAKP4+T7bm2glLOOcnbtQ2dCSMwPoz21GQbBRONH
	nImWX83UwYbG8rfNzz9sy+zpogUnOZC/3L81GCVvwidEmDqUpYkR8L4AQxm1dcfwXJvNB4
	G1fURSmZMBIYonryH72LDCm3UB/9RZY=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE
Date: Wed,  5 Aug 2026 10:21:36 +0200
Message-ID: <20260805082137.1214967-4-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805082137.1214967-1-jgross@suse.com>
References: <20260805082137.1214967-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-6.79 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.19)[-0.966];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -6.79
X-Spam-Level: 
X-purgate-ID: tlsNG-16d1c6/1785918126-1FACA77B-7E098417/0/0
X-purgate-type: clean
X-purgate-size: 3777

CONFIG_XEN_AUTO_XLATE is referenced only in code built with CONFIG_XEN
enabled. As it is enabled for all architectures supporting Xen, it can
be just dropped.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 drivers/xen/Kconfig   |  6 ------
 drivers/xen/Makefile  |  2 +-
 drivers/xen/privcmd.c |  4 ++--
 include/xen/xen-ops.h | 22 ----------------------
 4 files changed, 3 insertions(+), 31 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index cfb517cd77dc..32e35a8580ee 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -309,12 +309,6 @@ config XEN_EFI
 	def_bool y
 	depends on (ARM || ARM64 || X86_64) && EFI
 
-config XEN_AUTO_XLATE
-	def_bool y
-	depends on ARM || ARM64 || X86
-	help
-	  Support for auto-translated physmap guests.
-
 config XEN_ACPI
 	def_bool y
 	depends on X86 && ACPI
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index c0503f1c7d5b..6ce2e2a52d47 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 obj-y	+= grant-table.o features.o balloon.o manage.o time.o
 obj-y	+= mem-reservation.o
+obj-y	+= xlate_mmu.o
 obj-y	+= events/
 obj-y	+= xenbus/
 
@@ -29,7 +30,6 @@ obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
 obj-$(CONFIG_XEN_EFI)			+= efi.o
 obj-$(CONFIG_XEN_SCSI_BACKEND)		+= xen-scsiback.o
-obj-$(CONFIG_XEN_AUTO_XLATE)		+= xlate_mmu.o
 obj-$(CONFIG_XEN_PVCALLS_BACKEND)	+= pvcalls-back.o
 obj-$(CONFIG_XEN_PVCALLS_FRONTEND)	+= pvcalls-front.o
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 725a49a0eee7..7cfc28f1bb86 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -794,7 +794,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
 		goto out;
 	}
 
-	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
+	if (!xen_pv_domain()) {
 		unsigned int nr = DIV_ROUND_UP(kdata.num, XEN_PFN_PER_PAGE);
 		struct page **pages;
 		unsigned int i;
@@ -825,7 +825,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
 	if (rc)
 		goto out;
 
-	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
+	if (!xen_pv_domain()) {
 		rc = xen_remap_vma_range(vma, kdata.addr, kdata.num << PAGE_SHIFT);
 	} else {
 		unsigned int domid =
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 496e6013c689..15e0c3f4b7bb 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -59,7 +59,6 @@ static inline int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
 
 struct vm_area_struct;
 
-#ifdef CONFIG_XEN_AUTO_XLATE
 int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
 			      unsigned long addr,
 			      xen_pfn_t *gfn, int nr,
@@ -68,27 +67,6 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
 			      struct page **pages);
 int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
 			      int nr, struct page **pages);
-#else
-/*
- * These two functions are called from arch/x86/xen/mmu.c and so stubs
- * are needed for a configuration not specifying CONFIG_XEN_AUTO_XLATE.
- */
-static inline int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
-					    unsigned long addr,
-					    xen_pfn_t *gfn, int nr,
-					    int *err_ptr, pgprot_t prot,
-					    unsigned int domid,
-					    struct page **pages)
-{
-	return -EOPNOTSUPP;
-}
-
-static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
-					    int nr, struct page **pages)
-{
-	return -EOPNOTSUPP;
-}
-#endif
 
 int xen_remap_vma_range(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long len);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:22:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:22:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382957.1626234 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWtC-0003U5-AH; Wed, 05 Aug 2026 08:22:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382957.1626234; Wed, 05 Aug 2026 08: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWtC-0003Tt-72; Wed, 05 Aug 2026 08:22:14 +0000
Received: by outflank-mailman (input) for mailman id 1382957;
 Wed, 05 Aug 2026 08:22:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrWtA-0003QP-QT
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:22:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWt9-0036dz-Ud
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:22:11 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2b1-5cb7-0a2a0a5109dd-0a2a450aa3f2-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:22:11 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f2b3-f2d2-0a2a450a0019-c387df8285d6-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:22:11 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 717A67FC46;
 Wed,  5 Aug 2026 08:22:03 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2AD8B779B6;
 Wed,  5 Aug 2026 08:22:03 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id kWcaCavycmohcQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 05 Aug 2026 08:22:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918127; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=rPDqya+4UA57J3GUJhbUC4MCTBzBvrkl/Z2toy8Sr1k=;
	b=ZoGUiQsj0jyqR8egDB6TgaUfolmQBnQi1EashLbUpEn9JMdtMrIgLSHNpTtJXjrYXCeDKw
	R3YHsrovTBo+1vz/RXS20N/cv10G2LLDnDVoozg98STi8eOF8ZpSZuE9Z5HiJQTJzuNYju
	tq5iViYKyQrSu0vC9Cx984N5YONY5Nc=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1785918123; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=rPDqya+4UA57J3GUJhbUC4MCTBzBvrkl/Z2toy8Sr1k=;
	b=mo44s7jJ01TikRPeLn+M7SzLNQoKze3eAxQ4UHYFODcY4riiv0QCSJnyczh3TFIu1NDoOy
	HMcPUpmkdfSt0h+nx86nxIPWVbyGP0dvshsoT8uyF88sKCYLQGR/NY4BXdU6YQYC5UaKVJ
	Y3cGuKyyN+V46bgtJruvIgsMvqkW4YI=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
Date: Wed,  5 Aug 2026 10:21:37 +0200
Message-ID: <20260805082137.1214967-5-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805082137.1214967-1-jgross@suse.com>
References: <20260805082137.1214967-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.79
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-6.79 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.19)[-0.958];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FROM_EQ_ENVFROM(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)];
	RCPT_COUNT_SEVEN(0.00)[10];
	RCVD_TLS_ALL(0.00)[]
X-purgate-ID: tlsNG-4011c0/1785918131-59DDFCFC-F698A839/0/0
X-purgate-type: clean
X-purgate-size: 1145

CONFIG_XEN_PVHVM_SMP is referenced only on x86 in Xen specific code,
so it can be replaced with CONFIG_SMP.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/Kconfig  | 4 ----
 arch/x86/xen/Makefile | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 9e5bb51eecf4..609e79942fcb 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,10 +50,6 @@ config XEN_PV_DOM0
 	def_bool y
 	depends on XEN_PV && XEN_DOM0
 
-config XEN_PVHVM_SMP
-	def_bool y
-	depends on XEN && SMP
-
 config XEN_PVHVM_GUEST
 	bool "Xen PVHVM guest support"
 	default y
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 32d651aa9bc2..9c7e9ffffb85 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
 obj-$(CONFIG_EVENT_TRACING)	+= trace.o
 
 obj-$(CONFIG_SMP)		+= smp.o
+obj-$(CONFIG_SMP)		+= smp_hvm.o
 obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
-obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
 
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:29:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:29:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382989.1626243 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWzu-00051I-00; Wed, 05 Aug 2026 08:29:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382989.1626243; Wed, 05 Aug 2026 08:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrWzt-00051B-Tg; Wed, 05 Aug 2026 08:29:09 +0000
Received: by outflank-mailman (input) for mailman id 1382989;
 Wed, 05 Aug 2026 08:29:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrWzs-000515-KW
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:29:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrWzs-00BUsu-1H
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:29:08 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72f44c-e002-0a2a0a5209dd-0a2a450cdf62-16
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:29:07 +0200
Received: from [40.93.201.62]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72f450-f479-0a2a450c0019-285dc93ebed9-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:29:05 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DS0PR03MB8200.namprd03.prod.outlook.com (2603:10b6:8:293::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Wed, 5 Aug
 2026 08:29:03 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Wed, 5 Aug 2026
 08:29:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nPJ1TbLNTdv6viWLD3koI5xTNKI7wWR1p/UVLidU4tbYZdiQ/NA42uujDx2HP/U+SbjB6YUqX0TIcACSaULGWcEThyZ1rYiPrf0I/0ZUFxrc+52YETvsA5ksMXIktTsecNX3ZdzbEnQd3rztcxT/0toWH55XGn19Gu68pLi00DLBAtMvyAmwMvrLRW5E0qFfmTzLO1y+6svwwYTbPq+R913qIgFT74q927AqFn21xWHWezmxdRC3vmxwfXT4kXg1KE5plgfxN+uyV8pgbFo4YqY3V784EMwB4M5FGdPSKZzDCxx4ND56tFw1Xrk7ZX0BP7rLmvldlxQokmsxNjlXTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zp/pgBZDH+Lb5CV4YMTtHDjw9PCQLOyzUIdgVtTacZo=;
 b=y0u8zX0vqIQ9gS819nqF2CYWSkB3L7PE8lyCFdfsmdYR3w2/nBAHRo082Zb9GXFZcDUoQXvzwRvvk36c6rM8XPa+i2Elk5cFADtOxkMTSduW9qvhaltVlvmxe4+Azp3R0ykIZOj5ntrQAl7qXwSnFQ/MRf1ckZXmNiZYDMhZX/TK8MoEpvXmDgrFdFo0sYqMziu9LGM1Myu4kIgd3F9L44qCefel2wx0Y6M1GG6LJS/GNKEJxJ/s2/OzewPFJYb4SS0iazjlBmBL1y3COkyDanS3tFjIOULZWIqhfU1mRJaaN6HZWjmgxtLXGF0Yv5yPAzSW58oUUasQfjXcYzwLeA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zp/pgBZDH+Lb5CV4YMTtHDjw9PCQLOyzUIdgVtTacZo=;
 b=leoN1A5FCrGr46CLtKoG/rdEdx1yCNNk7cO3Hgh/HJGU3J23Bc5MxPd6TWk7bsbE1lsIMdYFvVmAAMmdIjJuqjnDn4W2tvo9Uj2qVal5VuUW2kMkhphNZjW5+bYOP/X1aLSpsLAocvTC6RZaaDMurX2ksIH0QrRcji0o2bDwDxw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <7179e004-76df-42be-94fd-f314614e65cd@citrix.com>
Date: Wed, 5 Aug 2026 09:28:58 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM
To: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-3-jgross@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260805082137.1214967-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO6P265CA0006.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:339::15) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB8200:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e5c4a25-2d68-494e-3309-08def2cb9b1c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|1800799024|376014|7416014|366016|10067099003|4143699003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	ROBnaTTJpTdEkEkWEZ6ZWx34O5Fvyweh5G753wFmi3yYPvwQY92t6fW7ZBsr/96q4CG61a4qaRq6sbEtsw60wtRfLX4fH4pgLUPSUyU4+XfzYlUgLBSuKmG7oxz4ZwbVLCs3/YRMcASbLfEryVPHdOQisf/i2EJhHqZEsqRCjY7tUKnQ9QwHrVucmSNOf1wQ54bXP5fT4tIZ88H+hIKv6sQA7feFsIxomTbePoRB+vm12Zt/9PxczpydfVyiEjwz6CUD3ccl/YyQVrWmaTzQyu4pfH8Mmw4b3NFAMWAUot3M2PCGPPMvgbjC1LpF5j1xTRg1miUt0A2LJF+JYm53TA8KMHmSoyNET53+VaMT1xDdfBX7XWDGydvUL4uqqcirW7xw//S6KwhRh+/lprsatcD2+Zs7Sj/FC5Rzk82l0LMbnF8PkSbVuOpzzwzx+6LWJg6hEsK3HsR6sioijmu9Y54n6+QKo1o3dJc+wywtdcjsOHR38x9zxI/ZW2hyEVb4UZurELvihC+3PYAIWTr0Cu3FILXseF+IXssL+JXc/tc9lV+RyFWsCdu63L/hzoOYutDYLFIr31etGiQ9ciNYIvf+AFv2xD1uokBQwiUeA83h+pLsGvORDEUHPEkdh4vE0U+9xy43dHomDbm+AfR0hGb+eg66hi0MCr6QaImlY3I=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(7416014)(366016)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YndXcnFBUmJYN1N5dUhqRnhtZFpDMUlpVVJkTUhnTk5jOExpRUY3Y2EvSnhX?=
 =?utf-8?B?a3dKOGZ3RUVaNHJBSnpQWUlDN3hZMUxTRjdFSjJiMUZMaVBmaU9ndjFwSGNG?=
 =?utf-8?B?NWJIRlJnNldMdkliZStVL24xaTFwbkdwUTFReHYyeUZrWHRBUkZKUGxrT2ZY?=
 =?utf-8?B?MVVJTFRZQ3RhSThHc1NDODRZTk1QcUdsZDcwZDRjTE14RmozbThPZE1YWnp2?=
 =?utf-8?B?QzBKVHIrYmtqTEdTN055NGp6RzMvai82L2sxQnpWNlVycVdkeDNVTFdaSEhJ?=
 =?utf-8?B?ZnRyNUkzYzdRYWUxZ2JmeTIwZjNZQm1XMm9GTzJWUTRaOTZ2UEZRanhWWisw?=
 =?utf-8?B?amtJZWVLQk9lZlpOZXJSN3RJbjhzeHJwK2NBb0VZNEJMcW9XTWN6YUhCV2ZD?=
 =?utf-8?B?QTFBcUtZZmNYUTh1Mzl1ekl5dlRicEcwSWZEdzlJRzFuTGlpRi92N3hlaUFO?=
 =?utf-8?B?QmFtQllUZXUzVXNHaVBBZmcrLzZvUHU2bHBPaGxJYjY3dXRrSHExaWJjZ096?=
 =?utf-8?B?N1JFRnhiQTZGTk94c3E4UVd6NW90YS93dWJNTjFQVE5hV1lKd3o2aU5TVzFs?=
 =?utf-8?B?NTJ1b0JCQkZvV3VBMEtSc0xqeGE4ZDBKVmNWTzVHcTEvTWtkR1lGMVo3TnFu?=
 =?utf-8?B?ZlpRQzRkemlVeXBiRTZobGlhNndIOURTd0FES0c5b2tiS0cyU1ZaUURmeks3?=
 =?utf-8?B?UjhSYW9xdVZHL3dNaEJ6Y1RMZTgxeXROYmptbUZkMS8zNHk3MEJISC9VTXJS?=
 =?utf-8?B?TTlQbGhKRG9FZFY5RHR0cWxhbW5WT25KbkV3V1lCSkRRQVRKZWtFKzJWQVJD?=
 =?utf-8?B?bDNKWEZmdW5zKzVqcFBqUG9ZYXNlM1VEeUNTVkRQZGx0Q1NVZkQraXM2QzU0?=
 =?utf-8?B?UlJ4TG5NcC9CNVJZekNkU3QwV1hKNGJEMHo4c1pjaWM5MnNLWGpvR3hiZ25o?=
 =?utf-8?B?OUZLdU9GV3g0U1lWWTJhM0pHcVluWUdCRUxQM3g5eTNsdkxJWkUyKzJ3TWtW?=
 =?utf-8?B?dTA5SnZBSGV1ZnBsd1FBTDBTOTg5blNjTllIcUdYekptdWZyZzJhYVg0anJ0?=
 =?utf-8?B?MFU0VmZQV3lndlp1N3p6WnAycGorRGUxMnNBTm1QSGg0OFVHakZmSTN1ejFP?=
 =?utf-8?B?MWJEL3NUdjFET3BXczEwVlRVYXgvSnhuRDBLQ3dvK1V1S0F4TEh5cjE4SkY2?=
 =?utf-8?B?d3B1KzlyZitWbnREYWltL0dzMEFCS3hNZ0hIVk51V3EvU2ZZOG9BV1ZZR1o1?=
 =?utf-8?B?ck1DOWYydVcwQzU2a1hxQkxuQ1NEeGxPMlhqc1JKNDN5bytQam9CanJMdDBC?=
 =?utf-8?B?dmx2Z3lENkNQNUZrUkpJalovU3dCVG84c2xQK1NYbjRjYnlEVmVUTjV3VE53?=
 =?utf-8?B?aHc2OTZ2UCtLcVRyWkhYa1FESGdva3FreUZTSjhCWWsybHRlakR2MVFvNG1D?=
 =?utf-8?B?TmRJUUVieFlTZ0ZLb3MvQTNvdnRlb2RGTkp1aGt0YmFiek10VkcxbStITUdN?=
 =?utf-8?B?WWExVnNaNHdUbHBIZkdmL2lYN096M2RPeXZGcmdrQzBIL3I0eVNkU2w4UjJI?=
 =?utf-8?B?TlRsNVRWTldjNVphcEU4eHJtV0tqTkdHNDNlYkNjcHVSVUJDbERicjduMDBL?=
 =?utf-8?B?ZkFQWjZ0aTdmNGdnb015TGZ6SEtqM21qUDhicE5qdE4vanc5dW5yRE82K1Qr?=
 =?utf-8?B?V2JHdVNxL2dnazZ4VXFRNjgzdXA3NHJOKzc3TitUWXZVRlhFY2cycHRrdEpn?=
 =?utf-8?B?MUZXUDRwWllQTkJkWlZVU0dwa251dDUzbStUY3lhakI2cTI4NncwanNBL05I?=
 =?utf-8?B?ZWkySzNibWxld1lDUW5ldTlCc1RKRDFhNUpXWHArWld0U1c1S09WK2R4WmFz?=
 =?utf-8?B?SURES0ZRTWxkTDBBZnZYcnJaT3dmNkV4UlU1RzVQVnVXWkR1TW9yMDNMMEJ1?=
 =?utf-8?B?SVZrWVc1NkR0ajV6ZnY1WGhFVDJURUp1THhRZnNSLzFLNmc2Z21PVXlSS1h4?=
 =?utf-8?B?bUExWkxaUGg1SjlMTGQxTGVIQUdhSksxcDRwL2tUbXcxNmNrbm10NW9VQUdD?=
 =?utf-8?B?eEwwRGk3WXM4REpwZ29kcjJYUmlKc1FXcUlXZkRxd3JHMzRGUWoyVkxJZ1Nq?=
 =?utf-8?B?bER6YjFWamdQV3VzRVVLQjQxQ1RaNkRxbkNpbmhRUU8zSldwM3Jpb1JIS25i?=
 =?utf-8?B?NmR6cklZUlZNRUFaTWZ1TDUybWVydmxkY0pxWm1IRUd5SU85a3hscXAyWjJo?=
 =?utf-8?B?cmsrczdvcFFnMmtLMkpPSnpVUGdROEFWVTUwU1JnaTVQeVh6eGFEcno3Mkdp?=
 =?utf-8?B?dmZUVS9kaWU5b0h4TUE5Nm9CVzlNNXNaMXBDMWNnZ1R4ZUZCYXoyWVhUVHJx?=
 =?utf-8?Q?TsRf4a0Uk6kyvqpQ=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e5c4a25-2d68-494e-3309-08def2cb9b1c
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 08:29:02.9384
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: HERn3Vt9+OjSsnyeOfZMaWYTZ8aZbnTaa9KV26QeQg/1znFjAI/B07/ItGBQgIXz+8MEauJM9+Ojdri2I2KnRjdScCTp/m/hoI+7I+Q0xHM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8200
X-purgate-ID: tlsNG-d25034/1785918546-00CCBA5B-FBA10572/0/0
X-purgate-type: clean
X-purgate-size: 1206

On 05/08/2026 9:21 am, Juergen Gross wrote:
> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
>
> In Xen specific x86 code it can be just dropped, in non-Xen specific
> x86 code it can be replaced with CONFIG_XEN.
>
> In architecture independent code it is used only where CONFIG_XEN is
> defined, so it can be replaced with CONFIG_X86 there.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
>
> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
> index 20f548702404..f400cfac69a6 100644
> --- a/arch/x86/include/asm/idtentry.h
> +++ b/arch/x86/include/asm/idtentry.h
> @@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
>  #endif
>  
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_XEN
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
>  #endif

I'm very happy to see a reduction in the number of Kconfig symbols for
Xen (there are definitely too many), but this looks wonky.

Or are you saying that there really is no way to build a Xen PV guest
excluding the HVM-only bits?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:29:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:29:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1382997.1626252 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrX0X-0005W6-7f; Wed, 05 Aug 2026 08:29:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1382997.1626252; Wed, 05 Aug 2026 08:29:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrX0X-0005Vz-4r; Wed, 05 Aug 2026 08:29:49 +0000
Received: by outflank-mailman (input) for mailman id 1382997;
 Wed, 05 Aug 2026 08:29:48 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrX0W-0005Vt-6Y
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:29:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrX0V-0038D2-JZ
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:29:47 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f46f-2eae-0a2a0a5409dd-0a2a45099aea-42
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:29:47 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f47b-be1a-0a2a45090019-d155dd2ab9ab-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:29:47 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47f84023916so585398f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:29:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfe5d7csm7306200f8f.15.2026.08.05.01.29.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:29:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785918587; x=1786523387; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=cAYu0/I5sBdxVDFVz3zsOh9BrRmirAGTcNyUBffNHFs=;
        b=KNXpGbxyvXhdsAnZlOnygETV9HzqBRF48vBEK7vCGiCnZ0cg9s/O6qW+c2wDG8zDp3
         c7n/YNwFBa9Zz/NHaFNS8FEGNynMK6UFLV3Ln5O0C+Fw7maA7o0FZn9PBFY7NDGx1LC/
         JTuKqOyhPwbOVXnr/AS6TkcpZyZITOJ9J6/p3uMvNYF6rRQ5uQe8s7X2KBWcRWBaA0U6
         03AIIMi15Bzo286LJ7nlncx8W5TRvJ5sWb7bh77wku5pJJ72PV9lscjVP+BFG4B+3N//
         qjhD53RCgqv8uY0OKj6QCAVk+gqBr6cXR2Uo/A8CaSonIBDZEdg6lLtDEuoqkFynATlK
         0Kpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785918587; x=1786523387;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cAYu0/I5sBdxVDFVz3zsOh9BrRmirAGTcNyUBffNHFs=;
        b=BXsgIfnTuczky4IfoA+ZB4nwWDiU8SqHiIAhqCXUeYPknKW6mV1L3iOWfMTciWYMga
         w02SejC9Qm2KHa2o6bAyNjXzV8aJHB0nO03QB00HwKcanejtEKnBqjq+zaHdXYJ+Z/6+
         OWGo+sFlMpPjNFmPB92lakIpaoBTLVhaJL3bKM1SMvTjnMPx7+vOecDSQl7V5eihE1NK
         Umc3z5bGvNjOTuIim/ZGtCeT1DrsKOQOI+lWNPyYCFs9JyjIhyh9teUONRkO0pZFyPd4
         BomHu2g3vWlFCYOJRYuXMMxjJpB9dnDRDHh9jCNS0/jLC5F/LgEc4E2LUf6J2+Ug21fD
         l0gw==
X-Gm-Message-State: AOJu0YwLrwYl7/VAw/if8LPUijlp5eV4zyJw9SJIMtjyiTwpZgwQyU5W
	jYZ/8+8Mllra8L+SCz+GlAOgms/MQ0GzblVlhIu8ocGYS5Km7sfSN9k6GlLyrOFjrsGI9FYNUTJ
	TWB59vA==
X-Gm-Gg: AR+sD10ZADqSR4fdXab7GzTcRJQ5yIKBoskNr+GMlz8ACKpLkhPatsPZyes1kI2pU/M
	AzpQrC26a4N0Qt+azs8q8202U8HUo5B/BBxUH99s64hRdY1ltv1cwElsdVHlW7yrQPGRMFck6Of
	QYOlUwQ+g4WU+9gSHyUfuDr5ajafi6z19F8Mi80rGkdBpiEui/fICksRIPo6LWFMf5vEXovDJKa
	333d75bJna2jXh9vfXK2yzsaRzYS8sTFq64GYYLcXDZTWU60N95oSIOHUtTd8E9r26M10W+Lqc/
	vGAuIrBI9IAsrblCJBFjAEVHNZGqP6xA1fyCwGyNWaM5mjsCAUDLYf0acrKZaCCULrwpPDjf7Bi
	PWB/O+RkJ9QwaY+UUhlLNQSAO83tr4WUg6qFZsDer9yX2hCKLuLl4/ROosSWebz54Dgxm/meAKN
	HC49eiXk1cz0XC0BULypKz8/Mz/kFBjNjQ+GFYylpn4MBgjYhkHKnN0j2cJwIg437VaSF3RtSFV
	3TzBHEMlGEwzo8Ecz/oT9fiq5PJxC8vTkJUbBvZyW+GWG+g3Pe2
X-Received: by 2002:adf:e005:0:10b0:47f:d0fb:ea40 with SMTP id ffacd0b85a97d-47fec532b81mr6611273f8f.21.1785918586889;
        Wed, 05 Aug 2026 01:29:46 -0700 (PDT)
Message-ID: <2a4d839d-44ce-40fb-af7b-5becd878c9fc@suse.com>
Date: Wed, 5 Aug 2026 10:29:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86: reduce dependencies on x86_emulate/x86_emulate.h
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1785918587-FDA6E034-C3C315E6/0/0
X-purgate-type: clean
X-purgate-size: 13038

Split out struct x86_event to an entirely separate header, and move a few
other items describing the architecture to a new x86-types.h. With a few
forward decls of structures and with a fair number of new #include-s in
.c files, the inclusion of x86_emulate.h (and hence
x86_emulate/x86_emulate.h) can be dropped from all header files except
hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The use in drivers/vpci/msix.c is certainly somewhat bogus, but as long as
X86EMUL_OKAY etc are used directly there, that's the way to go. Like done
for IOREQ, some abstraction will be needed here if this file was to be
re-used by non-x86.

--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -305,7 +305,7 @@ $(call cc-option-add,HOSTCFLAGS-x86_64,H
 HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
 
 x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
-                     x86-vendors.h x86-defns.h msr-index.h) \
+                     x86-vendors.h x86-defns.h x86-types.h x86-event.h msr-index.h) \
          $(addprefix $(XEN_ROOT)/tools/include/xen/lib/x86/, \
                      cpu-policy.h cpuid-autogen.h)
 x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h x86_emulate/private.h $(x86.h)
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -38,6 +38,8 @@
 
 #include <xen/asm/msr-index.h>
 #include <xen/asm/x86-defns.h>
+#include <xen/asm/x86-event.h>
+#include <xen/asm/x86-types.h>
 #include <xen/asm/x86-vendors.h>
 
 #include <xen-tools/common-macros.h>
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -37,6 +37,7 @@
 #include <asm/hvm/save.h>
 #include <asm/hvm/vpt.h>
 #include <asm/time.h>
+#include <asm/x86_emulate.h>
 
 #define domain_vpit(x) (&(x)->arch.vpit)
 #define vcpu_vpit(x)   (domain_vpit((x)->domain))
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -11,6 +11,8 @@
 #include <asm/current.h>
 #include <asm/hpet.h>
 #include <asm/mc146818rtc.h>
+#include <asm/x86_emulate.h>
+
 #include <xen/sched.h>
 #include <xen/event.h>
 #include <xen/trace.h>
--- a/xen/arch/x86/hvm/mmio.c
+++ b/xen/arch/x86/hvm/mmio.c
@@ -9,6 +9,7 @@
 #include <xen/mm.h>
 
 #include <asm/p2m.h>
+#include <asm/x86_emulate.h>
 
 static int cf_check subpage_mmio_accept(struct vcpu *v, unsigned long addr)
 {
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -11,6 +11,8 @@
 #include <asm/hvm/io.h>
 #include <asm/hvm/save.h>
 #include <asm/acpi.h> /* for hvm_acpi_power_button prototype */
+#include <asm/x86_emulate.h>
+
 #include <public/hvm/params.h>
 
 /* Slightly more readable port I/O addresses for the registers we intercept */
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -23,12 +23,15 @@
  */
 
 #include <xen/sched.h>
-#include <asm/mc146818rtc.h>
-#include <asm/hvm/vpt.h>
+#include <xen/trace.h>
+
 #include <asm/hvm/io.h>
 #include <asm/hvm/save.h>
+#include <asm/hvm/vpt.h>
 #include <asm/iocap.h>
-#include <xen/trace.h>
+#include <asm/mc146818rtc.h>
+#include <asm/x86_emulate.h>
+
 #include <public/hvm/params.h>
 
 #define USEC_PER_SEC    1000000UL
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -34,6 +34,8 @@
 #include <xen/numa.h>
 #include <xen/paging.h>
 
+#include <asm/x86_emulate.h>
+
 #define VGA_MEM_BASE 0xa0000
 #define VGA_MEM_SIZE 0x20000
 
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -38,6 +38,7 @@
 #include <asm/current.h>
 #include <asm/event.h>
 #include <asm/io_apic.h>
+#include <asm/x86_emulate.h>
 
 /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps. */
 #define IRQ0_SPECIAL_ROUTING 1
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -5,6 +5,8 @@
 
 #include <asm/hvm/save.h>
 #include <asm/hvm/viridian.h>
+#include <asm/x86_emulate.h>
+
 #include <public/hvm/params.h>
 
 int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -18,6 +18,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/p2m.h>
+#include <asm/x86_emulate.h>
 
 static DEFINE_PER_CPU(u64 *, vvmcs_buf);
 
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -33,6 +33,7 @@
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/io.h>
 #include <asm/hvm/save.h>
+#include <asm/x86_emulate.h>
 
 #define vpic_domain(v) (container_of((v), struct domain, \
                                      arch.hvm.vpic[!(v)->is_master]))
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -8,7 +8,8 @@
 #include <asm/e820.h>
 #include <asm/mce.h>
 #include <asm/vpmu.h>
-#include <asm/x86_emulate.h>
+#include <asm/x86-types.h>
+
 #include <public/vcpu.h>
 #include <public/hvm/hvm_info_table.h>
 
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -16,11 +16,13 @@
 #include <asm/current.h>
 #include <asm/hvm/asid.h>
 #include <asm/msr-index.h>
-#include <asm/x86_emulate.h>
+#include <asm/x86-event.h>
+#include <asm/x86-types.h>
 
 struct pirq; /* needed by pi_update_irte */
 struct hvm_hw_cpu;
 struct xen_domctl_createdomain;
+struct x86_event;
 
 #ifdef CONFIG_HVM_FEP
 /* Permit use of the Forced Emulation Prefix in HVM guests */
--- a/xen/arch/x86/include/asm/hvm/ioreq.h
+++ b/xen/arch/x86/include/asm/hvm/ioreq.h
@@ -8,6 +8,8 @@
 #ifndef __ASM_X86_HVM_IOREQ_H__
 #define __ASM_X86_HVM_IOREQ_H__
 
+#include <asm/x86_emulate.h>
+
 /* This correlation must not be altered */
 #define IOREQ_STATUS_HANDLED     X86EMUL_OKAY
 #define IOREQ_STATUS_UNHANDLED   X86EMUL_UNHANDLEABLE
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -14,6 +14,8 @@
 #include <asm/hvm/vmx/vvmx.h>
 #include <asm/hvm/svm-types.h>
 #include <asm/mtrr.h>
+#include <asm/x86-event.h>
+
 #include <public/hvm/ioreq.h>
 
 struct hvm_vcpu_asid {
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -9,6 +9,8 @@
 
 #include <xen/mm.h>
 
+#include <asm/x86-types.h>
+
 extern void vmcs_dump_vcpu(struct vcpu *v);
 extern int vmx_vmcs_init(void);
 int cf_check vmx_cpu_up_prepare(unsigned int cpu);
--- a/xen/arch/x86/include/asm/mce.h
+++ b/xen/arch/x86/include/asm/mce.h
@@ -35,6 +35,7 @@ struct vmce {
 
 struct domain;
 struct vcpu;
+struct hvm_vmce_vcpu;
 
 /* Guest vMCE MSRs virtualization */
 extern void vmce_init_vcpu(struct vcpu *v);
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -8,7 +8,6 @@
 #include <asm/io.h>
 #include <asm/page.h>
 #include <asm/uaccess.h>
-#include <asm/x86_emulate.h>
 
 /*
  * Per-page-frame information.
--- /dev/null
+++ b/xen/arch/x86/include/asm/x86-event.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * x86-event.h
+ *
+ * Helper definitions for event handling, which aren't prescribed by the
+ * architecture itself.
+ */
+
+#ifndef X86_X86_EVENT_H
+#define X86_X86_EVENT_H
+
+#ifdef __XEN__
+# include <xen/types.h>
+#else
+# include <stdint.h>
+#endif
+
+#define X86_EVENT_NO_EC (-1)        /* No error code. */
+
+struct x86_event {
+    int16_t       vector;
+    uint8_t       type;         /* X86_ET_* */
+    uint8_t       insn_len;     /* Instruction length */
+    int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
+    union {
+        unsigned long cr2;         /* #PF */
+        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */
+    };
+};
+
+#endif /* X86_X86_EVENT_H */
--- /dev/null
+++ b/xen/arch/x86/include/asm/x86-types.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * x86-types.h
+ *
+ * Type definitions and basic helpers which are more or less directly
+ * describing aspects of the architecture.
+ */
+
+#ifndef X86_X86_TYPES_H
+#define X86_X86_TYPES_H
+
+#ifdef __XEN__
+# include <xen/types.h>
+#else
+# include <stdint.h>
+#endif
+
+/*
+ * Comprehensive enumeration of x86 segment registers.  Various bits of code
+ * rely on this order (general purpose before system, tr at the beginning of
+ * system).
+ */
+enum x86_segment {
+    /* General purpose.  Matches the SReg3 encoding in opcode/ModRM bytes. */
+    x86_seg_es,
+    x86_seg_cs,
+    x86_seg_ss,
+    x86_seg_ds,
+    x86_seg_fs,
+    x86_seg_gs,
+    /* System: Valid to use for implicit table references. */
+    x86_seg_tr,
+    x86_seg_ldtr,
+    x86_seg_gdtr,
+    x86_seg_idtr,
+    /* No Segment: For (system/normal) accesses which are already linear. */
+    x86_seg_sys,
+    x86_seg_none
+};
+
+static inline bool is_x86_user_segment(enum x86_segment seg)
+{
+    unsigned int idx = seg;
+
+    return idx <= x86_seg_gs;
+}
+static inline bool is_x86_system_segment(enum x86_segment seg)
+{
+    return seg >= x86_seg_tr && seg < x86_seg_none;
+}
+
+/*
+ * Full state of a segment register (visible and hidden portions).
+ * Chosen to match the format of an AMD SVM VMCB.
+ */
+struct segment_register {
+    uint16_t   sel;
+    union {
+        uint16_t attr;
+        struct {
+            uint16_t type:4;
+            uint16_t s:   1;
+            uint16_t dpl: 2;
+            uint16_t p:   1;
+            uint16_t avl: 1;
+            uint16_t l:   1;
+            uint16_t db:  1;
+            uint16_t g:   1;
+            uint16_t pad: 4;
+        };
+    };
+    uint32_t   limit;
+    uint64_t   base;
+};
+
+#endif	/* X86_X86_TYPES_H */
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -22,6 +22,7 @@
 #include <asm/p2m.h>
 #include <asm/pv/domain.h>
 #include <asm/setup.h>
+#include <asm/x86_emulate.h>
 #include <asm/xstate.h>
 
 #include <public/hvm/params.h>
--- a/xen/arch/x86/pv/misc-hypercalls.c
+++ b/xen/arch/x86/pv/misc-hypercalls.c
@@ -12,6 +12,7 @@
 #include <asm/debugreg.h>
 #include <asm/fsgsbase.h>
 #include <asm/traps.h>
+#include <asm/x86_emulate.h>
 
 long do_set_debugreg(int reg, unsigned long value)
 {
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -13,6 +13,11 @@
 
 #include <xen/lib/x86/cpu-policy.h>
 
+#ifdef __XEN__
+# include <asm/x86-event.h>
+# include <asm/x86-types.h>
+#endif
+
 #define MAX_INST_LEN 15
 
 #if defined(__i386__)
@@ -25,77 +30,6 @@
 
 struct x86_emulate_ctxt;
 
-/*
- * Comprehensive enumeration of x86 segment registers.  Various bits of code
- * rely on this order (general purpose before system, tr at the beginning of
- * system).
- */
-enum x86_segment {
-    /* General purpose.  Matches the SReg3 encoding in opcode/ModRM bytes. */
-    x86_seg_es,
-    x86_seg_cs,
-    x86_seg_ss,
-    x86_seg_ds,
-    x86_seg_fs,
-    x86_seg_gs,
-    /* System: Valid to use for implicit table references. */
-    x86_seg_tr,
-    x86_seg_ldtr,
-    x86_seg_gdtr,
-    x86_seg_idtr,
-    /* No Segment: For (system/normal) accesses which are already linear. */
-    x86_seg_sys,
-    x86_seg_none
-};
-
-static inline bool is_x86_user_segment(enum x86_segment seg)
-{
-    unsigned int idx = seg;
-
-    return idx <= x86_seg_gs;
-}
-static inline bool is_x86_system_segment(enum x86_segment seg)
-{
-    return seg >= x86_seg_tr && seg < x86_seg_none;
-}
-
-#define X86_EVENT_NO_EC (-1)        /* No error code. */
-
-struct x86_event {
-    int16_t       vector;
-    uint8_t       type;         /* X86_ET_* */
-    uint8_t       insn_len;     /* Instruction length */
-    int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
-    union {
-        unsigned long cr2;         /* #PF */
-        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */
-    };
-};
-
-/*
- * Full state of a segment register (visible and hidden portions).
- * Chosen to match the format of an AMD SVM VMCB.
- */
-struct segment_register {
-    uint16_t   sel;
-    union {
-        uint16_t attr;
-        struct {
-            uint16_t type:4;
-            uint16_t s:   1;
-            uint16_t dpl: 2;
-            uint16_t p:   1;
-            uint16_t avl: 1;
-            uint16_t l:   1;
-            uint16_t db:  1;
-            uint16_t g:   1;
-            uint16_t pad: 4;
-        };
-    };
-    uint32_t   limit;
-    uint64_t   base;
-};
-
 struct x86_emul_fpu_aux {
     unsigned long ip, dp;
     uint16_t cs, ds;
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -25,6 +25,7 @@
 
 #include <asm/msi.h>
 #include <asm/p2m.h>
+#include <asm/x86_emulate.h>
 
 #define VMSIX_ADDR_IN_RANGE(addr, vpci, nr)                               \
     ((addr) >= vmsix_table_addr(vpci, nr) &&                              \


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:36:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:36:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383010.1626260 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrX77-0007SY-01; Wed, 05 Aug 2026 08:36:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383010.1626260; Wed, 05 Aug 2026 08:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrX76-0007SR-TR; Wed, 05 Aug 2026 08:36:36 +0000
Received: by outflank-mailman (input) for mailman id 1383010;
 Wed, 05 Aug 2026 08:36:35 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrX75-0007SI-Jc
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:36:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrX74-00HNgL-KO
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:36:34 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f611-bab6-0a2a0a5309dd-0a2a450cd29c-2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:36:34 +0200
Received: from [209.85.218.45] (helo=mail-ej1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72f612-f479-0a2a450c0019-d155da2db119-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:36:34 +0200
Received: by mail-ej1-f45.google.com with SMTP id
 a640c23a62f3a-c167aa9500dso116662666b.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:36:34 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2035e23afcsm89067666b.0.2026.08.05.01.36.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:36:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785918994; x=1786523794; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=x9EKI6NPBJG8Y7nbkj7ihhK4/1jMO++H4iDHuFnaf2I=;
        b=fYAkHzayNo91kYj5u5WCG6iINZ8L0MqiTpo+I9Ivu7HxWdAuAujZigeoxZIAceOyOM
         GJmsKTsycPiGiQXZ/y5oXiyAQIz7bpbPnWxB1g2maEcI4Fxb/nu4EKgft567iwkQUVbb
         SFIMMFHUKuMYWUXcQwZtzsJ9ilVWZXW9Lo5zVQZc0OU0PNLjML3dYqpJbXs2WN5nT3OV
         4gkt+B7i4gyRtNi+MUu74sro2QujIh4GTfuJUxwdmIIFBtBNyQ95l8+Lny2numHYsUkP
         LGsZYMzPyuxkgNtqa3oPao3sXgqiO/7WMJg+smBPlWM0MMTwlc1UIRZGYbe6qO2sK7KE
         ydSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785918994; x=1786523794;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=x9EKI6NPBJG8Y7nbkj7ihhK4/1jMO++H4iDHuFnaf2I=;
        b=WEfxiQLnaFuOKvcVhkcvDrQClFs+SEdGWW71IVmkOdqp6Fc1DqIDapU3yQ8P1X321w
         4s74hNxvzWC4l2DR7l1m4D1Ag0KDBgdnHdqbyFogL217X1+3jjdoZ5GJQogUCJbgQFiY
         Dif54AKfeQey+Ur0LhFYP2OqRfu7NhniQ4EdkZ2FuRtLcU2cL+LaKwiixJreGn8fyGiH
         2dbIu5usj3YyMgFljxDs4E3ROWLKloH0jwE4rzlyQA9u9mOxPLiRFXvlrzfZwFkk3Q93
         vEW9qrLoPN5GsSXFO/yYx6AVV3t24ownVOmgMHgDXsun09hq/LsyIT5PkFvlkvxvuAqC
         DQ0w==
X-Forwarded-Encrypted: i=1; AHgh+RqIG0WljcnYr+W72tBdd7t4bs35kuC0auCfIQJeijjNbQp+ikpoHAVWl4YR0lEtoG17kFESqQTqEeY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzNn9jQQjR/5IItKylSvyvuxZgTnud8xiscg/cNl0QmlkF5peqm
	GAYdcWjlsVZqwhISEibMLMQQY41WSaxxWKpHuQIwu0ZkHyCzhLfqPHuMiFJn6THby/o=
X-Gm-Gg: AR+sD12ZS78mO6Pid9a9wmVFuR7qhZDpsp4jBLN6z1Fnr89wA/q3MuTNIVAYow+0z9H
	5foG4wA4aUqQLsTm+yBRRlSiaVzlbFnUQKvVbWj+XNpN/Ufv9wEiMYuDoCUm7MVwJVyr62/8NOG
	/u5MlStNIEBA/KMovifeGaPB/JqwUldK8COHoLuZsGhbdSNvexY0KiQyTEiPpAq/YjilNtei9Km
	uLYnGBsf2O1K71QFDYE5PmaeikhhK2jAClKAD26DJtIEPCr2cJijyx5CaVzk1tdjsKw5nZzf5W2
	C7YZip5WENoP0wnOOwGXoa7oMEaX0aXdg7IvrdGZcECkPtGqIRkLS/zrhsHPIhUKFJkPDR4TULD
	OXwMKw4owlF8iJAb94HSI76MKWbwUsQAS25EGhO1GCd6I7u8kfZAUqly2puBBvvCkeeSZvrs8VZ
	6Ch0TJbaUQOGDXOd/CcT+D1ac8wg0HOLVRe5Yea+ECs8G9T9EwJqjzqeP/Nddj8sXdrn6sPBUWA
	LLdfhMMBuG4V9NIPrLOkOTClNQGg/rWshcb7Keh31WW658Oc9bXIBDPVrrN2p2x0xOtEpw8C/5U
	+4RZZzLkerklJJY=
X-Received: by 2002:a17:907:ea8b:b0:c16:126b:98b4 with SMTP id a640c23a62f3a-c2039c03283mr237087466b.3.1785918993934;
        Wed, 05 Aug 2026 01:36:33 -0700 (PDT)
Message-ID: <15824536-dff6-426d-b54c-6a1f362adaa2@suse.com>
Date: Wed, 5 Aug 2026 10:36:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM
To: Andrew Cooper <andrew.cooper3@citrix.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-3-jgross@suse.com>
 <7179e004-76df-42be-94fd-f314614e65cd@citrix.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <7179e004-76df-42be-94fd-f314614e65cd@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------03hIooiG2e5DB35vNVoqR7Vu"
X-purgate-ID: tlsNG-d25034/1785918994-774D7A5B-045C80CA/0/0
X-purgate-type: clean
X-purgate-size: 8222

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------03hIooiG2e5DB35vNVoqR7Vu
Content-Type: multipart/mixed; boundary="------------dsfviep0ZNxgC3wnR9IF0PBk";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org
Message-ID: <15824536-dff6-426d-b54c-6a1f362adaa2@suse.com>
Subject: Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-3-jgross@suse.com>
 <7179e004-76df-42be-94fd-f314614e65cd@citrix.com>
In-Reply-To: <7179e004-76df-42be-94fd-f314614e65cd@citrix.com>

--------------dsfviep0ZNxgC3wnR9IF0PBk
Content-Type: multipart/mixed; boundary="------------cjd2b7oUonfOwrhy1dlPiUfP"

--------------cjd2b7oUonfOwrhy1dlPiUfP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTA6MjgsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IE9uIDA1LzA4LzIw
MjYgOToyMSBhbSwgSnVlcmdlbiBHcm9zcyB3cm90ZToNCj4+IE9uIHg4NiBDT05GSUdfWEVO
X1BWSFZNIGlzIG5vdyBhIHN5bm9ueW0gb2YgQ09ORklHX1hFTi4NCj4+DQo+PiBJbiBYZW4g
c3BlY2lmaWMgeDg2IGNvZGUgaXQgY2FuIGJlIGp1c3QgZHJvcHBlZCwgaW4gbm9uLVhlbiBz
cGVjaWZpYw0KPj4geDg2IGNvZGUgaXQgY2FuIGJlIHJlcGxhY2VkIHdpdGggQ09ORklHX1hF
Ti4NCj4+DQo+PiBJbiBhcmNoaXRlY3R1cmUgaW5kZXBlbmRlbnQgY29kZSBpdCBpcyB1c2Vk
IG9ubHkgd2hlcmUgQ09ORklHX1hFTiBpcw0KPj4gZGVmaW5lZCwgc28gaXQgY2FuIGJlIHJl
cGxhY2VkIHdpdGggQ09ORklHX1g4NiB0aGVyZS4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5OiBK
dWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQo+Pg0KPj4gZGlmZiAtLWdpdCBhL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2lkdGVudHJ5LmggYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9p
ZHRlbnRyeS5oDQo+PiBpbmRleCAyMGY1NDg3MDI0MDQuLmY0MDBjZmFjNjlhNiAxMDA2NDQN
Cj4+IC0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL2lkdGVudHJ5LmgNCj4+ICsrKyBiL2Fy
Y2gveDg2L2luY2x1ZGUvYXNtL2lkdGVudHJ5LmgNCj4+IEBAIC03NDUsNyArNzQ1LDcgQEAg
REVDTEFSRV9JRFRFTlRSWV9TWVNWRUMoSFlQRVJWX1NUSU1FUjBfVkVDVE9SLAkJc3lzdmVj
X2h5cGVydl9zdGltZXIwKTsNCj4+ICAgREVDTEFSRV9JRFRFTlRSWV9TWVNWRUMoSFlQRVJW
SVNPUl9DQUxMQkFDS19WRUNUT1IsCXN5c3ZlY19hY3JuX2h2X2NhbGxiYWNrKTsNCj4+ICAg
I2VuZGlmDQo+PiAgIA0KPj4gLSNpZmRlZiBDT05GSUdfWEVOX1BWSFZNDQo+PiArI2lmZGVm
IENPTkZJR19YRU4NCj4+ICAgREVDTEFSRV9JRFRFTlRSWV9TWVNWRUMoSFlQRVJWSVNPUl9D
QUxMQkFDS19WRUNUT1IsCXN5c3ZlY194ZW5faHZtX2NhbGxiYWNrKTsNCj4+ICAgI2VuZGlm
DQo+IA0KPiBJJ20gdmVyeSBoYXBweSB0byBzZWUgYSByZWR1Y3Rpb24gaW4gdGhlIG51bWJl
ciBvZiBLY29uZmlnIHN5bWJvbHMgZm9yDQo+IFhlbiAodGhlcmUgYXJlIGRlZmluaXRlbHkg
dG9vIG1hbnkpLCBidXQgdGhpcyBsb29rcyB3b25reS4NCj4gDQo+IE9yIGFyZSB5b3Ugc2F5
aW5nIHRoYXQgdGhlcmUgcmVhbGx5IGlzIG5vIHdheSB0byBidWlsZCBhIFhlbiBQViBndWVz
dA0KPiBleGNsdWRpbmcgdGhlIEhWTS1vbmx5IGJpdHM/DQoNClNlZW1zIHNvLCB5ZXMuDQoN
ClRoaXMgaGFzIGJlZW4gbGlrZSB0aGlzIGZvciBhdCBsZWFzdCBzZXZlcmFsIHllYXJzIG5v
dy4NCg0KV2hhdCB5b3UgY2FuIGRvIGlzIHRvIGNvbmZpZ3VyZSB0aGUga2VybmVsIHRvIGV4
Y2x1ZGUgdGhlIFhlbiBwbGF0Zm9ybSBQQ0kNCmRldmljZSAoQ09ORklHX1hFTl9QVkhWTV9H
VUVTVD1uKS4NCg0KDQpKdWVyZ2VuDQo=
--------------cjd2b7oUonfOwrhy1dlPiUfP
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------cjd2b7oUonfOwrhy1dlPiUfP--

--------------dsfviep0ZNxgC3wnR9IF0PBk--

--------------03hIooiG2e5DB35vNVoqR7Vu
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpy9hEFAwAAAAAACgkQsN6d1ii/Ey+o
lwf/ZILi9GqY0ASMTn4+F5mdqH6HoBgZNN8A+OfdA1+17y9CliPpJyiKtL0udlK3bOKxohVmIfKZ
Q3uWtADSqNY510idPN+fWMd9jpZjBEPmTJsGuArUx+i848GfvSm3A260oIhf2U15Pu7s/BGXjAiO
renbxyOoIRaXJkXnrokmXMfs64bRolirMHBWDyO+sVdmXeM2hze9HJzXg3eDy27YOqcNAj3mZg6H
q/2lTFRIu3P5RouIyhB7KoA7Ct1uqLuaiPL8cGNnxGI4TKrXiOSG4+PHi4xaYBB4BLRZ9GLgamSh
XbOVOZSEJZ0m6en6Pys6Y+uZBPbg1uc4x2gr35dFPw==
=Hyf+
-----END PGP SIGNATURE-----

--------------03hIooiG2e5DB35vNVoqR7Vu--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:37:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:37:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383016.1626269 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrX86-0007z5-7g; Wed, 05 Aug 2026 08:37:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383016.1626269; Wed, 05 Aug 2026 08:37:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrX86-0007yy-5A; Wed, 05 Aug 2026 08:37:38 +0000
Received: by outflank-mailman (input) for mailman id 1383016;
 Wed, 05 Aug 2026 08:37:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrX84-0007xU-1Y
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:37:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrX83-00BHWz-E2
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:37:35 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f647-e002-0a2a0a5209dd-0a2a4502e3b8-34
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:37:35 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f64f-6ca4-0a2a45020019-d155802fbcf7-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:37:35 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so5468145e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:37:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49949fcb0c5sm142089105e9.4.2026.08.05.01.37.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:37:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785919055; x=1786523855; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=paXBUFX35ESCakqZniHvS5VX9ri+1pb6qV9fxpbxAvA=;
        b=WDoPQLN71qNMTw3HQM1k8wrovR2z8Ny6b4chreQid9+xz0q/M9sp7Pf6U5By8jDa5k
         GMbqyj/G2YhlQdN58bXd5G1KrHORRMUqUArEIs2o35vxqvkGDCAriOkhS6qu/1CwOVnc
         8XgmEnXKtzFNoCDQFNfzroBTme1MjLZpx/b8XErpSdDfz5vYfA7o1QVT1lorV+TRf43Q
         TQKDJaW9n8SNljpfekr/BfQmWrgFkDl4ufOe+ErLRFnAmvFSAbJ3ns6pBS7kJlrFm+Of
         6YPwAUtQIzwcyy/bg1NSC47BzZjDCpTyX3ZibIbb/Q22HuL29QIrfsxGsdkwQ5eALzNd
         x6rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785919055; x=1786523855;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=paXBUFX35ESCakqZniHvS5VX9ri+1pb6qV9fxpbxAvA=;
        b=WQOQlklx7bYAMf/FcVQ1phi5uOPUhEKu+iwJhdvQuwgp78FijHcrEqb4f/NvxDD9i8
         L0LovVyoXA9emR2MoGhVijCwiIEWf/yS2qF6lygLgKJHu3mZYU3UEKhFn9jtqF61ixtF
         u1NejSykxXG0o4TnhG7erZeZr2o/SdS+3qNUTSh/oEnq0TuEnGgHR+OjLFQcVjYRIROu
         BuNyvBaBKGtKDJNSvH/m9+R75mW+1bFWac4qu6hKSks39y3Oa/mzftiMUjrwQu4NW+e0
         uBNma9N7rDdvV+HtcNcwmEhhZnCE0yKh/YRMv9dkOuCC2GQH4B9zchK9IBRqW8Fvkebj
         j8hA==
X-Forwarded-Encrypted: i=1; AHgh+RoEKaOzhz0ZO7R5jitVPKpr9lUJ44ghCl/LUJCO11vetP5oyNXX9TGNC9gnFI+bup9v8CFqLxDb9+k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzmobcZagVCtWLCKmGGwU2E5zQ+RDat8GZNOA/ajAGVn3CLcVs5
	u4ko7EriXPW+qziub3887mDCEjKpKFMx+G6TMvCDm6Y2ATSvHRugf+XdTvD+WGHOkA==
X-Gm-Gg: AR+sD10rBDBsElnvtFn/I2Z+UMqVanfa9QcOyqaInTgBTy2jUWVX0q2mBtAyOqGuyVT
	R9PT+V27LsPEqHXCYYqZBf854uwG/Q79m1Vu9ftVKXP8RM8qHibr26C2SWxaRODFN4XVt0qn4PB
	A9DANvxBAfmxhajwMAqxRedfdXTkUnJg/nkH70lnOTg89XZOjK2/hF8apDepGBTF0ulUnfh6b6a
	r9aISAo27iXql8JfJXK7zu9CW/kTNRRo+L3aDKoGPtun6lqcoCYO9+l7mbFTUthiYA4l+vYt572
	sJj0XzAs10LDB6fUyVTpYFdhRdJIdvlrgbCTFWRzwDmMyTnwwgz1cyy6gBwp2gDD06Ils9btu6f
	C4M/G5n+43XV5ivRD7DVgz+gPYiRzxYJ5abGdmFbgadaBUQfx04NEJZGVc0iZ2EwxewqlvX4jfn
	bjsY/36eYeoA6Xf1yyJVLOdDHImZRSUGPdlIeoVYCaQqOtA6vCfaN4S54xsGCza9+XfVLZsr/pg
	2hspXlsHBWOBUsyP8QJMJhkLNDclBzPuq6g08Bh2cZMwHESmL0RZ58rF8V+pwc=
X-Received: by 2002:a05:600c:8b35:b0:493:c634:952 with SMTP id 5b1f17b1804b1-4994e79e668mr52852615e9.7.1785919054873;
        Wed, 05 Aug 2026 01:37:34 -0700 (PDT)
Message-ID: <08441834-6087-4cfe-8d56-ba660564384e@suse.com>
Date: Wed, 5 Aug 2026 10:37:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on
 X86_LOCAL_APIC
To: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-2-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805082137.1214967-2-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1785919055-F38BC2AC-E256C409/0/0
X-purgate-type: clean
X-purgate-size: 406

On 05.08.2026 10:21, Juergen Gross wrote:
> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

I've been noticing this every once in a while, but it never felt quite important
enough to make a patch, sorry.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:40:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:40:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383024.1626280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXAX-0001Io-Li; Wed, 05 Aug 2026 08:40:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383024.1626280; Wed, 05 Aug 2026 08:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXAX-0001Ih-H2; Wed, 05 Aug 2026 08:40:09 +0000
Received: by outflank-mailman (input) for mailman id 1383024;
 Wed, 05 Aug 2026 08:40:08 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXAW-0001Ia-O3
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:40:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXAU-00EDlS-Ud
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:40:06 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f6e4-5cb7-0a2a0a5109dd-0a2a450a8f22-12
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:40:06 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f6e6-f2d2-0a2a450a0019-d155802eddcc-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:40:06 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so6480415e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:40:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994e04c2a1sm73635405e9.14.2026.08.05.01.40.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:40:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785919206; x=1786524006; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=jA5HpDKU3mE94gRzH25Q1Upi+BYpu+RmxlAHFb4abds=;
        b=cyv7L5cS6mKU22GIR2JWZ8UDuGiFX3CaDLNKUZG0zTJ8yjHrD/O7AjKs4GYG89cfKy
         vI8RNjPRqVniu8xpUJAy5HTlejRx0ty4pbcLLhhwCZVZKBEMBYcW17+jwo2R2RhR7f3M
         SCMBwT/gyhfPY4dhZnhv+1tKOc/B1xA1Y3fBhn17DFyqNYneC2ItN9MEHtKfs4UpnUtc
         9UciQhvEke5QJu/V4Ii7CcgN21DJkFUbfrm4twkFhGSOqlBJqsO/CQwm8cX3T3Z/LB7j
         Ufkymgf+eEMkTy3dgHwbPdqFBmkQkYMFNg/Bt6lc1uW3nfeCsWRFiMs38tYC8P6pEdAl
         kPHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785919206; x=1786524006;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=jA5HpDKU3mE94gRzH25Q1Upi+BYpu+RmxlAHFb4abds=;
        b=f7UpKW/5VG7ksQ14FAjuS+6f7NrjR+lnFlSSLIWDYd0j8sWfrKTe+IgwvKMhr9unPQ
         s7IO6xqBW0Z7uMKIjmpG1HQ8VG+CaQLKoJIBzj//ziYDRWUfdYJSf0cah6Dv84BVE8h4
         Tchm2roVgOldKSSxZI7QWF8VvGqAakHxBvZb3EECo0cSrSAoyxt4GsIivnsPMXW76HgN
         wqp7Jb0Khs6Ht+oi4DuG36yT3Sxyw1PuFVGtbt5XRxb75HT2cJI9H3YL5wZ+G0MetX1A
         OSXFgznO1MEQlo3zfFO09UY2FcLkBEPLngZ/f2nGuV9AcrC4xDeryIg4kJ6OwRfTxTKy
         ruTg==
X-Forwarded-Encrypted: i=1; AHgh+Rrj/po9QEjOpHd6WoZvNn1+fLz83rvaR95Ftwtmz0kUbtImpr+wbBpm4CayC5gOiFek0iMF7XkA8/c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+cpvUGWsvmmouwWnnovTLSMi3Cmt1REIobt4j/ZDo6ANqxpAZ
	Rn++WIbL3TM0HUyEuQl4mExj+0VsgYnHRV81CuCvbcWnPgzw43k6jssI194mwZnlbA==
X-Gm-Gg: AR+sD13E5FdnD7EBbHTZd89LDWyFe0p/d5u42jBO/xvkR7mfQnTFA/eu1hVBhMcIms+
	yY4BXM8Wed+smjhZbbbYbkfkDzgPrnxe7Tdf7HW0TQRWez+/h8RY8Eky4XN4AzFi04J+qZRsmmB
	uF3NOAsRh+r/vR8xZZLdIfeEkX/ccOy5Iy5gm/0eF+UqqWAwPFhSFXcUVZYAQG4aPh4Z8NOHsWB
	fXTbUe3J3t7xQxgFp+qL62MVtqXwd7r0LFQvlYMzW7UH+GGl11RyT09vxjUQ3Y1EhByoRmlzD/q
	0J/XjOzQbKudKmWko7XTZbeALPDAelCHN+2bvia3TgJBbI5cYUTr3DjimbY2/edTNESMZGnbbnr
	Oci5X2JNy2NlT1w8ry6g0Yiio3nfGqJVRmqm6R/dGfRIJEZ4B/KHbMlIITOiju/KgfqnLghtcEm
	BOT6OA6BQzPTOmazbHsxWJvtstBGiGJGdW63bnIgniXmWHpK9w+n1wN9o0YzSTSzXZLVWRw0WI+
	t1/8fmmPTOg5t6l+95Qz6kqRiG209NGRCTuIwgVaXX17jcntjrk
X-Received: by 2002:a05:600c:1d0a:b0:495:78af:78e5 with SMTP id 5b1f17b1804b1-4994e70de03mr55446075e9.1.1785919206212;
        Wed, 05 Aug 2026 01:40:06 -0700 (PDT)
Message-ID: <5e7d500e-7403-4a64-8e4d-50f1031716ba@suse.com>
Date: Wed, 5 Aug 2026 10:40:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on
 X86_LOCAL_APIC
From: Jan Beulich <jbeulich@suse.com>
To: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-2-jgross@suse.com>
 <08441834-6087-4cfe-8d56-ba660564384e@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <08441834-6087-4cfe-8d56-ba660564384e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1785919206-4ABD8CFC-B6B09FA4/0/0
X-purgate-type: clean
X-purgate-size: 478

On 05.08.2026 10:37, Jan Beulich wrote:
> On 05.08.2026 10:21, Juergen Gross wrote:
>> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
>> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Hmm, looking at patch 2 I wonder: Isn't it XEN's dependency which wants
dropping? XEN_PV shouldn't require X86_LOCAL_APIC, should it?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:42:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:42:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383033.1626288 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXCp-0001uk-5Z; Wed, 05 Aug 2026 08:42:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383033.1626288; Wed, 05 Aug 2026 08:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXCp-0001ud-2r; Wed, 05 Aug 2026 08:42:31 +0000
Received: by outflank-mailman (input) for mailman id 1383033;
 Wed, 05 Aug 2026 08:42:30 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXCo-0001uX-0I
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:42:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXCn-00BIZw-DI
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:42:29 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f76b-2eae-0a2a0a5409dd-0a2a450ae862-48
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:42:29 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f775-f2d2-0a2a450a0019-d155dd31b8f2-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:42:29 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47362928f65so584672f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:42:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfe5bb9sm7083286f8f.10.2026.08.05.01.42.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:42:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785919349; x=1786524149; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=mHvHXoMiEfHV0d3+ZZnPlHNwbEsyLi1F3w1mF+3Pqnk=;
        b=WsGS3itvdN8PGg1HAxbcRaENlDP2zDhNXFZCh67pqro9Zpq4S+o166H+VdlAT5JVmc
         e269PZ36ide8Fgcg0tUcsZdSv+TlTFzLCFn/So6RAI3Ijn8/lfLp/FPscXZtmFs6tYW1
         2u3DtTYIwpm1p0AkOt2BQBfr44GP+KtOEp89ybFBzNlfw3VtJZN67hOSwgL6A62K9uqK
         +/HGSkrl4J9UiaASAflsQQeE+EqvueOMwpS1dLeL/ha8j/gWbcHwYPMkCyVXiFAVq7wy
         5Jb6vjSYEcEfjivgtZE5L2Ycev9Ce5h7qlO/JbeiWi0I+dXAfAdn+p+Uhq5D0DCxdrcG
         2xBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785919349; x=1786524149;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=mHvHXoMiEfHV0d3+ZZnPlHNwbEsyLi1F3w1mF+3Pqnk=;
        b=WeMK4XG56yVYdseDhm6pM35xPd/B4yqP8ugCSSdHzB8ZVXlwpA6dX3Rdwj/Lzk9+5P
         Qno+MfpDcmost450ChJufiUOy5HhdFxcWl9slRlG9UlTAXJvGuQSonwJ/dRxt3MTnov2
         OLt4njj/a44zK9H5tPdKB1s5Q785el1n/xfNquV/qYTv8og29e/+fj8QzdIO3uR6BfAW
         yh0n3XIjfpy7RhsdTQ7O37aE/k6+P/qEA2SeP2IOXUXo+cU7pH6u5aZqlDRHRcNru+1H
         YU6AKbu6iTLSZSalN8pQ4DVsl7Ue1kauQLtXHQHVgWvVZFJdTLDjmTTY4ThP1+d3nr8e
         5dKQ==
X-Forwarded-Encrypted: i=1; AHgh+Rpd31sxX4hh59ztyDjvS+sZS2QQBfxsOE0V8yWkCY1S01u8oBSBU12uGDn03MaWfplKKhU6YwIp8FU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3cn8ZQ6RMgpczBfDb7muKYUnjJ1k1f2WS6iTHtob1xYiuRah6
	6YVkc6NEsOGHlnLKmkfWhJT3i6kqamyQxAeS610V27CCK3CcAjUqE96YRdGsVdUEyQ==
X-Gm-Gg: AR+sD102sXZ+0OnTLMEn38MTQTbdxyu98gYhTIRPOHlyxJ61cqjMikCLbV75pk2sreH
	xXCLtnw3Cxq204zFg0WudkqBVcuUj557fJNhVffXBeJBJblCUOc/A3ZQ11IGbg5k19vIyvoPni4
	0Dswn2Y3fsM5IWO2id3kVLEPbUN+0icj5wgjVF6FBN7043vWwU1stdQ3w3MHhMUOow5J7hRKhXd
	ZeYyHYjrcCSs+DjMZ78Swl/93LaFa1ygqOLpo7iGQO+SU67BeiHB62j0hI7VSlRkds23hwA98Tr
	QaRgq/33qNX/o3qfQHSW1q+KcKjFwJP4M5jp1BDpQ4CTV+pGKX+qQgXY+RKDX3ogrCqnKvTc9mX
	uao7N7Lj/C6CGRIeaftVGVzlKtzQDZOwE2FpEJWYH0i18vs5OslaO0DZEjWLEgeV0ztCx6bxUnU
	vjqIQXEPnr/+ebgiNRZby7VsDAolXINtxD0xetL1v2821u2x85TuO7rXpBIvLjsllNqavJwxtuH
	ASCkOsIFdwiC7q97qLwHJZ6PAKl/9mPGL8IdsIxjla+zDxIESwU
X-Received: by 2002:a05:6000:2c0d:b0:47f:6f9e:1e82 with SMTP id ffacd0b85a97d-47fec4f11cbmr8645151f8f.9.1785919348735;
        Wed, 05 Aug 2026 01:42:28 -0700 (PDT)
Message-ID: <4ca560cd-c43b-4893-bec6-800a33cd1bb7@suse.com>
Date: Wed, 5 Aug 2026 10:42:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE
To: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-4-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805082137.1214967-4-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1785919349-50ECACFC-25EEF3BC/0/0
X-purgate-type: clean
X-purgate-size: 366

On 05.08.2026 10:21, Juergen Gross wrote:
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -309,12 +309,6 @@ config XEN_EFI
>  	def_bool y
>  	depends on (ARM || ARM64 || X86_64) && EFI
>  
> -config XEN_AUTO_XLATE
> -	def_bool y
> -	depends on ARM || ARM64 || X86

Yet is/was X86 correct here? Shouldn't that exclude PV-only configs?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:43:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:43:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383039.1626298 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXDi-0002Mp-GE; Wed, 05 Aug 2026 08:43:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383039.1626298; Wed, 05 Aug 2026 08:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXDi-0002Mi-Ay; Wed, 05 Aug 2026 08:43:26 +0000
Received: by outflank-mailman (input) for mailman id 1383039;
 Wed, 05 Aug 2026 08:43:24 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrXDg-0002MN-Dx
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:43:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXDf-008yvM-Qv
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:43:23 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72f7a8-5cb7-0a2a0a5109dd-0a2a450a81c8-4
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:43:23 +0200
Received: from [52.101.48.69]
 (helo=MW6PR02CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a72f7a9-f2d2-0a2a450a0019-3465304536bf-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:43:23 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SAWPR03MB989599.namprd03.prod.outlook.com (2603:10b6:806:55c::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Wed, 5 Aug
 2026 08:43:19 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Wed, 5 Aug 2026
 08:43:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EvVsttTWUj647XbRZLCHNglDPkLrMD2EzpTCINOJ7HDD0wkdBsIrdZL4TT/ogCUKnp7oqtL4mhX3YS5HpCH9JGq0+eYDxnJkIbqCYBfxbWZ78AZsUEegLOeWc3c9JEqtk553iJWAdYnKsfWcLahlLW7Xz+E0p02ve1ThdvutI6W+G9dPdAwhdoUdv+d1eTHKeo7GcLNLVnk4ZtP7L680yr8KNUPg1pr32sZSkIUppKzX4/zlPDRPUNr4imyJ+2E/Mq9NKKgqTckWx6dA9M+6mNUfPWMWgpn6bU1PZDt1olk+qWAzcdKq198EwB84wxlkY5ZzSxyNfaOWTmGO6YgBYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=j/RvCbaRfhs5kTs2/OCvfUueUwM9lcgQflO749DQY4Q=;
 b=cjY5nTsu4OBFZRuRIeORPXYKet3ZhKPcJsFn6or8Vhojn05iRGpTU2p7KMFra1xClCXqEvuPAmyIwL1OViu7qb8xmX0xQrrUZaD4GhlZjUAJQi0oHWwAFLthJTez1pvJ4cK5b+aQNlG7CZ4SvjNHRMokrNarIraX0f2ZaBC40DLLhJ12pQ5KKW0iyZlx+zoX3xTI1kHceFYzWxbdewg7XB/5XI/FSz86t3I3lKxlIy9f5zxgo9dzqcqAN+SExstZXI4LzyeusKlz2hkv0B9JekAG5QwpaUdrM8jlTnQST3OySNLMlvwwuxuq4ipXnEEHP8b4g5GYDO5SwNpPykyEyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=j/RvCbaRfhs5kTs2/OCvfUueUwM9lcgQflO749DQY4Q=;
 b=sHR/ZhOMgnkuV0u4iAjwUW/j+xDmFEg0s3MVxRYOOOOnQsKd4KPxwll6i0ZbSD60YTHlMM3rCGHGRvtkvdavq3giPsWcADN0qhPIbIJcl1tX63QTuO32J64kCQ2laUpnt8nATmtYk6WwWU2zoGGJUz0bOW9sUZud490XA0L9/0o=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <cf26aa7d-2d67-4328-b441-a1c9b7bcd925@citrix.com>
Date: Wed, 5 Aug 2026 09:43:15 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on
 X86_LOCAL_APIC
To: Jan Beulich <jbeulich@suse.com>, Juergen Gross <jgross@suse.com>
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-2-jgross@suse.com>
 <08441834-6087-4cfe-8d56-ba660564384e@suse.com>
 <5e7d500e-7403-4a64-8e4d-50f1031716ba@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <5e7d500e-7403-4a64-8e4d-50f1031716ba@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0180.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18a::23) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SAWPR03MB989599:EE_
X-MS-Office365-Filtering-Correlation-Id: 22eff28a-ad6d-4997-c5d1-08def2cd998b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|7416014|366016|376014|1800799024|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	soc8V89rktikwsKPTbEUOLSSI/WTVsJGX8KJcQzxEEbrJqBWhPPH9rL5H6BSL1+HxNw2CLAANoFcLgFYZi17Px4jHaBDNTIFjNHo5dgtFBZVbHMDkKWkGTu/HOzodRg6s71DeJsc5/UTS9Vuxozjgz9FZZ+K0yQlWS5wzuRuagsz42RtuODl0JSD8XCWXx5J06DxAgeTLQbFrhsYKT5zrWIvyGLJdoUcW2QXs4rZy/V2K0XIfq3jJm7sPhHKoXxpPk5Az33uuK2Icy/vN6faiAkQeknyBwKI0sE2x9sS999CrF92vsZl5w3V+/zcA6k2jY+YL3uqEBwh1rqUl4auSI67tbmg40o7uLnjDQGTtG8iiUXgJZMWdoOPcuZqv9fw09N+IDn8wPBUqR78CpOdwtiEXg/bNoPqPuPODrGp3SNFtYsOJ4UMwzO5ea5yrEReHn2acwtdRJU7FZY55kpVYAl48KNg+3yIGYYrkvksyV3ugLORfC56toLhARllWR92hmRp7dPNOKEFMaKKpC52ihS56VoughO1aNqfQ62CXe0K28EqwFWGxeiYkX331WoqVrfXG34X9Bz/swtbm71ov1WYcR2G7HBEWHOK4JGfhfcfThmER/f3pT53m5OzlE/TZyMqESJJp9StafEeknNodg3OwopD05K9MMPaETz6B4U=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(366016)(376014)(1800799024)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MXRQZXcrRFlDdWE4TXlOT1I2dTk0SGdBVTdrclFlREJmODQzSjRHUnJJNStR?=
 =?utf-8?B?S0YwUnpXRmdGWU5uTkVjZXB1MEkva3VTcXdhNSt2Wm5JcDlGVDUyN00vUUM2?=
 =?utf-8?B?c2V1ZVpTeVVCdEM0SlgyM1NvQXNmOU1IUXJsNTh3Q1FVSUx2YUlENEpNb2Jm?=
 =?utf-8?B?SG53bm9ONmtHVDdDQUwrdndYZjdWdlhZS3F0UlRkSFpwaWUrWkQ5cjdwL3lG?=
 =?utf-8?B?L3E4ZzhHT3p4VE9vaXl6T1lobnRndlVTOTQ0dWlzU0xhQmlrb1pFWUk0SWpy?=
 =?utf-8?B?VzdRT2hnZkxNVW5SUGozclcvdzNFWnhQZTFDZ3JvdG1yZ3NnMCtLN1JDTjRy?=
 =?utf-8?B?QVBFQlc0clF2WHJOaTIyczYrVVAxSjA0T25EWm9vWWNMSkFhU0Z3eFRlUDY5?=
 =?utf-8?B?M1lDQy9TYjV6R01hc2NScmRvbEtBSzJ3TVNjK3RCSS9mT2dRcCtXN3B1c1dJ?=
 =?utf-8?B?QVh0MGJISWl1TXhId1hvdUpXNmJkYkVkaE9OMW1JLzdGUHBJT2ZtRGJENnFi?=
 =?utf-8?B?YjVoQVpGbVMwaDYyNmtOMTk2LzQyR3R2cmk1bzRydDZ3bmthdGlBTCtLOVdH?=
 =?utf-8?B?WVErelRvVWRqd21nbC96bnEvZENGNVhkTXBCYzBzZGNyaVVueHlsbHJ3RXhQ?=
 =?utf-8?B?b2FyWEpMd1NqdTY2bFdoeUZOT2JJSG13TzRWSFZPenBvWkU4WDZidURyeXZy?=
 =?utf-8?B?bFJKV0VaRktSU2d1dFlLODJNT0FrZDdJVkNnckZaUHRneHgweWd2NlNqeTUy?=
 =?utf-8?B?OTZOZ2o4UDJaUWI0R0xLYThJdU5LN2ZDM3lSQnJoeVJXOWRuNEx0YkdLSmYx?=
 =?utf-8?B?Y2RrdUF3OGlnb05ZN3pLS1BrSGU3K2x3bXAyVWtBbk15SktlNS93eWhvenpi?=
 =?utf-8?B?dGl0NVBDVzRCTnI3SHRJNk5uVTNheVZzb2pEa3ZQVFlXMDF2OU9hV1FsOFNR?=
 =?utf-8?B?U1dLNExPZk45ZE5NQlFZOURRSFdGbGcwalNlaG1lUytkaEk3RU5KVFlXNkNV?=
 =?utf-8?B?Zm9OOHFlQ05ya1lpd1c5a3hMMGJBci9mcGtyL1RSRjVPd1BWWmNOS3VkUHdp?=
 =?utf-8?B?Y0liUUI4WFFoV0Y3bW9QOVhEUU5jSWptRW55ZGlDRnE5cktFUkNkWHpWWEZQ?=
 =?utf-8?B?RzNLa0NiTjFCSGdZSUh2d1lzak00UGJBYkZ0MXJHNW42a29UckxRUUs4bFdo?=
 =?utf-8?B?cGJCb0MxVVZFVW5BOXJ6QmsrK1Q0N3Q5cGY2TWE0UFFPTHRISDF2cTVhWkhS?=
 =?utf-8?B?am52Z1JtRDdzd3NESC8yVHVpbEhzZnBtMXZaeXVMZ1NINVBIMnovcXowVCtq?=
 =?utf-8?B?b2tkV0FXV2loUXNNRjNCNGVlZ0ZLb0JNR0ozMjcrUXZNL25LV3dVTEExYXJU?=
 =?utf-8?B?dmNzc1loTlhRT0FGMHFPbmhLL0xubTJoQytseElzb1NRaWt1WGJ5TDl6bnIy?=
 =?utf-8?B?U1pvWUNFaHZ2cW1tOEFEbVdlTUdWanUrRnFaTjNlWVRpNisxejJIN2NwYU1I?=
 =?utf-8?B?Y0QyL1Exck1GaDZWT0o2TEJzTDdnbzV3YlBFV09xcnBYQnErbTZTVGNPaVZu?=
 =?utf-8?B?RUJFU3NSNXdPbG8vdktOUzF1YnNHRlA2TWhCOURRK3pEQ1VUdC9YOWVRMmw3?=
 =?utf-8?B?K1NtaVF4VmoyMS9SbTlvdGtSZytiTDJmVUQ3NEJBMHRwRUFZOGRZM3dQdFlo?=
 =?utf-8?B?MThaUGgvckp4eVlDd3J3UUw1cXp6Q01NOTFxbkppejJvcWV6MVJ1VVkzb0xq?=
 =?utf-8?B?bmJzdGlVdkdWWWtsUkdhS3ZoaWxmY3dHNGRZT3FlcmczR2E1SDEvenJEd1Rk?=
 =?utf-8?B?aTNVZ3dSd255STVwVmlVYlpxY1ZMc2N6ejZBWjRZT2szQmw3WjJ5N1p0WTF3?=
 =?utf-8?B?dnFHMzNEd0lQUk5wSitsSmlmd0l2UTNEM25Ob1VUdlZNdjlhbWpGaUZQSC80?=
 =?utf-8?B?UjdHbDlVNTJHdTh1TitMZFVLTlNsUEFmRkNub3JUQklEaVI4Vk1ZYnpzZXdO?=
 =?utf-8?B?aHYzZ3hyNVhGdUFYMHlHbERESW1qSWNYV3pyTUo5MCtoWnM4Z3ZvUUFtbncz?=
 =?utf-8?B?bEZPZjdsOFRsM25PUzBMR0tMSzlTVHpSOWtOaHpvN1FhdzNMbUZLZmdtSHVK?=
 =?utf-8?B?TzZnV3o4NEYyZTYybmdiOEY3STg1eHhWSVl1UDNVZWhGY1JBT2J2SGpXUUxV?=
 =?utf-8?B?UmV2clhUUTB1MUpoSEVPQ0VlWHg1V0J5bWRWeFNtcWxHTjFlY0podjkzWC9E?=
 =?utf-8?B?R0NKejZTSit1d3pZOGt1M0VTQ1hNYzh6aDZYVDBpckJzQnhXMTg3cXlWVGpo?=
 =?utf-8?B?S0xicGpBamJuV3RLbEFGTHFsZllIVm1SdFA4MTF5V21KWVI0OC9LR2hxQ1RB?=
 =?utf-8?Q?jx5IffTO09Hbljwk=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22eff28a-ad6d-4997-c5d1-08def2cd998b
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 08:43:19.3057
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oDeE5ScGhUy9wWrt/c2uWei42siiV+NNsyNpZyYlABt34lerARRDwSQwbigAsItyeTG5lCAdfiEAvnaa+itu0rIiWIRuE47wTRx0sZcZJEg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAWPR03MB989599
X-purgate-ID: tlsNG-4011c0/1785919403-4BED2CFC-F23D01E6/0/0
X-purgate-type: clean
X-purgate-size: 765

On 05/08/2026 9:40 am, Jan Beulich wrote:
> On 05.08.2026 10:37, Jan Beulich wrote:
>> On 05.08.2026 10:21, Juergen Gross wrote:
>>> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
>>> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Hmm, looking at patch 2 I wonder: Isn't it XEN's dependency which wants
> dropping? XEN_PV shouldn't require X86_LOCAL_APIC, should it?

In Linux terms, XEN_PV does need X86_LOCAL_APIC.

While the PV guest doesn't have an APIC directly, other areas (parsing
the ACPI tables, configuring device interrupts) require Linux to think
it's on a normal APIC-like system.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:44:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383046.1626305 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXER-0002uR-Le; Wed, 05 Aug 2026 08:44:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383046.1626305; Wed, 05 Aug 2026 08:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXER-0002uK-Ik; Wed, 05 Aug 2026 08:44:11 +0000
Received: by outflank-mailman (input) for mailman id 1383046;
 Wed, 05 Aug 2026 08:44:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXEP-0002t1-So
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:44:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXEP-008z9Q-9e
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:44:09 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f7d1-bab6-0a2a0a5309dd-0a2a4504de10-14
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:44:09 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f7d6-b57f-0a2a45040019-d1558030dc52-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:44:06 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4954afac04bso7361125e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:44:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a0f7bf4sm162465895e9.11.2026.08.05.01.44.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:44:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785919446; x=1786524246; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=P9r862YZOyOGjhCsS+AtVypyNoqeUq1wkQoy8TnKSRE=;
        b=cklmco0fPAljN8a1UZG4uJl68sB3k507e+FWImXeGmxBn00zEohwt0nfgtHamxesHE
         ojeWDsWjOsH2V3+dpF/F3aWF+CmGGFvcbcjpWULutI+EbyxWramQZV3AJGfeaK4litl7
         AunN0+iD1g3M7l1Gl2Men4Jzzuc9uQ/YSigthBI+sxxSND0cC0hWZ9ay3UACCe/ClOnS
         Lz2Ao2KtHcSnfaN1lXYWN5t8o0ZqWRLEtDfvxpappn/hhrABDK1/8iJcPUaCMlpmzoPb
         9DA7AZhvIAmLLClf/62k657Z6aZgXtVim+jJTxX3Ml1yMzTathfpXFF4eER6Svaot7OK
         8Rdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785919446; x=1786524246;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=P9r862YZOyOGjhCsS+AtVypyNoqeUq1wkQoy8TnKSRE=;
        b=a2O7edOEJRXOH8YEglCJ3513Shs9Nrp7u56gbCY3G+dfx19NRZUGgd9t2BD3Ak1RF1
         ZTtKyKtojX4xPAUxAwfDPXQTbdp+TprKomgjy48Ng4RzztJDioi2KLvBgVkNFUG5RajH
         gr/WvgyPV/i5DTKIR3tGbIGQMaO57qAVLSGsFPReC8IcKmJ3rJG825PZbxe2E3vuYXg6
         vaoR0yWZ/ezaXCdjXVInaqmBC2ChYJOSXl0MWewnJM2TC+aNni8UePeB1z3I993rmUa8
         umD2Gc+0Ab3ll7rgnixmbZzKfMZjP0XmeT+/JE/7Eoir3KyUU6EBulVfU3ksqyAe6BQY
         R1Lg==
X-Forwarded-Encrypted: i=1; AHgh+RrpwKvD3UleDzIZHCR6TN7xu57VJMdU6c5gzLWbrwEpPbjJOM0zBuU66FZNspF+uKBNo5zXHX8uMB8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3eDx8CtSdMaDs5bHYfLNO0MEGvsaPD3XQq9K8l1OfCjU1ssML
	hioUube77aHur8g0hGhOYI6lDzozeFnDy0lOWcDoZinuosJ/6IeGtgBW3c/1qiO4Ew==
X-Gm-Gg: AR+sD11kY2KJDiT161SUSF32iDuLEaorvbbDw/YDn7ZO17KokZs5f40tzx0/CbDhXcM
	WQTJ7iQGFCSaetZWUbiqE/zpThGEiQww9w1jqE24xB/K26eO558o2o6CUJuFntQBbKae6YgCjib
	9EDH+D0h+m67wbExW2ZNgvjV+LJ71zwgDUH8+PJeVI4hPffa6KSFEl+JorwCLxBX8qtjiU+KYKm
	epl5HfM3gbmyN1lfStMNXKRs5tNqjAHSCKP1UIqU3u7KU8hDvldV+wSbW9Kp1VHdKwrQf/2eulZ
	mtIRKrCYhviYp7SMTsqQrr7fo7x3edE9PEE4o0WF5NVe7ukNHwE5TL05+4DGSIvhukSOXthGPF7
	K7K1+5JTvYk1Dhr1bJIJEft9RSitlxZPXwsmtpfPJQ9Asq4vUcTh8/NyX0+NksMaypor2Nt2QQf
	+7z50QIiwAVhFF5eblqPh6+KrKLL/nL2VlQvceNrxYgXgcfYijTC9+ltdWf0XNX2T9U2koINSNv
	bIyGYYoA5Ts0y0bWlSoIaEYWYzhopSjMkHSIT+2RmI0Ja+16yxl
X-Received: by 2002:a05:600c:8b23:b0:495:4d00:2fc0 with SMTP id 5b1f17b1804b1-4994e7bb12dmr49451095e9.12.1785919446376;
        Wed, 05 Aug 2026 01:44:06 -0700 (PDT)
Message-ID: <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
Date: Wed, 5 Aug 2026 10:44:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
To: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805082137.1214967-5-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1785919446-C1ED6B50-E9AD63C3/0/0
X-purgate-type: clean
X-purgate-size: 476

On 05.08.2026 10:21, Juergen Gross wrote:
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>  obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>  
>  obj-$(CONFIG_SMP)		+= smp.o
> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>  obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o

Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
need building.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:47:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:47:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383053.1626314 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXH9-0003Ye-1Z; Wed, 05 Aug 2026 08:46:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383053.1626314; Wed, 05 Aug 2026 08:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXH8-0003YX-VJ; Wed, 05 Aug 2026 08:46:58 +0000
Received: by outflank-mailman (input) for mailman id 1383053;
 Wed, 05 Aug 2026 08:46:58 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXH7-0003YR-Vo
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:46:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXH7-006QlE-8t
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:46:57 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f877-bab6-0a2a0a5309dd-0a2a45038e04-48
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:46:57 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72f880-fae8-0a2a45030019-d155dd2ea416-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:46:56 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47fde295992so578161f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:46:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfe5e85sm6963759f8f.14.2026.08.05.01.46.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:46:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785919616; x=1786524416; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=9K2nghcFTEoUumQc+qv00dhERm+3wC5Gi0zPR+wU7p0=;
        b=RdP+6138DK3Y+tiUYh9roc/kYhroYANfewd/5RapZtnqVVZ8UQilgZZGMtbZrmTkG7
         8o263Ed2iZqsDlBksFc5e/4vib8OpX7lSsvI2ZMeTgp2G94yJO/n+lVglE8PC14tlY8j
         u4ryZDyJZemW3daz7ZUjrOa2I2vvro09daqqgYTCkj9cZ++/UjvjW7qe2Yuz8gOQcJEj
         g+S+BH99QFGDgtu29m2TBYCcNv0cuPn0DiUYFHLM1RJK6tSi+SENPEQpBJMiBcevbc4I
         KZC1qTzopI2S+0daQKIdjGNOE/ptwBMYVFGnqqUbpty/7V05BK/k3rCi4Tfo/3dKWTL+
         Rn/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785919616; x=1786524416;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=9K2nghcFTEoUumQc+qv00dhERm+3wC5Gi0zPR+wU7p0=;
        b=A2LgVD2C351H1SHCMW89EiDNRvOr5Q59Y4xVzzL4y8JjKSYzRU2Fwb/Tj3bMVxlblz
         4YUYoW4iy+F6uBYVb1+KfgA2W48OvdRqwmOIalSdjvQY9NI2CjvcTl1jP6v15mBePTi/
         bCfG2EYHLcZWNTDyvAk3bwGYq/AZpdOk8ImfvjGCAIH1yZTyRlEVvjns59TOnW4RV/Fb
         2ZtIaF7jJp8Q071eixCtrWWbd4fW1b88i38fzUR3a3M9Cx3IZjOeMsWplKVKV29hQLoS
         ph+bhLiLNjd0trM+Z9/MX5Ba36fYFG/cfTcHAWABf6lINOLc0PsQX53TlQs2L4U5wiJz
         UwgA==
X-Forwarded-Encrypted: i=1; AHgh+Ro2RWAwbpThX3q+Exye57n2en8yHdNhiC8auLzv6sZDQBdFN4MoDfwrozQspRwpRC1mBDG9THu0wMY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfGLpmMwhe6qsnAKasTob7HUC2Jy2niXkiW5ulFaoKVlOATDXD
	xDKTFyfkowilR+d3hKhEK0GAJU84FR+V473zRBshdl0h54u5n/NukYqVtG2wXIV5jQ==
X-Gm-Gg: AR+sD11s65pZln/MaSSCjWHUmwADzJcZ8rFL2ZOtSuaxFp1I7nvu0HpJDZHWQMy4ULi
	aAj86Nrc9jOmij3+n62dP8EDTLh+pM1+VW2qcUtGKl64L8c/w+dj3qVT1KaIXW0Q3CDXfb1MrYb
	W6zGWygGtQJI7Tny4pw3SAYxIGNAjlwVLFwz6/H4+LhXc0Vhgvur0JaSZBKhnxBlzP9zaBTcfsK
	+WozO8Zqgdxjj4TDqmThlmBXQPP08mcXrOEjcJtpJzP4eYqA6fBOpu7ax5MF4xGkZLNTOWgvljk
	CtUJO6F+Jq9bsUDrYXU+pCFKfRxLBD1rigWw2kDJd5GUC/yXE0ZPGtzegA0IK9VbqCmqQqbWzsX
	2iHkaXWjA1tmIBxDyK6mcFErpYhUSfROvTIAsrqIJdkAdY0aPy7XlEE6dkF//kWY/0x4rkNDyDV
	06Mys9zPA0LBa497MIY3EwS8/FicSW/Ex7Hpfq7nu5hwWxipqy17v8cQ/m/++AGhQJWA1NZ+TPa
	QkkrgdBVSBboAS6muMrTWftGsylYPPe3VCFGeCLgd9CjfIPZaAyjOKIahe9zsy1
X-Received: by 2002:a05:6000:2282:b0:47f:9158:5924 with SMTP id ffacd0b85a97d-47fec517023mr7487875f8f.9.1785919616177;
        Wed, 05 Aug 2026 01:46:56 -0700 (PDT)
Message-ID: <ffbe1886-553c-499d-bbbc-fa239b671850@suse.com>
Date: Wed, 5 Aug 2026 10:46:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] x86/alternatives: Rework get_ideal_nops()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <20250522150015.555492-3-andrew.cooper3@citrix.com>
 <20260805075303.23105-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805075303.23105-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1785919616-776F34E9-7F2E92D1/0/0
X-purgate-type: clean
X-purgate-size: 480

On 05.08.2026 09:53, Andrew Cooper wrote:
> The {k8,p6}_nops[] arrays are both 80-byte structures indexing 45-byte
> structures.  Furthermore, perhaps unusually for C, the source layout is an
> obvious hint about the triangular nature of the structure.
> 
> Therefore, we can replace the pointer chase with some simple arithmetic.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:47:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:47:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383054.1626325 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXHH-0003oI-Fd; Wed, 05 Aug 2026 08:47:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383054.1626325; Wed, 05 Aug 2026 08:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXHH-0003o8-AX; Wed, 05 Aug 2026 08:47:07 +0000
Received: by outflank-mailman (input) for mailman id 1383054;
 Wed, 05 Aug 2026 08:47:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wrXHG-0003nU-5P
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:47:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wrXHE-006HEQ-0g;
 Wed, 05 Aug 2026 08:47:03 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wrXHD-00EwxE-1o;
 Wed, 05 Aug 2026 08:47:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=iNMWi0XtRBKOmYDv/Tp647cKGq+rA0jxZoCfmdFSxzg=; b=NJUzcebrvZ2GAaVE3sdR/cw3jG
	amx6gjPYPB8x1GFQdlD6blgf30WK4vhrJM7wwnk9y++g/YjLcVLOuMrlUnaqjiZjVE17Kd1+Aep8Y
	KS8UBxDvfc9Pm+N3pfcd+mVXJJbii6bb5cFfURvvdGSzF54f+eZppiv9E8Bx3iPVmaUE=;
Date: Wed, 5 Aug 2026 10:43:29 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Matthias Goergens <matthias.goergens@gmail.com>
Cc: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	Yannick Martin <yannick.martin@okazoo.eu>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH] x86/xen: fix init of balloon stats for PV guests with
 memory != maxmem
Message-ID: <anL3sbvftMybnwBG@macbook.local>
References: <20260730143548.39320-1-roger@xenproject.org>
 <20260805044607.2564210-1-matthias.goergens@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20260805044607.2564210-1-matthias.goergens@gmail.com>

On Wed, Aug 05, 2026 at 12:46:07PM +0800, Matthias Goergens wrote:
> Hi Roger,
> 
> thanks for picking this up, and Juergen, thanks for the quick review.  Two
> things I believe are still worth addressing; the Fixes: tag can of course
> also be fixed up on application.
> 
> I think the Fixes: tag should point to 0949c646d646 ("Partial revert
> \"x86/xen: fix balloon target initialization for PVH dom0\"").  Commit
> 87af633689ce changed the initial-page calculation and the extra-region
> subtraction together, so those two operations were coherent: the PV initial
> count then came from get_num_physpages(), which includes the extra regions.
> 0949c646d646 restored the PV start_info->nr_pages calculation, which
> excludes the extra regions, but retained the subtraction.

I've got the same doubts about which commit to reference in the Fixes
tag.  Here is my reasoning for picking the original bogus commit, and
not the subsequent attempt at fixing it:

Even if 87af633689ce was coherent in the usage of initial pages vs
extra regions, it was still wrong, and that's why it was (partially)
reverted.  I assume that anyone who picks the change in this patch
will also have picked 0949c646d646, otherwise they have a problem with
how they do backports.

> Its 6.12.y
> backport is also the reporter's identified regression, first seen in
> 6.12.75.  Applying this patch in a tree that has 87af633689ce but not
> 0949c646d646 (for example a 6.17-based distro tree) would double-account
> the extra region.

Why would someone apply this fix but not the preceding one?  It makes
no sense, you either pick backports consistently, or need to be very
careful at knowing what to pick (and assume that sometimes stuff will
break).

> This likely also wants Cc: stable@vger.kernel.org, since
> both 6.12.y and 6.18.y carry the 0949c646d646 regression.
> 
> Separately, and not something this patch introduces: PVH dom0 has the same
> shape of problem on mainline since b13cd24c15d7.  A successful
> XENMEM_current_reservation supplies current_pages for both PV and PVH dom0,
> and that count excludes the unpopulated xen_extra_mem, so the
> xen_pv_domain()-only branch leaves PVH dom0 subtracting those pages again
> (-ERANGE, or a silently wrong target, when CONFIG_XEN_UNPOPULATED_ALLOC=n
> leaves the regions for the balloon driver).  I am happy to pursue that as
> its own thread once this one lands.

Hm, I see.  Running a PVH dom0 without CONFIG_XEN_UNPOPULATED_ALLOC
will be a very bad idea anyway, as the kernel would likely end up
triggering an OOM as all pages would be ballooned out to create
grant/foreign mappings.

> Would it be safer to pass balloon_add_regions() an explicit indication of
> whether the chosen initial-page count includes the extra physmap regions?
> That would cover PV, PVH dom0, and the XENMEM_current_reservation fallback
> without deriving the accounting rule solely from the domain type.  On
> hypercall failure PVH dom0 falls back to get_num_physpages(), which
> includes the extra regions, so keying the accounting on the source of the
> count keeps the fallback correct as well.

Possibly, this has grown organically to accommodate for the
lack of proper interface to do memory balloon accounting.

I will send v2 attempting to take care of the PVH corner case and the
error fallback.  It's IMO best if we can get all the related fixes
here in a single patch to backport.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:56:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:56:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383074.1626333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXPq-0006JX-5g; Wed, 05 Aug 2026 08:55:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383074.1626333; Wed, 05 Aug 2026 08:55:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXPq-0006JQ-2Q; Wed, 05 Aug 2026 08:55:58 +0000
Received: by outflank-mailman (input) for mailman id 1383074;
 Wed, 05 Aug 2026 08:55:56 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrXPo-0006JJ-L9
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:55:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXPo-00BKzZ-1r
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:55:56 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72fa83-bab6-0a2a0a5309dd-0a2a4506cf2e-44
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:55:55 +0200
Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72fa9b-195a-0a2a45060019-d155d030bd83-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:55:55 +0200
Received: by mail-ed1-f48.google.com with SMTP id
 4fb4d7f45d1cf-6983f20a8bfso1163729a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:55:55 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a166335dfbsm1118557a12.14.2026.08.05.01.55.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:55:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785920155; x=1786524955; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Ymuh0DcPl2Ots+UHLDeP+fBlqnU5QkdY5IPw7VnqIzk=;
        b=ZJRagDwMfDjEig5odpzlSC2iUk7DCuJihQLqODAvkSPcUZ3zw78qo7p6pYLAl2t/y7
         kW6dt1edRcRaKRpxbOOWw9hMYf32I/qxjDmgayDxhXtNfEi/+qhbIIptd4AR5t6Rv/a+
         FdJegkC7nz9KfSfPzNF7qTiUKdvaOCFZbO3WieIFOlzNAvUGzIEVYmL35RNmri3xhYOA
         oo+eS/3Qz5q2GMy/Z5Kei7PkunJZ1W7f3I1Hk5bYMsUDijjW1xbXCrgEiqOsInhlgA1Z
         tO4Mey+oZ8f0PeUKYC5+wwBo4EJ4/FlmgCsR5I+odaV60wmRMVEBn0oRiYpZRkcnf3i4
         438w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785920155; x=1786524955;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Ymuh0DcPl2Ots+UHLDeP+fBlqnU5QkdY5IPw7VnqIzk=;
        b=kGV2TKQdGkj3KC5lnyntRSVlt4YbyJ3PlV34k4enHNDyNilk3E7oq9cg2RFCeWQWmk
         RXFNGMli2eB61RrUKOjIr1SG9NoxZ/IBDo/ftnFMYdl1xq7iO+IJZj3jJcdPMK12p86D
         4SxongwG6fe6ayWmKYHRSmxVeSX28tFQMEJSKL1w2rqeYU5zgV871FgMv8tFb327ZBCp
         e/61vB3Obw6Jf6sYVrlWwj/GpqDZmMZ1saY/a3vuSj7u5Vqf/cGJOXDL3wj/siyfudoh
         ITWTOqrFyHz3eYlRbssHh3HU7dWA1QUb39iVC23L24RZZIUgzHvktGza9yCh6EV7W6ab
         EgNw==
X-Forwarded-Encrypted: i=1; AHgh+RovcqL1L1YCrHs7l3qYVP0h4t6AVmWFd64rBRnTx2x2xs2GeUZSqmXvjdOeX8UWtc6Mc4C9Cfk1xK8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGSnXa5ZeLRt8MjLURXGyh5yFuilA96O5WZMG9gPiQrY8mpGxo
	GoINcNIQsxf0kchCkP+adFsdL6LTytoZMrFR6s9LizvF5utfVI6OBLDCv/LhwM5WKDE=
X-Gm-Gg: AR+sD13wgU6g6UHkv9UD0nknC3dWlprYnoV062KGlh8kODkj+QR3vosmIrhAsOAXNiN
	sykZl+T+8gsfrxg679xMBCbGTq3S5i/+4RXsr3a6qT1JY5cW488HlAwc5g5ThXMiXgM+Si0pR4d
	NMXbbAZwxyxH365jkS0sBPMsjDC37ihVafuQrJXdAGXoT14R1BoaXgOumPJFVxoq/Gl6OkxraCi
	zqwTh0OO3FH2SpOFYngSO38Kjlh/fBeUtSsae/DryjTzJEFSuogoKc97O5HQ0AbLDiIJpEFo/wq
	gqFPKf/UARyJwL3Tz4w5h5jg00Yj1M/bGr9h1ogjZslRUfAU3a0kwlXMX64v7K/k7xh+Y4OyCXJ
	EkL9WusBi0fOitGiDUzxewhugYukXU1WMaWrRlE3eP7Jj7ydbN71Yy30HS6v4j8JV/A2/5bHYVD
	whfdoZeRd/uQNxjR/wZ63OmtAVhpP4rUR+vHbtZosPbSjPcT9cYI8r+6XtrpGJElGJ6jH/yrOyt
	dkkk7F5z2c+iQYMJ1J++hlzQ2CzZmROyfsOXoPiEn8dGG+TaGITZzyURkwjjp+CaVMTXIYL4301
	iMIoN0HZhB612hg=
X-Received: by 2002:a05:6402:4550:b0:698:3dd2:6802 with SMTP id 4fb4d7f45d1cf-6a14f13c034mr2005116a12.12.1785920155301;
        Wed, 05 Aug 2026 01:55:55 -0700 (PDT)
Message-ID: <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
Date: Wed, 5 Aug 2026 10:55:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
To: Jan Beulich <jbeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
 <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------3An0i0jnKJ9M07xQcN6POwJ4"
X-purgate-ID: tlsNG-16d1c6/1785920155-F70C777B-7686AAAA/0/0
X-purgate-type: clean
X-purgate-size: 9485

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------3An0i0jnKJ9M07xQcN6POwJ4
Content-Type: multipart/mixed; boundary="------------4WW0qjN3x6DNZ0llnQU8epAf";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
Message-ID: <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
 <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
In-Reply-To: <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------4WW0qjN3x6DNZ0llnQU8epAf
Content-Type: multipart/mixed; boundary="------------U7EZUbIJg56Wv00dnzU6nCTX"

--------------U7EZUbIJg56Wv00dnzU6nCTX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTA6NDQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNS4wOC4yMDI2
IDEwOjIxLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEvYXJjaC94ODYveGVuL01h
a2VmaWxlDQo+PiArKysgYi9hcmNoL3g4Ni94ZW4vTWFrZWZpbGUNCj4+IEBAIC0zNyw4ICsz
Nyw4IEBAIG9iai0kKENPTkZJR19YRU5fUFZIKQkJKz0gZW5saWdodGVuX3B2aC5vDQo+PiAg
IG9iai0kKENPTkZJR19FVkVOVF9UUkFDSU5HKQkrPSB0cmFjZS5vDQo+PiAgIA0KPj4gICBv
YmotJChDT05GSUdfU01QKQkJKz0gc21wLm8NCj4+ICtvYmotJChDT05GSUdfU01QKQkJKz0g
c21wX2h2bS5vDQo+PiAgIG9iai0kKENPTkZJR19YRU5fUFZfU01QKSAgCSs9IHNtcF9wdi5v
DQo+PiAtb2JqLSQoQ09ORklHX1hFTl9QVkhWTV9TTVApICAJKz0gc21wX2h2bS5vDQo+IA0K
PiBTaW1pbGFyIGlzc3VlIGhlcmUgLSBpbiBhIFBWLW9ubHkgY29uZmlnIHNtcF9odm0ubyBk
b2Vzbid0IHdhbnQgLyBzaG91bGRuJ3QNCj4gbmVlZCBidWlsZGluZy4NCg0KTm90ZSB0aGF0
IEkgZGlkbid0IGNoYW5nZSBhbnkgZnVuY3Rpb25hbGl0eS4NCg0KSSBhZ3JlZSB0aGF0IGl0
IHNlZW1zIGEgbGl0dGxlIGJpdCBzdHJhbmdlLCBidXQgaW4gdGhlIGVuZCBJIGJlbGlldmUN
CnRoZSBjdXJyZW50IHN0YXR1cyBpcyBva2F5LWlzaC4gUFYtb25seSBoYXNuJ3QgYmVlbiBz
b21ldGhpbmcgaW4gdXBzdHJlYW0NCkxpbnV4IHNpbmNlIFhlbiBzdXBwb3J0IHdhcyBhZGRl
ZCwgYXMgUFYgd2FzIGFsd2F5cyBtZWFudCB0byBiZSBhbg0KYWx0ZXJuYXRpdmUgdG8gYmFy
ZSBtZXRhbCBzdXBwb3J0IHZpYSBwYXJhdmlydCBwYXRjaGluZy4gSXQgbWlnaHQgaGF2ZQ0K
YmVlbiBwb3NzaWJsZSB0byBidWlsZCBhIGtlcm5lbCBub3QgcmVhbGx5IGZ1bmN0aW9uYWwg
b24gYmFyZSBtZXRhbCwgYnV0DQp0aGlzIHdhcyBtb3JlIGxpa2UgdGhlIGFiaWxpdHkgdG8g
YnVpbGQgYSB4ODYga2VybmVsIG5vdCB3b3JraW5nIG9uIGFueQ0KZXhpc3RpbmcgbWFjaGlu
ZS4NCg0KSU1PIHRoZSBYZW4ga2VybmVsIGNvbmZpZyBvcHRpb25zIHNob3VsZCBhbGxvdyBm
b3IgYWRkaW5nIFhlbi1zcGVjaWZpYw0KZmVhdHVyZXMsIGJ1dCBtaW5pbXVtIFhlbiBzdXBw
b3J0IHNob3VsZCBhbHdheXMgaGF2ZSBiYXNpYyBIVk0gc3VwcG9ydCwNCndoaWNoIGluY2x1
ZGVzIHRoZSBYZW4gc3BlY2lmaWMgcGVyZm9ybWFuY2UgZW5oYW5jZW1lbnRzLg0KDQoNCkp1
ZXJnZW4NCg==
--------------U7EZUbIJg56Wv00dnzU6nCTX
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------U7EZUbIJg56Wv00dnzU6nCTX--

--------------4WW0qjN3x6DNZ0llnQU8epAf--

--------------3An0i0jnKJ9M07xQcN6POwJ4
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpy+poFAwAAAAAACgkQsN6d1ii/Ey9l
6wf/W3HihkA9Uswmcrucb7tqvb9cOHanp54LuaclrG8FpHgmia/XK9kqYKucq8x/PjndxPRRw7iR
tOMrc8W+tFk+XoFiPSL20Py+7dy8Gx1QVCCnCigJtCZB2lQNI5kem5MHtHz67Tfeol5ECFyI4QcZ
RTyT+QOQzr1I0lZkFOjG7XJSneJxE+w+p5bS6kkoL3hW+MX3Jg2r/ZMlJGKkSS1Ox229E5FdLYhM
worPO50+LlSCLD7yv3dsOCl5UtTFgLJhucCae9ETY6SGYEguxWR1/73YNOHC4rSBGkWVDSFIlHYR
BahBO/dX9OJjLhhhfcGUhITJJA7rF1BLqz2AY+ZPRw==
=GhTB
-----END PGP SIGNATURE-----

--------------3An0i0jnKJ9M07xQcN6POwJ4--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 08:56:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 08:56:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383079.1626343 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXQO-0006hw-Dv; Wed, 05 Aug 2026 08:56:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383079.1626343; Wed, 05 Aug 2026 08:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXQO-0006hp-AJ; Wed, 05 Aug 2026 08:56:32 +0000
Received: by outflank-mailman (input) for mailman id 1383079;
 Wed, 05 Aug 2026 08:56:31 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrXQN-0006hQ-04
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 08:56:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXQM-00BL75-CP
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:56:30 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a72fabd-bab6-0a2a0a5309dd-0a2a45089ac0-2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:56:30 +0200
Received: from [209.85.218.53] (helo=mail-ej1-f53.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a72fabe-f659-0a2a45080019-d155da35c801-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 10:56:30 +0200
Received: by mail-ej1-f53.google.com with SMTP id
 a640c23a62f3a-c1712a04ddaso126059566b.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 01:56:30 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a17bf29168sm631551a12.23.2026.08.05.01.56.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 01:56:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785920190; x=1786524990; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=/WAzVNKrEa94ZkoIMZwJA/XwMsXDf68SL8hYPTUGjw0=;
        b=PjJaIPIWCrdPtzmk/+rekj44mvHUCuPeMUyDXYmhjQtlRgDh1dFI65RWOarYsRVPnh
         rCqjI41xUTIzekIJjKYCbvWV/IAPoIxkFjQO2xlbxkd9O1H3jYSZE/jj8a6cOOMcx3KO
         bM+fq0uG1M0S2Qom19SdH9SI8gQofFP3qm0+VbvLeYi0tfZVlVWsTP7r1N20EBFvnSb+
         pguqoO5MXoxOiEs5HHhYrBgSDivlfLpoUCGEtzublOhYXyEK9w+pClNHTV0pLbGflrXc
         0bHSFjiFz24xETuo9p5wDFe7251hATkeXY3yv5IgF+pGl7OYvu5NtGyWJHz5lI3xJz41
         Mvxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785920190; x=1786524990;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=/WAzVNKrEa94ZkoIMZwJA/XwMsXDf68SL8hYPTUGjw0=;
        b=kYYzhdBinC+opWBaKoDMXfaUH9vmJFVMWPFNkb3fcm7GCOwt1IePDzmeocbTKNRsC6
         ARn1kaTvK9fRNH9cmrwUeCAr6zeGMOq+YNTMIRuu4HaYubjgrw4JQWeiGpQG6W3kuGPD
         yRMIcrp8/rXgZSc9HfOSVp9bXUZtIPj0L2w7hUF0JBzSNd+BchzNjYHGyGL5vm/bhz5l
         aNY9TOAmfJu43b+znBJQl2ryxRD/QshDmjLGnjTvtrI1sYJmtITRkS2w8t6Pgwurdoaw
         bFkFtRD1MRaP2Jgford+WYEAupWE0D4HjXrH5RjiU1LRe18RWYoOpUWhx8XhS6FfcCKD
         RFAQ==
X-Forwarded-Encrypted: i=1; AHgh+Rp07VOr6alxwlhqE5EpzOLxvP8Fm9U9ZQycpnMGhORmC8u8pto6/VsL+28GbvNmgg/gD7wyiAnrro4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0wf9e75HZC2b7OgmaeCk0FKRW1BATmwEPFV6ve+/MzdLhQCCr
	GrVeBLaGx60QQsPFwl1nBEuzWXgZOjJGNPyknIFLLOBcYx0b3KMg2e+KRWRICJAU3eM=
X-Gm-Gg: AR+sD103pa2fS3/fhRgtyrhuPeWg6Yu6fTafjpKI2FYcAdEFbSI1eQEPndg15IeuczE
	qBKJKX3I8o1xCg/DyUO/9SY8uMA65QALQsLoi50jNB2q2YtAIiIaegAJ5qEaN/ecB8xtTeOjCp8
	u5NIq8ZvuBibhcG+ZhaH+Yc4wYoxj0vlNoPoK9L9Oq5Qh8gjCGs1WsVfM0M3obFmyvd70qb1F3r
	Y545Y8C6ANYgNQtfZZOfnZRDsmvfdGXz6CytOL/qUK3ztJrqmWDyhrub++rYixd8snt+3vtvFyM
	ASM1iek+qcEjRQAx6YOc6iP3F8z03Cga3Ymnjpjc5h33ejBDoZ6PISMQEvk7NL4F0TZw/7sX59n
	DSrqbxTS7DPseDcKSCSVH0teiis+YfqbrpJ87zKt9jI2JuQ7a20zxia6XZ7JJyrHu/nB2CiO4nM
	KzJr2aitqh0+BHbxnLwkNeDj3rNDn40yZbFLKBBlSRcZDZ+DByXoa3Mf1ZuG+QQZUQZE/rkPBxi
	97V2Np41FuMhPQ8dIgQk7D+aaa0d3Xz4BvWYwJP9vyf2j/Vu6KGD5Kcb5FWSW8DzBMceb6b/cEz
	KekU26+eiOzt7hJtT30E5jk1FQ==
X-Received: by 2002:a17:907:1688:b0:c20:331c:cf0a with SMTP id a640c23a62f3a-c2039ad0de7mr189773966b.5.1785920189622;
        Wed, 05 Aug 2026 01:56:29 -0700 (PDT)
Message-ID: <2b144df0-c54e-41e1-afbc-5a6a0d5dad9f@suse.com>
Date: Wed, 5 Aug 2026 10:56:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-4-jgross@suse.com>
 <4ca560cd-c43b-4893-bec6-800a33cd1bb7@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <4ca560cd-c43b-4893-bec6-800a33cd1bb7@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------OfdoGTk13Cdl1qpBKjD05yeu"
X-purgate-ID: tlsNG-c1860d/1785920190-CF75B87B-98DCF980/0/0
X-purgate-type: clean
X-purgate-size: 8253

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------OfdoGTk13Cdl1qpBKjD05yeu
Content-Type: multipart/mixed; boundary="------------cyLXlascjfZ1ZpIXhc0dfFvc";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <2b144df0-c54e-41e1-afbc-5a6a0d5dad9f@suse.com>
Subject: Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-4-jgross@suse.com>
 <4ca560cd-c43b-4893-bec6-800a33cd1bb7@suse.com>
In-Reply-To: <4ca560cd-c43b-4893-bec6-800a33cd1bb7@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------cyLXlascjfZ1ZpIXhc0dfFvc
Content-Type: multipart/mixed; boundary="------------jMfJPo22aNSLaYa00xjt5SLN"

--------------jMfJPo22aNSLaYa00xjt5SLN
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTA6NDIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNS4wOC4yMDI2
IDEwOjIxLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEvZHJpdmVycy94ZW4vS2Nv
bmZpZw0KPj4gKysrIGIvZHJpdmVycy94ZW4vS2NvbmZpZw0KPj4gQEAgLTMwOSwxMiArMzA5
LDYgQEAgY29uZmlnIFhFTl9FRkkNCj4+ICAgCWRlZl9ib29sIHkNCj4+ICAgCWRlcGVuZHMg
b24gKEFSTSB8fCBBUk02NCB8fCBYODZfNjQpICYmIEVGSQ0KPj4gICANCj4+IC1jb25maWcg
WEVOX0FVVE9fWExBVEUNCj4+IC0JZGVmX2Jvb2wgeQ0KPj4gLQlkZXBlbmRzIG9uIEFSTSB8
fCBBUk02NCB8fCBYODYNCj4gDQo+IFlldCBpcy93YXMgWDg2IGNvcnJlY3QgaGVyZT8gU2hv
dWxkbid0IHRoYXQgZXhjbHVkZSBQVi1vbmx5IGNvbmZpZ3M/DQoNCkFnYWluLCB0aG9zZSBk
b24ndCBleGlzdC4NCg0KDQpKdWVyZ2VuDQo=
--------------jMfJPo22aNSLaYa00xjt5SLN
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------jMfJPo22aNSLaYa00xjt5SLN--

--------------cyLXlascjfZ1ZpIXhc0dfFvc--

--------------OfdoGTk13Cdl1qpBKjD05yeu
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpy+r0FAwAAAAAACgkQsN6d1ii/Ey9g
3Qf/TduT6P4Atx2oGLx/o2nDSVO14yCzVmoZPOXvuWesvK5Duqgn4P0T/x6tBEBN7iEZp7dtuhq/
SqUw3tuWeG65jj2nGLQxTa98odBw8uMh71Zh/qhwclD96Lggoz0ieKlHN0JUleEiO9EG4S04eL6v
aRELJK3V+gh98+l6SCLTicSWKi1jNes6shGW9k6Aso8f6TeTyVgG/GOPyrbiTezf/e22+Tb1vIgC
+A5IwnqTzAlUKMyP7ZER8mKmkVRsa5PJYliK8ycD1b/ojErtbSvy31X4z+DfrJ4V2orXDJFLOwwI
Ynb+i3db+iO87tEWSuW3ZQeCx3i0h1TcUgkZiKV+cA==
=QLSH
-----END PGP SIGNATURE-----

--------------OfdoGTk13Cdl1qpBKjD05yeu--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:04:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:04:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383095.1626351 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXXt-0000RX-8i; Wed, 05 Aug 2026 09:04:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383095.1626351; Wed, 05 Aug 2026 09:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXXt-0000RQ-5P; Wed, 05 Aug 2026 09:04:17 +0000
Received: by outflank-mailman (input) for mailman id 1383095;
 Wed, 05 Aug 2026 09:04:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXXr-0000RJ-RQ
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:04:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXXq-003Ex0-JW
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:04:14 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72fc89-e002-0a2a0a5209dd-0a2a450499a2-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:04:14 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72fc8e-b57f-0a2a45040019-d155802fbd04-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:04:14 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-49556f97a9dso4591765e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:04:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23ede6sm7230911f8f.30.2026.08.05.02.04.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:04:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785920654; x=1786525454; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=CcWPV/2C/noLJiB/mvTSLtIwjRvaHYyVNz5lIaVixS4=;
        b=eLL9tBzCCsDqDeWiq93199XJ/U6NjXuklWLUBNSM7IkY4ZoE91vjibio8JheXKXHiD
         /8YO4KtdbOy9h5zkuL+NJtLEQgHn1Ux5SYrEvmMX/eKgq5nDy//RfubH/+d+Ft6TOMv4
         7aNx5F1oyYM2CO+KGp+169Onj5AZ9OCE315LhN1ccr7vK+mKbw3DFJO7MDy9JWpkdIu1
         SWOe/6SZPY1Gwh5v/tBlsLGnsS9BD7oQfLb+unCDtORxv+rLHceaWokXRa51SvdUffKv
         EKnHBPtSvjyEhO8TvTJXB2xK8nKkkuRoLZcmb+nqvZI+1zbnRLwuPOsh2juhbqOUEG7g
         Cuug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785920654; x=1786525454;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=CcWPV/2C/noLJiB/mvTSLtIwjRvaHYyVNz5lIaVixS4=;
        b=ZxYsjU/m8QhPtsU2upPsb7tL9iw3NT1//QnQt9QrerlLzuMutIrs5xiMFdjunobSSe
         BtCXHT+gBNjIIfog+3NnNCv8Xnoh9BrjDGH0zcsj+CejxL8i1BYvMnZt6oQnDQutPXlT
         DdD8Sy7ehreywAERocrj5GHzazG54R0GMLugOWrgHA08ttlCIRQITKWH7bn9l+2kDzU1
         Vjnr1l+pAslVeAiLRC2gt2ZfVrhsUETip5FBefTPtFRDwWTd15Dh8SifsgS8cq41X8aC
         lbwfDggmgFKTcbFoY9Iwg8i/IflOl58HuHW5bzwI9PlNGq28qXZj+gBqWQ5SAFnTPyso
         qkkA==
X-Forwarded-Encrypted: i=1; AHgh+RqpexKbYGAMql7ShjY0WTRcPPAountQP4gUFc4ePY8NnqVkxVZZhRlnO7NrNgdRxKEx4XEhId17bvo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yye18rfQNRSpt8U3YoSjWAFMgU8uI+FiuOOXcu2v73cTRFqjWg0
	t76dJgnQp29qOkXYrDOtKBWVWFo8106rlXDtl5xXtNn/bNwBuxNkaO7sH2nsYJVtuw==
X-Gm-Gg: AR+sD11z+sGvQv408WCvZrvsOw4/f7oNP97NDcRJPI6zDfh9hMFrGcaZjdC5YMNju4D
	pVaFGPeI0/JdKNo0sKBGMmVkAtip7C2L/v5bA6fze/3wuIBJZj8kROQwPzsPFgsrDeyg+Ja8zSD
	SpR71W8Naa1JvnzF2ieNCmaRcrgzfN0AUxZNe5oHJIVA55u6fnzbajSMkusRlxp84UrW9vZjz8j
	yy6RqMQnfM2izz8aTK0kZv9pAjftzhAXrNUTFr1Z6Quqt46mnrGbQADItXiYwyOrWsN9IuO/dzZ
	JTnrqgK3ascCU2nutqF5AAJ1YDTVJ29MPyFqJC++VM8xka++uGi2CrFi8gMNvMzowtrXZ2W3gym
	xCZPtJehNe+/LsG7HEY8JYpy4f8sR/312lzOctw+gZlquccdxysOqPWeUPrCv/p7vQYGTX5tm+M
	GHLFqnfAbB1nKmaKXn0P1wzOR1LsqlnWU3ja5yb46UYhJS1J2J62mvJSIsL6Ao5OxREpIr3P0h4
	Hz4vGM1Vp8PaYkajrZnpjpxx0XCAYphgQ+bLNOogayoaN2tStNh
X-Received: by 2002:a05:600c:4688:b0:495:6bc9:62b0 with SMTP id 5b1f17b1804b1-4994e7d1487mr55628955e9.17.1785920653939;
        Wed, 05 Aug 2026 02:04:13 -0700 (PDT)
Message-ID: <bbae3eb9-6d1e-4caf-a647-25ca9ca8a61c@suse.com>
Date: Wed, 5 Aug 2026 11:04:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
To: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org, x86@kernel.org
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
 <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
 <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1785920654-520D5B50-1A0B19E4/0/0
X-purgate-type: clean
X-purgate-size: 1558

On 05.08.2026 10:55, Juergen Gross wrote:
> On 05.08.26 10:44, Jan Beulich wrote:
>> On 05.08.2026 10:21, Juergen Gross wrote:
>>> --- a/arch/x86/xen/Makefile
>>> +++ b/arch/x86/xen/Makefile
>>> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>>>   obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>>>   
>>>   obj-$(CONFIG_SMP)		+= smp.o
>>> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>>>   obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
>>> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>>
>> Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
>> need building.
> 
> Note that I didn't change any functionality.
> 
> I agree that it seems a little bit strange, but in the end I believe
> the current status is okay-ish. PV-only hasn't been something in upstream
> Linux since Xen support was added, as PV was always meant to be an
> alternative to bare metal support via paravirt patching. It might have
> been possible to build a kernel not really functional on bare metal, but
> this was more like the ability to build a x86 kernel not working on any
> existing machine.
> 
> IMO the Xen kernel config options should allow for adding Xen-specific
> features, but minimum Xen support should always have basic HVM support,
> which includes the Xen specific performance enhancements.

I fear I don't understand this. If I want a kernel just to run as PV Dom0,
why would it need to carry anything HVM-ish? That is (or should be)
entirely unrelated to being able to also run this same kernel on baremetal
then.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:11:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:11:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383107.1626360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXeW-0002Ul-TG; Wed, 05 Aug 2026 09:11:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383107.1626360; Wed, 05 Aug 2026 09:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXeW-0002Ue-Qb; Wed, 05 Aug 2026 09:11:08 +0000
Received: by outflank-mailman (input) for mailman id 1383107;
 Wed, 05 Aug 2026 09:11:07 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXeV-0002UY-Lp
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:11:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXeV-0095Bc-2j
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:11:07 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72fe1b-2eae-0a2a0a5409dd-0a2a450ca3c4-46
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:11:07 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a72fe2a-f479-0a2a450c0019-d155dd2bf1a6-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:11:06 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47f7872abb6so353885f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:11:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec231f5csm7197501f8f.23.2026.08.05.02.11.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:11:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921066; x=1786525866; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=VGV25APuoOGYWcIc/TeUgn93qgV5jI1K78UHmfRhA/k=;
        b=TYSsoK44bQmVSZ/0zdgRnzZCZhGwyJxLd1J8tcozyCdobYwJal/t9+kC811PYOn+fN
         IqNlwvtiXhadQF4witff2IwCZ9U/O8yjIeXxrQp9wgRfpfarOeeekIePUIrq3jcmRibS
         JBzGTnmtMG+rJ76Pe9xv4YAOGHM6zRA/q8lprV1tbcPUU8cRZBUIYmTg8W1ytCVkACxM
         0Sd/J/62lTV5LPJtCf/abIniVKz4rG5AwiX3KnOICgY7L9JTH91SWWheEk265u3e97Zh
         hiLhlAgFNAPqj4gxfst2pPh8RwPLOrpOQMHkLNVsMwL027hCfIXpGp8c/wgg2GySfWYB
         WsLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921066; x=1786525866;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=VGV25APuoOGYWcIc/TeUgn93qgV5jI1K78UHmfRhA/k=;
        b=SCiGtYgtBxlCLg9es0OD3hQ7JbB3GVQnRFp0NzqN+iHoSNdwZupJNfLihDyQHMYEwB
         jjlScQWhNMg0oqryk1Gbsp+XbVSWqlqpSkEHMCQuzqzet/S0jo2t2jGXUDCZnbpCHxAI
         NL7rDnSvv7+FKN5Ki4qpgZD7HR+9N5bn20WgQsYZEBObZkqoH2K/oivklLuty0fJd2ZP
         TzDoKxfTPPqUcsuLi2RFCl0FE7qVLPBQdQlhUTvTGENZqInpu/PdUiuB+CW8TKZuSFEa
         r0brTpBXgd+kaPiNA+Nhu49+EVPHN1z+BMKBRgejfrx9ImaDiA8/E7MwekuLuRU8DBDA
         szFQ==
X-Gm-Message-State: AOJu0YweteyBDw5aG6wQuqYlPXQ1V7YmLVLtvThh0+1zDfrxNOKy7HBQ
	lHJvoZ5LI4J72nI3MACeo+YFro3M8Ra9uJLqa15PphNlFwTbU26KNlfF76VRMn6L8A==
X-Gm-Gg: AR+sD10noqeDvxrbRSTFPOwUxk94gkBbAvM8rah+Z6PW38ZykO9nvSEO5fYchWCVL/H
	zqCMdOlKw+7CEBWVU1Y0B/9wxbNO9/2dCMy8cUflpH7GciDjBJqAXw56U3O4JeKtr50pxJNaKgI
	H6cKY0vUHKQWV8LiS1vt4onlDusQG0Z9jF9rrKZKq5izzi5JyT8jvKpmZe3HwhIi2aLTqbp+ebK
	XLUE6K/xFwgyoaTXTDoeadwUJJeXer4UKVq+Q/skS6uGOw9iHJQN9rGnJ/rBEQEsXhh+BdNuw18
	tZCmZYgkhxU9ZwAsTyOcuUhLKTGsJCZh8t5RoxniOiekTEPUsJWnf4f5Plag7ITIPqBsDQ/skl8
	hgkL5XJtOGsT9ZlpnBF7eQgP8Wtd7NWI4VLfADMbLJEw7gUNUSr+kRDGW+VCg7zE1esZxAxQsLk
	TJ3RWTj33976LjBhgYnGPc2KPsrnrbsMMo7kbhN2E2GLYqPrOY22zbhqcxdWYWS76I+fiX+wnug
	+8Cyz78Rbk6zyHrVezoE+dP8subgdxvGs33sti95qDwQnGNM6BdVUkv3C6DWbk=
X-Received: by 2002:a05:6000:4718:b0:47f:93fc:2d27 with SMTP id ffacd0b85a97d-47fec62c7e1mr8485530f8f.30.1785921066305;
        Wed, 05 Aug 2026 02:11:06 -0700 (PDT)
Message-ID: <b34dff82-8ead-467d-93b6-4dd655234400@suse.com>
Date: Wed, 5 Aug 2026 11:11:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jason Andryuk <jason.andryuk@amd.com>,
 Daniel Smith <dpsmith@apertussolutions.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <bbc2fb48-d79e-4f00-81b4-0170dd910aaa@amd.com>
 <8097d8e8-42ec-463a-8247-56c9e4d834cd@suse.com>
 <57bb7281-5898-4243-837a-1236b25e761e@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <57bb7281-5898-4243-837a-1236b25e761e@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1785921067-016C6A5B-CD5B4504/0/0
X-purgate-type: clean
X-purgate-size: 4124

On 04.08.2026 16:27, Jason Andryuk wrote:
> On 2026-08-04 03:53, Jan Beulich wrote:
>> On 03.08.2026 23:01, Jason Andryuk wrote:
>>> On 2026-07-28 09:22, Jan Beulich wrote:
>>>> --- a/xen/include/xsm/dummy.h
>>>> +++ b/xen/include/xsm/dummy.h
>>>
>>>> @@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
>>>>    #endif
>>>>    
>>>>    #ifdef CONFIG_ARGO
>>>> -static XSM_INLINE int xsm_argo_enable(const struct domain *d)
>>>> +
>>>> +static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
>>>>    {
>>>> -    return 0;
>>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>>> +    return xsm_default_action(action, current->domain, d);
>>>
>>> This one I think should be
>>>       return xsm_default_action(action, d, NULL);
>>>
>>> Usually current is passed in for the check, but for domain_create() ->
>>> argo_init() it is the under-construction domain.
>>
>> And in that case we want to make sure that current->domain may enable Argo
>> for d.
> 
> It's not a hook for current to enable for d, but more of a hook "is d 
> allowed to use argo."
> 
> In the hypercall entry path, it use is clear - "is this domain allowed 
> to make argo hypercalls."
> 
> In argo_init(), it is more of an optimization.  Only initialize if d is 
> allowed to use argo.  I think this use is questionable, but it is the 
> current code.
> 
> In flask, the source is d, the target is xen_t:
>      allow domain_type xen_t:argo enable
> 
> So it is not an operation between domains.
> 
>>>>    }
>>>>    
>>>>    static XSM_INLINE int xsm_argo_register_single_source(
>>>> -    const struct domain *d, const struct domain *t)
>>>> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>>>>    {
>>>> -    return 0;
>>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>>> +    return xsm_default_action(action, d, t);
>>>>    }
>>>>    
>>>>    static XSM_INLINE int xsm_argo_register_any_source(
>>>> -    const struct domain *d)
>>>> +    XSM_DEFAULT_ARG const struct domain *d)
>>>>    {
>>>> -    return 0;
>>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>>> +    return xsm_default_action(action, current->domain, d);
>>>
>>> Similarly:
>>>       return xsm_default_action(action, d, NULL);
>>>
>>> The single call is:
>>> xsm_argo_register_any_source(currd);
>>
>> There being just a single call puts this on the edge. If there was another
>> one not passing current->domain, I think the same argument as above would
>> hold here. And the general concept is what I think should matter when
>> writing the dummy implementations.
> 
> For flask, we have xen as the target again:
>      allow domain_type xen_t:argo register_any_source;
> 
> ... since a wildcard ring doesn't have a known target domain.
> 
>>> These argo hooks all pass in their arguments explicitly, so I think we
>>> should do that and not use current.  (The send and register hooks could
>>> use current, and that could make sense as those map to hypercalls.  But
>>> it is correct today with the explicit arguments.)
>>>
>>> With the changes:
>>> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
>>
>> Thanks, but no - unless I misunderstand how permissions are intended to
>> work here, I don't think I can make the changes requested, and hence I
>> can't apply the R-b.
> Understandable.
> 
> It seems to me that the XSM hooks have two styles.  Either implicit args 
> (using current) or explicit args.  Today, the argo hooks take explicit 
> like the grant hooks for instance.

Yes, which doesn't make things any easier. I follow your argumentation as
one of the possible interpretations, but I think I really need Daniel's
verdict (as XSM maintainer) here in order to know whether to adjust the
proposed code. (It is true that what you suggest comes closer to the
blanket "return 0" that were previously there in all the Argo hooks,
leaving aside that due to it being XSM_HOOK all of this is cosmetic / doc
only anyway. There is certainly also the option to retain those, but it
feels that doing it like this was wrong from the start.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:21:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:21:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383118.1626368 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXon-0004NI-R8; Wed, 05 Aug 2026 09:21:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383118.1626368; Wed, 05 Aug 2026 09: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXon-0004NB-O2; Wed, 05 Aug 2026 09:21:45 +0000
Received: by outflank-mailman (input) for mailman id 1383118;
 Wed, 05 Aug 2026 09:21:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXom-0004N5-Fz
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:21:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXol-00HW9a-AS
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:21:43 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7300a4-5cb7-0a2a0a5109dd-0a2a4505af8c-22
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:21:43 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7300a6-4cb1-0a2a45050019-d155802fd509-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:21:42 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so6086135e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:21:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfdd383sm6701110f8f.8.2026.08.05.02.21.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:21:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Content-Language:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921702; x=1786526502; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to:content-type;
        bh=TsYpXoA+xmQ+uT37K3y8LI1YqP2UpTicdeqYAxlPxBE=;
        b=QzY8PYXbwweH/TOKGQUbKM4ayT2a/rbGGFyq8YK2srDY3xjnD6v+JLz9QPTN8cu+UD
         KkfUxMlXbRqWBQNuIieim6Wj4Yuf6GIJPDGZWf0I08spJkYQDTYBwA5jR7XVXhbPAJby
         NWySf+mfMYCZuRxETn2KJEJPaXqnbf3kZGaDOH5qbygpClmkOIW9IQ29R5OGUrFXVhQM
         dZusQms1RkCnVOwqbPz8xdF12s628H8gLIPmLbfSjrFwbrHQBUkwmHno0q4Ki9jIMcKR
         aNFvKr87P5cwNhQZQk5HSOS8vjIp7nzDx9RYrcx42TvFFvrPZl7bGVIOyRUACUx2mBKO
         psOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921702; x=1786526502;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=TsYpXoA+xmQ+uT37K3y8LI1YqP2UpTicdeqYAxlPxBE=;
        b=ZZwnT3wHoFmbF8ZbnWmtFjsEJ5Nx+C8tMrBAg40IC/txcigHSp0IdLQcOyPKDN+blm
         tePzRJrJaVQ6uxHHccZRwnhO7GkgUx07Rgwl/11MUsxvfnTcnDP6m84WCHXxnYswGPgh
         AG5faS+a9No2/R7rapUTGUz38zkkAqYZdhR+/b5rQv+/tfToXXfA+McIQtzCQHpmcJyv
         WoA5j41QfRomRCguxlnwQVC9NuWQEIzAa5g+92yiujwfrxOkKeskZKUsuoO1Z0J0IPGb
         oj2esTS3ZqeV5IOCrJCxb2IKDWpXgw1XeINanY62TPf1xQlBh4VXQgeXclqVEag+RSym
         ALZA==
X-Gm-Message-State: AOJu0YwU5ciRN8uzh/GlySKBILda4LrAoe8aRbHyOjYQxLhPjs0nkTr1
	KnRwM+qDe6rmiNzDTZ5MDfWUpiyL9xwyNAL5LsX+WMDLxLLs7foFxFqYa/gQfLag3MfbG2ax4RI
	T6rT67g==
X-Gm-Gg: AR+sD13iVQwnD4k5Pd3PXhVnORZtSptFZx4Ge8j29E5CCQ7mGFVzG3E7J1lf17Z9ak3
	+WfZWP3HFRxDu37WOObSCfFgYypMyaO4h3H0FlQxCygVJ4osVyDMYuxoBRylcvmPW5NEGUMS3jG
	40BsK4SwGUma/EP+D6kTcKTH/5oaJ23ajGm8Q8rezHBgpIoCoLR6tnOQLPl37QZ/hzfwxTmh8i0
	vWSwlHfxLnZMQuaaZhT5ds6X2UsVegyGRSIQ18l/bwLGLZMuTNL4UoKGwRzUBxHG7+lnSGUOLuU
	mQjGkRiFFuQTQKOmbLiCy1VIAIOFjXjtEHc2jwI3Axqe3yv6CA88sCm9VsEFFTh99CIuoyH7U8N
	GxufVppTPS9nGh9uM41oceUH/vPrJ/8Gm9IZK1riQREo9KveoQVr6d7qe5N5P404SsBGVvb3kan
	FQnNCEAqqRCGNQPWkJJO0y175v5c5hFCysCvKe5rQTxDdaKXt9AEYCMGeCGnEvMUpMEhBAQCodz
	WXq1lDOR1l7LRKCj2F/qhN4TAgfwGt3FaGyqRrdceC47FKeG4aV
X-Received: by 2002:a05:600c:5694:b0:495:503f:cf9a with SMTP id 5b1f17b1804b1-4994e7bab0emr40018255e9.9.1785921702104;
        Wed, 05 Aug 2026 02:21:42 -0700 (PDT)
Message-ID: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Date: Wed, 5 Aug 2026 11:21:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v10 0/6] x86emul: misc additions (MSR accesses)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1785921702-F74BC2A1-2A83EC49/0/0
X-purgate-type: clean
X-purgate-size: 233

01: x86emul+VMX: support {RD,WR}MSRLIST
02: x86emul: support USER-MSR instructions
03: x86/cpu-policy: re-arrange no-VMX logic
04: VMX: support USER-MSR
05: x86emul: support MSR-IMM instructions
06: VMX: support MSR-IMM

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:22:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:22:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383125.1626377 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXpd-0004od-2o; Wed, 05 Aug 2026 09:22:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383125.1626377; Wed, 05 Aug 2026 09:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXpc-0004oW-WF; Wed, 05 Aug 2026 09:22:37 +0000
Received: by outflank-mailman (input) for mailman id 1383125;
 Wed, 05 Aug 2026 09:22:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXpb-0004oM-SA
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:22:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXpb-003xUi-5I
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:22:35 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7300d3-2eae-0a2a0a5409dd-0a2a4505b946-36
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:22:35 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7300da-4cb1-0a2a45050019-d155802ba8ba-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:22:35 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-4980fe6b3beso13701115e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:22:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23ec2fsm7161507f8f.29.2026.08.05.02.22.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:22:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921754; x=1786526554; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=fjs9sHGquZQF/L9bQ2CBvHTyahS9kvnKV++jSks/hjg=;
        b=aTi2DlL5iPdfdH0pnVUgeZHz5PewJmSA5XIEdpeqAEhwAH0eGoQq+mgM7ADhEZWE94
         8ESS91/JXM2YYrxa8fsSJPN9uDJ7Mirs1UREg7AoTDm6rBqjSU6CKdJt3lbmQJVMK0FC
         /YSVX2Wy877OHcqmkOAdMjOPYpC5r/XyEINzwMVE+Pi/MQGI+WLQZI8wLcc4dDvLIlWU
         AjbnKxCGr5LQ4W2mOfTILLcj4BRIoy1NOptTxQ8oNyBNUDowe2wWeziNCSwWPm2HQki1
         v3glK+QxdvB/1WqmYeaCz+Ssr2CDss7nNryhh8HBSk+lyYUEUtdDIIVN4dLpV3ipKF30
         FXZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921754; x=1786526554;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=fjs9sHGquZQF/L9bQ2CBvHTyahS9kvnKV++jSks/hjg=;
        b=e5vSWvOkY2SQ+XjIJqh5R8i5M+vWHUdUAM/zl37Zd644JlGlc+++TRGWr59jvuOLea
         jocPsDe57g7gJHXb6Hh3d5HLay+bzasIoQ4w00/GRfiLnDPKzlygIrwpv790jKmS8r1v
         GosAAyiVVTQhrAsr1G0bsxIXUuW8ULMDI/RCOiH5fykqz0RcugE0e2LSIGl5wHZ8WbAW
         JJnD4fMJbZW0fRet8e0vXxoKa2O7Mur5Hdb8lxMZVQx/IrpP3mB9/niypW12j9nT56ol
         ZuQ0AaJy2lKjTzirPLBbg/PHaVvSVTpcrP4seKwom30dgBgEaAxZnyUjPIaej1sMTqQI
         q1Zw==
X-Gm-Message-State: AOJu0YwR+OxwVKaOXgbe0FrW2ffvKeMhn3KR6teodYYlCpU/od51cKoV
	t/HfPvfFvtaxIxXGSOdTF4P77ROMWAWgSCgk2i/LRQRgZud5NQyG2x1ZZJ370UhafG0ZzoFEOFL
	ESOLD8Q==
X-Gm-Gg: AR+sD104OH90ORHdPj8+mbUZL21z+Z2r4m0u4LB2cwZdbUU812Hj0GD136B8/SLjjlI
	GuFTKRB8qfG2xnDiicUA5ziMAjD4fpL7oEnufImhhQ09H6zYDxbEZCWRDM2aRDt0UXOTSupXvan
	+r2bBjHZTM7TUHj2JWIMidawKAw89cOt5eJ/osawx29FWQHJF2cUeycJLelGceFN/Vvg8N8XXSY
	YpTxKth3euRdiNhLbhH3orjvmuP27VfNwbEUsK2xfcCoECEx1fa3wgU7BAz8+sAKdHLr5T1wqIZ
	orj9HiPYFr/J71NAmYtqAK7mRjQMVwXXiNo/Or1E2YUV2rWF3IIdREe/1k+uZMYRtnAcSJjloJo
	iucqm2o7QY2WKHI+WSSr4sOqtQb7RDTKdCKV1ZDef9SradVihzwnLEoF28hSSoc62lFpiBu/SW7
	GxbAXhaUrxSfNb5ob8CQn5HlXyfM/0ZJ9BdfA3sz7GNiyh1i3p2s9zLTkZNwN8205kKnlLv2NCs
	SeAt0GMh8/o+8TiLdhh2CrMcMWSG4OJjEXQHhjrNhH4SXQGWYEW
X-Received: by 2002:a05:600c:c042:b0:495:4f89:8117 with SMTP id 5b1f17b1804b1-49949fd9848mr140595665e9.1.1785921754483;
        Wed, 05 Aug 2026 02:22:34 -0700 (PDT)
Message-ID: <28b5b379-0577-4244-b660-d03cfb5ccc93@suse.com>
Date: Wed, 5 Aug 2026 11:22:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v10 1/6] x86emul+VMX: support {RD,WR}MSRLIST
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1785921755-F7CB82A1-C1C4B105/0/0
X-purgate-type: clean
X-purgate-size: 18832

These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by way of hvmemul_virtual_to_linear() handling
this case).

Preemption is being checked for in WRMSRLIST handling only, as only MSR
writes are expected to possibly take long.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: In vmx_vmexit_handler() handling is forwarded to the emulator
     blindly. Alternatively we could consult the exit qualification and
     process just a single MSR at a time (without involving the
     emulator), exiting back to the guest after every iteration. (I
     don't think a mix of both models makes a lot of sense.)

The precise behavior of MSR_BARRIER is still not spelled out in ISE 050,
so the (minimal) implementation continues to be a guess for now.

Wouldn't calculate_hvm_max_policy() for MPX better behave the same way
as done here, at least from an abstract perspective (assuming that AMD
won't add such functionality now that Intel have deprecated it)?
---
v10: fuzz_{read,write}() adjustment. Non-default-expose the feature.
     Re-base.
v8: Re-base.
v6: Use MSR constants in test harness. Re-base.
v5: Add missing vmx_init_vmcs_config() and construct_vmcs() adjustments.
    Avoid unnecessary uses of r(). Re-base.
v3: Add dependency on LM. Limit exposure to HVM. Utilize new info from
    ISE 050. Re-base.
v2: Use X86_EXC_*. Add preemption checking to WRMSRLIST handling. Remove
    the feature from "max" when the VMX counterpart isn't available.

--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -171,7 +171,7 @@ static int fuzz_read(
     struct x86_emulate_ctxt *ctxt)
 {
     /* Reads expected for all user and system segments. */
-    if ( is_x86_user_segment(seg) )
+    if ( is_x86_user_segment(seg) || seg == x86_seg_none )
         assert(ctxt->addr_size == 64 || !(offset >> 32));
     else if ( seg == x86_seg_tr )
         /*
@@ -340,7 +340,7 @@ static int fuzz_write(
     struct x86_emulate_ctxt *ctxt)
 {
     /* Writes not expected for any system segments. */
-    assert(is_x86_user_segment(seg));
+    assert(is_x86_user_segment(seg) || seg == x86_seg_none);
     assert(ctxt->addr_size == 64 || !(offset >> 32));
 
     return maybe_fail(ctxt, "write", true);
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -342,6 +342,8 @@ static const struct {
     { { 0x01, 0xc4 }, { 2, 2 }, F, N }, /* vmxoff */
     { { 0x01, 0xc5 }, { 2, 2 }, F, N }, /* pconfig */
     { { 0x01, 0xc6 }, { 2, 2 }, F, N }, /* wrmsrns */
+    { { 0x01, 0xc6 }, { 0, 2 }, F, W, pfx_f2 }, /* rdmsrlist */
+    { { 0x01, 0xc6 }, { 0, 2 }, F, R, pfx_f3 }, /* wrmsrlist */
     { { 0x01, 0xc8 }, { 2, 2 }, F, N }, /* monitor */
     { { 0x01, 0xc9 }, { 2, 2 }, F, N }, /* mwait */
     { { 0x01, 0xca }, { 2, 2 }, F, N }, /* clac */
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -626,7 +626,7 @@ static int write(
     if ( verbose )
         printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
-    if ( !is_x86_user_segment(seg) )
+    if ( !is_x86_user_segment(seg) && seg != x86_seg_none )
         return X86EMUL_UNHANDLEABLE;
     memcpy((void *)offset, p_data, bytes);
     return X86EMUL_OKAY;
@@ -713,6 +713,10 @@ static int read_msr(
 {
     switch ( reg )
     {
+    case MSR_BARRIER:
+        *val = 0;
+        return X86EMUL_OKAY;
+
     case MSR_EFER:
         *val = ctxt->addr_size > 32 ? EFER_LME | EFER_LMA : 0;
         return X86EMUL_OKAY;
@@ -1431,9 +1435,53 @@ int main(int argc, char **argv)
          (gs_base != 0x0000111122224444UL) ||
          gs_base_shadow )
         goto fail;
+    printf("okay\n");
 
     cpu_policy.extd.nscb = i;
     emulops.write_segment = NULL;
+
+    printf("%-40s", "Testing rdmsrlist...");
+    instr[0] = 0xf2; instr[1] = 0x0f; instr[2] = 0x01; instr[3] = 0xc6;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = (unsigned long)(res + 0x80);
+    regs.rdi = (unsigned long)(res + 0x80 + 0x40 * 2);
+    regs.rcx = 0x0002000100008000UL;
+    gs_base_shadow = 0x0000222244446666UL;
+    memset(res + 0x80, ~0, 0x40 * 8 * 2);
+    res[0x80 + 0x0f * 2] = MSR_GS_BASE;
+    res[0x80 + 0x0f * 2 + 1] = 0;
+    res[0x80 + 0x20 * 2] = MSR_SHADOW_GS_BASE;
+    res[0x80 + 0x20 * 2 + 1] = 0;
+    res[0x80 + 0x31 * 2] = MSR_BARRIER;
+    res[0x80 + 0x31 * 2 + 1] = 0;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[4]) ||
+         regs.rcx ||
+         (res[0x80 + (0x40 + 0x0f) * 2] != (unsigned int)gs_base) ||
+         (res[0x80 + (0x40 + 0x0f) * 2 + 1] != (gs_base >> (8 * sizeof(int)))) ||
+         (res[0x80 + (0x40 + 0x20) * 2] != (unsigned int)gs_base_shadow) ||
+         (res[0x80 + (0x40 + 0x20) * 2 + 1] != (gs_base_shadow >> (8 * sizeof(int)))) ||
+         res[0x80 + (0x40 + 0x31) * 2] || res[0x80 + (0x40 + 0x31) * 2 + 1] )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing wrmsrlist...");
+    instr[0] = 0xf3; instr[1] = 0x0f; instr[2] = 0x01; instr[3] = 0xc6;
+    regs.eip = (unsigned long)&instr[0];
+    regs.rsi -= 0x11 * 8;
+    regs.rdi -= 0x11 * 8;
+    regs.rcx = 0x0002000100000000UL;
+    res[0x80 + 0x0f * 2] = MSR_SHADOW_GS_BASE;
+    res[0x80 + 0x20 * 2] = MSR_GS_BASE;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[4]) ||
+         regs.rcx ||
+         (gs_base != 0x0000222244446666UL) ||
+         (gs_base_shadow != 0x0000111122224444UL) )
+        goto fail;
+
     emulops.write_msr     = NULL;
 #endif
     printf("okay\n");
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -66,6 +66,7 @@ bool emul_test_init(void)
     cpu_policy.feat.rdpid = true;
     cpu_policy.feat.lkgs = true;
     cpu_policy.feat.wrmsrns = true;
+    cpu_policy.feat.msrlist = true;
     cpu_policy.extd.clzero = true;
 
     if ( cpu_has_xsave )
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -824,6 +824,9 @@ static void __init calculate_hvm_max_pol
             __clear_bit(X86_FEATURE_XSAVES, fs);
     }
 
+    if ( !cpu_has_vmx_msrlist )
+        __clear_bit(X86_FEATURE_MSRLIST, fs);
+
     /*
      * Xen doesn't use PKS, so the guest support for it has opted to not use
      * the VMCS load/save controls for efficiency reasons.  This depends on
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -363,8 +363,9 @@ static int vmx_init_vmcs_config(bool bsp
 
     if ( caps.cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS )
     {
-        uint64_t opt = (TERTIARY_EXEC_VIRT_SPEC_CTRL |
-                        TERTIARY_EXEC_EPT_PAGING_WRITE);
+        uint64_t opt = TERTIARY_EXEC_EPT_PAGING_WRITE |
+                       TERTIARY_EXEC_ENABLE_MSRLIST |
+                       TERTIARY_EXEC_VIRT_SPEC_CTRL;
 
         caps.tertiary_exec_control = adjust_vmx_controls2(
             "Tertiary Exec Control", 0, opt,
@@ -1121,7 +1122,8 @@ static int construct_vmcs(struct vcpu *v
         v->arch.hvm.vmx.exec_control |= CPU_BASED_RDTSC_EXITING;
 
     v->arch.hvm.vmx.secondary_exec_control = vmx_caps.secondary_exec_control;
-    v->arch.hvm.vmx.tertiary_exec_control  = vmx_caps.tertiary_exec_control;
+    v->arch.hvm.vmx.tertiary_exec_control  = vmx_caps.tertiary_exec_control &
+                                             ~TERTIARY_EXEC_ENABLE_MSRLIST;
 
     /*
      * Disable features which we don't want active by default:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -894,6 +894,20 @@ static void cf_check vmx_cpuid_policy_ch
     else
         vmx_set_msr_intercept(v, MSR_PKRS, VMX_MSR_RW);
 
+    if ( cp->feat.msrlist )
+    {
+        vmx_clear_msr_intercept(v, MSR_BARRIER, VMX_MSR_RW);
+        v->arch.hvm.vmx.tertiary_exec_control |= TERTIARY_EXEC_ENABLE_MSRLIST;
+        vmx_update_tertiary_exec_control(v);
+    }
+    else if ( v->arch.hvm.vmx.tertiary_exec_control &
+              TERTIARY_EXEC_ENABLE_MSRLIST )
+    {
+        vmx_set_msr_intercept(v, MSR_BARRIER, VMX_MSR_RW);
+        v->arch.hvm.vmx.tertiary_exec_control &= ~TERTIARY_EXEC_ENABLE_MSRLIST;
+        vmx_update_tertiary_exec_control(v);
+    }
+
  out:
     vmx_vmcs_exit(v);
 
@@ -3846,6 +3860,22 @@ gp_fault:
     return X86EMUL_EXCEPTION;
 }
 
+static bool cf_check is_msrlist(
+    const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt)
+{
+
+    if ( ctxt->opcode == X86EMUL_OPC(0x0f, 0x01) )
+    {
+        unsigned int rm, reg;
+        int mode = x86_insn_modrm(state, &rm, &reg);
+
+        /* This also includes WRMSRNS; should be okay. */
+        return mode == 3 && rm == 6 && !reg;
+    }
+
+    return false;
+}
+
 static void vmx_do_extint(struct cpu_user_regs *regs)
 {
     unsigned long vector;
@@ -4656,6 +4686,17 @@ void asmlinkage vmx_vmexit_handler(struc
         }
         break;
 
+    case EXIT_REASON_RDMSRLIST:
+    case EXIT_REASON_WRMSRLIST:
+        if ( vmx_guest_x86_mode(v) != 8 || !currd->arch.cpuid->feat.msrlist )
+        {
+            ASSERT_UNREACHABLE();
+            hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
+        }
+        else if ( !hvm_emulate_one_insn(is_msrlist, "MSR list") )
+            hvm_inject_hw_exception(X86_EXC_GP, 0);
+        break;
+
     case EXIT_REASON_VMXOFF:
     case EXIT_REASON_VMXON:
     case EXIT_REASON_VMCLEAR:
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -275,8 +275,13 @@ void vmx_vmcs_reload(struct vcpu *v);
 #define TERTIARY_EXEC_EPT_PAGING_WRITE          BIT(2, UL)
 #define TERTIARY_EXEC_GUEST_PAGING_VERIFY       BIT(3, UL)
 #define TERTIARY_EXEC_IPI_VIRT                  BIT(4, UL)
+#define TERTIARY_EXEC_ENABLE_MSRLIST            BIT(6, UL)
 #define TERTIARY_EXEC_VIRT_SPEC_CTRL            BIT(7, UL)
 
+#define cpu_has_vmx_msrlist \
+    (IS_ENABLED(CONFIG_INTEL_VMX) && \
+     (vmx_caps.tertiary_exec_control & TERTIARY_EXEC_ENABLE_MSRLIST))
+
 #define cpu_has_vmx_virt_spec_ctrl \
      (vmx_caps.tertiary_exec_control & TERTIARY_EXEC_VIRT_SPEC_CTRL)
 
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -201,6 +201,8 @@ static inline void pi_clear_sn(struct pi
 #define EXIT_REASON_XRSTORS             64
 #define EXIT_REASON_BUS_LOCK            74
 #define EXIT_REASON_NOTIFY              75
+#define EXIT_REASON_RDMSRLIST           78
+#define EXIT_REASON_WRMSRLIST           79
 /* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
 
 /*
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -24,6 +24,8 @@
 #define  APIC_BASE_ENABLE                   (_AC(1, ULL) << 11)
 #define  APIC_BASE_ADDR_MASK                _AC(0x000ffffffffff000, ULL)
 
+#define MSR_BARRIER                         0x0000002f
+
 #define MSR_TEST_CTRL                       0x00000033
 #define  TEST_CTRL_SPLITLOCK_DETECT         (_AC(1, ULL) << 29)
 #define  TEST_CTRL_SPLITLOCK_DISABLE        (_AC(1, ULL) << 31)
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions,
 
 #ifdef CONFIG_HVM
 
-#define VMX_PERF_EXIT_REASON_SIZE 76
+#define VMX_PERF_EXIT_REASON_SIZE 80
 #define VMEXIT_NPF_PERFC 166
 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
 PERFCOUNTER_ARRAY(vmexits,              "vmexits",
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -148,6 +148,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t
     case MSR_AMD_PPIN:
         goto gp_fault;
 
+    case MSR_BARRIER:
+        if ( !cp->feat.msrlist )
+            goto gp_fault;
+        *val = 0;
+        break;
+
     case MSR_IA32_FEATURE_CONTROL:
         /*
          * Architecturally, availability of this MSR is enumerated by the
@@ -427,6 +433,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t
         uint64_t rsvd;
 
         /* Read-only */
+    case MSR_BARRIER:
     case MSR_IA32_PLATFORM_ID:
     case MSR_CORE_CAPABILITIES:
     case MSR_INTEL_CORE_THREAD_COUNT:
--- a/xen/arch/x86/x86_emulate/0f01.c
+++ b/xen/arch/x86/x86_emulate/0f01.c
@@ -11,6 +11,7 @@
 #include "private.h"
 
 #ifdef __XEN__
+#include <xen/event.h>
 #include <asm/prot-key.h>
 #endif
 
@@ -28,6 +29,7 @@ int x86emul_0f01(struct x86_emulate_stat
     switch ( s->modrm )
     {
         unsigned long base, limit, cr0, cr0w, cr4;
+        unsigned int n;
         struct segment_register sreg;
         uint64_t msr_val;
 
@@ -42,6 +44,65 @@ int x86emul_0f01(struct x86_emulate_stat
                                 ((uint64_t)regs->r(dx) << 32) | regs->eax,
                                 ctxt, true);
             goto done;
+
+        case vex_f3: /* wrmsrlist */
+            vcpu_must_have(msrlist);
+            generate_exception_if(!mode_64bit(), X86_EXC_UD);
+            generate_exception_if(!mode_ring0() || (regs->esi & 7) ||
+                                  (regs->edi & 7),
+                                  X86_EXC_GP, 0);
+            fail_if(!ops->write_msr);
+            while ( regs->r(cx) )
+            {
+                n = __builtin_ffsl(regs->r(cx)) - 1;
+                if ( (rc = ops->read(x86_seg_none, regs->r(si) + n * 8,
+                                     &msr_val, 8, ctxt)) != X86EMUL_OKAY )
+                    break;
+                generate_exception_if(msr_val != (uint32_t)msr_val,
+                                      X86_EXC_GP, 0);
+                base = msr_val;
+                if ( (rc = ops->read(x86_seg_none, regs->r(di) + n * 8,
+                                     &msr_val, 8, ctxt)) != X86EMUL_OKAY ||
+                     (rc = ops->write_msr(base, msr_val, ctxt,
+                                          true)) != X86EMUL_OKAY )
+                    break;
+                regs->r(cx) &= ~(1UL << n);
+
+#ifdef __XEN__
+                if ( regs->r(cx) && local_events_need_delivery() )
+                {
+                    rc = X86EMUL_RETRY;
+                    break;
+                }
+#endif
+            }
+            goto done;
+
+        case vex_f2: /* rdmsrlist */
+            vcpu_must_have(msrlist);
+            generate_exception_if(!mode_64bit(), X86_EXC_UD);
+            generate_exception_if(!mode_ring0() || (regs->esi & 7) ||
+                                  (regs->edi & 7),
+                                  X86_EXC_GP, 0);
+            fail_if(!ops->read_msr || !ops->write);
+            while ( regs->r(cx) )
+            {
+                n = __builtin_ffsl(regs->r(cx)) - 1;
+                if ( (rc = ops->read(x86_seg_none, regs->r(si) + n * 8,
+                                     &msr_val, 8, ctxt)) != X86EMUL_OKAY )
+                    break;
+                generate_exception_if(msr_val != (uint32_t)msr_val,
+                                      X86_EXC_GP, 0);
+                if ( (rc = ops->read_msr(msr_val, &msr_val,
+                                         ctxt)) != X86EMUL_OKAY ||
+                     (rc = ops->write(x86_seg_none, regs->r(di) + n * 8,
+                                      &msr_val, 8, ctxt)) != X86EMUL_OKAY )
+                    break;
+                regs->r(cx) &= ~(1UL << n);
+            }
+            if ( rc != X86EMUL_OKAY )
+                ctxt->regs->r(cx) = regs->r(cx);
+            goto done;
         }
         generate_exception(X86_EXC_UD);
 
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -612,6 +612,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_lkgs()        (ctxt->cpuid->feat.lkgs)
 #define vcpu_has_wrmsrns()     (ctxt->cpuid->feat.wrmsrns)
 #define vcpu_has_avx_ifma()    (ctxt->cpuid->feat.avx_ifma)
+#define vcpu_has_msrlist()     (ctxt->cpuid->feat.msrlist)
 #define vcpu_has_movrs()       (ctxt->cpuid->feat.movrs)
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
--- a/xen/arch/x86/x86_emulate/util.c
+++ b/xen/arch/x86/x86_emulate/util.c
@@ -100,6 +100,9 @@ bool cf_check x86_insn_is_mem_access(con
         break;
 
     case X86EMUL_OPC(0x0f, 0x01):
+        /* {RD,WR}MSRLIST */
+        if ( mode_64bit() && s->modrm == 0xc6 )
+            return s->vex.pfx >= vex_f3;
         /* Cover CLZERO. */
         return (s->modrm_rm & 7) == 4 && (s->modrm_reg & 7) == 7;
     }
@@ -160,7 +163,11 @@ bool cf_check x86_insn_is_mem_write(cons
         case 0xff: /* Grp5 */
             break;
 
-        case X86EMUL_OPC(0x0f, 0x01): /* CLZERO is the odd one. */
+        case X86EMUL_OPC(0x0f, 0x01):
+            /* RDMSRLIST */
+            if ( mode_64bit() && s->modrm == 0xc6 )
+                return s->vex.pfx == vex_f2;
+            /* CLZERO is another odd one. */
             return (s->modrm_rm & 7) == 4 && (s->modrm_reg & 7) == 7;
 
         default:
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -317,7 +317,7 @@ XEN_CPUFEATURE(NMI_SRC,      10*32+20) /
 XEN_CPUFEATURE(AMX_FP16,     10*32+21) /*   AMX FP16 instruction */
 XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /*A  AVX-IFMA Instructions */
 XEN_CPUFEATURE(LAM,          10*32+26) /*   Linear Address Masking */
-XEN_CPUFEATURE(MSRLIST,      10*32+27) /*   {RD,WR}MSRLIST instructions */
+XEN_CPUFEATURE(MSRLIST,      10*32+27) /*s  {RD,WR}MSRLIST instructions */
 XEN_CPUFEATURE(NO_INVD,      10*32+30) /*   INVD instruction unusable */
 XEN_CPUFEATURE(MOVRS,        10*32+31) /*a  MOV-read-shared instructions */
 
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -283,7 +283,7 @@ def crunch_numbers(state):
         # NO_LMSL indicates the absense of Long Mode Segment Limits, which
         # have been dropped in hardware.
         LM: [CX16, PCID, LAHF_LM, PAGE1GB, PKU, NO_LMSL, AMX_TILE, CMPCCXADD,
-             LKGS, MOVRS],
+             LKGS, MOVRS, MSRLIST],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:23:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:23:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383132.1626388 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXqC-0005JD-F4; Wed, 05 Aug 2026 09:23:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383132.1626388; Wed, 05 Aug 2026 09:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXqC-0005J6-Ay; Wed, 05 Aug 2026 09:23:12 +0000
Received: by outflank-mailman (input) for mailman id 1383132;
 Wed, 05 Aug 2026 09:23:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXqA-0005Im-LL
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:23:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXqA-003xnS-29
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:23:10 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7300fc-e002-0a2a0a5209dd-0a2a4504c0fc-20
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:23:10 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7300fd-b57f-0a2a45040019-d155dd2dacf7-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:23:09 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f703a9e5dso360398f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:23:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfd9f74sm7511626f8f.4.2026.08.05.02.23.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:23:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921789; x=1786526589; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=2SIGc7gedCikC6tD+F90xKM08ODZSCL6uvs5Cbn5Yv0=;
        b=HozyeeAAj38rSAgoH2Q+CArAhkYnlBpXgnTXYF63KSiYVy8xQevs6KQ3XlJPyxPj5s
         mWBkRqLeacdR/tL/3u234Ux/3q8f0+zqbXEYJnTCCwM7RDCwEKdOI+Ybr4UvXA8qCwNC
         OK9XsTkH06Sk969ZuJG6xbwiK3k7HDZQB2Q8jRwvt+TOWyHCJLHW8KrNVGr5oZLsqLu/
         BoWATxHYCOZgj5APo90dYhKXbfcorvJdpcZiPvRK/kgJHwO3qWDDmLODshl6Qn9DYtea
         FsDBHJS1llqLrv9ASiYv8l6kKu5XHJVugzm9d79cU+Dbhg0o4U7z0HI1snK2yKZpTVCl
         fxrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921789; x=1786526589;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=2SIGc7gedCikC6tD+F90xKM08ODZSCL6uvs5Cbn5Yv0=;
        b=DWj6Jjyxq0r7sOYQU+X3+WtkA9PNrsxP7K9DNTAJmXwnh4OMQrAeJ2hSxpqQS39cEm
         jM0ncbRX/UqR7iTLQx6EFa9h+BNXh3oNFberTn86croXhslBFIgSqxCcyWxFzlriCwth
         w00HGIe9aKIbhtwqjhfA/PDbFeoCNeNvmd5Z69p2N5nZcYmjiGT79sB6fL2D8HAZq7nk
         tTHOucCvkvqWXEcOw563hnIa+FPvvEJn1q4TnMPP5bK3ODvijMsHKjWgXdWmy12kYbnS
         IBVwo4225j1eyb1Vwg5dJb+aLA6SPAsdv28jhCKt/iqQ86L/eQD8CFn4uD4Q4xUbPNEL
         sGsQ==
X-Gm-Message-State: AOJu0Yy9f1490YIJu76FdnO5SaQzXzK57CyQFafu7kNhZiMIIgq8Yrvq
	0TgCTXNY100JvgnQDxIYp2Kgt9Xp81Fp/XrJc2AiRlZ93KJRHCzV6jljv9jVsT8mmxJH/MmDa/q
	SnEQpKA==
X-Gm-Gg: AR+sD10kJ7/wYwb10cNq4Vd5rD0sgM7dGiT6KOL4o4okU6ufvdGEPoOtztQ2TIdz+oW
	Gj0CqWm1L1c1qhphT6UOSVUpjfPlNu6zswYPpmTBmew6fp9iKtW3u659FrJDF74RWzKeFX1DSP4
	zB4duh15ZTVaH3Wce4tLvjb7t2tXKtt8ej1NpFDeD/PIXrfIUAuLKSdd6vlWl/rRfeH2wCcPpPM
	VzM9LmiAT42uOE+uLTnXxmZOuking0Z7OVPNCOPqGaIGLnPjVejIrDAYibIRdhSgpXVZSNnP+n5
	lrSYwMj9lc8/zqYdukP1KiGchCBJ7HfcfB1bi4eOq0T02BDiicqpFoX2fdqI3EHvyRzgUbC2WNc
	+reKCnndBYtjQ4S2JISIqFOQbfuW9NPM5ydWCS8InP/+CkByx1XLpL6UrTeDStrShOrdN3p0iPo
	CsNu6Ri8DmSbQVBByfRGY+VT9iXWOplVuCFGK5GGduV0u+lrPg37PgSEYJgpBrtvHTHupKGRLgO
	eGZD7bcEBsLa7Evh0aW7bQpmsl0yezuPcsvdDzLMa1cyvJeIDQk
X-Received: by 2002:a5d:5541:0:b0:47a:b86f:3ed1 with SMTP id ffacd0b85a97d-47fec62bacamr6533357f8f.21.1785921788871;
        Wed, 05 Aug 2026 02:23:08 -0700 (PDT)
Message-ID: <5cd53809-9762-4187-85e5-56a6a6d37a94@suse.com>
Date: Wed, 5 Aug 2026 11:23:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v10 2/6] x86emul: support USER-MSR instructions
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1785921789-C3AC0B50-3A53D68A/0/0
X-purgate-type: clean
X-purgate-size: 18726

While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).

Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 256-entry table.

In the test harness use the UINTR_TIMER MSR despite the UINTR and UTMR
features being removed from the architecture. Using UARCH_MISC_CTL would
constrain usable values overly much.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The retaining of (possible) #PF from the bitmap access is "speculative"
(the spec doesn't mention #PF as a possible exception; conceivably this
might also need converting to #GP).

I'm a little wary of the "MSRs Writeable by UWRMSR" table that the spec
has, and that our code thus also enforces: As new MSRs are added to that
table, we'll need piecemeal updates to that switch() statement.

The forced setting of cpu_policy.feat.utmr could likely be done
globally, i.e. early in main(). Limiting its scope is merely "just in
case". Thoughts?
---
v10: Use msr-index.h constants also in x86_emulate(). Re-base.
v8: Switch to using fallthrough pseudo-keyword. Re-base.
v7.1: Add MSR-specific feature checks for UWRMSR (incl the UTMR feature
      bit and its overriding in the test harness).
v7: Add missing vcpu_must_have() and override in emul_test_init(). Use
    MSR constants even more.
v6: Add MSR_UINTR_TIMER to header. Use MSR constants in test harness.
    Re-base.
v5: Correct ModR/M.reg check for VEX-encoded forms. Cosmetic test
    harness adjustment. Re-base.
v4: MSR index input regs are 64-bit (albeit only the APX spec has it
    this way for now).
v3: New.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -867,7 +867,9 @@ static const struct {
     { { 0xf6 }, { 2, 2 }, T, R, pfx_66 }, /* adcx */
     { { 0xf6 }, { 2, 2 }, T, R, pfx_f3 }, /* adox */
     { { 0xf8 }, { 2, 2 }, F, W, pfx_66 }, /* movdir64b */
+    { { 0xf8, 0xc0 }, { 0, 2 }, F, N, pfx_f3 }, /* uwrmsr */
     { { 0xf8 }, { 2, 2 }, F, W, pfx_f3 }, /* enqcmds */
+    { { 0xf8, 0xc0 }, { 0, 2 }, F, N, pfx_f2 }, /* urdmsr */
     { { 0xf8 }, { 2, 2 }, F, W, pfx_f2 }, /* enqcmd */
     { { 0xf9 }, { 2, 2 }, F, W }, /* movdiri */
 };
@@ -1519,6 +1521,9 @@ static const struct vex {
     { { 0xde }, 3, T, R, pfx_66, W0, L0 }, /* vsm3rnds2 */
     { { 0xdf }, 3, T, R, pfx_66, WIG, Ln }, /* vaeskeygenassist */
     { { 0xf0 }, 3, T, R, pfx_f2, Wn, L0 }, /* rorx */
+}, vex_map7[] = {
+    { { 0xf8, 0xc0 }, 6, F, N, pfx_f3, W0, L0 }, /* uwrmsr */
+    { { 0xf8, 0xc0 }, 6, F, N, pfx_f2, W0, L0 }, /* urdmsr */
 };
 
 static const struct {
@@ -1528,6 +1533,10 @@ static const struct {
     { vex_0f,   ARRAY_SIZE(vex_0f) },
     { vex_0f38, ARRAY_SIZE(vex_0f38) },
     { vex_0f3a, ARRAY_SIZE(vex_0f3a) },
+    { NULL,     0 }, /* map 4 */
+    { NULL,     0 }, /* map 5 */
+    { NULL,     0 }, /* map 6 */
+    { vex_map7, ARRAY_SIZE(vex_map7) },
 };
 
 static const struct xop {
@@ -2426,7 +2435,8 @@ void predicates_test(void *instr, struct
 
                 if ( vex[x].tbl[t].w == WIG || (vex[x].tbl[t].w & W0) )
                 {
-                    memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                    memcpy(ptr, vex[x].tbl[t].opc,
+                           MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L0) )
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
@@ -2436,7 +2446,8 @@ void predicates_test(void *instr, struct
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L1) )
                     {
                         ptr[-1] |= 4;
-                        memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                        memcpy(ptr, vex[x].tbl[t].opc,
+                               MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
                                 vex[x].tbl[t].modrm ? (void *)ptr - instr + 1 : 0,
@@ -2447,7 +2458,8 @@ void predicates_test(void *instr, struct
                 if ( vex[x].tbl[t].w == WIG || (vex[x].tbl[t].w & W1) )
                 {
                     ptr[-1] = 0xf8 | vex[x].tbl[t].pfx;
-                    memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                    memcpy(ptr, vex[x].tbl[t].opc,
+                           MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L0) )
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
@@ -2457,7 +2469,8 @@ void predicates_test(void *instr, struct
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L1) )
                     {
                         ptr[-1] |= 4;
-                        memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                        memcpy(ptr, vex[x].tbl[t].opc,
+                               MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
                                 vex[x].tbl[t].modrm ? (void *)ptr - instr + 1 : 0,
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -675,6 +675,7 @@ static int blk(
 
 #ifdef __x86_64__
 static unsigned long gs_base, gs_base_shadow;
+static unsigned long uintr_timer;
 #endif
 
 static int read_segment(
@@ -704,6 +705,15 @@ static int write_segment(
 
     return X86EMUL_OKAY;
 }
+
+static const uint8_t __attribute__((aligned(0x1000))) umsr_bitmap[0x1000] = {
+#define RD(msr) [(msr) >> 3] = 1 << ((msr) & 7)
+#define WR(msr) [0x800 + ((msr) >> 3)] = 1 << ((msr) & 7)
+    RD(MSR_IA32_APERF),
+    WR(MSR_UINTR_TIMER),
+#undef WR
+#undef RD
+};
 #endif
 
 static int read_msr(
@@ -713,10 +723,22 @@ static int read_msr(
 {
     switch ( reg )
     {
+#ifdef __x86_64__
+    case MSR_USER_MSR_CTL:
+        *val = (unsigned long)umsr_bitmap | 1;
+        return X86EMUL_OKAY;
+#endif
+
     case MSR_BARRIER:
         *val = 0;
         return X86EMUL_OKAY;
 
+    case MSR_IA32_APERF:
+#define APERF_LO_VALUE 0xAEAEAEAE
+#define APERF_HI_VALUE 0xEAEAEAEA
+        *val = ((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE;
+        return X86EMUL_OKAY;
+
     case MSR_EFER:
         *val = ctxt->addr_size > 32 ? EFER_LME | EFER_LMA : 0;
         return X86EMUL_OKAY;
@@ -753,6 +775,12 @@ static int write_msr(
 {
     switch ( reg )
     {
+    case MSR_UINTR_TIMER:
+        if ( ctxt->addr_size < 64 )
+            break;
+        uintr_timer = val;
+        return X86EMUL_OKAY;
+
     case MSR_GS_BASE:
         if ( ctxt->addr_size < 64 || !is_canonical_address(val) )
             break;
@@ -1481,6 +1509,68 @@ int main(int argc, char **argv)
          (gs_base != 0x0000222244446666UL) ||
          (gs_base_shadow != 0x0000111122224444UL) )
         goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing urdmsr %rdx,%rcx...");
+    instr[0] = 0xf2; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8; instr[4] = 0xd1;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rdx = MSR_IA32_APERF;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[5]) ||
+         (regs.rcx != (((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE)) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing urdmsr $MSR_IA32_APERF,%rdx...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7b; instr[3] = 0xf8; instr[4] = 0xc2;
+    *(uint32_t *)&instr[5] = MSR_IA32_APERF;
+    regs.rip = (unsigned long)&instr[0];
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (regs.rdx != (((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE)) )
+        goto fail;
+    printf("okay\n");
+
+    /* Our write_msr() knows of MSR_UINTR_TIMER. */
+    i = cpu_policy.feat.utmr;
+    cpu_policy.feat.utmr = true;
+
+    printf("%-40s", "Testing uwrmsr %rdi,%rsi...");
+    instr[0] = 0xf3; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8; instr[4] = 0xf7;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = MSR_UINTR_TIMER;
+    regs.rdi = 0x0011223344556677UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[5]) ||
+         (uintr_timer != 0x0011223344556677UL) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing uwrmsr %rsi,$MSR_UINTR_TIMER...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7a; instr[3] = 0xf8; instr[4] = 0xc6;
+    *(uint32_t *)&instr[5] = MSR_UINTR_TIMER;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = 0x8877665544332211UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (uintr_timer != 0x8877665544332211UL) )
+        goto fail;
+    printf("okay\n");
+
+    cpu_policy.feat.utmr = i;
+
+    printf("%-40s", "Testing uwrmsr %rsi,$MSR_UARCH_MISC_CTRL...");
+    *(uint32_t *)&instr[5] = MSR_UARCH_MISC_CTRL;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = 0;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_EXCEPTION) ||
+         (regs.rip != (unsigned long)&instr[0]) )
+        goto fail;
 
     emulops.write_msr     = NULL;
 #endif
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -67,6 +67,7 @@ bool emul_test_init(void)
     cpu_policy.feat.lkgs = true;
     cpu_policy.feat.wrmsrns = true;
     cpu_policy.feat.msrlist = true;
+    cpu_policy.feat.user_msr = true;
     cpu_policy.extd.clzero = true;
 
     if ( cpu_has_xsave )
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -24,6 +24,10 @@
 #define  APIC_BASE_ENABLE                   (_AC(1, ULL) << 11)
 #define  APIC_BASE_ADDR_MASK                _AC(0x000ffffffffff000, ULL)
 
+#define MSR_USER_MSR_CTL                    0x0000001c
+#define  USER_MSR_ENABLE                    (_AC(1, ULL) <<  0)
+#define  USER_MSR_ADDR_MASK                 0xfffffffffffff000ULL
+
 #define MSR_BARRIER                         0x0000002f
 
 #define MSR_TEST_CTRL                       0x00000033
@@ -209,6 +213,8 @@
 #define  MCU_CONTROL_DIS_MCU_LOAD           (_AC(1, ULL) <<  1)
 #define  MCU_CONTROL_EN_SMM_BYPASS          (_AC(1, ULL) <<  2)
 
+#define MSR_UINTR_TIMER                     0x00001b00
+
 #define MSR_UARCH_MISC_CTRL                 0x00001b01
 #define  UARCH_CTRL_DOITM                   (_AC(1, ULL) <<  0)
 
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -905,7 +905,7 @@ decode_0f38(struct x86_emulate_state *s,
     case 0x00 ... 0x89:
     case 0x8c ... 0xef:
     case 0xf2 ... 0xf5:
-    case 0xf7 ... 0xf8:
+    case 0xf7:
     case 0xfa ... 0xff:
         s->op_bytes = 0;
         /* fall through */
@@ -957,6 +957,18 @@ decode_0f38(struct x86_emulate_state *s,
     case X86EMUL_OPC_VEX_F2(0, 0xf7): /* shrx */
         break;
 
+    case 0xf8:
+        if ( s->modrm_mod == 3 ) /* u{rd,wr}msr */
+        {
+            s->desc = DstMem | SrcReg | Mov;
+            s->op_bytes = 8;
+            s->simd_size = simd_none;
+        }
+        else /* movdir64b / enqcmd{,s} */
+            s->op_bytes = 0;
+        ctxt->opcode |= MASK_INSR(s->vex.pfx, X86EMUL_OPC_PFX_MASK);
+        break;
+
     default:
         s->op_bytes = 0;
         break;
@@ -1255,6 +1267,16 @@ int x86emul_decode(struct x86_emulate_st
                          */
                         d = twobyte_table[0x38].desc;
                         break;
+
+                    case vex_map7:
+                        opcode |= MASK_INSR(7, X86EMUL_OPC_EXT_MASK);
+                        /*
+                         * No table lookup here for now, as there's only a single
+                         * opcode point (0xf8) populated in map 7.
+                         */
+                        d = DstMem | SrcImm | ModRM | Mov;
+                        s->op_bytes = 8;
+                        break;
                     }
                 }
                 else if ( s->ext < ext_8f08 + ARRAY_SIZE(xop_table) )
@@ -1611,6 +1633,7 @@ int x86emul_decode(struct x86_emulate_st
             s->simd_size = ext8f09_table[b].simd_size;
             break;
 
+        case ext_map7:
         case ext_8f08:
         case ext_8f0a:
             /*
@@ -1825,6 +1848,7 @@ int x86emul_decode(struct x86_emulate_st
 
     case ext_map5:
     case ext_map6:
+    case ext_map7:
     case ext_8f09:
     case ext_8f0a:
         break;
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -202,6 +202,7 @@ enum vex_opcx {
     vex_0f3a,
     evex_map5 = 5,
     evex_map6,
+    vex_map7,
 };
 
 enum vex_pfx {
@@ -259,6 +260,7 @@ struct x86_emulate_state {
         ext_0f3a = vex_0f3a,
         ext_map5 = evex_map5,
         ext_map6 = evex_map6,
+        ext_map7 = vex_map7,
         /*
          * For XOP use values such that the respective instruction field
          * can be used without adjustment.
@@ -617,6 +619,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
+#define vcpu_has_user_msr()    (ctxt->cpuid->feat.user_msr)
 
 #define vcpu_must_have(feat) \
     generate_exception_if(!vcpu_has_##feat(), X86_EXC_UD)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7086,10 +7086,74 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
-    case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 */
-    case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 */
+    case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 / uwrmsr r64,r32 */
+    case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 / urdmsr r32,r64 */
+        if ( ea.type == OP_MEM )
+            goto enqcmd;
+        imm1 = src.val;
+        fallthrough;
+    case X86EMUL_OPC_VEX_F3(7, 0xf8): /* uwrmsr r64,imm32 */
+    case X86EMUL_OPC_VEX_F2(7, 0xf8): /* urdmsr imm32,r64 */
+        generate_exception_if(!mode_64bit() || ea.type != OP_REG, X86_EXC_UD);
+        generate_exception_if(vex.l || vex.w, X86_EXC_UD);
+        generate_exception_if(vex.opcx && ((modrm_reg & 7) || vex.reg != 0xf),
+                              X86_EXC_UD);
+        vcpu_must_have(user_msr);
+        fail_if(!ops->read_msr);
+        if ( ops->read_msr(MSR_USER_MSR_CTL, &msr_val, ctxt) != X86EMUL_OKAY )
+        {
+            x86_emul_reset_event(ctxt);
+            msr_val = 0;
+        }
+        generate_exception_if(!(msr_val & USER_MSR_ENABLE), X86_EXC_UD);
+        generate_exception_if(imm1 & ~0x3fff, X86_EXC_GP, 0);
+
+        /* Check the corresponding bitmap. */
+        ea.mem.off = msr_val & ~0xfff;
+        if ( vex.pfx != vex_f2 )
+            ea.mem.off += 0x800;
+        ea.mem.off += imm1 >> 3;
+        if ( (rc = ops->read(x86_seg_sys, ea.mem.off, &b, 1,
+                             ctxt)) != X86EMUL_OKAY )
+            goto done;
+        generate_exception_if(!(b & (1 << (imm1 & 7))), X86_EXC_GP, 0);
+
+        /* Carry out the actual MSR access. */
+        if ( vex.pfx == vex_f2 )
+        {
+            /* urdmsr */
+            if ( (rc = ops->read_msr(imm1, &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.val = msr_val;
+            ASSERT(dst.type == OP_REG);
+            dst.bytes = 8;
+        }
+        else
+        {
+            /* uwrmsr */
+            switch ( imm1 )
+            {
+            case MSR_UINTR_TIMER:
+                generate_exception_if(!cp->feat.utmr, X86_EXC_GP, 0);
+                break;
+
+            case MSR_UARCH_MISC_CTRL:
+                generate_exception_if(!cp->arch_caps.doitm, X86_EXC_GP, 0);
+                break;
+
+            default:
+                generate_exception(X86_EXC_GP, 0);
+            }
+            fail_if(!ops->write_msr);
+            if ( (rc = ops->write_msr(imm1, dst.val, ctxt,
+                                      true)) != X86EMUL_OKAY )
+                goto done;
+            dst.type = OP_NONE;
+        }
+        break;
+
+    enqcmd:
         vcpu_must_have(enqcmd);
-        generate_exception_if(ea.type != OP_MEM, X86_EXC_UD);
         generate_exception_if(vex.pfx != vex_f2 && !mode_ring0(), X86_EXC_GP, 0);
         src.val = truncate_ea(*dst.reg);
         generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -360,7 +360,9 @@ XEN_CPUFEATURE(AVX_VNNI_INT8,      15*32
 XEN_CPUFEATURE(AVX_NE_CONVERT,     15*32+ 5) /*A  AVX-NE-CONVERT Instructions */
 XEN_CPUFEATURE(AMX_COMPLEX,        15*32+ 8) /*   AMX Complex Instructions */
 XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
+XEN_CPUFEATURE(UTMR,               15*32+13) /*   User Timer */
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
+XEN_CPUFEATURE(USER_MSR,           15*32+15) /*   U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(UIRET_UIF,          15*32+17) /*   UIRET updates UIF */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
 XEN_CPUFEATURE(SLSM,               15*32+24) /*   Static Lockstep Mode */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -283,7 +283,7 @@ def crunch_numbers(state):
         # NO_LMSL indicates the absense of Long Mode Segment Limits, which
         # have been dropped in hardware.
         LM: [CX16, PCID, LAHF_LM, PAGE1GB, PKU, NO_LMSL, AMX_TILE, CMPCCXADD,
-             LKGS, MOVRS, MSRLIST],
+             LKGS, MOVRS, MSRLIST, USER_MSR],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:23:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:23:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383136.1626396 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXqU-0005kG-LC; Wed, 05 Aug 2026 09:23:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383136.1626396; Wed, 05 Aug 2026 09:23:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXqU-0005k8-Hl; Wed, 05 Aug 2026 09:23:30 +0000
Received: by outflank-mailman (input) for mailman id 1383136;
 Wed, 05 Aug 2026 09:23:29 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXqT-0005iN-AD
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:23:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXqS-00HWZS-N8
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:23:28 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730109-5cb7-0a2a0a5109dd-0a2a4505dd44-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:23:28 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730110-4cb1-0a2a45050019-d1558034a518-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:23:28 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-495437bb891so7358885e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:23:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfd9f74sm7513106f8f.4.2026.08.05.02.23.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:23:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921808; x=1786526608; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=jQFpsonGz2MRoYUli6F1ue9CHvjmUgngklOxuIXC4is=;
        b=GhHNJ/0eAhELRPNZoQGm69d1qPcI2ZValB7n3/xOURDlbD5nwTLA+iCEG28F3RoDxO
         fn2kwzl7+CBt7wRPnAJ9gsG3JLILLIz9cJ2x4nlqwWAs2mH0mg35FbhPe63xclTmEgsO
         d25cMTpj+9ktimI+N18Gep6hmZ5qjDzk5NeqPeRHXyABwuvtzRDBmADQdqUjTmAWLkLi
         qur1U9RmXBvv20GkawlfTGC8tCbuhdKAzTWQF65VCp+pV/vrJ+b/bavgWc/grPWviVu0
         RYSPA3tGKj2zEsIaegG86CgT/zkDpR+Rs2O6GZYzq6EPRUl0584S6BrcjUYW9qNbgkq5
         NIZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921808; x=1786526608;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=jQFpsonGz2MRoYUli6F1ue9CHvjmUgngklOxuIXC4is=;
        b=JimxecVc3J+r6dA8HJfSkS0JILau3yj5KYaWm4iAz+ux2cwP43V9knCS7VfBU5K3gN
         AiQGK4JBwj4P6UPFfRntwx5qJw1j7/u237ULuc4o+XJCssgWB8rhYpDit+Wy3HKZjo4b
         fbCz1aMHCCIebyAnrM1EYsP7URMFBE+cSHeowONMkEXcHG70xMX9YMgIgBEWH16QVzTs
         HJI7/mX29uqKKNA7iX7iTTiQW3/jmZjocw6b4MXOobQ06hGZKvtnjN1cdy95hp0nIhiv
         JIqqpP51AgErEIjWLeJcCefrNRiqTa/C7xBHKFWccT8rMUfjDjIeS+Swq9T3huGzUYCZ
         9ANw==
X-Gm-Message-State: AOJu0Yz4tEgiak8lRvV6FEb6H9d86yea66tatBSqq9zz9svTgkk2kxtY
	SL2Mx26GEtoJbMKEP6WWxNfEEp/NQsQJ6D5pXUDnMEwjVl1/W97VSVf7SKDsVnCmbdXWlis0Xlh
	efkFfUg==
X-Gm-Gg: AR+sD11Ys2AZvuD0yIr2200ilccmKItrFG3Q9UAzZdCUK3qf6AL9MUtpaWcYLDxmCEz
	vRyq4m4VMFAs/AdFGW12T6bJghrHZrgJvdpSIGeMkw/aOmS0Q1ege9Mec8HinqJmK2rE+uTAe+N
	xvMXkjKOd3OGbg1xEzPibCatJccsR8d0Dxwq7j6piX6/o0PlNQxxF1eUTiwxGYp3YDcYOCT5OEQ
	/3kuw83aCHOOTM6mmQ2Ndpu2IupVg2afdB4CCu6rWRgmnV8hfbfer4/q2KAxLSaNvUkj6yMyveP
	WPlPsJZsmZMpnIZbpOMQ6qfnwfJeS5sCW57MmOP7lxB0FVG9r2cNu/oE2XQDIIdLtchKldkMg3U
	t493L7bVVe0LhIdTxER7HeMj1tQFULQ5HuVFcCtnFUiq4m91B0f/DvJ9QDpcZvRKjWMSancpH4i
	vJh6goXLDItLjFMMKlVKvWPQX3DBGqJfx2XHxTdTUy/wRSwNtleFCXH0JfLnujpUpSRBuBvn9PX
	osrQRll+GjHN1FIR7p9dnDzFTtdfVOic2bmKyjTaGT6IwGcHwKb
X-Received: by 2002:a7b:ce81:0:b0:495:41ea:f6e with SMTP id 5b1f17b1804b1-4994a107e2amr161122715e9.8.1785921807917;
        Wed, 05 Aug 2026 02:23:27 -0700 (PDT)
Message-ID: <fc503da1-85ec-45d7-8e8a-b06c3f78d3c7@suse.com>
Date: Wed, 5 Aug 2026 11:23:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v10 3/6] x86/cpu-policy: re-arrange no-VMX logic
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1785921808-F54AC2A1-E5632010/0/0
X-purgate-type: clean
X-purgate-size: 1478

Move the PKS check into an "else" for the corresponding "if()", such
that further adjustments (like for USER_MSR) can easily be put there as
well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v5: Re-base.
v4: New.

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -823,19 +823,20 @@ static void __init calculate_hvm_max_pol
         if ( !cpu_has_vmx_xsaves )
             __clear_bit(X86_FEATURE_XSAVES, fs);
     }
+    else
+    {
+        /*
+         * Xen doesn't use PKS, so the guest support for it has opted to not use
+         * the VMCS load/save controls for efficiency reasons.  This depends on
+         * the exact vmentry/exit behaviour, so don't expose PKS in other
+         * situations until someone has cross-checked the behaviour for safety.
+         */
+        __clear_bit(X86_FEATURE_PKS, fs);
+    }
 
     if ( !cpu_has_vmx_msrlist )
         __clear_bit(X86_FEATURE_MSRLIST, fs);
 
-    /*
-     * Xen doesn't use PKS, so the guest support for it has opted to not use
-     * the VMCS load/save controls for efficiency reasons.  This depends on
-     * the exact vmentry/exit behaviour, so don't expose PKS in other
-     * situations until someone has cross-checked the behaviour for safety.
-     */
-    if ( !cpu_has_vmx )
-        __clear_bit(X86_FEATURE_PKS, fs);
-
     /* 
      * Make adjustments to possible (nested) virtualization features exposed
      * to the guest



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:24:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:24:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383150.1626404 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXrB-0006Mj-0z; Wed, 05 Aug 2026 09:24:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383150.1626404; Wed, 05 Aug 2026 09:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXrA-0006Mc-UX; Wed, 05 Aug 2026 09:24:12 +0000
Received: by outflank-mailman (input) for mailman id 1383150;
 Wed, 05 Aug 2026 09:24:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXr9-0006MK-RU
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:24:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXr9-00Bfeu-4Y
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:24:11 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730139-5cb7-0a2a0a5109dd-0a2a4502e53e-6
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:24: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 <jbeulich@suse.com>)
 id 6a73013a-6ca4-0a2a45020019-d155dd30e1ba-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:24:11 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so541686f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:24:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfd9f74sm7517005f8f.4.2026.08.05.02.24.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:24:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921850; x=1786526650; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=/Igknh5+Nb88vcTcf1O5GexgYDuFGQ/RpiAXNqKISPo=;
        b=edu+C/cPcctMr8EOIquuOT/3qc4Dm9rn7aFRGcQNgaMwrohxGGr7LycEakeq6CypCe
         Jg2OzyGJh8z1TyQCNcur7/chqzwKKamffuEgShV3zb38tUAclh6Ea6PYs+yroI6AjYOO
         YkYuszLvWcVJm8cbY1LzgBWUhrQ6Oiz41jcV3nTCtowIxOKjjd3sc8DKybxgdcQ6YoH+
         CfCpa6tklkQZf9ZORP2sq3/53APyHji0hINyAHMx48Sm+gDpKKRGhx52+JprADoLEc8C
         hmzxz6ArSuCv/FUR+f6x1xGUI0dkX+jOaxWPznuC/AmMRFd1X53x/0pphIzA8r5SShfh
         aOPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921850; x=1786526650;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=/Igknh5+Nb88vcTcf1O5GexgYDuFGQ/RpiAXNqKISPo=;
        b=sFHVGdM4uuODDwwvQbuyjv6tdIpW8qsohanIeQLcIWCCT5AaOCycaO6MMZ9ED9b6Bb
         r9aLdgBBnprlUE3zhZSNVThBe7NvQuzyG6eN8xgeCDGSja5J/oswMeHoAttd5TY3Avp8
         +EMk9HZzUvUl2nL0u7tr1DKcb+6n8pC4cjdylm2SA76LwuSdAd2w0JW4hs6fhgCICGVJ
         5k+UvWSUDvWZ3Vgjw8rGXo7ao53onhw/w86xAq6WEwAWeYgGbhaujet44cWoY+BMzpnx
         yjyTaT0HlxyV02XBzx6oonvfL2xLBHFjmxtKumw4gumD+5Mab6kxO4tX8YrXUc+uLwyM
         WRkQ==
X-Gm-Message-State: AOJu0YyN79vTOlKqpMnWM9P1Uihhni1rnwYW6XEwCi4EzY5+Dj6CptyL
	2yoQrOZkjISZ3tpwODDOwyzzc6LSMOKX2ARvbAsgXMKtBGGPNnOixAizsWJk0GP1anQL3qJFcEG
	i0jJ8kA==
X-Gm-Gg: AR+sD12V+PZaXNWX1xZY1NdZc9cAn972CCcTJYd6WJAh5izrJYVbHvOlFfrBmfrvjop
	OZNLPAKS38ozasf+0ouSV7oDk3nkzVTvl0nJkr18vEbyfHhJ+UyfB4VhSkQE5wclFv+DAauoXi7
	VY8N4x6Zzv7gBw70KRHDJGUUoi9ksG83HtAx+9Dw4dqSaysW9E1uItRUtR7UW1hO1wkskIHy4yl
	YW6RfjUvI+bYcIg1aLEMBgG9bAOmeVxyNgKxZ9VXQyDvUdwt6xcRJ/tPlaSOAjGrqj/8sP+jHSf
	8AIhivHJgELWv3mbD5YY969tDe0r6WHIIkAyfcGALyXf62Q7+aFxZIGfQSyYtYP8vCd0QCLJAnP
	Ff98efXVOoDmCz0NQcymf5ydT4bfHBxwOUwTGWVHeAzkEX7qO0DbGACHJpMnIic5tiSTkWRqkBF
	vyZG2k0Fpoyezk+FEQQ6rUB6qKDXw86VO0td4Emaf4zaCsQzWtjfjSY6ujJ7UeIBQyhTWpNydW/
	aSzRZzZUIar/1TCCDWNtKM9mBv+OIekCvPzE+5Lk1NbdDTMx5XgdL1ZlJtgWds=
X-Received: by 2002:adf:e992:0:b0:47f:c648:e280 with SMTP id ffacd0b85a97d-47fec519539mr7084576f8f.18.1785921850450;
        Wed, 05 Aug 2026 02:24:10 -0700 (PDT)
Message-ID: <87a7505c-4883-48b7-9bc0-60444b9b6b05@suse.com>
Date: Wed, 5 Aug 2026 11:24:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v10 4/6] VMX: support USER-MSR
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1785921851-674BE2AC-85FAD874/0/0
X-purgate-type: clean
X-purgate-size: 10566

Hook up the new VM exit codes and handle guest accesses, context switch,
and save/restore. At least for now don't allow the guest direct access
to the control MSR; this may need changing if guests were to frequently
access it (e.g. on their own context switch path).

While there also correct a one-off in union ldt_or_tr_instr_info's
comment.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Needing to change two places in hvm.c continues to be unhelpful; I
recall I already did forget to also adjust hvm_load_cpu_msrs() for XFD.
Considering that MSRs typically arrive in the order the table has it,
couldn't we incrementally look up the incoming MSR index there, falling
back to a full lookup only when the incremental lookup failed (and thus
not normally re-iterating through the initial part of the array)?

Said comment in union ldt_or_tr_instr_info is further odd (same for
union gdt_or_idt_instr_info's) in that Instruction Information is only a
32-bit field. Hence bits 32-63 aren't undefined, but simply don't exist.

RFC: The wee attempt to "deal" with nested is likely wrong, but I'm
     afraid I simply don't know where such enforcement would be done
     properly. Returning an error there is also commented out, for
     domain_cpu_policy_changed() returning void without "x86/xstate:
     re-size save area when CPUID policy changes" in place.
---
v10: Replace __vmread() by vmread(). Add commentsto case labels in
     vmx_vmexit_handler(). Re-base.
v9: Use wrmsrns(). Do renames where bits are also going to be used for
    MSR-IMM. Re-base.
v8: Re-base.
v5: Introduce user_msr_gpr().
v4: New.

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -832,6 +832,12 @@ static void __init calculate_hvm_max_pol
          * situations until someone has cross-checked the behaviour for safety.
          */
         __clear_bit(X86_FEATURE_PKS, fs);
+
+        /*
+         * Don't expose USER-MSR until it is known how (if at all) it is
+         * virtualized on SVM.
+         */
+        __clear_bit(X86_FEATURE_USER_MSR, fs);
     }
 
     if ( !cpu_has_vmx_msrlist )
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -452,6 +452,10 @@ void domain_cpu_policy_changed(struct do
         }
     }
 
+    /* Nested doesn't have the necessary processing, yet. */
+    if ( nestedhvm_enabled(d) && p->feat.user_msr )
+        return /* -EINVAL */;
+
     for_each_vcpu ( d, v )
     {
         cpu_policy_updated(v);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1393,6 +1393,7 @@ static int cf_check hvm_load_cpu_xsave_s
 
 #define HVM_CPU_MSR_SIZE(cnt) offsetof(struct hvm_msr, msr[cnt])
 static const uint32_t msrs_to_send[] = {
+    MSR_USER_MSR_CTL,
     MSR_SPEC_CTRL,
     MSR_INTEL_MISC_FEATURES_ENABLES,
     MSR_PKRS,
@@ -1547,6 +1548,7 @@ static int cf_check hvm_load_cpu_msrs(st
         {
             int rc;
 
+        case MSR_USER_MSR_CTL:
         case MSR_SPEC_CTRL:
         case MSR_INTEL_MISC_FEATURES_ENABLES:
         case MSR_PKRS:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -696,13 +696,18 @@ static void cf_check vmx_vcpu_destroy(st
 }
 
 /*
- * To avoid MSR save/restore at every VM exit/entry time, we restore
- * the x86_64 specific MSRs at domain switch time. Since these MSRs
- * are not modified once set for para domains, we don't save them,
- * but simply reset them to values set in percpu_traps_init().
+ * To avoid MSR save/restore at every VM exit/entry time, we restore the
+ * x86_64 specific MSRs at vcpu switch time. Since these MSRs are not
+ * modified once set for para domains, we don't save them, but simply clear
+ * them or reset them to values set in percpu_traps_init().
  */
-static void vmx_restore_host_msrs(void)
+static void vmx_restore_host_msrs(const struct vcpu *v)
 {
+    const struct vcpu_msrs *msrs = v->arch.msrs;
+
+    if ( msrs->user_msr_ctl.enable )
+        wrmsrns(MSR_USER_MSR_CTL, 0);
+
     /* No PV guests?  No need to restore host SYSCALL infrastructure. */
     if ( !IS_ENABLED(CONFIG_PV) )
         return;
@@ -760,6 +765,9 @@ static void vmx_restore_guest_msrs(struc
 
     if ( cp->feat.pks )
         wrpkrs(msrs->pkrs);
+
+    if ( msrs->user_msr_ctl.enable )
+        wrmsrns(MSR_USER_MSR_CTL, msrs->user_msr_ctl.raw);
 }
 
 void vmx_update_cpu_exec_control(struct vcpu *v)
@@ -1165,7 +1173,7 @@ static void cf_check vmx_ctxt_switch_fro
     }
 
     vmx_save_guest_msrs(v);
-    vmx_restore_host_msrs();
+    vmx_restore_host_msrs(v);
     vmx_save_dr(v);
 
     if ( v->domain->arch.hvm.pi_ops.flags & PI_CSW_FROM )
@@ -4194,6 +4202,13 @@ static int vmx_handle_apic_write(void)
     return vlapic_apicv_write(current, exit_qualification & 0xfff);
 }
 
+static unsigned int msr_imm_gpr(void)
+{
+    msr_imm_instr_info_t info = { .raw = vmread(VMX_INSTRUCTION_INFO) };
+
+    return info.gpr;
+}
+
 static void undo_nmis_unblocked_by_iret(void)
 {
     unsigned long guest_info;
@@ -4697,6 +4712,41 @@ void asmlinkage vmx_vmexit_handler(struc
             hvm_inject_hw_exception(X86_EXC_GP, 0);
         break;
 
+    case EXIT_REASON_URDMSR: /* NB: User-MSR bitmap was checked by the CPU. */
+    {
+        uint64_t msr_content = 0;
+
+        switch ( hvm_msr_read_intercept(vmread(EXIT_QUALIFICATION),
+                                        &msr_content) )
+        {
+        case X86EMUL_OKAY:
+            *decode_gpr(regs, msr_imm_gpr()) = msr_content;
+            update_guest_eip(); /* Safe: URDMSR */
+            break;
+
+        case X86EMUL_EXCEPTION:
+            hvm_inject_hw_exception(X86_EXC_GP, 0);
+            break;
+        }
+        break;
+    }
+
+    case EXIT_REASON_UWRMSR: /* NB: User-MSR bitmap was checked by the CPU. */
+        exit_qualification = vmread(EXIT_QUALIFICATION);
+        switch ( hvm_msr_write_intercept(exit_qualification,
+                                         *decode_gpr(regs, msr_imm_gpr()),
+                                         true) )
+        {
+        case X86EMUL_OKAY:
+            update_guest_eip(); /* Safe: UWRMSR */
+            break;
+
+        case X86EMUL_EXCEPTION:
+            hvm_inject_hw_exception(X86_EXC_GP, 0);
+            break;
+        }
+        break;
+
     case EXIT_REASON_VMXOFF:
     case EXIT_REASON_VMXON:
     case EXIT_REASON_VMCLEAR:
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -203,6 +203,8 @@ static inline void pi_clear_sn(struct pi
 #define EXIT_REASON_NOTIFY              75
 #define EXIT_REASON_RDMSRLIST           78
 #define EXIT_REASON_WRMSRLIST           79
+#define EXIT_REASON_URDMSR              80
+#define EXIT_REASON_UWRMSR              81
 /* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
 
 /*
@@ -578,8 +580,18 @@ typedef union ldt_or_tr_instr_info {
         base_reg_invalid        :1,  /* bit 27 - Base register invalid */
         instr_identity          :1,  /* bit 28 - 0:LDT, 1:TR */
         instr_write             :1,  /* bit 29 - 0:store, 1:load */
-                                :34; /* bits 31:63 - Undefined */
+                                :34; /* bits 30:63 - Undefined */
     };
 } ldt_or_tr_instr_info_t;
 
+/* VM-Exit instruction info for URDMSR and UWRMSR */
+typedef union msr_imm_instr_info {
+    unsigned long raw;
+    struct {
+        unsigned int            :3,  /* Bits 0:2 - Undefined */
+        gpr                     :4,  /* Bits 3:6 - Source/Destination register */
+                                :25; /* bits 7:31 - Undefined */
+    };
+} msr_imm_instr_info_t;
+
 #endif /* __ASM_X86_HVM_VMX_VMX_H__ */
--- a/xen/arch/x86/include/asm/guest-msr.h
+++ b/xen/arch/x86/include/asm/guest-msr.h
@@ -8,6 +8,20 @@
 struct vcpu_msrs
 {
     /*
+     * 0x0000001c - MSR_USER_MSR_CTL
+     *
+     * Value is guest chosen, and always loaded in vcpu context.
+     */
+    union {
+        uint64_t raw;
+        struct {
+            bool enable:1;
+            unsigned int :11;
+            unsigned long bitmap:52;
+        };
+    } user_msr_ctl;
+
+    /*
      * 0x00000048 - MSR_SPEC_CTRL
      * 0xc001011f - MSR_VIRT_SPEC_CTRL (if X86_FEATURE_AMD_SSBD)
      *
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions,
 
 #ifdef CONFIG_HVM
 
-#define VMX_PERF_EXIT_REASON_SIZE 80
+#define VMX_PERF_EXIT_REASON_SIZE 82
 #define VMEXIT_NPF_PERFC 166
 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
 PERFCOUNTER_ARRAY(vmexits,              "vmexits",
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -278,6 +278,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t
         *val = msrs->xss.raw;
         break;
 
+    case MSR_USER_MSR_CTL:
+        if ( !cp->feat.user_msr )
+            goto gp_fault;
+        *val = msrs->user_msr_ctl.raw;
+        break;
+
     case 0x40000000 ... 0x400001ff:
         if ( is_viridian_domain(d) )
         {
@@ -616,6 +622,19 @@ int guest_wrmsr(struct vcpu *v, uint32_t
         msrs->xss.raw = val;
         break;
 
+    case MSR_USER_MSR_CTL:
+        if ( !cp->feat.user_msr )
+            goto gp_fault;
+
+        if ( (val & ~(USER_MSR_ENABLE | USER_MSR_ADDR_MASK)) ||
+             !is_canonical_address(val) )
+            goto gp_fault;
+
+        msrs->user_msr_ctl.raw = val;
+        if ( v == curr )
+            wrmsrns(MSR_USER_MSR_CTL, val);
+        break;
+
     case 0x40000000 ... 0x400001ff:
         if ( is_viridian_domain(d) )
         {
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -362,7 +362,7 @@ XEN_CPUFEATURE(AMX_COMPLEX,        15*32
 XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
 XEN_CPUFEATURE(UTMR,               15*32+13) /*   User Timer */
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
-XEN_CPUFEATURE(USER_MSR,           15*32+15) /*   U{RD,WR}MSR Instructions */
+XEN_CPUFEATURE(USER_MSR,           15*32+15) /*s  U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(UIRET_UIF,          15*32+17) /*   UIRET updates UIF */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
 XEN_CPUFEATURE(SLSM,               15*32+24) /*   Static Lockstep Mode */



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:24:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:24:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383155.1626414 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXrW-0006ou-90; Wed, 05 Aug 2026 09:24:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383155.1626414; Wed, 05 Aug 2026 09:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXrW-0006on-69; Wed, 05 Aug 2026 09:24:34 +0000
Received: by outflank-mailman (input) for mailman id 1383155;
 Wed, 05 Aug 2026 09:24:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXrV-0006oU-HA
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:24:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXrU-00HWng-U1
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:24:32 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730150-e002-0a2a0a5209dd-0a2a450ccecc-2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:24:32 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730150-f479-0a2a450c0019-d155dd31e523-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:24:32 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47fdd674e17so433959f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:24:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfe5d7csm7756543f8f.15.2026.08.05.02.24.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:24:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921872; x=1786526672; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=Yh5sgqmpsiDgmmWKbLvnKvsyVo9fXTHQYMZ46x1tb84=;
        b=S13YAMA4Sq3UqVAGo2NUs01F4Db/yaayCQ0DugXLpk+haMa9504+qCWsIghznJgp4M
         FujhkJ3xfviyKy303eOU/AKomKe9M4dOTTwEyAhAKiNPHD2PY8vgQIEJi0HiRAZ33IHL
         UWIdhE9JGICCJ0yTzVUBHKc2lYJPPv6ZUZYc2wya/Bo/aUXhKpv6ktJWXsoyoiyoXeuh
         Ts+XHVGCYUbSLIaddn3qoQCZEe6RqRUoq/7l7qOEgNLw1p4ZYw54riv1HbTh/7FwE8eY
         fZBddbzRQKYGDXNTiridvoEmLi2oFvn0auYTlU6n3epIOdHpksZol6xWIZ6awTcPNfMh
         z2YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921872; x=1786526672;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Yh5sgqmpsiDgmmWKbLvnKvsyVo9fXTHQYMZ46x1tb84=;
        b=AN6kakfyv4KtavxfME1wy4dGWQfRc4GZpNr79pCPCVaMabpubb985eIKPILf1cJMgj
         f+uKW3ajxPFSy46ErJy3wGC9xxXem8Du6lQaHAQFDGOZG40b8o66er31T4pTtlJJVyEj
         VrlDrg/M0rDp2RfpoiYgdfrvFUwuEyqklGKUk6rgP6ZWzCKETkcnK9KAhv7Ds/Z5H51n
         a7GIdMt/Z4QzV18nAwe7fMWH8MIbYreKonrW8X1sIZ0p31vs30t5LLmfWBJzYpi+AfXa
         yWxJPmDvHlU55GROOvI17VuUG6rjcbDC/EIVYP8H9MihjnZ6ArMO92de0YPHgYrg1ZhG
         1vmA==
X-Gm-Message-State: AOJu0YxCbM6Rzh1lAmfyJ0K0SB73t2rHuUFD1iX0mDfXPdurrdcbwSEc
	FTRq7Um+4PUlytHEm0TmJQaGlTAWF+uvmiSEVmavNGbQP0u72efhIzHLH5D/2p2VLPaKvKjxL7r
	nmX+QIw==
X-Gm-Gg: AR+sD13XywLOfX4kjMkV5F7lUZdZWZ9n8bOZeJwpcDOkFhdhLdM5y/d3/GQJzy3Vsb2
	9yNgQE9Kx4JH901VzU/wlQWBgsHR0JT4eNomWAUciiUUk+fFdJf9vgq/3nHDhaIFNSKJFWVahTa
	naCxex2RvtdeQOUX6MVPj5nI/LYkwWaQTvse/ygwAOoYpnva7lkKxynY4gbVizUQmK101rQW/H9
	N5j6dPVTCwfJGN09erUhQgHvEhsIu+WhmhdIX4VGbBpwgRMweRTsTPGg5UK+RELRTv1DNEYEqTD
	2OnuD7tAokHrX8bsBoNK0EhLpWMOeV4v0kLZ2I3DTBQQihLMLxsqU6txwazjroCeChBY9qVYGOx
	eVFB1ETxZCD68UYas6G2QYc+NtUuhP0eXSt7h6DpxaVHGUGU8gIIW3OaAlTZAnv4yo/X5fceq5X
	/AjIw4pvpee/JnEhYl++/Td7qojwCjAndz6jJLuw3RnWk86PzWIB5XUGDBLaWlTjAPl6qzfA64H
	lRkmLByXaxST9yBUTc0FW/teIjEVqsYtntJ/RpF6+p5U8QG9uB/
X-Received: by 2002:a05:6000:29d5:b0:47f:c648:e27b with SMTP id ffacd0b85a97d-47fec4e6fbcmr6793319f8f.2.1785921872105;
        Wed, 05 Aug 2026 02:24:32 -0700 (PDT)
Message-ID: <818b1fd4-ade7-4702-9dc6-f75fb0cfc575@suse.com>
Date: Wed, 5 Aug 2026 11:24:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v10 5/6] x86emul: support MSR-IMM instructions
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1785921872-022C0A5B-BC100AB1/0/0
X-purgate-type: clean
X-purgate-size: 6509

Encoding-wise these are very similar to URDMSR/UWRMSR, so existing logic
is easy to extend.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v10: Drop vex.opcx part of #UD check (wrongly copied from USER-MSR code).
     Re-base.
v8: Don't mark the feature 's' just yet. Re-base.
v7: New.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1522,6 +1522,8 @@ static const struct vex {
     { { 0xdf }, 3, T, R, pfx_66, WIG, Ln }, /* vaeskeygenassist */
     { { 0xf0 }, 3, T, R, pfx_f2, Wn, L0 }, /* rorx */
 }, vex_map7[] = {
+    { { 0xf6, 0xc0 }, 6, F, N, pfx_f3, W0, L0 }, /* wrmsrns */
+    { { 0xf6, 0xc0 }, 6, F, N, pfx_f2, W0, L0 }, /* rdmsr */
     { { 0xf8, 0xc0 }, 6, F, N, pfx_f3, W0, L0 }, /* uwrmsr */
     { { 0xf8, 0xc0 }, 6, F, N, pfx_f2, W0, L0 }, /* urdmsr */
 };
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1571,6 +1571,30 @@ int main(int argc, char **argv)
     if ( (rc != X86EMUL_EXCEPTION) ||
          (regs.rip != (unsigned long)&instr[0]) )
         goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing rdmsr $MSR_GS_BASE,%rdx...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7b; instr[3] = 0xf6; instr[4] = 0xc2;
+    *(uint32_t *)&instr[5] = MSR_GS_BASE;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rdx = ~gs_base;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (regs.rdx != gs_base) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing wrmsrns %rsi,$MSR_SHADOW_GS_BASE...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7a; instr[3] = 0xf6; instr[4] = 0xc6;
+    *(uint32_t *)&instr[5] = MSR_SHADOW_GS_BASE;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = 0x665544332211UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (gs_base_shadow != 0x665544332211UL) )
+        goto fail;
 
     emulops.write_msr     = NULL;
 #endif
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -67,6 +67,7 @@ bool emul_test_init(void)
     cpu_policy.feat.lkgs = true;
     cpu_policy.feat.wrmsrns = true;
     cpu_policy.feat.msrlist = true;
+    cpu_policy.feat.msr_imm = true;
     cpu_policy.feat.user_msr = true;
     cpu_policy.extd.clzero = true;
 
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -1271,8 +1271,9 @@ int x86emul_decode(struct x86_emulate_st
                     case vex_map7:
                         opcode |= MASK_INSR(7, X86EMUL_OPC_EXT_MASK);
                         /*
-                         * No table lookup here for now, as there's only a single
-                         * opcode point (0xf8) populated in map 7.
+                         * No table lookup here for now, as there are only two
+                         * (very similar) opcode points (0xf6, 0xf8) populated
+                         * in map 7.
                          */
                         d = DstMem | SrcImm | ModRM | Mov;
                         s->op_bytes = 8;
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -616,6 +616,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx_ifma()    (ctxt->cpuid->feat.avx_ifma)
 #define vcpu_has_msrlist()     (ctxt->cpuid->feat.msrlist)
 #define vcpu_has_movrs()       (ctxt->cpuid->feat.movrs)
+#define vcpu_has_msr_imm()     (ctxt->cpuid->feat.msr_imm)
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7086,6 +7086,35 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
+    case X86EMUL_OPC_VEX_F3(7, 0xf6): /* wrmsrns r64,imm32 */
+    case X86EMUL_OPC_VEX_F2(7, 0xf6): /* rdmsr imm32,r64 */
+        generate_exception_if((!mode_64bit() || ea.type != OP_REG ||
+                               (modrm_reg & 7) ||
+                               vex.l || vex.w || vex.reg != 0xf),
+                              X86_EXC_UD);
+        vcpu_must_have(msr_imm);
+        generate_exception_if(!mode_ring0(), X86_EXC_GP, 0);
+        if ( vex.pfx == vex_f2 )
+        {
+            /* urdmsr */
+            fail_if(!ops->read_msr);
+            if ( (rc = ops->read_msr(imm1, &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.val = msr_val;
+            ASSERT(dst.type == OP_REG);
+            dst.bytes = 8;
+        }
+        else
+        {
+            /* wrmsrns */
+            fail_if(!ops->write_msr);
+            if ( (rc = ops->write_msr(imm1, dst.val, ctxt,
+                                      true)) != X86EMUL_OKAY )
+                goto done;
+            dst.type = OP_NONE;
+        }
+        break;
+
     case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 / uwrmsr r64,r32 */
     case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 / urdmsr r32,r64 */
         if ( ea.type == OP_MEM )
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -354,6 +354,7 @@ XEN_CPUFEATURE(MCDT_NO,            13*32
 XEN_CPUFEATURE(UC_LOCK_DIS,        13*32+ 6) /*   UC-lock disable */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */
+XEN_CPUFEATURE(MSR_IMM,            14*32+ 5) /*   RDMSR/WRMSRNS with immediate operand */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.edx, word 15 */
 XEN_CPUFEATURE(AVX_VNNI_INT8,      15*32+ 4) /*A  AVX-VNNI-INT8 Instructions */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -283,7 +283,7 @@ def crunch_numbers(state):
         # NO_LMSL indicates the absense of Long Mode Segment Limits, which
         # have been dropped in hardware.
         LM: [CX16, PCID, LAHF_LM, PAGE1GB, PKU, NO_LMSL, AMX_TILE, CMPCCXADD,
-             LKGS, MOVRS, MSRLIST, USER_MSR],
+             LKGS, MOVRS, MSRLIST, USER_MSR, MSR_IMM],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:24:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:24:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383163.1626423 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXrs-0007Mi-Ji; Wed, 05 Aug 2026 09:24:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383163.1626423; Wed, 05 Aug 2026 09:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXrs-0007Ma-Gd; Wed, 05 Aug 2026 09:24:56 +0000
Received: by outflank-mailman (input) for mailman id 1383163;
 Wed, 05 Aug 2026 09:24:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXrq-0007Kl-Um
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:24:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXrq-006ZxT-BP
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:24:54 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a73015e-2eae-0a2a0a5409dd-0a2a450ca81c-14
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:24:54 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730166-f479-0a2a450c0019-d155dd35a468-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:24:54 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47fde295992so609364f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:24:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfda0bfsm7238538f8f.5.2026.08.05.02.24.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:24:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785921894; x=1786526694; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=0P8KtrMj33FZR9rXeuoR9W9HprP82JFkO8XpOVKL9W4=;
        b=WPTDfsHNT8Z/EIrSOINwOfKJpAGhXfcA0SpipIh8GZfrLtsW/etJkbFroeZJ8dBDvW
         h/Vj2fztfzLh5RXJOg0MwsR+OGNp2EwwWrAWOZvpUPNGGYMQws2yRfnA48I7eHtb8NmJ
         8IKiZboOeVqKIUNq0K9WqCcfTN+ExCvwjkp5qfg/ZzPlrj5l/LayeeG/llHg6uo/ibH8
         Tw0EY3r/wTea3Hyxf9zb498JktsDFq17f2InIPpCU32AhcDoGUJUCjueZf6ziCPq5bHH
         JJNsDlXH7PAvi5r5nNAau+eu28qkRzLPx58a9UhZN4DYvgjAEykx6+/YBDQQWE1D46M2
         BO+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785921894; x=1786526694;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0P8KtrMj33FZR9rXeuoR9W9HprP82JFkO8XpOVKL9W4=;
        b=MfyVl3XqwW4Q3mjlkWd0OCcL328Owe8ziRlhx14eTe/18kC8YQL8N9cJyB849k0VLz
         RF4qzBTmh3LU7bsS1Qo1klyvCUAlPbnXX5QR1THyg83IFukXiXlk/vTCyUKdOfqBFz7c
         qfdOZs//ECBUKmsZ6s9d+F7ZxeAuly6U5Qa2bMpMFYSYgdmGa2LzPwtyr4aNzXxdbIKQ
         zhphKMxq9jxvZxylDQwUd4BpqrMeHgLt0wRo+B2CY//i7Rc7kMndt/6zNguvBpDSXTz4
         iJu6MTyA9LEup1uV7uzD28BgEuCbvY14ZqcM/2gU9INkw3N9leqG5pfJ6sC9CSQ89P7g
         f1kQ==
X-Gm-Message-State: AOJu0Yw2o3zguHjSGs9XvlrTFq21LRczrE64u8x4UklDSSg+vVKTO8LQ
	tgE/UHtcdPwTfB6dumXUklLq3YjUIMxKd6R6DKDBHRVhvh8jWNb6rO5ex7w7/z2ui4FupVDD7sF
	PO/nlOA==
X-Gm-Gg: AR+sD11+z7NlHEjhl3rIYHAZd9Xbv/i2Z+xNnw6cwUhEd3JZCX7znl6Mn/EVz3MuUDm
	9IvocjZo9DeS5c4D9WlssYUDaFVhwDm3hmrB3OVoSd25mkMbH6mqoLsvl7omOeGYfCYGRxNl26f
	JK3zl+yrhTQl0yMi4amjSYGuUQdyqOR7t09LS1mHnWM3EYAmCMey+lk9mXK8LhON4Hof0OeM8+r
	gbGmXaQhns829JGLhj5yeiTicikf3Y45lGQLeHqgo2dlSONOeQEcCOJ4CfBmf+gA5cRrL9Y1Qxb
	1OESrqMohTikynF2Jr0Ql1uHnbKOyEGB5PgGxL9gFv/oFOydniId40HQmcezsy54yvBco2KnGuG
	quKcIMPUT4u0C+IooT1vTSNRSbcWc0LOnfmLNWK0Cjn+mlMeaviE8Iw8Ftk+ZGqKEMtRJkKe2xg
	YYRXjKRMNR1EHJfV8oP+Ks+b8fCOvVuPcyKcB5njM1ADIsmlgGPjY9Tt1D9pJd+7aAntjkpYeei
	1JigzF/0m7UbXNQzFWUVH8AobWMvwGN+o3Z/Zsb4toOWqNu9rSA
X-Received: by 2002:a05:6000:480f:b0:47f:8554:a341 with SMTP id ffacd0b85a97d-47fe81d131emr23983559f8f.13.1785921893765;
        Wed, 05 Aug 2026 02:24:53 -0700 (PDT)
Message-ID: <2ccead84-eaa4-428a-8684-da26874c05e9@suse.com>
Date: Wed, 5 Aug 2026 11:24:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v10 6/6] VMX: support MSR-IMM
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81a2c636-5a74-41c3-81a2-3f49ed717744@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1785921894-00ACCA5B-A4C27296/0/0
X-purgate-type: clean
X-purgate-size: 4687

Hook up the new VM exit codes and handle guest uses of the insns.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v10: Check feature bit in exit handler.
v9: New.
---
The lack of an enable bit is concerning; at least for the nested case
that's a security issue afaict (when L0 isn't aware of the insns, or more
specifically the exit codes).

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -834,10 +834,11 @@ static void __init calculate_hvm_max_pol
         __clear_bit(X86_FEATURE_PKS, fs);
 
         /*
-         * Don't expose USER-MSR until it is known how (if at all) it is
-         * virtualized on SVM.
+         * Don't expose USER-MSR and MSR-IMM until it is known how (if at all)
+         * they are virtualized on SVM.
          */
         __clear_bit(X86_FEATURE_USER_MSR, fs);
+        __clear_bit(X86_FEATURE_MSR_IMM, fs);
     }
 
     if ( !cpu_has_vmx_msrlist )
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -453,7 +453,7 @@ void domain_cpu_policy_changed(struct do
     }
 
     /* Nested doesn't have the necessary processing, yet. */
-    if ( nestedhvm_enabled(d) && p->feat.user_msr )
+    if ( nestedhvm_enabled(d) && (p->feat.user_msr || p->feat.msr_imm) )
         return /* -EINVAL */;
 
     for_each_vcpu ( d, v )
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4712,6 +4712,14 @@ void asmlinkage vmx_vmexit_handler(struc
             hvm_inject_hw_exception(X86_EXC_GP, 0);
         break;
 
+    case EXIT_REASON_RDMSR_IMM:
+        /* Check the feature bit in lieu of an enable one. */
+        if ( !currd->arch.cpuid->feat.msr_imm )
+        {
+            hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
+            break;
+        }
+        fallthrough;
     case EXIT_REASON_URDMSR: /* NB: User-MSR bitmap was checked by the CPU. */
     {
         uint64_t msr_content = 0;
@@ -4721,7 +4729,7 @@ void asmlinkage vmx_vmexit_handler(struc
         {
         case X86EMUL_OKAY:
             *decode_gpr(regs, msr_imm_gpr()) = msr_content;
-            update_guest_eip(); /* Safe: URDMSR */
+            update_guest_eip(); /* Safe: URDMSR / RDMSR <imm> */
             break;
 
         case X86EMUL_EXCEPTION:
@@ -4731,6 +4739,14 @@ void asmlinkage vmx_vmexit_handler(struc
         break;
     }
 
+    case EXIT_REASON_WRMSRNS_IMM:
+        /* Check the feature bit in lieu of an enable one. */
+        if ( !currd->arch.cpuid->feat.msr_imm )
+        {
+            hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
+            break;
+        }
+        fallthrough;
     case EXIT_REASON_UWRMSR: /* NB: User-MSR bitmap was checked by the CPU. */
         exit_qualification = vmread(EXIT_QUALIFICATION);
         switch ( hvm_msr_write_intercept(exit_qualification,
@@ -4738,7 +4754,7 @@ void asmlinkage vmx_vmexit_handler(struc
                                          true) )
         {
         case X86EMUL_OKAY:
-            update_guest_eip(); /* Safe: UWRMSR */
+            update_guest_eip(); /* Safe: UWRMSR / WRMSRNS <imm> */
             break;
 
         case X86EMUL_EXCEPTION:
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -205,6 +205,8 @@ static inline void pi_clear_sn(struct pi
 #define EXIT_REASON_WRMSRLIST           79
 #define EXIT_REASON_URDMSR              80
 #define EXIT_REASON_UWRMSR              81
+#define EXIT_REASON_RDMSR_IMM           84
+#define EXIT_REASON_WRMSRNS_IMM         85
 /* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */
 
 /*
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions,
 
 #ifdef CONFIG_HVM
 
-#define VMX_PERF_EXIT_REASON_SIZE 82
+#define VMX_PERF_EXIT_REASON_SIZE 86
 #define VMEXIT_NPF_PERFC 166
 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
 PERFCOUNTER_ARRAY(vmexits,              "vmexits",
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -354,7 +354,7 @@ XEN_CPUFEATURE(MCDT_NO,            13*32
 XEN_CPUFEATURE(UC_LOCK_DIS,        13*32+ 6) /*   UC-lock disable */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ecx, word 14 */
-XEN_CPUFEATURE(MSR_IMM,            14*32+ 5) /*   RDMSR/WRMSRNS with immediate operand */
+XEN_CPUFEATURE(MSR_IMM,            14*32+ 5) /*s  RDMSR/WRMSRNS with immediate operand */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.edx, word 15 */
 XEN_CPUFEATURE(AVX_VNNI_INT8,      15*32+ 4) /*A  AVX-VNNI-INT8 Instructions */



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:31:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:31:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383176.1626432 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXyb-00018u-9H; Wed, 05 Aug 2026 09:31:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383176.1626432; Wed, 05 Aug 2026 09:31:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrXyb-00018n-5z; Wed, 05 Aug 2026 09:31:53 +0000
Received: by outflank-mailman (input) for mailman id 1383176;
 Wed, 05 Aug 2026 09:31:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrXyZ-00018h-NR
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:31:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrXyZ-003zSv-3w
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:31:51 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7302fe-bab6-0a2a0a5309dd-0a2a4505ead8-36
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:31:50 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730306-4cb1-0a2a45050019-d155dd33d4c9-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:31:50 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47f93b2fe4cso501931f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:31:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfda6afsm6884988f8f.3.2026.08.05.02.31.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:31:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785922310; x=1786527110; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=m5ZVt/TEvWa5Y4pw8CpVX3kraK6kJ4ZA2MBNk4yY93o=;
        b=bsIggRdbkHqfEY7/rucbcqg/z9p3SuUyitrX2+KkbyADEAfK/mXrNgdaMhXunZ7rI6
         BgPLlGmtpRC/bSJa070F1aoIGiXRK8hUNun2c97QD1UMPV2SV+UM++6jYC+V+dSwBqZO
         UKd3Yz8JeBJgDG7H4+2+Ue4h3eUn8vrtV0f9txyfATuAYgObmatLcK/bGPIHgiwP8NFO
         KYiY/yO3eBIhNhHDWNVEbgCdMBgP7KiowmFB+qr6Bw65df209wniSGBWgq9JS/cYGV3g
         b07UruCv0sZAUhA9nr4hl0gzgDdUxxKOUucYTrB0xTOhaY6/5q7wXJSioKRDmnil1GC4
         Os0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785922310; x=1786527110;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=m5ZVt/TEvWa5Y4pw8CpVX3kraK6kJ4ZA2MBNk4yY93o=;
        b=lyyvmcDGLIDDJ9FpWCbTLoBAFZFQbTFO3b+zgASt3rV5tnsHsGpxMcndsZut74yvsw
         IGDqDEEv0yAQgZF5yV0PqqTTSzLfqX2Gc1dTLPaVtLGYcfgtZbVjZmjdKevkXMsAmhJU
         EkV+CM9U0cpCYz6sqPZpD5l7F/Dqdg6dX3iK52ucbvuhVcEsTEjbS5rUdPY5x/gmjj53
         /dRqUspa3tCg/pK1gxinT3abLjzC/ljOx+WkboWWtc5uobglIhJ+VgXpx6YrowGGm36i
         TvsCILCk7V5aGH6attf9ShWFWY+GBRl7hg68jqUReEe/WSFWksiRLXowl90ru0Nrx/j7
         Snng==
X-Forwarded-Encrypted: i=1; AHgh+Rp86nBZTpxIiAoJxGl+9eH4PfxKnWjM5psMP4mBZ/PdZ/w90HbspgoIYheRy+UFoJin/TbTwI0KVNw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwMjpZh2EMCAKk5Z/XQv14cOPd/oaHdxtcs5h3CUYZbD41E8ZUp
	2kmxY88liA3D8wxgEHFQxrC+c1oBlo6SjMqtiQ8B9LQ0GmXGaIpVl4ED27+CYJvKrw==
X-Gm-Gg: AR+sD10uLH+HJodJ2qjosv4Sp25+3DZ8sNqWSyreTc0FdoYexYr6srswZPN2aEkyTW+
	wF0ZdyZ0AJHo3KjjyjF+QzoYl9VYc1yQ3FM4WmwMa1lbvixOpq/iGEkHXW9O6d5xCeJU98iXO4s
	Eb4wv4tfM49jnN2YiSX+xsTdW5Y7M0Tb+9wmz3gp4iFAkjYSk6wYgvBQNFyjkD0tRl4H9CzIH7n
	HwIO1obJTYoZSuTUwkjoYGZ8+0UpnyziidsrSWw1nhhLjbKo+MvevPePAO3TMocyrrDAa49O6t2
	PXzJBxeDzQv/U6A+zgZj+OUkwC2jjTvX2aq7cNMf4jHY2lqqGW95b+H3Y3XUDWQrBFsOsvf+oGG
	k10uUnYLN1kAP2suHparb8AajycR+C/OcWtM1+qtc3t5OjmkDVecpf5Iaeo3Qwb6yGEj8jUB14n
	d9KiZta7n5mz1gD8w4NzZXrkhoUwFcGWdOUP9gAPHE149hlCO8i/tcbheom5NusAaCcfz31/VGt
	BKgX7nUVYEpFjiU5eG9w5iFdQ51JlaGqFPoZW9M3n5WXK1ZmMwB
X-Received: by 2002:a05:6000:1842:b0:47f:8d71:210a with SMTP id ffacd0b85a97d-47fec634b38mr8662442f8f.15.1785922310377;
        Wed, 05 Aug 2026 02:31:50 -0700 (PDT)
Message-ID: <07e4cde9-cbbe-4ca3-878b-1c72038e4530@suse.com>
Date: Wed, 5 Aug 2026 11:31:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/5] vtd: Print originating iommu on faults
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319342.8631fc262581453bbf619ec5b2062170.19fad533fa5000e099@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1785319342.8631fc262581453bbf619ec5b2062170.19fad533fa5000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1785922310-F7EB92A1-14438234/0/0
X-purgate-type: clean
X-purgate-size: 650

On 29.07.2026 11:59, Teddy Astie wrote:
> When a fault occurs on a IOMMU, print the IOMMU the fault is coming from.
> 
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>

Acked-by: Jan Beulich <jbeulich@suse.com>

Nevertheless I think this doesn't go quite far enough - this internal index,
to be helpful, would need associating back to the respective firmware data.
What iommu_alloc() logs is not only limited to verbose mode, but also doesn't
include the index. I think something need doing there, and then we need to be
more consistent throughout to include the IOMMU index in log messages
pertaining to a particular IOMMU.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:34:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:34:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383184.1626440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrY1K-0001ha-KR; Wed, 05 Aug 2026 09:34:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383184.1626440; Wed, 05 Aug 2026 09:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrY1K-0001hT-HQ; Wed, 05 Aug 2026 09:34:42 +0000
Received: by outflank-mailman (input) for mailman id 1383184;
 Wed, 05 Aug 2026 09:34:41 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+ef35d5f325ef5e0fcd65+8382+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wrY1F-0001hG-IP
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:34:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrY16-0040CN-JQ; Wed, 05 Aug 2026 11:34:36 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+ef35d5f325ef5e0fcd65+8382+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a730392-5cb7-0a2a0a5109dd-0a2a4506cc64-40
 for <multiple-recipients>; Wed, 05 Aug 2026 11:34:28 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+ef35d5f325ef5e0fcd65+8382+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7303a3-195a-0a2a45060019-5a9b3222e264-3
 for <multiple-recipients>; Wed, 05 Aug 2026 11:34:28 +0200
Received: from [2a07:aa00:8c:e0:2ef0:7ea2:4f15:3280]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wrXtU-00000001ABs-2rNZ; Wed, 05 Aug 2026 09:26:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=HCP6mO+wKKfIvYSWgV3yoR0hiLYWZQCLwXNtJuiZRtM=; b=jhXinj0CchuihGOKOsi5MD6O4W
	u+At7TWxLwHWZ3B6/Gu53v8QbU8MF7wc6mubv18a/7llwgDbUTK4o2l9pTEoKzPZNxhTsp6IXYZW1
	34UGn9+6hCOBNkXnyllVTAVvqzrbK+MenGznX5Z0AV05Ovwzahhsd6cWVADXSH0PVimAwVsMynMRO
	YxxdS+qtR/HRGBrYoZb9ggUG1LsPb5CWp4Iakz1AAyal6SuzahPza41YtGfgUOVcif/6dpbEAOvak
	3B3cNx4fYOe2YP8o3Ys98BjnwUBBl1f72Q+qSLeDu4q7aLEvOBMBFnNSuJyNNxs6SSOuQnLvns6q3
	Vo6/Hqmg==;
Message-ID: <38e16d4386a5ca428366a55ffa83ab34e0e1b72a.camel@infradead.org>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Wed, 05 Aug 2026 11:26:30 +0200
In-Reply-To: <anJ36SBzN7HL4A2D@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-32-dwmw2@infradead.org>
	 <am0upFND1r93HPxq@google.com>
	 <d2d98dd31718eb925ae44b0eceb325538a8174ae.camel@infradead.org>
	 <anJ36SBzN7HL4A2D@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-oAGZuj5i7ES/IfXkCZMt"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-16d1c6/1785922468-1EAC277B-C1621CBB/0/0
X-purgate-type: clean
X-purgate-size: 10712


--=-oAGZuj5i7ES/IfXkCZMt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-04 at 16:38 -0700, Sean Christopherson wrote:
> On Sat, Aug 01, 2026, David Woodhouse wrote:
> > On Fri, 2026-07-31 at 16:24 -0700, Sean Christopherson wrote:
> > >=20
> > > > +	/*
> > > > +	 * Allow for a discrepancy of 1 kHz either way between the TSC
> > > > +	 * frequency used to generate the user's pvclock and the current
> > > > +	 * host's measured frequency, since they may not precisely match.
> > > > +	 */
> > > > +	if (user_tsc_hz < curr_tsc_hz - 1000 ||
> > > > +	=C2=A0=C2=A0=C2=A0 user_tsc_hz > curr_tsc_hz + 1000) {
> > >=20
> > > I don't follow, why is KVM restricting what frequency userspace can s=
et?
> >=20
> > Userspace actually sets the frequency with KVM_SET_TSC_KHZ. What KVM is
> > insisting upon here is that the input to KVM_SET_CLOCK_GUEST is
> > *consistent* with the guest's TSC frequency (within a little slop
> > caused by different host TSCs).
>=20
> Why does KVM care though?=C2=A0 I know some people hate that KVM's uAPI i=
s permissive
> to a fault, but trying to "help" userspace often ends badly for everyone.=
=C2=A0 E.g.
> what happens if userspace does KVM_SET_TSC_KHZ after KVM_SET_CLOCK_GUEST?

The two operations have to be considered in isolation, at the time they
happen.

The KVM clock provides a y=3Dmx+c relationship from TSC (x) to kvmclock
(y), where the rate (m) depends on the TSC frequency.

The KVM_SET_CLOCK_GUEST function provides an equivalent y=3Dmx+c
relationship, instructing the kernel to make them match.

If the rates are the *same* then this is basically a case of adjusting
the constant epoch (c) to make the two parallel lines coincide.

If they *aren't* parallel, then what is KVM_SET_CLOCK_GUEST even asking
for? I guess the kernel can adjust the guest's kvmclock so that it
*intersects* the requested line at some point around now, but that
really isn't what KVM_SET_CLOCK_GUEST exists for.

--=-oAGZuj5i7ES/IfXkCZMt
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDUwOTI2MzBaMC8GCSqGSIb3DQEJBDEiBCDrMFuo3LMQwgzSkoKKUNMxtBxlyjvN
7KZ2Dl4YbaXEJzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAkOdbfLkZuku+SQVaoiGVaHf6YcFf5yzLX87vOO9o/+sDyzbNJ2Zu
REjNQ+5aojh9XoZcgeiWMi5e7VXN2WdEkSqtBBKsfNY982ZOLWo2uitaEdKaV4YgOe2xt/NZ2qWc
OWV3T4Cg8bUinS+IcMGkWhyZrbraASc1MJcM5d22cJ93gls9ovwf4jtbDyCZOjT4poCDMR+T9jqH
qkTBLtG+tso/Yw9Wp3ME4ZB2WPtaT39H2c63mrXIAMVQISPw8HQavnhB3z50Ns4cwLNkQVT03ZEu
kJG5MweXfkfgS9TqHS6YLTenDY6OiPEet5R5qY5TTdUHFc3eGcjLQXSNmM+WvQnFRyCDUVxw8mZA
WXhnp6QtN1VYMDJvFAmwj0l/HS7hBkKGEzf7wsuOpM46sa0hjhIuzCsGDsPVVYdPTgsbXbYiOTRi
w0ByXpLtlEzLDrP9JnrU/D/r8TOtfr3XubQvKJMFWkTkucYEhRV+QkupvIkEyR7840rPPJuESPEK
QxvQfJsUJlcbsPzg3thAE5TMCF7IOEKkUJZ+8ZPbgd3kuzpHvOCq319byh3dNTu+N+VAwjBG+nVk
PIu6y0roSGeVTegr8bwUeTIj6VplZgAkZNuB3PopN4/nVlvkjLOuH9SjTJVooMHu/Cm92It9VMhI
h/TFd2tqzGcQBYemqXDhjKcAAAAAAAA=


--=-oAGZuj5i7ES/IfXkCZMt--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:40:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:40:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383193.1626449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrY76-0003eh-AE; Wed, 05 Aug 2026 09:40:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383193.1626449; Wed, 05 Aug 2026 09:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrY76-0003ea-7f; Wed, 05 Aug 2026 09:40:40 +0000
Received: by outflank-mailman (input) for mailman id 1383193;
 Wed, 05 Aug 2026 09:40:39 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wrY75-0003eU-Hq
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:40:39 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wrY72-006IBs-32;
 Wed, 05 Aug 2026 09:40:36 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wrY72-00FGrj-18;
 Wed, 05 Aug 2026 09:40:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:Message-ID:Date:Subject:Cc:To:From;
	bh=jqWNmZY06DVMjdGxIRpnMRf2z1reaDJOSpTrbBkvv8c=; b=Rz/Fywb9AY5sDD9He27t1Qc5k2
	RRLgVyzgKt6l6h3C7jNH0drpNd+kl0uZZKYtPt3ybteq3VJImA/JPSCDOwYFsKpWvwIvFmKquewtp
	ud3QY0S6HTbjv2yVc3EgHFTnekJymgHrZpge7sFIVCqzIjlfT0KP6S7FcjlRKbpMe30Y=;
From: Roger Pau Monne <roger@xenproject.org>
To: Juergen Gross <jgross@suse.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Cc: Roger Pau Monne <roger@xenproject.org>,
	stable@vger.kernel.org,
	Yannick Martin <yannick.martin@okazoo.eu>,
	"Thorsten Leemhuis" <regressions@leemhuis.info>,
	Matthias Goergens <matthias.goergens@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: [PATCH v2] x86/xen: fix init of balloon stats again
Date: Wed,  5 Aug 2026 11:40:07 +0200
Message-ID: <20260805094008.95778-1-roger@xenproject.org>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The handling of extra memory regions done in balloon_add_regions() is not
correct for PV guests, since the initial target is set to reflect the real
memory the system has, not what's described on the memory map, which can be
higher if memory != maxmem.

Introduce separate logic for addition vs subtraction in
balloon_add_regions() and handle extra regions correctly by adding them to
the total amount of pages, instead of subtracting from the current and
target pages amounts.

In the common case PV domU/dom0 and PVH dom0 will use the addition path,
since the initial target reflects the real assigned memory.  HVM and PVH
domUs use the subtraction path, since the target is set based on the amount
of memory reported in the memory map, without accounting for released
regions.

Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0")
Fixes: 0949c646d646 ("Partial revert "x86/xen: fix balloon target initialization for PVH dom0"")
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Cc: stable@vger.kernel.org
---
Cc: Yannick Martin <yannick.martin@okazoo.eu>
Cc: "Thorsten Leemhuis" <regressions@leemhuis.info>
Cc: Matthias Goergens <matthias.goergens@gmail.com>
---
Changes since v1:
 - Also fix PVH dom0 without unpopulated pages support.
 - Account for XENMEM_current_reservation possibly failing.
---
 drivers/xen/balloon.c | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e7f1d4ca6d75..e7f74ea7cd5e 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -679,7 +679,7 @@ void xen_free_ballooned_pages(unsigned int nr_pages, struct page **pages)
 }
 EXPORT_SYMBOL(xen_free_ballooned_pages);
 
-static int __init balloon_add_regions(void)
+static int __init balloon_add_regions(bool append)
 {
 	unsigned long start_pfn, pages;
 	unsigned long pfn, extra_pfn_end;
@@ -703,19 +703,26 @@ static int __init balloon_add_regions(void)
 			balloon_append(pfn_to_page(pfn));
 
 		/*
-		 * Extra regions are accounted for in the physmap, but need
-		 * decreasing from current_pages and target_pages to balloon
-		 * down the initial allocation, because they are already
-		 * accounted for in total_pages.
+		 * There are two different use-cases depending on how the
+		 * initial memory target is fetched.  For PVH dom0 and PV the
+		 * target is usually set to reflect the domain assigned memory,
+		 * and hence extra regions need adding.
+		 *
+		 * OTOH for HVM and PVH domU the target is set to the amount of
+		 * RAM reported in the memory map, and hence extra regions need
+		 * subtracting to reflect the real memory usage.
 		 */
 		pages = extra_pfn_end - start_pfn;
-		if (pages >= balloon_stats.current_pages ||
-		    pages >= balloon_stats.target_pages) {
+		if (append) {
+			balloon_stats.total_pages += pages;
+		} else if (pages >= balloon_stats.current_pages ||
+		           pages >= balloon_stats.target_pages) {
 			WARN(1, "Extra pages underflow current target");
 			return -ERANGE;
+		} else {
+			balloon_stats.current_pages -= pages;
+			balloon_stats.target_pages -= pages;
 		}
-		balloon_stats.current_pages -= pages;
-		balloon_stats.target_pages -= pages;
 	}
 
 	return 0;
@@ -726,6 +733,7 @@ static int __init balloon_init(void)
 	struct task_struct *task;
 	long current_pages = 0;
 	domid_t domid = DOMID_SELF;
+	bool append = true;
 	int rc;
 
 	if (!xen_domain())
@@ -745,6 +753,7 @@ static int __init balloon_init(void)
 		} else {
 			if (xen_unpopulated_pages >= get_num_physpages())
 				goto underflow;
+			append = false;
 			current_pages = get_num_physpages() -
 			                xen_unpopulated_pages;
 		}
@@ -767,7 +776,7 @@ static int __init balloon_init(void)
 	register_sysctl_init("xen/balloon", balloon_table);
 #endif
 
-	rc = balloon_add_regions();
+	rc = balloon_add_regions(append);
 	if (rc)
 		return rc;
 
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:41:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:41:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383200.1626459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrY7k-00045p-Ir; Wed, 05 Aug 2026 09:41:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383200.1626459; Wed, 05 Aug 2026 09:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrY7k-00045i-FH; Wed, 05 Aug 2026 09:41:20 +0000
Received: by outflank-mailman (input) for mailman id 1383200;
 Wed, 05 Aug 2026 09:41:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrY7j-00045c-FK
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:41:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrY7i-00EPDH-Rn
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:41:18 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a73053a-5cb7-0a2a0a5109dd-0a2a4508c91c-6
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:41:18 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a73053e-f659-0a2a45080019-d1558031e553-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:41:18 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4957eefd361so5497635e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:41:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49949fcb46esm187293975e9.5.2026.08.05.02.41.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:41:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785922878; x=1786527678; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=MiIQ7czv9lPQAjuP9ijWUuHHGqlX/VIo/pd5dCsI4+4=;
        b=dfFHuO/qG248KrBOEo4zwyFFRTaJgXvtz6Hohm2mJd2N1qTmFGTbJOx7fwmal8Re/6
         O6pr4b0PJr0pvxjnwBl8BVHe4yNuSMMg0CiMt/4Jj+nGw4aAtHbGC77cjzKdlQuLrvPY
         zFVeoVTmYC6Ne83HjHbD/tf8fkSFm0whLtE/nZS8jX+ayfV6/zlRWryJFBWvgF2VEiYL
         rKz/+IV1QWwURM46Tgsj3m+n4RZBd201n5DixMDOS5R6QedDwX2SqOo/mdlmZ50mGu/0
         nTYfLcyD/eu6xdP0wGahKj9Wr//H9i5b57R5prN3FPSfylQSDpeds6H+4w9BxlIPVJTT
         SVVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785922878; x=1786527678;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=MiIQ7czv9lPQAjuP9ijWUuHHGqlX/VIo/pd5dCsI4+4=;
        b=dNH2wZGUBRZId8p2l5uOHWMqvZInzWqv07X77v8YlPgPKv27ViTeDFnUgw07r+k9Sx
         7vPZxhvvWFmYbKpo2ov39dbekantc/ie2GSgjoOj4UEY//4gE7cuac6ynTtMADkkWKhF
         /fkKA7jwEqoSIb0Ukw9M5o+gEOsizp3UlT4hajrgKZnlHbcO3fWOBHwt+xL8qOuUL1RE
         7UNMyvkWJYZD5LWSFY0ErJCjgjf3bogxuPlNe/3VY4GZUWXcE1X/Y/K+4OuSIUFQzT/Q
         FTeUnl2RVwf9sUiBUdf1+UVJeXcfLP6QTnwwsUlHEj6w0v73t5/AhVJcCjswuRpmhoOQ
         oKmg==
X-Forwarded-Encrypted: i=1; AHgh+RrE9bkw3Q0bU6n+TNGtd2+xLVtKq6Ne3Ytcde++nV/Yx2yEEUO2x37Q7S24EheNQkW04BMjqBCIxQA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz03Q1M+vljj3tNzRW7vsAW70O9TQr5cECgDVvPhabZKS2wqv4m
	Bj2jm/tfD+aO8KiQt5SZjMjR2xZu/L71BWMqgww1BeqLqkicaEmgRYjRLNzOvRWWZg==
X-Gm-Gg: AR+sD12VBbv3JhRZ5JM3SwBmFinT0ErFClDvK2XIh8UuiOkEB0FcqSm6mjiELQ8giMd
	KTxlfhV7YAjE7ROiwhXWTXEKx48oWPeTO0qOkDO99xqghaJ2jghiUOJdyKcqcPHhRNrXL2tDZ8v
	+ZBbkx040zmcZnCGx+f0GJ9MY3cyZ26XkmbMRKxP6C7YoutVTgoiNd+iqr7OBux1zFoYno+3oFi
	pOIZvTfBZAMOYzCrDcnhFQ0pWlaPCSF/3hdm9L+tf7k2EMB6sXEjQyJZW0gKaUMAcjLJ9feo8yf
	1cCgZ5jU4cW0/i1zaTeEzydQbh5nadRcRgfD6knp3ZFQTKkEKhXSb0sUxW1zF8aCqM6hrzLUw+O
	U0C4/wCf6JcDxyAZnj99GotP3S4MxPHVrufvi870yQuhS/FrUNvLVOGknkKNiZBg9Nixwy0ztQu
	iu9a0ZuIPT/EkdI8Bjeoeg0q0XeA3hh+ckTKKaX/4305DXvAb2UNPITdt6E+/Zy4/WfMu6wgI8U
	VQjmpJ9Q0MqNHN2K5iiR+G7pqoK5PD7VG4DEeXLXPlDqEbHGgyR
X-Received: by 2002:a05:600c:3b29:b0:495:4811:7998 with SMTP id 5b1f17b1804b1-4994e7d389emr49613065e9.17.1785922878278;
        Wed, 05 Aug 2026 02:41:18 -0700 (PDT)
Message-ID: <dfcd2023-7581-4621-9a29-9beaf472c376@suse.com>
Date: Wed, 5 Aug 2026 11:41:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/5] vtd: Don't disable hwdom passthrough on unhandled
 SAGAW bits
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319342.8631fc262581453bbf619ec5b2062170.19fad53421a000e099@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1785319342.8631fc262581453bbf619ec5b2062170.19fad53421a000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1785922878-D594A87B-4457EC51/0/0
X-purgate-type: clean
X-purgate-size: 1550

On 29.07.2026 11:59, Teddy Astie wrote:
> On recent VT-d spec, bit 3 indicates support for 5-level pagetables,
> this is currently considered unhandled and causes "hwdom passthrough"
> to be disabled, even though it's unrelated.
> 
> Given these are is capability bits, we don't need to consider unhandled
> bits, but only make sure that the ones we want (e.g 39-bit or 48-bit AGAW)
> are set.
> 
> Fixes: 474fc7d3c652 ("iommu/vt-d: fix SAGAW capability parsing")

The description of that commit explains pretty well why pass-through mode
does need disabling in that case. If there's anything wrong with that
explanation, this would need calling out here.

Additionally I can only repeat my proposal to finally default to strict
mode. In strict mode, pass-through mode is disabled anyway. (IOW there's
the additional question of why you need pass-through mode in the first
place.)

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1327,14 +1327,7 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
>      }
>  
>      if ( sagaw >> 3 )
> -    {
> -        printk_once(XENLOG_WARNING VTDPREFIX
> -                    " Unhandled bits in SAGAW %#x%s\n",
> -                    sagaw,
> -                    iommu_hwdom_passthrough ? ", disabling passthrough" : "");
> -
> -        iommu_hwdom_passthrough = false;
> -    }
> +        printk_once(XENLOG_WARNING VTDPREFIX " Unhandled bits in SAGAW %#x\n", sagaw);

Also please adhere to the line length limit.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:44:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:44:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383208.1626467 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYAN-0004iX-UD; Wed, 05 Aug 2026 09:44:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383208.1626467; Wed, 05 Aug 2026 09:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYAN-0004iQ-RX; Wed, 05 Aug 2026 09:44:03 +0000
Received: by outflank-mailman (input) for mailman id 1383208;
 Wed, 05 Aug 2026 09:44:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrYAM-0004iK-BD
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:44:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrYAL-0041xN-Jb
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:44:01 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7305b8-2eae-0a2a0a5409dd-0a2a4503ce90-44
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:44:01 +0200
Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7305e1-fae8-0a2a45030019-d155da29c161-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:44:01 +0200
Received: by mail-ej1-f41.google.com with SMTP id
 a640c23a62f3a-c1c4c7ddaf6so136317566b.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:44:01 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c20363e6e8fsm91963166b.39.2026.08.05.02.44.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:44:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785923041; x=1786527841; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=fIxT2QYlt7MhR6tH5xbR++rCxhH8SJlguVhp+ZQ3HcE=;
        b=TB68hf9lg726mk2jjJKMyJjrPpCfpnS+SXRdAAolAvU7saGO1H3uxf0KHwhlcVzZOq
         YCFjTpMxFBbtkcbpT2mkZQcgnkWy27WpnUqLpx5t7FZ+Gyfz8TZkJWr3ri4NnSzPZlyW
         5vqFk2rckVHgfkXsr6uiOtfNua+3mwhkKdGTvuJSI8UT88wI2Xq/+M/+feV/Qrn/nI+T
         N0j3UCJjNauvCdS2qp4988utffYzsCB6rcnfBsTwVK+QrIY+sotGKz6OFZFUa+Mr5Iuo
         jUevN0xc+5Ejkux4SHmZO/RIF4ei1bZCT5DD0xdu19D7QQnmkehFbq01TPWTgj4Ap2Mt
         hadw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785923041; x=1786527841;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=fIxT2QYlt7MhR6tH5xbR++rCxhH8SJlguVhp+ZQ3HcE=;
        b=PLSgfYXb8Iol1QdVoriPtFYl3ep2E9kw1SOmrhSGIM1Ju2iIUHlNB01PgJ+cKcyphP
         0Lndd/TBW79fPTfArbJE+bo4CL2go4yi6wl1BtLMBqsqQwE1zmaZsp1UfsbbO4l7VqoT
         +M0euj+SJPogaaRHVAymRjv2/uHU+Lg4Uh3o3i4p93li6tQNpIAg2fJoNYHeLrFqdu2/
         1JF9QQoOZINWMkJiCh0qwY6dqcJj92FyrUOnJasW5cawjf8bvwTWtGYdi9zuASQrEDNa
         0atAE6cQNnNrpkQMAtNdetF3GG0atZT0QLfZWSD9fwBY+Xs0nhNFQIFd8vi2cx4stAaB
         bNYQ==
X-Forwarded-Encrypted: i=1; AHgh+RrI8OzIVgXIxMljQgVxcodzC3bFN9HV5Xa80B1N1pnnCqiAoogjDK68s5n9FqkbEDDNRHCGTFwEM+k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxyFjylmlLt9uTOs2zKvKD8ULP41HbyltVNi3usBEFWzgDyv5Nt
	sWkdAgzLCWHKKDahkRgA80L/3paXKdZ32Im4J9sLO9X7W0cFYUpTZjLfQuKu68XVLzk=
X-Gm-Gg: AR+sD12gTfwxSCIW8rLXTW3FDIdMHUg1dvk+Fuoz7f/ecVBlke46pWiXlWRQ6/hjK8y
	hAJul2Sc0nofVJFcY1kHIJP4ZqfvgpZnI8F7C5sf6ueizFlNHUo0hzGku0dPd6o6suexZXGmOAm
	4y9+HiSdnZzuYsM6iUGJAcdJPe++cUQrRKwSDWYZA01leDCvT3HzmKAAWK/O3hKMRNRGGZTUJoE
	NDkyqizdqBIb9da5cElSzkUwJv5Byd3uTGC0To66NYnFKjBAjJi/b4IZ19dze6xFO/SI9ZN1aJu
	yRMh+4dcgrnIvhZQEKerlvp53fK4fgYlgUfauq2FZKjOcvBIUzIL2CkpUNmAEty/U8FM+IErnhD
	H4FXlT10bqa/DJnsmfmZbHuPPZKoO1ZpDbeFDDHTabr9ysEmYZkctwQiyWNu5noiKjGFa3i1ZWO
	9G6C6VeAsi/RoyZj2O0QyETEZBk0X4cocAj3ZMdgh0qRrO2BFQBN6hfscaplA4JdK/+LdRogWc/
	tnS2JN4Uj5gkcjMdWq9VZMq3r4XzVKyIo3qIMJkdY3CDv3zR5hsNRK/bc/Qetzph8p/WzHnpNBC
	hJuHxuEq7AcZ7Ww=
X-Received: by 2002:a17:907:1b04:b0:c12:1651:17b2 with SMTP id a640c23a62f3a-c2039d256e2mr229300166b.9.1785923040816;
        Wed, 05 Aug 2026 02:44:00 -0700 (PDT)
Message-ID: <a5cce538-87d2-40e5-8a8c-21102fb37a52@suse.com>
Date: Wed, 5 Aug 2026 11:44:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
To: Jan Beulich <jbeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel@lists.xenproject.org, Thomas Gleixner <tglx@kernel.org>,
 IngoMolnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 lkml <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
 <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
 <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
 <bbae3eb9-6d1e-4caf-a647-25ca9ca8a61c@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <bbae3eb9-6d1e-4caf-a647-25ca9ca8a61c@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------JLsQo2xsfStlXt0qsnHsk5Ct"
X-purgate-ID: tlsNG-33051d/1785923041-6CCDB4E9-0E4393B9/0/0
X-purgate-type: clean
X-purgate-size: 11313

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------JLsQo2xsfStlXt0qsnHsk5Ct
Content-Type: multipart/mixed; boundary="------------0mvgBLd6VDmor8xQK9Xed228";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel@lists.xenproject.org, Thomas Gleixner <tglx@kernel.org>,
 IngoMolnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 lkml <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
Message-ID: <a5cce538-87d2-40e5-8a8c-21102fb37a52@suse.com>
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
 <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
 <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
 <bbae3eb9-6d1e-4caf-a647-25ca9ca8a61c@suse.com>
In-Reply-To: <bbae3eb9-6d1e-4caf-a647-25ca9ca8a61c@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------0mvgBLd6VDmor8xQK9Xed228
Content-Type: multipart/mixed; boundary="------------aNYvgKSbnjvWNPRRggTG00UI"

--------------aNYvgKSbnjvWNPRRggTG00UI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTE6MDQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNS4wOC4yMDI2
IDEwOjU1LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMDUuMDguMjYgMTA6NDQsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDA1LjA4LjIwMjYgMTA6MjEsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IC0tLSBhL2FyY2gveDg2L3hlbi9NYWtlZmlsZQ0KPj4+PiArKysg
Yi9hcmNoL3g4Ni94ZW4vTWFrZWZpbGUNCj4+Pj4gQEAgLTM3LDggKzM3LDggQEAgb2JqLSQo
Q09ORklHX1hFTl9QVkgpCQkrPSBlbmxpZ2h0ZW5fcHZoLm8NCj4+Pj4gICAgb2JqLSQoQ09O
RklHX0VWRU5UX1RSQUNJTkcpCSs9IHRyYWNlLm8NCj4+Pj4gICAgDQo+Pj4+ICAgIG9iai0k
KENPTkZJR19TTVApCQkrPSBzbXAubw0KPj4+PiArb2JqLSQoQ09ORklHX1NNUCkJCSs9IHNt
cF9odm0ubw0KPj4+PiAgICBvYmotJChDT05GSUdfWEVOX1BWX1NNUCkgIAkrPSBzbXBfcHYu
bw0KPj4+PiAtb2JqLSQoQ09ORklHX1hFTl9QVkhWTV9TTVApICAJKz0gc21wX2h2bS5vDQo+
Pj4NCj4+PiBTaW1pbGFyIGlzc3VlIGhlcmUgLSBpbiBhIFBWLW9ubHkgY29uZmlnIHNtcF9o
dm0ubyBkb2Vzbid0IHdhbnQgLyBzaG91bGRuJ3QNCj4+PiBuZWVkIGJ1aWxkaW5nLg0KPj4N
Cj4+IE5vdGUgdGhhdCBJIGRpZG4ndCBjaGFuZ2UgYW55IGZ1bmN0aW9uYWxpdHkuDQo+Pg0K
Pj4gSSBhZ3JlZSB0aGF0IGl0IHNlZW1zIGEgbGl0dGxlIGJpdCBzdHJhbmdlLCBidXQgaW4g
dGhlIGVuZCBJIGJlbGlldmUNCj4+IHRoZSBjdXJyZW50IHN0YXR1cyBpcyBva2F5LWlzaC4g
UFYtb25seSBoYXNuJ3QgYmVlbiBzb21ldGhpbmcgaW4gdXBzdHJlYW0NCj4+IExpbnV4IHNp
bmNlIFhlbiBzdXBwb3J0IHdhcyBhZGRlZCwgYXMgUFYgd2FzIGFsd2F5cyBtZWFudCB0byBi
ZSBhbg0KPj4gYWx0ZXJuYXRpdmUgdG8gYmFyZSBtZXRhbCBzdXBwb3J0IHZpYSBwYXJhdmly
dCBwYXRjaGluZy4gSXQgbWlnaHQgaGF2ZQ0KPj4gYmVlbiBwb3NzaWJsZSB0byBidWlsZCBh
IGtlcm5lbCBub3QgcmVhbGx5IGZ1bmN0aW9uYWwgb24gYmFyZSBtZXRhbCwgYnV0DQo+PiB0
aGlzIHdhcyBtb3JlIGxpa2UgdGhlIGFiaWxpdHkgdG8gYnVpbGQgYSB4ODYga2VybmVsIG5v
dCB3b3JraW5nIG9uIGFueQ0KPj4gZXhpc3RpbmcgbWFjaGluZS4NCj4+DQo+PiBJTU8gdGhl
IFhlbiBrZXJuZWwgY29uZmlnIG9wdGlvbnMgc2hvdWxkIGFsbG93IGZvciBhZGRpbmcgWGVu
LXNwZWNpZmljDQo+PiBmZWF0dXJlcywgYnV0IG1pbmltdW0gWGVuIHN1cHBvcnQgc2hvdWxk
IGFsd2F5cyBoYXZlIGJhc2ljIEhWTSBzdXBwb3J0LA0KPj4gd2hpY2ggaW5jbHVkZXMgdGhl
IFhlbiBzcGVjaWZpYyBwZXJmb3JtYW5jZSBlbmhhbmNlbWVudHMuDQo+IA0KPiBJIGZlYXIg
SSBkb24ndCB1bmRlcnN0YW5kIHRoaXMuIElmIEkgd2FudCBhIGtlcm5lbCBqdXN0IHRvIHJ1
biBhcyBQViBEb20wLA0KPiB3aHkgd291bGQgaXQgbmVlZCB0byBjYXJyeSBhbnl0aGluZyBI
Vk0taXNoPyBUaGF0IGlzIChvciBzaG91bGQgYmUpDQo+IGVudGlyZWx5IHVucmVsYXRlZCB0
byBiZWluZyBhYmxlIHRvIGFsc28gcnVuIHRoaXMgc2FtZSBrZXJuZWwgb24gYmFyZW1ldGFs
DQo+IHRoZW4uDQoNClRoZSBmYWN0IGlzIHRoYXQgWGVuIFBWLW1vZGUgd2FzIGFsd2F5cyBh
IGZlYXR1cmUgbm90IHJlYWxseSBsaWtlZCBlc3BlY2lhbGx5DQpieSB4ODYgbWFpbnRhaW5l
cnMgKHRoaXMgaXMgdGhlIHBvbGl0ZSB3YXkgdG8gcGhyYXNlIGl0KS4NCg0KQ2hhbmdpbmcg
c29tZXRoaW5nIG91dHNpZGUgb2YgeGVuLXNwZWNpZmljIHBhcnRzIG9mIHRoZSBrZXJuZWwg
aW4gZmF2b3Igb2YgUFYgaXMNCm5lYXJseSBhbHdheXMgYSBmaWdodCBhbmQgSSdtIHByZXR0
eSBzdXJlIEkgb25seSBnZXQgY2hhbmdlcyBpbiBieSBwbGF5aW5nIG5pY2UNCihub3QgY2hh
bmdpbmcgbW9yZSB0aGFuIGFic29sdXRlbHkgbmVjZXNzYXJ5IGFuZCBjbGVhbmluZyB1cCBj
b25zdGFudGx5KS4gSSB3aWxsDQpjZXJ0YWlubHkgbm90IHRyeSB0byBwdXNoIGZvciBhICJQ
Vi1vbmx5IiBrZXJuZWwgd2hpbGUgdGhlIGhvcGUgb2YgdGhlIHg4Ng0KbWFpbnRhaW5lcnMg
aXMgbW9yZSAiUFYgd2lsbCBnbyBhd2F5IHNvbWUgdGltZSBpbiBmdXR1cmUiLg0KDQpUaGUg
Y2FwYWJpbGl0eSB0byBjb25maWd1cmUgdGhlIGtlcm5lbCB3aXRob3V0IEhWTSBzdHVmZiBi
dXQgd2l0aCBYZW4gc3VwcG9ydA0KaXMgdGhlIHdheSBpdCBoYXMgYmVlbiBzaW5jZSBtYW55
IHllYXJzIG5vdy4gTm9ib2R5IGhhcyBtaXNzZWQgYSBQVi1vbmx5IGtlcm5lbCwNCnNvIEkg
Y29uY2x1ZGUgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhhdC4gVGhlIGNsb3Nlc3Qgd2Ugd2ls
bCBnZXQgaGVyZSBpcyBhIFBWSA0Kb25seSBrZXJuZWwsIGFuZCB0aGlzIGlzIHBvc3NpYmxl
IGJ5IG5vdCBlbmFibGluZyBDT05GSUdfWEVOX1BWSFZNX0dVRVNULg0KDQoNCkp1ZXJnZW4N
Cg==
--------------aNYvgKSbnjvWNPRRggTG00UI
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------aNYvgKSbnjvWNPRRggTG00UI--

--------------0mvgBLd6VDmor8xQK9Xed228--

--------------JLsQo2xsfStlXt0qsnHsk5Ct
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpzBeAFAwAAAAAACgkQsN6d1ii/Ey/q
kwgAlENLixbffh1SBVhe3sWFz6j0uq2XADYRYKiwTMK9ic7L3Vvuu9roHT56SIivEKim2BzkL/7t
rBMTAV61qkqJs0DxOLajX5HcpYLX8nNxYGuSMNclukSCnEvuXpGSBoa5eZlizASZNyjWm3IpeSuO
E+FuxJfOEuN80H625y9YWocJmjRpTyW4fD/507Y5jCn9OWl/R65fQWwtZkM9WxR/iseqvibHGxg1
NWzOKzqOu+IEVQ1oUhjyN0iS43afKKe4wCf//LcULbgqahIxdawQ2y2wpC7mDOu2577h8ffiIdPH
PaiAx/zpbIj7xLAK7QQLlBELXKo/gw9bD3YKbiigbw==
=yloA
-----END PGP SIGNATURE-----

--------------JLsQo2xsfStlXt0qsnHsk5Ct--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:44:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:44:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383217.1626477 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYBC-0005Fi-97; Wed, 05 Aug 2026 09:44:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383217.1626477; Wed, 05 Aug 2026 09:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYBC-0005Fb-6W; Wed, 05 Aug 2026 09:44:54 +0000
Received: by outflank-mailman (input) for mailman id 1383217;
 Wed, 05 Aug 2026 09:44:52 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrYBA-0005FQ-De
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:44:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrYB9-00BWKw-Qi
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:44:51 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730610-5cb7-0a2a0a5109dd-0a2a4502d992-16
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:44:51 +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 <jbeulich@suse.com>)
 id 6a730613-6ca4-0a2a45020019-d1558036b490-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:44:51 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-495635a85d2so6730735e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:44:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23ec2fsm7302644f8f.29.2026.08.05.02.44.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:44:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785923091; x=1786527891; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=6/xC07hUjUOekDJMrhIxHqIepT3gweD/QF3bDgW0CRo=;
        b=INfxI3FhVW17vRpVGr4mLaypV40YA7P1zjppeiYtLDpx/YmUjGKSH4L9db0I1Lb83f
         t6oXuo/tHhjbDgFsHVz9aJpFD1mZq7jxxKatEvySISQ7qDhTxg1qI18Li9Y7jRlfB6DG
         dDmvLPDz5vIksJEd/4uyy144EVChwRImezorhj5l1H2QiEtL6oxHA+pDGZlWW+Xs+R4/
         8YO5iMQyGVYDmM5N2dLJ6gNlcWGer4E2+SyBjJpPWNHWtoDbMK8aPJKbH3ytU6ys8yfh
         yamKlm5dju50H2SaorYWhLwqdWOqvBzgcDUz3Ea3j1gCKeaSKuG88/g8X/A7POihRpIF
         mY5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785923091; x=1786527891;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=6/xC07hUjUOekDJMrhIxHqIepT3gweD/QF3bDgW0CRo=;
        b=fGJkW82/0Deg2WGmP62oWVgBpKbH0j3c0c/m/s0UKHmlukBjgMCCXZmtVxq+6xI1h3
         26i8ToT37/u7XkSzmSWnk3DhWbo2rHfTseX7FISXoJKqb88lnsz8zyZPXMcpjZna8ORy
         rrE6tUT+/Dzlpimf/FCtkt4vmhnrgG723WHOWX3eA7LTT0XPVbk+BrLCFy/Oypooy2Qo
         Rwbed4etJ57fC8Wk42NnjdzrMmWG+Un7z2YPvtUHvrCUryAn+ttH25S312wrtkyPl0RF
         5a+f45crwuQ5tVF5PohqYn3TDsDYaJtJgTVYaaaNTPSxkXM4l8vMhkMGx56NgBnmGRIa
         oCaQ==
X-Forwarded-Encrypted: i=1; AHgh+Rp/IP0iIWd4g8Kg0S4xHLiSc7p9seTbEduSVC0cqVwcbdNlUwbyKVNaIlR824gEH4AIdR6gNgRCALg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yytg6xOdoZiPJXoeO6b+HN0bE9lydWl5OqJ02872T4OLeBUXeXX
	RZN8dvHKtBQ+aH+ldJHHBCkV6vF7fzfIDbUacoARtvY2c8QwdYzzToewv7UakMVO8w==
X-Gm-Gg: AR+sD13/okSiDjk9Ud/Kl+XeWToTUX2BU9arXggmB+9eAp30cN3yfaz961YU9EOAKNV
	jrr8UnxL72GW7uDqeYfm57/W30vfPJ0eXoi82MTwhpz1M/1yvfozHMIv5UWHwjJu2aGyK6MWaVD
	jrjvl7c2GTKRmyxWubuCoIinGzxWxpcTuQlaGbRhEQ+lMkYmTvgUoHhMIeyIIIH1Wn7OxHfryyU
	/oSKrpiHHQbVS2PxVGGF1yTD5MAgxadfUVI1EEmzQrCrghc6PVgGOECvW3FtEzMS5E9XdXi+C5V
	xRILd6Bjy+OTQPJAlJcKoVYpToClRim069gkvJsnPZosrrLpFxmfk6iprbG2M7zzW5jtexNxTgn
	ZVvTy1BQZ6UwF6k5UQ1jdE3ykjuByC8U4LgAr4ly7QDz901ynZ1Iubc1A1FfQv16ncArA09Vz1D
	+3gZUq27fGZVB2QlH+B3zTQAnrTLke0XgntJxkyfNsN99DbooA2amCJInK5ny4hkviASXgKKTk0
	nxgv3ccatvVX2upLCrKeuD0Si70b7MOgODB1HGZ4tZQab9tXDHj
X-Received: by 2002:a05:600c:620e:b0:495:6274:56c2 with SMTP id 5b1f17b1804b1-4994e70a6f5mr73830555e9.2.1785923091196;
        Wed, 05 Aug 2026 02:44:51 -0700 (PDT)
Message-ID: <451978a5-7dfd-4b91-a241-eb13caf6d394@suse.com>
Date: Wed, 5 Aug 2026 11:44:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] vtd: Move intremap table to xenheap
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319343.8631fc262581453bbf619ec5b2062170.19fad5345fc000e099@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1785319343.8631fc262581453bbf619ec5b2062170.19fad5345fc000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1785923091-303C42AC-842312A3/0/0
X-purgate-type: clean
X-purgate-size: 741

On 29.07.2026 11:59, Teddy Astie wrote:
> Interrupt remapping entries often needs to be accessed, and we're creating
> pointers to it on demand, which brings a lot of complexity (e.g
> GET_IREMAP_ENTRY() macro), move it to xenheap such that it's persistently
> mapped and we won't have to worry about mapping and unmapping individual
> intremap table pages.

Afaic: No movement from domheap to xenheap except for _very_ good reasons.
For the case here that is - maybe establish a permanent mapping using
vmap(), but no change in where the memory is to come from. Whether such a
permanent mapping is really worthwhile may also want supporting by numbers.
You say "often", but you don't qualify / quantify this any further.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 09:55:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 09:55:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383229.1626493 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYLJ-0007J1-8j; Wed, 05 Aug 2026 09:55:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383229.1626493; Wed, 05 Aug 2026 09:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYLJ-0007Iu-5e; Wed, 05 Aug 2026 09:55:21 +0000
Received: by outflank-mailman (input) for mailman id 1383229;
 Wed, 05 Aug 2026 09:55:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrYLH-0007IQ-AR
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 09:55:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrYLG-00ESqr-6z
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:55:18 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a73087d-bab6-0a2a0a5309dd-0a2a4505ae3a-24
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:55:18 +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 <jbeulich@suse.com>)
 id 6a730885-4cb1-0a2a45050019-d1558033c1ae-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 11:55:17 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4954aff6088so7909135e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 02:55:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec24a24fsm8080783f8f.36.2026.08.05.02.55.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 02:55:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785923717; x=1786528517; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7k23JfBGtG8w8FZKJzglvJRq6dDsmFwVnAzVqjhZ8JM=;
        b=FZulFFenbwbAp/KQsRasxbwl3tEHwsOECEkaj4GBZwykcRfSWb7ie5GACUHQR1Y/pe
         MbRFChmSboUTcG0lhjIXGK/Mt30ya8wWIIx/pd2P5667CVz6f7UdWtzDJxE2ezfvAIXd
         v9EMiP+iYMSZBaahRoGQeQ0K0S3UJ3FnYNd5r9k3n/+i+Z/R3pMF+cht/caYtQQtfgFB
         /OvPtB3d1nJFWVM7x9oPRmqB6LbrsA1vlYf6YxFpv4qHOAsI5GTM5qX5Ltci5iGGsw7D
         GZF6TuwXdgDXCjMcLjfBoGQI+5gAUANaGQDO4KUjQuHnpKvXKI7U2xHOzvn6ubu8pxpM
         ucNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785923717; x=1786528517;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=7k23JfBGtG8w8FZKJzglvJRq6dDsmFwVnAzVqjhZ8JM=;
        b=NSQl5ikGlkRzvlfT/1QbtXtLnwRVqbAZK3fNtsSnLOCE0KBRPO9hNGEeig+LN6I3SC
         d4FsCUI+XXK6R/dFQZRcqDKXxVuVDOE8DVRi8uZqV7HwSbBnfYzWQ+XI+jhcIJJYPQHF
         DLRyinTgmXshSoDEih9OqE223Nq6vA1jIJNDSw81EVgC7tOsh0GhS44FvKd4DdNr0ECF
         9HzSzieD8Ahy+ZWZ6B2I4ipdQawFp1MmtdOmNqrCysGFjQMr8dak8hJ9kow7Xvrz4uU6
         2fyd3LZv7wwLMIbBUrtQ/vSeDVe8Zje4R2lQ+Ms2nrI9SR64OvgA5MXGrD+obOMsvzu8
         nA6A==
X-Forwarded-Encrypted: i=1; AHgh+RqV5UnCzqYJ8nN6zhxlWBaASS7+cqZdEGiLUTve0hNz5Nja+GQNuE0J+gqocBq7qQSdfr0Zq47FIv0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyavtesLQeqznFbugux04G/u/Iiy7beZMAFuKQXLdlkQGfX2O/2
	bHRBNMqgS+OsOhX00Q9YV5wYXyakALo3Xbo2DHMU/GmnpmvE4h39EEieYhhdYvTBB2pzD0EJlN+
	saWlOGA==
X-Gm-Gg: AR+sD12fkEUFoURY4bAk9o7jyF4wjwbzre/6ZHlm7Oig/953uYdelv6PBXfrk+y4EyD
	5CDMHIxArb8JAYZXbpZgsKmmWyZOJiEAglKem13yw+vErxUzTzFMFV47LLKlgy97XOoV5Vrtzpz
	Q1gQi0URn1YeV1GYZVV5Bvlsf4TRQDgIfobhK9iCV5FDk5NJ3+fO8GAJDNZLMjZ5IuuOVIyWCEl
	h7C6WrNmXPpMqSm9dQ6BoLUOJiVchOH/MYJ9z0epcEwYqPU+sfKb1/vv43UGUnw0Z5eLA7+RRVG
	egjyaev8NZOUcavXxUdQzvWqhtaH8IToWcrEPMFqrkxYHzu/CX/DycC2bBCUsleUFOJW1b1sVeg
	0oh9eaq9LL/byDHraUmjEqjoKf47cNqaX2/o26jTyYcsCH89GyN6asuFiY7twR2kQl3NGe9/cdw
	OhdAjKyMUmT18JUzo/hNYCPyWxxCBfStljLmZVbfY5YAOon0Hzh0Z33I59SknqugLje4GfXYpFj
	wZFZfBU9AANU05Ifta20wh3NW5Bb1xTj+cxNPQWutr3MOzqAJLn
X-Received: by 2002:a05:600c:1383:b0:493:bfad:9d99 with SMTP id 5b1f17b1804b1-4994e7caf7cmr55828995e9.13.1785923716237;
        Wed, 05 Aug 2026 02:55:16 -0700 (PDT)
Message-ID: <38863d15-c6d3-426d-b09c-3dbed9f2f0b0@suse.com>
Date: Wed, 5 Aug 2026 11:55:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 xen-devel@lists.xenproject.org, Thomas Gleixner <tglx@kernel.org>,
 IngoMolnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
 lkml <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-5-jgross@suse.com>
 <f06ccf87-c244-44a1-af82-52da3b01c334@suse.com>
 <5febc2c0-4355-48d9-9342-52d590041500@suse.com>
 <bbae3eb9-6d1e-4caf-a647-25ca9ca8a61c@suse.com>
 <a5cce538-87d2-40e5-8a8c-21102fb37a52@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <a5cce538-87d2-40e5-8a8c-21102fb37a52@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785923717-732B32A1-0584B9CF/0/0
X-purgate-type: clean
X-purgate-size: 2699

On 05.08.2026 11:44, Jürgen Groß wrote:
> On 05.08.26 11:04, Jan Beulich wrote:
>> On 05.08.2026 10:55, Juergen Gross wrote:
>>> On 05.08.26 10:44, Jan Beulich wrote:
>>>> On 05.08.2026 10:21, Juergen Gross wrote:
>>>>> --- a/arch/x86/xen/Makefile
>>>>> +++ b/arch/x86/xen/Makefile
>>>>> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>>>>>    obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>>>>>    
>>>>>    obj-$(CONFIG_SMP)		+= smp.o
>>>>> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>>>>>    obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
>>>>> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>>>>
>>>> Similar issue here - in a PV-only config smp_hvm.o doesn't want / shouldn't
>>>> need building.
>>>
>>> Note that I didn't change any functionality.
>>>
>>> I agree that it seems a little bit strange, but in the end I believe
>>> the current status is okay-ish. PV-only hasn't been something in upstream
>>> Linux since Xen support was added, as PV was always meant to be an
>>> alternative to bare metal support via paravirt patching. It might have
>>> been possible to build a kernel not really functional on bare metal, but
>>> this was more like the ability to build a x86 kernel not working on any
>>> existing machine.
>>>
>>> IMO the Xen kernel config options should allow for adding Xen-specific
>>> features, but minimum Xen support should always have basic HVM support,
>>> which includes the Xen specific performance enhancements.
>>
>> I fear I don't understand this. If I want a kernel just to run as PV Dom0,
>> why would it need to carry anything HVM-ish? That is (or should be)
>> entirely unrelated to being able to also run this same kernel on baremetal
>> then.
> 
> The fact is that Xen PV-mode was always a feature not really liked especially
> by x86 maintainers (this is the polite way to phrase it).
> 
> Changing something outside of xen-specific parts of the kernel in favor of PV is
> nearly always a fight and I'm pretty sure I only get changes in by playing nice
> (not changing more than absolutely necessary and cleaning up constantly). I will
> certainly not try to push for a "PV-only" kernel while the hope of the x86
> maintainers is more "PV will go away some time in future".
> 
> The capability to configure the kernel without HVM stuff but with Xen support
> is the way it has been since many years now. Nobody has missed a PV-only kernel,
> so I conclude there is no need for that.

Just FTR - I did, even if maybe I never said so explicitly. But as it's just
me ...

Jan

> The closest we will get here is a PVH
> only kernel, and this is possible by not enabling CONFIG_XEN_PVHVM_GUEST.
> 
> 
> Juergen



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 10:07:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 10:07:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383238.1626507 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYWV-000111-7x; Wed, 05 Aug 2026 10:06:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383238.1626507; Wed, 05 Aug 2026 10:06:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYWV-00010u-5R; Wed, 05 Aug 2026 10:06:55 +0000
Received: by outflank-mailman (input) for mailman id 1383238;
 Wed, 05 Aug 2026 10:06:54 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrYWU-00010m-45
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:06:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrYWS-00EVwl-QM
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:06:52 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a730b31-5cb7-0a2a0a5109dd-0a2a4504c2d0-34
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:06:52 +0200
Received: from [52.101.53.26]
 (helo=BL0PR03CU003.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a730b3a-b57f-0a2a45040019-3465351a0a1b-4
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:06:52 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SJ0PR03MB5934.namprd03.prod.outlook.com (2603:10b6:a03:2d7::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Wed, 5 Aug
 2026 10:06:48 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Wed, 5 Aug 2026
 10:06:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rZpW0BROxTfHjzuJU4o1GkK8FP1LTcwLhbe0ORRr/6owjGw86iXsl0O+ZXE8ltdHeP2sqDFcAUKuQ7iY5Z0+zCwGG+In7ByXobsRlSljMiGOkaElnPND1Y4wlzKpAKLVd1EHWR8Qx/1xh+nXm8+o3jCJQutuWh3KLdZO1Fy3xpg8/kC7myyuw5FYGQegqvDWgkCAbUboGIDPYDuoYb5hSM7dSx0VoP5ZZ12lqjGmedVULivHNKnsi8J6h5pIMstzBdBVDzLcMGdrVCjJYoiYbAKH21hyGqe6Ok44jG+cItP6wMVOA/iYNWKV8NgMw92VW9b/w7heeis0JPFbQVwt+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2ngLbiuAqbM9UA+pFpFmc+uYb8kAOJKSP7HZondo4IE=;
 b=SU79PPMnLEXMkygTdWYzxWbjgfl/CDQP3uVRRtuAqd3Owt/mgEGonjilqlKqS+3VkNqCRMpw1MpVSuWapnU3W7WowEN7aKdLqC9YfdGivCyBB6hirYb4Uw1+x7flEtC7MppMIudRfqyZnwTGeQmY8hRsTIrEeNNqC6cFmXXrAukSxcByKfdwI3Og1o2c+k/lJrPktNVGqwyeviiAdGxre3evlCOuoba9pYPLoprI+VErp7WO0I9YOAtWFr/BeoKCWpPKnpVk+D+UfEiZwdxSW/C9cyiOZCUhKnYqxrFYtWMFvCqb4pRhBODX3qe/qCprzC2GPsQIaBr7cS1SQZPu5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2ngLbiuAqbM9UA+pFpFmc+uYb8kAOJKSP7HZondo4IE=;
 b=ptx8NVG/S7FsCtDsFQzBvrs4/3ZOFPSIs6yROOn/vX4LsQGTlu4WAdijuZZrmkt6fVoSQrI/VcQKQoF2WBCjFmK81zPajGTFS90QTXSAdRKtcJH2JM+ru6dNSpu2g1gHQivv79jAUMpF2YowToMcoPfLNWeJWMkcDcxpSVk2ZjM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com>
Date: Wed, 5 Aug 2026 11:06:45 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org, George Dunlap <gwd@xenproject.org>
Subject: Re: [PATCH 5/5] vtd: Move intremap table to xenheap
To: Jan Beulich <jbeulich@suse.com>, Teddy Astie <teddy.astie@vates.tech>
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319343.8631fc262581453bbf619ec5b2062170.19fad5345fc000e099@vates.tech>
 <451978a5-7dfd-4b91-a241-eb13caf6d394@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <451978a5-7dfd-4b91-a241-eb13caf6d394@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO3P123CA0031.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:388::10) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5934:EE_
X-MS-Office365-Filtering-Correlation-Id: 00404da1-281d-4aab-e806-08def2d9435d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|6133799003|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	NZDK67+P31eRWs/XL9YxnZy8QNfGQ97iYJ9YMjT1ybptJCdQP6QOr/8tuIAqWK8p5AwK8HoMBKMOZ7Ixz+2u4qkYcqjjpId8BSzHdO9e2/REON2EBykS8qM3Krcv7qH9TnkIRjpoqpsMYTftdc/g+xc/E3ILwuCdFx3Bh81OLEJvzRZOOu+fMUa9gj0Rsfifqi7Q+KCw5gsEfSGNyCh79okpCXWwl6PiHF4FQlIav0Juf9kmJzF+HTiaB5pUxhDyP79crRRchTj10UHpPhEQr+vO7xscNZboqUiEXIWDCuWJFHrQkYZKj00wJ1ELVT/6OsJi+UF8srfIvubu74/KSyPEwkqZkT02Q98PjTBHDpwQOJmeYtS4cjtgBy+4zgXwfNBOUsb9eS+2Fv4eC4c/PAdK2dVPo+j48MQuf5vXBAi0BkZNe16KujfeJqFgfW09VndVjLwD/4UnG6SCbSbeJ9i3ZAofNphMss70sQlixA4ofFq/Jwqy7epjztLm7W4Dg0/dPCks2UyObozjmvea1/a3+GtutD9Q8XFbqyksbcEyWmZUrdQxi+RPKBoxnj/PIDohEZi1DXutTAKQ51lD8I11ytHlQaHrlBdqk5pi2a3PQIN0KC9Pnkb05bCBJVRH5dgYdqySr134LGb/N/xwAg/nEC3trSwFdqe7PNLT0rY=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(6133799003)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YUpMa0FUU1VER05VOHk2aEpKUlVHQ2JqNjZ2cnA1Tk9TYm1Ob1JrT3NPN0lZ?=
 =?utf-8?B?Y0FDZ0FrQkpYRjZ4cmEwNWo1OEJySGMycWdWc3JBZnJxQlhYaXhFbk9TQlQ5?=
 =?utf-8?B?d3VlVk92Q0dxazV0clFTbXRSRDZXbmxmOTRnSWJvZVNETUJ6SnI0SER4UStm?=
 =?utf-8?B?c0pySkgvV2NhNkZjN3d1VkZVWGRqdjNsNkdrQzNWNkg0NlRzeGxyS1praUZL?=
 =?utf-8?B?SVl0Qkg5eWpSOG9RYVN2Y2VEekpzM09ldjZCdml1QWpBcDhrd29DL05jWkRQ?=
 =?utf-8?B?V01Kd1pTUFBQRHE3dVQ0bFpwWlJqUVBmSFFGS3EzUVQveDFsN3MzM2VCcWtR?=
 =?utf-8?B?QVBESnJuMHFrRFM2WmlKQmZXdmhTSHZEdHdqencrV25lZThpMXp4NGk0L0o4?=
 =?utf-8?B?cDB0b1VmU3prUWhCWmxIaGwyYitBaEdNdUs1dE92UEsxMnJxVmRmTEF0Zk93?=
 =?utf-8?B?WGY1VktzZzQ5NXVGUVdjTFhnZE9yTEZaYkU2TEdhajBlUElYSExibmFjSDg5?=
 =?utf-8?B?MmNFTU5EOFdQVis5ZHFYWTgzZE5sQS9UdmRHcE5VQnF5dHlUTG40UitkNjRY?=
 =?utf-8?B?TTQxZDlBOWN3dTdNM0hWM0RVV2FlNnJpbWZScFVNVzVrTjh6VzJPVGZ0R2Nz?=
 =?utf-8?B?WWlHWVMzelU5aWlSV0tzMWlVR0dDK1RaQ0ZDMFp1R3VUQ3gvd0d5NWtDa1RD?=
 =?utf-8?B?eEM4bThNZWlZUVk5b2loYVU2U1d3cmd1cHZtZ2ZNbk1sSnRNejlIWFhCNVdy?=
 =?utf-8?B?bGxmQjZ4VXhrdkNWQ0RadHdld3RqOVhmZlZubEwyQXNSUUtGSlBGak9Fbm9K?=
 =?utf-8?B?Vlp2VW05enBBQ0xCTy9VSVFmN01vQTAzNWVJOW8wNmU1SnBrSzlnVmljMzlC?=
 =?utf-8?B?WndhMndUUW55ckhnMmJrNnd3aTR3VnQ2eFZWNnJTckR6L2lEUFJNcWZNYVR5?=
 =?utf-8?B?amJjT2UzSWhVdlhwWlNJaWpJbW0vOEdTWnJIeTNsYW9vUlhySHZ4Q0FMQlRQ?=
 =?utf-8?B?SExxaVdSbkkxcHFsajdEc25ieFBXTkpsSHBiUndLT1pJUzRxRU9KRmJlZnNs?=
 =?utf-8?B?aFVUOEhabTE3V0hRSW02b3o0M0krT2dxc2ZrbVFNQkQvcEkxSElzZTA3ZWRa?=
 =?utf-8?B?d1Bld3ZCY1hxSlhqZi93VXE5YlVUNEFwL082NVEva0hwV1pUZkxmTkF2VEJz?=
 =?utf-8?B?SXZsWC9HeC9idHFFUVZGQU9qenVKUVlCdU5rdUV4RFo2UCtXZUFZWFl4T1RB?=
 =?utf-8?B?QzRjQ3pmaU8zSk5IQmRVYVNRQnhIK09CWXlSbUErdWs0UGxxUEd5TnVaaFgw?=
 =?utf-8?B?V3BPQkVtMC8vWHdRWjFNUXpaVTRmcnFYaWV4Nng3cStGMHZKNFlTSWtnYnRI?=
 =?utf-8?B?YzZ5WXFvVmFqWEs0WjZOSVdSSnJFbXhsLzlYbVpzZURHTUdJQVdXbGVJZ09Q?=
 =?utf-8?B?T09IVzFxdDBDc0xCeTV5djB0RnRJVGNrcGIzZ1NFWHlmUDZQV3hHazQ4Qjhy?=
 =?utf-8?B?QkR2enBqTnE2RHZiR1pyd2ZWNWRRUExYN3N0TGd1cG1qNy92emhMcXZ2TkhG?=
 =?utf-8?B?cEJJVFF0UXhDdnZ1bnZuUHJpWnBUVUFwSE5XTXRibG9zeWpGcWtwRnNOZ3Fv?=
 =?utf-8?B?V0lOWnJmSWRrdzg0M2ppeEJoR2NmZ09mNjMrNCt2bVBNUFBnV2NTcDUrV3oz?=
 =?utf-8?B?amhsc3A2WXl1cFdoR2pGVUd4cTk4a0F6N2tUTGh0Q0pHZWRxYnorVlMweHZ1?=
 =?utf-8?B?ZEZvNW5ZTmtMQlhoWjAxSTRhdThSZmNKZFk0TGZlMU8wc212azMvQm1pdE9r?=
 =?utf-8?B?UEx3clNiNmJLLzV3QlczeGJNRkVIdldBMUhnMDlYVWk3c0k5T0k3MWVadUVr?=
 =?utf-8?B?S1dnTDBlZ0V0SFVyK3dBV3drQ3FJUFV6YXdTcU1xZmJwUXYwVGpsYVl5MGpJ?=
 =?utf-8?B?RXFNazVWaGNqdzZHVnRSbis2bHZjU21oeVpxYjBuenFmeDE4TzhUSVlZY2NU?=
 =?utf-8?B?VkVlTGRRTlRkNlR2Si9lemRvOVRiZmZiM3grMzNZc3orNUFGNnNRNUdxOTZJ?=
 =?utf-8?B?ejEzN01WeDduYVZKZmkrTGQzYmRmMkRTb05wL3RoNEpSYjJHS2RKZElXYklI?=
 =?utf-8?B?bW5Ccks1MGZwckt6dndWbDBraXhPVDRYVGN4ZzB0enFBSWlqdWdLSzMxN0xV?=
 =?utf-8?B?alMzOURDUmdoeW04Mm1JMVorZStzaFNNWVFSYXU5TU5VSGVSR0d5TjBoNDd2?=
 =?utf-8?B?YWF3SVhRUi9rRDh6UWdCWVNrejlkK2w0c1ZGMnFHdnEwU1BWT09NLzV1S09E?=
 =?utf-8?B?TENScHZsTFk5aGx6cXY4c1Mzb1VBNGE1UmEwZ3pSU1VWOURaSjZyS2VEdGVU?=
 =?utf-8?Q?uGeaMyYmGgluv8lg=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00404da1-281d-4aab-e806-08def2d9435d
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 10:06:48.6855
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Xi/qAKsVZtzFpjbb9EwtP/JeNaykidKn+Na7v+39dYVrsa48NtHPtMWAc4MQgzPvWe9FUabqJezjEMOzKBORi27i1Zon4S3mcGK5gTOnIS0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5934
X-purgate-ID: tlsNG-ebf023/1785924412-C3EC6B50-0B76682F/0/0
X-purgate-type: clean
X-purgate-size: 1432

On 05/08/2026 10:44 am, Jan Beulich wrote:
> On 29.07.2026 11:59, Teddy Astie wrote:
>> Interrupt remapping entries often needs to be accessed, and we're creating
>> pointers to it on demand, which brings a lot of complexity (e.g
>> GET_IREMAP_ENTRY() macro), move it to xenheap such that it's persistently
>> mapped and we won't have to worry about mapping and unmapping individual
>> intremap table pages.
> Afaic: No movement from domheap to xenheap except for _very_ good reasons.
> For the case here that is - maybe establish a permanent mapping using
> vmap(), but no change in where the memory is to come from. Whether such a
> permanent mapping is really worthwhile may also want supporting by numbers.
> You say "often", but you don't qualify / quantify this any further.

To expand on the "why" a bit more.

For systems with all RAM below the 4T boundary, domheap and xenheap are
equivalent.  We have 5T of directmap, but xenheap allocations have a
width restriction which is a power-of-2.

For systems with any RAM above the 4T boundary, you can't have xenheap
allocations be NUMA-local for all NUMA nodes.


As for "often", the IRTEs are modified every time a vCPU moves to a
different PCPU, because the target addresses need updating.  While it
probably doesn't matter much today, in the context of ASI it's something
which would want mapping permanently, rather than on-demand.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 10:18:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 10:18:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383250.1626515 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYhp-0003JS-9l; Wed, 05 Aug 2026 10:18:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383250.1626515; Wed, 05 Aug 2026 10:18:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYhp-0003JL-7D; Wed, 05 Aug 2026 10:18:37 +0000
Received: by outflank-mailman (input) for mailman id 1383250;
 Wed, 05 Aug 2026 10:18:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrYho-0003JF-47
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:18:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrYhn-006kKh-1o
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:18:35 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730de4-e002-0a2a0a5209dd-0a2a450bc846-38
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:18:34 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a730dfa-b7e8-0a2a450b0019-d1558034a4dd-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:18:34 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so8219105e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 03:18:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994e52d819sm36549685e9.1.2026.08.05.03.18.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 03:18:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785925114; x=1786529914; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=KgX6bksTA+tpxqRFpettIyoHBmuDk3+MMPRxWFaS8nQ=;
        b=XKe6TalWKGw5laz8btxNAQY6Efuwnu2T7Q4q/cfliOHU5kKsG+JUUNMj9xwPLlSNRR
         jjS3yfcsIGgZiH2BXqV6Kxz1aOZwkUozwJIl1lU1AGGUaJDJGEjqtwJeg5dOaFeKbm/j
         e0MNWgTaVzvgGq3gyZj33cvt2e8pb7ccFWoae2Gv2KSkfCy5di49R89d8+fsoIHXQTAM
         EC32N/p05g5lHqFPR+Ymfqi9/Fpi6Eq1xoiXKH5OLYjBSZOWzs6hwwGQGyUaM3RDHBVe
         EnkOR2dNvuKbf8iHN+OE1rfNiNm+UFIo3Rh22GkKKXQZig9mPLD3R5b5UWQBk8RnWEPO
         iaIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785925114; x=1786529914;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=KgX6bksTA+tpxqRFpettIyoHBmuDk3+MMPRxWFaS8nQ=;
        b=ZCOy73LCHQzgz1T0PdVqZxLdc6TlYXmcMtQp9RhG0oro+ydxk/jWXlvwBx6NN1S2en
         XGPNVQJYekxnaEgwKS6QCKSSXqr6lNqhN/lS6yfradDyt+wRQCgvaVnO0Z5CPGB7mwEv
         hgOM1kMZB/QVWYVmZtQnbPiGJ+SKisn4oR5cIsg7Jlqg2/TYXC7eDMXpzd/8B0Wj6rHC
         paiAg3ChwKTQPTlQl7FX49t5G1cFT5S3KuTRBxicEpkuvH+l9VXewZSv4VRYGK6En/eB
         xD9wk/fvZlxlK0AIHVRQmG1mfbqfo9+znOWogKkscv4UJkUNZVr8AKQpzMntXDtOLWyb
         GcaA==
X-Forwarded-Encrypted: i=1; AHgh+RqoIa5aSvCAzGEqlTKBahrkzsZCe4HBHuibe+0vCFG9C7843KzshBv3WEyaiRCq7AM0oT/Odw0rFKg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy2JKhb0mblJR8tj3rhOyBHt+kT5LwugPc5jK7U68VrRKR5SBZZ
	gGmZ9OK1lIdqjWuLJAcP1N1SWybFXMfvemZxmdYxCBqSJ+boDWNkX2zGSa0+iK89NQ==
X-Gm-Gg: AR+sD12s7XECbUlpiY5TRXC8QwlxeSqa5y8fMtsFHvomO68HUuxxRDdDzMnO21nCbZE
	LO23wDY2Un67SVnJbwoSFzVzU1FnH9U/Xt/dAK4aEWYVuG6gP/QYWKHS5htvOcwRh3WSPIb26Oa
	SWwIdCNi7nz10tx7VeYgvNzgEKtbxqkHypS6PPGeLvFU2y6GhwQziv7AqAxg2QnrW4Hxs6VPBLO
	St0PZUdFe8lI8tznuH7q0Bi1ZegvT7g+g2mcvABpLKbTCLmFdZubEanrhCM16oXoY3HnLDqKpW5
	hqtRkTIvTtPm2wf0YxAwKwJc3YeryKWZlB4XfYFz6SSDC1YyHQgcF56p60+jFH6obBbgaM86OQH
	mTIR1u0WisEBxXkEAGfq8CwOdFGRlGtnQT6OUgBKWpF8lyoo3LAPnqMifR4GRH3sBeUe2A2Gbys
	hQWetmYm00jQ8yHtVKQcCZOTIzM4X87XMgkrbSr4Qn6aufjzLfEwbpq5klkz+ebqNBI05x88+VN
	XQKGLY4W+s7Udcf7ghmtWuUsKm8m6BWSfh6EtmoKxs1KcIvySZB2Q1Jvj9HU+A=
X-Received: by 2002:a05:600c:468d:b0:493:f478:4c71 with SMTP id 5b1f17b1804b1-4994e382cacmr65576365e9.7.1785925114418;
        Wed, 05 Aug 2026 03:18:34 -0700 (PDT)
Message-ID: <0491d3fa-ea8f-4cd7-822a-9c5a9be8d8fd@suse.com>
Date: Wed, 5 Aug 2026 12:18:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] acpi: reboot: log reset parameters
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260801031737.344756-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260801031737.344756-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1785925114-1B6D29EA-20318E4D/0/0
X-purgate-type: clean
X-purgate-size: 1659

On 01.08.2026 05:17, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Xen does not provide much details for system reset debugging in case
> system reset happens via ACPI subsystem.
> 
> Log reset I/O address and reset value.
> 
> While here, add the missing default case, add breaks between case
> statements and drop full stops in the loglines.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> - v1: https://lore.kernel.org/xen-devel/20260730001854.905354-2-dmukhin@ford.com/ 
> - CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2723268852
> 
> Changes since v1:
> - removed wrong ASSERT_UNREACHABLE()

And you replaced it with a printk(), which I don't view as helpful. If we
want to diagnose the address violating the spec, that should be done
elsewhere.

> @@ -21,17 +22,30 @@ void acpi_reboot(void)
>  	 * on a device on bus 0. */
>  	switch (rr->space_id) {
>  	case ACPI_ADR_SPACE_PCI_CONFIG:
> -		printk("Resetting with ACPI PCI RESET_REG.\n");
> +		sbdf = PCI_SBDF(0, 0, rr->address >> 32, rr->address >> 16);
> +		printk("Resetting with ACPI PCI %pp RESET_REG at %#lx (%#x)\n",
> +		       &sbdf, rr->address & 0xff, reset_value);

rr->address is u64, and the code here isn't arch-specific. Yes, the file is
built for x86 only right now, so 'l' as format modifier is kind of okay for
the time being. But really PRIx64 would want using. (I'm sorry for not
noticing this on v1 already.)

Preferably with that adjustment and with the excess log message dropped
again (I can certainly do so while committing):
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 10:36:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 10:36:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383262.1626525 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYyu-0006GO-MG; Wed, 05 Aug 2026 10:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383262.1626525; Wed, 05 Aug 2026 10:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrYyu-0006GH-JM; Wed, 05 Aug 2026 10:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1383262;
 Wed, 05 Aug 2026 10:36:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrYyt-0006GA-5d
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:36:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrYys-00BgL6-Ek
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:36:14 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a731210-5cb7-0a2a0a5109dd-0a2a4501c8c8-40
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:36:14 +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 <jbeulich@suse.com>)
 id 6a73121e-5984-0a2a45010019-d1558036e589-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:36:14 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4957eefd361so5911415e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 03:36:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994dfe64e0sm78375335e9.6.2026.08.05.03.36.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 03:36:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785926174; x=1786530974; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cxgXNItvPHboV3BvDE9sEHj4kQfZuokLFmgUl2MM48c=;
        b=PTIw2ISP6anGSWdHxqsktqe9s+Apk04SNSgAhixjYnEzH1SfbJynFruxJxsKcSt5L2
         6ygWa2KUbpbCdePdB6TSse+jsWvLa0efYKQMiEXNQ4mVEKgcYVgsJr2SB3kLCE/G9nD7
         98xDvsB39jxSiGFDLi/PQXwQfkdPoSELnHLGU4NuJMDUosZRT5ndvWPkdzxMaKrYW56D
         JvrHbdXp+lz5q+STG4js623YN99obSe3PjdPzAi/qbPCMZEgYLixBrgjEJJ/2SbBD5VV
         K1cihG+GKjvKpz9j2gXl1v8ztOa5rFwntTMTu83Hrd68/VPOveVujJrjoFgu643f0tfd
         VzpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785926174; x=1786530974;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=cxgXNItvPHboV3BvDE9sEHj4kQfZuokLFmgUl2MM48c=;
        b=drQqmZOnGlFjjVQ1h/132pNlm1YT0cuG0HsWTD6BHTco0cKsJ+RoUU23FSRyi/9mSk
         9WdeZfxNRDwgeP/39nwADOJHQrV1x+0Qx/dfflzeWCH4NoXryRsjTp2GciCKvrQPfnaK
         T6SktSxLLUvrBafccIXg4wRJfIGONcfjDV6WN59Xf8KCAJsHppoXwIc47o4i9XGCxfPU
         b4GahYFJH4qdkhVnnmhPyQh+SbIWETW2LDFz+qSoJHPN+UHGkHfa0WTt20TpoobAF40s
         3EWbm3VRcuvEEyxML1whtax9v6cnHA3ABFejzulci6VC/geYy64FfSr8FnEnkxfhItlg
         tflA==
X-Forwarded-Encrypted: i=1; AHgh+RqGcfdOd+xg9XonUkHzhRMMR8ilwAsoLxYq4xZlCxv8BJ7C+RGil07gRRFeR8jF+6vFMHO0OX5FtSo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhW+besQ8XKP+XaIRS96alWF07vCHqQfcrGOvJmaqQtnmw5pE+
	2SOztQxaJHgBzGjkwjjQ2l1d+MdwsUe5KNCByC35on0mkNr6jr8OEfC1Obw7SyElBw==
X-Gm-Gg: AR+sD10PWvyNBptxLntow9xQHo3qIUSccOE3ciOtdjyjlVGsbxN7HZENtIPOCpQY8rO
	4fS91wCzPHjll8svRotvqXTrNKSJ7WandCG8Qu7zXHQmlcXuh4tqy85s2XCHm6BMeSPbpD5YV0i
	OtGjdh3Te8pfef5n7mIldbTVPhWI/VbOneQ718l7vUxWF4s2NxzSbRfCvPnkSR8iGvOFiPVloJV
	t1MPMGb1dfpHxDGQ78DzGtUifIJrtlglLiDi7kmCdgXQ9NKJeNK0lBTNTkeQU4y2y+4rzO5H2cG
	Uc7VrCrv1MbcxpeBXmHMSsdPu9t/wHLmIXnedr3ELG+aQEng8vILdP0EH1DKjBKus3UNgkNvV+v
	Loeks8AHntEjnPl4yK8L/nIdan18MWJvPcxEQwIETTUTl7BVRVAQxx/eR9AhKwPzM/MACVloJyM
	UUJtouen8JzVFsMGnpjxJO5nkZgei2oeL5IRkVrLrC1ZTbbDxZoyuQy2fu7Iztq8nfvuw2ijkQw
	vixidO3C9IT0P25J9HY32mzI3B9/1JuKfTVWqvM1iH/TEI3vrhu
X-Received: by 2002:a05:600c:524a:b0:495:5890:8f6c with SMTP id 5b1f17b1804b1-4994e71d349mr54947375e9.7.1785926173790;
        Wed, 05 Aug 2026 03:36:13 -0700 (PDT)
Message-ID: <ff01adce-5807-4fda-becc-3290ad6deafc@suse.com>
Date: Wed, 5 Aug 2026 12:36:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/nSVM: Check the L1 IOPM_BASE and MSRPM_BASE
 assigned physical addresses
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <966e58864089efbe30e9b900f09005fe13c74729.1785335079.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <966e58864089efbe30e9b900f09005fe13c74729.1785335079.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1785926174-BF66C757-4FD77AB2/0/0
X-purgate-type: clean
X-purgate-size: 1487

On 29.07.2026 16:38, Abdelkareem Abdelsaamad wrote:
> @@ -294,6 +296,24 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>      enum hvm_translation_result ret;
>      unsigned long *ns_viomap;
>      bool ioport_80 = true, ioport_ed = true;
> +    gfn_t ns_iopm_end =
> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), (IOPM_PAGES_COUNT - 1));
> +    gfn_t ns_msrpm_end =
> +        gfn_add(gaddr_to_gfn(ns_vmcb->_msrpm_base_pa), (MSRPM_PAGES_COUNT - 1));

Nit: Why the excess parentheses around the 2nd arguments each? Without them
the 2nd instance also more obviously stays within line length limits.

> +    if ( gfn_x(ns_iopm_end) > domain_get_maximum_gpfn(v->domain) )

I don't think using domain_get_maximum_gpfn() is correct here. Imo you want
to merely check against what the guest is told in CPUID. Everything else
ought to be properly covered by hvm_copy_from_guest_phys() /
hvm_map_guest_frame_ro() already. In fact for the MSR bitmap I thus can't
see why further checking would be needed. And for the I/O bitmap it looks
to be a matter of better error handling, rather than introducing extra
checking.

> +    {
> +        gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n",
> +                 __func__, ns_vmcb->_iopm_base_pa);
> +        return 1;

Why literal 1? Yes, there is another such return in the function, but no, we
don't want to extend that. Aiui NSVM_ERROR_VVMCB is meant here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 10:39:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 10:39:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383271.1626533 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrZ1e-0006pN-2E; Wed, 05 Aug 2026 10:39:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383271.1626533; Wed, 05 Aug 2026 10:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrZ1d-0006pG-VP; Wed, 05 Aug 2026 10:39:05 +0000
Received: by outflank-mailman (input) for mailman id 1383271;
 Wed, 05 Aug 2026 10:39:04 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrZ1c-0006p4-5f
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:39:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrZ1b-006oEi-FL
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:39:03 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7312b8-bab6-0a2a0a5309dd-0a2a45099690-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:39:03 +0200
Received: from [40.93.194.57]
 (helo=SN4PR0501CU005.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7312c5-be1a-0a2a45090019-285dc239327e-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:39:02 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by MWHPR03MB989486.namprd03.prod.outlook.com (2603:10b6:303:2a9::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 5 Aug
 2026 10:38:57 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.013; Wed, 5 Aug 2026
 10:38:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=W+W0g7/jedY1MAiWaM+j/HHgLKK43EDgPP5ZKUZbA+0GpBGx3TqCYZBruDtefgL+DoYkpIeOh/NArljBSAKBJgT/vje5qKaRr7VeEZ1/487v/B/R56mBEic5csRIIV9qNFXfQgUJqpAtlkR9ZkWFb9kTssxtZVOIOG3x/AoCV0DP2ahZhs55+9JvodhUz8scNUmbH6QtXyj/3pBQd0nDo/XHbH2E8vhxsgroJnRdggtfri89fkIKH3G8AgB/sROWbfmQQbG0xnN7/JHFrRvKQwcpB4veloBgiatApP2YjS40o8Uf/tnRp/2tQvpNj0cs0/yvavvOmg2m4YSB2VLXiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2G36z5DJb7tx78qIdEDFAy0U8RinsowMaCbqdgXZMPI=;
 b=WYFOCygKpXVYtEJG5krxU9Mo3MGwgkEmxDpnNzlgUOhy/fZN9BiQ4SxKQKypwPXMqn0GlwpQaEEPIbKRsZBTblptXvABhZQzi2+/zVnZHWM5FOVxOd2ZDpF2UAneYxK7Awcn62mcfls/Z4mjzTKdT+DwHzEFpQtgKfNfCnEVLNhl2WNrcfEpE8yKYnCB4ds/suPAuh3U8FJrPfqIGbB71rgKaaZLs+K5ksqEqdLyELac+AtfneDYjaUImf08JyGk1zeDWYX94MlP2DI6z8mR0VGkh5xQwGUIsrwwff7sN9r3H0t/80D4UNnTffjvIF1RPp89o4KcW+tfGIEoiP9uWQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2G36z5DJb7tx78qIdEDFAy0U8RinsowMaCbqdgXZMPI=;
 b=A89ChuRU3tzrBtdAZT20KNxmV90Bq9ZIg9PajTv6v/+9zQg5YAm3pRWtnpDSdbGAytSs8YIN8l4uVDEMo2J1mbfTY12R96AeaI4/tXCYVPpRn5I+QFkOK1wtCgXY8BoLbpvqXU5tVHnJhh68wk1AypCQ1CE+kKAw/igeUs7Y9Ug=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <81729a84-dccc-4470-ba91-4e7689c387fa@citrix.com>
Date: Wed, 5 Aug 2026 11:38:53 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Subject: Re: [PATCH] x86: reduce dependencies on x86_emulate/x86_emulate.h
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <2a4d839d-44ce-40fb-af7b-5becd878c9fc@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2a4d839d-44ce-40fb-af7b-5becd878c9fc@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0059.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:153::10) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MWHPR03MB989486:EE_
X-MS-Office365-Filtering-Correlation-Id: 074451f2-4208-40ac-5bb5-08def2ddc0a0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|10067099003|11063799006|5023799004|56012099006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	m/YUzdVTEsZR0jLwB89c3a2t3NCf4AhImO3LMjphJaVgAdFEGqlCZiC1qk1Z0+ehyBrI2CZWJOWXNF8q5IYcrM3OAMYNh7mluVpX46csquPT0dLapsa3RpRaTi9ViXqTgXjJyKOD8tj0kQCY+0DEif3JGg5TWpug9JR7bjQVfXFhxxbqGiQwzX0ERXmiHJ3QbSIDHwGATo7VSWXCD36s42er+n9OJ4PerFQCOsU2d0VlkzAT2e7UXtpphj7o9TPTjgVUlQL8jtF0yc2CoX1JfpR1f9ku45LA9j4ZUMdt0YHAdYV4cIMFQyf8RC+/3COFO/jZzJqW/P7o2Q95RCYAb8F0qvxSzdHq//vEhQGRtrNPfEbaaQLk368PRug0pNpnH9lRXpJ135qjrM3u/PXFqVIr8A21wPdKMc/itZ6NkR5AnYG7KCDwbJ663jt+i/kPudsPDLzgj0Jift0gXk1NQyie5y2nV8WBofTSFWB67jeWnsNtZZea8jjyj5KKFKtJIF0SWnXUjc0uGG/+w2TZbrXUbcAAv0z/lLQHaYdJ16rFxM/m+C7HvlGqfnBidLqU4rVSxj5SvsbkeXiUHRhvL3b14g1tiH9NATGfGnsSQbnyxF3BCWbaszmvojnIc95GIBSufzEFvKWruKeVuMKOauNqXxD+LVKu64lIRAqo6xA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(10067099003)(11063799006)(5023799004)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a2g1SnBWajBuc01URzgzcWNQdmUxem1IdjNFQm9HNDNQQUhtbUlFRWlKS1Bk?=
 =?utf-8?B?WlRUalMzQ3hpZ0V4STMzNk1ZNEE2eU9pR0ZJSTloVUNRbU0zVnlLc3Q5N0pz?=
 =?utf-8?B?WU54T1ozMlRmaVpjVDVQOGRack5pcjZ2WE14MFZOaFBSSmw0UGNuS01nVDZR?=
 =?utf-8?B?K3hQT3hqTWpIV2x5WGZZZkVFVG5zK1JBN3ZuRzJROHRhUS93UERLQW54U2ZK?=
 =?utf-8?B?RTF0TnVnQnhsZGVMSEUwVEQ1VzlKNjBVMTA5RldOVEczZ21lQ0xWRTduZGRl?=
 =?utf-8?B?M0RacnhkNFJEUmxOTnZQRU1pd3RDRWRpZGYzcWt0d3JucWJaeEVxOStZWXUv?=
 =?utf-8?B?VHgrY3hlekxSSkl6TGxvN015VDR1aklNVHpiS3k4Rm1VaitROFduNjdYTWhw?=
 =?utf-8?B?RUM0Z0JadW1HR1NYQUlnZk00R0V0am1lZTdUcmN6R1BKclozdy91SUxGUGd4?=
 =?utf-8?B?VUpJWkhnaGY3Uk9qWGF3TUtKWTBaTXREWUdOL3ZTMk9qQWl1c0NGU3VIb3NH?=
 =?utf-8?B?NHdrWThDMGI5WHpLNlY4RlhLWVN6anVLbEhrbGdsc3ROSm96S1AwMk9DOXNr?=
 =?utf-8?B?NzJWbldzWTYvNlBLSDJ3aisyUnp0Wml2OVJheG5CVWk3Wkg3ZWJ4bGhSRkUv?=
 =?utf-8?B?M2tQeDVFbGxnUWNOenpmMzRJWWtEVEYveUdzRjI5UExmVHUySTlXckpseTdy?=
 =?utf-8?B?VUc1QzcyUFNmUEtIbWFwZjYwdEtMUi95Wng4TVo5amh4dDJjYmtUeVhSVFY4?=
 =?utf-8?B?Q3dIaFIwQTdLbWEvbVU1SGk1REpUdUE1Wk9DTFJIdC9wdE1KNUlMRkxOWU9S?=
 =?utf-8?B?ZnJSMnpRMXR1RXZVei84blF0R2RpdG5FeExmRFViYkN4eUxFNC9tdURjc25s?=
 =?utf-8?B?Qk1nTm1zbkZqK2pjb2FvTmtlY2ErR0pYVnhqRUkrTnEyTmVqdkdERmQxYzdW?=
 =?utf-8?B?RkhnQlI0U21EYTZZL0hlZnRiS211ZVFoNDV6SlZkZGF3T3AybDFseFhra0sw?=
 =?utf-8?B?YUY0ODg5UytkZGRNK3pRT2lWVjJRSmRyZExiUnFrM1RudXBiSldtbGg1dmx4?=
 =?utf-8?B?ZnhqMTloTENNVWhreTFNQnY4UnJqM2lUaUwxRktzR0xLcnNGWE9xdXFMb0Va?=
 =?utf-8?B?bWtMV296cWZVNVRSQXZKYUEwajhNU05nUXRRNkxzakpzeVVyL1dMbTJBTXIz?=
 =?utf-8?B?SU5uTEdwbEJ0S0Jla1ZXNFhML0wzRDVodGRQOTE0VStxZXhybW5CejNBZ0Z0?=
 =?utf-8?B?dnFUWkxvZHRUdDEvYmtJcE1IMEh5OVgxczV0V3hlTVpOcTJPcWRVQjF1YTBo?=
 =?utf-8?B?blFjcGJ5RlJhOXdsaDFiYy9iWTdYYWZBeU03aXc0Q2xwK2ZkbFBCMVByU0ZK?=
 =?utf-8?B?K1lOcVZlU1d0bXlGYVd1S2MwYXlJSWwra00xMkorL3NackowRmpPZGVqRHo3?=
 =?utf-8?B?QXV4RCthM3FBWUZFdzRvckJxVHlIekNRTjdtRWUvZ3hBZjQ3Qm5kVnNScDk1?=
 =?utf-8?B?bktsUDdlczg1WkNqTU9PdzBQRG0rc0J0dlY1K3ZWdFZ4dzBjZkY5OVpHeUNw?=
 =?utf-8?B?M2VyeE1UQU83eGVMaUVXd3h5dlpJN081NXJFbitNK3pubWNReEUrS0hlQXJP?=
 =?utf-8?B?T1lzeDBJdkpCcnM0M2l6SXhLRkIxVjZuYkR4NERNaDI4RERva09BMWZHSGtr?=
 =?utf-8?B?TzZTQWlOUm9xdVBONGpmVkpJSnVyN05lUmVVSEpwbFQ3TnBDdXByVEo1TDlx?=
 =?utf-8?B?Rk96Mkc4Ri85VHoycUVWejY5eGVaN2FmaXQvQWovRUxiTWVVcTJSWFJOaUZu?=
 =?utf-8?B?cjFqTWwxT0JOZVlWclFHTUplai93TmN2MmdMZzNQZy96M1NuMzVMS1JlbXFT?=
 =?utf-8?B?TkdNQ0lGK2Rnbm01MXBmeG1KSHl6Sm5nWVJ4c3ZoK0JnT0lEazJqWE1mdmZP?=
 =?utf-8?B?cGhDNU1UdkxhZFZmTEpyWFBob09McFhVclhBbkhPWVc0WGNkZzNMTVJjQk1M?=
 =?utf-8?B?K0tuLzhPa0VrNUVDNm5QRnN6VWpTVDRDQVZvaDJHc1ViaEhnQ09rMklna0Jm?=
 =?utf-8?B?NTkrRU5jb1p2RDhwMm5sQ0RiNFVPMGtkZnFBUkZJWllXRHV3ZnJQUFpRYm9t?=
 =?utf-8?B?ZVRIdjdNVlNaYUpBajkwbTV5Q0I2T0F4RU0zS2NnVHEzb2ZDNTZTOXRQQkZu?=
 =?utf-8?B?YmRRdUQyMXFtQWNwTzRxMWcvY0diMkV1YTkxd3M4cEcrVXhEdzBQTEJma3hC?=
 =?utf-8?B?VjhCRVNwR0FYUmR3a2N5NU5hOEg1V1NmVkhLRjJ6cmVzdGJxRkIvYmhuTGh6?=
 =?utf-8?B?L2pGRSszcHE2Y1oxeXAxOGxHNnV1ZXpZUUVlZFI0SDZud1RPMTNweFB6OS9I?=
 =?utf-8?Q?vdoEJ7zdGT5EW6L4=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 074451f2-4208-40ac-5bb5-08def2ddc0a0
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 10:38:56.8444
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 5OvAETnQXxiDsfe2NlywBbBmG5676F9GWlZM6FfBorXuRhQT4NprNJ4Hnr9/+O0PpUFwUFcXNIooH2Zvs/JSMZ1Kfc9y1dF/aTMRHJZlVvE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB989486
X-purgate-ID: tlsNG-bad1c0/1785926343-39CC7034-3817E674/0/0
X-purgate-type: clean
X-purgate-size: 1540

On 05/08/2026 9:29 am, Jan Beulich wrote:
> Split out struct x86_event to an entirely separate header, and move a few
> other items describing the architecture to a new x86-types.h. With a few
> forward decls of structures and with a fair number of new #include-s in
> .c files, the inclusion of x86_emulate.h (and hence
> x86_emulate/x86_emulate.h) can be dropped from all header files except
> hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

This looks broadly fine.

However, I don't see any hunks downgrading arch/x86/hvm/svm/vmcb.h from
x86_emulate.h to x86-types.h.  It needs struct segment_register, but
nothing else I can spot.

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/x86-types.h
> @@ -0,0 +1,76 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * x86-types.h
> + *
> + * Type definitions and basic helpers which are more or less directly
> + * describing aspects of the architecture.
> + */
> +
> +#ifndef X86_X86_TYPES_H
> +#define X86_X86_TYPES_H
> +
> +#ifdef __XEN__
> +# include <xen/types.h>
> +#else
> +# include <stdint.h>
> +#endif
> +
> +/*
> + * Comprehensive enumeration of x86 segment registers.

This comment has become stale with the recent additions.  I'd be tempted
to simply drop "registers" from this sentence while you move it.

Due to the way we use these, we should even technically drop the
trailing r from gdt/ldt/idt but I suspect that is going too far.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 10:43:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 10:43:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383281.1626543 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrZ5s-0008SM-Mn; Wed, 05 Aug 2026 10:43:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383281.1626543; Wed, 05 Aug 2026 10:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrZ5s-0008SF-JK; Wed, 05 Aug 2026 10:43:28 +0000
Received: by outflank-mailman (input) for mailman id 1383281;
 Wed, 05 Aug 2026 10:43:26 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrZ5q-0008S9-AU
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 10:43:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrZ5p-00Bh8Y-Ar
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:43:25 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7313c6-e002-0a2a0a5209dd-0a2a4506d6f2-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:43:25 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7313cc-195a-0a2a45060019-d155dd2bb919-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 12:43:24 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47f84023916so705261f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 03:43:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfda0cbsm7652648f8f.6.2026.08.05.03.43.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 03:43:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785926604; x=1786531404; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=w1Bb4vmR8cZXbl+BHofF+bpO39VFBzO9m9JaXAQs06w=;
        b=WGf1gFgCDF6dfHH31vFQ5XwdAgdfEabDfP26YBulucQaLizMy3S6Wvh1UsB1UKzuJi
         cjvAiXE+Hvx+zoAmStnWjR2TL47NSZtI+rbvTytyfFcwZ8Oxo6FXBCet3a/QDexHeQ1j
         2CEa9288VdSjurveL1YmbiRASBhpQQxZgdPb5dd+X8L4pAB9iISjWIvmVs47emVoZ518
         gKCxxz/fMGxVpBy/Afgjio20f/Ukz/u71Kk6fWf1md14MJcps+2ae8ZXu1DejWX4kznv
         oFCgFu5drZlQ1mqQnkPdSmUoMu2JIlgsAKD2Xd7dYoz2XwDgYLijo9DrhHn99GDDLLyn
         Qqaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785926604; x=1786531404;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=w1Bb4vmR8cZXbl+BHofF+bpO39VFBzO9m9JaXAQs06w=;
        b=OyXOmzjKXSli9g64F/fYdAd+QA4jBkvhH64YBR/JbV5ZITqGwePF0n0VCpE+Wm3xgm
         RRZWvHhWcqSZkkv/H6RQcbOecWsz+ElCtkmsUWwCnVd2udgpyeKdspw0vQgSoWClj0mE
         n+/5mzgUIt82MZMCNUNqkX6hG8+DQcyDemEuxkQbtEN5ZCE9Ouwl4syOkhtxXOuxIEgK
         7wZ93GslwdvmaVM1Gtt0EW2P5PBauLnJFGbTWKK1QfGVrVj4632Bd4i0sa/EWHTaBKkJ
         7c05ByIDr5Ov7iedrQfRydeDnlT2g+OtGSCH21xQ9Z9VbcVRfg8u3i3e1oMl6Z/wzPv5
         OSCg==
X-Forwarded-Encrypted: i=1; AHgh+RqvOtRO5mKJLGNifD8EAQAMmasTQf55JO06pP0nbqxhi4vS1b0HEvntKCGx7ZWugeCAJfo2rRMD0d0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGm8c1FRg91xx+3MTaEsx7vX56z1drFfQjungwH3dXCeWPrwle
	2NhK21QSM46C3J8qRL8oJckrnBn8LNxAWKWFzoS7SZWIPNor3BPv/yeA0TWoBOuos56s4RFJv2X
	aCDMOOQ==
X-Gm-Gg: AR+sD10CL/ZKTbXG3CFWioEsKlJBslzAO/RgmxhAR/MtROlPDlKb1iiu2ikFjHCJJGe
	HLYpwV84vcuIM1Cs9Xh0+6UTjSiNDr4k+XaNyjU7kGgeSML4SHQQd0Pk2DE12CbWVROXwXSbAoD
	DIDCjBVYcFHivH1UBAc2+YhXUOIQRFY9mMXETO3cjg/Y6oyZdLi+WkPrPUc2+swg/UpVaLlG/yn
	Pn/53AsBD7cJ1daG+/v3+SJY3qwqgJAvUkNDzP3QKC0Ge4RS3rXRXRb128Z2VQUcVP+8FBL8c15
	Wh41W81e6vAMaS1yiAYV/+Q9rgaDwLbpiJAcmXGwqKIoAxgOGjIsal4ZJFefIFCo5xZrqn/NgwB
	I+0r4CobndJ9j/OGCrk+vDjdtZef8bEOLhBFTcWZ37dFoYTyHoFhu08ThcCylEvlYbvZZ5u2r0y
	3a1MTC85JUnkIw2tiaIYnn3HFoDikWqY/0zovDbBO+BUZzQvd+lZvPNnAFeP6+qpH8PJW/Qz25A
	ELkrJZDJp328EjpDoeTN4FdXestWYF3J+tjAsy3oYkmW6hALWrR
X-Received: by 2002:adf:e6cc:0:b0:47f:97e9:fe60 with SMTP id ffacd0b85a97d-47fec51a252mr6403140f8f.15.1785926604441;
        Wed, 05 Aug 2026 03:43:24 -0700 (PDT)
Message-ID: <13dd0296-95d4-43e4-9d79-3ffa113927ec@suse.com>
Date: Wed, 5 Aug 2026 12:43:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86: reduce dependencies on x86_emulate/x86_emulate.h
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <2a4d839d-44ce-40fb-af7b-5becd878c9fc@suse.com>
 <81729a84-dccc-4470-ba91-4e7689c387fa@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <81729a84-dccc-4470-ba91-4e7689c387fa@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785926604-FD40B77B-5019A7A0/0/0
X-purgate-type: clean
X-purgate-size: 1624

On 05.08.2026 12:38, Andrew Cooper wrote:
> On 05/08/2026 9:29 am, Jan Beulich wrote:
>> Split out struct x86_event to an entirely separate header, and move a few
>> other items describing the architecture to a new x86-types.h. With a few
>> forward decls of structures and with a fair number of new #include-s in
>> .c files, the inclusion of x86_emulate.h (and hence
>> x86_emulate/x86_emulate.h) can be dropped from all header files except
>> hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> This looks broadly fine.
> 
> However, I don't see any hunks downgrading arch/x86/hvm/svm/vmcb.h from
> x86_emulate.h to x86-types.h.  It needs struct segment_register, but
> nothing else I can spot.

Hmm, yes, I can apparently convert that as well. I was really after tidying
non-private headers, primarily.

>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/x86-types.h
>> @@ -0,0 +1,76 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * x86-types.h
>> + *
>> + * Type definitions and basic helpers which are more or less directly
>> + * describing aspects of the architecture.
>> + */
>> +
>> +#ifndef X86_X86_TYPES_H
>> +#define X86_X86_TYPES_H
>> +
>> +#ifdef __XEN__
>> +# include <xen/types.h>
>> +#else
>> +# include <stdint.h>
>> +#endif
>> +
>> +/*
>> + * Comprehensive enumeration of x86 segment registers.
> 
> This comment has become stale with the recent additions.  I'd be tempted
> to simply drop "registers" from this sentence while you move it.

Can do, sure.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 11:21:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 11:21:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383297.1626552 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrZg7-000627-D6; Wed, 05 Aug 2026 11:20:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383297.1626552; Wed, 05 Aug 2026 11:20:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrZg7-00061z-9m; Wed, 05 Aug 2026 11:20:55 +0000
Received: by outflank-mailman (input) for mailman id 1383297;
 Wed, 05 Aug 2026 11:20:54 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrZg6-00061t-HH
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:20:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrZg5-004Kzs-EH
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:20:53 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a731c8b-bab6-0a2a0a5309dd-0a2a4507d992-38
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 13:20:53 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a731c95-b4ea-0a2a45070019-d155dd2ac0b0-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 13:20:53 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47f64ca1c2dso263173f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 04:20:53 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfe5b1bsm7185664f8f.12.2026.08.05.04.20.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 04:20:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785928853; x=1786533653; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=TDLOIIhSUY69RWK+VPCe0WXj5DQ3s8AJzrsRVAB1iYw=;
        b=IboKLv8M/CM1IgP9QcnSxbl9l6wYB9qszsncKZ8mFrlvCBhISjJL8RI7KxlZe2Wy9/
         S4ZNXi3RifWvzVsG2a5BEUGyGPp5h5U/C7+XNFB+cu2VqBtmwH34OV1aYjZkNmJfRUuR
         BitR53h2jw9krAMJCloElKUMUlVQw0DMC33CZB021eo566UgZ5v/VSNLfl9JNidf9/F6
         LwEtZZpaPz2USxsh8qGnwjTS0dQeiCUINiHhTOOaBlmGyELp7AGC7NOSkWWrUO0geC1a
         ABx0vCWytam5qQVPwBOn0ESoezDZ0sATZVsg04wmc6Fwmsh5AwNItIRg3x+ClX9fN5rR
         DRgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785928853; x=1786533653;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=TDLOIIhSUY69RWK+VPCe0WXj5DQ3s8AJzrsRVAB1iYw=;
        b=iyUCDs2PKcewM8YcRRufuqA8Q8sOwVrFMVVg5EIQagPR7zLe1Jj0B8Wy0nM1btUNcm
         GUI9Hh6cmMX8WyX77D57aEIluQvRkQcp7Yca7u24l2yZ0WmpaTxMGD4aAOtCotgWVjLe
         TNbWloB7tA/9Q5f3u0688EF5Z4xBevotuy0K7k14r9B+oEjkyMnpGntn5vl1i0nBbihD
         07QY+7r1fUK8xhDIIsVL+FuOhpbLmj/DuxkAk7GPRINl9HVk7Ax3LqpsgvTlT6w+CtK4
         MFWQhbCypHzUfUnSwwz6+zdtxIYIDlgbF4dhNvYsZkvF/Q7IhRA/4+B/t81yJhFRhNNb
         yWpQ==
X-Forwarded-Encrypted: i=1; AHgh+RqeXwgsQ2TXw7CC0HkzP8eXk0e7YFlFfiR4zq8aHQNvB2WhGVd7GxmeKTsXV04VM4YSBfdnrnNpnZM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxb0Osp9Z4mR/JIz3PITZNQ5sLrv5bkRen4E4+XoA/HuU4Ufhk1
	+C0EGd0xQTbis5dASdQ952zyKjuZrcDVAWUxeUj3PlyJepsHrN50rYbH
X-Gm-Gg: AR+sD101AwSFAMh0rJXbW0iK+c53eV2NFc4R/sQuzLdNS8ZS1tHmw5+77C8hCUQu7Jc
	jm1hP+4jrGV/774ELc2LQkxu1yWkR+eT4XcpAwyKGwiOT+/O3MSpMV8Fq+tlrN621jvrM3TwGgU
	DVuMadNuqk1xCDR/ywm/zvL9IMQBcEOAVnBYcUKrHY02FNgNCxMtVxm2imuOPmZfgvwvZ8+2PYl
	nrI18psWMJHDbm+Ypd5RYQ1e5amAQ/Y/bXGfY/7Wr3yeKMg7zX2n3Ru9X1FlxFB/BHduXqxG4K4
	Voa0lawvDFxt/WX97ptobsMSj7uOr38wWMeIXkh1Krb9tesFV3yitYKYaGePXKIkMPXAuahKYqA
	cvC4Mm4ZFCZDcUi/g8XtU7s8J2o4211rEYH7XydXuHzNtDm55hXwLI/lRqFmaV5wZhsa/qHNHjq
	In8PNjHxcGxagHRwZKCEN4fazQFmGlU3EkcDXtZQIgE6Cl2qmOhylLmc7PbQULPZDBRUziv30yZ
	2yfT0hBcAEnyQ3C2ieZP8rnjL7aE6J3F0kwFuHny9yzB5yqNBuQAA==
X-Received: by 2002:a05:6000:4608:b0:47f:9ac6:ca60 with SMTP id ffacd0b85a97d-47fec484655mr10521923f8f.0.1785928852613;
        Wed, 05 Aug 2026 04:20:52 -0700 (PDT)
Message-ID: <aeb81a44-3857-4d75-9b6b-e1143f357dd7@gmail.com>
Date: Wed, 5 Aug 2026 13:20:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/livepatch: Move init_or_livepatch_* into xen/init.h
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Xen-devel <xen-devel@lists.xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Ross Lagerwall <ross.lagerwall@citrix.com>
References: <20260803150925.408857-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20260803150925.408857-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785928853-A74D3AE4-45DEA9BF/10/73395122804
X-purgate-type: spam
X-purgate-size: 1184



On 8/3/26 5:09 PM, Andrew Cooper wrote:
> xen/livepatch.h is a fairly heavyweight header pulling in public/sysctl.h, and
> a reasonable number of users care only for the init_or_livepatch_* tags only.
> 
> They're arguably more init than livepatch anyway, and by moving them to
> init.h, we can remove a number of includes.
> 
> The include in vsprintf was leftover from early versions of the work.  In the
> version committed, d5ccf4482e4f ("x86, xsplice: Print payload's symbol name
> and payload name in backtraces"), symbol_lookup() had been adjusted to handle
> the livepatch symbol names properly.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger@xenproject.org>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Ross Lagerwall <ross.lagerwall@citrix.com>
> ---

Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 11:43:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 11:43:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383311.1626561 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wra1f-0000Ub-UH; Wed, 05 Aug 2026 11:43:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383311.1626561; Wed, 05 Aug 2026 11:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wra1f-0000UU-R4; Wed, 05 Aug 2026 11:43:11 +0000
Received: by outflank-mailman (input) for mailman id 1383311;
 Wed, 05 Aug 2026 11:43:11 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wra1e-0000UL-SU
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:43:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wra1e-006zTo-2D
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:43:10 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7321c8-e002-0a2a0a5209dd-0a2a450a9cfe-20
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 13:43:09 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7321cd-f2d2-0a2a450a0019-d155802ee1a7-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 13:43:09 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49554ebb87dso8042765e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 04:43:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994dfda45asm102990935e9.4.2026.08.05.04.43.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 04:43:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785930189; x=1786534989; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1MMNEWYOK+POe4jOwV1jz677BcJ7a9OOCBTCoAEQmRw=;
        b=Nn/DxF1P5Dvt/wYGdJ1rO/LTjj0Ufa5cZrEdokwm1wBltHrRuCjnXWaO5Jvc0KcmGj
         fT3JoJKmWytKjqNV2KUog+m/7UrfKHHobJfX4/FL33s5vld8LwBMTK0QLqKgcTEZmTq3
         2cXFjSiKW45IQvmNLW9y1sjgLoSIbA37L7dg+RziZRYJiM2GWMEP+BWW4hRGRg5MIuWf
         Iz/nj+PjDe/+dsqDwk1Vv+4tKjOR6p8sOIPpfR+6oB7PfGKGAbwZSTrVC1FKJnlOVg7+
         P89TWlgO7pKsF/Z3edCTE12AiZdT9i45i/afBRre2HQSsJA1r8cIpG2lryuNKBWq8RdP
         /6YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785930189; x=1786534989;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=1MMNEWYOK+POe4jOwV1jz677BcJ7a9OOCBTCoAEQmRw=;
        b=laRIUlQhhFPgJueAJfUWEQ27MLkOxEtGNye5iR5LYbcnD675KNbTxWbExXOqYqDbNm
         Fd+yd/AW6Ctc80pFYbWUECtx02xHaHIJHKsYhEcgjt1IEtwYd7vZig4k4EW6duxw+d0b
         DHQWjyTwd/dW//dT/Co55k+MpvoHp7GeGr4+2qJdfqaSpgxNxzsMBid5WNIdbV+C8m/P
         CnMZY2JsJb3bMzPHlN5ygob5G5IQmRoqdHYYHsmW6pd9U7pf+Zx5OB4K52QK6YEWC7zJ
         c0mLAMElh6Zns2AmcEciknriLyon5g9f+GOh57NbFcHT0ccbbR3euq7pyU/vbiR74T1T
         xKhw==
X-Forwarded-Encrypted: i=1; AHgh+RqVQ/SB860RTHBVelZBly3YJECEA7OoYdXu5wg1avkgDBSdCKKpc0Ed+ee2zdDIrIhxqv9l/et7kYU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5ainJqPg/Ermt7xs9UCE6xfl7lbSZg30ltRgvggeVDcOwGtk0
	32imtU9lCSytiGd2hvLNnYIfy+90E3eZjLffnXZMlO4D0G+fOetNCPs88SV8baSY9Q==
X-Gm-Gg: AR+sD130IJHhl68CpdLXfzuuqkKPPV3V5Uh+pHskal8s9Shc72fp0PXHaotP9I4N/pX
	C+uVp/4rnpBQJywy/XazPUKy/v8lpIpBchARzBnGXfzM2WR2L3LM3gIGriYY3628UI7yGtDvwHH
	Z5ffteMZA3R23iHTMctBXraK2ILZ98XF3jLgrYR1ymxaUoSfAUhTus3LdUHof8mhyugiiAA2Oz6
	ReRyKTeKVq0cOlFWQoZhfaUDD0iOpjV78FoFQhQTeu2Z7igrys3ViZcIbEH/vi5dDscfs6PpDSQ
	R6Y9hPuxUNy5OH5PpDlYc8OzbfzOCQfGrSAJXWPTQ/CNoTGzwa/EUSgF7X1tBUv9CNXAJPwEhNV
	UH7FKaadrI/86gVJpysE4fth8jBqo7dw1g9GwSPGtjvBpxRk3H/Pk7tn1vf4BP3vu9Ok7TCJZqv
	PnTG7TxN46gTHHpCJIe9HG5MIeWOvZKBDwJEJw6i7ZWe4VCLvxVHMmXhLfohvtbBoP88LVyt39c
	Az74krFgNLAddWrol+Fy1Y/07/ibMYJ0Omw7y7fI1wTQhXfl5Zq
X-Received: by 2002:a05:600c:8b23:b0:495:4d00:2fc0 with SMTP id 5b1f17b1804b1-4994e7bb12dmr64911675e9.12.1785930188902;
        Wed, 05 Aug 2026 04:43:08 -0700 (PDT)
Message-ID: <14dd261f-8d78-4c24-b927-f7f2c01dbdf8@suse.com>
Date: Wed, 5 Aug 2026 13:43:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: rename scheduler registration symbols
To: Furkan Caliskan <frn1furkan10@gmail.com>
Cc: andrew.cooper3@citrix.com, jgross@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com,
 xen-devel@lists.xenproject.org
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-3-frn1furkan10@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260804055327.22119-3-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1785930189-4B6D6CFC-18D1B315/0/0
X-purgate-type: clean
X-purgate-size: 1311

On 04.08.2026 07:53, Furkan Caliskan wrote:
> REGISTER_SCHEDULER(), schedulers[], NUM_SCHEDULERS, and the
> per-arch SCHEDULER_ARRAY linker macro now register and hold
> struct sched_ops instances rather than struct scheduler ones,
> but still carry names describing the old type.
> 
> Rename them to match the current behaviour.
> No functional change.
> 
> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
> ---
>  xen/arch/arm/xen.lds.S      |  2 +-
>  xen/arch/ppc/xen.lds.S      |  2 +-
>  xen/arch/riscv/xen.lds.S    |  2 +-
>  xen/arch/x86/xen.lds.S      |  2 +-
>  xen/common/sched/arinc653.c |  2 +-
>  xen/common/sched/core.c     | 33 +++++++++++++++++----------------
>  xen/common/sched/credit.c   |  2 +-
>  xen/common/sched/credit2.c  |  2 +-
>  xen/common/sched/null.c     |  2 +-
>  xen/common/sched/private.h  |  4 ++--
>  xen/common/sched/rt.c       |  2 +-
>  xen/include/xen/xen.lds.h   | 10 +++++-----
>  12 files changed, 33 insertions(+), 32 deletions(-)

I'm not quite sure if all of this is really useful. In many (all?) places
I think "scheduler" as a term is still quite applicable.

One (general) nit though: if already you touch malformed lines (overlong
ones is which prompted this comment), please adjust them to be style-
conformant.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 11:50:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 11:50:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383318.1626570 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wra95-0002C4-KS; Wed, 05 Aug 2026 11:50:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383318.1626570; Wed, 05 Aug 2026 11:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wra95-0002Bx-H9; Wed, 05 Aug 2026 11:50:51 +0000
Received: by outflank-mailman (input) for mailman id 1383318;
 Wed, 05 Aug 2026 11:50:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <matthias.goergens@gmail.com>) id 1wra94-0002Br-5b
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 11:50:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wra93-00EoM2-Dm
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:50:49 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <matthias.goergens@gmail.com>)
 id 6a73238f-bab6-0a2a0a5309dd-0a2a4506cdba-20
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 13:50:49 +0200
Received: from [209.85.216.51] (helo=mail-pj1-f51.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <matthias.goergens@gmail.com>)
 id 6a732397-195a-0a2a45060019-d155d833dd7d-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 13:50:49 +0200
Received: by mail-pj1-f51.google.com with SMTP id
 98e67ed59e1d1-38e42560ebcso782359a91.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 04:50:48 -0700 (PDT)
Received: from spider.bream-herring.ts.net ([103.252.203.158])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3903927db6esm2936674a91.10.2026.08.05.04.50.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 04:50:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1785930647; x=1786535447; 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=9VOjG1qeqbpED3aclWfN9lJ5XhH5+1/8WZV2to/loYI=;
        b=KKR1bP08mU+SuGjic3P6//TyuUZDxrUn9Ytstok6joEPW/pUUciN+vt4yFwuI+iLjl
         ylmmr2O0ljuIsjdR8sKXRW1d2ba9+jvXYVVae/6Z79KlovdgmoLVxfnlq1hhBtf8JyRb
         ZMwvHouttC4MZumNX8+TQ75Pv6qux3DuVOGeWjskLAagRDkpxKwfxY9X+hjE1Fp1YSW2
         Lqvf8Zr2ZNPjVtT5gGTyrRNH+mMlp2RCOmeWtHvabn1iozvPOGI38/rhE3iJ+mhocFXC
         d2g13h2YHAnQPD3j7puwkWdxZXFCEhwP3jcdr5JN/GSwrJ6ZSsEDmVxInHWhcZbEzHxB
         xc6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785930647; x=1786535447;
        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=9VOjG1qeqbpED3aclWfN9lJ5XhH5+1/8WZV2to/loYI=;
        b=bEQV+Li4vWyHNg8LLvlyXJWgpPjbm7OiQiO1iyayIqnk387xZb/r8ZHNbmgZdlC59o
         G1CwAU+byGGq2pCx7qnf1nx7HQY9209eUZUFzb805JChogkHdzOMihZ5Fr8ZWAnERSjW
         RGRYNXmJ+L52ZPezZ6HHWOfC3EJw7S8a9bLzoy4YpkmL7F0SCyPIi7ok+dtRForrshHV
         N2yfrqiXq3joeMA6AiZM+NKgwjun5SsnuHbryeUr6mzgi/uLHsSgJMJpVCewZQdQdyXm
         +e9dfbb7G1XgwPqizFmF1FeDs50vhNiLPqkPIctmhLDYTjCSUHv6ELRQUgUNOhRPqGmi
         ZHRQ==
X-Forwarded-Encrypted: i=1; AHgh+RpDUIyktbVk7NKRGl5K+DM9eBCC9iFPOLwstFIEXmJkfU4zmUe2+tzOkV+dU98jufGZrJfm2NDD2ro=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzHq2z7dKLO3lSXUqKzkagw30mTXYN9BnhQevBB9fGGlWJzKPbf
	Z0Fh9KISfmgYXr80KhvFS6RihyTXU8WZGFO0UAhm6cimqCFzQsl6XggV
X-Gm-Gg: AR+sD11k69vJlZItCT4mONKBT+SjNktcDFZVzcjYpaZDNAIgAxLv8Gxfc5SVHPw0xua
	LvJXBMKErySilrvSBvBAcaGF4SyX08SL4oqS89Q7H0/+WHBap0VF3c2O+Zwlm0wyzU8c1C/D0Qb
	lLsJJGAw8eoG+LCIPz4p63nHmUBlsswekj8WzOqXvxLAWk6CSKOBSriWDAGIN+IrXIiqsfb3fU6
	VVYYf81F7wcRQVvOFxnLSglFrRKdfsCOooe8iDB3gxWx53EMz5/mSS1igkovxzV4Ep+S9xkI33Z
	LCYCxS7oDhikvHfkk5XsqA82XPeJ1vFCKl3KfFhAigpXNaZ8X6k8rAjuNNTK5FKtNYblsmQp8bN
	UrI5IXaAgfHSBIEPKXj74rC7eBhKX2X8s1v71GEqbiGm+e1inOyA6+WoOPK2PZRbnVLyIck+LOT
	cTbXatxpquGZkAewV585Xu3iOmk0PGLn/MJZ8jmuCRI+zamDcMpakHR1DjaTINjlx5BrZ04XpWx
	WQfMkvqafc1turj1bGYq+WDBJtRKzhoWTfZXemBdaj2FCilyceuliAJ831T5eBJ9OUAF0cA4KgW
	L1NNrmN/bZBQF6PXkE6xHVzm/nWTZuhHgkGHJqvZHBxXPZsmOJzo
X-Received: by 2002:a17:90b:224e:b0:38e:9ef9:eb97 with SMTP id 98e67ed59e1d1-3903c5c443dmr5103146a91.16.1785930647103;
        Wed, 05 Aug 2026 04:50:47 -0700 (PDT)
From: Matthias Goergens <matthias.goergens@gmail.com>
To: Roger Pau Monne <roger@xenproject.org>
Cc: Matthias Goergens <matthias.goergens@gmail.com>,
	Juergen Gross <jgross@suse.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	Yannick Martin <yannick.martin@okazoo.eu>,
	Thorsten Leemhuis <regressions@leemhuis.info>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH v2] x86/xen: fix init of balloon stats again
Date: Wed,  5 Aug 2026 19:50:41 +0800
Message-ID: <20260805115041.409008-1-matthias.goergens@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260805094008.95778-1-roger@xenproject.org>
References: <20260730143548.39320-1-roger@xenproject.org> <20260805094008.95778-1-roger@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785930649-F440377B-5E610B4F/0/0
X-purgate-type: clean
X-purgate-size: 1104

Hi Roger,

v2 looks good to me.  Keying append on the source of the initial count
covers every case I can construct: by inspection, a domU always enters
the fallback branch (current_pages stays 0), so HVM/PVH domU and the
dom0 hypercall-failure path share the subtraction branch, while the PV
start_info path and a successful dom0 XENMEM_current_reservation append.

I also ran it on a nested-KVM Xen rig (Xen 4.23-unstable, Linux
11028ab62899e as dom0, static busybox initramfs):

- PV dom0, dom0_mem=2048M,max:4096M and 3072M,max:4096M,
  CONFIG_XEN_UNPOPULATED_ALLOC=n: no WARN, current_kb matches dom0_mem
  (2 and 3 GiB respectively).  Same with =y.
- PVH dom0, same two memory configurations, =n: v1 WARNed in
  balloon_init and returned -ERANGE in exactly these cases; v2
  completes cleanly and the balloon driver initialises.

(Scope note: PVH dom0 userspace stalls later in boot under nested KVM
for an unrelated reason, so the PVH evidence is boot-time dmesg and the
balloon sysfs state.)

Tested-by: Matthias Goergens <matthias.goergens@gmail.com>

Thanks,
Matthias


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:04:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:04:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383331.1626586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraMX-0004GI-V1; Wed, 05 Aug 2026 12:04:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383331.1626586; Wed, 05 Aug 2026 12:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraMX-0004GB-SP; Wed, 05 Aug 2026 12:04:45 +0000
Received: by outflank-mailman (input) for mailman id 1383331;
 Wed, 05 Aug 2026 12:04:44 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wraMW-0004G3-CH
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:04:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wraMV-00ErFj-Ot
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:04:43 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7326db-5cb7-0a2a0a5109dd-0a2a450a8a60-0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:04:43 +0200
Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7326db-f2d2-0a2a450a0019-d155d029ec63-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:04:43 +0200
Received: by mail-ed1-f41.google.com with SMTP id
 4fb4d7f45d1cf-69fab5a852cso1253176a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:04:43 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a1453d3825sm1959506a12.0.2026.08.05.05.04.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 05:04:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785931483; x=1786536283; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=5j/I7AVi0xll2QqyeskKm0Pq/Bxqw77h9LnRP5nnM64=;
        b=cSeU8aMzDgz7nHP55H7Q9PROhsawDqPN5VSqoe9KsV5HLpFio9CPAS4QDWtV+6bwSP
         kdjJl0eFnyUcjGlNbJ7UqvApFqfP5ewGjP0PtA2Y0q8XbPTygLk0kWGZtomHarMiV8wq
         UkdYcPy0Z1lcR8RPViFH8dRhtNJK+55xVHx20c/VVYu0XjGw3XnSh2+bIwtHyxY2SOue
         aa1DCrscknfF/qaimd0eMbVPuUCLhDfHnuQk5To0UfQD8IChc5xgxpFzS120s9FceeOv
         p5rxnLax7GIv42hVxQ6yHEQVpFPCMzG4Utjb+vHPNghgQmaR3qZl+LLGlz1v+A8qL1UJ
         vmxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785931483; x=1786536283;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=5j/I7AVi0xll2QqyeskKm0Pq/Bxqw77h9LnRP5nnM64=;
        b=p88DiHMNj1Iynq/yu82blkLmyS/jzO2OL2UAnrhWe8Mn7W2xfMoSHzoZBXnBeuhWCL
         W0zPQfWtvXtdAPE8eOiJ1ChoXdHQVz6vahGdSHshaQgQ4Ur2nyXf8sLo8IZ9OBNhO/sj
         4ECQLWdZ3Xy1K4CehZn1roOvUUKqj9MclRnJnFbo56wlL0r2SRu8BT0sfrhwCHjEha+s
         xpPOVd5/oxLjBEquxQrn/lRSocIsHgqeGL0VqDuin9JZU0MHHUfWm43PhHDtermEwDrA
         PNzNuW2Of4YiuNuP1nnfcqoEBd08ff3j0+DpL50svVFpFkC8pi/KgQP+1DxGAJAgSvKq
         htsw==
X-Forwarded-Encrypted: i=1; AHgh+RqDg+M0tFQrEgJ44UUfXJ4V01hFSBPVqrt1s8f3HCRBPr98Juy5ZygHtAMNAWvjr/fOGMfgtCYv4/w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhHeDafwjw2bxOvycteCACijEJTk/UfjS9q300HLDEUzib3LIS
	i12ltdzIfwrim2QfyT/eKKFfWV9FP561KKIyxnqVnLwa9rJSWv+wQjmOKMsnNzF3NB8=
X-Gm-Gg: AR+sD12hnxcYYQ2Iuux1o/rHyI6iQmXyjhaoq+xM0FI8N0nReUq3tBDhFRPMaNI0kKD
	eRL79Lkl73PDEeJlFSt8MTLz44zfsNKYdsfZGU6ieouIzw3faTEDA8NsumvPS5vCWCtpx/jRukx
	yetvUwEcX4+ZLafeIrKiJd25r4Dmn7V1vQXAXdSXEWa0u/Xj4VshydRQDwwir29a8HP3H2nwFA0
	C3i0cMU4+bcRHNLnbRNzW0xUuLEJOrixW3oD7oNmmsEfE7PfqichqGmR19N5Fhe/ktQ/LjQhRfi
	6OuduszGTTHZ3B7dRQ9M7MHAvT5j9pXUfP8fLefCGAsHllF9ul5QtkPQKOYIx+rAZ4P5IfSD4l5
	TXIvhmEKYhmPBkmbvU0HVhR7lzTl7oSClINZtqrZUV8G74/IOxVGqZ++4zBUnwmCQJ3WAsyHnOp
	vRvTogsg6y0pZGBQKeE7nQKzW7JQaZJCl0ZpsGHPy573BTWmRW6ELu4WzzPHKn3JKaaYEx+0yzC
	nnuISEm0g1GLPjyGhPMznA5AepK/1zNsNfhmbmegKRIEXBFRlS8mjy+Qec2ecLn0NItaqfoaMv1
	D9YGNiqQHPN6aE8=
X-Received: by 2002:a05:6402:e0d:b0:69e:2d56:690a with SMTP id 4fb4d7f45d1cf-6a14f0bbe0cmr3187654a12.8.1785931483058;
        Wed, 05 Aug 2026 05:04:43 -0700 (PDT)
Message-ID: <bed904b1-792e-4233-86a1-6c38678c9689@suse.com>
Date: Wed, 5 Aug 2026 14:04:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/xen: fix init of balloon stats again
To: Roger Pau Monne <roger@xenproject.org>,
 Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Yannick Martin <yannick.martin@okazoo.eu>,
 Thorsten Leemhuis <regressions@leemhuis.info>,
 Matthias Goergens <matthias.goergens@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
References: <20260805094008.95778-1-roger@xenproject.org>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260805094008.95778-1-roger@xenproject.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------nrg9apKmLaIB11gz9qpYEwWd"
X-purgate-ID: tlsNG-4011c0/1785931483-50CCBCFC-E207E094/0/0
X-purgate-type: clean
X-purgate-size: 7677

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------nrg9apKmLaIB11gz9qpYEwWd
Content-Type: multipart/mixed; boundary="------------D3cUtnDAbK80qUskmqQx0yJU";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Roger Pau Monne <roger@xenproject.org>,
 Roger Pau Monne <roger.pau@citrix.com>, xen-devel@lists.xenproject.org,
 linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Yannick Martin <yannick.martin@okazoo.eu>,
 Thorsten Leemhuis <regressions@leemhuis.info>,
 Matthias Goergens <matthias.goergens@gmail.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Message-ID: <bed904b1-792e-4233-86a1-6c38678c9689@suse.com>
Subject: Re: [PATCH v2] x86/xen: fix init of balloon stats again
References: <20260805094008.95778-1-roger@xenproject.org>
In-Reply-To: <20260805094008.95778-1-roger@xenproject.org>

--------------D3cUtnDAbK80qUskmqQx0yJU
Content-Type: multipart/mixed; boundary="------------OE5OoLbEmJF7vthcfOs1YCtK"

--------------OE5OoLbEmJF7vthcfOs1YCtK
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTE6NDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gVGhlIGhhbmRs
aW5nIG9mIGV4dHJhIG1lbW9yeSByZWdpb25zIGRvbmUgaW4gYmFsbG9vbl9hZGRfcmVnaW9u
cygpIGlzIG5vdA0KPiBjb3JyZWN0IGZvciBQViBndWVzdHMsIHNpbmNlIHRoZSBpbml0aWFs
IHRhcmdldCBpcyBzZXQgdG8gcmVmbGVjdCB0aGUgcmVhbA0KPiBtZW1vcnkgdGhlIHN5c3Rl
bSBoYXMsIG5vdCB3aGF0J3MgZGVzY3JpYmVkIG9uIHRoZSBtZW1vcnkgbWFwLCB3aGljaCBj
YW4gYmUNCj4gaGlnaGVyIGlmIG1lbW9yeSAhPSBtYXhtZW0uDQo+IA0KPiBJbnRyb2R1Y2Ug
c2VwYXJhdGUgbG9naWMgZm9yIGFkZGl0aW9uIHZzIHN1YnRyYWN0aW9uIGluDQo+IGJhbGxv
b25fYWRkX3JlZ2lvbnMoKSBhbmQgaGFuZGxlIGV4dHJhIHJlZ2lvbnMgY29ycmVjdGx5IGJ5
IGFkZGluZyB0aGVtIHRvDQo+IHRoZSB0b3RhbCBhbW91bnQgb2YgcGFnZXMsIGluc3RlYWQg
b2Ygc3VidHJhY3RpbmcgZnJvbSB0aGUgY3VycmVudCBhbmQNCj4gdGFyZ2V0IHBhZ2VzIGFt
b3VudHMuDQo+IA0KPiBJbiB0aGUgY29tbW9uIGNhc2UgUFYgZG9tVS9kb20wIGFuZCBQVkgg
ZG9tMCB3aWxsIHVzZSB0aGUgYWRkaXRpb24gcGF0aCwNCj4gc2luY2UgdGhlIGluaXRpYWwg
dGFyZ2V0IHJlZmxlY3RzIHRoZSByZWFsIGFzc2lnbmVkIG1lbW9yeS4gIEhWTSBhbmQgUFZI
DQo+IGRvbVVzIHVzZSB0aGUgc3VidHJhY3Rpb24gcGF0aCwgc2luY2UgdGhlIHRhcmdldCBp
cyBzZXQgYmFzZWQgb24gdGhlIGFtb3VudA0KPiBvZiBtZW1vcnkgcmVwb3J0ZWQgaW4gdGhl
IG1lbW9yeSBtYXAsIHdpdGhvdXQgYWNjb3VudGluZyBmb3IgcmVsZWFzZWQNCj4gcmVnaW9u
cy4NCj4gDQo+IEZpeGVzOiA4N2FmNjMzNjg5Y2UgKCJ4ODYveGVuOiBmaXggYmFsbG9vbiB0
YXJnZXQgaW5pdGlhbGl6YXRpb24gZm9yIFBWSCBkb20wIikNCj4gRml4ZXM6IDA5NDljNjQ2
ZDY0NiAoIlBhcnRpYWwgcmV2ZXJ0ICJ4ODYveGVuOiBmaXggYmFsbG9vbiB0YXJnZXQgaW5p
dGlhbGl6YXRpb24gZm9yIFBWSCBkb20wIiIpDQo+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBh
dSBNb25uw6kgPHJvZ2VyQHhlbnByb2plY3Qub3JnPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdl
biBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg==
--------------OE5OoLbEmJF7vthcfOs1YCtK
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------OE5OoLbEmJF7vthcfOs1YCtK--

--------------D3cUtnDAbK80qUskmqQx0yJU--

--------------nrg9apKmLaIB11gz9qpYEwWd
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpzJtoFAwAAAAAACgkQsN6d1ii/Ey/j
bwf/fx2QwqDkGGCIigcGoZhn8yP3B7uDWZ+sZc7Bm1NfMoo/yOxkhdwtrt2Tz6AXVZNRcRiSNMil
aI/cHFD+uTmUapvrFEk8BYKvrg6lJut7jSOIrlGxQgW1ymY3PNRidN3mYLiZMT4jBNIJLfm0a4Kr
yxYxKgZrdc4Je8rqiak1mFCfsbvQZUzcaasimPbr78cfa+ssRXV9Cvhmsdk0fNKcsEyXvO3ugdBY
ewD1FKFt5C60Sv3V9hg6q9BGlwzeDjQimm7z942/kx9xhxsK+8sv3W/wFhxSpRaQwSSsiO20gzlA
OtZTMDPJCc0COKJi+cp1ZQk1MFbCIF+gH2ArpKtlXg==
=TvOA
-----END PGP SIGNATURE-----

--------------nrg9apKmLaIB11gz9qpYEwWd--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:11:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:11:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383340.1626597 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraTH-00061e-L5; Wed, 05 Aug 2026 12:11:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383340.1626597; Wed, 05 Aug 2026 12:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraTH-00061X-HJ; Wed, 05 Aug 2026 12:11:43 +0000
Received: by outflank-mailman (input) for mailman id 1383340;
 Wed, 05 Aug 2026 12:11:41 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wraTF-00061K-N0
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:11:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wraTD-000RKK-Fr
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:11:39 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a732873-bab6-0a2a0a5309dd-0a2a450ba03a-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:11:39 +0200
Received: from [40.93.198.60]
 (helo=CY7PR03CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a732879-b7e8-0a2a450b0019-285dc63cc973-4
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:11:38 +0200
Received: from BN9PR03CA0277.namprd03.prod.outlook.com (2603:10b6:408:f5::12)
 by LV3PR12MB9095.namprd12.prod.outlook.com (2603:10b6:408:1a6::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.20; Wed, 5 Aug
 2026 12:11:34 +0000
Received: from BN1PEPF00004680.namprd03.prod.outlook.com
 (2603:10b6:408:f5:cafe::15) by BN9PR03CA0277.outlook.office365.com
 (2603:10b6:408:f5::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.15 via Frontend Transport; Wed, 5
 Aug 2026 12:11:34 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN1PEPF00004680.mail.protection.outlook.com (10.167.243.85) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.292.8 via Frontend Transport; Wed, 5 Aug 2026 12:11:33 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 07:11:33 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 07:11:32 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via
 Frontend Transport; Wed, 5 Aug 2026 07:11:31 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Iq8h8IzjFckCyOTXJiuJ7qlHw9hvr9TUbx60pEibpOP6Kdu+EsVe6j2Kw80Lb78PfgsRDwJkGNVB6peip3vRmBRV7+j1gM735HPI/bKE3e/xZPa96DtHr7z4715VqjZ9aXhtsNEQxiT9JMtWnfAoyrz7RxDxkAvwbXGAFtagFGmD691B52V3a8x1iABX5bRo9eHCocmG6NyHn7hVPj0CJmNKkc7Q4v+dPz5OX4XfCDFLj4SYIgVh1V5c279o0OF8FQ855qHVWRKm8lxseGDSbebVpv+UeR5ZT6fp/Ij+WCcDgvDiSEEPjhxcspUxHMennYk3kaVQlSrye/slyECBjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=unubrNBuqj+l9w841dcepEg1+HSa6SRJQulOWbGXmbQ=;
 b=HxPIgH0f+9HrEyKUpVqGklGyWYFPLtPuCE744HupCsJPrCDVivftbbLxXq0pNDVrAJlBGaNxxi3AG8b9aYEt2kaCAyK3FBc5zwPPkuR3lhhfZKwB8mHu5ynS7J2DuChnwItHo0ooJhDfu+aUYQShqqS+TdtpZ1lL33/bbH/kI/J/Awyt3AVVHI8NF4QkTrlRvyNU3j/z7bNJ1M/tGShbpgaSFR8+rD+4vLn65/gH/6hpyH3AXcNhAj+BVPUCTV5O5NtrlJbQjBBWoJvtDSmCHlu12hatv/0Byw+kAwJ/rTpfEdopi94exGxHoVn1e+6/d1P7PV1ir3r5SYy2sFaAgw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=unubrNBuqj+l9w841dcepEg1+HSa6SRJQulOWbGXmbQ=;
 b=OxzlD8e1ExXlTN3sVpBgGim+q1fFiR45FlSF1B5hwID/plXvgqNM28DRSFZjwpYVg7nIcl827NUzwjT9lBO6f8Nr/K8TrPXT/BJharvqnEN6UmBjobplgldREWlweiwYBEci+YmrZEdENQJTym7s9yJXf/Iiu9LQeZLlDRiJbXU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>
Subject: [PATCH] xen/dt: reject "xen,static-mem" when CONFIG_STATIC_MEMORY is disabled
Date: Wed, 5 Aug 2026 14:11:24 +0200
Message-ID: <20260805121124.150017-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004680:EE_|LV3PR12MB9095:EE_
X-MS-Office365-Filtering-Correlation-Id: 29b49c11-5aa0-4d4d-7399-08def2eab0eb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700016|376014|23010399003|18002099003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	BB1sJBMTcNGyTgToF77qGmz342YlYFXjJEb+0nvHRfGhny39QBU7qq8rrq4H9o2J57d9z9fmgxSNjOXv7nPQqEUY9wfk0K0iW8U3UKkBILd4Px0BjuyEvWBGf3KXmLPx5xRTY0RzXoZkhTpZwjnW/aDy7ZSBd6UUDvJ1xd7klijMP8/YPTagtgM6w4ei4oKPt7bh/a0u35Pyv8nhsgG2+O5uzC03tlxXWTL+VldQjWk727T2qvmLmAJbxU1PrTING3PmxQOwF1uOJbinjTuGkp+GzR+WwHp86hA3dwE2yAt9yqDM5lKo6K4pSb+CVvs0SynB6xqTDqGw6mUGgbOeGoBPzCw+TFLiGJY/diN9aM0tpGk/hpNNU1QCY1hsdtlM76U/e26WmDkoS0hYZv4GGcnhWuiE7AX9TUKjPLoExKWHxTkNct5oUZ5hiIFhRU3k4cfzmhMuU4wn6AgB7mZ4AXY9d8fh8hIjthOaY+blQiajLQ2NRhcYbQOCU8CwRcL6ELDynDZbBrTqQzBOuDdFTpyEZ/XuNvhLZT2wf5q12io8BaTgujsTu1nw30GVvmUJwUuhYoT5phW6jdk2ju5VzmqCyqBfvkcEJlQFu9WsM8TzHA76ApNa2hfpp5Rjh57h+rioxw13PytYJsvZGHiqaYpxNHHf6tjx7OCnS9hqWYM/bsKTcXvZJaaQt7khIR+bLjA1/qD/zC0z40YU1K26Ew==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700016)(376014)(23010399003)(18002099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	WXekfs5cg5Ioaj0ZgKl4J5ksnPXL41yeJdUOGL9N31ff3OVMLWu6bf/WGHs/jwbLVgD6mUt9az6O58XcvMq7gmQmSrNHtkpmkZVOuL4ykZn9GXH9NF3gNSI6zmJl6RyT/1qom4kZKHtdUHUfZw9Rd+c3CP1UYxS+uPoIxT9RHmby8m9qonUUJrWNdvI5DE2DRMgaOudNLmGbahECMu4qz8Fs/f0qhVj9gsMrkxgKnG+ZBWoXcDRVHz7rncudoTtB7QAENL/31fWjHTvOZtRRc0yiZxZaWrU0A9PTqOk6fGKZA77U++5XOZH435QrBay74oTHDXtLU3s1w3APbrQi246Fuv14lho1MVy2spvPsEh9zYpDtx2nx7Pfr+120LCgdI/AXz+5sfiLOUb/csWAtqKtgTJirxAydMnLND5Fu0DUx7hzKMrhuAsqF9u5xevn
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 12:11:33.7245
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 29b49c11-5aa0-4d4d-7399-08def2eab0eb
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004680.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9095
X-purgate-ID: tlsNG-42698a/1785931899-18AC89EA-276021D3/0/0
X-purgate-type: clean
X-purgate-size: 1483

process_domain_node() parses "xen,static-mem" regardless of
CONFIG_STATIC_MEMORY. With the feature off, init_staticmem_pages() is a
no-op stub, so boot carries on until construct_domU() reaches the
ASSERT_UNREACHABLE() stubs of allocate_static_memory() /
assign_static_memory_11(): a debug build trips the assertion, a production
build gives the domain no memory at all.

Bail out at parse time instead, like process_shm_node() already does for
CONFIG_STATIC_SHM.

Fixes: 41c031ff437b ("xen/arm: introduce domain on Static Allocation")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/common/device-tree/bootinfo-fdt.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tree/bootinfo-fdt.c
index 272b5a6c0ae6..ca64daf4cdc8 100644
--- a/xen/common/device-tree/bootinfo-fdt.c
+++ b/xen/common/device-tree/bootinfo-fdt.c
@@ -349,6 +349,12 @@ static int __init process_domain_node(const void *fdt, int node,
         /* No "xen,static-mem" present. */
         return 0;
 
+    if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) )
+    {
+        printk("CONFIG_STATIC_MEMORY must be enabled for parsing xen,static-mem\n");
+        return -EINVAL;
+    }
+
     return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_cells,
                                    size_cells, bootinfo_get_reserved_mem(),
                                    MEMBANK_STATIC_DOMAIN);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:15:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:15:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383347.1626605 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraXA-0006bv-2a; Wed, 05 Aug 2026 12:15:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383347.1626605; Wed, 05 Aug 2026 12:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraX9-0006bo-WE; Wed, 05 Aug 2026 12:15:44 +0000
Received: by outflank-mailman (input) for mailman id 1383347;
 Wed, 05 Aug 2026 12:15:43 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wraX9-0006bi-9u
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:15:43 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wraX9-006L26-0A
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:15:42 +0000
Received: from mail-lf1-f47.google.com ([209.85.167.47])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wraX8-00GCzS-2K
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:15:42 +0000
Received: by mail-lf1-f47.google.com with SMTP id
 2adb3069b0e04-5b28c91fba5so1192544e87.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:15:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:Cc:To:Subject:Message-ID:
	Date:From:In-Reply-To:References:MIME-Version;
	bh=IAx6f5biC3iTv+LdiiiwtGsshSnWp3OICO2uNsEBnTo=; b=mJPyro+NE58cJsdfG12gs5vvyr
	nkPuxedqJEQfj9Aa/lCavfquqgu9Z5hJHe2MZ3yO+/tdPHW/tTtVXS+3vj3USZGUHfisLKuIeOHCa
	M3oqRcCwBlrvOGeomeE6cA7lU/hEWcZ+8wmTvoDmmMireVCiw9/OxtimgPgYFxoKppf0=;
X-Gm-Message-State: AOJu0Ywsymk96fTsFbkJwYb1wPVYUsNifo8QYybdlr2Jf8wBBhHlyrMd
	WzgY/MK7DGuEsfPT8khciycenr7OfaqQYmOSBXJdUit/pOzmQzS1qB5qREtRFuI+9g02tPBk2uM
	fhcFjajtyFF5vT9p7ljgx/cj+lkYnZrw=
X-Received: by 2002:a05:6512:20c2:b0:5b2:c068:3530 with SMTP id
 2adb3069b0e04-5b2f488ed8bmr531704e87.13.1785932141585; Wed, 05 Aug 2026
 05:15:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com> <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com> <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
In-Reply-To: <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Wed, 5 Aug 2026 22:15:27 +1000
X-Gmail-Original-Message-ID: <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
X-Gm-Features: AUfX_mxhzcbGZ8RteTnwsFS0o1a3r0nJXrgamS0cpFvyyutHHEhD_1DDg1EdDSM
Message-ID: <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
Subject: Dual content (text/plain and text/html) on xen-devel (was Re: Linux
 PV domU with >1 vCPU never resumes after xl save/restore)
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Content-Type: multipart/mixed; boundary="000000000000e4836606584bba67"

--000000000000e4836606584bba67
Content-Type: multipart/alternative; boundary="000000000000e4836406584bba65"

--000000000000e4836406584bba65
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[Adding back in xen-devel, since this is relevant]

On Wed, Aug 5, 2026 at 9:15=E2=80=AFPM J=C3=BCrgen Gro=C3=9F <jgross@suse.c=
om> wrote:

> On 04.08.26 11:34, George Dunlap wrote:
> > On Tue, Aug 4, 2026 at 6:45=E2=80=AFPM J=C3=BCrgen Gro=C3=9F <jgross@su=
se.com
> > <mailto:jgross@suse.com>> wrote:
> >
> >
> >     P.S.: George, would it be possible to turn off HTML mails when
> sending to
> >             xen-devel?
> >
> >
> > I see both a text/plain part and a text/html part in the mail I sent;
> isn't the
> > presence of a text/plain version sufficient?
> >
> > Obviously sending patches is a different matter; but for that I'll be
> using git-
> > send-email.
>
> This is a reply to your mail using Thunderbird (which I have configured t=
o
> use
> plain text format as the default, in order to comply with most mailing
> lists
> I'm using).
>
> I don't think Thunderbird is an exotic MUA, but please have a look how it
> rendered your HTML reply to my original mail. I can't see clearly which
> part
> was written by me originally and was cited by you in this mail.
>

Thanks, this is what I was looking for.

Attached is the message Gmail sent.  As you can see, text/plain uses normal
`>` for quotes.

That makes me think that the problem is in Thunderbird.  It should either
take the text/plan part, and reply to that as though it were the only part
it had received; or it should take the HTML part, and convert the quotes to
text properly.  Replying in HTML and then rendering it with only space
indentations seems like a bug.

Thunderbird certainly isn't exotic, but last time I used it it was
definitely under-maintained.

You're asking every person who sends an email to xen-devel to remember to
take an action before sending the mail (or to send *all* mail as
text/plain, even if it's not to xen-devel), because your MUA isn't handling
the standard properly.  Is that really reasonable?  Couldn't you tell
Thunderbird to ignore html and only render text/plain?

 -George

--000000000000e4836406584bba65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><div>[Adding back in xen-devel, sinc=
e this is relevant]</div></div><div><br></div></div><div class=3D"gmail_quo=
te gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug=
 5, 2026 at 9:15=E2=80=AFPM J=C3=BCrgen Gro=C3=9F &lt;<a href=3D"mailto:jgr=
oss@suse.com">jgross@suse.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On 04.08.26 11:34, George Dunlap wrote:<br>
&gt; On Tue, Aug 4, 2026 at 6:45=E2=80=AFPM J=C3=BCrgen Gro=C3=9F &lt;<a hr=
ef=3D"mailto:jgross@suse.com" target=3D"_blank">jgross@suse.com</a> <br>
&gt; &lt;mailto:<a href=3D"mailto:jgross@suse.com" target=3D"_blank">jgross=
@suse.com</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0P.S.: George, would it be possible to turn off HTML=
 mails when sending to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xen-devel?<br>
&gt; <br>
&gt; <br>
&gt; I see both a text/plain part and a text/html part in the mail I sent; =
isn&#39;t the <br>
&gt; presence of a text/plain version sufficient?<br>
&gt; <br>
&gt; Obviously sending patches is a different matter; but for that I&#39;ll=
 be using git- <br>
&gt; send-email.<br>
<br>
This is a reply to your mail using Thunderbird (which I have configured to =
use<br>
plain text format as the default, in order to comply with most mailing list=
s<br>
I&#39;m using).<br>
<br>
I don&#39;t think Thunderbird is an exotic MUA, but please have a look how =
it<br>
rendered your HTML reply to my original mail. I can&#39;t see clearly which=
 part<br>
was written by me originally and was cited by you in this mail.<br></blockq=
uote><div><br></div><div>Thanks, this is what I was looking for.</div><div>=
<br></div><div>Attached is the message Gmail sent.=C2=A0 As you can see, te=
xt/plain uses normal `&gt;` for quotes.</div><div><br></div><div>That makes=
 me think that the problem is in Thunderbird.=C2=A0=C2=A0<span style=3D"bac=
kground-color:transparent">It should either take the text/plan part, and re=
ply to that as though it were the only part it had received; or it should t=
ake the HTML part, and convert the quotes to text properly.=C2=A0 Replying =
in HTML and then rendering it with only space indentations seems like a bug=
.</span></div><div><br></div><div>Thunderbird certainly isn&#39;t exotic, b=
ut last time I used it it was definitely under-maintained.</div><div><br></=
div><div>You&#39;re asking every person who sends an email to xen-devel to =
remember to take an action before sending the mail (or to send *all* mail a=
s text/plain, even if it&#39;s not to xen-devel), because your MUA isn&#39;=
t handling the standard properly.=C2=A0 Is that really reasonable?=C2=A0 Co=
uldn&#39;t you tell Thunderbird to ignore html and only render text/plain?<=
/div><div><br></div><div>=C2=A0-George</div></div></div>

--000000000000e4836406584bba65--
--000000000000e4836606584bba67
Content-Type: text/plain; charset="US-ASCII"; name="quoted-reply.txt"
Content-Disposition: attachment; filename="quoted-reply.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_msg1t17q0>
X-Attachment-Id: f_msg1t17q0

TUlNRS1WZXJzaW9uOiAxLjANCkRhdGU6IFR1ZSwgNCBBdWcgMjAyNiAxOTozNDoxMyArMTAwMA0K
UmVmZXJlbmNlczogPENBRkxCeFpaTFl4azRaWlo5KytCOXFSbl9KOFg2b2NoYkhyNDAzN21iQzhz
RGZzUnFEQUBtYWlsLmdtYWlsLmNvbT4NCgk8NjFiOWM5ZmItM2Q5Ny00NDgwLTgxNzEtYmNlOTg2
ZTY5OGE4QHN1c2UuY29tPg0KCTwzMTI2N2Q5Yi0wMjJmLTQ4YjUtYjU4My02ZDkzODBhMjI3NDBA
c3VzZS5jb20+DQpJbi1SZXBseS1UbzogPDMxMjY3ZDliLTAyMmYtNDhiNS1iNTgzLTZkOTM4MGEy
Mjc0MEBzdXNlLmNvbT4NCk1lc3NhZ2UtSUQ6IDxDQUZMQnhaWWZmYjNiT1M0Wno4bTJRWDUySjZW
OS1ab25heFBDVUxvcXlSTHBQS2gtVlFAbWFpbC5nbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogTGlu
dXggUFYgZG9tVSB3aXRoID4xIHZDUFUgbmV2ZXIgcmVzdW1lcyBhZnRlciB4bCBzYXZlL3Jlc3Rv
cmUNCkZyb206IEdlb3JnZSBEdW5sYXAgPGd3ZEB4ZW5wcm9qZWN0Lm9yZz4NClRvOiA9P1VURi04
P0I/U3NPOGNtZGxiaUJIY20vRG53PT0/PSA8amdyb3NzQHN1c2UuY29tPg0KQ29udGVudC1UeXBl
OiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7IGJvdW5kYXJ5PSIwMDAwMDAwMDAwMDA5YzcwMzUwNjU4
MzU1YjZmIg0KDQotLTAwMDAwMDAwMDAwMDljNzAzNTA2NTgzNTViNmYNCkNvbnRlbnQtVHlwZTog
dGV4dC9wbGFpbjsgY2hhcnNldD0iVVRGLTgiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBx
dW90ZWQtcHJpbnRhYmxlDQoNCk9uIFR1ZSwgQXVnIDQsIDIwMjYgYXQgNjo0NT1FMj04MD1BRlBN
IEo9QzM9QkNyZ2VuIEdybz1DMz05RiA8amdyb3NzQHN1c2UuYz0NCm9tPiB3cm90ZToNCg0KPg0K
PiBQLlMuOiBHZW9yZ2UsIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHR1cm4gb2ZmIEhUTUwgbWFp
bHMgd2hlbiBzZW5kaW5nIHRvDQo+ICAgICAgICB4ZW4tZGV2ZWw/DQo+DQoNCkkgc2VlIGJvdGgg
YSB0ZXh0L3BsYWluIHBhcnQgYW5kIGEgdGV4dC9odG1sIHBhcnQgaW4gdGhlIG1haWwgSSBzZW50
OyBpc24ndA0KdGhlIHByZXNlbmNlIG9mIGEgdGV4dC9wbGFpbiB2ZXJzaW9uIHN1ZmZpY2llbnQ/
DQoNCk9idmlvdXNseSBzZW5kaW5nIHBhdGNoZXMgaXMgYSBkaWZmZXJlbnQgbWF0dGVyOyBidXQg
Zm9yIHRoYXQgSSdsbCBiZSB1c2luZw0KZ2l0LXNlbmQtZW1haWwuDQoNCiAtR2VvcmdlDQoNCi0t
MDAwMDAwMDAwMDAwOWM3MDM1MDY1ODM1NWI2Zg0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNo
YXJzZXQ9IlVURi04Ig0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJs
ZQ0KDQo8ZGl2IGRpcj0zRCJsdHIiPjxkaXYgZGlyPTNEImx0ciI+PHNwYW4gc3R5bGU9M0QiYmFj
a2dyb3VuZC1jb2xvcjp0cmFuc3BhcmU9DQpudCI+T24gVHVlLCBBdWcgNCwgMjAyNiBhdCA2OjQ1
PUUyPTgwPUFGUE0gSj1DMz1CQ3JnZW4gR3JvPUMzPTlGICZsdDs8YSBocmU9DQpmPTNEIm1haWx0
bzpqZ3Jvc3NAc3VzZS5jb20iPmpncm9zc0BzdXNlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48
L2Rpdj48ZGk9DQp2IGNsYXNzPTNEImdtYWlsX3F1b3RlIGdtYWlsX3F1b3RlX2NvbnRhaW5lciI+
PGJsb2NrcXVvdGUgY2xhc3M9M0QiZ21haWxfcXU9DQpvdGUiIHN0eWxlPTNEIm1hcmdpbjowcHgg
MHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA9DQo0KTtw
YWRkaW5nLWxlZnQ6MWV4Ij48YnI+DQpQLlMuOiBHZW9yZ2UsIHdvdWxkIGl0IGJlIHBvc3NpYmxl
IHRvIHR1cm4gb2ZmIEhUTUwgbWFpbHMgd2hlbiBzZW5kaW5nIHRvPGI9DQpyPg0KPUMyPUEwID1D
Mj1BMCA9QzI9QTAgPUMyPUEweGVuLWRldmVsPzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9k
aXY+PGRpdj5JPQ0KIHNlZSBib3RoIGEgdGV4dC9wbGFpbiBwYXJ0IGFuZCBhIHRleHQvaHRtbCBw
YXJ0IGluIHRoZSBtYWlsIEkgc2VudDsgaXNuJiMzPQ0KOTt0IHRoZSBwcmVzZW5jZSBvZiBhIHRl
eHQvcGxhaW4gdmVyc2lvbiBzdWZmaWNpZW50PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkPQ0KaXY+
T2J2aW91c2x5IHNlbmRpbmcgcGF0Y2hlcyBpcyBhIGRpZmZlcmVudCBtYXR0ZXI7IGJ1dCBmb3Ig
dGhhdCBJJiMzOTtsbCBiPQ0KZSB1c2luZyBnaXQtc2VuZC1lbWFpbC48L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2Pj1DMj1BMC1HZW9yZ2U8L2Rpdj48L2Rpdj48PQ0KL2Rpdj4NCg0KLS0wMDAwMDAw
MDAwMDA5YzcwMzUwNjU4MzU1YjZmLS0NCg==
--000000000000e4836606584bba67--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:37:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:37:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383360.1626615 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrars-0001QI-Sr; Wed, 05 Aug 2026 12:37:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383360.1626615; Wed, 05 Aug 2026 12:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrars-0001QB-Ov; Wed, 05 Aug 2026 12:37:08 +0000
Received: by outflank-mailman (input) for mailman id 1383360;
 Wed, 05 Aug 2026 12:37:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Bertrand.Marquis@arm.com>) id 1wrarq-0001Q5-VL
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:37:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrarq-00CF1S-8Q
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:37:06 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a732e71-5cb7-0a2a0a5109dd-0a2a450ad472-4
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:37:05 +0200
Received: from [52.101.65.71]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a732e6c-f2d2-0a2a450a0019-346541473830-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:37:00 +0200
Received: from AS4P191CA0033.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:657::20)
 by DU2PR08MB10201.eurprd08.prod.outlook.com (2603:10a6:10:496::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Wed, 5 Aug
 2026 12:36:55 +0000
Received: from AM4PEPF00027A6A.eurprd04.prod.outlook.com
 (2603:10a6:20b:657:cafe::4a) by AS4P191CA0033.outlook.office365.com
 (2603:10a6:20b:657::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.19 via Frontend Transport; Wed, 5
 Aug 2026 12:36:55 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A6A.mail.protection.outlook.com (10.167.16.88) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.8
 via Frontend Transport; Wed, 5 Aug 2026 12:36:54 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13)
 by GVXPR08MB11541.eurprd08.prod.outlook.com (2603:10a6:150:2e2::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 5 Aug
 2026 12:36:22 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0292.018; Wed, 5 Aug 2026
 12:36:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=h7odzjxf8BQ6ldplA6o9NJqYIJqIoAC54m/QDw7BQ+1rcsopagJShSfQRDeRr3W2cd6tQ/iFwbvJMk1GPTqlnrp5fHj/sqb1FZh3n4Rn8I7A/0wI7ii5Vs/KYDlwvIocx6i9/hI4zhhoyzBRJqb+34bwvMF9DAlLkHI0CrKgl2y/oxkKBtMPe6mdh/hPlemNHvGOl6QW37g1z2IUIWHw08rMX1K5hO1uGegp95SG8uxj/wVf6FG2ru8YMkI3K7FK6ppQp0BTcSZqru2ar+EzYJaxdl2OBpaeISiI9OJdAidoF3XvYIiDpQZ7BO2RL59Ru6QbjvOoWI8+Rw5T1aPzIg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JDS7KKBKW4Tb50TD937EvBFtqo53hc8n1Bbyf2j1eKw=;
 b=ghW5l6iExF8jvHcUfAE1MbrYgm2gU46wSK6vJ5LNweDady4QSAKHL9S8EpN4TatP+JjRqNDKNxhhqVM6IFId7fM3Zm9481+JmsC2bkMyC6vpnOhCjyj4zsTMYjje13CmtCn+F45KiBv6W9Nbvhf4fpkDKyWRaFWGObb2KCqfUk+w/r34K3yRx9qH5wxlEYtU6Rc8dQLDH/JWH71nzEN69s6S2qIpuvZm7EWxWo9mT3mAGYBP5Z8/qsC7KK92z8DIjunyurODwonUnEZERm76o2LORQwYfcCbyvOAH1tesXmcVTjI57l3nmrNx8B9EoUKhG8VyYDZAGNktN6T0ihljQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JDS7KKBKW4Tb50TD937EvBFtqo53hc8n1Bbyf2j1eKw=;
 b=ACANzZEmhpaoSmtOEZ6JBoEGJ8c+Hz1BJPkip470x4r3cdkG0RSgOoQbinwStCBuqAnmKaN3VV0kXRRgWwAmysnLlzmUaurTT6qvBBe5LqGAopZ5eYZUhsN823lkIieYHCh/jf7zTrVDwg40lVeQF50X/Jd5Jo5Ie9SMXM+kCiw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=D7c7zbuXW9vzrQJLSN2rh4u9z1DdD6l3vx9tACVFVRiG80+8dgH5XOZwvwPa1owJ1pBZsovcl5dkFEJetLlPg4h6oSAXLd7/JaEd+fHM9LaxwoItd2W7dA1l0X0BvgTZ7mA9PPPij/V0+3rnXuav6RKvKBpC9nmVRJw3KTAI/DznymGI2YFlc9IynmwB2OA/NWZ6OAVIJFt0Wjv8sn12SPFUjddP8XI7CLZzkQqZUimRPkB6c+5R9kbLtE4ZpNZ46uutiJ7/fDXpiBJNkLEo1G+HLfpCvLzpfeP9Iu1Z2AK0zfogTVYEFQxw4AxfyFEM19o5Ko2UmyCghC7RdsAdfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JDS7KKBKW4Tb50TD937EvBFtqo53hc8n1Bbyf2j1eKw=;
 b=e2N3WIBLsWHA1nWjid7sKr32/wSTSDKGtZ7F/OA+70T5XWkYUVT2EkXG5iBzMdUw43wVJImLm1a9Uucs9ai5wlAxN/MM6DQAxb9bmlVmF92+XpJJu0R9ir33XXz3itcswbP4DKyuaUPpYgbR3TerlLk84vOHDIk7VIEX8Wr4lvbC7fuNcTVTcFs7ViBqHifROUuEeq5riiRhbtWshaDomXzPDQZVu0aQKR1jliKohAF/6ecUYVpvGVDgjYuKJDvcwW6T8mzIYclsM7zwUoGXt5QEvtpwknDLW8W+jA6yLnnYj953XCClq0HF3D6oJ08Ga1G8E4dT8de39Wk0p7kvwQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JDS7KKBKW4Tb50TD937EvBFtqo53hc8n1Bbyf2j1eKw=;
 b=ACANzZEmhpaoSmtOEZ6JBoEGJ8c+Hz1BJPkip470x4r3cdkG0RSgOoQbinwStCBuqAnmKaN3VV0kXRRgWwAmysnLlzmUaurTT6qvBBe5LqGAopZ5eYZUhsN823lkIieYHCh/jf7zTrVDwg40lVeQF50X/Jd5Jo5Ie9SMXM+kCiw=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Michal Orzel <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>
Subject: Re: [PATCH] xen/dt: reject "xen,static-mem" when CONFIG_STATIC_MEMORY
 is disabled
Thread-Topic: [PATCH] xen/dt: reject "xen,static-mem" when
 CONFIG_STATIC_MEMORY is disabled
Thread-Index: AQHdJNOUeuyw7dxJRkGaYTQIrzZGNraPZFaA
Date: Wed, 5 Aug 2026 12:36:21 +0000
Message-ID: <040DF1FA-14D5-466D-8139-22FA3B6C86B0@arm.com>
References: <20260805121124.150017-1-michal.orzel@amd.com>
In-Reply-To: <20260805121124.150017-1-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3864.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PR3PR08MB5593:EE_|GVXPR08MB11541:EE_|AM4PEPF00027A6A:EE_|DU2PR08MB10201:EE_
X-MS-Office365-Filtering-Correlation-Id: 8f4b0ada-5b17-4f34-6035-08def2ee3ba6
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|22082099003|18002099003|11063799006|56012099006|38070700021|10067099003;
X-Microsoft-Antispam-Message-Info-Original:
 TIDFX+z3m/b3vYTYKbaDpb136eYYyyyDqMHD0OkijxVkBFEj+v1y51ZisliATH/N8HKniy2hutSvqn6+dqOUXXYyekjWLWil1X4QOujQqbmPYK272ygGsxb8V8rxWHUk+49lKiAvkNzpo5ltHuWP7OD8DjvOh6f5RBmpNgNsNuQWoTi+Cw/VRoqL6ckytZ4o2UHQDP4XlZcyOzptmr6hEBd3aNxS0v8QQlSmdpZzrQkqBJrRE+cgNbT8+9yr4MiYb23glOaN+oZXrpqYKfelwThA3gffohZDPi7mIJ942+qpiPcbxuXo9ZKKQdAQ0EacN/94w7k99DAawTv6w1oHwLYeq6yzVrttlSUZRdacZ1xWEva3hhqtUZ5NYZnCufeQtxGwxI3XcxB9uR3/XLExxvbfEtFPo6bDYpL4CZL4Axvfqd10l8HvvEifFd5Qw73AKcsDQ4oT5DULhSomaJewN1D1+JCVeXWM7c+sGxKp/0f8ezqNwuFzV6UlejKHTBhGladUJr/fSSRA8kvLdbMyBT70sjFhuWGcJu7BgwfVvNkCVoQLGm5pcNay1Ttk0c/6Gn6P10kqJhJDwAeROYrY+LnBnNirp2uBkS4EAOkCCTtorQfvoeNrljX4SPfsOQGh/TENlRBqIEwsVcDLJlGm+RgiI7AFq372iwrA8+4EL2YrIdPiUkUEdOyn6PaBs7LeryIP55QojnIHVdhOWGYt7Vmzux6Hv7M+/JZW3w7wonI=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(22082099003)(18002099003)(11063799006)(56012099006)(38070700021)(10067099003);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EA34F65E996E7347A6833BC1BC22881A@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Exchange-RoutingPolicyChecked:
 X7PtPt1MGD9At8nACIU2GidkG9yTyUQFdU/Zb2z5p6Ufu6sUFAlWwwmD47wrW3+i4MRR1ldhW2wcUcwHcR4s+pNttJxTs/k+VQ2PAlCQK86lwOy3Yd6Nchu/Ea3blYSwk5PPbs8grHIpS/5lMBZciWm49+dRP+BBPOMcQXpJGvGf0Bjwd+E17TFx3eIVHgUlStcmvOnjDVI5gSbw+4ahAJD9zTLoODY2WxbnSjPRYIxOOmrW7+KoEdH8G/yHNCW3RC1e6eppMq7UiDLIYJdAYe6UFhni4O2eRRMef4OAManr8WASG9Am3Bq49q2D5bgEpuG1B9B+FyBqiVnDFYjnRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11541
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A6A.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	1bf17a0c-c981-452a-a2e1-08def2ee27ce
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|35042699022|376014|82310400026|1800799024|23010399003|36860700016|11063799006|56012099006|10067099003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	0GkIquKFzGmVa1D95dnUQVCCOinErv/ewQ5JM+bpUqO/UbhVujyh57uwgAlX3xLCBPaMBNlrpS+7SLXAvOFCX7chacZCP2OTSKkWIWcDD9xPCyS3qwgu6UIPtpIJTv1R/DIE/hx4zi884My30bDLrcZuur6vjNGPdJ1NFXALQpv7vRMco3lv2p9zIfwXv3qopHYtogRCwyBVwvZCeGqHIcBahg5pPMxuyQsSL2idC10HYMhUTuSnmb95Wyzw5QCmpj8e1sxPYLNf5QxQWKQE+aKmpTyY55NdPe0/dEDmFOmSTiuU5HENOYfQ9Eh9x6OUvWgiIA8WPWeQpuO4qyLNZ9Nymtx1eTKu00zkb6trdNRMRzG2BWKeMe2QGjhGhH5AazOkRVBP5ycRpoI+Xm3BkV1rSnJij8tFR02FFtRrMzDW7TCFZ9TFB4vizAULTcvPz80EcNlRRqvvpswVU9UKQlFyBPQVX1nTS7cY2T5SR4g9EtVsQk8nnXQtZTIy6uAa9mf5xM9EH7cH0vzCwo8gBzyoRDuwu21hIHr8VLT9ybL6XknUYawM20GXKIGHedE0I91KvdeJQO7GU8CvgdGV+U5ysbHuXFzAcIjCf5XCtWlXOZ5Nim6uAMXn9C6+Aw9jnw+0cpmi3bL1B5VenNx6aG/TN3TWEZowGPLFYM8iAywWv7x+YnDX7OmOg5jFGPksGMlHWmV4XdEi0DdFYYByBg==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(35042699022)(376014)(82310400026)(1800799024)(23010399003)(36860700016)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	2gPPcS+PgzxDd33T6BblDXVf5jxfhhE7qWGi7YSKuIbVwINACQu2ho4GolwwmuZt8Qp8QkbjYsFj6yU1K3vYx71wJkZ+NaF4d+sI9E7EfGdhDEeP+yyQnXnq8H4idD5VfpAGbji+Ui5NXarv6iI+Zb1aDs8pkxdibgsuo0uDCfxqZdJT0oSTNrlCCjO6aZoHOJLLqksgV13BabrS3HG2XDnpsJ6EvUMkpih8expzDtnn6E7r9TvUdBL6pCd0ph38L7pQjX6fQufWmZG/XRJ03gRnom2TgG/pbGOxsFBUESEplpRjOMnfI4rw1wHH9KFs+3B3UgiRh+oGcu9fMIYsqP7ABEYm/KFMU0ymtuFKu9B5Bcltm3/WN52pIzEpvyyU9jln00V+l19OifCfgc8EJpfHbkIYNN9VLDkB3ozn6Hs74HfaBdA5b92KKX4jglaH
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 12:36:54.9175
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f4b0ada-5b17-4f34-6035-08def2ee3ba6
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM4PEPF00027A6A.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB10201
X-purgate-ID: tlsNG-4011c0/1785933425-50ACCCFC-51586234/0/0
X-purgate-type: clean
X-purgate-size: 1749

Hi Michal,

> On 5 Aug 2026, at 14:11, Michal Orzel <michal.orzel@amd.com> wrote:
>=20
> process_domain_node() parses "xen,static-mem" regardless of
> CONFIG_STATIC_MEMORY. With the feature off, init_staticmem_pages() is a
> no-op stub, so boot carries on until construct_domU() reaches the
> ASSERT_UNREACHABLE() stubs of allocate_static_memory() /
> assign_static_memory_11(): a debug build trips the assertion, a productio=
n
> build gives the domain no memory at all.
>=20
> Bail out at parse time instead, like process_shm_node() already does for
> CONFIG_STATIC_SHM.
>=20
> Fixes: 41c031ff437b ("xen/arm: introduce domain on Static Allocation")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

> ---
> xen/common/device-tree/bootinfo-fdt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>=20
> diff --git a/xen/common/device-tree/bootinfo-fdt.c b/xen/common/device-tr=
ee/bootinfo-fdt.c
> index 272b5a6c0ae6..ca64daf4cdc8 100644
> --- a/xen/common/device-tree/bootinfo-fdt.c
> +++ b/xen/common/device-tree/bootinfo-fdt.c
> @@ -349,6 +349,12 @@ static int __init process_domain_node(const void *fd=
t, int node,
>         /* No "xen,static-mem" present. */
>         return 0;
>=20
> +    if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) )
> +    {
> +        printk("CONFIG_STATIC_MEMORY must be enabled for parsing xen,sta=
tic-mem\n");
> +        return -EINVAL;
> +    }
> +
>     return device_tree_get_meminfo(fdt, node, "xen,static-mem", address_c=
ells,
>                                    size_cells, bootinfo_get_reserved_mem(=
),
>                                    MEMBANK_STATIC_DOMAIN);
> --=20
> 2.43.0
>=20



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:41:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:41:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383368.1626624 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrawC-00036e-Cl; Wed, 05 Aug 2026 12:41:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383368.1626624; Wed, 05 Aug 2026 12:41:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrawC-00036X-94; Wed, 05 Aug 2026 12:41:36 +0000
Received: by outflank-mailman (input) for mailman id 1383368;
 Wed, 05 Aug 2026 12:41:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrawA-00036E-OR
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:41:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wraw9-003tJ0-TB
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:41:33 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a732f66-2eae-0a2a0a5409dd-0a2a4505a08c-36
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:41:33 +0200
Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a732f7d-4cb1-0a2a45050019-d155da2ac5dd-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:41:33 +0200
Received: by mail-ej1-f42.google.com with SMTP id
 a640c23a62f3a-c1c24ec9525so159578466b.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:41:33 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2036461395sm103784666b.62.2026.08.05.05.41.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 05:41:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785933693; x=1786538493; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0QaMmvum05DIEb1UosvTT9n8I5x15tm5IM4WzUyxoRw=;
        b=U9uNaUOkEi2Frt6B8MqqJE0Q6DKo4gh60p20aT/JWgPcj1pKEg6i17RzjmrDIpV+3/
         Vd9R82bvR/3llIub20ItSfz6fN4bOescDRmAlfmw6iljxCmJse3TIqpHVfxZruIe4EtZ
         B8VG6QmUtOFt6J/ItQquSfSaoEfY/FdVZ3jH2x0qGxOhc4K0NJnP4SYat/2W5s3JqE4V
         fdFhPo2ZM9Qx8OrD76nQEnB5SdOfpWB5A7QU7vzvGBP+MHWG+2Dt+4LemhexPSvyZfG9
         xhImJJ2zUjycHlW6Jf3LyyN+hr8vkctj2X8TTFUmGOOcXRGgbvm/PrHWrAKxXjZ+4umC
         Ji5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933693; x=1786538493;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0QaMmvum05DIEb1UosvTT9n8I5x15tm5IM4WzUyxoRw=;
        b=FoIXTIPI7E6BGxsD10KFnGxUuPwKckXp0osKcmz19WSM7s5Q584al5St7uBRoXbe/d
         nqNQkotA07zZ8C0yFu3wfum1xiLdTZ9lo1qCV3vUzfuuUovyUMJ2I/CRVToEpbTItfB0
         Z039UmrIqVaCGxbi4QDYBe/ZC5ZHyHeBLhw0kHqKF8MpIIoqLaDUm981LCToJdOMi4Sg
         sObpiL8iPWXe8/ctN7avrk3Lo996YwSXspwfYJDXK4EPQ43PASW96wO4ZvVSPHgpjzRl
         NXDPSSv7T31nvk2tVMtDct1xurzk7ycd17sWsAbSqAs9ieUXrYTehboiyEnaSwDTjMrM
         kMcw==
X-Gm-Message-State: AOJu0Yz2S1guTNX2kSLGJEvOwAU75nJA5VV8rlIFRylal0NGQusNoLp4
	EE8FIIyDRLXdX9Go9tuvS6aExIzc8DLdi89j6LaM0LdnPo7kpMwZTbpqBZhTFTrInn0=
X-Gm-Gg: AR+sD1076gGms7LPqPbfD+4kAVG2uU50l83GMgT8fvW6DTEMdNBuN4b2f36k5oBShyo
	PLlkcBFMgVRDgCEF/q1XovhrEUuvtUD3/iRcI4/QTuVk66Bep/1wIp456JBlcr+OJpH+tMeTjkB
	JJ0wY4dNSeNp5tZhqUHLcv1IX1K2mItgYW+mvd//lMjXSyf73LrTZ9IAsTAFBnkfYhSCFir3Fwk
	yi1OdTUGFPWuPoyxHunsI/ra7h2KrgCMrRerWmh4oPhCZNhmzs0sQQSg8S0390veKK58rWMZZen
	regDIdMVqt4pt0QWGl8TUggzuIYMEMbMBW4y/Blvn14QZ+6W1oQIy5SWKs8I2sr3OB3La+bABFh
	OptizJoM6iOTkbaKQESIdgdyL5aUzg9bOWiCOK5YTj/BAoVrcL741h2hlI4uEwgjyrqlkZ0U8Ql
	JdinRmH94wTTtyQltKebK1M2DADUXE0oWppHfgNK5IrVBpTMhOkQokH3mDa5n0SHJ87JWt+PsJF
	J2UourL7vv7H9VDM/34zlMNOJh+3wT6hIlyFuUy3bpbex1ltJ/l/dlwi008+o3R/9tQA7PitDB1
	AxVwOMTBkW4jtec=
X-Received: by 2002:a17:907:934b:b0:c20:768:af62 with SMTP id a640c23a62f3a-c2039c6c8a2mr341458166b.22.1785933692951;
        Wed, 05 Aug 2026 05:41:32 -0700 (PDT)
Message-ID: <f0394e8a-1ac3-4aa9-bae2-af52380ff07a@suse.com>
Date: Wed, 5 Aug 2026 14:41:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
 <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
 <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ZRJM6pLxAC9zdk5WjgZzPb3j"
X-purgate-ID: tlsNG-c201ff/1785933693-F68B62A1-8C327E0F/0/0
X-purgate-type: clean
X-purgate-size: 10094

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ZRJM6pLxAC9zdk5WjgZzPb3j
Content-Type: multipart/mixed; boundary="------------uvadjcU5bDKL9u0vra1EE0hE";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <f0394e8a-1ac3-4aa9-bae2-af52380ff07a@suse.com>
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
 <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
 <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
In-Reply-To: <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>

--------------uvadjcU5bDKL9u0vra1EE0hE
Content-Type: multipart/mixed; boundary="------------yjwpHgik2wtI91TARDmFirUE"

--------------yjwpHgik2wtI91TARDmFirUE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTQ6MTUsIEdlb3JnZSBEdW5sYXAgd3JvdGU6DQo+IFtBZGRpbmcgYmFj
ayBpbiB4ZW4tZGV2ZWwsIHNpbmNlIHRoaXMgaXMgcmVsZXZhbnRdDQo+IA0KPiBPbiBXZWQs
IEF1ZyA1LCAyMDI2IGF0IDk6MTXigK9QTSBKw7xyZ2VuIEdyb8OfIDxqZ3Jvc3NAc3VzZS5j
b20gDQo+IDxtYWlsdG86amdyb3NzQHN1c2UuY29tPj4gd3JvdGU6DQo+IA0KPiAgICAgT24g
MDQuMDguMjYgMTE6MzQsIEdlb3JnZSBEdW5sYXAgd3JvdGU6DQo+ICAgICAgPiBPbiBUdWUs
IEF1ZyA0LCAyMDI2IGF0IDY6NDXigK9QTSBKw7xyZ2VuIEdyb8OfIDxqZ3Jvc3NAc3VzZS5j
b20NCj4gICAgIDxtYWlsdG86amdyb3NzQHN1c2UuY29tPg0KPiAgICAgID4gPG1haWx0bzpq
Z3Jvc3NAc3VzZS5jb20gPG1haWx0bzpqZ3Jvc3NAc3VzZS5jb20+Pj4gd3JvdGU6DQo+ICAg
ICAgPg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBQLlMuOiBHZW9yZ2UsIHdvdWxkIGl0
IGJlIHBvc3NpYmxlIHRvIHR1cm4gb2ZmIEhUTUwgbWFpbHMgd2hlbiBzZW5kaW5nIHRvDQo+
ICAgICAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgeGVuLWRldmVsPw0KPiAgICAgID4NCj4gICAg
ICA+DQo+ICAgICAgPiBJIHNlZSBib3RoIGEgdGV4dC9wbGFpbiBwYXJ0IGFuZCBhIHRleHQv
aHRtbCBwYXJ0IGluIHRoZSBtYWlsIEkgc2VudDsNCj4gICAgIGlzbid0IHRoZQ0KPiAgICAg
ID4gcHJlc2VuY2Ugb2YgYSB0ZXh0L3BsYWluIHZlcnNpb24gc3VmZmljaWVudD8NCj4gICAg
ICA+DQo+ICAgICAgPiBPYnZpb3VzbHkgc2VuZGluZyBwYXRjaGVzIGlzIGEgZGlmZmVyZW50
IG1hdHRlcjsgYnV0IGZvciB0aGF0IEknbGwgYmUNCj4gICAgIHVzaW5nIGdpdC0NCj4gICAg
ICA+IHNlbmQtZW1haWwuDQo+IA0KPiAgICAgVGhpcyBpcyBhIHJlcGx5IHRvIHlvdXIgbWFp
bCB1c2luZyBUaHVuZGVyYmlyZCAod2hpY2ggSSBoYXZlIGNvbmZpZ3VyZWQgdG8gdXNlDQo+
ICAgICBwbGFpbiB0ZXh0IGZvcm1hdCBhcyB0aGUgZGVmYXVsdCwgaW4gb3JkZXIgdG8gY29t
cGx5IHdpdGggbW9zdCBtYWlsaW5nIGxpc3RzDQo+ICAgICBJJ20gdXNpbmcpLg0KPiANCj4g
ICAgIEkgZG9uJ3QgdGhpbmsgVGh1bmRlcmJpcmQgaXMgYW4gZXhvdGljIE1VQSwgYnV0IHBs
ZWFzZSBoYXZlIGEgbG9vayBob3cgaXQNCj4gICAgIHJlbmRlcmVkIHlvdXIgSFRNTCByZXBs
eSB0byBteSBvcmlnaW5hbCBtYWlsLiBJIGNhbid0IHNlZSBjbGVhcmx5IHdoaWNoIHBhcnQN
Cj4gICAgIHdhcyB3cml0dGVuIGJ5IG1lIG9yaWdpbmFsbHkgYW5kIHdhcyBjaXRlZCBieSB5
b3UgaW4gdGhpcyBtYWlsLg0KPiANCj4gDQo+IFRoYW5rcywgdGhpcyBpcyB3aGF0IEkgd2Fz
IGxvb2tpbmcgZm9yLg0KPiANCj4gQXR0YWNoZWQgaXMgdGhlIG1lc3NhZ2UgR21haWwgc2Vu
dC7CoCBBcyB5b3UgY2FuIHNlZSwgdGV4dC9wbGFpbiB1c2VzIG5vcm1hbCBgPmAgDQo+IGZv
ciBxdW90ZXMuDQo+IA0KPiBUaGF0IG1ha2VzIG1lIHRoaW5rIHRoYXQgdGhlIHByb2JsZW0g
aXMgaW4gVGh1bmRlcmJpcmQuIEl0IHNob3VsZCBlaXRoZXIgdGFrZSANCj4gdGhlIHRleHQv
cGxhbiBwYXJ0LCBhbmQgcmVwbHkgdG8gdGhhdCBhcyB0aG91Z2ggaXQgd2VyZSB0aGUgb25s
eSBwYXJ0IGl0IGhhZCANCj4gcmVjZWl2ZWQ7IG9yIGl0IHNob3VsZCB0YWtlIHRoZSBIVE1M
IHBhcnQsIGFuZCBjb252ZXJ0IHRoZSBxdW90ZXMgdG8gdGV4dCANCj4gcHJvcGVybHkuwqAg
UmVwbHlpbmcgaW4gSFRNTCBhbmQgdGhlbiByZW5kZXJpbmcgaXQgd2l0aCBvbmx5IHNwYWNl
IGluZGVudGF0aW9ucyANCj4gc2VlbXMgbGlrZSBhIGJ1Zy4NCj4gDQo+IFRodW5kZXJiaXJk
IGNlcnRhaW5seSBpc24ndCBleG90aWMsIGJ1dCBsYXN0IHRpbWUgSSB1c2VkIGl0IGl0IHdh
cyBkZWZpbml0ZWx5IA0KPiB1bmRlci1tYWludGFpbmVkLg0KPiANCj4gWW91J3JlIGFza2lu
ZyBldmVyeSBwZXJzb24gd2hvIHNlbmRzIGFuIGVtYWlsIHRvIHhlbi1kZXZlbCB0byByZW1l
bWJlciB0byB0YWtlIA0KPiBhbiBhY3Rpb24gYmVmb3JlIHNlbmRpbmcgdGhlIG1haWwgKG9y
IHRvIHNlbmQgKmFsbCogbWFpbCBhcyB0ZXh0L3BsYWluLCBldmVuIGlmIA0KPiBpdCdzIG5v
dCB0byB4ZW4tZGV2ZWwpLCBiZWNhdXNlIHlvdXIgTVVBIGlzbid0IGhhbmRsaW5nIHRoZSBz
dGFuZGFyZCBwcm9wZXJseS4gIA0KDQpBbmQgeW91IGFyZSBhc2tpbmcgZXZlcnkgVGh1bmRl
cmJpcmQgdXNlciB0byBsaXZlIHdpdGggYmFkIHRocmVhZGluZyBvciB0bw0KdXNlIGEgZGlm
ZmVyZW50IG1haWwgY2xpZW50Lg0KDQo+IElzIHRoYXQgcmVhbGx5IHJlYXNvbmFibGU/wqAg
Q291bGRuJ3QgeW91IHRlbGwgVGh1bmRlcmJpcmQgdG8gaWdub3JlIGh0bWwgYW5kIA0KPiBv
bmx5IHJlbmRlciB0ZXh0L3BsYWluPw0KDQpJIGRpZCBsb29rIGZvciBhIHNldHRpbmcgY29u
dHJvbGxpbmcgdGhhdCwgYnV0IGNvdWxkbid0IGZpbmQgYW55LiBJJ20gYWxyZWFkeQ0KdXNp
bmcgdG8gc2VuZCBwbGFpbiB0ZXh0IG9ubHkuIFRoZXJlIHNlZW1zIHRvIGJlIG5vIG9idmlv
dXMgY29udHJvbCB0byBwcmVmZXINCnRleHQgb3ZlciBodG1sIGluIGFsdGVybmF0aXZlIGJv
ZGllcy4NCg0KT24gTWF0cml4IHlvdSBzdGF0ZWQgeW91IGFyZSB1c2luZyB0aGUgc2FtZSBj
b25maWd1cmF0aW9uIGZvciBzZW5kaW5nIG1haWxzIHRvDQp4ZW4tZGV2ZWwgc2luY2UgMjAw
Ni4gSSdtIG5vdCBzdXJlIHRoaXMgaXMgdHJ1ZSwgYXMgbW9zdCBtYWlscyBJJ3ZlIHJlY2Vp
dmVkDQpmcm9tIHlvdSB2aWEgeGVuLWRldmVsIGhhdmUgYmVlbiBzZW50IGZyb20geW91ciBD
aXRyaXggYWNjb3VudCwgYW5kIHRob3NlIHdlcmUNCmFsbCB0ZXh0LW9ubHkuDQoNCg0KSnVl
cmdlbg0K
--------------yjwpHgik2wtI91TARDmFirUE
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------yjwpHgik2wtI91TARDmFirUE--

--------------uvadjcU5bDKL9u0vra1EE0hE--

--------------ZRJM6pLxAC9zdk5WjgZzPb3j
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpzL3wFAwAAAAAACgkQsN6d1ii/Ey+N
0Qf+Oz+4knDaDZrFzTXvCPkf6w7xmSFDMubRRs8MfCp4BEZDgsOSHLHydn8dUR9kQg4FJiSicdJ5
RAXUTF2EBmlf0hhODc81xEWuY9rmipE3UUP2CMJi+C5CH4WY/tUl/ScyZ6NNBMSkxEfdp+t7nSsc
ayo1aSgP26D37Newtjn5j4IR53Wd9YqnyjMFfYSsKPkz/iBd3w3DudQUwp9fBYmKih8oSLgcl7yh
8stny+MkQKvQDs43OoMduNUUL2BOYLVAF+YJQQoAYTUpSZ2U9U4lXVlv3At0O+LWy7y5Z+y13zAc
C7swPP5I9E8J4QmIqw6TEDiPMbhJ77qfY7nW0kpMXA==
=OSNP
-----END PGP SIGNATURE-----

--------------ZRJM6pLxAC9zdk5WjgZzPb3j--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:43:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:43:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383377.1626633 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraxW-0003ef-Om; Wed, 05 Aug 2026 12:42:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383377.1626633; Wed, 05 Aug 2026 12:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wraxW-0003eY-LT; Wed, 05 Aug 2026 12:42:58 +0000
Received: by outflank-mailman (input) for mailman id 1383377;
 Wed, 05 Aug 2026 12:42:57 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd1f2bc52000e099@swg.vates.tech>)
 id 1wraxU-0003eP-It
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:42:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wraxT-00CG6T-FM
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:42:55 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd1f2bc52000e099@swg.vates.tech>)
 id 6a732fc6-5cb7-0a2a0a5109dd-0a2a4507c282-10
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:42:55 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd1f2bc52000e099@swg.vates.tech>)
 id 6a732fce-b4ea-0a2a45070019-b9ff1c12ad2d-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:42:54 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fd1f2bc52000e099.002 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 05 Aug 2026 12:42:53 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id 1DC4481FD3;
 Wed,  5 Aug 2026 14:42:53 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=gfMf2inEG6pdNO/k2iXwdhSdR+/CUahmyCFr9YdPWmo=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=sQQuJ+h2yWOqkFcO6QIYQiqoWBUOaH1wXsIcn1xeYOG8/qJXXEsct90dT/VHoxQgRxqmETXqc
 2rapoTuDZjXMAAi+mA7jXhB+ir8ID31e0uQBEYlvKrRcwAt5rsrHu4k/IwULXMw4/BwQR+AYp2+
 Gd7KFARXvb4chnUIcQHEli9SmIhG7N698+LM+aLixWYuvjB+XiM7PUXCjGtr+ePxMFIxSoL+B5D
 Jmn8maLXgixPshRs5izAv4ZhW/N8uKHodODgUPxQOjs1LX1JLVD08SLzS2M3OJ7va0oa22Gockj
 jZ9HmDC4NuKOSjWrCIvOVWrSARttnTXEqH6QeshXdW7A==
X-Zone-Loop: 36e1f8791f1a1bf331bd4481293e85525dec21758348
x-campaign-type: default
x-transaction-id: b89f5a5f-a33e-4a3d-b693-31f403d88185
x-swg-uid: 01-116444aa-9e67-4a48-979c-fff7f6abd1e3
X-Mailer: Sweego
Message-ID:
 <1785933773.8631fc262581453bbf619ec5b2062170.19fd1f2bc52000e099@vates.tech>
x-swg-bid: 1785933773.8631fc262581453bbf619ec5b2062170.19fd1f2bc52000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Wed, 5 Aug 2026 14:42:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] vtd: Move intremap table to xenheap
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org, George Dunlap <gwd@xenproject.org>
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319343.8631fc262581453bbf619ec5b2062170.19fad5345fc000e099@vates.tech>
 <451978a5-7dfd-4b91-a241-eb13caf6d394@suse.com>
 <59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------GTmS6zkj5FCxYf87Yo944WNQ"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1785933773255
X-purgate-ID: tlsNG-ef75cf/1785933775-372DCAE4-531C9AC0/0/0
X-purgate-type: clean
X-purgate-size: 7403

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------GTmS6zkj5FCxYf87Yo944WNQ
Content-Type: multipart/mixed; boundary="------------kRpbAI5tISuh33WXwkRqz3Cm";
 protected-headers="v1"
From: Teddy Astie <teddy.astie@vates.tech>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org, George Dunlap <gwd@xenproject.org>
Message-ID: <e7f67cf6-f6a9-4619-b7d5-639618ff5f56@vates.tech>
Subject: Re: [PATCH 5/5] vtd: Move intremap table to xenheap
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319343.8631fc262581453bbf619ec5b2062170.19fad5345fc000e099@vates.tech>
 <451978a5-7dfd-4b91-a241-eb13caf6d394@suse.com>
 <59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com>
In-Reply-To: <59d0de8f-2d97-4f65-af16-876be20398fa@citrix.com>

--------------kRpbAI5tISuh33WXwkRqz3Cm
Content-Type: multipart/mixed; boundary="------------8GEWshzGg3W6GDgYK8rnW80B"

--------------8GEWshzGg3W6GDgYK8rnW80B
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDUvMDgvMjAyNiDDoCAxMjowOSwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBP
biAwNS8wOC8yMDI2IDEwOjQ0IGFtLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE9uIDI5LjA3
LjIwMjYgMTE6NTksIFRlZGR5IEFzdGllIHdyb3RlOg0KPj4+IEludGVycnVwdCByZW1hcHBp
bmcgZW50cmllcyBvZnRlbiBuZWVkcyB0byBiZSBhY2Nlc3NlZCwgYW5kIHdlJ3JlIGNyZWF0
aW5nDQo+Pj4gcG9pbnRlcnMgdG8gaXQgb24gZGVtYW5kLCB3aGljaCBicmluZ3MgYSBsb3Qg
b2YgY29tcGxleGl0eSAoZS5nDQo+Pj4gR0VUX0lSRU1BUF9FTlRSWSgpIG1hY3JvKSwgbW92
ZSBpdCB0byB4ZW5oZWFwIHN1Y2ggdGhhdCBpdCdzIHBlcnNpc3RlbnRseQ0KPj4+IG1hcHBl
ZCBhbmQgd2Ugd29uJ3QgaGF2ZSB0byB3b3JyeSBhYm91dCBtYXBwaW5nIGFuZCB1bm1hcHBp
bmcgaW5kaXZpZHVhbA0KPj4+IGludHJlbWFwIHRhYmxlIHBhZ2VzLg0KPj4gQWZhaWM6IE5v
IG1vdmVtZW50IGZyb20gZG9taGVhcCB0byB4ZW5oZWFwIGV4Y2VwdCBmb3IgX3ZlcnlfIGdv
b2QgcmVhc29ucy4NCj4+IEZvciB0aGUgY2FzZSBoZXJlIHRoYXQgaXMgLSBtYXliZSBlc3Rh
Ymxpc2ggYSBwZXJtYW5lbnQgbWFwcGluZyB1c2luZw0KPj4gdm1hcCgpLCBidXQgbm8gY2hh
bmdlIGluIHdoZXJlIHRoZSBtZW1vcnkgaXMgdG8gY29tZSBmcm9tLiBXaGV0aGVyIHN1Y2gg
YQ0KPj4gcGVybWFuZW50IG1hcHBpbmcgaXMgcmVhbGx5IHdvcnRod2hpbGUgbWF5IGFsc28g
d2FudCBzdXBwb3J0aW5nIGJ5IG51bWJlcnMuDQo+PiBZb3Ugc2F5ICJvZnRlbiIsIGJ1dCB5
b3UgZG9uJ3QgcXVhbGlmeSAvIHF1YW50aWZ5IHRoaXMgYW55IGZ1cnRoZXIuDQo+IA0KDQpJ
IHRoaW5rIHRoZSByZWR1Y3Rpb24gdGhlIGNvbXBsZXhpdHkgb2YgdGhlIGxvZ2ljIGlzIGEg
Z29vZCByZWFzb24gaW50byANCnVzaW5nIGEgcGVyc2lzdGVudCBtYXBwaW5nIGhlcmUgKGVz
cGVjaWFsbHkgc2luY2UgaXQncyBub3QgYSANCnBhcnRpY3VsYXJseSBsYXJnZSBvbmUpLg0K
DQo+IFRvIGV4cGFuZCBvbiB0aGUgIndoeSIgYSBiaXQgbW9yZS4NCj4gDQo+IEZvciBzeXN0
ZW1zIHdpdGggYWxsIFJBTSBiZWxvdyB0aGUgNFQgYm91bmRhcnksIGRvbWhlYXAgYW5kIHhl
bmhlYXAgYXJlDQo+IGVxdWl2YWxlbnQuwqAgV2UgaGF2ZSA1VCBvZiBkaXJlY3RtYXAsIGJ1
dCB4ZW5oZWFwIGFsbG9jYXRpb25zIGhhdmUgYQ0KPiB3aWR0aCByZXN0cmljdGlvbiB3aGlj
aCBpcyBhIHBvd2VyLW9mLTIuDQo+IA0KPiBGb3Igc3lzdGVtcyB3aXRoIGFueSBSQU0gYWJv
dmUgdGhlIDRUIGJvdW5kYXJ5LCB5b3UgY2FuJ3QgaGF2ZSB4ZW5oZWFwDQo+IGFsbG9jYXRp
b25zIGJlIE5VTUEtbG9jYWwgZm9yIGFsbCBOVU1BIG5vZGVzLg0KPiANCj4gDQo+IEFzIGZv
ciAib2Z0ZW4iLCB0aGUgSVJURXMgYXJlIG1vZGlmaWVkIGV2ZXJ5IHRpbWUgYSB2Q1BVIG1v
dmVzIHRvIGENCj4gZGlmZmVyZW50IFBDUFUsIGJlY2F1c2UgdGhlIHRhcmdldCBhZGRyZXNz
ZXMgbmVlZCB1cGRhdGluZy7CoCBXaGlsZSBpdA0KPiBwcm9iYWJseSBkb2Vzbid0IG1hdHRl
ciBtdWNoIHRvZGF5LCBpbiB0aGUgY29udGV4dCBvZiBBU0kgaXQncyBzb21ldGhpbmcNCj4g
d2hpY2ggd291bGQgd2FudCBtYXBwaW5nIHBlcm1hbmVudGx5LCByYXRoZXIgdGhhbiBvbi1k
ZW1hbmQuDQo+IA0KDQpPaywgc28gZG9taGVhcCB3aXRoIHZtYXAgd291bGQgYmUgcHJlZmVy
YWJsZSBoZXJlLg0KDQo+IH5BbmRyZXc+DQoNClRlZGR5DQo=
--------------8GEWshzGg3W6GDgYK8rnW80B
Content-Type: application/pgp-keys; name="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Disposition: attachment; filename="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7L
TBVHV/XOZw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJ
T4ny+OGntnJntUoRKRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJA
WicutjkkUgd28Bh6HV9EIumHtCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO
8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaTVqMdqul07o72m3eA2mf+LMu9a04FX/d4
wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/EoucejoZ5SH49ksmVAmKOLkt
OaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+SPhHar7TPKjFz0G3D
PNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89MXfQXZ3q
t1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWj
moACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNz
uyOVCskwfUZPla6Zpd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp
0x0HfuhcYfAYPR46XHTvjaJEv99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuR
OxdK8G+YHccJY8PvWSq2K2yiae2KGiAv1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50
wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhPeP3IdpfWc8cyRLXF06Rk46YM
YCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcTUwgnYlFRk2FLq0Qe
KEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9Egr/Wmu3
MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEM
AKiQiZa3yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ
3DbVf+en3/FvdVZg2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTm
etSG5/52AjtmPFtlXAk0NmLvfJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0
s3109sJeXT5ImVdphFs9cvyZyBT9t1PbRowv58EgV0zE4hbAeVkULAbxFV5b/ExT
jjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKbYu6NCfiHfEyB3Xyg9hfdrRgj
MRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ovXoK4jm+Py0FiUGUa
A6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/eVtR2Q1w
ZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWj
moACGwwACgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiV
oUiHYN5QwhnbZnsaJDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764Qxy
X6rld2f2RcWkDuBHun55ZWXjby8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk
/dS0XTOQi2wVUb17sW/+ybCEokdVacZGzOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fu
oGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+lOWSvdNHgoEkWR0RXBPQjnGm
LKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/OffO485NOTKwGOxyWb0
06cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR8ULR9nX0
LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
x9fhaZEsniw8/bYgC3igkk5YJiOa
=3DlUIA
-----END PGP PUBLIC KEY BLOCK-----

--------------8GEWshzGg3W6GDgYK8rnW80B--

--------------kRpbAI5tISuh33WXwkRqz3Cm--

--------------GTmS6zkj5FCxYf87Yo944WNQ
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmpzL8wFAwAAAAAACgkQZg+p0QLLz9DA
6gv7BltTaonVluo9LKHT9I/blqHpaofr38z4HkJzHm8CWcqWysnFLsdtJdZqedLwF3TcAkx8NCKm
wasH4fZX1xMRiMULsFnrgntiUMJZz2v8IEfK44XKxo1Eb6s5bzUSRINraQ7LXo0wK2ukHbkd4JT6
zWHMmhg5kz9AdIPF2Rtoiq6X1qUrZjPvDKg4EILopPjbzzQC7Kvvi5Hgk8SYQYFylJ/8ybf3BFI7
IJ5D6Z0PzGsOPWtRbcMgnD6f4uoe5K5WJ8P/g+qPCXhkuULkhosqkqK2gmsdBWgPuGZ++AiR9fnQ
ucUtYz3yMb86gFzrsreRhmJDqrXYCYBc1uQEBf54SQ8tJF1Nf8Xu0fHAGiCFZ+M0c3bR/hODQ38i
LUVUPeb71H7p3EdmZl/z4CqJGZAJNmIoIeUQEwpsasCrpthkIz1YxtTFffsFjYDc1Pmm48J+7ypc
SEaRaMo+pQSt2E2pS3kdh0gWSZZ4QIL2Vo9ZA3y6WWuP/UiL+Q1fT/n2vZca
=U8KH
-----END PGP SIGNATURE-----

--------------GTmS6zkj5FCxYf87Yo944WNQ--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:45:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:45:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383390.1626666 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrazy-0004Sj-GN; Wed, 05 Aug 2026 12:45:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383390.1626666; Wed, 05 Aug 2026 12:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrazy-0004Sc-CX; Wed, 05 Aug 2026 12:45:30 +0000
Received: by outflank-mailman (input) for mailman id 1383390;
 Wed, 05 Aug 2026 12:45:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrazx-0004Pq-Pr
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:45:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrazx-004adb-5y
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:45:29 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a733061-2eae-0a2a0a5409dd-0a2a450382f4-24
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:29 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a733069-fae8-0a2a45030019-d155dd31b952-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:29 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47f84023916so817188f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:45:29 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8779762f8f.28.2026.08.05.05.45.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 05:45:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785933928; x=1786538728; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=/9e6A8lC1tkLbZ56fkZqK4C1TbgXO56ls4av+lt8mI4=;
        b=oti0kg3AVl1LHrgzwn6xfD6lu0S2jgpc69Bd+ZBIvOSVfroggz8dqYvfnst7nuXXFo
         UMyhpBsLHmC4Vnipzvzb8T415oy8mBIUncblimuA1WVwvSPijU3H5u1DYcro28w8vVPk
         7iJp6Z5EcMHiAw83+TTSBqyJp8xn9OHGzpnLk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933928; x=1786538728;
        h=content-transfer-encoding:content-type: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=/9e6A8lC1tkLbZ56fkZqK4C1TbgXO56ls4av+lt8mI4=;
        b=hnnWWWadiWjrYGBTxZqXvcW3I+CDTKH9OHKagtZab/AQtLUBXrP/NhMWEoqt65gQRo
         fgWnmRo+H6/z+h5weXw5x6RPTIXuLaHoket1cN0mtGvNtBdJ6TFEHslkCL2O7Y2ayeWD
         qjQEyXfZDHxwhknubm8s3DsGd+8sGhTM2f5+/NbzbEGo2oYHS0T9pNEcX3rNgCcZGRjH
         +q6K1eR0iIwfPWzBs37LhRdzuKNCms7sGw5NVwfRFQUWM6i/5FT0RHB/vJH7ynzqRcU2
         lRblTKWjK6g8ZkkZYnQSfG5OhtrRHDxYlxBL+l6rQFuVNBviJQinPnVS/oGOpvlJ/E66
         uR1A==
X-Gm-Message-State: AOJu0YzlZYhHPvL0585h8fHwFI7dOiTGkKqyKfCVMci8yscSIWY5L7fg
	iK2yVoIgHrnEQ+gPE3CidDPpJk6AfqTT2s8FqK/0uF4H70weyIdkCDGr3u0KK++Ooxj94dRv1Bz
	L7fMFLac=
X-Gm-Gg: AR+sD10ewMCSIIVXo+EOLHika776xFvy9H0uFxwihmPCValhlx0EZBWVN+axV9vsmyZ
	FD94mZff9sAxUW2oJEpYgHTp0qCFQFHfC14XoJh1ucchBeSj/L1ZR/O/O8sYDrSZYxX33yElczs
	HweDrmDSwGWLqcf+YOLhO0ErBy9yoTbAhep+t5V4XCH3KC+zSxw0hA5b7FEn9IK4lZWQs0HPhvW
	OUSmGICOGAOZcO9oYX3dR46PLty9zjD8RtSwG9VDZlSNyd1tIXuNDw7nC/Og0Ul2zoDsgoeE828
	VygqClMa/tBfbZEg9OJfn0+BHh3MuJo94HfnZpaoPIMltd88AHNHt35Sl9bGz6bDuGfOLL0eeV+
	z8M5agQbXY5CdfRdsJKgl4xDFrJ7aNXvykrM+o0Y45H9El9d0rjEQzE1bD+e9d7MnLUWCagmi8O
	mCJVt7gKyOWtn0FxTYTbxBt/5pLpAWgVfubN+e4F8TDGkW+7u2DkXeFlgXyUGJZwBBFkwXzYQp
X-Received: by 2002:a5d:5f09:0:b0:47f:7aee:ed3c with SMTP id ffacd0b85a97d-47fec4e2a1cmr12936314f8f.5.1785933928318;
        Wed, 05 Aug 2026 05:45:28 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 1/5] x86/nmi: Drop {reserve,release}_lapic_nmi()
Date: Wed,  5 Aug 2026 13:45:21 +0100
Message-Id: <20260805124525.105457-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260805124525.105457-1-andrew.cooper3@citrix.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785933929-768FA4E9-06458010/0/0
X-purgate-type: clean
X-purgate-size: 3296

With Oprofile support dropped, there are no more users of these.  Drop them.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/include/asm/apic.h |  2 --
 xen/arch/x86/nmi.c              | 50 ---------------------------------
 2 files changed, 52 deletions(-)

diff --git a/xen/arch/x86/include/asm/apic.h b/xen/arch/x86/include/asm/apic.h
index 918f1cee3567..f30d57ad22c5 100644
--- a/xen/arch/x86/include/asm/apic.h
+++ b/xen/arch/x86/include/asm/apic.h
@@ -174,8 +174,6 @@ extern void setup_boot_APIC_clock (void);
 extern void setup_secondary_APIC_clock (void);
 extern void setup_apic_nmi_watchdog (void);
 extern void disable_lapic_nmi_watchdog(void);
-extern int reserve_lapic_nmi(void);
-extern void release_lapic_nmi(void);
 extern void self_nmi(void);
 extern void disable_timer_nmi_watchdog(void);
 extern void enable_timer_nmi_watchdog(void);
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 91f95fe6d080..616bfdbc9029 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -89,20 +89,6 @@ static int __init cf_check parse_watchdog_timeout(const char *s)
 }
 custom_param("watchdog_timeout", parse_watchdog_timeout);
 
-/*
- * lapic_nmi_owner tracks the ownership of the lapic NMI hardware:
- * - it may be reserved by some other driver, or not
- * - when not reserved by some other driver, it may be used for
- *   the NMI watchdog, or not
- *
- * This is maintained separately from nmi_active because the NMI
- * watchdog may also be driven from the I/O APIC timer.
- */
-static DEFINE_SPINLOCK(lapic_nmi_owner_lock);
-static unsigned int lapic_nmi_owner;
-#define LAPIC_NMI_WATCHDOG	(1<<0)
-#define LAPIC_NMI_RESERVED	(1<<1)
-
 /* nmi_active:
  * +1: the lapic NMI watchdog is active, but can be disabled
  *  0: the lapic NMI watchdog has not been set up, and cannot
@@ -239,41 +225,6 @@ void disable_lapic_nmi_watchdog(void)
     nmi_watchdog = NMI_NONE;
 }
 
-static void enable_lapic_nmi_watchdog(void)
-{
-    if (nmi_active < 0) {
-        nmi_watchdog = NMI_LOCAL_APIC;
-        setup_apic_nmi_watchdog();
-    }
-}
-
-int reserve_lapic_nmi(void)
-{
-    unsigned int old_owner;
-
-    spin_lock(&lapic_nmi_owner_lock);
-    old_owner = lapic_nmi_owner;
-    lapic_nmi_owner |= LAPIC_NMI_RESERVED;
-    spin_unlock(&lapic_nmi_owner_lock);
-    if (old_owner & LAPIC_NMI_RESERVED)
-        return -EBUSY;
-    if (old_owner & LAPIC_NMI_WATCHDOG)
-        disable_lapic_nmi_watchdog();
-    return 0;
-}
-
-void release_lapic_nmi(void)
-{
-    unsigned int new_owner;
-
-    spin_lock(&lapic_nmi_owner_lock);
-    new_owner = lapic_nmi_owner & ~LAPIC_NMI_RESERVED;
-    lapic_nmi_owner = new_owner;
-    spin_unlock(&lapic_nmi_owner_lock);
-    if (new_owner & LAPIC_NMI_WATCHDOG)
-        enable_lapic_nmi_watchdog();
-}
-
 /*
  * Activate the NMI watchdog via the local APIC.
  * Original code written by Keith Owens.
@@ -417,7 +368,6 @@ void setup_apic_nmi_watchdog(void)
         return;
     }
 
-    lapic_nmi_owner = LAPIC_NMI_WATCHDOG;
     nmi_active = 1;
 }
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:45:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:45:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383389.1626660 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrazy-0004Q5-8K; Wed, 05 Aug 2026 12:45:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383389.1626660; Wed, 05 Aug 2026 12:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrazy-0004Py-5j; Wed, 05 Aug 2026 12:45:30 +0000
Received: by outflank-mailman (input) for mailman id 1383389;
 Wed, 05 Aug 2026 12:45:29 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrazx-0004Pk-CU
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:45:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrazw-007AOn-PI
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:45:28 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73305a-bab6-0a2a0a5309dd-0a2a4508d3fa-22
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:28 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a733068-f659-0a2a45080019-d155dd2aa57d-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:28 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47de008b020so573330f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:45:28 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8779762f8f.28.2026.08.05.05.45.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 05:45:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785933928; x=1786538728; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qkOlx3mU5UhqIngqtbxU1MfSfxL2gIQyRof2hmDeYxw=;
        b=CWwbAXb961dFVc+q8Cjfpnmzg4H9KXGWmGd5IT3UL95w8OLN719HVBc+sdTC8Bwe4t
         nlIV3dbdCGsAQAvo8kD8JyeP3asFsGlj49/rS6vJnjIIbwpFPZmzIy6zXyTKthvxeh0/
         j70YCHF1cdvQCfLDubDckbf8QIKbcTdknGPdw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933928; x=1786538728;
        h=content-transfer-encoding:content-type:mime-version: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=qkOlx3mU5UhqIngqtbxU1MfSfxL2gIQyRof2hmDeYxw=;
        b=Sto+ZeFd9++sE6uASMPMMffTLiRhBkyz92gPQn0tCnT10+zM9xbJvq6C1QL0ZQXOhE
         cOdncjSHZ8afCm1JhbIsA208fawb/bHbe96HT39V4rjGotOZNrqXx4zMIKoN8pJ9c95Y
         fxjBZIsUa5sf+Wg/MBiJdtB9FjWp9DIhVkxyE8qN3b0Z0JDKVTF24iN41nqKuIZQqV7l
         6NTzYpZUhS8pVN3I+RLoqfIz+VMcIoEgaEGPjl6XfG7XgvSCNJCzbU4neo3bGV8mUKSH
         y0OocBXQyNJLqrY+c0pADmSE3GmGnbm1tB9uleEyxGuOzRB9Hvatq6KPqg1w5HQ/gTfD
         TlnQ==
X-Gm-Message-State: AOJu0YwGBDI7GihvxrAga2v3h311bFUuc064NeDV+kdj/MquXmUoTDT5
	OhjWMx8zeS4P0kxUROvKTHH4El9gOjxPC5XuWTzvG1YVtIGLhij2ekGYhfXov9NgT+M826xNLx7
	glyQo
X-Gm-Gg: AR+sD13JaJvVugZiGAwpQa3zZch85z5FHOidHzXnJ9u4vzWMp4guc8giOtYNx5g7gVt
	gU5OfT/6g2/zFKiHz0YRP6YhDKJtWqkCTaPC8EUetQ9MJ84pNGCECxiO+1L7nHb4b1hCZeuEIxp
	rMB+0J9KV5JcIIHPB5abV51L9j4XrAIjrG+Ms+bdEFX4MybwfKBOhL7u0pgUebNaksjyubLfcfK
	cd/OKJ4h43Q1MPNxEPuil5vDQCAl6VLYTcG7bJLODV1OtbBiZ/zJ3+nJ+AIsGqrOPlIxiV/Bl1W
	pepiJiS2sqvjCBwSGJEFnclmQzOH4B0wC3Z5dYtYLD2H7OhxbxFmWDkZE3vSaD2IkSsp3gx9MYf
	a1JgA8yJNOiSGPWzqY26EMsRigfOXkvyUclRqE7QurETcFD7cX4qVVI1MxiI0i5wii0x2Pr1Jpb
	eicExxrHno8zVVeOSalKR+aBsC6W3D0vmQYZY8ooKq6FT1MmxwFQC+rsEkTvti7gvkz0YBn7UEj
	nCIUaPAw0U=
X-Received: by 2002:a05:6000:2989:10b0:47f:7ea0:6c20 with SMTP id ffacd0b85a97d-47fec629365mr9292314f8f.15.1785933927607;
        Wed, 05 Aug 2026 05:45:27 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 0/5] x86/nmi: Watchdog fixes/improvement Part 1
Date: Wed,  5 Aug 2026 13:45:20 +0100
Message-Id: <20260805124525.105457-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785933928-D6B4187B-A509A04A/0/0
X-purgate-type: clean
X-purgate-size: 692

This is the start of a very long rabbit hole to address the
mis-classification of some watchdog NMIs as non-watchdog NMIs.  For
now, just some simple and hopefully non-controvertial changes.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2733861049

Andrew Cooper (5):
  x86/nmi: Drop {reserve,release}_lapic_nmi()
  x86/nmi: Drop K7_NMI_EVENT
  x86/nmi: Misc style fixes
  x86/nmi: Check MSR_MISC_ENABLE for all Intel platforms
  x86/nmi: Don't configure EvtSel repeatedly

 xen/arch/x86/include/asm/apic.h |   2 -
 xen/arch/x86/nmi.c              | 153 ++++++++++----------------------
 2 files changed, 47 insertions(+), 108 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:45:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:45:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383391.1626679 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb00-0004qg-LR; Wed, 05 Aug 2026 12:45:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383391.1626679; Wed, 05 Aug 2026 12:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb00-0004qZ-Ig; Wed, 05 Aug 2026 12:45:32 +0000
Received: by outflank-mailman (input) for mailman id 1383391;
 Wed, 05 Aug 2026 12:45:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrazz-0004gP-5w
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:45:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrazy-007AOn-In
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:45:30 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73305a-bab6-0a2a0a5309dd-0a2a4508d3fa-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:30 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73306a-f659-0a2a45080019-d155dd32a5e5-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:30 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47de008b020so573348f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:45:30 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8779762f8f.28.2026.08.05.05.45.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 05:45:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785933930; x=1786538730; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=v6YeRlTNauFBLjWJsxycUzL7eVgOm6WLxLhWDN+HbJU=;
        b=udEnqSmqzEKqr30c4WmlY74xN4zW4hVH132pJbsRK5cQxSgnZQ3id160fqebHx0u47
         Q3aUIK2M/9K7BIAq0WaqexGzvJIndbZmgT4r950aqI6LPVXsjnQpBYv6gfmbR/WUuBoi
         U9wDyGy8aZwl0H5cHFYCFWkjHEGXGeGkRBAXw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933930; x=1786538730;
        h=content-transfer-encoding:content-type: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=v6YeRlTNauFBLjWJsxycUzL7eVgOm6WLxLhWDN+HbJU=;
        b=Y4LDSHYLhIxfj/E9MIV1aWqmKaMbL08f21Ay/TrYhC/cMVfYkxc0xMRqQn+k3t6vt2
         5ounHtrVloUKoVIipdkpXwD52hbNYGu8XlKfjtaBZ4/rWNMAKpgwFmf6i8/6rQyXATxU
         fTuAD6BaI2SWLW5Ea6dXOhkIGqq2IqKDjImBPel3xzGvZJy8kFJd/IJ8od03rrdH3Tbq
         5KXU5yRXnmo/xnww080+2OO2SCkKWy6fQWKIL/Ra4We52UcW/y55eaVIiSqO81NQmd5V
         LCWxnXxA6Zp7qaJQjMUdVU8QqNQkF6+OBTrwIDxMS/Lo8EcxynZyjqR//j9I+4J5pY62
         3v9Q==
X-Gm-Message-State: AOJu0YwU+WyBslh4iuS2yFY1uyk+EO4ujKVGFvEfuFMBFYHbbisAsdtt
	eeE4ytLnx/1C4RwODLahD1Pl4E9WADQrXYzYVR1eTkNX/c2tZxFiPuaz9dG2O/631HPAZMUzXia
	rg4NZ
X-Gm-Gg: AR+sD10nAmiW4lY6lAbh5+HMlc3NmmardfZISMYoMAwSTx5K4XCw2QwGtkbdu07x5pO
	BvLawlNIt8sLBWc4iGsv2ErOhQ4bmScIp33gwS1pQtjbpaH8vFRgnlwS6VPJZ4k8HoxsPSA5j43
	+8tGEyXDWlaIjnRRr8VP68a6PmJZOpGrAgW+BcgupnjehLH0tXdZx3aHxjyHiC5XdN/BdeIw4XY
	SAcCYYcZ9eXybsXhu6Dq4iHy8Jo9cLYWS90GR1GG+HiDyX6gLCj27/4bpgRztNEoPBBq5mtt1By
	03NJ0B5nB0IKe/amiLZZDUmQ/IHxS3QuEhxtqUQ7Cletsqy7uLbc6/aLjlj9Jqpo1rPHekGT4CE
	QMd//Y5fJORqemRv2j6RKRwbj6eN3kScjOJqRKnYAsLV7v+vM5+fhHzJPRm+aHu1YfmmOqSQD9T
	5vnU/trDav2pySsEBU76UfjCXvOAPgzRgf35rHEbx8DYLAMxp6IMsNUA211R7bLGIZ9DOedTeZ
X-Received: by 2002:a05:6000:250b:b0:47f:7fe0:a287 with SMTP id ffacd0b85a97d-47fec4e739dmr11551387f8f.2.1785933929270;
        Wed, 05 Aug 2026 05:45:29 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 2/5] x86/nmi: Drop K7_NMI_EVENT
Date: Wed,  5 Aug 2026 13:45:22 +0100
Message-Id: <20260805124525.105457-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260805124525.105457-1-andrew.cooper3@citrix.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785933930-CC77387B-DFBF17D8/0/0
X-purgate-type: clean
X-purgate-size: 1393

This name is misleading.

It's not possible to configure NMI or not from the event select register; that
comes from the APIC configuration for performance events.

This name is "the thing we want to count for the NMI watchdog", but that's
clearer to follow when it simply names the event.  Drop the indirection.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/nmi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 616bfdbc9029..113e672c4f15 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -102,7 +102,6 @@ static int nmi_active;
 #define K7_EVNTSEL_OS		(1 << 17)
 #define K7_EVNTSEL_USR		(1 << 16)
 #define K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING	0x76
-#define K7_NMI_EVENT		K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING
 #define K7_EVENT_WIDTH          32
 
 #define P6_EVNTSEL0_ENABLE	(1 << 22)
@@ -259,7 +258,7 @@ static void setup_k7_watchdog(void)
     evntsel = K7_EVNTSEL_INT
         | K7_EVNTSEL_OS
         | K7_EVNTSEL_USR
-        | K7_NMI_EVENT;
+        | K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING;
 
     wrmsrns(MSR_K7_EVNTSEL0, evntsel);
     write_watchdog_counter("K7_PERFCTR0");
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:45:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:45:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383392.1626684 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb01-0004tX-0G; Wed, 05 Aug 2026 12:45:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383392.1626684; Wed, 05 Aug 2026 12:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb00-0004si-Pi; Wed, 05 Aug 2026 12:45:32 +0000
Received: by outflank-mailman (input) for mailman id 1383392;
 Wed, 05 Aug 2026 12:45:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrazz-0004pu-Sy
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:45:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrazz-004adb-9X
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:45:31 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73306b-2eae-0a2a0a5409dd-0a2a4509ba4e-0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:31 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73306b-be1a-0a2a45090019-d155dd34c8a3-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:31 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47f9ab7ee38so496183f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:45:31 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8779762f8f.28.2026.08.05.05.45.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 05:45:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785933931; x=1786538731; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=lqsAtBET9oa8FmQopb1o6zNaXAFCZR7+pOGZSxtba0c=;
        b=IB3WkI6/nrEAOvOTS9+gWcGasd54tbrhgFLOVPT+klom1JpCm40QHP50iKno6uSAn3
         9ms495ykJviGATEtbSp9l0gPF//jmm5h9Deby5Q6L0GFNIkt9c6h4zLMBbP1N7DZrRLq
         d9pTgzdE9AMaAdvXcyOoeQx/NcGv8u1NLaAb0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933931; x=1786538731;
        h=content-transfer-encoding:content-type: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=lqsAtBET9oa8FmQopb1o6zNaXAFCZR7+pOGZSxtba0c=;
        b=p6MfRnZKcc2x0J3i1FK3TpfDOUeDqyjYTtCZft6WaFzRnh8KlRMbdQudJOvGZtCTed
         XABXAA3wTMR1X7plcrK0QL84+Ed0Qz9GEPoqRqPFnNfkoLuaCtCsYW+Oy9GvbbX+40SU
         O89QWmh8Qc3qOZg6bsP32OoP0PQjLYGLe3Ct0vX3u/Bk0JcS58GwVeebJjDnmgl+VqZp
         sq09+CARwCaqLyHTcDW7G8J3kaUWiCwgslNBPK4ahwd24c/CG17zep+10h2Tfg4+QkYR
         VVRrUStZT35PTaHP6CBI/31Ph9AlurChiITPnbijdoZVcP1I1i4/i0ZpEvDzt16k3Cn8
         ZAog==
X-Gm-Message-State: AOJu0YzCjspTZ5tgmIMd/qSpHh16ucGJ8DgJ1OWB7frFBkFvtwHOkGC/
	rMVCQvEFffjwghKDFFfILsnDZy0TzIL8Y0aeMXCyKbw9W8PaGRQWQRppnny7w7yfIhy3KAcSnLe
	jaRXLIpw=
X-Gm-Gg: AR+sD1016s42HIWxZ/Eo7AQb/amPaBK+I8ewFLn4ZkM11Qnr3ma1U+kvyfJvlyR8Bh0
	x8OJtPIw9sYQOvpPDy2A0dcu42e/VtWcdEFLy7xRsnTDjX6E9B8PkMbRRn+09N0NdLqgnMWJ4BG
	dci7MNCdsMQmRzctj7B+Kuu+pipsPkbTGgXiz9Bfy6M6t9OYqVTVbWdFKLYjr9vCSv2XgzDYV25
	MAaGrzmdnpMfLod6xdUe8aXxKdvG66rjFQwwDXrYVc9yeNGl/J8zsqDPpWxvoKVE73T888ZbvYQ
	Dlxe29f96ftaOM8CHjXCCiiPzPY9S72wkL7fRFVtRCtnNalxB3iOgVHiloot8L2feq7I+NDPOpc
	lmHDGD+73tjWO9NviZMEh6YOy5nHkcBNU/K8i5LMyjuqPYpHiJrBr84ahT3BHl3eNt4XoVNrN28
	Gu37Cc4RqDkFtdAEZaU88DJD9gO7pYhdmW30UtTZQL9BlGoSVLCzrE4izQbMtRy1FnJteW2JkJ
X-Received: by 2002:a05:6000:2489:b0:47f:6f9e:1e86 with SMTP id ffacd0b85a97d-47fec63481dmr10039143f8f.27.1785933930160;
        Wed, 05 Aug 2026 05:45:30 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 3/5] x86/nmi: Misc style fixes
Date: Wed,  5 Aug 2026 13:45:23 +0100
Message-Id: <20260805124525.105457-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260805124525.105457-1-andrew.cooper3@citrix.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785933931-BE4DB034-C4BD65E7/0/0
X-purgate-type: clean
X-purgate-size: 5407

 * Drop trailing whitespace
 * Sort includes, dropping asm/mc146818rtc.h and asm/div64.h as unused
 * Brace position, and types

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/nmi.c | 54 ++++++++++++++++++++++++----------------------
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 113e672c4f15..d9d07870a333 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -13,26 +13,25 @@
  *  Mikael Pettersson : PM converted to driver model. Disable/enable API.
  */
 
+#include <xen/console.h>
+#include <xen/cpu.h>
+#include <xen/delay.h>
 #include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/keyhandler.h>
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/param.h>
-#include <xen/irq.h>
-#include <xen/delay.h>
-#include <xen/time.h>
 #include <xen/sched.h>
-#include <xen/console.h>
 #include <xen/smp.h>
-#include <xen/keyhandler.h>
+#include <xen/time.h>
 #include <xen/watchdog.h>
-#include <xen/cpu.h>
+
+#include <asm/apic.h>
 #include <asm/current.h>
-#include <asm/mc146818rtc.h>
-#include <asm/msr.h>
 #include <asm/mpspec.h>
+#include <asm/msr.h>
 #include <asm/nmi.h>
-#include <asm/div64.h>
-#include <asm/apic.h>
 
 unsigned int nmi_watchdog = NMI_NONE;
 static unsigned int nmi_hz = HZ;
@@ -124,10 +123,10 @@ static int nmi_active;
 #define P4_CCCR_REQUIRED	(3<<16)
 #define P4_CCCR_ESCR_SELECT(N)	((N)<<13)
 #define P4_CCCR_ENABLE		(1<<12)
-/* 
+/*
  * Set up IQ_PERFCTR0 to behave like a clock, by having IQ_CCCR0 filter
  * CRU_ESCR0 (with any non-null event selector) through a complemented
- * max threshold. [IA32-Vol3, Section 14.9.9] 
+ * max threshold. [IA32-Vol3, Section 14.9.9]
  */
 #define P4_NMI_CRU_ESCR0	P4_ESCR_EVENT_SELECT(0x3F)
 #define P4_NMI_IQ_CCCR0	\
@@ -182,7 +181,7 @@ void __init check_nmi_watchdog(void)
      * There's a limit to how slow we can go because writing the perfctr
      * MSRs only sets the low 32 bits, with the top 8 bits sign-extended
      * from those, so it's not possible to set up a delay larger than
-     * 2^31 cycles and smaller than (2^40 - 2^31) cycles. 
+     * 2^31 cycles and smaller than (2^40 - 2^31) cycles.
      * (Intel SDM, section 18.22.2)
      */
     if ( nmi_watchdog == NMI_LOCAL_APIC )
@@ -199,8 +198,9 @@ static void cf_check nmi_timer_fn(void *unused)
 
 void disable_lapic_nmi_watchdog(void)
 {
-    if (nmi_active <= 0)
+    if ( nmi_active <= 0 )
         return;
+
     switch ( boot_cpu_data.vendor )
     {
     case X86_VENDOR_AMD:
@@ -231,9 +231,7 @@ void disable_lapic_nmi_watchdog(void)
 
 static void clear_msr_range(unsigned int base, unsigned int n)
 {
-    unsigned int i;
-
-    for (i = 0; i < n; i++)
+    for ( unsigned int i = 0; i < n; i++ )
         wrmsrns(base + i, 0);
 }
 
@@ -302,7 +300,7 @@ static void setup_p4_watchdog(void)
     uint64_t misc_enable;
 
     rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
-    if (!(misc_enable & MSR_IA32_MISC_ENABLE_PERF_AVAIL))
+    if ( !(misc_enable & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
         return;
 
     nmi_perfctr_msr = MSR_P4_IQ_PERFCTR0;
@@ -310,15 +308,18 @@ static void setup_p4_watchdog(void)
     if ( boot_cpu_data.x86_num_siblings == 2 )
         nmi_p4_cccr_val |= P4_CCCR_OVF_PMI1;
 
-    if (!(misc_enable & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL))
+    if ( !(misc_enable & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL) )
         clear_msr_range(0x3F1, 2);
     /* MSR 0x3F0 seems to have a default value of 0xFC00, but current
        docs doesn't fully define it, so leave it alone for now. */
-    if (boot_cpu_data.model >= 0x3) {
+    if ( boot_cpu_data.model >= 0x3 )
+    {
         /* MSR_P4_IQ_ESCR0/1 (0x3ba/0x3bb) removed */
         clear_msr_range(0x3A0, 26);
         clear_msr_range(0x3BC, 3);
-    } else {
+    }
+    else
+    {
         clear_msr_range(0x3A0, 31);
     }
     clear_msr_range(0x3C0, 6);
@@ -393,7 +394,7 @@ static int cf_check cpu_nmi_callback(
 }
 
 static struct notifier_block cpu_nmi_nfb = {
-    .notifier_call = cpu_nmi_callback
+    .notifier_call = cpu_nmi_callback,
 };
 
 static DEFINE_PER_CPU(unsigned int, last_irq_sums);
@@ -444,15 +445,15 @@ bool nmi_watchdog_tick(const struct cpu_user_regs *regs)
          * before doing the oops ...
          */
         this_cpu(alert_counter)++;
-        if ( this_cpu(alert_counter) == opt_watchdog_timeout*nmi_hz )
+        if ( this_cpu(alert_counter) == opt_watchdog_timeout * nmi_hz )
         {
             console_force_unlock();
             printk("Watchdog timer detects that CPU%d is stuck!\n",
                    smp_processor_id());
             fatal_trap(regs, 1);
         }
-    } 
-    else 
+    }
+    else
     {
         this_cpu(last_irq_sums) = sum;
         this_cpu(alert_counter) = 0;
@@ -512,7 +513,8 @@ bool nmi_watchdog_tick(const struct cpu_user_regs *regs)
 void self_nmi(void)
 {
     unsigned long flags;
-    u32 id = get_apic_id();
+    uint32_t id = get_apic_id();
+
     local_irq_save(flags);
     apic_wait_icr_idle();
     apic_icr_write(APIC_DM_NMI | APIC_DEST_PHYSICAL, id);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:45:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:45:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383393.1626696 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb03-0005KG-BQ; Wed, 05 Aug 2026 12:45:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383393.1626696; Wed, 05 Aug 2026 12:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb03-0005K9-8h; Wed, 05 Aug 2026 12:45:35 +0000
Received: by outflank-mailman (input) for mailman id 1383393;
 Wed, 05 Aug 2026 12:45:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrb01-0004qQ-A6
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:45:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrb00-009h29-1B
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:45:32 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a733064-e002-0a2a0a5209dd-0a2a45029942-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:31 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73306b-6ca4-0a2a45020019-d155dd2cbcf9-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:31 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f96c5b722so540548f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:45:31 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8779762f8f.28.2026.08.05.05.45.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 05:45:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785933931; x=1786538731; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=gfNjW9ZQ4iFlwv+IcWbWGLC4if7o3p4HypcYr/O3FIo=;
        b=j4nb/rXoyPeZIvZcycFCLsHvSo8ggmdJdpITXFhun2a5v9dRXpGQL2A2NxMpt/Qn9W
         N9DLKzOUBQGYqdEE0d/RBGvr+IdX5cRyX4JwviLRX//uP6X2mAImuJL4uEdM9DacYhmx
         XGI/pVoUGgaquKL0xrLMyEb+v9fwwHbBDiNVg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933931; x=1786538731;
        h=content-transfer-encoding:content-type: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=gfNjW9ZQ4iFlwv+IcWbWGLC4if7o3p4HypcYr/O3FIo=;
        b=KAoo6+Itq4TOJ3gJ1u/KPPUvk3VoVb0WIEwo26IBBbdVMjxYynCETrq355IcRPAv92
         m90Q2eoyN8ocmGP7B5dN9LDnxrmiLmnE23SpRS861PxVpEhIxeK16eYOr8xY4BbLcHCK
         JyoUPu0I6R7hvgn1h+JmVMp/5I+RSVloiPb4r0w4JwZy/z8SR7MP8lnD38XJ+Lnupjvh
         jllPq5dlqa5NVSFuZuLe02EN6og76q0WfxdLxbArI3dxF8YWU0hTotsjIeJjIKhlNfoY
         ahI2ZIB2undMe6id1YknLLYL5aoa8xvbf+ioE2Vxcz16itmxUUtkxwEBoS7Ma/iogEZy
         CrGw==
X-Gm-Message-State: AOJu0YzxChSpPl1v8167gI4X0BFzEttrU8RrgizWsRzoOwKksnCOTrFh
	GjpEwHQYB1dc3kszCEww7HYLOsVhgDnqHvTemu3x2mde9pDrJ8XEtMp6Jaz8sFdHXa0xk+F7x5p
	rpJ8ceRk=
X-Gm-Gg: AR+sD11RTdq1lVtRH1x9Xv3nE+TKTYDE2TMO+qn8fN8Suu0x6FMo9e6FrS2cXxcyV3E
	IZn3Oo9t2vqsRaOF9w+sXJKW43ahJG4vEErGwhvPdy4Sdinp0JqRr3R5FZtB3DJ78PyStXUbXyz
	FcWZeRNr86g37stLirw5D5nU6IheuOX06SBgi32cv1rLp5+rF/4PsIzVvNuc82Zuh+0F28J2SBf
	ESyBeXHbVrN2Jr9TtiFcf1IyCICI21XApbZX9gkRzXzyw1N9kltRZwATr05qL67HleERFyGQwaB
	qX/K01OdPLBODhN9VnhFAcHTpSpwWD+WPBA+Kn/zcDKoDjmMLV9I5gYaRyFRgRDt8bd2AscoscW
	eChd1+tBDQG9tvUXKlq5xuJMV272afE3UcZ4BlAt6f4TlArRJ1ULKmI96oJkLbBKkfq8eGEXSKD
	b51I31Tfn2PRc5Wubai2vNgKBTUR+l09RBNcXEfNZonzq0JPu1LeaxligIaDXg8MORwNZnsxLD
X-Received: by 2002:adf:f311:0:b0:46e:7f72:b6fe with SMTP id ffacd0b85a97d-47fec523d07mr8462161f8f.19.1785933931038;
        Wed, 05 Aug 2026 05:45:31 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 4/5] x86/nmi: Check MSR_MISC_ENABLE for all Intel platforms
Date: Wed,  5 Aug 2026 13:45:24 +0100
Message-Id: <20260805124525.105457-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260805124525.105457-1-andrew.cooper3@citrix.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785933931-F1EAB2AC-CB6B44DA/0/0
X-purgate-type: clean
X-purgate-size: 2470

Right now it's only checked in setup_p4_watchdog(), and not in
setup_p6_watchdog().

Perform the check in the common Intel path in
setup_apic_nmi_watchdog(), and pass misc_enable as a parameter into
setup_p4_watchdog() to aoid reading it twice.

Fixes: 0dfba864fbff ("NMI watchdog support in Xen.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

I presume this bug went unnoticed because watchdog is off-by-default.
---
 xen/arch/x86/nmi.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index d9d07870a333..a8b0d79c7cf2 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -295,14 +295,8 @@ static void setup_p6_watchdog(unsigned counter)
     wrmsrns(MSR_P6_EVNTSEL(0), evntsel);
 }
 
-static void setup_p4_watchdog(void)
+static void setup_p4_watchdog(uint64_t misc_enable)
 {
-    uint64_t misc_enable;
-
-    rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
-    if ( !(misc_enable & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
-        return;
-
     nmi_perfctr_msr = MSR_P4_IQ_PERFCTR0;
     nmi_p4_cccr_val = P4_NMI_IQ_CCCR0;
     if ( boot_cpu_data.x86_num_siblings == 2 )
@@ -337,6 +331,8 @@ static void setup_p4_watchdog(void)
 
 void setup_apic_nmi_watchdog(void)
 {
+    uint64_t misc;
+
     if ( nmi_watchdog == NMI_NONE )
         return;
 
@@ -347,6 +343,14 @@ void setup_apic_nmi_watchdog(void)
         break;
 
     case X86_VENDOR_INTEL:
+        misc = rdmsr(MSR_IA32_MISC_ENABLE);
+
+        if ( !(misc & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
+        {
+            printk(XENLOG_WARNING "Intel Perfmon unavailable\n");
+            goto disable;
+        }
+
         switch ( boot_cpu_data.family )
         {
         case 6:
@@ -355,7 +359,7 @@ void setup_apic_nmi_watchdog(void)
                               : CORE_EVENT_CPU_CLOCKS_NOT_HALTED);
             break;
         case 15:
-            setup_p4_watchdog();
+            setup_p4_watchdog(misc);
             break;
         }
         break;
@@ -363,6 +367,7 @@ void setup_apic_nmi_watchdog(void)
 
     if ( nmi_perfctr_msr == 0 )
     {
+    disable:
         printk(XENLOG_WARNING "Failed to configure NMI watchdog\n");
         nmi_watchdog = NMI_NONE;
         return;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:45:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:45:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383394.1626703 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb03-0005NH-PI; Wed, 05 Aug 2026 12:45:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383394.1626703; Wed, 05 Aug 2026 12:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb03-0005M5-GC; Wed, 05 Aug 2026 12:45:35 +0000
Received: by outflank-mailman (input) for mailman id 1383394;
 Wed, 05 Aug 2026 12:45:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wrb01-00059f-TT
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:45:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrb01-009h29-A2
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:45:33 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a733064-e002-0a2a0a5209dd-0a2a45029942-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:33 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a73306d-6ca4-0a2a45020019-d155dd2addd7-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:45:33 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47f7854678cso591338f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:45:33 -0700 (PDT)
Received: from andrew-laptop.. ([157.231.70.114])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8779762f8f.28.2026.08.05.05.45.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 05:45:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1785933933; x=1786538733; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=7770vZRJ4ZFGBtmI51IRg/58qd/H6KqbB1Rxt63P7kE=;
        b=s304l9ZBXdbG+N90oKjzRFvQmwbyWj3DNzRlz0DMfQbu+SGg5uNeROz1Di0mbsY17P
         vzz95s/g3mC+b3eZBevM6NbnAueDYHVD5vbpn3vpL604j6HPOUEkKcnLpDCFG3axPKX0
         csPDP/lj3vVfRWdOjn/OCrnA/+e73FIOvxqx8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785933933; x=1786538733;
        h=content-transfer-encoding:content-type: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=7770vZRJ4ZFGBtmI51IRg/58qd/H6KqbB1Rxt63P7kE=;
        b=a7imZzMVvmwPOexWyxoOz0rHNwS9BLKu+veWRkWG7G1eARk7SU//48VTHsYwKbHH+A
         6V2mHK/2oqR+jdoF4iWylfT8hv5Edg7Jpwby73eQkiONGtAImG/LDpvW9F3hH4lkTiJ8
         xpaIqs86XASxUh6SSO92QVxi9lHtH6xEbt5r/t7i5JcRIeo3TwyzhUPr66DzjpvqTBIE
         6BNoScfRnOcUA5cV2dc1u/1YUJJMnKh2hcip8vAXOdh/sVnxiEtS0o38FVucuk0tz2Zs
         wv3ef8byUYeX5oUWaxgJj/+floIaj7TSOcijjwDScjLoE5KK5Hv4LoNrSlxyOo+3jjGF
         AU1g==
X-Gm-Message-State: AOJu0Yw3Ijxhg/Lzd+iWM9d+nAvYfjS4Hvk7lZEjq92VlGxyfC5VVEc3
	fLrqO5OqB8na8Rbq6FpJ9dD6fhBpRSOCdB1i4s7A+PEC0Jzh16Bex4hVLqeXQFwFq4Ohq+ZxyON
	AzyP8
X-Gm-Gg: AR+sD12+Wl6Yke9FX6SLwmYr8qt7TjYkamDLyS5rbrZS6SEksDSHIfFFB3Xw/cuHAVG
	ZNepcxHS2p2q11MoNs3Gsrrl97Kpo9xMnZ+jLwdscRLd4MQIHpa9yxI5JHl+LGHW38uuqWiUvm2
	PN801DMn40+kUuI1e40W3RuVPM5qr9q+Nas6zN0jsH/Bc3MWLNbvlpTCI54BgC4shRx1puLlJWP
	ueaKfmYZuVmixwg/jnLFXzrE55mqPTryWoqNKU4RmhjML5JYpvkbEyLhJbntAmHiIcHC5ou5cCB
	wNCPTxl3xlsBRKPHgHju7JMywDdFGOOAHRAzrkXWW8vVByRUXm8mbB5VmPSznBvSBEzoqLQGF7d
	m5pZwvD8sm2uSX0DanNh5HlhBL2vpjQbsHjEFJ92af7qYAjXPap7IGOwEx8zOnfx+EhG1YZ+qlW
	wbqf/QIJzSZT5zbslif80pjdfbP7WcKHeif9lg+t4nPRCLthTg5oW8j0g7T5Azr9QEt6K6Twr2
X-Received: by 2002:a05:6000:25ca:b0:47f:9568:ebf0 with SMTP id ffacd0b85a97d-47fec52786bmr10833838f8f.23.1785933932021;
        Wed, 05 Aug 2026 05:45:32 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 5/5] x86/nmi: Don't configure EvtSel repeatedly
Date: Wed,  5 Aug 2026 13:45:25 +0100
Message-Id: <20260805124525.105457-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260805124525.105457-1-andrew.cooper3@citrix.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1785933933-F38BC2AC-84BF9D56/0/0
X-purgate-type: clean
X-purgate-size: 3266

In both setup_{k7,p6}_watchdog(), EvtSel0 is first zeroed, then written with
everything but the enable bit, then written with the enable bit.

setup_p4_watchdog() is slightly more complicated, owing to what
appears to be a bug introduced by commit 2a2bd8de16b6 ("Clean up NMI
watchdog handler."), which causes a second bit to be temporarily
different too.

The middle of the three writes is useless in all cases.  Drop it.

While doing this, rename the 'counter' parameter for
setup_p6_watchdog().  It is the event which is passed in; the counter
is always counter 0.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/nmi.c | 29 +++++++----------------------
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index a8b0d79c7cf2..a697486b834d 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -246,29 +246,20 @@ static inline void write_watchdog_counter(const char *descr)
 
 static void setup_k7_watchdog(void)
 {
-    unsigned int evntsel;
-
     nmi_perfctr_msr = MSR_K7_PERFCTR0;
 
     clear_msr_range(MSR_K7_EVNTSEL0, 4);
     clear_msr_range(MSR_K7_PERFCTR0, 4);
 
-    evntsel = K7_EVNTSEL_INT
-        | K7_EVNTSEL_OS
-        | K7_EVNTSEL_USR
-        | K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING;
-
-    wrmsrns(MSR_K7_EVNTSEL0, evntsel);
     write_watchdog_counter("K7_PERFCTR0");
     apic_write(APIC_LVTPC, APIC_DM_NMI);
-    evntsel |= K7_EVNTSEL_ENABLE;
-    wrmsrns(MSR_K7_EVNTSEL0, evntsel);
+    wrmsrns(MSR_K7_EVNTSEL0,
+            K7_EVNTSEL_ENABLE | K7_EVNTSEL_INT | K7_EVNTSEL_OS |
+            K7_EVNTSEL_USR | K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING);
 }
 
-static void setup_p6_watchdog(unsigned counter)
+static void setup_p6_watchdog(unsigned int event)
 {
-    unsigned int evntsel;
-
     if ( !nmi_p6_event_width && current_cpu_data.cpuid_level >= 0xa )
         nmi_p6_event_width = MASK_EXTR(cpuid_eax(0xa), P6_EVENT_WIDTH_MASK);
     if ( !nmi_p6_event_width )
@@ -283,16 +274,11 @@ static void setup_p6_watchdog(unsigned counter)
     clear_msr_range(MSR_P6_EVNTSEL(0), 2);
     clear_msr_range(MSR_P6_PERFCTR(0), 2);
 
-    evntsel = P6_EVNTSEL_INT
-        | P6_EVNTSEL_OS
-        | P6_EVNTSEL_USR
-        | counter;
-
-    wrmsrns(MSR_P6_EVNTSEL(0), evntsel);
     write_watchdog_counter("P6_PERFCTR0");
     apic_write(APIC_LVTPC, APIC_DM_NMI);
-    evntsel |= P6_EVNTSEL0_ENABLE;
-    wrmsrns(MSR_P6_EVNTSEL(0), evntsel);
+    wrmsrns(MSR_P6_EVNTSEL(0),
+            P6_EVNTSEL0_ENABLE | P6_EVNTSEL_INT | P6_EVNTSEL_OS |
+            P6_EVNTSEL_USR | event);
 }
 
 static void setup_p4_watchdog(uint64_t misc_enable)
@@ -323,7 +309,6 @@ static void setup_p4_watchdog(uint64_t misc_enable)
     clear_msr_range(MSR_P4_BPU_PERFCTR0, 18);
 
     wrmsrl(MSR_P4_CRU_ESCR0, P4_NMI_CRU_ESCR0);
-    wrmsrl(MSR_P4_IQ_CCCR0, P4_NMI_IQ_CCCR0 & ~P4_CCCR_ENABLE);
     write_watchdog_counter("P4_IQ_COUNTER0");
     apic_write(APIC_LVTPC, APIC_DM_NMI);
     wrmsrl(MSR_P4_IQ_CCCR0, nmi_p4_cccr_val);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:48:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:48:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383433.1626716 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb2q-0007ix-4G; Wed, 05 Aug 2026 12:48:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383433.1626716; Wed, 05 Aug 2026 12:48:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrb2p-0007iq-Vs; Wed, 05 Aug 2026 12:48:27 +0000
Received: by outflank-mailman (input) for mailman id 1383433;
 Wed, 05 Aug 2026 12:48:26 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wrb2o-0007ik-JB
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:48:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrb2n-009hgA-RT
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:48:25 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a733103-5cb7-0a2a0a5109dd-0a2a450ba28a-38
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:48:25 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a733119-b7e8-0a2a450b0019-d155dd36d961-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:48:25 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-47f71156e1aso448147f8f.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:48:25 -0700 (PDT)
Received: from [192.168.1.109] ([88.241.184.235])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e533sm8799726f8f.28.2026.08.05.05.48.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 05:48:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785934105; x=1786538905; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=4Fg5Jlc1jxaGcQAj3FbA1in17FLwTIaps3QCwd1CSKs=;
        b=CQLLvx4cRrVSugBPl3P9oSqPMh2sRVdebg6I7FuBJw9LP/NkuArW6wBqb2ziwYYtZD
         fuXsexzQMy7h9EnTHDmUtFf8jNpkbkMjKxnm8qfisWpcm9RmfMP+eIRigNi/5lCZTkhY
         QPRY3ZpVd5YaNLo09wpuufW6DCX5AR+G/pYgs/sIoQT90ZXAAnd6/QxLedcAYDAlRAcl
         yXc+75l86lEJ6cIwRH6/yqUKs5yAWU3krjgxzEl3xw/Gimil4Jc017FVhScV3zOZOQ4L
         QYS3gO3oblh+3VK5Qh+VbZxaU5v92ZGMn5sASMgrC3kbFLcDU3KmUWJpuGr0GVRGgBVT
         x0aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785934105; x=1786538905;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=4Fg5Jlc1jxaGcQAj3FbA1in17FLwTIaps3QCwd1CSKs=;
        b=LnsRFjLDYz6tvk5Y5PQTZW0qpH0A3DdJl8u5KNoVwVGKh8YoO2hUoJipH+TDWmIeKo
         mrhEDRJvUZLlYSvsfNni6zJV1ZyzD3oCx0kWq9VmWK/EQ6GYnCoKBWGdqvAjM8c+a5PZ
         TLcTWxOuN5GgmiNMPnoNd1dJ2VRNljVBdf4Dvf5J37Nm7RgagRVnqmAEzheMKi9lduTk
         VCfWX6aqtGu72Xd4bkxM6a6d1nuq8Av1z4cHhCk+C9CYX4ZjsA5BPWTV08noABi1i1JE
         AOrgcOW8XT0kzofok3o/eLYkelq1mKo3e3kFk6dMqFZFImHB7mNZG4TioM19ZJv9tB6L
         nHrw==
X-Forwarded-Encrypted: i=1; AHgh+RrQb/B9zTywgz+CkwwEtxrpygjGz5Cclhh8YcxOmMVWvszYMKO8o60eleg9tf7EsaOapW2bULzyI6s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWYuOo4NW0cgM9T2KROYWWMQzs1NLCLPl3ysi12/5GH1BUqdH6
	YytNqHFXIyBftXRX6tAyYO280liRmcGtyoxhdfdlMNsy0z8pRGgTVHHE
X-Gm-Gg: AR+sD12pTjDJhrznwhZ0sdvk85L1zuEy27C4z82YDCWUuj/LuRPVYurqrI0WeW+JVyE
	fjXMDaupylh2EEN/jTwUNOYwh2PHbhSKKshhD4yyTQvBzRPeokLdRrt3KqiVO+Ybj4K6XEML8RB
	O1qWX4BYfdmDbS98j/Bu+mmLyYLAAk8AE+tjIB8CnTW4Sc5FjM0R4+gl9jRqDjBnwnabqYzi/Sv
	ucwhA3+qcUG4pkh27JgkyZrX+vm23Bgi1rYQTSy0+N0qSSxxkXnZ/I0yDnhkB9aseRvdQ1GnoVU
	OSwVQNsXKhrTsV6/zANaTpzhHP+5dTpCsWZ7ioVudoim8e+23DteQXJDhhYnwjfMO4UMp961QEa
	p217JFxQbIWL83Oi7yH4m1sZpGLVdSNQ+O4frzIgOM2t9F8J4hdy3Du1yUb7kXkaysKuxFCQih4
	VdEyaJB0A9XG+q9e/99geXPAycOpNF/k2EhByU9ADeEXDP8GgvzP8LTbEX5Sl0bNIfI61O
X-Received: by 2002:a05:6000:41f7:b0:47f:4ac9:98bc with SMTP id ffacd0b85a97d-47fec63f8dbmr11018768f8f.24.1785934105000;
        Wed, 05 Aug 2026 05:48:25 -0700 (PDT)
Message-ID: <3de6fbd2-0e2c-46ac-b858-d3987833d796@gmail.com>
Date: Wed, 5 Aug 2026 15:48:16 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: rename scheduler registration symbols
To: Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, jgross@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com,
 xen-devel@lists.xenproject.org
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-3-frn1furkan10@gmail.com>
 <14dd261f-8d78-4c24-b927-f7f2c01dbdf8@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <14dd261f-8d78-4c24-b927-f7f2c01dbdf8@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1785934105-192CC9EA-EC8BA660/0/0
X-purgate-type: clean
X-purgate-size: 2059

Hi Jan,

On 8/5/26 14:43, Jan Beulich wrote:
> On 04.08.2026 07:53, Furkan Caliskan wrote:
>> REGISTER_SCHEDULER(), schedulers[], NUM_SCHEDULERS, and the
>> per-arch SCHEDULER_ARRAY linker macro now register and hold
>> struct sched_ops instances rather than struct scheduler ones,
>> but still carry names describing the old type.
>>
>> Rename them to match the current behaviour.
>> No functional change.
>>
>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>> ---
>>  xen/arch/arm/xen.lds.S      |  2 +-
>>  xen/arch/ppc/xen.lds.S      |  2 +-
>>  xen/arch/riscv/xen.lds.S    |  2 +-
>>  xen/arch/x86/xen.lds.S      |  2 +-
>>  xen/common/sched/arinc653.c |  2 +-
>>  xen/common/sched/core.c     | 33 +++++++++++++++++----------------
>>  xen/common/sched/credit.c   |  2 +-
>>  xen/common/sched/credit2.c  |  2 +-
>>  xen/common/sched/null.c     |  2 +-
>>  xen/common/sched/private.h  |  4 ++--
>>  xen/common/sched/rt.c       |  2 +-
>>  xen/include/xen/xen.lds.h   | 10 +++++-----
>>  12 files changed, 33 insertions(+), 32 deletions(-)
> 
> I'm not quite sure if all of this is really useful. In many (all?) places
> I think "scheduler" as a term is still quite applicable.
> 
> One (general) nit though: if already you touch malformed lines (overlong
> ones is which prompted this comment), please adjust them to be style-
> conformant.
> 
> Jan

The main reason I renamed those symbols was type consistency - since 
'struct scheduler' is now just the runtime per-cpupool object, keeping 
'schedulers[]' and 'REGISTER_SCHEDULER()' around to hold 'struct 
sched_ops' pointers felt like it might confuse someone reading the code 
later. 

That said, I get your point. At a higher level, those macros and linker 
arrays are still just registering scheduler implementations, so keeping 
the names is okay too. If the maintainers prefer keeping the existing 
naming, patch 1 can simply be taken on its own without the second patch. 

Juergen, what do you think here?

Thanks,
Furkan Caliskan



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 12:57:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 12:57:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383450.1626724 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbBN-000115-0u; Wed, 05 Aug 2026 12:57:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383450.1626724; Wed, 05 Aug 2026 12:57:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbBM-00010y-TI; Wed, 05 Aug 2026 12:57:16 +0000
Received: by outflank-mailman (input) for mailman id 1383450;
 Wed, 05 Aug 2026 12:57:15 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrbBL-00010s-DT
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 12:57:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrbBK-004dNI-Gr
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:14 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a733324-e002-0a2a0a5209dd-0a2a450bd186-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:57:11 +0200
Received: from [209.85.208.54] (helo=mail-ed1-f54.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a733327-b7e8-0a2a450b0019-d155d036a42d-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 14:57:11 +0200
Received: by mail-ed1-f54.google.com with SMTP id
 4fb4d7f45d1cf-6a0a0466d12so2137761a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 05:57:11 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a18b26b488sm264446a12.25.2026.08.05.05.57.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 05:57:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785934631; x=1786539431; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Uez3Y760HCQxEKEaZ9zt8WAYJlzXp3nbhVm+nYgHW9Y=;
        b=f4CU36V84buenv3rSqOhO31cqUt5mK1lh4wDDwgZOMuruFN9o1FfIgwQdxhEL4MNM2
         9zKfVfKDFscBiJuV3eYzcAtaamM9iKMPLoUk16BhWCGO2FWFt7RlQ+dK4szkE4FoYtIQ
         zJVKjlEzhl44VUmfJW06AYNREl2/ChSc0kyebMQ0qdOxgHORcyBvtlUzGI7tDIBTdaxn
         LBeBii387W2TMsvjjasyYek5i/V+qYq0I8InyZKlbepUmE5FZfKcfhoSkRzCll0+woNV
         fqkdiPAV2vBk9xv4VsZwqox0iKqPAhs/QbYYKPJKK3svg1xvE11+x9r+QlWC+pxowsMl
         q4Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785934631; x=1786539431;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Uez3Y760HCQxEKEaZ9zt8WAYJlzXp3nbhVm+nYgHW9Y=;
        b=WQ44CjiONgieh6gDcLLu6lw3+yLcrK3Cpyfk7qyaIbgLlufj2YYnr9+1RioMoUr+fi
         RBi2xzCy+uYBk733sPfOTtKfMC8W/tosMD5pxJWIZC1Tphed8zojcuKZq3+z35pS47tq
         4A9z5qzkShyVhQvbOTnktcFxq8nF5P/OK7MD7AzidQqA0mzU1VzI6YH4nVoIqc7nNe8d
         PAjJkoicyuf0e4o1BxUOJPwZg8YQpLWr1ZUdxGFO7LQN30WVoa7ZTaJecNl7Lxmrzh/1
         q6y1LKRVlpSUyhL33mnj2Pk1eHSMVzJhu16cgsTJZ3nV3KvwatC/aWhbh9jQvcqTFdaf
         fZkA==
X-Forwarded-Encrypted: i=1; AHgh+Ro90WSjoP34W4JmfVIPJL3ozU7W2ug9OPRvkaGmDhsQ0PUiSNs2VHf31cocXd7g4hPPbbaoC2cbnVQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxFKxqShXUojhhpdcVVlN26SZrWdgJCqXFKehmIHbFhzUr49wbU
	uu3amZFvIy76CufxsJ6Ph6AngG7KDCj34wSQ94Q4fKQ6p0OWdcFy9nc9Jtj7akMqwdM=
X-Gm-Gg: AR+sD10PhEwVEuufcys2MFEmecOgKgcrYndaY4W+AP835N30x0Hdfrq+5PWy5O6I0NF
	yJNegnle3Wo+UmMjbDsGriJ70gFHcTvaf1wXsfYTzTmHfKDoQMfU8v8Vp9Sf3yL5DOmOhxs3SMP
	R8scGm211kZLKT4bhkXJperXG600ipgQnjwEH/TGvH3Uah1sBs0BsCyT1VfoEJJ4Bs5BhGFBPhJ
	iXMZ1czV8kdSaDPcrfYl0cRSvh2qBwQs8tVkLm9I6XnByYSG23YhzttEpuEllt8OF2hywbonSVC
	n8yvKs/ZMjrgQtH2EXonWosJTlfeUfNpHjHH2ejbXd6zPZsJi7OVYJMJDpSGiwN0TuMbRwRjjpX
	NAmbkTzrsGE8iQ802JT9ATrX1XjKJeM10CZvTy9JG9TFGaKuE+0LaYGSgvDXT5ZJRZrCHrUQccy
	1GUPd17asKm8KW5X+9nUfKqgqGYpw/u7PZZlM1f2MEnNitPUuSy2mN6LEneoOx9AHgBvucmnlnO
	yaK0EaORX8/Ov/13ALFzQPJN/s7j4rUJ7yo6GJ6r83hGT5QfBpGyHCSmZSvwZ9y9ojmMEOtMMwE
	ABlwi2uCk/Y6tSI=
X-Received: by 2002:a05:6402:52cd:b0:697:8b0c:36e1 with SMTP id 4fb4d7f45d1cf-6a14ef2123bmr3632287a12.4.1785934630814;
        Wed, 05 Aug 2026 05:57:10 -0700 (PDT)
Message-ID: <a7f8dbfd-6247-4905-bc37-ac4e9977ad94@suse.com>
Date: Wed, 5 Aug 2026 14:57:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: rename scheduler registration symbols
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, gwd@xenproject.org, dfaggioli@suse.com,
 stewart.hildebrand@amd.com, nathan.studer@dornerworks.com,
 roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org,
 sstabellini@kernel.org, michal.orzel@amd.com, bertrand.marquis@arm.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech,
 tpearson@raptorengineering.com, alistair.francis@wdc.com,
 connojdavis@gmail.com, xen-devel@lists.xenproject.org
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-3-frn1furkan10@gmail.com>
 <14dd261f-8d78-4c24-b927-f7f2c01dbdf8@suse.com>
 <3de6fbd2-0e2c-46ac-b858-d3987833d796@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <3de6fbd2-0e2c-46ac-b858-d3987833d796@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------8VDZGiCxvC0PohVfEt0ee0cV"
X-purgate-ID: tlsNG-42698a/1785934631-A88C99EA-BCD349D8/0/0
X-purgate-type: clean
X-purgate-size: 11470

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------8VDZGiCxvC0PohVfEt0ee0cV
Content-Type: multipart/mixed; boundary="------------Dt5H7KYGzgPxZyK0fqoYT3T4";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, gwd@xenproject.org, dfaggioli@suse.com,
 stewart.hildebrand@amd.com, nathan.studer@dornerworks.com,
 roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org,
 sstabellini@kernel.org, michal.orzel@amd.com, bertrand.marquis@arm.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech,
 tpearson@raptorengineering.com, alistair.francis@wdc.com,
 connojdavis@gmail.com, xen-devel@lists.xenproject.org
Message-ID: <a7f8dbfd-6247-4905-bc37-ac4e9977ad94@suse.com>
Subject: Re: [PATCH v2 2/2] xen/sched: rename scheduler registration symbols
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-3-frn1furkan10@gmail.com>
 <14dd261f-8d78-4c24-b927-f7f2c01dbdf8@suse.com>
 <3de6fbd2-0e2c-46ac-b858-d3987833d796@gmail.com>
In-Reply-To: <3de6fbd2-0e2c-46ac-b858-d3987833d796@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------Dt5H7KYGzgPxZyK0fqoYT3T4
Content-Type: multipart/mixed; boundary="------------IRlJKDHBgdj9ad1hPAxHm6Jb"

--------------IRlJKDHBgdj9ad1hPAxHm6Jb
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTQ6NDgsIEZ1cmthbiDDh2FsxLHFn2thbiB3cm90ZToNCj4gSGkgSmFu
LA0KPiANCj4gT24gOC81LzI2IDE0OjQzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE9uIDA0
LjA4LjIwMjYgMDc6NTMsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4+PiBSRUdJU1RFUl9T
Q0hFRFVMRVIoKSwgc2NoZWR1bGVyc1tdLCBOVU1fU0NIRURVTEVSUywgYW5kIHRoZQ0KPj4+
IHBlci1hcmNoIFNDSEVEVUxFUl9BUlJBWSBsaW5rZXIgbWFjcm8gbm93IHJlZ2lzdGVyIGFu
ZCBob2xkDQo+Pj4gc3RydWN0IHNjaGVkX29wcyBpbnN0YW5jZXMgcmF0aGVyIHRoYW4gc3Ry
dWN0IHNjaGVkdWxlciBvbmVzLA0KPj4+IGJ1dCBzdGlsbCBjYXJyeSBuYW1lcyBkZXNjcmli
aW5nIHRoZSBvbGQgdHlwZS4NCj4+Pg0KPj4+IFJlbmFtZSB0aGVtIHRvIG1hdGNoIHRoZSBj
dXJyZW50IGJlaGF2aW91ci4NCj4+PiBObyBmdW5jdGlvbmFsIGNoYW5nZS4NCj4+Pg0KPj4+
IFNpZ25lZC1vZmYtYnk6IEZ1cmthbiBDYWxpc2thbiA8ZnJuMWZ1cmthbjEwQGdtYWlsLmNv
bT4NCj4+PiAtLS0NCj4+PiAgIHhlbi9hcmNoL2FybS94ZW4ubGRzLlMgICAgICB8ICAyICst
DQo+Pj4gICB4ZW4vYXJjaC9wcGMveGVuLmxkcy5TICAgICAgfCAgMiArLQ0KPj4+ICAgeGVu
L2FyY2gvcmlzY3YveGVuLmxkcy5TICAgIHwgIDIgKy0NCj4+PiAgIHhlbi9hcmNoL3g4Ni94
ZW4ubGRzLlMgICAgICB8ICAyICstDQo+Pj4gICB4ZW4vY29tbW9uL3NjaGVkL2FyaW5jNjUz
LmMgfCAgMiArLQ0KPj4+ICAgeGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMgICAgIHwgMzMgKysr
KysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tDQo+Pj4gICB4ZW4vY29tbW9uL3NjaGVk
L2NyZWRpdC5jICAgfCAgMiArLQ0KPj4+ICAgeGVuL2NvbW1vbi9zY2hlZC9jcmVkaXQyLmMg
IHwgIDIgKy0NCj4+PiAgIHhlbi9jb21tb24vc2NoZWQvbnVsbC5jICAgICB8ICAyICstDQo+
Pj4gICB4ZW4vY29tbW9uL3NjaGVkL3ByaXZhdGUuaCAgfCAgNCArKy0tDQo+Pj4gICB4ZW4v
Y29tbW9uL3NjaGVkL3J0LmMgICAgICAgfCAgMiArLQ0KPj4+ICAgeGVuL2luY2x1ZGUveGVu
L3hlbi5sZHMuaCAgIHwgMTAgKysrKystLS0tLQ0KPj4+ICAgMTIgZmlsZXMgY2hhbmdlZCwg
MzMgaW5zZXJ0aW9ucygrKSwgMzIgZGVsZXRpb25zKC0pDQo+Pg0KPj4gSSdtIG5vdCBxdWl0
ZSBzdXJlIGlmIGFsbCBvZiB0aGlzIGlzIHJlYWxseSB1c2VmdWwuIEluIG1hbnkgKGFsbD8p
IHBsYWNlcw0KPj4gSSB0aGluayAic2NoZWR1bGVyIiBhcyBhIHRlcm0gaXMgc3RpbGwgcXVp
dGUgYXBwbGljYWJsZS4NCj4+DQo+PiBPbmUgKGdlbmVyYWwpIG5pdCB0aG91Z2g6IGlmIGFs
cmVhZHkgeW91IHRvdWNoIG1hbGZvcm1lZCBsaW5lcyAob3ZlcmxvbmcNCj4+IG9uZXMgaXMg
d2hpY2ggcHJvbXB0ZWQgdGhpcyBjb21tZW50KSwgcGxlYXNlIGFkanVzdCB0aGVtIHRvIGJl
IHN0eWxlLQ0KPj4gY29uZm9ybWFudC4NCj4+DQo+PiBKYW4NCj4gDQo+IFRoZSBtYWluIHJl
YXNvbiBJIHJlbmFtZWQgdGhvc2Ugc3ltYm9scyB3YXMgdHlwZSBjb25zaXN0ZW5jeSAtIHNp
bmNlDQo+ICdzdHJ1Y3Qgc2NoZWR1bGVyJyBpcyBub3cganVzdCB0aGUgcnVudGltZSBwZXIt
Y3B1cG9vbCBvYmplY3QsIGtlZXBpbmcNCj4gJ3NjaGVkdWxlcnNbXScgYW5kICdSRUdJU1RF
Ul9TQ0hFRFVMRVIoKScgYXJvdW5kIHRvIGhvbGQgJ3N0cnVjdA0KPiBzY2hlZF9vcHMnIHBv
aW50ZXJzIGZlbHQgbGlrZSBpdCBtaWdodCBjb25mdXNlIHNvbWVvbmUgcmVhZGluZyB0aGUg
Y29kZQ0KPiBsYXRlci4NCj4gDQo+IFRoYXQgc2FpZCwgSSBnZXQgeW91ciBwb2ludC4gQXQg
YSBoaWdoZXIgbGV2ZWwsIHRob3NlIG1hY3JvcyBhbmQgbGlua2VyDQo+IGFycmF5cyBhcmUg
c3RpbGwganVzdCByZWdpc3RlcmluZyBzY2hlZHVsZXIgaW1wbGVtZW50YXRpb25zLCBzbyBr
ZWVwaW5nDQo+IHRoZSBuYW1lcyBpcyBva2F5IHRvby4gSWYgdGhlIG1haW50YWluZXJzIHBy
ZWZlciBrZWVwaW5nIHRoZSBleGlzdGluZw0KPiBuYW1pbmcsIHBhdGNoIDEgY2FuIHNpbXBs
eSBiZSB0YWtlbiBvbiBpdHMgb3duIHdpdGhvdXQgdGhlIHNlY29uZCBwYXRjaC4NCj4gDQo+
IEp1ZXJnZW4sIHdoYXQgZG8geW91IHRoaW5rIGhlcmU/DQoNCkkgZG9uJ3QgdGhpbmsgZGlm
ZmVyZW50IG5hbWVzIG1ha2UgYSByZWFsIGRpZmZlcmVuY2UuIEkgYWxyZWFkeSBleHBlY3Rl
ZA0KdGhpcyByZW5hbWluZyB0byBiZSBxdWVzdGlvbmVkLCBoZW5jZSB0aGUgc3VnZ2VzdGlv
biB0byBkbyBpdCBpbiBhbiBleHRyYQ0KcGF0Y2gsIGFsbG93aW5nIHRvIHRha2UgdGhlIG1h
aW4gcmV3b3JrIGluZGVwZW5kZW50bHkgZnJvbSBpdC4gOi0pDQoNCklPVzogSSB3b3VsZG4n
dCBvcHBvc2UgZG9pbmcgdGhlIHJlbmFtaW5nLCBidXQgSSdkIHRha2UgcmVwbGllcyBhcyBK
YW4ncw0KYXMgYSBoaW50IG5vdCB0byBBY2sgdGhlIHBhdGNoLg0KDQoNCkp1ZXJnZW4NCg==

--------------IRlJKDHBgdj9ad1hPAxHm6Jb
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------IRlJKDHBgdj9ad1hPAxHm6Jb--

--------------Dt5H7KYGzgPxZyK0fqoYT3T4--

--------------8VDZGiCxvC0PohVfEt0ee0cV
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpzMyYFAwAAAAAACgkQsN6d1ii/Ey+K
fAgAgIT4pyEw2GnM013+P1NM1eLKA/QPWRpp4aekdA2de4MHsNArJTP4YmBFqrtQWUvXm/rIMw3s
tmXw9pWqNhbNCwb8opk8XYe61OTyb3xnKZWfZq/sBslexo697p0oIUJHL/BPIc6W3KNtGAChH0CJ
w02F2NAmAsR2FtFVD2vJUzJr4hG0GXB+pMkTftm8UWxVTucD+PEWy44lUPae/GAdofHvsCa+LnTC
8evYpKctcPh+drlFbsJafVXVy8nXYD1GMXvt5sOTdB6DkZ+8LJs1N5yxz5KTLMlgp0ZL9KXAKg1F
hzasZyhzf3qEpIeviolvLiSmi3WYF4I0WVkIUcncng==
=qBl0
-----END PGP SIGNATURE-----

--------------8VDZGiCxvC0PohVfEt0ee0cV--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:01:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:01:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383457.1626734 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbF6-0002wF-Fr; Wed, 05 Aug 2026 13:01:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383457.1626734; Wed, 05 Aug 2026 13:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbF6-0002w8-CF; Wed, 05 Aug 2026 13:01:08 +0000
Received: by outflank-mailman (input) for mailman id 1383457;
 Wed, 05 Aug 2026 13:01:06 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrbF4-0002w1-B2
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:01:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrbF3-00F0hI-Jl
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:01:05 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a73340f-5cb7-0a2a0a5109dd-0a2a450cca3a-10
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:01:05 +0200
Received: from [209.85.208.50] (helo=mail-ed1-f50.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a733411-f479-0a2a450c0019-d155d032e8bf-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:01:05 +0200
Received: by mail-ed1-f50.google.com with SMTP id
 4fb4d7f45d1cf-6a097f5ab95so1386932a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:01:05 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a1462c4432sm1966922a12.26.2026.08.05.06.01.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 06:01:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785934864; x=1786539664; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Dy7OAYKdpFSION1qK9mLR1WaGwo6ArtSEVtHpH3KkpM=;
        b=QQEf42qJnrTxfo1zRW2FSPqPD3+R4acarIimedep5XEd7SDJKp+981nbkjpxKz1eqL
         HObxr1QAG8EpkQPtnqfjflKePiVCoWUQFHeoW9kNQP/+nUvHaexVsURXj92Kw7yPnRPa
         4tGaf6tt104+f1o32w5XjHwazbJ7d5EV89jkDukdRbKt07ZvBJoSqzCVO8cyXuiTI78Q
         ZOBF/EnzGunbJQUjtHIGVQKXoXQAZMBqfCbrJm+Xzs+IAx6xiaUbxC6ZY2RA5y9ZTwyn
         2C38InWsC/WjudtPE9ybA23ur9/DKk8JcYa6GhaYMS1aiCODk37c+AjS8R/SqsMTksl6
         rpiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785934864; x=1786539664;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Dy7OAYKdpFSION1qK9mLR1WaGwo6ArtSEVtHpH3KkpM=;
        b=Q4ovANe17yu7rglKxdLIvC9vhs0RUNZJq8ib1OhVcc8T8rABupDCIHT1UOZvOFcKTn
         sJbOlYM3Xt08J3e01c/k60Qe5kub4s+KeIRhOysJ1XhbZd+8u/XR7Eso6blJkqrl1hqY
         aXoviu7IG20UVn6XsXJKgE35muiDBts/E/6qhAWuUVIZQr0diffHyaxp0+LmxITLWGrG
         PDVytwBeQYeugNo1+Oy/WZFQ5nmfXwcrmLaISINyqKgkSccpVqkHkC8DJiLia75le4TS
         OHsdR/5JY+/jw2lWENKFIEr5Ko3pjjGGzObV6WvIaVd0l0Ishp2ZZx4/nzj4EOBnfjWs
         JK+w==
X-Forwarded-Encrypted: i=1; AHgh+Roq46QCZtxZctSerCzozF5SCWdkj39e5z6JlrCPlXgAqVAoQUdCXIQjl7w0f45gseGjWDXrm+Zz4BU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyW9bg1Y5hAu0WWgwXC8+h0phdvT/uHWzJbV/N7YcYYnUh85WXO
	bJk0hjZ49pqlUnKAHf7MeAoGSkgQ8LVkSd4Lx6IvzYH6wFkHEc/uZ7RdYYA0/J5T604B0ciSJoj
	k5sPPldE=
X-Gm-Gg: AR+sD13hO26k4whFaJ2UmvtuZHlgkky2h158Zs/hyFBB66r1t/D00CcibFPH9TyIQ0w
	J/DBNArHw4vRcknpN8XdScW1J4ngPvr08tUFNjI1r6NZIidEFyhFSliUQ2xsvcluKUlpH+hu6dp
	cllAlRs5lYbE2jrnh4itKyFLWd5WhhxuC0cL3p5eK8ik4bjOtBMOErrFqUWlqZF+hgDJCffg+LJ
	XITDR0XTNA3CGcMcwOnWYWArrRtYT0fiVVZPpxZ12RzvITsCxcLH+fM4ZVxytYcLyqsjQoOHnFM
	NyMw66QFuViHzwoAjCZv4LLT+tljQzcPOaup/Z+z6xkC3WzXNmtZkRAo9AMayxDpyEsnKAIeFh5
	eBxaDmMbps8c2TEKvyIaQjF1dRc5tdDLOoYM9wgVsJLhkuOerTOg/SMGkJNCANj1muzTFXk7F6c
	IsL25FHj1BeuZHItQmSFdUl+q7kZfP5h2KzCWU5X2t6JEaBoSIFMrPHsjxoQ8BNPrr5fa25YEIo
	TPH6YSKnww83SK+E2ERRHcgFGo0lhFczHpCtzyXmbsfx/Pejb0KbD0m4UzsifApzAUXsgo3iwcU
	nsf0BncCtf1BxAw=
X-Received: by 2002:a05:6402:50cf:b0:6a0:7a06:302a with SMTP id 4fb4d7f45d1cf-6a14f0e51f6mr3480243a12.3.1785934863571;
        Wed, 05 Aug 2026 06:01:03 -0700 (PDT)
Message-ID: <9ecb95f6-5235-4032-b0ab-c8b2f5a8830e@suse.com>
Date: Wed, 5 Aug 2026 15:01:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: split scheduler vtable from struct
 scheduler
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-2-frn1furkan10@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260804055327.22119-2-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------MaBRrfc6bR2rpKhS7HyJH9hK"
X-purgate-ID: tlsNG-d25034/1785934865-52331A5B-2BDD2FDC/0/0
X-purgate-type: clean
X-purgate-size: 9864

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------MaBRrfc6bR2rpKhS7HyJH9hK
Content-Type: multipart/mixed; boundary="------------k00BdssbclEkhrLi90HNJ0s9";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, gwd@xenproject.org,
 dfaggioli@suse.com, stewart.hildebrand@amd.com,
 nathan.studer@dornerworks.com, roger@xenproject.org,
 anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org,
 michal.orzel@amd.com, bertrand.marquis@arm.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech, tpearson@raptorengineering.com,
 alistair.francis@wdc.com, connojdavis@gmail.com
Message-ID: <9ecb95f6-5235-4032-b0ab-c8b2f5a8830e@suse.com>
Subject: Re: [PATCH v2 1/2] xen/sched: split scheduler vtable from struct
 scheduler
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-2-frn1furkan10@gmail.com>
In-Reply-To: <20260804055327.22119-2-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------k00BdssbclEkhrLi90HNJ0s9
Content-Type: multipart/mixed; boundary="------------CoTMydheAf7SCdPdQy3APn7A"

--------------CoTMydheAf7SCdPdQy3APn7A
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDQuMDguMjYgMDc6NTMsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gc3RydWN0IHNj
aGVkdWxlciBjdXJyZW50bHkgc2VydmVzIHR3byBwdXJwb3NlczogaXQgaXMgdGhlIHN0YXRp
Yw0KPiB2dGFibGUgYSBzY2hlZHVsZXIgYmFja2VuZCBkZWZpbmVzIChuYW1lLCBvcHRfbmFt
ZSwgc2NoZWRfaWQsIGFuZA0KPiBhbGwgaXRzIGZ1bmN0aW9uIHBvaW50ZXJzKSwgYW5kIGl0
IGlzIGFsc28gdGhlIHBlci1jcHVwb29sIHJ1bnRpbWUNCj4gb2JqZWN0IHNjaGVkdWxlcl9h
bGxvYygpIGFsbG9jYXRlcy4gQmVpbmcgdGhlIHNhbWUgdHlwZSBmb3JjZXMNCj4gc2NoZWR1
bGVyX2FsbG9jKCkgdG8gbWVtY3B5KCkgdGhlIHdob2xlIHZ0YWJsZSBpbnRvIGEgZnJlc2gN
Cj4gYWxsb2NhdGlvbiBwZXIgY3B1cG9vbCwgZHVwbGljYXRpbmcgaWRlbnRpY2FsIGZ1bmN0
aW9uIHBvaW50ZXJzDQo+IGFjcm9zcyBldmVyeSBjcHVwb29sIHVzaW5nIHRoZSBzYW1lIHNj
aGVkdWxlci4NCj4gDQo+IFNwbGl0IHRoZSB2dGFibGUgb3V0IGludG8gaXRzIG93biB0eXBl
LCBzdHJ1Y3Qgc2NoZWRfb3BzLCBzbyBpdA0KPiBjYW4gYmUgc2hhcmVkIGJ5IGV2ZXJ5IGNw
dXBvb2wgdXNpbmcgYSBnaXZlbiBzY2hlZHVsZXIgaW5zdGVhZCBvZg0KPiBjb3BpZWQgcGVy
IGNwdXBvb2wuIHN0cnVjdCBzY2hlZHVsZXIgaXMgbGVmdCBob2xkaW5nIG9ubHkgd2hhdCBp
cw0KPiBhY3R1YWxseSBwZXItaW5zdGFuY2U6IGEgcG9pbnRlciB0byB0aGUgc2hhcmVkIHNj
aGVkX29wcywgcGx1cw0KPiBzY2hlZF9kYXRhIGFuZCBjcHVwb29sLiBzY2hlZHVsZXJfYWxs
b2MoKSBub3cgc3RvcmVzIGEgcG9pbnRlciB0bw0KPiB0aGUgbWF0Y2hpbmcgc2NoZWRfb3Bz
IGluc3RhbmNlIGluc3RlYWQgb2YgY29weWluZyBpdHMgZmllbGRzLCBhbmQNCj4gZXZlcnkg
YWNjZXNzb3IgaW4gcHJpdmF0ZS5oIGlzIHVwZGF0ZWQgZnJvbSBzLT5maWVsZCB0bw0KPiBz
LT5vcHMtPmZpZWxkIHRvIG1hdGNoLg0KPiANCj4gRXZlcnkgaW4tdHJlZSBzY2hlZHVsZXIg
YmFja2VuZCAoY3JlZGl0LCBjcmVkaXQyLCBydGRzLCBhcmluYzY1MywNCj4gbnVsbCkgaXMg
Y29udmVydGVkIGZyb20gc3RydWN0IHNjaGVkdWxlciB0byBzdHJ1Y3Qgc2NoZWRfb3BzLg0K
PiANCj4gQSBoYW5kZnVsIG9mIGNhbGwgc2l0ZXMgZWxzZXdoZXJlIHJlYWQgYSBzY2hlZHVs
ZXIncyBuYW1lLA0KPiBvcHRfbmFtZSBvciBzY2hlZF9pZCBkaXJlY3RseSBhbmQgYXJlIHVw
ZGF0ZWQgdG8gZ28gdGhyb3VnaA0KPiAtPm9wcyBhcyB3ZWxsLg0KPiANCj4gU2lnbmVkLW9m
Zi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KDQpSZXZp
ZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4N
Cg==
--------------CoTMydheAf7SCdPdQy3APn7A
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------CoTMydheAf7SCdPdQy3APn7A--

--------------k00BdssbclEkhrLi90HNJ0s9--

--------------MaBRrfc6bR2rpKhS7HyJH9hK
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpzNA4FAwAAAAAACgkQsN6d1ii/Ey9K
2gf/aXMssP8XDAyhOIOkEt4YoePTHfdH5BPzbI3OLIYHRDSw6T/ynN4iw40h6HNRy10Hs8hG0X2i
djTW6AqTlOXn3jtqAgWRa7DDy8abE06RJGt4euMXHR2z4eisXZqubSNmtpkSRf+AU05cqHqr/G2J
CTxNz0fSbBVz6wClkxvZkF695w436XE2VzTedtU2/b1RZKeawnpBD8j/7LKgM7UgjbTKbjtHhWWe
sxq/KCbElZVlu/cEBQp2mVf4RMz9BKVPcRvrcmIuiSqdkT6UmUzGRG0xgzLXlEKWwUQ0QCkqYgKW
MrIjVQF14z9erj5FZUwEv93aB6W2k5A39pntEMY+xA==
=OprQ
-----END PGP SIGNATURE-----

--------------MaBRrfc6bR2rpKhS7HyJH9hK--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:03:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:03:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383467.1626741 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbHV-0003W1-UQ; Wed, 05 Aug 2026 13:03:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383467.1626741; Wed, 05 Aug 2026 13:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbHV-0003Vu-Rq; Wed, 05 Aug 2026 13:03:37 +0000
Received: by outflank-mailman (input) for mailman id 1383467;
 Wed, 05 Aug 2026 13:03:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd205a597000e099@swg.vates.tech>)
 id 1wrbHU-0003Vk-RY
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:03:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrbHU-004exm-2c
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:03:36 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd205a597000e099@swg.vates.tech>)
 id 6a7334a4-2eae-0a2a0a5409dd-0a2a45038e3c-10
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:03:35 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd205a597000e099@swg.vates.tech>)
 id 6a7334a6-fae8-0a2a45030019-b9ff1c12b033-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:03:35 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fd205a597000e099.002 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 05 Aug 2026 13:03:33 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id 9855F83532;
 Wed,  5 Aug 2026 15:03:32 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=ZF6WP7UgFAc2NwspHi2jmBKrhGZX12HLI7355rllVlY=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=bKzS3fH8fcTgmTMH919eLmqA0iiG7PfxBrOy255DtkOcUW1uXnC6Ry+HCDzkrXJsah6t/IX0D
 rviASMjk5sX5nt9PKWVBm/6/utqWiBwCWXxYcaqQ+LJc8n7iNUpbH8igGhuiMzLLJK5wsGN6A9i
 bFhh8uc96KAVJcAVOBLaP4j/7D1P3KPERe7jZbt/PMTn52r/Xgnam2ZwEK9yh6ItIFAAubAqJLk
 Iz117q1924YM7GfVKV62NshJEvpP0V3JYP2zGd+G+8VqW8x7srEJrdKGbMQ6c5xjKHgwL0LprCk
 atSyPFQc9++P8qw0jPSG9HlCjkhC2x7IWytaJcDcggpA==
X-Zone-Loop: 1aa6608b4569365f6f40efd511b4be805d3142dc85b3
x-campaign-type: default
x-transaction-id: 87f2a609-f5fe-4793-b9ca-dd303678cb73
x-swg-uid: 01-5f0b3d50-284b-4c41-9694-8db580106f0a
X-Mailer: Sweego
Message-ID:
 <1785935013.8631fc262581453bbf619ec5b2062170.19fd205a597000e099@vates.tech>
x-swg-bid: 1785935013.8631fc262581453bbf619ec5b2062170.19fd205a597000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Wed, 5 Aug 2026 15:03:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RESEND PATCH 1/5] vtd: Ensure root entry is updated consistently
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319678.8631fc262581453bbf619ec5b2062170.19fad586037000e099@vates.tech>
 <a10f82fb-c4fa-493a-88cc-0b5d4c8db3ff@suse.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <a10f82fb-c4fa-493a-88cc-0b5d4c8db3ff@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------mBz3RI5Xho308WveCHZtQD4r"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1785935012731
X-purgate-ID: tlsNG-33051d/1785935015-6E0D14E9-F747BA69/0/0
X-purgate-type: clean
X-purgate-size: 7999

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------mBz3RI5Xho308WveCHZtQD4r
Content-Type: multipart/mixed; boundary="------------6W4b2IEA0qJW7DYa5oUm8d4W";
 protected-headers="v1"
From: Teddy Astie <teddy.astie@vates.tech>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
Message-ID: <60a9556b-4d2c-40ce-ada8-e20e7c28df43@vates.tech>
Subject: Re: [RESEND PATCH 1/5] vtd: Ensure root entry is updated consistently
References: <1785319236.8631fc262581453bbf619ec5b2062170.19fad51a4be000e099@vates.tech>
 <1785319678.8631fc262581453bbf619ec5b2062170.19fad586037000e099@vates.tech>
 <a10f82fb-c4fa-493a-88cc-0b5d4c8db3ff@suse.com>
In-Reply-To: <a10f82fb-c4fa-493a-88cc-0b5d4c8db3ff@suse.com>

--------------6W4b2IEA0qJW7DYa5oUm8d4W
Content-Type: multipart/mixed; boundary="------------BXis0eJJqRvCkaDxo25jEDMC"

--------------BXis0eJJqRvCkaDxo25jEDMC
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDQvMDgvMjAyNiDDoCAxODowMCwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g
MjkuMDcuMjAyNiAxMjowNSwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiAtLS0gYS94ZW4vZHJp
dmVycy9wYXNzdGhyb3VnaC92dGQvaW9tbXUuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMvcGFz
c3Rocm91Z2gvdnRkL2lvbW11LmMNCj4+IEBAIC0yODEsMTMgKzI4MSwxMyBAQCB2b2lkIGZy
ZWVfcGd0YWJsZV9tYWRkcih1NjQgbWFkZHIpDQo+PiAgIC8qIGNvbnRleHQgZW50cnkgaGFu
ZGxpbmcgKi8NCj4+ICAgc3RhdGljIHU2NCBidXNfdG9fY29udGV4dF9tYWRkcihzdHJ1Y3Qg
dnRkX2lvbW11ICppb21tdSwgdTggYnVzKQ0KPj4gICB7DQo+PiAtICAgIHN0cnVjdCByb290
X2VudHJ5ICpyb290LCAqcm9vdF9lbnRyaWVzOw0KPj4gKyAgICBzdHJ1Y3Qgcm9vdF9lbnRy
eSByb290LCAqcm9vdF9lbnRyaWVzOw0KPj4gICAgICAgdTY0IG1hZGRyOw0KPj4gICANCj4+
ICAgICAgIEFTU0VSVChzcGluX2lzX2xvY2tlZCgmaW9tbXUtPmxvY2spKTsNCj4+ICAgICAg
IHJvb3RfZW50cmllcyA9IChzdHJ1Y3Qgcm9vdF9lbnRyeSAqKW1hcF92dGRfZG9tYWluX3Bh
Z2UoaW9tbXUtPnJvb3RfbWFkZHIpOw0KPj4gLSAgICByb290ID0gJnJvb3RfZW50cmllc1ti
dXNdOw0KPj4gLSAgICBpZiAoICFyb290X3ByZXNlbnQoKnJvb3QpICkNCj4+ICsgICAgcm9v
dC52YWwgPSBBQ0NFU1NfT05DRShyb290X2VudHJpZXNbYnVzXS52YWwpOw0KPiANCj4gSSdt
IHByZXR0eSBjb25jZXJuZWQgYWJvdXQgdGhpczogWW91J3JlIHJlYWRpbmcgb25seSBoYWxm
IG9mIHRoZSBlbnRyeSBoZXJlLA0KPiBhbmQgeW91J3JlIHdyaXRpbmcgb25seSBoYWxmIG9m
IGl0IGZ1cnRoZXIgZG93bi4gVGhlIG90aGVyIGhhbGYgaXMgcmVzZXJ2ZWQNCj4gcmlnaHQg
bm93LCBidXQgdGhlcmUncyBub3QgZXZlbiBhIGNvbW1lbnQgYmVpbmcgYWRkZWQgdG8gdGhp
cyBlZmZlY3QuIChZZXQNCj4gZXZlbiB3aXRoIGEgY29tbWVudCwgSSdkIHN0aWxsIGJlIGNv
bmNlcm5lZCwganVzdCBub3QgYXMgbXVjaC4pDQo+IA0KDQpUaGUgaWRlYSBpcyB0byBtYXRj
aCB0aGUgb3JpZ2luYWwgbG9naWMgd2hpbGUgbWFraW5nIGl0IGFsd2F5cyBjb21waWxlIA0K
Y29ycmVjdGx5LiBBcyB3ZSBkb24ndCBpbnRlcmFjdCB3aXRoIHRoZSBvdGhlciBwYXJ0IG9m
IHRoZSByb290IGVudHJ5IA0KKHJlc2VydmVkLCBvciB1cHBlciBjb250ZXh0IHRhYmxlIHdp
dGggU2NhbGFibGUtTW9kZSkuDQoNCklkZWFsbHksIGl0IHNob3VsZCBiZSB3cml0dGVuIHVz
aW5nIGEgYml0ZmllbGQgc3RydWN0dXJlIGluc3RlYWQsIGJ1dCANCml0J3MgYSBtdWNoIGxh
cmdlciBjaGFuZ2UuDQoNCj4+IEBAIC0yOTUsMTEgKzI5NSwxMiBAQCBzdGF0aWMgdTY0IGJ1
c190b19jb250ZXh0X21hZGRyKHN0cnVjdCB2dGRfaW9tbXUgKmlvbW11LCB1OCBidXMpDQo+
PiAgICAgICAgICAgICAgIHVubWFwX3Z0ZF9kb21haW5fcGFnZShyb290X2VudHJpZXMpOw0K
Pj4gICAgICAgICAgICAgICByZXR1cm4gMDsNCj4+ICAgICAgICAgICB9DQo+PiAtICAgICAg
ICBzZXRfcm9vdF92YWx1ZSgqcm9vdCwgbWFkZHIpOw0KPj4gLSAgICAgICAgc2V0X3Jvb3Rf
cHJlc2VudCgqcm9vdCk7DQo+PiAtICAgICAgICBpb21tdV9zeW5jX2NhY2hlKHJvb3QsIHNp
emVvZihzdHJ1Y3Qgcm9vdF9lbnRyeSkpOw0KPj4gKyAgICAgICAgc2V0X3Jvb3RfdmFsdWUo
cm9vdCwgbWFkZHIpOw0KPj4gKyAgICAgICAgc2V0X3Jvb3RfcHJlc2VudChyb290KTsNCj4+
ICsgICAgICAgIEFDQ0VTU19PTkNFKHJvb3RfZW50cmllc1tidXNdLnZhbCkgPSByb290LnZh
bDsNCj4+ICsgICAgICAgIGlvbW11X3N5bmNfY2FjaGUoJnJvb3RfZW50cmllc1tidXNdLCBz
aXplb2Yoc3RydWN0IHJvb3RfZW50cnkpKTsNCj4gDQo+IHNpemVvZig8ZXhwcmVzc2lvbj4p
IHBsZWFzZSBpbiBmYXZvciBvZiBzaXplb2YoPHR5cGU+KSwgd2hlbmV2ZXIgcG9zc2libGUu
DQo+IA0KPj4gICAgICAgfQ0KPj4gLSAgICBtYWRkciA9ICh1NjQpIGdldF9jb250ZXh0X2Fk
ZHIoKnJvb3QpOw0KPj4gKyAgICBtYWRkciA9ICh1NjQpIGdldF9jb250ZXh0X2FkZHIocm9v
dCk7DQo+IA0KPiBXaGlsZSB0aGVyZSwgZHJvcCB0aGUgcG9pbnRsZXNzIGNhc3RzLCB0aHVz
IGdldHRpbmcgcmlkIG9mIHR3byBzdHlsZSBpc3N1ZXMNCj4gYXMgd2VsbD8NCj4gDQoNCkZp
eGVkIGxvY2FsbHkuDQoNCj4gSmFuDQo+IA0KDQpUZWRkeQ0K
--------------BXis0eJJqRvCkaDxo25jEDMC
Content-Type: application/pgp-keys; name="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Disposition: attachment; filename="OpenPGP_0x660FA9D102CBCFD0.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7L
TBVHV/XOZw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJ
T4ny+OGntnJntUoRKRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJA
WicutjkkUgd28Bh6HV9EIumHtCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO
8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaTVqMdqul07o72m3eA2mf+LMu9a04FX/d4
wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/EoucejoZ5SH49ksmVAmKOLkt
OaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+SPhHar7TPKjFz0G3D
PNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89MXfQXZ3q
t1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWj
moACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNz
uyOVCskwfUZPla6Zpd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp
0x0HfuhcYfAYPR46XHTvjaJEv99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuR
OxdK8G+YHccJY8PvWSq2K2yiae2KGiAv1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50
wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhPeP3IdpfWc8cyRLXF06Rk46YM
YCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcTUwgnYlFRk2FLq0Qe
KEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9Egr/Wmu3
MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEM
AKiQiZa3yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ
3DbVf+en3/FvdVZg2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTm
etSG5/52AjtmPFtlXAk0NmLvfJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0
s3109sJeXT5ImVdphFs9cvyZyBT9t1PbRowv58EgV0zE4hbAeVkULAbxFV5b/ExT
jjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKbYu6NCfiHfEyB3Xyg9hfdrRgj
MRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ovXoK4jm+Py0FiUGUa
A6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/eVtR2Q1w
ZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWj
moACGwwACgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiV
oUiHYN5QwhnbZnsaJDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764Qxy
X6rld2f2RcWkDuBHun55ZWXjby8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk
/dS0XTOQi2wVUb17sW/+ybCEokdVacZGzOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fu
oGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+lOWSvdNHgoEkWR0RXBPQjnGm
LKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/OffO485NOTKwGOxyWb0
06cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR8ULR9nX0
LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
x9fhaZEsniw8/bYgC3igkk5YJiOa
=3DlUIA
-----END PGP PUBLIC KEY BLOCK-----

--------------BXis0eJJqRvCkaDxo25jEDMC--

--------------6W4b2IEA0qJW7DYa5oUm8d4W--

--------------mBz3RI5Xho308WveCHZtQD4r
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmpzNKQFAwAAAAAACgkQZg+p0QLLz9Cg
ZAv8CejTcvdc2zq4YcBR1xmNNBKPx4ZBBe7qz5WPnbS+cOuKUWm5yxrbxwtWmItg9/L14Uho73Ws
tKxdYHYanu0UzZ8gcGwtQ4nkhA+hKnDGlAJNp51msQCtYcfwWjw99y2crXOj4D5yE+v7nBSHHiM3
6HB6+Iv2k150B9Xwcerzj6AkWpYqzXDr3BEt7LDs1k+1jxvdsd87cuPDEMIgfkcSyQz1mpkXEagK
g29wlRJ1CuXKtVzRGz6UydHevv3rQhDpCSS9/yf9us/B4JB1ondSTYOYEqjoJcOjy0lABKe61FT7
GM2D4TzkFqLe3JIUkdZ40/5GCsaBhN67EgCLhzu9Rewh0Y1U7WhInzZb2N4rdWrxLYvKRoQinu3u
fRT5FbkZbuTK2CpTGfynmnf5IwSeUEVSeCaXak3yVT2JftFQEdvAQ1sTyskHBQNak8P70Jizi6zj
JFME/W7nwPkf3m3z3v02CZJ+wWR/tEmTsYmBfEGHHPKyek5z6Absm8XjCacZ
=emah
-----END PGP SIGNATURE-----

--------------mBz3RI5Xho308WveCHZtQD4r--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:21:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:21:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383477.1626751 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbYd-0007IO-Ai; Wed, 05 Aug 2026 13:21:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383477.1626751; Wed, 05 Aug 2026 13:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbYd-0007IG-6U; Wed, 05 Aug 2026 13:21:19 +0000
Received: by outflank-mailman (input) for mailman id 1383477;
 Wed, 05 Aug 2026 13:21:18 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrbYc-0007IA-4C
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:21:18 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrbYc-006MEa-0M
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:21:17 +0000
Received: from mail-lj1-f176.google.com ([209.85.208.176])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrbYb-00Gga6-2U
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:21:17 +0000
Received: by mail-lj1-f176.google.com with SMTP id
 38308e7fff4ca-39ee96f8047so7161101fa.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:21:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=Aj2MapBS2f21v+Kw08Px43b1OXbhUlXb81lE0rDAxHA=; b=iOK0r0o1ehJVu/beuwHkNn58kD
	bT8NyB+fjAQ33jxQizlkZUWYUhjswdjwzqQbhG73nigXmLqKG6pJj5RZgixgH+LKewupJjOhp4yVa
	ybn3EgytdS0GNCw8k9Gn1O1SwZdjP7WhA6kcsVvcLQOyGlWAy/sSX0FAC3dANoadTuQw=;
X-Gm-Message-State: AOJu0Yy1beqhDc8GA/BcVXJJxGeu/8yAMOxyyL0bPweqySOslv1F7Yaj
	aGsrxr3Skm3tmW6nE3fwldwzOiEUQkPqG8ToVsOENOXRwkgMYPu9bn0r2Xqoq0C2QRW9+F7aqM5
	NA5uPlyyxTFI3t35NVll/E/PRHStmdEY=
X-Received: by 2002:a05:651c:a388:10b0:39b:1a03:bcb0 with SMTP id
 38308e7fff4ca-39fbb1e30c3mr7617981fa.10.1785936076704; Wed, 05 Aug 2026
 06:21:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com> <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com> <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
 <f0394e8a-1ac3-4aa9-bae2-af52380ff07a@suse.com>
In-Reply-To: <f0394e8a-1ac3-4aa9-bae2-af52380ff07a@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Wed, 5 Aug 2026 23:21:02 +1000
X-Gmail-Original-Message-ID: <CAFLBxZZk_jc=by6zA4qxc+WVDZ2SkQ2tgoFAfbVaEy8yY5y5DQ@mail.gmail.com>
X-Gm-Features: AUfX_mwH9odwJKdDNjCUl7vL4fcG7q9LlDV3AqgiQdkB-sGx8QqXswN89PeojV8
Message-ID: <CAFLBxZZk_jc=by6zA4qxc+WVDZ2SkQ2tgoFAfbVaEy8yY5y5DQ@mail.gmail.com>
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 5, 2026 at 10:41=E2=80=AFPM J=C3=BCrgen Gro=C3=9F <jgross@suse.=
com> wrote:
>
> On 05.08.26 14:15, George Dunlap wrote:
> > [Adding back in xen-devel, since this is relevant]
> >
> > On Wed, Aug 5, 2026 at 9:15=E2=80=AFPM J=C3=BCrgen Gro=C3=9F <jgross@su=
se.com
> > <mailto:jgross@suse.com>> wrote:
> >
> >     On 04.08.26 11:34, George Dunlap wrote:
> >      > On Tue, Aug 4, 2026 at 6:45=E2=80=AFPM J=C3=BCrgen Gro=C3=9F <jg=
ross@suse.com
> >     <mailto:jgross@suse.com>
> >      > <mailto:jgross@suse.com <mailto:jgross@suse.com>>> wrote:
> >      >
> >      >
> >      >     P.S.: George, would it be possible to turn off HTML mails wh=
en sending to
> >      >             xen-devel?
> >      >
> >      >
> >      > I see both a text/plain part and a text/html part in the mail I =
sent;
> >     isn't the
> >      > presence of a text/plain version sufficient?
> >      >
> >      > Obviously sending patches is a different matter; but for that I'=
ll be
> >     using git-
> >      > send-email.
> >
> >     This is a reply to your mail using Thunderbird (which I have config=
ured to use
> >     plain text format as the default, in order to comply with most mail=
ing lists
> >     I'm using).
> >
> >     I don't think Thunderbird is an exotic MUA, but please have a look =
how it
> >     rendered your HTML reply to my original mail. I can't see clearly w=
hich part
> >     was written by me originally and was cited by you in this mail.
> >
> >
> > Thanks, this is what I was looking for.
> >
> > Attached is the message Gmail sent.  As you can see, text/plain uses no=
rmal `>`
> > for quotes.
> >
> > That makes me think that the problem is in Thunderbird. It should eithe=
r take
> > the text/plan part, and reply to that as though it were the only part i=
t had
> > received; or it should take the HTML part, and convert the quotes to te=
xt
> > properly.  Replying in HTML and then rendering it with only space inden=
tations
> > seems like a bug.
> >
> > Thunderbird certainly isn't exotic, but last time I used it it was defi=
nitely
> > under-maintained.
> >
> > You're asking every person who sends an email to xen-devel to remember =
to take
> > an action before sending the mail (or to send *all* mail as text/plain,=
 even if
> > it's not to xen-devel), because your MUA isn't handling the standard pr=
operly.
>
> And you are asking every Thunderbird user to live with bad threading or t=
o
> use a different mail client.

Right, but Gmail is following the convention correctly, using nested >
in plain text and nested <blockquote> in html; Thunderbird (it would
appear) is not following the convention, mis-rendering HTML blockquote
into text as spaces instead of > (or instead of just using the plain
text to reply to in the first place, rather than re-rendering the HTML
into text badly).

> > Is that really reasonable?  Couldn't you tell Thunderbird to ignore htm=
l and
> > only render text/plain?
>
> I did look for a setting controlling that, but couldn't find any. I'm alr=
eady
> using to send plain text only. There seems to be no obvious control to pr=
efer
> text over html in alternative bodies.
>
> On Matrix you stated you are using the same configuration for sending mai=
ls to
> xen-devel since 2006. I'm not sure this is true, as most mails I've recei=
ved
> from you via xen-devel have been sent from your Citrix account, and those=
 were
> all text-only.

The last email I sent to the list in 2024 was dual format:

https://marc.info/?l=3Dxen-devel&m=3D171405222718671

Basically, if I was writing a new email, or replying to one that I was
cc'd on, I tended to use Apple Mail (and Thunderbird before that); but
if I was responding to an email that I wasn't cc'd on, I used Google.
Apple seems to have been configured to send text-only, while Gmail
generally sends dual-format unless I ask it not to for specific
messages.  (I've done so for this message, we'll see what it looks
like.)

 -George


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:28:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:28:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383487.1626760 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbfY-00084k-Tl; Wed, 05 Aug 2026 13:28:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383487.1626760; Wed, 05 Aug 2026 13:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbfY-00084d-Qv; Wed, 05 Aug 2026 13:28:28 +0000
Received: by outflank-mailman (input) for mailman id 1383487;
 Wed, 05 Aug 2026 13:28:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrbfY-00084X-5g
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:28:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrbfX-007Hib-Ib
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:28:27 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733a77-5cb7-0a2a0a5109dd-0a2a450393f0-16
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:28:27 +0200
Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733a7b-fae8-0a2a45030019-d155dd30d5b3-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:28:27 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-47c6e9a694bso633357f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:28:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47febfda58fsm9094648f8f.7.2026.08.05.06.28.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 06:28:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785936507; x=1786541307; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=uzXqEp59+17Vsqm1XWbN09ezWzAaeB9MVxhuAbnt2YA=;
        b=TEbMIZn6jPAZtas8+xHExBwQ5Z5p3rWzv9giujm9rgGccME/3G3v9dewsBQagGH3dv
         dInesvfjCqfSkPoImsScXKj9coRmgbjFh+wM4LsAQME6yuM6xLM2/P0RPcr1vW7c8nH7
         DYLhr4lytZUyTPIZ1wOTX9G2Qvc0/TnpgKJ8D/V9VWCMm8keydO61cgsk71bgig5Tkv9
         Vt3NP8nUFh82Bq6jtK79YT8YU53zk/w1ZATlnkBjvWThxcFo+zR09WHbDeHoMmH+Txvc
         1FVrkPRovWfqeingZeKG65C+K0FkPxIN7VTwtHNJ5TCu6i4dEJK+b/CKcPQE6rR/EHI+
         T22w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785936507; x=1786541307;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=uzXqEp59+17Vsqm1XWbN09ezWzAaeB9MVxhuAbnt2YA=;
        b=fMmzDs3gy66WPiyOIinFsZqJMybsbs+6YcWv2t+NuWATkZYhePcFl2GxsY9T/901sq
         lCFjoSDKoB50iyz9fbIz/5IrKTIKFQ0nVajyeG0Xs3JUDzLakzOer9j366oipaZfFeso
         5/2kgIGxdn6fwz0LjRupZjdPvfbk50EE1ZvBS4356mP9yM3Lxq85oNvZpf3vPfZjLsSp
         l+o6r9LH04IcLCSf9gs0dTqqwhs/iBc0NTXV27WARlj0XjvpvnbugwK7WWrT0ESFgBzr
         90OfEuSOJzJ0dcK3X772xvb+kGTwXYpZfR4wBagfC0srORDnCi97WtS2NscvVOa4elKE
         RQjA==
X-Gm-Message-State: AOJu0YxTEWZWWd6tCDF9elMc7NgS9++fHleNBQTnpUdRPVAuU1Qlh6jG
	LCR6aEtXEdvAdSWRfqgPgNt0oW09gd1oBmAY+JzmI1aJ3hujxeJ7XHuNGv0d0ZIj/g==
X-Gm-Gg: AR+sD1372Ff9F/5ncpMQflEoB2E145nYQOsRtbkvysbW0A1KycOuFUyTSFefUKHxhOj
	N+QMQ4UpJVtG+HPaEkzCLu0KfBgxE7R+KIMiIzUuflTsZy2fJ0mymqf8ZhmiQQo2mdhhthb4irg
	RfjGzLxerDDZs8qoFI3g5Px1LcBAEt64i00P4DXCkGgy1pgcx8DmnivGxxaDvGLD7vNs4lmYXyI
	fQfmT+lDjl9BsLHmeKpsUtuSHycibzGb2lPyQc3v53/HptX3eaH+IkjMltpaWa98nh+bI/LTBSM
	SiPxS2Gk+BDyJSDwY3bV5m7pT0B2WbFGh2Dyd6FLQmjPw6WmbycHY7fg+PFDLb5dFwGb00JTkK4
	wkKkIX+a1aoA/pQYLrire7TRB6FwzlpgliWoEKTUHbQYl72kZOd94XdAnXIPL1lLz39Z0l+ea6s
	mNlsTKg5VkbmzmaO+6N5Fu54gpdYDvD8PfUzds64obF/y2aw4DFhzIpUCZPv7GQ1075JS8x7OCA
	+Dqfy6686Fnckx1bQf6WZg4cMi6qKt25kq3o1wzTN2ZxF3d4CK7
X-Received: by 2002:a7b:ca4a:0:b0:499:4892:d022 with SMTP id 5b1f17b1804b1-4994e738af2mr70515625e9.8.1785936506898;
        Wed, 05 Aug 2026 06:28:26 -0700 (PDT)
Message-ID: <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
Date: Wed, 5 Aug 2026 15:28:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>, =?UTF-8?B?SsO8cmdlbiBHcm8=?=
 =?UTF-8?B?w58=?= <jgross@suse.com>
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
 <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
 <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1785936507-7428D4E9-1174FD0F/0/0
X-purgate-type: clean
X-purgate-size: 1078

On 05.08.2026 14:15, George Dunlap wrote:
> You're asking every person who sends an email to xen-devel to remember to
> take an action before sending the mail

You're by far not the first one to be asked this; you're the first one to
have an issue with being asked, beyond some companies' IT getting in the
way. (As to the latter point, I'm already combining my observations on
xen-devel@ with those elsewhere.)

> (or to send *all* mail as
> text/plain, even if it's not to xen-devel),

By default, that is. MUAs may or may not offer options to control this in
the course of composing a message.

> because your MUA isn't handling
> the standard properly.  Is that really reasonable?  Couldn't you tell
> Thunderbird to ignore html and only render text/plain?

Both questions go together: text/plain as the only content is (not just by
us) being asked for because that's the form known to work virtually
everywhere. Wanting your mails to be properly handled at all receiving
ends is - I think - not only reasonable, but also in your own interest?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:42:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:42:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383496.1626768 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbt2-0002Zb-5V; Wed, 05 Aug 2026 13:42:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383496.1626768; Wed, 05 Aug 2026 13:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbt2-0002ZU-2f; Wed, 05 Aug 2026 13:42:24 +0000
Received: by outflank-mailman (input) for mailman id 1383496;
 Wed, 05 Aug 2026 13:42:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrbt0-0002Z5-MB
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:42:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrbsz-0018PP-24
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:42:21 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733db3-2eae-0a2a0a5409dd-0a2a45098ae0-20
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:42:20 +0200
Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733dbc-be1a-0a2a45090019-d155da29b591-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:42:20 +0200
Received: by mail-ej1-f41.google.com with SMTP id
 a640c23a62f3a-c15f020a223so165436866b.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:42:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c203625459dsm120745466b.20.2026.08.05.06.42.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 06:42:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785937340; x=1786542140; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Eh+aB4Fu1hQ4npYew960LgpTX0/RSp2uKRxnVc27sDs=;
        b=ei4VW/MOgQb/SM1Nm59KIH13r6zdr+1GKp2SGu47YR91/EsKHtrobFaHaq4NkWghh1
         LZRSVFNwtaxdgHjsWa2fqTLvLGR3si7LwQXGKbnBhzKov87o4ac05vm9QWq2jjhH6iDZ
         PGbPJIj/+DU9YPusLyasz9k3+/45VgiJy3eX4BhMOpQcv7UrlFPH1kcqT3JMswuqtGP+
         rjArJU4bHcoMPrPCMJgse3Vw4aylMkGh5BIr0sjDWBAtyXUgRG52HTX8dVkrhnQQlJtN
         6RS3XMFcWMQuaVXfRzgHcnm5HkCF392J2kcefBSlCSe8gKerPlLThD1c/v4lq0CRe17d
         +OhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785937340; x=1786542140;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Eh+aB4Fu1hQ4npYew960LgpTX0/RSp2uKRxnVc27sDs=;
        b=hcOiOLtM8WEZnoHxIP4YO0A+5pQYenaTbCKXbP+icq0Wf7KnbWHe5TdaXdKG6meN8T
         yj4gx5yrnGh95qRjeGiNN3M1JurJFSaof/7srYO/yIWZwSa+5h0DzpanUPnBz1HDlMi1
         +NjcbDovxF4wfKOn/6/WZtnyiXV3RwKAX9HKm4/hv1yZ7ckjKjaMYsKGugOBfsj8/Ms0
         N+4DAvmouvXSMznvotUmebWvubf602rmYa7s3dAsDiCMuYkXk1CbO6kYk3EOW8A2GHbe
         FE3ADcB2tEWIC6H6QBiVZbxIKOLO3sv8OYfI6LalrbvThYu7tcmEe+Ha5hOAfBi+nvsM
         SaSg==
X-Forwarded-Encrypted: i=1; AHgh+Rre7Hu1LlL+lYMTOJloRA+7lLBE7PCNF4QG/mbxTKvTDLNkAfaWIxGgJ9MOyLmUn7bwf/iKlguwMkw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyj8WWrqmvkLjsYF3HkLe5YoxqvCGeFWbPeGDlYBsi9qghxfgJM
	ukZ6/8tm7Qy07+RNtpXRjQ4oEEEMo2J9l6coo/u4C8r+8A+4JE9GW7TudZeoNRTdmJQtdXHblv+
	poNK5EA==
X-Gm-Gg: AR+sD11/74hcg5RhKo+dfMuLpPezhKnA0ciKj0yTFrHdbJv2g3wjerL8C3NbwQgW9tL
	PkT78m7DsKK/5EkqUOEPaWayQORiNkyFBSedCHqbIqhEvuLmaHedRruZRGpCIVcQTqcFK6Qq+7J
	vfiPk737mAzQcOO6ee/jOwN/gLJYCPWB7nIGReDgXpR7at/iaSyiYKOVgIeY6EP6MJMBCNmGb40
	K4bn88Q9VZcl65E7KQeyJYkipLbWsmixSMgdCpHOC92aLD1IbqM+94jbpfydU5qHoALJI8nVoQ6
	zPQjtqInw354Sx+4vNpr2mtCPJFxq116Ly82iUwbEAou6+8HIWaKY5BgjOq0KWUefoN1OsX4vRV
	NuM4TiEUPDIGdC1hhGrA6l1g6mArDZ8Z9GJisqdXl+m5yrFOGq91/4RH3aSQM9lyfMeL4VRImTx
	msQZiQF/7F5aaWOiTR2RC925yhYiESNAllB70bk53OWpATF+ICLiOzY/xzDJGoCGCUPril89Pjf
	pnpG+v6PZmF8PIiMollKUbWaYhkvVIAqZ8LNVm8YN93zDanBeHN
X-Received: by 2002:a17:907:6d1b:b0:c16:242a:4722 with SMTP id a640c23a62f3a-c2039d1cae8mr291133066b.22.1785937340368;
        Wed, 05 Aug 2026 06:42:20 -0700 (PDT)
Message-ID: <e1e873d9-6dc0-4e08-90f5-e99ff42802a0@suse.com>
Date: Wed, 5 Aug 2026 15:42:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/5] x86/nmi: Watchdog fixes/improvement Part 1
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805124525.105457-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1785937340-BF2DC034-09D12C29/0/0
X-purgate-type: clean
X-purgate-size: 1662

On 05.08.2026 14:45, Andrew Cooper wrote:
> This is the start of a very long rabbit hole to address the
> mis-classification of some watchdog NMIs as non-watchdog NMIs.  For
> now, just some simple and hopefully non-controvertial changes.
> 
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2733861049
> 
> Andrew Cooper (5):
>   x86/nmi: Drop {reserve,release}_lapic_nmi()
>   x86/nmi: Drop K7_NMI_EVENT
>   x86/nmi: Misc style fixes
>   x86/nmi: Check MSR_MISC_ENABLE for all Intel platforms
>   x86/nmi: Don't configure EvtSel repeatedly
> 
>  xen/arch/x86/include/asm/apic.h |   2 -
>  xen/arch/x86/nmi.c              | 153 ++++++++++----------------------
>  2 files changed, 47 insertions(+), 108 deletions(-)

This series, once again, is putting me in a difficult position: Should I look
at it, or should I let it sit for two years or more, just like my earlier
fixes in this area [1], [2] are? (Of course, as always so far, I will look at
the patches, and I will likely also accept them going in ahead of mine. But I
cannot exclude that at some point I might actually stop doing so, seeing how
many of my patches are in that state. While at the same time none of yours
are, afaict, i.e. as per the track record that I keep of what still needs
responding to.)

Yes, you did respond to [1], but is not being comfortable with a change really
a reason to block it, when it _is_ an improvement, and when the alternative
hasn't materialized in all the time?

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2024-01/msg01365.html
[2] https://lists.xen.org/archives/html/xen-devel/2024-04/msg00194.html


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:49:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383505.1626778 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbzR-0003M7-Qr; Wed, 05 Aug 2026 13:49:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383505.1626778; Wed, 05 Aug 2026 13:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrbzR-0003Lz-NZ; Wed, 05 Aug 2026 13:49:01 +0000
Received: by outflank-mailman (input) for mailman id 1383505;
 Wed, 05 Aug 2026 13:48:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrbzP-0003Lt-QA
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:48:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrbzO-00CExk-L3
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:48:58 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733f47-2eae-0a2a0a5409dd-0a2a4509a2f6-8
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:48:58 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733f4a-be1a-0a2a45090019-d1558034c1c3-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:48:58 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4954aff6088so10631145e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:48:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994e98adc4sm46474035e9.2.2026.08.05.06.48.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 06:48:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785937738; x=1786542538; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=BojFhfKUlzIX2gMyZ1JO9FluxFCiamsA1rnpe2TZWSI=;
        b=V/3pHKj+PgK3pOH1IC5GpsLapJ5AP9kjPh9zh170sXT+1BD/2iD4uYdihF6bdvZP7v
         TqGzp8xg3AnSuC99FnHJB6GBJQa8ZTPTpeZbRDoOJ22f+K2Cw2nCuzqD3aGIIeherXcj
         mJKQlSK0vdLkmBuJPKoxs3j4URFluVEXiAWVBSdzGM4zo5wGx6gdURiey3YuOPgh+0Rb
         Ob874ACga8DZtNNQ7tiy4tlkRuxSb1wJtUfAeh1wj/ijAvMLFjHSuyzZ1TZWSQ7fkV+1
         WtE9tymrKSz6G4jgX/2birPQH1ATz8Tgkwg3KUWR0XizgX/AzXcTlSyxEWy/rXL/PCm/
         YPcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785937738; x=1786542538;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=BojFhfKUlzIX2gMyZ1JO9FluxFCiamsA1rnpe2TZWSI=;
        b=OtBm9nVTxa6urTXl8Be54GXbFJ+DYuBJ3NVX4UMoBHeLdT9FLOapXgiNrhss8/PoJO
         bU+1xUtlTxlv8vwmlsezIANNNqweT7axVf5vgp6AFeWcirfwkLdDwTQ/s7HGU7bhBBTD
         ONDEcfqOHHPzvWEUkqv2Z8LTZFVvWLLLVopdGCpaKL+JmfBs+9eRVGBzNP040pOl5IZw
         OUu+WDnY5hULmjhoYWuWRzk/eYrSZaTxLGFIGf1CBgDdLQ/aZvZJtuu/JgA3BRkmFScM
         XSbJF6MIJPebxe1dB7H9egNlkEWbcKJbAb1atKoOEE1X7j5DeBy+E6cd370bXgl4MGkr
         23bg==
X-Forwarded-Encrypted: i=1; AHgh+RpuudY4SGVEvRQwGcwoxrMvV5U4IJfgTtiL74E80MQTNaxjrGWvqP4nb8c4P/7wQpw4n9PMNsFQvdc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRW/GT3XUTkfD29KREQ45hhBtwbv9K7Fu2SOl/zN2wrU5Pd5nf
	oqtRE1Ed11S/lPvbC+7THgVvHQiHpgl4SBktKpvA53/D91DsI7axBOgbhzvfCsQGMQ==
X-Gm-Gg: AR+sD12xWGXbRWwFFVolSa2YZ0OGTMSctiCXxzQBIuSi81SMFBC1/tc5AxJMONwumL5
	xmP7+xb1oGPT3rXod5t6QbFZeCpapIf2cez4+YBstl4R40VedQftb4m8dp32xlGvnfeEpyKETUH
	4/Rbi3AcezFWnJikxKsJPsGSRgoWxX9XXmGLuJXNP2+B59ctcFf5k7rSMX+Ij91FMMVFKwJASCP
	sq1hY/pDDPbfXCU4skoOEPir86qIEQZZy0b9rhdsgNnwgcrUjP+GS92547pYTjXlPloE0MgOnMe
	c4ucPhgCSey77Va+T6aViq1uolhcu3km9W5ZSl2iOHk96FMmS6Lp67GPbrPM+g/AxfQpYIQC35/
	sZYXmoyuBMlGbKK1ZGH9teHiyE3F/uewhi4UcbxqtcatVLxaCRZrQQPfAQpSiauQDpKHmSPFcgt
	AAjAd3uK1aOCfc6oHEkD7wTpD4t+yfu62Q5zXhi95Iu26WwDSFMleKSbFXsEOpMJKBJhNN8+hdK
	p+HWjSfdTFWvTvEm/1KC4C4I5EG+JfsoBvKBZrJYcrvha5edEyt
X-Received: by 2002:a05:600c:1991:b0:493:e451:a9e1 with SMTP id 5b1f17b1804b1-4994e7448d9mr86234205e9.2.1785937737942;
        Wed, 05 Aug 2026 06:48:57 -0700 (PDT)
Message-ID: <0e2707dd-4ced-4c77-9060-23bf7344a3e2@suse.com>
Date: Wed, 5 Aug 2026 15:48:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/5] x86/nmi: Drop {reserve,release}_lapic_nmi()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805124525.105457-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1785937738-3BAD0034-5176101A/0/0
X-purgate-type: clean
X-purgate-size: 266

On 05.08.2026 14:45, Andrew Cooper wrote:
> With Oprofile support dropped, there are no more users of these.  Drop them.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:49:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:49:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383512.1626788 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrc0N-0003q5-4i; Wed, 05 Aug 2026 13:49:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383512.1626788; Wed, 05 Aug 2026 13:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrc0M-0003px-W6; Wed, 05 Aug 2026 13:49:58 +0000
Received: by outflank-mailman (input) for mailman id 1383512;
 Wed, 05 Aug 2026 13:49:58 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrc0M-0003pp-0W
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:49:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrc0L-000mCf-De
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:49:57 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733f76-5cb7-0a2a0a5109dd-0a2a4503dc02-42
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:49:57 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a733f85-fae8-0a2a45030019-d1558030ed8a-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:49:57 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49553515a8bso14793265e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:49:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994e041b4bsm92452265e9.12.2026.08.05.06.49.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 06:49:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785937797; x=1786542597; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=TvL2rOspMd85SySpoKUosK/j3GMuZB8mHcX/K39i1Kk=;
        b=MjjZ9+7m9htjO5pBkii5jLrAnSYf1JwGjv4L9vv61VnzT1t/vI3CcF4BU1GSfYhfUP
         Ko/Mn4664bFNLFlzfPyld042u+6zny8rmi4UgVrpZlGIDDoQ6ekBha4QuVBOgGMX2UBc
         EbgjwACcR1HjduwrY1KErOTD+r7rXzCRQDoSaXN+2xujZ4jcc03/9JyeUSQIlCLiTXCL
         MHc/3ntoJjP2qn98beAmZct9oTE+ggRe92raKgzr9wFPY0xOwVLiokIHI4bW1s1IoIO2
         pN1sMtgypdrj56CGWXEcJFnz1jZylF7u3Pu9bgxxhsHnDWfwbLOMtLB4tGqVNiKYrOs2
         X/PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785937797; x=1786542597;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=TvL2rOspMd85SySpoKUosK/j3GMuZB8mHcX/K39i1Kk=;
        b=s3amUSQF2wslXzQNLK2gJolJiIlZd1c/+sOS2efcguNy4W3Gn2VZYlPEluL8lHBkvD
         oP0biA68qU+7sXiOpTfQLDcZS8zL5MkKMbfwGfnY6pBTgm4gjujcJ+4Ib1p/j4wwXSHu
         sZYQ6xDlJaGTM9vqdGVSTiEuud/iW7dvA20O7zzl4msCu2vW/QmLB5Yg688kcXXBQT1c
         4DOnNsGloskc3QfwUS/39gRprDglV65XLYqmRoJTl6rtabzZ0s1OC6omrTOUtNpkVLeF
         jUQ/cOkzNG264/UTGTUrzGgYXHTNV/02BWesaPA/WcKMVdFEZ2R8kbmA5Q0H0X5/Jrdw
         MJTw==
X-Forwarded-Encrypted: i=1; AHgh+RqHkp5jttNb2Piwg37dJfYYt8VOKs7Qn6Of1aYukVOaSPXZQrgPffEEP01xULXK+PmqOC+ijflRxFU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJQVB7d11FTJIywxjwbcKRSj4mSIH70BnN125sAqExaFeJ0xVA
	nq46dcb62Mr8l89IAi+MwNaoKdn8HCgioVUxLYHCKN666HT6eXiBX6PQhEnCOuTuag==
X-Gm-Gg: AR+sD10MZ99UJxhWUURZ8hT5rnvSg+GDBAJSxonZT0zOG8ED79PMcjD+zeCMLcotKFq
	qBR7JLpuhjEK859/CkYBpfc8t2i6N3koAbfNrjoiLGlpwv2l74OFwTqEoTXP9T0PN65nPzz/M56
	CMsbpW+dLYfAPWHrlmTUe0vs+RjtpxztqlnP8M5w6LYnD4xFYRiR3Vd8R24Uv1VWSTlXIbwbepN
	d6NK9h8t8JiBzHLDJXkpP4shZIOvCED9ABvUkOTC+6/5DbOMC5BwNBdeUaHmf1P3h7D7tQV++7e
	sNXrB4VF+10I7yTIIxKig9NIvJzv8Zg93X+Qf0H/3B6luD2qzhaFzD49XpbESDnSi0PbT6z7Npu
	Tftm92B48jCsS72DjafHl4DRPaYGPr776+ZQ3/puCTx/Ft4EvQBL3EAHZ91m6QJIu4ofmzuG2EM
	R4D7zKlb6c7mLtZwhyCuQAsoEIcjWQgX8yeT4NqnxP8BObuSEolm7BEPZiP5XoVk1ft6ag4577T
	cvYLILDSZxPpIklNQHLTrYw+4cue1RPIXAD3/qkntVh9ZtYgJj+
X-Received: by 2002:a05:600c:8b35:b0:499:518d:ebd6 with SMTP id 5b1f17b1804b1-499518decc7mr29528305e9.17.1785937796784;
        Wed, 05 Aug 2026 06:49:56 -0700 (PDT)
Message-ID: <243ac905-6949-414d-823c-f6e183637bda@suse.com>
Date: Wed, 5 Aug 2026 15:49:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/5] x86/nmi: Drop K7_NMI_EVENT
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805124525.105457-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1785937797-758824E9-CC757DF9/0/0
X-purgate-type: clean
X-purgate-size: 516

On 05.08.2026 14:45, Andrew Cooper wrote:
> This name is misleading.
> 
> It's not possible to configure NMI or not from the event select register; that
> comes from the APIC configuration for performance events.
> 
> This name is "the thing we want to count for the NMI watchdog", but that's
> clearer to follow when it simply names the event.  Drop the indirection.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:53:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:53:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383519.1626796 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrc3J-0005Nc-G9; Wed, 05 Aug 2026 13:53:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383519.1626796; Wed, 05 Aug 2026 13:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrc3J-0005NV-DD; Wed, 05 Aug 2026 13:53:01 +0000
Received: by outflank-mailman (input) for mailman id 1383519;
 Wed, 05 Aug 2026 13:53:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrc3I-0005NO-HV
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:53:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrc3H-004o6f-Cu
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:52:59 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a734010-2eae-0a2a0a5409dd-0a2a45098992-40
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:52:59 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a73403b-be1a-0a2a45090019-d155802fb4e8-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:52:59 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-495635a85d2so8997825e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:52:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49949fc2da2sm202715925e9.3.2026.08.05.06.52.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 06:52:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785937979; x=1786542779; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=yHYw2W3qf29n9rzSQDKJYEq1mbdZ//fm9YT20zpV35c=;
        b=GwAIAcdDKLNoKqP1HyjYvHRObLiCL2VaLm8NEuxniOu9J0oo3LY5otJUjdk+WXNtwc
         9KvAOdsdM6G+Ud64MNqV26vw0Apb+pm5CxH9TVwTpytIeazvbpmYFB7uS/8W35+dvM8C
         yJHCK6doo1pexFjGL7EJkszvQWR8aeZOg0fuqRC/RmyU4nJ1Ora5EW4C8DnoFDLoeQpm
         JwEjBk77ojm0Oj+IZn+U1zO2KthOkyEbxqrwlBL/eAcxRgZmzyMg5i0fNxgZFLCZJkjs
         +0mzLBcJ3m4WvoAtO1tYcc7SB5n0bNGNqVFbZVND4GKJvmll1GVfsW+VH2DHMmx3wDaK
         CucA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785937979; x=1786542779;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=yHYw2W3qf29n9rzSQDKJYEq1mbdZ//fm9YT20zpV35c=;
        b=Ae9P19rUgt1LEurz7LanP9ouWeEcLULdDXOKP01UEp9mT9XSFWHi3zPaG+XCNPEPHo
         Zytsj5bmuk7Dn84fy/yM+B+jOPZH84qyYxNMIgAp97p5y67E9r7LYKs0xnQZYmuvgKEj
         NlqSf7UCT/qYNOD385GW+KLRXkUB690OpIRRdClVNK22r3KOEFqTePxAqGYtjx/gYjnf
         OjuFUirX25QXWy//r1lINtaCJbbG0nsn/3538BC+poG6svD3gR8896ONY3jclfN6C9j2
         eOLx+VK5EMhFwf0yYnI/2e7uM6lBfvaR9tJ6vTY6qjzWrGKHPkTSD3cT+sJoFHVciOES
         vtUg==
X-Forwarded-Encrypted: i=1; AHgh+RpKJS1Cd7ZjZBbF9KGlOFLRwJsf9YHADDvPZrXXI98j6BWC/ZwnahM7Mpg29YCufOOgWEXONf3xrYw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxUt/a5mlIOxDHJjpQB5xNzvV6LnJTo3eHn+zK32bNB6cO2chsE
	Ec5qL0y2L0bwK3F0GC+mNC+Oo2RwoK4s51S/CMMAVQ5h/AAqD5drhWmslb25ykRvVhZWkN0mvmi
	nQJuBZw==
X-Gm-Gg: AR+sD12O14tAEQm9n6aYRUqfbc8NnP9Z2/VAZoX2Zs6Jp8yq1kFqyMSxIQI0PJzKoC5
	BuKBLPiOBiLS6Rg6rGvCXFfn+xetVmm5wC3Z2dOTuo+4pEM0jramIK3iU6HmXGpysRcumzQoD5a
	DQl3x6bmDZ8KoOXvV4LP99WhYvplamK9+8PT6wxoZdXfMxUy8YO9jlM7xaJF03bGN5hfFdF5KCK
	dSe/qM/IFdnwVohHm9d9tFAcXefNk6S5pN1y/UJLRyB0qPTTh8TmbpGR/2bZLvAOq7Xz9kVREuE
	aS9D4bzgzEs25+lhOXvqo3ftpK1nksz6ayPT5d9vq2drEHJ9zb6jOJW1QIx6do6ORBtHECPFC6J
	MyufSguWrY77rgiirPuPcJ7E9mxCPD/Kz/80GrKGSnQRmqH9w8+I8ewmDfEjq8oIaF0myQGnCPN
	hIHiKKZq/Kix+IZnXtry836zUvGraNU83q5yqgSVzAie8NzlvFQB9Ph+tszHw5zkU5SWKbL01JU
	NMis2VrOCE3JKI8hOOE6fb5vIiEKVdnQ4rM5Bg0q/+RQcKRwHkK
X-Received: by 2002:a05:600c:1553:b0:495:5045:39e6 with SMTP id 5b1f17b1804b1-4994e7d3080mr65359155e9.17.1785937978687;
        Wed, 05 Aug 2026 06:52:58 -0700 (PDT)
Message-ID: <3e414c79-26cd-4fe4-a48e-73d80b02b4e2@suse.com>
Date: Wed, 5 Aug 2026 15:52:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/5] x86/nmi: Misc style fixes
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-4-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805124525.105457-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1785937979-3BED6034-15F8B057/0/0
X-purgate-type: clean
X-purgate-size: 1220

On 05.08.2026 14:45, Andrew Cooper wrote:
>  * Drop trailing whitespace
>  * Sort includes, dropping asm/mc146818rtc.h and asm/div64.h as unused
>  * Brace position, and types
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
albeit I would have suggested ...

> @@ -310,15 +308,18 @@ static void setup_p4_watchdog(void)
>      if ( boot_cpu_data.x86_num_siblings == 2 )
>          nmi_p4_cccr_val |= P4_CCCR_OVF_PMI1;
>  
> -    if (!(misc_enable & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL))
> +    if ( !(misc_enable & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL) )
>          clear_msr_range(0x3F1, 2);
>      /* MSR 0x3F0 seems to have a default value of 0xFC00, but current
>         docs doesn't fully define it, so leave it alone for now. */
> -    if (boot_cpu_data.model >= 0x3) {
> +    if ( boot_cpu_data.model >= 0x3 )
> +    {
>          /* MSR_P4_IQ_ESCR0/1 (0x3ba/0x3bb) removed */
>          clear_msr_range(0x3A0, 26);
>          clear_msr_range(0x3BC, 3);
> -    } else {
> +    }
> +    else
> +    {
>          clear_msr_range(0x3A0, 31);
>      }

... to instead drop the figure braces here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 13:55:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 13:55:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383529.1626805 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrc5g-0005yB-UH; Wed, 05 Aug 2026 13:55:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383529.1626805; Wed, 05 Aug 2026 13:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrc5g-0005y4-Rc; Wed, 05 Aug 2026 13:55:28 +0000
Received: by outflank-mailman (input) for mailman id 1383529;
 Wed, 05 Aug 2026 13:55:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <matthias.goergens@gmail.com>) id 1wrc5f-0005xy-TG
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 13:55:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrc5e-00FCef-Va
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:55:26 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <matthias.goergens@gmail.com>)
 id 6a7340c7-2eae-0a2a0a5409dd-0a2a4509e32c-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:55:26 +0200
Received: from [209.85.160.51] (helo=mail-oa1-f51.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <matthias.goergens@gmail.com>)
 id 6a7340cd-be1a-0a2a45090019-d155a033c9d9-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 15:55:26 +0200
Received: by mail-oa1-f51.google.com with SMTP id
 586e51a60fabf-44cedfaab6bso490880fac.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 06:55:26 -0700 (PDT)
Received: from spider.bream-herring.ts.net ([103.252.203.158])
 by smtp.gmail.com with ESMTPSA id
 586e51a60fabf-4599e5b7ec1sm2484235fac.12.2026.08.05.06.55.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 05 Aug 2026 06:55:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1785938125; x=1786542925; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=u4KVtir626gFVd35a54C+CtXHXFocgfKtNH4N3LL1vI=;
        b=JelmxEaNquBW0vHspdLQnmoyvaRtvZC5kJhF2vKJAh3lmmnqknhgRy0DfydtS+7lpw
         RLypQpMZ0P/NC21jZtiFS3aal+wq/Cs+9Yx3YRjLPiIDi22t0OGkUcrgKuAKPVews5NM
         oxkd96wLeMw5ZDDTwLfu6DTH/9dXthe/f8Fwl0F6G+3vJ0h9gp+S+wLAQT1+8ZQTD+xb
         wX2ckwP4EKVGbimyevz8/Cr8RrPLSy4HyzOIiR85BFGlMGJNjY4r5TMvER9pxArTX0na
         oo/r3OZpRm5LlO69QZYbJ0r5AmuchBCs/pHikRieSNQjAgK6I5AVwvOxCsVWJRAYrm+d
         EEYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785938125; x=1786542925;
        h=content-transfer-encoding:mime-version: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=u4KVtir626gFVd35a54C+CtXHXFocgfKtNH4N3LL1vI=;
        b=XyREivLMG9eqnoRmjbt5dHNUQXuJb/ixs1KnnvTmbaHTeTrAx+UTuRtXikFsJcULh1
         4pyqdCCF1Q2AmiZkU7/k3/w42XN0kLhFD/ORd7su8PXGO/W9V/WPFFHoMqt2klB86Wwi
         U44jUc4QZ9YNtYX6volaiLVYbEY2jEUxJgLsUkYGuZYImULeW+wSdrezay+mbjcgEAx3
         sSBnfxB3XQSCDhEMrEPf+6mmCwM0nTDSD+ZmHy8iUMhT6SuhsRWXk5gRkA6ewWuU4J5z
         vm8rfRO7Jjrw40h690Z29i/hgcfPXg0mRoC/If9KgTmbd+UK1tdaAICJhsVgqA/kdIKc
         0DdA==
X-Gm-Message-State: AOJu0Yy7XVuu4JkGgf32zIhMoQ2tgwGFrUubpKPSYxCPfKwD8QhWG1kF
	bzGrugBHUjkcx/sIVqKr8ocY+qcWJbzEKVK0EPOLo+nGjlDz+gDAT/Pabz4oa0Mb
X-Gm-Gg: AR+sD11NSSRAs/plcZ9++WU4ozN2j0rfHABBHWtzhO3E6+x0CqoZ/vtB6u6So+emLcD
	Ssl1P/p6bGT9UDvAiQ0/oQgtJl//xZe+Nr9IFZyyoFWIY1DafYRfnfCfL2GyPzY4GM9bzcECMjG
	CIGBUVoRC0tZqF0dISCbPg2G+8fqn65MzA3ekqYL+dCqFwA6WMMc+YmzHONWXJvJRhHRPSw/Rlg
	L+Vord9tTYVZsKAQfRoDgE0dsPK6gIWNweordpApAqo+wj4sKYnpUz5dPA16mxjAl2ygXQYsyd3
	9xj0jd6KuaZW1OSN7k6w9BGILPwxTYhxAyio+cPpwp1lo81kAdyRFUWEjo8L5tH9L+BINPtwBB5
	vNCCQHbsewo8QW8x5o+VMihHLncfoYh65YQNurrNRA6rXof9ZQQV75GrIyakthFFUn6g5fP1/9z
	AIBULk0fczEBmjgGAYtd0kj+8U1cFyLJW5UfPmnhlfEbILomznxMZ0um2j9CJmRwVUM5EY/vM10
	NiSSd/keUfDxYJ4d19yWOt/zCqF8Dx3i9SF1lq9wAF5q0dY4UDUWDp51ktknfZJ5lVhlbutgOXK
	1GCxfuAwiRLaIBybYjkbiTUIUwWPPJDaCiUJ0dJbs6U/KlecdWuf42LqgoG15YqF
X-Received: by 2002:a05:6871:7996:b0:448:aaaa:6b93 with SMTP id 586e51a60fabf-4599f1246bamr3533288fac.17.1785938125108;
        Wed, 05 Aug 2026 06:55:25 -0700 (PDT)
From: Matthias Goergens <matthias.goergens@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: anthony.perard@vates.tech,
	Matthias Goergens <matthias.goergens@gmail.com>
Subject: [PATCH] tools/xentop: reject invalid --delay and --iterations arguments
Date: Wed,  5 Aug 2026 21:55:21 +0800
Message-ID: <20260805135521.790750-1-matthias.goergens@gmail.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785938126-BE4DB034-15ED710E/0/0
X-purgate-type: clean
X-purgate-size: 4483

xentop parses -d/--delay and -i/--iterations with atoi(), so invalid
input is silently accepted with surprising results: a fractional delay
such as "-d 2.5" is truncated to 2; "-d abc" parses as 0, which in
batch mode turns the output loop into a busy loop; "-d -1" wraps to an
effective delay of about 136 years; and "-i 0" (or any unparsable
iterations count) decrements an unsigned counter from zero, running
for about 2^32 iterations.  atoi() also has undefined behaviour on
out-of-range input.

Parse both options with strtoull() instead, and reject anything that
is not a plain decimal integer in range: a sign, a fractional part,
trailing junk or overflow now produce an error and exit rather than a
silently wrong value.

Compatibility considerations: "--delay 0" remains accepted, since
updating as fast as possible is a plausible deliberate choice and
works today; "--iterations 0" is rejected, since running the loop
2^32 times cannot be what the caller meant.  The interactive 'D'
prompt already validates its input and is unchanged.  The only
previously useful invocation this breaks is a fractional delay, which
now fails loudly instead of silently rounding down - which is the
point of the change.

A patch documenting the --delay truncation was posted in 2010 but
never applied:
Link: https://lore.kernel.org/xen-devel/01ea26d2420e3562eb30.1292604768@chilopoda.uk.xensource.com/

Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
Tested by compiling with -Wall -Wextra (no new warnings) and by running
the parse helper, extracted verbatim from the patched file, against a
19-case input matrix covering both the accepted and the rejected inputs
listed above.  Not run against a live Xen host: the change is confined
to command line parsing, ahead of any hypervisor interaction.

Happy to add a CHANGELOG.md entry under "Changed" if that is wanted for
a tools CLI change of this size.

 docs/man/xentop.1.pod |  5 +++--
 tools/xentop/xentop.c | 27 +++++++++++++++++++++++++--
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/docs/man/xentop.1.pod b/docs/man/xentop.1.pod
index db64ceb..13f3f13 100644
--- a/docs/man/xentop.1.pod
+++ b/docs/man/xentop.1.pod
@@ -27,7 +27,7 @@ output version information and exit
 
 =item B<-d>, B<--delay>=I<SECONDS>
 
-seconds between updates (default 3)
+seconds between updates (default 3); must be a non-negative integer
 
 =item B<-n>, B<--networks>
 
@@ -55,7 +55,8 @@ output data in batch mode (to stdout)
 
 =item B<-i>, B<--iterations>=I<ITERATIONS>
 
-maximum number of iterations xentop should produce before ending
+maximum number of iterations xentop should produce before ending; must
+be a positive integer
 
 =item B<-z>, B<--dom0-first>
 
diff --git a/tools/xentop/xentop.c b/tools/xentop/xentop.c
index addb1c7..c7fb4ca 100644
--- a/tools/xentop/xentop.c
+++ b/tools/xentop/xentop.c
@@ -23,6 +23,7 @@
 
 #include <ctype.h>
 #include <errno.h>
+#include <limits.h>
 #include <math.h>
 #include <stdio.h>
 #include <stdlib.h>
@@ -1297,6 +1298,28 @@ static void signal_exit_handler(int sig)
 	signal_exit = 1;
 }
 
+/* Parse a numeric command line argument as a plain decimal integer no
+ * smaller than min_val.  Anything else - a sign, a fractional part,
+ * trailing junk, overflow - is fatal, rather than being silently
+ * accepted as a wrong value the way atoi() would.
+ */
+static unsigned int parse_uint_arg(const char *name, const char *arg,
+				   unsigned int min_val)
+{
+	unsigned long long val;
+	char *end;
+
+	errno = 0;
+	if (isdigit((unsigned char)arg[0])) {
+		val = strtoull(arg, &end, 10);
+		if (!errno && !*end && val >= min_val && val <= UINT_MAX)
+			return val;
+	}
+	fprintf(stderr, "xentop: invalid %s argument '%s': expected a %s decimal integer\n",
+		name, arg, min_val ? "positive" : "non-negative");
+	exit(1);
+}
+
 int main(int argc, char **argv)
 {
 	int opt, optind = 0;
@@ -1347,7 +1370,7 @@ int main(int argc, char **argv)
 			show_vcpus = 1;
 			break;
 		case 'd':
-			delay = atoi(optarg);
+			delay = parse_uint_arg("--delay", optarg, 0);
 			break;
 		case 'b':
 			batch = 1;
@@ -1356,7 +1379,7 @@ int main(int argc, char **argv)
 			show_pcpus = 1;
 			break;
 		case 'i':
-			iterations = atoi(optarg);
+			iterations = parse_uint_arg("--iterations", optarg, 1);
 			loop = 0;
 			break;
 		case 'f':
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:02:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:02:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383537.1626814 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcCB-0007rJ-Jn; Wed, 05 Aug 2026 14:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383537.1626814; Wed, 05 Aug 2026 14:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcCB-0007rC-Gh; Wed, 05 Aug 2026 14:02:11 +0000
Received: by outflank-mailman (input) for mailman id 1383537;
 Wed, 05 Aug 2026 14:02:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrcCA-0007r3-Ik
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:02:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrcC9-000nzY-Hq
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:02:09 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a734257-bab6-0a2a0a5309dd-0a2a45028bae-40
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:02:09 +0200
Received: from [209.85.208.45] (helo=mail-ed1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a734261-6ca4-0a2a45020019-d155d02dd484-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:02:09 +0200
Received: by mail-ed1-f45.google.com with SMTP id
 4fb4d7f45d1cf-6a144c8eea2so1184316a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:02:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47ff34da5c4sm888240f8f.5.2026.08.05.07.02.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 07:02:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785938529; x=1786543329; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=UWqyquH56toU5J0j8tnzTyZp4IECkHmUybItXJUtOtc=;
        b=M9sZVGnhRQC4dmFZQPUgxSbo+54VMdcdVLVEdb3p2z66gG9IhilIneQetjz+UDkru8
         cZGGVhHTYDczbq9x+BL1ztYurFNewo2i9OM5yy3NTzEMBWb/6Se8EvGZK7AIJPDaUNV1
         /DcMrf8rsxYVjr1torrfNOjGUvWxqEmPAI8JHaFOcOLvOJGq+ZOY04njgsYjNV1epFp4
         hGhF4fC+BdTDfCfr8Ch/QVehLJPJuDsKd/19W20/6siWfFYt5kxP2gwpZCrH/htWKe8Y
         RQleUAaupVKczsvOIVaIsWrGhhp/zR57YoQpSIVAj04X+M4l/7E8oYd9p1NLBtaRJ5rU
         ONoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785938529; x=1786543329;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=UWqyquH56toU5J0j8tnzTyZp4IECkHmUybItXJUtOtc=;
        b=tB2TAPtNO5htYWdXpisGdkzrsA4LDQCs6WvVuzvzx5SP8ibYnAkv1kgPMGfPz46dKF
         Hs028Irk5bfMNV+iTGWyQwWIQgFiF876vjMVvVPAZse3SIDs86Mr7a6mFEg16CTaSFlQ
         slXnA4k4oB9Y+vRVggzWysDONisLo6RklUer3GW+qjeiHFb4aioCICA8DbtQbI4lxPz7
         J9CvmQm9nN79xSv7IMd/1cMZCoGDHFd0NvHCV5SF9aXYj+0jd6m1kANu9t+dK5srZjM/
         2282jzNAPiRQ+G8Qkj061tpEC7TONEwz43koBT+fevGGDKVS8wOLeIXgHq00+MAshIf9
         VHRw==
X-Forwarded-Encrypted: i=1; AHgh+RrXSWL2uTgGbQTcEv4MYASRtCsbVeduYE6m/gN37cnmrWl75LGCDjiBA5c7cHHCEayVkuD/N5uXR/M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzeSUqxxkth2S/k2oOKpe/y1H3NAl3DmOpMg0/8ZlWBNKJH+jnD
	y6aHQMcsW4faF8Fxj7mNVVDHPzGt55ljXlw3Z/Lqfd5J1dL1Y40+/+jmqGO2HbboMg==
X-Gm-Gg: AR+sD138xgcpd5XqEmssjJfHf0nMMBh8oiuOtVFI6hOMCPKWx0kwFQVUfGw5Sal3Ip1
	0708zlL4dLAEAxunOCpFy/I9zP8rSbdRBzqiv0uDLeIwSgmGXl1BuawNOmyjTtqXfuXFG/X/9KQ
	GAH7eiQW2gC2dmKDY9ZFE16RWrwf6Boju7YW+q75CQdox4u7Ht1BKHucnJsksbCsX4vEEzB41T7
	ci2T9ZVhbKFbpzxh90ermlza0KXTuknM/6j2S12nHNvJPf5U2JL80q2SPr7MA6eEx7RjRWPcSqI
	fnRf3wa8wmsb2PHf4NAtPYkHSLx/pPtElEmb0sRWxTleDZ0N+Len/gvq3sgw6u17djdkKWLuz+8
	M3VW3N8i2C9d9ikEzpGfHEWa8otan+F34nRVK1brU2M+lES/OtiRANRUJouaMPOWmHM+h1FxAeT
	dUwk+1Wn4iz2nn7/g7EC4iCF29q2yKcVX9wQNo2F/Cb/Kb/gZVqwStffPh/UlfhcYijOYL7hTvS
	UVYIoQ4KkOXJM1BMKKgzoX1esnjV8pnavIK1tJAZsPJv628XoEYBsGepiAWI7g=
X-Received: by 2002:a17:907:961a:b0:c15:b67b:523e with SMTP id a640c23a62f3a-c2039e67177mr309632566b.19.1785938527924;
        Wed, 05 Aug 2026 07:02:07 -0700 (PDT)
Message-ID: <13568d23-b742-4a38-89d1-d49b761fd88c@suse.com>
Date: Wed, 5 Aug 2026 16:02:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/5] x86/nmi: Check MSR_MISC_ENABLE for all Intel
 platforms
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-5-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805124525.105457-5-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1785938529-305C52AC-BFDF0866/0/0
X-purgate-type: clean
X-purgate-size: 1296

On 05.08.2026 14:45, Andrew Cooper wrote:
> @@ -347,6 +343,14 @@ void setup_apic_nmi_watchdog(void)
>          break;
>  
>      case X86_VENDOR_INTEL:
> +        misc = rdmsr(MSR_IA32_MISC_ENABLE);
> +
> +        if ( !(misc & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
> +        {
> +            printk(XENLOG_WARNING "Intel Perfmon unavailable\n");
> +            goto disable;
> +        }

Please can we avoid "goto" when that's easily possible? You can use
"break" here instead, and ...

>          switch ( boot_cpu_data.family )
>          {
>          case 6:
> @@ -355,7 +359,7 @@ void setup_apic_nmi_watchdog(void)
>                                : CORE_EVENT_CPU_CLOCKS_NOT_HALTED);
>              break;
>          case 15:
> -            setup_p4_watchdog();
> +            setup_p4_watchdog(misc);
>              break;
>          }
>          break;
> @@ -363,6 +367,7 @@ void setup_apic_nmi_watchdog(void)
>  
>      if ( nmi_perfctr_msr == 0 )
>      {
> +    disable:
>          printk(XENLOG_WARNING "Failed to configure NMI watchdog\n");
>          nmi_watchdog = NMI_NONE;
>          return;

... we'll still end up here, as nmi_perfctr_msr won't be written.
Preferably with that change:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:03:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383544.1626823 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcDO-0008JH-Sx; Wed, 05 Aug 2026 14:03:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383544.1626823; Wed, 05 Aug 2026 14:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcDO-0008JA-QA; Wed, 05 Aug 2026 14:03:26 +0000
Received: by outflank-mailman (input) for mailman id 1383544;
 Wed, 05 Aug 2026 14:03:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrcDN-0008Iy-C6
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:03:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrcDM-00FEQe-LX
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:03:24 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a73429e-2eae-0a2a0a5409dd-0a2a4502b42e-40
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:03:24 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7342ac-6ca4-0a2a45020019-d155da36f0e5-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:03:24 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c1fbe461f59so164280366b.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:03:24 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2036422825sm125182766b.43.2026.08.05.07.03.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 07:03:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785938604; x=1786543404; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=ZELl0gN6/oR6iSAb1frKORNtawYItp/FeUnGx75S0aY=;
        b=BWbUxHQc0M+iRrkLJvu/Z70QAL+UhyXJ3dyL+OxDsdgIJJJ2Ji+1m4VbVYqnbiJQYN
         C+3RlKubmlUTqQw6ewtkEaAncPBkvIwTz2d0tGIjBzHT7etfZ0kiZ6zsoucmDAyRJClv
         rMU7VUTL9SR1+Pawj4q99ESxKF1jtizsZfpAWX3W2A8PX3BfaPiI8nF0J5apWPRiDvXW
         p3dqHP2U0Wvwftngdb4bzFmi2Zte5J9Xb4+8dpCCUaGPSjeys/9PAYUSSx0+RDJ/i7Gl
         OVYpm1oYuM2bXPIZU/Ms6IzgZ6UgbttT0uxTDn2VgvTqQA7a/N3EuxOZkjVDjt9srtsR
         BgJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785938604; x=1786543404;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ZELl0gN6/oR6iSAb1frKORNtawYItp/FeUnGx75S0aY=;
        b=NpF/AxW4Tj3/OIE8IolFuulzKjsgreFhiHlUHffwpgGK8n6rI7E0xc0vSqAJ56Rzj4
         c03kb5VutiHm2/eL0RdRCypvleO5q+XMf697ksNf0wXefu/HDmkZuN4RFLKRW+l9gEhc
         2a5BjX0DjyNV6j7ZYtqCNv6MMA/50plbU/dikDcZ9insRA9tN9+rWXovvbmBERBAGoON
         4AjzAuC7/HtaHiiphVOl3gKUUKN/Gb4MEVrh67htennLf975dVJtRMCRTbq2JALHNWr1
         s5zGt50+1Q/LClYcPn+4u323Xf1tmRkUQvMM365Bg1OIG7QjVMLzzh9cWVv/SKTjcChm
         4sSA==
X-Gm-Message-State: AOJu0YxHEh3JJ1d24iHlubzWzgPe5FDaLRYIEJHUaHSgNCkSQ7D+3muU
	RYWb3L3jMVdiho6AFmtH5LDu+TJ7TwvBfY8vbJ9Fze+5WGy3G/3TvZPDwPBWnpJzpgw=
X-Gm-Gg: AR+sD112Wwp0cDKq4py6JvYcB/BSCQHhsPypqCkSOmuoNG9679bEio6pzLgoVKvwW/1
	pdIaZSMi7zSgzdKbUDaXql6bIFNVxTk/pDNzGJoyJpQxqZrk1itR4pLMYQ84K1Xm3J4tTHDFckC
	ONmc7AEp5vOzp2OgwcgbQ/eBjPXqzi/Pqk0T3YuoENmRO1Lv2+/XWU59qr2Ht9pX12XTsoe+MtM
	7dbV/4cWP+qGjGOkirLaQZUqiUAIxFffsXn1Y+i3nMl/0RIXdS4HWLengeVAzF/UJ65fBdiiKzv
	X7201AvG9s8vNbkdUp2r3bsIhwPLtO02Mzu8Vq2m312oJzeLk2/zxCnfivbqRpYtaYzs9ezlKZA
	8U9K9BJIG3RYZt2B6D1v32sbqV4Y+hBrVWRujUCctnGlAfvhBDhlkLmd56pkJlWdthGb95dp28d
	HLomw+nh00NGCcqxqvkpaPD4qXEjmgUcXR9Oj0/H5bKWwYX6Qn15l9wCgncpRy3r25UQZPeIyyg
	GT4x2CiV5k9wwacBqCdVXUHLq94mDBTAWAm4czTdN2lNqO974YX6tZE1+XdTvv1Fhte611mmnmy
	VJn3YoPSHE80g70=
X-Received: by 2002:a17:907:988:b0:c12:74af:51f3 with SMTP id a640c23a62f3a-c2039d1fb0emr364693266b.6.1785938603408;
        Wed, 05 Aug 2026 07:03:23 -0700 (PDT)
Message-ID: <a9478ddd-247c-46f0-a18c-4bd3140df668@suse.com>
Date: Wed, 5 Aug 2026 16:03:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
To: Jan Beulich <jbeulich@suse.com>, George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
 <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
 <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
 <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Tz3rseFSLpEZJ5KWjMvgU50I"
X-purgate-ID: tlsNG-720697/1785938604-303C42AC-6804DC65/0/0
X-purgate-type: clean
X-purgate-size: 9164

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Tz3rseFSLpEZJ5KWjMvgU50I
Content-Type: multipart/mixed; boundary="------------qWmVQ8kIsdZu0Frl0vYDN0ec";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>, George Dunlap <gwd@xenproject.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Message-ID: <a9478ddd-247c-46f0-a18c-4bd3140df668@suse.com>
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com>
 <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com>
 <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
 <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
In-Reply-To: <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------qWmVQ8kIsdZu0Frl0vYDN0ec
Content-Type: multipart/mixed; boundary="------------f447bij2vWIY0iRtuYHiak0h"

--------------f447bij2vWIY0iRtuYHiak0h
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUuMDguMjYgMTU6MjgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNS4wOC4yMDI2
IDE0OjE1LCBHZW9yZ2UgRHVubGFwIHdyb3RlOg0KPj4gWW91J3JlIGFza2luZyBldmVyeSBw
ZXJzb24gd2hvIHNlbmRzIGFuIGVtYWlsIHRvIHhlbi1kZXZlbCB0byByZW1lbWJlciB0bw0K
Pj4gdGFrZSBhbiBhY3Rpb24gYmVmb3JlIHNlbmRpbmcgdGhlIG1haWwNCj4gDQo+IFlvdSdy
ZSBieSBmYXIgbm90IHRoZSBmaXJzdCBvbmUgdG8gYmUgYXNrZWQgdGhpczsgeW91J3JlIHRo
ZSBmaXJzdCBvbmUgdG8NCj4gaGF2ZSBhbiBpc3N1ZSB3aXRoIGJlaW5nIGFza2VkLCBiZXlv
bmQgc29tZSBjb21wYW5pZXMnIElUIGdldHRpbmcgaW4gdGhlDQo+IHdheS4NClRvIHB1dCBp
dCBkaWZmZXJlbnRseTogdGhlcmUgaXMgYSBzdGF0ZW1lbnQgb24gdGhlIFhlbiB3aWtpIGFz
a2luZyB0byBzZW5kDQpvbmx5IHRleHQgZW1haWxzIHRvIHhlbi1kZXZlbC4gSSdtIG5vdCB0
aGUgb25lIHRvIGFzayB0byByZWxheCB0aGF0IHJ1bGUuDQpJZiB5b3Ugd2FudCB0aGlzIHJ1
bGUgdG8gYmUgZHJvcHBlZCwgeW91IHByb2JhYmx5IHNob3VsZCByYWlzZSB0aGlzIHRvcGlj
DQpmb3IgZGlzY3Vzc2lvbi4NCg0KSU1ITyBpdCBpcyBmaW5lIHRvIHF1ZXN0aW9uIHN1Y2gg
Z3VpZGVsaW5lcywgYnV0IGp1c3Qgc2F5aW5nIHlvdSBkb24ndA0KYmVsaWV2ZSB0aGV5IG1h
a2Ugc2Vuc2UgYW5kIHRoZXJlZm9yIGlnbm9yaW5nIHRoZW0sIGVzcGVjaWFsbHkgYWZ0ZXIg
aGF2aW5nDQpiZWVuIGFza2VkIHRvIG9iZXkgdGhlbSwgaXMga2luZCBvZiBydWRlLg0KDQpU
aGlzIGlzIGp1c3QgbXkgb3BpbmlvbiBhbmQgSSBkb24ndCB3YW50IHRvIHdhc3RlIG15IHRp
bWUgZGlzY3Vzc2luZyB0aGlzDQphbnkgbG9uZ2VyLg0KDQoNCkp1ZXJnZW4NCg==
--------------f447bij2vWIY0iRtuYHiak0h
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------f447bij2vWIY0iRtuYHiak0h--

--------------qWmVQ8kIsdZu0Frl0vYDN0ec--

--------------Tz3rseFSLpEZJ5KWjMvgU50I
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmpzQqoFAwAAAAAACgkQsN6d1ii/Ey+O
2wf9ErHqLOST1ON4ayiBv8FDliAxo/xCj2g91Q/mMQTkMhPCxRpfdIOmB38aOtHBKEX3XhF6YN9G
c5sXuOeyhVXVETK6nCI/efSts4GczH7ny68TdGQOH7nkc18OrXPLLZF9rLVE6IJFa1QEh3BqlTqK
YnK4TfWcjNkk40/13YEDqWijc2+aBsE7R1qiYCBV7vT2DtWuHMcF8OMNMnre+1yX/h7lzYyvRxVn
uAy6QsNq+7dEjOwCA9DPXbWooOK+cMPPVdVqIdQ2LP298Dte+pDATlq+jw4wfj5SdrQk+vJ85Fph
a+rgxKvjQ7xlVQvE605v2k0lypyx2GEJTgoQ1jjqSw==
=SKAW
-----END PGP SIGNATURE-----

--------------Tz3rseFSLpEZJ5KWjMvgU50I--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:04:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:04:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383551.1626831 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcE2-0000KJ-8F; Wed, 05 Aug 2026 14:04:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383551.1626831; Wed, 05 Aug 2026 14:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcE2-0000Jw-5c; Wed, 05 Aug 2026 14:04:06 +0000
Received: by outflank-mailman (input) for mailman id 1383551;
 Wed, 05 Aug 2026 14:04:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wrcE1-0000Jm-T3
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:04:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrcE1-006NBO-2c
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:04:05 +0000
Received: from mail-lf1-f54.google.com ([209.85.167.54])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wrcE1-00H4TB-1a
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:04:05 +0000
Received: by mail-lf1-f54.google.com with SMTP id
 2adb3069b0e04-5b0117d49dcso1282438e87.3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:04:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Type:Cc:To:Subject:Message-ID:
	Date:From:In-Reply-To:References:MIME-Version;
	bh=3qLiuJFGpN11+MdjblulRfLKk+aAgO7+B5B9IdpRmA4=; b=0EAC0Wfaz2J7xsn6HBHrMcuE75
	fKeBxfxoCC1N7wHRpy2hcaqbCC2YKyg3Zr5wcvA7OAdAT9L4m1LgpLlsCwEvTw+ro2jtc1XnlThuF
	J08MAiHvWjQtLxZ6MSOmJ+S17XZp/IHEFp/LHYC/ycqjY7+sp5aOiKQ9xKTRWHGSPy14=;
X-Gm-Message-State: AOJu0YypqaiMLIOlE2MQ6NudXoVyacOl/DCRSqj7VBzuwkejwcPkSaPU
	4Q+0wsOAtFHEPaVmQ5/Brl2DCPcUi/h6/oviPQQk/o0NM//TgQpp+lZHX++J5tOwPZ+CF279EO9
	aFiMX3G4cXG5uWBbgI9NRJggRGpsgr8k=
X-Received: by 2002:a05:6512:1327:b0:5ae:bc4f:d631 with SMTP id
 2adb3069b0e04-5b2f4cd42dbmr1077274e87.44.1785938644416; Wed, 05 Aug 2026
 07:04:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com> <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com> <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
 <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
In-Reply-To: <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Thu, 6 Aug 2026 00:03:52 +1000
X-Gmail-Original-Message-ID: <CAFLBxZZZP+NvCsvszNAmoTSSD2tZqe=Z0UVoo-sY+DyOrVu2PQ@mail.gmail.com>
X-Gm-Features: AUfX_mzd6dBticIODYK7r_o4tlKgLtoPNRNzITXiNfwT22XduMBsW7Lo1OjTvAk
Message-ID: <CAFLBxZZZP+NvCsvszNAmoTSSD2tZqe=Z0UVoo-sY+DyOrVu2PQ@mail.gmail.com>
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Content-Type: multipart/alternative; boundary="0000000000007dc03f06584d3e53"

--0000000000007dc03f06584d3e53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 5, 2026 at 11:28=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wro=
te:

> On 05.08.2026 14:15, George Dunlap wrote:
> > You're asking every person who sends an email to xen-devel to remember =
to
> > take an action before sending the mail
>
> You're by far not the first one to be asked this; you're the first one to
> have an issue with being asked, beyond some companies' IT getting in the
> way. (As to the latter point, I'm already combining my observations on
> xen-devel@ with those elsewhere.)
>

And indeed, if I were sending to a community I was new to, I would just
suck it up.  I'm pushing back for two reasons: first, it wasn't an issue
for the previous 18 years, so I'm trying to figure out why it's an issue
now; secondly, whether it's a big barrier or not, it adds a barrier, which
seems to me unnecessary.

I do feel a bit weird starting an argument about this on my second or third
public post coming back.  But, the arguments put forth to support the
"text/plain *only*" position don't seem to me (at the moment) to be
justified; and in this community I'm in a position to push back in a way a
newbie would not be.


> > because your MUA isn't handling
> > the standard properly.  Is that really reasonable?  Couldn't you tell
> > Thunderbird to ignore html and only render text/plain?
>
> Both questions go together: text/plain as the only content is (not just b=
y
> us) being asked for because that's the form known to work virtually
> everywhere. Wanting your mails to be properly handled at all receiving
> ends is - I think - not only reasonable, but also in your own interest?
>

As I said in a sibling thread, the fact stands that (as far as I can tell)
Gmail is following long-established mail conventions, and Thunderbird is
not.  Juergen can read my mail just fine.  *His* MUA generates somewhat
mangled responses, specifically because *it* is using HTML rather than
text/plain; I don't see why that should be my issue.

 -George

--0000000000007dc03f06584d3e53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 5, =
2026 at 11:28=E2=80=AFPM Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.co=
m">jbeulich@suse.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">On 05.08.2026 14:15, George Dunlap wrote:<br>
&gt; You&#39;re asking every person who sends an email to xen-devel to reme=
mber to<br>
&gt; take an action before sending the mail<br>
<br>
You&#39;re by far not the first one to be asked this; you&#39;re the first =
one to<br>
have an issue with being asked, beyond some companies&#39; IT getting in th=
e<br>
way. (As to the latter point, I&#39;m already combining my observations on<=
br>
xen-devel@ with those elsewhere.)<br></blockquote><div><br></div><div>And i=
ndeed, if I were sending to a community I was new to, I would just suck it =
up.=C2=A0 I&#39;m pushing back for two reasons: first, it wasn&#39;t an iss=
ue for the previous 18 years, so I&#39;m trying to figure out why it&#39;s =
an issue now; secondly, whether it&#39;s a big barrier or not, it adds a ba=
rrier, which seems to me unnecessary.</div><div><br></div><div>I do feel a =
bit weird starting an argument about this on my second or third public post=
 coming back.=C2=A0 But, the arguments put forth to support the &quot;text/=
plain *only*&quot; position don&#39;t seem to me (at the moment) to be just=
ified; and in this community I&#39;m in a position to push back in a way a =
newbie would not be.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">&gt; because your MUA isn&#39;t handling<br>
&gt; the standard properly.=C2=A0 Is that really reasonable?=C2=A0 Couldn&#=
39;t you tell<br>
&gt; Thunderbird to ignore html and only render text/plain?<br>
<br>
Both questions go together: text/plain as the only content is (not just by<=
br>
us) being asked for because that&#39;s the form known to work virtually<br>
everywhere. Wanting your mails to be properly handled at all receiving<br>
ends is - I think - not only reasonable, but also in your own interest?<br>=
</blockquote><div><br></div><div>As I said in a sibling thread, the fact st=
ands that (as far as I can tell) Gmail is following long-established mail c=
onventions, and Thunderbird is not.=C2=A0 Juergen can read my mail just fin=
e.=C2=A0 *His* MUA generates somewhat mangled responses, specifically becau=
se *it* is using HTML rather than text/plain; I don&#39;t see why that shou=
ld be my issue.</div><div><br></div><div>=C2=A0-George</div></div></div>

--0000000000007dc03f06584d3e53--


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:21:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:21:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383569.1626842 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcUO-0003ms-Mq; Wed, 05 Aug 2026 14:21:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383569.1626842; Wed, 05 Aug 2026 14:21:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcUO-0003ml-IY; Wed, 05 Aug 2026 14:21:00 +0000
Received: by outflank-mailman (input) for mailman id 1383569;
 Wed, 05 Aug 2026 14:20:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrcUN-0003md-J4
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:20:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrcUM-004Azg-W2
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:20:59 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7346c1-e002-0a2a0a5209dd-0a2a4506d2d2-42
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:20:58 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7346ca-195a-0a2a45060019-d155dd2fe8e4-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:20:58 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47f6609c657so532307f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:20:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47fec23e5efsm9339266f8f.27.2026.08.05.07.20.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 07:20:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785939658; x=1786544458; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ztlQGn8DvKCCDgciuvr4MBrBLBlPYBDCgdZ1t25z4Cw=;
        b=ayVM+D2Kxo4T09BKLOTN2LqLnpH42WWy7+KKpunvyIvUBVWs5trAZBZiHJ71LtcRvZ
         JoDxuDJAWMG3RvjhE3dvdf5+a7WQamMS61K7qOOg3fzSM5nt4h9BAPffQhV4CV7ELY2M
         ek/lqSFbz7jdolg4MISIs7sJlVGEuVc2XA4kSJHrZhPuN15mPQVRslKIn9ntBu1htGr2
         BEr+0rrCIiORbigntd3FzGr9nykPRDDvdGmyusCl49vYXp7j5ry1U81bofubEwl5lBMx
         y9grbC/+NUf/bbI8aZg+pBCp4x/Qgff34W0ZKn82sv8VXNiZI1H+8FmNcB9NSH5QQlmh
         VjEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785939658; x=1786544458;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ztlQGn8DvKCCDgciuvr4MBrBLBlPYBDCgdZ1t25z4Cw=;
        b=MR+R40dwlBhsP2qqSoc8uoLIpKJxUPg42PQ64w3r9r5G19bBMGhcIlOKlmuXaceDpW
         eXNAEgQZidQ5V7h7KJXuWJ58qoKNSsog/Ejrnkf8VFAQXahxOY7v4tTFIvILT5hfo6RH
         KRNZpI9aCass5M/4crcNOw1M7Ro9I81R9pB72CWDgGR6RUHcid7eIGPHKBkRXPku+uUG
         Kw3Ose2e/6MTBHmfQOcOcqiVcmnOr6/3vecrqTqlPP8BeNmINspq/4PvdceW/j7Y29vF
         aDNbpx7g6ObVRaBmeTSc1vjnk1jiiak4e9dSIOTz+NBgHwW3YKwWq+2aGnpRWFoBFK/F
         MZHQ==
X-Forwarded-Encrypted: i=1; AHgh+RqBp1P4A3S3svoAOgYdRYc1DQ8bFql9OuO7h9lW5o26hJSOcfI4HceRUd1nspFLC885QPyN1EAxmPs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyuP9LqLhl5+qCpEN6B0tu5MkA09ivr4UNRCP2PHTfLS2JqRYrb
	RpkAuTrs/Y0QwJ0Er7dBFT3x9ApjW4dNJuSRgrrUo9/Ora1Ydn7OQVdBSf3IX1OE7w==
X-Gm-Gg: AR+sD11BMzrcv2krFbha6zdtjOMrC9G1K3yK88cfAGmYStrXQigcHXt1+kAmNkAEs/T
	GJeWUIeAiuAmA9GMbHTeSpB5wM7sCimKOqFNn54RveQ/7afYF3/HGnXAPi0BkJsIwpYjimN3YJq
	zFthOVJsm0MABH4FThZLVr54/sN/SxxIV4eJqu2qqWnKO/0h8LKGeFdeWMR4yIHtxMnfahdQBuE
	rxG5SNj2vNFMf0lMTpFlai8Frfcy+ruWLsIBdtF2UztTVG+tJ3BBpDpj99Z3r6Pp2ychdMdP7x7
	9eHNIwoK7dMIX6g7jYjz8M2INura6eVBu5bxd7Ys+icIYU2QficQkVF0FdbERwBTTW2/E3rAzt/
	X2BmmCSlMBRpM0/mC4PL6Z3YVztvLttc1Z8WfM72UqbAv8v/wu1jkzPi67rj+NaAQX37cii+nxt
	13fxfD8TRABy8Mx747Xz+MVoFktHjQ9NXURAmc8kleku2sm8dXQ5NduPT2d6LXy3miOLUUq+W9S
	ZKr+recQgFQRv5heoy2M5ZGAkEkNS8avaDR6GGAKRVDjkLdXSUs
X-Received: by 2002:a05:6000:41d0:b0:45e:73eb:5119 with SMTP id ffacd0b85a97d-47fec62ea74mr13286445f8f.22.1785939658244;
        Wed, 05 Aug 2026 07:20:58 -0700 (PDT)
Message-ID: <d76fa0a2-1a53-4ee4-b077-d51715dba339@suse.com>
Date: Wed, 5 Aug 2026 16:20:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] x86/nmi: Don't configure EvtSel repeatedly
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-6-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260805124525.105457-6-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1785939658-FCA0477B-568236C7/0/0
X-purgate-type: clean
X-purgate-size: 1224

On 05.08.2026 14:45, Andrew Cooper wrote:
> In both setup_{k7,p6}_watchdog(), EvtSel0 is first zeroed, then written with
> everything but the enable bit, then written with the enable bit.
> 
> setup_p4_watchdog() is slightly more complicated, owing to what
> appears to be a bug introduced by commit 2a2bd8de16b6 ("Clean up NMI
> watchdog handler."), which causes a second bit to be temporarily
> different too.
> 
> The middle of the three writes is useless in all cases.  Drop it.

Spotting the 1st write in setup_p4_watchdog() wasn't quite as easy, as
MSR_P4_BPU_CCCR0 (as passed to clear_msr_range()) has nothing to do with
MSR_P4_IQ_CCCR0. Using unrelated MSR names there is as unhelpful as using
raw hex numbers.

> While doing this, rename the 'counter' parameter for
> setup_p6_watchdog().  It is the event which is passed in; the counter
> is always counter 0.
> 
> No functional change.

These sequences of writes almost look as if they were trying to cover for
errata. Are you sufficiently sure there are none anywhere, for this to
truly be no functional change? If so, ...

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:24:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:24:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383578.1626850 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcXR-0004Kg-2h; Wed, 05 Aug 2026 14:24:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383578.1626850; Wed, 05 Aug 2026 14:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrcXQ-0004KZ-Va; Wed, 05 Aug 2026 14:24:08 +0000
Received: by outflank-mailman (input) for mailman id 1383578;
 Wed, 05 Aug 2026 14:24:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrcXP-0004KR-Cm
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:24:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrcXO-00CYWN-PY
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:24:06 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a734775-5cb7-0a2a0a5109dd-0a2a4507e9dc-46
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:24:06 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a734786-b4ea-0a2a45070019-d1558031b5bf-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:24:06 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49557167508so9697765e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 07:24:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4994a100e14sm171303405e9.14.2026.08.05.07.24.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 07:24:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785939846; x=1786544646; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=vbRVw62g8SNCcV8AekHEQaKPLBlLD87oFEQk+G4hP3c=;
        b=NGODxzB3nbbe9lBKUiIF1N+KcS4w/U8muYTDKADsjlAiQpRBVU735XU1G+QVUm+pLT
         OxIhbeC71kQNYAQTPQrfwX64Ml3W4z7o0ftSaMvo3DnyILPVqSfzl7T2L8cb9mWIyUDJ
         5mtg5qTUS/FuqNdY1D+P53A35xqr8VFo+NYwvswWrNoc2wWZ2K4/W+ugNmp4FBUmw2xS
         4V8qf/7TcsWg0I9lHCsDzGqWB2oEUvbDH7Q49yIkg/4vjwm07d/F0fIeLNYBdX5anlQp
         Rt5Q1lxDKXoFAJkHPk9CtnYTSgH5JMOwps6AlNkruI9PbIlQg14R033Jn1HZplXpXoPE
         UfDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785939846; x=1786544646;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=vbRVw62g8SNCcV8AekHEQaKPLBlLD87oFEQk+G4hP3c=;
        b=YQ2Uwd4cS0W74zUX641JxTk3AyAiGHFyLony0Q8GV7nc6ykFT0NgeAWx2BJTRa/tAY
         6XXVI7DxqiZUWRk6bd4dbjzWxcPYNKqIroy7KSrklnZdEugP2wkEJPV+4JVGuMaIAen/
         +uGYCswvSE8SDYnV8GEwnJ33iCvcmrzi/IFo0+8xNK4VfY0+msO79BGtbB98EDR2ahvD
         bEXLxx2QDP6ZFvMkXR06bV9Y11c8u/ljUI4hlbbRFNmgwhgAd8xuLr4UU9jFX68HI1VP
         xgPJ9T2rL+LZDqdMZzB36mrv8kl/4RFRwPLCf0wpKSNLMFQUCMJZrmJCQHXjv6gBHgGS
         CmrQ==
X-Forwarded-Encrypted: i=1; AHgh+RqRwoF8DcezR/YLeiI0ubYzn8B0Fp1iNdWoS2+45RPBrjPsDYgqCH2fwu+pSp8vCtGYORyPH32R1H8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyNYOxhSHnk4bdUbiquEE1m3PUbAt7Ie6TWJ8IAmqH5S6j09BYd
	mJvqeW7yGbqf5O5iIppfF/cjK+InUejuh/SRpFmaKde+9OFFpjl0lHT6yowtahJ4lg==
X-Gm-Gg: AR+sD12cFfbd/TVGaGaQ6qDldMrThNDhOM0NgSvNqSM4HyPGMRnmi3BMlSaT2QOO+v2
	MOCTMhp32SWk/gCq4MjNZW1F6bWfMvsUbRNnnnvcwy0pCn9K1uVnXNKw8zC3hfytwllg2nG8xUE
	XwCoVt/yuPh3FLEq0yoxn9eood5pbrtmrke6cX0qK69v3s5CczKzCTpbcJeJwpY8MWBYZgELvSR
	foUIN52L9Dn7Qmmxz2eDMI/1B00vM6wbR2MzJtQuU3l2pmsM+TNAdC1DWAWPOoy/voot/vkkirN
	lKJ4DilMwbdYIsvmuYWPukFFgSujNxvLj5gAaLBPwVd0sCvDsM2XKpNLZIwEMaXIFsUDXRCG55d
	2tjpstn4BhL9SToITBxEJ3PNcd07iCVD6KqufatHZ3GGEZfYcJqUg4twZxZYLfVos0qeedN1XMN
	nCIELQ74LZ3ozgFFytrnvTfnQ41HlthplGOUPNCYgClS04XXNTgjqL6Wl8VXflF77pbqrYtGUOT
	GzKtwz6aakBhGZDhShXtQRHLxTElb08DG7ImWj9S+sI9sXXnCRt
X-Received: by 2002:a05:600c:1d23:b0:499:51b8:d649 with SMTP id 5b1f17b1804b1-49951b8d652mr25870305e9.3.1785939845902;
        Wed, 05 Aug 2026 07:24:05 -0700 (PDT)
Message-ID: <5a444465-1d4b-4618-825e-1be612408009@suse.com>
Date: Wed, 5 Aug 2026 16:24:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 4/4] xen/acpi: Parse PPTT to initialize CPU topology
To: Hirokazu Takahashi <taka@valinux.co.jp>
Cc: Mykyta_Poturai@epam.com, Stefano Stabellini <sstabellini@kernel.org>,
 Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260728050642.411240-1-taka@valinux.co.jp>
 <20260728050642.411240-5-taka@valinux.co.jp>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260728050642.411240-5-taka@valinux.co.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1785939846-A7CD7AE4-C3F38FC4/0/0
X-purgate-type: clean
X-purgate-size: 454

On 28.07.2026 07:06, Hirokazu Takahashi wrote:
> Parse the ACPI PPTT (Processor Properties Topology Table) to
> initialize the CPU topology.
> 
> For ACPI 6.3 and later, the ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD flag
> is checked to determine the presence of threading. For ACPI 6.2 and
> earlier, CPUs are assumed not to support threading.
> 
> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383600.1626864 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3A-0000jb-Ls; Wed, 05 Aug 2026 14:56:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383600.1626864; Wed, 05 Aug 2026 14:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3A-0000j6-Hh; Wed, 05 Aug 2026 14:56:56 +0000
Received: by outflank-mailman (input) for mailman id 1383600;
 Wed, 05 Aug 2026 14:56:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd39-0000gL-3c
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:56:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd38-00Cdp1-GR
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:56:54 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f2b-e002-0a2a0a5209dd-0a2a4501c102-14
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:54 +0200
Received: from [202.12.124.150] (helo=fout-b7-smtp.messagingengine.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f35-5984-0a2a45010019-ca0c7c969577-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:54 +0200
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfout.stl.internal (Postfix) with ESMTP id 0A1B61D00141;
 Wed,  5 Aug 2026 10:56:53 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Wed, 05 Aug 2026 10:56:53 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:56:51 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941812; x=1786028212; bh=ZR1d1bGRuW
	7PkpYXNT/MSUaHwUt8D8/XKZCozOxnmOo=; b=vRq70RxyIF7I4jufZwP/UbDIMa
	ae5kBZB/LeAG7dK2DBrpmeSZOsg7CZ1GXg8BG44IxbEjq0eUPc/+jjXOomdtw5CJ
	HuiMn+jxtn0GOFJt1mxf+oMZ+dKJfxr97mgmDHN4VKH9OSOjJBohJAuTWnqJSO/e
	WSjOiLshyq32RGc2TLXv6H1G+BIEcBkZlhmWeg3Hz9Fh+VGY0AF1gDqSJAR4neVI
	hQBjQXxSiNGpZNmu2RPJwOX4inygBJ+J6Z5eM0leAjSmMvawR97apwChuvVYJAq/
	kguPg9dLaUsT8mZfjGElriKcsVSNyfA+6o0SURqQ3xOb9GZFxAiM1S3o5U/w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941812; x=
	1786028212; bh=ZR1d1bGRuW7PkpYXNT/MSUaHwUt8D8/XKZCozOxnmOo=; b=O
	cpOX6rtQ1SWfMcY2UsgEx6B7W8piD3gKamXRpE3RKInvXLrCILucVG4Ja0MtAYLg
	8Kgd7Qz78Y7q92b29uIvzLdRwdaG7wIbRTAYr8Fpgv79G85Tn3zsUvtE9dnGioc+
	Mef1MSv1sU91TWk/c82e+Aq6JCw1+5yVhExS7X5lSl13t7Ix75TeKA6Hg1kk59mv
	ax4k2Ywhzb9KrK22iirYwtpBo0er/nt2xz1kQgUtc/gVm+Ib3T04c2voaWr/7cwc
	YjsXxCSc6AN8028R/DwECp/taSnJxnDts+K6fH0+HQyd2Aas6e51u7mzf9e7Xt1n
	R9chyGGrqFxFuyWwX5p8g==
X-ME-Sender: <xms:NE9zappkLM1cIdRwWHZT9R1vTaGrItDmghoiD03TPvjBHK8v4PoO5w>
    <xme:NE9zaigYbqNRWCguozHrpBi1vc1kQwB9j6LAM0v6pl_Cnuzw2vBbD8ZBZOZKySc8k
    DrLH7rtYNvIpe_SLubTezi3l9jOnRAA52tvwW1BBHhAhepu1qk>
X-ME-Received: <xmr:NE9zaujLhheOTynhj5Po4hE7MnwrhWNzr0RTIrUBhlb3d6rQ0HCQCVMPfrJ8MURx4l0hOYN1ee5ROrXQXzQuz2ODyxGF5iAUfd0pHlVPDbc>
X-ME-Proxy-Cause: dmFkZTFg5HWH/RDqdPpR88i/6M1gtPWzLlXDm7puE44YW+OQRkCu0ypR/9JOPRDl1te3/p
    2ugUGdWUlQb8kocRthjZN7vvr6IWWNFcyKYmBFPe+BzKMnxGjKoBahL5VCHV3UAfs0EHAg
    nj3sYoDmr7GyZbFXABfsR3rbdQAxCafinJpMUI+6VqMVy7guc3dUP2M2goerpX03cWT8GB
    3tIsn5JiFR3GjgHhPz/r2yz7V7NDg477JFOnzakkhw9w+L8/GP2qYPPRO39CHuug0G7Ubo
    N42GUSC5i0XOiRx9MufeivVdVi29Q812Jc2LJ90UxPjSbThjlODlkTjM/Zl+lF8/E+2aXQ
    K57x5zBbETIFSPxn/glgXCEXI5Rd5omb7Rl9K0RE2BeAtMwCZ0c8U4ZMWkXw9ZMEZTz0RL
    OKo0euqiJNUWJvCkgiR1XXxX8UjQn2EcgSU95KvZktQVlqmkSJW6SrX7eSZtO7u0FLxXFC
    +6eMrs9ZGOWvo0W6EVGjorhGjfSTq2dn2cyNLMf1aA79VNRk14OTFLmAUYBet/ylkfmWj6
    bblUIr7WrdCSerBW2Kz1BrDyJW8KxJoQ2Q5Q0D7TfY49vlQQLtfThuXNYjePMTOZx9i96e
    iWsaoEND85aEUGHz6cEZEW4XI4r8UKX3UwdQ08gANR6AExLKijMDWrUcdCWA
X-ME-Proxy: <xmx:NE9zaghsGM9_u-MCiKJjCjyxu4OEou7D83-AVYgx8t_0tY2QTZmilg>
    <xmx:NE9zamLs6tqKAiBIjrtGag2eOmHbdvupWMhWb-xF0pXsF9cyDhdeaA>
    <xmx:NE9zanELuzDB65V6DaiNhfSDc-SaAXDDjIHa_FtmA2OWty3Oh0Lu7w>
    <xmx:NE9zaiStUKxFFjH_qiNdto1NrOhIGqcaua2YjzgNbPJ1a8NrtVv68w>
    <xmx:NE9zauWon1p1BS9hGiFolrNWG0F8_gIG8WR6i1_t3gIhokFUmeVTnvyY>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 01/13] CI: set LOG_MSG as end-of-test marker consistently
Date: Wed,  5 Aug 2026 16:55:29 +0200
Message-ID: <6a0c80ab0f09bf471679f811e22ba51c034b29e2.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1785941814-C5341757-CA20101A/0/0
X-purgate-type: clean
X-purgate-size: 3715

Especially, do not set it to either empty string (not the same as
unset), nor to a message found earlier in the test execution. This
change will allow more consistent waiting for test end regardless of its
result.

Note for dom0less tests - waiting for dom0 prompt is not the right thing
to do, as the actual test is executed in domU, and those are started
asynchronously.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/scripts/qemu-alpine-x86_64.sh        | 1 -
 automation/scripts/qemu-smoke-dom0-arm32.sh     | 1 -
 automation/scripts/qemu-smoke-dom0-arm64.sh     | 1 -
 automation/scripts/qemu-smoke-dom0less-arm32.sh | 5 ++++-
 automation/scripts/qemu-smoke-dom0less-arm64.sh | 1 -
 5 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
index 242ffca693fe..0c60b2503858 100755
--- a/automation/scripts/qemu-alpine-x86_64.sh
+++ b/automation/scripts/qemu-alpine-x86_64.sh
@@ -81,7 +81,6 @@ export TEST_CMD="qemu-system-x86_64 \
 
 export TEST_LOG="smoke.serial"
 export BOOT_MSG="Latest ChangeSet: "
-export LOG_MSG="Domain-0"
 export PASSED="BusyBox"
 
 ./automation/scripts/console.exp |& sed 's/\r\+$//'
diff --git a/automation/scripts/qemu-smoke-dom0-arm32.sh b/automation/scripts/qemu-smoke-dom0-arm32.sh
index 5dc348c71aa9..4cda80843a84 100755
--- a/automation/scripts/qemu-smoke-dom0-arm32.sh
+++ b/automation/scripts/qemu-smoke-dom0-arm32.sh
@@ -91,7 +91,6 @@ export TEST_CMD="qemu-system-arm \
 export UBOOT_CMD="virtio scan; dhcp; tftpb 0x40000000 boot.scr; source 0x40000000"
 export TEST_LOG="${serial_log}"
 export BOOT_MSG="Latest ChangeSet: "
-export LOG_MSG="Domain-0"
 export PASSED="/ #"
 
 ../automation/scripts/console.exp |& sed 's/\r\+$//'
diff --git a/automation/scripts/qemu-smoke-dom0-arm64.sh b/automation/scripts/qemu-smoke-dom0-arm64.sh
index 1d673f184251..6defd51ca449 100755
--- a/automation/scripts/qemu-smoke-dom0-arm64.sh
+++ b/automation/scripts/qemu-smoke-dom0-arm64.sh
@@ -101,7 +101,6 @@ export TEST_CMD="qemu-system-aarch64 \
 export UBOOT_CMD="virtio scan; dhcp; tftpb 0x40000000 boot.scr; source 0x40000000"
 export BOOT_MSG="Latest ChangeSet: "
 export TEST_LOG="smoke.serial"
-export LOG_MSG="Domain-0"
 export PASSED="BusyBox"
 
 ./automation/scripts/console.exp |& sed 's/\r\+$//'
diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh b/automation/scripts/qemu-smoke-dom0less-arm32.sh
index 20e43b4f049d..fff6d3b56df2 100755
--- a/automation/scripts/qemu-smoke-dom0less-arm32.sh
+++ b/automation/scripts/qemu-smoke-dom0less-arm32.sh
@@ -144,7 +144,10 @@ export TEST_CMD="qemu-system-arm \
 export UBOOT_CMD="virtio scan; dhcp; tftpb 0x40000000 boot.scr; source 0x40000000"
 export BOOT_MSG="Latest ChangeSet: "
 export TEST_LOG="${serial_log}"
-export LOG_MSG="${dom0_prompt}"
 export PASSED="${passed}"
 
 ../automation/scripts/console.exp |& sed 's/\r\+$//'
+
+if [ -n "$dom0_prompt" ]; then
+    grep "$dom0_prompt" "${serial_log}"
+fi
diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh b/automation/scripts/qemu-smoke-dom0less-arm64.sh
index a9e99f1ae392..0d1244d3dc90 100755
--- a/automation/scripts/qemu-smoke-dom0less-arm64.sh
+++ b/automation/scripts/qemu-smoke-dom0less-arm64.sh
@@ -213,7 +213,6 @@ export TEST_CMD="qemu-system-aarch64 \
 
 export UBOOT_CMD="virtio scan; dhcp; tftpb 0x40000000 boot.scr; source 0x40000000"
 export TEST_LOG="smoke.serial"
-export LOG_MSG="Welcome to Alpine Linux"
 export PASSED="${passed}"
 
 ./automation/scripts/console.exp |& sed 's/\r\+$//'
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383599.1626859 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3A-0000gZ-E9; Wed, 05 Aug 2026 14:56:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383599.1626859; Wed, 05 Aug 2026 14:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3A-0000gS-Ax; Wed, 05 Aug 2026 14:56:56 +0000
Received: by outflank-mailman (input) for mailman id 1383599;
 Wed, 05 Aug 2026 14:56:54 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd38-0000gF-Hx
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:56:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd37-004z8Z-DV
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:56:53 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f04-5cb7-0a2a0a5109dd-0a2a450beae0-18
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:53 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f33-b7e8-0a2a450b0019-ca0c7c9883bd-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:52 +0200
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 34C4D7A008E;
 Wed,  5 Aug 2026 10:56:51 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Wed, 05 Aug 2026 10:56:51 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:56:50 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:Message-ID:MIME-Version:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm2;
	 t=1785941811; x=1786028211; bh=YEDuDEwDOK77MggXfQc8ZDeI/hZyM8at
	FiPKnftVAqg=; b=x7GlZqCsludFrj/q5XXF9teD8yNd7di7sCnKuAPP3waJ88oZ
	QJ3vP3pEEryJuIyC76dEtZqe4CibOsVj3WJDBN1cBcqJw+wl845AaNnQkzWRvit6
	mYkG1sX16ZgipiWnL6GG/Mr2J9b2+stSas7/UkAunhJYmAd9x7K8WKO1KYCH+fKu
	AcLNPnVnibmoEVS+ynQieinyeNsv+xBPZe8A3XelaHEhtDiK/8Im+5UDOtUM1oUY
	R61uEdVMu6RicADqAK4DAGT1KjJgq3BOEeJjUV28q0eYQbihJ7RZ0K4PbJLjSDn1
	sqjbWmzEECMASqwIAZzR9G9a5ZW3mEm789o9xA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1785941811; x=1786028211; bh=YEDuDEwDOK77MggXfQc8ZDeI/hZy
	M8atFiPKnftVAqg=; b=jb6orZKg4GFdwpW+oKBcCTkdbiYDujxp1sUaTZSL+Qqn
	In6xj3vPmti0SR7AdPWYs2r2hTYWH9uEbc/XeLoPhQ8v5Pzawp5PcJp5QF1PA7ND
	gknek+iPRjH+90JwVURw21X72RoRUt11X/JNDIlR8TIWsCyyKdVk4ffcmi5fGvdN
	aVXOYk/ZUktbopIbVgzMI7oeJ6PcqmzLS8d6sRc2xbUzuwRUrTefMCZSyrFsviU3
	6mE5jtMyRcMN8LNoxsAmq+0KAOD5uzSf+w9XLutQ6KbvErHyJql0zJ6iHYa0Jm3G
	SYmWVIWthtqsEUTWbJsloYicWaleo3a9SGv6aHPgaQ==
X-ME-Sender: <xms:Mk9zalrxYE4irgR7PDHKmwhBjeVH1oiI3CSQEweXrEaAFD0MPmCEAA>
    <xme:Mk9zavGW57QtepkE3o6wSuwZqiH5wslrTM6nhNMj6TXFVr2ZwzREhFJGrhgoTj2o1
    _xLrj4o_F5a0PByrdj0w1iA5oiiy5ec4SQ8K9xXFre2Nfe7WA>
X-ME-Received: <xmr:Mk9zavnS4XByn026JwsU3uasTC4CcGQk1erDn0f4k-MPvLoMVOXdOK_zoBsvvUuNCLGtSqRC-WAGFN2ylERDz7Auyw2OIOuPo4hBlHyeO4Q>
X-ME-Proxy-Cause: dmFkZTFS2I1DSF/oTs2YQfmubyAQWQKrS9o1T9OtKuY9CuWqDf88oVZfpzRXmQuQDDJlCl
    9cmEs94RusrZIbcOtjToT0S5XlxTu0/NKy/T3ezOs80gUEweOM8EWQajxRiCc2sDk21uFi
    a4W+iCgUtDsR5dmCnaQ56nlW2fJozQqjHRcYXuCeeFL+jQmZGgs0ZNlC0/gFWKng4/Hr+C
    8Gn0wpielhGrWVaWgN6OXQIoyclA+ItQI53S5PNvID0Kpf5iYNI3phx9/STnOHfBHybjoR
    bIZxgdoC1Dc79u2nQ91uWl/a9KidXZ1rnyWoT2gMs6tv7i5vCoPE48r/uiqnWUQ6JAxTpO
    dHLGpTRmNkGEgXxcid+oX7qhV5XmaLsm2Iobk/jPDr1Z+nFsKVGtKaXt1K6wqa/qBOMHm4
    mKMX1+QC+rBgAHV1tMvUhHh+DnqvKq/ekWLMsp6J2o9LZbSFhHhzn6KsLWQoQ9xZiNbyZr
    ZsPlp++qS09qmFkioyY43rtam+hb7uSUGRHDf88kPTzzGXkPZWX1+f8HG9zphrA9B9tJQv
    lNETVsasGQxTMHgIk/IxD9XAvMMoITMXnVTCgYujClddSWU4DUREwXiF+1k9EM2XWcvrj+
    A+gc5z/3jGby+q6Qw1cdQnHzBXvrUUeMMES1D2PLO8HcablrxcH89z+eK5Vw
X-ME-Proxy: <xmx:Mk9zaqkNCUiLS-JFiztHr_qQEQl3DGZc7DOvX7XUBRtdQ3CpjB6vBA>
    <xmx:Mk9zaosiTl75rh28knDc7zUPM6btlC_Z8Z9dcHEetbn2lAwavhMbIQ>
    <xmx:Mk9zalkYA8eChIS6R5BaC-VXPdK_OhBbObW_EZhPtdWUr49UNMOvlA>
    <xmx:Mk9zartdEJLoO-_hL6PzCErrr1Sqhkob7SQvuiJU-H-obD2bs5DpLQ>
    <xmx:M09zat1AhrzcAx0z7JA50rp0MNoZNg8IHhsvL4t4qo5biRKBhkpbLLEe>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: [PATCH v5 00/13] Add several more tests
Date: Wed,  5 Aug 2026 16:55:28 +0200
Message-ID: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785941813-A94C39EA-3731F3D2/0/0
X-purgate-type: clean
X-purgate-size: 2791

This series used to be about just driver domains test, but over time got a few
more. Now it includes:
- fix to detect test failure early, instead of a timeout (at least in some cases)
- simple driver domains test (network backend in domU)
- UKI version of xen.efi booting from firmware directly and via grub2
- domU suspend/resume test (detects recent migration bug)
- fix for macos build jobs being stuck in personal repos

https://gitlab.com/xen-project/people/marmarek/xen/-/pipelines/2734175811

This series requires companion test-artifacts series pushed first (it's fully
acked already):
https://lore.kernel.org/xen-devel/cover.30e6171ddf1c6a72eadf4af0a77c892d4f18d811.1777898148.git-series.marmarek@invisiblethingslab.com/#r

---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>

Marek Marczykowski-Górecki (13):
  CI: set LOG_MSG as end-of-test marker consistently
  CI: Reduce timeout on test failure
  CI: Add driver domains tests
  CI: Add configure --enable-systemd for full build
  CI: Run driver domains test on Debian too
  CI: extract building domU/dom0 out of qemu-alpine-x86_64.sh
  CI: add a smoke test for UKI xen.efi
  CI: add tests booting UKI via grub
  CI: enable xenconsoled logging in alpine tests
  CI: add oops=panic to smoke tests
  CI: Extend qemu-alpine-lib.sh to allow simple networking test
  CI: Add simple domU suspend test
  CI: gate macos build jobs with MACOS_JOBS variable

 automation/build/debian/13-x86_64.dockerfile          |   4 +-
 automation/gitlab-ci/build.yaml                       |   6 +-
 automation/gitlab-ci/test.yaml                        |  51 ++++-
 automation/scripts/build                              |   1 +-
 automation/scripts/console.exp                        |   1 +-
 automation/scripts/qemu-alpine-domU-suspend-x86_64.sh |  71 +++++-
 automation/scripts/qemu-alpine-lib.sh                 |  86 ++++++-
 automation/scripts/qemu-alpine-x86_64.sh              |  60 +----
 automation/scripts/qemu-driverdomains-x86_64.sh       | 149 +++++++++++-
 automation/scripts/qemu-smoke-dom0-arm32.sh           |   1 +-
 automation/scripts/qemu-smoke-dom0-arm64.sh           |   1 +-
 automation/scripts/qemu-smoke-dom0less-arm32.sh       |   5 +-
 automation/scripts/qemu-smoke-dom0less-arm64.sh       |   1 +-
 automation/scripts/qemu-smoke-x86-64-efi-uki.sh       |  92 +++++++-
 14 files changed, 468 insertions(+), 61 deletions(-)
 create mode 100755 automation/scripts/qemu-alpine-domU-suspend-x86_64.sh
 create mode 100755 automation/scripts/qemu-alpine-lib.sh
 create mode 100755 automation/scripts/qemu-driverdomains-x86_64.sh
 create mode 100755 automation/scripts/qemu-smoke-x86-64-efi-uki.sh

base-commit: 0dc67f3aab0a080b756f9e54b8a58a4a887f702b
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383604.1626905 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3I-0001nP-0A; Wed, 05 Aug 2026 14:57:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383604.1626905; Wed, 05 Aug 2026 14:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3H-0001n8-OC; Wed, 05 Aug 2026 14:57:03 +0000
Received: by outflank-mailman (input) for mailman id 1383604;
 Wed, 05 Aug 2026 14:57:02 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3G-0001db-47
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3F-00A5Sr-HC
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:01 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f30-bab6-0a2a0a5309dd-0a2a4505ce0c-22
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:01 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f3c-4cb1-0a2a45050019-ca0c7c98dfed-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:01 +0200
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id F10037A008E;
 Wed,  5 Aug 2026 10:56:59 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Wed, 05 Aug 2026 10:57:00 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:56:58 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941819; x=1786028219; bh=VIHXaX1e+f
	fgdFqzeWyvSlfdqJI5vq9gFySsJjLA51g=; b=bulDFjky/O6MBmdY6opnGgaFXC
	UU08ORMuosrIGedJpG1TBpuidEYA2Ze8EWlvRaNU3PTos/5pShOmM47pl6NEetLV
	wYandMud6QOR5XR39HNtT2WsibgANJrbAju/VQzYEHsj4WjWjktUeSRbeis1gC4N
	XGcn4MSd08orJvYQkA9Cvh2iANFqLNWo1UzGTL7a55BMIJhn5fW78MzXQ7hiP/MH
	h9cHep4xx72Fiphka8co4WiOqeHlR+UbvQ7YDCDnvONjqaICrHz/B/duiOhcZ37/
	8IWuc7ka8jrCRhx7H0gQyWdQmBPYB0/AWi0zWqvbRL3cWJjlcAa+Ps3Cdm3g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941819; x=
	1786028219; bh=VIHXaX1e+ffgdFqzeWyvSlfdqJI5vq9gFySsJjLA51g=; b=C
	2DmdOwu/f9N3SoLHK3Xs1vZ++r2SSALR0O1QAacHN0OXpnIADY0mw3lPcbRi2IZD
	964+gVgyKREZ+jHjqyzFMeEI+oK3y8YsZqfWmAmIAKKiieicVUR6hu4sWGUWx5uL
	snmDhfh0rgsmbh7yAEB4QiNHOBOWMRzrj2waXnEb1R17oST/QsaDyOIEQesUBaZ+
	D+zBd7NN3u43iumv8E6n8jz/2pxkpE7XI/Tf35Y9AC9eJ0NcicEnfxSTpkKgGJ/I
	nwdOfvQwnDvjo5VJOZVJkdSyjTMndb0ltKmoP6jqhfg/rQA8jAC/a8U5JAlPQJPz
	0F2IOQNH9VHpGtMgOjsPg==
X-ME-Sender: <xms:O09zanBhnh-ABZNqErvuhrFHwwE04-oD2YeSV0gjNSWgBGWPsNKjPQ>
    <xme:O09zakYDZ9AOLZzuLiNUAEF_IVL5xy2oxbpvPcmkITFyJxI7zKyMp-x-r72RfJ-6K
    ItAmWkspUyDEtfB_fIMUbtsN-Ks4wguZkwSZHYWDg5kp31aGQ>
X-ME-Received: <xmr:O09zaq7bZ6T6BLtI5mkI7dYz8_oU0rx2mXjFqDPRUtfxwmLE1ADGV-FJNavsRi-D3Mv3OnIQcF3n9n0-cJu746WfgE_s0-rHJlFxasb0IX4>
X-ME-Proxy-Cause: dmFkZTFg5HWH/RDqdPpR88i/6M1gtPWzLlXDm7puE44YW+OQRkCu0ypR/9JOPRDl1te3/p
    2ugUGdWUlQb8kocRthjZN7vvr6IWWNFcyKYmBFPe+BzKMnxGjKoBahL5VCHV3UAfs0EHAg
    nj3sYoDmr7GyZbFXABfsR3rbdQAxCafinJpMUI+6VqMVy7guc3dUP2M2goerpX03cWT8GB
    3tIsn5JiFR3GjgHhPz/r2yz7V7NDg477JFOnzakkhw9w+L8/GP2qYPPRO39CHuug0G7Ubo
    N42GUSC5i0XOiRx9MufeivVdVi29Q812Jc2LJ90UxPjSbThjlODlkTjM/Zl+lF8/E+2aqt
    yLt1OCe/nhAJMu2CJUS7qRdrtLxh2jFsE6WK4OVh+oT2+FC56uWyodULwj6z4RYpvXMpDn
    ewuSorjvwbszn0rU/9FzOXB23lxuSQdgnDfmmO00Hvw8LbpbTYmtiqViV7RFvxunh50c3G
    8VXisn+B7wyNhjl+xzIq5pMSVC7JZtPn2QiYC9iodIB1U6smXPV4xHBYegFH/vB2XAhqIJ
    Dfq6UY98Zv5LIJAw15Ciy1EI0oCl+sMiLPNQ68YPpEzBsNGDmbcL5gnje631EYYPqZK7QR
    /bOjS3BtFN/loXp192R7t9b32urTvDsuoKVrkyU3gvTDrnQiaWpCtVqW/TfQ
X-ME-Proxy: <xmx:O09zalYHoD0fl8bfjwn2HujCqeRp9Q83q0D95yyNvj50BOa16kPl7A>
    <xmx:O09zapggGJDqU_ufBrEJH0gXM0H-aJi1KsBHrZ5ozTsqWKuBAOXpZA>
    <xmx:O09zam_KqudWhQP23OOJ14kaGl9E6dHAq_adDqcGAxUZAOrK2Z8CQQ>
    <xmx:O09zakozJUzz63UB6mP0I1rb72RYtr3OH-pWFAN41JSg-jXPCjrXiQ>
    <xmx:O09zaiOs77kzefBTQ3YWeaX0xEcpm1jw9pWxrxA0b-n3ebJrXHj3Qqv->
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Doug Goldstein <cardoe@cardoe.com>
Subject: [PATCH v5 05/13] CI: Run driver domains test on Debian too
Date: Wed,  5 Aug 2026 16:55:33 +0200
Message-ID: <372962629561e96b83fc87039b0e6e31e4f9b6e6.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1785941821-F54AC2A1-1B0081E9/0/0
X-purgate-type: clean
X-purgate-size: 3655

The recent failure affected only glibc-based systems, so do the test on
Debian too.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
---
Changes in v3:
- update to trixie
Changes in v2:
- use systemd in Debian

Needs debian/13-x86_64 container rebuild.
---
 automation/build/debian/13-x86_64.dockerfile    |  1 +-
 automation/gitlab-ci/test.yaml                  | 19 ++++++++++++++++++-
 automation/scripts/qemu-driverdomains-x86_64.sh | 18 +++++++++++++++--
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/automation/build/debian/13-x86_64.dockerfile b/automation/build/debian/13-x86_64.dockerfile
index 5088f7435c1e..8a36774f1155 100644
--- a/automation/build/debian/13-x86_64.dockerfile
+++ b/automation/build/debian/13-x86_64.dockerfile
@@ -61,6 +61,7 @@ RUN <<EOF
         fakeroot
         ovmf
         qemu-system-x86
+        systemctl
 
         # for build-each-commit-gcc
         ccache
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 566d1f4287d7..184cf9b47d46 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -27,6 +27,17 @@
     job: microcode-x86
     ref: $ARTIFACTS_BRANCH
 
+.debian-x86-64-test-needs: &debian-x86-64-test-needs
+  - project: xen-project/hardware/test-artifacts
+    job: linux-6.6.56-x86_64
+    ref: master
+  - project: xen-project/hardware/test-artifacts
+    job: debian-13-x86_64-rootfs
+    ref: master
+  - project: xen-project/hardware/test-artifacts
+    job: microcode-x86
+    ref: master
+
 .qemu-arm64:
   extends: .test-jobs-common
   variables:
@@ -741,6 +752,14 @@ qemu-alpine-driverdomains-x86_64-gcc:
     - *x86_64-test-needs
     - alpine-3.24-x86_64-gcc
 
+qemu-debian-13-driverdomains-x86_64-gcc:
+  extends: .qemu-x86_64
+  script:
+    - ./automation/scripts/qemu-driverdomains-x86_64.sh 2>&1 | tee ${LOGFILE}
+  needs:
+    - *debian-x86-64-test-needs
+    - debian-13-x86_64-gcc-debug
+
 qemu-smoke-x86_64-gcc:
   extends: .qemu-smoke-x86_64
   script:
diff --git a/automation/scripts/qemu-driverdomains-x86_64.sh b/automation/scripts/qemu-driverdomains-x86_64.sh
index bada6599842e..07bc617058f9 100755
--- a/automation/scripts/qemu-driverdomains-x86_64.sh
+++ b/automation/scripts/qemu-driverdomains-x86_64.sh
@@ -20,7 +20,11 @@ if grep -q test=backend /proc/cmdline; then
     brctl addbr xenbr0
     ip link set xenbr0 up
     ip addr add 192.168.0.1/24 dev xenbr0
-    bash /etc/init.d/xendriverdomain start
+    if [ -d /run/systemd ]; then
+        systemctl start xendriverdomain
+    else
+        bash /etc/init.d/xendriverdomain start
+    fi
     # log backend-related logs to the console
     tail -F /var/log/xen/xldevd.log /var/log/xen/xen-hotplug.log >>/dev/console 2>/dev/null &
 else
@@ -83,7 +87,11 @@ cat > etc/local.d/xen.start << EOF
 
 set -x
 
-bash /etc/init.d/xencommons start
+if [ -d /run/systemd ]; then
+    systemctl start xen-init-dom0.service
+else
+    bash /etc/init.d/xencommons start
+fi
 
 xl list
 
@@ -100,6 +108,12 @@ cp ../bzImage ./root/
 mkdir -p etc/default
 echo 'XENCONSOLED_TRACE=all' >> etc/default/xencommons
 mkdir -p var/log/xen/console
+if [ -e etc/systemd/system.conf ]; then
+    systemctl --root=. enable \
+        xenstored.service \
+        xenconsoled.service \
+        xen-init-dom0.service
+fi
 # this is a sparse file, not really using full 2GiB
 fakeroot -i ../fakeroot-save mkfs.ext4 -d . ../dom0-rootfs.img 2048M
 cd ..
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383602.1626886 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3E-0001JF-8B; Wed, 05 Aug 2026 14:57:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383602.1626886; Wed, 05 Aug 2026 14:57:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3E-0001J5-48; Wed, 05 Aug 2026 14:57:00 +0000
Received: by outflank-mailman (input) for mailman id 1383602;
 Wed, 05 Aug 2026 14:56:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3C-00015x-QJ
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:56:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3C-00Cdp1-6c
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:56:58 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f20-e002-0a2a0a5209dd-0a2a4503d7c8-38
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:58 +0200
Received: from [202.12.124.150] (helo=fout-b7-smtp.messagingengine.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f39-fae8-0a2a45030019-ca0c7c96eddb-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:57 +0200
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id A81F11D00112;
 Wed,  5 Aug 2026 10:56:56 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Wed, 05 Aug 2026 10:56:56 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:56:55 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941816; x=1786028216; bh=If8iCaUuEU
	VvExp6X8arU9RVZ07EdT9hQbyHaLfCGsI=; b=BKxRI+UeLWnwHMgldypAuxkp4B
	sAhPF4dDpp0+iZVUhwDc2eIxzKEIzToOoiNBuHrUHTnrr0FIMwlyhC0FAHpO1hkt
	mfmTUhOE7UOAscOiLYyW+M5l2aIMDA0ibf706YtQW8/Pux5GZ8kzeQLkXKTAnX2T
	lktIo8gbK5xfvQHqiDHw62gSM552SFZpUBq1AN5caiNKoX1U/z/IGQjgpCJo/wSQ
	hsTuzXp6/eBhgj2U6IA67dy6OBYFXEmBW/Fp1UE2+CJMkKsSoR+5f8Q3wKV5f9XW
	weCCruNpm1xUIwprX2IT1kn0ndQ4/qFdzIBdpE1Do3lpbF7Zf2BHjlaLo3LA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941816; x=
	1786028216; bh=If8iCaUuEUVvExp6X8arU9RVZ07EdT9hQbyHaLfCGsI=; b=O
	l4tHmUjfe8ZhMaDLMq6E7KD+QxGkkIjsDCi9GBszronts+gyX4VsjansEpk3NS9F
	9EFLCHX+JICZ/DRPwI6SpL/aSqWyVxuI/cBYQ92cFLJM59kccZ2ezug5bypNMAna
	1pFQ1UExX/sL+2ulRE0GxYQgUd5ihQtbQhNPbCCt/cauvnu4IOrLl1UNSz9TGq3X
	gf3fBz8X7qS37i69Q/FVhKFJYM6VD4yABjB75a8wnT2VwuR6Hgaz8WfMbRaAYp0+
	drMOnTHsj+RN531Qf0qkHMyz0R0QcHpuokLnxn30AjcNj3zLWyiY7Um+djoprceC
	I1F2AogWztUmgjuJopddg==
X-ME-Sender: <xms:OE9zanSTxSkPeqkUD4EIMN8nW-F8LTgT0a3yAtHKzZ3skut7NbhaFQ>
    <xme:OE9zavrmtu2_KWvO7FVO0lmCfXRybQulnlXpAkObJpz7aAPEMtSddb2cpO7XyAjXL
    xGcTBuNlTqzlRpV3BDyA_88SKDUNd60BABIcfjm6k26Bw3Z5g>
X-ME-Received: <xmr:OE9zalKH7-f-_i8j_xNagir3RheLuPQJz8R3QIxF81UNvoYLsasaLESA_Nircol8PeQru5fdcehm426xjU7woRWFNpRBYeTx67t7FoquZn4>
X-ME-Proxy-Cause: dmFkZTFg5HWH/RDqdPpR88i/6M1gtPWzLlXDm7puE44YW+OQRkCu0ypR/9JOPRDl1te3/p
    2ugUGdWUlQb8kocRthjZN7vvr6IWWNFcyKYmBFPe+BzKMnxGjKoBahL5VCHV3UAfs0EHAg
    nj3sYoDmr7GyZbFXABfsR3rbdQAxCafinJpMUI+6VqMVy7guc3dUP2M2goerpX03cWT8GB
    3tIsn5JiFR3GjgHhPz/r2yz7V7NDg477JFOnzakkhw9w+L8/GP2qYPPRO39CHuug0G7Ubo
    N42GUSC5i0XOiRx9MufeivVdVi29Q812Jc2LJ90UxPjSbThjlODlkTjM/Zl+lF8/E+2ahn
    is+bRSV1dAKf+3WxH9+prVq11Vy45YWKlbNbiCrUBO4C04CBMR49ODI1BGXvU81EfFnMcR
    yJNuMZTdimaUPAfhBnBegsmDDqegTWMsNbq7Cf5fGuC4MzRrG5bsJh8ApZyuiKE548EiMP
    xHdto99MpuSSifVixRyp7mCJf2Y03CzI+zmXDa760m0p0lnAyGy4w/J98Dt1WBHQoGCZY4
    dz90z4nsVqfSe8hnTtAsKKeRJst0PGohEAE8C9kRi8ZlKfyabM1ItPXG+rc5tNKazpDfrg
    ZrAIhGLT2jkoWixnEOZ0TH1Zk8GMSGeHV6DNSy0CSm++0JasOabEJFXXPgUQ
X-ME-Proxy: <xmx:OE9zaip0yVVY7xZHWyG74bQnBUJclspaCsZzfzNcHokjrek7jjRy-A>
    <xmx:OE9zatzu8TxnMl9QA-1UipHfz_6UR1L5imGFBxWFUGICJ7UYVK2XPA>
    <xmx:OE9zamO1aE4cIZPjZl9SoNLjz2a_e0FOxlqUW-An0jJYJUX-qP5u1Q>
    <xmx:OE9zai51Cd039mgKdBmLhT0a5hFa-NvwO__yX6jEgC_iBc4NbKvRfA>
    <xmx:OE9zapcQD4ZuK9LTewgok6Hm68x3-jPBdfb155i4unocalH84EqlxJAW>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 03/13] CI: Add driver domains tests
Date: Wed,  5 Aug 2026 16:55:31 +0200
Message-ID: <20b70bd488f533cdaa8e72a92a69afc0d5de4d7d.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785941818-6E2D04E9-85FFADF0/0/0
X-purgate-type: clean
X-purgate-size: 6516

Setup a simple two domU system. One with network backend, running
xendriverdomain service, and one with frontend, trying to ping the
backend.

Contrary to other similar tests, use disk image instead of initrd, to
allow bigger rootfs without adding more RAM (for both dom0 and domU).
But keep using pxelinux as a bootloader as it's easier to setup than
installing grub on the disk. Theoretically, it could be started via direct
kernel boot in QEMU, but pxelinux is slightly closer to real-world
deployment.

Use fakeroot to preserve file owners/permissions. This is especially
important for suid binaries like /bin/mount - without fakeroot, they
will end up as suid into non-root user.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
Changes in v5:
- add code comment about sparse files
Changes in v3:
- add fakeroot
- run ldconfig at the disk image creation time, to avoid running it at
  dom0/domU boot time (which is much slower)
Changes in v2:
- use heredoc
- limit ping loop iterations
- use full "backend" / "frontend" in disk image names
- print domU consoles directly to /dev/console, to avoid systemd-added
  messages prefix
- terminate test on failure, don't wait for timeout

Needs debian/13-x86_64 container rebuild.
---
 automation/build/debian/13-x86_64.dockerfile    |   2 +-
 automation/gitlab-ci/test.yaml                  |   8 +-
 automation/scripts/qemu-driverdomains-x86_64.sh | 135 +++++++++++++++++-
 3 files changed, 145 insertions(+)
 create mode 100755 automation/scripts/qemu-driverdomains-x86_64.sh

diff --git a/automation/build/debian/13-x86_64.dockerfile b/automation/build/debian/13-x86_64.dockerfile
index 784299d52dc3..5088f7435c1e 100644
--- a/automation/build/debian/13-x86_64.dockerfile
+++ b/automation/build/debian/13-x86_64.dockerfile
@@ -56,7 +56,9 @@ RUN <<EOF
 
         # for test phase, qemu-* jobs
         busybox-static
+        e2fsprogs
         expect
+        fakeroot
         ovmf
         qemu-system-x86
 
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 61adc1baff30..566d1f4287d7 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -733,6 +733,14 @@ qemu-alpine-x86_64-gcc:
     - *x86_64-test-needs
     - alpine-3.24-x86_64-gcc
 
+qemu-alpine-driverdomains-x86_64-gcc:
+  extends: .qemu-x86_64
+  script:
+    - ./automation/scripts/qemu-driverdomains-x86_64.sh 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86_64-test-needs
+    - alpine-3.24-x86_64-gcc
+
 qemu-smoke-x86_64-gcc:
   extends: .qemu-smoke-x86_64
   script:
diff --git a/automation/scripts/qemu-driverdomains-x86_64.sh b/automation/scripts/qemu-driverdomains-x86_64.sh
new file mode 100755
index 000000000000..bada6599842e
--- /dev/null
+++ b/automation/scripts/qemu-driverdomains-x86_64.sh
@@ -0,0 +1,135 @@
+#!/bin/bash
+
+set -ex -o pipefail
+
+cd binaries
+
+# DomU rootfs
+
+mkdir -p rootfs
+cd rootfs
+mkdir -p etc/local.d
+passed="ping test passed"
+failed="TEST FAILED"
+cat > etc/local.d/xen.start << EOF
+#!/bin/bash
+
+set -x
+
+if grep -q test=backend /proc/cmdline; then
+    brctl addbr xenbr0
+    ip link set xenbr0 up
+    ip addr add 192.168.0.1/24 dev xenbr0
+    bash /etc/init.d/xendriverdomain start
+    # log backend-related logs to the console
+    tail -F /var/log/xen/xldevd.log /var/log/xen/xen-hotplug.log >>/dev/console 2>/dev/null &
+else
+    ip link set eth0 up
+    ip addr add 192.168.0.2/24 dev eth0
+    timeout=6 # 6*10s
+    until ping -c 10 192.168.0.1; do
+        sleep 1
+        if [ \$timeout -le 0 ]; then
+            echo "${failed}"
+            exit 1
+        fi
+        ((timeout--))
+    done
+    echo "${passed}"
+fi
+EOF
+chmod +x etc/local.d/xen.start
+fakeroot sh -c "
+    zcat ../rootfs.cpio.gz | cpio -imd
+    zcat ../xen-tools.cpio.gz | cpio -imd
+    ldconfig -r .
+    touch etc/.updated
+    # this is a sparse file, not really using full 1GiB
+    mkfs.ext4 -d . ../domU-rootfs.img 1024M
+"
+cd ..
+rm -rf rootfs
+
+# Dom0 rootfs
+mkdir -p rootfs
+cd rootfs
+fakeroot -s ../fakeroot-save sh -c "
+    zcat ../rootfs.cpio.gz | cpio -imd
+    zcat ../xen-tools.cpio.gz | cpio -imd
+    ldconfig -r .
+    touch etc/.updated
+"
+mkdir -p root etc/local.d
+cat > root/backend.cfg << EOF
+name="backend"
+memory=512
+vcpus=1
+kernel="/root/bzImage"
+extra="console=hvc0 root=/dev/xvda net.ifnames=0 test=backend"
+disk=[ '/root/domU-rootfs-backend.img,raw,xvda,rw' ]
+EOF
+cat > root/frontend.cfg << EOF
+name="frontend"
+memory=512
+vcpus=1
+kernel="/root/bzImage"
+extra="console=hvc0 root=/dev/xvda net.ifnames=0 test=frontend"
+disk=[ '/root/domU-rootfs-frontend.img,raw,xvda,rw' ]
+vif=[ 'bridge=xenbr0,backend=backend' ]
+EOF
+
+cat > etc/local.d/xen.start << EOF
+#!/bin/bash
+
+set -x
+
+bash /etc/init.d/xencommons start
+
+xl list
+
+tail -F /var/log/xen/console/guest-backend.log 2>/dev/null | sed -e "s/^/(backend) /" >>/dev/console &
+tail -F /var/log/xen/console/guest-frontend.log 2>/dev/null | sed -e "s/^/(frontend) /" >>/dev/console &
+xl -vvv create /root/backend.cfg
+xl -vvv create /root/frontend.cfg
+EOF
+chmod +x etc/local.d/xen.start
+
+cp ../domU-rootfs.img ./root/domU-rootfs-backend.img
+cp ../domU-rootfs.img ./root/domU-rootfs-frontend.img
+cp ../bzImage ./root/
+mkdir -p etc/default
+echo 'XENCONSOLED_TRACE=all' >> etc/default/xencommons
+mkdir -p var/log/xen/console
+# this is a sparse file, not really using full 2GiB
+fakeroot -i ../fakeroot-save mkfs.ext4 -d . ../dom0-rootfs.img 2048M
+cd ..
+rm -rf rootfs
+
+cd ..
+
+cat >> binaries/pxelinux.0 << EOF
+#!ipxe
+
+kernel xen console=com1 console_timestamps=boot
+module bzImage console=hvc0 root=/dev/sda net.ifnames=0
+boot
+EOF
+
+# Run the test
+rm -f smoke.serial
+export TEST_CMD="qemu-system-x86_64 \
+    -cpu qemu64,+svm \
+    -m 2G -smp 2 \
+    -monitor none -serial stdio \
+    -nographic \
+    -device virtio-net-pci,netdev=n0 \
+    -netdev user,id=n0,tftp=binaries,bootfile=/pxelinux.0 \
+    -drive file=binaries/dom0-rootfs.img,format=raw"
+
+export TEST_LOG="smoke.serial"
+export BOOT_MSG="Latest ChangeSet: "
+# exit early on test failure too, check if it was success below
+export LOG_MSG="$passed|$failed"
+export PASSED="$passed"
+
+./automation/scripts/console.exp | sed 's/\r\+$//'
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383605.1626913 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3J-00022O-4j; Wed, 05 Aug 2026 14:57:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383605.1626913; Wed, 05 Aug 2026 14:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3J-00021X-17; Wed, 05 Aug 2026 14:57:05 +0000
Received: by outflank-mailman (input) for mailman id 1383605;
 Wed, 05 Aug 2026 14:57:03 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3H-0001mW-Gs
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3G-004zD5-Tn
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:02 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f32-e002-0a2a0a5209dd-0a2a45079ea8-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:02 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f3d-b4ea-0a2a45070019-ca0c7c98bcbd-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:02 +0200
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 7C30F7A00CD;
 Wed,  5 Aug 2026 10:57:01 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Wed, 05 Aug 2026 10:57:01 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:00 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941821; x=1786028221; bh=NJqCn/CpFS
	hQ4iywkQBEF1/M0+zfv/NLrkPB9AYJeCY=; b=0l/iKxUU+2hwwvEKxPktRRLuar
	Pfw/dYsXbJ571858vogWyyUq7IiHNpW6wDKcglyiSeYRHwxvS/CBtPv34WLIV1ZY
	rnvTW01Wq860M1V5zU1HXzAPikk9r88pu2rHNHOvHYgEf1B04Jn8tJEygqQ0877+
	sMILnqr372ZS5vuPhhPRuqCICbWH9d08yMCFYF4Gf9XBNdp5DUdNOLJdrl+7g8py
	qmzQNzqfe48FitDQvkUQys4ktXbJcFV8Y3qiXuUWEFX3nJQT5R45Oh7sEQy9DAIw
	m0s+hR5LJ/zSPiMpjEeW2lcq2fbekEA4Lpr2w1lp/cReqxYsLCJghi3gRHgA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941821; x=
	1786028221; bh=NJqCn/CpFShQ4iywkQBEF1/M0+zfv/NLrkPB9AYJeCY=; b=H
	GzAdrxOkUp3hBBSaJwOHv5CfVzqSNaf/m8Qizq+/IrAHIJ0ZIP9MitMrHEwgGkd3
	hW8vdzLmxddYXbUjHJhLhkp20djA4FX5xW+FXwzB/CWWNOOLxsssZ5fipijsKu1H
	OksV5W2vp5ExMCD6qeKuXFmyh042D2kQsoUko+kn/UGb3hyZPewkERd0YvY8zd8x
	MdgFOyAyTSID474PDSegCYfmw8zds8woS3Q7W6Y5Ai7sFfrxBQ14ZVwhvlQSybOO
	zbN0QSlGHrbO/ky8yBuPA576gX9DhRbUcrv06JBzH993sXo66RiD2oEqBgULXZqm
	cD9aWcMq+47J4mHuqGOIA==
X-ME-Sender: <xms:PU9zapJg__N98i6FbDSklH4yMKtqbDHC3dDUaQAVzSMB4SGriU24jQ>
    <xme:PU9zasAwRBL0MZDbCYnn_jnQZaf-N2ViX-28wuGlKbrfzncrY-lkg-kqd2kvlKY5h
    WGLtRRu4m-4uMELGL6wqP_4ZfSkAFqVmzDyhpsmzOQ6vuD5Uw>
X-ME-Received: <xmr:PU9zaqDU5x47Q1f4nivOH1I27y5C2WB-_4I_0c6OFycIGfk1B21LG4I6T9lo_C7HncBb-S4IH-cG7Mv2WkoDKYPhzX_G0bcg42RojNmaXFY>
X-ME-Proxy-Cause: dmFkZTE1tKvhsT+Fhei0Yg+G27SZQPQVopYNzanoImCL8xkq2oL6bKpGea3H8hzYRKHrGC
    B6kQUNlF+nZ7bYZBt1/dQdXqlMW9NJlyslPcE0+Pa5JNi0jTkDFxiuq8QbvTIJJx2SeYvk
    MURT57H+uIHzESnQrqQOd471thhd85FLBD10JZToXtKcwAL2lIl13tKixe9zx9R8K6lDVh
    KmpaTBDrNZA6jwf9idIZL/vdHPuMsaLOe+zilHC5z0fnjufSdy4lnRs2QJOWeDUP+W5tLW
    UzmcKwTf1aOSEOg4bUbniMBRaVMDpagjyVQAluXe6sHMhg18pP5cC9VjXvgw8aCZHU5tcV
    JRg0Dl83yyuPeVOfv1CsBEx7Rt+EWXR/sDFDuKWCf7D2Fzsq7L0xpbqq95ejzCCqrSu5O7
    YdglTevOLDxzB+X1v2mF5+NCpPaGwCX835GKY6koo1LlZ+ULHFm4jD3R+jsPdprbEgaihM
    /fw6zto9NmRt893XgnqD5y4J5qV8HITW5ZppAFXmfZbf6Z9eoTg5/UEEzGD4nKfIbymrpj
    zFUsBdy4F4VMb1RdPpDuv4mquGjr7D15Yn+Nfo0qxUBr1d3kVm8LaeNKsi7OKO/zr5EdDV
    6LEzyNotZaaRUBZaIQ1/91fAtLdhqXj04aI4iG7VBuFhOmGX8sotuwl+RpzQ
X-ME-Proxy: <xmx:PU9zamBy3rrDINh0oBMjtlVNL8AmJvMAEFtdTC26vYA4J4xpfMyG4A>
    <xmx:PU9zatqvDlFdttl8XiO8EOwdXsMWF3TblrtRlIXgmF_TeSLuwl2PGw>
    <xmx:PU9zaokVM-J7LmHy4urvUa0Z98SZL_6AppzISodiESJOJNQCUwaUlA>
    <xmx:PU9zalyJnjOPrROTAKIg7ArQ1UFIFryUAIJdPnLgLbfwYDzHBSh6Cw>
    <xmx:PU9zav2_GJ1wYcmVxyHVGUosN3DhkbinHXf5b3AJ9lif6HauJAxyru8g>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 06/13] CI: extract building domU/dom0 out of qemu-alpine-x86_64.sh
Date: Wed,  5 Aug 2026 16:55:34 +0200
Message-ID: <ddb2b1dbebaa662c15957587ac2aeb74007464b3.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1785941822-A50CDAE4-2B5DB2C4/0/0
X-purgate-type: clean
X-purgate-size: 3993

Add qemu-alpine-lib.sh with utility functions that build dom0/domU out
of container binaries.
This will be used in further tests that re-use similar structure.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/scripts/qemu-alpine-lib.sh    | 62 +++++++++++++++++++++++++-
 automation/scripts/qemu-alpine-x86_64.sh | 59 +-----------------------
 2 files changed, 66 insertions(+), 55 deletions(-)
 create mode 100755 automation/scripts/qemu-alpine-lib.sh

diff --git a/automation/scripts/qemu-alpine-lib.sh b/automation/scripts/qemu-alpine-lib.sh
new file mode 100755
index 000000000000..29fdff4f562a
--- /dev/null
+++ b/automation/scripts/qemu-alpine-lib.sh
@@ -0,0 +1,62 @@
+#!/bin/bash
+
+build_domU() {
+    # DomU Busybox
+    mkdir -p initrd
+    mkdir -p initrd/bin
+    mkdir -p initrd/sbin
+    mkdir -p initrd/etc
+    mkdir -p initrd/dev
+    mkdir -p initrd/proc
+    mkdir -p initrd/sys
+    mkdir -p initrd/lib
+    mkdir -p initrd/var
+    mkdir -p initrd/mnt
+    cp /bin/busybox initrd/bin/busybox
+    initrd/bin/busybox --install initrd/bin
+    echo "#!/bin/sh
+
+mount -t proc proc /proc
+mount -t sysfs sysfs /sys
+mount -t devtmpfs devtmpfs /dev
+/bin/sh" > initrd/init
+    chmod +x initrd/init
+    # DomU rootfs
+    cd initrd
+    find . | cpio -R 0:0 -H newc -o | gzip > ../domU-rootfs.cpio.gz
+    cd ..
+}
+
+build_dom0() {
+    # Dom0 rootfs
+    cp rootfs.cpio.gz dom0-rootfs.cpio.gz
+    cat xen-tools.cpio.gz >> dom0-rootfs.cpio.gz
+
+    # test-local configuration
+    mkdir -p rootfs
+    cd rootfs
+    mkdir -p root etc/local.d
+    mv ../domU-rootfs.cpio.gz ./root
+    cp ../bzImage ./root
+    echo "name=\"domU\"
+    memory=512
+    vcpus=1
+    kernel=\"/root/bzImage\"
+    ramdisk=\"/root/domU-rootfs.cpio.gz\"
+    extra=\"console=hvc0 root=/dev/ram0 rdinit=/bin/sh\"
+    " > root/domU.cfg
+    echo "#!/bin/bash
+
+    set -x
+
+    bash /etc/init.d/xencommons start
+
+    xl list
+
+    xl -vvv create -c /root/domU.cfg
+
+    " > etc/local.d/xen.start
+    chmod +x etc/local.d/xen.start
+    find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
+    cd ..
+}
diff --git a/automation/scripts/qemu-alpine-x86_64.sh b/automation/scripts/qemu-alpine-x86_64.sh
index 0c60b2503858..e1b5060f4490 100755
--- a/automation/scripts/qemu-alpine-x86_64.sh
+++ b/automation/scripts/qemu-alpine-x86_64.sh
@@ -2,64 +2,13 @@
 
 set -ex -o pipefail
 
-# DomU Busybox
-cd binaries
-mkdir -p initrd
-mkdir -p initrd/bin
-mkdir -p initrd/sbin
-mkdir -p initrd/etc
-mkdir -p initrd/dev
-mkdir -p initrd/proc
-mkdir -p initrd/sys
-mkdir -p initrd/lib
-mkdir -p initrd/var
-mkdir -p initrd/mnt
-cp /bin/busybox initrd/bin/busybox
-initrd/bin/busybox --install initrd/bin
-echo "#!/bin/sh
+. "$(dirname "$0")"/qemu-alpine-lib.sh
 
-mount -t proc proc /proc
-mount -t sysfs sysfs /sys
-mount -t devtmpfs devtmpfs /dev
-/bin/sh" > initrd/init
-chmod +x initrd/init
-# DomU rootfs
-cd initrd
-find . | cpio -R 0:0 -H newc -o | gzip > ../domU-rootfs.cpio.gz
+cd binaries
+build_domU
+build_dom0
 cd ..
 
-# Dom0 rootfs
-cp rootfs.cpio.gz dom0-rootfs.cpio.gz
-cat xen-tools.cpio.gz >> dom0-rootfs.cpio.gz
-
-# test-local configuration
-mkdir -p rootfs
-cd rootfs
-mkdir -p root etc/local.d
-mv ../domU-rootfs.cpio.gz ./root
-cp ../bzImage ./root
-echo "name=\"domU\"
-memory=512
-vcpus=1
-kernel=\"/root/bzImage\"
-ramdisk=\"/root/domU-rootfs.cpio.gz\"
-extra=\"console=hvc0 root=/dev/ram0 rdinit=/bin/sh\"
-" > root/domU.cfg
-echo "#!/bin/bash
-
-set -x
-
-bash /etc/init.d/xencommons start
-
-xl list
-
-xl -vvv create -c /root/domU.cfg
-
-" > etc/local.d/xen.start
-chmod +x etc/local.d/xen.start
-find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
-cd ../..
-
 cat >> binaries/pxelinux.0 << EOF
 #!ipxe
 
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383601.1626877 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3D-00016E-2u; Wed, 05 Aug 2026 14:56:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383601.1626877; Wed, 05 Aug 2026 14:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3C-000163-Tk; Wed, 05 Aug 2026 14:56:58 +0000
Received: by outflank-mailman (input) for mailman id 1383601;
 Wed, 05 Aug 2026 14:56:57 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3B-0000oe-Dq
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:56:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3A-00CQKb-CY
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:56:56 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f34-2eae-0a2a0a5409dd-0a2a4506baa6-22
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:56 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f37-195a-0a2a45060019-ca0c7c98a5ef-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:56 +0200
Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50])
 by mailfhigh.stl.internal (Postfix) with ESMTP id E012B7A00D4;
 Wed,  5 Aug 2026 10:56:54 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-10.internal (MEProxy); Wed, 05 Aug 2026 10:56:55 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:56:53 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941814; x=1786028214; bh=6TXF8NBknI
	pzz7v8cLxu16DA3612q9rG5557ATJiwak=; b=Sb3H46GsSvOXvjLFOyX29JlQU4
	ZWXRgpaqy4poyVxgoCf1giiPzFWlLouA9i0u69wmMVCudibDySNaPNrulk6qIBlw
	EqIMFyFcf/lZ/O/6S9x6MxwIrjT5M2m2uoqVnSO2ztc16z28mSX0uyQvI6jxdaDp
	KFmEKywQKk1YbKWp0kS0q8a+xUW1PaHGb52QOnLsdGPrN5Vy28oanLNRqYbOLOEZ
	yEikl78FBNyGEv/CLc9sxd+tutbPGjy97a84W/8chgNPC95HMWg3oK63gVNyDkAl
	mHD4yz9UIr1xtdr39R1mOdF+tF4IooGwuEBKG638uCnBHIy6pj0FxsX5JE8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941814; x=
	1786028214; bh=6TXF8NBknIpzz7v8cLxu16DA3612q9rG5557ATJiwak=; b=E
	fRk2NPg0l8ET21oYuUJYmm2qib4u0HSEYV4VfbjipkYv2nKlXNVtjlf6kBc9+fpj
	JlKo2zzp5yvm+joVfBhoheI/KY0XZDTVCkgd/APvw0vvnr71f5b/s5FPhcMbuYI2
	l9BvCfUxSOXWTIbWoOoDqHtIBXSQslvdtqXQTJQ82hBWEtScg4Z/HHYlJO3WbWnA
	YHG6lxUJtcD8eKOzkPesihBUi+zUAwoXN6wu4i+5tP3ybT+guCEnCpqUU/Hh1RMw
	r5UqgoDL99S3QSgA+OqnjTLEgG+YYTwDAcNzANdyS2RR1mj4ML7VUsdNcb6k8+Op
	PaKghpNffJ13OXFrMl8+g==
X-ME-Sender: <xms:Nk9zavH771BruQAWtN6_X-1LVCaflknDIJm-42cjDDKCcoEpQrx-9g>
    <xme:Nk9zajOy4W2TfApTJ43LcldY6ksEQ5YFuS5nFT7AbGmc9uMIk71bLQj06KzJi0ded
    9aAqDogC1dJCLe0ZMnE6t_cF-58mEjvf7RipYYa1AlNI2Ngs3I>
X-ME-Received: <xmr:Nk9zapdESbN_wwHMyq0iSHP54XhTR99TDsXgKm4TAXS0An9znGweOT_R18Rps9X0QZZTBHc-kVT2PJw40B4DdPLvkxSyxFUNTTqTU5iLTrU>
X-ME-Proxy-Cause: dmFkZTEdkvLxT+7ERUoKSapa1INrusQu2FZX/o9rqRP1XBK15rAw70yPydcC3NfqbA6Lrf
    4puMmK5txEfuISPRuXWjpSCdsSeR+ufxTsazl6IC22b0hWJX0iKN7KSwQVuS2VSUUDH+Dj
    2vVw9VAwzNzcOOEo/3GzaHvePPom9QgwnkPOERV+gliyvt2NHofrpPdQOkhW49z8fC8cgn
    6kDdLCqxJkQ6dXm9LDBL8Zi+6SnAUc+9mUiuLRAzS1mwJNsan9xrkGOxbXhqopJIC+MZM1
    sAWmGCMwjHA49BcUskgsz4gguRIIl/ww8SE206Z0mStY/oUSsgfAxoS44sAUZllLWOs9UM
    PUROGKfl1JuD7sVMVMUTtvEWjbrSP8wRxo1QtPYztct2Zd1WxPDkYL0LtWoaQCsIsvl6cd
    ZQEnFSWOR/CWxpbdxMm+pinEgdd+1wUB566ulqsvWis+MMlKid9QAUyIkIP2kVvEcnCt1d
    7MjzIfSOWcXg9dbsIZoc4Pl/PY7L2cUAe6YPDB+0aL/Zx6biqAXw6FtDbV8EmHfjqyz7xl
    J6W21Nflen2Z7QeueBJBHrbJWTDVpFs78CjL7EEFactwScrmXpliOwBhVj+X/KSdWbnH4j
    dK8VVEJP0AGePaDhut8pji95e0QWjnlE0gu5kKMEThRLwxi7wXj0UWQ6MXAA
X-ME-Proxy: <xmx:Nk9zaosIp9xnMxZjWSuZpYKVtlHKKtPS3MtQb6fXfy7R2U0ZUM4sBQ>
    <xmx:Nk9zailCBaSlXeaqVRRvrQDTjeQxAnJ-liw5HVoISSILhOO12DuRfg>
    <xmx:Nk9zaixbdh_D9_eYwmV-E6gLsCt3IfiVVhwMoYkbhiRrfyTB6wEMsA>
    <xmx:Nk9zasOhF0b_u3hntbVlOW3sm9SSXUx5WKnma_3s8FGtepxll8FR0w>
    <xmx:Nk9zakDbBMykPr7VjR0HdarW5M141sQIptpcQFx-SmJYNSrI8SREwDEH>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 02/13] CI: Reduce timeout on test failure
Date: Wed,  5 Aug 2026 16:55:30 +0200
Message-ID: <a61efbd50844b2c3084182faa73d629d45250575.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785941816-1FCCD77B-1F28CA92/0/0
X-purgate-type: clean
X-purgate-size: 1357

Tests can specify two expressions to look for:
- PASSED variable: what to look for in a successful test
- LOG_MSG variable: what marks end of test execution (regardless of the
  result)

If the latter is found, do not wait full timeout for the former one
(which will never be found in a failed test), but check for it with a
short timeout instead. In a successful test it's supposed to be in the
expect's buffer already, and in a failed test it will never arrive.

This should reduce waiting time in case of a failed test.

Note the other case (when PASSED is found first), the timeout should not
be reduced, as test may execute some more after determining the result
(for example it may collect logs for uploading).

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/scripts/console.exp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/scripts/console.exp b/automation/scripts/console.exp
index e27886bbef23..d65f840a315e 100755
--- a/automation/scripts/console.exp
+++ b/automation/scripts/console.exp
@@ -65,6 +65,7 @@ if {[info exists env(LOG_MSG)]} {
             exit 0
         }
         -notransfer -re "$env(LOG_MSG)" {
+            set timeout 10
             expect -re "$env(PASSED)"
             exit 0
         }
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383603.1626895 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3F-0001XK-IH; Wed, 05 Aug 2026 14:57:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383603.1626895; Wed, 05 Aug 2026 14:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3F-0001XD-Ee; Wed, 05 Aug 2026 14:57:01 +0000
Received: by outflank-mailman (input) for mailman id 1383603;
 Wed, 05 Aug 2026 14:57:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3E-0001JE-BI
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3D-004zD5-OO
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:56:59 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f20-e002-0a2a0a5209dd-0a2a4503d7c8-44
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:59 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f3a-fae8-0a2a45030019-ca0c7c98b99b-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:56:59 +0200
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 566847A0036;
 Wed,  5 Aug 2026 10:56:58 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-02.internal (MEProxy); Wed, 05 Aug 2026 10:56:58 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:56:57 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941818; x=1786028218; bh=NSW54GHtEO
	i9vl/a/xrx8zk65+87yD71z/uJn8Y/c8o=; b=kfGpXYhitUAtm/97ggczMUjKHR
	cgK1XTo6Z6e4pal2s0rAge7tokSNEkEkrtnJnW+5LRx1GWkcBRvnKDT/pMfXdYIZ
	69qYIQ8M2prpIbXdKYkc3DxT8ZW7QLkhMpo2TiUc7487EV1q98mS0B2t2TH8qcZh
	CQU6kyf0IMhiGcJbML3SmLHxuQT2Fm2P//4y0m7AfvOIrWv1H1FF4bCNCWUdkeqp
	IKXU7zcV0IVa3H5xndaus7KrNj8TDBWCewQ95McrT8BfPsm3Lm2uAjJyCkkWMsVe
	d5e3ZUvULGQvb+FV4k769EsGKNAbW2Lg9Ktjlnt4G97/o4vG0BNYh6tN/vpg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941818; x=
	1786028218; bh=NSW54GHtEOi9vl/a/xrx8zk65+87yD71z/uJn8Y/c8o=; b=C
	Ba/F9bnraC1AP1UnFxXLMQKuEzKuMnYM6J7Vr0nFUu6HeErboBGiSjFTqKBEtQaI
	Rhqa/Z6PgJAy7r6BYzt+vmFlEOp4dXdn5KA6sWvd2Cuyn2RJ+reNpche5oksZiyD
	5WOK991pl55bHe9UYvh01N4SODZ0Yndwg6+rOPB2CpKFAoITpvOZhuQEMNRVNlyX
	/rnxz65q3AIzRguLcvIELeEFaLEsCuan7+ih30XYnUpLNVEPLnwFNlpDAxnYX+A3
	OzS1s4F4YD8j70q+se3R3eJhWRGFUaNTuEJroUXSjxmAYU2gI7TtlazbRzYC2SVb
	0W3yA5PRnwuODrespeQWQ==
X-ME-Sender: <xms:Ok9zauMV3JtiHCGDozRbfo-vEWVHTFwWrTQ5QRYH09ykAGsN3YZllA>
    <xme:Ok9zaj0q0DqmnJ-AH9wfFHgn4A60QuFAm7nzcenmPpeeO0zNZAj77UqWjcaVjD-62
    jS6LLHDY2ohQFnMMyrD1TeVM7sNa16CwQ8-faaYhAwxKTIWNYY>
X-ME-Received: <xmr:Ok9zatlc44myDWJCmomaAzVWxcLJP0NH3h_9bqBYQQXnggWOB-HiJwWQsVYW4md3Sm_rk82Fs-GN79OmNINIF5Yz9UvyYiz-45vy6Yaej0Q>
X-ME-Proxy-Cause: dmFkZTEdkvLxT+7ERUoKSapa1INrusQu2FZX/o9rqRP1XBK15rAw70yPydcC3NfqbA6Lrf
    4puMmK5txEfuISPRuXWjpSCdsSeR+ufxTsazl6IC22b0hWJX0iKN7KSwQVuS2VSUUDH+Dj
    2vVw9VAwzNzcOOEo/3GzaHvePPom9QgwnkPOERV+gliyvt2NHofrpPdQOkhW49z8fC8cgn
    6kDdLCqxJkQ6dXm9LDBL8Zi+6SnAUc+9mUiuLRAzS1mwJNsan9xrkGOxbXhqopJIC+MZM1
    sAWmGCMwjHA49BcUskgsz4gguRIIl/ww8SE206Z0mStY/oUSsgfAxoS44sAUZllLWOs9dw
    TEDio0/XVTjbPYzt9Hux7zQESi9grPIq2OpQ0g+s41ZnxOnsEwBHOkjLzSSH8KYVzrLtNs
    QHgkT1s8qVUet1Kh70b40AQ5DhcwrtIYchkPCaZ2fDCIXDfV7ktrcFAkpSseEOvzTTb8F7
    u+CMpnE1HWGjtzIrFhoiTgJ6rsGLOPkOklpm5SrTMQwSx3l3l2W12/Nh0G1EYeaN6yTeux
    T0iyTBqwSBlVzHNXnNH0N2f37Sk9cnwvBowhLnmsf7ytoIxwsR1TFrd6meSVvb+hRMFAGm
    o48p8yXGwFJF8gGJAkLFmrXnExpfJU4Mce1TEXFi2SBH80uc00zZGFUZU7wg
X-ME-Proxy: <xmx:Ok9zaqWo5kbErH66I0uTPNPrnNQcWfFFjEE9xa1bfGAiSWfQGhkrkA>
    <xmx:Ok9zajvJ6y4RI3b4qZT9DBoh86pPqEHq2D-xJPLvEhPbXAbFTBKg7A>
    <xmx:Ok9zatYJkIH9Q1Rk2pgOQZylsKB4Bya9gzq3pZ9WZWzrmkkNB7ZpXA>
    <xmx:Ok9zaiW8q47IZjbKDMpFwCl1uycia2n_bViHwfMuRCKVXkF-WLtIhw>
    <xmx:Ok9zaqrA4voqnuvbp2jm_v-OILw77FpjTaj5yyaGkEMn47vEbaGWZSN7>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Doug Goldstein <cardoe@cardoe.com>
Subject: [PATCH v5 04/13] CI: Add configure --enable-systemd for full build
Date: Wed,  5 Aug 2026 16:55:32 +0200
Message-ID: <b1ef91e0b72c83b0f5567a57c991d61ebd846f2c.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785941819-6E6CE4E9-A4A274D6/0/0
X-purgate-type: clean
X-purgate-size: 889

This doesn't exclude sysvinit scripts, but allows testing systemd too.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
--
Changes in v4:
- drop systemd-dev, add --enable-systemd always
Changes in v3:
- switch to trixie

New in v2.
---
 automation/scripts/build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/automation/scripts/build b/automation/scripts/build
index bdaab11c3722..33de967c4b9b 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -59,6 +59,7 @@ else
     # Full build.  Figure out our ./configure options
     cfgargs=("--prefix=/usr")
     cfgargs+=("--enable-docs")
+    cfgargs+=("--enable-systemd")
 
     # booleans for which compiler is in use
     cc_is_gcc="$($cc --version | grep -q gcc && echo "y" || :)"
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383606.1626922 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3K-0002HS-DL; Wed, 05 Aug 2026 14:57:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383606.1626922; Wed, 05 Aug 2026 14:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3K-0002HD-8I; Wed, 05 Aug 2026 14:57:06 +0000
Received: by outflank-mailman (input) for mailman id 1383606;
 Wed, 05 Aug 2026 14:57:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3J-00020K-4a
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3I-00Cdrb-HA
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:04 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f34-5cb7-0a2a0a5109dd-0a2a45098958-38
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:04 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f3f-be1a-0a2a45090019-ca0c7c98c8ef-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:04 +0200
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 1BECE7A008E;
 Wed,  5 Aug 2026 10:57:03 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Wed, 05 Aug 2026 10:57:03 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:01 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941822; x=1786028222; bh=D4TMGAPIXT
	KE8KLggURHTOvWsEJPhlI6eLx2c1m5BIU=; b=ohubngivkCKQVuc545HNXHpP6/
	+s7e7NmX1I7isyjFwEj/Q3mdwiG95YuM6Y10dWhnVoP+67rxgOK6rrkEPP1xM4r7
	GtVuLWk5fhet6HReTwVjb/6/i4eI0Y5ymga4qWHMYNEq2PcILh9r3/hREX6IZsM4
	owpyy38F3LN2dIHxGxN6/55PXZbSAqBjrAiHmohqYhTY0oZECAgA7iDkyNZEzugZ
	nTF48K3cY/OCs6GgRtGR7avVu18fOn9cpJNKg5lnijXRxM7NroXYCthtFsxkDsWR
	Ja53xMXfJIbRi4z8UpzUP1qlb/SvqwdXZ8DKx/VEWFoqAg2AmUsejltqnEwg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941822; x=
	1786028222; bh=D4TMGAPIXTKE8KLggURHTOvWsEJPhlI6eLx2c1m5BIU=; b=j
	0avhJJQ/IsdWWu4NSI5uVM1bY2HUiFuofzythMYdIKrKimDXtDO2JYvaxKv8KM0Y
	XpJK5PSyxLiTCNXdGuR5E9Pu0c3RFT+Nwc69kyN2Z8tZ8NGEALwnPttL4rjKLZRG
	gey0vQr5k6Zfa48Ku+juoueSQvY1fVOiolezkGnzXJQjlCP3WeK2l2syBCJdGdh7
	RXveyDn50m3JDeOHOyNZsZONNmQTfLdHdAWZa7XEnP/zVlWnx/0iZ07dbUPZBWjj
	mp6b9O74gXGmDskT2hS3nAiMQPYPFqqM3mytToTuO/Ej5q7y8/luDlUnf3sx0BaN
	qzWrJL/yTN+em/aqcU5Sw==
X-ME-Sender: <xms:Pk9zaqa7Cwfw8o6U4qNx-k2xs7GusK84OZL5aPIe7NW0LbqLU5JqSw>
    <xme:Pk9zakTwypYBoTu1Fw7Gu4EopRrJkXmV4UJrTJ4U-1OEQ0YSItGcEW0d8bfFTuAvV
    q8bwrg_agGO6n0sWQaQdxPG8dLc275OJEX-6_7bvFxKxnq1sUU>
X-ME-Received: <xmr:Pk9zatT3B6JGKmWgoQIh1cnA494i1iIB6QJ5l50r6SeZHiru-Z45BEOCIzB0iAhIRsJaC5wPaDK6lrd_lP8zEo0wp4doX4desJ17zKBaAUk>
X-ME-Proxy-Cause: dmFkZTFg5HWH/RDqdPpR88i/6M1gtPWzLlXDm7puE44YW+OQRkCu0ypR/9JOPRDl1te3/p
    2ugUGdWUlQb8kocRthjZN7vvr6IWWNFcyKYmBFPe+BzKMnxGjKoBahL5VCHV3UAfs0EHAg
    nj3sYoDmr7GyZbFXABfsR3rbdQAxCafinJpMUI+6VqMVy7guc3dUP2M2goerpX03cWT8GB
    3tIsn5JiFR3GjgHhPz/r2yz7V7NDg477JFOnzakkhw9w+L8/GP2qYPPRO39CHuug0G7Ubo
    N42GUSC5i0XOiRx9MufeivVdVi29Q812Jc2LJ90UxPjSbThjlODlkTjM/Zl+lF8/E+2ajc
    I8e4yupEnk/I7m2P4LYPmY0lkBVs/oS6MiW8d+RZvksuW60ckAKttxjQebuSBcn7dNi7zi
    yYUrIntPstk/r96xUMuBjLaSpqpyqEEs81sxL765Hj2yE87S2VasrSZ305//Rm33ZjBu67
    CjL5KLoeHME7mHkfB6nCh3KfETG7004vHb5/bFGf+uL1iTatYcZPuaGwv+/tMFetoYKKK5
    u09P80XM9rJeJmjAhV0kZXFfAAUi4DQapWwdZTL0RTsTzTip+6WBQP0TEyqW7eK8iLrrIy
    hGRZ7ERl7bZVEesG8E+pvrbEmezSJaujXl8NHBlD6uQQf4yKBXgoopxhw11g
X-ME-Proxy: <xmx:Pk9zaoQnHvt_eYTdxFZMRJ0TYANlTS1a-HDdTED2j8VZAXTpx7Z5qA>
    <xmx:Pk9zai4oHR5j3plZ_VUh7F0rG6B-s0CsioVssMqhK7Tl6fa5JY-Xhw>
    <xmx:Pk9zak3J5_aeqAnRLkH8phD5T98NUedISDwDLOCC9D-Rk4JoYXiHZQ>
    <xmx:Pk9zatArwQ6gybkAw5rRM6XdqvkPkCEAfgBlyoOhMIjxS29-4gCzSA>
    <xmx:Pk9zakEzxyWM0tTBK5JLs8tPCtY5wklfZjKg8mIbiw_GaxW5Erat_rGw>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 07/13] CI: add a smoke test for UKI xen.efi
Date: Wed,  5 Aug 2026 16:55:35 +0200
Message-ID: <bdb2ef7b0a351687f6c160e7e244e0d757726b8b.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785941824-BE8D9034-63D63DDD/0/0
X-purgate-type: clean
X-purgate-size: 3267

Combine xen.efi test with alpine smoke test. This one should not use
XTF, as having initrd is an important part of the test.
The command to build UKI is constructed based on the documentation.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5

The documentation says to put extra sections after .pad section, but I
don't see it anymore...
---
 automation/gitlab-ci/test.yaml                  |  8 ++-
 automation/scripts/qemu-smoke-x86-64-efi-uki.sh | 62 ++++++++++++++++++-
 2 files changed, 70 insertions(+)
 create mode 100755 automation/scripts/qemu-smoke-x86-64-efi-uki.sh

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 184cf9b47d46..8e2db8c33528 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -804,6 +804,14 @@ qemu-xtf-argo-x86_64-gcc-debug:
   needs:
     - alpine-3.24-x86_64-gcc-debug
 
+qemu-smoke-x86-64-gcc-efi-uki:
+  extends: .qemu-smoke-x86_64
+  script:
+    - ./automation/scripts/qemu-smoke-x86-64-efi-uki.sh pv 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86_64-test-needs
+    - alpine-3.24-x86_64-gcc-debug
+
 qemu-smoke-riscv64-gcc:
   extends: .qemu-riscv64
   script:
diff --git a/automation/scripts/qemu-smoke-x86-64-efi-uki.sh b/automation/scripts/qemu-smoke-x86-64-efi-uki.sh
new file mode 100755
index 000000000000..8275dd1a81b3
--- /dev/null
+++ b/automation/scripts/qemu-smoke-x86-64-efi-uki.sh
@@ -0,0 +1,62 @@
+#!/bin/bash
+
+set -ex -o pipefail
+
+. "$(dirname "$0")"/qemu-alpine-lib.sh
+
+cd binaries
+build_domU
+build_dom0
+
+# variant should be either pv or pvh
+variant=$1
+
+case $variant in
+    pvh) extra="dom0-iommu=none dom0=pvh" ;;
+    pv)  extra= ;;
+    *)   echo "Unknown test variant!" >&2; exit 2;;
+esac
+
+mkdir -p boot-esp/EFI/BOOT
+
+cat > xen.cfg <<EOF
+[global]
+default=test
+
+[test]
+options=loglvl=all console=com1 noreboot console_timestamps=boot $extra
+kernel=kernel console=hvc0
+EOF
+
+vma=$(objdump -h xen.efi \
+    | perl -ane 'if (/\..*/) { $vma=hex($F[2]) + hex($F[3]) }
+    END { printf "0x%016x\n", ($vma + 0xfff) & ~0xfff }')
+
+objcopy \
+    --add-section .config=xen.cfg \
+    --change-section-vma .config=$vma \
+    --add-section .kernel=bzImage \
+    --change-section-vma .kernel=$(( $vma + 0x100000 )) \
+    --add-section .ramdisk=dom0-rootfs.cpio.gz \
+    --change-section-vma .ramdisk=$(( $vma + 0x2000000 )) \
+    xen.efi \
+    boot-esp/EFI/BOOT/BOOTX64.EFI
+
+cp /usr/share/OVMF/OVMF_CODE_4M.fd OVMF_CODE.fd
+cp /usr/share/OVMF/OVMF_VARS_4M.fd OVMF_VARS.fd
+
+rm -f smoke.serial
+export TEST_CMD="qemu-system-x86_64 -nographic -M q35,kernel-irqchip=split \
+        -drive if=pflash,format=raw,readonly=on,file=OVMF_CODE.fd \
+        -drive if=pflash,format=raw,file=OVMF_VARS.fd \
+        -device virtio-net-pci,netdev=n0 \
+        -netdev user,id=n0 \
+        -drive file=fat:rw:boot-esp,media=disk,index=0,format=raw \
+        -m 1024 -monitor none -serial stdio"
+
+export TEST_LOG="smoke.serial"
+export BOOT_MSG="Latest ChangeSet: "
+export PASSED="Welcome to Alpine"
+
+../automation/scripts/console.exp | sed 's/\r\+$//'
+
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383608.1626931 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3L-0002Y6-RY; Wed, 05 Aug 2026 14:57:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383608.1626931; Wed, 05 Aug 2026 14:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3L-0002Xl-Nj; Wed, 05 Aug 2026 14:57:07 +0000
Received: by outflank-mailman (input) for mailman id 1383608;
 Wed, 05 Aug 2026 14:57:06 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3K-0002Kl-Q5
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3K-00A5Sr-6T
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:06 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f41-bab6-0a2a0a5309dd-0a2a4506aaa0-4
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:06 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f41-195a-0a2a45060019-ca0c7c98ac8f-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:05 +0200
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfhigh.stl.internal (Postfix) with ESMTP id A90017A00C0;
 Wed,  5 Aug 2026 10:57:04 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Wed, 05 Aug 2026 10:57:04 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:03 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941824; x=1786028224; bh=llNtFQlQYr
	7PILGy+20tguUtKJuL+FX+u1XXE52nbb0=; b=wu9hYmcLMZxkhllF1qZl+f4epq
	OXOA0ZcpGU1OFgPjGHtqevarlAzDzWlyL1R/66KONJop+0o3BadnQjMwo7fVdAyZ
	xOVYO0b1KDiVqHs/qpbEcC2pOrpTm3XIlBIqEsICnzeoJshqpcdYXeS7lRGljtta
	Rjpl6QMclcERy4+QBr1KcKuLBjtyZJ8Blm/9zJ0Cz3OxEhJXX09eOErdNM33BrAN
	bmnl6LYyfYSOhPWmSYkgMKbzqqt5MTBrhV+LNt/sOrUwJzeduuJFQaSlFqit9Pze
	VQeuUYjvL30iW9A4I1yeelnitZMut5MHW+rekHRZ6aeKtogjzSk0qYJWJz8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941824; x=
	1786028224; bh=llNtFQlQYr7PILGy+20tguUtKJuL+FX+u1XXE52nbb0=; b=O
	HpOn8zBtsjG1XTpVSXWn8hCHW0f5fb67Y/D1+Mcd2E6EiVIJ8scIGiDtOvMqPaLs
	tmQ7mEPHunYsWJAQl5TAdeT658WUmHLrPx9+di9K5kEUu+nbOvo/hJPS6B+HeA3+
	rQHjwVl+fNCrhrwkSvlJTgXhBSCZOh7b9PEza1ETkWJtG+uidWIaKhVNRP+qXznj
	S99Tc504t5C5LjMXW1Sl6XYb81KKboQLKMSbax0TKHLsCePvKE7PNyjZAfpe4bfM
	bHbczxDnmQ/ndZFfexZ5zrK5ToQITgBey9svvCEoKAhy1Qou/qAyt24mwyiYn+Dj
	5+NEpx4oL4NPLfFbIYncw==
X-ME-Sender: <xms:QE9zallsdyVKT2X0xJjrEQ9UtrFNDs3LrEQzuF3WgXtfcQaxW_wUSg>
    <xme:QE9zanv-aWqgTkQf2ax6xIXdokCJO6XBw88eRUY-10HxCgWH-GeeMMpPitUSsj31A
    k5gc29nCgCV9Bhtcq2KkQiZi9-9yNzVBRI7t9kXpTGjvlKOrVw>
X-ME-Received: <xmr:QE9zaj9vOnDIjoRn3cd6onNGHoby_KmWM_w0NMyYxlkzuERGVBXPJveTQ9g73oyB6KqkWtqmJGg6no7i8zt00NiLx5ajUhGnAsDugUoUKlM>
X-ME-Proxy-Cause: dmFkZTFg5HWH/RDqdPpR88i/6M1gtPWzLlXDm7puE44YW+OQRkCu0ypR/9JOPRDl1te3/p
    2ugUGdWUlQb8kocRthjZN7vvr6IWWNFcyKYmBFPe+BzKMnxGjKoBahL5VCHV3UAfs0EHAg
    nj3sYoDmr7GyZbFXABfsR3rbdQAxCafinJpMUI+6VqMVy7guc3dUP2M2goerpX03cWT8GB
    3tIsn5JiFR3GjgHhPz/r2yz7V7NDg477JFOnzakkhw9w+L8/GP2qYPPRO39CHuug0G7Ubo
    N42GUSC5i0XOiRx9MufeivVdVi29Q812Jc2LJ90UxPjSbThjlODlkTjM/Zl+lF8/E+2aG7
    aOyEBHoV8EgKgIvYVDmRxD7FYtA8R9JSO6Q6iTa1qhDfTedO6kcBPv2Zc7fFOGSBjVj4If
    EK9LBVBNO+tASBhg/3jgvdFnTHv19oF8tdtHz6iY9gcgZoN0LEy0UNhXaFqQ1lGv6zx5mk
    InjPTLPm44ggMAKBkGvYFgISlyb9HnoK0/6OxJTDDH0bSp36V0YHYUhP6qsYkx+ThWQPjs
    i854as250OH2ovH2HZgWjrxZ4rlm+uOXYtWtzCHg4aIMg5rOrLyZLUb/TpArYrI1PyO8VG
    seLT7bP+LnHOfcaE0JRpOnagI6j9WEgu3HoBCJFAQXGYJj5OjjqOWpwfEsoA
X-ME-Proxy: <xmx:QE9zahMiif7_80k1JeSpE5_NJXYrmjnQ1BaZaBjsUEbhyylv8MD7Yw>
    <xmx:QE9zahFRmq1BKSLKe_LdJ8AAl2S4iMlGl7GzW1_xrHibOrvoXKIUgw>
    <xmx:QE9zavQjMg30q-sS8cQszvZIs_TQ70IbNGNClARmVLS89Pbma_zHyQ>
    <xmx:QE9zauvOz72dWIUamRzp8GYeeTVGx2MlLjdAosaF30o6UnS9PkSFYg>
    <xmx:QE9zagh70fA4Bv4ymp3WmH2jEpyBIVKNs5463Hwy6BJ1gp01OZ39jYC0>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 08/13] CI: add tests booting UKI via grub
Date: Wed,  5 Aug 2026 16:55:36 +0200
Message-ID: <8f7e40b5f544677321d994fa6168e2090333635a.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1785941826-F6A7477B-7C654A22/0/0
X-purgate-type: clean
X-purgate-size: 3746

Test booting unified xen.efi via grub. The new test (grub2-pv) simply
loads the same xen.efi as the earlier test but via Grub's "chainloader"
command. In theory it should be the same as loading it directly from
firmware, but practice shows there are some corner cases sometimes
(especially before calling ExitBootServices).

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5

Needs containers rebuild
---
 automation/build/debian/13-x86_64.dockerfile    |  1 +-
 automation/gitlab-ci/test.yaml                  |  8 ++++-
 automation/scripts/qemu-smoke-x86-64-efi-uki.sh | 36 ++++++++++++++++--
 3 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/automation/build/debian/13-x86_64.dockerfile b/automation/build/debian/13-x86_64.dockerfile
index 8a36774f1155..3ae1d27fb257 100644
--- a/automation/build/debian/13-x86_64.dockerfile
+++ b/automation/build/debian/13-x86_64.dockerfile
@@ -59,6 +59,7 @@ RUN <<EOF
         e2fsprogs
         expect
         fakeroot
+        grub-efi
         ovmf
         qemu-system-x86
         systemctl
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 8e2db8c33528..1359d70ff2b4 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -812,6 +812,14 @@ qemu-smoke-x86-64-gcc-efi-uki:
     - *x86_64-test-needs
     - alpine-3.24-x86_64-gcc-debug
 
+qemu-smoke-x86-64-gcc-efi-uki-grub:
+  extends: .qemu-smoke-x86_64
+  script:
+    - ./automation/scripts/qemu-smoke-x86-64-efi-uki.sh grub2-pv 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86_64-test-needs
+    - alpine-3.24-x86_64-gcc-debug
+
 qemu-smoke-riscv64-gcc:
   extends: .qemu-riscv64
   script:
diff --git a/automation/scripts/qemu-smoke-x86-64-efi-uki.sh b/automation/scripts/qemu-smoke-x86-64-efi-uki.sh
index 8275dd1a81b3..82702fdcb682 100755
--- a/automation/scripts/qemu-smoke-x86-64-efi-uki.sh
+++ b/automation/scripts/qemu-smoke-x86-64-efi-uki.sh
@@ -11,9 +11,14 @@ build_dom0
 # variant should be either pv or pvh
 variant=$1
 
+extra=
+grub2_chain=false
+grub2_linux=false
+
 case $variant in
     pvh) extra="dom0-iommu=none dom0=pvh" ;;
     pv)  extra= ;;
+    grub2-pv) grub2_chain=true; extra= ;;
     *)   echo "Unknown test variant!" >&2; exit 2;;
 esac
 
@@ -32,15 +37,40 @@ vma=$(objdump -h xen.efi \
     | perl -ane 'if (/\..*/) { $vma=hex($F[2]) + hex($F[3]) }
     END { printf "0x%016x\n", ($vma + 0xfff) & ~0xfff }')
 
+UKI_PATH=boot-esp/EFI/BOOT/BOOTX64.EFI
+ramdisk_section=(
+    --add-section .ramdisk=dom0-rootfs.cpio.gz
+    --change-section-vma .ramdisk=$(( $vma + 0x2000000 ))
+)
+if $grub2_chain; then
+    grub-mkimage \
+        -p /EFI/BOOT \
+        -O x86_64-efi \
+        -o boot-esp/EFI/BOOT/BOOTX64.EFI \
+        chain \
+        ext2 \
+        fat \
+        linux \
+        normal \
+        part_gpt \
+        part_msdos
+    if $grub2_chain; then
+        echo "chainloader /EFI/BOOT/xen.efi" > boot-esp/EFI/BOOT/grub.cfg
+        echo "boot" >> boot-esp/EFI/BOOT/grub.cfg
+        UKI_PATH=boot-esp/EFI/BOOT/xen.efi
+    fi
+fi
+
 objcopy \
     --add-section .config=xen.cfg \
     --change-section-vma .config=$vma \
     --add-section .kernel=bzImage \
     --change-section-vma .kernel=$(( $vma + 0x100000 )) \
-    --add-section .ramdisk=dom0-rootfs.cpio.gz \
-    --change-section-vma .ramdisk=$(( $vma + 0x2000000 )) \
+    "${ramdisk_section[@]}" \
     xen.efi \
-    boot-esp/EFI/BOOT/BOOTX64.EFI
+    $UKI_PATH
+
+ls -l boot-esp/EFI/BOOT/ ./
 
 cp /usr/share/OVMF/OVMF_CODE_4M.fd OVMF_CODE.fd
 cp /usr/share/OVMF/OVMF_VARS_4M.fd OVMF_VARS.fd
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383610.1626940 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3Q-0002ya-3b; Wed, 05 Aug 2026 14:57:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383610.1626940; Wed, 05 Aug 2026 14:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3P-0002yN-WD; Wed, 05 Aug 2026 14:57:12 +0000
Received: by outflank-mailman (input) for mailman id 1383610;
 Wed, 05 Aug 2026 14:57:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3O-0002rq-2b
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3N-000x73-Eu
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:09 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f3c-5cb7-0a2a0a5109dd-0a2a45039e98-28
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:09 +0200
Received: from [202.12.124.150] (helo=fout-b7-smtp.messagingengine.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f42-fae8-0a2a45030019-ca0c7c96e627-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:07 +0200
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42])
 by mailfout.stl.internal (Postfix) with ESMTP id 4AC921D00189;
 Wed,  5 Aug 2026 10:57:06 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-02.internal (MEProxy); Wed, 05 Aug 2026 10:57:06 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:05 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941826; x=1786028226; bh=Tk4FR3C+E8
	hj+04G0aqKUyY5BojG7M7wHi0BRJd3Wo8=; b=G6krjpI5q0lTW24JoT4zzJ3MLZ
	RMuG55LpdTKldC13FOHL9wy9RlCsDGBa9XfgwKDX4GhLVIySMXp8K0kwsc9x66Vx
	4Qovm83h3h3UaUyyGWSCdfkPM2/x+f34qUMgd+Gj1WK56ms/JVPDXhJB4MtFuv/w
	+pyUKrtKKfksjwhZmGQ4pDdWPSWcjHydoIisRs+OBAfmIHjs5ijSaN9UG3/7BIR1
	HlAZ3z/fK4wjwCjqgb3XVYeJHd7lNSq/ikY72AA7WWIyJnfU0SljMGT92gxAQ0qG
	aH6cJSY7AYtf5yTK45PocUDvUFn6jf7WGm2zbG7xcrGn30t08xfyKXSQw2+Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941826; x=
	1786028226; bh=Tk4FR3C+E8hj+04G0aqKUyY5BojG7M7wHi0BRJd3Wo8=; b=k
	SHS+j/4qg/4/oH+J3qjJIBKwahI+Dn132DNHzhYvh4XvcKIJOAYYanbzPaNr7R82
	V9d4avt94PdTj9CaEMjnSrVH2B9SQsqIcyzU+yuBGHTCYly/SG5l0lUn5cXSEFy7
	bXx+R1bk1OmXKoCIKX1/iOa9PSX4hCycBieGZOamOFH9g5jxOUV+bN0sCvpVGiNb
	yWNmgP4rTRD05FG0LCkdAKj9uN2awxazvyYvFteA+AuibL1Ug/9YER9vSXG1x1BP
	DKJpHt0y8sdJIzS6LerfZMOKYzXjmlWc5jUxyg/X/U3nMicZurq1la3i175m6Xu/
	6Ki7cgj537Cf6ikyKRNoA==
X-ME-Sender: <xms:Qk9zapaaJ_k-kjYs4ORQ420YH7_gQHI2eZPzPOY7MaH8wWRZbNfNpg>
    <xme:Qk9zanR8NFwAjx4jvGEbmeBuOelHDv0k282uxgg0qv4iwEa2YJ9_fSxkzH4LKKrRV
    eeaF4JLIUHkehkgsb34uv5EILnAmzGyYNi7254ocZHRg1SM5kw>
X-ME-Received: <xmr:Qk9zakTIK2DxGyeH_4jWn06olPxIFdfItbyqDFid7_BRGo4SJWzf_3JeaVQNteR9T4VFV2CvEqzqls9Ywuf2hKyBaEefz0fuE-Q6lpXbqz4>
X-ME-Proxy-Cause: dmFkZTEdkvLxT+7ERUoKSapa1INrusQu2FZX/o9rqRP1XBK15rAw70yPydcC3NfqbA6Lrf
    4puMmK5txEfuISPRuXWjpSCdsSeR+ufxTsazl6IC22b0hWJX0iKN7KSwQVuS2VSUUDH+Dj
    2vVw9VAwzNzcOOEo/3GzaHvePPom9QgwnkPOERV+gliyvt2NHofrpPdQOkhW49z8fC8cgn
    6kDdLCqxJkQ6dXm9LDBL8Zi+6SnAUc+9mUiuLRAzS1mwJNsan9xrkGOxbXhqopJIC+MZM1
    sAWmGCMwjHA49BcUskgsz4gguRIIl/ww8SE206Z0mStY/oUSsgfAxoS44sAUZllLWOs9kz
    M+2EhVPXnm463WsVTR7vt8wtFsLTgkuGJDU3ThGsfCB1pIk58dNk2MnZTWkzV+0r6EyUid
    3cFDm8u+tw2qUoPfO2e2N5u2Qw9aNSNkAAPwTL+5/cpnqmIUxBSN/wNVqyEFM3dw3lYWxf
    ugbBPhIk5pay1bOoEMkySjQGW7G0pfq64fSYYFhMj+B/TphviwAtYZU2A7H4JrXOGI3X5K
    4r4H4cVIF6zKxDT2JTPWoa1dSnjrX26d7LCYUHQL5hu+aQOvDIQcp8gMJDdtogbbWF7DeL
    ms67pWOxQyuVP2bd8952TxbN9PukkDImsreqa/7F19phu12IrgywSonlJCxw
X-ME-Proxy: <xmx:Qk9zajSH4mRuk5_hC9i9ZccNvu0cP55xf82GaNLLQwDbjLwCjERoCg>
    <xmx:Qk9zah4G8mqFG1jXHAy3dp4YFP-0eJTnzrIHhSRHESIgfWTGmSopmA>
    <xmx:Qk9zan3oL6YkgS6bQMhDkkk82MIn5oDJE5b7uGx8M9t0traKFkASGQ>
    <xmx:Qk9zakCTu9wgymh0Hyx9CdpyYs3ey6VQmhJIM5rbTw5mtY1gJNVNXA>
    <xmx:Qk9zanEMSvriwlQ5KCkcVWuiG2YqPcFiS-Mn8IJV8jBC9tIxZXoPpsJK>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 09/13] CI: enable xenconsoled logging in alpine tests
Date: Wed,  5 Aug 2026 16:55:37 +0200
Message-ID: <4a2974f971922780bf571547f137f2cf7cb102cf.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785941827-74A894E9-94074D3F/0/0
X-purgate-type: clean
X-purgate-size: 741

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/scripts/qemu-alpine-lib.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/automation/scripts/qemu-alpine-lib.sh b/automation/scripts/qemu-alpine-lib.sh
index 29fdff4f562a..5221b7dec1c6 100755
--- a/automation/scripts/qemu-alpine-lib.sh
+++ b/automation/scripts/qemu-alpine-lib.sh
@@ -38,6 +38,9 @@ build_dom0() {
     mkdir -p root etc/local.d
     mv ../domU-rootfs.cpio.gz ./root
     cp ../bzImage ./root
+    mkdir -p etc/default
+    echo "XENCONSOLED_TRACE=all" >> etc/default/xencommons
+    mkdir -p var/log/xen/console
     echo "name=\"domU\"
     memory=512
     vcpus=1
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383611.1626942 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3Q-000328-Fb; Wed, 05 Aug 2026 14:57:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383611.1626942; Wed, 05 Aug 2026 14:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3Q-00031c-9d; Wed, 05 Aug 2026 14:57:12 +0000
Received: by outflank-mailman (input) for mailman id 1383611;
 Wed, 05 Aug 2026 14:57:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3O-0002sB-6t
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3N-000x73-JL
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:09 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f2b-5cb7-0a2a0a5109dd-0a2a450ab934-46
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:09 +0200
Received: from [202.12.124.150] (helo=fout-b7-smtp.messagingengine.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f44-f2d2-0a2a450a0019-ca0c7c96c8a5-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:09 +0200
Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id 2AB8D1D00112;
 Wed,  5 Aug 2026 10:57:08 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Wed, 05 Aug 2026 10:57:08 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:06 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941828; x=1786028228; bh=LtpC8kb3w5
	sylrY5i2rJ1VyunzmKl36EvEgXZscahng=; b=DOfBreqSzAaPHKanjVbGt761Tz
	+7I46fmizfbtYd/ipmbF23pZabm8ENCYjb8axvtz9za3FYMZbWc1DbEmls30jD7o
	wDEmk6wWfKLIuyT1Eqv1xNVupv2/ZDDh+nNfouU1q1d7XUt34nSjqB+mc/RCg90h
	QiJGW1BOi0gWZwgIjFdfTvtFXBEjaL6j0BhQif60z1zRFinYoKam4T2mlcvjH7bQ
	7wlEA8WUBtAUz/PfdYyzcNp3DIsna2Dv/pz0cW4nSDAKG53tk2ta998VPwL/yCMT
	ptmvm+OYNWvsRHlP1ilSzrEuX1Jr1ffDFYcV6RyFlQDttXt+NyxQ1lI2sV8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941828; x=
	1786028228; bh=LtpC8kb3w5sylrY5i2rJ1VyunzmKl36EvEgXZscahng=; b=G
	kew2zVCRVR1po7pqQgJZpxm4l2hwgtCtFk7tbQSODqKIxXSRxOCChY2ZMORaHOEv
	rk+EZyuPViReXZQ9v++AQ6H24tTvgwSYFjITtg4ZcpjLC5DQL4l3s0nxkKNOZiHx
	Tt/TAZ4tiy41CSZrj0Wpiosbg3bQ9kCthExShPFURv84Wz+k4ujA/6EiEDoCZKzC
	gT9Gs7V4MZaNVQu2Ar0yJ9sZI7mUZYUkF/qAchU194cKsYbtDwUsWwL/ti7rmuvS
	DKRntgx8DYr0NdFyQYy65jYrYKCYZnbe6XL7MdaECMSKZESo2Fm+PsfBl3K1xYHS
	0KSRopS8VsVzkj8Cqc+uA==
X-ME-Sender: <xms:Q09zarOn8K-ZHxm6KNrEuk7FuJco7C5a_GqnH52JDfg_cbgBYnyweg>
    <xme:Q09zas0fUw5SZFWO6HxZhoBx8bjYRgGrcw0tludqOMsz_wLmH0mwFISNM6QkXFRF0
    jd99RxpKImE0DbEHy-DMH6ak5FDuUiEksMaGbUdRxhlaPAsBdo>
X-ME-Received: <xmr:Q09zailLBYLQ6KgDKzhN7DwkCO7vm8VqUOAiyVbB6bUNZJC96wqzBW5_xXtH3YNSHTmr1J8k5rw1vRGRBz8wgGpCEqpdpnMRAYltXAUZfts>
X-ME-Proxy-Cause: dmFkZTEdkvLxT+7ERUoKSapa1INrusQu2FZX/o9rqRP1XBK15rAw70yPydcC3NfqbA6Lrf
    4puMmK5txEfuISPRuXWjpSCdsSeR+ufxTsazl6IC22b0hWJX0iKN7KSwQVuS2VSUUDH+Dj
    2vVw9VAwzNzcOOEo/3GzaHvePPom9QgwnkPOERV+gliyvt2NHofrpPdQOkhW49z8fC8cgn
    6kDdLCqxJkQ6dXm9LDBL8Zi+6SnAUc+9mUiuLRAzS1mwJNsan9xrkGOxbXhqopJIC+MZM1
    sAWmGCMwjHA49BcUskgsz4gguRIIl/ww8SE206Z0mStY/oUSsgfAxoS44sAUZllLWOs9ru
    v6SOT6ZGZq9hSagMNqMTFH8vdp6O/L5MrKzNDDi7nZLfVHJsioFEZTYyrXxjaY/AwAcAlk
    sXVAUjeaSNfQZbrzwtHrtgNuvYYSuP702NMIGsM/SNmdqTWhEkrct047Su+Bt5rTagGiiH
    gYUh30QkTBM+AxtRjABy1cfA/LferyWxei/VMJjU2wdPn1D6MkFvc0ewdrcPYb4+xgM4es
    RphFaJmrrBphLIWscDorA2sk5T7AlgsctwlQStyRrflabZGWm0q+dMBK0+/JZwY84IkGPG
    NrZ9G38eWZ3VJ2R4zC6vg4/QMeU4BIrD8fIg8DV4x2NNOlEVpFStkfN25FSQ
X-ME-Proxy: <xmx:Q09zarUANXvfAraOUM78xk_NsEaL4cuKcA1TmiPLpLfG4J7cNjl2VQ>
    <xmx:Q09zaguoJeZNdQtxZA4dRGohwykNGOV0K6i6bHWeOsrl75Llmlw4OQ>
    <xmx:Q09zambIIkvuctyQDfUR2suMibn8bVqga3NXEgXdOnEhWNVuQiVE1g>
    <xmx:Q09zanU_HMaGSLhiN7QnaAfwKYVnynD0XP-drBPW90CjwZGQElthHA>
    <xmx:RE9zajqNBx8f7Tfciy_o89m1NsZ01MbwghYxWy2fcRDM5ccwXV5IiSF_>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 10/13] CI: add oops=panic to smoke tests
Date: Wed,  5 Aug 2026 16:55:38 +0200
Message-ID: <c6b50a72b933ce2ee3e5c35e8fb808cb1496dd9a.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785941829-59BC0CFC-9A336D88/0/0
X-purgate-type: clean
X-purgate-size: 783

Make it easier to detect failures.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/scripts/qemu-alpine-lib.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/scripts/qemu-alpine-lib.sh b/automation/scripts/qemu-alpine-lib.sh
index 5221b7dec1c6..2d306f384f6f 100755
--- a/automation/scripts/qemu-alpine-lib.sh
+++ b/automation/scripts/qemu-alpine-lib.sh
@@ -46,7 +46,7 @@ build_dom0() {
     vcpus=1
     kernel=\"/root/bzImage\"
     ramdisk=\"/root/domU-rootfs.cpio.gz\"
-    extra=\"console=hvc0 root=/dev/ram0 rdinit=/bin/sh\"
+    extra=\"console=hvc0 root=/dev/ram0 rdinit=/bin/sh oops=panic\"
     " > root/domU.cfg
     echo "#!/bin/bash
 
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383615.1626957 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3S-0003b0-Ty; Wed, 05 Aug 2026 14:57:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383615.1626957; Wed, 05 Aug 2026 14:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3S-0003aQ-Pd; Wed, 05 Aug 2026 14:57:14 +0000
Received: by outflank-mailman (input) for mailman id 1383615;
 Wed, 05 Aug 2026 14:57:13 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3R-0003Du-BJ
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3Q-000x73-Ns
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:12 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f3c-5cb7-0a2a0a5109dd-0a2a45039e98-32
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:12 +0200
Received: from [202.12.124.152] (helo=fhigh-b1-smtp.messagingengine.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f47-fae8-0a2a45030019-ca0c7c98d795-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:12 +0200
Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 51A607A0036;
 Wed,  5 Aug 2026 10:57:11 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Wed, 05 Aug 2026 10:57:11 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:10 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941831; x=1786028231; bh=AtMWHKAIdG
	HRUVSdbCNClD81EvWMYyNJcMteHXAqTCA=; b=RlYV4alhVoFuXVE3Pd+sGcU+Fb
	SBq1fqrKR0MkQO7u2XaYtffJyWv3jnM2u9CyqP02qe9Pz9V4KsYP3U+mxk7Y/Q/F
	S0vqkWSXnYtaLtDJbjaSltW5mlQ/rXWlVbINAwnilVM1TGHhu56yx3oGCpF4h1n1
	m5LWkVwzc+eC0D3jtayoog5RJOEwE6B7jP6iqw0+3QcYYUYBTLKy7kWeoUt7Bz8i
	hwxDK87NQjBHjpsLUQatZBbMbHEIiSnIl/nVDLextekJj1Csb21yZnAsxRmTzKy6
	FpQJBNFE9ByE+S5xEAhjqfGBx2xhzUXQdv1rycB8KOBKbYo0OIgNLUQ0KXsQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941831; x=
	1786028231; bh=AtMWHKAIdGHRUVSdbCNClD81EvWMYyNJcMteHXAqTCA=; b=e
	IzWCS7WjIFceauE0YnCvNqNc9jT4CcUExCcULOwUEKXMzouNxiwEeqHmSI+SjqGb
	3DZ6PEFMTuz+ynNv2KfZaeFbC4aIeu+1ORpTXHTNAd6+axQBYXKiCdE3RVIYv3cn
	pqbzaahjplYX3rE4PZ6nMVW+ag/qI8AYa34YXvSHvVmQDNK6lKeEnPeUPMQQ95O4
	1Jf+FTOQ46J/TiXz6J8CKlr0RWk+H1XWLMlsbnFfcfYx2PfFHuyVOSNy92Z4RNzA
	F7gf8abr9b99hhrnP1zK+6PVc/t6nWENxI2pDpgnFYcSCTnhHhbAVESS5FkX+IS1
	0Nr3OCeg2bOlhPok2f3cA==
X-ME-Sender: <xms:R09zarE5_mWbsl2I1p_GMdt5Bg82F04TujgOxVxevX-bCn2bmpBZ2g>
    <xme:R09zavN8bJ3opn-cab1eW9RFxc2ir1R9ICxtarfozqdZLXRbVDaHvJH5CCwzuo-q5
    j1aboBpMRRqp0te-m3SF5YYyhy2ARrb8-V5ZJCT6s1rhvWCWw>
X-ME-Received: <xmr:R09zalcYigwZahcfC7DKm4QcyC8Mxy2ARtVABd9P5NpFUxZ58dKlpyNIaC872Efb6VBzKje3MGlA1ktsNKnu7TBzYmlm8tGUSa6I9PBpTX8>
X-ME-Proxy-Cause: dmFkZTE0EKbTjmPNLZDegeYJdEvPSKSCO9s22HLtuTKYZ7HLLcaPOQZvc2gjx+GpVjK1KQ
    jrioOGZanX06/wIhePYLadU4DobC5qkSj8L7MnsO15xCkd0z3P7cB6csRPqHGlKuTaZb5h
    bM8drPp/PFHwerIiCnTVd0Vgi6099jSCpXjCLjIJdn4zWBCVR6N9uvmLz0rWPjgF7BHWOt
    vZlPGCN6uONSy4YX7Yy4Wn3rLisBe4bDC6tE4xTe6rnrMqnP5QjyYvMtgRyYANegauBYoF
    kML4/02DYXlfbad4N9Brad2EsuDCdJwSnqfO7HDbcHdezGZGbNsN6UDmvsoEPXJBAd6vtz
    mYRIaVy7tNuBhjd4t1GM2v0qfBu6bmE9e3SxBcsv1S69ZJNVNK3r996hIL74kmOFL1NLfl
    PCG5FfvZl+akhjVy9VIK/zpS9sx5iBoeuuLSChYzkM0EQ86VRSCvxAVH3bd7xx7kuWT3FL
    XMSR6dNqO5XE/rxJb5VTp1/YazROxPPhiz84dADYQNrBJqLiRJZOcH3CGp0RbDzehJJS4+
    9AYchQUb0k4D/fCOLoc7CuO/GaQvUJaENnDARbzhsKip6aEAhLy6S7TZgjG7Lxcs8h6/xo
    /rRKQDTO7MIB3/7nveTu1R+YHrluFxy5YhOQLKVGMwYHgTnUAS7Erdz3rCdw
X-ME-Proxy: <xmx:R09zakuxf9AiwdL2QNLy37FY4SFuibBvS46taG0ff65Abae0zgd0VA>
    <xmx:R09zaumb4S_T7WoXlHVxRWaOZ6rWjTQWhIVMEIEBnuoNj9o4Vv78ug>
    <xmx:R09zauwR6-HC9MWUrrIi8EErtyZlAK7mF5amd2Gopd2rTq_c70Kd9Q>
    <xmx:R09zaoPx-eZS_ZgIowFZokBXzrzlB00Q7wTDH9cXOp8HjUmNyU611Q>
    <xmx:R09zagA6yR7zotDLfG17cRVfQOczG4J5X16zTgv7pSnYklGF94F4dXtf>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 12/13] CI: Add simple domU suspend test
Date: Wed,  5 Aug 2026 16:55:40 +0200
Message-ID: <dc30d924d8c2fa51275b660943f05da0ad541ee3.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1785941832-762FD4E9-E6B7DA1C/0/0
X-purgate-type: clean
X-purgate-size: 2936

Regression test for https://lore.kernel.org/xen-devel/ajUm2SQtMD6Y-K9S@mail-itl/

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/gitlab-ci/test.yaml                        |  8 +-
 automation/scripts/qemu-alpine-domU-suspend-x86_64.sh | 71 ++++++++++++-
 2 files changed, 79 insertions(+)
 create mode 100755 automation/scripts/qemu-alpine-domU-suspend-x86_64.sh

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 1359d70ff2b4..b7cdb3a3eb09 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -752,6 +752,14 @@ qemu-alpine-driverdomains-x86_64-gcc:
     - *x86_64-test-needs
     - alpine-3.24-x86_64-gcc
 
+qemu-alpine-domU-suspend-x86_64-gcc:
+  extends: .qemu-x86_64
+  script:
+    - ./automation/scripts/qemu-alpine-domU-suspend-x86_64.sh 2>&1 | tee ${LOGFILE}
+  needs:
+    - *x86_64-test-needs
+    - alpine-3.24-x86_64-gcc
+
 qemu-debian-13-driverdomains-x86_64-gcc:
   extends: .qemu-x86_64
   script:
diff --git a/automation/scripts/qemu-alpine-domU-suspend-x86_64.sh b/automation/scripts/qemu-alpine-domU-suspend-x86_64.sh
new file mode 100755
index 000000000000..f46a40b67306
--- /dev/null
+++ b/automation/scripts/qemu-alpine-domU-suspend-x86_64.sh
@@ -0,0 +1,71 @@
+#!/bin/bash
+
+set -ex -o pipefail
+
+. "$(dirname "$0")"/qemu-alpine-lib.sh
+
+dom0_test="
+
+$dom0_setup_network
+
+set -ex
+
+tail -F /var/log/xen/console/guest-domU.log 2>/dev/null | sed -e \"s/^/(domU) /\" &
+xl -vvv create /root/domU.cfg
+sleep 10
+ping -c 3 192.168.0.2
+xl -vvv suspend domU
+sleep 2
+xl -vvv resume domU
+sleep 2
+xl list domU
+alive_test=\$(nc 192.168.0.2 8888 </dev/null)
+test \"\$alive_test\" = \"Still alive\"
+# try again
+xl -vvv suspend domU
+sleep 2
+xl -vvv resume domU
+sleep 2
+xl list domU
+alive_test=\$(nc 192.168.0.2 8888 </dev/null)
+test \"\$alive_test\" = \"Still alive\"
+echo Test result: \$?
+"
+
+domU_test="$domU_setup_network
+
+nc -ll -p 8888 -e sh -c 'echo Still alive'
+"
+domU_config_add="vif=[ 'bridge=xenbr0' ]"
+
+cd binaries
+build_domU
+build_dom0
+cd ..
+
+cat >> binaries/pxelinux.0 << EOF
+#!ipxe
+
+kernel xen console=com1 console_timestamps=boot dom0_mem=1024M
+module bzImage console=hvc0 oops=panic
+module dom0-rootfs.cpio.gz
+boot
+EOF
+
+# Run the test
+rm -f smoke.serial
+export TEST_CMD="qemu-system-x86_64 \
+    -cpu qemu64,+svm \
+    -m 2G -smp 2 \
+    -monitor none -serial stdio \
+    -nographic \
+    -device virtio-net-pci,netdev=n0 \
+    -netdev user,id=n0,tftp=binaries,bootfile=/pxelinux.0"
+
+export TEST_LOG="smoke.serial"
+export BOOT_MSG="Latest ChangeSet: "
+export LOG_MSG="Welcome to Alpine"
+export PASSED="Test result: 0"
+export TEST_TIMEOUT="180"
+
+./automation/scripts/console.exp |& sed 's/\r\+$//'
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383616.1626964 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3T-0003eS-Ni; Wed, 05 Aug 2026 14:57:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383616.1626964; Wed, 05 Aug 2026 14:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3T-0003dO-5U; Wed, 05 Aug 2026 14:57:15 +0000
Received: by outflank-mailman (input) for mailman id 1383616;
 Wed, 05 Aug 2026 14:57:13 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3R-0003Ff-Ee
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3Q-00A5Sr-RK
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:12 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f36-bab6-0a2a0a5309dd-0a2a4504c650-38
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:12 +0200
Received: from [202.12.124.150] (helo=fout-b7-smtp.messagingengine.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f46-b57f-0a2a45040019-ca0c7c96abd5-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:10 +0200
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id AF0361D00112;
 Wed,  5 Aug 2026 10:57:09 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Wed, 05 Aug 2026 10:57:09 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:08 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941829; x=1786028229; bh=KBUzmph2e2
	g7I3mmWwGwHw/D0ca5oikmXyWa2C9D49g=; b=xu1sYIIreeAU8R7FTNLSiqLMoG
	29pO+JjSoqH0ASq2tt54TPJ9tGW/ckQqXNTiD0R8+gpRmtc1Lzd+eAXqUWgXDm89
	k8jL3b80CVAEsPGdyE+U9YRM0DrhoWS79YnvczA42lMSQ+VwFW7NJgp/EsZUCLXz
	9elZIJFCg2yfDbackBH0K/myWxy9C35IJspThNsZ2mpQ87wPNfTm+j8WjIftj3vW
	a03Rduyp+y4CxH9XYGLctPFAl8PYHJUgb5U4FvFEOgPQRzBtGIHzzW4x5SkmHZsp
	s4lx18jOBFLUs7ICxLiHp7trj5awBrTwAtu03GD6g81U8SIfmKHKy4aZVBmQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941829; x=
	1786028229; bh=KBUzmph2e2g7I3mmWwGwHw/D0ca5oikmXyWa2C9D49g=; b=P
	K6gpp2S4gd3y+Ik7IUPwOwmYrYb2vDe/iknrK3BMduzhEL3aUZVv0KKpQHlxyzp0
	5Mf4Op6nKEy5eiZ8Fp7O15lSY2k3uBmedQCdy2k01jA07MsM+xkxnvEwfb2uO1xP
	sc8X2lYfnT14hWrat83mO6D95tAmthmOojS7+P/Uk475R5YS10u0wd/1y/JbBjyB
	l2NimBuSyKfsOeYPs6BR1XAvhHaSjf+Ninb0TXrDJm81GFrcXBL8FsRDTjd70jle
	DsrDnL4x9jlTSCJ+AAoShzg7Q5rPU2vq8eUaHA/bxV9/lmTUi9SLfHi2ffEqoox8
	UaezNEnVzwedcSs3ju1Fg==
X-ME-Sender: <xms:RU9zagaokAb3Ru--jrdY07Vccz4c2lhJD088Z-WxLC8AgJKxa7mTeQ>
    <xme:RU9zaiTVQffIGZPM9IcgZzralmdeABPo3BHIPbtMIr_SovHExmyQFx5TvVINPfS20
    gvGpGP2SZ3zU9WBWaJmEo6yIXC16JCIsCcnF29qoSySntuFvnY>
X-ME-Received: <xmr:RU9zajSryMR1t2pZFSZmhcVparK9lxEgE9-xe0OSPc38KKnoP_EuOnGeW93sbcvOtJ3-oBip0hhK_wDqOIT71x0b62hwNptGhewxEmmsEkk>
X-ME-Proxy-Cause: dmFkZTFg5HWH/RDqdPpR88i/6M1gtPWzLlXDm7puE44YW+OQRkCu0ypR/9JOPRDl1te3/p
    2ugUGdWUlQb8kocRthjZN7vvr6IWWNFcyKYmBFPe+BzKMnxGjKoBahL5VCHV3UAfs0EHAg
    nj3sYoDmr7GyZbFXABfsR3rbdQAxCafinJpMUI+6VqMVy7guc3dUP2M2goerpX03cWT8GB
    3tIsn5JiFR3GjgHhPz/r2yz7V7NDg477JFOnzakkhw9w+L8/GP2qYPPRO39CHuug0G7Ubo
    N42GUSC5i0XOiRx9MufeivVdVi29Q812Jc2LJ90UxPjSbThjlODlkTjM/Zl+lF8/E+2aWA
    rexhyc6F6J6Gg4kgL+ELyn4KdQJdvDLu9RZg5NJLg5n5i7/HT1VBjffulld9VrKKT8I4yw
    zn4vJPGmvQUAC0x+7g7TORoqIh/IrKo/gMepIB3an1eH4e9iWAS6pcj2OU9v4YslFGx2qz
    iA0zhbv/ofO32duhlX8Uv7QCSaESivnvSQOF72N1n6N8+/0nuGQ8Ypi53GsHpMwWWb0Yiq
    e9gLXwfhrfmXtBRE9FYpPW0vATiPvbD3+Xzo4oPZjIgvGhddca+y7vZK1oSSH3Wyh9n08+
    nA1zDi73ncHshzXsSgCQnfsXjHLjyEnWP4q6WEta/3a4J/4V1RMWcXrh+clg
X-ME-Proxy: <xmx:RU9zamTH0oR6K2uw4k1MZdqdw84d25Ha-UC7JdMPhg03vAkuxtjOIQ>
    <xmx:RU9zao56KKoDXCe3Yi7f99lPEoyaiktgAihDGC-rocEfz6LH4Ae78w>
    <xmx:RU9zai0cPPTWSC2d_DkulyWaO0xAWm31Q4bsq5ON9DvifEoFHMp8ow>
    <xmx:RU9zajC1nVQ94A2CQLvs-LEwg8jWIlmvvYEG8ZWoHtkcKxrsEC_MZQ>
    <xmx:RU9zajdnBzd4M-7bPdA94Ab6TAxQkN_xU9KhlKe9kEJs3CKUb1RgEJ0i>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 11/13] CI: Extend qemu-alpine-lib.sh to allow simple networking test
Date: Wed,  5 Aug 2026 16:55:39 +0200
Message-ID: <22516b48ec472a1c507cf62a44856a4912037eaf.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1785941831-C10DDB50-6305D1A3/0/0
X-purgate-type: clean
X-purgate-size: 1842

Allow some tests do a little more reliable test if a domU is still
alive.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5
---
 automation/scripts/qemu-alpine-lib.sh | 31 +++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/automation/scripts/qemu-alpine-lib.sh b/automation/scripts/qemu-alpine-lib.sh
index 2d306f384f6f..7f0046888325 100755
--- a/automation/scripts/qemu-alpine-lib.sh
+++ b/automation/scripts/qemu-alpine-lib.sh
@@ -1,5 +1,25 @@
 #!/bin/bash
 
+dom0_test="
+xl list
+
+xl -vvv create -c /root/domU.cfg
+"
+
+domU_test=""
+domU_config_add=""
+
+# snippets to be used in $dom[0U]_test
+dom0_setup_network="
+brctl addbr xenbr0
+ip link set xenbr0 up
+ip addr add 192.168.0.1/24 dev xenbr0
+"
+domU_setup_network="
+ip link set eth0 up
+ip addr add 192.168.0.2/24 dev eth0
+"
+
 build_domU() {
     # DomU Busybox
     mkdir -p initrd
@@ -19,6 +39,9 @@ build_domU() {
 mount -t proc proc /proc
 mount -t sysfs sysfs /sys
 mount -t devtmpfs devtmpfs /dev
+
+$domU_test
+
 /bin/sh" > initrd/init
     chmod +x initrd/init
     # DomU rootfs
@@ -46,7 +69,8 @@ build_dom0() {
     vcpus=1
     kernel=\"/root/bzImage\"
     ramdisk=\"/root/domU-rootfs.cpio.gz\"
-    extra=\"console=hvc0 root=/dev/ram0 rdinit=/bin/sh oops=panic\"
+    extra=\"console=hvc0 root=/dev/ram0 rdinit=/init oops=panic\"
+    $domU_config_add
     " > root/domU.cfg
     echo "#!/bin/bash
 
@@ -54,10 +78,7 @@ build_dom0() {
 
     bash /etc/init.d/xencommons start
 
-    xl list
-
-    xl -vvv create -c /root/domU.cfg
-
+    $dom0_test
     " > etc/local.d/xen.start
     chmod +x etc/local.d/xen.start
     find . | cpio -R 0:0 -H newc -o | gzip >> ../dom0-rootfs.cpio.gz
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 14:57:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 14:57:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383622.1626973 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3V-000455-BH; Wed, 05 Aug 2026 14:57:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383622.1626973; Wed, 05 Aug 2026 14:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrd3V-00044b-0a; Wed, 05 Aug 2026 14:57:17 +0000
Received: by outflank-mailman (input) for mailman id 1383622;
 Wed, 05 Aug 2026 14:57:15 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wrd3S-0003aY-Vv
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 14:57:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrd3S-00A5WQ-CG
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 16:57:14 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f46-bab6-0a2a0a5309dd-0a2a450a919c-6
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:14 +0200
Received: from [202.12.124.150] (helo=fout-b7-smtp.messagingengine.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a734f49-f2d2-0a2a450a0019-ca0c7c96d3d1-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 16:57:14 +0200
Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])
 by mailfout.stl.internal (Postfix) with ESMTP id E9A701D00112;
 Wed,  5 Aug 2026 10:57:12 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Wed, 05 Aug 2026 10:57:13 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 5 Aug 2026 10:57:11 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm2 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:subject
	:subject:to:to; s=fm2; t=1785941832; x=1786028232; bh=2Vy1lzpSY6
	+3Xwm7/h9xeFzQJEpkpv/owElMc4Xp8Lc=; b=NYJbOasRE9L1E0wgi5mSk11pdQ
	ajDa8QGC6ERrlyAkrFHy5Y2tOk/b5yR0jQlN1RhLQAQy08MW7BBdi1tFrXNQgHje
	7VrwMOUCy9+WZPsbWvOsbIWbPmfp1e7x7IH4RpUXF1TrwC2EAsFsWFhXEr6NTRWn
	/UKYHXc3ucsuOdz0QWMRQfatVmUcj5uF/smWMheZLvrTPWzD6KlZ0ctzuNcprrix
	qstweGiFOqtnyC4CgzMVlil+ZsGf/gjsUHFdcilfFGbtHwcH3oFkkz0dwURMLY/C
	7j5Zgn6Y5orfGHLFc/x3pHhbahW8AJPhsCh4ndT86LB/uGHJZYyr4a1zWQFQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1785941832; x=
	1786028232; bh=2Vy1lzpSY6+3Xwm7/h9xeFzQJEpkpv/owElMc4Xp8Lc=; b=g
	k6TFj1XhbIeAqdIDcFDGnd9mwKCfGRerxAFZ9KeSOdPXMOvOI2rOhuDRlWa6fCAo
	yVowXJDdQxkRM094uyJl6r+XFw4l1hmUiWt3NXA4xy5WYMS1ld5quTNIqaaOb5T7
	L0nB6EyYx85ZiLUm5N/ANXXSq2nwwNoXyy1d9d/sPiyKGVip7jN8WnvzLcEEiHh1
	l2vT8GERixtm7JYFUi4ljvZ8/fMyOwfivegxZ0C7mQr5KwmjOgTdoNQUh+s+qrLN
	51364xF+X0+rq673KbUHWhcm3kwJvQ/yG3O7HdwzzAQwCHw7KUM+BAs2ZcJhh9Js
	VyrEWrXQL9fQqOygpEZMg==
X-ME-Sender: <xms:SE9zaukDRHdvRPBwnSXEhX_sToO4aQE0PPb8Euw3fWqwQNKSLfhw6A>
    <xme:SE9zasvmcafuk7k7hkNetbXRDGJXgMUGtQ7mliwL1PaxSrID9J87QnibvVkFzg2pJ
    WWgpy0gH38GvoZRV-9EUxRwT9WHwE1erEEk_UxDUX-xjppnblY>
X-ME-Received: <xmr:SE9zak85EBHmp-1IXdjfB71S_iUlTsZfnBOLsooxM85u_pFtoWEPKwMPpWNThfHnIdavSpGP1ShDdwEg8QSh9rLY4zFSz39gClQ0OP45wq0>
X-ME-Proxy-Cause: dmFkZTEFsr3fiWkpZYryqooLx3kbh+Ts4f345KkT9gdVvpd9ekszqJy7VWnjK2PbrFj5LQ
    NitBf0PdEIBI/suHvnS0zYo/R5qRsLDQBrEmW499IT3EzTl2MaahwXqbjmFFNYGZpxZ/5b
    p4B7pJg15sYbnlZBXco7mxb3X542gdkXCEqYlJa8P5WQQB/RtX317N4YIN9ziiRafDhlGc
    89OM/jfJgDpS8wQRNYzsSDpchNxcRoX3QPKj3oUa0eRNoOX1hDQ02PPD1gK7dvYPchRjIC
    wwvd5eKYYqWlIYSB3GyrYxdAwo+eEieLgrN0OEb4P1KAx+i+QHw+JcyQdOgdE1KkSRVItB
    mkzmperyN8loa/AWp8P7Pk1f4qBZuhubAWJELqBgm1dUEJzT6AKDMTszOWO8Fs7Z2J3ynm
    vnc39N3M7rimyYF5McZ3rkDL1qWV52Ia6An64JFj5QboLVTOFuWonicd3WN55LMkwC6QWT
    p3AamUlSaYSUDJGgkCIrtHutRl5JaDUV8Zk9BSrcbPR7m4APkzjD9lP+7DJdlBGLRLUHjn
    jq0D/RSHxtpxJrrOZPAW3bw9lqaEg2vV7JfxfraS/J1NSC7B4mR3kI+oE8a3uMpleCBl9F
    aZTSNAJWiqTG9fxAcj0jIGEIZjoRrzCOC86VSpzL1NBylojRu2SoosdOraOQ
X-ME-Proxy: <xmx:SE9zauOK2rO9IW-xkAvXPfTaM3xbTNXq2d000_O9PGpo1WqjO70SqA>
    <xmx:SE9zaqHRLgVXosbUV4j5wgTebiJLvifW7Nrol68dQX9gSXL8I_jBCw>
    <xmx:SE9zakRBricJyK_D9ygIKGB5rWB9aD0XQnQNEYjz-jeLQIQwnjV-mg>
    <xmx:SE9zavspvuzjTH56JCYBJQm4_ChWP3xgtaiZM2QWy2LLA2d6mYCI-g>
    <xmx:SE9zalhOyvvWOjGeUDA5LkuhFLBSp3_D2nEfRcTWyJbtdmQkdFCdzKGO>
Feedback-ID: i1568416f:Fastmail
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v5 13/13] CI: gate macos build jobs with MACOS_JOBS variable
Date: Wed,  5 Aug 2026 16:55:41 +0200
Message-ID: <1c63c71893b9cc2cb6cf2dacaad8fb96fab6cdb8.1785941707.git-series.marmarek@invisiblethingslab.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
References: <cover.099eede8b72ebc9acb07545472d72abceed1c8b7.1785941707.git-series.marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1785941834-536D6CFC-9DEF1200/0/0
X-purgate-type: clean
X-purgate-size: 1483

The macos runners have limited availability (they aren't enabled for all
repositories, and have a monthly usage limit). Do not schedule macos
build jobs unless explicitly enabled with MACOS_JOBS=true variable.
Note: just setting the variable is not enough to have macos builds,
relevant runners need to be enabled too. Unfortunately there isn't any
built-in variable signaling runners availability.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
New in v5

MACOS_JOBS=true wants to be set as a group variable in
xen-project/hardware group. Specifically, on this page:
https://gitlab.com/groups/xen-project/hardware/-/settings/ci_cd#ci-variables
---
 automation/gitlab-ci/build.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 27eefec5f9a5..85831f44838b 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -13,7 +13,7 @@
       - '*/*.log'
     when: always
   needs: []
-  rules:
+  rules: &build-rules
     - if: $BUILD_FOR_TESTS_ONLY
       when: never
     - if: $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
@@ -806,6 +806,10 @@ debian-13-riscv64-gcc-randconfig:
 # macOS build jobs
 .macos-26:
   <<: *build
+  rules:
+    - if: $MACOS_JOBS != true
+      when: never
+    - *build-rules
   tags:
     - saas-macos-medium-m1
   image: macos-26-xcode-26
-- 
git-series 0.9.1


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 15:37:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 15:37:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383719.1626985 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrdgM-0005yz-8W; Wed, 05 Aug 2026 15:37:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383719.1626985; Wed, 05 Aug 2026 15:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrdgM-0005ys-5h; Wed, 05 Aug 2026 15:37:26 +0000
Received: by outflank-mailman (input) for mailman id 1383719;
 Wed, 05 Aug 2026 15:37:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrdgK-0005yW-WE
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 15:37:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrdgI-00AAlK-5V
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 17:37:22 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7358a2-5cb7-0a2a0a5109dd-0a2a450b9a3c-26
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 17:37:22 +0200
Received: from [52.101.61.63]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7358b0-b7e8-0a2a450b0019-34653d3f75a3-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 17:37:21 +0200
Received: from IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6)
 by CO1PR03MB5937.namprd03.prod.outlook.com (2603:10b6:303:6e::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 5 Aug
 2026 15:37:18 +0000
Received: from IA1PR03MB8288.namprd03.prod.outlook.com
 ([fe80::b5ee:28c6:e04b:5599]) by IA1PR03MB8288.namprd03.prod.outlook.com
 ([fe80::b5ee:28c6:e04b:5599%5]) with mapi id 15.21.0292.018; Wed, 5 Aug 2026
 15:37:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UBB/a+RoHluFkJF7rGfmEJDk6AgzwRcxJRoq7DafGICkamXXhVSICKkqhOB3MsjCvhuU0Udid8dBKi30lwnfZgawuam29jkb4QRST25BJXPj2S0TIqtPlxS5+F7UQvTB6/GgB7KHZ3xSFXh8EYRxLbPvuS2MBTZFi3YpgD15xtKVpWxXGBf3dJDXbsjoYtb6L+YH6rUBqFscXgmCh0uLKPA1B2ELBh46czcIeQ29/CRCvvgz/VX8DRH6qb08+NNIj80ISGYon/f6bMvk1ePEwBvLXx3vJ0F6jCHD5RZzEzgQjbsQdLjd90Ri5M49fmHjtPF0EoaIewkHxa9samyLnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OpJuoyeWX8X4J/xCvkd6XAjCDW5W2vgxIKAaH7xIHAI=;
 b=twUR1hHZaW9NSMFEo0SBTfoeAISL0pNV31JxaV9IsWfqnFkYfp74aS4jD4na2ZGcunleT8YcMC9ilclCMJ5FoZFKDBs1LUrCGYb8lz84TUZVeSBHRr1blpUUBCqY5IkVRPx6cnPSiU0Qyihnqqj9dYZPY0DwrYPfpz+qB0B4TXwcT/xpFKx9+d56wVcalVqsHdywk4OQgaKsBBkkUGxiuUUYB2E72ykB6glMfPcA7zBHAa9iRSdcsKOs9v053HT7eaQSyyJ8KDZy6w7qRupY++2kj919ATw3o9ni9hqu2rI5n83PXcv4Chpb1IlTWARlVsi1oZ6cN4ipoT9u7msfKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OpJuoyeWX8X4J/xCvkd6XAjCDW5W2vgxIKAaH7xIHAI=;
 b=caJSxtAhrFc+rwlQZucvGQRKn/2RExporS3MtAsMo/hGHTFQrGAF03ALc9lea+jcLLRwIjrMZCH+lBd1LpO8t55+N7dDMagGm9Fz/3XiVVu9tj1O6ITHu7pzQ++n3aVuTXyg8JFeLxsjiaoSd9UVxJWk70CknnSDEOPNtm/knQ0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <da3b4ee8-7c12-4fec-8d31-6f2f66bba4a8@citrix.com>
Date: Wed, 5 Aug 2026 16:37:15 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/5] x86/nmi: Don't configure EvtSel repeatedly
To: Jan Beulich <jbeulich@suse.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-6-andrew.cooper3@citrix.com>
 <d76fa0a2-1a53-4ee4-b077-d51715dba339@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <d76fa0a2-1a53-4ee4-b077-d51715dba339@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0203.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a5::10) To IA1PR03MB8288.namprd03.prod.outlook.com
 (2603:10b6:208:59e::6)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA1PR03MB8288:EE_|CO1PR03MB5937:EE_
X-MS-Office365-Filtering-Correlation-Id: 194fc579-9724-4c52-e1f9-08def3076ed9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|18002099003|22082099003|5023799004|11063799006|4143699003|10067099003|56012099006;
X-Microsoft-Antispam-Message-Info:
	J1ls53dVXlI5kO3RN9tk1OcaQxcDkPasxiLwXSFrYwPq46tgNuarPaU76P72rUye/L/Wq9XBgyDvvVHyYpCvoXh1NejM0bAglJ93+r2ZFEIV6CH03K2HVl40DwJ3JnqoUgbn5u3uKaZ8CjhWbJbnitzXq1iEJ+eoVlGOgUfKT8OVbHn88NSJAkdCipWN+3c7CfvWSe7zFF9f5od1+J+NG91a2T3t3w5ELSnLxJ0pL9Ia1m/6CVvoDpUKkx725/fYVttqAzyMgvDxKxsRrAaaZOWqOmFZSOgour5zhYKlYo7S+5g5t0In+8YkYrp2IDfaCya0aJXfesUNDrMGjsJiu1+g7ouaXIXm3OVYCU6/E6BAHH8Ljjkc/IpyylNd2LRG+1WZXZOiVI5xiEFQpqWyq96Ug7QdmuF1DMIsB00VX53MOFOJhpULI+BsOx8W1ZVZcLLGeLct9bRrOCkmCtityPhZTtckQj4rswcro2xXxYFOuQ1EJu4Pq1ggv+PfbsJl/I+LYF/tSRK75i3ZiilkxLn2sq9RPNnJ4lNOtllKPIL8MzQ0B80gfY5FWzIPAAF0fmdHLbDL3geQlTHpa6EKOKPnz08pw5L8n9wQfQLaFZgFmJlGCvGEmSaJ2JtCC1F+MDzF4Qt/aaIq86vWOdtiPHrIfY94BlpZCcNBLvmA3sE=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR03MB8288.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(18002099003)(22082099003)(5023799004)(11063799006)(4143699003)(10067099003)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TnNINytmUFlXUmFoM3VNd3NBbHFGbGJXdWVEbWlUa0hrcUlhamh4WlRVOEIy?=
 =?utf-8?B?WXdCUk00SVJGalJ3QlBVWjRhZ2pLd2FWbXllL1dMbFN3SE4rdm41UkdieGZj?=
 =?utf-8?B?dlhtSlZnaUlTcFBVSEtyaGNVSW8vMGgvTFVNZkd4cmppL3hMV24yTDB4djV3?=
 =?utf-8?B?b1BXR0FERHVkL3hITTN2eWdiK1lGS00xWVhyejltUDNuMEdleExwbmpKOC9s?=
 =?utf-8?B?cU1oZnVxNTNESDFsRy9FMHlpZEtzU1NvUnJxeWZyZnQ0VU15aFRhdm90dGV1?=
 =?utf-8?B?NElKYUh3djJ2eXpqNTBwb0VMYjh6elYzbTM2Y3hrR2E2ZjNtWEpZRDN3ck1v?=
 =?utf-8?B?K3NPNzVycFVrUWJLN3FXOWsxaVMxbktkYWdKRFdGNEI4NG5EcnBWbnJzMnMx?=
 =?utf-8?B?SnhnOUgyVkN4L0pVdHFBSVdIamxBZkp1WDNGR0lPRjl0ZWdZTWExOWptTVNz?=
 =?utf-8?B?OW9KQVZiSS9uQ2sxSFlHVnNRTUdGMXdvdUdYNEZWTVlLenJqVENqanFWeGJT?=
 =?utf-8?B?OGxXR1FBQkVOa1E3WVAxc2hzNnVVckNUNzFMWmw4ejQvV21XaFhRWGlBNUta?=
 =?utf-8?B?TUJmdkh4NWt1M0JmM1d2cVBoY1dNa1dBaUUwL2JKWExKTTQ2RVdkSkY1STla?=
 =?utf-8?B?cDFlS2U0SGpyWHZiVC9VOGx2UGVzMEtHTUdvU0JYa0RkdzdPZ3JXdVUyakNU?=
 =?utf-8?B?ck1zNVAzbGdjMHU3KzB5dDIwMEFrTnNsOVdjRXQ0RWlqV1dSb1VWbjEzN1NG?=
 =?utf-8?B?ZGVtamdkZUpraEN0bkJOZGx4T2NxaVFlTUFOdlRqV2RVVE05bzhKd0tmQkxv?=
 =?utf-8?B?ZUJINXlOMGFQWllCUE9OajluMkRFanJOVExnWm5sbnR2em9OT1BpV1dkL20z?=
 =?utf-8?B?NmRvRHYrMDFrUnBIQjArUmtXZ2N2OFNQYWFaK2tMZ09ROXRhQ3FVY3c1NE4z?=
 =?utf-8?B?S1l6NHZ1NUtUOGh5RXYzaC9tTnJ5Uis0OTMyWXM5c1NvOXdUd1RzazlIVWl4?=
 =?utf-8?B?aCtrV09adm1wNndSam5MMU42eldQQllFQzZ2dWlmSGFURWxOdUlFcHBTTVVO?=
 =?utf-8?B?RFdnSXVXclRyOFRjOVRjSWxWVGpTTVN1NHpldGE5R3BUdEg2Yi9SV1pSWDlP?=
 =?utf-8?B?ZTdKRHd6Y3ZpdDdmdWRMZnl6Y3puZmpIS3BEbnN2UXJFQTJZL1kxRm9oUEFE?=
 =?utf-8?B?dnQvWGRGZTUzaHAzRTgwMGNJZlJ5OWhZQlVSVGdld1lhZ3NiaUl1SnJFU3hu?=
 =?utf-8?B?NXBLYmVtaTdySFVFaXNRWUxzcmNzZlFaS0VSUEpGcUNEY1pRdG5NUThYWUx2?=
 =?utf-8?B?cjk2MUQ0Q0ZxdFppb3R4Y3lxSGdMMGpVY2xQTUtKenNOMitEUW9iMTlYb3JU?=
 =?utf-8?B?UFdXVC9kNFUxMkxieXFQZjM1S2EwNFRwM2lzbFM2dkUzcDVxVk1TMFhLS3ln?=
 =?utf-8?B?UWp5d3VsNEJoVmNsd29GRTMwVW5YeG15R2R4L2RTQkI2STJBa2FoKzhmd05i?=
 =?utf-8?B?Y3VtVUhXbmNWT2xPRDVhSUR4eTdCc0s3ZWNRM0VtY2hZUEFPUlZXd2xrOXhy?=
 =?utf-8?B?Q2ZYU0grcGVtVDRzekFpSmpFS2oxREI3UFdTdG5VUzI0Z3UydER6Q0RKL2dO?=
 =?utf-8?B?WElYUlZ1NHlJZ3NMNWVaTEExdy9yK3pIUzFNRk85d1VzTldUUE83aWpldW92?=
 =?utf-8?B?bkxIVFk2cW5NZWxnLzNkT3h1dEtqK3BrbHBRY0lESE04QmZGbkhWSm1FTGo5?=
 =?utf-8?B?MFZobWg5aGU0eUtra2pxTDh6UEtiSVJZUjlRUzhpZ3BsS3RBM1V6KzdHSEJZ?=
 =?utf-8?B?UmtDdU9tWGo2T3lzd3dUaHpHVE1KMXNRVStpVTFXdGZwbmNJWE5tY0VialI2?=
 =?utf-8?B?WkhjaEp4WGNNVmVqL0hhU25tOWZPWGVQblR4Q0FRREUvT3dubGpVZW1FVEpy?=
 =?utf-8?B?VThEdFhHb2c1bTlqRFdRQTBVbWpoT29qMFhEb1RzUFdSRE1Yc1dDRGRoTTZh?=
 =?utf-8?B?MEp0UFR0RHhVUExFMFlaNWdWTXNDTUFHUzV3YkRxU1BSZzJZcnNGWTdLeXU1?=
 =?utf-8?B?cms4d0tLVnRqQzU2YW4ycThGcDlicUxOYXErZTRnd3NEaXI3Y2FFZzZhR1Nw?=
 =?utf-8?B?bjRrRTZ2NDl6RlBvTUVuWHgzUm5Vck9QQzQ5bTE3QitFRkowT0Y5ZzViQUJM?=
 =?utf-8?B?WmJYb0pPbGsyQ2prazIrZ2FCUHR5VUI5SEt0bkhCYjNKTkc0bFY2SkhkOFh3?=
 =?utf-8?B?UGJaNG5WTmd4Z3ZBNHNxR1U5RUZQOW40TS9SZVg3dmQ4NGtRYkd4Sk51Tis4?=
 =?utf-8?B?NkZmMGlrSy81MFBrVkFqWUt6YU05SVNXMVA2aCtNWDhSZUx1RDhNbnNYb0tG?=
 =?utf-8?Q?gyZiZXuaPI+x54yM=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 194fc579-9724-4c52-e1f9-08def3076ed9
X-MS-Exchange-CrossTenant-AuthSource: IA1PR03MB8288.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 15:37:18.4413
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nOqA4flYTpnk9H8GQhu7KJExGQTbxSQVDUbYgSfzCDrNE+LmKuOzsXcFU5XRwsCvjaZuI47UUEOSryyw1/yqHIiNb1FTlRINbHL4evBWdII=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5937
X-purgate-ID: tlsNG-42698a/1785944242-AB0DD9EA-2C67C515/0/0
X-purgate-type: clean
X-purgate-size: 2252

On 05/08/2026 3:20 pm, Jan Beulich wrote:
> On 05.08.2026 14:45, Andrew Cooper wrote:
>> In both setup_{k7,p6}_watchdog(), EvtSel0 is first zeroed, then written with
>> everything but the enable bit, then written with the enable bit.
>>
>> setup_p4_watchdog() is slightly more complicated, owing to what
>> appears to be a bug introduced by commit 2a2bd8de16b6 ("Clean up NMI
>> watchdog handler."), which causes a second bit to be temporarily
>> different too.
>>
>> The middle of the three writes is useless in all cases.  Drop it.
> Spotting the 1st write in setup_p4_watchdog() wasn't quite as easy, as
> MSR_P4_BPU_CCCR0 (as passed to clear_msr_range()) has nothing to do with
> MSR_P4_IQ_CCCR0. Using unrelated MSR names there is as unhelpful as using
> raw hex numbers.

Perf counters on the P4 are utterly insane, but our local logic really
doesn't help matters.

Another option would be to remove P4 watchdog support, in the basis that
we really can't test it.

>
>> While doing this, rename the 'counter' parameter for
>> setup_p6_watchdog().  It is the event which is passed in; the counter
>> is always counter 0.
>>
>> No functional change.
> These sequences of writes almost look as if they were trying to cover for
> errata. Are you sufficiently sure there are none anywhere, for this to
> truly be no functional change?

There is a reason to write logic in this form; it's just not applicable
to us.

The original P6 (besides being 32bit only) had two counters, but the
enable bit was in counter 0 only and controlled both.  I.e. you needed
to write logic to program EvtSel1 without the enable bit (it is strictly
reserved), and then EvtSel0 with the enable bit, in that order.  This is
in the SDM, just well hidden.

I spoke to various people, including PeterZ who wrote the perf
infrastructure in Linux (starting with Westmere, so it never ran on P6),
and Linux has absolutely no logic of this form at all.

I am reasonably confident that it's just copy&paste without due care and
attention which has left us with the code in this form.

>  If so, ...
>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 17:57:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 17:57:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383811.1626993 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrfrA-0007oN-SE; Wed, 05 Aug 2026 17:56:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383811.1626993; Wed, 05 Aug 2026 17:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrfrA-0007oG-PQ; Wed, 05 Aug 2026 17:56:44 +0000
Received: by outflank-mailman (input) for mailman id 1383811;
 Wed, 05 Aug 2026 17:56:42 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrfr8-0007o9-Iz
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 17:56:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrfr7-007xQH-SF
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 19:56:42 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a73792d-5cb7-0a2a0a5109dd-0a2a450b8752-36
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 19:56:41 +0200
Received: from [52.101.43.59]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a737958-b7e8-0a2a450b0019-34652b3b670f-3
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 19:56:41 +0200
Received: from IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6)
 by BY5PR03MB5048.namprd03.prod.outlook.com (2603:10b6:a03:1e8::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 5 Aug
 2026 17:56:37 +0000
Received: from IA1PR03MB8288.namprd03.prod.outlook.com
 ([fe80::b5ee:28c6:e04b:5599]) by IA1PR03MB8288.namprd03.prod.outlook.com
 ([fe80::b5ee:28c6:e04b:5599%5]) with mapi id 15.21.0292.018; Wed, 5 Aug 2026
 17:56:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RynfGg/1BWj8KVgkYctZH3zjXUk57loPoTssB1aW7/WznBY7wfq+C3oRj9bDrzWwitUqZ4faj2QPiOSG2D4dABCZNG+6hrJy3gSpw5LuQ7LTrL+PAljiu6XSTPa9SwIU2iueXKV3o0q5N23b81oaezyMb7lNZ0cAUnA3t76EH41t/EWTjOPpxDHAEJ+d1dp1Mq3r2A0W/jU0XrCLC88CjKlSdJOmjkLiC4J+7eNy50OCppQvjxTxlvLhKtTnwwvyPSDIluPXCOq3uprnc33O1FZ93ReMEFi7XOr9mB15P5fOjQ1X1ZKKdwCpUJt6yjEopgnUCdXiZ0Mg7E3qEjnaxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AWL4OLP8uDAfZ7Dt2Z1hIzCUXwvGDKhNOKb66JnPpNs=;
 b=vuWUWENJrTXyHUjN/QbW24zWbs+WPdFjSgr0dcf0M3UQrtINZ1meHQ2aPTLCMjCOUugUlDPJAj/2l3lu+v5OarTIOp53+Z/PIzIdeheM8pdh617fEE47m/76Gm+PK6SP4QaJK5Li3hwCCs6nRTdhs+DC4ajj5Qzp5FAD8hcFoirlwpnIOcc+EW2eeVRm4IXmTao1eKsNVeIiLLcz9044WbLK/Y4yj4nnOJUQ+wf7JIjD8QLf1pTUqG8Nlvd02S/9Gl8GaQssumD5e4yGyDiQwvcNGtZmnoIAiBCaCHlg/wlr7vmy1Sq/KPd+vCih9joFL41SrljDCwYxv1jSuH7OiQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=AWL4OLP8uDAfZ7Dt2Z1hIzCUXwvGDKhNOKb66JnPpNs=;
 b=Gq2Y3Mgayoqq7J87XC7jdDYmQqt3vNKnF/+JFKjc9fN4aysHsP3/vzGeAIZoA4z2zJ/JlxD6kjAZoT/QByyyFq05rxVrgbd7JyTmH/iuzionSWzmzOO+hioLbVcUBuqQluRAzgr9QJeWsy0FMAStnBoDdN3WT5zwx6hi15jZh7k=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <49738195-ad6f-4889-984d-b1eeb5372708@citrix.com>
Date: Wed, 5 Aug 2026 18:56:34 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/5] x86/nmi: Watchdog fixes/improvement Part 1
To: Jan Beulich <jbeulich@suse.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <e1e873d9-6dc0-4e08-90f5-e99ff42802a0@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <e1e873d9-6dc0-4e08-90f5-e99ff42802a0@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0110.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:192::7) To IA1PR03MB8288.namprd03.prod.outlook.com
 (2603:10b6:208:59e::6)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA1PR03MB8288:EE_|BY5PR03MB5048:EE_
X-MS-Office365-Filtering-Correlation-Id: 78f2b456-6a2f-48c2-393f-08def31ae503
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|6133799003|10067099003|4143699003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	DnuFKRt6lHemYsw6AkJW3boK+i9uwXTpqUrEu0tdjsc+48jDcUpTCs97Us9FcgPu1BBO4mdaecmpk8M1DWd0YClOZHbAELxAul4Ozn8PlVk+YN5yv1C8nhBODlGTTsMtDxgMES6HWWm2bzAHIzkIKfyX2S2O5pD1tSs/rk3ixjGLPl5D4I5VRiz6hksDGX98gTCI/Lziejp6HArP+7k1GRZ+DRR46SjEXkMDsMnIIsF7yvQDJl/YySaSKSAKPpnJ1j7PU5vEyD0Df/Pglt14E68LO+7LsGaS3zYRcScuxp3IoXhAInRQ+lesUdeWXG5tEh1fg2EoIBX0EJyHGrQQVLc1FO3TYQupiVE61g842nIOgWHzX5Yn/Q1dFlvHr4YBWkb7cPFC6Ug04a/3W51swzFRIWHyNnJ9bh3b/IHivfwRfuOTfBBOTV4oDZVX9EGqxGnFeLG9Tb9a9yBQw7Y6NcUvDfKCXpUMp0hsHYPbOtu+zAMT7XCGdezXUUB4guv4e9XY8OeL+ks2HZdheCQYlKId54ghAQGfFb80unq/eKf6E/ltOvjWx81vumIVGQWxzP28zDj7tDuvat3Nzec5CTAMeY1HRza6XVIpt6k1JwCyjB1tXeuTsoPP5gddr6FPJOkhqOUyavWdjn/dBKNrtwSvzUDD5nZFMTeQxeobbtM=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR03MB8288.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(6133799003)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TkdRdzEyeGdKRnQ4Wkt5ZDZEd3FrdW1vUit3QmJqZ3N1RFBLRll2WWxsdTFK?=
 =?utf-8?B?U3ZhZUJGcXBhb2RBZzhRSloyM0xHekxnUVlzc3d1YjhSbHNkTjlxa0hQVGlB?=
 =?utf-8?B?K2piTlo5VllrM1pqYm5mM25RbXdHcFlNOExWTTJDM1ZVaW1USDltSjNqaGZu?=
 =?utf-8?B?WCt3S2NGNnVLeldVQi9GL2d0blhBUzVTd0NpRkl0Q1I5Q3NybVFrYTQ3U1dK?=
 =?utf-8?B?ZmpvZ0NLaW1ya2JXM0pVSnJNRXU5clMrK3ZPOW5JbTFEWXpJRDF0aFVySTVB?=
 =?utf-8?B?K0pIQ1JDWS9ONmpJQWwvUGRCUEdEaDdRUXFUS2toWGN1TTlhWkhNM2NtakpX?=
 =?utf-8?B?cDNTOUFVZ0htVkpydWZKQ3paM1lRbWlDZDRwb3B3NkNFZDRzNStKZE9YMDJH?=
 =?utf-8?B?dE1TR2JVUmZxdFlQcEUyRFpXRE1Ob2thY2tOY0JpckZpUVYyelF3d0RmTWdm?=
 =?utf-8?B?dVlnRmFPU1haL241cXZnbWNSeEp5ejIvYjB3ZG1xeGl5cXVPM2dLek50bmp5?=
 =?utf-8?B?SDRSa0dYKy9qSmNtZVlQQVQwMTZPOGR0eWw0Wk9aMW5MRTJQWmo0OS82U2Fu?=
 =?utf-8?B?UFIyM0U1cWJMcDliMzZtOVRNUWdObWZDMzVQMVF5TWxHTEFRelEraW5oc3V0?=
 =?utf-8?B?VGtsc1dUSlVDa0hDbXVVZ3k1TCtjbXpTYVlRUmMwUzgwQ0NwQlpNQ3M4cDdz?=
 =?utf-8?B?MnZBWlBCaHR4UEI0ejkzcUJUNEdGYzl0UGxBRlYyU1dNSEhHd2UxZGVtdkxZ?=
 =?utf-8?B?Wmt0aThTVEtrNlk3UjVOMERLdHZjR1VYaWFWbkR5TlM3aFhvRDBFZDNuazYz?=
 =?utf-8?B?OEdyTXhEb0FxbkluOU9jVEFadGZrclN3cmVyOXREdmZDTnlHejhnY0h2K0tL?=
 =?utf-8?B?a0F4dXZSbXhqOVFvcTZhZ1IwMzQ0alJsMC9MSnNydVJnUEtVUHRFZzdjckJG?=
 =?utf-8?B?dEJxTW1aRlUzSjExTFZBT0ZBblU0UWJvUFQ5Z2NncmdDT1JJMXM2UEN6UnJC?=
 =?utf-8?B?UytjVUZxeTgzMkRMZWEvajA5SXpKeXhDdS92WVk5Y0Jtc0xTZDNURmRlQm5J?=
 =?utf-8?B?Y3BkVWgrampwRVZqWUpJNWZBc2EzTjNPcVFhb1VxS1MyK3FpSmt2enE1N2ky?=
 =?utf-8?B?TFU0cDhONTE5WTM5VkJHK2hwQVlBRlFIdjJnZUFjeGJMcFRZcWZjNE9DOUFk?=
 =?utf-8?B?SXo2YUJjbjdMMXMvZzlzVC9Ld3EvVXJZWThKK0cvSWgxK2U4SDdvbUM4d28v?=
 =?utf-8?B?NnFJVmNwSDZDVlRPOXhUN0FxUjBxUGhyVytoWUgyMSs5SkFyWDVSZy9kdUYv?=
 =?utf-8?B?a3JYWS9JM2UyUEp1MkZkM0JrWmJSK2trNlFrQWlQRStCQWN0b2cxU2k4L0Zv?=
 =?utf-8?B?bHM4S0IxOEF6ZWZZYWFicVZ4R2UrTHV4ZEpiVlUydGNCdnJtNHFDcjJLMHNF?=
 =?utf-8?B?UC9HTUlyeU1KUk1MSjdLQlVmc3pJSVJ2ZzRXNkpsZEcxQjB2THNkSm50cnhM?=
 =?utf-8?B?cHRDdkxqUEZqcitTTitIQ2VZaHhBSlNuSmRRUm1XejU2UjNrT3lsTFBCb1Nv?=
 =?utf-8?B?NW05eHNzZlI1elNielJ0OVJSRW5sTWVZVUgxSmJBMEM3VVdJMHJUTDN2TmNs?=
 =?utf-8?B?T2h3Vm92R3ZYS3c0OTJ2bjZXMUdyeE9lSDg0d2orVk94L1VjbHp0RHJNV1A4?=
 =?utf-8?B?UUtGbFVvYnVHTDBMcExleXBKRE0wdDRkbVJnOWx4UzBDekNMVUR3TGJtV0hN?=
 =?utf-8?B?L3d4UzJWVjl3NWl1ZDZOazBHbXB6SCtoejRGdUo2MjhGU3FHeFZJNDdSeFdk?=
 =?utf-8?B?SEVNS1VPSGF0Y0E4RUJleE0yTjJxbi9iS2Ntb0VmcGxpdHk2R0lEQXJBcXND?=
 =?utf-8?B?b0JwT3pmamdzeCtuMUFlQ0xJWUw4M1VET1VKMVlQNXpFdFpra2RJVElNVTk4?=
 =?utf-8?B?T0VIOTViNHlFcXlaNmtoRmVSKzgwdUt6a2VPOFFVNE1heFdId2ZjSEtBZUdJ?=
 =?utf-8?B?T3Z5a29VcFRPcWJyNlJtZjlKR2dKQ3BEQnNveE54V1phWUhTOXExY1RuSFF6?=
 =?utf-8?B?VmtqNzFuM1pZZjV5OXpmVm9YV09PeXQ4bDBCKy9nZjJvRSt6S2Vndk5BT2Rs?=
 =?utf-8?B?VDJGanJvS3A5SDlmYkcwMEs2NVk1eDVrQjRMV3NudTB5RFRYczRzZG1ucXlB?=
 =?utf-8?B?d2w4TmxBZHcyMXgrdHFFaVZ1ako0TFg3OFJaNFZpS1l5SXgyNVFkSE9SZFN5?=
 =?utf-8?B?cmFvMXcwejlSMmlSRXBPbTBYeDZ0Vk1XRkNLL2FKQ01keFN2dlJLWm1DTE1z?=
 =?utf-8?B?dUxtOUYyL2JlRE40WWlyQkkwdWVMbnZSVkU5QlJRdWlpTGIxcy91QT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78f2b456-6a2f-48c2-393f-08def31ae503
X-MS-Exchange-CrossTenant-AuthSource: IA1PR03MB8288.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 17:56:37.1113
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Kvp7iL3S1er8kkuyeoMjXpJHYB6e154Yvy2Nj7YonjR5vz0hRb0ho/WWuuFzmb5HiK0wEmBtUh3mcgdp1vq5JAOIBC25xsvebdC4rx7GnLs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5048
X-purgate-ID: tlsNG-42698a/1785952601-1B2DC9EA-40C466E9/0/0
X-purgate-type: clean
X-purgate-size: 3491

On 05/08/2026 2:42 pm, Jan Beulich wrote:
> On 05.08.2026 14:45, Andrew Cooper wrote:
>> This is the start of a very long rabbit hole to address the
>> mis-classification of some watchdog NMIs as non-watchdog NMIs.  For
>> now, just some simple and hopefully non-controvertial changes.
>>
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2733861049
>>
>> Andrew Cooper (5):
>>   x86/nmi: Drop {reserve,release}_lapic_nmi()
>>   x86/nmi: Drop K7_NMI_EVENT
>>   x86/nmi: Misc style fixes
>>   x86/nmi: Check MSR_MISC_ENABLE for all Intel platforms
>>   x86/nmi: Don't configure EvtSel repeatedly
>>
>>  xen/arch/x86/include/asm/apic.h |   2 -
>>  xen/arch/x86/nmi.c              | 153 ++++++++++----------------------
>>  2 files changed, 47 insertions(+), 108 deletions(-)
> This series, once again, is putting me in a difficult position: Should I look
> at it, or should I let it sit for two years or more, just like my earlier
> fixes in this area [1], [2] are? (Of course, as always so far, I will look at
> the patches, and I will likely also accept them going in ahead of mine. But I
> cannot exclude that at some point I might actually stop doing so, seeing how
> many of my patches are in that state. While at the same time none of yours
> are, afaict, i.e. as per the track record that I keep of what still needs
> responding to.)
>
> Yes, you did respond to [1], but is not being comfortable with a change really
> a reason to block it, when it _is_ an improvement, and when the alternative
> hasn't materialized in all the time?
>
> Jan
>
> [1] https://lists.xen.org/archives/html/xen-devel/2024-01/msg01365.html
> [2] https://lists.xen.org/archives/html/xen-devel/2024-04/msg00194.html

I'd forgotten about these.

Patch 1, I'm (still) distinctly uneasy about, but I dispute your claim
that it is an improvement.  You are adding complexity and not fixing
anything AFAICT.

The watchdog counts NMIs (and counts incorrectly; this is the root issue
I'm needing to fix).  A timeout is declared when a fixed number of NMIs
(10, in default configuration) pass without the timer softirq having run.

The rate of NMIs varies with P states, including lower than cpu_khz, and
differs between cores.  In some but not all hardware, we could switch
from Unhalted Cycles to Unhalted Reference Cycles, but even that has a
bit caveat saying that the definition changed in 12th Generation.

You are making the rate of the timer softirq dynamic, but it is an
arbitrary fixed rate still unconnected to the rate of NMIs.

The only fix is to make it safe for the NMI handler to read real time. 
Until that time, in a choice between your patch and saying "well don't
set watchdog_timeout=1 then", I'd firmly favour the latter because at
least it means there's less to revert when a real fix does come along.


For patch 2, I had figured that bug out independently though inspection,
and yes I do agree it's an issue.  I was debating removing
watchdog_timeout=, and agree with that aspect of the patch.  However,
watchdog_force needs deleting to fix the incorrect counting, and with
your /* reset to defaults */ you're breaking the incremental property we
have of command line parsing elsewhere; specifically "watchdog=force
watchdog=10s" now sets force to false.

I will make sure to address this bug in my series, but I think it will
be a fairly different patch when the other dust has settled.

~Andrew



From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:30:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:30:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383908.1627004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrk8I-000191-Iz; Wed, 05 Aug 2026 22:30:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383908.1627004; Wed, 05 Aug 2026 22:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrk8I-00018t-DF; Wed, 05 Aug 2026 22:30:42 +0000
Received: by outflank-mailman (input) for mailman id 1383908;
 Wed, 05 Aug 2026 22:30:40 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wrk8G-00018n-RB
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:30:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrk8F-00GHO2-F1
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:30:39 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73b977-5cb7-0a2a0a5109dd-0a2a4504ea92-16
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:30:39 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73b98e-b57f-0a2a45040019-ac6904fe9736-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:30:39 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 860B260A63;
 Wed,  5 Aug 2026 22:30:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D8DF1F000E9;
 Wed,  5 Aug 2026 22:30:35 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1785969037;
	bh=UyQFCcMMSY/nbGntlznDMnICY2Uy0xvxXdgPyh8X9mI=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=nA4o5PUKLu5Wv3Zh23xrawOuZwiesBL+Dxbv59c0yLNJxxlb9OzysC1lbb+pTmbEB
	 Jm8covCACK8+kqbiKbYME+GvCT9MgbNSg4WB7gDBfYgjoVWys6Wgdq84DV2L/R9uig
	 nFSryxPCP/KCqg41N/Shytj15TmmuTTGMfTqntCYL9lqGOX953dPQbkszejKiayb1Z
	 LKdiFW6nJUBumNhq8lcUgJDPEhPh1/pcrzG4XclhhrkISxmLVRZDwjOGH87wkuUhzM
	 EOXXiRuSqMxUOAh2+67Sx3xC89MNCXObS5C3QS7jmIMUWiUZ3JEOtkWU8cBf98XIZb
	 eNvaTplYNP/zw==
Date: Wed, 5 Aug 2026 15:30:31 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Juergen Gross <jgross@suse.com>
cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
    Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
    Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
    Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
    "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/4] x86/xen: Remove redundant config dependency on
 X86_LOCAL_APIC
In-Reply-To: <20260805082137.1214967-2-jgross@suse.com>
Message-ID: <740aa008-a1ec-5c94-27cd-afad1f1b0495@kernel.org>
References: <20260805082137.1214967-1-jgross@suse.com> <20260805082137.1214967-2-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-ebf023/1785969039-528C9B50-4F71B5FC/0/0
X-purgate-type: clean
X-purgate-size: 765

On Wed, 5 Aug 2026, Juergen Gross wrote:
> CONFIG_XEN depends on CONFIG_X86_LOCAL_APIC already, so the dependency
> of CONFIG_XEN_PVHVM on CONFIG_X86_LOCAL_APIC can be dropped.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  arch/x86/xen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 99b06f5c47cd..bb420a4cb75f 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -52,7 +52,7 @@ config XEN_PV_DOM0
>  
>  config XEN_PVHVM
>  	def_bool y
> -	depends on XEN && X86_LOCAL_APIC
> +	depends on XEN
>  
>  config XEN_PVHVM_SMP
>  	def_bool y
> -- 
> 2.55.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:38:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:38:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383920.1627012 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkFq-0001lO-6Z; Wed, 05 Aug 2026 22:38:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383920.1627012; Wed, 05 Aug 2026 22:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkFq-0001lH-3r; Wed, 05 Aug 2026 22:38:30 +0000
Received: by outflank-mailman (input) for mailman id 1383920;
 Wed, 05 Aug 2026 22:38:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrkFo-0001lB-5H
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:38:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkFn-008Rbs-90
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:38:27 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bb0d-e002-0a2a0a5209dd-0a2a4503e7a4-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:38:27 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bb61-fae8-0a2a45030019-888fbc3352c7-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:38:26 +0200
Received: by mx.zohomail.com with SMTPS id 1785969494811920.453860135087;
 Wed, 5 Aug 2026 15:38:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785969497; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=WMZ0tV0vDY58A1Y2BQNAxpQ7qR3vhS2nDHJ5z6vK3NggI2JpKZlUuxQRO/TCMlPqmHJJsek04N0NaydwJ3LvtleXKutHbvedcQNwRvGXZ1K+zJ5osbI6BE0IFs8F6no14EdfDpEm6Z4ucqKbXScKRWGwSJFzLqfD3RlzM75EWBg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785969497; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=ttnFYpU9leG8PdYp6bKDfbnCt02hGSvDeDU0wyx0J6M=; 
	b=OZjP6ViM/UGD1VPRjqlJ33uVjm0uvOk7hDgLP7rt9h7NWTNa7wyzXfzQs0U0wZ91r6PYZT3mVTjNcM/MwsTMrJ46SvLAK+9Uy8Pwo7B6UmZ3SfJlkVDBnmFl9ppqjIAuzOF11yUgPDUddQ9jLV6/+46pj3lMPfSL75RbEVlLUHM=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785969497;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=ttnFYpU9leG8PdYp6bKDfbnCt02hGSvDeDU0wyx0J6M=;
	b=Z8Ug7BYh1Rd3sa+dU5SlLQpddjmWhBCmFIkNoESM7vqEUhlSfW4k75gkeCjPsMO+
	Wa4pC79On7+tJbqjKNlJ/D7uL7+8AYdPg/ZxZhuAKH8QIUrDkoM6a5u7kTSrRzwsiQF
	zaV/3XzCAUoQF9SBwunB0tryCPuFeW5lJWNxxFxk=
Message-ID: <a5867626-3ff1-4210-a542-fb5ee8cedf57@apertussolutions.com>
Date: Wed, 5 Aug 2026 18:38:18 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 13/24] x86: restrict PHYSDEVOP_* when PV=n
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <5b3ba207-aa18-4ebe-9c8b-2ccf51240698@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <5b3ba207-aa18-4ebe-9c8b-2ccf51240698@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1785969507-76AF94E9-E366E1AD/0/0
X-purgate-type: clean
X-purgate-size: 5015

On 7/28/26 9:19 AM, Jan Beulich wrote:
> hvm_physdev_op() permits through only a subset of sub-ops. The code
> handling other sub-ops is therefore unreachable when PV=n, violating MISRA
> C:2012 rule 2.1. With that the XSM .apic() hook also becomes unreachable /
> dead when PV=n.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> At least for the sub-ops using xsm_apic() IS_ENABLED() cannot be used.
> Therefore #ifdef is used throughout.
> 
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -233,6 +233,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>           break;
>       }
>   
> +#ifdef CONFIG_PV
> +
>       case PHYSDEVOP_pirq_eoi_gmfn_v2:
>       case PHYSDEVOP_pirq_eoi_gmfn_v1: {
>           struct physdev_pirq_eoi_gmfn info;
> @@ -281,6 +283,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>           break;
>       }
>   
> +#endif /* CONFIG_PV */
> +
>       case PHYSDEVOP_irq_status_query: {
>           struct physdev_irq_status_query irq_status_query;
>           ret = -EFAULT;
> @@ -379,6 +383,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>           break;
>       }
>   
> +#ifdef CONFIG_PV
> +
>       case PHYSDEVOP_apic_read: {
>           struct physdev_apic apic;
>           ret = -EFAULT;
> @@ -524,6 +530,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>           break;
>       }
>   
> +#endif /* CONFIG_PV */
> +
>       case PHYSDEVOP_pci_mmcfg_reserved: {
>           struct physdev_pci_mmcfg_reserved info;
>   
> @@ -558,6 +566,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>           break;
>       }
>   
> +#ifdef CONFIG_PV
> +
>       case PHYSDEVOP_restore_msi: {
>           struct physdev_restore_msi restore_msi;
>           struct pci_dev *pdev;
> @@ -589,6 +599,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>           break;
>       }
>   
> +#endif /* CONFIG_PV */
> +
>       case PHYSDEVOP_setup_gsi: {
>           struct physdev_setup_gsi setup_gsi;
>   
> @@ -608,6 +620,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>                                 setup_gsi.polarity);
>           break;
>       }
> +
>       case PHYSDEVOP_get_free_pirq: {
>           struct physdev_get_free_pirq out;
>   
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -648,13 +648,6 @@ static XSM_INLINE int cf_check xsm_mem_s
>       return xsm_default_action(action, current->domain, cd);
>   }
>   
> -static XSM_INLINE int cf_check xsm_apic(
> -    XSM_DEFAULT_ARG struct domain *d, int cmd)
> -{
> -    XSM_ASSERT_ACTION(XSM_PRIV);
> -    return xsm_default_action(action, d, NULL);
> -}
> -
>   static XSM_INLINE int cf_check xsm_machine_memory_map(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> @@ -670,6 +663,13 @@ static XSM_INLINE int cf_check xsm_domai
>   
>   #ifdef CONFIG_PV
>   
> +static XSM_INLINE int cf_check xsm_apic(
> +    XSM_DEFAULT_ARG struct domain *d, int cmd)
> +{
> +    XSM_ASSERT_ACTION(XSM_PRIV);
> +    return xsm_default_action(action, d, NULL);
> +}
> +
>   static XSM_INLINE int cf_check xsm_do_mca(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -131,10 +131,10 @@ XSM_HOOK(int, mem_sharing_op, struct dom
>   XSM_HOOK(int, platform_op, uint32_t)
>   
>   #ifdef CONFIG_X86
> -XSM_HOOK(int, apic, struct domain *, int)
>   XSM_HOOK(int, machine_memory_map)
>   XSM_HOOK(int, domain_memory_map, struct domain *)
>   #ifdef CONFIG_PV
> +XSM_HOOK(int, apic, struct domain *, int)
>   XSM_HOOK(int, do_mca)
>   XSM_HOOK(int, mmu_update, struct domain *, struct domain *, struct domain *,
>                             uint32_t)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1749,6 +1749,19 @@ static int cf_check flask_mem_sharing_op
>   }
>   #endif
>   
> +static int cf_check flask_machine_memory_map(void)
> +{
> +    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP,
> +                                NULL);
> +}
> +
> +static int cf_check flask_domain_memory_map(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
> +}
> +
> +#ifdef CONFIG_PV
> +
>   static int cf_check flask_apic(struct domain *d, int cmd)
>   {
>       uint32_t perm;
> @@ -1769,18 +1782,6 @@ static int cf_check flask_apic(struct do
>       return domain_has_xen(d, perm);
>   }
>   
> -static int cf_check flask_machine_memory_map(void)
> -{
> -    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
> -}
> -
> -static int cf_check flask_domain_memory_map(struct domain *d)
> -{
> -    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
> -}
> -
> -#ifdef CONFIG_PV
> -
>   static int cf_check flask_do_mca(void)
>   {
>       return domain_has_xen(current->domain, XEN__MCA_OP);
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:39:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:39:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383926.1627021 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkGx-0002GW-EC; Wed, 05 Aug 2026 22:39:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383926.1627021; Wed, 05 Aug 2026 22:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkGx-0002GP-BZ; Wed, 05 Aug 2026 22:39:39 +0000
Received: by outflank-mailman (input) for mailman id 1383926;
 Wed, 05 Aug 2026 22:39:37 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrkGv-0002GC-Lz
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:39:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkGv-008Rbs-2v
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:39:37 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bb8e-e002-0a2a0a5209dd-0a2a4506c7a2-18
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:39:37 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bba7-195a-0a2a45060019-888fbc3352cb-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:39:36 +0200
Received: by mx.zohomail.com with SMTPS id 17859695700809.225365282640382;
 Wed, 5 Aug 2026 15:39:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785969572; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=DfC6AhuciVKP71ZJ6MlUTWDfiOrwlWYQrlJlx9nRhQMI3pHlZ/b6GkASfxkxzukVYn/oPr+d/Cnp0YNdtyyB5gFyIf/VuRf4Yy74SaMVLiHRR2xb0uyg5dEmm4+7NrkCYVikjAbp0cNe6Y4WklzJXn01IeVDLxfjH9daBGFt/20=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785969572; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=55C6XabZ5c/mpGx9kDIAwy5gjkAlqjWC61nxx1cPiSg=; 
	b=EZ/Mr+o43rx1hFhK70VJem6hyiL0u/36Mw5EkTZ1Y9p9YMxG6b0bcpq36bIJA0LP5zT4u9C63FbPB8kQF39Tt/qpR/A6p7MgTUgnho55RvwSlrOvNh8t+YjYSL4zSvXf4X/Jq20jnsx1EnEHy6khW8ubXloRroa4ORHumRaTHss=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785969572;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=55C6XabZ5c/mpGx9kDIAwy5gjkAlqjWC61nxx1cPiSg=;
	b=JQVP1zI4rs4dO2W4y23Jst5LQWCxXeMuP2TS905Z8890bopwCqGNb+9ZLTYI5W+m
	W43aiE+dNdwo30reEJr4R304guq6bF+xF4TVs4B7lIgLs6Au7AwDvsPyJKZjGjFUi+B
	WLZjKaDmIIn0ctAnjLfDNks0lClkPtqKOXg0v4DQ=
Message-ID: <06a151ca-df45-4fc5-b52a-23f7b02f41b6@apertussolutions.com>
Date: Wed, 5 Aug 2026 18:39:34 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 14/24] XSM/dummy: fold cf_check into XSM_INLINE
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <6c8f1317-5dd0-4f91-b1b1-820fb43b5c39@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <6c8f1317-5dd0-4f91-b1b1-820fb43b5c39@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-16d1c6/1785969577-FE87577B-3442C33D/0/0
X-purgate-type: clean
X-purgate-size: 25615

On 7/28/26 9:19 AM, Jan Beulich wrote:
> Use of cf_check together with always_inline is pretty pointless, and with
> XSM=n none of the dummy handlers are supposed to have their address taken.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -54,7 +54,7 @@ void __xsm_action_mismatch_detected(void
>    * There is no xsm_default_t argument available, so the value from the assertion
>    * is used to initialize the variable.
>    */
> -#define XSM_INLINE __maybe_unused
> +#define XSM_INLINE __maybe_unused cf_check
>   
>   #define XSM_DEFAULT_ARG /* */
>   #define XSM_DEFAULT_VOID void
> @@ -104,7 +104,7 @@ static always_inline int xsm_default_act
>       }
>   }
>   
> -static XSM_INLINE int cf_check xsm_set_system_active(void)
> +static XSM_INLINE int xsm_set_system_active(void)
>   {
>       struct domain *d = current->domain;
>   
> @@ -121,34 +121,34 @@ static XSM_INLINE int cf_check xsm_set_s
>       return 0;
>   }
>   
> -static XSM_INLINE void cf_check xsm_security_domaininfo(
> +static XSM_INLINE void xsm_security_domaininfo(
>       struct domain *d, struct xen_domctl_getdomaininfo *info)
>   {
>       return;
>   }
>   
> -static XSM_INLINE int cf_check xsm_domain_create(
> +static XSM_INLINE int xsm_domain_create(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t ssidref)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_getdomaininfo(
> +static XSM_INLINE int xsm_getdomaininfo(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_XS_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_set_target(
> +static XSM_INLINE int xsm_set_target(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *e)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_domctl(
> +static XSM_INLINE int xsm_domctl(
>       XSM_DEFAULT_ARG struct domain *d, struct xen_domctl *op)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> @@ -174,61 +174,61 @@ static XSM_INLINE int cf_check xsm_domct
>       }
>   }
>   
> -static XSM_INLINE int cf_check xsm_sysctl(
> +static XSM_INLINE int xsm_sysctl(
>       XSM_DEFAULT_ARG const struct xen_sysctl *op)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_alloc_security_domain(struct domain *d)
> +static XSM_INLINE int xsm_alloc_security_domain(struct domain *d)
>   {
>       return 0;
>   }
>   
> -static XSM_INLINE void cf_check xsm_free_security_domain(struct domain *d)
> +static XSM_INLINE void xsm_free_security_domain(struct domain *d)
>   {
>       return;
>   }
>   
>   #ifdef CONFIG_GRANT_TABLE
>   
> -static XSM_INLINE int cf_check xsm_grant_mapref(
> +static XSM_INLINE int xsm_grant_mapref(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2, uint32_t flags)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_grant_unmapref(
> +static XSM_INLINE int xsm_grant_unmapref(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_grant_setup(
> +static XSM_INLINE int xsm_grant_setup(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_grant_transfer(
> +static XSM_INLINE int xsm_grant_transfer(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_grant_copy(
> +static XSM_INLINE int xsm_grant_copy(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_grant_query_size(
> +static XSM_INLINE int xsm_grant_query_size(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
> @@ -237,28 +237,28 @@ static XSM_INLINE int cf_check xsm_grant
>   
>   #endif /* CONFIG_GRANT_TABLE */
>   
> -static XSM_INLINE int cf_check xsm_memory_exchange(
> +static XSM_INLINE int xsm_memory_exchange(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_memory_adjust_reservation(
> +static XSM_INLINE int xsm_memory_adjust_reservation(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_memory_stat_reservation(
> +static XSM_INLINE int xsm_memory_stat_reservation(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_console_io(
> +static XSM_INLINE int xsm_console_io(
>       XSM_DEFAULT_ARG struct domain *d, int cmd)
>   {
>       XSM_ASSERT_ACTION(XSM_OTHER);
> @@ -272,21 +272,21 @@ static XSM_INLINE int cf_check xsm_conso
>   }
>   
>   #ifdef CONFIG_KEXEC
> -static XSM_INLINE int cf_check xsm_kexec(XSM_DEFAULT_VOID)
> +static XSM_INLINE int xsm_kexec(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   #endif
>   
> -static XSM_INLINE int cf_check xsm_schedop_shutdown(
> +static XSM_INLINE int xsm_schedop_shutdown(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_memory_pin_page(
> +static XSM_INLINE int xsm_memory_pin_page(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2,
>       struct page_info *page)
>   {
> @@ -294,20 +294,20 @@ static XSM_INLINE int cf_check xsm_memor
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_claim_pages(XSM_DEFAULT_ARG struct domain *d)
> +static XSM_INLINE int xsm_claim_pages(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_evtchn_unbound(
> +static XSM_INLINE int xsm_evtchn_unbound(
>       XSM_DEFAULT_ARG struct domain *d, struct evtchn *chn, domid_t id2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_evtchn_interdomain(
> +static XSM_INLINE int xsm_evtchn_interdomain(
>       XSM_DEFAULT_ARG struct domain *d1, struct evtchn *chan1, struct domain *d2,
>       struct evtchn *chan2)
>   {
> @@ -315,72 +315,72 @@ static XSM_INLINE int cf_check xsm_evtch
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE void cf_check xsm_evtchn_close_post(struct evtchn *chn)
> +static XSM_INLINE void xsm_evtchn_close_post(struct evtchn *chn)
>   {
>       return;
>   }
>   
> -static XSM_INLINE int cf_check xsm_evtchn_send(
> +static XSM_INLINE int xsm_evtchn_send(
>       XSM_DEFAULT_ARG struct domain *d, struct evtchn *chn)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, d, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_evtchn_status(
> +static XSM_INLINE int xsm_evtchn_status(
>       XSM_DEFAULT_ARG struct domain *d, struct evtchn *chn)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_evtchn_reset(
> +static XSM_INLINE int xsm_evtchn_reset(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_alloc_security_evtchns(
> +static XSM_INLINE int xsm_alloc_security_evtchns(
>       struct evtchn chn[], unsigned int nr)
>   {
>       return 0;
>   }
>   
> -static XSM_INLINE void cf_check xsm_free_security_evtchns(
> +static XSM_INLINE void xsm_free_security_evtchns(
>       struct evtchn chn[], unsigned int nr)
>   {
>       return;
>   }
>   
> -static XSM_INLINE char *cf_check xsm_show_security_evtchn(
> +static XSM_INLINE char *xsm_show_security_evtchn(
>       struct domain *d, const struct evtchn *chn)
>   {
>       return NULL;
>   }
>   
> -static XSM_INLINE int cf_check xsm_init_hardware_domain(
> +static XSM_INLINE int xsm_init_hardware_domain(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_get_pod_target(
> +static XSM_INLINE int xsm_get_pod_target(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_set_pod_target(
> +static XSM_INLINE int xsm_set_pod_target(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_get_vnumainfo(
> +static XSM_INLINE int xsm_get_vnumainfo(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
> @@ -388,7 +388,7 @@ static XSM_INLINE int cf_check xsm_get_v
>   }
>   
>   #if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
> -static XSM_INLINE int cf_check xsm_get_device_group(
> +static XSM_INLINE int xsm_get_device_group(
>       XSM_DEFAULT_ARG uint32_t machine_bdf)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> @@ -398,14 +398,14 @@ static XSM_INLINE int cf_check xsm_get_d
>   
>   #if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
>   
> -static XSM_INLINE int cf_check xsm_resource_plug_pci(
> +static XSM_INLINE int xsm_resource_plug_pci(
>       XSM_DEFAULT_ARG uint32_t machine_bdf)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_resource_unplug_pci(
> +static XSM_INLINE int xsm_resource_unplug_pci(
>       XSM_DEFAULT_ARG uint32_t machine_bdf)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> @@ -416,14 +416,14 @@ static XSM_INLINE int cf_check xsm_resou
>   
>   #ifdef CONFIG_HAS_PCI
>   
> -static XSM_INLINE int cf_check xsm_resource_setup_pci(
> +static XSM_INLINE int xsm_resource_setup_pci(
>       XSM_DEFAULT_ARG uint32_t machine_bdf)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_resource_setup_gsi(XSM_DEFAULT_ARG int gsi)
> +static XSM_INLINE int xsm_resource_setup_gsi(XSM_DEFAULT_ARG int gsi)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
> @@ -431,47 +431,47 @@ static XSM_INLINE int cf_check xsm_resou
>   
>   #endif /* CONFIG_HAS_PCI */
>   
> -static XSM_INLINE int cf_check xsm_resource_setup_misc(XSM_DEFAULT_VOID)
> +static XSM_INLINE int xsm_resource_setup_misc(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
>   #ifdef CONFIG_HYPFS
> -static XSM_INLINE int cf_check xsm_hypfs_op(XSM_DEFAULT_VOID)
> +static XSM_INLINE int xsm_hypfs_op(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   #endif
>   
> -static XSM_INLINE long cf_check xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
> +static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
>       return -ENOSYS;
>   }
>   
>   #ifdef CONFIG_COMPAT
> -static XSM_INLINE int cf_check xsm_do_compat_op(XEN_GUEST_HANDLE_PARAM(void) op)
> +static XSM_INLINE int xsm_do_compat_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
>       return -ENOSYS;
>   }
>   #endif
>   
> -static XSM_INLINE char *cf_check xsm_show_irq_sid(int irq)
> +static XSM_INLINE char *xsm_show_irq_sid(int irq)
>   {
>       return NULL;
>   }
>   
>   #ifdef CONFIG_HAS_PIRQ
>   
> -static XSM_INLINE int cf_check xsm_map_domain_pirq(
> +static XSM_INLINE int xsm_map_domain_pirq(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_unmap_domain_pirq(
> +static XSM_INLINE int xsm_unmap_domain_pirq(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
> @@ -480,49 +480,49 @@ static XSM_INLINE int cf_check xsm_unmap
>   
>   #endif /* CONFIG_HAS_PIRQ */
>   
> -static XSM_INLINE int cf_check xsm_map_domain_irq(
> +static XSM_INLINE int xsm_map_domain_irq(
>       XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_bind_pt_irq(
> +static XSM_INLINE int xsm_bind_pt_irq(
>       XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_unbind_pt_irq(
> +static XSM_INLINE int xsm_unbind_pt_irq(
>       XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_unmap_domain_irq(
> +static XSM_INLINE int xsm_unmap_domain_irq(
>       XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_irq_permission(
> +static XSM_INLINE int xsm_irq_permission(
>       XSM_DEFAULT_ARG struct domain *d, int pirq, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_iomem_permission(
> +static XSM_INLINE int xsm_iomem_permission(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_iomem_mapping(
> +static XSM_INLINE int xsm_iomem_mapping(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
> @@ -530,7 +530,7 @@ static XSM_INLINE int cf_check xsm_iomem
>   }
>   
>   #ifdef CONFIG_HAS_VPCI
> -static XSM_INLINE int cf_check xsm_iomem_mapping_vpci(
> +static XSM_INLINE int xsm_iomem_mapping_vpci(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
> @@ -539,7 +539,7 @@ static XSM_INLINE int cf_check xsm_iomem
>   #endif
>   
>   #ifdef CONFIG_HAS_PCI
> -static XSM_INLINE int cf_check xsm_pci_config_permission(
> +static XSM_INLINE int xsm_pci_config_permission(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t machine_bdf, uint16_t start,
>       uint16_t end, uint8_t access)
>   {
> @@ -548,21 +548,21 @@ static XSM_INLINE int cf_check xsm_pci_c
>   }
>   #endif /* CONFIG_HAS_PCI */
>   
> -static XSM_INLINE int cf_check xsm_add_to_physmap(
> +static XSM_INLINE int xsm_add_to_physmap(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_remove_from_physmap(
> +static XSM_INLINE int xsm_remove_from_physmap(
>       XSM_DEFAULT_ARG struct domain *d1, struct domain *d2)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d1, d2);
>   }
>   
> -static XSM_INLINE int cf_check xsm_map_gmfn_foreign(
> +static XSM_INLINE int xsm_map_gmfn_foreign(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
> @@ -571,14 +571,14 @@ static XSM_INLINE int cf_check xsm_map_g
>   
>   #ifdef CONFIG_HVM
>   
> -static XSM_INLINE int cf_check xsm_hvm_param(
> +static XSM_INLINE int xsm_hvm_param(
>       XSM_DEFAULT_ARG struct domain *d, unsigned long op)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_hvm_param_altp2mhvm(
> +static XSM_INLINE int xsm_hvm_param_altp2mhvm(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
> @@ -588,7 +588,7 @@ static XSM_INLINE int cf_check xsm_hvm_p
>   #endif /* CONFIG_HVM */
>   
>   #ifdef CONFIG_ALTP2M
> -static XSM_INLINE int cf_check xsm_hvm_altp2mhvm_op(
> +static XSM_INLINE int xsm_hvm_altp2mhvm_op(
>       XSM_DEFAULT_ARG struct domain *d, uint64_t mode, uint32_t op)
>   {
>       XSM_ASSERT_ACTION(XSM_OTHER);
> @@ -610,7 +610,7 @@ static XSM_INLINE int cf_check xsm_hvm_a
>   #endif /* CONFIG_ALTP2M */
>   
>   #ifdef CONFIG_VM_EVENT
> -static XSM_INLINE int cf_check xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
> +static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> @@ -618,7 +618,7 @@ static XSM_INLINE int cf_check xsm_mem_a
>   #endif
>   
>   #ifdef CONFIG_MEM_PAGING
> -static XSM_INLINE int cf_check xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
> +static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> @@ -626,14 +626,14 @@ static XSM_INLINE int cf_check xsm_mem_p
>   #endif
>   
>   #ifdef CONFIG_MEM_SHARING
> -static XSM_INLINE int cf_check xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
> +static XSM_INLINE int xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   #endif
>   
> -static XSM_INLINE int cf_check xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
> +static XSM_INLINE int xsm_platform_op(XSM_DEFAULT_ARG uint32_t op)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
> @@ -641,20 +641,20 @@ static XSM_INLINE int cf_check xsm_platf
>   
>   #ifdef CONFIG_X86
>   
> -static XSM_INLINE int cf_check xsm_mem_sharing_op(
> +static XSM_INLINE int xsm_mem_sharing_op(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *cd, int op)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, cd);
>   }
>   
> -static XSM_INLINE int cf_check xsm_machine_memory_map(XSM_DEFAULT_VOID)
> +static XSM_INLINE int xsm_machine_memory_map(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_domain_memory_map(
> +static XSM_INLINE int xsm_domain_memory_map(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
> @@ -663,20 +663,20 @@ static XSM_INLINE int cf_check xsm_domai
>   
>   #ifdef CONFIG_PV
>   
> -static XSM_INLINE int cf_check xsm_apic(
> +static XSM_INLINE int xsm_apic(
>       XSM_DEFAULT_ARG struct domain *d, int cmd)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, d, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_do_mca(XSM_DEFAULT_VOID)
> +static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, NULL);
>   }
>   
> -static XSM_INLINE int cf_check xsm_mmu_update(
> +static XSM_INLINE int xsm_mmu_update(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *t, struct domain *f,
>       uint32_t flags)
>   {
> @@ -689,14 +689,14 @@ static XSM_INLINE int cf_check xsm_mmu_u
>       return rc;
>   }
>   
> -static XSM_INLINE int cf_check xsm_mmuext_op(
> +static XSM_INLINE int xsm_mmuext_op(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *f)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
>       return xsm_default_action(action, d, f);
>   }
>   
> -static XSM_INLINE int cf_check xsm_update_va_mapping(
> +static XSM_INLINE int xsm_update_va_mapping(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *f, l1_pgentry_t pte)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
> @@ -706,7 +706,7 @@ static XSM_INLINE int cf_check xsm_updat
>   #endif /* CONFIG_PV */
>   
>   #if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
> -static XSM_INLINE int cf_check xsm_priv_mapping(
> +static XSM_INLINE int xsm_priv_mapping(
>       XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>   {
>       XSM_ASSERT_ACTION(XSM_TARGET);
> @@ -714,21 +714,21 @@ static XSM_INLINE int cf_check xsm_priv_
>   }
>   #endif
>   
> -static XSM_INLINE int cf_check xsm_ioport_permission(
> +static XSM_INLINE int xsm_ioport_permission(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_ioport_mapping(
> +static XSM_INLINE int xsm_ioport_mapping(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int cf_check xsm_pmu_op(
> +static XSM_INLINE int xsm_pmu_op(
>       XSM_DEFAULT_ARG struct domain *d, unsigned int op)
>   {
>       XSM_ASSERT_ACTION(XSM_OTHER);
> @@ -747,7 +747,7 @@ static XSM_INLINE int cf_check xsm_pmu_o
>   #endif /* CONFIG_X86 */
>   
>   #ifdef CONFIG_IOREQ_SERVER
> -static XSM_INLINE int cf_check xsm_dm_op(XSM_DEFAULT_ARG struct domain *d)
> +static XSM_INLINE int xsm_dm_op(XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> @@ -755,24 +755,24 @@ static XSM_INLINE int cf_check xsm_dm_op
>   #endif
>   
>   #ifdef CONFIG_ARGO
> -static XSM_INLINE int cf_check xsm_argo_enable(const struct domain *d)
> +static XSM_INLINE int xsm_argo_enable(const struct domain *d)
>   {
>       return 0;
>   }
>   
> -static XSM_INLINE int cf_check xsm_argo_register_single_source(
> +static XSM_INLINE int xsm_argo_register_single_source(
>       const struct domain *d, const struct domain *t)
>   {
>       return 0;
>   }
>   
> -static XSM_INLINE int cf_check xsm_argo_register_any_source(
> +static XSM_INLINE int xsm_argo_register_any_source(
>       const struct domain *d)
>   {
>       return 0;
>   }
>   
> -static XSM_INLINE int cf_check xsm_argo_send(
> +static XSM_INLINE int xsm_argo_send(
>       const struct domain *d, const struct domain *t)
>   {
>       return 0;
> @@ -780,7 +780,7 @@ static XSM_INLINE int cf_check xsm_argo_
>   
>   #endif /* CONFIG_ARGO */
>   
> -static XSM_INLINE int cf_check xsm_get_domain_state(
> +static XSM_INLINE int xsm_get_domain_state(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_XS_PRIV);
> @@ -788,7 +788,7 @@ static XSM_INLINE int cf_check xsm_get_d
>   }
>   
>   #include <public/version.h>
> -static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
> +static XSM_INLINE int xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
>   {
>       XSM_ASSERT_ACTION(XSM_OTHER);
>       switch ( op )
> @@ -815,7 +815,7 @@ static XSM_INLINE int cf_check xsm_xen_v
>       }
>   }
>   
> -static XSM_INLINE int cf_check xsm_domain_resource_map(
> +static XSM_INLINE int xsm_domain_resource_map(
>       XSM_DEFAULT_ARG struct domain *d)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:40:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:40:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383935.1627029 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkHi-0003kb-P2; Wed, 05 Aug 2026 22:40:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383935.1627029; Wed, 05 Aug 2026 22:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkHi-0003kU-MU; Wed, 05 Aug 2026 22:40:26 +0000
Received: by outflank-mailman (input) for mailman id 1383935;
 Wed, 05 Aug 2026 22:40:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrkHh-0003kK-PW
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:40:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkHh-008Rno-6f
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:40:25 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bb5e-bab6-0a2a0a5309dd-0a2a4504a8f0-48
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:40:25 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bbd7-b57f-0a2a45040019-888fbc3352ce-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:40:24 +0200
Received: by mx.zohomail.com with SMTPS id 1785969620651244.58061568349672;
 Wed, 5 Aug 2026 15:40:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785969621; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=CP9Blk9FJeGRefQp4c4yqBJdZ14hNzBaYbAHq0DfWpYvAVDPl8x8DnSEYWBbw93C+IbkRTvKnyWYLiX373qgMkE4TZVvOhBmhF96ZWJ0B4hayGl7d2/PjkWEqvfPn4J03RQQ/Ip4QQlE0AcOScGi1XOZ1pkqUBffDzh+hD8u0dQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785969621; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=exdTnw8wAxnwKL2WEgMO2tqs2wU8iaIgCY+olaqOOdI=; 
	b=DONCxbJeBfuy25e6KJglT1mpIFc0+dA8ENywiD8Q9k2NBi3YTyTI72ERk+9EZuDKw0JNbixMgOSC+xpnWjTu9XjOMYj5/fH+ia6wrM6Q6JMS4aL/33VUHm5MHjtcrzG8tpYI/1CGxQueKxaxkgJWCVeyRW1AqdbHncLkpJ21Yto=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785969621;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=exdTnw8wAxnwKL2WEgMO2tqs2wU8iaIgCY+olaqOOdI=;
	b=A2awKJGYKNjdvolabq9kmneyZdC8CK789na+aZia6l39MesECoIm+17UXjqcnXPT
	lJo0eQvpwHdi1I7zQ4bOBAIG7qf6sJVTn3LRNTSJiKC/MzT3xRIRA5LMyiYI3wZeuj1
	lb/rEF/LaCMQAyrbrGLSyOESyDUtyilHnw7oQM7E=
Message-ID: <b7ce1840-1849-4c95-ae57-fbd8bc164701@apertussolutions.com>
Date: Wed, 5 Aug 2026 18:40:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 15/24] XSM/dummy: drop redundant return statements
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <b2dfb144-b475-4a64-b71d-4566691a9deb@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <b2dfb144-b475-4a64-b71d-4566691a9deb@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-ebf023/1785969625-C10DDB50-BB59C97B/0/0
X-purgate-type: clean
X-purgate-size: 1457

On 7/28/26 9:20 AM, Jan Beulich wrote:
> They're meaningless when no value is returned.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -123,9 +123,7 @@ static XSM_INLINE int xsm_set_system_act
>   
>   static XSM_INLINE void xsm_security_domaininfo(
>       struct domain *d, struct xen_domctl_getdomaininfo *info)
> -{
> -    return;
> -}
> +{}
>   
>   static XSM_INLINE int xsm_domain_create(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t ssidref)
> @@ -187,9 +185,7 @@ static XSM_INLINE int xsm_alloc_security
>   }
>   
>   static XSM_INLINE void xsm_free_security_domain(struct domain *d)
> -{
> -    return;
> -}
> +{}
>   
>   #ifdef CONFIG_GRANT_TABLE
>   
> @@ -316,9 +312,7 @@ static XSM_INLINE int xsm_evtchn_interdo
>   }
>   
>   static XSM_INLINE void xsm_evtchn_close_post(struct evtchn *chn)
> -{
> -    return;
> -}
> +{}
>   
>   static XSM_INLINE int xsm_evtchn_send(
>       XSM_DEFAULT_ARG struct domain *d, struct evtchn *chn)
> @@ -349,9 +343,7 @@ static XSM_INLINE int xsm_alloc_security
>   
>   static XSM_INLINE void xsm_free_security_evtchns(
>       struct evtchn chn[], unsigned int nr)
> -{
> -    return;
> -}
> +{}
>   
>   static XSM_INLINE char *xsm_show_security_evtchn(
>       struct domain *d, const struct evtchn *chn)
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:42:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:42:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383946.1627040 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkK0-0004IO-58; Wed, 05 Aug 2026 22:42:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383946.1627040; Wed, 05 Aug 2026 22:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkK0-0004IH-1F; Wed, 05 Aug 2026 22:42:48 +0000
Received: by outflank-mailman (input) for mailman id 1383946;
 Wed, 05 Aug 2026 22:42:47 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrkJz-0004IA-6w
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:42:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkJx-00GIdT-Vw
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:42:45 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bc64-2eae-0a2a0a5409dd-0a2a450b81b2-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:42:45 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73bc64-b7e8-0a2a450b0019-888fbc335273-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:42:45 +0200
Received: by mx.zohomail.com with SMTPS id 1785969752886426.49762714455005;
 Wed, 5 Aug 2026 15:42:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785969756; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=OtjRAeOB3W63X7nJO+6k23SAistada/5vTpF/PZIMtgwD0YaABmYuUFYNVKXvyjtj+v4i0gHXlWU7sa7o3/fssc1cGFO0grBBW1JO4csYdGIEwYQgRGmWhxHHVktQ4mbOE8TEvT008gqkc20LumRDKHW2/n4BXRJ1bOKABumwU8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785969756; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=lruKykF7Bez3AHxlAg46tPNe7nOSsS4PSeVZZpQY56U=; 
	b=SUs/P0uuFq+gnC2gKkL2KfEZF9eLXnAQiHvjmv7tVVL4t3B016Sc6QzrT3Q3es5Y3AUeqqU++Mt221etNFzIgf1LXOe0V5wuizGE8/1UeXgx8i4GIVU2+XVECsKEXr3PM4q2weadv0A0uZ6WZ4PnD+3b+Pc8QhtBRz6rzWlWJXM=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785969756;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=lruKykF7Bez3AHxlAg46tPNe7nOSsS4PSeVZZpQY56U=;
	b=GClTKLDY4y3an7YY3lUOwM//tackaflunC+/xBpeSNvDPPNtwEPjNSJMHBEO1fJ8
	W11o17NJBMs0lRsijG0OfCzyHQDVd3JI/qTp6YbtgvSR8AC9xSlGE7GFUOhjiVNxOCf
	cBbga1ufKeBK/7iTE2VYHhQB/sstHRZ8jGF6r4Go=
Message-ID: <e93eab10-7c96-4898-a5f6-8ced35a72bd2@apertussolutions.com>
Date: Wed, 5 Aug 2026 18:42:36 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 16/24] XSM: suppress hypercall when XSM=n
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <b533ed9f-1ea8-4d27-8420-2159ccd27cc8@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <b533ed9f-1ea8-4d27-8420-2159ccd27cc8@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-42698a/1785969765-AB8D19EA-98C82AB8/0/0
X-purgate-type: clean
X-purgate-size: 3089

On 7/28/26 9:20 AM, Jan Beulich wrote:
> This can be easily done in hypercall-defs.c, thus avoiding the need to
> dive into xsm/ when building Xen, just to add code which does what is done
> for an absent hypercall handler anyway (returning -ENOSYS).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -458,7 +458,7 @@ CFLAGS += -I$(objtree)/arch/$(SRCARCH)/i
>   ALL_OBJS-y                := common/built_in.o
>   ALL_OBJS-y                += drivers/built_in.o
>   ALL_OBJS-y                += lib/built_in.o
> -ALL_OBJS-y                += xsm/built_in.o
> +ALL_OBJS-$(CONFIG_XSM)    += xsm/built_in.o
>   ALL_OBJS-y                += arch/$(SRCARCH)/built_in.o
>   ALL_OBJS-$(CONFIG_CRYPTO) += crypto/built_in.o
>   
> --- a/xen/include/hypercall-defs.c
> +++ b/xen/include/hypercall-defs.c
> @@ -119,7 +119,9 @@ prefix: do PREFIX_compat
>   xen_version(int cmd, void *arg)
>   vcpu_op(int cmd, unsigned int vcpuid, void *arg)
>   sched_op(int cmd, void *arg)
> +#ifdef CONFIG_XSM
>   xsm_op(void *op)
> +#endif
>   callback_op(int cmd, const void *arg)
>   #ifdef CONFIG_ARGO
>   argo_op(unsigned int cmd, void *arg1, void *arg2, unsigned long arg3, unsigned long arg4)
> @@ -264,7 +266,9 @@ set_segment_base                   do:2
>   #ifdef CONFIG_PV
>   mmuext_op                          compat:2 do:2     compat   do       -
>   #endif
> +#ifdef CONFIG_XSM
>   xsm_op                             compat   do       compat   do       do
> +#endif
>   nmi_op                             compat   do       -        -        -
>   sched_op                           compat   do       compat   do       do
>   callback_op                        compat   do       -        -        -
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -437,6 +437,8 @@ static XSM_INLINE int xsm_hypfs_op(XSM_D
>   }
>   #endif
>   
> +#ifdef CONFIG_XSM
> +
>   static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
>       return -ENOSYS;
> @@ -449,6 +451,8 @@ static XSM_INLINE int xsm_do_compat_op(X
>   }
>   #endif
>   
> +#endif /* CONFIG_XSM */
> +
>   static XSM_INLINE char *xsm_show_irq_sid(int irq)
>   {
>       return NULL;
> --- a/xen/xsm/Makefile
> +++ b/xen/xsm/Makefile
> @@ -1,6 +1,6 @@
>   obj-y += xsm_core.o
> -obj-$(CONFIG_XSM) += xsm_policy.o
> -obj-$(CONFIG_XSM) += dummy.o
> +obj-y += xsm_policy.o
> +obj-y += dummy.o
>   obj-$(CONFIG_XSM_SILO) += silo.o
>   
>   obj-$(CONFIG_XSM_FLASK) += flask/
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -18,8 +18,6 @@
>   #include <xen/hypercall.h>
>   #include <xsm/xsm.h>
>   
> -#ifdef CONFIG_XSM
> -
>   #ifdef CONFIG_MULTIBOOT
>   #include <asm/bootinfo.h>
>   #include <asm/setup.h>
> @@ -216,8 +214,6 @@ bool __init has_xsm_magic(paddr_t start)
>   }
>   #endif
>   
> -#endif
> -
>   long do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
>       return xsm_do_xsm_op(op);
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolution.com>


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:45:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:45:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383955.1627048 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkMZ-0004pq-Ha; Wed, 05 Aug 2026 22:45:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383955.1627048; Wed, 05 Aug 2026 22:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkMZ-0004pi-Du; Wed, 05 Aug 2026 22:45:27 +0000
Received: by outflank-mailman (input) for mailman id 1383955;
 Wed, 05 Aug 2026 22:45:26 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wrkMY-0004pc-5E
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:45:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkMX-001qHF-4f
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:45:25 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73bc77-2eae-0a2a0a5409dd-0a2a4504dc7a-30
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:45:25 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73bd03-b57f-0a2a45040019-aceafc1fa802-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:45:24 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id A855B42E90;
 Wed,  5 Aug 2026 22:45:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E77F21F000E9;
 Wed,  5 Aug 2026 22:45:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1785969922;
	bh=3d3XFROd8+sbFsK8tpt4qnvKUt7FVBYbqAtzzam2GJw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=LlwwsD176RfWsrVexLR7F8hO3K5O5ZgRQ80M4oMI+GHkCpPu4qctzNdrfJjNz5AIq
	 hLbqGEmh4+w4m+NZ2x11Zy1CoqM21IuaxZFGAJh4Nn6BZfKemNHEc9W2cGbeomRqAR
	 dw1cFxbu3EFQaYy7DMemmVitp/Rvtwkt8ixSq2ITGNKkeunSLNRP/of+HiJB13b9cu
	 zmvU5t0XceRKHATS0gnt7jQ9NCu4ZRPkUHrRmqj6Cs0XMlVAJyJ/zdbuuCDle56Lq/
	 i3fSpdq3GnHOsuVFH3Cg2b4N94YioS0fVUJciTtFC9yafnIuzy3amlu3lklgBl5XZu
	 VrW5Sj8MFIOJw==
Date: Wed, 5 Aug 2026 15:45:20 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Juergen Gross <jgross@suse.com>
cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
    Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
    Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
    "H. Peter Anvin" <hpa@zytor.com>, 
    Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM
In-Reply-To: <20260805082137.1214967-3-jgross@suse.com>
Message-ID: <00aabcc8-cbdf-b7b9-b253-c7a1f46a22bd@kernel.org>
References: <20260805082137.1214967-1-jgross@suse.com> <20260805082137.1214967-3-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-ebf023/1785969925-C30CDB50-B8D71824/0/0
X-purgate-type: clean
X-purgate-size: 7958

On Wed, 5 Aug 2026, Juergen Gross wrote:
> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
> 
> In Xen specific x86 code it can be just dropped, in non-Xen specific
> x86 code it can be replaced with CONFIG_XEN.
> 
> In architecture independent code it is used only where CONFIG_XEN is
> defined, so it can be replaced with CONFIG_X86 there.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

While I think there is value in compiling a tiny PV-only kernel (in
fact I even have a real-world use case for it) the code addition is
minimal and also considering your reply to Andrew:

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  arch/x86/include/asm/idtentry.h   |  2 +-
>  arch/x86/kernel/cpu/hypervisor.c  |  2 +-
>  arch/x86/xen/Kconfig              | 10 +++-------
>  arch/x86/xen/Makefile             |  9 ++++-----
>  arch/x86/xen/time.c               |  2 --
>  arch/x86/xen/xen-ops.h            |  4 ----
>  drivers/xen/Kconfig               |  2 +-
>  drivers/xen/events/events_base.c  |  7 -------
>  drivers/xen/xenbus/xenbus_probe.c |  2 +-
>  include/xen/platform_pci.h        |  6 +++---
>  10 files changed, 14 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
> index 20f548702404..f400cfac69a6 100644
> --- a/arch/x86/include/asm/idtentry.h
> +++ b/arch/x86/include/asm/idtentry.h
> @@ -745,7 +745,7 @@ DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,		sysvec_hyperv_stimer0);
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_acrn_hv_callback);
>  #endif
>  
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_XEN
>  DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,	sysvec_xen_hvm_callback);
>  #endif
>  
> diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
> index f3e9219845e8..73428afca796 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -31,7 +31,7 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] =
>  #ifdef CONFIG_XEN_PV
>  	&x86_hyper_xen_pv,
>  #endif
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_XEN
>  	&x86_hyper_xen_hvm,
>  #endif
>  	&x86_hyper_vmware,
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index bb420a4cb75f..9e5bb51eecf4 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,24 +50,20 @@ config XEN_PV_DOM0
>  	def_bool y
>  	depends on XEN_PV && XEN_DOM0
>  
> -config XEN_PVHVM
> -	def_bool y
> -	depends on XEN
> -
>  config XEN_PVHVM_SMP
>  	def_bool y
> -	depends on XEN_PVHVM && SMP
> +	depends on XEN && SMP
>  
>  config XEN_PVHVM_GUEST
>  	bool "Xen PVHVM guest support"
>  	default y
> -	depends on XEN_PVHVM && PCI
> +	depends on XEN && PCI
>  	help
>  	  Support running as a Xen PVHVM guest.
>  
>  config XEN_PVH
>  	bool "Xen PVH guest support"
> -	depends on XEN && XEN_PVHVM && ACPI
> +	depends on XEN && ACPI
>  	select PVH
>  	help
>  	  Support for running as a Xen PVH guest.
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 717264ae269b..32d651aa9bc2 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -16,11 +16,10 @@ obj-y				+= mmu.o
>  obj-y				+= time.o
>  obj-y				+= grant-table.o
>  obj-y				+= suspend.o
> -
> -obj-$(CONFIG_XEN_PVHVM)		+= enlighten_hvm.o
> -obj-$(CONFIG_XEN_PVHVM)		+= mmu_hvm.o
> -obj-$(CONFIG_XEN_PVHVM)		+= suspend_hvm.o
> -obj-$(CONFIG_XEN_PVHVM)		+= platform-pci-unplug.o
> +obj-y				+= enlighten_hvm.o
> +obj-y				+= mmu_hvm.o
> +obj-y				+= suspend_hvm.o
> +obj-y				+= platform-pci-unplug.o
>  
>  obj-$(CONFIG_XEN_PV)		+= setup.o
>  obj-$(CONFIG_XEN_PV)		+= apic.o
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index d62c14334b35..5c7822254a01 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -586,7 +586,6 @@ void __init xen_init_time_ops(void)
>  		x86_platform.set_wallclock = xen_set_wallclock;
>  }
>  
> -#ifdef CONFIG_XEN_PVHVM
>  static void xen_hvm_setup_cpu_clockevents(void)
>  {
>  	int cpu = smp_processor_id();
> @@ -643,7 +642,6 @@ void __init xen_hvm_init_time_ops(void)
>  
>  	hvm_time_initialized = true;
>  }
> -#endif
>  
>  /* Kernel parameter to specify Xen timer slop */
>  static int __init parse_xen_timer_slop(char *ptr)
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index dc265bdda24d..47eebbb3684a 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -236,11 +236,7 @@ void xen_pin_vcpu(int cpu);
>  
>  void xen_emergency_restart(void);
>  
> -#ifdef CONFIG_XEN_PVHVM
>  void xen_hvm_post_suspend(int suspend_cancelled);
> -#else
> -static inline void xen_hvm_post_suspend(int suspend_cancelled) {}
> -#endif
>  
>  /*
>   * The maximum amount of extra memory compared to the base size.  The
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index f9a35ed266ec..cfb517cd77dc 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -311,7 +311,7 @@ config XEN_EFI
>  
>  config XEN_AUTO_XLATE
>  	def_bool y
> -	depends on ARM || ARM64 || XEN_PVHVM
> +	depends on ARM || ARM64 || X86
>  	help
>  	  Support for auto-translated physmap guests.
>  
> diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
> index 6ea945508a89..fd16d652c81f 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -2180,7 +2180,6 @@ static struct irq_chip xen_percpu_chip __read_mostly = {
>  };
>  
>  #ifdef CONFIG_X86
> -#ifdef CONFIG_XEN_PVHVM
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -2242,12 +2241,6 @@ static __init void xen_alloc_callback_vector(void)
>  	pr_info("Xen HVM callback vector for event delivery is enabled\n");
>  	sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_xen_hvm_callback);
>  }
> -#else
> -void xen_setup_callback_vector(void) {}
> -static inline void xen_init_setup_upcall_vector(void) {}
> -int xen_set_upcall_vector(unsigned int cpu) {}
> -static inline void xen_alloc_callback_vector(void) {}
> -#endif /* CONFIG_XEN_PVHVM */
>  #endif /* CONFIG_X86 */
>  
>  bool xen_fifo_events = true;
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index fafb2b84fa5c..082b8c1fee8e 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -831,7 +831,7 @@ static void xenbus_probe(void)
>   */
>  static bool xs_hvm_defer_init_for_callback(void)
>  {
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_X86
>  	return xen_store_domain_type == XS_HVM &&
>  		!xen_have_vector_callback;
>  #else
> diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
> index e51e7cb71a85..267040c1f504 100644
> --- a/include/xen/platform_pci.h
> +++ b/include/xen/platform_pci.h
> @@ -30,7 +30,7 @@
>  static inline int xen_must_unplug_nics(void) {
>  #if (defined(CONFIG_XEN_NETDEV_FRONTEND) || \
>  		defined(CONFIG_XEN_NETDEV_FRONTEND_MODULE)) && \
> -		defined(CONFIG_XEN_PVHVM)
> +		defined(CONFIG_X86)
>          return 1;
>  #else
>          return 0;
> @@ -40,14 +40,14 @@ static inline int xen_must_unplug_nics(void) {
>  static inline int xen_must_unplug_disks(void) {
>  #if (defined(CONFIG_XEN_BLKDEV_FRONTEND) || \
>  		defined(CONFIG_XEN_BLKDEV_FRONTEND_MODULE)) && \
> -		defined(CONFIG_XEN_PVHVM)
> +		defined(CONFIG_X86)
>          return 1;
>  #else
>          return 0;
>  #endif
>  }
>  
> -#if defined(CONFIG_XEN_PVHVM)
> +#if defined(CONFIG_X86)
>  extern bool xen_has_pv_devices(void);
>  extern bool xen_has_pv_disk_devices(void);
>  extern bool xen_has_pv_nic_devices(void);
> -- 
> 2.55.0
> 


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:47:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:47:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383962.1627057 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkOG-0005SN-RQ; Wed, 05 Aug 2026 22:47:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383962.1627057; Wed, 05 Aug 2026 22:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkOG-0005SG-Nl; Wed, 05 Aug 2026 22:47:12 +0000
Received: by outflank-mailman (input) for mailman id 1383962;
 Wed, 05 Aug 2026 22:47:11 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wrkOF-0005SA-12
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:47:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkOE-005shb-EJ
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:47:10 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73bd04-e002-0a2a0a5209dd-0a2a4508ab58-36
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:47:10 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73bd6c-f659-0a2a45080019-aceafc1f8bae-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:47:10 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 423C9439F0;
 Wed,  5 Aug 2026 22:47:08 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 636D81F000E9;
 Wed,  5 Aug 2026 22:47:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1785970028;
	bh=fuuPEvAgsHQj9nsqLXSKpXJzZS7FnT2ffJxVGZb1cbA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=cz/EpjzlrGUmxt+B0JJyEawyTl6rwJbKaxw6SkzKrj6S4yhYdGRNOsyxG2x4OD+jl
	 yWCl4Kn26ujSZrB0Oh9FFklTurJ4MoF0dPRBOdv2DlbjGh02l/1jRlzTIR/8zcAFKH
	 X2RZjl4NkdVKGtKl956zpqWN+23Io66ZlMChieQl4BWxpMmrYgBOlLfswWvmXtqudT
	 MIdXFKwZwxG2Txe9XbdjsucTEQsEXoUrpzNQeIwZSBah2SZ/KSaz1quHzm/vTWiitT
	 wH2+yCcRQ6hpDUI4CJq+YTeu0AfftbUJeEjDpUfK88+t+FJB98hG8kFu9FUgZOJbTE
	 TXdV3qAiKby0w==
Date: Wed, 5 Aug 2026 15:47:06 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Juergen Gross <jgross@suse.com>
cc: linux-kernel@vger.kernel.org, Stefano Stabellini <sstabellini@kernel.org>, 
    Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>, 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/4] xen: Drop CONFIG_XEN_AUTO_XLATE
In-Reply-To: <20260805082137.1214967-4-jgross@suse.com>
Message-ID: <fcdf9321-c4bf-216e-7be9-395ba0f20df4@kernel.org>
References: <20260805082137.1214967-1-jgross@suse.com> <20260805082137.1214967-4-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-c1860d/1785970030-CFED287B-37B27DC7/0/0
X-purgate-type: clean
X-purgate-size: 4109

On Wed, 5 Aug 2026, Juergen Gross wrote:
> CONFIG_XEN_AUTO_XLATE is referenced only in code built with CONFIG_XEN
> enabled. As it is enabled for all architectures supporting Xen, it can
> be just dropped.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> ---
>  drivers/xen/Kconfig   |  6 ------
>  drivers/xen/Makefile  |  2 +-
>  drivers/xen/privcmd.c |  4 ++--
>  include/xen/xen-ops.h | 22 ----------------------
>  4 files changed, 3 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index cfb517cd77dc..32e35a8580ee 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -309,12 +309,6 @@ config XEN_EFI
>  	def_bool y
>  	depends on (ARM || ARM64 || X86_64) && EFI
>  
> -config XEN_AUTO_XLATE
> -	def_bool y
> -	depends on ARM || ARM64 || X86
> -	help
> -	  Support for auto-translated physmap guests.
> -
>  config XEN_ACPI
>  	def_bool y
>  	depends on X86 && ACPI
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index c0503f1c7d5b..6ce2e2a52d47 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,6 +2,7 @@
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  obj-y	+= grant-table.o features.o balloon.o manage.o time.o
>  obj-y	+= mem-reservation.o
> +obj-y	+= xlate_mmu.o
>  obj-y	+= events/
>  obj-y	+= xenbus/
>  
> @@ -29,7 +30,6 @@ obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
>  obj-$(CONFIG_XEN_EFI)			+= efi.o
>  obj-$(CONFIG_XEN_SCSI_BACKEND)		+= xen-scsiback.o
> -obj-$(CONFIG_XEN_AUTO_XLATE)		+= xlate_mmu.o
>  obj-$(CONFIG_XEN_PVCALLS_BACKEND)	+= pvcalls-back.o
>  obj-$(CONFIG_XEN_PVCALLS_FRONTEND)	+= pvcalls-front.o
>  xen-evtchn-y				:= evtchn.o
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 725a49a0eee7..7cfc28f1bb86 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -794,7 +794,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
>  		goto out;
>  	}
>  
> -	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
> +	if (!xen_pv_domain()) {
>  		unsigned int nr = DIV_ROUND_UP(kdata.num, XEN_PFN_PER_PAGE);
>  		struct page **pages;
>  		unsigned int i;
> @@ -825,7 +825,7 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
>  	if (rc)
>  		goto out;
>  
> -	if (IS_ENABLED(CONFIG_XEN_AUTO_XLATE) && !xen_pv_domain()) {
> +	if (!xen_pv_domain()) {
>  		rc = xen_remap_vma_range(vma, kdata.addr, kdata.num << PAGE_SHIFT);
>  	} else {
>  		unsigned int domid =
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 496e6013c689..15e0c3f4b7bb 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -59,7 +59,6 @@ static inline int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
>  
>  struct vm_area_struct;
>  
> -#ifdef CONFIG_XEN_AUTO_XLATE
>  int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>  			      unsigned long addr,
>  			      xen_pfn_t *gfn, int nr,
> @@ -68,27 +67,6 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>  			      struct page **pages);
>  int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
>  			      int nr, struct page **pages);
> -#else
> -/*
> - * These two functions are called from arch/x86/xen/mmu.c and so stubs
> - * are needed for a configuration not specifying CONFIG_XEN_AUTO_XLATE.
> - */
> -static inline int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> -					    unsigned long addr,
> -					    xen_pfn_t *gfn, int nr,
> -					    int *err_ptr, pgprot_t prot,
> -					    unsigned int domid,
> -					    struct page **pages)
> -{
> -	return -EOPNOTSUPP;
> -}
> -
> -static inline int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
> -					    int nr, struct page **pages)
> -{
> -	return -EOPNOTSUPP;
> -}
> -#endif
>  
>  int xen_remap_vma_range(struct vm_area_struct *vma, unsigned long addr,
>  			unsigned long len);
> -- 
> 2.55.0
> 


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 22:49:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 22:49:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383971.1627066 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkQZ-0006HU-8t; Wed, 05 Aug 2026 22:49:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383971.1627066; Wed, 05 Aug 2026 22:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkQZ-0006HN-61; Wed, 05 Aug 2026 22:49:35 +0000
Received: by outflank-mailman (input) for mailman id 1383971;
 Wed, 05 Aug 2026 22:49:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wrkQX-0006HG-PV
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 22:49:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkQW-00AyQD-W0
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:49:33 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73bdca-5cb7-0a2a0a5109dd-0a2a450584ba-34
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:49:32 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a73bdfb-4cb1-0a2a45050019-aceafc1fd156-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:49:32 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 0EA3940815;
 Wed,  5 Aug 2026 22:49:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88E261F000E9;
 Wed,  5 Aug 2026 22:49:29 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1785970170;
	bh=fHVmsCi75+bOy9xF1TMBrC/j7NUcRqJEe7b8M5dGgho=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=Uq/0Az7dFA0DuUlaa/qWDjeOEXo6q0B1nwKSMlQpZbklPFPI5YVDoI7McTLLkVgCp
	 wa98kE2yqy4Lwrf42VlFfsMO9k0G9YMqArWcqQO9CxT8VFUG53YadBfAvQMbSHZKfP
	 E742IrgSoxWHH3/69/WZ/zhkuRZU0QwATTUMO9e5mVLkvn2546G0NWL53iChWNVXTS
	 pCbHvmj/aVtyTikPcx7QAGHRsezXQmNp4XdN4FhnWLAW2N6mI/BgrlDCivQVG4thqu
	 bqVZ4DZkCE+A/3uE1woFV98GEyVvBnUxDqBQnDwr0RdR/jtP8AGmox80U+jWGw7azY
	 CVOX8j92u6zLA==
Date: Wed, 5 Aug 2026 15:49:28 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Juergen Gross <jgross@suse.com>
cc: linux-kernel@vger.kernel.org, x86@kernel.org, 
    Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
    Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
    Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
    "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/4] x86/xen: Drop CONFIG_XEN_PVHVM_SMP
In-Reply-To: <20260805082137.1214967-5-jgross@suse.com>
Message-ID: <ed8559a3-d955-826c-7646-2c98b4a781ed@kernel.org>
References: <20260805082137.1214967-1-jgross@suse.com> <20260805082137.1214967-5-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-c201ff/1785970172-F46A52A1-86B8FFDB/0/0
X-purgate-type: clean
X-purgate-size: 1337

On Wed, 5 Aug 2026, Juergen Gross wrote:
> CONFIG_XEN_PVHVM_SMP is referenced only on x86 in Xen specific code,
> so it can be replaced with CONFIG_SMP.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  arch/x86/xen/Kconfig  | 4 ----
>  arch/x86/xen/Makefile | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 9e5bb51eecf4..609e79942fcb 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,10 +50,6 @@ config XEN_PV_DOM0
>  	def_bool y
>  	depends on XEN_PV && XEN_DOM0
>  
> -config XEN_PVHVM_SMP
> -	def_bool y
> -	depends on XEN && SMP
> -
>  config XEN_PVHVM_GUEST
>  	bool "Xen PVHVM guest support"
>  	default y
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 32d651aa9bc2..9c7e9ffffb85 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -37,8 +37,8 @@ obj-$(CONFIG_XEN_PVH)		+= enlighten_pvh.o
>  obj-$(CONFIG_EVENT_TRACING)	+= trace.o
>  
>  obj-$(CONFIG_SMP)		+= smp.o
> +obj-$(CONFIG_SMP)		+= smp_hvm.o
>  obj-$(CONFIG_XEN_PV_SMP)  	+= smp_pv.o
> -obj-$(CONFIG_XEN_PVHVM_SMP)  	+= smp_hvm.o
>  
>  obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
>  
> -- 
> 2.55.0
> 
> 


From xen-devel-bounces@lists.xenproject.org Wed Aug 05 23:02:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Aug 2026 23:02:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1383979.1627075 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkcx-0000qD-Ay; Wed, 05 Aug 2026 23:02:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1383979.1627075; Wed, 05 Aug 2026 23:02:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrkcx-0000q6-7a; Wed, 05 Aug 2026 23:02:23 +0000
Received: by outflank-mailman (input) for mailman id 1383979;
 Wed, 05 Aug 2026 23:02:22 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrkcv-0000q0-Tq
 for xen-devel@lists.xenproject.org; Wed, 05 Aug 2026 23:02:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrkcu-001sBx-P0
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:02:20 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73c0b3-bab6-0a2a0a5309dd-0a2a4503e538-44
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 01:02:20 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73c0fa-fae8-0a2a45030019-888fbc335293-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 01:02:19 +0200
Received: by mx.zohomail.com with SMTPS id 1785970931757862.8809731529432;
 Wed, 5 Aug 2026 16:02:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785970935; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=kjana2zBCDvLxbIF/c321U3JNAzvGg7Utwb47zDODFZvTSlMS4blq/7n97LS68hlqGjxm1kt7u4G2TBZKkgdKx2NwjBSChZcLUS6brU4fFICVChZuLx1s1hRpPGWBo+VTXhJAeAJrcl0XQyDpELpb6AE2bZDgIGhBbksqo7bxeE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785970935; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=QOAXveVRzSj2f6mnVcA49KXV+dsWmNXoVe0bGwk16xA=; 
	b=lqJcMwuN9VeJGr7VwC90/hn/uPxbjBriiMjz/1FJcb0E4WTO+eV9pQkFifU2GK6kwxmh5o5bsZWmflJmkaSdbOCD0tHWprlK1IWtb6fEE+dFG2Wl864onuKhgE09PZVijxDlNcp5qc3hkeDLqfQsd4S5wwu5Kg5g6yJJVJsgYIA=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785970935;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=QOAXveVRzSj2f6mnVcA49KXV+dsWmNXoVe0bGwk16xA=;
	b=rmvLsRYcn/qhWZmuOK/lINIzXBWq3tEVpFpiBxuFObRbommY31Bnk9+A45hKRuLm
	eWZKwJXhliOVScmDJq4fbdt1eorT76xJNLeUd6UtW+fYel+7+k9KHXwWZAFncPYgkLh
	AX+qd+zsYx3hGE/8ur0fI/jK16/kBX1zBAb9qvbU=
Message-ID: <6991badc-dcc4-44b9-a048-29eb67c46d2e@apertussolutions.com>
Date: Wed, 5 Aug 2026 19:02:15 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Jason Andryuk <jason.andryuk@amd.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1785970940-74E874E9-C409397B/0/0
X-purgate-type: clean
X-purgate-size: 9013

On 7/28/26 9:22 AM, Jan Beulich wrote:
> For whatever reason they didn't have an xsm_default_t first argument (to
> cope with XSM=n mode), making it impossible to (easily) cover them in
> xsm/hooks.h.
> 
> To be able to retain the const on their function parameters, adjust
> xsm_default_action() accordingly.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -1341,7 +1341,7 @@ fill_ring_data(const struct domain *curr
>        * Don't supply information about rings that a guest is not
>        * allowed to send to.
>        */
> -    ret = xsm_argo_send(currd, dst_d);
> +    ret = xsm_argo_send(XSM_HOOK, currd, dst_d);
>       if ( ret )
>           goto out;
>   
> @@ -1666,8 +1666,9 @@ register_ring(struct domain *currd,
>   
>       if ( reg.partner_id == XEN_ARGO_DOMID_ANY )
>       {
> -        ret = opt_argo_mac_permissive ? xsm_argo_register_any_source(currd) :
> -                                        -EPERM;
> +        ret = opt_argo_mac_permissive
> +              ? xsm_argo_register_any_source(XSM_HOOK, currd)
> +              : -EPERM;
>           if ( ret )
>               return ret;
>       }
> @@ -1680,7 +1681,7 @@ register_ring(struct domain *currd,
>               return -ESRCH;
>           }
>   
> -        ret = xsm_argo_register_single_source(currd, dst_d);
> +        ret = xsm_argo_register_single_source(XSM_HOOK, currd, dst_d);
>           if ( ret )
>               goto out;
>   
> @@ -2002,7 +2003,7 @@ sendv(struct domain *src_d, xen_argo_add
>       if ( !dst_d )
>           return -ESRCH;
>   
> -    ret = xsm_argo_send(src_d, dst_d);
> +    ret = xsm_argo_send(XSM_HOOK, src_d, dst_d);
>       if ( ret )
>       {
>           gprintk(XENLOG_ERR, "argo: XSM REJECTED %i -> %i\n",
> @@ -2100,7 +2101,7 @@ do_argo_op(unsigned int cmd, XEN_GUEST_H
>       if ( unlikely(!opt_argo) )
>           return -EOPNOTSUPP;
>   
> -    rc = xsm_argo_enable(currd);
> +    rc = xsm_argo_enable(XSM_HOOK, currd);
>       if ( rc )
>           return rc;
>   
> @@ -2242,7 +2243,7 @@ compat_argo_op(unsigned int cmd, XEN_GUE
>       if ( unlikely(!opt_argo) )
>           return -EOPNOTSUPP;
>   
> -    rc = xsm_argo_enable(currd);
> +    rc = xsm_argo_enable(XSM_HOOK, currd);
>       if ( rc )
>           return rc;
>   
> @@ -2307,7 +2308,7 @@ argo_init(struct domain *d)
>   {
>       struct argo_domain *argo;
>   
> -    if ( !opt_argo || xsm_argo_enable(d) )
> +    if ( !opt_argo || xsm_argo_enable(XSM_HOOK, d) )

This question came up on another thread, so thought I might point it out 
that when FLASK is in use this can return a nubmer of error codes beyond 
an access deny. While I know it's the existing behavior, but if the 
error code is anything other than -EPERM, then it's not that the policy 
denied the access but something cause a fault in the security server. In 
that case the domain is still being allowed to construct with the 
assumption that it was a policy deny. At a minimum should the error code 
at least get reported, and perhaps it should be passed up to domain 
construction to allowing it to make an informed decision on construction?


>       {
>           argo_dprintk("argo disabled, domid: %u\n", d->domain_id);
>           return 0;
> @@ -2365,8 +2366,8 @@ argo_soft_reset(struct domain *d)
>           wildcard_rings_pending_remove(d);
>   
>           /*
> -         * Since neither opt_argo or xsm_argo_enable(d) can change at runtime,
> -         * if d->argo is true then both opt_argo and xsm_argo_enable(d) must be
> +         * Since neither opt_argo nor xsm_argo_enable() can change at runtime,
> +         * if d->argo is true then both opt_argo and xsm_argo_enable() must be
>            * true, and we can assume that init is allowed to proceed again here.
>            */
>           argo_domain_init(d->argo);
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -76,7 +76,7 @@ void __xsm_action_mismatch_detected(void
>   #endif /* CONFIG_XSM */
>   
>   static always_inline int xsm_default_action(
> -    xsm_default_t action, struct domain *src, struct domain *target)
> +    xsm_default_t action, const struct domain *src, const struct domain *target)
>   {
>       switch ( action ) {
>       case XSM_HOOK:
> @@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
>   #endif
>   
>   #ifdef CONFIG_ARGO
> -static XSM_INLINE int xsm_argo_enable(const struct domain *d)
> +
> +static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, current->domain, d);

I will reply on Jason's thread.

>   }
>   
>   static XSM_INLINE int xsm_argo_register_single_source(
> -    const struct domain *d, const struct domain *t)
> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, d, t);
>   }
>   
>   static XSM_INLINE int xsm_argo_register_any_source(
> -    const struct domain *d)
> +    XSM_DEFAULT_ARG const struct domain *d)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, current->domain, d);
>   }
>   
>   static XSM_INLINE int xsm_argo_send(
> -    const struct domain *d, const struct domain *t)
> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>   {
> -    return 0;
> +    XSM_ASSERT_ACTION(XSM_HOOK);
> +    return xsm_default_action(action, d, t);
>   }
>   
>   #endif /* CONFIG_ARGO */
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -156,6 +156,14 @@ XSM_HOOK(int, dm_op, struct domain *)
>   XSM_HOOK(int, xen_version, uint32_t)
>   XSM_HOOK(int, domain_resource_map, struct domain *)
>   
> +#ifdef CONFIG_ARGO
> +XSM_HOOK(int, argo_enable, const struct domain *)
> +XSM_HOOK(int, argo_register_single_source, const struct domain *,
> +                                           const struct domain *)
> +XSM_HOOK(int, argo_register_any_source, const struct domain *)
> +XSM_HOOK(int, argo_send, const struct domain *, const struct domain *)
> +#endif
> +
>   #undef XSM_HOOK0
>   #undef XSM_HOOK1
>   #undef XSM_HOOK2
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -90,14 +90,6 @@ struct xsm_ops {
>   #ifdef CONFIG_COMPAT
>       int (*do_compat_op)(XEN_GUEST_HANDLE_PARAM(void) op);
>   #endif
> -
> -#ifdef CONFIG_ARGO
> -    int (*argo_enable)(const struct domain *d);
> -    int (*argo_register_single_source)(const struct domain *d,
> -                                       const struct domain *t);
> -    int (*argo_register_any_source)(const struct domain *d);
> -    int (*argo_send)(const struct domain *d, const struct domain *t);
> -#endif
>   };
>   
>   #ifdef CONFIG_XSM
> @@ -213,30 +205,6 @@ static inline int xsm_do_compat_op(XEN_G
>   }
>   #endif
>   
> -#ifdef CONFIG_ARGO
> -static inline int xsm_argo_enable(const struct domain *d)
> -{
> -    return alternative_call(xsm_ops.argo_enable, d);
> -}
> -
> -static inline int xsm_argo_register_single_source(
> -    const struct domain *d, const struct domain *t)
> -{
> -    return alternative_call(xsm_ops.argo_register_single_source, d, t);
> -}
> -
> -static inline int xsm_argo_register_any_source(const struct domain *d)
> -{
> -    return alternative_call(xsm_ops.argo_register_any_source, d);
> -}
> -
> -static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
> -{
> -    return alternative_call(xsm_ops.argo_send, d, t);
> -}
> -
> -#endif /* CONFIG_ARGO */
> -
>   #endif /* XSM_NO_WRAPPERS */
>   
>   #ifdef CONFIG_MULTIBOOT
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -40,13 +40,6 @@ static const struct xsm_ops __initconst_
>   #ifdef CONFIG_COMPAT
>       .do_compat_op                  = xsm_do_compat_op,
>   #endif
> -
> -#ifdef CONFIG_ARGO
> -    .argo_enable                   = xsm_argo_enable,
> -    .argo_register_single_source   = xsm_argo_register_single_source,
> -    .argo_register_any_source      = xsm_argo_register_any_source,
> -    .argo_send                     = xsm_argo_send,
> -#endif
>   };
>   
>   void __init xsm_fixup_ops(struct xsm_ops *ops)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1977,13 +1977,6 @@ static const struct xsm_ops __initconst_
>   #ifdef CONFIG_COMPAT
>       .do_compat_op = compat_flask_op,
>   #endif
> -
> -#ifdef CONFIG_ARGO
> -    .argo_enable = flask_argo_enable,
> -    .argo_register_single_source = flask_argo_register_single_source,
> -    .argo_register_any_source = flask_argo_register_any_source,
> -    .argo_send = flask_argo_send,
> -#endif
>   };
>   
>   const struct xsm_ops *__init flask_init(
> 



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 00:37:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 00:37:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384007.1627084 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrm6f-00075b-DI; Thu, 06 Aug 2026 00:37:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384007.1627084; Thu, 06 Aug 2026 00:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrm6f-00075T-9F; Thu, 06 Aug 2026 00:37:09 +0000
Received: by outflank-mailman (input) for mailman id 1384007;
 Thu, 06 Aug 2026 00:37:07 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrm6d-00075M-Bc
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:37:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrm6c-00B99s-LJ
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:37:06 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73d725-bab6-0a2a0a5309dd-0a2a4501bc9c-12
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 02:37:06 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73d730-5984-0a2a45010019-888fbc335282-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 02:37:06 +0200
Received: by mx.zohomail.com with SMTPS id 1785976617233237.7105325983797;
 Wed, 5 Aug 2026 17:36:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785976619; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Xk/U3OB0byKOg1m3hHzUVjM25Zod62w5PRAOq84C6xyAovu9W3YMWQxnWrh+PXrxui3G4B/EfdnjLtJeQ5W+4o9SWjgRWFhIsBkX/6nWMM9CUsOjylQYZJy67Vw9GRbW4sXoIuWpkgzbh+x/cvBkAZURNp/thcVgxGXuBSRMPOY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785976619; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=oqa2ViCllzgOCvQN5qwRSj/4I/e66JiUdGJ48N8Wzro=; 
	b=OJV84ze+RSTzOYS0NXhPv8NqpQTTY+Wj3iqTBssxfam87gT0cgq5q8f1oZqPKkagHiCYcWq5aKeGGJ0XmLLSHvfgSLYHdOe/4TdlQZZF5EvdRqMEdbwGgQcOCQ+NZM42oFzCklv5TlOYqsH0kw580DQAMIioEqxcvnia8HeZR8g=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785976619;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=oqa2ViCllzgOCvQN5qwRSj/4I/e66JiUdGJ48N8Wzro=;
	b=OgRgsRBfljTgR7lOswZ9etHDS0I4SG6iYHfBVUHWFQR1/wjcZYfF8WjMz0IXmqeg
	MdJ9NjTuNQFkmBip4mn7uxyyck6NwOHbrQX6ToB5YVmjgwq3qdF1VpAnNckxwhzNVSz
	TWH2Cr+Hk6hbND5VoQNDBwob4TXkVrQfKKERJW88=
Message-ID: <185b9a3a-2a54-4f45-8c22-5792666b2aa3@apertussolutions.com>
Date: Wed, 5 Aug 2026 20:37:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>, Jason Andryuk <jason.andryuk@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <bbc2fb48-d79e-4f00-81b4-0170dd910aaa@amd.com>
 <8097d8e8-42ec-463a-8247-56c9e4d834cd@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <8097d8e8-42ec-463a-8247-56c9e4d834cd@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-d62444/1785976626-1E867757-A83E8F75/0/0
X-purgate-type: clean
X-purgate-size: 3026



On 8/4/26 3:53 AM, Jan Beulich wrote:
> On 03.08.2026 23:01, Jason Andryuk wrote:
>> On 2026-07-28 09:22, Jan Beulich wrote:
>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>
>>> @@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
>>>    #endif
>>>    
>>>    #ifdef CONFIG_ARGO
>>> -static XSM_INLINE int xsm_argo_enable(const struct domain *d)
>>> +
>>> +static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
>>>    {
>>> -    return 0;
>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>> +    return xsm_default_action(action, current->domain, d);
>>
>> This one I think should be
>>       return xsm_default_action(action, d, NULL);
>>
>> Usually current is passed in for the check, but for domain_create() ->
>> argo_init() it is the under-construction domain.
> 
> And in that case we want to make sure that current->domain may enable Argo
> for d.
> 

Jason is correct here, the design of Argo is that authorization is 
granted by the hypervisor and not by any domains. It's why we coined the 
term Hypervisor Mediated eXchange (HMX). The source of that 
authorization was designed to be XSM. As such the intent of this check 
is, "is d allowed to register rings".

>>>    }
>>>    
>>>    static XSM_INLINE int xsm_argo_register_single_source(
>>> -    const struct domain *d, const struct domain *t)
>>> +    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
>>>    {
>>> -    return 0;
>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>> +    return xsm_default_action(action, d, t);
>>>    }
>>>    
>>>    static XSM_INLINE int xsm_argo_register_any_source(
>>> -    const struct domain *d)
>>> +    XSM_DEFAULT_ARG const struct domain *d)
>>>    {
>>> -    return 0;
>>> +    XSM_ASSERT_ACTION(XSM_HOOK);
>>> +    return xsm_default_action(action, current->domain, d);
>>
>> Similarly:
>>       return xsm_default_action(action, d, NULL);
>>
>> The single call is:
>> xsm_argo_register_any_source(currd);
> 
> There being just a single call puts this on the edge. If there was another
> one not passing current->domain, I think the same argument as above would
> hold here. And the general concept is what I think should matter when
> writing the dummy implementations.
> 

As explained above, the check is asking the hypervisor if the domain 
currd is allowed to register wildcard rings.


>> These argo hooks all pass in their arguments explicitly, so I think we
>> should do that and not use current.  (The send and register hooks could
>> use current, and that could make sense as those map to hypercalls.  But
>> it is correct today with the explicit arguments.)
>>
>> With the changes:
>> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> 
> Thanks, but no - unless I misunderstand how permissions are intended to
> work here, I don't think I can make the changes requested, and hence I
> can't apply the R-b.
> 

Please apply the changes requested.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Thu Aug 06 00:53:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 00:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384016.1627093 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmMd-0001zA-Pp; Thu, 06 Aug 2026 00:53:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384016.1627093; Thu, 06 Aug 2026 00:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmMd-0001z3-NA; Thu, 06 Aug 2026 00:53:39 +0000
Received: by outflank-mailman (input) for mailman id 1384016;
 Thu, 06 Aug 2026 00:53:39 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrmMc-0001yx-Uh
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:53:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmMb-00DUgw-CP
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:53:37 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73dada-e002-0a2a0a5209dd-0a2a4501ac28-10
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 02:53:36 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73db0f-5984-0a2a45010019-888fbc33528d-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 02:53:36 +0200
Received: by mx.zohomail.com with SMTPS id 1785977608866406.3191270237992;
 Wed, 5 Aug 2026 17:53:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785977612; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=CrAtIn+IHUM1Ck9odLMGFWWw8nOMYVzh7DDvqoVkp19P2qlNigCVH6E7tgWa3FuOrcA0BLIZsORutpAiqePzTLnWRRZEbNFvJQt1A1hszq/0l9LtZdolEsz2/RvJoqodDP+tEZqkFrYJ1OX2ndMBJXVyWS1KnqP9cv0VKXt3Uqg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785977612; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=gF+3hmcKcDN3bvGGKSRKUBSi2/vWsmYQYvFS3ztz2xQ=; 
	b=jV7unf/R/qr6aJpzuR7LBktstArdrQCcYHmfJ4l8krPJKnKchf/2JhIgPVfLY8n6KQpZC/tzgkmr/b4SewxzKmgclMnC2hfIY81qAHhbHf+2OBIEKX4I0A28Z9RR4XglxyIwTnWQHG3XwtjysTNiX5LBh5fR0MzA1/tKGiQXogI=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785977612;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=gF+3hmcKcDN3bvGGKSRKUBSi2/vWsmYQYvFS3ztz2xQ=;
	b=l4etnh0wGSmIfzd3VM0OWXvBgW39OhyudH0TCozJ0XoA+4NzG6v05sFNqi2SKDxN
	hdXdk+etzpKt84bxnIXePs3UF3vvYLZglFCe7JVyB8RKypFLgiPhzjmjGfYFkJe5kqw
	Lw3GiLHwphePkKaNuBHPTZM4P6zJxA2TlPjZqIuc=
Message-ID: <fc08fe79-cdb5-4ee3-9efc-78b02d00db15@apertussolutions.com>
Date: Wed, 5 Aug 2026 20:53:32 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 18/24] XSM: make XSM hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <2c108d3c-eef1-4d4b-9874-b0721fd7560f@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <2c108d3c-eef1-4d4b-9874-b0721fd7560f@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-d62444/1785977616-BFA6E757-AEDC5DC6/0/0
X-purgate-type: clean
X-purgate-size: 5926

On 7/28/26 9:22 AM, Jan Beulich wrote:
> For whatever reason they didn't have an xsm_default_t first argument (to
> cope with XSM=n mode), making it impossible to (easily) cover them in
> xsm/hooks.h.
> 
> flask_do_xsm_op() is also changed to return int, as all the function ever
> returns is an int. This way no new machinery needs adding to xsm/hooks.h.
> Instead one piece of compat machinery can then be dropped from
> xsm/flask/flask_op.c.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Instead of XSM_HOOK, using XSM_OTHER may also be a sensible option here.
> 

I would say XSM_HOOK is sufficient since at this point it doesn't matter 
what op is passed the dummy policy is just going to return the same 
value. If the dummy policy is extended to support an op, then at that 
point the implementer can switch it to XSM_OTHER.

> Question is whether some/all of the other hooks still declared explicitly
> in struct xsm_ops should follow suit.
> 

I would say either comment these are exceptions or make them consistent, 
though I haven't studied if there would be any consequences (doubtful) 
changing the others.

> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -439,7 +439,7 @@ static XSM_INLINE int xsm_hypfs_op(XSM_D
>   
>   #ifdef CONFIG_XSM
>   
> -static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
> +static XSM_INLINE int xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)

With this change, should there be a comment that the int is going to get 
cast to long before return?

>   {
>       return -ENOSYS;
>   }
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -156,6 +156,11 @@ XSM_HOOK(int, dm_op, struct domain *)
>   XSM_HOOK(int, xen_version, uint32_t)
>   XSM_HOOK(int, domain_resource_map, struct domain *)
>   
> +XSM_HOOK(int, do_xsm_op, XEN_GUEST_HANDLE_PARAM(void))
> +#ifdef CONFIG_COMPAT
> +XSM_HOOK(int, do_compat_op, XEN_GUEST_HANDLE_PARAM(void))
> +#endif
> +
>   #ifdef CONFIG_ARGO
>   XSM_HOOK(int, argo_enable, const struct domain *)
>   XSM_HOOK(int, argo_register_single_source, const struct domain *,
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -85,11 +85,6 @@ struct xsm_ops {
>       char *(*show_security_evtchn)(struct domain *d, const struct evtchn *chn);
>   
>       char *(*show_irq_sid)(int irq);
> -
> -    long (*do_xsm_op)(XEN_GUEST_HANDLE_PARAM(void) op);
> -#ifdef CONFIG_COMPAT
> -    int (*do_compat_op)(XEN_GUEST_HANDLE_PARAM(void) op);
> -#endif
>   };
>   
>   #ifdef CONFIG_XSM
> @@ -193,18 +188,6 @@ static inline char *xsm_show_irq_sid(int
>       return alternative_call(xsm_ops.show_irq_sid, irq);
>   }
>   
> -static inline long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
> -{
> -    return alternative_call(xsm_ops.do_xsm_op, op);
> -}
> -
> -#ifdef CONFIG_COMPAT
> -static inline int xsm_do_compat_op(XEN_GUEST_HANDLE_PARAM(void) op)
> -{
> -    return alternative_call(xsm_ops.do_compat_op, op);
> -}
> -#endif
> -
>   #endif /* XSM_NO_WRAPPERS */
>   
>   #ifdef CONFIG_MULTIBOOT
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -35,11 +35,6 @@ static const struct xsm_ops __initconst_
>       .show_security_evtchn          = xsm_show_security_evtchn,
>   
>       .show_irq_sid                  = xsm_show_irq_sid,
> -
> -    .do_xsm_op                     = xsm_do_xsm_op,
> -#ifdef CONFIG_COMPAT
> -    .do_compat_op                  = xsm_do_compat_op,
> -#endif
>   };
>   
>   void __init xsm_fixup_ops(struct xsm_ops *ops)
> --- a/xen/xsm/flask/flask_op.c
> +++ b/xen/xsm/flask/flask_op.c
> @@ -23,7 +23,6 @@
>   #include <conditional.h>
>   #include "private.h"
>   
> -#define ret_t long
>   #define _copy_to_guest copy_to_guest
>   #define _copy_from_guest copy_from_guest
>   
> @@ -606,7 +605,7 @@ static int flask_relabel_domain(const st
>   
>   #endif /* !COMPAT */
>   
> -ret_t cf_check do_flask_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op)
> +int cf_check flask_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op)
>   {
>       xen_flask_op_t op;
>       int rv;
> @@ -772,9 +771,7 @@ CHECK_flask_transition;
>   #define flask_devicetree_label compat_devicetree_label
>   
>   #define xen_flask_op_t compat_flask_op_t
> -#undef ret_t
> -#define ret_t int
> -#define do_flask_op compat_flask_op
> +#define flask_do_xsm_op flask_do_compat_op
>   
>   #include "flask_op.c"
>   #endif
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1971,12 +1971,6 @@ static const struct xsm_ops __initconst_
>       .show_security_evtchn = flask_show_security_evtchn,
>   
>       .show_irq_sid = flask_show_irq_sid,
> -
> -    .do_xsm_op = do_flask_op,
> -
> -#ifdef CONFIG_COMPAT
> -    .do_compat_op = compat_flask_op,
> -#endif
>   };
>   
>   const struct xsm_ops *__init flask_init(
> --- a/xen/xsm/flask/private.h
> +++ b/xen/xsm/flask/private.h
> @@ -3,7 +3,7 @@
>   
>   #include <public/xen.h>
>   
> -long cf_check do_flask_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op);
> -int cf_check compat_flask_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op);
> +int cf_check flask_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op);
> +int cf_check flask_do_compat_op(XEN_GUEST_HANDLE_PARAM(void) u_flask_op);
>   
>   #endif /* XSM_FLASK_PRIVATE */
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -216,12 +216,12 @@ bool __init has_xsm_magic(paddr_t start)
>   
>   long do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
> -    return xsm_do_xsm_op(op);
> +    return xsm_do_xsm_op(XSM_HOOK, op);
>   }
>   
>   #ifdef CONFIG_COMPAT
>   int compat_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>   {
> -    return xsm_do_compat_op(op);
> +    return xsm_do_compat_op(XSM_HOOK, op);
>   }
>   #endif
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 00:56:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 00:56:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384025.1627103 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmPm-0002cN-Cj; Thu, 06 Aug 2026 00:56:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384025.1627103; Thu, 06 Aug 2026 00:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmPm-0002cG-9D; Thu, 06 Aug 2026 00:56:54 +0000
Received: by outflank-mailman (input) for mailman id 1384025;
 Thu, 06 Aug 2026 00:56:53 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrmPl-0002cA-5u
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 00:56:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmPk-008dks-JN
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:56:52 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73dbd4-5cb7-0a2a0a5109dd-0a2a450a9434-0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 02:56:52 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73dbd2-f2d2-0a2a450a0019-888fbc335296-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 02:56:52 +0200
Received: by mx.zohomail.com with SMTPS id 1785977800385533.5825905966658;
 Wed, 5 Aug 2026 17:56:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785977802; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=iZsKCXGWV5ncS4CWyXh+taLTBrQs2p/s3mJdCXcF37pgFd49ikL+YxdR9iMjVzN46KwhTd8HnN7y3tKqUIR9HYgo0VJ4Txn3PAT/bP20vWF4JLkxulgnMr8r1fCTKa0qwYL6GHGt1rBoxh8dI2Ie83ipom5WCxCZZaEhu55hx8U=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785977802; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=iueZ3QDZK5JeDTaKUrqRN8sWfPVwnmJv7o+5G5s4yXU=; 
	b=IeZuRVaR3q8e7/tqgSZE3QnBZSTNroj7CrosfRKZ7JhoXiAgKC/4rs6dLSmlkgIxx86Xtr/BZ4gBzHwetxP2vu+wbtj3Blm3x8Z1BpiFyMzKLGyCZbxrVOMY9TFbK2WLp7Hwp2jjX+tctiY8B5g/PnPS3T3gDQ14vZLoLL3fyYM=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785977802;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=iueZ3QDZK5JeDTaKUrqRN8sWfPVwnmJv7o+5G5s4yXU=;
	b=BiPQE1bEzIJPrdUlEo4olIewbTJetPUpSluO9mhdDIIDdmzqdNYKD3wl4z1jC87R
	GXRKZWLU7V9sIU5Xh5bkRtrj3TFUdAnQHt7WHloTseGvEhM9EJHHqvbvA/NWHRxS2Ud
	YOHVkUGJMniFoGEQFwDh23k+IjMAkX+94Kf3kQXg=
Message-ID: <3b9803d1-5d07-42c4-8295-fb399b1cdd71@apertussolutions.com>
Date: Wed, 5 Aug 2026 20:56:44 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 19/24] XSM: convert "allow" (Flask: "access") parameters
 to bool
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <dc7d05da-ace4-4dc9-ad55-bdb178dfbee0@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <dc7d05da-ace4-4dc9-ad55-bdb178dfbee0@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-4011c0/1785977812-59DDFCFC-1A9C3BDD/0/0
X-purgate-type: clean
X-purgate-size: 10045

On 7/28/26 9:23 AM, Jan Beulich wrote:
> These are boolean, so they should always have used bool (originally
> bool_t), not uint8_t. Leverage recent changes to arrange for this with
> (now) fewer places which need changing (within the XSM machinery itself).
> Adjust call sites as well, where the conversion wasn't done so far.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Why is it that Arm doesn't use xsm_irq_permission() at all? Same for Arm64
> vs xsm_pci_config_permission().
> 
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -235,7 +235,7 @@ long arch_do_domctl(
>       {
>           unsigned int fp = domctl->u.ioport_permission.first_port;
>           unsigned int np = domctl->u.ioport_permission.nr_ports;
> -        int allow = domctl->u.ioport_permission.allow_access;
> +        bool allow = domctl->u.ioport_permission.allow_access;
>   
>           ret = -EINVAL;
>           if ( (fp + np) <= fp || (fp + np) > MAX_IOPORTS )
> @@ -306,7 +306,8 @@ long arch_do_domctl(
>               break;
>           }
>   
> -        ret = xsm_irq_permission(XSM_PRIV, d, irq, flags);
> +        ret = xsm_irq_permission(XSM_PRIV, d, irq,
> +                                 flags & XEN_DOMCTL_GSI_ACTION_MASK);
>           if ( ret )
>               break;
>   
> @@ -687,7 +688,7 @@ long arch_do_domctl(
>           unsigned int fgp = domctl->u.ioport_mapping.first_gport;
>           unsigned int fmp = domctl->u.ioport_mapping.first_mport;
>           unsigned int np = domctl->u.ioport_mapping.nr_ports;
> -        unsigned int add = domctl->u.ioport_mapping.add_mapping;
> +        bool add = domctl->u.ioport_mapping.add_mapping;
>           struct hvm_domain *hvm;
>           struct g2m_ioport *g2m_ioport;
>           int found = 0;
> --- a/xen/arch/x86/pci.c
> +++ b/xen/arch/x86/pci.c
> @@ -78,7 +78,7 @@ int pci_conf_write_intercept(unsigned in
>   {
>       struct pci_dev *pdev;
>       int rc = xsm_pci_config_permission(XSM_HOOK, current->domain, bdf,
> -                                       reg, reg + size - 1, 1);
> +                                       reg, reg + size - 1, true);
>   
>       if ( rc < 0 )
>           return rc;
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -260,7 +260,7 @@ static bool pci_cfg_ok(struct domain *cu
>   
>       return !write ?
>              xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf,
> -                                     start, start + size - 1, 0) == 0 :
> +                                     start, start + size - 1, false) == 0 :
>              pci_conf_write_intercept(0, machine_bdf, start, size, write) >= 0;
>   }
>   
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -505,21 +505,21 @@ static XSM_INLINE int xsm_unmap_domain_i
>   }
>   
>   static XSM_INLINE int xsm_irq_permission(
> -    XSM_DEFAULT_ARG struct domain *d, int pirq, uint8_t allow)
> +    XSM_DEFAULT_ARG struct domain *d, int pirq, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
>   static XSM_INLINE int xsm_iomem_permission(
> -    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
> +    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
>   static XSM_INLINE int xsm_iomem_mapping(
> -    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
> +    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> @@ -527,7 +527,7 @@ static XSM_INLINE int xsm_iomem_mapping(
>   
>   #ifdef CONFIG_HAS_VPCI
>   static XSM_INLINE int xsm_iomem_mapping_vpci(
> -    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
> +    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
> @@ -537,7 +537,7 @@ static XSM_INLINE int xsm_iomem_mapping_
>   #ifdef CONFIG_HAS_PCI
>   static XSM_INLINE int xsm_pci_config_permission(
>       XSM_DEFAULT_ARG struct domain *d, uint32_t machine_bdf, uint16_t start,
> -    uint16_t end, uint8_t access)
> +    uint16_t end, bool access)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
> @@ -711,14 +711,14 @@ static XSM_INLINE int xsm_priv_mapping(
>   #endif
>   
>   static XSM_INLINE int xsm_ioport_permission(
> -    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
> +    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_PRIV);
>       return xsm_default_action(action, current->domain, d);
>   }
>   
>   static XSM_INLINE int xsm_ioport_mapping(
> -    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
> +    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -77,12 +77,12 @@ XSM_HOOK(int, unmap_domain_irq, struct d
>   XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   
> -XSM_HOOK(int, irq_permission, struct domain *, int, uint8_t)
> -XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, uint8_t)
> +XSM_HOOK(int, irq_permission, struct domain *, int, bool)
> +XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, bool)
>   
> -XSM_HOOK(int, iomem_mapping, struct domain *, uint64_t, uint64_t, uint8_t)
> +XSM_HOOK(int, iomem_mapping, struct domain *, uint64_t, uint64_t, bool)
>   #ifdef CONFIG_HAS_VPCI
> -XSM_HOOK(int, iomem_mapping_vpci, struct domain *, uint64_t, uint64_t, uint8_t)
> +XSM_HOOK(int, iomem_mapping_vpci, struct domain *, uint64_t, uint64_t, bool)
>   #endif
>   
>   #if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
> @@ -97,7 +97,7 @@ XSM_HOOK(int, resource_setup_misc)
>   XSM_HOOK(int, resource_setup_pci, uint32_t)
>   XSM_HOOK(int, resource_setup_gsi, int)
>   XSM_HOOK(int, pci_config_permission, struct domain *, uint32_t, uint16_t,
> -                                     uint16_t, uint8_t)
> +                                     uint16_t, bool)
>   #endif
>   
>   #ifdef CONFIG_HYPFS
> @@ -144,8 +144,8 @@ XSM_HOOK(int, update_va_mapping, struct
>   #if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
>   XSM_HOOK(int, priv_mapping, struct domain *, struct domain *)
>   #endif
> -XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, uint8_t)
> -XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, uint8_t)
> +XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, bool)
> +XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, bool)
>   XSM_HOOK(int, pmu_op, struct domain *, unsigned int)
>   #endif /* CONFIG_X86 */
>   
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -998,7 +998,7 @@ static int cf_check flask_sysctl(const s
>   }
>   #endif /* CONFIG_SYSCTL */
>   
> -static inline uint32_t resource_to_perm(uint8_t access)
> +static inline uint32_t resource_to_perm(bool access)
>   {
>       if ( access )
>           return RESOURCE__ADD;
> @@ -1166,7 +1166,7 @@ static int cf_check flask_unbind_pt_irq(
>   }
>   
>   static int cf_check flask_irq_permission(
> -    struct domain *d, int pirq, uint8_t access)
> +    struct domain *d, int pirq, bool access)
>   {
>       /* the PIRQ number is not useful; real IRQ is checked during mapping */
>       return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
> @@ -1199,7 +1199,7 @@ static int cf_check _iomem_has_perm(
>   }
>   
>   static int cf_check flask_iomem_permission(
> -    struct domain *d, uint64_t start, uint64_t end, uint8_t access)
> +    struct domain *d, uint64_t start, uint64_t end, bool access)
>   {
>       struct iomem_has_perm_data data;
>       int rc;
> @@ -1221,7 +1221,8 @@ static int cf_check flask_iomem_permissi
>       return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
>   }
>   
> -static int cf_check flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
> +static int cf_check flask_iomem_mapping(
> +    struct domain *d, uint64_t start, uint64_t end, bool access)
>   {
>       return flask_iomem_permission(d, start, end, access);
>   }
> @@ -1230,7 +1231,7 @@ static int cf_check flask_iomem_mapping(
>   #ifdef CONFIG_HAS_PCI
>   static int cf_check flask_pci_config_permission(
>       struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end,
> -    uint8_t access)
> +    bool access)
>   {
>       uint32_t dsid, rsid;
>       int rc = -EPERM;
> @@ -1709,7 +1710,7 @@ static int cf_check _ioport_has_perm(
>   }
>   
>   static int cf_check flask_ioport_permission(
> -    struct domain *d, uint32_t start, uint32_t end, uint8_t access)
> +    struct domain *d, uint32_t start, uint32_t end, bool access)
>   {
>       int rc;
>       struct ioport_has_perm_data data;
> @@ -1733,7 +1734,7 @@ static int cf_check flask_ioport_permiss
>   }
>   
>   static int cf_check flask_ioport_mapping(
> -    struct domain *d, uint32_t start, uint32_t end, uint8_t access)
> +    struct domain *d, uint32_t start, uint32_t end, bool access)
>   {
>       return flask_ioport_permission(d, start, end, access);
>   }
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384036.1627111 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmXv-0004AU-4F; Thu, 06 Aug 2026 01:05:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384036.1627111; Thu, 06 Aug 2026 01:05:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmXv-0004AN-1R; Thu, 06 Aug 2026 01:05:19 +0000
Received: by outflank-mailman (input) for mailman id 1384036;
 Thu, 06 Aug 2026 01:05:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmXt-0004AH-Im
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmXs-002Rtw-Vt
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:16 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddba-5cb7-0a2a0a5109dd-0a2a4501e924-32
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:16 +0200
Received: from [66.163.185.33] (helo=sonic313-10.consmr.mail.ne1.yahoo.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddcb-5984-0a2a45010019-42a3b9219c87-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:16 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic313.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:14 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978314; bh=u2ICDeT8EkzZPEkZ0GkRz/PZQjnhXux/kxcij9AaLW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=q/G2BOr7WloM0VHKXN2nwJ0rDbxjY+y04yBIggP1Mgn2Y7OR2CGFfBoeairu/dufh8WlbcUEY6Z2/sciIZ6dqFa/+SASV3ri2Ab+tEeIa+k8k+A3xeqGV8f12y8jlJAUoqWewX/z0ntm4hlnXNQtSovCU2URfCoKcOEezI0PoKQ6DwJI1P2KCxMIBj3Vnswja30kIwJlOF0P+1PULgbRPuA6KonN4yE4fnQ0O7DiI2f7BIHq29AnbTQK55MZXEGhtZMChFu7RHKC9zmTkYnRqPzYy+S6CRuWFsGNbHGMXaeFy4vl55P1YKouRuvu4TJ5Q72Ba4yBWEtYvNLwA57SSg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978314; bh=cHWT7ryeN9yIxVQ9xAUubGD/UkRKAGncO1k5XMUDO6e=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=O0rd0dKkVq4tpJT9hTf3se/kJZ17q2puZXxbjqBvuuSDBXUV+0IEKNPAHuRL5Y/E/mxOU4KPKwaFKCjZ2JeCGmQrD9OqOG5tdWDqI+CsR3wxIP4NuBq2DSOdeeJE/xCaFaiD+mnFriCGLbca39xSpYbP8F0pfhV772DaSSg9/EQtbQyJ5UdHX5OQtr3b+ARyBu/Z8/I8Lfv7/q+0f1XOzYYQXjdZt18FqlQxiLVX4nxPST3Mh3ngFf7MBWnmC5puHlvW6OPAa3NOZ+qFk2Uxy3qcSxol0EPAoozlUnwx+CMJSx1iUAGWx6Uc0Gjev00UyK7+/3iO3VasZMCAvTpHCw==
X-YMail-OSG: uHAyLrIVM1mZELM3QZA_rjjFjQeZhI7GIk5ir7ZwfpD8woO2tdFJd3oV32S4I9F
 K2XpvLxjyaHCsGm5lhkVt09Z9P7303YQT4Q5ZwRJHwntssS_K3ic2tbbHpOKBeoVQtyLiisy615E
 csDiHLsrQU8EtCmfHbVykC5UYKAOrjRfP2P5qk1VxbbKmvxHch.HIu9eASabKw3iMBBzXRlKvJrW
 mhQgJossJjKDdlntNwQJIWvSgLOhaAeaEBUbG0HomTQRXfq6PSXegaupD8itEACXgRvArIlV8LIf
 P_h9cEBc_ciT4ba64b6m486boLteuybUOpOZuYzjVUoeEq4ZxOoqGFDa2pQGywtEv3Y8YKey06Y5
 27yljMXpdI2eO0bo.ItreXOATlThMVr2jO5Px7dpFp28AsfIMw2OOi3K2Zss8orDSYaRhhNAVBtp
 tn0hsEsva7TF7gc8s.B.0XW223e9HiEel5_Upfh8lfP5mq7LVqJkXGTAzMB2gRzhEXkc0HiXYJRi
 grdExkne7VxFh21zuWy0u.soCIJ3ufsoNMpRbJvupc7.bwdE.CQ0lwLibfIWWamgcVwSo1fYFB0B
 SnI93oS4xdbQhmMfbUtYahifr1uW1SFE1_ekAkaxX8Wwza.5CrgPEdKCVn.D5f6HSp6G40zGZxJH
 tbPSecfhrVHOze4Y6wcV34.3up0tEAAsHMjcRMLP1SM0mBT7oaBcxtLliOEp5N6q2KL_2VMaprib
 iA1b7ydElQHUUyXxWXhWDPTSrLqEdlCsIxYt9dRLYC8qtljptTG05wBZM26OcNf56hLepRqvFR5A
 l1iPgWs5NWId1xUf9lkzhgsRcIQKa9sYSP2BidBQcO1Vs2uqd4cVzYK8DouYCK0rpTLyD2PzhkIr
 Ok8.xETvZL_NE1ZYj857hfYCFmFKzdYFP4BOKacRMfL7SOfN.a7ltErRM5_kZBzmP2m9jKxpOjWf
 k_j70SvhyGamQQN54hrIvygyjQZJ8giDp.Fw3SS_XFUf0sE7j0mAmZTZxZ_XiXUsSTx5dXylbINV
 bc5QjQm2IGVCi.62Eb96lwu9iFyWiy52amQ1L7UB0xswSlOakL3vC_SENQ9zXe_2xcySeX58d7lJ
 Soto98fB_2vcGdhXuRe9W3RkS7XgLKg1R1Dzofpy3AXrmvXuNNeOMDshs6TiLsL.Pueggk6kihu2
 bFxK2xGsKHxfyKQ.b1YYoZ7LvnfMml5PfyqXzjc7bsDFx2N4veUqCEvYm4rwMbN.rCvd7u60eQLo
 jRlgir.3sh8QzmV9o9cqCd5dAWqXEhEk3erKpt4qK1VjmDC8MHRaizo_lXxc0McNEOkack75ImY9
 up_6vHycvMTGkriXfLU7_hJFqHlgPKvISmpqNh4DgUzWmza1Ma7Ka3C5CWxV2BPB6zxQ6cU4b_b1
 wtF81xthkg8Y7FIWJO.5h99P3D8n3CZgbl_T9ZiSsK_6ep1QRnWxMJkGBPFjgTTKb6DGGUU_DfX4
 KtEdF6g6L1cHlaMQ3hSBQbac1a3E_TLk4v_RA7wl4UZIzYIKyJ.P9beAtfJvPKQP_dLg_7ARpMvz
 LyLCk_S.h3k.JP.gjKOVyuDRXW8kfLZLxOkIt9OND97EXP.16243DxddmeOXfs1UBdkUZVkM_At_
 lRZ1b1rw6uiVFCSpNWE.bSa8N1vfdgLbbUwbR6s3unJpaRU7vWNimmusMHdpV_FAof4aeXZDPEC_
 DwtlyamEGIpz0XvX5n8D2_GRAj_zpKfCp.vDNPb.IQix4qsjL0X76rGISbZnS6nLt7sSAAktgWEf
 pIN0gXy_dVekv2zE85l9.cKfQF0aj7GEABuAqYfN4HRWhcQOy3TxkP9OF.pBBau6u.sR7p79mTw2
 FhBpFvS81qjLLQF.3k9sPSxlxtvxo4O70k.G2Ih0d5d11lNpXgMOcMcDhYng1N3iPGXYmiCEKtsQ
 EpLhaIGkXIiA26Aho8HO8uV74fUuyaxgQyRzuGeqarMoJT4SZY0hpH.k7b9uj3wEp89l4pothTBq
 mE0eKkaD2KqgH75ZlUyolwwPIVWOWb.UbWxtkzUVw6zueIQdv3NYXtEqBYYI2VqIWfyUMYaefW0R
 fMcGHtJxOyMTtc4LZ9N31U5Ro9ullIbn1WmeTAJufFC_D2lTJBOiGP4ybsnDlqx38QYjAF2Qx8i0
 rkGJfGePAyZ3N7AGcjNUimxb2zhYj3ZsB5dfE.ItUDcLgSaCD7Csjck_J79W5itlfx0hZcGfa2Te
 VOOs9IVQcX0oDaJQ9axGTiCvllVH07pLyZ.56K5rz
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 3e58ec08-0dc8-4d98-83be-2a7e74387771
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 1/6] xen/igd: get PCH info from host sysfs
Date: Wed,  5 Aug 2026 21:04:51 -0400
Message-ID: <20260806010506.492490-2-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806010506.492490-1-brchuckz@aol.com>
References: <20260806010506.492490-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 5780
X-purgate-ID: tlsNG-d62444/1785978316-1DC79757-10579EBE/0/0
X-purgate-type: clean
X-purgate-size: 5935

The igd_combo_id_infos[] data is out of date with many
devices missing from igd_combo_id_infos[]. For newer
devices not in igd_combo_id_infos[], get the infos from
the host sysfs. If logging is configured, print log
messages displaying the PCH info used for the guest.

Introduce helper function xen_pt_get_host_pch_info() to
facilitate getting the necessary information from sysfs.
Treat failure to get the host PCH device id as an unrecoverable
error that causes guest creation to fail. If access to the host
PCH device revision id fails, print a warning message and use
a default value of 0x1 in that case.

Also, use errp in xen_igd_passthrough_isa_bridge_create()
to set errors from xen_pt_get_host_pch_info() and cleanup
on error path with xen_host_pci_device_put(&s->real_device)
and object_unparent(OBJECT(&d->rom)) for errors when creating
creating the IGD PCH bridge.

Add cleanup with object_unparent(OBJECT(&d->rom)) for errors
when setting up VGA BIOS for GFX passthrough.

Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - re-wrote xen_pt_get_host_pch_info() using functions from
    xen-host-pci-device.h
  - add more error handling to clean up better after if errors occur
  - don't consider failure to get the PCH device revision id a fatal
    error but instead print a warning message and use a default value
    of 0x1

Changes in v5:
  - Shorten warn_report message to resolve checkpatch line length warning

 hw/xen/xen_pt.c          | 10 +++++++++-
 hw/xen/xen_pt_graphics.c | 39 +++++++++++++++++++++++++++++++++++++--
 include/hw/xen/xen_igd.h |  3 ++-
 3 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 0fe9c0a..c8f08b5 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -862,12 +862,20 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
         if (*errp) {
             error_append_hint(errp, "Setup VGA BIOS of passthrough"
                               " GFX failed");
+            object_unparent(OBJECT(&d->rom));
             xen_host_pci_device_put(&s->real_device);
             return;
         }
 
         /* Register ISA bridge for passthrough GFX. */
-        xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
+        xen_igd_passthrough_isa_bridge_create(s, &s->real_device, errp);
+        if (*errp) {
+            error_append_hint(errp, "Failed to create PCH bridge"
+                              " for passthrough GFX");
+            object_unparent(OBJECT(&d->rom));
+            xen_host_pci_device_put(&s->real_device);
+            return;
+        }
     }
 
     /* Handle real device's MMIO/PIO BARs */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 7df9344..b37f9b7 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -2,6 +2,7 @@
  * graphics passthrough
  */
 #include "qemu/osdep.h"
+#include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "hw/xen/xen_pt.h"
 #include "hw/xen/xen_igd.h"
@@ -376,8 +377,33 @@ static void pt_graphics_register_types(void)
 }
 type_init(pt_graphics_register_types)
 
+static void xen_pt_get_host_pch_info(uint16_t *pch_dev_id, uint8_t *pch_rev_id,
+                                     Error **errp)
+{
+    g_autofree XenHostPCIDevice *pch_dev = g_new(XenHostPCIDevice, 1);
+
+    xen_host_pci_device_get(pch_dev, 0, 0, 0x1f, 0, errp);
+    if (*errp) {
+        goto error;
+    }
+
+    *pch_dev_id = pch_dev->device_id;
+
+    if (xen_host_pci_get_byte(pch_dev, PCI_REVISION_ID, pch_rev_id)) {
+        *pch_rev_id = 0x1;
+        warn_report("IGD: failed to get host PCH revision, setting it to 0x1");
+    }
+
+    xen_host_pci_device_put(pch_dev);
+    return;
+
+error:
+    error_append_hint(errp, "failed to get host PCH device for Intel IGD");
+}
+
 void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
-                                           XenHostPCIDevice *dev)
+                                           XenHostPCIDevice *dev,
+                                           Error **errp)
 {
     PCIBus *bus = pci_get_bus(&s->dev);
     struct PCIDevice *bridge_dev;
@@ -394,7 +420,16 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
         }
     }
 
+    /* Newer devices get PCH infos from host sysfs */
+    if ((pch_dev_id == 0xffff) || !pch_rev_id) {
+        xen_pt_get_host_pch_info(&pch_dev_id, &pch_rev_id, errp);
+    }
+
+    XEN_PT_LOG(&s->dev, "PCH device id: 0x%x\n", pch_dev_id);
+    XEN_PT_LOG(&s->dev, "PCH revision: 0x%x\n", pch_rev_id);
+
     if (pch_dev_id == 0xffff) {
+        error_setg(errp, "failed to get PCH device id");
         return;
     }
 
@@ -406,7 +441,7 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
      * Note that vendor id is always PCI_VENDOR_ID_INTEL.
      */
     if (!bridge_dev) {
-        fprintf(stderr, "set igd-passthrough-isa-bridge failed!\n");
+        error_setg(errp, "set igd-passthrough-isa-bridge failed!");
         return;
     }
     pci_config_set_device_id(bridge_dev->config, pch_dev_id);
diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h
index 7ffca06..da51f09 100644
--- a/include/hw/xen/xen_igd.h
+++ b/include/hw/xen/xen_igd.h
@@ -22,7 +22,8 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s);
 void xen_igd_reserve_slot(PCIBus *pci_bus);
 void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
 void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
-                                           XenHostPCIDevice *dev);
+                                           XenHostPCIDevice *dev,
+                                           Error **errp);
 
 static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
 {
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384037.1627121 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY0-0004O1-Cn; Thu, 06 Aug 2026 01:05:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384037.1627121; Thu, 06 Aug 2026 01:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY0-0004Nt-7h; Thu, 06 Aug 2026 01:05:24 +0000
Received: by outflank-mailman (input) for mailman id 1384037;
 Thu, 06 Aug 2026 01:05:22 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmXy-0004N9-QD
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmXx-008epB-NZ
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:21 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73dda4-2eae-0a2a0a5409dd-0a2a45059c28-38
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:16 +0200
Received: from [66.163.184.148] (helo=sonic309-22.consmr.mail.ne1.yahoo.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddcb-4cb1-0a2a45050019-42a3b894868f-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:16 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic309.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:15 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:08 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978315; bh=fw4HdPaoace2t+OlFHdLFzcl2NiVn/+uZd1DSdtjjQY=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=lpBzXO54AeZhZwpm97O/lgjN4Gr3Th1LXKX3gA4R48w7vBd+g18FjKHkRd0fdDvcLAWQQt1M4AjVWvsyP6BdVPSnjhG0ZpTrKO79NEHR+40umq4YOxBPM2hPl16n/VaN/UBg7wpZHRMnr9+pg/y7lzh5UshtMT8kQ54jUxGMdyAvj8eiQA+I9lBurvIJ9cDH5xTcxmSulY7BztygsSkv6Dn1Z+phMQzopZdsboh5hh3aFmF1ZvWerS7K27hdlWKxOY2o5ZFqkM/lIojuz/8A+bvc37k2rv5XlrRDfHcavlwVAkCkxSI4UPpht2LPXbXcgl3MWl0itOli9MbKoU3w/A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978315; bh=OjKQGJpeXAI+iDr9u7zv+KwtGcuFJ0aLnWAIzROdy0U=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=N+9NBUvkHu3abSCTBrp8tHKMA4TKrNgF66gry3Gtg3Ib3RnFrqcPN7qL087GNup6l3y9v1daeeIvXuXdSD6Gt43quXGFs5qu3xohbdMxUQRL5fdZb7OcZBiu5DSiWoqo+Pxb5kXmQAES+t4g+3UNaHW+r8O5TmjKo8ffbCvIcqadVqQ/6RqDpJiB0AYKwZXT6M3EBvqMCD4kRwNaY3dB3CDlsyb9/OdK7Tca/d1Umz2fL6NOBndV3po0HLZ5le0mqVocLu0kjNWoGoaYA+U5NH2vxg2bAcGdnvQAzAjGEUu0T+JUi5KuuEEhM5DNMiljQZID17ZFDVywEXqtwXptVA==
X-YMail-OSG: xqNcuykVM1l1WTx5uLZ.F2HoxO_Ro_7aK7ZBCq6T3BHtDa0hl3bajy9x40Hd3V7
 3R27P7Ar41eEyBh.rxjGEJ4s0fPPIRRyYJmCaScZEnzpzl4mUq4UgYAatWujz1Q.oTbxzfV8Ilpk
 ZJMcWhMCP92LEYAmkoN8xESgFnSUQoL2Q1PVcqQ8bnE3TagICRy0L5velY4wHl4uiTpaZdniFcZt
 mniaRIxHNl7Slw8MIhQirWxy3y.19Oik2CcxMKiJGCJz1H_VLP.rKS1Or_nBvm3YlgZeE6WiGw.G
 LpuMw9GKgWHC9lY0v_nBpjC.1U9ZDSUY1Bos4LMjZWcblCXLH3kRAtGJOoRMV6Qg0UX3hAtlUBMr
 u3uMZfJaBDsypnj1qrQ9iYB5Kne5lWaRktG_c4dE3Kbdlsg4XS2ZJqNxiSw9ZpfcIcQqu6UEyZDj
 P2XGpWhsd3Q7H_TCL_VMYCA3pRthNaA9gOzOwQNjiU0EsCRB8eJzXtEyfA7wuJHzXf5XkPxeLLdD
 HhCyiKwOEJ3XdiRzlc8z6zBfl7olYAhs3QYTSGq5MDZnVrbVpkb7UHGlW_C23HFRLMmUDQ.GkQaU
 pI2_573A22uZvSuDaLmnMt6wyf23bujF722dBVa4a0w.6jE4O6UcQoyaJVIOfV7lY43GcypHUa8K
 25Z4KXbrUkpBgBIY.yUik08IvCW.PyCxBSQXaafOsQcE7Lw7mFEX8IhYz0qDp7j8aeVIsuu7h55_
 72BbVnheQ6LEZhs66CCH.lmeFWYbqgWzZaP42d7xkSlfmiLl4n.hsG9_yuX7PnEyg1H3hVgWdZKl
 mQTgh9JQXGScN4Uw_LBNix6ooT5i.lB2.FSIaf7HOprkRZ4xHGU589euI9i9Y8OviSkgqPTWJUCY
 eaR40UMJ_aqLXsjwbRlxmc.SzBVYAAW35gPAEV_xJmAOxiarYmLoWWohCbvv2hMxY4Gl88MgiSxJ
 0oxtsIlB1vaa1RVzI0SIVsgVhRviPqtYNZze4TSBirO2fPFpauitShrDYj6OPS3iIccyE.Ozbd.c
 V5dbLzCPCLsoOk6yu1W7fNvwtzqLSs5rFOnWjksHXMSm8AttaQZMVJoaMI0wXTmRmuF3bQEcLvSa
 hM8Kob_B5V8CkIwkzf1IK5n5PqTrrxzcuvz2tan0P8CSgtjZXGFm1gqOwg84GUqKW5n2THmaVfMz
 QYc1AurpEtVOcKdBKO.9X24mueXwylG5qSxRhd26vcuLckLhm0TAmZhyDM6CaQI_rA8aGY3.hiUr
 VNxBDAkE.kQ2zlUJp0m_EoKyzOcs3.xaxiT4BuQODnlx03ouSC2TGV5_MKnG0Nh0CGek670kgu7l
 QU2UNsm1MGQBM0bYD4nzoGOP2iN3_dqK5JIxrTz2aBi55trwYFwrKLA0jtALzoVon4_AIYldX9dr
 DiWI3N3cQwbybAyGC5rxTE39fNKoIPjCj93eyTd_8bBP8QnCh8TXN7J179zPHgmTG51hOVYbODZJ
 b7pqr.h9tjChP5sMzY0UhXb1ouZmYHlNkSQQIJxHX73WJsxS9T6nrfT71J0la.yzy_dYMGJZi761
 FZAekQc1S30uZIrR7bGPGa8pVRlPjaigduxBaTQ3lK9YOSM3g5glF5okEqgs.dFJeOduVH6cZ3bT
 xwWbruwzTiRHeICwVftaTXvha.GAIdEYzz_QZ3xLq8mkWEzAT1o9Djn7xYmCaBTO3qOUbv4oT2gN
 zmQm2OmG9ahAn7CThj6kfihDcxDBthLefJdB92T6db9JmON_deVN_viafdb8uXacN9Gw.nMJpquh
 VJX5DYGoKTA.lpuk631VGItzp6oRQSBWeMTxsPKtnC4FIexDlIGm4cepPxgRH8NUXfp7fYLXFjml
 _C8mbvq9Vduob3ri0XDsGa8jBJHGBAlma9iDOfLcpv1S7PD0NsrqKNoAsbw4DGqDJ2Us8zCJkjw5
 seIj4M.K8LWgQGOCMlEi1jJjHcY0o44PjVCPPcfiuxu13ag_zAe2b.ymWZFDGfPTMkc0aQhldouk
 BThRyoTDGsAngNqBRQcMOL4crTDHCqr2Ye2tHrIeM01Tbx3Rf7mGNRAfNxs5PgBgjTKwpfOKxTfC
 DyKMBf1auuSyXUDK5U08.uviVwwgkzXaE_P6KQTeNcHOR7gcLY.BdWY.N9jw5AmNRfG28IlOUUe5
 XD2_r12rpi9J3K.XNBSgzyjtOIp.XBP0vfPrnUbFGHaFVP3SICP9XjTSpcisPSeN4cIYz2jWZxDb
 gZJqvnp7R62iWwKbBsng1Exsdlmr9aNvU6SdPEw--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: ee9741dd-5910-4e33-8451-29e3ab64a197
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 0/6] xen/igd: fixes for Intel IGD passthrough
Date: Wed,  5 Aug 2026 21:04:50 -0400
Message-ID: <20260806010506.492490-1-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
References: <20260806010506.492490-1-brchuckz.ref@aol.com>
Content-Length: 4947
X-purgate-ID: tlsNG-c201ff/1785978316-72AB72A1-79BB4FAB/0/0
X-purgate-type: clean
X-purgate-size: 5058

Please note that Patch 5 of this series also requires a patch
to hvmloader of Xen for the new support to take effect that
is available here:

https://lore.kernel.org/qemu-devel/20260802050824.10554-1-brchuckz@aol.com/

This patch series aims to fix long-standing bugs that need
to be backported to all currently supported stable versions
in order to support passthrough of both older and modern
Intel IGD devices to Xen HVM guests. Note that previous
versions of this patch series only fixed the bugs
affecting older devices and the patches needed for newer
devices were not included, so this is the first version
of this patch series that is suitable for use and testing
with newer devices that, for example, are designed by the
manufacturer to only work with UEFI firmware.

These patches fix several bugs that cause problems
ranging from a dark screen in the guest until the guest OS
graphics are loaded to an assert failure or other failures
in newer devices that in many cases prevent guest creation
from succeeding or cause other problems such as code 43
errors in Windows guests.

To test the the third patch and verify it fixes the bug of
no video output from Seabios, it is necessary to test
with older Intel IGD devices that have support for legacy
VGA bios (Seabios) because the newer devices, as far as I
can tell, are not compatible with legacy VGA BIOS.

The first three patches have been tested using Xen 4.21 and
Seabios 1.17 on Fedora 44 using an older Intel NUC7i5BNK with
an i5-7260U processor and have been verified to fix the bugs
described in the individual patches. This device is compatible
with legacy VGA BIOS and Seabios.

With the fourth through sixth patches applied, it is possible to
use/test with newer devices since, with those patches applied, the
bugs that prevent guest creation from succeeding with many newer
devices are fixed. All six patches have been tested on both the
older Intel NUC7i5BNK mentioned above and a newer 14th Gen i5-14500
Raptor Lake processor in an ASRock board that, as far as I can
tell, is not compatible with legacy VGA BIOS and Seabios, which
means that, although one can successfully create a guest with
Seabios for the guest with the newer device, there will be no
graphics output from the guest until the guest OS loads the
graphics drivers when using the newer device with Seabios.

The sixth patch is provided for use with newer devices that require
an EFI graphics output protocol (GOP) driver for graphics output
during early boot. For more details, read the commit message and
the accompanying notes in Patch 6.

Two hints to help configuring Xen HVM guests with Intel IGD passthrough:

  - Increase the value of mmio_hole from its default value of
    256 to at least 512 using the mmio_hole setting in the guest
    config. The value of 512 works well when the stolen memory is
    256 MiB. If more stolen memory is used, the mmio_hole may need
    to be increased even more.

  - If there are rdm conflicts, lower the rdm_mem_boundary setting
    in the guest config from its default value of 2048 to a
    value at which all rdm conflicts are resolved. I have discovered
    that lowering it in 128 MiB increments works well. With the older
    device I needed to lower it to 1792 and with the newer one I
    needed to lower it to 1664. See the description of the rdm_mem_boundary
    setting in the xl.cfg(5) man page for more details.

Changes in v2:
  - close open files before setting errp
  - improvements to readability and style
  - small corrections to the commit messages
  - add stable to Cc list

Changes in v3:
  - whitespace fix in first patch
  - fix Cc address for qemu-stable

Changes in v4:
  - add three patches to provide support for newer Intel IGD devices
  - edit the commit messages for better consistency of style
  - use 12 digits instead of 7 when referencing commit hashes
  - re-write xen_pt_get_host_pch_info() in patch 1 using the
    functions declared in xen-host-pci-device.h
  - handle errors in patch 1 that in previous versions of that
    patch were not handled
  - add a Fixes tag to the third patch
  - add two hints in the cover letter to help those who are trying
    to configure Xen HVM guests with an Intel IGD passed through

Changes in v5:
  - fix style problems reported by checkpatch (see each patch for details)
  - update the link to the companion patch for Xen hvmloader

Chuck Zmudzinski (6):
  xen/igd: get PCH info from host sysfs
  xen/igd: don't register rom bar twice
  xen/igd: fixup device id before registering rom
  xen/igd: enable guest creation when ROM read fails
  xen/igd: implement support for extended VBT
  xen/igd: use custom option ROM if provided

 hw/xen/xen_pt.c          |  13 +-
 hw/xen/xen_pt_graphics.c | 282 +++++++++++++++++++++++++++++++++++++--
 hw/xen/xen_pt_load_rom.c |  64 ++++++---
 include/hw/xen/xen_igd.h |   3 +-
 4 files changed, 327 insertions(+), 35 deletions(-)

-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384038.1627125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY0-0004RH-Le; Thu, 06 Aug 2026 01:05:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384038.1627125; Thu, 06 Aug 2026 01:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY0-0004QQ-G3; Thu, 06 Aug 2026 01:05:24 +0000
Received: by outflank-mailman (input) for mailman id 1384038;
 Thu, 06 Aug 2026 01:05:23 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmXz-0004NK-15
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmXy-00Dmiq-E7
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:22 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddca-e002-0a2a0a5209dd-0a2a4508a0e8-6
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:18 +0200
Received: from [66.163.186.146] (helo=sonic302-20.consmr.mail.ne1.yahoo.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddcd-f659-0a2a45080019-42a3ba928d83-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:18 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic302.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:16 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978316; bh=obmks52YmrFX3M/nOgH2+nRuVRmljJ9a96OvnoWzDN0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=kh8tfiI5X2mLkXTltEf1/TcNAbw9dHgs2OXe6/Cx4f4Q2W6aW63BXJmSVUGkINreNcBD6FfkTh+LU/PZ/9ev/PPDIhFXlLEd5DF9qRH0ZT133j+EbvArqqLxdVG+CIYuBgZk87zNSAMfhBXeGs7TSvU4iQ0b4yTmxYhJCWMf35Xml1JursLU3YArBNZcnq06L792aANSeBpwycj45QA+42ABhE6pKl2XJwrrvkIHk/+NChuo4QrpzNRevFVwGoi2dY/qKiLP/Fg0A01edPoGhgAltg5IklPjIt6jt0yDOfQIw6DvU+RedQcECB3yfm/w+fbWJHmTkposNbKtQ7sIbw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978316; bh=ck6kJNsZA5u6QunEVrirntyEJVzU70IKy2/Lw3IfRxB=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=seq5ZWIU5B6NV56rwGUzNRaiukH2pxkuBSHwIm5hFen4SIbMRS3ENPc4ZC5HG2zFkyDfYw+7H8SgJRr8ppyKspt5c+Xix+nMCLvw28oKcc+qUOMrrHWN09oRUtkmmAJnd/XsJ3R1cMJfqpVOSod/yacHuvYk/tzdQjxo6eU3r8djSoeeqOafayIiIcOgA8ANaGsxDIXI7j/YROY1dwuE/R040usL+uXjv6LQw5SXXEj1WHC0RVMJsA+ywcVHL5/YauFFy0VhTSVoYoM0OWCoRj4+bTfpDPzi1OzLla8XfeEAJuA6vARajc7CRv8mjST5gyrGsM6n7OYcR9pwZ77J5A==
X-YMail-OSG: xe.__RgVM1l_hd0jAUIpXgp5HdcGo.Fg7qzC5hEqyLrEB6dmqcjtO7EnO83gYOE
 GdoUZIRcPl4682QnmcoLQDxFV1YiOxV7z10s9oiJciW3.BpnQ.xl6Lgs.cKFe9DEntPnhVV1Gflh
 R_vv_v5VsgTOgQTjb02wbhR7BaicgKG4m_5NYp0e7azVnegtsv2qznQfIXSZ49zCpPeVnSGepg7O
 fmpu1czhJ_Biamcu7HWQvW1Mtd.8RJGlHchC605NeDSR9t5VDe3vg1HrWv6DLy.3QmnAd39n07A8
 .lKFqgozDDtOnri_pthmomKAXEiyEMQ8YkuspAETr67CtZR3EPi4SFc1msSD_8jcVPmqbtmDfIph
 7b9_3yAdy6DCPrEfW4w9UN4MmRDCN7KcczKHG00eYBhCiBxrMlqEJ9sK0kt1tnO3XlKQeGtgSIIN
 wxAeuf49eyyqYUk.OHveIgmW_6luLMJOVxafp6gmx4XMS0Vlguc1Xwm.Z.xs._NrbIEU2q2mKpCs
 y6seMDNYU.ktsDUDJfy.ceAatpCRknL5pwf_0R_p.btzXt43FIgg5e6RMFfWfKgwKRgUPlgIby3y
 tgI0QlPDRbyRsnRDa.kY.iPAvTPehxuTQaaBGkIL6hiLSI72.0tcgw6x4Jr.LWK18RS.GBg5OnMQ
 6JkXFbN3o.3YnKpKn2dioejzpgeRynZjC2o7y7Dl92drO.vdx6CHRQcEbVd8drtKjm16la502FUT
 xpAHW5IV9UCFOnyHi.MgIPUWKe1umqDPnbR3G31N1_nkIfSOqq7vKk5ke0EOOl4boXYe4gEPtLK.
 qcKeaSTJ4c_09WnQ9MC7R4DvUNJnqiXVMnJhncNhtZmdqvimtpw1kylQWUI4F7Lh1WlDHZdVVN6h
 pIO4ToiY3hi6msThigvzwkitiS5EfbihvX.ZRiVtw_OiLHQMtiAn6mpAsAjdHpPnNhClY8yOfUzu
 DzJZpcZvl0_N9QI0lTTfHoScNd08JMLERtnCJRwnR0UhIPQkVYRlRaL1iEBQjuDnjx4ehaCKgmky
 q.Vkq1.5lZAzuA0ERmMyV_YpQHn2h5qnNW.B4Jx4RaKF6g2JTqaMmgn.tW4nus77.m.PNufImZ.T
 UoYvMrVqEJfEWHgS_B6Vh8d0OJAPWHz24XFfojnZzjNai1NMg22qc7TWVkA8uliZFJ2_Lz6vNSb2
 o1eMIYhugUrWwtaTUp78PY_BMTNclTpUHZLbIuF.XTz6Y6jrtZRjJaGcykPoBaHBWUzrIer0hxng
 9Ob7D237hExdRe9MHXd6bofsbaTlAiX4LzcRY6lGqp7JTAJDgQhpSeAtBE11UbMV7F2dLYKjdCB8
 kWEca00akBqg1IRbrp5MrzWZnrBKo7uqOH5vq6bjI_3RpnAycNPN11y02fmTv1Lzy6UuOMzeyuzR
 VzhkyxTLEMcNW3YqSZ3ZUTO5g6soWx0qu8CyL08K3.NvQTtDp8SBA9xRNJsunYksk6BEj0et1cRo
 dAzA739pPjyaG_oe9GgxB51kGjsfsgKNSkbM7eVQUMVmaIXToUsod553kFtJeIF2cLI1ZxtIrbpx
 rFtcrTKYuIbgmUfzxhstYUPtwFc.WIwNpFeBxzmsrikanf6LgzEakFK0sOn0u74SKYVyo4hvx1No
 eJZZ02NuN6jTEhvLoeTGPcLXcIVuueouRMUmOtUTRl9DFWvxpXahWS_hFhG1DRv4Ocycdp76Ywoe
 yVrQFO4OgRA_hewDljdN2taq7UP0CdkUirC7viQW9zPqdselF2hmN5zVP4boYIQz4tNufX_6FiBW
 vAP3XMiAnLXmXKBfU76WWUnbXrweMe4p_1TbsRcLodTHM8mrTor08pcS1.CyeclPwZZNe4Yx28Yg
 nyYk.DXoWZVX.FK9180XjYglAsD9HADqsiFeEVeQRqwuRTvYusctUptH_QxFWqMWG4l3FylIGUxq
 Ix4YdzqAbQOYT3i6YzrJygMfnKTskv7P4c.or6wbvNx8sXcVGQ5JHXweXIofznjQV_cdPh4Xo5hb
 YoYPZOOYmlxpFqCHO8QLyTGnCLSb5vgSjfQSHv6JW4cfmxMckt0B9Q8my7dPlHWYlbClCrUtZEBx
 PPY5Qk.SqfKiJCeGurO3y9X_Kln0_kUTQjRdaW14c2zavvGsmIA3bFBeDSNAJvaDRV1DRBUEqgDh
 h4afNOjFn7Oc5rmYt9ev15A3dYURu_esAZ9nUCCyBYkrEQ7at0wsBmIx0Zpelci_jnqmVAwxWS._
 dFPtE9kCgzMSlHNYsqg9FDG2Odjjyg8YUroeIQb8-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 446e3e3e-5ba5-48e7-8e09-de07860e2ac3
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 3/6] xen/igd: fixup device id before registering rom
Date: Wed,  5 Aug 2026 21:04:53 -0400
Message-ID: <20260806010506.492490-4-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806010506.492490-1-brchuckz@aol.com>
References: <20260806010506.492490-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 3210
X-purgate-ID: tlsNG-c1860d/1785978318-CCF4F87B-4E20A411/0/0
X-purgate-type: clean
X-purgate-size: 3294

With the current implementation, Seabios does not see the fixup of
the device id done here and consequently Seabios does not load the
VGA bios and the guest screen does not light up until the guest OS
graphics driver is loaded. So there is no VGA output from the passed
through Intel IGD from either Seabios or the guest bootloader with
the current implementation in cases when the device id needs fixing.

Fix this by waiting until after doing fixup of the device id before
registering the option ROM. With this patch, Seabios sees the fixup
done here and loads the VGA bios, and both Seabios and the guest
bootloader light up the guest screen in cases when fixup of the
device id is needed.

Also, remove unused header hw/core/loader.h.

Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work")
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - Add a Fixes tag

Changes in v5:
  - No changes to this patch

 hw/xen/xen_pt_graphics.c |  3 +++
 hw/xen/xen_pt_load_rom.c | 18 ++++++++++++------
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index b37f9b7..0ae95cc 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -223,6 +223,9 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
         }
     }
 
+    pci_register_bar(&s->dev, PCI_ROM_SLOT, 0, &s->dev.rom);
+    s->dev.has_rom = true;
+
     /* Currently we fixed this address as a primary for legacy BIOS. */
     physical_memory_write(0xc0000, bios, bios_size);
 }
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 319efca..407b630 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -4,14 +4,22 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
-#include "hw/core/loader.h"
 #include "hw/pci/pci.h"
 #include "xen_pt.h"
 
 /*
- * Scan the assigned devices for the devices that have an option ROM, and then
- * load the corresponding ROM data to RAM. If an error occurs while loading an
- * option ROM, we just ignore that option ROM and continue with the next one.
+ * Normally xen_pt_register_regions will handle loading the option ROM,
+ * but in some cases, such as for the Intel IGD, the option ROM might
+ * need to be modified.
+ *
+ * For such cases, use this function to get a pointer to the option ROM
+ * from sysfs. Caller has the responsibility to edit the option ROM as
+ * needed, call pci_register_bar to register the modified option ROM,
+ * and set has_rom to true for the PCI device.
+ *
+ * This function must be called before xen_pt_register_regions is called
+ * because if xen_pt_register_regions is called first, it will register
+ * the option ROM and any attempt to register it again will fail.
  */
 void *pci_assign_dev_load_option_rom(PCIDevice *dev,
                                      int *size, unsigned int domain,
@@ -76,8 +84,6 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
         goto close_rom;
     }
 
-    pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom);
-    dev->has_rom = true;
     *size = st.st_size;
 close_rom:
     /* Write "0" to disable ROM */
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384039.1627138 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY2-0004ph-0A; Thu, 06 Aug 2026 01:05:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384039.1627138; Thu, 06 Aug 2026 01:05:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY1-0004pT-T5; Thu, 06 Aug 2026 01:05:25 +0000
Received: by outflank-mailman (input) for mailman id 1384039;
 Thu, 06 Aug 2026 01:05:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmY1-0004Zp-5k
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmY0-00Dmq5-IG
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:24 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73dd9e-e002-0a2a0a5209dd-0a2a450bc99e-30
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:20 +0200
Received: from [74.6.131.125] (helo=sonic311-15.consmr.mail.bf2.yahoo.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddcf-b7e8-0a2a450b0019-4a06837d9972-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:20 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic311.consmr.mail.bf2.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:19 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:12 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978319; bh=h5QyMZ5Ty9ooeK2ctmMp9atdh7YP6qYwvti8uYhWKKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=WXNAtiY9RChQYvCGuuLGy7KGeXy4O9j6SP/y0MMsyyqqenPnDbYnoFLGfDrF5fVHHb1gmmsRPzK1Lz9Af4qI1Loal/uC6jTdtVsCA+EHctj2FC8sTzWwRl8SgPNv/NJMOWF4DKuiguWQY3hlwwZu+3tA4feJB5saI1xkQxHCdu4ySoClKu8vr8YvVrEWw2B23fEdFpL+ggpAoglcPwvLuOBjVlHpaRO4S84b6Fk+ITC/npzOSdIVqKCERgRM+HeH3yVSqw/T5SBa+8q6QjRbZULn4eDUOqZ1wGv4Qq5HH3+75yv0Bz9kWyU102qR2pquN8JiME/3ZU0ZicdruySTmA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978319; bh=HtHedw0HjklR4Bxd03Z/oktcnxIu5kpeFcKt5A5jUx9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=sci23NeLeQW7/83wPOO2xYxrJrnIzvA1nCne+qp01PehatgfHclk9IQBzehCg/x9lN7XF1Xhwg89pyZLdxTctgs9u1D3DIYJrBb0lCA3MYiQHi97zp6MdBfZYh1Ia7wh14EmS0KZi061RkXmAqOAC46QwFtIdGwdUJZNjqX5ODGJAVEvgmDUOujEQ8tw6ubB2K3KltLYZeyY0rUJYW2E1xuAYuyl8ts4/pWr5swcrhgHHDh/9I2+ZbR588UKIu/DHoIFFMrxzd9wWhcyYrBBWniH/oLZZZodThbnFKnYVgCvNWqm4LP4vLSP/SrE7FzckSaghPTcbWUGAlffpHWPCQ==
X-YMail-OSG: NjVK234VM1lD9.mUG.YoQ1naz2l046QG0gja2Xq3fbevJ7ptMpnQ.3EcZS3oYyn
 NhwfjfzgkSM7ZkTtioAD9keWSwSCStzoJAxvYag7LL.5zN51nW4NJyYOKgh6A_Po5i4KsrN86u6P
 pZqUoSBIr_SsMXRRc49x5tjkTKiaVc1T7uB940mTZrmGcEPSWibZrf482SnBnOtuPv8p.NdTEUQi
 ZtLT9c6IcJWwgCAAIwr4pUYIKnq28ozHaqd4l3MdriQrRRLGu79Vfu7bt6nlCRoykDfNgq95p80c
 XQoiuVbNB8KnrPrlAUgnZe9Xr0nrKWTyHRNhEteUjsvxn4bK2XvEJT.Mw3gb7dsPk8GxpjfydzyJ
 lPlacR4Oly.TtnsZmUUUym.4XrqCJdhk.7nySdVeqywdoAu3vAETdcJhjbhtHBrbyAU61hk7g6ZW
 mCKfXSeagiSrGBtX8M_t_8JHiRxVbO7yhx0d3iSPglkqm3XUzEY6TIPO5FqBI9FM6iADU90EQmkr
 CxBDDEFFBST4kOa5oPj7FR3hdiOOxxHjW0rOO0EFJGRq2kGXKfz7uit7ASoM5UKf_tIxKjGVaVjf
 u4lsJKgFWBttSL1tCvxIaMI83QfS_WzS074zbhymysSx4n5NZkFnFfeOQHvvwKFEgl5CrskUYE5E
 HIqdg9OOGb1oUCe4Qmm3lQI_unMugQP55LYYtAaDzBBfiwIyhjxKrstXAAqPB_YMTH4.TM9tlzHO
 JByQPb5Nlpx2B.xSMQfEckVgvOQIjBXY.sSeVhjt.so6Pk_8mDnZ4Bsvsj9MAJzmcVr0lDkIqcP8
 fvGYjqiAyT2GELjU5PNae4djk4ZphG4hrnnKsHA7.Hb6ysoo9GELD4mtYt3debFIn0.xz8w6hVvC
 xcpc3ZWrptF29SKGUaQwAijwVJUSCueLE1BD9Fc2e39UF08TTcYRw4iHCLqWsr0.LjenWlD9.yGP
 c9KmoarKCFGAGV0ioLtksq2rAR6el_04YYGq1sSse4pNrG94.rbhem1NJcdpEKSgrf3KNIMAxG9Y
 T7DFotuHgwUCdxmo7spfxdmJ7DXIX7JWYuYYdKeyIiHa2VPwbRubXvyTkhkHposzL7w1ucCHloHr
 _Gk1z41Mic6aoC6bSyKZ8vt4s.qsz7AVl2YRO5sJDlYNaJEA1Th53gRShg.bnJUXvXZrdOmo3Fr8
 kM7t75B1srS4Qh6AgYpkGg45kl85pePrRBqW5XfB_8v9P7D_LOz9UySUcR0n..APL5OAh164QtLM
 jqKiPnKDSPuD6YXjE3QXO45N0ukzjQ5jzAA3iBGnm_qgeuQyDRDM4S7ZEOR4SIs0YiQ0N.VKAFcq
 IfDXALKaQK9ZRKX_b0DJ7GRm5K6v3MvZwCDvTYK3VxJVpqIIb93fQuv8G80bK_hgkgNhBlR7qHaW
 8dEQ50f2.PHapsTahNTchVhHVwph76zvUPF8uUzlfpuBh41snPpWf_FcwRYDizghVEYYl6AN0hcX
 efd_Tq9goGIMJGg7eVT.CHLop8VblyT59azRqBtIvrXqqKAVhcW_O60iB_NTzAzbg47M2taBg1jj
 3ZtZH9ykhUOdgq8lBLPbQbHDKTFUIgDbzAreNhd56.atJ5SGdATudlourGtr6GaVBYKEGm489kwi
 tNUfKscmt5bilcr.7bjnWOcP3DCUM_Asxv8OwLyZPGe.PmmTJvzL4FRYpYqRKWUFNXGzF7Ydzxv7
 yiihKuTJ7ifon0_PEskGgGwyAAgFllt2E29nviS5xdba.Hk7Xogx6hu0OSHiSbON13mZ_nMqaO.X
 1KMjMA0vewPIFeVVRxc6bPs23aoJNPldQwwrxFXy5HF6p9EcuyYFfuUxAydYz4KflpQQiSEHxx4E
 X9O54dy1Ln7sf0X6ctLLJfHWS61dREG._tczC_CXwGmckDZgyOWPJPuHVhRoJlO23C31_nDjRf2A
 6cmXuoMxeGXd5P_r2EupZqCj_VNlh03j0MK6EpNAxOXqD.eW7_aD8YFpYXIHojh4NGeLNMsv.vvq
 4MTPisFmRRxCR9EDOGW60Zq0hWwH3Jpsa8ZBe_4CaG4.XH7A0eELt9DMjNUDCr21I_RPrDSJlg0w
 pfaeuzGNC4Boe69QUvMpU9jyvIxL.gENusIDMyvYGXeyhK4Ajr8j47btyu2lRIUGLzwJCTaiEKsj
 ITGG5.7L5LyWfXrpxHM0poUOaP.OPwpFDvHXjFp4XJypdJo9R_fZ0kJjJ.qeLNICSNzE5aM3IqTx
 OAw_.0S752jcQsBRsRfsXMqV1G8BHpg.7rQE95A--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 2529bb1c-5623-4262-a178-66bc47244aad
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 2/6] xen/igd: don't register rom bar twice
Date: Wed,  5 Aug 2026 21:04:52 -0400
Message-ID: <20260806010506.492490-3-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806010506.492490-1-brchuckz@aol.com>
References: <20260806010506.492490-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 1312
X-purgate-ID: tlsNG-42698a/1785978320-1A2C49EA-CF5DBA8D/0/0
X-purgate-type: clean
X-purgate-size: 1353

This also fixes a failed assertion in pci [1] for Qemu
version 10 and higher when passing through an Intel
IGD with an option ROM to the guest.

[1] f6fc01c78666 ("hw/pci: Assert a bar is not registered multiple times")

Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work")
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - Use 12 digits for commit hashes

Changes in v5:
  - No changes to this patch

 hw/xen/xen_pt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c8f08b5..4d159a2 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -459,6 +459,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
 {
     int i = 0;
     XenHostPCIDevice *d = &s->real_device;
+    const pcibus_t romsize = s->dev.io_regions[PCI_ROM_SLOT].size;
 
     /* Register PIO/MMIO BARs */
     for (i = 0; i < PCI_ROM_SLOT; i++) {
@@ -495,7 +496,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
     }
 
     /* Register expansion ROM address */
-    if (d->rom.base_addr && d->rom.size) {
+    if (!romsize && d->rom.base_addr && d->rom.size) {
         uint32_t bar_data = 0;
 
         /* Re-set BAR reported by OS, otherwise ROM can't be read. */
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384040.1627147 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY3-00054M-8Y; Thu, 06 Aug 2026 01:05:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384040.1627147; Thu, 06 Aug 2026 01:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY3-00054B-4f; Thu, 06 Aug 2026 01:05:27 +0000
Received: by outflank-mailman (input) for mailman id 1384040;
 Thu, 06 Aug 2026 01:05:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmY1-0004dF-AL
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmY0-00GWgj-NP
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:24 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73dda4-2eae-0a2a0a5409dd-0a2a45059c28-42
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:24 +0200
Received: from [66.163.191.148] (helo=sonic304-22.consmr.mail.ne1.yahoo.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddd2-4cb1-0a2a45050019-42a3bf94939e-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:24 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:22 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:18 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978322; bh=evB25RMTSzQAfthgYsyzolI932AZpxXExd3y4km457k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=CGhAqESmK9usG95tKKWtvULiwhR46Cmj4l7Nr/fBR4x5IKPPJs6g38HCr2NM21HXJsUgAUJ8N6UWJ3eFdw9HzEchjDUGaIm4f8xt/2kvzrj+WFqJ3HywKjZ6P7wks6eMkEdDgcoK9EPjdQjRI9WPM++7WvzQj3ZXggg+bw86fE7eZWGkEF8U92+7krdc5x6ixZxk5oqhnFy50Jwt5TR0zxzQsp+4yHIm7Yrdxt2aUp1PoD12KMCqEcbz1yAnBsv4rxa4F7Bj2kERZSgLoXx5d20hd5PcASUj+J4eNybUcf2nGkLIK9cQfnVZnHuk5VFVUZ6Dn/VVwAMJETa2EKurgw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978322; bh=UoVOmCdCQ4BIcpmuzCu7GbBrf0XMwYbjqiL6WaXGwGX=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=q/VFzd9fSN+dkVHeetwvtfjDntAAUUfkPKWOACKE+YSrmkYhahKW7eT7a6nfZtDIcM/CR99Y3AqmyniaMKSJUYi+4RXDum1eq/BV284MZiaNzbBVgUOdjnRInHRNHQ521t8vD050DiqUmp/N1tjhxQu31YXPvkDcnpWVgguNt5eiyqDm0cILdPd12A0efbjx00kFha4ymiyWfpv+YPBZ6DwcsUGrZF3xNdgcatRfXKoEJXiDniM8gs1HRChibjD/QfQPxx8ptuOXpkFTacf2mk8jsrEY/07p/MYe3cahlwdYvcqxWUJPb89FrGPJxH1c1IgkOfKXKpKkAWEdrC92xw==
X-YMail-OSG: wKTvT74VM1l3.wJJxXa53Q_pbyAuRjVyoIJPGNVxZfNtF4hUodYF0AqMELrgeBi
 _sIDSjSMELVdo2CAcOMn9.eiXjo4r8w_VX4pguyV9XkDtXs4YdpH4NYJEnIijAuuSbyFSHwKRThY
 wyM5r_edXDMtcvauaZNwzgpxzyaqXd5bf1KWjcJH5sNkRcfp4RauVUG4xj0oItng9vkKZLrJjcFq
 IlxEay5ao8tNb4tEEM3BNN21FL17ax_wcsqu6PQjVPQSt7Fsvu.v27vmUrKRQx15pR68rB5qz66Z
 iVnXJ_BgeBEdfHG_yIJALoUt8zFRwn8ehHsyX1VzcvuT8Tli5IKmqfS6AsFcEGv4rrTi0oIagr54
 K_alXnfMNPBJEE3WjV3l_UAP31OKKgYg5KXelX4UlQ8jj3Pt_2fXZRr8IunNV.x477cMNx0Tf3q7
 HwgTSMXl6Cx2fsZkgaNw3yNtLO834M_vSgE7sZBICincNPBUeKx5.Ld.7BbY4ueQzoprYPUAIjH6
 AaP_KkvsvBwsGgnKX0b6.MdoGmR76RajBwHsZr0LZINLN6b9R0rCFD1Z96y4xU4ssOFciDF2zNxu
 mJ24dBI0Ngz9IzrvkE9aNG3BCM3EK2JPIZtSfIOrM9TTtUVX8i.XChs6l0kzQZYJAQKPZ9o4uZTT
 Ia80MuUls17e0_DJkvQL_OrskRdzuwXGhFJkwCgyUEvh3ikO4cslWpFMJTujEoYOHuKTWl5exuGO
 X1ttqpvlzukQWmx7XdZHBIbUFAF999nUsqgO4te_cNMd6wurJ9o7.i61n_Q3_Y4Jt948OsjdP8sB
 68iCOLZ4ygL55VywJSmM4G69ASSRs541BIV3D5jHhocPYxaOv7GASgMSdwaAmP3NLXHrNQpv3CUs
 AHIwXZabTe9T3IfeGkV9sfV1tcQu9hjKfm.Ob4YuBRSqbf5CbYg5h5I6Cz9t3fyqPNKHnqPVTSry
 r8Nb12mcHMJrNqg_8UxyZEbBjip0dj3VXMH4gSTUb.ixPig0kLDuLT9_JOS4X4NuS4syONJE2qel
 vQjaH4ENmBjpzA7HLPZEboIyLAztTspvzYV8VqlT0gAXgtZtqr6gzrcVO_qYg0BpaKfd4oTlm_1Q
 mU_IlTXLjCyXksDE3B_BibAAIHhYMv8V3j7BMATvCIuFxvfr8mXp5MKScNLBL8vSRq98BZjVXLdF
 w3e8psinkPI3k2Ve8v_Kj46l6JZke3l9dE39zx_YM7xxJdoKiENN01bZIOwdaB.g15W4gg4fvb6u
 iSNB69Z0LfQAxlith8Z7sqNyBWM7e3FByu9tdGj8tNUskVRerRLCALrg7_hDGeojtkbdZZRJbJlF
 xWfIewEfc_VzkgCJBx6zBbP0BVnCcW0TQYqLdXobVNzW_X2VAafQ1B8GoAOarcbkDAA8xxUVed2K
 svsZR8lwNSzuBGevM1oIR2nt_csErLLbwQM9cjYdw.D_dwwVrOJsUujRrWwaykrcuk0Eff8Ucii1
 FBzP5Pz8YEZNqEcu5J2fYyyIIqSEeLUlhXu_3dfWuncrN.zw_G3ZKK7aZs16Urh3gHCwWErlQOaQ
 vH7zzFaaOHpsEkkiTPkkeFVOnP8sBwQ3alydE85Jq0d2RbXD5fRFLVWEj5LHAxBuhC1G0y30dmfa
 EFfPkAwXmfpcIzQNbelQDUvuZUbZqqI.TrQwmFYbRVX5I59FLHCOYqToK8Mlp70kKy0JSvHgbiMd
 WRvuOgCYNXul_KU3eO4ha6NHilwDP_kBbtBQHdYtI59FU2xEmCKf_oVDsH0_dKYkMgXKqxED2qTx
 hkh4XL9CaL5cuoR5tpoX6mzW9VwGHaq_mIXaU3Kaua5.XIEXUaU5Dhk.DUKwiBb45c6gYevdW4Lh
 SDh0Le2Z.AihHQCYIvlRK4B7N9ocQq1_Py6JjJNfYJwy7yaW6jh9tUPuVd7x6gc9adogTBxiUx0j
 qWVQJIk3h5.eh51CdStywHJQJkmd8oZ_PU3Hrg9gQAsfcLO_VWuyP2vHeG1qewFpV234E0KCnHd_
 U2noFmL1g6ae.iV.kr4PtwQZSmWLDNakcws4CX3J0Vm9nDoX9z6RuHN6N.x.koGoITFtg3OXgBKF
 c8gsiZ7W53V0NQ3rHmGqjxwOs4w.F68jvUlGTJYrFAydsYLjTC.KvtMeDAzuakDINmvR0rm2TPXo
 FE74kE5q7P8OHqAoxHX2X9OLj_p9ucP2JTDNvT4mWRABeXyN6RnvWO_w5i.RgSz7CA87HmoVMvkI
 0oVzK6KX9x9Nbkxo9r5PZhXsZkDi3eiyI5O.49vrt
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: d6264233-3872-45c9-8ba3-4c440a588136
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 5/6] xen/igd: implement support for extended VBT
Date: Wed,  5 Aug 2026 21:04:55 -0400
Message-ID: <20260806010506.492490-6-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806010506.492490-1-brchuckz@aol.com>
References: <20260806010506.492490-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 14820
X-purgate-ID: tlsNG-c201ff/1785978324-720AA2A1-A7E3AB38/0/0
X-purgate-type: clean
X-purgate-size: 15160

Newer devices with versions of the OpRegion >= 2 require an
extended bios table (VBT) in some cases and also in some cases
require modifications to the OpRegion for proper operation in
the guest. This is in contrast to legacy devices in which the
VBT is always embedded within the OpRegion.

This makes the current approach of providing only the unmodified
host OpRegion to the guest with no guest access to the VBT
insufficient for proper support of devices with OpRegion version
2 or higher and an extended VBT.

Support for extended VBT also depends on compatible support in
hvmloader. If such support is lacking in hvmloader, fall back to
the current protocol that does not provide support for extended VBT.

To implement support for extended VBT:

Instead of configuring the guest with access to the unmodified
host OpRegion via hypervisor mapping of the OpRegion from
the host to the guest, temporarily map the host OpRegion and
VBT into the guest, allowing the guest (hvmloader) to get copies
of the host OpRegion and VBT which hvmloader can modify as needed
to support cases that require modifications to the OpRegion.

In xen_pt_unregister_vga_regions(), do not try to unmap the OpRegion
in cases when the OpRegion is not mapped during normal operation of
the guest, and replace the constant '3' with the macro
XEN_PCI_INTEL_OPREGION_PAGES which is defined to be 3.
To implement this:

Use 'done = true' to end further processing when the OpRegion does
not need to be unmapped in xen_pt_unregister_vga_regions(), and use
'guest_supports_opregion2 = false' to end further processing when the
OpRegion does need to be unmapped in xen_pt_unregister_vga_regions().

The OpRegion 2+ support that can be provided by this patch and a
compatible patch to hvmloader is required to fix code 43 errors in
Windows guests that have an Intel IGD with extended VBT passed
through to the guest.

Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - v4 is the first version of the series that has this patch

Changes in v5:
  - fix style by adding braces to two if blocks and not initializing
    two static boolean variables to false
  - update the link to the companion patch for Xen hvmloader

The companion patch to hvmloader that is needed to make this patch take
effect is available here:

https://lore.kernel.org/qemu-devel/20260802050824.10554-1-brchuckz@aol.com/

 hw/xen/xen_pt_graphics.c | 233 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 225 insertions(+), 8 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index a124233..3d2a94c 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -12,7 +12,26 @@
 static unsigned long igd_guest_opregion;
 static unsigned long igd_host_opregion;
 
+/*
+ * These are true until they are set to false when the guest first
+ * accesses the OpRegion address register for a read or write,
+ * respectively.
+ */
+static bool first_guest_opregion_read = true;
+static bool first_guest_opregion_write = true;
+
+static uint32_t guest_opregion_extra_writes;
+static bool guest_supports_opregion2;
+static bool done;
+static unsigned long rvda; /* absolute host VBT address */
+static unsigned long vbt_guest_pgbase;
+static uint32_t vbt_nr_pages;
+
 #define XEN_PCI_INTEL_OPREGION_MASK 0xfff
+#define XEN_PCI_INTEL_OPREGION_PAGES 0x3
+#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
+#define XEN_PCI_INTEL_OPREGION_DISABLE_ACCESS 0x0
+#define XEN_PCI_INTEL_OPREGION2_SUPPORT_MASK 0x1
 
 typedef struct VGARegion {
     int type;           /* Memory or port I/O */
@@ -117,11 +136,11 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
         }
     }
 
-    if (igd_guest_opregion) {
+    if (!guest_supports_opregion2 && igd_guest_opregion) {
         ret = xc_domain_memory_mapping(xen_xc, xen_domid,
                 (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
                 (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
-                3,
+                XEN_PCI_INTEL_OPREGION_PAGES,
                 DPCI_REMOVE_MAPPING);
         if (ret) {
             return ret;
@@ -239,7 +258,31 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
 
 uint32_t igd_read_opregion(XenPCIPassthroughState *s)
 {
+    if (!igd_host_opregion) {
+        /* We just work with LE. */
+        xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
+                               (uint8_t *)&igd_host_opregion, 4);
+    }
+
+    /*
+     * By returning igd_host_opregion here instead of 0, we can
+     * indicate to hvmloader that we support OpRegion 2.
+     *
+     * The conditions are there to prevent returning igd_host_opregion
+     * to guests that have a version of hvmloader that lacks support
+     * for OpRegion 2. We do this to maintain backward compatibility for
+     * guests with earlier versions of hvmloader that always expect us
+     * to return 0 instead of igd_host_opregion when igd_guest_opregion
+     * is not yet set to a non-zero value.
+     */
+    if (first_guest_opregion_read && !igd_guest_opregion &&
+        first_guest_opregion_write) {
+        first_guest_opregion_read = false;
+        return igd_host_opregion;
+    }
+
     uint32_t val = 0;
+    first_guest_opregion_read = false;
 
     if (!igd_guest_opregion) {
         return val;
@@ -251,21 +294,195 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s)
     return val;
 }
 
-#define XEN_PCI_INTEL_OPREGION_PAGES 0x3
-#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
 void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
 {
     int ret;
 
-    if (igd_guest_opregion) {
+    /* hvmloader with OpRegion 2 support uses lsb of val to indicate support */
+    if ((val & XEN_PCI_INTEL_OPREGION2_SUPPORT_MASK) &&
+        first_guest_opregion_write) {
+        guest_supports_opregion2 = true;
+    } else if (first_guest_opregion_write) {
+        XEN_PT_LOG(&s->dev, "hvmloader lacks extended VBT support, "
+                   "continuing with legacy support only\n");
+    }
+
+    if ((!guest_supports_opregion2 && igd_guest_opregion) || done) {
         XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
                    val);
         return;
     }
 
-    /* We just work with LE. */
-    xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
-            (uint8_t *)&igd_host_opregion, 4);
+    if (guest_supports_opregion2 && !first_guest_opregion_write) {
+        /*
+         * OpRegion 2 is supported and we are processing
+         * additional writes that the legacy protocol ignores.
+         *
+         * We should always return from this if block to prevent
+         * executing code below which is only for the first write
+         * when we map the host OpRegion into the guest.
+         */
+        guest_opregion_extra_writes++;
+        switch (guest_opregion_extra_writes) {
+        case 1:
+            /*
+             * Hvmloader expects us to store the value as the least
+             * significant DWORD of rvda.
+             */
+            rvda = (unsigned long)val;
+            break;
+        case 2:
+            /*
+             * Hvmloader expects us to store the value as the most
+             * significant DWORD of rvda and unmap the OpRegion if
+             * rvda is not equal to zero.
+             *
+             * If the unmapping fails, hvmloader will fall back to the
+             * behavior of older versions which simply map the OpRegion
+             * from the host to the guest without trying to configure
+             * the guest with OpRegion 2 with extended VBT support.
+             */
+            rvda |= (unsigned long)(val) << 32;
+            if (rvda) {
+                ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                               (unsigned long)
+                                               (igd_guest_opregion >> XC_PAGE_SHIFT),
+                                               (unsigned long)
+                                               (igd_host_opregion >> XC_PAGE_SHIFT),
+                                               XEN_PCI_INTEL_OPREGION_PAGES,
+                                               DPCI_REMOVE_MAPPING);
+                if (ret) {
+                    XEN_PT_ERR(&s->dev, "[%d]:Can't unmap IGD host opregion:0x%lx"
+                               " from guest opregion:0x%lx.\n", ret,
+                               (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                               (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
+                    rvda = 0;
+                    guest_supports_opregion2 = false;
+                }
+                ret = xc_domain_iomem_permission(xen_xc, xen_domid,
+                                                 (unsigned long)
+                                                 (igd_host_opregion >> XC_PAGE_SHIFT),
+                                                 XEN_PCI_INTEL_OPREGION_PAGES,
+                                                 XEN_PCI_INTEL_OPREGION_DISABLE_ACCESS);
+                if (ret) {
+                    XEN_PT_WARN(&s->dev, "[%d]:Can't disable access to IGD host"
+                                " OpRegion: 0x%x.\n", ret,
+                                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT));
+                }
+            } else {
+                guest_supports_opregion2 = false;
+            }
+            break;
+        case 3:
+            /*
+             * Hvmloader expects us to store the value as the address
+             * to map the VBT to in the guest and to map the VBT at the
+             * provided address in the guest. Hvmloader encodes the number
+             * of pages to map in the least significant 12 bits of the
+             * provided address.
+             *
+             * If VBT verification fails, hvmloader can't determine if the
+             * VBT is mapped but corrupted or unmapped, so it crashes the
+             * guest as an unrecoverable error.
+             */
+
+            /* address (gfn) to map VBT to in the guest */
+            vbt_guest_pgbase = val >> XC_PAGE_SHIFT;
+            vbt_nr_pages = val & XEN_PCI_INTEL_OPREGION_MASK;
+            ret = xc_domain_iomem_permission(xen_xc, xen_domid,
+                                             (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                             vbt_nr_pages,
+                                             XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "[%d]:Can't enable access to IGD host VBT:"
+                           " 0x%lx.\n", ret,
+                           (unsigned long)(rvda >> XC_PAGE_SHIFT)),
+                rvda = 0;
+                vbt_guest_pgbase = 0;
+                vbt_nr_pages = 0;
+                done = true;
+                break;
+            }
+            ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                           (unsigned long)vbt_guest_pgbase,
+                                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                           vbt_nr_pages, DPCI_ADD_MAPPING);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host VBT:0x%lx to"
+                           " guest VBT:0x%lx.\n", ret,
+                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                           (unsigned long)vbt_guest_pgbase);
+                rvda = 0;
+                vbt_guest_pgbase = 0;
+                vbt_nr_pages = 0;
+                done = true;
+                break;
+            }
+            XEN_PT_LOG(&s->dev, "Map VBT: 0x%lx -> 0x%lx\n",
+                       (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                       (unsigned long)vbt_guest_pgbase);
+            XEN_PT_LOG(&s->dev, "VBT host address: 0x%lx\n", rvda);
+            break;
+        case 4:
+            /*
+             * Hvmloader expects us to store the given value as the
+             * final value for the register that stores the OpRegion
+             * address in the guest. We also unmap the VBT since the
+             * guest now has its own copy of both it and the OpRegion.
+             *
+             * If the unmapping fails the VBT will be mapped where
+             * hvmloader needs to place the OpRegion plus VBT in the
+             * guest E820 map. In this case, hvmloader will crash with
+             * BUG() rather than try to use the mapped VBT with the
+             * guest's copy of the OpRegion.
+             */
+            igd_guest_opregion = val;
+            ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                           (unsigned long)vbt_guest_pgbase,
+                                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                           vbt_nr_pages, DPCI_REMOVE_MAPPING);
+            if (ret) {
+                XEN_PT_ERR(&s->dev, "[%d]:Can't unmap IGD host VBT:0x%lx from"
+                           " guest VBT:0x%lx.\n", ret,
+                           (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                           (unsigned long)vbt_guest_pgbase);
+                rvda = 0;
+                done = true;
+                break;
+            }
+
+            ret = xc_domain_iomem_permission(xen_xc, xen_domid,
+                                             (unsigned long)(rvda >> XC_PAGE_SHIFT),
+                                             vbt_nr_pages,
+                                             XEN_PCI_INTEL_OPREGION_DISABLE_ACCESS);
+            if (ret) {
+                XEN_PT_WARN(&s->dev, "[%d]:Can't disable access to IGD host"
+                            " VBT: 0x%x.\n", ret,
+                            (unsigned long)(rvda >> XC_PAGE_SHIFT));
+            }
+
+            done = true;
+            break;
+        default:
+            break;
+        }
+        return;
+    }
+
+    /*
+     * This code handles the first write to the register from the guest.
+     * It maps the host OpRegion into the guest.
+     *
+     * Set first_guest_opregion_write to false to enable more writes
+     * if OpRegion 2 is supported.
+     */
+    first_guest_opregion_write = false;
+
+    if (!igd_host_opregion) {
+        /* We just work with LE. */
+        xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
+                               (uint8_t *)&igd_host_opregion, 4);
+    }
     igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
                             | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK);
 
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384041.1627152 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY3-00057n-Ms; Thu, 06 Aug 2026 01:05:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384041.1627152; Thu, 06 Aug 2026 01:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY3-00057d-FH; Thu, 06 Aug 2026 01:05:27 +0000
Received: by outflank-mailman (input) for mailman id 1384041;
 Thu, 06 Aug 2026 01:05:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmY1-0004gH-FC
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmY0-00Dmq5-SR
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:24 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddb4-e002-0a2a0a5209dd-0a2a4504b9fe-22
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:24 +0200
Received: from [66.163.188.206] (helo=sonic311-25.consmr.mail.ne1.yahoo.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddd3-b57f-0a2a45040019-42a3bcce86d4-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:24 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic311.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:22 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978322; bh=G3VmkipyMhZjj38uG/j4xipQ/TGQEWVZ1kywsdVeHas=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=sYh2bdc5USWGn/sFhSPBJe1EnhxZwUUrqvj6+oB/+JhLjRbMnVh3ubZYOYS5WoeKzb47Ne6IdsUr+VjRfAq1jQOMuqLmQDN5nDLtrS3DO/eKwtYyXyibDTdDvisZ0WRb8Xyyv7mON2D3Li4ATYkY5IfbFjubGkG5Q8wRdJ43aS7qp5mSvnjFRY+KskoQomSsIri5FNhgQghUnIYROeMM2Mp+/ugQzt/TlGlBgsHiTQW0emGg6+aqLt3B6JbGnfgVGTkmju/re4cvJSWOpM0gHj0RWDutE1O6iyiKsebTnLghagbWhAl7QvVLmwTJvQ9v7VbPNlDQAw5kkJhscqLP2w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978323; bh=DZ9DSj/zpZJ3CsUxLDF6vIBJyRg0So43YHTPMQfuJzl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=TAKI7iHY46DjDMy++WItmCEFlDeyjlPs21SUXO0aljNq/2YyX2/COoN7d0+2e2YIPHsw2g5FFMEDH8l75xCjHJgb9Z/zCGVy68wfROiuG3/OXveUYSM2rTBn6QuJbBvfbfUGrqG/CPsY/BTXWtGw9fLZo8E6jkplPHW0FQ/7IGtkun1/1F0v8dNNjgyaSbctYhseiz6/Ym9cvSgDT07oW+3x8V6fYm1QZgw3PE819oS91wLUcqMna8rCyrTiFd9ffPRd/rxP2ZVNE89g0NsWE+Dz1EPjkuSABRrLzTR2j1h+x9qoKRa6m+igpzNJ+TdBYfG/Wm7zvXUfNQbATfBUtQ==
X-YMail-OSG: MK2xyiEVM1mskLxz7Nzv39526zcsIPBExeYJkJ6wwg4Pj7cCurKbGeeUSjkNAg5
 Wg6SU9axyUHI.gGoWPw3yN.J9PfmYE42REwRg6sBTQzgu2NEa1PkSI71xSyPnmk6Nvx738HTf9w7
 dUyDx9ZvQoqjsEhkQomCM9xunTW5RshlOICtH3y.dhV4Icz39Vgt4uuFdX4jbd2dnDqGj0vnxw31
 TlDQbsVjdc2uC33HzYzumdCjHf0BFoMC3sqsIhMd8mXqY5Iwr6GWQ33QJRYFGCc_ClN2CK2e.FO5
 CBNNHWiMSqA5X5lO5VbgbAP8WZJtuUgkDgULDS6VHqraDXhM.4F_Qq8OlcRGxUnGIiQB.RwIgR.m
 giAgfnSysr4GZdMwxhE4Sy.ylDeCtvO.Bxnjg_1KhYzUZLw53HJ4wEV.Xd4h.uulOl40wQFyugU7
 TA4ye7aYvWJW3ybt4ACGEwzfLYTu6vIJJar1ABuktyaKu0YFlRQ3VNExJYRHwSfC8jER.KlXP2kK
 ehmQ0zkxeXl7FIjPY0KhhGRsAVDaLTFzu_w9iGLENNk.rSHaxJy92adtBp1DmMwXKC9vVe4BpTAw
 Pp.Ms2_WnYXp8G39Aio1cKvP4IZR7Nk3BlHkDfJ28sBOP1s4if.p3jmhLjnVQCh3htfQyhxtm56d
 EdLjfVqkyF3DyhD1K_KctZjXYVF_3Roq5AuxNkmJSEmoC.lVZnIm9GH_pMhF5tJSPMmqHLpyKcEs
 30oX.OITe50tYOLvnf5Cd8rEf3tcoJCDeAYRUq80rinoSaaChYs1qZg6wCUxTqVQAQ_JRg6vBkq8
 ghRpDSLtjLhRGvpV2Rr9GukwbQPjMJ2OzC2Vc5REMRcMAA8GjRazto24P0c6SBoJ.TGhTPeHW.ze
 .hB1FKxmTyyuesnANSBe2UFg3gi0gwgfho5OssocFgr2cHUdbsumdUsdvYoKvvWqltnG7yz3WBXM
 s5sgutRVx5S0pJdQ8NlhgkUnaR1JEmCXdd6xE20WSvfrs5xGjX9oX1GxQT60AU6exo2b_C4Lg.x3
 oVo7No7MTuw2RM2oJYxuVxgqMa7i2FMmyuzFsA4CtFERiA.zmByC4ZNaPtwPibn9jttakKgmaymn
 CNhlbogFnNY7GNAulF_Mp0InKzXoTjVGPXLbjmSpoSn3R7pgowzThrHRLCVw3AArpKrZDxqbDk6p
 ULrXqTil2x5RJOOeeSqElUxMu.LX.Egf05mDG3yvnAT5eaD.pWpwkJIYELMQBQQ_TPY2TWGcPUzh
 Y0owemd.IPVo4aJ0kHg4gck8C.C1sXfOMYRpbzjYK3dQhv_Mam7aHTY.33orh6PSva82D1gbGr6X
 Ptw9wpn4IpM.H64I5A5G9jbVNkqzMcMSAkGOGGhHcY39hXJgxOt8MqLEbQZMF_QgJaaFiEZhvyMi
 bgBc.mnDx.2tz6LljKKrtvV.qDI1haWPf.9MD7gIwQu94tctzGm6QvJVgLl4CvVy4wtMwhC7OK46
 y.9JsBpMNRxKaPFthdfwct_.pUYD0pNkk1jvObfQdPaelAVPthSq1d9DKeJlgQ8LQwQEOXAnOcaU
 7ojhZAWihDIOhA1vEiTV3n9T4WYQBaTQPwT26YSYt4ocgp78AJOIhDgkJ3r_fEVZKPNwf1tHOHnC
 cTWqil54q1DiY36AFrqJed90uIiIK.TkwxCX9Ev91irKlcWsfLwH6iBCPPCVr4we99H1kHToEqeW
 MzO5pDyfaeNd83lNStHKneUBbBfFt5.c1N_h7CLeL26Q44apRYC5jk14fsryUIDrHO5Cnh6B9pvd
 jImYKbY2z3bPvVD3ZzHG5sj.616szDR88RkZ2jTgt_mtuCSu8mg07WC1gXAYIZARQvCpwbknHhUS
 MKMLYBKKDJU0U5zEoKPoOxtGF_dGkQD4gAF_5CjAp8K8Ptqhlnb4YTdsX.lxxHigF1LUD3p8L07R
 r6E6R_iUr5NBpacyKSJzYKXkoeeLfKbyMpCw4OJ0_4Fy.v3R1ADimO4uKo1ilUhtUTOcZ.WkRJV7
 e4xuC9RwBAevbyvJM_8sESWSDgN4lRqcxBRwA3jjmqzUuod1onTzjLMlyh73OKpUJcSsYd8FiVMd
 yACclYtGNxBqeZWcHaMs80lwpWaE2QPMLnwEw4GhR.Rj_aKyatY2CLiyL.kpGePTCcT4yO8YGG0m
 34C17PuwEmDDyXCxekBzXUchFB_QTyam7SK68sYCbjOmeoqJ2ZDwJg7aJmHV5
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: af215a46-7fce-4258-a2a7-e4fc20b5d1e5
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 4/6] xen/igd: enable guest creation when ROM read fails
Date: Wed,  5 Aug 2026 21:04:54 -0400
Message-ID: <20260806010506.492490-5-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806010506.492490-1-brchuckz@aol.com>
References: <20260806010506.492490-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 4888
X-purgate-ID: tlsNG-ebf023/1785978324-C04DBB50-D6FC651B/0/0
X-purgate-type: clean
X-purgate-size: 4998

For newer IGD devices, the host option ROM is not readable from sysfs
and this results in a call to error_fail() that causes Qemu to
exit(1) so guest creation fails with the current implementation for
many newer IGD devices. But this read failure need not be a fatal
error causing guest creation to fail because the guest does not need
the option ROM to successfully boot and run. The guest only needs the
option ROM for getting graphics output from the guest during early
boot before the guest OS loads the Intel IGD graphics drivers.

To fix this, allow guest creation to continue by avoiding setting errp
if the attempt to read the host ROM file from sysfs fails. In this case,
the memory for the guest option ROM has been allocated so free that
memory by calling object_unparent(OBJECT(&s->dev.rom)) before
continuing.

Replace the error_report() and error_printf() messages for this case
when the option ROM cannot be read via sysfs with a suitable
info_report() message.

In the case when the host option ROM cannot be read via the sysfs
interface, xen_pt_register_regions() will attempt to setup the option
ROM for the guest the same way it would for any other Xen passthrough
PCI device that has an option ROM.

Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - v4 is the first version of the series that has this patch

Changes in v5:
  - Shorten info_report message to resolve checkpatch line length warning

This patch provides initial support for many newer Intel IGD devices
so, at least, guest creation will not fail if such newer Intel
IGD devices are passed through to a Xen HVM guest. But this patch
alone is not sufficient for proper operation of the Intel IGD
for many, if not all, of the newer Intel IGD devices when passed
through to a Xen HVM guest.

There are two main problems with more recent, modern devices:

1. The newer divices might require patches to the Intel OpRegion
   and also an extended video bios table (VBT). Without support
   for these aspects of the newer devices, the experience will
   not be great and in many cases the Intel IGD still will not
   function properly in the guest.

2. The newer devices only work with UEFI AFAICT, and the Ovmf*
   platforms provided by the upsream edk2 project do not provide
   support for the Intel IGD. It appears the problem is that the
   ekd2 project deems the fact that the hardware manufacturer does
   not provide the necessary firmware, the EFI graphics output
   protocol (GOP) driver, in the ordinary way by making the EFI
   GOP driver accessible in virtual environments via the option
   ROM of the real PCI device, to be a reason to reject patches
   that add support for the Intel IGD. This, however, is not a
   fatal problem since it only affects the guest during early boot
   when OVMF or the bootloader is running and the guest OS
   graphics drivers have not yet been loaded. Lack of support
   for the Intel IGD in OVMF does not seem to affect the experience
   negatively once the guest OS graphics drivers have been loaded.
   So efforts to address this problem are only important in cases
   when it is necessary to get graphics output from OVMF and/or
   the guest bootloader.

The next two patches in this patchset address these two problems.
Of those two patches, the first one is more necessary, and the
second of those two patches is only needed to provide graphics output
from the guest during early boot.

 hw/xen/xen_pt_graphics.c | 7 +++++++
 hw/xen/xen_pt_load_rom.c | 5 +----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 0ae95cc..a124233 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -187,6 +187,13 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
         return;
     }
 
+    /* Case when the host ROM file from sysfs could not be read */
+    if (!bios_size) {
+        object_unparent(OBJECT(&s->dev.rom));
+        bios = NULL;
+        return;
+    }
+
     if (bios_size < sizeof(struct rom_header)) {
         error_setg(errp, "VGA: VBIOS image corrupt (too small)");
         return;
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 407b630..eaf0ae1 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -77,10 +77,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     memset(ptr, 0xff, dev->romsize);
 
     if (!fread(ptr, 1, st.st_size, fp)) {
-        error_report("pci-assign: Cannot read from host %s", rom_file);
-        error_printf("Device option ROM contents are probably invalid "
-                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
-                     "or load from file with romfile=\n");
+        info_report("pci-assign: Can't read Option ROM %s from host", rom_file);
         goto close_rom;
     }
 
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:05:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:05:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384043.1627165 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY6-0005aQ-3G; Thu, 06 Aug 2026 01:05:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384043.1627165; Thu, 06 Aug 2026 01:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmY6-0005aH-0C; Thu, 06 Aug 2026 01:05:30 +0000
Received: by outflank-mailman (input) for mailman id 1384043;
 Thu, 06 Aug 2026 01:05:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wrmY4-0005Nq-MO
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:05:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmY4-00GWgj-3E
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:05:28 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73dda4-2eae-0a2a0a5409dd-0a2a45059c28-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:28 +0200
Received: from [66.163.186.146] (helo=sonic302-20.consmr.mail.ne1.yahoo.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a73ddd6-4cb1-0a2a45050019-42a3ba928c39-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:05:27 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic302.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Aug 2026 01:05:26 +0000
Received: by hermes--production-bf1-54b5569bdc-xjdx5 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 734f0c8329adecc00a98ec91cc943adb; 
 Thu, 06 Aug 2026 01:05:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1785978326; bh=WVED5z9X3DhNfWYWPsssganxjMal/mDmQeJ0RW0UVpo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=ZocemVWyPNNRVCWp7tcTVgsj+okAl85RtnTc32+vJJ5sadpkFdJjGYhONhinL4v0zs+y+IwypGr20hAbhYz82xNsU+5MJVf7NWpB5o2LFRUZfsHpCu93egs1ixYs3kNRLbF6W/XJpFIgY5RMP4y+r0XOiixz1/MzjFYhn8+ovaC8s6o/6KDB8NIgdig7PcGQ7FRHRzp06DRAljcH2flA8PplF1h9GAGo0Hn5AtcDov9pSdGA82sL0FvnWrXVL1/13gYiNN04kw3IL9UmqxeHQIiAoOVwU/yRrGiyfxnGxxDxyaw4P7K7SVDzEJXVLtM8g7aPR0p627Fzr11HxMQZCg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785978326; bh=7iBAhNNuxjWjoR7/fE95Vs5pQIIIvyJSx7pSZDa7+RG=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=RNdXb/80spp6ENsUBxZI+42NUmGBdhNVnseX9RZtUI1LW2pzFeivMyNFP6yqM9RPGJ1/z6T/MCYOys8zdj5q9OyVwlpE0llOzSxclN62i+7AsrDqWaGxsLepTvuro9CuKjR0Tk4AXTut5OdGuwsoa7Ee8zqMICWW05o3BtGHirls/P+hzqk9yAOC19chNdfvrYuvMhnPUyKpr401hCLoSvaiLeJJjpKEIuj9+WC0wsJHe2bsscZtiy/eXR7NljIp2rbY1kLkSowLF7EsbeDS9JXSg2Q7MVY4Wsf0ka8tOzGEwm7TbUWtU6+9hh49QcvOR+DFaHdrFxxqINC2INxnxQ==
X-YMail-OSG: Bt9JW_UVM1lR7EDyBjBA4WITfblYAyVeX6sJfDcmO2E6TQejB0h7rMfn06k5CMk
 ePEHp0_1iFs3i4ESLe02aQZo6cc_EbOXlyVBMIOMSSWcZM2zSvHENUIru3gS5CRGqBBSd3.iZc2w
 whauvyh.OKTC26zl5Gcp13d1FeER4Ftf7qGC4PpsYV7MXAPiOYQS2jcGesa_xLvzfkvYggDcJ2rg
 bcLAJQhNHUa5g0B.YnoK29i_Qzko2SxW62S2_dk53np1yaifCh5Ig3i1rxQvkZ8uSRjcO3LFC7sL
 HOC6t_HjSQ4dNlUZA1bTrtSJhOAa2MEZDnt5vO9dMKWvM4jT0o2QsPEk_lLWiAzs8aWoKwrUeUiU
 XVbpI08AuJo28209ycuW8wrdi7hhy_rwEZFxSX4YyVG8lhhoMdjAObKBlsAA8hRxyqgOf8tjMA7O
 G5q9rv0_W2HJP151u6fvHOE49T4Unmv0mW_c0rqLFaayslmq1yHdq.biUChcDgkw98XXL62d0Apz
 2QF2.Pj_BSXWnLfUf.ok74zDZRuKDNaN.fTsFSlNQUWS8o7HiVBQD8Qj24XVjdFya_sqwrToDdOl
 Vk2Ly4STBXtMniRBxhDlVMcjkJbnmL1xMrQ9NBe31z.TrdUonhLd4HECLA.GUjwpVtp4oZv1Z8nC
 xkd3wXf9gGVdEDjJwQiSSbpp4mthgPFgvxIftnJwHhGjepewYjo4ne3tzUfflkx7xkmp80dhfKqy
 4NJrzbw2JlHaNmOY1W..oceP5arvKi7CfSb57feAZ9aPA3ZHSZn6o7rtU3pQfeAoG8K5LtmyPRs3
 _uPU4_E0suz0Yf1iq.Wg7x56A6cgtp9BpVRZF88qBGG8_XmNp_9Vaiu8sQcVYYqGK1.KadvCmFmR
 LUnfNL9KqUx_0REFtwJaV4WPWEd.1lmrb72pmQ6.5jjF3U5BCVHrjpqoJZAvqTvfEwCMPgBjaSiG
 VC5hK5kGcff7SfWcrMzfb8zW04Mc7Z72O3t3pYyU_L66Xp1mYvYuUlG.sh1kj6tSjAHASZiCMPvz
 6zpeqEKcp1OFQ5ExRUzN.GpQYEX8N5Rcu_pNjLis03ZFSafJp6_NWUI4GeBWvGBq1pBC.HS0WgXX
 zhezKvPUaFNpeT9jh1QQwiqooi8kY2lMxReIg5SxSamLG5FmctKmfG9BPizGeFwNBZTN16JLjSPp
 tpZ0afekS9_09yjLXSSiNwcX8SQhKYl0ZG5176fA4HdZRhALbaN7GuimYglTpPAoXfysHu6YeKKt
 JEGGbJVQp4gsB5daHu5YJfAn6NFNkV7MsxXvs.6cT64cI2SXkVEzLx8oCLEzB65MCsrlBMsPgoHP
 nD2JR5xNQTgKIfniy20WZBz7IZmJr10A_R0kNYhbGqyOvnPYZuReA3tC3hohLmjr2VsI4.hlW5No
 hoU.iaE8.0Ni4rC88p29TUS5rnlC469QdQAtsb0uKqA2yMRIA4.ajIirQZRLQ6TU2OQm11x5UyJY
 f6huFuXm6eSBRlvVTfsagdnxWoo6ICAUVzGIQzp45MI2U41eNyGJ8RUnFU5qiU42tL9NI5i3xdTz
 0L6be12TygPAfgiIDblB4zvby0K6SP_DBkP_RmkmotWWAEi2Ts3XrpYk8u1pekRTS33Bm.ko06wd
 soDlY9sAQYIEieX.7JU0cATWifWoLfcJS5O7EionM0m85RzoodGGZdlAKx7_8biI.GZJCL_qFmHj
 plIxPmwToxiPaOxC1tZ1wDUlJRwpUxEQ3kkrJkWCLjwhFEJ0CLdD7lvKXhHdQ_fMF1P2ZTSfrdvL
 qyPsuj0x.CDQMpggTsnfgKNdnGaMjqPWMGLJCuFnWvcK84UFfdJOJT89pALzbqDdU3bM6h_znBgU
 JXN0M6drr7GLt.aHUL7sCuD1snJEkznEzqEwFOUTmzYGzigQ9sizb6J3vuvCcyeQwETN9oMCw3J8
 3sZb.j4j0Lhe63EN.L8FqFTdJtbMYm7EFH1Rq4kev0eC_vDQzQptA_72ml7g_gLXkF4FVVC0aYdR
 73ulu5L7rRI.cn.q32eadpWxNvEi2VcMu7Q1d7mkEzn1q6b1rTob_1u52jDUxNmi8uoF.O5gG82h
 eQGgOQSK06ah8lTI6xYjO_2wE0uFrLinYUth33L8ND6Ey.Jx_lEtT7dEaBfPnXmpsEZBuoQU0FMW
 gpnwNHzWh1jiQaldlp5KQ6oRpSxjwYRqnlIzF.TZXQhXmOsIkECPQWnght4nZB2H1HMhJeeGrpcy
 60bgAaiL64O0UuyZHGa8cfiYNBIOkhahnYCGd
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 1c24a953-a693-4bad-a4c9-6097629114f1
From: Chuck Zmudzinski <brchuckz@aol.com>
To: qemu-devel@nongnu.org
Cc: qemu-stable@nongnu.org,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Tomita Moeko <tomitamoeko@gmail.com>
Subject: [PATCH v5 6/6] xen/igd: use custom option ROM if provided
Date: Wed,  5 Aug 2026 21:04:56 -0400
Message-ID: <20260806010506.492490-7-brchuckz@aol.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806010506.492490-1-brchuckz@aol.com>
References: <20260806010506.492490-1-brchuckz@aol.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 8876
X-purgate-ID: tlsNG-c201ff/1785978328-F4AA72A1-E2944F08/0/0
X-purgate-type: clean
X-purgate-size: 9089

Since in some cases the option ROM is not readable from sysfs
on the host, provide the option to use a custom option ROM file
instead that, for example, could be extracted from BIOS or UEFI
firmware and modified as needed for use with a particular Intel
IGD device.

The file must be named "igd.rom" and be located in a directory
configured at build time as a Qemu firmware directory and its
size should be a power of two, and it must be compatible with
the particular Intel IGD device being passed through.

If provided, the "igd.rom" file will be used as the option ROM
instead of the option ROM file epxosed in the host sysfs.

If no "igd.rom" file is provided, this patch has no effect.

Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v4:
  - v4 is the first version of the series that has this patch

Changes in v5:
  - Fix wrong whitespace in three places in a conditional block

Sorry for the length of these notes but there are many things
to say about this patch that are not obvious to persons without
some experience of actually trying to use the option ROM of an
Intel IGD when it is passed through to a Xen HVM guest.

This patch is primarily for providing a way to add Intel IGD
support for the OvmfXen platform to get graphics output during
early boot from modern Intel IGD devices that are only compatible
with UEFI for graphics output during early boot.

Note this patch is not necessary for successful operation of the
Intel IGD in the guest once the guest OS drivers have loaded. It
is only needed as part of the patchset necessary to provide
graphics output from the Intel IGD in the guest during early
boot when using newer devices that are only compatible with UEFI
for graphics output during early boot. Most older devices that are
compatible with legacy VGA BIOS will work with Seabios without
this patch, but they will need Patch 3 of this patchset to work
with Seabios.

Some notes on adding Intel IGD support for the OvmfXen platform:

It is necessary to provide an EFI graphics output protocol (GOP)
driver to the guest to get output from the Intel IGD before the
guest OS loads the graphics drivers when the guest uses UEFI.
This GOP driver is essentially the replacement of the VBIOS
driver that applied to older devices that use legacy bios, as
described here:

https://www.intel.com/content/www/us/en/support/articles/000005749/graphics.html

Unfortunately, with modern Intel IGD devices, the EFI GOP driver
is not provided to the guest in the usual way of providing firmware
for a PCI device in the option ROM of the real PCI device. So I
included this patch in this patchset to provide a way to expose
the EFI GOP driver to the guest. I was able to extract the
GOP driver for my device using the UEFI bios update file from
the motherboard manufacturer and the UEFITool available here:

https://github.com/longsoft/uefitool

That EFI driver can be wrapped into an option ROM using the
EfiRom bin wrapper that is part of the edk2 project:

https://github.com/tianocore/edk2/blob/master/BaseTools/BinWrappers/PosixLike/EfiRom

I tried setting the 'romfile' member of the PCIDevice struct that
is used by KVM/VFIO Qemu devices and emulated Qemu PCI devices, but
that did not work with Xen PCI passthrough devices. Neither Seabios
nor the OvmfXen platform could detect the option ROM in the guest
with that method of exposing an option ROM to the guest. So I
implemented this approach of substituting the 'rom' file exposed by
sysfs with an administrator-provided file instead of using 'romfile'.

In the commit message I mentioned the size of the rom file "should"
be a power of two. I mentioned this because the code in pci.c that
handles the 'romfile' setting for PCI devices enforces this
requirement strictly on the romfile that Qemu emulated or VFIO
devices use. However, I do not know for sure whether or not the rom 
file is strictly required to have a size of a power of two, so that
is why I say it should be a power of two. In my testing, I zero pad
the "igd.rom" file so it has a size of a power of two. I will accept
the suggestions of experts on this question about the appropriate size
of the option ROM file (I am not such an expert!).

As mentioned in the message accompanying Patch 4 of this patchset,
the official edk2 project does not provide support for the Intel
IGD, but some OVMF patches for Intel IGD support are available
online for KVM/VFIO guests, such as at the links below (they apply
to the OvmfPkgX64 platform):

https://github.com/cmd2001/build-edk2-gvtd
https://eci.intel.com/docs/3.3/components/kvm-hypervisor.html#build-ovmf-fd-for-kvm
https://github.com/LongQT-sea/intel-igpu-passthru

With such patches it is reported that the passed through Intel
IGD device lights up the display during early boot from OVMF
and the guest bootloader in KVM/VFIO guests provided that the
administrator provides the correct ROM file via the 'romfile'
setting for the passed thorugh Intel iGD device and applies
appropriate patches to the OvmfPkgX64 platform.

It should also be possible to add Intel IGD support for the OvmfXen
platform also but I have not seen any such patches online for OvmfXen
and if anyone knows of such patches online I would be interested to
be informed about them. I am also working on my own patches to
add Intel IGD support to the OvmfXen platform, in private for now.
If anyone is interested, I can make the work I have done so far
toward this goal avalable online.

 hw/xen/xen_pt_load_rom.c | 47 +++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index eaf0ae1..6c2aa8f 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -2,6 +2,7 @@
  * This is splited from hw/i386/kvm/pci-assign.c
  */
 #include "qemu/osdep.h"
+#include "qemu/datadir.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "hw/pci/pci.h"
@@ -13,9 +14,9 @@
  * need to be modified.
  *
  * For such cases, use this function to get a pointer to the option ROM
- * from sysfs. Caller has the responsibility to edit the option ROM as
- * needed, call pci_register_bar to register the modified option ROM,
- * and set has_rom to true for the PCI device.
+ * from a user provided romfile or sysfs. Caller has the responsibility
+ * to edit the option ROM as needed, call pci_register_bar to register
+ * the modified option ROM, and set has_rom to true for the PCI device.
  *
  * This function must be called before xen_pt_register_regions is called
  * because if xen_pt_register_regions is called first, it will register
@@ -32,17 +33,27 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
     struct stat st;
     void *ptr = NULL;
     Object *owner = OBJECT(dev);
+    g_autofree const char *fname = g_strdup("igd.rom");
+    g_autofree const char *path = qemu_find_file(QEMU_FILE_TYPE_BIOS, fname);
+    bool sysfs = false;
 
     /* If loading ROM from file, pci handles it */
     if (dev->romfile || !dev->rom_bar) {
         return NULL;
     }
 
-    snprintf(rom_file, sizeof(rom_file),
-             "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
-             domain, bus, slot, function);
+    if (path) {
+        snprintf(rom_file, sizeof(rom_file), "%s", path);
+        XEN_PT_LOG(dev, "Using Intel IGD romfile %s "
+                   "(administratior provided)\n", path);
+    } else {
+        snprintf(rom_file, sizeof(rom_file),
+                 "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
+                 domain, bus, slot, function);
+        sysfs = true;
+        XEN_PT_LOG(dev, "Using Intel IGD romfile from host sysfs\n");
+    }
 
-    /* Write "1" to the ROM file to enable it */
     fp = fopen(rom_file, "r+");
     if (fp == NULL) {
         if (errno != ENOENT) {
@@ -55,10 +66,14 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
         goto close_rom;
     }
 
-    val = 1;
-    if (fwrite(&val, 1, 1, fp) != 1) {
-        goto close_rom;
+    /* Write "1" to the ROM file to enable it if using ROM from sysfs */
+    if (sysfs) {
+        val = 1;
+        if (fwrite(&val, 1, 1, fp) != 1) {
+            goto close_rom;
+       }
     }
+
     fseek(fp, 0, SEEK_SET);
 
     if (dev->romsize != UINT_MAX) {
@@ -83,11 +98,13 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
 
     *size = st.st_size;
 close_rom:
-    /* Write "0" to disable ROM */
-    fseek(fp, 0, SEEK_SET);
-    val = 0;
-    if (!fwrite(&val, 1, 1, fp)) {
-        XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
+    /* Write "0" to disable ROM if using ROM from sysfs */
+    if (sysfs) {
+        fseek(fp, 0, SEEK_SET);
+        val = 0;
+        if (!fwrite(&val, 1, 1, fp)) {
+            XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
+        }
     }
     fclose(fp);
 
-- 
2.52.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:10:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:10:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384090.1627173 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmck-0001CR-JY; Thu, 06 Aug 2026 01:10:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384090.1627173; Thu, 06 Aug 2026 01:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmck-0001CK-Gs; Thu, 06 Aug 2026 01:10:18 +0000
Received: by outflank-mailman (input) for mailman id 1384090;
 Thu, 06 Aug 2026 01:10:17 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrmcj-0001CE-BP
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:10:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmci-008fJr-OZ
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:10:16 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73dee9-5cb7-0a2a0a5109dd-0a2a45068b46-6
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:10:16 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73def6-195a-0a2a45060019-888fbc3352a0-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:10:16 +0200
Received: by mx.zohomail.com with SMTPS id 17859786036791003.8173726789206;
 Wed, 5 Aug 2026 18:10:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785978606; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=BYDW82AB/c6PR6jHqfSPrXv/7tEAm9cd12rZVgegiYkRmLIT0aBa1eO7gHXtLY35eMuIwVkcGWTnQI9h6/c4lt8RGqEYxIROGdnNy7uzaXrw6iOO6SQY7rv2NZx2BKLDZuA4Nx+ajjZ19MFyWdsxeehjiegCV4dFRBYG3rwOpy0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785978606; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=WOVbCK6Sw64aXSe6a9720k6wPznzFto4aLH7lBPPGaE=; 
	b=G1h2+wvyuBFGDSqU3NFu70bhzWaA3apVhXiJy6s+IK8aW1Dg/4Xd0sNFfbDX4nDJ8DNWDMX8FB6OKefUVh4IXYTIL74r6S/7tgFKdLt+9uqf6KZoatjMNox32KjlBFM2szcG1OjlZTJ6JnUI8BeqAWxafHqgPflBFxtRHFi2MOA=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785978606;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=WOVbCK6Sw64aXSe6a9720k6wPznzFto4aLH7lBPPGaE=;
	b=kU8l+lv9qZwRtUSAnywyH4J+Xja9pVCid2XnELAjlt055ur/UI7lL/rhTDUOy1Yw
	WuZVN5Idu77RjDNusz56yCmiy2UKyP+jBudAd6wy2BLGAwxTd2oIW34jmuo85dY2yAJ
	DQov7Dxr71EfGc+jOcy6wheAWcqkNJsDGi66idAw=
Message-ID: <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
Date: Wed, 5 Aug 2026 21:10:07 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-16d1c6/1785978616-F520877B-2D071E36/0/0
X-purgate-type: clean
X-purgate-size: 3101

On 7/28/26 9:23 AM, Jan Beulich wrote:
> Like other resource management hooks they are different in just "add
> resource" vs "remove resource". Hence like in other cases a single hook
> can easily serve both purposes.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -109,7 +109,7 @@ int physdev_map_pirq(struct domain *d, i
>           return physdev_hvm_map_pirq(d, type, index, pirq_p);
>       }
>   
> -    ret = xsm_map_domain_pirq(XSM_DM_PRIV, d);
> +    ret = xsm_map_domain_pirq(XSM_DM_PRIV, d, true);
>       if ( ret )
>           return ret;
>   
> @@ -142,7 +142,7 @@ int physdev_unmap_pirq(struct domain *d,
>       int ret = 0;
>   
>       if ( d != current->domain || !is_hvm_domain(d) || !has_pirq(d) )
> -        ret = xsm_unmap_domain_pirq(XSM_DM_PRIV, d);
> +        ret = xsm_map_domain_pirq(XSM_DM_PRIV, d, false);
>       if ( ret )
>           return ret;
>   
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -461,14 +461,7 @@ static XSM_INLINE char *xsm_show_irq_sid
>   #ifdef CONFIG_HAS_PIRQ   
>   static XSM_INLINE int xsm_map_domain_pirq(
> -    XSM_DEFAULT_ARG struct domain *d)
> -{
> -    XSM_ASSERT_ACTION(XSM_DM_PRIV);
> -    return xsm_default_action(action, current->domain, d);
> -}
> -
> -static XSM_INLINE int xsm_unmap_domain_pirq(
> -    XSM_DEFAULT_ARG struct domain *d)
> +    XSM_DEFAULT_ARG struct domain *d, bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -68,8 +68,7 @@ XSM_HOOK(int, kexec)
>   XSM_HOOK(int, schedop_shutdown, struct domain *, struct domain *)
>   
>   #ifdef CONFIG_HAS_PIRQ
> -XSM_HOOK(int, map_domain_pirq, struct domain *)
> -XSM_HOOK(int, unmap_domain_pirq, struct domain *)
> +XSM_HOOK(int, map_domain_pirq, struct domain *, bool)
>   #endif
>   
>   XSM_HOOK(int, map_domain_irq, struct domain *, int, const void *)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
>   
>   #ifdef CONFIG_HAS_PIRQ
>   
> -static int cf_check flask_map_domain_pirq(struct domain *d)
> +static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
>   {
> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
> -}
> -
> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
> -{
> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
> +    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>   }
>   
>   #endif /* CONFIG_HAS_PIRQ */
> 

I am not opposed to collapsing the calls as long as the semantic is not 
lost, which I feel the reuse of the xsm_map_domain_pirq does looses it 
much less provides an opportunity for confusion. Something like 
xsm_domain_pirq(..., access) makes more semantic sense to me, as it 
would read, grant domain pirq access T/F.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Thu Aug 06 01:17:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 01:17:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384099.1627183 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmjD-0001v2-BU; Thu, 06 Aug 2026 01:16:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384099.1627183; Thu, 06 Aug 2026 01:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrmjD-0001uv-82; Thu, 06 Aug 2026 01:16:59 +0000
Received: by outflank-mailman (input) for mailman id 1384099;
 Thu, 06 Aug 2026 01:16:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wrmjB-0001ul-Uv
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 01:16:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrmjA-00Do4S-Sw
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:16:56 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73e07b-2eae-0a2a0a5409dd-0a2a450983c2-12
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:16:56 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a73e087-be1a-0a2a45090019-888fbc3352a8-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:16:56 +0200
Received: by mx.zohomail.com with SMTPS id 1785979003559740.7769617646599;
 Wed, 5 Aug 2026 18:16:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1785979007; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=R8gJm8Zm80GT4sAWpV5I+3zGT3kpCqyLu81aDqKdnfcXoGKuUQhIC7cOURejOCEdBteqjSpgMb+cBSP09G6p+2fdHMOcWL6ZDJ1h0FEbbZuHlhf7A0dKQCY9JB6wkvOG5CSpKKo/RCCb/blk+Icuy+9waBUzfLuMU7e3ipfTEEo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1785979007; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=V3/EhLMHE8sXOMAwNruXoiI8Fv5KpArkvZMGohzfTcI=; 
	b=OHqb1uJF0Ed8BDeOMVq0srEpg3z/97mferUtYLBY2/HqA1LtXUyNpjv8W19ShVk/TaBpdSxGSkxUGgzvYytUhcaLOZHoLukGdecVa1f/ilLn4Y4CIBQ3xpoZaLPLLKv1BsYgUiJkODcfv+IWQZrTyhdgxwom0b3+2B9nF4VCkr0=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1785979007;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=V3/EhLMHE8sXOMAwNruXoiI8Fv5KpArkvZMGohzfTcI=;
	b=jSXjrsSsS/6dm8pqDxEP9JVXaG7q3bgisy2QlyMEMnMczZ7dlGAXGWo56aLzW6Hw
	10bCJaH8Px3ezNxfHgwwGk5/MwULedB3Ogr2m6kau1jyeb8yY0gqLbwoL1dw9lULdtt
	N9zqGkrk0uvtZq5vhAD2kekK0hVPnpk6X84j7YAE=
Message-ID: <ba033c3d-dd62-4f94-b90c-0a749ba8b905@apertussolutions.com>
Date: Wed, 5 Aug 2026 21:16:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 22/24] XSM: pass just SBDF to xsm_{,un}map_domain_irq()
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <a1c5dd1c-9b7b-4bc2-b202-7e2a4eb210e2@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <a1c5dd1c-9b7b-4bc2-b202-7e2a4eb210e2@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-bad1c0/1785979016-BECDF034-D62AB649/0/0
X-purgate-type: clean
X-purgate-size: 5386

On 7/28/26 9:25 AM, Jan Beulich wrote:
> That's what Flask needs, and by unifying the hooks flask_map_domain_msi()
> can then also serve both flask_{,un}map_domain_irq().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> How come Arm doesn't use xsm_unmap_domain_irq()?
> 

I do not know, perhaps a gap in completeness. I would have to go study 
it to see if there was something more to it.

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2214,7 +2214,7 @@ int map_domain_pirq(
>           return 0;
>       }
>   
> -    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi);
> +    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi ? &msi->sbdf : NULL);
>       if ( ret )
>       {
>           dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
> @@ -2442,7 +2442,7 @@ int unmap_domain_pirq(struct domain *d,
>        */
>       if ( !d->is_dying )
>           ret = xsm_unmap_domain_irq(XSM_HOOK, d, irq,
> -                                   msi_desc ? msi_desc->dev : NULL);
> +                                   msi_desc ? &msi_desc->dev->sbdf : NULL);
>   
>       if ( ret )
>           goto done;
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -470,7 +470,7 @@ static XSM_INLINE int xsm_map_domain_pir
>   #endif /* CONFIG_HAS_PIRQ */
>   
>   static XSM_INLINE int xsm_map_domain_irq(
> -    XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
> +    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
> @@ -491,7 +491,7 @@ static XSM_INLINE int xsm_unbind_pt_irq(
>   }
>   
>   static XSM_INLINE int xsm_unmap_domain_irq(
> -    XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
> +    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -71,8 +71,8 @@ XSM_HOOK(int, schedop_shutdown, struct d
>   XSM_HOOK(int, map_domain_pirq, struct domain *, bool)
>   #endif
>   
> -XSM_HOOK(int, map_domain_irq, struct domain *, int, const void *)
> -XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const void *)
> +XSM_HOOK(int, map_domain_irq, struct domain *, int, const pci_sbdf_t *)
> +XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const pci_sbdf_t *)
>   XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1030,17 +1030,14 @@ static int cf_check flask_map_domain_pir
>   #endif /* CONFIG_HAS_PIRQ */
>   
>   static int flask_map_domain_msi (
> -    struct domain *d, int irq, const void *data, uint32_t *sid,
> +    struct domain *d, int irq, pci_sbdf_t sbdf, uint32_t *sid,
>       struct avc_audit_data *ad)
>   {
>   #ifdef CONFIG_HAS_PCI_MSI
> -    const struct msi_info *msi = data;
> -    uint32_t machine_bdf = msi->sbdf.sbdf;
> -
>       AVC_AUDIT_DATA_INIT(ad, DEV);
> -    ad->device = machine_bdf;
> +    ad->device = sbdf.sbdf;
>   
> -    return security_device_sid(machine_bdf, sid);
> +    return security_device_sid(sbdf.sbdf, sid);
>   #else
>       return -EINVAL;
>   #endif
> @@ -1066,15 +1063,15 @@ static uint32_t flask_iommu_resource_use
>   }
>   
>   static int cf_check flask_map_domain_irq(
> -    struct domain *d, int irq, const void *data)
> +    struct domain *d, int irq, const pci_sbdf_t *sbdf)
>   {
>       uint32_t sid, dsid;
>       int rc = -EPERM;
>       struct avc_audit_data ad;
>       uint32_t dperm = flask_iommu_resource_use_perm(d);
>   
> -    if ( irq >= nr_static_irqs && data )
> -        rc = flask_map_domain_msi(d, irq, data, &sid, &ad);
> +    if ( irq >= nr_static_irqs && sbdf )
> +        rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
>       else
>           rc = get_irq_sid(irq, &sid, &ad);
>   
> @@ -1091,32 +1088,15 @@ static int cf_check flask_map_domain_irq
>       return rc;
>   }
>   
> -static int flask_unmap_domain_msi (
> -    struct domain *d, int irq, const void *data, uint32_t *sid,
> -    struct avc_audit_data *ad)
> -{
> -#ifdef CONFIG_HAS_PCI_MSI
> -    const struct pci_dev *pdev = data;
> -    uint32_t machine_bdf = (pdev->seg << 16) | (pdev->bus << 8) | pdev->devfn;
> -
> -    AVC_AUDIT_DATA_INIT(ad, DEV);
> -    ad->device = machine_bdf;
> -
> -    return security_device_sid(machine_bdf, sid);
> -#else
> -    return -EINVAL;
> -#endif
> -}
> -
>   static int cf_check flask_unmap_domain_irq(
> -    struct domain *d, int irq, const void *data)
> +    struct domain *d, int irq, const pci_sbdf_t *sbdf)
>   {
>       uint32_t sid;
>       int rc = -EPERM;
>       struct avc_audit_data ad;
>   
> -    if ( irq >= nr_static_irqs && data )
> -        rc = flask_unmap_domain_msi(d, irq, data, &sid, &ad);
> +    if ( irq >= nr_static_irqs && sbdf )
> +        rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
>       else
>           rc = get_irq_sid(irq, &sid, &ad);
>   
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 02:15:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 02:15:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384119.1627192 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrndE-0007bD-Bb; Thu, 06 Aug 2026 02:14:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384119.1627192; Thu, 06 Aug 2026 02:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrndE-0007b6-8l; Thu, 06 Aug 2026 02:14:52 +0000
Received: by outflank-mailman (input) for mailman id 1384119;
 Thu, 06 Aug 2026 02:14:50 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrndC-0007az-D4
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:14:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrndB-005SbK-QK
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 04:14:49 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ed9f-2eae-0a2a0a5409dd-0a2a4508c090-42
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:14:49 +0200
Received: from [40.93.201.62]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee17-f659-0a2a45080019-285dc93e5ab0-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:14:49 +0200
Received: from BN1PR14CA0030.namprd14.prod.outlook.com (2603:10b6:408:e3::35)
 by CY8PR12MB7708.namprd12.prod.outlook.com (2603:10b6:930:87::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Thu, 6 Aug
 2026 02:14:43 +0000
Received: from BN3PEPF0000B077.namprd04.prod.outlook.com
 (2603:10b6:408:e3:cafe::8f) by BN1PR14CA0030.outlook.office365.com
 (2603:10b6:408:e3::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.20 via Frontend Transport; Thu, 6
 Aug 2026 02:14:42 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BN3PEPF0000B077.mail.protection.outlook.com (10.167.243.122) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Thu, 6 Aug 2026 02:14:42 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 21:14:42 -0500
Received: from [172.19.79.34] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Wed, 5 Aug 2026 21:14:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DO/bjLARzlv+5rkIBW7/wS8kN6Cmo/cKvRD1iwfO3MAqqWIdOqoGY+Cmnpk3Pmv5Fx/2VP8ScxF+t1CNPgh60krhudF7xydnya0a+lTyhbZtVMjaPNw9P3AlKKwlrcOLjToKurEZZs6uMK9f2VK/GnxLabF8DvyYXxYYM7W3z4QXluQLV0bPrS3VX0dAoXCX78/2TQKP9CuKQsQGH1/ZBV84duwFkZUX30bMAusR3C/lbzqeX8NkvNPUlc2Lbw3KnIiX1oxTzFnLnfz1K0j8X+C0IboSmLOpCo0IzN2pTvYTAT06Gs6aRLYH1IvWSv5UoovMB8PYblrRNUuxKWXwlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0P6fp9yfApqMGT/Drm+Sfrk8wWNTPqAvXMP5hletWlQ=;
 b=zL4/G5PcNin02TnDsfhULQvRftXDPHo5b5+aGnquY2aKI7ijB5f2MEs9cRiQh/1LyO5oX2I7lUmyVtf0tMA+OcKrwUSHGUUxZ4pKef69ZL1mjaFumxAi1Yts29nz3bHEVrTB7qB/zL8O2J1DWbY8bcxmNC1FOIRDO1nx+pwGJOzHVpABaY+39mp1Y3+t0pacoBycCJTlPSlzEVP2qUdypRBilI5gx4zpcwajRrFN4mq7Y0vm0JTTdlIvG0hUL+5V9E+CzxE/J01vqViAky4B8cuvQ/XHzFsjophVZlmgdalN5OS1Qfs3APX25tUP98M7ER1EX1xw5u/VgSqw4oZjyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0P6fp9yfApqMGT/Drm+Sfrk8wWNTPqAvXMP5hletWlQ=;
 b=4zo/WxPdPif9OwB8yQNv2lX4oohJQ2IluQSjTOTpAskU9119aed3JP+LCj9lstlvXKBCu42yEsbA/uPtsKr2Ay9peG8818g7sv3N0v4ZHrHSxvzC4mS7TihorSHDvrUfzbg5bY/pSdHKR0IMdRUQYh7o5UNpeXJtvgaZ+Sh3Hv0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <f45d2a03-a9df-4d39-8c9c-2276d4f0ebea@amd.com>
Date: Wed, 5 Aug 2026 21:51:34 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] xen: Drop CONFIG_XEN_PVHVM
To: Juergen Gross <jgross@suse.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, <linux-kernel@vger.kernel.org>, <x86@kernel.org>
CC: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	<xen-devel@lists.xenproject.org>
References: <20260805082137.1214967-1-jgross@suse.com>
 <20260805082137.1214967-3-jgross@suse.com>
 <7179e004-76df-42be-94fd-f314614e65cd@citrix.com>
 <15824536-dff6-426d-b54c-6a1f362adaa2@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <15824536-dff6-426d-b54c-6a1f362adaa2@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B077:EE_|CY8PR12MB7708:EE_
X-MS-Office365-Filtering-Correlation-Id: 117afe2a-f8f9-4b26-fe0c-08def3607a3c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|23010399003|82310400026|36860700016|1800799024|18002099003|22082099003|4143699003|10067099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	cDep0RmGVdJ+FSUDwi9N56Qf9kpKG3n/heqNoO25ONzqSllnxpGK23rJIZnNr4ZfyUS6Mn+wJOrn+hVMCshsCgYY7yeBcf+MQtAmcYTBziJPZfTQBIXTv52PvWsLm1FYaVZv50PeFo748gXXIIvRy/WnDFJAQsMAWU+m8WmZsIqc5uMtm7Tkc4OyVLL6S5zy00jg4ZVNtzWpZnk8V28FGAJhLcEuuLHn12f7YAdYegEWu1BxW7DTHK/tHLtIAKQ+peoWeK1qyXzUC9+zu6dIF8qCT/3xQqR9F1rVp2dY0QdYHMpHNb+U+LkbZshhPbvl7wdLuSCoKgO9+36gIlOuhC8wosvSgqAdPonjPQOJdNcHiULpOjVEMIdSQrGlQD3nlpCGyOIx+n7W5lEVEXzVPTOUzx0cUw87MIOg/5e09ICiAI571sdjsd50/kMghOzL5aXfKKh/OR5m1+iRXaDUjg197ZZIwUwW+OOomwcyM6tYS3A5CTEpZykZQmsqAVksL3n3Hxkavz6PnwW1im9vAdinH4+HO5FVCCX5eJui4FyGB48vPipTFRxFIwPGuonWX10isQHZs7Ju4GKzVRRT4zWeguCOqDwb4gbQ58rWgt/WSJ1UQ2ohxqlLurcwvFPdjESUO67p+66icKmYkrw4sVwGn/Z/wKTwXPUnTL17JYKQVFVGyzVtnK4iJlj6fk77wNkhQAOByFmn/BsiFJnH4Q==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(82310400026)(36860700016)(1800799024)(18002099003)(22082099003)(4143699003)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	xv+R/7yqZcLhE13Vq5fJu6lI/PUV0ZrbwRUN3fsGyVgHHPPr28PVk3tfIO/AK+uUlExFxHVBmJc+DtrVA2lkZeb4RFLP32314BcaPX3YbYmU6AA1AW5ieBLbzxW7EbsWCbiBWjo9Ul/vbZFWT1KWbQXehjZVb7yo6nj3gOAgRN1m4wmdlrqdwz+uMf5mzyveFSVJuX4FtguRLRqViS+PTJ4M8rTcBePhyIerZeM4V4T4iEmAf5dIV30iplNR7CmpNL0ETPHMh/5SC1ppzRkpJrYiyiUwi+lDpTSsGoRmloLfvzXB5sjfg7MzT8z0IlOXhp/ite4nFCxEIBIRz9A575rOUAiGKWxzyy4aAv/gVfoVL66vWFhp2QYdUKIyHjQhwguoNSDxeMQBo7pq6+a1e+MJ6wl4jPQ9fZFDmGs6rtHM0+3EADBW7lHgqqFinMmZ
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 02:14:42.5971
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 117afe2a-f8f9-4b26-fe0c-08def3607a3c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B077.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7708
X-purgate-ID: tlsNG-c1860d/1785982489-CD74B87B-81BC9252/0/0
X-purgate-type: clean
X-purgate-size: 1899

On 2026-08-05 04:36, Juergen Gross wrote:
> On 05.08.26 10:28, Andrew Cooper wrote:
>> On 05/08/2026 9:21 am, Juergen Gross wrote:
>>> On x86 CONFIG_XEN_PVHVM is now a synonym of CONFIG_XEN.
>>>
>>> In Xen specific x86 code it can be just dropped, in non-Xen specific
>>> x86 code it can be replaced with CONFIG_XEN.
>>>
>>> In architecture independent code it is used only where CONFIG_XEN is
>>> defined, so it can be replaced with CONFIG_X86 there.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/ 
>>> idtentry.h
>>> index 20f548702404..f400cfac69a6 100644
>>> --- a/arch/x86/include/asm/idtentry.h
>>> +++ b/arch/x86/include/asm/idtentry.h
>>> @@ -745,7 +745,7 @@ 
>>> DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR,        
>>> sysvec_hyperv_stimer0);
>>>   DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,    
>>> sysvec_acrn_hv_callback);
>>>   #endif
>>> -#ifdef CONFIG_XEN_PVHVM
>>> +#ifdef CONFIG_XEN
>>>   DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR,    
>>> sysvec_xen_hvm_callback);
>>>   #endif
>>
>> I'm very happy to see a reduction in the number of Kconfig symbols for
>> Xen (there are definitely too many), but this looks wonky.
>>
>> Or are you saying that there really is no way to build a Xen PV guest
>> excluding the HVM-only bits?
> 
> Seems so, yes.
> 
> This has been like this for at least several years now.
> 
> What you can do is to configure the kernel to exclude the Xen platform PCI
> device (CONFIG_XEN_PVHVM_GUEST=n).
I think I caused this inadvertently in 34aff14580d1 ("xen: Remove Xen 
PVH/PVHVM dependency on PCI")

CONFIG_XEN_PVHVM should just be bool, and then XEN_PVH & XEN_PVHVM_GUEST 
can select it.  Then it can be disabled for a PV only build.

I'll send it out, so you can evaluate it.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 02:15:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 02:15:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384126.1627200 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrneH-00082A-Ko; Thu, 06 Aug 2026 02:15:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384126.1627200; Thu, 06 Aug 2026 02:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrneH-000823-IB; Thu, 06 Aug 2026 02:15:57 +0000
Received: by outflank-mailman (input) for mailman id 1384126;
 Thu, 06 Aug 2026 02:15:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrneG-00081o-CG
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:15:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrneF-006DJx-PG
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 04:15:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee22-bab6-0a2a0a5309dd-0a2a4508dc6e-44
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:15:55 +0200
Received: from [52.101.53.63]
 (helo=BL0PR03CU003.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee5a-f659-0a2a45080019-3465353f0e4b-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:15:55 +0200
Received: from MW4PR02CA0005.namprd02.prod.outlook.com (2603:10b6:303:16d::14)
 by SN7PR12MB6690.namprd12.prod.outlook.com (2603:10b6:806:272::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.17; Thu, 6 Aug
 2026 02:15:46 +0000
Received: from SJ1PEPF000026C6.namprd04.prod.outlook.com
 (2603:10b6:303:16d:cafe::84) by MW4PR02CA0005.outlook.office365.com
 (2603:10b6:303:16d::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.19 via Frontend Transport; Thu, 6
 Aug 2026 02:15:45 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ1PEPF000026C6.mail.protection.outlook.com (10.167.244.103) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Thu, 6 Aug 2026 02:15:45 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 21:15:45 -0500
Received: from fedora.mshome.net (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Wed, 5 Aug 2026 21:15:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ff7yCzeY2fiHOc+IDfZLIZuZVKwJyf4/hOzKyCR2UQeatP51RAUY/ypm3DwF0TlWqQdD0ybB2M+cnwf5+qqXqCmWl6OqeQPPDNo/ZHum41SK5TmkbBNeZqNNx4ao8z5cdBIzLTcMLt08oVynO3mvYn5HVu+KBbqMpOhEYSOnmw8jvojfvwyrXgqtHDI3qp/UpGqmoW3TIsRZQyYTJn29a1RvHeQ4mB2zb02w0Wvdf5AsINHcEiDwQiWO9wwvAT7yV0WlaBhfutAbnUFNRQ4kun3i/KALe6vGZfWXmdmYvBGxDomz5pVZ0zp20Yw5B+r+Wg4YiOJNorRKQjy9hSl29Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jX3bNwYFJtQHkDdoGtRpfMniKOM+GB0LphuiU0WB4hM=;
 b=PwLefr11JQpo56ryxxt9ZBgkoc6Wl5IzsNprJcdi20RHKqUuyo+k4cUUGRi3x1t25hGIIYz738whTx9K9dwzRe53O04oYMBt1nueP4a9KZoSokjjq2g9apR2APpldTJXq/NCk8Li+/ZT7Mps0Z5nrF0tTGW71vXDAhG/p44Yo3q6DYZkvKia8Vf300hovDhDDWyBWjTiJGJbkBJP9AyazCiMqON4vL3OLhfldYIFbzmTxoiQDqmy8cXrfq7UStCXIgrYldiryvkAE1n5NJ2MiaXed+JUnRI1z3fYzU1cfZCHnHaZcU7WdEX5w6bwBNJtYHAMrfLRmlkbtBFot9+1Jg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jX3bNwYFJtQHkDdoGtRpfMniKOM+GB0LphuiU0WB4hM=;
 b=iQn37Xgmzdm9FPhOiG2k1AohDPyRFVVAdw/Uzs1/rdMIl7x4LdLFO555q+ZiQZK8sCaEHBg4GDlTZczHSUFlt/qBJoeyP2rO//j0FnKd6ltpopaO1Sjyx015HqqpPZBnge7Mz9j8rtLGTTEdK4JflGndDRYSVkZz/f5GcYEqYTs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Jason Andryuk <jason.andryuk@amd.com>
To: Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross
	<jgross@suse.com>, Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Jane Malalane
	<jane.malalane@citrix.com>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, "H. Peter Anvin"
	<hpa@zytor.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Jason Andryuk
	<jason.andryuk@amd.com>, <xen-devel@lists.xenproject.org>,
	<linux-kernel@vger.kernel.org>
Subject: [PATCH 0/2] xen: Fix PV-only build
Date: Wed, 5 Aug 2026 21:52:29 -0400
Message-ID: <20260806015233.202486-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C6:EE_|SN7PR12MB6690:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c36e370-57f2-458d-3902-08def3609ff6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|23010399003|36860700016|7416014|376014|18002099003|11063799006|10067099003|56012099006|921020;
X-Microsoft-Antispam-Message-Info:
	Ibu/xr63siR0DF2AA2xQ7uGE3BrBlvSyupte6c0UjYGWkSstrwf6VPeBJrlGl9H9NV7C+/pXI7IvJeNxYIir7USqwVF7zkzT8J8TRuVHULCHv13udPolIeqkfHloRYw6CpMKWWu4rXYZ/S3gb7U9ZS/MhS6ajIoe/VDZxEt3ZsFMP6SX++0paaBLETZwu19H/5SOoduriVrcEirKU7ocWCEzzojq8lB3vd+q64nyyCeZuWzyIP6rejeoR+WY7IStt0swXVaGxPmV/g3SFRg2y4jo6rmwc/3PNdcs9SR4nnx6TrTAvkLFNoR58YMu1xUrLR1GKKJy89oZPyEa4LDk7LuQdvebE3ARdR9oQQZNcaC/8jnU1aXmoIQX9S4pILKJzcT25BSKIWKWaFWE/RJ93icXM4RSNRFCkkarIq370DHjUkWkQykx1nLF/6yonZw6+vchn4ZaHNAqvSt7BVnCwp9ekGHegODCwluWE8ef8atadUlqGHpYqyE9M2DhSDHrNlcEN3ZaxFsg3yQ0x/F3d38iFgxVdbb0vXZa6wxttrLz5Pvdlnx3jJj0tAMTbt/L+kuoPOM4cWsS2VJ4T9/5ZEM9njEjCtB5U9rggygdt611KT7MqVGGHnta7IPjUo4/Q09J6PqfENdiMn2Nlf60xXNMUNK9lG10SkK7ebk7HnyCgCgmuRs4Z1rjmky/1AQvIM3DekMdxcbd/3obACpQuUWTt1hWgqIH2/yLIgTPQsPV5uOw+4vXs7qGmPExbnDb
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(23010399003)(36860700016)(7416014)(376014)(18002099003)(11063799006)(10067099003)(56012099006)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Gk16PvomKptKGYo4kWQuqvF5e49bpUhBp4YmMi5zxirbK1zzsBtaU9htBbhOwoTVjnfdol8iZq/cDdZP/A5DlF9FL6XlosNdFYW2p1moE3FfiXgQmRkhsLamyJ8oHobNrBN0viciJs+al8wvU+KArssVM87frf0mA3hAM9rTGAKUS7szBO9cyvHchg7jV0MVzTHL5vWujab3VCcOq2XfTWJt1iMxSDMorN7Wh6vFt2zVuPlp1CKr1FSUqGHr6ymBhrviBM8efbjjbRDSAzmYpX5hjJ2s1IKs2XKRL4i6JxB1+diJ5kWa6yIpE5vyEJsYQipbaRQShdmCL+EWOF0GaVGx8nO/vCOBacRRPcLLPZoGRWxi2KeriIP9x0WbWHYnWpnxXvu/NRojDchgBKRhmqrtir2l2FQXKpTvJEDcsBQsfJhNltEAnDGbOTXf121b
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 02:15:45.8046
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c36e370-57f2-458d-3902-08def3609ff6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000026C6.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6690
X-purgate-ID: tlsNG-c1860d/1785982555-CEB4187B-A1B31A69/0/0
X-purgate-type: clean
X-purgate-size: 363

Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
code needs to be fixed first.

Jason Andryuk (2):
  xen/events: Fix xen_set_upcall_vector stub
  xen/Kconfig: select XEN_PVHVM

 arch/x86/xen/Kconfig             | 8 +++++---
 drivers/xen/events/events_base.c | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 02:15:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 02:15:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384127.1627210 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrneI-0008F2-Sp; Thu, 06 Aug 2026 02:15:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384127.1627210; Thu, 06 Aug 2026 02:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrneI-0008Ev-Ot; Thu, 06 Aug 2026 02:15:58 +0000
Received: by outflank-mailman (input) for mailman id 1384127;
 Thu, 06 Aug 2026 02:15:58 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrneI-000822-3J
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:15:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrneG-00GdGF-WF
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 04:15:57 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee52-5cb7-0a2a0a5109dd-0a2a4505ebc2-2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:15:56 +0200
Received: from [40.107.208.28]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee5a-4cb1-0a2a45050019-286bd01c69af-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:15:56 +0200
Received: from SJ0PR03CA0345.namprd03.prod.outlook.com (2603:10b6:a03:39c::20)
 by CY8PR12MB7099.namprd12.prod.outlook.com (2603:10b6:930:61::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Thu, 6 Aug
 2026 02:15:51 +0000
Received: from SJ1PEPF000026C9.namprd04.prod.outlook.com
 (2603:10b6:a03:39c:cafe::8d) by SJ0PR03CA0345.outlook.office365.com
 (2603:10b6:a03:39c::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.19 via Frontend Transport; Thu, 6
 Aug 2026 02:15:51 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ1PEPF000026C9.mail.protection.outlook.com (10.167.244.106) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.292.8 via Frontend Transport; Thu, 6 Aug 2026 02:15:51 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 21:15:50 -0500
Received: from fedora.mshome.net (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Wed, 5 Aug 2026 21:15:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xdo5L35LXODd09otAaJlr+S+QtR0J72oZRMdNbQdDuDizhVzbujhnl0H8/kAhYbT3RyEzipFdT38oEwZA5G9BylqSh/HQkoA9zarHkJJoO8v6v1A5cdYwNb0BepxmIQJbFnbDhH/WoR/XoQXUKvHCgxH8JI0JPnkJ45UMjoUqJB8TI0pCwyyesUPricqPqpLl4GN4C8Uk0kZFBEta3xVptQls+jddGyHhHt0RssKRaMGqGkt9aRNTzPzgDaqWVS4ZojxGmfPPRP+1rXcFoqEVuOeNwk1ZCzCNnPFlN6aK100iuTJ26cRXAKqsLLZ88IbmMWVBDcjw/KBY76fDSup7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pXAvQeolZboNEWTS4fZrLvWfW/st6wbkjRYk4ih4T68=;
 b=QxV8HxKd4NbZjW/gd1JgFD60eTICMpYstSXbzZpr9eYvXP1gvpTi0CYnUL/ena2thrZ5i74C2m5KwE4KnUTxLkjpmQnkWI7wMITxhWJnFW2UdQ60K/W0aMUqq7MaVYNHQk7TDZ969fLZZdDN08CTexCO7L82w8UbZNh5b5hlnzVDPNVeHxLd6T5V3pek9A9JzxNJFJm3zPOeWr9KEwL/3YsO46SbNtNG2w6Y8kvaqR1AoRgb9HyJH0IXIVZh0LcxcqKU8uBTyv782gglVpF1tdg5m+dILId0Rwvp9jfucSa0cxC3oga5bIVu7ODySeG174FDalpXVBHz3D16P+xdfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=pXAvQeolZboNEWTS4fZrLvWfW/st6wbkjRYk4ih4T68=;
 b=pqryTsKuQaSM60OUjRqZR+vZ6Cj/CbqsgcGWs5tTeMFvDsYqVWlxLPzaTO1Ysq07c8h9sIK7v3xEFs//FnjJP548g7WRvZCc38u35KTctMWtY0sg0MjFiMvK1UdA8yix5B5edq7smNLcRlpsJ5q9pfNwKXROp2WAIXIqbkVKUc8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Jason Andryuk <jason.andryuk@amd.com>
To: Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross
	<jgross@suse.com>, Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Jane Malalane
	<jane.malalane@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Jason Andryuk
	<jason.andryuk@amd.com>, <xen-devel@lists.xenproject.org>,
	<linux-kernel@vger.kernel.org>
Subject: [PATCH 1/2] xen/events: Fix xen_set_upcall_vector stub
Date: Wed, 5 Aug 2026 21:52:30 -0400
Message-ID: <20260806015233.202486-2-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260806015233.202486-1-jason.andryuk@amd.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C9:EE_|CY8PR12MB7099:EE_
X-MS-Office365-Filtering-Correlation-Id: 8d62d85c-85e0-4988-5a79-08def360a32f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700016|23010399003|11063799006|10067099003|18002099003|22082099003|56012099006;
X-Microsoft-Antispam-Message-Info:
	g+6irZcPPMyS5Z+fpScCudS5BQHP0IvueDRiFeFmCcr7kMfd77p/dz/COJ9n0EAEYE+zNspkroz6u+Cln13AHl1XhtODFA9yD1DlsEUU76VUuEXG5F8kkU9TRTzL0N6sISXpVwhNhJMdvYEHXOqAmd7m6A0UEiReomyNyz11XGHJ+pfLQr4kour9Aexqy/d2NOhWsPYCQ5+MUs5k4PW4f2GJmwddn9BswEyNZ8suCpl+NnOZzndFE4pzjwGvK5s3cujMj1+KtuHKi5cKmD80O6z2KPGNtGuKnZwpof61anHWH5CrTjYk219+iNDcEAyVSHfArQvv72zBBIYnmK1x7RcSQxxStG23LOBCCU57u6XSdzHaTmPz1hSrFPdMs9xGAotF6H+IqcUpTF+4sI8Z1Nr/diEc40nBDQqzfYkTkYvCUMHJ3v0h2TBfoqsr5jaeF5qhxWE/iMH3xTB31h5Q1OOSif6hpzoUCoTWP/j0FebzocZfsfXC+9OPqrHNnL5X2MDucvqPGwiam0BVQSDptNLY0jI3ME7mV8EkRhgsYHzjOAejf0/JdZq8+diGTr8BUyHNmzq6+goBlgN1sU1eP/JPYbZGAn3cyzISPXneYgMn1yiT230SfHD4eQVAOhxNq5UOrmL6/gCEex0MuqdZ6aTDC7FbNG1POE73QkWTPjzvNJSNuvcIIdOw5tRzBKkVs+xLPOOaFKm0XD/mS4fOMw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700016)(23010399003)(11063799006)(10067099003)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	ukc4V5iWWvD3oEDitPOUcApowXWrjpelPreuhinvzvw/Tx144JsAG0B486Vw74JwbOrzhI3m0AvWdSWxI0BnU94uMkMXg/5hUKffn/1pPFXJvBI05g8PShZQayE7U5UN/e6xHUFBCPd+8Dx4QFN9CH9XGUjhb9SEAFWq1rzG1GflsM8kb9CAZsSvFPrRb0caBj1gMRMJnalgxjQGR5xvMmUE05qHXASVF+FZgrLRz487XDCO3DrxG6d+Ny1cwz2yGHEH8upTLs908DNsnJiqU8Y7GR0p2vzQSFHkW5n8qnw32xk+UbcbLxKFvZQtRe/+gHf++VvYcQcXqhfSFtTdXyz3Kl/9YsTkrrNsHirNKNKRK3Fn4KMLuZaeJe/2C+O4tYZcCLLZxKMqGYSMSdBd1RhBlENiqCmAzsq0RJUvbQMda5rH85jrNVfODMxicd11
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 02:15:51.2124
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d62d85c-85e0-4988-5a79-08def360a32f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000026C9.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7099
X-purgate-ID: tlsNG-c201ff/1785982556-F6EB12A1-C7B14472/0/0
X-purgate-type: clean
X-purgate-size: 1100

Building the xen_set_upcall_vector stub fails with
error: control reaches end of non-void function.

Return -EINVAL, which matches the hypercall's return for a non-HVM
domain.

This is needed to allow disabling CONFIG_XEN_PVHVM.

Fixes: b1c3497e604d ("x86/xen: Add support for HVMOP_set_evtchn_upcall_vector")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
 drivers/xen/events/events_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6ea945508a89..3a5ae96e73cc 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -2245,7 +2245,7 @@ static __init void xen_alloc_callback_vector(void)
 #else
 void xen_setup_callback_vector(void) {}
 static inline void xen_init_setup_upcall_vector(void) {}
-int xen_set_upcall_vector(unsigned int cpu) {}
+int xen_set_upcall_vector(unsigned int cpu) { return -EINVAL; }
 static inline void xen_alloc_callback_vector(void) {}
 #endif /* CONFIG_XEN_PVHVM */
 #endif /* CONFIG_X86 */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 02:16:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 02:16:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384131.1627220 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrneZ-0000Ge-8G; Thu, 06 Aug 2026 02:16:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384131.1627220; Thu, 06 Aug 2026 02:16:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrneZ-0000GU-3B; Thu, 06 Aug 2026 02:16:15 +0000
Received: by outflank-mailman (input) for mailman id 1384131;
 Thu, 06 Aug 2026 02:16:13 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrneX-0000Cx-JJ
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 02:16:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrneX-002APw-0D
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 04:16:13 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee4e-e002-0a2a0a5209dd-0a2a450ae860-14
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:16:12 +0200
Received: from [52.101.85.64]
 (helo=BYAPR05CU005.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a73ee6b-f2d2-0a2a450a0019-346555403318-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:16:12 +0200
Received: from SJ0PR13CA0007.namprd13.prod.outlook.com (2603:10b6:a03:2c0::12)
 by MW4PR12MB6682.namprd12.prod.outlook.com (2603:10b6:303:1e3::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Thu, 6 Aug
 2026 02:16:07 +0000
Received: from SJ1PEPF000026C4.namprd04.prod.outlook.com
 (2603:10b6:a03:2c0:cafe::40) by SJ0PR13CA0007.outlook.office365.com
 (2603:10b6:a03:2c0::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.7 via Frontend Transport; Thu, 6
 Aug 2026 02:16:07 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ1PEPF000026C4.mail.protection.outlook.com (10.167.244.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Thu, 6 Aug 2026 02:16:07 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 21:15:53 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 5 Aug
 2026 21:15:53 -0500
Received: from fedora.mshome.net (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Wed, 5 Aug 2026 21:15:52 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kP+MY6reK9n+KgKtWgmIMQZFyiR3h066PE7t6+Fe2swwZB8ezOIBimzxayv3BIjEk5nUFzFjDh+o86IcqFXggVHnWLPXnnVCGe3oBKq/Iq8Iv3rR33Yba1ALCyvARUf4dAOrdY1x9vxmr6h9xnmcYFU7JKJe881l8Sgrknun7M5bbTX9D5IM/A6gvEzmcYfQgEjxnL/sayyKrFHvBfiqXs2Dla1/sIN0VWQ05IYI6hxf60i/blHF7Gt0zDfrYc1Ieo04y7wd8VTWOCHYJ/LfaDxvJMGVyvlVuTl/Ln4SpCnKNaDYJTh39pcaJJ6bep9tPx92n/o4B09IeO3ec9w9AQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/Xv0fA6/T7b3pIp+x7N+NA8yd+wXonHAePsFkZrVh0g=;
 b=QE2czA3MCUIEEfhUuWXe+4pCXBOaYFWuGcQB17Jdo/cTarpLrleY4VyVuGSj/w03pFWvtW35RJzAKLUnpUNGFxGAfh2wWmHYk4WHCbtnod565l5v4ARTBy40nsqJb6w6/qRHjiEj53a/+6GvfziuZgswHP3ufgHvhtWsWQR3Ob9Z0xD1evA3INFnTTW12Xde03QfxehfXcsqLQIQScHKeUxyph3mniVB14afhNcpfWsF3IVPwpvGGtDaLJ0mmcuwoFWI3YtDP0bvHQyd4zodbZ+D4wfi/T40Fq8obgBgYf5qlDtyTtVMV9DLbQvhTf4+Qv1DP9GAs04bhi/DJZ9l5Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/Xv0fA6/T7b3pIp+x7N+NA8yd+wXonHAePsFkZrVh0g=;
 b=QghUWubbjkvkU7KV6Da/m6iZVyH63MMkbZQ8B08xHsIm5Bb2NTK4ZwvsiDJlP5BYgxyA1PKymM12we2rrNQAxLsIWRrtpPcHp0p5aUSOuermjDarMrdeUAH1RB+rGIkfK9LQinZ7MlF8fCMV2tw7qH7ZHyA2hWZXoe6oUdQCCDM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Jason Andryuk <jason.andryuk@amd.com>
To: Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross
	<jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, "Thomas
 Gleixner" <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov
	<bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Jason Andryuk <jandryuk@gmail.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Jason Andryuk
	<jason.andryuk@amd.com>, <xen-devel@lists.xenproject.org>,
	<linux-kernel@vger.kernel.org>
Subject: [PATCH 2/2] xen/Kconfig: select XEN_PVHVM
Date: Wed, 5 Aug 2026 21:52:31 -0400
Message-ID: <20260806015233.202486-3-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260806015233.202486-1-jason.andryuk@amd.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C4:EE_|MW4PR12MB6682:EE_
X-MS-Office365-Filtering-Correlation-Id: e7772e28-c9bc-4c2f-3f60-08def360acaf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|23010399003|36860700016|82310400026|1800799024|921020|10067099003|5023799004|11063799006|56012099006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	D3wvuUBQx835/K8ljV1ZOJgk+n0ph5OZ7/i5Esc+m4zOOoPoz2+p47cW//cRKeo/1Ylc5HA6tlckc+myPS7BM6cOu831kbSlTbx6EjWHfX0CFbUfw2gLbjtxKexaZKrpKP6RmwY8x1Mm0hxn6VQxdik+Ftv0VSopo/I+5oUTqW/um17UARbCd9tS99SoIVxLgIpefsHikvSpLZy2c2vbX8Eb91Pyon3U/egkg418he5fI+j/yTblvcf+MDA16vurBXEEkU6wd60jiCgBa1Xve5aywp7Ol9UnYPJXOR4GlV/dJYbE9nXbIpc8YTZ7KVs7YyXfvU9bG5PgfhPTe08bx1Wk3EsCqMJrZniPQnEmPT4PZz9qWkAigZ4AIkdfbuVYFtAe/MjZzZygXGxl6kJMA1nzdMf7OBP1ktMD3CCv/cVoMD/B5IfAAAFtJbp1HAlMm7YDqrB8KAcnkTcyq+LEWVqcL0KbMdqg6kyTECwzrhJ0tni4SoBsR7eRu9NQUaOPyrjOgymtc5zIEC10r/5NJUClAybb1EnwDIPBY+AJe8Ni3o5WgyEGiTMzgYHeDU6EUp3IbPntnpjp9A39q9l9obMB05EQ/x5KalkF21+3oPJetEWC5jsjHfRvjNxPIxf+r+ZEh+ASKyeQsLAFEMdYIsWvsTFoqkMR8j58+Ni/fGvo+VhdsBOZjn6uaX1sfPQiFcxrITk8zpZ2NeTbo/eQnDluDqZdXQ7k2YAp910IBOM5thxOPUrIJLjDOi+fDhVe
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(36860700016)(82310400026)(1800799024)(921020)(10067099003)(5023799004)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	zdoew5idMZ/uCpHJb08mf+fDQOsptiovS67Kpj5VeFBDnq4MZZPhWbKlSq/lxHM0vTjtej5OIE19nZDywcEd/SyfRLsOuLxcCdiNBJcTqFGMhdByvqxFrWjBuhk3QJoc1FhrXVSHvdVRAug2qGUmD5ou1hM8SIHg9e8oI3w/n9mAIzD2CjSmzQcA1oYd92xlagpRuoHfI2g8ipAlnOjT80PIpgNtdi/bF92CJn6D5gAViLO7bWwlOjIdeL1xP6hvJGgkmMW5xyKp0EPmzLVDRNsHf4KyumwklL+qqVPL1zWU5Qn5aqBa6aPiGavKK5SOajwSsO9ITbEuOr3LCHhWdMbqXQhcCUczIFM0e9PjgsE+cLK1FXLaT9gW1URcvpkHZkgQiouwwwTXjAMiXFyF7KJCdeHCb5pYDraV6oiirJ7ZJrKZcAkM0eQB2dx7/zdz
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 02:16:07.1414
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e7772e28-c9bc-4c2f-3f60-08def360acaf
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000026C4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6682
X-purgate-ID: tlsNG-4011c0/1785982572-4AEDACFC-8E30C4D5/0/0
X-purgate-type: clean
X-purgate-size: 1241

XEN_PVHVM cannot be disabled as it is a hidden variable with def_bool y.
Switch XEN_PVHVM to a plain bool, and make XEN_PVH and XEN_PVHVM_GUEST
select it.  It will be pulled in as needed, and drop the code from
PV-only builds.

Fixes: 34aff14580d1 ("xen: Remove Xen PVH/PVHVM dependency on PCI")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
 arch/x86/xen/Kconfig | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 99b06f5c47cd..7bdaa28ff232 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -51,7 +51,7 @@ config XEN_PV_DOM0
 	depends on XEN_PV && XEN_DOM0
 
 config XEN_PVHVM
-	def_bool y
+	bool
 	depends on XEN && X86_LOCAL_APIC
 
 config XEN_PVHVM_SMP
@@ -61,13 +61,15 @@ config XEN_PVHVM_SMP
 config XEN_PVHVM_GUEST
 	bool "Xen PVHVM guest support"
 	default y
-	depends on XEN_PVHVM && PCI
+	depends on XEN && PCI
+	select XEN_PVHVM
 	help
 	  Support running as a Xen PVHVM guest.
 
 config XEN_PVH
 	bool "Xen PVH guest support"
-	depends on XEN && XEN_PVHVM && ACPI
+	depends on XEN && ACPI
+	select XEN_PVHVM
 	select PVH
 	help
 	  Support for running as a Xen PVH guest.
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 05:12:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 05:12:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384160.1627227 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrqP8-0004CW-7W; Thu, 06 Aug 2026 05:12:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384160.1627227; Thu, 06 Aug 2026 05:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrqP8-0004CP-4t; Thu, 06 Aug 2026 05:12:30 +0000
Received: by outflank-mailman (input) for mailman id 1384160;
 Thu, 06 Aug 2026 03:17:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <chunjie.zhu@citrix.com>) id 1wroc3-0005Wp-Gj
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 03:17:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wroc2-006J3Y-Gc
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 05:17:42 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <chunjie.zhu@citrix.com>)
 id 6a73fcb9-bab6-0a2a0a5309dd-0a2a4508b712-12
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 05:17:42 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <chunjie.zhu@citrix.com>)
 id 6a73fcd5-f659-0a2a45080019-a06583088c6e-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 05:17:42 +0200
Received: from eddie6.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id EE706448DDE0;
 Wed,  5 Aug 2026 23:16:02 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Chunjie Zhu <chunjie.zhu@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jason Andryuk <jason.andryuk@amd.com>,
	Teddy Astie <teddy.astie@vates.tech>
Cc: Chunjie Zhu <chunjie.zhu@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH] x86/svm: mandatory update VMCB nextrip for soft interrupts
Date: Thu,  6 Aug 2026 03:17:24 +0000
Message-ID: <20260806031732.10242-1-chunjie.zhu@citrix.com>
X-Mailer: git-send-email 2.52.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785986262-DFAD487B-04C0ABD2/0/0
X-purgate-type: clean
X-purgate-size: 1068

Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
---
 xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index b06124c2c9ed..815713b8b506 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -449,7 +449,14 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
     n2vmcb->virt_ext.bytes =
         n1vmcb->virt_ext.bytes | ns_vmcb->virt_ext.bytes;
 
-    /* NextRIP - only evaluated on #VMEXIT. */
+    /* next_rip is consumed on VMRUN as the return address pushed on the
+     * stack·for·injected·soft·exceptions/interrupts. This assignment
+     * statement must be enforced, otherwise, it might cause vcpu wedge.
+     *
+     * APM Vol.2 Event Injection does not specifies what happens if NEXTRIP
+     * holds an invalid/garbage value.
+     */
+    n2vmcb->nextrip = ns_vmcb->nextrip;
 
     /*
      * VMCB Save State Area
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 06:14:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 06:14:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384219.1627237 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrrMs-0001GA-Gs; Thu, 06 Aug 2026 06:14:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384219.1627237; Thu, 06 Aug 2026 06:14:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrrMs-0001G3-Du; Thu, 06 Aug 2026 06:14:14 +0000
Received: by outflank-mailman (input) for mailman id 1384219;
 Thu, 06 Aug 2026 06:14:13 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrrMr-0001Fx-AV
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 06:14:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrrMq-005t37-3W
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:14:12 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a74262b-e002-0a2a0a5209dd-0a2a450890fe-24
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:14:11 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a742633-f659-0a2a45080019-d155802bb831-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:14:11 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so20017235e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 23:14:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47ff79a7302sm3526880f8f.1.2026.08.05.23.14.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 23:14:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785996851; x=1786601651; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=q3NsvjRiIBbs/lup0KuOeVPgWmqzORz6pTEhOcQJm1U=;
        b=G3Wz+skJIpa2GoqTT/D6h5xTGwjn65+Q0WakCCHDw0aPeeIki2FnB80Ifd/qIUoE6S
         t3q4vS1zPtZMFshQNhi1U64N4oJcG65zW/hjcZV1UMx2gXygZzvsW/Nhq7qruJEMZm/3
         BpUMn9NYLqB/GSTzBmomYCdYMFKISYbv8dLpA4iIj/T/eDkvCJVGbKCAKAi0aG/eXXNy
         jKM4yC3YmJeGnw55H4W81XwJd6XUC36CBtNQTnLdzBM5cQIr+DUtNVRvrSlYaVtT+vFy
         I4IFuDgkjbc/HJ8wPanwyFDZFGBIV+ooHfrGm3kHk137sNnREr4m8weCN4PM8Hx8Rwck
         CwcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785996851; x=1786601651;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=q3NsvjRiIBbs/lup0KuOeVPgWmqzORz6pTEhOcQJm1U=;
        b=Y/XZ3Cc36NG6Qrdh7V2VQfjQ9+87l393oQbPqZiBzT5oFSYrgxpt8X6OLoJCi7UE9s
         iyXt005NVHxJOvHR08QFjkB4hi3Z8C9KZHzMfZ3R65Qsnk2KcBxsNXsCrt+NrVDfGKzS
         vxnzUCx3F76wMlfWSWWds/y+jqJVYgzaeSGXDCcAMLinaJB40EvAqwggBvuimexHw2yz
         0oDiIcPVgbruAxyZo/QmXSowAWoAh3u5KpoBAz0sAnW/pRFB+CRSYFB+KoBUaf0R3VgC
         XWMwBWnO1SlM1kstMStOM1EctlL/oroAq3Ey+/67C8rLX36wtwfIBNizw56gD4ue2AYB
         n/Fg==
X-Gm-Message-State: AOJu0YzL5B0LQFHT+OQ59BzsqWIUMFdCmsoSPYni05utBIvLVkxH8931
	uSSPiGyTrGnsr4vMX0ccaGjvGwfnD18suHqBjWlIl5ttBISNpZ2qo8Jeh8CWI1OsHQ==
X-Gm-Gg: AR+sD136Jcq8MC+hNYGgGfh9f6YiSqV+xfXm4pDQDQ4zTEEdi/t26RpQlUC/uuBnDEs
	IRfgfQxCrX3hEyFR/HtcQEAmblELY9ED+NgX2AuM/Un/O2C6ez1RDFtxiCARNzJqP8lHaSB2u9D
	6ppluiGOfSr3NCuiIIy9bjhkOMWc5w8aGa3uOcpR3Sj2f9f0X4g11fBYj3/kQON0k/PHv7kCfRY
	ciazOVB4aWtDf8sQLnbRewuDvDUU9V7JPutsUuBDE8nyIcj7xGiPrufLSvAmyOz/cDXeaqC2YaV
	CXkmcgL9LB0yqoqrF+1sHbbCb7QHhGgvm2wBRR572ypRZQxPZa0uU85vU0h8IPrQRMkLpcpEZd+
	tXlDgXsvzMKEKxWJH5ynj5MYKDjf6/J7EoV2jdtB9nU70ICVM8g8lHBagEyIXI9YBuYuR+43Ksp
	B+WbKRQ2QU1MnuKrJ1KwJRxE3d99f6G3hmMdZ+713Edq2MpmdtXvXJR2qGkQntLCiDH8lkiP2c1
	8zCpLE3ArRZmVq10xx1ve+kDeAT5KQJBh9NPR1MKlqqTFjAOJxA
X-Received: by 2002:a05:600c:8b75:b0:495:4fd4:619b with SMTP id 5b1f17b1804b1-4994e70a6eamr191952195e9.1.1785996851313;
        Wed, 05 Aug 2026 23:14:11 -0700 (PDT)
Message-ID: <27d57a69-360d-4247-a5c2-0fa2c3482b13@suse.com>
Date: Thu, 6 Aug 2026 08:14:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/svm: mandatory update VMCB nextrip for soft
 interrupts
To: Chunjie Zhu <chunjie.zhu@citrix.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Jason Andryuk <jason.andryuk@amd.com>,
 Teddy Astie <teddy.astie@vates.tech>
References: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1785996851-CC77387B-61A32AC0/0/0
X-purgate-type: clean
X-purgate-size: 1367

On 06.08.2026 05:17, Chunjie Zhu wrote:
> Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
> ---
>  xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)

Several (formal) issues: First, please adhere to patch submission guidelines:
To: the list, with maintainers Cc:-ed.

> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -449,7 +449,14 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
>      n2vmcb->virt_ext.bytes =
>          n1vmcb->virt_ext.bytes | ns_vmcb->virt_ext.bytes;
>  
> -    /* NextRIP - only evaluated on #VMEXIT. */
> +    /* next_rip is consumed on VMRUN as the return address pushed on the
> +     * stack·for·injected·soft·exceptions/interrupts. This assignment
> +     * statement must be enforced, otherwise, it might cause vcpu wedge.
> +     *
> +     * APM Vol.2 Event Injection does not specifies what happens if NEXTRIP
> +     * holds an invalid/garbage value.
> +     */
> +    n2vmcb->nextrip = ns_vmcb->nextrip;

Then, much of the comment looks like it wants to be the patch description
instead. Any remaining comment here then wants to follow style as set forth
by ./CODING_STYLE. And finally the unusual not-exactly-space characters
('·') likely aren't justified to use here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 06:20:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 06:20:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384227.1627246 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrrSj-0003fk-1W; Thu, 06 Aug 2026 06:20:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384227.1627246; Thu, 06 Aug 2026 06:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrrSi-0003fd-Uu; Thu, 06 Aug 2026 06:20:16 +0000
Received: by outflank-mailman (input) for mailman id 1384227;
 Thu, 06 Aug 2026 06:20:16 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrrSi-0003fX-6O
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 06:20:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrrSh-005tz5-FX
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:20:15 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a742799-bab6-0a2a0a5309dd-0a2a450bcf9c-24
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:20:15 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a74279f-b7e8-0a2a450b0019-d1558034dc48-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:20:15 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4954afac04bso19210135e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 23:20:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499542241c4sm34174345e9.11.2026.08.05.23.20.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 23:20:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785997215; x=1786602015; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=aAuvnCD1uphQa04NcpaDiUaJGfs6oUj2xypwAwI1W/U=;
        b=I1Ph6eM/eflyoE1aHXqNYUHcR5iIod4dWqnCgDPjB9O+RjB2ua6LzmHe5NLebxj/gz
         5UKQQx9JtSkZHW8VrctFuh1g9aSjf64ClvxXihNQbhU9CXhVli7plCCmRqJE7qysKGIy
         FznPAPhnMqSZeEzHFvYcR2T8BYvxlNfCvRAQRLXVGcOZpJKp/uDpTqlMQ3UW0//s46Jv
         XwPD/tPWyISPne+/nI+W1JUYP6SNIA5YtdUbzkQJGakr7SGqmqzZ1j1cqWtD4jmzFh2R
         yRzQC21C+d3K332mVcrMqcXcZtkawYo2i0q4oBFZg+e9GIQh7uocBc10TkgePecWYzc8
         EoBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785997215; x=1786602015;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=aAuvnCD1uphQa04NcpaDiUaJGfs6oUj2xypwAwI1W/U=;
        b=mKHxcnVaWrTb5eZdn3OusZ2Ny8uZsFPhaela7NqmSwNg/PYdAP7RaR8NmTuq9WH31r
         Y/yEnx6HWBb4cxQXf/EV17mgar47X90hjrODXG2mqMaqz4i2Sk3Z9UON60/AN5DWJTKy
         aTes6av6fiU83ycrLaiQLVasVpeKrVOSRkFK1p0rEKVZ8+mjOBRVmffxHvsE3/lRhbGy
         NF4PjuS73Wnb3g9ka7HBSg7js49tG0bl60EmsIt6sx8oyMxLBTGweHe8mVlFl1Jtyc18
         J0eOcOtI4MWjLpkIm3KyAcOiLY4lgY0xK9htfSy1VJBFa9YZsaLkK4u42sGZXONMlyj2
         vXTA==
X-Forwarded-Encrypted: i=1; AHgh+Rpti235/SPfveZpjzhE9SrGFiYiRZJRVdRQqcGjyEPhcwhvFTVUtNIidL18s9K2ByESvtvwuPpNL+Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/r8z05yVyYHrCUdLUg6SLGl8HG2b8hvPsISXrDPE2Zs8BL6A7
	b/0h8M4BFSBqGsc5UZ6k0/w90zNLTYBDoKcA4eJQ4dl4VJuYDGFuNxScxwsIY19vYw==
X-Gm-Gg: AR+sD10phROJdTqYNFevz/H9ChSDGMefSgtQwFz/GqpnT4qHLDkyjEWta8K33RWtN2F
	vZ1/X+YSsfo8hasN8zGaHezfiCSy2Sif7/eVzpF6WViFWE0eGQ2CjHxyzLuc5eb/oATquKSzunP
	4oljWRvgSnEp1EYgu9VKd3qiiu0s+gIhohzRvar26Df0X8mM4bJM2c10SCq4S8zz6unfj/uFzd2
	nn51/P3hIWmfFL17rkMklFJG/+ovqWVU8rHp/T7DeTDqWCAwegeScyc0JtqLfnJML+Zh18qYHHZ
	YENH9e0mOwgfqqGqA0uozFbRYGErDQMvXi9tLkbHn//zdu3Z2i9veI+mbw2b+nXRrIYcKcb2c1P
	Gcw+LtDInuIv76xRMv5jKYU1/ssYFfkHSBJ8sNrTe5XKuW2VAGKmZ4Tsop4TPsypirZlWt5aWB5
	V3DCwTNgZ7eBq3UEzIru6XiTMisPnGrvnmxCAEKdWZU9w+ekx/DpaEH39rKcdeNfWZ8DrXTjm25
	iBnOY9dKZEBKpf4vOooj6nEiAfBqCIKXjg6v9hjOIyD9qoUfdje
X-Received: by 2002:a05:600c:35c4:b0:499:4dca:aa4 with SMTP id 5b1f17b1804b1-4994e70ed73mr161340535e9.4.1785997214876;
        Wed, 05 Aug 2026 23:20:14 -0700 (PDT)
Message-ID: <d44f3abc-8b64-4542-bb10-936626c418a2@suse.com>
Date: Thu, 6 Aug 2026 08:20:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen/Kconfig: select XEN_PVHVM
To: Jason Andryuk <jason.andryuk@amd.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
 Jason Andryuk <jandryuk@gmail.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <20260806015233.202486-3-jason.andryuk@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260806015233.202486-3-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1785997215-1A0C59EA-8F1AA1F4/0/0
X-purgate-type: clean
X-purgate-size: 1161

On 06.08.2026 03:52, Jason Andryuk wrote:
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -51,7 +51,7 @@ config XEN_PV_DOM0
>  	depends on XEN_PV && XEN_DOM0
>  
>  config XEN_PVHVM
> -	def_bool y
> +	bool
>  	depends on XEN && X86_LOCAL_APIC

Imo "depends on" on prompt-less, default-off options are at best unhelpful
in the common case. (Aiui it can be helpful when "imply" is used instead of
"select".) Hence I think this dependency wants dropping right in this patch,
justified further by ...

> @@ -61,13 +61,15 @@ config XEN_PVHVM_SMP
>  config XEN_PVHVM_GUEST
>  	bool "Xen PVHVM guest support"
>  	default y
> -	depends on XEN_PVHVM && PCI
> +	depends on XEN && PCI
> +	select XEN_PVHVM
>  	help
>  	  Support running as a Xen PVHVM guest.
>  
>  config XEN_PVH
>  	bool "Xen PVH guest support"
> -	depends on XEN && XEN_PVHVM && ACPI
> +	depends on XEN && ACPI
> +	select XEN_PVHVM
>  	select PVH
>  	help
>  	  Support for running as a Xen PVH guest.

... the XEN dependency being in both of the options selecting XEN_PVHVM and,
as per Jürgen's patch, X86_LOCAL_APIC being redundant anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 06:44:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 06:44:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384241.1627255 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrrpo-0000pZ-U4; Thu, 06 Aug 2026 06:44:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384241.1627255; Thu, 06 Aug 2026 06:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrrpo-0000pS-QT; Thu, 06 Aug 2026 06:44:08 +0000
Received: by outflank-mailman (input) for mailman id 1384241;
 Thu, 06 Aug 2026 06:44:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrrpn-0000pM-93
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 06:44:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrrpl-0034mA-V4
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:44:05 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a742d1d-2eae-0a2a0a5409dd-0a2a4509bb38-42
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:44:05 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a742d35-be1a-0a2a45090019-d155dd31ed9b-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:44:05 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47ddf7b09e5so1646017f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 23:44:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47ff79b529fsm4174563f8f.12.2026.08.05.23.44.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 23:44:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785998645; x=1786603445; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=EfQIuo25alYydqJl7CsWTFV1Lp4Og1ZUqJTTMZut3GU=;
        b=gJ1wps/A3muG8mBgg2W9yZWuF8IBc9LS1Mz4NYPCB4CeuuVAHm9TR18VjR/mh2cdpX
         iT+sqXCAt45zr0yRIOWpyR7KbwNKMWquE7I4+bg0dZpkq6osnsCxSD2ffoIGr+RPpqxm
         Lif+mqhXkeML7HGAkRA3klGZ3Nfg1HzYsKBWG9jVK+w4jY1ybykRbR5Hkpq7TjLZZqp8
         WWa9bv5iASBxv1PKcr5RSAaWYv7NvkW1FA1bQy5o1qWpv8NA0+VbOUKjgSAQDCUFGkWC
         YOwvGFP0AyCnMds3xUvnWgc+k5+6JPykgKjQ2EO682p86AIcxbTCfQtrGrRXjiRgGjLM
         f82Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785998645; x=1786603445;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=EfQIuo25alYydqJl7CsWTFV1Lp4Og1ZUqJTTMZut3GU=;
        b=Ie1ti86TZGrglMP3nT+kRuYl78/qBdkn42tZOCOy+j4xkMxHeluFN3NsBBIJveeAvg
         iN+Rn7rPPwvYU760HaHh4y2SHxsR1h8ofGC7fTxoN+DY4WurDTp3y75hbT/gGmSNRz9u
         mMGhdSLNOd+SvsUrp+cbR8Q3U9myusSC9HPwKHqUPEJHC8uBp/GgbC+2oNPH9grtm2LM
         Kq+Oq6Z8ZRKdKQXjO7na0RQy1xXJVPS+KDAieiEmPHcHmE4fgCv9BS7M5JX/l4xmxmvq
         La4OLZwuFc07CRnxzNnARBtVGueTLbF+AfTIexkbxvrE4JA9ki0clTydG79e6hbHGgFZ
         m+Dg==
X-Forwarded-Encrypted: i=1; AHgh+RpdiDEdH3nnSIPMpCYy7mGON2Wt5v1QRRvFi3WHIQniTraH5t/wESUE1TAW2iipZsxdp9RhPAlDnpI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxH6JWiU5wxlS68I1aKnkZ+JigukOZ1mo/Q72XNtVVnS2lPMXRW
	o823srUMcdSPU+lFx3KzWsIxjW/b/bz/YEFA1uqDDWUjtqFoNe06UdbhS3evRDs33w==
X-Gm-Gg: AR+sD13hWvLZcam+bqJ5uEJtQnIdCqRYM3R48RQmZ7bHTb3EmdoSIae+tG2d0x5++eH
	uFe1wuuWy5fw1zLO2hrjM922a8sJxYjiX9C9n2DArRDxnhbc6RkHa22eCOL1KIZcA8X24CcOtES
	wRbJ8Ebx7f8nMxVZjWHh8g+uEnf9r1IRPhOSLug9armU+kUawcbHQPf7xg57xpp7Do6/+7So8gu
	QwB9W6BZyZ+Yv8umkhHHxXmtgBErBtCuj4FFLKSf1zHLOCL4nJlBabL4iLQ7EbQ8AhKZSKVlZWO
	nDGC9st8avQRUkVQtDJhQv4+eLLnEUE7EPJBM8D8Y+lBodOHzdTRaOh8iy3C9c0F7HWUNFQ1R8Y
	oZs9XRgxOMdktNsgIDljkkfznbU5ubrpKwH4zWr5yRaPKUjSNriO/rWZFboZ3JtiwUhS3OpdPep
	Vi0z3EVTm2zkMw1RdO599dPyMJm+w8wA2wUHsizO2zvHvYzdnwtomNvBIs9TKv+GZfSyABE01Yx
	oTPm/++JounCi8uR9C7RURo4ZnRGDDClIDo/ZXl24yrsylYLRtm
X-Received: by 2002:a05:6000:18c:b0:47f:7c50:2222 with SMTP id ffacd0b85a97d-47fec53259emr17005053f8f.24.1785998645277;
        Wed, 05 Aug 2026 23:44:05 -0700 (PDT)
Message-ID: <8c2e2d27-2802-4ba5-9b91-cb6cf8a5fa1a@suse.com>
Date: Thu, 6 Aug 2026 08:44:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/5] x86/nmi: Watchdog fixes/improvement Part 1
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <e1e873d9-6dc0-4e08-90f5-e99ff42802a0@suse.com>
 <49738195-ad6f-4889-984d-b1eeb5372708@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <49738195-ad6f-4889-984d-b1eeb5372708@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1785998645-FC212034-CF05F789/0/0
X-purgate-type: clean
X-purgate-size: 4238

On 05.08.2026 19:56, Andrew Cooper wrote:
> On 05/08/2026 2:42 pm, Jan Beulich wrote:
>> On 05.08.2026 14:45, Andrew Cooper wrote:
>>> This is the start of a very long rabbit hole to address the
>>> mis-classification of some watchdog NMIs as non-watchdog NMIs.  For
>>> now, just some simple and hopefully non-controvertial changes.
>>>
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2733861049
>>>
>>> Andrew Cooper (5):
>>>   x86/nmi: Drop {reserve,release}_lapic_nmi()
>>>   x86/nmi: Drop K7_NMI_EVENT
>>>   x86/nmi: Misc style fixes
>>>   x86/nmi: Check MSR_MISC_ENABLE for all Intel platforms
>>>   x86/nmi: Don't configure EvtSel repeatedly
>>>
>>>  xen/arch/x86/include/asm/apic.h |   2 -
>>>  xen/arch/x86/nmi.c              | 153 ++++++++++----------------------
>>>  2 files changed, 47 insertions(+), 108 deletions(-)
>> This series, once again, is putting me in a difficult position: Should I look
>> at it, or should I let it sit for two years or more, just like my earlier
>> fixes in this area [1], [2] are? (Of course, as always so far, I will look at
>> the patches, and I will likely also accept them going in ahead of mine. But I
>> cannot exclude that at some point I might actually stop doing so, seeing how
>> many of my patches are in that state. While at the same time none of yours
>> are, afaict, i.e. as per the track record that I keep of what still needs
>> responding to.)
>>
>> Yes, you did respond to [1], but is not being comfortable with a change really
>> a reason to block it, when it _is_ an improvement, and when the alternative
>> hasn't materialized in all the time?
>>
>> Jan
>>
>> [1] https://lists.xen.org/archives/html/xen-devel/2024-01/msg01365.html
>> [2] https://lists.xen.org/archives/html/xen-devel/2024-04/msg00194.html
> 
> I'd forgotten about these.
> 
> Patch 1, I'm (still) distinctly uneasy about, but I dispute your claim
> that it is an improvement.  You are adding complexity and not fixing
> anything AFAICT.
> 
> The watchdog counts NMIs (and counts incorrectly; this is the root issue
> I'm needing to fix).  A timeout is declared when a fixed number of NMIs
> (10, in default configuration) pass without the timer softirq having run.
> 
> The rate of NMIs varies with P states, including lower than cpu_khz, and
> differs between cores.  In some but not all hardware, we could switch
> from Unhalted Cycles to Unhalted Reference Cycles, but even that has a
> bit caveat saying that the definition changed in 12th Generation.
> 
> You are making the rate of the timer softirq dynamic, but it is an
> arbitrary fixed rate still unconnected to the rate of NMIs.

And I'm not claiming to address that (independent) issue. What the patch
does fix is a watchdog timeout occurring too early when a CPU runs in
turbo mode for perhaps an extended period of time.

> The only fix is to make it safe for the NMI handler to read real time. 
> Until that time, in a choice between your patch and saying "well don't
> set watchdog_timeout=1 then", I'd firmly favour the latter because at
> least it means there's less to revert when a real fix does come along.

As said in the description, if the ratio between max and normal is high
enough, even the default of 5 could be a problem.

> For patch 2, I had figured that bug out independently though inspection,
> and yes I do agree it's an issue.  I was debating removing
> watchdog_timeout=, and agree with that aspect of the patch.  However,
> watchdog_force needs deleting to fix the incorrect counting, and with
> your /* reset to defaults */ you're breaking the incremental property we
> have of command line parsing elsewhere; specifically "watchdog=force
> watchdog=10s" now sets force to false.
> 
> I will make sure to address this bug in my series, but I think it will
> be a fairly different patch when the other dust has settled.

Okay, we'll see if and when that arrives. With your intent to address
this differently, I don't see a reason then to try and adjust the cmdline
behavior. FTR, with watchdog= in particular I'm rather uncertain whether
the common (but unwritten) "incremental" policy is appropriate.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 06:57:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 06:57:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384249.1627264 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrs2h-00045Z-0h; Thu, 06 Aug 2026 06:57:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384249.1627264; Thu, 06 Aug 2026 06:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrs2g-00045R-Tk; Thu, 06 Aug 2026 06:57:26 +0000
Received: by outflank-mailman (input) for mailman id 1384249;
 Thu, 06 Aug 2026 06:57:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrs2f-00044G-CS
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 06:57:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrs2d-006mfY-Ot
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:57:23 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a74304e-5cb7-0a2a0a5109dd-0a2a4505e1c2-24
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:57:23 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a743052-4cb1-0a2a45050019-d155dd2fdd8e-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 08:57:23 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47f7854678cso1117281f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 05 Aug 2026 23:57:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47ff7b1809csm3173036f8f.18.2026.08.05.23.57.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 05 Aug 2026 23:57:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1785999442; x=1786604242; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=5xl4BRyTVRm2AXv14x5ldoaieV1jo7UO/WRkwMTRXvk=;
        b=WnskGpLCh7TobAX64mgB9lCYOC4IjYZfhTdt7wtFYvfOKxIRKHQzdh36Q0hl78d5wD
         yjoh9+qBSLye9VbZQhlRFw8XmNPQZgTNVp5nQUUjymPNfVHVmYI3JDGw30W67bhtTzyM
         uDYt5lKKfbbo+K7cghwynkUmQyNgpNHSF/O3EmMffRx3Ytr6ujnHjHHcgaECi8c2v5cx
         GgP6/+rI12XZcYA5jqFqDuTvomBDvjDj8dEGxFiQvNIyv+OMZ5lRvGgs8xbnj15G3xfL
         slbGtA0QGVdW+8PK+GRB3I8ROru+i+evKX7UMhbV1GNB09d8sGUo62J+5HkqoEwi19xj
         JrjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1785999442; x=1786604242;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=5xl4BRyTVRm2AXv14x5ldoaieV1jo7UO/WRkwMTRXvk=;
        b=kTr/gwgWsndnG2dRxJuVwSRN53deW/lWe58IkykX84dIrka36tNHaoDXriVVIqW/vv
         MMwwFRIbBsmsn+SV74YO6Q8evMZs4kJ2ogeIqg+EVh1Ms796Khji8o0Jpc9aDYmN667S
         IYtVX+ZPzKzJmdCO6XAGIEz2Rp0xBZzhzFYaTzH8WrGIQFrHsIwzt4OBO7epq0JrVtST
         x99qkHVZ58puPUo+fPB6m4nnRXbHmfN8qwujbMMeQMkDec8eJIDpckZ6wn1/eBvHPgnY
         KqZK/h91Qoe7Iiheoc/8tqFaZbS/R5paCpyM9a9X+wM13TzD4kzFY3oVQmhp651+WnIY
         Gesw==
X-Forwarded-Encrypted: i=1; AHgh+RrzBfbEs5qORfjEx2BrfwpS4d3llfbP0+u97I6t98wCp/lMMOg78lj3u9EFQh0n+av6nEx8OKZQycI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7gatpJFXNDQtzG+iQyY1ejO8dQkwcfmbKgevJwR1cyCkzgqEm
	kpWiv7yCPnmjvpoTGdTyJgxlNt3StmEvZ8AJqjaRSDMy9z96s2ehhDinwz8hGBZFbY893Wt3wfh
	/Vp1jxA==
X-Gm-Gg: AR+sD10rikYar2HuUa8Hp+aOTHei/ZipZFaJCStxz9jk3H7tG8PLcAkQyVIa/xOqNpP
	BIqBV9x4nALSmBcMXqfKrhjOX9G9kIZMYFcYNY/JizpSkKIztGrSz6OWEzdigIjOsBZIAHYAFtE
	tKmu4iH/U4lCz/KDBi5kMPCDN9NWe8vluPpwKyDeuFg0kg8FFj/rx6WxFZvnpqtiEvbgOlj9fj8
	BUirUJ0FwzsRABIbnhopklqK5xJQcdeAssMO9QGcwceOu9h7baxMso1ECtH/5sd4vO4Okf7kZVc
	L0JND2hpqrqwnZoIyYVNiiTRtPLgFDFnUsRXRVzJCPLqCTeAcbolpHUKNefkeRoCq0lV30FKbRP
	aEPfHwdwNs7oyMHQOe0M+yK9/oMcjfQAoCr1SR5iL9YPVboqyw+9q6D++ksFjUqn+ByvnNlT156
	uZskM/tikzEc2CYqjmNLVsTf8StAi6ckntx4n4y423tnr7mKCtj4AM55yw2wy+qWl4Rp4GmZFZL
	Cd6KsI2q8C2TkhVA7hQhIRThjmIxFZuddfnaD4ZJpjnY7fjnm+92eZYrKCywwQ=
X-Received: by 2002:a5d:62c5:0:b0:47f:8fb6:c32f with SMTP id ffacd0b85a97d-47fec52a71cmr15377387f8f.24.1785999442600;
        Wed, 05 Aug 2026 23:57:22 -0700 (PDT)
Message-ID: <0b38417e-2c59-4df1-8429-ec7c98ce22d6@suse.com>
Date: Thu, 6 Aug 2026 08:57:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] x86/nmi: Don't configure EvtSel repeatedly
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-6-andrew.cooper3@citrix.com>
 <d76fa0a2-1a53-4ee4-b077-d51715dba339@suse.com>
 <da3b4ee8-7c12-4fec-8d31-6f2f66bba4a8@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <da3b4ee8-7c12-4fec-8d31-6f2f66bba4a8@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1785999443-24F1F2A1-F266D2C3/0/0
X-purgate-type: clean
X-purgate-size: 1155

On 05.08.2026 17:37, Andrew Cooper wrote:
> On 05/08/2026 3:20 pm, Jan Beulich wrote:
>> On 05.08.2026 14:45, Andrew Cooper wrote:
>>> In both setup_{k7,p6}_watchdog(), EvtSel0 is first zeroed, then written with
>>> everything but the enable bit, then written with the enable bit.
>>>
>>> setup_p4_watchdog() is slightly more complicated, owing to what
>>> appears to be a bug introduced by commit 2a2bd8de16b6 ("Clean up NMI
>>> watchdog handler."), which causes a second bit to be temporarily
>>> different too.
>>>
>>> The middle of the three writes is useless in all cases.  Drop it.
>> Spotting the 1st write in setup_p4_watchdog() wasn't quite as easy, as
>> MSR_P4_BPU_CCCR0 (as passed to clear_msr_range()) has nothing to do with
>> MSR_P4_IQ_CCCR0. Using unrelated MSR names there is as unhelpful as using
>> raw hex numbers.
> 
> Perf counters on the P4 are utterly insane, but our local logic really
> doesn't help matters.
> 
> Another option would be to remove P4 watchdog support, in the basis that
> we really can't test it.

Well, my Tulsa system is still alive, and the watchdog looks to be working
there.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 07:17:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 07:17:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384262.1627276 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrsLN-0000s1-Gt; Thu, 06 Aug 2026 07:16:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384262.1627276; Thu, 06 Aug 2026 07:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrsLN-0000rt-Di; Thu, 06 Aug 2026 07:16:45 +0000
Received: by outflank-mailman (input) for mailman id 1384262;
 Thu, 06 Aug 2026 07:16:43 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrsLL-0000rn-Qc
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 07:16:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrsLK-009R4U-L3
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 09:16:42 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7434c9-bab6-0a2a0a5309dd-0a2a4509b588-44
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 09:16:42 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7434da-be1a-0a2a45090019-d155dd2cddf0-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 09:16:42 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f7854678cso1130104f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:16:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49954228a47sm58644065e9.12.2026.08.06.00.16.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 00:16:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786000602; x=1786605402; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=afWRBDy6f/MYpbm8V8ND9nRxMaDsHk8GOgxRDVlc6g8=;
        b=IOHVQhLPbH/ZeFyOs8PNb/I516WzGBk97S+5dTFX28ODBWhONY1yWOYK6GUAw7251p
         pAMg05VTNT1CVO8OBOIHYzINXLCtuDvnmJNnLYW5OgFOsdSLIz7l9WBXLzkYoagkWB5Z
         FH+aGK0RJ+e4XPdyT2YXdZc4ypb0E0jr//d+vDsOE9slKpxRmfKoSNkMiCbXtmZt+yrI
         b2nVhMxK0FSHVt04PpeRuo7uGk5iy9H8qVcd8vEnsW7DbXn0KFMtVovmUhLV2gMkmPIF
         yqZwcnNm9QKSi1YUy7oxi1itncN+/ptPiJcjSgbtzcwBoS17nvCaySC3Ddr7dgyqnpPX
         OAtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786000602; x=1786605402;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=afWRBDy6f/MYpbm8V8ND9nRxMaDsHk8GOgxRDVlc6g8=;
        b=D7pNpfL+E8cJsNuUjTJJSmSHbJ02VmCCzzH4nJrVpOzjg1aVGXo6kE24GMXFhD/Nn8
         8cF2sl23H7qPJJ3Yu3qUqGzuQq4/CY8Kxe4/FhLbL4g3ppocBY6Vh/hkTFa2ZEipw6ny
         sv3Vu358TRm34gYfHvpEIcZwp0MYcdZ9vurbaO14RN3CmwBKQYgKLC31ikh0qjYM0/OG
         zfdP+RcJZcOUpyqCsQeh49eszEShjO5oKwpSY6iAnNEjOCotSmM+RgJnNqwhWty26tKo
         svzv3XOwpe4O2CjnwBVFhCKVBYJFBDcPTV7LTREgbE4yPHbnEBOCm0/Zo/jKe9EroP4R
         2frA==
X-Forwarded-Encrypted: i=1; AHgh+RqmQ42yFp6s6Flo5sXzobxOV18yXG7I4c9Yttvqae+8YyFlLiVN0n22x4RTN3HeiqxZUPBWHbp7YhM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwFT/x4QB7KdqCQDmnK2XyWMZ9JMuHLYKqwNoUnbjJs1Jx8T98R
	SqvYXHU3qQVRA0Ocdk0Jx1z88W1STBSUwgoGfkWbndq0+Wh5WOBIeBfSpwJAllT5XR1WaAKcoHr
	EOh/NZw==
X-Gm-Gg: AR+sD112NOjNHdOu7Mexm3U1+vNEUs3v3VDVBBATDEAmddSPAAJaN1hOcESsNy9reCV
	1tgXK8bmHXSv1J5UegqDNO3ist8Dj/ssiavaIAw3qrlZWp0fCpI+UhzVxPIt/iTmjzAWyB1wM0a
	2O3hOn9UBYlJoYkUD9WCIfp2e5DgraLuBi0OHh/GrOSgSD4l63Nduv1mu0cugn4ZGCdkvH7LiwB
	kVvaJqehmwBMjMs4rzINNdcc4YCQu1mVEDPJfunkS/fJQgP7vMkMwoUm5mmzsh1DP6R31Mof4WH
	LbVKQj1hMNIFYDYMzsQ8XpnxRkO0PQvcvIYNEFDHOvXeu3iB+S4PmKf72S0XRweXoaWTd3IGC+p
	IaH5d9uldclscEnsa0v09Rxp4VY0oJaBc5aqOSK7UPoY0VavicgfSN+aFK5EgfRmlgJhQInxKZn
	g4hWcxuIblhiXLl7fvn4T+dAAGKvlSqKkLLEjVQr2vknUdvsdCCFmPR8Q9QxxI0ytA3ej4xH/Fm
	cfhymPoXlowiBpDClhRddaF05zZ+8QsRZdkM08geQGbilOCDzCM97R/WKIIT6w=
X-Received: by 2002:a05:600d:8489:10b0:495:4749:16a7 with SMTP id 5b1f17b1804b1-4994e7c5e9bmr143037545e9.14.1786000601911;
        Thu, 06 Aug 2026 00:16:41 -0700 (PDT)
Message-ID: <7762513c-0d3a-465a-abd9-73e3ba586556@suse.com>
Date: Thu, 6 Aug 2026 09:16:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Jason Andryuk <jason.andryuk@amd.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <6991badc-dcc4-44b9-a048-29eb67c46d2e@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <6991badc-dcc4-44b9-a048-29eb67c46d2e@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786000602-BD2CC034-198D6D2D/0/0
X-purgate-type: clean
X-purgate-size: 1053

On 06.08.2026 01:02, Daniel P. Smith wrote:
> On 7/28/26 9:22 AM, Jan Beulich wrote:
>> @@ -2307,7 +2308,7 @@ argo_init(struct domain *d)
>>   {
>>       struct argo_domain *argo;
>>   
>> -    if ( !opt_argo || xsm_argo_enable(d) )
>> +    if ( !opt_argo || xsm_argo_enable(XSM_HOOK, d) )
> 
> This question came up on another thread, so thought I might point it out 
> that when FLASK is in use this can return a nubmer of error codes beyond 
> an access deny. While I know it's the existing behavior, but if the 
> error code is anything other than -EPERM, then it's not that the policy 
> denied the access but something cause a fault in the security server. In 
> that case the domain is still being allowed to construct with the 
> assumption that it was a policy deny. At a minimum should the error code 
> at least get reported, and perhaps it should be passed up to domain 
> construction to allowing it to make an informed decision on construction?

Sounds plausible, but definitely wants doing in a separate patch.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 07:23:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 07:23:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384272.1627285 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrsRS-0003Uh-48; Thu, 06 Aug 2026 07:23:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384272.1627285; Thu, 06 Aug 2026 07:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrsRS-0003Ua-1S; Thu, 06 Aug 2026 07:23:02 +0000
Received: by outflank-mailman (input) for mailman id 1384272;
 Thu, 06 Aug 2026 07:23:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrsRR-0003UU-6P
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 07:23:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrsRQ-003CiB-Fs
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 09:23:00 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a74364f-5cb7-0a2a0a5109dd-0a2a450be154-10
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 09:23:00 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a743654-b7e8-0a2a450b0019-d1558030ad3c-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 09:23:00 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49558ce01afso12892895e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:23:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995421b1e2sm48667145e9.8.2026.08.06.00.22.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 00:22:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786000980; x=1786605780; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ckcvMovW0LtLyQPM832KezdfHJgVxcVYWAXZjbEPPA0=;
        b=Jspyi1LwmoRHKL3zEurc8Dyv0ohM3Ariqo2FkRhpPJNepLuU4Eedy94ewrJcxeAnOe
         5vuT/UFBA/Bk874BNB3MwMLFxpyqsvNuKjsKjm7wuueKWIn4NjC/5Jt40hNTA9U8Jzdd
         eQwyMZEOvkck6KqgN7vE4yFztQNl/sYi2DJAc7+FkHPNhSsLV4fvnsDPjGeK4sz5bSou
         KPETM99CeYqHcFClqsGAwLenjnTZho8n/Cp9vUNYhzyKs8U+8tfJ3EH0ycnweaBZD+kT
         m3ZTrL68AmIt5EYl0BKb4zOnDLj2O6MMpjTarFDSX3GLoe69wHLHakp8p8tqXbRjS/ix
         oO6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786000980; x=1786605780;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ckcvMovW0LtLyQPM832KezdfHJgVxcVYWAXZjbEPPA0=;
        b=sPGFb2QqykmUgmW2WAEahINmmSdeR7Hfqj2jSru0/+/RSbJLn4s9oxVwtIajv89ZVN
         5mJZcNXMNsS4m+tDs9q0bQoAGhAuzqDpkNghcRz2JQxttJ8brrI0p3UxzHZlUuO6Dw4G
         6x6OjfR7YTy4KADX8GRjOBvzoCc1fNyeojHuJYq3TTXcfRJDBh2rYRZnNU/UtJa1Gl4U
         i5eb1ui08EPUtEk0WOALIhMHje9c9l81BOABuHvtEvZwgdJeM0rvbFx1AcCi0kPIbd3X
         7h8rmoiVQY91TIfzgSoMd6w+kUx1JpoDl36oZHWUdZzkiqbV4/7fj09l3yxvjdILuMdb
         yQnA==
X-Gm-Message-State: AOJu0YwkLtT0zLEUd8nA8INyAP/cXOxO06kB9+oK90FedZY/vtLSum+1
	ZF/BC/yemwZcMNlAqhaZrUpRxNr3QDOxmskWzBD0Sx3RP+PyRCU0CDzIdz988bdbEn6RWLLjh4u
	mtS9K7A==
X-Gm-Gg: AR+sD13mfRBaC/FeWVivKELSCl4n264IcYLj/2gx797yg9v4d89whdB/1Qy9pwCuwLx
	zwihPteap9c0eubv90YhFmyu0EZ74F7bidCqN3asR51afQKYFdyT2Y6CzYU6KfiJQIM9j3YZz2j
	hhdE/VipGBQ3jndruAbdngExDE4VdOeZ0ij6710z42AvzxEqvxLwvBuIUkxWpY3I+XOJvrJZb53
	+BD45SJ+OC01s43YBkdjt2jLwcpvynJbx0/GJyvA2TuzkRC2GEdirTY77korG8KjrmIehUL6R3e
	xvz4uz/QjKLzUCxcsMdrd+AFyeJDPc5nqpaikjAXQcDGGP5lJafZG4tYTOow5//koxwPrVYo1w9
	uf+XwC8YB7/x7woEVbtY6okq85yTbPMRC927pFpxkfxB+kGs/yhh4kzbd5TEUP1fl7LdTRkGM0s
	vMC4hiSnXM0a/J4OmtrpuWJhNaWazbKL1XSLB3iJvTSh9xDnqDdiGOfbdsdQtD9qr2MHBFFgmvJ
	QGuWczWZU9zKCY8tCvODsSI2eeAfU72s/QO8wgPkw76mnpx3dFeUMIT6mPcMGs=
X-Received: by 2002:a05:600c:c043:b0:495:7a5a:d96c with SMTP id 5b1f17b1804b1-4994e7d89cfmr131608205e9.18.1786000979800;
        Thu, 06 Aug 2026 00:22:59 -0700 (PDT)
Message-ID: <d2207507-d15a-4e3b-a057-77bea7621efa@suse.com>
Date: Thu, 6 Aug 2026 09:22:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 18/24] XSM: make XSM hooks well-formed ones
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <2c108d3c-eef1-4d4b-9874-b0721fd7560f@suse.com>
 <fc08fe79-cdb5-4ee3-9efc-78b02d00db15@apertussolutions.com>
Content-Language: en-US
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fc08fe79-cdb5-4ee3-9efc-78b02d00db15@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786000980-AACDF9EA-89DFB1E8/0/0
X-purgate-type: clean
X-purgate-size: 2406

On 06.08.2026 02:53, Daniel P. Smith wrote:
> On 7/28/26 9:22 AM, Jan Beulich wrote:
>> For whatever reason they didn't have an xsm_default_t first argument (to
>> cope with XSM=n mode), making it impossible to (easily) cover them in
>> xsm/hooks.h.
>>
>> flask_do_xsm_op() is also changed to return int, as all the function ever
>> returns is an int. This way no new machinery needs adding to xsm/hooks.h.
>> Instead one piece of compat machinery can then be dropped from
>> xsm/flask/flask_op.c.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Instead of XSM_HOOK, using XSM_OTHER may also be a sensible option here.
> 
> I would say XSM_HOOK is sufficient since at this point it doesn't matter 
> what op is passed the dummy policy is just going to return the same 
> value. If the dummy policy is extended to support an op, then at that 
> point the implementer can switch it to XSM_OTHER.

Good.

>> Question is whether some/all of the other hooks still declared explicitly
>> in struct xsm_ops should follow suit.
> 
> I would say either comment these are exceptions or make them consistent, 
> though I haven't studied if there would be any consequences (doubtful) 
> changing the others.

As I've now added patches to convert the remaining hooks, this remark is
gone anyway. Hence comments there aren't going to be needed (unless those
extra patches would be rejected, once posted).

>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -439,7 +439,7 @@ static XSM_INLINE int xsm_hypfs_op(XSM_D
>>   
>>   #ifdef CONFIG_XSM
>>   
>> -static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>> +static XSM_INLINE int xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
> 
> With this change, should there be a comment that the int is going to get 
> cast to long before return?

Not in my opinion, but if you strictly think such is needed, I can certainly
add a comment.

> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Thanks, including (again) for all the others. Nevertheless a request here:
Especially when an ack is the only part of a reply, could you please trim
reply context much like (most) others do? Without that, every reader has to
scroll through the entire reply context, just to find the single line at
the bottom. That can be a lot of scrolling with larger patches.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 07:37:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 07:37:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384286.1627294 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrsf0-0006bx-BB; Thu, 06 Aug 2026 07:37:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384286.1627294; Thu, 06 Aug 2026 07:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrsf0-0006bq-8Y; Thu, 06 Aug 2026 07:37:02 +0000
Received: by outflank-mailman (input) for mailman id 1384286;
 Thu, 06 Aug 2026 07:37:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrsez-0006bk-8e
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 07:37:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrsey-00EejD-LT
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 09:37:00 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a743997-e002-0a2a0a5209dd-0a2a45079c08-10
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 09:37:00 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a74399c-b4ea-0a2a45070019-d1558036f1ef-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 09:37:00 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so14946355e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 00:37:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499542135cesm42363935e9.4.2026.08.06.00.36.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 00:36:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786001820; x=1786606620; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ViL4VHVHnGZCDBTWYy/BbLFUaSoqso542Mz4ZuHRR0k=;
        b=KIuLmYYbHUfxRC/XsvUjm/KXzPIi4iHsP3Cr4muM2r6JdqGhVUuwfGuUF7QFGxbRTN
         NzlMaNHlHoOmeXYyZLZXdiPuIAEXgQsUwuRo4VmAsozwzniSkCP7S/1ur8H/Y8Zyv4lj
         ziaI+RDRYg4doUGW43qcOIIdh5rrsUbwKGgCxym8BngX78CV/UyGtyZNPQ9rdOW+Gmk/
         Yf0Y9oT0mBB3kvFclG8VQrSjiEe/gYXxjKGdd71U3fqJV/D+4Vb7ow5CWEGX/LkgfRs6
         aJj4caaZbqha9Kv8Gmp5wqUpJWhYwLzNKdEYV77vu98k1MOLXsSSRomyni3PpfB61zFq
         ATIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786001820; x=1786606620;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ViL4VHVHnGZCDBTWYy/BbLFUaSoqso542Mz4ZuHRR0k=;
        b=qy2eFLRbhnBhG0e+J5VU91Ho0VjmBo0y+0zZZuZmBpxSeClP1C/B/jr4O76ueT02kU
         GP3vVgOdSktseRHhpvHFhJKeNcXS0BDavmWv7p3gzD6D9Zb4i5kEKs+DoITv1G3zDfPj
         lJARkDCG+PSlMqxZYjdV19WvHb95LcpDp1PGrmbRT/wkVe36IeSzQS3oVgo8FPBgQLp7
         ObdrVv/uYGtFN/EMjStBQ6kVxx7cdOmbfom5x0LU1OLlEhBCn80RSQYoNiiT82RDglyU
         IXpHOjgswhrHhJRsj5HbhU2gMYyiuov3mfh8RI2E66wX/SAnucqViNiEmcv5gqmMOdJJ
         fP3w==
X-Forwarded-Encrypted: i=1; AHgh+RrgKAr37uK9ZkkTekM/wnXV6E2Ck1jLnI3DqAFGjQ/crIUZxTYxpet9sKBCBBXN/JWT3R822eKT0AU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwUs7VXkNHbyg6PJ0Qkfp7kINbSuJ2qMwAqvO3++gFaAmmAoVnA
	xOXyargz/McvILT1f8iMTiBV9XIGV1yrKn6IB+7Gu8A3K4J+dOtQh3WE0Rc/OzCxgg==
X-Gm-Gg: AR+sD131UxgVKAMm6L2AD5mtK0pFXYa+lfr1F4ekMWRO3bPMw4diJOp14RBMolKmqtn
	j/frcYDQ94QW9JQPIXpRvbg4UBFvxbrRXD8Kl1DGxdD8uG+Dn1S8Rq7dZp9EOzIVsTeQPT4yvy2
	y09tlFhGfsbuF/aMME6MnaLuLyA2bl3I93E/wWBwSxPvqdslGINQtrGcV8qVHehYyy7obPmUkA0
	D+vq2OLXXjfti5n6yVm5k5WgghVrE4rplU/YYSwjSNnIi1E19jSZGhxZXPD5yzmmibW6VWlfVWU
	+0vJSo8cE65FjxzIb9+kr2cB4goZPPczMY9+6gVYLwAcaYoom/UZLxqQhWe29B30HzMzb8a46hK
	WYE8lH7588ryTSvc00ZEZoJ1prbm++o3h9R8k4qhF2n9u9l1VDs0SX1NcbMMSWl4UtIfdWHwNpE
	wQq6NqG7B8Vl5yiACTUS7Tx0wzDqlUDe4AbiVtOYZ4yn2ZkgDPfiOf0kspBnMYR7+58RYM3Myg7
	6uzY6xW14IqU+8/XyRdWwNSOyowzSTXapoiTgCIWJYcemNLnB9f
X-Received: by 2002:a05:600c:348a:b0:490:c6c2:52 with SMTP id 5b1f17b1804b1-4994e79b9c0mr185355295e9.3.1786001819346;
        Thu, 06 Aug 2026 00:36:59 -0700 (PDT)
Message-ID: <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
Date: Thu, 6 Aug 2026 09:36:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
 <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786001820-A6CDFAE4-CE4363B4/0/0
X-purgate-type: clean
X-purgate-size: 1869

On 06.08.2026 03:10, Daniel P. Smith wrote:
> On 7/28/26 9:23 AM, Jan Beulich wrote:
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
>>   
>>   #ifdef CONFIG_HAS_PIRQ
>>   
>> -static int cf_check flask_map_domain_pirq(struct domain *d)
>> +static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
>>   {
>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
>> -}
>> -
>> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
>> -{
>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>> +    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>>   }
>>   
>>   #endif /* CONFIG_HAS_PIRQ */
>>
> 
> I am not opposed to collapsing the calls as long as the semantic is not 
> lost, which I feel the reuse of the xsm_map_domain_pirq does looses it 
> much less provides an opportunity for confusion. Something like 
> xsm_domain_pirq(..., access) makes more semantic sense to me, as it 
> would read, grant domain pirq access T/F.

In fact I was as well wondering about naming (and a possible name change)
here. I decided against it because of the other hooks (touched by patch
19), which all follow a similar model of their names really more expressing
the "positive" form than the "negative" one. Further, entirely losing "map"
from the name also doesn't look quite right, as physdev_{,un}map_pirq() is
where they're called from. To follow the naming of some of the other hook,
maybe xsm_domain_pirq_mapping(..., bool map)? Possibly even with "domain"
dropped from the name, fully fitting xsm_io{mem,port}_mapping()? Which
would then further raise the question whether patch 19 should maybe rename
the parameters of those two hooks to "map" at the same time.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:02:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:02:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384333.1627316 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrt3v-000625-Vc; Thu, 06 Aug 2026 08:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384333.1627316; Thu, 06 Aug 2026 08:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrt3v-00061y-SV; Thu, 06 Aug 2026 08:02:47 +0000
Received: by outflank-mailman (input) for mailman id 1384333;
 Thu, 06 Aug 2026 08:02:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrt3v-00061s-9n
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:02:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrt3u-00EmAW-Mo
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:02:46 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a743f9f-5cb7-0a2a0a5109dd-0a2a45078852-38
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:02:46 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a743fa6-b4ea-0a2a45070019-d155dd2fd027-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:02:46 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-4799b3f7c83so1125769f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 01:02:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-47ff79b32cbsm4274844f8f.10.2026.08.06.01.02.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 01:02:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786003366; x=1786608166; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=3qC2koAO6M5d9qfd2TP0PWbB9YVhSs3GAciczfY0x2w=;
        b=I/Aq02b6ZaJEFEzXrGHHy5NCot2aiv7oKbvefORiHOwgS/Z/MrmLLkALC0JiEwYto4
         6PHpZ33slz7BEP+8Fy8i1Bm4Xf3z3coS9BYhMmXSi8WcXi2i/21O2kfnrffXfmGOHEwj
         U7muqe9kFMtbafTb21rAR9/hFTGmVBFkKdmls51QmgtI98djyuS4LfdD7BChO75q/TQA
         lRkga4Yx2lQMlItcHkVFvMOOuPLLeqWXq1vGP5P5WNnzI4qN0ST2oDRws+JrJF5r0pT+
         ux17+FsGfnmP500bp2GOMRSXeyKvVWDlcPTrtrlozsVJzNyo/69eCQmh3p16H15b0/xs
         8BIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786003366; x=1786608166;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=3qC2koAO6M5d9qfd2TP0PWbB9YVhSs3GAciczfY0x2w=;
        b=oZvZAH9AH+R+AEiprew/vYrgFPdeeXC9svokQtppmnd5ZIvWk20GUwG9DhiL/kMiHD
         E+Po6kZnLioU2885woFD1GgU6mGcUrY8PvhUP7MdTRel7mdWQsW4A4XI+pHHl7QPZkDE
         DN1buDppZws63OC6RiDm+YJeVSrM9LiXLEB9+8FFIiopHcDQRr/bJjvcddbWb/HQMEQt
         bQTokizWbxM7C3JonMunzXl4rxJW1sF/eFWZbMVQIAbrAY7iqeaEykuRuzqcv1cdFdF/
         CbutsKvfcRPFOC+1rJKTIzBUOqbkrYog4WLsH/AjZmw+r6h0AzNzgqDE6CENE+xNw+bg
         nasQ==
X-Forwarded-Encrypted: i=1; AHgh+RqE8XOo7E8R/unKLpqux5p1lAp0LTIoTQzAVZfI4VIfQXrHcVBWHK4JpHmF37wklEhLTbwfvvvxg90=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdnIA4E/lJgpY7yryC2eB3nXnWJbDRICb/4sMvYjmvYM1jhqtS
	LV1DI5HSuQxS4hAjlMeyG2VmaYyFUEtglwxNBzqXypBCQYn6EZnQCzzo1vWVf06/RA==
X-Gm-Gg: AR+sD10N7cbtlNZwTRBQ8jHak6vPOeeO9NPp77lg4J/KHUsxZuCJ2pyljv0hvtp2nOj
	GL3ZqLs2+11aMhNFjA8WL43bacs8TxMysDgex27R0cSS0KoVKEqPcnJSkvyV19xLhhU3cKTMsnv
	Ilve9EVJAm8vTfA6I283yrAqlzVJs/DnBBU3g1rJb/aNqH3f7audGYNEgTx7z5y+pC9QfgzrmcF
	earL+QuwiTSSeb7A7begUWGj0sSlnH9XPgk59BMQI2nzF0k0nJAHudpkUp0zVmISJ7BcWS+x5j4
	fdYD/5qBMbvfc5nYAptct8gDdo3y9Ov0rrsIU0zOvdAJ4tD/5xUGfyLwaci3IE7dreAQhGi/5mE
	oZipJr0EhiWsvjqyPSGaNVb4+EB5MQK0epHE+MA6jYkS0F4eNYgrVLc36Jtu8iVa+aNmzGM/9ax
	uQrk6wrZhhyh8eLW1GpL/fzfrQ8AH44P6Zy3nU5/MA7trK0TObnoHPTwKofiog5vDgwhHQ0r3cZ
	458K35o5wjHm+QupgNQ11olUFpSa8Tk6RA+S8I5yCC2EYAhItWnJ6phYBs1KYQ=
X-Received: by 2002:a05:6000:3113:b0:47f:80f0:8d33 with SMTP id ffacd0b85a97d-47fec6457camr19128500f8f.30.1786003365298;
        Thu, 06 Aug 2026 01:02:45 -0700 (PDT)
Message-ID: <7bfe23f3-b7cc-4821-b4a8-1d1793ffaa92@suse.com>
Date: Thu, 6 Aug 2026 10:02:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks
From: Jan Beulich <jbeulich@suse.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
 <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
 <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786003366-374D3AE4-6B3AF600/0/0
X-purgate-type: clean
X-purgate-size: 2058

On 06.08.2026 09:36, Jan Beulich wrote:
> On 06.08.2026 03:10, Daniel P. Smith wrote:
>> On 7/28/26 9:23 AM, Jan Beulich wrote:
>>> --- a/xen/xsm/flask/hooks.c
>>> +++ b/xen/xsm/flask/hooks.c
>>> @@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
>>>   
>>>   #ifdef CONFIG_HAS_PIRQ
>>>   
>>> -static int cf_check flask_map_domain_pirq(struct domain *d)
>>> +static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
>>>   {
>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
>>> -}
>>> -
>>> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
>>> -{
>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>>> +    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>>>   }
>>>   
>>>   #endif /* CONFIG_HAS_PIRQ */
>>>
>>
>> I am not opposed to collapsing the calls as long as the semantic is not 
>> lost, which I feel the reuse of the xsm_map_domain_pirq does looses it 
>> much less provides an opportunity for confusion. Something like 
>> xsm_domain_pirq(..., access) makes more semantic sense to me, as it 
>> would read, grant domain pirq access T/F.
> 
> In fact I was as well wondering about naming (and a possible name change)
> here. I decided against it because of the other hooks (touched by patch
> 19), which all follow a similar model of their names really more expressing
> the "positive" form than the "negative" one. Further, entirely losing "map"
> from the name also doesn't look quite right, as physdev_{,un}map_pirq() is
> where they're called from. To follow the naming of some of the other hook,
> maybe xsm_domain_pirq_mapping(..., bool map)? Possibly even with "domain"
> dropped from the name, fully fitting xsm_io{mem,port}_mapping()?

And then xsm_irq_mapping() in patch 23 and xsm_pt_irq_binding() in patch 24?

Jan

> Which
> would then further raise the question whether patch 19 should maybe rename
> the parameters of those two hooks to "map" at the same time.
> 
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384362.1627334 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrte2-0006dA-2C; Thu, 06 Aug 2026 08:40:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384362.1627334; Thu, 06 Aug 2026 08:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrte1-0006ci-Uk; Thu, 06 Aug 2026 08:40:05 +0000
Received: by outflank-mailman (input) for mailman id 1384362;
 Thu, 06 Aug 2026 08:40:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrte0-0006IA-9a
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrtdz-007961-ML
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:03 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744862-e002-0a2a0a5209dd-0a2a4505856c-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:03 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744862-4cb1-0a2a45050019-d98c6eacde50-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:02 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 91F4019F0;
 Thu,  6 Aug 2026 01:39:57 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id D66C63F632;
 Thu,  6 Aug 2026 01:39:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005601; bh=iynuOAJCPNuRyHhHF6oGom9ZpKtzcvQOC1dJwzRcJvM=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=PZG9EdTY1k5yypy3196H+wqk2/KNoPtVM/b9UYaFI6ZI3d24qfuLCJzRICQkyCkLc
	 sFKziULNcmx7SYfTqR1bq57rbn7/KNqG7/Xk/gSlWU94DTBYVqXEPKUndhrDA8EsJE
	 22M3TfK+4A1Hh9u1/kuRYdSEUGb4ZkLFgLd50Kg4=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
Date: Thu,  6 Aug 2026 09:38:39 +0100
Message-ID: <20260806083926.1807279-2-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1786005603-243112A1-4377233D/0/0
X-purgate-type: clean
X-purgate-size: 2610

pte_t is used both for logical PTE values and for entries stored in a PTE
table, so pte_t * does not distinguish a pointer to a copied value from a
pointer to table storage.

Introduce hw_pte_t as the generic name for a PTE table element. Define it
as a macro alias of pte_t by default. When an architecture selects
ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead.
This preserves the representation while allowing converted architectures
to enforce the distinction at compile time.

Keep the C type definitions behind an __ASSEMBLY__ check because
architecture assembly sources can include this header indirectly. Include
asm/page.h so consumers such as linux/vmalloc.h retain the page definitions
they previously obtained from that header.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition.
- Exclude the C type definitions from assembly sources.
- Update the description for the new opt-in model.
---
 MAINTAINERS                   |  1 +
 include/linux/pgtable_types.h | 17 +++++++++++++++++
 mm/Kconfig                    |  3 +++
 3 files changed, 21 insertions(+)
 create mode 100644 include/linux/pgtable_types.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e9c8567308a75..7169bea968cf5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16982,6 +16982,7 @@ F:	include/linux/mmu_notifier.h
 F:	include/linux/pagewalk.h
 F:	include/linux/pgalloc.h
 F:	include/linux/pgtable.h
+F:	include/linux/pgtable_types.h
 F:	include/linux/ptdump.h
 F:	include/linux/vmpressure.h
 F:	include/linux/vmstat.h
diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
new file mode 100644
index 0000000000000..70c3edd00a01b
--- /dev/null
+++ b/include/linux/pgtable_types.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PGTABLE_TYPES_H
+#define _LINUX_PGTABLE_TYPES_H
+
+#include <asm/page.h>
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_ARCH_HAS_HW_PTE_T
+typedef struct { pte_t __pte; } hw_pte_t;
+#else
+#define hw_pte_t pte_t
+#endif
+
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _LINUX_PGTABLE_TYPES_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 331daf7fcfab5..31ba9ebf4aafd 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1316,6 +1316,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled"
 config GUP_GET_PXX_LOW_HIGH
 	bool
 
+config ARCH_HAS_HW_PTE_T
+	bool
+
 config DMAPOOL_TEST
 	tristate "Enable a module to run time tests on dma_pool"
 	depends on HAS_DMA
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384361.1627325 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrtdt-0005XE-NC; Thu, 06 Aug 2026 08:39:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384361.1627325; Thu, 06 Aug 2026 08:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrtdt-0005X6-Jj; Thu, 06 Aug 2026 08:39:57 +0000
Received: by outflank-mailman (input) for mailman id 1384361;
 Thu, 06 Aug 2026 08:39:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrtds-0005Vv-6l
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:39:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrtdr-00790P-Jg
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:39:55 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744842-e002-0a2a0a5209dd-0a2a450a8a14-44
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:39:55 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74485a-f2d2-0a2a450a0019-d98c6eacdb06-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:39:54 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 836C4153B;
 Thu,  6 Aug 2026 01:39:49 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C4F063F632;
 Thu,  6 Aug 2026 01:39:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005593; bh=1/GXhzlocZP3RO99ssHRo2N31fXX+evtIf1AglwmeYk=;
	h=From:To:Cc:Subject:Date:From;
	b=XAD0GC3BFV+aOtURbErU8rEzfMbSmdJMzfNwzK/FHv0gx1gos8TDz/dRjKI0JzDR0
	 AQ4BuCvKLoJi+XVzKw+vUT1ULkUCtkTdaFTQUlv601HAIs75njL9FmO8WmoPB+Psrr
	 TDc5b83VZ6vnRuzuzlPGu/pmjS3BAMBtce5CKFQo=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 0/9] mm: distinguish PTE table storage from PTE values
Date: Thu,  6 Aug 2026 09:38:38 +0100
Message-ID: <20260806083926.1807279-1-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786005595-502F0CFC-4C0B5F46/0/0
X-purgate-type: clean
X-purgate-size: 12117

Hi,

pte_t currently describes both a logical PTE value and an element stored
in a PTE table. Consequently, pte_t * can point either to a standalone
value, often a stack copy, or to a PTE-table slot. The compiler cannot
distinguish these cases. A value pointer can therefore be passed to an
interface that expects table storage, while table storage can be read by
direct dereference instead of the architecture accessor.

This series begins a staged conversion at the PTE level. It introduces
hw_pte_t as the element type for PTE-table storage and converts generic
MM to use hw_pte_t *. Logical PTE values remain pte_t. Interfaces that
intentionally return a value through pte_t *, such as install_pte,
remain value interfaces; the relevant parameters are named ptentp to
make that distinction explicit.

The generic definition aliases hw_pte_t to pte_t unless an architecture
selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper. No
architecture selects it in this series, so the representation and
behaviour of every architecture are preserved. ptep_get() keeps its
existing READ_ONCE() semantics and converts the stored element through
__pte_from_hw(). An architecture can later select the option and convert
its PTE interfaces to make the distinction compiler-enforced.
Architecture PTE implementations and most architecture code are
deliberately left for those later opt-in conversions.

Here, hw_pte_t identifies PTE-table storage rather than table lifetime:
complete PTE tables use hw_pte_t whether or not they are currently
linked into a page-table hierarchy, while standalone copied values use
pte_t. The distinction between complete but unlinked tables and
hardware-reachable tables was raised during discussion and remains an
important point for review.

PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be
converted in later series after the PTE boundary is agreed, avoiding the
PMD-specific cases that made an all-level conversion difficult to
review.

Most mechanical pointer conversions were generated with the Coccinelle
script included below, then audited and fixed by hand.

This series does not add a second ptep_get_once() accessor and does not
remove or replace STRICT_MM_TYPECHECKS.

The design discussion is available at [1]; while the original idea came
from [2].

I've the patches here [3] for arm64 conversion which I used to find
usages in generic code which I missed during development. These would be
sent separately.

[1] https://lore.kernel.org/all/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com/
[2] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com
[3] https://github.com/musamaanjum/linux/commits/pte0_arm/

Thanks,
Usama
---
Changes since RFC v1:
- Add ARCH_HAS_HW_PTE_T so architectures can opt in to a distinct
  PTE-table storage type.
- Define the distinct hw_pte_t wrapper and its conversion helpers in
  generic code instead of requiring each architecture to define them.
- Read hw_pte_t through READ_ONCE() before converting it to pte_t.
- Drop the previous mremap patch in favour of [a]. Apply [a] first if
  it is not already present.
- Drop the previous two dead-code conversion patches; the affected
  code was cleaned up separately in [b] and [c].

[a] https://lore.kernel.org/linux-mm/20260720141633.501799-1-agordeev@linux.ibm.com/
[b] https://lore.kernel.org/all/20260730111316.3672672-1-usama.anjum@arm.com
[c] https://lore.kernel.org/all/20260730094501.3002718-1-usama.anjum@arm.com

---
// SPDX-License-Identifier: GPL-2.0-only
///
/// Rename raw PTE pointer types to hardware PTE pointer types.
///
/// This is a mechanical type rename. It converts common declarations,
/// function parameters, prototypes, return types and casts from "pte_t *"
/// to "hw_pte_t *". Plain "pte_t" objects are intentionally left unchanged.
/// Pointers named "ptentp" refer to temporary logical PTE values and are
/// intentionally ignored in all modes.
/// Re-run in context mode afterwards to audit remaining raw pte_t pointers
/// and cases that need hand conversion, such as trace macros and mixed
/// declarations.
///
/// Confidence: Moderate
// Options: --no-includes --include-headers

virtual patch
virtual report
virtual context

@local_decl depends on patch@
identifier x != ptentp;
@@
- pte_t *x;
+ hw_pte_t *x;

@local_decl_init depends on patch@
identifier x != ptentp;
expression e;
@@
- pte_t *x = e;
+ hw_pte_t *x = e;

@param_proto depends on patch@
identifier f;
identifier x != ptentp;
type R;
@@
R f(...,
- pte_t *x
+ hw_pte_t *x
,...);

@param_proto_unnamed depends on patch@
identifier f;
type R;
@@
R f(...,
- pte_t *
+ hw_pte_t *
,...);

@param_def depends on patch@
identifier f;
identifier x != ptentp;
type R;
@@
R f(...,
- pte_t *x
+ hw_pte_t *x
,...)
{ ... }

@ret_proto depends on patch@
identifier f;
parameter list ps;
@@
- pte_t *
+ hw_pte_t *
  f(ps);

@ret_def depends on patch@
identifier f;
parameter list ps;
@@
- pte_t *
+ hw_pte_t *
  f(ps)
{ ... }

@struct_member depends on patch@
identifier S;
identifier x != ptentp;
@@
struct S {
...
- pte_t *x;
+ hw_pte_t *x;
...
};

@union_member depends on patch@
identifier x != ptentp;
@@
union {
...
- pte_t *x;
+ hw_pte_t *x;
...
};

@union_member_in_struct depends on patch@
identifier S;
identifier x != ptentp;
@@
struct S {
...
union {
...
- pte_t *x;
+ hw_pte_t *x;
...
};
...
};

@fnptr_struct_member depends on patch@
identifier S,f;
identifier x != ptentp;
type R;
@@
struct S {
...
R (*f)(...,
- pte_t *x
+ hw_pte_t *x
,...);
...
};

@fnptr_typedef_pte_fn_t depends on patch@
identifier x != ptentp;
@@
typedef int (*pte_fn_t)(...,
- pte_t *x
+ hw_pte_t *x
,...);

@cast depends on patch@
expression e;
@@
- (pte_t *)e
+ (hw_pte_t *)e

@remaining_decl depends on context || report@
identifier x != ptentp;
position p;
@@
* pte_t *x@p;

@remaining_decl_init depends on context || report@
identifier x != ptentp;
expression e;
position p;
@@
* pte_t *x@p = e;

@remaining_param_proto depends on context || report@
identifier f;
identifier x != ptentp;
type R;
position p;
@@
R f(...,
* pte_t *x@p
,...);

@remaining_param_proto_unnamed depends on context || report@
identifier f;
type R;
position p;
@@
R f(...,
* pte_t *@p
,...);

@remaining_param_def depends on context || report@
identifier f;
identifier x != ptentp;
type R;
position p;
@@
R f(...,
* pte_t *x@p
,...)
{ ... }

@remaining_ret_proto depends on context || report@
identifier f;
parameter list ps;
position p;
@@
* pte_t *f@p(ps);

@remaining_ret_def depends on context || report@
identifier f;
parameter list ps;
position p;
@@
* pte_t *f@p(ps)
{ ... }

@remaining_struct_member depends on context || report@
identifier S;
identifier x != ptentp;
position p;
@@
struct S {
...
* pte_t *x@p;
...
};

@remaining_union_member depends on context || report@
identifier x != ptentp;
position p;
@@
union {
...
* pte_t *x@p;
...
};

@remaining_union_member_in_struct depends on context || report@
identifier S;
identifier x != ptentp;
position p;
@@
struct S {
...
union {
...
* pte_t *x@p;
...
};
...
};

@remaining_fnptr_struct_member depends on context || report@
identifier S,f;
identifier x != ptentp;
type R;
position p;
@@
struct S {
...
R (*f)(...,
* pte_t *x@p
,...);
...
};

@remaining_fnptr_typedef_pte_fn_t depends on context || report@
identifier x != ptentp;
position p;
@@
typedef int (*pte_fn_t)(...,
* pte_t *x@p
,...);

Muhammad Usama Anjum (9):
  mm: introduce hw_pte_t for PTE table storage
  mm: make hw_pte_t visible to generic PTE interfaces
  mm: name pointers to copied PTE values ptentp
  mm: use hw_pte_t for generic PTE table storage
  mm: convert PTE table entries in ptep_get()
  mm: convert PTE table entry to pte
  mm/kasan: use hw_pte_t for the early shadow PTE table
  drm/i915: use hw_pte_t for PTE range callbacks
  xen: use hw_pte_t for PTE range callbacks

 MAINTAINERS                                   |  1 +
 .../drm/i915/gem/selftests/i915_gem_mman.c    |  4 +-
 drivers/gpu/drm/i915/i915_mm.c                |  4 +-
 drivers/xen/gntdev.c                          |  2 +-
 drivers/xen/privcmd.c                         |  2 +-
 drivers/xen/xenbus/xenbus_client.c            |  2 +-
 drivers/xen/xlate_mmu.c                       |  4 +-
 fs/hugetlbfs/inode.c                          |  3 +-
 fs/proc/task_mmu.c                            | 33 ++++----
 include/asm-generic/hugetlb.h                 | 15 ++--
 include/asm-generic/pgalloc.h                 |  6 +-
 include/asm-generic/tlb.h                     |  5 +-
 include/linux/hugetlb.h                       | 52 ++++++------
 include/linux/kasan.h                         |  2 +-
 include/linux/mm.h                            | 26 +++---
 include/linux/page_table_check.h              | 10 ++-
 include/linux/pagewalk.h                      | 10 +--
 include/linux/pgtable.h                       | 81 ++++++++++---------
 include/linux/pgtable_types.h                 | 19 +++++
 include/linux/rmap.h                          |  2 +-
 include/linux/swapops.h                       |  6 +-
 include/linux/vmalloc.h                       |  4 +-
 include/trace/events/xen.h                    | 10 +--
 kernel/bpf/arena.c                            |  9 ++-
 kernel/events/core.c                          |  3 +-
 mm/Kconfig                                    |  3 +
 mm/damon/ops-common.c                         |  2 +-
 mm/damon/ops-common.h                         |  2 +-
 mm/damon/vaddr.c                              | 20 ++---
 mm/debug_vm_pgtable.c                         |  2 +-
 mm/filemap.c                                  |  4 +-
 mm/gup.c                                      |  9 ++-
 mm/highmem.c                                  | 15 ++--
 mm/hmm.c                                      |  6 +-
 mm/huge_memory.c                              |  4 +-
 mm/hugetlb.c                                  | 60 +++++++-------
 mm/hugetlb_vmemmap.c                          | 13 +--
 mm/internal.h                                 | 16 ++--
 mm/kasan/init.c                               | 14 ++--
 mm/kasan/shadow.c                             |  6 +-
 mm/khugepaged.c                               | 24 +++---
 mm/ksm.c                                      | 11 +--
 mm/madvise.c                                  | 18 +++--
 mm/mapping_dirty_helpers.c                    |  4 +-
 mm/memory-failure.c                           |  6 +-
 mm/memory.c                                   | 78 +++++++++---------
 mm/mempolicy.c                                |  4 +-
 mm/migrate.c                                  |  4 +-
 mm/migrate_device.c                           |  4 +-
 mm/mincore.c                                  |  4 +-
 mm/mlock.c                                    |  4 +-
 mm/mprotect.c                                 | 19 ++---
 mm/mremap.c                                   |  4 +-
 mm/page_table_check.c                         |  4 +-
 mm/pagewalk.c                                 |  9 ++-
 mm/percpu.c                                   |  2 +-
 mm/pgtable-generic.c                          | 20 ++---
 mm/ptdump.c                                   |  4 +-
 mm/rmap.c                                     |  6 +-
 mm/sparse-vmemmap.c                           | 24 +++---
 mm/swap_state.c                               |  3 +-
 mm/swapfile.c                                 |  5 +-
 mm/userfaultfd.c                              | 32 ++++----
 mm/util.c                                     |  2 +-
 mm/vmalloc.c                                  | 13 +--
 mm/vmscan.c                                   |  6 +-
 66 files changed, 437 insertions(+), 368 deletions(-)
 create mode 100644 include/linux/pgtable_types.h

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384364.1627343 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteB-00072n-8z; Thu, 06 Aug 2026 08:40:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384364.1627343; Thu, 06 Aug 2026 08:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteB-00072g-5o; Thu, 06 Aug 2026 08:40:15 +0000
Received: by outflank-mailman (input) for mailman id 1384364;
 Thu, 06 Aug 2026 08:40:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrte9-00071H-6B
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrte8-00HXWH-J7
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:12 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74486a-2eae-0a2a0a5409dd-0a2a450b8d92-6
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:11 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74486a-b7e8-0a2a450b0019-d98c6eacb280-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:11 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9E7E7153B;
 Thu,  6 Aug 2026 01:40:05 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E349C3F632;
 Thu,  6 Aug 2026 01:40:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005609; bh=iJ1Ndc5V3Xfq1tWscZTZQDNLVYCcoKPyTZqTCUohTZA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=SCDN3dhSTWUZvm7NxWd7kT2BoSqz+CVAJ52EjmPO3XFFI5DgzdxTKarmA8W7w8CCM
	 vAytJ56KvsfJiBpTM3sWcsX5b4vufVL2p6PVM/2YavA5VjzU41jcEC/tN2j35rLOND
	 s5OV5gCpv0HvNaWN+KVLCNsfqo1phtuKS4Aoj7Iw=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 2/9] mm: make hw_pte_t visible to generic PTE interfaces
Date: Thu,  6 Aug 2026 09:38:40 +0100
Message-ID: <20260806083926.1807279-3-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786005611-A86CA9EA-8529D4D7/0/0
X-purgate-type: clean
X-purgate-size: 1999

Later conversions use hw_pte_t in page-table checking, generic page-table
helpers, and vmalloc interfaces. Include linux/pgtable_types.h from the
headers that declare those interfaces before changing their types.

For vmalloc.h, replace the direct asm/page.h include with
linux/pgtable_types.h. The latter includes asm/page.h, so pgprot_t remains
available. It also provides either the default alias or the opted-in
hw_pte_t wrapper.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Clarify that the header provides both generic hw_pte_t definitions.
---
 include/linux/page_table_check.h | 2 ++
 include/linux/pgtable.h          | 1 +
 include/linux/vmalloc.h          | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/page_table_check.h b/include/linux/page_table_check.h
index 12268a32e8be1..12ee6d16ad339 100644
--- a/include/linux/page_table_check.h
+++ b/include/linux/page_table_check.h
@@ -7,6 +7,8 @@
 #ifndef __LINUX_PAGE_TABLE_CHECK_H
 #define __LINUX_PAGE_TABLE_CHECK_H
 
+#include <linux/pgtable_types.h>
+
 #ifdef CONFIG_PAGE_TABLE_CHECK
 #include <linux/jump_label.h>
 
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 8c093c119e5a8..cf595608cc4c4 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -4,6 +4,7 @@
 
 #include <linux/pfn.h>
 #include <asm/pgtable.h>
+#include <linux/pgtable_types.h>
 
 #define PMD_ORDER	(PMD_SHIFT - PAGE_SHIFT)
 #define PUD_ORDER	(PUD_SHIFT - PAGE_SHIFT)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index aed121d729b01..b068e6ade4207 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -8,7 +8,7 @@
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/llist.h>
-#include <asm/page.h>		/* pgprot_t */
+#include <linux/pgtable_types.h>	/* pgprot_t, hw_pte_t */
 #include <linux/rbtree.h>
 #include <linux/overflow.h>
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384366.1627352 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteH-0007O3-GC; Thu, 06 Aug 2026 08:40:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384366.1627352; Thu, 06 Aug 2026 08:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteH-0007Nq-Cn; Thu, 06 Aug 2026 08:40:21 +0000
Received: by outflank-mailman (input) for mailman id 1384366;
 Thu, 06 Aug 2026 08:40:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrteF-0007J6-LW
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrteF-009i3R-24
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:19 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74486e-5cb7-0a2a0a5109dd-0a2a450c952a-14
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:19 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744872-f479-0a2a450c0019-d98c6eacde30-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:18 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A8879176C;
 Thu,  6 Aug 2026 01:40:13 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id EF03D3F632;
 Thu,  6 Aug 2026 01:40:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005617; bh=kDSHwmzLBaSmEkZSi49/oE6mr/pQwSNTv0JlBRbim1E=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=iRLwcLlHzWWbx5Qhr2Q5N2yfBSglhNBHPcd7h0s5kOdYERPY7KTBCkBr+hcYbbhK4
	 U8v8vfKwbyB14RWAIzfzO9dXyKyK4cPchCL93DUg0JYZDnVP/bmKmDJDFD/ZKVGJnS
	 ia0P1AlmZO2FcO7EoUGQ6dM9k9gIa9RXeahhrylM=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 3/9] mm: name pointers to copied PTE values ptentp
Date: Thu,  6 Aug 2026 09:38:41 +0100
Message-ID: <20260806083926.1807279-4-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786005619-5113AA5B-BC21F25D/0/0
X-purgate-type: clean
X-purgate-size: 2575

The hw_pte_t conversion must retain pte_t * for pointers to standalone PTE
values. Name the value parameters ptentp in the install_pte callback,
write_protect_page(), and guard_install_set_pte() so the later mechanical
conversion can distinguish them from pointers to PTE table storage.

Some functions already use the ptentp name, including:
- madvise_folio_pte_batch()
- folio_pte_batch_flags()
No need to convert them.

This is a naming-only change.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Update the description for the architecture opt-in conversion.
---
 include/linux/pagewalk.h | 2 +-
 mm/ksm.c                 | 4 ++--
 mm/madvise.c             | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index b41d7265c01bc..c34d826c5e4a2 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -89,7 +89,7 @@ struct mm_walk_ops {
 		       struct mm_walk *walk);
 	void (*post_vma)(struct mm_walk *walk);
 	int (*install_pte)(unsigned long addr, unsigned long next,
-			   pte_t *ptep, struct mm_walk *walk);
+			   pte_t *ptentp, struct mm_walk *walk);
 	enum page_walk_lock walk_lock;
 };
 
diff --git a/mm/ksm.c b/mm/ksm.c
index ad05d7791307e..11d50518d02e9 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1292,7 +1292,7 @@ static u32 calc_checksum(struct page *page)
 }
 
 static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
-			      pte_t *orig_pte)
+			      pte_t *ptentp)
 {
 	struct mm_struct *mm = vma->vm_mm;
 	DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, 0, 0);
@@ -1371,7 +1371,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
 
 		set_pte_at(mm, pvmw.address, pvmw.pte, entry);
 	}
-	*orig_pte = entry;
+	*ptentp = entry;
 	err = 0;
 
 out_unlock:
diff --git a/mm/madvise.c b/mm/madvise.c
index 07a21ca31bad4..c324cc991f841 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1101,12 +1101,12 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr,
 }
 
 static int guard_install_set_pte(unsigned long addr, unsigned long next,
-				 pte_t *ptep, struct mm_walk *walk)
+				 pte_t *ptentp, struct mm_walk *walk)
 {
 	unsigned long *nr_pages = (unsigned long *)walk->private;
 
 	/* Simply install a PTE marker, this causes segfault on access. */
-	*ptep = make_pte_marker(PTE_MARKER_GUARD);
+	*ptentp = make_pte_marker(PTE_MARKER_GUARD);
 	(*nr_pages)++;
 
 	return 0;
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384374.1627361 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteP-0007qL-OY; Thu, 06 Aug 2026 08:40:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384374.1627361; Thu, 06 Aug 2026 08:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteP-0007pp-JF; Thu, 06 Aug 2026 08:40:29 +0000
Received: by outflank-mailman (input) for mailman id 1384374;
 Thu, 06 Aug 2026 08:40:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrteO-0007ot-Qa
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrteO-00Etan-6x
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:28 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744870-bab6-0a2a0a5309dd-0a2a45019188-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:28 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74487a-5984-0a2a45010019-d98c6eacdf26-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:27 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 69FED16F2;
 Thu,  6 Aug 2026 01:40:22 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 07CB63F632;
 Thu,  6 Aug 2026 01:40:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005626; bh=d6puQD0Mlx5ltItzd5udaSgPV/9XlOWc9bnV0b+nB4o=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=cOeZ8WDEB0HIOoXZjJUkBEVwqKv1KMVSpbMDuFZbx0FnRdsYjSLepXZyHqpvJsuh6
	 WZa6EuxYoWzXD2kpI13QAxmR890RAa2Lh3SeS+mmMtr+t+8p7GVjpetwVjTSm3dgtR
	 RKhiPlUrHrdv/m9Axp1IccPBL2vZheuHoOXHlCdM=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 4/9] mm: use hw_pte_t for generic PTE table storage
Date: Thu,  6 Aug 2026 09:38:42 +0100
Message-ID: <20260806083926.1807279-5-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1786005628-BF0634F7-678253F3/0/0
X-purgate-type: clean
X-purgate-size: 122503

Generic page-table interfaces use pte_t * for both pointers to PTE table
storage and pointers to standalone PTE values. Convert the generic
declarations and their MM, fs, and kernel users together so parameters,
return types, callbacks, and local pointers that designate table storage
use hw_pte_t *.

Keep logical PTE values as pte_t and retain pte_t * for value interfaces.

No architecture selects ARCH_HAS_HW_PTE_T at this point, so hw_pte_t
remains an alias of pte_t and this changes the interface vocabulary without
changing representation or behavior.

Most of this mechanical conversion was generated with the Coccinelle script
included in the cover letter. The script deliberately ignores pte_t *
pointers named ptentp because they designate standalone PTE values. The
result was then audited, and sites the script could not convert were
updated by hand.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Clarify that the distinct generic definition is activated by an
  architecture opt-in.
---
 fs/hugetlbfs/inode.c             |  3 +-
 fs/proc/task_mmu.c               | 33 +++++++-------
 include/asm-generic/hugetlb.h    | 15 +++---
 include/asm-generic/pgalloc.h    |  6 +--
 include/asm-generic/tlb.h        |  5 +-
 include/linux/hugetlb.h          | 50 +++++++++++---------
 include/linux/mm.h               | 26 +++++------
 include/linux/page_table_check.h |  8 ++--
 include/linux/pagewalk.h         |  8 ++--
 include/linux/pgtable.h          | 78 +++++++++++++++++---------------
 include/linux/rmap.h             |  2 +-
 include/linux/swapops.h          |  6 ++-
 include/linux/vmalloc.h          |  2 +-
 include/trace/events/xen.h       | 10 ++--
 kernel/bpf/arena.c               |  9 ++--
 kernel/events/core.c             |  3 +-
 mm/damon/ops-common.c            |  2 +-
 mm/damon/ops-common.h            |  2 +-
 mm/damon/vaddr.c                 | 20 ++++----
 mm/debug_vm_pgtable.c            |  2 +-
 mm/filemap.c                     |  4 +-
 mm/gup.c                         |  9 ++--
 mm/highmem.c                     | 15 +++---
 mm/hmm.c                         |  6 +--
 mm/huge_memory.c                 |  4 +-
 mm/hugetlb.c                     | 60 ++++++++++++------------
 mm/hugetlb_vmemmap.c             | 13 +++---
 mm/internal.h                    | 16 +++----
 mm/kasan/init.c                  | 12 ++---
 mm/kasan/shadow.c                |  6 +--
 mm/khugepaged.c                  | 24 +++++-----
 mm/ksm.c                         |  7 +--
 mm/madvise.c                     | 14 +++---
 mm/mapping_dirty_helpers.c       |  4 +-
 mm/memory-failure.c              |  6 +--
 mm/memory.c                      | 78 ++++++++++++++++----------------
 mm/mempolicy.c                   |  4 +-
 mm/migrate.c                     |  4 +-
 mm/migrate_device.c              |  4 +-
 mm/mincore.c                     |  4 +-
 mm/mlock.c                       |  4 +-
 mm/mprotect.c                    | 19 ++++----
 mm/mremap.c                      |  4 +-
 mm/page_table_check.c            |  4 +-
 mm/pagewalk.c                    |  9 ++--
 mm/percpu.c                      |  2 +-
 mm/pgtable-generic.c             | 20 ++++----
 mm/ptdump.c                      |  2 +-
 mm/rmap.c                        |  6 +--
 mm/sparse-vmemmap.c              | 24 +++++-----
 mm/swap_state.c                  |  3 +-
 mm/swapfile.c                    |  5 +-
 mm/userfaultfd.c                 | 32 +++++++------
 mm/util.c                        |  2 +-
 mm/vmalloc.c                     | 13 +++---
 mm/vmscan.c                      |  6 +--
 56 files changed, 391 insertions(+), 348 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index a578fba8e2fca..03a538352229b 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -328,7 +328,8 @@ static void hugetlb_delete_from_page_cache(struct folio *folio)
 static bool hugetlb_vma_maps_pfn(struct vm_area_struct *vma,
 				unsigned long addr, unsigned long pfn)
 {
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 
 	ptep = hugetlb_walk(vma, addr, huge_page_size(hstate_vma(vma)));
 	if (!ptep)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 817e3e0f91943..4118138f08c8e 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1046,7 +1046,7 @@ static void smaps_pte_hole_lookup(unsigned long addr, struct mm_walk *walk)
 #endif
 }
 
-static void smaps_pte_entry(pte_t *pte, unsigned long addr,
+static void smaps_pte_entry(hw_pte_t *pte, unsigned long addr,
 		struct mm_walk *walk)
 {
 	struct mem_size_stats *mss = walk->private;
@@ -1140,7 +1140,7 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			   struct mm_walk *walk)
 {
 	struct vm_area_struct *vma = walk->vma;
-	pte_t *pte;
+	hw_pte_t *pte;
 	spinlock_t *ptl;
 
 	ptl = pmd_trans_huge_lock(pmd, vma);
@@ -1263,7 +1263,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
-static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
+static int smaps_hugetlb_range(hw_pte_t *pte, unsigned long hmask,
 				 unsigned long addr, unsigned long end,
 				 struct mm_walk *walk)
 {
@@ -1704,7 +1704,7 @@ static inline bool pte_is_pinned(struct vm_area_struct *vma, unsigned long addr,
 }
 
 static inline void clear_soft_dirty(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *pte)
+		unsigned long addr, hw_pte_t *pte)
 {
 	if (!pgtable_supports_soft_dirty())
 		return;
@@ -1772,7 +1772,8 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,
 {
 	struct clear_refs_private *cp = walk->private;
 	struct vm_area_struct *vma = walk->vma;
-	pte_t *pte, ptent;
+	hw_pte_t *pte;
+	pte_t ptent;
 	spinlock_t *ptl;
 	struct folio *folio;
 
@@ -2172,7 +2173,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end,
 	struct vm_area_struct *vma = walk->vma;
 	struct pagemapread *pm = walk->private;
 	spinlock_t *ptl;
-	pte_t *pte, *orig_pte;
+	hw_pte_t *pte, *orig_pte;
 	int err = 0;
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
@@ -2210,7 +2211,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end,
 
 #ifdef CONFIG_HUGETLB_PAGE
 /* This function walks within one hugetlb entry in the single call */
-static int pagemap_hugetlb_range(pte_t *ptep, unsigned long hmask,
+static int pagemap_hugetlb_range(hw_pte_t *ptep, unsigned long hmask,
 				 unsigned long addr, unsigned long end,
 				 struct mm_walk *walk)
 {
@@ -2501,7 +2502,7 @@ static unsigned long pagemap_page_category(struct pagemap_scan_private *p,
 }
 
 static void make_uffd_wp_pte(struct vm_area_struct *vma,
-			     unsigned long addr, pte_t *pte, pte_t ptent)
+			     unsigned long addr, hw_pte_t *pte, pte_t ptent)
 {
 	if (pte_present(ptent)) {
 		pte_t old_pte;
@@ -2634,7 +2635,7 @@ static unsigned long pagemap_hugetlb_category(struct vm_area_struct *vma,
 }
 
 static void make_uffd_wp_huge_pte(struct vm_area_struct *vma,
-				  unsigned long addr, pte_t *ptep,
+				  unsigned long addr, hw_pte_t *ptep,
 				  pte_t ptent)
 {
 	const unsigned long psize = huge_page_size(hstate_vma(vma));
@@ -2868,7 +2869,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 	struct pagemap_scan_private *p = walk->private;
 	struct vm_area_struct *vma = walk->vma;
 	unsigned long addr, flush_end = 0;
-	pte_t *pte, *start_pte;
+	hw_pte_t *pte, *start_pte;
 	spinlock_t *ptl;
 	int ret;
 
@@ -2962,7 +2963,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
-static int pagemap_scan_hugetlb_entry(pte_t *ptep, unsigned long hmask,
+static int pagemap_scan_hugetlb_entry(hw_pte_t *ptep, unsigned long hmask,
 				      unsigned long start, unsigned long end,
 				      struct mm_walk *walk)
 {
@@ -3043,7 +3044,7 @@ static int pagemap_scan_hugetlb_hole_wp(struct vm_area_struct *vma,
 	unsigned long psize = huge_page_size(h);
 	struct mm_struct *mm = vma->vm_mm;
 	spinlock_t *ptl;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pte_t pte;
 
 	for (addr = ALIGN_DOWN(addr, psize); addr < end; addr += psize) {
@@ -3427,8 +3428,8 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long addr,
 	struct numa_maps *md = walk->private;
 	struct vm_area_struct *vma = walk->vma;
 	spinlock_t *ptl;
-	pte_t *orig_pte;
-	pte_t *pte;
+	hw_pte_t *orig_pte;
+	hw_pte_t *pte;
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	ptl = pmd_trans_huge_lock(pmd, vma);
@@ -3461,7 +3462,7 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long addr,
 	return 0;
 }
 #ifdef CONFIG_HUGETLB_PAGE
-static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask,
+static int gather_hugetlb_stats(hw_pte_t *pte, unsigned long hmask,
 		unsigned long addr, unsigned long end, struct mm_walk *walk)
 {
 	pte_t huge_pte;
@@ -3484,7 +3485,7 @@ static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask,
 }
 
 #else
-static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask,
+static int gather_hugetlb_stats(hw_pte_t *pte, unsigned long hmask,
 		unsigned long addr, unsigned long end, struct mm_walk *walk)
 {
 	return 0;
diff --git a/include/asm-generic/hugetlb.h b/include/asm-generic/hugetlb.h
index 635c41cc34797..3bfad4a99b64d 100644
--- a/include/asm-generic/hugetlb.h
+++ b/include/asm-generic/hugetlb.h
@@ -60,7 +60,7 @@ static inline int huge_pte_uffd(pte_t pte)
 
 #ifndef __HAVE_ARCH_HUGE_PTE_CLEAR
 static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
-		    pte_t *ptep, unsigned long sz)
+		    hw_pte_t *ptep, unsigned long sz)
 {
 	pte_clear(mm, addr, ptep);
 }
@@ -68,7 +68,7 @@ static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
 
 #ifndef __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
 static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, pte_t pte, unsigned long sz)
+		hw_pte_t *ptep, pte_t pte, unsigned long sz)
 {
 	set_pte_at(mm, addr, ptep, pte);
 }
@@ -76,7 +76,7 @@ static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
 
 #ifndef __HAVE_ARCH_HUGE_PTEP_GET_AND_CLEAR
 static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
-		unsigned long addr, pte_t *ptep, unsigned long sz)
+		unsigned long addr, hw_pte_t *ptep, unsigned long sz)
 {
 	return ptep_get_and_clear(mm, addr, ptep);
 }
@@ -84,7 +84,7 @@ static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
 
 #ifndef __HAVE_ARCH_HUGE_PTEP_CLEAR_FLUSH
 static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep)
+		unsigned long addr, hw_pte_t *ptep)
 {
 	return ptep_clear_flush(vma, addr, ptep);
 }
@@ -99,7 +99,7 @@ static inline int huge_pte_none(pte_t pte)
 
 #ifndef __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT
 static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
-		unsigned long addr, pte_t *ptep)
+		unsigned long addr, hw_pte_t *ptep)
 {
 	ptep_set_wrprotect(mm, addr, ptep);
 }
@@ -107,7 +107,7 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
 
 #ifndef __HAVE_ARCH_HUGE_PTEP_SET_ACCESS_FLAGS
 static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep,
+		unsigned long addr, hw_pte_t *ptep,
 		pte_t pte, int dirty)
 {
 	return ptep_set_access_flags(vma, addr, ptep, pte, dirty);
@@ -115,7 +115,8 @@ static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 #endif
 
 #ifndef __HAVE_ARCH_HUGE_PTEP_GET
-static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
+static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
+		hw_pte_t *ptep)
 {
 	return ptep_get(ptep);
 }
diff --git a/include/asm-generic/pgalloc.h b/include/asm-generic/pgalloc.h
index 051aa1331051c..b35e5a2158ada 100644
--- a/include/asm-generic/pgalloc.h
+++ b/include/asm-generic/pgalloc.h
@@ -16,7 +16,7 @@
  *
  * Return: pointer to the allocated memory or %NULL on error
  */
-static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm)
+static inline hw_pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm)
 {
 	struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL, 0);
 
@@ -40,7 +40,7 @@ static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm)
  *
  * Return: pointer to the allocated memory or %NULL on error
  */
-static inline pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm)
+static inline hw_pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm)
 {
 	return __pte_alloc_one_kernel_noprof(mm);
 }
@@ -52,7 +52,7 @@ static inline pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm)
  * @mm: the mm_struct of the current context
  * @pte: pointer to the memory containing the page table
  */
-static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
+static inline void pte_free_kernel(struct mm_struct *mm, hw_pte_t *pte)
 {
 	pagetable_dtor_free(virt_to_ptdesc(pte));
 }
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index bdcc2778ac64f..2c3517800a9a8 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -644,7 +644,8 @@ static inline void tlb_flush_p4d_range(struct mmu_gather *tlb,
 }
 
 #ifndef __tlb_remove_tlb_entry
-static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep, unsigned long address)
+static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb,
+		hw_pte_t *ptep, unsigned long address)
 {
 }
 #endif
@@ -670,7 +671,7 @@ static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep, u
  * consecutive ptes instead of only a single one.
  */
 static inline void tlb_remove_tlb_entries(struct mmu_gather *tlb,
-		pte_t *ptep, unsigned int nr, unsigned long address)
+		hw_pte_t *ptep, unsigned int nr, unsigned long address)
 {
 	tlb_flush_pte_range(tlb, address, PAGE_SIZE * nr);
 	for (;;) {
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 16c4c4caa126c..bc0b9c65aa1d0 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -141,7 +141,7 @@ unsigned long hugetlb_total_pages(void);
 vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 			unsigned long address, unsigned int flags);
 #ifdef CONFIG_USERFAULTFD
-int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
+int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte,
 			     struct vm_area_struct *dst_vma,
 			     unsigned long dst_addr,
 			     unsigned long src_addr,
@@ -161,7 +161,7 @@ void hugetlb_fix_reserve_counts(struct inode *inode);
 extern struct mutex *hugetlb_fault_mutex_table;
 u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx);
 
-pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
+hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
 		      unsigned long addr, pud_t *pud);
 bool hugetlbfs_pagecache_present(struct hstate *h,
 				 struct vm_area_struct *vma,
@@ -186,22 +186,22 @@ void hugetlb_bootmem_set_nodes(void);
  * which may go down to the lowest PTE level in their huge_pte_offset() and
  * huge_pte_alloc(): to avoid reliance on pte_offset_map() without pte_unmap().
  */
-static inline pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address)
+static inline hw_pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address)
 {
 	return pte_offset_kernel(pmd, address);
 }
-static inline pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd,
+static inline hw_pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd,
 				    unsigned long address)
 {
 	return pte_alloc(mm, pmd) ? NULL : pte_offset_huge(pmd, address);
 }
 #endif
 
-pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
+hw_pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
 			unsigned long addr, unsigned long sz);
 /*
  * huge_pte_offset(): Walk the hugetlb pgtable until the last level PTE.
- * Returns the pte_t* if found, or NULL if the address is not mapped.
+ * Returns the hw_pte_t* if found, or NULL if the address is not mapped.
  *
  * IMPORTANT: we should normally not directly call this function, instead
  * this is only a common interface to implement arch-specific
@@ -236,11 +236,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
  * a concurrent pmd unshare, but it makes sure the pgtable page is safe to
  * access.
  */
-pte_t *huge_pte_offset(struct mm_struct *mm,
+hw_pte_t *huge_pte_offset(struct mm_struct *mm,
 		       unsigned long addr, unsigned long sz);
 unsigned long hugetlb_mask_last_page(struct hstate *h);
 int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep);
+		unsigned long addr, hw_pte_t *ptep);
 void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma);
 void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
 				unsigned long *start, unsigned long *end);
@@ -302,7 +302,8 @@ static inline struct address_space *hugetlb_folio_mapping_lock_write(
 }
 
 static inline int huge_pmd_unshare(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep)
+		struct vm_area_struct *vma, unsigned long addr,
+		hw_pte_t *ptep)
 {
 	return 0;
 }
@@ -394,7 +395,7 @@ static inline int is_hugepage_only_range(struct mm_struct *mm,
 }
 
 #ifdef CONFIG_USERFAULTFD
-static inline int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
+static inline int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte,
 					   struct vm_area_struct *dst_vma,
 					   unsigned long dst_addr,
 					   unsigned long src_addr,
@@ -406,7 +407,7 @@ static inline int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
 }
 #endif /* CONFIG_USERFAULTFD */
 
-static inline pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr,
+static inline hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr,
 					unsigned long sz)
 {
 	return NULL;
@@ -989,7 +990,8 @@ static inline bool htlb_allow_alloc_fallback(enum migrate_reason reason)
 }
 
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
-					   struct mm_struct *mm, pte_t *pte)
+					   struct mm_struct *mm,
+					   hw_pte_t *pte)
 {
 	const unsigned long size = huge_page_size(h);
 
@@ -1053,7 +1055,8 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
 #ifndef huge_ptep_modify_prot_start
 #define huge_ptep_modify_prot_start huge_ptep_modify_prot_start
 static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
-						unsigned long addr, pte_t *ptep)
+						unsigned long addr,
+						hw_pte_t *ptep)
 {
 	unsigned long psize = huge_page_size(hstate_vma(vma));
 
@@ -1064,7 +1067,8 @@ static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma,
 #ifndef huge_ptep_modify_prot_commit
 #define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit
 static inline void huge_ptep_modify_prot_commit(struct vm_area_struct *vma,
-						unsigned long addr, pte_t *ptep,
+						unsigned long addr,
+						hw_pte_t *ptep,
 						pte_t old_pte, pte_t pte)
 {
 	unsigned long psize = huge_page_size(hstate_vma(vma));
@@ -1252,7 +1256,8 @@ static inline bool htlb_allow_alloc_fallback(enum migrate_reason reason)
 }
 
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
-					   struct mm_struct *mm, pte_t *pte)
+					   struct mm_struct *mm,
+					   hw_pte_t *pte)
 {
 	return &mm->page_table_lock;
 }
@@ -1269,11 +1274,11 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
 {
 }
 
-pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep);
+pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, hw_pte_t *ptep);
 unsigned long huge_pte_dirty(pte_t pte);
 
 static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
-					  unsigned long addr, pte_t *ptep)
+					  unsigned long addr, hw_pte_t *ptep)
 {
 #ifdef CONFIG_MMU
 	return ptep_get(ptep);
@@ -1283,7 +1288,8 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 }
 
 static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
-				   pte_t *ptep, pte_t pte, unsigned long sz)
+				   hw_pte_t *ptep, pte_t pte,
+				   unsigned long sz)
 {
 }
 
@@ -1311,7 +1317,7 @@ static inline void hugetlb_bootmem_struct_page_init(void)
 #endif	/* CONFIG_HUGETLB_PAGE */
 
 static inline spinlock_t *huge_pte_lock(struct hstate *h,
-					struct mm_struct *mm, pte_t *pte)
+					struct mm_struct *mm, hw_pte_t *pte)
 {
 	spinlock_t *ptl;
 
@@ -1329,12 +1335,12 @@ static inline __init void hugetlb_cma_reserve(void)
 #endif
 
 #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
-static inline bool hugetlb_pmd_shared(pte_t *pte)
+static inline bool hugetlb_pmd_shared(hw_pte_t *pte)
 {
 	return ptdesc_pmd_is_shared(virt_to_ptdesc(pte));
 }
 #else
-static inline bool hugetlb_pmd_shared(pte_t *pte)
+static inline bool hugetlb_pmd_shared(hw_pte_t *pte)
 {
 	return false;
 }
@@ -1361,7 +1367,7 @@ bool __vma_private_lock(struct vm_area_struct *vma);
  * Safe version of huge_pte_offset() to check the locks.  See comments
  * above huge_pte_offset().
  */
-static inline pte_t *
+static inline hw_pte_t *
 hugetlb_walk(struct vm_area_struct *vma, unsigned long addr, unsigned long sz)
 {
 #if defined(CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING) && defined(CONFIG_LOCKDEP)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7fabe6c66b4b7..f41441c4a5a3b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -782,7 +782,7 @@ struct vm_fault {
 					 * VM_FAULT_ERROR).
 					 */
 	/* These three entries are valid only while holding ptl lock */
-	pte_t *pte;			/* Pointer to pte entry matching
+	hw_pte_t *pte;			/* Pointer to pte entry matching
 					 * the 'address'. NULL if the page
 					 * table hasn't been allocated.
 					 */
@@ -3188,7 +3188,7 @@ struct follow_pfnmap_args {
 	 * The caller shouldn't touch any of these.
 	 */
 	spinlock_t *lock;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	/**
 	 * Outputs:
 	 *
@@ -3525,7 +3525,7 @@ static inline pud_t pud_mkspecial(pud_t pud)
 }
 #endif	/* CONFIG_ARCH_SUPPORTS_PUD_PFNMAP */
 
-extern pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr,
+extern hw_pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr,
 			     spinlock_t **ptl);
 
 #ifdef __PAGETABLE_P4D_FOLDED
@@ -3803,7 +3803,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd)
 	return ptlock_ptr(page_ptdesc(pmd_page(*pmd)));
 }
 
-static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte)
+static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, hw_pte_t *pte)
 {
 	BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHPTE));
 	BUILD_BUG_ON(MAX_PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE);
@@ -3834,7 +3834,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd)
 {
 	return &mm->page_table_lock;
 }
-static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte)
+static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, hw_pte_t *pte)
 {
 	return &mm->page_table_lock;
 }
@@ -3875,19 +3875,19 @@ static inline bool pagetable_pte_ctor(struct mm_struct *mm,
 	return true;
 }
 
-pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp);
+hw_pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp);
 
-static inline pte_t *pte_offset_map(pmd_t *pmd, unsigned long addr)
+static inline hw_pte_t *pte_offset_map(pmd_t *pmd, unsigned long addr)
 {
 	return __pte_offset_map(pmd, addr, NULL);
 }
 
-pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd,
+hw_pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd,
 			   unsigned long addr, spinlock_t **ptlp);
 
-pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
+hw_pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
 				unsigned long addr, spinlock_t **ptlp);
-pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd,
+hw_pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd,
 				unsigned long addr, pmd_t *pmdvalp,
 				spinlock_t **ptlp);
 
@@ -4836,7 +4836,7 @@ static inline bool gup_can_follow_protnone(const struct vm_area_struct *vma,
 	return !vma_is_accessible(vma);
 }
 
-typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data);
+typedef int (*pte_fn_t)(hw_pte_t *pte, unsigned long addr, void *data);
 extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
 			       unsigned long size, pte_fn_t fn, void *data);
 extern int apply_to_existing_page_range(struct mm_struct *mm,
@@ -5086,7 +5086,7 @@ void *vmemmap_alloc_block(unsigned long size, int node);
 struct vmem_altmap;
 void *vmemmap_alloc_block_buf(unsigned long size, int node,
 			      struct vmem_altmap *altmap);
-void vmemmap_verify(pte_t *, int, unsigned long, unsigned long);
+void vmemmap_verify(hw_pte_t *, int, unsigned long, unsigned long);
 void vmemmap_set_pmd(pmd_t *pmd, void *p, int node,
 		     unsigned long addr, unsigned long next);
 int vmemmap_check_pmd(pmd_t *pmd, int node,
@@ -5454,7 +5454,7 @@ static inline bool snapshot_page_is_faithful(const struct page_snapshot *ps)
 
 void snapshot_page(struct page_snapshot *ps, const struct page *page);
 
-void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
+void map_anon_folio_pte_nopf(struct folio *folio, hw_pte_t *pte,
 		struct vm_area_struct *vma, unsigned long addr,
 		bool uffd_wp);
 
diff --git a/include/linux/page_table_check.h b/include/linux/page_table_check.h
index 12ee6d16ad339..933c1028c2232 100644
--- a/include/linux/page_table_check.h
+++ b/include/linux/page_table_check.h
@@ -23,7 +23,7 @@ void __page_table_check_pmd_clear(struct mm_struct *mm, unsigned long addr,
 void __page_table_check_pud_clear(struct mm_struct *mm, unsigned long addr,
 				  pud_t pud);
 void __page_table_check_ptes_set(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, pte_t pte, unsigned int nr);
+		hw_pte_t *ptep, pte_t pte, unsigned int nr);
 void __page_table_check_pmds_set(struct mm_struct *mm, unsigned long addr,
 		pmd_t *pmdp, pmd_t pmd, unsigned int nr);
 void __page_table_check_puds_set(struct mm_struct *mm, unsigned long addr,
@@ -76,7 +76,8 @@ static inline void page_table_check_pud_clear(struct mm_struct *mm,
 }
 
 static inline void page_table_check_ptes_set(struct mm_struct *mm,
-					     unsigned long addr, pte_t *ptep,
+					     unsigned long addr,
+					     hw_pte_t *ptep,
 					     pte_t pte, unsigned int nr)
 {
 	if (static_branch_likely(&page_table_check_disabled))
@@ -139,7 +140,8 @@ static inline void page_table_check_pud_clear(struct mm_struct *mm,
 }
 
 static inline void page_table_check_ptes_set(struct mm_struct *mm,
-					     unsigned long addr, pte_t *ptep,
+					     unsigned long addr,
+					     hw_pte_t *ptep,
 					     pte_t pte, unsigned int nr)
 {
 }
diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index c34d826c5e4a2..7ab2eb39e02c0 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -38,7 +38,7 @@ enum page_walk_lock {
  *			not trigger for any populated ranges.
  * @hugetlb_entry:	if set, called for each hugetlb entry. This hook
  *			function is called with the vma lock held, in order to
- *			protect against a concurrent freeing of the pte_t* or
+ *			protect against a concurrent freeing of the hw_pte_t* or
  *			the ptl. In some cases, the hook function needs to drop
  *			and retake the vma lock in order to avoid deadlocks
  *			while calling other functions. In such cases the hook
@@ -76,11 +76,11 @@ struct mm_walk_ops {
 			 unsigned long next, struct mm_walk *walk);
 	int (*pmd_entry)(pmd_t *pmd, unsigned long addr,
 			 unsigned long next, struct mm_walk *walk);
-	int (*pte_entry)(pte_t *pte, unsigned long addr,
+	int (*pte_entry)(hw_pte_t *pte, unsigned long addr,
 			 unsigned long next, struct mm_walk *walk);
 	int (*pte_hole)(unsigned long addr, unsigned long next,
 			int depth, struct mm_walk *walk);
-	int (*hugetlb_entry)(pte_t *pte, unsigned long hmask,
+	int (*hugetlb_entry)(hw_pte_t *pte, unsigned long hmask,
 			     unsigned long addr, unsigned long next,
 			     struct mm_walk *walk);
 	int (*test_walk)(unsigned long addr, unsigned long next,
@@ -173,7 +173,7 @@ struct folio_walk {
 	struct page *page;
 	enum folio_walk_level level;
 	union {
-		pte_t *ptep;
+		hw_pte_t *ptep;
 		pud_t *pudp;
 		pmd_t *pmdp;
 	};
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index cf595608cc4c4..dad80d264aac2 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -94,26 +94,26 @@ static inline void pud_init(void *addr)
 #endif
 
 #ifndef pte_offset_kernel
-static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
+static inline hw_pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
 {
-	return (pte_t *)pmd_page_vaddr(*pmd) + pte_index(address);
+	return (hw_pte_t *)pmd_page_vaddr(*pmd) + pte_index(address);
 }
 #define pte_offset_kernel pte_offset_kernel
 #endif
 
 #ifdef CONFIG_HIGHPTE
 #define __pte_map(pmd, address) \
-	((pte_t *)kmap_local_page(pmd_page(*(pmd))) + pte_index((address)))
+	((hw_pte_t *)kmap_local_page(pmd_page(*(pmd))) + pte_index((address)))
 #define pte_unmap(pte)	do {	\
 	kunmap_local((pte));	\
 	rcu_read_unlock();	\
 } while (0)
 #else
-static inline pte_t *__pte_map(pmd_t *pmd, unsigned long address)
+static inline hw_pte_t *__pte_map(pmd_t *pmd, unsigned long address)
 {
 	return pte_offset_kernel(pmd, address);
 }
-static inline void pte_unmap(pte_t *pte)
+static inline void pte_unmap(hw_pte_t *pte)
 {
 	rcu_read_unlock();
 }
@@ -173,7 +173,7 @@ static inline pmd_t *pmd_off_k(unsigned long va)
 	return pmd_offset(pud_offset(p4d_offset(pgd_offset_k(va), va), va), va);
 }
 
-static inline pte_t *virt_to_kpte(unsigned long vaddr)
+static inline hw_pte_t *virt_to_kpte(unsigned long vaddr)
 {
 	pmd_t *pmd = pmd_off_k(vaddr);
 
@@ -408,7 +408,7 @@ static inline void lazy_mmu_mode_resume(void) {}
  *
  * May be overridden by the architecture, else pte_batch_hint is always 1.
  */
-static inline unsigned int pte_batch_hint(pte_t *ptep, pte_t pte)
+static inline unsigned int pte_batch_hint(hw_pte_t *ptep, pte_t pte)
 {
 	return 1;
 }
@@ -443,7 +443,7 @@ static inline pte_t pte_advance_pfn(pte_t pte, unsigned long nr)
  * to the same folio.  The PTEs are all in the same PMD.
  */
 static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, pte_t pte, unsigned int nr)
+		hw_pte_t *ptep, pte_t pte, unsigned int nr)
 {
 	page_table_check_ptes_set(mm, addr, ptep, pte, nr);
 
@@ -460,7 +460,7 @@ static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
 
 #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 extern int ptep_set_access_flags(struct vm_area_struct *vma,
-				 unsigned long address, pte_t *ptep,
+				 unsigned long address, hw_pte_t *ptep,
 				 pte_t entry, int dirty);
 #endif
 
@@ -491,7 +491,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma,
 #endif
 
 #ifndef ptep_get
-static inline pte_t ptep_get(pte_t *ptep)
+static inline pte_t ptep_get(hw_pte_t *ptep)
 {
 	return READ_ONCE(*ptep);
 }
@@ -527,7 +527,7 @@ static inline pgd_t pgdp_get(pgd_t *pgdp)
 
 #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
 static inline bool ptep_test_and_clear_young(struct vm_area_struct *vma,
-		unsigned long address, pte_t *ptep)
+		unsigned long address, hw_pte_t *ptep)
 {
 	pte_t pte = ptep_get(ptep);
 	bool young = true;
@@ -566,7 +566,7 @@ static inline bool pmdp_test_and_clear_young(struct vm_area_struct *vma,
 
 #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
 bool ptep_clear_flush_young(struct vm_area_struct *vma,
-		unsigned long address, pte_t *ptep);
+		unsigned long address, hw_pte_t *ptep);
 #endif
 
 #ifndef __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH
@@ -645,7 +645,7 @@ static inline void arch_check_zapped_pud(struct vm_area_struct *vma, pud_t pud)
 #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR
 static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
 				       unsigned long address,
-				       pte_t *ptep)
+				       hw_pte_t *ptep)
 {
 	pte_t pte = ptep_get(ptep);
 	pte_clear(mm, address, ptep);
@@ -674,7 +674,7 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm,
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline void clear_young_dirty_ptes(struct vm_area_struct *vma,
-					  unsigned long addr, pte_t *ptep,
+					  unsigned long addr, hw_pte_t *ptep,
 					  unsigned int nr, cydp_t flags)
 {
 	pte_t pte;
@@ -699,7 +699,7 @@ static inline void clear_young_dirty_ptes(struct vm_area_struct *vma,
 #endif
 
 static inline void ptep_clear(struct mm_struct *mm, unsigned long addr,
-			      pte_t *ptep)
+			      hw_pte_t *ptep)
 {
 	pte_t pte = ptep_get(ptep);
 
@@ -740,7 +740,7 @@ static inline void ptep_clear(struct mm_struct *mm, unsigned long addr,
  * present bit set *unless* it is 'l'. Because get_user_pages_fast() only
  * operates on present ptes we're safe.
  */
-static inline pte_t ptep_get_lockless(pte_t *ptep)
+static inline pte_t ptep_get_lockless(hw_pte_t *ptep)
 {
 	pte_t pte;
 
@@ -778,7 +778,7 @@ static inline pmd_t pmdp_get_lockless(pmd_t *pmdp)
  * We require that the PTE can be read atomically.
  */
 #ifndef ptep_get_lockless
-static inline pte_t ptep_get_lockless(pte_t *ptep)
+static inline pte_t ptep_get_lockless(hw_pte_t *ptep)
 {
 	return ptep_get(ptep);
 }
@@ -845,7 +845,8 @@ static inline pud_t pudp_huge_get_and_clear_full(struct vm_area_struct *vma,
 
 #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
 static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
-					    unsigned long address, pte_t *ptep,
+					    unsigned long address,
+					    hw_pte_t *ptep,
 					    int full)
 {
 	return ptep_get_and_clear(mm, address, ptep);
@@ -873,7 +874,7 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm,
-		unsigned long addr, pte_t *ptep, unsigned int nr, int full)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr, int full)
 {
 	pte_t pte, tmp_pte;
 
@@ -909,7 +910,7 @@ static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm,
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, unsigned int nr)
+		hw_pte_t *ptep, unsigned int nr)
 {
 	return get_and_clear_full_ptes(mm, addr, ptep, nr, 0);
 }
@@ -934,7 +935,7 @@ static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr,
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, unsigned int nr, int full)
+		hw_pte_t *ptep, unsigned int nr, int full)
 {
 	for (;;) {
 		ptep_get_and_clear_full(mm, addr, ptep, full);
@@ -963,7 +964,7 @@ static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr,
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline void clear_ptes(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, unsigned int nr)
+		hw_pte_t *ptep, unsigned int nr)
 {
 	clear_full_ptes(mm, addr, ptep, nr, 0);
 }
@@ -978,13 +979,14 @@ static inline void clear_ptes(struct mm_struct *mm, unsigned long addr,
  */
 #ifndef update_mmu_tlb_range
 static inline void update_mmu_tlb_range(struct vm_area_struct *vma,
-				unsigned long address, pte_t *ptep, unsigned int nr)
+				unsigned long address, hw_pte_t *ptep,
+				unsigned int nr)
 {
 }
 #endif
 
 static inline void update_mmu_tlb(struct vm_area_struct *vma,
-				unsigned long address, pte_t *ptep)
+				unsigned long address, hw_pte_t *ptep)
 {
 	update_mmu_tlb_range(vma, address, ptep, 1);
 }
@@ -1001,7 +1003,7 @@ static inline void update_mmu_tlb(struct vm_area_struct *vma,
  * The PTEs are all in the same PMD.
  */
 static inline void clear_nonpresent_ptes(struct mm_struct *mm,
-		unsigned long addr, pte_t *ptep, unsigned int nr)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr)
 {
 	(void)addr;
 
@@ -1017,7 +1019,7 @@ static inline void clear_nonpresent_ptes(struct mm_struct *mm,
 #ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH
 extern pte_t ptep_clear_flush(struct vm_area_struct *vma,
 			      unsigned long address,
-			      pte_t *ptep);
+			      hw_pte_t *ptep);
 #endif
 
 #ifndef __HAVE_ARCH_PMDP_HUGE_CLEAR_FLUSH
@@ -1045,7 +1047,8 @@ static inline pmd_t pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma)
 
 #ifndef __HAVE_ARCH_PTEP_SET_WRPROTECT
 struct mm_struct;
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep)
+static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address,
+				      hw_pte_t *ptep)
 {
 	pte_t old_pte = ptep_get(ptep);
 	set_pte_at(mm, address, ptep, pte_wrprotect(old_pte));
@@ -1071,7 +1074,7 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres
  * ptep_try_set as an identity macro. The generic stub returns false, which is
  * correct for callers that fall through to oops on failure.
  */
-static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
+static inline bool ptep_try_set(hw_pte_t *ptep, pte_t new_pte)
 {
 	return false;
 }
@@ -1114,7 +1117,7 @@ static inline void flush_tlb_before_set(unsigned long addr)
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr,
-		pte_t *ptep, unsigned int nr)
+		hw_pte_t *ptep, unsigned int nr)
 {
 	for (;;) {
 		ptep_set_wrprotect(mm, addr, ptep);
@@ -1145,7 +1148,7 @@ static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr,
  * pages that belong to the same folio.  The PTEs are all in the same PMD.
  */
 static inline bool clear_flush_young_ptes(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, unsigned int nr)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr)
 {
 	bool young = false;
 
@@ -1182,7 +1185,7 @@ static inline bool clear_flush_young_ptes(struct vm_area_struct *vma,
  * Returns: whether any PTE was young.
  */
 static inline bool test_and_clear_young_ptes(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, unsigned int nr)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr)
 {
 	bool young = false;
 
@@ -1586,7 +1589,7 @@ static inline int pmd_none_or_clear_bad(pmd_t *pmd)
 
 static inline pte_t __ptep_modify_prot_start(struct vm_area_struct *vma,
 					     unsigned long addr,
-					     pte_t *ptep)
+					     hw_pte_t *ptep)
 {
 	/*
 	 * Get the current pte state, but zero it out to make it
@@ -1598,7 +1601,7 @@ static inline pte_t __ptep_modify_prot_start(struct vm_area_struct *vma,
 
 static inline void __ptep_modify_prot_commit(struct vm_area_struct *vma,
 					     unsigned long addr,
-					     pte_t *ptep, pte_t pte)
+					     hw_pte_t *ptep, pte_t pte)
 {
 	/*
 	 * The pte is non-present, so there's no hardware state to
@@ -1624,7 +1627,7 @@ static inline void __ptep_modify_prot_commit(struct vm_area_struct *vma,
  */
 static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma,
 					   unsigned long addr,
-					   pte_t *ptep)
+					   hw_pte_t *ptep)
 {
 	return __ptep_modify_prot_start(vma, addr, ptep);
 }
@@ -1637,7 +1640,8 @@ static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma,
  */
 static inline void ptep_modify_prot_commit(struct vm_area_struct *vma,
 					   unsigned long addr,
-					   pte_t *ptep, pte_t old_pte, pte_t pte)
+					   hw_pte_t *ptep, pte_t old_pte,
+					   pte_t pte)
 {
 	__ptep_modify_prot_commit(vma, addr, ptep, pte);
 }
@@ -1668,7 +1672,7 @@ static inline void ptep_modify_prot_commit(struct vm_area_struct *vma,
  */
 #ifndef modify_prot_start_ptes
 static inline pte_t modify_prot_start_ptes(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, unsigned int nr)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr)
 {
 	pte_t pte, tmp_pte;
 
@@ -1708,7 +1712,7 @@ static inline pte_t modify_prot_start_ptes(struct vm_area_struct *vma,
  */
 #ifndef modify_prot_commit_ptes
 static inline void modify_prot_commit_ptes(struct vm_area_struct *vma, unsigned long addr,
-		pte_t *ptep, pte_t old_pte, pte_t pte, unsigned int nr)
+		hw_pte_t *ptep, pte_t old_pte, pte_t pte, unsigned int nr)
 {
 	int i;
 
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index a174758f77775..1fc64074283d6 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -868,7 +868,7 @@ struct page_vma_mapped_walk {
 	struct vm_area_struct *vma;
 	unsigned long address;
 	pmd_t *pmd;
-	pte_t *pte;
+	hw_pte_t *pte;
 	spinlock_t *ptl;
 	unsigned int flags;
 	bool is_anon_walk;
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index c956bc445ee01..aeba03c96da1f 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -215,7 +215,8 @@ static inline swp_entry_t make_migration_entry_dirty(swp_entry_t entry)
 
 extern void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd,
 					unsigned long address);
-extern void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, pte_t *pte);
+extern void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr,
+				      hw_pte_t *pte);
 #else  /* CONFIG_MIGRATION */
 static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
 {
@@ -235,7 +236,8 @@ static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
 static inline void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd,
 					unsigned long address) { }
 static inline void migration_entry_wait_huge(struct vm_area_struct *vma,
-					     unsigned long addr, pte_t *pte) { }
+					     unsigned long addr,
+					     hw_pte_t *pte) { }
 
 static inline swp_entry_t make_migration_entry_young(swp_entry_t entry)
 {
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index b068e6ade4207..666ff2b3741da 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -120,7 +120,7 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr, uns
 
 #ifndef arch_vmap_pte_range_unmap_size
 static inline unsigned long arch_vmap_pte_range_unmap_size(unsigned long addr,
-							   pte_t *ptep)
+							   hw_pte_t *ptep)
 {
 	return PAGE_SIZE;
 }
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index ad384969e2cb2..1972d50b043a5 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -138,10 +138,10 @@ TRACE_EVENT(xen_mc_extend_args,
 TRACE_DEFINE_SIZEOF(pteval_t);
 
 TRACE_EVENT(xen_mmu_set_pte,
-	    TP_PROTO(pte_t *ptep, pte_t pteval),
+	    TP_PROTO(hw_pte_t *ptep, pte_t pteval),
 	    TP_ARGS(ptep, pteval),
 	    TP_STRUCT__entry(
-		    __field(pte_t *, ptep)
+		    __field(hw_pte_t *, ptep)
 		    __field(pteval_t, pteval)
 		    ),
 	    TP_fast_assign(__entry->ptep = ptep;
@@ -207,12 +207,12 @@ TRACE_EVENT(xen_mmu_set_p4d,
 
 DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot,
 	    TP_PROTO(struct mm_struct *mm, unsigned long addr,
-		     pte_t *ptep, pte_t pteval),
+		     hw_pte_t *ptep, pte_t pteval),
 	    TP_ARGS(mm, addr, ptep, pteval),
 	    TP_STRUCT__entry(
 		    __field(struct mm_struct *, mm)
 		    __field(unsigned long, addr)
-		    __field(pte_t *, ptep)
+		    __field(hw_pte_t *, ptep)
 		    __field(pteval_t, pteval)
 		    ),
 	    TP_fast_assign(__entry->mm = mm;
@@ -227,7 +227,7 @@ DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot,
 #define DEFINE_XEN_MMU_PTEP_MODIFY_PROT(name)				\
 	DEFINE_EVENT(xen_mmu_ptep_modify_prot, name,			\
 		     TP_PROTO(struct mm_struct *mm, unsigned long addr,	\
-			      pte_t *ptep, pte_t pteval),		\
+			      hw_pte_t *ptep, pte_t pteval),		\
 		     TP_ARGS(mm, addr, ptep, pteval))
 
 DEFINE_XEN_MMU_PTEP_MODIFY_PROT(xen_mmu_ptep_modify_prot_start);
diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
index 80b7b8a694464..c554c07b15592 100644
--- a/kernel/bpf/arena.c
+++ b/kernel/bpf/arena.c
@@ -153,7 +153,7 @@ struct clear_range_data {
 	struct page *scratch_page;
 };
 
-static int apply_range_set_cb(pte_t *pte, unsigned long addr, void *data)
+static int apply_range_set_cb(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	struct apply_range_data *d = data;
 	struct page *page;
@@ -204,7 +204,7 @@ static void flush_vmap_cache(unsigned long start, unsigned long size)
 	flush_cache_vmap(start, start + size);
 }
 
-static int apply_range_clear_cb(pte_t *pte, unsigned long addr, void *data)
+static int apply_range_clear_cb(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	struct clear_range_data *d = data;
 	pte_t old_pte;
@@ -234,7 +234,8 @@ static int apply_range_clear_cb(pte_t *pte, unsigned long addr, void *data)
 	return 0;
 }
 
-static int apply_range_set_scratch_cb(pte_t *pte, unsigned long addr, void *data)
+static int apply_range_set_scratch_cb(hw_pte_t *pte, unsigned long addr,
+				      void *data)
 {
 	struct page *scratch_page = data;
 
@@ -336,7 +337,7 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr)
 	return ERR_PTR(err);
 }
 
-static int existing_page_cb(pte_t *ptep, unsigned long addr, void *data)
+static int existing_page_cb(hw_pte_t *ptep, unsigned long addr, void *data)
 {
 	struct bpf_arena *arena = data;
 	struct page *page;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index cf78e892a4bb0..5413c3919935c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8488,7 +8488,8 @@ static u64 perf_get_pgtable_size(struct mm_struct *mm, unsigned long addr)
 	p4d_t *p4dp, p4d;
 	pud_t *pudp, pud;
 	pmd_t *pmdp, pmd;
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 
 	pgdp = pgd_offset(mm, addr);
 	pgd = pgdp_get(pgdp);
diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
index fbda70d8ea4d0..d7093500fdee4 100644
--- a/mm/damon/ops-common.c
+++ b/mm/damon/ops-common.c
@@ -39,7 +39,7 @@ struct folio *damon_get_folio(unsigned long pfn)
 	return folio;
 }
 
-void damon_ptep_mkold(pte_t *pte, struct vm_area_struct *vma, unsigned long addr)
+void damon_ptep_mkold(hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr)
 {
 	pte_t pteval = ptep_get(pte);
 	struct folio *folio;
diff --git a/mm/damon/ops-common.h b/mm/damon/ops-common.h
index 38d295488fa18..34b7e5715fcf9 100644
--- a/mm/damon/ops-common.h
+++ b/mm/damon/ops-common.h
@@ -7,7 +7,7 @@
 
 struct folio *damon_get_folio(unsigned long pfn);
 
-void damon_ptep_mkold(pte_t *pte, struct vm_area_struct *vma, unsigned long addr);
+void damon_ptep_mkold(hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr);
 void damon_pmdp_mkold(pmd_t *pmd, struct vm_area_struct *vma, unsigned long addr);
 void damon_folio_mkold(struct folio *folio);
 bool damon_folio_young(struct folio *folio);
diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
index 0648400b2d65b..e32b914720d5c 100644
--- a/mm/damon/vaddr.c
+++ b/mm/damon/vaddr.c
@@ -268,7 +268,7 @@ static void damon_va_walk_page_range(struct mm_struct *mm, unsigned long start,
 static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr,
 		unsigned long next, struct mm_walk *walk)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 	spinlock_t *ptl;
 
 	ptl = pmd_trans_huge_lock(pmd, walk->vma);
@@ -293,7 +293,7 @@ static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr,
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
-static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm,
+static void damon_hugetlb_mkold(hw_pte_t *pte, struct mm_struct *mm,
 				struct vm_area_struct *vma, unsigned long addr)
 {
 	bool referenced = false;
@@ -320,7 +320,7 @@ static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm,
 	folio_put(folio);
 }
 
-static int damon_mkold_hugetlb_entry(pte_t *pte, unsigned long hmask,
+static int damon_mkold_hugetlb_entry(hw_pte_t *pte, unsigned long hmask,
 				     unsigned long addr, unsigned long end,
 				     struct mm_walk *walk)
 {
@@ -389,7 +389,7 @@ struct damon_young_walk_private {
 static int damon_young_pmd_entry(pmd_t *pmd, unsigned long addr,
 		unsigned long next, struct mm_walk *walk)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 	pte_t ptent;
 	spinlock_t *ptl;
 	struct folio *folio;
@@ -433,7 +433,7 @@ static int damon_young_pmd_entry(pmd_t *pmd, unsigned long addr,
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
-static int damon_young_hugetlb_entry(pte_t *pte, unsigned long hmask,
+static int damon_young_hugetlb_entry(hw_pte_t *pte, unsigned long hmask,
 				     unsigned long addr, unsigned long end,
 				     struct mm_walk *walk)
 {
@@ -522,7 +522,7 @@ static unsigned int damon_va_check_accesses(struct damon_ctx *ctx)
 
 static bool damos_va_filter_young_match(struct damos_filter *filter,
 		struct folio *folio, struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, pmd_t *pmdp)
+		unsigned long addr, hw_pte_t *ptep, pmd_t *pmdp)
 {
 	bool young = false;
 
@@ -544,7 +544,7 @@ static bool damos_va_filter_young_match(struct damos_filter *filter,
 
 static bool damos_va_filter_out(struct damos *scheme, struct folio *folio,
 		struct vm_area_struct *vma, unsigned long addr,
-		pte_t *ptep, pmd_t *pmdp)
+		hw_pte_t *ptep, pmd_t *pmdp)
 {
 	struct damos_filter *filter;
 	bool matched;
@@ -641,7 +641,8 @@ static int damos_va_migrate_pmd_entry(pmd_t *pmd, unsigned long addr,
 	struct damos_migrate_dests *dests = &s->migrate_dests;
 	struct folio *folio;
 	spinlock_t *ptl;
-	pte_t *start_pte, *pte, ptent;
+	hw_pte_t *start_pte, *pte;
+	pte_t ptent;
 	int nr;
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
@@ -801,7 +802,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr,
 	struct vm_area_struct *vma = walk->vma;
 	struct folio *folio;
 	spinlock_t *ptl;
-	pte_t *start_pte, *pte, ptent;
+	hw_pte_t *start_pte, *pte;
+	pte_t ptent;
 	int nr;
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 2875fd22d7bb0..54e194d2a5854 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -50,7 +50,7 @@ struct pgtable_debug_args {
 	p4d_t			*p4dp;
 	pud_t			*pudp;
 	pmd_t			*pmdp;
-	pte_t			*ptep;
+	hw_pte_t		*ptep;
 
 	p4d_t			*start_p4dp;
 	pud_t			*start_pudp;
diff --git a/mm/filemap.c b/mm/filemap.c
index 6afec636881fb..636fcc0add26c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3490,7 +3490,7 @@ static vm_fault_t filemap_fault_recheck_pte_none(struct vm_fault *vmf)
 {
 	struct vm_area_struct *vma = vmf->vma;
 	vm_fault_t ret = 0;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 
 	/*
 	 * We might have COW'ed a pagecache folio and might now have an mlocked
@@ -3796,7 +3796,7 @@ static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf,
 	vm_fault_t ret = 0;
 	struct page *page = folio_page(folio, start);
 	unsigned int count = 0;
-	pte_t *old_ptep = vmf->pte;
+	hw_pte_t *old_ptep = vmf->pte;
 	unsigned long addr0;
 
 	/*
diff --git a/mm/gup.c b/mm/gup.c
index d110f30d9bf42..c7eb459b29375 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -761,7 +761,7 @@ static struct page *follow_huge_pmd(struct vm_area_struct *vma,
 #endif	/* CONFIG_PGTABLE_HAS_HUGE_LEAVES */
 
 static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
-		pte_t *pte, unsigned int flags)
+		hw_pte_t *pte, unsigned int flags)
 {
 	if (flags & FOLL_TOUCH) {
 		pte_t orig_entry = ptep_get(pte);
@@ -806,7 +806,8 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
 	struct folio *folio;
 	struct page *page;
 	spinlock_t *ptl;
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 	int ret;
 
 	ptep = pte_offset_map_lock(mm, pmd, address, &ptl);
@@ -1035,7 +1036,7 @@ static int get_gate_page(struct mm_struct *mm, unsigned long address,
 	p4d_t *p4d;
 	pud_t *pud;
 	pmd_t *pmd;
-	pte_t *pte;
+	hw_pte_t *pte;
 	pte_t entry;
 	int ret = -EFAULT;
 
@@ -2849,7 +2850,7 @@ static int gup_fast_pte_range(pmd_t pmd, pmd_t *pmdp, unsigned long addr,
 		int *nr)
 {
 	int ret = 0;
-	pte_t *ptep, *ptem;
+	hw_pte_t *ptep, *ptem;
 
 	ptem = ptep = pte_offset_map(&pmd, addr);
 	if (!ptep)
diff --git a/mm/highmem.c b/mm/highmem.c
index a33e411839517..87f94cac6106b 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -141,7 +141,7 @@ EXPORT_SYMBOL(__totalhigh_pages);
 static int pkmap_count[LAST_PKMAP];
 static  __cacheline_aligned_in_smp DEFINE_SPINLOCK(kmap_lock);
 
-pte_t *pkmap_page_table;
+hw_pte_t *pkmap_page_table;
 
 /*
  * Most architectures have no use for kmap_high_get(), so let's abstract
@@ -532,9 +532,9 @@ static inline bool kmap_high_unmap_local(unsigned long vaddr)
 	return false;
 }
 
-static pte_t *__kmap_pte;
+static hw_pte_t *__kmap_pte;
 
-static pte_t *kmap_get_pte(unsigned long vaddr, int idx)
+static hw_pte_t *kmap_get_pte(unsigned long vaddr, int idx)
 {
 	if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY))
 		/*
@@ -549,8 +549,9 @@ static pte_t *kmap_get_pte(unsigned long vaddr, int idx)
 
 void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot)
 {
-	pte_t pteval, *kmap_pte;
 	unsigned long vaddr;
+	hw_pte_t *kmap_pte;
+	pte_t pteval;
 	int idx;
 
 	/*
@@ -597,7 +598,7 @@ EXPORT_SYMBOL(__kmap_local_page_prot);
 void kunmap_local_indexed(const void *vaddr)
 {
 	unsigned long addr = (unsigned long) vaddr & PAGE_MASK;
-	pte_t *kmap_pte;
+	hw_pte_t *kmap_pte;
 	int idx;
 
 	if (addr < __fix_to_virt(FIX_KMAP_END) ||
@@ -646,7 +647,7 @@ EXPORT_SYMBOL(kunmap_local_indexed);
 void __kmap_local_sched_out(void)
 {
 	struct task_struct *tsk = current;
-	pte_t *kmap_pte;
+	hw_pte_t *kmap_pte;
 	int i;
 
 	/* Clear kmaps */
@@ -683,7 +684,7 @@ void __kmap_local_sched_out(void)
 void __kmap_local_sched_in(void)
 {
 	struct task_struct *tsk = current;
-	pte_t *kmap_pte;
+	hw_pte_t *kmap_pte;
 	int i;
 
 	/* Restore kmaps */
diff --git a/mm/hmm.c b/mm/hmm.c
index 2b05c53b82dc3..56208cd603c2a 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -240,7 +240,7 @@ static inline unsigned long pte_to_hmm_pfn_flags(struct hmm_range *range,
 }
 
 static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr,
-			      unsigned long end, pmd_t *pmdp, pte_t *ptep,
+			      unsigned long end, pmd_t *pmdp, hw_pte_t *ptep,
 			      unsigned long *hmm_pfn)
 {
 	struct hmm_vma_walk *hmm_vma_walk = walk->private;
@@ -411,7 +411,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
 		&range->hmm_pfns[(start - range->start) >> PAGE_SHIFT];
 	unsigned long npages = (end - start) >> PAGE_SHIFT;
 	unsigned long addr = start;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pmd_t pmd;
 
 again:
@@ -547,7 +547,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long start, unsigned long end,
 #endif
 
 #ifdef CONFIG_HUGETLB_PAGE
-static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned long hmask,
+static int hmm_vma_walk_hugetlb_entry(hw_pte_t *pte, unsigned long hmask,
 				      unsigned long start, unsigned long end,
 				      struct mm_walk *walk)
 {
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 804b8f6aa5570..6a68739fffe06 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3099,7 +3099,7 @@ static void __split_huge_zero_page_pmd(struct vm_area_struct *vma,
 	pgtable_t pgtable;
 	pmd_t _pmd, old_pmd;
 	unsigned long addr;
-	pte_t *pte;
+	hw_pte_t *pte;
 	int i;
 
 	/*
@@ -3149,7 +3149,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
 	bool soft_dirty, uffd_wp = false, young = false, write = false;
 	bool anon_exclusive = false, dirty = false;
 	unsigned long addr;
-	pte_t *pte;
+	hw_pte_t *pte;
 	int i;
 
 	VM_BUG_ON(haddr & ~HPAGE_PMD_MASK);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index e6a210920637d..c954b60dfbdd4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -120,7 +120,7 @@ static void hugetlb_vma_lock_free(struct vm_area_struct *vma);
 static void hugetlb_vma_lock_alloc(struct vm_area_struct *vma);
 static void __hugetlb_vma_unlock_write_free(struct vm_area_struct *vma);
 static int __huge_pmd_unshare(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep,
+		struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep,
 		bool check_locks);
 static void hugetlb_unshare_pmds(struct vm_area_struct *vma,
 		unsigned long start, unsigned long end, bool take_locks);
@@ -4852,7 +4852,7 @@ static pte_t make_huge_pte(struct vm_area_struct *vma, struct folio *folio,
 }
 
 static void set_huge_ptep_writable(struct vm_area_struct *vma,
-				   unsigned long address, pte_t *ptep)
+				   unsigned long address, hw_pte_t *ptep)
 {
 	pte_t entry;
 
@@ -4862,14 +4862,14 @@ static void set_huge_ptep_writable(struct vm_area_struct *vma,
 }
 
 static void set_huge_ptep_maybe_writable(struct vm_area_struct *vma,
-					 unsigned long address, pte_t *ptep)
+					 unsigned long address, hw_pte_t *ptep)
 {
 	if (vma->vm_flags & VM_WRITE)
 		set_huge_ptep_writable(vma, address, ptep);
 }
 
 static void
-hugetlb_install_folio(struct vm_area_struct *vma, pte_t *ptep, unsigned long addr,
+hugetlb_install_folio(struct vm_area_struct *vma, hw_pte_t *ptep, unsigned long addr,
 		      struct folio *new_folio, pte_t old, unsigned long sz)
 {
 	pte_t newpte = make_huge_pte(vma, new_folio, true);
@@ -4895,7 +4895,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
 			    struct vm_area_struct *dst_vma,
 			    struct vm_area_struct *src_vma)
 {
-	pte_t *src_pte, *dst_pte, entry;
+	hw_pte_t *src_pte, *dst_pte;
+	pte_t entry;
 	struct folio *pte_folio;
 	unsigned long addr;
 	bool cow = is_cow_mapping(src_vma->vm_flags);
@@ -5087,7 +5088,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
 }
 
 static void move_huge_pte(struct vm_area_struct *vma, unsigned long old_addr,
-			  unsigned long new_addr, pte_t *src_pte, pte_t *dst_pte,
+			  unsigned long new_addr, hw_pte_t *src_pte,
+			  hw_pte_t *dst_pte,
 			  unsigned long sz)
 {
 	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
@@ -5149,7 +5151,7 @@ int move_hugetlb_page_tables(struct vm_area_struct *vma,
 	struct mm_struct *mm = vma->vm_mm;
 	unsigned long old_end = old_addr + len;
 	unsigned long last_addr_mask;
-	pte_t *src_pte, *dst_pte;
+	hw_pte_t *src_pte, *dst_pte;
 	struct mmu_notifier_range range;
 	struct mmu_gather tlb;
 
@@ -5210,7 +5212,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
 	struct mm_struct *mm = vma->vm_mm;
 	const bool folio_provided = !!folio;
 	unsigned long address;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pte_t pte;
 	spinlock_t *ptl;
 	struct hstate *h = hstate_vma(vma);
@@ -5744,7 +5746,7 @@ static inline vm_fault_t hugetlb_handle_userfault(struct vm_fault *vmf,
  * false if pte changed or is changing.
  */
 static bool hugetlb_pte_stable(struct hstate *h, struct mm_struct *mm, unsigned long addr,
-			       pte_t *ptep, pte_t old_pte)
+			       hw_pte_t *ptep, pte_t old_pte)
 {
 	spinlock_t *ptl;
 	bool same;
@@ -6269,7 +6271,7 @@ static struct folio *alloc_hugetlb_folio_vma(struct hstate *h,
  * Used by userfaultfd UFFDIO_* ioctls. Based on userfaultfd's mfill_atomic_pte
  * with modifications for hugetlb pages.
  */
-int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
+int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte,
 			     struct vm_area_struct *dst_vma,
 			     unsigned long dst_addr,
 			     unsigned long src_addr,
@@ -6328,7 +6330,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
 
 		folio = alloc_hugetlb_folio(dst_vma, dst_addr, false);
 		if (IS_ERR(folio)) {
-			pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE);
+			hw_pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE);
 			if (actual_pte) {
 				ret = -EEXIST;
 				goto out;
@@ -6496,7 +6498,7 @@ long hugetlb_change_protection(struct vm_area_struct *vma,
 {
 	struct mm_struct *mm = vma->vm_mm;
 	unsigned long start = address;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pte_t pte;
 	struct hstate *h = hstate_vma(vma);
 	long pages = 0, psize = huge_page_size(h);
@@ -6981,15 +6983,15 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
  * racing tasks could either miss the sharing (see huge_pte_offset) or select a
  * bad pmd for sharing.
  */
-pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
+hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
 		      unsigned long addr, pud_t *pud)
 {
 	struct address_space *mapping = vma->vm_file->f_mapping;
 	const pgoff_t idx = linear_page_index(vma, addr);
 	struct vm_area_struct *svma;
 	unsigned long saddr;
-	pte_t *spte = NULL;
-	pte_t *pte;
+	hw_pte_t *spte = NULL;
+	hw_pte_t *pte;
 
 	i_mmap_lock_read(mapping);
 	mapping_rmap_tree_foreach(svma, mapping, idx, idx) {
@@ -7020,13 +7022,13 @@ pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
 	}
 	spin_unlock(&mm->page_table_lock);
 out:
-	pte = (pte_t *)pmd_alloc(mm, pud, addr);
+	pte = (hw_pte_t *)pmd_alloc(mm, pud, addr);
 	i_mmap_unlock_read(mapping);
 	return pte;
 }
 
 static int __huge_pmd_unshare(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep,
+		struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep,
 		bool check_locks)
 {
 	unsigned long sz = huge_page_size(hstate_vma(vma));
@@ -7067,7 +7069,7 @@ static int __huge_pmd_unshare(struct mmu_gather *tlb,
  *	    was not a shared PMD table.
  */
 int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep)
+		unsigned long addr, hw_pte_t *ptep)
 {
 	return __huge_pmd_unshare(tlb, vma, addr, ptep, /*check_locks=*/true);
 }
@@ -7097,21 +7099,21 @@ void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma)
 
 #else /* !CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */
 
-pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
+hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma,
 		      unsigned long addr, pud_t *pud)
 {
 	return NULL;
 }
 
 static int __huge_pmd_unshare(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep,
+		struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep,
 		bool check_locks)
 {
 	return 0;
 }
 
 int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep)
+		unsigned long addr, hw_pte_t *ptep)
 {
 	return 0;
 }
@@ -7132,13 +7134,13 @@ bool want_pmd_share(struct vm_area_struct *vma, unsigned long addr)
 #endif /* CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */
 
 #ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB
-pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
+hw_pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
 			unsigned long addr, unsigned long sz)
 {
 	pgd_t *pgd;
 	p4d_t *p4d;
 	pud_t *pud;
-	pte_t *pte = NULL;
+	hw_pte_t *pte = NULL;
 
 	pgd = pgd_offset(mm, addr);
 	p4d = p4d_alloc(mm, pgd, addr);
@@ -7147,13 +7149,13 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
 	pud = pud_alloc(mm, p4d, addr);
 	if (pud) {
 		if (sz == PUD_SIZE) {
-			pte = (pte_t *)pud;
+			pte = (hw_pte_t *)pud;
 		} else {
 			BUG_ON(sz != PMD_SIZE);
 			if (want_pmd_share(vma, addr) && pud_none(*pud))
 				pte = huge_pmd_share(mm, vma, addr, pud);
 			else
-				pte = (pte_t *)pmd_alloc(mm, pud, addr);
+				pte = (hw_pte_t *)pmd_alloc(mm, pud, addr);
 		}
 	}
 
@@ -7175,7 +7177,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma,
  * size @sz doesn't match the hugepage size at this level of the page
  * table.
  */
-pte_t *huge_pte_offset(struct mm_struct *mm,
+hw_pte_t *huge_pte_offset(struct mm_struct *mm,
 		       unsigned long addr, unsigned long sz)
 {
 	pgd_t *pgd;
@@ -7193,14 +7195,14 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
 	pud = pud_offset(p4d, addr);
 	if (sz == PUD_SIZE)
 		/* must be pud huge, non-present or none */
-		return (pte_t *)pud;
+		return (hw_pte_t *)pud;
 	if (!pud_present(*pud))
 		return NULL;
 	/* must have a valid entry and size to go further */
 
 	pmd = pmd_offset(pud, addr);
 	/* must be pmd huge, non-present or none */
-	return (pte_t *)pmd;
+	return (hw_pte_t *)pmd;
 }
 
 /*
@@ -7379,7 +7381,7 @@ static void hugetlb_unshare_pmds(struct vm_area_struct *vma,
 	struct mmu_gather tlb;
 	unsigned long address;
 	spinlock_t *ptl;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 
 	if (!(vma->vm_flags & VM_MAYSHARE))
 		return;
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 917db0984143c..2850c19c45287 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -33,7 +33,7 @@
  *			operations.
  */
 struct vmemmap_remap_walk {
-	void			(*remap_pte)(pte_t *pte, unsigned long addr,
+	void			(*remap_pte)(hw_pte_t *pte, unsigned long addr,
 					     struct vmemmap_remap_walk *walk);
 
 	unsigned long		nr_walked;
@@ -55,7 +55,7 @@ static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start,
 	pmd_t __pmd;
 	int i;
 	unsigned long addr = start;
-	pte_t *pgtable;
+	hw_pte_t *pgtable;
 
 	pgtable = pte_alloc_one_kernel(&init_mm);
 	if (!pgtable)
@@ -64,7 +64,8 @@ static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start,
 	pmd_populate_kernel(&init_mm, &__pmd, pgtable);
 
 	for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) {
-		pte_t entry, *pte;
+		pte_t entry;
+		hw_pte_t *pte;
 		pgprot_t pgprot = PAGE_KERNEL;
 
 		entry = mk_pte(head + i, pgprot);
@@ -136,7 +137,7 @@ static int vmemmap_pmd_entry(pmd_t *pmd, unsigned long addr,
 	return vmemmap_split_pmd(pmd, head, addr & PMD_MASK, vmemmap_walk);
 }
 
-static int vmemmap_pte_entry(pte_t *pte, unsigned long addr,
+static int vmemmap_pte_entry(hw_pte_t *pte, unsigned long addr,
 			     unsigned long next, struct mm_walk *walk)
 {
 	struct vmemmap_remap_walk *vmemmap_walk = walk->private;
@@ -198,7 +199,7 @@ static void free_vmemmap_page_list(struct list_head *list)
 		free_vmemmap_page(page);
 }
 
-static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
+static void vmemmap_remap_pte(hw_pte_t *pte, unsigned long addr,
 			      struct vmemmap_remap_walk *walk)
 {
 	struct page *page = pte_page(ptep_get(pte));
@@ -232,7 +233,7 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
 	set_pte_at(&init_mm, addr, pte, entry);
 }
 
-static void vmemmap_restore_pte(pte_t *pte, unsigned long addr,
+static void vmemmap_restore_pte(hw_pte_t *pte, unsigned long addr,
 				struct vmemmap_remap_walk *walk)
 {
 	struct page *src = pte_page(ptep_get(pte)), *dst;
diff --git a/mm/internal.h b/mm/internal.h
index f47f06c555481..46039190db8bf 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -278,7 +278,7 @@ void unmap_vmas(struct mmu_gather *tlb, struct unmap_desc *unmap);
 #ifdef CONFIG_MMU
 
 bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, pte_t pte,
+		unsigned long addr, hw_pte_t *ptep, pte_t pte,
 		unsigned long nr_ptes);
 
 static inline void get_anon_vma(struct anon_vma *anon_vma)
@@ -414,7 +414,7 @@ static inline pte_t __pte_batch_clear_ignored(pte_t pte, fpb_t flags)
  * Return: the number of table entries in the batch.
  */
 static inline unsigned int folio_pte_batch_flags(struct folio *folio,
-		struct vm_area_struct *vma, pte_t *ptep, pte_t *ptentp,
+		struct vm_area_struct *vma, hw_pte_t *ptep, pte_t *ptentp,
 		unsigned int max_nr, fpb_t flags)
 {
 	bool any_writable = false, any_young = false, any_dirty = false;
@@ -468,7 +468,7 @@ static inline unsigned int folio_pte_batch_flags(struct folio *folio,
 	return min(nr, max_nr);
 }
 
-unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte,
+unsigned int folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte,
 		unsigned int max_nr);
 
 /**
@@ -525,11 +525,11 @@ static inline pte_t pte_next_swp_offset(pte_t pte)
  *
  * Return: the number of table entries in the batch.
  */
-static inline int swap_pte_batch(pte_t *start_ptep, int max_nr, pte_t pte)
+static inline int swap_pte_batch(hw_pte_t *start_ptep, int max_nr, pte_t pte)
 {
 	pte_t expected_pte = pte_next_swp_offset(pte);
-	const pte_t *end_ptep = start_ptep + max_nr;
-	pte_t *ptep = start_ptep + 1;
+	const hw_pte_t *end_ptep = start_ptep + max_nr;
+	hw_pte_t *ptep = start_ptep + 1;
 
 	VM_WARN_ON(max_nr < 1);
 	VM_WARN_ON(!softleaf_is_swap(softleaf_from_pte(pte)));
@@ -1569,7 +1569,7 @@ static inline void maybe_rmap_unlock_action(struct vm_area_struct *vma,
 
 #ifdef CONFIG_MMU_NOTIFIER
 static inline bool clear_flush_young_ptes_notify(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, unsigned int nr)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr)
 {
 	bool young;
 
@@ -1590,7 +1590,7 @@ static inline bool pmdp_clear_flush_young_notify(struct vm_area_struct *vma,
 }
 
 static inline bool test_and_clear_young_ptes_notify(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, unsigned int nr)
+		unsigned long addr, hw_pte_t *ptep, unsigned int nr)
 {
 	bool young;
 
diff --git a/mm/kasan/init.c b/mm/kasan/init.c
index 66a8838879876..30c5266eaf37e 100644
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -92,7 +92,7 @@ static __init void *early_alloc(size_t size, int node)
 static void __ref zero_pte_populate(pmd_t *pmd, unsigned long addr,
 				unsigned long end)
 {
-	pte_t *pte = pte_offset_kernel(pmd, addr);
+	hw_pte_t *pte = pte_offset_kernel(pmd, addr);
 	pte_t zero_pte;
 
 	zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_early_shadow_page)),
@@ -122,7 +122,7 @@ static int __ref zero_pmd_populate(pud_t *pud, unsigned long addr,
 		}
 
 		if (pmd_none(*pmd)) {
-			pte_t *p;
+			hw_pte_t *p;
 
 			if (slab_is_available())
 				p = pte_alloc_one_kernel(&init_mm);
@@ -281,9 +281,9 @@ int __ref kasan_populate_early_shadow(const void *shadow_start,
 	return 0;
 }
 
-static void kasan_free_pte(pte_t *pte_start, pmd_t *pmd)
+static void kasan_free_pte(hw_pte_t *pte_start, pmd_t *pmd)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 	int i;
 
 	for (i = 0; i < PTRS_PER_PTE; i++) {
@@ -341,7 +341,7 @@ static void kasan_free_p4d(p4d_t *p4d_start, pgd_t *pgd)
 	pgd_clear(pgd);
 }
 
-static void kasan_remove_pte_table(pte_t *pte, unsigned long addr,
+static void kasan_remove_pte_table(hw_pte_t *pte, unsigned long addr,
 				unsigned long end)
 {
 	unsigned long next;
@@ -369,7 +369,7 @@ static void kasan_remove_pmd_table(pmd_t *pmd, unsigned long addr,
 	unsigned long next;
 
 	for (; addr < end; addr = next, pmd++) {
-		pte_t *pte;
+		hw_pte_t *pte;
 
 		next = pmd_addr_end(addr, end);
 
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index d286e0a045437..86fc7ed45dcd0 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -189,7 +189,7 @@ static bool shadow_mapped(unsigned long addr)
 	p4d_t *p4d;
 	pud_t *pud;
 	pmd_t *pmd;
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	if (pgd_none(*pgd))
 		return false;
@@ -297,7 +297,7 @@ struct vmalloc_populate_data {
 	struct page **pages;
 };
 
-static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
+static int kasan_populate_vmalloc_pte(hw_pte_t *ptep, unsigned long addr,
 				      void *_data)
 {
 	struct vmalloc_populate_data *data = _data;
@@ -465,7 +465,7 @@ int __kasan_populate_vmalloc(unsigned long addr, unsigned long size, gfp_t gfp_m
 	return 0;
 }
 
-static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
+static int kasan_depopulate_vmalloc_pte(hw_pte_t *ptep, unsigned long addr,
 					void *unused)
 {
 	pte_t pte;
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 3338e9dc11dd0..d1a4a40bef9ea 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -665,7 +665,7 @@ static void release_pte_folio(struct folio *folio)
 	folio_putback_lru(folio);
 }
 
-static void release_pte_pages(pte_t *pte, pte_t *_pte,
+static void release_pte_pages(hw_pte_t *pte, hw_pte_t *_pte,
 		struct list_head *compound_pagelist)
 {
 	struct folio *folio, *tmp;
@@ -811,13 +811,14 @@ static enum pte_check_result collapse_check_pte(pte_t pteval,
 }
 
 static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
-		unsigned long start_addr, pte_t *pte, struct collapse_control *cc,
+		unsigned long start_addr, hw_pte_t *pte, struct collapse_control *cc,
 		unsigned int order, struct list_head *compound_pagelist)
 {
 	const unsigned long nr_pages = 1UL << order;
 	struct folio *folio = NULL;
 	unsigned long addr = start_addr;
-	pte_t *_pte, pteval;
+	hw_pte_t *_pte;
+	pte_t pteval;
 	int referenced = 0;
 	enum scan_result result = SCAN_FAIL;
 	enum pte_check_result pte_check;
@@ -929,7 +930,7 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
 	return result;
 }
 
-static void __collapse_huge_page_copy_succeeded(pte_t *pte,
+static void __collapse_huge_page_copy_succeeded(hw_pte_t *pte,
 		struct vm_area_struct *vma, unsigned long address,
 		spinlock_t *ptl, unsigned int order,
 		struct list_head *compound_pagelist)
@@ -938,7 +939,7 @@ static void __collapse_huge_page_copy_succeeded(pte_t *pte,
 	unsigned long end = address + (PAGE_SIZE * nr_pages);
 	struct folio *src, *tmp;
 	pte_t pteval;
-	pte_t *_pte;
+	hw_pte_t *_pte;
 	unsigned int nr_ptes;
 
 	for (_pte = pte; _pte < pte + nr_pages; _pte += nr_ptes,
@@ -993,7 +994,7 @@ static void __collapse_huge_page_copy_succeeded(pte_t *pte,
 	}
 }
 
-static void __collapse_huge_page_copy_failed(pte_t *pte,
+static void __collapse_huge_page_copy_failed(hw_pte_t *pte,
 		pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma,
 		unsigned int order, struct list_head *compound_pagelist)
 {
@@ -1031,7 +1032,7 @@ static void __collapse_huge_page_copy_failed(pte_t *pte,
  * @ptl: lock on raw pages' PTEs
  * @compound_pagelist: list that stores compound pages
  */
-static enum scan_result __collapse_huge_page_copy(pte_t *pte, struct folio *folio,
+static enum scan_result __collapse_huge_page_copy(hw_pte_t *pte, struct folio *folio,
 		pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma,
 		unsigned long address, spinlock_t *ptl, unsigned int order,
 		struct list_head *compound_pagelist)
@@ -1253,7 +1254,7 @@ static enum scan_result __collapse_huge_page_swapin(struct mm_struct *mm,
 	vm_fault_t ret = 0;
 	unsigned long addr, end = start_addr + (PAGE_SIZE << order);
 	enum scan_result result;
-	pte_t *pte = NULL;
+	hw_pte_t *pte = NULL;
 	spinlock_t *ptl;
 
 	for (addr = start_addr; addr < end; addr += PAGE_SIZE) {
@@ -1381,7 +1382,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
 	const unsigned long end_addr = start_addr + (PAGE_SIZE << order);
 	LIST_HEAD(compound_pagelist);
 	pmd_t *pmd, _pmd;
-	pte_t *pte = NULL;
+	hw_pte_t *pte = NULL;
 	pgtable_t pgtable;
 	struct folio *folio;
 	spinlock_t *pmd_ptl, *pte_ptl;
@@ -1692,7 +1693,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
 {
 	enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
 	pmd_t *pmd;
-	pte_t *pte, *_pte, pteval;
+	hw_pte_t *pte, *_pte;
+	pte_t pteval;
 	int i;
 	struct folio *folio = NULL;
 	int referenced = 0;
@@ -1887,7 +1889,7 @@ static enum scan_result try_collapse_pte_mapped_thp(struct mm_struct *mm, unsign
 	unsigned long end = haddr + HPAGE_PMD_SIZE;
 	struct vm_area_struct *vma = vma_lookup(mm, haddr);
 	struct folio *folio;
-	pte_t *start_pte, *pte;
+	hw_pte_t *start_pte, *pte;
 	pmd_t *pmd, pgt_pmd;
 	spinlock_t *pml = NULL, *ptl;
 	int i;
diff --git a/mm/ksm.c b/mm/ksm.c
index 11d50518d02e9..744024cc5bf02 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -618,7 +618,7 @@ static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long en
 {
 	unsigned long *found_addr = (unsigned long *) walk->private;
 	struct mm_struct *mm = walk->mm;
-	pte_t *start_ptep, *ptep;
+	hw_pte_t *start_ptep, *ptep;
 	spinlock_t *ptl;
 	int found = 0;
 
@@ -1399,7 +1399,7 @@ static int replace_page(struct vm_area_struct *vma, struct page *page,
 	struct folio *folio = page_folio(page);
 	pmd_t *pmd;
 	pmd_t pmde;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pte_t newpte;
 	spinlock_t *ptl;
 	unsigned long addr;
@@ -2531,7 +2531,8 @@ static int ksm_next_page_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned lon
 {
 	struct ksm_next_page_arg *private = walk->private;
 	struct vm_area_struct *vma = walk->vma;
-	pte_t *start_ptep = NULL, *ptep, pte;
+	hw_pte_t *start_ptep = NULL, *ptep;
+	pte_t pte;
 	struct mm_struct *mm = walk->mm;
 	struct folio *folio;
 	struct page *page;
diff --git a/mm/madvise.c b/mm/madvise.c
index c324cc991f841..6f99cef91b6bd 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -189,7 +189,7 @@ static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start,
 {
 	struct vm_area_struct *vma = walk->private;
 	struct swap_io_ctx ctx = {};
-	pte_t *ptep = NULL;
+	hw_pte_t *ptep = NULL;
 	spinlock_t *ptl;
 	unsigned long addr;
 
@@ -341,7 +341,7 @@ static inline bool can_do_file_pageout(struct vm_area_struct *vma)
 }
 
 static inline int madvise_folio_pte_batch(unsigned long addr, unsigned long end,
-					  struct folio *folio, pte_t *ptep,
+					  struct folio *folio, hw_pte_t *ptep,
 					  pte_t *ptentp)
 {
 	int max_nr = (end - addr) / PAGE_SIZE;
@@ -359,7 +359,8 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	bool pageout = private->pageout;
 	struct mm_struct *mm = tlb->mm;
 	struct vm_area_struct *vma = walk->vma;
-	pte_t *start_pte, *pte, ptent;
+	hw_pte_t *start_pte, *pte;
+	pte_t ptent;
 	spinlock_t *ptl;
 	struct folio *folio = NULL;
 	LIST_HEAD(folio_list);
@@ -658,7 +659,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	struct mm_struct *mm = tlb->mm;
 	struct vm_area_struct *vma = walk->vma;
 	spinlock_t *ptl;
-	pte_t *start_pte, *pte, ptent;
+	hw_pte_t *start_pte, *pte;
+	pte_t ptent;
 	struct folio *folio;
 	int nr_swap = 0;
 	unsigned long next;
@@ -1083,7 +1085,7 @@ static int guard_install_pmd_entry(pmd_t *pmd, unsigned long addr,
 	return pmd_trans_huge(pmdval);
 }
 
-static int guard_install_pte_entry(pte_t *pte, unsigned long addr,
+static int guard_install_pte_entry(hw_pte_t *pte, unsigned long addr,
 				   unsigned long next, struct mm_walk *walk)
 {
 	pte_t pteval = ptep_get(pte);
@@ -1226,7 +1228,7 @@ static int guard_remove_pmd_entry(pmd_t *pmd, unsigned long addr,
 	return 0;
 }
 
-static int guard_remove_pte_entry(pte_t *pte, unsigned long addr,
+static int guard_remove_pte_entry(hw_pte_t *pte, unsigned long addr,
 				  unsigned long next, struct mm_walk *walk)
 {
 	pte_t ptent = ptep_get(pte);
diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c
index e0efa36e0a076..dcbd39912f819 100644
--- a/mm/mapping_dirty_helpers.c
+++ b/mm/mapping_dirty_helpers.c
@@ -31,7 +31,7 @@ struct wp_walk {
  * The function write-protects a pte and records the range in
  * virtual address space of touched ptes for efficient range TLB flushes.
  */
-static int wp_pte(pte_t *pte, unsigned long addr, unsigned long end,
+static int wp_pte(hw_pte_t *pte, unsigned long addr, unsigned long end,
 		  struct mm_walk *walk)
 {
 	struct wp_walk *wpwalk = walk->private;
@@ -86,7 +86,7 @@ struct clean_walk {
  * in the address_space, as well as the first and last of the bits
  * touched.
  */
-static int clean_record_pte(pte_t *pte, unsigned long addr,
+static int clean_record_pte(hw_pte_t *pte, unsigned long addr,
 			    unsigned long end, struct mm_walk *walk)
 {
 	struct wp_walk *wpwalk = walk->private;
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index d4d967dd08ea1..f45bd3d1f0dd8 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -342,7 +342,7 @@ static unsigned long dev_pagemap_mapping_shift(struct vm_area_struct *vma,
 	p4d_t *p4d;
 	pud_t *pud;
 	pmd_t *pmd;
-	pte_t *pte;
+	hw_pte_t *pte;
 	pte_t ptent;
 
 	VM_BUG_ON_VMA(address == -EFAULT, vma);
@@ -742,7 +742,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr,
 {
 	struct hwpoison_walk *hwp = walk->private;
 	int ret = 0;
-	pte_t *ptep, *mapped_pte;
+	hw_pte_t *ptep, *mapped_pte;
 	spinlock_t *ptl;
 
 	ptl = pmd_trans_huge_lock(pmdp, walk->vma);
@@ -770,7 +770,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr,
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
-static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask,
+static int hwpoison_hugetlb_range(hw_pte_t *ptep, unsigned long hmask,
 			    unsigned long addr, unsigned long end,
 			    struct mm_walk *walk)
 {
diff --git a/mm/memory.c b/mm/memory.c
index b735fbf5e323c..c5b54d98e5635 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -462,7 +462,7 @@ int __pte_alloc(struct mm_struct *mm, pmd_t *pmd)
 
 int __pte_alloc_kernel(pmd_t *pmd)
 {
-	pte_t *new = pte_alloc_one_kernel(&init_mm);
+	hw_pte_t *new = pte_alloc_one_kernel(&init_mm);
 	if (!new)
 		return -ENOMEM;
 
@@ -941,7 +941,7 @@ struct page *vm_normal_page_pud(struct vm_area_struct *vma,
  */
 static void restore_exclusive_pte(struct vm_area_struct *vma,
 		struct folio *folio, struct page *page, unsigned long address,
-		pte_t *ptep, pte_t orig_pte)
+		hw_pte_t *ptep, pte_t orig_pte)
 {
 	pte_t pte;
 
@@ -978,7 +978,7 @@ static void restore_exclusive_pte(struct vm_area_struct *vma,
  * sleeping.
  */
 static int try_restore_exclusive_pte(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, pte_t orig_pte)
+		unsigned long addr, hw_pte_t *ptep, pte_t orig_pte)
 {
 	const softleaf_t entry = softleaf_from_pte(orig_pte);
 	struct page *page = softleaf_to_page(entry);
@@ -1001,7 +1001,7 @@ static int try_restore_exclusive_pte(struct vm_area_struct *vma,
 
 static unsigned long
 copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
-		pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct *dst_vma,
+		hw_pte_t *dst_pte, hw_pte_t *src_pte, struct vm_area_struct *dst_vma,
 		struct vm_area_struct *src_vma, unsigned long addr, int *rss)
 {
 	vm_flags_t vm_flags = dst_vma->vm_flags;
@@ -1116,7 +1116,7 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
  */
 static inline int
 copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
-		  pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
+		  hw_pte_t *dst_pte, hw_pte_t *src_pte, unsigned long addr, int *rss,
 		  struct folio **prealloc, struct page *page)
 {
 	struct folio *new_folio;
@@ -1155,7 +1155,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
 }
 
 static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma,
-		struct vm_area_struct *src_vma, pte_t *dst_pte, pte_t *src_pte,
+		struct vm_area_struct *src_vma, hw_pte_t *dst_pte, hw_pte_t *src_pte,
 		pte_t pte, unsigned long addr, int nr)
 {
 	struct mm_struct *src_mm = src_vma->vm_mm;
@@ -1205,7 +1205,7 @@ static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma,
  */
 static inline int
 copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
-		 pte_t *dst_pte, pte_t *src_pte, pte_t pte, unsigned long addr,
+		 hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t pte, unsigned long addr,
 		 int max_nr, int *rss, struct folio **prealloc)
 {
 	fpb_t flags = FPB_MERGE_WRITE;
@@ -1305,8 +1305,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
 {
 	struct mm_struct *dst_mm = dst_vma->vm_mm;
 	struct mm_struct *src_mm = src_vma->vm_mm;
-	pte_t *orig_src_pte, *orig_dst_pte;
-	pte_t *src_pte, *dst_pte;
+	hw_pte_t *orig_src_pte, *orig_dst_pte;
+	hw_pte_t *src_pte, *dst_pte;
 	pmd_t dummy_pmdval;
 	pte_t ptent;
 	spinlock_t *src_ptl, *dst_ptl;
@@ -1699,7 +1699,7 @@ static inline bool zap_drop_markers(struct zap_details *details)
  * Returns true if uffd-wp PTEs were installed, false otherwise.
  */
 bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, pte_t pte,
+		unsigned long addr, hw_pte_t *ptep, pte_t pte,
 		unsigned long nr_ptes)
 {
 	bool arm_uffd_pte = false;
@@ -1753,7 +1753,7 @@ bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma,
  */
 static inline bool
 zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
-			      unsigned long addr, pte_t *pte, int nr,
+			      unsigned long addr, hw_pte_t *pte, int nr,
 			      struct zap_details *details, pte_t pteval)
 {
 	if (zap_drop_markers(details))
@@ -1764,7 +1764,7 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma,
 
 static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
 		struct vm_area_struct *vma, struct folio *folio,
-		struct page *page, pte_t *pte, pte_t ptent, unsigned int nr,
+		struct page *page, hw_pte_t *pte, pte_t ptent, unsigned int nr,
 		unsigned long addr, struct zap_details *details, int *rss,
 		bool *force_flush, bool *force_break, bool *any_skipped)
 {
@@ -1814,7 +1814,7 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
  * Returns the number of processed (skipped or zapped) PTEs (at least 1).
  */
 static inline int zap_present_ptes(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, pte_t *pte, pte_t ptent,
+		struct vm_area_struct *vma, hw_pte_t *pte, pte_t ptent,
 		unsigned int max_nr, unsigned long addr,
 		struct zap_details *details, int *rss, bool *force_flush,
 		bool *force_break, bool *any_skipped)
@@ -1860,7 +1860,7 @@ static inline int zap_present_ptes(struct mmu_gather *tlb,
 }
 
 static inline int zap_nonpresent_ptes(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, pte_t *pte, pte_t ptent,
+		struct vm_area_struct *vma, hw_pte_t *pte, pte_t ptent,
 		unsigned int max_nr, unsigned long addr,
 		struct zap_details *details, int *rss, bool *any_skipped)
 {
@@ -1931,7 +1931,7 @@ static inline int zap_nonpresent_ptes(struct mmu_gather *tlb,
 }
 
 static inline int do_zap_pte_range(struct mmu_gather *tlb,
-				   struct vm_area_struct *vma, pte_t *pte,
+				   struct vm_area_struct *vma, hw_pte_t *pte,
 				   unsigned long addr, unsigned long end,
 				   struct zap_details *details, int *rss,
 				   bool *force_flush, bool *force_break,
@@ -1994,7 +1994,7 @@ static bool zap_pte_table_if_empty(struct mm_struct *mm, pmd_t *pmd,
 		unsigned long addr, pmd_t *pmdval)
 {
 	spinlock_t *pml, *ptl = NULL;
-	pte_t *start_pte, *pte;
+	hw_pte_t *start_pte, *pte;
 	int i;
 
 	pml = pmd_lock(mm, pmd);
@@ -2034,8 +2034,8 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
 	struct mm_struct *mm = tlb->mm;
 	int rss[NR_MM_COUNTERS];
 	spinlock_t *ptl;
-	pte_t *start_pte;
-	pte_t *pte;
+	hw_pte_t *start_pte;
+	hw_pte_t *pte;
 	pmd_t pmdval;
 	unsigned long start = addr;
 	bool direct_reclaim = true;
@@ -2417,7 +2417,7 @@ static pmd_t *walk_to_pmd(struct mm_struct *mm, unsigned long addr)
 	return pmd;
 }
 
-pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr,
+hw_pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr,
 		      spinlock_t **ptl)
 {
 	pmd_t *pmd = walk_to_pmd(mm, addr);
@@ -2475,7 +2475,7 @@ static int validate_page_before_insert(struct vm_area_struct *vma,
 	return 0;
 }
 
-static int insert_page_into_pte_locked(struct vm_area_struct *vma, pte_t *pte,
+static int insert_page_into_pte_locked(struct vm_area_struct *vma, hw_pte_t *pte,
 				unsigned long addr, struct page *page,
 				pgprot_t prot, bool mkwrite)
 {
@@ -2520,7 +2520,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr,
 			struct page *page, pgprot_t prot, bool mkwrite)
 {
 	int retval;
-	pte_t *pte;
+	hw_pte_t *pte;
 	spinlock_t *ptl;
 
 	retval = validate_page_before_insert(vma, page);
@@ -2537,7 +2537,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr,
 	return retval;
 }
 
-static int insert_page_in_batch_locked(struct vm_area_struct *vma, pte_t *pte,
+static int insert_page_in_batch_locked(struct vm_area_struct *vma, hw_pte_t *pte,
 			unsigned long addr, struct page *page, pgprot_t prot)
 {
 	int err;
@@ -2555,7 +2555,7 @@ static int insert_pages(struct vm_area_struct *vma, unsigned long addr,
 			struct page **pages, unsigned long *num, pgprot_t prot)
 {
 	pmd_t *pmd = NULL;
-	pte_t *start_pte, *pte;
+	hw_pte_t *start_pte, *pte;
 	spinlock_t *pte_lock;
 	struct mm_struct *const mm = vma->vm_mm;
 	unsigned long curr_page_idx = 0;
@@ -2798,7 +2798,8 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr,
 			unsigned long pfn, pgprot_t prot, bool mkwrite)
 {
 	struct mm_struct *mm = vma->vm_mm;
-	pte_t *pte, entry;
+	hw_pte_t *pte;
+	pte_t entry;
 	spinlock_t *ptl;
 
 	pte = get_locked_pte(mm, addr, &ptl);
@@ -3039,7 +3040,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 			unsigned long addr, unsigned long end,
 			unsigned long pfn, pgprot_t prot)
 {
-	pte_t *pte, *mapped_pte;
+	hw_pte_t *pte, *mapped_pte;
 	spinlock_t *ptl;
 	int err = 0;
 
@@ -3440,7 +3441,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
 				     pte_fn_t fn, void *data, bool create,
 				     pgtbl_mod_mask *mask)
 {
-	pte_t *pte, *mapped_pte;
+	hw_pte_t *pte, *mapped_pte;
 	int err = 0;
 	spinlock_t *ptl;
 
@@ -4743,7 +4744,7 @@ static vm_fault_t handle_pte_marker(struct vm_fault *vmf)
 /*
  * Check if the PTEs within a range are contiguous swap entries.
  */
-static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep, int nr_pages)
+static bool can_swapin_thp(struct vm_fault *vmf, hw_pte_t *ptep, int nr_pages)
 {
 	unsigned long addr;
 	int idx;
@@ -4795,7 +4796,7 @@ static unsigned long thp_swapin_suitable_orders(struct vm_fault *vmf)
 	unsigned long addr;
 	softleaf_t entry;
 	spinlock_t *ptl;
-	pte_t *pte;
+	hw_pte_t *pte;
 	int order;
 
 	/*
@@ -4889,7 +4890,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	int nr_pages;
 	unsigned long page_idx;
 	unsigned long address;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 
 	if (!pte_unmap_same(vmf))
 		goto out;
@@ -5053,7 +5054,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 		unsigned long idx = folio_page_idx(folio, page);
 		unsigned long folio_start = address - idx * PAGE_SIZE;
 		unsigned long folio_end = folio_start + nr * PAGE_SIZE;
-		pte_t *folio_ptep;
+		hw_pte_t *folio_ptep;
 		pte_t folio_pte;
 
 		if (unlikely(folio_start < max(address & PMD_MASK, vma->vm_start)))
@@ -5283,7 +5284,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	return ret;
 }
 
-static bool pte_range_none(pte_t *pte, int nr_pages)
+static bool pte_range_none(hw_pte_t *pte, int nr_pages)
 {
 	int i;
 
@@ -5302,7 +5303,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf)
 	unsigned long orders;
 	struct folio *folio;
 	unsigned long addr;
-	pte_t *pte;
+	hw_pte_t *pte;
 	gfp_t gfp;
 	int order;
 
@@ -5384,7 +5385,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf)
 	return folio_prealloc(vma->vm_mm, vma, vmf->address, true);
 }
 
-void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
+void map_anon_folio_pte_nopf(struct folio *folio, hw_pte_t *pte,
 		struct vm_area_struct *vma, unsigned long addr,
 		bool uffd_wp)
 {
@@ -5405,7 +5406,7 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
 	update_mmu_cache_range(NULL, vma, addr, pte, nr_pages);
 }
 
-static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte,
+static void map_anon_folio_pte_pf(struct folio *folio, hw_pte_t *pte,
 		struct vm_area_struct *vma, unsigned long addr, bool uffd_wp)
 {
 	const unsigned int order = folio_order(folio);
@@ -6190,7 +6191,7 @@ int numa_migrate_check(struct folio *folio, struct vm_fault *vmf,
 }
 
 static void numa_rebuild_single_mapping(struct vm_fault *vmf, struct vm_area_struct *vma,
-					unsigned long fault_addr, pte_t *fault_pte,
+					unsigned long fault_addr, hw_pte_t *fault_pte,
 					bool writable)
 {
 	pte_t pte, old_pte;
@@ -6212,7 +6213,7 @@ static void numa_rebuild_large_mapping(struct vm_fault *vmf, struct vm_area_stru
 	unsigned long start, end, addr = vmf->address;
 	unsigned long addr_start = addr - (nr << PAGE_SHIFT);
 	unsigned long pt_start = ALIGN_DOWN(addr, PMD_SIZE);
-	pte_t *start_ptep;
+	hw_pte_t *start_ptep;
 
 	/* Stay within the VMA and within the page table. */
 	start = max3(addr_start, pt_start, vma->vm_start);
@@ -6974,7 +6975,7 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
 #endif /* __PAGETABLE_PMD_FOLDED */
 
 static inline void pfnmap_args_setup(struct follow_pfnmap_args *args,
-				     spinlock_t *lock, pte_t *ptep,
+				     spinlock_t *lock, hw_pte_t *ptep,
 				     pgprot_t pgprot, unsigned long pfn_base,
 				     unsigned long addr_mask, bool writable,
 				     bool special)
@@ -7043,7 +7044,8 @@ int follow_pfnmap_start(struct follow_pfnmap_args *args)
 	p4d_t *p4dp, p4d;
 	pud_t *pudp, pud;
 	pmd_t *pmdp, pmd;
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 
 	pfnmap_lockdep_assert(vma);
 
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 5720f7f54d942..729a600132386 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -691,7 +691,7 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr,
 	struct folio *folio;
 	struct queue_pages *qp = walk->private;
 	unsigned long flags = qp->flags;
-	pte_t *pte, *mapped_pte;
+	hw_pte_t *pte, *mapped_pte;
 	pte_t ptent;
 	spinlock_t *ptl;
 	int max_nr, nr;
@@ -771,7 +771,7 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr,
 	return 0;
 }
 
-static int queue_folios_hugetlb(pte_t *pte, unsigned long hmask,
+static int queue_folios_hugetlb(hw_pte_t *pte, unsigned long hmask,
 			       unsigned long addr, unsigned long end,
 			       struct mm_walk *walk)
 {
diff --git a/mm/migrate.c b/mm/migrate.c
index b937cbd764808..bc2ca59ecf9cd 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -497,7 +497,7 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd,
 			  unsigned long address)
 {
 	spinlock_t *ptl;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pte_t pte;
 	softleaf_t entry;
 
@@ -528,7 +528,7 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd,
  *
  * This function will release the vma lock before returning.
  */
-void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep)
+void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep)
 {
 	spinlock_t *ptl = huge_pte_lockptr(hstate_vma(vma), vma->vm_mm, ptep);
 	softleaf_t entry;
diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index 9a346162c6881..27c761e433d65 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -254,7 +254,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
 	spinlock_t *ptl;
 	struct folio *fault_folio = migrate->fault_page ?
 		page_folio(migrate->fault_page) : NULL;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 
 again:
 	if (pmd_trans_huge(*pmdp) || !pmd_present(*pmdp)) {
@@ -989,7 +989,7 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate,
 	p4d_t *p4dp;
 	pud_t *pudp;
 	pmd_t *pmdp;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	pte_t orig_pte;
 
 	/* Only allow populating anonymous memory */
diff --git a/mm/mincore.c b/mm/mincore.c
index ff4ac82817683..15454ced345ab 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -24,7 +24,7 @@
 #include "swap.h"
 #include "internal.h"
 
-static int mincore_hugetlb(pte_t *pte, unsigned long hmask, unsigned long addr,
+static int mincore_hugetlb(hw_pte_t *pte, unsigned long hmask, unsigned long addr,
 			unsigned long end, struct mm_walk *walk)
 {
 #ifdef CONFIG_HUGETLB_PAGE
@@ -164,7 +164,7 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 {
 	spinlock_t *ptl;
 	struct vm_area_struct *vma = walk->vma;
-	pte_t *ptep;
+	hw_pte_t *ptep;
 	unsigned char *vec = walk->private;
 	int nr = (end - addr) >> PAGE_SHIFT;
 	int step, i;
diff --git a/mm/mlock.c b/mm/mlock.c
index efa6716e4dfbd..36002b80382a9 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -305,7 +305,7 @@ void munlock_folio(struct folio *folio)
 }
 
 static inline unsigned int folio_mlock_step(struct folio *folio,
-		pte_t *pte, unsigned long addr, unsigned long end)
+		hw_pte_t *pte, unsigned long addr, unsigned long end)
 {
 	unsigned int count = (end - addr) >> PAGE_SHIFT;
 	pte_t ptent = ptep_get(pte);
@@ -353,7 +353,7 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr,
 {
 	struct vm_area_struct *vma = walk->vma;
 	spinlock_t *ptl;
-	pte_t *start_pte, *pte;
+	hw_pte_t *start_pte, *pte;
 	pte_t ptent;
 	struct folio *folio;
 	unsigned int step = 1;
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 2888ee638d872..1d23475e0bb76 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -103,7 +103,7 @@ bool can_change_pte_writable(struct vm_area_struct *vma, unsigned long addr,
 	return can_change_shared_pte_writable(vma, pte);
 }
 
-static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep,
+static int mprotect_folio_pte_batch(struct folio *folio, hw_pte_t *ptep,
 				    pte_t pte, int max_nr_ptes, fpb_t flags)
 {
 	/* No underlying folio, so cannot batch */
@@ -118,7 +118,7 @@ static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep,
 
 /* Set nr_ptes number of ptes, starting from idx */
 static __always_inline void prot_commit_flush_ptes(struct vm_area_struct *vma,
-		unsigned long addr, pte_t *ptep, pte_t oldpte, pte_t ptent,
+		unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent,
 		int nr_ptes, int idx, bool set_write, struct mmu_gather *tlb)
 {
 	/*
@@ -170,7 +170,7 @@ static __always_inline int page_anon_exclusive_batch(int start_idx, int max_len,
  * retrieve sub-batches.
  */
 static __always_inline void commit_anon_folio_batch(struct vm_area_struct *vma,
-		struct folio *folio, struct page *first_page, unsigned long addr, pte_t *ptep,
+		struct folio *folio, struct page *first_page, unsigned long addr, hw_pte_t *ptep,
 		pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb)
 {
 	bool expected_anon_exclusive;
@@ -189,7 +189,7 @@ static __always_inline void commit_anon_folio_batch(struct vm_area_struct *vma,
 }
 
 static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_struct *vma,
-		struct folio *folio, struct page *page, unsigned long addr, pte_t *ptep,
+		struct folio *folio, struct page *page, unsigned long addr, hw_pte_t *ptep,
 		pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb)
 {
 	bool set_write;
@@ -212,7 +212,7 @@ static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_stru
 }
 
 static long change_softleaf_pte(struct vm_area_struct *vma,
-	unsigned long addr, pte_t *pte, pte_t oldpte, unsigned long cp_flags)
+	unsigned long addr, hw_pte_t *pte, pte_t oldpte, unsigned long cp_flags)
 {
 	const bool uffd_prot = cp_flags & (MM_CP_UFFD_WP | MM_CP_UFFD_RWP);
 	const bool uffd_prot_resolve = cp_flags &
@@ -279,7 +279,7 @@ static long change_softleaf_pte(struct vm_area_struct *vma,
 }
 
 static __always_inline void change_present_ptes(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, unsigned long addr, pte_t *ptep,
+		struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep,
 		int nr_ptes, unsigned long end, pgprot_t newprot,
 		struct folio *folio, struct page *page, unsigned long cp_flags)
 {
@@ -332,7 +332,8 @@ static long change_pte_range(struct mmu_gather *tlb,
 		struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr,
 		unsigned long end, pgprot_t newprot, unsigned long cp_flags)
 {
-	pte_t *pte, oldpte;
+	hw_pte_t *pte;
+	pte_t oldpte;
 	spinlock_t *ptl;
 	long pages = 0;
 	bool is_private_single_threaded;
@@ -727,7 +728,7 @@ long change_protection(struct mmu_gather *tlb,
 	return pages;
 }
 
-static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
+static int prot_none_pte_entry(hw_pte_t *pte, unsigned long addr,
 			       unsigned long next, struct mm_walk *walk)
 {
 	return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
@@ -736,7 +737,7 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
-static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
+static int prot_none_hugetlb_entry(hw_pte_t *pte, unsigned long hmask,
 				   unsigned long addr, unsigned long next,
 				   struct mm_walk *walk)
 {
diff --git a/mm/mremap.c b/mm/mremap.c
index 464bed198bf93..ecb90ccee6fdd 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -176,7 +176,7 @@ static pte_t move_soft_dirty_pte(pte_t pte)
 }
 
 static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr,
-		pte_t *ptep, pte_t pte, int max_nr)
+		hw_pte_t *ptep, pte_t pte, int max_nr)
 {
 	struct folio *folio;
 
@@ -200,7 +200,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
 	struct vm_area_struct *vma = pmc->old;
 	bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma);
 	struct mm_struct *mm = vma->vm_mm;
-	pte_t *old_ptep, *new_ptep;
+	hw_pte_t *old_ptep, *new_ptep;
 	pte_t old_pte, pte;
 	pmd_t dummy_pmdval;
 	spinlock_t *old_ptl, *new_ptl;
diff --git a/mm/page_table_check.c b/mm/page_table_check.c
index 6ffc536359cd0..70984b4e3cde3 100644
--- a/mm/page_table_check.c
+++ b/mm/page_table_check.c
@@ -208,7 +208,7 @@ static void page_table_check_pte_flags(pte_t pte)
 }
 
 void __page_table_check_ptes_set(struct mm_struct *mm, unsigned long addr,
-				 pte_t *ptep, pte_t pte, unsigned int nr)
+				 hw_pte_t *ptep, pte_t pte, unsigned int nr)
 {
 	unsigned int i;
 
@@ -279,7 +279,7 @@ void __page_table_check_pte_clear_range(struct mm_struct *mm,
 		return;
 
 	if (!pmd_bad(pmd) && !pmd_leaf(pmd)) {
-		pte_t *ptep = pte_offset_map(&pmd, addr);
+		hw_pte_t *ptep = pte_offset_map(&pmd, addr);
 		unsigned long i;
 
 		if (WARN_ON(!ptep))
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index ed4860c01936c..172addf9e6558 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -26,7 +26,7 @@ static int real_depth(int depth)
 	return depth;
 }
 
-static int walk_pte_range_inner(pte_t *pte, unsigned long addr,
+static int walk_pte_range_inner(hw_pte_t *pte, unsigned long addr,
 				unsigned long end, struct mm_walk *walk)
 {
 	const struct mm_walk_ops *ops = walk->ops;
@@ -61,7 +61,7 @@ static int walk_pte_range_inner(pte_t *pte, unsigned long addr,
 static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			  struct mm_walk *walk)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 	int err = 0;
 	spinlock_t *ptl;
 
@@ -343,7 +343,7 @@ static int walk_hugetlb_range(unsigned long addr, unsigned long end,
 	unsigned long next;
 	unsigned long hmask = huge_page_mask(h);
 	unsigned long sz = huge_page_size(h);
-	pte_t *pte;
+	hw_pte_t *pte;
 	const struct mm_walk_ops *ops = walk->ops;
 	int err = 0;
 
@@ -909,7 +909,8 @@ struct folio *folio_walk_start(struct folio_walk *fw,
 	struct page *page;
 	pud_t *pudp, pud;
 	pmd_t *pmdp, pmd;
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 	spinlock_t *ptl;
 	pgd_t *pgdp;
 	p4d_t *p4dp;
diff --git a/mm/percpu.c b/mm/percpu.c
index a802d72c116fb..fa79a1295c5bf 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -3176,7 +3176,7 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 
 	pmd = pmd_offset(pud, addr);
 	if (!pmd_present(*pmd)) {
-		pte_t *new;
+		hw_pte_t *new;
 
 		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
index b91b1a98029c7..52f286da3eec6 100644
--- a/mm/pgtable-generic.c
+++ b/mm/pgtable-generic.c
@@ -68,7 +68,7 @@ void pmd_clear_bad(pmd_t *pmd)
  * force that call on sun4c so we changed this macro slightly
  */
 int ptep_set_access_flags(struct vm_area_struct *vma,
-			  unsigned long address, pte_t *ptep,
+			  unsigned long address, hw_pte_t *ptep,
 			  pte_t entry, int dirty)
 {
 	int changed = !pte_same(ptep_get(ptep), entry);
@@ -82,7 +82,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
 
 #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
 bool ptep_clear_flush_young(struct vm_area_struct *vma,
-		unsigned long address, pte_t *ptep)
+		unsigned long address, hw_pte_t *ptep)
 {
 	bool young;
 
@@ -95,7 +95,7 @@ bool ptep_clear_flush_young(struct vm_area_struct *vma,
 
 #ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH
 pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address,
-		       pte_t *ptep)
+		       hw_pte_t *ptep)
 {
 	struct mm_struct *mm = (vma)->vm_mm;
 	pte_t pte;
@@ -282,7 +282,7 @@ static unsigned long pmdp_get_lockless_start(void) { return 0; }
 static void pmdp_get_lockless_end(unsigned long irqflags) { }
 #endif
 
-pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp)
+hw_pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp)
 {
 	unsigned long irqflags;
 	pmd_t pmdval;
@@ -308,11 +308,11 @@ pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp)
 	return NULL;
 }
 
-pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
+hw_pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
 				unsigned long addr, spinlock_t **ptlp)
 {
 	pmd_t pmdval;
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	pte = __pte_offset_map(pmd, addr, &pmdval);
 	if (likely(pte))
@@ -320,11 +320,11 @@ pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
 	return pte;
 }
 
-pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd,
+hw_pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd,
 				unsigned long addr, pmd_t *pmdvalp,
 				spinlock_t **ptlp)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	VM_WARN_ON_ONCE(!pmdvalp);
 	pte = __pte_offset_map(pmd, addr, pmdvalp);
@@ -390,12 +390,12 @@ pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd,
  * table, and may not use RCU at all: "outsiders" like khugepaged should avoid
  * pte_offset_map() and co once the vma is detached from mm or mm_users is zero.
  */
-pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd,
+hw_pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd,
 			   unsigned long addr, spinlock_t **ptlp)
 {
 	spinlock_t *ptl;
 	pmd_t pmdval;
-	pte_t *pte;
+	hw_pte_t *pte;
 again:
 	pte = __pte_offset_map(pmd, addr, &pmdval);
 	if (unlikely(!pte))
diff --git a/mm/ptdump.c b/mm/ptdump.c
index 5851096e6f656..376880071ca2a 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -117,7 +117,7 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr,
 	return 0;
 }
 
-static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
+static int ptdump_pte_entry(hw_pte_t *pte, unsigned long addr,
 			    unsigned long next, struct mm_walk *walk)
 {
 	struct ptdump_state *st = walk->private;
diff --git a/mm/rmap.c b/mm/rmap.c
index b917431759ee0..4d19caa5f8c84 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1124,7 +1124,7 @@ static int page_vma_mkclean_one(struct page_vma_mapped_walk *pvmw)
 
 		address = pvmw->address;
 		if (pvmw->pte) {
-			pte_t *pte = pvmw->pte;
+			hw_pte_t *pte = pvmw->pte;
 			pte_t entry = ptep_get(pte);
 
 			/*
@@ -2141,7 +2141,7 @@ static pte_t swp_pte_prepare(swp_entry_t entry, pte_t old_pte,
 
 static bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma,
 		struct folio *folio, struct page *page, unsigned long address,
-		pte_t *ptep, pte_t pteval)
+		hw_pte_t *ptep, pte_t pteval)
 {
 	const bool anon_exclusive = folio_test_anon(folio) &&
 				    PageAnonExclusive(page);
@@ -2176,7 +2176,7 @@ static bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma,
 }
 
 static bool ttu_anon_folio(struct vm_area_struct *vma, struct folio *folio,
-		struct page *page, unsigned long address, pte_t *ptep,
+		struct page *page, unsigned long address, hw_pte_t *ptep,
 		pte_t pteval, unsigned long nr_pages)
 {
 	/*
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 5a2469fb1838c..2bbf7adef511d 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -137,7 +137,7 @@ static void * __meminit altmap_alloc_block_buf(unsigned long size,
 	return __va(__pfn_to_phys(pfn));
 }
 
-void __meminit vmemmap_verify(pte_t *pte, int node,
+void __meminit vmemmap_verify(hw_pte_t *pte, int node,
 				unsigned long start, unsigned long end)
 {
 	unsigned long pfn = pte_pfn(ptep_get(pte));
@@ -148,11 +148,11 @@ void __meminit vmemmap_verify(pte_t *pte, int node,
 			start, end - 1);
 }
 
-static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
+static hw_pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
 				       struct vmem_altmap *altmap,
 				       unsigned long ptpfn, unsigned long flags)
 {
-	pte_t *pte = pte_offset_kernel(pmd, addr);
+	hw_pte_t *pte = pte_offset_kernel(pmd, addr);
 	if (pte_none(ptep_get(pte))) {
 		pte_t entry;
 		void *p;
@@ -243,7 +243,7 @@ static pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node)
 	return pgd;
 }
 
-static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node,
+static hw_pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node,
 					      struct vmem_altmap *altmap,
 					      unsigned long ptpfn,
 					      unsigned long flags)
@@ -252,7 +252,7 @@ static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node,
 	p4d_t *p4d;
 	pud_t *pud;
 	pmd_t *pmd;
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	pgd = vmemmap_pgd_populate(addr, node);
 	if (!pgd)
@@ -281,7 +281,7 @@ static int __meminit vmemmap_populate_range(unsigned long start,
 					    unsigned long flags)
 {
 	unsigned long addr = start;
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	for (; addr < end; addr += PAGE_SIZE) {
 		pte = vmemmap_populate_address(addr, node, altmap,
@@ -314,7 +314,7 @@ void vmemmap_wrprotect_hvo(unsigned long addr, unsigned long end,
 				    int node, unsigned long headsize)
 {
 	unsigned long maddr;
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	for (maddr = addr + headsize; maddr < end; maddr += PAGE_SIZE) {
 		pte = virt_to_kpte(maddr);
@@ -364,7 +364,7 @@ int __meminit vmemmap_populate_hvo(unsigned long addr, unsigned long end,
 {
 	unsigned long maddr;
 	struct page *tail;
-	pte_t *pte;
+	hw_pte_t *pte;
 	int node = zone_to_nid(zone);
 
 	tail = vmemmap_get_tail(order, zone);
@@ -396,7 +396,7 @@ int __weak __meminit vmemmap_check_pmd(pmd_t *pmd, int node,
 {
 	if (!pmd_leaf(pmdp_get(pmd)))
 		return 0;
-	vmemmap_verify((pte_t *)pmd, node, addr, next);
+	vmemmap_verify((hw_pte_t *)pmd, node, addr, next);
 
 	return 1;
 }
@@ -474,9 +474,9 @@ static bool __meminit reuse_compound_section(unsigned long start_pfn,
 	return !IS_ALIGNED(offset, nr_pages) && nr_pages > PAGES_PER_SUBSECTION;
 }
 
-static pte_t * __meminit compound_section_tail_page(unsigned long addr)
+static hw_pte_t * __meminit compound_section_tail_page(unsigned long addr)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	addr -= PAGE_SIZE;
 
@@ -497,7 +497,7 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
 						     struct dev_pagemap *pgmap)
 {
 	unsigned long size, addr;
-	pte_t *pte;
+	hw_pte_t *pte;
 	int rc;
 
 	if (reuse_compound_section(start_pfn, pgmap)) {
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 5be825911e645..cb1b2d434a581 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -917,7 +917,8 @@ static struct folio *swap_vma_readahead(swp_entry_t targ_entry, gfp_t gfp_mask,
 	struct swap_io_ctx ctx = {};
 	struct blk_plug plug;
 	struct folio *folio;
-	pte_t *pte = NULL, pentry;
+	hw_pte_t *pte = NULL;
+	pte_t pentry;
 	int win;
 	unsigned long start, end, addr;
 	pgoff_t ilx = targ_ilx;
diff --git a/mm/swapfile.c b/mm/swapfile.c
index dea2d3b36e06f..9644878c82fec 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2476,7 +2476,8 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd,
 	struct page *page;
 	struct folio *swapcache;
 	spinlock_t *ptl;
-	pte_t *pte, new_pte, old_pte;
+	hw_pte_t *pte;
+	pte_t new_pte, old_pte;
 	bool hwpoisoned = false;
 	int ret = 1;
 
@@ -2587,7 +2588,7 @@ static int unuse_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
 			unsigned long addr, unsigned long end,
 			unsigned int type)
 {
-	pte_t *pte = NULL;
+	hw_pte_t *pte = NULL;
 
 	do {
 		struct folio *folio;
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 258b03182a780..f22cfb2ccb07d 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -361,13 +361,13 @@ static int mfill_atomic_install_pte(pmd_t *dst_pmd,
 {
 	int ret;
 	struct mm_struct *dst_mm = dst_vma->vm_mm;
-	pte_t _dst_pte, *dst_pte;
+	hw_pte_t *dst_pte;
 	bool writable = dst_vma->vm_flags & VM_WRITE;
 	bool vm_shared = dst_vma->vm_flags & VM_SHARED;
 	spinlock_t *ptl;
 	struct folio *folio = page_folio(page);
 	bool page_in_cache = folio_mapping(folio);
-	pte_t dst_ptep;
+	pte_t _dst_pte, dst_ptep;
 
 	_dst_pte = mk_pte(page, dst_vma->vm_page_prot);
 	_dst_pte = pte_mkdirty(_dst_pte);
@@ -656,7 +656,8 @@ static int mfill_atomic_pte_zeropage(struct mfill_state *state)
 	struct vm_area_struct *dst_vma = state->vma;
 	unsigned long dst_addr = state->dst_addr;
 	pmd_t *dst_pmd = state->pmd;
-	pte_t _dst_pte, *dst_pte;
+	hw_pte_t *dst_pte;
+	pte_t _dst_pte;
 	spinlock_t *ptl;
 	int ret;
 
@@ -737,7 +738,8 @@ static int mfill_atomic_pte_poison(struct mfill_state *state)
 	struct mm_struct *dst_mm = dst_vma->vm_mm;
 	unsigned long dst_addr = state->dst_addr;
 	pmd_t *dst_pmd = state->pmd;
-	pte_t _dst_pte, *dst_pte;
+	hw_pte_t *dst_pte;
+	pte_t _dst_pte;
 	spinlock_t *ptl;
 	int ret;
 
@@ -784,7 +786,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
 {
 	struct mm_struct *dst_mm = dst_vma->vm_mm;
 	ssize_t err;
-	pte_t *dst_pte;
+	hw_pte_t *dst_pte;
 	unsigned long src_addr, dst_addr;
 	long copied;
 	struct folio *folio;
@@ -1261,7 +1263,7 @@ void double_pt_unlock(spinlock_t *ptl1,
 		__release(ptl2);
 }
 
-static inline bool is_pte_pages_stable(pte_t *dst_pte, pte_t *src_pte,
+static inline bool is_pte_pages_stable(hw_pte_t *dst_pte, hw_pte_t *src_pte,
 				       pte_t orig_dst_pte, pte_t orig_src_pte,
 				       pmd_t *dst_pmd, pmd_t dst_pmdval)
 {
@@ -1279,7 +1281,8 @@ static inline bool is_pte_pages_stable(pte_t *dst_pte, pte_t *src_pte,
  */
 static struct folio *check_ptes_for_batched_move(struct vm_area_struct *src_vma,
 						 unsigned long src_addr,
-						 pte_t *src_pte, pte_t *dst_pte)
+						 hw_pte_t *src_pte,
+						 hw_pte_t *dst_pte)
 {
 	pte_t orig_dst_pte, orig_src_pte;
 	struct folio *folio;
@@ -1310,7 +1313,7 @@ static long move_present_ptes(struct mm_struct *mm,
 			      struct vm_area_struct *dst_vma,
 			      struct vm_area_struct *src_vma,
 			      unsigned long dst_addr, unsigned long src_addr,
-			      pte_t *dst_pte, pte_t *src_pte,
+			      hw_pte_t *dst_pte, hw_pte_t *src_pte,
 			      pte_t orig_dst_pte, pte_t orig_src_pte,
 			      pmd_t *dst_pmd, pmd_t dst_pmdval,
 			      spinlock_t *dst_ptl, spinlock_t *src_ptl,
@@ -1398,7 +1401,7 @@ static long move_present_ptes(struct mm_struct *mm,
 
 static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma,
 			 unsigned long dst_addr, unsigned long src_addr,
-			 pte_t *dst_pte, pte_t *src_pte,
+			 hw_pte_t *dst_pte, hw_pte_t *src_pte,
 			 pte_t orig_dst_pte, pte_t orig_src_pte,
 			 pmd_t *dst_pmd, pmd_t dst_pmdval,
 			 spinlock_t *dst_ptl, spinlock_t *src_ptl,
@@ -1464,7 +1467,7 @@ static int move_zeropage_pte(struct mm_struct *mm,
 			     struct vm_area_struct *dst_vma,
 			     struct vm_area_struct *src_vma,
 			     unsigned long dst_addr, unsigned long src_addr,
-			     pte_t *dst_pte, pte_t *src_pte,
+			     hw_pte_t *dst_pte, hw_pte_t *src_pte,
 			     pte_t orig_dst_pte, pte_t orig_src_pte,
 			     pmd_t *dst_pmd, pmd_t dst_pmdval,
 			     spinlock_t *dst_ptl, spinlock_t *src_ptl)
@@ -1510,8 +1513,8 @@ static long move_pages_ptes(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd
 	pte_t orig_src_pte, orig_dst_pte;
 	pte_t src_folio_pte;
 	spinlock_t *src_ptl, *dst_ptl;
-	pte_t *src_pte = NULL;
-	pte_t *dst_pte = NULL;
+	hw_pte_t *src_pte = NULL;
+	hw_pte_t *dst_pte = NULL;
 	pmd_t dummy_pmdval;
 	pmd_t dst_pmdval;
 	struct folio *src_folio = NULL;
@@ -2658,7 +2661,8 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx,
 					      unsigned long reason)
 {
 	struct vm_area_struct *vma = vmf->vma;
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 
 	assert_fault_locked(vmf);
 
@@ -2731,7 +2735,7 @@ static inline bool userfaultfd_must_wait(struct userfaultfd_ctx *ctx,
 	p4d_t *p4d;
 	pud_t *pud;
 	pmd_t *pmd, _pmd;
-	pte_t *pte;
+	hw_pte_t *pte;
 	pte_t ptent;
 	bool ret;
 
diff --git a/mm/util.c b/mm/util.c
index bf0513d1d3d08..cc253050f6892 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -1564,7 +1564,7 @@ EXPORT_SYMBOL(mmap_action_complete);
  *
  * Return: the number of table entries in the batch.
  */
-unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte,
+unsigned int folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte,
 		unsigned int max_nr)
 {
 	return folio_pte_batch_flags(folio, NULL, ptep, &pte, max_nr, 0);
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index c5d4deae8084f..a94392053e2e9 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -100,7 +100,7 @@ static DEFINE_PER_CPU(struct vfree_deferred, vfree_deferred);
  *
  * Return: mapping size.
  */
-static __always_inline unsigned long vmap_set_ptes(pte_t *pte,
+static __always_inline unsigned long vmap_set_ptes(hw_pte_t *pte,
 		unsigned long addr, unsigned long end, u64 pfn,
 		pgprot_t prot, unsigned int max_page_shift)
 {
@@ -124,7 +124,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			phys_addr_t phys_addr, pgprot_t prot,
 			unsigned int max_page_shift, pgtbl_mod_mask *mask)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 	u64 pfn;
 	struct page *page;
 	unsigned long size;
@@ -406,7 +406,7 @@ int ioremap_page_range(unsigned long addr, unsigned long end,
 static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			     pgtbl_mod_mask *mask)
 {
-	pte_t *pte;
+	hw_pte_t *pte;
 	pte_t ptent;
 	unsigned long size = PAGE_SIZE;
 
@@ -569,7 +569,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
 	unsigned long pfn, size;
 	unsigned int steps;
 	int err = 0;
-	pte_t *pte;
+	hw_pte_t *pte;
 
 	/*
 	 * nr is a running index into the array which helps higher level
@@ -862,7 +862,8 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
 	p4d_t *p4d;
 	pud_t *pud;
 	pmd_t *pmd;
-	pte_t *ptep, pte;
+	hw_pte_t *ptep;
+	pte_t pte;
 
 	/*
 	 * XXX we might need to change this if we add VIRTUAL_BUG_ON for
@@ -3759,7 +3760,7 @@ struct vmap_pfn_data {
 	unsigned int	idx;
 };
 
-static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
+static int vmap_pfn_apply(hw_pte_t *pte, unsigned long addr, void *private)
 {
 	struct vmap_pfn_data *data = private;
 	unsigned long pfn = data->pfns[data->idx];
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 17d2b793cbfc4..85b6ab60d830b 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3539,7 +3539,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 {
 	int i;
 	bool dirty;
-	pte_t *pte;
+	hw_pte_t *pte;
 	spinlock_t *ptl;
 	unsigned long addr;
 	int total = 0;
@@ -3572,7 +3572,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end,
 	for (i = pte_index(start), addr = start; addr != end; i += nr, addr += nr * PAGE_SIZE) {
 		unsigned long pfn;
 		struct folio *folio;
-		pte_t *cur_pte = pte + i;
+		hw_pte_t *cur_pte = pte + i;
 		pte_t ptent = ptep_get(cur_pte);
 
 		nr = 1;
@@ -4261,7 +4261,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr)
 	struct lru_gen_mm_walk *walk;
 	struct folio *last = NULL;
 	int young = 1;
-	pte_t *pte = pvmw->pte;
+	hw_pte_t *pte = pvmw->pte;
 	unsigned long addr = pvmw->address;
 	struct vm_area_struct *vma = pvmw->vma;
 	struct folio *folio = pfn_folio(pvmw->pfn);
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384384.1627370 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteY-0008NV-8S; Thu, 06 Aug 2026 08:40:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384384.1627370; Thu, 06 Aug 2026 08:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteY-0008NL-1c; Thu, 06 Aug 2026 08:40:38 +0000
Received: by outflank-mailman (input) for mailman id 1384384;
 Thu, 06 Aug 2026 08:40:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrteW-0008Ka-Uu
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrteW-003Rvn-Bg
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:36 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744874-e002-0a2a0a5209dd-0a2a450ad1d0-32
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:36 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744882-f2d2-0a2a450a0019-d98c6eac8546-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:35 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 09CBB176C;
 Thu,  6 Aug 2026 01:40:30 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4AF5F3F9A2;
 Thu,  6 Aug 2026 01:40:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005634; bh=N7Kx8cypRY/4tgLqgkZyPCXbOC37nDVo81ML0oOq7lc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=tagQFezCw9aBUWT7bOfI3ipYrSvBgGoc0nvAu5XpEVT8jAWZTUXoDkAzn54+nSZu/
	 C0359lFjQAXDgtRxm2t3RSVQ591J+t3FxW0ZNLk6ZGX5bMdhv/n3Wr7ekNo3EB6nJi
	 fG5//UTE+Z1Arn0RcPLdaPIBOCt1BQtKZG1psE+U=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 5/9] mm: convert PTE table entries in ptep_get()
Date: Thu,  6 Aug 2026 09:38:43 +0100
Message-ID: <20260806083926.1807279-6-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786005636-4B0D9CFC-A15E1982/0/0
X-purgate-type: clean
X-purgate-size: 1459

ptep_get() now accepts a pointer to hw_pte_t storage but must continue to
return a logical pte_t value. Add __pte_from_hw for both generic hw_pte_t
definitions. Read the hw_pte_t table element atomically before converting
it to pte_t.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Define __pte_from_hw for the opted-in generic wrapper.
- Apply READ_ONCE() to hw_pte_t before converting it to pte_t.
---
 include/linux/pgtable.h       | 2 +-
 include/linux/pgtable_types.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index dad80d264aac2..1768421755a9c 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -493,7 +493,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma,
 #ifndef ptep_get
 static inline pte_t ptep_get(hw_pte_t *ptep)
 {
-	return READ_ONCE(*ptep);
+	return __pte_from_hw(READ_ONCE(*ptep));
 }
 #endif
 
diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
index 70c3edd00a01b..a625516fd67b1 100644
--- a/include/linux/pgtable_types.h
+++ b/include/linux/pgtable_types.h
@@ -8,8 +8,10 @@
 
 #ifdef CONFIG_ARCH_HAS_HW_PTE_T
 typedef struct { pte_t __pte; } hw_pte_t;
+#define __pte_from_hw(pte)	((pte).__pte)
 #else
 #define hw_pte_t pte_t
+#define __pte_from_hw(pte)	(pte)
 #endif
 
 #endif /* !__ASSEMBLY__ */
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384393.1627378 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteg-0000OR-EG; Thu, 06 Aug 2026 08:40:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384393.1627378; Thu, 06 Aug 2026 08:40:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteg-0000OK-BG; Thu, 06 Aug 2026 08:40:46 +0000
Received: by outflank-mailman (input) for mailman id 1384393;
 Thu, 06 Aug 2026 08:40:45 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrtef-0000NF-9N
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrtee-00HXhn-M9
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:44 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744866-2eae-0a2a0a5409dd-0a2a4507ce48-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:44 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74488a-b4ea-0a2a45070019-d98c6eac85b6-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:44 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 125021A00;
 Thu,  6 Aug 2026 01:40:38 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 58AF73F632;
 Thu,  6 Aug 2026 01:40:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005642; bh=QpJOEY7MAUNTQ3U6qtfA/cSosGpAOafJ7uPgYOeWuHo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=LH0Y7EZ8u+Hxz4ct2u7B3pbaW7kO2q9mCmBpSc3Gc5aIuRyHyNcQBmJ6i/FKIN1mG
	 dO0EeHj+xqiekdjfLTdjC448G/b6+B4ErFjOTWEV9jERZSZ8hTZnDekIxcwtofLf58
	 Qhbc4ZPDILqETQxHx0gtUFWmYjKyy7XySo97FBTY=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 6/9] mm: convert PTE table entry to pte
Date: Thu,  6 Aug 2026 09:38:44 +0100
Message-ID: <20260806083926.1807279-7-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786005644-A52CCAE4-190B13BD/0/0
X-purgate-type: clean
X-purgate-size: 685

The non-MMU stub receives hw_pte_t but returns a logical pte_t
value. Convert the stored entry through __pte_from_hw() before
returning.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
 include/linux/hugetlb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index bc0b9c65aa1d0..9e8b391aa4bc9 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 #ifdef CONFIG_MMU
 	return ptep_get(ptep);
 #else
-	return *ptep;
+	return __pte_from_hw(*ptep);
 #endif
 }
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:40:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:40:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384400.1627387 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrten-0000ra-MJ; Thu, 06 Aug 2026 08:40:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384400.1627387; Thu, 06 Aug 2026 08:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrten-0000rP-Iv; Thu, 06 Aug 2026 08:40:53 +0000
Received: by outflank-mailman (input) for mailman id 1384400;
 Thu, 06 Aug 2026 08:40:52 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrtem-0000ov-2N
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:40:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrtel-009iCj-F2
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:51 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744892-5cb7-0a2a0a5109dd-0a2a4505d84a-6
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:51 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a744892-4cb1-0a2a45050019-d98c6eaceb6c-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:51 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2184016F2;
 Thu,  6 Aug 2026 01:40:46 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 643063F632;
 Thu,  6 Aug 2026 01:40:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005650; bh=DTTtIRekIWF5l2t5St3KvKIy8eTeym6aWT0fxyUq96k=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=t/Ynr+ejNvl4R99JThgrl19rvWFbBsiFV4hn5i1ECdKW0th4VOZ7KbW1N62KnLaza
	 TGn2qP6Pu9ZcqkbElZvF+YoQ4TJ4dUl2ixVRmZMzHmEnq7CwFY1Ip2FbKjsKbj8QSs
	 SKPo2pQcwBYzu1+FTzMJdgVouKkCbA21MTO5pHvM=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 7/9] mm/kasan: use hw_pte_t for the early shadow PTE table
Date: Thu,  6 Aug 2026 09:38:45 +0100
Message-ID: <20260806083926.1807279-8-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1786005651-F70B22A1-D909486F/0/0
X-purgate-type: clean
X-purgate-size: 2312

kasan_early_shadow_pte is a complete PTE table rather than a standalone
PTE value. Declare and define its elements as hw_pte_t so the object uses
the PTE table storage type.

Read the first element through ptep_get(), which returns the logical pte_t
value expected by note_page_pte(), instead of accessing hw_pte_t storage
directly. This also uses the accessor selected by the architecture.

No architecture selects ARCH_HAS_HW_PTE_T at this point, so the storage
representation remains unchanged.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Update the description for the architecture opt-in model.
---
 include/linux/kasan.h | 2 +-
 mm/kasan/init.c       | 2 +-
 mm/ptdump.c           | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index bf233bde68c7e..ff41949c0ac08 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -51,7 +51,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t;
 #endif
 
 extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
-extern pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS];
+extern hw_pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS];
 extern pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD];
 extern pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD];
 extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
diff --git a/mm/kasan/init.c b/mm/kasan/init.c
index 30c5266eaf37e..9bbc2a41d23f0 100644
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -64,7 +64,7 @@ static inline bool kasan_pmd_table(pud_t pud)
 	return false;
 }
 #endif
-pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]
+hw_pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]
 	__bss_pgtbl;
 
 static inline bool kasan_pte_table(pmd_t pmd)
diff --git a/mm/ptdump.c b/mm/ptdump.c
index 376880071ca2a..8f19f20be3c44 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -19,7 +19,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
 {
 	struct ptdump_state *st = walk->private;
 
-	st->note_page_pte(st, addr, kasan_early_shadow_pte[0]);
+	st->note_page_pte(st, addr, ptep_get(kasan_early_shadow_pte));
 
 	walk->action = ACTION_CONTINUE;
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:41:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:41:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384407.1627397 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteu-0001H3-Ta; Thu, 06 Aug 2026 08:41:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384407.1627397; Thu, 06 Aug 2026 08:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrteu-0001Gu-QG; Thu, 06 Aug 2026 08:41:00 +0000
Received: by outflank-mailman (input) for mailman id 1384407;
 Thu, 06 Aug 2026 08:41:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrteu-0001Ep-1f
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:41:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrtet-003S2w-Ec
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:40:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74489a-2eae-0a2a0a5409dd-0a2a4507d156-6
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:59 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74489a-b4ea-0a2a45070019-d98c6eacb468-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:40:59 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 289F5176C;
 Thu,  6 Aug 2026 01:40:54 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 712203F632;
 Thu,  6 Aug 2026 01:40:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005658; bh=Jt3lY9Rfe2qE4RAnGMFG9uUvIQ7Ln1RzFK0qs/6Pya4=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=luByc3jtbBV3gUID39iGf/O7Ordl38J04J9ScF6tTrQH2SAyJst4PI5/HEx/+oO2M
	 tC4u2VpNMwnUKS+GMCR24TnNoqgA1Zh5W58AIkL2KnpnrIKANxQnj1eS3ryjCi4BDm
	 nxuZnsP5XbydqmOlfXFKlJJcGS7jqx3QJB3bT6Ww=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 8/9] drm/i915: use hw_pte_t for PTE range callbacks
Date: Thu,  6 Aug 2026 09:38:46 +0100
Message-ID: <20260806083926.1807279-9-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786005659-A48C9AE4-C3315845/0/0
X-purgate-type: clean
X-purgate-size: 2379

apply_to_page_range() now passes PTE table storage to its callback as
hw_pte_t *. Update the i915 remap and selftest callbacks to match the new
type.

Continue to use ptep_get() for logical values and set_pte_at() for updates.
The type remains an alias of pte_t on x86 until that architecture opts in.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Clarify the effect on architectures that have not opted in.
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 4 ++--
 drivers/gpu/drm/i915/i915_mm.c                     | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index d01acfb7d93d0..056faf4a3618b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1690,7 +1690,7 @@ static int igt_mmap_gpu(void *arg)
 	return 0;
 }
 
-static int check_present_pte(pte_t *pte, unsigned long addr, void *data)
+static int check_present_pte(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	pte_t ptent = ptep_get(pte);
 
@@ -1703,7 +1703,7 @@ static int check_present_pte(pte_t *pte, unsigned long addr, void *data)
 	return 0;
 }
 
-static int check_absent_pte(pte_t *pte, unsigned long addr, void *data)
+static int check_absent_pte(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	pte_t ptent = ptep_get(pte);
 
diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index fd89e7c7d8d6f..aab88e8edf946 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -48,7 +48,7 @@ static inline unsigned long sgt_pfn(const struct remap_pfn *r)
 		return r->sgt.pfn + (r->sgt.curr >> PAGE_SHIFT);
 }
 
-static int remap_sg(pte_t *pte, unsigned long addr, void *data)
+static int remap_sg(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	struct remap_pfn *r = data;
 
@@ -70,7 +70,7 @@ static int remap_sg(pte_t *pte, unsigned long addr, void *data)
 #define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
 
 #if IS_ENABLED(CONFIG_X86)
-static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
+static int remap_pfn(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	struct remap_pfn *r = data;
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 08:41:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 08:41:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384415.1627406 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrtf6-0001vI-5X; Thu, 06 Aug 2026 08:41:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384415.1627406; Thu, 06 Aug 2026 08:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrtf6-0001ut-1q; Thu, 06 Aug 2026 08:41:12 +0000
Received: by outflank-mailman (input) for mailman id 1384415;
 Thu, 06 Aug 2026 08:41:11 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <usama.anjum@arm.com>) id 1wrtf5-0001q0-6l
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 08:41:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrtf4-0034l4-0O
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:41:10 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a74489f-2eae-0a2a0a5409dd-0a2a450c9f88-28
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:41:09 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <usama.anjum@arm.com>)
 id 6a7448a2-f479-0a2a450c0019-d98c6eac8690-1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 10:41:07 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 34C59153B;
 Thu,  6 Aug 2026 01:41:02 -0700 (PDT)
Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com
 [10.2.198.93])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 7CABF3F632;
 Thu,  6 Aug 2026 01:40:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786005666; bh=26js+M9zWrHNC4a3AjcYSrQ4VRwzJZBtm9+Mxf/tKbk=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=TTBSkLercTTP8PzXx2W54PajQtmr3ocTbHrCDjoVYDyhLdl97U7CcPQ3qilKSBkf9
	 vIh9ep96aTHrl1x02wMw5yGa/VgSgdxL9PNbjwHpeKiFJfhkPl82/MnNvLvZO9B0+j
	 c9NuO4Hhw/STBkgcZsI3sprKusZaJGcpuNEKybDo=
From: Muhammad Usama Anjum <usama.anjum@arm.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Helge Deller <deller@gmx.de>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Will Deacon <will@kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Nick Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	David Hildenbrand <david@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Chris Li <chrisl@kernel.org>,
	Kairui Song <kasong@tencent.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	SJ Park <sj@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Leon Romanovsky <leon@kernel.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Dennis Zhou <dennis@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@gentwo.org>,
	Mike Rapoport <rppt@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	ziy@nvidia.com,
	pfalcato@suse.de,
	agordeev@linux.ibm.com,
	ryan.roberts@arm.com
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>,
	linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	linux-parisc@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	damon@lists.linux.dev
Subject: [PATCH 9/9] xen: use hw_pte_t for PTE range callbacks
Date: Thu,  6 Aug 2026 09:38:47 +0100
Message-ID: <20260806083926.1807279-10-usama.anjum@arm.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260806083926.1807279-1-usama.anjum@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786005667-03AD4A5B-5E84EDC5/0/0
X-purgate-type: clean
X-purgate-size: 3287

Generic PTE range and remapping helpers now pass pointers to PTE table
storage as hw_pte_t *. Update the Xen callbacks to match those interfaces.

Keep logical PTE values as pte_t and continue to access them through the
existing PTE helpers. This is required when Xen is built for an
architecture that selects the distinct hw_pte_t wrapper.

Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
---
Changes since RFC v1:
- Clarify why the callback conversion is required after architecture
  opt-in.
---
 drivers/xen/gntdev.c               | 2 +-
 drivers/xen/privcmd.c              | 2 +-
 drivers/xen/xenbus/xenbus_client.c | 2 +-
 drivers/xen/xlate_mmu.c            | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1dcc4675580ed..b013bcad99b5b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -301,7 +301,7 @@ void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map *map)
 
 /* ------------------------------------------------------------------ */
 
-static int find_grant_ptes(pte_t *pte, unsigned long addr, void *data)
+static int find_grant_ptes(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	struct gntdev_grant_map *map = data;
 	unsigned int pgnr = (addr - map->pages_vm_start) >> PAGE_SHIFT;
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 725a49a0eee72..b4a487dcc9ecb 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -1658,7 +1658,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
  * on a per pfn/pte basis. Mapping calls that fail with ENOENT
  * can be then retried until success.
  */
-static int is_mapped_fn(pte_t *pte, unsigned long addr, void *data)
+static int is_mapped_fn(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	return pte_none(ptep_get(pte)) ? 0 : -EBUSY;
 }
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 27682cb5e58ab..387f97a555594 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -749,7 +749,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 #ifdef CONFIG_XEN_PV
-static int map_ring_apply(pte_t *pte, unsigned long addr, void *data)
+static int map_ring_apply(hw_pte_t *pte, unsigned long addr, void *data)
 {
 	struct map_ring_valloc *info = data;
 
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 8efd7b55223fb..d7244f9f9a545 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -93,7 +93,7 @@ static void setup_hparams(unsigned long gfn, void *data)
 	info->fgfn++;
 }
 
-static int remap_pte_fn(pte_t *ptep, unsigned long addr, void *data)
+static int remap_pte_fn(hw_pte_t *ptep, unsigned long addr, void *data)
 {
 	struct remap_data *info = data;
 	struct page *page = info->pages[info->index++];
@@ -269,7 +269,7 @@ struct remap_pfn {
 	unsigned long i;
 };
 
-static int remap_pfn_fn(pte_t *ptep, unsigned long addr, void *data)
+static int remap_pfn_fn(hw_pte_t *ptep, unsigned long addr, void *data)
 {
 	struct remap_pfn *r = data;
 	struct page *page = r->pages[r->i];
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 09:32:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 09:32:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384465.1627415 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wruSG-0007St-S7; Thu, 06 Aug 2026 09:32:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384465.1627415; Thu, 06 Aug 2026 09:32:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wruSG-0007Sm-On; Thu, 06 Aug 2026 09:32:00 +0000
Received: by outflank-mailman (input) for mailman id 1384465;
 Thu, 06 Aug 2026 09:31:59 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd66a3fd5000e099@swg.vates.tech>)
 id 1wruSF-0007Sg-0H
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 09:31:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wruSD-00F3hd-SX
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 11:31:57 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd66a3fd5000e099@swg.vates.tech>)
 id 6a74547e-e002-0a2a0a5209dd-0a2a4501ddde-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 11:31:57 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd66a3fd5000e099@swg.vates.tech>)
 id 6a74548c-5984-0a2a45010019-b9ff1c238c9b-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 11:31:57 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fd66a3fd5000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 06 Aug 2026 09:31:55 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id 7341280143;
 Thu,  6 Aug 2026 11:31:54 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=H1/fDbtueoAwVW3NxBpCSNwTTB+L6V1ifVuLniu1eT0=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=lRkORnFdwoF3/T8ot2U0iQSVIAPMq407z+wV9lvfVRbARHPNBoDpMUSDMvqFwSyAljBV39ErJ
 6lVLdY3l9IcHEpc5ILwwPv1IWm1JxPjRmBjvFrl34GPdBP97M2sTcCjWNQnNTulADrtomg2NaEQ
 NpP9zqYf8vAabQ7V6vMv68VUdUs1DSpJuBJa6NjeFub5BIRvmgJ0h/6C3/sPgKeVAELE/PhZQ5Q
 AEQSS46KY5qI4DBK0H2iH4MR/bh18Z0j94EpVmC01LK89X/n9nElV5WepvpNoNbWNSeClxEYDUb
 a45WJnehuCSPK7u1CHsHcc5c8NfGFoB162atyOqEFgQA==
X-Zone-Loop: 6287a73f1fb7823a2cc539e32ecfd4b93bb4fd248b5d
x-campaign-type: default
x-transaction-id: 658cb477-1178-4c71-b777-d4b628fef0ed
x-swg-uid: 01-34470f5a-29de-496a-aa18-199d4b415288
X-Mailer: Sweego
Message-ID:
 <1786008715.8631fc262581453bbf619ec5b2062170.19fd66a3fd5000e099@vates.tech>
x-swg-bid: 1786008715.8631fc262581453bbf619ec5b2062170.19fd66a3fd5000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 6 Aug 2026 11:31:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/svm: mandatory update VMCB nextrip for soft
 interrupts
To: Chunjie Zhu <chunjie.zhu@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Jason Andryuk <jason.andryuk@amd.com>
Cc: xen-devel@lists.xenproject.org
References: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------RQ0cKYyiZfxQAjq0mGLb0A08"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786008714614
X-purgate-ID: tlsNG-d62444/1786008717-BFE68757-CF656530/0/0
X-purgate-type: clean
X-purgate-size: 6615

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------RQ0cKYyiZfxQAjq0mGLb0A08
Content-Type: multipart/mixed; boundary="------------2ihUYEGYZ0TyVk9YM9E0oq6X";
 protected-headers="v1"; hp="clear"
Message-ID: <37659b5a-486e-48e0-b4a4-1ff4819598b1@vates.tech>
Date: Thu, 6 Aug 2026 11:31:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/svm: mandatory update VMCB nextrip for soft
 interrupts
To: Chunjie Zhu <chunjie.zhu@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Jason Andryuk <jason.andryuk@amd.com>
Cc: xen-devel@lists.xenproject.org
References: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <20260806031732.10242-1-chunjie.zhu@citrix.com>

--------------2ihUYEGYZ0TyVk9YM9E0oq6X
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDYvMDgvMjAyNiDDoCAwNToxNywgQ2h1bmppZSBaaHUgYSDDqWNyaXTCoDoNCj4gU2ln
bmVkLW9mZi1ieTogQ2h1bmppZSBaaHUgPGNodW5qaWUuemh1QGNpdHJpeC5jb20+DQo+IC0t
LQ0KPiAgIHhlbi9hcmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jIHwgOSArKysrKysrKy0N
Cj4gICAxIGZpbGUgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+
IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMgYi94
ZW4vYXJjaC94ODYvaHZtL3N2bS9uZXN0ZWRzdm0uYw0KPiBpbmRleCBiMDYxMjRjMmM5ZWQu
LjgxNTcxM2I4YjUwNiAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVz
dGVkc3ZtLmMNCj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMNCj4g
QEAgLTQ0OSw3ICs0NDksMTQgQEAgc3RhdGljIGludCBuc3ZtX3ZtY2JfcHJlcGFyZTR2bXJ1
bihzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+ICAgICAg
IG4ydm1jYi0+dmlydF9leHQuYnl0ZXMgPQ0KPiAgICAgICAgICAgbjF2bWNiLT52aXJ0X2V4
dC5ieXRlcyB8IG5zX3ZtY2ItPnZpcnRfZXh0LmJ5dGVzOw0KPiAgIA0KPiAtICAgIC8qIE5l
eHRSSVAgLSBvbmx5IGV2YWx1YXRlZCBvbiAjVk1FWElULiAqLw0KPiArICAgIC8qIG5leHRf
cmlwIGlzIGNvbnN1bWVkIG9uIFZNUlVOIGFzIHRoZSByZXR1cm4gYWRkcmVzcyBwdXNoZWQg
b24gdGhlDQo+ICsgICAgICogc3RhY2vCt2ZvcsK3aW5qZWN0ZWTCt3NvZnTCt2V4Y2VwdGlv
bnMvaW50ZXJydXB0cy4gVGhpcyBhc3NpZ25tZW50DQo+ICsgICAgICogc3RhdGVtZW50IG11
c3QgYmUgZW5mb3JjZWQsIG90aGVyd2lzZSwgaXQgbWlnaHQgY2F1c2UgdmNwdSB3ZWRnZS4N
Cj4gKyAgICAgKg0KDQpXZWxsLCBpdCdzIG1vcmUgdGhhdCBucmlwIHNlbWFudGljcyByZXF1
aXJlcyBucmlwIHRvIGJlIHByb3Blcmx5IA0KY29uZmlndXJlZCBpbiB0aGUgdm1jYi4gVGhh
dCBsb29rcyBsaWtlIGEgbWlzc2luZyBwaWVjZSwgYnV0IHdlIG1heSANCnN0aWxsIHdhbnQg
dG8ga2VlcCBzb21lIGluZm9ybWF0aW9ucyBhYm91dCB3aGF0IGhhcHBlbnMgb24gdGhlICNW
TUVYSVQgc2lkZS4NCg0KPiArICAgICAqIEFQTSBWb2wuMiBFdmVudCBJbmplY3Rpb24gZG9l
cyBub3Qgc3BlY2lmaWVzIHdoYXQgaGFwcGVucyBpZiBORVhUUklQDQo+ICsgICAgICogaG9s
ZHMgYW4gaW52YWxpZC9nYXJiYWdlIHZhbHVlLg0KDQpUbyBtZSwgaXQncyBzaW1pbGFyIHRv
IHNldHRpbmcgUklQIGRpcmVjdGx5IHRvIGEgYm9ndXMgdmFsdWUuIG5yaXAgaXMgDQpqdXN0
IGEgIm5leHQgaW5zdHJ1Y3Rpb24gcmlwIiBiYXNpY2FsbHkgKHdydCBldmVudCBpbmplY3Rp
b24sIC4uLikuDQoNCj4gKyAgICAgKi8NCj4gKyAgICBuMnZtY2ItPm5leHRyaXAgPSBuc192
bWNiLT5uZXh0cmlwOw0KPiAgIA0KPiAgICAgICAvKg0KPiAgICAgICAgKiBWTUNCIFNhdmUg
U3RhdGUgQXJlYQ0KDQpUZWRkeQ0K

--------------2ihUYEGYZ0TyVk9YM9E0oq6X--

--------------RQ0cKYyiZfxQAjq0mGLb0A08
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmp0VIkFAwAAAAAACgkQZg+p0QLLz9D1
OAv8CTskpTSydVdROIYyIF8Mf17Yj/Tqg8xy9XWovx3ENaMf77enPEB4WK8cj7Ch9oPR25s9HNtO
oruWr9d94kW+EsroKP3TvcVlhX6zV0T5lst0it2c7HSHgiPc1oWhNigRbOQzbIhlCw9mBUJ968sc
28APvzUunNizul5VQ2YIuaGanELbW67ZEJxR8ueMotQPnJAJgpoUAESDdAD3AlqV+q5TtTqpTZWJ
uJX06Pq4IfL8FPlhlGLedQhxImhGHYJplIJX5AvN6TiNpWEZmQUQlKVLFiLPZJchRYH1VXBclt5h
1Wxulj3fEH2tL981/Oe6ySG4RHHbrY5IFdWVumMW53ePKWSCRR97Z45uF9EBDbIjJNao7oenSDF+
GSM2cnM3yvM9oAjROtNxTI6J9S+M4WN+ZmvG/ziyiRsMBrG+viWeG8CK4gbhOZG+RCoPGLcGClKL
qeePJ4Aou0FbyadIMH0JJR5dJZhVJs6pp1cqD44IjilzBf7AFEiQK2QYD4W2
=mrhF
-----END PGP SIGNATURE-----

--------------RQ0cKYyiZfxQAjq0mGLb0A08--


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 09:40:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 09:40:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384478.1627424 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wruaD-0001ip-Km; Thu, 06 Aug 2026 09:40:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384478.1627424; Thu, 06 Aug 2026 09:40:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wruaD-0001ii-H0; Thu, 06 Aug 2026 09:40:13 +0000
Received: by outflank-mailman (input) for mailman id 1384478;
 Thu, 06 Aug 2026 09:40:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wruaC-0001ia-3i
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 09:40:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wruaB-003eUK-Gm
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 11:40:11 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a745675-5cb7-0a2a0a5109dd-0a2a4506d7c6-8
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 11:40:11 +0200
Received: from [52.101.43.44]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a745679-195a-0a2a45060019-34652b2cf386-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 11:40:10 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by LV1PR03MB989626.namprd03.prod.outlook.com (2603:10b6:408:3f8::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.21; Thu, 6 Aug
 2026 09:40:06 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.019; Thu, 6 Aug 2026
 09:40:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dFe+kXS/DunfMfIlyc/I2JaQNHUwKjfl3rBafT6AiFi0UrppemzPsQFaTAeo6uQvqwyiZtjHybEcSRGI3OdvWYvo77aDowp8a0qZh4+fSXwIum8Xty3feGN5wALOPPo3m82c0tZyU/cBUe+ORjUQZc9TsC7YfTEplwCnPsOt2jCV0Il7pW7oYTJXYZt4fNQCEvfbpQr41kWaflSSXsqO8uyDMqmKkE9gz1E3YlvioRBG0YOjiiy6s7/uB5YjLtp7pPwbxNBNOvr8VrN8CQDBk2wo6H2tcwIm8YZ7guziOPvLiv6GImGbmjhKL9mU7D2QXSREcGXv1MFVZUCGECGRhw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sQBE6PmyIsgW0exlUidMoLkPd7iub8pgxLjMotEfFkY=;
 b=pCWl3+NzWIVRG1tMyH3essZU8iu5LRZin5qNv9lBIrcNENATygzp/GoS9MlMRQhv83cJ1OHXY2cRnrJyVD4fMoFBm0yCtTKUE3Chu8dNfw5mU1zqztFWa3azz1Saot2G5gBRnDviD6iqY1A+j/OAfHb/NBYaCJDdXwhwao5wscEaZPF6bLfn84B/T+3xRLRmX2jPOQNSvlAooZ1pt9jpYOEonIt0Ni1D3iB2XWtLui1w6uuuO4R56YQzLy+zcwHCREOdhXcTUS7xRxCOM8Y6/mu4rq4CL9A5VIZd3xm5MFo7UzVi9vh9OF98lKzi/AwDHqQ8lvXID4go7SlT6tgx8w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sQBE6PmyIsgW0exlUidMoLkPd7iub8pgxLjMotEfFkY=;
 b=fauHB9+wzoLKDIjGVg63CYXD8enma692aCrS0qGxk9XCebMKNn1aPfY1upaaYGHFKY3gaEVpbvJ3M+MR1cj4vi1dxPmeeYtuFqAO3duWnpIpTm+r9QSeZOIyCtmt2KpfYGIuhwPnh8WhKrYFaSwr7XW2O5OFYgpPGs+RLn/5rJo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <bad63e21-5ac2-44a2-9669-558e7e45dbb6@citrix.com>
Date: Thu, 6 Aug 2026 10:40:03 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/5] x86/nmi: Don't configure EvtSel repeatedly
To: Jan Beulich <jbeulich@suse.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-6-andrew.cooper3@citrix.com>
 <d76fa0a2-1a53-4ee4-b077-d51715dba339@suse.com>
 <da3b4ee8-7c12-4fec-8d31-6f2f66bba4a8@citrix.com>
 <0b38417e-2c59-4df1-8429-ec7c98ce22d6@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <0b38417e-2c59-4df1-8429-ec7c98ce22d6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0548.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:319::11) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV1PR03MB989626:EE_
X-MS-Office365-Filtering-Correlation-Id: 192567b1-1fb6-4044-a964-08def39eb2a5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|10067099003|56012099006|11063799006|5023799004|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	LmJxxGPFVEFIS1AYsUQDDOVkAqQRz4fWcygsNamIXxJEKmVnuId6uBVNudOuET1LDaeK5/BEMiTAQMsBI2lReW1xohu3LCiywIYSVH5kdXZlkSqjD4QhdXndcJeSsFD3gbG9jnLWzKPhx14z5Qk2G+Oy0qtjwtlcRprJ0XOXlBJRy+FxvYDBR5eGhBlFNKdXyt7dbHjqeV7mHkyPBAVDkEQes/Y8kjtTbRlYzAXJwc3nFUgEnQXTjxbF9suCjM/9NBBfIbFC5mH4/jf6nAn403mZvMXuUX0adYf6HtMnNGqcjF5O/pDHHO4cm8+n9f9yzw+ulCXD1LkNN544KFWEMyiAw8tn0aa8zbnd+ajXXDNH9FsLJHvblb75Q0K0R/aLQHEPUi1G53n13gwdIO2w/ANQTdyUFvdlWt8ahoMQSLuTlGQA1yd96mspMuhhUyDkEfcMpjyUIDYSDKZiKMbihCl7dW6iXGwW1Ax58SK9xJU/e3yGdcvYiWWhQAFwSab7hbCF63yfll1TN8uDY3iYRt0H34M3tG67d5/xXkpx7lImVC6uGwOEnxshK4FXWguvcmG+uhv6KKZEDTFqKDElM2fVm0Cu27sRe1aSIpy6iKbVQHjB7cDo87UdoxzqtVcylC/tO/jzUbP1O9pTzElcT+De7cUpBhKagVTwjt4qmZ0=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(10067099003)(56012099006)(11063799006)(5023799004)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Vm9la3NPdHArbWVEWlNMZFNCTUo3eCs3Zi9xUnVGQzI1S3dvNDY3ZVYzY3Vy?=
 =?utf-8?B?a1loMG5aU1I1THVVWFg2b1lmQUpqbjdmclNYcU1BUHdRVHMydDBESTdwWS9q?=
 =?utf-8?B?d2VuNVpncFUwSjdVbTRYS0RXVU1YYXpMeTNLams4MzJsL3h2OEZ4T0kwYS8r?=
 =?utf-8?B?WjVlRWFaak9pN1JYaloxbkRFejJuRWkwckt0SWVnazVCTWNpQzF5SzFLZmdK?=
 =?utf-8?B?YTZlTnlsYXRRaFpha0Z0N045YmR2TzBGSCsrd3o1ZXdhTjFYVFpSM3BSd0ZF?=
 =?utf-8?B?TS9yeHpBZUFTOXBjNGQvVDRVUjFFQXQ5bjdkbnljd3ZoYjU4UU5sNEdsc3hV?=
 =?utf-8?B?NFp6c2dVQ1VGV2ljZEJkVzR6VU5qT1E0aEhCWUM2UjVDWEdWbHNCbE94Z29E?=
 =?utf-8?B?M3RINk1VNkg1VnR4RXJjSDQ0c0pRMkgycndXVzlhYmFDWTdKRHpRZzZvRWNv?=
 =?utf-8?B?N2s2cVpwTU82SHZWSGRLTm1vMlZkRTRCOHpORHlmWHhURXFpeFVKZ1cyYXdR?=
 =?utf-8?B?akliVWV6aURvc1VxdVpleXc2OUFKMWxreW5vWlI3UzBuY0xqRmtiNnl3Q1Vk?=
 =?utf-8?B?LzNVZDhhblNodmRlRThYZHBzV05xODZISElDT05URnhjVDhnTXdzZzcwRkZX?=
 =?utf-8?B?Y2tJRURiRUdOVkwwRU1QS1ZQd1QveHNxRC9CaCtwV0NQT1BxeGJGREk1cHBY?=
 =?utf-8?B?RVFVaVloQ09oVWxhMlN5a1RzdEFSeWQySFhnTDB0MFFFTUUwbHVLZGdTME9V?=
 =?utf-8?B?MTNBMVM3cWZVSTJucmVVYlY0M0EwanZ3NDY4ZEVQUU8wZFc5YUVMRDRaSmhZ?=
 =?utf-8?B?R05ERkQ4eGVCYlkvTDVvU2lYOUQzSW5aSTVhRnlqaUxDQ2pzZjF4dDN4K1Jl?=
 =?utf-8?B?UFVybVVnSTBIM1RYYXhzemhMWU92VEtMTFBNb0UvbGQvREQ0MURBSCt1T1ky?=
 =?utf-8?B?YnA3MFhSVU1VcWMvZitrT3V6TjJSc013WTlXWFZIbVh4dEQrR2NjZUplRENv?=
 =?utf-8?B?WTRzYWk1RWYvN210Ukt5bWoreXZFRktJVitqcC8vQUVNM0t1UzB4SlJOUlRq?=
 =?utf-8?B?UzZqRE8rZy8vcUVBWjJnSGZyT0lqc1lyNmtGeXJwRlhUMi9PanNCNjJFTG1V?=
 =?utf-8?B?bE9rdE5XSkxRb0xkclhnVGJia2NIanoxZVJCRndHTWNpaE9FcnkyU254SjFY?=
 =?utf-8?B?Q1pxNVJ3ZXNnOTJKcExzNkoyR29PSUFNeWJLajJjdDVwdUVDMXhxNElsQVA5?=
 =?utf-8?B?V1hzb2ttV2pwaWI4d0JwNVJiVjR1SHU3SVVHWXluYXVUczMvTURVK1Ywd0Vo?=
 =?utf-8?B?Y2R6U3Z5bFE5UFhOaE43Uk9WZmVQazhkcW0vTlo1NjFUWXNwai83N3dBYjB2?=
 =?utf-8?B?T3dzalp1S2lDYm1rVVVnWHBpaXpBNUh5UitJVVFWdk81YXByM1pHdjlDWkFu?=
 =?utf-8?B?dkVQUVh6UjVuZUZtQnZCRDlQUVdLQm1jQVl5c25ObXc3dU9WQVh0RHZCL2VJ?=
 =?utf-8?B?RGRhRG91cGZxY2pNV2JtNXZGZjcxTkFrUUFwNXkyYVB2a2NvOE44ajJoM0FB?=
 =?utf-8?B?MGFHTWtmZEUrb3lpcUVpUUVWY2lqY2N2ZFQxaUJIUFgxQUJ0enMvRGc4U1h5?=
 =?utf-8?B?cW55U0VmSUZUcUVsK2FnOHo0TVFCWkdORG1DSEdRYmdtSWZJU0txdHl0eFdm?=
 =?utf-8?B?bjFES1hrVFNzMWVDSEdjOVQ0b2tEa0xxbGIwbTB2M0JxMW1GdU9HMDlScGpw?=
 =?utf-8?B?dW9yMFM4WWhXNzhtYXh4VXRQdjYyR2VDM1VacmJzU2RYZThDakJGN3liaUZ4?=
 =?utf-8?B?cjQzTldUUUN3VEpoY0s2Q1NzeWRpc051TFZjQWtKaHpIenJpT1QrZTBVVmVv?=
 =?utf-8?B?dWtYWDk0M3JvRGJ0aGl5a1J3dEhXclFQWDlWVVNDMWcvdkwwcjdxSUF4NmpF?=
 =?utf-8?B?WllPZm13U24ycUZmQ1NnNjRnRnZzNFpyU3RJcDJ0Wkw0Q05GWlF1a2JjTXpG?=
 =?utf-8?B?QmFuazQ5WU9KRi8yZjBLano1Nlc1NEdIUVVHa2xYbzhoY3o1SndKL3YvdGg2?=
 =?utf-8?B?MkV4OXYzYlpKR01TNS9hMnEzOE1sVG8yL1pxeDl0TnNNK0RycmRYcElONnN0?=
 =?utf-8?B?UXI3dU1mTGNDM0l6MDBZcEQ0a1EydkdjNENCTHVOaEZWMXpjVjZUMjNBQUUw?=
 =?utf-8?B?MUVucStNVitJY2F6TldPWVlML0tnY1hMdUZUakFIdUd3SlY4SDRNSnowSXp3?=
 =?utf-8?B?WWtqYm9IZ2kzdXJMY1RNc2wzeVA0S2Faa3AwRUlLcGdhOWRiVjUzSGQzN2wz?=
 =?utf-8?B?QVA3WTNXdW13M0NpNHlIRGQ0em9tWThueUZHdHBNaW9DQTRneGptQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 192567b1-1fb6-4044-a964-08def39eb2a5
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 09:40:06.1614
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Mwz+k5e4PI+fH0GSjsLQJtqOsyUR5ssr5Pl1Y19ShP3X9VxhJs87bY+H6xKZWcf+s++ZBKdu3VY8dVI/T/4Vb1tjxkGZX0hbb2V2F05wvCk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV1PR03MB989626
X-purgate-ID: tlsNG-16d1c6/1786009211-F580D77B-4BB27AB1/0/0
X-purgate-type: clean
X-purgate-size: 1283

On 06/08/2026 7:57 am, Jan Beulich wrote:
> On 05.08.2026 17:37, Andrew Cooper wrote:
>> On 05/08/2026 3:20 pm, Jan Beulich wrote:
>>> On 05.08.2026 14:45, Andrew Cooper wrote:
>>>> In both setup_{k7,p6}_watchdog(), EvtSel0 is first zeroed, then written with
>>>> everything but the enable bit, then written with the enable bit.
>>>>
>>>> setup_p4_watchdog() is slightly more complicated, owing to what
>>>> appears to be a bug introduced by commit 2a2bd8de16b6 ("Clean up NMI
>>>> watchdog handler."), which causes a second bit to be temporarily
>>>> different too.
>>>>
>>>> The middle of the three writes is useless in all cases.  Drop it.
>>> Spotting the 1st write in setup_p4_watchdog() wasn't quite as easy, as
>>> MSR_P4_BPU_CCCR0 (as passed to clear_msr_range()) has nothing to do with
>>> MSR_P4_IQ_CCCR0. Using unrelated MSR names there is as unhelpful as using
>>> raw hex numbers.
>> Perf counters on the P4 are utterly insane, but our local logic really
>> doesn't help matters.
>>
>> Another option would be to remove P4 watchdog support, in the basis that
>> we really can't test it.
> Well, my Tulsa system is still alive, and the watchdog looks to be working
> there.

Oh, if you're still able to test, then that's even better.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 10:44:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 10:44:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384562.1627440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrva0-0000Wp-5E; Thu, 06 Aug 2026 10:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384562.1627440; Thu, 06 Aug 2026 10:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrva0-0000Wi-2S; Thu, 06 Aug 2026 10:44:04 +0000
Received: by outflank-mailman (input) for mailman id 1384562;
 Thu, 06 Aug 2026 10:44:03 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wrvZz-0000Wc-7P
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:44:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrvZy-007XZa-4H
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 12:44:02 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a74655b-e002-0a2a0a5209dd-0a2a450be1d8-44
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 12:44:02 +0200
Received: from [40.93.196.65]
 (helo=SA9PR02CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a746570-b7e8-0a2a450b0019-285dc441fe8b-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 12:44:01 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by SJ0PR03MB5503.namprd03.prod.outlook.com (2603:10b6:a03:288::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.21; Thu, 6 Aug
 2026 10:43:57 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0292.019; Thu, 6 Aug 2026
 10:43:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=e+WjnN1x62m821yepLlTypVVUw2lA5aoIKF/Aj+OADbpN6Gfk4SSjKzzA3DzRWdEvaNse+5gFNj+3Q7fx11NjKhDSC+pKppLP8UEkmbGuat2pAL+1lE5AwjumN91IrN/9sVBVEAOLVhLJQsc4mHhk+9+r19lumR4fESbpeGvAOHnesGqTd930fH8MQ7s7yTnaeufBpNxDBLeYKu5Xf3UbHa+o73oDNndWYloFbbP3GOjo7BWj6FU9NIWi9uh+a/mv+14HlTGKDnNU3jeH54ttfnpCXzkQ/nQGgKIYE27xY/qczx8GfoSqji76KJJg2gqj+JVIt8dIi0N5fkPtwFcaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7rJ/ii9+zYru9tGxrnZ9ThdtN66dT0Yw8UgDRDt0hto=;
 b=EDfjIMxn+reGV3AAwKWSJbsSMUSd2W//FxwBoWORVU4FKHStWsWScrebw7vxXxRwMgOUAg/hF+M0caLqM8R167ByV/nP4IpBSvmGtF1SxTLcSS+8IiDmGLbQZEfkvvNClm46Ww/KxcqmOSV6smQWK1kKfiPth03tQgoACpZ/GzVFBzcAVfHwMW7mx6InFORj91WgNy3Y6TopLsVJsXBxLKMYV3XicoiFz19djMkfFX5zFQvHgGYTIo6f58vYIqp3KeEAwm6zcfPrUWpJpOjv69rpRWGiZoZV9ThOAO/j00e7L2sNLIy4jZ2DNDpNwoQRkvW7fgcv60quHQE2onvX1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7rJ/ii9+zYru9tGxrnZ9ThdtN66dT0Yw8UgDRDt0hto=;
 b=0IMavQE5UjYj+VpvNUvqtKvMX7939XpLDT9D4p6vFPXXtTv3Rc6Q0GcRTv27AGvbfaB+TDW1mM7JypX1c0dR1z6bt2BD9bCugGL43j8Rnq+R6O/y/dG8f1qLT12AI2wwPiXT8UVbElHORKWtL3A//k3PcpG5c+0TRswOTEuIP7w=
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: Andrew Cooper <andrew.cooper@citrix.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Jan Beulich <jbeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>,
	Jason Andryuk <jason.andryuk@amd.com>, Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v1 1/6] nestedsvm: Fix CR3 MBZ check
Thread-Topic: [PATCH v1 1/6] nestedsvm: Fix CR3 MBZ check
Thread-Index: AQHc7Qzj6Zyg1vqVRkydd+9Jb6lnwrYgRXUAgAAGJoCAcPgFxA==
Date: Thu, 6 Aug 2026 10:43:56 +0000
Message-ID:
 <CH8PR03MB8274EFC6FA9AA86D68E4277FF0D22@CH8PR03MB8274.namprd03.prod.outlook.com>
References: <20260526124027.573412-1-ross.lagerwall@citrix.com>
 <20260526124027.573412-2-ross.lagerwall@citrix.com>
 <b9ddc37c-216b-4c18-8d77-03ce641d2614@citrix.com>
 <6e81d92d-cef7-43e4-8dfc-08c5edbb504d@citrix.com>
In-Reply-To: <6e81d92d-cef7-43e4-8dfc-08c5edbb504d@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH8PR03MB8274:EE_|SJ0PR03MB5503:EE_
x-ms-office365-filtering-correlation-id: b8e387ad-18e9-4930-33ea-08def3a79db3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|4143699003|10067099003|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 nVk/XadbjvbD4dlpOG/3qfpklA81R6BhOTF+CdQOJ6UEUbXICWst23Eq5ss5IZRD9eZEht01l1ckxSKVN8JxFqNBPECbgejEEML6R2pLbNm0kzbHqBg62jR+k7K4LP2dOu2XKQVHTH4KjrPRZUSriYdWraed4QmudJafSOFCJUis//5HAY9853e+6JCdWkZYraAl+DGx/7d1XZZHRhb9h9FmXcEmd83lAKZK4wt7ofP6guaWVpTNaOA7I9jzMtpj22BYTtfIRq1uXLVPVOmCqPjsAXuVDQNGGFb8T+PaKC8O4zaeE1DD4FU96s2En7Glu1zO9rIZgcI1+tc9b5Ecu8LWk8iqTK/N+c34DZt8fdrLYpPI1AhTG6s/xTk2A46n14Ri0j4U+fAbzE3G0Cw9pgpyNAvarPEBgTt8l5ach06pA8gUbwre0DDwl/iLzoK3RPp7LPgWBckTvc0wkuBfx7pQiQFf0wQtYma4D+4pmXK7uz5POUX6SYCAFei/TkFpE62nMhQ69u2JLIb9mkJjFfJFR0sZAiSvjJ6cmtIsGAZWV6oLzMiN1PwrEsj/7mkHnIuqGm7qqkpAUl0tDbAF43GiyjQ/sDuviefoWgeKPrOBs/24M8IgnDVYPP8OjbVhHle6SpsTPiY2c8MZzwu9Pv2X6t3VMdoA73aHesDVIpSsd4Ir5Io95rNEVfjhLomUZis6qMS2ybSzB95u7ljsxfL/F70lqFCfmHAkL4510ok=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(56012099006)(11063799006)(4143699003)(10067099003)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?4MsTEWwLufj0XGW0kg4xA8JQV5HbfCK99up3iyykBGpVMwwOZc4L63C6pC?=
 =?iso-8859-1?Q?iRroVpdPwltGDc35/Olmvva5sxJUSPphrMtvwtrJVo3esqL0iOChRaPArO?=
 =?iso-8859-1?Q?7WbTMvOBWOzXtJw+fyNzMoJiCFmiRn56oCdLJfEmNFVgfEI4qzDp6nsxU3?=
 =?iso-8859-1?Q?6GjxIQrdB5WN2AkMUihxWrz19Rk1aMGOg0o9Rcfjxhvb91wZHPYynFiz+d?=
 =?iso-8859-1?Q?TSgo4WUnf6j8M7jw11PAwQQgX+ex9Qu8sTH3qifu+G41TXXumWuxAc+CyQ?=
 =?iso-8859-1?Q?NUGQPFA991qSPm4X4gk+aj8PZBNHPAvmC162mWRK710SlBE4kLrYnJn/PC?=
 =?iso-8859-1?Q?52/4gJai5w56sBiE+LoMFVmhpiUwOPl3RNPVFYKc1xgzRnlw659me78Imt?=
 =?iso-8859-1?Q?P3ogKm5B7UjG4SP67CrrMVYiW52vudi2xknE0ZG3dQL7xZtv6fHiVbRHRH?=
 =?iso-8859-1?Q?UiKXyytloIrapCVOgdF4b9jLRvjOuAUP5oH4VhikuGfHZdGHy1h8YCY6I8?=
 =?iso-8859-1?Q?dEMjv//8oG7vgZc5J6TRaYEVvyP4JnFN2Y52d3kzVLOLhkTX196xvXAf67?=
 =?iso-8859-1?Q?Zx/VlSrdTH/zSUuG8J2SzU4JKeg1AAGKA/GuxRtoMhfdulyL/sXa8S+WjX?=
 =?iso-8859-1?Q?dKZQaHp7HAZ5mU0LozCIa4c/KIpmZZyX+zOok+mgx7RSlgthKa2Y6aigZG?=
 =?iso-8859-1?Q?V2nTApoqLu6XVSXU+QHEZ0zXYQTEvWrHxlSg0WpCHy6ckgHubgQC1UWPHI?=
 =?iso-8859-1?Q?Qm1iIbf/UItwI6ZsSLy5dhIJPwU68upkkrEYm8q8QjNvhLfpNRf1vpoKU9?=
 =?iso-8859-1?Q?SOj19Vin/3BVd0EKeUgDvUEiV0O1Wss12rY1Ayl2+yT5ljiMGtqBJoY2dy?=
 =?iso-8859-1?Q?wojmTgWDgJUtYbXPtDsUHLEwd0gK31esC8uWLJGUo0I/LnSrJd9yUShOuQ?=
 =?iso-8859-1?Q?ARdg/DKg0KyWYCZjMUUZRM0a9nE12odacvyI2eVM6BscH+dYSgr0UVV/o5?=
 =?iso-8859-1?Q?u62YFNMVVOurr4b1Kgrn2lBXTgBhyQnC2xOM+6LwH9SfrkDoiTPLuECQYv?=
 =?iso-8859-1?Q?0SBXh5ZCOyFDPkHkLYtQW8lWArEGGSsrWs6V2MOhhpV3IRQ1R22jFmLXuU?=
 =?iso-8859-1?Q?Qy3c4TyjJqXKTJ8ml8T8yEBj9teVW81xSGysNoW0oI3eL6QXx8rxej8THL?=
 =?iso-8859-1?Q?2ga1aGDvbzZDrC2H10OxH3j2jqMVfTBkAiC2ij1RsDIXER4+nkcE67Dzam?=
 =?iso-8859-1?Q?3EC2b/6eNHQy5PAqg9fZBZ6qhbGZHBlps9APq/9TrOzBFP5aYrgpOpuzLT?=
 =?iso-8859-1?Q?6qHF6EV1yr8mWTlOAeeVj5robtoAuloVK6Olevha3Jc81wpMGdXVACnO49?=
 =?iso-8859-1?Q?YLQDDMm5x+NIyPGypcy2PAYvN38Hx8iOwH+zZyOwkUQAfDvIJcSxcfTjLi?=
 =?iso-8859-1?Q?7rDMUVS93QMEqTeDYIqLhBYaxtv+Fbv4icnv7XEkuDaIMMEubN+Ks+7eYT?=
 =?iso-8859-1?Q?BwNAo/rWRT3MFgBwlGzOEVzNpCW7b3wgDU8jNXVcKimzkTePtbIBx5S6J4?=
 =?iso-8859-1?Q?SEVhAFaitaqx8RSmntR+a5z5Xy9SY+VsvKgSrhrGj/qzL/RuvanPKL4x2j?=
 =?iso-8859-1?Q?pIuuiF5PvIgP4BEewy3mPhqSA9UBPzrXFkKA0Bv1dztBAaJKgfhsGOvkNO?=
 =?iso-8859-1?Q?+FqVu5JYSoYYt4ATFrhIlcYn8ltcxL8f4zQt39CQw/G2JlPcxyJHv3QSh9?=
 =?iso-8859-1?Q?ZOBuwEV3kyjx3NR1VkVvLtx7SI0pSOcFvFlj6clFXpKYHsVfF1v+t1zMgO?=
 =?iso-8859-1?Q?cjLBBye1vA=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8e387ad-18e9-4930-33ea-08def3a79db3
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2026 10:43:56.3654
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KQtrGXFI+BKnqPnlGYMBbEg32qCJAn5NOcRQPVxoSqTuwYrLqx7B/hPql9pVYh7nuStlOoDWH6mrQothEa+90EFjxXyToyuorEHiNYt8MWQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5503
X-purgate-ID: tlsNG-42698a/1786013042-A98C19EA-BEBCB92D/0/0
X-purgate-type: clean
X-purgate-size: 3155

> From: Ross Lagerwall=0A=
> Sent: Tuesday, May 26, 2026 2:23 PM=0A=
> To: Andrew Cooper; xen-devel@lists.xenproject.org=0A=
> Cc: Jan Beulich; Roger Pau Monne; Jason Andryuk; Teddy Astie=0A=
> Subject: Re: [PATCH v1 1/6] nestedsvm: Fix CR3 MBZ check=0A=
> =0A=
> On 5/26/26 2:01 PM, Andrew Cooper wrote:=0A=
> > On 26/05/2026 1:40 pm, Ross Lagerwall wrote:=0A=
> >> The existing code checks for any reserved bit set while the APM only=
=0A=
> >> considers it invalid if an MBZ bit is set. Relax the check to match th=
e=0A=
> >> APM and hardware.=0A=
> >>=0A=
> >> Some of the reserved bits were observed to be set running Rocky Linux=
=0A=
> >> 10.1 on Xen on Xen.=0A=
> >>=0A=
> >> Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualiz=
ation")=0A=
> >> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>=0A=
> >> ---=0A=
> >>   xen/arch/x86/hvm/svm/vmcb.c | 6 ++----=0A=
> >>   1 file changed, 2 insertions(+), 4 deletions(-)=0A=
> >>=0A=
> >> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c=
=0A=
> >> index 975a1eaef806..9ada491e57db 100644=0A=
> >> --- a/xen/arch/x86/hvm/svm/vmcb.c=0A=
> >> +++ b/xen/arch/x86/hvm/svm/vmcb.c=0A=
> >> @@ -347,10 +347,8 @@ bool svm_vmcb_isvalid(=0A=
> >>           PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n", cr0)=
;=0A=
> >>=0A=
> >>       if ( (cr0 & X86_CR0_PG) &&=0A=
> >> -         ((cr3 & 7) ||=0A=
> >> -          ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && (cr3 & 0xfe=
0)) ||=0A=
> >> -          ((efer & EFER_LMA) &&=0A=
> >> -           (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) )=0A=
> >> +         ((efer & EFER_LMA) &&=0A=
> >> +           (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) )=0A=
> >>           PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3);=0A=
> >>=0A=
> >>       valid =3D hvm_cr4_guest_valid_bits(v->domain);=0A=
> >=0A=
> > The APM does say MBZ for VMRUN, but the end result of a VMEntry (virtua=
l=0A=
> > or otherwise) must be a legal CR3 value.=0A=
> >=0A=
> > For 5.2.1 CR3 Register (Legacy) and 5.3.2 CR3 (Long), the APM states:=
=0A=
> >=0A=
> > Reserved Bits. Reserved fields should be cleared to 0 by software when=
=0A=
> > writing CR3.=0A=
> >=0A=
> > What's the real behaviour for trying to set a reserved, non-MBZ bit in=
=0A=
> > CR3?  On Intel it's strictly a #GP, and I really hope it's the same on =
AMD.=0A=
> >=0A=
> > i.e. I really hope this is a documentation error on AMD's behalf, and=
=0A=
> > not a misfeature we need to support.=0A=
> >=0A=
> =0A=
> An hvm32pae XTF test that does this...=0A=
> =0A=
>      write_cr3(read_cr3() | 1);=0A=
>      printk("cr3 is %lx\n", read_cr3());=0A=
> =0A=
> ... succeeds and prints:=0A=
> =0A=
>      cr3 is 105001=0A=
> =0A=
> This was similarly observed by the KVM folks in this thread:=0A=
> https://patchwork.kernel.org/project/kvm/patch/20200713043908.39605-1-nam=
it@vmware.com/#23578493=0A=
=0A=
Ping, Andrew?=0A=
=0A=
The existing check doesn't mirror what hardware does and causes real-world =
failures.=0A=
Can this patch go in?=0A=
=0A=
Ross=


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 10:46:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 10:46:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384571.1627448 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvcG-00018c-Ih; Thu, 06 Aug 2026 10:46:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384571.1627448; Thu, 06 Aug 2026 10:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvcG-00018V-G4; Thu, 06 Aug 2026 10:46:24 +0000
Received: by outflank-mailman (input) for mailman id 1384571;
 Thu, 06 Aug 2026 10:46:23 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wrvcF-00018L-Lg
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:46:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrvcF-00FJJc-2K
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 12:46:23 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a7465f0-5cb7-0a2a0a5109dd-0a2a450ce2a2-30
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 12:46:23 +0200
Received: from [40.93.196.47]
 (helo=SA9PR02CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a7465fd-f479-0a2a450c0019-285dc42fd2aa-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 12:46:22 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by SJ0PR03MB5503.namprd03.prod.outlook.com (2603:10b6:a03:288::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.21; Thu, 6 Aug
 2026 10:46:19 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0292.019; Thu, 6 Aug 2026
 10:46:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=n7PpmMRu13Cb0988JUFHrsR4dEaVBYXtkf5REmmf5G5iBQvsBgzUZUliI+lsgJhZcy2BVLB1GjmanNebzkaptef8Q/7+Vl9lHHVSm53lSSdRkNGAo8eDVYc0YozKplWi/zWuQVvOlQfSA490M31CaDc899uDhn23nIfVvn5V2juVT6CaGxlcYfHMYY3yGk0VULv8ZDnP0sImEHqJZd/5yqSOulDbARCfC6rPY8QO2y/LL6wS/DotYOBJPD/rb+C1/FyvQMoHkRzXgasXOo+kHZdTExWvUD6ilV1kJggyo/iABT1O7KT5GKOJUY5JWS5r+7Hy5gPnq2dI2/KnUigS5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zeAbZflcsgtYbs0Djv2pO3bp8Pg7BdliWHPU2oAikOk=;
 b=qz/QEIGNBEmaO7lLsFIJX6wfjlgwMIycEqvkpj+TeVMs97mbN/sg3j/ViKI8AoMReDA1x7CqCFkkBWtURbV2FTt2EgzclkkeLWF/l951Ks3X1Fz67hMTl8SU22Iq5mIOJ9oA2HqXCyijQLOX6P15wY76jcNP7ukwlqucgCuWSnEf/d7U0yo9doJ2HAlfN1OzeeBjGQEL8E038N7Tm7IU1X2RRQ3X0Hw1+FcZBZ2z964ZcFWy5Lxd+e+7+YBShCpXl4L590T1yRKbnf9XJGd+rYkepIkXg4ptSYpySlzagpuy9BORriWiPSrHxILgxQbM5yKYnHUuGilqs8fZjotJ1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zeAbZflcsgtYbs0Djv2pO3bp8Pg7BdliWHPU2oAikOk=;
 b=hedUaixTku8z3Y2Qq8I9RsS3bBCDxiVBPipExXoeamqRlmx9t8tfUeVbHt2O72DNxI2jVuy1el2OPVPYNFeBBBuYQnxUA1L+Wth6d4ET6F1/uA/8CRtb70uparNrrlaSzb2gIRyeqUKubkBonFSgvEJ5tRztTiMKmp4ODkGcJ7I=
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>, Jason Andryuk
	<jason.andryuk@amd.com>, Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v1 0/6] nestedsvm: Misc fixes
Thread-Topic: [PATCH v1 0/6] nestedsvm: Misc fixes
Thread-Index: AQHc7QzgdzWBfRT220y6Z9wl6s7+W7aRRvIr
Date: Thu, 6 Aug 2026 10:46:19 +0000
Message-ID:
 <CH8PR03MB82749DB863DD5566B83C6DE0F0D22@CH8PR03MB8274.namprd03.prod.outlook.com>
References: <20260526124027.573412-1-ross.lagerwall@citrix.com>
In-Reply-To: <20260526124027.573412-1-ross.lagerwall@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH8PR03MB8274:EE_|SJ0PR03MB5503:EE_
x-ms-office365-filtering-correlation-id: e545e8d1-cc4e-4d33-467f-08def3a7f337
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|56012099006|11063799006|5023799004|10067099003|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 +DBpt7k6bS8bMBa2Sm226Sf4SWa5djM80KgbdvWdf6PAVO6a6fiAsi9+L+jbf5K/6zhg8jsvWN4TV9RQnbmi8kjfOtXgLK29R9wb/YLxcvYIK1gzo10cS7lXaxYIVkljygkZ4kkZOYULQtzkWA/2ISZuOtrQ0uJATriY5J365ftJ8YYxYHxMzWHARPVeml+FONeKXWSkozi8kdbMROyehJkQ7ak0H58efYdpqFiXHhWow+1wnVC1Os4iY4CDWCCWJ9BJGtoQ/RZ8kKGM4r/Coc4MyjYMyYVrsTAsNjEqpgMYhXp4rgl2bgFXlzBR8LfNDK1sNJ2yfwRg0XkyHnVnRIvuhI5FWQbrML9qYFRqtEEWygzBcHgVQDynQQpt/e8Y9xy+NZlcitYXJ+GRMh81hUEuSkXSQuz0Uq3nNcF3auPxVNOlHgPp/Ti+0I9a2r0Bkq1wju6KqRnnvhaw0bOMrW/HB3i2hg+MhKXzjr3hQ56G0Z35Pkkfz2lst/lfr+LawsesYrPGwj1oPmviVi9bcKkET20zbe5wDIAGsB888F43tTGJYqUVXR+j8zDokxpzUHyXBjT+QSHwo2347afbIkA22sGB7p1GlxQWFgN9JMDNmCck3zB+mR5VtqlkZCGlnfkEEVgecw1gh7fOSS/hp6rxmwK2JumY2crTQCdsBfV1iHLRdwURUGiEp98Qdi2BZ/uIbqMnhWRu1GYHcC9dvhsC43a40Q7HRdU6ijL0ZUs=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(56012099006)(11063799006)(5023799004)(10067099003)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?qEGHupsILwS+48f/krHsv4ZXJ2RdoZUgVTwsmm2jNninBGw4M/cHG1U6G8?=
 =?iso-8859-1?Q?peI9JMYYB/R/5TCJNqo+I27IaVixvFQxyJjHCTw3ME0qxyiZUG5j/zSGXB?=
 =?iso-8859-1?Q?1dSckOz706OYjoR16js0Z72cpyQpEBASdSiGIvvIUf2IjB/WcerbJGMLYt?=
 =?iso-8859-1?Q?PobAKZD2d/DVWFam323VbCTHmdq2tVDTta03AZqCmTA6us7E52aexwUwP9?=
 =?iso-8859-1?Q?3V32FKnvSoAX/li2yeyY+0NPsExZAXS4MvA7itVie06rPeTOvH/nYB7bc8?=
 =?iso-8859-1?Q?w/GvCL8taIKAbfaM0NCs7YkWYVIw9shZ6rAf4EKEowh3D2HfoVzXsjjBnX?=
 =?iso-8859-1?Q?w8jUiv+7HquPB6DEoKQNDNWjOJ9NHP0dGMV5tBYo9dOrUbIOw25mcyJT0E?=
 =?iso-8859-1?Q?yndjyk/85p1XOFT30PQq0rqn1UqFZelnC4InSzl5otVrW2X+BIEzzS06RZ?=
 =?iso-8859-1?Q?KvBY/pfwX4lUMSz0fbEV5xJQKfVXLr2lkSIvoiJw5T6XSI+3lOvLORdTUN?=
 =?iso-8859-1?Q?/QFNKqzoXyK2DXWJ3sNbTQi94OSm+8ZZDMGclBQJUCItOvc+RF7ZN5si4Z?=
 =?iso-8859-1?Q?xuiP2YnUY+DNJMRVZxLE32Nu8aQCjWxFFgkW6mViogqTCWk9+8S7IFlUUL?=
 =?iso-8859-1?Q?+WIH/vdRPwMxUVnc+Jqy8zz8Qz/FmJGvPBcEaaj7kShvvGJk/s+1EAfY01?=
 =?iso-8859-1?Q?khyIHjYoRVP9IcTB2EvuHRh8S2eAbpwwBcng2RJjPmy5LLTf+dmDVvVRFP?=
 =?iso-8859-1?Q?7umxuFaT+SRfxrpZCZkFlbjbKDPfx8etPIgSOA29UoGZ8Tac7WSn/S9WQU?=
 =?iso-8859-1?Q?pyqlb8l4KHJEmnxEM4EMo4mXZv69LuzciG7wBK8orgaKQ0tW7afGRfYgLy?=
 =?iso-8859-1?Q?XaqKLsznnqzHgLqjSTr49KoxmspdoPN31gOdfzmN3bNeQPRXHQyWv3KIrW?=
 =?iso-8859-1?Q?di28O+BXwSBfr7I3+rMGiwy8ur5xH7GsqbEv+TEgjKcgIyY7ygICAU0jhK?=
 =?iso-8859-1?Q?JVvOv+NqjqHLj6ZWz0PuV89Mqzf6kLRJR6M4PHuWf50+kisIXuvVt7MJYA?=
 =?iso-8859-1?Q?XpbDC6/+58oxyN4YuF5GXNa7xXEKScZ81kSsg9J4YpnDUMDwSZLeWE7fRQ?=
 =?iso-8859-1?Q?+riDaWFJz25B/k4FnB4+STjnheU50DOBA7TkB/0IgNAszTpp79p/MEdze9?=
 =?iso-8859-1?Q?cDA6eNebsrUoPeELNuoPNtAVkO60vC6y3oMn+n0xWtyf9cuB37CRKpmeeA?=
 =?iso-8859-1?Q?Bx3Mudn3nofceQ/2ogNReoB24rsco4oJvC+FKqzPF67s7vvi4w3HJpnjOo?=
 =?iso-8859-1?Q?YH6FIdNDTLGjMplSvKuqCxVJndNrthyvoZuD1wb5amV+GCm+dIxHD6XgaK?=
 =?iso-8859-1?Q?2aM7mBEEjBaRdjh5zawlQWPICYDrRO/hAchtO6U0MZc72LIcbMXmKTiIgQ?=
 =?iso-8859-1?Q?5imvlw1ZI/kdmuxoYdWFqygTuPrsUIWcnfoYYahkyviLjJVPHZj8f972oR?=
 =?iso-8859-1?Q?4Kch14qjHPB8P/xGqMy243Ijo0pTHYDo0GX3MkWbCfFK7k5K01LeV0qfgQ?=
 =?iso-8859-1?Q?cu3T9OEvRATRQm3eExVkiHtrFydDnnY4RLVRsTbHTGAJQSvhCVzXdXX7Zt?=
 =?iso-8859-1?Q?wFSujHVuzKJ/RRrqECeqfNoRqlTWYsLKqmApfeyHBy/S/3B3/5DqI2WJ79?=
 =?iso-8859-1?Q?oE6o+FkFJmGswbUx40EgUMmSCWR/fQHCSdvLm6oouPaPOIcKkzddEAKBS1?=
 =?iso-8859-1?Q?R3P8CPFISmW1SJtpgZgoNmBkdH2aCpCuYz/y5Q2lmPLjHEdKfAL/b6C8SP?=
 =?iso-8859-1?Q?7WF9JJz1fg=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e545e8d1-cc4e-4d33-467f-08def3a7f337
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2026 10:46:19.8251
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qV6bCrhHmZxwy4xS/4ljTBTPkh+bg0tQtIkWjNOnl9CIF7F6kUiL9dpCrn/fKiN9J8eWeNqGieBSh72szuA5Ye/OQVE6CxlcsdIoTM88IyI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5503
X-purgate-ID: tlsNG-d25034/1786013182-032D8A5B-C2D00A0C/0/0
X-purgate-type: clean
X-purgate-size: 1234

> From: Ross Lagerwall=0A=
> Sent: Tuesday, May 26, 2026 1:40 PM=0A=
> To: xen-devel@lists.xenproject.org=0A=
> Cc: Ross Lagerwall; Jan Beulich; Andrew Cooper; Roger Pau Monne; Jason An=
dryuk; Teddy Astie=0A=
> Subject: [PATCH v1 0/6] nestedsvm: Misc fixes=0A=
> =0A=
> Before this series, running Linux on Xen on Xen on a modern AMD=0A=
> processor would lock up L1 shortly after L2 reached the bootloader.=0A=
> Furthermore, L1's domain could not be destroyed.=0A=
> =0A=
> After this series, repeating the same results in L2 crashing shortly=0A=
> after it reaches the Linux kernel but L1 survives and its domain can be=
=0A=
> properly destroyed. This is not great but is at least some small amount=
=0A=
> of progress.=0A=
> =0A=
> Thanks,=0A=
> Ross=0A=
> =0A=
> Ross Lagerwall (6):=0A=
>   nestedsvm: Fix CR3 MBZ check=0A=
>   nestedsvm: Adjust L2's DR intercept when adjusting L1=0A=
>   nestedsvm: Use the correct VMCB for vGIF=0A=
>   nestedsvm: Set GIF during VMRUN if vGIF is enabled=0A=
>   nestedsvm: Fix deferred event injection=0A=
>   nestedsvm: Allow destroying the domain fully=0A=
=0A=
Ping? Can I please get some reviews on patches 3, 4, and 5 please?=0A=
=0A=
Thanks,=0A=
Ross=


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 10:55:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 10:55:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384586.1627459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvlP-0003xH-FD; Thu, 06 Aug 2026 10:55:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384586.1627459; Thu, 06 Aug 2026 10:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvlP-0003xA-Af; Thu, 06 Aug 2026 10:55:51 +0000
Received: by outflank-mailman (input) for mailman id 1384586;
 Thu, 06 Aug 2026 10:55:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrvlO-0003x4-FH
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 10:55:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrvlN-00A61n-SW
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 12:55:49 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a74682d-2eae-0a2a0a5409dd-0a2a4507b530-20
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 12:55:49 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a746835-b4ea-0a2a45070019-d155da36c597-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 12:55:49 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c1c24ec9525so325530266b.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 03:55:49 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c203642435dsm235407766b.44.2026.08.06.03.55.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 03:55:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786013749; x=1786618549; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=xWlyahj/sMjy6rjl58blxQkLJ8D2LwIzxmQQ1iH7RK8=;
        b=cRTT9L98pyCyyGRAr6yVPOiK359gWpF2b2nft3GqSddxkIar1MIPIknJvbS7TK4jKP
         855O6hhyrnn9JbUFEdPRuK1VMURhRrqrZMQ+R/19Mgx3wkx1fp1D7upSMdg0frNJm+aO
         4Ve/2h8Ry44MtgLBNBToUYVKBtLNkHZVCh7zNJ5RnywA1wZfV6Ow3lHFINjqx0EcBQ4L
         M5J15y6VJXw4jrMutQ4yN5WibrLsCrHxzxzmI3Wp7fUSuPdivxgU3D1ZHb4RqmmLkzFF
         IpVcCmxYXQmPdIS3iPwc7NoCzKRq0W9CEq+N2/Ox0XkPSBdilKlecl7r41+g3d+ejUo6
         N5UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786013749; x=1786618549;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=xWlyahj/sMjy6rjl58blxQkLJ8D2LwIzxmQQ1iH7RK8=;
        b=UdWe0/toFAPhcrvHMCcydKwLlAE6RXxOx1FwP2v8FLedSF/3EuSOthbWxjNG89uctu
         WwZdQBL0TxAnBvSz7o9juh2NKjTqh1yaB4xGdz8lio5Df/9BCUi3T22YknlENoMhgxls
         QzwMc2ZVicwoF1heX9c28VxenwguEnyg6yd641isGFa9ojBIpzuzrZgCIpz7th4f4tsb
         ezABykdD17dNl61DKLG/jBO4JgWaQemeRUSnOWH+ykpb8uuvCY2cIEEZWkRYDzTSM2vB
         FyDimyMwNA+w5OI5SUe1Or6zyS86So/renk3PZFKRYutbSkH3F7wFiNwiAYQcCuMqj++
         PpWg==
X-Forwarded-Encrypted: i=1; AHgh+RpInJmP+NdGVN9CIhpjf2PobKusA9KkfOcWT4oEuZ9fApm5WeywJObR0hLQzG/jGI6z0DkZOajJp3Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyeDmjqe+aaY2CjhJnf6s4iviTKRpX8nbEyAf11afn/ruSEAPpx
	oigzfLhtMwBATTq7JsEyEA+T63d2GothCdklqL03fNNvHfRlu/li4KOmSeeqbfkxyg0=
X-Gm-Gg: AR+sD12NeMn0m1dmIB1CInzMIbI73CV6fYoGnPmMzbY3b0S6ggmoOpWmTDaWDQ/JYkt
	TC4j7f6PyyCIlPMmAbNWdslHfzJSeGnbytPilIwv0ioXWgHvTjqbbGO7Tz1EFSWhMvI/oIJA2Lx
	4Vl9X7IMqzfmNlxla4uCa2Y/LWieBlU73UUryIf2DZguh8/0qHzb5QmWsEOvrMTDOnGIj7bfi0o
	aOre6Wp4nLcQhhSxoI+98Mi0idhWPCSk8FaZgSVI8n5SC2Ammswl0OlOAeqI1z6mAQ9gZmvfj4f
	fiA5GZWpO8I85OY+Z8khI8rpYtyMbD/QBGbyOAev2Pe5+lME8WhvM4u5pxLxE3UipvQH6QJtRjK
	/4w5ZWHHr8BZ4sXbEUKhYn1We/zl0//45WTVgfjBtm7PqTPZArvyNFdEggzIoIN/PlPwYxPVm9t
	iEVNYW9WgRcYCHQXqSnVD3XJLwro/defxF5bUv4uoYgDoz/cIIhDf5apXzhyAiBFDM4WNVGIe45
	cHcK1kmCvGniHuPYortlCEQCrqne5wOVg3dPv+DISUzGH2KpS8Ch81dhgWvL9PrhgBa+fJbR/kn
	CKyAcGx6oWVb7IPilmOtX41eNUE=
X-Received: by 2002:a17:907:97d3:b0:c15:e33b:8c4d with SMTP id a640c23a62f3a-c2039ad16a9mr695343566b.4.1786013749295;
        Thu, 06 Aug 2026 03:55:49 -0700 (PDT)
Message-ID: <083db883-558a-4000-b404-bf170c8309ee@suse.com>
Date: Thu, 6 Aug 2026 12:55:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
To: Jason Andryuk <jason.andryuk@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Jane Malalane <jane.malalane@citrix.com>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
 "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20260806015233.202486-1-jason.andryuk@amd.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260806015233.202486-1-jason.andryuk@amd.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------gzu0resIcHTErGXU9L6jffqY"
X-purgate-ID: tlsNG-ef75cf/1786013749-A7AD0AE4-1F58DC6E/0/0
X-purgate-type: clean
X-purgate-size: 7261

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------gzu0resIcHTErGXU9L6jffqY
Content-Type: multipart/mixed; boundary="------------L5O05nTVmBw2yqdmWVg9WV73";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jason Andryuk <jason.andryuk@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Jane Malalane <jane.malalane@citrix.com>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
 "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <083db883-558a-4000-b404-bf170c8309ee@suse.com>
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
References: <20260806015233.202486-1-jason.andryuk@amd.com>
In-Reply-To: <20260806015233.202486-1-jason.andryuk@amd.com>

--------------L5O05nTVmBw2yqdmWVg9WV73
Content-Type: multipart/mixed; boundary="------------dAXaIYIpph80x9DFkCdb7Wm8"

--------------dAXaIYIpph80x9DFkCdb7Wm8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDYuMDguMjYgMDM6NTIsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IEFsbG93IGRpc2Fi
bGluZyBYRU5fUFZIVk0gZm9yIGEgUFYtb25seS4gIEEgc3R1YiBpbiB0aGUgZXZlbnQgY2hh
bm5lbA0KPiBjb2RlIG5lZWRzIHRvIGJlIGZpeGVkIGZpcnN0Lg0KPiANCj4gSmFzb24gQW5k
cnl1ayAoMik6DQo+ICAgIHhlbi9ldmVudHM6IEZpeCB4ZW5fc2V0X3VwY2FsbF92ZWN0b3Ig
c3R1Yg0KPiAgICB4ZW4vS2NvbmZpZzogc2VsZWN0IFhFTl9QVkhWTQ0KPiANCj4gICBhcmNo
L3g4Ni94ZW4vS2NvbmZpZyAgICAgICAgICAgICB8IDggKysrKystLS0NCj4gICBkcml2ZXJz
L3hlbi9ldmVudHMvZXZlbnRzX2Jhc2UuYyB8IDIgKy0NCj4gICAyIGZpbGVzIGNoYW5nZWQs
IDYgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkNCj4gDQoNCkkgZGlkIGEgY29tcGFy
aXNvbiBvZiBhIGtlcm5lbCBidWlsdCB3aXRoIHlvdXIgcGF0Y2hlcyBkaXNhYmxpbmcgWEVO
X1BWSFZNDQphbmQgbXkgcGF0Y2hlcyB3aXRoIFhFTl9QVkhWTV9HVUVTVCBkaXNhYmxlZC4N
Cg0KVGhlIGtlcm5lbCBidWlsdCB3aXRoIG15IHBhdGNoZXMgaXMgNiBieXRlcyBzbWFsbGVy
IHRoYW4gdGhlIG9uZSB3aXRoIHlvdXINCnBhdGNoZXMuDQoNClNvIEkgZG9uJ3Qgc2VlIGFu
eSByZWFzb24gdG8gdGFrZSB5b3VyIHBhdGNoZXMsIHdoaWNoIGNvbmZsaWN0IHdpdGggbWlu
ZSwNCmVzcGVjaWFsbHkgYXMgbXkgcGF0Y2hlcyBoYXZlIGEgbmVnYXRpdmUgZGlmZnN0YXQg
b24gc291cmNlIGxldmVsLCB0b28uDQoNCg0KSnVlcmdlbg0K
--------------dAXaIYIpph80x9DFkCdb7Wm8
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------dAXaIYIpph80x9DFkCdb7Wm8--

--------------L5O05nTVmBw2yqdmWVg9WV73--

--------------gzu0resIcHTErGXU9L6jffqY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp0aDQFAwAAAAAACgkQsN6d1ii/Ey+b
ZQf/eR48/c6KEp1olIh7+JTTsmH0G/RHs3eVKzlrAUmx17yAJxXhxEBiCbNuFtTdpRc4SFAWWi2d
XLjAxZtiokcZc5oGlpwzz/wgcoKdlAmbUeEdUHo/dHPeWh2SHHK51pEPMq0QCr/mawOqo85QqtGp
hG0KNePaAbCA7n/sQWbU5ZBmZ7dZfkpK/bksP5KWv198P4M4QsdAIV+xZnzGLf5ffnV8e7LjGu+j
j3QLat8JdlvwVnI14qguA8Ce8D9GQopQXd497qZqGhLWtP7UZWxSLU2FVVGL0I2LN7XFsVbTDJqm
+WltejLIAw3PP+bhWWUuu7eWKoonlNWr0jlf50QEDA==
=Bbn+
-----END PGP SIGNATURE-----

--------------gzu0resIcHTErGXU9L6jffqY--


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 11:00:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 11:00:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384596.1627467 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvpX-0006V1-U5; Thu, 06 Aug 2026 11:00:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384596.1627467; Thu, 06 Aug 2026 11:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvpX-0006Uu-QR; Thu, 06 Aug 2026 11:00:07 +0000
Received: by outflank-mailman (input) for mailman id 1384596;
 Thu, 06 Aug 2026 11:00:06 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrvpW-0006Ou-GT
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 11:00:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrvpV-003tIU-TI
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:00:05 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a74692f-2eae-0a2a0a5409dd-0a2a4506aafe-12
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 13:00:05 +0200
Received: from [52.101.193.22]
 (helo=CH1PR05CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a74692f-195a-0a2a45060019-3465c1164473-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 13:00:00 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BN8PR03MB5009.namprd03.prod.outlook.com (2603:10b6:408:d7::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Thu, 6 Aug
 2026 10:59:57 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.019; Thu, 6 Aug 2026
 10:59:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pm7bPBJMXXONYi0I88alJYlXPKHEETQns2Lq6MM6ufsf5Zujl8aLgqn2olczTwjJx8JmJ9DG2LFzpDuExmSvSad6l5w145/vejTxtUcAoLFs/IUJ1QF+UHMH502w8OTEUIbG7HvmKyt7C+IT/6fC1CuzzHBr9t6wTYo0qwQQvqHbhjSW3biYRZ7iezwRbKqXTlBkvK1s5FiAw1fzbO44/OkNOfgk3dem8iCtkOmiwYDfxzjE5oM9iJUmaAIUTOItV6EMmBLdOeXrBAs3oNXmd6MQJU+SWQzj9udMT3vza3hfQjnn+rwX9//xNzWY8Rie3V6vnO1zegsm/nrA2Y0+1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L4+YmngKR9FGyhYhU7floGTmr7QgSYAhmIaPMsg8CLI=;
 b=A9SZ8niV58ojXzUZEeKcS1Pe+41DqNE206ry1slePt3vLbi8KFlrxIaJew7zv8N5NdfbfQ25XATzpKSMOnqNyYWs+8+zhJk8RcR5GJjBUIBsnX1kqs7acWlpt0fyPbWnsJs2GJ+PlWOMm7t58lzf/ZhJU6Am2OrmAZK2yviJhCEQCVynk60HaiOg8/+ylv4UhDpadEAQNA6cNQogsjEjFXaJ/S1q4EWZjAgaE6Kd8/YMPVPEZppjx2MkJXPLZYmYITMUPQZ7o1KjERBpp8nJ6TU6h33dsg496kqPrvWAB7p6PZI1s8rSMl2ysD+oJTjphvmAfvh+rkeWBhb6dyVpGQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=L4+YmngKR9FGyhYhU7floGTmr7QgSYAhmIaPMsg8CLI=;
 b=zS7Az9w2rM6lKS/CnPueFkKbl+w+5u/3hJHSDdQNTTa3YBBLdeAZuBCPsiB4TT7C0Dumlv0cDsLOH2okPykWnpyWc1MYxRdp6szaNhSYJUkySztnATeIUdAhxA3b0eilRFazOpTjnhgTCH/MK8I8rJIUSRJoweO1qP7jL9hAoiI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <0835710d-f67d-4678-ba39-4597b9c9c7f7@citrix.com>
Date: Thu, 6 Aug 2026 11:59:53 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/svm: mandatory update VMCB nextrip for soft
 interrupts
To: Chunjie Zhu <chunjie.zhu@citrix.com>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Jason Andryuk <jason.andryuk@amd.com>, Teddy Astie <teddy.astie@vates.tech>,
 Ross Lagerwall <ross.lagerwall@citrix.com>
References: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260806031732.10242-1-chunjie.zhu@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO6P123CA0022.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:313::15) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN8PR03MB5009:EE_
X-MS-Office365-Filtering-Correlation-Id: ee720e00-172b-483a-e881-08def3a9da3f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|18002099003|22082099003|3023799007|56012099006|5023799004|11063799006|10067099003|6133799003;
X-Microsoft-Antispam-Message-Info:
	BX95SAXDWNVICk1QG2ta7bzegnXgdzlBWLxE9qH2++UPqC6GDzxeeoFBiO2iLA+l+T86AMjBsB7Uwy+BCT2bVMzty62XrA17JBBvfN8KaEN+W3PIOCf4MtiNXOYVRO7kGHTenqVPqYW5JMBMmu6Qz8Hx2W8n4a5aNcfbwpE4PW2hJ2xS2oUrburjh8T3gAYAY7NbSqdD/634e0SaMLG1xkvbkeaAccgxLTKp+tJaJWrwiprYbIKVwYNmJg9kz5nIqlvJ7BRcGaJACNdYSqBiXWLxcgdW6orMjnzBuOrt2PfvYxVbQ8QO/b2GkWrqA8F0HZ6GVlG4uj7Mz3JdJJqV35qx7lkUJUONPdaKmIMdEfJcvFPNb6KaYD9+DOsXsgL6WFiQm1nIdRoO1CvRdh2ul/YkYxXHH5pPr0Rvyd+dFxCGf6fp9zD8jEewUTopwfsTcD3ddEevq9d0uBLfSPMk0xpQe/krRDcOm7edkqOFhtaxDYNFn77anDMuaBFE66alXjC5tP66CIbQWFag1uLS4XfFi20mMHtqTD6bF0tcvqcYgBF9uO+mo1QGMAbu45481iZGl/q2NsNSzb2O642QovLj1ibVaR5jIxLeFg7Z962olwP3dchqr/c1UmBD0+ehJ6eIAp95BPn6bebWbqLyEsJ95WEwFwsV8uKgKr+T0WM=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(18002099003)(22082099003)(3023799007)(56012099006)(5023799004)(11063799006)(10067099003)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UHR0bzNlQmxwZmcvdFM0OWF5N3dERnNDcVhMVmpVQWQ4M1A4NU5jWjdadjNt?=
 =?utf-8?B?VUwwdHFuSUYycnViVklzV2ZpVy9yVVE2NzhHdjJSYVNUb0JBTTNnWkxXODFr?=
 =?utf-8?B?VjJqcXRzWUFIL0hYRmZCUWpPZTBWUHZJTGxoV1JvN3k1bzBlMUhpdmFVRXNi?=
 =?utf-8?B?N2ZqRDUvcyt3bWh5anZ2VWJNaGdLTkZvSmV5UmFweVZvVmxUcnc1NDhjVVBi?=
 =?utf-8?B?RVUyWHRYT1VhS2JJZ1I3S1EzbDk0d1RUNitLTFErUDV6TUhJN0JYRzc1OUxH?=
 =?utf-8?B?bkV0RFVqdW5OSzV5Yyt5MzgxdndxeTIzSFZMMUdPUzlqaUpTdVVHTThXZE1I?=
 =?utf-8?B?eXRlNGY5V2ppWHJ4MXhZYWZmWklaU0xhUUJFNEhRVnhtVnp6WWlTV2MwWFYx?=
 =?utf-8?B?dnd0c2NnSWlyTEtNNURObzdsTkVGdWlJSWNCeml1OGlTUkNNdUl3L0hHZXJN?=
 =?utf-8?B?b3FPSXlNUDRIMHh5N2dlQ2M5WU9YTWRGNW5kbG1kL3BDdVFDajhWN1JBSEYx?=
 =?utf-8?B?ZzJrNW81c055RmxhVDVjenNNR1hXbW5PYk01SmdCemx4RG1rZnZPc2xEQjhS?=
 =?utf-8?B?VG9HQnR2MlNXWFVzM1oxeDg5V0crc2tPM25RUEFhTHZXaDBzL1hpMVBLek1n?=
 =?utf-8?B?c210Ykl4cGRSUm1sNXhyN3FlS0pNaUh3MDhHWmc5ck8vS3Bhd1NwOWRoSXhW?=
 =?utf-8?B?UEllZW5ZY3hjZWpWQUVPVmlrR2I1aW9PVk45Rk95bTBjRmdXVnlIeW9rS1JP?=
 =?utf-8?B?Tjl2UGZ5VGFkelNvVlJYbzhLbHh0TlBwbml0RkVzYmx4MndlRHRtQmE5cnV2?=
 =?utf-8?B?bXBEc2dxTFJtREFEL2VkU3BQeGZ4OGRQaFp0SDdzdVliOTA5ME0xUjlWYlI3?=
 =?utf-8?B?Tm8xU3NkUUI5empGWVdZbGJwTkxvazc5bDdMQ1VpYzVvMkNMQWRrL2NZOHJZ?=
 =?utf-8?B?TDIzZEZ0QTNzQ1FHUkorTnd6bEdld21USUJYZVpZclRHZitrYUszak5Id3Np?=
 =?utf-8?B?cC9SaUh3bGZEWnJ2WTVsY2J5RXVtWVVhRnd0WTgrQUNYRXllM2RBdGFNUVNR?=
 =?utf-8?B?U0xxOFNuVWlpWVJhVUMwUTc0L3MrZk80clBRYTl4SkhhWWhpdXh0cy9FYS8w?=
 =?utf-8?B?SXNUTzBocTFLQjY2SDM0dk1paTQyVG9DRkRlR0VxSmYxZ1F3eVpVSVRRcU41?=
 =?utf-8?B?UzExWFZna3ZqdEVsQklBV20zZnRvTTNxdzdwSTlabkg2dnA2Y29yemdDUFo3?=
 =?utf-8?B?d0Y5ZUZjUmt4SGdtMysybGdEWUZmMHRyc1lIa2s3TWp6MFd1Ry82WmE1VmVP?=
 =?utf-8?B?US9tV25Dd3U1STZpUlZGSkYvY1Qxc2ZGRWJuTCtpREkxaEM3VHJhemcxTVdk?=
 =?utf-8?B?blNlZXFrZTViK0VFZW9mV2lJUFpQUXRoSXNwb3dqQ1Ezd2kwRGJWc0hHb2xa?=
 =?utf-8?B?djdEK25pZUlRUHA4OFNlZWNva1FUOEFrUWZXN3NvWm9Wam5qVzh5M2Y3emJn?=
 =?utf-8?B?L09QT3dGSkpxV2tmTmNCQ2ZBajRCTUwvQjEvbXhsU1V3dzJuV3ArcEZOcUlO?=
 =?utf-8?B?WTQ4d0RvWUJhNFE2Tjg4dzBySmU1dGprMlAyTm5Wb08yRGhIdnZWVi9GVGR6?=
 =?utf-8?B?cEFMWCtjTlh1bVk2SzUwRDFUZllTajhnTVhDeEFKWUtveVptdTFaVHErSnpM?=
 =?utf-8?B?eFJhMkhLWjR0MGc0WHNOTGNLR0FFcDZ3ZXQxNllnMERPbS9jd2FxS2gyS1k5?=
 =?utf-8?B?cVVyZCticWs0Y0NlWmhxYlJNdFNMZUtkV1VtV2dKdStOeE8xYWhWRk5OcVVu?=
 =?utf-8?B?WVZrRlFrbURveFR4NFpaSmRtcGJmQTR2QXlHU2xUK2h0UFpmZEFPYlpwU3VC?=
 =?utf-8?B?aUQvM2lOZkRWOTdTWGxPSko1SldiVDFCblVmb01TMFpuZEN4QzZaSXZDNVkv?=
 =?utf-8?B?cTlsVkNUZ1JZM3VlRExKZkp2OURMZWIwOGtJb3RJR2c4S3JqVWkyTFdyblh2?=
 =?utf-8?B?eHg1NlFVNWluNDkzOW04aVpER3Fmb29rR2ZiUDFkZDhON08vakJSS05jUFV4?=
 =?utf-8?B?TDVKL2JIeTlUY1hDZnVFSjZRdDZvOXF3NzhlK3poRGJXdHRjcEZXamRvOWVH?=
 =?utf-8?B?SmZtbm82VllrMGJnSVNFMFEwL0tkUm1mTDN5OWJpaWFRc3F5Zmpkbnp3NGtv?=
 =?utf-8?B?TUs3UitvWVVxVmVRK1d2Y0VQa0JaTG0rS1EycWg1Rk9NTmgxMDJ0bWZxTjNa?=
 =?utf-8?B?ZGl6N05EbHhYZFIyUUxHeVE3YXo4NWJhUUsvWXNrdTgzVitqR1g4SmlVcXBF?=
 =?utf-8?B?TXBaVnJxWFhua3cyTExUbmtzU1phbXhBNTFld3N0OE5oeFl1VThMUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee720e00-172b-483a-e881-08def3a9da3f
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 10:59:57.0560
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: T60YekYCeS5qEIpYwVwc5V5fumLbO9EI2tMvM9GH1P5qS34enDdRpROebXhU4cLA3CeMeNkMzu8WywBZ61dnTiJ7mY5SiKvH8WZ6HR0T2zQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB5009
X-purgate-ID: tlsNG-16d1c6/1786014000-F72C677B-10A13D00/0/0
X-purgate-type: clean
X-purgate-size: 3058

On 06/08/2026 4:17 am, Chunjie Zhu wrote:
> Signed-off-by: Chunjie Zhu <chunjie.zhu@citrix.com>
> ---
>  xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
> index b06124c2c9ed..815713b8b506 100644
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -449,7 +449,14 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
>      n2vmcb->virt_ext.bytes =
>          n1vmcb->virt_ext.bytes | ns_vmcb->virt_ext.bytes;
>  
> -    /* NextRIP - only evaluated on #VMEXIT. */
> +    /* next_rip is consumed on VMRUN as the return address pushed on the
> +     * stack·for·injected·soft·exceptions/interrupts. This assignment
> +     * statement must be enforced, otherwise, it might cause vcpu wedge.
> +     *
> +     * APM Vol.2 Event Injection does not specifies what happens if NEXTRIP
> +     * holds an invalid/garbage value.
> +     */
> +    n2vmcb->nextrip = ns_vmcb->nextrip;

The old comment is indeed wrong.  However, this comment is distinctly
out-of-character for the function too.

As for the text, your subject probably wants to be "x86/svm: Sync
nextrip during virtual VMRUN".

The commit message needs to say that the NextRIP field is consumed
during event injection, with the L1 hypervisor being required to
configure it appropriately.  For a garbage value, the APM does say; it
states that nextrip is always what's used for traps.  Nothing checks
that ->rip and ->nextrip are within 15 bytes, and you can it to
arbitrary values and hardware will put the value on the stack.


Finally, there is a fun problem when running an L1 hypervisor which
can't see NRIPS on hardware which does have NRIPS.  In that case, the
correct sync is actually:

    n2vmcb->nextrip = cp->extd.nrips ? ns_vmcb->nextrip : ns_vmcb->rip;

because for event injection the L1 hypervisor will have had to move
->rip forwards for anything with trap semantics, but the real VMRUN will
still read ->nextrip even if the L1 hypervisor didn't know about it.

Note, we don't actually have the cp->extd.nrips field yet.  I need to
dust off another series to get that fixed.


NRIPs has been around almost forever in SVM terms.  It was also a
breaking change when AMD added it to hardware; while you can ignore the
field for the purposes of instruction length calculations, event
injection still requires it to be set correctly.

We only offer nested virt on NRIPS-capable hardware, but we don't have
any interlock concerning the guest visibility of NRIPS.  Given it's age,
I suggest we don't try and care about guests which can't see NRIPS, so
our safety reasoning becomes:

* Nested Virt is only available on hardware with NRIPS
* NRIPS is required to be advertised [*]
* Therefore the L1 hypervisor is required to set ->nrips correctly
* Therefore we can just do a simple sync with no conditionals

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 11:05:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 11:05:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384608.1627475 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvuc-0007Dv-IC; Thu, 06 Aug 2026 11:05:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384608.1627475; Thu, 06 Aug 2026 11:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrvuc-0007Do-FB; Thu, 06 Aug 2026 11:05:22 +0000
Received: by outflank-mailman (input) for mailman id 1384608;
 Thu, 06 Aug 2026 11:05:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wrvub-0007Di-AD
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 11:05:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wrvua-007xdk-2a;
 Thu, 06 Aug 2026 11:05:20 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wrvua-006MK2-0Z;
 Thu, 06 Aug 2026 11:05:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:Message-ID:Date:Subject:Cc:To:From;
	bh=QlpYR75WSAkB6qNHLmK4Eu1sVy+Cr3Q5Xsy/wys7VpI=; b=OCtwmyFrgRPtR/T/HCZqPBnM2S
	wYU91bwXJQ0GXSE8J2OgKx5+CvbP6QfjzMuL3tBQtcBGxi1j1QwZk+raB15HZ4uLyWLwJSuvzWGZH
	wD9KSdxjAFL0hx483+GBX77eWMN5ZmBPeF07V8uKbtQn14tT59WaSL0jc0Zxe6i0ArbE=;
From: Roger Pau Monne <roger@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger@xenproject.org>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Stewart Hildebrand <stewart.hildebrand@amd.com>,
	Jason Andryuk <jason.andryuk@amd.com>
Subject: [PATCH] xen/vpci: allow unaligned accesses by the hardware domain
Date: Thu,  6 Aug 2026 13:04:01 +0200
Message-ID: <20260806110401.19615-1-roger@xenproject.org>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It's possible for domains to generate unaligned PCI config space accesses
when using ECAM, and hence vPCI should support those at least for the
hardware domain.  Such unaligned accesses to the PCI config space have been
reported to come from ACPI logic.

Relax the checking in vpci_access_allowed() to allow such accesses for the
hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
fulfill them using MMCFG.

MMCFG regions are identity exposed to the hardware domain, and hence such
unaligned accesses can only come as a result of the host having MMCFG in the
first place, as otherwise MMCFG won't be exposed to the hardware domain
either.

Reported-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
---
 tools/include/xen-tools/common-macros.h | 2 ++
 xen/arch/x86/x86_64/pci.c               | 8 ++++----
 xen/drivers/vpci/vpci.c                 | 4 +++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/include/xen-tools/common-macros.h b/tools/include/xen-tools/common-macros.h
index 88b4a0e5a693..1f9146b23b0e 100644
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -68,6 +68,8 @@
     })
 #endif
 
+#define IS_ALIGNED(val, align) (!((val) & ((align) - 1)))
+
 #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
 #define ROUNDDOWN(x, a) ((x) & ~((a) - 1))
 
diff --git a/xen/arch/x86/x86_64/pci.c b/xen/arch/x86/x86_64/pci.c
index 8d33429103b9..6298141c3ca7 100644
--- a/xen/arch/x86/x86_64/pci.c
+++ b/xen/arch/x86/x86_64/pci.c
@@ -26,7 +26,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg)
 
 uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
     {
         uint32_t value;
 
@@ -39,7 +39,7 @@ uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
 
 uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 4) )
     {
         uint32_t value;
 
@@ -60,7 +60,7 @@ void pci_conf_write8(pci_sbdf_t sbdf, unsigned int reg, uint8_t data)
 
 void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
         pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, data);
     else
         pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), reg & 2, 2, data);
@@ -68,7 +68,7 @@ void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data)
 
 void pci_conf_write32(pci_sbdf_t sbdf, unsigned int reg, uint32_t data)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 4) )
         pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, data);
     else
         pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), 0, 4, data);
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 0ac9ec8b0475..b4e053bb4946 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -685,6 +685,8 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
 /* Helper function to check an access size and alignment on vpci space. */
 bool vpci_access_allowed(unsigned int reg, unsigned int len)
 {
+    const struct domain *currd = current->domain;
+
     /* Check access size. */
     if ( len != 1 && len != 2 && len != 4 && len != 8 )
         return false;
@@ -696,7 +698,7 @@ bool vpci_access_allowed(unsigned int reg, unsigned int len)
 #endif
 
     /* Check that access is size aligned. */
-    if ( (reg & (len - 1)) )
+    if ( !is_hardware_domain(currd) && !IS_ALIGNED(reg, len) )
         return false;
 
     return true;
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 11:32:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 11:32:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384624.1627485 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrwKK-0005XV-Fh; Thu, 06 Aug 2026 11:31:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384624.1627485; Thu, 06 Aug 2026 11:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrwKK-0005XO-Cj; Thu, 06 Aug 2026 11:31:56 +0000
Received: by outflank-mailman (input) for mailman id 1384624;
 Thu, 06 Aug 2026 11:31:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrwKJ-0005XI-2U
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 11:31:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrwKI-00AD88-FF
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:31:54 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7470a1-2eae-0a2a0a5409dd-0a2a4502c222-34
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 13:31:54 +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 <jbeulich@suse.com>)
 id 6a7470aa-6ca4-0a2a45020019-d1558029c164-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 13:31:54 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4954aff6088so21092675e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 04:31:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49954246f9dsm65439275e9.15.2026.08.06.04.31.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 04:31:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786015914; x=1786620714; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Imj1BdRczFgTNSp3crVFriTNBqw2cpBDb5vyHLuAegU=;
        b=WASbFKQoK8i4+xbQZ1M/3yLVdyRbeL09ZHCObsPKkGdHf6v+1gtw2i7GTjEO7Tw/vN
         7zOxLhWrYsaCBc1CtpjvlWAVIV8LadAOGFprKcelhCTjDO6yM6vXi6q3guIAseo2grpt
         XbAjhSODbszSrq3T41oOAVl9XZLHVeG5v/Ft7IXTcxV0r100yxbIIj0wso6isS4Sumua
         vtmOfgew5UkYInlP4tTsm3Cb4lAiL25pXU0zjJbMCyvnfxmieSXGF/FqjUdeoh1EK525
         HMNv6zclns6ASr4TqF6Jmkcnxr8evi1VdwtRZKo2Zudcfjf3b/dMSrGxs3kUKCWa63cW
         BuSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786015914; x=1786620714;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Imj1BdRczFgTNSp3crVFriTNBqw2cpBDb5vyHLuAegU=;
        b=RRTxdSn/tn7D17d02bJjUhvuYqD4dSsMy+Bgz1PSQMK/jCY2ZbTbE7+nAIEYWD6oSs
         XmXjWhMzg70FTQsgdhvaEekUaroJCMC0C+tBh4SsadyetyNGVmdf0OLMyElf0fHTqZgy
         RzHQl0yfsVcfYhlikb0WoGSIvbgtKEObzuz8nw7foDPTMYFZAj2aPyg9wmf4LXZ8Vn5C
         LKRIyR2hByL8xin1yQ1nZKPmvdLPBEOmfGjWurelNJPHEWgxKyhm1UanHC9/q0je38XK
         AThiUBl6ad8qAajFqAIciUwcF6w3zSvnm7ox/pq1wts73BFiD9xvpnKLvs/d35VkhC5B
         WyXQ==
X-Forwarded-Encrypted: i=1; AHgh+RrcMohXZS+kDQ9RflgEZCPwSQAz8UmP1KoYCvyjBz8zi/bkmzNfr0ZUV+Irp6ynZjxHFedmriIGNkU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwYtVsOQgc7hsNje/zh2ITJ+oLdcnXAOxMJ8MF2sNJ39aJxEi9P
	pdI6gpInhqSlAuaFcqEIXjH54Ud2fDWRWtc6tBvFn61bxqIyFyW3M6P9P8FeEa2FCA==
X-Gm-Gg: AR+sD13rJvGM5ii2Rv9OmFEeJa2rmFPvw85+zFFyBbKvnRi1kVoiM44Nem4OrOYZ28v
	tbDWx+5RtTw7LSl2qOJanfNCwep8/MC2DUm6szWAgX2u1lxheK79O0MBrx6ZYPXN8fF8QBymdPl
	aBYmBOZsVEQrzLQcI6pQt6AE9xxXrYKGRCvIUhMmgXo/cUUttc4X+/tWKoGrkNiEszaWzwHfZRQ
	d26UHHVPzcg97WC4MZjYwwVs5tryA9SDD0tkv4f/UynotXrICb2HRP9mWZjuR6o1VtWD0HEvVn3
	FBDausMCCS3CC17RHVFbSIaIZHD2DtXeKSKZFPrbp+vXHtYT4dxjOdp/sYYzMmhmz/ZCZexfAj8
	sIG76zQDhby0cQpk/vmwo0Rfe9jzVuA5cunnSx4HekuQAeUQa+hbbj6ov0LAiGGnBaosZQCqawo
	vDIhqOUv8qeFY4LhT76JYn0PkBg8nT6IOytGvN/gRopObtcQvCsH2ZSTxlUN5wuPnyMu53sSC7N
	d9OWrmr0OveC98Pd4EbTmzCnpKtWvjHY8cKlV55NDUdmRkpDED5
X-Received: by 2002:a05:600c:630c:b0:499:4d4a:4990 with SMTP id 5b1f17b1804b1-4994e74566bmr147562345e9.3.1786015913665;
        Thu, 06 Aug 2026 04:31:53 -0700 (PDT)
Message-ID: <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
Date: Thu, 6 Aug 2026 13:31:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Jason Andryuk <jason.andryuk@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <083db883-558a-4000-b404-bf170c8309ee@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786015914-F18AC2AC-E996FB79/0/0
X-purgate-type: clean
X-purgate-size: 1083

On 06.08.2026 12:55, Juergen Gross wrote:
> On 06.08.26 03:52, Jason Andryuk wrote:
>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>> code needs to be fixed first.
>>
>> Jason Andryuk (2):
>>    xen/events: Fix xen_set_upcall_vector stub
>>    xen/Kconfig: select XEN_PVHVM
>>
>>   arch/x86/xen/Kconfig             | 8 +++++---
>>   drivers/xen/events/events_base.c | 2 +-
>>   2 files changed, 6 insertions(+), 4 deletions(-)
>>
> 
> I did a comparison of a kernel built with your patches disabling XEN_PVHVM
> and my patches with XEN_PVHVM_GUEST disabled.
> 
> The kernel built with my patches is 6 bytes smaller than the one with your
> patches.

Isn't this a sign of something else needing tweaking, somewhere?

> So I don't see any reason to take your patches, which conflict with mine,
> especially as my patches have a negative diffstat on source level, too.

Hmm, Jason's patches look to move things into a more adequate direction,
though. In which case I think a negative diffstat becomes an irrelevant
argument?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 11:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 11:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384648.1627493 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrwaD-0000ZP-N0; Thu, 06 Aug 2026 11:48:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384648.1627493; Thu, 06 Aug 2026 11:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrwaD-0000ZI-K4; Thu, 06 Aug 2026 11:48:21 +0000
Received: by outflank-mailman (input) for mailman id 1384648;
 Thu, 06 Aug 2026 11:48:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wrwaC-0000Wk-4G
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 11:48:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrwaB-00F8Za-H7
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:48:19 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a74747f-5cb7-0a2a0a5109dd-0a2a4503b636-22
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 13:48:19 +0200
Received: from [52.101.85.32]
 (helo=BYAPR05CU005.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a747481-fae8-0a2a45030019-346555209f12-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 13:48:19 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA1PR03MB787740.namprd03.prod.outlook.com (2603:10b6:806:51c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.21; Thu, 6 Aug
 2026 11:48:15 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.019; Thu, 6 Aug 2026
 11:48:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lgbZqSciwmw9km0Qt+B6NDfLVd6aZdTKWwFbDkpFyRnZWoqpb+fHU4JKlewRnMj/pimoi6Oi0xazZyuDqQpJth6sqsI0r0q9tvoi+v9eczouLLPX0aNt/VIjv4lcIu2y1jTdDYkKhwv7nndRx8gQ246UwcKsFaBsW08rDvWTzhoFYQiuuleGHXheOo+9CHjSzlReDyQYAv8lI2drtYs3EtW2pWzneihwGy3MJPx+26RpEl4Fs/hTZIPv8VEor9sYV35yG7d11y9M6+6Zv8cIeOzV0lRFmDunJqrAFR3SMfK3Z83Udw8/cvgzmbD/rudMLoT8OVIbLne8RIcmTzYgRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LJHuwZp7A9ScOnrOoEHuY8gDSLlZRB842wSSW8st0xM=;
 b=PWp8jLelefc3sVUBuaW/wVkfkwiuDtrR2gEqh0WpJ9utr9FjQ8+8bFK+KOubMbKoiENaSlsuS9tXRF1ubCxKjTBbV8b3wg4hocFwjZFbKyAsYvvStKMRVN7q6gQetMNvUUS9JYdPQJoNuSpUwe3bM4K5bxOBsyM/AYjK4C7rAYXKDdkBLWVkyXwJK9Rat10OwWHYpGx4HB/YI2gSRBDOdMaBlJkOqI4qaJOuh43Zhdc3bTYjzWBqd1IZ9VHz7MWqjdbI7KrS51lRms3d1DWiQhTbHAS2Do/4CJoTQ9TxRTiofw4HaCZ5NsOaKPteAKOYkk0lzktEtSFX40CYg7vV+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LJHuwZp7A9ScOnrOoEHuY8gDSLlZRB842wSSW8st0xM=;
 b=GhBOSebTaZyHoyJ6msnqSO4XU+KC+RfWFtPh0dmMfji0Pz2ItEnyuBo8XmrUvCw0/r3pw10gaEnMhRpAJLiHo8ojacYeiyPXmfvNQ5hh4hNhFqp1CROOApoIuREi5Vt70IFLDMJ2Le7ysssLAqH56IGp3s87PEGvTpTsZngnzlc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <c510770f-33e5-4b85-a52b-67bb776fb70c@citrix.com>
Date: Thu, 6 Aug 2026 12:48:12 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 Stewart Hildebrand <stewart.hildebrand@amd.com>,
 Jason Andryuk <jason.andryuk@amd.com>
Subject: Re: [PATCH] xen/vpci: allow unaligned accesses by the hardware domain
To: Roger Pau Monne <roger@xenproject.org>, xen-devel@lists.xenproject.org
References: <20260806110401.19615-1-roger@xenproject.org>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260806110401.19615-1-roger@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO2P265CA0492.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:13a::17) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA1PR03MB787740:EE_
X-MS-Office365-Filtering-Correlation-Id: cb437712-bc1f-4dae-0aca-08def3b099ba
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|6133799003|10067099003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	KnHUCbxltax4cC4T5QGZJkHVekeLRxupPAWrSNxVoICfzqx4HLQ2Mo/Kxtv+xzjF/vLP3meRvHEiUMk8qjBhB9IFjLjTR9oxiWvcFty6uE8R8fI5nRnib4TL4GkwfJAoVKV8V5AJc7tl5K01kD1dK+S1D3NGPWL99JmaGKtAhgXIjhJZcs3e2tZ0NIJPIgMDrjWwS/I8bqt3rby98fhA00qDZxBqx5uWtRmfcFJ3rwDL4f+sBnFLILLFvSzZDAC09UnK9oEV6HOX+I26MTsm7PYveTDe3Gc9t0PJkSKCeMsASI1/oZBMaZ5+9vXQr67q7JAks33cGaPoNg3J6sl410bXh2r551tDHfBUn2b2Kf4xY5byGOeEZsuUkTti1oT2ks/2EKJxN56G0Yq3UbKFDVWCpA8pN8KwxMBxsWNqWp9JBAjGc0FZRZGJK7s6Orjcyhmks0RTpLA+oEj0AlyIbwKHRua5Y61p1LxzUipXPAQ0kx/dxuCcrgajFdXNuSHfTeUQMd1/2gcORRfL4ErL1yCATXjujs73f0/LtQRv/jdt6HDwREvuh++0+o6QhdOKa9Dyv/ZTbH0eq6oIGsz+uCbHXJS/NqZFZGdAEVh1t19+ATB4yoZd3JtPtk7TRtZLOaDWRKHcaCcRNT1QTncawHzQKi6eRmMYf3Z/geH3pv8=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(6133799003)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dTBZaWJ6akVyMk9QaHkrc2cvTFQycUFVSjN5ZHgyU2g1aXZhVEFDaGFpYmhK?=
 =?utf-8?B?ZURDTjNMTzc0NW9PN3BIbk9YRCtEWi9IUmNZWlVCcWpXWUtRQnRsMm5IVHJ3?=
 =?utf-8?B?ZVBTUFlIRkE2U2FrMEhnOVFOUmZIYUxoK1dGb2R6K0pZTU5mWGcwa0dLNzJm?=
 =?utf-8?B?dk8rSy9YeXNta1psWk5qb0ZlSFNCRklYSnc1SlBlTGJTMFhIYzBSb2I0ODB1?=
 =?utf-8?B?bFI4d2hqcXFhV1dpQ3hVdCtJZjNod05Xdm9zRktpRkllajdOTXE5QktpbnZX?=
 =?utf-8?B?eld5UGlwL3E0bjhleWZFczlYSkhhNmdJeWY3U2hib1p0UEJTaHFEeHUxV1BZ?=
 =?utf-8?B?Ym9LWUIxVUg2MStiOUpZQTNzTFIrdEJUU294U2owK1ZrWE1iWmt0L0xFN2Rm?=
 =?utf-8?B?a0FFTC96NFdaRm81ZDdNdEwyT2xPK1NnL1NXUWJqaXJld093WGZDTFZES2xH?=
 =?utf-8?B?NUt3NjVyMVNucGtKSGNtbFQxSEE5dkNJbzVUaDQrMUxyaHVDTjV3U0lKN3RG?=
 =?utf-8?B?dFBVbWFyMmhLVEtqUnFkRnkvRWZjdkRBOVZ0TjVwTUdBNWpmckhaaEtsMGRn?=
 =?utf-8?B?bEdnTFdyODlEV1pmWHFXaXpoMFVndzFYUWt6V3ZIWEt0VmJ1YzlhR0xLWkxp?=
 =?utf-8?B?L0pYWTNxSHQxTDhyV1M2c2dlMjZLN3ZBZWxiL1JQSTNnSDlIYVVvOTkxKzlt?=
 =?utf-8?B?ODN6dHM2VHM0V242Sm9xYmMxSzJYQ3hkQUZacDU3ZG8vZ1RiTE5JL05ucjBu?=
 =?utf-8?B?MHBwdlFQcjBPbjdrN0FWMlFEYzdaNmNmZ0VzRXRqUHBUQzc0OWllTnVtVm9h?=
 =?utf-8?B?Vm5NUGxESkU2Q0YwcEs0cTZZQisveDJnSXZoMC9JQmxPUnFqcldROGE0OTZG?=
 =?utf-8?B?bWZCaGRGbUszRFhQdWROcEJ5cnRENTlVaEhIeEcrUWI3YXFUSWhxMllHZ2cy?=
 =?utf-8?B?WHN3bkVhK0VPcHJpdVZFellxdkpZaGx0MDZkYmhjc2hld2JXQjRMdURLNitm?=
 =?utf-8?B?VnJIM3k2NHZuQWhpU1h4YnhzYnZROTN4ZWVuSU80STVET05sOXVrMHN5eUdR?=
 =?utf-8?B?cWg1RGlGNVBYOURVekZmbUFZL3NVRFBWY0dTRDFiemQ4WXpGVHdnVGVVU29C?=
 =?utf-8?B?YW5OeDVMbnA5MitiT3c3ek9UUDg1ZW92NksvQm10bWs1ZnlsQWlQaHB1RjVC?=
 =?utf-8?B?cWE1UUdHc0RwcTRqb2VjaWdhR3FrT2VLT3VWR3FHcFZJaDBQQnRtTkhtbVRt?=
 =?utf-8?B?cnIrR2pKRXF4eWI2WWdLajFid3luL0l2VXp5d3pEMlNNeVlOaEdWTVFMMFdt?=
 =?utf-8?B?T0NvZStHcGkyOENxWlIzN3piZVdVTDZoWFN2cGQ5WnpnZzhxSkhlZWxaeElF?=
 =?utf-8?B?ZEJLUHVjVzZDRUlDN0Z5YlMvUkRNNGY3Y3JnSnJMaHQvVWhsUDhTTTd6Uzdi?=
 =?utf-8?B?bFY0THFsMkZOdjdzaG8rWUx0L0Z1UzZGVVVoeW8yMzZjTVQ3MDk1dFAwSk9Q?=
 =?utf-8?B?T3pLREEwYUgxcDZGN1ZISWZRa1lpYkxsU1NLc2tSeXBDV2NIK2pxcnJZTkpx?=
 =?utf-8?B?R2RDT1NCaGhoVzNTVFhvM1hrUmlPTXFBSzN1Vk5VL2JmbkhzMUJFcTJuRk5F?=
 =?utf-8?B?RjZiUlpCVkVIdmhBQWJtYmM2NlRRQUQ1OFFXT3AwOS8yRnB6ODVaYjFYZ2U1?=
 =?utf-8?B?c3Mxc1Fub2NsLzYxVnBZcUxRUzRpWWpicUYwVnFaY3RpU2EvdmMwSGthYXZZ?=
 =?utf-8?B?SjluOS8wWUF0cTRDT2l5Y0NnV1Ixb0loWkVucHV6ckxyV1dTd3cySFZJUHNa?=
 =?utf-8?B?WTNtbkFCT0NDMXJXY2FwZkU2ZWRZaEFxc0lYcWdrWU5SVTJLay9ITWxROGJO?=
 =?utf-8?B?Wk5WWW5raE5NYWJxczYvQmZ1VGJsNWppN1JGYkhnSW1vTWRISi81M2JBejYz?=
 =?utf-8?B?UkRvUWJVSmpuTEtjanoyOEI5VTYwSHc1K29Ja1RGVWt3bVhyRDRyWEl4ZjdU?=
 =?utf-8?B?clVITXVGaFh5UXNLQzJrNW1wTTBhRlE2ZTVSRlhWaWIxcERFdnZML3luNGVL?=
 =?utf-8?B?L0hzZmdOS3FzWEl3bVFvQ0dWMTRrUGlycmI1WCtHU3FsdGJ1OFNQYTBjNUh1?=
 =?utf-8?B?d0YvZUhaTlhYM0JoN0xFaitMR3dzTDAxdG9PMjhFcTlvaWlqNmdUd3Q3akdu?=
 =?utf-8?B?YkEzTEQ1VTM2YUpiZE9JaGlIUTA0L0JnVVg0SmdEaHFMZVF6eVQ2L3hJWkxW?=
 =?utf-8?B?TmM3S1J0Tjd5emxpRFBtcU5XYVpNMVZua1JTTjVZR0pZS2JYdVFreW5oNHk3?=
 =?utf-8?B?VU1kTk11QlV4dlpudHI3RUJLOVBIblkwcTVDeFdSZ2I2b1FHQSsxQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb437712-bc1f-4dae-0aca-08def3b099ba
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 11:48:15.2924
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: O2IPFVcHoZWWeThh/Lgr9TA3BrPy2/TrWu5zomY+Q9RCTzh1TkEqE+8+Xjur2AOpkiaKcoLf3g4e8sqzgpeFW/KBEny7Ql69Zl5vHRdYwfU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB787740
X-purgate-ID: tlsNG-33051d/1786016899-6F8C54E9-DF4E9F66/0/0
X-purgate-type: clean
X-purgate-size: 3001

On 06/08/2026 12:04 pm, Roger Pau Monne wrote:
> It's possible for domains to generate unaligned PCI config space accesses
> when using ECAM, and hence vPCI should support those at least for the
> hardware domain.  Such unaligned accesses to the PCI config space have been
> reported to come from ACPI logic.

By this, I presume you mean AML from the DSDT/SSDT ?

Misaligned ECAM accesses have undefined behaviour.  On a particular
platform this probably means implementation defined, and for an access
wholly within a single devices CFG window it might even work.  But,
misaligning allows you to have one access hitting two devices, and this
really can't be a good thing.

I presume "fix your BIOS" isn't on the cards, even if it would be for
the greater good?

>
> Relax the checking in vpci_access_allowed() to allow such accesses for the
> hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
> fulfill them using MMCFG.
>
> MMCFG regions are identity exposed to the hardware domain, and hence such
> unaligned accesses can only come as a result of the host having MMCFG in the
> first place, as otherwise MMCFG won't be exposed to the hardware domain
> either.
>
> Reported-by: Jason Andryuk <jason.andryuk@amd.com>
> Signed-off-by: Roger Pau Monné <roger@xenproject.org>
> ---
>  tools/include/xen-tools/common-macros.h | 2 ++
>  xen/arch/x86/x86_64/pci.c               | 8 ++++----
>  xen/drivers/vpci/vpci.c                 | 4 +++-
>  3 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/x86_64/pci.c b/xen/arch/x86/x86_64/pci.c
> index 8d33429103b9..6298141c3ca7 100644
> --- a/xen/arch/x86/x86_64/pci.c
> +++ b/xen/arch/x86/x86_64/pci.c
> @@ -26,7 +26,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg)
>  
>  uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
>  {
> -    if ( sbdf.seg || reg > 255 )
> +    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
>      {
>          uint32_t value;
>  

Personally, I think this is making a bad situation worse.

Baring quirks (i.e. K10 era), there is never a case where we want to use
the IO Ports when we've got ECAM.  Furthermore, on AMD systems when
we're lacking ECAM we can still access Extended Config Space; something
which Xen currently gets wrong in several ways.

The IO ports require a global spinlock in Xen, and then a global
resource in hardware just to be able to translate the IO access back
into the ECAM access we passed on originally.  i.e. from a safety
non-interference point of view, you want to veto any use of the IO ports
by Xen.

Xen needs to use ECAM, and only fall back to IO Ports if we think there
isn't ECAM covering the target sbdf.  This will cause (mis)alignment to
get fixed automatically.  It will also be a substantial perf boost in
the general case; all the MSI/MSI-X editing we do (far too frequently)
is in Legacy Config Space just uses IO Ports.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 12:00:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 12:00:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384673.1627504 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrwlt-0005Aq-To; Thu, 06 Aug 2026 12:00:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384673.1627504; Thu, 06 Aug 2026 12:00:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrwlt-0005Aj-QG; Thu, 06 Aug 2026 12:00:25 +0000
Received: by outflank-mailman (input) for mailman id 1384673;
 Thu, 06 Aug 2026 12:00:24 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wrwls-0005Ad-PD
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 12:00:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrwls-003fam-5W
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:00:24 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a747752-bab6-0a2a0a5309dd-0a2a45058f22-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 14:00:24 +0200
Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a747757-4cb1-0a2a45050019-d155da2bcdd3-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 14:00:24 +0200
Received: by mail-ej1-f43.google.com with SMTP id
 a640c23a62f3a-c1677c91969so245824166b.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 05:00:24 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2036428e13sm239555266b.45.2026.08.06.05.00.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 05:00:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786017623; x=1786622423; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0Ybdpf8/wjx+iaseSxODwkj4wcj0Z9/yn9laCTF9dtE=;
        b=cj5KX/oBukMy+reKPdK2YcOGux12slEYV06ZLr5gXcd4qWEbH5XHSOJ+RHaraUZ6xa
         qLDvTnk/NxX3uI0BdfKg4zmIYvBBwOY5gsuAzwh2llAucrjepgS88SadimH5j+pGxJ/h
         aqwdKZp6ncQOYPiQiwxVWBRiwsMd40Xlw19WId+MQ/H6bWJ2z8GTIuE7So7p1Adb0qaU
         qWOZjg0t0W+zCh3Sz14aEk/pF/zlYMXcAmgHr3Nx+H1dzWgpsAbuvwrX/bW/xDrXxH+O
         96w1y2wsFyq6EF8w/qdBIu294QW2sIAVYelajTi+Y1A4i0AP5SaudzuUh3Ff9WxwwSzv
         1fcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786017623; x=1786622423;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0Ybdpf8/wjx+iaseSxODwkj4wcj0Z9/yn9laCTF9dtE=;
        b=qQ0xDOMZ1Wj8mgkPjeg9wHhgxe52ETbb20hMMLlWJVBTeJ7ohjTXtL6yfdqwgShOsd
         6siXbus+DfZSWMFJsmpTQoIK7oVitK1y1hZwATnN6LzXYdRfg6/ejd/h8dzM3JcWa1z9
         wKyURb6O8BTMSQ0VJNFL23I5zjeWWKVCBDswx0xVb6ONa1bbZ35sVOnAip7Kyfbzz9is
         kxSXSosQsMI/Rr5fbPnaOTXN8LwAFIlwn+rg/oZbs5yBYQA7fy15f9JyCD/dMZSqYqQr
         ITsrgwk+9f+yChtRQAmqpS2r6YvBybNV+TzA2f3O1foXjdfKPrj8d4l6+7Civo9Fj2VM
         YzCw==
X-Forwarded-Encrypted: i=1; AHgh+Ro7IAZ3WA3wTD8J6UUN8anNDhBXAM/vcR84mmyzadhiEqcABzenD7X6+9R784zE19VfuBtUKOq0aBE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGzP4G5vbcq6zt2Yr9eWiw+tb2C8ebK+v/6pY1VPA5Ohq8S+aa
	MDSCLXsejJBEBcNkENat7uo2WetioYjWx/UzD5prPX4bsSmtetr/9hkJ3F06wGeFVOE=
X-Gm-Gg: AR+sD13fsOFDJvvpelzTbp8pKhyY7vvkyTYwLwEjTh89P3ItB6OuHSx3dRNztaJ4qYH
	luUxa6O6Bu7T2/z6m1iSwjItU74J8PMTuAiGlZ3puKIuAUmRGhavxfNyIokzAJLU/nlQSY+Tc5l
	6a6SLs3XjIuLbk0znvPeJPho0WeUu0fBFApV/ZsLAG5Nx4hW5jcpkmtfXI1BzoIXkSOpmbyAivr
	uY0DCnjsgwULwPiqTw/k/LkGoqqh1gX7mU1fwrmoT9CzlZtY/dY35DklzgBszgTkWB2a+WcWTkl
	535bS8UwUJLVF8jJ0SEtt7uYs9nwXJlqq9xfxZwpl3CXvoLMN9D2jz0ocf7E/R68LYRWMjWcL5P
	IsT03XEQCUlJpFgyT9AoAOPry/MCWCNUfHQo8ph55kvACwJfYSFFrJcdFSEJnTWkqYvAP/0TkPn
	vYQoaBZicv966llHa6WIYHyk8hSGuPOg7dditVbnND7zFK8vTB/bpZS42KPmkrbP36Cs38ZzyUD
	bn9Z2Kgoh7NyeKMZY+HqBKepISPcwrfNJ5BfMhP+ewaDFQYJRfUstUhDrhy8GNumwEt4zxavdX9
	wmu4yKgRBTHLeWDq7ie+CaaxKgY=
X-Received: by 2002:a17:906:9fc5:b0:c12:12b7:84de with SMTP id a640c23a62f3a-c2039c4a959mr598128466b.17.1786017623286;
        Thu, 06 Aug 2026 05:00:23 -0700 (PDT)
Message-ID: <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
Date: Thu, 6 Aug 2026 14:00:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Jason Andryuk <jason.andryuk@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
 <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------uxNiNwuKyqiy8WT2Z6TKl64T"
X-purgate-ID: tlsNG-c201ff/1786017624-F6EB12A1-F0DA8FFD/0/0
X-purgate-type: clean
X-purgate-size: 10903

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------uxNiNwuKyqiy8WT2Z6TKl64T
Content-Type: multipart/mixed; boundary="------------qkri4ZR0n1B8ZcmddgEmCyAY";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Jason Andryuk <jason.andryuk@amd.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
 <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
In-Reply-To: <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------qkri4ZR0n1B8ZcmddgEmCyAY
Content-Type: multipart/mixed; boundary="------------hcsGsDhH3CmWe1jsW0yEqvuR"

--------------hcsGsDhH3CmWe1jsW0yEqvuR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDYuMDguMjYgMTM6MzEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNi4wOC4yMDI2
IDEyOjU1LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMDYuMDguMjYgMDM6NTIsIEph
c29uIEFuZHJ5dWsgd3JvdGU6DQo+Pj4gQWxsb3cgZGlzYWJsaW5nIFhFTl9QVkhWTSBmb3Ig
YSBQVi1vbmx5LiAgQSBzdHViIGluIHRoZSBldmVudCBjaGFubmVsDQo+Pj4gY29kZSBuZWVk
cyB0byBiZSBmaXhlZCBmaXJzdC4NCj4+Pg0KPj4+IEphc29uIEFuZHJ5dWsgKDIpOg0KPj4+
ICAgICB4ZW4vZXZlbnRzOiBGaXggeGVuX3NldF91cGNhbGxfdmVjdG9yIHN0dWINCj4+PiAg
ICAgeGVuL0tjb25maWc6IHNlbGVjdCBYRU5fUFZIVk0NCj4+Pg0KPj4+ICAgIGFyY2gveDg2
L3hlbi9LY29uZmlnICAgICAgICAgICAgIHwgOCArKysrKy0tLQ0KPj4+ICAgIGRyaXZlcnMv
eGVuL2V2ZW50cy9ldmVudHNfYmFzZS5jIHwgMiArLQ0KPj4+ICAgIDIgZmlsZXMgY2hhbmdl
ZCwgNiBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQ0KPj4+DQo+Pg0KPj4gSSBkaWQg
YSBjb21wYXJpc29uIG9mIGEga2VybmVsIGJ1aWx0IHdpdGggeW91ciBwYXRjaGVzIGRpc2Fi
bGluZyBYRU5fUFZIVk0NCj4+IGFuZCBteSBwYXRjaGVzIHdpdGggWEVOX1BWSFZNX0dVRVNU
IGRpc2FibGVkLg0KPj4NCj4+IFRoZSBrZXJuZWwgYnVpbHQgd2l0aCBteSBwYXRjaGVzIGlz
IDYgYnl0ZXMgc21hbGxlciB0aGFuIHRoZSBvbmUgd2l0aCB5b3VyDQo+PiBwYXRjaGVzLg0K
PiANCj4gSXNuJ3QgdGhpcyBhIHNpZ24gb2Ygc29tZXRoaW5nIGVsc2UgbmVlZGluZyB0d2Vh
a2luZywgc29tZXdoZXJlPw0KDQpUaGlzIGlzIGEgc2lnbiB0aGF0IHRoZXJlIGFyZSBwcm9i
YWJseSBvbmx5IHZlcnkgZmV3IHJlYWxseSBIVk0gc3BlY2lmaWMgcGF0aHMNCihpbiB0aGUg
c2Vuc2Ugb2Y6IGV4cGxpY2l0bHkgbm90IG1hcmtlZCBhcyBpcnJlbGV2YW50IGZvciBQVikg
aW4gdGhlIGtlcm5lbC4NClllcywgSSdtIHN1cmUgeW91IGNhbiBmaW5kIHNvbWUgbW9yZSwg
YnV0IEknbSByZWFsbHkgbm90IHN1cmUgdGhpcyBpcyByZWxldmFudA0KZm9yIG1vcmUgdGhh
biBhIGhhbmRmdWwgb2YgdXNlcnMuDQoNCj4+IFNvIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24g
dG8gdGFrZSB5b3VyIHBhdGNoZXMsIHdoaWNoIGNvbmZsaWN0IHdpdGggbWluZSwNCj4+IGVz
cGVjaWFsbHkgYXMgbXkgcGF0Y2hlcyBoYXZlIGEgbmVnYXRpdmUgZGlmZnN0YXQgb24gc291
cmNlIGxldmVsLCB0b28uDQo+IA0KPiBIbW0sIEphc29uJ3MgcGF0Y2hlcyBsb29rIHRvIG1v
dmUgdGhpbmdzIGludG8gYSBtb3JlIGFkZXF1YXRlIGRpcmVjdGlvbiwNCj4gdGhvdWdoLiBJ
biB3aGljaCBjYXNlIEkgdGhpbmsgYSBuZWdhdGl2ZSBkaWZmc3RhdCBiZWNvbWVzIGFuIGly
cmVsZXZhbnQNCj4gYXJndW1lbnQ/DQoNCkRlcGVuZHMgb24gd2hhdCB5b3UgYXJlIGxvb2tp
bmcgZm9yLg0KDQpNeSB0YWtlIGZyb20gdGhpcyBpcyB0aGF0IGEgUFYtb25seSBrZXJuZWwg
d2l0aCBKYXNvbidzIHBhdGNoZXMgaXMgbm90IHJlYWxseQ0KYWRkaW5nIGFueSB2YWx1ZSwg
d2hpbGUgbXkgc2ltcGxpZmljYXRpb24gaXMgYXQgbGVhc3QgbWFraW5nIHRoaW5ncyBzaW1w
bGVyDQppbiB0ZXJtcyBvZiBjb2RlIHZvbHVtZSBhbmQgbnVtYmVyIG9mIFhlbiByZWxhdGVk
IGNvbmZpZyBvcHRpb25zLg0KDQpPZiBjb3Vyc2UgaXQgd291bGQgYmUgcG9zc2libGUgdG8g
aGF2ZSBhIHNtYWxsZXIgUFYtb25seSBrZXJuZWwsIGJ1dCBhcyBJIHNhaWQNCmFscmVhZHks
IHRoZXJlIGhhcyBiZWVuIG5vIHB1YmxpYyBkZW1hbmQgZm9yIHRoYXQgaW4gdGhlIGxhc3Qg
eWVhcnMgYW5kIHRoZQ0KZG93bnNpZGVzIElNSE8gZmFyIG91dHdlaWdoIHRoZSBwb3RlbnRp
YWwgZ2Fpbi4NCg0KSU1PIHRoZSAiYWRlcXVhdGUgZGlyZWN0aW9uIiByZWdhcmRpbmcgWGVu
IHNwZWNpZmljIGtlcm5lbCBjb2RlIGlzIHRvd2FyZHMgUFZIDQphbmQgbm90IHRvd2FyZHMg
bW9yZSBQViBzcGVjaWZpYyB0d2Vha2luZy4gQW5kIEknbSB2ZXJ5IHN1cmUgdGhlIGtlcm5l
bA0KY29tbXVuaXR5IG91dHNpZGUgb2YgdGhlIFhlbiBjb21tdW5pdHkgaXMgYWdyZWVpbmcg
d2l0aCBtZSBoZXJlLg0KDQoNCkp1ZXJnZW4NCg==
--------------hcsGsDhH3CmWe1jsW0yEqvuR
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------hcsGsDhH3CmWe1jsW0yEqvuR--

--------------qkri4ZR0n1B8ZcmddgEmCyAY--

--------------uxNiNwuKyqiy8WT2Z6TKl64T
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp0d1YFAwAAAAAACgkQsN6d1ii/Ey/s
PQf/RmWSU8PmAFvgouFrYfNYILXmJGZhWhBd2gHdpMWHSOjgQFAmKhqIK42bjsNnyh1eF0crr+g7
m9O8qY+fd+fXcI6iwPa+RWDZHTGLxdYuI6TQX7OMsuaDRnTzHk+WacAwVfOSqvkDx0f2uagfxqef
sFhirnvS0wyiSKd9Qo3UGmFJGvKfiVdVYKfDb4y9TuOdxtM4E0BiFcyzYqWIWh+SHA3yoZXzwnAf
pyBpj/WERJZex8/+SEshJz1weNKMe7Z56P/12K2e4m83nndEF+qNOXRA89YAW5FCCb+Ri11VEJcm
AFCuNSIEYM1ZLI/qAx+nNLRZ8K75WKQrhe+gbd+/Ug==
=vN2B
-----END PGP SIGNATURE-----

--------------uxNiNwuKyqiy8WT2Z6TKl64T--


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 12:15:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 12:15:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384689.1627511 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrx05-0008BF-32; Thu, 06 Aug 2026 12:15:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384689.1627511; Thu, 06 Aug 2026 12:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrx04-0008B8-W2; Thu, 06 Aug 2026 12:15:04 +0000
Received: by outflank-mailman (input) for mailman id 1384689;
 Thu, 06 Aug 2026 12:15:03 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrx03-0008B2-PA
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 12:15:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrx03-00FZMR-4w
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:15:03 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a747ac5-bab6-0a2a0a5309dd-0a2a4509d75c-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 14:15:03 +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 <jbeulich@suse.com>)
 id 6a747ac6-be1a-0a2a45090019-d1558036e9f4-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 14:15:02 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4955de8797cso14202675e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 05:15:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499541b86f5sm59244655e9.0.2026.08.06.05.15.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 05:15:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786018502; x=1786623302; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=3R0vA+IQ+bdFfwfHDI/nIiFtIJi+isNnUOnVQX7C3yc=;
        b=MADXWPqvEscO9DbC8WHrOoPlDFDZ04z9wpoEs1J7t0+zbG7DYCunqPHKlKJnDuDoZN
         QMIMt0xZF+i4u95BjtOR3DDY/FCSo9R8o6knSoimQslK6Cg1KBiFlsHyIttNz1YaFJHr
         mnGnN6PHwuc+LtR0nQvhvpdERU7vAHfsr1ZNhxxQfb/foVHD09uNXQeDRNuHtrIzM/Bb
         BBsYw8EbVI3iiOODrB7t8hAUiOvji5XJrykrjUXow58wHPCOolyBNgP81Ka55urQDvQ7
         aZxq8Sd4N5EwmS/teB2NTN0ag1bnvPFzMpkhXGuHS8hbqSJQimCRF101DCNnnztcDNCz
         BGlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786018502; x=1786623302;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=3R0vA+IQ+bdFfwfHDI/nIiFtIJi+isNnUOnVQX7C3yc=;
        b=Vk4KOZlMQYxqaR9O79ZvpAzG5Ux9nsIlNdFsuuQ42JXnt4G+8yxcBfpxvOvF1Q+e0e
         FBBP95Xy5B43Hc8yNF/z222oa0rXxDayV8P4yDclXXFQMpAYXO7IRE9XKl/+Irp34tGD
         D4v/jwWWw+StncJanP8zYhwEEKW5nD/9F6NTLmUDrDJufY0Ef/ExK4cTsTM2oenRHJMT
         SxxSkuxetQ3mZDLboNBK7mEN8kZ5+MYv4hoAs3m+53xHrCaTdA1sSH4QvToyNKaXxWyw
         1wDvF6CSoNgDzNpfJ1oH0sraxEVHwiHIoXXqUIME2ubGZ5f6AS6vRu9eVQGSVm2h4oHS
         piBQ==
X-Forwarded-Encrypted: i=1; AHgh+RqrTmyow76wEiJxexkTrQ5TbCeKPQjrrWVIG1DhRKV9BttHqXA4HveJO7wMEfncRurc0hsDyQjuRMk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNIzIGbm3pIc1+w0PGpI9HnWQDjR2hcEFtpjezIem9wjBYs7ZA
	M7WAVULl9DIbYODsoyFZPZZItO+blMLAjb2zOmVOKYj018aXZRNrqTdMxVpRL8Pzzw==
X-Gm-Gg: AR+sD10n3oA6q4UUTwRQmqQaKCAd9bo1BkIgNeLDVBRtHfU1w8Ogj4nJzwMwuWJ1hdV
	/fQfutrFUtmpy0OLL1sKmVCsKPfxy+RbAMMkNIMTbQdWYQg42vKi7qr7fLr8CRL+Wmrczo9+F74
	+k43Lhf5MTzIOnlvhsRQM5mv/mYRdn1CmmKOZItGcsyEXCAKsG7vx3YjYiIitluux765vT7aN01
	ZT/x78IWMKAo+BemKvYeq5ggexhpR0rCRJneEtGinoquSWZMNtd2DUP4LevbIO1jYwxNKNB8lM4
	Ndt44irHKtlGVsychsiUkDdKq22H8Mdc1AU8TPGDzg34gQW03Ec5lhKmeCBAR9w/K+7ar3+NNnE
	DMpoCZesdI5MrDD1wx4cv0Yteh63FPJUR2Z69P/msC0IePV8K4mjgBAClIXRiqN+5Gp/LOnckP3
	hHTwfJdOEChHvfb5f7WTJSmwsPNoM4co4BzoB2l+KJvhZFFBXD+Q6vPhKRw5PHcMVvz8ecZYI50
	1Ldtc9j64d4aiO3iJ/6ZABH9RKWozCEcmTJz6nmap0LPB/HKETe
X-Received: by 2002:a05:600c:4fca:b0:496:c2fd:1731 with SMTP id 5b1f17b1804b1-4994e711309mr172456795e9.1.1786018502050;
        Thu, 06 Aug 2026 05:15:02 -0700 (PDT)
Message-ID: <eb219e1f-39a0-46b9-9035-2b156cea684c@suse.com>
Date: Thu, 6 Aug 2026 14:15:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vpci: allow unaligned accesses by the hardware domain
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Roger Pau Monne <roger@xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Teddy Astie <teddy.astie@vates.tech>,
 Stewart Hildebrand <stewart.hildebrand@amd.com>,
 Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
References: <20260806110401.19615-1-roger@xenproject.org>
 <c510770f-33e5-4b85-a52b-67bb776fb70c@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <c510770f-33e5-4b85-a52b-67bb776fb70c@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1786018502-3BCD7034-5A9AB471/0/0
X-purgate-type: clean
X-purgate-size: 1745

On 06.08.2026 13:48, Andrew Cooper wrote:
> On 06/08/2026 12:04 pm, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/x86_64/pci.c
>> +++ b/xen/arch/x86/x86_64/pci.c
>> @@ -26,7 +26,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg)
>>  
>>  uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
>>  {
>> -    if ( sbdf.seg || reg > 255 )
>> +    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
>>      {
>>          uint32_t value;
>>  
> 
> Personally, I think this is making a bad situation worse.
> 
> Baring quirks (i.e. K10 era), there is never a case where we want to use
> the IO Ports when we've got ECAM.  Furthermore, on AMD systems when
> we're lacking ECAM we can still access Extended Config Space; something
> which Xen currently gets wrong in several ways.
> 
> The IO ports require a global spinlock in Xen, and then a global
> resource in hardware just to be able to translate the IO access back
> into the ECAM access we passed on originally.  i.e. from a safety
> non-interference point of view, you want to veto any use of the IO ports
> by Xen.
> 
> Xen needs to use ECAM, and only fall back to IO Ports if we think there
> isn't ECAM covering the target sbdf.  This will cause (mis)alignment to
> get fixed automatically.  It will also be a substantial perf boost in
> the general case; all the MSI/MSI-X editing we do (far too frequently)
> is in Legacy Config Space just uses IO Ports.

While I agree, that's a bigger change which likely is going to be unsuitable
for (immediate) backporting. Nevertheless the cross-device access that the
changes as presented could cause needs preventing, by altering the checks at
the start of pci_mmcfg_{read,write}().

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:21:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:21:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384730.1627520 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wry1t-0007Fl-KP; Thu, 06 Aug 2026 13:21:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384730.1627520; Thu, 06 Aug 2026 13:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wry1t-0007Fe-HC; Thu, 06 Aug 2026 13:21:01 +0000
Received: by outflank-mailman (input) for mailman id 1384730;
 Thu, 06 Aug 2026 13:20:59 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wry1r-0007FY-Lt
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:20:59 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wry1r-0080BL-0A;
 Thu, 06 Aug 2026 13:20:58 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wry1q-0077Km-1L;
 Thu, 06 Aug 2026 13:20:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=V9I8wN3vFwmrsijFohcDbSfGEb54X0VqpVhd06JB0DM=; b=qbMm5RDrShyacGJPQC/eUzRe/i
	A0EkPoJZYyKhST4ZbttF7Bg4jeSIRTNKG1BAcYpqOb/2PWTkdhip11i1NBGFnypffvhfix1swWVza
	hYJS9BVTMS8mw9oUOJlpD1zDSoSMpDv3uHnE0G/B42cOR9YefLYIVlMIAeHwXCLpTmjA=;
Date: Thu, 6 Aug 2026 15:20:47 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Stewart Hildebrand <stewart.hildebrand@amd.com>,
	Jason Andryuk <jason.andryuk@amd.com>
Subject: Re: [PATCH] xen/vpci: allow unaligned accesses by the hardware domain
Message-ID: <anSKL_v4KByCgltV@macbook.local>
References: <20260806110401.19615-1-roger@xenproject.org>
 <c510770f-33e5-4b85-a52b-67bb776fb70c@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c510770f-33e5-4b85-a52b-67bb776fb70c@citrix.com>

On Thu, Aug 06, 2026 at 12:48:12PM +0100, Andrew Cooper wrote:
> On 06/08/2026 12:04 pm, Roger Pau Monne wrote:
> > It's possible for domains to generate unaligned PCI config space accesses
> > when using ECAM, and hence vPCI should support those at least for the
> > hardware domain.  Such unaligned accesses to the PCI config space have been
> > reported to come from ACPI logic.
> 
> By this, I presume you mean AML from the DSDT/SSDT ?

That's my understanding yes, I can't confirm whether it's from the
DSDST/SSDT or maybe one of the OEM tables.

> Misaligned ECAM accesses have undefined behaviour.  On a particular
> platform this probably means implementation defined, and for an access
> wholly within a single devices CFG window it might even work.  But,
> misaligning allows you to have one access hitting two devices, and this
> really can't be a good thing.

Well, for the hardware domain I merely wanted to replay the access,
but it's true that for access control (that we still do in the
hardware domain case) an access targeting two different devices would
require extra checking that we don't do.

I think it's possibly best to not relax the check in
vpci_access_allowed() as much as I did, and refuse cross-device
accesses.

> I presume "fix your BIOS" isn't on the cards, even if it would be for
> the greater good?

I don't know really, maybe it's possible to get this one fixed.  But
it's likely Xen would hit this again, and most people would attribute
the issue to Xen, because it works with plain Linux, but doesn't when
running as a hardware domain (as the unaligned access is ignored or
reads all 1s).

We have always said that for the hardware domain we would attempt to
get as less as possible in the way of it interacting with devices. I
think this is just one more instance of such avoidance of interference
from hardware domain accesses.

> >
> > Relax the checking in vpci_access_allowed() to allow such accesses for the
> > hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
> > fulfill them using MMCFG.
> >
> > MMCFG regions are identity exposed to the hardware domain, and hence such
> > unaligned accesses can only come as a result of the host having MMCFG in the
> > first place, as otherwise MMCFG won't be exposed to the hardware domain
> > either.
> >
> > Reported-by: Jason Andryuk <jason.andryuk@amd.com>
> > Signed-off-by: Roger Pau Monné <roger@xenproject.org>
> > ---
> >  tools/include/xen-tools/common-macros.h | 2 ++
> >  xen/arch/x86/x86_64/pci.c               | 8 ++++----
> >  xen/drivers/vpci/vpci.c                 | 4 +++-
> >  3 files changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/x86/x86_64/pci.c b/xen/arch/x86/x86_64/pci.c
> > index 8d33429103b9..6298141c3ca7 100644
> > --- a/xen/arch/x86/x86_64/pci.c
> > +++ b/xen/arch/x86/x86_64/pci.c
> > @@ -26,7 +26,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg)
> >  
> >  uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
> >  {
> > -    if ( sbdf.seg || reg > 255 )
> > +    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
> >      {
> >          uint32_t value;
> >  
> 
> Personally, I think this is making a bad situation worse.
> 
> Baring quirks (i.e. K10 era), there is never a case where we want to use
> the IO Ports when we've got ECAM.  Furthermore, on AMD systems when
> we're lacking ECAM we can still access Extended Config Space; something
> which Xen currently gets wrong in several ways.
> 
> The IO ports require a global spinlock in Xen, and then a global
> resource in hardware just to be able to translate the IO access back
> into the ECAM access we passed on originally.  i.e. from a safety
> non-interference point of view, you want to veto any use of the IO ports
> by Xen.
> 
> Xen needs to use ECAM, and only fall back to IO Ports if we think there
> isn't ECAM covering the target sbdf.  This will cause (mis)alignment to
> get fixed automatically.  It will also be a substantial perf boost in
> the general case; all the MSI/MSI-X editing we do (far too frequently)
> is in Legacy Config Space just uses IO Ports.

I've wondered the same myself for some time, but I was also a bit
puzzled by Linux using the same approach, and preferring the IO ports
for accesses to the non-extended space.

Overall I think we would widen the hardware domain accesses _before_
ahead of switching PCI accesses to prefer ECAM over IO ports.  So that
the former can be backported without depending on the latter.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:24:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384739.1627531 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wry5P-00083z-7C; Thu, 06 Aug 2026 13:24:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384739.1627531; Thu, 06 Aug 2026 13:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wry5P-00083s-3n; Thu, 06 Aug 2026 13:24:39 +0000
Received: by outflank-mailman (input) for mailman id 1384739;
 Thu, 06 Aug 2026 13:24:38 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wry5N-00083k-S5
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:24:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wry5M-00D6Wn-VM
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:24:36 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a748b0b-5cb7-0a2a0a5109dd-0a2a4506908c-16
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:24:36 +0200
Received: from [52.101.53.19]
 (helo=BL0PR03CU003.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a748b12-195a-0a2a45060019-346535137015-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:24:35 +0200
Received: from BL1PR13CA0166.namprd13.prod.outlook.com (2603:10b6:208:2bd::21)
 by SAWPR12MB999115.namprd12.prod.outlook.com (2603:10b6:806:4e3::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Thu, 6 Aug
 2026 13:24:31 +0000
Received: from MN1PEPF0000F0E2.namprd04.prod.outlook.com
 (2603:10b6:208:2bd:cafe::74) by BL1PR13CA0166.outlook.office365.com
 (2603:10b6:208:2bd::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.8 via Frontend Transport; Thu, 6
 Aug 2026 13:24:30 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 MN1PEPF0000F0E2.mail.protection.outlook.com (10.167.242.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Thu, 6 Aug 2026 13:24:30 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 6 Aug
 2026 08:24:30 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 6 Aug
 2026 08:24:30 -0500
Received: from [172.19.79.34] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Thu, 6 Aug 2026 08:24:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cTMz2uCOe150771s0ea9CpVcK9ABgIvKotVY3DV9CH9zxw/1hPcgqcy/1IygGVZ7Np6iIJtG3wSwczlSy2jSQthXGXC7mAzwhPitABy6gKreDnH9Kn2cBoMsyuA64LeDl0CtWk36TBpVYNBmVaAD58CmHffkxJYcGkJQjvceieVPFej2avl/GjCH3HR5uabJjkpwLbbhpsBL5JoWeCfLLn8cNYjJ60beffeBAvwnCquIZn/q7SOIHu5pks0rC+c3F7GfekPbg0idFjreNcFUcqeL1R4XAthX0iHEv8ft2jUeTaznJh4W/PCh4/bzzdFu8UDGKLkE2wxAfGNsQ1XyCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VqnVCxBV0rWSAz2hpAfkfFUUEiUk19P4xvnLAhsWtzY=;
 b=BmezDUTZ5Hprw6OF+nVrjMp/jNg2dMeVvFru+loo/Ncx7KUyHqOGt1Ol0wacP+66KesyosO4Bq9odgwnMkd7jBRPbhIrWX+TrwaaeOIVGN5SydNqBMED6L4hW6FnM10PzIZII77Bdy+dVnauXcpsmIYemIhI8ZscMBdGs2MrEaCnxadkq7v4LGIdwHFhlcIiflylL6U0D66nFrBlbGuGXnMzZPBvZ0lf6XGEBh+BXApI0UA3CmLjLGtuY+kd7aoD2iQCRCey7cQWUtVI/OZxu3HHwPklka96R+pLHCs38sozd5A0eZ6VOyVGDiaeTYBK5BJdVvypXlEBxwzV3cOhMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=VqnVCxBV0rWSAz2hpAfkfFUUEiUk19P4xvnLAhsWtzY=;
 b=tkwa01y8Tb/U/5rJ/toka0qQgmrK2n/2ukfcsRg9qaCx00TGir0r0KfavIqcMCB+zyn4YjztJjpJnmnYx3AfTTiRorWBCkRfozSYLiSF3O2eXCPT+LZ+xI/y6W/09t3HsQUeWDffsZ8S7f1PEYt6VqfnFCHRVRKjXLZvSeMFOzY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <a6c55f20-c5cf-45fa-beb8-532fe3b95270@amd.com>
Date: Thu, 6 Aug 2026 09:24:23 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>, Jan Beulich
	<jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>,
	<xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>, "Stefano
 Stabellini" <sstabellini@kernel.org>, Oleksandr Tyshchenko
	<oleksandr_tyshchenko@epam.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, "H. Peter Anvin"
	<hpa@zytor.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
 <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
 <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E2:EE_|SAWPR12MB999115:EE_
X-MS-Office365-Filtering-Correlation-Id: 519541e7-654c-4ad3-ec19-08def3be0c45
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|82310400026|7416014|1800799024|376014|36860700016|4143699003|56012099006|10067099003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	ssmviAh4UlGbLMVR9qrVzGMffOV+F93ogJBOiX2JmxPorOV/wZD2YNcTH6+snAgGYByvpg3c13rL8jGnIlSR7Tt6UKR1ulTAFIjmGyjGChBGpwTsM7TgwfzfM7JB3D2M0B6t42wd5nBFRyU3boD8JKSJWullescDG2oZG5CCrSinnVcNNC9cM5M5D1vkN9ObJYDagXl1rYys/5X1rG+9bYTliJsm4l1ON3XUt7xLinXkI7+Nm+pjkh5SRtOmbl9THGaigJf1W4tsMdh3RIV3a4lYhs2/swUUlxurAtIWKyQPod5vb5bGrY7JtJFOX1BFKNc7LD3YtYOyKg59nNVCZlCPiDHPz/x15OQaXzlC0ddjWjzuBEinjB2oWHILMrcDi7jDqvC6UFK7ZP5ZHbTsrxCyLzI7qLTZKv/ufAaMrUX97Wp1tc6fbpLNBRlRy0q6Xf/cXi3ULLmIgutYkfHAdCcMGbBBn1iVRQ7RsTOwoDD2zLJt+AQ8Kn/ch33R8l1IFbGgjG//IqkkSWHsWaZfm0ZNj8SQS+9DW1aoaXQLF5TH3DNdPueWkXF96TIyul1ZqBQGZMsfVIz0fnGDa5uGOWL6hW5N29N/xLnFOQeJzIkCFxWUFYw0yVTOGOrpDz6dlpIq0umcvLG9pfSE9rtMYokONSkOpPB18/Mol1quDJisR1XtmedbO3o22+qh7aPF0ICXCe4Axwb47B5zb23A2g==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(7416014)(1800799024)(376014)(36860700016)(4143699003)(56012099006)(10067099003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	IuKYHvvcTRYFO/KZfmFoO/sm6r+TPgmOi/Np8cb7Bhat02kwhhP2Qt63hD/yxQntVyKbkqvfS5i0jrOS2NU72YA6232HMDiJD2G4VvgPZXmODeoqe6KOr1oda/jZRrMu1c6i99o0FfDfeTR9Rm8Ehjx6F5obJzESmtBLlkBOlOqBmxpKbKiiK7exXj8EYDDRpPOE0atZM52ca2+oE/7uZxAt6QpKk5fuqdBUfWxbdP+R1OH0mwlDuiHg3JlkD+eKASC9kmO2zsbhxn7Xzv5qt1CCBzMN/IZkY+Oi5U2PJLajPniUAYHTKSFm+iwsuN4k7DB+IcvinwIzfE+3y6a7GHqz0mgpqz9AJZvOqBevlAab4hgW6eWCcIHC5VxatK96eS9fez8fS5yL31epkGRvfduKVTZIRTMkdyJBIxELh+4kOXdK7rUuc/MJdhTlrO9X
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 13:24:30.7985
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 519541e7-654c-4ad3-ec19-08def3be0c45
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000F0E2.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAWPR12MB999115
X-purgate-ID: tlsNG-16d1c6/1786022676-F5C0F77B-6412BB99/0/0
X-purgate-type: clean
X-purgate-size: 2949

On 2026-08-06 08:00, Jürgen Groß wrote:
> On 06.08.26 13:31, Jan Beulich wrote:
>> On 06.08.2026 12:55, Juergen Gross wrote:
>>> On 06.08.26 03:52, Jason Andryuk wrote:
>>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>>> code needs to be fixed first.
>>>>
>>>> Jason Andryuk (2):
>>>>     xen/events: Fix xen_set_upcall_vector stub
>>>>     xen/Kconfig: select XEN_PVHVM
>>>>
>>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>>    drivers/xen/events/events_base.c | 2 +-
>>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>>
>>>
>>> I did a comparison of a kernel built with your patches disabling 
>>> XEN_PVHVM
>>> and my patches with XEN_PVHVM_GUEST disabled.
>>>
>>> The kernel built with my patches is 6 bytes smaller than the one with 
>>> your
>>> patches.
>>
>> Isn't this a sign of something else needing tweaking, somewhere?
> 
> This is a sign that there are probably only very few really HVM specific 
> paths
> (in the sense of: explicitly not marked as irrelevant for PV) in the 
> kernel.
> Yes, I'm sure you can find some more, but I'm really not sure this is 
> relevant
> for more than a handful of users.

I see more reduction:
15029248 - arch/x86/boot/bzImage
15021056 - arch/x86/boot/bzImage.after

~8k

52542480 - vmlinux
52523184 - vmlinux.after

~18k

$ ../linux/scripts/bloat-o-meter vmlinux vmlinux.after
add/remove: 1/136 grow/shrink: 14/48 up/down: 15902/-22430 (-6528)

>>> So I don't see any reason to take your patches, which conflict with 
>>> mine,
>>> especially as my patches have a negative diffstat on source level, too.
>>
>> Hmm, Jason's patches look to move things into a more adequate direction,
>> though. In which case I think a negative diffstat becomes an irrelevant
>> argument?
> 
> Depends on what you are looking for.
> 
> My take from this is that a PV-only kernel with Jason's patches is not 
> really
> adding any value, while my simplification is at least making things simpler
> in terms of code volume and number of Xen related config options.
> 
> Of course it would be possible to have a smaller PV-only kernel, but as 
> I said
> already, there has been no public demand for that in the last years and the
> downsides IMHO far outweigh the potential gain.
> 
> IMO the "adequate direction" regarding Xen specific kernel code is 
> towards PVH
> and not towards more PV specific tweaking. And I'm very sure the kernel
> community outside of the Xen community is agreeing with me here.
I don't need PV-only kernels, so I am fine with not pursuing this patch set.

Mainly I wanted to post this alternative since restoring PV-only is 
possible (and I inadvertently broke it).  Converting CONFIG_XEN_PVHVM to 
CONFIG_XEN looked wrong when it didn't apply to PV.

Pursuing your patches for the reasons you give also makes sense.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:28:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:28:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384746.1627540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wry8f-00012o-N2; Thu, 06 Aug 2026 13:28:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384746.1627540; Thu, 06 Aug 2026 13:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wry8f-00012g-Hm; Thu, 06 Aug 2026 13:28:01 +0000
Received: by outflank-mailman (input) for mailman id 1384746;
 Thu, 06 Aug 2026 13:28:00 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd7425a8b000e099@swg.vates.tech>)
 id 1wry8e-00012Z-Dw
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:28:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wry8d-00D7Jb-I3
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:27:59 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd7425a8b000e099@swg.vates.tech>)
 id 6a748bbe-e002-0a2a0a5209dd-0a2a4508860c-16
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:27:59 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd7425a8b000e099@swg.vates.tech>)
 id 6a748bde-f659-0a2a45080019-b9ff1c238b09-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:27:59 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fd7425a8b000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 06 Aug 2026 13:27:57 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 1441B82386;
 Thu,  6 Aug 2026 15:27:57 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=fjcOJJ9BNo78EaWRAyLGoUF/eBtBx/DiG9665z3EPtU=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=f6UMgWaqhRFqVgHx1QmH/JtT16Z/dYDma5hx456VQEJwCfM58H7RWZ9927IY1YnnpGHslFAN2
 m8WQhguhqtuE9U23n56xaJTuprJKI6LYvsEWjEwkkHWZzd026uc0aiXEEXD0rl4ImbCm0sW9gc+
 RA6QJBgcOQYEnAFsdUely1De6CxpkJjd5zycpyzQa3QgBlHgoa6IoGJnbMr7973QXFnL5MBxTeP
 9qm00Y5jW5wdzoyvaNXQ3+8p5Na69+7C03+P8md36mcsV993eKZZ+Gp3XJR0gWXemPykD1ILE3y
 wreEwz0HsjEgSLE9CDBY9OJAy0iVg1F9SVixDba+Zasw==
X-Zone-Loop: dec621bc5d807e9562f8be292c276d08a94a153578e9
x-campaign-type: default
x-transaction-id: 927a11e6-6598-4bd5-af17-fdf5ba979995
x-swg-uid: 01-e21cba5d-2040-4d00-bfdf-fd5ca1d1d74f
X-Mailer: Sweego
Message-ID:
 <1786022877.8631fc262581453bbf619ec5b2062170.19fd7425a8b000e099@vates.tech>
x-swg-bid: 1786022877.8631fc262581453bbf619ec5b2062170.19fd7425a8b000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 6 Aug 2026 15:27:56 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 2/3] xen/scripts: adapt gen_compile_commands.py to Xen
References: <20260805015247.41943-1-gwd@xenproject.org>
 <20260805015247.41943-3-gwd@xenproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260805015247.41943-3-gwd@xenproject.org>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.1dd4.114358bb8e9b1a69.19fd742582f.9b2b9f1f500dbd5c=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786022877231
X-purgate-ID: tlsNG-c1860d/1786022879-CDF4787B-4101139F/0/0
X-purgate-type: clean
X-purgate-size: 4002

---=Part.1dd4.114358bb8e9b1a69.19fd742582f.9b2b9f1f500dbd5c=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 05, 2026 at 11:52:39AM +1000, George Dunlap wrote:
> Two changes from the Linux original:
>=20
>  - Linux's compiler invocations end with the source file
>    ("=2E=2E=2E -c -o foo=2Eo foo=2Ec"), and the script's line pattern re=
lies
>    on that; Xen's cmd_cc_o_c places "-c $<" before "-o" and "-MQ",
>    so on a Xen object tree the unmodified script matches nothing and
>    produces an empty database=2E  Adjust _LINE_PATTERN to capture the
>    command up to and including "-c" plus the source file, dropping
>    the remainder, which database consumers do not need=2E
>=20
>  - Reword the docstring and help text to refer to Xen=2E
>=20
> The support for reading object lists from archives and modules=2Eorder
> is unused in Xen but retained to minimise divergence from the
> original=2E
>=20
> Assisted-by: LLM
> Signed-off-by: George Dunlap <gwd@xenproject=2Eorg>
> ---
>  xen/scripts/gen_compile_commands=2Epy | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
>=20
> diff --git a/xen/scripts/gen_compile_commands=2Epy b/xen/scripts/gen_com=
pile_commands=2Epy
> index 96e6e46ad1=2E=2E9abc6410c1 100755
> --- a/xen/scripts/gen_compile_commands=2Epy
> +++ b/xen/scripts/gen_compile_commands=2Epy
> @@ -5,7 +5,7 @@
>  #
>  # Author: Tom Roeder <tmroeder@google=2Ecom>
>  #
> -"""A tool for generating compile_commands=2Ejson in the Linux kernel=2E=
"""
> +"""A tool for generating compile_commands=2Ejson for the Xen hypervisor=
=2E"""
> =20
>  import argparse
>  import json
> @@ -19,7 +19,10 @@ _DEFAULT_OUTPUT =3D 'compile_commands=2Ejson'
>  _DEFAULT_LOG_LEVEL =3D 'WARNING'
> =20
>  _FILENAME_PATTERN =3D r'^\=2E=2E*\=2Ecmd$'
> -_LINE_PATTERN =3D r'^(saved)?cmd_[^ ]*\=2Eo :=3D (?P<command_prefix>=2E=
* )(?P<file_path>[^ ]*\=2E[cS]) *(;|$)'
> +# Unlike Linux, Xen's compile commands do not end with the source file:
> +# cmd_cc_o_c places "-c $<" before "-o" and "-MQ"=2E

This looks like a comment for the patch rather than the pattern in the
following line=2E So it doesn't seems useful here=2E

>                                                      Capture the command=
 up
> +# to and including "-c" plus the source file, and drop the remainder=2E

Here, I think it would be worth it to explain what the remainder is,
which in turn would help explain why it is dropped at all=2E

Besides that, the patch description and the other changes looks fine to
me=2E

> +_LINE_PATTERN =3D r'^(saved)?cmd_[^ ]*\=2Eo :=3D (?P<command_prefix>=2E=
* -c )(?P<file_path>[^ ]*\=2E[cS])( =2E*)?$'
>  _VALID_LOG_LEVELS =3D ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
>  # The tools/ directory adopts a different build system, and produces =
=2Ecmd
>  # files in a different format=2E Do not support it=2E
> @@ -35,10 +38,10 @@ def parse_arguments():
>          output: Where to write the compile-commands JSON file=2E
>          paths: The list of files/directories to handle to find =2Ecmd f=
iles=2E
>      """
> -    usage =3D 'Creates a compile_commands=2Ejson database from kernel =
=2Ecmd files'
> +    usage =3D 'Creates a compile_commands=2Ejson database from Xen =2Ec=
md files'
>      parser =3D argparse=2EArgumentParser(description=3Dusage)
> =20
> -    directory_help =3D ('specify the output directory used for the kern=
el build '
> +    directory_help =3D ('specify the output directory used for the Xen =
build '
>                        '(defaults to the working directory)')
>      parser=2Eadd_argument('-d', '--directory', type=3Dstr, default=3D'=
=2E',
>                          help=3Ddirectory_help)

Thanks,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.1dd4.114358bb8e9b1a69.19fd742582f.9b2b9f1f500dbd5c=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:30:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:30:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384754.1627549 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wryAk-0002dR-1L; Thu, 06 Aug 2026 13:30:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384754.1627549; Thu, 06 Aug 2026 13:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wryAj-0002dK-T0; Thu, 06 Aug 2026 13:30:09 +0000
Received: by outflank-mailman (input) for mailman id 1384754;
 Thu, 06 Aug 2026 13:30:08 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wryAi-0002dB-Sa
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:30:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wryAg-0080Mb-0z;
 Thu, 06 Aug 2026 13:30:06 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wryAf-0078oR-2M;
 Thu, 06 Aug 2026 13:30:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=qS5CrHMRnqXJOO0K6atLjDsVfa8CL8D+bDKEO+jgW5E=; b=SbJv5Ej9gb+LPNvByrr+01ow3O
	zLoTXKs/Y3yVijsGi++K55YDAXWCZig8OLkNGOTNQPOmOgR0TmQXqgo0AxRbWkAD54B0uSD8BRqS/
	TZbmvRyp/2Cni4IvRk415alc0QC55IROgUVq6bnhTPSoogROCXTLwThjbfoOTWvBqJ/Q=;
Date: Thu, 6 Aug 2026 15:26:32 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Teddy Astie <teddy.astie@vates.tech>,
	Stewart Hildebrand <stewart.hildebrand@amd.com>,
	Jason Andryuk <jason.andryuk@amd.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/vpci: allow unaligned accesses by the hardware domain
Message-ID: <anSLiMyyONR26e1m@macbook.local>
References: <20260806110401.19615-1-roger@xenproject.org>
 <c510770f-33e5-4b85-a52b-67bb776fb70c@citrix.com>
 <eb219e1f-39a0-46b9-9035-2b156cea684c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <eb219e1f-39a0-46b9-9035-2b156cea684c@suse.com>

On Thu, Aug 06, 2026 at 02:15:02PM +0200, Jan Beulich wrote:
> On 06.08.2026 13:48, Andrew Cooper wrote:
> > On 06/08/2026 12:04 pm, Roger Pau Monne wrote:
> >> --- a/xen/arch/x86/x86_64/pci.c
> >> +++ b/xen/arch/x86/x86_64/pci.c
> >> @@ -26,7 +26,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg)
> >>  
> >>  uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
> >>  {
> >> -    if ( sbdf.seg || reg > 255 )
> >> +    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
> >>      {
> >>          uint32_t value;
> >>  
> > 
> > Personally, I think this is making a bad situation worse.
> > 
> > Baring quirks (i.e. K10 era), there is never a case where we want to use
> > the IO Ports when we've got ECAM.  Furthermore, on AMD systems when
> > we're lacking ECAM we can still access Extended Config Space; something
> > which Xen currently gets wrong in several ways.
> > 
> > The IO ports require a global spinlock in Xen, and then a global
> > resource in hardware just to be able to translate the IO access back
> > into the ECAM access we passed on originally.  i.e. from a safety
> > non-interference point of view, you want to veto any use of the IO ports
> > by Xen.
> > 
> > Xen needs to use ECAM, and only fall back to IO Ports if we think there
> > isn't ECAM covering the target sbdf.  This will cause (mis)alignment to
> > get fixed automatically.  It will also be a substantial perf boost in
> > the general case; all the MSI/MSI-X editing we do (far too frequently)
> > is in Legacy Config Space just uses IO Ports.
> 
> While I agree, that's a bigger change which likely is going to be unsuitable
> for (immediate) backporting. Nevertheless the cross-device access that the
> changes as presented could cause needs preventing, by altering the checks at
> the start of pci_mmcfg_{read,write}().

Hm, OK. I was planning to be a bit mire strict in
vpci_access_allowed(), but I can also adjust pci_mmcfg_{read,write}().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:32:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:32:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384760.1627557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wryCV-0003EQ-9u; Thu, 06 Aug 2026 13:31:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384760.1627557; Thu, 06 Aug 2026 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wryCV-0003EJ-6q; Thu, 06 Aug 2026 13:31:59 +0000
Received: by outflank-mailman (input) for mailman id 1384760;
 Thu, 06 Aug 2026 13:31:57 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wryCT-0003EA-Al
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:31:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wryCS-004LYS-Bc
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:31:56 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a748cb7-e002-0a2a0a5209dd-0a2a45039d68-46
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:31:56 +0200
Received: from [209.85.208.42] (helo=mail-ed1-f42.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a748ccc-fae8-0a2a45030019-d155d02aed7c-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:31:56 +0200
Received: by mail-ed1-f42.google.com with SMTP id
 4fb4d7f45d1cf-6a1a546a6bbso803594a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 06:31:56 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a196aed253sm837140a12.29.2026.08.06.06.31.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 06:31:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786023116; x=1786627916; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=ER2daL09LDBbo/3gJph6npA5SXNYn5TQtVyv8ie4GOI=;
        b=Uj5hrzuz5pSSU2Ysz/r3qdndk+DRSuWv9vHuJyNvKaunObvZ2FyDq+PmZiapEdcxuj
         AB22/V5g/OiwFp/cFGpT6LqV5sF8To/CA2dhGE9RSlKD8sG6BTywtLSVmUGr352cwph0
         RvIm3dG8zEWNy1v/51TdYPbms2abyXkE8OTGegKzx3XjOkoEZlIMeiRZGo11QK8zci1Y
         XZTvkuHsYvvSS2H1qCUv1hUpU1JB+6FI5UNfqSLOJhQdvhBhlKQijhiS4uH4nfjqBY73
         O700zfsah7egsfiLpgQ/kvovCiWOOyTnzXzYdaga94ZMmacVu4KRHq5ssmNWgAfL8qsy
         jTsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786023116; x=1786627916;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ER2daL09LDBbo/3gJph6npA5SXNYn5TQtVyv8ie4GOI=;
        b=Hr+/W7wr04FUcwiZwKYPZ8yDix36eLcdJWbafEEDV16v4FzlsCoFq3Ypi6aI73cbZd
         1URs/OBx7SH6fzhBxHR7+OqbwrX8//PQNXXnSL7OVsy9mlr7cacA/J+1wvaNaAiWoONh
         iMyd9CG7lN8kttZ6aklHt7PD9xh3dlKl4plVL6/TEScIVzD0mXEgEh1MQqgIQvzpka2Q
         ozjCiO93eNNwWTV4ylza0PX+c5MONr2Z3sTTBBJ3SApcrGlFan/KSKqq97/DqeA88r19
         J/uQIOUP22BGpURuAIZkgq/S4vF5/v0oznqF/DtUnZUU1DBvHtVQI20nPwK7ylHxni33
         vzww==
X-Forwarded-Encrypted: i=1; AHgh+RoEWaP5JJZWjvzCS6rp4zLy1hzr+IcWfH4Vn4r6IBLH/x6PfT9eDPvwufs/ZuI4M7vYKst2TiseStE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhXNNNQ8gjsLr7NKsoTzBwkQlWjzANd/xpoCaIUqPznNvdJmOc
	/jgMEvaRrtqSWjVR2IjLhCb0k4Wt7DeXThpDl2uZ1mdiU99FMGIRwqNHAIltqLHvoOQ=
X-Gm-Gg: AR+sD10dEOAAgS40a7qPNKakHPnZH3JDcu9Kdn/O+cv5gCfK+NFpjoRp13yatls+jQr
	OoDSs/gwnqf4FAFSGxtQtdBVQue5VHAiGW1p+X0+8zqgNarYxXaKG2zWAlmOQ7q9j3sGxo2H9JO
	W28OulPO+tIefUM7K4E+FWGqtWo2FgmTJHmnsOZ2LI23y/j/nEQARImxHAl9ONo5GvjME/LgV47
	lwP1qhfZtIicy9ctkOXYSvXYyfFsVzcGJRQAP14UnUMLCUMSVvwgfSVBxMxnZwbWSBKzsPXYpLh
	luShwpgT0owrXbrGYAFupO6Elho6OqSgdEUAxhrjX3CVrc/7WhIkXAcNUSgile/JTwfk3NnEEO9
	9Z7Sd+/UglUyZT/w7pASMMsIZ0s6RSAE+MwCd+MlCEYp/xVUw2w6hdUe5YsZn9uU2n8BWibz06h
	9Ecupm9BwkOgb3NpEggwVMQI/RTYwid2bJrGbxNMhPWcCFZ1RGEnWo5CDraTxxpYVEgbz18lbd2
	Qw3lbmDYv8ncA+aGWihMeDftJl2ey2GNQxKmLDzQ8Zgu7VDsqpvJbPZCL/cSWDQdYLkAENsTQJL
	SuEWOl4h4ZYZZ/k=
X-Received: by 2002:a05:6402:518f:b0:6a1:8ec3:766d with SMTP id 4fb4d7f45d1cf-6a1b4bad1f5mr742692a12.19.1786023115597;
        Thu, 06 Aug 2026 06:31:55 -0700 (PDT)
Message-ID: <3206813c-33fc-476f-a553-4d3f319459aa@suse.com>
Date: Thu, 6 Aug 2026 15:31:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
To: Jason Andryuk <jason.andryuk@amd.com>, Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
 <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
 <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
 <a6c55f20-c5cf-45fa-beb8-532fe3b95270@amd.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <a6c55f20-c5cf-45fa-beb8-532fe3b95270@amd.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------RBWR0lk1dgQ1uIbaPM46ZDwI"
X-purgate-ID: tlsNG-33051d/1786023116-6CEDA4E9-1AE071EA/0/0
X-purgate-type: clean
X-purgate-size: 12320

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------RBWR0lk1dgQ1uIbaPM46ZDwI
Content-Type: multipart/mixed; boundary="------------tzV1pVdD3C6cGm0x2ChdpT1y";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Jason Andryuk <jason.andryuk@amd.com>, Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <3206813c-33fc-476f-a553-4d3f319459aa@suse.com>
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
 <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
 <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
 <a6c55f20-c5cf-45fa-beb8-532fe3b95270@amd.com>
In-Reply-To: <a6c55f20-c5cf-45fa-beb8-532fe3b95270@amd.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------tzV1pVdD3C6cGm0x2ChdpT1y
Content-Type: multipart/mixed; boundary="------------UgvAncgvKwTDoFqxTDog8p7a"

--------------UgvAncgvKwTDoFqxTDog8p7a
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDYuMDguMjYgMTU6MjQsIEphc29uIEFuZHJ5dWsgd3JvdGU6DQo+IE9uIDIwMjYtMDgt
MDYgMDg6MDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+PiBPbiAwNi4wOC4yNiAxMzozMSwg
SmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4gT24gMDYuMDguMjAyNiAxMjo1NSwgSnVlcmdlbiBH
cm9zcyB3cm90ZToNCj4+Pj4gT24gMDYuMDguMjYgMDM6NTIsIEphc29uIEFuZHJ5dWsgd3Jv
dGU6DQo+Pj4+PiBBbGxvdyBkaXNhYmxpbmcgWEVOX1BWSFZNIGZvciBhIFBWLW9ubHkuwqAg
QSBzdHViIGluIHRoZSBldmVudCBjaGFubmVsDQo+Pj4+PiBjb2RlIG5lZWRzIHRvIGJlIGZp
eGVkIGZpcnN0Lg0KPj4+Pj4NCj4+Pj4+IEphc29uIEFuZHJ5dWsgKDIpOg0KPj4+Pj4gwqDC
oMKgIHhlbi9ldmVudHM6IEZpeCB4ZW5fc2V0X3VwY2FsbF92ZWN0b3Igc3R1Yg0KPj4+Pj4g
wqDCoMKgIHhlbi9LY29uZmlnOiBzZWxlY3QgWEVOX1BWSFZNDQo+Pj4+Pg0KPj4+Pj4gwqDC
oCBhcmNoL3g4Ni94ZW4vS2NvbmZpZ8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8IDggKysr
KystLS0NCj4+Pj4+IMKgwqAgZHJpdmVycy94ZW4vZXZlbnRzL2V2ZW50c19iYXNlLmMgfCAy
ICstDQo+Pj4+PiDCoMKgIDIgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspLCA0IGRl
bGV0aW9ucygtKQ0KPj4+Pj4NCj4+Pj4NCj4+Pj4gSSBkaWQgYSBjb21wYXJpc29uIG9mIGEg
a2VybmVsIGJ1aWx0IHdpdGggeW91ciBwYXRjaGVzIGRpc2FibGluZyBYRU5fUFZIVk0NCj4+
Pj4gYW5kIG15IHBhdGNoZXMgd2l0aCBYRU5fUFZIVk1fR1VFU1QgZGlzYWJsZWQuDQo+Pj4+
DQo+Pj4+IFRoZSBrZXJuZWwgYnVpbHQgd2l0aCBteSBwYXRjaGVzIGlzIDYgYnl0ZXMgc21h
bGxlciB0aGFuIHRoZSBvbmUgd2l0aCB5b3VyDQo+Pj4+IHBhdGNoZXMuDQo+Pj4NCj4+PiBJ
c24ndCB0aGlzIGEgc2lnbiBvZiBzb21ldGhpbmcgZWxzZSBuZWVkaW5nIHR3ZWFraW5nLCBz
b21ld2hlcmU/DQo+Pg0KPj4gVGhpcyBpcyBhIHNpZ24gdGhhdCB0aGVyZSBhcmUgcHJvYmFi
bHkgb25seSB2ZXJ5IGZldyByZWFsbHkgSFZNIHNwZWNpZmljIHBhdGhzDQo+PiAoaW4gdGhl
IHNlbnNlIG9mOiBleHBsaWNpdGx5IG5vdCBtYXJrZWQgYXMgaXJyZWxldmFudCBmb3IgUFYp
IGluIHRoZSBrZXJuZWwuDQo+PiBZZXMsIEknbSBzdXJlIHlvdSBjYW4gZmluZCBzb21lIG1v
cmUsIGJ1dCBJJ20gcmVhbGx5IG5vdCBzdXJlIHRoaXMgaXMgcmVsZXZhbnQNCj4+IGZvciBt
b3JlIHRoYW4gYSBoYW5kZnVsIG9mIHVzZXJzLg0KPiANCj4gSSBzZWUgbW9yZSByZWR1Y3Rp
b246DQo+IDE1MDI5MjQ4IC0gYXJjaC94ODYvYm9vdC9iekltYWdlDQo+IDE1MDIxMDU2IC0g
YXJjaC94ODYvYm9vdC9iekltYWdlLmFmdGVyDQo+IA0KPiB+OGsNCj4gDQo+IDUyNTQyNDgw
IC0gdm1saW51eA0KPiA1MjUyMzE4NCAtIHZtbGludXguYWZ0ZXINCj4gDQo+IH4xOGsNCj4g
DQo+ICQgLi4vbGludXgvc2NyaXB0cy9ibG9hdC1vLW1ldGVyIHZtbGludXggdm1saW51eC5h
ZnRlcg0KPiBhZGQvcmVtb3ZlOiAxLzEzNiBncm93L3NocmluazogMTQvNDggdXAvZG93bjog
MTU5MDIvLTIyNDMwICgtNjUyOCkNCg0KRGlkIHlvdSBkaXNhYmxlIENPTkZJR19YRU5fUFZI
Vk1fR1VFU1QgaW4gdGhlIGJlZm9yZSBrZXJuZWwsIHRvbz8NCg0KPiANCj4+Pj4gU28gSSBk
b24ndCBzZWUgYW55IHJlYXNvbiB0byB0YWtlIHlvdXIgcGF0Y2hlcywgd2hpY2ggY29uZmxp
Y3Qgd2l0aCBtaW5lLA0KPj4+PiBlc3BlY2lhbGx5IGFzIG15IHBhdGNoZXMgaGF2ZSBhIG5l
Z2F0aXZlIGRpZmZzdGF0IG9uIHNvdXJjZSBsZXZlbCwgdG9vLg0KPj4+DQo+Pj4gSG1tLCBK
YXNvbidzIHBhdGNoZXMgbG9vayB0byBtb3ZlIHRoaW5ncyBpbnRvIGEgbW9yZSBhZGVxdWF0
ZSBkaXJlY3Rpb24sDQo+Pj4gdGhvdWdoLiBJbiB3aGljaCBjYXNlIEkgdGhpbmsgYSBuZWdh
dGl2ZSBkaWZmc3RhdCBiZWNvbWVzIGFuIGlycmVsZXZhbnQNCj4+PiBhcmd1bWVudD8NCj4+
DQo+PiBEZXBlbmRzIG9uIHdoYXQgeW91IGFyZSBsb29raW5nIGZvci4NCj4+DQo+PiBNeSB0
YWtlIGZyb20gdGhpcyBpcyB0aGF0IGEgUFYtb25seSBrZXJuZWwgd2l0aCBKYXNvbidzIHBh
dGNoZXMgaXMgbm90IHJlYWxseQ0KPj4gYWRkaW5nIGFueSB2YWx1ZSwgd2hpbGUgbXkgc2lt
cGxpZmljYXRpb24gaXMgYXQgbGVhc3QgbWFraW5nIHRoaW5ncyBzaW1wbGVyDQo+PiBpbiB0
ZXJtcyBvZiBjb2RlIHZvbHVtZSBhbmQgbnVtYmVyIG9mIFhlbiByZWxhdGVkIGNvbmZpZyBv
cHRpb25zLg0KPj4NCj4+IE9mIGNvdXJzZSBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBoYXZl
IGEgc21hbGxlciBQVi1vbmx5IGtlcm5lbCwgYnV0IGFzIEkgc2FpZA0KPj4gYWxyZWFkeSwg
dGhlcmUgaGFzIGJlZW4gbm8gcHVibGljIGRlbWFuZCBmb3IgdGhhdCBpbiB0aGUgbGFzdCB5
ZWFycyBhbmQgdGhlDQo+PiBkb3duc2lkZXMgSU1ITyBmYXIgb3V0d2VpZ2ggdGhlIHBvdGVu
dGlhbCBnYWluLg0KPj4NCj4+IElNTyB0aGUgImFkZXF1YXRlIGRpcmVjdGlvbiIgcmVnYXJk
aW5nIFhlbiBzcGVjaWZpYyBrZXJuZWwgY29kZSBpcyB0b3dhcmRzIFBWSA0KPj4gYW5kIG5v
dCB0b3dhcmRzIG1vcmUgUFYgc3BlY2lmaWMgdHdlYWtpbmcuIEFuZCBJJ20gdmVyeSBzdXJl
IHRoZSBrZXJuZWwNCj4+IGNvbW11bml0eSBvdXRzaWRlIG9mIHRoZSBYZW4gY29tbXVuaXR5
IGlzIGFncmVlaW5nIHdpdGggbWUgaGVyZS4NCj4gSSBkb24ndCBuZWVkIFBWLW9ubHkga2Vy
bmVscywgc28gSSBhbSBmaW5lIHdpdGggbm90IHB1cnN1aW5nIHRoaXMgcGF0Y2ggc2V0Lg0K
PiANCj4gTWFpbmx5IEkgd2FudGVkIHRvIHBvc3QgdGhpcyBhbHRlcm5hdGl2ZSBzaW5jZSBy
ZXN0b3JpbmcgUFYtb25seSBpcyBwb3NzaWJsZSANCj4gKGFuZCBJIGluYWR2ZXJ0ZW50bHkg
YnJva2UgaXQpLsKgIENvbnZlcnRpbmcgQ09ORklHX1hFTl9QVkhWTSB0byBDT05GSUdfWEVO
IA0KPiBsb29rZWQgd3Jvbmcgd2hlbiBpdCBkaWRuJ3QgYXBwbHkgdG8gUFYuDQo+IA0KPiBQ
dXJzdWluZyB5b3VyIHBhdGNoZXMgZm9yIHRoZSByZWFzb25zIHlvdSBnaXZlIGFsc28gbWFr
ZXMgc2Vuc2UuDQoNClRoYW5rcywNCg0KDQpKdWVyZ2VuDQo=
--------------UgvAncgvKwTDoFqxTDog8p7a
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------UgvAncgvKwTDoFqxTDog8p7a--

--------------tzV1pVdD3C6cGm0x2ChdpT1y--

--------------RBWR0lk1dgQ1uIbaPM46ZDwI
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp0jMoFAwAAAAAACgkQsN6d1ii/Ey+w
0QgAgWFtwLXHbZiI2x6rwpaNKVn9HGdNEHtNajXZkomknhdnC4BlDSPqQtnqp0Sai0mrHWwfD4+I
c/N5h+PLnRGs4QT2KvS5/XNu0AYdNkb7W+Aml2Ac/gLMXoMnn6p8XpvGydDJxKph7tWyBrZH556F
YQCYOX8w+UjjZukEuw9riSvjdZliFdS7HU6jmBgkubbRTHTQBq1bDFGmC72/Tqo7yaDlivE0QJxe
m7t0cIWPOAr/5TPzpjV+TxH7rAbJqznPpFPh8eZRzGWN6y1HrEC4QmMry7XjWdfK88z99SEA1/PA
2qYSKDk2aZYDR4tw0+nHEnxrZLB8hbLcmxIMWqdmwg==
=odcF
-----END PGP SIGNATURE-----

--------------RBWR0lk1dgQ1uIbaPM46ZDwI--


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:48:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:48:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384780.1627565 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrySI-00070E-NT; Thu, 06 Aug 2026 13:48:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384780.1627565; Thu, 06 Aug 2026 13:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrySI-000707-Km; Thu, 06 Aug 2026 13:48:18 +0000
Received: by outflank-mailman (input) for mailman id 1384780;
 Thu, 06 Aug 2026 13:48:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd754d83e000e099@swg.vates.tech>)
 id 1wrySG-0006ym-Va
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:48:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrySG-00875C-8C
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:48:16 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd754d83e000e099@swg.vates.tech>)
 id 6a74907d-2eae-0a2a0a5409dd-0a2a4503e2e8-48
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:48:16 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd754d83e000e099@swg.vates.tech>)
 id 6a74909f-fae8-0a2a45030019-b9ff1c238131-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:48:15 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fd754d83e000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 06 Aug 2026 13:48:09 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 0609782116;
 Thu,  6 Aug 2026 15:48:09 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=WHDYfvmtJwvA3xxIRm+9ijAb7jiUxc5x/W+7GWYTxbk=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=FrPItnuDc6hnKwl+QsTrEyWkX4l7VoK76o9SOivGkvYO2Re9ClUFGZSOmFFBmG8TwKK3sPnp/
 sReawACDZ5R330BFwOqwkcnANk7G8NAyimNdhFmaT0jwjfsC8QjPCBC9SddENaoXh0bRkHQBTPj
 CCk/i9jHhNi68QMpFHBMi/uF3u7zCqUQigVMwZQbmKgQSjmv6Tw0DuFIQPXbY1CZlEbqGRtcBGx
 m/PgS4GP1F1XI3FEabI2ca0lAuaTRx8KnnTpscS0I8D8OAWu2ygc92jCDinGUVxp96wfw35tQVl
 1l1jK+hKf7qafEQZZn5bJ6LhvkO5I1R3cyhH8oiPNH4g==
X-Zone-Loop: 34273c20037e853124b395c6f5f59e81331e7e35d82e
x-campaign-type: default
x-transaction-id: 3d320ad8-8c15-4596-afe2-33d0285e86f5
x-swg-uid: 01-ac6c1f46-bacf-4631-a6ac-d8f06165d54e
X-Mailer: Sweego
Message-ID:
 <1786024089.8631fc262581453bbf619ec5b2062170.19fd754d83e000e099@vates.tech>
x-swg-bid: 1786024089.8631fc262581453bbf619ec5b2062170.19fd754d83e000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 6 Aug 2026 15:48:08 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 3/3] build: add compile_commands.json target
References: <20260805015247.41943-1-gwd@xenproject.org>
 <20260805015247.41943-4-gwd@xenproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260805015247.41943-4-gwd@xenproject.org>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.1ddb.a4f82da285c3bf95.19fd754d655.e0a61ca139faa02a=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786024089174
X-purgate-ID: tlsNG-33051d/1786024096-6F2C84E9-58D5D385/0/0
X-purgate-type: clean
X-purgate-size: 2439

---=Part.1ddb.a4f82da285c3bf95.19fd754d655.e0a61ca139faa02a=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 05, 2026 at 11:52:40AM +1000, George Dunlap wrote:
> Add a phony convenience target generating the compilation database

"phony convenience target", that a funny way to put it :-) the target
isn't phony, it just use the Make keyword "phony" to have it ignore the
existing target=2E

> from a built object tree, alongside the other developer conveniences
> (tags, cscope, cloc -- the last of which already walks the same =2Ecmd
> files):
>=20
>     make -C xen compile_commands=2Ejson
>=20
> The output lands in the object tree root, where clangd and other
> consumers discover it automatically when opening files from an
> in-tree build=2E

What about out-of-tree build? :-) that first part of the sentence
almost seems to acknowledge their existence=2E Anyway, one can create a
symlink=2E

> Note the database records the compiler invocations actually used=2E
> With a clang build it is consumable by clangd as-is; for a gcc build,
> clang-based tools may need a small =2Eclangd configuration
> (CompileFlags: Remove/Add) dropping gcc-only flags=2E
>=20
> Also add the generated file to =2Egitignore=2E
>=20
> Assisted-by: LLM
> Signed-off-by: George Dunlap <gwd@xenproject=2Eorg>
> ---
>  =2Egitignore   | 1 +
>  xen/Makefile | 4 ++++
>  2 files changed, 5 insertions(+)
>=20
> diff --git a/=2Egitignore b/=2Egitignore
> index bfc7bdf043=2E=2E0aa9b801de 100644
> --- a/=2Egitignore
> +++ b/=2Egitignore
> @@ -192,6 +192,7 @@ xen/arch/*/include/generated
>  xen/build-dir-cppcheck/
>  xen/common/config_data=2ES
>  xen/common/config=2Egz
> +xen/compile_commands=2Ejson
>  xen/cppcheck-htmlreport/
>  xen/cppcheck-report/
>  xen/cppcheck-misra=2E*
> diff --git a/xen/Makefile b/xen/Makefile
> index d39bdfdd53=2E=2Ef87240f33c 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -685,6 +685,10 @@ cloc:
>  	    done; \
>  	done | cloc --list-file=3D-
> =20
> +=2EPHONY: compile_commands=2Ejson
> +compile_commands=2Ejson:

Could you use FORCE instead =2EPHONY? That is just:

    +compile_commands=2Ejson: FORCE

Thanks,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.1ddb.a4f82da285c3bf95.19fd754d655.e0a61ca139faa02a=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:54:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:54:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384804.1627576 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wryY4-0000RS-Bs; Thu, 06 Aug 2026 13:54:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384804.1627576; Thu, 06 Aug 2026 13:54:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wryY4-0000RL-7K; Thu, 06 Aug 2026 13:54:16 +0000
Received: by outflank-mailman (input) for mailman id 1384804;
 Thu, 06 Aug 2026 13:54:15 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd75a4b75000e099@swg.vates.tech>)
 id 1wryY3-0000RF-HW
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:54:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wryY2-00DByA-UF
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:54:14 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd75a4b75000e099@swg.vates.tech>)
 id 6a7491ea-5cb7-0a2a0a5109dd-0a2a450a894c-42
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:54:14 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fd75a4b75000e099@swg.vates.tech>)
 id 6a749203-f2d2-0a2a450a0019-b9ff1c238685-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:54:11 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fd75a4b75000e099.001 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 06 Aug 2026 13:54:06 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 3B939835D7;
 Thu,  6 Aug 2026 15:54:06 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=fRUrVE630RsEJS6ZLH/6Y7mCfFS4TvhyflfWwJQ0YOg=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=kLMgsXDIZTafA0fkFQjJNbTLoLEaf7fp1foPgZ9xOQUW7urHLmD5hT9jAETdnXeNBO5iuRLdJ
 P+sXO3AQLdDG/r5smJMoMoIPnqLHya4z9Ua7aR1D9JqHtXURYzAOO+mSU7OH9ixexUA4il63yhh
 J73maPUXHSUeNT6YTHnq0rMdPpFwP4vtLrpPs8ZNH1NAaaHv2JocbkcMV4q4NXNcPtf0jVHtCC2
 fc6pPXleytR4Khjm2Fd3yDeyrkmFDQF0Xxwd/DrtPjXu6ptdomJ2WOjxll8ZvOhG5JUa7HEj9Qs
 jjAIdJ8dUacyCJAVZhiz9ktrGVjFxbidLZd6UbAkjQVg==
X-Zone-Loop: d4caa2c739aea8cb86290f11f27ffc1973338f8f1048
x-campaign-type: default
x-transaction-id: 56243759-dbbc-4dce-bb13-071b2c860a6b
x-swg-uid: 01-1f5bf399-c575-4415-aa71-d7a76acc85b8
X-Mailer: Sweego
Message-ID:
 <1786024446.8631fc262581453bbf619ec5b2062170.19fd75a4b75000e099@vates.tech>
x-swg-bid: 1786024446.8631fc262581453bbf619ec5b2062170.19fd75a4b75000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 6 Aug 2026 15:54:06 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH 0/3] Add compile_commands.json target
References: <20260805015247.41943-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260805015247.41943-1-gwd@xenproject.org>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.1de0.9fcff84f069bedcf.19fd75a4985.d81b5e994d9e9a15=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786024446342
X-purgate-ID: tlsNG-4011c0/1786024451-583CCCFC-A45D6261/0/0
X-purgate-type: clean
X-purgate-size: 772

---=Part.1de0.9fcff84f069bedcf.19fd75a4985.d81b5e994d9e9a15=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 05, 2026 at 11:52:37AM +1000, George Dunlap wrote:
> Modern tools like emacs' `eglot` rely on compile_commands=2Ejson to
> gather information about the project=2E  Import the build script from Li=
nux,
> adapting it to the core Xen binary=2E

Thanks=2E I've looked at using that script, but since it wasn't going to
be useful for the tool side, I didn't do anything and just used `bear`
instead=2E

Cheers,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.1de0.9fcff84f069bedcf.19fd75a4985.d81b5e994d9e9a15=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 13:58:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 13:58:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384813.1627584 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrycQ-0001ws-Qa; Thu, 06 Aug 2026 13:58:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384813.1627584; Thu, 06 Aug 2026 13:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrycQ-0001wl-Ni; Thu, 06 Aug 2026 13:58:46 +0000
Received: by outflank-mailman (input) for mailman id 1384813;
 Thu, 06 Aug 2026 13:58:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrycP-0001wf-90
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 13:58:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrycO-004Qcb-8j
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:58:44 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a749302-bab6-0a2a0a5309dd-0a2a450cd4ce-34
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:58:43 +0200
Received: from [52.101.48.35]
 (helo=MW6PR02CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a749310-f479-0a2a450c0019-346530230f97-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:58:43 +0200
Received: from BN9PR03CA0424.namprd03.prod.outlook.com (2603:10b6:408:113::9)
 by SJ2PR12MB8881.namprd12.prod.outlook.com (2603:10b6:a03:546::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Thu, 6 Aug
 2026 13:58:35 +0000
Received: from BN3PEPF0000B076.namprd04.prod.outlook.com
 (2603:10b6:408:113:cafe::11) by BN9PR03CA0424.outlook.office365.com
 (2603:10b6:408:113::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.21 via Frontend Transport; Thu, 6
 Aug 2026 13:58:35 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BN3PEPF0000B076.mail.protection.outlook.com (10.167.243.121) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Thu, 6 Aug 2026 13:58:35 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 6 Aug
 2026 08:58:34 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 6 Aug
 2026 08:58:34 -0500
Received: from [172.19.79.34] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Thu, 6 Aug 2026 08:58:33 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QNyqNc4cNXJqFGmKKpucAn7dxtzWQR8l6bC4Y3MPmh0hmf7bcYwKK667TyeY/j7z/ZdICMnkFKUFhpo6om4DDdiCZ0nHatHfzNVaD03tU5ZqEIlRY9JZWUX1zSLIIxZvPKvAkuFvu4LQpzkG62hy99hNu8m+FIB/a9VdCpuQwDBBgO2enaaU/HilQE6XkY06pzPEN0XUofCNIRVqLc7btYW3LKo+24LgUGl+YoTvT3m/MhVor4JlwqPG8tYag7M/xuH8p6bx4ioWxWI64ruYLkPnJ0TjDHP3QkxyTGQkv4xWnzbwD9VU4DU9dkA5sXnFolFtC6xGkIuzxqmZI819Cg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ps0ZJGdu/nNFySK1kD7HgjTQDo++3/DWtEi+//fDIvA=;
 b=y45vNvRTpJTLmAyxbxs1GOR64tC3WT1RCLBufVbf9Z2ZZJ5BkOaq95vfF5bztfDuuR1oqigzQ+R1vkA6HCORlsnv2rVSZ0MxgvROqJpaI/JY+veZa0E7TUgz3RIQJp55IjDynhHP4EqtGHtbwaY2w+5pQvUH42tArG1GrI0Q1wZoEBW8vFZLZYIMcPGDb3s3vuI+OE80H+IVVWg1O7tpl+K/QaH7zsHo+6XRyIZino2X7IiChn9hrqdPouBzfIe/prFMMqZTbaRi5vUtAGyEyEA2ff/u5DxPA04sDEZeE+SG0h0Tpoh3JLwy+Mp1WGYZe1HnTBROVwU4GgtpKY8zrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ps0ZJGdu/nNFySK1kD7HgjTQDo++3/DWtEi+//fDIvA=;
 b=Upl9+7iGl29zwCjUP5s0SPMrBRyKu4T/wFl8XgW6K+USwxpWSmQ91M19G6Nru8l6rsddT/KAVcJnFAHr9UYS3tNxgF+5/+J3GuWDOKDjJqLt8A93WjZ509l3MubTI8SrnNvY+0Bj1fG0eUCtylzSUKEZrsqY/bXkHN8NEKArrXA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <9f2588a1-b585-47dc-b825-993c31ab3fd6@amd.com>
Date: Thu, 6 Aug 2026 09:58:32 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen: Fix PV-only build
To: Juergen Gross <jgross@suse.com>, Jan Beulich <jbeulich@suse.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>,
	<xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>, "Stefano
 Stabellini" <sstabellini@kernel.org>, Oleksandr Tyshchenko
	<oleksandr_tyshchenko@epam.com>, Boris Ostrovsky
	<boris.ostrovsky@oracle.com>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, "H. Peter Anvin"
	<hpa@zytor.com>
References: <20260806015233.202486-1-jason.andryuk@amd.com>
 <083db883-558a-4000-b404-bf170c8309ee@suse.com>
 <62b5117f-928d-4908-9217-cc16d9cf15f9@suse.com>
 <967208c9-8d51-4380-8cb4-298f5c313d35@suse.com>
 <a6c55f20-c5cf-45fa-beb8-532fe3b95270@amd.com>
 <3206813c-33fc-476f-a553-4d3f319459aa@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <3206813c-33fc-476f-a553-4d3f319459aa@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B076:EE_|SJ2PR12MB8881:EE_
X-MS-Office365-Filtering-Correlation-Id: f3c6461b-1d28-43cc-22d0-08def3c2cebb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|36860700016|82310400026|376014|23010399003|1800799024|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	1CP4srme/UHBIZGwwigWh27iMkxSgnH8KnZR+Z6lRwdzyEmO3jDsL7g11H20DH0zJsmSrYWXu87oRXUtKsqf0dLK2KR4gMaxOCUyR59I6RiZKVfIcnaPouPCIfx+dVY5w+qyO2mNmpXKQ2UVJys+szvD82NptQxc05IhBzjErmRQqCUsU2zDe5yekVHNIu0S/QWpiPV/eOA0sZwC16Jb3RZ60EShNLZLsqCWcV+i3mhw5NBYkU/c9lKl5Xf6yAcovk4kughjseetQK7qNZC42xNLWr5rf1iPsmKYrMC2qGrpKEOZ9iOV7JzLJm7+/+OFlyDTa8+OeJfljZMdUzyhxVqo1is2D/sZC108QL1/zqqn/3b/zLPpf0nMXAsTB4khuGGh8TaE2zTdXlUO9hdrONtg+789oTPnXO67opkquXHqcI/HmUZ18Z94p4Ukmh1ivtGHope3p4qD8+8C/XxCHx4KkrPIuxDxumNpr/5IqWZ8afzjjuL0jm+BkF+nfVuhQXfOHA7HF99hHTkh6X9QqnPFmiTdhx4GkITiUTG6hIfkEJKr4BsNsI3RJNZ9rDB/JM7dicyuuEO6UGdPCGJFKrhFH92AiTKbbrFp3vH0SxsgnLbe2A6xmxxyC6vINFIftzGRFC0cIlXOaE7L59YoU5/94uRAb/xYi4AY5UHLp9Od+JMYTUK7JHasP+9AO3AQ
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(36860700016)(82310400026)(376014)(23010399003)(1800799024)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	k1G1CMbkAWeDRKUcpL9U6a5ZkMlBqQ0lfIdWEzQs9SEm4hCMYmfZRAbhdBN5Pl8WilMkQ6vJKypVT69PSFkwm4Deex68hAFC2yALUMJ5HAZQdKZd5WrbSSUb1QsIrFeOMHcHbOKoGJoHAaRZ2oFdHf+8B20MzpP1Tl7EEP5VCxm5u1eNSQ62JfIQeSQaiRYIW5NAKAYZJ1rHFdgprnkNvVmoLI3g9QlKVtIRsjV2wfNKIeQB/+nevp+IuP51sIeJMA+UplboLDt4dytCv0vPoVLKhRraMEUXFegGXKT5yhs6KkqH6guTrjP99MdQUIfm7isrpITGGdolc+jdKHHMbrVB/lMkNUwUcuhjOcpOD8IgLHdZZs6ZZkF9hsT22EOvswAFal71mTlsZitArm6k7VfKBZsBkbGU46pvPVqUHG0KowWrKJJuH0+29JKLEuQS
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 13:58:35.0349
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f3c6461b-1d28-43cc-22d0-08def3c2cebb
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B076.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8881
X-purgate-ID: tlsNG-d25034/1786024723-77ED2A5B-765E4CD0/0/0
X-purgate-type: clean
X-purgate-size: 2175

On 2026-08-06 09:31, Juergen Gross wrote:
> On 06.08.26 15:24, Jason Andryuk wrote:
>> On 2026-08-06 08:00, Jürgen Groß wrote:
>>> On 06.08.26 13:31, Jan Beulich wrote:
>>>> On 06.08.2026 12:55, Juergen Gross wrote:
>>>>> On 06.08.26 03:52, Jason Andryuk wrote:
>>>>>> Allow disabling XEN_PVHVM for a PV-only.  A stub in the event channel
>>>>>> code needs to be fixed first.
>>>>>>
>>>>>> Jason Andryuk (2):
>>>>>>     xen/events: Fix xen_set_upcall_vector stub
>>>>>>     xen/Kconfig: select XEN_PVHVM
>>>>>>
>>>>>>    arch/x86/xen/Kconfig             | 8 +++++---
>>>>>>    drivers/xen/events/events_base.c | 2 +-
>>>>>>    2 files changed, 6 insertions(+), 4 deletions(-)
>>>>>>
>>>>>
>>>>> I did a comparison of a kernel built with your patches disabling 
>>>>> XEN_PVHVM
>>>>> and my patches with XEN_PVHVM_GUEST disabled.
>>>>>
>>>>> The kernel built with my patches is 6 bytes smaller than the one 
>>>>> with your
>>>>> patches.
>>>>
>>>> Isn't this a sign of something else needing tweaking, somewhere?
>>>
>>> This is a sign that there are probably only very few really HVM 
>>> specific paths
>>> (in the sense of: explicitly not marked as irrelevant for PV) in the 
>>> kernel.
>>> Yes, I'm sure you can find some more, but I'm really not sure this is 
>>> relevant
>>> for more than a handful of users.
>>
>> I see more reduction:
>> 15029248 - arch/x86/boot/bzImage
>> 15021056 - arch/x86/boot/bzImage.after
>>
>> ~8k
>>
>> 52542480 - vmlinux
>> 52523184 - vmlinux.after
>>
>> ~18k
>>
>> $ ../linux/scripts/bloat-o-meter vmlinux vmlinux.after
>> add/remove: 1/136 grow/shrink: 14/48 up/down: 15902/-22430 (-6528)
> 
> Did you disable CONFIG_XEN_PVHVM_GUEST in the before kernel, too?

Yes

$ grep PVHVM config-before config-after config-pvh-before:CONFIG_XEN_PVHVM=y
config-pvh-before:CONFIG_XEN_PVHVM_SMP=y
config-pvh-before:# CONFIG_XEN_PVHVM_GUEST is not set
config-pvh-after:# CONFIG_XEN_PVHVM_GUEST is not set

These three options change:
$ diff -u config-before config-after
-CONFIG_XEN_PVHVM=y
-CONFIG_XEN_PVHVM_SMP=y
-CONFIG_XEN_AUTO_XLATE=y

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 14:09:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 14:09:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384826.1627592 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrymz-0004zs-PG; Thu, 06 Aug 2026 14:09:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384826.1627592; Thu, 06 Aug 2026 14:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrymz-0004zl-Lt; Thu, 06 Aug 2026 14:09:41 +0000
Received: by outflank-mailman (input) for mailman id 1384826;
 Thu, 06 Aug 2026 14:09:40 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wrymy-0004zb-01
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:09:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrymx-0045I7-9h
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 16:09:39 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a74959f-2eae-0a2a0a5409dd-0a2a4502ddec-10
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:09:38 +0200
Received: from [52.101.43.6]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a7495a0-6ca4-0a2a45020019-34652b06de94-4
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:09:38 +0200
Received: from SJ0PR03CA0045.namprd03.prod.outlook.com (2603:10b6:a03:33e::20)
 by CH3PR12MB7593.namprd12.prod.outlook.com (2603:10b6:610:141::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Thu, 6 Aug
 2026 14:09:25 +0000
Received: from CO1PEPF00012E63.namprd05.prod.outlook.com
 (2603:10b6:a03:33e:cafe::73) by SJ0PR03CA0045.outlook.office365.com
 (2603:10b6:a03:33e::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.20 via Frontend Transport; Thu, 6
 Aug 2026 14:09:25 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CO1PEPF00012E63.mail.protection.outlook.com (10.167.249.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Thu, 6 Aug 2026 14:09:24 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 6 Aug
 2026 09:09:24 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Thu, 6 Aug
 2026 09:09:24 -0500
Received: from [172.19.79.34] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.41 via Frontend
 Transport; Thu, 6 Aug 2026 09:09:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Fhipckk14ODah3M+iu7gSTZr3+Ig0ZIvkTY0vt94EUexvA9iVdvc4/wU/XNd4P0T7F60KXOfz/fL7rLTGQgwMa7QrvF35TZELIYZAEC0UxPPH6+YlhQTX8B4/C/xcdZz4IEh4Ne+/A/3e5ecz7f1l29HV3tBcuWqufMsCDZ2G/+TbqJV+LJk6LYGvOSA18P3ZK48rqHu1xe3WjpbQcSsCSdDM3sp5ijhctazKv55bx9c3VlWweLMi0wFEUqrzdFDKDoyy7fbM6GtjGhJWCN9Uv3mG+L8lFsKnRJp45Ps/tVlLfJ5ReT26Mt8+DlzgdSvX7aBa/KhappmaRD+XCU+wQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HTnl1ehLlzrWHapilZ0dYORgkBNrPt2rSXy3za9bZWQ=;
 b=xCmKOP8vnqehGKTrcRLz9Hzz+OpQ7iF2H4wCKHn1/9qS94l4osWOG0RqouEATG2EQmiARUNoCnYlJi627OhQFkW/C++XZbeDzFIyEsI78V+GpwQH5CEjZlVTna5s3yaQTYdi13HaSl3FBFeshEwSbn77DgUpKxfAi89xHzQbh3qaVglmSqdS8FfpWdcVxDH6cpZGuuLKS1Ztk7vRameYhm6a7GBxbF+ngxFikjs8xOLXALcfUdcpcLTHRJo+/vF7/a056zQRsww4PO2x5NXISaxWF0wrB6PGIgrEJIoX5URjQ81zDPf8IAl9zYjvVrdULYwRtzqWSvK0lnaIV/QtoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=HTnl1ehLlzrWHapilZ0dYORgkBNrPt2rSXy3za9bZWQ=;
 b=AXzJ2L9BESrjHHLc8H1jmMT5u7t324uyHtXMWrQmnE1Wg/0aPI7RM43CcJM/sF9eoldLyrqY5MESySZuFDhaudHrFIcMWieN5PoanMi5b1ctYaPMNIaNHbUH3oSaJW9HeN1FPFCq/QELhkA3tjJ/6PCIGWOtIr6d30Nay6FnUxo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <29546ca9-1875-4c20-b42b-39c886f3d41c@amd.com>
Date: Thu, 6 Aug 2026 10:09:23 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <6991badc-dcc4-44b9-a048-29eb67c46d2e@apertussolutions.com>
 <7762513c-0d3a-465a-abd9-73e3ba586556@suse.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <7762513c-0d3a-465a-abd9-73e3ba586556@suse.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF00012E63:EE_|CH3PR12MB7593:EE_
X-MS-Office365-Filtering-Correlation-Id: 9101fe5a-ffa0-47c3-15e9-08def3c45222
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|1800799024|23010399003|376014|82310400026|18002099003|22082099003|13003099007|6133799003|11063799006|56012099006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	hKBiHbgit6k4kFJ097hW7JSzVb3zwUdux7kATasSulqR6VowylzBdYQkrZp4huXes8ZdiStaJnfvwosrmJpnbbgq/cTaew1ECHht7i25Ihc3ieFUVKlD9UTLq9f2sWGj2LD10RTXNqujUmaZpJ7cIFitLB75rzB7cxWIhGZQ6SXlSWW72n2rKmYhoKB9HPskQ2vwGZxaf9j9dIugCtVJIS52LmIfhbH9gJ0omFSA8My/gYUZmA6GYc9eXRN8WNexqiHix7VFUODshdfuLqWA1bj6YN3seVKob6VjObKAIJqoPNWAFzWCHMVOJ9uU7aHbZfl8Bg5ik9ic92IwKnNysPhGxEyj2isU6+uzqgrWKRjkCYabDZmktYqZQFUdTwMSgBs4pv+DQnATIZf7pNvtweL+/me5MUUPR+RX/gv0/+PM5+AS6YDv6sQ42aXUDC2d+bDqQj5b6HX00SdX7CadTczIqUKFCwNmeB53egNQYfAtMsNeDQ/DuQIo/4nqtdUJDaiz3GMYdpuudb5q5W46vBDcL/+sHH/89OFIo3au8/ErewqawoFPz7ATHtap+nntVlk41QBkuPHgEMrOyexHzaQYbnI0dzAv2tVu/fXePJwzrrbYNL2cjacrzeS140KSmXi8UGcNY4EfeU9a2IP3yE6DaHS0xFjEO1oTmd3USO8cM/g2qTgzs4s/dO4m4uzMBT4xjrbPh6Ivs4dQpdO3og==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(23010399003)(376014)(82310400026)(18002099003)(22082099003)(13003099007)(6133799003)(11063799006)(56012099006)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	BpZliNvyeF/EbtP3QEncxDe//U4smaiwL6D0lijgMAA5V22EtZIsDmjn9p/z4AJx3qDolcLxoHD6h3DbzjZ0OyJo8hbsSoFQF+n9yPYjfQBJ9lnAAvThJt78sDF/OSOWquYUIzVt3Z3713nL6WvQ/aDcKQWH93hNvlQ2rAIBUK9SmeGdZolbZXircbo17L97bXcbeL0uOVWFSCndPOlku0nse5QKJul/B+wvKY/iNZQZteMEeyQpey160QGQHiivWalOOC5Py2G2Vx2HM83WjD0XiGzpbZaFgVH4PONB2AKFwutwA0P2GOS0JH4CHwXHvOpbiom+bO5rKvGoEIcJ/pQTwPtw8Pn2FQnY+NDJwDXQO76hgzZ+wbGTShL/km0PHcRWawiTuimUQlLn24GEn9MjOw5n4iRr9Mb+mnFYdwVVxXgbhp5UhI1tXcPc2USP
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2026 14:09:24.9445
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9101fe5a-ffa0-47c3-15e9-08def3c45222
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF00012E63.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7593
X-purgate-ID: tlsNG-720697/1786025378-F38BC2AC-692CF31A/0/0
X-purgate-type: clean
X-purgate-size: 2036

On 2026-08-06 03:16, Jan Beulich wrote:
> On 06.08.2026 01:02, Daniel P. Smith wrote:
>> On 7/28/26 9:22 AM, Jan Beulich wrote:
>>> @@ -2307,7 +2308,7 @@ argo_init(struct domain *d)
>>>    {
>>>        struct argo_domain *argo;
>>>    
>>> -    if ( !opt_argo || xsm_argo_enable(d) )
>>> +    if ( !opt_argo || xsm_argo_enable(XSM_HOOK, d) )
>>
>> This question came up on another thread, so thought I might point it out
>> that when FLASK is in use this can return a nubmer of error codes beyond
>> an access deny. While I know it's the existing behavior, but if the
>> error code is anything other than -EPERM, then it's not that the policy
>> denied the access but something cause a fault in the security server. In
>> that case the domain is still being allowed to construct with the
>> assumption that it was a policy deny. At a minimum should the error code
>> at least get reported, and perhaps it should be passed up to domain
>> construction to allowing it to make an informed decision on construction?
>
> Sounds plausible, but definitely wants doing in a separate patch.

I think this is a mis-use of xsm_argo_enable().  As I wrote in [1], this 
isn't an access decision, but an ~optimization to skip initializing argo 
data structures when a domain is not allowed to use argo.

With Flask, this prints an AVC denial during domain construction when 
the domain doesn't have argo enabled.  That is misleading as it isn't 
the domain's action causing the access.  In OpenXT, I wrote a patch to 
add a noaudit variant to hide the denial.  I didn't upstream it because 
I didn't really like it.

The issue is really the conditional initialization of d->argo.  It seems 
like it would be simpler to always initialized argo for all domains. 
xsm_argo_enable() would still prevent using it, but internal checking of 
d->argo could be removed.

Regards,
Jason

[1] 
https://lore.kernel.org/xen-devel/758c8410-a18e-45dc-8944-5913e5832397@suse.com/T/#m149e1571b819a0cf481eea558c6220a5a24d5285


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 14:29:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 14:29:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384854.1627601 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrz5h-0001h5-GJ; Thu, 06 Aug 2026 14:29:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384854.1627601; Thu, 06 Aug 2026 14:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrz5h-0001gy-Cm; Thu, 06 Aug 2026 14:29:01 +0000
Received: by outflank-mailman (input) for mailman id 1384854;
 Thu, 06 Aug 2026 14:28:59 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrz5f-0001gs-6e
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:28:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrz5e-0010z3-8W
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 16:28:58 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a749a15-e002-0a2a0a5209dd-0a2a450baf20-34
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:28:58 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a749a29-b7e8-0a2a450b0019-d1558034c551-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:28:58 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4980dc26022so22404025e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 07:28:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995420cb4esm66193295e9.2.2026.08.06.07.28.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 07:28:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786026537; x=1786631337; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=dzaRPmaEHzQlkduFv0nG4HxLqJX6MeEmdM6T+7huPik=;
        b=DFDXbM9al6GvAxyc97QaUfXDdsy03XUaENB5pEkvO6BM0/2cbyfZJLQdKDNMj4sUFg
         nivnqICUE265WOUvlkL/Jbx3KDm4WgYC7sC/07S3/kXP6EsF2ODxap6mbDQc6abyn9eI
         N4Ujd2ncAusUhqS8aMOh1xeS2wsoChHEQsV80z2v6mRJt1/ykn2Cd87DLHE8+y4Bm4w2
         kwy6W65dccgkNGKEQWwRho8e0DfeVRt+uqL6vISvGmCHytcuEJuKwJZabVMeE/vUOe3U
         O3T5v3eOCMt1TCTVajk3T2ip/Yy2yzalLyb/CMOg3TyG6YySIiPwTeCVCZkNSISY3kb1
         E6sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786026537; x=1786631337;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=dzaRPmaEHzQlkduFv0nG4HxLqJX6MeEmdM6T+7huPik=;
        b=WuPkYtDZFAO3tbocjREMXi5F6IUmdVuvPew0acE/I0O6R8DgnKZBzqv3A8yfchcZoh
         jy6dVt2ZQYsKhwhEmecnidHlTalQwmgLYYvdHLlrIVFY28JBFHftnET5MQfchh+L1zeT
         46UQY8+zEHq+J1ab+B1LmsTHjj6iIrvTOAHA3YvZoXamPo/m+HgG/8pYBGEmsQjVBz+z
         wkFO8rLp1W0qSTy1BCAtvPQzW/Y9mClboFcmItNDZ6k0pvNVZMKiju82qeDI6Q36HUlw
         Uc6qYKEWnP3XzURY8GMh0mSWF8BQQh4iwzgF9JTXMmdokiol/aFVRuCdWlhNJFZw3Onc
         Afkg==
X-Forwarded-Encrypted: i=1; AHgh+Rrw8SooQIS5okhP67Z/CzyCJ+PvwMumn2IjHsJXd4Jk+OiiaQAePD/E0icHty93T0kMRWxBd2Xs20I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+gl7DBvxNOF7jkhSNpUAIAWjDe0gRCFuozoh+nOXxOPwARQuT
	21vAq0f5fqi10CgIarTwA+u7g0iW8ZkTdx668UMDJtfDAIIqSNWR3zpwrUf/w2sERA==
X-Gm-Gg: AR+sD12iupUHXs2gsXDXU9MCY/AUy84EPpaJH5TMG4BIJFBk30DSQbq4tKUIgkNTRcy
	FwRI2Wbn/oV5VrOy2kLegcimQk3wGRERSuCil/2ARaqmggkz1dAr1JiAfdER1j1J8wvCpOYnX5A
	20/x8dm1JgRaYNPrK/7FLvrJZsuT0JOHo3i5y5dmjGeW18rRFMQuUgis2nPThXS4suz+xu7YtGw
	bf8OzJz7c8s7WKHi+htczcOo/MiCQSFuS/uWahPDvI7/6uUjZ53N0kiimrYWXsDN0P5XbMBDU5v
	251mzbNIH5tAK0l/+61xbAVK5G9ep4j5SIkcvWsJGR3cp6OQlOR1rORWsjGjig1zqLDZAnSsrpU
	a67iwbDZU6srUxHYcjUVJFYY/tMXtR+UBJ5rKbmoGZVE3Za2PiPt7NL0Qr2vaa1/IBld6CNS6hy
	txWxkMfV9wrP7nxDPdCYI6gHHflRPmGRTeMFIVWKORsV3kXEzdE/leLcCBIfpKeB6oUWOfe2qrM
	pAdtwbbaQdpDQUwGsYqcF5pPbbQDgxXZWudvN45TGT9DqbUr4Tx
X-Received: by 2002:a05:600c:474f:b0:499:5210:c537 with SMTP id 5b1f17b1804b1-4995210c57fmr106068785e9.1.1786026537383;
        Thu, 06 Aug 2026 07:28:57 -0700 (PDT)
Message-ID: <57793423-aadd-4786-90fd-2923925b766d@suse.com>
Date: Thu, 6 Aug 2026 16:28:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786026538-AB4D39EA-C2C9447D/10/73395122804
X-purgate-type: spam
X-purgate-size: 14636

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> 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 <Romain.Caritey@microchip.com>
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
> Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech> # vaplic_mmio_{read,write}

For this tag to have any meaning, it should move ahead of the --- above;
the explanations ...

> The downstream changes related to `vaplic_mmio_{read,write}` were originally
> in a separate patch (which was reviewed by Baptiste). However, before
> upstreaming, it was decided to merge them into the current patch.
> I added `Reviewed-by: Baptiste` in this form for now, but Baptiste will
> probably review the remaining changes as well.
> Once that happens, I'll simply move the `Reviewed-by` tag up and
> remove the `#`.

... here rather explain the restriction on the R-b, not its odd placement.

> ---
> Changes in v3:

As this looks to be recurring - please get versioning of your series right.
The series is supposedly v1, but here you give the impression of it being
v3. If there really was an earlier v2 posting, why isn't the entire series
here v3?

> --- a/xen/arch/riscv/aplic-priv.h
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -48,4 +48,6 @@ struct aplic_priv {
>   */
>  extern unsigned int guest_aplic_num_sources;
>  
> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, uint32_t base_val);

PLease can you, before submitting, self-review your patches? I'm really
getting tired of having to repeatedly point out basic style issues, like
the overlong line here.

> @@ -38,6 +39,60 @@ static struct intc_info __ro_after_init aplic_info = {
>      .hw_variant = INTC_APLIC,
>  };
>  
> +static unsigned long aplic_hart_field(unsigned long hartid)
> +{
> +    const struct imsic_config *imsic = imsic_get_config();
> +    unsigned int lhxw = imsic->hart_index_bits;
> +    unsigned int hhxw = imsic->group_index_bits;

It extends to the other local variables here, but I'll use these two to
try to make my point: I'm struggling to associate the names with the
values they are set to. Likely "hxw" is an abbreviation of hart index
width, but (a) what's the leading 'l' then and (b) why is there no 'g'
in "hhxw"? By using hard to grasp names, you make it hard to actually
understand the subsequent expressions, in particular ...

> +    unsigned int hhxs =
> +        imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;
> +    unsigned long tppn =
> +        imsic->msi[hartid].base_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
> +    unsigned long group_index =
> +        (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
> +        APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
> +
> +    return (group_index << lhxw) | hartid;

... these last two. As it stands, they may be easier to understand if
you didn't have the local variables at all, despite them then getting
textually longer.

> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, uint32_t base_val)

Same issue as with the decl.

> +{
> +    unsigned int guest_id = vcpu_guest_file_id(target_vcpu);
> +    unsigned long hart_id = cpuid_to_hartid(target_vcpu->processor);
> +    unsigned long hart_field = aplic_hart_field(hart_id);
> +
> +    base_val &= APLIC_TARGET_EIID_MASK;
> +    base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX_MASK);
> +    base_val |= MASK_INSR(hart_field, APLIC_TARGET_HART_IDX_MASK);
> +
> +    return base_val;
> +}
> +
> +uint32_t aplic_hw_read_reg(unsigned int offset, uint32_t mask)
> +{
> +    unsigned long flags;
> +    uint32_t val;
> +
> +    ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t)));
> +
> +    spin_lock_irqsave(&aplic.lock, flags);
> +    val = readl((volatile void __iomem *)aplic.regs + offset) & mask;

Wouldn't this applying of a mask better be done in those callers which
actually need it? It's not the least the asymmetry with ...

> +    spin_unlock_irqrestore(&aplic.lock, flags);
> +
> +    return val;
> +}
> +
> +void aplic_hw_write_reg(unsigned int offset, uint32_t value)

... this which I consider unhelpful.

> --- a/xen/arch/riscv/include/asm/aplic.h
> +++ b/xen/arch/riscv/include/asm/aplic.h
> @@ -28,6 +28,8 @@
>  #define APLIC_DOMAINCFG_BE      BIT(0, U)
>  
>  /* sourcecfg register fields */
> +#define APLIC_SOURCECFG_D       BIT(10, U)

As to the comment - this indeed looks to be a field, but ...

>  #define APLIC_SOURCECFG_SM_INACTIVE     0x0
>  #define APLIC_SOURCECFG_SM_DETACH       0x1
>  #define APLIC_SOURCECFG_SM_EDGE_RISE    0x4

... these look to be values of some other field which isn't described. Please
may I (again) ask that definitions are their commentary at the very least not
misguide readers?

> --- a/xen/arch/riscv/include/asm/imsic.h
> +++ b/xen/arch/riscv/include/asm/imsic.h
> @@ -40,6 +40,16 @@ struct imsic_config {
>      /* Base address */
>      paddr_t base_addr;
>  
> +    /*
> +     * MSI Target Address Scheme
> +     *
> +     * XLEN-1                                                12     0
> +     * |                                                     |     |
> +     * -------------------------------------------------------------
> +     * |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
> +     * -------------------------------------------------------------
> +     */

And the xxx-es in here mean what exactly? Don't care? Some other, unrelated
values? Yet something else?

> --- a/xen/arch/riscv/vaplic.c
> +++ b/xen/arch/riscv/vaplic.c
> @@ -17,6 +17,7 @@
>  #include <asm/aia.h>
>  #include <asm/imsic.h>
>  #include <asm/intc.h>
> +#include <asm/mmio.h>
>  #include <asm/vaplic.h>
>  
>  #include "aplic-priv.h"
> @@ -27,6 +28,256 @@ unsigned int __ro_after_init guest_aplic_num_sources;
>  
>  #define FDT_VAPLIC_INT_CELLS 2
>  
> +#define AUTH_IRQ_BIT(d, irqn) ( \
> +    ((irqn) < (d)->arch.vintc->nr_virqs) && \
> +    test_bit(irqn, (d)->arch.vintc->used_irqs) )

Nit: Indentation.

> +/*
> + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to
> + * a 32-bit word index into the allocated_irqs bitmap.  Each word covers 32
> + * interrupt sources.  For SOURCECFG and TARGET groups the same division also
> + * 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 inline uint32_t generate_auth_mask(const struct domain *d,
> +                                          unsigned int word_idx)
> +{
> +    unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
> +
> +    if ( word_idx >= DIV_ROUND_UP(d->arch.vintc->nr_virqs,
> +                                  sizeof(uint32_t) * BITS_PER_BYTE) )
> +    {
> +        dprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx);

Is this really meant to stay?

> +        return 0U;

The U suffix is mainly (even if only slightly) obfuscating things, I think.

> +    }
> +
> +    return (uint32_t)(d->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >>
> +                      (first_bit % BITS_PER_LONG));

I don't quite understand the need for the cast.

> +static int cf_check vaplic_emulate_load(const struct vcpu *v,

Why the cf_check (also for the store counterpart)?

> +static int cf_check vaplic_emulate_store(const struct vcpu *v,
> +                                         unsigned long addr, uint32_t value)
> +{
> +    int rc = -EINVAL;
> +    const struct domain *d = v->domain;
> +    unsigned int offset = addr & APLIC_REG_OFFSET_MASK;
> +
> +    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 =
> +            regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK);
> +
> +        value &= generate_auth_mask(d, word_idx);
> +
> +        break;
> +    }
> +
> +    case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST:
> +        if ( value & APLIC_SOURCECFG_D )
> +        {
> +            rc = -EOPNOTSUPP;
> +
> +            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(d, regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) )
> +            /* Interrupt not enabled, ignore it */
> +            return 0;
> +
> +        if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW )
> +        {
> +            gdprintk(XENLOG_ERR,
> +                     "value(%u) is incorrect for sourcecfg register\n", value);
> +
> +            return 0;
> +        }
> +
> +        break;
> +
> +    case APLIC_TARGET_BASE ... APLIC_TARGET_LAST:
> +    {
> +        struct vcpu *target_vcpu = NULL;
> +        unsigned int hart_idx = value >> APLIC_TARGET_HART_IDX_SHIFT;
> +
> +        /*
> +         * Look at vaplic_emulate_load() for explanation why
> +         * APLIC_GENMSI is subtracted.
> +         */
> +        if ( !AUTH_IRQ_BIT(d, regoffset_to_word_idx(offset - APLIC_GENMSI)) )
> +            /* Interrupt not enabled, ignore it */
> +            return 0;
> +
> +        if ( hart_idx < v->domain->max_vcpus )

You have d as a local variable.

> +            target_vcpu = v->domain->vcpu[hart_idx];

Use domain_vcpu()?

> +        if ( !target_vcpu )
> +        {
> +            dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n");
> +
> +            /* Ignore such writings */
> +            return 0;
> +        }
> +
> +        value = aplic_msi_target_gen(target_vcpu, value);
> +
> +        break;
> +    }
> +
> +    case APLIC_SETIPNUM:
> +    case APLIC_SETIPNUM_LE:
> +    case APLIC_CLRIPNUM:
> +    case APLIC_SETIENUM:
> +    case APLIC_CLRIENUM:
> +        if ( !value || !AUTH_IRQ_BIT(d, value) )
> +            return 0;
> +
> +        break;
> +
> +    case APLIC_DOMAINCFG:
> +    {
> +        struct vaplic *vaplic = to_vaplic(v->domain);
> +
> +        /*
> +         * The domaincfg register has this format:
> +         * bits 31:24 read-only 0x80
> +         * bit 8      IE
> +         * bit 7      read-only 0
> +         * bit 2      DM (WARL)
> +         * bit 0      BE (WARL)
> +         *
> +         * The most interesting bit for us is IE(Interrupt Enable) bit.
> +         * At the moment, at least, Linux doesn't use domaincfg.IE bit to
> +         * disable interrupts globally, but if one day someone will use it
> +         * then extra actions should be done.
> +         *
> +         * Only DM (bit 2) and IE (bit 8) are writable here. They are assigned
> +         * (not OR-ed) so that a write of 0 can also clear them (WARL), and the
> +         * read-only high byte (0x80) is always kept set on read-back.
> +         */
> +        if ( value & ~(APLIC_DOMAINCFG_RO | APLIC_DOMAINCFG_DM |
> +                       APLIC_DOMAINCFG_IE) )
> +            printk_once("%s: Ignore writes to non-writable domaincfg bits as "
> +                        "they are set by aplic during initialization in Xen\n",
> +                        __func__);
> +
> +        vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO |
> +                                 (value & (APLIC_DOMAINCFG_DM |
> +                                           APLIC_DOMAINCFG_IE));
> +
> +        return 0;
> +    }
> +
> +    default:
> +        goto fail;

Instead of this goto, I think you simply want to move the label here.
That'll also make the function more similar to its load counterpart.

> @@ -105,6 +356,50 @@ static const struct vintc_init_ops __initconstrel init_ops = {
>      .make_domu_dt_node = vaplic_make_domu_dt_node,
>  };
>  
> +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, mmio_info_t *info,
> +                                               register_t *r)
> +{
> +    uint32_t data = 0;
> +
> +    if ( info->len != sizeof(uint32_t) ||
> +         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
> +    {
> +        gdprintk(XENLOG_DEBUG,
> +                 "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n",
> +                 info->gpa, info->len);

You have v passed in here, but you'd log current. If passing in v is
necessary (i.e. here or elsewhere it may be other than current), then you
need to either ASSERT(v == current) at the top of the funciton or otherwise
handle v != current correctly.

> +        return IO_ABORT;
> +    }
> +
> +    if ( vaplic_emulate_load(v, info->gpa, &data) < 0 )

If all you care about is a boolean result, why not make the function return
bool?

> +        return IO_ABORT;
> +
> +    *r = data;
> +    return IO_HANDLED;

Nit: Blank line please ahead of <etc>.

> +static enum io_state cf_check vaplic_mmio_write(struct vcpu *v, mmio_info_t *info,
> +                                                register_t r)
> +{
> +    if ( info->len != sizeof(uint32_t) ||
> +         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
> +    {
> +        gdprintk(XENLOG_DEBUG,
> +                 "VAPLIC: unaligned/wrong-width write gpa=%"PRIpaddr" len=%u\n",
> +                 info->gpa, info->len);
> +        return IO_ABORT;
> +    }
> +
> +    if ( vaplic_emulate_store(v, info->gpa, r) < 0 )

Same here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 14:43:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 14:43:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384867.1627611 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrzJV-0005cO-Kp; Thu, 06 Aug 2026 14:43:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384867.1627611; Thu, 06 Aug 2026 14:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrzJV-0005cH-I0; Thu, 06 Aug 2026 14:43:17 +0000
Received: by outflank-mailman (input) for mailman id 1384867;
 Thu, 06 Aug 2026 14:43:16 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gyf161023@gmail.com>) id 1wrzJU-0005cB-P2
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:43:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrzJT-004AKZ-J6
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 16:43:15 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <gyf161023@gmail.com>)
 id 6a749d72-bab6-0a2a0a5309dd-0a2a4506e8b2-28
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:43:15 +0200
Received: from [209.85.222.173] (helo=mail-qk1-f173.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <gyf161023@gmail.com>)
 id 6a749d82-195a-0a2a45060019-d155deade5ac-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:43:15 +0200
Received: by mail-qk1-f173.google.com with SMTP id
 af79cd13be357-92ed3993c1eso122815385a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 07:43:15 -0700 (PDT)
Received: from LAPTOP-DPAKMOI4.it.purdue.edu (pal-210-106-74.itap.purdue.edu.
 [128.210.106.74]) by smtp.gmail.com with ESMTPSA id
 6a1803df08f44-9088a219ea8sm35070376d6.37.2026.08.06.07.43.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 06 Aug 2026 07:43:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786027394; x=1786632194; 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=mQCss4lFgE6Dwf1NizCh8ZHT2e94D2G9yvtYGo+Xll0=;
        b=aZTJbtITyY6Y9eLkwnxb/0uNSxHV9TlnK46I6nZZlacGx7iw6pF50IiTJ2AlvipjKg
         mTm/XJxazqQaxEmFgMxN0uQ4RV4fHtWHGNfvfPz3rVsjGJ3vrQKR3hMwU7ByG3JeGh7j
         Gm1BNYsT0IelzmgpWAGNuQvPQRej+6GY3ur3lz+Mf/E1A+DGgGE6O+gVoNiGZAPbeRPC
         VFEQUtOlMVO89hNXHa+1mtK7qI4pynvM1WU8o8cJpOabrDQ/8j5iIONM0fE2ToUpvScc
         /3VhdH881N0NvCdhmyr7VtaCLGvDE8Tu7rzHPXRyMZ0ErjVnRnxtnLmJNWRxgEt+QwX1
         abvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786027394; x=1786632194;
        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=mQCss4lFgE6Dwf1NizCh8ZHT2e94D2G9yvtYGo+Xll0=;
        b=oK6s9JO0IOKa+xvGp8sSOGC6cwmGIHekoguGABCWFD3Dk6JC5l/RwHFagNSOhcKjDq
         29abejOqKAIHtk2bSbGp9kvy53eSZalIp+PBcurvlD3a5JsxkVTiu2CDvD+94gB6a18g
         zz8Vhx88dKyWoFxomu5Lo6nsFVyJojSKmtS3sEKkfPRj7KDcFkk31jlkvrtzlRpOcX6l
         iY0tQ7LgpF4qJQzARjfxaI0W6vSbARHRGFwDA+SURlsEaR8ZuTQGo+Ckmr3eqP/jx03I
         o08BlXyOOq1210mn9Vn1Isjp2dL56vDztuI8VK3sZapTmVSj9/wCFyi76qYpXx704xp+
         RkyA==
X-Forwarded-Encrypted: i=1; AHgh+RrN4cePeeUnr2lLzt7++JGHkzr81cb2luWu7ZHUJjuHk1JBxSOptfpNP0y80CpcdYSmdBmbcy9+33E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWXZea0WTBQgYCyQnon6Fpx1yyQJxnysUJD9upH5ppH52fyHhg
	jqQbHudbI/oi6FfA0RADMJNHdw76lLSq0Q9vMAPefv6IdhqC150TwYgB
X-Gm-Gg: AR+sD13ehG1dJqKT2D8czvE7C515ikDZT2fo2fnngX8e8mxkMklw7IT7JuAEqWfe0iq
	Net49qIfPQ4AafuIcekEQctuEmGfsMifi/zkHkcEtxQ14wPhhzwbT1RjtVMyVCwyyOkyTUr+vl5
	DBYVOFueyyNXAscoh0/NKxu2VH3tKXCx2e3O9cA9KpvGjQ0YCJPRLfbrrFkP2fqF9COC7I/baLS
	WKLB2CyFv847wGqTvvdVPsvmFgJc5TjmdVmObaT+y2rjZ3oPuwcgiNpiR4Wd438DAREymGm5Jgk
	QwFk9Y/xd0HkW2Io/Sohor8pwQI44e2Gd95Z+/UKHNAEWjqonoJH9NtFvqriPfqycY3uS/fC/3p
	VhwC93DMQ/ja7LzZ9Hdd3f4KpCXEPV3TfSbwIeFuorU0osLNwEAFNIE9bhIkC0GEypY2HfQEZfY
	JYG2+RhaONi81BzdUfWUOvJvfvxgf9iIIkxqdYP2Zsi/rI8994/FQLDdFGd7zMsj32p0dB8gpsv
	xJyAED0HaI2IV85K+UlOSJ5H74h6l58R0cHL2iD3J8=
X-Received: by 2002:ac8:5e08:0:b0:527:f0a:ccbc with SMTP id d75a77b69052e-52ce5fa28acmr159831981cf.18.1786027393869;
        Thu, 06 Aug 2026 07:43:13 -0700 (PDT)
From: Yifei Gao <gyf161023@gmail.com>
To: Eric Van Hensbergen <ericvh@kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>,
	Dominique Martinet <asmadeus@codewreck.org>,
	v9fs@lists.linux.dev
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
	Juergen Gross <jgross@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	stable@vger.kernel.org,
	Yifei Gao <gyf161023@gmail.com>
Subject: [PATCH v2] 9p/xen: fix refcount leak in p9_xen_response() on wrong tag
Date: Thu,  6 Aug 2026 14:42:54 +0000
Message-ID: <20260806144255.4167019-1-gyf161023@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260804213550.3409638-1-gyf161023@gmail.com>
References: <20260804213550.3409638-1-gyf161023@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786027395-FE27077B-8C9B03B3/0/0
X-purgate-type: clean
X-purgate-size: 1515

p9_xen_response() looks up the request for an incoming reply with
p9_tag_lookup(), which takes a reference on the returned p9_req_t. When
the tag does not resolve to a request in REQ_STATUS_SENT, the function
warns and continues the loop without dropping that reference, permanently
leaking the p9_req_t and its msize buffers. The reply header, including
the tag, is supplied by the backend, so a malicious or buggy 9P backend
can leak kernel memory on every crafted response.

Drop the reference before continuing.

Fixes: 728356dedeff ("9p: Add refcount to p9_req_t")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Yifei Gao <gyf161023@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
v2:
  - Fix Fixes: tag to reference the correct commit (728356dedeff).
  - Drop the inaccurate trans_fd.c comparison from the changelog.
  - Add Reviewed-by from Stefano.


 net/9p/trans_xen.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index f9fb2db7a066..8eea0da8797f 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -203,6 +203,8 @@ static void p9_xen_response(struct work_struct *work)
 		req = p9_tag_lookup(priv->client, h.tag);
 		if (!req || req->status != REQ_STATUS_SENT) {
 			dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag);
+			if (req)
+				p9_req_put(priv->client, req);
 			cons += h.size;
 			virt_mb();
 			ring->intf->in_cons = cons;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 14:48:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 14:48:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384886.1627619 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrzOD-00077P-5L; Thu, 06 Aug 2026 14:48:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384886.1627619; Thu, 06 Aug 2026 14:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrzOD-00077I-2G; Thu, 06 Aug 2026 14:48:09 +0000
Received: by outflank-mailman (input) for mailman id 1384886;
 Thu, 06 Aug 2026 14:48:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wrzOB-00077C-RX
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:48:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrzOB-004XwN-1c
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 16:48:07 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a749ea0-e002-0a2a0a5209dd-0a2a45029324-6
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:48:03 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a749ea3-6ca4-0a2a45020019-d1558035e41a-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:48:03 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso17093035e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 07:48:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995422b741sm73799625e9.14.2026.08.06.07.48.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 07:48:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786027683; x=1786632483; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=yeruhxuIPamUdYkWP7spwzBqzWKRPoiRPaCXYfXcQp4=;
        b=dou3MvI95s38manyguIPx5CCo8HLb1khLoieNt7hO81g/hqEDn2NVvc1pUKXF28RsM
         lxHNvl12EsZUKBQ2z6Jg3zJpQrbkG3r+wxVy0BuXAkzTgM7sTgcOZ7Cmsyv5w0E7RCYy
         kwuTPudOCY14pmuoXg4tRMUFb9Vypiv1Q2lhVX2uSl+BC81BHQF4p0HDtpW4meJPBNB2
         9zdkRkxChi60itToUt+Nm+KFCbrY0LFFtNl8SwaLU+onWRvWFXwZcPL9ytKkrENhhc1a
         qTqVNCoVo/as2OLIRGSmTkGRZkyy/gU6WtB34OIeolYuHhOYlVjl4cBsJaUdc5X6af8a
         qY3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786027683; x=1786632483;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=yeruhxuIPamUdYkWP7spwzBqzWKRPoiRPaCXYfXcQp4=;
        b=O1HOhLlnle8u2bfsYCVWBNnrybn3A/y+1tWh4zvog1v42NLAcUFkm5Mi/t9cWM+YNY
         1xHN2l4hCANmFwOeHMfcMt9UYYLgD5ZIelwzeguMuyPpcL0q3QdO5i8x4iLAt22sFa42
         XNTeb5M3PgC3DjWYcwEu7mMEPe2++yqsf6OfvkJwRhBtnqEBzfZom0HFSnUSQsEQiEy5
         9GVEy+FgTi7wQkpEwfoVgCKFKsHXDs3IkZtTUEtTrmm8yPgtC0pweZtScCoUhJYexR0X
         v5rYgO9FTW2FCaWdcwXfpbS2NZyEiY59XGvH+XjPKCg9HoLj71igDjzbxIEG5CyzNID5
         Obpg==
X-Forwarded-Encrypted: i=1; AHgh+RrqQ4azrhovjs1hvnKvCRlMHiJMvUIY/oh8QgllwkU7Qdaga4fVon4/nt9pJ/nAdxunOncVtBgVRyI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8skxZG+9bwKkthBV9ElagHg2nGW4QWdUG7akV5yjOYUiCNDRc
	O5jaZm6oohixLrNHPOKyIDB3qm2YeLlBshot75/pNBIfVvwPRBr0OdOTfCPcNaUBog==
X-Gm-Gg: AR+sD12yQcK0l2bcglV5IJ1Ku9nKw4KBZ3NytuMwjmmA7u7PCYawmKWAEyPU+Tw00+f
	hJTIxJz0zJrY8gCz+UPBU9n4GmVPo6XTDXdsc6aIiY8p7eNdLlAWfktfDnXpooIE83enNJIneRR
	//ATvRP7NpXd/gvRC5pam4bqqFvWY/JmqXITTEx0hWAwc/L5OBdXage8WfAvplIrogm5qlkYy1u
	h7Eq+ISpRVt9YAG1fpUodVo4NnBYPKVJ8MEIa0P9pk8XP4dD0+NPJn1tGQF4dBNK4LDztbKX0su
	Ac8HPjXKaolYUiyHj3LU0lF9XHSDqRFSfXG4Hcgcs/z+REdkDhTiet2doUlZzRjugMz3z4OLyhD
	aalcGKz+AydIfK9ySeLQTrkRPu6IhwVLryUJwafFvY74zxejqMI1UyXhSL73foNomuTQ2WNudtV
	jyIpCEqbXEiiQsM6j8abcbaRlGK+EQWjn005/qh9vDnDWSEcZTt5ntDFsnUNC9ex8e/f+4m7sTt
	Braur25KSNGUfN25QsyGC1K2VCIv+FEQGEWpvsgILAfysIl9fxN
X-Received: by 2002:a05:600c:529b:b0:493:a613:56b2 with SMTP id 5b1f17b1804b1-4994e71d3e5mr224238625e9.8.1786027682662;
        Thu, 06 Aug 2026 07:48:02 -0700 (PDT)
Message-ID: <dda2f05b-2965-4fff-92d9-326619be313b@suse.com>
Date: Thu, 6 Aug 2026 16:48:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786027683-307C22AC-0DD0A8B4/10/73395122804
X-purgate-type: spam
X-purgate-size: 4328

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> 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 <oleksii.kurochko@gmail.com>
> ---
> The corresponding unmap of the IMSIC interrupt file will be introduced
> separately when the need arises.

Doesn't the need exist right away? There is ...

> @@ -342,6 +344,67 @@ static int __init imsic_parse_node(const struct dt_device_node *node,
>      return 0;
>  }
>  
> +/*
> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU v
> + * 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 block,
> + * 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 hart.
> + *
> + * Xen pins each vCPU to a pCPU (v->processor) and assigns it a physical

... an apparently wrong assumption here: Xen doesn't normally pin vCPU-s.
When a vCPU migrates between pCPU-s, clearly the mapping referencing the
page associated with the old hart needs tearing down again.

That said, since the new mapping will appear at the same GFN, the original
mapping may simply end up being replaced. If such direct replacement is
legitimate to do, maybe this could actually be mentioned here?

> + * guest file index (guest_file_id) from the vGEIN allocator. A guest_file_id
> + * of 0 indicates that no hardware guest file is selected (matching the
> + * architectural behavior where vGEIN = 0 in the hstatus CSR selects no
> + * guest external interrupt source), requiring the VS-file to be emulated
> + * in software.
> + *
> + * 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 current pCPU.
> + */
> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
> +{
> +    int res = 0;
> +    struct domain *d = v->domain;
> +    unsigned int cpu = v->processor;
> +    vaddr_t gaddr = imsic_cfg.base_addr + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);
> +    paddr_t paddr;
> +    unsigned long guest_stride;
> +
> +    /* Nothing to map in the case of sw interrupt file. */
> +    if ( !vsfile_id )
> +        return res;
> +
> +    guest_stride = vsfile_id * IMSIC_MMIO_PAGE_SZ;

To me "stride" feels the wrong term here, as there's nothing that repeats.
"offset" likely would be better, assuming the use of this local variable is
really deemed worth it, as it's used ...

> +    paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset +
> +            guest_stride;

... only here.

> +#ifdef IMSIC_DEBUG
> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
> +#endif
> +
> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
> +                           arch_dt_passthrough_p2m_type());
> +    if ( res )
> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",
> +               __func__, paddr, gaddr);

I think you mean to use PRIpaddr with paddr_t (oddly enough there's no
PRIgaddr).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 14:56:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 14:56:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384898.1627629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrzWb-0000fS-2G; Thu, 06 Aug 2026 14:56:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384898.1627629; Thu, 06 Aug 2026 14:56:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wrzWa-0000fL-Up; Thu, 06 Aug 2026 14:56:48 +0000
Received: by outflank-mailman (input) for mailman id 1384898;
 Thu, 06 Aug 2026 14:56:47 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wrzWZ-0000fF-Ou
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 14:56:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wrzWZ-004CAw-5Y
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 16:56:47 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a74a09e-5cb7-0a2a0a5109dd-0a2a4501df4a-32
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:56:47 +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 <jbeulich@suse.com>)
 id 6a74a0ae-5984-0a2a45010019-d1558030e075-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:56:47 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4956242332dso18106905e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 07:56:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49954206d72sm100063155e9.1.2026.08.06.07.56.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 07:56:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786028206; x=1786633006; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=pMXs6HRqpuYzHBhbiGaH5JuzeeH9ysfL+n/X4NDredY=;
        b=AIF5yAQ3fReRo96L/XGDOpQjmUEbWK5rY8eu3+BCbra8lFDmMT7bpGHuB+Se8pvxBc
         IyT/fSihpd/C2Tp8xtynMx152QYkJHmBF3kWF0UhQoZl2dQnlwNglplZgbvNLjJCifXX
         vDdxNQfX/luMGaCSwoepBadlHFXsU68mstnAMPFNkQ5FhWnlmtgYLYv4jtauttyERd56
         mkbKTVaQsHE44lTyeXm+9M2vMM5Rs/Zq8vNYy2z11v+73o7XyA0pBW8sV1OfpVVZlrzL
         0VI1TaaJOMy1bVxdzZkgDGEPKo6q414j2G9ja0vt7/b2lMGpw4Ld6w0JntwXLOExUYxO
         xDNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786028206; x=1786633006;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=pMXs6HRqpuYzHBhbiGaH5JuzeeH9ysfL+n/X4NDredY=;
        b=SOPX7IssFeNmx69kCIj7q72FTmejQo1Ctr09CU4GKdYZTMEfuR0J6VX62x5oKbosa1
         BDHC9lq0+1XIM3RVx8cNE9Vu1WvBJdlvOF+sEW3a1xYvyT6WuOLM8ENrcwuMdFYtNZcW
         R6ux5hZo/cIF6veMHlafTxyIl7WNjh3YzuOozRxhP1QEt+Uk9ZasU/8qJg9EpuCqxFnv
         GkPA/Wzuv6aTmOHRAEgu4kH3bABGgq0Uo2XA64uqJfEiUNirSJkHhVLwgIxs5rCiFuLY
         vE/EwOutoIn9xWuKQVF+cq517lBUV/tHcJitp2foodlpW8Rz+12ZdMfplUnzvSm8YihF
         VQHg==
X-Forwarded-Encrypted: i=1; AHgh+RrOziqSp3CcH1f/qxP/vbOshbZHAepvgY5m49o9tlCVi5h+xyw1D4YP9E0LFFp29YUCLc4wsEw2JmU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxVdxnvoLnaIWWW8xrJkdBz3WwUMlsxkg4GVCdb+RIHmVBo+lTx
	/S2diz4CB+LEUKMR78FAYzp/zacQ/pb3F3ob8USGln2ezSJGXAUcpzgejA9I9xMDAQ==
X-Gm-Gg: AR+sD121w6ZnScminG6oo4o2p0D7vTBl3gv9GJSS9HTl0C2v3mJ+MvUDvolZElZr9wX
	ttjX3zXK+SigkpaItkA6UjHgqsVDvmArBTQBNWn7S/ifEd/kZ0YL2LfwUYNeBKyVcKgHCmgUwnu
	D0SprppXylNN8RPouVRSpWIMqY/3mmCPtzmlpqIuXF4DJ2hoTU5zjbN8mIXVwvrD613t4SjHuV0
	oKW1hj+Q67ZzV7JieJCt+I9dyBLuN9Nzqe3rTCxuOAVy9+LczL5rz44UMvzDVjuXUIJEdc9ud6/
	0E7YIlt+lD9hinEGdL2Jeg4EsVM7gRCYpyk50OKGcdZiBLPdd3F2W0Q9YB15sbgrbvcWz9Lfx77
	4dR4iTxBSO/i2r+Zl/ODRE/fzpV0A0YF7j0C6Nlcn3IUEFbnnEU56XvYxD024kqIu/oMVMlZI6t
	1G/KQDor8cXPDe/aN4XCcVz0tlzV12G0pE7T4fjs4YyPXyXw0ImP2UghXhG2ubZCGVmwDX8KrBT
	bAMy8Y+YRjsdg1oUsToC8G32W2YSbjeCGiBuJdtNKbmBNtjkcL1
X-Received: by 2002:a05:600c:1992:b0:496:c378:6420 with SMTP id 5b1f17b1804b1-4994e71a1c9mr188832845e9.8.1786028206534;
        Thu, 06 Aug 2026 07:56:46 -0700 (PDT)
Message-ID: <f3e14d18-7732-4a34-9ae4-31cdc89e6495@suse.com>
Date: Thu, 6 Aug 2026 16:56:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786028207-BD146757-FB7EF3BC/0/0
X-purgate-type: clean
X-purgate-size: 3096

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> Introduce vcpu_aia_init() 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, vcpu_aia_init() will instead be
> called from a later point in the scheduling path (e.g.
> continue_to_new_vcpu()), to be introduced in a follow-up patch. Since
> it will end up being called from a non-__init context, it is not
> itself marked __init.

If it's called during scheduling, perhaps vcpu_aia_init() simply isn't
an appropriate name, and that issue is then also reflected in a
misleading patch subject?

> @@ -36,6 +37,35 @@ bool aia_usable(void)
>      return _aia_usable;
>  }
>  
> +void vcpu_aia_init(struct vcpu *v)
> +{
> +    unsigned int new_vsfile_id;
> +    int rc;
> +
> +    if ( !aia_usable() )
> +        return;
> +
> +    new_vsfile_id = vgein_assign(v);
> +
> +    /*
> +     * vgein_assign() returns 0 when no free h/w guest interrupt file is
> +     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
> +     * in that case.
> +     */
> +    rc = imsic_map_guest_file(v, new_vsfile_id);
> +    if ( rc )
> +    {
> +        /* Can't continue w/o correctly mapped IMSIC interrupt file */
> +        domain_crash(v->domain);
> +        return;
> +    }
> +
> +    vcpu_guest_cpu_user_regs(v)->hstatus |=
> +        MASK_INSR(new_vsfile_id, HSTATUS_VGEIN);

Looks like you're assuming that no other ID was previously stored in that
field. That can't be quite right when the function is called after the
vCPU moved to a different pCPU.

> --- a/xen/arch/riscv/imsic.c
> +++ b/xen/arch/riscv/imsic.c
> @@ -83,6 +83,19 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v)
>      return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id);
>  }
>  
> +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id)
> +{
> +    unsigned long flags;
> +    struct vimsic_state *vimsic_state = v->arch.vimsic_state;
> +    unsigned long pcpu = ( !guest_file_id ) ?
> +                         NR_CPUS : cpuid_to_hartid(v->processor);

"pcpu" as a name is misleading when what you store is a hart ID. NR_CPUS
then also isn't a suitable sentinel.

Also, style nit: The parentheses aren't really needed around the conditional.
But what's definitely wrong are the blanks immediately inside them.

> +    write_lock_irqsave(&vimsic_state->vsfile_lock, flags);
> +    vimsic_state->guest_file_id = guest_file_id;
> +    vimsic_state->vsfile_pcpu = pcpu;

By implication from the remark above, the field name stored into then also
is misnamed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 15:49:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 15:49:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384954.1627646 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws0LY-0004t2-Vq; Thu, 06 Aug 2026 15:49:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384954.1627646; Thu, 06 Aug 2026 15:49:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws0LY-0004ss-TF; Thu, 06 Aug 2026 15:49:28 +0000
Received: by outflank-mailman (input) for mailman id 1384954;
 Thu, 06 Aug 2026 15:49:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1ws0LX-0004sV-Pv
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:49:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1ws0LX-00834N-1a;
 Thu, 06 Aug 2026 15:49:27 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1ws0LW-009qdZ-2z;
 Thu, 06 Aug 2026 15:49:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=4D0z06vjOYg9blHCRUsB77y4tATWODBBrawlmczEE3k=; b=1FpGpzkxrMGxAJSJ6Ab7WQRMjd
	SFsrpewCbERnt7CjwpKqp4f2Wq8cXbDeMLDvxEUV+HGSVDzrhWRsgoUe1Eg+wqrLYzdWaTWwBnSHj
	YHYBpLyrI5rf8h38BaHm7Fu3MORoI+ikSlF0XUrKdCsNYDTXB8lfSyDfetTtrFTy8HWo=;
From: Roger Pau Monne <roger@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger@xenproject.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v2 1/2] x86/pci: prevent cross-device accesses in pci_mmcfg_{read,write}()
Date: Thu,  6 Aug 2026 17:26:18 +0200
Message-ID: <20260806152619.23881-2-roger@xenproject.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260806152619.23881-1-roger@xenproject.org>
References: <20260806152619.23881-1-roger@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Introduce a specific check that prevents an accesses from spilling across
two devices.

Signed-off-by: Roger Pau Monné <roger@xenproject.org>
---
Changes since v1:
 - New in this version.
---
 xen/arch/x86/x86_64/mmconfig_64.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_64/mmconfig_64.c b/xen/arch/x86/x86_64/mmconfig_64.c
index 940cf6d7471b..91b1a398e646 100644
--- a/xen/arch/x86/x86_64/mmconfig_64.c
+++ b/xen/arch/x86/x86_64/mmconfig_64.c
@@ -61,7 +61,8 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
     char __iomem *addr;
 
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
-    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
+    if (unlikely((bus > 255) || (devfn > 255) ||
+                 (reg + len > PCI_CFG_SPACE_EXP_SIZE))) {
 err:        *value = -1;
         return -EINVAL;
     }
@@ -91,7 +92,8 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
     char __iomem *addr;
 
     /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
-    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
+    if (unlikely((bus > 255) || (devfn > 255) ||
+                 (reg + len > PCI_CFG_SPACE_EXP_SIZE)))
         return -EINVAL;
 
     addr = pci_dev_base(seg, bus, devfn);
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 15:49:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 15:49:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384955.1627656 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws0Le-000588-98; Thu, 06 Aug 2026 15:49:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384955.1627656; Thu, 06 Aug 2026 15:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws0Le-000580-4X; Thu, 06 Aug 2026 15:49:34 +0000
Received: by outflank-mailman (input) for mailman id 1384955;
 Thu, 06 Aug 2026 15:49:32 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1ws0Lc-000579-S3
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:49:32 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1ws0Lc-00834V-28;
 Thu, 06 Aug 2026 15:49:32 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1ws0Lc-009r6I-0L;
 Thu, 06 Aug 2026 15:49:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=v8h1wppUhC/u/nkKEBQJ22KAaFfqUX8DZenk5l0qwSs=; b=E3djs5jXPwiXuhHLhTg9/Zkj/V
	BUEnWf+1Uz1xhEse4IKMmlZxHISKW5NFHqUzbijq8DDScnvR9y0sEWsKLv8kojb/QLURb9HkRHnSy
	rnEfu87ivdlfZDUnuXA9O+B1qTT17bpzIEnCU0sJrQuMFPphb0CdfikQg+O24mSr+w2s=;
From: Roger Pau Monne <roger@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger@xenproject.org>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Stewart Hildebrand <stewart.hildebrand@amd.com>,
	Jason Andryuk <jason.andryuk@amd.com>
Subject: [PATCH v2 2/2] xen/vpci: allow unaligned accesses by the hardware domain
Date: Thu,  6 Aug 2026 17:26:19 +0200
Message-ID: <20260806152619.23881-3-roger@xenproject.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260806152619.23881-1-roger@xenproject.org>
References: <20260806152619.23881-1-roger@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It's possible for domains to generate unaligned PCI config space accesses
when using ECAM, and hence vPCI should support those at least for the
hardware domain.  Such unaligned accesses to the PCI config space have been
reported to come from ACPI logic.

Relax the checking in vpci_access_allowed() to allow such accesses for the
hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
fulfill them using MMCFG.

MMCFG regions are identity exposed to the hardware domain, and hence such
unaligned accesses can only come as a result of the host having MMCFG in the
first place, as otherwise MMCFG won't be exposed to the hardware domain
either.

Note that vpci_ecam_{read,write}() already refuse accesses that cross a
device boundary unconditionally.

Reported-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Roger Pau Monné <roger@xenproject.org>
---
 tools/include/xen-tools/common-macros.h | 2 ++
 xen/arch/x86/x86_64/pci.c               | 8 ++++----
 xen/drivers/vpci/vpci.c                 | 6 ++++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/include/xen-tools/common-macros.h b/tools/include/xen-tools/common-macros.h
index 88b4a0e5a693..1f9146b23b0e 100644
--- a/tools/include/xen-tools/common-macros.h
+++ b/tools/include/xen-tools/common-macros.h
@@ -68,6 +68,8 @@
     })
 #endif
 
+#define IS_ALIGNED(val, align) (!((val) & ((align) - 1)))
+
 #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
 #define ROUNDDOWN(x, a) ((x) & ~((a) - 1))
 
diff --git a/xen/arch/x86/x86_64/pci.c b/xen/arch/x86/x86_64/pci.c
index 8d33429103b9..6298141c3ca7 100644
--- a/xen/arch/x86/x86_64/pci.c
+++ b/xen/arch/x86/x86_64/pci.c
@@ -26,7 +26,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg)
 
 uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
     {
         uint32_t value;
 
@@ -39,7 +39,7 @@ uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg)
 
 uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 4) )
     {
         uint32_t value;
 
@@ -60,7 +60,7 @@ void pci_conf_write8(pci_sbdf_t sbdf, unsigned int reg, uint8_t data)
 
 void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) )
         pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, data);
     else
         pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), reg & 2, 2, data);
@@ -68,7 +68,7 @@ void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data)
 
 void pci_conf_write32(pci_sbdf_t sbdf, unsigned int reg, uint32_t data)
 {
-    if ( sbdf.seg || reg > 255 )
+    if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 4) )
         pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, data);
     else
         pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), 0, 4, data);
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 0ac9ec8b0475..9e2c27e3a300 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -685,6 +685,8 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
 /* Helper function to check an access size and alignment on vpci space. */
 bool vpci_access_allowed(unsigned int reg, unsigned int len)
 {
+    const struct domain *currd = current->domain;
+
     /* Check access size. */
     if ( len != 1 && len != 2 && len != 4 && len != 8 )
         return false;
@@ -695,8 +697,8 @@ bool vpci_access_allowed(unsigned int reg, unsigned int len)
         return false;
 #endif
 
-    /* Check that access is size aligned. */
-    if ( (reg & (len - 1)) )
+    /* Refuse unaligned accesses for non-hardware domains. */
+    if ( !is_hardware_domain(currd) && !IS_ALIGNED(reg, len) )
         return false;
 
     return true;
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 15:49:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 15:49:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1384953.1627637 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws0LU-0004ei-PJ; Thu, 06 Aug 2026 15:49:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1384953.1627637; Thu, 06 Aug 2026 15:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws0LU-0004eb-Mm; Thu, 06 Aug 2026 15:49:24 +0000
Received: by outflank-mailman (input) for mailman id 1384953;
 Thu, 06 Aug 2026 15:49:23 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1ws0LT-0004eV-8A
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 15:49:23 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1ws0LS-00834C-17;
 Thu, 06 Aug 2026 15:49:22 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1ws0LR-009pwT-2L;
 Thu, 06 Aug 2026 15:49:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:Message-ID:Date:Subject:Cc:To:From;
	bh=o3yaR1bb4+BXLENjHX+LaY79Q3ebPt+U4+8LUNnuhlg=; b=U+WUsv/klw2chglEXJrFunuuZj
	jjfotCwxIuFrB1FafeC9rma3Pf2/BhyJY/fK5so3EzomddTISydRL2Bn04NuoaovFK2R6XTLPE9F8
	ZmMftCC1raQ4/fYGX4SBmBWWYO89O5rrsV2IoX/xeMFI1aXkVGCp9y+miPNqLFEuu/eY=;
From: Roger Pau Monne <roger@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger@xenproject.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Stewart Hildebrand <stewart.hildebrand@amd.com>
Subject: [PATCH v2 0/2] vpci: allow unaligned accesses by the hardware domain
Date: Thu,  6 Aug 2026 17:26:17 +0200
Message-ID: <20260806152619.23881-1-roger@xenproject.org>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Mostly the same as v1, plus an additional patch that refuses accesses
that cross a device boundary in pci_mmcfg_{read,write}() itself.

Thanks, Roger.

Roger Pau Monne (2):
  x86/pci: prevent cross-device accesses in pci_mmcfg_{read,write}()
  xen/vpci: allow unaligned accesses by the hardware domain

 tools/include/xen-tools/common-macros.h | 2 ++
 xen/arch/x86/x86_64/mmconfig_64.c       | 6 ++++--
 xen/arch/x86/x86_64/pci.c               | 8 ++++----
 xen/drivers/vpci/vpci.c                 | 6 ++++--
 4 files changed, 14 insertions(+), 8 deletions(-)

-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 17:27:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 17:27:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385047.1627665 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws1rn-0002g5-21; Thu, 06 Aug 2026 17:26:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385047.1627665; Thu, 06 Aug 2026 17:26:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws1rm-0002fy-Vf; Thu, 06 Aug 2026 17:26:50 +0000
Received: by outflank-mailman (input) for mailman id 1385047;
 Thu, 06 Aug 2026 17:26:49 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1ws1rl-0002fs-Cc
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 17:26:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws1rk-00Dhsu-Lm
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 19:26:48 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a74c3ba-e002-0a2a0a5209dd-0a2a4502ca6a-18
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 19:26:48 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a74c3d7-6ca4-0a2a45020019-a06583088ea4-3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 19:26:48 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id A6381444E917;
 Thu,  6 Aug 2026 13:25:08 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Subject: [PATCH v3] x86/nSVM: Check injected event consistency
Date: Thu,  6 Aug 2026 18:23:32 +0100
Message-ID: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1786037208-317CA2AC-6869F7CD/0/0
X-purgate-type: clean
X-purgate-size: 6067

On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has
debugging complications, security and performance implications. The APM
volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that
result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are
• Reserved values of TYPE have been specified.
• TYPE = 3 (exception) has been specified with a vector that does not
  correspond to an exception (this includes vector 2, which is an NMI, not
  an exception).

Extend the VMCB validation to check for such inconsistency.

The collection of the invalid exception vectors are ported from the upstream
KVM commit
("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust
the checks from the commit to align with the APM Volume #2 and Volume #3
(40332—Rev. 4.40—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which
should not be valid on the x86 64-bit (long mode) platforms. The adjustment is
posted to the KVM mailing commit patch thread
https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Changes in v3:
- Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to 
  non-64-bit guests to prevent impossible guest-mode state injections
  per AMD APM Volumes 2 & 3.
- Refactored exception vector validation from if-conditions to a switch
  statement to improve readability and extensibility.
- Restricted X86_EXC_CP (21) vector injection to hosts with enabled CET
  to prevent VMRUN failures on hardware without CET support.

Changes in v2:
- Remove the redundant SVM_EVENT_INJ_TYPE_MASK and SVM_EVENT_INJ_VEC_MASK
  constants.
- Correct the Injected Event Type consistency check to disallow the injection
  of reserved type 1 events.
---
Testing:
 - Using a locally developed XTF nested virt setup, I manually tested VMRUN
   instruction handling with a malformed VMCB:
   1) Inject event with the type (7).
      The hypervisor logs show the message
      (XEN) [  645.155609] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid
            Injected Event Type: (0x7)
   2) Inject event with the exception value (3) and the vector value (2) for 
      NMI. The hypervisor logs show the message
      (XEN) [  645.157277] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid
            Injected Event. Exception type: (0x3), with a vector: (0x2) does
            not belong to an exception on the platform.
   3) Inject event with the exception value (3) and the vector value (21) for
      the X86_EXC_CP (Control-Flow Protection).
      Without the changes included:
          On the Naples host, where the vector was not yet known to the
          hardware. VMRUN immediately triggers VMEXIT_INVALID.
          On the Genoa host, VMRUN immediately triggers VMEXIT_VMMCALL.
      With the changes included:
          On the Naples host and the Genoa host, VMEXIT_INVALID is reported back
          without VMRUN execution.

 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2734283788
---
 xen/arch/x86/hvm/svm/vmcb.c | 51 +++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 975a1eaef8..4379bbef09 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -320,6 +320,41 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
     svm_dump_sel("  TR", &vmcb->tr);
 }
 
+static bool is_valid_svm_vmcb_injected_exception_vector(
+    const struct vmcb_struct *vmcb, uint8_t vmcb_injected_vector)
+{
+    switch ( vmcb_injected_vector )
+    {
+    case X86_EXC_DE:
+    case X86_EXC_DB:
+    case X86_EXC_BP:
+    case X86_EXC_UD:
+    case X86_EXC_NM:
+    case X86_EXC_DF:
+    case X86_EXC_TS:
+    case X86_EXC_NP:
+    case X86_EXC_SS:
+    case X86_EXC_GP:
+    case X86_EXC_PF:
+    case X86_EXC_MF:
+    case X86_EXC_AC:
+    case X86_EXC_MC:
+    case X86_EXC_XM:
+    case X86_EXC_HV:
+    case X86_EXC_SX:
+        return true;
+    case X86_EXC_OF:
+    case X86_EXC_BR:
+        return !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l);
+    case X86_EXC_VC:
+        return vmcb_get_sev_es(vmcb);
+    case X86_EXC_CP:
+        return !!(vmcb_get_cr4(vmcb) & X86_CR4_CET);
+    default:
+        return false;
+    }
+}
+
 bool svm_vmcb_isvalid(
     const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v,
     bool verbose)
@@ -330,6 +365,12 @@ bool svm_vmcb_isvalid(
     unsigned long cr4 = vmcb_get_cr4(vmcb);
     unsigned long valid;
     uint64_t efer = vmcb_get_efer(vmcb);
+    uint8_t vmcb_injected_type = vmcb->event_inj.type;
+    uint8_t vmcb_injected_vector = vmcb->event_inj.vector;
+    uint8_t vmcb_valid_event_inj_types_mask = (1 << X86_ET_EXT_INTR) |
+                                              (1 << X86_ET_NMI) |
+                                              (1 << X86_ET_HW_EXC) |
+                                              (1 << X86_ET_SW_INT);
 
 #define PRINTF(fmt, args...) do { \
     if ( !verbose ) return true; \
@@ -392,6 +433,16 @@ bool svm_vmcb_isvalid(
         PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
                vmcb->event_inj.raw);
 
+    if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) )
+        PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n",
+               vmcb_injected_type);
+
+    if ( (vmcb_injected_type == X86_ET_HW_EXC) &&
+         !is_valid_svm_vmcb_injected_exception_vector(
+             vmcb, vmcb_injected_vector) )
+        PRINTF("eventinj: Invalid Injected Event. Exception type: (%#"PRIx8"),"
+               " with a vector: (%#"PRIx8") does not belong to an exception on"
+               " the platform \n", vmcb_injected_type, vmcb_injected_vector);
 #undef PRINTF
     return ret;
 }
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 22:18:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 22:18:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385234.1627674 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws6Pi-0006qM-I3; Thu, 06 Aug 2026 22:18:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385234.1627674; Thu, 06 Aug 2026 22:18:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws6Pi-0006qE-Er; Thu, 06 Aug 2026 22:18:10 +0000
Received: by outflank-mailman (input) for mailman id 1385234;
 Thu, 06 Aug 2026 22:18:08 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3HQh1agYKCVwM84HD6AIIAF8.6IGR8H-78P8FFCMNM.R8HJLID86N.ILA@flex--seanjc.bounces.google.com>)
 id 1ws6Pg-0006q7-QR
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 22:18:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws6Pg-00Bhhc-79
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 00:18:08 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3HQh1agYKCVwM84HD6AIIAF8.6IGR8H-78P8FFCMNM.R8HJLID86N.ILA@flex--seanjc.bounces.google.com>)
 id 6a7507d5-e002-0a2a0a5209dd-0a2a450181b4-42
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 00:18:08 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3HQh1agYKCVwM84HD6AIIAF8.6IGR8H-78P8FFCMNM.R8HJLID86N.ILA@flex--seanjc.bounces.google.com>)
 id 6a75081e-5984-0a2a45010019-d155d2c5c0cd-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 00:18:07 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84eccf9d899so3597352b3a.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 15:18:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786054686; x=1786659486; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=/BEVvi4/7i6XDSu/QYDIwcuZoEPs9pbAb29S0DeOBes=;
        b=MyQHE4rFqyN3m4oFV5xa7RNhfCtFhVjlKYGIK0a6ZRDBcuC2ZO0BIsmG0Wloe8j4st
         ejAUwT6Y5q/EoIbebz/BZ4gjgBhQAzR6EuyWkuN9Tazjzo2uANonA30vIU0BNZoY4OzT
         9h3ohjJMbN9xkIgJOUrN3NfKP+HRBFAtmkel30D9O0wFRVKjjdsrq7b4uAjYvT6fKmJm
         M/116vDGMLT7gzo89YXWdn93m0oshXZe5onSQJjnlhCW2JLGK5FKSTn5ZxhC+CSU4s1u
         nxlYe5GyRwVXUb18JFd5srq+QUIXCtoArfBLw3M4+XuUYWYW1dwH4r71fuafxTNR0m5o
         M43Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786054686; x=1786659486;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=/BEVvi4/7i6XDSu/QYDIwcuZoEPs9pbAb29S0DeOBes=;
        b=sejdI5255W3AWBybJU0QBV9Ucv1hcANohmmto+YT7s5P4dVfjRb5F5yG5wW5jBZeIZ
         tExJVbO5/akNw/mJrPByzAgIbsA08VpEfx+DNm4ghbGE2RBLgnO6QcgxoxVmJgY83jIE
         yxKHnzJqW1hZr567yQqTmsZ3sPJlTsNYaizrs3j7XD0StFgAlGS32B41HOEQJ8sj6xbT
         3TnC3yLgc0NYpgM1uNZbVuFC89xJQdSjPqFdzDeK5lEJda/O68Fi6AaGRJpoTHkH1/Gw
         +2PwoulwVgPeXdtDAB2ARnHdgeYXcJVAqy6eKyiCrP+js9P1gg71rxblnbQYPUKFUCIt
         c9ng==
X-Forwarded-Encrypted: i=1; AHgh+RrFnw5PHqidxRYUsrHDoF5OcfDQVW6SqieHSjuS7oLcSX0ZY3UocY6YR+40UeHUs36NWNPkZ7CniqY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3TuYDJIzb/xjyVmnIkJqGRrAjgqdoJumMgVabgI+FoaQ7TiYl
	roT6YyB8Kv8c5tRYY46bBl/30qJoEU6jkIbKXUY0ZUYU8bYPxj2Me0H3OHztTs2wj2SkPVWoDSP
	Vvv03ww==
X-Received: from pfbln15.prod.google.com ([2002:a05:6a00:3ccf:b0:848:5415:1869])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3a0f:b0:848:3f07:c5a2
 with SMTP id d2e1a72fcca58-84f2dfd0a06mr18297213b3a.4.1786054685697; Thu, 06
 Aug 2026 15:18:05 -0700 (PDT)
Date: Thu, 6 Aug 2026 15:18:05 -0700
In-Reply-To: <SN6PR02MB4157453D405AB80859B12DF9D4F52@SN6PR02MB4157.namprd02.prod.outlook.com>
Mime-Version: 1.0
References: <20260701193212.749551-1-seanjc@google.com> <20260701193212.749551-48-seanjc@google.com>
 <SN6PR02MB4157453D405AB80859B12DF9D4F52@SN6PR02MB4157.namprd02.prod.outlook.com>
Message-ID: <anUIHY-1_q3oVFPf@google.com>
Subject: Re: [PATCH v5 47/51] x86/paravirt: Don't use a PV sched_clock in CoCo
 guests with trusted TSC
From: Sean Christopherson <seanjc@google.com>
To: Michael Kelley <mhklinux@outlook.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Paolo Bonzini <pbonzini@redhat.com>, 
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, 
	Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Andy Lutomirski <luto@kernel.org>, 
	Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, John Stultz <jstultz@google.com>, 
	Shuah Khan <skhan@linuxfoundation.org>, "H. Peter Anvin" <hpa@zytor.com>, 
	Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>, 
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>, 
	"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Tom Lendacky <thomas.lendacky@amd.com>, 
	Nikunj A Dadhania <nikunj@amd.com>, David Woodhouse <dwmw@amazon.co.uk>, 
	David Woodhouse <dwmw2@infradead.org>, Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-d62444/1786054688-C5146757-6D791EC4/0/0
X-purgate-type: clean
X-purgate-size: 2223

On Thu, Jul 02, 2026, Michael Kelley wrote:
> From: Sean Christopherson <seanjc@google.com> Sent: Wednesday, July 1, 2026 12:32 PM
> > 
> > Silently ignore attempts to switch to a paravirt sched_clock when running
> > as a CoCo guest with trusted TSC.  In hand-wavy theory, a misbehaving
> > hypervisor could attack the guest by manipulating the PV clock to affect
> > guest scheduling in some weird and/or predictable way.  More importantly,
> > reading TSC on such platforms is faster than any PV clock, and sched_clock
> > is all about speed.
> > 
> > Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kernel/tsc.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> > index 012321fed5e5..a146fc7b5e74 100644
> > --- a/arch/x86/kernel/tsc.c
> > +++ b/arch/x86/kernel/tsc.c
> > @@ -283,6 +283,15 @@ bool using_native_sched_clock(void)
> >  int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
> >  				      void (*save)(void), void (*restore)(void))
> >  {
> > +	/*
> > +	 * Don't replace TSC with a PV clock when running as a CoCo guest and
> > +	 * the TSC is secure/trusted; PV clocks are emulated by the hypervisor,
> > +	 * which isn't in the guest's TCB.
> > +	 */
> > +	if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC) ||
> > +	    boot_cpu_has(X86_FEATURE_TDX_GUEST))
> > +		return -EPERM;
> 
> Do a pr_warn() in the error case? Your commit message says to do the ignore
> silently, but I wonder if that's a good idea. At least for Hyper-V, the error
> case shouldn't happen.

I agree it's not a great idea, but unfortunately it's pretty much guaranteed to
fire on KVM-based setups.  The KVM world hasn't been anywhere near as aggressive
as Hyper-V in terms of killing off PV features when running SNP/TDX guests (which
is largely how this series came to be in the first place).

So while I'm conceptually not opposed to the idea of printing an error message,
in practice I'm pretty strong against it because odds are very good I'll end up
dealing with "bug" reports due to less-than-awesome setups.


From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385269.1627715 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dY-0007Em-49; Thu, 06 Aug 2026 23:36:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385269.1627715; Thu, 06 Aug 2026 23:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dX-0007E0-TO; Thu, 06 Aug 2026 23:36:31 +0000
Received: by outflank-mailman (input) for mailman id 1385269;
 Thu, 06 Aug 2026 23:36:31 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3fBp1agYKCd8TFBOKDHPPHMF.DPNYFO-EFWFMMJTUT.YFOQSPKFDU.PSH@flex--seanjc.bounces.google.com>)
 id 1ws7dX-000791-D8
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dW-00GcaU-QT
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:30 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3fBp1agYKCd8TFBOKDHPPHMF.DPNYFO-EFWFMMJTUT.YFOQSPKFDU.PSH@flex--seanjc.bounces.google.com>)
 id 6a751a49-bab6-0a2a0a5309dd-0a2a4501d568-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:30 +0200
Received: from [209.85.214.200] (helo=mail-pl1-f200.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3fBp1agYKCd8TFBOKDHPPHMF.DPNYFO-EFWFMMJTUT.YFOQSPKFDU.PSH@flex--seanjc.bounces.google.com>)
 id 6a751a7d-5984-0a2a45010019-d155d6c8f1f5-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:30 +0200
Received: by mail-pl1-f200.google.com with SMTP id
 d9443c01a7336-2cfc52ddc55so34439545ad.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059389; x=1786664189; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=Bl6f0kmYO+QvCHyY9ZYfUQzYrQcYJLjL3x7Z6ExdFrE=;
        b=Z+aQxQiE+OE1I3dn5dzeeW95DU07hYNTCDlCxjhYO+Aq6aPRS2RNr/2klJwuC+E4/x
         ftWoVyu/tz0Lb5p5trYqxrefnuqxmAPLuys0tsQNmUc8O9TEM4uQ2kqDWdXTJjIGpWeZ
         in5zUOHqVdgEBr56INMLsc79On8vJWHIGiI1yBfh+D/5A729uwtac9xfMdhtJsFofvys
         kjWroSa9NWPmsvak+Mm+bnXpbGt3Iq2j4PQwu0nA21rYUDWMV2zyw+B+mcCjgIVahJl9
         tKVwvrZARasr9fVInvqmhj3+0e1/EZEJ3T/aczJDP4zCxVK2fvk7e/zgWMdGcEbOqP4d
         +R1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059389; x=1786664189;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=Bl6f0kmYO+QvCHyY9ZYfUQzYrQcYJLjL3x7Z6ExdFrE=;
        b=rrfebHGB4boAlvbqG3TrCdJj6XBNdiWhphIGVZwILC02WTPUNts2T6ARI/n4i62AdH
         wLlwjXhN3oyhDPdSBeTkfLDrrXunRj07HjHvMIBpOSfB1vJI9BKEtWdZs8CPKJL/2rRR
         VzaKY3KVjL/FO8hpWctDoVZBx+vHPcbtpgjMOh2MxYukUPd1WjWu+DCaruZ+IFmE9Ugt
         5DVhtuTxdPUixHADkQXQP5p7C3MfJMQNJEafpCepR97MCvapIQa6DFtDtXnFvkGsonQz
         XMSe/7aL6TeW3h/1quRu2sFC2qZ3a+X4iDw8GdqdkgLu1JN4tLkBsP7gqczxfmzO+01F
         1ZRg==
X-Forwarded-Encrypted: i=1; AHgh+RrtFcl/L/ifj9/+w2Wdu35WGtEEKCvO69d6wRHt52dGO1j9cZERVjZFE4zMJSCgK+I+t32JZtw3Hrg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzoK51m8zmU8itLWqjEfP5u7DJdKiwdt2Ze543xRr6TO7SUlETY
	lzJPsKh4v2ruDxIpUKyBsfeMHjlc2FM953+P3THHKbnk+CGLWQFf/2QGpyKSJOgOy3sCU0EnoX5
	z80ihaA==
X-Received: from pgav2.prod.google.com ([2002:a05:6a02:2dc2:b0:c85:9dd2:d11e])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7349:b0:3c6:3c5b:f2e1
 with SMTP id adf61e73a8af0-3cbadcfcacfmr5222309637.32.1786059388428; Thu, 06
 Aug 2026 16:36:28 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:21 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-5-seanjc@google.com>
Subject: [PATCH v6 04/51] x86/tsc: Restrict recalibrate_cpu_khz() export to
 p4-clockmod and powernow-k7
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786059390-BCB45757-AB75D175/0/0
X-purgate-type: clean
X-purgate-size: 833

Export recalibrate_cpu_khz() only for its two users, p4-clockmod.ko and
powernow-k7.ko, to help document that recalibration is relevant only to
ancient CPUs.

For all intents and purposes, no functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index bc4348585194..09bf10f322ba 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -943,7 +943,7 @@ void recalibrate_cpu_khz(void)
 						    cpu_khz_old, cpu_khz);
 #endif
 }
-EXPORT_SYMBOL_GPL(recalibrate_cpu_khz);
+EXPORT_SYMBOL_FOR_MODULES(recalibrate_cpu_khz, "p4-clockmod,powernow-k7");
 
 
 static unsigned long long cyc2ns_suspend;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385266.1627688 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dV-0006cw-8c; Thu, 06 Aug 2026 23:36:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385266.1627688; Thu, 06 Aug 2026 23:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dV-0006cj-42; Thu, 06 Aug 2026 23:36:29 +0000
Received: by outflank-mailman (input) for mailman id 1385266;
 Thu, 06 Aug 2026 23:36:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3eBp1agYKCdsPB7KG9DLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--seanjc.bounces.google.com>)
 id 1ws7dU-0006a3-4O
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dT-00BpFw-Hd
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:27 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3eBp1agYKCdsPB7KG9DLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--seanjc.bounces.google.com>)
 id 6a751a44-2eae-0a2a0a5409dd-0a2a45069178-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:27 +0200
Received: from [209.85.214.199] (helo=mail-pl1-f199.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3eBp1agYKCdsPB7KG9DLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--seanjc.bounces.google.com>)
 id 6a751a79-195a-0a2a45060019-d155d6c7c0f2-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:27 +0200
Received: by mail-pl1-f199.google.com with SMTP id
 d9443c01a7336-2ce8a76df2dso47495605ad.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059385; x=1786664185; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=VnGiMJAeWdyvdLpQdGy9NuKyd6BkLuzFrwi8wF2quVo=;
        b=d+kiInm2fADfglJT76haTsw7CHKZ07SSlfYuJorup/spRNvkTY9+7JQteJU8USu07z
         6eSMkWGRG+aiz56Kc9Ha/crhehSxXv3+vsPcbXYyt5R1qGCbYDhBKiCm6hZFx4GBAsPr
         ijTSulVZ0wddVnHDbiyIZq64dIfriYX4xRuYX5J2M4b+GIHM70YJAMDYTqg85XwjEacI
         1ZP3pkm2sXGUS4ws1fvA9sLlvNmVaGiF9ejmthB4btiobAnbFGFBl6pN2YooYKoik2v4
         KeYrzxS6avNoYx4g0PUaI9KJQQsslE+cyil1an85ANPTS+iQHcPid/qxFMz2CrTiQKDE
         If0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059385; x=1786664185;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=VnGiMJAeWdyvdLpQdGy9NuKyd6BkLuzFrwi8wF2quVo=;
        b=kTXKFnutqIdMf597YTHTM9S+SU6v4DoHat1Fkms8lj8bnac+mCWDiUkSvlNtTGEQlu
         RFVloznxVka9uSJpsoSmba5+lRFIBEN4Ld+KtjJdfb+TIQDgWK6OGjMSlm8YARq8DUe/
         f2J+gylE07u42sJgTM4i9aWMe1yeKL6xAos3sKrlxzCvwPQ+DABqqlkf25iGw9zD9Nzo
         qbmYVoPhaSiTRjrMum7KIdDD+LgbqjFmyhfn4YNUqW9N1l1FwXX0a8QGRBpEWtA1Dsc8
         IRMUVmZFYdS7lhBNHITPCieibWbXG/oT3wqzBvI2XfNzdYKhGfMHtWFuQHnyrz3Oh8vO
         JZAA==
X-Forwarded-Encrypted: i=1; AHgh+RrArYAKB3SyFv9KZ/8D+XVk8At5Rs2Jmw9b9W/clwIfbULicIoXHMDrXiFmPQiFFv3s85StiAdCgHI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjlmpxxqhyFHPK7vn0aeRXThlmLMk5kfo8JxsFEkXHDVED4gOM
	/efZwP88fLXQTRmETKAvNA7CoJeqXn8VTtW3JWfrnbeQjhqlgZpXgYD7mMGLbtvAiMcCBIbwoR+
	6l+zw1Q==
X-Received: from plzw6.prod.google.com ([2002:a17:902:9046:b0:2cc:6ddb:debc])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:dac1:b0:2c0:e5ee:f554
 with SMTP id d9443c01a7336-2d0ca71b3d7mr204312595ad.8.1786059384888; Thu, 06
 Aug 2026 16:36:24 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:18 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-2-seanjc@google.com>
Subject: [PATCH v6 01/51] x86/apic: Provide helpers to set local APIC timer
 frequency in hz and khz
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-16d1c6/1786059387-FD20877B-5EBF9333/0/0
X-purgate-type: clean
X-purgate-size: 6199

Add and use APIs to set the local APIC timer period (given a frequency)
instead of open coding the subtle HZ math in all external callers, and
make lapic_timer_period local to apic.c.  Provide APIs to specify the
frequency in both hertz and kilohertz so that Hyper-V and VMware code
aren't forced to lose precision.

Opportunistically take the frequency as a u64 to harden against the
possibility that the frequency (in Khz) is greater than 4294967, i.e. if
the APIC timer runs at ~4.29 GHz.  As pointed out by Sashiko,
4294968 * 1000 == 0x1_000002c0, and thus a Khz period of 4294968 would
silently overflow the 32-bit unsigned integer used by most callers.

Print out who set the period to maintain equivalent Hyper-V and VMware
functionality, and in general to make it easier to triage/debug issues.

Cc: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/apic.h    |  3 ++-
 arch/x86/kernel/apic/apic.c    | 19 ++++++++++++++++++-
 arch/x86/kernel/cpu/mshyperv.c |  5 +----
 arch/x86/kernel/cpu/vmware.c   |  4 +---
 arch/x86/kernel/jailhouse.c    |  2 +-
 arch/x86/kernel/tsc.c          |  2 +-
 arch/x86/kernel/tsc_msr.c      |  2 +-
 7 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 9cd493d467d4..6946220a6008 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -63,7 +63,6 @@ extern int apic_verbosity;
 extern int local_apic_timer_c2_ok;
 
 extern bool apic_is_disabled;
-extern unsigned int lapic_timer_period;
 
 extern enum apic_intr_mode_id apic_intr_mode;
 enum apic_intr_mode_id {
@@ -138,6 +137,8 @@ void register_lapic_address(unsigned long address);
 extern void setup_boot_APIC_clock(void);
 extern void setup_secondary_APIC_clock(void);
 extern void lapic_update_tsc_freq(void);
+extern void apic_set_timer_frequency_hz(u64 freq_hz, const char *source);
+extern void apic_set_timer_frequency_khz(u64 freq_khz, const char *source);
 
 #ifdef CONFIG_X86_64
 static inline bool apic_force_enable(unsigned long addr)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 90025451ace2..9239dca91c41 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -37,6 +37,7 @@
 #include <linux/smp.h>
 #include <linux/mm.h>
 #include <linux/kvm_types.h>
+#include <linux/units.h>
 
 #include <xen/xen.h>
 
@@ -176,7 +177,7 @@ static struct resource lapic_resource = {
 };
 
 /* Measured in ticks per HZ. */
-unsigned int lapic_timer_period = 0;
+static unsigned int lapic_timer_period;
 
 static void apic_pm_activate(void);
 
@@ -796,6 +797,22 @@ bool __init apic_needs_pit(void)
 	return lapic_timer_period == 0;
 }
 
+void apic_set_timer_frequency_hz(u64 freq_hz, const char *source)
+{
+	u32 f_remainder;
+	u64 f_khz = div_u64_rem(freq_hz, HZ_PER_KHZ, &f_remainder);
+
+	lapic_timer_period = div_u64(freq_hz, HZ);
+
+	pr_info("Local APIC Timer Frequency set to %llu.%03u KHz (from '%s').\n",
+		f_khz, f_remainder, source);
+}
+
+void apic_set_timer_frequency_khz(u64 freq_khz, const char *source)
+{
+	apic_set_timer_frequency_hz(freq_khz * HZ_PER_KHZ, source);
+}
+
 static int __init calibrate_APIC_clock(void)
 {
 	struct clock_event_device *levt = this_cpu_ptr(&lapic_events);
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 185d4f677ec0..cadc7f872b4f 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -646,10 +646,7 @@ static void __init ms_hyperv_init_platform(void)
 		u64	hv_lapic_frequency;
 
 		rdmsrq(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
-		hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
-		lapic_timer_period = hv_lapic_frequency;
-		pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
-			lapic_timer_period);
+		apic_set_timer_frequency_hz(hv_lapic_frequency, "Hyper-V hypervisor");
 	}
 
 	register_nmi_handler(NMI_UNKNOWN, hv_nmi_unknown, NMI_FLAG_FIRST,
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 34b73573b108..22842bf5b59e 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -424,9 +424,7 @@ static void __init vmware_platform_setup(void)
 
 #ifdef CONFIG_X86_LOCAL_APIC
 		/* Skip lapic calibration since we know the bus frequency. */
-		lapic_timer_period = ecx / HZ;
-		pr_info("Host bus clock speed read from hypervisor : %u Hz\n",
-			ecx);
+		apic_set_timer_frequency_hz(ecx, "VMware hypervisor");
 #endif
 	} else {
 		pr_warn("Failed to get TSC freq from the hypervisor\n");
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index f58ce9220e0f..615a1f25c83a 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -65,7 +65,7 @@ static void jailhouse_get_wallclock(struct timespec64 *now)
 
 static void __init jailhouse_timer_init(void)
 {
-	lapic_timer_period = setup_data.v1.apic_khz * (1000 / HZ);
+	apic_set_timer_frequency_khz(setup_data.v1.apic_khz, "Jailhouse hypervisor");
 }
 
 static unsigned long jailhouse_get_tsc(void)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 723347e2cf7f..63e26805f8dd 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -717,7 +717,7 @@ unsigned long native_calibrate_tsc(void)
 	 * lapic_timer_period here to avoid having to calibrate the APIC
 	 * timer later.
 	 */
-	lapic_timer_period = crystal_khz * 1000 / HZ;
+	apic_set_timer_frequency_khz(crystal_khz, "CPUID 0x15/0x16");
 #endif
 
 	return crystal_khz * ebx_numerator / eax_denominator;
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index d74743c8d2a4..4bd5f2ae656b 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -212,7 +212,7 @@ unsigned long cpu_khz_from_msr(void)
 		pr_err("Error MSR_FSB_FREQ index %d is unknown\n", index);
 
 #ifdef CONFIG_X86_LOCAL_APIC
-	lapic_timer_period = (freq * 1000) / HZ;
+	apic_set_timer_frequency_khz(freq, "MSR_FSB_FREQ");
 #endif
 
 	/*
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385271.1627737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dc-0007we-M6; Thu, 06 Aug 2026 23:36:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385271.1627737; Thu, 06 Aug 2026 23:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dc-0007wT-IX; Thu, 06 Aug 2026 23:36:36 +0000
Received: by outflank-mailman (input) for mailman id 1385271;
 Thu, 06 Aug 2026 23:36:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3fxp1agYKCeIWIERNGKSSKPI.GSQbIR-HIZIPPMWXW.bIRTVSNIGX.SVK@flex--seanjc.bounces.google.com>)
 id 1ws7da-0007gB-Mn
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7da-00GcaU-3n
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:34 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3fxp1agYKCeIWIERNGKSSKPI.GSQbIR-HIZIPPMWXW.bIRTVSNIGX.SVK@flex--seanjc.bounces.google.com>)
 id 6a751a70-bab6-0a2a0a5309dd-0a2a450ae97a-10
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:34 +0200
Received: from [209.85.210.199] (helo=mail-pf1-f199.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3fxp1agYKCeIWIERNGKSSKPI.GSQbIR-HIZIPPMWXW.bIRTVSNIGX.SVK@flex--seanjc.bounces.google.com>)
 id 6a751a80-f2d2-0a2a450a0019-d155d2c7ed64-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:33 +0200
Received: by mail-pf1-f199.google.com with SMTP id
 d2e1a72fcca58-8484f26852dso3084112b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059392; x=1786664192; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=tcL8w1SVbwtFzoahyKqy3HGwkprj7A9nnDUrJsX64pM=;
        b=DgFqVJTosbcOR4sDQQ29htYcgOWEzPZte/iAOYmjWIG7mDh/jCAcfKdpEU1WPqXEfW
         uzlYtZZTbPUGuKzQ5p4DTKIvYsa/qWOJ2feqFnsGE60Vrjf++givTPJBx4vIFQ/s1++m
         15bJYnVFP0nO7WJYVShFD+vE5qvah1xnLNTNmLijiBGPSaBFPm038qagJ+BLXK/lryY+
         ZStvDzWPy1fbwiMmpqhvg/3YDasTXNbQFtcUyYZcWFPZX/ZMP9yxkemEpAxgnSLx4s+a
         4uu0a1jRF6M5SmetfaoN+QiGvUDstlrfdJ5tNHdeXC5CRiURfXZo4NqVnd4vHdvzXtg6
         YBBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059392; x=1786664192;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=tcL8w1SVbwtFzoahyKqy3HGwkprj7A9nnDUrJsX64pM=;
        b=UTTijzli51J1/FrMrWRJLvi1OtkPHxXBEBrgMeMs52Q2FXOtpZYNa8ePWVRAdh8kKv
         xWliQ485rSWlTCtehZniitUQnPnOp97KT8vGha6PPqEYW/BKnnM/gNT5WSdi5+NB8XZI
         bYMtglH/+Tu9H7/q2lg0aCQ2l+p6aDD2s9vVmvydmqkfG6wosrOvNCehJwPtvFrHMWOb
         2vJooTfLovoogWMZ9XnMeES5UMLmiyEmrLq9Mt4EKklpwJ3jGag9Xn3UBr6kg9ti63zM
         /V5aX6hQYPjNK85B49aPMPUC9PtjYIaH2PBDUYuLQnJcXPIphLRSDFq7XGmvqe6kBSvz
         wFZg==
X-Forwarded-Encrypted: i=1; AHgh+RoMuNLEXsoD8oLR7S8pbCTqXq1ZmKaDxuu4DR71chipMQq/876Ze5/HDCjuDp1SPY7vIB213mR6q4M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjKRyfwq0ZYndv3+PbQJyM5je+eDCqcFkOYLZeU3ZuvZG3L30d
	cgzOfs+iQCj3ZFrChdyHbyto3K/RnyWyeUgi5bpZL9Wo8FfGRElZIScfFS9KaIMMPc+ZHhJ/zqX
	yWheV8Q==
X-Received: from pgmc14.prod.google.com ([2002:a63:1c4e:0:b0:cbb:8a1e:efa4])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:10cd:b0:848:8445:6956
 with SMTP id d2e1a72fcca58-84f4fe9f90emr5350899b3a.18.1786059391731; Thu, 06
 Aug 2026 16:36:31 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:23 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-7-seanjc@google.com>
Subject: [PATCH v6 06/51] x86/sev: Don't override CPU frequency calibration
 for SNP's Secure TSC
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059394-53ED2CFC-FFA6726C/0/0
X-purgate-type: clean
X-purgate-size: 1503

Don't override the kernel's CPU frequency calibration routine when
registering SNP's Secure TSC calibration routine.  SNP (the architecture)
provides zero guarantees that the CPU runs at the same frequency as the
TSC.  The justification for clobbering the CPU routine was:

  Since the difference between CPU base and TSC frequency does not apply
  in this case, the same callback is being used.

but that's simply not true.  E.g. if APERF/MPERF is exposed to the VM, then
the CPU frequency absolutely does matter.

While relying on heuristics and/or the untrusted hypervisor to provide the
CPU frequency isn't ideal, it's at least not outright wrong.

Fixes: 73bbf3b0fbba ("x86/tsc: Init the TSC for Secure TSC guests")
Cc: Nikunj A Dadhania <nikunj@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/coco/sev/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index ed0ac52a765e..665de1aea0ee 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2046,7 +2046,6 @@ void __init snp_secure_tsc_init(void)
 
 	snp_tsc_freq_khz = SNP_SCALE_TSC_FREQ(tsc_freq_mhz * 1000, secrets->tsc_factor);
 
-	x86_platform.calibrate_cpu = securetsc_get_tsc_khz;
 	x86_platform.calibrate_tsc = securetsc_get_tsc_khz;
 
 	early_memunmap(mem, PAGE_SIZE);
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385270.1627728 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7db-0007hN-Ao; Thu, 06 Aug 2026 23:36:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385270.1627728; Thu, 06 Aug 2026 23:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7db-0007hC-6f; Thu, 06 Aug 2026 23:36:35 +0000
Received: by outflank-mailman (input) for mailman id 1385270;
 Thu, 06 Aug 2026 23:36:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3fhp1agYKCeEVHDQMFJRRJOH.FRPaHQ-GHYHOOLVWV.aHQSURMHFW.RUJ@flex--seanjc.bounces.google.com>)
 id 1ws7dZ-0007dT-KO
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dZ-00GcVS-1I
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:33 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3fhp1agYKCeEVHDQMFJRRJOH.FRPaHQ-GHYHOOLVWV.aHQSURMHFW.RUJ@flex--seanjc.bounces.google.com>)
 id 6a751a81-e002-0a2a0a5209dd-0a2a450c8794-0
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:33 +0200
Received: from [209.85.214.198] (helo=mail-pl1-f198.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3fhp1agYKCeEVHDQMFJRRJOH.FRPaHQ-GHYHOOLVWV.aHQSURMHFW.RUJ@flex--seanjc.bounces.google.com>)
 id 6a751a7f-f479-0a2a450c0019-d155d6c6e99d-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:32 +0200
Received: by mail-pl1-f198.google.com with SMTP id
 d9443c01a7336-2caf4173b1cso48599815ad.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059391; x=1786664191; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=JiQKL/d/a0vrWgDwSPI6P4lMZN4rNkkCCv7n67xdKiQ=;
        b=LR3ZngN0m0wafXvHznKSeHMsej0U8P7i0l+F9WvFiM2vXPABkAhlt2exRf4LiG2hC6
         xge3aKkxCuAV3HkitlFMidsda69rjtPVNJz7WLh2k87ANrpOmluGxtrWewEt/+CswuBC
         GK21YW9wMpW9KGsQ5D7aI+1TOEmmguXmhjQaWV2cBNIalMIdDTlWXovVgqYCWxyixJ3J
         lE1dqeuPFpluWyzD2rgxSj2QdU+ywu688/t6azOfRWdHWWSVOd1S4C3qYCV8t6NwgVk+
         iS9jnv3JcKW8IlZUwptc0DKPqDPWpFMmGdK7Kx7I4KcCfYdxBJRQ3htQ1ps9NLE/Pfsk
         DLsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059391; x=1786664191;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=JiQKL/d/a0vrWgDwSPI6P4lMZN4rNkkCCv7n67xdKiQ=;
        b=iPR9EyKUNXVQD4LIwKmhD2YotvBCEdSMcXec48rEuk8Lv8VLYI+pxDjhkj9FH7O5lo
         CCcaNTkFR7acMnxSP4iWXJQhE3Mt0LLyeP/mXG3++FPfgogfC89Hnse7ZzaUXpjk+1aF
         6QoHBu8ZL4JXI3OXxDJ6cX9Vk7c/V0Xvu6y2dyA5RcXx+TDYBVeRR7P7vYU+Fo1T6n6j
         u64pZT8Ap/sqO88OV2Y0EfDLBM0GGPevGjvm9kZfKGNDjKD6EKp76KkgsjNkKegFkcxp
         IwLuc+AAnDfo3lnjGZqrO1qv4vcJ46ZGS7nOQ1T2/PPRDZZmutJDC2EpRnPsMA9yGmCt
         5tXw==
X-Forwarded-Encrypted: i=1; AHgh+RqvHo0k1SY5K3AzkZwDIQRinMBD52hifIomn2awZaTSvAPfdlzmflinyo2oIxrcCLnpZvr+PTZBUBE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwmIGeV4JylSUyFChQ8A63TY0hu4ATt7DjPInf0EV4ET2Nc3znv
	8USV5lgSf0BeOuJVjrnwa7xGvBes1ua/QJz/ioXMnxzhOM9uL5dj7EskE2NRHd6N926XoBgQvzc
	Q7M9OGg==
X-Received: from pjbsr12.prod.google.com ([2002:a17:90b:4e8c:b0:383:a728:1317])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:ec86:b0:38e:bbf1:de34
 with SMTP id 98e67ed59e1d1-3903c537a12mr20234960a91.7.1786059390540; Thu, 06
 Aug 2026 16:36:30 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:22 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-6-seanjc@google.com>
Subject: [PATCH v6 05/51] x86/sev: Mark TSC as reliable when configuring
 Secure TSC
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d25034/1786059393-024DFA5B-0FE27686/0/0
X-purgate-type: clean
X-purgate-size: 1723

Move the code to mark the TSC as reliable from sme_early_init() to
snp_secure_tsc_init().  The only reader of TSC_RELIABLE is the aptly
named check_system_tsc_reliable(), which runs in tsc_init(), i.e.
after snp_secure_tsc_init().

This will allow consolidating the handling of TSC_KNOWN_FREQ and
TSC_RELIABLE when overriding the TSC calibration routine.

Cc: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/coco/sev/core.c      | 2 ++
 arch/x86/mm/mem_encrypt_amd.c | 3 ---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index ecd77d3217f3..ed0ac52a765e 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2037,6 +2037,8 @@ void __init snp_secure_tsc_init(void)
 	secrets = (__force struct snp_secrets_page *)mem;
 
 	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+	setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+
 	rdmsrq(MSR_AMD64_GUEST_TSC_FREQ, tsc_freq_mhz);
 
 	/* Extract the GUEST TSC MHZ from BIT[17:0], rest is reserved space */
diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
index 2f8c32173972..6c3af974c7c2 100644
--- a/arch/x86/mm/mem_encrypt_amd.c
+++ b/arch/x86/mm/mem_encrypt_amd.c
@@ -535,9 +535,6 @@ void __init sme_early_init(void)
 		 */
 		x86_init.resources.dmi_setup = snp_dmi_setup;
 	}
-
-	if (sev_status & MSR_AMD64_SNP_SECURE_TSC)
-		setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
 }
 
 void __init mem_encrypt_free_decrypted_mem(void)
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385267.1627700 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dW-0006zf-I0; Thu, 06 Aug 2026 23:36:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385267.1627700; Thu, 06 Aug 2026 23:36:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dW-0006zW-F0; Thu, 06 Aug 2026 23:36:30 +0000
Received: by outflank-mailman (input) for mailman id 1385267;
 Thu, 06 Aug 2026 23:36:29 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3eRp1agYKCdwQC8LHAEMMEJC.AMKVCL-BCTCJJGQRQ.VCLNPMHCAR.MPE@flex--seanjc.bounces.google.com>)
 id 1ws7dV-0006aA-8Y
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dU-00GcVS-D4
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:28 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3eRp1agYKCdwQC8LHAEMMEJC.AMKVCL-BCTCJJGQRQ.VCLNPMHCAR.MPE@flex--seanjc.bounces.google.com>)
 id 6a7519b9-e002-0a2a0a5209dd-0a2a450cbaea-48
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:28 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3eRp1agYKCdwQC8LHAEMMEJC.AMKVCL-BCTCJJGQRQ.VCLNPMHCAR.MPE@flex--seanjc.bounces.google.com>)
 id 6a751a7a-f479-0a2a450c0019-d155d2c8dcb1-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:28 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-8487ed7f7beso3066060b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059386; x=1786664186; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=lGVITa15iYf7ywTb6PznrnwE5mV86GVcr9KZACd8UjM=;
        b=P5Mmiu0kxT8zdJ6oMfjjzlKWJroER5Z8qJszJtCnI2Jxz7iUDBTB3K8wrQxURhee4y
         TFvC3RmcKkPExJwp7RL8zPWMmRCiodcOQYp4hnzVMwn8pK7jmpiYsFXsvvlfnBrRE/bG
         q9ce8HmgSIuFqBWD3UpxgqiMSioNTTffVV1fNp7bmaM2s3UjuZ+jqI/yN5S8U1sQPSxr
         4z0UGnN4goFFn0TNpGEVfs3W+obqbRGp3g+wh5pTEVqhM1cYZXDCQnQRR9JWTTfwBPon
         hz9vbrWXQElGSmTbtYWChUBSJxIdNuPZTOMU7MW5bm+Zo5it2ypgdqSccpeS7FAr4KT1
         9lng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059386; x=1786664186;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=lGVITa15iYf7ywTb6PznrnwE5mV86GVcr9KZACd8UjM=;
        b=oYjhB2ufCvUpRN6n9DsIcH7pg4iNIqQhpMsBiDymnoHD35lFLWHQ2MTWDkdjIMYMSY
         PU44GNzi0qivY1e1q41wTUchIwxgxajhrI2IStJLiRfka4tdMYx70VFEvL1PC3Oa8JFO
         AMSSATUfkveQYVqSgEfu9kh5s2WjZrRveCuvgvo2KSc3YrSF8JzQqxXS5MhU0JhRWpWM
         BLxJUply9SUGlyfRXblEy4OxjTYlfaVO0xl/aMbsh8HgoLHP2Vp0cE1HoQuIYpKuEVO0
         R37E6tdjW+WVqlF6z45e6YfZCRTW26d/uhIUeZzbNm5W9+R+G330RcOInG/58hklljY6
         3CDw==
X-Forwarded-Encrypted: i=1; AHgh+RqR3Z+eXpPjXcO1wdYD5FBGRDSIrqNWByrDds3nyojF24++tQOQpIrU+K74uCdvpY6JszardIfzgns=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxA284ru0lfGMc+tHOqqMJamVLF7AlI+9LCYSHVvFKum5GfTsYC
	Kx62gZs6B515tGmK87ZZNZGiDa2AD4q31HkW4AVumKsr/OBwel+5XEO54FuxKWKbrQXgLqdQ6DI
	wWptxAQ==
X-Received: from pgnc18.prod.google.com ([2002:a63:7252:0:b0:c9e:6c82:64e8])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1310:b0:84e:216d:7e52
 with SMTP id d2e1a72fcca58-84f2e03175emr20642138b3a.14.1786059385989; Thu, 06
 Aug 2026 16:36:25 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:19 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-3-seanjc@google.com>
Subject: [PATCH v6 02/51] x86/apic: Add CONFIG_X86_LOCAL_APIC=n stubs for APIC
 timer frequency APIs
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d25034/1786059388-52530A5B-E5B61271/0/0
X-purgate-type: clean
X-purgate-size: 3092

Add stubs for the apic_set_timer_frequency_{,k}hz() APIs when the kernel is
built without support for a local APIC, and drop #ifdefs in callers that
don't need to check CONFIG_X86_LOCAL_APIC for other reasons.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/apic.h  | 2 ++
 arch/x86/kernel/cpu/vmware.c | 2 --
 arch/x86/kernel/tsc.c        | 2 --
 arch/x86/kernel/tsc_msr.c    | 2 --
 4 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 6946220a6008..9c5084f3317f 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -189,6 +189,8 @@ static inline void disable_local_APIC(void) { }
 # define setup_boot_APIC_clock x86_init_noop
 # define setup_secondary_APIC_clock x86_init_noop
 static inline void lapic_update_tsc_freq(void) { }
+static inline void apic_set_timer_frequency_hz(u64 freq_hz, const char *source) { }
+static inline void apic_set_timer_frequency_khz(u64 freq_khz, const char *source) { }
 static inline void init_bsp_APIC(void) { }
 static inline void apic_intr_mode_select(void) { }
 static inline void apic_intr_mode_init(void) { }
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 22842bf5b59e..2225df67d45f 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -422,10 +422,8 @@ static void __init vmware_platform_setup(void)
 		x86_platform.calibrate_tsc = vmware_get_tsc_khz;
 		x86_platform.calibrate_cpu = vmware_get_tsc_khz;
 
-#ifdef CONFIG_X86_LOCAL_APIC
 		/* Skip lapic calibration since we know the bus frequency. */
 		apic_set_timer_frequency_hz(ecx, "VMware hypervisor");
-#endif
 	} else {
 		pr_warn("Failed to get TSC freq from the hypervisor\n");
 	}
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 63e26805f8dd..4392fddd616e 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -710,7 +710,6 @@ unsigned long native_calibrate_tsc(void)
 	if (boot_cpu_data.x86_vfm == INTEL_ATOM_GOLDMONT)
 		setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
 
-#ifdef CONFIG_X86_LOCAL_APIC
 	/*
 	 * The local APIC appears to be fed by the core crystal clock
 	 * (which sounds entirely sensible). We can set the global
@@ -718,7 +717,6 @@ unsigned long native_calibrate_tsc(void)
 	 * timer later.
 	 */
 	apic_set_timer_frequency_khz(crystal_khz, "CPUID 0x15/0x16");
-#endif
 
 	return crystal_khz * ebx_numerator / eax_denominator;
 }
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 4bd5f2ae656b..179e3a331ef9 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -211,9 +211,7 @@ unsigned long cpu_khz_from_msr(void)
 	if (freq == 0)
 		pr_err("Error MSR_FSB_FREQ index %d is unknown\n", index);
 
-#ifdef CONFIG_X86_LOCAL_APIC
 	apic_set_timer_frequency_khz(freq, "MSR_FSB_FREQ");
-#endif
 
 	/*
 	 * TSC frequency determined by MSR is always considered "known"
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385272.1627746 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7de-0008Bc-0D; Thu, 06 Aug 2026 23:36:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385272.1627746; Thu, 06 Aug 2026 23:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dd-0008Ak-QD; Thu, 06 Aug 2026 23:36:37 +0000
Received: by outflank-mailman (input) for mailman id 1385272;
 Thu, 06 Aug 2026 23:36:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3gBp1agYKCeMXJFSOHLTTLQJ.HTRcJS-IJaJQQNXYX.cJSUWTOJHY.TWL@flex--seanjc.bounces.google.com>)
 id 1ws7db-0007kf-Nb
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7db-00GcVS-4X
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:35 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3gBp1agYKCeMXJFSOHLTTLQJ.HTRcJS-IJaJQQNXYX.cJSUWTOJHY.TWL@flex--seanjc.bounces.google.com>)
 id 6a751a81-e002-0a2a0a5209dd-0a2a450c8794-2
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:35 +0200
Received: from [209.85.214.197] (helo=mail-pl1-f197.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3gBp1agYKCeMXJFSOHLTTLQJ.HTRcJS-IJaJQQNXYX.cJSUWTOJHY.TWL@flex--seanjc.bounces.google.com>)
 id 6a751a81-f479-0a2a450c0019-d155d6c5e156-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:34 +0200
Received: by mail-pl1-f197.google.com with SMTP id
 d9443c01a7336-2cee1ec30f2so33068775ad.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059393; x=1786664193; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=AA+qmVUXq1UZoUYGqhY11Guml9As0mrU+L3gWPkVgC8=;
        b=ixyfPz9/AtOU4gqhTNmQ7HEQbdluEmTCxFLp+2HsWDMb5m45kBlLXlQNlFII7dXEX7
         pgYR+A0LWZO3abD7o0wWkpnenkpEbPLUidL9hw1t2FK0nv06h1mVGl8Bwft1b/WpDRIH
         e5jL/4X0cXdPjikP9B8ohzyJWqzDOU04M1IHCEU2YtUOT2udCqd7TPVol6KwRNmV4ENf
         Wl1lNsTWaZLxspm4OjCVjKAlKpYRS1PAGeaA2QhGxqcogoZ+Rycrmktvhtjp1F8K3xf/
         d4jFkOZ7UnCDsQIWLXHgi969584ZimWhdcmlfElI7fxUU1McJ+vz8YhDRrTRi9wTHt2Z
         wlmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059393; x=1786664193;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=AA+qmVUXq1UZoUYGqhY11Guml9As0mrU+L3gWPkVgC8=;
        b=WRg7SJ5wxcOo+Ls7TCcws1EJcOE1XljSG8YzVyzG8rQBN4v9mY1hfSXWYJzW/IOp+X
         j5xOwqO/t7mqGe2MHUDdYLlwQpmhj5XSI7ni8j2zZZPjR+lt6kPQcvGtALfH654Ax/bD
         lPzW3czQm3dmb8YdMMD230rVTAxN+ef335KPXEyC0+ne8bAnaCV6vAaoviB2XZedLdqC
         gYdNoycOPyKAZ6XxyMs82yON0lKX6rCjvrxMP/SXhc3wmSFUJZ44OpJp2O0IhPOt+wpY
         Tv75sMDTKXbTjkroAG2UGkn0aap6Hc3TLCgnYI0m+rLY0k3WNk+Hj6IFdaD/bNE0rQNx
         1rdw==
X-Forwarded-Encrypted: i=1; AHgh+Rp4n2aiK4iAKjkEpEHpDdP8nwPGxKU+5ypyrc+u3BpXTc0dcktfAPGJq+LcWuX+NWfxhTr9hR3rg8A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKZGBU/gjf9tvDNzYJjflLE7MAWqrsYzXPJ05Zacr2s1KvoPRz
	qymHYX03/AuWt8BFGNKoAIiK8cXpEbHscYkJJjl24eG02b292t8VWOKrgjKibWnoImK9KCsgFPV
	kPzXbkg==
X-Received: from plbjc21.prod.google.com ([2002:a17:903:25d5:b0:2ca:d66c:97b2])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ef0a:b0:2c9:c517:d070
 with SMTP id d9443c01a7336-2d0ca7afebcmr224927325ad.3.1786059392825; Thu, 06
 Aug 2026 16:36:32 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:24 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-8-seanjc@google.com>
Subject: [PATCH v6 07/51] x86/sev: Move check for SNP Secure TSC support to tsc_early_init()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d25034/1786059395-77ED2A5B-32AC4DBD/0/0
X-purgate-type: clean
X-purgate-size: 1583

Move the check on having a Secure TSC to the common tsc_early_init() so
that it's obvious that having a Secure TSC is conditional, and to prepare
for adding TDX to the mix (blindly initializing *both* SNP and TDX TSC
logic looks especially weird).

No functional change intended.

Cc: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/coco/sev/core.c | 3 ---
 arch/x86/kernel/tsc.c    | 3 ++-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 665de1aea0ee..403dcea86452 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2025,9 +2025,6 @@ void __init snp_secure_tsc_init(void)
 	unsigned long tsc_freq_mhz;
 	void *mem;
 
-	if (!cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC))
-		return;
-
 	mem = early_memremap_encrypted(sev_secrets_pa, PAGE_SIZE);
 	if (!mem) {
 		pr_err("Unable to get TSC_FACTOR: failed to map the SNP secrets page.\n");
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 09bf10f322ba..c710c71a1bdf 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1509,7 +1509,8 @@ void __init tsc_early_init(void)
 	if (is_early_uv_system())
 		return;
 
-	snp_secure_tsc_init();
+	if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC))
+		snp_secure_tsc_init();
 
 	if (!determine_cpu_tsc_frequencies(true))
 		return;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385274.1627751 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7de-0008Fe-GG; Thu, 06 Aug 2026 23:36:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385274.1627751; Thu, 06 Aug 2026 23:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7de-0008EQ-6p; Thu, 06 Aug 2026 23:36:38 +0000
Received: by outflank-mailman (input) for mailman id 1385274;
 Thu, 06 Aug 2026 23:36:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3gRp1agYKCeQYKGTPIMUUMRK.IUSdKT-JKbKRROYZY.dKTVXUPKIZ.UXM@flex--seanjc.bounces.google.com>)
 id 1ws7dc-0007wv-Sl
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dc-00GcaU-9U
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:36 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3gRp1agYKCeQYKGTPIMUUMRK.IUSdKT-JKbKRROYZY.dKTVXUPKIZ.UXM@flex--seanjc.bounces.google.com>)
 id 6a751a49-bab6-0a2a0a5309dd-0a2a4501d568-40
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:36 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3gRp1agYKCeQYKGTPIMUUMRK.IUSdKT-JKbKRROYZY.dKTVXUPKIZ.UXM@flex--seanjc.bounces.google.com>)
 id 6a751a82-5984-0a2a45010019-d155d2c8bc06-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:36 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-848d21bbb55so4633309b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059394; x=1786664194; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=kH88onT2XQPjPMTP9foWuf2kpVwGIl3qVDy3ZQ/XBNk=;
        b=WgpBj2tnuNJ8SKIkDltzyjZYZdaZ4+v5LrHck/UlzPGVAaC0Y+kWkaw7cQoy0DjGB/
         Koa0/gX/mEToB0MINePIOkunIjb6f6S7sdX0pL1Fy67Y9pARoXS5xt4df38bIU6LwBAd
         maiiV7PBAT3ShzRssQ/ghWB8VQLcM+zhMAraRJ95hmS6IBKFowXlwJBPpPwSBaetWY/U
         nqnM5X6M9fSZvCaCJS0kBFWoxZ44BehTNxPe1eiAhL+XKnZoNX3F+SxvUXp606yW6Nm/
         XwYAXiihNRxJDzwwVvmRDnWjFSOxfreg2UYK/RMOx2wPux5Bijeq6bxP44qD1IuF9I3s
         apQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059394; x=1786664194;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=kH88onT2XQPjPMTP9foWuf2kpVwGIl3qVDy3ZQ/XBNk=;
        b=ZQuOQh9JBLwvjrb/DXSmp3fLrCv4pUxkuiUf871DeJ3ItpP62L2Lt+0TcJT1+t6NvY
         4hSz3K6cpOpj1bQhxtgKMf1ZaB+aoi9QIqEIOkCN/kYaCMZSfkYXn7jJd9efzvWkRMUb
         uw3D05cEJw2ZqnE42/5nIquxx5vVkpSUFiAdC4EXTD+eVlfiEfym4soIF7vpb5jRKPfh
         RFSkDVOpfeGaE/edDg8gdGvImdltTnrluVL8QT/cqN2bHQGKNrQMFKCFzsPERcxdithO
         Ev8GdVs3oGqND+WUJhqhueUfiTmiTEj1b8N1jGxDNKCRpAO4fPA9R9UUk5VFMAv35I01
         rFHg==
X-Forwarded-Encrypted: i=1; AHgh+RpZMiycyxlC7LBHRni2KqoN/d82d1ecAJ8JS3qiAH9HczEmWCxym2W6TbBOplgdppSWTBXpyZ3YY5E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAvwnQIc5B1tAHSQNLfEbgzMJK0aYXa5SJNUEK25YUzIQwuId5
	U2GSOvcLaQPcM2Tg6UQaq6t35I+jfQlpCieiwIKZ0QlBtz275PP3T/AGEm9ako0ZGOR0M1g2bC2
	lzoyWEA==
X-Received: from pgei3.prod.google.com ([2002:a05:6a02:5263:b0:c82:7761:9936])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1ca2:b0:847:8ccc:d7c6
 with SMTP id d2e1a72fcca58-84f2e0278d5mr21014018b3a.31.1786059393911; Thu, 06
 Aug 2026 16:36:33 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:25 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-9-seanjc@google.com>
Subject: [PATCH v6 08/51] x86/sev: Shove SNP's secure/trusted TSC frequency
 directly into "calibration"
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786059396-BEA66757-721236B2/0/0
X-purgate-type: clean
X-purgate-size: 7245

As a first step towards dropping .calibrate_{cpu,tsc}() and explicitly
defining precedence/priority for "calibration" routines, pass the secure
TSC frequency obtained from SNP firmware directly to
determine_cpu_tsc_frequencies() instead of overriding the .calibrate_tsc()
hook.

Unlike the native calibration routines, all of the paravirtual overrides,
including SNP and TDX, are constant in the sense that the frequency
provided by the hypervisor or trusted firmware is fixed, known, and always
available during early boot.  More importantly, for CoCo (SNP and TDX) VMs,
it's imperative that the kernel uses the frequency provided by the trusted
firmware, not by the untrusted hypervisor.  Enforcing the priority between
sources by carefully ordering seemingly unrelated init calls, so that the
trusted override "wins", is brittle and all but impossible to follow.

Explicitly ignore tsc_early_khz if the exact TSC frequency was obtained
from trusted firmware, as per commit bd35c77e32e4 ("x86/tsc: Add
tsc_early_khz command line parameter"), the goal of the param is to play
nice with setups that provide partial frequency information in CPUID, i.e.
is NOT intended to be a hard override.  Neither SNP's secure TSC nor TDX
was supported when commit bd35c77e32e4 landed back in 2020, i.e. lack of
consideration for the interaction was purely due to oversight when SNP and
TDX support came along.

Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 .../admin-guide/kernel-parameters.txt         |  4 +++
 arch/x86/coco/sev/core.c                      | 14 +++--------
 arch/x86/include/asm/sev.h                    |  4 +--
 arch/x86/kernel/tsc.c                         | 25 ++++++++++++++-----
 4 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 87bb1fb31696..aa4eb568d9fb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7946,6 +7946,10 @@ Kernel parameters
 			with CPUID.16h support and partial CPUID.15h support.
 			Format: <unsigned int>
 
+			Note, tsc_early_khz is ignored if the TSC frequency is
+			provided by trusted firmware when running as an SNP
+			guest.
+
 	tsx=		[X86] Control Transactional Synchronization
 			Extensions (TSX) feature in Intel processors that
 			support TSX control.
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 403dcea86452..bc5ae9ef74da 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -99,7 +99,6 @@ static const char * const sev_status_feat_names[] = {
  */
 static u64 snp_tsc_scale __ro_after_init;
 static u64 snp_tsc_offset __ro_after_init;
-static unsigned long snp_tsc_freq_khz __ro_after_init;
 
 DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);
 DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa);
@@ -2014,15 +2013,10 @@ void __init snp_secure_tsc_prepare(void)
 	pr_debug("SecureTSC enabled");
 }
 
-static unsigned long securetsc_get_tsc_khz(void)
-{
-	return snp_tsc_freq_khz;
-}
-
-void __init snp_secure_tsc_init(void)
+unsigned int __init snp_secure_tsc_init(void)
 {
+	unsigned long snp_tsc_freq_khz, tsc_freq_mhz;
 	struct snp_secrets_page *secrets;
-	unsigned long tsc_freq_mhz;
 	void *mem;
 
 	mem = early_memremap_encrypted(sev_secrets_pa, PAGE_SIZE);
@@ -2043,7 +2037,7 @@ void __init snp_secure_tsc_init(void)
 
 	snp_tsc_freq_khz = SNP_SCALE_TSC_FREQ(tsc_freq_mhz * 1000, secrets->tsc_factor);
 
-	x86_platform.calibrate_tsc = securetsc_get_tsc_khz;
-
 	early_memunmap(mem, PAGE_SIZE);
+
+	return snp_tsc_freq_khz;
 }
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 594cfa19cbd4..05ebf0b73ef4 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -530,7 +530,7 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
 int snp_svsm_vtpm_send_command(u8 *buffer);
 
 void __init snp_secure_tsc_prepare(void);
-void __init snp_secure_tsc_init(void);
+unsigned int snp_secure_tsc_init(void);
 enum es_result savic_register_gpa(u64 gpa);
 enum es_result savic_unregister_gpa(u64 *gpa);
 u64 savic_ghcb_msr_read(u32 reg);
@@ -637,7 +637,7 @@ static inline int snp_send_guest_request(struct snp_msg_desc *mdesc,
 					 struct snp_guest_req *req) { return -ENODEV; }
 static inline int snp_svsm_vtpm_send_command(u8 *buffer) { return -ENODEV; }
 static inline void __init snp_secure_tsc_prepare(void) { }
-static inline void __init snp_secure_tsc_init(void) { }
+static inline unsigned int __init snp_secure_tsc_init(void) { return 0; }
 static inline void sev_evict_cache(void *va, int npages) {}
 static inline enum es_result savic_register_gpa(u64 gpa) { return ES_UNSUPPORTED; }
 static inline enum es_result savic_unregister_gpa(u64 *gpa) { return ES_UNSUPPORTED; }
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index c710c71a1bdf..6898584610a7 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1440,15 +1440,16 @@ static int __init init_tsc_clocksource(void)
  */
 device_initcall(init_tsc_clocksource);
 
-static bool __init determine_cpu_tsc_frequencies(bool early)
+static bool __init determine_cpu_tsc_frequencies(bool early,
+						 unsigned int known_tsc_khz)
 {
 	/* Make sure that cpu and tsc are not already calibrated */
 	WARN_ON(cpu_khz || tsc_khz);
 
 	if (early) {
 		cpu_khz = x86_platform.calibrate_cpu();
-		if (tsc_early_khz)
-			tsc_khz = tsc_early_khz;
+		if (known_tsc_khz)
+			tsc_khz = known_tsc_khz;
 		else
 			tsc_khz = x86_platform.calibrate_tsc();
 	} else {
@@ -1503,6 +1504,8 @@ static void __init tsc_enable_sched_clock(void)
 
 void __init tsc_early_init(void)
 {
+	unsigned int known_tsc_khz = 0;
+
 	if (!boot_cpu_has(X86_FEATURE_TSC))
 		return;
 	/* Don't change UV TSC multi-chassis synchronization */
@@ -1510,9 +1513,19 @@ void __init tsc_early_init(void)
 		return;
 
 	if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC))
-		snp_secure_tsc_init();
+		known_tsc_khz = snp_secure_tsc_init();
 
-	if (!determine_cpu_tsc_frequencies(true))
+	/*
+	 * Ignore the user-provided TSC frequency if the exact frequency was
+	 * obtained from trusted firmware, as the user-provided frequency is
+	 * intended as a "starting point", not a known, guaranteed frequency.
+	 */
+	if (!known_tsc_khz)
+		known_tsc_khz = tsc_early_khz;
+	else if (tsc_early_khz)
+		pr_err("Ignoring 'tsc_early_khz' in favor of trusted firmware.\n");
+
+	if (!determine_cpu_tsc_frequencies(true, known_tsc_khz))
 		return;
 	tsc_enable_sched_clock();
 }
@@ -1533,7 +1546,7 @@ void __init tsc_init(void)
 
 	if (!tsc_khz) {
 		/* We failed to determine frequencies earlier, try again */
-		if (!determine_cpu_tsc_frequencies(false)) {
+		if (!determine_cpu_tsc_frequencies(false, 0)) {
 			mark_tsc_unstable("could not calculate TSC khz");
 			setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
 			return;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385265.1627683 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dV-0006aJ-0d; Thu, 06 Aug 2026 23:36:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385265.1627683; Thu, 06 Aug 2026 23:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dU-0006aB-TV; Thu, 06 Aug 2026 23:36:28 +0000
Received: by outflank-mailman (input) for mailman id 1385265;
 Thu, 06 Aug 2026 23:36:27 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3dxp1agYKCdoOA6JF8CKKCHA.8KITAJ-9ARAHHEOPO.TAJLNKFA8P.KNC@flex--seanjc.bounces.google.com>)
 id 1ws7dT-0006Zy-Lz
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dS-00BpFw-9T
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:26 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3dxp1agYKCdoOA6JF8CKKCHA.8KITAJ-9ARAHHEOPO.TAJLNKFA8P.KNC@flex--seanjc.bounces.google.com>)
 id 6a751a68-2eae-0a2a0a5409dd-0a2a4503dca0-10
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:26 +0200
Received: from [209.85.216.69] (helo=mail-pj1-f69.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3dxp1agYKCdoOA6JF8CKKCHA.8KITAJ-9ARAHHEOPO.TAJLNKFA8P.KNC@flex--seanjc.bounces.google.com>)
 id 6a751a78-fae8-0a2a45030019-d155d845e936-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:26 +0200
Received: by mail-pj1-f69.google.com with SMTP id
 98e67ed59e1d1-38dbf293831so5540470a91.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:Mime-Version:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059384; x=1786664184; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:mime-version:date
         :reply-to:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=keDa3uiMUyNdngDUOX3bQBFQQi+1yM63Rcdpk9ukwB4=;
        b=evNv5RETlj1UOHaSOKKCIijsDCTxuFZDIAZT3RVZZLC5O6ov2gBfb8+QnUjAWSx+Sg
         lKcA1ZpM5Kp1DmprbJ7LuHbp05r6bLJfcW1pjPgnKVm9olO81iDNlew5MimIrOnaEDQt
         JML5n+xAmY+7syhDwI12nFuqbKO+f0R14jRMLrP+dodG/VvW0FBcout0pr7emD1FTl0U
         VWtjKgDf0+aUEKrFfoX8sDmlabfHyugIWy3hV3wprr4r4/xatFHuU6Po86yNK4vD3DO4
         MQ9nWf18H1/hh2aqU/tK1xhi0/YnN4TmRL6AbtbNYKgXBdEqyubzSdkY9EOnvSQnRoEy
         oSBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059384; x=1786664184;
        h=content-type:cc:to:from:subject:message-id:mime-version:date
         :reply-to:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=keDa3uiMUyNdngDUOX3bQBFQQi+1yM63Rcdpk9ukwB4=;
        b=NLQpp7U35yRcC+4JqKrhWnDeHPzIVmso/SDR/A7B0OSbwAUJ5qVFK165T51kZVaSGi
         BZplOnYGaHZpxNyk6Of59e9H/bqCW21EgpZ2U3AKpAWct6BGnWXoFKZa5RM1cey+aH4y
         fmRPP252nNPQy8mMJ8Rtc2nD4ee1LW7PhVHEqap822YLvOQ6SJDbp26pT/8WIdEhvfIT
         ND8jPoO7SBmpFmWAeRr/S55Vs91LFgy5VXDG7s1kuQwbRbQzTD4p1hkUrM2uDEUiCyv1
         a8yNRHil3AbQDWLGO9fol4TMxe3FYx/ESk6FWApJwDcoEsoBrF5yIyyInnCQgvDx/56w
         K64w==
X-Forwarded-Encrypted: i=1; AHgh+RrC8bAWgq5QcqyZ54Do+hmbbJR6LWfMeIlRR7u+qAYTM56/bP5glrhRCx9/UFMaUxWqfFjCb7jjzOM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxB+yCS0RNvhEOs8ffWXO2QqK/PU4Rtwf5JZJUHy/gJigVk6uut
	9lsXOKP3NIX7CPFvgbsep0T5YiXWtXWqQjQJSoAd0IR+IK7fltLQLSDxvSiOFZsJoUvzecYeabw
	YCoeIJQ==
X-Received: from pjnu1.prod.google.com ([2002:a17:90a:8901:b0:383:c59b:fc00])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:278c:b0:381:792d:f993
 with SMTP id 98e67ed59e1d1-3903c5bf6fbmr20025179a91.17.1786059383863; Thu, 06
 Aug 2026 16:36:23 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:17 -0700
Mime-Version: 1.0
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-1-seanjc@google.com>
Subject: [PATCH v6 00/51] x86: Try to wrangle PV clocks vs. TSC
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-33051d/1786059386-766FB4E9-CEA7D76F/0/0
X-purgate-type: clean
X-purgate-size: 11039

The primary goal of this series to fix flaws with SNP and TDX guests where a
PV clock provided by the untrusted hypervisor is used instead of the secure
TSC that is controlled by trusted firmware.

The secondary goal is modernize running under KVM.  Currently, KVM guests will
use TSC for clocksource, but not sched_clock.  And Linux-as-a-KVM-guest doesn't
support paravirt enumeration of the TSC/APIC frequencies, even though QEMU
provides that information by default.

The tertiary goal is to clean up the PV clock code to deduplicate logic across
hypervisors, and to hopefully make it all easier to maintain going forward.

The quaternary goal is to clean up the TSC calibration code, which was made
stupidly hard to follow by hypervisor code mixing in with the native
calibration routines, instead of being implemented as a pure alternative.

Note, the VMware and Xen changes still probably should get acks from those
maintainers, as my understanding of what they're trying to do may be flawed.

Lots more background on the SNP/TDX motiviation:
https://lore.kernel.org/all/20250106124633.1418972-13-nikunj@amd.com

As before, I deliberately omitted jailhouse-dev@googlegroups.com from the To/Cc,
as those emails bounced on v1, AFAICT nothing has changed.

v5:
 - Use cpu_feature_enabled() instead of boot_cpu_has(). [Boris]
 - WARN if recalibrate_cpu_khz() runs on a system with TSC_KNOWN_FREQ. [Thomas]
 - Opportunistically drop a line break in native_calibrate_tsc(). [Thomas]
 - Rely on callers of cpuid_get_tsc_info() to check the result instead of
   unnecessarily zeroing the structure. [Boris]
 - Ignore tsc_early_khz if the TSC frequency is provided by trusted firmware
   or by the hypervisor. [Thomas, Sashiko]
 - Cache CPUID output in acrn_init_platform() to avoid introducing a transient
   bug where TSC_KNOWN_FREQ could be set even if the ACRN hypervisor didn't
   actually provide the frequency. [Sashiko]
 - Drop kvmclock's useless/dead check_tsc_unstable() call (it occurs before the
   command line parameter is parsed). [Sashiko]
 - Add helpers to set lapic_timer_period, to fix not-so-theoretical overflow
   in the various "khz * 1000 / HZ" patterns. [Sashiko]
 - Drop the "x86/xen: Obtain TSC frequency from CPUID if present" patch as it
   doesn't have any dependencies/conflicts on/with this series, and Sashiko had
   concerns about the assumptions it was making. [Sashiko]
 - Collect reviews. [David] (Kirill's got dropped because the patch he reviewed
   got completely rewritten).


v4:
 - Use x86_init_noop() to skip save/restore on VMware and Xen instead of
   nullifying x86_platform.{save,restore}_sched_clock_state. [Sashiko]
 - Use '0' to indicate "failure" when getting the CPU frequency from CPUID, to
   avoid using an out-param and thus make it all but impossible to
   unintentionally clobber the global cpu_khz (which v3 did). [Sashiko]
 - Rename cpuid_get_cpu_freq() => __cpu_khz_from_cpuid() to capture its
   relationship with cpu_khz_from_cpuid().
 - Compute lapic_timer_period in units of ticks, not Khz. [Sashiko]
 - Kill off x86_platform_ops.calibrate_{cpu,tsc}(), and instead use dedicated
   hooks for hypervisor code, and direct calls for TDX and SNP. [David, loosely]
 - Drop SNP's secure TSC override of _CPU_ calibration, as there's zero
   evidence it's justified or a net positive.
 - Collect reviews/acks. [David, Wei]
 - Decouple getting TSC/APIC frequencies from KVM PV CPUID from kvmclock. [David]
 - Fix an amusing number of Opportunistically misspellings. [David]
 - Set kvm_sched_clock_offset _before_ registering kvmclock as sched_clock,
   and add a comment to guard against future goofs. [Sashiko]
 - Keep "setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE)" in Hyper-V's handling
   of HV_ACCESS_TSC_INVARIANT, as it's technically possible to have a VM
   with HV_ACCESS_TSC_INVARIANT but not HV_ACCESS_FREQUENCY_MSRS.  Though as
   a _very_ nice side effect of using dedicated sequencing for selecting the
   TSC frequency source, this would have naturally happened anyways. [Sashiko]

v3:
 - https://lore.kernel.org/all/20260515191942.1892718-1-seanjc@google.com
 - Collect reviews. [Michael, Thomas]
 - Use Hyper-V reference counter / refcounter instead of Hyper-V timer. [Michael]
 - Use the paravirt CPUID interface first proposed by VMware for KVM's
   "official" mechanism for communicating frequency to KVM-aware guests,
   instead of abusing Intel's CPUID leafs. [David]
 - Deal with paravirt code being moved into asm/timers.h and
   arch/x86/kernel/tsc.c.

v2:
 - https://lore.kernel.org/all/Z8YWttWDtvkyCtdJ@google.com
 - Add struct to hold the TSC CPUID output. [Boris]
 - Don't pointlessly inline the TSC CPUID helpers. [Boris]
 - Fix a variable goof in a helper, hopefully for real this time. [Dan]
 - Collect reviews. [Nikunj]
 - Override the sched_clock save/restore hooks if and only if a PV clock
   is successfully registered.
 - During resome, restore clocksources before reading persistent time.
 - Clean up more warts created by kvmclock.
 - Fix more bugs in kvmclock's suspend/resume handling.
 - Try to harden kvmclock against future bugs.

v1: https://lore.kernel.org/all/20250201021718.699411-1-seanjc@google.com

David Woodhouse (2):
  KVM: x86: Officially define CPUID 0x40000010 as PV Timing Info (TSC
    and Bus)
  x86/kvm: Obtain TSC frequency from PV CPUID if present

Sean Christopherson (49):
  x86/apic: Provide helpers to set local APIC timer frequency in hz and
    khz
  x86/apic: Add CONFIG_X86_LOCAL_APIC=n stubs for APIC timer frequency
    APIs
  x86/tsc: Ensure that TSC recalibration doesn't run if TSC frequency is
    known
  x86/tsc: Restrict recalibrate_cpu_khz() export to p4-clockmod and
    powernow-k7
  x86/sev: Mark TSC as reliable when configuring Secure TSC
  x86/sev: Don't override CPU frequency calibration for SNP's Secure TSC
  x86/sev: Move check for SNP Secure TSC support to tsc_early_init()
  x86/sev: Shove SNP's secure/trusted TSC frequency directly into
    "calibration"
  x86/tsc: Add a standalone helper for getting TSC info from CPUID.0x15
  x86/tdx: Force TSC frequency with CPUID-based info provided by the
    TDX-Module
  x86/tsc: Add dedicated hypervisor hooks for getting known TSC/CPU
    frequencies
  x86/acrn: Register TSC/CPU frequency callbacks iff frequency is
    actually in CPUID
  x86/acrn: Mark TSC frequency as known when using ACRN for calibration
  x86/tsc: Consolidate forcing of X86_FEATURE_TSC_KNOWN_FREQ for PV code
  x86/tsc: Kill off x86_platform_ops.calibrate_{cpu,tsc}() hooks
  x86/tsc: Rename pit_hpet_ptimer_calibrate_cpu() =>
    native_calibrate_cpu_late()
  x86/tsc: Fold native_calibrate_cpu() into recalibrate_cpu_khz()
  x86/kvmclock: Rename kvm_get_tsc_khz() to kvmclock_get_tsc_khz()
  x86/kvmclock: Drop dead check on TSC being unstable during
    kvmclock_init()
  x86/kvm: Mark TSC as reliable when it's constant and nonstop
  x86/tsc: Add standalone helper for getting CPU frequency from CPUID
  x86/kvm: Get CPU base frequency from CPUID when it's available
  clocksource: hyper-v: Register sched_clock save/restore iff it's
    necessary
  clocksource: hyper-v: Drop wrappers to sched_clock save/restore
    helpers
  clocksource: hyper-v: Don't save/restore TSC offset when using HV
    sched_clock
  x86/kvmclock: Setup kvmclock for secondary CPUs iff CONFIG_SMP=y
  x86/kvm: Don't disable kvmclock on BSP in syscore_suspend()
  x86/paravirt: Remove unnecessary PARAVIRT=n stub for
    paravirt_set_sched_clock()
  x86/paravirt: Move handling of unstable PV clocks into
    paravirt_set_sched_clock()
  x86/kvmclock: Move sched_clock save/restore helpers up in kvmclock.c
  x86/xen/time: NOP-ify x86_platform's sched_clock save/restore hooks
  x86/vmware: NOP-ify save/restore hooks when using VMware's sched_clock
  x86/tsc: WARN if TSC sched_clock save/restore used with PV sched_clock
  x86/paravirt: Pass sched_clock save/restore helpers during
    registration
  x86/kvmclock: Move kvm_sched_clock_init() down in kvmclock.c
  x86/xen/time: Mark xen_setup_vsyscall_time_info() as __init
  x86/pvclock: Mark setup helpers and related various as
    __init/__ro_after_init
  x86/pvclock: WARN if pvclock's valid_flags are overwritten
  x86/kvmclock: Refactor handling of PVCLOCK_TSC_STABLE_BIT during
    kvmclock_init()
  timekeeping: Resume clocksources before reading persistent clock
  x86/kvmclock: Hook clocksource.suspend/resume when kvmclock isn't
    sched_clock
  x86/kvmclock: WARN if wall clock is read while kvmclock is suspended
  x86/paravirt: Mark __paravirt_set_sched_clock() as __init
  x86/paravirt: Plumb a return code into __paravirt_set_sched_clock()
  x86/paravirt: Don't use a PV sched_clock in CoCo guests with trusted
    TSC
  x86/kvmclock: Use TSC for sched_clock if it's constant and non-stop
  x86/kvmclock: Plumb in AP-online and BSP-resume to kvmlock, for
    documentation
  x86/paravirt: Move using_native_sched_clock() stub into timer.h
  x86/kvm: Get local APIC bus frequency from PV CPUID Timing Info

 .../admin-guide/kernel-parameters.txt         |   5 +
 Documentation/virt/kvm/x86/cpuid.rst          |  12 +
 arch/x86/coco/sev/core.c                      |  21 +-
 arch/x86/coco/tdx/tdx.c                       |  19 +-
 arch/x86/include/asm/acrn.h                   |   5 -
 arch/x86/include/asm/apic.h                   |   5 +-
 arch/x86/include/asm/kvm_para.h               |  12 +-
 arch/x86/include/asm/sev.h                    |   4 +-
 arch/x86/include/asm/tdx.h                    |   2 +
 arch/x86/include/asm/timer.h                  |  15 +-
 arch/x86/include/asm/tsc.h                    |  10 +-
 arch/x86/include/asm/x86_init.h               |   8 +-
 arch/x86/include/uapi/asm/kvm_para.h          |  11 +
 arch/x86/kernel/apic/apic.c                   |  19 +-
 arch/x86/kernel/cpu/acrn.c                    |  14 +-
 arch/x86/kernel/cpu/mshyperv.c                |  70 +-----
 arch/x86/kernel/cpu/vmware.c                  |  19 +-
 arch/x86/kernel/jailhouse.c                   |   9 +-
 arch/x86/kernel/kvm.c                         | 101 ++++++--
 arch/x86/kernel/kvmclock.c                    | 208 +++++++++++------
 arch/x86/kernel/pvclock.c                     |   9 +-
 arch/x86/kernel/tsc.c                         | 218 +++++++++++-------
 arch/x86/kernel/tsc_msr.c                     |   4 +-
 arch/x86/kernel/x86_init.c                    |   2 -
 arch/x86/mm/mem_encrypt_amd.c                 |   3 -
 arch/x86/xen/time.c                           |  14 +-
 drivers/clocksource/hyperv_timer.c            |  38 ++-
 include/clocksource/hyperv_timer.h            |   2 -
 kernel/time/timekeeping.c                     |   9 +-
 29 files changed, 547 insertions(+), 321 deletions(-)


base-commit: 6949feed6e32823a6628873000602988a4cafe06
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385268.1627710 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dX-0007Cp-Qh; Thu, 06 Aug 2026 23:36:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385268.1627710; Thu, 06 Aug 2026 23:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dX-0007Ci-Me; Thu, 06 Aug 2026 23:36:31 +0000
Received: by outflank-mailman (input) for mailman id 1385268;
 Thu, 06 Aug 2026 23:36:30 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3exp1agYKCd4SEANJCGOOGLE.COMXEN-DEVELLISTS.XENPROJECT.ORG@flex--seanjc.bounces.google.com>)
 id 1ws7dW-0006wt-B6
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dV-00BpFw-OJ
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:29 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3exp1agYKCd4SEANJCGOOGLE.COMXEN-DEVELLISTS.XENPROJECT.ORG@flex--seanjc.bounces.google.com>)
 id 6a751a68-2eae-0a2a0a5409dd-0a2a4503dca0-12
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:29 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3exp1agYKCd4SEANJCGOOGLE.COMXEN-DEVELLISTS.XENPROJECT.ORG@flex--seanjc.bounces.google.com>)
 id 6a751a7c-fae8-0a2a45030019-d155d2c8b58b-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:29 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-8486ffba174so6231388b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059388; x=1786664188; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=2SJsprQma6tQ2oU494vKbTkDMI4EE2yRA8rYyHQJqoI=;
        b=n4Hy1f/s0tj0vRdDTiDRCu5VS4gfXmQLfJcrwbMBZNuQ1kBE1EfSQHspcOCwyptVeh
         51Lzvt8S3VPVfbT1F1KoYQjCe/GhJQG6viwMeGV3xGi+N8MfMTI0ceECgJqTDZkjECtU
         ta+xAIrWdDfw7GN5P1dsBm9AeLTkOX4Z608KT1OZP7r17f/3zmEiC+PpJufshDrPCcL8
         tGKt+doHE/NO9mcYomTCl7se1XT+TxBEY+nSB284+o97Nr8HdRqRYJ+CZuMFPnni1fTm
         THxCHFxaraKTcWIEQNwuh+S5VomxDPy9qjBMt6nWTIB9MqrXBIbjB/ttQV1/o6e3dV3G
         nmvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059388; x=1786664188;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=2SJsprQma6tQ2oU494vKbTkDMI4EE2yRA8rYyHQJqoI=;
        b=ibixDnDakB/lb5yqDOOHzevpuGGtGIdDaQxW8FPvaeIqVkGWxKD8EIXxhpSIO0gVm0
         m56uSa7nzD0vMWoGt0a9AltgTlUla5KJ9AcART2v5vPiuMZBsDAAncCqX23jFFjGML7t
         79MBakHKYWFf/aTPE4ZU3zSnLIVH3rfdrtdANNyzn9a02MRy2EvW7bzWnqGfN+gJ/88N
         551vMaoztgi5MMyy85StUw6+04UNsj/C41k7WOGI0PppBN5sTl64GdI8H1ejQSPm8gSQ
         mQz/Jhrk8WVIgkckiSRkjnQg15n6yHXqkvQRM4NYlBkKIbS9gLLPNzGhAF4DSY4Ra/Z3
         inKw==
X-Forwarded-Encrypted: i=1; AHgh+RrLYLgL9ESakyj5CZCuWRQ995Lii1QhVLGVwbR4CB7M1A9DWIIago0RWoz3gNsmPF36YLRZSQXXfj4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysDo6Y9Z8pw9wMpQw+qnck42nc+ZdbVbArX7jONWwCm14O+GIr
	vQFkmRZ1zZYhYv19C9zGqQ24hqlINTTNCBzsPVxSZYWgRAfE3C9WU5Lx+JrcN0B4lwLWSMTextw
	KkRimug==
X-Received: from pglr15.prod.google.com ([2002:a63:514f:0:b0:c9a:7d72:c316])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2d0c:b0:84e:2382:f4f0
 with SMTP id d2e1a72fcca58-84f2dfc8ed4mr19812672b3a.4.1786059387185; Thu, 06
 Aug 2026 16:36:27 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:20 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-4-seanjc@google.com>
Subject: [PATCH v6 03/51] x86/tsc: Ensure that TSC recalibration doesn't run
 if TSC frequency is known
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-33051d/1786059389-764FC4E9-10560814/0/0
X-purgate-type: clean
X-purgate-size: 1414

When attempting TSC recalibration post-boot, which is only done for ancient
CPUS (P4 and K7) on SMP=n kernels, assert that the TSC frequency isn't
known (explicitly provided by hardware) by way of MSR or CPUID, and bail if
the impossible happens.  In practice, recalibration and TSC_KNOWN_FREQ are
mutually exclusive, as TSC_KNOWN_FREQ will only be set when running on
hardware that was released decades after recalibration was obsoleted, but
but it's hard to see that, especially when looking at just the TSC code.

Note, the WARN can likely be tripped by running in a virtual machine and
concocting an impossible CPU model, e.g. by combining a P4 signature with
CPUID 0x15.  This is working as intended, as such a virtual CPU model is
wildly out-of-spec and is not supported.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 4392fddd616e..bc4348585194 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -930,6 +930,9 @@ void recalibrate_cpu_khz(void)
 	if (!boot_cpu_has(X86_FEATURE_TSC))
 		return;
 
+	if (WARN_ON_ONCE(cpu_feature_enabled(X86_FEATURE_TSC_KNOWN_FREQ)))
+		return;
+
 	cpu_khz = x86_platform.calibrate_cpu();
 	tsc_khz = x86_platform.calibrate_tsc();
 	if (tsc_khz == 0)
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385276.1627765 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dg-0000KK-RF; Thu, 06 Aug 2026 23:36:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385276.1627765; Thu, 06 Aug 2026 23:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dg-0000Jt-JL; Thu, 06 Aug 2026 23:36:40 +0000
Received: by outflank-mailman (input) for mailman id 1385276;
 Thu, 06 Aug 2026 23:36:39 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3hBp1agYKCecbNJWSLPXXPUN.LXVgNW-MNeNUURbcb.gNWYaXSNLc.XaP@flex--seanjc.bounces.google.com>)
 id 1ws7df-0008UC-A3
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7de-00GcaU-Mr
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:38 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3hBp1agYKCecbNJWSLPXXPUN.LXVgNW-MNeNUURbcb.gNWYaXSNLc.XaP@flex--seanjc.bounces.google.com>)
 id 6a751a70-bab6-0a2a0a5309dd-0a2a450ae97a-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:38 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3hBp1agYKCecbNJWSLPXXPUN.LXVgNW-MNeNUURbcb.gNWYaXSNLc.XaP@flex--seanjc.bounces.google.com>)
 id 6a751a85-f2d2-0a2a450a0019-d155d2c5cd50-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:38 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84857446424so4590880b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059397; x=1786664197; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:reply-to:from
         :to:cc:subject:date:message-id:reply-to:content-type;
        bh=QkWxTw8zJYn5bKvqCmD8koA0mP/8bnNFfn6ySpGUKjQ=;
        b=fJHLnSiqbKcx+tpzrPBosh7ZXY5G0rsX5Fvcp+/DjjmreXQ05GHGKbRh3/7mkj0MQN
         z7qH/WwlM22VEphBuA6YD2eOwtCqDNeDCd7DEenINVqwTX1jXd6FKmwTGiP6Cdn7JZac
         wViJoOks7DytdFEfLEaHOGQFaLRd6UF0V/LZyxZpFRCpzisGeWGvNonNv+GwzjDD4i9h
         zzv3ee5xwQPoaTmFERWhAiABc0OaxIfbQdWr1ScJq5E7OfB3kgsKBVlsLlmBrTz5NbHn
         4Odd8jfoQQERmhNXiMgy0Paq5YIY8d5HFoFd+LNXm/cufEeUAqeGj8ntCCnf9ADsS+jT
         C+4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059397; x=1786664197;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:reply-to
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=QkWxTw8zJYn5bKvqCmD8koA0mP/8bnNFfn6ySpGUKjQ=;
        b=BD35hR5geCUCSlAfpimeafDg4+LIuOYL0Bo5XNbdMjfBfx2Oku7WCHcUxdmbHb6Ibp
         bek1NoFtcBHl0kVN86X8V6zi869rjQZe7Cr45G9HzLJZmb63Yzm4x3Ab67FYhUhkKHL+
         /m1XO+tB+bTxiRdEbjsDHTOerrV/EG+PPr1+5sQMmxlxbjsZmOtsNDdpBjnMn8brKevH
         hmU84mVSI5z6/2rPeK92BZXJV86eqHA9mDXd7wUWBGIepR0oH+Q7yhz4Y4NDo5xqnZIP
         x+B2eYZ2Pg2dMEqaOGuIBbwEZSLlQv0oxRUmctWRKQjMIWF0wJO38kUg0yYR/d4OUwCF
         gqCA==
X-Forwarded-Encrypted: i=1; AHgh+RooYxWkuyztSGgLJZP3xr9nYLVOaZHvxt4W2rFPsrAw/kGFHub70xudot8gsebQcC66Tc3MKHvTGqk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzPHCq/YLkJmclDPoiAk4fy3LraDYvd6GFVLlLgDfAKHyLdVQ6G
	ZQAc4KI+OwkeOzbauUIKuHLf6H7LQyGaf68X9Np81ibWwxOKZb+UfDFhY4mbFvjIqmWq0PPjmE6
	Cl1AmCA==
X-Received: from pfqy1.prod.google.com ([2002:aa7:9e01:0:b0:848:46e6:1aac])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3692:b0:84e:24f:2677
 with SMTP id d2e1a72fcca58-84f2dfc0601mr21949181b3a.4.1786059396135; Thu, 06
 Aug 2026 16:36:36 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:27 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-11-seanjc@google.com>
Subject: [PATCH v6 10/51] x86/tdx: Force TSC frequency with CPUID-based info
 provided by the TDX-Module
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-4011c0/1786059398-52EDACFC-0339FAF7/0/0
X-purgate-type: clean
X-purgate-size: 6604

When running as a TDX guest, explicitly set the TSC frequency to a known
value, using CPUID-based information, instead of potentially relying on a
hypervisor-controlled PV routine.  For TDX guests, CPUID.0x15 is always
emulated by the TDX-Module, i.e. the information from CPUID is more
trustworthy than the information provided by the hypervisor.

To maintain backwards compatibility with TDX guest kernels that use native
calibration, and because it's the least awful option, retain
native_calibrate_tsc()'s stuffing of the local APIC bus period using the
core crystal frequency.  While it's entirely possible for the hypervisor
to emulate the APIC timer at a different frequency than the core crystal
frequency, the commonly accepted interpretation of Intel's SDM is that APIC
timer runs at the core crystal frequency when that latter is enumerated via
CPUID:

  The APIC timer frequency will be the processor=E2=80=99s bus clock or cor=
e
  crystal clock frequency (when TSC/core crystal clock ratio is enumerated
  in CPUID leaf 0x15).

If the hypervisor is malicious and deliberately runs the APIC timer at the
wrong frequency, nothing would stop the hypervisor from modifying the
frequency at any time, i.e. attempting to manually calibrate the frequency
out of paranoia would be futile.

Deliberately leave CPU frequency calibration as is, since the TDX-Module
doesn't provide any guarantees with respect to CPUID.0x16.

Expose and use cpuid_get_tsc_info() instead of providing a wrapper to
get the TSC and core crystal frequency, as TDX is the only anticipated
user outside of the TSC code, i.e. adding a helper to dedup the math won't
actually dedup anything.  Having TDX use "struct cpuid_tsc_info" also
avoids the temptation of declaring a local "tsc_khz" variable and thus
unintentionally creating a shadow of the global "tsc_khz".

Cc: Kiryl Shutsemau (Meta) <kas@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 .../admin-guide/kernel-parameters.txt         |  4 ++--
 arch/x86/coco/tdx/tdx.c                       | 20 ++++++++++++++++---
 arch/x86/include/asm/tdx.h                    |  2 ++
 arch/x86/include/asm/tsc.h                    |  7 +++++++
 arch/x86/kernel/tsc.c                         | 11 ++++------
 5 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio=
n/admin-guide/kernel-parameters.txt
index aa4eb568d9fb..5a3d40a4a4ec 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7947,8 +7947,8 @@ Kernel parameters
 			Format: <unsigned int>
=20
 			Note, tsc_early_khz is ignored if the TSC frequency is
-			provided by trusted firmware when running as an SNP
-			guest.
+			provided by trusted firmware when running as an SNP or
+			TDX guest.
=20
 	tsx=3D		[X86] Control Transactional Synchronization
 			Extensions (TSX) feature in Intel processors that
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index f904a636d449..ec28a15e26ac 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -8,6 +8,7 @@
 #include <linux/export.h>
 #include <linux/io.h>
 #include <linux/kexec.h>
+#include <asm/apic.h>
 #include <asm/coco.h>
 #include <asm/tdx.h>
 #include <asm/vmx.h>
@@ -1121,9 +1122,6 @@ void __init tdx_early_init(void)
=20
 	setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
=20
-	/* TSC is the only reliable clock in TDX guest */
-	setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
-
 	cc_vendor =3D CC_VENDOR_INTEL;
=20
 	/* Configure the TD */
@@ -1193,3 +1191,19 @@ void __init tdx_early_init(void)
=20
 	tdx_announce();
 }
+
+unsigned int __init tdx_tsc_init(void)
+{
+	struct cpuid_tsc_info info;
+
+	if (WARN_ON_ONCE(cpuid_get_tsc_info(&info) || !info.crystal_khz))
+		return 0;
+
+	apic_set_timer_frequency_khz(info.crystal_khz, "TDX-Module via CPUID");
+
+	/* TSC is the only reliable clock in TDX guest */
+	setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+
+	return info.crystal_khz * info.numerator / info.denominator;
+}
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index 89e97d5761d8..d23ff06db41a 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -68,6 +68,7 @@ struct ve_info {
 #ifdef CONFIG_INTEL_TDX_GUEST
=20
 void __init tdx_early_init(void);
+unsigned int __init tdx_tsc_init(void);
=20
 void tdx_get_ve_info(struct ve_info *ve);
=20
@@ -89,6 +90,7 @@ void __init tdx_dump_td_ctls(u64 td_ctls);
 #else
=20
 static inline void tdx_early_init(void) { };
+static inline unsigned int tdx_tsc_init(void) { return 0; }
 static inline void tdx_halt(void) { };
=20
 static inline bool tdx_early_handle_ve(struct pt_regs *regs) { return fals=
e; }
diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index 4d2d2f21ff06..b6b86e24e1bf 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -82,6 +82,13 @@ static inline cycles_t get_cycles(void)
 }
 #define get_cycles get_cycles
=20
+struct cpuid_tsc_info {
+	unsigned int denominator;
+	unsigned int numerator;
+	unsigned int crystal_khz;
+};
+extern int cpuid_get_tsc_info(struct cpuid_tsc_info *info);
+
 extern void tsc_early_init(void);
 extern void tsc_init(void);
 extern void mark_tsc_unstable(char *reason);
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index d405ff4e45e0..f3febe406fa8 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -34,6 +34,7 @@
 #include <asm/topology.h>
 #include <asm/uv/uv.h>
 #include <asm/sev.h>
+#include <asm/tdx.h>
=20
 unsigned int __read_mostly cpu_khz;	/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -645,13 +646,7 @@ static unsigned long quick_pit_calibrate(void)
 	return delta;
 }
=20
-struct cpuid_tsc_info {
-	unsigned int denominator;
-	unsigned int numerator;
-	unsigned int crystal_khz;
-};
-
-static int cpuid_get_tsc_info(struct cpuid_tsc_info *info)
+int cpuid_get_tsc_info(struct cpuid_tsc_info *info)
 {
 	unsigned int ecx_hz, edx;
=20
@@ -1529,6 +1524,8 @@ void __init tsc_early_init(void)
=20
 	if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC))
 		known_tsc_khz =3D snp_secure_tsc_init();
+	else if (boot_cpu_has(X86_FEATURE_TDX_GUEST))
+		known_tsc_khz =3D tdx_tsc_init();
=20
 	/*
 	 * Ignore the user-provided TSC frequency if the exact frequency was
--=20
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385278.1627771 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7di-0000aC-Bk; Thu, 06 Aug 2026 23:36:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385278.1627771; Thu, 06 Aug 2026 23:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7di-0000Z9-66; Thu, 06 Aug 2026 23:36:42 +0000
Received: by outflank-mailman (input) for mailman id 1385278;
 Thu, 06 Aug 2026 23:36:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3hRp1agYKCegcOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@flex--seanjc.bounces.google.com>)
 id 1ws7dg-0000Ig-F2
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7df-00GcT3-Ro
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:39 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3hRp1agYKCegcOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@flex--seanjc.bounces.google.com>)
 id 6a751a35-5cb7-0a2a0a5109dd-0a2a450bb002-36
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:39 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3hRp1agYKCegcOKXTMQYYQVO.MYWhOX-NOfOVVScdc.hOXZbYTOMd.YbQ@flex--seanjc.bounces.google.com>)
 id 6a751a86-b7e8-0a2a450b0019-d155d2c5ed0a-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:39 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-8484f26852dso3084165b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059398; x=1786664198; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=BTA01HvIZtLfKHw73sD4lcjm5hs9HMIraXdGO98hTIs=;
        b=KLzF5lYbfJcAarXUGcqkhaTeNAVsD0XO0D6/e+mae/DJPv1S3Smidgd+lbVDRvXfoG
         58IJ69eubmfkaiRLxzmAm8CjRwaCdR3DUmTTory+Y46AS0JPIEXQRtJkduoY+fG0CLue
         J+Ku5KDeNUVB7rTATBJsLuVXoBQmbNc/KsHJ+jRoZ85aHqfsIcNEMaar6wO+/k6LYv7i
         QUHeivxexhweFpGmqeQ0nDK5OUg1WS8tnoBpOUj/r/q0hGd2dYAn6Ju9uJcTj+AcLtfZ
         nXsLrML1KVOB1++MD4rWDHsNX/YoozWMAPE/4aZR6OdtTOUIYLEMy2Ot1th6R7tFdiNy
         Oe7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059398; x=1786664198;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=BTA01HvIZtLfKHw73sD4lcjm5hs9HMIraXdGO98hTIs=;
        b=Ybeaf0DXjTwFIe/UQ4lX2D3RyrL4ykKtAb136CtzSdSh/zpVnFoYrD9CXnxWiid4RW
         IxMP/FAfBoYgzEE5Z8xbgoLPGtzhnpAXZLcLdO8Y8oolgAmdhT/3vmfxLwtoq+3A8rtv
         RKiciaj0nIhXGn8mR2MVawBB6fT8SdmHXdiPl+XurNmI1UatxcdVZQX5TWCWSpxWBfwL
         s9pIPcWQHwICn7+fYdphtShf44gB2b52d9LTOH6R67k1iGCDbwOuldvGQ9FEGE42dbBo
         QeYK5l2OzQ4o2K//btKEG9hXtsHYdZmJvmvAoAQM3lKn6g1mBlLZ/rhjZ3bqpc7CBfGh
         Qt0Q==
X-Forwarded-Encrypted: i=1; AHgh+Rpx/1cvQGXP96dTDgwqx8AMY9QPaT3M+ZqPLVtlLsZJoAaFGkX0xKR9Ltxc5Lkss/jT59Yu4QFx4LQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8BZLLU5UB6pxdEy/2PUhZP0aWdPS6JPRvFbBY5R4xIjWXUEfr
	dTyvRIrbx7BwW3eaYKNcHvTpXAD3VqkFzf5qKP4CrOvS2/H37lfXlvnXwORcX3llf6uirWZOGYs
	4JsckFA==
X-Received: from pfbkx25.prod.google.com ([2002:a05:6a00:6f19:b0:847:8449:eef1])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1388:b0:848:30c3:45dd
 with SMTP id d2e1a72fcca58-84f4fdbf18amr5180418b3a.11.1786059397399; Thu, 06
 Aug 2026 16:36:37 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:28 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-12-seanjc@google.com>
Subject: [PATCH v6 11/51] x86/tsc: Add dedicated hypervisor hooks for getting
 known TSC/CPU frequencies
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-42698a/1786059399-1B6D29EA-230C55CD/0/0
X-purgate-type: clean
X-purgate-size: 12640

Add dedicated hypervisor hooks for getting known TSC/CPU frequencies
instead of overriding seemingly generic platform hooks, and explicitly
prioritize hypervisor-provided frequencies over native methods, but do NOT
clobber the frequency obtained from trusted firmware.  While shuffling the
hooks around is arguably "six of one, half dozen of the other", scoping
them to x86_hyper_init makes their purpose more obvious, and allows for
explicitly defining the priority of sources (as is done here).

As is already done when trusted firmware provides the TSC frequency, ignore
tsc_early_khz if the exact TSC frequency was obtained from the hypervisor,
as attempting to refine the TSC frequency when running in a VM is all but
guaranteed to cause problems sooner or later due to the calibration sources
being emulated devices in the vast majority of setups.

Cc: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 .../admin-guide/kernel-parameters.txt         |  3 +-
 arch/x86/include/asm/acrn.h                   |  5 ----
 arch/x86/include/asm/x86_init.h               |  4 +++
 arch/x86/kernel/cpu/acrn.c                    | 10 +++++--
 arch/x86/kernel/cpu/mshyperv.c                |  6 ++--
 arch/x86/kernel/cpu/vmware.c                  |  8 ++---
 arch/x86/kernel/jailhouse.c                   |  6 ++--
 arch/x86/kernel/kvmclock.c                    |  6 ++--
 arch/x86/kernel/tsc.c                         | 29 ++++++++++++++-----
 arch/x86/xen/time.c                           |  4 +--
 10 files changed, 50 insertions(+), 31 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 5a3d40a4a4ec..1ab56fbdc35d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -7948,7 +7948,8 @@ Kernel parameters
 
 			Note, tsc_early_khz is ignored if the TSC frequency is
 			provided by trusted firmware when running as an SNP or
-			TDX guest.
+			TDX guest, or when the hypervisor provides the exact
+			frequency via a paravirtual interface.
 
 	tsx=		[X86] Control Transactional Synchronization
 			Extensions (TSX) feature in Intel processors that
diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
index db42b477c41d..a892179c61c6 100644
--- a/arch/x86/include/asm/acrn.h
+++ b/arch/x86/include/asm/acrn.h
@@ -32,11 +32,6 @@ static inline u32 acrn_cpuid_base(void)
 	return 0;
 }
 
-static inline unsigned long acrn_get_tsc_khz(void)
-{
-	return cpuid_eax(ACRN_CPUID_TIMING_INFO);
-}
-
 /*
  * Hypercalls for ACRN
  *
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 953d3199408a..0c89bf40f507 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -123,6 +123,8 @@ struct x86_init_pci {
  * @msi_ext_dest_id:		MSI supports 15-bit APIC IDs
  * @init_mem_mapping:		setup early mappings during init_mem_mapping()
  * @init_after_bootmem:		guest init after boot allocator is finished
+ * @get_tsc_khz:		get the TSC frequency (returns 0 if frequency is unknown)
+ * @get_cpu_khz:		get the CPU frequency (returns 0 if frequency is unknown)
  */
 struct x86_hyper_init {
 	void (*init_platform)(void);
@@ -131,6 +133,8 @@ struct x86_hyper_init {
 	bool (*msi_ext_dest_id)(void);
 	void (*init_mem_mapping)(void);
 	void (*init_after_bootmem)(void);
+	unsigned int (*get_tsc_khz)(void);
+	unsigned int (*get_cpu_khz)(void);
 };
 
 /**
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index dc119af83524..ad8f2da8003b 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -24,13 +24,15 @@ static u32 __init acrn_detect(void)
 	return acrn_cpuid_base();
 }
 
+static unsigned int __init acrn_get_tsc_khz(void)
+{
+	return cpuid_eax(ACRN_CPUID_TIMING_INFO);
+}
+
 static void __init acrn_init_platform(void)
 {
 	/* Install system interrupt handler for ACRN hypervisor callback */
 	sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_acrn_hv_callback);
-
-	x86_platform.calibrate_tsc = acrn_get_tsc_khz;
-	x86_platform.calibrate_cpu = acrn_get_tsc_khz;
 }
 
 static bool acrn_x2apic_available(void)
@@ -78,4 +80,6 @@ const __initconst struct hypervisor_x86 x86_hyper_acrn = {
 	.type			= X86_HYPER_ACRN,
 	.init.init_platform     = acrn_init_platform,
 	.init.x2apic_available  = acrn_x2apic_available,
+	.init.get_tsc_khz	= acrn_get_tsc_khz,
+	.init.get_cpu_khz	= acrn_get_tsc_khz,
 };
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index cadc7f872b4f..4a0cdda0c49e 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -395,7 +395,7 @@ static int hv_nmi_unknown(unsigned int val, struct pt_regs *regs)
 }
 #endif
 
-static unsigned long hv_get_tsc_khz(void)
+static unsigned int __init hv_get_tsc_khz(void)
 {
 	unsigned long freq;
 
@@ -573,8 +573,8 @@ static void __init ms_hyperv_init_platform(void)
 
 	if (ms_hyperv.features & HV_ACCESS_FREQUENCY_MSRS &&
 	    ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) {
-		x86_platform.calibrate_tsc = hv_get_tsc_khz;
-		x86_platform.calibrate_cpu = hv_get_tsc_khz;
+		x86_init.hyper.get_tsc_khz = hv_get_tsc_khz;
+		x86_init.hyper.get_cpu_khz = hv_get_tsc_khz;
 		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	}
 
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 2225df67d45f..3f1dab69d90e 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -64,7 +64,7 @@ struct vmware_steal_time {
 	u64 reserved[7];
 };
 
-static unsigned long vmware_tsc_khz __ro_after_init;
+static unsigned long vmware_tsc_khz __initdata;
 static u8 vmware_hypercall_mode     __ro_after_init;
 
 unsigned long vmware_hypercall_slow(unsigned long cmd,
@@ -137,7 +137,7 @@ static inline int __vmware_platform(void)
 	return eax != UINT_MAX && ebx == VMWARE_HYPERVISOR_MAGIC;
 }
 
-static unsigned long vmware_get_tsc_khz(void)
+static unsigned int __init vmware_get_tsc_khz(void)
 {
 	return vmware_tsc_khz;
 }
@@ -419,8 +419,8 @@ static void __init vmware_platform_setup(void)
 		}
 
 		vmware_tsc_khz = tsc_khz;
-		x86_platform.calibrate_tsc = vmware_get_tsc_khz;
-		x86_platform.calibrate_cpu = vmware_get_tsc_khz;
+		x86_init.hyper.get_tsc_khz = vmware_get_tsc_khz;
+		x86_init.hyper.get_cpu_khz = vmware_get_tsc_khz;
 
 		/* Skip lapic calibration since we know the bus frequency. */
 		apic_set_timer_frequency_hz(ecx, "VMware hypervisor");
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 615a1f25c83a..595cd28f9a9f 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -68,7 +68,7 @@ static void __init jailhouse_timer_init(void)
 	apic_set_timer_frequency_khz(setup_data.v1.apic_khz, "Jailhouse hypervisor");
 }
 
-static unsigned long jailhouse_get_tsc(void)
+static unsigned int __init jailhouse_get_tsc(void)
 {
 	return precalibrated_tsc_khz;
 }
@@ -210,8 +210,6 @@ static void __init jailhouse_init_platform(void)
 	x86_init.mpparse.parse_smp_cfg		= jailhouse_parse_smp_config;
 	x86_init.pci.arch_init			= jailhouse_pci_arch_init;
 
-	x86_platform.calibrate_cpu		= jailhouse_get_tsc;
-	x86_platform.calibrate_tsc		= jailhouse_get_tsc;
 	x86_platform.get_wallclock		= jailhouse_get_wallclock;
 	x86_platform.legacy.rtc			= 0;
 	x86_platform.legacy.warm_reset		= 0;
@@ -293,5 +291,7 @@ const struct hypervisor_x86 x86_hyper_jailhouse __refconst = {
 	.detect			= jailhouse_detect,
 	.init.init_platform	= jailhouse_init_platform,
 	.init.x2apic_available	= jailhouse_x2apic_available,
+	.init.get_tsc_khz	= jailhouse_get_tsc,
+	.init.get_cpu_khz	= jailhouse_get_tsc,
 	.ignore_nopv		= true,
 };
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index cb3d0ca1fa22..4f8299303a19 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -136,7 +136,7 @@ static inline void kvm_sched_clock_init(bool stable)
  * poll of guests can be running and trouble each other. So we preset
  * lpj here
  */
-static unsigned long kvm_get_tsc_khz(void)
+static unsigned int __init kvm_get_tsc_khz(void)
 {
 	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	return pvclock_tsc_khz(this_cpu_pvti());
@@ -343,8 +343,8 @@ void __init kvmclock_init(void)
 	flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
 	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
 
-	x86_platform.calibrate_tsc = kvm_get_tsc_khz;
-	x86_platform.calibrate_cpu = kvm_get_tsc_khz;
+	x86_init.hyper.get_tsc_khz = kvm_get_tsc_khz;
+	x86_init.hyper.get_cpu_khz = kvm_get_tsc_khz;
 	x86_platform.get_wallclock = kvm_get_wallclock;
 	x86_platform.set_wallclock = kvm_set_wallclock;
 #ifdef CONFIG_X86_LOCAL_APIC
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index f3febe406fa8..7f1ca6df0004 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1451,13 +1451,17 @@ static int __init init_tsc_clocksource(void)
 device_initcall(init_tsc_clocksource);
 
 static bool __init determine_cpu_tsc_frequencies(bool early,
+						 unsigned int known_cpu_khz,
 						 unsigned int known_tsc_khz)
 {
 	/* Make sure that cpu and tsc are not already calibrated */
 	WARN_ON(cpu_khz || tsc_khz);
 
 	if (early) {
-		cpu_khz = x86_platform.calibrate_cpu();
+		if (known_cpu_khz)
+			cpu_khz = known_cpu_khz;
+		else
+			cpu_khz = x86_platform.calibrate_cpu();
 		if (known_tsc_khz)
 			tsc_khz = known_tsc_khz;
 		else
@@ -1514,7 +1518,7 @@ static void __init tsc_enable_sched_clock(void)
 
 void __init tsc_early_init(void)
 {
-	unsigned int known_tsc_khz = 0;
+	unsigned int known_cpu_khz = 0, known_tsc_khz = 0;
 
 	if (!boot_cpu_has(X86_FEATURE_TSC))
 		return;
@@ -1522,22 +1526,33 @@ void __init tsc_early_init(void)
 	if (is_early_uv_system())
 		return;
 
+	if (x86_init.hyper.get_cpu_khz)
+		known_cpu_khz = x86_init.hyper.get_cpu_khz();
+
 	if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC))
 		known_tsc_khz = snp_secure_tsc_init();
 	else if (boot_cpu_has(X86_FEATURE_TDX_GUEST))
 		known_tsc_khz = tdx_tsc_init();
 
+	/*
+	 * If the TSC frequency wasn't provided by trusted firmware, try to get
+	 * it from the hypervisor (which is untrusted when running as a CoCo guest).
+	 */
+	if (!known_tsc_khz && x86_init.hyper.get_tsc_khz)
+		known_tsc_khz = x86_init.hyper.get_tsc_khz();
+
 	/*
 	 * Ignore the user-provided TSC frequency if the exact frequency was
-	 * obtained from trusted firmware, as the user-provided frequency is
-	 * intended as a "starting point", not a known, guaranteed frequency.
+	 * obtained from trusted firmware or the hypervisor, as the user-
+	 * provided frequency is intended as a "starting point", not a known,
+	 * guaranteed frequency.
 	 */
 	if (!known_tsc_khz)
 		known_tsc_khz = tsc_early_khz;
 	else if (tsc_early_khz)
-		pr_err("Ignoring 'tsc_early_khz' in favor of trusted firmware.\n");
+		pr_err("Ignoring 'tsc_early_khz' in favor of firmware/hypervisor.\n");
 
-	if (!determine_cpu_tsc_frequencies(true, known_tsc_khz))
+	if (!determine_cpu_tsc_frequencies(true, known_cpu_khz, known_tsc_khz))
 		return;
 	tsc_enable_sched_clock();
 }
@@ -1558,7 +1573,7 @@ void __init tsc_init(void)
 
 	if (!tsc_khz) {
 		/* We failed to determine frequencies earlier, try again */
-		if (!determine_cpu_tsc_frequencies(false, 0)) {
+		if (!determine_cpu_tsc_frequencies(false, 0, 0)) {
 			mark_tsc_unstable("could not calculate TSC khz");
 			setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
 			return;
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index d62c14334b35..1adb44fdddb2 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -38,7 +38,7 @@
 static u64 xen_sched_clock_offset __read_mostly;
 
 /* Get the TSC speed from Xen */
-static unsigned long xen_tsc_khz(void)
+static unsigned int __init xen_tsc_khz(void)
 {
 	struct pvclock_vcpu_time_info *info =
 		&HYPERVISOR_shared_info->vcpu_info[0].time;
@@ -569,7 +569,7 @@ static void __init xen_init_time_common(void)
 	static_call_update(pv_steal_clock, xen_steal_clock);
 	paravirt_set_sched_clock(xen_sched_clock);
 
-	x86_platform.calibrate_tsc = xen_tsc_khz;
+	x86_init.hyper.get_tsc_khz = xen_tsc_khz;
 	x86_platform.get_wallclock = xen_get_wallclock;
 }
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385284.1627782 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dm-000177-Re; Thu, 06 Aug 2026 23:36:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385284.1627782; Thu, 06 Aug 2026 23:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dm-00016d-M3; Thu, 06 Aug 2026 23:36:46 +0000
Received: by outflank-mailman (input) for mailman id 1385284;
 Thu, 06 Aug 2026 23:36:45 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3ihp1agYKCe0hTPcYRVddVaT.RdbmTc-STkTaaXhih.mTcegdYTRi.dgV@flex--seanjc.bounces.google.com>)
 id 1ws7dl-0000zb-1s
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dk-00GcT3-Eh
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:44 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3ihp1agYKCe0hTPcYRVddVaT.RdbmTc-STkTaaXhih.mTcegdYTRi.dgV@flex--seanjc.bounces.google.com>)
 id 6a751a63-5cb7-0a2a0a5109dd-0a2a45099b3a-14
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:44 +0200
Received: from [209.85.216.71] (helo=mail-pj1-f71.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3ihp1agYKCe0hTPcYRVddVaT.RdbmTc-STkTaaXhih.mTcegdYTRi.dgV@flex--seanjc.bounces.google.com>)
 id 6a751a8a-be1a-0a2a45090019-d155d847b8c1-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:44 +0200
Received: by mail-pj1-f71.google.com with SMTP id
 98e67ed59e1d1-38e667368f0so4358162a91.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059402; x=1786664202; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=wbY0NuQ4jmVaTb967BiKKQEFZ81rzIFWsnI6s/GLKnk=;
        b=wU0/80f/2tfxf6oVmy6NECSHzNhhT0Ndg5wkXXqKAGhqPiuL+EINjJO3oVS8DLXj1p
         /HUcwVU/OTHEEuAovapscHBEkt7Wtwu1nYVMGW2ob28WO1fsIRTFGqIBLPV+2D/iMSBT
         XyYnb2rxXP0GLJ6De2Cjka/B7+TO0fHWSmmGQnHMcRK/oxwRzEEVSaZdC6v56cipmKn6
         b0ZGtLc0UiD8gwnViVlsB9S/ClDqx2tTPJFqH2XulN8Yr7nfRpwy3Tfo+PAyOkgn9/Z+
         5ynifEuCAm/y2nu8IBT2YeRs7dyv79e5r5QY91HeBIswEB7wL7XMWJXj+jbHGl2+PqWK
         t9Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059402; x=1786664202;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=wbY0NuQ4jmVaTb967BiKKQEFZ81rzIFWsnI6s/GLKnk=;
        b=CZbx8Mx958nQAE7y4AfTwtE5qYUn2BHzwCvm02wpOrzwOBf44xo5cPY+jeiNiI4T1P
         RWaatoZ/4WOy05zk1ABLwL4QiikvEXff9UM1kIlaZ6azwG6t+LPsNsOfJ/jebj9IrAiM
         V4h/hD7thojso+ZJ7POOIDBx083F1DNHLOx+Us1B73PlB9X5UC48mh5V1pRmEiaNv5Uz
         KwhEkull4TmWOkd/XWrgcoM8lCLPue1dQvlQ7QBpi82/Pef6kA1ZVSjxIlroHyGxCHp1
         EW+kqX1K8Up8LpqJU4T12YgKsYICxqnsRJ5Lba78zQZ6udunjfsDCAzlpCHWkHN5uixx
         vr9g==
X-Forwarded-Encrypted: i=1; AHgh+Ro10JlYN7uXMq5wdLHHq8IBB/8dlHc9PEDgagA202qntvLP6zSx07oBNhOUFPjwMubOmkafvTSvGt4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwrUa3B3M5+sxN7NrfYUw6JHoKaGB/vhwafgGBarCgAm53lpsLq
	ryrXsQrTp6dyF/4g8sbZT3731EXww3qFuPAD4HRu/ThidEL37fWsSeqrl8pY5YL7TvjPT8jc5or
	bThwn2g==
X-Received: from pjbcv18.prod.google.com ([2002:a17:90a:fd12:b0:38e:7f2c:2c4b])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:264c:b0:37f:e326:6557
 with SMTP id 98e67ed59e1d1-3903c598e8amr20096574a91.4.1786059402046; Thu, 06
 Aug 2026 16:36:42 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:32 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-16-seanjc@google.com>
Subject: [PATCH v6 15/51] x86/tsc: Kill off x86_platform_ops.calibrate_{cpu,tsc}()
 hooks
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-bad1c0/1786059404-BEAD8034-89559CF6/0/0
X-purgate-type: clean
X-purgate-size: 5639

Now that getting the CPU and/or TSC frequencies from the hypervisor uses
dedicated hooks, drop x86_platform_ops.calibrate_{cpu,tsc}() and instead
directly invoke the correct helper at each phase of (re)calibration.  In
addition to eliminating unnecessary code, this makes it a bit more obvious
when the "late" path invokes pit_hpet_ptimer_calibrate_cpu() instead of
x86_platform_ops.calibrate_cpu().

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/tsc.h      |  2 --
 arch/x86/include/asm/x86_init.h |  4 ----
 arch/x86/kernel/tsc.c           | 28 ++++++++++++----------------
 arch/x86/kernel/x86_init.c      |  2 --
 4 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index b6b86e24e1bf..c09ec485abcd 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -95,8 +95,6 @@ extern void mark_tsc_unstable(char *reason);
 extern int unsynchronized_tsc(void);
 extern int check_tsc_unstable(void);
 extern void mark_tsc_async_resets(char *reason);
-extern unsigned long native_calibrate_cpu_early(void);
-extern unsigned long native_calibrate_tsc(void);
 extern unsigned long long native_sched_clock_from_tsc(u64 tsc);
 
 extern int tsc_clocksource_reliable;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 0c89bf40f507..e879e6e83428 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -295,8 +295,6 @@ struct x86_hyper_runtime {
 
 /**
  * struct x86_platform_ops - platform specific runtime functions
- * @calibrate_cpu:		calibrate CPU
- * @calibrate_tsc:		calibrate TSC, if different from CPU
  * @get_wallclock:		get time from HW clock like RTC etc.
  * @set_wallclock:		set time back to HW clock
  * @iommu_shutdown:		set by an IOMMU driver for shutdown if necessary
@@ -320,8 +318,6 @@ struct x86_hyper_runtime {
  * @guest:			guest incarnations callbacks
  */
 struct x86_platform_ops {
-	unsigned long (*calibrate_cpu)(void);
-	unsigned long (*calibrate_tsc)(void);
 	void (*get_wallclock)(struct timespec64 *ts);
 	int (*set_wallclock)(const struct timespec64 *ts);
 	void (*iommu_shutdown)(void);
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index f42872c9ae99..1d41ef1db27c 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -672,7 +672,7 @@ int cpuid_get_tsc_info(struct cpuid_tsc_info *info)
  * native_calibrate_tsc - determine TSC frequency
  * Determine TSC frequency via CPUID, else return 0.
  */
-unsigned long native_calibrate_tsc(void)
+static unsigned long native_calibrate_tsc(void)
 {
 	struct cpuid_tsc_info info;
 
@@ -904,7 +904,7 @@ static unsigned long pit_hpet_ptimer_calibrate_cpu(void)
 /**
  * native_calibrate_cpu_early - can calibrate the cpu early in boot
  */
-unsigned long native_calibrate_cpu_early(void)
+static unsigned long native_calibrate_cpu_early(void)
 {
 	unsigned long flags, fast_calibrate = cpu_khz_from_cpuid();
 
@@ -918,7 +918,7 @@ unsigned long native_calibrate_cpu_early(void)
 	return fast_calibrate;
 }
 
-
+#ifndef CONFIG_SMP
 /**
  * native_calibrate_cpu - calibrate the cpu
  */
@@ -931,6 +931,7 @@ static unsigned long native_calibrate_cpu(void)
 
 	return tsc_freq;
 }
+#endif
 
 void recalibrate_cpu_khz(void)
 {
@@ -943,8 +944,8 @@ void recalibrate_cpu_khz(void)
 	if (WARN_ON_ONCE(cpu_feature_enabled(X86_FEATURE_TSC_KNOWN_FREQ)))
 		return;
 
-	cpu_khz = x86_platform.calibrate_cpu();
-	tsc_khz = x86_platform.calibrate_tsc();
+	cpu_khz = native_calibrate_cpu();
+	tsc_khz = native_calibrate_tsc();
 	if (tsc_khz == 0)
 		tsc_khz = cpu_khz;
 	else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
@@ -1458,17 +1459,19 @@ static bool __init determine_cpu_tsc_frequencies(bool early,
 	WARN_ON(cpu_khz || tsc_khz);
 
 	if (early) {
+		/*
+		 * Early CPU calibration can only use methods that are available
+		 * early in boot (obviously).
+		 */
 		if (known_cpu_khz)
 			cpu_khz = known_cpu_khz;
 		else
-			cpu_khz = x86_platform.calibrate_cpu();
+			cpu_khz = native_calibrate_cpu_early();
 		if (known_tsc_khz)
 			tsc_khz = known_tsc_khz;
 		else
-			tsc_khz = x86_platform.calibrate_tsc();
+			tsc_khz = native_calibrate_tsc();
 	} else {
-		/* We should not be here with non-native cpu calibration */
-		WARN_ON(x86_platform.calibrate_cpu != native_calibrate_cpu);
 		cpu_khz = pit_hpet_ptimer_calibrate_cpu();
 	}
 
@@ -1571,13 +1574,6 @@ void __init tsc_init(void)
 		return;
 	}
 
-	/*
-	 * native_calibrate_cpu_early can only calibrate using methods that are
-	 * available early in boot.
-	 */
-	if (x86_platform.calibrate_cpu == native_calibrate_cpu_early)
-		x86_platform.calibrate_cpu = native_calibrate_cpu;
-
 	if (!tsc_khz) {
 		/* We failed to determine frequencies earlier, try again */
 		if (!determine_cpu_tsc_frequencies(false, 0, 0)) {
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 252c5827d063..b7a48e622f48 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -147,8 +147,6 @@ static void enc_kexec_finish_noop(void) {}
 static bool is_private_mmio_noop(u64 addr) {return false; }
 
 struct x86_platform_ops x86_platform __ro_after_init = {
-	.calibrate_cpu			= native_calibrate_cpu_early,
-	.calibrate_tsc			= native_calibrate_tsc,
 	.get_wallclock			= mach_get_cmos_time,
 	.set_wallclock			= mach_set_cmos_time,
 	.iommu_shutdown			= iommu_shutdown_noop,
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385295.1627792 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dr-0001tl-CF; Thu, 06 Aug 2026 23:36:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385295.1627792; Thu, 06 Aug 2026 23:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dr-0001so-2g; Thu, 06 Aug 2026 23:36:51 +0000
Received: by outflank-mailman (input) for mailman id 1385295;
 Thu, 06 Aug 2026 23:36:49 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3jhp1agYKCfElXTgcVZhhZeX.VhfqXg-WXoXeeblml.qXgikhcXVm.hkZ@flex--seanjc.bounces.google.com>)
 id 1ws7dp-0001fJ-7C
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7do-00GcaU-KN
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:48 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3jhp1agYKCfElXTgcVZhhZeX.VhfqXg-WXoXeeblml.qXgikhcXVm.hkZ@flex--seanjc.bounces.google.com>)
 id 6a751a70-bab6-0a2a0a5309dd-0a2a450ae97a-20
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:48 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3jhp1agYKCfElXTgcVZhhZeX.VhfqXg-WXoXeeblml.qXgikhcXVm.hkZ@flex--seanjc.bounces.google.com>)
 id 6a751a8f-f2d2-0a2a450a0019-d155d2c6c9e2-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:48 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-84870e7f498so2970699b3a.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059406; x=1786664206; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=bafmbn4x7WGy8QY/EzYypINgs3wQBC6UPHmanD+knFs=;
        b=rNz8Q677rJoZ53N2qPQKXwQ4hihCKOhYUY0cOKrxQCTX9Sv4UtbSK8zEcLdS0x5dOx
         T2xb4CBhnfLY02gHuc07ZH71Rypw4KgmKocMe3LutsWkBY7sd2SvJfZVO7YEUjrsk6z4
         u99+lEP4h5AmoxeFSSxhmvlf0HvdDsByL5MtKQh56Q8TT9dh5tlh9EzPE/0YMtZAjrmK
         vzKEYupH+3jWbRaHa8ItwDpPi5WcyBqPz8cS/v6hmBbkfL9yGpeiXEF8+7v5DnhkRURZ
         PQppwq2wiGHAiKAFR0i3ptxJdVBoW9BPr52oompLchMKyuj1pMlIOaDCjeauPxlg5Qfj
         ZYOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059406; x=1786664206;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=bafmbn4x7WGy8QY/EzYypINgs3wQBC6UPHmanD+knFs=;
        b=II875WJVKpdRzEtpR9yD6JVz+pW1GHLdCAI9iFgnHvB1YdY8igW6zLYZqsrC+1YbwB
         zbyv158JDlaECfww9tySMqLS2PwLsn9KoEfwtK1lrYTnXi2z6PriwJKfO9Iqf0tZePzo
         bhWlAePf3AH5yoWs2UDeE3Q/RId268AJBB7SoJZfvZNhVh4v5Y+IUzrR2CA2JjeV8zqG
         9zBSX7r54rng+Y/kSCBRN61q9uvFTzeqDxEv9EduFituVavHZbnbb3Y2tS94PNBl2cRE
         /uLU71mxHlloRC+Dm3D8evJ0fhbgzD9Rgz9YWLRF1wxijrcbSxcMFuo36ygEKwtXBhVF
         IOnQ==
X-Forwarded-Encrypted: i=1; AHgh+RobKBeDVUH67WbiI62fAP+DbH0Fk7wnF9ceDVzVwsow4+YpSzzZUKPUETs/VJnsA8+RKjzlLrTGoPI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzcAlwINBmIij8UKpae1EU5T2tNBB5l0GSpxfDrOCNP0zXwuxyX
	wepC5m2ge3NMUfmQRybnoEicQ+q6l5hr9ubCbNBQ5uJdaDsXxknxE3gcOPXl959ifSkIKupHQD4
	Z9ti3UA==
X-Received: from pfks7.prod.google.com ([2002:a05:6a00:1947:b0:84e:2400:dc7d])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:409b:b0:842:5b63:6112
 with SMTP id d2e1a72fcca58-84f2e12d036mr22581852b3a.32.1786059406261; Thu, 06
 Aug 2026 16:36:46 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:35 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-19-seanjc@google.com>
Subject: [PATCH v6 18/51] x86/kvmclock: Rename kvm_get_tsc_khz() to kvmclock_get_tsc_khz()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059408-508CDCFC-68200CFA/0/0
X-purgate-type: clean
X-purgate-size: 1630

Rename kvm_get_tsc_khz() to kvmclock_get_tsc_khz() in anticipation of
adding support for getting TSC info from PV CPUID, i.e. in a KVM specific
way, but without non-kvmclock.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 35a879d33e9e..061a22d31dea 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -136,7 +136,7 @@ static inline void kvm_sched_clock_init(bool stable)
  * poll of guests can be running and trouble each other. So we preset
  * lpj here
  */
-static unsigned int __init kvm_get_tsc_khz(void)
+static unsigned int __init kvmclock_get_tsc_khz(void)
 {
 	return pvclock_tsc_khz(this_cpu_pvti());
 }
@@ -146,7 +146,7 @@ static void __init kvm_get_preset_lpj(void)
 	unsigned long khz;
 	u64 lpj;
 
-	khz = kvm_get_tsc_khz();
+	khz = kvmclock_get_tsc_khz();
 
 	lpj = ((u64)khz * 1000);
 	do_div(lpj, HZ);
@@ -342,8 +342,8 @@ void __init kvmclock_init(void)
 	flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
 	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
 
-	x86_init.hyper.get_tsc_khz = kvm_get_tsc_khz;
-	x86_init.hyper.get_cpu_khz = kvm_get_tsc_khz;
+	x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
+	x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
 	x86_platform.get_wallclock = kvm_get_wallclock;
 	x86_platform.set_wallclock = kvm_set_wallclock;
 #ifdef CONFIG_X86_LOCAL_APIC
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385304.1627800 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dt-0002NH-KU; Thu, 06 Aug 2026 23:36:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385304.1627800; Thu, 06 Aug 2026 23:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dt-0002N7-GK; Thu, 06 Aug 2026 23:36:53 +0000
Received: by outflank-mailman (input) for mailman id 1385304;
 Thu, 06 Aug 2026 23:36:52 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3kRp1agYKCfQoaWjfYckkcha.Ykitaj-Zarahheopo.tajlnkfaYp.knc@flex--seanjc.bounces.google.com>)
 id 1ws7ds-0002Ay-Bw
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dr-005BVk-OV
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:51 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3kRp1agYKCfQoaWjfYckkcha.Ykitaj-Zarahheopo.tajlnkfaYp.knc@flex--seanjc.bounces.google.com>)
 id 6a751a63-5cb7-0a2a0a5109dd-0a2a45099b3a-22
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:51 +0200
Received: from [209.85.216.71] (helo=mail-pj1-f71.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3kRp1agYKCfQoaWjfYckkcha.Ykitaj-Zarahheopo.tajlnkfaYp.knc@flex--seanjc.bounces.google.com>)
 id 6a751a92-be1a-0a2a45090019-d155d847f0b3-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:51 +0200
Received: by mail-pj1-f71.google.com with SMTP id
 98e67ed59e1d1-38e11baa66eso2407878a91.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059410; x=1786664210; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=eYIjdKzjgH3nVD0iNsx5sVBVp8XFdFFsnkR62+s/p+Q=;
        b=E5LLqXiTKfzr8w4IqDOo0QY+iuqgo807Di4c0I7wK/4WJ1kEtAr1iBNZ5Co/adFgd7
         g9urHpdWNoBF625p4u+bzb+hRk+OsRZQj/yhe8zZBiPKaahmUMqCCDjaeCKmjMmz6ye9
         dmp2/sMqpu4rCeGpyX4nHdggjfTtmecinVOb9X30S3uUgLgVqD6L7eh9E2iSllqOm8bN
         Sf7tOm0pAb7a2Q6O0zvos0/+MTdvhdcN0ODVxx4Wmx7w4JQUKb2kULU2pH3ugQ1IHSlg
         ICwAJW3Uv1iyLFl81CYS6S03Vhfmll9oYOhowG6BqV0g87YU8XYGxkl417TzFIQvUwE9
         XN9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059410; x=1786664210;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=eYIjdKzjgH3nVD0iNsx5sVBVp8XFdFFsnkR62+s/p+Q=;
        b=aojaK7+BgMLo+SOsVlGT+yu67L3XJcLffNpnPSTr/pq407ZEGFlr8OcvWqVJR/u7gk
         TcH4sHntzj2BasUFEUGh0RQYHyvKWhbj+GyraKQ82vJSeYQQ8iGAFR9JQx09jSwU/+if
         JrKJtbAiaK+WPapRrMzjG+YjdpDTlcTVjAVBU4V97KxLVF78fkTUeb46nd2iDdn0r6W8
         uDWm+agfUHrhoWv43Walgd3hXpbOUPoFizIWW/k9c4aDuRh4lyFbcNHP5tdvVPYBU14i
         GnkyZ4tGAJ1gZYVs6JlE6PjEIQUK1kbdBfcXeKc+GtWMQ/MREtccVZBINX9LPOX/6e02
         SHcg==
X-Forwarded-Encrypted: i=1; AHgh+RqQUZ8OwWDYlSNYhqZGCYaWsTyA9pOE3f+blw6hStF5CEFjKPFwnBxCsB4KHiIUGEWPCjST6DM99lk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpTHW9Vso1wNanHWQpCnJQ1IF6wDKoXCGdmmoFjwtK8hy9zZdN
	ugB21nk58bD7586574X8ENdSBaZRz7f0LI6rpAlMVoFOMW0/SmGR/lrpmWdNvqqnUcYgaU/Kad2
	1bCA+YQ==
X-Received: from pjji3.prod.google.com ([2002:a17:90a:6503:b0:381:224:393a])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:c106:b0:38e:250b:122f
 with SMTP id 98e67ed59e1d1-3909d8d5993mr5453558a91.16.1786059409368; Thu, 06
 Aug 2026 16:36:49 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:37 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-21-seanjc@google.com>
Subject: [PATCH v6 20/51] KVM: x86: Officially define CPUID 0x40000010 as PV
 Timing Info (TSC and Bus)
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-bad1c0/1786059411-BDAC0034-07F8BD3C/0/0
X-purgate-type: clean
X-purgate-size: 3769

From: David Woodhouse <dwmw@amazon.co.uk>

Formally define and document CPUID 0x40000010 as providing TSC and local
APIC bus frequency information for KVM's PV CPUID range.  Way back in
2008, VMware proposed (https://lkml.org/lkml/2008/10/1/246) carving out a
range of CPUID leaves for use by hypervisors.  While the broader proposal
from VMware was mostly shot down in flames, use of CPUID 0x40000010 to
provide TSC and local APIC bus frequency information survived and made it's
way into multiple guest operating systems.

XNU unconditionally assumes CPUID 0x40000010 contains the frequency
information, if it's present on any hypervisor:

  https://github.com/apple/darwin-xnu/blob/main/osfmk/i386/cpuid.c

As does FreeBSD:

  https://github.com/freebsd/freebsd-src/commit/4a432614f68

More importantly, QEMU (the de facto "reference" VMM for KVM) has
conditionally provided timing information in CPUID 0x40000010 for almost
9 years, since commit 9954a1582e ("x86-KVM: Supply TSC and APIC clock
rates to guest like VMWare").

So at this point it would be daft for KVM (or any hypervisor) to expose
0x40000010 for any *other* content.  Officially carve out and define the
CPUID leaf so that Linux-as-a-guest can follow suit and pull TSC and Local
APIC Bus frequency information from CPUID.

Defer providing userspace with the necessary information needed to
precisely and accurately enumerate the _actual_ configured TSC frequency
to the guest (that exact information, along with the scaled ratio, isn't
exposed to userspace).  As evidenced by QEMU, providing CPUID 0x40000010
without help from KVM is entirely possible, just not ideal.

Link: https://lore.kernel.org/all/ea0d7f43d910cee9600b254e303f468722fa355b.camel@infradead.org
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
[sean: drop KVM filling of CPUID, add documentation, massage changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 Documentation/virt/kvm/x86/cpuid.rst | 12 ++++++++++++
 arch/x86/include/uapi/asm/kvm_para.h | 11 +++++++++++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/virt/kvm/x86/cpuid.rst b/Documentation/virt/kvm/x86/cpuid.rst
index bda3e3e737d7..a5ee8ff052ce 100644
--- a/Documentation/virt/kvm/x86/cpuid.rst
+++ b/Documentation/virt/kvm/x86/cpuid.rst
@@ -122,3 +122,15 @@ KVM_HINTS_REALTIME 0            guest checks this feature bit to
                                 preempted for an unlimited time
                                 allowing optimizations
 ================== ============ =================================
+
+function: KVM_CPUID_TIMING_INFO (0x40000010)
+
+returns::
+
+   eax = (Virtual) TSC frequency in kHz
+   ebx = (Virtual) Bus (local APIC timer) frequency in kHz
+   ecx = 0 (Reserved)
+   edx = 0 (Reserved)
+
+Note, KVM only defines the semantics of KVM_CPUID_TIMING_INFO; KVM does NOT
+advertise support via KVM_GET_SUPPORTED_CPUID.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h
index a1efa7907a0b..c3a384711f3a 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -44,6 +44,17 @@
  */
 #define KVM_FEATURE_CLOCKSOURCE_STABLE_BIT	24
 
+/*
+ * The timing information leaf provides TSC and local APIC timer frequency
+ * information to the guest.  Note, userspace is responsible for filling the
+ * leaf with the correct information.
+ *
+ *  # EAX: (Virtual) TSC frequency in kHz.
+ *  # EBX: (Virtual) Bus (local APIC timer) frequency in kHz.
+ *  # ECX, EDX: Reserved (must be zero).
+ */
+#define KVM_CPUID_TIMING_INFO	0x40000010
+
 #define MSR_KVM_WALL_CLOCK  0x11
 #define MSR_KVM_SYSTEM_TIME 0x12
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385307.1627807 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dv-0002fV-4a; Thu, 06 Aug 2026 23:36:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385307.1627807; Thu, 06 Aug 2026 23:36:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7du-0002en-UD; Thu, 06 Aug 2026 23:36:54 +0000
Received: by outflank-mailman (input) for mailman id 1385307;
 Thu, 06 Aug 2026 23:36:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3khp1agYKCfUpbXkgZdlldib.Zljubk-absbiifpqp.ubkmolgbZq.lod@flex--seanjc.bounces.google.com>)
 id 1ws7dt-0002Ml-FF
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ds-00Gcdg-SP
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:52 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3khp1agYKCfUpbXkgZdlldib.Zljubk-absbiifpqp.ubkmolgbZq.lod@flex--seanjc.bounces.google.com>)
 id 6a751a4d-e002-0a2a0a5209dd-0a2a45078cde-40
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:52 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3khp1agYKCfUpbXkgZdlldib.Zljubk-absbiifpqp.ubkmolgbZq.lod@flex--seanjc.bounces.google.com>)
 id 6a751a93-b4ea-0a2a45070019-d155d2c5e5a2-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:52 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84e4ef9a74aso4706501b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059411; x=1786664211; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:reply-to:from
         :to:cc:subject:date:message-id:reply-to:content-type;
        bh=GbCVidvwQkuTYRlTXFKmfz6LBshlnXLBUNEqveo1L6E=;
        b=CSCErPHu++GbfzI1KqY2HMp3e75UFu3AB5KOlsWAiRQTbuPqmt+lmQSiUGA/61iJtl
         J5fh5giRXJbwBgjcfI9RkXhsPlFnjfJEvxBfsJWyyreULgT8Mpz4VAabaepS+G73xuEM
         Y3QkqWD4RcxEG1vkthJUggExzKUXcNWk440LHra7kW/Snl2uER9dcLP6pXdDhh01Jk7u
         ljaCGbAJLI/UrGV6tOsQN9m9trzNzsUngAqqwiXmXLgxS5Gl7LzUtxRQhfGDR9vkCox7
         Salk9YHE2TxAHmKgEmZlymHjp92YZ983s8K6a+fEqFbFMdme+s19nHCaf4bjWXZJPO8C
         ujuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059411; x=1786664211;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:reply-to
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=GbCVidvwQkuTYRlTXFKmfz6LBshlnXLBUNEqveo1L6E=;
        b=MMJUd3+Mb4i9+oIwHhTE6oakdUR3BiyYKBhLI8KvnSsGZFQ1fy8bzfg911QeOmM66V
         /D6kFQjBTWQOkKXygJi0N9TOEYDWbTNC22Ybec+ZcShE/fC6bwEX3/G4xpjI9DlAD7td
         tYj2x8XNdmEbIqDw7DDsdRnYRJGj1jqYDLp2IksmABAZ0NylIr5QcqX4WCWjkCa8b9G7
         diwHBoX7rZP8JEL7dq+UhrZI69sRLIt06A9dftzEGgVd16CKy0NvyelvNgzqFYJjutai
         WtuZBsizVDM7rp05F9NgtSui4TL4wGvLpNcZV4peCHK+ZfVduoz0s/fLohXr7OV42atq
         40/A==
X-Forwarded-Encrypted: i=1; AHgh+RonBZB76IHxKDosIlXJMTlZKWKJVdVVB4H+Cic+SZRW+UrbCpiaUKIh1o1mUqF9y817No/DZGtDyzc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzSAQDp1YBXPwXNtp0uRcLtz1eoQbazySYmiFJ+5amaZKpM+Iqa
	1rELmb4Rsi985GKjxDF+1jSPM+WglFVBu7gHiNNMdyyTQTh+PplEexdtW5crzRMubdJqhjuXLNX
	+BOHzRQ==
X-Received: from pfbll6.prod.google.com ([2002:a05:6a00:7286:b0:84e:a25:1e6b])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3a12:b0:848:354f:4f8f
 with SMTP id d2e1a72fcca58-84f2dff3015mr20822585b3a.22.1786059410525; Thu, 06
 Aug 2026 16:36:50 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:38 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-22-seanjc@google.com>
Subject: [PATCH v6 21/51] x86/kvm: Obtain TSC frequency from PV CPUID if present
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-ef75cf/1786059412-354C3AE4-331BC121/0/0
X-purgate-type: clean
X-purgate-size: 5045

From: David Woodhouse <dwmw@amazon.co.uk>

In https://lkml.org/lkml/2008/10/1/246 a proposal was made for generic
CPUID conventions across hypervisors. It was mostly shot down in flames,
but the leaf at 0x40000010 containing timing information didn't die.

It's used by XNU and FreeBSD guests under all hypervisors=C2=B9=C2=B2 to de=
termine
the TSC frequency, and also exposed by the EC2 Nitro hypervisor (as
well as, presumably, VMware). FreeBSD's Bhyve is probably just about
to start exposing it too.

Use it under KVM to obtain the TSC frequency more accurately, instead of
reverse-calculating the frequency from the mul/shift values in the KVM
clock.  Use the information to get the CPU frequency as well (kvmclock
feeds in kvm_get_tsc_khz() for both TSC and CPU calibration), as the info
from CPUID is superior in every way; whether or not kvmclock should be
overriding CPU calibration in the first place is an entirely different
question.

Use the info from CPUID even if the user explicitly disables kvmclock, or
if it's unsupported.  The PV CPUID leaf has no dependency on kvmclock, and
is in fact more useful if kvmclock is disabled since the kernel won't be
able to use kvmclock to derive a derive the TSC frequency.

Before:
[    0.000020] tsc: Detected 2900.014 MHz processor

After:
[    0.000020] tsc: Detected 2900.015 MHz processor

$ cpuid -1 -l 0x40000010
CPU:
   hypervisor generic timing information (0x40000010):
      TSC frequency (Hz) =3D 2900015
      bus frequency (Hz) =3D 1000000

Note!  *Independently* query for non-null get_{cpu,tsc}_khz() overrides so
that kvmclock doesn't clobber x86_init.hyper.get_cpu_khz() if/when KVM adds
support for getting the CPU frequency separately from the TSC frequency.

=C2=B9 https://github.com/apple/darwin-xnu/blob/main/osfmk/i386/cpuid.c
=C2=B2 https://github.com/freebsd/freebsd-src/commit/4a432614f68

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvm.c      | 33 +++++++++++++++++++++++++++++++++
 arch/x86/kernel/kvmclock.c |  6 ++++--
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 5b554e480c0e..8ed02f4f5775 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -49,6 +49,8 @@
 #include <asm/svm.h>
 #include <asm/e820/api.h>
=20
+static unsigned int kvm_tsc_khz_cpuid __initdata;
+
 DEFINE_STATIC_KEY_FALSE_RO(kvm_async_pf_enabled);
=20
 static int kvmapf =3D 1;
@@ -913,6 +915,21 @@ bool kvm_para_available(void)
 }
 EXPORT_SYMBOL_GPL(kvm_para_available);
=20
+static u32 __init kvm_cpuid_timing_info_leaf(void)
+{
+	u32 base =3D kvm_cpuid_base();
+
+	if (!base || cpuid_eax(base) < (base | KVM_CPUID_TIMING_INFO))
+		return 0;
+
+	return base | KVM_CPUID_TIMING_INFO;
+}
+
+static unsigned int __init kvm_get_tsc_khz(void)
+{
+	return kvm_tsc_khz_cpuid;
+}
+
 unsigned int kvm_arch_para_features(void)
 {
 	return cpuid_eax(kvm_cpuid_base() | KVM_CPUID_FEATURES);
@@ -962,6 +979,7 @@ static void __init kvm_init_platform(void)
 		.mask_lo =3D (u32)(~(SZ_4G - tolud - 1)) | MTRR_PHYSMASK_V,
 		.mask_hi =3D (BIT_ULL(boot_cpu_data.x86_phys_bits) - 1) >> 32,
 	};
+	u32 timing_info_leaf;
=20
 	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
 	    kvm_para_has_feature(KVM_FEATURE_MIGRATION_CONTROL)) {
@@ -1009,6 +1027,21 @@ static void __init kvm_init_platform(void)
 			wrmsrq(MSR_KVM_MIGRATION_CONTROL,
 			       KVM_MIGRATION_READY);
 	}
+
+	/*
+	 * If KVM advertises the frequency directly in CPUID, use that instead
+	 * of reverse-calculating it from the KVM clock data, or worse, trying
+	 * to calibratate the TSC using an emulated device.
+	 */
+	timing_info_leaf =3D kvm_cpuid_timing_info_leaf();
+	if (timing_info_leaf) {
+		kvm_tsc_khz_cpuid =3D cpuid_eax(timing_info_leaf);
+		if (kvm_tsc_khz_cpuid) {
+			x86_init.hyper.get_tsc_khz =3D kvm_get_tsc_khz;
+			x86_init.hyper.get_cpu_khz =3D kvm_get_tsc_khz;
+		}
+	}
+
 	kvmclock_init();
 	x86_platform.apic_post_init =3D kvm_apic_init;
=20
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 29ca37e9a3bc..f55d0305d1f3 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -342,8 +342,10 @@ void __init kvmclock_init(void)
 	flags =3D pvclock_read_flags(&hv_clock_boot[0].pvti);
 	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
=20
-	x86_init.hyper.get_tsc_khz =3D kvmclock_get_tsc_khz;
-	x86_init.hyper.get_cpu_khz =3D kvmclock_get_tsc_khz;
+	if (!x86_init.hyper.get_tsc_khz)
+		x86_init.hyper.get_tsc_khz =3D kvmclock_get_tsc_khz;
+	if (!x86_init.hyper.get_cpu_khz)
+		x86_init.hyper.get_cpu_khz =3D kvmclock_get_tsc_khz;
 	x86_platform.get_wallclock =3D kvm_get_wallclock;
 	x86_platform.set_wallclock =3D kvm_set_wallclock;
 #ifdef CONFIG_X86_LOCAL_APIC
--=20
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:36:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:36:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385320.1627818 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dy-0003N6-KL; Thu, 06 Aug 2026 23:36:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385320.1627818; Thu, 06 Aug 2026 23:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7dy-0003Mh-Dz; Thu, 06 Aug 2026 23:36:58 +0000
Received: by outflank-mailman (input) for mailman id 1385320;
 Thu, 06 Aug 2026 23:36:57 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3lhp1agYKCfktfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>)
 id 1ws7dx-00037d-0B
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dw-00Gcdg-Cl
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:56 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3lhp1agYKCfktfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>)
 id 6a751a4d-e002-0a2a0a5209dd-0a2a45078cde-42
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:56 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3lhp1agYKCfktfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>)
 id 6a751a96-b4ea-0a2a45070019-d155d2c5e556-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:56 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84e4ef9a74aso4706560b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059414; x=1786664214; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=RXgfgHNb2M05mbaK7fzwXMNXNJyNMqWfUYS+q8iqpyw=;
        b=n0LdWODQkNSZbGoDZGntD8WKnws5alyJdnc/uxbP/j+r+CdCJeqvgYDQDltEnnErwP
         Ey8JJjM0qHUTEi/HFHzjNvv61q3CpUQZXq0GCM+jpvF7R2UK0HRwtHAit7nzNEMdk89U
         qGg8Ihh7B8pjzS5Fb9ukDY/VRETSXgYMMbsOMwQWSiJ2lvAa9GFd/d9bAwMjB0uwy+mJ
         zC+SwbELrj4bv3Uei9loxb5isZE6l+dFqbUH0H6QAh337ncH+H2LeLY6mXnrkEWSai82
         b3sXi/DD6pZdAZE0MY6O2+MVT91IPObgNI3AWSws+KEA4o4sLhirFwp6Zen2BoaFhuwi
         d41g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059414; x=1786664214;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=RXgfgHNb2M05mbaK7fzwXMNXNJyNMqWfUYS+q8iqpyw=;
        b=f+EUNDwLQsuv4GPY2eElSzZBzVNsdKNzVxYgqybMjtwU5/Q/H92ehicekPCyC/2LV6
         Rle714ArsDuDjB2RX9zwOgXfKyA8DyV4qOeAFvOeVFcdLobiRXGyprHnhNj1A2wIc+Mz
         8ERWlUNyhjMk8iVherKd14pX/0M3UnXCnAZItKSqbEG0pYBBIrYDQTt2p9UhtmAFMhQT
         D//saACs2ysGuZnCJwo2Sghpm5+hZFG4SYz7KJzoy4a0lohNzpQC1S2BtR2eMZlvjdlK
         aYhjU/CQShYK6wdyRWnjDJ2f5jJfabd7PP6p2j3k/pvGLq+ht+oOdAhNQZ4/A0gA2tmb
         TKLg==
X-Forwarded-Encrypted: i=1; AHgh+Rpq6KWhDx8TcgourNkGdeFapvF2mg1s/Nss16Y/EMMFXVfx9XJHe1nvm4huR8sB8E0PSOBs9sWuDVA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzj2WvDiylOCf7k5j65NCtPSHtpmVgrWCRIR8ycTeGEAZlmDl6A
	CubXjdrCI5t9+n29gMF7het3yooUbox04RpM1h7gYedmfw2TtCI1vncW73vETLmlVPXZZR89zAf
	UnY3RYQ==
X-Received: from pfcy7.prod.google.com ([2002:a05:6a00:93c7:b0:845:e683:1287])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:6e81:b0:84e:2bb:2d3e
 with SMTP id d2e1a72fcca58-84f2dfb4e50mr16994834b3a.9.1786059414067; Thu, 06
 Aug 2026 16:36:54 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:41 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-25-seanjc@google.com>
Subject: [PATCH v6 24/51] x86/kvm: Get CPU base frequency from CPUID when it's available
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059416-A60C5AE4-38FBD5C8/0/0
X-purgate-type: clean
X-purgate-size: 1756

If CPUID.0x16 is present and valid, use the CPU frequency provided by
CPUID instead of assuming that the virtual CPU runs at the same
frequency as TSC and/or kvmclock.  Back before constant TSCs were a
thing, treating the TSC and CPU frequencies as one and the same was
somewhat reasonable, but now it's nonsensical, especially if the
hypervisor explicitly enumerates the CPU frequency.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvm.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 255a24a99f28..83b9351f2810 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -50,6 +50,7 @@
 #include <asm/e820/api.h>
 
 static unsigned int kvm_tsc_khz_cpuid __initdata;
+static unsigned int kvm_cpu_khz_cpuid __initdata;
 
 DEFINE_STATIC_KEY_FALSE_RO(kvm_async_pf_enabled);
 
@@ -930,6 +931,11 @@ static unsigned int __init kvm_get_tsc_khz(void)
 	return kvm_tsc_khz_cpuid;
 }
 
+static unsigned int __init kvm_get_cpu_khz(void)
+{
+	return kvm_cpu_khz_cpuid;
+}
+
 unsigned int kvm_arch_para_features(void)
 {
 	return cpuid_eax(kvm_cpuid_base() | KVM_CPUID_FEATURES);
@@ -1043,6 +1049,14 @@ static void __init kvm_init_platform(void)
 		}
 	}
 
+	/*
+	 * Prefer CPUID.0x16 over KVM's PV CPUID when possible, as the base CPU
+	 * frequency isn't necessarily the same as the TSC frequency.
+	 */
+	kvm_cpu_khz_cpuid = __cpu_khz_from_cpuid();
+	if (kvm_cpu_khz_cpuid)
+		x86_init.hyper.get_cpu_khz = kvm_get_cpu_khz;
+
 	/*
 	 * If the TSC counts at a constant frequency across P/T states and in
 	 * deep C-states, treat the TSC reliable, as guaranteed by KVM.
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:37:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:37:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385330.1627827 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7e1-0003oo-Vo; Thu, 06 Aug 2026 23:37:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385330.1627827; Thu, 06 Aug 2026 23:37:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7e1-0003oc-Q6; Thu, 06 Aug 2026 23:37:01 +0000
Received: by outflank-mailman (input) for mailman id 1385330;
 Thu, 06 Aug 2026 23:36:59 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3mBp1agYKCfsvhdqmfjrrjoh.frp0hq-ghyhoolvwv.0hqsurmhfw.ruj@flex--seanjc.bounces.google.com>)
 id 1ws7dz-0003Va-EL
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:36:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7dy-005BVk-Ra
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:36:58 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3mBp1agYKCfsvhdqmfjrrjoh.frp0hq-ghyhoolvwv.0hqsurmhfw.ruj@flex--seanjc.bounces.google.com>)
 id 6a751a9a-5cb7-0a2a0a5109dd-0a2a4507ada8-0
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:58 +0200
Received: from [209.85.215.197] (helo=mail-pg1-f197.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3mBp1agYKCfsvhdqmfjrrjoh.frp0hq-ghyhoolvwv.0hqsurmhfw.ruj@flex--seanjc.bounces.google.com>)
 id 6a751a99-b4ea-0a2a45070019-d155d7c5c430-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:58 +0200
Received: by mail-pg1-f197.google.com with SMTP id
 41be03b00d2f7-cb11535e6a1so2334989a12.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059417; x=1786664217; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=mGO2RWCI+1OC1QgQlwRZRpcTYMYFszJFieAT3RQjORg=;
        b=E12iinLPKW0UPbyF7VCB8n5hfuuRtfdwFrg9iU/wapa7Q9dCWo4alPhYiw7A0xXwoL
         6pOZgajVAaF7i5HzK9rTaUBXJB/jhshj+5fUGV13O41fexyzGrNySi2KpLErs3cNtrmM
         KZqwhUG9meUtzNPnT36BoIYdMKfh9l4NaULqtRgfrBiaurXgOVZQAjocUH+PMp/r7nI9
         GNFmQUubVoM6phDJBNDuWJgIL7a4j7+2kWGK1Hh58GRyFIxCT1nhQ/6wMzbb4nVltiq1
         oO7t3QlXe8t3hG3+EvKOdyGK9WWLQ5DG2Zz94AhMpqkAW4TuBdyVB+6SjAP8J/QFFr0B
         tyfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059417; x=1786664217;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=mGO2RWCI+1OC1QgQlwRZRpcTYMYFszJFieAT3RQjORg=;
        b=P/dXzTyyDX2V4dHwUMfBWRtdHOmmlR6fRFXPHQx0OA56W0CzbqDH4aN9L9qEz3tMko
         Z7LUVXQdljd09Sa84IGMjZ4var2+EAElJtpZwLJV9VrPv3HLZK+PFDEhstyeVPFZLd0K
         A1Jr6QPh4w2lLSHGGHYQaHz+Opi2oon//XhUbgN9egGCGzSQC+4G36V5B7p7Q5VrtBhq
         bUrnpvq2+ObgngYlrrcj7pxhRlbcc/93gcZL6eZjiFnRx4fWq+4zpUX5+ZXiwnLtTNi7
         X/Eg4NebNXIespVgx100H8pMH+An1rYRRG/H7avyxQU8AZfRJl6IjJkFMHYX/k0U7Cd+
         RpyQ==
X-Forwarded-Encrypted: i=1; AHgh+RrzZzQoPb7p2MJf89ByKSyVgbvVj6Ai/DjGfynbNk+N8/rl8St6BTXtxRRgHahf+o3vCrjUTQZo5x8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOTdsxwvCX475/20fxShqiXq9tyz6RRZ2f9BxL65vt/RQtfF3S
	oQOjayOzRTS+VFI48sIaVA3p7LuWpe+nwEJoZWPwMPN35pFcI7JY3RCcJKvSaeWgYVp1BQsRXjU
	3qmNDYw==
X-Received: from pgmj25.prod.google.com ([2002:a63:5959:0:b0:c9e:364c:61a2])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:329c:b0:3c3:8315:80b7
 with SMTP id adf61e73a8af0-3cb85e9757amr21773483637.9.1786059416350; Thu, 06
 Aug 2026 16:36:56 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:43 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-27-seanjc@google.com>
Subject: [PATCH v6 26/51] clocksource: hyper-v: Drop wrappers to sched_clock
 save/restore helpers
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059418-A76D2AE4-D9FCF316/0/0
X-purgate-type: clean
X-purgate-size: 3432

Now that all of the Hyper-V reference counter sched_clock code is located
in a single file, drop the superfluous wrappers for the save/restore flows.

No functional change intended.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 drivers/clocksource/hyperv_timer.c | 34 +++++-------------------------
 include/clocksource/hyperv_timer.h |  2 --
 2 files changed, 5 insertions(+), 31 deletions(-)

diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index 4293173c3a27..daa8cbfe61ee 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -488,17 +488,6 @@ static void resume_hv_clock_tsc(struct clocksource *arg)
 	hv_set_msr(HV_MSR_REFERENCE_TSC, tsc_msr.as_uint64);
 }
 
-/*
- * Called during resume from hibernation, from overridden
- * x86_platform.restore_sched_clock_state routine. This is to adjust offsets
- * used to calculate time for hv tsc page based sched_clock, to account for
- * time spent before hibernation.
- */
-void hv_adj_sched_clock_offset(u64 offset)
-{
-	hv_sched_clock_offset -= offset;
-}
-
 #ifdef HAVE_VDSO_CLOCKMODE_HVCLOCK
 static int hv_cs_enable(struct clocksource *cs)
 {
@@ -565,12 +554,14 @@ static void (*old_restore_sched_clock_state)(void);
  * based clocksource, proceeds from where it left off during suspend and
  * it shows correct time for the timestamps of kernel messages after resume.
  */
-static void save_hv_clock_tsc_state(void)
+static void hv_save_sched_clock_state(void)
 {
+	old_save_sched_clock_state();
+
 	hv_ref_counter_at_suspend = hv_read_reference_counter();
 }
 
-static void restore_hv_clock_tsc_state(void)
+static void hv_restore_sched_clock_state(void)
 {
 	/*
 	 * Adjust the offsets used by hv tsc clocksource to
@@ -578,23 +569,8 @@ static void restore_hv_clock_tsc_state(void)
 	 * adjusted value = reference counter (time) at suspend
 	 *                - reference counter (time) now.
 	 */
-	hv_adj_sched_clock_offset(hv_ref_counter_at_suspend - hv_read_reference_counter());
-}
-/*
- * Functions to override save_sched_clock_state and restore_sched_clock_state
- * functions of x86_platform. The Hyper-V clock counter is reset during
- * suspend-resume and the offset used to measure time needs to be
- * corrected, post resume.
- */
-static void hv_save_sched_clock_state(void)
-{
-	old_save_sched_clock_state();
-	save_hv_clock_tsc_state();
-}
+	hv_sched_clock_offset -= (hv_ref_counter_at_suspend - hv_read_reference_counter());
 
-static void hv_restore_sched_clock_state(void)
-{
-	restore_hv_clock_tsc_state();
 	old_restore_sched_clock_state();
 }
 
diff --git a/include/clocksource/hyperv_timer.h b/include/clocksource/hyperv_timer.h
index d48dd4176fd3..a4c81a60f53d 100644
--- a/include/clocksource/hyperv_timer.h
+++ b/include/clocksource/hyperv_timer.h
@@ -38,8 +38,6 @@ extern void hv_remap_tsc_clocksource(void);
 extern unsigned long hv_get_tsc_pfn(void);
 extern struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
 
-extern void hv_adj_sched_clock_offset(u64 offset);
-
 static __always_inline bool
 hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
 		     u64 *cur_tsc, u64 *time)
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:37:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:37:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385367.1627835 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7eH-0005E1-EI; Thu, 06 Aug 2026 23:37:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385367.1627835; Thu, 06 Aug 2026 23:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7eH-0005Dq-At; Thu, 06 Aug 2026 23:37:17 +0000
Received: by outflank-mailman (input) for mailman id 1385367;
 Thu, 06 Aug 2026 23:37:16 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3qRp1agYKCQ46so1xqu22uzs.q20Bs1-rs9szzw676.Bs1352xsq7.25u@flex--seanjc.bounces.google.com>)
 id 1ws7eF-00056Z-VC
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:37:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7eF-00Gchi-CG
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:37:15 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3qRp1agYKCQ46so1xqu22uzs.q20Bs1-rs9szzw676.Bs1352xsq7.25u@flex--seanjc.bounces.google.com>)
 id 6a751aa2-bab6-0a2a0a5309dd-0a2a4505a808-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:15 +0200
Received: from [209.85.216.70] (helo=mail-pj1-f70.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3qRp1agYKCQ46so1xqu22uzs.q20Bs1-rs9szzw676.Bs1352xsq7.25u@flex--seanjc.bounces.google.com>)
 id 6a751aa9-4cb1-0a2a45050019-d155d846b569-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:15 +0200
Received: by mail-pj1-f70.google.com with SMTP id
 98e67ed59e1d1-38f5ac7354dso3867268a91.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059433; x=1786664233; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=rt852L9wHdv0bDRlKJAMITX85TrVIH1oxytQu/w6xUg=;
        b=hB1cuZKpyyowQkIuPIQPK4SDD3mNXcl+F3g0EdPblRujk6bQ6RazudGIEWHYIcZtgo
         sIMC2Cqxg5QFcEi7nwmq7Y9ACLV8OUHwqovnj/Ey3b8eY50flNmugiB+24pDA6I8YJcf
         NHf8TctOk5YPbVDomx7BJ8KxYa7y0/pR0DPMYLuN8YyWn3fi8B8rVU3iqsBGoP+zE6IV
         yx6EGhn0qSrooSOUiInhsdSPGWt7Wd84kQt1kVvsb26qWjPuDZmOylfQcHQfs6YXgfeC
         CA8gtN1RtiODWWbMqZnHkxVhLFlccxwlsMKQdJ3KylbjOAzqHW3tL/bAlY8rSFhUFeIi
         S9rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059433; x=1786664233;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=rt852L9wHdv0bDRlKJAMITX85TrVIH1oxytQu/w6xUg=;
        b=daDMgkg9YrrssARbkmqGLyFrDHPb6Js6uCb7ektGKD2hmL6hczZrqRnVvDSmPBMlLi
         Ak803lbErSVzGPQAL7ficTzY4HZta3dTrsVasUeqxKdXpE/D2SOmK4l/Dj5aZdaOSxTy
         P9UGEEUz6Py+casuPqOjevbEq10PqRKldoZXCitf8q6Nsl25NegQmAa47UohTeOwWJjo
         rJnYoKe9n9VXtClSQvXc9L/WSYXUARbEb950NyO3S+WUOS5jCzFsY1bFN1ss781Id/yx
         cojWbWlHk9U5kct5wfgfolnJ2yGgPZa8iZn/NiWXbngz0beXFTy/t1T0o4qI8UAmDNje
         t95Q==
X-Forwarded-Encrypted: i=1; AHgh+RrF30tF+Z4W+fml7WgPHbKrPibBg7yOEdrF+Hairo4bSKf7RZTgJGBXui1W8LW6AYhkGTI88Lwuso4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzy1PesDviqwhZeAAltjENPqzSZ3jQYOF1fuVZ6m795kuqBiHpY
	G0LW3n7e4VHyvHLfOgRWN4OrO+yfIaJoD3MT9SbeGkoKWFuQnWbIQ1KDdIEBFgHOqHRGgUBZAUn
	QgDO1sA==
X-Received: from pgkd23.prod.google.com ([2002:a63:f257:0:b0:cbe:7907:901])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:d52c:b0:3c3:812a:2198
 with SMTP id adf61e73a8af0-3cb85df190amr24070365637.4.1786059433092; Thu, 06
 Aug 2026 16:37:13 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:56 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-40-seanjc@google.com>
Subject: [PATCH v6 39/51] x86/pvclock: Mark setup helpers and related various
 as __init/__ro_after_init
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c201ff/1786059435-F62AB2A1-C6F9C289/0/0
X-purgate-type: clean
X-purgate-size: 1384

Now that Xen PV clock and kvmclock explicitly do setup only during init,
tag the common PV clock flags/vsyscall variables and their mutators with
__init.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/pvclock.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index b3f81379c2fc..a51adce67f92 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -16,10 +16,10 @@
 #include <asm/pvclock.h>
 #include <asm/vgtod.h>
 
-static u8 valid_flags __read_mostly = 0;
-static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
+static u8 valid_flags __ro_after_init = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __ro_after_init;
 
-void pvclock_set_flags(u8 flags)
+void __init pvclock_set_flags(u8 flags)
 {
 	valid_flags = flags;
 }
@@ -153,7 +153,7 @@ void pvclock_read_wallclock(struct pvclock_wall_clock *wall_clock,
 	set_normalized_timespec64(ts, now.tv_sec, now.tv_nsec);
 }
 
-void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
+void __init pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
 {
 	WARN_ON(vclock_was_used(VDSO_CLOCKMODE_PVCLOCK));
 	pvti_cpu0_va = pvti;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:37:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:37:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385396.1627845 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ed-0006gr-MS; Thu, 06 Aug 2026 23:37:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385396.1627845; Thu, 06 Aug 2026 23:37:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ed-0006gk-Iw; Thu, 06 Aug 2026 23:37:39 +0000
Received: by outflank-mailman (input) for mailman id 1385396;
 Thu, 06 Aug 2026 23:37:38 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3gxp1agYKCeYaMIVRKOWWOTM.KWUfMV-LMdMTTQaba.fMVXZWRMKb.WZO@flex--seanjc.bounces.google.com>)
 id 1ws7ec-0006d5-23
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:37:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7eb-005Ba1-FM
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:37:37 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3gxp1agYKCeYaMIVRKOWWOTM.KWUfMV-LMdMTTQaba.fMVXZWRMKb.WZO@flex--seanjc.bounces.google.com>)
 id 6a751a9a-5cb7-0a2a0a5109dd-0a2a4507ada8-40
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:37 +0200
Received: from [209.85.216.72] (helo=mail-pj1-f72.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3gxp1agYKCeYaMIVRKOWWOTM.KWUfMV-LMdMTTQaba.fMVXZWRMKb.WZO@flex--seanjc.bounces.google.com>)
 id 6a751a83-b4ea-0a2a45070019-d155d848c1f7-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:37 +0200
Received: by mail-pj1-f72.google.com with SMTP id
 98e67ed59e1d1-38827cee19eso3452825a91.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059395; x=1786664195; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=rOLPH8cbFzmNmyBMg+VXArbJGugFBL/MCFG1XvEwkdc=;
        b=lwAodFCpFUQJmlJC04f9nWHxfIs2WuX48vI7pZAX3odWybVzRnOc9+pvkw9adIymUO
         urQewPv6r80YNXWtBIZWn5TeLv4dPcbdWkXBxYL9hJiwh33Tb1jqx2xR7gTdozfL73t7
         8lpXkNITCI2X3eK2x0NqN7Q/uhni37bTCuG7nPN1ZKFeEve9bR4VgWr9mq5iqhuScLeL
         Pu3AY/DRdLi9QZlGB/atYjL4b4F/nvMija/y1BDGiIYa9dhRwuvZCkbhuTkNetb8uCD4
         qk/NR9grTk7NDvX7USf5T/vjJChs4aNiOoig8Y8mgEx4YfsmDyj1EjcQ81KEDRz0Pmhv
         I/6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059395; x=1786664195;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=rOLPH8cbFzmNmyBMg+VXArbJGugFBL/MCFG1XvEwkdc=;
        b=qaXXaPH5DDU4772U9XXg6CijfGjBYEf26VshQnb0Q5MOIHfGeLdBgMwkkQgh1J7T1B
         Rs9H1VRJoKaH88oeMXGXED7OTxlPQarWgUTYqRMixNiel6/6TbVoLTMHnh8RKTI9mrkH
         NoIR+HtLfl+GsVzZpyO/tcW5vjsewJJHR9rTk0UAHLV0M9nCQL3mtdgfAKd/uOFvZQFQ
         8OZMTki0tD5mPH8BYsi7MLIxpJ7q6GHvXjj37O5frLvlJBXtIYgoYXhxZqoEOU5fFi7A
         aCTFQapq5QKahCCWAsE3jEAv9gv51LtxH2yRy63kSsX4nWCCVm/eHqCLG7QmPpefn0Ga
         KSRA==
X-Forwarded-Encrypted: i=1; AHgh+Rr2Jt8VQKmwafNOzsyuH5kJng+W2TegCZI/a1GtkdgXzbriMUI2aNvFEbNOlJapq7XHElGPtq6faII=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6ftfqQzK45nudAlBUnntuOSKc6Ebwf3mOYu2fboWJAxVSIGGU
	nJIdIK4BerXDJbNRnNN1pUXZvXvVkGC8fmBllXerOUmChJCPlasjV3nsTCSbLModMSay95xgegt
	nxlUpSw==
X-Received: from pjte20.prod.google.com ([2002:a17:90a:c214:b0:38e:7f69:82cf])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5683:b0:38e:6aa7:68ad
 with SMTP id 98e67ed59e1d1-3903c54fbc4mr18735745a91.5.1786059395009; Thu, 06
 Aug 2026 16:36:35 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:26 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-10-seanjc@google.com>
Subject: [PATCH v6 09/51] x86/tsc: Add a standalone helper for getting TSC
 info from CPUID.0x15
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059397-A62C4AE4-EF248B82/13/0
X-purgate-type: clean
X-purgate-size: 4246

Extract retrieval of TSC frequency information from CPUID into a standalone
helper so that TDX guest support can reuse the logic.

Opportunistically drop native_calibrate_tsc()'s "== 0" and "!= 0" checks
in favor of the kernel's preferred style.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 61 +++++++++++++++++++++++++++----------------
 1 file changed, 38 insertions(+), 23 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 6898584610a7..d405ff4e45e0 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -645,46 +645,62 @@ static unsigned long quick_pit_calibrate(void)
 	return delta;
 }
 
+struct cpuid_tsc_info {
+	unsigned int denominator;
+	unsigned int numerator;
+	unsigned int crystal_khz;
+};
+
+static int cpuid_get_tsc_info(struct cpuid_tsc_info *info)
+{
+	unsigned int ecx_hz, edx;
+
+	if (boot_cpu_data.cpuid_level < CPUID_LEAF_TSC)
+		return -ENOENT;
+
+	/* CPUID 15H TSC/Crystal ratio, plus optionally Crystal Hz */
+	cpuid(CPUID_LEAF_TSC, &info->denominator, &info->numerator, &ecx_hz, &edx);
+
+	if (!info->denominator || !info->numerator)
+		return -ENOENT;
+
+	/*
+	 * Note: some CPUs provide the multiplier information, but not the core
+	 * crystal frequency.  The multiplier information is still useful for
+	 * such CPUs, as the crystal frequency can be gleaned from CPUID.0x16.
+	 */
+	info->crystal_khz = ecx_hz / 1000;
+	return 0;
+}
+
 /**
  * native_calibrate_tsc - determine TSC frequency
  * Determine TSC frequency via CPUID, else return 0.
  */
 unsigned long native_calibrate_tsc(void)
 {
-	unsigned int eax_denominator, ebx_numerator, ecx_hz, edx;
-	unsigned int crystal_khz;
+	struct cpuid_tsc_info info;
 
 	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
 		return 0;
 
-	if (boot_cpu_data.cpuid_level < CPUID_LEAF_TSC)
+	if (cpuid_get_tsc_info(&info))
 		return 0;
 
-	eax_denominator = ebx_numerator = ecx_hz = edx = 0;
-
-	/* CPUID 15H TSC/Crystal ratio, plus optionally Crystal Hz */
-	cpuid(CPUID_LEAF_TSC, &eax_denominator, &ebx_numerator, &ecx_hz, &edx);
-
-	if (ebx_numerator == 0 || eax_denominator == 0)
-		return 0;
-
-	crystal_khz = ecx_hz / 1000;
-
 	/*
 	 * Denverton SoCs don't report crystal clock, and also don't support
 	 * CPUID_LEAF_FREQ for the calculation below, so hardcode the 25MHz
 	 * crystal clock.
 	 */
-	if (crystal_khz == 0 &&
-			boot_cpu_data.x86_vfm == INTEL_ATOM_GOLDMONT_D)
-		crystal_khz = 25000;
+	if (!info.crystal_khz && boot_cpu_data.x86_vfm == INTEL_ATOM_GOLDMONT_D)
+		info.crystal_khz = 25000;
 
 	/*
 	 * TSC frequency reported directly by CPUID is a "hardware reported"
 	 * frequency and is the most accurate one so far we have. This
 	 * is considered a known frequency.
 	 */
-	if (crystal_khz != 0)
+	if (info.crystal_khz)
 		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 
 	/*
@@ -692,15 +708,14 @@ unsigned long native_calibrate_tsc(void)
 	 * clock, but we can easily calculate it to a high degree of accuracy
 	 * by considering the crystal ratio and the CPU speed.
 	 */
-	if (crystal_khz == 0 && boot_cpu_data.cpuid_level >= CPUID_LEAF_FREQ) {
+	if (!info.crystal_khz && boot_cpu_data.cpuid_level >= CPUID_LEAF_FREQ) {
 		unsigned int eax_base_mhz, ebx, ecx, edx;
 
 		cpuid(CPUID_LEAF_FREQ, &eax_base_mhz, &ebx, &ecx, &edx);
-		crystal_khz = eax_base_mhz * 1000 *
-			eax_denominator / ebx_numerator;
+		info.crystal_khz = eax_base_mhz * 1000 * info.denominator / info.numerator;
 	}
 
-	if (crystal_khz == 0)
+	if (!info.crystal_khz)
 		return 0;
 
 	/*
@@ -716,9 +731,9 @@ unsigned long native_calibrate_tsc(void)
 	 * lapic_timer_period here to avoid having to calibrate the APIC
 	 * timer later.
 	 */
-	apic_set_timer_frequency_khz(crystal_khz, "CPUID 0x15/0x16");
+	apic_set_timer_frequency_khz(info.crystal_khz, "CPUID 0x15/0x16");
 
-	return crystal_khz * ebx_numerator / eax_denominator;
+	return info.crystal_khz * info.numerator / info.denominator;
 }
 
 static unsigned long cpu_khz_from_cpuid(void)
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:37:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:37:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385400.1627854 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7eg-0007EM-U6; Thu, 06 Aug 2026 23:37:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385400.1627854; Thu, 06 Aug 2026 23:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7eg-0007EE-Qv; Thu, 06 Aug 2026 23:37:42 +0000
Received: by outflank-mailman (input) for mailman id 1385400;
 Thu, 06 Aug 2026 23:37:41 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3hhp1agYKCekdPLYUNRZZRWP.NZXiPY-OPgPWWTded.iPYacZUPNe.ZcR@flex--seanjc.bounces.google.com>)
 id 1ws7ef-0007C5-H1
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:37:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ee-005Ba1-UG
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:37:40 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3hhp1agYKCekdPLYUNRZZRWP.NZXiPY-OPgPWWTded.iPYacZUPNe.ZcR@flex--seanjc.bounces.google.com>)
 id 6a751a9a-5cb7-0a2a0a5109dd-0a2a4507ada8-46
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:40 +0200
Received: from [209.85.216.70] (helo=mail-pj1-f70.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3hhp1agYKCekdPLYUNRZZRWP.NZXiPY-OPgPWWTded.iPYacZUPNe.ZcR@flex--seanjc.bounces.google.com>)
 id 6a751a87-b4ea-0a2a45070019-d155d846e5fb-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:40 +0200
Received: by mail-pj1-f70.google.com with SMTP id
 98e67ed59e1d1-3811279d51aso4526963a91.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059399; x=1786664199; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=yV4aOROKwLK4YUA2A0rPmI+8Xp1hkN/OxQzRiMqFKuI=;
        b=Ih1hwm2k2Rkv49kqy7aXuFUm2Xr7H64db2H163AG0uodO0EPKODbA/UZ9gKh/vbVRa
         L7RvN4RKp34VICoQbth75MJ6Ho5qE4meAjBT47lcThaGytdruq4eAwxHRM92nfgqfGdV
         8/YvWFinMeaRoN8hhYcFc/1tltLqp8ON6UdQ8BfcmV6HYhT9cKBQ7b4miGRaKiEp57NX
         fCvBEt3GvdmQPBsC/gpeYIrapXGHWxp1CHFforqky8RF6Wm1lI0OTnIcfnpMOfOmCmUF
         5kfkVa9AJFhok/xxtFiHF67887uP93mxqk3Wl4I2radt1HJwB+Ie0w4gyqUAmNKV9ZdI
         fQXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059399; x=1786664199;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=yV4aOROKwLK4YUA2A0rPmI+8Xp1hkN/OxQzRiMqFKuI=;
        b=sOFEGUFl9gEr415oPIh+wFA1es+LXUoAfSrs1n6KmEcrw+/dF7BuZDIJmEBdP8a5WC
         HpE1GHq3LlAPocBg9Ij4i/bTfFHurzCEEc+i6ToQka+Z0lWJCthe/FMeOWwurKS7y9Rg
         F8Qx2rm4hCoI13mRAhlwF+jSS9PunDaEspUHw0R3jawG92A/Oox/Fp7XqThXWkEDl0GZ
         17/jOIvVAkw/lPhhfKXwTA8Yh+NPsP73RgvihZLE937VrdRqDfQCftiUuxzqHT5Opi6E
         rz3QvDWKJyVlcNsMGW/jRkoOmPpOxZDUXLu045nrWJNq/kr+zFJv0iJWZ7Rj6dSVAg6B
         FMSA==
X-Forwarded-Encrypted: i=1; AHgh+RqgG2QEPKUv/06J2cXOQFFuJgbE6r+043DWTeAyT5KC0Z+6lovHhyBZ+8jiSvC4H0cKXeT3SieDv0s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxTpzjEVN8Pj7cIjstv+vRD8nLBZQ587qjmTf61eUumsxtlWuoy
	DtkLAwaft0CFFi66/io9enMafqq6youWP/oU1DMWz7jwSRLDnrcjJN045MfjIgfpKL799tUYOoQ
	5RF/CdQ==
X-Received: from pjbqa7.prod.google.com ([2002:a17:90b:4fc7:b0:38e:bbd1:f3c8])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:c88e:b0:38e:488f:7068
 with SMTP id 98e67ed59e1d1-3903c5373b4mr20563002a91.2.1786059398528; Thu, 06
 Aug 2026 16:36:38 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:29 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-13-seanjc@google.com>
Subject: [PATCH v6 12/51] x86/acrn: Register TSC/CPU frequency callbacks iff
 frequency is actually in CPUID
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059400-360C5AE4-60DE75CB/13/0
X-purgate-type: clean
X-purgate-size: 1812

Register ACRN's TSC/CPU frequency overrides if and only if the exact TSC
frequency is actually provided in CPUID.  This will allow marking the TSC
as reliable as appropriate, and avoids relying on the caller to handle
"failure".

For all intents and purposes, no functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/cpu/acrn.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index ad8f2da8003b..dc71a6fdd461 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -19,6 +19,8 @@
 #include <asm/idtentry.h>
 #include <asm/irq_regs.h>
 
+static unsigned int acrn_tsc_khz_cpuid __initdata;
+
 static u32 __init acrn_detect(void)
 {
 	return acrn_cpuid_base();
@@ -26,13 +28,19 @@ static u32 __init acrn_detect(void)
 
 static unsigned int __init acrn_get_tsc_khz(void)
 {
-	return cpuid_eax(ACRN_CPUID_TIMING_INFO);
+	return acrn_tsc_khz_cpuid;
 }
 
 static void __init acrn_init_platform(void)
 {
 	/* Install system interrupt handler for ACRN hypervisor callback */
 	sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_acrn_hv_callback);
+
+	acrn_tsc_khz_cpuid = cpuid_eax(ACRN_CPUID_TIMING_INFO);
+	if (acrn_tsc_khz_cpuid) {
+		x86_init.hyper.get_tsc_khz = acrn_get_tsc_khz;
+		x86_init.hyper.get_cpu_khz = acrn_get_tsc_khz;
+	}
 }
 
 static bool acrn_x2apic_available(void)
@@ -80,6 +88,4 @@ const __initconst struct hypervisor_x86 x86_hyper_acrn = {
 	.type			= X86_HYPER_ACRN,
 	.init.init_platform     = acrn_init_platform,
 	.init.x2apic_available  = acrn_x2apic_available,
-	.init.get_tsc_khz	= acrn_get_tsc_khz,
-	.init.get_cpu_khz	= acrn_get_tsc_khz,
 };
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:37:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:37:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385403.1627864 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7em-0007x0-AS; Thu, 06 Aug 2026 23:37:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385403.1627864; Thu, 06 Aug 2026 23:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7em-0007w3-5V; Thu, 06 Aug 2026 23:37:48 +0000
Received: by outflank-mailman (input) for mailman id 1385403;
 Thu, 06 Aug 2026 23:37:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3ixp1agYKCe4iUQdZSWeeWbU.SecnUd-TUlUbbYiji.nUdfheZUSj.ehW@flex--seanjc.bounces.google.com>)
 id 1ws7ek-0007la-Rq
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:37:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ek-009HY2-4A
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:37:46 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3ixp1agYKCe4iUQdZSWeeWbU.SecnUd-TUlUbbYiji.nUdfheZUSj.ehW@flex--seanjc.bounces.google.com>)
 id 6a751aa4-e002-0a2a0a5209dd-0a2a4503b82a-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:46 +0200
Received: from [209.85.216.69] (helo=mail-pj1-f69.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3ixp1agYKCe4iUQdZSWeeWbU.SecnUd-TUlUbbYiji.nUdfheZUSj.ehW@flex--seanjc.bounces.google.com>)
 id 6a751a8c-fae8-0a2a45030019-d155d845c026-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:45 +0200
Received: by mail-pj1-f69.google.com with SMTP id
 98e67ed59e1d1-38ce7fabf76so4358982a91.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059404; x=1786664204; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=VAfqOqpweyKvsFpq/agEYC9CEWnfcmlui4k8L8ZR5pE=;
        b=l8v/bFCH5DueBriRFBLsBOvg00nFAJB1SYanY2hZ0S51HjAOZSeZcZzMAJSXKw60b5
         ZQqEkG0nLm43ahHa02+ZXd86NibWujsh6PEouC3li5X5QZB6q8RZlWS/221/IfoNW2Yb
         xZSHiCmSQxxG7Y/Zc0xXbI6JRg7NPsbFKhwCgy0un/4cnV9f2w25e2Nx84WE7PGEg9FL
         HEg5tVPkMXp6JvtUq8fdBbreljIsgyp//3q/cmCcRVw42ECTiEjLTQtI/+QVPpriPW5G
         sdRhqrZCD7Vk2fO8TXDMwvYOqM3SWkw7yLyanEsb2G+Fcry6wiQ3mIvED5rzA/KqEyd3
         j74Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059404; x=1786664204;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=VAfqOqpweyKvsFpq/agEYC9CEWnfcmlui4k8L8ZR5pE=;
        b=hTEKz2SBgBT/9LDb45Qm1dWH5PGYsTlQ/V0KzAWFvtV+Dmr7M2av5isoo6GDoEDzyQ
         SqEEB0bm3WNcU50GvqyGRMP1utVBAWI9OV4nbz6P/YxzpcjHYELjljTQTsCQOtQ4oWHs
         k5pQ8ooHXPMz71+0tNeVkmF1TdG0A9sG4hC/dKRknkVs9kN7R9Jns4hKtkxDMjYOn+ce
         n9T2ppfhbX+EvDhF5O0XtLDO6zP4HiMeL74RQFbpFkqYsohBd1A2RhPv4OPJAyN1AvlU
         YTAcV1inC4DpgY6Fg/GYVwwfxbaO4ltsMLiKJeJsT4BOMT6wB3+4pFGJzAzCd/epOEYo
         G0Pg==
X-Forwarded-Encrypted: i=1; AHgh+RrISvcwfZAvUTl5UmR9J848KKtuOR0UvSBrWDPxa7TzkUgUULzDXLU8l0XAuh2kSk81DieEaoYspUw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxsd2U6QacbHWYWiRHYcn2H55q40HSsE2ggVVPAaH+cK6ixku2q
	nFNeb6rJAjMdb5gqNH5Bys1LBFPo41doJfqbynpDuBj0P6Ttyk82rj514k7JuLVyLJrp0phnYCR
	gywRr+A==
X-Received: from pjbcu4.prod.google.com ([2002:a17:90a:fa84:b0:381:7fb0:5a60])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:288b:b0:38e:8300:af51
 with SMTP id 98e67ed59e1d1-3903c54d040mr19813478a91.8.1786059403683; Thu, 06
 Aug 2026 16:36:43 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:33 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-17-seanjc@google.com>
Subject: [PATCH v6 16/51] x86/tsc: Rename pit_hpet_ptimer_calibrate_cpu() => native_calibrate_cpu_late()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-33051d/1786059406-6F6C64E9-EC6DA9E6/13/0
X-purgate-type: clean
X-purgate-size: 1430

Rename the late CPU calibration routine so that its relationship to the
early routine is more obvious and intuitive.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 1d41ef1db27c..dd9e04e325d6 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -752,7 +752,7 @@ static unsigned long cpu_khz_from_cpuid(void)
  * calibrate cpu using pit, hpet, and ptimer methods. They are available
  * later in boot after acpi is initialized.
  */
-static unsigned long pit_hpet_ptimer_calibrate_cpu(void)
+static unsigned long native_calibrate_cpu_late(void)
 {
 	u64 tsc1, tsc2, delta, ref1, ref2;
 	unsigned long tsc_pit_min = ULONG_MAX, tsc_ref_min = ULONG_MAX;
@@ -927,7 +927,7 @@ static unsigned long native_calibrate_cpu(void)
 	unsigned long tsc_freq = native_calibrate_cpu_early();
 
 	if (!tsc_freq)
-		tsc_freq = pit_hpet_ptimer_calibrate_cpu();
+		tsc_freq = native_calibrate_cpu_late();
 
 	return tsc_freq;
 }
@@ -1472,7 +1472,7 @@ static bool __init determine_cpu_tsc_frequencies(bool early,
 		else
 			tsc_khz = native_calibrate_tsc();
 	} else {
-		cpu_khz = pit_hpet_ptimer_calibrate_cpu();
+		cpu_khz = native_calibrate_cpu_late();
 	}
 
 	/*
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:38:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:38:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385420.1627872 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7fA-0001fu-LW; Thu, 06 Aug 2026 23:38:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385420.1627872; Thu, 06 Aug 2026 23:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7fA-0001fn-Ij; Thu, 06 Aug 2026 23:38:12 +0000
Received: by outflank-mailman (input) for mailman id 1385420;
 Thu, 06 Aug 2026 23:38:11 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3pBp1agYKCQk1njwslpxxpun.lxv6nw-mn4nuur121.6nwy0xsnl2.x0p@flex--seanjc.bounces.google.com>)
 id 1ws7f9-0001bN-1H
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:38:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7f8-005Ba1-ET
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:38:10 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3pBp1agYKCQk1njwslpxxpun.lxv6nw-mn4nuur121.6nwy0xsnl2.x0p@flex--seanjc.bounces.google.com>)
 id 6a751aa4-5cb7-0a2a0a5109dd-0a2a450adfc0-34
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:38:10 +0200
Received: from [209.85.216.70] (helo=mail-pj1-f70.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3pBp1agYKCQk1njwslpxxpun.lxv6nw-mn4nuur121.6nwy0xsnl2.x0p@flex--seanjc.bounces.google.com>)
 id 6a751aa4-f2d2-0a2a450a0019-d155d846e865-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:10 +0200
Received: by mail-pj1-f70.google.com with SMTP id
 98e67ed59e1d1-38ec0f510a9so5941233a91.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059428; x=1786664228; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=aQ8musMrPFB3W7GZXrEzufcFO/9G0XUPjz13+bRyF/M=;
        b=UayW8GJqxBg5VG1/3FkRkdLbU/2Q1/1qHyI5vIVC/GbO5PPRtRDKjWLyMghueaSpKl
         tIBca+4/VLzOePgFa64RrbfAk8Wx28TjH5GgQ0MCkPzLJKsq2ZW9sDgQ6yVdJk935OZm
         9CKbJXpIXGhyUr6oHG7BeOhdCeCjCCjyjVdB7SmtLJI2h2Ly0AKm7Y2c5rCTRH/6ANaN
         v72Brr4zf60WJ3d6yArfwjZQwVPeA+15qxyWwHi9IuS/HJBs61JVPVHqM32t2X2L7V6Q
         /qE4eW3xZ5h9GSbln+eHUpOTLi8hmy68ww2bxVFWAKaJGOFARCo0sxigvGjRjkVd58qR
         9weQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059428; x=1786664228;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=aQ8musMrPFB3W7GZXrEzufcFO/9G0XUPjz13+bRyF/M=;
        b=qPRsFaIMFfzAsy/lpq4ksJWyzM3RpNEs47upMXraBuV0xPuDNv3gzp7LFowgBco6RS
         D03CZoLNlDd6kDvZ08Rno5Zj9HgfAS/VAntTqfuvX+Eiub8wWHMuuHfnu41b8pQnj1g9
         6M4xcs3m7xJ0wC1tmno0lPSTVPWc/4JgdFnuKl5u4HFPeaDUJtEw3XZ6vibYR83epYsH
         +eQuWDT7X0DbHeryWBmT2TmFFIKKTGT6OLMjZth9gwi2VLzFhPIpc6FcYeO4qNUnuGp7
         IJ6xI8lpnsbPX+VN0q0XRdAJHI3E4UqUQf2penOKegUzZPSPQC1keelNKBLnM4oHVXtm
         FE1g==
X-Forwarded-Encrypted: i=1; AHgh+RqV3WM3YMlzA9Fs/fTJ8sT5+Ry653AxlUMsqk5FwRN5s8LFJ3jF1XQFTavtzuiKUAxDZrTXDT5OLkU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQPgCrl6wuG+TG4Pn3MHIqVkcGazOQbpO5t3z7EDOFSIXlvJ/U
	eSDb7klEwevVQdRCblOeWY0WNhITYeKs3knZE+XTdE61IygtHcJwgkhp4ktFdhX479oTMj8XnLO
	mTliHhw==
X-Received: from pjpq20.prod.google.com ([2002:a17:90a:a014:b0:38e:befb:90c6])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:264b:b0:38a:c3f:3b87
 with SMTP id 98e67ed59e1d1-3903c58a6femr19988163a91.12.1786059428057; Thu, 06
 Aug 2026 16:37:08 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:52 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-36-seanjc@google.com>
Subject: [PATCH v6 35/51] x86/tsc: WARN if TSC sched_clock save/restore used
 with PV sched_clock
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059430-514C7CFC-831FA0FF/13/0
X-purgate-type: clean
X-purgate-size: 1422

Now that all PV clocksources override the sched_clock save/restore hooks
when overriding sched_clock, WARN if the "default" TSC hooks are invoked
when using a PV sched_clock, e.g. to guard against regressions.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 964f3d6c2c71..60fcc3020792 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -947,9 +947,17 @@ EXPORT_SYMBOL_FOR_MODULES(recalibrate_cpu_khz, "p4-clockmod,powernow-k7");
 
 static unsigned long long cyc2ns_suspend;
 
+static __always_inline bool tsc_is_save_restore_needed(void)
+{
+	if (WARN_ON_ONCE(!using_native_sched_clock()))
+		return false;
+
+	return static_branch_likely(&__use_tsc) || sched_clock_stable();
+}
+
 void tsc_save_sched_clock_state(void)
 {
-	if (!static_branch_likely(&__use_tsc) && !sched_clock_stable())
+	if (!tsc_is_save_restore_needed())
 		return;
 
 	cyc2ns_suspend = sched_clock();
@@ -969,7 +977,7 @@ void tsc_restore_sched_clock_state(void)
 	unsigned long flags;
 	int cpu;
 
-	if (!static_branch_likely(&__use_tsc) && !sched_clock_stable())
+	if (!tsc_is_save_restore_needed())
 		return;
 
 	local_irq_save(flags);
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:38:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:38:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385424.1627880 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7fD-0001wt-UF; Thu, 06 Aug 2026 23:38:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385424.1627880; Thu, 06 Aug 2026 23:38:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7fD-0001wm-RV; Thu, 06 Aug 2026 23:38:15 +0000
Received: by outflank-mailman (input) for mailman id 1385424;
 Thu, 06 Aug 2026 23:38:14 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3pxp1agYKCQw4qmzvos00sxq.o0y9qz-pq7qxxu454.9qz130vqo5.03s@flex--seanjc.bounces.google.com>)
 id 1ws7fC-0001vM-Ib
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:38:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7fB-009HY2-W0
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:38:13 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3pxp1agYKCQw4qmzvos00sxq.o0y9qz-pq7qxxu454.9qz130vqo5.03s@flex--seanjc.bounces.google.com>)
 id 6a751a81-e002-0a2a0a5209dd-0a2a450c8794-30
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:38:13 +0200
Received: from [209.85.216.71] (helo=mail-pj1-f71.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3pxp1agYKCQw4qmzvos00sxq.o0y9qz-pq7qxxu454.9qz130vqo5.03s@flex--seanjc.bounces.google.com>)
 id 6a751aa8-f479-0a2a450c0019-d155d847e594-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:13 +0200
Received: by mail-pj1-f71.google.com with SMTP id
 98e67ed59e1d1-3811279d51aso4527477a91.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059432; x=1786664232; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=4ag8yTwNbmjHFkBZxZL+JA4uvidx3vZA6IwgDKjMnAQ=;
        b=Piom0kQr4Kh+m63x/ZDynnRPc3ANRDeOmA8b5i3ynVjtawdp6zNesqbmKdBBckGXlE
         FEBmzy5g6Q9GgCIvoWgxzw/KDt3aztVW0MuXULpub0v2dlnqzxo+w2pIRdAggZRyY32y
         uccTRGfIgs7SQNRJ/xiPNwwkd+eG9LILp062arAvUkYQxayO+wi+GeeBFG34XNt1miHm
         5N72PBq9xhkMWuqkR7YBSEWUoZiXqPymjlSxkbeuWhSQO8niEzjaQq2pb9ApPCjRXO/w
         +nobWh0e5euzsYaxfPqvY4vMEQOOSKWdQBHEYFIzFFjGsYtOJA8hM8O07wYz6uIWLpsP
         XVng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059432; x=1786664232;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=4ag8yTwNbmjHFkBZxZL+JA4uvidx3vZA6IwgDKjMnAQ=;
        b=kFcGcf7mDmof3Szcu0toB/lJ4Sy6cCmNEFDrSWOixmOD1FoCozLawuSmk6KzanJo22
         NfDeLHx+XuSSVXcGRQHYF6PwKB2B95zafUAqrOGBiGc8zA9t70L79agCba5EDLQf0ZjE
         fcrMkEpR+W7AXOpsTXvEgKi14oMuBnIebv0Q5Fi8pRRGd4Zuo0tHjazaZJtjQL7BvEZG
         OVmhHLDsQmBtcJpEjmX5XRAYldwutuM1dV27W3qSm1jj71jJbLSf8ArPjLJJ9IuPO1sG
         d1BuGxqiHPlXWn9dW+mtHkkmL8PsuuovH0cAIKMqWvnwvX+QXDKIk0VuSvVq79h0uNGJ
         Oe+Q==
X-Forwarded-Encrypted: i=1; AHgh+RqIGLQCqMDY9UKRuXHfGptwxBZdDZqtogpM5OnRr8ZsBqEnlpiZ9YcGM4Bq/ZanHHKi8rdrsoDsQJQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxvf1tkChgyLxhk9HKxFyfyTa+bVreFjKa6tPX3iR8fID38O3Cx
	KKSoA3OJFK/VAh1zm6FrzLuOOZ0Mi02psffd+umP4bjYRCdDnsxCbGQEknsZF904xTe2qHjXSst
	R98eRXw==
X-Received: from pjbqb12.prod.google.com ([2002:a17:90b:280c:b0:38f:2874:84ed])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:c88e:b0:38e:488f:7068
 with SMTP id 98e67ed59e1d1-3903c5373b4mr20565740a91.2.1786059431685; Thu, 06
 Aug 2026 16:37:11 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:55 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-39-seanjc@google.com>
Subject: [PATCH v6 38/51] x86/xen/time: Mark xen_setup_vsyscall_time_info() as __init
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d25034/1786059433-51D34A5B-46BCA67A/13/0
X-purgate-type: clean
X-purgate-size: 879

Annotate xen_setup_vsyscall_time_info() as being used only during kernel
initialization; it's called only by xen_time_init(), which is already
tagged __init.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/xen/time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 8cd8bfaf1320..bc26f00fc53e 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -443,7 +443,7 @@ void xen_restore_time_memory_area(void)
 	xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
 }
 
-static void xen_setup_vsyscall_time_info(void)
+static void __init xen_setup_vsyscall_time_info(void)
 {
 	struct vcpu_register_time_memory_area t;
 	struct pvclock_vsyscall_time_info *ti;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:39:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:39:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385440.1627890 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7gM-00034P-8s; Thu, 06 Aug 2026 23:39:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385440.1627890; Thu, 06 Aug 2026 23:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7gM-00034I-5f; Thu, 06 Aug 2026 23:39:26 +0000
Received: by outflank-mailman (input) for mailman id 1385440;
 Thu, 06 Aug 2026 23:39:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3sRp1agYKCRYE0w95y2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--seanjc.bounces.google.com>)
 id 1ws7gK-00033h-ED
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:39:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7gJ-009Hfj-RS
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:39:23 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3sRp1agYKCRYE0w95y2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--seanjc.bounces.google.com>)
 id 6a751afa-e002-0a2a0a5209dd-0a2a4505b878-20
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:39:23 +0200
Received: from [209.85.216.72] (helo=mail-pj1-f72.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3sRp1agYKCRYE0w95y2AA270.yA8J09-z0H0774EFE.J09BDA50yF.AD2@flex--seanjc.bounces.google.com>)
 id 6a751ab2-4cb1-0a2a45050019-d155d848cc55-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:23 +0200
Received: by mail-pj1-f72.google.com with SMTP id
 98e67ed59e1d1-388b404eaa4so3501845a91.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059442; x=1786664242; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=+in/CASVMXdQrSwySi/14FWqsmLN6M2d30MjdmJLYfo=;
        b=OtHCkTjQxkkxyfCvqdDCUZdlyaK+F0dFQbQ1rOYrnoNGnxNn5379nb/BfO9c20Rfz5
         4d6Qd47Ldu9xpsSFUAb6N+jE1UqU6r8WlI6tIYsqy6hiaC5KWKiRwRgcID6yBZaMxPxU
         PyeazyC4cvo4FMvnLTJCDGHieClID73xCQHFC1zQd/+Xk8tfRAzA43Fp+r51bycPwDmb
         pJ/gsNklohVYnpBmOr3x0JrNnZGONH/y5fGR73pizyP7WKyFW+uOOVgVXdwqzDiU6XF3
         6XjA3LiKI0pCvFUMqfMzUw/ZBSYiv02MGFwZRJopu+gxa+Ijdy4Mfi+m7dBmqAYkdcdH
         pYKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059442; x=1786664242;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=+in/CASVMXdQrSwySi/14FWqsmLN6M2d30MjdmJLYfo=;
        b=FCJVi7HTZcGj8sfFd9rynZy4XzqNH9RjOqCU6h0UjW5y25TmrIhPZH4jGSuxW4iJsl
         Wsw/ve0HQr8jipWAVzHSCSekXRd/ZFxmFX7Tz3zmsjwSxv01+DPz7j9fANXR2t5tWbyp
         Ntw3X+WCH50jExI8tODW1twA2HnWr7wvZgLQTiqo8Dr6+xqnj5W6T4wqRMRsKQaxliZ6
         l+KO5+QhnKciBxgBMx0mRm6FlzYOkA+WbodruRc8chRGaDVRY2rlYSDwXE7feJ41UjTx
         BmZ5laBZqMAzlzox0HI5TMGRjzqDhGbAXngHpsn+7EmPU4Pl2h0UUYeuFuAcNwEiITYQ
         tyWg==
X-Forwarded-Encrypted: i=1; AHgh+RpDGKKi6BYMkKksgsogcYhMVpvkHrF3dY9uEoJOzsxvqBl8mlvIN7GNla2svSZviN8UGFr9BrXNn/s=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6trUhJps5x5wWXmQzQK3DcaNbleTjWVb+khprWAvrvRSPF5Es
	zYButhdL3TS8ZTKt+v8LxslhcIyyQXk2xE9waxitXYLW0fGyq3FAO32UksCuZl6f+0yQsYr7LSJ
	gdbfJjw==
X-Received: from pgii4.prod.google.com ([2002:a63:2204:0:b0:c8d:62a8:ee35])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:7a9c:b0:3bf:983d:e9b4
 with SMTP id adf61e73a8af0-3cb8603af0dmr21846910637.33.1786059441366; Thu, 06
 Aug 2026 16:37:21 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:03 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-47-seanjc@google.com>
Subject: [PATCH v6 46/51] x86/paravirt: Plumb a return code into __paravirt_set_sched_clock()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c201ff/1786059443-732B32A1-47A3F831/13/0
X-purgate-type: clean
X-purgate-size: 3365

Add a return code to __paravirt_set_sched_clock() so that the kernel can
reject attempts to use a PV sched_clock without breaking the caller.  E.g.
when running as a CoCo VM with a secure TSC, using a PV clock is generally
undesirable.

Note, kvmclock is the only PV clock that does anything "extra" beyond
simply registering itself as sched_clock, i.e. is the only caller that
needs to check the new return value.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/timer.h | 6 +++---
 arch/x86/kernel/kvmclock.c   | 9 ++++++---
 arch/x86/kernel/tsc.c        | 5 +++--
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index 96ae7feac47c..ca5c95d48c03 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -14,14 +14,14 @@ extern int no_timer_check;
 extern bool using_native_sched_clock(void);
 
 #ifdef CONFIG_PARAVIRT
-void __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
-				       void (*save)(void), void (*restore)(void));
+int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
+				      void (*save)(void), void (*restore)(void));
 
 static __always_inline void paravirt_set_sched_clock(u64 (*func)(void),
 						     void (*save)(void),
 						     void (*restore)(void))
 {
-	__paravirt_set_sched_clock(func, true, save, restore);
+	(void)__paravirt_set_sched_clock(func, true, save, restore);
 }
 #endif
 
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 2cc3dd2ba355..22e8855fcd4d 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -332,10 +332,13 @@ static int kvmclock_setup_percpu(unsigned int cpu)
 
 static __init void kvm_sched_clock_init(bool stable)
 {
+	/* Ensure the offset is configured before making kvmclock visible! */
 	kvm_sched_clock_offset = kvm_clock_read();
-	__paravirt_set_sched_clock(kvm_sched_clock_read, stable,
-				   kvm_save_sched_clock_state,
-				   kvm_restore_sched_clock_state);
+
+	if (__paravirt_set_sched_clock(kvm_sched_clock_read, stable,
+				       kvm_save_sched_clock_state,
+				       kvm_restore_sched_clock_state))
+		return;
 
 	/*
 	 * The BSP's clock is managed via dedicated sched_clock save/restore
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 363145c83919..fcf331ffd874 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -280,8 +280,8 @@ bool using_native_sched_clock(void)
 	return static_call_query(pv_sched_clock) == native_sched_clock;
 }
 
-void __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
-				       void (*save)(void), void (*restore)(void))
+int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
+				      void (*save)(void), void (*restore)(void))
 {
 	if (!stable)
 		clear_sched_clock_stable();
@@ -289,6 +289,7 @@ void __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
 	static_call_update(pv_sched_clock, func);
 	x86_platform.save_sched_clock_state = save;
 	x86_platform.restore_sched_clock_state = restore;
+	return 0;
 }
 #else
 u64 sched_clock_noinstr(void) __attribute__((alias("native_sched_clock")));
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:39:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:39:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385441.1627900 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7gQ-0003KW-GI; Thu, 06 Aug 2026 23:39:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385441.1627900; Thu, 06 Aug 2026 23:39:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7gQ-0003KP-CC; Thu, 06 Aug 2026 23:39:30 +0000
Received: by outflank-mailman (input) for mailman id 1385441;
 Thu, 06 Aug 2026 23:39:29 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3thp1agYKCRsJ51EA37FF7C5.3FDO5E-45M5CC9JKJ.O5EGIFA53K.FI7@flex--seanjc.bounces.google.com>)
 id 1ws7gP-0003JY-0u
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:39:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7gO-008NwO-E3
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:39:28 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3thp1agYKCRsJ51EA37FF7C5.3FDO5E-45M5CC9JKJ.O5EGIFA53K.FI7@flex--seanjc.bounces.google.com>)
 id 6a751ae6-5cb7-0a2a0a5109dd-0a2a4501dcf8-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:39:28 +0200
Received: from [209.85.216.72] (helo=mail-pj1-f72.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3thp1agYKCRsJ51EA37FF7C5.3FDO5E-45M5CC9JKJ.O5EGIFA53K.FI7@flex--seanjc.bounces.google.com>)
 id 6a751ab6-5984-0a2a45010019-d155d848bc7f-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:28 +0200
Received: by mail-pj1-f72.google.com with SMTP id
 98e67ed59e1d1-38e22137fb3so3727924a91.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059446; x=1786664246; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=yUUzKej44hzjMWM7byUMUm3T8+/2OB7FMHfj7k4gSDk=;
        b=QZI/nV7PAFv/pPThl5nZ4RPWlJsnkOb7y6J7quwQbDi7/wn5/47jyI+C89Lk123cLW
         gd8Q6y8cRwJajOs0bwx3ZanhJ4g0FCFi9tS3/DvgANYrqEO7Th2J+rOenzzYmB1Ptxeo
         JrA+TQJ7wkbOzGv36YqZKfOmaxjB2Lvu75ud32X8UYJMTv2cZWvTOVuy+0GXSjsR/uiU
         tWBVR+vdJSAC7bh6Qv+mh3rY0FCkrVcnvUpPc+/ElPgQYVpvT0kNONS5Ui4PApqS8HYy
         Wh8o/00pcrhYddpAbkOX9tiyC6nw0O6GerycAR2PHT0d8j54zyVSbI+ltkZsRHdUrd0X
         eeYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059446; x=1786664246;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=yUUzKej44hzjMWM7byUMUm3T8+/2OB7FMHfj7k4gSDk=;
        b=B4W/3kg5C3w86yDh48zk/PPI+9pDp8xMXRBV2gOQDbCSWKIMf3zSD4clDGS+StuXFS
         CsJZF4+AvfW731soMeJmD5fQsZrX/FR9Whg99TuoFLUlHfuNU4xkHLGqDEz5EuaGD1IF
         rWFAuQ9ci+ufx15u01E0YWAeUpCCFU2zyY0xugmNbuiNavcdV66pM/K/6C7N7A9R+Rhr
         k+lsYOEyXMBO2zqsXqb2c1eiwlQTETtXr1YtvdOEYNcwqq3KQNeEPIY6bke8nLScR0/k
         nU53twn+h56mSacWhNYzJmbqzKno+rMTpV3USDaEoPghfqbZL59Kf2n89KQ1hi6LYPNK
         Ek5Q==
X-Forwarded-Encrypted: i=1; AHgh+RoygyQERN3NgLw7YsnBAGpNR+tTy6zTd+v6kUdzvNFGRH1P3R4hyrLTb14xN5QUGV8I//hr2nZY0Hg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGhKK97N07ygs7xiHIRPP4/NA8+NmX5g1LHhHpXrNbcosDpsx/
	TGQmHzv2Q2UwkEQUq1X5f9bwUb/wZPWb1ctwRznPRImptjP/5Gy+YDPfp7X2D/vo6WChJjmI4Ap
	LJXZYfg==
X-Received: from pjzp16.prod.google.com ([2002:a17:90b:110:b0:382:7fcd:a18a])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:520a:b0:38f:5828:a40c
 with SMTP id 98e67ed59e1d1-3903c59a6eemr19079453a91.10.1786059446038; Thu, 06
 Aug 2026 16:37:26 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:07 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-51-seanjc@google.com>
Subject: [PATCH v6 50/51] x86/paravirt: Move using_native_sched_clock() stub
 into timer.h
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786059448-1E867757-C00BCBAE/13/0
X-purgate-type: clean
X-purgate-size: 1710

Now that timer.h ended up with CONFIG_PARAVIRT #ifdeffery anyways, move the
PARAVIRT=n using_native_sched_clock() stub into timer.h as a "free"
optimization.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/timer.h | 6 ++++--
 arch/x86/kernel/tsc.c        | 2 --
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index ca5c95d48c03..a52388af6055 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -11,9 +11,9 @@ extern void recalibrate_cpu_khz(void);
 
 extern int no_timer_check;
 
-extern bool using_native_sched_clock(void);
-
 #ifdef CONFIG_PARAVIRT
+extern bool using_native_sched_clock(void);
+
 int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
 				      void (*save)(void), void (*restore)(void));
 
@@ -23,6 +23,8 @@ static __always_inline void paravirt_set_sched_clock(u64 (*func)(void),
 {
 	(void)__paravirt_set_sched_clock(func, true, save, restore);
 }
+#else
+static inline bool using_native_sched_clock(void) { return true; }
 #endif
 
 /*
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index c0e4485484f2..74298e8ffa1f 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -302,8 +302,6 @@ int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
 }
 #else
 u64 sched_clock_noinstr(void) __attribute__((alias("native_sched_clock")));
-
-bool using_native_sched_clock(void) { return true; }
 #endif
 
 notrace u64 sched_clock(void)
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:39:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:39:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385450.1627907 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7gi-0003vs-Rp; Thu, 06 Aug 2026 23:39:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385450.1627907; Thu, 06 Aug 2026 23:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7gi-0003vl-Ot; Thu, 06 Aug 2026 23:39:48 +0000
Received: by outflank-mailman (input) for mailman id 1385450;
 Thu, 06 Aug 2026 23:39:48 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3jRp1agYKCfAkWSfbUYggYdW.UgepWf-VWnWddaklk.pWfhjgbWUl.gjY@flex--seanjc.bounces.google.com>)
 id 1ws7gi-0003u5-6G
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:39:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7gh-008O38-Jc
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:39:47 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3jRp1agYKCfAkWSfbUYggYdW.UgepWf-VWnWddaklk.pWfhjgbWUl.gjY@flex--seanjc.bounces.google.com>)
 id 6a751b32-2eae-0a2a0a5409dd-0a2a4506abfa-14
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:39:47 +0200
Received: from [209.85.214.197] (helo=mail-pl1-f197.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3jRp1agYKCfAkWSfbUYggYdW.UgepWf-VWnWddaklk.pWfhjgbWUl.gjY@flex--seanjc.bounces.google.com>)
 id 6a751a8d-195a-0a2a45060019-d155d6c5bdc7-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:47 +0200
Received: by mail-pl1-f197.google.com with SMTP id
 d9443c01a7336-2cca3673560so40738305ad.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059405; x=1786664205; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=as+YzjPRM0DAZztxhbx3Raa/ax9+dW0ZzZ4Dw8q0B68=;
        b=kWfa/AsaHAaOPijm2y8OJA5bnjUNwAVvFc2FCCHiOfYHYxYau4I6t8DRERbCxhIL4C
         KovV1Z8rv7f09cwCN1BvnhH4b3oWB7BoQh55xgPJeL2h+QLJ2l3zdMfnFcalfOCo0anO
         qkqCbCpddeWtMMBR+h1FXUrf9rlvHIgy0rmidcqkQ6k+zJ6krhnmQB965ZaXrgSGb6sr
         /GOkVO5X79wL4eOWSgYalsbg6nDCq11U5wvKuaPoq1sbInlElaBOiQCgwwBWHfBFMS4/
         P9plgmNFfGKUJ5ZI5E7j/n2+wNAm82UHzxOCSTV9N02X+RN/YLFbufdo4SiWuou174QN
         HSbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059405; x=1786664205;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=as+YzjPRM0DAZztxhbx3Raa/ax9+dW0ZzZ4Dw8q0B68=;
        b=YsjkKpmc+hwYoRm2sRI8yyrzGzIi6OFaYv9Uz5tzQmyqzVZrs+kKDCGdVqn2MOrQSd
         I7vvkAnTE/LbanNsKkeZVzSexKQd3GnbIGCLudEXHydapG7dghd6WzrHBsvg1OUV9dy7
         5DBKPyOg30m9xmyT8YPnYKyEORw38Gn3Plx9XT88iwhaOdTdxCjd8r/bF4n49yXizc/p
         cwjxiAL9CHDQX9Y1V7WAsN1PTGY+4TmsvGjnM58b+7RhGeGkKl5lwopNwzICKDvDLSDS
         SM5d0MPGX8HyxtpmcraqdmnJGg+XJOSGJ3dtY1zaWJz2qqLHdB7RHtNvrZEXJcz4K8qx
         LCzQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr23BhP8yqt3AE8tmwpbtvsCxCIS5h2cCbWiDFz+BNtwF467ylp3uWFWdfXrsEPBitN+P84Jnb2ey0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoPnfZX8rSbjTwnrsPo/Q7m4CxCOWswD/LEEf9HHUj/GzEqpsg
	LKzo2X06eTIIfiyWR68N0aqm0/CqjpPzJNzCXJRvYjrta3EBOiWZ/Op/ZxhTARK+EBlye9Cfs4c
	RrXEbHA==
X-Received: from plblh12.prod.google.com ([2002:a17:903:290c:b0:2cf:277e:c60c])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f708:b0:2ba:6518:a6d4
 with SMTP id d9443c01a7336-2d0ca9624bdmr224800085ad.20.1786059405010; Thu, 06
 Aug 2026 16:36:45 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:34 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-18-seanjc@google.com>
Subject: [PATCH v6 17/51] x86/tsc: Fold native_calibrate_cpu() into recalibrate_cpu_khz()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-16d1c6/1786059407-1ECC577B-EE81E4AE/0/0
X-purgate-type: clean
X-purgate-size: 1493

Fold the guts of native_calibrate_cpu() into its sole remaining caller,
recalibrate_cpu_khz() to eliminate the extra SMP=n #ifdef, and so that it's
more obvious that directly invoking the early vs. late calibration routines
in determine_cpu_tsc_frequencies() is intentional.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 19 +++----------------
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index dd9e04e325d6..d95e4f059f17 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -918,21 +918,6 @@ static unsigned long native_calibrate_cpu_early(void)
 	return fast_calibrate;
 }
 
-#ifndef CONFIG_SMP
-/**
- * native_calibrate_cpu - calibrate the cpu
- */
-static unsigned long native_calibrate_cpu(void)
-{
-	unsigned long tsc_freq = native_calibrate_cpu_early();
-
-	if (!tsc_freq)
-		tsc_freq = native_calibrate_cpu_late();
-
-	return tsc_freq;
-}
-#endif
-
 void recalibrate_cpu_khz(void)
 {
 #ifndef CONFIG_SMP
@@ -944,7 +929,9 @@ void recalibrate_cpu_khz(void)
 	if (WARN_ON_ONCE(cpu_feature_enabled(X86_FEATURE_TSC_KNOWN_FREQ)))
 		return;
 
-	cpu_khz = native_calibrate_cpu();
+	cpu_khz = native_calibrate_cpu_early();
+	if (!cpu_khz)
+		cpu_khz = native_calibrate_cpu_late();
 	tsc_khz = native_calibrate_tsc();
 	if (tsc_khz == 0)
 		tsc_khz = cpu_khz;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:40:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:40:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385459.1627917 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7h1-0005MG-4o; Thu, 06 Aug 2026 23:40:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385459.1627917; Thu, 06 Aug 2026 23:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7h1-0005Lb-0F; Thu, 06 Aug 2026 23:40:07 +0000
Received: by outflank-mailman (input) for mailman id 1385459;
 Thu, 06 Aug 2026 23:40:06 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3nxp1agYKCQQwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 1ws7h0-0005Ip-4K
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:40:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7gz-008O38-HU
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:40:05 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3nxp1agYKCQQwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 6a751b32-2eae-0a2a0a5409dd-0a2a4506abfa-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:40:05 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3nxp1agYKCQQwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 6a751a9f-195a-0a2a45060019-d155d2c6d4bf-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:05 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-84eee2147ffso3479047b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059423; x=1786664223; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=vn6W6kHEL1s4RiTIjTKhQPQXVLtQ6/4gpgI7E1htjZ4=;
        b=L+lNhrIiLPPkrx9RhTXHgKpvAT8p1sItqamBUWfrX2xvWk3lLOs7XTlq+piC9SQNz3
         nnkdSsknXF2qnBCK6kp4Ejrj9wlD15lMSHPUxFvLduy4auSofNxJRCeeQcS8g3wvRF6N
         OTwYl37lmpHoGboe+cRTrYnpMrym4+lPiI+K9YRMHAPHlYNMbxntdRuju/NcFBj+J/c/
         LQkVftSXJ+7/8Jhg7vCCgostOmAzjZMyQiiyViOjm3C4USbhlEobSeztEu24X26OzKe1
         ZLEXp0sqmS69ms5DUGtuatdsmLuOedEkOkh2DsxXuJ/F8RsVjwM8VBPqcIHRoS1rRfXe
         eVog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059423; x=1786664223;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=vn6W6kHEL1s4RiTIjTKhQPQXVLtQ6/4gpgI7E1htjZ4=;
        b=sUB/3jO4ke7db79uU3aHqqZg00ow/al4n0c9Bww7ECkAy1dPcg6x8fOuFB/wq8gjaV
         sZTtbTWMhtvr1ypWSepS32n8Lhu/2mEXUMrk6mzeyiR3/R3xejEyT/jVy4HV6lv8FWvC
         kTxcGgQlOH3pmSb7zgECE43A3+8m9onyDASdv9NrxemlHXtCZPrdHndtSUMKaEi5y/LN
         tF/WNkOPPiHrHOxozADBKM4NE7tEKsnSB3BOWO9j7/n+1WdUF9kbI0h3Wdc1dsIjq8OC
         Yo9yaroM/4d37V+fueL6cqWGM8W4SuP0U5zc/GHxuJ/A8k2hlmP1uhsK2dPom8sTpLjd
         dCGg==
X-Forwarded-Encrypted: i=1; AHgh+Rrm/b1JUdNzrGZKXysurfUr9FnuzKCxIk3dWlBnQmdPsj9TMMhS9Ky3/sOEeSpXE73HFhGCOaR3QsQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQp18155z5eXyWRUwrPsQy9pWyWJJErVE15X6u6YOuSbVUZ5tt
	STdxygpzb+CGK+oZR9gVcIoblc5Vz5BkdbtV2bUwahwLItViBT1L9YDDvKOkzFinowbh6Ermj4c
	qpYsBew==
X-Received: from pfbbx10.prod.google.com ([2002:a05:6a00:428a:b0:848:2e0e:62e])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1daa:b0:848:401c:98e
 with SMTP id d2e1a72fcca58-84f2e0432a7mr20883954b3a.15.1786059423013; Thu, 06
 Aug 2026 16:37:03 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:48 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-32-seanjc@google.com>
Subject: [PATCH v6 31/51] x86/paravirt: Move handling of unstable PV clocks
 into paravirt_set_sched_clock()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-16d1c6/1786059425-F4A0477B-06BBC8DE/0/0
X-purgate-type: clean
X-purgate-size: 2569

Move the handling of unstable PV clocks, of which kvmclock is the only
example, into paravirt_set_sched_clock().  This will allow modifying
paravirt_set_sched_clock() to keep using the TSC for sched_clock in
certain scenarios without unintentionally marking the TSC-based clock as
unstable.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/timer.h | 7 ++++++-
 arch/x86/kernel/kvmclock.c   | 5 +----
 arch/x86/kernel/tsc.c        | 5 ++++-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index c71b466d6ace..fe41d40a9ae6 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -14,7 +14,12 @@ extern int no_timer_check;
 extern bool using_native_sched_clock(void);
 
 #ifdef CONFIG_PARAVIRT
-void paravirt_set_sched_clock(u64 (*func)(void));
+void __paravirt_set_sched_clock(u64 (*func)(void), bool stable);
+
+static inline void paravirt_set_sched_clock(u64 (*func)(void))
+{
+	__paravirt_set_sched_clock(func, true);
+}
 #endif
 
 /*
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index a3ec298d56d7..4bc0495f1f9e 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -12,7 +12,6 @@
 #include <linux/hardirq.h>
 #include <linux/cpuhotplug.h>
 #include <linux/sched.h>
-#include <linux/sched/clock.h>
 #include <linux/mm.h>
 #include <linux/slab.h>
 #include <linux/set_memory.h>
@@ -115,10 +114,8 @@ static noinstr u64 kvm_sched_clock_read(void)
 
 static inline void kvm_sched_clock_init(bool stable)
 {
-	if (!stable)
-		clear_sched_clock_stable();
 	kvm_sched_clock_offset = kvm_clock_read();
-	paravirt_set_sched_clock(kvm_sched_clock_read);
+	__paravirt_set_sched_clock(kvm_sched_clock_read, stable);
 
 	pr_info("kvm-clock: using sched offset of %llu cycles",
 		kvm_sched_clock_offset);
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index e0bea58b6658..964f3d6c2c71 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -280,8 +280,11 @@ bool using_native_sched_clock(void)
 	return static_call_query(pv_sched_clock) == native_sched_clock;
 }
 
-void paravirt_set_sched_clock(u64 (*func)(void))
+void __paravirt_set_sched_clock(u64 (*func)(void), bool stable)
 {
+	if (!stable)
+		clear_sched_clock_stable();
+
 	static_call_update(pv_sched_clock, func);
 }
 #else
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:40:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:40:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385463.1627926 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7h5-0005jq-B3; Thu, 06 Aug 2026 23:40:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385463.1627926; Thu, 06 Aug 2026 23:40:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7h5-0005jh-8F; Thu, 06 Aug 2026 23:40:11 +0000
Received: by outflank-mailman (input) for mailman id 1385463;
 Thu, 06 Aug 2026 23:40:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3ohp1agYKCQczlhuqjnvvnsl.jvt4lu-kl2lsspz0z.4luwyvqlj0.vyn@flex--seanjc.bounces.google.com>)
 id 1ws7h3-0005ir-Vh
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:40:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7h3-008O38-Cc
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:40:09 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3ohp1agYKCQczlhuqjnvvnsl.jvt4lu-kl2lsspz0z.4luwyvqlj0.vyn@flex--seanjc.bounces.google.com>)
 id 6a751b32-2eae-0a2a0a5409dd-0a2a4506abfa-34
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:40:09 +0200
Received: from [209.85.214.197] (helo=mail-pl1-f197.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3ohp1agYKCQczlhuqjnvvnsl.jvt4lu-kl2lsspz0z.4luwyvqlj0.vyn@flex--seanjc.bounces.google.com>)
 id 6a751aa3-195a-0a2a45060019-d155d6c5e826-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:08 +0200
Received: by mail-pl1-f197.google.com with SMTP id
 d9443c01a7336-2cfa4e4684bso67531345ad.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059427; x=1786664227; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=f+UXuTD6z7zajVoSPLixW+N3kzbQtDvz4+hCO4pCJ+c=;
        b=pT6jUOebSWW9nxnOIAVPDQrEqpOFzWNjRwR1nXVUasyB6WDZ7hb7tKIY5doc33hl8u
         AuhAb3Zk0o1DYfPs3/n3pvBAO/WM/LXyHwST9k9r+2XM/KyetHSmftWIONPH+CNV/lZX
         YMaF23Bh42ShopbgkEZdFs24i+XNqoSagY2H5ch0bUMxI6XlBO5HVGPR+TtgUfvx/s3h
         l5kZklvVZMhLKDeAspINDjDpYeQM67VmElHfVFO7GPTbJx3bXHyJfs3WOKXtjj6ghpYz
         DMX5QxLApLCbWBt1/Emx8AkWRHDw0U+H/6dWjgorT6iRPq6NHubWHF3od5IHpDnhKvRi
         IMfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059427; x=1786664227;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=f+UXuTD6z7zajVoSPLixW+N3kzbQtDvz4+hCO4pCJ+c=;
        b=V910eu6cD3/8AHTLn44d3bPSB05HBuCjOuADf+hzm2xc8IpnYNKoqlj3x0vGVbOBcU
         3ujPOsrD+/ikRKhc2lBUvSVOVTPAYjkOO1FbAq16NWITIa7B8oTKpaWVj4HzqjxRn3IQ
         tE1r04wG5bBZ5ewxW4x3ZbaR6Tf+GpLjRvFUQ6mIA0qXMNf2UxUU8QMnc0Bx2re0Wots
         DxfjHzEjlPLe2yy/4/Z7SekiZihIELeenjckGNzieEghenCSgNvjdd1xogmp57TdGbI5
         BuIagvp/QQGoQPFa8uQCgz9g2Ib54x/wUq+USOotkxcv6qXtPa/V2wXx0D0nmFJmVIeJ
         73JQ==
X-Forwarded-Encrypted: i=1; AHgh+Rrqah0YF/OR58460WB0WpZ7xkMelmPOunoNRIt9INoy5t4GTxgNHOB04biEYsQWmUzxb9FZ647Oksw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxyOz6XD2cWNp/AIGE0d4JYvTU9/fHEx/Kabhadbyqv+KW1uXxd
	DwbcCpdqWUgjXQl/TJ/bIYTf0iZOqQ9YuhimSeDVbu4cd7mlC5fL9VDpagh28H0848NRJG5ubDE
	DLWEcBQ==
X-Received: from plbi11.prod.google.com ([2002:a17:903:20cb:b0:2cc:6da3:442d])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f546:b0:2cc:aa36:c046
 with SMTP id d9443c01a7336-2d0ca77ece3mr197228075ad.14.1786059426608; Thu, 06
 Aug 2026 16:37:06 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:51 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-35-seanjc@google.com>
Subject: [PATCH v6 34/51] x86/vmware: NOP-ify save/restore hooks when using
 VMware's sched_clock
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-16d1c6/1786059429-F687577B-A5130C9C/0/0
X-purgate-type: clean
X-purgate-size: 1263

NOP-ify the sched_clock save/restore hooks when using VMware's version of
sched_clock.  This will allow extending paravirt_set_sched_clock() to set
the save/restore hooks, without having to simultaneously change the
behavior of VMware guests.

Note, it's not at all obvious that it's safe/correct for VMware guests to
do nothing on suspend/resume, but that's a pre-existing problem.  Leave it
for a VMware expert to sort out.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/cpu/vmware.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index cbe8b59ab79f..94fec990a02c 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -347,8 +347,11 @@ static void __init vmware_paravirt_ops_setup(void)
 
 	vmware_cyc2ns_setup();
 
-	if (vmw_sched_clock)
+	if (vmw_sched_clock) {
 		paravirt_set_sched_clock(vmware_sched_clock);
+		x86_platform.save_sched_clock_state = x86_init_noop;
+		x86_platform.restore_sched_clock_state = x86_init_noop;
+	}
 
 	if (vmware_is_stealclock_available()) {
 		has_steal_clock = true;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:40:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:40:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385467.1627934 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7hH-00068X-Ha; Thu, 06 Aug 2026 23:40:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385467.1627934; Thu, 06 Aug 2026 23:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7hH-00068O-Eu; Thu, 06 Aug 2026 23:40:23 +0000
Received: by outflank-mailman (input) for mailman id 1385467;
 Thu, 06 Aug 2026 23:40:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3rhp1agYKCRMBxt62vz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--seanjc.bounces.google.com>)
 id 1ws7hG-00066O-6k
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:40:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7hF-009HnE-Jv
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:40:21 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3rhp1agYKCRMBxt62vz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--seanjc.bounces.google.com>)
 id 6a751b63-e002-0a2a0a5209dd-0a2a4506acd4-2
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:40:21 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3rhp1agYKCRMBxt62vz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--seanjc.bounces.google.com>)
 id 6a751aaf-195a-0a2a45060019-d155d2c8b1ac-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:21 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-84a3514f912so4400199b3a.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059439; x=1786664239; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=+wCYK2twR3W1N/eNELl9D0JNBeD1Zbsv+o0OdDwvKek=;
        b=bXA5lh07ACzBAI6MdJBK8aiPQlJNNE8vJ90Lvl2817WkJcLPJaC/aihGFacbAy9/zh
         nk0DiViZVxb4CFgJppNC7vTx4NalXtLocbrA98Ndkc6Rsh89LDGYp9O6XLJ4zkpup0r2
         tq1xbdLGBBBDmCZmk+ix/Bg4pB3vWIM+R/iINeRDsrMf8I7ZRMWTFQ7JazfacAxWK/48
         P5BYkLdZQOZ83Htw0jZ+VY5O31f3C2z+T+RyS8xwcdm/Ypd/12xkjInxnj3sbmU1+GIz
         917J4Qc/6cchBlJRHtODlPPUYQz2Uy5G7VeBcrlc5QhSEm6aIvUxsndNHV77atWUIwce
         hcIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059439; x=1786664239;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=+wCYK2twR3W1N/eNELl9D0JNBeD1Zbsv+o0OdDwvKek=;
        b=OMShWt/yzAmdFwvH+STbsLxolBlBmK2KGwQCXmIg8xWSecVc5vq9oqXcaeYLjJjdNp
         X5SByMhPLIP7/g5cdUnUGcreWqczCohRImPu98hlnfV9UHWNLAh+vnzNUBIjstjLPHF7
         4OLxiK4zPvztvB8MjRbsIyE1qsySR4D8Gr3kBZv+R4Nj6KKpXjv4K4TcBuX+vDqHwMOS
         q2LbYFj7SuzbpfKfq5R1xQYpnNi2wPMBxIZ7XyrrJl39Dvo6V6mvLRzjDobT92i78dkQ
         /15iRLSJNIjCdVoC1cUG3Ug/+5J2oa0gcvLHYlWlv0LcMk2CNtw/kt8CPqAvIhYnlY8p
         Xniw==
X-Forwarded-Encrypted: i=1; AHgh+RrIQlS5O/uOMbetS1Z1UWIebl7lIrjavg9JQ+PToAyAjKfeaKiKhRmxET5vSJlK4/oWffJLuHLHAoA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyphl5Sb5f7vVIbg2USZ9jfx7YiILU4LQjhfzQppfH2h4LKHvul
	dPxD1bVEH8IvZDh4EB42159N1QYXsvT/YlTudLbMvkNqZgfYs4KBtHY113CQWMXWSNjQGGQ2nbl
	bvwFGJg==
X-Received: from pfn34.prod.google.com ([2002:a05:6a00:a222:b0:84a:31b0:7544])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3d4b:b0:84e:89a:b8f7
 with SMTP id d2e1a72fcca58-84f2dff69eemr17547973b3a.11.1786059438943; Thu, 06
 Aug 2026 16:37:18 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:01 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-45-seanjc@google.com>
Subject: [PATCH v6 44/51] x86/kvmclock: WARN if wall clock is read while
 kvmclock is suspended
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-16d1c6/1786059441-F5A0C77B-106E8E26/0/0
X-purgate-type: clean
X-purgate-size: 2065

WARN if kvmclock is still suspended when its wallclock is read, i.e. when
the kernel reads its persistent clock.  The wallclock subtly depends on
the BSP's kvmclock being enabled, and returns garbage if kvmclock is
disabled.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 41aff709b90a..2cc3dd2ba355 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -53,6 +53,8 @@ static struct pvclock_vsyscall_time_info *hvclock_mem;
 DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, hv_clock_per_cpu);
 EXPORT_PER_CPU_SYMBOL_GPL(hv_clock_per_cpu);
 
+static bool kvmclock_suspended;
+
 /*
  * The wallclock is the time of day when we booted. Since then, some time may
  * have elapsed since the hypervisor wrote the data. So we try to account for
@@ -60,6 +62,7 @@ EXPORT_PER_CPU_SYMBOL_GPL(hv_clock_per_cpu);
  */
 static void kvm_get_wallclock(struct timespec64 *now)
 {
+	WARN_ON_ONCE(kvmclock_suspended);
 	wrmsrq(msr_kvm_wall_clock, slow_virt_to_phys(&wall_clock));
 	preempt_disable();
 	pvclock_read_wallclock(&wall_clock, this_cpu_pvti(), now);
@@ -140,6 +143,7 @@ static void kvm_save_sched_clock_state(void)
 	 * to the old address prior to reconfiguring kvmclock would clobber
 	 * random memory.
 	 */
+	kvmclock_suspended = true;
 	kvmclock_disable();
 }
 
@@ -152,16 +156,19 @@ static void kvm_setup_secondary_clock(void)
 
 static void kvm_restore_sched_clock_state(void)
 {
+	kvmclock_suspended = false;
 	kvm_register_clock("primary cpu, sched_clock resume");
 }
 
 static void kvmclock_suspend(struct clocksource *cs)
 {
+	kvmclock_suspended = true;
 	kvmclock_disable();
 }
 
 static void kvmclock_resume(struct clocksource *cs)
 {
+	kvmclock_suspended = false;
 	kvm_register_clock("primary cpu, clocksource resume");
 }
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385486.1627944 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7hx-00074g-Tg; Thu, 06 Aug 2026 23:41:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385486.1627944; Thu, 06 Aug 2026 23:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7hx-00074Z-QB; Thu, 06 Aug 2026 23:41:05 +0000
Received: by outflank-mailman (input) for mailman id 1385486;
 Thu, 06 Aug 2026 23:41:04 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3nRp1agYKCQIugcpleiqqing.eqozgp-fgxgnnkuvu.zgprtqlgev.qti@flex--seanjc.bounces.google.com>)
 id 1ws7hw-000747-Hs
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7hv-008OCw-V3
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:03 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3nRp1agYKCQIugcpleiqqing.eqozgp-fgxgnnkuvu.zgprtqlgev.qti@flex--seanjc.bounces.google.com>)
 id 6a751b54-2eae-0a2a0a5409dd-0a2a4501e234-26
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:03 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3nRp1agYKCQIugcpleiqqing.eqozgp-fgxgnnkuvu.zgprtqlgev.qti@flex--seanjc.bounces.google.com>)
 id 6a751a9e-5984-0a2a45010019-d155d2c8b455-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:03 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-848568a6f62so4588798b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059422; x=1786664222; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=3J0zUIaWZrZleLZttsrL9ykC8Y4xnIiv8MkXpJdWFpw=;
        b=sdwf+hdnPk8M/0AF0lBHccc4p6Y9Ik5dPM0XPEuzGms0GaXsNtIfI+xnYuATdYKmb1
         FVLtZTBP+pT40BUnlVkYj39XCkQcHw82Z2kVKGZIQHyDjlo2WpS/OB0exHrfHo4/7/xR
         fMjCoM52OmQC0E0mubLNOJ9cuSx0upgRK1Fgg1H8KYRqyonpSQ5C59fWOB42h/m4adHw
         DbbrBmaNjW/PA5yD8HNI+lCEiQAh4T36yIIUcVHvbsUV3X4LvGm+dMH+CP0UMdLLHTpC
         8EmXFPJR/A30ajTM9BeOypvgqBzowb8Y+IUX2DptsN0CQYmKUn4fdtTaJYjFa8ipN97i
         Js/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059422; x=1786664222;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=3J0zUIaWZrZleLZttsrL9ykC8Y4xnIiv8MkXpJdWFpw=;
        b=NVHMznmnYgi0wOicAkbFPXv0iJQmb3kCDTRWe+FKMHYfl0TmBSiQsVyq1Gx1dbUmAD
         F6+kgSNudSRlfTw+Lv+pUfmxttaKMAc0cRdFis3rC9JC1bkZr7intzl4u15CzyRYtafk
         8LpgYy6RHr2kS67Fh4paFLIzQbd/SCONiWqtXZXOwGsNO0OWaKgBXxyffB1nmZRz0WUk
         TuguapvyG+JsEkfjo0pG/91Dsa0hNPeZ5uSKvP9MaOHIZo50D9Ih6J7hv0CnsQXz5I6J
         9qn8VvUAGH6KtLiFYUiXuARLSIPTupbQjq5t0bxxN9wXFUE6/TdSBeLXcr8yitkLFOTM
         zRhA==
X-Forwarded-Encrypted: i=1; AHgh+Ro/0aATLLG60Lft9v7prygMxyoV1MIY05jSP4Bc366Lb/RP42jxF+cNXHgvYWXB7VxAw9073VfR12g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyM6Q3s+hYRWJywn4pvHxrY3Wj+lUsnhbHUfsyi0Kgnoz5XrDr9
	kCbqNCoQcMiYD4jzIu2YGYiHIU0IQEluTC2nCKLDDPw/AvRix6tcQ3yerE56OleYg5qZchdUOu4
	BPfNa3g==
X-Received: from pfbcz13.prod.google.com ([2002:aa7:930d:0:b0:848:2e05:6161])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:a58f:b0:848:3fe2:c88b
 with SMTP id d2e1a72fcca58-84f2dfc8fa4mr23126519b3a.6.1786059421552; Thu, 06
 Aug 2026 16:37:01 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:47 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-31-seanjc@google.com>
Subject: [PATCH v6 30/51] x86/paravirt: Remove unnecessary PARAVIRT=n stub for paravirt_set_sched_clock()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786059423-C475B757-413D17DB/0/0
X-purgate-type: clean
X-purgate-size: 1570

Remove the unnecessary paravirt_set_sched_clock() stub for PARAVIRT=n, as
all callers are gated by PARAVIRT=y.  Eliminating the stub will avoid a
pile of pointless churn as the "real" implementation evolves.

No functional change intended.

Fixes: 39965afb1151 ("x86/paravirt: Move paravirt_sched_clock() related code into tsc.c")
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/timer.h | 3 +++
 arch/x86/kernel/tsc.c        | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index fda18bcb19b4..c71b466d6ace 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -12,7 +12,10 @@ extern void recalibrate_cpu_khz(void);
 extern int no_timer_check;
 
 extern bool using_native_sched_clock(void);
+
+#ifdef CONFIG_PARAVIRT
 void paravirt_set_sched_clock(u64 (*func)(void));
+#endif
 
 /*
  * We use the full linear equation: f(x) = a + b*x, in order to allow
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 4c5328d19ebe..e0bea58b6658 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -288,7 +288,6 @@ void paravirt_set_sched_clock(u64 (*func)(void))
 u64 sched_clock_noinstr(void) __attribute__((alias("native_sched_clock")));
 
 bool using_native_sched_clock(void) { return true; }
-void paravirt_set_sched_clock(u64 (*func)(void)) { }
 #endif
 
 notrace u64 sched_clock(void)
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385487.1627953 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7i5-0007LH-4U; Thu, 06 Aug 2026 23:41:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385487.1627953; Thu, 06 Aug 2026 23:41:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7i5-0007L6-1L; Thu, 06 Aug 2026 23:41:13 +0000
Received: by outflank-mailman (input) for mailman id 1385487;
 Thu, 06 Aug 2026 23:41:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3pRp1agYKCQo2okxtmqyyqvo.myw7ox-no5ovvs232.7oxz1ytom3.y1q@flex--seanjc.bounces.google.com>)
 id 1ws7i4-0007KV-Cv
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7i3-008OCw-Q5
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:11 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3pRp1agYKCQo2okxtmqyyqvo.myw7ox-no5ovvs232.7oxz1ytom3.y1q@flex--seanjc.bounces.google.com>)
 id 6a751b54-2eae-0a2a0a5409dd-0a2a4501e234-30
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:11 +0200
Received: from [209.85.214.198] (helo=mail-pl1-f198.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3pRp1agYKCQo2okxtmqyyqvo.myw7ox-no5ovvs232.7oxz1ytom3.y1q@flex--seanjc.bounces.google.com>)
 id 6a751aa6-5984-0a2a45010019-d155d6c6ad1b-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:11 +0200
Received: by mail-pl1-f198.google.com with SMTP id
 d9443c01a7336-2cc5faecf01so51050895ad.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059429; x=1786664229; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=bZd2/vTLw6kP6aan4oVP2ByAHPA3GmOMxUTn1c9gmLc=;
        b=JwPsMS2qePbuLpzxHWVdn8VaL8zbSDsTDuvkoD7xlWQyw13kHqKVLpdhbptw+HsRYY
         m1Ey/HsdQMsonzyBppLMgyXePpjjFsCgK9d2Pa4NbM0dMJL6r1436kNF733cLrg9qvR7
         JgZ1NQo3B2QJ/WlgyKA9Y9/ICIeW6NKRoprz5+TyP8OfNeDknekzFFmLfBlkQO+mGl0m
         MLOmpd44lko0zLcNwQCFHfgxnmUCxgK9GF6+z0pGakvEwGwakTLKd3uyzjCM6U/+GDma
         R0oh6Zw1n6Sy3vuNOgMZu1VxKy6YUw6cSx2riEkyqQ9uhAafzzDjikM72hTQ/383dftp
         80Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059429; x=1786664229;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=bZd2/vTLw6kP6aan4oVP2ByAHPA3GmOMxUTn1c9gmLc=;
        b=rphPptBVjmGjeewxawFUOm8qxfUwfVfTy+XybJxyJVvspABKLK9vKl/cUCal8V6Fws
         7cnMos9eO1jPIY+ovskMT4yx2qUZ0aRwkDu8v6xC7rZWacfGipppvzWNjDgKvdLOX6W/
         3xOckocujP/s4sJlzd6MKZm7Fbdc4pbvamlNC2vW1vvoyxLDe5ZbrfskCBSRwHq7dNR1
         viEzAIjv5TO/BIDH/YRg04LTzSmoG/EyaXkwjGMZ/lDp08EsaeyItOfF25gcjSFc18lA
         sFdMbODhO+L/ErSqBk73u3dNdN3Gbcd0gLs7zF5vfuC7zcAnJZ8BPk3WoUhQN/pWCN5h
         qVgw==
X-Forwarded-Encrypted: i=1; AHgh+RogyYbq65Q3wW7SPjjNTMkdhR4zV8OrTeJ9x0X+MFliyp5vQIpluUxXkiIbvUelk/nfMEZleQn+iJ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxurvRWL+YNBynMez2zFmofEdNqjXkg0xv3g9Z0e5gKCP4SYfyO
	ElTBJJJg3uPOGLoO68z0FL8F6CFrR1nLe7nBEFUejm8pGUQs3utsuaxt/32OKRll3nEXv9WVdp5
	UYGWUEA==
X-Received: from pjtz20.prod.google.com ([2002:a17:90a:cb14:b0:36b:7f07:6fcd])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1c84:b0:38f:1e1a:515e
 with SMTP id 98e67ed59e1d1-3903c5b1688mr16494071a91.14.1786059429092; Thu, 06
 Aug 2026 16:37:09 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:53 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-37-seanjc@google.com>
Subject: [PATCH v6 36/51] x86/paravirt: Pass sched_clock save/restore helpers
 during registration
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786059431-BF46D757-901C4318/0/0
X-purgate-type: clean
X-purgate-size: 5767

Pass in a PV clock's save/restore helpers when configuring sched_clock
instead of relying on each PV clock to manually set the save/restore hooks.
In addition to bringing sanity to the code, this will allow gracefully
"rejecting" a PV sched_clock, e.g. when running as a CoCo guest that has
access to a "secure" TSC.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/timer.h       | 9 ++++++---
 arch/x86/kernel/cpu/vmware.c       | 8 +++-----
 arch/x86/kernel/kvmclock.c         | 6 +++---
 arch/x86/kernel/tsc.c              | 5 ++++-
 arch/x86/xen/time.c                | 5 ++---
 drivers/clocksource/hyperv_timer.c | 6 ++----
 6 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index fe41d40a9ae6..e97cd1ae03d1 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -14,11 +14,14 @@ extern int no_timer_check;
 extern bool using_native_sched_clock(void);
 
 #ifdef CONFIG_PARAVIRT
-void __paravirt_set_sched_clock(u64 (*func)(void), bool stable);
+void __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
+				void (*save)(void), void (*restore)(void));
 
-static inline void paravirt_set_sched_clock(u64 (*func)(void))
+static inline void paravirt_set_sched_clock(u64 (*func)(void),
+					    void (*save)(void),
+					    void (*restore)(void))
 {
-	__paravirt_set_sched_clock(func, true);
+	__paravirt_set_sched_clock(func, true, save, restore);
 }
 #endif
 
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 94fec990a02c..3598de5297f8 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -347,11 +347,9 @@ static void __init vmware_paravirt_ops_setup(void)
 
 	vmware_cyc2ns_setup();
 
-	if (vmw_sched_clock) {
-		paravirt_set_sched_clock(vmware_sched_clock);
-		x86_platform.save_sched_clock_state = x86_init_noop;
-		x86_platform.restore_sched_clock_state = x86_init_noop;
-	}
+	if (vmw_sched_clock)
+		paravirt_set_sched_clock(vmware_sched_clock,
+					 x86_init_noop, x86_init_noop);
 
 	if (vmware_is_stealclock_available()) {
 		has_steal_clock = true;
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 07e875738c39..5b9955343199 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -158,7 +158,9 @@ static void kvm_restore_sched_clock_state(void)
 static inline void kvm_sched_clock_init(bool stable)
 {
 	kvm_sched_clock_offset = kvm_clock_read();
-	__paravirt_set_sched_clock(kvm_sched_clock_read, stable);
+	__paravirt_set_sched_clock(kvm_sched_clock_read, stable,
+				   kvm_save_sched_clock_state,
+				   kvm_restore_sched_clock_state);
 
 	pr_info("kvm-clock: using sched offset of %llu cycles",
 		kvm_sched_clock_offset);
@@ -367,8 +369,6 @@ void __init kvmclock_init(bool prefer_tsc)
 #ifdef CONFIG_SMP
 	x86_cpuinit.early_percpu_clock_init = kvm_setup_secondary_clock;
 #endif
-	x86_platform.save_sched_clock_state = kvm_save_sched_clock_state;
-	x86_platform.restore_sched_clock_state = kvm_restore_sched_clock_state;
 	kvm_get_preset_lpj();
 
 	/*
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 60fcc3020792..d4f7cb127235 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -280,12 +280,15 @@ bool using_native_sched_clock(void)
 	return static_call_query(pv_sched_clock) == native_sched_clock;
 }
 
-void __paravirt_set_sched_clock(u64 (*func)(void), bool stable)
+void __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
+				void (*save)(void), void (*restore)(void))
 {
 	if (!stable)
 		clear_sched_clock_stable();
 
 	static_call_update(pv_sched_clock, func);
+	x86_platform.save_sched_clock_state = save;
+	x86_platform.restore_sched_clock_state = restore;
 }
 #else
 u64 sched_clock_noinstr(void) __attribute__((alias("native_sched_clock")));
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 477441752f40..8cd8bfaf1320 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -566,13 +566,12 @@ static void __init xen_init_time_common(void)
 {
 	xen_sched_clock_offset = xen_clocksource_read();
 	static_call_update(pv_steal_clock, xen_steal_clock);
-	paravirt_set_sched_clock(xen_sched_clock);
+
 	/*
 	 * Xen has paravirtualized suspend/resume and so doesn't use the common
 	 * x86 sched_clock save/restore hooks.
 	 */
-	x86_platform.save_sched_clock_state = x86_init_noop;
-	x86_platform.restore_sched_clock_state = x86_init_noop;
+	paravirt_set_sched_clock(xen_sched_clock, x86_init_noop, x86_init_noop);
 
 	x86_init.hyper.get_tsc_khz = xen_tsc_khz;
 	x86_platform.get_wallclock = xen_get_wallclock;
diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index 220668207d19..8ee7a9de0f4f 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -570,10 +570,8 @@ static void hv_restore_sched_clock_state(void)
 static __always_inline void hv_setup_sched_clock(void *sched_clock)
 {
 	/* We're on x86/x64 *and* using PV ops */
-	paravirt_set_sched_clock(sched_clock);
-
-	x86_platform.save_sched_clock_state = hv_save_sched_clock_state;
-	x86_platform.restore_sched_clock_state = hv_restore_sched_clock_state;
+	paravirt_set_sched_clock(sched_clock, hv_save_sched_clock_state,
+				 hv_restore_sched_clock_state);
 }
 #else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
 static __always_inline void hv_setup_sched_clock(void *sched_clock) {}
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385489.1627962 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iB-0007dy-Bx; Thu, 06 Aug 2026 23:41:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385489.1627962; Thu, 06 Aug 2026 23:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iB-0007dr-8a; Thu, 06 Aug 2026 23:41:19 +0000
Received: by outflank-mailman (input) for mailman id 1385489;
 Thu, 06 Aug 2026 23:41:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3qxp1agYKCRA8uq3zsw44w1u.s42Du3-tuBu11y898.Du3574zus9.47w@flex--seanjc.bounces.google.com>)
 id 1ws7iA-0007d6-HU
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7i9-008OCw-Ue
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:17 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3qxp1agYKCRA8uq3zsw44w1u.s42Du3-tuBu11y898.Du3574zus9.47w@flex--seanjc.bounces.google.com>)
 id 6a751b54-2eae-0a2a0a5409dd-0a2a4501e234-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:17 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3qxp1agYKCRA8uq3zsw44w1u.s42Du3-tuBu11y898.Du3574zus9.47w@flex--seanjc.bounces.google.com>)
 id 6a751aac-5984-0a2a45010019-d155d2c6c949-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:17 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-84870e7f498so2971196b3a.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059436; x=1786664236; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=DfVsK4/eNAzlqgTkif/k+3bkJqkVsqeG8riFv7GGWx4=;
        b=bSzLM4/00PB1CxAEp+IcCxGjD269tSdqycIW8zekVxv/OHABbdfOVwmR21q1fU72Gu
         xWG0asr0bVIqogTS9CAp6hKw4Er6job4QcWphqUaAqrJ0v7w6tRDhsDApgiFWux61LeX
         Xo/m5u6OdwsRkK2gk3Dch3TrdC26HLeGXmarzNiFFDuZzTlpAWYM8z8V4QuTOaIUqkst
         bbycINGQ8Ttc51/A8YmosKo2uXXY/uapTFHHq6kwSDhuq5LDu4MPqYcRusVZYQAKoBgN
         uneXgX8i+tn9c8fvpfzzrevbid5x45eHtze6qLRYT6Ycz/l+Qw34saXgBiS3demKloU1
         0AjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059436; x=1786664236;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=DfVsK4/eNAzlqgTkif/k+3bkJqkVsqeG8riFv7GGWx4=;
        b=XrVylOJaUFaH0HD4BLoBkL3anAzv6QnXRw5rM+invhm9YL5q82TSoWSEHTmomyfN3Q
         fs0bBCTEhLngJXrhkkdAeRyYbJKqBOy2V6tC9NvanuOrnL1AZ/tfyM/A0PPe5tIyMojf
         L+b5YZQLhkrmeUrzAN3Ke5w2OVK/piztWuNhhOP53qD2XYV1kC2IMcNvrDuM7ynfElD7
         JlBx9lceW4gsYddXOBhCeSd4kM6k2T7wxtUTA/+J6NOLiBD5KCjGCQjyA6RM9jzJGLvr
         zpebVJ9P9+OcnljFBxpnA397F3k8rqWUFPeGnonU28iK7HRU3PU4PCusoJ+ElMW/JfR1
         fP5Q==
X-Forwarded-Encrypted: i=1; AHgh+RqN63UmZBGi/fEqUt03MJMG0USpSWvFIAbBWzGc4OV0SsVESxCMx6wxFHZjbyv67FT6xZIsMzWALJM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/9uVhU+JKFAssWnuBEDzjoWO4GAPzDlcrI7lO0hCWV5wtzuUT
	Akdecpif2+7spua3OfUM2dnTtoxFc/CDZlSNZMij3vUNCvw8UeGVo8fEBNk08Z8HZL99SROAT/D
	3P7nMdA==
X-Received: from pfbko19.prod.google.com ([2002:a05:6a00:4613:b0:847:926b:dc17])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1886:b0:847:99a7:c751
 with SMTP id d2e1a72fcca58-84f2e05d02dmr18083285b3a.25.1786059435385; Thu, 06
 Aug 2026 16:37:15 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:58 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-42-seanjc@google.com>
Subject: [PATCH v6 41/51] x86/kvmclock: Refactor handling of
 PVCLOCK_TSC_STABLE_BIT during kvmclock_init()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786059437-BF063757-6D3BDBFE/0/0
X-purgate-type: clean
X-purgate-size: 1894

Clean up the setting of PVCLOCK_TSC_STABLE_BIT during kvmclock init to
make it somewhat obvious that pvclock_read_flags() must be called *after*
pvclock_set_flags().

Note, in theory, a different PV clock could have set PVCLOCK_TSC_STABLE_BIT
in the supported flags, i.e. reading flags only if
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT is set could very, very theoretically
result in a change in behavior.  In practice, the kernel only supports a
single PV clock.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 5220d205abc7..61d4d943fe74 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -327,7 +327,7 @@ static __init void kvm_sched_clock_init(bool stable)
 
 void __init kvmclock_init(bool prefer_tsc)
 {
-	u8 flags;
+	bool stable = false;
 
 	if (!kvm_para_available() || !kvmclock)
 		return;
@@ -354,11 +354,18 @@ void __init kvmclock_init(bool prefer_tsc)
 	kvm_register_clock("primary cpu clock");
 	pvclock_set_pvti_cpu0_va(hv_clock_boot);
 
-	if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT))
+	if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT)) {
 		pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
 
-	flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
-	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
+		/*
+		 * Check if the clock is stable *after* marking TSC_STABLE as a
+		 * valid flag.
+		 */
+		stable = pvclock_read_flags(&hv_clock_boot[0].pvti) &
+			 PVCLOCK_TSC_STABLE_BIT;
+	}
+
+	kvm_sched_clock_init(stable);
 
 	if (!x86_init.hyper.get_tsc_khz)
 		x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385491.1627971 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iE-0007vt-In; Thu, 06 Aug 2026 23:41:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385491.1627971; Thu, 06 Aug 2026 23:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iE-0007vh-FN; Thu, 06 Aug 2026 23:41:22 +0000
Received: by outflank-mailman (input) for mailman id 1385491;
 Thu, 06 Aug 2026 23:41:21 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3rRp1agYKCRIAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@flex--seanjc.bounces.google.com>)
 id 1ws7iD-0007sA-1P
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iC-00EM9p-El
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:20 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3rRp1agYKCRIAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@flex--seanjc.bounces.google.com>)
 id 6a751b54-bab6-0a2a0a5309dd-0a2a450297c0-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:20 +0200
Received: from [209.85.214.197] (helo=mail-pl1-f197.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3rRp1agYKCRIAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@flex--seanjc.bounces.google.com>)
 id 6a751aae-6ca4-0a2a45020019-d155d6c5ac6e-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:19 +0200
Received: by mail-pl1-f197.google.com with SMTP id
 d9443c01a7336-2ce7dfd33ffso32943235ad.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059438; x=1786664238; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=LM+bFo6oZyT6hMjeOJv5/5C5Sfvue9FfV0H+MNWzQd0=;
        b=bwdii+XOuYFQh4W5s+gsVBsTZlabSvuKjQ7targ/TP2zDDQ29IqcxdMYeWzQOol/kO
         YovjPed21L0/DoJSf1iMqruWYB4ppxFfBpj0cA3FsUXLVuqyJgnivh3lcdK8jZVAbrjU
         eLW88Iy/7lk89HGbBFcVUIdCqzPk00OPU+O2XMBB7f8+hPO0h+yISxMtkakbWFQ1L0gB
         ZDLrPbelxa+1qMDXX3sgO1qd7ESAkrJ8+efgy1JiBrSyfSz2wb5E04EGRdW6WK4SrRbx
         U0kyfBtefF6bR8roiyH+iUnMIVN/QJjmLLDzUzqNQTwOjMqf9Vw9y+XRtDoQYfn/59Yt
         sgKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059438; x=1786664238;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=LM+bFo6oZyT6hMjeOJv5/5C5Sfvue9FfV0H+MNWzQd0=;
        b=E3Fd3WsSUxfm4bzQWFRnTD+r1cWem2efhi3I9tG5ylNlaZdpw8wfDmx8APZBio5tap
         0iI6/SLJ/59B0AkVSNWZSXd7LIShXYEsE7Iu/d0eb2M6hSC9CrJWjaWi9TCQH+hYigDh
         Ke7OdtXIqKw/kaSYJlUm4ncbsb8UHPXcExv1+NwTm1mf7nMd7iNqQZD/g6gsk5cRmo7Z
         RArMv8usgwnN27HbR8pzFouS/Ia4jYTnGsqA1VDs1YwOZ/09gwgM4Ry5dh9VII15Qnbz
         7Tfx0i5wDqhD0sQ+PoAAMrulepmnL5MPwQySEG199Qw7WQqU3ZYnbM0zKY7t8k6tC5jH
         1wuA==
X-Forwarded-Encrypted: i=1; AHgh+RoHQeaPcC8nKZDBR2S/rGJkgSWFGMozsdFjua6XYqBu5wk+uoxclvA2XakCy2VqGGNhgIkz7skuOCg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3LKCPX17aaspYoI0/WKPI/tnLafwevWYGmguMp7++vMAzcwhE
	0RhNHzgJybzkcQy/68yNn+isIURL4f75Xjj+MCf1Pokj7bYtvsWjyrDNk5CLyATfDxVuz1zXBoX
	qRuy5vQ==
X-Received: from pjuf1.prod.google.com ([2002:a17:90a:ce01:b0:38e:aa86:7cac])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5447:b0:380:83fc:4315
 with SMTP id 98e67ed59e1d1-3903c66b3bfmr20385633a91.21.1786059437671; Thu, 06
 Aug 2026 16:37:17 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:00 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-44-seanjc@google.com>
Subject: [PATCH v6 43/51] x86/kvmclock: Hook clocksource.suspend/resume when
 kvmclock isn't sched_clock
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-720697/1786059440-30BC02AC-D92D305D/0/0
X-purgate-type: clean
X-purgate-size: 2030

Save/restore kvmclock across suspend/resume via clocksource hooks when
kvmclock isn't being used for sched_clock.  This will allow using kvmclock
as a clocksource (or for wallclock!) without also using it for sched_clock.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 61d4d943fe74..41aff709b90a 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -152,7 +152,17 @@ static void kvm_setup_secondary_clock(void)
 
 static void kvm_restore_sched_clock_state(void)
 {
-	kvm_register_clock("primary cpu clock, resume");
+	kvm_register_clock("primary cpu, sched_clock resume");
+}
+
+static void kvmclock_suspend(struct clocksource *cs)
+{
+	kvmclock_disable();
+}
+
+static void kvmclock_resume(struct clocksource *cs)
+{
+	kvm_register_clock("primary cpu, clocksource resume");
 }
 
 void kvmclock_cpu_action(enum kvm_guest_cpu_action action)
@@ -223,6 +233,8 @@ static struct clocksource kvm_clock = {
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 	.id		= CSID_X86_KVM_CLK,
 	.enable		= kvm_cs_enable,
+	.suspend	= kvmclock_suspend,
+	.resume		= kvmclock_resume,
 };
 
 static void __init kvmclock_init_mem(void)
@@ -318,6 +330,15 @@ static __init void kvm_sched_clock_init(bool stable)
 				   kvm_save_sched_clock_state,
 				   kvm_restore_sched_clock_state);
 
+	/*
+	 * The BSP's clock is managed via dedicated sched_clock save/restore
+	 * hooks when kvmclock is used as sched_clock, as sched_clock needs to
+	 * be kept alive until the very end of suspend entry, and restored as
+	 * quickly as possible after resume.
+	 */
+	kvm_clock.suspend = NULL;
+	kvm_clock.resume = NULL;
+
 	pr_info("kvm-clock: using sched offset of %llu cycles",
 		kvm_sched_clock_offset);
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385492.1627980 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iH-0008DB-0O; Thu, 06 Aug 2026 23:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385492.1627980; Thu, 06 Aug 2026 23:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iG-0008Cz-SH; Thu, 06 Aug 2026 23:41:24 +0000
Received: by outflank-mailman (input) for mailman id 1385492;
 Thu, 06 Aug 2026 23:41:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3sBp1agYKCRUDzv84x19916z.x97Iz8-yzGz663DED.Iz8AC94zxE.9C1@flex--seanjc.bounces.google.com>)
 id 1ws7iF-000875-K5
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iF-00EM9p-0p
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:23 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3sBp1agYKCRUDzv84x19916z.x97Iz8-yzGz663DED.Iz8AC94zxE.9C1@flex--seanjc.bounces.google.com>)
 id 6a751b43-bab6-0a2a0a5309dd-0a2a4503de86-44
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:23 +0200
Received: from [209.85.214.197] (helo=mail-pl1-f197.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3sBp1agYKCRUDzv84x19916z.x97Iz8-yzGz663DED.Iz8AC94zxE.9C1@flex--seanjc.bounces.google.com>)
 id 6a751ab1-fae8-0a2a45030019-d155d6c5dd76-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:22 +0200
Received: by mail-pl1-f197.google.com with SMTP id
 d9443c01a7336-2cc640dfde3so31468195ad.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059440; x=1786664240; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=ITopxW07/FQizEWlsu5JVYhKtG4YNcRGYaSiNeAs44w=;
        b=OEOiy4AadltqPg7dktu1ig2gjTVOJ0LY1Lt0Ni40UNEkqd0+CE1V41tpxoY2jaiul1
         +hF3dJjSmkWxh369YXpBPYEkwstgq3YfsiF0+8od4igD9KchpP71c9YupRc7YhRYcdrf
         34LIBIuzG5UMLBQfwwzhfYw+c0cNLvLXBfxWtz/7SLWQzBZ8ZkyYjlzaBuHH2Ot6LiZf
         naRH33EQ2pDgbdpS7d33OOCO1Z9cFdPF+v4UNPrv6wIN3cOba/PwZcLGs2hmH5snsAJm
         m/1yCOXoqIqSIGYcOvgzRJwhPue5ujtHNzx8YBXM6/QPb+hnmSRt4XB1LVsgtUJwPyAY
         NHRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059440; x=1786664240;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=ITopxW07/FQizEWlsu5JVYhKtG4YNcRGYaSiNeAs44w=;
        b=fHpsTz6TW6asDxr1wL7rvjMdO6UTIvx9J7+VP+FJitTHIdXYDofhiFvLlrIAZrbG/m
         e42afvqdvTVN0Q2+gKuYmEAKNPIbcNPA3BOR6vvTnfW91LtR53EHkGLMIph5MgrmJ1c8
         XtKRLH83YPX9wZbaRZS5yO73Lb7Fyc0hjKyVK70HOHnKDt3951AJlvfB/cMZbIs7Cuow
         eomiFcrcmfDYGP9+CBloHp0CZ1QeK5LqjoXJIF8WbDFll6KQtsagjWBf654p9pF+HXan
         /fsy+PsLJfMGmOnGOT8o9+cYeIU+YDtwOvniRv2E8ns7koxutT0xiv9ACe1xLKoMz2UZ
         y8Tg==
X-Forwarded-Encrypted: i=1; AHgh+RrPln7+KZu6/nyWteNpYj1huCIqnT6XkRGcKX52cwbYoS27EKbm9nV9c09ZxleIN2Ge1+ROLplERes=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAZB4RWFKKaBMhzTm/WIsYsFgqCf/vbx8zfb7Gy5Ew9UaCtrdF
	SFEYLRK3hy6zK72AEJ1V4Ev14LXb1w86tmJ+6qjVM7V/j9PneOL6qI4YRns1EG/3MK6KbqPgpw3
	QmIFGzw==
X-Received: from pljs12.prod.google.com ([2002:a17:903:3bac:b0:2ca:e163:e0c8])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:41ce:b0:2cf:afa5:b19a
 with SMTP id d9443c01a7336-2d0ca7f8e9amr186517945ad.11.1786059440120; Thu, 06
 Aug 2026 16:37:20 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:02 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-46-seanjc@google.com>
Subject: [PATCH v6 45/51] x86/paravirt: Mark __paravirt_set_sched_clock() as __init
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-33051d/1786059442-6DED24E9-0AC77DE5/0/0
X-purgate-type: clean
X-purgate-size: 2068

Annotate __paravirt_set_sched_clock() as __init, and make its wrapper
__always_inline to ensure sanitizers don't result in a non-inline version
hanging around.  All callers run during __init, and changing sched_clock
after boot would be all kinds of crazy.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/timer.h | 10 +++++-----
 arch/x86/kernel/tsc.c        |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index e97cd1ae03d1..96ae7feac47c 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -14,12 +14,12 @@ extern int no_timer_check;
 extern bool using_native_sched_clock(void);
 
 #ifdef CONFIG_PARAVIRT
-void __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
-				void (*save)(void), void (*restore)(void));
+void __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
+				       void (*save)(void), void (*restore)(void));
 
-static inline void paravirt_set_sched_clock(u64 (*func)(void),
-					    void (*save)(void),
-					    void (*restore)(void))
+static __always_inline void paravirt_set_sched_clock(u64 (*func)(void),
+						     void (*save)(void),
+						     void (*restore)(void))
 {
 	__paravirt_set_sched_clock(func, true, save, restore);
 }
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index d4f7cb127235..363145c83919 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -280,8 +280,8 @@ bool using_native_sched_clock(void)
 	return static_call_query(pv_sched_clock) == native_sched_clock;
 }
 
-void __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
-				void (*save)(void), void (*restore)(void))
+void __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
+				       void (*save)(void), void (*restore)(void))
 {
 	if (!stable)
 		clear_sched_clock_stable();
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385493.1627988 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iJ-0008V2-9o; Thu, 06 Aug 2026 23:41:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385493.1627988; Thu, 06 Aug 2026 23:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iJ-0008U8-5M; Thu, 06 Aug 2026 23:41:27 +0000
Received: by outflank-mailman (input) for mailman id 1385493;
 Thu, 06 Aug 2026 23:41:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3shp1agYKCRcF1xA6z3BB381.zB9K1A-01I1885FGF.K1ACEB61zG.BE3@flex--seanjc.bounces.google.com>)
 id 1ws7iH-0008Nb-Rw
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iH-00H1om-8Y
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:25 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3shp1agYKCRcF1xA6z3BB381.zB9K1A-01I1885FGF.K1ACEB61zG.BE3@flex--seanjc.bounces.google.com>)
 id 6a751b6a-5cb7-0a2a0a5109dd-0a2a45058b62-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:25 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3shp1agYKCRcF1xA6z3BB381.zB9K1A-01I1885FGF.K1ACEB61zG.BE3@flex--seanjc.bounces.google.com>)
 id 6a751ab3-4cb1-0a2a45050019-d155d2c6b8a6-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:24 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-84e375d9736so3450990b3a.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059443; x=1786664243; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=NcgEnPBxyGviYS1Y0BEogKtyt4exk2sJiTd88Re19eg=;
        b=gk79UyMXWHbVx8Tg7IcacASgySWpa/8r9P+UNNN10lXzRr0rRCNjsZ241i87iur94m
         kXlpfambj0vZ4aDfXBL3hYXwf5mKnZ2E4g2HeCALcLv8PjZiz3azvG9X6Kny5FclVUjL
         5B0Yl1up8lStw3KDb4u6h/ZLNXrnipkOimgf86rICGHF5aCo/BQxDn7G0KcSsgIQUBh+
         /8wZDNsoNBkHtz8MXYUxzcfyfVbxSBl2fuMgVUx2aa5DiRHw5QDjGcX2R9xQqgLstMV5
         gXwXP0F7y0nvA51e0Nh1jCtyb1jThSomHSkr7x00z7HT4dgpY+JHzv76Z/cjrdqK+2V0
         Vuig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059443; x=1786664243;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=NcgEnPBxyGviYS1Y0BEogKtyt4exk2sJiTd88Re19eg=;
        b=VjNkqZFhRQoZMrBfNT7KNRa1r5jsW8V0VFXUn9a1+PIThyoE5SyZBd1/PNAkuBKJ6p
         uWM6HfKIBroMcFShj1edGoezLU1zVsBr0JnIFYKqzjhXb9y5f9ZYysPHoT6s7Ul6+AZi
         bgph83kxDKKXt3/i8pa0fzg9VC5ThGiEfsEgUQI66CSBk1ChS3L/musn2g0gFX0Ccxx5
         85XylLC8W0DPBIaoVybYKsVb1nkkGahLaVpGpmxRUOJJPTkGn4BPD2S5vJtV0FFz8xGY
         M/xSoLHfYBSMY3tRxoQDlYuG0fgZNTmRQIDUOBXF9ryiQLiG1fxhXHnpVeAvohTbbbtT
         LNTg==
X-Forwarded-Encrypted: i=1; AHgh+RoFvNBDNGWUwZJHIN8zbhFn779uCQM809fUfj6m/JBfhm5lO1mKJpvRRfsGbnyTvMtxoCAINonAtNQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzXB72d8kGe9B7dVIPWZW/42lrYKvX/h2Gag9h3gtBolp9EUKWI
	hk/nZFBt1DyK+p7hqH1E/Om1pA6jwG1eBo/K4k7ZY3Hmnk2dWciHDp2+uv7AomVyFymoAonHouL
	1XvZ5yA==
X-Received: from pfbcw11.prod.google.com ([2002:a05:6a00:450b:b0:848:51a7:e8bb])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2999:b0:848:67ca:bfd
 with SMTP id d2e1a72fcca58-84f2dff1913mr22778991b3a.16.1786059442569; Thu, 06
 Aug 2026 16:37:22 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:04 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-48-seanjc@google.com>
Subject: [PATCH v6 47/51] x86/paravirt: Don't use a PV sched_clock in CoCo
 guests with trusted TSC
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c201ff/1786059444-71EA92A1-D7CF7710/0/0
X-purgate-type: clean
X-purgate-size: 1384

Silently ignore attempts to switch to a paravirt sched_clock when running
as a CoCo guest with trusted TSC.  In hand-wavy theory, a misbehaving
hypervisor could attack the guest by manipulating the PV clock to affect
guest scheduling in some weird and/or predictable way.  More importantly,
reading TSC on such platforms is faster than any PV clock, and sched_clock
is all about speed.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/tsc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index fcf331ffd874..c0e4485484f2 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -283,6 +283,15 @@ bool using_native_sched_clock(void)
 int __init __paravirt_set_sched_clock(u64 (*func)(void), bool stable,
 				      void (*save)(void), void (*restore)(void))
 {
+	/*
+	 * Don't replace TSC with a PV clock when running as a CoCo guest and
+	 * the TSC is secure/trusted; PV clocks are emulated by the hypervisor,
+	 * which isn't in the guest's TCB.
+	 */
+	if (cc_platform_has(CC_ATTR_GUEST_SNP_SECURE_TSC) ||
+	    boot_cpu_has(X86_FEATURE_TDX_GUEST))
+		return -EPERM;
+
 	if (!stable)
 		clear_sched_clock_stable();
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385494.1627998 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iK-0000Mf-Li; Thu, 06 Aug 2026 23:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385494.1627998; Thu, 06 Aug 2026 23:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iK-0000Lt-Ej; Thu, 06 Aug 2026 23:41:28 +0000
Received: by outflank-mailman (input) for mailman id 1385494;
 Thu, 06 Aug 2026 23:41:27 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3sxp1agYKCRgG2yB704CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--seanjc.bounces.google.com>)
 id 1ws7iI-0008T8-W7
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iI-00EM9p-D4
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:26 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3sxp1agYKCRgG2yB704CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--seanjc.bounces.google.com>)
 id 6a751b54-bab6-0a2a0a5309dd-0a2a450297c0-18
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:26 +0200
Received: from [209.85.215.199] (helo=mail-pg1-f199.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3sxp1agYKCRgG2yB704CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--seanjc.bounces.google.com>)
 id 6a751ab4-6ca4-0a2a45020019-d155d7c7b07f-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:25 +0200
Received: by mail-pg1-f199.google.com with SMTP id
 41be03b00d2f7-cb733fc5024so3799739a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059444; x=1786664244; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=ZEuUzNS+h+uJbnucj4BSLPHP7Njp50j+oXkHsgjPk/g=;
        b=L6L5D/GQ3gaL/LVb4vPxChzBzNid+DgXTN5AY8HZiN9dR+uGu6op0q1L8Q0GR21wd3
         rQ6AgC2JasMNQ0Ui75vzttHkhcOkXynjG8okz7vSWrV1ro5SMxw7QilFAUrOHRykWbjG
         H5F6npHvSPRyC6gmkfuGPbfRuHJciEanKtS7++SJxFDZI/6vOjJ6HMMFeUKI4LXbcHEK
         Wij7OqV6yM0U0tlUyrre4x6q7tf5gIchSsqCICTXRSE1PL8iMopd/wC1K9Suoq9EJjUD
         Iplv5T6lXlSr94GG1mu/z4JiMjcgXsnLIQy88NiJBBhM8Eh19iv4M7OmDNaklChYMbSV
         h/yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059444; x=1786664244;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=ZEuUzNS+h+uJbnucj4BSLPHP7Njp50j+oXkHsgjPk/g=;
        b=KOyo6VN4wwQmVBmhR9zKHObQSuAzn1rQ4jXlYcpG7A2qBGyXpirqfvcxCRR6mgJaCA
         mgv+S2iwAIroB2jpVSzUYH4t38IiQk+MjV3AVXL3rgEw4lg0oHhR7NAb9gcVq8M0X+Hb
         nuck6YbcdbzXYMHkb8QuCUtLIkWKMdecwwYe5UztYKMkP1Jw8IS7Af1ViI6aluPuYbtn
         ex2S7g3s+OjGG4BLbNl4r5f8FNo9ob5YM/yvvQLh4NvoZc5y0slj2IMU16sqdY7e4GgP
         4NeJkrCWRQuL//1mdGYbHbFz5n4+qY1NDCXUjsDykV+YxYswfsbMd25Dqro7H0d7iKnN
         Zb1g==
X-Forwarded-Encrypted: i=1; AHgh+RpB54QCTu930IlnMc0AaUIMkXWEWb2PV2fhCrxjhOAqSvRmFdS/cZQhsJjtNXHI1msYth4xvnrGfxs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzrH40Sr805+PNleITevinm9W+lyRpTzwzuikwSoCyv4pNrqoSl
	QBxEHZ2/lQugKf/OO/mzZF4OvI7Hf0+w7kgPCOlIBwscj+WEo9c1PIyS8TYp14j6VDNBAFG0kwO
	j1WHCgg==
X-Received: from pgng29.prod.google.com ([2002:a63:375d:0:b0:c9a:c533:8329])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:4309:b0:3c8:ead5:bf7b
 with SMTP id adf61e73a8af0-3cb85ded991mr21268446637.4.1786059443651; Thu, 06
 Aug 2026 16:37:23 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:05 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-49-seanjc@google.com>
Subject: [PATCH v6 48/51] x86/kvmclock: Use TSC for sched_clock if it's
 constant and non-stop
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-720697/1786059446-67ABD2AC-0AC34026/13/0
X-purgate-type: clean
X-purgate-size: 2191

Prefer the TSC over kvmclock for sched_clock if the TSC is constant and
nonstop.  I.e. use the same criteria as tweaking the clocksource rating so
that TSC is preferred over kvmclock.  Per the below comment from
native_sched_clock(), sched_clock is more tolerant of slop than
clocksource; using TSC for clocksource but not sched_clock makes little to
no sense, especially now that KVM CoCo guests with a trusted TSC use TSC,
not kvmclock.

        /*
         * Fall back to jiffies if there's no TSC available:
         * ( But note that we still use it if the TSC is marked
         *   unstable. We do this because unlike Time Of Day,
         *   the scheduler clock tolerates small errors and it's
         *   very important for it to be as fast as the platform
         *   can achieve it. )
         */

The only advantage of using kvmclock is that doing so allows for early
and common detection of PVCLOCK_GUEST_STOPPED, but that code has been
broken for over two years with nary a complaint, i.e. it can't be
_that_ valuable.  And as above, certain types of KVM guests are losing
the functionality regardless, i.e. acknowledging PVCLOCK_GUEST_STOPPED
needs to be decoupled from sched_clock() no matter what.

Link: https://lore.kernel.org/all/Z4hDK27OV7wK572A@google.com
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 22e8855fcd4d..bc98ebb8587d 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -396,7 +396,6 @@ void __init kvmclock_init(bool prefer_tsc)
 			 PVCLOCK_TSC_STABLE_BIT;
 	}
 
-	kvm_sched_clock_init(stable);
 
 	if (!x86_init.hyper.get_tsc_khz)
 		x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
@@ -416,6 +415,8 @@ void __init kvmclock_init(bool prefer_tsc)
 	 */
 	if (prefer_tsc)
 		kvm_clock.rating = 299;
+	else
+		kvm_sched_clock_init(stable);
 
 	clocksource_register_hz(&kvm_clock, NSEC_PER_SEC);
 	pv_info.name = "KVM";
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385500.1628007 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iL-0000da-Tm; Thu, 06 Aug 2026 23:41:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385500.1628007; Thu, 06 Aug 2026 23:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iL-0000cu-OB; Thu, 06 Aug 2026 23:41:29 +0000
Received: by outflank-mailman (input) for mailman id 1385500;
 Thu, 06 Aug 2026 23:41:28 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3tBp1agYKCRkH3zC815DD5A3.1DBM3C-23K3AA7HIH.M3CEGD831I.DG5@flex--seanjc.bounces.google.com>)
 id 1ws7iK-0000Hg-CK
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iJ-00EM9p-Lx
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:27 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3tBp1agYKCRkH3zC815DD5A3.1DBM3C-23K3AA7HIH.M3CEGD831I.DG5@flex--seanjc.bounces.google.com>)
 id 6a751b7a-bab6-0a2a0a5309dd-0a2a4504bd98-22
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:27 +0200
Received: from [209.85.214.200] (helo=mail-pl1-f200.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3tBp1agYKCRkH3zC815DD5A3.1DBM3C-23K3AA7HIH.M3CEGD831I.DG5@flex--seanjc.bounces.google.com>)
 id 6a751ab5-b57f-0a2a45040019-d155d6c8e0ce-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:27 +0200
Received: by mail-pl1-f200.google.com with SMTP id
 d9443c01a7336-2cfca8558d2so38193835ad.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059445; x=1786664245; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=/TxUyuE9/koLQyW6zcM5dMaQ+pcBou93eYQoJAAWN+E=;
        b=py92CSIgyIhcjgfTx2xOs1Vcu3Mzaz8ATWpS5/tETq28W/m6sIKylWGyEndVB8Rvnr
         tfN3y+ayFk984f/50g3cHAz6iJUHhASw/ocOVFqfOW0KUTUmq423VpuaI9pFoRrqOPzo
         FvSNiM922zAjK7Sb8hBIoC6315AX6aG9htVQ5Ll9DtTUHUts07NbMLFd6e34ZBqtJY9k
         BGA7zJPbjh0QP7OhJ5TUCQCpa+ieAvCAMvDLC7j06BjveIgpf1LlAzDdtzaKvyeGxt0w
         N8RM3Fa2OWxsUfZFzQ/4BSgDNpSTjdjj2v7eNIXtwgwYDAhKivBwM9I2SZAXXe7m1VQ3
         UHAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059445; x=1786664245;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=/TxUyuE9/koLQyW6zcM5dMaQ+pcBou93eYQoJAAWN+E=;
        b=HB/zEO4WrAkbFIiMtOmap7ioFIEX/mVao0Ri/eMJybRuaRtGX9ZnehfdqLHXFmjez1
         Xcbupq5qemb2tMEPjNgATOyCtqLZs9NIwnsVBLsWquP5wLAHay7f7mlQYIrB7iFlnh3F
         8LsAv4i10esxlBIAeq0odME2sz+cSQqg8oPGBPm0ftFR1jL8yr9foVsf1jpGGTpkF5lm
         ZmEQXmmOT97FM3a+z1/LPou1SPn97Wss4U0E7oHGWNo3mDtVM7he44axRH8/IziUF2Wq
         lb/cBiJaboOuC55YreYeqOzR7UAhY75AyNqDkwrGb2d8y979cs9C21xoM2dkSDGYPsTs
         W6ww==
X-Forwarded-Encrypted: i=1; AHgh+RqdIkRmN+ymEEYUsy3nAxZy0Dk3M2jHPzRVpnbWMHTTh4U+inHvzxJk0y07btHe+iUA3I8A/HGY9fo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwM9poZNYrEdq4ijRdwTIYGKKK03fDllfdx11zmA1lVCF3uj5qe
	CHUc1J0Wkc9XMOGlOuiM9amgkn50IRmrK68P7VaOgHE9jsSgbEbenY2mIcYTKy0LSjv+tAuVE53
	mFcwxgA==
X-Received: from plgi9.prod.google.com ([2002:a17:902:cf09:b0:2c7:e06e:86f6])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:c402:b0:2c9:c952:6e9
 with SMTP id d9443c01a7336-2d0ca7b024fmr202039245ad.2.1786059444816; Thu, 06
 Aug 2026 16:37:24 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:06 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-50-seanjc@google.com>
Subject: [PATCH v6 49/51] x86/kvmclock: Plumb in AP-online and BSP-resume to
 kvmlock, for documentation
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ebf023/1786059447-50AD8B50-855BEA99/0/0
X-purgate-type: clean
X-purgate-size: 4589

Invoke kvmclock_cpu_action() with AP_ONLINE and BSP_RESUME, even though
kvmclock doesn't need to do anything in either case, so that the asymmetry
of kvmclock is a detail buried in kvmclock, and to explicitly document
that doing nothing during those phases is intentional and correct.

For all intents and purposes, no functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/kvm_para.h |  2 ++
 arch/x86/kernel/kvm.c           | 22 +++++++++++++-------
 arch/x86/kernel/kvmclock.c      | 37 ++++++++++++++++++++++++++-------
 3 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 08686ff19caa..763ed017738a 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -120,6 +120,8 @@ static inline long kvm_sev_hypercall3(unsigned int nr, unsigned long p1,
 #ifdef CONFIG_KVM_GUEST
 enum kvm_guest_cpu_action {
 	KVM_GUEST_BSP_SUSPEND,
+	KVM_GUEST_BSP_RESUME,
+	KVM_GUEST_AP_ONLINE,
 	KVM_GUEST_AP_OFFLINE,
 	KVM_GUEST_SHUTDOWN,
 };
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 9c0b2fc98cc9..b954238b09fc 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -474,18 +474,24 @@ static void kvm_guest_cpu_offline(enum kvm_guest_cpu_action action)
 	kvmclock_cpu_action(action);
 }
 
+static void __kvm_cpu_online(unsigned int cpu, enum kvm_guest_cpu_action action)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+	kvmclock_cpu_action(action);
+	kvm_guest_cpu_init();
+	local_irq_restore(flags);
+}
+
+#ifdef CONFIG_SMP
+
 static int kvm_cpu_online(unsigned int cpu)
 {
-	unsigned long flags;
-
-	local_irq_save(flags);
-	kvm_guest_cpu_init();
-	local_irq_restore(flags);
+	__kvm_cpu_online(cpu, KVM_GUEST_AP_ONLINE);
 	return 0;
 }
 
-#ifdef CONFIG_SMP
-
 static DEFINE_PER_CPU(cpumask_var_t, __pv_cpu_mask);
 
 static bool pv_tlb_flush_supported(void)
@@ -752,7 +758,7 @@ static int kvm_suspend(void *data)
 
 static void kvm_resume(void *data)
 {
-	kvm_cpu_online(raw_smp_processor_id());
+	__kvm_cpu_online(raw_smp_processor_id(), KVM_GUEST_BSP_RESUME);
 
 #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
 	if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL) && has_guest_poll)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index bc98ebb8587d..842f38c5f6ca 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -150,7 +150,7 @@ static void kvm_save_sched_clock_state(void)
 #ifdef CONFIG_SMP
 static void kvm_setup_secondary_clock(void)
 {
-	kvm_register_clock("secondary cpu clock");
+	kvm_register_clock("secondary cpu, startup");
 }
 #endif
 
@@ -174,13 +174,34 @@ static void kvmclock_resume(struct clocksource *cs)
 
 void kvmclock_cpu_action(enum kvm_guest_cpu_action action)
 {
-	/*
-	 * Don't disable kvmclock on the BSP during suspend.  If kvmclock is
-	 * being used for sched_clock, then it needs to be kept alive until the
-	 * last minute, and restored as quickly as possible after resume.
-	 */
-	if (action != KVM_GUEST_BSP_SUSPEND)
+	switch (action) {
+		/*
+		 * The BSP's clock is managed via clocksource suspend/resume,
+		 * to ensure it's enabled/disabled when timekeeping needs it
+		 * to be, e.g. before reading wallclock (which uses kvmclock).
+		 */
+	case KVM_GUEST_BSP_SUSPEND:
+	case KVM_GUEST_BSP_RESUME:
+		break;
+	case KVM_GUEST_AP_ONLINE:
+		/*
+		 * Secondary CPUs use a dedicated hook to enable kvmclock early
+		 * during bringup, there's nothing to be done during CPU online
+		 * (which runs at CPUHP_AP_ONLINE_DYN).  When kvmclock is being
+		 * used as sched_clock, kvmclock must be enabled *very* early,
+		 * and even when kvmclock is "only" being used for the main
+		 * clocksource, it still needs to be enabled long before the
+		 * dynamic CPUHP calls are made.
+		 */
+		break;
+	case KVM_GUEST_AP_OFFLINE:
+	case KVM_GUEST_SHUTDOWN:
 		kvmclock_disable();
+		break;
+	default:
+		WARN_ON_ONCE(1);
+		break;
+	}
 }
 
 /*
@@ -382,7 +403,7 @@ void __init kvmclock_init(bool prefer_tsc)
 		msr_kvm_system_time, msr_kvm_wall_clock);
 
 	this_cpu_write(hv_clock_per_cpu, &hv_clock_boot[0]);
-	kvm_register_clock("primary cpu clock");
+	kvm_register_clock("primary cpu, online");
 	pvclock_set_pvti_cpu0_va(hv_clock_boot);
 
 	if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT)) {
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385503.1628016 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iN-0000wk-FK; Thu, 06 Aug 2026 23:41:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385503.1628016; Thu, 06 Aug 2026 23:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iN-0000vE-8F; Thu, 06 Aug 2026 23:41:31 +0000
Received: by outflank-mailman (input) for mailman id 1385503;
 Thu, 06 Aug 2026 23:41:30 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3txp1agYKCRwK62FB48GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--seanjc.bounces.google.com>)
 id 1ws7iM-0000k9-Er
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iL-00EM9p-Ra
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:29 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3txp1agYKCRwK62FB48GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--seanjc.bounces.google.com>)
 id 6a751b7a-bab6-0a2a0a5309dd-0a2a4504bd98-24
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:29 +0200
Received: from [209.85.215.200] (helo=mail-pg1-f200.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3txp1agYKCRwK62FB48GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--seanjc.bounces.google.com>)
 id 6a751ab8-b57f-0a2a45040019-d155d7c8b14a-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:29 +0200
Received: by mail-pg1-f200.google.com with SMTP id
 41be03b00d2f7-ca8aee88725so3901087a12.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059447; x=1786664247; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=WG6tzs8/D5vUVAMD7J6BXfy7SNaM+XPXtfc+RTelhM8=;
        b=uilflh9oNcI4wX1XQh3mgOAdnBE24/Vkfwf1yWU7PcpqnqFe/kuZbMpRi1pLfb2KZ0
         VZ/LwfvIbGr73tCz8kC9XDoP4N0aL7L1e/lfHrCAK/sJ/CNF/ejoaiHDbv14ZZmsR+Qi
         0akxKxKPHK6tNL4fzdTwl7wdvSb2PahL+HPR6675LOh+Geqya/hbBQjlJqwcGq/ZvXKW
         NxCY6munzfMmtwwiEu714ucw9sj+5PcGW+jlA/GefI5t1B62/7jQhRcfu4ZhJvrM4fIq
         nuyrXU/spECm3FpJo4AkqFiS14fSP+4ADS3yoBCQm4ap8b0lGKt3Kb6Xc4puF3yeATII
         z3pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059447; x=1786664247;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=WG6tzs8/D5vUVAMD7J6BXfy7SNaM+XPXtfc+RTelhM8=;
        b=fUOnWZXl9RGTuQtHKDL3QLa22mkfWAuhmYhlgtxAn4vFoiTWSFtkqX4foOxS1zR1Kd
         OwDB52Uxa7q3U8MSVDCkEWc0yv66xLTOmnHp3z3kiKhAw4mplXp5tQMM4EiqN/mNxe2u
         wj0+eELNirKDqfTp73vaUa5pNOPvHMFHPLHuCDi1zYllBUBw9t73kXR5lrKA8bXCnBiF
         3GvdG8ysiSgT+BPZTQw+aU7e/kUs3C3fTOznQKyUEf7hl4j9JSgBphAbKjuXyWxUUt1K
         igJpmnoPs6njjS0DGV/WLbxbb0YueZhGpH/wwntUfT4SGd/TZCnXzjnGjdv9TkcBTtfl
         GkpQ==
X-Forwarded-Encrypted: i=1; AHgh+Rqpu1q9OfFdUa8n/Gtrq3JOWx3bUVKLY5vx1YjDRDZ/2wA7HJzHNWg2u9HHrRMSKyJt/CEnEJEspdI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhT79nc8LkzpxtycXFq4cT+jFMNHCgivAamPwH57Hkmnw0w5kT
	RzMB3Sdun9HXl21ZVO8Kz7oTPQ//0lq0ZFUVr7iBNvhBKgIsm6Oe47ehehSOOfRtvv2pO8VkwaL
	4QWXmlw==
X-Received: from pjgg14.prod.google.com ([2002:a17:90b:57ce:b0:380:f969:825e])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2590:b0:38f:2168:b9cb
 with SMTP id 98e67ed59e1d1-3903c572a05mr18788898a91.9.1786059447175; Thu, 06
 Aug 2026 16:37:27 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:36:08 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-52-seanjc@google.com>
Subject: [PATCH v6 51/51] x86/kvm: Get local APIC bus frequency from PV CPUID
 Timing Info
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ebf023/1786059449-C24CBB50-6CCD359A/13/0
X-purgate-type: clean
X-purgate-size: 1406

When running as a KVM guest with PV timing info provided by the host,
stuff the APIC timer period/frequency with the local APIC bus frequency
reported in CPUID.0x40000010.EBX instead of trying to calibrate/guess the
frequency.

See Documentation/virt/kvm/x86/cpuid.rst for details.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b954238b09fc..edeff41c03c2 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -992,7 +992,7 @@ static void __init kvm_init_platform(void)
 		.mask_lo = (u32)(~(SZ_4G - tolud - 1)) | MTRR_PHYSMASK_V,
 		.mask_hi = (BIT_ULL(boot_cpu_data.x86_phys_bits) - 1) >> 32,
 	};
-	u32 timing_info_leaf;
+	u32 timing_info_leaf, apic_khz;
 	bool tsc_is_reliable;
 
 	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
@@ -1054,6 +1054,11 @@ static void __init kvm_init_platform(void)
 			x86_init.hyper.get_tsc_khz = kvm_get_tsc_khz;
 			x86_init.hyper.get_cpu_khz = kvm_get_tsc_khz;
 		}
+
+		/* The leaf also includes the local APIC bus/timer frequency.*/
+		apic_khz = cpuid_ebx(timing_info_leaf);
+		if (apic_khz)
+			apic_set_timer_frequency_khz(apic_khz, "KVM hypervisor");
 	}
 
 	/*
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385528.1628034 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7id-0002Ot-39; Thu, 06 Aug 2026 23:41:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385528.1628034; Thu, 06 Aug 2026 23:41:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ic-0002Nb-TD; Thu, 06 Aug 2026 23:41:46 +0000
Received: by outflank-mailman (input) for mailman id 1385528;
 Thu, 06 Aug 2026 23:41:45 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3iBp1agYKCesfRNaWPTbbTYR.PbZkRa-QRiRYYVfgf.kRacebWRPg.beT@flex--seanjc.bounces.google.com>)
 id 1ws7ia-00021x-V2
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ia-00EMEo-Bf
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:44 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3iBp1agYKCesfRNaWPTbbTYR.PbZkRa-QRiRYYVfgf.kRacebWRPg.beT@flex--seanjc.bounces.google.com>)
 id 6a751b7b-e002-0a2a0a5209dd-0a2a4507ba7e-24
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:44 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3iBp1agYKCesfRNaWPTbbTYR.PbZkRa-QRiRYYVfgf.kRacebWRPg.beT@flex--seanjc.bounces.google.com>)
 id 6a751a89-b4ea-0a2a45070019-d155d2c6c536-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:43 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-84f0d3ab2f4so2320951b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059401; x=1786664201; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=xHY7WhZzoR4x+WtFqsSoEfBU4PaM9Rhz3R83jbux6ZU=;
        b=l3AxvYlcIv5t4p50ACKgOr8BmfXFznkGjO5XzZmRCFmzcGJq3TSAPfjGHop+KsftGV
         kTKG6IdfHqwUDcy4EJyLFd98+3NdcqEnL+9scHbYGCu15m6NQQ6GdVabg5T0chaQKLuN
         i/Q6tU/MJuYI1DTZPYUqlyqZxHkqhmj/qmrPrkNbxaMCt1gEQmrf36QGq8PKMoIWEtG1
         Ke1BAcIkU93DqZFd7UPXpEaPccAk1xpK5fBr06eGQU4yTR47oT6W7uZCnIZljhUTMlhv
         9bFy3PlZXzyKnUYVY+McaJqB+KkSnz+P7Z0HwZ3XxgAOqGU4Ib0MNzM2FicFnijUzbVx
         TykA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059401; x=1786664201;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=xHY7WhZzoR4x+WtFqsSoEfBU4PaM9Rhz3R83jbux6ZU=;
        b=TcgjIMVicxErgAmMoOcd3icYrz/FER5Hi5DAmOHGPieLjVRf72NZdsqCweDz4PVbim
         GNCQz/bJhio2c0fsXdPJuUKH48/KE91Os80s6p93I1/uemsDnW4UmzrWxZTkQWvgQHVG
         EAqa/sqstbxZW4cFT2IurULTAMQZ5cynCqoInAnKh+hRxv9DpC2o2ZFCJtz51bPJhXs/
         U+aZ+YaEIwnMEzZVBfFrTH0GEUIMk99PB3WPOQ4SK4l+iSliq20BKFbUvwad/90NcUHd
         1L0hYFBRTf+c65HFP3KYM9Dk+/1ABsDQUUew09lNgc7VKjR9/2BonBGxIv2/sE/iWoPd
         kt/g==
X-Forwarded-Encrypted: i=1; AHgh+RqaWv1QSgaOPxyuzXfUuA1V91XGUinzCJKMZOI6M6V4Wvs/rDJtFL7eWEpdgXoOC21dGMFlY0gz00A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3RhHNuXPlQdI6Sl8ypKy6H/RkexgUAiPqhIBW9R9Ecsm0JvCY
	9nsseWsu+rQL5hIFW+RWrbUpjS4yDts9Z+zrNNYNJeZqy0KIMdSm9/wEbj0fSigb4uSGywcdpqQ
	aBoBkdg==
X-Received: from pfbbu11.prod.google.com ([2002:a05:6a00:410b:b0:848:8b16:23d6])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2383:b0:842:5b66:3c7f
 with SMTP id d2e1a72fcca58-84f2dedf356mr20263411b3a.0.1786059400868; Thu, 06
 Aug 2026 16:36:40 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:31 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-15-seanjc@google.com>
Subject: [PATCH v6 14/51] x86/tsc: Consolidate forcing of X86_FEATURE_TSC_KNOWN_FREQ
 for PV code
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059403-A50CDAE4-3B769141/0/0
X-purgate-type: clean
X-purgate-size: 5920

Now that all paravirt code that explicitly specifies the TSC frequency
also sets X86_FEATURE_TSC_KNOWN_FREQ, replace all of the one-off code
and simply set X86_FEATURE_TSC_KNOWN_FREQ if the TSC frequency is known.

Do NOT force set TSC_KNOWN_FREQ if the "known" TSC frequency was provided
by the user.  Per commit bd35c77e32e4 ("x86/tsc: Add tsc_early_khz command
line parameter"), one of the goals of the param is to allow the refined
calibration work "to do meaningful error checking".

No functional change intended.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/coco/sev/core.c       |  1 -
 arch/x86/coco/tdx/tdx.c        |  1 -
 arch/x86/kernel/cpu/acrn.c     |  1 -
 arch/x86/kernel/cpu/mshyperv.c |  1 -
 arch/x86/kernel/cpu/vmware.c   |  2 --
 arch/x86/kernel/jailhouse.c    |  1 -
 arch/x86/kernel/kvmclock.c     |  1 -
 arch/x86/kernel/tsc.c          | 13 ++++++++++---
 arch/x86/xen/time.c            |  1 -
 9 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index bc5ae9ef74da..72313b36b6f5 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2027,7 +2027,6 @@ unsigned int __init snp_secure_tsc_init(void)
 
 	secrets = (__force struct snp_secrets_page *)mem;
 
-	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
 
 	rdmsrq(MSR_AMD64_GUEST_TSC_FREQ, tsc_freq_mhz);
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index ec28a15e26ac..21a574e60e0f 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -1203,7 +1203,6 @@ unsigned int __init tdx_tsc_init(void)
 
 	/* TSC is the only reliable clock in TDX guest */
 	setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
-	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 
 	return info.crystal_khz * info.numerator / info.denominator;
 }
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index 3818f6ae0629..dc71a6fdd461 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -40,7 +40,6 @@ static void __init acrn_init_platform(void)
 	if (acrn_tsc_khz_cpuid) {
 		x86_init.hyper.get_tsc_khz = acrn_get_tsc_khz;
 		x86_init.hyper.get_cpu_khz = acrn_get_tsc_khz;
-		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	}
 }
 
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 4a0cdda0c49e..3bca987e05c3 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -575,7 +575,6 @@ static void __init ms_hyperv_init_platform(void)
 	    ms_hyperv.misc_features & HV_FEATURE_FREQUENCY_MSRS_AVAILABLE) {
 		x86_init.hyper.get_tsc_khz = hv_get_tsc_khz;
 		x86_init.hyper.get_cpu_khz = hv_get_tsc_khz;
-		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	}
 
 	if (ms_hyperv.priv_high & HV_ISOLATION) {
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 3f1dab69d90e..cbe8b59ab79f 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -390,8 +390,6 @@ static void __init vmware_set_capabilities(void)
 {
 	setup_force_cpu_cap(X86_FEATURE_CONSTANT_TSC);
 	setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
-	if (vmware_tsc_khz)
-		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMCALL)
 		setup_force_cpu_cap(X86_FEATURE_VMCALL);
 	else if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMMCALL)
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 595cd28f9a9f..8107c28eb2bc 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -255,7 +255,6 @@ static void __init jailhouse_init_platform(void)
 	pr_debug("Jailhouse: PM-Timer IO Port: %#x\n", pmtmr_ioport);
 
 	precalibrated_tsc_khz = setup_data.v1.tsc_khz;
-	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 
 	pci_probe = 0;
 
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 4f8299303a19..35a879d33e9e 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -138,7 +138,6 @@ static inline void kvm_sched_clock_init(bool stable)
  */
 static unsigned int __init kvm_get_tsc_khz(void)
 {
-	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	return pvclock_tsc_khz(this_cpu_pvti());
 }
 
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 7f1ca6df0004..f42872c9ae99 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1541,11 +1541,18 @@ void __init tsc_early_init(void)
 	if (!known_tsc_khz && x86_init.hyper.get_tsc_khz)
 		known_tsc_khz = x86_init.hyper.get_tsc_khz();
 
+	/*
+	 * Mark the TSC frequency as known if it was obtained from a hypervisor
+	 * or trusted firmware.
+	 */
+	if (known_tsc_khz)
+		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
+
 	/*
 	 * Ignore the user-provided TSC frequency if the exact frequency was
-	 * obtained from trusted firmware or the hypervisor, as the user-
-	 * provided frequency is intended as a "starting point", not a known,
-	 * guaranteed frequency.
+	 * obtained from trusted firmware or the hypervisor, and don't mark the
+	 * frequency as known, as the user-provided frequency is intended as a
+	 * "starting point", not a known, guaranteed frequency
 	 */
 	if (!known_tsc_khz)
 		known_tsc_khz = tsc_early_khz;
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1adb44fdddb2..487ad838c441 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -43,7 +43,6 @@ static unsigned int __init xen_tsc_khz(void)
 	struct pvclock_vcpu_time_info *info =
 		&HYPERVISOR_shared_info->vcpu_info[0].time;
 
-	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	return pvclock_tsc_khz(info);
 }
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385522.1628026 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ia-00021T-QN; Thu, 06 Aug 2026 23:41:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385522.1628026; Thu, 06 Aug 2026 23:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ia-000206-Jg; Thu, 06 Aug 2026 23:41:44 +0000
Received: by outflank-mailman (input) for mailman id 1385522;
 Thu, 06 Aug 2026 23:41:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3hxp1agYKCeoeQMZVOSaaSXQ.OaYjQZ-PQhQXXUefe.jQZbdaVQOf.adS@flex--seanjc.bounces.google.com>)
 id 1ws7iZ-0001u2-8S
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iY-00H1om-LX
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:42 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3hxp1agYKCeoeQMZVOSaaSXQ.OaYjQZ-PQhQXXUefe.jQZbdaVQOf.adS@flex--seanjc.bounces.google.com>)
 id 6a751b81-5cb7-0a2a0a5109dd-0a2a450b92be-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:42 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3hxp1agYKCeoeQMZVOSaaSXQ.OaYjQZ-PQhQXXUefe.jQZbdaVQOf.adS@flex--seanjc.bounces.google.com>)
 id 6a751a88-b7e8-0a2a450b0019-d155d2c8a497-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:41 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-848474825ffso2105024b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059400; x=1786664200; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=kmrkRlf4iOUyRYugkcn9gxIXBFL0cMozIwMb4/CeDNQ=;
        b=WxEH38kt8trdGNMyInAbF5tr2ZeIhc6gKC3b0nC1gjlTOkmEGr8zGh6rlHvqOGqo31
         SBA2xCvvczxNopG3jCVl6MQ2s1xvFMiETO1XNST+HX7kv4JJrMMpPuDk9mjDjUszAg0q
         XqQucByNypUdwm4AWh7162V1j4B3CqjkK3fS6n7ihH78jYrSAzjku35tM3kcTKwQwJPl
         rKYHTcQKZS7W1PHBR9kdM8iFyv82ZZY1OYfTqzNl2x7GaEXQRfJBdsZ04pf13cjHK358
         Tf+njsvjKeQyDb01OhVLdZ4DLIFxrX++b3GKWDe4g+/rGscUNxpkGUhcKCusD36VXUKX
         5vCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059400; x=1786664200;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=kmrkRlf4iOUyRYugkcn9gxIXBFL0cMozIwMb4/CeDNQ=;
        b=L/dY02vG3ogMwrTh7AeBk7JvtnNlLY+PKS5uYQahdoS5hEeysL+3euuOKPgKVH9e4M
         SiLTirc7AZbqwC5lLowJXY0Y/355o3jUbOHt6GW8M9n3y3R4HkKyykH0MJujLlhvBsqL
         wMVpdiHa9OfGxixl2wVRXwbQKwLSIdsTuSMsgKIp8mATPfylXGkpd4pn+zgbb2QTtrio
         BQ4X7mTZSZ5de8C91PoAevtwncI8Q9briNl9XqvCyd64gxsd5sRZJcyPztqiywJ6kvAx
         VN2iOz4uLBwNY4R1KrNi+08UIMH3sTuZyIx12tQINs+r5HDyz6JSLshVptTX3D9sUsEb
         W93Q==
X-Forwarded-Encrypted: i=1; AHgh+RoZrF8/hlPQcEmlruUHLlkQN/avZ1P1wBOcw/kr9XggM1GkCaNzEB/NGzDmy3r568/8b7LWHb+758k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyq97ujbmtdgKd1l4wxcld/rR5bXsY6XkGTxRhTlej4u52MEuRo
	b1m+zZ10vIOlXtUBcYqf+yA5pWlr27f457fcqwN0+x0kr5Xq4VMDqguO8DphNU/C4juzUgv/IHF
	35ubDbQ==
X-Received: from pfbcz9.prod.google.com ([2002:aa7:9309:0:b0:847:aa6c:47fc])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:4648:b0:842:63f5:d097
 with SMTP id d2e1a72fcca58-84f41ba51c5mr11209793b3a.3.1786059399712; Thu, 06
 Aug 2026 16:36:39 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:30 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-14-seanjc@google.com>
Subject: [PATCH v6 13/51] x86/acrn: Mark TSC frequency as known when using
 ACRN for calibration
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-42698a/1786059402-A9EC69EA-8845AC6D/0/0
X-purgate-type: clean
X-purgate-size: 812

Mark the TSC frequency as known when using ACRN's PV CPUID information.
Per commit 81a71f51b89e ("x86/acrn: Set up timekeeping") and common sense,
the TSC freq is explicitly provided by the hypervisor.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/cpu/acrn.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index dc71a6fdd461..3818f6ae0629 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -40,6 +40,7 @@ static void __init acrn_init_platform(void)
 	if (acrn_tsc_khz_cpuid) {
 		x86_init.hyper.get_tsc_khz = acrn_get_tsc_khz;
 		x86_init.hyper.get_cpu_khz = acrn_get_tsc_khz;
+		setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 	}
 }
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385540.1628043 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ij-00034B-Ef; Thu, 06 Aug 2026 23:41:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385540.1628043; Thu, 06 Aug 2026 23:41:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ij-00033Z-AH; Thu, 06 Aug 2026 23:41:53 +0000
Received: by outflank-mailman (input) for mailman id 1385540;
 Thu, 06 Aug 2026 23:41:51 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3kBp1agYKCfMnZVieXbjjbgZ.XjhsZi-YZqZggdnon.sZikmjeZXo.jmb@flex--seanjc.bounces.google.com>)
 id 1ws7ih-0002wK-CD
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ig-008OCw-PP
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:50 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3kBp1agYKCfMnZVieXbjjbgZ.XjhsZi-YZqZggdnon.sZikmjeZXo.jmb@flex--seanjc.bounces.google.com>)
 id 6a751ba5-2eae-0a2a0a5409dd-0a2a450a9b14-16
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:50 +0200
Received: from [209.85.210.200] (helo=mail-pf1-f200.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3kBp1agYKCfMnZVieXbjjbgZ.XjhsZi-YZqZggdnon.sZikmjeZXo.jmb@flex--seanjc.bounces.google.com>)
 id 6a751a91-f2d2-0a2a450a0019-d155d2c8c457-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:50 +0200
Received: by mail-pf1-f200.google.com with SMTP id
 d2e1a72fcca58-84865f326efso3250044b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059408; x=1786664208; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=kOFXKheX158XT5RdBZeZqj6PvfchU0LO18FYNMDj3A4=;
        b=gZd/+F2G6OlP23WLTRA/RMd/lhy3+ox1hcLkW1lN8p3NWHRGsyEGnNR7cJ2tNbcGAW
         smdZvOvZbOxcj7Dl78ycJqVVFfuNN0pHVSuTBwzPY60W6Q0tVmv3cybbHdNlILWHu9f4
         xQrRrPO0jkMS1lni94cmMF3g5N5YNUZtWnlqElhYF3QDnEFXI0ypEZNBsCbXiTss9Uej
         mkXrOkeRvGHGBorhyLzfHCabWi8KxMFcyrhN7RKOihlGcNagtcph4GbHt8rw6oZKFK0Q
         rwrmFQKk0EY0P/rn/uNEBZ9XyA8xizoybwL9M1qj36SO58cEAdRmp+aM6hnFIkU0qjqH
         G0Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059408; x=1786664208;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=kOFXKheX158XT5RdBZeZqj6PvfchU0LO18FYNMDj3A4=;
        b=jVHNP4Ii/DJCdBU95UK0GsredK2+WXi2uIP9MjpESoXwms36MNAo4Lv0RHOp7ecIAe
         rMofFMMeUKJwvfnrsPiX2vuNkMdmR1M64Q1Y+NNnBy7rEYVqw44+QXZ3q4zouswzzr0j
         AB1EdcgHtSwBYM+HiOVTu5ZWCcPJHVd3QvJBPg1o8XpU8LxUpFEK8uY2ZpizJnZ6pSDW
         gCF6Vqs4Ya5ABmfjXpSYxG6s6tYEZ12vydBIQqcZXS+qUXDHLYgyfBITeIUVWZgapP+p
         Ls0EpNtlCc6aDzDJRy3lWAHXDWNL2LPb6vR2FItclurtD1QjfJR1HYMilKdLfWqtv72W
         i0fw==
X-Forwarded-Encrypted: i=1; AHgh+RphbPeKrUD7Yiy+oLFMgXFDi1Z/xceIYBTVWBz6PAyrHSHYxStaNf+BrSeTTXgXfwgZiNKyi3B9iOs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0AUbxenQEKwk73e+skrhVfUbPhFlxiJn2TPuOcBx43Yy40tLc
	/eF73gVJ4IzXFJlEqvedysWBf3hT9CwiEzNJspyuZ3YI7qJVI5PBJipvIZ4gyU+s4nava/LqTT+
	mSEx4UQ==
X-Received: from pgay6.prod.google.com ([2002:a05:6a02:4966:b0:cbb:8616:5536])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3d4f:b0:847:9188:e492
 with SMTP id d2e1a72fcca58-84f2e04d173mr18898130b3a.22.1786059408172; Thu, 06
 Aug 2026 16:36:48 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:36 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-20-seanjc@google.com>
Subject: [PATCH v6 19/51] x86/kvmclock: Drop dead check on TSC being unstable
 during kvmclock_init()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059410-53CD3CFC-F03526C2/0/0
X-purgate-type: clean
X-purgate-size: 1729

As pointed out by Sashiko[*], kvmclock_init() runs before __setup() and
thus before notsc_setup() or tsc_setup() can mark the TSC unstable.
kvmclock_init() also runs well before tsc_init(), and even before
tsc_early_init().  Simply delete the check, as it's been dead code since
it was introduced.

Note, odds are good the check_tsc_unstable() call was copied from Xen's
xen_time_init()+xen_tsc_safe_clocksource() logic (as so much of KVM's PV
code was).  However, xen_time_init() runs via x86_init.timers.timer_init(),
which is invoke from x86_late_time_init(), and thus after params have been
parsed.

Alternatively, kvmclock could register itself later on, or tsc_setup()
could be parsed as an early param.  Given that there's zero evidence there
was any meaningful intent or need to actually check for an unstable TSC,
go with the simplest option.

Fixes: 7539b174aef4 ("x86: kvmguest: use TSC clocksource if invariant TSC is exposed")
Link: https://lore.kernel.org/all/20260529181213.0B27A1F00893@smtp.kernel.org [*]
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 061a22d31dea..29ca37e9a3bc 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -362,8 +362,7 @@ void __init kvmclock_init(void)
 	 *
 	 */
 	if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
-	    boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
-	    !check_tsc_unstable())
+	    boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
 		kvm_clock.rating = 299;
 
 	clocksource_register_hz(&kvm_clock, NSEC_PER_SEC);
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385550.1628052 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7im-0003W6-Tc; Thu, 06 Aug 2026 23:41:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385550.1628052; Thu, 06 Aug 2026 23:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7im-0003Vt-Pp; Thu, 06 Aug 2026 23:41:56 +0000
Received: by outflank-mailman (input) for mailman id 1385550;
 Thu, 06 Aug 2026 23:41:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3kxp1agYKCfYqcYlhaemmejc.amkvcl-bctcjjgqrq.vclnpmhcar.mpe@flex--seanjc.bounces.google.com>)
 id 1ws7il-0003Oy-1v
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ik-00H1om-Eo
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:54 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3kxp1agYKCfYqcYlhaemmejc.amkvcl-bctcjjgqrq.vclnpmhcar.mpe@flex--seanjc.bounces.google.com>)
 id 6a751b81-5cb7-0a2a0a5109dd-0a2a450b92be-26
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:54 +0200
Received: from [209.85.214.199] (helo=mail-pl1-f199.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3kxp1agYKCfYqcYlhaemmejc.amkvcl-bctcjjgqrq.vclnpmhcar.mpe@flex--seanjc.bounces.google.com>)
 id 6a751a94-b7e8-0a2a450b0019-d155d6c7d513-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:53 +0200
Received: by mail-pl1-f199.google.com with SMTP id
 d9443c01a7336-2cca5e0a0c9so47575325ad.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059412; x=1786664212; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=9lHEbI53WDwynue0wsp+pOzdIE1KL/OlJm0qjHY+exI=;
        b=SFr28XEaSt6UgjRIJoKY55daRUKXCrTvedZjMBPb5ELN8tdLyF99ykPorQrN4PunXf
         lWb2SctUmfzZtPhw9pc74mHAMbS+onyvOdtY2igX8QeGYCfJ2BBGGQzzRf794R2DFC1Q
         XuKDyH0s2G3U+VTY4iLvydW6/QwOJCMLx2SMjB/DBceU1Irc3hJSwhsJil5iGRiLA8v0
         oegUVkoJpLQi6PSwOsPcR14PANswABwTYkTEErJ+fh+nVu9v0AXpx3Qi/+XVl4u6q3td
         IAarnfYbq7wSaV15TTAv8u+tAtmmkRk1Pw79v/mH1T8Jm5BncZ2TeJ5FmgzKsF3mzWPL
         eufQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059412; x=1786664212;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=9lHEbI53WDwynue0wsp+pOzdIE1KL/OlJm0qjHY+exI=;
        b=r5saDU2HOuzbTPEpvpc3D4FlpoLURxL6U3GuReQ5V+R/as/05fe2IwBB5Zi/oO/JGK
         aGq2osKChExJ85V0NKCON74DRJtZQE4AqZGVNmnW3PoU4kdN5hEc4Z/5AqmYk5slFaa4
         i2UERrr9VmXXIvmtu5oZeDgKvyPUEVMClKLxmTKAU8rzSBARW+brK0rWqsOihECH+wNR
         hzCJmlMim0uYrVvc4xWQ/PGa+dAewbLh2XdAg06SnjlQem+6rZ1i4eQfJf1RbLE0lvzd
         pz4eBPfZYCZoKrAOOnCn/p9EQBSowxJx0bIlqtT4U/NpLYnEjCTl3yHIjJhjuCR6c9tP
         Lorg==
X-Forwarded-Encrypted: i=1; AHgh+RrKKNzvrFmim61+43g7QgSrA2wU1ZNC4TDLodZd13Usb2XTgh67o24Fx7++b0ABqW7VJSM26/38NnM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGVtV1I7NJhCACMPe9xa5WkBPLG7Np+54UB0wafDgpQ1aNnTvc
	aD3OD6AEGpZ2+1uMOGFwA2T97HoTBcVqNgZ8vHnYs3vm4T6J2fSWPu2179/PHqFKrk+wSmtTIg8
	5PFL64Q==
X-Received: from plpn24.prod.google.com ([2002:a17:902:9698:b0:2cc:ae2b:c324])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:3d0d:b0:2d0:4021:bb6b
 with SMTP id d9443c01a7336-2d0ca15c87amr222771235ad.0.1786059411603; Thu, 06
 Aug 2026 16:36:51 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:39 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-23-seanjc@google.com>
Subject: [PATCH v6 22/51] x86/kvm: Mark TSC as reliable when it's constant and nonstop
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-42698a/1786059413-194C39EA-07710684/0/0
X-purgate-type: clean
X-purgate-size: 3764

Mark the TSC as reliable if the hypervisor (KVM) has enumerated the TSC
as constant and nonstop.  Like most (all?) virtualization setups, any
secondary clocksource that's used as a watchdog is guaranteed to be less
reliable than a constant, nonstop TSC, as all clocksources the kernel uses
as a watchdog are all but guaranteed to be emulated when running as a KVM
guest.  I.e. any observed discrepancies between the TSC and watchdog will
be due to jitter in the watchdog.

This is especially true for KVM, as the watchdog clocksource is usually
emulated in host userspace, i.e. reading the clock incurs a roundtrip
cost of thousands of cycles.

Marking the TSC reliable addresses a flaw where the TSC will occasionally
be marked unstable if the host is under moderate/heavy load.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/kvm_para.h |  2 +-
 arch/x86/kernel/kvm.c           | 12 +++++++++++-
 arch/x86/kernel/kvmclock.c      | 14 +++++---------
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 4a47c16e2df8..4a49fc286b4c 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -118,7 +118,7 @@ static inline long kvm_sev_hypercall3(unsigned int nr, unsigned long p1,
 }
 
 #ifdef CONFIG_KVM_GUEST
-void kvmclock_init(void);
+void kvmclock_init(bool prefer_tsc);
 void kvmclock_disable(void);
 bool kvm_para_available(void);
 unsigned int kvm_arch_para_features(void);
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8ed02f4f5775..255a24a99f28 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -980,6 +980,7 @@ static void __init kvm_init_platform(void)
 		.mask_hi = (BIT_ULL(boot_cpu_data.x86_phys_bits) - 1) >> 32,
 	};
 	u32 timing_info_leaf;
+	bool tsc_is_reliable;
 
 	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
 	    kvm_para_has_feature(KVM_FEATURE_MIGRATION_CONTROL)) {
@@ -1042,7 +1043,16 @@ static void __init kvm_init_platform(void)
 		}
 	}
 
-	kvmclock_init();
+	/*
+	 * If the TSC counts at a constant frequency across P/T states and in
+	 * deep C-states, treat the TSC reliable, as guaranteed by KVM.
+	 */
+	tsc_is_reliable = boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
+			  boot_cpu_has(X86_FEATURE_NONSTOP_TSC);
+	if (tsc_is_reliable)
+		setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+
+	kvmclock_init(tsc_is_reliable);
 	x86_platform.apic_post_init = kvm_apic_init;
 
 	/*
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index f55d0305d1f3..2e7ab54cb9dc 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -307,7 +307,7 @@ static int kvmclock_setup_percpu(unsigned int cpu)
 	return p ? 0 : -ENOMEM;
 }
 
-void __init kvmclock_init(void)
+void __init kvmclock_init(bool prefer_tsc)
 {
 	u8 flags;
 
@@ -356,15 +356,11 @@ void __init kvmclock_init(void)
 	kvm_get_preset_lpj();
 
 	/*
-	 * X86_FEATURE_NONSTOP_TSC is TSC runs at constant rate
-	 * with P/T states and does not stop in deep C-states.
-	 *
-	 * Invariant TSC exposed by host means kvmclock is not necessary:
-	 * can use TSC as clocksource.
-	 *
+	 * If TSC is preferred over kvmlock, drop kvmclock's rating so that TSC
+	 * is chosen as the clocksource (but still register kvmclock in case
+	 * the kernel doesn't want to use TSC for whatever reason).
 	 */
-	if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
-	    boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
+	if (prefer_tsc)
 		kvm_clock.rating = 299;
 
 	clocksource_register_hz(&kvm_clock, NSEC_PER_SEC);
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:41:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:41:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385555.1628061 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7io-0003mb-6D; Thu, 06 Aug 2026 23:41:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385555.1628061; Thu, 06 Aug 2026 23:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7io-0003lx-20; Thu, 06 Aug 2026 23:41:58 +0000
Received: by outflank-mailman (input) for mailman id 1385555;
 Thu, 06 Aug 2026 23:41:56 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3lBp1agYKCfcrdZmibfnnfkd.bnlwdm-cdudkkhrsr.wdmoqnidbs.nqf@flex--seanjc.bounces.google.com>)
 id 1ws7im-0003Uh-Ay
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7il-00EMEo-OJ
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:55 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3lBp1agYKCfcrdZmibfnnfkd.bnlwdm-cdudkkhrsr.wdmoqnidbs.nqf@flex--seanjc.bounces.google.com>)
 id 6a751b45-e002-0a2a0a5209dd-0a2a450cbd60-46
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:55 +0200
Received: from [209.85.215.198] (helo=mail-pg1-f198.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3lBp1agYKCfcrdZmibfnnfkd.bnlwdm-cdudkkhrsr.wdmoqnidbs.nqf@flex--seanjc.bounces.google.com>)
 id 6a751a95-f479-0a2a450c0019-d155d7c6eddc-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:55 +0200
Received: by mail-pg1-f198.google.com with SMTP id
 41be03b00d2f7-c88cfe287e1so2212099a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059413; x=1786664213; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=gK3sjM001OyHimEt3r9e3MTxT5BkhagjBxMzBV7doNU=;
        b=fciNCWp1Dx0DOh61gLXEdpIpN6AoB9zvLad0YYA5tHxBbineEnVN1fMpe64CvhZPic
         z2br75Z1ZwItMC9hAmcvldKj5N0yQ2ymv5JC2RIYRyK6tlT1goIAOkWpNV+WdaBnGaJc
         H2Q3cL3DrIydLaM9C2lgcB7eJLRkHVj0z76IX7dC8bEixLgpVR5EeS8EsWWJTTFWfRXc
         iOikwNMO2IPhRTMkfXP+x7PwOkQdGmKzubSQI/g6aLlwBqFI2RlWLTDz6QSgB4oKMW5o
         7DcO9WLrWyktw1k8k/NZ9L8RP9/QnRowzA/WMcQwCmtgE8Shxzre20FW7SSqTs0YkZwf
         xIBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059413; x=1786664213;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=gK3sjM001OyHimEt3r9e3MTxT5BkhagjBxMzBV7doNU=;
        b=aHodXI43os7+Mhn0RISDOuwukRJ+oHk6hgCjSi3ys7JXa/cLSwy0qK37oHupvQ/ZzB
         6LxlcX2k9BtBACkw8rXsc+6kj6dvo2hDr4I7ySrcwyws/9xadxCd+5YGPT02BJ4pzcFU
         NJH9/w7f2X0kcjMrtDtBlltzYlS4jpWBgUeX8AYUkT8zu023fail7jdVthVSHWuB45Q7
         Fod2zO/Md1SP/NgfuWcE2hZuBjx5vgKKtZCSGQwkAh662eW+VYOtsitQUixyRRUozzKp
         YrULZf1+44vC+jmWZLybAkO4dyQuF+cHnoxo/738BSGbWab33XkN2m8sXn+yNzcG8ppI
         WGvg==
X-Forwarded-Encrypted: i=1; AHgh+RrWcFYKG+bTo8Owytd6b46jCy6Xxg0V/vj0TtJ2072NviIFIcIMouOvzj+kOZuBMunA/0hRwvJX/CQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yya0zsFzKNL6T95JS6U3gGKfplK/uEenHlSj3Seb4YDP8ZC7hOU
	l3q6lcQQ12FeodFaJ2qkKr6E8kFtilq4wJIz0gC6XH/4Jruuy5y9vA4waEJ7BdoQXko78EpDqQa
	dLzqwwA==
X-Received: from pglu1.prod.google.com ([2002:a63:1401:0:b0:c99:aff5:7078])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:6da8:b0:3c3:bee9:8eec
 with SMTP id adf61e73a8af0-3cbadc10910mr5429156637.19.1786059412806; Thu, 06
 Aug 2026 16:36:52 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:40 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-24-seanjc@google.com>
Subject: [PATCH v6 23/51] x86/tsc: Add standalone helper for getting CPU
 frequency from CPUID
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d25034/1786059415-01EC2A5B-4D077EA2/0/0
X-purgate-type: clean
X-purgate-size: 2814

Extract the guts of cpu_khz_from_cpuid() to a standalone helper that
doesn't restrict the usage to Intel CPUs.  This will allow sharing the
core logic with KVM-as-a-guest, as KVM generally doesn't restrict CPUID
based on vendor.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/tsc.h |  1 +
 arch/x86/kernel/tsc.c      | 31 +++++++++++++++----------------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index c09ec485abcd..cb682f097ea7 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -88,6 +88,7 @@ struct cpuid_tsc_info {
 	unsigned int crystal_khz;
 };
 extern int cpuid_get_tsc_info(struct cpuid_tsc_info *info);
+extern unsigned int __cpu_khz_from_cpuid(void);
 
 extern void tsc_early_init(void);
 extern void tsc_init(void);
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index d95e4f059f17..4c5328d19ebe 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -668,6 +668,18 @@ int cpuid_get_tsc_info(struct cpuid_tsc_info *info)
 	return 0;
 }
 
+unsigned int __cpu_khz_from_cpuid(void)
+{
+	unsigned int eax_base_mhz, ebx, ecx, edx;
+
+	if (boot_cpu_data.cpuid_level < CPUID_LEAF_FREQ)
+		return 0;
+
+	cpuid(CPUID_LEAF_FREQ, &eax_base_mhz, &ebx, &ecx, &edx);
+
+	return eax_base_mhz * 1000;
+}
+
 /**
  * native_calibrate_tsc - determine TSC frequency
  * Determine TSC frequency via CPUID, else return 0.
@@ -703,12 +715,8 @@ static unsigned long native_calibrate_tsc(void)
 	 * clock, but we can easily calculate it to a high degree of accuracy
 	 * by considering the crystal ratio and the CPU speed.
 	 */
-	if (!info.crystal_khz && boot_cpu_data.cpuid_level >= CPUID_LEAF_FREQ) {
-		unsigned int eax_base_mhz, ebx, ecx, edx;
-
-		cpuid(CPUID_LEAF_FREQ, &eax_base_mhz, &ebx, &ecx, &edx);
-		info.crystal_khz = eax_base_mhz * 1000 * info.denominator / info.numerator;
-	}
+	if (!info.crystal_khz)
+		info.crystal_khz = __cpu_khz_from_cpuid() * info.denominator / info.numerator;
 
 	if (!info.crystal_khz)
 		return 0;
@@ -733,19 +741,10 @@ static unsigned long native_calibrate_tsc(void)
 
 static unsigned long cpu_khz_from_cpuid(void)
 {
-	unsigned int eax_base_mhz, ebx_max_mhz, ecx_bus_mhz, edx;
-
 	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
 		return 0;
 
-	if (boot_cpu_data.cpuid_level < CPUID_LEAF_FREQ)
-		return 0;
-
-	eax_base_mhz = ebx_max_mhz = ecx_bus_mhz = edx = 0;
-
-	cpuid(CPUID_LEAF_FREQ, &eax_base_mhz, &ebx_max_mhz, &ecx_bus_mhz, &edx);
-
-	return eax_base_mhz * 1000;
+	return __cpu_khz_from_cpuid();
 }
 
 /*
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385558.1628070 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iq-00044g-Cc; Thu, 06 Aug 2026 23:42:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385558.1628070; Thu, 06 Aug 2026 23:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iq-00044Q-9B; Thu, 06 Aug 2026 23:42:00 +0000
Received: by outflank-mailman (input) for mailman id 1385558;
 Thu, 06 Aug 2026 23:41:58 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3lxp1agYKCfougcpleiqqing.eqozgp-fgxgnnkuvu.zgprtqlgev.qti@flex--seanjc.bounces.google.com>)
 id 1ws7io-0003nQ-Do
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:41:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7in-00EMFx-Qw
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:41:57 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3lxp1agYKCfougcpleiqqing.eqozgp-fgxgnnkuvu.zgprtqlgev.qti@flex--seanjc.bounces.google.com>)
 id 6a751ba5-2eae-0a2a0a5409dd-0a2a450a9b14-18
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:41:57 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3lxp1agYKCfougcpleiqqing.eqozgp-fgxgnnkuvu.zgprtqlgev.qti@flex--seanjc.bounces.google.com>)
 id 6a751a98-f2d2-0a2a450a0019-d155d2c6ed27-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:57 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-8484f26852dso3084354b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059415; x=1786664215; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=LVVzZOjwmw/JiJ4qXIbPAPAp0QWxfKUo2q2D7ecTrQM=;
        b=hTF2lT9DqHChkWBoxQa6p7zWaLa7LIZl/5shX6RsHLEQ/zw7GV8qWvbKld/xvU1jrq
         FAt5i2xJ0s3sJweKxBycUrYGuGcaztCusxD37uJGPLTFNQj7TAK9EbEm4fvwRgd2jHJq
         TCFcHPGYZwz5xJiSAYk3WK0gCBbOQUlwFYiVPfaq26lAs2c79Vsn4LHaiNhLFDaSx4Q8
         E8FHJn+rzf4csVPliwWOfMERPgaXBj+n5guogY2OcxYB7xryoa9mVy4ATcSVLIslVOp2
         WqBBSKIWnNvanSHhEGNRmKRiuodKyc79Dh8v4mnwLTfmpG/fawW3a0wpF1/OlIAek3O+
         br2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059415; x=1786664215;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=LVVzZOjwmw/JiJ4qXIbPAPAp0QWxfKUo2q2D7ecTrQM=;
        b=V9HhinPOprV4JIMVYhbHor0vSZ6UNuw72zQGdlhXSwfTZReMYSpq+iaQlYIzhKHXRE
         GOhmcb4Dmt2d1iaiJuhXPU7iTMbPaATsPgnXzk7L8mzCRt/QyYGIUYziTv3e1icnf+hA
         meUhyvoOZgl/R47ruouLZO7T4YPwPkrWwdINboVT1jLSYNyEE/okSiRuS0zkZxeDlv7o
         eJSB0uKvUuChJ+5dtG2VMqpRkTRo/pkz1bwf2GSzkPj3+DF/lqkGZPzuH2MHUaz5d7w/
         iOzTbgA5uYWLrEBRfDw7+HjDz38fuhrdqZgs/N0HFoy8d6GRj7m4g1KtdbzVIazvZRjb
         gJIQ==
X-Forwarded-Encrypted: i=1; AHgh+RrJDcOXr6lrwKNHWzUnKQr8RBnLctSglnJp7MmyDUXOo9Bw7Qi872Wk6Eiy0tH2W3F0ZgYER2Jv2Rs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw323y/D4ruGMCDaEUjg3O8Pq7IKkpb2RUtSPeqqC3dB7YpVRdX
	gOXmz3IWIlMiLfu0ncDns+T4i5HetZDmL7PAlu4NbGPfP5senAJAfYDRHt6gDNBjtf23SQuiBnm
	LOKhvig==
X-Received: from pfcy22.prod.google.com ([2002:a05:6a00:93d6:b0:84b:be30:8d22])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:8019:b0:848:4a48:9f9f
 with SMTP id d2e1a72fcca58-84f4fee000fmr6402250b3a.34.1786059415266; Thu, 06
 Aug 2026 16:36:55 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:42 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-26-seanjc@google.com>
Subject: [PATCH v6 25/51] clocksource: hyper-v: Register sched_clock
 save/restore iff it's necessary
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059417-4ACDBCFC-72ED3FAD/0/0
X-purgate-type: clean
X-purgate-size: 6603

Register the Hyper-V reference counter (refcounter) callbacks for saving
and restoring its PV sched_clock, if and only if the refcounter is
actually being used for sched_clock.  Currently, Hyper-V overrides the
save/restore hooks if the reference TSC available, whereas the Hyper-V
refcounter code only overrides sched_clock if the reference TSC is
available *and* it's not invariant.  The flaw is effectively papered over
by invoking the "old" save/restore callbacks as part of save/restore, but
that's unnecessary and fragile.

To avoid introducing more complexity, and to allow for additional cleanups
of the PV sched_clock code, move the save/restore hooks and logic into
hyperv_timer.c and simply wire up the hooks when overriding sched_clock
itself.

Note, while the Hyper-V refcounter code is intended to be architecture
neutral, CONFIG_PARAVIRT is firmly x86-only, i.e. adding a small amount of
x86 specific code (which will be reduced in future cleanups) doesn't
meaningfully pollute generic code.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/cpu/mshyperv.c     | 58 ------------------------------
 drivers/clocksource/hyperv_timer.c | 50 ++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 58 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 3bca987e05c3..d704496d0409 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -275,63 +275,6 @@ static void hv_guest_crash_shutdown(struct pt_regs *regs)
 }
 #endif /* CONFIG_CRASH_DUMP */
 
-static u64 hv_ref_counter_at_suspend;
-static void (*old_save_sched_clock_state)(void);
-static void (*old_restore_sched_clock_state)(void);
-
-/*
- * Hyper-V clock counter resets during hibernation. Save and restore clock
- * offset during suspend/resume, while also considering the time passed
- * before suspend. This is to make sure that sched_clock using hv tsc page
- * based clocksource, proceeds from where it left off during suspend and
- * it shows correct time for the timestamps of kernel messages after resume.
- */
-static void save_hv_clock_tsc_state(void)
-{
-	hv_ref_counter_at_suspend = hv_read_reference_counter();
-}
-
-static void restore_hv_clock_tsc_state(void)
-{
-	/*
-	 * Adjust the offsets used by hv tsc clocksource to
-	 * account for the time spent before hibernation.
-	 * adjusted value = reference counter (time) at suspend
-	 *                - reference counter (time) now.
-	 */
-	hv_adj_sched_clock_offset(hv_ref_counter_at_suspend - hv_read_reference_counter());
-}
-
-/*
- * Functions to override save_sched_clock_state and restore_sched_clock_state
- * functions of x86_platform. The Hyper-V clock counter is reset during
- * suspend-resume and the offset used to measure time needs to be
- * corrected, post resume.
- */
-static void hv_save_sched_clock_state(void)
-{
-	old_save_sched_clock_state();
-	save_hv_clock_tsc_state();
-}
-
-static void hv_restore_sched_clock_state(void)
-{
-	restore_hv_clock_tsc_state();
-	old_restore_sched_clock_state();
-}
-
-static void __init x86_setup_ops_for_tsc_pg_clock(void)
-{
-	if (!(ms_hyperv.features & HV_MSR_REFERENCE_TSC_AVAILABLE))
-		return;
-
-	old_save_sched_clock_state = x86_platform.save_sched_clock_state;
-	x86_platform.save_sched_clock_state = hv_save_sched_clock_state;
-
-	old_restore_sched_clock_state = x86_platform.restore_sched_clock_state;
-	x86_platform.restore_sched_clock_state = hv_restore_sched_clock_state;
-}
-
 #ifdef CONFIG_X86_64
 DEFINE_STATIC_CALL(hv_hypercall, hv_std_hypercall);
 EXPORT_STATIC_CALL_TRAMP_GPL(hv_hypercall);
@@ -736,7 +679,6 @@ static void __init ms_hyperv_init_platform(void)
 
 	/* Register Hyper-V specific clocksource */
 	hv_init_clocksource();
-	x86_setup_ops_for_tsc_pg_clock();
 	hv_vtl_init_platform();
 #endif
 	/*
diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index df567795d175..4293173c3a27 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -554,10 +554,60 @@ static __always_inline void hv_setup_sched_clock(void *sched_clock)
 #elif defined CONFIG_PARAVIRT
 #include <asm/timer.h>
 
+static u64 hv_ref_counter_at_suspend;
+static void (*old_save_sched_clock_state)(void);
+static void (*old_restore_sched_clock_state)(void);
+
+/*
+ * Hyper-V clock counter resets during hibernation. Save and restore clock
+ * offset during suspend/resume, while also considering the time passed
+ * before suspend. This is to make sure that sched_clock using hv tsc page
+ * based clocksource, proceeds from where it left off during suspend and
+ * it shows correct time for the timestamps of kernel messages after resume.
+ */
+static void save_hv_clock_tsc_state(void)
+{
+	hv_ref_counter_at_suspend = hv_read_reference_counter();
+}
+
+static void restore_hv_clock_tsc_state(void)
+{
+	/*
+	 * Adjust the offsets used by hv tsc clocksource to
+	 * account for the time spent before hibernation.
+	 * adjusted value = reference counter (time) at suspend
+	 *                - reference counter (time) now.
+	 */
+	hv_adj_sched_clock_offset(hv_ref_counter_at_suspend - hv_read_reference_counter());
+}
+/*
+ * Functions to override save_sched_clock_state and restore_sched_clock_state
+ * functions of x86_platform. The Hyper-V clock counter is reset during
+ * suspend-resume and the offset used to measure time needs to be
+ * corrected, post resume.
+ */
+static void hv_save_sched_clock_state(void)
+{
+	old_save_sched_clock_state();
+	save_hv_clock_tsc_state();
+}
+
+static void hv_restore_sched_clock_state(void)
+{
+	restore_hv_clock_tsc_state();
+	old_restore_sched_clock_state();
+}
+
 static __always_inline void hv_setup_sched_clock(void *sched_clock)
 {
 	/* We're on x86/x64 *and* using PV ops */
 	paravirt_set_sched_clock(sched_clock);
+
+	old_save_sched_clock_state = x86_platform.save_sched_clock_state;
+	x86_platform.save_sched_clock_state = hv_save_sched_clock_state;
+
+	old_restore_sched_clock_state = x86_platform.restore_sched_clock_state;
+	x86_platform.restore_sched_clock_state = hv_restore_sched_clock_state;
 }
 #else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
 static __always_inline void hv_setup_sched_clock(void *sched_clock) {}
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385561.1628079 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ir-0004Kt-Rc; Thu, 06 Aug 2026 23:42:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385561.1628079; Thu, 06 Aug 2026 23:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7ir-0004KJ-MX; Thu, 06 Aug 2026 23:42:01 +0000
Received: by outflank-mailman (input) for mailman id 1385561;
 Thu, 06 Aug 2026 23:42:00 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3mRp1agYKCfwwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 1ws7iq-00047c-QD
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iq-00EMFx-6l
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:00 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3mRp1agYKCfwwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 6a751ba5-2eae-0a2a0a5409dd-0a2a450a9b14-20
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:00 +0200
Received: from [209.85.215.198] (helo=mail-pg1-f198.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3mRp1agYKCfwwierngksskpi.gsq1ir-hizippmwxw.1irtvsnigx.svk@flex--seanjc.bounces.google.com>)
 id 6a751a9a-f2d2-0a2a450a0019-d155d7c6c01f-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:36:59 +0200
Received: by mail-pg1-f198.google.com with SMTP id
 41be03b00d2f7-cb5ea36f969so2798106a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:36:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059418; x=1786664218; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=heSuqSIgeH92pLRWbhNi7GYX8HqrNShkMIs22IEn4aI=;
        b=BIIBZnGlGffTWkDS2scCLpiOfDiJwvzTr6PGVhYlq5AWmczdDm77AuAqCHdUnGwYy4
         5OyTPcurT16+KqdtBumy4hMZl5SyOOz2Mw8Nc3InEtinjV7pXtBL4+jKFsqmrY8/FOY3
         qfpTtHc4jDWhZ5ACkz03AFX842sVVG0PtfgVVIRF9kwnnwfrgtpZuBSyLuR9BMrQvDMF
         YOG8B3YhzYawkabeweEikBblZRovSFbBBDTdU39Z30qHe2JNCte2+RWThgpBZXcVCtTg
         4QpAPX7NksJsSX7SrDmyMkCSLS8VZKtx/gX16eABXyC+cauiq7mVZmuT92OWSN2r4bX6
         1M7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059418; x=1786664218;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=heSuqSIgeH92pLRWbhNi7GYX8HqrNShkMIs22IEn4aI=;
        b=iAWT92RYLqG13YCmWmpW9XhFdiP4+c+9Cn7u1bL6xjcIsrDF/2HHrSYqMH6vkR6P0U
         wYJzNOQlfBuLcS3kRjnRbcom3O5Mw3px7J6f3TVcDymh4bcTp+WNaCDEutfNuKY2oInX
         /z1IzssBuy+x5Et5UtD1aIyqLvFzcl2nNhTizJArKSQBZSk8aM75U4/fBr8oCY0ke8/W
         wo3rIsSdV2M8+/d6FrSsHJlAowvi9GmbKt5nNDsLLKaMktbU8jJUNXxI6+bxUBEw8WG3
         BFU6Zw5Y218/WHM/RG4C/EAevYDwB7p5oBWw62tE+2CUgGZR6Y1jRK58T821/ja/ZBZc
         s4+g==
X-Forwarded-Encrypted: i=1; AHgh+RqFGQC/U1F3YCDAg55dZZxzVIhwM//TJfBnQcKfSVifl3VwUbrPPMunizee48H/7Pw8sC4oWv0tqng=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2Tt27bUjjFV2olajzLngT9jWedYJ8l2zjis5HW0WkQWR9em0Z
	RIQCevI+FwIEaVON8aRop6W6pRnAGkg/cfwk4yZQx8HRqhicMn+yB/bDrEDHaLG2nVIG4+FQ/zi
	gCL8aHw==
X-Received: from pgmc19.prod.google.com ([2002:a63:1c53:0:b0:c98:2639:852e])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7344:b0:3bf:6acf:2940
 with SMTP id adf61e73a8af0-3cb85df0a1bmr20575846637.11.1786059417589; Thu, 06
 Aug 2026 16:36:57 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:44 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-28-seanjc@google.com>
Subject: [PATCH v6 27/51] clocksource: hyper-v: Don't save/restore TSC offset
 when using HV sched_clock
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059419-591C5CFC-42B8086B/0/0
X-purgate-type: clean
X-purgate-size: 2763

Now that Hyper-V overrides the sched_clock save/restore hooks if and only
sched_clock itself is set to the Hyper-V reference counter, drop the
invocation of the "old" save/restore callbacks.  When the registration of
the PV sched_clock was done separately from overriding the save/restore
hooks, it was possible for Hyper-V to clobber the TSC save/restore
callbacks without actually switching to the Hyper-V refcounter.

Enabling a PV sched_clock is a one-way street, i.e. the kernel will never
revert to using TSC for sched_clock, and so there is no need to invoke the
TSC save/restore hooks (and if there was, it belongs in common PV code).

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Acked-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 drivers/clocksource/hyperv_timer.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index daa8cbfe61ee..220668207d19 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -544,9 +544,6 @@ static __always_inline void hv_setup_sched_clock(void *sched_clock)
 #include <asm/timer.h>
 
 static u64 hv_ref_counter_at_suspend;
-static void (*old_save_sched_clock_state)(void);
-static void (*old_restore_sched_clock_state)(void);
-
 /*
  * Hyper-V clock counter resets during hibernation. Save and restore clock
  * offset during suspend/resume, while also considering the time passed
@@ -556,8 +553,6 @@ static void (*old_restore_sched_clock_state)(void);
  */
 static void hv_save_sched_clock_state(void)
 {
-	old_save_sched_clock_state();
-
 	hv_ref_counter_at_suspend = hv_read_reference_counter();
 }
 
@@ -570,8 +565,6 @@ static void hv_restore_sched_clock_state(void)
 	 *                - reference counter (time) now.
 	 */
 	hv_sched_clock_offset -= (hv_ref_counter_at_suspend - hv_read_reference_counter());
-
-	old_restore_sched_clock_state();
 }
 
 static __always_inline void hv_setup_sched_clock(void *sched_clock)
@@ -579,10 +572,7 @@ static __always_inline void hv_setup_sched_clock(void *sched_clock)
 	/* We're on x86/x64 *and* using PV ops */
 	paravirt_set_sched_clock(sched_clock);
 
-	old_save_sched_clock_state = x86_platform.save_sched_clock_state;
 	x86_platform.save_sched_clock_state = hv_save_sched_clock_state;
-
-	old_restore_sched_clock_state = x86_platform.restore_sched_clock_state;
 	x86_platform.restore_sched_clock_state = hv_restore_sched_clock_state;
 }
 #else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385563.1628087 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7it-0004em-Ak; Thu, 06 Aug 2026 23:42:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385563.1628087; Thu, 06 Aug 2026 23:42:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7it-0004dr-4R; Thu, 06 Aug 2026 23:42:03 +0000
Received: by outflank-mailman (input) for mailman id 1385563;
 Thu, 06 Aug 2026 23:42:02 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3mhp1agYKCf0xjfsohlttlqj.htr2js-ij0jqqnxyx.2jsuwtojhy.twl@flex--seanjc.bounces.google.com>)
 id 1ws7is-0004OP-6c
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7ir-00EMEo-JB
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:01 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3mhp1agYKCf0xjfsohlttlqj.htr2js-ij0jqqnxyx.2jsuwtojhy.twl@flex--seanjc.bounces.google.com>)
 id 6a751b7b-e002-0a2a0a5209dd-0a2a4507ba7e-30
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:01 +0200
Received: from [209.85.215.199] (helo=mail-pg1-f199.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3mhp1agYKCf0xjfsohlttlqj.htr2js-ij0jqqnxyx.2jsuwtojhy.twl@flex--seanjc.bounces.google.com>)
 id 6a751a9b-b4ea-0a2a45070019-d155d7c7e533-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:00 +0200
Received: by mail-pg1-f199.google.com with SMTP id
 41be03b00d2f7-cb4cdf95b5aso4647022a12.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059419; x=1786664219; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=IDybt2K9QzXIIF0RtAPpPcNbJv3nyQQRnp+0cGRBepM=;
        b=U8zn6oj+pXJ4i7lMeXnmYvIAyYJ8t5d1ncj+BkYYksenQJB87we/ljatLfLlEpLjpW
         1kkcaJ/b+1Kv6/uPDGPjz1m4eaoMR4+PeeLejCauvmQ2yjKRRJIISybf5zd3KtNt441a
         +tpIpzPOrdKvPr5pxx2ZvlY7KFgl0X30ELsDeUZkS1ivDszQ8rbpOfDCELg+OoCHLDFs
         Wb5H6aeRz9FG+BCHEoCpNSaqD78+d+3syeg/LHEoDOU5kYRtR7Kg/zPwHYQDvqAtYmCS
         gOx2kFCp8o22y8ZBVLp+4ETojLRfQL5YcGTAP5M1/6BA8rW5h7HyusMtYUv5F2/aoR7q
         Shxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059419; x=1786664219;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=IDybt2K9QzXIIF0RtAPpPcNbJv3nyQQRnp+0cGRBepM=;
        b=fdAcdOcx6nlYcKjQgKUDaw/3HnDSxjNRCRcPo1v8N+pKxxw0kubViUnwcj1O72jFVe
         kL/un9HkVF+mPZ8GRYov1vU8W+2Z0NgX6b90sbkbxaT8eRCrBWk5e6YpRbq4WPmjbS44
         TEcvvSEysCuHUnbqFhI6kG8WkC9ijdmbnUOeqLt2OeoIGy6dSfWAd/knqcDTBFbLncpp
         ReBLwMcE5MUDtM4VUnBpt6kUJTWKMutW8l9Ex6PmMbRl8gZOHrI5lRiVTtumfCCdAjgK
         H6vo9vAvV0E+yNEG4Z+uvZQX79iAoAQ8WFwOvDl2T8thz1KT2r9DGQncDpBjKC2stGm8
         Q/Gw==
X-Forwarded-Encrypted: i=1; AHgh+Rq+1eEzdwbjlIRtiZ3mEJK67j/JstHIbotRWnNzLAVVqkaono5FO85WxFMOANcAnHpqbtvQJkngzG8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqBMytgyFZqs1AINCBwPOj4ynFkmebec6V/loqSnuIcQtqSowT
	E5pUu3K1dd/MzKNeJ1iOQAEfoupFEAKwGGQfwawCrGCWtiwD6oxwdpuyGFZpNzlD6oRGHZMIBwd
	lcvVxOQ==
X-Received: from pgbcp2.prod.google.com ([2002:a05:6a02:4002:b0:c8b:fa4f:f001])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:4314:b0:3c3:89ce:b5bc
 with SMTP id adf61e73a8af0-3cb85e28fd0mr22042606637.15.1786059418706; Thu, 06
 Aug 2026 16:36:58 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:45 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-29-seanjc@google.com>
Subject: [PATCH v6 28/51] x86/kvmclock: Setup kvmclock for secondary CPUs iff CONFIG_SMP=y
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059421-356C2AE4-6803097E/0/0
X-purgate-type: clean
X-purgate-size: 1438

Gate kvmclock's secondary CPU code on CONFIG_SMP, not CONFIG_X86_LOCAL_APIC.
Originally, kvmclock piggybacked PV APIC ops to setup secondary CPUs.
When that wart was fixed by commit df156f90a0f9 ("x86: Introduce
x86_cpuinit.early_percpu_clock_init hook"), the dependency on a local APIC
got carried forward unnecessarily.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 2e7ab54cb9dc..b0c871ba8232 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -208,7 +208,7 @@ static void kvm_restore_sched_clock_state(void)
 	kvm_register_clock("primary cpu clock, resume");
 }
 
-#ifdef CONFIG_X86_LOCAL_APIC
+#ifdef CONFIG_SMP
 static void kvm_setup_secondary_clock(void)
 {
 	kvm_register_clock("secondary cpu clock");
@@ -348,7 +348,7 @@ void __init kvmclock_init(bool prefer_tsc)
 		x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
 	x86_platform.get_wallclock = kvm_get_wallclock;
 	x86_platform.set_wallclock = kvm_set_wallclock;
-#ifdef CONFIG_X86_LOCAL_APIC
+#ifdef CONFIG_SMP
 	x86_cpuinit.early_percpu_clock_init = kvm_setup_secondary_clock;
 #endif
 	x86_platform.save_sched_clock_state = kvm_save_sched_clock_state;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385567.1628097 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iv-00054V-M5; Thu, 06 Aug 2026 23:42:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385567.1628097; Thu, 06 Aug 2026 23:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iv-00054I-I5; Thu, 06 Aug 2026 23:42:05 +0000
Received: by outflank-mailman (input) for mailman id 1385567;
 Thu, 06 Aug 2026 23:42:04 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3nBp1agYKCQEtfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>)
 id 1ws7it-0004kF-Se
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7it-008OLI-9U
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:03 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3nBp1agYKCQEtfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>)
 id 6a751b7a-bab6-0a2a0a5309dd-0a2a4504bd98-40
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:03 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3nBp1agYKCQEtfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>)
 id 6a751a9d-b57f-0a2a45040019-d155d2c5d912-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:02 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84a67b16217so4508395b3a.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059421; x=1786664221; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=o8F+mGATSkCnO7RB7Nrhalcr3db+GPA7pyXAMrOPMa0=;
        b=TU8gvqp2Xs2TI9bhAeX4P+HrTuHBER0l6RwBZhwwm+Vdi8PQK6WfW8l1h/Q9w8HNPl
         NaTt4COG/0MZ5MlPnKoaHVAWhAcvVJNTv1RkTPI+TJdkDCnxzZ0XTL8yoOnCzUsyHGIE
         OW0DclQsdPi7f/O8GrTdYUVlQ/xCC5rJOb97VXN0QW6N8h/qiz91ApB3Pftn+CiU3x2Y
         iwxb8biObr5TVwUfaz4AOcFKmuQOIX33rGIrxxn8WtV6H+G2N4Kt2AHocb0nc6G4WXOU
         xgm/iYwZtUYTSjBJlngZfMDXw6JbAUkErlUJKt2ntLIbsABQGjQgkXmEs5+Q/pnbK3eO
         hW/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059421; x=1786664221;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=o8F+mGATSkCnO7RB7Nrhalcr3db+GPA7pyXAMrOPMa0=;
        b=Dn9HTRyT+QTl9OyM9PIUAKtpim93EP5BXvLKw0XTP6pS7m4iOjj69anpfyWlMFCuYA
         FtqW4C34iIHngbBSVyxBLYnzw5Sus4x3hvNb2xUdN9MGqCpvH7mdQbQqlPgtcGShoEUR
         8AtFJkBHpV5LTK6uW7sU5VpjgBbdOpKAhvVSwaNPArgu8E8cBz3AI6Ip/QXA4M9QV7Cp
         4yPIpCA75JJxlzo1N8HHZT4LMbWlTeMCaAWVjC6PMlTJw39goes1060FALvoWwo3eY+A
         i9J8T1ar62MIJbULgFUb5RKJPDtAyG5FhFRxwp0XL4TJn3qFQIObn6WN9X6uQZ/+ibX7
         iwbQ==
X-Forwarded-Encrypted: i=1; AHgh+Ro5cI0txA7pmFjtxGTa4TnVJs25ZU0OjeUCqjY+hUcv5CpHQmnB4LndKcG85GE3+gfONsr6YlYGKP0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyL+4p8l6Eszz/G5brakP0VTolzhUzpnqKg0MDSs2Z7PBF16Gdl
	MMaIqrKjNrCm2ikSuT7mspEevNGYvmHBlqtvIxsGZJhPhLpGzmj9qC1Bfr4o8Kf1PX6PHEaC9cO
	gup0aLw==
X-Received: from pfwp49.prod.google.com ([2002:a05:6a00:26f1:b0:84a:894f:23f2])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1daa:b0:848:401c:98e
 with SMTP id d2e1a72fcca58-84f2e0432a7mr20883725b3a.15.1786059420393; Thu, 06
 Aug 2026 16:37:00 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:46 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-30-seanjc@google.com>
Subject: [PATCH v6 29/51] x86/kvm: Don't disable kvmclock on BSP in syscore_suspend()
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ebf023/1786059422-522D4B50-BCD4A772/0/0
X-purgate-type: clean
X-purgate-size: 5413

Don't disable kvmclock on the BSP during syscore_suspend(), as the BSP's
clock is NOT restored during syscore_resume(), but is instead restored
earlier via the sched_clock restore callback.  If suspend is aborted, e.g.
due to a late wakeup, the BSP will run without its clock enabled, which
"works" only because KVM-the-hypervisor is kind enough to not clobber the
shared memory when the clock is disabled.  But over time, the BSP's view
of time will drift from APs.

Plumb in an "action" to KVM-as-a-guest and kvmclock code in preparation
for additional cleanups to kvmclock's suspend/resume logic.

Fixes: c02027b5742b ("x86/kvm: Disable kvmclock on all CPUs on shutdown")
Cc: stable@vger.kernel.org
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/include/asm/kvm_para.h |  8 +++++++-
 arch/x86/kernel/kvm.c           | 15 ++++++++-------
 arch/x86/kernel/kvmclock.c      | 31 +++++++++++++++++++++++++------
 3 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 4a49fc286b4c..08686ff19caa 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -118,8 +118,14 @@ static inline long kvm_sev_hypercall3(unsigned int nr, unsigned long p1,
 }
 
 #ifdef CONFIG_KVM_GUEST
+enum kvm_guest_cpu_action {
+	KVM_GUEST_BSP_SUSPEND,
+	KVM_GUEST_AP_OFFLINE,
+	KVM_GUEST_SHUTDOWN,
+};
+
 void kvmclock_init(bool prefer_tsc);
-void kvmclock_disable(void);
+void kvmclock_cpu_action(enum kvm_guest_cpu_action action);
 bool kvm_para_available(void);
 unsigned int kvm_arch_para_features(void);
 unsigned int kvm_arch_para_hints(void);
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 83b9351f2810..9c0b2fc98cc9 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -460,7 +460,7 @@ static void __init sev_map_percpu_data(void)
 	}
 }
 
-static void kvm_guest_cpu_offline(bool shutdown)
+static void kvm_guest_cpu_offline(enum kvm_guest_cpu_action action)
 {
 	kvm_disable_steal_time();
 	if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
@@ -468,9 +468,10 @@ static void kvm_guest_cpu_offline(bool shutdown)
 	if (kvm_para_has_feature(KVM_FEATURE_MIGRATION_CONTROL))
 		wrmsrq(MSR_KVM_MIGRATION_CONTROL, 0);
 	kvm_pv_disable_apf();
-	if (!shutdown)
+	if (action != KVM_GUEST_SHUTDOWN)
 		apf_task_wake_all();
-	kvmclock_disable();
+
+	kvmclock_cpu_action(action);
 }
 
 static int kvm_cpu_online(unsigned int cpu)
@@ -728,7 +729,7 @@ static int kvm_cpu_down_prepare(unsigned int cpu)
 	unsigned long flags;
 
 	local_irq_save(flags);
-	kvm_guest_cpu_offline(false);
+	kvm_guest_cpu_offline(KVM_GUEST_AP_OFFLINE);
 	local_irq_restore(flags);
 	return 0;
 }
@@ -739,7 +740,7 @@ static int kvm_suspend(void *data)
 {
 	u64 val = 0;
 
-	kvm_guest_cpu_offline(false);
+	kvm_guest_cpu_offline(KVM_GUEST_BSP_SUSPEND);
 
 #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
 	if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL))
@@ -770,7 +771,7 @@ static struct syscore kvm_syscore = {
 
 static void kvm_pv_guest_cpu_reboot(void *unused)
 {
-	kvm_guest_cpu_offline(true);
+	kvm_guest_cpu_offline(KVM_GUEST_SHUTDOWN);
 }
 
 static int kvm_pv_reboot_notify(struct notifier_block *nb,
@@ -794,7 +795,7 @@ static struct notifier_block kvm_pv_reboot_nb = {
 #ifdef CONFIG_CRASH_DUMP
 static void kvm_crash_shutdown(struct pt_regs *regs)
 {
-	kvm_guest_cpu_offline(true);
+	kvm_guest_cpu_offline(KVM_GUEST_SHUTDOWN);
 	native_machine_crash_shutdown(regs);
 }
 #endif
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index b0c871ba8232..a3ec298d56d7 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -199,8 +199,22 @@ static void kvm_register_clock(char *txt)
 	pr_debug("kvm-clock: cpu %d, msr %llx, %s", smp_processor_id(), pa, txt);
 }
 
+static void kvmclock_disable(void)
+{
+	if (msr_kvm_system_time)
+		native_write_msr(msr_kvm_system_time, 0);
+}
+
 static void kvm_save_sched_clock_state(void)
 {
+	/*
+	 * Stop host writes to kvmclock immediately prior to suspend/hibernate.
+	 * If the system is hibernating, then kvmclock will likely reside at a
+	 * different physical address when the system awakens, and host writes
+	 * to the old address prior to reconfiguring kvmclock would clobber
+	 * random memory.
+	 */
+	kvmclock_disable();
 }
 
 static void kvm_restore_sched_clock_state(void)
@@ -208,6 +222,17 @@ static void kvm_restore_sched_clock_state(void)
 	kvm_register_clock("primary cpu clock, resume");
 }
 
+void kvmclock_cpu_action(enum kvm_guest_cpu_action action)
+{
+	/*
+	 * Don't disable kvmclock on the BSP during suspend.  If kvmclock is
+	 * being used for sched_clock, then it needs to be kept alive until the
+	 * last minute, and restored as quickly as possible after resume.
+	 */
+	if (action != KVM_GUEST_BSP_SUSPEND)
+		kvmclock_disable();
+}
+
 #ifdef CONFIG_SMP
 static void kvm_setup_secondary_clock(void)
 {
@@ -215,12 +240,6 @@ static void kvm_setup_secondary_clock(void)
 }
 #endif
 
-void kvmclock_disable(void)
-{
-	if (msr_kvm_system_time)
-		native_write_msr(msr_kvm_system_time, 0);
-}
-
 static void __init kvmclock_init_mem(void)
 {
 	unsigned long ncpus;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385577.1628106 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7j0-0005eF-5b; Thu, 06 Aug 2026 23:42:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385577.1628106; Thu, 06 Aug 2026 23:42:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7iz-0005dt-Uw; Thu, 06 Aug 2026 23:42:09 +0000
Received: by outflank-mailman (input) for mailman id 1385577;
 Thu, 06 Aug 2026 23:42:08 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3oRp1agYKCQYykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 1ws7iy-0005YJ-Nj
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iy-00EMFx-4g
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:08 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3oRp1agYKCQYykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 6a751ba5-2eae-0a2a0a5409dd-0a2a450a9b14-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:08 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3oRp1agYKCQYykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 6a751aa2-f2d2-0a2a450a0019-d155d2c5a962-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:07 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84a251c2e3eso1816043b3a.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059426; x=1786664226; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=7lbZxAdhwKhuj6TvbAGr7x+TgvyyRrRPdrrP8vwGefI=;
        b=gb840K9NfEn/C6h5FHraJYb1bYxHmL0lL+af7n2/IFou3Kddqy4nMf5Ls0/rzrR+Rh
         O57JCe6jNvrDt2PxW9Ntz/Jnnk14mue4Ky9ZMMlfbdVyBUCaHE/Vw4QjJe3XhmHquu10
         H6UOmZyctytwi238Kt7fvPObnMYSMjvMWkf8B1flf/zQXnUWiGpsv8h9RBpvbovbpZrB
         vTFbLPQM0cz8azR/0xmxg/TBTFcLGflRK5w8wMly5OYTl9inaOsayMykDjYkEfBu3IgT
         DryCKtvmQZ6icLzs/KBXjTDeaOLFLBNWNwZmi8P/9JVHcr9dETHo9pvVqZbnQdq7tRF3
         Dh4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059426; x=1786664226;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=7lbZxAdhwKhuj6TvbAGr7x+TgvyyRrRPdrrP8vwGefI=;
        b=j8CWkRjmb5WyasPnc+QPuULC+T+L2Y6u56UwPnFK5Zxj2CZ2fQ1graYNYyqFj0BV8F
         SHj4908dJCK2izyyCKamZXuSCPjIu8/V8r53L1vUn15LFCImNm3CtV8xMaPCx806UnR0
         ydLC9EiL6oUQILMizJxCpqsi9BkWdbDF8d8nEYGkWKmVU5rkAkQ/DiazSBBpWLWZs7yi
         OOdmKjtvsfLJv2VwmMt/TabmfPacFcmZDcYLivnY1S8f0pnmiWRKDO9g5JOAyLduOnlU
         mMriHQ1gpC1N5ZmMNYMsyH+qFZcnjgWMbzdpAgeXzZ/c0v4p/vEuWfkcW0w4HACA8jaf
         MK5w==
X-Forwarded-Encrypted: i=1; AHgh+RrkXt6iv5Dy51jvtrZA+b6E+kLKTlSz1LQQvAfdufIee1L5uBPMHvjgjPrNb05Eu47CrXz12F+zYyo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywxkui/WVTwdm/W9p9Q//zVB6WD/BDAhNQclStWIJHtQru8A8B2
	jhZ3uzP4hrkzHB0Hxx4WAS/rcSwmzfWf8rc7x4RbodH5kjNp+oHbmz4/W0ynQFtuDPCbeejcN6W
	N5Z3dAA==
X-Received: from pgmt23.prod.google.com ([2002:a63:2257:0:b0:c86:61a1:3390])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:7105:b0:3bf:651d:fee0
 with SMTP id adf61e73a8af0-3cba2b5d6a7mr10015839637.19.1786059425491; Thu, 06
 Aug 2026 16:37:05 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:50 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-34-seanjc@google.com>
Subject: [PATCH v6 33/51] x86/xen/time: NOP-ify x86_platform's sched_clock
 save/restore hooks
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059427-51EC2CFC-B6E954E2/0/0
X-purgate-type: clean
X-purgate-size: 1153

NOP-ify the x86_platform sched_clock save/restore hooks when setting up
Xen's PV clock to make it somewhat obvious the hooks aren't used when
running as a Xen guest (Xen uses a paravirtualized suspend/resume flow).

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/xen/time.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 487ad838c441..477441752f40 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -567,6 +567,12 @@ static void __init xen_init_time_common(void)
 	xen_sched_clock_offset = xen_clocksource_read();
 	static_call_update(pv_steal_clock, xen_steal_clock);
 	paravirt_set_sched_clock(xen_sched_clock);
+	/*
+	 * Xen has paravirtualized suspend/resume and so doesn't use the common
+	 * x86 sched_clock save/restore hooks.
+	 */
+	x86_platform.save_sched_clock_state = x86_init_noop;
+	x86_platform.restore_sched_clock_state = x86_init_noop;
 
 	x86_init.hyper.get_tsc_khz = xen_tsc_khz;
 	x86_platform.get_wallclock = xen_get_wallclock;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385578.1628114 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7j1-0005wC-Lz; Thu, 06 Aug 2026 23:42:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385578.1628114; Thu, 06 Aug 2026 23:42:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7j1-0005vG-F5; Thu, 06 Aug 2026 23:42:11 +0000
Received: by outflank-mailman (input) for mailman id 1385578;
 Thu, 06 Aug 2026 23:42:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3oBp1agYKCQUxjfsohlttlqj.htr2js-ij0jqqnxyx.2jsuwtojhy.twl@flex--seanjc.bounces.google.com>)
 id 1ws7iz-0005cX-NB
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7iz-00EMEo-4A
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:09 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3oBp1agYKCQUxjfsohlttlqj.htr2js-ij0jqqnxyx.2jsuwtojhy.twl@flex--seanjc.bounces.google.com>)
 id 6a751b7b-e002-0a2a0a5209dd-0a2a4507ba7e-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:09 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3oBp1agYKCQUxjfsohlttlqj.htr2js-ij0jqqnxyx.2jsuwtojhy.twl@flex--seanjc.bounces.google.com>)
 id 6a751aa1-b4ea-0a2a45070019-d155d2c6dc9f-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:06 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-8487ed7f7beso3066702b3a.0
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059425; x=1786664225; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=EB+XxHVCdw85PrkaMnB06pus7nsirHAVeqpBTRH+yt8=;
        b=XhC8vE42GHi+5vCSKyifOCJlEJLI3t5FZystoXY5ojkacL6DebBjtEp0Ddts3Fin7R
         XS9RUq4lIMCNNcGW+F4qcY/sgewf/MfyjHQJgdr7kqlFDW/VFYOF7lIkk2Ytn9nfghnC
         mCKD581PxuUU755Hcc9VolXuwL2oU2TGzPuXeJSfBYpOCzJx2OSgitQhnSpg3CX3WUhU
         KW2hX2JRmVKVXOohb8uA80pc5rrUeO1ndbXT0pYk6jOFstIEsEXAKyZrujBDnDwygxoi
         UoL9DlkWeqrnqMzOGpGU/azMr5VAjrsjb4m8xXQiKC9sER06nwqfPlcgq4M/lZl9znxQ
         ZeiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059425; x=1786664225;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=EB+XxHVCdw85PrkaMnB06pus7nsirHAVeqpBTRH+yt8=;
        b=elFBD3FU3K4voGsqh7GEA1LmxC0Lx0RVuWn/qbrPF0lB4Yf83zENgfe3mrRe6yulKU
         oM6ST81XRe4OTOQS6Cz3anNgL1/Ih7hKSS9PWBeHY834fzudIuHBoCAZGAeHO7779vUE
         FoG/ROYXwKiE0XTUP9e/BPZTFnVBx4Q72fhSQo+5U9rn9sdbADNUc3igHwrTXiIBxdyJ
         TPX6B1aSZKm5H5ddSYWFtjmYftt9Qvh+l09vRu9D3CS3XpKUK3xWE71u5mizN8PrrNBz
         JJnW47Bnd+OfMTxGt2KaUFFVc2SC55zhTi+Wf757s4LII+CKsRntRVse2K/2zjA4IKuF
         I+qw==
X-Forwarded-Encrypted: i=1; AHgh+RoVwlC3nooX7heHAPtWMwm9icV9ekzgXjXKFx0vzlfOOwYTEL8G3jOxBlBLNAFlBBsmw6O/mR/YBxU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6l+pBldenHktCu3QJfTK7bLdIVrJx0fLYaTv/fWJhL4a3YDll
	+sNGBOW/91wiTs1PwESm/HQIDpLb9BO2dwmbwD1Bc2t786ej6NFmT43rwhumqXz2CFMSsharLWz
	/0EOjNw==
X-Received: from pfbmc40.prod.google.com ([2002:a05:6a00:76a8:b0:84c:1460:ab72])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2441:b0:848:5951:ff78
 with SMTP id d2e1a72fcca58-84f2e1525d0mr19690745b3a.36.1786059424271; Thu, 06
 Aug 2026 16:37:04 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:49 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-33-seanjc@google.com>
Subject: [PATCH v6 32/51] x86/kvmclock: Move sched_clock save/restore helpers
 up in kvmclock.c
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-ef75cf/1786059426-A78D1AE4-23391718/0/0
X-purgate-type: clean
X-purgate-size: 4420

Move kvmclock's sched_clock save/restore helper "up" so that they can
(eventually) be referenced by kvm_sched_clock_init().

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 108 ++++++++++++++++++-------------------
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 4bc0495f1f9e..07e875738c39 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -71,6 +71,25 @@ static int kvm_set_wallclock(const struct timespec64 *now)
 	return -ENODEV;
 }
 
+static void kvm_register_clock(char *txt)
+{
+	struct pvclock_vsyscall_time_info *src = this_cpu_hvclock();
+	u64 pa;
+
+	if (!src)
+		return;
+
+	pa = slow_virt_to_phys(&src->pvti) | 0x01ULL;
+	wrmsrq(msr_kvm_system_time, pa);
+	pr_debug("kvm-clock: cpu %d, msr %llx, %s", smp_processor_id(), pa, txt);
+}
+
+static void kvmclock_disable(void)
+{
+	if (msr_kvm_system_time)
+		native_write_msr(msr_kvm_system_time, 0);
+}
+
 static u64 kvm_clock_read(void)
 {
 	u64 ret;
@@ -112,6 +131,30 @@ static noinstr u64 kvm_sched_clock_read(void)
 	return pvclock_clocksource_read_nowd(this_cpu_pvti()) - kvm_sched_clock_offset;
 }
 
+static void kvm_save_sched_clock_state(void)
+{
+	/*
+	 * Stop host writes to kvmclock immediately prior to suspend/hibernate.
+	 * If the system is hibernating, then kvmclock will likely reside at a
+	 * different physical address when the system awakens, and host writes
+	 * to the old address prior to reconfiguring kvmclock would clobber
+	 * random memory.
+	 */
+	kvmclock_disable();
+}
+
+#ifdef CONFIG_SMP
+static void kvm_setup_secondary_clock(void)
+{
+	kvm_register_clock("secondary cpu clock");
+}
+#endif
+
+static void kvm_restore_sched_clock_state(void)
+{
+	kvm_register_clock("primary cpu clock, resume");
+}
+
 static inline void kvm_sched_clock_init(bool stable)
 {
 	kvm_sched_clock_offset = kvm_clock_read();
@@ -124,6 +167,17 @@ static inline void kvm_sched_clock_init(bool stable)
 		sizeof(((struct pvclock_vcpu_time_info *)NULL)->system_time));
 }
 
+void kvmclock_cpu_action(enum kvm_guest_cpu_action action)
+{
+	/*
+	 * Don't disable kvmclock on the BSP during suspend.  If kvmclock is
+	 * being used for sched_clock, then it needs to be kept alive until the
+	 * last minute, and restored as quickly as possible after resume.
+	 */
+	if (action != KVM_GUEST_BSP_SUSPEND)
+		kvmclock_disable();
+}
+
 /*
  * If we don't do that, there is the possibility that the guest
  * will calibrate under heavy load - thus, getting a lower lpj -
@@ -183,60 +237,6 @@ static struct clocksource kvm_clock = {
 	.enable		= kvm_cs_enable,
 };
 
-static void kvm_register_clock(char *txt)
-{
-	struct pvclock_vsyscall_time_info *src = this_cpu_hvclock();
-	u64 pa;
-
-	if (!src)
-		return;
-
-	pa = slow_virt_to_phys(&src->pvti) | 0x01ULL;
-	wrmsrq(msr_kvm_system_time, pa);
-	pr_debug("kvm-clock: cpu %d, msr %llx, %s", smp_processor_id(), pa, txt);
-}
-
-static void kvmclock_disable(void)
-{
-	if (msr_kvm_system_time)
-		native_write_msr(msr_kvm_system_time, 0);
-}
-
-static void kvm_save_sched_clock_state(void)
-{
-	/*
-	 * Stop host writes to kvmclock immediately prior to suspend/hibernate.
-	 * If the system is hibernating, then kvmclock will likely reside at a
-	 * different physical address when the system awakens, and host writes
-	 * to the old address prior to reconfiguring kvmclock would clobber
-	 * random memory.
-	 */
-	kvmclock_disable();
-}
-
-static void kvm_restore_sched_clock_state(void)
-{
-	kvm_register_clock("primary cpu clock, resume");
-}
-
-void kvmclock_cpu_action(enum kvm_guest_cpu_action action)
-{
-	/*
-	 * Don't disable kvmclock on the BSP during suspend.  If kvmclock is
-	 * being used for sched_clock, then it needs to be kept alive until the
-	 * last minute, and restored as quickly as possible after resume.
-	 */
-	if (action != KVM_GUEST_BSP_SUSPEND)
-		kvmclock_disable();
-}
-
-#ifdef CONFIG_SMP
-static void kvm_setup_secondary_clock(void)
-{
-	kvm_register_clock("secondary cpu clock");
-}
-#endif
-
 static void __init kvmclock_init_mem(void)
 {
 	unsigned long ncpus;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385586.1628124 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7j6-0006Xe-1G; Thu, 06 Aug 2026 23:42:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385586.1628124; Thu, 06 Aug 2026 23:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7j5-0006XH-Qu; Thu, 06 Aug 2026 23:42:15 +0000
Received: by outflank-mailman (input) for mailman id 1385586;
 Thu, 06 Aug 2026 23:42:13 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3php1agYKCQs3plyunrzzrwp.nzx8py-op6pwwt343.8py02zupn4.z2r@flex--seanjc.bounces.google.com>)
 id 1ws7j3-0006JR-T4
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7j3-00EMEo-9g
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:13 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3php1agYKCQs3plyunrzzrwp.nzx8py-op6pwwt343.8py02zupn4.z2r@flex--seanjc.bounces.google.com>)
 id 6a751bae-e002-0a2a0a5209dd-0a2a4503e136-26
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:13 +0200
Received: from [209.85.214.198] (helo=mail-pl1-f198.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3php1agYKCQs3plyunrzzrwp.nzx8py-op6pwwt343.8py02zupn4.z2r@flex--seanjc.bounces.google.com>)
 id 6a751aa7-fae8-0a2a45030019-d155d6c6ad5d-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:12 +0200
Received: by mail-pl1-f198.google.com with SMTP id
 d9443c01a7336-2cc5faecf01so51051255ad.1
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059431; x=1786664231; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=dLl1t0qRZTm556OBeVqKVx/DHfexmKODeXAiUOaDm4I=;
        b=ln7BlPKUPiOO/cp4dV5mxjLgoz+Vyp23kyPFqwsk+elJtcPFrpcLepHogTzrv3GqRt
         j2JUtiidAiBz4/pMrBPzzdZqoK4dNw3S+Blha7EtBpnF443vs2aT7n2KpIrdAszljvkK
         C5BaGsrYvMlYI3RbhfKb9HtKbaZ24AagDQaKfZJZ1qv86YLnefDX+a0YdPJtkylPh0TX
         AVNKkD9RYbRTuPQiqGvxWUVAzw9R2v0LMOlmPqnFMrqeIWiju1SWviJa7NK+xM5ClBGO
         UdYfKONlGTAbsIDcm1K27/Bgc+whh1G0JIxjiTG3DFvH5w7Mwj4HKDgsaP0ZIYKl85SG
         Y4/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059431; x=1786664231;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=dLl1t0qRZTm556OBeVqKVx/DHfexmKODeXAiUOaDm4I=;
        b=jiRdE5uef4VzH9yeYjFcXpXov5OSc+eXAuCAp+rJblTbQ+DZNCymotlzEd1mJI3lpT
         1R4wijZ545e5s2M+MgVGEd7+6HHBzHITgxqhM3wn6qx3D0UqaOY0cBZU/RbZIvBEOzE+
         Pz+QGOumkmK4wLt5Z3fEvtoW87hLAhUUiO+lXr1PHfklxfNKCoVhHt288nz7mssTTdJK
         JTyjT5V2Vy0VwdST+m0SSwhk/NfmOsc/2iU815erdSq/hYAbPzYuLZ9l2Y3Awm0djUxc
         jgyghvJTLAjnFz2cwckURDGiRitlDsGKGClfWyHYYz8DhLEujlPHsNk0C+UNRLhn6xcr
         7Zmg==
X-Forwarded-Encrypted: i=1; AHgh+Ro9iegpaXyxjhDozmkhSSzneAg2mniL+pEZGc0bvT+nncByT3iQAMFVHvdYhQUV8L8g0fM2MHyYGys=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlxbnLvdVezlMjlUqO8aZVyW246GdEHsmVrQWz+j3Litjhfmpr
	h4HH1dPRNoR5tzViUNX3iU3rU+rONO0PN91/SF71alOCmLuWbr8OJ3EWOdkPoGojnPkRDlOMvCf
	0as/T1A==
X-Received: from pjzg4.prod.google.com ([2002:a17:90a:e584:b0:38e:b470:e6db])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2590:b0:38f:2168:b9cb
 with SMTP id 98e67ed59e1d1-3903c572a05mr18787499a91.9.1786059430539; Thu, 06
 Aug 2026 16:37:10 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:54 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-38-seanjc@google.com>
Subject: [PATCH v6 37/51] x86/kvmclock: Move kvm_sched_clock_init() down in kvmclock.c
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-33051d/1786059432-77AC44E9-8818F214/0/0
X-purgate-type: clean
X-purgate-size: 2297

Move kvm_sched_clock_init() "down" so that it can reference the global
kvm_clock structure without needing a forward declaration.

Opportunistically mark the helper as "__init" instead of "inline" to make
its usage more obvious; modern compilers don't need a hint to inline a
single-use function, and an extra CALL+RET pair during boot is a complete
non-issue.  And, if the compiler ignores the hint and does NOT inline the
function, the resulting code may not get discarded after boot due lack of
an __init annotation.

No functional change intended.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/kvmclock.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 5b9955343199..5220d205abc7 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -155,20 +155,6 @@ static void kvm_restore_sched_clock_state(void)
 	kvm_register_clock("primary cpu clock, resume");
 }
 
-static inline void kvm_sched_clock_init(bool stable)
-{
-	kvm_sched_clock_offset = kvm_clock_read();
-	__paravirt_set_sched_clock(kvm_sched_clock_read, stable,
-				   kvm_save_sched_clock_state,
-				   kvm_restore_sched_clock_state);
-
-	pr_info("kvm-clock: using sched offset of %llu cycles",
-		kvm_sched_clock_offset);
-
-	BUILD_BUG_ON(sizeof(kvm_sched_clock_offset) >
-		sizeof(((struct pvclock_vcpu_time_info *)NULL)->system_time));
-}
-
 void kvmclock_cpu_action(enum kvm_guest_cpu_action action)
 {
 	/*
@@ -325,6 +311,20 @@ static int kvmclock_setup_percpu(unsigned int cpu)
 	return p ? 0 : -ENOMEM;
 }
 
+static __init void kvm_sched_clock_init(bool stable)
+{
+	kvm_sched_clock_offset = kvm_clock_read();
+	__paravirt_set_sched_clock(kvm_sched_clock_read, stable,
+				   kvm_save_sched_clock_state,
+				   kvm_restore_sched_clock_state);
+
+	pr_info("kvm-clock: using sched offset of %llu cycles",
+		kvm_sched_clock_offset);
+
+	BUILD_BUG_ON(sizeof(kvm_sched_clock_offset) >
+		sizeof(((struct pvclock_vcpu_time_info *)NULL)->system_time));
+}
+
 void __init kvmclock_init(bool prefer_tsc)
 {
 	u8 flags;
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385600.1628134 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7jB-0007Dh-E5; Thu, 06 Aug 2026 23:42:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385600.1628134; Thu, 06 Aug 2026 23:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7jB-0007D1-5l; Thu, 06 Aug 2026 23:42:21 +0000
Received: by outflank-mailman (input) for mailman id 1385600;
 Thu, 06 Aug 2026 23:42:20 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3rBp1agYKCRE9vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--seanjc.bounces.google.com>)
 id 1ws7jA-00077X-06
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7j9-00H1om-DF
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:19 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3rBp1agYKCRE9vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--seanjc.bounces.google.com>)
 id 6a751b6a-5cb7-0a2a0a5109dd-0a2a45058b62-42
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:19 +0200
Received: from [209.85.215.199] (helo=mail-pg1-f199.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3rBp1agYKCRE9vr40tx55x2v.t53Ev4-uvCv22z9A9.Ev46850vtA.58x@flex--seanjc.bounces.google.com>)
 id 6a751aad-4cb1-0a2a45050019-d155d7c7c87d-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:18 +0200
Received: by mail-pg1-f199.google.com with SMTP id
 41be03b00d2f7-cbe62e01567so2346093a12.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059437; x=1786664237; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=qISz6FBmFt+Rjc4N/P+Kp805/IDsq2ZStMxtEE1uDRQ=;
        b=khAI2sx07TzbmQEw6txieutghq3rpZ+AQVw90UMqkHZhFed1yn/lwVe1KoASch7LR6
         kgXrdwQ/QHM5lheLbgs1O99YVOZizjfxGkdhJ0rf46PBrmLZdrsEa9zlu5qOsENd4Y3y
         YVlcMIh/j2nEo3XDHvqJ4tYT51cLVr6bLVhvf0QiA5XunPOUssF2ukbfuD8mKfvM32D6
         T0l5l/EkJWYRr6neF1E786kEmtGV2tHRuY6BcpWxgq9c4hj/wEwzt81iInHIsw0g1VHk
         tGbv8fJqko+cznyBtjt3w3efNsWPjjSjV9fgYG8MSAVviVVIrfbykAUoBHR9//9ZPsIa
         cskA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059437; x=1786664237;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=qISz6FBmFt+Rjc4N/P+Kp805/IDsq2ZStMxtEE1uDRQ=;
        b=a4gDH3zilvz6psJlPfimaccTRWt4FSGU9Ixdq5gxQOQCG16h0/Ec1jaPtW4z4yCMZU
         fupSt3HjLpmybbvwOBeQ5RWnESdOeqjW1tQvQtQ/pf8GzVdjbD0/u4gwqB5AxXwXDu7/
         hYZ/PXCpTJzrMYCYL4/hzLmdsUOf9sOFYrHa1ecZa9lkugBmLc0M6JY2abSfSBvdeeS1
         cp70a2oRmS3ajwmYeO3CgdaXFeLfrjqQEqzoDMkIfhQQM9lZGhFSOLnjk4F+S9t9zdMi
         2v+8QQBxUOkW18Tr1Df0G4Li/+RU+pxAn0cBEo/IMsf35+rRcG3ciGKwuB23CWKdaaAx
         HfHg==
X-Forwarded-Encrypted: i=1; AHgh+Rpcjmqouk2srAGMannHyFL81UuKPtQ7SFBX/JN2sQo3beGoQzeBhIRG7R8hxaYL/baDdFQS59tPqCM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxE1zeLni3+dnu/NlJOvYX1SpDYDLNt+s05AJXOxEEMkB+7u7n1
	QczARDNgk0g4YzK2h0x9YuBHCq9R5aMcczGww7M7FuMdGm1cPNowJRDq8/Q/sOLL0fdOOsMvZlR
	utbFUVQ==
X-Received: from pgbep6.prod.google.com ([2002:a05:6a02:2646:b0:c99:90dc:7b3f])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:6112:b0:3b4:e4f6:4f15
 with SMTP id adf61e73a8af0-3cb85e9922cmr22668021637.5.1786059436589; Thu, 06
 Aug 2026 16:37:16 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:59 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-43-seanjc@google.com>
Subject: [PATCH v6 42/51] timekeeping: Resume clocksources before reading
 persistent clock
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c201ff/1786059438-F6AB72A1-D1235742/13/0
X-purgate-type: clean
X-purgate-size: 1667

When resuming timekeeping after suspend, restore clocksources prior to
reading the persistent clock.  Paravirt clocks, e.g. kvmclock, tie the
validity of a PV persistent clock to a clocksource, i.e. reading the PV
persistent clock will return garbage if the underlying PV clocksource
hasn't been enabled.  The flaw has gone unnoticed because kvmclock is a
mess and uses its own suspend/resume hooks instead of the clocksource
suspend/resume hooks, which happens to work by sheer dumb luck (the
kvmclock resume hook runs before timekeeping_resume()).

Note, there is no evidence that any clocksource supported by the kernel
depends on a persistent clock.

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 kernel/time/timekeeping.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 97db2e9393f9..585525f5c1f6 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2226,11 +2226,16 @@ void timekeeping_resume(void)
 	u64 cycle_now, nsec;
 	unsigned long flags;
 
-	read_persistent_clock64(&ts_new);
-
 	clockevents_resume();
 	clocksource_resume();
 
+	/*
+	 * Read persistent time after clocksources have been resumed.  Paravirt
+	 * clocks have a nasty habit of piggybacking a persistent clock on a
+	 * system clock, and may return garbage if the system clock is suspended.
+	 */
+	read_persistent_clock64(&ts_new);
+
 	raw_spin_lock_irqsave(&tk_core.lock, flags);
 
 	/*
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Thu Aug 06 23:42:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Aug 2026 23:42:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385603.1628141 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7jC-0007VZ-QY; Thu, 06 Aug 2026 23:42:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385603.1628141; Thu, 06 Aug 2026 23:42:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ws7jC-0007VH-Ie; Thu, 06 Aug 2026 23:42:22 +0000
Received: by outflank-mailman (input) for mailman id 1385603;
 Thu, 06 Aug 2026 23:42:21 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3qhp1agYKCQ87tp2yrv33v0t.r31Ct2-stAt00x787.Ct2463ytr8.36v@flex--seanjc.bounces.google.com>)
 id 1ws7jB-0007C8-1p
 for xen-devel@lists.xenproject.org; Thu, 06 Aug 2026 23:42:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ws7jA-00EMFx-Ey
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 01:42:20 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3qhp1agYKCQ87tp2yrv33v0t.r31Ct2-stAt00x787.Ct2463ytr8.36v@flex--seanjc.bounces.google.com>)
 id 6a751ba5-2eae-0a2a0a5409dd-0a2a450a9b14-44
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:42:20 +0200
Received: from [209.85.210.199] (helo=mail-pf1-f199.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3qhp1agYKCQ87tp2yrv33v0t.r31Ct2-stAt00x787.Ct2463ytr8.36v@flex--seanjc.bounces.google.com>)
 id 6a751aab-f2d2-0a2a450a0019-d155d2c7e928-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 01:37:16 +0200
Received: by mail-pf1-f199.google.com with SMTP id
 d2e1a72fcca58-84e3d575d6eso4633580b3a.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 16:37:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786059434; x=1786664234; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=gswAR/5wSepHR0W/S6/oLzBYH0wiOXioT7kjM1AQclw=;
        b=ditBFt2pCyTk3Lwqeow5V9ILHsm3qtTn0mOvL72447NgS25l7p2yLkWXNAXeCwUu/c
         B0BqLBaYRI/7PxK9Vtq1qT69Wub2AjDSLTrHVbUzss90rE3KIzkxgtBqHNkjxgJf7tXv
         uFyK5nC09ZyFlkVePY8eP+y9Jxlea3aL/645AmHsfLTkzUWB69xuei4gtlZKBd6Gw5bs
         hPoydVOX8MniXlOZhpfCQBw0AbucCNZmFckVZrEvBD1NX5b40T0MIdpP+u3cdM8FLhtk
         9eRnzJQo9Mu4Y16N0OWOHCrAOFyWwc3qJ0y9GiwR1SkmbYVhR81gIWy+F3t+gJP66yqY
         tmUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786059434; x=1786664234;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:reply-to:x-gm-message-state:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=gswAR/5wSepHR0W/S6/oLzBYH0wiOXioT7kjM1AQclw=;
        b=KVyIwsJWS45tCncstCMLiuaGwKqUQ0u97XDioZr+vswXtR/pQ4EyA2tUINqDL7liE5
         sRR9kZTBQQ8bCN7n1lZlZ7vabAfw5Ld0+kBUXMmrQ8oAJBlhILF48uNppkZVDhKNK2Rx
         ur1dqpcERHqxhfOEWbUwPIrQkOlIgQwvCaIPzgFK1lrZNPk2+FNDITAhoT27rN1cW/TX
         8w9NM5bi4PWTCZ5PCkUAPFxXUu9+ijz3Wx8+IHpr7sC8RX3u/7PUYKzMl+AZwohuqfbJ
         P+N0bN2eYz4D3Mpu2b47hTj2zpAzTl7qGJakHOcWm145a5dF0EZJzuEVmJ5Tk0kZEyNm
         /bLA==
X-Forwarded-Encrypted: i=1; AHgh+RqHi0L2msiSVT29fORRrIRzV87igwW1xJ1Y++EIWAXlPP0VdbO003eGehNtRf4XfJ1YXmTBZ8vymeA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzsq2sXIJbs6xGM55XG29cpMsV5z2mnqKyMPEngGm9RNrjQaoXv
	H+vQypukfCsxPP/i81JoiuE7f6nTOzZSrwMN0NFcvv2rj24ppk7ghZiFCTGIRifrctmIPrZc9Wc
	RvOg3EQ==
X-Received: from pfjt11.prod.google.com ([2002:a05:6a00:21cb:b0:84e:2062:2edb])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:9506:b0:84a:29a7:f64c
 with SMTP id d2e1a72fcca58-84f2de45511mr20003910b3a.0.1786059434181; Thu, 06
 Aug 2026 16:37:14 -0700 (PDT)
Reply-To: Sean Christopherson <seanjc@google.com>
Date: Thu,  6 Aug 2026 16:35:57 -0700
In-Reply-To: <20260806233609.212337-1-seanjc@google.com>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <20260806233609.212337-41-seanjc@google.com>
Subject: [PATCH v6 40/51] x86/pvclock: WARN if pvclock's valid_flags are overwritten
From: Sean Christopherson <seanjc@google.com>
To: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786059436-524DFCFC-23BCB0E7/13/0
X-purgate-type: clean
X-purgate-size: 780

WARN if the common PV clock valid_flags are overwritten; all PV clocks
expect that they are the one and only PV clock, i.e. don't guard against
another PV clock having modified the flags.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kernel/pvclock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index a51adce67f92..8d098841a225 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -21,6 +21,7 @@ static struct pvclock_vsyscall_time_info *pvti_cpu0_va __ro_after_init;
 
 void __init pvclock_set_flags(u8 flags)
 {
+	WARN_ON(valid_flags);
 	valid_flags = flags;
 }
 
-- 
2.55.0.679.g6767b8d81c-goog



From xen-devel-bounces@lists.xenproject.org Fri Aug 07 05:22:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 05:22:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385725.1628151 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsD2O-0002sa-UF; Fri, 07 Aug 2026 05:22:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385725.1628151; Fri, 07 Aug 2026 05: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wsD2O-0002sS-Qg; Fri, 07 Aug 2026 05:22:32 +0000
Received: by outflank-mailman (input) for mailman id 1385725;
 Fri, 07 Aug 2026 03:23:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dbgh9129@gmail.com>) id 1wsBBH-0001eF-Fl
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 03:23:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsBBG-00GxkT-5W
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 05:23:34 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dbgh9129@gmail.com>)
 id 6a754faf-e002-0a2a0a5209dd-0a2a450a958c-2
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 05:23:34 +0200
Received: from [209.85.160.171] (helo=mail-qt1-f171.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dbgh9129@gmail.com>)
 id 6a754fb5-f2d2-0a2a450a0019-d155a0abe157-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 05:23:33 +0200
Received: by mail-qt1-f171.google.com with SMTP id
 d75a77b69052e-52b4e988c77so19005511cf.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 20:23:33 -0700 (PDT)
Received: from i4-gl-tmk5904.ad.psu.edu ([130.203.156.186])
 by smtp.gmail.com with ESMTPSA id
 d75a77b69052e-52d1663e9e1sm3438561cf.30.2026.08.06.20.23.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 06 Aug 2026 20:23:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786073012; x=1786677812; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=T5tWYfkrSYEAFJzgjYou2Lj+31bzExLORMbEtdMFcLw=;
        b=K2tIR2uxsfa+PGMPzJQddWSF//kpOlHCmsCoaNIOjt/UrHoGlPzx/g8LsaRyV9nZiI
         HtUhp7xaUPKjLMWbNgkduFKWS4LDL9kiFQ5Dh12zCnH2pG6HNcuSYDKhsu7eWBciyh7e
         jk+ZRHXQgRgTT5U5iuuxj9Xs6BszIJSSbJwbBUm4AgJJM9Kp1iKUoUGMGMYVImjwBnPg
         ExoDppTRna+zCeTdQ0zGuHFlPzlRIARCrSzIoJyCZqMjRUYuJ8aQQZZINMQ0uKBEHGKR
         XgwUmviMsfNWNBvFDilE0w9FiEpEqJQlRlMqmMsQt41MosAd9nLU/mb/EKE5ByHqSICF
         FFxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786073012; x=1786677812;
        h=content-transfer-encoding:mime-version: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=T5tWYfkrSYEAFJzgjYou2Lj+31bzExLORMbEtdMFcLw=;
        b=gD2IQQlTfn6UZbIh8j9W7SzmyLtn44TqzWv71evRS4kVDb5G3yyCHBev8z9Ute6Ngr
         Yvw74QPbkk73z4ZYyK0xEwJK10hU2q9YiVHiwdomTCZwED684ArGXKUoNO6EyW4xjktU
         QPOn3gp0hyLIM3+Csc4/4U/6bYp+lLhuRATJHqYppqZpYOJFgYiCh8DRHEGB8R8QyI2e
         mNACg7Yge2/+Mi6Ock6YqE2j9+oiZakQZa4uu7Qnvo9rlOPfgIzPru/8xOyHIn36hLDJ
         ao8Q2dtuHHHRSVICkUf1cSclhReAtq7hqtUZkN9ffUNdSGPnxv44gq3lJQ4qNKtRmc7+
         AZKA==
X-Forwarded-Encrypted: i=1; AHgh+RpcElaMLWmbEakA4zuqHOUDmj85H7drWTznBrHfP8liIBujiEBo3wEk3RVw02bZgBo/+Fe1yEbGQBc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyzAw0k9Jw2i4u5WmQBEGnRxmXi16yQ4eFLcrFsNjIsKisgx3o
	kEB3MdUy7evKl2/jspocY9QWJ4muRRLkLpMxZk99c2BP4cZcgAuESzH2
X-Gm-Gg: AR+sD13iYVBdptK2G5BYPyijNXD2ybPPdixxc5uMPPYCmd31E66ZoBCpm0MeHNf645d
	KSvEIKsJAPWuY3QgLaOjLGvMK3YMuP4PJrBNnzt0kqlNIDzRkDKFNttzbGvGTXQW2ZSagumzTmY
	XaSuywRXrLfviI8B9RMynOoy8caU7YrYIm8Jo3DMueuLEZySgFhwoHxvGvHq76Nx9+/1EJ+pVYs
	heRpXWiobNYIrx1j/MQnq6+7X7ZO7VpYu/2e1r1Q7qh/unfGHaa43mTck72WIMnWnz07wXo4c6Q
	Bnpyv608zJbSTuT6gKjl4gnjpUv/pavwsEaAfD5Mxz/RzMKjv+vzMBT+fwgxDCArZIO7dEZEFx5
	LUjL8Fqtuoo0pU06fy/pj0HBXJYFmkFb4ue4tGiS/SSMyPzcOEQ1JcXjE2WXqgWM+h8Xd61m2Cy
	ZWKTZNemXSRVdt9N+pB2VjpEVXd0RP5ai2WKvY8L01KWmGYUeWa7QkYn2yaIcdGPDsiX3A0PyK7
	LfOJiq+5w8WoXsJiP8U8c06FoO3e9flcQuo95oXb4476qhfxf1atg5B7S2HinI=
X-Received: by 2002:a05:622a:8cb:b0:51c:d1c:10e3 with SMTP id d75a77b69052e-52ce619a1c0mr217368161cf.35.1786073012343;
        Thu, 06 Aug 2026 20:23:32 -0700 (PDT)
From: Yuho Choi <dbgh9129@gmail.com>
To: jgross@suse.com
Cc: sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com,
	thorsten.blum@linux.dev,
	jason.andryuk@amd.com,
	alhouseenyousef@gmail.com,
	kees@kernel.org,
	darwi@linutronix.de,
	jpoimboe@kernel.org,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org,
	alhouseenyoursef@gmail.com,
	Yuho Choi <dbgh9129@gmail.com>
Subject: [PATCH v1] xenbus: Unregister reboot notifier on init failure
Date: Thu,  6 Aug 2026 23:23:26 -0400
Message-ID: <20260807032326.940377-1-dbgh9129@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786073013-502F0CFC-77C0471A/0/0
X-purgate-type: clean
X-purgate-size: 1551

xs_init() registers xs_reboot_nb before initializing XenStore
communications and starting xenwatch. If either operation fails, the
notifier remains registered and a later initialization attempt can hit a
duplicate registration.

Check the notifier registration result and unregister it on every
subsequent failure path.

Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
 drivers/xen/xenbus/xenbus_xs.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index d1cca4acb6f3..62274d377b3a 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -915,19 +915,27 @@ int xs_init(void)
 	int err;
 	struct task_struct *task;
 
-	register_reboot_notifier(&xs_reboot_nb);
+	err = register_reboot_notifier(&xs_reboot_nb);
+	if (err)
+		return err;
 
 	/* Initialize the shared memory rings to talk to xenstored */
 	err = xb_init_comms();
 	if (err)
-		return err;
+		goto err_unregister_reboot_notifier;
 
 	task = kthread_run(xenwatch_thread, NULL, "xenwatch");
-	if (IS_ERR(task))
-		return PTR_ERR(task);
+	if (IS_ERR(task)) {
+		err = PTR_ERR(task);
+		goto err_unregister_reboot_notifier;
+	}
 
 	/* shutdown watches for kexec boot */
 	xs_reset_watches();
 
 	return 0;
+
+err_unregister_reboot_notifier:
+	unregister_reboot_notifier(&xs_reboot_nb);
+	return err;
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 07 06:23:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 06:23:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385762.1628159 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsDyi-0006NO-4x; Fri, 07 Aug 2026 06:22:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385762.1628159; Fri, 07 Aug 2026 06:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsDyi-0006NH-1s; Fri, 07 Aug 2026 06:22:48 +0000
Received: by outflank-mailman (input) for mailman id 1385762;
 Fri, 07 Aug 2026 06:22:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wsDyh-0006N9-3p
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 06:22:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsDyg-009zRA-CJ
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 08:22:46 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7579ad-e002-0a2a0a5209dd-0a2a4506a050-6
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 08:22:46 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7579b6-195a-0a2a45060019-d1558031d130-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 08:22:46 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so6166875e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 23:22:46 -0700 (PDT)
Received: from ?IPV6:2003:ca:b70d:300d:c60:b520:be19:f863?
 (p200300cab70d300d0c60b520be19f863.dip0.t-ipconnect.de.
 [2003:ca:b70d:300d:c60:b520:be19:f863])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995ea2d84csm7397145e9.12.2026.08.06.23.22.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 23:22:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786083766; x=1786688566; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=2Mju8ec2JsULKhgYsZxe4dHqgEj7FEBGGh4W6raF2x0=;
        b=aFb6OKuPHp38Vnm3K/ztincFsJ6AnlKzVeGrBp+CZQZYrCmpTPevw5/GmPOv9RqDIf
         z6Pzv8WfiawoaTA2EdNMa7S5mfgSmseVKl9uIFgPi69K6Tz0iaVveG6ks4HrY+YqD5hT
         ynFrcnzIFgIS/YMwAhca2W8WFHnrlLeYTsBCNRAlXmsTkQWWckzFscOQ+GyABqWgEpXS
         C3UueuYuGf30jnCilqdt8wQFV9YMRQxAngLFDLSBjCN6zNItILpB26/8CAyOjtJlrkYa
         uGII/8Va0+fhDs5YVr+8bNK8DDVhMI9ItAG8e4OH0yBaedxX95H0Lr5T/lXRRySwvIDD
         aBHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786083766; x=1786688566;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=2Mju8ec2JsULKhgYsZxe4dHqgEj7FEBGGh4W6raF2x0=;
        b=l1FF8xIXuJP1P9ZumO1d2znM4LAgAZJRqMp5+GN5hHuaC8bqrBf61mYDJUWSU/drvm
         9UIFaZByt8uPk0MXIDiVvv4nNHI234XEBpotReJhygZP7c5/xERbUyrXr5shmRmCnGB8
         TChYGpCos4/4Ep0C8eOqMRjrZ7qrgqSveii+kVFJwWKWOiEOQFXIKu54DQdPLnlYkImH
         BfpacMfoId2cMOHYT/G3Jhn8NZjDG4cOCiCWbpJe/Zu06jKYb84LSrIttzHZl3mKokZF
         Zaitrc4kx77Wv7hELmjh8fPTyHaCiFEfnthQJ95u5nEP7JvGGauRy3bifnUKI6OfGlA5
         jLLg==
X-Forwarded-Encrypted: i=1; AHgh+Rqo3PhH0J+UhsQWAVINLkUafapKkyKMHsUFdd7NjkPXRHSW6yNjCKVfGrtT3adgurEeT/aMCNRLayo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYwYslfZEmzuHVWS2fS/HJzDTR1KAV/pi4/XioElbdaqr0xOkQ
	03Teydyz6iCG1WoR5zIQBhTVHf0slDpJKJnYb0pWb26gERPatcyGvKVBiAIv74S97NVi4onP1fN
	LeYQ=
X-Gm-Gg: AR+sD11vFDdVezDIwOCN3IiWDFpFZWwjs8XeX+t4SCILtmtU0JLYoQHthzCXTDhIyjp
	E9Uxc5uxPGiu5LzdOUSifhslLNeDpxDMiEU6veuvhBQReOk4phpcmziKeW4u+pdGUG7Knn+e11E
	LTqzII2Np4XPIyeXZStPVTNinQydx2fZHfohxXQQ59oqbyjzDEF0840rpYW/L2oE1wD/16TK2T/
	LEAco4BO3+1AyVhSqsJ/MKqaqg5wHmFGl+DNxwLg/mK+MtHHkLf9IlLUd4bcl+ado8pqYq/tNz+
	71Lfz+/qVIKzbtmAvO7YNvBBTs6+5J7VVWkvasEfi0D37SHdloJDI5HPOsfxTeFgOIHJcVvOGFN
	cCZ6z50sbjk/HVewjFC+/b2io4pWC088ATGqPEJ79jRXYJpMO/O8b2aSKN+TlMjOzikX9zR1DRq
	8iuIzqHS/JERaX29J2DF0U5HeFbSXjWBOptktT8HFDqxEAsITQ0qnXAmma2efQ+MRrIj0dH6Lsf
	2+8vfbOgVQ8T0Qvf/9mdAKEGqNihxBiJisWZj4LxyFs4wXZz7emkgYsAi5nwtHegnlZHtC37Fs4
	Hk2dV468UmyvVcvY3L8=
X-Received: by 2002:a05:600c:198f:b0:492:4e09:9fc1 with SMTP id 5b1f17b1804b1-4994e7cc5a4mr272904255e9.15.1786083765693;
        Thu, 06 Aug 2026 23:22:45 -0700 (PDT)
Message-ID: <c818745e-6f61-4b32-b7f5-ee5b7ff82981@suse.com>
Date: Fri, 7 Aug 2026 08:22:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86/pci: prevent cross-device accesses in
 pci_mmcfg_{read,write}()
To: Roger Pau Monne <roger@xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-2-roger@xenproject.org>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260806152619.23881-2-roger@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786083766-FD20877B-0B928D98/0/0
X-purgate-type: clean
X-purgate-size: 1528

On 06.08.2026 17:26, Roger Pau Monne wrote:
> Introduce a specific check that prevents an accesses from spilling across
> two devices.
> 
> Signed-off-by: Roger Pau Monné <roger@xenproject.org>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
albeit with a remark:

> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> @@ -61,7 +61,8 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
>      char __iomem *addr;
>  
>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
> +    if (unlikely((bus > 255) || (devfn > 255) ||
> +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE))) {
>  err:        *value = -1;
>          return -EINVAL;
>      }
> @@ -91,7 +92,8 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
>      char __iomem *addr;
>  
>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
> +    if (unlikely((bus > 255) || (devfn > 255) ||
> +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE)))
>          return -EINVAL;
>  
>      addr = pci_dev_base(seg, bus, devfn);

In both cases the unlikely() uses won't have the intended effect, from all I
know. They would help as used here only if the compiler managed to fold all
three parts of the ||-expression into a single conditional branch, which I
don't think it would end up doing.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 06:40:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 06:40:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385772.1628170 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsEFS-0001uN-J8; Fri, 07 Aug 2026 06:40:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385772.1628170; Fri, 07 Aug 2026 06:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsEFS-0001uF-EY; Fri, 07 Aug 2026 06:40:06 +0000
Received: by outflank-mailman (input) for mailman id 1385772;
 Fri, 07 Aug 2026 06:40:05 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wsEFR-0001g4-5m
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 06:40:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsEFQ-002pOb-HF
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 08:40:04 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a757dbc-bab6-0a2a0a5309dd-0a2a4508c8e0-8
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 08:40:00 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a757dc0-f659-0a2a45080019-d1558032b01a-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 08:40:00 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4954d29264cso15562365e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 06 Aug 2026 23:40:00 -0700 (PDT)
Received: from ?IPV6:2003:ca:b70d:300d:c60:b520:be19:f863?
 (p200300cab70d300d0c60b520be19f863.dip0.t-ipconnect.de.
 [2003:ca:b70d:300d:c60:b520:be19:f863])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48002206effsm2648301f8f.32.2026.08.06.23.39.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 06 Aug 2026 23:39:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786084800; x=1786689600; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Zpl041G9bgvH6HkJ+ZJLgBdw/y0qwr5ssc4m7Dc70ag=;
        b=JSXapQwAvzEr+zCvkg+nhPdobWfH2z8yDn26/yF1oucTxa4JJB4FST943JdTvkkxqf
         cOVHJAlu+BaYoDwZYeOPIskwWHfwvob6+QGWZg2cn/75z7NAKtUI8KQqZ69sP9iOXEZr
         WjAWuZEw47Bip+yNzUSokwJXyKu/c/S+/4av4l2XKjwVfjyOYMlwTUCUo6zViTI/2FOP
         KJwMCXm+NMgLmI5Tdv+lzccZmLMrW0TWr5GbWuXWxoHFLzOg5jAH/yd6vtNJhJZ1TokX
         1c9LPipJN7N1gjHQsGnzoyQws18kuDryRWIJElp5A8H4Qf33rAdrgTKTgCT4H2Oz0DUf
         GUPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786084800; x=1786689600;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Zpl041G9bgvH6HkJ+ZJLgBdw/y0qwr5ssc4m7Dc70ag=;
        b=OODCyslZq/pNhEptAOxmSx2Nk/UXSp/IZQnlm877sMqZOhsDSejgwTYHnNiLIOEnzs
         yQEqk2Z6F6wXmDtaEXu/B1AH2zlt7p1ieLm8TBa/IAKGVORA00LxHNqTIn5OVr14PzW6
         8stV1eVf+ypHPRY6P73pWP5QEf7h62Ilo6HKTaZOLRFbxKEmpCCt/rDwq+UdD6eX6w5z
         SpxdC2Bgrs3PBEcBPWEsAGw+3UgjVbJRmhXNh/5HllTOd2Om16RTfpwk3qY7StaWBFyt
         8zzYplzdI7RzwXxWpfG0KNh8pKWOojKaNUkTU5WYZIv3+dXtlQn6vvUai5618PWu2vPR
         w6AQ==
X-Forwarded-Encrypted: i=1; AHgh+RqKVCoOw5v/sp+t6oD1bEAHyncz7n8E0WH4gAUKAEynaikXjols3+nO8VGfsFbmPtsc7GdJACgUrtE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyy874pry3Ga4Ci7lVw6fSxWEinokM7QINzuyJgV/Qy8QCXM1j+
	Ld7qvSI8p34BgRh3jx1fTkMtXxUTCo8Z7/mQ5IsS45RYF04Ypva470fC5CGYxcv43w==
X-Gm-Gg: AR+sD10ixeQLUe1SsAgT7LR5ICDMAuTSolgvJbVM7JNkXv1lat4B7xV328xfPsKcoe1
	VEr+y0Sj6Su5tYxjlSQRGFWcJ9NBf/n+s7SJQXszXgfeWgqXlKasHBtFb2kLjT9tq1UaBFL92vU
	1KhNFoqOu8rHJHfAYapOagM8gd0BSK93Tue8IseaX9GSv6fpw++2hxgVmblyQ8wpUx9r1RSNUnG
	euU0sAgNd71fThCx1jBy8IZrIyZUL1RBQeDdlKAm0Y96AjrHLeBWxd71T8mGVVnAdbJK/bIYViQ
	Q0/pv6cen1V9xVBvW1kQuLffjMQDa8YqGhLcxFU9hohd6Yj4CrJLpRtUAnP55vkAVe0w7nzdVrc
	zOAsXZKZyneiJiqbMtUdaI9T2qb+AK6JSBacLbmd+2kED8f04XULuPluLvP7hcoskoWC1P/SIv8
	t6Ze37J9cCMS+KU41lRvH9SlUvjWj4gvvHGBRu0jDmGbBn4nfKy5Ri4X+Ew1rLFYtWMoKCpEc5I
	qyJvgGPY0kKRj3DT0/buG0g8yDnFog2SixsfQrGLkPpBX/pRCR+SfYLgS/3fsVs3rMi3OnLzynL
	E+gynpTah4IaM8egViw=
X-Received: by 2002:a05:600c:5246:b0:495:52dc:73a9 with SMTP id 5b1f17b1804b1-4994e7ba79dmr240349585e9.11.1786084799851;
        Thu, 06 Aug 2026 23:39:59 -0700 (PDT)
Message-ID: <62a2d0ec-648c-4b2b-b456-077d3967771f@suse.com>
Date: Fri, 7 Aug 2026 08:39:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/vpci: allow unaligned accesses by the hardware
 domain
To: Roger Pau Monne <roger@xenproject.org>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 Stewart Hildebrand <stewart.hildebrand@amd.com>,
 Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-3-roger@xenproject.org>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260806152619.23881-3-roger@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1786084800-CE34587B-00B02BB7/0/0
X-purgate-type: clean
X-purgate-size: 1115

On 06.08.2026 17:26, Roger Pau Monne wrote:
> It's possible for domains to generate unaligned PCI config space accesses
> when using ECAM, and hence vPCI should support those at least for the
> hardware domain.  Such unaligned accesses to the PCI config space have been
> reported to come from ACPI logic.
> 
> Relax the checking in vpci_access_allowed() to allow such accesses for the
> hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
> fulfill them using MMCFG.
> 
> MMCFG regions are identity exposed to the hardware domain, and hence such
> unaligned accesses can only come as a result of the host having MMCFG in the
> first place, as otherwise MMCFG won't be exposed to the hardware domain
> either.
> 
> Note that vpci_ecam_{read,write}() already refuse accesses that cross a
> device boundary unconditionally.
> 
> Reported-by: Jason Andryuk <jason.andryuk@amd.com>
> Signed-off-by: Roger Pau Monné <roger@xenproject.org>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Albeit without the intent to override possible remaining objections by Andrew.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 06:59:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 06:59:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385781.1628178 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsEXz-0005Cn-1d; Fri, 07 Aug 2026 06:59:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385781.1628178; Fri, 07 Aug 2026 06:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsEXy-0005Cg-V8; Fri, 07 Aug 2026 06:59:14 +0000
Received: by outflank-mailman (input) for mailman id 1385781;
 Fri, 07 Aug 2026 06:59:14 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <agordeev@linux.ibm.com>) id 1wsEXx-0005Ca-T6
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 06:59:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsEXx-00A4qv-9T
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 08:59:13 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a758240-2eae-0a2a0a5409dd-0a2a4509baf2-2
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 08:59:13 +0200
Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a75823f-be1a-0a2a45090019-94a39e05d40c-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 08:59:12 +0200
Received: from pps.filterd (m0360072.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6770Huoo016275; Fri, 7 Aug 2026 06:58:32 GMT
Received: from ppma12.dal12v.mail.ibm.com
 (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fvy00am7a-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 07 Aug 2026 06:58:32 +0000 (GMT)
Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1])
 by ppma12.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 6776uLDe003221;
 Fri, 7 Aug 2026 06:58:31 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4fsu4qxspg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 07 Aug 2026 06:58:31 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com
 [10.20.54.101])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 6776wSir33882500
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 7 Aug 2026 06:58:29 GMT
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id D3B0620040;
 Fri,  7 Aug 2026 06:58:28 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 4351E20043;
 Fri,  7 Aug 2026 06:58:26 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.111.55.180])
 by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri,  7 Aug 2026 06:58:26 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=Ra4H8CAbtiN9wPr1aKFBAag6HNf0qB
	uveAYY5O5upyA=; b=b6abVgzghGiyJP2Wlz0QxQ4Xlm4EEGD9Kpi/bbrlqUSFBE
	peaClBZE7a6uUDxpMzlqxLdBYmzJ2Zv0Gov1Z/ABs95zQALrNBxETA0/pEucil/j
	W+YyJwlwpe3OK1MAOCII7fcp3YeD9G589urjh/7H6praJpDu3PDyifCYlbxg55Wq
	kegIhHrXFaKgEStmSWQn7LYsur2nUZn/xPNaUh2EUQxX/E75LETTqXwjtCkcIvTM
	6z2V+hipWhFW5E/1SdFcNJm3hHGg12nD12POK8woGUy/Cd3cVuoSGV0jyJiT1nQe
	XgoPgNhStcc1pjBG2Dfbs0hQJW5cw8oy/wETB5bQ==
Date: Fri, 7 Aug 2026 08:58:24 +0200
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Tvrtko Ursulin <tursulin@ursulin.net>,
        David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
        Dimitri Sivanich <dimitri.sivanich@hpe.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
        Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Muchun Song <muchun.song@linux.dev>,
        Oscar Salvador <osalvador@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Liam R. Howlett" <liam@infradead.org>,
        Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
        Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        David Hildenbrand <david@kernel.org>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
        Uladzislau Rezki <urezki@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Eduard Zingerman <eddyz87@gmail.com>,
        Kumar Kartikeya Dwivedi <memxor@gmail.com>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>,
        Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>,
        Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
        Christoph Lameter <cl@gentwo.org>, Mike Rapoport <rppt@kernel.org>,
        Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, pfalcato@suse.de,
        ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
        linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
        linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
        linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 6/9] mm: convert PTE table entry to pte
Message-ID: <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-7-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260806083926.1807279-7-usama.anjum@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-Spam-Info: AW1haW4tMjYwODA3MDA0OSBTYWx0ZWRfX3Npn1dSDlp+R
 fqhR9MpXZOAAKnyVJ8e3VxdJ3uPpsfM7vsZzpddpvCei+hGCUgHlBFVERXxX+W23gcpS04A1TAu
 ZsTRXf6ZMD17BVZmsTCM0lUCa3PumjU=
X-Authority-Analysis: v=2.4 cv=VPTtWdPX c=1 sm=1 tr=0 ts=6a758218 cx=c_pps
 a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17
 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=VwQbUJbxAAAA:8
 a=7CQSdrXTAAAA:8 a=VnNF1IyMAAAA:8 a=MkxDnzPc83ckttyupOUA:9 a=CjuIK1q_8ugA:10
 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Proofpoint-ORIG-GUID: 9g22-5Yiq-VIyR9utDe_g8M8U8wsuEOd
X-Proofpoint-GUID: 9g22-5Yiq-VIyR9utDe_g8M8U8wsuEOd
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODA3MDA0OSBTYWx0ZWRfX4qeGdjjX3Iob
 oR2d/W90tNYt47jYoawp2wnB7y1FcZkNxxg7/PT57hDZR5feFluugIlRZ22mBQ/td/U5spNK5Sw
 r8fBBZDJMOMHDyBDHn28hS5vFD1IBzJcw9uh6xxZ9XoecZCsQnhJUSSf9noMzRB2RMvDZxhPIkf
 XMKQ1X4w4JsUHL/vsYXt9nxlaz1I/q7ljQgCtXwMvAVt1kijbs35mMQ7c76oGi39I1XSIpxXjmb
 kIMcLde1EyTpmQmaPbN+E3LbUk4M/lkkgjjjvsZIBgTXWy3e0GMD7NaUrStoYwo4ESb8Z4Wsdqh
 +581CUAUBwBVUa2TokmdsZzGbrL67tdrfft71SfQsy0ZlWFNR+iL1PR2Oez6zshpb+e7rynA9dG
 f8FbSxO38FmGhTq0nvrdQcjHK2fKXR2vKx64CE0UHGLhgbh7cUWWpBSkiNUoiKjHZV0BphvCO4H
 jlupay2/A2mIbK8uZUQ==
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-07_01,2026-08-06_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 lowpriorityscore=0 malwarescore=0 bulkscore=0 spamscore=0 clxscore=1015
 priorityscore=1501 phishscore=0 impostorscore=0 adultscore=0 suspectscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608070049
X-purgate-ID: tlsNG-bad1c0/1786085953-BC6CA034-5FC34A1E/0/0
X-purgate-type: clean
X-purgate-size: 1822

On Thu, Aug 06, 2026 at 09:38:44AM +0100, Muhammad Usama Anjum wrote:
> The non-MMU stub receives hw_pte_t but returns a logical pte_t
> value. Convert the stored entry through __pte_from_hw() before
> returning.
> 
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> ---
>  include/linux/hugetlb.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index bc0b9c65aa1d0..9e8b391aa4bc9 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>  #ifdef CONFIG_MMU
>  	return ptep_get(ptep);
>  #else
> -	return *ptep;
> +	return __pte_from_hw(*ptep);

But this is a direct dereferencing, which breaks the whole point, isn't it?

What about introducing something like pte_t ptep_get_sw(hw_pte_t *ptep)
to be used in exactly situations like this? With that the semantics of
hw_pte_t pointers becomes straightforward and closes the still ongoing
"storage vs lifetime" discussion:

hw_pte_t*     points to HW-formatted page table entries

ptep_get()    is used to obtain HW-linked/attached entries, and may wire
              extra code like [1] or [2]

ptep_get_sw() is used to obtain HW-unlinked/unattached entries and in
              most cases is just a direct dereference

The caller should always know whether the entry is attached or not, so
confusions like [3] are avoided.

1. https://lore.kernel.org/linux-mm/20260526-kpkeys-v8-21-eaaacdacc67c@arm.com/
2. https://lore.kernel.org/linux-s390/650903a4-0dd9-4e6b-9d4b-3c32c5657236-agordeev@linux.ibm.com/
3. https://lore.kernel.org/linux-s390/b44e071d-7c9d-4e7e-a84d-4af3499a5a05@arm.com/

>  #endif
>  }
>  
> -- 
> 2.47.3
> 


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 07:10:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 07:10:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385791.1628186 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsEiN-0007oo-1a; Fri, 07 Aug 2026 07:09:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385791.1628186; Fri, 07 Aug 2026 07:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsEiM-0007oh-V2; Fri, 07 Aug 2026 07:09:58 +0000
Received: by outflank-mailman (input) for mailman id 1385791;
 Fri, 07 Aug 2026 07:09:57 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <agordeev@linux.ibm.com>) id 1wsEiK-0007ob-VU
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 07:09:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsEiH-00604c-VG
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 09:09:53 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a7584b8-2eae-0a2a0a5409dd-0a2a450cdfc0-10
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 09:09:53 +0200
Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a7584c0-f479-0a2a450c0019-94a39e059bbc-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 09:09:53 +0200
Received: from pps.filterd (m0353725.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6770JZQv4064146; Fri, 7 Aug 2026 07:09:19 GMT
Received: from ppma23.wdc07v.mail.ibm.com
 (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fvy02anmy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 07 Aug 2026 07:09:18 +0000 (GMT)
Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma23.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 6776uIAD024920;
 Fri, 7 Aug 2026 07:09:17 GMT
Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225])
 by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4fsvmhpmkb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Fri, 07 Aug 2026 07:09:17 +0000 (GMT)
Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com
 [10.20.54.102])
 by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 67779F7T51315084
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 7 Aug 2026 07:09:15 GMT
Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 668A020040;
 Fri,  7 Aug 2026 07:09:15 +0000 (GMT)
Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id EA50320043;
 Fri,  7 Aug 2026 07:09:12 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.111.55.180])
 by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Fri,  7 Aug 2026 07:09:12 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=jpeOcxycXBTAlw8xEd8qyVhgpwcjWF
	NB4soWtck85Pw=; b=Qh6BCzQcqD/AGOqi1hTQHgQVz6HuWuBJB87Gbu8R2QRIrL
	ftEfzBmybSkNntrd41XE524cbuEjupU7byCqaB7YxW9kBgydkUCxBhrhTSiwT6H+
	U4OKIllzATyLLGfNArjEOqj0akgLZ0asqOkSM0XKJyYYoIst8JvDseeB2sH706u4
	hhs9ueI6JSC+Ld/f6qPFOuLXDpab+v18Jf4LeEQIr4j5+MFCFi1kjnwg8/MvRqx/
	KhT+u3vzeF7qrRG7dH6ram2Pu9RQGcAByOzaawNWn2aii58OGSRM1hM7xmzHRjNe
	Si5vdvDt7lOVvC8K31hkxayAWljo7JjlQf3ZTeQg==
Date: Fri, 7 Aug 2026 09:09:11 +0200
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Tvrtko Ursulin <tursulin@ursulin.net>,
        David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
        Dimitri Sivanich <dimitri.sivanich@hpe.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
        Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Muchun Song <muchun.song@linux.dev>,
        Oscar Salvador <osalvador@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Liam R. Howlett" <liam@infradead.org>,
        Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
        Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        David Hildenbrand <david@kernel.org>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
        Uladzislau Rezki <urezki@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Eduard Zingerman <eddyz87@gmail.com>,
        Kumar Kartikeya Dwivedi <memxor@gmail.com>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>,
        Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>,
        Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
        Christoph Lameter <cl@gentwo.org>, Mike Rapoport <rppt@kernel.org>,
        Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, pfalcato@suse.de,
        ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
        linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
        linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
        linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
Message-ID: <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-2-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260806083926.1807279-2-usama.anjum@arm.com>
X-TM-AS-GCONF: 00
X-Authority-Analysis: v=2.4 cv=G6ws1dk5 c=1 sm=1 tr=0 ts=6a75849e cx=c_pps
 a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17
 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=V8glGbnc2Ofi9Qvn3v5h:22 a=7CQSdrXTAAAA:8
 a=knT6YJskkHJV9nTHl7IA:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODA3MDA0OSBTYWx0ZWRfX0nP+lx57+9VF
 1gmEHMdPT9FDdcpiQyi8SmdcwszvdSJS7mABzCaLeNrHd5Sn8+sTGSPk7wgKar3hoAN1E4B/pVx
 bnXvboS9h3/hfmNoqiGrVCRZoMjtdCQHGGcTi/BUQBFwhU3T8reyBMtbDszvLlwmh+wtmaSZLqp
 yvHKwixzlq6G3K0WuaMTKb0rV/vx4p/+UD+c1HQ1XyaQGUDlAtP+qGdAxuohRKj+obB6JSz4pJf
 zR2/7yIz+BcCrmWWxRtyEAkQu5yJbla8dkOuZTNT+Te2QfvIou3iP7qEQNN4GRIU2Q5uHMR6b+I
 Dj47k0jZ1vEd4+qsmknTL/rQ5DO0GSFvsjQsVYtZ2xV19zVeKyvXq+fRINOYMQUEmIHFL/MkEMn
 a61cmrTNbkwX+us4u3c+MP3DMEixACEHjWeKrnFUAYotTcrys6EiCMj8gXkAJjhYM+ZfvANLuAs
 LDq51urlTaBYjwemYPw==
X-Proofpoint-ORIG-GUID: 24rCQEgxgE9QBP75I4HmK7CgK28n9dSJ
X-Proofpoint-Spam-Info: AW1haW4tMjYwODA3MDA0OSBTYWx0ZWRfX1i5aYO825ZYa
 TwQN6H3jwP2QZ+OLP/IGdT3C7Slc5GOjV5747KQtgAdatwi/16p60JYaM2efb4DysHgyipihWtH
 8fPlfABrpBSxaw7p4kLOdK2+bYjkzog=
X-Proofpoint-GUID: 24rCQEgxgE9QBP75I4HmK7CgK28n9dSJ
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-07_01,2026-08-06_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 impostorscore=0 spamscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0
 phishscore=0 priorityscore=1501 adultscore=0 bulkscore=0 clxscore=1015
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608070049
X-purgate-ID: tlsNG-d25034/1786086593-030D9A5B-0DAC0A19/0/0
X-purgate-type: clean
X-purgate-size: 3174

On Thu, Aug 06, 2026 at 09:38:39AM +0100, Muhammad Usama Anjum wrote:
> pte_t is used both for logical PTE values and for entries stored in a PTE
> table, so pte_t * does not distinguish a pointer to a copied value from a
> pointer to table storage.
> 
> Introduce hw_pte_t as the generic name for a PTE table element. Define it
> as a macro alias of pte_t by default. When an architecture selects
> ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead.
> This preserves the representation while allowing converted architectures
> to enforce the distinction at compile time.
> 
> Keep the C type definitions behind an __ASSEMBLY__ check because
> architecture assembly sources can include this header indirectly. Include
> asm/page.h so consumers such as linux/vmalloc.h retain the page definitions
> they previously obtained from that header.
> 
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> ---
> Changes since RFC v1:
> - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition.
> - Exclude the C type definitions from assembly sources.
> - Update the description for the new opt-in model.
> ---
>  MAINTAINERS                   |  1 +
>  include/linux/pgtable_types.h | 17 +++++++++++++++++
>  mm/Kconfig                    |  3 +++
>  3 files changed, 21 insertions(+)
>  create mode 100644 include/linux/pgtable_types.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9c8567308a75..7169bea968cf5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16982,6 +16982,7 @@ F:	include/linux/mmu_notifier.h
>  F:	include/linux/pagewalk.h
>  F:	include/linux/pgalloc.h
>  F:	include/linux/pgtable.h
> +F:	include/linux/pgtable_types.h
>  F:	include/linux/ptdump.h
>  F:	include/linux/vmpressure.h
>  F:	include/linux/vmstat.h
> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
> new file mode 100644
> index 0000000000000..70c3edd00a01b
> --- /dev/null
> +++ b/include/linux/pgtable_types.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_PGTABLE_TYPES_H
> +#define _LINUX_PGTABLE_TYPES_H
> +
> +#include <asm/page.h>
> +
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARCH_HAS_HW_PTE_T
> +typedef struct { pte_t __pte; } hw_pte_t;

On s390 it fails to compile once we do typedef hw_pte_t *pgtable_t
in asm/page.h. m68k, powerpc and sparc may also have such problem.

The below declaration helps to resolve it using forward declaration
and without meddling with headers, though I do not like it much:

typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;

> +#else
> +#define hw_pte_t pte_t
> +#endif
> +
> +#endif /* !__ASSEMBLY__ */
> +
> +#endif /* _LINUX_PGTABLE_TYPES_H */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 331daf7fcfab5..31ba9ebf4aafd 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1316,6 +1316,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled"
>  config GUP_GET_PXX_LOW_HIGH
>  	bool
>  
> +config ARCH_HAS_HW_PTE_T
> +	bool
> +
>  config DMAPOOL_TEST
>  	tristate "Enable a module to run time tests on dma_pool"
>  	depends on HAS_DMA
> -- 
> 2.47.3
> 


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 08:01:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 08:01:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385819.1628197 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsFWK-0002Bj-9X; Fri, 07 Aug 2026 08:01:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385819.1628197; Fri, 07 Aug 2026 08:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsFWK-0002Bc-5w; Fri, 07 Aug 2026 08:01:36 +0000
Received: by outflank-mailman (input) for mailman id 1385819;
 Fri, 07 Aug 2026 08:01:35 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wsFWJ-0002BS-BQ
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 08:01:35 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wsFWH-009ZSo-2l;
 Fri, 07 Aug 2026 08:01:33 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wsFWH-006LIO-0i;
 Fri, 07 Aug 2026 08:01:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=jiIZkAdiXaojC9R+XVALoX8ou523o/rMMDXXJG8HhLk=; b=AJ+PSt3VdhGDN7nodq+ohX29Vk
	rJmfvtCMZ6Zgor4Al/IKLlYAZlqDmcUrd7TiDG2S1VBNb9QKk9DUYxUh2iHoqYrSyEGNuseulGmop
	y3/SnZeyO9M3/Lq+9pxhRbs3lGxlA/CI28pak5Di2QZp+1bpfAp8WyJeFmXXEk0TMmYI=;
Date: Fri, 7 Aug 2026 10:01:27 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] x86/pci: prevent cross-device accesses in
 pci_mmcfg_{read,write}()
Message-ID: <anWQ15K8vi3t1sgF@macbook.local>
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-2-roger@xenproject.org>
 <c818745e-6f61-4b32-b7f5-ee5b7ff82981@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c818745e-6f61-4b32-b7f5-ee5b7ff82981@suse.com>

On Fri, Aug 07, 2026 at 08:22:44AM +0200, Jan Beulich wrote:
> On 06.08.2026 17:26, Roger Pau Monne wrote:
> > Introduce a specific check that prevents an accesses from spilling across
> > two devices.
> > 
> > Signed-off-by: Roger Pau Monné <roger@xenproject.org>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> albeit with a remark:
> 
> > --- a/xen/arch/x86/x86_64/mmconfig_64.c
> > +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> > @@ -61,7 +61,8 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
> >      char __iomem *addr;
> >  
> >      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> > -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
> > +    if (unlikely((bus > 255) || (devfn > 255) ||
> > +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE))) {
> >  err:        *value = -1;
> >          return -EINVAL;
> >      }
> > @@ -91,7 +92,8 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
> >      char __iomem *addr;
> >  
> >      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> > -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
> > +    if (unlikely((bus > 255) || (devfn > 255) ||
> > +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE)))
> >          return -EINVAL;
> >  
> >      addr = pci_dev_base(seg, bus, devfn);
> 
> In both cases the unlikely() uses won't have the intended effect, from all I
> know. They would help as used here only if the compiler managed to fold all
> three parts of the ||-expression into a single conditional branch, which I
> don't think it would end up doing.

I don't mind dropping the unlikely() while changing the line.  I tend
to leave those alone if present, even when I'm not sure they are
actually helpful.  The comment ahead of the check is also not very
useful IMO, but I've decided to leave it alone.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 08:08:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 08:08:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385832.1628205 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsFdK-0003RW-V8; Fri, 07 Aug 2026 08:08:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385832.1628205; Fri, 07 Aug 2026 08:08:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsFdK-0003RP-SS; Fri, 07 Aug 2026 08:08:50 +0000
Received: by outflank-mailman (input) for mailman id 1385832;
 Fri, 07 Aug 2026 08:08:49 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Stewart.Hildebrand@amd.com>) id 1wsFdJ-0003Pv-AV
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 08:08:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsFdI-006B0U-B4
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 10:08:48 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a75928f-bab6-0a2a0a5309dd-0a2a4502c0aa-0
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 10:08:47 +0200
Received: from [40.93.198.2]
 (helo=CY7PR03CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a75928d-6ca4-0a2a45020019-285dc6022029-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 10:08:47 +0200
Received: from PH7PR12MB6467.namprd12.prod.outlook.com (2603:10b6:510:1f5::14)
 by SN7PR12MB7346.namprd12.prod.outlook.com (2603:10b6:806:299::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.23; Fri, 7 Aug
 2026 08:08:41 +0000
Received: from PH7PR12MB6467.namprd12.prod.outlook.com
 ([fe80::7b8:36ff:4c76:46de]) by PH7PR12MB6467.namprd12.prod.outlook.com
 ([fe80::7b8:36ff:4c76:46de%6]) with mapi id 15.21.0292.019; Fri, 7 Aug 2026
 08:08:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=woM3NgpM3IidDHJtcHG76LyptG9cHNCLdJe8t4awZ1RimG1eeHx5r7Wcq7J/2E8klYapX2ifihugV9rSbXpZjZE/fv1cy8dD8qp9YSP+QwkkYtNk1eMKqylbEE9twth5I3WLRPmPxIOpcG1Fhzmca2eOexOjKFfoOsdtDZ68ML2lSYViMk0IOljnf2NvCV2B1IUe43PkF7TKot/GyjFtAijRE+TcwkS0YloZxwnj8AXEDQ4LxUDdHcXjMkE05PMtwRSCVyS/nxCpzlh/aTHdordzhJre69rwBAoD6F+6auUvxFXaKE1pTHlA4zZwEcGwaoXZ3xF84oPRFG2zFkn6iQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LuG3C0E+vQjBn+CrawwxKulOSJySFub1hoxtYYsjEb0=;
 b=tmeEmLCdK4kgo4w9zYL00RM5scGa+OqMYTkq/dNk2/41rZUwqf1uPzzErIsg+dfMfOQcafp8MOzd6LWAeh4WzDEnIjkROpqgWwTgbGu7b+edxMfusKh7Fhy8z2s32eMOBTDLhyNujKQSvx40Pd7ewXtNtYnHbkOpZ8JG5as+bcGZWgFac+kyrGJ48UIC9wLY+PO/TD2B6zuSUA0xNoaFcY2L0aO9bVLCtJtNjxCm04XANmzLHw5cL/pQSy+U0rZgWOE4hIS3Qgu8FoxG4QH+B1Iuingss1+RRb+0Ynz0/JndZDiG8B9TThua1ZCfqgLnr/rtA2NSMmP7tobrGQNXPQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LuG3C0E+vQjBn+CrawwxKulOSJySFub1hoxtYYsjEb0=;
 b=cp+IXF3kYg6P4nLaytA9sLwd3wmmwL+lJVXt4h6mYPwNXrB3G0gdOTREQW0LvSDskTwpvRjveIanbyToD8gKrnLt/tmgSeitSdgzDAE0hpZL0LYWsNWIwKSKang8GbuREpjpmZ5Nh/8FyFgHEMPvAGYk+CofZwxeGN7L/wUPoAc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <b162fe11-1a47-4120-9c61-acec2f5bac1a@amd.com>
Date: Fri, 7 Aug 2026 10:08:32 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: split scheduler vtable from struct
 scheduler
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, jbeulich@suse.com, jgross@suse.com,
 gwd@xenproject.org, dfaggioli@suse.com, nathan.studer@dornerworks.com,
 roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org,
 sstabellini@kernel.org, michal.orzel@amd.com, bertrand.marquis@arm.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech,
 tpearson@raptorengineering.com, alistair.francis@wdc.com,
 connojdavis@gmail.com
References: <20260804055327.22119-1-frn1furkan10@gmail.com>
 <20260804055327.22119-2-frn1furkan10@gmail.com>
Content-Language: en-US
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
In-Reply-To: <20260804055327.22119-2-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BL1PR13CA0092.namprd13.prod.outlook.com
 (2603:10b6:208:2b9::7) To PH7PR12MB6467.namprd12.prod.outlook.com
 (2603:10b6:510:1f5::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH7PR12MB6467:EE_|SN7PR12MB7346:EE_
X-MS-Office365-Filtering-Correlation-Id: 5f8b5865-96a7-4389-f84b-08def45b172f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|7416014|6133799003|4143699003|56012099006|11063799006|10067099003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	ey/7PWvsiJCg+mfjTAsMXyDW1YZr70I008K94rLw7DpgmxNLV7lxtLu73uwzbKnOsbPw96/tfTpodFJgKAgma9U5JWKVMWFHPhSU/RCjLifif4EkvzgCYQGp+a54BrKXRKbQb8aEoxcNlsZGvWlB3rZRpqHztjPJey28bTlcBJ2OTnTmo8N5weO79zJ8x/mlKR+NsqIyON8GvYgZYJ9JvW1PaHSWKCeAqTZrDq8owA6jWmkCgbe8P+O9b+oM6ZmvucpzNWC1glN9F6LTT+YJgOEv3hhT6gE6KPYNJ6jsV3CFfoToGQpYFeX29opkhZn9SiizX9pKWHZUpdNPGQgMwHB6FLdqZ70NzqknTkQ/WN9nZcAuH4XfC3m8HMbGJRKbeLSueyCv5ilz5sUGQYSXUXrbsWYmBRpmkrujbbSfh6CgNit1EH1qeKYmoH1JpWR7kfM3D57mZzOA5euRKxJmCSF2tVCNTWLOAO2HaCt7FDo99K86kv3uME+KMYxPC4sVNY6afbTCwMHxFa5rvRM/+oZjMMlnqrlrCBn3irEJ+iAGktbxjR+Fhaica8ctzLppajKKZuWFc3wJ5kjJukQWaHm4yjaCyqsHn/lNROZYMfl4x/4MBsGpJMH/JOuY2aj+roni27li2qjXUT/sbCUM/twTI2SjQFVLpBgSUl/TVa4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB6467.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(7416014)(6133799003)(4143699003)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?RXJQSnAydGwvWk5veXdkMS93cEp5MFlqbHdnZmxPNWJEL3lwL1ZzNDRSR2Ur?=
 =?utf-8?B?dUpDQndzcmp3VXFpQmFlR1B5VFJKYU1aTWdWOCtNTC9SWks1R0ZibkZnTStT?=
 =?utf-8?B?S2hYRlY4RFBBc0NYNElCanhNZGtGb0ZyMXNNVHpOT3Z0RVQ1cU81QWpQdjdk?=
 =?utf-8?B?UzNlcXd0ZDZ4RUhXQTYvallPbmxtTlpxRWk3MVNrdDdqQUVVcXBLWGdEWmEz?=
 =?utf-8?B?UjNSai94dU03WG84dU8wVmMvNVhYa1BuZ2JJa1VpNE1PWjlQWkFEaFFFNTg3?=
 =?utf-8?B?WklJa0V5aGhXd2w1UjN1YUoxSjZsUUtmS2ZVMXZTeUJFTGJZS1B1U2o2TWQ2?=
 =?utf-8?B?LzhkOEdhWHVmczU3d0cxQUhPajJ2SlZzdWFGSGdQVi91ZUowQmhnbDhnU3A2?=
 =?utf-8?B?dzBQSEE3Q0lVdzNmVWtCZTE5QkthTXpEcXRLZkI2WkYvUTd0UlpzZkxJTFpa?=
 =?utf-8?B?YWtETG9jYkJPYU91anJROURxTjJ4Z2pnTWFNTnZGTkNpeGNFYkQ4QXk1Nmd0?=
 =?utf-8?B?Uzd3dXNRSEJ0emlkdnRBZUJpcENjS2UrTWR2OG8wcitCbXZQYjBpVCs0Wk5J?=
 =?utf-8?B?S1N6Y2VrZGFLOUxueXNtaGZEaHd5WmQzSnFOSDlyQWE5Unl1bUlNcFlXRlA3?=
 =?utf-8?B?WFFWelVVbGZZNk1oN3llYkNkMlVLTXZqcW5WUHFwTUJMbHJwdk5zemRzU2wr?=
 =?utf-8?B?SEFmcm1LTytkY2V4L2lSdHF1N3NvRzJCWDNYTThRdERneE55RjFNSEZHMjRj?=
 =?utf-8?B?cXZNYW5yUC9BeGxtaDI1R00vWkxodE52bnJ0dzMwV0xrK21zS0VxQkJpUjRx?=
 =?utf-8?B?VFRqUVU4QjNLY2dUWlN2bmFqdDB2YXFScWowMWt3Tk5LYmU2dC9pQlZXeEt1?=
 =?utf-8?B?ZnRqaGxoRW9LdkVuTmtvTkpRaytUdGRBNVJhZ3JBM3o1R1NIeWtVRWtjanRw?=
 =?utf-8?B?ditPREJpRXZYNGI0OVZ2NlJCU3Y2QjZMbTFJYXNKOXJMR3hmUnl1QmtrbTBT?=
 =?utf-8?B?OWJ2b0lRVUxsNlRWeHpzbjJZUTk2OVcxVS9MZDlQVVpaSVlaZENZRVIrdElw?=
 =?utf-8?B?bDkyU1dsR200V2U0ZFdrNVk3L0h5aVdtQVprQ2ZFdERvYTBjck1zaHVCN3FB?=
 =?utf-8?B?T05DQUFrektEc0thWXBtNWxDVVc4ME9zNkRycXBMWU9jc1lFTFYzanZLeXQv?=
 =?utf-8?B?NStvOVNGb2RuVEtBYS9BVzNCaXdjSE9lUk1Gc2hxZkVRcXAyWlpNVmJxOWMr?=
 =?utf-8?B?SmRLQlp6MHZhTTFPdURJRTBVZVl4WGI2ZDkrd3ZuVjFOZFFxTWNRbkUyU0hw?=
 =?utf-8?B?dE9tNzdsSXVTOHNpeEFuUG9jdWdqL0tOYXIxRE1GQ0xXblZwSVBaTXRkRDI5?=
 =?utf-8?B?U2E0YUg3a04rNUNOTkQzQzgzS0tVYU5TZmVPcU45bkxUdzlDd0dVS3h6V05X?=
 =?utf-8?B?NUlwc2J3clhZNEdGRElpVU5jb1Z2dUc2NE4zbHN3YmwxK2lqRGtPU1huVE1V?=
 =?utf-8?B?SEJYbGJhTEZoWGNHSk9WNW5BcTljODlnYURCOTN2OWdneW9IU3F6NUEwL1My?=
 =?utf-8?B?a2tza2JWQmhPQUIyWU1hMEIyenh6aHg3bUtZcXZjZVdhK0NVNmxSMzgxckph?=
 =?utf-8?B?Rm1FczZVVXdEVWJHNVJYSERKTWpGNlYydkFDNUtwcFNCWFJTN0N5ZFVWOU1z?=
 =?utf-8?B?Q0MyOTJHak1YVzV6QW5hRDNCZzQyUTNuUE4rcXlXRTY3cjVONlFvSCthVFBM?=
 =?utf-8?B?MjRNV0taODQzUGRITnlla0RVaGtlaGRPVWI0cG80eDVHcnlweGlhY1MveUdD?=
 =?utf-8?B?YUorY1ZqTTZTM2RmSGhSWHBYbk1DWDA3cnpIb1ZDSGlPeUo2RUN6V3gzR3My?=
 =?utf-8?B?MUsvVldadlJvZXo1ZjE0amRnUW01MnpTR0Jpd0Nodm1rbEZMVVg5V3g3R2wv?=
 =?utf-8?B?OThCQnpnaUtmbmZTRmc0Q2lGeW5xYnRYbDZIZ2dPZHorSUZFRTA5NFRlaTRk?=
 =?utf-8?B?THVjNmVXM2RRWU9SMXp4V2ZpcXY3a1dzMXBLTU9NWUIxN3NGMTJBMUVUYXZ6?=
 =?utf-8?B?di9seUFyWGt1b0VxWnZGZ1p3dnl2ZEF6WHVpQk1kV2F2L1hGbXpkTmVMNEdN?=
 =?utf-8?B?WmZGTUx4M09MQnBUTDc2ZEZBWHVpZFNYY1NsV0VFQzJaNnFqeWJvbzhVUnFB?=
 =?utf-8?B?UkNqeEZMVk85NEJLVFRMSHpYS3Z2SzVJR2ZjT1RvRXdqaHBXUHRhMkdhUzdJ?=
 =?utf-8?B?ekFLZEJqM1lpMUl5N3UzVXdNemtYZWNZeHR6czFIbGpGUVlZMHJaUVR4SERq?=
 =?utf-8?Q?/wN/3sqvLuQYrjOx3q?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f8b5865-96a7-4389-f84b-08def45b172f
X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB6467.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2026 08:08:40.6399
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1jgvzTlOKLO4TQ1/pJuXJVVWe53JqY+ZXP/HIEUsNpHvcZ1NxMvNKaIoX6/S9SrGXm4GrWqsjUwVX2oaM9zAqw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7346
X-purgate-ID: tlsNG-720697/1786090127-F06A72AC-02582F36/0/0
X-purgate-type: clean
X-purgate-size: 13945

On 8/4/26 07:53, Furkan Caliskan wrote:
> struct scheduler currently serves two purposes: it is the static
> vtable a scheduler backend defines (name, opt_name, sched_id, and
> all its function pointers), and it is also the per-cpupool runtime
> object scheduler_alloc() allocates. Being the same type forces
> scheduler_alloc() to memcpy() the whole vtable into a fresh
> allocation per cpupool, duplicating identical function pointers
> across every cpupool using the same scheduler.
> 
> Split the vtable out into its own type, struct sched_ops, so it
> can be shared by every cpupool using a given scheduler instead of
> copied per cpupool. struct scheduler is left holding only what is
> actually per-instance: a pointer to the shared sched_ops, plus
> sched_data and cpupool. scheduler_alloc() now stores a pointer to
> the matching sched_ops instance instead of copying its fields, and
> every accessor in private.h is updated from s->field to
> s->ops->field to match.
> 
> Every in-tree scheduler backend (credit, credit2, rtds, arinc653,
> null) is converted from struct scheduler to struct sched_ops.
> 
> A handful of call sites elsewhere read a scheduler's name,
> opt_name or sched_id directly and are updated to go through
> ->ops as well.
> 
> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
> ---
>  xen/common/sched/arinc653.c |  9 +---
>  xen/common/sched/core.c     | 52 +++++++++++---------
>  xen/common/sched/cpupool.c  |  7 +--
>  xen/common/sched/credit.c   |  3 +-
>  xen/common/sched/credit2.c  |  3 +-
>  xen/common/sched/null.c     |  3 +-
>  xen/common/sched/private.h  | 98 +++++++++++++++++++------------------
>  xen/common/sched/rt.c       |  3 +-
>  8 files changed, 89 insertions(+), 89 deletions(-)
> 
> diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
> index 32c596a23c..746963806e 100644
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -702,17 +702,10 @@ a653sched_adjust_global(const struct scheduler *ops,
>  }
>  #endif /* CONFIG_SYSCTL */
>  
> -/**
> - * This structure defines our scheduler for Xen.
> - * The entries tell Xen where to find our scheduler-specific
> - * callback functions.
> - * The symbol must be visible to the rest of Xen at link time.
> - */

The removal of the comment about symbol visibility is a definite improvement,
and I'm okay with the overall comment removal. However, next time I'd prefer
this to be mentioned in the commit message.

For now, I don't want to delay this any further, so for ARINC 653:

Acked-by: Stewart Hildebrand <stewart.hildebrand@amd.com>

I will still give some additional remarks below, but I don't consider them
blocking since they are nit/cosmetic and Juergen already gave his R-b.

> -static const struct scheduler sched_arinc653_def = {
> +static const struct sched_ops sched_arinc653_def = {
>      .name           = "ARINC 653 Scheduler",
>      .opt_name       = "arinc653",
>      .sched_id       = XEN_SCHEDULER_ARINC653,
> -    .sched_data     = NULL,
>  
>      .init           = a653sched_init,
>      .deinit         = a653sched_deinit,
> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> index 9ccf5811bf..5cdae0415c 100644
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -87,7 +87,7 @@ DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
>  /* How many urgent vcpus. */
>  DEFINE_PER_CPU(atomic_t, sched_urgent_count);
>  
> -extern const struct scheduler *__start_schedulers_array[], *__end_schedulers_array[];
> +extern const struct sched_ops *__start_schedulers_array[], *__end_schedulers_array[];
>  #define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
>  #define schedulers __start_schedulers_array
>  
> @@ -127,10 +127,9 @@ static void cf_check sched_idle_schedule(
>      unit->next_task = sched_idle_unit(cpu);
>  }
>  
> -static struct scheduler sched_idle_ops = {
> +static struct sched_ops sched_idle_sched_ops = {
>      .name           = "Idle Scheduler",
>      .opt_name       = "idle",
> -    .sched_data     = NULL,
>  
>      .pick_resource  = sched_idle_res_pick,
>      .do_schedule    = sched_idle_schedule,
> @@ -139,6 +138,11 @@ static struct scheduler sched_idle_ops = {
>      .free_udata     = sched_idle_free_udata,
>  };
>  
> +static struct scheduler sched_idle_ops = {
> +    .ops        = &sched_idle_sched_ops,
> +    .sched_data = NULL,
> +};
> +
>  static inline struct vcpu *unit2vcpu_cpu(const struct sched_unit *unit,
>                                           unsigned int cpu)
>  {
> @@ -2081,7 +2085,7 @@ long do_set_timer_op(s_time_t timeout)
>  /* scheduler_id - fetch ID of current scheduler */
>  int scheduler_id(void)
>  {
> -    return operations.sched_id;
> +    return operations.ops->sched_id;
>  }
>  #endif
>  
> @@ -2090,7 +2094,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
>  {
>      long ret;
>  
> -    if ( op->sched_id != dom_scheduler(d)->sched_id )
> +    if ( op->sched_id != dom_scheduler(d)->ops->sched_id )
>          return -EINVAL;
>  
>      switch ( op->cmd )
> @@ -2132,7 +2136,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
>  
>      rcu_read_lock(&sched_res_rculock);
>  
> -    rc = ((op->sched_id == pool->sched->sched_id)
> +    rc = ((op->sched_id == pool->sched->ops->sched_id)
>            ? sched_adjust_cpupool(pool->sched, op) : -EINVAL);
>  
>      rcu_read_unlock(&sched_res_rculock);
> @@ -2299,7 +2303,7 @@ static struct sched_unit *do_schedule(struct sched_unit *prev, s_time_t now,
>      struct sched_unit *next;
>  
>      /* get policy-specific decision on scheduling... */
> -    sched->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
> +    sched->ops->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
>  
>      next = prev->next_task;
>  
> @@ -2989,10 +2993,9 @@ void scheduler_enable(void)
>  }
>  
>  static inline
> -const struct scheduler *__init sched_get_by_name(const char *sched_name)
> +const struct sched_ops *__init sched_ops_get_by_name(const char* sched_name)

Nit: whitespace: const char *sched_name

>  {
>      unsigned int i;
> -

Nit: please retain the newline here

>      for ( i = 0; i < NUM_SCHEDULERS; i++ )
>          if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
>              return schedulers[i];
> @@ -3002,16 +3005,15 @@ const struct scheduler *__init sched_get_by_name(const char *sched_name)
>  
>  int __init sched_get_id_by_name(const char *sched_name)
>  {
> -    const struct scheduler *scheduler = sched_get_by_name(sched_name);
> -
> -    return scheduler ? scheduler->sched_id : -1;
> +    const struct sched_ops *ops = sched_ops_get_by_name(sched_name);

Nit: newline

> +    return ops ? ops->sched_id : -1;
>  }
>  
>  /* Initialise the data structures. */
>  void __init scheduler_init(void)
>  {
>      struct domain *idle_domain;
> -    const struct scheduler *scheduler;
> +    const struct sched_ops *ops;
>      int i;
>  
>      scheduler_enable();
> @@ -3044,21 +3046,23 @@ void __init scheduler_init(void)
>          }
>      }
>  
> -    scheduler = sched_get_by_name(opt_sched);
> -    if ( !scheduler )
> +    ops = sched_ops_get_by_name(opt_sched);
> +    if ( !ops )
>      {
>          printk("Could not find scheduler: %s\n", opt_sched);
> -        scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
> -        BUG_ON(!scheduler);
> -        printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
> +        ops = sched_ops_get_by_name(CONFIG_SCHED_DEFAULT);
> +        BUG_ON(!ops);
> +        printk("Using '%s' (%s)\n", ops->name, ops->opt_name);
>      }
> -    operations = *scheduler;
> +
> +    operations.ops = ops;
>  
>      if ( cpu_schedule_up(0) )
>          BUG();
>      register_cpu_notifier(&cpu_schedule_nfb);
>  
> -    printk("Using scheduler: %s (%s)\n", operations.name, operations.opt_name);
> +    printk("Using scheduler: %s (%s)\n",
> +           operations.ops->name, operations.ops->opt_name);
>      if ( sched_init(&operations) )
>          panic("scheduler returned error on init\n");
>  
> @@ -3411,12 +3415,14 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
>      for ( i = 0; i < NUM_SCHEDULERS; i++ )
>          if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
>              goto found;
> +
>      return ERR_PTR(-ENOENT);
>  
>   found:
> -    if ( (sched = xmalloc(struct scheduler)) == NULL )
> +    if ( (sched = xzalloc(struct scheduler)) == NULL )

The change to xzalloc deserves a mention in the commit message.

>          return ERR_PTR(-ENOMEM);
> -    memcpy(sched, schedulers[i], sizeof(*sched));
> +    sched->ops = schedulers[i];
> +
>      if ( (ret = sched_init(sched)) != 0 )
>      {
>          xfree(sched);
> @@ -3447,7 +3453,7 @@ void schedule_dump(struct cpupool *c)
>      {
>          sched = c->sched;
>          cpus = c->res_valid;
> -        printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
> +        printk("Scheduler: %s (%s)\n", sched->ops->name, sched->ops->opt_name);
>          sched_dump_settings(sched);
>      }
>      else
> diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
> index 081e1053eb..640578201f 100644
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -338,7 +338,8 @@ static struct cpupool *cpupool_create(unsigned int poolid,
>      spin_unlock(&cpupool_lock);
>  
>      debugtrace_printk("Created cpupool %u with scheduler %s (%s)\n",
> -                      c->cpupool_id, c->sched->name, c->sched->opt_name);
> +                      c->cpupool_id, c->sched->ops->name,
> +                      c->sched->ops->opt_name);
>  
>      return c;
>  
> @@ -862,7 +863,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
>          if ( c == NULL )
>              break;
>          op->cpupool_id = c->cpupool_id;
> -        op->sched_id = c->sched->sched_id;
> +        op->sched_id = c->sched->ops->sched_id;
>          op->n_dom = c->n_dom;
>          ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
>          cpupool_put(c);
> @@ -1294,7 +1295,7 @@ struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
>      struct cpupool *pool;
>  
>      if ( sched_id < 0 )
> -        sched_id = scheduler_get_default()->sched_id;
> +        sched_id = scheduler_get_default()->ops->sched_id;
>  
>      pool = cpupool_create(pool_id, sched_id);
>  
> diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
> index 4dde2ede12..8df746bf6b 100644
> --- a/xen/common/sched/credit.c
> +++ b/xen/common/sched/credit.c
> @@ -2277,11 +2277,10 @@ csched_deinit(struct scheduler *ops)
>      }
>  }
>  
> -static const struct scheduler sched_credit_def = {
> +static const struct sched_ops sched_credit_def = {
>      .name           = "SMP Credit Scheduler",
>      .opt_name       = "credit",
>      .sched_id       = XEN_SCHEDULER_CREDIT,
> -    .sched_data     = NULL,
>  
>      .global_init    = csched_global_init,
>  
> diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
> index 95946634d1..4949606881 100644
> --- a/xen/common/sched/credit2.c
> +++ b/xen/common/sched/credit2.c
> @@ -4230,11 +4230,10 @@ csched2_deinit(struct scheduler *ops)
>      xfree(prv);
>  }
>  
> -static const struct scheduler sched_credit2_def = {
> +static const struct sched_ops sched_credit2_def = {
>      .name           = "SMP Credit Scheduler rev2",
>      .opt_name       = "credit2",
>      .sched_id       = XEN_SCHEDULER_CREDIT2,
> -    .sched_data     = NULL,
>  
>      .global_init    = csched2_global_init,
>  
> diff --git a/xen/common/sched/null.c b/xen/common/sched/null.c
> index 952bb47444..b3c6651fb1 100644
> --- a/xen/common/sched/null.c
> +++ b/xen/common/sched/null.c
> @@ -1037,11 +1037,10 @@ static void cf_check null_dump(const struct scheduler *ops)
>      spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
> -static const struct scheduler sched_null_def = {
> +static const struct sched_ops sched_null_def = {
>      .name           = "null Scheduler",
>      .opt_name       = "null",
>      .sched_id       = XEN_SCHEDULER_NULL,
> -    .sched_data     = NULL,
>  
>      .init           = null_init,
>      .deinit         = null_deinit,
> diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
> index d6884550cd..0c5181891c 100644
> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/private.h
> @@ -294,12 +294,10 @@ static inline spinlock_t *pcpu_schedule_trylock(unsigned int cpu)
>      return NULL;
>  }
>  
> -struct scheduler {
> -    const char *name;       /* full name for this scheduler      */
> -    const char *opt_name;   /* option name for this scheduler    */
> -    unsigned int sched_id;  /* ID for this scheduler             */
> -    void *sched_data;       /* global data pointer               */
> -    struct cpupool *cpupool;/* points to this scheduler's pool   */
> +struct sched_ops {
> +    const char *name;       /* full name for this sched_ops      */
> +    const char *opt_name;   /* option name for this sched_ops    */
> +    unsigned int sched_id;  /* ID for this sched_ops             */
>  
>      int          (*global_init)    (void);
>  
> @@ -366,127 +364,133 @@ struct scheduler {
>                                      struct sched_resource *sr);
>  };
>  
> +struct scheduler {
> +    const struct sched_ops *ops; /* shared, read-only dispatch table */
> +    void *sched_data;            /* global data pointer               */

Isn't it a scheduler instance data pointer, not global?


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 09:33:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 09:33:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385875.1628213 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsGwl-0002i6-Ur; Fri, 07 Aug 2026 09:32:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385875.1628213; Fri, 07 Aug 2026 09:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsGwl-0002hz-S9; Fri, 07 Aug 2026 09:32:59 +0000
Received: by outflank-mailman (input) for mailman id 1385875;
 Fri, 07 Aug 2026 09:32:59 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hoepf@cit.tum.de>) id 1wsGwk-0002ht-Li
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 09:32:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsGwk-00AXZx-2W
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 11:32:58 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <hoepf@cit.tum.de>)
 id 6a75a649-bab6-0a2a0a5309dd-0a2a4507b28e-6
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 11:32:57 +0200
Received: from [131.159.0.202] (helo=mailout2.rbg.tum.de)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <hoepf@cit.tum.de>)
 id 6a75a649-b4ea-0a2a45070019-839f00cae863-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 11:32:57 +0200
Received: from mailrelay1n.ito.cit.tum.de (mailrelay.in.tum.de
 [131.159.254.10])
 by mailout2.rbg.tum.de (Postfix) with ESMTPS id E856C4C0285;
 Fri,  7 Aug 2026 11:32:56 +0200 (CEST)
Received: from mail.in.tum.de (vmrbg426.in.tum.de [131.159.0.73])
 by mailrelay1n.ito.cit.tum.de (Postfix) with ESMTPS id 4hGf885Wngz2xTS;
 Fri,  7 Aug 2026 11:32:56 +0200 (CEST)
Received: by mail.in.tum.de (Postfix, from userid 112)
 id BC2E04A04C1; Fri,  7 Aug 2026 11:32:56 +0200 (CEST)
Received: (Authenticated sender: hoepf)
 by mail.in.tum.de (Postfix) with ESMTPSA id 903A74A0425;
 Fri,  7 Aug 2026 11:32:56 +0200 (CEST)
 (Extended-Queue-bit xtech_ja@fff.in.tum.de)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20220209 header.d=cit.tum.de header.i="@cit.tum.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cit.tum.de;
	s=20220209; t=1786095176;
	bh=Z3p8olyxZ32+8cGkN/ra6kddtLV2OiPHtOEbdJxzTvw=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=OVrl0+BRIokrzr4rCeMINBhIvom/UiDN0tOeYeRH4VE675ijh06oyIQHhBrdnadlh
	 /RhojvqJZ7cFaGk9pIaeWiNQ1rz2N+6d8keSh9et9y3gytnofPNjIphXF24seNqvIQ
	 ICyfWJf6gyXY+FVpHDRFZ/H7/UmvlqzQKOrNpVnBiq95D8+WEuhrQHBqnWLPomQL4Q
	 u9mX13Qt22FbdgJ7EBZmTbLF2g74E5W0KhJ/CD6vMqS9hHLGWj5GveDh23+3u47KS6
	 jMUxp1TgNKgNIS53FfYyE2ZtJZswY8EsAjGWizR20aqZ7RdT47cbkV/5PcXKL4/Hbt
	 Fg3+RvFjxNrog==
Date: Fri, 7 Aug 2026 11:32:55 +0200
From: Johann =?utf-8?Q?H=C3=B6pfner?= <hoepf@cit.tum.de>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, 
	Andrew Cooper <andrew.cooper3@citrix.com>, Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] vvmx: Fix uninitialised writeback to vmcs12
Message-ID: <anWa8ExGlrqsoxfN@cit.tum.de>
References: <alfcosYs35pOCslN@cit.tum.de>
 <af5dfcaa-8da8-4bd2-ac30-24bc65e65a6e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <af5dfcaa-8da8-4bd2-ac30-24bc65e65a6e@suse.com>
X-Virus-Scanned: clamav-milter 1.5.3 at itovm121
X-Virus-Status: Clean
X-purgate-ID: tlsNG-ef75cf/1786095177-348C9AE4-312987C3/0/0
X-purgate-type: clean
X-purgate-size: 2381

nvmx_handle_vmwrite leaves local eight byte variable 'operand'
uninitialised to be written as an out-parameter by decode_vmx_inst. In
cases where the operand to vmwrite is a 32 bit memory operand, the
invokation of  hvm_copy_from_guest_linear leaves the upper half of
*poperandS uninitialised. The resulting eight byte value is consequently
written to the vmcs12 leaking the four uninitialised bytes into guest
physical memory.

Initialize the stack-space passed to decode_vmx_inst to avoid this
issue.

Fixes: 2b2793d3ae44 ("nEPT: handle invept instruction from L1 VMM")
Fixes: d4c5b9db5a85 ("Nested VMX: Emulation of guest VMWRITE")
Fixes: 9ccf55307868 ("nVMX: virutalize VPID capability to nested VMM")
Signed-off-by: Johann Höpfner <hoepf@cit.tum.de>
---

> In any event - why don't you make your proposed change into a proper patch
> (primary piece missing is your S-o-b, and perhaps we also would want a
> suitable Fixes: tag)?

Sorry to have kept you waiting. Here is the formatted patch. I included
the invvpid case still, though I believe only vmwrite remains after the
patch you linked is merged, right?

 xen/arch/x86/hvm/vmx/vvmx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index e4cdfe55c1..68c5df6658 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1968,7 +1968,7 @@ static int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
     struct vmx_inst_decoded decode;
-    unsigned long operand; 
+    unsigned long operand = 0;
     u64 vmcs_encoding;
     enum vmx_insn_errno err;
     int rc;
@@ -2012,7 +2012,7 @@ static int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
 static int nvmx_handle_invept(struct cpu_user_regs *regs)
 {
     struct vmx_inst_decoded decode;
-    unsigned long eptp;
+    unsigned long eptp = 0;
     int ret;
 
     if ( (ret = decode_vmx_inst(regs, &decode, &eptp)) != X86EMUL_OKAY )
@@ -2040,7 +2040,7 @@ static int nvmx_handle_invept(struct cpu_user_regs *regs)
 static int nvmx_handle_invvpid(struct cpu_user_regs *regs)
 {
     struct vmx_inst_decoded decode;
-    unsigned long vpid;
+    unsigned long vpid = 0;
     int ret;
 
     if ( (ret = decode_vmx_inst(regs, &decode, &vpid)) != X86EMUL_OKAY )
-- 
2.53.0


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 09:57:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 09:57:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1385882.1628222 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsHKP-0007Wi-RM; Fri, 07 Aug 2026 09:57:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1385882.1628222; Fri, 07 Aug 2026 09:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsHKP-0007Wb-Oj; Fri, 07 Aug 2026 09:57:25 +0000
Received: by outflank-mailman (input) for mailman id 1385882;
 Fri, 07 Aug 2026 09:36:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <h.bakker@hunenet.nl>) id 1wsH0B-0003Sy-T3
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 09:36:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsH0B-00AYi3-5o
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 11:36:31 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <h.bakker@hunenet.nl>)
 id 6a75a715-8faa-0a2a0a5109dd-0a2a450cde46-48
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 11:36:31 +0200
Received: from [52.101.69.90]
 (helo=AM0PR83CU005.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <h.bakker@hunenet.nl>)
 id 6a75a71e-f479-0a2a450c0019-3465455a8e61-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 11:36:30 +0200
Received: from AM9PR05MB7665.eurprd05.prod.outlook.com (2603:10a6:20b:2cd::14)
 by PAXPR05MB8781.eurprd05.prod.outlook.com (2603:10a6:102:210::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.23; Fri, 7 Aug
 2026 09:36:29 +0000
Received: from AM9PR05MB7665.eurprd05.prod.outlook.com
 ([fe80::48e2:5393:ed5a:3b3e]) by AM9PR05MB7665.eurprd05.prod.outlook.com
 ([fe80::48e2:5393:ed5a:3b3e%4]) with mapi id 15.21.0292.022; Fri, 7 Aug 2026
 09:36:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=hunenet.nl header.i="@hunenet.nl" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q2XrPJ7h6OtVWZFU/dHqXyF3SvS9kmam6c/PexFcI6BMVrr7W4+jHbykO6c4O9YTZ+9xG+C11AFfQ9yH6fYSDbWr+o5mXY2yVRZZged+Sz8DsvyvGLx+U52pJw8sYs+AmRXBJX0slRANtkns9pMmTRv+bC8HY9rT13OnO6XVgjEQpzP17cA2roirEPTgeJVZvqUZHKnV4CqyVbGkzQ2buiA+vzeyVo+9YT2LFmuJYwsTiltF+oEQ77WseHuqZZT+5XKMBL+WDb+bR5fw1U/QnAGXSqQr7Uy4DpEmHTIhW1m281gIYcr8VEPxv092dlhDHK8IoZ+6nx8A438w+h3EfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=e/o1g/Dd7HtR4QqtG9BroF9eIcDTquPeoIVlm/S0voQ=;
 b=J7uGlNUsoHq7CWi9JQHNChp5rLPG3F2in9CbriPFRCniBeahxRveeJqdHQj7O7Ugcjjk9XaUYKeY+V0PfJ9MKsLCxXMsa2V0Hx1wvrId0+ti/60kqRLiBFw39fLVwAGviZ9Sx74B7sIIJ5uKBWbURUCqXtwtBM47+psCSqfpoZdA8BlLjrSxlPsHZiIPOphNlt7adWjcI3PD5o81mhgDMYvcmRDCvzkM43m43my+yEhsghP4OUVm5URugg+sgqxUAA6ITG2hsaXOFzR4Hu/zDv9Jb7sLAgF2iMLt5nN+6Thvfn1TtnNJEJEUrR4UgSHlFrWduFYg8NzcDBWARjWQNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=hunenet.nl; dmarc=pass action=none header.from=hunenet.nl;
 dkim=pass header.d=hunenet.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hunenet.nl;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=e/o1g/Dd7HtR4QqtG9BroF9eIcDTquPeoIVlm/S0voQ=;
 b=giJ9xBI+tX1GKF8WzyjimvmQnaJMXicBYTi+zRCA33s2vZa+BxpS/jUODp13nwo0UCTigt5YRdYJshvCKFW976waxZDH7RYm7mz0DtWTzTlsBE9Ml5qhyp4fXZHzyIjKH1zSkynge0ozy3UiGklPtn1omRIwWjspAzp7weeXLWFEn7uJQ73qOUCbc9ECTpVSzov90JzyHZKvRDfUdyj+CIJyWUVKz18zKnAhqb5MqjVuHQPHWqAvooRlojB7+UUh+bO6WHNfQrDFgktUv1pEchVWNyV+1ObxRvvLsZCDFXOgMue6a6v/H0MyphS3NkZKzb7YJRvM2vsdkVhlbjTOaA==
From: "H. Bakker - Hunenet B.V." <h.bakker@hunenet.nl>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: help Windows PV Drivers and Windows Server 2025
Thread-Topic: help Windows PV Drivers and Windows Server 2025
Thread-Index: Ad0mT/qwzqiDr4LQQ4SZEldj1o5M7Q==
Date: Fri, 7 Aug 2026 09:36:29 +0000
Message-ID:
 <AM9PR05MB7665DF8E88357A35E50C1CA6EDD12@AM9PR05MB7665.eurprd05.prod.outlook.com>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=hunenet.nl;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM9PR05MB7665:EE_|PAXPR05MB8781:EE_
x-ms-office365-filtering-correlation-id: ded94f0f-b30c-4bf4-0146-08def4675bfc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|38070700021|8096899003|10067099003|56012099006;
x-microsoft-antispam-message-info:
 eqqxxP/57iBa4NFu4279BYEiwwnzQrFKO1kJDD/lWWSlwa/GyDO1ILnkt9wGFcmOZpme8iPSlEwW/tVDgIFWL4ZFoAR1PWqqtBvf91sn1LPzbSdd8bIQrVWFAZ2szdhsllg/l2tkN6Rqau71na9VJYBhHcziNHD5Bj13RvVHKhTOBhZSrNuc68h4CJYrrrfclvrS+9olKbXf0JXk4EDf2AnuraO8PiNV5UC81ld5Lb+dCfRR6LGqah2LLSIkfTFZVNi0AuSlIIo2azkMGN/mepyMXCB6Gsu+qHH7d1PROccvXHqwhaOhR+VlvnnqMZ6ErI2NB7dc67RqQcKjKZCphUA3SY7BNvbYTk5kn1E8ZsIIJYYh5Mm1mMmLasOcZcMolK/Max9n5C0rr3Nl73dtkXVS9Goxs00XqkwzdHGSuLT6WSUhIQ5mGt8MKqD4ZrT9Uojc7lMSOc22GoAoaBKE0r4sAMdOYA6374U6wvR6ZDV8UPIZe4BDffBwcIW7gFRW64/a8rFrJ6nDT4tVhj4H+oHK8FfP0L6toK1BYpugejue6n/svpZjU6WyoJ1XJLspC6OPbOI6KJfQDsiQiKDNbsGeQdbSKlGQwfJtr5Y3mFEOwQtpf0PwRHCsmf3vWqjam0m9zpf74JJIEIUWlYC1uGmuNjqONQ0fN1sOceM3++8FHL750F4a2why2f5PcQG/MFOQAFL9bX77ug4QHNAhuQ==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR05MB7665.eurprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(38070700021)(8096899003)(10067099003)(56012099006);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?aTR5RVBZazZsblFUSy9mRkY3T0JmTFNhc2h2RTdqRHFtaEs1dlFFaG05L3dF?=
 =?utf-8?B?R1hwYTZSM25xODYwaGVaV0JDenZYTklWVDdVbFRickJmRCs1d1hDNnFqOGRk?=
 =?utf-8?B?U3pBWUU1eGpKUXQ1d1N4YkYrN0I1WGV5UVRDM240NjJBQWZHOGU0ZWpkZk8w?=
 =?utf-8?B?MTlzRXdHWjZQcko2b0ZJcE9GUGQ4VXdmSW9jeHQ5V09VZk9Rb1NzZURRbno4?=
 =?utf-8?B?SS9keFhESWZJUHZHQ1pIUHRCWnZmQjg1WVJSWm5MQ3Nrd2l1WXQrQ0NZdXNY?=
 =?utf-8?B?Qi9OSWMydWFTS3p4cHE5OWVPdzM3OEpBd3ZjZWQvb0xQcUxwOFArcVA0MXZS?=
 =?utf-8?B?UXlPbjhiSlUrS09GN0VESkNFdTlsUFZXcjh5d1U3UkZWQ2o5VnZET0x3Y0pn?=
 =?utf-8?B?VTdETGFnUVd5M0pYWkZ6dHQyK2wzYjhlZndkczZHaERheWE2L3RyV3htV09N?=
 =?utf-8?B?ZkxCN0FyN0VteFQ2RmcybXhhWGwrcnNQNkJhNTd2eWEvaktRcFpTWXpLYmtY?=
 =?utf-8?B?UWdkVjRaNUVMaldWbzY5amp1NHhVNGllNHV4cm41ODFVR2F3RnhYdHNKbEpE?=
 =?utf-8?B?aWQ2cjZYTmdCZ2EycnVXbUNCaVVCR3o5Ui9kTUhONmg4MGI5US9zREZPY2wr?=
 =?utf-8?B?SVRWenEvSVdqVE54VkNtK2ZkVkhSaDdrR1FZY1ppZ01Jb0h2bHRteHFua3ZR?=
 =?utf-8?B?YUpsR05QZ1E0Q1k5T0orRUkrU0Zjd2kvRGxRQnA4TTMzQnk2cU8za2V4WHM2?=
 =?utf-8?B?dmtHYnFaRWJLVHhSUm0wVmZQUmhxdzRqSVFOb3VLTCtBSVQwK0ZLTzNTanZL?=
 =?utf-8?B?YjNZY0RiK2J1U2tWdGY2MXJhclNLeTZPOHQ3YWpxYUdHbm4vY0cyTzkzeTBj?=
 =?utf-8?B?bEl5SUdjSUlpRTUyZVF2eDNJVnZScU5DcDdNKys3Wk42VmVUQ3ZEblpINFFQ?=
 =?utf-8?B?YjE0VFJiRTBmc0MzaHAxaWZIa29NSTU0aWkyUlFlMjVDTTRnb2p6MzNTZkpp?=
 =?utf-8?B?aVRGSlczRXZDMzBDalNTUVdoVHhuOG9jNE9KUmVEZnZaWTk2ZE9RRndTQjA0?=
 =?utf-8?B?MTZXZGlvUVJKRTRhUDBnNVYxWnc1bFgyY2pqM3Rzc2ZZNndZSVg3d2pKSjF5?=
 =?utf-8?B?Nk92UnhndHIxS3dWWG9QOHUzbmYvd0lRRzJVUzlmL1lMY2JKRUwrSEhCS2I4?=
 =?utf-8?B?TmNiK2NDVFYxMU1KSzBKeEQ1RlQrTW5yWlZaeHI4dmNTMTlrdERLb0JJcUM3?=
 =?utf-8?B?ZXpVMDJFdENjL015YVNVRWg1cEduOGhPSlU3RVVvVElsZFZKUWE0L2FkbUt1?=
 =?utf-8?B?YzRnaDh0aEd0c1NPTVhVZHQxQ0hBckZRV0YvbDZPdWdnZm16TGtTd0Y4eS9q?=
 =?utf-8?B?M2oyWUpGcUEyWDdGNG5EK3BhUFovTGUzL1k1clpiQXJ2ckp4V1FMYmVtZmpU?=
 =?utf-8?B?VTlNaEdKcDA2L0RGTnlnWDBWSmFPWVRzb211WDU2OWFiV2tqVlp1Yks2bDJl?=
 =?utf-8?B?T05TMVE2aWF5dGFRektzSXU5N1FFTFp4d2NtLzc3bTVGdXRPcWdwT3h1ZmlI?=
 =?utf-8?B?QW4vM21rOGF0Y3MvOGhYVzJFelNxS1ZFaDhDR09NNi9LOVBJMXhBQzFXSFJl?=
 =?utf-8?B?VWNHajNXTEFFempnTkxFWnZaWk9vNVFrOGpKR2R3UjRNMmNTOHFtdVd6ZXNV?=
 =?utf-8?B?RGEwQ0NRQ3VXOGFCb2dyaGNXdXE2TnpsZFI3NVBJZjk1bGFBcmJUOU1wNElv?=
 =?utf-8?B?dEVRSVdkT05WcXVWQjB6TDkvazc1bmpyLzJwRFkwbTJyYlZ4b0Q5cmJRM25k?=
 =?utf-8?B?Q2licTdtbnB1R0NRcGZLK1hKeFA3aWxGLy84TjFod0R6YXczOGE0TVBRMk5p?=
 =?utf-8?B?RG1Qc3NxUUt2bUVJV3NzRlkwRTdjS2tvdWExd1gxeUtGbC9nNDJ4K1dUV0Nl?=
 =?utf-8?B?VWpHRTlBa01VbHJkU3lQYjBrWE5lbDBmQkREeVJhbUpXeFhac2lGWEh5dEg3?=
 =?utf-8?B?UGZCSTY2VUk3WTU0bWdVMUNOazI3TWwwMDFhcWxFTENLMjU2T2IwSGY1QXky?=
 =?utf-8?B?TEZEZlkzWjZCRUQxSko2Z3E3NEw2TkxKTWVMU1FqaityWmdSMWZZczZ4bkUz?=
 =?utf-8?B?NmdFbWM3azdZS0pjbUs0LzF3MDVoaVNzdWRZUk54ZTJKeGcxWStwdnhlSmt1?=
 =?utf-8?B?dnU1WHpSczA0d3JHUEI2L1orQTkxZ2JkV1ZPNGxBc3FYOUlCUXdibmI3TERD?=
 =?utf-8?B?dmJQWk9lZlRsOENpRlZBc24yeEV5YlFMd1BCTElkc1ZYREEzUUZHSVdDSm9u?=
 =?utf-8?B?Q01CU3NWNC9wa0RJNEV1YmZvNjFIaXVXcENmQjI1Z0FtWDdtN3ROZz09?=
Content-Type: multipart/alternative;
	boundary="_000_AM9PR05MB7665DF8E88357A35E50C1CA6EDD12AM9PR05MB7665eurp_"
MIME-Version: 1.0
X-OriginatorOrg: hunenet.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM9PR05MB7665.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ded94f0f-b30c-4bf4-0146-08def4675bfc
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2026 09:36:29.4771
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 887aa16f-e08f-4cfb-bc70-8f3f25a72a41
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DrB+QvkdfxGl9uaSjXP0+C762tRRfgEHo598UzvoAuuUvJURFLVAfNUAKAiO4BnM60lsO74YL6fkOox/9DLdnA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR05MB8781
X-purgate-ID: tlsNG-d25034/1786095391-01AC4A5B-CE6FEE1B/0/0
X-purgate-type: clean
X-purgate-size: 4652

--_000_AM9PR05MB7665DF8E88357A35E50C1CA6EDD12AM9PR05MB7665eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBjb25jZXJucyB0aGUgaW5zdGFsbGF0aW9uIG9mIHRoZSBXaW5kb3dzIFBWIERyaXZlcnMg
b24gV2luZG93cyBTZXJ2ZXIgMjAyNS4NCg0KV2hlbiBydW5uaW5nICJkcGluc3QuZXhlIiwgdGhl
IGluc3RhbGxhdGlvbiBmYWlscyB3aXRoIHRoZSBtZXNzYWdlICJJbnN0YWxsIGZhaWxlZCIuDQoN
ClRoZSBhZmZlY3RlZCBkcml2ZXIgdmVyc2lvbiBpczoNCkRyaXZlclZlcj0wNy8xMy8yMDIzLDku
MS4wLjENCg0KSSBhbSBjdXJyZW50bHkgdXNpbmcgYW4gb2xkZXIgdmVyc2lvbiB0aGF0IHdvcmtz
IGNvcnJlY3RseToNCkRyaXZlclZlcj0xMi8wNS8yMDE5LDkuMC4wLjINCktpbmQgcmVnYXJkcywg
SGVucnkgQmFra2VyLg0KDQo=

--_000_AM9PR05MB7665DF8E88357A35E50C1CA6EDD12AM9PR05MB7665eurp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpBcHRvczt9DQovKiBTdHlsZSBEZWZpbml0
aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn
aW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFwdG9zIixzYW5zLXNl
cmlmOw0KCW1zby1saWdhdHVyZXM6c3RhbmRhcmRjb250ZXh0dWFsOw0KCW1zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTO30NCnNwYW4uRS1tYWlsU3RpamwxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJBcHRvcyIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWxpZ2F0dXJlczpub25lO30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0
IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9Ik5MIiBsaW5rPSIjNDY3ODg2IiB2bGluaz0iIzk2
NjA3RCIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBjb25j
ZXJucyB0aGUgaW5zdGFsbGF0aW9uIG9mIHRoZSBXaW5kb3dzIFBWIERyaXZlcnMgb24gV2luZG93
cyBTZXJ2ZXIgMjAyNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoZW4gcnVubmluZyA8Yj4mcXVvdDtk
cGluc3QuZXhlJnF1b3Q7PC9iPiwgdGhlIGluc3RhbGxhdGlvbiBmYWlscyB3aXRoIHRoZSBtZXNz
YWdlDQo8Yj4mcXVvdDtJbnN0YWxsIGZhaWxlZCZxdW90OzwvYj4uPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5UaGUgYWZmZWN0ZWQgZHJpdmVyIHZlcnNpb24gaXM6PGJyPg0KPGI+RHJpdmVyVmVyPTA3LzEz
LzIwMjMsOS4xLjAuMTxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gY3VycmVudGx5IHVzaW5n
IGFuIG9sZGVyIHZlcnNpb24gdGhhdCB3b3JrcyBjb3JyZWN0bHk6PGJyPg0KPGI+RHJpdmVyVmVy
PTEyLzA1LzIwMTksOS4wLjAuMjwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tbGlnYXR1cmVzOm5vbmU7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6TkwiPktpbmQgcmVnYXJkcywgSGVucnkgQmFra2VyLjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1saWdhdHVy
ZXM6bm9uZTttc28tZmFyZWFzdC1sYW5ndWFnZTpOTCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWxp
Z2F0dXJlczpub25lO21zby1mYXJlYXN0LWxhbmd1YWdlOk5MIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_AM9PR05MB7665DF8E88357A35E50C1CA6EDD12AM9PR05MB7665eurp_--


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 14:28:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 14:28:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386041.1628240 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsLYM-0006cI-4w; Fri, 07 Aug 2026 14:28:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386041.1628240; Fri, 07 Aug 2026 14:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsLYM-0006cA-1i; Fri, 07 Aug 2026 14:28:06 +0000
Received: by outflank-mailman (input) for mailman id 1386041;
 Fri, 07 Aug 2026 14:28:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wsLYK-0006aw-Ep
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 14:28:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsLYJ-001Pe9-Rs
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 16:28:03 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a75eb73-e002-0a2a0a5209dd-0a2a450bc9b0-0
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 16:28:03 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a75eb72-b7e8-0a2a450b0019-a0658308cbf4-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 16:28:03 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 9001C44BABEF;
 Fri,  7 Aug 2026 10:26:23 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech
Subject: Re: Re: [PATCH v2] x86/nSVM: Check the L1 IOPM_BASE and MSRPM_BASE
Date: Fri,  7 Aug 2026 15:24:44 +0100
Message-ID: <20260807142444.2510849-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <ff01adce-5807-4fda-becc-3290ad6deafc@suse.com>
References: <ff01adce-5807-4fda-becc-3290ad6deafc@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786112883-19CC79EA-F6BB306F/0/0
X-purgate-type: clean
X-purgate-size: 2182

On 05.08.2026 10:36, Jan Beulich wrote:
>On 29.07.2026 16:38, Abdelkareem Abdelsaamad wrote:
>> @@ -294,6 +296,24 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>>      enum hvm_translation_result ret;
>>      unsigned long *ns_viomap;
>>      bool ioport_80 = true, ioport_ed = true;
>> +    gfn_t ns_iopm_end =
>> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), (IOPM_PAGES_COUNT - 1));
>> +    gfn_t ns_msrpm_end =
>> +        gfn_add(gaddr_to_gfn(ns_vmcb->_msrpm_base_pa), (MSRPM_PAGES_COUNT - 1));
>
>Nit: Why the excess parentheses around the 2nd arguments each? Without them
>the 2nd instance also more obviously stays within line length limits.
>
I will address in V3.

>> +    if ( gfn_x(ns_iopm_end) > domain_get_maximum_gpfn(v->domain) )
>
>I don't think using domain_get_maximum_gpfn() is correct here. Imo you want
>to merely check against what the guest is told in CPUID. 
I will switch to using gfn_valid() in V3 to properly align with what is valid
for the guest.
>...Everything else
>ought to be properly covered by hvm_copy_from_guest_phys() /
>hvm_map_guest_frame_ro() already. In fact for the MSR bitmap I thus can't
>see why further checking would be needed. 
Indeed,  I rechecked the call and confirmed that an invalid address should be
caught downstream in __hvm_copy() -> hvm_translate_get_page(). I will drop this
check in V3.
>..And for the I/O bitmap it looks
>to be a matter of better error handling, rather than introducing extra
>checking.
>
I tested with the address (0xffffffffffffffffUL) assigned to the VMCB::IOPM and
this just passes successfully without any error reported because it is all the
time mapped to a valid host address. So, I think an explicit extra check is
required here rather than just better error reporting.

> +    {
> +        gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n",
> +                 __func__, ns_vmcb->_iopm_base_pa);
> +        return 1;

>Why literal 1? Yes, there is another such return in the function, but no, we
>don't want to extend that. Aiui NSVM_ERROR_VVMCB is meant here.
I will change both in V3.

>Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 15:24:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 15:24:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386107.1628250 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsMRJ-0000hY-5X; Fri, 07 Aug 2026 15:24:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386107.1628250; Fri, 07 Aug 2026 15:24:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsMRJ-0000hR-0p; Fri, 07 Aug 2026 15:24:53 +0000
Received: by outflank-mailman (input) for mailman id 1386107;
 Fri, 07 Aug 2026 15:24:52 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wsMRH-0000hJ-S9
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 15:24:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsMRG-004DkZ-BJ
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 17:24:50 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a75f8ba-2eae-0a2a0a5409dd-0a2a4507d61e-10
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 17:24:49 +0200
Received: from [52.101.65.59]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a75f8c0-b4ea-0a2a45070019-3465413b253b-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 17:24:49 +0200
Received: from DU2PR04CA0029.eurprd04.prod.outlook.com (2603:10a6:10:3b::34)
 by VI0PR08MB10800.eurprd08.prod.outlook.com (2603:10a6:800:205::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.23; Fri, 7 Aug
 2026 15:24:43 +0000
Received: from DU2PEPF00028D12.eurprd03.prod.outlook.com
 (2603:10a6:10:3b:cafe::3a) by DU2PR04CA0029.outlook.office365.com
 (2603:10a6:10:3b::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.21 via Frontend Transport; Fri, 7
 Aug 2026 15:24:43 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU2PEPF00028D12.mail.protection.outlook.com (10.167.242.26) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Fri, 7 Aug 2026 15:24:42 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16)
 by DU0PR08MB10360.eurprd08.prod.outlook.com (2603:10a6:10:417::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.23; Fri, 7 Aug
 2026 15:24:04 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0292.018; Fri, 7 Aug 2026
 15:24:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=YgYEf8/SAqc2pFNvqaD4dDMa/gsJUU+5MZOxScmIqgUj/Tx7t4IlrtLsb91lNcg69MR7dVZoeSppBCkkBgQGOqwkJ6OWWJ+MTzZdA5kBb1VsrAvpI2lcKR4S8ceD0HjUcj+ESfu4Zd+1mIbJMlJ0ibLEGcuwKGy8JlCK2FsT3toHWjiGadnfZeBoOXcXciv/bmssMN5WrVhJFvGs2j8vQzPbqaxRjQSaxJiLt+8aMVo0WuXLmER0/KfgBnTJb7H6E9NhxpSG9VS6y01FqG904amkoWg43Gzd4regFez2fl/jNZpv5RUfsY46/OvfjqvHaibmSbVVst2yCnM5oUxUZg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=214jEOHDvbqO65kJp7R9WvTe7aHGn+ywbFPey8CpPng=;
 b=y+TPSW3BkJ1wUWEQ2sdPKNn62KbZXzdE/RRRrao+EOsUTJgTZtUkfUNwGiKVCpF39Swbmbd5wxX4F7TgHkMR/eHuxNXfS60q5y3z2KCSD9V/rFsOQDDkPkOxMtAaMC1vEvORGD77NqqZuZ2t6zVYfxHh0tSrPjjxPy9iwHrAy4mekd47nKe08vlEsLMc2/53MckeG+WHt9Rd9/5SqaDvyL1zYObh9cIOBQysoAOscfpwXLhOEJffH1pZiNbV5UxBhASGtAXqrZpIylWQ3A2qq07ZT5YNmb3jKWs8dOpSPNEgnZPRyVJAFWTYhgQlasMIEbdxCVJtRCfD4iGbYwH77Q==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linux.ibm.com smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=214jEOHDvbqO65kJp7R9WvTe7aHGn+ywbFPey8CpPng=;
 b=enPJXwJauFv1oQ+Zsu+QSANwW3vkwSHO6idG1f9lavXYCMDiQj7zALU9r7ZrSNwB83ddazzAia7berLLBPNVREmY+i8jUOiFiAzFgVdPhUoiSCQgYnEuLgSz9qoiTNaXORSa7/hhnbz2uAkAxi6hltZwGxaaMH2YsrtnaxNGBH4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nyb2Zb/LWU68b4QGwWAhlcQocb72STHW3uhfNyJ/g64lELJLAmSW96qAz/OMx/oWcaZqLK49ey50C0zOyinM7uz2f7t/rswIfJA3on937Xr6rhZb33gq8yhF4bo6zdBOVTLTTmBkHDZqbrhB1LfT98VZ4UuY+vRsvJGn47rpYM2oVFn7z917NcM2U9kmEetzF9c++WTMl6VCBZgLdoLH5eaGhWUVZSpGlwrGUhQRbJUXUyod4ZZbXfyj0kyvcfN7N4KwVdsxEpfT0a5ugq9b0gRmqdJdpiXUKBiRnGKrU20+fpbtbBQlvm3ws17MFXcdqwsLv/8+HoZLqlMT5UlyGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=214jEOHDvbqO65kJp7R9WvTe7aHGn+ywbFPey8CpPng=;
 b=Iq5uLCPRY95NgPG05ec3/v2umI3pqGev6OJlMs7JnoSZa/9RU2leY3JSX/bYvrQkD0I7P1+cm78rMIHmjbqvjBW7B9mXVoMfVYbF+opAu4V+XE2BHctMeSKfr2XeJY44FM3zl1dqPfSUlfEMG+B6CiPQfIIlotdibkE9UBosH1EJPtygjT0yjeDg+eI5L/m71FQd9x8g57J2U6XhfKwPEIWMwIrh1riSh2LF+rAZ7E22DOaKucwUf1CTatrBeX0rJ5Q5DU7hX6WqB6NmLRg7PAqNEZZ6AHGC1dUBwtSis4KZ/YYk69flyBa7kLy0fsZiiWBcyjtBZR0lPz6uPGvmLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=214jEOHDvbqO65kJp7R9WvTe7aHGn+ywbFPey8CpPng=;
 b=enPJXwJauFv1oQ+Zsu+QSANwW3vkwSHO6idG1f9lavXYCMDiQj7zALU9r7ZrSNwB83ddazzAia7berLLBPNVREmY+i8jUOiFiAzFgVdPhUoiSCQgYnEuLgSz9qoiTNaXORSa7/hhnbz2uAkAxi6hltZwGxaaMH2YsrtnaxNGBH4=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <eef14e97-20cd-4b08-ae22-7636af049b09@arm.com>
Date: Fri, 7 Aug 2026 16:24:00 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
To: Alexander Gordeev <agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-2-usama.anjum@arm.com>
 <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0612.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:314::6) To VI1PR08MB3421.eurprd08.prod.outlook.com
 (2603:10a6:803:80::16)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	VI1PR08MB3421:EE_|DU0PR08MB10360:EE_|DU2PEPF00028D12:EE_|VI0PR08MB10800:EE_
X-MS-Office365-Filtering-Correlation-Id: 7b1f1875-57fb-491d-136b-08def4980165
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|7416014|22082099003|18002099003|56012099006|4143699003|11063799006|10067099003|6133799003;
X-Microsoft-Antispam-Message-Info-Original:
 2t3nqJ+jv2XLoMl6etGaV134C/dZQIRkfbXAbpMvG3W60rxh9JNS7vnG7JumwZOuXshH8/Khuk3XFmNjAOvraHt1FiMxY6SDqUc2bwJ7gjYZ8RtOPYKcClF0QM+zYRhnM2CHCrpr7hoXmeUcNK1NloD1WpyVejEgA1J4jgFzdItq9u6OyZXdImufdWj+LEBGS6IBmv+6/BB4ye4g2SKWQIknvPuEDBuj1QJcOVK16BBecyhY/ujuWGSnNHP185oWRvXeO9VonLi2CbWPODWWJ6+GNA1EHlmq0Q4ZqO2p+w3c5VO7/ibcU56cA9Zm1BPAr5gV3dSiIY5gBrrO0GhJM/Nz6RG84n0RW8uE6xU5lIhiU0aD67U5Nv3EgUz3WjaosLO/zSgKYoBUWVByOz+9Priy7ZB1ksCjLvXt3lJinMQPrFeYsVK6CNwe9nME7chQkisUZPHEKJn9+l8p6tsQWo4cFJaBq/z/0EYkPFoVR0A8yv0iaX3Wc+ux7aTJ/42G09Rj3Dead4InmbspUi+Ht3U8qdwytMOXQUE/LL9p10Moqf0AmvqZoPncIsUwaQ4XpIbvzZ39tWHKbpiuDcdyBJ5WqoGT7NG2PDYTvLuVLzk29GuoAKjCGC+s6nyChN0n+dYaspSn0T4UGPXwMasE55ULyoI/4NgyGnNil4b9eEY=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(7416014)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006)(10067099003)(6133799003);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 dlDyhQkPRofMsLRSwwlNt05buGPmBxT0qhTwS66CFq8RqMH9JnrYeuRl/dIwLMTa3S0/tZc6rtzklCAqGaMnZaEqdUOy9ty+kky5eI4h+1Wf1WKIT0YHlFeHr0vRqQZTfCnso0G6QzigOOedxx6gMxysMT0bK0ziCJd0J1RyfKzdTW8odKVbcKEuWC5tBK5BP8pSTpUvb9bqjJt22KWmnNAWz2ZwHUnOCAJKWRrFwk8vXvlbNdJcHpB5C7uykx7jnsyv/KXKYdJZ+mj0wHCvlqXKkXG1OQs27M0t8YC/n8p+GVaGFyr5QH2Su5t2Nu/Vrv2mfXu8Eux58avYedux6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB10360
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D12.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	78010af5-117a-4010-9bc3-08def497e9d7
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|82310400026|35042699022|14060799003|376014|7416014|1800799024|36860700016|4143699003|10067099003|11063799006|56012099006|6133799003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	x2l+m/+TZiN5WDcR3BKopXymxFpy1n/w8zewuFb2y9Ds335w4O4Ipg3KOXg2n4Xh8Z6ZlmT7QUcRkLaff92m3Ne0kmAudKqF1i7KCM0DsFpx3DuUqfjaP7aF7OmXLIxPwJDeNR1W4aFtqQsMzj6mGeLYmKeqqcSPNPzag2ub2GOj2/bK/1pDOYTo1K/k4bk0vhAynOwzYNa1Nx7/1WC7PI3jL/TJiYXFCp8dpLng+J/aNdOXoAm/RLQNmFW4ljg84owYqlCIOCcbCANBBRVgveRdJU0JPGD82Od0h/a0+Oq0aW9pFkmA0o2dCO+bzsekY0s+7XFX1ZHLlI1HQN6ViBp6bPK1ybVXLSu1PwTi4Vv4eNXkBTJx5fk3hzwhU3PHuJhxB8mxgL9ZTTpSgQzsxo0vJKN+HlDTJEuEoUX6pfOPCHlhyvD80zyfKVHQsdUVjHubTkpPRxB7j+LSyo5f9JriQn5T2mpl7uwyUXioFUweqjQAZskVMuoQcyTxNU0O/sqBdp2Ce9+PHxvT6pLO2MVwmDJigEVSUruzu7+RQG81CMOio5AB+p4ZhsqB7FVhLbsM5WPYVMbMbGTGhrHYk4RU/s8FcW61yPwCV/Jr+M0S2432PHauUfoUr4fKduq/SZoY6dd/CSw7MzOR563j+j2GQhVfmsDKgWE1s4d62IKk5MiyhpQkdB08qiAYJIzxAsYqQudlQv3BkGSoxsFW4w==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(35042699022)(14060799003)(376014)(7416014)(1800799024)(36860700016)(4143699003)(10067099003)(11063799006)(56012099006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	g6sLusA9X41u1ejA18zr5/0Hh+oxjNblxuqvfooYrhKJWuytwsqkYM4RBDsVD6JUPG5ejrRcqnr5/e7tppZJbWyjdo7t0o+y6z68tsoif+F1MBaBmgNHyyctH3CIoA/SkECaXcG16VOwlN9BPUQ0jemKU5fquWEAgHzOiZRFYVgG6EPWjni/TQvwedDSSGb8Razw3w014ZbBUH6R3/c0wWm24LvnYzQv+O7tSwf+LD8ovZuboPDpk0K2qUMKcAzXRFN5Agl8K8bfESJXk4tJL+oyf7av+q6WK2Br07wYwX8iCuY6olsVmayuluAaae4jxdx6l7Rfd0Sxs1FZSgFIEBdpvTlmClNis1jG6i1BiVLn1AWIPxbDqedfdPJx2hH9vhU5ko2RaVILr1JHK4cc51ZlbJ7gAPev9zfv7mGajHlpjSLdLi8QeNSS211id+sa
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2026 15:24:42.8031
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b1f1875-57fb-491d-136b-08def4980165
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF00028D12.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10800
X-purgate-ID: tlsNG-ef75cf/1786116289-3C411AE4-3B9B8F8D/0/0
X-purgate-type: clean
X-purgate-size: 3647

On 07/08/2026 8:09 am, Alexander Gordeev wrote:
> On Thu, Aug 06, 2026 at 09:38:39AM +0100, Muhammad Usama Anjum wrote:
>> pte_t is used both for logical PTE values and for entries stored in a PTE
>> table, so pte_t * does not distinguish a pointer to a copied value from a
>> pointer to table storage.
>>
>> Introduce hw_pte_t as the generic name for a PTE table element. Define it
>> as a macro alias of pte_t by default. When an architecture selects
>> ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead.
>> This preserves the representation while allowing converted architectures
>> to enforce the distinction at compile time.
>>
>> Keep the C type definitions behind an __ASSEMBLY__ check because
>> architecture assembly sources can include this header indirectly. Include
>> asm/page.h so consumers such as linux/vmalloc.h retain the page definitions
>> they previously obtained from that header.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
>> ---
>> Changes since RFC v1:
>> - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition.
>> - Exclude the C type definitions from assembly sources.
>> - Update the description for the new opt-in model.
>> ---
>>  MAINTAINERS                   |  1 +
>>  include/linux/pgtable_types.h | 17 +++++++++++++++++
>>  mm/Kconfig                    |  3 +++
>>  3 files changed, 21 insertions(+)
>>  create mode 100644 include/linux/pgtable_types.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e9c8567308a75..7169bea968cf5 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -16982,6 +16982,7 @@ F:	include/linux/mmu_notifier.h
>>  F:	include/linux/pagewalk.h
>>  F:	include/linux/pgalloc.h
>>  F:	include/linux/pgtable.h
>> +F:	include/linux/pgtable_types.h
>>  F:	include/linux/ptdump.h
>>  F:	include/linux/vmpressure.h
>>  F:	include/linux/vmstat.h
>> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
>> new file mode 100644
>> index 0000000000000..70c3edd00a01b
>> --- /dev/null
>> +++ b/include/linux/pgtable_types.h
>> @@ -0,0 +1,17 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _LINUX_PGTABLE_TYPES_H
>> +#define _LINUX_PGTABLE_TYPES_H
>> +
>> +#include <asm/page.h>
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#ifdef CONFIG_ARCH_HAS_HW_PTE_T
>> +typedef struct { pte_t __pte; } hw_pte_t;
> 
> On s390 it fails to compile once we do typedef hw_pte_t *pgtable_t
> in asm/page.h. m68k, powerpc and sparc may also have such problem.
> 
> The below declaration helps to resolve it using forward declaration
> and without meddling with headers, though I do not like it much:
> 
> typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
Thank you for testing it out on s390.

As __hw_pte_t isn't being used yet in this series, would s390 enablement
patches add __hw_pte_t to this definition?

This could have been avoided if each architecture defined its own hw_pte_t.
But for now we are keeping the generic definition of hw_pte_t.

> 
>> +#else
>> +#define hw_pte_t pte_t
>> +#endif
>> +
>> +#endif /* !__ASSEMBLY__ */
>> +
>> +#endif /* _LINUX_PGTABLE_TYPES_H */
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 331daf7fcfab5..31ba9ebf4aafd 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -1316,6 +1316,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled"
>>  config GUP_GET_PXX_LOW_HIGH
>>  	bool
>>  
>> +config ARCH_HAS_HW_PTE_T
>> +	bool
>> +
>>  config DMAPOOL_TEST
>>  	tristate "Enable a module to run time tests on dma_pool"
>>  	depends on HAS_DMA
>> -- 
>> 2.47.3
>>

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Fri Aug 07 16:02:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 16:02:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386132.1628258 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsN1N-0000dC-Pa; Fri, 07 Aug 2026 16:02:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386132.1628258; Fri, 07 Aug 2026 16:02:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsN1N-0000d5-MA; Fri, 07 Aug 2026 16:02:09 +0000
Received: by outflank-mailman (input) for mailman id 1386132;
 Fri, 07 Aug 2026 16:02:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wsN1N-0000cx-3K
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 16:02:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsN1K-007QSw-N5
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 18:02:06 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a760178-e002-0a2a0a5209dd-0a2a450ae87e-14
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:02:06 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a76017d-f2d2-0a2a450a0019-a0658308b224-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:02:06 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 8E8D444BFF9D;
 Fri,  7 Aug 2026 12:00:25 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>
Subject: [PATCH v3] x86/nSVM: Check the L1 IOPM_BASE assigned physical address
Date: Fri,  7 Aug 2026 16:58:43 +0100
Message-ID: <f97fdc50622e4db559ce059091d0ebf2028e2f2e.1786114518.git.abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786118526-506CECFC-4DBDBEBC/0/0
X-purgate-type: clean
X-purgate-size: 4957

The Xen nested virtualization code maps the physical address assigned by the L1
guests, for IOPM_BASE, directly to valid host address without sanity checks.
Add sanity checks to verify the L1 assigned address is a valid guest address.
This check also makes the bahavior compliant with the Hardware handling of the
assigned addresses. The hardware is expected to trigger VMEXIT_INVALID with
IOPM_BASE address greater than or qual to the maximum supported physical
address, see the APM volume #2 (40332—Rev. 4.40—July 2026).

While at it, clean up the code. Remove the unused bool viopm and the
svm_vcpu::ns_oiomap_pa. Change nsvm_vmrun_permissionmap return error from
literal 1 to NSVM_ERROR_VVMCB.

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Changes in V3:
- Switch to using gfn_valid() instead of domain_get_maximum_gpfn() to align
  with what is told to the guest in the CPUID.
- Change nsvm_vmrun_permissionmap return error from literal 1 to 
  NSVM_ERROR_VVMCB.
- Remove parentheses (IOPM_PAGES_COUNT - 1).
Changes in V2:
- Rename IOPM_MAX_PAGES_DIFF and MSRPM_MAX_PAGES_DIFF constants to
  IOPM_PAGES_COUNT and MSRPM_PAGES_COUNT.
- Drop the 2-pages for domain check.
- Change the IOPM and MSRPM boundary checks.
- Use gaddr_to_gfn instead of open-coding >> PAGE_SHIFT.
- Use __func__ instead of hardcoding raw function names.
---
Testing:
 - Using a locally developed XTF nested virt setup, I manually tested VMRUN
   instruction handling with the address value (0xffffffffffffffffUL) assigned
   to VMCB::iopm_base_pa:
   - Without the changes the address is mapped by the Xen code to the address
     0x604b634000 and it completes the execution without any reported errors.
   - With the changes, the VMRUN execution fails and VMEXIT_INVALID is reported
     back in the ns_vmexit.exitcode.
 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2741283982
---
 xen/arch/x86/hvm/svm/nestedsvm.c         | 17 +++++++++++++----
 xen/arch/x86/include/asm/hvm/svm-types.h |  2 +-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index b06124c2c9..e895cf12c4 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -18,6 +18,7 @@
 
 #define NSVM_ERROR_VVMCB        1
 #define NSVM_ERROR_VMENTRY      2
+#define IOPM_PAGES_COUNT        3
 
 int nestedsvm_vmcb_map(struct vcpu *v, uint64_t vmcbaddr)
 {
@@ -282,7 +283,7 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
     return 0;
 }
 
-static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
+static int nsvm_vmrun_permissionmap(struct vcpu *v)
 {
     struct svm_vcpu *arch_svm = &v->arch.hvm.svm;
     struct nestedsvm *svm = &vcpu_nestedsvm(v);
@@ -294,6 +295,15 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
     enum hvm_translation_result ret;
     unsigned long *ns_viomap;
     bool ioport_80 = true, ioport_ed = true;
+    gfn_t ns_iopm_end =
+        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), IOPM_PAGES_COUNT - 1);
+
+    if ( !gfn_valid(v->domain, ns_iopm_end) )
+    {
+        gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n",
+                 __func__, ns_vmcb->_iopm_base_pa);
+        return NSVM_ERROR_VVMCB;
+    }
 
     ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
 
@@ -302,13 +312,12 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
     if ( ret != HVMTRANS_okay )
     {
         gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret);
-        return 1;
+        return NSVM_ERROR_VVMCB;
     }
 
     /* Check l1 guest io permission map and get a shadow one based on
      * if l1 guest intercepts io ports 0x80 and/or 0xED.
      */
-    svm->ns_oiomap_pa = svm->ns_iomap_pa;
     svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
 
     ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT, 0);
@@ -418,7 +427,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
     n2vmcb->_tsc_offset = n1vmcb->_tsc_offset + ns_vmcb->_tsc_offset;
 
     /* Nested IO permission bitmaps */
-    rc = nsvm_vmrun_permissionmap(v, clean.iopm);
+    rc = nsvm_vmrun_permissionmap(v);
     if ( rc )
         return rc;
 
diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h
index 8acadb9dcc..beab9a3af2 100644
--- a/xen/arch/x86/include/asm/hvm/svm-types.h
+++ b/xen/arch/x86/include/asm/hvm/svm-types.h
@@ -51,7 +51,7 @@ struct nestedsvm {
     unsigned long *ns_merged_msrpm;
 
     /* guest physical address of virtual io permission map */
-    paddr_t ns_iomap_pa, ns_oiomap_pa;
+    paddr_t ns_iomap_pa;
     /* Shadow io permission map */
     unsigned long *ns_iomap;
 
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 07 16:08:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 16:08:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386165.1628268 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsN7S-0001hq-I0; Fri, 07 Aug 2026 16:08:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386165.1628268; Fri, 07 Aug 2026 16:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsN7S-0001hj-Dn; Fri, 07 Aug 2026 16:08:26 +0000
Received: by outflank-mailman (input) for mailman id 1386165;
 Fri, 07 Aug 2026 16:08:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wsN7Q-0001hd-DH
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 16:08:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsN7P-001cXz-QF
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 18:08:23 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7602e0-bab6-0a2a0a5309dd-0a2a450cc8de-22
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:08:23 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7602f7-f479-0a2a450c0019-d155dd2aacab-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:08:23 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47f703a9e5dso1901116f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 09:08:23 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-480021e8c5asm7639218f8f.18.2026.08.07.09.08.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 07 Aug 2026 09:08:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786118903; x=1786723703; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=xcaFk3ixeEuYgcoQ8XLn+8G7y+rECFC1WUDOEimqWVw=;
        b=JY7iI8SiBhtmh9V6/DQvfRRLNJZtSHkcWwvRIlPSe/PUOMSq2TYAeAPIo5DFXbZe3e
         yRQu2YhoVOqeFGwDpAqEJ+2KGKXf7PnShta+rvgtuk0DV4ZqUWwl5YtU/tyeMyuTVXw4
         jIseGjiYwEfjN2gDKN1Fv8/+4MQ/42pt2vWnsI7Y86XmhQuZp5AmU17VxTCctV3Q1/xt
         HnwYUymLfp+pFyBoWt6zHJQ5GEgkBSBeupWbXys1AUFmYeza29sjqvrMVx979GMkQVRH
         S6f7u6+w9Ex/HrH77tO+naMJ4GQUCV2pm/D+Q7bD+l4Obxr0eBAVVC3aMFrooNfQw7EI
         e2MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786118903; x=1786723703;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=xcaFk3ixeEuYgcoQ8XLn+8G7y+rECFC1WUDOEimqWVw=;
        b=H8OcBTqCGTOjXZErhxLConT/sOXKG6j+H/Qcz/It2ky7JFW+gJiBVdr3bKD6tr228D
         Yse+fC9Wx/pKmfSLoB6vBzi7NOd5sOGgwIu5DUbUnttJDjLFSnvrsS8Zt53jiNZ9Xmx7
         sHf3eIi8d2XC+2Vu+m/iz9J8TIhlQwI2XPH0hv6oln2ynCkJ2MiokSnx5lBbTvX3im+X
         1QMQDQb84DdSL8mpa9kylPrw/Dij4HdBeDikv6OwiWCinQr3ck6/mZYuHBSxZGoZq/Ng
         0yT3oYVaZuUuLMaKcR1TWr1Rnt4/DYTYiFZoYnhCE0b6vTj9XUpU08OetC8U/NI2dRx4
         Ewgg==
X-Forwarded-Encrypted: i=1; AHgh+RqiS/N5KYWZR/JJaS5KOte/BlKnQtTuX7o3RJPve97BR7bp7niRgPsxiQyLzRa2rKOKX6PRdIbrlXY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzGsl5DKTFD05SScnNnK3JEnxAooCYdl8ZwHK4PxQymyDtgP5HO
	a7KcyYJ0VTVVTp9WwQrDIgqdquotO3xbAggOt/EN2NPJ9dLybiYhbTJ1vFf1aQ==
X-Gm-Gg: AR+sD12NXLxoPxIZGBTIMsuanMKyi8u4fFqZOscbmE4SCaXBKoKDTtjPjuUnym4VVGU
	URQTl/uc1I4S8lUPbFGpLO7VPnU0+P0apzcx04ll0/OichUbnI0hnkXgI0acSOEFEZD/2Wy9N43
	RCbtF2ENWJTCqd1DkUYi8UKemfq1wHpGwm07YvajTUu1bs9Ec2MEjQnCur3ILroJH8YaJ50rZco
	iPi6yn2plj65IzIpVL9u/bkLF6+EI8d+u6dopWD86Dd+iWAj3DFK/B8fqjac5ehSK+WbNh0exwG
	CSP+eZSZo5pQMh9b7jFHOfbxQnbJqWD9cYf1kbgEWoyA7micE560HyArjfJzK7FnldKtOiu4roY
	t2Bw7CO23509PLMhmTvHvR/lpuamDyXCWNCqkiMUSw5eFt+mLW85KwEaax9RzxR022A11ryrbMa
	nH8WXu55eHIYSrUq6DHAH6toFslF2Ze5/q6fLoP78sV5O1FhSUB5wxsmWvuj2d5Oq2HmnR93S5z
	gvaL53kOI18SGoby/j+kn8hvVm8xnqxUquliFJAE5o=
X-Received: by 2002:a05:6000:1787:b0:47f:8802:c182 with SMTP id ffacd0b85a97d-47fec63cdd1mr36686966f8f.29.1786118902822;
        Fri, 07 Aug 2026 09:08:22 -0700 (PDT)
Message-ID: <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
Date: Fri, 7 Aug 2026 18:08:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
Content-Language: en-US
In-Reply-To: <57793423-aadd-4786-90fd-2923925b766d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786118903-52530A5B-98AD61D7/10/73395122804
X-purgate-type: spam
X-purgate-size: 20273



On 8/6/26 4:28 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> 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 <Romain.Caritey@microchip.com>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> ---
>> Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech> # vaplic_mmio_{read,write}
> 
> For this tag to have any meaning, it should move ahead of the --- above;
> the explanations ...
> 
>> The downstream changes related to `vaplic_mmio_{read,write}` were originally
>> in a separate patch (which was reviewed by Baptiste). However, before
>> upstreaming, it was decided to merge them into the current patch.
>> I added `Reviewed-by: Baptiste` in this form for now, but Baptiste will
>> probably review the remaining changes as well.
>> Once that happens, I'll simply move the `Reviewed-by` tag up and
>> remove the `#`.
> 
> ... here rather explain the restriction on the R-b, not its odd placement.
> 
>> ---
>> Changes in v3:
> 
> As this looks to be recurring - please get versioning of your series right.
> The series is supposedly v1, but here you give the impression of it being
> v3. If there really was an earlier v2 posting, why isn't the entire series
> here v3?

It is v3 before before it was a part of another patch series connected 
to dom0less config enablement.

Would it be better to just write in "Change in v3" that it is moved from 
another patch series + link to that patch series? Or it will be enough 
just to drop "Changes in v2 and v1" and just start from v1?

> 
>> --- a/xen/arch/riscv/aplic-priv.h
>> +++ b/xen/arch/riscv/aplic-priv.h
>> @@ -48,4 +48,6 @@ struct aplic_priv {
>>    */
>>   extern unsigned int guest_aplic_num_sources;
>>   
>> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, uint32_t base_val);
> 
> PLease can you, before submitting, self-review your patches? I'm really
> getting tired of having to repeatedly point out basic style issues, like
> the overlong line here.

Sorry for that, I will write an extra checker for such cases to not miss 
them.

> 
>> @@ -38,6 +39,60 @@ static struct intc_info __ro_after_init aplic_info = {
>>       .hw_variant = INTC_APLIC,
>>   };
>>   
>> +static unsigned long aplic_hart_field(unsigned long hartid)
>> +{
>> +    const struct imsic_config *imsic = imsic_get_config();
>> +    unsigned int lhxw = imsic->hart_index_bits;
>> +    unsigned int hhxw = imsic->group_index_bits;
> 
> It extends to the other local variables here, but I'll use these two to
> try to make my point: I'm struggling to associate the names with the
> values they are set to. Likely "hxw" is an abbreviation of hart index
> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
> in "hhxw"? By using hard to grasp names, you make it hard to actually
> understand the subsequent expressions, in particular ...

The names it taken directly from AIA spec:

The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low 
Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart 
Index Width) for determining target addresses for MSIs is described 
later, in Section 4.9.1.

The AIA specification interprets the machine-level hart index as a 
combination of the **group index** (`g`) and the **hart index within the 
group** (`h`), according to the following formulas:

```
(1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
(2) h = machine-level hart index & (2^LHXW − 1)
```

(In our case, the machine-level hart index is equal to `mhartid`, i.e. 
the hart index.)

For systems that use IMSIC groups, the IMSIC address layout is defined 
by the following parameters:

* `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the 
hart number within a group.
* `hhxw` (High Hart Index Width, or *j*): the number of bits used for 
the group number.
* `hhxs` (High Hart Index Shift): the bit offset of the combined 
hart/group index field within the physical address.

To extract the group index, we first shift the address by `hhxs` so that 
the group index bits are aligned, and then apply a mask derived from 
`hhxw` to isolate those bits.

The hardware performs the same operation to extract the hart index from 
the MSI address. However, in our case we already know which hart should 
receive the interrupt (`hartid`), so there is no need to extract the 
hart index from the base address. We only need to recover the group 
index and combine it with `hartid` to construct the value expected by 
the `target` register.

> 
>> +    unsigned int hhxs =
>> +        imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;
>> +    unsigned long tppn =
>> +        imsic->msi[hartid].base_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
>> +    unsigned long group_index =
>> +        (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
>> +        APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
>> +
>> +    return (group_index << lhxw) | hartid;
> 
> ... these last two. As it stands, they may be easier to understand if
> you didn't have the local variables at all, despite them then getting
> textually longer.

With the explanation above, do the variable names make sense?

To be closer to AIA spec I think it would be better to rename 
group_index to g and hart_id to h. Does it make sense to you?

>> +
>> +uint32_t aplic_hw_read_reg(unsigned int offset, uint32_t mask)
>> +{
>> +    unsigned long flags;
>> +    uint32_t val;
>> +
>> +    ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t)));
>> +
>> +    spin_lock_irqsave(&aplic.lock, flags);
>> +    val = readl((volatile void __iomem *)aplic.regs + offset) & mask;
> 
> Wouldn't this applying of a mask better be done in those callers which
> actually need it? It's not the least the asymmetry with ...

Agree, that to be in sync, I will drop mask argument and apply it on 
caller side.

> 
>> +    spin_unlock_irqrestore(&aplic.lock, flags);
>> +
>> +    return val;
>> +}
>> +
>> +void aplic_hw_write_reg(unsigned int offset, uint32_t value)
> 
> ... this which I consider unhelpful.
> 
>> --- a/xen/arch/riscv/include/asm/aplic.h
>> +++ b/xen/arch/riscv/include/asm/aplic.h
>> @@ -28,6 +28,8 @@
>>   #define APLIC_DOMAINCFG_BE      BIT(0, U)
>>   
>>   /* sourcecfg register fields */
>> +#define APLIC_SOURCECFG_D       BIT(10, U)
> 
> As to the comment - this indeed looks to be a field, but ...
> 
>>   #define APLIC_SOURCECFG_SM_INACTIVE     0x0
>>   #define APLIC_SOURCECFG_SM_DETACH       0x1
>>   #define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
> 
> ... these look to be values of some other field which isn't described. Please
> may I (again) ask that definitions are their commentary at the very least not
> misguide readers?

Thanks for pointing this out. You're right, the comment is misleading as 
written. APLIC_SOURCECFG_D is a field, whereas the APLIC_SOURCECFG_SM_* 
definitions are values for the source mode (SM) field, and the comment 
doesn't make that distinction.

I'll update the comments to describe the fields more accurately:

#define APLIC_SOURCECFG_BASE            0x0004
#define APLIC_SOURCECFG_LAST            0x0ffc
/*
  * sourcecfg[] register fields:
  *  - bit 10 (D) selects the layout of the remaining bits;
  *  - D = 1: bits [9:0] hold the Child Index, i.e. the source is delegated
  *           to a child domain (unsupported by Xen);
  *  - D = 0: bits [2:0] hold the source mode SM (WARL).
  */
#define  APLIC_SOURCECFG_D              BIT(10, U)
/* SM field values (0x2 and 0x3 are reserved): */
#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

Does it look better? Probably there is not sense for two extra spaces 
for APLIC_SOURCECFG_SM_*. I want to show by such identation that it is 
values for SM field of APLIC_SOURCECFG.


> 
>> --- a/xen/arch/riscv/include/asm/imsic.h
>> +++ b/xen/arch/riscv/include/asm/imsic.h
>> @@ -40,6 +40,16 @@ struct imsic_config {
>>       /* Base address */
>>       paddr_t base_addr;
>>   
>> +    /*
>> +     * MSI Target Address Scheme
>> +     *
>> +     * XLEN-1                                                12     0
>> +     * |                                                     |     |
>> +     * -------------------------------------------------------------
>> +     * |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
>> +     * -------------------------------------------------------------
>> +     */
> 
> And the xxx-es in here mean what exactly? Don't care? Some other, unrelated
> values? Yet something else?

  The `x` bits denote address bits that are constant across all IMSIC 
interrupt files. They are not used to encode the group, HART, or guest 
index; instead, they correspond to the fixed portion of the IMSIC 
address determined by the platform's memory map.

For example, consider the IMSIC DT binding:

     interrupt-controller@28000000 {
       compatible = "qemu,imsics", "riscv,imsics";
       interrupts-extended = <&cpu1_intc 9>,
                             <&cpu2_intc 9>,
                             <&cpu3_intc 9>,
                             <&cpu4_intc 9>;
       reg = <0x28000000 0x2000>, /* Group0 IMSICs */
             <0x29000000 0x2000>; /* Group1 IMSICs */
       interrupt-controller;
       #interrupt-cells = <0>;
       msi-controller;
       #msi-cells = <0>;
       riscv,num-ids = <127>;
       riscv,group-index-bits = <1>;
       riscv,group-index-shift = <24>;
     };


Here, `hart_index_bits = 2` (4 CPUs) and `guest_index_bits = 0`, so the 
address layout becomes:

31          25 24 23         14 13 12 11          0
+-------------+-+-------------+-----+-------------+
| constant    |G|  constant   |HART |    zeros    |
+-------------+-+-------------+-----+-------------+


I can update the comment to say:
"x denotes bits that are constant across all interrupt file addresses."

or, if you think it's clearer: "x denotes bits whose values are 
platform-defined and common to all interrupt file addresses."

Does it make sense any of suggested options?


> 
>> --- a/xen/arch/riscv/vaplic.c
>> +++ b/xen/arch/riscv/vaplic.c
>> @@ -17,6 +17,7 @@
>>   #include <asm/aia.h>
>>   #include <asm/imsic.h>
>>   #include <asm/intc.h>
>> +#include <asm/mmio.h>
>>   #include <asm/vaplic.h>
>>   
>>   #include "aplic-priv.h"
>> @@ -27,6 +28,256 @@ unsigned int __ro_after_init guest_aplic_num_sources;
>>   
>>   #define FDT_VAPLIC_INT_CELLS 2
>>   
>> +#define AUTH_IRQ_BIT(d, irqn) ( \
>> +    ((irqn) < (d)->arch.vintc->nr_virqs) && \
>> +    test_bit(irqn, (d)->arch.vintc->used_irqs) )
> 
> Nit: Indentation.

I will use the following indentation:

... (((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 allocated_irqs bitmap.  Each word covers 32
>> + * interrupt sources.  For SOURCECFG and TARGET groups the same division also
>> + * 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 inline uint32_t generate_auth_mask(const struct domain *d,
>> +                                          unsigned int word_idx)
>> +{
>> +    unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
>> +
>> +    if ( word_idx >= DIV_ROUND_UP(d->arch.vintc->nr_virqs,
>> +                                  sizeof(uint32_t) * BITS_PER_BYTE) )
>> +    {
>> +        dprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx);
> 
> Is this really meant to stay?

For debug purpose it could be useful, so I prefer to have it with 
changing it to gprintk(XENLOG_DEBUG, ...) to understand which domain is 
trying to access something wrong.

> 
>> +        return 0U;
> 
> The U suffix is mainly (even if only slightly) obfuscating things, I think.

Agree, I will drop U.

> 
>> +    }
>> +
>> +    return (uint32_t)(d->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >>
>> +                      (first_bit % BITS_PER_LONG));
> 
> I don't quite understand the need for the cast.

Functionally it isn't need but it documents that it is expected that 
translation from unsinged long  to uint32_t will happen. I will drop the 
cast.

> 
>> +static int cf_check vaplic_emulate_load(const struct vcpu *v,
> 
> Why the cf_check (also for the store counterpart)?

Missed to drop. Before vaplic_emulate_load() was used to initialize 
vints_ops. It should be dropped here.

> 
>> +static int cf_check vaplic_emulate_store(const struct vcpu *v,
>> +                                         unsigned long addr, uint32_t value)
>> +{
>> +    int rc = -EINVAL;
>> +    const struct domain *d = v->domain;
>> +    unsigned int offset = addr & APLIC_REG_OFFSET_MASK;
>> +
>> +    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 =
>> +            regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK);
>> +
>> +        value &= generate_auth_mask(d, word_idx);
>> +
>> +        break;
>> +    }
>> +
>> +    case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST:
>> +        if ( value & APLIC_SOURCECFG_D )
>> +        {
>> +            rc = -EOPNOTSUPP;
>> +
>> +            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(d, regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) )
>> +            /* Interrupt not enabled, ignore it */
>> +            return 0;
>> +
>> +        if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW )
>> +        {
>> +            gdprintk(XENLOG_ERR,
>> +                     "value(%u) is incorrect for sourcecfg register\n", value);
>> +
>> +            return 0;
>> +        }
>> +
>> +        break;
>> +
>> +    case APLIC_TARGET_BASE ... APLIC_TARGET_LAST:
>> +    {
>> +        struct vcpu *target_vcpu = NULL;
>> +        unsigned int hart_idx = value >> APLIC_TARGET_HART_IDX_SHIFT;
>> +
>> +        /*
>> +         * Look at vaplic_emulate_load() for explanation why
>> +         * APLIC_GENMSI is subtracted.
>> +         */
>> +        if ( !AUTH_IRQ_BIT(d, regoffset_to_word_idx(offset - APLIC_GENMSI)) )
>> +            /* Interrupt not enabled, ignore it */
>> +            return 0;
>> +
>> +        if ( hart_idx < v->domain->max_vcpus )
> 
> You have d as a local variable.
> 
>> +            target_vcpu = v->domain->vcpu[hart_idx];
> 
> Use domain_vcpu()?

It will be better, thanks.

> 
>> +        if ( !target_vcpu )
>> +        {
>> +            dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n");
>> +
>> +            /* Ignore such writings */
>> +            return 0;
>> +        }
>> +
>> +        value = aplic_msi_target_gen(target_vcpu, value);
>> +
>> +        break;
>> +    }
>> +
>> +    case APLIC_SETIPNUM:
>> +    case APLIC_SETIPNUM_LE:
>> +    case APLIC_CLRIPNUM:
>> +    case APLIC_SETIENUM:
>> +    case APLIC_CLRIENUM:
>> +        if ( !value || !AUTH_IRQ_BIT(d, value) )
>> +            return 0;
>> +
>> +        break;
>> +
>> +    case APLIC_DOMAINCFG:
>> +    {
>> +        struct vaplic *vaplic = to_vaplic(v->domain);
>> +
>> +        /*
>> +         * The domaincfg register has this format:
>> +         * bits 31:24 read-only 0x80
>> +         * bit 8      IE
>> +         * bit 7      read-only 0
>> +         * bit 2      DM (WARL)
>> +         * bit 0      BE (WARL)
>> +         *
>> +         * The most interesting bit for us is IE(Interrupt Enable) bit.
>> +         * At the moment, at least, Linux doesn't use domaincfg.IE bit to
>> +         * disable interrupts globally, but if one day someone will use it
>> +         * then extra actions should be done.
>> +         *
>> +         * Only DM (bit 2) and IE (bit 8) are writable here. They are assigned
>> +         * (not OR-ed) so that a write of 0 can also clear them (WARL), and the
>> +         * read-only high byte (0x80) is always kept set on read-back.
>> +         */
>> +        if ( value & ~(APLIC_DOMAINCFG_RO | APLIC_DOMAINCFG_DM |
>> +                       APLIC_DOMAINCFG_IE) )
>> +            printk_once("%s: Ignore writes to non-writable domaincfg bits as "
>> +                        "they are set by aplic during initialization in Xen\n",
>> +                        __func__);
>> +
>> +        vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO |
>> +                                 (value & (APLIC_DOMAINCFG_DM |
>> +                                           APLIC_DOMAINCFG_IE));
>> +
>> +        return 0;
>> +    }
>> +
>> +    default:
>> +        goto fail;
> 
> Instead of this goto, I think you simply want to move the label here.
> That'll also make the function more similar to its load counterpart.

Good point. I am curious how fail label should be aligned:

     default:
  fail:
         gdprintk(XENLOG_WARNING,
                  "Unhandled APLIC write at offset %#x (value %#x)\n", 
offset,
                  value);

         return rc;
     }

or default:
     fail:

?

> 
>> @@ -105,6 +356,50 @@ static const struct vintc_init_ops __initconstrel init_ops = {
>>       .make_domu_dt_node = vaplic_make_domu_dt_node,
>>   };
>>   
>> +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, mmio_info_t *info,
>> +                                               register_t *r)
>> +{
>> +    uint32_t data = 0;
>> +
>> +    if ( info->len != sizeof(uint32_t) ||
>> +         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
>> +    {
>> +        gdprintk(XENLOG_DEBUG,
>> +                 "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n",
>> +                 info->gpa, info->len);
> 
> You have v passed in here, but you'd log current. If passing in v is
> necessary (i.e. here or elsewhere it may be other than current), then you
> need to either ASSERT(v == current) at the top of the funciton or otherwise
> handle v != current correctly.

It makes sense. I will add ASSERT(v == current) here and for 
vaplic_mmio_write().

> 
>> +        return IO_ABORT;
>> +    }
>> +
>> +    if ( vaplic_emulate_load(v, info->gpa, &data) < 0 )
> 
> If all you care about is a boolean result, why not make the function return
> bool?

Agree, bool will be enough for vaplic_emulate_load() and 
vaplic_emulate_save().

Thanks!

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 16:27:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 16:27:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386187.1628276 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsNPJ-00060H-VS; Fri, 07 Aug 2026 16:26:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386187.1628276; Fri, 07 Aug 2026 16:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsNPJ-00060A-SW; Fri, 07 Aug 2026 16:26:53 +0000
Received: by outflank-mailman (input) for mailman id 1386187;
 Fri, 07 Aug 2026 16:26:52 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wsNPI-000604-7i
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 16:26:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsNPH-001esW-9S
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 18:26:51 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7606fd-8faa-0a2a0a5109dd-0a2a45018012-40
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:26:50 +0200
Received: from [52.101.69.58]
 (helo=AM0PR83CU005.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a76074a-5984-0a2a45010019-3465453a316f-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:26:50 +0200
Received: from AS4P192CA0049.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:658::22)
 by PAXPR08MB7442.eurprd08.prod.outlook.com (2603:10a6:102:2b8::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.16; Fri, 7 Aug
 2026 16:26:44 +0000
Received: from AMS0EPF00000199.eurprd05.prod.outlook.com
 (2603:10a6:20b:658:cafe::5) by AS4P192CA0049.outlook.office365.com
 (2603:10a6:20b:658::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.23 via Frontend Transport; Fri, 7
 Aug 2026 16:26:44 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF00000199.mail.protection.outlook.com (10.167.16.245) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Fri, 7 Aug 2026 16:26:44 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16)
 by VI0PR08MB10655.eurprd08.prod.outlook.com (2603:10a6:800:209::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.23; Fri, 7 Aug
 2026 16:26:07 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0292.018; Fri, 7 Aug 2026
 16:26:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=S1XfxwbdoezrGNtcj8UyE3GCZXPXBdAlOWQPBP28V+8tyrszTTGsxfqldiEGqWUtuUE3vGD6hP9N8iWgN/hWSoqJbKvP7dCnk5mClR/jGw+Xd8ULlXemEMgYLQG5a8+SX+zAiRD/IiLlYYyj9WdOPaiYjjvyJLvzn4300I63UoltiCDj8Jg0P5yNqhROTB5cT1IJ66IKetoBSUH9ZlAkDZ0jb1JhqadNZhlcWhQg0uXCf1ZZJUT/3VejedLWxaDFhoB7eXKVxueFE8+BcEVbJjRFeKflCsN6qbZXJGnduh1MfFIEI7/GxeHQ+Rq3Rlf9McLwZh3G/s7I32c5KxrR3g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MS1lmnXLC+3vPC4LjFRguif+C4PkJMlmWukiMTyIh2c=;
 b=QoPWnMGbeaEPY70JHB5FQkhZMhNEsKVxusaXcu3ZHcrzDdOsIH9+aABL25xarJ2p0BlpVUxRf6Rgne1yLcv5zGx6QYZC0BurUyoI26KRLxEWfz7BT1WkTKdGln9XQj+21bbKcTWU5FdswTkyPLbGGfARa3gbWsvHVimPUlPOEt/SW7LYQCODLdiyL+SIffv0U//X6j+iV2CRM+LdaMa6FV/uONol3kF+A/EQq4DM41RU4LgJE6M4FV88hSW9/TUJWGaUuxL5/L7o/ivebYQhF9bO3h+hR2CNByMmIjCJr6HDtFMzZtLfkA/9O71rEd8cKcmANziXxWRrfApO7Lw8Fw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linux.ibm.com smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MS1lmnXLC+3vPC4LjFRguif+C4PkJMlmWukiMTyIh2c=;
 b=LbE4HoBxjfRtlY7c6ZHDXc95qdWRroP7GkPtXzaFqe+eQxYuiOQOAwMBr7zadR4TuTA5v2UTuXmiECUnpZtueKfuejTnnfUkBfLrYjyJgXAvWpK0ohfjKh71EC1IompC0jkrflMssKe0/wRqt9RdzegAqcf5Dc1XBW/fb9/q1tA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FBDF7vggKyg/P39qymfNUnPXNLSQX3uZtATlVOwaLtC8TwntOHJPr284gwOOE6pZfD9pmyFHAa1UmVfQW8bWlKsBhgNU/ouiGX+26VsQpjWXWZ03OJBCOzmApMN/ySTKE8mQDBvgdWMFtoxsru3C01DYlr7vL3iyKVBB5c54bw0QQucf/VJGVkwhwn0z/NmQitzGga1XjI0FH3FYglUvWzdpCvBaLvOiejWwJW7tBPnR8nOSG9qg1A/4DhkmlwKTNOGQjqPvIBUIIUSuFkWtbpulF3P6v2SWp5fzB49KalXQ7i7JhAcvUoHoajLSseZYDQIz+xv6ilzZFCFfYm3ztg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MS1lmnXLC+3vPC4LjFRguif+C4PkJMlmWukiMTyIh2c=;
 b=RvoYgMTkY2CEpoffjFhgvcG6DOqoHwEYbJ3Ie40Y2aRdAowA7ORsQl6ZnFxPWEiRodcf+LQDB5UOCktktQ+uxJAXXkH3XltD1V1wzgI2rtyhQsrVcO8xIqGBAnRZ+pnWcT0zs6U3BkS0mNhhnOV96LiBzjqE7VbRskZWsDvkN+P1KzSRZcbvzKEh42wx0U5sjamKWFkxFTgC6XqVLLTJ//iITABk8mNNNio7hfW87kMwg27jLdrB+/9eJLsIyVTVEgYOvUXJ1zW80G/r81Ak3LDbRkKk/TMVrZf9o1etFK7qrsmJCJNLp2hUG362ZxNhsBXDxRQjMohSfbormJVZnQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MS1lmnXLC+3vPC4LjFRguif+C4PkJMlmWukiMTyIh2c=;
 b=LbE4HoBxjfRtlY7c6ZHDXc95qdWRroP7GkPtXzaFqe+eQxYuiOQOAwMBr7zadR4TuTA5v2UTuXmiECUnpZtueKfuejTnnfUkBfLrYjyJgXAvWpK0ohfjKh71EC1IompC0jkrflMssKe0/wRqt9RdzegAqcf5Dc1XBW/fb9/q1tA=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <5c329236-7761-4e42-a549-b822e43b4358@arm.com>
Date: Fri, 7 Aug 2026 17:26:04 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 6/9] mm: convert PTE table entry to pte
To: Alexander Gordeev <agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-7-usama.anjum@arm.com>
 <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0420.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18b::11) To VI1PR08MB3421.eurprd08.prod.outlook.com
 (2603:10a6:803:80::16)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	VI1PR08MB3421:EE_|VI0PR08MB10655:EE_|AMS0EPF00000199:EE_|PAXPR08MB7442:EE_
X-MS-Office365-Filtering-Correlation-Id: 18b46daa-e409-4390-8a75-08def4a0abaf
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|1800799024|7416014|376014|23010399003|18002099003|22082099003|4143699003|11063799006|56012099006|3023799007|10067099003;
X-Microsoft-Antispam-Message-Info-Original:
 1mEC+1GW7muqv9YRUa+5/AFrrrerVojSEnd0ecaTJkfa3ovLhwzSUtq/5/iXk3EltNs1VIgCRf8Zh7GTAr6czHLzj1LlHiHnMTDT5Dcb24wAlC09Mw+6D5YHPspvL2sx1EVI20obl2sTrjQoXjDCgA7aBVp0HoJDluRDuV7/B58aAjYrXiLYtdilyVB/c4ILJZct9XSAPErba2JDglH3GKJD4ype/UD4mcHzequXHk1JMOE06O16tguwAUEIG0u+MJ8ggTWNqgYTzNOd6MVIq6sd2hHoWdX2Y2qjuTpQTX+YA2OBeZDzPK349/Ui6sl0RztQtbMC3yY/MuAf8RC0UbnnCeYg8DCCD41dNdhUatK+JRo5T3IK1KmdaqJIqc1SsTX08C88FG2Lg8b1iyt7B2jUsYSIVllojrtRN+9N6ntm73XxGeP7W/EKk2HijMVLt/zJ00cBPF+s6ehrAwUuLcXR3bFWdCxqikr9Hu5qgLqNLiBeQyU9LZ3Rn0uE/AjKJr7KxBolhiCVsfoUtLoROh7bFHlrC6EFaGGtVgi1y6ZHnr30Pd2XXuuZe89Ym83TMhdg1ihZmFB2EXbHj6gKjLziMPVkfqXTj4k6Xt+iMxg68NNxRNU+gVap/tVp0ZnjQsNUaocWwqx1SokpwWWnu8VdsKL2mjWzZqYQVxBsrn0=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(23010399003)(18002099003)(22082099003)(4143699003)(11063799006)(56012099006)(3023799007)(10067099003);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 dn/YewereVVzC5A5tIWzHJtVSWhBYpgpDSi5ALQzfsiowfVbPFqVXI1S32+w2Gf3hBalkT4ScA+EB4sUwudcOtIJhjhR9aueBLUTgRnHXPmr0dbhEUDZJ+v2rrucvP3u7iERclCslQl2A5NyoZhvKU3h4jrT3J9OorOozCFUP/qcN/HdbFVtvnLxCOyew+JGCZ6WkqiuZJrWgmbPl2r9U72xSp7bx/EmXd8DnNf3SnfIcujY2BMitEtNTLz7u55xSDP2vPsc11Dyxs/oe8ZFQ05c4AHjsCyEnqkcV8VIhBM96NYmH5IBO7uCDB0P5KyPkh6gWTBXXIEFZ97AzZVXsA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10655
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000199.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	0a4a3d81-f480-4118-d51a-08def4a09582
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|7416014|82310400026|23010399003|376014|35042699022|1800799024|36860700016|13003099007|10067099003|11063799006|56012099006|4143699003|3023799007|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	3ee23sDBvCMpGWS4TDHQCLYyUuSwv+AYpmfNHpcECbYwo+er0pcuW0YBJ/JGlzMVJsYwX+sABSXsOIooXGv1Z0M+CPTlgjlg8l/Ty/wmwVr9lgrVojIjexEIkm6+ajX+jCaGQkEO1zUJo0wXkMoWdebOCQaVpddKqpa301BXJrr6TFCTFHFnP4U3N8xqK/Yw3VDWz/HR+Tmja6qer8yUgdSzdJJOcu3WoyKS89aiOVle25K9alBtrNPHYoQoWKJ06NlFBf751x6aeo652mwomwBFkHSiU2zKXMeAFWuaxSYXq1glMto7hAF/gOGGTL2KsodAfMs/ljrXF2CelpRYmy7dwl871eDCtbhP7HZoQm95AyQDVHiuS6igbUrWVHInoFmIcSSYQ/pKGROsSzIS9uHKiT7mjVo4I+Jt8RhdN6Qu7v9+iowjNrvL73d5s7jF/NcJvL+dVY88XcquKU700NMF0mYZsemFR7s3WLsgCe9H7NzHlwj0UTfVbvv+b/p3fSGye2GK0W+Cf5h6XQwGCOInM1gxaeD2SAmf6gEEMx0eI5VC946Ussig+Y5WXGfBzdXeBSVELZFMUB3Mrj0zZ87rzh8sgxNwXrn0iQFJEUDkZkzpkge9bwfairbgtuVQtzayx75zCTl1VV7FA1Sk9FfxIDz8ceClCSD8heLSBoia02CVnceaJ5LQ/HpxSzWGxbG6EIome9u0k4ClWpNNmw==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(7416014)(82310400026)(23010399003)(376014)(35042699022)(1800799024)(36860700016)(13003099007)(10067099003)(11063799006)(56012099006)(4143699003)(3023799007)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	d+88svJ5Haq6WSE5QYn4CZJyPMiUwhrt6t1V2RHk3Ee1c9prJyx4tb+QtGTj3UbgmutI/PnhCtEHsr35ZeMYJIjsJ1kttUusNFj9C44KxueqFhTUJy1pVRJjR7gJbqZb0XMMkZZBV8qaszUzoOYuG3Fmn74WxXMTHpIniau7xxMzQqqH+IEnWJ+LM/afEF7mm1UuFtpi61Es1j6qU/6DdzZefnT+s7uMDbLXE75755Yr3IgrwazWn4HlBUcwVZSyzmwFVXX+7IB10zw772A9Uc0UPJ5QKASwy6/zQ3PJ05eo7i0EfLOboN8P005OBeG3KiQdN6k/85+GF3+NgIOzozCldvxfEbHC+2lhiRP1hysiIPiJVK+xNnkfisRuPDTC/zUrbgJfQU3UTvywsjWWCl89sfVDR1zg4iJA8cEZxL45be/o2DGrtvgTNcV8TyCA
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2026 16:26:44.4840
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 18b46daa-e409-4390-8a75-08def4a0abaf
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF00000199.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7442
X-purgate-ID: tlsNG-d62444/1786120010-1E07B757-3A9DD1AB/0/0
X-purgate-type: clean
X-purgate-size: 2574

On 07/08/2026 7:58 am, Alexander Gordeev wrote:
> On Thu, Aug 06, 2026 at 09:38:44AM +0100, Muhammad Usama Anjum wrote:
>> The non-MMU stub receives hw_pte_t but returns a logical pte_t
>> value. Convert the stored entry through __pte_from_hw() before
>> returning.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
>> ---
>>  include/linux/hugetlb.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index bc0b9c65aa1d0..9e8b391aa4bc9 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>>  #ifdef CONFIG_MMU
>>  	return ptep_get(ptep);
>>  #else
>> -	return *ptep;
>> +	return __pte_from_hw(*ptep);
> 
> But this is a direct dereferencing, which breaks the whole point, isn't it?
Yes, this is particular line is for non MMU. In this case, CONIFG_ARCH_HAS_HW_PTE
would never be defined. Hence hw_pte_t is just pte_t and direct dereference is
allowed. I'd thought a lot about it; is better to leave direct dereference here
or use some helper. Then used __pte_from_hw() was already being used in generic
ptep_get().

There are only two users of __pte_from_hw() at this time. 

> 
> What about introducing something like pte_t ptep_get_sw(hw_pte_t *ptep)
> to be used in exactly situations like this? With that the semantics of
> hw_pte_t pointers becomes straightforward and closes the still ongoing
> "storage vs lifetime" discussion:
> 
> hw_pte_t*     points to HW-formatted page table entries
> 
> ptep_get()    is used to obtain HW-linked/attached entries, and may wire
>               extra code like [1] or [2]
> 
> ptep_get_sw() is used to obtain HW-unlinked/unattached entries and in
>               most cases is just a direct dereference
ptep_get_sw() or ptep_get_deref() is better name here?

I thought __pte_from_hw() is ugly enough that if someone tries to use it
wrongly, it'll be noticed pretty easily. I'm fine with any other name.

> 
> The caller should always know whether the entry is attached or not, so
> confusions like [3] are avoided.
> 
> 1. https://lore.kernel.org/linux-mm/20260526-kpkeys-v8-21-eaaacdacc67c@arm.com/
> 2. https://lore.kernel.org/linux-s390/650903a4-0dd9-4e6b-9d4b-3c32c5657236-agordeev@linux.ibm.com/
> 3. https://lore.kernel.org/linux-s390/b44e071d-7c9d-4e7e-a84d-4af3499a5a05@arm.com/
> 
>>  #endif
>>  }
>>  
>> -- 
>> 2.47.3
>>

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Fri Aug 07 18:11:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 18:11:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386265.1628285 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsP2K-0001Lh-7P; Fri, 07 Aug 2026 18:11:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386265.1628285; Fri, 07 Aug 2026 18:11:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsP2K-0001La-43; Fri, 07 Aug 2026 18:11:16 +0000
Received: by outflank-mailman (input) for mailman id 1386265;
 Fri, 07 Aug 2026 18:11:15 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wsP2H-0001LU-Mn
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 18:11:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsP2G-004Xa2-K4
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 20:11:12 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a761fb9-e002-0a2a0a5209dd-0a2a4509cb34-2
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 20:11:07 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a761fb5-be1a-0a2a45090019-94a38ff133ca-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 20:11:02 +0200
Received: from pps.filterd (m0367130.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 677GPY6I687294
 for <xen-devel@lists.xenproject.org>; Fri, 7 Aug 2026 18:11:01 GMT
Received: from sa9pr02cu001.outbound.protection.outlook.com
 (mail-southcentralusazon11013000.outbound.protection.outlook.com
 [40.93.196.0])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4fwh9ytarq-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 18:11:01 +0000 (GMT)
Received: from BY1P220CA0026.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::17)
 by DS4PR16MB935079.namprd16.prod.outlook.com (2603:10b6:8:34b::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.21; Fri, 7 Aug
 2026 18:10:57 +0000
Received: from SJ1PEPF000026C7.namprd04.prod.outlook.com
 (2603:10b6:a03:5c3::4) by BY1P220CA0026.outlook.office365.com
 (2603:10b6:a03:5c3::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.24 via Frontend Transport; Fri, 7
 Aug 2026 18:10:56 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SJ1PEPF000026C7.mail.protection.outlook.com (10.167.244.104) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Fri, 7 Aug 2026 18:10:56 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 677GPpos735195
 for <xen-devel@lists.xenproject.org>; Fri, 7 Aug 2026 14:10:55 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [3.215.31.156])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fwht505re-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 14:10:55 -0400 (EDT)
Received: from localhost ([19.12.76.221]) by cmsmtp with ESMTPSA
 id sP1xwLQNMQLYTsP1yw4Ucm; Fri, 07 Aug 2026 18:10:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppford; bh=TlrCq8h8VLV4J0xBkPzKOMs+OF2
	Q33B6BaooHIRCSes=; b=dSNxbnYlbOfMQ/i3QdM16QIbLUGyMPY8QiCqTa/9mYc
	4xGg637+10oRqg5Ez0Gkv0TGYcDoP4Ag4bLNSP74DBcR5/vxXzf5lgQ7A4ikziLt
	WgXv+dlOLnExp40t0EXCxsPINAkvMGbcwf8ZK1hIOGKLfdYq/ONDDrtCw0HkMeT2
	Oi9TEyfDF0P3n6tXMa6FaeS88lNmgr2I1IMBghv2duijnRLEuM/CSQ7lxgA0BKv0
	12l21jn72RMVfFtZm4f3rUY6tcYw0g5mvVOuRzh8YgXSYWP98hMLuixj4lAZReHr
	/tk5y9Ghl2U1AbfLk2RKUiiHAYh3ub5D1qGmUk02Fxg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lPolVldk7IM3D2km7fe4T51PyP8/3j+YwrXq6DwlVLkd4YkU7jcnJzffjtO+0nkxi7yEscx1hp/1RQ4FESR8QpfY53YqO2Iu2Uq0eDTp/PFQQ0WYUeP5nyFqVcT8+/IPLL5HUcBHtVbBBo2EARGBBrOwxANH7YygheAAP/gQ8W0wxDl8Vde+b0jVySZg+V3pRWLLvcbhi+y77mMks9hoVXJB1h5YFeJ1lCViDFzl/jV+ivDFG2efYEx86lWRc0se2PU9W/3khIBBVlpiu6GrUjG/n6iwy1xZl1Zqzcc5k7T02Xh5K2hImnUrXGDCpKnTQoxKzV+Wkm04mCEHhjbpng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TlrCq8h8VLV4J0xBkPzKOMs+OF2Q33B6BaooHIRCSes=;
 b=mLeTJLPq5e0gIwTVdBevH2yrvoEA3al+wZXy+ocxKneQ2AaxU2nqD0sCsnRKUJfC7jPKWdwjcRn6l7oOozz+RdP+HyUZbskg/pa5ky3OB2fqpuA1h6MFL2ALrsgMQjEJqNsdJ/XmhuAD+MdSBaIYQ5OE6YqMTWi6doyRxlQSCmBEAOj7LKYWQQwH4CZCHKBaNnk89c2CF+o3eoFX1Den43NXDcdfIXuqnI/UE8PtPTyNiI4MEt0ENBXjlCXMr05F29DldMEe81gC9nDxpvstSi1S6WmP7Deq0GFV11XERJdluWm6+leQKooVrVnlgxGyJbpT+AB2fjdqiCmg6iNcjg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TlrCq8h8VLV4J0xBkPzKOMs+OF2Q33B6BaooHIRCSes=;
 b=FCkKc98XClcLVRupCG2uF9z6+6WNW8eSe+9CR39Y0gxlPlifEnsKf1KSwbie93/IG9k8osUhd5TuTNa8gidgI1Qj+XEy9S4rWLLHcnkrfSQP+8Zf1Ym2uEwaUj5tNxmIHAmLoS0f8eFHRf/LXgDwol16fQR0GjBOAATu0MXIWWo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppserprodsaar;
	 bh=TlrCq8h8VLV4J0xBkPzKOMs+OF2Q33B6BaooHIRCSes=; b=V/5aAixlQ+It
	bX2EfjGhBOHGGl6ok9T6b5weqvYrCAJH9nY17x7rEQ5ZQBwT7yjA80CSEVAo5j0S
	bte6KoHvDodtSM5z9L+bXRqHQhMgxakp/pf9dcmiG25eD8+mDkocN6nl+Znxke6l
	TEjSKwY0CpBEjicfeCn7332jrWm5VnCC1VWDvsJpPszDkaK9iy6+cdxbp6v13mrl
	ni/7+54HfPFsuWDxhAYh+cHF3KOpYCvSjXLenHGE6LN1nxFDKVBBzUj9NZncSzM3
	2ZjK2Dt/2UueuiTe+inw5Sg6djTVcmQagnKPuj/k9+jzfSXTHLWiSUU8ao4MSDCf
	OtQCnUSCRg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppfserpocford; bh=TlrCq8h8VLV4J0xBkPzK
	OMs+OF2Q33B6BaooHIRCSes=; b=JtgH0VxNYzBf8r8lcqxqrhP0YiLtSa2Y1IhG
	I9V/HwEjRsWXMIaxIuBhTOeR6oYHhXZ9uIPGPj6VbaYlntAVpG4F/FDLLmlIMkY1
	e2feQqS+zqfLZDR+KJmhVDE/5n2lvr8iOCu9GU/Vm5gtjFBlI7dn9FSVDcW5d2N7
	o/pZV6BFwEVM3zKnH8i5R1/Ybl4duEX+Y5/EpM0UIJ42/C0ty9Tltp48BIBBGlGc
	M5sXSFKHIjyIi0rQ2XlSIoiR5Lt4o0sR4tme9Ykk/a/1vU8oe+L0ljXBQI3wJoVS
	blTzUA4+Pjl9M2bu3LYBW34I0sRJkni3QzSr2Dhmxy78JtLQ8A==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: sP1xwLQNMQLYTsP1yw4Ucm
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Fri, 7 Aug 2026 11:10:52 -0700
To: Jan Beulich <jbeulich@suse.com>
Cc: dmukhin@ford.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] acpi: reboot: log reset parameters
Message-ID: <anYfrNnXTsWJJ5kH@kraken>
References: <20260801031737.344756-3-dmukhin@ford.com>
 <0491d3fa-ea8f-4cd7-822a-9c5a9be8d8fd@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0491d3fa-ea8f-4cd7-822a-9c5a9be8d8fd@suse.com>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-07_03,2026-08-07_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 bulkscore=0 adultscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608070142
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C7:EE_|DS4PR16MB935079:EE_
X-MS-Office365-Filtering-Correlation-Id: 41fbe0de-83e6-48d5-1601-08def4af3a60
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|36860700016|376014|23010399003|18002099003|22082099003|4143699003|11063799006|56012099006|13003099007|10067099003;
X-Microsoft-Antispam-Message-Info:
	uYxjCVJfNd6gFypYbtjtQ94sZU49xJmIcqaSdTwPBEum31K0peJZUCwiMwQgJqFS2lLf4Qk0siBOXm0EyrIYgadLD9oIo+T2JDvmEdn6uR6w5o1QTaIhbyRv6fuoiFlfgSWx+bfRVpf65pNfgaQnMdKEzGlPlzG4jdTfOWCjyv/WQQLEHvxR7KVJLiXP41hKfhY1/NS9stiLdQLQRtLiAP8x7vZ2Gkz3hrRc9limypHMtCbnSzp4WwEE3QtPedHKix1cHsVhsRQRmaB9BHkPw2e2IRnHG8uSXpxyQkLB7msqo0kTwY5ZIf/7Xo25mGA2AyJ1zz6+tiWZseYQNharQj8m4dbsAjCTXWgYsIyEoXKN+p4I18O9pm2RMRuSKM7Hlj5VyhW3uNPFVvbe1d6VskaN4JsKVHZ5liIurNSLfvcutFg+aJtXrhAuvuTi6Ow4Cq0XzUuEziI3hd46wr24BuoZY7flAhZs2GnZ4s75fzoxk5Cu85HiglmvL+YeE8wplCSxzGNgz494e8dT6l2/FYUg5G9RaSB5KtKrW6ee0tDKZspcal68J79O5TWGWoS9wPw1XZr4AOFeQvPVG8L33aRtWSqWodI6tCdzJitvVTi6fHz1E1jRsgzEOMcGI0Mqxzo8WkM40qjS4NLWX0dtZIhBaTgFHU7DZRdjHeHrUt39oQEr/n4kICiv3ubajY9kYkzqdh9K3DBMfOESr8NHhg==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700016)(376014)(23010399003)(18002099003)(22082099003)(4143699003)(11063799006)(56012099006)(13003099007)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	ni41hoY3aOp2ceXs5ViB1HR4xkl5pe/eRfpWIzelALq5HTrfMjdz8YDBNT9678ecaHlkC/ALVZ6Rsg9w2WPwoySHgVuqzlFRPiklXNuwVEkvlMG437FUVf2uihOccEvWeceR9bhS/4CZoX4jy4kwPx9Npf9wO8BwC/H1vtp0h2hU8+i034YZx2bdIPc130Ixx3bn5Z9mD0yZa0g7duUFj0BWSxaddQ9J/7nbfrW9sgrxQ6MnJHmlopj3CAHFb+xBEnzllF290F/x0eW9QIrm05mxzDQSyqIf0IVojEBnq1vAPeUoNJw0WnMKMpEKEI3BJoCNN+cMbekigz0WNH0dcnZ+6mpgn29efqnB90djEZKVSFzIFoTL7EsQNHpym/pPt2yhBucZCyr2ZNyh31LhJIY26fCRT+jKsTUVdgq+0B9ptKonurwP+YxLuYJDalh+
X-Exchange-RoutingPolicyChecked:
	jQ1cU4rIQFld1UAwkXLl84P3hWPTaGBsC6hSZ1KvzTdd+ajIcBk2HTvd+BocnL/Y9rxwqke0cakkhJQTJfrlMUqoLzQFBYZ9mugmJr3ddUSNWsE63EfxUvIiggX8oNkukn7ljsOqIAGN7LwC/+8IMRIN3LdPde4CTb7oKO06Aou/QAGyNc373wI75ixu/hvW1NsqbSavC9CFNnIswv3s+MY3KYD6OWA/+viUXO8UrZyfeBlAtt7Sh+1IWF7K4UUobthnwxmQj9nlklWOAu4J0M/cpXdItOqWFQHlRzhHrdXTVRKZFhT06isjuePHjjIqMRIAAasM/1la61I5JYod1A==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	B5iaohBeSYtfk4oZY9P60S6bpcF6f+c7BWOOYm5VBoLRMGW8xRL0I0kWmhEMU6xx9Qdkp1Qfefq2sL6M+RkEpCwuFQEAhcHnDqDj7Tidk81HNQ+yOm0xy8VWObx16g6K1nRt/1dzOtYs3G3fLWxSi3+iyBxU6S6NQ7npUesEBgi3Al8yJCTCi9wu94xPjHb3r4L7dcqd9XSuUH2Szn6Ze5ejTpzK0Zd/xWOkK6f77CUtLttzOx07e+tswFo3YjIf62NGcNuXAcDnbUuVmws7at4DFRKmZpD5ulOgtYFlO+z14/2P/bVTtq1F15NR2d8BuWJSywSriheFlaw0MB4nH6IosBguOyuZN8hXTQOi05SwiGRVee/ZSm9seJ8Jv9do4XlvxMWJ7xv4hTxH5/oS6OW5BrETmHaa8uyDfwN0kTrDmK72sRr0KdybRwlVtmzlL7GmEu3bccgIlvvBG1xpr30ag2AJRw4jCBiOOoY/w8LtESFiO147PyiKrrmuvnsdg4HOXQI70Fdo5neklXwQUsv0VfOC7t1tXi55CXS9Lf9sQjigAftYx+s9pczPVzVrSp9LBv0xX1niaYaJXKTn1seNIkQEeZz2iwqDXNaap6QpX/rbMW6q9wtrmWJECtl2
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2026 18:10:56.6268
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 41fbe0de-83e6-48d5-1601-08def4af3a60
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000026C7.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR16MB935079
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODA3MDE0MiBTYWx0ZWRfX1kvezEFzi9K5
 Pv39NhfYMOnGofOqXjldIxYSWKZNzr7CkAWtCq3IydKcvw8Nl1t9trFbTWvJbx/Qm4mx/UwJiGA
 WC7p4ZZmx5PEXzijuqGqOuZxeIQHmndhmEerJ5zmKxReLCpybwTwQQzQEAwNbqgGe4AasRPAx30
 ddC5zZX6dWrnxJDUL5XCu3ojrQvb3Vyb4fSGwU7owRbT736vNO6j3m+eqv0jQkmGSk2MQATNd/w
 9hz6VLzd1sGagID5lihzlzONOimCTTYXqR893bb1Yp7/XnQJSPCiDoQaJwac0rewYP+IB2eJGUk
 m5MhSwLgiZNfIGPNBPwXGQsvS4CEuW+qb6idyLuISRKgQKdj5h+JE2HbRPiJCAOS4begnUfIBMI
 z+BMfzYjjxVmLlvUeHvM3VBJb6kHY7YYvXcHZH/PMATbQDohg53vrwV6H3vpR5cLRDlilkrJRNK
 RPMHdhJscq1qGFN2UWg==
X-Authority-Analysis: v=2.4 cv=S/7pBosP c=1 sm=1 tr=0 ts=6a761fb5 cx=c_pps
 a=9AjoWhdl+q7f6/Aw5qa/DQ==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=vnUQfov-gS4s1L7hHvr-:22
 a=VwQbUJbxAAAA:8 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=iox4zFpeAAAA:8
 a=gQpY9S37BheUtGlbrbAA:9 a=CjuIK1q_8ugA:10 a=G69WFyCBNqGPyalROSdv:22
 a=WzC6qhA0u3u7Ye7llzcV:22
X-Proofpoint-ORIG-GUID: t_oamdVL4yaJ6Gqd0i7c3CS87yG68LkV
X-Proofpoint-Spam-Info: AW1haW4tMjYwODA3MDE0MiBTYWx0ZWRfX1/xQPnQ1Rlfy
 Yisj+ESKJTIKL+6zXAjbvfwISOmurLUBUuYy3IZEz9MLuFTNdSUOILsR85DGpO48ql9VFg8RC9K
 Mfmg2kFIhkR2SvihXiFfcL2VUV+Y8JnHGJFXLlgonyYEqASLHgHw
X-Proofpoint-GUID: t_oamdVL4yaJ6Gqd0i7c3CS87yG68LkV
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-07_03,2026-08-07_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 suspectscore=0 phishscore=0 priorityscore=1501 bulkscore=0 clxscore=1015
 lowpriorityscore=0 spamscore=0 impostorscore=0 adultscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608070142
X-purgate-ID: tlsNG-bad1c0/1786126267-3B6D2034-DAB91B74/0/0
X-purgate-type: clean
X-purgate-size: 1900

On Wed, Aug 05, 2026 at 12:18:33PM +0200, Jan Beulich wrote:
> On 01.08.2026 05:17, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com> 
> > 
> > Xen does not provide much details for system reset debugging in case
> > system reset happens via ACPI subsystem.
> > 
> > Log reset I/O address and reset value.
> > 
> > While here, add the missing default case, add breaks between case
> > statements and drop full stops in the loglines.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > - v1: https://lore.kernel.org/xen-devel/20260730001854.905354-2-dmukhin@ford.com/ 
> > - CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2723268852
> > 
> > Changes since v1:
> > - removed wrong ASSERT_UNREACHABLE()
> 
> And you replaced it with a printk(), which I don't view as helpful. If we
> want to diagnose the address violating the spec, that should be done
> elsewhere.

Ack.

> 
> > @@ -21,17 +22,30 @@ void acpi_reboot(void)
> >  	 * on a device on bus 0. */
> >  	switch (rr->space_id) {
> >  	case ACPI_ADR_SPACE_PCI_CONFIG:
> > -		printk("Resetting with ACPI PCI RESET_REG.\n");
> > +		sbdf = PCI_SBDF(0, 0, rr->address >> 32, rr->address >> 16);
> > +		printk("Resetting with ACPI PCI %pp RESET_REG at %#lx (%#x)\n",
> > +		       &sbdf, rr->address & 0xff, reset_value);
> 
> rr->address is u64, and the code here isn't arch-specific. Yes, the file is
> built for x86 only right now, so 'l' as format modifier is kind of okay for
> the time being. But really PRIx64 would want using. (I'm sorry for not
> noticing this on v1 already.)

I had doubts on that one, but decided to go with 'l' in v2.

> 
> Preferably with that adjustment and with the excess log message dropped
> again (I can certainly do so while committing):
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thank you!

> 
> Jan
> 


From xen-devel-bounces@lists.xenproject.org Fri Aug 07 21:29:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Aug 2026 21:29:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386340.1628293 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsS7U-0000IL-GY; Fri, 07 Aug 2026 21:28:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386340.1628293; Fri, 07 Aug 2026 21:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsS7U-0000IE-DV; Fri, 07 Aug 2026 21:28:48 +0000
Received: by outflank-mailman (input) for mailman id 1386340;
 Fri, 07 Aug 2026 21:28:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@swg.vates.tech>)
 id 1wsS7S-0000I7-SF
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 21:28:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsS7R-008FS8-JY
 for xen-devel@lists.xenproject.org; Fri, 07 Aug 2026 23:28:45 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@swg.vates.tech>)
 id 6a764dc4-2eae-0a2a0a5409dd-0a2a4502dd92-32
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 23:28:45 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@swg.vates.tech>)
 id 6a764e0c-6ca4-0a2a45020019-b9ff1c239c41-3
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 23:28:45 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fde20d3e4000e099.005 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 07 Aug 2026 21:28:41 +0000
Received: from localhost.localdomain (88-188-240-210.subs.proxad.net
 [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 540A1835D6;
 Fri,  7 Aug 2026 23:28:40 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=siQjNhS1rXHQWa6eDG4c4KcvJWFe9SWt3KniEaLmaqw=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id;
 b=oOchjdIjqNY73vWIm+X3lBJirJzsJpZnFCh+IN2ROdO7Nm4qe4Qv5qUmQ5mWndQQ3DHXGwTK6
 PytkPhENDY8BW2FP5j/tKa1hD1XvZHfFBJFgx6p6csPsOgZxFK4HJ61RosdYGe5DW///shObQjq
 cEmHuNsc/b+1jmJ06gaY15+OI6/crVWEuyvrNt8lZ6YGwRrcRSX0LN9hZAho+4UYrazo/GOANUD
 qgf3hP1+dChhmszwOi+Pld/h6+3lunu67hDyN1lhymUhpdOSxENItYXUfU3bv6KjtEne/T2jp4+
 1UqtERyGqjcJTPp9XZPGip8FxCqn4B3bvQqYSJHgxUeQ==
X-Zone-Loop: 0f7696cbc95cc987e045f65c6e6af76de5cb2c0eb37c
x-campaign-type: default
x-transaction-id: fd0e310a-1f27-4724-be14-41255f131e87
x-swg-uid: 01-db421d96-5e6c-44da-b753-4c378dd236cc
X-Mailer: Sweego
Message-ID:
 <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
x-swg-bid: 1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Teddy Astie <teddy.astie@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Kevin Lampis <kevin.lampis@citrix.com>
Subject: [PATCH] public/xen.h: Update comment on mmu_update sub-command size and PTE alignment
Date: Fri,  7 Aug 2026 23:28:10 +0200
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.1f09.34907377b737dadc.19fde20d17d.acbe1d96dc5fb6c6=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786138120576
X-purgate-ID: tlsNG-720697/1786138125-323D42AC-1DCA6395/0/0
X-purgate-type: clean
X-purgate-size: 4436

---=Part.1f09.34907377b737dadc.19fde20d17d.acbe1d96dc5fb6c6=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

HYPERVISOR_mmu_update passes a set of request, where each request has a poi=
nter
to the PTE along with a sub-command=2E

The PTE alignment padding is used to transport the sub-command while the r=
est
is used as a address to a PTE entry=2E The current documentation state tha=
t the
2 first bits are used for sub-command, hence the other ones for PTE which
imply here a 4-bytes alignment on PTEs=2E

On PV64 and PV32-PAE guests, all pagetable PTEs are 8-bytes aligned, hence
off-by-4 PTEs addresses are always incorrect=2E Non-PAE PV32 guests used
"legacy pagetables" which had 4-byte aligned PTEs=2E However, support had
been completely removed since Xen 4=2E0, and were only available when Xen =
was
built in 32-bits non-PAE mode [1]=2E

Current Xen logic behave as if 3 bits are used as sub-command, thus all
off-by-4 PTEs are actually rejected as being unknown sub-commands=2E

Adjust the documentation to match the current logic implemented in Xen,
also expanding the documented sub-command parameter to 3 bits=2E

[1] 84d54d5d8b31 ("i386: Remove non-PAE hypervisor build target=2E")

Signed-off-by: Teddy Astie <teddy=2Eastie@vates=2Etech>
---
This happens to be a complete rewording of [2]=2E I'm not sure what to do =
exactly
regarding the signed-off=2E

CC: Kevin Lampis <kevin=2Elampis@citrix=2Ecom>
This now expanded sub-command field can be used for your "unmap_page_range=
 optimisation"
series to avoid having to introduce a new dedicated hypercall=2E

[2] https://lore=2Ekernel=2Eorg/xen-devel/20260528075539=2E10209-3-fredian=
o=2Eziglio@cloud=2Ecom/

 xen/include/public/xen=2Eh | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/include/public/xen=2Eh b/xen/include/public/xen=2Eh
index 2149b8dd38=2E=2Eb4fef2c5ba 100644
--- a/xen/include/public/xen=2Eh
+++ b/xen/include/public/xen=2Eh
@@ -218,16 +218,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *                     x =3D=3D 0 =3D> PFD =3D=3D DOMID_SELF
  *                     x !=3D 0 =3D> PFD =3D=3D x - 1
  *
- * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command=2E
+ * Sub-commands: ptr[2:0] specifies the appropriate MMU_* command=2E
  * -------------
- * ptr[1:0] =3D=3D MMU_NORMAL_PT_UPDATE:
+ * ptr[2:0] =3D=3D MMU_NORMAL_PT_UPDATE:
  * Updates an entry in a page table belonging to PFD=2E If updating an L1=
 table,
  * and the new table entry is valid/present, the mapped frame must belong=
 to
  * FD=2E If attempting to map an I/O page then the caller assumes the pri=
vilege
  * of the FD=2E
  * FD =3D=3D DOMID_IO: Permit /only/ I/O mappings, at the priv level of t=
he caller=2E
  * FD =3D=3D DOMID_XEN: Map restricted areas of Xen's heap space=2E
- * ptr[:2]  -- Machine address of the page-table entry to modify=2E
+ * ptr[:3]  -- Machine address of the page-table entry to modify=2E
  * val      -- Value to write=2E
  *
  * There also certain implicit requirements when using this hypercall=2E =
The
@@ -264,17 +264,17 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * mentioned above=2E The argument is MMUEXT_UNPIN_TABLE for all levels a=
nd the
  * pagetable MUST not be in use (meaning that the cr3 is not set to it)=
=2E
  *
- * ptr[1:0] =3D=3D MMU_MACHPHYS_UPDATE:
+ * ptr[2:0] =3D=3D MMU_MACHPHYS_UPDATE:
  * Updates an entry in the machine->pseudo-physical mapping table=2E
- * ptr[:2]  -- Machine address within the frame whose mapping to modify=
=2E
+ * ptr[:3]  -- Machine address within the frame whose mapping to modify=
=2E
  *             The frame must belong to the FD, if one is specified=2E
  * val      -- Value to write into the mapping entry=2E
  *
- * ptr[1:0] =3D=3D MMU_PT_UPDATE_PRESERVE_AD:
+ * ptr[2:0] =3D=3D MMU_PT_UPDATE_PRESERVE_AD:
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are O=
Red
  * with those in @val=2E
  *
- * ptr[1:0] =3D=3D MMU_PT_UPDATE_NO_TRANSLATE:
+ * ptr[2:0] =3D=3D MMU_PT_UPDATE_NO_TRANSLATE:
  * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
  * page tables=2E
  *
--=20
2=2E54=2E0



-- 
 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vate=
s=2Etech
---=Part.1f09.34907377b737dadc.19fde20d17d.acbe1d96dc5fb6c6=---


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 00:45:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 00:45:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386379.1628304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsVBD-0001P5-Fa; Sat, 08 Aug 2026 00:44:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386379.1628304; Sat, 08 Aug 2026 00:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsVBD-0001Ou-Ac; Sat, 08 Aug 2026 00:44:51 +0000
Received: by outflank-mailman (input) for mailman id 1386379;
 Sat, 08 Aug 2026 00:44:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wsVBB-0001Oo-UA
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 00:44:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsVBA-00EqqD-He
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 02:44:48 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a767b46-bab6-0a2a0a5309dd-0a2a4501de6c-48
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 02:44:48 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a767bff-5984-0a2a45010019-ac6904fea2e6-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 02:44:48 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id AC356600B1;
 Sat,  8 Aug 2026 00:44:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA8411F000E9;
 Sat,  8 Aug 2026 00:44:44 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786149886;
	bh=yOkvWs6dZIhxOfDfv+/i3ba1lORp8hpNwzvQJIvho3Y=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=GPyJ0bnryF6XL37qew3mlhH2YarbNIa+tif4ZHxlR6k/ZKXZPFYXTHA544WFRgRUT
	 fllp2pOJ34aPwoxXlMDq9v4g5OYYm3qkmS5ic0vq9YICLX5w4kqhqkwPZJXNMdJXPC
	 IEiIbDXI1pP2CUsiKeKTPgsENJRL6Ukyjd59GmCMLn1+tX4TerJOvcKtdGvfw7clad
	 gljQZ4OOwtP1nPuJ2JG7Gy5J+joJzq/rMU1pESq/27meriQ89Ng+dIxxI1/noOj9wL
	 rSFqe3/IMHIeT73ZjBaSPuE2suLmy5cAXtgv6h9g0/xxYcQEc3hkyO4Q8aPYbodo0T
	 8z+VnjvoLXL5Q==
Date: Fri, 7 Aug 2026 17:44:41 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org
Subject: Re: [PATCH v2 2/2] xen/common: add keyhandler to show Xen command
 line
In-Reply-To: <20260803070047.3097846-3-dmukhin@ford.com>
Message-ID: <df43b4f0-9973-b80e-47a9-f0cfa65651aa@kernel.org>
References: <20260803070047.3097846-1-dmukhin@ford.com> <20260803070047.3097846-3-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-d62444/1786149888-BCF47757-C0EA106E/0/0
X-purgate-type: clean
X-purgate-size: 1929

On Mon, 3 Aug 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Currently there's no way to print Xen command line on the emergency
> console for debugging purposes (e.g. 'xl' is not available in dom0).
> 
> Add new keyhander 'X' to do command line printout.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> v1: https://lore.kernel.org/xen-devel/20260730061459.2702672-2-dmukhin@ford.com/
> 
> Changes since v1:
> - moved implementation into kernel.c
> ---
>  xen/common/kernel.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index d1bef9ac2b2b..9f334c92e3ab 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <xen/init.h>
> +#include <xen/keyhandler.h>
>  #include <xen/lib.h>
>  #include <xen/errno.h>
>  #include <xen/param.h>
> @@ -505,6 +506,21 @@ static int __init cf_check param_init(void)
>  __initcall(param_init);
>  #endif
>  
> +static void cf_check show_hypervisor_info(unsigned char key)
> +{
> +    printk("'%c' pressed -> showing hypervisor information\n", key);
> +    printk("Command line: %s\n", saved_cmdline);

if CONFIG_CMDLINE_OVERRIDE is defined, saved_cmdline is empty. We could
at least do this:

#ifdef CONFIG_CMDLINE_OVERRIDE
    printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");
#else
    printk("Command line: %s\n", saved_cmdline);
#endif

Other than that it is fine for me



> +}
> +
> +static int __init cf_check misc_init(void)
> +{
> +    register_keyhandler('X', show_hypervisor_info,
> +                        "show hypervisor information", 0);
> +
> +    return 0;
> +}
> +__initcall(misc_init);
> +
>  static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      struct xen_varbuf user_str;
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 02:38:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 02:38:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386416.1628312 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsWxN-0001y9-C3; Sat, 08 Aug 2026 02:38:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386416.1628312; Sat, 08 Aug 2026 02:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsWxN-0001y1-6u; Sat, 08 Aug 2026 02:38:41 +0000
Received: by outflank-mailman (input) for mailman id 1386416;
 Sat, 08 Aug 2026 02:38:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wsWxL-0001xv-5f
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 02:38:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsWxK-002dkF-4n
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 04:38:38 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7696a2-2eae-0a2a0a5409dd-0a2a450387fa-2
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 04:38:38 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7696ac-fae8-0a2a45030019-94a39217ca32-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 04:38:37 +0200
Received: from pps.filterd (m0367124.ppops.net [127.0.0.1])
 by mx0a-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6780jSmm1685007
 for <xen-devel@lists.xenproject.org>; Sat, 8 Aug 2026 02:38:35 GMT
Received: from ph7pr06cu001.outbound.protection.outlook.com
 (mail-westus3azon11010018.outbound.protection.outlook.com [52.101.201.18])
 by mx0a-00498f03.pphosted.com (PPS) with ESMTPS id 4fwmjyap7y-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 02:38:35 +0000 (GMT)
Received: from MN0PR05CA0018.namprd05.prod.outlook.com (2603:10b6:208:52c::30)
 by BLAPR16MB3843.namprd16.prod.outlook.com (2603:10b6:208:27c::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.245.11; Sat, 8 Aug
 2026 02:38:32 +0000
Received: from BL6PEPF00022571.namprd02.prod.outlook.com
 (2603:10b6:208:52c:cafe::97) by MN0PR05CA0018.outlook.office365.com
 (2603:10b6:208:52c::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.10 via Frontend Transport; Sat, 8
 Aug 2026 02:38:32 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 BL6PEPF00022571.mail.protection.outlook.com (10.167.249.39) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Sat, 8 Aug 2026 02:38:32 +0000
Received: from pps.filterd (m0426317.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 6780l5xw1815968
 for <xen-devel@lists.xenproject.org>; Fri, 7 Aug 2026 22:38:31 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [3.215.31.156])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4fsyvwg463-7
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 22:38:31 -0400 (EDT)
Received: from localhost ([19.12.92.222]) by cmsmtp with ESMTPSA
 id sWxBwTb4fSqacsWxBwv8E7; Sat, 08 Aug 2026 02:38:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppford; bh=VVocyPjs5xADxPDxMphRRc5RXD7
	ku5EpzkZWOv5SIjQ=; b=m75gY0m49hZT3uNrqSt4mog4Kxa1csBrgs4fyw2tXok
	anKQkyGva47M56lf17AZhOwcuKcfwq+wNBW6MXlz4idRi75zsnMWL3iNEDazfpM+
	FDPcoVEp5e1Y9L25ftJYrVhKvSGNaA7SMJ/4V6avHbz0WyupBqYbT+jkRxirSx2e
	Omt/Ip521u88RdnIw8NOf+CulZzUnUXtdRUAgUUmPAxgFkVROhe21mnC4fS2VB6t
	G73TAO9U4hSlGuJp1+ArA/ibnxkcmYh40HpcHTYyG4TZx5ylJ7u7uBN1KUAjxmgN
	Y7vhWp4uDtethozEe+Swb3bBX+dNeNrshVP0hFjLHew==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=o2hZhpHS6/VsLyAbbbfh1MyiVI90ia7LsJEwmFJ4hnacOaliaf1rT1uOKcHhxTfaSJXK19uV2adC0oyv34P4FN7U2rxGOY6ZWnyKNN/ninrBSWjySoVpv/csoeINC87mG0g86V4DJF+OdLBajtH/RBXIZGrEn6qPNeBeK+UimFx9H5zZlNf4F6NiTcH3Ii9Mu/11IUadXj8SLK+q3udWyV6t8npLqvEPraqbo1boilOjnUesMbdKyxhRy1byb93G6LbdXUoin9+qvSLpPCW0yeM1z2b/STKyEQ989+0rY3ZAWLw9P7CZOH0+DShrzp+7fYUxUBU8Ie0I5R+c0rnIPQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VVocyPjs5xADxPDxMphRRc5RXD7ku5EpzkZWOv5SIjQ=;
 b=jDrGTTkI/hEvCffUQ0Oi+g8KQSi31J9erkQ3ZFD/AEGeNsGW5tySuDThWpZdpbBkiUtUXmYSy8grFnk1H7b3GlwTbwLlWQkqjsMfj4vkEDmznoFgev0qd0gbdo9lCs9ShWG/QQCYLG2+QCh1u8hglf9WsInQK2ebDkQ2uF63gPOFF0mXqf/wiSDYzni+iPEBPIekqrQUwLvFgis4/HnYfVeGTfrOp2E7UxNcFNKojIQAhPuymcOILkfpiZntQ1/OYu3gmxjxtysxdcxQNlnEG8elK+oD1Xfm0YNBg61q6z7ZCxL4vyA3BHtDyfjdbPCFW0nQJ5qxegDls0a2+CsU9g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=VVocyPjs5xADxPDxMphRRc5RXD7ku5EpzkZWOv5SIjQ=;
 b=KaGOw8ALV/QCf6xIA0uJIpxjmd5tgibm1TWWrcNc0TxW40+gpNFAdBUIkltfSid3DkGOXEchhJvY2nIblPJw9AaJ2cKJClY3IoNfssc9cHSpXcykipIUJr3wM5mucue/egqNbk+axWmjWnFem0IOwXY54k5NqGEOM2WDaJ9qtWs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppserprodsaar;
	 bh=VVocyPjs5xADxPDxMphRRc5RXD7ku5EpzkZWOv5SIjQ=; b=B+gu6SccxuV9
	Z8eE4fjHPdQxpqXWQbGoxAe3Fwa6NgwZnKqMg1xE1kFP4DU/pBAsLss+Wnzw4H2B
	jtP4AqPxi518ErzH+ln70iHbrVXiNCrdNBTkLj5zxa88PTlfhjS81l12tTr0TUGO
	wAKEtVCT0w4tOD3aw16RENT3JfUhiENk7pHfO4oLcP3ONqZyeYx48oJbm0gslGbC
	Tn46rOJSaO3pc+L+/QdSHZD6jWdEQxeitwJL+rmpPoCaw5Un+JNyNnLyNvWJDj9e
	HVQQbDlPXO2qLiy+Zl2pg/kD1q50NTzigaOg47Caq1NXhVPBQqBM4B0KjcokPhAH
	GSOFTatMaw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppfserpocford; bh=VVocyPjs5xADxPDxMphR
	Rc5RXD7ku5EpzkZWOv5SIjQ=; b=Aqo+lMzp0GtEvJWv/r2AKR1vfmDRZCAnPULi
	OXZjh+/AIbORYk89jRnePNc7Lf4gwgKDXxTKyihSJC/j7+kv7Jw6NbHvFmEnZg/8
	Xaf8AI0O7cqJbQIVtnbJdhanu7kOCIEp8EdeZip7Gv8cZesTjJ/4ndCFoHId9az9
	Ja+VQFrhHdZvPusRG2mi4GqC26df07zQYyTxsZamcOcrc4Tz4gilGBS3Xx1P9rvU
	0sKKJbb479hZTJtAChSSdEi4JG1AH12vuaAOCSdtfcjL1w01CzX2savpxHGWlvy1
	9Dci+4/sf7NrBSRtvYPXwvhY6A8KrPsvDmJslxLPzHfH/NPQuw==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: sWxBwTb4fSqacsWxBwv8E7
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Fri, 7 Aug 2026 19:38:28 -0700
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
        andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com,
        roger@xenproject.org
Subject: Re: [PATCH v2 2/2] xen/common: add keyhandler to show Xen command
 line
Message-ID: <anaWpO/zu5sI4A9u@kraken>
References: <20260803070047.3097846-1-dmukhin@ford.com>
 <20260803070047.3097846-3-dmukhin@ford.com>
 <df43b4f0-9973-b80e-47a9-f0cfa65651aa@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <df43b4f0-9973-b80e-47a9-f0cfa65651aa@kernel.org>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-08_01,2026-08-07_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 malwarescore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608080019
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF00022571:EE_|BLAPR16MB3843:EE_
X-MS-Office365-Filtering-Correlation-Id: 37698fbd-f206-4af6-c3b0-08def4f62374
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|1800799024|36860700016|82310400026|13003099007|56012099006|4143699003|11063799006|10067099003|18002099003|22082099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	MlAmNTfO8wAQMFmPiYJc+it6uKR0nq6u3z8HLJWQAzChB0bDuEV/Xz03ucgB37WPJ0p/p7nqY0u4imlock7ea5JpsUDZK22SEoq7bYvj68GzssXfwDr4WcThXgffiPIjVg+vStem7STyGnpQqHbqRRS6+O0Ad7YavISPB2mKEsi6Gff/A+IvXTYUsMwHrvYwTnNv7hNscyICqzhkABmHCwuePmklu7/YR2h01S8h3icFFSI+b+wZAc9iYUUEdq1qDeicv66DQUyx66zVnTARFM+JSv2VJC12ETiiIV1dqct5SeQCwMwv8Hvn8Ny6GZwjwYa0K1mn8NLjClSRwkbCzvNzybi0gNiCz/YlrGOKgl3ffMPN+diaqiX3nh3n0xKfIZW74pQTiMZpKVQ+55BgTdHPLyvacoU+ZPRJ/mW38aBCLg3UOH1F2ub8LbvfhbdZDA58eq4c8hSFSHWal8+36ytpmUBrS45vZy3ct5W3Sc5A88IMsUVTUKaJrR6yhfm/sdRtUszcoqtNszqxNiYjOlMK57uI4/VnTzUNuaULbfMwG3XFa+MK1XIIF8GTduGR62ZSjVZEaxWnd9NyCA5gF74HQDnZV5fKgIBvpV4zTX1zVxR99SbJ7rhpmM/+fYWMXx5Cr5wSg3KOo1it63Plx9XRvtUPEpX10RYgZrm/NSr2EfrgrNMteVFJQJ5cafuPgkxAxzakbVKPmpQnb+W5qw==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(36860700016)(82310400026)(13003099007)(56012099006)(4143699003)(11063799006)(10067099003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	y8oeqO9haz5v/5BpcdEnvV8tFjAHSOJxVp02xba5XozKr5MsIpejqpIN+aIS/8DF7586oc0xp1Ti0Wi6OyNDTxsHpl28gHWOngq1CwZpbrs42kZ3fb2yub99IhifH/3WI4hCACNNZYznl2axG2PhJw75Cr8rfqv7CFg+T591R+navkTF6QqRX4wJJTKTj2a0DK5hLBJdEF6oU1g3H4qHH6/Fc02oPHybOauaoyGOFecN3RwenGwuYIGR883RjfhDt8gHIkuDUdToi9Dxsbvp0V+3m/Bk4zpZwgqMs8xFc28n2cr4c6nRe/fp3PkqTxRNd1DHXCi7R9W7hnLI96hb+rFpktG0pq6Bg0BQ/czdaIfErEydwqwPZQ2QzqteOAb0gcPGuu9qvOEtcs/y51ly3VtjpMfQKGpCb9xRxCzd2lQPQJRxgi+706u57hZ/AUAF
X-Exchange-RoutingPolicyChecked:
	gXddJERaxPSpqJMgy1pO3stgbF1xrMNYT+SWc914Qiu/w6Ze8yOQqTEX+yvYSb56qTs4wD1vPY4z4ABeD6ruVfcKnKmaT3Zg/7Jllr4qbCp16w7VqKfCt/7fxzTiHpD+824+l/xzYeHjekpLbevtid4a3qyEe88k3qmzhCEnJMfcIN17fVDhD1wLjsjJxY1e5M79ZyMgS3suM1L5qK1gmNO1qGKb3uJvmslj4cjJywadf/D+5KAtJ9o5flegNCAKgDBoUTfSxNzeoqjzwcGjZDJzXYaHWra4Ey6tluE9+APZrV0J2zl1vYyiZwODtYGugeJvSRwxAzq56CKgyRVaTQ==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	M0rORpk7GN9cEZRzEHKS1XXnHoyQ93XSsyZP4Mg+2Pw/4YkxU/CzUBgnUUd5o9zriiOmnKe+hS39yLmNVGxizymX//SsRE4Oej4iUQweQKGkoqzx4OgLWpPPTxeKi6/2PrOf+f8YjWficWmMZE2DNCKrvKavQ/mRNkpPQxZQrQ9LGX5cVkIUrQc8JQAIrt655+yE9hRP8IxFPA/7Pr6MWDx8RqN7Of3CQQ5gPqSAVJOWVroQKlYIyDz0POZqzpKBSCGUoHvFbLrue73xdNvXCeckbGv62rl9ZxqwR7JMRyGijJcw894engZAEtrh7DHnWptjUFFkjyLa80HFGPpkFdC8YBi3eB/qpIfPwLjxj/cKI1WVQ2/Y71YIZt+HsDzWUzu+NfBWGl4zRbrvZwYPXo055pEk5KRYGaP9e11TG73DRvUhL61XsOBEF0TjoE+WbmIENm0HRdVWmvP+S38XMtaAVy6ZSq4VAOM1Ct4SszLxoSQFR7HYg4grNDPyO0ewt9I3fFD9kDvOct7uliLiHXHiIuKZxtPjUPOxRJQCkjriRKuIfqYQDHA0Pl/hcFdkbN0Tki1m+TXrqACj2L5j/rs4hmVhK89qQiz+cIdHgyyIr9+T3umfXwvd+WSgSCAh
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2026 02:38:32.4014
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 37698fbd-f206-4af6-c3b0-08def4f62374
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF00022571.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR16MB3843
X-Proofpoint-Spam-Info: AW1haW4tMjYwODA4MDAxOSBTYWx0ZWRfX3xjDHc05s/a9
 8N2OSC/yW3YNiy3LBwl84FFCX+nYgb5lb0tkVIl1yPueV6xhydnXi6TFsHSAYpKPy12aJEV2i5t
 VbshUYTNqbepWltFgES8pdcfgRgAM46hQ+Gj9JkMyXcgy5aIDyuJ
X-Authority-Analysis: v=2.4 cv=dJ+WXuZb c=1 sm=1 tr=0 ts=6a7696ab cx=c_pps
 a=mOf1MaddDbw/YSD//5QIpg==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=YJXg7OVxOWrJwj3yZo-i:22
 a=VwQbUJbxAAAA:8 a=cbNQJ9GKAAAA:8 a=aJccLSbELdoR-C0BZckA:9 a=CjuIK1q_8ugA:10
 a=G69WFyCBNqGPyalROSdv:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODA4MDAxOSBTYWx0ZWRfX0VBqGGVrRB6v
 JPg6cEBCkFx3vdL+Vp1MIVMd5QbMa9V007yeFTcVqIx7t9mKF8RCM0q3fHwIqsvFyzWRzL93AW0
 ZmMxBpyPN4bAcRmI8GzQOVqJ+GWuS1TvGo4cwKjsqZeRQMq1/LfDBPZJC49TixE0mpXMcSyYRgN
 y67cGAJqNseRIO4qZ3wDg189VJqZTxbgZ/ObYHZUdNlCXiXKhqNahc83GEc76hJSSN4316sv0iF
 GnyMdzZBwuCCIgRSy7ma1bbq7P5AM5BjnSxVNCsysc26rYVECNGf+1EN/gqA5XZR5vgc35gENa5
 Ix7SiikZghbA7cjnYzaU+EYJBdVUQ0JJRa0+D9RIDL8VO8R6KKfLD24kSHK132bR6VQbyXPnbgZ
 38dbRZ5hL8SJSyFAa5L8FPOeg9s1TyTvXIY15LxP0hvfQWc9ZIZsK2JJzPi9kuPPK1pQokVa/J3
 /pnsk9mx0bPqJc+804A==
X-Proofpoint-ORIG-GUID: EIlE6y0uOYUcrdH2QAEHziZwBEFPlzUi
X-Proofpoint-GUID: EIlE6y0uOYUcrdH2QAEHziZwBEFPlzUi
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-08_01,2026-08-07_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 lowpriorityscore=0 malwarescore=0 impostorscore=0 suspectscore=0
 priorityscore=1501 adultscore=0 phishscore=0 clxscore=1015 bulkscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608080019
X-purgate-ID: tlsNG-33051d/1786156718-6F6C64E9-16307A8C/0/0
X-purgate-type: clean
X-purgate-size: 2444

On Fri, Aug 07, 2026 at 05:44:41PM -0700, Stefano Stabellini wrote:
> On Mon, 3 Aug 2026, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com> 
> > 
> > Currently there's no way to print Xen command line on the emergency
> > console for debugging purposes (e.g. 'xl' is not available in dom0).
> > 
> > Add new keyhander 'X' to do command line printout.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > v1: https://lore.kernel.org/xen-devel/20260730061459.2702672-2-dmukhin@ford.com/
> > 
> > Changes since v1:
> > - moved implementation into kernel.c
> > ---
> >  xen/common/kernel.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> > index d1bef9ac2b2b..9f334c92e3ab 100644
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -5,6 +5,7 @@
> >   */
> >  
> >  #include <xen/init.h>
> > +#include <xen/keyhandler.h>
> >  #include <xen/lib.h>
> >  #include <xen/errno.h>
> >  #include <xen/param.h>
> > @@ -505,6 +506,21 @@ static int __init cf_check param_init(void)
> >  __initcall(param_init);
> >  #endif
> >  
> > +static void cf_check show_hypervisor_info(unsigned char key)
> > +{
> > +    printk("'%c' pressed -> showing hypervisor information\n", key);
> > +    printk("Command line: %s\n", saved_cmdline);
> 
> if CONFIG_CMDLINE_OVERRIDE is defined, saved_cmdline is empty. We could
> at least do this:
> 
> #ifdef CONFIG_CMDLINE_OVERRIDE
>     printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");
> #else
>     printk("Command line: %s\n", saved_cmdline);
> #endif

Actually, CONFIG_CMDLINE can set the built-in command line which can be
non-empty.

Perhaps, something like this:

    printk("Command line (built-in): %s\n", opt_builtin_cmdline);
#ifndef CONFIG_CMDLINE_OVERRIDE
    printk("Command line: %s\n", saved_cmdline);
#endif

What do you think?

> 
> Other than that it is fine for me
> 
> 
> 
> > +}
> > +
> > +static int __init cf_check misc_init(void)
> > +{
> > +    register_keyhandler('X', show_hypervisor_info,
> > +                        "show hypervisor information", 0);
> > +
> > +    return 0;
> > +}
> > +__initcall(misc_init);
> > +
> >  static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >  {
> >      struct xen_varbuf user_str;
> > -- 
> > 2.54.0
> > 
> 


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 06:41:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 06:41:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386466.1628321 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsakK-0006We-Nc; Sat, 08 Aug 2026 06:41:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386466.1628321; Sat, 08 Aug 2026 06:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsakK-0006WN-IG; Sat, 08 Aug 2026 06:41:28 +0000
Received: by outflank-mailman (input) for mailman id 1386466;
 Sat, 08 Aug 2026 06:41:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wsakI-0006WE-He
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 06:41:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsakH-0091b7-Uk
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 08:41:25 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a76cf95-2eae-0a2a0a5409dd-0a2a4508a826-0
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 08:41:25 +0200
Received: from [209.85.128.180] (helo=mail-yw1-f180.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a76cf94-f659-0a2a45080019-d15580b4c591-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 08:41:25 +0200
Received: by mail-yw1-f180.google.com with SMTP id
 00721157ae682-81ecf499af9so3572887b3.1
 for <xen-devel@lists.xenproject.org>; Fri, 07 Aug 2026 23:41:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786171284; cv=none;
        d=google.com; s=arc-20260327;
        b=Sb6dl+QXVy3YRSDc0669Gdd5we154J9Bmi3TfZQeeeHQrzm8REsqO7/KBAO8AKxs/Y
         JVrwP/ollsKnfSCteINcoqTz3ipoMTfwJR/YfNeYwoQupoaREdNu4Rkde7+Zy3mx9hbf
         iLSjAvGYUI3Nd9lDoVYMBAAMyG70gZsDggvpk7Dtb0RDGLkCEDTCjN/AG6SjJMtEMkoB
         SkbGIdZ86aAD2NH0tQMpJxBU0boed0G8LiB1rrgWhDmhaH/hk2mv9EBgyPB0r0kpN2NL
         CME7OTMupcnH9hU9ifmPJKIzSXQ1H87Gk4CwiUFCmu4+lDYrGDDk7/0gAIBvVgRnULAL
         DYKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=brAEPTkTQJOk5s9dmGcGn0aA5cl+Wfl2BWYesPthOS8=;
        fh=gKNe9p6CUigmZ3hfEbBZPSHY3Mosr9iEmW1Mh4pK8Uo=;
        b=f4pGPcNVR1ELSiTv1/5B9HiSg7wS31Gl5H6EJUPtzccjQmUgiM142Iy9Mhs2tnglJP
         f/uayeTQk+4uKUxTCvqnWHQyo8NzTToyq6aV72S4V88ZYAgIC5QfljpFv4lr9OnoJAvn
         pO/JO4PxenvYnXGp+vV9yuaW9bHThCEr5JL+Alt7BmIT6D6NaoydZBnvUTGSumAme/k2
         NYd+V0nMwCqCzkTHGo4bjaCFHLsZzDspehBjagqgjidg96djfT5keRJ1XRGqrVBC2S/4
         so10GGazjKUejwH28BOR0o/Lw5T1rJybyZU2NIQqAc7xAV7qUbBFPvwckrf2mFUDWDMN
         a/CA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786171284; x=1786776084; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=brAEPTkTQJOk5s9dmGcGn0aA5cl+Wfl2BWYesPthOS8=;
        b=rxIXKgN/tEvlg+Ne5hGF0Dn2JgfevxaBIDCLmF+aRSNSmU3rShDDxrhb+N43+dRYUF
         ySxV6whzb5LkHVJgfeRtLknApfiaeULI5BozEORBH2SQsy22G15Rsn1Nh6JEd0rucEfK
         0P+dXDKqLcNBssyDP5rLu2gcfzRCkxL1N9q5LKO/ryDflGaHySP/CuKWd+2SdVFSsQpd
         OhETg5BpTmzAn1K7jqVqxTwIeQv0oQ1uUjbbFVIv5OOX5C6fPEDQISY4kaOXOulypLOj
         tNezjYkQzfdfsjkl+QnJ0ciFrY1O2RJ2IA2KQlayLzlzEXLCrR/bphp3FRV3VWnmu9Rv
         o/lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786171284; x=1786776084;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=brAEPTkTQJOk5s9dmGcGn0aA5cl+Wfl2BWYesPthOS8=;
        b=oOOMULCOAOfAnRX7gxYfUm8UtLZCbH+NLpo6ugSNzrcfBxCKOqadLSPiKkLaUYMmfk
         MxJZkQGIKwp9f75HyFAYaCpgcFw2bg40nI0LK/QpyLpOhdNl2eNXkTyWbXjoaBJ42dxB
         jYI44FZJpiKr//rDfeJ9bH0guP8FScuBbmE0Qc9Mli+TLDPpxbZimCV1Tt9VvyRJ9w1U
         WiCGFQi2ee2YFWH2MDm27eukXx/DpyFiBU6g6yDgM1BLdHGhfV0DdU9/tNBVEBC64zdV
         jdkkjeVGXch5VmhnzZqn2yfgkKwsgwI+0EiKQf+GEQelEkY+WjgQZwY4+Fmdfrrfc2zt
         Ochw==
X-Gm-Message-State: AOJu0Yzu+AV5m21LT6gYBgdCeOVtT9PvewK4CLDn1jhfC7QDs+3onZ69
	Rt3c04fFllgM0zjvqudEs2x5BehKR7MMrkxbFHCSHWTeoEY4C1bFRmAJULzjlAS/+tggdmD+1TJ
	Br6ofApzyD2RYjPw84mkcCF8H/v0Ohv1cdkPx
X-Gm-Gg: AR+sD11WmNWCERp1MoJeZfqYvWqNif/R67c9LAI76GcPbW6fGiXuCLAGfocd/YRQHAY
	Fwft4xEImrXzlvkuP5Nzhto77dFFuJ7UnogKrqKzgUMKrKI9Y2yuWryUB5sCpB0ym3rtAYnVXhs
	VFqxZchActqMlZbTo0Ifo2VMatj3bQyivvbjVzB3qVnwfNIowXebw5sVGrNhIUHnQVFz/rgzNiY
	D98INrW+WxBCe5kAQYQ3xJpIZ9B70eRE5PqL8iB6hnfzzn2/7YhmIGNWdZ5ON/5Px/qk+pwu5w3
	qw3IBoX/rSG5QWHwO9M51SIuC5+PDl+hT2qXUl6PuAkir0dk7uqFyZicfs97udWfviMeeQGFLPn
	Viw==
X-Received: by 2002:a05:690c:e3ed:b0:81f:d505:8ea4 with SMTP id
 00721157ae682-8202243d372mr183759337b3.18.1786171284309; Fri, 07 Aug 2026
 23:41:24 -0700 (PDT)
MIME-Version: 1.0
References: <20260715062206.328049-1-frediano.ziglio@citrix.com>
In-Reply-To: <20260715062206.328049-1-frediano.ziglio@citrix.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Sat, 8 Aug 2026 07:41:11 +0100
X-Gm-Features: AUfX_mzZA91mCnnCMSoV-jVtHsRISJpZXkdZfeKuQnapIB88c-QFN9wkflUB9TE
Message-ID: <CAHt6W4cG_-=8MBJ+7dWQrLuC2Lf-fLOHDUyGwWDGQn6=9bO1Lw@mail.gmail.com>
Subject: Re: [PATCH v8 0/4] Various patches to improve Secure Boot support
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-c1860d/1786171285-D715E87B-E74CC900/0/0
X-purgate-type: clean
X-purgate-size: 1734

On Wed, 15 Jul 2026 at 07:22, Frediano Ziglio <freddy77@gmail.com> wrote:
>
> These patches improve support for Secure boot.
> UEFI CA memory mitigation requires memory pages to be not executable and
> writable at the same time. So changing permissions and splitting some sec=
tion
> is required.
> Remove multiboot pieces from EFI executable.
>
> Changes since v1:
> - improved some comments;
> - merged 2 pacthes removing multiboot support in x86 PE;
> - removed a patch dealing with SBAT;
> - other minor changes (see single patches).
>
> Changes since v2:
> - improved some comments.
>
> Changes since v3:
> - Added Acked-by;
> - Improve commit message.
>
> Changes since v4:
> - Messages updates;
> - Clean some dependencies cause by code removal;
> - Add small commit to remove a possibly unused string.
>
> Changes since v5:
> - removed merged commit;
> - remove more code/data from xen.efi output.
>
> Changes since v6:
> - fix commit message.
>
> Changes since v7:
> - added Acked-by, all commit are now acked.
>
> Frediano Ziglio (2):
>   Align relevant sections to 4KB
>   x86: Split .init section to satisfy UEFI CA memory mitigation
>
> Roger Pau Monn=C3=A9 (2):
>   x86/efi: discard multiboot and PVH support for PE binary
>   x86/efi: avoid a relocation in efi_arch_post_exit_boot()
>
>  docs/hypervisor-guide/x86/how-xen-boots.rst |  6 -----
>  xen/arch/x86/boot/head.S                    |  8 +++----
>  xen/arch/x86/efi/efi-boot.h                 |  7 ++++--
>  xen/arch/x86/xen.lds.S                      | 25 ++++++++++++---------
>  xen/tools/combine_two_binaries.py           |  2 +-
>  5 files changed, 25 insertions(+), 23 deletions(-)
>

Ping

Frediano


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 10:37:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 10:37:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386553.1628330 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wseQ5-0006th-Vn; Sat, 08 Aug 2026 10:36:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386553.1628330; Sat, 08 Aug 2026 10:36:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wseQ5-0006tW-QO; Sat, 08 Aug 2026 10:36:49 +0000
Received: by outflank-mailman (input) for mailman id 1386553;
 Sat, 08 Aug 2026 10:36:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wseQ1-0006tQ-Ke
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 10:36:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wseQ1-00FlFN-19
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 12:36:45 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a770674-2eae-0a2a0a5409dd-0a2a4509c79c-16
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 12:36:44 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7706bb-be1a-0a2a45090019-5a9b32229f8a-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 12:36:43 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsePo-00000006Fn4-0KfB; Sat, 08 Aug 2026 10:36:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=mrC+xOT3bpITTMAExjiGGBzjrg3sW5ihiujwcUvw5oE=; b=MiHbwmDIzYwEe6BwoNHGeNjHq7
	f65veJY5YjTHd83AKNHa4qlLhl2EUZpbVBaKqJiRZbtmu20uTY06o1B9vUPmy9ooa0TSwVbO5SmyB
	Xy0GLrvdIYt0ZVf9LjZ9Y5CZGlIdKAAMhY3vBTHKxjBRud+sPw9U/bCbRI6kAK+1MRJ14Lqdn74XU
	imEjrXxYVgSdeKhaTEfdqtWfdcNVAMSL8GeyMQWoCow4VfoKrqiLLHSIhmsGgpzr51rHAAQTat189
	ObgOshNFcjyaEjVmhcISSqs8Yd6VuRoErbndkGqxAkVjftfRavz/HKtgRiucilnU6E14iBEd/ZZjN
	z8nvzx4A==;
Message-ID: <f00c9f7af1d24f833dbca0958e54cae989994ae1.camel@infradead.org>
Subject: Re: [PATCH v6 01/51] x86/apic: Provide helpers to set local APIC
 timer frequency in hz and khz
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 11:36:30 +0100
In-Reply-To: <20260806233609.212337-2-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-+oD9ig9rliifEw/S0oU7"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-bad1c0/1786185404-BF2DC034-66616C4B/0/0
X-purgate-type: clean
X-purgate-size: 9860


--=-+oD9ig9rliifEw/S0oU7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Add and use APIs to set the local APIC timer period (given a frequency)
> instead of open coding the subtle HZ math in all external callers, and
> make lapic_timer_period local to apic.c.  Provide APIs to specify the
> frequency in both hertz and kilohertz so that Hyper-V and VMware code
> aren't forced to lose precision.
>
> Opportunistically take the frequency as a u64 to harden against the
> possibility that the frequency (in Khz) is greater than 4294967, i.e. if
> the APIC timer runs at ~4.29 GHz.  As pointed out by Sashiko,
> 4294968 * 1000 =3D=3D 0x1_000002c0, and thus a Khz period of 4294968 woul=
d
> silently overflow the 32-bit unsigned integer used by most callers.
>
> Print out who set the period to maintain equivalent Hyper-V and VMware
> functionality, and in general to make it easier to triage/debug issues.
>
> Cc: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-+oD9ig9rliifEw/S0oU7
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxMDM2MzBaMC8GCSqGSIb3DQEJBDEiBCDZfXqeVG3VulW1SDf7vKX5fGconm3X
N2jFMhL1JOKjFzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIADj/qkDRDOXKU7m9R5GVeBXirw935MPsnVjsswGqUR0qI7rfbDsus
C317c59+rHUVhQ/RGvTbt9QTl6+kEeB8nPqpJWdyR7FUrMxTJruHZcYI9/6a74QSnQLgq9205z+o
DrXBGzO1WLxZFNe5uBZGUoUgSfp1gFh1jQKOr93lavH+1uuEHKOv3MNR2V/ZxtwagTvX7rMszWsG
T8auRZCEEZZQK8Nx62U4lYCn7usBnyDuR+kAgW4kcjbMDDahpdxVZKoBDNBehOoxyvWyoYjiBz8e
L8FB00fFYf8rLer7VsIPPxyQNW71hVMZQfCfyr4mhnRVhEU2E/DoyeHtk0gX1LD7Ge7cs12zyqgd
VGvamvr1MZT5Afvi629Y8yAfNIUPmKCp1mIcvyzob+5R7iKc6x1BYUerssfWqNl4gpt8qC3o6RFF
ECLljyC2cmS/EXxxA9WZimyf5/dmKwOeO+Jn2JiLd6+i3FeK60BUu0Oph/5uZ5dOD+o/RPk3IiFC
aEk+qOBVog+J++klFK7mdzacPy58SEMgWHwcQM5wRDyMJNpz51edFxxfrSLG/odY9wmI0p1mwwRx
+xgd46fmnh8z3xees84PdNwk973eSCR0oaDg5ApNb+uvCPkspUT1rlOcINqHiRivu7WCn2Ll4RH/
KYW1bIAgIYcNvvK8GmKR4aQAAAAAAAA=


--=-+oD9ig9rliifEw/S0oU7--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 10:37:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 10:37:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386559.1628339 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wseQg-0007M1-8L; Sat, 08 Aug 2026 10:37:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386559.1628339; Sat, 08 Aug 2026 10:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wseQg-0007Lu-5i; Sat, 08 Aug 2026 10:37:26 +0000
Received: by outflank-mailman (input) for mailman id 1386559;
 Sat, 08 Aug 2026 10:37:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wseQe-0007KK-S9
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 10:37:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wseQe-00FlFN-91
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 12:37:24 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7706a1-2eae-0a2a0a5409dd-0a2a4508a3d4-40
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 12:37:23 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7706e3-f659-0a2a45080019-5a9b3222de06-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 12:37:23 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wseQX-00000006Fq7-0f75; Sat, 08 Aug 2026 10:37:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=f29rvv9+wlkntIPT5Ps4cFH0UXO7Vv52XKOfUHOb+Q0=; b=D2svqsHAXm4sBiBfJCyb7jCc5/
	2wMus2zAWLXhTf14y5qyPC4zugp6/m6ba1ITEUNUoKUQbjx3piavkex81lXXz4JHO/+kzvfoKKjuz
	WwcK/33N1SB7z6NbpQ9pe3t3ae8GqEeyNrOxP4E9VRrOzW/Mo/ig3ukPpQUke9rHChYuko6251JX0
	ofhLEfsxvEh9VGdfXpONsOssRrjQ3zqdSsH7kxVdMA/F21SHMISVjgRZleSmm9JR9WXcC2nW9qXyt
	f9fp6iq0Nl5JMmnCJpS/CalLFw2DacVaSsjzq8fCuc/VRfMCGbDCli/r7hPfrM4Evg49V/If4+8da
	2S0sG7pQ==;
Message-ID: <3203fdfd32780c24eb084b6210ecbb6757ffde4d.camel@infradead.org>
Subject: Re: [PATCH v6 02/51] x86/apic: Add CONFIG_X86_LOCAL_APIC=n stubs
 for APIC timer frequency APIs
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 11:37:16 +0100
In-Reply-To: <20260806233609.212337-3-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-xuPnJagTwLip0w74n07K"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-c1860d/1786185443-D574B87B-D715DF6B/0/0
X-purgate-type: clean
X-purgate-size: 9224


--=-xuPnJagTwLip0w74n07K
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Add stubs for the apic_set_timer_frequency_{,k}hz() APIs when the kernel =
is
> built without support for a local APIC, and drop #ifdefs in callers that
> don't need to check CONFIG_X86_LOCAL_APIC for other reasons.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-xuPnJagTwLip0w74n07K
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxMDM3MTZaMC8GCSqGSIb3DQEJBDEiBCDqMNTrhIQcYeugvtTx9Nml3TBZja4Z
MoH1u5VFH23opjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIACpDMdxTrh/nlXzCRYR7RK5tgv/Hap8079kw9mZGcxh2T4wpY0E23
y7NBF1BFXOtAun11AXyLSjlLiJtXw3eaBJrlkc9y8OTY3t4FHSCEglOrHQh7hEYaJ98qcLkZnqnY
RUXjhGNpgJv05Rx+xx1TTTAdnhvjZzruuUGTAoRGNLbSuKTqFmgwwLEwMOgEG+x6oohxkjND8mQT
qgpiKi208SkPGQLQbmDKmBAT/jLjNkAUWphmht56yj3r/2i0N96GSM58zX0fa084gz4acBl2BQsY
KaLH1EK6YFSjl0XdU17xBFzyqjxx1b7iQz99faWQrjR7puDMpU3ThsbpyCOV5ctjjSINjt6vQcBa
5mC5Le5E1XkdpDiqjJghuWQN1em25UeSMN7c7LY8KUmmkDENXbKoic/vm55zijHWf/Pa9vXUHBxH
8QtPvCctx4PDHz5NKUE6Xv+LJf74aaNIVbvROMNdlqojoezkJDoKMgqwEdQ0riSa3m+vd5d1ID4B
QIAPdyHbP3IHHNswQOQYtQCsfDQ7R0h7NFeA4tWa3MQ143dHPNDRhzEjZ+V/bBrtQdXK5a8zzyx4
JW8WiD5oKkRRT9zD37uzo2rqWXnmJqIRWxj8UhEoXRchfz1SJRSveC4NhcjbzghCcCjLug52iLZy
kl915kfTy426nEBLZ+qMrkIAAAAAAAA=


--=-xuPnJagTwLip0w74n07K--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 14:40:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 14:40:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386662.1628348 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiD9-0006Wn-Py; Sat, 08 Aug 2026 14:39:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386662.1628348; Sat, 08 Aug 2026 14:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiD9-0006Wf-LL; Sat, 08 Aug 2026 14:39:43 +0000
Received: by outflank-mailman (input) for mailman id 1386662;
 Sat, 08 Aug 2026 14:39:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiD7-0006WV-5h
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 14:39:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiD6-009kza-1B
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 16:39:40 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a773fab-e002-0a2a0a5209dd-0a2a4506b280-0
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:39:39 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a773faa-195a-0a2a45060019-5a9b3222a42e-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:39:38 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiCt-00000006XD2-20no; Sat, 08 Aug 2026 14:39:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=zcSx2XSdEAVzm2aLWJJxByNSKo4VAVjMXcHmClS1zuA=; b=Opz4fZKQr5mQdoa8mNtwrphERm
	UZxNV7GFNsZh6vj3rokfMu6jtiLmubRDSITaBu8i2vMFC4BdxWrHUGnKFVKsSNOJQFB12LYt0vfMq
	dCibvfzWu9c73U4QJ3LdLjdmZ1lcxgSFnbGlX1nK3+KVAwYhldPl4TvCe3UT4aVTUFMzkjNvjN6Cr
	ZF3n0ORlBUF19jlI7BqM1Vf7pzx+rHebNIfh3nrnYOZIFE5JTfh23ZcMzB2YGkolb68Obj4BtlK8t
	fjMNEebsqkNEwhbtKuudD1/ZatUZXMZUJcJR1HqBfYhmBZEmlmLqUzeGzdHh/nPVyJ6j+n4VyoKBw
	cJC26uNA==;
Message-ID: <1309dea94c39c3eeaa09cb394abd8bf2d9b3d8af.camel@infradead.org>
Subject: Re: [PATCH v6 04/51] x86/tsc: Restrict recalibrate_cpu_khz() export
 to p4-clockmod and powernow-k7
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:39:26 +0100
In-Reply-To: <20260806233609.212337-5-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-+ggM4Pf5WdSfLKU8iKJa"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-16d1c6/1786199979-F7CCD77B-E05B8D16/0/0
X-purgate-type: clean
X-purgate-size: 9199


--=-+ggM4Pf5WdSfLKU8iKJa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Export recalibrate_cpu_khz() only for its two users, p4-clockmod.ko and
> powernow-k7.ko, to help document that recalibration is relevant only to
> ancient CPUs.
>
> For all intents and purposes, no functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-+ggM4Pf5WdSfLKU8iKJa
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDM5MjZaMC8GCSqGSIb3DQEJBDEiBCBBdQiKFmqXnTh3gQJ7xEHfosgUxTx5
vAPUivWkWYWhQjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAII6kynXVCZ++SWypAd2Klh0RLvXDGvSVylQVsLJInxyXi4zN214F
69potnIz6FJoY3TtvszmTmZHsq7eX9jR1gYLV0QvI5JXeFOjqqG8B04Hge3GF6bJjPvDFVzdcokQ
UI47DP+qc4C6Cuy+dkCvpIV0ZmEIgGfiJZyTN/Xfs++hwoAZrySxDcnxtxp6KovtQwB7xtCqqOj0
KUEWgJaLNhdb9ThuW3bn8QfeRS9cAK8WbnR/QLUNv56WR8FJjY9Ko0MVojQxcK595bSAohvHrh1d
fgnfRGA3WwlNDaE70oq4NpxQUkUwDry7dD+BaT3OPRtHV8x+lR968zhpEqvrMH+nRbVEW3mlfXoN
+XHI7iKz+8zfzU6gFD+t7H2PZSFMufuNNQeMF7D1aR85XpJEkqbXOdbwH7cuEb1xIzDjAGxJPBf2
pbuwIOh9gT14amUq0rVfvqbbCXkyWpV1mecBcgjEsM0kbVfPRC01IEY/qychxc5U08v0Ew0OTkXJ
dtL1vVzGz9w8vneB1Ny6hXPFgktpfa0HwL3CQZof7Rvoh0xJ/LBG/xBicRuuS96EPhKfDaMuB3IA
Fx42/Oe5ByXBhgdYcFcfG60qdllOIV5GB0tzjmqv4/9m9lKDoB7WVeFpenhuI3NMoftMcc2MsuYo
iNGNcSU68Vx0IK8E98Y/kYoAAAAAAAA=


--=-+ggM4Pf5WdSfLKU8iKJa--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 14:48:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 14:48:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386671.1628357 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiLk-00005H-Hk; Sat, 08 Aug 2026 14:48:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386671.1628357; Sat, 08 Aug 2026 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiLk-000054-EA; Sat, 08 Aug 2026 14:48:36 +0000
Received: by outflank-mailman (input) for mailman id 1386671;
 Sat, 08 Aug 2026 14:48:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiLj-00004x-2Q
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 14:48:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiLi-009le7-8Y
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 16:48:34 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7741bf-bab6-0a2a0a5309dd-0a2a45038ac8-2
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:48:34 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7741c1-fae8-0a2a45030019-5a9b3222a534-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:48:34 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiLa-00000006Xtt-3R8T; Sat, 08 Aug 2026 14:48:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=xY4a+9HON7tEJc6vDtf+k5V2duOaIaUpGsGxjtTbvEs=; b=rBOnKBSIfNIiJWrONCIgb0BG7F
	ylD/TZimAGdzgAEI5IcIkgHTwd38AKwrBjjDHK8RPKNMPRaT9gi1rOQtAp05FECP4gcBXxbNwzcSZ
	9K27YZmoAcmeXzFZbU20BTS3wuazn5qthvl0pxWs4WDw/ylYlQ2xWJAbT4yeFH5q1J6dotOsWD9zv
	Gw2YN5cSgII8IIvzUEpcFxm3DuG52OAn33VXMWJ3hERGDovRuCgWlAPGLJEZdsGJpRpaPO5YFDLS9
	DRRdXewcmsvVBmteeZFBT4Cgu1Y+bg5IWGwaCxnEw4fvEWMHCdYIM/mH9CPBQhK2PprWvfr/4eohc
	0wwE4hEA==;
Message-ID: <58d4607c93e72094d0394c09c976142e7e179cb5.camel@infradead.org>
Subject: Re: [PATCH v6 06/51] x86/sev: Don't override CPU frequency
 calibration for SNP's Secure TSC
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, nikunj@amd.com, thomas.lendacky@amd.com,
 x86@kernel.org, 	linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, 	virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, 	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:48:25 +0100
In-Reply-To: <20260806233609.212337-7-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-2WHVA9tRtaaaro8+TEvx"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-33051d/1786200514-75A814E9-A0852725/0/0
X-purgate-type: clean
X-purgate-size: 10036


--=-2WHVA9tRtaaaro8+TEvx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Don't override the kernel's CPU frequency calibration routine when
> registering SNP's Secure TSC calibration routine.  SNP (the architecture)
> provides zero guarantees that the CPU runs at the same frequency as the
> TSC.  The justification for clobbering the CPU routine was:
>
>   Since the difference between CPU base and TSC frequency does not apply
>   in this case, the same callback is being used.
>
> but that's simply not true.  E.g. if APERF/MPERF is exposed to the VM, th=
en
> the CPU frequency absolutely does matter.
>
> While relying on heuristics and/or the untrusted hypervisor to provide th=
e
> CPU frequency isn't ideal, it's at least not outright wrong.
>
> Fixes: 73bbf3b0fbba ("x86/tsc: Init the TSC for Secure TSC guests")
> Cc: Nikunj A Dadhania <nikunj@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

I don't think I care about Sashiko's complaint. Even if we still clamp
it in generic code, I think that's better than having those in the
platform-specific code.

--=-2WHVA9tRtaaaro8+TEvx
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDQ4MjVaMC8GCSqGSIb3DQEJBDEiBCCQubn/jFA3eSBfXv3QWaqzwBRRhkIm
IOwbMGknJhY/TjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAffxk/dqrhP4HMbv3HB1zGSpyStJ1EN+hO7+2zJd431JlQJq9VWW4
3vGaA3GFtSotn2ZYoZAGBd54XyqIbzafd0AV3MzDJGn1GU1rbYPIHEjnuF0pysFI+gSl4aRiHrOI
GubT6zS8vJxttEIOXf1QRzl5NK/OMXiAik6SSimZo+c0e/dRM9wYO77QSGx53XW5NVKPIB8u1r6H
xNHW+CA5qDIRam5Q+xk0juc0RZxaCnMJbWdmB9rDk3iVY+dv5gv28S2CQtOhfXIZx2i6q6C38bKd
jmxZ6TtEWOgvqpQkwT0uH+r/AaB88xVUK0ywNaj1lRSx861QTwNsyyC2HmexOL5ON2jVN8nm5tXL
l7xDZ4vWogvwguJ1sp8pnW85snUD0ngU5ANvdIZoUqi6rvgDrLWSZgOuc6i/Ka0cPdd+mhp4wJYd
IHSOY564LDqmU1t3MoBbWxchW/UvYUOM4uU4uvaIZwsK1gFG/LTA9CnOoyIrvCawEPaxuFZsVMxS
hDl1qqxQt9XtJJBiFN8gfcR1oUStsWwFxKX4g2hESwRn+pY+5mLYPTbezB5ZyH05xXlbzYMVfpdA
gtSY8/ATfqNHJGFtt6UqvfuSRe/8gMoc6WwJlQb5d8TsTO+Oz7V548z2X3fFOkVtfiaU0IQ0480b
ebvE1iHCFgXC+N29aIfPgLEAAAAAAAA=


--=-2WHVA9tRtaaaro8+TEvx--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 14:50:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 14:50:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386678.1628366 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiNU-0001bj-S4; Sat, 08 Aug 2026 14:50:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386678.1628366; Sat, 08 Aug 2026 14:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiNU-0001bc-Oi; Sat, 08 Aug 2026 14:50:24 +0000
Received: by outflank-mailman (input) for mailman id 1386678;
 Sat, 08 Aug 2026 14:50:23 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiNT-0001bS-5N
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 14:50:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiNQ-009lvu-17
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 16:50:20 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7741e1-2eae-0a2a0a5409dd-0a2a45029296-38
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:50:19 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a77422b-6ca4-0a2a45020019-5a9b32228bcc-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:50:19 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiNI-00000006Y8K-1AmE; Sat, 08 Aug 2026 14:50:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=bnJWUG/JPui2uKucDdDHwnUhtYzLmNsoiXZpYxk9nBU=; b=XTFvbD+5iS6pcriqXmD8agcern
	2FWv3Ir1GasPqGWKF61v/VQd6u2VdUgnlRwC0CcW6lzrEk8qKHOS3F10tdhT3WYBAXA2hb5XBNHok
	bFLrhfZbt41DRqScoE19op5dRHSpEuwAo+yDPi4a1JpUBMVMKRhTOEYvUbAjaKLiDQWgHQjVVGx/g
	cAi9Q9g+iOCA1tWwOzgfN/5xZo3zRtfebUDQP2MNsYwdRKmusewzwtnJTPBsnvEuN0aUEibgi5Skh
	fUpO1VmwLCDPjl9S4jB5tjFamBmVI2sA2tGjGpPR1UoH3nUQ/zYtpO29WBFHHPMNW+UDk0FXX7zKK
	XtRCOGEw==;
Message-ID: <0f3e31008c86e07e020dbcdfc5a279ab76498695.camel@infradead.org>
Subject: Re: [PATCH v6 08/51] x86/sev: Shove SNP's secure/trusted TSC
 frequency directly into "calibration"
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, nikunj@amd.com, thomas.lendacky@amd.com,
 x86@kernel.org, 	linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, 	virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, 	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:50:10 +0100
In-Reply-To: <20260806233609.212337-9-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-mi0iPdDBicy/0pphTprS"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-720697/1786200619-F32B12AC-D4C1D000/0/0
X-purgate-type: clean
X-purgate-size: 10550


--=-mi0iPdDBicy/0pphTprS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> As a first step towards dropping .calibrate_{cpu,tsc}() and explicitly
> defining precedence/priority for "calibration" routines, pass the secure
> TSC frequency obtained from SNP firmware directly to
> determine_cpu_tsc_frequencies() instead of overriding the .calibrate_tsc(=
)
> hook.
>
> Unlike the native calibration routines, all of the paravirtual overrides,
> including SNP and TDX, are constant in the sense that the frequency
> provided by the hypervisor or trusted firmware is fixed, known, and alway=
s
> available during early boot.  More importantly, for CoCo (SNP and TDX) VM=
s,
> it's imperative that the kernel uses the frequency provided by the truste=
d
> firmware, not by the untrusted hypervisor.  Enforcing the priority betwee=
n
> sources by carefully ordering seemingly unrelated init calls, so that the
> trusted override "wins", is brittle and all but impossible to follow.
>
> Explicitly ignore tsc_early_khz if the exact TSC frequency was obtained
> from trusted firmware, as per commit bd35c77e32e4 ("x86/tsc: Add
> tsc_early_khz command line parameter"), the goal of the param is to play
> nice with setups that provide partial frequency information in CPUID, i.e=
.
> is NOT intended to be a hard override.  Neither SNP's secure TSC nor TDX
> was supported when commit bd35c77e32e4 landed back in 2020, i.e. lack of
> consideration for the interaction was purely due to oversight when SNP an=
d
> TDX support came along.
>
> Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
> Tested-by: Nikunj A Dadhania <nikunj@amd.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-mi0iPdDBicy/0pphTprS
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDUwMTBaMC8GCSqGSIb3DQEJBDEiBCBXwFXXgl/z9qBpWUhMcnA7RIlh7ihZ
bd+UGk7JfRe7djCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAAJnHOpJupW9mJZGzq/kZvUu4BPry95maA6XY7JFXlHcdvpFIPkBc
j6z4VU1YqlFRNpDCyMzjzucpoF6y1OsLeM20pTRwDp5uQFb8XnCyyGFRPjcAaPO5t66piomh+5nT
+1K01m6O3Pk9jb9akYiq8l1YjMvCOhRnNb19TV+W33ZanaHloNUxNpFHSMCbk7lm29XRAlj4gcWI
eMYiF54O/PIGrzoS4S4Pcda0IaqsQvLzC4nQFV3DOOnh8Vyx6hasMqffi6z/dECSBWIlkM2Tr0+Y
FtwdtnWAZvoNMrxI63dmkAUAWjWgb8fIHttZGvJxVyrZkDbk7FfDtESnyclNgJ7POmFzcxj67tmI
ZNsLhYdlS2a4qz+rcPfVcsDG1NfQv5R8q9xZ7lj6WxgHQdMgFwyYxRVZpN8PA114ywECvKXfJSq/
WrZsgW9imgpB0xa5uDTO7RCDhLnctmlqsQoWpq8hArSn5liJ2zWeD+KislrBAOIk2445l3ciJAVS
ZPFwl8gotWgmUgRIGW6CURWQFBjK2CgPKNEhiEl2EMgvz93uEt2BHmbV9ACmqvNl52HIW5zT9uFt
SEedWaoPTUw+SHT47gZPbre9HSPx56N5EH0TcROiyi/46oaxBY0k3mqvRlshxXhOK1PyMc06a01A
CvZEvf56ddFQXuDGNuyMrM4AAAAAAAA=


--=-mi0iPdDBicy/0pphTprS--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 14:54:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 14:54:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386688.1628375 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiR6-0002HY-EU; Sat, 08 Aug 2026 14:54:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386688.1628375; Sat, 08 Aug 2026 14:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiR6-0002HR-B0; Sat, 08 Aug 2026 14:54:08 +0000
Received: by outflank-mailman (input) for mailman id 1386688;
 Sat, 08 Aug 2026 14:54:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiR4-0002HL-Vt
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 14:54:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiR4-009mCq-6P
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 16:54:06 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7742c0-8faa-0a2a0a5109dd-0a2a4504a59a-38
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:54:05 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a77430d-b57f-0a2a45040019-5a9b3222e7c0-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:54:05 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiQw-00000006YJq-463R; Sat, 08 Aug 2026 14:53:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=Cuh+2guypgME3E5tPAMft+l41S7Z051cLycWAT64MZc=; b=KvnfyU3Kg+Hyujh2eKk8oY/xbS
	AWycnumVzq2JvmDw3H2xzJa7LvtAG2SLujPf8ebnAmlYv/VsGtvSs3wpeNL7ayKVAxPPqElMyIJko
	U44CufxlA0UUnsperbJHSupH+gpofgP1UCW9i2OBfzSOa5NrLm4WS6Ax0O4fPYn2+th94CJfDbuPs
	3wl4u5tKMYlIHHqSB1dKSjrrVK/jYFzrqIUAT8f/OjvqjTrqH2iH3kFRpWZkTsNc5CYyQMuEj6/13
	Xyv1qVAulf5sk3wfXHTi6gQV83zct5cCkUVVefEKGJ6/B4xRIH8dApgUX9dVLLdHsKv+5AX+HoLje
	AhoVhZzg==;
Message-ID: <b8c0e3537904e29f233cbb03f4d3ddb5247e2af7.camel@infradead.org>
Subject: Re: [PATCH v6 10/51] x86/tdx: Force TSC frequency with CPUID-based
 info provided by the TDX-Module
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:53:57 +0100
In-Reply-To: <20260806233609.212337-11-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-t9ptKw29GmA8+P6aeY7O"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-ebf023/1786200845-50EDEB50-A5B25CBE/0/0
X-purgate-type: clean
X-purgate-size: 11230


--=-t9ptKw29GmA8+P6aeY7O
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> When running as a TDX guest, explicitly set the TSC frequency to a known
> value, using CPUID-based information, instead of potentially relying on a
> hypervisor-controlled PV routine.  For TDX guests, CPUID.0x15 is always
> emulated by the TDX-Module, i.e. the information from CPUID is more
> trustworthy than the information provided by the hypervisor.
>
> To maintain backwards compatibility with TDX guest kernels that use nativ=
e
> calibration, and because it's the least awful option, retain
> native_calibrate_tsc()'s stuffing of the local APIC bus period using the
> core crystal frequency.  While it's entirely possible for the hypervisor
> to emulate the APIC timer at a different frequency than the core crystal
> frequency, the commonly accepted interpretation of Intel's SDM is that AP=
IC
> timer runs at the core crystal frequency when that latter is enumerated v=
ia
> CPUID:
>
>   The APIC timer frequency will be the processor's bus clock or core
>   crystal clock frequency (when TSC/core crystal clock ratio is enumerate=
d
>   in CPUID leaf 0x15).
>
> If the hypervisor is malicious and deliberately runs the APIC timer at th=
e
> wrong frequency, nothing would stop the hypervisor from modifying the
> frequency at any time, i.e. attempting to manually calibrate the frequenc=
y
> out of paranoia would be futile.
>
> Deliberately leave CPU frequency calibration as is, since the TDX-Module
> doesn't provide any guarantees with respect to CPUID.0x16.
>
> Expose and use cpuid_get_tsc_info() instead of providing a wrapper to
> get the TSC and core crystal frequency, as TDX is the only anticipated
> user outside of the TSC code, i.e. adding a helper to dedup the math won'=
t
> actually dedup anything.  Having TDX use "struct cpuid_tsc_info" also
> avoids the temptation of declaring a local "tsc_khz" variable and thus
> unintentionally creating a shadow of the global "tsc_khz".
>
> Cc: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

I don't know if we should set X86_FEATURE_TSC_RELIABLE before bailing
out in the case where cpuid_get_tsc_info() fails, or just not care
about that because it Can Never Happen=E2=84=A2? Previously it was set
unconditionally from tdx_early_init().

Whatever...

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-t9ptKw29GmA8+P6aeY7O
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDUzNTdaMC8GCSqGSIb3DQEJBDEiBCB128CVBJN8xuT3FiKKePSSmD1dGYDR
PbTRvv3V0qPdhzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAONQVsVqcQyHMNv3ndBzrZgpCILyQP+t1HaHjvmV8XwFE+1n+c6wZ
5kxata2TXbey92bUtsTg6WpP4/A56MFfNWaTRjFxxOS0ZeWWsryymaD1XDpdHdhWpOZPUfdq7VWm
ctAXsM8mdlD2tMk/L7KYvgx1WsdEGiE+ZKtTlMmZjuxCkOGMh07ZbhY+dzm7VJk6ybiw+D8R57hu
BLcjmDEhLbxIs/MWasr6lY9NXe4qyMmRcT4L9f+ppQ+t2QhcZ/MktdHhop+YXdl2K1oRzvUU7SHf
Vpf7t3taxR2mrqscOxwmu4E2s5Qi9CQGJ7kvEuE+FqKfTjjcusg3jZ0VMItrxNR5lLoAx8MZ9PTD
xUMNUJzhDE2Crh55kbSkkEkfxz1mILKWBNhK7+tQ+7mXIi/8fJ+qzUE0hW4kLV4A7iU1PS8pAF8p
pjYPlVws/cqXhoj2iEaT8SAT5aICcXZ+LWq3lmZKSPhTvls4l5oKfsD2Sx3Jy5OtTshtwV8HRsU3
tXmsaZxeq2vYQVIvDGy6IoNvUSfK67W23VCWaVINNRgRok7Qd0paFBZz2OTwgU5fEm/LAUlQe+1s
3SOg6XMHVDD61w/MDzNmbysf9L6bH795bXTEalXqwhR4qd51LhACF09ku60FvSWPbgUdTE+f/rvE
Exg5EaO7qp5P7n9DQ5PyO44AAAAAAAA=


--=-t9ptKw29GmA8+P6aeY7O--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 14:55:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 14:55:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386695.1628384 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiSX-0002qR-NL; Sat, 08 Aug 2026 14:55:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386695.1628384; Sat, 08 Aug 2026 14:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiSX-0002qJ-K5; Sat, 08 Aug 2026 14:55:37 +0000
Received: by outflank-mailman (input) for mailman id 1386695;
 Sat, 08 Aug 2026 14:55:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiSX-0002qB-2I
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 14:55:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiSW-003ngs-Bw
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 16:55:36 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a77430e-bab6-0a2a0a5309dd-0a2a450cd2ac-24
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:55:35 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a774367-f479-0a2a450c0019-5a9b3222a388-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:55:35 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiSN-00000006YVa-3vur; Sat, 08 Aug 2026 14:55:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=9ZmoEJU8Nj3R7GEBPZuKKQOrDJ9kwjJLRhMvX9eg2b0=; b=qJnOvhH/oom5NnirTM1L3sqRet
	zFy6+LaUk6eYcTvcX776vouIX3Nf3O+yd9Q4oxOXRrt3y7NfCMk4gArdnMLxdVZTpnP68AWbUF5DB
	zc7NOWZS42fketVNwBjHe6GRIGAIv/JxbK38FwAK9iu15FChMR+PBll/RDaQidTWi2LKz7z7iUD0e
	3IrdyOVumQ6UC8zb0+WKukb+yb3wM+eY3DZboLvHuvSJfw9KWQo/swQCBB7uW35Rnvy2fDG0wcPOO
	v7DzUoGoCgbe3/quqnGwJ6G1W3fTY6gObp0ieJ81dufGHnoXcU4yhekVl3jsLTp2sfPosHVYctUvV
	xv8gXpuQ==;
Message-ID: <91341b40020a6c12c380651f2658897d3e4c6345.camel@infradead.org>
Subject: Re: [PATCH v6 11/51] x86/tsc: Add dedicated hypervisor hooks for
 getting known TSC/CPU frequencies
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, mhklinux@outlook.com, x86@kernel.org, 
	linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, 	virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, 	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:55:26 +0100
In-Reply-To: <20260806233609.212337-12-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-rqA7MqJn6IlGbHYL5W9W"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-d25034/1786200935-034D7A5B-5809F31A/0/0
X-purgate-type: clean
X-purgate-size: 9971


--=-rqA7MqJn6IlGbHYL5W9W
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Add dedicated hypervisor hooks for getting known TSC/CPU frequencies
> instead of overriding seemingly generic platform hooks, and explicitly
> prioritize hypervisor-provided frequencies over native methods, but do NO=
T
> clobber the frequency obtained from trusted firmware.  While shuffling th=
e
> hooks around is arguably "six of one, half dozen of the other", scoping
> them to x86_hyper_init makes their purpose more obvious, and allows for
> explicitly defining the priority of sources (as is done here).
>
> As is already done when trusted firmware provides the TSC frequency, igno=
re
> tsc_early_khz if the exact TSC frequency was obtained from the hypervisor=
,
> as attempting to refine the TSC frequency when running in a VM is all but
> guaranteed to cause problems sooner or later due to the calibration sourc=
es
> being emulated devices in the vast majority of setups.
>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-rqA7MqJn6IlGbHYL5W9W
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDU1MjZaMC8GCSqGSIb3DQEJBDEiBCBXj2pOn7w99V9/APxOjyywOoy1tNze
sBNaxAitVZEENTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAkLLvuDi2xErhAXmhGRxhKl29cHidfsYNi+OvY8o/YUo20MCbwkOf
Y0Wldj9/dOacpxTtEp218iwxL3Y/45pYGTaBXv+PjgVn+Epet+g8T7t78DhaX+FZ/13VpB30The7
f+v/V+mvS49kI/4EG7NDd3B1LSVgxH1eYRXvakdAP0o7R7lAz9eEln5j6lKi4s/33yK3iwRo+dmc
Fsm9oGVP7Jyom1aZ6gkm0Tuf1ZFmDjoPdemkXQblVXahYM8JiR4PXUkC75ANioqfF3G6u/qpbaxc
U/g8hhJMlcnjhZaBgxkZby2K0i094zvRrcZhbJaMtM2VWU6FODUTS0z0chxbpkFAT2eUaNRipZcM
KsJYWe6SHfIXoa+TGeBd3gvBfEaPJFzFl0WNb0G8xeMjvVg0LqhVaLg2DVMPCSZbB7nqZf62+t1Y
eHyS+QGunPqYXkWgYGrULorsiz0AhgiARJr7Z6DMc8YD/Ecy1LX2F0eSQ0v0AiDZ9kYYQIBFbpHZ
LGPBPXjGFhisUoNW+RYzOsFuiZKtSpzb+zpEp2gYDR8nioFjd4zih3xmXLQ7/xNvfhcbyibGNbPC
XVK4j6hKT53M+636FeKveRHYpFQon4cUH9qAbrOzdZg6AzV08g1Q7cOgD+WsYxNm5DQm4W4TTJJ8
mPEnWr/Iz/Fi0iFJQu669ckAAAAAAAA=


--=-rqA7MqJn6IlGbHYL5W9W--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 14:57:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 14:57:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386703.1628392 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiUQ-0003SD-1k; Sat, 08 Aug 2026 14:57:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386703.1628392; Sat, 08 Aug 2026 14:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiUP-0003S6-VS; Sat, 08 Aug 2026 14:57:33 +0000
Received: by outflank-mailman (input) for mailman id 1386703;
 Sat, 08 Aug 2026 14:57:32 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiUO-0003Rz-I8
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 14:57:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiUN-009cCv-Jr
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 16:57:31 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7743ca-8faa-0a2a0a5109dd-0a2a4505d93a-14
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:57:31 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7743db-4cb1-0a2a45050019-5a9b3222846e-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:57:31 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiUH-00000006Yb7-1FD8; Sat, 08 Aug 2026 14:57:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=goIfeKepOMWSzakf5pw+sPdIm1bWS35DFpCXt8MSupo=; b=p96FcflViCat4ySTi/DsnOVH7Y
	OWUql4bbp1fOAfACeyXPzIVujSGn405GbbS4XQTkAqsF2Ee2T3pBBDM/RwsgjvCGdvcrF62P8k0Qv
	+j0ziw5KY27pi7xiKTjKBHqJGqJUTI7cHxBZwd1MEbOC+nCwFEHpdO8vxU01ELVLyu8OMc/Y8ttSG
	ujZwU5OWZiUa3FHl7UNQi+aMTAE82JTY8X0rEd6tzu7d0ZC1W9/fXWcXDZhB/kwgIqRJF5yrXMls/
	TH8GVTZh9RgDpqvMF4ddigrlzTvF0XLyvNWVpLCLIGTBZFSJ02e6EbcP1NxXxgqxlylWlBkd2y9h0
	4VFw87uA==;
Message-ID: <890afcaebda8688d5b642e312da2c27a3731354a.camel@infradead.org>
Subject: Re: [PATCH v6 12/51] x86/acrn: Register TSC/CPU frequency callbacks
 iff frequency is actually in CPUID
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:57:23 +0100
In-Reply-To: <20260806233609.212337-13-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-Y57aRO+CU11wowyiP33M"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-c201ff/1786201051-72AB72A1-5598AD23/0/0
X-purgate-type: clean
X-purgate-size: 9273


--=-Y57aRO+CU11wowyiP33M
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Register ACRN's TSC/CPU frequency overrides if and only if the exact TSC
> frequency is actually provided in CPUID.  This will allow marking the TSC
> as reliable as appropriate, and avoids relying on the caller to handle
> "failure".
>
> For all intents and purposes, no functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-Y57aRO+CU11wowyiP33M
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDU3MjNaMC8GCSqGSIb3DQEJBDEiBCBNe8sZhW1r/oYnm1j0YO2K+/rjRNSD
8xlcT1C2Jk9SWjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAxo9YW8AOod7cWia03OVU4V4JE2q4NqDOHa+dlXSm6gdzeweMYKJT
bgDzyK6WOJMYCUmmLylQWR2E7EAZE8WMaCblt5YcZL725mGJjcnTnirsJ6dGUR14Ml+2TcucWFoD
tmk7T5bV+6r5DQRvRJCVqNb3enFVlBsBgFicBwUTCtoFsco8OTd7pK3z5INuUMPCfST6/u2rAE4i
f083BhwEJx2DtefyoF4z55pXibZltA9HCcjNTj5DwuWgq16Tygmn/R1A3M6+OZof1WTBY4gM9big
C5j3MeXrDgKw0M0umhybNRMbIHN5be/SwlZg5Cgk73f4Swz8Ww5Td6gc6kfvzhQNeVfDt2m5vyEf
jJeKijtinMX5UibLbHr+CVTWX/dF5C1/Yo/ShXNoEyXNEbMO/TTduFAs7HUN0Xh8Ph8Ab/4Q5Voa
zu31O1OapaIo1ab6s26WguagVWDoQlsKw3N3FFAhU6Czzt5/39ewzAvTaTZFUOOVNnToa01jrH2x
QC7Bs3ALzWfOMVMqXk+5zTAStTjV0PzvU2FJBvdxDMO42f8MzADaC5PHVyIB9FvVKJ3niFe/iKq6
Pte0y22JM/UbGSu3Ut8EkrAMnY9mK8N02l20fZ7e4LWq6wiPUsjQC81/lfM0HNgYl6J25KULmMBA
zS/JkQqcCXwG9s8K8lOlLcYAAAAAAAA=


--=-Y57aRO+CU11wowyiP33M--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 15:01:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 15:01:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386716.1628401 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiXm-0005Cf-Ic; Sat, 08 Aug 2026 15:01:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386716.1628401; Sat, 08 Aug 2026 15:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiXm-0005CY-Fz; Sat, 08 Aug 2026 15:01:02 +0000
Received: by outflank-mailman (input) for mailman id 1386716;
 Sat, 08 Aug 2026 15:01:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiXl-0005CS-BF
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 15:01:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiXk-0019mN-OU
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 17:01:00 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7744ac-e002-0a2a0a5209dd-0a2a4508c1ec-0
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:01:00 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7744ab-f659-0a2a45080019-5a9b32229dec-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:00:59 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiXc-00000006Yv6-3MY3; Sat, 08 Aug 2026 15:00:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=c4buHOPZ0bv4R4NaEGhdIQQVpZl513kZ0VUZz72Z6nQ=; b=idGrWCohNRmBgA/YGZOQqJxDsA
	k3wQhrj0VjDBMG8JodKxYbYtLSGI/kmklqklDXk+DXeCeV50NV43iFpkW8y2PSr9WvW7Jrhwwvgrz
	VxzS1EQVP0o/gk087C8CXi5i34Y+xLX0UBpSz4d1hvvTVXkAm1gC+jbWE+LMfyFcN8OR9dBEX6I+I
	ndK7de7kJSwGsyuVrYgo6LTi1uB4bIjFoE+Dl59NSdmrqbrSXXfmUX9F+ZcRQofgOWgS+mTBwRcMU
	ogVkhgo0HacPcds+kv+1mOrhrU2h5nsSVpwH0LzXeK/6rFtcu++iFfns+JQT27PeoCXa0fYqsSQPl
	+VWnLgog==;
Message-ID: <ce799a0b5dd12d80ae0d75e85a7e965199060059.camel@infradead.org>
Subject: Re: [PATCH v6 14/51] x86/tsc: Consolidate forcing of
 X86_FEATURE_TSC_KNOWN_FREQ for PV code
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, mhklinux@outlook.com, x86@kernel.org, 
	linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, 	virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, 	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 16:00:51 +0100
In-Reply-To: <20260806233609.212337-15-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-8/mRcnFKKGOky2orgg6e"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-c1860d/1786201259-D5F4787B-156574D3/0/0
X-purgate-type: clean
X-purgate-size: 9570


--=-8/mRcnFKKGOky2orgg6e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Now that all paravirt code that explicitly specifies the TSC frequency
> also sets X86_FEATURE_TSC_KNOWN_FREQ, replace all of the one-off code
> and simply set X86_FEATURE_TSC_KNOWN_FREQ if the TSC frequency is known.
>
> Do NOT force set TSC_KNOWN_FREQ if the "known" TSC frequency was provided
> by the user.  Per commit bd35c77e32e4 ("x86/tsc: Add tsc_early_khz comman=
d
> line parameter"), one of the goals of the param is to allow the refined
> calibration work "to do meaningful error checking".
>
> No functional change intended.
>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-8/mRcnFKKGOky2orgg6e
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNTAwNTFaMC8GCSqGSIb3DQEJBDEiBCDTAZMeDB5NUudSa1SgH3uYEQRYZrGc
iAMarKDxBeHsjDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAgFQM/AN8fHVMioNBRlOChv5+9L+91ZtiHLMzRfe74UjeZTaBnrEW
l8MjDT9KP3yloTgeGY1Kq+GMQdc9yWNZ2IEi7SJfJ3GXwNFG8ci6jRxjX4/GvzHZPQoY5Ylzsvzi
lNjngUSINtSTrMWk8vfWl9Da3hNH+Mcr7XB1ycn7ci7jOQamSQ/5vyazW7P/AZLHdcXmMsTt0p4+
HKMteIKaavmItYrj4GSJo8f104PNWrTTIgmEzXfWAscqY3XKIfKnHTa0amZX5MkT04frZ8ePCltp
3CofcDopJzT5e5VGh3ALgOjyceW13n7naBVUxbj5JlJ9uWm9FBw5D++xasvBlx//MypdExRZqPAw
mi62dTv6A1ukCivEwjQUMWvUqlqbvcFRcl0kHf9khvLzSD/gsBEBCqTP6eszoZWG/YOKYC9ap1Ih
I+eHmnksk5EfzOMxKU9679sGvS+daA4LtNUqLAsF5C0Hj3LFLgTkM+g8LqOMlU22amqRDukl02Ls
NyPIDP3ip3epzIixnD5/bxxTE2FlYHglsv+zE/Wr84HMccfvPM7mSru68wSA/bSf7xWQuz3xQI3N
rOTTpwKkynO83J6DoX2cJsCugLO8seIXuID6KRQO1dLGPKRQPp0+ibMi3dips3kXm3HAn4gVzUNZ
o+BkaAi2Rel3KHiQvNzOB7oAAAAAAAA=


--=-8/mRcnFKKGOky2orgg6e--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 15:01:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 15:01:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386723.1628411 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiYc-0005gQ-Qt; Sat, 08 Aug 2026 15:01:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386723.1628411; Sat, 08 Aug 2026 15:01:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiYc-0005gJ-O9; Sat, 08 Aug 2026 15:01:54 +0000
Received: by outflank-mailman (input) for mailman id 1386723;
 Sat, 08 Aug 2026 15:01:53 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsiYb-0005g3-9h
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 15:01:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiYa-0019rA-Mn
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 17:01:52 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7744c0-e002-0a2a0a5209dd-0a2a4501b2d8-24
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:01:52 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7744df-5984-0a2a45010019-5a9b3222d77a-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:01:52 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiYV-00000006YxH-0R1J; Sat, 08 Aug 2026 15:01:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=cHemq+R8kBm2N1D7zG41iiZY974/e28EH+HY3NEkjlY=; b=RQl6FO1TyeVj01qXv3h/XfhhJx
	dAHGFabC35mI/v7f6ZF5yH+HKPBOeuP/bWSBVFV5as4PSm1Bv8io5zjFliFY0HcIylgKGiHaC748n
	zu9G33Xwug60AG3WOjt2XjSME+LG4diie634BCniVnH1TVMNv2fbzCzsFf8oNNZDe6AwxB6pBZ/1R
	p24TokgsZ2p0tkHnytpq5r6cCg+Q/byy6DfZuj8jh3RxuE5Q3IIJz5ucstMPbT1hyxOfCnCMH+1W6
	dLkKOEN7clgBbyoNP5OHrVenrk6iCo/mr+l9IkUlE1t5n2u1m6JWn9JvaL1ZfHw/7VSutADt9Rpqn
	n2jjdCVQ==;
Message-ID: <8cdb54e0c25494e9574559d858a81916cc461863.camel@infradead.org>
Subject: Re: [PATCH v6 15/51] x86/tsc: Kill off
 x86_platform_ops.calibrate_{cpu,tsc}() hooks
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 16:01:45 +0100
In-Reply-To: <20260806233609.212337-16-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-pJV6LuA8JirWt+CeIJA2"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-d62444/1786201312-1E27A757-3F0C0830/0/0
X-purgate-type: clean
X-purgate-size: 9423


--=-pJV6LuA8JirWt+CeIJA2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Now that getting the CPU and/or TSC frequencies from the hypervisor uses
> dedicated hooks, drop x86_platform_ops.calibrate_{cpu,tsc}() and instead
> directly invoke the correct helper at each phase of (re)calibration.  In
> addition to eliminating unnecessary code, this makes it a bit more obviou=
s
> when the "late" path invokes pit_hpet_ptimer_calibrate_cpu() instead of
> x86_platform_ops.calibrate_cpu().
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-pJV6LuA8JirWt+CeIJA2
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNTAxNDVaMC8GCSqGSIb3DQEJBDEiBCD6U2t+qvpPAReeHMywFnP+Wc79R2Uj
KxqBjf4L3+z40DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAAy3K89cKEOtHZsOjH0NMIQUudmikHtnnYwiYb4UJ2XjXJt1UOcWy
bt9n7ZC4GFpOjb8SbQ8pcL2H7+QL2SvmrOnzxk/+k4Q1gf1xTAk/veIK31v1K74zzsM7vxBue7lg
4K01P7Dqei6rlTkS+tX4E/C95L9bC2SGgk8E72GWfeAKvywnIc8MtJXhIk7l958gY/PFPIzcUOj8
TMWGz2CKMdvMGlCUD4d0sJAjxZKHfHunykJDVzJsyjB/NH5oTXndyvmqZt/S9Cuk1Pxl3PR0ipGX
nAC1ieRnd9rFGgMkmSuNo+S76vaNTNsYXx5ubha1gSfBOLAIbNFc3wrksW0oriE/U7cJeec0ePXr
9BlD26Q56z/grlOSwUCP3hMmGUiymPZbj2rI626kexeCleFFszCQnJQJ57YQujNY4HGEInWpwGGc
Bk1C8zMunpNRKBshfQKM5hJ78yg5PwiMQED8jwqfN0YZ+Xi20GcjUSeS/vnhAa4ICp+n+B35P/IS
RQzo3I47LKoHzGhLSqtrLaehP5pzoxsVlz/Gvbxj0lWZ1WKcVu9ZI/VhbQacslUKk0x/Pkti0NkU
tyJKN+pgCpBZyet6g+e7ERgeqAJzJ6/BSve5aa4+wF/K4rEEJRt+7/bcG4bUdCpqTMfOJtrzTnm6
SnNxS0tHcFCE4mXozVOfHnMAAAAAAAA=


--=-pJV6LuA8JirWt+CeIJA2--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 15:02:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 15:02:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386732.1628420 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiZb-0006B6-37; Sat, 08 Aug 2026 15:02:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386732.1628420; Sat, 08 Aug 2026 15:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsiZb-0006Az-0D; Sat, 08 Aug 2026 15:02:55 +0000
Received: by outflank-mailman (input) for mailman id 1386732;
 Sat, 08 Aug 2026 15:02:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wsiZZ-0006Ap-CG
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 15:02:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsiZY-00CiCT-An
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 17:02:52 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7744fd-bab6-0a2a0a5309dd-0a2a4505913a-22
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:02:51 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a774467-4cb1-0a2a45050019-5a9b3222b638-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 16:59:51 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiWX-00000006YkS-3zRH; Sat, 08 Aug 2026 14:59:46 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=cjqV/irGmZd8w6lcxaSK+6WNSve4cl+1LpivEBexyMQ=; b=hJpYeLKwSuZ8Qt4awuG8YSOdQo
	xVSJPwo++/8O48Hidkh6qkd4vfwndvt5tv3FsleZzl/6+hsZ9miZQNetemQqNScue7dAL0AePNPk2
	G5b1VSuOTXNHIdHIB9DCctSB5NyYM97seEvg1RZ0Z2DTElK97RQXOhYfeIxxa+oAxBSk2zHLkSq56
	1iN0lU8zLe/+6oKFdHzMMO58Of+Nfcy2Ek466haCQ97dxvgd6ch6EwMBfCi5JIUlVt88T1follGIr
	si/DBu0pJpIh10OdJlEfXZzm9YBO9v7aQpUwIm0IEA6B7lY05B3UmAL1QhYnkvSncyNu2BFhf5AjY
	JL50e9mw==;
Message-ID: <d0ee3cf97854b904323db3799e05117d065a6ba0.camel@infradead.org>
Subject: Re: [PATCH v6 13/51] x86/acrn: Mark TSC frequency as known when
 using ACRN for calibration
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 15:59:44 +0100
In-Reply-To: <20260806233609.212337-14-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-swfj4Wc+2w/NxQrUPIhf"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-c201ff/1786201191-F44A42A1-38606B23/13/0
X-purgate-type: clean.bounce
X-purgate-size: 9335


--=-swfj4Wc+2w/NxQrUPIhf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Mark the TSC frequency as known when using ACRN's PV CPUID information.
> Per commit 81a71f51b89e ("x86/acrn: Set up timekeeping") and common sense=
,
> the TSC freq is explicitly provided by the hypervisor.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Huh... does this literally get reverted completely in the very *next*
patch in the series? Kind of weird, but I guess in some ways it makes
sense...


Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-swfj4Wc+2w/NxQrUPIhf
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNDU5NDRaMC8GCSqGSIb3DQEJBDEiBCCLHDsVEr47QLniCvl1BHh7jULcWyP1
JFbCuD+qwvoPNzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAR8KWcORVTZQasIgxPzemsBTyXMobtaBuoDyuKdNegOlt6B+9r/34
lQPmQzpYXE2c+M0nMbA1C0t8XTSPGRQ6pbu3enjsm6Etlto/EFiyfkZDZok4WFauDbalheV1+gRj
p8HmX8Nfp5sv5Ou7dwCk7Lh8mJcuH+4z4jyIKyNKJOVMuQVG26Pc0r6eoQP1c49xGbSzuJ4ntzl8
ZSwSUQKulQtOhOYo7qtctV2sdsb9c4cuhUGZLtIJy2nO7qflZKDQ7+9HEZR5t8KesfGpykHuHweU
kYqIbShxhI14dCTVeVey+ijIatUBBghH0irBc50ML5mxiH0z0T4tsFIITE5Pocpd7oNa7KmKEgVs
RjDfd4sggGjWXRM33apHgvLK4Y1PjlhqnkgaIas3Q4GrCyOiuMsI8yAoRIHmyS3jN3d4UqULiYLh
6RRnFiazWuzuEMwjo9qdJabZ5A/4FCcFFsborS0n8Tqlo6/54ohHwSMmDIp4ZctOH+SofAokgqZM
Usz5v+HDUnM5pnF89Q3YiWIcAj45mVI8fhxqsfcsv0VLQ82ljqkOa0X7nh1CIOWcsoHtI9VlRbZt
pp45qlJKWW2wO706FStcVF+doACf1LiRgmI8KuOZdZhXDV1lFfdkBq+8ENFdyUTh87arS/jLshbP
L9KEvoOBTrQ3mDfQa9VMYCoAAAAAAAA=


--=-swfj4Wc+2w/NxQrUPIhf--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 15:06:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 15:06:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386743.1628430 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsico-0006zW-LT; Sat, 08 Aug 2026 15:06:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386743.1628430; Sat, 08 Aug 2026 15:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsico-0006zP-Gc; Sat, 08 Aug 2026 15:06:14 +0000
Received: by outflank-mailman (input) for mailman id 1386743;
 Sat, 08 Aug 2026 15:06:13 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wsicn-0006zJ-9o
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 15:06:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsicm-001ALT-Mx
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 17:06:12 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a774581-bab6-0a2a0a5309dd-0a2a450ac5a4-40
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:06:12 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a77452f-f2d2-0a2a450a0019-5a9b3222c3aa-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:03:12 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsiZm-00000006Z4O-0oAc; Sat, 08 Aug 2026 15:03:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=Wa7Hzq2JSx29IaNuU/muzEjzSoG8OuGbp+agE00B49Q=; b=rmnS9mZpeKjdGdBlUegOL51BkB
	pKn5oJgOcQodQGcg9eGzYS2wFJKM/KZYTLkRAEyutqxfbi+pYDyPRfMgJhLYKI+EuWlRgRoRyYfNc
	gB9wfCiu9XDZZY5sijChUtaNjzq/Hizp3Xi21sQmf8gP5yzKSs1ZrH+tu0MvunYWQFsBl61TOp7wa
	1NMeK9CQnYQPVKHz+rLmD0X0f42m9xhYRZt6G1ylOv/6rQBcCOCAiCVJxtjJdOOJjA3rlyb8iempC
	QZ+0RuqumEp7/7WkG25rcVsZk2rQU1EaGpdE73GctG0VJeeEsQLb+QQ3YykGJVWsaRKaTqcKcQBfY
	6x4NhTqA==;
Message-ID: <b3bdd75b8f22b5c10f834c09e0231b9c10ded250.camel@infradead.org>
Subject: Re: [PATCH v6 17/51] x86/tsc: Fold native_calibrate_cpu() into
 recalibrate_cpu_khz()
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 16:03:04 +0100
In-Reply-To: <20260806233609.212337-18-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-3h8ypXMqBwC7mZwWnyZO"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-4011c0/1786201392-591C5CFC-C4802DC2/13/0
X-purgate-type: clean.bounce
X-purgate-size: 9297


--=-3h8ypXMqBwC7mZwWnyZO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> Fold the guts of native_calibrate_cpu() into its sole remaining caller,
> recalibrate_cpu_khz() to eliminate the extra SMP=3Dn #ifdef, and so that =
it's
> more obvious that directly invoking the early vs. late calibration routin=
es
> in determine_cpu_tsc_frequencies() is intentional.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-3h8ypXMqBwC7mZwWnyZO
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNTAzMDRaMC8GCSqGSIb3DQEJBDEiBCDwb5m5oE9xtGsjsdRmZNgxK62hdyL4
WC3aSn2DOLO7iDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIACx2XiWqoOsyRHJvHYpRHx2KK8aqyfD7+x4R0BLQ0PVFMU3qilduU
RfgooqwW+L0+Gv6dMwsC1wlZipXcALB+wp+0tK72qgMitY4A/SYQa02Ycy80m/CldZhFh4ntn6K3
EzQXz2sg95KiE+0JgNYZJXY+92ur0y8i/3qRPcZWZW7fwiASskS3RX5+o9Pz0u8HeaA8MMHe647A
wpw1qBKUtlBrUidL7AMOG9kfbBC3g2bOrKdGgmPT59OKny0rnTYjXrSEmlvOBz7YDidbEGSwOTHT
EUfFzCME58zSPxiGE86zuIfIrs+vOnKqjwbQWZO65IFJYqiAGiqoUWkTOxdS9l8rlfah72m+Y/Lu
O+XDzCujaGwZ4XpTf5dhM1sojJNDx+syG1ColZz6SkmFroS8UPSGna7qMMtNWyXxU9okHTVcVQgL
uLdFMNY2+rn9ImFgfsG8eC4c2wDRuBDmvVbSXBsji4kmKfDlnpw43G6dCpuLYv8rbLz5Cct6PcAB
S005/n00xCdXREcIxwzgkWKhUBw7dWhlvbGRq6B0qxbRZtlqBAuZ+5H2lzppx0tVgUEUw41qKEXy
tBQMmFNP7HsDhb7B9l8kn96VPVC+xTzU+c2hA9icEM3N/G5nCuTPcLP/kB2rxA31Zt30G3ii9rAJ
eqD95h+YeobJ1DGZJK81JbAAAAAAAAA=


--=-3h8ypXMqBwC7mZwWnyZO--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 15:06:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 15:06:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386752.1628438 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsidG-0007R9-RW; Sat, 08 Aug 2026 15:06:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386752.1628438; Sat, 08 Aug 2026 15:06:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsidG-0007R2-O8; Sat, 08 Aug 2026 15:06:42 +0000
Received: by outflank-mailman (input) for mailman id 1386752;
 Sat, 08 Aug 2026 15:06:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wsidG-0007Qs-4W
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 15:06:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsidF-003ojO-Hl
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 17:06:41 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7745f0-e002-0a2a0a5209dd-0a2a4509ab24-6
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:06:40 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7745c4-be1a-0a2a45090019-5a9b3222ed76-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:05:40 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsicA-00000006ZIm-2rcE; Sat, 08 Aug 2026 15:05:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=k+OamkYrv2Q/1Mc6CsMtTvPptfqZvc3HFc+EwxszCfc=; b=hlYPBpotHaB95aCGdAYb8rWrKG
	KNI9+ZVShJ4Ay6zxwsOUpNJWjPvdGkEG9NwAn5zoMv/eGYSvR8AsXsfffEJnoQQKlLgd8Qnqa+OuU
	mNBgEL6qPs8Sy5mGvzbmNMGWGa5UTCuk+md58+H01r5jM5AK1pWT0DaOtuNRDOHr73p7f1P0IZ0M+
	o7WyiBkfKf5TLyq50c7Vf+G/sgGEej2IoI5tPmWAxAiqI0RBo5N6/54mpQLYJZRAVwIPTw6oNahu9
	5zcqtF1+uci6tRLFYlZNAc25hy+I4btFu/um7mbNPifcJ2HzQC9bkx4VrQuxV6KOmh0d9aHxfdQv7
	GcrajjZA==;
Message-ID: <91c9ca8c1ab7f3facc12fd7a033d79254d4a181d.camel@infradead.org>
Subject: Re: [PATCH v6 19/51] x86/kvmclock: Drop dead check on TSC being
 unstable during kvmclock_init()
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 16:05:33 +0100
In-Reply-To: <20260806233609.212337-20-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-jL4BIGsiNKeXF0OKBwg7"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-bad1c0/1786201540-FD86F034-C11D5310/0/0
X-purgate-type: clean
X-purgate-size: 10053


--=-jL4BIGsiNKeXF0OKBwg7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> As pointed out by Sashiko[*], kvmclock_init() runs before __setup() and
> thus before notsc_setup() or tsc_setup() can mark the TSC unstable.
> kvmclock_init() also runs well before tsc_init(), and even before
> tsc_early_init().  Simply delete the check, as it's been dead code since
> it was introduced.
>
> Note, odds are good the check_tsc_unstable() call was copied from Xen's
> xen_time_init()+xen_tsc_safe_clocksource() logic (as so much of KVM's PV
> code was).  However, xen_time_init() runs via x86_init.timers.timer_init(=
),
> which is invoke from x86_late_time_init(), and thus after params have bee=
n
> parsed.
>
> Alternatively, kvmclock could register itself later on, or tsc_setup()
> could be parsed as an early param.  Given that there's zero evidence ther=
e
> was any meaningful intent or need to actually check for an unstable TSC,
> go with the simplest option.
>
> Fixes: 7539b174aef4 ("x86: kvmguest: use TSC clocksource if invariant TSC=
 is exposed")
> Link: https://lore.kernel.org/all/20260529181213.0B27A1F00893@smtp.kernel=
.org [*]
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-jL4BIGsiNKeXF0OKBwg7
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNTA1MzNaMC8GCSqGSIb3DQEJBDEiBCBPg/28/nMAA7kD8KB7YWidZV5ltXud
WC5ifsuEkfezqjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIA0VHY3rUJsG/wBPTSPREp9yqeyqejmyR/heT+mqB8BWh225fhd04z
ioB0PkU7vEaPfZcTY/8jq/iJWAkLqQrFJrkPoZOdQ0ahcn5xe8H+dPFK8qaZ93V2rKJ1wIl9/Uxi
bsJs3B2GFpvGnsppMORG5oYNiqz1VZcT6o40tKq5Z5UyehSaMmb5ZBRdq4EMo7dgF2WpAlLllQsm
aM5GYWUhFjUMD0MGY5HWWLwL08otRfdVO+QrMGgxV6Kq3I4VknD5cVHj9AWbWFWoQMfurpoL53Ua
ggqemoRyZCctjEMwcGa0mldjBFzt7O44GEqcrQj/sulmDwZT4r7vsB2aR+RdgeMqODtpUSFrfCKN
y1FGIIY4ya0vyUZ7wnNj9Om5iTKEa/mCTvWUEzA/blotqYzgXQTEPekqB7y/fDgzvFW/Y3AnU+v5
srizsBxsxt9SBKLre1D3DFheyAM0hqwMONtqf+udkfLTYx46gveIE9diCSUlNWXMb8AQb8e/4OU1
81mzeXpMe4DHVsd0veZZ+/DQNa6gnh7qnDzvWln7ZE4OPUDxIt6/ZPWFoUUDVHwdAl0fQAgM5E3Y
v+BY9BVoViYVBRC69H0YKScpNOOF00/QgKLRpGafit9TWGdrVcJ5YS9V3YXkiahKAAyi4aNV4Eqb
ArTRJFANS1EAwPtGmF7Q3zUAAAAAAAA=


--=-jL4BIGsiNKeXF0OKBwg7--


From xen-devel-bounces@lists.xenproject.org Sat Aug 08 15:10:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Aug 2026 15:10:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386759.1628447 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsigY-0000dO-BE; Sat, 08 Aug 2026 15:10:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386759.1628447; Sat, 08 Aug 2026 15:10:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsigY-0000dG-62; Sat, 08 Aug 2026 15:10:06 +0000
Received: by outflank-mailman (input) for mailman id 1386759;
 Sat, 08 Aug 2026 15:10:05 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wsigW-0000Md-Vs
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 15:10:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsigW-00Cip4-8D
 for xen-devel@lists.xenproject.org; Sat, 08 Aug 2026 17:10:04 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a774658-8faa-0a2a0a5109dd-0a2a45038e70-18
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:10:03 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+fdab5150087f7d84ce52+8385+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a774617-fae8-0a2a45030019-5a9b3222aae4-3
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 17:07:03 +0200
Received: from [54.239.6.187] (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wsidV-00000006ZMH-1xgd; Sat, 08 Aug 2026 15:06:57 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:In-Reply-To:
	Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:References;
	bh=5/jyAha6D+U5zzU3W+cCpJ3j4Z4I6ySL2lxtV4bdMdQ=; b=YoP6gRksn/p59tVjUCAEqmph19
	weP9rQo8AlW5WV2KQS0n5f4YHgiz2Pl+8aPdOGfzFhagy5y5Ssii1oWx+2ScxbgznxW9qpWhhA/0A
	ajwu5drZGj+3XNpCbCT46fXxUbrOlkD2uJ83sZVbE1SzC7/Di1WJW6k7VapxZ+2HdMQAaQlznVIEV
	+UQAWE1PdzjUoASLyv+2+mTRbnshLC2mqyc36EQJN0F4qjxxBpnPX2O1viAXFperEWI4HRTjeTjR6
	xIeK1PAAwGivwf9G5AboB23MahXCwnXhFTAhLz7GC1wb64934IM9q5kZI67h4UKuWxz1s50LqEWAp
	oaelbJ3g==;
Message-ID: <908a4fd0ec4498c907decfd105e1662fb4ce19eb.camel@infradead.org>
Subject: Re: [PATCH v6 24/51] x86/kvm: Get CPU base frequency from CPUID
 when it's available
From: David Woodhouse <dwmw2@infradead.org>
To: seanjc@google.com
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
 decui@microsoft.com, 	longli@microsoft.com, ajay.kaher@broadcom.com,
 alexey.makhalov@broadcom.com, 	jan.kiszka@siemens.com,
 dave.hansen@linux.intel.com, luto@kernel.org, 	peterz@infradead.org,
 jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Date: Sat, 08 Aug 2026 16:06:56 +0100
In-Reply-To: <20260806233609.212337-25-seanjc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-5qVG4UC9E8Q5nQrvV8Pq"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-33051d/1786201623-6E2D04E9-01568F36/13/0
X-purgate-type: clean.bounce
X-purgate-size: 9427


--=-5qVG4UC9E8Q5nQrvV8Pq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> If CPUID.0x16 is present and valid, use the CPU frequency provided by
> CPUID instead of assuming that the virtual CPU runs at the same
> frequency as TSC and/or kvmclock.  Back before constant TSCs were a
> thing, treating the TSC and CPU frequencies as one and the same was
> somewhat reasonable, but now it's nonsensical, especially if the
> hypervisor explicitly enumerates the CPU frequency.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

I still don't think I care about Sashiko's complaint.

Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>

--=-5qVG4UC9E8Q5nQrvV8Pq
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MDgxNTA2NTZaMC8GCSqGSIb3DQEJBDEiBCAkPGP3r5uT4tS4OGDg5LaRCyG2yz/P
/Lwudtzg4ZoebTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAuRtAu48d3cDEH8Yyruawqxjo+2bBjXqiN17kaxj+u6IcLAW0Nrdo
nzxRSU7g63188lVFEYlyVH1mR8e/jnhuLNbISNodetQLsVn48QsKDnvjTf03Qg8EfWMW2Q9XPflg
ujjMSLOjY+oy5TCeXl1MiYwiYhOnWAMOikQybdXiN4yKyu8d7Gkydo8xr8ru8/a0TF2KKhfu3I1d
2xkI268NxH6+Cv9y5+bGCHzpe9uLgPsEbl59gRqxfxGFniNgDb1s9nmrA0sHNkZ8USM/MDh/KsrM
qWJWvxLIurJ+Xn7Y9irqlMbA+JP7v6yMYDH2QAHMvxVpw4iaIo0L7UCAFb37/HI6YK7Trdk1GJgF
HAshq0ZDzPYkkNFl3HBbQldIf4Jy3Eu8QiizlbiiDOvp4HqKCgS0bnBtcjHtx86Ord4r/mzm04qY
8HDk7icEUoMyxTMJlntkJCEtLvBfQ0SkEACFQmxcXDqaI/EqUzt4YuNYdo7Tp2GAeCyYIDdDMI4H
ELDUg1Q+jdabA45cKulihQLMEC/5aOkrJGZaPeSwx1uueapFNBUUHdSwIMeXuUdrjVm9IcLgum3c
YfU7Cd9T4E0dqkggIiLcvkwBSeKK4Ev3lDN6cNSSNzRRQbWp8aMqd6eIh5r9zVWMgsJwnB0UEjBs
snTppZI8KQqD0ALD+ClLQUYAAAAAAAA=


--=-5qVG4UC9E8Q5nQrvV8Pq--


From xen-devel-bounces@lists.xenproject.org Sun Aug 09 01:04:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Aug 2026 01:04:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1386894.1628456 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsrxU-0005uA-Ii; Sun, 09 Aug 2026 01:04:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1386894.1628456; Sun, 09 Aug 2026 01:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wsrxU-0005u2-Ds; Sun, 09 Aug 2026 01:04:12 +0000
Received: by outflank-mailman (input) for mailman id 1386894;
 Sun, 09 Aug 2026 01:04:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wsrxT-0005tw-VG
 for xen-devel@lists.xenproject.org; Sun, 09 Aug 2026 01:04:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wsrxS-00DY1u-Mm
 for xen-devel@lists.xenproject.org; Sun, 09 Aug 2026 03:04:10 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a77d1f4-2eae-0a2a0a5409dd-0a2a4501d6f6-16
 for <xen-devel@lists.xenproject.org>; Sun, 09 Aug 2026 03:04:10 +0200
Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a77d208-5984-0a2a45010019-d15580b6a9da-3
 for <xen-devel@lists.xenproject.org>; Sun, 09 Aug 2026 03:04:09 +0200
Received: by mail-yw1-f182.google.com with SMTP id
 00721157ae682-81e6f2ee60bso46448447b3.1
 for <xen-devel@lists.xenproject.org>; Sat, 08 Aug 2026 18:04:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786237448; cv=none;
        d=google.com; s=arc-20260327;
        b=U9DIo9+dqt2Bo0uacPSOf4OmnTbwhmIzG+r3MXzkhj1U/jv8fq9S59LbA2tSz/Nr7x
         yc00w1C6N7mpjUXJke0V6VcCpLa0Dl33FwbyxvGp2mbfCU6G5i9pWQnX2pC5eWLpcwVB
         wc+5h6OVFZWr3QS7oxgIXbtdF+b1BytR35MCxY8ez9NYQksGO7dntuHmNhtrLxZCHXgA
         XP46mldXpjn6dCetfk2wkcYZXS0egeKx3uM5oY4KYbJObNKmR/q+gKFVN9MEzCTYgRb4
         u6oQWxhpoo8blkkvz7Etg/oPJVGgTFUTO0cHaDXrT8gQLI4CMiC1k6Phrd2dg/EhyAr6
         40rA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=/ooYtvOl/yrpSWjC6UMdC3vC8WtM8ahkSkG9Lt94FP0=;
        fh=A7KicbXY4441il0jhjM7233yohb6a4hGn+JPZkGjASc=;
        b=HCK0nIn5dJIsqxCNBoaCl+Tbypf+sjRDvFCSDbPxPu5ykw+h/ZcoqtVbBFsgXejD4c
         CPCpYMPnthSOt1hnNs6eZJgW3FA+qkkgs0pLefGNa82nvKSBaD+C1v+gOjS1yk45ZUzR
         5PaTI5PRx+B6pjX9rOnJXYfgxmuLyHXqVmg5CZG9wt2Ty+3Mr+KA3CGOEVy8Fl4T9WE2
         oA+OxqobnJf5R2P+dFKRGTFzKZAn7x2dwb1cc0GIxFvyXqNOFeYQHe1ax7jp3cXse2sX
         sigGL1V6hr4VOybs9X8oVIgOkfGUohHqDaMwXTsOWPo1FCvrsMR2PXQbNWn/LbpwDIZ3
         Nz2A==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786237448; x=1786842248; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=/ooYtvOl/yrpSWjC6UMdC3vC8WtM8ahkSkG9Lt94FP0=;
        b=JeUTH5XoBZ/8ZEH8/whm25A9Cze3n3Fqy0k7Z+RmtnMrkWUHUSdrIbnPfV3KTftY7K
         xVAPplCVzLln0l3RXqeTCUWoeq4MsBOB/VMZZlbTdjTGY+L0CpNdJhmP/Sdd4nuny+Mo
         BQ+bskDzHm0AfaVYyccg/9prXeRohhF0/a/SvZegFH584mijtaAN3UVFSIt6c7TRaI7t
         +ykxN1fxkB2KKeqVDkJ4BoQhSSy0PpKH+CxlJPo6+6isW2J/QB4NFDtosFSd/gwDy3bi
         udnFD6FzdptL+BDec750YXG3HQxk0FTF3p2vBzQ3E1XnoL/E0R+OQ9tPvVxjTKmoqXVC
         Z2iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786237448; x=1786842248;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=/ooYtvOl/yrpSWjC6UMdC3vC8WtM8ahkSkG9Lt94FP0=;
        b=Tw0sDXPXqmE74RqGS3jaNS/MxuCNq96ZXQ6m3eKlisUMVCgpSIbJXYZb2pCgdYjaKJ
         o2G4A481ncBSCT0CZ89P65E1GOy7PdzK68m+6bwI2mslvD7GO9oiUfkEejk234QAKBK4
         vsEzoAm8LJlZz1Tf586oeNz7wAe2XPg8jCA86olwKSGUIdk8R+iX/4o3SkrSkLq1l2F9
         eRozKbrDPjctouAmg7Mj0nGtRqheaBB4RTjdwzHIhOamcnWhFnKU8nh20ZEkImh36O4N
         x//bkaPUecI7LlIwsoUgz5K03yC2p4on1o7QWhWPiIGhsGNKkjkh6Hz89evq4oEGYHD3
         LgoQ==
X-Gm-Message-State: AOJu0Yzmrtvks2fmnCChHfSuYu2lSCgUruxVt9uhtBHqdCSihKNQzJ6N
	BgKtLNt9b62+zW7tt1adW3F/g3wnPEBU+YmUdALSMqe1VVvtmvalhjG7qQmNkr1PW/PFUWlniTK
	F7usyGLpI5WiekhpTzjLbgX8GhMd86CQ=
X-Gm-Gg: AR+sD13FmIxRxODsp5dFvVLlmN+1kFlAEnsuqzrfjNej/zDgAbKzPwH8h7pjJeaheW+
	yOrRWKCv2BEG18DD8iDuoY1sXBf0t4IPo5+TYJ5InmwTEKAVFrmJNO4TUGyBDRGt5pym1BKkANu
	xWAwvuFJD1D4tYzDYBs0ApwEg0/5qC6PZqpEcgEuvGZ02fIBLORft2aTCG/atrayGJeyuC/y5QU
	fS/F5yBzm1wQZk21QSd1H3/SyN+dOpAOMJA2jrakW+injrn3NYvz+dUecweHRBzw7CbPW4J7QKX
	hUYR4sIZXmos2h7SjxwesZzrIaOc5nn45upXmYRpys+nMoCN4vmBc/0Bu0Lp6redA5rrFZsRuth
	s
X-Received: by 2002:a05:690c:d84:b0:826:9d78:a0cf with SMTP id
 00721157ae682-8269d78a480mr35873217b3.9.1786237448260; Sat, 08 Aug 2026
 18:04:08 -0700 (PDT)
MIME-Version: 1.0
References: <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
In-Reply-To: <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Sun, 9 Aug 2026 02:03:53 +0100
X-Gm-Features: AUfX_mx9bSVYxMwwHMrbKF5yAn2YZdvWOCF1zck5pvGNc3a3_Tsf6-V73c6L2Ok
Message-ID: <CAHt6W4dEqeaO9Q2u0n4CLN=hvi8T-_XedHC_tmrdYgC6sMGmjw@mail.gmail.com>
Subject: Re: [PATCH] public/xen.h: Update comment on mmu_update sub-command
 size and PTE alignment
To: Teddy Astie <teddy.astie@vates.tech>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>, 
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, Kevin Lampis <kevin.lampis@citrix.com>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786237449-BE867757-15D9DBB8/0/0
X-purgate-type: clean
X-purgate-size: 4229

On Fri, 7 Aug 2026 at 22:29, Teddy Astie <teddy.astie@vates.tech> wrote:
>
> HYPERVISOR_mmu_update passes a set of request, where each request has a pointer
> to the PTE along with a sub-command.
>
> The PTE alignment padding is used to transport the sub-command while the rest
> is used as a address to a PTE entry. The current documentation state that the

"an address"

> 2 first bits are used for sub-command, hence the other ones for PTE which
> imply here a 4-bytes alignment on PTEs.
>
> On PV64 and PV32-PAE guests, all pagetable PTEs are 8-bytes aligned, hence
> off-by-4 PTEs addresses are always incorrect. Non-PAE PV32 guests used
> "legacy pagetables" which had 4-byte aligned PTEs. However, support had
> been completely removed since Xen 4.0, and were only available when Xen was

"was only available"

> built in 32-bits non-PAE mode [1].
>
> Current Xen logic behave as if 3 bits are used as sub-command, thus all

"behaves"

> off-by-4 PTEs are actually rejected as being unknown sub-commands.
>
> Adjust the documentation to match the current logic implemented in Xen,
> also expanding the documented sub-command parameter to 3 bits.
>
> [1] 84d54d5d8b31 ("i386: Remove non-PAE hypervisor build target.")
>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> This happens to be a complete rewording of [2]. I'm not sure what to do exactly
> regarding the signed-off.
>

You should use them both.

> CC: Kevin Lampis <kevin.lampis@citrix.com>
> This now expanded sub-command field can be used for your "unmap_page_range optimisation"
> series to avoid having to introduce a new dedicated hypercall.
>
> [2] https://lore.kernel.org/xen-devel/20260528075539.10209-3-frediano.ziglio@cloud.com/
>
>  xen/include/public/xen.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 2149b8dd38..b4fef2c5ba 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -218,16 +218,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   *                     x == 0 => PFD == DOMID_SELF
>   *                     x != 0 => PFD == x - 1
>   *
> - * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
> + * Sub-commands: ptr[2:0] specifies the appropriate MMU_* command.
>   * -------------
> - * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
> + * ptr[2:0] == MMU_NORMAL_PT_UPDATE:
>   * Updates an entry in a page table belonging to PFD. If updating an L1 table,
>   * and the new table entry is valid/present, the mapped frame must belong to
>   * FD. If attempting to map an I/O page then the caller assumes the privilege
>   * of the FD.
>   * FD == DOMID_IO: Permit /only/ I/O mappings, at the priv level of the caller.
>   * FD == DOMID_XEN: Map restricted areas of Xen's heap space.
> - * ptr[:2]  -- Machine address of the page-table entry to modify.
> + * ptr[:3]  -- Machine address of the page-table entry to modify.
>   * val      -- Value to write.
>   *
>   * There also certain implicit requirements when using this hypercall. The
> @@ -264,17 +264,17 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
>   * pagetable MUST not be in use (meaning that the cr3 is not set to it).
>   *
> - * ptr[1:0] == MMU_MACHPHYS_UPDATE:
> + * ptr[2:0] == MMU_MACHPHYS_UPDATE:
>   * Updates an entry in the machine->pseudo-physical mapping table.
> - * ptr[:2]  -- Machine address within the frame whose mapping to modify.
> + * ptr[:3]  -- Machine address within the frame whose mapping to modify.
>   *             The frame must belong to the FD, if one is specified.
>   * val      -- Value to write into the mapping entry.
>   *
> - * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
> + * ptr[2:0] == MMU_PT_UPDATE_PRESERVE_AD:
>   * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
>   * with those in @val.
>   *
> - * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE:
> + * ptr[2:0] == MMU_PT_UPDATE_NO_TRANSLATE:
>   * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
>   * page tables.
>   *

Frediano


From xen-devel-bounces@lists.xenproject.org Sun Aug 09 17:46:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Aug 2026 17:46:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387126.1628465 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wt7bW-0006hh-Uw; Sun, 09 Aug 2026 17:46:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387126.1628465; Sun, 09 Aug 2026 17:46:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wt7bW-0006hZ-Pp; Sun, 09 Aug 2026 17:46:34 +0000
Received: by outflank-mailman (input) for mailman id 1387126;
 Sun, 09 Aug 2026 17:46:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <agordeev@linux.ibm.com>) id 1wt7bU-0006hT-RN
 for xen-devel@lists.xenproject.org; Sun, 09 Aug 2026 17:46:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wt7bT-00F1qH-T7
 for xen-devel@lists.xenproject.org; Sun, 09 Aug 2026 19:46:31 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a78bcb8-2eae-0a2a0a5409dd-0a2a450ccd8e-10
 for <xen-devel@lists.xenproject.org>; Sun, 09 Aug 2026 19:46:31 +0200
Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a78bcf5-f479-0a2a450c0019-94a39c01e0a8-3
 for <xen-devel@lists.xenproject.org>; Sun, 09 Aug 2026 19:46:31 +0200
Received: from pps.filterd (m0360083.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 679FW1sE3277678; Sun, 9 Aug 2026 17:45:49 GMT
Received: from ppma22.wdc07v.mail.ibm.com
 (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fwvq94twx-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Sun, 09 Aug 2026 17:45:48 +0000 (GMT)
Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma22.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 679HfJG7012053;
 Sun, 9 Aug 2026 17:45:47 GMT
Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230])
 by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4fxf5vt2bb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Sun, 09 Aug 2026 17:45:47 +0000 (GMT)
Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com
 [10.20.54.104])
 by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 679HjjQR34275656
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sun, 9 Aug 2026 17:45:45 GMT
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 0842520040;
 Sun,  9 Aug 2026 17:45:45 +0000 (GMT)
Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 7C40720043;
 Sun,  9 Aug 2026 17:45:42 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.87.135.220])
 by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Sun,  9 Aug 2026 17:45:42 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=1V46XsJ2ASYOMqPQa9NRG149ty7O7K
	B1wPG7dfwq0b8=; b=UabY2i2O0DFebgnB5Itk1pRi3/Htbxgsnj9zfMhYyXAq+k
	yF4QkmQIRPAjVGN5n1TRYRA93L73U7SajNdDfI3dDHHhuVPIhOocLrBCQRPGo6fO
	zRUesLej41tQv0v/OKC288JhXJxpOKbIav1Tz2cpvXyghY1uWfY3xJlpLdnQWSkO
	g9By3jcVfZdNthUqy8R7s35WFAUQpmZ+ICuM5XKofi9TBR9lWHWDncMDr7e2p4Pd
	ahAwkkpqBsFsqnU9UxNpc/YeN9/xorzOtztL+lqAorMkbJvqxaDn+ti/Ykb1NS4P
	GkIfLBl2FlcgU/0FYB7OxhPqwp9WpNOjoazF1Vnw==
Date: Sun, 9 Aug 2026 19:45:41 +0200
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Tvrtko Ursulin <tursulin@ursulin.net>,
        David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
        Dimitri Sivanich <dimitri.sivanich@hpe.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
        Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Muchun Song <muchun.song@linux.dev>,
        Oscar Salvador <osalvador@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Liam R. Howlett" <liam@infradead.org>,
        Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
        Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        David Hildenbrand <david@kernel.org>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
        Uladzislau Rezki <urezki@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Eduard Zingerman <eddyz87@gmail.com>,
        Kumar Kartikeya Dwivedi <memxor@gmail.com>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>,
        Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>,
        Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
        Christoph Lameter <cl@gentwo.org>, Mike Rapoport <rppt@kernel.org>,
        Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, pfalcato@suse.de,
        ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
        linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
        linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
        linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
Message-ID: <4a42c498-58ca-46f4-819f-da14cfba154f-agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-2-usama.anjum@arm.com>
 <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
 <eef14e97-20cd-4b08-ae22-7636af049b09@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <eef14e97-20cd-4b08-ae22-7636af049b09@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: ehRYw8QMBCJQ6XIfQUmc1xOZ8VBocr8y
X-Authority-Analysis: v=2.4 cv=PbDPQChd c=1 sm=1 tr=0 ts=6a78bccc cx=c_pps
 a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17
 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=7CQSdrXTAAAA:8
 a=7ZejAh3qsUrew3BXsuMA:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODA5MDE1OCBTYWx0ZWRfX8PAJydAF9Sdz
 7Q3LQNawdCCW5p3S9Cbrhno/+8i0akWT9oxXen6S0nUhBQsH880/7RsGl95VX21rT54x9YhFqi1
 20KERD3HCbwvoqxx4T70j96cVKwA2YxlZ6l2xOFcmMWRehBEI40oNe5oKbokVHGzUV8t5ZkpMSK
 ns0C/90GTY6G7Afmg3i4iWKGKI/x2MSzhpkhUmia4LUS0tqD/uSG8uJudCOs75ncoAMtIyBtPts
 SBc2vAEfXkhI2UuaiCwcdAwFVnvK8EgubcrGc/SgeNggiVPjDgs5qWQ8+vOIPtcC9cEpr02poOB
 Lg7APmO3Rx8vA6tguusRIZ4Fs8vWJdm8vnK+m2H0UOB6WahoA26KXbJqrB0927hzkoKT62s0AOf
 RGde2c8tcj7xMXKNQULCZu1ZlHt1NIVwRcJ45XzbncbVNxXZWhcoK8gsn97hT6hSSx+Fo3N5VVF
 ELeKceQfHYIaUoeswKw==
X-Proofpoint-ORIG-GUID: ehRYw8QMBCJQ6XIfQUmc1xOZ8VBocr8y
X-Proofpoint-Spam-Info: AW1haW4tMjYwODA5MDE1OCBTYWx0ZWRfX40Jd01nPAYq/
 0UVJDKsUAxNz/IYIJFjnAhSgQRETCQqeUcuCeVy3WJaqKm5o/wyOjpQIKh0TKZ3HawAxontKM5X
 Anm2JSFRi6CK3bLpHrJPHohn6MgFj5w=
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-09_05,2026-08-07_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 spamscore=0 bulkscore=0 impostorscore=0 malwarescore=0 adultscore=0
 clxscore=1015 priorityscore=1501 suspectscore=0 phishscore=0
 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608090158
X-purgate-ID: tlsNG-d25034/1786297591-03CD3A5B-548D1899/0/0
X-purgate-type: clean
X-purgate-size: 4168

On Fri, Aug 07, 2026 at 04:24:00PM +0100, Muhammad Usama Anjum wrote:
> On 07/08/2026 8:09 am, Alexander Gordeev wrote:
> > On Thu, Aug 06, 2026 at 09:38:39AM +0100, Muhammad Usama Anjum wrote:
> >> pte_t is used both for logical PTE values and for entries stored in a PTE
> >> table, so pte_t * does not distinguish a pointer to a copied value from a
> >> pointer to table storage.
> >>
> >> Introduce hw_pte_t as the generic name for a PTE table element. Define it
> >> as a macro alias of pte_t by default. When an architecture selects
> >> ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead.
> >> This preserves the representation while allowing converted architectures
> >> to enforce the distinction at compile time.
> >>
> >> Keep the C type definitions behind an __ASSEMBLY__ check because
> >> architecture assembly sources can include this header indirectly. Include
> >> asm/page.h so consumers such as linux/vmalloc.h retain the page definitions
> >> they previously obtained from that header.
> >>
> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> >> ---
> >> Changes since RFC v1:
> >> - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition.
> >> - Exclude the C type definitions from assembly sources.
> >> - Update the description for the new opt-in model.
> >> ---
> >>  MAINTAINERS                   |  1 +
> >>  include/linux/pgtable_types.h | 17 +++++++++++++++++
> >>  mm/Kconfig                    |  3 +++
> >>  3 files changed, 21 insertions(+)
> >>  create mode 100644 include/linux/pgtable_types.h
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index e9c8567308a75..7169bea968cf5 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -16982,6 +16982,7 @@ F:	include/linux/mmu_notifier.h
> >>  F:	include/linux/pagewalk.h
> >>  F:	include/linux/pgalloc.h
> >>  F:	include/linux/pgtable.h
> >> +F:	include/linux/pgtable_types.h
> >>  F:	include/linux/ptdump.h
> >>  F:	include/linux/vmpressure.h
> >>  F:	include/linux/vmstat.h
> >> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
> >> new file mode 100644
> >> index 0000000000000..70c3edd00a01b
> >> --- /dev/null
> >> +++ b/include/linux/pgtable_types.h
> >> @@ -0,0 +1,17 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#ifndef _LINUX_PGTABLE_TYPES_H
> >> +#define _LINUX_PGTABLE_TYPES_H
> >> +
> >> +#include <asm/page.h>
> >> +
> >> +#ifndef __ASSEMBLY__
> >> +
> >> +#ifdef CONFIG_ARCH_HAS_HW_PTE_T
> >> +typedef struct { pte_t __pte; } hw_pte_t;
> > 
> > On s390 it fails to compile once we do typedef hw_pte_t *pgtable_t
> > in asm/page.h. m68k, powerpc and sparc may also have such problem.
> > 
> > The below declaration helps to resolve it using forward declaration
> > and without meddling with headers, though I do not like it much:
> > 
> > typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
> Thank you for testing it out on s390.
> 
> As __hw_pte_t isn't being used yet in this series, would s390 enablement
> patches add __hw_pte_t to this definition?

I hope there is a better solution. As I noted m68k, powerpc and sparc
may also be affected, so I would suggest to look into those as well.
I would prefer s390 to use the generic one rather than circumvent a
compile error in a custom way.

> This could have been avoided if each architecture defined its own hw_pte_t.
> But for now we are keeping the generic definition of hw_pte_t.
> 
> > 
> >> +#else
> >> +#define hw_pte_t pte_t
> >> +#endif
> >> +
> >> +#endif /* !__ASSEMBLY__ */
> >> +
> >> +#endif /* _LINUX_PGTABLE_TYPES_H */
> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> index 331daf7fcfab5..31ba9ebf4aafd 100644
> >> --- a/mm/Kconfig
> >> +++ b/mm/Kconfig
> >> @@ -1316,6 +1316,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled"
> >>  config GUP_GET_PXX_LOW_HIGH
> >>  	bool
> >>  
> >> +config ARCH_HAS_HW_PTE_T
> >> +	bool
> >> +
> >>  config DMAPOOL_TEST
> >>  	tristate "Enable a module to run time tests on dma_pool"
> >>  	depends on HAS_DMA
> >> -- 
> >> 2.47.3
> >>
> 
> -- 
> Thanks,
> Usama
> 


From xen-devel-bounces@lists.xenproject.org Sun Aug 09 22:38:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Aug 2026 22:38:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387167.1628474 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtC9z-0007eK-3i; Sun, 09 Aug 2026 22:38:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387167.1628474; Sun, 09 Aug 2026 22:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtC9y-0007e9-V5; Sun, 09 Aug 2026 22:38:26 +0000
Received: by outflank-mailman (input) for mailman id 1387167;
 Sun, 09 Aug 2026 22:38:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hoepf@cit.tum.de>) id 1wtC9w-0007e3-Ga
 for xen-devel@lists.xenproject.org; Sun, 09 Aug 2026 22:38:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtC9u-00CROE-KE
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 00:38:22 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <hoepf@cit.tum.de>)
 id 6a790098-2eae-0a2a0a5409dd-0a2a4502bc58-30
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 00:38:22 +0200
Received: from [131.159.0.202] (helo=mailout2.rbg.tum.de)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <hoepf@cit.tum.de>)
 id 6a79015d-6ca4-0a2a45020019-839f00cab431-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 00:38:21 +0200
Received: from mailrelay1n.ito.cit.tum.de (mailrelay1.in.tum.de
 [IPv6:2a09:80c0:254::14])
 by mailout2.rbg.tum.de (Postfix) with ESMTPS id 8515E4C0240;
 Mon, 10 Aug 2026 00:38:21 +0200 (CEST)
Received: from mail.in.tum.de (mailproxy.in.tum.de [IPv6:2a09:80c0::78])
 by mailrelay1n.ito.cit.tum.de (Postfix) with ESMTPS id 4hJCTT2g9qz2xRH;
 Mon, 10 Aug 2026 00:38:21 +0200 (CEST)
Received: by mail.in.tum.de (Postfix, from userid 112)
 id 55F894A03EE; Mon, 10 Aug 2026 00:38:21 +0200 (CEST)
Received: (Authenticated sender: hoepf)
 by mail.in.tum.de (Postfix) with ESMTPSA id 030B74A008B;
 Mon, 10 Aug 2026 00:38:20 +0200 (CEST)
 (Extended-Queue-bit xtech_zn@fff.in.tum.de)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20220209 header.d=cit.tum.de header.i="@cit.tum.de" header.h="Date:From:To:Cc:Subject"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cit.tum.de;
	s=20220209; t=1786315101;
	bh=eWB0xF/Ua9gI7/dD9vLvBWcZzJ0BdDJBvA6sapEdlxU=;
	h=Date:From:To:Cc:Subject:From;
	b=TnMpww/Ilp+dvn2ZFWEpI6LGQ7bm0TCzfDvwr/HVki05fz/S1zXUx98gQCm5DQdaY
	 4tUq2wZA2y2h85+lrfQ6KjxDd9UhyCswyYqazCS5SxeMrzGVMmGcEDK7xj0lASBpAM
	 /hL/aSEhbWoOOWDUd/6seLBfq3I4ukHttLCRqtSFzfk+U3qqwYa+kb34D3pF1p7/VO
	 CX75jC47tMsxiBTAXAjMcU0/2YAGMDDaFtgeixVgb5H/mBckbk/UFS3GK6IOMD9w4x
	 cUt9wG9kMZJsKfHUi1l4skAzFuZS/ARSZXG8OJYYmglTo5b35+bq7BK9ZKMok5FEFV
	 IYl19WyXcJ96A==
Date: Mon, 10 Aug 2026 00:38:19 +0200
From: Johann =?utf-8?Q?H=C3=B6pfner?= <hoepf@cit.tum.de>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/domctl: Fix unitialized copyback in XEN_DOMCTL_PSR_GET_*
Message-ID: <anWrDspbnvRYCwGZ@cit.tum.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 1.5.3 at itovm121
X-Virus-Status: Clean
X-purgate-ID: tlsNG-720697/1786315102-F12A12AC-150EB9B3/0/0
X-purgate-type: clean
X-purgate-size: 1148

domctl_psr_get_val() copies unitialized stack space back if psr_get_val
fails. Fix by zero-initializing v_.

Fixes: 03f30dc193c8 ("x86: refactor psr: L3 CAT: implement get value flow.")
Signed-off-by: Johann Höpfner <hoepf@cit.tum.de>
---

Consider instead removing the local variable indirection introduced by
03f30dc193c8 and passing &(domctl)->u.psr_alloc.data to psr_get_val
instead or only conditionally setting copyback true.

 xen/arch/x86/domctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f26990208d..6e42fa383c 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1347,7 +1347,7 @@ long arch_do_domctl(
             break;
 
 #define domctl_psr_get_val(d, domctl, type, copyback) ({    \
-    uint32_t v_;                                            \
+    uint32_t v_ = 0;                                        \
     int r_ = psr_get_val((d), (domctl)->u.psr_alloc.target, \
                          &v_, (type));                      \
                                                             \
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 05:15:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 05:15:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387205.1628483 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtIMD-0002e3-0o; Mon, 10 Aug 2026 05:15:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387205.1628483; Mon, 10 Aug 2026 05:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtIMC-0002dv-SM; Mon, 10 Aug 2026 05:15:28 +0000
Received: by outflank-mailman (input) for mailman id 1387205;
 Mon, 10 Aug 2026 05:15:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wtIMB-0002dp-75
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 05:15:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtIM9-00Gsoa-PH
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 07:15:25 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a795e33-2eae-0a2a0a5409dd-0a2a4502c6b6-40
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 07:15:25 +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 <frn1furkan10@gmail.com>)
 id 6a795e6d-6ca4-0a2a45020019-d155802eaca2-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 07:15:25 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-495590dde14so17152245e9.0
 for <xen-devel@lists.xenproject.org>; Sun, 09 Aug 2026 22:15:25 -0700 (PDT)
Received: from notebook.. ([85.107.103.196]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995c7b2898sm207058025e9.4.2026.08.09.22.15.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 09 Aug 2026 22:15:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786338925; x=1786943725; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=Hm21pwCcSfBBYRAiBMC0UPopMsN4Ck6e6kpf8prhvNs=;
        b=JcvtXyA0X/GesC39VpBb5fdi4h4EN9cHYNgaWdB0dq4iCe7cxw4ZYEByjvBMvqsI7t
         2R63aodwNHqP29G/9ZG5Q8HSWOQWqRkQMXwjhHqfC+pNDv6IYyAvQNX8XRnpa9ERwtcR
         EAa3gsFX/6v1kxtl+S5vsmW4/NvYyDlYRXfI9VntPeeUtcQv6zJqIPmeqnsx5bA5ZzCO
         klWQuCcMqQrSq4udvnXsivvbAsoe+lil7gmtZPxDf4PWCVH8zZZk++PuqMDCxhSrtRR6
         9n5CYd+mEgxct755ZaTLsMlTM0swpZniXvh97993Ic4fM/MXrhipac4DH6Qm+tZbcq08
         rjBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786338925; x=1786943725;
        h=content-transfer-encoding:mime-version: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=Hm21pwCcSfBBYRAiBMC0UPopMsN4Ck6e6kpf8prhvNs=;
        b=Wlruec5uU3tVKdJbuVh+6vjDSdOTy1UELV/f8B2VF8dpzRCJF3lQn5VWod/dkJChzd
         Srq5MK2ifRrHdn6hFXGFne4hn37ZJTQlJB49AWSn2D3pQjNA6ej6cL+dQZxCoKZCAPjI
         VNr6WB1hgR2zPI5B54KMyo+fWVWlEUtp9ktxghCXD+AI2uNdVMaIvcpKWxpw+1qEMA/4
         UjLaIolRa1PnGPZaDTOKv5qvfBMmWeSs/BcqNK649dIfUngtVsGfBv2QgLBjqkWnYue0
         GUfgria91/ZM1E9utoTwSGT3KtumxUso69z07urdHy3bVmpZ3GKfdeQIIrDAH2hk83UF
         1O9A==
X-Gm-Message-State: AOJu0YwlLac9RoOrsh5EKncI9InalflfPQXr7RjbrC5jh7/gSg+UqMTC
	IjnNYcgQZYjeEpaHNONDdLtAy6k3btaAianAiM3V/dlG7Ha7wUYYlmJa3rPEwQ==
X-Gm-Gg: AR+sD10c7RpZiztVukDTFrzltY3jSSwzBhr0QfXTYWSDPajsH9RtCbyZRbjua0pmcaP
	jrxbWy8yNuZpllGqszfrrlmxgdYHRr23ODbtfhWjQEx8ERQbcyRrd2GYb92XFi0w+K1CIoRDdAJ
	VeBIzbplrjS6Snv7ft+SfrKmbhvjX6ZjA//mA7bvxNy908zC6irZS39fWaMRwdQIhjiVn1QIncl
	JjR8TH5ZT8pdsMA6M/KkmRRFXbKcjVAr5gGPMpFhME7Y7+JnYwCyiSB/sMCrKix95Jy7rnVrvrn
	Jnz0oUKykcIhQajeC/Z5gu2oBhSzDDqJ78A54MASic50dE6Ryn9saY9UeWjFTzrJZ5hxTpj8mQz
	Kps4s/BT4zHV2NWc8xAvvEBjY2ydRdkM1LbJQFeU2+psajbexx6ph6Xgvov2QGZ5/jJiI8A1qAD
	gsrgCCv6sVxBgsZevPNN2PKZSJMFXVxVMyhII2Zb3DX60o2TryhUf/Izc2YaO+Rg==
X-Received: by 2002:a05:600c:4ed3:b0:493:e983:806e with SMTP id 5b1f17b1804b1-4994e72f795mr544276295e9.3.1786338924899;
        Sun, 09 Aug 2026 22:15:24 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com,
	jbeulich@suse.com,
	jgross@suse.com,
	gwd@xenproject.org,
	dfaggioli@suse.com,
	stewart.hildebrand@amd.com,
	nathan.studer@dornerworks.com,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	michal.orzel@amd.com,
	bertrand.marquis@arm.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v3] xen/sched: split scheduler vtable from struct scheduler
Date: Mon, 10 Aug 2026 08:15:01 +0300
Message-Id: <20260810051501.6282-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1786338925-F0AA52AC-51B1DC04/0/0
X-purgate-type: clean
X-purgate-size: 20320

struct scheduler currently serves two purposes: it is the static
vtable a scheduler backend defines (name, opt_name, sched_id, and
all its function pointers), and it is also the per-cpupool runtime
object scheduler_alloc() allocates. Being the same type forces
scheduler_alloc() to memcpy() the whole vtable into a fresh
allocation per cpupool, duplicating identical function pointers
across every cpupool using the same scheduler.

Split the vtable out into its own type, struct sched_ops, so it
can be shared by every cpupool using a given scheduler instead of
copied per cpupool. struct scheduler is left holding only what is
actually per-instance: a pointer to the shared sched_ops, plus
sched_data and cpupool. scheduler_alloc() now stores a pointer to
the matching sched_ops instance instead of copying its fields and
uses xzalloc() to zero-initialize the struct. Every accessor in
private.h is updated from s->field to s->ops->field to match.

Every in-tree scheduler backend (credit, credit2, rtds, arinc653,
null) is converted from struct scheduler to struct sched_ops.
Also drop the generic comment in arinc653.c.

A handful of call sites elsewhere read a scheduler's name,
opt_name or sched_id directly and are updated to go through
->ops as well.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
---
v3:
 * fixed whitespace and blank-lines
 * mentioned the xzalloc() change and the arinc653 
   comment removal
 * fixed the overlong lines.
---
 xen/common/sched/arinc653.c |  9 +---
 xen/common/sched/core.c     | 51 +++++++++++--------
 xen/common/sched/cpupool.c  |  7 +--
 xen/common/sched/credit.c   |  3 +-
 xen/common/sched/credit2.c  |  3 +-
 xen/common/sched/null.c     |  3 +-
 xen/common/sched/private.h  | 98 +++++++++++++++++++------------------
 xen/common/sched/rt.c       |  3 +-
 8 files changed, 90 insertions(+), 87 deletions(-)

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 32c596a23c..746963806e 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -702,17 +702,10 @@ a653sched_adjust_global(const struct scheduler *ops,
 }
 #endif /* CONFIG_SYSCTL */
 
-/**
- * This structure defines our scheduler for Xen.
- * The entries tell Xen where to find our scheduler-specific
- * callback functions.
- * The symbol must be visible to the rest of Xen at link time.
- */
-static const struct scheduler sched_arinc653_def = {
+static const struct sched_ops sched_arinc653_def = {
     .name           = "ARINC 653 Scheduler",
     .opt_name       = "arinc653",
     .sched_id       = XEN_SCHEDULER_ARINC653,
-    .sched_data     = NULL,
 
     .init           = a653sched_init,
     .deinit         = a653sched_deinit,
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9ccf5811bf..e4e4da95d8 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -87,7 +87,8 @@ DEFINE_PER_CPU(cpumask_t, cpumask_scratch);
 /* How many urgent vcpus. */
 DEFINE_PER_CPU(atomic_t, sched_urgent_count);
 
-extern const struct scheduler *__start_schedulers_array[], *__end_schedulers_array[];
+extern const struct sched_ops *__start_schedulers_array[];
+extern const struct sched_ops *__end_schedulers_array[];
 #define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
 #define schedulers __start_schedulers_array
 
@@ -127,10 +128,9 @@ static void cf_check sched_idle_schedule(
     unit->next_task = sched_idle_unit(cpu);
 }
 
-static struct scheduler sched_idle_ops = {
+static struct sched_ops sched_idle_sched_ops = {
     .name           = "Idle Scheduler",
     .opt_name       = "idle",
-    .sched_data     = NULL,
 
     .pick_resource  = sched_idle_res_pick,
     .do_schedule    = sched_idle_schedule,
@@ -139,6 +139,11 @@ static struct scheduler sched_idle_ops = {
     .free_udata     = sched_idle_free_udata,
 };
 
+static struct scheduler sched_idle_ops = {
+    .ops        = &sched_idle_sched_ops,
+    .sched_data = NULL,
+};
+
 static inline struct vcpu *unit2vcpu_cpu(const struct sched_unit *unit,
                                          unsigned int cpu)
 {
@@ -2081,7 +2086,7 @@ long do_set_timer_op(s_time_t timeout)
 /* scheduler_id - fetch ID of current scheduler */
 int scheduler_id(void)
 {
-    return operations.sched_id;
+    return operations.ops->sched_id;
 }
 #endif
 
@@ -2090,7 +2095,7 @@ long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
     long ret;
 
-    if ( op->sched_id != dom_scheduler(d)->sched_id )
+    if ( op->sched_id != dom_scheduler(d)->ops->sched_id )
         return -EINVAL;
 
     switch ( op->cmd )
@@ -2132,7 +2137,7 @@ long sched_adjust_global(struct xen_sysctl_scheduler_op *op)
 
     rcu_read_lock(&sched_res_rculock);
 
-    rc = ((op->sched_id == pool->sched->sched_id)
+    rc = ((op->sched_id == pool->sched->ops->sched_id)
           ? sched_adjust_cpupool(pool->sched, op) : -EINVAL);
 
     rcu_read_unlock(&sched_res_rculock);
@@ -2299,7 +2304,7 @@ static struct sched_unit *do_schedule(struct sched_unit *prev, s_time_t now,
     struct sched_unit *next;
 
     /* get policy-specific decision on scheduling... */
-    sched->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
+    sched->ops->do_schedule(sched, prev, now, sched_tasklet_check(cpu));
 
     next = prev->next_task;
 
@@ -2989,7 +2994,7 @@ void scheduler_enable(void)
 }
 
 static inline
-const struct scheduler *__init sched_get_by_name(const char *sched_name)
+const struct sched_ops *__init sched_ops_get_by_name(const char *sched_name)
 {
     unsigned int i;
 
@@ -3002,16 +3007,16 @@ const struct scheduler *__init sched_get_by_name(const char *sched_name)
 
 int __init sched_get_id_by_name(const char *sched_name)
 {
-    const struct scheduler *scheduler = sched_get_by_name(sched_name);
+    const struct sched_ops *ops = sched_ops_get_by_name(sched_name);
 
-    return scheduler ? scheduler->sched_id : -1;
+    return ops ? ops->sched_id : -1;
 }
 
 /* Initialise the data structures. */
 void __init scheduler_init(void)
 {
     struct domain *idle_domain;
-    const struct scheduler *scheduler;
+    const struct sched_ops *ops;
     int i;
 
     scheduler_enable();
@@ -3044,21 +3049,23 @@ void __init scheduler_init(void)
         }
     }
 
-    scheduler = sched_get_by_name(opt_sched);
-    if ( !scheduler )
+    ops = sched_ops_get_by_name(opt_sched);
+    if ( !ops )
     {
         printk("Could not find scheduler: %s\n", opt_sched);
-        scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
-        BUG_ON(!scheduler);
-        printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
+        ops = sched_ops_get_by_name(CONFIG_SCHED_DEFAULT);
+        BUG_ON(!ops);
+        printk("Using '%s' (%s)\n", ops->name, ops->opt_name);
     }
-    operations = *scheduler;
+
+    operations.ops = ops;
 
     if ( cpu_schedule_up(0) )
         BUG();
     register_cpu_notifier(&cpu_schedule_nfb);
 
-    printk("Using scheduler: %s (%s)\n", operations.name, operations.opt_name);
+    printk("Using scheduler: %s (%s)\n",
+           operations.ops->name, operations.ops->opt_name);
     if ( sched_init(&operations) )
         panic("scheduler returned error on init\n");
 
@@ -3411,12 +3418,14 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
     for ( i = 0; i < NUM_SCHEDULERS; i++ )
         if ( schedulers[i] && schedulers[i]->sched_id == sched_id )
             goto found;
+
     return ERR_PTR(-ENOENT);
 
  found:
-    if ( (sched = xmalloc(struct scheduler)) == NULL )
+    if ( (sched = xzalloc(struct scheduler)) == NULL )
         return ERR_PTR(-ENOMEM);
-    memcpy(sched, schedulers[i], sizeof(*sched));
+    sched->ops = schedulers[i];
+
     if ( (ret = sched_init(sched)) != 0 )
     {
         xfree(sched);
@@ -3447,7 +3456,7 @@ void schedule_dump(struct cpupool *c)
     {
         sched = c->sched;
         cpus = c->res_valid;
-        printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
+        printk("Scheduler: %s (%s)\n", sched->ops->name, sched->ops->opt_name);
         sched_dump_settings(sched);
     }
     else
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 081e1053eb..640578201f 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -338,7 +338,8 @@ static struct cpupool *cpupool_create(unsigned int poolid,
     spin_unlock(&cpupool_lock);
 
     debugtrace_printk("Created cpupool %u with scheduler %s (%s)\n",
-                      c->cpupool_id, c->sched->name, c->sched->opt_name);
+                      c->cpupool_id, c->sched->ops->name,
+                      c->sched->ops->opt_name);
 
     return c;
 
@@ -862,7 +863,7 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
         if ( c == NULL )
             break;
         op->cpupool_id = c->cpupool_id;
-        op->sched_id = c->sched->sched_id;
+        op->sched_id = c->sched->ops->sched_id;
         op->n_dom = c->n_dom;
         ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
         cpupool_put(c);
@@ -1294,7 +1295,7 @@ struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
     struct cpupool *pool;
 
     if ( sched_id < 0 )
-        sched_id = scheduler_get_default()->sched_id;
+        sched_id = scheduler_get_default()->ops->sched_id;
 
     pool = cpupool_create(pool_id, sched_id);
 
diff --git a/xen/common/sched/credit.c b/xen/common/sched/credit.c
index 4dde2ede12..8df746bf6b 100644
--- a/xen/common/sched/credit.c
+++ b/xen/common/sched/credit.c
@@ -2277,11 +2277,10 @@ csched_deinit(struct scheduler *ops)
     }
 }
 
-static const struct scheduler sched_credit_def = {
+static const struct sched_ops sched_credit_def = {
     .name           = "SMP Credit Scheduler",
     .opt_name       = "credit",
     .sched_id       = XEN_SCHEDULER_CREDIT,
-    .sched_data     = NULL,
 
     .global_init    = csched_global_init,
 
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 95946634d1..4949606881 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -4230,11 +4230,10 @@ csched2_deinit(struct scheduler *ops)
     xfree(prv);
 }
 
-static const struct scheduler sched_credit2_def = {
+static const struct sched_ops sched_credit2_def = {
     .name           = "SMP Credit Scheduler rev2",
     .opt_name       = "credit2",
     .sched_id       = XEN_SCHEDULER_CREDIT2,
-    .sched_data     = NULL,
 
     .global_init    = csched2_global_init,
 
diff --git a/xen/common/sched/null.c b/xen/common/sched/null.c
index 952bb47444..b3c6651fb1 100644
--- a/xen/common/sched/null.c
+++ b/xen/common/sched/null.c
@@ -1037,11 +1037,10 @@ static void cf_check null_dump(const struct scheduler *ops)
     spin_unlock_irqrestore(&prv->lock, flags);
 }
 
-static const struct scheduler sched_null_def = {
+static const struct sched_ops sched_null_def = {
     .name           = "null Scheduler",
     .opt_name       = "null",
     .sched_id       = XEN_SCHEDULER_NULL,
-    .sched_data     = NULL,
 
     .init           = null_init,
     .deinit         = null_deinit,
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index d6884550cd..18ccab183e 100644
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -294,12 +294,10 @@ static inline spinlock_t *pcpu_schedule_trylock(unsigned int cpu)
     return NULL;
 }
 
-struct scheduler {
-    const char *name;       /* full name for this scheduler      */
-    const char *opt_name;   /* option name for this scheduler    */
-    unsigned int sched_id;  /* ID for this scheduler             */
-    void *sched_data;       /* global data pointer               */
-    struct cpupool *cpupool;/* points to this scheduler's pool   */
+struct sched_ops {
+    const char *name;       /* full name for this sched_ops      */
+    const char *opt_name;   /* option name for this sched_ops    */
+    unsigned int sched_id;  /* ID for this sched_ops             */
 
     int          (*global_init)    (void);
 
@@ -366,127 +364,133 @@ struct scheduler {
                                     struct sched_resource *sr);
 };
 
+struct scheduler {
+    const struct sched_ops *ops; /* shared, read-only dispatch table   */
+    void *sched_data;            /* per-cpupool scheduler-private data */
+    struct cpupool *cpupool;     /* points to this scheduler's pool    */
+};
+
 static inline int sched_init(struct scheduler *s)
 {
-    return s->init(s);
+    return s->ops->init(s);
 }
 
 static inline void sched_deinit(struct scheduler *s)
 {
-    s->deinit(s);
+    s->ops->deinit(s);
 }
 
 static inline spinlock_t *sched_switch_sched(struct scheduler *s,
                                              unsigned int cpu,
                                              void *pdata, void *vdata)
 {
-    return s->switch_sched(s, cpu, pdata, vdata);
+    return s->ops->switch_sched(s, cpu, pdata, vdata);
 }
 
 static inline void sched_dump_settings(const struct scheduler *s)
 {
-    if ( s->dump_settings )
-        s->dump_settings(s);
+    if ( s->ops->dump_settings )
+        s->ops->dump_settings(s);
 }
 
 static inline void sched_dump_cpu_state(const struct scheduler *s, int cpu)
 {
-    if ( s->dump_cpu_state )
-        s->dump_cpu_state(s, cpu);
+    if ( s->ops->dump_cpu_state )
+        s->ops->dump_cpu_state(s, cpu);
 }
 
 static inline void *sched_alloc_domdata(const struct scheduler *s,
                                         struct domain *d)
 {
-    return s->alloc_domdata ? s->alloc_domdata(s, d) : NULL;
+    return s->ops->alloc_domdata ? s->ops->alloc_domdata(s, d) : NULL;
 }
 
 static inline void sched_free_domdata(const struct scheduler *s,
                                       void *data)
 {
-    ASSERT(s->free_domdata || !data);
-    if ( s->free_domdata )
-        s->free_domdata(s, data);
+    ASSERT(s->ops->free_domdata || !data);
+    if ( s->ops->free_domdata )
+        s->ops->free_domdata(s, data);
 }
 
 static inline void *sched_alloc_pdata(const struct scheduler *s, int cpu)
 {
-    return s->alloc_pdata ? s->alloc_pdata(s, cpu) : NULL;
+    return s->ops->alloc_pdata ? s->ops->alloc_pdata(s, cpu) : NULL;
 }
 
 static inline void sched_free_pdata(const struct scheduler *s, void *data,
                                     int cpu)
 {
-    ASSERT(s->free_pdata || !data);
-    if ( s->free_pdata )
-        s->free_pdata(s, data, cpu);
+    ASSERT(s->ops->free_pdata || !data);
+    if ( s->ops->free_pdata )
+        s->ops->free_pdata(s, data, cpu);
 }
 
 static inline void sched_deinit_pdata(const struct scheduler *s, void *data,
                                       int cpu)
 {
-    if ( s->deinit_pdata )
-        s->deinit_pdata(s, data, cpu);
+    if ( s->ops->deinit_pdata )
+        s->ops->deinit_pdata(s, data, cpu);
 }
 
 static inline void *sched_alloc_udata(const struct scheduler *s,
                                       struct sched_unit *unit, void *dom_data)
 {
-    return s->alloc_udata(s, unit, dom_data);
+    return s->ops->alloc_udata(s, unit, dom_data);
 }
 
 static inline void sched_free_udata(const struct scheduler *s, void *data)
 {
-    s->free_udata(s, data);
+    s->ops->free_udata(s, data);
 }
 
 static inline void sched_insert_unit(const struct scheduler *s,
                                      struct sched_unit *unit)
 {
-    if ( s->insert_unit )
-        s->insert_unit(s, unit);
+    if ( s->ops->insert_unit )
+        s->ops->insert_unit(s, unit);
 }
 
 static inline void sched_remove_unit(const struct scheduler *s,
                                      struct sched_unit *unit)
 {
-    if ( s->remove_unit )
-        s->remove_unit(s, unit);
+    if ( s->ops->remove_unit )
+        s->ops->remove_unit(s, unit);
 }
 
 static inline void sched_sleep(const struct scheduler *s,
                                struct sched_unit *unit)
 {
-    if ( s->sleep )
-        s->sleep(s, unit);
+    if ( s->ops->sleep )
+        s->ops->sleep(s, unit);
 }
 
 static inline void sched_wake(const struct scheduler *s,
                               struct sched_unit *unit)
 {
-    if ( s->wake )
-        s->wake(s, unit);
+    if ( s->ops->wake )
+        s->ops->wake(s, unit);
 }
 
 static inline void sched_yield(const struct scheduler *s,
                                struct sched_unit *unit)
 {
-    if ( s->yield )
-        s->yield(s, unit);
+    if ( s->ops->yield )
+        s->ops->yield(s, unit);
 }
 
 static inline void sched_context_saved(const struct scheduler *s,
                                        struct sched_unit *unit)
 {
-    if ( s->context_saved )
-        s->context_saved(s, unit);
+    if ( s->ops->context_saved )
+        s->ops->context_saved(s, unit);
 }
 
 static inline void sched_migrate(const struct scheduler *s,
                                  struct sched_unit *unit, unsigned int cpu)
 {
-    if ( s->migrate )
-        s->migrate(s, unit, cpu);
+    if ( s->ops->migrate )
+        s->ops->migrate(s, unit, cpu);
     else
         sched_set_res(unit, get_sched_res(cpu));
 }
@@ -494,7 +498,7 @@ static inline void sched_migrate(const struct scheduler *s,
 static inline struct sched_resource *sched_pick_resource(
     const struct scheduler *s, const struct sched_unit *unit)
 {
-    return s->pick_resource(s, unit);
+    return s->ops->pick_resource(s, unit);
 }
 
 static inline void sched_adjust_affinity(const struct scheduler *s,
@@ -502,29 +506,29 @@ static inline void sched_adjust_affinity(const struct scheduler *s,
                                          const cpumask_t *hard,
                                          const cpumask_t *soft)
 {
-    if ( s->adjust_affinity )
-        s->adjust_affinity(s, unit, hard, soft);
+    if ( s->ops->adjust_affinity )
+        s->ops->adjust_affinity(s, unit, hard, soft);
 }
 
 static inline int sched_adjust_dom(const struct scheduler *s, struct domain *d,
                                    struct xen_domctl_scheduler_op *op)
 {
-    return s->adjust ? s->adjust(s, d, op) : 0;
+    return s->ops->adjust ? s->ops->adjust(s, d, op) : 0;
 }
 
 #ifdef CONFIG_SYSCTL
 static inline int sched_adjust_cpupool(const struct scheduler *s,
                                        struct xen_sysctl_scheduler_op *op)
 {
-    return s->adjust_global ? s->adjust_global(s, op) : 0;
+    return s->ops->adjust_global ? s->ops->adjust_global(s, op) : 0;
 }
 #endif
 
 static inline void sched_move_timers(const struct scheduler *s,
                                      struct sched_resource *sr)
 {
-    if ( s->move_timers )
-        s->move_timers(s, sr);
+    if ( s->ops->move_timers )
+        s->ops->move_timers(s, sr);
 }
 
 static inline void sched_unit_pause_nosync(const struct sched_unit *unit)
@@ -543,7 +547,7 @@ static inline void sched_unit_unpause(const struct sched_unit *unit)
         vcpu_unpause(v);
 }
 
-#define REGISTER_SCHEDULER(x) static const struct scheduler *x##_entry \
+#define REGISTER_SCHEDULER(x) static const struct sched_ops *x##_entry \
   __used_section(".data.schedulers") = &(x)
 
 struct cpupool
diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 744f214173..0e9f04ea72 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1617,11 +1617,10 @@ static void cf_check repl_timer_handler(void *data)
     spin_unlock_irq(&prv->lock);
 }
 
-static const struct scheduler sched_rtds_def = {
+static const struct sched_ops sched_rtds_def = {
     .name           = "SMP RTDS Scheduler",
     .opt_name       = "rtds",
     .sched_id       = XEN_SCHEDULER_RTDS,
-    .sched_data     = NULL,
 
     .dump_cpu_state = rt_dump_pcpu,
     .dump_settings  = rt_dump,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 06:45:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 06:45:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387220.1628492 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtJl9-0007sd-Cx; Mon, 10 Aug 2026 06:45:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387220.1628492; Mon, 10 Aug 2026 06:45:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtJl9-0007sV-8m; Mon, 10 Aug 2026 06:45:19 +0000
Received: by outflank-mailman (input) for mailman id 1387220;
 Mon, 10 Aug 2026 06:45:18 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <agordeev@linux.ibm.com>) id 1wtJl8-0007sP-Jf
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 06:45:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtJl6-002EPF-NU
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 08:45:16 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a79735d-e002-0a2a0a5209dd-0a2a4507af76-44
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 08:45:16 +0200
Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <agordeev@linux.ibm.com>)
 id 6a79737a-b4ea-0a2a45070019-94a39c01c418-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 08:45:16 +0200
Received: from pps.filterd (m0353729.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67A5VYZX3085069; Mon, 10 Aug 2026 06:44:38 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fwvjypkqg-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 10 Aug 2026 06:44:37 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67A6ffw0026503;
 Mon, 10 Aug 2026 06:44:36 GMT
Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4fxhfxueyp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 10 Aug 2026 06:44:36 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com
 [10.20.54.101])
 by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 67A6iYQG34930976
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 10 Aug 2026 06:44:34 GMT
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 17B532004B;
 Mon, 10 Aug 2026 06:44:34 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 2335D20043;
 Mon, 10 Aug 2026 06:44:31 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.87.135.220])
 by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Mon, 10 Aug 2026 06:44:31 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=vVPGPVZ23NsreeExE7+jGCM0ud2bcA
	JA4ypv1DILR34=; b=cP2dX1rqRgJGyJQPsc4KFbE1PC99K1ErC8LoPBcJX/kDVk
	D9Jo4Iz1SXdFchU8Ko5W4WB9COXrRcti5DpxhwdI5dfEePzz5UmgRzT8EYYyBi07
	KU36zRJaFsP0Akw7apyJ4SCl4IAb1VRGvP8L0mKhwBZnn0XUkDZ2PW7t9oviZUQq
	bN2tmVBhSWNgiSiSi7ymdtf6iKh4gNTCCXIweHK0Tg6HF6KYslOZj/J1AEcJVHnf
	kWNlsq5fwLgQr2DlUZF0whZYM5XqlyiEV4xJgAR6wPkWOH+OEMcVL/bVHH8IYS6D
	MxDe73qz6EXJrcPmB5P+oxGbZoA1keo68zERDcAg==
Date: Mon, 10 Aug 2026 08:44:29 +0200
From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        Tvrtko Ursulin <tursulin@ursulin.net>,
        David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
        Dimitri Sivanich <dimitri.sivanich@hpe.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
        Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Muchun Song <muchun.song@linux.dev>,
        Oscar Salvador <osalvador@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Liam R. Howlett" <liam@infradead.org>,
        Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
        Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        David Hildenbrand <david@kernel.org>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
        Uladzislau Rezki <urezki@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Eduard Zingerman <eddyz87@gmail.com>,
        Kumar Kartikeya Dwivedi <memxor@gmail.com>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>,
        Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>,
        Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
        Christoph Lameter <cl@gentwo.org>, Mike Rapoport <rppt@kernel.org>,
        Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, pfalcato@suse.de,
        ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
        linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
        linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
        linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 6/9] mm: convert PTE table entry to pte
Message-ID: <2599c5b3-e8ac-4865-993b-d41e6f060d52-agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-7-usama.anjum@arm.com>
 <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
 <5c329236-7761-4e42-a549-b822e43b4358@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5c329236-7761-4e42-a549-b822e43b4358@arm.com>
X-TM-AS-GCONF: 00
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEwMDA1NCBTYWx0ZWRfXxI/cthX2D0Wc
 iHPLS8hc2Kj/zk+XaKiAAFgipdFaX6yt5ULiZYFw9cMykKZhsGzYdz8Ozez/WjJFTxNxMxdlY+Z
 xRKD8hb46fc3eq4T3zk/Ay2gFewaqBQyLERBaqjOrmguPqyfrY4V/sj3PMJQSwHxbC9gQ3JPdGp
 nwoFQng/LWfi/b2CNXX0ejbyTRbXCpU6ISkPy5ReFIqwletsdYxZQh3JZdOlQrUjBCsND1GblNt
 G/4DaSrhSqHIA4lB3PliH1JLOCq/gqtakESjF4VI9bapYhuQXt1SuBKOBQMvOtnuq4THGnpYdaA
 9DlU8ZKdg0fttjy6cWWMXxwJNMzsJQnfWACC9mQPG3O4x/cS3d0NgAmCjmdVYfXi8XGUV9/5PxJ
 HdlkuRfRyvN/kE+SQ4EeTy+wa+g6t6URPTCSrkC11WsiBzyO9FuJFEs1QK/7K/rvQyfHrqCYbs4
 iMEVrVdUzEx5zR0r21A==
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEwMDA1NCBTYWx0ZWRfX9Ko1NY31ilHb
 y/krrlO5A2ANnAiXusNks5NMrWI4UvS7c1Y7yzgoGS6CxTGjDGRyAu8EHxJ1ITitPdxPjbMc8pe
 lyb7xPyJDB1SIBriSbnTKYVPxMcf33w=
X-Authority-Analysis: v=2.4 cv=RqD16imK c=1 sm=1 tr=0 ts=6a797355 cx=c_pps
 a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17
 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=VwQbUJbxAAAA:8
 a=7CQSdrXTAAAA:8 a=VnNF1IyMAAAA:8 a=2hzp2EkNZNX3k9pX5ccA:9 a=CjuIK1q_8ugA:10
 a=a-qgeE7W1pNrGK8U0ZQC:22
X-Proofpoint-GUID: YbHEwP5JTLZr3QYF8zr2RkJeozrhuIz7
X-Proofpoint-ORIG-GUID: YbHEwP5JTLZr3QYF8zr2RkJeozrhuIz7
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-10_01,2026-08-07_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 phishscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0
 clxscore=1015 adultscore=0 bulkscore=0 malwarescore=0 impostorscore=0
 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound
 adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608100054
X-purgate-ID: tlsNG-ef75cf/1786344316-A50CDAE4-BE82F9CE/0/0
X-purgate-type: clean
X-purgate-size: 3062

On Fri, Aug 07, 2026 at 05:26:04PM +0100, Muhammad Usama Anjum wrote:
> On 07/08/2026 7:58 am, Alexander Gordeev wrote:
> > On Thu, Aug 06, 2026 at 09:38:44AM +0100, Muhammad Usama Anjum wrote:
> >> The non-MMU stub receives hw_pte_t but returns a logical pte_t
> >> value. Convert the stored entry through __pte_from_hw() before
> >> returning.
> >>
> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> >> ---
> >>  include/linux/hugetlb.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> >> index bc0b9c65aa1d0..9e8b391aa4bc9 100644
> >> --- a/include/linux/hugetlb.h
> >> +++ b/include/linux/hugetlb.h
> >> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> >>  #ifdef CONFIG_MMU
> >>  	return ptep_get(ptep);
> >>  #else
> >> -	return *ptep;
> >> +	return __pte_from_hw(*ptep);
> > 
> > But this is a direct dereferencing, which breaks the whole point, isn't it?
> Yes, this is particular line is for non MMU. In this case, CONIFG_ARCH_HAS_HW_PTE
> would never be defined. Hence hw_pte_t is just pte_t and direct dereference is
> allowed. I'd thought a lot about it; is better to leave direct dereference here
> or use some helper. Then used __pte_from_hw() was already being used in generic
> ptep_get().

But in case CONIFG_ARCH_HAS_HW_PTE=n __pte_from_hw() is still gets called.
That looks inconsistent to me. Why not just call ptep_deref() (see below)?

> There are only two users of __pte_from_hw() at this time. 
> 
> > 
> > What about introducing something like pte_t ptep_get_sw(hw_pte_t *ptep)
> > to be used in exactly situations like this? With that the semantics of
> > hw_pte_t pointers becomes straightforward and closes the still ongoing
> > "storage vs lifetime" discussion:
> > 
> > hw_pte_t*     points to HW-formatted page table entries
> > 
> > ptep_get()    is used to obtain HW-linked/attached entries, and may wire
> >               extra code like [1] or [2]
> > 
> > ptep_get_sw() is used to obtain HW-unlinked/unattached entries and in
> >               most cases is just a direct dereference
> ptep_get_sw() or ptep_get_deref() is better name here?

ptep_deref() would be it.

Do you agree to the suggested API requirements?

> I thought __pte_from_hw() is ugly enough that if someone tries to use it
> wrongly, it'll be noticed pretty easily. I'm fine with any other name.

The name may be not perfect, but it is the way it is used above looks
wrong to me.

> > The caller should always know whether the entry is attached or not, so
> > confusions like [3] are avoided.
> > 
> > 1. https://lore.kernel.org/linux-mm/20260526-kpkeys-v8-21-eaaacdacc67c@arm.com/
> > 2. https://lore.kernel.org/linux-s390/650903a4-0dd9-4e6b-9d4b-3c32c5657236-agordeev@linux.ibm.com/
> > 3. https://lore.kernel.org/linux-s390/b44e071d-7c9d-4e7e-a84d-4af3499a5a05@arm.com/
> > 
> >>  #endif
> >>  }

Thanks!

> -- 
> Thanks,
> Usama
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 08:50:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 08:50:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387244.1628501 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtLiH-0000iM-8s; Mon, 10 Aug 2026 08:50:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387244.1628501; Mon, 10 Aug 2026 08:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtLiH-0000iF-5g; Mon, 10 Aug 2026 08:50:29 +0000
Received: by outflank-mailman (input) for mailman id 1387244;
 Mon, 10 Aug 2026 08:50:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtLiF-0000i9-3R
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 08:50:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtLiE-007vGO-19
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:50:26 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7990cb-8faa-0a2a0a5109dd-0a2a4509b816-12
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 10:50:25 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7990d1-be1a-0a2a45090019-d155802adc97-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 10:50:25 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-4954afac04bso17657615e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 01:50:25 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995e9ea92csm278572485e9.4.2026.08.10.01.50.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2026 01:50:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786351825; x=1786956625; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=v7DOr//1UMzxx+qvWjE8pgs9kDMNMgbOq3Hi6M6TC7U=;
        b=PIkVWlyC5Z2NveOk3zRh6zl9TAajdIZVGZs9uadB0jOK+g+SGkVwgf8x1bEty0N37U
         qBSmAw2VakRIsNyoGDiTg+cDxBT5NOwJs7I94hu66wWbcCB02/JQU1bRP0z/7IfikzEc
         kSP+MbAXk74dYmQJuJ9PWE8jFb3p0SJ4DD947DrfhtrOjEqK5161v7dKu1neQMFhQ9AB
         IRJVntugLJEhSeqSjuD7l3VeNTMiJ6O3f9ZdWj6AFAo/wdDSIW1BEvf0GslEZTMP1tkE
         IFl9AK1aCC8BVO7oZ/Rdncn6falRo1ZF3o/79xquL6Vv+wpGngIJsDgyU7yuMN/jVOKc
         vmeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786351825; x=1786956625;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=v7DOr//1UMzxx+qvWjE8pgs9kDMNMgbOq3Hi6M6TC7U=;
        b=DliCiWilLdvx6BO+2Q03j2ybSnsVR+sEj95jm7hhpjj44wGY6UvG1D6fGAv3kGi5Wb
         ZHtHZYXSlzh8tYIaOqyZYgxfnlhvX7Q/UW+6e5B3kXGE3rLycMNokoSoXQeMjZK4ITAn
         tv1UexvcWtKV4aAJ8lCCwplEFhLnsOSXau9f/q2PuSkUaB/i5SqhWUsT73jaomOn/s41
         gUEMwV4mJujI4VKSHXj86vPdKqAhcY+47lY+ydtA/itt+RHwE0fxZcBe0shgVgStNQjo
         GURpPZy2Xw611IKYV8KBzhLmhuDpioPOzUQ64Oc3BdITh3JPJL6BxOU82+s0ijijkGEE
         JE0A==
X-Forwarded-Encrypted: i=1; AHgh+RoslYNr19aqX6Ln3VER5AA0NArTUts/InTHZz0oJgTeIVeVIvoQmeVsJfeTI2uZj6YhnZQfjMwafwo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwEuUiUVDxQ9n2UnINSLqv2HanOeWo7TyMi/MAoXnh6DrUdTNha
	LrOQZWblkTAc7A4V5PffwLtV5geCOfT7HViRROwbZKFzosxIUcdt8vC+
X-Gm-Gg: AR+sD13uygAh7FUrjSMepfj8zKQTc1Hqb590JV6oZFzQISAB7l2DNMg/WqAHeZB7Noo
	GB5cW8LeZ09RUFLWcATnXZiUOGDXwlspkJM/2XZ6goUkD8IaH4UHnvon1cG2BpAp46cvGjSA8Mf
	8ca80g0LD5tObO6NKugpml6MK9QRkIjTRNiNRaoUFvSp7ZHnQwkRhUTzPbAw0cFCJAU/IOy3/TU
	F4C9EkrLSFMxddLyVzjYRt/z2oB6OR3B0Kzl12jXw2X45uWT2wn0tRn5tK1tnAdB4cL87/lSnVZ
	5wL0RvzqV/VGyXwCyA1SOaFccoimhN/aIhdK/4JIxOODEji2lLf9Ho2oCcTXRL1PC6jpoHGLAtH
	IXfiCRi6DCaGoXjon9v/XKlwt+iqjkZuheGs3w/TKJAFEo5ypvYGTFUIG1lN664GFbOfvx6FZRz
	A7KZG4hJx2vSEvPD8vcb7oOy8tsvbwvhG6l5wHxoN0pJ6ENFqxx8BHBiFVDyLWImXuKIG/PdJLC
	qPjE6Gkub/JWHuN9ScBtvwLrTskeU0sD6SB9PmswV1UtqJhNExwvzA=
X-Received: by 2002:a05:600c:4e88:b0:495:4491:b8c2 with SMTP id 5b1f17b1804b1-4996194e257mr217755905e9.3.1786351824681;
        Mon, 10 Aug 2026 01:50:24 -0700 (PDT)
Message-ID: <2071e8f2-4994-4b8f-affb-999376250e35@gmail.com>
Date: Mon, 10 Aug 2026 10:50:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
 <dda2f05b-2965-4fff-92d9-326619be313b@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <dda2f05b-2965-4fff-92d9-326619be313b@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1786351825-3A2C4034-AA4EDBFB/10/73395122804
X-purgate-type: spam
X-purgate-size: 6384



On 8/6/26 4:48 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> 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 <oleksii.kurochko@gmail.com>
>> ---
>> The corresponding unmap of the IMSIC interrupt file will be introduced
>> separately when the need arises.
> 
> Doesn't the need exist right away? There is ...
> 
>> @@ -342,6 +344,67 @@ static int __init imsic_parse_node(const struct dt_device_node *node,
>>       return 0;
>>   }
>>   
>> +/*
>> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU v
>> + * 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 block,
>> + * 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 hart.
>> + *
>> + * Xen pins each vCPU to a pCPU (v->processor) and assigns it a physical
> 
> ... an apparently wrong assumption here: Xen doesn't normally pin vCPU-s.
> When a vCPU migrates between pCPU-s, clearly the mapping referencing the
> page associated with the old hart needs tearing down again.

The word “pin” was incorrect to use here. What I meant is that a vCPU is 
assigned to a pCPU by scheduler and of course it could be re-scheduled 
by a scheduler to another pCPU (maybe for NULL scheduler such 
re-scheduling don't happen...), and after this assignment happens, the 
IMSIC interrupt file mapping needs to be recalculated.

> 
> That said, since the new mapping will appear at the same GFN, the original
> mapping may simply end up being replaced. If such direct replacement is
> legitimate to do, maybe this could actually be mentioned here?

Yes, the GFN isn’t changed for a vCPU. The plan was for 
map_regions_p2mt() to simply replace the corresponding PTE for the GFN, 
which is why imsic_unmap_guest_file() isn’t really needed now.

I will re-phrase this paragraph to:
  * 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 
where
  * vGEIN = 0 in the hstatus CSR selects no guest external interrupt 
source),
  * requiring the VS-file to be emulated in software.
  *
  * Consequently the mapping installed here is only valid as long as the 
vCPU
  * 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.

> 
>> + * guest file index (guest_file_id) from the vGEIN allocator. A guest_file_id
>> + * of 0 indicates that no hardware guest file is selected (matching the
>> + * architectural behavior where vGEIN = 0 in the hstatus CSR selects no
>> + * guest external interrupt source), requiring the VS-file to be emulated
>> + * in software.
>> + *
>> + * 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 current pCPU.
>> + */
>> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>> +{
>> +    int res = 0;
>> +    struct domain *d = v->domain;
>> +    unsigned int cpu = v->processor;
>> +    vaddr_t gaddr = imsic_cfg.base_addr + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);

I just noticed that imsic_cfg.base_addr isn't really good to use here. 
It should be GUEST_IMSIC_S_BASE instead.

>> +    paddr_t paddr;
>> +    unsigned long guest_stride;
>> +
>> +    /* Nothing to map in the case of sw interrupt file. */
>> +    if ( !vsfile_id )
>> +        return res;
>> +
>> +    guest_stride = vsfile_id * IMSIC_MMIO_PAGE_SZ;
> 
> To me "stride" feels the wrong term here, as there's nothing that repeats.
> "offset" likely would be better, assuming the use of this local variable is
> really deemed worth it, as it's used ...
> 
>> +    paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset +
>> +            guest_stride;
> 
> ... only here.

I will apply your suggestion.

> 
>> +#ifdef IMSIC_DEBUG
>> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
>> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
>> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
>> +#endif
>> +
>> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
>> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
>> +                           arch_dt_passthrough_p2m_type());
>> +    if ( res )
>> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",
>> +               __func__, paddr, gaddr);
> 
> I think you mean to use PRIpaddr with paddr_t (oddly enough there's no
> PRIgaddr).

I’m wondering if it wouldn’t be better to use paddr_t for gaddr as well, 
since technically it is a guest *physical address*. In that case, 
PRIpaddr could be used to print both paddr and gaddr variables.

Also, could this be the reason why PRIgaddr doesn’t exist? Basically, a 
GPA could be considered a physical address, while for a GVA there is 
already PRIvaddr.

Thanks!

Best regards,
  Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 08:53:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 08:53:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387250.1628510 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtLku-0001Bp-KD; Mon, 10 Aug 2026 08:53:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387250.1628510; Mon, 10 Aug 2026 08:53:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtLku-0001Bi-HV; Mon, 10 Aug 2026 08:53:12 +0000
Received: by outflank-mailman (input) for mailman id 1387250;
 Mon, 10 Aug 2026 08:53:10 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wtLks-0001BZ-Jj
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 08:53:10 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtLks-00EdxF-1d
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 08:53:10 +0000
Received: from mail-lf1-f50.google.com ([209.85.167.50])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtLks-001BkH-0e
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 08:53:10 +0000
Received: by mail-lf1-f50.google.com with SMTP id
 2adb3069b0e04-5b0f19bea2fso1675167e87.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 01:53:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=r1aA22qzwxz1bQAx6+Cvagz7egcF6XzF1zJxl+kpU2g=; b=FD5RHpb99RW+ivE3vpPO7FN0/a
	lj7oRsPzYdXH9zdXGFVIait2s/TtE8+K5S0bebOb36crZjgOW05jEfXT6/mGd7y6Yip/VKfL94TVq
	XtU1PRpupnw8IJ5lr4typFSxKMJmet/QhzI1M9YXFdzcNN9/fXV/EIBjs0W35f8+1Rj4=;
X-Forwarded-Encrypted: i=1; AHgh+Rr+oSphyZLvEIYCmw9YNvT0mADyKGm22t3KXBP7UGQWffdQLJ09kNxara6N1yp01+695XRpg2xudFc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySX8KPtVKx0q3/SMGFz4tj+dUkzDOKwvUVRdFO/El2Ux9MCrDL
	U132lQeD7llHOXgae28b3V26FROLDjpyljN9w/v2gMglf1PxkYm0T9oHJ+6lLEfgkjXECoKvc1W
	fIKhT6NaXzJM/i6rzuTnpm3l42IRWEac=
X-Received: by 2002:a05:6512:1294:b0:5ae:bd66:553b with SMTP id
 2adb3069b0e04-5b3092e3ca5mr2591964e87.38.1786351989102; Mon, 10 Aug 2026
 01:53:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAFLBxZZLYxk4ZZZ9++B9qRn_J8X6ochbHr4037mbC8sDfsRqDA@mail.gmail.com>
 <61b9c9fb-3d97-4480-8171-bce986e698a8@suse.com> <31267d9b-022f-48b5-b583-6d9380a22740@suse.com>
 <CAFLBxZYffb3bOS4Zz8m2QX52J6V9-ZonaxPCULoqyRLpPKh-VQ@mail.gmail.com>
 <e9cffe43-f3d2-4af1-a429-7c83e98daec5@suse.com> <CAFLBxZaTLg7fN1HkQvHMR=o=EEZRBPaWHV3+6Wp9bkcaHTmF-A@mail.gmail.com>
 <0f821f2d-70ea-4616-a82e-73a6fe19829e@suse.com> <a9478ddd-247c-46f0-a18c-4bd3140df668@suse.com>
In-Reply-To: <a9478ddd-247c-46f0-a18c-4bd3140df668@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Mon, 10 Aug 2026 09:52:56 +0100
X-Gmail-Original-Message-ID: <CAFLBxZZm12tJCR=BkY-9cwcmzJQ4cp0M4j9z==rSWZFxgOmZ3w@mail.gmail.com>
X-Gm-Features: AUfX_mwg3PTOPUZCBTiSB7Si3ubD5yD3n8sM02G1vEYIRJzzj9hrSt2wIjsU7Bc
Message-ID: <CAFLBxZZm12tJCR=BkY-9cwcmzJQ4cp0M4j9z==rSWZFxgOmZ3w@mail.gmail.com>
Subject: Re: Dual content (text/plain and text/html) on xen-devel (was Re:
 Linux PV domU with >1 vCPU never resumes after xl save/restore)
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel <xen-devel@lists.xenproject.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 5, 2026 at 3:03=E2=80=AFPM J=C3=BCrgen Gro=C3=9F <jgross@suse.c=
om> wrote:
>
> On 05.08.26 15:28, Jan Beulich wrote:
> > On 05.08.2026 14:15, George Dunlap wrote:
> >> You're asking every person who sends an email to xen-devel to remember=
 to
> >> take an action before sending the mail
> >
> > You're by far not the first one to be asked this; you're the first one =
to
> > have an issue with being asked, beyond some companies' IT getting in th=
e
> > way.
> To put it differently: there is a statement on the Xen wiki asking to sen=
d
> only text emails to xen-devel. I'm not the one to ask to relax that rule.
> If you want this rule to be dropped, you probably should raise this topic
> for discussion.
>
> IMHO it is fine to question such guidelines, but just saying you don't
> believe they make sense and therefor ignoring them, especially after havi=
ng
> been asked to obey them, is kind of rude.

The rule seems ambiguous to me.  Here it is for those following along
at home [1]:

> Please post in plain text (i.e. not HTML), word-wrapped to somewehere aro=
und 72 characters.

It never says "only".   Recall that frequently, mailers are configured
to send *only* HTML emails; or, they send HTML emails with plain-text
attachments that do not reflect everything in the HTML version of the
email (perhaps because people actually use the mark-up to convey
information).  Given that, the rule could mean two things:

1. Please post at least plain-text, and expect that the plain-text
version will be the only one read.  Do not post HTML-only, and do not
post an email where the plain text is difficult to read (mis-formatted
or garbled) or is missing information present in the HTML version.

2. Please post in *only* plain text; mail to xen-devel should contain
no HTML attachment whatsoever.

Either way, it seems to me like the expectations could be clarified.

It looks like I can send plain-text only by selecting it for each
individual message.  I may try to do that, but knowing the way my
brain works, I wouldn't be surprised if I frequently forget.

 -George

[1] https://wiki.xenproject.org/wiki/Asking_Developer_Questions


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 09:51:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 09:51:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387270.1628546 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMex-0003P1-CP; Mon, 10 Aug 2026 09:51:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387270.1628546; Mon, 10 Aug 2026 09:51:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMex-0003Oo-92; Mon, 10 Aug 2026 09:51:07 +0000
Received: by outflank-mailman (input) for mailman id 1387270;
 Mon, 10 Aug 2026 09:51:05 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wtMev-00038U-JV
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 09:51:05 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMeu-00Ef1f-34;
 Mon, 10 Aug 2026 09:51:04 +0000
Received: from [217.155.165.12] (helo=localhost.localdomain)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMeu-0066Tx-1O;
 Mon, 10 Aug 2026 09:51:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=sLc17oTn+YSlEdecd+yFeeelQCBxepbt0iFKxuboJsM=; b=WdIje4qxZOspjwdk9yTSKiONQ5
	/1cO8SG4QFUpLyMuhoijKzQcyjVSaC5D8xbTb60afH0NVTgfPa4s/cYVFq0UqtAPOBetluqSLR6RB
	sJgiu/YlcF04cRI6fRrXHG16WiSGm4cUFADAXkS4Zj6GspLGlXVfHAo64ovT+eDuAVh4=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 3/3] build: add compile_commands.json target
Date: Mon, 10 Aug 2026 10:49:45 +0100
Message-ID: <20260810095056.29884-4-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260810095056.29884-1-gwd@xenproject.org>
References: <20260810095056.29884-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a convenience target generating the compilation database from a
built object tree, alongside the other developer conveniences (tags,
cscope, cloc -- the last of which already walks the same .cmd files):

    make -C xen compile_commands.json

The output lands in the object tree root.  For an in-tree build,
clangd and other consumers discover it there automatically when
opening files; for an out-of-tree build, symlink it into the source
tree root (consumers search the ancestors of the file being edited).

Note the database records the compiler invocations actually used.
With a clang build it is consumable by clangd as-is; for a gcc build,
clang-based tools may need a small .clangd configuration
(CompileFlags: Remove/Add) dropping gcc-only flags.

Also add the generated file to .gitignore.

Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
v2:
 - Make compile_commands.json a file target forced via FORCE rather
   than declaring it .PHONY, matching the local idiom and Linux's
   rule for the same target
 - Commit message: the target is not phony; cover out-of-tree builds
---
 .gitignore   | 1 +
 xen/Makefile | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/.gitignore b/.gitignore
index bfc7bdf043..0aa9b801de 100644
--- a/.gitignore
+++ b/.gitignore
@@ -192,6 +192,7 @@ xen/arch/*/include/generated
 xen/build-dir-cppcheck/
 xen/common/config_data.S
 xen/common/config.gz
+xen/compile_commands.json
 xen/cppcheck-htmlreport/
 xen/cppcheck-report/
 xen/cppcheck-misra.*
diff --git a/xen/Makefile b/xen/Makefile
index d39bdfdd53..d10c29162f 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -685,6 +685,9 @@ cloc:
 	    done; \
 	done | cloc --list-file=-
 
+compile_commands.json: FORCE
+	$(PYTHON) $(srctree)/scripts/gen_compile_commands.py -d $(objtree)
+
 # Target used by xen-analysis.sh script to retrieve Xen build system variables
 export-variable-%:
 	$(info $*=$($*))
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 09:51:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 09:51:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387268.1628527 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMeu-0002yt-VZ; Mon, 10 Aug 2026 09:51:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387268.1628527; Mon, 10 Aug 2026 09:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMeu-0002ym-T2; Mon, 10 Aug 2026 09:51:04 +0000
Received: by outflank-mailman (input) for mailman id 1387268;
 Mon, 10 Aug 2026 09:51:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wtMeu-0002yS-46
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 09:51:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMes-00Ef1R-1B;
 Mon, 10 Aug 2026 09:51:02 +0000
Received: from [217.155.165.12] (helo=localhost.localdomain)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMer-0066Tx-2V;
 Mon, 10 Aug 2026 09:51:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=Lee8YbDbDbQD/PEEAUhgQiCV3VG2M8ylKmtExRHl+xg=; b=rhhNW8QKc6pgPjBx97lRlSd+06
	uTwG8e4Wb8L6wbm3TkCTEMvZOmN6xF9jVdobMxidsjyTnfKoEgstkpUj72mdWvMELH50f/XXrq9kF
	Pt8eIbh/PncyV6spL/WmZBKxElkk072jRANCLK7Rx36w0eOQZe24nLiLjG1Sm6AT3KU0=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 1/3] xen/scripts: import gen_compile_commands.py from Linux
Date: Mon, 10 Aug 2026 10:49:43 +0100
Message-ID: <20260810095056.29884-2-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260810095056.29884-1-gwd@xenproject.org>
References: <20260810095056.29884-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Xen's Kbuild-derived build system records the exact command line used
to compile each object in .<target>.o.cmd files.  That is everything
needed to produce a compile_commands.json compilation database, the
format clangd and other tooling consume to provide accurate
cross-referencing (go to definition, find references, call hierarchy)
in LSP-capable editors.

Import scripts/clang-tools/gen_compile_commands.py from the Linux
kernel, unmodified, so that the provenance of the code is easy to
verify (commit 90efe2b9119f, Linux v6.16).

As-is the script produces an empty database on a Xen tree, since
Xen's compile command lines differ slightly from Linux's; the
following patch adapts it.

Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
 xen/scripts/gen_compile_commands.py | 228 ++++++++++++++++++++++++++++
 1 file changed, 228 insertions(+)
 create mode 100755 xen/scripts/gen_compile_commands.py

diff --git a/xen/scripts/gen_compile_commands.py b/xen/scripts/gen_compile_commands.py
new file mode 100755
index 0000000000..96e6e46ad1
--- /dev/null
+++ b/xen/scripts/gen_compile_commands.py
@@ -0,0 +1,228 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) Google LLC, 2018
+#
+# Author: Tom Roeder <tmroeder@google.com>
+#
+"""A tool for generating compile_commands.json in the Linux kernel."""
+
+import argparse
+import json
+import logging
+import os
+import re
+import subprocess
+import sys
+
+_DEFAULT_OUTPUT = 'compile_commands.json'
+_DEFAULT_LOG_LEVEL = 'WARNING'
+
+_FILENAME_PATTERN = r'^\..*\.cmd$'
+_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P<command_prefix>.* )(?P<file_path>[^ ]*\.[cS]) *(;|$)'
+_VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
+# The tools/ directory adopts a different build system, and produces .cmd
+# files in a different format. Do not support it.
+_EXCLUDE_DIRS = ['.git', 'Documentation', 'include', 'tools']
+
+def parse_arguments():
+    """Sets up and parses command-line arguments.
+
+    Returns:
+        log_level: A logging level to filter log output.
+        directory: The work directory where the objects were built.
+        ar: Command used for parsing .a archives.
+        output: Where to write the compile-commands JSON file.
+        paths: The list of files/directories to handle to find .cmd files.
+    """
+    usage = 'Creates a compile_commands.json database from kernel .cmd files'
+    parser = argparse.ArgumentParser(description=usage)
+
+    directory_help = ('specify the output directory used for the kernel build '
+                      '(defaults to the working directory)')
+    parser.add_argument('-d', '--directory', type=str, default='.',
+                        help=directory_help)
+
+    output_help = ('path to the output command database (defaults to ' +
+                   _DEFAULT_OUTPUT + ')')
+    parser.add_argument('-o', '--output', type=str, default=_DEFAULT_OUTPUT,
+                        help=output_help)
+
+    log_level_help = ('the level of log messages to produce (defaults to ' +
+                      _DEFAULT_LOG_LEVEL + ')')
+    parser.add_argument('--log_level', choices=_VALID_LOG_LEVELS,
+                        default=_DEFAULT_LOG_LEVEL, help=log_level_help)
+
+    ar_help = 'command used for parsing .a archives'
+    parser.add_argument('-a', '--ar', type=str, default='llvm-ar', help=ar_help)
+
+    paths_help = ('directories to search or files to parse '
+                  '(files should be *.o, *.a, or modules.order). '
+                  'If nothing is specified, the current directory is searched')
+    parser.add_argument('paths', type=str, nargs='*', help=paths_help)
+
+    args = parser.parse_args()
+
+    return (args.log_level,
+            os.path.realpath(args.directory),
+            args.output,
+            args.ar,
+            args.paths if len(args.paths) > 0 else [args.directory])
+
+
+def cmdfiles_in_dir(directory):
+    """Generate the iterator of .cmd files found under the directory.
+
+    Walk under the given directory, and yield every .cmd file found.
+
+    Args:
+        directory: The directory to search for .cmd files.
+
+    Yields:
+        The path to a .cmd file.
+    """
+
+    filename_matcher = re.compile(_FILENAME_PATTERN)
+    exclude_dirs = [ os.path.join(directory, d) for d in _EXCLUDE_DIRS ]
+
+    for dirpath, dirnames, filenames in os.walk(directory, topdown=True):
+        # Prune unwanted directories.
+        if dirpath in exclude_dirs:
+            dirnames[:] = []
+            continue
+
+        for filename in filenames:
+            if filename_matcher.match(filename):
+                yield os.path.join(dirpath, filename)
+
+
+def to_cmdfile(path):
+    """Return the path of .cmd file used for the given build artifact
+
+    Args:
+        Path: file path
+
+    Returns:
+        The path to .cmd file
+    """
+    dir, base = os.path.split(path)
+    return os.path.join(dir, '.' + base + '.cmd')
+
+
+def cmdfiles_for_a(archive, ar):
+    """Generate the iterator of .cmd files associated with the archive.
+
+    Parse the given archive, and yield every .cmd file used to build it.
+
+    Args:
+        archive: The archive to parse
+
+    Yields:
+        The path to every .cmd file found
+    """
+    for obj in subprocess.check_output([ar, '-t', archive]).decode().split():
+        yield to_cmdfile(obj)
+
+
+def cmdfiles_for_modorder(modorder):
+    """Generate the iterator of .cmd files associated with the modules.order.
+
+    Parse the given modules.order, and yield every .cmd file used to build the
+    contained modules.
+
+    Args:
+        modorder: The modules.order file to parse
+
+    Yields:
+        The path to every .cmd file found
+    """
+    with open(modorder) as f:
+        for line in f:
+            obj = line.rstrip()
+            base, ext = os.path.splitext(obj)
+            if ext != '.o':
+                sys.exit('{}: module path must end with .o'.format(obj))
+            mod = base + '.mod'
+            # Read from *.mod, to get a list of objects that compose the module.
+            with open(mod) as m:
+                for mod_line in m:
+                    yield to_cmdfile(mod_line.rstrip())
+
+
+def process_line(root_directory, command_prefix, file_path):
+    """Extracts information from a .cmd line and creates an entry from it.
+
+    Args:
+        root_directory: The directory that was searched for .cmd files. Usually
+            used directly in the "directory" entry in compile_commands.json.
+        command_prefix: The extracted command line, up to the last element.
+        file_path: The .c file from the end of the extracted command.
+            Usually relative to root_directory, but sometimes absolute.
+
+    Returns:
+        An entry to append to compile_commands.
+
+    Raises:
+        ValueError: Could not find the extracted file based on file_path and
+            root_directory or file_directory.
+    """
+    # The .cmd files are intended to be included directly by Make, so they
+    # escape the pound sign '#' as '$(pound)'. The compile_commands.json file
+    # is not interepreted by Make, so this code replaces the escaped version
+    # with '#'.
+    prefix = command_prefix.replace('$(pound)', '#')
+
+    # Return the canonical path, eliminating any symbolic links encountered in the path.
+    abs_path = os.path.realpath(os.path.join(root_directory, file_path))
+    if not os.path.exists(abs_path):
+        raise ValueError('File %s not found' % abs_path)
+    return {
+        'directory': root_directory,
+        'file': abs_path,
+        'command': prefix + file_path,
+    }
+
+
+def main():
+    """Walks through the directory and finds and parses .cmd files."""
+    log_level, directory, output, ar, paths = parse_arguments()
+
+    level = getattr(logging, log_level)
+    logging.basicConfig(format='%(levelname)s: %(message)s', level=level)
+
+    line_matcher = re.compile(_LINE_PATTERN)
+
+    compile_commands = []
+
+    for path in paths:
+        # If 'path' is a directory, handle all .cmd files under it.
+        # Otherwise, handle .cmd files associated with the file.
+        # built-in objects are linked via vmlinux.a
+        # Modules are listed in modules.order.
+        if os.path.isdir(path):
+            cmdfiles = cmdfiles_in_dir(path)
+        elif path.endswith('.a'):
+            cmdfiles = cmdfiles_for_a(path, ar)
+        elif path.endswith('modules.order'):
+            cmdfiles = cmdfiles_for_modorder(path)
+        else:
+            sys.exit('{}: unknown file type'.format(path))
+
+        for cmdfile in cmdfiles:
+            with open(cmdfile, 'rt') as f:
+                result = line_matcher.match(f.readline())
+                if result:
+                    try:
+                        entry = process_line(directory, result.group('command_prefix'),
+                                             result.group('file_path'))
+                        compile_commands.append(entry)
+                    except ValueError as err:
+                        logging.info('Could not add line from %s: %s',
+                                     cmdfile, err)
+
+    with open(output, 'wt') as f:
+        json.dump(sorted(compile_commands, key=lambda x: x["file"]), f, indent=2, sort_keys=True)
+
+
+if __name__ == '__main__':
+    main()
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 09:51:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 09:51:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387269.1628537 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMew-0003Bp-66; Mon, 10 Aug 2026 09:51:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387269.1628537; Mon, 10 Aug 2026 09:51:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMew-0003Bi-2w; Mon, 10 Aug 2026 09:51:06 +0000
Received: by outflank-mailman (input) for mailman id 1387269;
 Mon, 10 Aug 2026 09:51:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wtMeu-0002ya-H7
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 09:51:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMet-00Ef1T-21;
 Mon, 10 Aug 2026 09:51:03 +0000
Received: from [217.155.165.12] (helo=localhost.localdomain)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMet-0066Tx-0J;
 Mon, 10 Aug 2026 09:51:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=LeEkJR3wDbFHkguioVrXqEE8FwRBWi05Kbj07PLC7cQ=; b=H0+YJe1MKYv4xfnK6X3L3qR+TV
	MeoyYG7k9NupZWxt2mQDA9UXMVZbsr5hNkvOw13kPfxWgQfCVHyAXdTLKYIhE37qSoBU+wZ6R1xae
	ttW/9mrJUlm+dQ3s6vxsvTcQTTgmsAoTGYpGFofRTqcynUf8vI8G9C0XJhqTDptI3AyM=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 2/3] xen/scripts: adapt gen_compile_commands.py to Xen
Date: Mon, 10 Aug 2026 10:49:44 +0100
Message-ID: <20260810095056.29884-3-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260810095056.29884-1-gwd@xenproject.org>
References: <20260810095056.29884-1-gwd@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Two changes from the Linux original:

 - Linux's compiler invocations end with the source file
   ("... -c -o foo.o foo.c"), and the script's line pattern relies
   on that; Xen's cmd_cc_o_c places "-c $<" before "-o" and "-MQ",
   so on a Xen object tree the unmodified script matches nothing and
   produces an empty database.  Adjust _LINE_PATTERN to capture the
   command up to and including "-c" plus the source file, dropping
   the remainder, which database consumers do not need.

 - Reword the docstring and help text to refer to Xen.

The support for reading object lists from archives and modules.order
is unused in Xen but retained to minimise divergence from the
original.

Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
v2: Reword the _LINE_PATTERN comment to describe what the dropped
remainder is, rather than commenting on the change relative to Linux.
---
 xen/scripts/gen_compile_commands.py | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/scripts/gen_compile_commands.py b/xen/scripts/gen_compile_commands.py
index 96e6e46ad1..1c9b05e4dd 100755
--- a/xen/scripts/gen_compile_commands.py
+++ b/xen/scripts/gen_compile_commands.py
@@ -5,7 +5,7 @@
 #
 # Author: Tom Roeder <tmroeder@google.com>
 #
-"""A tool for generating compile_commands.json in the Linux kernel."""
+"""A tool for generating compile_commands.json for the Xen hypervisor."""
 
 import argparse
 import json
@@ -19,7 +19,11 @@ _DEFAULT_OUTPUT = 'compile_commands.json'
 _DEFAULT_LOG_LEVEL = 'WARNING'
 
 _FILENAME_PATTERN = r'^\..*\.cmd$'
-_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P<command_prefix>.* )(?P<file_path>[^ ]*\.[cS]) *(;|$)'
+# Capture the command up to and including "-c" plus the source file, and
+# drop the remainder: all that follows the source file is the output
+# location and dependency-tracking arguments ("-o ...", "-MQ ..."), which
+# database consumers do not need.
+_LINE_PATTERN = r'^(saved)?cmd_[^ ]*\.o := (?P<command_prefix>.* -c )(?P<file_path>[^ ]*\.[cS])( .*)?$'
 _VALID_LOG_LEVELS = ['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
 # The tools/ directory adopts a different build system, and produces .cmd
 # files in a different format. Do not support it.
@@ -35,10 +39,10 @@ def parse_arguments():
         output: Where to write the compile-commands JSON file.
         paths: The list of files/directories to handle to find .cmd files.
     """
-    usage = 'Creates a compile_commands.json database from kernel .cmd files'
+    usage = 'Creates a compile_commands.json database from Xen .cmd files'
     parser = argparse.ArgumentParser(description=usage)
 
-    directory_help = ('specify the output directory used for the kernel build '
+    directory_help = ('specify the output directory used for the Xen build '
                       '(defaults to the working directory)')
     parser.add_argument('-d', '--directory', type=str, default='.',
                         help=directory_help)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 09:51:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 09:51:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387267.1628519 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMer-0002lo-N6; Mon, 10 Aug 2026 09:51:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387267.1628519; Mon, 10 Aug 2026 09:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMer-0002lh-K6; Mon, 10 Aug 2026 09:51:01 +0000
Received: by outflank-mailman (input) for mailman id 1387267;
 Mon, 10 Aug 2026 09:51:00 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wtMeq-0002lb-Tb
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 09:51:00 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMeq-00Ef1C-3A
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 09:51:00 +0000
Received: from [217.155.165.12] (helo=localhost.localdomain)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wtMeq-0066Tx-1X
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 09:51:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	Message-ID:Date:Subject:To:From;
	bh=x1Sp3yZQN5Q3kV7fZfg+oIULJI60NzjOq6ViWln5I7o=; b=e6n0K73pr/L+zZD0Civ/2UCMPB
	8FqMFMjtGFxM1BTedfF+LInuz7cLZhtshkPh+PMfmIVaO+4e6ibJMvMIBYmVuhVW+K0LZtPWkCQIf
	r/M+d5b6jUWVz1SegN/RlXxTSMbqDBBFO3tyg4E8rdk0a0TRFYubPDwpjODXHODT2MAA=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/3] Add compile_commands.json target
Date: Mon, 10 Aug 2026 10:49:42 +0100
Message-ID: <20260810095056.29884-1-gwd@xenproject.org>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Modern tools like emacs' `eglot` rely on compile_commands.json to
gather information about the project.  Import the build script from Linux,
adapting it to the core Xen binary.



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:01:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:01:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387297.1628555 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMoz-0006De-8U; Mon, 10 Aug 2026 10:01:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387297.1628555; Mon, 10 Aug 2026 10:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMoz-0006DX-5Z; Mon, 10 Aug 2026 10:01:29 +0000
Received: by outflank-mailman (input) for mailman id 1387297;
 Mon, 10 Aug 2026 10:01:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtMox-0006DR-Da
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:01:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtMow-00Dt4l-0w
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:01:26 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79a16e-bab6-0a2a0a5309dd-0a2a45018e30-22
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:01:25 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79a175-5984-0a2a45010019-d155dd2cb803-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:01:25 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47362928f65so1390297f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:01:25 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48002145839sm32564405f8f.7.2026.08.10.03.01.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2026 03:01:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786356085; x=1786960885; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=KXQIqdRVAv8DGRTLU1MiBZfEi64arVF7ua5/ksd67b4=;
        b=dVjJaIM2+gdjvKVMk3ahl5PpWQVmT6hiSh6KB7BgVmKXcc86FBCpcsPxToHdi3beFo
         Iy4GNslUXEEYVo6D+oWvkPUziinCcGDOO1dPmmp/RqprbRRwVwxmP9Jr2Q6DBQV5uk44
         SiyqBIQHFeuVAnDp071MhFpF1Y89wU1e5jd1Tr8fMt3eAzAONvksis7xmcBfCAESSTI0
         ZCDXa5yUuNQI+YJZn/+Qzq8gGjY6XnmX1T/bEOlUxi/gaY89czcPI0O7hF6fp0t4/VoT
         KH3AfYxmxnS0hmug3A55vX16oeGm3d/MXedHQxbfIVeN7G3JqfUqvrI0vJKK0cD7viu9
         3a7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786356085; x=1786960885;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=KXQIqdRVAv8DGRTLU1MiBZfEi64arVF7ua5/ksd67b4=;
        b=W27yEKzeHVfBBJwEJAmql18XO3GmrY4lcEdWQkKpMsi+XmKwHB/gyb7ev8Dd+AUhFp
         HK63gKaQrjwX1KbpSpArYvH5D04PZ06oB/vsmkRsy3+wb6GkW9ii0VqGzYBronh4UUhu
         xl0cpocWysQNFBWiH/4qnxkhmO5cWQBHvZlLlxfaib0qqBdMaP/IVRDviOp9OnX8VuGX
         F0UUZFEFzxmEgRtTb/0IZWqT7CWAjVCsRLiBqL0+oZiXbqihQ/qpERqKGGLblpxGDcpL
         NEEh+JDXFaI0RFzS9W4pbLCfuaStRFXbA6XVSmhPvywCqxyCmLpTzDopgHbi8+qpV6lb
         YNyQ==
X-Forwarded-Encrypted: i=1; AHgh+RqQj6MYV1Kj7W4vr1Lub3a1lU34okqL6O5+Klnk0mJ/hoCXQr7eTbt3dNNHK/jXIkEsqtrOCL9Mpjw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4Mr41BDuVmlopKjALyO8j8xZCj81Pa3udt6ah8Dg+R24L1WVo
	Kv7svPKhjvcqxtFBU5SnLDb/lteZvux/S2WeKrsHaUSRy5fGCPjn95Q3tFMF1Q==
X-Gm-Gg: AR+sD11VpJq9wwZx0z72s5kcpS7Yl+40F5u81dkbcNsMpyS4FP7/morShGOo4chhPtc
	fKfRKZ1EtFIMSAhRT0/sfZrOPt3hBdJh9x3Yd3qYcIKdk86JahUq65f/gdwRrEIlpX0ShkQIom2
	YBj+cuxrNdeL/91E+G+d5whRM9sPMFpS8PGInnHgt9xcp4HCowOHT5FgeoO8KXio7Ixsjn1Aw9e
	HC8BduPZIW30wd8aFkXA8lr59yIcw/ZTuIfVZkrCzriM6+QM3qM12GV3zRKRvXJLPk186SQQ23/
	OLDz6+SF0ruLA348OqPCqmdMl7UpkrxdHGoHDR7WXzm7jklsy69OwVLydAxC2+20BavsLoO9xZW
	3MqoW2nLvGuc1YnuUSCRASyypniRRlWUfDmF52LptMhcdBAPOOLaUpeBOQRj+3U/Vm5NeB26byz
	22Q855Fb7cgeuV0JZg879TT7WY1tObXeFxquCkrLW5J209aT37Bz9c6ll+qUBfPf6jswN+vLkzf
	vzapaKo7NDCZ97+W2y7dQ6NZm6ACz4yJbx6NbFfjhM=
X-Received: by 2002:a05:6000:491e:b0:47d:ee9d:90c8 with SMTP id ffacd0b85a97d-47fec4e2910mr68258764f8f.3.1786356071544;
        Mon, 10 Aug 2026 03:01:11 -0700 (PDT)
Message-ID: <55d800f3-6211-4c18-95b6-8682ecfe3330@gmail.com>
Date: Mon, 10 Aug 2026 12:01:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
 <f3e14d18-7732-4a34-9ae4-31cdc89e6495@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <f3e14d18-7732-4a34-9ae4-31cdc89e6495@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786356085-C5540757-6A469E5C/10/73395122804
X-purgate-type: spam
X-purgate-size: 4800



On 8/6/26 4:56 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> Introduce vcpu_aia_init() 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, vcpu_aia_init() will instead be
>> called from a later point in the scheduling path (e.g.
>> continue_to_new_vcpu()), to be introduced in a follow-up patch. Since
>> it will end up being called from a non-__init context, it is not
>> itself marked __init.
> 
> If it's called during scheduling, perhaps vcpu_aia_init() simply isn't
> an appropriate name, and that issue is then also reflected in a
> misleading patch subject?z
I also thought about that while working on the IMSIC interrupt file 
support, but I was thinking of moving it to imsic.c.

Regarding the function name, a better name would be 
vcpu_imsic_hw_vsfile_attach(). Alternatively, we could use a slightly 
more architectural term, such as HGEI/VGEIN, and call it 
vcpu_imsic_hgei_attach(). I think I prefer vcpu_imsic_hw_vsfile_attach().

Considering your observation and question, it could also be placed where 
it will actually be called from continue_new() in the future, so 
riscv/domain.c might be the right place for it but at the moment I think 
it will be better to put it in imsic.c closer to other IMSIC functionality.

> 
>> @@ -36,6 +37,35 @@ bool aia_usable(void)
>>       return _aia_usable;
>>   }
>>   
>> +void vcpu_aia_init(struct vcpu *v)
>> +{
>> +    unsigned int new_vsfile_id;
>> +    int rc;
>> +
>> +    if ( !aia_usable() )
>> +        return;
>> +
>> +    new_vsfile_id = vgein_assign(v);

I will add here also the check that if new_vsfile_id = 0 then we don't 
need to map guest file.

>> +
>> +    /*
>> +     * vgein_assign() returns 0 when no free h/w guest interrupt file is
>> +     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
>> +     * in that case.
>> +     */
>> +    rc = imsic_map_guest_file(v, new_vsfile_id);
>> +    if ( rc )
>> +    {

I missed here vgein_release().

>> +        /* Can't continue w/o correctly mapped IMSIC interrupt file */
>> +        domain_crash(v->domain);
>> +        return;
>> +    }
>> +
>> +    vcpu_guest_cpu_user_regs(v)->hstatus |=
>> +        MASK_INSR(new_vsfile_id, HSTATUS_VGEIN);
> 
> Looks like you're assuming that no other ID was previously stored in that
> field. That can't be quite right when the function is called after the
> vCPU moved to a different pCPU.

I don't use it during the migration process as during migration it is a 
little bit different sequence of how all of that inside the function is 
called; I use it only jumping to new vCPU (continue_new_cpu()), where I 
expect ->hstatus.vgein to be zero because of how the area for the vCPU 
registers is allocated, via vzalloc().

Probably I should consider to rework that and make it re-usable for both 
creating/jumping_to_new_vcpu and migration process.

> 
>> --- a/xen/arch/riscv/imsic.c
>> +++ b/xen/arch/riscv/imsic.c
>> @@ -83,6 +83,19 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v)
>>       return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id);
>>   }
>>   
>> +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id)
>> +{
>> +    unsigned long flags;
>> +    struct vimsic_state *vimsic_state = v->arch.vimsic_state;
>> +    unsigned long pcpu = ( !guest_file_id ) ?
>> +                         NR_CPUS : cpuid_to_hartid(v->processor);
> 
> "pcpu" as a name is misleading when what you store is a hart ID. NR_CPUS
> then also isn't a suitable sentinel.
> 

Agree. I will store here v->processor and NR_CPUS if s/w interrupt file 
is used and then use cpuid_to_hartid() when it will be necessary.

> Also, style nit: The parentheses aren't really needed around the conditional.
> But what's definitely wrong are the blanks immediately inside them.

I will deal with that.

> 
>> +    write_lock_irqsave(&vimsic_state->vsfile_lock, flags);
>> +    vimsic_state->guest_file_id = guest_file_id;
>> +    vimsic_state->vsfile_pcpu = pcpu;
> 
> By implication from the remark above, the field name stored into then also
> is misnamed.

I think with the suggested changed above here everything will be fine.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:10:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:10:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387307.1628564 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMxS-0008Bi-5b; Mon, 10 Aug 2026 10:10:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387307.1628564; Mon, 10 Aug 2026 10:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtMxS-0008Bb-26; Mon, 10 Aug 2026 10:10:14 +0000
Received: by outflank-mailman (input) for mailman id 1387307;
 Mon, 10 Aug 2026 10:10:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wtMxQ-0008BV-P0
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:10:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtMxP-00Ah7v-RK
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:10:12 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a79a382-bab6-0a2a0a5309dd-0a2a4502d82e-4
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:10:11 +0200
Received: from [52.101.65.63]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a79a382-6ca4-0a2a45020019-3465413fe6fa-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:10:10 +0200
Received: from AS4P191CA0001.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:5d5::14)
 by AS4PR08MB7831.eurprd08.prod.outlook.com (2603:10a6:20b:51b::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 10:10:02 +0000
Received: from DB5PEPF00014B90.eurprd02.prod.outlook.com
 (2603:10a6:20b:5d5:cafe::71) by AS4P191CA0001.outlook.office365.com
 (2603:10a6:20b:5d5::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Mon,
 10 Aug 2026 10:10:02 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB5PEPF00014B90.mail.protection.outlook.com (10.167.8.228) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Mon, 10 Aug 2026 10:10:02 +0000
Received: from AM6PR08MB3414.eurprd08.prod.outlook.com (2603:10a6:20b:49::10)
 by GV2PR08MB11418.eurprd08.prod.outlook.com (2603:10a6:150:2c9::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 10:09:26 +0000
Received: from AM6PR08MB3414.eurprd08.prod.outlook.com
 ([fe80::dde8:bf0b:1dc:2a2]) by AM6PR08MB3414.eurprd08.prod.outlook.com
 ([fe80::dde8:bf0b:1dc:2a2%2]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 10:09:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=S2VIJpv8VwAb5nGpLGZco2CwJBxJrdyYG0R62U+CUHku9g3BmuTtMlMlIalp3nI4J7nE7zlNG9ZnMtfOtlZTFLneApMOEKjlMD7Ql6qnWhXJ5IFseiPtR3Th4DDKJaIdYvVWj+X5pw9qFiTe80e8kNtxtL1olXtIBI3mcZ2ZElrHCmVnqKWUHhryztxnYN0XtDj5KDUStZ/CpJ6yD0+vXzgXcAwh1p1jNY18syNeP+u+6Rf/JgIh83qOelSMLB2jjsipz2iZkbwTgJWDRyaE6sg6dhDLCsQdETz/8GqmSbYDfiWc4ukfs2V7R+KGM1DLVLPyWp1yBhymet1S8Hy/JQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sGHMm995GRpz8U1PURPcj9ORNaGW0JAp4jH7dTCsP5Q=;
 b=v1zz21/zgnctBGF04WoXuyaVM+n5aAJ7fY9Xa8kNx9OlnPNxnTdtI9JDT7zRBWR/jESJ5pyShmr0RkuG8+nyLXgWakdbtpE2OZVWzZ+eUDTQyRgEFqA3aCf6liib8Hhtfj3vm2AaqDgdCwqXGXm6YlZZ4tAndD3O+JqoGjcLEYi6cXk3oeCc+meBuwwtRzHf6MriVf+TGaj+b1lUnvcmgr69NfqY2+Aar+yk2YHMoJzcW8QcAQnz9B6smEzBJWx9MuUyohXKTF3uwtUk9MHvCgWX99gHiROvfAMFeXf6r9ur7ozd0DQq4BAbt/wBySamT6N9dGd2+/2GoSoA3Hewxg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linux.ibm.com smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sGHMm995GRpz8U1PURPcj9ORNaGW0JAp4jH7dTCsP5Q=;
 b=X/TDbJ7ebcrgT+EhFqFMXkZrLW/4YZDc8WqKTw7e75/PXAK8hVBv6C+G4sRbqAlFtYUqJEtd2tPQmUS9T18h/wXtC2aoCPud+bRck2pQq9CYkNqoCovk3ytIAzcRbI1Snb/v7MuNLuEi4ToSBvjeB4IQeWdFklu/yB6MC0uCDmQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lu7ea3NWDFQpIQidj/jgqt5/KcmZz0+/1a76oNtofgRKQtEybTY1fyBCnkJjwDsyW7/qX3L6SuD9Uh5OOHCJZv4AsAKYRa7pqgYV5bpV89zK0ET5xvFNA69JUYBVaBtP0v7tg2VZAyWAiuyhnRXyRJmyI6iJTXkdrK8qzmLAX72W8xQB1C86P44R4flTtnd2wfkhUaNejYRyNyzz7kDmWdH4jUVPDlAovM32wCDcB9FIoKAtzVEOFXG21H0s8vbW8kpr9DkQcw+l1uc4z2ouPB+PKPpQgUkqAgSo7BymZKjTQDr1YQgtlWllUFntTrZaE/f0vUEuw7WNLHE7NfbLKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sGHMm995GRpz8U1PURPcj9ORNaGW0JAp4jH7dTCsP5Q=;
 b=INpxTaXgNxtQiT573C05qSNgM1vbGnG8XOl2r9kZCWWdSH5g6G1tsg4YtDB2RnlUfjNClceUU3wo9Klb9vEyafV39ILI5xqT1mB40WqPtm3NOuPUzwS5rBds59divY4qpTl7kf1EzwOf8HLDVNq5OTM7M6etkjs2xop/w+dMmKowx8ZP6A7DWAFSqY0QuOdrj5QS8eOgAYJv13UTwNieAv7yjfEIN10iM0PeUyIVFvRpY3+skcHmBU15LSyj0evBb/FYsMgrn8p9G/rw5d2z6CVDr0Xv7YlNJpp1GNZQl4fgnkZvyFgrCH78oR/UhFhwGdFC2APICbt2IEP03StPWw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sGHMm995GRpz8U1PURPcj9ORNaGW0JAp4jH7dTCsP5Q=;
 b=X/TDbJ7ebcrgT+EhFqFMXkZrLW/4YZDc8WqKTw7e75/PXAK8hVBv6C+G4sRbqAlFtYUqJEtd2tPQmUS9T18h/wXtC2aoCPud+bRck2pQq9CYkNqoCovk3ytIAzcRbI1Snb/v7MuNLuEi4ToSBvjeB4IQeWdFklu/yB6MC0uCDmQ=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <52b5066c-64f6-40bb-9bce-365a18f24265@arm.com>
Date: Mon, 10 Aug 2026 11:09:24 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
To: Alexander Gordeev <agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-2-usama.anjum@arm.com>
 <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
 <eef14e97-20cd-4b08-ae22-7636af049b09@arm.com>
 <4a42c498-58ca-46f4-819f-da14cfba154f-agordeev@linux.ibm.com>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <4a42c498-58ca-46f4-819f-da14cfba154f-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0541.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:319::12) To AM6PR08MB3414.eurprd08.prod.outlook.com
 (2603:10a6:20b:49::10)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	AM6PR08MB3414:EE_|GV2PR08MB11418:EE_|DB5PEPF00014B90:EE_|AS4PR08MB7831:EE_
X-MS-Office365-Filtering-Correlation-Id: 96d6ff17-0376-40a1-bf75-08def6c78b22
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|366016|7416014|1800799024|23010399003|6133799003|4143699003|11063799006|56012099006|10067099003|3023799007|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info-Original:
 mSQv7AaybVdP8lh1lVFlcXP3kGG1cksbK7NhWTSFCBI3T0vZN0VuY2xwLDoDTGWs3W5PpK1u3qICDytNzKUqK9SDvSv7mOhBGz8mCm/T4p9TZ37PTi68WrHC7SBnCBiKxzCJ1ggOVHo04CZfBzLVji6+kBvSiujrzeh5gmb35+T9IoDVoY8YoaoS6y3IVsR/GNlvmGtl5h83qJwaCQGveRteXDi/EkCuqvbd5zatwi9ASQA/qgf3VrS4W7mHxiqhY/nlY5S2wjkycoMVtJy07vAqhKdVMsdnlL25x/Iwz4DXtgLyS6aJ6fYrNzxhQ3+eeZbR9SXZ64cp+5Kn89v3W3otEbkLRadT3SUQngLaRqNN8wIsqyOU8D4Yz99lvY6ZDxbtPq7pRcf3CTk8/Al5XLIF1V5sHok4sc9I5uDs30xNOq+ymqN4IBv9JdPHOaSs/1do4M34tKTFM41rHL/hmWIhHTdx8kq07vwMPgvnN5p7o+qmmoZSROUn3GPPhVdKXZ/LpJhu+sxmyl/Sx++vGNwaHa6REVMYmcFmZNeFvyZ/Y3jMrZuslEQMs0LbQZ2M5AtlfuTDIL4Je4PJTXc6RkGhF6yffaGrIBjR+RmxDHg5eXT2WqHRIQ6DcoTZIfTUIKxMWJPNuZkweSPQ7vN4An9Dr/hNzavgZ0covaVZmjI=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3414.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(7416014)(1800799024)(23010399003)(6133799003)(4143699003)(11063799006)(56012099006)(10067099003)(3023799007)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 opP+uzSVHSCRZK1SnjoVnNSw+fDPOATCeo/EkQ/9TKyIWl0BioAAzSjZhW8oRWRhh0VP/Q1IhuRQUxZSxCsMBYVxG/vcaCq1wzUNu0nQPwwWo+QE2KhmS9+j4egy16LiRS4nTmRLKN+XuBdurSLoP+kaCOoDnMKd3pxwSOThge4lF9ONak39/a4lKk8vojL/Ah1HFZ0d8Go5NuqSGNowzXBjnKGdIXTD/jk32PsEmyqcNbc2TwzdKXhRdNZujBGi+KEGdynA/VP0mrbFbmrciAva+eyNqKFeXEVWYbI8GKT7kDRSysVn0Mgym+JU9ctCXZkrSk7GbR3mC+NkBpOOug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB11418
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B90.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	b22ca400-de72-440a-7983-08def6c77506
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|82310400026|14060799003|36860700016|35042699022|22082099003|18002099003|56012099006|10067099003|3023799007|11063799006|4143699003|6133799003;
X-Microsoft-Antispam-Message-Info:
	cRrjktM/0DgtNP+E1PYP/0TkmX3sW8qhpY9DcxvRfNeCDy8AXNMKLuDb4jtrpgipjzOzFQliODcOOY4RT92OTAXEaRCQ7E8drxYE9301ePLgTjvbj5KSRwz5uxaT8ET0eGm6NCQdUL4MwmspJAR/K/koXYxEQR8PpkShv+2mLpdO/hvV2vVx5phfc7TjVBx1COc/IpRWuf2G9XfZZks0y1EN2Q34OgU0Am9DiPRHRbT6k1rn9/q6qNa5cEuxA1CBtpe3HM/na9j3mE3HhYOgZLW96Ez7DsV+rlaQV0o5bVbUzSqItNRYQhG7ggz04xHaeOzU7WiE1ZHXzQDL9LHzaOccmv9e29M6u4Lu404ORpzuva9lnkueRswUV+7NHztVd2TdweKlYHqyHaQV32baOQHtWWgOCzxPP/i8y2k1EdqfeVivtE+SUotRzWqX4b+wFKf8TE1x6gs3kJEt1vD0O6iQaetLgtFPOD9lcztBFADSza/1D1T64EPGO/iULK9iV+gQ+WcfsG9Xet7UAWNF4verB7aZ71XjTFFAH10J705ZwKAORUbP9qntrVwLy7R5q2qJXHXiMYH28W9O8rJf8X981Y/FdjlFG7a8rlCqezM9+Vx8/f1ahn1fMI1qpujZx87DZcCRqB+fAUZ9biioHBrXp6PqYCzMzAlkIXMokzwZFfsfSA0aonNvmQ21odrDzgb8d/ug7NM2gwuGhDfScw==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(23010399003)(82310400026)(14060799003)(36860700016)(35042699022)(22082099003)(18002099003)(56012099006)(10067099003)(3023799007)(11063799006)(4143699003)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	RZu5a05QZ2FkwUV+f3u/xNJ5M977oWBQ8C7GFk7ktc47z+21uudAEAHRHlGSo5AXhoiep89PdJZItSNMVMKzhUWkAzOcbK1aDFW/Mi7N4e8tpvPJlry/aLrtdxgCK6kaQFJRAsOgE/+7N3cXDyiQfUZw+1Gee/0CnYC2dvf05U3qAEsjAQfdrCTHKQKH5tBZy+2KPL7OM2eCxrNi9Gz0AbGh/+NomfeCMStvdy//InA+bHcfFAOJZTvNIE6SEqd15SnoxmQPwOC0MKvmF+jgtvEYJ1/QNCoj4vbau8Q6BterG7888HbRyE6pSP2pgILQsPNbTd+Am8BVwld3VFN6zngsr09c3yxKP3xFmqxE/jdbWplTagyu0d+50/ntJpmFUgC5AEPtB0UZ7gK6HWiys18iUs6JwL3+Gige/sROB32Eq1eo0jD5flZ0SUXOiW8/
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 10:10:02.5666
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 96d6ff17-0376-40a1-bf75-08def6c78b22
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B90.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7831
X-purgate-ID: tlsNG-720697/1786356610-F04A62AC-69D85AD0/0/0
X-purgate-type: clean
X-purgate-size: 3798

On 09/08/2026 6:45 pm, Alexander Gordeev wrote:
> On Fri, Aug 07, 2026 at 04:24:00PM +0100, Muhammad Usama Anjum wrote:
>> On 07/08/2026 8:09 am, Alexander Gordeev wrote:
>>> On Thu, Aug 06, 2026 at 09:38:39AM +0100, Muhammad Usama Anjum wrote:
>>>> pte_t is used both for logical PTE values and for entries stored in a PTE
>>>> table, so pte_t * does not distinguish a pointer to a copied value from a
>>>> pointer to table storage.
>>>>
>>>> Introduce hw_pte_t as the generic name for a PTE table element. Define it
>>>> as a macro alias of pte_t by default. When an architecture selects
>>>> ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead.
>>>> This preserves the representation while allowing converted architectures
>>>> to enforce the distinction at compile time.
>>>>
>>>> Keep the C type definitions behind an __ASSEMBLY__ check because
>>>> architecture assembly sources can include this header indirectly. Include
>>>> asm/page.h so consumers such as linux/vmalloc.h retain the page definitions
>>>> they previously obtained from that header.
>>>>
>>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
>>>> ---
>>>> Changes since RFC v1:
>>>> - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition.
>>>> - Exclude the C type definitions from assembly sources.
>>>> - Update the description for the new opt-in model.
>>>> ---
>>>>  MAINTAINERS                   |  1 +
>>>>  include/linux/pgtable_types.h | 17 +++++++++++++++++
>>>>  mm/Kconfig                    |  3 +++
>>>>  3 files changed, 21 insertions(+)
>>>>  create mode 100644 include/linux/pgtable_types.h
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index e9c8567308a75..7169bea968cf5 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -16982,6 +16982,7 @@ F:	include/linux/mmu_notifier.h
>>>>  F:	include/linux/pagewalk.h
>>>>  F:	include/linux/pgalloc.h
>>>>  F:	include/linux/pgtable.h
>>>> +F:	include/linux/pgtable_types.h
>>>>  F:	include/linux/ptdump.h
>>>>  F:	include/linux/vmpressure.h
>>>>  F:	include/linux/vmstat.h
>>>> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
>>>> new file mode 100644
>>>> index 0000000000000..70c3edd00a01b
>>>> --- /dev/null
>>>> +++ b/include/linux/pgtable_types.h
>>>> @@ -0,0 +1,17 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +#ifndef _LINUX_PGTABLE_TYPES_H
>>>> +#define _LINUX_PGTABLE_TYPES_H
>>>> +
>>>> +#include <asm/page.h>
>>>> +
>>>> +#ifndef __ASSEMBLY__
>>>> +
>>>> +#ifdef CONFIG_ARCH_HAS_HW_PTE_T
>>>> +typedef struct { pte_t __pte; } hw_pte_t;
>>>
>>> On s390 it fails to compile once we do typedef hw_pte_t *pgtable_t
>>> in asm/page.h. m68k, powerpc and sparc may also have such problem.
>>>
>>> The below declaration helps to resolve it using forward declaration
>>> and without meddling with headers, though I do not like it much:
>>>
>>> typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
>> Thank you for testing it out on s390.
>>
>> As __hw_pte_t isn't being used yet in this series, would s390 enablement
>> patches add __hw_pte_t to this definition?
> 
> I hope there is a better solution. As I noted m68k, powerpc and sparc
> may also be affected, so I would suggest to look into those as well.
> I would prefer s390 to use the generic one rather than circumvent a
> compile error in a custom way.
I've just checked all of these architectures by doing dirty conversion and
reached to same conclusion that __hw_pte_t must be defined like:
 
typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;

I'lll add __hw_pte_t to this series. (Initially on last email I'd thought
that the first user would add __hw_pte_t. But it seems sensible to add it
now)

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:20:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:20:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387316.1628572 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtN7F-0001on-0t; Mon, 10 Aug 2026 10:20:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387316.1628572; Mon, 10 Aug 2026 10:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtN7E-0001og-UP; Mon, 10 Aug 2026 10:20:20 +0000
Received: by outflank-mailman (input) for mailman id 1387316;
 Mon, 10 Aug 2026 10:20:19 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19feb2ff2f9000e099@swg.vates.tech>)
 id 1wtN7D-0001oZ-6v
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:20:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtN7C-00Dzem-De
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:20:18 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19feb2ff2f9000e099@swg.vates.tech>)
 id 6a79a5cb-8faa-0a2a0a5109dd-0a2a45048b74-34
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:20:18 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19feb2ff2f9000e099@swg.vates.tech>)
 id 6a79a5e1-b57f-0a2a45040019-b9ff1c2396d3-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:20:18 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19feb2ff2f9000e099.002 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 10:20:15 +0000
Received: from [192.168.1.61] (155.223.66.37.rev.sfr.net [37.66.223.155])
 (Authenticated sender: ngoc-tu.dinh@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 60F3B81C5E;
 Mon, 10 Aug 2026 12:20:15 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=dwh4fyIqqBY7gZ43AJfLXV5jUYa61S3uFDhcudB0Tfk=;
 h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references:feedback-id;
 b=YGu7j7qiGvDn7d/nUlypyg4U69Pen65i0Y9F1mJzQjg0Igl8Syhv2Y1oYdEicqoWkGVx4uKUt
 lRTgzYrTwlz7swJRNJTTKQMfDYKBJoHQM0y8HOV+CNtgb/FLGfFLbesI2QREHPwsx3u3gC3/FAa
 oX5xj+diAH7Gyb7DCH6FSLAGtiXLEqIM7hR4mNFsixDvyQtoMIpLnfi3ZID3JiMeXGKE6qbeRP0
 6H1ewuIX8ZfSqp4tNGYvnvx/mGjOdIv38km7p5C9JmMNRIo/eEG8ndciRt8Rltl5WHI0NVwfW6A
 Zl9hcPcQd+waNuNlhaoaCnjCYmypLsvm0JAQjaAf6RDw==
X-Zone-Loop: 3e4d87dda4f87756c6df8b0e14db86ef75f8ee700b9e
x-campaign-type: default
x-transaction-id: 1d10f385-683d-41bf-a44c-f7a4b66d3af9
x-swg-uid: 01-b4e90962-d767-4f93-96db-19a98ff1c15a
X-Mailer: Sweego
Message-ID:
 <1786357216.8631fc262581453bbf619ec5b2062170.19feb2ff2f9000e099@vates.tech>
x-swg-bid: 1786357216.8631fc262581453bbf619ec5b2062170.19feb2ff2f9000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Mon, 10 Aug 2026 12:20:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: help Windows PV Drivers and Windows Server 2025
To: "H. Bakker - Hunenet B.V." <h.bakker@hunenet.nl>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <AM9PR05MB7665DF8E88357A35E50C1CA6EDD12@AM9PR05MB7665.eurprd05.prod.outlook.com>
Content-Language: en-US
From: Tu Dinh <ngoc-tu.dinh@vates.tech>
In-Reply-To: <AM9PR05MB7665DF8E88357A35E50C1CA6EDD12@AM9PR05MB7665.eurprd05.prod.outlook.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.1fe4.78f79b667744f805.19feb2ff0d7.9ad1b47bc5e7f8fb=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786357215448
X-purgate-ID: tlsNG-ebf023/1786357218-52ECEB50-8C6F1673/0/0
X-purgate-type: clean
X-purgate-size: 1312

---=Part.1fe4.78f79b667744f805.19feb2ff0d7.9ad1b47bc5e7f8fb=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07/08/2026 11:59, H=2E Bakker - Hunenet B=2EV=2E wrote:
> This concerns the installation of the Windows PV Drivers on Windows=20
> Server 2025=2E
>=20
> When running *"dpinst=2Eexe"*, the installation fails with the message=
=20
> *"Install failed"*=2E
>=20
> The affected driver version is:
> *DriverVer=3D07/13/2023,9=2E1=2E0=2E1*
>=20
> I am currently using an older version that works correctly:
> *DriverVer=3D12/05/2019,9=2E0=2E0=2E2*
>=20
> Kind regards, Henry Bakker=2E
>=20

Hello,

Looks like you're trying to install the downloads from the Xen Project=20
website (xenbus=2Etar and related)=2E These downloads are not digitally=20
signed, nor are they kept up-to-date with upstream development=2E You can=
=20
rebuild the drivers from source repos [1] (requires enabling testsigned=20
mode), or download a signed build from downstream distributions=2E

[1] https://xenbits=2Exen=2Eorg/gitweb/?a=3Dproject_list;pf=3Dpvdrivers/wi=
n


-- 
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.1fe4.78f79b667744f805.19feb2ff0d7.9ad1b47bc5e7f8fb=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387324.1628582 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHE-00041L-TU; Mon, 10 Aug 2026 10:30:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387324.1628582; Mon, 10 Aug 2026 10:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHE-00041E-Qn; Mon, 10 Aug 2026 10:30:40 +0000
Received: by outflank-mailman (input) for mailman id 1387324;
 Mon, 10 Aug 2026 10:30:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHD-000411-A5
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHC-00DyfU-Bz
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:38 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a842-bab6-0a2a0a5309dd-0a2a4504c9d8-8
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:38 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a84e-b57f-0a2a45040019-d1558030e42d-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:38 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso12486365e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:38 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786357838; x=1786962638; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0MRp6EbxOKuhWqTL6XGBFd4TDttNHZTC51Obk9EfEk8=;
        b=XyDVjGAa3f48bZvE+Htj4K9LJd27o2MOr+PnzjgH+eM3CvACnc+m18z18ZlNUpv7S6
         1YTcjHdvsffy2QEU/kK4q5u4gGic1qTpzA1cgjcUzO88hiUfWD+bqScJK+8HiGIanW+x
         kishQga3hBQ4YlOXk3wIJ5K0UTsbj6QXVJOS3F/FhyDKAV1McuGggR2s+3/brSQV6own
         Oxdmq3k2LGPTKiG57ImAtuebH3Xtf84eaV0OfdJXg+QFBUJKUw1LC19CwSRaeNchLqNP
         5YR48i6u+FNu71dTLGByG0X087ctvIZv6EYUWEXfmtTjklv0N5/2s5Z7z2D6VRGTUi/6
         73lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357838; x=1786962638;
        h=content-transfer-encoding:content-type:mime-version: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=0MRp6EbxOKuhWqTL6XGBFd4TDttNHZTC51Obk9EfEk8=;
        b=nyQ6ARqwrHOZOOcJYhqDmM+KQ7GSJ3yIQ1nYPvW/hul1Y47uwkhZiAjLb4QwU/6bnM
         hcvhRz6x0/84sieCvfRW0VZJ1QyGijLGHHdEdmYTMTDcSikEIUtAMaiAn+sSovZnPiEZ
         CaH6DggkxGRcrmYCBLVDegZ4VOHsRV3KFy7BDZiG0LK9/fbm9mejd4mlWd5lNBxKdJY3
         BiDW8pWK7OTVZ5WtoOM2vWEfiiJffE38GIb8/NiB8JyupwcPwdu1utJsMgdTJ5S14n3V
         g+kdHgIFAvkZAvSOzW0LDrskEFupHaMAkVdC2gGPlW626Q4khSCqoXCG7uRDeb9vP+L7
         szuA==
X-Gm-Message-State: AOJu0YxqBXt1hMEVQ7AgJX86SOdqNoNdkOaEgmESy9j8EbmPsRSyzaLk
	J3AsdSZULoO/yLc+hvuhAnrlHjl5YMs96eRyErPoDlNNdzYR3/C4zdkSgT/XEzCoqEQ=
X-Gm-Gg: AR+sD110pFA3YKSNouIQCb6Uqd0v1QppYfRss7xrG77Jum+7NOcL3XavUZ3HiOwvfhj
	4dzxjvDyE7sGCpJ2tKi9eaXwP7LpypIvj2N/45ix1NSAsVvlSeYaDCqOaP2iuK9e64EpN3jhJ3p
	AvTtUD53/a/lUDgom57XWrQmWHDChqVH+/w7e/n0ZKxeHu2AFwNJ+wY/HlEc8dSnRn1pHSFEsCi
	oFX3xK6UuIgtijPCpkqUyN5PddCGFA/1sSTqATz3KqV9PDMhQDn/NT7bso9p94V5fAYLHbaoKNT
	mMN0wdUWid9fi9fBBn/nNzb2F5+/mjzcjyp74LDVxTAE7uLgeMvy7werGHaTbDrSno7bHDyz611
	iC5kFhx1i04O+PhtTuERFyIHMAwliCu5qR4GxbTQFd8HmXCs0HktI7+0Mo7P2qVPlDqx8CaLzYb
	uOQb/KMkeLeEbkIJp8QwjQTz1KA0SRvfnlhkbPh0x2IydwGfp5qNPAQ3TFrmBX54vQ+sK3poWnj
	C97aU1JGsDIVvWEKnjr/dL7AGz3g7tkl0XQ8Czn7TUi2FE4kRA=
X-Received: by 2002:a05:600c:4f49:b0:499:4892:e84e with SMTP id 5b1f17b1804b1-4995e0d03a8mr270212795e9.11.1786357837543;
        Mon, 10 Aug 2026 03:30:37 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH v10 0/10] xenguest optimisations
Date: Mon, 10 Aug 2026 11:30:03 +0100
Message-ID: <20260810103018.54564-1-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1786357838-530CDB50-1831BAB8/0/0
X-purgate-type: clean
X-purgate-size: 3210

Reduce number of allocations sending memory state.

Implement and use new Xen and Linux kernel ABI to copy foreign memory.
This new ABI allows to replace the expensive  map/copy/unmap sequence
with a single call.

Changes since v1:
- add commit to cache up to 4 pages in hypercall;
- add other 2 commits reducing chunks passed to write/writev.

Changes since v2:
- update patches commit prefixes;
- add other 2 optisations.

Changes since v3:
- address some comments;
- add patches for foreign copy optimisation.

Changes since v4:
- added Reviewed-by;
- improved commit messages;
- other minor fixes, see individual commits.

Changes since v5:
- avoids potential buffer underflow if nr_pages is 0 calling cache_alloc;
- do not overwrite errno if xenforeignmemory_map fails;
- lot of changes to "implement new foreign copy hypercall", see specific
  commit.

Changes since v6:
- removed merged patch;
- keep only optimization commits for now;
- improve comments;
- merged "fill directly iov structure collapsing them" and moved it;
- split "allocate various migration arrays just once";
- add a commit for memory checks using Valgrind.

Changes since v7:
- removed merged commits;
- minor style fixes.

Changes since v8:
- added Reviewed-by;
- remove useless check;
- remove useless memset;
- initialize variables while declaring them.

Changes since v9:
- add back commits for foreign copy;
- rework page permissions check;
- do not limit domain for new hypercall;
- add back some memory check using Valgrind and sanitizers;
- fixed compatibility for ARM;
- minor fixes.

Edwin Török (3):
  libs/call: cache up to 4 pages in hypercall bounce buffers
  libs/guest: allocate various migration arrays just once
  libs/guest: use foreign copy API during migration

Frediano Ziglio (6):
  libs/guest: move batch_pfns into a separate structure
  libs/guest: use Valgrind or sanitizers to detect various buffer
    overflows
  libs/guest: add xg_foreignmemory_copy_{from,to}
  xen: implement new foreign copy hypercall
  privcmd: Add definition for new Linux privcmd to access new Xen
    hypercall
  libs/guest: use new hypercall if available

 tools/config.h.in                     |   6 ++
 tools/configure                       |  12 +++
 tools/configure.ac                    |   3 +-
 tools/include/xen-sys/Linux/privcmd.h |  10 ++
 tools/libs/call/buffer.c              |  34 ++++--
 tools/libs/call/core.c                |   3 +-
 tools/libs/call/private.h             |   8 +-
 tools/libs/ctrl/xc_private.h          |  61 ++++++++++-
 tools/libs/guest/xg_sr_common.c       |  86 +++++++++++++++
 tools/libs/guest/xg_sr_common.h       |  25 ++++-
 tools/libs/guest/xg_sr_restore.c      |  78 +++++++-------
 tools/libs/guest/xg_sr_save.c         | 134 +++++++++++------------
 xen/common/memory.c                   | 149 ++++++++++++++++++++++++++
 xen/include/public/memory.h           |  45 +++++++-
 xen/include/xsm/dummy.h               |  14 +++
 xen/include/xsm/hooks.h               |   2 +
 xen/xsm/flask/hooks.c                 |  10 ++
 17 files changed, 552 insertions(+), 128 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387325.1628587 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHF-00043N-4S; Mon, 10 Aug 2026 10:30:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387325.1628587; Mon, 10 Aug 2026 10:30:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHF-00042i-0W; Mon, 10 Aug 2026 10:30:41 +0000
Received: by outflank-mailman (input) for mailman id 1387325;
 Mon, 10 Aug 2026 10:30:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHD-000418-UB
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHD-00GuV3-Au
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:39 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a84a-8faa-0a2a0a5109dd-0a2a4505b244-16
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:39 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a84f-4cb1-0a2a45050019-d1558032e1c9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:39 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49554ebb87dso16345825e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:39 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type: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=1786357839; x=1786962639; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=wimWBVOYQqwPaXI8zWtV5Ue4b9r9c1tb/eSNhf7mAu8=;
        b=pMUY2/gLuvqcZpxqSH9bQjQUMiMRz7VNj44/wMATq5FDXfYlUUIHNtcIYMkFnioD7g
         aTT7jQdzjZTihTKOfEo5Pde+rm00UqxP/T6/VySpfQCWoX4K6Qzn2O9x2BZLzaqZC3LE
         o2GDwMlUqxmJDBYBGkLxOMhS67xdP3Yr92cBGltYdV30jY4wMiTrqd6RMwafWIpYmhgC
         QbCjAn1IrLBuL3Sj2Bl3pJGKvcZNsJvOuTenpekm0z+GLT2/eDyfRVEIgJFEvA6t0/+r
         l53C1HVlx9ekfr58cJ/+vf9Iwl386KtspUwcUzQ9UMYYbPRBhoLPT1gMo2ujAg2ZC0v4
         YB+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357839; x=1786962639;
        h=content-transfer-encoding:content-type: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=wimWBVOYQqwPaXI8zWtV5Ue4b9r9c1tb/eSNhf7mAu8=;
        b=OB+K3eIcuyxWNy5hXxSBPTa5HvZRO4xdTQKS0ZumNLvtq3H6LSdwywjghNP5TwinWm
         shTrgpYsiPBoFP5Yy+2uYh2pQnFJHFBrC4MgpULSflAPDnobXJNQr9CKykfyXTASr8qa
         +P3jzh0JBxrdMmwQQfFg6NWS1Gay+Dfui03gxNOONBL3kZzFpAzjIadPgS0+x7AM+t/P
         tZmJ/W5pW/ptP7+wuBIHvV02xU/vzs1w/thrAq1pDWwtY0WgZkafNTvhwPEwALl7cyPf
         oL4NdBgx7EJEXeppUuyhewiBCSoLsPZRPPIrWwL1cO8boF9ABuNfp1/1JJUV3zyNmyIs
         zVPQ==
X-Gm-Message-State: AOJu0Yz80MEPM5A+eXTfuMOoSkluJ7x7I0HaSViyJSG6dPAhixzQiX7z
	oRAY0/UFQMVUYP8+kjitNrqb0RSQtPafWrrLVa1PZ7hxztYgKpbWoxgi7qAFjHP8RRs=
X-Gm-Gg: AR+sD114K50KmHlnBQk48gKRilgm2Wm66uS171Rf1h2CNmYJa9PpVK/zYZliOswxEQ9
	l/bYD8WRLmqVmSCNDDpuyMGWXCkJXXhukzMIoH40CNVCzXaY/AUAUVSVi/7CoF6o+0t9xSZHsFW
	g6qOf3N5HBsWWlqfLVFiTva2P991QUpWsdtfk7Fq6Pgsx1n2Mt6XPsgblGl9RMB7rt38/fsbEKr
	TkW7JEp/wFE3pzoWMwQCVUnM3xUXVwzhpd/5ozVe/rU68EFnbkNpqXBz3tLdSd9AZUGzAqe5i7e
	sW5c1J1PkbD9/kh5dh8br6dubNV7GepIL5cU815WYQbeFj3j53YyUlMbg/akOwksKc0UKVKDmrD
	DeKkXWxOjAAAtZzK3wMA1JH7uG5RVB6W8lX39f6xB9tx45RoUfGNMOYgeeLbcTWKmO7Glw1srKl
	1eiNevzc/ozaUyKqlHSaWCPAVk5xkeMzbnoJp2M1Dwc3mU+uDEKTsb2qeexS9qTeFQs6HgNYGuy
	9W6yeV7NTFqkzXwiAFsH1dRkFWF0VJ6QViN7ID+OgwYgRT/Jxza
X-Received: by 2002:a05:600c:4715:b0:493:cefc:d113 with SMTP id 5b1f17b1804b1-4996195884bmr212355625e9.5.1786357838544;
        Mon, 10 Aug 2026 03:30:38 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= <edwin.torok@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: [PATCH v10 1/10] libs/call: cache up to 4 pages in hypercall bounce buffers
Date: Mon, 10 Aug 2026 11:30:04 +0100
Message-ID: <20260810103018.54564-2-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1786357839-F74BC2A1-E42AB6FA/0/0
X-purgate-type: clean
X-purgate-size: 5706

From: Edwin Török <edwin.torok@citrix.com>

During migration there are a lot of mmap/munmap calls,
because xc_get_pfn_type_batch() exceeds the default hypercall bounce
buffer cache size, and needs to allocate every time it is called.

munmap() is slow, especially in a PV Dom0 (takes an emulation fault),
so is best avoided.

Eventually it'd be good if the memory pool from  xmalloc_tlsf.c
was reused here, but for now make it handle the commonly encountered
sizes (so far up to 4 pages).

Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
Changes since v2:
- change prefix in subject.

Changes since v4:
- fix off-by-one bug.

Changes since v5:
- avoids potential buffer underflow if nr_pages is 0 calling cache_alloc.

Changes since v6:
- align changes made to cache_alloc to cache_free.

Changes since v7:
- use "unsigned int" instead of "unsigned".

Changes since v8:
- added Reviewed-by.
---
 tools/libs/call/buffer.c  | 34 +++++++++++++++++++++++-----------
 tools/libs/call/core.c    |  3 ++-
 tools/libs/call/private.h |  8 +++++---
 3 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/tools/libs/call/buffer.c b/tools/libs/call/buffer.c
index 155e4f9d43..b7d00185c4 100644
--- a/tools/libs/call/buffer.c
+++ b/tools/libs/call/buffer.c
@@ -49,6 +49,9 @@ static void *cache_alloc(xencall_handle *xcall, size_t nr_pages)
 {
     void *p = NULL;
 
+    if ( nr_pages == 0 )
+        return NULL;
+
     cache_lock(xcall);
 
     xcall->buffer_total_allocations++;
@@ -56,13 +59,13 @@ static void *cache_alloc(xencall_handle *xcall, size_t nr_pages)
     if ( xcall->buffer_current_allocations > xcall->buffer_maximum_allocations )
         xcall->buffer_maximum_allocations = xcall->buffer_current_allocations;
 
-    if ( nr_pages > 1 )
+    if ( nr_pages > ARRAY_SIZE(xcall->buffer_cache) )
     {
         xcall->buffer_cache_toobig++;
     }
-    else if ( xcall->buffer_cache_nr > 0 )
+    else if ( xcall->buffer_cache_nr[nr_pages-1] > 0 )
     {
-        p = xcall->buffer_cache[--xcall->buffer_cache_nr];
+        p = xcall->buffer_cache[nr_pages-1][--xcall->buffer_cache_nr[nr_pages-1]];
         xcall->buffer_cache_hits++;
     }
     else
@@ -79,15 +82,18 @@ static int cache_free(xencall_handle *xcall, void *p, size_t nr_pages)
 {
     int rc = 0;
 
+    if ( nr_pages == 0 )
+        return 0;
+
     cache_lock(xcall);
 
     xcall->buffer_total_releases++;
     xcall->buffer_current_allocations--;
 
-    if ( nr_pages == 1 &&
-         xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
+    if ( nr_pages && nr_pages <= ARRAY_SIZE(xcall->buffer_cache) &&
+         xcall->buffer_cache_nr[nr_pages-1] < BUFFER_CACHE_SIZE )
     {
-        xcall->buffer_cache[xcall->buffer_cache_nr++] = p;
+        xcall->buffer_cache[nr_pages-1][xcall->buffer_cache_nr[nr_pages-1]++] = p;
         rc = 1;
     }
 
@@ -108,17 +114,23 @@ void buffer_release_cache(xencall_handle *xcall)
     DBGPRINTF("current allocations:%d maximum allocations:%d",
               xcall->buffer_current_allocations,
               xcall->buffer_maximum_allocations);
-    DBGPRINTF("cache current size:%d",
-              xcall->buffer_cache_nr);
+    for ( unsigned int i = 0; i < ARRAY_SIZE(xcall->buffer_cache_nr); ++i )
+    {
+        DBGPRINTF("cache current size[%u pages]:%d", i+1,
+                xcall->buffer_cache_nr[i]);
+    }
     DBGPRINTF("cache hits:%d misses:%d toobig:%d",
               xcall->buffer_cache_hits,
               xcall->buffer_cache_misses,
               xcall->buffer_cache_toobig);
 
-    while ( xcall->buffer_cache_nr > 0 )
+    for ( unsigned int i = 0; i < ARRAY_SIZE(xcall->buffer_cache_nr); ++i )
     {
-        p = xcall->buffer_cache[--xcall->buffer_cache_nr];
-        osdep_free_pages(xcall, p, 1);
+        while ( xcall->buffer_cache_nr[i] > 0 )
+        {
+            p = xcall->buffer_cache[i][--xcall->buffer_cache_nr[i]];
+            osdep_free_pages(xcall, p, i + 1);
+        }
     }
 
     cache_unlock(xcall);
diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index 02c4f8e1ae..dd8877c1a0 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -14,6 +14,7 @@
  */
 
 #include <stdlib.h>
+#include <string.h>
 
 #include "private.h"
 
@@ -44,7 +45,7 @@ xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags)
     xentoolcore__register_active_handle(&xcall->tc_ah);
 
     xcall->flags = open_flags;
-    xcall->buffer_cache_nr = 0;
+    memset(xcall->buffer_cache_nr, 0, sizeof(xcall->buffer_cache_nr));
 
     xcall->buffer_total_allocations = 0;
     xcall->buffer_total_releases = 0;
diff --git a/tools/libs/call/private.h b/tools/libs/call/private.h
index 9c3aa432ef..8e6a208975 100644
--- a/tools/libs/call/private.h
+++ b/tools/libs/call/private.h
@@ -31,13 +31,15 @@ struct xencall_handle {
     Xentoolcore__Active_Handle tc_ah;
 
     /*
-     * A simple cache of unused, single page, hypercall buffers
+     * A simple cache of unused, small, hypercall buffers
+     * buffer_cache[i]'s size is (i+1) pages
      *
      * Protected by a global lock.
      */
 #define BUFFER_CACHE_SIZE 4
-    int buffer_cache_nr;
-    void *buffer_cache[BUFFER_CACHE_SIZE];
+#define BUFFER_CACHE_NRPAGES 4
+    int buffer_cache_nr[BUFFER_CACHE_NRPAGES];
+    void *buffer_cache[BUFFER_CACHE_NRPAGES][BUFFER_CACHE_SIZE];
 
     /*
      * Hypercall buffer statistics. All protected by the global
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387327.1628609 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHI-0004eP-LO; Mon, 10 Aug 2026 10:30:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387327.1628609; Mon, 10 Aug 2026 10:30:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHI-0004eF-H9; Mon, 10 Aug 2026 10:30:44 +0000
Received: by outflank-mailman (input) for mailman id 1387327;
 Mon, 10 Aug 2026 10:30:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHH-0004Qx-Cx
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHG-000B9X-Pv
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:42 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a84d-2eae-0a2a0a5409dd-0a2a450ce5b4-16
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:42 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a852-f479-0a2a450c0019-d155802fe454-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:42 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso12486915e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:42 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type: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=1786357842; x=1786962642; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=2NxxLpvMxvCVNIhMLzqk93Yy2TTgs6s75lOWPEK4aL8=;
        b=WWMY34C84Gr2gIQEaxu6lLq5DNlTNwYhWCjGo99tLHoTTAvvrEBhKdpXVAbhAER/dI
         xShAcUzSH6rwIcYm8/jy0ws8yXx3PHzxsdqcnLu9p6Rb0sJl9/ZlsXwRzaKKOKdODe/4
         J9uRIaqeGCwJM8sbY+y7+si3q4684NniBbD+rI5k567JdZnhd3bEkF7Xa6ghzFaLtKCQ
         tT8WhcB1XQlMhrssCb9KlpBt6P/u9vm3nYM1M7e5wpiSZcZaA4KfkceT1D0cUwKUBsQX
         81rDHFTEYpQ5FXn2siLlCQUWryUYDOpzVtczDUlX70JZsJFUW0HTuq10BSELoc7RQsdS
         8cuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357842; x=1786962642;
        h=content-transfer-encoding:content-type: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=2NxxLpvMxvCVNIhMLzqk93Yy2TTgs6s75lOWPEK4aL8=;
        b=U7Ob54e4udQPEf4hbQRTlSHgq9WxFYvsq03m0qBkGVFVETVl4Ivo/8qhTQOA6/iVNn
         NXsuhZD9lxC4+mojFx+Ex/s+nsuYPMBSK2cIYtSWQfEwJN7ZG0V974NK0HIhQzqev7HI
         nzQ4AtzUAuHYamubwQiBHJZ5M32zL30vy8ADHht9NxRM5l8M5Jb1ghr1YWbSK4e7xkjL
         CyFqYVIAMIk+wwomy3235oUGmUQKKU9+XZSwTtHx6yjis9MdHFc8/g/4SBosJG0HE4/K
         2OG0/PfZjjfr0b7y5DX1ptWw0WJqBPpMw0a0iEttFYkzDDu1YnkPBljW9hXi2EMRr/+k
         3MPQ==
X-Gm-Message-State: AOJu0YzhzZyR7f75N2MndHdI5Ud08seJEGcnNv9H1zjFOj4tqTPU5QR/
	4b3juZr/SJiP6s/I8wP2KYGCXshnWLGKPbmhIHBddunDTr6ripkibmUxaNtPtC5RRwg=
X-Gm-Gg: AR+sD13xEAgsLrqQ2r8yol4nTt/olGWo8B0mM7KXqF5WR1W9ONmPHWLJSS/8lMXVmlF
	Ptae/Ae/9/Dn2P/t/hIwydTf0VCpyq/PZCF2wPRVMA9x6es2bVLSv1n5mQtIa2yp8bXM2nfzCSG
	LKmkrIjEJ/b0y+0qWnnT+A3xtrnc5loBoeUHOOhIrj+Mp8SUpHNHjvfC8Dqh+SnkVoOXCCOXLjO
	XE2/qbTHDt3g8u9oJm42wqzV4oU/rP0AN14GWC2XzNY9OiUwSSVONBEDSo1neeOGK3HioC/odcx
	1RCHpCsVLkTbOspK+EHsIF+Q4ViSdVGYhfr9YF53cmIEVCOsCwLbF0f21vxn1vuzwMGFgs6eVMA
	FnJDinlqHbKshAYE2j5Xo5WKB01LxSV2/+SBPfK1wscaGbQmJqgx2Jv8ep/0na14bWRcU8AogS3
	GpKFk6mFUZ7IOIRoqNLuk2HrB482qESPoXKaaFd2wt+CsViwCHMhM1ZcR5jF+iBUWgtHJr5e9zK
	bLzcwvdlDH6l/ICD0H5jNKheqV97FpGEM+P0aPd
X-Received: by 2002:a05:600c:4fcb:b0:495:5890:8f6c with SMTP id 5b1f17b1804b1-4995e084875mr253273375e9.7.1786357841888;
        Mon, 10 Aug 2026 03:30:41 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= <edwin.torok@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: [PATCH v10 3/10] libs/guest: allocate various migration arrays just once
Date: Mon, 10 Aug 2026 11:30:06 +0100
Message-ID: <20260810103018.54564-4-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786357842-034D7A5B-FE0536AF/0/0
X-purgate-type: clean
X-purgate-size: 4898

From: Edwin Török <edwin.torok@citrix.com>

Allocate these array just once at the start of migration,
using the maximum batch size, and free them at the end.

Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
Changes since v2:
- change prefix in subject.

Changes since v3:
- fix comment style

Changes since v4:
- change order of fields in structure.

Changes since v6:
- split preparation commit.

Changes since v8:
- remove useless memset;
- initialize variables while declaring them.

Changes since v9:
- added Reviewed-by.
---
 tools/libs/guest/xg_sr_common.h |  6 +++++
 tools/libs/guest/xg_sr_save.c   | 45 ++++++++++++---------------------
 2 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h
index 7574c9f5b6..c07c6db59e 100644
--- a/tools/libs/guest/xg_sr_common.h
+++ b/tools/libs/guest/xg_sr_common.h
@@ -246,6 +246,12 @@ struct xc_sr_context
             struct xc_sr_context_save_buffers
             {
                 xen_pfn_t batch_pfns[MAX_BATCH_SIZE];
+                xen_pfn_t mfns[MAX_BATCH_SIZE];
+                xen_pfn_t types[MAX_BATCH_SIZE];
+                void *local_pages[MAX_BATCH_SIZE];
+                struct iovec iov[MAX_BATCH_SIZE + 2]; /* Headers + data. */
+                uint64_t rec_pfns[MAX_BATCH_SIZE];
+                int errors[MAX_BATCH_SIZE];
             } *buffers;
         } save;
 
diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c
index 22348db445..6a77e33a47 100644
--- a/tools/libs/guest/xg_sr_save.c
+++ b/tools/libs/guest/xg_sr_save.c
@@ -86,15 +86,12 @@ static int write_checkpoint_record(struct xc_sr_context *ctx)
 static int write_batch(struct xc_sr_context *ctx)
 {
     xc_interface *xch = ctx->xch;
-    xen_pfn_t *mfns = NULL, *types = NULL;
     void *guest_mapping = NULL;
-    void **local_pages = NULL;
-    int *errors = NULL, rc = -1;
+    int rc = -1;
     unsigned int i, p, nr_pages = 0, nr_pages_mapped = 0;
     unsigned int nr_pfns = ctx->save.nr_batch_pfns;
     void *page, *orig_page;
-    uint64_t *rec_pfns = NULL;
-    struct iovec *iov = NULL; int iovcnt = 0;
+    int iovcnt = 0;
     xen_pfn_t *const batch_pfns = ctx->save.buffers->batch_pfns;
     struct {
         struct xc_sr_rhdr rec;
@@ -110,28 +107,21 @@ static int write_batch(struct xc_sr_context *ctx)
         },
     };
 
-    assert(nr_pfns != 0);
-    assert(nr_pfns <= MAX_BATCH_SIZE);
-
     /* Mfns of the batch pfns. */
-    mfns = malloc(nr_pfns * sizeof(*mfns));
+    xen_pfn_t *const mfns = ctx->save.buffers->mfns;
     /* Types of the batch pfns. */
-    types = malloc(nr_pfns * sizeof(*types));
+    xen_pfn_t *const types = ctx->save.buffers->types;
     /* Errors from attempting to map the gfns. */
-    errors = malloc(nr_pfns * sizeof(*errors));
+    int *const errors = ctx->save.buffers->errors;
     /* Pointers to locally allocated pages.  Need freeing. */
-    local_pages = calloc(nr_pfns, sizeof(*local_pages));
+    void **const local_pages = ctx->save.buffers->local_pages;
     /* iovec[] for writev(). */
-    iov = malloc((nr_pfns + 2) * sizeof(*iov));
+    struct iovec *const iov = ctx->save.buffers->iov;
     /* page_data record PFNs list */
-    rec_pfns = malloc(nr_pfns * sizeof(*rec_pfns));
+    uint64_t *const rec_pfns = ctx->save.buffers->rec_pfns;
 
-    if ( !mfns || !types || !errors || !local_pages || !iov || !rec_pfns )
-    {
-        ERROR("Unable to allocate arrays for a batch of %u pages",
-              nr_pfns);
-        goto err;
-    }
+    assert(nr_pfns != 0);
+    assert(nr_pfns <= MAX_BATCH_SIZE);
 
     iov[0].iov_base = &hdrs;
     iov[0].iov_len = sizeof(hdrs);
@@ -249,14 +239,11 @@ static int write_batch(struct xc_sr_context *ctx)
  err:
     if ( guest_mapping )
         xenforeignmemory_unmap(xch->fmem, guest_mapping, nr_pages_mapped);
-    for ( i = 0; local_pages && i < nr_pfns; ++i )
+    for ( i = 0; i < nr_pfns; ++i )
+    {
         free(local_pages[i]);
-    free(rec_pfns);
-    free(iov);
-    free(local_pages);
-    free(errors);
-    free(types);
-    free(mfns);
+        local_pages[i] = NULL;
+    }
 
     return rc;
 }
@@ -790,8 +777,8 @@ static int setup(struct xc_sr_context *ctx)
 
     if ( !ctx->save.buffers || !dirty_bitmap || !ctx->save.deferred_pages )
     {
-        ERROR("Unable to allocate memory for dirty bitmaps, batch pfns and"
-              " deferred pages");
+        ERROR("Unable to allocate memory for dirty bitmaps, deferred pages"
+              " and various batch buffers");
         rc = -1;
         errno = ENOMEM;
         goto err;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387326.1628600 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHH-0004R7-E0; Mon, 10 Aug 2026 10:30:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387326.1628600; Mon, 10 Aug 2026 10:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHH-0004R0-AT; Mon, 10 Aug 2026 10:30:43 +0000
Received: by outflank-mailman (input) for mailman id 1387326;
 Mon, 10 Aug 2026 10:30:42 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHF-0004A8-UM
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHE-00AlTW-T7
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:40 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a84a-e002-0a2a0a5209dd-0a2a450bb4c2-14
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:40 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a850-b7e8-0a2a450b0019-d1558031dcd9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:40 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4954afac04bso18664995e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:40 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357840; x=1786962640; 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=GVzljfbFKFoNV9C92LIEgW8vPbCFaLYksP7zU4eJtPg=;
        b=mAuUos2CXlYTXPWJltByqIPNA33B+CgqhMp2167Xx6dyFfepDXvO40fF5An+0q0o+E
         uz5ssDPs9wHWyjOEuw0W47iT063PE9BajXSY4saCCbn67KO0or2rvSbQJQ0/nmWvEtYu
         29x5+3XxesexNMqS1Hlhrw6ivLT41PTv/ZYWqquuyz3xXN3ZyLfkkQCWmXHeqI+kOTuG
         UoUZB09yML3HC5v0LcswG8hslDVMAhhja4J9qEsXImnRQhvRN3U9c2gCCC/D6MpowiG3
         3cVxCL2ngY/gBz5rlntqxpmxVJnQBOO9uPTrIbSIegc4g80J0B0oJPzZHdt6nsLYRAmy
         r1FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357840; x=1786962640;
        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=GVzljfbFKFoNV9C92LIEgW8vPbCFaLYksP7zU4eJtPg=;
        b=nKglD52EDNS4oY59KtjyIiwDFYVjuHitrDfoS/imn8nWV6O6V1+nMEhU/EDEEj7ALm
         ZK0VAcOW/gq48pCS1ier5vzBWxBsPSctZp37ru4C4iPCS3O2VxCp8H8CtELny4Q9qleq
         cW2fC30yQfS1J9dpS7jw+g7QRlohlW85zU99FqrZdbRHrq5VJawzZHgueXg+h7KsvRN0
         aqK7qGI3teKPN/IfGJDpLlnh5kwRe0EAJGr82jVvsh3WtBGhZku0YMwdRhHY6b3v1heq
         JCkZ3EUutgrlRbfTT6tLWIYDDGJlFf2hM7W1Adhtg3FUzQVkdXqP6dBJUMXcwORgomvY
         pTZQ==
X-Gm-Message-State: AOJu0YyWDgjO99Ob7zCEhPbbyI3Pes52LgD7lnsGJYz6G+4rsiGGgHhQ
	MgM/74PG6m9z5E75hMKZgWdwDreLOwP0/DHa/ePEOlmG6JH4F971mVAVRpCgK6etzQg=
X-Gm-Gg: AR+sD13RNGobMQJo3WwOBOMTB3HvYO7+pHv1fR3QB0TyrK6n6qDh+3UtqbSE4Jah4e5
	qniKf7rnb248cqvTB8k7Bi2BvZseXROq/iDzLqEHfATrAKu4CQpLWJnAHcwLv6VWFR/WoWJThu9
	/7uFcnYmjZ8k7fQKjpC43PJDXIDAvTK+1sjQPPS8JyFEjpSgR32+AD0E9uAetJxGXIxSnQIEcNj
	wvmnO1/aQ3CkTO6z/5r2mCB+RBvPskwF6fO4+hgRPxEV7dobfyVIIOWik9jfbDksyjKxM6RAXhO
	PaXFHoPz8Lhe69ZMN2z33uqoCr1p5db9OLp10A0d0+EXi8w+Ratoql/mdljKo8ubhIxZcZrR1GG
	/7fKfDYCKuAhr6nppLbjqdSQFZsVP4MoE7n2QyC+VFHckCwWKVw0cetiEm1Cv7Djagi714MigSy
	OCnC7hX7hQ/gJseYZ3U1mkp6akij6ahAibWoXFwPyLaX7l12WzXEfOEjVEEZ10bD4GI6zeTZh+k
	ZItuQPBeIcBz5mDVUrNkLD4c/9kfAfV2DHvkdIp
X-Received: by 2002:a05:600c:3555:b0:499:521d:bff1 with SMTP id 5b1f17b1804b1-4996194e53emr251879455e9.2.1786357840167;
        Mon, 10 Aug 2026 03:30:40 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH v10 2/10] libs/guest: move batch_pfns into a separate structure
Date: Mon, 10 Aug 2026 11:30:05 +0100
Message-ID: <20260810103018.54564-3-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786357840-AB0DD9EA-63863286/0/0
X-purgate-type: clean
X-purgate-size: 6125

Preparation for a followup patch "libs/guest: allocate various migration
arrays just once".

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
---
Changes since v6:
- split from "libs/guest: allocate various migration arrays just once".

Changes since v7:
- initialize "batch_pfns" on declaration.

Changes since v8:
- remove useless check;
- added Reviewed-by.
---
 tools/libs/guest/xg_sr_common.h |  5 ++++-
 tools/libs/guest/xg_sr_save.c   | 28 ++++++++++++++--------------
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h
index f1573aefcb..7574c9f5b6 100644
--- a/tools/libs/guest/xg_sr_common.h
+++ b/tools/libs/guest/xg_sr_common.h
@@ -239,11 +239,14 @@ struct xc_sr_context
 
             struct precopy_stats stats;
 
-            xen_pfn_t *batch_pfns;
             unsigned int nr_batch_pfns;
             unsigned long *deferred_pages;
             unsigned long nr_deferred_pages;
             xc_hypercall_buffer_t dirty_bitmap_hbuf;
+            struct xc_sr_context_save_buffers
+            {
+                xen_pfn_t batch_pfns[MAX_BATCH_SIZE];
+            } *buffers;
         } save;
 
         struct /* Restore data. */
diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c
index 84fdbe4140..22348db445 100644
--- a/tools/libs/guest/xg_sr_save.c
+++ b/tools/libs/guest/xg_sr_save.c
@@ -75,7 +75,7 @@ static int write_checkpoint_record(struct xc_sr_context *ctx)
 
 /*
  * Writes a batch of memory as a PAGE_DATA record into the stream.  The batch
- * is constructed in ctx->save.batch_pfns.
+ * is constructed in ctx->save.buffers->batch_pfns.
  *
  * This function:
  * - gets the types for each pfn in the batch.
@@ -95,6 +95,7 @@ static int write_batch(struct xc_sr_context *ctx)
     void *page, *orig_page;
     uint64_t *rec_pfns = NULL;
     struct iovec *iov = NULL; int iovcnt = 0;
+    xen_pfn_t *const batch_pfns = ctx->save.buffers->batch_pfns;
     struct {
         struct xc_sr_rhdr rec;
         struct xc_sr_rec_page_data_header page_data;
@@ -110,6 +111,7 @@ static int write_batch(struct xc_sr_context *ctx)
     };
 
     assert(nr_pfns != 0);
+    assert(nr_pfns <= MAX_BATCH_SIZE);
 
     /* Mfns of the batch pfns. */
     mfns = malloc(nr_pfns * sizeof(*mfns));
@@ -141,13 +143,12 @@ static int write_batch(struct xc_sr_context *ctx)
 
     for ( i = 0; i < nr_pfns; ++i )
     {
-        types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx,
-                                                      ctx->save.batch_pfns[i]);
+        types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx, batch_pfns[i]);
 
         /* Likely a ballooned page. */
         if ( mfns[i] == INVALID_MFN )
         {
-            set_bit(ctx->save.batch_pfns[i], ctx->save.deferred_pages);
+            set_bit(batch_pfns[i], ctx->save.deferred_pages);
             ++ctx->save.nr_deferred_pages;
         }
     }
@@ -193,7 +194,7 @@ static int write_batch(struct xc_sr_context *ctx)
             if ( errors[p] )
             {
                 ERROR("Mapping of pfn %#"PRIpfn" (mfn %#"PRIpfn") failed %d",
-                      ctx->save.batch_pfns[i], mfns[p], errors[p]);
+                      batch_pfns[i], mfns[p], errors[p]);
                 goto err;
             }
 
@@ -207,7 +208,7 @@ static int write_batch(struct xc_sr_context *ctx)
             {
                 if ( rc == -1 && errno == EAGAIN )
                 {
-                    set_bit(ctx->save.batch_pfns[i], ctx->save.deferred_pages);
+                    set_bit(batch_pfns[i], ctx->save.deferred_pages);
                     ++ctx->save.nr_deferred_pages;
                     types[i] = XEN_DOMCTL_PFINFO_XTAB;
                     --nr_pages;
@@ -235,7 +236,7 @@ static int write_batch(struct xc_sr_context *ctx)
     hdrs.rec.length += nr_pages * PAGE_SIZE;
 
     for ( i = 0; i < nr_pfns; ++i )
-        rec_pfns[i] = ((uint64_t)(types[i]) << 32) | ctx->save.batch_pfns[i];
+        rec_pfns[i] = ((uint64_t)(types[i]) << 32) | batch_pfns[i];
 
     if ( writev_exact(ctx->fd, iov, iovcnt) )
     {
@@ -274,9 +275,9 @@ static int flush_batch(struct xc_sr_context *ctx)
 
     if ( !rc )
     {
-        VALGRIND_MAKE_MEM_UNDEFINED(ctx->save.batch_pfns,
+        VALGRIND_MAKE_MEM_UNDEFINED(ctx->save.buffers->batch_pfns,
                                     MAX_BATCH_SIZE *
-                                    sizeof(*ctx->save.batch_pfns));
+                                    sizeof(*ctx->save.buffers->batch_pfns));
     }
 
     return rc;
@@ -293,7 +294,7 @@ static int add_to_batch(struct xc_sr_context *ctx, xen_pfn_t pfn)
         rc = flush_batch(ctx);
 
     if ( rc == 0 )
-        ctx->save.batch_pfns[ctx->save.nr_batch_pfns++] = pfn;
+        ctx->save.buffers->batch_pfns[ctx->save.nr_batch_pfns++] = pfn;
 
     return rc;
 }
@@ -784,11 +785,10 @@ static int setup(struct xc_sr_context *ctx)
 
     dirty_bitmap = xc_hypercall_buffer_alloc_pages(
         xch, dirty_bitmap, NRPAGES(bitmap_size(ctx->save.p2m_size)));
-    ctx->save.batch_pfns = malloc(MAX_BATCH_SIZE *
-                                  sizeof(*ctx->save.batch_pfns));
     ctx->save.deferred_pages = bitmap_alloc(ctx->save.p2m_size);
+    ctx->save.buffers = calloc(1, sizeof(*ctx->save.buffers));
 
-    if ( !ctx->save.batch_pfns || !dirty_bitmap || !ctx->save.deferred_pages )
+    if ( !ctx->save.buffers || !dirty_bitmap || !ctx->save.deferred_pages )
     {
         ERROR("Unable to allocate memory for dirty bitmaps, batch pfns and"
               " deferred pages");
@@ -819,7 +819,7 @@ static void cleanup(struct xc_sr_context *ctx)
     xc_hypercall_buffer_free_pages(xch, dirty_bitmap,
                                    NRPAGES(bitmap_size(ctx->save.p2m_size)));
     free(ctx->save.deferred_pages);
-    free(ctx->save.batch_pfns);
+    free(ctx->save.buffers);
 }
 
 /*
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387328.1628618 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHK-0004tl-4h; Mon, 10 Aug 2026 10:30:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387328.1628618; Mon, 10 Aug 2026 10:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHJ-0004tc-W6; Mon, 10 Aug 2026 10:30:45 +0000
Received: by outflank-mailman (input) for mailman id 1387328;
 Mon, 10 Aug 2026 10:30:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHJ-0004ir-4M
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHI-00Dyin-HR
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:44 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a842-bab6-0a2a0a5309dd-0a2a4504c9d8-22
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:44 +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 <freddy77@gmail.com>)
 id 6a79a854-b57f-0a2a45040019-d155802dd551-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:44 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so10862685e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:44 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357843; x=1786962643; 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=mmYKOwc9TBhHBw9HKQnv11v7wtvX4hGi6xT3sze3LxM=;
        b=c9eyfgznDHwu2KFRkAc50rBNR8rftgT1J23Rmqp97Z0WRxm+RhDwY4K+l+l8xrh0KU
         3wAJTBHeSYDR7lbdOzXKEp6kc+MwZ9Cb8pzvqL2wGJHafopwqyHAPJO4xg+pXlIJsubl
         oLYNOt8Z7IqNqU5ieODubmMRUCgAI5uNHGHRIvtseOfAKVlV3K0lQcXiApzVQ2mbTRz5
         fPAoQKxB+bLAQmTX05YupoK1dBAi8VEAcnTI1MmixNtHEdq+7x6dLdNCrkotcQP8zt0x
         d0/Zgqs4nOSnjYTA3dLDd3h5taJN31VvraEpvYvqycakpQKwmO+D+vOmgJb/7OitpQez
         /G4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357843; x=1786962643;
        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=mmYKOwc9TBhHBw9HKQnv11v7wtvX4hGi6xT3sze3LxM=;
        b=eQbLOBpe3qmqiK840BMANpP87LpQOxDhANMOP79RDNOW888qcBWGPD0WtmqYgeyhqU
         VtkkpqRmY8f/PrHgHyXUG0ixgi61TJC1JtjKH4uDCby8/POaNjrytJPnT31s0vh0OQmv
         x4aovnk620OtPQi35dVIIbHIFq7AMluEs2RcRWHJKycjKKy7AzTLP490QZPxgbW2Z0YE
         Gnt2xATrLl3hM5ieB1qBKCMGlZ2r31xW7OdGQACmF4fxdm106a4Sd3M4xIinmlM05Es8
         MbuheIvHOSPIEqdLeSUE1gfMM/qwrKJ38h8wcsoSfhKE4VdIZeyI4LD5sEFIfpId6cML
         Fi2Q==
X-Gm-Message-State: AOJu0YwazFJExIbwzBquVb/tz0lWRsommcT/GEouq4yGbYbH7FkBkCjt
	Fap1xZPvHdRf+jBQIBmmd5rW8CRh/SsgfqfPA/rNGLofCSaRqDHNjB53IOZfkt/94c0=
X-Gm-Gg: AR+sD12WBUM0fMkuAJQxxc27YUthk2n0YcsD+ozU5BEMLrwThQOm8bjUV9ctpvKOmQx
	xUKp76U7IKcH+Ly5OOtyLaTg3NOAk5qDR7Vj6LPBUHt4PKTxe9liJzXSAC9W0G4rOvh67NoV0u7
	nMxQP6dohXPMrn1MQYs5qhJ0BRtDDOZxG2Au45OL4Xbk20WrvHD2i2ZJ2U5o013F4Bj/WQDvVNS
	rse0152W5JHykR2OuhlYNZ7qC+QtJyV/TETbkN4ETMLu/W4wlKIP2RFNDaU9TAroDRGKd4pI7Ua
	F7uQ+4meHclH+H4vzCLdodelCwPi0U6W7ToUetJGz2DmphxH0RzLUYxG7Qs/1/fjXvUlgCftJgT
	ks007RO3ufT3uyWv8OvIJnwo5/1v3420Ku8k+x7J48+6FR8LTZUo+++SKFTfa0LRixSypYV3Aq+
	gT1fGT+VXt1HTfu4EqzilXArKql1+FYnu0JY0/SN8RkQ7SZqE8+6TyYbPJgHIAjp/JTJa4z03si
	VmnmKUr37H4T54m1G9NTcGkwOfnPRroruRaxs6v
X-Received: by 2002:a05:600c:6298:b0:495:503f:cf9a with SMTP id 5b1f17b1804b1-499619839d6mr196524995e9.9.1786357843492;
        Mon, 10 Aug 2026 03:30:43 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH v10 4/10] libs/guest: use Valgrind or sanitizers to detect various buffer overflows
Date: Mon, 10 Aug 2026 11:30:07 +0100
Message-ID: <20260810103018.54564-5-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1786357844-C0EDEB50-0D7D9B2F/0/0
X-purgate-type: clean
X-purgate-size: 7329

Previously this was done as buffers were allocated separately.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
Changes since v9:
- add support for sanitizers also;
- remove some unneeded check buffers.
---
 tools/config.h.in               |  6 ++++
 tools/configure                 | 12 +++++++
 tools/configure.ac              |  3 +-
 tools/libs/ctrl/xc_private.h    | 61 +++++++++++++++++++++++++++++++--
 tools/libs/guest/xg_sr_common.h |  6 ++++
 tools/libs/guest/xg_sr_save.c   | 11 ++++++
 6 files changed, 96 insertions(+), 3 deletions(-)

diff --git a/tools/config.h.in b/tools/config.h.in
index ed0042018d..d51816453b 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -48,6 +48,12 @@
 /* ROMBIOS enabled */
 #undef HAVE_ROMBIOS
 
+/* Define to 1 if you have the <sanitizer/asan_interface.h> header file. */
+#undef HAVE_SANITIZER_ASAN_INTERFACE_H
+
+/* Define to 1 if you have the <sanitizer/msan_interface.h> header file. */
+#undef HAVE_SANITIZER_MSAN_INTERFACE_H
+
 /* Define to 1 if you have the <stdint.h> header file. */
 #undef HAVE_STDINT_H
 
diff --git a/tools/configure b/tools/configure
index cd989925ed..94e630665f 100755
--- a/tools/configure
+++ b/tools/configure
@@ -10203,6 +10203,18 @@ then :
   printf "%s\n" "#define HAVE_UTMP_H 1" >>confdefs.h
 
 fi
+ac_fn_c_check_header_compile "$LINENO" "sanitizer/asan_interface.h" "ac_cv_header_sanitizer_asan_interface_h" "$ac_includes_default"
+if test "x$ac_cv_header_sanitizer_asan_interface_h" = xyes
+then :
+  printf "%s\n" "#define HAVE_SANITIZER_ASAN_INTERFACE_H 1" >>confdefs.h
+
+fi
+ac_fn_c_check_header_compile "$LINENO" "sanitizer/msan_interface.h" "ac_cv_header_sanitizer_msan_interface_h" "$ac_includes_default"
+if test "x$ac_cv_header_sanitizer_msan_interface_h" = xyes
+then :
+  printf "%s\n" "#define HAVE_SANITIZER_MSAN_INTERFACE_H 1" >>confdefs.h
+
+fi
 
 
 # Check for libnl3 >=3.2.8. If present enable remus network buffering.
diff --git a/tools/configure.ac b/tools/configure.ac
index 74b9f56025..5346ff6129 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -454,7 +454,8 @@ AC_CHECK_DECLS([fdt_property_u32],,,[#include <libfdt.h>])
 esac
 
 # Checks for header files.
-AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h valgrind/memcheck.h utmp.h])
+AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h valgrind/memcheck.h \
+                  utmp.h sanitizer/asan_interface.h sanitizer/msan_interface.h])
 
 # Check for libnl3 >=3.2.8. If present enable remus network buffering.
 PKG_CHECK_MODULES(LIBNL3, [libnl-3.0 >= 3.2.8 libnl-route-3.0 >= 3.2.8],
diff --git a/tools/libs/ctrl/xc_private.h b/tools/libs/ctrl/xc_private.h
index 8a325c17b0..7803192599 100644
--- a/tools/libs/ctrl/xc_private.h
+++ b/tools/libs/ctrl/xc_private.h
@@ -42,13 +42,70 @@
 
 #include <xen-tools/common-macros.h>
 
-#if defined(HAVE_VALGRIND_MEMCHECK_H) && !defined(NDEBUG) && !defined(__MINIOS__)
+#undef XEN_USE_MEM_NOACCESS
+#if !defined(NDEBUG) && !defined(__MINIOS__)
+
+#if !defined(__has_feature)
+#define __has_feature(x) 0
+#endif
+
+#if defined(HAVE_SANITIZER_ASAN_INTERFACE_H) && \
+    (__has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__))
+#include <sanitizer/asan_interface.h>
+#define XEN_USE_MEM_NOACCESS 1
+#elif defined(HAVE_SANITIZER_MSAN_INTERFACE_H) && \
+    __has_feature(memory_sanitizer)
+#include <sanitizer/msan_interface.h>
+#define XEN_USE_MEM_NOACCESS 1
+#endif
+#if defined(HAVE_VALGRIND_MEMCHECK_H)
 /* Compile in Valgrind client requests? */
 #include <valgrind/memcheck.h>
-#else
+#define XEN_USE_MEM_NOACCESS 1
+#endif
+
+#endif
+
+#if !defined(HAVE_VALGRIND_MEMCHECK_H) || defined(NDEBUG) || defined(__MINIOS__)
 #define VALGRIND_MAKE_MEM_UNDEFINED(addr, len) /* addr, len */
 #endif
 
+#if defined(XEN_USE_MEM_NOACCESS)
+#define MEM_NOACCESS_BUFFER(name, size) uint8_t name[size];
+#if defined(HAVE_VALGRIND_MEMCHECK_H)
+#define MEM_NOACCESS_INIT_VALGRIND(field) \
+    VALGRIND_MAKE_MEM_NOACCESS(field, sizeof(field))
+#else
+#define MEM_NOACCESS_INIT_VALGRIND(field)
+#endif
+#if defined(HAVE_SANITIZER_ASAN_INTERFACE_H) && \
+    (__has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__))
+#define MEM_NOACCESS_INIT_SANITIZER(field) \
+    ASAN_POISON_MEMORY_REGION(field, sizeof(field))
+#else
+#define MEM_NOACCESS_INIT_SANITIZER(field)
+#endif
+#if defined(HAVE_SANITIZER_MSAN_INTERFACE_H) && \
+    __has_feature(memory_sanitizer)
+#define MEM_UNDEFINED_INIT_SANITIZER(field) \
+    __msan_poison(field, sizeof(field))
+#else
+#define MEM_UNDEFINED_INIT_SANITIZER(field)
+#endif
+#define MEM_NOACCESS_INIT(field) do { \
+    MEM_NOACCESS_INIT_VALGRIND(field); \
+    MEM_NOACCESS_INIT_SANITIZER(field); \
+} while(0)
+#define MEM_UNDEFINED_INIT(field) do { \
+    VALGRIND_MAKE_MEM_UNDEFINED(field, sizeof(field)); \
+    MEM_UNDEFINED_INIT_SANITIZER(field); \
+} while(0)
+#else
+#define MEM_NOACCESS_BUFFER(name, size)
+#define MEM_NOACCESS_INIT(field) do {} while(0)
+#define MEM_UNDEFINED_INIT(field) do {} while(0)
+#endif
+
 #if defined(__MINIOS__)
 /*
  * MiniOS's libc doesn't know about sys/uio.h or writev().
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h
index c07c6db59e..020b1a5272 100644
--- a/tools/libs/guest/xg_sr_common.h
+++ b/tools/libs/guest/xg_sr_common.h
@@ -246,11 +246,17 @@ struct xc_sr_context
             struct xc_sr_context_save_buffers
             {
                 xen_pfn_t batch_pfns[MAX_BATCH_SIZE];
+                MEM_NOACCESS_BUFFER(na0, 64);
                 xen_pfn_t mfns[MAX_BATCH_SIZE];
+                MEM_NOACCESS_BUFFER(na1, 64);
                 xen_pfn_t types[MAX_BATCH_SIZE];
+                MEM_NOACCESS_BUFFER(na2, 64);
                 void *local_pages[MAX_BATCH_SIZE];
+                MEM_NOACCESS_BUFFER(na3, 64);
                 struct iovec iov[MAX_BATCH_SIZE + 2]; /* Headers + data. */
+                MEM_NOACCESS_BUFFER(na4, 64);
                 uint64_t rec_pfns[MAX_BATCH_SIZE];
+                MEM_NOACCESS_BUFFER(na5, 64);
                 int errors[MAX_BATCH_SIZE];
             } *buffers;
         } save;
diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c
index 6a77e33a47..96d7e9e2f8 100644
--- a/tools/libs/guest/xg_sr_save.c
+++ b/tools/libs/guest/xg_sr_save.c
@@ -123,6 +123,11 @@ static int write_batch(struct xc_sr_context *ctx)
     assert(nr_pfns != 0);
     assert(nr_pfns <= MAX_BATCH_SIZE);
 
+    MEM_UNDEFINED_INIT(ctx->save.buffers->mfns);
+    MEM_UNDEFINED_INIT(ctx->save.buffers->types);
+    MEM_UNDEFINED_INIT(ctx->save.buffers->iov);
+    MEM_UNDEFINED_INIT(ctx->save.buffers->rec_pfns);
+
     iov[0].iov_base = &hdrs;
     iov[0].iov_len = sizeof(hdrs);
 
@@ -783,6 +788,12 @@ static int setup(struct xc_sr_context *ctx)
         errno = ENOMEM;
         goto err;
     }
+    MEM_NOACCESS_INIT(ctx->save.buffers->na0);
+    MEM_NOACCESS_INIT(ctx->save.buffers->na1);
+    MEM_NOACCESS_INIT(ctx->save.buffers->na2);
+    MEM_NOACCESS_INIT(ctx->save.buffers->na3);
+    MEM_NOACCESS_INIT(ctx->save.buffers->na4);
+    MEM_NOACCESS_INIT(ctx->save.buffers->na5);
 
     rc = 0;
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387329.1628627 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHL-00058Z-CE; Mon, 10 Aug 2026 10:30:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387329.1628627; Mon, 10 Aug 2026 10:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHL-00058O-8P; Mon, 10 Aug 2026 10:30:47 +0000
Received: by outflank-mailman (input) for mailman id 1387329;
 Mon, 10 Aug 2026 10:30:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHJ-0004t8-UU
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHJ-000B9X-Ay
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:45 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a854-2eae-0a2a0a5409dd-0a2a4509bf7e-10
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:45 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a855-be1a-0a2a45090019-d155802ec06a-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:45 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4996f1ee4a4so6106325e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:45 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357845; x=1786962645; 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=DkECl6LDMDGOPn0+PvCj6l9ySrP1BztPa+S0NKPl8lo=;
        b=XK4ZZmLdPIeRTaxO29DQeKvE5Yq9F2kKDoE/51xEgGvfJCOhc3VQTU2SsUf693ssh3
         LWKzwQ5/ARqHDrv/6JIt2VFglMMitk6P6GACT3nmFz/NHxrI0UWpWTmJm9uxF9d7TfqQ
         H+7EvhagApP6OKFXWJNOP0dxpmXNU8Y6XP09b/6QkKzfI5eks1x+2MQxJCJLpJCIFygF
         saU1GAgFTaq9QBfcL202wcg6/4Vf85nXDw/zcr7OnmMFHnz/lyazsqyUs5mQlAJTq400
         BQP1lz8bjADlFNOsIJ9rfBAhLa8csd3VFRpNrzbyEi09/7+dSBMfH4q5wXFoRImD9rni
         jXwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357845; x=1786962645;
        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=DkECl6LDMDGOPn0+PvCj6l9ySrP1BztPa+S0NKPl8lo=;
        b=smh4Dds/2tE2EFxDV9SxuowfUvow7zxwImZh+/EEkEpEhKggFxYPysMUsvcBWWHMy1
         APpvwp8LiGE10ECBlM+9l9S4LctnaoUCuVN4EYyYP4zHnTbRbOEV0T44MWPnd1bSMrNp
         B11GDHqss8FeIY4Gtgh/CVyQy7cVob8yez0c+a4MYMhreCi1ly5eiYdNXxwkZgND691k
         pIaHahjd/VbKXUgGw6DJKaoF87p1W816zotfn2oTSjKr+y8IqpLLg+h909P76lFiF8rA
         UOiFXPHcqWwfQt/Tyn26CAr7S2IzdH39cw6TZe6BW1ErIfOR3r73swobpHOAxRoytvVn
         srwA==
X-Gm-Message-State: AOJu0YyIRu+n3IiHtAB6wzM5Q4OsziYbEoM14VLijSYUw5PZMO3tGsLJ
	v3zEJLFalBn05ZluDnb2LK6lDXM9GxzcWIVJoWz8S/sQ2ezrj4K+w4FiDcSC0RpWqXk=
X-Gm-Gg: AR+sD10bp/jD1AEj8oWHDVxrLEyn8C8E7QjgnZcAP/Qlxg/UwaInUKk+ekX4r9emFuK
	s9awuR06gsyyAeTg2Frm/Nkkr9GU32ZaLlimqDyGmtDMnsfkGRhdmvdY8oWkutBz0tMvG9GtAsH
	W0GLsc8kNf4tuXGYfriZjU0/ivXLrIia48zfz7gMvlu6lcns9Ha1pWB3QJPRDZbZWd887ZWk1IB
	0UI1tpVBuvqR6MUeCuCn7GlN63N9q/7AO995krbgT1ufC8yRo4dB9w8uVk1Phd5QQcEMkDSNmN4
	KiR3fcXXRF4R9o0kjTjLy5Qgqv1dp02q0Sb2BhXUi6IRE7n3yvVL+CpPdcCymVl4UWpekCskFEA
	RFq58/cP4ZDfn5GZgwhrIxNTZkzLfKz1zHsBtyCqtUgIJGXTZBPVHAl5UC1t2UsQRUpDDTBZYrY
	Nuvuj7u+W69lFUfl76NGsxV+ZRVEHM8qzGcoLZsZG4zCoOQ1uU5bbiiyiAKFD8ahscBTph07FMe
	1UaYkytL4EG3EMv+koplDndrTaMPMpfxfYXqmRm
X-Received: by 2002:a05:600c:3b93:b0:495:6a50:3fb8 with SMTP id 5b1f17b1804b1-499727417c7mr9643525e9.1.1786357844497;
        Mon, 10 Aug 2026 03:30:44 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH v10 5/10] libs/guest: add xg_foreignmemory_copy_{from,to}
Date: Mon, 10 Aug 2026 11:30:08 +0100
Message-ID: <20260810103018.54564-6-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1786357845-3A8D9034-D08973B3/0/0
X-purgate-type: clean
X-purgate-size: 4001

This change prepare code to use a new "foreign copy" hypercall.
The new hypercall will copy memory from/to a foreign domain.
The new hypercall can be emulated with a sequence of:
- map foreign memory;
- copy memory;
- unmap foreign memory.

The reason to introduce the emulation first is that you can refactor on the
emulation without having to introduce the new hypercall.  Introducing the
hypercall first would make testing more complicated as bugs on the hypercall
have to be taken into account and considered.  Also it is easier that way to
enable or disable new code. For instance you want to test for performance
regression (in this case the code emulated should not perform worse).

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
Changes since v5:
- Do not overwrite errno if xenforeignmemory_map fails.

Changes since v6:
- improve commit message, explain order and changes.
---
 tools/libs/guest/xg_sr_common.c | 57 +++++++++++++++++++++++++++++++++
 tools/libs/guest/xg_sr_common.h |  8 +++++
 2 files changed, 65 insertions(+)

diff --git a/tools/libs/guest/xg_sr_common.c b/tools/libs/guest/xg_sr_common.c
index 9b2782b5cf..90da21c35f 100644
--- a/tools/libs/guest/xg_sr_common.c
+++ b/tools/libs/guest/xg_sr_common.c
@@ -156,6 +156,63 @@ static void __attribute__((unused)) build_assertions(void)
     BUILD_BUG_ON(sizeof(struct xc_sr_rec_hvm_params)        != 8);
 }
 
+enum {
+    foreigncopy_from,
+    foreigncopy_to
+};
+
+static int xg_foreignmemory_copy(xc_interface *xch, domid_t domid,
+                                 int dir, size_t nr_pages, void *buffer,
+                                 const xen_pfn_t foreign_pfns[nr_pages])
+{
+    if ( nr_pages == 0 )
+        return 0;
+
+    if ( !buffer || !foreign_pfns )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    int err[nr_pages];
+    const int prot = (dir == foreigncopy_from) ? PROT_READ : PROT_READ|PROT_WRITE;
+
+    void *p = xenforeignmemory_map(xch->fmem, domid, prot, nr_pages, foreign_pfns, err);
+    if ( !p )
+        return -1;
+
+    for ( size_t n = 0; n < nr_pages; ++n )
+        if ( err[n] )
+        {
+            xenforeignmemory_unmap(xch->fmem, p, nr_pages);
+            errno = -err[n];
+            return -1;
+        }
+
+    if ( dir == foreigncopy_from )
+        memcpy(buffer, p, nr_pages * XC_PAGE_SIZE);
+    else
+        memcpy(p, buffer, nr_pages * XC_PAGE_SIZE);
+
+    return xenforeignmemory_unmap(xch->fmem, p, nr_pages);
+}
+
+int xg_foreignmemory_copy_from(xc_interface *xch, domid_t dom,
+                               size_t nr_pages, void *dest,
+                               const xen_pfn_t source[nr_pages])
+{
+    return xg_foreignmemory_copy(xch, dom, foreigncopy_from,
+                                 nr_pages, dest, source);
+}
+
+int xg_foreignmemory_copy_to(xc_interface *xch, domid_t dom,
+                             size_t nr_pages, const xen_pfn_t dest[nr_pages],
+                             const void *source)
+{
+    return xg_foreignmemory_copy(xch, dom, foreigncopy_to,
+                                 nr_pages, (void *) source, dest);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h
index 020b1a5272..50f235ba87 100644
--- a/tools/libs/guest/xg_sr_common.h
+++ b/tools/libs/guest/xg_sr_common.h
@@ -556,6 +556,14 @@ static inline bool page_type_has_stream_data(uint32_t type)
     }
 }
 
+int xg_foreignmemory_copy_from(xc_interface *xch, domid_t dom,
+                               size_t nr_pages, void *dest,
+                               const xen_pfn_t source[nr_pages]);
+
+int xg_foreignmemory_copy_to(xc_interface *xch, domid_t dom,
+                             size_t nr_pages, const xen_pfn_t dest[nr_pages],
+                             const void *source);
+
 #endif
 /*
  * Local variables:
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387330.1628636 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHM-0005Nb-Jb; Mon, 10 Aug 2026 10:30:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387330.1628636; Mon, 10 Aug 2026 10:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHM-0005NI-FW; Mon, 10 Aug 2026 10:30:48 +0000
Received: by outflank-mailman (input) for mailman id 1387330;
 Mon, 10 Aug 2026 10:30:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHL-00056B-5W
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHK-00Dyin-IZ
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:46 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a854-bab6-0a2a0a5309dd-0a2a450799ec-8
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:46 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a856-b4ea-0a2a45070019-d1558033dd86-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:46 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so16277125e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:46 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type: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=1786357846; x=1786962646; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=noFi4Nk2/RkhWge/ysH4KvzMVBLDNZGcIPZ/3WMBXro=;
        b=Imf5WD3OT3FoiLQZlFAhUwHzfItTrfwcC805OQe8ZgUajU6edQ48oxW1Fp/lfVgGfK
         qweM9sP1zGrsbgXTalSCme7QTKxTV0IcW0HIHzupvYTAZAQOPq8ikTOPLYM+J6AusguP
         U+1dN7vFfDumlHhVs8RwAaZc++wxf2V0Y0YQ11RtZjFvId3XePbwPn2sMebNOYXZlkD7
         NBepaUPBSB721VMjuGJL+V1u7ZuHTg0QVXqjfLJt6EmCpqt8FkX4N3XPOa4JyOagawoq
         psE6/XJzxu+dXGJzy8CN2VX79RLp+QIKi0fNncf6WBcxTZiD7T5uqt2mMNk5UTwBFWFD
         UbGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357846; x=1786962646;
        h=content-transfer-encoding:content-type: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=noFi4Nk2/RkhWge/ysH4KvzMVBLDNZGcIPZ/3WMBXro=;
        b=bfL7TnJxG2kVKz+iUOkJkJG5IXuXG6lwoL+YhCgQLefxQASALSLUxEZQy3oIxRelRq
         u7dop67zjyem7dsc/FqvYdwUOP/hP4JjxsFU1WbPJeOBjIAg/xXyREcURSx+FP6SuCg+
         8rg4FJAC66JPrjRVGsIEshY8YeTwaPA/VLY2Z2nROqz6CTCx/9CMwYGLH/AaJ84ASV0K
         44w1T1oDCZLqKLELYwJ7UY6qOWuz59bNDz1V64u8IILKFtNWSCfXisetZGNYHoHrAziH
         AdcY7avMvoD8BnUT18bxvIZOXGBuTKENLXAMOWnYWR5W4uKXzZiVTLXUdSpfqQwvClGA
         tKxw==
X-Gm-Message-State: AOJu0Yx19SGQ/cWTb7+JmUyMs49hgk34uzecIY8k3CPdzwJlcTrJOFiQ
	3u8QJDHnB/V01y8Gp9JAWQC121qlynJ7y1CpHB5RkSzI/1lEVc9VZq8w8Z/h1hBvrlI=
X-Gm-Gg: AR+sD12WeVVYwl5ZtZG/KZif3EoxcPUp/Owu9vs1dmpdEEmg9ef57g7wH0sKIRaIxCG
	Ua4mFNUQ1zY+iZ/AAipP+op/DlIZAzmh+itZlF7xfi1ZtrM9jV5HfLGacmt5DioTNap3K3aTSsZ
	VgjvRPzlKMgrqo+PZGt+X7BSlLf0O2jk+AM5TLQTAz2zq2PuGya8L4SqqpmYk7suBPQc51fHM5X
	aUbJFBLXBmNrNr/KGTvur21ymH7nRElsQIANCdZn/RMJwEjqcUaHntLKPot39bTkY2KdRL4Kf9+
	e345jt/LYg9xAVfYZ508IyYn9qOh2aoeiySI9g0YFVhjuV3H0kGWQyOlYfb+BpRkZzo5DQbIEI+
	KKZ4o7btN7r19HCsA01qZ12PdzpKVSBK3na8AAKOdh5vfqaYWwLbBNdchUgFSGgs/6VXVlI7g0A
	C+3WfTe45Zf2M5O06AzoSyyRCt6ctlc5HkSWy+8FoLDINdtEL7KudvswVy/ODa/IYTYDSmvUKIY
	AH9ilWkwM4auEZqcvqGvVoNdODgUcQQPySX4HoV
X-Received: by 2002:a05:600c:1391:b0:499:4dca:aa4 with SMTP id 5b1f17b1804b1-4996194deb6mr204011195e9.4.1786357845569;
        Mon, 10 Aug 2026 03:30:45 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= <edwin.torok@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: [PATCH v10 6/10] libs/guest: use foreign copy API during migration
Date: Mon, 10 Aug 2026 11:30:09 +0100
Message-ID: <20260810103018.54564-7-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786357846-378D1AE4-808F9804/0/0
X-purgate-type: clean
X-purgate-size: 13400

From: Edwin Török <edwin.torok@citrix.com>

Use foreign code emulation code provided by previous commit to prepare
to use new hypercall.
This to make sure there are no regression in both functionality and
performance.

In particular tested:
- HVM VM;
- PV VM;
- verification code.

Migration times did not change.

Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
Changes since v6:
- merge with "finalize PoC" to remove the PoC;
- remove statistics, old and not clear at all how they were made;
- describe tests made.
---
 tools/libs/guest/xg_sr_common.h  |  4 +-
 tools/libs/guest/xg_sr_restore.c | 78 +++++++++++++++++---------------
 tools/libs/guest/xg_sr_save.c    | 62 +++++++++++--------------
 3 files changed, 71 insertions(+), 73 deletions(-)

diff --git a/tools/libs/guest/xg_sr_common.h b/tools/libs/guest/xg_sr_common.h
index 50f235ba87..ec3435790a 100644
--- a/tools/libs/guest/xg_sr_common.h
+++ b/tools/libs/guest/xg_sr_common.h
@@ -243,6 +243,7 @@ struct xc_sr_context
             unsigned long *deferred_pages;
             unsigned long nr_deferred_pages;
             xc_hypercall_buffer_t dirty_bitmap_hbuf;
+            xc_hypercall_buffer_t dest_buf;
             struct xc_sr_context_save_buffers
             {
                 xen_pfn_t batch_pfns[MAX_BATCH_SIZE];
@@ -256,8 +257,6 @@ struct xc_sr_context
                 struct iovec iov[MAX_BATCH_SIZE + 2]; /* Headers + data. */
                 MEM_NOACCESS_BUFFER(na4, 64);
                 uint64_t rec_pfns[MAX_BATCH_SIZE];
-                MEM_NOACCESS_BUFFER(na5, 64);
-                int errors[MAX_BATCH_SIZE];
             } *buffers;
         } save;
 
@@ -269,6 +268,7 @@ struct xc_sr_context
             int send_back_fd;
             unsigned long p2m_size;
             xc_hypercall_buffer_t dirty_bitmap_hbuf;
+            xc_hypercall_buffer_t verify_buf;
 
             /* From Image Header. */
             uint32_t format_version;
diff --git a/tools/libs/guest/xg_sr_restore.c b/tools/libs/guest/xg_sr_restore.c
index 458eaa5992..af97f3d466 100644
--- a/tools/libs/guest/xg_sr_restore.c
+++ b/tools/libs/guest/xg_sr_restore.c
@@ -257,16 +257,15 @@ static int process_page_data(struct xc_sr_context *ctx, unsigned int count,
 {
     xc_interface *xch = ctx->xch;
     xen_pfn_t *mfns = malloc(count * sizeof(*mfns));
-    int *map_errs = malloc(count * sizeof(*map_errs));
     int rc;
-    void *mapping = NULL, *guest_page = NULL;
     unsigned int nr_pages = 0;
+    void *const source = page_data;
 
-    if ( !mfns || !map_errs )
+    if ( !mfns )
     {
         rc = -1;
         ERROR("Failed to allocate %zu bytes to process page data",
-              count * (sizeof(*mfns) + sizeof(*map_errs)));
+              count * sizeof(*mfns));
         goto err;
     }
 
@@ -294,27 +293,8 @@ static int process_page_data(struct xc_sr_context *ctx, unsigned int count,
     if ( nr_pages == 0 )
         goto done;
 
-    mapping = guest_page = xenforeignmemory_map(
-        xch->fmem, ctx->domid, PROT_READ | PROT_WRITE,
-        nr_pages, mfns, map_errs);
-    if ( !mapping )
-    {
-        rc = -1;
-        PERROR("Unable to map %u mfns for %u pages of data",
-               nr_pages, count);
-        goto err;
-    }
-
     for ( unsigned int i = 0; i < nr_pages; ++i )
     {
-        if ( map_errs[i] )
-        {
-            rc = -1;
-            ERROR("Mapping pfn %#"PRIpfn" (mfn %#"PRIpfn", type %#"PRIx32") failed with %d",
-                  pfns[i], mfns[i], types[i], map_errs[i]);
-            goto err;
-        }
-
         /* Undo page normalisation done by the saver. */
         rc = ctx->restore.ops.localise_page(ctx, types[i], page_data);
         if ( rc )
@@ -324,31 +304,41 @@ static int process_page_data(struct xc_sr_context *ctx, unsigned int count,
             goto err;
         }
 
-        if ( ctx->restore.verify )
+        page_data += PAGE_SIZE;
+    }
+    if ( !ctx->restore.verify )
+    {
+        rc = xg_foreignmemory_copy_to(xch, ctx->domid, nr_pages, mfns, source);
+        if ( rc < 0 )
+            goto err;
+    }
+    else
+    {
+        DECLARE_HYPERCALL_BUFFER_SHADOW(uint8_t, verify_buf,
+                                        &ctx->restore.verify_buf);
+        void *guest_page = verify_buf;
+
+        rc = xg_foreignmemory_copy_from(xch, ctx->domid, nr_pages, verify_buf, mfns);
+        if ( rc < 0 )
+            goto err;
+
+        page_data = source;
+        for ( unsigned int i = 0; i < nr_pages; ++i )
         {
             /* Verify mode - compare incoming data to what we already have. */
             if ( memcmp(guest_page, page_data, PAGE_SIZE) )
                 ERROR("verify pfn %#"PRIpfn" failed (type %#"PRIx32")",
                       pfns[i], types[i] >> XEN_DOMCTL_PFINFO_LTAB_SHIFT);
-        }
-        else
-        {
-            /* Regular mode - copy incoming data into place. */
-            memcpy(guest_page, page_data, PAGE_SIZE);
-        }
 
-        guest_page += PAGE_SIZE;
-        page_data += PAGE_SIZE;
+            guest_page += PAGE_SIZE;
+            page_data += PAGE_SIZE;
+        }
     }
 
  done:
     rc = 0;
 
  err:
-    if ( mapping )
-        xenforeignmemory_unmap(xch->fmem, mapping, nr_pages);
-
-    free(map_errs);
     free(mfns);
 
     return rc;
@@ -738,6 +728,18 @@ static int setup(struct xc_sr_context *ctx)
     int rc;
     DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
                                     &ctx->restore.dirty_bitmap_hbuf);
+    DECLARE_HYPERCALL_BUFFER_SHADOW(uint8_t, verify_buf,
+                                    &ctx->restore.verify_buf);
+
+    verify_buf = xc_hypercall_buffer_alloc_pages(
+        xch, verify_buf, MAX_BATCH_SIZE);
+
+    if ( !verify_buf )
+    {
+        ERROR("Unable to allocate memory for test buffer");
+        rc = -1;
+        goto err;
+    }
 
     if ( ctx->stream_type == XC_STREAM_COLO )
     {
@@ -786,6 +788,8 @@ static void cleanup(struct xc_sr_context *ctx)
     unsigned int i;
     DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
                                     &ctx->restore.dirty_bitmap_hbuf);
+    DECLARE_HYPERCALL_BUFFER_SHADOW(uint8_t, verify_buf,
+                                    &ctx->restore.verify_buf);
 
     for ( i = 0; i < ctx->restore.buffered_rec_num; i++ )
         free(ctx->restore.buffered_records[i].data);
@@ -794,6 +798,8 @@ static void cleanup(struct xc_sr_context *ctx)
         xc_hypercall_buffer_free_pages(
             xch, dirty_bitmap, NRPAGES(bitmap_size(ctx->restore.p2m_size)));
 
+    xc_hypercall_buffer_free_pages(xch, verify_buf, MAX_BATCH_SIZE);
+
     free(ctx->restore.buffered_records);
     free(ctx->restore.populated_pfns);
 
diff --git a/tools/libs/guest/xg_sr_save.c b/tools/libs/guest/xg_sr_save.c
index 96d7e9e2f8..6b381f0219 100644
--- a/tools/libs/guest/xg_sr_save.c
+++ b/tools/libs/guest/xg_sr_save.c
@@ -86,11 +86,9 @@ static int write_checkpoint_record(struct xc_sr_context *ctx)
 static int write_batch(struct xc_sr_context *ctx)
 {
     xc_interface *xch = ctx->xch;
-    void *guest_mapping = NULL;
     int rc = -1;
-    unsigned int i, p, nr_pages = 0, nr_pages_mapped = 0;
+    unsigned int i, nr_pages = 0;
     unsigned int nr_pfns = ctx->save.nr_batch_pfns;
-    void *page, *orig_page;
     int iovcnt = 0;
     xen_pfn_t *const batch_pfns = ctx->save.buffers->batch_pfns;
     struct {
@@ -111,8 +109,6 @@ static int write_batch(struct xc_sr_context *ctx)
     xen_pfn_t *const mfns = ctx->save.buffers->mfns;
     /* Types of the batch pfns. */
     xen_pfn_t *const types = ctx->save.buffers->types;
-    /* Errors from attempting to map the gfns. */
-    int *const errors = ctx->save.buffers->errors;
     /* Pointers to locally allocated pages.  Need freeing. */
     void **const local_pages = ctx->save.buffers->local_pages;
     /* iovec[] for writev(). */
@@ -170,30 +166,26 @@ static int write_batch(struct xc_sr_context *ctx)
         mfns[nr_pages++] = mfns[i];
     }
 
-    if ( nr_pages > 0 )
+    if ( nr_pages )
     {
-        guest_mapping = xenforeignmemory_map(
-            xch->fmem, ctx->domid, PROT_READ, nr_pages, mfns, errors);
-        if ( !guest_mapping )
+        DECLARE_HYPERCALL_BUFFER_SHADOW(uint8_t, dest_buf,
+                                        &ctx->save.dest_buf);
+
+        rc = xg_foreignmemory_copy_from(xch, ctx->domid, nr_pages, dest_buf, mfns);
+        if ( rc < 0 )
         {
-            PERROR("Failed to map guest pages");
+            ERROR("xg_foreignmemory_copy_from failed");
             goto err;
         }
-        nr_pages_mapped = nr_pages;
 
-        for ( i = 0, p = 0; i < nr_pfns; ++i )
+        for ( unsigned int i = 0, p = 0; i < nr_pfns; ++i )
         {
+            void *page, *orig_page;
+
             if ( !page_type_has_stream_data(types[i]) )
                 continue;
 
-            if ( errors[p] )
-            {
-                ERROR("Mapping of pfn %#"PRIpfn" (mfn %#"PRIpfn") failed %d",
-                      batch_pfns[i], mfns[p], errors[p]);
-                goto err;
-            }
-
-            orig_page = page = guest_mapping + (p * PAGE_SIZE);
+            orig_page = page = dest_buf + (p * PAGE_SIZE);
             rc = ctx->save.ops.normalise_page(ctx, types[i], &page);
 
             if ( orig_page != page )
@@ -201,15 +193,13 @@ static int write_batch(struct xc_sr_context *ctx)
 
             if ( rc )
             {
-                if ( rc == -1 && errno == EAGAIN )
-                {
-                    set_bit(batch_pfns[i], ctx->save.deferred_pages);
-                    ++ctx->save.nr_deferred_pages;
-                    types[i] = XEN_DOMCTL_PFINFO_XTAB;
-                    --nr_pages;
-                }
-                else
+                if ( rc != -1 || errno != EAGAIN )
                     goto err;
+
+                set_bit(batch_pfns[i], ctx->save.deferred_pages);
+                ++ctx->save.nr_deferred_pages;
+                types[i] = XEN_DOMCTL_PFINFO_XTAB;
+                --nr_pages;
             }
             else if ( iov[iovcnt - 1].iov_base + iov[iovcnt - 1].iov_len !=
                       page )
@@ -222,8 +212,6 @@ static int write_batch(struct xc_sr_context *ctx)
             {
                 iov[iovcnt - 1].iov_len += PAGE_SIZE;
             }
-
-            rc = -1;
             ++p;
         }
     }
@@ -236,14 +224,13 @@ static int write_batch(struct xc_sr_context *ctx)
     if ( writev_exact(ctx->fd, iov, iovcnt) )
     {
         PERROR("Failed to write page data to stream");
+        rc = -1;
         goto err;
     }
 
     rc = ctx->save.nr_batch_pfns = 0;
 
  err:
-    if ( guest_mapping )
-        xenforeignmemory_unmap(xch->fmem, guest_mapping, nr_pages_mapped);
     for ( i = 0; i < nr_pfns; ++i )
     {
         free(local_pages[i]);
@@ -770,17 +757,21 @@ static int setup(struct xc_sr_context *ctx)
     int rc;
     DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
                                     &ctx->save.dirty_bitmap_hbuf);
+    DECLARE_HYPERCALL_BUFFER_SHADOW(uint8_t, dest_buf,
+                                    &ctx->save.dest_buf);
 
     rc = ctx->save.ops.setup(ctx);
     if ( rc )
         goto err;
 
+    dest_buf = xc_hypercall_buffer_alloc_pages(
+        xch, dest_buf, MAX_BATCH_SIZE);
     dirty_bitmap = xc_hypercall_buffer_alloc_pages(
         xch, dirty_bitmap, NRPAGES(bitmap_size(ctx->save.p2m_size)));
     ctx->save.deferred_pages = bitmap_alloc(ctx->save.p2m_size);
     ctx->save.buffers = calloc(1, sizeof(*ctx->save.buffers));
 
-    if ( !ctx->save.buffers || !dirty_bitmap || !ctx->save.deferred_pages )
+    if ( !ctx->save.buffers || !dirty_bitmap || !ctx->save.deferred_pages || !dest_buf )
     {
         ERROR("Unable to allocate memory for dirty bitmaps, deferred pages"
               " and various batch buffers");
@@ -793,7 +784,6 @@ static int setup(struct xc_sr_context *ctx)
     MEM_NOACCESS_INIT(ctx->save.buffers->na2);
     MEM_NOACCESS_INIT(ctx->save.buffers->na3);
     MEM_NOACCESS_INIT(ctx->save.buffers->na4);
-    MEM_NOACCESS_INIT(ctx->save.buffers->na5);
 
     rc = 0;
 
@@ -806,7 +796,8 @@ static void cleanup(struct xc_sr_context *ctx)
     xc_interface *xch = ctx->xch;
     DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
                                     &ctx->save.dirty_bitmap_hbuf);
-
+    DECLARE_HYPERCALL_BUFFER_SHADOW(uint8_t, dest_buf,
+                                    &ctx->save.dest_buf);
 
     xc_shadow_control(xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_OFF,
                       NULL, 0);
@@ -816,6 +807,7 @@ static void cleanup(struct xc_sr_context *ctx)
 
     xc_hypercall_buffer_free_pages(xch, dirty_bitmap,
                                    NRPAGES(bitmap_size(ctx->save.p2m_size)));
+    xc_hypercall_buffer_free_pages(xch, dest_buf, MAX_BATCH_SIZE);
     free(ctx->save.deferred_pages);
     free(ctx->save.buffers);
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387331.1628645 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHN-0005di-Vt; Mon, 10 Aug 2026 10:30:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387331.1628645; Mon, 10 Aug 2026 10:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHN-0005dR-Si; Mon, 10 Aug 2026 10:30:49 +0000
Received: by outflank-mailman (input) for mailman id 1387331;
 Mon, 10 Aug 2026 10:30:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHM-0005NJ-LC
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHM-00AlYD-1S
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:48 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a84f-e002-0a2a0a5209dd-0a2a450394e8-34
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:48 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a857-fae8-0a2a45030019-d1558033b954-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:47 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4954a2e73a9so10218785e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:47 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.45
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357847; x=1786962647; 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=qkv0EX1DlL9MRRhP+Wk/CTJgzWiZHG9SS1IgseXcsTo=;
        b=dssgC8bYdRsy1rv6mnHpmk95qopnTHYfBG03RycozOpT7Xmo8dQHhxB4Sl82MMD8Ky
         SL7nAtNBYvO64eJ8Wt1qRqhU5ylZ/0T9PIM5ZVbIe0qPqRVbfHUqhKxncYSJRrNaihlo
         9v3m550Ved+iR0qBsQwToFNObsJ2CDpgnY/2X2a9hRmv05Omh6rTU4ymTtMGwU1nGMwz
         ylLreFa3surfadgv7cEnSYpIXW5p14mpny2mXs1DodIOw71itLZgmVidYsN+fM2s37K/
         L/ACBDLCjUKnZFA4MKbauic9HfS9fKKO0j3uGCRlAXRRdgtQCJwHTEQi7Sa276EHiyqk
         dQSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357847; x=1786962647;
        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=qkv0EX1DlL9MRRhP+Wk/CTJgzWiZHG9SS1IgseXcsTo=;
        b=dUjd7OW6kr4BH7uGzI12euWAKiRyleMJxRQlElE1/X9oFlnevP7pkjKzn/b6UohWY+
         kREO8Tk39mH2zuwsn23LahkgcEE3XxUn2pJ3abjM2rmJxhaoBK49wkJXNNj8/UOeEMtT
         BvRUA16pxopJePk5Tf0udlLubNxl/EPay75/QeY2rTuKusdsTV61KG6Dq70/MNh1k7r3
         2qCt7VHkjQqbSbjv67MqFTW9UrnC/XehxXlIgmqy8n/3tK+t9EFyjl0hJhucU/+9dZJ8
         XTuSE928tNz+VfvXaIyJUGUB3AJ8l72iLFik6bTmjjM2fSIoII6N8U1Hqwiqxr4739Ua
         zTwg==
X-Gm-Message-State: AOJu0Yxbfd396HTgZ9Dei6HV0dGyxCccFE0393rBFMqGnlzB+FsOiDCG
	yMyYJSfZIetHeNkT2NSyIeUmTy9dcAHmikh437yZXjlN4lU2qaDvLiVeQeqQ2T46Mig=
X-Gm-Gg: AR+sD10RbCtaaPoqbfSabvQh9WZMXwhuYE0KepEB/FZ+LWAIO8Sxl8ZJrcRBiVM1upM
	WhUN2jP0Y9jsAxbV7KbFpTZVSr9JUwsVUm5ag6wwTmF8DGWO9xuYPQOfJMVzLKbPEcFKin72s1j
	sT2uKMD78B0rc0mCAzHDtyi3/Et+K4pe/w41DJduCq13EayJ3CKXwDwJijPLhEsqdOKWtJNl1dZ
	aZxtTjox4zWeJOQAx5+G+GRYtzLEtYMswz8p1l2T3foSdy2tTtznrFTGjyDlyQISsiUCaln1TEo
	4vdxEFFYNd+g4ORzafx/5SRPkvieQtmxMA2cX49I4yIAbY+FwGUChZ7Xiez/ysRv0b3EaDzyW9o
	W8lRZ6vNnEWAWqHXGkphlYcBb3piQzhzo4dUVvKRSBurOM+Iks6UpcbTKXBDH2yXSeYEkjjLxWS
	WtOlZo5YvIynE4h6JrCKx2g1J0BtfsZpTojVcuDjc9dDQkGj+bzTvb7VkRPHl7XggVuuARmrabz
	dia0edVq2QMvMcHedzLF+t6VT4iFMUMGwkeH/P5
X-Received: by 2002:a05:600c:1553:b0:495:5045:39e6 with SMTP id 5b1f17b1804b1-4994e7d3080mr453921205e9.17.1786357847166;
        Mon, 10 Aug 2026 03:30:47 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>,
	"Daniel P . Smith" <dpsmith@apertussolutions.com>
Subject: [PATCH v10 7/10] xen: implement new foreign copy hypercall
Date: Mon, 10 Aug 2026 11:30:10 +0100
Message-ID: <20260810103018.54564-8-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1786357847-74C884E9-DCD50404/0/0
X-purgate-type: clean
X-purgate-size: 10676

Add a sub hypercall to __HYPERVISOR_memory_op to allow to read/write
memory from/to a foreign domain.

Extending MMUEXT_COPY_PAGE seems better on first sight but considering
that MMUEXT is meant for PV only and trying to change that sub-op this
solution is better.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
Changes since v4:
- Fix typo in comment.

Changes since v5:
- update xen_foreigncopy structure comments;
- move check for no frames after checking the domain;
- use mnemonic instead of 1U;
- fix page type checks;
- do not overwrite error copying back structure;
- latch MFN value;
- improved commit message.

Changes since v6:
- check permissions before nr_frames;
- different flag for read or write;
- print error as negative for coherence;
- update some comments;
- different page types for different architectures.

Changes since v9:
- page permission checks like MMU_UPDATE;
- new XSM settings;
- do not restrict domain;
- different explanation why HVM guests are not supported.
---
 xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
 xen/include/public/memory.h |  45 ++++++++++-
 xen/include/xsm/dummy.h     |  14 ++++
 xen/include/xsm/hooks.h     |   2 +
 xen/xsm/flask/hooks.c       |  10 +++
 5 files changed, 219 insertions(+), 1 deletion(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 9443e35a7f..29a70d99b1 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1548,6 +1548,141 @@ static int acquire_resource(
     return rc;
 }
 
+/*
+ * The "noinline" qualifier avoids the compiler to create a large function
+ * consuming quite a lot of stack.
+ */
+static int noinline mem_foreigncopy(
+    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
+{
+    struct domain *d, *const currd = current->domain;
+    xen_foreigncopy_t copy;
+    int rc, direction;
+
+    if ( copy_from_guest(&copy, arg, 1) )
+        return -EFAULT;
+
+    if ( copy.flags & ~XENMEM_foreigncopy_direction )
+        return -EINVAL;
+
+    direction = copy.flags & XENMEM_foreigncopy_direction;
+
+    d = rcu_lock_domain_by_any_id(copy.domid);
+    if ( !d )
+        return -ESRCH;
+
+    /*
+     * Check we are allowed to map and access these foreign pages.
+     */
+    if ( direction == XENMEM_foreigncopy_from )
+        rc = xsm_foreigncopy_from(XSM_TARGET, currd, d);
+    else
+        rc = xsm_foreigncopy_to(XSM_TARGET, currd, d);
+    if ( rc )
+        goto out;
+
+    while ( copy.nr_frames )
+    {
+        /*
+         * Arbitrary size.  Not too much stack space, and a reasonable stride
+         * for continuation checks.
+         */
+        xen_pfn_t gfn_list[32];
+        unsigned int todo = MIN(ARRAY_SIZE(gfn_list), copy.nr_frames);
+
+        rc = -EFAULT;
+        if ( copy_from_guest(gfn_list, copy.frame_list, todo) )
+            goto out;
+
+        for ( unsigned int i = 0; i < todo; i++ )
+        {
+            struct page_info *foreign_page;
+            mfn_t foreign_mfn;
+            void *foreign;
+            p2m_type_t p2mt;
+            p2m_query_t q = (direction == XENMEM_foreigncopy_to) ?
+                            P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
+
+            foreign_page = get_page_from_gfn(d, gfn_list[i], &p2mt, q);
+
+            if ( unlikely(p2m_is_paged(p2mt)) )
+            {
+                if ( foreign_page )
+                    put_page(foreign_page);
+                p2m_mem_paging_populate(d, _gfn(gfn_list[i]));
+                p2mt = p2m_ram_paging_in;
+                foreign_page = NULL;
+            }
+
+            if ( unlikely(!foreign_page) )
+            {
+                rc = -ENOENT;
+                if ( p2mt != p2m_ram_paging_in )
+                {
+                    gdprintk(XENLOG_WARNING,
+                             "Error accessing foreign gfn %" PRI_gfn "\n",
+                             gfn_list[i]);
+                    rc = -EINVAL;
+                }
+                copy.nr_frames -= i;
+                guest_handle_add_offset(copy.frame_list, i);
+                goto out;
+            }
+
+            foreign_mfn = page_to_mfn(foreign_page);
+
+            /* A page is dirtied when it's being copied to. */
+            if ( direction == XENMEM_foreigncopy_to )
+                paging_mark_dirty(d, foreign_mfn);
+
+            foreign = map_domain_page(foreign_mfn);
+            if ( direction == XENMEM_foreigncopy_from )
+                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
+            else
+                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);
+            unmap_domain_page(foreign);
+            put_page(foreign_page);
+
+            if ( unlikely(rc) )
+            {
+                gdprintk(XENLOG_WARNING,
+                         "Error %d copying gfn %" PRI_gfn "\n",
+                         rc, gfn_list[i]);
+                copy.nr_frames -= i;
+                guest_handle_add_offset(copy.frame_list, i);
+                goto out;
+            }
+
+            guest_handle_add_offset(copy.buffer, PAGE_SIZE);
+        }
+
+        copy.nr_frames -= todo;
+        guest_handle_add_offset(copy.frame_list, todo);
+
+        if ( copy.nr_frames && hypercall_preempt_check() )
+        {
+            rc = hypercall_create_continuation(
+                __HYPERVISOR_memory_op, "lh", XENMEM_foreigncopy, arg);
+            goto out;
+        }
+    }
+
+    rc = 0;
+
+ out:
+    rcu_unlock_domain(d);
+
+    /*
+     * Update in all cases, it allows the caller to know how many
+     * frames were successfully copied and the continuation to
+     * continue correctly.
+     */
+    if ( __copy_to_guest(arg, &copy, 1) && rc >= 0 )
+        rc = -EFAULT;
+
+    return rc;
+}
+
 long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d, *curr_d = current->domain;
@@ -2027,6 +2162,20 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             start_extent);
         break;
 
+    case XENMEM_foreigncopy:
+        /*
+         * Instead of using "start_extent" for the continuation, we update
+         * the xen_foreigncopy structure back, so we are not constrained by
+         * MEMOP_EXTENT_SHIFT.
+         * We copy it back also to tell the caller where the copy stopped
+         * (either for error or because all frames were copied).
+         */
+        if ( unlikely(start_extent) )
+            return -EINVAL;
+
+        rc = mem_foreigncopy(guest_handle_cast(arg, xen_foreigncopy_t));
+        break;
+
     default:
         rc = arch_memory_op(cmd, arg);
         break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index bd9fc37b52..66bd2a6c42 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
 typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
 DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
 
-/* Next available subop number is 29 */
+/*
+ * Copy memory from/to a given domain.
+ * This calls is meant to replace expensive operations during migration which
+ * are only supported for PV guests.
+ */
+#define XENMEM_foreigncopy 29
+struct xen_foreigncopy {
+    /* IN - The domain whose memory is to be copied. */
+    domid_t domid;
+
+    /* IN - Flags. */
+#define XENMEM_foreigncopy_from 0
+#define XENMEM_foreigncopy_to 1
+#define XENMEM_foreigncopy_direction 1
+    uint16_t flags;
+
+    /*
+     * IN/OUT
+     *
+     * As an IN parameter number of frames of the domain to be copied.
+     * On output updated number of frames left (0 if success).
+     */
+    uint32_t nr_frames;
+
+    /*
+     * IN/OUT
+     *
+     * Frames to be copied.
+     * On output updated to point to the first frame unhandled, if any.
+     */
+    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
+
+    /*
+     * IN/OUT
+     *
+     * Guest buffer to read/write from.
+     * On output updated to point to the first page pointer unhandled.
+     */
+    XEN_GUEST_HANDLE(uint8) buffer;
+};
+typedef struct xen_foreigncopy xen_foreigncopy_t;
+DEFINE_XEN_GUEST_HANDLE(xen_foreigncopy_t);
+
+/* Next available subop number is 30 */
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 131631cb27..dcdb7f5396 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -569,6 +569,20 @@ static XSM_INLINE int cf_check xsm_map_gmfn_foreign(
     return xsm_default_action(action, d, t);
 }
 
+static XSM_INLINE int cf_check xsm_foreigncopy_from(
+    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
+{
+    XSM_ASSERT_ACTION(XSM_TARGET);
+    return xsm_default_action(action, d, t);
+}
+
+static XSM_INLINE int cf_check xsm_foreigncopy_to(
+    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
+{
+    XSM_ASSERT_ACTION(XSM_TARGET);
+    return xsm_default_action(action, d, t);
+}
+
 #ifdef CONFIG_HVM
 
 static XSM_INLINE int cf_check xsm_hvm_param(
diff --git a/xen/include/xsm/hooks.h b/xen/include/xsm/hooks.h
index 5bdb23f26d..63e2831d31 100644
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -58,6 +58,8 @@ XSM_HOOK(int, add_to_physmap, struct domain *, struct domain *)
 XSM_HOOK(int, remove_from_physmap, struct domain *, struct domain *)
 XSM_HOOK(int, map_gmfn_foreign, struct domain *, struct domain *)
 XSM_HOOK(int, claim_pages, struct domain *)
+XSM_HOOK(int, foreigncopy_from, struct domain *, struct domain *);
+XSM_HOOK(int, foreigncopy_to, struct domain *, struct domain *);
 
 XSM_HOOK(int, console_io, struct domain *, int)
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3cfdf6bf08..281800e176 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1368,6 +1368,16 @@ static int cf_check flask_map_gmfn_foreign(struct domain *d, struct domain *t)
     return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
 }
 
+static int cf_check flask_foreigncopy_from(struct domain *d, struct domain *t)
+{
+    return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ);
+}
+
+static int cf_check flask_foreigncopy_to(struct domain *d, struct domain *t)
+{
+    return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
+}
+
 #ifdef CONFIG_HVM
 
 static int cf_check flask_hvm_param(struct domain *d, unsigned long op)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387332.1628653 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHQ-0005wj-BT; Mon, 10 Aug 2026 10:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387332.1628653; Mon, 10 Aug 2026 10:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHQ-0005wW-7O; Mon, 10 Aug 2026 10:30:52 +0000
Received: by outflank-mailman (input) for mailman id 1387332;
 Mon, 10 Aug 2026 10:30:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHO-0005mI-Re
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHO-00Dyin-8C
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:50 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a854-bab6-0a2a0a5309dd-0a2a450799ec-14
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:50 +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 <freddy77@gmail.com>)
 id 6a79a85a-b4ea-0a2a45070019-d1558035a911-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:50 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4954a9e8490so22911205e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:50 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357849; x=1786962649; 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=3+Xmp4HOhS3Pe3sNnwkV9Nev075F3jzmTYNfYLmJyJ8=;
        b=gtDSvt3XLEF0+lvQmQpagPOxD+0HfyCi9SY4SgOtI34Q71fF520A50KI3R6asKiy7o
         EcYlQ3rf4vzvzkchvPC01UnKK++WMHlUXH5OH706GiBiqvJmi+8U6zknAp+RHmOuY0Tm
         Hdp4ppYkczqspONQlul4iFdjhg/pVXFFOo/CPqeM5m/7HBN2E8w5pSC17iPxKzAgZ25S
         uOKOV4HqmTJFIXMyJVIfJgSyvCcNZ4r+OpQMO9LMWYVp1FgrISAx7+4gLTMyaTZqnoay
         hAkRBTQPbtx2qHVGzVMwATUKSGA7uhSiwtjyvijDYIQCm9+fuL6BKjsmeJ/nvGY5rMYo
         icZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357849; x=1786962649;
        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=3+Xmp4HOhS3Pe3sNnwkV9Nev075F3jzmTYNfYLmJyJ8=;
        b=nNMea2ZxnrskLsVM7ZtZTuExUNL9p7rztECnxYx/Jyh9bjzpg5GpAPiPipHYJ/Qpik
         EMZ3yoAbdHImBimhP0g8Hc5mlCUW5vkXbLUij9OSBdgsf4riDudsERx6HrqpejkAqFDF
         iv7X3xzGZJ50P5crPIcj1xzbh/MvcsOPtIk6QJL9u5kEaVM/fN6EWlj0BQSBOOKBDUte
         fk+vMm3m7Tm0engIlvzKElhTuWl1ITEiKfzw7j0YabFyH6JTadG0mlf7C70IC4D5fFnd
         brNLTg3s76yB8zvmRP7qA0RHIf8TjXNPQiWKcS7duVSCGH/11Ux1qruDJ8/yMfcG+qRk
         9Zdw==
X-Gm-Message-State: AOJu0YyhS9Da4dMD8o5+/DCwl3AeCosrtOZm0jGpyyVd74k48sUEVIBm
	Pfbcaps3+vtKSJSk4oK1i7D8WHeRBM7YInfadNtMttnFqAys1LWEhCv546Wn0ljjjFs=
X-Gm-Gg: AR+sD11E9+7ILZ58VGN/7jJlVXLWJNpaGETrhUnec912ha4u18E6sqbVHs5zAhEYzsB
	TM1YunT6CHuk1seD3h+az2jpbweExOvp2Ui0X6UMWw47+GAdIMTfyYdESfF4FSXZ3TXxEsDfdGz
	msitmMpjZVoatZYA6WCr0EWYmXTreM55GGnx4sqRv89hxakWY5/0edBZ687FOXHi04TkUqWD1CN
	U3xFJ8OgmR9NlHmDZc98w92yo0oBvxNnj14n3w8f67SDBCra55FaiyEWyFtPpMT3f7JYjqcpBLs
	cJgIcOy6CoWtr6gj/WWBAY35lKSWhimmbXi3vRjanX/JovtP2p/yFdDQCNl/jD6Bfhkx3llsLBc
	q1YDmTlUsgQVDGXaGTb9tu41AByUxiybfpJ0+68mHoZoCRhKNHwxAG4hqK7drROyrtJ/0Oc12Ut
	8MGGOiG7MofJyEwlmspeDEyxIQv7mfXQw4r26RdhNOuVjy+MOE7MLeCr4P3ba6yF7u27Pcp1VAy
	YVnfjMOzSG1VJaixXneYAEIWJZPJT1nFaLOoVFm
X-Received: by 2002:a05:600c:3154:b0:495:3bc6:d381 with SMTP id 5b1f17b1804b1-49962453c45mr201315725e9.2.1786357848475;
        Mon, 10 Aug 2026 03:30:48 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH v10 8/10] privcmd: Add definition for new Linux privcmd to access new Xen hypercall
Date: Mon, 10 Aug 2026 11:30:11 +0100
Message-ID: <20260810103018.54564-9-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786357850-374D3AE4-0A5726EE/0/0
X-purgate-type: clean
X-purgate-size: 1401

Userspace should use new ioctl to access new hypercall.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
Changes since v4:
- update comment.
---
 tools/include/xen-sys/Linux/privcmd.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h
index 607dfa2287..7a3c41308b 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -100,6 +100,14 @@ typedef struct privcmd_pcidev_get_gsi {
 	__u32 gsi;
 } privcmd_pcidev_get_gsi_t;
 
+typedef struct privcmd_foreigncopy {
+	domid_t dom;          /* Foreign domain. */
+	__u16 dir;            /* Direction,  0 from, 1 to. */
+	__u32 num;            /* Number of pages to copy. */
+	const xen_pfn_t __user *pfns; /* Array of pfns. */
+	void __user *buffer;  /* Buffer to copy to/from. */
+} privcmd_foreigncopy_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -121,6 +129,8 @@ typedef struct privcmd_pcidev_get_gsi {
 	_IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
 #define IOCTL_PRIVCMD_PCIDEV_GET_GSI			\
 	_IOC(_IOC_NONE, 'P', 10, sizeof(privcmd_pcidev_get_gsi_t))
+#define IOCTL_PRIVCMD_FOREIGNCOPY				\
+	_IOWR('P', 11, privcmd_foreigncopy_t)
 #define IOCTL_PRIVCMD_UNIMPLEMENTED				\
 	_IOC(_IOC_NONE, 'P', 0xFF, 0)
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387334.1628660 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHQ-0005zd-S1; Mon, 10 Aug 2026 10:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387334.1628660; Mon, 10 Aug 2026 10:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHQ-0005yb-GH; Mon, 10 Aug 2026 10:30:52 +0000
Received: by outflank-mailman (input) for mailman id 1387334;
 Mon, 10 Aug 2026 10:30:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHP-0005rk-Bq
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHO-00Dyin-Oq
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:50 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a85a-bab6-0a2a0a5309dd-0a2a450ce3f8-0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:50 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a85a-f479-0a2a450c0019-d1558032ad5d-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:50 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49558ce01afso13250535e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:50 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357850; x=1786962650; 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=kAXV9ixt1kgi3GnwQ2iOZUoRsAZqt/4+AFDCaE6CjSg=;
        b=P5iCpsfNaVH88Si13CsIDlLOFZztr6wXx6/QCdl1ZFuI4R/OZccH+ZMMxp5OAFoS2/
         IQsUMSmvlVryFWImXqacDwF/dXwMabeeRyrSsqyRmyCaDxSgT2MRpkerCM/tdLkE3bA4
         pHO693NJptx9bwrdUmbznIh8L0PrUL0nGGGYF+9zfCA9+SlcohYv5LiDaZ3X/8JTG5k4
         lPl4aplLUymxPbI55R8UpTejLhm2ybPnjL7xF8QJCkWygt9ZcVVOQgarR6ELVijkoort
         mS8oyYbSqkhIhhgT0Fn35QTFIiy6Bma7f8pmcOUcrTHtKkdSSxZggFwjpaMC1ieAxNqC
         pe/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357850; x=1786962650;
        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=kAXV9ixt1kgi3GnwQ2iOZUoRsAZqt/4+AFDCaE6CjSg=;
        b=rY/hK24RFYvWKtj+nJpwj03KxQepQ0sGNqDpP6PnG2hHUWHMazsQ3VXQ+WLGybocg7
         oxIC3p7LD41aiEU/+mzNqI30WPF0riSlXcsgevmDYo6jsGF3EmPCIJkSfL6SV3Mg9YSy
         k8gXbsS2yMGJX8v4OGr909Q9mQG52Zx9uYCdme6ONg7Yy5O5PW+N+DCQpNYp7KnQPcHB
         z8MQlwrQNYtvU+STulPuJurlhP72Ahlhg/4xNyxiTzJ7tzSBRJajXxTz+QLC7BR5wk6X
         wysYMoeHEM2x3PLsPWXdAYdIHc37ZFmFxBjp1G2rE3tUwH/lN76BrnC+gm1EoMzI8ifc
         Fnmw==
X-Gm-Message-State: AOJu0YzncX2+NPhg9m9OZTiQgTtN53M6hpXdS0fmTUkOCQ7h43ioOg5W
	YzQjJpHOg7z9gB4eUsop3w4HUtkqwfXbLQCpLEmbyfKCKlZLd23Cetew9PFZSal2T6s=
X-Gm-Gg: AR+sD11ZoQpDWYJWdZduz8EPTTu2UDEv+8gGN6W3lT3OZLoGxmLGxIqtzLTuPqzTumh
	G8x4ISKAgJLt0Sz/WiA55jMZS5pUdnvoRDFgHoy5RKuzHPD7f2ay0VkTJA07sgi3+FDGch8wK2N
	+CinvDQ2iLAA4CgqFt9pZoSxabkrAmU0kUeHQ743AvGZySd/t+gPgQgPufO+/0Ub0ddKgIcrFsC
	GiORVZfh1uP5Ap9mdN5rNCIzrwfuYwPVn7j54wE8dO9v/j+5TKWOwo9jZzzqsGpRpTs313sX1P/
	osto5luJSZWm+0/B3vqJPn2Z39PqIXWUKwTeIsfn6U8S0lde8jUO/kz7T6E9JRzyCI9QjbH773p
	fepH99Yx93OIwHAKwBTSC+tMRSohwMM67SEogEGkRWgvmswSk0OszqtRoKo1T8Hw1wkBBp11v7e
	rCZa+7L0VNk1NTkD5hUXWRgFla0Wo8Gt/k3KT913+QL5q3Q1k21QYX7TLOYZzOT06RqcXfkCuuU
	VUv4VheoKXoxPdPBeyQpRKk4auOfKPdtJdIbbBD
X-Received: by 2002:a05:600c:35c8:b0:499:593b:a15b with SMTP id 5b1f17b1804b1-499593ba192mr395987645e9.1.1786357850038;
        Mon, 10 Aug 2026 03:30:50 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH v10 9/10] libs/guest: use new hypercall if available
Date: Mon, 10 Aug 2026 11:30:12 +0100
Message-ID: <20260810103018.54564-10-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786357850-51D34A5B-337B1D1C/0/0
X-purgate-type: clean
X-purgate-size: 4281

Use new hypercall if available, otherwise fall back to map+copy+unmap
sequence.

I took some statistics while migrating some machines instrumenting the
code to use new and old code and doing it 5 times in a row for each and
the raw operation takes at least 4 (from) or 5 (to) times less.

Specifically for a test done with a machine with Intel Xeon Sapphire
Rapids CPUs and migrating a Windows 10 machine with 12 GB of RAM
the ratios were:
- 4.9 times faster copying from guest to dom0;
- 5.3 times faster copying to guest from dom0.
The test was repeated multiple times resulting consistent in all rans.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
Changes since v4:
- use int8_t instead of char for signed type.

Changes since v6:
- add some statistics.

Changes since v9:
- fixed a pointer initialization.
---
 tools/libs/guest/xg_sr_common.c | 47 ++++++++++++++++++++++++++-------
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/tools/libs/guest/xg_sr_common.c b/tools/libs/guest/xg_sr_common.c
index 90da21c35f..ce5026c707 100644
--- a/tools/libs/guest/xg_sr_common.c
+++ b/tools/libs/guest/xg_sr_common.c
@@ -156,11 +156,6 @@ static void __attribute__((unused)) build_assertions(void)
     BUILD_BUG_ON(sizeof(struct xc_sr_rec_hvm_params)        != 8);
 }
 
-enum {
-    foreigncopy_from,
-    foreigncopy_to
-};
-
 static int xg_foreignmemory_copy(xc_interface *xch, domid_t domid,
                                  int dir, size_t nr_pages, void *buffer,
                                  const xen_pfn_t foreign_pfns[nr_pages])
@@ -174,8 +169,42 @@ static int xg_foreignmemory_copy(xc_interface *xch, domid_t domid,
         return -1;
     }
 
+    /*
+     * If foreign copy is supported, -1 not initialized, 0 not supported,
+     * 1 supported.
+     */
+    static int8_t foreign_copy_supported = -1;
+
+    if ( foreign_copy_supported )
+    {
+        int rc;
+        privcmd_foreigncopy_t copy = {
+            .dom = domid,
+            .dir = dir,
+            .num = nr_pages,
+            .buffer = buffer,
+        };
+        DECLARE_HYPERCALL_BOUNCE_IN(foreign_pfns, nr_pages * sizeof(xen_pfn_t));
+
+        if ( xc_hypercall_bounce_pre(xch, foreign_pfns) )
+            return -1;
+
+        copy.pfns = (xen_pfn_t *)HYPERCALL_BUFFER_AS_ARG(foreign_pfns);
+
+        rc = ioctl(xencall_fd(xch->xcall), IOCTL_PRIVCMD_FOREIGNCOPY, &copy);
+        if ( foreign_copy_supported < 0 )
+            foreign_copy_supported =
+                (!rc || (errno != ENOTTY && errno != ENOSYS));
+
+        xc_hypercall_bounce_post(xch, foreign_pfns);
+
+        if ( foreign_copy_supported )
+            return rc;
+    }
+
+    /* Fallback, emulate. */
     int err[nr_pages];
-    const int prot = (dir == foreigncopy_from) ? PROT_READ : PROT_READ|PROT_WRITE;
+    const int prot = (dir == XENMEM_foreigncopy_from) ? PROT_READ : PROT_READ|PROT_WRITE;
 
     void *p = xenforeignmemory_map(xch->fmem, domid, prot, nr_pages, foreign_pfns, err);
     if ( !p )
@@ -189,7 +218,7 @@ static int xg_foreignmemory_copy(xc_interface *xch, domid_t domid,
             return -1;
         }
 
-    if ( dir == foreigncopy_from )
+    if ( dir == XENMEM_foreigncopy_from )
         memcpy(buffer, p, nr_pages * XC_PAGE_SIZE);
     else
         memcpy(p, buffer, nr_pages * XC_PAGE_SIZE);
@@ -201,7 +230,7 @@ int xg_foreignmemory_copy_from(xc_interface *xch, domid_t dom,
                                size_t nr_pages, void *dest,
                                const xen_pfn_t source[nr_pages])
 {
-    return xg_foreignmemory_copy(xch, dom, foreigncopy_from,
+    return xg_foreignmemory_copy(xch, dom, XENMEM_foreigncopy_from,
                                  nr_pages, dest, source);
 }
 
@@ -209,7 +238,7 @@ int xg_foreignmemory_copy_to(xc_interface *xch, domid_t dom,
                              size_t nr_pages, const xen_pfn_t dest[nr_pages],
                              const void *source)
 {
-    return xg_foreignmemory_copy(xch, dom, foreigncopy_to,
+    return xg_foreignmemory_copy(xch, dom, XENMEM_foreigncopy_to,
                                  nr_pages, (void *) source, dest);
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 10:30:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 10:30:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387336.1628668 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHS-0006LE-8S; Mon, 10 Aug 2026 10:30:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387336.1628668; Mon, 10 Aug 2026 10:30:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNHS-0006Jf-1g; Mon, 10 Aug 2026 10:30:54 +0000
Received: by outflank-mailman (input) for mailman id 1387336;
 Mon, 10 Aug 2026 10:30:53 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtNHQ-0005zg-Q5
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 10:30:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNHQ-000BDZ-6F
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 12:30:52 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a854-2eae-0a2a0a5409dd-0a2a4509bf7e-46
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:52 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a79a85c-be1a-0a2a45090019-d1558029d1c2-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 12:30:52 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so14895985e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 03:30:52 -0700 (PDT)
Received: from localhost.localdomain ([31.111.172.30])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995bb8b668sm218478455e9.0.2026.08.10.03.30.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 03:30:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786357851; x=1786962651; 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=UVOrYo9kwDL27bIBgSRi6l0uRZVsLr0xOhtweF06SqI=;
        b=OFQuNM/CI3Ms3ghElvx6gHV113l9f8rJdEPvrkjHSnPr/Fl7VuGVd6HOrhKZpudEKU
         VsgqdHY0flt9zyRLmzpU3zwUbLIFBp9EZbBad5flLsliatOf50DNxMxyg677h6eo1y3u
         3eBdyqtLeFbwqQaoXR1QI0rPH2jiTj5M6CFsCINN7apxor5ivpAXUffe9YK9aD8NLkez
         I1BlKtfemqzeT86jBU74TXh14bntZGjYqziICDDf/UWuHWRPYFG8+aEpjLVEbE1SrmL6
         1ffu1VoSwkJqfXG18P0PtsNvUfbf4A7gbAFSR9KbqHaGp6IbHlzS4FdknKZcrzh9cqRK
         H2fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786357851; x=1786962651;
        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=UVOrYo9kwDL27bIBgSRi6l0uRZVsLr0xOhtweF06SqI=;
        b=qbYnE6xRPVHuZ0s8uCRbR6NBYLuLocC1ujczkNtCKV8hdSu1hh3zzqgVNvG7QA1LUx
         3RCbQdjx0Aq9YF18MXMvRSnhst9c2OVM+I213AlWA1wIIUIxRWyw37lHPwrdg7KQKlQv
         T6O79/1xDX1l2b9Dmtvp24yOQtHUj2G3qGF596SEeo8cXV9P0tdWSfPUqUayfldq15nx
         ljxl/RBwUDUkmSBFd3Pl4B/D1+ywUJMuZ/YMYKF8QdO95W+qrcAa2MqNDf3ClD6UF5as
         BDeBabtQT0bB9LT/4VrddCly6NZkcgu/sqozD6TVWWQcWwNovyxbz0XCrdtEBctI9147
         SpXw==
X-Gm-Message-State: AOJu0YzUxup0D13r3gziyWX8EzSqjidParyWHBB24FpMtibY8S030vGI
	e1vn9bgyQOgMSux978Stui3mtbvqCAFMbpwQHB9N1fCz9UXKl5DIo7dIEcBnLe6kWVk=
X-Gm-Gg: AR+sD12cUWJyexX2URDj4+cUh5U9q2py+t52F6gRZjy3syVxB00j1zvGu1dFvljZWfI
	jNS8D3nX/Hw26AoBjLHPyfqreAiGOHsj8iGVlk5y8bTkHCw2mvzC1xIczWi4hdwMD3ybxqrVf4j
	nsfzynpIQUWCJ0QD3Y0RaAG2RSu+IRIVJK9okYT0HyCuPfVFpVM0Gs4B0Zbnpltr+BHMZjfdNEe
	LKKLL8ZbVjfFzef+8s8dH6usgZmDt1TMsFKyVsvWXuHt4v3c9XSTQuEdaUECy/8kYtXN99HlHBs
	/rskhkG98SRMFfLTmvpQpz2XfBstRgGAN4VYFISTVYlrZez1tdmjk8hTkIKRVWIiEzBOkg5ep1w
	c9soKxsffV/4+ixIczmR4R3JhA3g0UGYImo/JkAmZ/P6pNoAbRmOR9TA38PlL4rsmcFw16bm1+x
	Fz3i5OosHXGPfMQPsXEYL1D/AZDeYLv1COiZeSDN0NA58W54gXeYgwSB5skyIhUOVWkz5+jESN+
	pFjPc4pGWyBRIrsoP2BTjOBiU35Vy4mAneEVCkm
X-Received: by 2002:a05:600c:4f45:b0:493:c47f:3c55 with SMTP id 5b1f17b1804b1-49972764ed2mr11520785e9.5.1786357851500;
        Mon, 10 Aug 2026 03:30:51 -0700 (PDT)
From: Frediano Ziglio <freddy77@gmail.com>
X-Google-Original-From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: [PATCH Linux v6 10/10] xen/privcmd: Add new ABI to allow copying foreign memory
Date: Mon, 10 Aug 2026 11:30:13 +0100
Message-ID: <20260810103018.54564-11-frediano.ziglio@citrix.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1786357852-BCAC8034-8D57BA6A/0/0
X-purgate-type: clean
X-purgate-size: 6569

This new ABI allows to copy foreign domain memory to/from a buffer.
This avoids having to map/copy/unmap foreign memory which is
expensive.
This operation is done particularly when migrating VMs.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
--
Changes since v4:
- fix wrong assign;
- use set_xen_guest_handle to set handle;
- wrap slow hypercall with xen_preemptible_hcall_{begin,end};
- use _IOWR for ioctl code to be more specific;
- use __copy_to_user if buffer already checked.

Changes since v6:
- compatibility ARM/x86.

---
 arch/x86/include/asm/xen/interface.h |  3 ++
 drivers/xen/privcmd.c                | 49 ++++++++++++++++++++++++++++
 include/uapi/xen/privcmd.h           | 10 ++++++
 include/xen/arm/interface.h          |  2 ++
 include/xen/interface/memory.h       | 37 +++++++++++++++++++++
 5 files changed, 101 insertions(+)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index a078a2b0f032..fc76fac8fb16 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -59,6 +59,7 @@
 #elif defined(__x86_64__)
 #define set_xen_guest_handle(hnd, val)	do { (hnd).p = val; } while (0)
 #endif
+#define get_xen_guest_handle(hnd) ((hnd).p)
 #else
 #if defined(__i386__)
 #define set_xen_guest_handle(hnd, val)			\
@@ -70,6 +71,7 @@
 #elif defined(__x86_64__)
 #define set_xen_guest_handle(hnd, val)	do { (hnd) = val; } while (0)
 #endif
+#define get_xen_guest_handle(hnd) (hnd)
 #endif
 
 #ifndef __ASSEMBLER__
@@ -91,6 +93,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 #endif
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 725a49a0eee7..55364801ba2e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -1522,6 +1522,51 @@ static inline void privcmd_ioeventfd_exit(void)
 }
 #endif /* CONFIG_XEN_PRIVCMD_EVENTFD */
 
+static long privcmd_ioctl_foreigncopy(
+	struct file *file, void __user *udata)
+{
+	const struct privcmd_data *const data = file->private_data;
+	long ret;
+	struct privcmd_foreigncopy copy;
+	struct xen_foreigncopy xcopy;
+
+	if (copy_from_user(&copy, udata, sizeof(copy)))
+		return -EFAULT;
+	if (copy.dir & ~1u)
+		return -EINVAL;
+	if (copy.num >= U32_MAX >> PAGE_SHIFT)
+		return -EINVAL;
+	if (!access_ok(copy.pfns, copy.num * sizeof(*copy.pfns)))
+		return -EFAULT;
+	if (!access_ok(copy.buffer, copy.num << PAGE_SHIFT))
+		return -EFAULT;
+
+	/* If restriction is in place, check the domid matches */
+	if (data->domid != DOMID_INVALID && data->domid != copy.dom)
+		return -EPERM;
+
+	xcopy.domid = copy.dom;
+	xcopy.flags = copy.dir;
+	xcopy.nr_frames = copy.num;
+	set_xen_guest_handle(xcopy.frame_list,  (__force xen_pfn_t *)copy.pfns);
+	set_xen_guest_handle(xcopy.buffer, (__force uint8_t *)copy.buffer);
+
+	xen_preemptible_hcall_begin();
+	ret = HYPERVISOR_memory_op(XENMEM_foreigncopy, &xcopy);
+	xen_preemptible_hcall_end();
+
+	/* copy values back in case of error */
+	if (ret) {
+		copy.num = xcopy.nr_frames;
+		copy.pfns = get_xen_guest_handle(xcopy.frame_list);
+		copy.buffer = get_xen_guest_handle(xcopy.buffer);
+		if (__copy_to_user(udata, &copy, sizeof(copy)))
+			ret = -EFAULT;
+	}
+
+	return ret;
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -1569,6 +1614,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_pcidev_get_gsi(file, udata);
 		break;
 
+	case IOCTL_PRIVCMD_FOREIGNCOPY:
+		ret = privcmd_ioctl_foreigncopy(file, udata);
+		break;
+
 	default:
 		break;
 	}
diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index 8e2c8fd44764..993b501e35bf 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -131,6 +131,14 @@ struct privcmd_pcidev_get_gsi {
 	__u32 gsi;
 };
 
+struct privcmd_foreigncopy {
+	domid_t dom;		/* foreign domain */
+	__u16 dir;		/* direction,  0 from, 1 to */
+	__u32 num;		/* number of pages to copy */
+	const xen_pfn_t __user *pfns;	/* array of pfns */
+	void __user *buffer;	/* buffer to copy to/from */
+};
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -164,5 +172,7 @@ struct privcmd_pcidev_get_gsi {
 	_IOW('P', 9, struct privcmd_ioeventfd)
 #define IOCTL_PRIVCMD_PCIDEV_GET_GSI				\
 	_IOC(_IOC_NONE, 'P', 10, sizeof(struct privcmd_pcidev_get_gsi))
+#define IOCTL_PRIVCMD_FOREIGNCOPY				\
+	_IOWR('P', 11, struct privcmd_foreigncopy)
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/include/xen/arm/interface.h b/include/xen/arm/interface.h
index 61360b89da40..20ee1ed44436 100644
--- a/include/xen/arm/interface.h
+++ b/include/xen/arm/interface.h
@@ -27,6 +27,7 @@
 			*(uint64_t *)&(hnd) = 0;	\
 		(hnd).p = val;				\
 	} while (0)
+#define get_xen_guest_handle(hnd) ((hnd).p)
 
 #define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
 
@@ -53,6 +54,7 @@ DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(uint8_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 DEFINE_GUEST_HANDLE(xen_ulong_t);
 
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 1a371a825c55..5981402fccde 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -325,4 +325,41 @@ struct xen_mem_acquire_resource {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_mem_acquire_resource);
 
+/*
+ * Copy memory from/to a given domain.
+ */
+#define XENMEM_foreigncopy 29
+struct xen_foreigncopy {
+    /* IN - The domain whose resource is to be copied */
+    domid_t domid;
+
+    /* IN - Flags */
+#define XENMEM_foreigncopy_from 0
+#define XENMEM_foreigncopy_to 1
+#define XENMEM_foreigncopy_direction 1
+    uint16_t flags;
+
+    /*
+     * IN
+     *
+     * As an IN parameter number of frames of the domain to be copied.
+     */
+    uint32_t nr_frames;
+
+    /*
+     * IN
+     *
+     * Frames to be copied.
+     */
+    GUEST_HANDLE(xen_pfn_t) frame_list;
+
+    /*
+     * IN/OUT
+     *
+     * Userspace buffer to read/write from.
+     */
+    GUEST_HANDLE(uint8_t) buffer;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_foreigncopy);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 11:07:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 11:07:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387415.1628681 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNqx-0006gu-SU; Mon, 10 Aug 2026 11:07:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387415.1628681; Mon, 10 Aug 2026 11:07:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtNqx-0006gn-PG; Mon, 10 Aug 2026 11:07:35 +0000
Received: by outflank-mailman (input) for mailman id 1387415;
 Mon, 10 Aug 2026 11:07:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wtNqw-0006ft-0N
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 11:07:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtNqs-0034BO-OA
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:07:30 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a79b0e7-2eae-0a2a0a5409dd-0a2a4509d582-26
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:07:30 +0200
Received: from [40.107.130.48]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a79b0f1-be1a-0a2a45090019-286b823060bf-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:07:29 +0200
Received: from DU6P191CA0014.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:540::15)
 by AM0PR08MB5473.eurprd08.prod.outlook.com (2603:10a6:208:180::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 11:07:23 +0000
Received: from DB1PEPF0003922F.eurprd03.prod.outlook.com
 (2603:10a6:10:540:cafe::48) by DU6P191CA0014.outlook.office365.com
 (2603:10a6:10:540::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Mon,
 10 Aug 2026 11:07:23 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF0003922F.mail.protection.outlook.com (10.167.8.102) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.8
 via Frontend Transport; Mon, 10 Aug 2026 11:07:22 +0000
Received: from AM6PR08MB3414.eurprd08.prod.outlook.com (2603:10a6:20b:49::10)
 by VI0PR08MB10485.eurprd08.prod.outlook.com (2603:10a6:800:1b9::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 11:06:41 +0000
Received: from AM6PR08MB3414.eurprd08.prod.outlook.com
 ([fe80::dde8:bf0b:1dc:2a2]) by AM6PR08MB3414.eurprd08.prod.outlook.com
 ([fe80::dde8:bf0b:1dc:2a2%2]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 11:06:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=NpfveSg/8h0SZbLFOQkd9a23PTo9LDt9y+bWfMh9J2+KQ80xwXGIx2B+WmDxkOTlFdPMn9r3AUQrASz7wbWOVso69P75Ftpp2ZuW0uadEWi3ULKuuNCXT3UDo/MlPmBHD6+nR7vThRvrHpmX+XfcH+okPBXjn2EiHm3DLtJnSfZL2kRK5ebWvkwJi6y0+oXilnoS04k+uqH5AqQkrBGxKTXh1lN22oU0gb8TQWEFHM6utJA105mYrmHpMHos1igY/vRJWkOSMz7+fibMeeAWrhjRc178ZFOCB5MVEONnWquzfdhZi8u9jPDAQg+YggpyzOJUC0oGgLg509lWVZrHZw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BnQqdXX1ZyOUKKU4li9Bc+RBJzrUk6RyawcfqsSj/Eo=;
 b=G+FkAECJjVw0S0GHsHYBzilgEhx+mh3nMjHEmm3/QIsdHJuFaqOpe7EWTpH/cIUsAcDUJe5YGHTq9H0Mv6vxDe4cUXZ/lxFnlfuCyYwf14o1x20iWGXYw8co5Qtoa7sTdmQfm+dg0efhWdP8B/tltGRDVog1K04qF7Ba2EewOo/Oqezxs9Jss462e6DuhRO1JjRFbNeISoIdqmM6wO8n/tWoMivh28F7lDgxxSGQfgLXNBPImvDgGR/zOB3tPl2CRDbR8juQv3PiO0bH0xi4lMtTwizYvC6VGayanrxr+pVY+Y8Dz2UgpZOnoQeDPdv1LMgmNGjqO+C9rdorbSqtIQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linux.ibm.com smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BnQqdXX1ZyOUKKU4li9Bc+RBJzrUk6RyawcfqsSj/Eo=;
 b=kPqHrKjbFDa0OLbzp0kgLoxHv44vUa1iZaGhbeDApeXGB9si5HckD9jCUzXFUvjwQ6ya/WFbbblYxXJlQHpxAODd9pB0y6zyz/xt54rLMTBPk10MHoPyHEicMGmUNuP6ZNCcHkdYwPp2GXqM5wrurn9J2iWj+66UzgYkF/HfI7U=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ziuome5/djtyBQzLEzz0klmAysoiBI5ZAwdG5vnb3nMr09jdV9VGv97x/PZogNuexDHgr5Xo5nw3XjHMCCjfiOoa3inGpsNMEfFzlW8yKZg8LiwfBlpVURriB1zGsB2mAyZBoQUt4prjIke7q/FWySr+Ygo8QBVmuE6d+O/0OjpAKTIxOIjcOkraqFpDsBHE4rCU647hc4e0D6FVP0Kv4noUVajpvIWXLH9litFTkeZXuLKIJYC12llbrMGJ4d2Dt8a8LFKPaUChAGM6/FefuJTy4GvU/zRGIvq3uWLhj4xlGe29JKudC2FebNsOezbu0guaNOMNCGQI/DuWebZESA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BnQqdXX1ZyOUKKU4li9Bc+RBJzrUk6RyawcfqsSj/Eo=;
 b=GdzwAUCegwRfCxVii+ZLGkAHtO3xXp4tzYPyF0iDSnfrKkoUNGEAMGhyDAQb39r1zcUcsMnxah9Xs/c0/bOPAN64IsYrxlHANrH0uiSvjthio3zxLLdIAClSLHTCk/a2+wLIy/0MPUkjKdt2o8mrBSwHvXehtjU2VwCbcamMxE5XsWs9w1H5IV6kNrcPdqkbq5Q6QOTzInJZbqCCym37I5EOnc2q7D/bPp1USuGxXPCX3As3bQ2IIjG6tgAGC81jJJmeoYrKOCrspJs2VC20PJ0vlwKKSWXEZu3j4/LNx5lQiLcRbzue4l6uOentjCiBOvApUlYxv4u6XBCNs2j9Kg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BnQqdXX1ZyOUKKU4li9Bc+RBJzrUk6RyawcfqsSj/Eo=;
 b=kPqHrKjbFDa0OLbzp0kgLoxHv44vUa1iZaGhbeDApeXGB9si5HckD9jCUzXFUvjwQ6ya/WFbbblYxXJlQHpxAODd9pB0y6zyz/xt54rLMTBPk10MHoPyHEicMGmUNuP6ZNCcHkdYwPp2GXqM5wrurn9J2iWj+66UzgYkF/HfI7U=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <f0b0dacb-fb83-4402-b0ea-30072727dfd7@arm.com>
Date: Mon, 10 Aug 2026 12:06:39 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 6/9] mm: convert PTE table entry to pte
To: Alexander Gordeev <agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-7-usama.anjum@arm.com>
 <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
 <5c329236-7761-4e42-a549-b822e43b4358@arm.com>
 <2599c5b3-e8ac-4865-993b-d41e6f060d52-agordeev@linux.ibm.com>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <2599c5b3-e8ac-4865-993b-d41e6f060d52-agordeev@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0240.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a7::11) To AM6PR08MB3414.eurprd08.prod.outlook.com
 (2603:10a6:20b:49::10)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	AM6PR08MB3414:EE_|VI0PR08MB10485:EE_|DB1PEPF0003922F:EE_|AM0PR08MB5473:EE_
X-MS-Office365-Filtering-Correlation-Id: a953ce51-28e1-48aa-165f-08def6cf8d94
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|366016|6133799003|10067099003|4143699003|56012099006|11063799006|22082099003|18002099003|3023799007;
X-Microsoft-Antispam-Message-Info-Original:
 lQ0hyfxi02b4F9VwRxN8Znn5OAewgjlyPjRZcVcEUaWc/2czU2/V4NIVgJiRy5t4QbhGiEJ0KwtaSe7jPvxwE+NAtXM/byDqA7dfUzahbycT7I25PzR5jhkw4frdVt9oxMHTuT5akKF8RzZ33dyxm3YumgOMNPXleL3/6dgR5gVsXlm7rW/4NEmneY9iocIiXc9AJnfTRej+kH5hV/eFNjczN84h/tHRt+GWHZjzpSAoJPL9JYvhN2uJY/S+VrzqF+CWj+0w5yWDWDTqJ2PBgzAAUUUZs2kukSyhTiklg5Og1PLgZuW6iLLN9l3sFHSU2tcSI9gz7kEmj/CGBr9gAEUkaYQ39JJiiB4jvVQCheZ+7eOV/F/NBXKAzFVSt5gbfbkSknaem3qoa0pI/BVUw5qogKsLivyhv9KJhur+AwUg3Hgnw5miP0aiKhBTfaPE0nfqcrLZgmGWMPvil7+FlI8U60XhaDqEly8cC0jIpSQvVcvtGMEalbBtDiQFFCEDkDZUFQgjRdmfVg8KexBPyscLIZeZnbQZrbdecvE8TcK0E/1c/PBQ2CN+jz7B3aX/bKPp9LZqOK57affgO+aFBh9J1aTXDH4Sj/DOUdJRckS46M4BPeWnU89+1GK6l1c08XjUtoEwa9L+S8w73BiSAlNMsrmS1vmLGiUwtdwZAdU=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3414.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(1800799024)(366016)(6133799003)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 cPVi6hN5aavRhhAswfgv28wAXtZ6qeLTlP8q/AgWsrYcs7+vK+svJwSvC9NxV7RCHctlS0aIjO7/jx28wsEyjQwzfPGHOGPv1O1cSupSolWeBAX4rw+U98JrzgQTU06aoDW97oqwj+5onDZpDRYSBHwBov2+hRwPNJzrr2UbtXUdSOHd+PD4+E88nTrZSLjZV/sS2M1LGA2uVyfjDBfSo+DAoVyrKGPcprIh6Cee/RdcDdxZjE1/fY7YTLbnfllaV7GL+zNTiE62tYtPGYGbhMmEk7fG0EHHuqShM2REU2EwVZP0Wify25HFm73akjgX+cx6WziW0ou0CWTB9iKpKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10485
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF0003922F.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	ca79a833-59da-449f-a5ec-08def6cf7495
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|14060799003|35042699022|1800799024|23010399003|82310400026|36860700016|6133799003|56012099006|10067099003|11063799006|4143699003|3023799007|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	aB9doTRqRN7kd9TfOrTQxmun2zbzD4oTTuD1y4OqC14UyKyJNSMCGw36kf1xi38PqJ9Rtp0jlNKym4r2OvGN7Mdrix8L0sWVy1R3t6kLJaHIHqtZQGtm9crMkpQLwvqLi2JgPsgruMFGtOnAnNv3RQ3jd0sHJDccJkUb6R1CgSG5NjxGfKwCzdTVzH0f7NMXHC32MDDQrfjyaYntV5Z6MTlqnp74aBu1/Vfz2aUWF1CyaM76flGKf/iR3DBVz4zXlZ8gFMj5t7TWKAJYlfH2RHQyl1+ejF9TEC0M1d3EUUSKNIcAXS2+B6uwgaDjBF9YYZPsBe3x+8jsnEctfOzx5+LgWISUO8YhGuEFvPM/zwSeQ/ZhMN9x2dHjXnduF7LZAfeeCdXdli081Iv3yl6OxpFpBdzWQzTDA8t3zPUqrfsxQqi4pJn9BIAcFetfFrc1SZhlCQIvXZF5riUG97QLoOgJ5jTFlh2d6z5sTdXhjEujrl1WgCaQb26YYn0WAFkV5x7f+IKzUmVPkdVDWwLvrqlJA5wR2gYDNc+HKbuzIcI1SMN0BthkYebkD7uyDh23PB+OSWYO5+W8R7TMXcL4WzHNl8Ib05dzPcPnUmL6C1ZLD8qMzrvGTZ2v73Td3vbzSktxFDUeAgTLYg7gm00imt20iVjJbxchyo81jYXSiun4qm4IeZsyVNCM67/xrcFUHwajnV6IM3mpC+M3quGFmg==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(14060799003)(35042699022)(1800799024)(23010399003)(82310400026)(36860700016)(6133799003)(56012099006)(10067099003)(11063799006)(4143699003)(3023799007)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	BtLaHivFG2MjBv8/s8qRcGiJDKiPENYB+2PYjmVYu+THljKaOqxVe40MzKEcSJKsZWVaiKFtOKgq9S7joX+TrjW4CONkg8omF1hSH5KQcXcggLJulUwFxWbo+WyIVRRnie8RGxdM8oI9wId9eGQEVsIa2lyk7lpRNcmJSduk+6bTsON6zLC1kFnHFKOPdQWuDJ+5gvPtkQH4gI0OcploDbbXUEAvdfQjGSf1ocLCBOu97QcYTPG0/hDWOR8EDViud7W10iQ+bgqduvXMyNwOhAmdDEZ01OiYXqqsUfO2i2bLso0Pv0p/qqXtnpvfSJ2dA7uAlOKWN9wQfclNiV893SiPpDWiKNOkuyLlnRCSZuEXEGiiQknPj+wo2iq8eG6Smx9xZv6RYcEamsBsfgmbep0Y20LINnYyBgOzRLzRtRNvmy3fgDmgtJD0KNuUHASX
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 11:07:22.6360
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a953ce51-28e1-48aa-165f-08def6cf8d94
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB1PEPF0003922F.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5473
X-purgate-ID: tlsNG-bad1c0/1786360050-BFCD7034-43D8616F/0/0
X-purgate-type: clean
X-purgate-size: 3835

On 10/08/2026 7:44 am, Alexander Gordeev wrote:
> On Fri, Aug 07, 2026 at 05:26:04PM +0100, Muhammad Usama Anjum wrote:
>> On 07/08/2026 7:58 am, Alexander Gordeev wrote:
>>> On Thu, Aug 06, 2026 at 09:38:44AM +0100, Muhammad Usama Anjum wrote:
>>>> The non-MMU stub receives hw_pte_t but returns a logical pte_t
>>>> value. Convert the stored entry through __pte_from_hw() before
>>>> returning.
>>>>
>>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
>>>> ---
>>>>  include/linux/hugetlb.h | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>>>> index bc0b9c65aa1d0..9e8b391aa4bc9 100644
>>>> --- a/include/linux/hugetlb.h
>>>> +++ b/include/linux/hugetlb.h
>>>> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>>>>  #ifdef CONFIG_MMU
>>>>  	return ptep_get(ptep);
>>>>  #else
>>>> -	return *ptep;
>>>> +	return __pte_from_hw(*ptep);
>>>
>>> But this is a direct dereferencing, which breaks the whole point, isn't it?
>> Yes, this is particular line is for non MMU. In this case, CONIFG_ARCH_HAS_HW_PTE
>> would never be defined. Hence hw_pte_t is just pte_t and direct dereference is
>> allowed. I'd thought a lot about it; is better to leave direct dereference here
>> or use some helper. Then used __pte_from_hw() was already being used in generic
>> ptep_get().
> 
> But in case CONIFG_ARCH_HAS_HW_PTE=n __pte_from_hw() is still gets called.
> That looks inconsistent to me. Why not just call ptep_deref() (see below)?

Agreed. Calling __pte_from_hw() directly exposes the representation
conversion at the call site. I will introduce ptep_deref() and use it
here.

> 
>> There are only two users of __pte_from_hw() at this time. 
>>
>>>
>>> What about introducing something like pte_t ptep_get_sw(hw_pte_t *ptep)
>>> to be used in exactly situations like this? With that the semantics of
>>> hw_pte_t pointers becomes straightforward and closes the still ongoing
>>> "storage vs lifetime" discussion:
>>>
>>> hw_pte_t*     points to HW-formatted page table entries
>>>
>>> ptep_get()    is used to obtain HW-linked/attached entries, and may wire
>>>               extra code like [1] or [2]
>>>
>>> ptep_get_sw() is used to obtain HW-unlinked/unattached entries and in
>>>               most cases is just a direct dereference
>> ptep_get_sw() or ptep_get_deref() is better name here?
> 
> ptep_deref() would be it.
> 
> Do you agree to the suggested API requirements?

Yes. hw_pte_t * identifies storage containing hardware-formatted PTEs,
regardless of whether it is attached. ptep_get() is used for attached
entries and may provide additional architecture-specific handling.
ptep_deref() is used for unattached entries and performs only the raw
storage-to-value conversion.

For review, this patch would become:

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index bc0b9c65aa1d0..ce900d2652d91 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
 #ifdef CONFIG_MMU
 	return ptep_get(ptep);
 #else
-	return *ptep;
+	return ptep_deref(ptep);
 #endif
 }
 
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 1768421755a9c..08613593f3320 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -490,6 +490,13 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma,
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 #endif
 
+#ifndef ptep_deref
+static inline pte_t ptep_deref(hw_pte_t *ptep)
+{
+	return __pte_from_hw(*ptep);
+}
+#endif
+
 #ifndef ptep_get
 static inline pte_t ptep_get(hw_pte_t *ptep)
 {

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 11:20:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 11:20:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387424.1628691 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtO3L-0001L0-1f; Mon, 10 Aug 2026 11:20:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387424.1628691; Mon, 10 Aug 2026 11:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtO3K-0001Kt-UI; Mon, 10 Aug 2026 11:20:22 +0000
Received: by outflank-mailman (input) for mailman id 1387424;
 Mon, 10 Aug 2026 11:20:21 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <david@kernel.org>) id 1wtO3J-0001Kn-0z
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 11:20:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtO3H-00H3rN-Nc
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:20:19 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <david@kernel.org>)
 id 6a79b3f1-e002-0a2a0a5209dd-0a2a4504b020-12
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:20:19 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <david@kernel.org>)
 id 6a79b3f1-b57f-0a2a45040019-aceafc1fd3a6-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:20:19 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id C481943CFA;
 Mon, 10 Aug 2026 11:20:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E03C31F000E9;
 Mon, 10 Aug 2026 11:20:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786360816;
	bh=TulNsLyt4vpxh4RnOYY8l7zFcFvhf8Jk6fhq8antiP0=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To;
	b=ORpkNGg2BSqzSD3++4ACU0dyFe22rkPiIMoU4R5mPSk3EtaJZnBfm9B7KMXy3Cpn9
	 EBzrW+XdYiOLcXC12dWCfufaWEf7uVo5F5Q6l7B+x/SQi1hrzOx4P+TYRuRH2K86BY
	 EfLvOXfLrutZagBlSPjyDUJkCKXGlFDn/fYq15/QO3Le0ZwBaPaPuveYBVCq+WTVCt
	 s/E5qciIPs+zNCp4IRtoqZMK6oa1m3Sf8hMh6hsAiXBqO/D1CFH8Tu73oGhIbOK+dX
	 wYEgqUXRoWzuwdYwzU5h1IrGCcweUrkLEbvSZcd0YLdh/1LHqiZFAtpgbOXTQGITRC
	 MZDRGV6O/Lpbw==
Message-ID: <b40d4359-3156-4d02-9662-73bfeace607c@kernel.org>
Date: Mon, 10 Aug 2026 13:20:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
To: Muhammad Usama Anjum <usama.anjum@arm.com>,
 Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-2-usama.anjum@arm.com>
 <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
 <eef14e97-20cd-4b08-ae22-7636af049b09@arm.com>
 <4a42c498-58ca-46f4-819f-da14cfba154f-agordeev@linux.ibm.com>
 <52b5066c-64f6-40bb-9bce-365a18f24265@arm.com>
From: "David Hildenbrand (Arm)" <david@kernel.org>
Content-Language: en-US
Autocrypt: addr=david@kernel.org; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk
 ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik
 AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN
 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD
 g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz
 ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x
 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7
 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4
 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ
 DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R
 HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC
 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7
 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <52b5066c-64f6-40bb-9bce-365a18f24265@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786360819-C3EC6B50-2CA773C0/0/0
X-purgate-type: clean
X-purgate-size: 1123

On 8/10/26 12:09, Muhammad Usama Anjum wrote:
> On 09/08/2026 6:45 pm, Alexander Gordeev wrote:
>> On Fri, Aug 07, 2026 at 04:24:00PM +0100, Muhammad Usama Anjum wrote:
>>> Thank you for testing it out on s390.
>>>
>>> As __hw_pte_t isn't being used yet in this series, would s390 enablement
>>> patches add __hw_pte_t to this definition?
>>
>> I hope there is a better solution. As I noted m68k, powerpc and sparc
>> may also be affected, so I would suggest to look into those as well.
>> I would prefer s390 to use the generic one rather than circumvent a
>> compile error in a custom way.
> I've just checked all of these architectures by doing dirty conversion and
> reached to same conclusion that __hw_pte_t must be defined like:
>  
> typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
> 
> I'lll add __hw_pte_t to this series. (Initially on last email I'd thought
> that the first user would add __hw_pte_t. But it seems sensible to add it
> now)

Yes, do it as part of the introduction. Also a good idea to mention in the patch
description *why* that is required.

-- 
Cheers,

David


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 11:50:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 11:50:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387433.1628699 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtOWP-0005mS-8L; Mon, 10 Aug 2026 11:50:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387433.1628699; Mon, 10 Aug 2026 11:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtOWP-0005mL-4w; Mon, 10 Aug 2026 11:50:25 +0000
Received: by outflank-mailman (input) for mailman id 1387433;
 Mon, 10 Aug 2026 11:50:23 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtOWN-0005mF-3y
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 11:50:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtOWM-00Azn7-3N
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:50:22 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79baea-2eae-0a2a0a5409dd-0a2a4507bcd6-46
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:50:22 +0200
Received: from [209.85.218.44] (helo=mail-ej1-f44.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79bafd-b4ea-0a2a45070019-d155da2cd88f-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:50:22 +0200
Received: by mail-ej1-f44.google.com with SMTP id
 a640c23a62f3a-c197e7e4e94so283959966b.2
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 04:50:22 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a1e7d48ce7sm4332394a12.16.2026.08.10.04.50.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2026 04:50:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786362621; x=1786967421; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=q4mNRdlCUxidZFH38/qGNOT5l90EeTySOEWFVi0lnRs=;
        b=fog+lRMEWPtM2qAq/ABYxRkIgCV9Zy5H43B7xo3OVWp1FfRORmSgqzahdov4+zrM+w
         rUkRWvDX3pWhAaTYzMikoxCP9t+K0LV5213vzPMbK93mi8/keVhAgH7LvEnYsIlZnd5A
         JLxWGlYP/3gYU4x9eDBdtKQfFvP7bDzx8NE9OI0VTABWTUkCWbz8YFhcGmwnLY/zJDRk
         iaKg6/IqWapiEgZUqRSrVkmZqKvJ63JKqGx4JbKN1YWuX/lGNN8qeavbwYeThNoktmLj
         yzZAOFACZDB7nr57kyyU82a1krUWA5J7zZUa8+MnTnDhh7XbcpvQpdpvg2JMHnct79Md
         y2uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786362621; x=1786967421;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=q4mNRdlCUxidZFH38/qGNOT5l90EeTySOEWFVi0lnRs=;
        b=dy5OOmn9zxEyoDURr12b96UkHpFavg5lsRK9K3Pk2TuVcW9IIRei3wGCzJjEHFGb4p
         JAvyNfrsfv9CvC0MmZaKz7DdE0tigvptwqsUgUWv9sQoT27S9dEW8akiiL8HJIIrQ3yN
         9offDw5PEIO/kplN5OrJp/S2xYoVVB+nohJOYtPuFvARl/e1P0m2I5rb5TSDWPRPzN05
         tLzbVog+NLf3873gRDYDp8jpB3s/MSefZeyWgsq4gbszVbhDOJeqDLzkK5XIJ2t5oOUw
         jeo3xOoZqd5Ty229XCi2+9de8n5O2b4M3R46/8fplfDl33QC8hESc2LtqJLUZs0jfHaL
         3+Pg==
X-Gm-Message-State: AOJu0YxsY3MjWBIgdbsgyWtlC2RFnwGw4wt1D86wZJtao5864M61K3h2
	8VPXwzB7EUHG9ixzEVDM+pXOd30P+ykDGoLFeBkuo1KVT5uMVC8gJiJD
X-Gm-Gg: AR+sD13sSoYaDHXWgdiQko7kG1Clnh8Y/5scr8QDbWl+KTFulDGMykbGo9q9JXuLlXB
	wK053kPnF/mFJHtYKkHeEoxBRYLXuFknvlnyB6MyN0D08JcQ7colUcGsnZxQGy9zrf3F9BU2IuU
	9waQ3+u/l1ClH8pmJHOCGlN7tkbtCq7v3NgsDcE9TEnGTiye/FrgbwE/bh7JDkF4D2NF3Z9J0NT
	DrHrVSqwiWj2PzOv892lUX70b7A1xb+H7TLHhaL9SQYbZFwB4p4tjhVwj4XvN6vrirT1OSqq33U
	SVvffumzebp5RhsCAqRP3n8zh/CbpTaktESMDTdCvuXhMgQTwtPzhOUEd80ffE6Ov0wuwDI16wb
	TRjfEVFLf8Hyhke4QaUwa3zFKrDhfkh1zntlw0Sf6jaJJjGqB+RBs84vdUxo83oSH7zErIykArH
	gXqie6fHpTy3cy4w18PJi/Wa4/bWO+Ol4KIo8AHCiMwy+yaRYyokuxCwBmf1qr02GxqUxapGqHV
	8yUA9KPyUMpbfr67ZVCucVJMrE+OaFeUV8iZYLXHzo=
X-Received: by 2002:a17:906:4786:b0:c20:af9d:454a with SMTP id a640c23a62f3a-c20af9d54a7mr449512766b.16.1786362621434;
        Mon, 10 Aug 2026 04:50:21 -0700 (PDT)
Message-ID: <1282e93e-df55-4d22-9327-8454ef181588@gmail.com>
Date: Mon, 10 Aug 2026 13:50:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/common: add keyhandler to show Xen command
 line
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org,
 Stefano Stabellini <sstabellini@kernel.org>
References: <20260803070047.3097846-1-dmukhin@ford.com>
 <20260803070047.3097846-3-dmukhin@ford.com>
 <df43b4f0-9973-b80e-47a9-f0cfa65651aa@kernel.org> <anaWpO/zu5sI4A9u@kraken>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <anaWpO/zu5sI4A9u@kraken>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786362622-A4CCFAE4-6DBD73C8/10/73395122804
X-purgate-type: spam
X-purgate-size: 2351



On 8/8/26 4:38 AM, dmukhin@ford.com wrote:
> On Fri, Aug 07, 2026 at 05:44:41PM -0700, Stefano Stabellini wrote:
>> On Mon, 3 Aug 2026, dmukhin@ford.com wrote:
>>> From: Denis Mukhin <dmukhin@ford.com>
>>>
>>> Currently there's no way to print Xen command line on the emergency
>>> console for debugging purposes (e.g. 'xl' is not available in dom0).
>>>
>>> Add new keyhander 'X' to do command line printout.
>>>
>>> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>>> ---
>>> v1: https://lore.kernel.org/xen-devel/20260730061459.2702672-2-dmukhin@ford.com/
>>>
>>> Changes since v1:
>>> - moved implementation into kernel.c
>>> ---
>>>   xen/common/kernel.c | 16 ++++++++++++++++
>>>   1 file changed, 16 insertions(+)
>>>
>>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>>> index d1bef9ac2b2b..9f334c92e3ab 100644
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -5,6 +5,7 @@
>>>    */
>>>   
>>>   #include <xen/init.h>
>>> +#include <xen/keyhandler.h>
>>>   #include <xen/lib.h>
>>>   #include <xen/errno.h>
>>>   #include <xen/param.h>
>>> @@ -505,6 +506,21 @@ static int __init cf_check param_init(void)
>>>   __initcall(param_init);
>>>   #endif
>>>   
>>> +static void cf_check show_hypervisor_info(unsigned char key)
>>> +{
>>> +    printk("'%c' pressed -> showing hypervisor information\n", key);
>>> +    printk("Command line: %s\n", saved_cmdline);
>>
>> if CONFIG_CMDLINE_OVERRIDE is defined, saved_cmdline is empty. We could
>> at least do this:
>>
>> #ifdef CONFIG_CMDLINE_OVERRIDE
>>      printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");
>> #else
>>      printk("Command line: %s\n", saved_cmdline);
>> #endif
> 
> Actually, CONFIG_CMDLINE can set the built-in command line which can be
> non-empty.
> 
> Perhaps, something like this:
> 
>      printk("Command line (built-in): %s\n", opt_builtin_cmdline);
> #ifndef CONFIG_CMDLINE_OVERRIDE
>      printk("Command line: %s\n", saved_cmdline);
> #endif
> 
> What do you think?

Considering that opt_builtin_cmdline is declared as __initconst won't it 
be an issue to print it in non-init function (show_hypervisor_info())? 
In other words, I expected that __init section should be freed at some 
point and I expect that it should be data abort here.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:06:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:06:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387454.1628707 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtPhL-0007QS-Gz; Mon, 10 Aug 2026 13:05:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387454.1628707; Mon, 10 Aug 2026 13:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtPhL-0007QL-EH; Mon, 10 Aug 2026 13:05:47 +0000
Received: by outflank-mailman (input) for mailman id 1387454;
 Mon, 10 Aug 2026 13:05:46 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wtPhK-0007QF-JN
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:05:46 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wtPhF-00Eilq-0J;
 Mon, 10 Aug 2026 13:05:40 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wtPhE-00EO51-1g;
 Mon, 10 Aug 2026 13:05:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=luRJpyLb9INx6Asvxsh+vF1/7s+qu9Bs4HzlyKTfIh4=; b=Ak7BNB85M51zQGSTv+WNSiZG0Q
	22l8cSRSdtkpE50IPsNtIxAZ69Dilkk4GDVjO2tAAHsX8DcuKgRzKrv1qfdbqIuwieabqkpgEc1n5
	NAIDngqZHwgnltLL5U0hB3+j6iRYN8eE3GVdafVdXRz63cAdSonuu/AcZqgdAyGd4cGU=;
Date: Mon, 10 Aug 2026 15:05:34 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org
Subject: Re: [PATCH v4 1/2] xen/console: correct leaky-bucket rate limiter
Message-ID: <annMnrWtyC0OSwi6@Mac.lan>
References: <20260729072520.1556970-1-dmukhin@ford.com>
 <20260729072520.1556970-2-dmukhin@ford.com>
 <annJ3WK35xsv56Xn@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <annJ3WK35xsv56Xn@macbook.local>

You mention "correct" in the subject, but there's no fixes tag, and
it's not clear exactly what this patch corrects.

On Wed, Jul 29, 2026 at 12:25:19AM -0700, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Use existing 'ratelimit_ms' and 'ratelimit_burst' variables in
> do_printk_ratelimit() instead of hardcoded values 5000 and 10 respectively.
> 
> Ensure rate limiter is disabled if either 'ratelimit_ms' or 'ratelimit_burst'
> is 0.
> 
> Account for integer overflow in the rate-limiter logic.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - fixed types
> - fixed integer division logic - I used DIM_MUL2() from xvmalloc.h
>   I hope this is fine given another pending patch which will include xvmalloc.h
>   for heap allocations
> - fixed potential problem w/ overflow of toks (introduced elapsed)
> - fixed potential problem with toks == 0 which is also "uninitialized"
>   state.
> ---
>  xen/drivers/char/console.c | 37 ++++++++++++++++++++++++++++++-------
>  1 file changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index ea4e3ff34178..76a1681670c1 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,6 +33,7 @@
>  #include <asm/setup.h>
>  #include <xen/sections.h>
>  #include <xen/consoled.h>
> +#include <xen/xvmalloc.h>
>  
>  #ifdef CONFIG_X86
>  #include <asm/guest.h>
> @@ -1286,21 +1287,43 @@ bool __printk_ratelimit(unsigned int ratelimit_ms,
>                          unsigned int ratelimit_burst)
>  {
>      static DEFINE_SPINLOCK(ratelimit_lock);
> -    static unsigned long toks = 10 * 5 * 1000;
> +    static unsigned long toks;
>      static unsigned long last_msg;
>      static unsigned int missed;
> +    static bool initialized;
> +    unsigned long limit;
>      unsigned long flags;
> -    unsigned long long now = NOW(); /* ns */
>      unsigned long ms;
> +    s_time_t now;
>  
> -    do_div(now, 1000000);
> -    ms = (unsigned long)now;
> +    if ( !ratelimit_ms || !ratelimit_burst )
> +        return true;
> +
> +    limit = DIM_MUL2(ratelimit_burst, ratelimit_ms);
> +
> +    now = NOW(); /* ns */
> +    do_div(now, MILLISECS(1));
> +    ms = now;
>  
>      spin_lock_irqsave(&ratelimit_lock, flags);
> -    toks += ms - last_msg;
> +
> +    if ( initialized )
> +    {
> +        unsigned long elapsed = ms - last_msg;
> +
> +        if ( toks >= limit || elapsed >= limit - toks )
> +            toks = limit;
> +        else
> +            toks += elapsed;
> +    }
> +    else
> +    {
> +        toks = limit;
> +        initialized = true;
> +    }

I'm not sure you need the `initialized` static variable.  You could
set the initial value of toks = ~0, and then if the limit is set to a
lower value it would already get adjusted as part of the toks >= limit
check?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:06:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:06:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387461.1628717 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtPiD-0007ro-QA; Mon, 10 Aug 2026 13:06:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387461.1628717; Mon, 10 Aug 2026 13:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtPiD-0007rg-Mb; Mon, 10 Aug 2026 13:06:41 +0000
Received: by outflank-mailman (input) for mailman id 1387461;
 Mon, 10 Aug 2026 13:06:41 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wtPiD-0007rS-2u
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:06:41 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wtPiC-00Eima-1A;
 Mon, 10 Aug 2026 13:06:40 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wtPiB-00EPaK-2b;
 Mon, 10 Aug 2026 13:06:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=i4Ix+U9e9KBV/c/msUl5WKDJGozI83ZXi5f8mrs4zgM=; b=sv93cXzy6g7FwRkbsdP1K1OHjC
	wjvE6+E5n5+vJMz0GQQQ7n9/HnA5vh3xh03Zox94MZVLg7hMyEuMXmg9gEY7KizF0ToKnqXgrr/3g
	0ARLvunHlGM7Y5SIdhH44MLTlRCLuKPI9ivchEymACicF2m/H8HAiaQ4aLRnOvtClycQ=;
Date: Mon, 10 Aug 2026 15:06:35 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org
Subject: Re: [PATCH v4 2/2] xen/console: add compile-time rate-limiting
 controls
Message-ID: <annM2322Ig23p4RG@Mac.lan>
References: <20260729072520.1556970-1-dmukhin@ford.com>
 <20260729072520.1556970-3-dmukhin@ford.com>
 <annMNjOodiS3hHp7@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <annMNjOodiS3hHp7@macbook.local>

On Wed, Jul 29, 2026 at 12:25:20AM -0700, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Introduce CONFIG_PRINTK_RATELIMIT_MS and CONFIG_PRINTK_RATELIMIT_BURST
> for configuring rate-limiting policy at the compile time.
> 
> Use symbols for global rate-limiting initialization in the console driver.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - added note on security support for non-standard configurations
> - gated menu with EXPERT
> 
> I kept both settings for now.
> ---
>  xen/common/Kconfig         | 36 ++++++++++++++++++++++++++++++++++++
>  xen/drivers/char/console.c |  6 ++++--
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index da80fdba8469..749d3bfb08e0 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -672,4 +672,40 @@ config PM_STATS
>  	  Enable collection of performance management statistics to aid in
>  	  analyzing and tuning power/performance characteristics of the system
>  
> +menu "Console rate-limiting"
> +	visible if EXPERT

No strong opinion, but there's a drivers/char/Kconfig which might be a
more natural place for those option to live, and then there's no
reason for the extra menu?

> +
> +config PRINTK_RATELIMIT_MS
> +	int "printk rate-limiting time window (milliseconds)"
> +	default 5000
> +	help
> +	  Specifies the time window, in milliseconds, for rate-limited [*] printk
> +	  messages. No more than `CONFIG_PRINTK_RATELIMIT_BURST` messages will be
> +	  printed within this window.
> +
> +	  Setting this value to 0 disables rate-limiting entirely.
> +
> +	  Configurations using a value other than the default of 5000 are not
> +	  security supported.
> +
> +	  [*] Rate-limited messages are those controlled by the `loglvl` and
> +	  `guest_loglvl` command-line parameters.
> +
> +config PRINTK_RATELIMIT_BURST
> +	int "printk rate-limited message burst size"
> +	default 10
> +	help
> +	  Defines the maximum number of rate-limited [*] printk messages that may
> +	  be printed within each `CONFIG_PRINTK_RATELIMIT_MS` time window.
> +
> +	  Setting this value to 0 disables rate-limiting entirely.
> +
> +	  Configurations using a value other than the default of 10 are not
> +	  security supported.
> +
> +	  [*] Rate-limited messages are those controlled by the `loglvl` and
> +	  `guest_loglvl` command-line parameters.

Is it common to use footnotes in Kconfig options?  It seems a bit
weird to me, I would probably just expand inside parenthesis if
needed.

Also, I'm a bit confused by the mention of loglvl and guest_loglvl
explicitly here: messages outside of the selected level are just
discarded, and hence it's kind of obvious that just messages inside
the selected level are controlled by this rate-limiting.


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:28:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:28:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387470.1628727 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQ3M-0003K6-Dy; Mon, 10 Aug 2026 13:28:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387470.1628727; Mon, 10 Aug 2026 13:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQ3M-0003Jz-AH; Mon, 10 Aug 2026 13:28:32 +0000
Received: by outflank-mailman (input) for mailman id 1387470;
 Mon, 10 Aug 2026 13:28:31 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wtQ3L-0003Jt-3H
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:28:31 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wtQ3H-00EjD9-1v;
 Mon, 10 Aug 2026 13:28:27 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wtQ3G-00F0LR-3A;
 Mon, 10 Aug 2026 13:28:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=ORu4AAR8UbgfOu7JMv6ASKuKTn1N0oTYlJ6YRXD8Evk=; b=aVU9hUqACLE+XANhM8RiRhB8uq
	4FiNc71SfvbnSGv1+BeJAMk9qkwNhsQOwbh3gH31RnZYBRh1pgRWpPVQXiQNdwjPzaf7ZPStuWTzM
	MKfsjR+SsnNdDJHXoBI6EQ++6IZs4zSPPuL7WpPFevLwWpbLi3Ccqz8JxHHpkttJlewA=;
Date: Mon, 10 Aug 2026 15:28:21 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: dmukhin@ford.com
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com
Subject: Re: [PATCH v2 2/2] xen/common: add keyhandler to show Xen command
 line
Message-ID: <annR9YMHp1t8NVnP@macbook.local>
References: <20260803070047.3097846-1-dmukhin@ford.com>
 <20260803070047.3097846-3-dmukhin@ford.com>
 <df43b4f0-9973-b80e-47a9-f0cfa65651aa@kernel.org>
 <anaWpO/zu5sI4A9u@kraken>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <anaWpO/zu5sI4A9u@kraken>

On Fri, Aug 07, 2026 at 07:38:28PM -0700, dmukhin@ford.com wrote:
> On Fri, Aug 07, 2026 at 05:44:41PM -0700, Stefano Stabellini wrote:
> > On Mon, 3 Aug 2026, dmukhin@ford.com wrote:
> > > From: Denis Mukhin <dmukhin@ford.com> 
> > > 
> > > Currently there's no way to print Xen command line on the emergency
> > > console for debugging purposes (e.g. 'xl' is not available in dom0).
> > > 
> > > Add new keyhander 'X' to do command line printout.
> > > 
> > > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > > ---
> > > v1: https://lore.kernel.org/xen-devel/20260730061459.2702672-2-dmukhin@ford.com/
> > > 
> > > Changes since v1:
> > > - moved implementation into kernel.c
> > > ---
> > >  xen/common/kernel.c | 16 ++++++++++++++++
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> > > index d1bef9ac2b2b..9f334c92e3ab 100644
> > > --- a/xen/common/kernel.c
> > > +++ b/xen/common/kernel.c
> > > @@ -5,6 +5,7 @@
> > >   */
> > >  
> > >  #include <xen/init.h>
> > > +#include <xen/keyhandler.h>
> > >  #include <xen/lib.h>
> > >  #include <xen/errno.h>
> > >  #include <xen/param.h>
> > > @@ -505,6 +506,21 @@ static int __init cf_check param_init(void)
> > >  __initcall(param_init);
> > >  #endif
> > >  
> > > +static void cf_check show_hypervisor_info(unsigned char key)
> > > +{
> > > +    printk("'%c' pressed -> showing hypervisor information\n", key);
> > > +    printk("Command line: %s\n", saved_cmdline);
> > 
> > if CONFIG_CMDLINE_OVERRIDE is defined, saved_cmdline is empty. We could
> > at least do this:
> > 
> > #ifdef CONFIG_CMDLINE_OVERRIDE
> >     printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");
> > #else
> >     printk("Command line: %s\n", saved_cmdline);
> > #endif
> 
> Actually, CONFIG_CMDLINE can set the built-in command line which can be
> non-empty.
> 
> Perhaps, something like this:
> 
>     printk("Command line (built-in): %s\n", opt_builtin_cmdline);
> #ifndef CONFIG_CMDLINE_OVERRIDE
>     printk("Command line: %s\n", saved_cmdline);
> #endif

Aside from the remark from Oleksii, can you use IS_ENABLED() here
instead of preprocessor conditionals?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:32:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:32:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387477.1628735 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQ7K-00057L-T6; Mon, 10 Aug 2026 13:32:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387477.1628735; Mon, 10 Aug 2026 13:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQ7K-00057E-PV; Mon, 10 Aug 2026 13:32:38 +0000
Received: by outflank-mailman (input) for mailman id 1387477;
 Mon, 10 Aug 2026 13:32:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtQ7J-000578-MX
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:32:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQ7I-00EVma-Ts
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:32:36 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febdfec57000e099@swg.vates.tech>)
 id 6a79d2f4-8faa-0a2a0a5109dd-0a2a4505d9b0-2
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:32:36 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febdfec57000e099@swg.vates.tech>)
 id 6a79d2f0-4cb1-0a2a45050019-b9ff1c228ecb-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:32:32 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19febdfec57000e099.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 13:32:28 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id CF80880611;
 Mon, 10 Aug 2026 15:32:27 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=9T81Ju4UB2/Vn420Il4Co/BASrpk2PZLpayGASNpGIg=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=kj8htTYBNhWfrmZuOk9batNxqHmH+h5+0tz9w1zCqi6GzVsz+LUZ2YdGGuxYegBePuGBjgExC
 E99QuhJlS/H6qOMOipraT7H8pBOd4t/NUKfIGRueZYHSZG1J1TpKwC75Mjy8jsvKanOrMXHpeXz
 FlDz06wARapPp4zSWQnta5Bpwqhb+ij/1D7tX8ihBFpaWNjjqD5v3YsMgXNbteDu1AUbxodE6vk
 Ppn21jc8QGBNbB0tB1FFcrr+cvQAIcnzhYIcxwO/F4QC1yvPNxWknXk/xOvW9QO6qKJbLJNY77q
 g22mLpNpV01MyIG70k3kL54YM/5dbqRcuEiHzFiVYDYA==
X-Zone-Loop: a6eedb683102cb253a4f04589759be9d313423c8b3e7
x-campaign-type: default
x-transaction-id: 7e602ab6-55e8-4678-9ee2-11771dbc2b49
x-swg-uid: 01-ef17d2ef-e34c-4b43-8045-07519d2a2185
X-Mailer: Sweego
Message-ID:
 <1786368748.8631fc262581453bbf619ec5b2062170.19febdfec57000e099@vates.tech>
x-swg-bid: 1786368748.8631fc262581453bbf619ec5b2062170.19febdfec57000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Subject: Re: [PATCH v1 01/17] xen/riscv: manage IRQ_DISABLED flag in APLIC
 irq enable/disable callbacks
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <a6d85647d0d726ffb25708829813510421ed5234.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <a6d85647d0d726ffb25708829813510421ed5234.1784560663.git.oleksii.kurochko@gmail.com>
Date: Mon, 10 Aug 2026 15:32:21 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786368747; l=772;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=z02B9/tgz4LcVlE41Cj6lNYEwulnqWqQ/cFrEUrfPxI=;
 b=ocjRHBv4tBaTWtOhs11xzsQVxbm2E83P6NRd0rGksdzE+B3IXqDDd1nHNRk5T7A7kUc4bp9nJ
 gXCqLnMAk5yBbPSsLqWVTtVXkkprXt70UZFGw2KuHuZ6vwkkeWa/3QF
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2010.886a82330ba67ff7.19febdfea13.ce5d1f6ba744cb64=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786368748052
X-purgate-ID: tlsNG-c201ff/1786368752-F62AB2A1-828BBD7D/10/73395122804
X-purgate-type: spam
X-purgate-size: 1148

---=Part.2010.886a82330ba67ff7.19febdfea13.ce5d1f6ba744cb64=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, 20 Jul 2026 18:01:59 +0200, Oleksii Kurochko <oleksii=2Ekurochko@gm=
ail=2Ecom> wrote:
> desc->status is only set once during setup_irq(), but interrupts can be
> enabled/disabled at runtime, so update it in the corresponding callbacks=
=2E
>=20
> For the purposes of the FENCE instruction, CSR read accesses are
> classified as device input (I) and CSR write accesses as device output
> (O), while the barriers used by spin locks (fence rw,rw) only order
> normal memory accesses=2E An explicit wmb() (fence ow,ow) is therefore
> added in aplic_irq_{enable,disable}() to order the desc->status update
> with respect to the IMSIC CSR write=2E
>=20
> [=2E=2E=2E]

Reviewed-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>

--=20
Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>


-- 
Baptiste Le Duc | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.2010.886a82330ba67ff7.19febdfea13.ce5d1f6ba744cb64=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:32:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:32:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387478.1628744 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQ7O-0005L1-3T; Mon, 10 Aug 2026 13:32:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387478.1628744; Mon, 10 Aug 2026 13:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQ7N-0005Ku-W0; Mon, 10 Aug 2026 13:32:42 +0000
Received: by outflank-mailman (input) for mailman id 1387478;
 Mon, 10 Aug 2026 13:32:40 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtQ7M-0005Jj-Ff
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:32:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQ7L-003Xnu-CF
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:32:39 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099@swg.vates.tech>)
 id 6a79d2e5-e002-0a2a0a5209dd-0a2a450b9eba-46
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:32:39 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099@swg.vates.tech>)
 id 6a79d2f6-b7e8-0a2a450b0019-b9ff1c239bd9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:32:39 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19febdfed5f000e099.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 13:32:28 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 47F0E83637;
 Mon, 10 Aug 2026 15:32:28 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=B8XqmmZKLgCncAIlKFa+leieV2tUIHyhNz/C3/qNJGs=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=pZNYPkxfV70VJUsy+ECFCpciVklxEExPfYLKixHgVUjfeRUC/QKIz3ACOEwprpUx7GOYrlamD
 QdmhiKDvI8B07IPeVCrxXQkwaM0iaC3KX/6vTbFaC+0AJxXSTZa+I1ONeiq1IqchO2q/Y+rTF+s
 o6vs5A2jac+2RGZm/8hNsc/+DXCPxoYd05taZSloj4NI8Sx1rDWSQfWmUpRFIx7yhnVexVH4+IE
 /wpMFZ5UiClhr2B6/XeQrKmMPE5SB13JOA7Kp9EAhdcuSP5pKty++1shRekW63n4hdbeCt9GARQ
 QJzlYHdNikGORlS5ayOVqO6PIcMl48v2QstXzKM5fq9g==
X-Zone-Loop: fe21c313ec40f27de269a635cf4985c6e5078b28f485
x-campaign-type: default
x-transaction-id: b1f5b066-9d13-4ffc-abea-aac0c1b45edc
x-swg-uid: 01-550e9b3e-0583-468c-bdd3-090d8980b5bd
X-Mailer: Sweego
Message-ID:
 <1786368748.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099@vates.tech>
x-swg-bid: 1786368748.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Subject: Re: [PATCH v1 02/17] xen/riscv: add basic VGEIN management for AIA
 guests
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <b141b8d976719bb9b76147cacfd5842fb7aac74e.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b141b8d976719bb9b76147cacfd5842fb7aac74e.1784560663.git.oleksii.kurochko@gmail.com>
Date: Mon, 10 Aug 2026 15:32:21 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786368747; l=8037;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=/suDN280+hL3fCZDTTxmVx1ex2fURVPekHgQ4TonBYQ=;
 b=LxrofuYjYUYpV9+IlCKbegOA9u3AzG9yWlEYI6U54VAfbZCs+ZBSihrthJCDn1VYKRkD2bnZq
 CJtnANvazd5BVdBY3hEyWhxTI5pZRy60WU5QqicxkHzQwCF2Bc4mPYv
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2011.76c267eae0dd40.19febdfebbd.80b0a5b8f4d6725b=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786368748477
X-purgate-ID: tlsNG-42698a/1786368759-1BCD79EA-D9CAAED3/10/73395122804
X-purgate-type: spam
X-purgate-size: 8646

---=Part.2011.76c267eae0dd40.19febdfebbd.80b0a5b8f4d6725b=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> It was decided to add support for IMSIC from the start instead of having =
APLIC
> operate in direct delivery mode, as it requires a trap-and-emulation app=
roach,
> which is not optimal from a performance standpoint=2E
>=20
> AIA provides a hardware-accelerated mechanism for delivering external
> interrupts to domains via "guest interrupt files" located in IMSIC=2E
> A single physical hart can implement multiple such files (up to GEILEN),
> allowing several virtual harts to receive interrupts directly from hardw=
are=2E
>=20
> Introduce per-CPU tracking of guest interrupt file identifiers (VGEIN)
> for systems implementing AIA specification=2E Each CPU maintains
> a bitmap describing which guest interrupt files are currently in use=2E
>=20
> Add 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=2E When assigning a VGEIN, the corresponding value
> is written to the VGEIN field of the guest hstatus register so that
> VS-level external interrupts are delivered from the selected interrupt
> file=2E
>=20
> Signed-off-by: Oleksii Kurochko <oleksii=2Ekurochko@gmail=2Ecom>
>
> diff --git a/xen/arch/riscv/aia=2Ec b/xen/arch/riscv/aia=2Ec
> index e31c9c2d24=2E=2E4f7f46f58f 100644
> --- a/xen/arch/riscv/aia=2Ec
> +++ b/xen/arch/riscv/aia=2Ec
> @@ -1,11 +1,33 @@
>  /* SPDX-License-Identifier: GPL-2=2E0-only */
> =20
> +#include <xen/bitmap=2Eh>
> +#include <xen/cpu=2Eh>
>  #include <xen/errno=2Eh>
>  #include <xen/init=2Eh>

Add a #include <xen/percpu=2Eh> here instead of in aia=2Eh=2E

>  #include <xen/sections=2Eh>
> +#include <xen/sched=2Eh>
> +#include <xen/spinlock=2Eh>
>  #include <xen/types=2Eh>
> +#include <xen/xvmalloc=2Eh>
> =20
> +#include <asm/aia=2Eh>
>  #include <asm/cpufeature=2Eh>
> +#include <asm/csr=2Eh>
> +#include <asm/current=2Eh>
> +
> +struct vgein_ctrl {
> +    unsigned long bmp;
> +    spinlock_t lock;
> +    struct vcpu **owners;
> +    /* The least-significant bits are implemented first, apart from bit=
 0 */
> +    unsigned int geilen;
> +};
> +
> +/*
> + * VGEIN control structure for each physical CPU to track which VS (gue=
st)
> + * interrupt file IDs are in use=2E
> + */
> +static DEFINE_PER_CPU(struct vgein_ctrl, vgein);
> =20
>  static bool __ro_after_init _aia_usable;
> =20
> @@ -14,10 +36,133 @@ bool aia_usable(void)
>      return _aia_usable;
>  }
> =20
> +static int vgein_init(unsigned int cpu)

Could we call this function with a different cpu arg than the current
one running? If yes, we would read hgeie of not the cpu we wanted=2E
> +{
> +    struct vgein_ctrl *vgein =3D &per_cpu(vgein, cpu);
> +
> +    csr_write(CSR_HGEIE, -1UL);
> +    vgein->geilen =3D flsl(csr_read(CSR_HGEIE) >> 1);
> +    csr_write(CSR_HGEIE, 0);
> +
> +    printk("cpu%u=2Egeilen=3D%u\n", cpu, vgein->geilen);

> +
> +    if ( !vgein->geilen )
> +        return -EOPNOTSUPP;
> +
> +    vgein->owners =3D xvzalloc_array(struct vcpu *, vgein->geilen);
> +    if ( !vgein->owners )
> +        return -ENOMEM;
> +
> +    spin_lock_init(&vgein->lock);
> +
> +    return 0;
> +}
> +
> +static int cf_check cpu_callback(struct notifier_block *nfb, unsigned l=
ong action,
> +                        void *hcpu)
> +{
> +    unsigned int cpu =3D (unsigned long)hcpu;
> +    int rc =3D 0;
> +
> +    switch ( action )
> +    {
> +    case CPU_STARTING:
> +        rc =3D vgein_init(cpu);
> +        if ( rc )
> +            printk("AIA: failed to init vgein for CPU%u\n", cpu);
> +        break;
> +    }
> +
> +    return notifier_from_errno(rc);
> +}
> +
> +static struct notifier_block cpu_nfb =3D {
> +    =2Enotifier_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(0)) )

Why `0` rather than smp_processor_id()? As described above vgein_init() re=
ads CSR_HGEIE
of the current hart but stores the result into per_cpu(vgein, cpu), so the=
 two
must agree=2E

> +    {
> +        dprintk(XENLOG_ERR, "vgein_init() failed: %d\n", rc);
> +        return;
> +    }
> =20
>      _aia_usable =3D true;
> +
> +    register_cpu_notifier(&cpu_nfb);
> +}
> +
> +unsigned int vgein_assign(struct vcpu *v)
> +{
> +    unsigned int vgein_id;
> +    struct vgein_ctrl *vgein =3D &per_cpu(vgein, v->processor);

What happens if v->processor change between vgein_assign() and
vgein_release? Because it seems in such case the release will hit a
different pCPU's bitmap: the original bit will leak and an unrelated
CPU's bit will be cleared under another vCPU's feet=2E

> +    unsigned long *bmp =3D &vgein->bmp;
> +    unsigned long flags;
> +
> +    if ( !vgein->geilen )
> +        return 0;
> +
> +    spin_lock_irqsave(&vgein->lock, flags);
> +    /*
> +     * The vgein_id shouldn't be zero, as it will indicate that no gues=
t
> +     * external interrupt source is selected for VS-level external inte=
rrupts
> +     * according to RISC-V privileged spec:
> +     *   Hypervisor Status Register (hstatus) in RISC-V privileged spec=
:
> +     *
> +     *   The VGEIN (Virtual Guest External Interrupt Number) field sele=
cts
> +     *   a guest external interrupt source for VS-level external interr=
upts=2E
> +     *   VGEIN is a WLRL field that must be able to hold values between=
 zero
> +     *   and the maximum guest external interrupt number (known as GEIL=
EN),
> +     *   inclusive=2E
> +     *   When VGEIN=3D0, no guest external interrupt source is selected=
 for
> +     *   VS-level external interrupts=2E
> +     *
> +     * So start to search from bit number 1=2E
> +     */
> +    vgein_id =3D find_next_zero_bit(bmp, vgein->geilen + 1, 1);
> +
> +    if ( vgein_id > vgein->geilen )
> +        vgein_id =3D 0;
> +    else
> +    {

Potential index error, because above you did:

    vgein->owners =3D xvzalloc_array(struct vcpu*, vgein->geilen)

so valid index are 0=2E=2E=2E(vgein->geilen-1)=2E Adopt either
one of those two options:
    1=2E vgein->owners[vgein_id-1] =3D v
    2=2E vgein->owners =3D xvzalloc_array(struct vcpu *, vgein->geilen+1) =
in
       vgein_init()

I think `2` could be better to have vgein->owners replicated hgeie CSR but
it would left the first entry read-only=2E

> +        __set_bit(vgein_id, bmp);
> +        vgein->owners[vgein_id] =3D v;
> +    }
> +
> +    spin_unlock_irqrestore(&vgein->lock, flags);
> +
> +#ifdef VGEIN_DEBUG

VGEIN_DEBUG is not defined anywhere in the patch, please use
gdprintk(XENLOG_DEBUG, =2E=2E=2E) directly, or drop this branch=2E

> +    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;
> +}
> +
> +void vgein_release(struct vcpu *v, unsigned int vgein_id)
> +{
> +    unsigned long flags;
> +    struct vgein_ctrl *vgein =3D &per_cpu(vgein, v->processor);
> +
> +    if ( !vgein_id )
> +        return;
> +
> +    spin_lock_irqsave(&vgein->lock, flags);
> +    __clear_bit(vgein_id, &vgein->bmp);
> +    vgein->owners[vgein_id] =3D NULL;
> +    spin_unlock_irqrestore(&vgein->lock, flags);
> +
> +#ifdef VGEIN_DEBUG
> +    gprintk(XENLOG_DEBUG, "%s: vgein_id(%u), xen_cpu%u_bmp=3D%#lx\n",
> +           __func__, vgein_id, v->processor, vgein->bmp);
> +#endif
>  }
> diff --git a/xen/arch/riscv/include/asm/aia=2Eh b/xen/arch/riscv/include=
/asm/aia=2Eh
> index aaa4bf91fc=2E=2Ec67be0069a 100644
> --- a/xen/arch/riscv/include/asm/aia=2Eh
> +++ b/xen/arch/riscv/include/asm/aia=2Eh
> @@ -3,8 +3,16 @@
>  #ifndef RISCV_AIA_H
>  #define RISCV_AIA_H
> =20
> +#include <xen/percpu=2Eh>

asm/aia=2Eh needs neither <xen/percpu=2Eh> nor <xen/spinlock=2Eh> as struc=
t
vgein_ctrl and the per-CPU variable both live in aia=2Ec=2E Please drop th=
em
and add <xen/percpu=2Eh> in aia=2Ec

--=20
Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>


-- 
Baptiste Le Duc | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.2011.76c267eae0dd40.19febdfebbd.80b0a5b8f4d6725b=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:45:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:45:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387494.1628753 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQJx-0007zm-94; Mon, 10 Aug 2026 13:45:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387494.1628753; Mon, 10 Aug 2026 13:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQJx-0007zf-5s; Mon, 10 Aug 2026 13:45:41 +0000
Received: by outflank-mailman (input) for mailman id 1387494;
 Mon, 10 Aug 2026 13:45:40 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtQJw-0007zF-9z
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:45:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQJu-00BJvF-Tf
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:45:38 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febebe536000e099@swg.vates.tech>)
 id 6a79d5ea-e002-0a2a0a5209dd-0a2a45029048-40
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:45:38 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febebe536000e099@swg.vates.tech>)
 id 6a79d602-6ca4-0a2a45020019-b9ff1c12a695-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:45:38 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19febebe536000e099.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 13:45:33 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 7B54581C91;
 Mon, 10 Aug 2026 15:45:32 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=AuvJ46ZXsKaVPL6J4UJsdpNDRwM9r7zXEul3tg/qrhg=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=QiO85++4v8Y0lcf+26gHwHqOOxEpKOzB7Tel7kFHD1MMG0uvKBigYgOBre1qR8Vecc7GOC09b
 l2WgyirxCAy1JA63gF2PDn2MoOC5YSvv0nMCypjYg+zCCWZtjJdmKSjDB6CpAMWrdqGyNGgb53a
 QAnroT+JUJiv/uxHawaJ2hga2kOYehIQejhO/1KIb7Q/Yqpwn/lRkYSsqCLTbJ/FLOLCo1uZob7
 2VMvgGHEUF85fATItRcN7zB6PrshPwb5XEWEIfN5i9e/PkqOqw9J5KhuV7Kv+qH6aEwXe2g14xo
 HkFEs5u4RtuOakboWPLUL0H6/Z8+pIqVMRoRO3NZbqGA==
X-Zone-Loop: 2ad11547e23e446bcfd583493630f987771b4a341e0e
x-campaign-type: default
x-transaction-id: 49d14ca0-9328-4204-9a9d-4a365047c0a7
x-swg-uid: 01-f33560e1-6228-48de-99f9-2e09ee78e2bb
X-Mailer: Sweego
Message-ID:
 <1786369533.8631fc262581453bbf619ec5b2062170.19febebe536000e099@vates.tech>
x-swg-bid: 1786369533.8631fc262581453bbf619ec5b2062170.19febebe536000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Subject: Re: [PATCH v1 03/17] xen/riscv: add missing APLIC register
 offsets, masks to asm/aplic.h
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <ee3825adfd0012437a594f6a0e51c6ee71175cc4.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <ee3825adfd0012437a594f6a0e51c6ee71175cc4.1784560663.git.oleksii.kurochko@gmail.com>
Date: Mon, 10 Aug 2026 15:45:23 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786369532; l=932;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=cyL2Gx4dqiwndaPOMigFbRN7tCrMS1O7Fo6s0xPhDnk=;
 b=O4qqs96ENfYIcotiry1NxIU6yitbUjcvnH+bbR4hn57vCMEXo+h6u+P02qXTVknyUCZ4PNlf1
 f99f2rx/kAJDK8gMmYGSLZvi+Yx7MLS+v4lote35pS5mg5qDDysYWkk
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2018.943d49f9532550e2.19febebe324.69f557a2f31343bb=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786369532709
X-purgate-ID: tlsNG-720697/1786369538-31FD62AC-03C5A3EB/10/73395122804
X-purgate-type: spam
X-purgate-size: 1317

---=Part.2018.943d49f9532550e2.19febebe324.69f557a2f31343bb=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> 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=2E
>=20
> No functional change is intended by this patch; it only centralises
> hardware definitions that were previously missing=2E
>=20
> Co-developed-by: Romain Caritey <Romain=2ECaritey@microchip=2Ecom>
> Signed-off-by: Oleksii Kurochko <oleksii=2Ekurochko@gmail=2Ecom>
>
> diff --git a/xen/arch/riscv/include/asm/aplic=2Eh b/xen/arch/riscv/inclu=
de/asm/aplic=2Eh
> index 07318aaac2=2E=2Ef22622b9a2 100644
> --- a/xen/arch/riscv/include/asm/aplic=2Eh
> +++ b/xen/arch/riscv/include/asm/aplic=2Eh
> @@ -15,6 +15,8 @@
> =20
>  #include <asm/imsic=2Eh>
> =20
> +#define APLIC_REG_OFFSET_MASK   0x3fff

_REG stands for memory-mapped control "region" as explained in spec? If
yes, it'd be better to add a comment=2E

--=20
Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>


-- 
Baptiste Le Duc | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.2018.943d49f9532550e2.19febebe324.69f557a2f31343bb=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:55:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:55:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387502.1628761 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQSw-0001fH-2d; Mon, 10 Aug 2026 13:54:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387502.1628761; Mon, 10 Aug 2026 13:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQSv-0001fA-W3; Mon, 10 Aug 2026 13:54:57 +0000
Received: by outflank-mailman (input) for mailman id 1387502;
 Mon, 10 Aug 2026 13:54:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febf4636c000e099@swg.vates.tech>)
 id 1wtQSu-0001f4-R4
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:54:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQSu-003bn7-1G
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:54:56 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febf4636c000e099@swg.vates.tech>)
 id 6a79d828-8faa-0a2a0a5109dd-0a2a4502cb30-16
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:54:56 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19febf4636c000e099@swg.vates.tech>)
 id 6a79d82f-6ca4-0a2a45020019-b9ff1c2299a1-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:54:55 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19febf4636c000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 13:54:49 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 33FCE836B7;
 Mon, 10 Aug 2026 15:54:49 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=qYZlMcdmRV5gUuAWGbMRzHbSRcI58EU4VevDR3Dt7GE=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=XCFbg2XCWFLGGR27dXrp6Q4WGZ9rV+6OoxX+Uw7FQe9HoBZn7PfTdBZYqUaDS8ZsbnYAhrqCU
 thWTcPsI+YMIRL5KuL3ckNPz+CnxocMgOTT4AOcKg3JINFp+uHjG1xpLfZXcyLJnxmdhdW6yn/u
 0xaWhLRLJV6gfNYsvtsrDHLREOm+/gERZKjxkRoR2e04a6LUzcPuaBuV1t0OBO8RHr+DNmDrn+s
 iGUgb+matMPlXXnxteV/2ZM+CLCw5KdgVkhYebwslmEUtZvA17J62ZFJmXUgDTbvfN/L3lmE0Vr
 Gxa2llKzC0sm1qzY/M+pVowGF33wFG96zE1b6YArfySw==
X-Zone-Loop: 12ac97beabf66f61959a1ab1a95b9d6c178d7839e040
x-campaign-type: default
x-transaction-id: bff11c7e-85d3-4528-b2de-57a1e2ce49b8
x-swg-uid: 01-ba4e17f1-c418-4ef8-b15c-4e1af4467c88
X-Mailer: Sweego
Message-ID:
 <1786370089.8631fc262581453bbf619ec5b2062170.19febf4636c000e099@vates.tech>
x-swg-bid: 1786370089.8631fc262581453bbf619ec5b2062170.19febf4636c000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Mon, 10 Aug 2026 15:54:48 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v3 1/2] x86/domctl: don't imply I/O port permissions from
 I/O port mapping
References: <65f69026-f284-4cfd-b502-8d8955b412f5@suse.com>
 <724bd14c-ebba-4e29-be7c-012aa7aa82b2@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <724bd14c-ebba-4e29-be7c-012aa7aa82b2@suse.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2020.8836ca613bbf8c64.19febf46169.4adba427c2485d41=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786370089321
X-purgate-ID: tlsNG-720697/1786370095-30DC12AC-4A3917C6/0/0
X-purgate-type: clean
X-purgate-size: 2019

---=Part.2020.8836ca613bbf8c64.19febf46169.4adba427c2485d41=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 30, 2026 at 03:54:04PM +0200, Jan Beulich wrote:
> Rather than granting permissions when mapping (an operation that DM-s ar=
e
> allowed to carry out, while they can't invoke ioport-permission), check
> whether permissions actually were granted when adding a mapping=2E This =
then
> also allows relaxing the necessary locking=2E
>=20
> While no longer granting permissions upon mapping is "only" at risk of
> breaking guests, no longer revoking permissions upon unmapping strictly
> requires callers to additionally invoke XEN_DOMCTL_ioport_permission=2E =
Or
> else a security issue would arise=2E In-tree code already does so=2E
>=20
> While there switch to using %pd in the two log messages=2E
>=20
> Fixes: 192c4dabc344 ("domctl and p2m changes for PCI passthru")
> Signed-off-by: Jan Beulich <jbeulich@suse=2Ecom>
> ---
> libxl has libxl__grant_vga_iomem_permission(), but I can't spot any I/O
> port equivalent (nor a revoke counterpart, btw)=2E Everywhere else MMIO =
and
> I/O ports look to be treated equally=2E
>=20
> Qemu uses both xc_domain_{iomem_permission,memory_mapping}() in
> igd_write_opregion(), but only xc_domain_{memory,ioport}_mapping() in
> xen_pt_region_update() and xen_pt_{,un}register_vga_regions()=2E Is the =
IGD
> region special in any way? Clearly this can't work from a stubdom=2E

Yes, the IGD opregion is special, it's not something that exist on every
PCI devices, just some Intel graphic devices, it's probably not part of
any spec=2E Other region are just PCI bar, or the VGA region=2E

I guess the toolstack could handle that device and call iomem_perission
instead of QEMU, if needed=2E


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.2020.8836ca613bbf8c64.19febf46169.4adba427c2485d41=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 13:56:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 13:56:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387509.1628771 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQUX-0002Ey-CC; Mon, 10 Aug 2026 13:56:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387509.1628771; Mon, 10 Aug 2026 13:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQUX-0002Er-9f; Mon, 10 Aug 2026 13:56:37 +0000
Received: by outflank-mailman (input) for mailman id 1387509;
 Mon, 10 Aug 2026 13:56:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3j9h5agYKCYIykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 1wtQUV-0002Eh-SL
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 13:56:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQUT-00EaMq-TR
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:56:33 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3j9h5agYKCYIykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 6a79d889-e002-0a2a0a5209dd-0a2a4505e71e-30
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:56:33 +0200
Received: from [209.85.214.200] (helo=mail-pl1-f200.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3j9h5agYKCYIykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 6a79d890-4cb1-0a2a45050019-d155d6c8ccb9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:56:33 +0200
Received: by mail-pl1-f200.google.com with SMTP id
 d9443c01a7336-2cacd6d37edso31874985ad.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 06:56:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786370192; x=1786974992; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=scUOSvWK83pq1cJ9Y23cB7+1ZF4+W+kSdr2X3LP0fns=;
        b=Btw3EVE0HPrzXezXN8OZpzVtRs6G+8xuttQe0mJUOu8hc7KcFEPRSWnd9WSxLNRWBI
         9GspDDOsCJIVD8dB23HSAAQ9H+lNeiS3VZA1ZyMWb5HbCLO028zIBj1Dp4bP6KPWRC1l
         koUk3Gvbruyp8VLAdTBXD7CCCnahk4Jtx15NgK4l+UqA9j1omZvwuQ+kJxSh+trEWi/D
         19AXPFpY+NFf+BAQq4NLPb2q14O/Qzkpu526C/dhHfcD7k+fygUDAYwpjG7utyzXEzHO
         4XYUtp6A2vse944RP/FePCNa2BVO/cv8svX1JoWM+L1mJo5mGuvqdsZq9HLSw8EuKdvs
         2Xlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786370192; x=1786974992;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=scUOSvWK83pq1cJ9Y23cB7+1ZF4+W+kSdr2X3LP0fns=;
        b=mLoGQjaVMaOsxvOskj9X2QA7B0bRnpT0h2vtmXlDVlRSSrY1tPKJwB4tHv3PHb4EWg
         Z59/NkwFBEtra78lmL586nOd2zBl326tGpHw2rCSfIh/jgxtVDCkAIrt1fOjxmoiBG5+
         pueIA84/o2Coi9MR0ZfBi5S18rCfPQlS8x45J5JY1L0Hn5+6gfcoJUFG/0h1YzV0T5GA
         4+pDCBC84uRBTVNm38VMvZDUJ6AsmS+bZPpoJETzZU+e4UpI8aYld1WI5gfsZ4Zy+26s
         DMQetZvQ1A5MH/VARXwnnh4e55rRQD2V8el8EKKsW5zDgF0RmaZhfyLGjZ0oDvBic9rp
         3esw==
X-Forwarded-Encrypted: i=1; AHgh+RpJcUuNE3bLAl8wev9Gc+9Yj1OnPmn1AwV0kMcNhQNF/A566RI+HigjuMOIFpT1LODTR469GuPCtmc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxceE7SkJdcEp0Hr2dHBZzgrO9NtPTqW9FJgrDe5UZiNmLhdzkB
	TIYK0MMJhI90sypr+fR4T2Ng4pGwSoiRjgiRqcvj5fWKJGF/bACWxPu+bhII8TxoZ7bQIlOsr7d
	gTZg6nA==
X-Received: from plml3.prod.google.com ([2002:a17:903:1843:b0:2cc:7ef7:ea41])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:13c7:b0:2ce:9c48:22d3
 with SMTP id d9443c01a7336-2d30033718fmr21913835ad.11.1786370191619; Mon, 10
 Aug 2026 06:56:31 -0700 (PDT)
Date: Mon, 10 Aug 2026 06:56:31 -0700
In-Reply-To: <d0ee3cf97854b904323db3799e05117d065a6ba0.camel@infradead.org>
Mime-Version: 1.0
References: <20260806233609.212337-14-seanjc@google.com> <d0ee3cf97854b904323db3799e05117d065a6ba0.camel@infradead.org>
Message-ID: <annYj0zj68hH8zIu@google.com>
Subject: Re: [PATCH v6 13/51] x86/acrn: Mark TSC frequency as known when using
 ACRN for calibration
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, 
	decui@microsoft.com, longli@microsoft.com, ajay.kaher@broadcom.com, 
	alexey.makhalov@broadcom.com, jan.kiszka@siemens.com, 
	dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, 
	jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-c201ff/1786370193-716AD2A1-C2E3E16F/0/0
X-purgate-type: clean
X-purgate-size: 876

On Sat, Aug 08, 2026, David Woodhouse wrote:
> On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> > Mark the TSC frequency as known when using ACRN's PV CPUID information.
> > Per commit 81a71f51b89e ("x86/acrn: Set up timekeeping") and common sense,
> > the TSC freq is explicitly provided by the hypervisor.
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> 
> Huh... does this literally get reverted completely in the very *next*
> patch in the series? Kind of weird, but I guess in some ways it makes
> sense...

The literal code gets reverted, but the functional change does not.  Before this
change, ACRN is the only guest-side PV code that doesn't set X86_FEATURE_TSC_KNOWN_FREQ
when the hypervisor provides the exact frequency.  I.e. this patch allows for
making the "No functional change intended" claim in the next patch.


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:24:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:24:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387521.1628779 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQvE-0007KW-Cn; Mon, 10 Aug 2026 14:24:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387521.1628779; Mon, 10 Aug 2026 14:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQvE-0007KP-9h; Mon, 10 Aug 2026 14:24:12 +0000
Received: by outflank-mailman (input) for mailman id 1387521;
 Mon, 10 Aug 2026 14:24:11 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f24d6000e099@swg.vates.tech>)
 id 1wtQvC-0007JE-Sz
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:24:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQvB-008vgD-Rc
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:24:09 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f24d6000e099@swg.vates.tech>)
 id 6a79df00-2eae-0a2a0a5409dd-0a2a4508b484-30
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:24:09 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f24d6000e099@swg.vates.tech>)
 id 6a79df09-f659-0a2a45080019-b9ff1c128abf-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:24:09 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec0f24d6000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 14:24:03 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 9079F83723;
 Mon, 10 Aug 2026 16:24:02 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=w3Us9nesQGAMRB6+hb7KVElnxo3+BAlMCfqBlWxluIU=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=sLomAFoEh0VD9jNswyxRCc0EHebV2qsMrWrQ23ZSKUDgeF/ZDPCpz0rWQJ/Q9On0T7kKhBt1D
 Itnn9mYI509sRMhynAWL8uLqM8WNcTONiWh898tDmGmduMou2m3Gmd38vzOUU9wTdJVa6JZ7yeh
 kJL6LmJK9SqUEBtWaTxQ4CyT9T7EYpwGEypSya+wlbv+0ClTbBHOfYfl1imNxYknNgF2GE4hx/3
 xgqFcfdTa6rve3EFQihoVQ34fyroWtSlMjyNjdOKnuNVzNoRrNWzgvKT+CjusVn5tgszCOiUFra
 p/VI9XzeFA7e18OKxcAffnHRia4vFx2imhkEDzm2wWBQ==
X-Zone-Loop: 64e6ac7acbbe1721415925217bf7e9260646a46776ea
x-campaign-type: default
x-transaction-id: 0942e2cc-63eb-4493-9f70-8b571d7cadb0
x-swg-uid: 01-816107dc-484d-40c0-bc0a-0c1d64c0ec7e
X-Mailer: Sweego
Message-ID:
 <1786371843.8631fc262581453bbf619ec5b2062170.19fec0f24d6000e099@vates.tech>
x-swg-bid: 1786371843.8631fc262581453bbf619ec5b2062170.19fec0f24d6000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Mon, 10 Aug 2026 16:24:02 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 1/3] xen/scripts: import gen_compile_commands.py from
 Linux
References: <20260810095056.29884-1-gwd@xenproject.org>
 <20260810095056.29884-2-gwd@xenproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260810095056.29884-2-gwd@xenproject.org>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2029.9152c53835ec1e0f.19fec0f22a8.f9e5d48b8774318a=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786371842728
X-purgate-ID: tlsNG-c1860d/1786371849-CF15E87B-9B6DBEA1/0/0
X-purgate-type: clean
X-purgate-size: 1319

---=Part.2029.9152c53835ec1e0f.19fec0f22a8.f9e5d48b8774318a=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 10, 2026 at 10:49:43AM +0100, George Dunlap wrote:
> Xen's Kbuild-derived build system records the exact command line used
> to compile each object in =2E<target>=2Eo=2Ecmd files=2E  That is everyt=
hing
> needed to produce a compile_commands=2Ejson compilation database, the
> format clangd and other tooling consume to provide accurate
> cross-referencing (go to definition, find references, call hierarchy)
> in LSP-capable editors=2E
>=20
> Import scripts/clang-tools/gen_compile_commands=2Epy from the Linux
> kernel, unmodified, so that the provenance of the code is easy to
> verify (commit 90efe2b9119f, Linux v6=2E16)=2E
>=20
> As-is the script produces an empty database on a Xen tree, since
> Xen's compile command lines differ slightly from Linux's; the
> following patch adapts it=2E
>=20
> Assisted-by: LLM
> Signed-off-by: George Dunlap <gwd@xenproject=2Eorg>

Acked-by: Anthony PERARD <anthony=2Eperard@vates=2Etech>

Thanks,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.2029.9152c53835ec1e0f.19fec0f22a8.f9e5d48b8774318a=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:24:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:24:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387522.1628788 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQvP-0007Zr-Iq; Mon, 10 Aug 2026 14:24:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387522.1628788; Mon, 10 Aug 2026 14:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQvP-0007Zk-G1; Mon, 10 Aug 2026 14:24:23 +0000
Received: by outflank-mailman (input) for mailman id 1387522;
 Mon, 10 Aug 2026 14:24:22 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f65df000e099@swg.vates.tech>)
 id 1wtQvO-0007ZB-Fl
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:24:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQvN-003hT6-Sf
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:24:21 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f65df000e099@swg.vates.tech>)
 id 6a79defc-8faa-0a2a0a5109dd-0a2a4509b7d8-46
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:24:21 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f65df000e099@swg.vates.tech>)
 id 6a79df15-be1a-0a2a45090019-b9ff1c2298b3-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:24:21 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec0f65df000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 14:24:19 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 4972583725;
 Mon, 10 Aug 2026 16:24:19 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=04I6Hu+440OeMPdcU+TDpogAnzI3pS1YCoJF4T84N+4=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=Iig7tMnTtsAQ1YfCjsshDExFGGfEw30lhyH1+hRLo5nmzcVnVTdQIz6G26q/XquHTAAMAodGh
 A+5xOuNF15+s0fDlg1fOZ9W1jccSX6S1UOnXxx1AQCP5JFe4UDITydmcJ+4EA/lES73BHhUdW6g
 6J8OSS1412myjXX2SWW/CkBsdxCQmI/6uZ9U1eSK7eag95wS9/KbF/RTrc+XFDO9dRBEAP8YYwW
 aMenGrJ2Fi6rM0kaXEh5nG5RC8Me7s2AMOoHOKPNOc3BE6bgMrYE74FziYb5j4NwbzeY7G94cKN
 E3M7OFGvzauhlUpWCo9KeFt3zhW2iF1vtakrPNkfyagw==
X-Zone-Loop: 9d0be436b5d9daf2dfb7e39491816da8b6c27f56a948
x-campaign-type: default
x-transaction-id: 0c5de289-a693-4dda-b2de-1c0f95263859
x-swg-uid: 01-6602d102-7a6f-4bfb-92f4-564e150c8a96
X-Mailer: Sweego
Message-ID:
 <1786371860.8631fc262581453bbf619ec5b2062170.19fec0f65df000e099@vates.tech>
x-swg-bid: 1786371860.8631fc262581453bbf619ec5b2062170.19fec0f65df000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Mon, 10 Aug 2026 16:24:19 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 2/3] xen/scripts: adapt gen_compile_commands.py to Xen
References: <20260810095056.29884-1-gwd@xenproject.org>
 <20260810095056.29884-3-gwd@xenproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260810095056.29884-3-gwd@xenproject.org>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.202a.e62aed357f894a53.19fec0f63e6.8e7d40e4d9946ad=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786371859430
X-purgate-ID: tlsNG-bad1c0/1786371861-FC610034-4EC8FEAF/0/0
X-purgate-type: clean
X-purgate-size: 1320

---=Part.202a.e62aed357f894a53.19fec0f63e6.8e7d40e4d9946ad=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 10, 2026 at 10:49:44AM +0100, George Dunlap wrote:
> Two changes from the Linux original:
>=20
>  - Linux's compiler invocations end with the source file
>    ("=2E=2E=2E -c -o foo=2Eo foo=2Ec"), and the script's line pattern re=
lies
>    on that; Xen's cmd_cc_o_c places "-c $<" before "-o" and "-MQ",
>    so on a Xen object tree the unmodified script matches nothing and
>    produces an empty database=2E  Adjust _LINE_PATTERN to capture the
>    command up to and including "-c" plus the source file, dropping
>    the remainder, which database consumers do not need=2E
>=20
>  - Reword the docstring and help text to refer to Xen=2E
>=20
> The support for reading object lists from archives and modules=2Eorder
> is unused in Xen but retained to minimise divergence from the
> original=2E
>=20
> Assisted-by: LLM
> Signed-off-by: George Dunlap <gwd@xenproject=2Eorg>

Reviewed-by: Anthony PERARD <anthony=2Eperard@vates=2Etech>

Thanks,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.202a.e62aed357f894a53.19fec0f63e6.8e7d40e4d9946ad=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:24:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:24:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387525.1628797 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQvc-0007y7-S9; Mon, 10 Aug 2026 14:24:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387525.1628797; Mon, 10 Aug 2026 14:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtQvc-0007xz-PS; Mon, 10 Aug 2026 14:24:36 +0000
Received: by outflank-mailman (input) for mailman id 1387525;
 Mon, 10 Aug 2026 14:24:34 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f92fc000e099@swg.vates.tech>)
 id 1wtQva-0007up-NE
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:24:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtQva-008vjl-2h
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:24:34 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f92fc000e099@swg.vates.tech>)
 id 6a79df15-2eae-0a2a0a5409dd-0a2a4507c85c-46
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:24:33 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec0f92fc000e099@swg.vates.tech>)
 id 6a79df21-b4ea-0a2a45070019-b9ff1c12b527-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:24:33 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec0f92fc000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 14:24:31 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id E2C7183723;
 Mon, 10 Aug 2026 16:24:30 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=ipFeHvE57IAsAWSsNWzZuqCIDNnFW9Ndjb+yWQWlc1U=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=DBweDEdn4CifiahFKFPNlF+TeE3vA4Mpbhwla78HlQzT8f76yrRsRlKXJOZnpRPyBQnzON+6S
 odtufhIQdC8vr9xtI6jJW1T6WFuAqKLahEDbunaZcFXEfM6XYMGRF+avGHcQC8b3l1PmSFCeLlJ
 4s1UlWDY9fcHFhtZbSd/Lt0GsPGr3T+RuJqI+tg/LrV+8Dk3IqGPYTJ1z+j2PUU6tGY6nA5/hlS
 W4qK1KDTjuKiJc0lPVpTEhvDHvF8dS9fo6hicW7st+H+wW/qYvIbf4PdkkazDFrFlSWJ0p0Glis
 EcO4eXxcbk7pcud0Uz8Z133n5JhH/bZ+Tq2OsHXCkApw==
X-Zone-Loop: c68e55a2f3f3038df9810e67bca596aaae5f8543d083
x-campaign-type: default
x-transaction-id: f23847f2-c3a6-4677-b231-080ca9acecf4
x-swg-uid: 01-58a8410e-2e16-4d41-ad90-e7d6de06d9dc
X-Mailer: Sweego
Message-ID:
 <1786371871.8631fc262581453bbf619ec5b2062170.19fec0f92fc000e099@vates.tech>
x-swg-bid: 1786371871.8631fc262581453bbf619ec5b2062170.19fec0f92fc000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Mon, 10 Aug 2026 16:24:30 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: George Dunlap <gwd@xenproject.org>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 3/3] build: add compile_commands.json target
References: <20260810095056.29884-1-gwd@xenproject.org>
 <20260810095056.29884-4-gwd@xenproject.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260810095056.29884-4-gwd@xenproject.org>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.202b.b5ca387bdc25a7b2.19fec0f914f.d3edfe96f7118aa8=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786371871055
X-purgate-ID: tlsNG-ef75cf/1786371873-374D3AE4-9C644EFB/0/0
X-purgate-type: clean
X-purgate-size: 1441

---=Part.202b.b5ca387bdc25a7b2.19fec0f914f.d3edfe96f7118aa8=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 10, 2026 at 10:49:45AM +0100, George Dunlap wrote:
> Add a convenience target generating the compilation database from a
> built object tree, alongside the other developer conveniences (tags,
> cscope, cloc -- the last of which already walks the same =2Ecmd files):
>=20
>     make -C xen compile_commands=2Ejson
>=20
> The output lands in the object tree root=2E  For an in-tree build,
> clangd and other consumers discover it there automatically when
> opening files; for an out-of-tree build, symlink it into the source
> tree root (consumers search the ancestors of the file being edited)=2E
>=20
> Note the database records the compiler invocations actually used=2E
> With a clang build it is consumable by clangd as-is; for a gcc build,
> clang-based tools may need a small =2Eclangd configuration
> (CompileFlags: Remove/Add) dropping gcc-only flags=2E
>=20
> Also add the generated file to =2Egitignore=2E
>=20
> Assisted-by: LLM
> Signed-off-by: George Dunlap <gwd@xenproject=2Eorg>

Reviewed-by: Anthony PERARD <anthony=2Eperard@vates=2Etech>

Thanks,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.202b.b5ca387bdc25a7b2.19fec0f914f.d3edfe96f7118aa8=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:30:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:30:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387544.1628806 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtR0z-0001hA-EB; Mon, 10 Aug 2026 14:30:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387544.1628806; Mon, 10 Aug 2026 14:30:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtR0z-0001h3-Ba; Mon, 10 Aug 2026 14:30:09 +0000
Received: by outflank-mailman (input) for mailman id 1387544;
 Mon, 10 Aug 2026 14:30:08 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3beB5agYKCXAgSObXQUccUZS.QcalSb-RSjSZZWghg.lSbdfcXSQh.cfU@flex--seanjc.bounces.google.com>)
 id 1wtR0y-0001gx-OA
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:30:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtR0y-003iou-0l
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:30:08 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3beB5agYKCXAgSObXQUccUZS.QcalSb-RSjSZZWghg.lSbdfcXSQh.cfU@flex--seanjc.bounces.google.com>)
 id 6a79e04b-2eae-0a2a0a5409dd-0a2a4505cff8-42
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:30:07 +0200
Received: from [209.85.215.197] (helo=mail-pg1-f197.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3beB5agYKCXAgSObXQUccUZS.QcalSb-RSjSZZWghg.lSbdfcXSQh.cfU@flex--seanjc.bounces.google.com>)
 id 6a79e06e-4cb1-0a2a45050019-d155d7c5e039-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:30:07 +0200
Received: by mail-pg1-f197.google.com with SMTP id
 41be03b00d2f7-c856470fe9fso1448938a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 07:30:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786372206; x=1786977006; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Pt4y4GsIfgXju50y9aE1V5oqKvyqhzjPLlHBnjvlrwI=;
        b=LGFverQ9ixFZDnqSr2+C8XTmo954m86TKoh7xjZnMoyE0apo/oikqD9OPbJf9iCxxF
         oEAJZaF8FJZpbbLOXFhmr8gQrTPJDJ9A91LI9+x1TvlszL4e+8C2AxP5vy3GIeMfJh99
         O4d0ZIDHMGa0mX5zeW8A92BjpUThvha+HNDlNoguwRgvmrk4MPLZ1m/BluhGUnck94iI
         ThT2YygDWMETP/Sc0ExmZFIipC967HZqQSkhcr+pz3ZoHODUdMwLSfbAAmP50IdA6F6I
         c1vrvRMHiX6p1Os4YHYmbbpDe9cKJfJjLwocQf4L3Ehl5nhUTkGh3vxUGfdFqiXoRj3N
         JTnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786372206; x=1786977006;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Pt4y4GsIfgXju50y9aE1V5oqKvyqhzjPLlHBnjvlrwI=;
        b=O/O0mf+yx8dPblnG9a/fLjbnMM0w7eqcJsVGamqsHt3MvcaESml/4JCgZjYL8JDYP1
         r3u5k16yEIqJ/mO62nE3MDPzE3UuVQi2Yb3rIG7qxQzEof85swHFCYNgLtv4kSO04rG2
         opqlJdiTbKjyb8WDWqp62HzgDq2klkxrIn0QxRqVwa/3EG/nf3i1Cja2jZ9mda9tMF0V
         QoyyzsJagHCSfOYbQkud1/aYWSklCT2TjzYgBubOsR7EE477kluLreMknU5UIAbDb7J+
         8ZtOhkADOllAOwg6AW1FrBp6JrS9K5rjOQSOwgElVJvs45dgFrt0PRZ1JrRUBDFzD5Tf
         NkUQ==
X-Forwarded-Encrypted: i=1; AHgh+Rolpmiq8dKpYkrYHoODd9bdC9qWUoXJdkZu1k+jHETVQFuOnuc4D3BVc2yCfBw3MFxSQ8D8j6kxu0M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyXPK23p6rBzwedzkMxxFEHHIFsPpR9taUtksRnSUZICVsjqV0F
	jJABi7Pv3p8hSZE4+HDS6EPy6KbRwOIevhIseeex3cKVLqS8Xb0BlfIBVie1XJxSyFhPXNG8jgr
	H94NB+g==
X-Received: from pgmo14.prod.google.com ([2002:a63:5d4e:0:b0:cbe:7df7:35b0])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:7fa0:b0:3c3:76a8:c0f
 with SMTP id adf61e73a8af0-3cbce6f17b9mr20503675637.4.1786372205374; Mon, 10
 Aug 2026 07:30:05 -0700 (PDT)
Date: Mon, 10 Aug 2026 07:30:04 -0700
In-Reply-To: <b8c0e3537904e29f233cbb03f4d3ddb5247e2af7.camel@infradead.org>
Mime-Version: 1.0
References: <20260806233609.212337-11-seanjc@google.com> <b8c0e3537904e29f233cbb03f4d3ddb5247e2af7.camel@infradead.org>
Message-ID: <anngbOavdPam2kKy@google.com>
Subject: Re: [PATCH v6 10/51] x86/tdx: Force TSC frequency with CPUID-based
 info provided by the TDX-Module
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, pbonzini@redhat.com, 
	kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, 
	decui@microsoft.com, longli@microsoft.com, ajay.kaher@broadcom.com, 
	alexey.makhalov@broadcom.com, jan.kiszka@siemens.com, 
	dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, 
	jgross@suse.com, daniel.lezcano@kernel.org, tglx@kernel.org, 
	jstultz@google.com, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-c201ff/1786372207-71CA82A1-EC93AD19/0/0
X-purgate-type: clean
X-purgate-size: 2896

On Sat, Aug 08, 2026, David Woodhouse wrote:
> On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> > When running as a TDX guest, explicitly set the TSC frequency to a know=
n
> > value, using CPUID-based information, instead of potentially relying on=
 a
> > hypervisor-controlled PV routine.  For TDX guests, CPUID.0x15 is always
> > emulated by the TDX-Module, i.e. the information from CPUID is more
> > trustworthy than the information provided by the hypervisor.
> >
> > To maintain backwards compatibility with TDX guest kernels that use nat=
ive
> > calibration, and because it's the least awful option, retain
> > native_calibrate_tsc()'s stuffing of the local APIC bus period using th=
e
> > core crystal frequency.  While it's entirely possible for the hyperviso=
r
> > to emulate the APIC timer at a different frequency than the core crysta=
l
> > frequency, the commonly accepted interpretation of Intel's SDM is that =
APIC
> > timer runs at the core crystal frequency when that latter is enumerated=
 via
> > CPUID:
> >
> >   The APIC timer frequency will be the processor's bus clock or core
> >   crystal clock frequency (when TSC/core crystal clock ratio is enumera=
ted
> >   in CPUID leaf 0x15).
> >
> > If the hypervisor is malicious and deliberately runs the APIC timer at =
the
> > wrong frequency, nothing would stop the hypervisor from modifying the
> > frequency at any time, i.e. attempting to manually calibrate the freque=
ncy
> > out of paranoia would be futile.
> >
> > Deliberately leave CPU frequency calibration as is, since the TDX-Modul=
e
> > doesn't provide any guarantees with respect to CPUID.0x16.
> >
> > Expose and use cpuid_get_tsc_info() instead of providing a wrapper to
> > get the TSC and core crystal frequency, as TDX is the only anticipated
> > user outside of the TSC code, i.e. adding a helper to dedup the math wo=
n't
> > actually dedup anything.  Having TDX use "struct cpuid_tsc_info" also
> > avoids the temptation of declaring a local "tsc_khz" variable and thus
> > unintentionally creating a shadow of the global "tsc_khz".
> >
> > Cc: Kiryl Shutsemau (Meta) <kas@kernel.org>
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
>=20
> I don't know if we should set X86_FEATURE_TSC_RELIABLE before bailing
> out in the case where cpuid_get_tsc_info() fails, or just not care
> about that because it Can Never Happen=E2=84=A2? Previously it was set
> unconditionally from tdx_early_init().
>=20
> Whatever...

Heh, yeah, "whatever" is about my thought exactly.  I could go either way. =
 I
would buy an argument that the TSC itself is still reliable even if the fre=
quency
isn't known.  On the other hand, the frequency could be computed via calibr=
ation,
at which point the frequency is no longer reliable and arguably should be s=
anity
checked.


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:45:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387553.1628816 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRFn-0003XE-LP; Mon, 10 Aug 2026 14:45:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387553.1628816; Mon, 10 Aug 2026 14:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRFn-0003X7-IH; Mon, 10 Aug 2026 14:45:27 +0000
Received: by outflank-mailman (input) for mailman id 1387553;
 Mon, 10 Aug 2026 14:45:26 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtRFm-0003X1-Qk
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:45:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtRFl-00ElvR-KI
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:45:25 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79e3fd-2eae-0a2a0a5409dd-0a2a4503da2a-30
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:45:25 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79e405-fae8-0a2a45030019-d155dd2ce41c-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:45:25 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f703a9d05so1477577f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 07:45:25 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48002150952sm31371763f8f.15.2026.08.10.07.45.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2026 07:45:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786373125; x=1786977925; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1zR4+Ndao50WlK7Io6aceA3WQTvXsw/XX3ZCuxEEkqA=;
        b=TtJ6eU9F7hOoTZJLb1mW/rQWz2GuHn69+vzwOuBnc3oiEaUo9XN5ssjyuAoEF8VbND
         JEkEU6ejWRkotnOdDzJW/bIq+RUcly5EwBy3GS1FW91AeJDTOq9wcp04iw+9vxlAJON2
         vHLO7873nOCuwNUdZOzI8+Od7MQg5AzmARv1Cw142qlr9mf1KNlbVjshsT2JtUvTPEe0
         dEXjjg4yrRQ5URmS3twZquPKP+P0ush8kiAFKtVTO+Ogdd+qMiZ+rUiNjL3TghOmSp3w
         0P1FUxpAHy5aEfsqSsgCuMqcmEgJ1Lo0g3XA6vMXj/8X5k1l25wW0JFF0atDVyE9qORC
         b0ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786373125; x=1786977925;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=1zR4+Ndao50WlK7Io6aceA3WQTvXsw/XX3ZCuxEEkqA=;
        b=XEMU4fjO2L6WMh3XD9L4hF9bv5DNFNHQauuXac7Nf4t9AeJCOqc2v92qCRzIFuIwKg
         seVpk4QKJdMS75TIFsLlXdw25hI4F2HCEKFJ8FcNVeyN6On40LXLjb9PUCp2vJAaph4D
         XPY/Gec6PM8TIeJZhG/KLur+xJsqNjXWRb+NqLx02xY3A3BVOLccO+z8v/60jT55pPud
         2bQGexBBXoMYCnnQzSpj/o/VNOZ/9aZr/taQCxfEPi87dZk2IGnsHXzNEmhc38i43oBt
         mC4bvC1m1lp5wsrNWWctlDMk3J84oq6zWuw96FMKd8oycdXfLKwMNSSjL4OotYU4GCz5
         YVWQ==
X-Gm-Message-State: AOJu0YwTHWL7EJNY5yL/04zFluow5tbiSSt6xVBmfzKeOCEGCp9MjayL
	noFdu7ZOLJSkxUaODmt9wq4DO9NY5z/8dzQfqv70iv1JDQtzPbYYHXii
X-Gm-Gg: AR+sD13tYwpYyp/HFV1tM8Rl/QABVPFu59Mgkf1Rw2Iigo3KZtR5IwfvIugQ/nHe/II
	imo2AMo+30nlMU3NZ8RigIuVN1rPebIE68DZuvwVZm7oLAxyENH3nvdYTSqVkT14ZQRL9vRNms3
	FVy4Q38o50K/4PK/VutOxQts9I5D+a8qyOoBK0A1QVtBthPNSzfOsyZ79R8zxsL1oi4wWVj140F
	B+YagwVzdoHOjhjMpgE2vZ292YQJfJO0ucAzZZGHt1OFwiAijVOiI8zXiHCxgfsfyiW/uqezhKW
	09RJUG+345zGFCwL4PkwSSH/TN7rXEALrcCUAoXdUsK49jvR2AKWT6NFbPrJRZOZqnUyS1oeEzE
	sZc19j4FRBh7yYsIkUwKQA7YT1Vvjo3iAzcH5u2Cuc3hUx3kjpxtOrzp8Bs1omR0RJ9I8XeXAWK
	wecVjGdgArTsDzFJyUVwNTXZ1o5ipz41Q041pQKc5b1qW4R8f0vHZyl8z2K8mj8K5koo2QoxCD2
	kymkmMgne7qCFt7WFs0ZBm+/rIqv+1r+k2vwxUTULE=
X-Received: by 2002:a05:6000:4715:b0:47f:86af:8fdd with SMTP id ffacd0b85a97d-48002670a9fmr35995155f8f.3.1786373125080;
        Mon, 10 Aug 2026 07:45:25 -0700 (PDT)
Message-ID: <b1e6363b-2012-44fe-9aa9-3d0f049f0b69@gmail.com>
Date: Mon, 10 Aug 2026 16:45:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 03/17] xen/riscv: add missing APLIC register offsets,
 masks to asm/aplic.h
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <ee3825adfd0012437a594f6a0e51c6ee71175cc4.1784560663.git.oleksii.kurochko@gmail.com>
 <1786369533.8631fc262581453bbf619ec5b2062170.19febebe536000e099@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786369533.8631fc262581453bbf619ec5b2062170.19febebe536000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1786373125-758824E9-CD6F66F3/10/73395122804
X-purgate-type: spam
X-purgate-size: 1723



On 8/10/26 3:45 PM, Baptiste Le Duc wrote:
>> 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.
>>
>> No functional change is intended by this patch; it only centralises
>> hardware definitions that were previously missing.
>>
>> Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
>> index 07318aaac2..f22622b9a2 100644
>> --- a/xen/arch/riscv/include/asm/aplic.h
>> +++ b/xen/arch/riscv/include/asm/aplic.h
>> @@ -15,6 +15,8 @@
>>   
>>   #include <asm/imsic.h>
>>   
>> +#define APLIC_REG_OFFSET_MASK   0x3fff
> 
> _REG stands for memory-mapped control "region" as explained in spec? If
> yes, it'd be better to add a comment.
> 

Yes, it is a mask that allows us to get the offsets for the registers of 
an interrupt domain’s memory-mapped control region.

IMO, if the problem is with the name of the macro, it would be better to 
use a clearer name instead of adding a comment. For example, 
`APLIC_CTRL_REGION_OFFSET_MASK` sounds self-explanatory to me.

If you’re still not happy with the suggested name and it isn't 
self-explanatory, then:

/*
  * Offsets of the registers of an interrupt domain's memory-mapped control
  * region, which is APLIC_MIN_SIZE bytes large.
  */
#define APLIC_CTRL_REGION_OFFSET_MASK   0x3fff

Alternatively, I could keep the old name (APLIC_REG_OFFSET_MASK) and use 
the suggested comment.

Which option do you prefer?

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:49:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:49:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387559.1628826 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRJw-0004Bb-5N; Mon, 10 Aug 2026 14:49:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387559.1628826; Mon, 10 Aug 2026 14:49:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRJw-0004BU-1k; Mon, 10 Aug 2026 14:49:44 +0000
Received: by outflank-mailman (input) for mailman id 1387559;
 Mon, 10 Aug 2026 14:49:43 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtRJu-0004BO-SP
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:49:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtRJu-0001Yw-5F
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:49:42 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@swg.vates.tech>)
 id 6a79e501-8faa-0a2a0a5109dd-0a2a4501d10a-2
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:49:42 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@swg.vates.tech>)
 id 6a79e505-5984-0a2a45010019-b9ff1c2396c9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:49:41 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec268e07000e099.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 14:49:37 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id C63A882207;
 Mon, 10 Aug 2026 16:49:36 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=8hzj2NizrqUYvebWcKT36+ktgNDru+858dceapaxZhg=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=nQrpnSdu08xzASFK1N2seAmvfyAc4BdmSZkG+5iv0YPjjuvbQI/CL7ul8IBWlzJBrnpGwX9Vc
 811cKku0kEhi4VOLLH9qkpODaBmE7jP6qEY9C4mAi7To2WbLHhkTENmyKfYdGYaAZKU0gYnAqE4
 oiTaaOHsjWSEETdPqG/agsJDAHrRZk/t40QM9TsLAriG2+9boOmx0idRCNOmsQqwQQ7EVn645Bp
 ecIDLp516qxwdeSRD412gQZEei6Ra0rzzA/JWqwxONbD7tuD5lGrFzLRTimEdbbAqAXDUwCdFQB
 obUI0prf7qu5vb7wgURsHP0eQFq8AfKRGz60q+bGyACg==
X-Zone-Loop: e37e6a050a64299685ac3f4f3c4e3dbfecd4d29a4ca3
x-campaign-type: default
x-transaction-id: c97014f1-4772-476b-98f1-0d3f9e539b8f
x-swg-uid: 01-52b058f6-6e36-46e4-9a58-f129f24452a5
X-Mailer: Sweego
Message-ID:
 <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
x-swg-bid: 1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
Date: Mon, 10 Aug 2026 16:49:30 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786373376; l=5445;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=fmPG1sGGrW14MnmDh+vw1K0FhMsncCr8M+mT56ERHzk=;
 b=gOK7CD1jOyWuCSsquECy+s1gQu7CQBdyDNn07ynxTxy0ADI6qdVLbYeVOGc8VYl9u3f+FyORO
 aSv0c2I2J1NC8fFyC5PQZVAafquChPCDoDoWSPnrgmav8Kn2sGEIvrT
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2039.d3a9d985718257a9.19fec268bf5.69e8bf0c8ca29046=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786373377014
X-purgate-ID: tlsNG-d62444/1786373381-BEA66757-4173BB55/10/73395122804
X-purgate-type: spam
X-purgate-size: 6007

---=Part.2039.d3a9d985718257a9.19fec268bf5.69e8bf0c8ca29046=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> RISC-V guests can expose several virtual interrupt controllers at
> distinct GPA ranges: vPLIC (hasn't been introduced yet) for legacy machi=
nes,
> vAPLIC and vIMSIC for AIA-compliant ones (is being introduced in the fol=
low
> up patches)=2E 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=2E
>=20
> 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=2E The MMIO fault path delegates to a single
> try_handle_mmio() entry point and remains agnostic of which device
> owns a particular address=2E
>=20
> Subsequent patches wire this into arch_domain_create() and the MMIO faul=
t
> path in traps=2Ec=2E
>=20
> Signed-off-by: Oleksii Kurochko <oleksii=2Ekurochko@gmail=2Ecom>
> Reviewed-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
>
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index 046f73f4d8=2E=2Ec452ebc3cf 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -14,6 +14,7 @@ obj-y +=3D intc=2Eo
>  obj-y +=3D irq=2Eo
>  obj-y +=3D kernel=2Einit=2Eo
>  obj-y +=3D mm=2Eo
> +obj-y +=3D mmio=2Eo
>  obj-y +=3D p2m=2Eo
>  obj-y +=3D paging=2Eo
>  obj-y +=3D pt=2Eo
> diff --git a/xen/arch/riscv/domain=2Ec b/xen/arch/riscv/domain=2Ec
> index 4db9c28662=2E=2E1e6f0ef66c 100644
> --- a/xen/arch/riscv/domain=2Ec
> +++ b/xen/arch/riscv/domain=2Ec
> @@ -12,6 +12,7 @@
>  #include <asm/cpufeature=2Eh>
>  #include <asm/csr=2Eh>
>  #include <asm/intc=2Eh>
> +#include <asm/mmio=2Eh>
>  #include <asm/riscv_encoding=2Eh>
>  #include <asm/vtimer=2Eh>
> =20
> @@ -308,6 +309,9 @@ int arch_domain_create(struct domain *d,
>      if ( (rc =3D p2m_init(d, config)) !=3D 0)
>          goto fail;
> =20
> +    if ( (rc =3D domain_io_init(d, MAX_IO_HANDLER)) !=3D 0 )


> +        goto fail;


> +
>      if ( (rc =3D domain_vintc_init(d)) )
>          goto fail;
> =20
> diff --git a/xen/arch/riscv/include/asm/domain=2Eh b/xen/arch/riscv/incl=
ude/asm/domain=2Eh
> index e035b33ddf=2E=2E15e8fa1968 100644
> --- a/xen/arch/riscv/include/asm/domain=2Eh
> +++ b/xen/arch/riscv/include/asm/domain=2Eh
> @@ -9,6 +9,7 @@
> =20
>  #include <asm/cpufeature=2Eh>
>  #include <asm/guest-layout=2Eh>
> +#include <asm/mmio=2Eh>
>  #include <asm/p2m=2Eh>
>  #include <asm/vtimer=2Eh>
> =20
> @@ -101,6 +102,8 @@ struct arch_domain {
>      const unsigned long *isa;
> =20
>      struct vintc *vintc;
> +
> +    struct vmmio vmmio;
>  };
> =20
>  #include <xen/sched=2Eh>
> diff --git a/xen/arch/riscv/include/asm/mmio=2Eh b/xen/arch/riscv/includ=
e/asm/mmio=2Eh
> new file mode 100644
> index 0000000000=2E=2E18df1133e6
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/mmio=2Eh
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2=2E0-or-later */

According to coding style, it should be GPL-2=2E0-only=2E

> +#ifndef RISCV_MMIO_H
> +#define RISCV_MMIO_H
> +
> +#include <xen/lib=2Eh>
> +#include <xen/rwlock=2Eh>
> +
> +#define MAX_IO_HANDLER  16
> +
> +typedef struct {
> +    paddr_t gpa;
> +    unsigned int len;  /* access width in bytes (1, 2, 4, 8) */
> +    bool is_write;
> +    register_t data;   /* store: value to write; load: value read (set =
by handler) */

Nit: line too long (85)

> +} mmio_info_t;
> +
> +enum io_state
> +{
> +    IO_ABORT,       /* The IO was handled and led to an abort=2E */
> +    IO_HANDLED,     /* The IO was successfully handled=2E */
> +    IO_UNHANDLED,   /* No handler found for the IO=2E */
> +};
> +
> +typedef enum io_state (*mmio_read_t)(struct vcpu *v, mmio_info_t *info,
> +                                     register_t *r);
> +typedef enum io_state (*mmio_write_t)(struct vcpu *v, mmio_info_t *info=
,
> +                                      register_t r);


> +
> +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;
> +    unsigned int max_num_entries;
> +    rwlock_t lock;
> +    struct mmio_handler *handlers;


> +};
> +
> +enum io_state try_handle_mmio(mmio_info_t *info);

> +void register_mmio_handler(struct domain *d,
> +                           const struct mmio_handler_ops *ops,
> +                           paddr_t addr, paddr_t size);
> +int domain_io_init(struct domain *d, unsigned int max_count);
> +void domain_io_free(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=2Ec b/xen/arch/riscv/mmio=2Ec
> new file mode 100644
> index 0000000000=2E=2E7d56bc8b27
> --- /dev/null
> +++ b/xen/arch/riscv/mmio=2Ec
> @@ -0,0 +1,145 @@
> +/* SPDX-License-Identifier: GPL-2=2E0-or-later */
Should be GPL-2=2E0-only=2E
> +/*
> + * Copyright (C) Vates
> + */
Why have you included a copyright notice here, but not in the other
files? I don=E2=80=99t know if you can keep it, but I just wanted to point=
 out
that there are other files where this type of copyright notice includes
the year=2E

--=20
Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>


-- 
Baptiste Le Duc | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.2039.d3a9d985718257a9.19fec268bf5.69e8bf0c8ca29046=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 14:51:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 14:51:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387569.1628833 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRLt-0005ha-IH; Mon, 10 Aug 2026 14:51:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387569.1628833; Mon, 10 Aug 2026 14:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRLt-0005hT-Ff; Mon, 10 Aug 2026 14:51:45 +0000
Received: by outflank-mailman (input) for mailman id 1387569;
 Mon, 10 Aug 2026 14:51:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec2874e4000e099@swg.vates.tech>)
 id 1wtRLs-0005hN-6B
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 14:51:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtRLr-006Ghm-JO
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:51:43 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec2874e4000e099@swg.vates.tech>)
 id 6a79e56c-bab6-0a2a0a5309dd-0a2a4506bcdc-38
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:51:43 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec2874e4000e099@swg.vates.tech>)
 id 6a79e57f-195a-0a2a45060019-b9ff1c22a46d-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 16:51:43 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec2874e4000e099.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 14:51:42 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8D79083700;
 Mon, 10 Aug 2026 16:51:41 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=oh2DgB3SGnmWnc2owIE3IXRTnj2Ospz9Wo6bD61coCI=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=Yxq0k2NkBG/y6/LnMmUtoLQlYXSzEbNlFcxyWo2V81C4swoHO7E1K1e/ewl0IK+wZvPuzb/87
 5aKTb9qtTBt9+ssfl9/MR1NZFx4/BHMe1eQ73DTZu/rpHDxMgxYiXpSqfeLIarEdI9smRHlAHP0
 qAQzBEcXhmR7U9MHoM3/2POMhwpJcurI5kfM8EpAHneFU1IQ1JMR81A/ZXprYVaIufmn2DEh9qP
 8NTUyczUE/z+Vergwi7OeHFlNTPGhDQGDF+51zxKj1VF/zUWxJCY++9I8n2pRrKJ2oVmxpXO2ln
 fJZ/i0wo8U+PIRluzvEC5klb10qMNxFEevz/M8HzcKwg==
X-Zone-Loop: 7c266bd4a239a061645f15bae85c0dec40ef71421f58
x-campaign-type: default
x-transaction-id: f8fdb848-13b6-4ca6-9b1c-6c2355ef87f4
x-swg-uid: 01-ea7f7148-5ec1-4575-a726-5ff57c40b051
X-Mailer: Sweego
Message-ID:
 <1786373502.8631fc262581453bbf619ec5b2062170.19fec2874e4000e099@vates.tech>
x-swg-bid: 1786373502.8631fc262581453bbf619ec5b2062170.19fec2874e4000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Subject: Re: [PATCH v1 03/17] xen/riscv: add missing APLIC register
 offsets, masks to asm/aplic.h
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <b1e6363b-2012-44fe-9aa9-3d0f049f0b69@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <ee3825adfd0012437a594f6a0e51c6ee71175cc4.1784560663.git.oleksii.kurochko@gmail.com>
 <1786369533.8631fc262581453bbf619ec5b2062170.19febebe536000e099@vates.tech>
 <b1e6363b-2012-44fe-9aa9-3d0f049f0b69@gmail.com>
Date: Mon, 10 Aug 2026 16:51:36 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786373501; l=1226;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=pX3pIsTRAJ2uAndkfmMJyp9wTrk95aLN1X+NZ0w8Kss=;
 b=EaiCKGGunu/86m+j2fMlnTVPNsbjQbBrvKECZnFYfMrCb5ZStVfupaQcICKo6v08UUMPM2aiq
 aM+mRefYqwPA1RKVqZmNr3pXWumVMgLRI8N3JIY3ZYQouTr5YdwZvWp
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.203c.e671b9931e088f51.19fec287342.7804da051366af2a=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786373501762
X-purgate-ID: tlsNG-16d1c6/1786373503-FEA7477B-10D815E7/0/0
X-purgate-type: clean
X-purgate-size: 1642

---=Part.203c.e671b9931e088f51.19fec287342.7804da051366af2a=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 2026-08-10 16:45:23+02:00, Oleksii Kurochko wrote:
> On 8/10/26 3:45 PM, Baptiste Le Duc wrote:
>=20
> >> These definitions are required for correct decoding of APLIC MMIO
> >=20
> > _REG stands for memory-mapped control "region" as explained in spec? I=
f
> > yes, it'd be better to add a comment=2E
>=20
> Yes, it is a mask that allows us to get the offsets for the registers of=
=20
> an interrupt domain=E2=80=99s memory-mapped control region=2E
>=20
> IMO, if the problem is with the name of the macro, it would be better to=
=20
> use a clearer name instead of adding a comment=2E For example,=20
> `APLIC_CTRL_REGION_OFFSET_MASK` sounds self-explanatory to me=2E

I think the rename of the macro is enough=2E
Lets keep this:

#define APLIC_CTRL_REGION_OFFSET_MASK   0x3fff

>=20
> If you=E2=80=99re still not happy with the suggested name and it isn't=
=20
> self-explanatory, then:
>=20
> /*
>   * Offsets of the registers of an interrupt domain's memory-mapped cont=
rol
>   * region, which is APLIC_MIN_SIZE bytes large=2E
>   */
> #define APLIC_CTRL_REGION_OFFSET_MASK   0x3fff
>=20
> Alternatively, I could keep the old name (APLIC_REG_OFFSET_MASK) and use=
=20
> the suggested comment=2E
>=20
> Which option do you prefer?
>=20
> ~ Oleksii




-- 
Baptiste Le Duc | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.203c.e671b9931e088f51.19fec287342.7804da051366af2a=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 15:05:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 15:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387579.1628843 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRYW-0007b8-KA; Mon, 10 Aug 2026 15:04:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387579.1628843; Mon, 10 Aug 2026 15:04:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtRYW-0007b1-H2; Mon, 10 Aug 2026 15:04:48 +0000
Received: by outflank-mailman (input) for mailman id 1387579;
 Mon, 10 Aug 2026 15:04:46 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtRYU-0007av-Oh
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:04:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtRYT-003qFa-O0
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:04:45 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79e883-8faa-0a2a0a5109dd-0a2a450aafe0-48
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:04:45 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79e88d-f2d2-0a2a450a0019-d1558029a806-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:04:45 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4980fe6b3beso31576355e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 08:04:45 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4995420bd1csm441680165e9.3.2026.08.10.08.04.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2026 08:04:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786374285; x=1786979085; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=skTb9mvllojkrjztHhBL1PK1ndFafhM1LatERGnQ4Fg=;
        b=qKFRnzlqlpR0qTaa6/gwyMv89LUAPHW5ZIyNT0eLlaGIQfpZ2YgKYyWxnWXW4TZyaA
         zOK9rdcumyTFR+nWjN2zhRXhDhXeHj4bC8Z9nz11IS1hpOaytiB2gVweAhGVDAWv4Cvt
         Tbl14Rk54e8tT8bHFIoMZF5eQo6TdEQXhJw8tMqL5lrm7Hiz2ibtcBtO4WNlRuJfWHOX
         3BApc2uI24RgDIJ+MBm9LJ29Fsa4KcOSR9zHf8rbb/qRKhmEJwjTLXejIBllKx9oEIUl
         IbB9FOKtdWKgQg6nqQDaF9yB0LbTGWr8n5X3KoL14dFtcqIUtpI+aA6GcUJPIo7EB46P
         Q8wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786374285; x=1786979085;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=skTb9mvllojkrjztHhBL1PK1ndFafhM1LatERGnQ4Fg=;
        b=IU/egJf5m3pwV6q/MlELzaePYE+6yZL5ujErFBNVzPo+OMeMo4tl+rxWXNc0E9AWYi
         xUQJ8siqOQMVfn2INGp2Y67Zo5lXXwpg6atVi0TMTBZcdd5FQkaL922GdIi7jE7OAnaT
         ZubFlPixz9pcNECRixjopOKDtIlokH/WcLw1UFb2fArPKY5QxMLdt+NC10aeBaeRUKTO
         CHxtNM6bU4Dooz0jj7hN+bg0S/bhf5o8kDZALRSUKEsIREf/Gmv284Uy0UVwaPrl3gCy
         u+qGUPGt5TBA5vQ6J9Ppir2ZjEQCeH+0FBvWx3/3hu2eclB9eB5EDW5a8ESd2wzMn7kW
         mInA==
X-Gm-Message-State: AOJu0YzG+o8i3GhWOzfMEfGYVFm/mtQwIe0sBkeRMCDal4L5Tm9R2fR3
	2K2skqj9tlp0VxNgM51+7X973HM1Y163M4TuxGbvU6cr8NLPf+llRECX
X-Gm-Gg: AR+sD12CAbceWdfhQqI/klZ/4Wp9RHeOQOljFw44b0iAci/W9Wu2jibJ4GC6Pmn9Jt2
	2PeMwLHJH+iD15zFeOm0N9ngqa53aqRVC/llJDcJvv6TSLBVUCvEUN3Z/O7ZMN9g+LV9Uu1Jx7n
	93uE8stYZpTw9d9sx1v6reUNdHcJTNY9EB/qCZFrPURaKWqFCHyfMg8Ig760Xv0VL7bUQl4VLSM
	z66m39YL5R39tDdATvuDeOb6oK1FT+2f6t5JZUh6T6TvNubpdham5DR+2wc+MZVg1QezDM4KfGZ
	0T3LqkKfMqDpnT+UfC4M8XxgfHR45aRZrh6XGLU8vidr3+2yulLVcCaZiOyAFf2JFQCmevZdDjp
	U1k3kuZPjabkBvU7ySeiXQFG6ucAJhClAi5MDsEaO6Mh+RmTRw/wELwp+BxpvbPp2ViG/7kX6me
	ZixoA7LE9QZof79Uxz/dwi39LhW/4d8/FGAgGHgqY9x8aUX8WlX+pe1HdI6joR805Eio6JpupK3
	lWQ0I3omNwIAmYIlm502FDeF9InLrz+el00MomdRac=
X-Received: by 2002:a05:600c:45d5:b0:495:69eb:27d3 with SMTP id 5b1f17b1804b1-4996247a563mr23707995e9.8.1786374284985;
        Mon, 10 Aug 2026 08:04:44 -0700 (PDT)
Message-ID: <293a08d8-ff96-4726-b713-bc2d14973ca4@gmail.com>
Date: Mon, 10 Aug 2026 17:04:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 02/17] xen/riscv: add basic VGEIN management for AIA
 guests
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b141b8d976719bb9b76147cacfd5842fb7aac74e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786368748.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786368748.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786374285-53CD3CFC-7EC80455/10/73395122804
X-purgate-type: spam
X-purgate-size: 9889



On 8/10/26 3:32 PM, Baptiste Le Duc wrote:
>> It was decided to add support for IMSIC from the start instead of having APLIC
>> operate in direct delivery mode, as it requires a trap-and-emulation approach,
>> 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.
>>
>> Add 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. When assigning a VGEIN, the corresponding value
>> is written to the VGEIN field of the guest hstatus register so that
>> VS-level external interrupts are delivered from the selected interrupt
>> file.
>>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c
>> index e31c9c2d24..4f7f46f58f 100644
>> --- a/xen/arch/riscv/aia.c
>> +++ b/xen/arch/riscv/aia.c
>> @@ -1,11 +1,33 @@
>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>   
>> +#include <xen/bitmap.h>
>> +#include <xen/cpu.h>
>>   #include <xen/errno.h>
>>   #include <xen/init.h>
> 
> Add a #include <xen/percpu.h> here instead of in aia.h.

Sorry, but I’m a little confused here. <asm/aia.h> doesn’t include 
<xen/percpu.h>.

> 
>>   #include <xen/sections.h>
>> +#include <xen/sched.h>
>> +#include <xen/spinlock.h>
>>   #include <xen/types.h>
>> +#include <xen/xvmalloc.h>
>>   
>> +#include <asm/aia.h>
>>   #include <asm/cpufeature.h>
>> +#include <asm/csr.h>
>> +#include <asm/current.h>
>> +
>> +struct vgein_ctrl {
>> +    unsigned long bmp;
>> +    spinlock_t lock;
>> +    struct vcpu **owners;
>> +    /* The least-significant bits are implemented first, apart from bit 0 */
>> +    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);
>>   
>>   static bool __ro_after_init _aia_usable;
>>   
>> @@ -14,10 +36,133 @@ bool aia_usable(void)
>>       return _aia_usable;
>>   }
>>   
>> +static int vgein_init(unsigned int cpu)
> 
> Could we call this function with a different cpu arg than the current
> one running? If yes, we would read hgeie of not the cpu we wanted.

Considering that it touches the CSR_HGIEI register, it can only be 
called on the currently running CPU.

That’s why I suggested in one of my replies to Jan B. that I would drop 
the argument altogether for this function.

>> +{
>> +    struct vgein_ctrl *vgein = &per_cpu(vgein, cpu);
>> +
>> +    csr_write(CSR_HGEIE, -1UL);
>> +    vgein->geilen = flsl(csr_read(CSR_HGEIE) >> 1);
>> +    csr_write(CSR_HGEIE, 0);
>> +
>> +    printk("cpu%u.geilen=%u\n", cpu, vgein->geilen);
> 
>> +
>> +    if ( !vgein->geilen )
>> +        return -EOPNOTSUPP;
>> +
>> +    vgein->owners = xvzalloc_array(struct vcpu *, vgein->geilen);
>> +    if ( !vgein->owners )
>> +        return -ENOMEM;
>> +
>> +    spin_lock_init(&vgein->lock);
>> +
>> +    return 0;
>> +}
>> +
>> +static int cf_check cpu_callback(struct notifier_block *nfb, unsigned long action,
>> +                        void *hcpu)
>> +{
>> +    unsigned int cpu = (unsigned long)hcpu;
>> +    int rc = 0;
>> +
>> +    switch ( action )
>> +    {
>> +    case CPU_STARTING:
>> +        rc = vgein_init(cpu);
>> +        if ( rc )
>> +            printk("AIA: failed to init vgein for CPU%u\n", cpu);
>> +        break;
>> +    }
>> +
>> +    return notifier_from_errno(rc);
>> +}
>> +
>> +static struct notifier_block cpu_nfb = {
>> +    .notifier_call = 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 = vgein_init(0)) )
> 
> Why `0` rather than smp_processor_id()? As described above vgein_init() reads CSR_HGEIE
> of the current hart but stores the result into per_cpu(vgein, cpu), so the two
> must agree.

aia_init() is executed on boot cpu only so it uses 0 as Xen boot cpu is 
always 0. But it won't be an issue anymore as I mentioned above an 
argument of vgein_init() will be dropped anyway so it will be guaranteed 
that a correct CPU is used.

> 
>> +    {
>> +        dprintk(XENLOG_ERR, "vgein_init() failed: %d\n", rc);
>> +        return;
>> +    }
>>   
>>       _aia_usable = true;
>> +
>> +    register_cpu_notifier(&cpu_nfb);
>> +}
>> +
>> +unsigned int vgein_assign(struct vcpu *v)
>> +{
>> +    unsigned int vgein_id;
>> +    struct vgein_ctrl *vgein = &per_cpu(vgein, v->processor);
> 
> What happens if v->processor change between vgein_assign() and
> vgein_release? Because it seems in such case the release will hit a
> different pCPU's bitmap: the original bit will leak and an unrelated
> CPU's bit will be cleared under another vCPU's feet.

So, if v->processor changes between the calls to vgein_assign() and 
vgein_release(), it means that migration has happened. If migration has 
happened, then it is the responsibility of the migration code to 
properly assign the new vgein and release the previous one.

All other cases where vgein_release() is called are when the vCPU is 
dying, so everything is okay there as migration cannot happen.


> 
>> +    unsigned long *bmp = &vgein->bmp;
>> +    unsigned long flags;
>> +
>> +    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 interrupts
>> +     * 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 interrupts.
>> +     *   VGEIN is a WLRL field that must be able to hold values between zero
>> +     *   and the maximum guest external interrupt number (known as GEILEN),
>> +     *   inclusive.
>> +     *   When VGEIN=0, no guest external interrupt source is selected for
>> +     *   VS-level external interrupts.
>> +     *
>> +     * So start to search from bit number 1.
>> +     */
>> +    vgein_id = find_next_zero_bit(bmp, vgein->geilen + 1, 1);
>> +
>> +    if ( vgein_id > vgein->geilen )
>> +        vgein_id = 0;
>> +    else
>> +    {
> 
> Potential index error, because above you did:
> 
>      vgein->owners = xvzalloc_array(struct vcpu*, vgein->geilen)
> 
> so valid index are 0...(vgein->geilen-1). Adopt either
> one of those two options:
>      1. vgein->owners[vgein_id-1] = v
>      2. vgein->owners = xvzalloc_array(struct vcpu *, vgein->geilen+1) in
>         vgein_init()
> 
> I think `2` could be better to have vgein->owners replicated hgeie CSR but
> it would left the first entry read-only.

I've found that too during prepare a reply to Jan B. so fixed it already 
in v2. I've decided to go with what you suggested in 2.

> 
>> +        __set_bit(vgein_id, bmp);
>> +        vgein->owners[vgein_id] = v;
>> +    }
>> +
>> +    spin_unlock_irqrestore(&vgein->lock, flags);
>> +
>> +#ifdef VGEIN_DEBUG
> 
> VGEIN_DEBUG is not defined anywhere in the patch, please use
> gdprintk(XENLOG_DEBUG, ...) directly, or drop this branch.

It is intentionally not defined. If a user needs additional VGEIN debug 
information, they should define it themselves, as it can produce a 
pretty large amount of logs due to, for example, the migration process, 
where vgein_assign() and vgein_release() are used quite actively.

> 
>> +    gprintk(XENLOG_DEBUG, "%s: %pv: vgein_id(%u), xen_cpu%u_bmp=%#lx\n",
>> +           __func__, v, vgein_id, v->processor, *bmp);
>> +#endif
>> +
>> +    return vgein_id;
>> +}
>> +
>> +void vgein_release(struct vcpu *v, unsigned int vgein_id)
>> +{
>> +    unsigned long flags;
>> +    struct vgein_ctrl *vgein = &per_cpu(vgein, v->processor);
>> +
>> +    if ( !vgein_id )
>> +        return;
>> +
>> +    spin_lock_irqsave(&vgein->lock, flags);
>> +    __clear_bit(vgein_id, &vgein->bmp);
>> +    vgein->owners[vgein_id] = NULL;
>> +    spin_unlock_irqrestore(&vgein->lock, flags);
>> +
>> +#ifdef VGEIN_DEBUG
>> +    gprintk(XENLOG_DEBUG, "%s: vgein_id(%u), xen_cpu%u_bmp=%#lx\n",
>> +           __func__, vgein_id, v->processor, vgein->bmp);
>> +#endif
>>   }
>> diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h
>> index aaa4bf91fc..c67be0069a 100644
>> --- a/xen/arch/riscv/include/asm/aia.h
>> +++ b/xen/arch/riscv/include/asm/aia.h
>> @@ -3,8 +3,16 @@
>>   #ifndef RISCV_AIA_H
>>   #define RISCV_AIA_H
>>   
>> +#include <xen/percpu.h>
> 
> asm/aia.h needs neither <xen/percpu.h> nor <xen/spinlock.h> as struct
> vgein_ctrl and the per-CPU variable both live in aia.c. Please drop them
> and add <xen/percpu.h> in aia.c
> 

Yes, it is redundant code that I missed removing. I’ve already noticed 
it and removed it in v2.

Thanks.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 15:37:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 15:37:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387594.1628853 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtS3g-00040L-1D; Mon, 10 Aug 2026 15:37:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387594.1628853; Mon, 10 Aug 2026 15:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtS3f-00040D-TQ; Mon, 10 Aug 2026 15:36:59 +0000
Received: by outflank-mailman (input) for mailman id 1387594;
 Mon, 10 Aug 2026 15:36:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtS3f-000406-7K
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:36:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtS3e-0008Z4-KM
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:36:58 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79f00c-8faa-0a2a0a5109dd-0a2a4502d55e-26
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:36:58 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a79f01a-6ca4-0a2a45020019-d1558034e947-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:36:58 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4955de8797cso13750495e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 08:36:58 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499740c1e65sm1464585e9.4.2026.08.10.08.36.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2026 08:36:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786376218; x=1786981018; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Nt96e5JrhJ37b+v36cltLHlfFI5f1cPCJ8WVk3Ws90Q=;
        b=ApNhojU0wAfZm7igbZOBXK7zC4xOddYjslB/BTguXJAU4xQpmOcU90sECLaYlXTHCN
         qzQjJGfUDaFom9zR20PoLTp48pMZml1TvZegtTKEQCObqtK86OoOT/0yE7L02Wti7GjM
         oIYi5zb1BB/ktdpyrZNjDLykBkFj7NdbVkGvi7TA/cqYt6CorJhmBBPK4AMpJTgSuTkQ
         ctz+0CVhByWpKbxX+XZ3R/MspZ3Xv/Ot+UK8hQafxV5zy72qNpZNFbxwTYyKw7d4lhBK
         e92LxYhFozDC1SqBRzLuwe5Yr2vkqQJ5bSNmWx9wiQE+tChOBYjTo2W+bkkqYI5KHD4N
         9fng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786376218; x=1786981018;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Nt96e5JrhJ37b+v36cltLHlfFI5f1cPCJ8WVk3Ws90Q=;
        b=nRoHgNcZGldvNCB7f5FPBPLr4vsjes6q0/vDOSvrUOn6kGTR40PbJRA5j3HOt1j/lx
         pEcqQGj/wKs3lXfSu2uhZ41rZLxQleUtJNgzZvHu6IqjV8Ya5DF+x4yn82B0a8wO20fA
         0ThXlWaZe051tDpSV7fWxKXwz8gwbAh9gjM2NYD7t1ohMfwkfDlSxWlWEsa3aaz2Q163
         YttGbYHWgHZnsx077TLJkro8lpFuyacBju1uMz2ZRWz8GzX1bmZ8BYWkvjmEyImEXJcV
         +0foGGuMVPFpY6Yd0NODK37+NXkrOZjmnK4wsHIGZ+KBo/RNp5V05pgIKTKhFnIoNo6T
         6WJA==
X-Gm-Message-State: AOJu0YzzsKdd76Bfz/Zq6QquEh0yfBwFwQxmRTciNGn3YzgG+lRh2+MD
	r3doU7+5NWnbSre/uwI6l76IfwxxEBaNhTxOcmAe5m7F7I6U50NHei1p
X-Gm-Gg: AR+sD10VpZDdjufcEkch5j3S9M2/cTnY2Em1HbAQ44vvNnwVgD6GdKWqmZd6C1SDmF3
	yQ2jMLMz+kH+GozYcx8Mm+X899NXXhQ5u7pAC4c/rIrReBprhqRsdvUGmQhsKlASigQ5V90C252
	tqWuD/kB5R9VjENCujbEQis9qtVHRZm2tbTz2PEBWZKiG0yC8+MM3Cyn3CvozgtFsoD8OG/jdZC
	trWWOTNEj5SAAJkL/cML6jA6BVyCruh3f+ol+S7PmKn3zKiVrgvsNveVcQXiaHvGLmCBKya1SNm
	UdmQPMchWfm6oaBbukCznaMEy/yEPrPFvU+pt7ZzXo9AOhPsSG/UwQGjejbA12qNp8zz8Lra1nt
	tASZECf3rFnXs9Aqco4MYjLGoUbv3fQQmjPf0jx9on8RorYyJLdPf4YFDOIp+cJrsZ+cbbV4qp+
	3egs0OXSVBbAunHKpZjVN2UE/EJEpxKI+Adg7XXYRu/jf6fU1biCExD9dGCcLSjZGkGgInaJXA/
	2AuAq+Mu6gju0Vm6pxCPWebUkaPnNKrxAU9eeFMFEg=
X-Received: by 2002:a05:600c:c050:b0:493:a613:56b2 with SMTP id 5b1f17b1804b1-4995e08e537mr216929085e9.8.1786376217831;
        Mon, 10 Aug 2026 08:36:57 -0700 (PDT)
Message-ID: <05283ea0-de82-4160-a3f9-5fc1292a20a5@gmail.com>
Date: Mon, 10 Aug 2026 17:36:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1786376218-666B72AC-03B528EE/10/73395122804
X-purgate-type: spam
X-purgate-size: 2760



On 8/10/26 4:49 PM, Baptiste Le Duc wrote:
>> diff --git a/xen/arch/riscv/include/asm/mmio.h b/xen/arch/riscv/include/asm/mmio.h
>> new file mode 100644
>> index 0000000000..18df1133e6
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/mmio.h
>> @@ -0,0 +1,63 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> 
> According to coding style, it should be GPL-2.0-only.

Could you please point me to the line in the coding style document where 
this is mentioned?

If you are referring to:
   New files should start with a single-line SPDX comment to express the
   license, e.g.:

   /* SPDX-License-Identifier: GPL-2.0-only */

   See LICENSES/ for a list of licenses and SPDX tags currently used.

Then my understanding is that /* SPDX-License-Identifier: GPL-2.0-only 
*/ is used only as an example, and I can choose any license from 
LICENSES/. There, it is mentioned:
   Valid-License-Identifier: LGPL-2.0-only
   Valid-License-Identifier: LGPL-2.0-or-later

I am pretty sure that I am free to choose any license that does not 
conflict with the other licenses used in the project.

>> +#ifndef RISCV_MMIO_H
>> +#define RISCV_MMIO_H
>> +
>> +#include <xen/lib.h>
>> +#include <xen/rwlock.h>
>> +
>> +#define MAX_IO_HANDLER  16
>> +
>> +typedef struct {
>> +    paddr_t gpa;
>> +    unsigned int len;  /* access width in bytes (1, 2, 4, 8) */
>> +    bool is_write;
>> +    register_t data;   /* store: value to write; load: value read (set by handler) */
> 
> Nit: line too long (85)

I will apply that. Actually I've already fixed that by putting the 
comment above:
   /* store: value to write; load: value read (set by handler) */
   register_t data;


>> diff --git a/xen/arch/riscv/mmio.c b/xen/arch/riscv/mmio.c
>> new file mode 100644
>> index 0000000000..7d56bc8b27
>> --- /dev/null
>> +++ b/xen/arch/riscv/mmio.c
>> @@ -0,0 +1,145 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> Should be GPL-2.0-only.

Regarding license I've wrote a comment above so lets continue discussion 
there.

>> +/*
>> + * Copyright (C) Vates
>> + */
> Why have you included a copyright notice here, but not in the other
> files? 

So I just decided to do that for new files as I am not using corporate 
e-mail.

I don’t know if you can keep it,

Good point, I have to ask then someone from our legal department...

  but I just wanted to point out
> that there are other files where this type of copyright notice includes
> the year.
> 

Before, I used to include the year, but someone pointed out (or perhaps 
I misunderstood) that there isn’t much point in including it and that it 
is enough to have just (c) <company name>.

Thanks.

~ Oleksii





From xen-devel-bounces@lists.xenproject.org Mon Aug 10 15:40:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 15:40:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387602.1628860 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtS75-0005l9-G8; Mon, 10 Aug 2026 15:40:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387602.1628860; Mon, 10 Aug 2026 15:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtS75-0005l2-DJ; Mon, 10 Aug 2026 15:40:31 +0000
Received: by outflank-mailman (input) for mailman id 1387602;
 Mon, 10 Aug 2026 15:40:30 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Stewart.Hildebrand@amd.com>) id 1wtS74-0005kw-5v
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:40:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtS73-0098Dt-33
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:40:29 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a79f0eb-8faa-0a2a0a5109dd-0a2a4507aa5c-6
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:40:28 +0200
Received: from [52.101.57.56]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a79f0eb-b4ea-0a2a45070019-34653938efdf-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:40:28 +0200
Received: from DM4PR12MB6472.namprd12.prod.outlook.com (2603:10b6:8:bc::7) by
 LV3PR12MB9439.namprd12.prod.outlook.com (2603:10b6:408:20e::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 15:40:25 +0000
Received: from DM4PR12MB6472.namprd12.prod.outlook.com
 ([fe80::4a4d:4208:3862:fb7a]) by DM4PR12MB6472.namprd12.prod.outlook.com
 ([fe80::4a4d:4208:3862:fb7a%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 15:40:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tiipi1qKGKHbHC7MFEX9/lXtkyks5yGkPFq5xazp5UdaqNu+Sj78hKxTLEGmbVYs9XJ9KlbWHA9hZZu8DIW5YLHXfHJiaz8FhKSGAY2XnU9YBbkysZxBdqGA4Z2RM5iKizLXyN3j9r0ijfDHKbGbOTf4NGw+ampk4ZHqc3qI73WTHXQ2adzuPFF0LY5nnQumzlUpFPf2bV/ZLjivgPSa34DwB1UcfBJpz/pRPVxPvaemdMIF0EB4jRK2DZpx4HoiAoZOAxEz00VDedXGpM2ZrThwv4IfACmayqR7D1YcozRWLMS0vDxBNc6BiyVeBtAm2xodSl5fHo9AMGPj/q6CxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JLQH6i+1RsBXNMnLQnCymGu9+MWr54FLe3zoM/hw45o=;
 b=fZy6xoGPH9CD0a3bqTCNdbPARgjA9Htu5NRUzuaSOABpzH2AUMGxFj7gpYTMNCpzUMwzyXHrSwxVhzVDQPs7moh7ZbYiv/QQgIbnDyfqAGJZvS3ehtTHniZZgQn0oBYcX4zY/YqBdRS8Gkg95SL680PsoaZsEOWe+BsmvSSOSHtyn0dTKayI5Ix+QQSYCk/2FAGO8oaasuJfJAEFCC6TKd3QJDsQ9SiU5H+mPK8luEu5aXyG0u7FYVi0UnAkzmp8hL2hahRaDe5dXCB9eqm1sXhQoSm4EljRSMvZn455UhLPS1OCc+CEoqROwKPy7AtnKRANe0ffudUXzVw43GIqzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JLQH6i+1RsBXNMnLQnCymGu9+MWr54FLe3zoM/hw45o=;
 b=tfP61KIBOa2spXuLjZipld4ySrKWt2J4KTSCgACDp8ajq47l+tJx6ZmqQc8UwPw6FQrqqbR+7xPvOzMQAUrqbKzsTxIye4dMRj/52xB2Go1NBYOqYE4OCkoFZ1qhunpdr9hdFOzJWtJtUygWgVNCsGqg7pG2lkSoyBBfq3gqJHM=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <3a3267a3-01e9-419c-9d82-dd4867056732@amd.com>
Date: Mon, 10 Aug 2026 17:40:18 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86/pci: prevent cross-device accesses in
 pci_mmcfg_{read,write}()
To: Roger Pau Monne <roger@xenproject.org>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, Teddy Astie <teddy.astie@vates.tech>
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-2-roger@xenproject.org>
Content-Language: en-US
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
In-Reply-To: <20260806152619.23881-2-roger@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: CPCP307CA0007.DNKP307.PROD.OUTLOOK.COM (2603:10a6:380::7)
 To DM4PR12MB6472.namprd12.prod.outlook.com (2603:10b6:8:bc::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB6472:EE_|LV3PR12MB9439:EE_
X-MS-Office365-Filtering-Correlation-Id: b4a66409-c7e4-45ba-42c5-08def6f5b0d2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|18002099003|22082099003|11063799006|56012099006|3023799007|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	D5oSoCxy9edBa7t7iaUrgk6Zm0+ljEXAMMsEAhSWFio7GSTq/DNkrN9g26ibwGicrkuf/iK7FzqocPPDtOJq6NizMAxlHP+lPFgf6cSZE2kpIm6JYBorfGNYRt3T/s9fpX7CmmFIjQRTo/KpXHYUgYVwc7s9S2i+pu/ngHekS6bNgI7eekVZAaZrLBSoNmdxaTCwNnv714pmG3yia+pr6sxvVWNINiXnePs1ZQ9R9K5wxgiP/HZ/BjG4Lys+rEEpZzINgKW8H7PRci4elopOvO77RgJ8LSLKX6hHMkZ70zmmTQuQmilcoK3OkrTDghrI/Bh8J4UfqyFgmGTxVhSf4xxKNg657JGUmfrl4lTVhpJ00QSb+l907TLYpgHCR6myekamvlpJ75ZLcrusBVar2mzv51CQ1pGVyr0Ue3l8ADZlvTmXed09H6V1wcqc4b64Nwq3ssKL5f8UIyBUpEeNiBsGiN6ZpyZYY1CDPZSsAci6l3XfNNLGl6OTNsVatx3pE0OO0XIyFSNbiXj40OFld4jw/cpakBLqW6XcxDyCy7g8Vtnj5vgAgLVFcCEhiNf1ghW+vaBhQstTD5vEPGxv0QL0UK0b31dhmLkk6RagbUCgIBlbcgjrYMnizYsrE+bI6x8q7ZbOmbU+jxxbC26SfSaX0h3STOyd4nKC+jv2uVk=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB6472.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(3023799007)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VFhnSUtTaVFnMU5EeFhNUzMzbklsSDBJOHBVcHpNQVBNOElCSWtaM0wzb2Vw?=
 =?utf-8?B?VVVoVlliL0lRckxnbnlPTTBnbThrV053bWQrbmhPSi9KQzI1K2lsVU9rRU9Y?=
 =?utf-8?B?dkNKTTRwVlAvQ202dUVUR1ozZU5GNU1rVExYY0FrRjdObGk2K3lwa0tSK1Fv?=
 =?utf-8?B?RzZVYnpNdFhPT1F1bUZmakdFODdqM2xMd000S1U2c2dGODdCb3VEbVpUUU1Q?=
 =?utf-8?B?UkZtYkM0dVRpKzRoUE5EbDQvTkp3MVBoUk84MVVaOGNwT1UyMU9DRWZxY1NT?=
 =?utf-8?B?YmZZa2ZIUzVUOTNCbVVoM1AxejJReEc5NzFnOUVENFIwdlpGMXRDS3FTTHJp?=
 =?utf-8?B?c3hJZlc1bWE4cmdOWDh4ZnRUbDM2d2lLZ1lIeFpjR0FleVdEb28wdU96dzJu?=
 =?utf-8?B?eWJocFBJV2xFSHErWkM1Q2h0emZ3UnVkR2JyWWF0VTZTTDF6UHBqN1Z3Zmpz?=
 =?utf-8?B?ZGFUWjlhQ3FyV0I5cWUxeVpEcEZ4Z0N6Ykdnay9oQ2xFb1ZtSmp0NHYwVVBV?=
 =?utf-8?B?MExtUHFWVnNNQk8zc2kvUENOV0dxMHVnNVJncXRDd1ZjbnJyRlZhWXNBYUUv?=
 =?utf-8?B?cFEzZUYveHJGbWFvLzNPR0l5VVhvTnphcmdQd2ZqNFN2Z2p4cTBoNm5IWE9D?=
 =?utf-8?B?S1lpSG9WTXRzNDBQekpDd090MXBCeXU5S2gzejk0YmdNWjZoNXBoTWNYU1d3?=
 =?utf-8?B?Qis0SnFySThZakdITkZ0NzVoT3VHbE1WdFcxTkVPdURpNlN4MEZPb3gvMGhY?=
 =?utf-8?B?aHF4dFMwNmlSTmh5Yk91RjlMRzE2NkdGMFNCWWZNTzF3dUU3RFBBdk5QQTBt?=
 =?utf-8?B?THJHbXZWL3paMjBRWGo3VW1KN2xvRlArY2VhSmZRQzZLeUpUSjJJQmRuWXBk?=
 =?utf-8?B?TGNMbGF3SVdsRDhnWkRLVWtRVmRQaWNoN25XYU1LQ0dDM096SkNsb1pQQTA0?=
 =?utf-8?B?bjlkb0dyQmJ0eDluRnF5WDF3S2FKcE9rZzB2SC9Gcmk2RkhOWVlZb0E2VVg2?=
 =?utf-8?B?TTdqbmwyY29tUjNJeVh1RThjRzNaa3FVaVZ1bWVpcWh3VDRRWXVvSnI1azdj?=
 =?utf-8?B?em0wK0hlTUhDYlp0TkRDL3lvbXZjY2ZodlpUZUlBSDNTc2d5dUhGaUlIZVdn?=
 =?utf-8?B?cDJxZGRic1F2M1FEWUZDK3pDR3QvVmsydTFveEg2RmVTTVlNdHpQQWpVcldH?=
 =?utf-8?B?dGVleWZIRHkzNVJ2YmphMEdiTFV2cWdTNWQyVDM4SEY3eUpObm0rWWJySnpm?=
 =?utf-8?B?WGZ5OElMQkhNbW52azVXbUVvSmpTSGJSR0pRSzNZUnN2a3U5TlhqOHpDU1Nu?=
 =?utf-8?B?M29RZlk3aVZ2Wkc5eUxlTWFwMDl6RFYwbjFKQmFiMlJtRXJORkFvd2pDbzUz?=
 =?utf-8?B?ZnlISW1scHhmVGFNVzE5L2JkZUVMalJTdkdMVzI3WFFOdFhJWVRoWm9WbCt1?=
 =?utf-8?B?UTl4R3lYMVJpeVBuNU1rNi81bDFDTWVhZTdQL3F1YUJMK0xiYlVJeUNOOXVX?=
 =?utf-8?B?ckhXQjBoMU93bC9mdmpSeUg3YkJJOERnaTE5SXhCTHdsMkdlWVBBREtwQkR3?=
 =?utf-8?B?UVZwKzRCQXRpSUsxMXRXR01iQlpQVXdXbkRCM3UyRjc4RC9GaXV5Z2RqU1N1?=
 =?utf-8?B?Y2tMa055T0hPZk5ZZUdFczdaOVJxVWlNUFFkYTFaUk1IYlZvOExrOXUzc0ZX?=
 =?utf-8?B?Rzh4SzJ5TDZRQVREcEJjNzZRT3YraDhOb0xuekc4QzJNMUtqdnJzUU9wcC8w?=
 =?utf-8?B?cEFlNExVQ0xNRFphRER3SGMydGZBYzIzOHZYK0FadktrcTM5YlNLdEZHc0Vh?=
 =?utf-8?B?TGVobGRQelduWW1RSUpMVStoWGZGc1ZJT0REVWtWZFFGajRoditUNmoyL1Jj?=
 =?utf-8?B?cXY3Y3kydDAvSVNNWno3S3ptWmswYzNLbFg4OTF3T2o4b2xDdXV6eUhvSlE1?=
 =?utf-8?B?TTJsN3JVMlkwRHdNcDI0NmVyb0RxS2I4ZUNzeGlWdmRGdXZUbEhKeTZqSTQ5?=
 =?utf-8?B?M3kwL2dUeWVwRzhwaFhndGlMQWVsNWJHZmJEbm41M0FTem80TmJvRVhzNi9j?=
 =?utf-8?B?QzRnK1U3L0tBNjVPbUJiWHlhS2xXQ2t1aE5wb3dTeHNXMEQ1MnEvUm9XdFNY?=
 =?utf-8?B?cmtKWFFrUkdXUnpYNHBXTWdGWlRnSDR3UWt3YWNuNWlSazU2cjVrVWNpNXA0?=
 =?utf-8?B?dU1jWlNPZU9YZFV6T0swQlhJRCtDKzF3bHZEalNPSjNZVlAvVThnQWIvZ0Jh?=
 =?utf-8?B?cUlrRExXakMrM3lOYnBXOEJYRVZGbVV3TVVrWnpTdENFekloanp4aHEwQnND?=
 =?utf-8?B?dHFFNXVKOHdXZ2diL1NiYzA5Y2Y4T3lrc0NLQ0Y1YkhBSFh5cy9XQT09?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4a66409-c7e4-45ba-42c5-08def6f5b0d2
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB6472.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 15:40:22.8949
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 71eXWvjvt/PAnXEWqY6KapE6yQbpSABIRRX1lnoQRmYcL6PSz/31uLp0C6hKVEQFvw/LxPEDjL7F6so/sF8Sew==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9439
X-purgate-ID: tlsNG-ef75cf/1786376428-350CDAE4-5AD3C65B/0/0
X-purgate-type: clean
X-purgate-size: 258

On 8/6/26 17:26, Roger Pau Monne wrote:
> Introduce a specific check that prevents an accesses from spilling across
> two devices.
> 
> Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 15:41:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 15:41:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387609.1628871 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtS8O-0006ER-RW; Mon, 10 Aug 2026 15:41:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387609.1628871; Mon, 10 Aug 2026 15:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtS8O-0006EK-NT; Mon, 10 Aug 2026 15:41:52 +0000
Received: by outflank-mailman (input) for mailman id 1387609;
 Mon, 10 Aug 2026 15:41:52 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Stewart.Hildebrand@amd.com>) id 1wtS8N-0006EE-Tt
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 15:41:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtS8N-00ErSm-Ah
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:41:51 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a79f12b-bab6-0a2a0a5309dd-0a2a4509aaea-34
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:41:50 +0200
Received: from [52.101.201.14]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a79f13d-be1a-0a2a45090019-3465c90e8ff0-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:41:50 +0200
Received: from DM4PR12MB6472.namprd12.prod.outlook.com (2603:10b6:8:bc::7) by
 MN0PR12MB6054.namprd12.prod.outlook.com (2603:10b6:208:3ce::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 15:41:45 +0000
Received: from DM4PR12MB6472.namprd12.prod.outlook.com
 ([fe80::4a4d:4208:3862:fb7a]) by DM4PR12MB6472.namprd12.prod.outlook.com
 ([fe80::4a4d:4208:3862:fb7a%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 15:41:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jOeRiICe3BP3G+FrsYmqCglQP6oUN+t03VhmnVtkiuGhojVrOktgPumNCUyHT/u4XVJV+JSY4fQ8/I7LHCgPL6Koj4H3VEa617THlF3I53CTZZX3QkBMChBWNUqHRmPuKJ8bM9lyOjJh24Zua2Cfvyu63mKEL4ZWPE9zNrAFJbYAcHkahdgY9FyW39JGnVTGnJmKcEtWWDhYJsdt8p5vlCb9l/ACKMXuqbF7bhHq2Gt3ZuGwTY5V5JuMLqTrIEFEXh9h/yCrplRcQwqlhJM/wcW/eAmZQBiCgSK43RXrdaBIocXecHN0ObXq5ZDv10Q48Xg0HL7ssZthl0hXwTXJMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eycNA89dKo9QWALjfwVpOmoCniYD7R5v+ovAdxRCMFU=;
 b=FwZ56anSXG4WUDD0EEJo0H2+KgxjfZXd/QpyVNz6JCK/8ArR5DRL1ctvtBwkKJihW9rsMz604Ae3DYwacH058AChQATVVly57aotmmX1LJKlnlhrL+I9EfLVWgyvoaz1WBVmAAh8pdy04HIRt/QiXhvAMXw+xTMsg6UHp6w2Og3eJ1aE8NPuzVy5lhqcAfMJxNXFa5eIKkRjK1IHntD/P7fwRCML3mcEICa+yBi9Grx7mA909epBXxCa/vM/ss4fSnEsr+yAOODfOmoLlLMp7ZdXh5YhVsNqEp35m1rAgVxmhZyBwRaIboMuDTpTT6tMFEyGJABKGjGNIfN/9Y3WuA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eycNA89dKo9QWALjfwVpOmoCniYD7R5v+ovAdxRCMFU=;
 b=qIhpT0Dyz3Vs0vgAPMAlZVmg0+s9p9aJDnplOVSKxkp8AlA5KS0AXgRabJUagJVcqg5EifhSCsaa5zRdF+9IKgxfF7z2S42k2t/JU3JDwVS1DG1e+Kty5oGn/V9x1GnnRPqQ1Sw3uvZn4aapUwjVeAzF42Ta3zpKtrRWINXIUO0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <9191c840-5d9f-4780-a9f9-918459454cff@amd.com>
Date: Mon, 10 Aug 2026 17:41:40 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/vpci: allow unaligned accesses by the hardware
 domain
To: Roger Pau Monne <roger@xenproject.org>, xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, Jason Andryuk <jason.andryuk@amd.com>
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-3-roger@xenproject.org>
Content-Language: en-US
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
In-Reply-To: <20260806152619.23881-3-roger@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: CPCP307CA0002.DNKP307.PROD.OUTLOOK.COM (2603:10a6:380::15)
 To DM4PR12MB6472.namprd12.prod.outlook.com (2603:10b6:8:bc::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB6472:EE_|MN0PR12MB6054:EE_
X-MS-Office365-Filtering-Correlation-Id: 32963758-a488-47f3-e55b-08def6f5e1ce
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|18002099003|22082099003|11063799006|56012099006|6133799003|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	Tt8DrEBwWDHaZbiLNkaTcMtEK6yUQP+Xi5hV+hIXN+oBnTU0huTLQjrxbNv+P4d/ZlJdXPMyw4+LYFuckoIjnOvsSgu/AlynrkJxs/3dGBzBcpARpV13WQuUYI3Uoyz4E2iYyPRV441AKoJK4BEv9TAfB1HHvOYOeEoQ8h3JiK2OnIiqPf5j8LR6fKYZuv4Z308QBmQ3KJRwrZsqVUNIX72nad7G5KKdP2DVOWGXrbh3Y40mHgDRralNKAgB1vNFy+u7bmqnOBfedgpPiRMCssVYjw/vowgLmR3V0v3OP/AYXx5SonKTTKlDnfCIa653ownU87qQUpGk0vhzCVKGrYUU/V2NwVyWF9BiVDKkHL6CNn8kb5Pd97mOJ8FV+36mMTWL0FJLP55IKqyMwoLU2fs1wDrrhRR7e19S/TtCzmJ40tFl906rO/TbFa9rPHKzjKQSXqstLgYScbZSINII7tSug/CRbpyM89xx2OsRBAS7BTuMn5TS2MX/h4lKY6sk32j8Hz31Y1XPRBw+RrvicxWzCYQJfvCQSmE/6MTlU5l1gK5A1EHx6q5gZ4jQS5ZFD12qgl3FXVVlABy6+j+8sXiM/qr3QPRZd8Mv1Q631IQIWYjSJUCcNgULI0j+5UkCvgEZWZ4ttA/51XZzmF/QNPvou6Q8WVG2cvVW9/Nwy1k=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB6472.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(6133799003)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Tlg0ejJjbjA5eXhQYW1UT0JRK290TlJJK2RhaVUra2s2dUF1UzJVL3k1ZFpO?=
 =?utf-8?B?dThFMHVnSmVWblVId2E2NCtlNTRoV1U4bEEzdFpJT1JaQ0RLRlp2UlFPMUxk?=
 =?utf-8?B?UjJ1WkdSOWFENzdrSHZYdWdRTmJJTUlwV3JjTTdsNllEcVQ0QzhxWDBkRVNH?=
 =?utf-8?B?b0V6dzJjSXBNNEtPdzdoMHlrM0djRFZLMTJZSWdmdVVVWVh3d3pqRjdmU1l1?=
 =?utf-8?B?UE9KVlM2amNab0JmbzZGa2o1b2RFcS9SN0ZGRWJnYVNzdXA0NDVHeHBhVTJw?=
 =?utf-8?B?SWJOUzdzcDN0R2REOVg0U0tpRTI0a2N0TEtHc3o1bS9BYjkwdGdXR2lpSkVJ?=
 =?utf-8?B?MUlhcGtZZFhsSXRvZzEzSTJHVmw5R3F0QnpkN0hkS1hsZi9RNzUzMER6SDEv?=
 =?utf-8?B?cDdGVWh3UW1yeEhSS3R2RHFTdFVzWEhRdDF0aU45aDJnbjhucE8wdnZhVVc5?=
 =?utf-8?B?N2RJMkxPWHNtWHpxUlNEdGJ2UE54MktSaFNNbmdQRkx5cjRaNkEwUlluSWp4?=
 =?utf-8?B?MnY4S1R1TmEvTmRwZWxKZ1Y0ZHloOHYxOWNmUXNObTI5ZVUzQkJrWHBMUGEx?=
 =?utf-8?B?clozNjhKNmdjNS9ZaCsvY1p3bWZDOFRDQ3B6ZThvMFhOKzJjd2ErTUgvbnNx?=
 =?utf-8?B?N0d3MHJ0QWJJNDFqMGhGOGFHcTdEVTA5M2ttT3N4bk5WR2tRcU0xNDZVREZK?=
 =?utf-8?B?SFNqS3BrZFZTMnpPN0FRalZJMHNzUFFLdEFOMWI4OExDNXUzU1ZkVmFnbkRh?=
 =?utf-8?B?UWtFTGpzOFVFMFR3OUxsVEJxN1F2bFJlbDlmRFNVdFV6YzNwejRNb2tvWXZS?=
 =?utf-8?B?ZnZ5bGVNVnJaNDRsRnBYZ0VEM2xrYzdOd1FZaStFeE84R2pQOU1NV3M5Q1J5?=
 =?utf-8?B?L3hMRzkwL1VEMTdXV0l3TUhBRWtXVWl6NWxQWVA5eVRyNHZPZFRxYUNkZ21F?=
 =?utf-8?B?WEpmZG81MVFNYjlEUHlUalJDNmFPSzZxK3hhQnVQR2tDSXAzMTdrNnpydFdE?=
 =?utf-8?B?cFZXTjZRaHJJblJKamc4OXJleEpGU3Q3L2xtNFpBZUExWTFOaHBJRTdoYW4x?=
 =?utf-8?B?blpNaXhoc25sUWV6R1IvKzVtcVR4Z0dMRHFKTG9UMEdkR2lCM0w0a0xiWFhX?=
 =?utf-8?B?UHNXMkNWRjMrMFIzblJXZmhWRnNUdW90aGNrNlI5alBFb3hOSHNFYytZOUJx?=
 =?utf-8?B?NXBrUjJMcGRGRWV6WU9QN2ZFTDlrN09wci9EaGFyYUFVVURQa2xuWXJZTW4z?=
 =?utf-8?B?VjdieFBhSDNBSHhoRzROaWM0Z3BnVVBQWXcvMkFXaURoYXBJdndPaWlzTVg1?=
 =?utf-8?B?U2w2dnZESlhCclV3YjMzeEVic1hYL1ZyNFBDSFVLdHRmT1NXbUZqc2pQU2Za?=
 =?utf-8?B?MTFjS3o4allHS2prRlQ1VmhIYmN3SS95SU1XSkgrbFlkNW84dCtzcm5RcklB?=
 =?utf-8?B?T0hRcENHNTRBMldPQkpGTmRLZVczd3JCcUhPMXNzUXlYTmJ4d3dTRVhWY1V6?=
 =?utf-8?B?b0o4SUtYN0o1NDVNZTR2MExUcU16WUFtdVdtbC9sRzhLYU1vM3IzVFByQk94?=
 =?utf-8?B?anNKRnRtNHFFb1Ercm5WSi9wZVpQbWQ1eUlBd25VcmY2dGNJQWdWQkNDb3BP?=
 =?utf-8?B?OGY5cXBEOUlxcG1tZ2dTUllscWc5a283amx4aGNaNE45bEJORVBGc1ZhRFNw?=
 =?utf-8?B?L3RrSnhiYzZ1SUJuRTVwNDdmQ0wyRU8vYjRaN2hJclY3a2twNWFzSDJPamE4?=
 =?utf-8?B?dlN0b0pCS3BGTU1JRTVnZERnODRaSGpNM0gvWkppTmdDb0dnNWIrMjNWTUpt?=
 =?utf-8?B?ZWVrbU4wYUFPN251Tzl0QzRtYUtXcmNOYnZhU2tMMzVlcW9QVUtFd2lvWFIz?=
 =?utf-8?B?WXcwTVJkdmJzK05lekdIT3RPeWJTcndwQlJ6ZkRFL1RCNmFYYlRVWWpxWW5O?=
 =?utf-8?B?UUVEUnA0TzRLdTlSbGVlaERocWoxRjNPWmgzVVhxQnFmM2Vydm5LMGVvK1V3?=
 =?utf-8?B?TFhpc3dpalZmd0tkeFRpSk41dng0TEw2dEpYQ01iUnc4TDcxdUhhRHRrdUNi?=
 =?utf-8?B?cFE1aVF0Q1JlN2tLeGJYbGppUXlFNTNtY1lYM0J4UmNBUjhDd3ZEdFlyWE0y?=
 =?utf-8?B?c3gxamxPWlhJbm9BRE5ieU1tWGRMRFlKS1RxSGgwZzZ1K0FtNUExNkFhNytN?=
 =?utf-8?B?Qkl2QnMyY0NKRlZsNzhnOE9CZUdCTm5ISklNU1JaY0doSnJqZVVUdXFkYkVs?=
 =?utf-8?B?T1dkbmVsU01LdUxiN3ErRGpEZExOdW5NcUQwblJKcTY5b0lFNHBnYW1JUWlI?=
 =?utf-8?B?Uks0a29lQ3FJMWlPTEtHa0JDMEtpZDM2aUoreUtkSGt6cnh6T1pEUT09?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 32963758-a488-47f3-e55b-08def6f5e1ce
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB6472.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 15:41:45.1002
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ge29tHxVBQ4Qk6I50SD//CgDemzT3X0tzCwpDeeB5o2REGw36PoV9itEl0OhPMZMGC6P5gWbr3hemTQYmxRmUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6054
X-purgate-ID: tlsNG-bad1c0/1786376510-BC2F4034-DB415B39/0/0
X-purgate-type: clean
X-purgate-size: 1036

On 8/6/26 17:26, Roger Pau Monne wrote:
> It's possible for domains to generate unaligned PCI config space accesses
> when using ECAM, and hence vPCI should support those at least for the
> hardware domain.  Such unaligned accesses to the PCI config space have been
> reported to come from ACPI logic.
> 
> Relax the checking in vpci_access_allowed() to allow such accesses for the
> hardware domain, and fix the handling in pci_conf_{read,write}{16,32}() to
> fulfill them using MMCFG.
> 
> MMCFG regions are identity exposed to the hardware domain, and hence such
> unaligned accesses can only come as a result of the host having MMCFG in the
> first place, as otherwise MMCFG won't be exposed to the hardware domain
> either.
> 
> Note that vpci_ecam_{read,write}() already refuse accesses that cross a
> device boundary unconditionally.
> 
> Reported-by: Jason Andryuk <jason.andryuk@amd.com>
> Signed-off-by: Roger Pau Monné <roger@xenproject.org>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:02:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:02:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387623.1628880 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSRn-0001XO-E3; Mon, 10 Aug 2026 16:01:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387623.1628880; Mon, 10 Aug 2026 16:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSRn-0001XH-A9; Mon, 10 Aug 2026 16:01:55 +0000
Received: by outflank-mailman (input) for mailman id 1387623;
 Mon, 10 Aug 2026 16:01:53 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec689f7e000e099@swg.vates.tech>)
 id 1wtSRl-0001XB-I1
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:01:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSRk-003yAp-KY
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:01:52 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec689f7e000e099@swg.vates.tech>)
 id 6a79f5e1-2eae-0a2a0a5409dd-0a2a45018502-42
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:01:52 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec689f7e000e099@swg.vates.tech>)
 id 6a79f5f0-5984-0a2a45010019-b9ff1c1283ff-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:01:52 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec689f7e000e099.002 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:01:47 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id CDEB880143;
 Mon, 10 Aug 2026 18:01:45 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=mDWDY8uCcNpOoWchPUgPLSC3AhEIumSbEE6oZEH4OMs=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id;
 b=orkGOrmvBqXcC5/yo/UFmyKqN0YxWs3qMjSf7eltUIA3lif439MB9sezVO9uvIMpUWf/yNLG4
 tb1vU3/5FovEcCh5MiACrbkZkzzopSKOHbusdvkAPjfk/0H3OguhFuwuC1Vu2q7USAnHrEuuSNE
 iz6jocWQQsI5QE16Y8UQ/R5Tk5Z/Wu7pUyHIWoyDsCDOujwDYWvM2+KNBXnZZD2/rcoFmakZuZL
 AT7KDZtI91esKRgkJ7wqdA36vx8vJC4xCireKx+L8xpca1x7kAQPiPrGnVt1nNXC6WTgu3b/+Kg
 IdFihvX3tXavbvQw0tTVsKmcYVLkqi/ti0OlU7ep3llQ==
X-Zone-Loop: c8e3ca4d7798ec05392c0dd2ef91c4d0587d2a8872c6
x-campaign-type: default
x-transaction-id: ab6c9570-46a5-487a-a4d1-af9b08c5d184
x-swg-uid: 01-3221a14d-cc91-447f-964c-cd7f08f435e1
X-Mailer: Sweego
Message-ID:
 <1786377707.8631fc262581453bbf619ec5b2062170.19fec689f7e000e099@vates.tech>
x-swg-bid: 1786377707.8631fc262581453bbf619ec5b2062170.19fec689f7e000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Doug Goldstein <cardoe@cardoe.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>
Subject: [PATCH 0/6] automation: add QTB test framework for riscv64 smoke tests
Date: Mon, 10 Aug 2026 18:01:13 +0200
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2047.9748927987cc8332.19fec6899c0.104ee129b456d5ba=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786377705920
X-purgate-ID: tlsNG-d62444/1786377712-1E07B757-9824E1D3/0/0
X-purgate-type: clean
X-purgate-size: 8391

---=Part.2047.9748927987cc8332.19fec6899c0.104ee129b456d5ba=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Xen is being made safety certifiable to IEC 61508 SIL 3 and ISO 26262 ASIL
D, with Arm and x86 as the current targets [1]=2E Evidence at those levels=
 is
requirements based testing plus structural coverage, produced automaticall=
y
and repeatably in CI=2E

QTB (QEMU Test Bench) [2] is the framework AMD wrote for it as part of the
Xen safety initiative=2E It drives a live QEMU instance over qtest, QMP an=
d
GDB, so a test has full access to the machine while emulation runs: read
and write the consoles, inspect registers and memory, inject interrupts an=
d
faults, all from Python and all reproducible in a pipeline=2E QTB is not
upstream in QEMU yet, but is planned to be=2E

RISC-V is not in the certification scope today=2E It is also the youngest
port, so it has close to no test infrastructure to undo, which makes it th=
e
cheapest place to adopt QTB=2E Starting the riscv64 tests on the framework
now means the port grows its tests in the shape certification asks for as
the port itself grows, instead of a pile of expect scripts to convert late=
r
if riscv64 ever becomes a certification target=2E It also puts a second
architecture on QTB, which is useful to the framework itself before it is
proposed to QEMU upstream=2E

Concretely, the riscv64 CI coverage today is one expect script,
automation/scripts/qemu-smoke-riscv64=2Esh, which boots Xen alone under QE=
MU
and greps a single string out of one serial console=2E The machine it boot=
s
is hardcoded, so a second configuration means a second script, and a test
with a DomU in it means growing guest handling from scratch=2E

This series replaces that script with a data-driven framework using QTB=2E=
 A
machine is a YAML entry (pcpus, scheduler, interrupt controller, boot
arguments), a test type is a small Python class saying what to do with a
booted machine, and a test binds a machine to that type's expectations=2E
Adding a configuration to CI is then a config change and a job stanza=2E

Patch 1 goes to test-artifacts [3] and must land first, since patches 2-6
run inside the container it adds=2E Patches 2-6 go to xen=2Egit=2E
qemu-smoke-riscv64-gcc also pulls the riscv64 QEMU and OpenSBI binaries
from the qemu-9=2E0=2E0-riscv64 job in test-artifacts, which is not in
test-artifacts master yet and has to land there too=2E

test-artifacts [3]:
- Add a QTB container to run the Xen riscv64 tests
    debian:13-qtb-riscv64, carrying qemu=2Eqtb from AMD's QEMU fork and th=
e
    dtc/fdt dependencies the framework needs at run time=2E

xen=2Egit:
- automation/qtb: add jinja2 device trees for riscv64 smoke tests
    The host tree varies with hart count, MMU type and device set, so it i=
s
    rendered per machine from a template rather than shipping one static
    =2Edts per configuration=2E
- automation/qtb: add Python QTB framework with the console-test type
    The base layer every test type builds on (machine catalog lookup, host
    DT generation, QEMU invocation, per-console log capture) plus the firs=
t
    test type, which asserts every string listed in console-test=2Eyaml is
    printed on the expected console=2E
- automation/qtb: add unit tests for the QTB framework
    pytest coverage of the QEMU-agnostic parts, for developers only=2E
- automation/qtb: add QTB framework README
    How to add a machine, add a test type and run one locally=2E
- CI: run the riscv64 smoke test via QTB framework console-test
    Repoints qemu-smoke-riscv64-gcc at the framework and drops
    qemu-smoke-riscv64=2Esh, which then has no caller left=2E

Testing: QEMU only, as the existing riscv64 CI does=2E
qemu-smoke-riscv64-gcc runs the same check as before=2E

The catalog ships a single Xen-only machine, since Xen cannot boot a DomU
on RISC-V yet=2E DomU machines plus an irq-test type using QTest interrupt
injection follow once DomU support lands=2E

[1] https://elisa=2Etech/blog/2026/07/22/the-final-phase-of-xen-safety-sol=
ving-coverage-and-residual-gaps-stefano-stabellini-amd/
[2] https://gitlab=2Ecom/xen-project/people/amd/qemu/-/tree/safety
[3] https://gitlab=2Ecom/xen-project/hardware/test-artifacts

CI test:
https://gitlab=2Ecom/xen-project/people/baptleduc/xen/-/pipelines/27408369=
46

Baptiste Le Duc (5):
  automation/qtb: add jinja2 device trees for riscv64 smoke tests
  automation/qtb: add Python QTB framework with the console-test type
  automation/qtb: add unit tests for the QTB framework
  automation/qtb: add QTB framework README
  CI: run the riscv64 smoke test via QTB framework console-test

 =2Egitlab-ci=2Eyml                                |   3 +
 automation/gitlab-ci/test=2Eyaml                |  26 ++-
 automation/scripts/qemu-smoke-riscv64=2Esh      |  19 --
 automation/scripts/qemu_smoke_riscv64=2Epy      | 122 ++++++++++
 automation/scripts/qtb/__init__=2Epy            |   2 +
 automation/scripts/qtb/riscv/README=2Emd        | 182 +++++++++++++++
 automation/scripts/qtb/riscv/__init__=2Epy      |   9 +
 automation/scripts/qtb/riscv/config=2Epy        | 125 ++++++++++
 automation/scripts/qtb/riscv/config=2Eyaml      |  19 ++
 =2E=2E=2E/qtb/riscv/console_test/__init__=2Epy        |   4 +
 =2E=2E=2E/qtb/riscv/console_test/console-test=2Eyaml  |  18 ++
 =2E=2E=2E/qtb/riscv/console_test/console_test=2Epy    | 145 ++++++++++++
 automation/scripts/qtb/riscv/dt=2Epy            |  57 +++++
 =2E=2E=2E/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2    | 160 +++++++++++=
++
 automation/scripts/qtb/riscv/machine=2Epy       |  56 +++++
 automation/scripts/qtb/riscv/paths=2Epy         |  51 ++++
 automation/scripts/qtb/riscv/qtb_test=2Epy      |  53 +++++
 automation/scripts/qtb/riscv/unit/__init__=2Epy |   2 +
 automation/scripts/qtb/riscv/unit/conftest=2Epy |  42 ++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_config=2Epy     | 128 +++++++++++
 =2E=2E=2E/qtb/riscv/unit/test_console_test=2Epy       | 217 +++++++++++++=
+++++
 automation/scripts/qtb/riscv/unit/test_dt=2Epy  |  99 ++++++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_machine=2Epy    |  58 +++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_temp_dir=2Epy   |  42 ++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_xen_dt=2Epy     |  46 ++++
 automation/scripts/qtb/riscv/xen_dt=2Epy        |  58 +++++
 26 files changed, 1718 insertions(+), 25 deletions(-)
 delete mode 100755 automation/scripts/qemu-smoke-riscv64=2Esh
 create mode 100755 automation/scripts/qemu_smoke_riscv64=2Epy
 create mode 100644 automation/scripts/qtb/__init__=2Epy
 create mode 100644 automation/scripts/qtb/riscv/README=2Emd
 create mode 100644 automation/scripts/qtb/riscv/__init__=2Epy
 create mode 100644 automation/scripts/qtb/riscv/config=2Epy
 create mode 100644 automation/scripts/qtb/riscv/config=2Eyaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/__init__=2Ep=
y
 create mode 100644 automation/scripts/qtb/riscv/console_test/console-test=
=2Eyaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/console_test=
=2Epy
 create mode 100644 automation/scripts/qtb/riscv/dt=2Epy
 create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2
 create mode 100644 automation/scripts/qtb/riscv/machine=2Epy
 create mode 100644 automation/scripts/qtb/riscv/paths=2Epy
 create mode 100644 automation/scripts/qtb/riscv/qtb_test=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/__init__=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/conftest=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_config=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_console_test=2E=
py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_dt=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_machine=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_temp_dir=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_xen_dt=2Epy
 create mode 100644 automation/scripts/qtb/riscv/xen_dt=2Epy

--=20
2=2E55=2E0



-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.2047.9748927987cc8332.19fec6899c0.104ee129b456d5ba=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:10:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:10:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387635.1628894 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZw-0003Tb-Hf; Mon, 10 Aug 2026 16:10:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387635.1628894; Mon, 10 Aug 2026 16:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZw-0003TR-B3; Mon, 10 Aug 2026 16:10:20 +0000
Received: by outflank-mailman (input) for mailman id 1387635;
 Mon, 10 Aug 2026 16:10:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec70581a000e099@swg.vates.tech>)
 id 1wtSZu-0003Qj-Oj
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:10:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSZt-008NAc-Sr
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:10:17 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec70581a000e099@swg.vates.tech>)
 id 6a79f7dd-bab6-0a2a0a5309dd-0a2a45049fd2-26
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:17 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec70581a000e099@swg.vates.tech>)
 id 6a79f7e9-b57f-0a2a45040019-b9ff1c128dc1-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:17 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec70581a000e099.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:10:13 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 9AB75836CA;
 Mon, 10 Aug 2026 18:10:12 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=0V35KKyCyWU/Pb/pFIo83QM223XPnac1kuZzpR5VrJw=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=QWbdslD1TykVDm7ZCK6mB87orQiy+XeG9IQ9BRqhFO1t1CTlxu2zCEzbMzPhmoQcWA5j7PS8n
 9Zq7c5RD+NPoHoJ8p8/n7qA6tSTjVJwIwTLpxy/QC91NN3vS0ZXs0GKcJbpH/H9VE2jIdiR6mCS
 n7MAvlJePywnAYtmFjVJ2EAlRlkQTPa7laFkwXrJpjVaUySq0V2G+VXBdwJ6SEBx6rT7TmMgwag
 U9oqF2+Fa1/+iDseQFr4vZ0xGAnSsLtQQftjJc3GBTPDp9hxxAvNN6YLvbGWTba7Pqmf25+28BC
 Q8nCWfX1DP2oUsMASMuOKxJ/QId20FayXpqQzQqKqFgQ==
X-Zone-Loop: c24006a88a476bd7b77c74e0bbcfebe1aa929b85d8b1
x-campaign-type: default
x-transaction-id: 05a9d833-b609-4159-b82d-147cbcfeed1a
x-swg-uid: 01-de0d33b5-f43e-4c41-bd42-d2c4f0d67d31
X-Mailer: Sweego
Message-ID:
 <1786378213.8631fc262581453bbf619ec5b2062170.19fec70581a000e099@vates.tech>
x-swg-bid: 1786378213.8631fc262581453bbf619ec5b2062170.19fec70581a000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests
Date: Mon, 10 Aug 2026 18:09:52 +0200
In-Reply-To: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2049.93281b3fe6baf6b5.19fec705570.451b9a4538daf6f6=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378212720
X-purgate-ID: tlsNG-ebf023/1786378217-C32CCB50-25BB999F/0/0
X-purgate-type: clean
X-purgate-size: 7543

---=Part.2049.93281b3fe6baf6b5.19fec705570.451b9a4538daf6f6=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The dom0less RISC-V smoke tests need a host device tree describing the
platform (CPUs, APLIC/IMSIC, uart)=2E It varies per machine (hart count, M=
MU
type), so a single static =2Edts cannot cover the test matrix=2E

Add dts/qemu-host=2Edts=2Ej2, a template of the QEMU virt platform in
aia=3Daplic-imsic mode: per-hart cpu/cpu-intc nodes, the M- and S-mode APL=
IC
and IMSIC pairs, CLINT and the ns16550a uart=2E It takes ncpus, mmu_type a=
nd
xen_bootargs as arguments=2E

Values QEMU hardcodes are set as named constants matching their source
symbols (QEMU_UART0_IRQ, QEMU_IRQCHIP_NUM_SOURCES, =2E=2E=2E) rather than
open-coded, so a QEMU-side change is easy to trace=2E

The template is inert on its own: the generated dtb will be used in next
patch=2E

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
---
 =2E=2E=2E/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2    | 160 +++++++++++=
+++++++
 1 file changed, 160 insertions(+)
 create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2

diff --git a/automation/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2 b/autom=
ation/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2
new file mode 100644
index 0000000000=2E=2E13a8e983ce
--- /dev/null
+++ b/automation/scripts/qtb/riscv/dts/qemu-host=2Edts=2Ej2
@@ -0,0 +1,160 @@
+/dts-v1/;
+
+{#-
+ * Jinja2 QEMU "virt" platform device tree for Xen RISC-V tests=2E
+ *
+ * Interrupt controller: APLIC in MSI mode + IMSIC
+ * (QEMU -M virt,aia=3Daplic-imsic)=2E
+ *
+ * Rendered by xen_dt=2Epy=2E
+ *
+ * Variables:
+ *   ncpus        - number of physical harts                (int, >=3D 1)
+ *   mmu_type     - Xen host MMU type, e=2Eg=2E "sv39"          (string)
+ *   xen_bootargs - Xen command line                        (string)
+ *
+ * Per-hart nodes are labelled cpu<i> / cpu<i>_intc and referenced with &=
label=2E
+ *
+ * No `aia-guests=3DN`, so no VS-mode guest files: IMSIC reg size is
+ * ncpus * page size=2E
+-#}
+{#- Values QEMU hardcodes, need to be described to Xen -#}
+{%- set QEMU_TIMEBASE_FREQUENCY =3D 10000000 %}   {#- RISCV_ACLINT_DEFAUL=
T_TIMEBASE_FREQ -#}
+{%- set QEMU_IRQCHIP_NUM_SOURCES =3D 96 %}        {#- VIRT_IRQCHIP_NUM_SO=
URCES (virt=2Eh) -#}
+{%- set QEMU_IRQCHIP_NUM_MSIS =3D 255 %}          {#- VIRT_IRQCHIP_NUM_MS=
IS -#}
+{%- set QEMU_UART_CLOCK_FREQUENCY =3D 3686400 %}  {#- create_fdt_uart() -=
#}
+{%- set QEMU_UART0_IRQ =3D 10 %}                  {#- UART0_IRQ -#}
+{%- set QEMU_IMSIC_PAGE_SZ =3D 0x1000 %}          {#- IMSIC_MMIO_PAGE_SZ =
-#}
+
+{%- set IRQ_TYPE_LEVEL_HIGH =3D 4 %}
+{%- set APLIC_IRQ_CELLS =3D 2 %}
+
+{%- set IRQ_M_SOFT =3D 3 %}
+{%- set IRQ_M_TIMER =3D 7 %}
+{%- set IRQ_S_EXT =3D 9 %}
+{%- set IRQ_M_EXT =3D 11 %}
+
+/ {
+    #address-cells =3D <0x02>;
+    #size-cells =3D <0x02>;
+    compatible =3D "riscv-virtio";
+    model =3D "riscv-virtio,qemu";
+
+    memory@80000000 {
+        device_type =3D "memory";
+        reg =3D <0x00 0x80000000 0x00 0x80000000>;
+    };
+
+    cpus {
+        #address-cells =3D <0x01>;
+        #size-cells =3D <0x00>;
+        timebase-frequency =3D <{{ QEMU_TIMEBASE_FREQUENCY }}>;
+{% for i in range(ncpus) %}
+        cpu{{ i }}: cpu@{{ i }} {
+            device_type =3D "cpu";
+            reg =3D <0x{{ '%x' % i }}>;
+            status =3D "okay";
+            compatible =3D "riscv";
+            riscv,cbop-block-size =3D <0x40>;
+            riscv,cboz-block-size =3D <0x40>;
+            riscv,cbom-block-size =3D <0x40>;
+            riscv,isa =3D "rv64imafdch_zicntr_zicsr_zifencei_zihintpause_=
zihpm_zba_zbb_zbs_smstateen_svpbmt_smaia_ssaia";
+            mmu-type =3D "riscv,{{ mmu_type }}";
+
+            cpu{{ i }}_intc: interrupt-controller@{{ i }} {
+                #interrupt-cells =3D <0x01>;
+                interrupt-controller;
+                compatible =3D "riscv,cpu-intc";
+            };
+        };
+{% endfor %}
+        cpu-map {
+
+            cluster0 {
+{% for i in range(ncpus) %}
+                core{{ i }} {
+                    cpu =3D <&cpu{{ i }}>;
+                };
+{% endfor %}
+            };
+        };
+    };
+
+    soc {
+        #address-cells =3D <0x02>;
+        #size-cells =3D <0x02>;
+        compatible =3D "simple-bus";
+        ranges;
+
+        serial@10000000 {
+            interrupts =3D <{{ QEMU_UART0_IRQ }} {{ IRQ_TYPE_LEVEL_HIGH }=
}>;
+            interrupt-parent =3D <&aplic_s>;
+            clock-frequency =3D <{{ QEMU_UART_CLOCK_FREQUENCY }}>;
+            reg =3D <0x00 0x10000000 0x00 0x100>;
+            compatible =3D "ns16550a";
+        };
+
+        aplic_s: aplic@d000000 {
+            riscv,num-sources =3D <{{ QEMU_IRQCHIP_NUM_SOURCES }}>;
+            reg =3D <0x00 0xd000000 0x00 0x8000>;
+            msi-parent =3D <&imsic_s>;
+            interrupt-controller;
+            #interrupt-cells =3D <{{ APLIC_IRQ_CELLS }}>;
+            compatible =3D "riscv,aplic";
+        };
+
+        aplic@c000000 {
+            riscv,delegate =3D <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCES=
 }}>;
+            riscv,children =3D <&aplic_s>;
+            riscv,num-sources =3D <{{ QEMU_IRQCHIP_NUM_SOURCES }}>;
+            reg =3D <0x00 0xc000000 0x00 0x8000>;
+            msi-parent =3D <&imsic_m>;
+            interrupt-controller;
+            #interrupt-cells =3D <{{ APLIC_IRQ_CELLS }}>;
+            compatible =3D "riscv,aplic";
+        };
+
+        imsic_s: imsics@28000000 {
+            riscv,num-ids =3D <{{ QEMU_IRQCHIP_NUM_MSIS }}>;
+            reg =3D <0x00 0x28000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC=
_PAGE_SZ) }}>;
+            interrupts-extended =3D <
+                {%- for i in range(ncpus) %}
+                    &cpu{{ i }}_intc {{ IRQ_S_EXT }}
+                {%- endfor %}
+            >;
+            msi-controller;
+            interrupt-controller;
+            #interrupt-cells =3D <0x00>;
+            compatible =3D "riscv,imsics";
+        };
+
+        imsic_m: imsics@24000000 {
+            riscv,num-ids =3D <{{ QEMU_IRQCHIP_NUM_MSIS }}>;
+            reg =3D <0x00 0x24000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC=
_PAGE_SZ) }}>;
+            interrupts-extended =3D <
+                {%- for i in range(ncpus) %}
+                    &cpu{{ i }}_intc {{ IRQ_M_EXT }}
+                {%- endfor %}
+            >;
+            msi-controller;
+            interrupt-controller;
+            #interrupt-cells =3D <0x00>;
+            compatible =3D "riscv,imsics";
+        };
+
+        clint@2000000 {
+            interrupts-extended =3D <
+                {%- for i in range(ncpus) %}
+                    &cpu{{ i }}_intc {{ IRQ_M_SOFT }} &cpu{{ i }}_intc {{=
 IRQ_M_TIMER }}
+                {%- endfor %}
+            >;
+            reg =3D <0x00 0x2000000 0x00 0x10000>;
+            compatible =3D "sifive,clint0", "riscv,clint0";
+        };
+    };
+
+    chosen {
+        stdout-path =3D "/soc/serial@10000000";
+        xen,xen-bootargs =3D "{{ xen_bootargs }}";
+    };
+};


-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.2049.93281b3fe6baf6b5.19fec705570.451b9a4538daf6f6=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:10:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:10:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387637.1628915 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZz-00043g-35; Mon, 10 Aug 2026 16:10:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387637.1628915; Mon, 10 Aug 2026 16:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZy-00043Z-Vt; Mon, 10 Aug 2026 16:10:22 +0000
Received: by outflank-mailman (input) for mailman id 1387637;
 Mon, 10 Aug 2026 16:10:21 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705b96000e099@swg.vates.tech>)
 id 1wtSZx-0003e4-0E
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:10:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSZw-00Exz0-D2
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:10:20 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705b96000e099@swg.vates.tech>)
 id 6a79f79b-e002-0a2a0a5209dd-0a2a45018e00-40
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:20 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705b96000e099@swg.vates.tech>)
 id 6a79f7e7-5984-0a2a45010019-b9ff1c23956d-4
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:20 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec705b96000e099.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:10:14 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8BD63836CA;
 Mon, 10 Aug 2026 18:10:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=2bfsoiEs2rAdY4I4Kp7G6nvU3IQk8zu75BYtS3wxPMU=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=fAyLc397XD5acd0FvQWQnTjkI0Fj/7gzULhacda+HOeTumzNfTtCYDw7+LWdUiS8dmUbeMVE0
 tJnuF5ie+W7b6jV4Sv+IcUxjgt8DMILEdt2TGPrgt7n8E1ztI/dJ+qUH/V2M7NmWADg4zvtBL9N
 SvYMyV152VL9SAzyv07Ipb65t8l1P8ziNnTE+3gTm29khg4LZrr/RMtuLmxfFdmDwPE0oqbfOl2
 ow0L46E2Qpzu1tTtkWinWoCKYleB/RggdaEVQbwx59zsrueWdcNCwFSx8bLBjbaAtmpKFDklDCQ
 0lN8ESxIq4VvuCUyJVx76wSMZD+plIp0PZ3JJoe9HFXQ==
X-Zone-Loop: fe2e1731f33cf08b1ea41793c6cbaffb04564bcafc2b
x-campaign-type: default
x-transaction-id: 074ba940-8969-42e1-b2e3-2204decf4e2a
x-swg-uid: 01-3cd3a695-e1d4-474c-8385-3d852215669b
X-Mailer: Sweego
Message-ID:
 <1786378214.8631fc262581453bbf619ec5b2062170.19fec705b96000e099@vates.tech>
x-swg-bid: 1786378214.8631fc262581453bbf619ec5b2062170.19fec705b96000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 4/6] automation/qtb: add unit tests for the QTB framework
Date: Mon, 10 Aug 2026 18:09:54 +0200
In-Reply-To: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.204b.877beba074a48ee1.19fec70591b.fc1f12a78ffda386=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378213659
X-purgate-ID: tlsNG-d62444/1786378220-BDC79757-45D141D2/0/0
X-purgate-type: clean
X-purgate-size: 26123

---=Part.204b.877beba074a48ee1.19fec70591b.fc1f12a78ffda386=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The QTB framework is meant to be extended: new test types, new machines and
new device trees aim to be added by other people=2E

Add pytest coverage of the framework's functions, and of the console-test
type's config validation and expect/retry loop, so that such changes get
immediate feedback and existing behaviour does not silently regress=2E

The suite covers 100% of the framework's statements, so a new code path
added without a test shows up as a coverage drop=2E

The tests are meant to be run locally, from the Xen tree root:

    python3 -m pytest automation/scripts/qtb/riscv/unit/

and, with pytest-cov installed, the coverage report is:

    python3 -m pytest --cov=3Dautomation/scripts/qtb \
        automation/scripts/qtb/riscv/unit/

The tests drive fakes rather than QEMU, so they need no artifacts to run=
=2E

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
---
 automation/scripts/qtb/riscv/unit/__init__=2Epy |   2 +
 automation/scripts/qtb/riscv/unit/conftest=2Epy |  42 ++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_config=2Epy     | 128 +++++++++++
 =2E=2E=2E/qtb/riscv/unit/test_console_test=2Epy       | 217 +++++++++++++=
+++++
 automation/scripts/qtb/riscv/unit/test_dt=2Epy  |  99 ++++++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_machine=2Epy    |  58 +++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_temp_dir=2Epy   |  42 ++++
 =2E=2E=2E/scripts/qtb/riscv/unit/test_xen_dt=2Epy     |  46 ++++
 8 files changed, 634 insertions(+)
 create mode 100644 automation/scripts/qtb/riscv/unit/__init__=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/conftest=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_config=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_console_test=2E=
py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_dt=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_machine=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_temp_dir=2Epy
 create mode 100644 automation/scripts/qtb/riscv/unit/test_xen_dt=2Epy

diff --git a/automation/scripts/qtb/riscv/unit/__init__=2Epy b/automation/=
scripts/qtb/riscv/unit/__init__=2Epy
new file mode 100644
index 0000000000=2E=2Eb234dc5303
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/__init__=2Epy
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""pytest tests of the framework's own logic=2E"""
diff --git a/automation/scripts/qtb/riscv/unit/conftest=2Epy b/automation/=
scripts/qtb/riscv/unit/conftest=2Epy
new file mode 100644
index 0000000000=2E=2E576eaf13b1
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/conftest=2Epy
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Shared pytest fixtures for the qtb unit tests=2E"""
+
+from __future__ import annotations
+
+import pytest
+
+from =2E=2Econfig import MachineConfig
+
+
+@pytest=2Efixture
+def make_file(tmp_path):
+    """Return a factory creating a file of `size` bytes, yielding its pat=
h=2E"""
+
+    def _make(name: str, size: int =3D 16) -> str:
+        p =3D tmp_path / name
+        p=2Ewrite_bytes(b"\0" * size)
+        return str(p)
+
+    return _make
+
+
+@pytest=2Efixture
+def make_machine():
+    """Return a factory building a MachineConfig for tests=2E"""
+
+    def _make(
+        *,
+        name=3D"m",
+        binaries=3DNone,
+        mmu=3D"sv48",
+        xen_bootargs=3D"",
+    ) -> MachineConfig:
+        return MachineConfig(
+            name=3Dname,
+            pcpu=3D4,
+            binaries=3Dbinaries,
+            mmu_type=3Dmmu,
+            xen_bootargs=3Dxen_bootargs,
+        )
+
+    return _make
diff --git a/automation/scripts/qtb/riscv/unit/test_config=2Epy b/automati=
on/scripts/qtb/riscv/unit/test_config=2Epy
new file mode 100644
index 0000000000=2E=2E790328a13f
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_config=2Epy
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Unit tests for the YAML machine-catalog parser=2E"""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+import pytest
+import yaml
+
+from =2E=2Econfig import (
+    XEN_BOOTARGS_DEFAULT,
+    XEN_MMU_TYPE_DEFAULT,
+    MachineConfig,
+    _parse_binaries,
+)
+
+
+@pytest=2Efixture
+def binaries(make_file):
+    """Raw binaries dict pointing at three existing files=2E"""
+    return {
+        "qemu": make_file("qemu-system-riscv64"),
+        "firmware": make_file("fw=2Ebin"),
+        "xen": make_file("xen"),
+    }
+
+
+# ---- _parse_binaries ----
+
+
+def test_parse_binaries_resolves_existing_paths(binaries):
+    cfg =3D _parse_binaries(binaries)
+    assert cfg=2Eqemu =3D=3D Path(binaries["qemu"])
+    assert cfg=2Efirmware =3D=3D Path(binaries["firmware"])
+    assert cfg=2Exen =3D=3D Path(binaries["xen"])
+
+
+def test_parse_binaries_missing_key_raises(binaries):
+    del binaries["xen"]
+    with pytest=2Eraises(ValueError, match=3D"missing keys"):
+        _parse_binaries(binaries)
+
+
+def test_parse_binaries_missing_file_raises(binaries, tmp_path):
+    binaries["xen"] =3D str(tmp_path / "absent")
+    with pytest=2Eraises(FileNotFoundError):
+        _parse_binaries(binaries)
+
+
+# ---- MachineConfig=2Efrom_config ----
+
+
+def _write_yaml(tmp_path, binaries, name=3D"machine-a", **machine_overrid=
es):
+    machine =3D {
+        "pcpu": 1,
+        "xen_bootargs": "com1=3Dpoll sched=3Dnull",
+    }
+    machine=2Eupdate(machine_overrides)
+    doc =3D {"binaries": binaries, "machines": {name: machine}}
+    path =3D tmp_path / "config=2Eyaml"
+    path=2Ewrite_text(yaml=2Esafe_dump(doc))
+    return str(path)
+
+
+def test_from_config_builds_machineconfig(tmp_path, binaries):
+    path =3D _write_yaml(tmp_path, binaries)
+
+    mc =3D MachineConfig=2Efrom_config(path, "machine-a")
+
+    assert mc=2Ename =3D=3D "machine-a"
+    assert mc=2Epcpu =3D=3D 1
+    assert mc=2Exen_bootargs =3D=3D "com1=3Dpoll sched=3Dnull"
+    assert mc=2Ebinaries=2Eqemu =3D=3D Path(binaries["qemu"])
+
+
+def test_from_config_applies_optional_defaults(tmp_path, binaries):
+    # A machine with only the required keys falls back to the module defa=
ults=2E
+    path =3D _write_yaml(
+        tmp_path,
+        binaries,
+        name=3D"bare",
+        mmu_type=3DNone,
+        xen_bootargs=3DNone,
+    )
+    # Drop the keys set to None so the parser sees them as absent=2E
+    doc =3D yaml=2Esafe_load(Path(path)=2Eread_text())
+    for k in ("mmu_type", "xen_bootargs"):
+        doc["machines"]["bare"]=2Epop(k, None)
+    Path(path)=2Ewrite_text(yaml=2Esafe_dump(doc))
+
+    mc =3D MachineConfig=2Efrom_config(path, "bare")
+
+    assert mc=2Emmu_type =3D=3D XEN_MMU_TYPE_DEFAULT
+    assert mc=2Exen_bootargs =3D=3D XEN_BOOTARGS_DEFAULT
+
+
+def test_from_config_missing_machine_key_raises(tmp_path, binaries):
+    path =3D _write_yaml(tmp_path, binaries, name=3D"bare")
+    doc =3D yaml=2Esafe_load(Path(path)=2Eread_text())
+    del doc["machines"]["bare"]["pcpu"]
+    Path(path)=2Ewrite_text(yaml=2Esafe_dump(doc))
+
+    with pytest=2Eraises(ValueError, match=3D"machine config missing keys=
"):
+        MachineConfig=2Efrom_config(path, "bare")
+
+
+def test_from_config_missing_top_level_key_raises(tmp_path, binaries):
+    path =3D _write_yaml(tmp_path, binaries)
+    doc =3D yaml=2Esafe_load(Path(path)=2Eread_text())
+    del doc["binaries"]
+    Path(path)=2Ewrite_text(yaml=2Esafe_dump(doc))
+
+    with pytest=2Eraises(ValueError, match=3D"missing keys: \\['binaries'=
\\]"):
+        MachineConfig=2Efrom_config(path, "machine-a")
+
+
+def test_from_config_unknown_machine_raises(tmp_path, binaries):
+    path =3D _write_yaml(tmp_path, binaries)
+    with pytest=2Eraises(ValueError, match=3D"unknown machine 'nope'"):
+        MachineConfig=2Efrom_config(path, "nope")
+
+
+def test_from_config_missing_binary_raises(tmp_path, binaries):
+    binaries["qemu"] =3D str(tmp_path / "gone")
+    path =3D _write_yaml(tmp_path, binaries)
+    with pytest=2Eraises(FileNotFoundError):
+        MachineConfig=2Efrom_config(path, "machine-a")
diff --git a/automation/scripts/qtb/riscv/unit/test_console_test=2Epy b/au=
tomation/scripts/qtb/riscv/unit/test_console_test=2Epy
new file mode 100644
index 0000000000=2E=2Ecf15ed3b1b
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_console_test=2Epy
@@ -0,0 +1,217 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Unit tests for the console-test test type (console_test=2Epy)=2E"""
+
+from __future__ import annotations
+
+from itertools import chain, repeat
+from unittest import mock
+
+import pexpect
+import pytest
+
+from =2E=2Econsole_test=2Econsole_test import ConsoleTest
+from =2E=2Econfig import MachineConfig
+
+
+# ---- helpers ----
+
+
+def _parse_test_data(machine, expect, name=3D"dummy"):
+    """Validate `expect` against `machine`, without reading a catalog fil=
e=2E"""
+    test_data =3D {"machine": "box", "expect": expect}
+    with mock=2Epatch=2Eobject(MachineConfig, "from_config", return_value=
=3Dmachine):
+        return ConsoleTest=2E_parse_test_data("config=2Eyaml", test_data,=
 name)
+
+
+def _console(fail_times: int =3D 0, matches: int =3D 1) -> mock=2EMock:
+    """Stand in for a pexpect spawn: `fail_times` timeouts, then `matches=
` hits=2E
+
+    Every wait past `matches` times out, so a test that waits more often =
than it
+    should fails instead of silently passing=2E
+    """
+    cons =3D mock=2EMock()
+    cons=2Eexpect_exact=2Eside_effect =3D chain(
+        [pexpect=2ETIMEOUT("nope")] * fail_times,
+        [None] * matches,
+        repeat(pexpect=2ETIMEOUT("nope")),
+    )
+    return cons
+
+
+def _asked(cons: mock=2EMock) -> list[str]:
+    """The strings waited for on `cons`, one entry per attempt (matched o=
r not)=2E"""
+    return [call=2Eargs[0] for call in cons=2Eexpect_exact=2Ecall_args_li=
st]
+
+
+def _test(expect, machine, **opts):
+    """Build a ConsoleTest bound to `machine`, skipping the YAML read=2E"=
""
+    raw =3D {
+        "machine_catalog": "config=2Eyaml",
+        "tests": {"dummy": {"machine": "box", "expect": expect, **opts}},
+    }
+    with mock=2Epatch=2Eobject(MachineConfig, "from_config", return_value=
=3Dmachine):
+        return ConsoleTest(raw, "dummy")
+
+
+# ---- _parse_test_data ----
+
+
+def test_parse_test_data_accepts_a_list_of_strings(make_machine):
+    machine =3D make_machine()
+    name, data, got =3D _parse_test_data(machine, {0: ["Hello", "All set =
up"]})
+    assert (name, got) =3D=3D ("dummy", machine)
+    assert data["expect"] =3D=3D {0: ["Hello", "All set up"]}
+
+
+def test_parse_test_data_bare_string_raises(make_machine):
+    # A bare string is refused, not wrapped: the YAML must spell out the =
list=2E
+    machine =3D make_machine()
+    with pytest=2Eraises(ValueError, match=3D"expects a list of string"):
+        _parse_test_data(machine, {0: "All set up"})
+
+
+@pytest=2Emark=2Eparametrize(
+    "expect",
+    [
+        {-1: ["All set up"]},  # console index below Xen's
+        {1: ["All set up"]},  # console index above Xen's
+        {0: ["All set up"], 1: ["More"]},  # Xen's + another unknown
+        ["All set up"],  # no console index
+        None,
+        "All set up",  # not a map at all
+    ],
+)
+def test_parse_test_data_not_the_xen_console_map_raises(expect, make_mach=
ine):
+    machine =3D make_machine()
+    with pytest=2Eraises(ValueError, match=3D"must map console index 0"):
+        _parse_test_data(machine, expect)
+
+
+def test_parse_test_data_empty_list_raises(make_machine):
+    machine =3D make_machine()
+    with pytest=2Eraises(ValueError, match=3D"Xen has no expected string"=
):
+        _parse_test_data(machine, {0: []})
+
+
+def test_parse_test_data_empty_string_in_list_raises(make_machine):
+    machine =3D make_machine()
+    with pytest=2Eraises(ValueError, match=3D"Xen expects non-empty strin=
gs"):
+        _parse_test_data(machine, {0: ["All set up", ""]})
+
+
+def test_parse_test_data_missing_expect_raises():
+    with pytest=2Eraises(ValueError, match=3D"missing keys"):
+        ConsoleTest=2E_parse_test_data("config=2Eyaml", {"machine": "box"=
}, "dummy")
+
+
+# ---- _parse_test_cfg ----
+
+
+def test_parse_test_cfg_missing_machine_catalog_raises():
+    with pytest=2Eraises(ValueError, match=3D"missing keys"):
+        ConsoleTest=2E_parse_test_cfg({"tests": {}}, "dummy")
+
+
+def test_parse_test_cfg_unknown_test_raises():
+    raw =3D {"machine_catalog": "config=2Eyaml", "tests": {"a": {}}}
+    with pytest=2Eraises(ValueError, match=3D"unknown test 'dummy'"):
+        ConsoleTest=2E_parse_test_cfg(raw, "dummy")
+
+
+# ---- __init__ ----
+
+
+def test_timeout_and_attempts_are_read(make_machine):
+    test =3D _test({0: ["All set up"]}, make_machine(), timeout=3D7, atte=
mpts=3D2)
+    assert (test=2Etimeout, test=2Eattempts) =3D=3D (7, 2)
+
+
+def test_timeout_below_one_raises(make_machine):
+    with pytest=2Eraises(ValueError, match=3D"timeout < 1"):
+        _test({0: ["All set up"]}, make_machine(), timeout=3D0)
+
+
+def test_attempts_below_one_raises(make_machine):
+    with pytest=2Eraises(ValueError, match=3D"attempts < 1"):
+        _test({0: ["All set up"]}, make_machine(), attempts=3D0)
+
+
+# ---- run ----
+
+
+def test_run_expects_each_string_in_order_on_con0(make_machine):
+    test =3D _test({0: ["first", "then"]}, make_machine())
+    vm =3D mock=2EMock(console=3D_console(matches=3D2))
+
+    test=2Erun(vm)
+
+    assert _asked(vm=2Econsole) =3D=3D ["first", "then"]
+
+
+def test_run_xen_console_not_wired_raises(make_machine):
+    test =3D _test({0: ["All set up"]}, make_machine())
+    vm =3D mock=2EMock(console=3DNone)
+
+    with pytest=2Eraises(RuntimeError, match=3D"not launched"):
+        test=2Erun(vm)
+
+
+# ---- _expect_string ----
+
+
+def test_expect_string_retries_after_a_timeout(make_machine):
+    test =3D _test({0: ["All set up"]}, make_machine(), attempts=3D3)
+    cons =3D _console(fail_times=3D2)
+
+    test=2E_expect_string(cons, "All set up")
+
+    assert _asked(cons) =3D=3D ["All set up"] * 3
+
+
+def test_expect_string_raises_once_attempts_are_spent(make_machine):
+    test =3D _test({0: ["All set up"]}, make_machine(), attempts=3D2)
+    cons =3D _console(matches=3D0)
+
+    with pytest=2Eraises(pexpect=2ETIMEOUT):
+        test=2E_expect_string(cons, "All set up")
+
+    assert _asked(cons) =3D=3D ["All set up"] * 2
+
+
+# ---- config IO ----
+
+
+def test_list_tests_reads_the_type_yaml():
+    names =3D ConsoleTest=2Elist_tests("console_test/console-test=2Eyaml"=
)
+    assert "dom0less-1smp-0domu-1vcpu-aplic-imsic-null" in names
+
+
+def test_list_tests_without_a_tests_key_returns_empty():
+    with mock=2Epatch=2Eobject(ConsoleTest, "_load_yaml", return_value=3D=
{}):
+        assert ConsoleTest=2Elist_tests("console-test=2Eyaml") =3D=3D []
+
+
+def test_from_config_builds_instance(make_machine):
+    machine =3D make_machine()
+
+    raw =3D {
+        "machine_catalog": "config=2Eyaml",
+        "tests": {"dummy": {"machine": "box", "expect": {0: ["All set up"=
]}}},
+    }
+    # Mock the YAML read and the catalog lookup: only the build logic is =
under test=2E
+    with (
+        mock=2Epatch=2Eobject(ConsoleTest, "_load_yaml", return_value=3Dr=
aw),
+        mock=2Epatch=2Eobject(MachineConfig, "from_config", return_value=
=3Dmachine),
+    ):
+        test =3D ConsoleTest=2Efrom_config("console-test=2Eyaml", "dummy"=
)
+
+    assert test=2Ename =3D=3D "dummy"
+    assert test=2Etype_id =3D=3D "console-test"
+    assert test=2Emachine is machine
+    assert test=2Eexpect =3D=3D {0: ["All set up"]}
+
+
+def test_from_config_unknown_test_raises():
+    # Also pins from_config's argument order (config file, then test name=
)=2E
+    with pytest=2Eraises(ValueError, match=3D"unknown test 'nope'"):
+        ConsoleTest=2Efrom_config("console_test/console-test=2Eyaml", "no=
pe")
diff --git a/automation/scripts/qtb/riscv/unit/test_dt=2Epy b/automation/s=
cripts/qtb/riscv/unit/test_dt=2Epy
new file mode 100644
index 0000000000=2E=2E2201a8651f
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_dt=2Epy
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Unit tests for the device-tree compile path (dt=2Epy)=2E"""
+
+from __future__ import annotations
+
+import shutil
+from unittest import mock
+
+import pytest
+
+from =2E=2E import dt
+
+_HAS_DTC =3D shutil=2Ewhich("dtc") is not None
+_MINIMAL_DTS =3D "/dts-v1/;\n/ { };\n"
+
+
+# ---- _compile_dts (dtc wrapper) ----
+
+
+def test_compile_dts_invokes_dtc(tmp_path):
+    src =3D tmp_path / "in=2Edts"
+    src=2Ewrite_text(_MINIMAL_DTS)
+    dtb =3D tmp_path / "in=2Edtb"
+
+    with mock=2Epatch=2Eobject(dt=2Esubprocess, "run") as run:
+        dt=2E_compile_dts(src, dtb)
+
+    run=2Eassert_called_once()
+    argv =3D run=2Ecall_args=2Eargs[0]
+    assert argv =3D=3D ["dtc", "-I", "dts", "-O", "dtb", "-o", str(dtb), =
str(src)]
+    assert run=2Ecall_args=2Ekwargs["check"] is True
+    assert run=2Ecall_args=2Ekwargs["capture_output"] is True
+
+
+def test_compile_dts_missing_dtc_raises_runtimeerror(tmp_path):
+    src, dtb =3D tmp_path / "a=2Edts", tmp_path / "a=2Edtb"
+    src=2Ewrite_text(_MINIMAL_DTS)
+
+    with mock=2Epatch=2Eobject(dt=2Esubprocess, "run", side_effect=3DFile=
NotFoundError):
+        with pytest=2Eraises(RuntimeError, match=3D"dtc not found"):
+            dt=2E_compile_dts(src, dtb)
+
+
+def test_compile_dts_dtc_failure_raises_runtimeerror(tmp_path):
+    src, dtb =3D tmp_path / "a=2Edts", tmp_path / "a=2Edtb"
+    src=2Ewrite_text(_MINIMAL_DTS)
+    err =3D dt=2Esubprocess=2ECalledProcessError(1, "dtc", output=3D"out"=
, stderr=3D"syntax error")
+
+    with mock=2Epatch=2Eobject(dt=2Esubprocess, "run", side_effect=3Derr)=
:
+        with pytest=2Eraises(RuntimeError, match=3D"syntax error"):
+            dt=2E_compile_dts(src, dtb)
+
+
+# ---- compile_to_dtb path handling ----
+
+
+def test_compile_to_dtb_missing_source_raises_filenotfound(tmp_path):
+    with pytest=2Eraises(FileNotFoundError, match=3D"not found"):
+        dt=2Ecompile_to_dtb(tmp_path / "nope=2Edts", tmp_path)
+
+
+def test_compile_to_dtb_missing_out_dir_raises_filenotfound(tmp_path):
+    src =3D tmp_path / "a=2Edts"
+    src=2Ewrite_text(_MINIMAL_DTS)
+
+    with pytest=2Eraises(FileNotFoundError, match=3D"doesn't exist"):
+        dt=2Ecompile_to_dtb(src, tmp_path / "absent")
+
+
+def test_compile_to_dtb_source_goes_to_out_dir_with_dtb_suffix(tmp_path):
+    src =3D tmp_path / "host-1smp=2Edts"
+    src=2Ewrite_text(_MINIMAL_DTS)
+    out =3D tmp_path / "binaries"
+    out=2Emkdir()
+
+    with mock=2Epatch=2Eobject(dt, "_compile_dts") as compile_mock:
+        result =3D dt=2Ecompile_to_dtb(src, out)
+
+    assert result =3D=3D out / "host-1smp=2Edtb"
+    compile_mock=2Eassert_called_once_with(src, out / "host-1smp=2Edtb")
+
+
+# ---- write_dts ----
+
+
+def test_write_dts_writes_source_under_out_dir(tmp_path):
+    src =3D dt=2Ewrite_dts(_MINIMAL_DTS, name=3D"unit", out_dir=3Dtmp_pat=
h)
+
+    assert src =3D=3D tmp_path / "unit=2Edts"
+    assert src=2Eread_text() =3D=3D _MINIMAL_DTS
+
+
+@pytest=2Emark=2Eskipif(not _HAS_DTC, reason=3D"dtc not installed")
+def test_write_then_compile_produces_dtb(tmp_path):
+    src =3D dt=2Ewrite_dts(_MINIMAL_DTS, name=3D"unit", out_dir=3Dtmp_pat=
h)
+    dtb =3D dt=2Ecompile_to_dtb(src, tmp_path)
+
+    assert dtb=2Eis_file()
+    assert dtb=2Esuffix =3D=3D "=2Edtb"
diff --git a/automation/scripts/qtb/riscv/unit/test_machine=2Epy b/automat=
ion/scripts/qtb/riscv/unit/test_machine=2Epy
new file mode 100644
index 0000000000=2E=2E0a90a5545b
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_machine=2Epy
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Unit tests for RiscvTestMachine QEMU argument assembly=2E"""
+
+from __future__ import annotations
+
+from unittest import mock
+
+from =2E=2Emachine import RiscvTestMachine
+from =2E=2Econfig import MACHINE_MEMORY, BinariesConfig
+
+
+def _binaries(tmp_path):
+    paths =3D {}
+    for name in ("qemu", "firmware", "xen"):
+        p =3D tmp_path / name
+        p=2Ewrite_bytes(b"")
+        paths[name] =3D str(p)
+    return BinariesConfig(**paths)
+
+
+def _machine(mc) -> RiscvTestMachine:
+    """Build the machine with QtbMachine=2E__init__ stubbed out (it spawn=
s QEMU)=2E"""
+    with mock=2Epatch("qemu=2Eqtb=2EQtbMachine=2E__init__", return_value=
=3DNone):
+        return RiscvTestMachine(mc, timeout=3D30)
+
+
+def test_init_forwards_cpus_to_qtbmachine(tmp_path, make_machine):
+    mc =3D make_machine(name=3D"machine", binaries=3D_binaries(tmp_path))
+
+    with mock=2Epatch("qemu=2Eqtb=2EQtbMachine=2E__init__", return_value=
=3DNone) as base_init:
+        vm =3D RiscvTestMachine(mc, timeout=3D30, log_dir=3D"/logs")
+
+    assert vm=2Emachine_conf is mc
+    assert base_init=2Ecall_args=2Ekwargs =3D=3D {
+        "memory": MACHINE_MEMORY,
+        "cpus": mc=2Epcpu,
+        "mirror_console": False,
+        "timeout": 30,
+        "log_dir": "/logs",
+    }
+
+
+def test_resolve_binary_is_the_configured_qemu(tmp_path, make_machine):
+    mc =3D make_machine(name=3D"machine", binaries=3D_binaries(tmp_path))
+
+    assert _machine(mc)=2E_resolve_binary() =3D=3D str(mc=2Ebinaries=2Eqe=
mu)
+
+
+def test_machine_args_wires_firmware_kernel_and_dtb(tmp_path, make_machin=
e):
+    mc =3D make_machine(name=3D"machine", binaries=3D_binaries(tmp_path))
+
+    args =3D list(_machine(mc)=2E_machine_args(memory=3D2048, cpus=3D4))
+
+    assert args[args=2Eindex("-bios") + 1] =3D=3D str(mc=2Ebinaries=2Efir=
mware)
+    assert args[args=2Eindex("-kernel") + 1] =3D=3D str(mc=2Ebinaries=2Ex=
en)
+    assert args[args=2Eindex("-dtb") + 1] =3D=3D str(mc=2Edt=2Edtb)
+    assert args[args=2Eindex("-m") + 1] =3D=3D "2048"
+    assert args[args=2Eindex("-smp") + 1] =3D=3D "4"
diff --git a/automation/scripts/qtb/riscv/unit/test_temp_dir=2Epy b/automa=
tion/scripts/qtb/riscv/unit/test_temp_dir=2Epy
new file mode 100644
index 0000000000=2E=2Ed595d824d7
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_temp_dir=2Epy
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Unit tests for the temp_dir scratch-directory singleton=2E"""
+
+from __future__ import annotations
+
+import pytest
+
+from =2E=2E import paths
+
+
+@pytest=2Efixture(autouse=3DTrue)
+def _reset_singleton():
+    # Force each test to begin with fresh temp dir
+    yield
+    paths=2Ecleanup_temp_dir()
+
+
+def test_temp_dir_exists_and_prefixed():
+    d =3D paths=2Etemp_dir()
+    assert d=2Eis_dir()
+    assert d=2Ename=2Estartswith("qtb-")
+
+
+def test_temp_dir_is_singleton():
+    assert paths=2Etemp_dir() =3D=3D paths=2Etemp_dir()
+
+
+def test_temp_dir_handle_kept_alive():
+    h =3D paths=2E_temp_dir_handle()
+    assert h is paths=2E_temp_dir_handle()
+    assert h=2Ename =3D=3D str(paths=2Etemp_dir())
+
+
+def test_cleanup_temp_dir_removes_and_resets():
+    d =3D paths=2Etemp_dir()
+    assert d=2Eis_dir()
+    paths=2Ecleanup_temp_dir()
+    assert not d=2Eexists()
+    # Cache reset: next call builds a fresh, existing dir, not the gone o=
ne=2E
+    fresh =3D paths=2Etemp_dir()
+    assert fresh=2Eis_dir()
+    assert fresh !=3D d
diff --git a/automation/scripts/qtb/riscv/unit/test_xen_dt=2Epy b/automati=
on/scripts/qtb/riscv/unit/test_xen_dt=2Epy
new file mode 100644
index 0000000000=2E=2E37c4055b31
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_xen_dt=2Epy
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Unit tests for xen_dt device-tree generation=2E"""
+
+from __future__ import annotations
+
+from unittest import mock
+
+from =2E=2E import xen_dt
+
+
+# ---- _render_xen_dts ----
+
+
+def test_render_injects_bootargs(make_machine):
+    machine =3D make_machine(xen_bootargs=3D"com1=3Dpoll sched=3Dnull")
+    out =3D xen_dt=2E_render_xen_dts(machine)
+
+    assert 'xen,xen-bootargs =3D "com1=3Dpoll sched=3Dnull";' in out
+
+
+def test_render_injects_xen_mmu_type(make_machine):
+    machine =3D make_machine(mmu=3D"sv39")
+    out =3D xen_dt=2E_render_xen_dts(machine)
+
+    assert 'mmu-type =3D "riscv,sv39";' in out
+
+
+# ---- build_xen_device_tree ----
+
+
+def test_build_xen_device_tree_compiles(tmp_path, make_machine):
+    machine =3D make_machine(name=3D"unit-test")
+    dts =3D tmp_path / "unit-test=2Edts"
+    dtb =3D tmp_path / "unit-test=2Edtb"
+    with (
+        mock=2Epatch=2Eobject(xen_dt, "temp_dir", return_value=3Dtmp_path=
),
+        mock=2Epatch=2Eobject(xen_dt, "write_dts", return_value=3Ddts) as=
 write_dts,
+        mock=2Epatch=2Eobject(xen_dt, "compile_to_dtb", return_value=3Ddt=
b) as compile_to_dtb,
+    ):
+        result =3D xen_dt=2Ebuild_xen_device_tree(machine)
+
+    write_dts=2Eassert_called_once()
+    assert write_dts=2Ecall_args=2Eargs[1] =3D=3D machine=2Ename
+    compile_to_dtb=2Eassert_called_once_with(dts, tmp_path)
+    assert result=2Edts =3D=3D dts
+    assert result=2Edtb =3D=3D dtb


-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.204b.877beba074a48ee1.19fec70591b.fc1f12a78ffda386=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:10:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:10:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387636.1628906 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZx-0003q4-N0; Mon, 10 Aug 2026 16:10:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387636.1628906; Mon, 10 Aug 2026 16:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZx-0003px-JW; Mon, 10 Aug 2026 16:10:21 +0000
Received: by outflank-mailman (input) for mailman id 1387636;
 Mon, 10 Aug 2026 16:10:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec7059c4000e099@swg.vates.tech>)
 id 1wtSZw-0003V4-M9
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:10:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSZw-008NAc-2g
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:10:20 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec7059c4000e099@swg.vates.tech>)
 id 6a79f7dd-bab6-0a2a0a5309dd-0a2a45049fd2-30
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:20 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec7059c4000e099@swg.vates.tech>)
 id 6a79f7e9-b57f-0a2a45040019-b9ff1c128dc1-4
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:19 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec7059c4000e099.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:10:13 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 17DBA83637;
 Mon, 10 Aug 2026 18:10:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=4gwMD6zXp3l+68wW5VATdQU87ALcOqMpO+ibR2khxMk=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=qoT8XPsVnYTVy3ZrL7EMcKfbekmhFjlYs+vYaEbWIkE2S6AB/dYx3k6w/IsiqAmpaj9m9Her3
 Q/5jhKRN/kThgy/9RW/r4TqYU/SaKWPKxZIyoZZTmfYsd71S5hYxl0TCocyt+mT6W4P8HtDVuJq
 v8qMYdWyiZxX2ydCPKK6xpZiAmycYLQK8KTaOm9gB6i7Oek3U3NWFvuv2s8tiLz/H6bEmre05ez
 Y6w3FXK2nMNonZs83EhWtQWe1BYRzRRaBvKa/rMAfFLdurEDWglzubjkKVisfmzAArVPIf69E9t
 wnIHsdXEnK8/e4/1uIc/TzIltv1AMIcPFo/v1EkOPZpg==
X-Zone-Loop: 6278c9a605463988f0e2096657a2f01e6a13ac656913
x-campaign-type: default
x-transaction-id: 2f24dc91-d34a-4ced-b8d8-e3a2d1e72128
x-swg-uid: 01-78e2c1f4-9781-4c1e-a18a-116b488b716b
X-Mailer: Sweego
Message-ID:
 <1786378213.8631fc262581453bbf619ec5b2062170.19fec7059c4000e099@vates.tech>
x-swg-bid: 1786378213.8631fc262581453bbf619ec5b2062170.19fec7059c4000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 3/6] automation/qtb: add Python QTB framework with the console-test type
Date: Mon, 10 Aug 2026 18:09:53 +0200
In-Reply-To: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.204a.3666f13f27356d06.19fec70574c.2d6a0cec16cef1a9=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378213196
X-purgate-ID: tlsNG-ebf023/1786378220-528C9B50-72A61DF8/0/0
X-purgate-type: clean
X-purgate-size: 32316

---=Part.204a.3666f13f27356d06.19fec70574c.2d6a0cec16cef1a9=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Port qemu-smoke-riscv64=2Esh from shell to a Python QTB framework that driv=
es
QEMU over qtest/QMP and the console to run riscv64 smoke tests=2E

The framework is based on AMD's QTB (QEMU Test Bench) framework, which is
not yet upstream in QEMU but is planned to be soon=2E This is a riscv64
adaptation of it=2E

The framework:
  - parses a test config (config=2Eyaml) into typed machine descriptions
    (config=2Epy)=2E The host device tree of a machine is compiled on firs=
t
    use of MachineConfig=2Edt, so a run that never boots (`list`, or a
    config error) does not invoke dtc=2E
  - generates the Xen host device tree from a Jinja2 template and compiles
    it to a DTB with dtc (xen_dt=2Epy, dt=2Epy)=2E
  - assembles the QEMU command line in RiscvTestMachine (machine=2Epy),
    resolving artifact paths via paths=2Epy=2E
  - defines an abstract RiscvQtbTest base shared by every test type
    (qtb_test=2Epy)=2E
  - wires it together behind a CLI: the test type is a leading positional
    with `list` and `run` subcommands (qemu_smoke_riscv64=2Epy)=2E

console-test test type comes with it=2E It boots a machine from the shared
catalog and asserts every expected string is printed on Xen's own console
within the timeout=2E Its tests live in console-test=2Eyaml, which maps co=
nsole
indices to the expected output strings=2E This makes it straightforward to
add support for a domU console index once Xen provides it=2E

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
---
 automation/scripts/qemu_smoke_riscv64=2Epy      | 122 +++++++++++++++
 automation/scripts/qtb/__init__=2Epy            |   2 +
 automation/scripts/qtb/riscv/__init__=2Epy      |   9 ++
 automation/scripts/qtb/riscv/config=2Epy        | 125 +++++++++++++++
 automation/scripts/qtb/riscv/config=2Eyaml      |  19 +++
 =2E=2E=2E/qtb/riscv/console_test/__init__=2Epy        |   4 +
 =2E=2E=2E/qtb/riscv/console_test/console-test=2Eyaml  |  18 +++
 =2E=2E=2E/qtb/riscv/console_test/console_test=2Epy    | 145 +++++++++++++=
+++++
 automation/scripts/qtb/riscv/dt=2Epy            |  57 +++++++
 automation/scripts/qtb/riscv/machine=2Epy       |  56 +++++++
 automation/scripts/qtb/riscv/paths=2Epy         |  51 ++++++
 automation/scripts/qtb/riscv/qtb_test=2Epy      |  53 +++++++
 automation/scripts/qtb/riscv/xen_dt=2Epy        |  58 +++++++
 13 files changed, 719 insertions(+)
 create mode 100755 automation/scripts/qemu_smoke_riscv64=2Epy
 create mode 100644 automation/scripts/qtb/__init__=2Epy
 create mode 100644 automation/scripts/qtb/riscv/__init__=2Epy
 create mode 100644 automation/scripts/qtb/riscv/config=2Epy
 create mode 100644 automation/scripts/qtb/riscv/config=2Eyaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/__init__=2Ep=
y
 create mode 100644 automation/scripts/qtb/riscv/console_test/console-test=
=2Eyaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/console_test=
=2Epy
 create mode 100644 automation/scripts/qtb/riscv/dt=2Epy
 create mode 100644 automation/scripts/qtb/riscv/machine=2Epy
 create mode 100644 automation/scripts/qtb/riscv/paths=2Epy
 create mode 100644 automation/scripts/qtb/riscv/qtb_test=2Epy
 create mode 100644 automation/scripts/qtb/riscv/xen_dt=2Epy

diff --git a/automation/scripts/qemu_smoke_riscv64=2Epy b/automation/scrip=
ts/qemu_smoke_riscv64=2Epy
new file mode 100755
index 0000000000=2E=2Ef338fafcc2
--- /dev/null
+++ b/automation/scripts/qemu_smoke_riscv64=2Epy
@@ -0,0 +1,122 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""CLI launcher for the qtb riscv64 dom0less tests=2E
+
+The test type comes first (e=2Eg=2E `console-test`), then a command=2E Ea=
ch type
+reads its own config file, which ships with the type=2E
+
+Commands:
+    list  Print every test the type defines in the config, then exit=2E
+    run   Boot one test's machine under QEMU and drive it to a pass/fail
+          verdict=2E
+
+Usage:
+    =2E/qemu_smoke_riscv64=2Epy console-test list
+    =2E/qemu_smoke_riscv64=2Epy console-test run dom0less-1smp-0domu-1vcp=
u-aplic-imsic-null
+"""
+
+from __future__ import annotations
+
+import argparse
+import logging
+import sys
+from collections=2Eabc import Sequence
+from traceback import extract_tb, format_exc
+
+from qtb=2Eriscv import RiscvQtbTest, TEST_TYPES, RiscvTestMachine, clean=
up_temp_dir
+
+logger =3D logging=2EgetLogger(__name__)
+
+
+def _run_test(test: RiscvQtbTest, log_dir: str | None) -> int:
+    """Compile the machine's device trees, boot it, and run the test=2E""=
"
+    vm =3D RiscvTestMachine(test=2Emachine, timeout=3Dtest=2Etimeout, log=
_dir=3Dlog_dir)
+    try:
+        with vm:
+            vm=2Elaunch()
+            test=2Erun(vm)
+    except Exception as exc:
+        print(
+            f"FAIL: {test=2Ename}: {type(exc)=2E__name__}: {exc}",
+            file=3Dsys=2Estderr,
+            flush=3DTrue,
+        )
+        return 1
+
+    print(f"PASS: {test=2Ename}", flush=3DTrue)
+    return 0
+
+
+def _cmd_list(ns: argparse=2ENamespace) -> int:
+    """`<type> list`: print every test the type defines=2E"""
+    for name in ns=2Ecls=2Elist_tests(ns=2Ecls=2Econfig_file):
+        print(name)
+    return 0
+
+
+def _cmd_run(ns: argparse=2ENamespace) -> int:
+    """`<type> run`: build the named test and drive it to a verdict=2E"""
+    test =3D ns=2Ecls=2Efrom_config(ns=2Ecls=2Econfig_file, ns=2Etest)
+    return _run_test(test, ns=2Elog_dir)
+
+
+def setup_parser() -> argparse=2EArgumentParser:
+    parser =3D argparse=2EArgumentParser(
+        description=3D"Launch a qtb riscv64 dom0less test: "
+        "qemu_smoke_riscv64=2Epy <type> <command>=2E",
+    )
+    common_args =3D argparse=2EArgumentParser(add_help=3DFalse)
+    common_args=2Eadd_argument(
+        "-v", "--verbose", action=3D"store_true", help=3D"Print debug out=
put"
+    )
+    run_args =3D argparse=2EArgumentParser(add_help=3DFalse)
+    run_args=2Eadd_argument("test", help=3D"Name of the test to run=2E")
+    run_args=2Eadd_argument(
+        "--log-dir",
+        default=3DNone,
+        metavar=3D"DIR",
+        help=3D"Directory for all logs (QEMU process log, qtest, and the =
"
+        "consoles as con<N>=2Elog)=2E When unset, no logs are written=2E"=
,
+    )
+
+    # qemu_smoke_riscv64=2Epy <type> <command>
+    types =3D parser=2Eadd_subparsers(dest=3D"type", required=3DTrue)
+    for cls in TEST_TYPES:
+        desc =3D cls=2Edescription
+        cmds =3D types=2Eadd_parser(
+            cls=2Etype_id, help=3Ddesc, description=3Ddesc
+        )=2Eadd_subparsers(dest=3D"command", required=3DTrue)
+        cmds=2Eadd_parser(
+            "list",
+            parents=3D[common_args],
+            description=3Ddesc,
+            help=3D"List the tests for the type and exit=2E",
+        )=2Eset_defaults(func=3D_cmd_list, cls=3Dcls)
+        cmds=2Eadd_parser(
+            "run",
+            parents=3D[common_args, run_args],
+            description=3Ddesc,
+            help=3D"Run one test=2E",
+        )=2Eset_defaults(func=3D_cmd_run, cls=3Dcls)
+
+    return parser
+
+
+def main(argv: Sequence[str] | None =3D None) -> int:
+    ns =3D setup_parser()=2Eparse_args(argv)
+    logging=2EbasicConfig(
+        level=3Dlogging=2EDEBUG if ns=2Everbose else logging=2EWARNING, f=
ormat=3D"%(message)s"
+    )
+    try:
+        return ns=2Efunc(ns)
+    except Exception as exc:
+        logger=2Edebug(format_exc())
+        frame =3D extract_tb(exc=2E__traceback__)[-1]
+        print(f"{frame=2Efilename}:{frame=2Elineno}: {exc}")
+        return 2
+    finally:
+        cleanup_temp_dir()
+
+
+if __name__ =3D=3D "__main__":
+    sys=2Eexit(main())
diff --git a/automation/scripts/qtb/__init__=2Epy b/automation/scripts/qtb=
/__init__=2Epy
new file mode 100644
index 0000000000=2E=2Ea0e6e76cb2
--- /dev/null
+++ b/automation/scripts/qtb/__init__=2Epy
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""QTB (QEMU Test Bench) test frameworks=2E"""
diff --git a/automation/scripts/qtb/riscv/__init__=2Epy b/automation/scrip=
ts/qtb/riscv/__init__=2Epy
new file mode 100644
index 0000000000=2E=2E6a6c48be32
--- /dev/null
+++ b/automation/scripts/qtb/riscv/__init__=2Epy
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""QTB riscv64 test framework package=2E"""
+
+from =2Eqtb_test import RiscvQtbTest
+from =2Econsole_test import ConsoleTest
+from =2Emachine import RiscvTestMachine
+from =2Epaths import cleanup_temp_dir
+
+TEST_TYPES: tuple[type[RiscvQtbTest], =2E=2E=2E] =3D (ConsoleTest,)
diff --git a/automation/scripts/qtb/riscv/config=2Epy b/automation/scripts=
/qtb/riscv/config=2Epy
new file mode 100644
index 0000000000=2E=2E92b5ea0f55
--- /dev/null
+++ b/automation/scripts/qtb/riscv/config=2Epy
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""YAML config parser for qtb-based Xen riscv64 tests=2E
+
+Parsing steps:
+    - validate the YAML
+    - build the dataclasses: the host device tree is compiled on first us=
e
+      of MachineConfig=2Edt
+"""
+
+from __future__ import annotations
+
+import functools
+import inspect
+from dataclasses import dataclass
+from functools import cached_property
+from pathlib import Path
+
+import yaml
+
+from =2Epaths import resolve_binary, resolve_path
+from =2Exen_dt import DeviceTree, build_xen_device_tree
+
+XEN_MMU_TYPE_DEFAULT: str =3D "sv48"
+XEN_BOOTARGS_DEFAULT: str =3D ""
+
+MACHINE_MEMORY: int =3D 2048
+MACHINE_INTERRUPT_CONTROLLER: str =3D "aplic-imsic"
+
+
+def required_keys(argument_name: str, keys: set, label: str =3D ""):
+    """Validate the dict passed as `argument_name` has every key in `keys=
`=2E"""
+    keys =3D set(keys)
+
+    def decorate(func):
+        sig =3D inspect=2Esignature(func)
+
+        @functools=2Ewraps(func)
+        def wrapper(*args, **kwargs):
+            arg =3D sig=2Ebind(*args, **kwargs)=2Earguments[argument_name=
]
+            missing =3D keys - arg=2Ekeys()
+            if missing:
+                raise ValueError(
+                    f"{label or func=2E__name__} missing keys: {sorted(mi=
ssing)}"
+                )
+            return func(*args, **kwargs)
+
+        return wrapper
+
+    return decorate
+
+
+@dataclass
+class BinariesConfig:
+    qemu: Path
+    firmware: Path
+    xen: Path
+
+
+@required_keys("raw", {"qemu", "firmware", "xen"}, label=3D"binaries conf=
ig")
+def _parse_binaries(raw: dict) -> BinariesConfig:
+    return BinariesConfig(
+        qemu=3Dresolve_binary(raw["qemu"]),
+        firmware=3Dresolve_binary(raw["firmware"]),
+        xen=3Dresolve_binary(raw["xen"]),
+    )
+
+
+@required_keys("raw", {"pcpu"}, label=3D"machine config")
+def _parse_machine(
+    raw: dict,
+    binaries: BinariesConfig,
+    machine: str,
+) -> MachineConfig:
+    return MachineConfig(
+        name=3Dmachine,
+        pcpu=3Draw["pcpu"],
+        binaries=3Dbinaries,
+        mmu_type=3Draw=2Eget("mmu_type", XEN_MMU_TYPE_DEFAULT),
+        xen_bootargs=3Draw=2Eget("xen_bootargs", XEN_BOOTARGS_DEFAULT),
+    )
+
+
+@dataclass(frozen=3DTrue)
+class MachineConfig:
+    """One named machine: the test-agnostic description of what to boot=
=2E
+
+    A machine is reusable across test types; a test (see RiscvQtbTest
+    subclasses) picks a machine by name and layers its own parameters on =
top=2E
+    """
+
+    name: str
+    pcpu: int
+    binaries: BinariesConfig
+    mmu_type: str  # Xen (host) MMU type, injected into the host dts cpus=
=2E
+    xen_bootargs: str
+
+    @classmethod
+    def from_config(cls, file_name: str, machine: str) -> MachineConfig:
+        """Build only the single named machine from the catalog at `path`=
=2E
+
+        A test run boots one machine, so there is no need to construct th=
e
+        whole catalog: parse the YAML, validate the shared binaries, and
+        build just the requested entry=2E
+        """
+        fpath: Path =3D resolve_path(file_name)
+        raw: dict =3D yaml=2Esafe_load(fpath=2Eread_text())
+
+        required =3D ("binaries", "machines")
+        missing =3D [k for k in required if k not in raw]
+        if missing:
+            raise ValueError(f"Global config {file_name} missing keys: {m=
issing}")
+
+        binaries: BinariesConfig =3D _parse_binaries(raw["binaries"])
+
+        machines =3D raw["machines"]
+        if machine not in machines:
+            known =3D ", "=2Ejoin(sorted(machines)) or "(none)"
+            raise ValueError(f"unknown machine {machine!r}; known machine=
s: {known}")
+
+        return _parse_machine(machines[machine], binaries, machine)
+
+    @cached_property
+    def dt(self) -> DeviceTree:
+        """Host device tree, compiled on first use=2E"""
+        return build_xen_device_tree(self)
diff --git a/automation/scripts/qtb/riscv/config=2Eyaml b/automation/scrip=
ts/qtb/riscv/config=2Eyaml
new file mode 100644
index 0000000000=2E=2Ec1b69ad441
--- /dev/null
+++ b/automation/scripts/qtb/riscv/config=2Eyaml
@@ -0,0 +1,19 @@
+# Shared config for the qtb riscv64 tests
+#
+# A machine is the test-agnostic description of what to boot (cpus, Xen c=
ommand
+# line)=2E Test YAMLs (e=2Eg=2E console-test=2Eyaml) pick a machine by na=
me and layer
+# their own parameters on top=2E
+#
+# Path resolution (see paths=2Epy): `binaries:` entries resolve against
+# $QTB_BINARIES_DIR env var if defined else `binaries`=2E Absolute paths =
used
+# as-is=2E
+
+binaries:
+  qemu:     qemu-system-riscv64
+  firmware: opensbi-riscv64-generic-fw_dynamic=2Ebin
+  xen:      xen
+
+machines:
+  dom0less-1smp-0domu-1vcpu-aplic-imsic-null:
+    xen_bootargs: "sched=3Dnull"
+    pcpu: 1
diff --git a/automation/scripts/qtb/riscv/console_test/__init__=2Epy b/aut=
omation/scripts/qtb/riscv/console_test/__init__=2Epy
new file mode 100644
index 0000000000=2E=2E5db5569965
--- /dev/null
+++ b/automation/scripts/qtb/riscv/console_test/__init__=2Epy
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""console-test type package=2E"""
+
+from =2Econsole_test import ConsoleTest
diff --git a/automation/scripts/qtb/riscv/console_test/console-test=2Eyaml=
 b/automation/scripts/qtb/riscv/console_test/console-test=2Eyaml
new file mode 100644
index 0000000000=2E=2Ecec0edc510
--- /dev/null
+++ b/automation/scripts/qtb/riscv/console_test/console-test=2Eyaml
@@ -0,0 +1,18 @@
+# Console string expectation test (run with: qemu_smoke_riscv64=2Epy cons=
ole-test run <test>)=2E
+#
+# Each test uses a machine from config=2Eyaml and maps a console index to=
 the list
+# of string(s) expected on that console: 0 is Xen's own console=2E The ru=
nner boots
+# the machine and asserts each string is printed within the timeout=2E No=
thing is
+# injected=2E
+#
+# Test options:
+#   timeout: int  # timeout between each string match (in seconds)
+#   attempts: int # number of tries for a wait before failing=2E Default =
3 (min =3D 1)
+
+machine_catalog: config=2Eyaml
+
+tests:
+  dom0less-1smp-0domu-1vcpu-aplic-imsic-null:
+    machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null
+    expect:
+      0: ["All set up"]
diff --git a/automation/scripts/qtb/riscv/console_test/console_test=2Epy b=
/automation/scripts/qtb/riscv/console_test/console_test=2Epy
new file mode 100644
index 0000000000=2E=2E95540fd388
--- /dev/null
+++ b/automation/scripts/qtb/riscv/console_test/console_test=2Epy
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Console string expectation test (`type: console-test`)=2E
+
+Per console: assert each expected string is printed within the timeout=2E
+Nothing is injected; this only watches console output=2E
+
+YAML (console-test=2Eyaml): each test names the machine it boots (tests m=
ay
+share one) and maps a console index to the string(s) expected on it: 0 is
+Xen's own console=2E
+
+    machine_catalog: config=2Eyaml
+    tests:
+      dom0less-1smp-0domu-1vcpu-aplic-imsic-null:  # test name (run posit=
ional)
+        machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null  # from confi=
g=2Eyaml
+        expect:                                    # console index -> str=
ing(s)
+          0: [All set up]
+"""
+
+from __future__ import annotations
+
+import logging
+from typing import ClassVar
+
+import pexpect
+import yaml
+
+from =2E=2Epaths import resolve_path
+from =2E=2Econfig import MachineConfig, required_keys
+from =2E=2Eqtb_test import TIMEOUT_DEFAULT, RiscvQtbTest
+from =2E=2Emachine import RiscvTestMachine
+
+logger =3D logging=2EgetLogger(__name__)
+
+TYPE_ID: str =3D "console-test"
+
+CONFIG_FILE_DEFAULT: str =3D "console_test/console-test=2Eyaml"
+DESCRIPTION_DEFAULT: str =3D "Assert expected string(s) are printed on th=
e Xen console"
+ATTEMPTS_DEFAULT: int =3D 3
+
+XEN_CONS_IDX: int =3D 0
+
+
+class ConsoleTest(RiscvQtbTest):
+    type_id: ClassVar[str] =3D TYPE_ID
+    description: ClassVar[str] =3D DESCRIPTION_DEFAULT
+    config_file: ClassVar[str] =3D CONFIG_FILE_DEFAULT
+
+    def __init__(self, raw: dict, test_name: str) -> None:
+        self=2Ename, self=2Edata, self=2Emachine =3D self=2E_parse_test_c=
fg(raw, test_name)
+
+        self=2Eexpect =3D self=2Edata["expect"]  # expected console strin=
g
+
+        self=2Etimeout =3D int(self=2Edata=2Eget("timeout", TIMEOUT_DEFAU=
LT))
+        if self=2Etimeout < 1:
+            raise ValueError("timeout < 1, must be at least 1")
+
+        self=2Eattempts =3D int(self=2Edata=2Eget("attempts", ATTEMPTS_DE=
FAULT))
+        if self=2Eattempts < 1:
+            raise ValueError("attempts < 1, must be at least 1")
+
+    @staticmethod
+    def _load_yaml(path) -> dict:
+        return yaml=2Esafe_load(resolve_path(path)=2Eread_text())
+
+    @classmethod
+    def from_config(cls, config_file: str, test_name: str) -> ConsoleTest=
:
+        return cls(cls=2E_load_yaml(config_file), test_name)
+
+    @staticmethod
+    @required_keys("test_data", {"machine", "expect"})
+    def _parse_test_data(
+        machine_catalog: str, test_data: dict, test_name: str
+    ) -> tuple[str, dict, MachineConfig]:
+        """Parse test data dictionary"""
+        test_machine =3D MachineConfig=2Efrom_config(machine_catalog, tes=
t_data["machine"])
+
+        def invalid(why: str) -> ValueError:
+            return ValueError(
+                f"test {test_name!r}: {why}; expected "
+                f"{{{XEN_CONS_IDX}: ['str1', 'str2', =2E=2E=2E]}}"
+            )
+
+        expect =3D test_data["expect"]
+        if not isinstance(expect, dict) or expect=2Ekeys() !=3D {XEN_CONS=
_IDX}:
+            raise invalid(
+                f"expect must map console index {XEN_CONS_IDX} (Xen's own=
 "
+                f"console, the only one) and nothing else, got {expect!r}=
"
+            )
+        strings =3D expect[XEN_CONS_IDX]
+        if not isinstance(strings, list):
+            raise invalid(
+                f"{ConsoleTest=2Econfig_file} expects a list of string(s)=
, "
+                f"got {type(strings)=2E__name__}"
+            )
+        if not strings:
+            raise invalid("Xen has no expected string")
+        if not all(isinstance(s, str) and s for s in strings):
+            raise invalid(f"Xen expects non-empty strings, got {strings!r=
}")
+        return (test_name, test_data, test_machine)
+
+    @staticmethod
+    @required_keys("raw", {"machine_catalog", "tests"})
+    def _parse_test_cfg(raw: dict, test_name: str) -> tuple[str, dict, Ma=
chineConfig]:
+        """Read the config: return the named test dict and its machine=2E=
"""
+
+        tests =3D raw["tests"]
+        if test_name not in tests:
+            known =3D ", "=2Ejoin(sorted(tests)) or "(none)"
+            raise ValueError(f"unknown test {test_name!r}; known tests: {=
known}")
+
+        test_data =3D tests[test_name]
+        return ConsoleTest=2E_parse_test_data(
+            raw["machine_catalog"], test_data, test_name
+        )
+
+    @staticmethod
+    def list_tests(config_file: str) -> list[str]:
+        tests =3D ConsoleTest=2E_load_yaml(config_file)=2Eget("tests")
+        if not tests:
+            logger=2Ewarning("no 'tests' key found in %s", config_file)
+            return []
+        return list(tests)
+
+    @staticmethod
+    def _console(vm: RiscvTestMachine):
+        """Xen's own console (con0)=2E"""
+        if vm=2Econsole is None:
+            raise RuntimeError("Xen console not wired up, machine not lau=
nched?")
+        return vm=2Econsole
+
+    def run(self, vm: RiscvTestMachine) -> None:
+        cons =3D self=2E_console(vm)
+        for strings in self=2Eexpect=2Evalues():
+            for s in strings:
+                self=2E_expect_string(cons, s)
+
+    def _expect_string(self, cons, expected: str) -> None:
+        """Wait for `expected` on the console, retrying on timeout=2E"""
+        for attempt in range(self=2Eattempts):
+            try:
+                cons=2Eexpect_exact(expected, timeout=3Dself=2Etimeout)
+                return
+            except pexpect=2ETIMEOUT:
+                if attempt =3D=3D self=2Eattempts - 1:
+                    raise
diff --git a/automation/scripts/qtb/riscv/dt=2Epy b/automation/scripts/qtb=
/riscv/dt=2Epy
new file mode 100644
index 0000000000=2E=2Ef0376979e5
--- /dev/null
+++ b/automation/scripts/qtb/riscv/dt=2Epy
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Device tree (DT) handling: compile a =2Edts source into a =2Edtb"""
+
+from __future__ import annotations
+
+import logging
+import subprocess
+from pathlib import Path
+
+logger =3D logging=2EgetLogger(__name__)
+
+
+def _compile_dts(src: Path, out: Path):
+    """Run dtc to compile =2Edts `src` into the =2Edtb file at `out`"""
+    try:
+        p =3D subprocess=2Erun(
+            ["dtc", "-I", "dts", "-O", "dtb", "-o", str(out), str(src)],
+            check=3DTrue,
+            capture_output=3DTrue,
+            text=3DTrue,
+        )
+        logger=2Edebug("dtc %s: stdout: %s stderr: %s", src, p=2Estdout, =
p=2Estderr)
+
+    except FileNotFoundError as e:
+        raise RuntimeError("dtc not found in PATH; install device-tree-co=
mpiler") from e
+    except subprocess=2ECalledProcessError as e:
+        raise RuntimeError(
+            f"dtc failed on {str(src)!r} (exit {e=2Ereturncode}):\n"
+            f" stdout: {e=2Estdout}\n stderr: {e=2Estderr}"
+        ) from e
+
+
+def compile_to_dtb(src: Path, out: Path) -> Path:
+    """
+    Compile a =2Edts source to a =2Edtb under out dir and return the =2Ed=
tb path=2E
+
+    Raises FileNotFoundError if `src` or `out` don't exist=2E
+    """
+    if not src=2Eexists():
+        raise FileNotFoundError(
+            f"Device tree source {str(src)!r} not found"
+        )
+
+    if not out=2Eexists():
+        raise FileNotFoundError(f"Device Tree output dir: {out} doesn't e=
xist")
+
+    dtb =3D out / (src=2Estem + "=2Edtb")
+    _compile_dts(src, dtb)
+    return dtb
+
+
+def write_dts(text: str, name: str, out_dir: Path) -> Path:
+    """Write generated =2Edts text to <out_dir>/<name>=2Edts; return its =
path=2E"""
+    src =3D out_dir / f"{name}=2Edts"
+    src=2Eparent=2Emkdir(parents=3DTrue, exist_ok=3DTrue)
+    src=2Ewrite_text(text)
+    return src
diff --git a/automation/scripts/qtb/riscv/machine=2Epy b/automation/script=
s/qtb/riscv/machine=2Epy
new file mode 100644
index 0000000000=2E=2E9ea44ffc4e
--- /dev/null
+++ b/automation/scripts/qtb/riscv/machine=2Epy
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""QtbMachine for riscv64=2E"""
+
+from __future__ import annotations
+
+from collections=2Eabc import Sequence
+
+from qemu=2Eqtb import QtbMachine
+
+from =2Econfig import MACHINE_INTERRUPT_CONTROLLER, MACHINE_MEMORY, Machi=
neConfig
+
+
+class RiscvTestMachine(QtbMachine):
+    arch_name =3D "riscv64"
+    gdb_arch =3D "riscv:rv64"
+
+    def __init__(
+        self,
+        mc: MachineConfig,
+        *,
+        timeout: int,
+        log_dir: str | None =3D None,
+    ) -> None:
+        self=2Emachine_conf =3D mc
+        super()=2E__init__(
+            memory=3DMACHINE_MEMORY,
+            cpus=3Dmc=2Epcpu,
+            mirror_console=3DFalse,
+            timeout=3Dtimeout,
+            log_dir=3Dlog_dir,
+        )
+
+    def _machine_args(self, memory: int, cpus: int) -> Sequence[str]:
+        machine =3D self=2Emachine_conf
+        machine_opt =3D f"virt,aclint=3Doff,aia=3D{MACHINE_INTERRUPT_CONT=
ROLLER}"
+        # Xen has no sstc support yet=2E
+        cpu_opt =3D "rv64,svpbmt=3Don,smstateen=3Don,sstc=3Doff"
+        return [
+            "-dtb",
+            str(machine=2Edt=2Edtb),
+            "-M",
+            machine_opt,
+            "-cpu",
+            cpu_opt,
+            "-smp",
+            str(cpus),
+            "-m",
+            str(memory),
+            "-bios",
+            str(machine=2Ebinaries=2Efirmware),
+            "-kernel",
+            str(machine=2Ebinaries=2Exen),
+        ]
+
+    def _resolve_binary(self) -> str:
+        return str(self=2Emachine_conf=2Ebinaries=2Eqemu)
diff --git a/automation/scripts/qtb/riscv/paths=2Epy b/automation/scripts/=
qtb/riscv/paths=2Epy
new file mode 100644
index 0000000000=2E=2E94a134530f
--- /dev/null
+++ b/automation/scripts/qtb/riscv/paths=2Epy
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Path helpers: resolve pkg-relative paths=2E"""
+
+from __future__ import annotations
+
+import os
+import tempfile
+from functools import lru_cache
+from pathlib import Path
+
+# Every relative path in this module is resolved against this base=2E
+_BASE =3D Path(__file__)=2Eresolve()=2Eparent
+
+# Build artifacts (qemu, firmware, xen) base, overridable for CI=2E
+_BINARIES_BASE =3D Path(os=2Eenviron=2Eget("QTB_BINARIES_DIR") or _BASE /=
 "binaries")
+
+
+@lru_cache(maxsize=3D1)
+def _temp_dir_handle() -> tempfile=2ETemporaryDirectory:
+    return tempfile=2ETemporaryDirectory(prefix=3D"qtb-")
+
+
+def temp_dir() -> Path:
+    """Process-wide scratch dir for generated/compiled artifacts (singlet=
on)=2E"""
+    return Path(_temp_dir_handle()=2Ename)
+
+
+def cleanup_temp_dir() -> None:
+    """Remove the scratch dir, if one was created, and clear the cache=2E=
"""
+    if _temp_dir_handle=2Ecache_info()=2Ecurrsize:
+        _temp_dir_handle()=2Ecleanup()
+        _temp_dir_handle=2Ecache_clear()
+
+
+def resolve_path(file_name: str) -> Path:
+    """Resolve `file_name` against _BASE, absolute paths pass through=2E"=
""
+    return _resolve_under(file_name, _BASE)
+
+
+def resolve_binary(file_name: str) -> Path:
+    """Resolve a build artifact against _BINARIES_BASE, absolute paths pa=
ss through=2E"""
+    return _resolve_under(file_name, _BINARIES_BASE)
+
+
+def _resolve_under(file_name: str, base: Path) -> Path:
+    """Resolve `file_name` against `base`, absolute paths pass through=2E=
"""
+    p =3D Path(file_name)
+    path =3D p if p=2Eis_absolute() else base / p
+    if not path=2Eexists():
+        raise FileNotFoundError(f"cannot resolve {str(path)!r}: does not =
exist")
+    return path
diff --git a/automation/scripts/qtb/riscv/qtb_test=2Epy b/automation/scrip=
ts/qtb/riscv/qtb_test=2Epy
new file mode 100644
index 0000000000=2E=2E872fbc2fa9
--- /dev/null
+++ b/automation/scripts/qtb/riscv/qtb_test=2Epy
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Abstract base for the qtb riscv64 test types=2E
+
+A test type is a RiscvQtbTest subclass owning a config file that describe=
s its
+tests, each bound to a machine from the shared catalog=2E
+"""
+
+from __future__ import annotations
+
+from abc import ABC, abstractmethod
+from typing import ClassVar
+
+from =2Econfig import MachineConfig
+from =2Emachine import RiscvTestMachine
+
+# Default per-test timeout (seconds)
+TIMEOUT_DEFAULT: int =3D 120
+
+
+class RiscvQtbTest(ABC):
+    """One runnable test bound to the machine it boots=2E
+
+    A subclass sets `type_id`, `description`, and `config_file`, and impl=
ements
+    `from_config` to parse its config file, `list_tests` to enumerate the=
 tests
+    it declares, and `run` to drive the test logic=2E
+    """
+
+    # Set by each concrete subclass=2E
+    type_id: ClassVar[str] =3D ""
+    # One-line summary of what the type does, shown in the CLI help=2E
+    description: ClassVar[str] =3D ""
+    # Config file the type reads its tests from, resolved pkg-relative=2E
+    config_file: ClassVar[str] =3D ""
+
+    # Set by the subclass parser=2E
+    name: str
+    data: dict
+    machine: MachineConfig
+    timeout: int =3D TIMEOUT_DEFAULT
+
+    @classmethod
+    @abstractmethod
+    def from_config(cls, config_file: str, test_name: str) -> RiscvQtbTes=
t:
+        """Build the test named `test_name` from `config_file`=2E"""
+
+    @staticmethod
+    @abstractmethod
+    def list_tests(config_file: str) -> list[str]:
+        """Return the names of every test declared in the config file=2E"=
""
+
+    @abstractmethod
+    def run(self, vm: RiscvTestMachine) -> None:
+        """Drive the running machine and assert the expected result=2E"""
diff --git a/automation/scripts/qtb/riscv/xen_dt=2Epy b/automation/scripts=
/qtb/riscv/xen_dt=2Epy
new file mode 100644
index 0000000000=2E=2E8881b01b36
--- /dev/null
+++ b/automation/scripts/qtb/riscv/xen_dt=2Epy
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2=2E0-only
+"""Build the Xen host device tree for a MachineConfig=2E
+
+The tree is rendered from its Jinja2 template (dts/qemu-host=2Edts=2Ej2),=
 which
+takes the hart count, the Xen MMU type and the Xen command line, then com=
piled
+to a DTB with dtc=2E
+"""
+
+from __future__ import annotations
+
+from dataclasses import dataclass
+from functools import lru_cache
+from pathlib import Path
+from typing import TYPE_CHECKING
+from jinja2 import Environment, FileSystemLoader
+
+from =2Epaths import resolve_path, temp_dir
+from =2Edt import compile_to_dtb, write_dts
+
+if TYPE_CHECKING:  # config imports this module, so only import it for ty=
ping=2E
+    from =2Econfig import MachineConfig
+
+# Directory holding the Jinja2 platform device tree templates=2E
+_DTS_DIR =3D "dts"
+
+
+@dataclass(frozen=3DTrue)
+class DeviceTree:
+    """Compiled device trees for one machine launch=2E"""
+
+    dts: Path
+    dtb: Path
+
+
+@lru_cache(maxsize=3D1)
+def _env() -> Environment:
+    return Environment(
+        loader=3DFileSystemLoader(resolve_path(_DTS_DIR)),
+        keep_trailing_newline=3DTrue,
+    )
+
+
+def _render_xen_dts(machine: MachineConfig) -> str:
+    """Render the Xen host device tree source text for `machine`=2E"""
+    tmpl =3D _env()=2Eget_template("qemu-host=2Edts=2Ej2")
+    return tmpl=2Erender(
+        ncpus=3Dmachine=2Epcpu,
+        mmu_type=3Dmachine=2Emmu_type,
+        xen_bootargs=3Dmachine=2Exen_bootargs,
+    )
+
+
+def build_xen_device_tree(machine: MachineConfig) -> DeviceTree:
+    """Compile `machine` device tree into the shared scratch dir=2E"""
+    out =3D temp_dir()
+    dts: Path =3D write_dts(_render_xen_dts(machine), machine=2Ename, out=
)
+    dtb: Path =3D compile_to_dtb(dts, out)
+    return DeviceTree(dts=3Ddts, dtb=3Ddtb)


-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.204a.3666f13f27356d06.19fec70574c.2d6a0cec16cef1a9=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:10:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:10:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387634.1628888 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZw-0003Qy-7s; Mon, 10 Aug 2026 16:10:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387634.1628888; Mon, 10 Aug 2026 16:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSZw-0003Qr-5F; Mon, 10 Aug 2026 16:10:20 +0000
Received: by outflank-mailman (input) for mailman id 1387634;
 Mon, 10 Aug 2026 16:10:18 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtSZu-0003Qe-57
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:10:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSZs-00Exue-DC
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:10:16 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705643000e099@swg.vates.tech>)
 id 6a79f79b-e002-0a2a0a5209dd-0a2a45018e00-36
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:16 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705643000e099@swg.vates.tech>)
 id 6a79f7e7-5984-0a2a45010019-b9ff1c23956d-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:16 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec705643000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:10:12 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 1015683637;
 Mon, 10 Aug 2026 18:10:12 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=HPY5KGo/VIwCujbKN7MPUq1fMcqLDozezWN+GUEapgE=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=NmKVVJOZy+xIPZzg6dOvGfZBZk48PkhyGPAQSxFQ/Y6IptkNe1TMzrJ3IOLKZPlCInxryPJAk
 5AJ60KQ9Pif7ELtmqjukClyNlq7eFfG62KsDXIZuSTaWpL92FsppVRGF8c/ox7sDX4bTuzpzOAe
 DWX3nIjmvRg+FA/+TDrUQyYPbAhDmtv/pHfJYCaNit1cA+Xv/zMlLcBtebAsTHfTmUZzT/vbTTW
 h89tyJmKqb1qVWott6OapujF5lJ11O6rg0OXpdo0i/O8DCWxVOEh5g0kc3MM1LQi7rP2Fh6MciX
 2VzEboj+5r1jKzrCCHfkmXuRH6EIWApZEHbTsRvClzfw==
X-Zone-Loop: 8daa169fd0630ec516f0a8d154ab406ac16cf6fa2551
x-campaign-type: default
x-transaction-id: 467ac744-8f84-4df0-8cbc-3a4c19cac1eb
x-swg-uid: 01-ed8ec477-e6d0-4af5-85db-9867530b7a14
X-Mailer: Sweego
Message-ID:
 <1786378213.8631fc262581453bbf619ec5b2062170.19fec705643000e099@vates.tech>
x-swg-bid: 1786378213.8631fc262581453bbf619ec5b2062170.19fec705643000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 1/6 TEST-ARTIFACTS] Add a QTB container to run the Xen riscv64 tests
Date: Mon, 10 Aug 2026 18:09:51 +0200
In-Reply-To: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2048.292bd88b0601f785.19fec705373.26d4cb990fb59c26=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378212212
X-purgate-ID: tlsNG-d62444/1786378216-1F86F757-4B913EE8/10/63158204843
X-purgate-type: spam
X-purgate-size: 3421

---=Part.2048.292bd88b0601f785.19fec705373.26d4cb990fb59c26=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

QTB (QEMU Test Bench) is a Python framework, developed as part of AMD's Xen
safety initiative, that drives a live QEMU instance over qtest and QMP=2E =
It
gives a test full access to the machine while the emulation runs: read and
write the consoles, inspect the registers and the memory, inject interrupt=
s=2E

For now the riscv64 CI tests only use it to read the Xen console in the
smoke test, since DomU is not supported yet=2E Once it is, the same
framework will read and write the DomU consoles and inject IRQs, so the
tests can assert an interrupt reaches the expected guest and vCPU=2E

QTB is not upstream in QEMU yet, though it is planned to be, so get the
framework from AMD's fork gitlab=2Ecom/xen-project/people/amd/qemu and
pip-installs qemu=2Eqtb from it=2E

Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
---
 containerize                            |  1 +
 images/debian/13-qtb-riscv64=2Edockerfile | 45 +++++++++++++++++++++++++
 2 files changed, 46 insertions(+)
 create mode 100644 images/debian/13-qtb-riscv64=2Edockerfile

diff --git a/containerize b/containerize
index dad9afa=2E=2E477b670 100755
--- a/containerize
+++ b/containerize
@@ -31,6 +31,7 @@ case "_${CONTAINER}" in
     _alpine-3=2E24-arm64-base) CONTAINER=3D"${BASE}/alpine:3=2E24-arm64-b=
ase" ;;
     _alpine-3=2E24-arm64-build) CONTAINER=3D"${BASE}/alpine:3=2E24-arm64-=
build" ;;
     _alpine-3=2E24-x86_64-base) CONTAINER=3D"${BASE}/alpine:3=2E24-x86_64=
-base" ;;
+    _debian-13-qtb-riscv64) CONTAINER=3D"${BASE}/debian:13-qtb-riscv64" ;=
;
     _alpine-3=2E24-x86_64-build|_) CONTAINER=3D"${BASE}/alpine:3=2E24-x86=
_64-build" ;;
 esac
=20
diff --git a/images/debian/13-qtb-riscv64=2Edockerfile b/images/debian/13-=
qtb-riscv64=2Edockerfile
new file mode 100644
index 0000000=2E=2E86215d3
--- /dev/null
+++ b/images/debian/13-qtb-riscv64=2Edockerfile
@@ -0,0 +1,45 @@
+# syntax=3Ddocker/dockerfile:1
+FROM --platform=3Dlinux/amd64 debian:trixie-slim
+LABEL maintainer=2Ename=3D"The Xen Project"
+LABEL maintainer=2Eemail=3D"xen-devel@lists=2Exenproject=2Eorg"
+
+ENV DEBIAN_FRONTEND=3Dnoninteractive
+
+ARG QEMU_REPO=3Dhttps://gitlab=2Ecom/xen-project/people/amd/qemu=2Egit
+ARG QEMU_COMMIT=3D24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab
+
+RUN <<EOF
+#!/bin/bash
+    set -eu
+
+    useradd --create-home user
+
+    apt-get update
+
+    DEPS=3D(# Base environment
+        ca-certificates
+        device-tree-compiler
+        git
+        python3-jinja2
+        python3-minimal
+        python3-pip
+        python3-yaml
+
+        # Qemu for test phase
+        qemu-system-riscv64
+    )
+
+    apt-get -y --no-install-recommends install "${DEPS[@]}"
+
+    # QTB framework
+    git init /tmp/qemu
+    git -C /tmp/qemu fetch --depth 1 "$QEMU_REPO" "$QEMU_COMMIT"
+    git -C /tmp/qemu checkout FETCH_HEAD
+    pip install --break-system-packages /tmp/qemu/python[qtb]
+
+    rm -rf /tmp/qemu
+    rm -rf /var/lib/apt/lists/*
+EOF
+
+USER user
+WORKDIR /build


-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.2048.292bd88b0601f785.19fec705373.26d4cb990fb59c26=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:10:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:10:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387638.1628924 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSa1-0004Jd-8L; Mon, 10 Aug 2026 16:10:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387638.1628924; Mon, 10 Aug 2026 16:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSa1-0004JW-5Z; Mon, 10 Aug 2026 16:10:25 +0000
Received: by outflank-mailman (input) for mailman id 1387638;
 Mon, 10 Aug 2026 16:10:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705d4f000e099@swg.vates.tech>)
 id 1wtSZz-00043O-34
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:10:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSZy-00Exz0-GH
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:10:22 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705d4f000e099@swg.vates.tech>)
 id 6a79f79b-e002-0a2a0a5209dd-0a2a45018e00-44
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:22 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705d4f000e099@swg.vates.tech>)
 id 6a79f7e7-5984-0a2a45010019-b9ff1c23956d-5
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:22 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec705d4f000e099.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:10:14 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 05DC283637;
 Mon, 10 Aug 2026 18:10:14 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=9di4me1yvbuqspU7BIqnNXEvi4rg8NzN9nAZG65MC1c=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=S4iKRsLkA2y1u2Ia4FcWyfUJVnRPLSFSxmsw8CDHpDLBHBlUfrKtd8sSSpprTlK4YF0/jD6Ki
 ccAz9hHgpmjeVe7ImQPNOTq2qH9Pa8F9jWM9aBH9DGLShlqzig9vMB5/BfZQtlxD+9x2o19t+Wi
 FOmXH3+PPEljfBQJhQC1letP/Ce6V22t/XjueAb15pQnwAUt/iZqdNzoZSezQ6yyf60+tl28vro
 UnF//RRdAxCEt47u2jgiTPOQAV2pVjuwNW0HzoSvsy2ZGkdgmVlYaKtyaFqQB4AkWURqaDKaBXv
 ru3sd8M36u/UUxEQlaKIAlwpB5uwiS+iQEx6AA7+ssWQ==
X-Zone-Loop: ab6935da73f37db8225160c8308ea7678a0ff97380b8
x-campaign-type: default
x-transaction-id: 52953e68-b175-457e-a583-68c71d0e9933
x-swg-uid: 01-a6312d36-96ce-43c8-831e-5c6f590a83d4
X-Mailer: Sweego
Message-ID:
 <1786378214.8631fc262581453bbf619ec5b2062170.19fec705d4f000e099@vates.tech>
x-swg-bid: 1786378214.8631fc262581453bbf619ec5b2062170.19fec705d4f000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 5/6] automation/qtb: add QTB framework README
Date: Mon, 10 Aug 2026 18:09:55 +0200
In-Reply-To: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.204c.8057a2cfa8722de8.19fec705adb.8862fb7305d5dccf=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378214107
X-purgate-ID: tlsNG-d62444/1786378222-1FE68757-1E8E5302/0/0
X-purgate-type: clean
X-purgate-size: 8331

---=Part.204c.8057a2cfa8722de8.19fec705adb.8862fb7305d5dccf=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Document the qtb riscv64 test framework in a README=2E

It covers:
  - the core concepts (machine, test type, test) and how they map to files
  - the source files layout
  - the CLI: `qemu_smoke_riscv64=2Epy <type> <command>`, with "console-tes=
t"
    as the type
  - the config files: the machine catalog and a type's own `<type>=2Eyaml`
  - the Jinja2 device-tree templates under dts/
  - how to add a test (config-only) and how to add a new test type=2E

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
---
 automation/scripts/qtb/riscv/README=2Emd | 182 +++++++++++++++++++++++++
 1 file changed, 182 insertions(+)
 create mode 100644 automation/scripts/qtb/riscv/README=2Emd

diff --git a/automation/scripts/qtb/riscv/README=2Emd b/automation/scripts=
/qtb/riscv/README=2Emd
new file mode 100644
index 0000000000=2E=2Effcb027bbc
--- /dev/null
+++ b/automation/scripts/qtb/riscv/README=2Emd
@@ -0,0 +1,182 @@
+qtb riscv64 test framework
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+
+A small framework that boots Xen under QEMU on riscv64 and drives it to a
+pass/fail verdict automatically from its console output=2E
+
+It is built on QEMU's qtb (QEMU Test Bench) Python package, which gives
+programmatic control of a QEMU process over QMP and qtest, plus access to=
 the
+consoles=2E
+
+What it does
+------------
+
+1=2E Reads a machine description (what to boot: cpus, Xen command line) a=
nd a
+   test description (what to assert)=2E
+2=2E Generates the host device tree=2E
+3=2E Launches QEMU with Xen and the firmware wired in=2E
+4=2E Reads the console and checks what Xen printed=2E
+
+Core concepts
+-------------
+
+- Machine: test-agnostic description of what to boot=2E Reusable across t=
est
+  types=2E `config=2Eyaml` -> `MachineConfig`=2E
+- Test type: a `RiscvQtbTest` subclass implementing the logic of a kind o=
f test
+  (e=2Eg=2E `console-test`)=2E Identified by `type_id`=2E See `console_te=
st/`=2E
+- Test: one named, runnable instance of a type: a machine plus the type's
+  parameters=2E Lives in the type's `<type>=2Eyaml`=2E
+
+A test type owns a config file describing its tests, each test names a ma=
chine
+from the shared catalog (`config=2Eyaml`) and layers its own parameters o=
n top=2E
+
+Layout
+------
+
+```
+qemu_smoke_riscv64=2Epy        CLI entry point (<type> run | list)
+
+qtb/riscv/                   This framework
+  __init__=2Epy                Public API
+  qtb_test=2Epy                RiscvQtbTest ABC every test type derives f=
rom
+  config=2Epy                  Machine catalog parser -> MachineConfig
+  xen_dt=2Epy                  Generates the host device tree from its Ji=
nja2 template
+  dt=2Epy                      Compile =2Edts -> =2Edtb with dtc
+  paths=2Epy                   Path resolution (pkg-relative)
+  machine=2Epy                 RiscvTestMachine: assembles the QEMU comma=
nd line
+
+  config=2Eyaml                The machine catalog (shared across test ty=
pes)
+  dts/                       Jinja2 device-tree templates (host, common)
+
+  console_test/              The console-test type
+    __init__=2Epy
+    console_test=2Epy          ConsoleTest implementation
+    console-test=2Eyaml        Its tests
+
+  unit/                      pytest unit tests of the framework logic its=
elf
+```
+
+How a type is selected
+----------------------
+
+The test type is the first positional argument (`qemu_smoke_riscv64=2Epy =
console-test run
+=2E=2E=2E`)=2E The CLI builds one subcommand per entry of `TEST_TYPES` (`=
__init__=2Epy`),
+named after the type's `type_id`=2E
+
+Each type declares the `config_file` it reads its tests from=2E
+
+Prerequisites
+-------------
+
+- `qemu=2Eqtb`, QEMU's Python package (`python/` in the QEMU tree)
+- `jinja2`, `pyyaml`, `pexpect`
+- `dtc` (device-tree-compiler)
+- the binaries a machine boots: `qemu-system-riscv64`, the firmware
+  (OpenSBI) and `xen`
+
+CLI usage
+---------
+
+Run from `automation/scripts/`, or give the full path from the Xen tree r=
oot
+(`=2E/automation/scripts/qemu_smoke_riscv64=2Epy =2E=2E=2E`), which is wh=
at CI does=2E
+
+```
+# List every test the type defines in its config:
+=2E/qemu_smoke_riscv64=2Epy console-test list
+
+# Run one test (drives it to PASS/FAIL, exit 0/1):
+=2E/qemu_smoke_riscv64=2Epy console-test run dom0less-1smp-0domu-1vcpu-ap=
lic-imsic-null \
+    --log-dir qtb-logs
+```
+
+`--log-dir` (run only) collects the QEMU process log, the qtest log, and =
each
+console as `con<N>=2Elog`: `con0=2Elog` is Xen's own console, the only on=
e wired
+up today=2E Omit it to write no logs=2E `-v/--verbose` raises the
+log level to debug=2E
+
+Config files
+------------
+
+`config=2Eyaml` is the machine catalog=2E `binaries:` are build artifacts=
 resolved
+under `binaries/` (overridable with `$QTB_BINARIES_DIR`); absolute paths =
pass
+through=2E
+
+Machine entries omit any optional field left at its default=2E
+Here are the parameters:
+
+- `pcpu` (required): host physical cpus=2E
+- `mmu_type` (default `sv48`): Xen host MMU type=2E
+- `xen_bootargs` (default `""`): Xen command line=2E
+
+`<type>=2Eyaml` describes the tests of that type=2E
+
+`console-test`
+--------------
+
+A test names a machine and maps a console index to the string(s) expected=
 on
+that console: index 0 is Xen's own console (`con0`, logged as `con0=2Elog=
`)=2E
+
+```
+machine_catalog: config=2Eyaml    # the catalog to resolve machine names =
against
+tests:
+  dom0less-1smp-0domu-1vcpu-aplic-imsic-null:
+    machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null   # a name in con=
fig=2Eyaml
+    expect:
+      0: [All set up]           # Xen itself must print "All set up"
+```
+
+Logic, per console:
+
+1=2E read the console
+2=2E wait for each expected string in turn, in the order listed
+3=2E bound each wait by `timeout` seconds, retrying a timed-out wait up t=
o
+   `attempts` times
+
+The map itself must not be empty, otherwise the test would pass without
+asserting anything=2E
+
+Device trees (dts/)
+-------------------
+
+Jinja2 template, generated per machine and compiled with dtc:
+
+- `qemu-host=2Edts=2Ej2` - the Xen host tree: the hart count, the host MM=
U type and
+  the Xen command line=2E
+
+Adding a test
+-------------
+
+To add a test to an existing type (e=2Eg=2E `console-test`):
+
+1=2E Pick a machine from `config=2Eyaml`, or add a new one under `machine=
s:` (set
+   `pcpu`, and any optional field that differs from its default =E2=80=94=
 see the
+   field list above)=2E
+2=2E Add a test entry under `tests:` in the type's `<type>=2Eyaml`, namin=
g that
+   machine and supplying the type's own parameters (for `console-test`, o=
ne
+   `expect` list per console)=2E
+3=2E Run it: `=2E/qemu_smoke_riscv64=2Epy console-test run <your-test-nam=
e>`=2E
+
+No code change is needed, a test is pure config=2E
+
+Adding a new test type
+----------------------
+
+1=2E Create `mytype/` with `mytype=2Epy` defining a `RiscvQtbTest` subcla=
ss: set
+   `type_id`, `description`, and `config_file`, and implement `from_confi=
g`,
+   `list_tests`, and `run(vm)`=2E
+2=2E Add `mytype/__init__=2Epy` that does `from =2Emytype import MyType`=
=2E
+3=2E Add `MyType` to `TEST_TYPES` in `__init__=2Epy` so the CLI exposes i=
t=2E
+
+Unit tests
+----------
+
+The `unit/` directory holds pytest tests of the framework's own logic (co=
nfig
+parsing, device-tree rendering, QEMU arg assembly)=2E They do not boot QE=
MU and
+are independent of the CI smoke tests, but they import the framework, so =
they
+need the prerequisites above plus `pytest`=2E
+
+Run from the Xen tree root:
+
+```
+python3 -m pytest automation/scripts/qtb/riscv/unit/
+```


-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.204c.8057a2cfa8722de8.19fec705adb.8862fb7305d5dccf=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:10:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:10:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387639.1628928 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSa1-0004Mr-JI; Mon, 10 Aug 2026 16:10:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387639.1628928; Mon, 10 Aug 2026 16:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSa1-0004LP-DU; Mon, 10 Aug 2026 16:10:25 +0000
Received: by outflank-mailman (input) for mailman id 1387639;
 Mon, 10 Aug 2026 16:10:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705e62000e099@swg.vates.tech>)
 id 1wtSZz-00046c-Dv
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:10:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSZy-00Exz0-Qy
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:10:22 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705e62000e099@swg.vates.tech>)
 id 6a79f79b-e002-0a2a0a5209dd-0a2a45018e00-46
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:22 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec705e62000e099@swg.vates.tech>)
 id 6a79f7e7-5984-0a2a45010019-b9ff1c23956d-6
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:10:22 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec705e62000e099.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:10:15 +0000
Received: from leducb (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 718B5836CA;
 Mon, 10 Aug 2026 18:10:14 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=b8uUu5RVBX4cAl4lJFvLAs2NLoZ3l9PfrUwp54rMNoY=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=EN0WKQPt5ZeZQht5quSPoVwqugNHnkC+k/xdLPn7T/H09/ivM2dM8Q6FSiRUOWNrIKfh+5bNY
 yL+h7c+Z7K0xtzZkkmGklgNLxZ7Mby7p8xD9ry6hwCaqcnmSh8Zl601tKO9YZFtW/OWPvVBD0Nw
 dgmIII4IfGXahumpMkVjpyZq/67lgLblpY8+rrRM37Qoqp1Cw+1QBLmFmF0uZItDijzMt8WW5Nt
 2xccH4LLYbzugr/IQeCc9ZujydqFmqhCokxSnK4UVQyYpKqDaKYY9av0A7arVrR5IH5YD0hT1qy
 EAFKjw7jb5Bq70EwVEUn9+S3wxG4rOxU4DFACcwulJ/Q==
X-Zone-Loop: 5e910abe6b09df3b0635cd623e41b48cfcda30c2ec62
x-campaign-type: default
x-transaction-id: bd1c45bf-91a7-4f09-a9d4-206f924aa378
x-swg-uid: 01-a5039f13-fdab-4e2c-b90b-809608327dcb
X-Mailer: Sweego
Message-ID:
 <1786378215.8631fc262581453bbf619ec5b2062170.19fec705e62000e099@vates.tech>
x-swg-bid: 1786378215.8631fc262581453bbf619ec5b2062170.19fec705e62000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 6/6] CI: run the riscv64 smoke test via QTB framework console-test
Date: Mon, 10 Aug 2026 18:09:56 +0200
In-Reply-To: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.204d.96642db73297cb4b.19fec705c90.6ffbbdec5d88f335=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378214544
X-purgate-ID: tlsNG-d62444/1786378222-BD67C757-D7FE074B/0/0
X-purgate-type: clean
X-purgate-size: 5029

---=Part.204d.96642db73297cb4b.19fec705c90.6ffbbdec5d88f335=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

qemu-smoke-riscv64-gcc drove QEMU through
automation/scripts/qemu-smoke-riscv64=2Esh, an expect wrapper whose machin=
e
description (cpus, memory, device tree, console wiring) lived in the scrip=
t
itself=2E The QTB framework now owns all of that: machines come from the
shared catalog, expectations from the test type's own YAML=2E

Turn =2Eqemu-riscv64 into a template running qemu_smoke_riscv64=2Epy <type=
> run
<test> in the qtb-riscv64 container, machine and test picked per job
through QTB_TEST_TYPE/QTB_TEST=2E The container comes from the test-artifa=
cts
registry, hence the new ARTIFACTS_REGISTRY next to the existing
ARTIFACTS_REPO/ARTIFACTS_BRANCH=2E QTB_BINARIES_DIR points at the artifact=
s
of the job in the new =2Eriscv64-test-needs anchor (QEMU and its firmware)=
,
and QTB_LOG_DIR collects the per-console logs, kept on failure and on
success=2E

Point qemu-smoke-riscv64-gcc at that template, running the console-test
type on dom0less-1smp-0domu-1vcpu-aplic-imsic-null: a Xen-only machine, so
the smoke check is Xen's own "All set up" on console 0, the same string th=
e
expect script waited for=2E

Drop automation/scripts/qemu-smoke-riscv64=2Esh as it has no caller left i=
n
the CI after this patch and drop smoke=2Eserial from the =2Eqemu-riscv64
artifacts since no riscv64 job uses it anymore, the logs are now kept unde=
r
QTB_LOG_DIR=2E

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
---
 =2Egitlab-ci=2Eyml                           |  3 +++
 automation/gitlab-ci/test=2Eyaml           | 26 ++++++++++++++++++------
 automation/scripts/qemu-smoke-riscv64=2Esh | 19 -----------------
 3 files changed, 23 insertions(+), 25 deletions(-)
 delete mode 100755 automation/scripts/qemu-smoke-riscv64=2Esh

diff --git a/=2Egitlab-ci=2Eyml b/=2Egitlab-ci=2Eyml
index f42a9abeaa=2E=2E15f93b8634 100644
--- a/=2Egitlab-ci=2Eyml
+++ b/=2Egitlab-ci=2Eyml
@@ -11,6 +11,9 @@ variables:
   ARTIFACTS_BRANCH:
     description: "Branch in test-artifacts to use"
     value: master
+  ARTIFACTS_REGISTRY:
+    description: "Registry holding the test-artifacts containers"
+    value: registry=2Egitlab=2Ecom/xen-project/hardware/test-artifacts
   LINUX_JOB_X86_64:
     description: "Job name in test-artifacts to use for Linux x86_64"
     value: linux-6=2E6=2E56-x86_64
diff --git a/automation/gitlab-ci/test=2Eyaml b/automation/gitlab-ci/test=
=2Eyaml
index 61adc1baff=2E=2E4775d2cc4e 100644
--- a/automation/gitlab-ci/test=2Eyaml
+++ b/automation/gitlab-ci/test=2Eyaml
@@ -5,6 +5,11 @@
   - if: $CI_JOB_NAME =3D~ $SELECTED_JOBS_ONLY
     when: on_success
=20
+=2Eriscv64-test-needs: &riscv64-test-needs
+  - project: $ARTIFACTS_REPO
+    job: qemu-9=2E0=2E0-riscv64
+    ref: $ARTIFACTS_BRANCH
+
 =2Earm64-test-needs: &arm64-test-needs
   - project: $ARTIFACTS_REPO
     job: $LINUX_JOB_ARM64
@@ -72,14 +77,21 @@
     TEST_TIMEOUT_OVERRIDE: 120
=20
 =2Eqemu-riscv64:
+  image: ${ARTIFACTS_REGISTRY}/${CONTAINER}
   extends: =2Etest-jobs-common
   variables:
-    CONTAINER: debian:13-riscv64
-    LOGFILE: qemu-smoke-riscv64=2Elog
+    CONTAINER: debian:13-qtb-riscv64
+    QTB_LOG_DIR: qtb-logs
+    QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries
+  script:
+    - =2E/automation/scripts/qemu_smoke_riscv64=2Epy
+      ${QTB_TEST_TYPE}
+      run
+      ${QTB_TEST}
+      --log-dir ${QTB_LOG_DIR}
   artifacts:
     paths:
-      - smoke=2Eserial
-      - '*=2Elog'
+      - ${QTB_LOG_DIR}
     when: always
   tags:
     - x86_64
@@ -779,9 +791,11 @@ qemu-xtf-argo-x86_64-gcc-debug:
=20
 qemu-smoke-riscv64-gcc:
   extends: =2Eqemu-riscv64
-  script:
-    - =2E/automation/scripts/qemu-smoke-riscv64=2Esh 2>&1 | tee ${LOGFILE=
}
+  variables:
+    QTB_TEST_TYPE: console-test
+    QTB_TEST: dom0less-1smp-0domu-1vcpu-aplic-imsic-null
   needs:
+    - *riscv64-test-needs
     - debian-13-riscv64-gcc-debug
=20
 qemu-smoke-ppc64le-powernv9-gcc:
diff --git a/automation/scripts/qemu-smoke-riscv64=2Esh b/automation/scrip=
ts/qemu-smoke-riscv64=2Esh
deleted file mode 100755
index c0b1082a08=2E=2E0000000000
--- a/automation/scripts/qemu-smoke-riscv64=2Esh
+++ /dev/null
@@ -1,19 +0,0 @@
-#!/bin/bash
-
-set -ex -o pipefail
-
-# Run the test
-rm -f smoke=2Eserial
-
-export TEST_CMD=3D"qemu-system-riscv64 \
-    -M virt,aia=3Daplic-imsic \
-    -cpu rv64,svpbmt=3Don \
-    -smp 1 \
-    -nographic \
-    -m 2g \
-    -kernel binaries/xen"
-
-export TEST_LOG=3D"smoke=2Eserial"
-export PASSED=3D"All set up"
-
-=2E/automation/scripts/console=2Eexp |& sed 's/\r\+$//'


-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.204d.96642db73297cb4b.19fec705c90.6ffbbdec5d88f335=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:20:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:20:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387682.1628941 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSjX-0007s6-LG; Mon, 10 Aug 2026 16:20:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387682.1628941; Mon, 10 Aug 2026 16:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtSjX-0007rz-IP; Mon, 10 Aug 2026 16:20:15 +0000
Received: by outflank-mailman (input) for mailman id 1387682;
 Mon, 10 Aug 2026 16:20:14 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtSjV-0007rt-Vu
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:20:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtSjU-009EC3-Np
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:20:12 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec796ecb000e099@swg.vates.tech>)
 id 6a79fa27-bab6-0a2a0a5309dd-0a2a4509e39c-32
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:20:12 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fec796ecb000e099@swg.vates.tech>)
 id 6a79fa3c-be1a-0a2a45090019-b9ff1c2389c7-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:20:12 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fec796ecb000e099.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 10 Aug 2026 16:20:09 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 4BA8681C91;
 Mon, 10 Aug 2026 18:20:08 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=gbPx00y3KZQyqLCbi95Q/5Iy/Nq3Js6/1jBe0l/XbHA=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=iZwvScOPNDwRHidRp1D1sBZ6sAaWavesjr+nrAcchvwJoRfxfC7d42mfuAk4aVq7jQgEeQs93
 S237qv22SzkAxewfAiB5gx7j9EIoQJwYmVWYFRptRSKpJ7mhm/lN1ArrE+sgMMd3i3Ju0q3tdJn
 r+zmgPpPisrmMnJ9oXdiOnBVnTaTh8dr33EKUoMIBAumuzQqzRkkuvR41h7SC9XUMxM7NZAcYhn
 vDdzk+lO8SqNJa5egSRQwrI79efwyHAd9xmWsMVao3gxpEZH0nwiF9k2E1ZW+/XbsfIXitOpdZb
 WMge6hw5gDDEzVyVUqS/VK/tttg/uv7USUr8cP66MQjQ==
X-Zone-Loop: 821d28af57f8c5ba89765fecf76785c21a5a07a45059
x-campaign-type: default
x-transaction-id: f2e13ac5-9ad7-45dd-96ea-845289fefced
x-swg-uid: 01-717e97ef-b827-4be6-9117-ec1f3973f62b
X-Mailer: Sweego
Message-ID:
 <1786378809.8631fc262581453bbf619ec5b2062170.19fec796ecb000e099@vates.tech>
x-swg-bid: 1786378809.8631fc262581453bbf619ec5b2062170.19fec796ecb000e099
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Subject: Re: [PATCH 1/6 TEST-ARTIFACTS] Add a QTB container to run the Xen
 riscv64 tests
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <1786378213.8631fc262581453bbf619ec5b2062170.19fec705643000e099@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
 <1786378213.8631fc262581453bbf619ec5b2062170.19fec705643000e099@vates.tech>
Date: Mon, 10 Aug 2026 18:20:02 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786378808; l=3567;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=wul/TDdovu7bl+ESViJYK6YcweHy78HHk6jvpWvPtOM=;
 b=fF48VRfAUCey5J/4cr/xdAMb6PnjkgzuejEjKbtCbEI6j7279KYJiFw3L0VAjUxQSDaLaAYSP
 hkgcjspy5j5DLWtbwU8HHYA5h6/+tBBGgvG9eUSiWEqe5ft7ptAgfvo
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.204e.d8cf671d69c5fb59.19fec796c82.bff95559d196618f=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786378808450
X-purgate-ID: tlsNG-bad1c0/1786378812-FD668034-52B069E3/10/63158204843
X-purgate-type: spam
X-purgate-size: 4084

---=Part.204e.d8cf671d69c5fb59.19fec796c82.bff95559d196618f=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Apologies for the broken threading, my SMTP relay rewrote the
Message-IDs=2E Cover letter is here:
https://lore=2Ekernel=2Eorg/xen-devel/1786377707=2E8631fc262581453bbf619ec=
5b2062170=2E19fec689f7e000e099@vates=2Etech/T/#u

Kind regards,

On 2026-08-10 18:09 +0200, Baptiste Le Duc wrote:
> QTB (QEMU Test Bench) is a Python framework, developed as part of AMD's =
Xen
> safety initiative, that drives a live QEMU instance over qtest and QMP=
=2E It
> gives a test full access to the machine while the emulation runs: read a=
nd
> write the consoles, inspect the registers and the memory, inject interru=
pts=2E
>=20
> For now the riscv64 CI tests only use it to read the Xen console in the
> smoke test, since DomU is not supported yet=2E Once it is, the same
> framework will read and write the DomU consoles and inject IRQs, so the
> tests can assert an interrupt reaches the expected guest and vCPU=2E
>=20
> QTB is not upstream in QEMU yet, though it is planned to be, so get the
> framework from AMD's fork gitlab=2Ecom/xen-project/people/amd/qemu and
> pip-installs qemu=2Eqtb from it=2E
>=20
> Signed-off-by: Baptiste Le Duc <baptiste=2Ele-duc@vates=2Etech>
> ---
>  containerize                            |  1 +
>  images/debian/13-qtb-riscv64=2Edockerfile | 45 ++++++++++++++++++++++++=
+
>  2 files changed, 46 insertions(+)
>  create mode 100644 images/debian/13-qtb-riscv64=2Edockerfile
>=20
> diff --git a/containerize b/containerize
> index dad9afa=2E=2E477b670 100755
> --- a/containerize
> +++ b/containerize
> @@ -31,6 +31,7 @@ case "_${CONTAINER}" in
>      _alpine-3=2E24-arm64-base) CONTAINER=3D"${BASE}/alpine:3=2E24-arm64=
-base" ;;
>      _alpine-3=2E24-arm64-build) CONTAINER=3D"${BASE}/alpine:3=2E24-arm6=
4-build" ;;
>      _alpine-3=2E24-x86_64-base) CONTAINER=3D"${BASE}/alpine:3=2E24-x86_=
64-base" ;;
> +    _debian-13-qtb-riscv64) CONTAINER=3D"${BASE}/debian:13-qtb-riscv64"=
 ;;
>      _alpine-3=2E24-x86_64-build|_) CONTAINER=3D"${BASE}/alpine:3=2E24-x=
86_64-build" ;;
>  esac
> =20
> diff --git a/images/debian/13-qtb-riscv64=2Edockerfile b/images/debian/1=
3-qtb-riscv64=2Edockerfile
> new file mode 100644
> index 0000000=2E=2E86215d3
> --- /dev/null
> +++ b/images/debian/13-qtb-riscv64=2Edockerfile
> @@ -0,0 +1,45 @@
> +# syntax=3Ddocker/dockerfile:1
> +FROM --platform=3Dlinux/amd64 debian:trixie-slim
> +LABEL maintainer=2Ename=3D"The Xen Project"
> +LABEL maintainer=2Eemail=3D"xen-devel@lists=2Exenproject=2Eorg"
> +
> +ENV DEBIAN_FRONTEND=3Dnoninteractive
> +
> +ARG QEMU_REPO=3Dhttps://gitlab=2Ecom/xen-project/people/amd/qemu=2Egit
> +ARG QEMU_COMMIT=3D24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab
> +
> +RUN <<EOF
> +#!/bin/bash
> +    set -eu
> +
> +    useradd --create-home user
> +
> +    apt-get update
> +
> +    DEPS=3D(# Base environment
> +        ca-certificates
> +        device-tree-compiler
> +        git
> +        python3-jinja2
> +        python3-minimal
> +        python3-pip
> +        python3-yaml
> +
> +        # Qemu for test phase
> +        qemu-system-riscv64
> +    )
> +
> +    apt-get -y --no-install-recommends install "${DEPS[@]}"
> +
> +    # QTB framework
> +    git init /tmp/qemu
> +    git -C /tmp/qemu fetch --depth 1 "$QEMU_REPO" "$QEMU_COMMIT"
> +    git -C /tmp/qemu checkout FETCH_HEAD
> +    pip install --break-system-packages /tmp/qemu/python[qtb]
> +
> +    rm -rf /tmp/qemu
> +    rm -rf /var/lib/apt/lists/*
> +EOF
> +
> +USER user
> +WORKDIR /build
>=20
>=20
> --=20
> Baptiste Le Duc | Vates Hypervisor & Kernel Engineer
>=20
> XCP-ng & Xen Orchestra - Vates solutions
>=20
> web: https://vates=2Etech



-- 
Baptiste Le Duc | Vates Hypervisor & Kernel Engineer

XCP-ng & Xen Orc=
hestra - Vates solutions

web: https://vates=2Etech
---=Part.204e.d8cf671d69c5fb59.19fec796c82.bff95559d196618f=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 16:42:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 16:42:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387696.1628951 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtT57-0002x9-B1; Mon, 10 Aug 2026 16:42:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387696.1628951; Mon, 10 Aug 2026 16:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtT57-0002x2-86; Mon, 10 Aug 2026 16:42:33 +0000
Received: by outflank-mailman (input) for mailman id 1387696;
 Mon, 10 Aug 2026 16:42:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3c_95agYKCbQmYUhdWaiiafY.WigrYh-XYpYffcmnm.rYhjlidYWn.ila@flex--seanjc.bounces.google.com>)
 id 1wtT55-0002ww-Mp
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 16:42:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtT53-00434s-Pt
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:42:29 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3c_95agYKCbQmYUhdWaiiafY.WigrYh-XYpYffcmnm.rYhjlidYWn.ila@flex--seanjc.bounces.google.com>)
 id 6a79ff6c-2eae-0a2a0a5409dd-0a2a4506e2d8-12
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:42:29 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3c_95agYKCbQmYUhdWaiiafY.WigrYh-XYpYffcmnm.rYhjlidYWn.ila@flex--seanjc.bounces.google.com>)
 id 6a79ff74-195a-0a2a45060019-d155d2c5ec63-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 18:42:29 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-848544a8496so2343430b3a.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 09:42:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786380148; x=1786984948; darn=lists.xenproject.org;
        h=content-type:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1aMkrKlnySSkZTh98FOauiGYQlFOQqftaK5JuEjFP4g=;
        b=atN7bTXZeZzv7IrVzyQngYnKgJjlmMoz52g9gAW169OJK86ZDfItMpwKhrTBKVKIQy
         bwhcRRVKdLxPiYFHvuHHummmrJoNTCVyp4BsS2OZTOB1xjBylnsxOBF+kYPdct4kTiK0
         pndTJ1Pnh6qcof3c8FwwFT6wzf2bUas/2KIptcHLhsqKi7luKhMCZi8y7EvkkiDEAnCa
         bqAdEks9R9dOWyFfoIFkuRnevy7FHYDp8SrWDX0Yg9PmHbldsZZcRGFbNZIg/5aMr8iq
         WwlNmKfs6uaSvfqHsiqHkmKfm4UwKa4KmfjRaGOB2eTbLUBmKI4r5gflp3szNIWklF1q
         K3+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786380148; x=1786984948;
        h=content-type:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=1aMkrKlnySSkZTh98FOauiGYQlFOQqftaK5JuEjFP4g=;
        b=hVgMfAJcA6qA5XHLvJEYhFYrLH9Cy5RgPK+wSJx3BUSpxM4QlQGOSsZY4vB8Pso4Th
         p9fue90myBTIgEv1M3Tx7atUHp5NOUpkZCPouzsOmHwWkrMghOYCmS6XQxoRzEw9B+sn
         kBkwQL7GcVu2GXr9U+bROAKXUmaIrSLd0HTQZFocMDDEPLvQcFJp7iqecVAhS7/sHy3j
         pHqD+fyuyqWenPwvHNyz+PjhpWPBAX71+k0bMK3ohh83O9p9F8L7UsfHGBUrqFoqMO+/
         jljQfnidsMG7M3xM48ctYn1xuuPc6tDz5gHYY5aRiIecmFwW4ZJwv7jbngi9m55AiwSy
         DMEg==
X-Forwarded-Encrypted: i=1; AHgh+RomswLUx+Ltg65YDGmmilA8UBsDS2J9Z9gByC6N90O6QaJmrYN9DmWTG6j5oiphr3OOPyBc4G9cObw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxw5UyxdrtA/zle/J0sWMihzIJ9wg2ggrA0x0E6+g6wlgo7/OUZ
	0vpMKoSQbafTEY+J/jvDx78zUJvQUKpmQdjxFpqxVQmNg7aotmnAlCO80DTPGsSnFtTRN6ZdGQd
	ICtVfkQ==
X-Received: from pfbkr10.prod.google.com ([2002:a05:6a00:4b4a:b0:848:569f:3464])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3cc5:b0:847:8dec:1427
 with SMTP id d2e1a72fcca58-84f4fd9f647mr32987651b3a.8.1786380147208; Mon, 10
 Aug 2026 09:42:27 -0700 (PDT)
Date: Mon, 10 Aug 2026 09:42:21 -0700
In-Reply-To: <20260728144954.355376-1-dwmw2@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org>
X-Mailer: git-send-email 2.55.0.679.g6767b8d81c-goog
Message-ID: <178637989949.703398.16006467247639187150.b4-ty@google.com>
Subject: Re: [PATCH v7 00/36] Cleaning up the KVM clock mess
From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <skhan@linuxfoundation.org>, 
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org, 
	David Woodhouse <dwmw2@infradead.org>
Content-Type: text/plain; charset="utf-8"
X-purgate-ID: tlsNG-16d1c6/1786380149-FD60A77B-0AA3C434/0/0
X-purgate-type: clean
X-purgate-size: 1327

On Tue, 28 Jul 2026 15:39:40 +0100, David Woodhouse wrote:
> This is v7 of the series to clean up the KVM clock, rebased onto
> kvm-x86/next (patch 1 of v6 is already merged there as commit
> 710b3a30f407).
> 
> The KVM clock has historically suffered from three problems:
> 
>  1. Imprecision: get_kvmclock_ns() computed the clock from the *host*
>     TSC without applying guest TSC scaling, causing systemic drift from
>     the values the guest computes from its own TSC.
> 
> [...]

Applied two more Xen patches to kvm-x86 clocks.

Given that KVM was updating the wrong sub-leaf (which amused me greatly), I
didn't see any point in waiting for the new uAPI updates to yank out the CPUID
updates.  Holler if you feel strongly that that change in particular should be
bundled with the kernel that adds the TSC scaling uAPI, omitting these changes
from 7.3 and waiting for 7.4 is trivial.  I'm just trying to reduce the number
of in-flight patches we need to keep track of.

Thanks!

[20/36] KVM: x86/xen: Prevent runstate times from becoming negative
        https://github.com/kvm-x86/linux/commit/36a85200643e

...

[22/36] KVM: x86: Remove runtime Xen TSC frequency CPUID update
        https://github.com/kvm-x86/linux/commit/7d3bd21e457b

--
https://github.com/kvm-x86/linux/tree/next


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 17:01:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 17:01:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387708.1628961 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtTNI-00067K-R2; Mon, 10 Aug 2026 17:01:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387708.1628961; Mon, 10 Aug 2026 17:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtTNI-00067D-Mq; Mon, 10 Aug 2026 17:01:20 +0000
Received: by outflank-mailman (input) for mailman id 1387708;
 Mon, 10 Aug 2026 17:01:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtTNE-000677-D8
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:01:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtTND-001GeV-6W; Mon, 10 Aug 2026 19:01:15 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7a03bb-8faa-0a2a0a5109dd-0a2a450ca636-46
 for <multiple-recipients>; Mon, 10 Aug 2026 19:01:13 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7a03d8-f479-0a2a450c0019-5a9b3222ba68-3
 for <multiple-recipients>; Mon, 10 Aug 2026 19:01:12 +0200
Received: from 54-240-197-233.amazon.com ([54.240.197.233]
 helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtTIe-0000000FsrG-3EQh; Mon, 10 Aug 2026 16:56:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=F7K1udkVZU92GKtfiKiXkKfBInmHr+hymLHX/Ey5Ckw=; b=PE46M4nRVtFgPxlNu0c9dSQEMW
	VvDkhDdmKfzplsEXmqnxF6LZId3EsY1ahIcEPrkowD/ABrNFFCqDT0rLlLDjWy/+YWLi2CZev4zF8
	RpmlJSP0bhrOnmLZRmoxzEaW3Macd5S1LtVtO0iegHDApVsLOSvGNTcxE/NjzQHafA1zdaqLw4YzH
	JDLhZPmZ0mGX++kZUkDn4tLSQ7kRdWBjSGmm5zFb9uNWJEUoybiDyC0fpHHKxqrh0IZOjCxBQZymV
	9yrKrCpJx1XvAK6YVwRc3x22nfNvRZc652VHJkHK9NbVBabjd8JGROt7qZAQFQvCyyW3yc2uptICr
	LHpalZdQ==;
Message-ID: <8e7b756145d047e7a7da7804263eaf4a83f67e1b.camel@infradead.org>
Subject: Re: [PATCH v7 00/36] Cleaning up the KVM clock mess
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>,  Jonathan Corbet	 <corbet@lwn.net>, Shuah Khan
 <skhan@linuxfoundation.org>, Thomas Gleixner	 <tglx@kernel.org>, Ingo
 Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,  Dave Hansen
 <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross
 <jgross@suse.com>, Boris Ostrovsky	 <boris.ostrovsky@oracle.com>, Paul
 Durrant <paul@xen.org>, Jonathan Cameron	 <jic23@kernel.org>, Sascha
 Bischoff <Sascha.Bischoff@arm.com>, Marc Zyngier	 <maz@kernel.org>, Joey
 Gouly <joey.gouly@arm.com>, Jack Allister	 <jalliste@amazon.com>, Dongli
 Zhang <dongli.zhang@oracle.com>, 	joe.jin@oracle.com, kvm@vger.kernel.org,
 linux-doc@vger.kernel.org, 	linux-kernel@vger.kernel.org,
 xen-devel@lists.xenproject.org, 	linux-kselftest@vger.kernel.org
Date: Mon, 10 Aug 2026 17:56:23 +0100
In-Reply-To: <178637989949.703398.16006467247639187150.b4-ty@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <178637989949.703398.16006467247639187150.b4-ty@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-Ym+XPLy3h0xTCiX5d9Zd"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-d25034/1786381273-76CDBA5B-91548E1C/0/0
X-purgate-type: clean
X-purgate-size: 9630


--=-Ym+XPLy3h0xTCiX5d9Zd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2026-08-10 at 09:42 -0700, Sean Christopherson wrote:
>=20
> Applied two more Xen patches to kvm-x86 clocks.
>=20
> Given that KVM was updating the wrong sub-leaf (which amused me greatly),=
 I
> didn't see any point in waiting for the new uAPI updates to yank out the =
CPUID
> updates.=C2=A0 Holler if you feel strongly that that change in particular=
 should be
> bundled with the kernel that adds the TSC scaling uAPI, omitting these ch=
anges
> from 7.3 and waiting for 7.4 is trivial.=C2=A0 I'm just trying to reduce =
the number
> of in-flight patches we need to keep track of.

Sounds good. Let me know when the dust has settled, and I can look at
rebasing the remaining parts on top of part 1. In the meantime I shall
continue to polish the GPC/RCU stuff, which looks like it's working
quite nicely now.

--=-Ym+XPLy3h0xTCiX5d9Zd
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTAxNjU2MjNaMC8GCSqGSIb3DQEJBDEiBCAybwx1QWRoKMDiRyZ64eaKw51fEKZI
/kvexMNutyvnZTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAx/53F7uaU7YMdDo0sjw5EeKzwlz0DNt6fbdQkKbfXgNXjdKJHTOU
4kSEhoBJpzr87r9nyStsTxM/F0mvtQjqGjFUggbsZ9YEwtdDpEriE18ixibCW1MXxh9lS9AHrPdA
i+3BhK0+WfK8P8VyXP8jq0MqpTx+1x2ZZ2zoTZjktUrUqYaVlHhImboCKZex8qFXBUg8aa5qgnbc
wFpnz4stsBTRQ+WgkHigmlKGlWe76MpmgEfvBuvzM2lm497AAq88I0Nk0F1NgviJeE4leuCDQLhB
W3SRCLxePsHKwgp2SR1nkpPCHR1HHccoI7R8DwlL7d+Ptqty+dyACtxdwLXpoIueV5oWdzLa9jOC
KHODCLSCujLgYCh94bfvIOmBCo+51Haah/3TZKi1WZrkeLzt7UFHAMYl1cqernHNkDuqKeUIxSLl
Oxu4mFqIJUMQ+0UyOL+/nTfr4fCPlYE0+KA7AdBXkNVF0H+EN0QOPV8ZY8PxYMgqqudR4Z2J6mba
TbbM8YhLFq8nE4Tm69jhSN8y7WNXdLH18GZSmcXS4rm75Vvk34gMlGuB2Fa3jNcE2e3yqJhzBgbC
etj3LeM9Ji7kEoNrnhJsFVL03Cl7E6M+WNGsniZa+j28riIMcgidlPJuz5ONf3LOB9xaTMmEyzTR
vhB20ETalyiujq48e8jsfJUAAAAAAAA=


--=-Ym+XPLy3h0xTCiX5d9Zd--


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 17:48:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 17:48:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387727.1628970 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtU6X-0004IL-80; Mon, 10 Aug 2026 17:48:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387727.1628970; Mon, 10 Aug 2026 17:48:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtU6X-0004IE-3r; Mon, 10 Aug 2026 17:48:05 +0000
Received: by outflank-mailman (input) for mailman id 1387727;
 Mon, 10 Aug 2026 17:48:04 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <30A56agYKCTEfRNaWPTbbTYR.PbZkRa-QRiRYYVfgf.kRacebWRPg.beT@flex--seanjc.bounces.google.com>)
 id 1wtU6V-0004H0-Uq
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:48:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtU6V-00Bt7l-2E
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 19:48:03 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <30A56agYKCTEfRNaWPTbbTYR.PbZkRa-QRiRYYVfgf.kRacebWRPg.beT@flex--seanjc.bounces.google.com>)
 id 6a7a0eb2-e002-0a2a0a5209dd-0a2a4504d570-42
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 19:48:02 +0200
Received: from [209.85.214.199] (helo=mail-pl1-f199.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <30A56agYKCTEfRNaWPTbbTYR.PbZkRa-QRiRYYVfgf.kRacebWRPg.beT@flex--seanjc.bounces.google.com>)
 id 6a7a0ed1-b57f-0a2a45040019-d155d6c7ec70-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 19:48:02 +0200
Received: by mail-pl1-f199.google.com with SMTP id
 d9443c01a7336-2cacf17c7e0so31032415ad.0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 10:48:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786384081; x=1786988881; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=SniDEAr8Q0oZEkC+DBXZ7AH2ONN7iandHQRV9KjayUM=;
        b=D46kqTkDEKuBRi2F4mjHWOZBsvIc0JTutWxM5i5TjMq5VBJ/RYbmr4FA0A5EeNUYBA
         SvQpaEYUlWFtksoCDmNEfsIV+n7uM/DOrMLxkNOabvesDvEycbcRuCTArvhz+iO2Tu4i
         Y4m4buNbSZTpCOW0g1sKruMMaOxXkNOATjpf69Ykdv8ELwQ96hhln9jSo27DU57YZ1os
         7avBWkPH/iz/s9QamMSmJjNw2NZUjQLX7NcMPGFvAcE6dFzJSLX30ZP+ARhcNI6w5i+N
         qgqonlFaEeRNl7Jr4skixvrhclln2q+u+nKvBPCBQC/jpEA9zAEyXAA7SpE6w7LZXprb
         iJUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786384081; x=1786988881;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=SniDEAr8Q0oZEkC+DBXZ7AH2ONN7iandHQRV9KjayUM=;
        b=p9TgHWasbejSZ6cRD3A+nNDESCHwukSGinpM0FCSahAT34N4N8CQLzv+3SZimR7AGK
         /jvkZSLozGumlW8cdMVLWs0m0wcq17OFtqLFu5obN3cC3zwU0Uj/eQKBzbXtf+eFVhzI
         OmAgHB0wmt1a5IBim1Y5cSmraIt9RtkDCqVXM4tDyBeEy5x49ZXfjrY5YCLJz8eWXOv7
         B1XIl3n4/5pgaTmpu8jI89fP4Rs5m7e0iIEjYfs9MBPHGN2NjzauluKMFpimPH9G7SY5
         ZjTyaOsKzEmE8ZuTNb0420TN3YlDkENi/xI4MRHMmrBi6Tl+kGWgtRPkcuZ+ExUS9Zhs
         pevQ==
X-Forwarded-Encrypted: i=1; AHgh+Ro8V+NYJDaTB0G6Pm9GOtiuCz8oGT5+Ul7uUyjv7X23YcEHZx3r+17Cl43Wdak2762ektlSNXH1064=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxMLbDsiMF6ntgmUgbDPUOBsayZFmdIPRN8LokcDfe0xzy7dMsB
	2xORxWe08tKurIi/mug6ZEU/UDjP3tTH+OmPbg7eCM/W+WbA6tqny3pvfO26W/YsHTlPT+KpNKW
	WC48R8Q==
X-Received: from plof2.prod.google.com ([2002:a17:902:8602:b0:2ca:f171:2082])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ea0d:b0:2c6:a012:6241
 with SMTP id d9443c01a7336-2d106a7e616mr344060945ad.6.1786384080573; Mon, 10
 Aug 2026 10:48:00 -0700 (PDT)
Date: Mon, 10 Aug 2026 10:47:59 -0700
In-Reply-To: <20260728144954.355376-18-dwmw2@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-18-dwmw2@infradead.org>
Message-ID: <anoOz2rZ02KFk1l-@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-ebf023/1786384082-C1CD7B50-0587739D/0/0
X-purgate-type: clean
X-purgate-size: 2413

On Tue, Jul 28, 2026, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Previously, a guest writing different TSC values on different vCPUs could
> force KVM out of master clock mode. With this change, only a frequency
> mismatch disables master clock. The only ways for non-master-clock mode
> to happen now are archaic hardware without a TSC-based clocksource, a
> VMM that sets different TSC frequencies across vCPUs, or a guest using
> the legacy MSR_KVM_SYSTEM_TIME (which could be addressed in future by
> simply updating tsc_timestamp more frequently rather than falling out of
> master clock mode entirely).
> 
> Running at a different frequency would lead to a systemic skew between
> the clock(s) as observed by different vCPUs due to arithmetic precision
> in the scaling. So that should indeed force the clock to be based on the
> host's CLOCK_MONOTONIC_RAW instead of being in masterclock mode where it
> is defined by the guest TSC.
> 
> But when the vCPUs merely have a different TSC *offset*, that's not a
> problem. The offset is applied to that vCPU's kvmclock->tsc_timestamp
> field, and it all comes out in the wash.

It's not though?  The value stored in kvmclock->tsc_timestamp is per-VM, not
per-vCPU, when using the master clock.  It's a little easier to see once the
master clock TSC isn't shoved into host_tsc:

	do {
		seq = read_seqcount_begin(&ka->pvclock_sc);
		use_master_clock = ka->use_master_clock;
		if (!use_master_clock)
			continue;

		if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) {
			use_master_clock = false;
			continue;
		}

		master_tsc = ka->master_cycle_now;
		master_ns = ka->master_kernel_ns;
	} while (read_seqcount_retry(&ka->pvclock_sc, seq));

	...

	if (use_master_clock) {
		hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, master_tsc);
		hv_clock.system_time = master_ns + v->kvm->arch.kvmclock_offset;
	} else {
		hv_clock.tsc_timestamp = tsc_timestamp;
		hv_clock.system_time = kernel_ns + v->kvm->arch.kvmclock_offset;
	}

To allow different offsets, KVM would need to track a per-vCPU offset to the
master clock and apply that in kvm_guest_time_update() (and maybe other places?).
Which is doable, but it's not clear to me why we'd want to support that (though
I haven't fully processed the back half ot his series, so it's very possible I'm
missing something obvious).


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 17:56:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 17:56:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387737.1628977 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUEf-0005yF-Um; Mon, 10 Aug 2026 17:56:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387737.1628977; Mon, 10 Aug 2026 17:56:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUEf-0005y8-SC; Mon, 10 Aug 2026 17:56:29 +0000
Received: by outflank-mailman (input) for mailman id 1387737;
 Mon, 10 Aug 2026 17:56:28 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wtUEd-0005y1-PW
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 17:56:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtUEd-008Ycq-6S
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 19:56:27 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7a10a9-2eae-0a2a0a5409dd-0a2a4506d452-32
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 19:56:27 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7a10c9-195a-0a2a45060019-94a392179362-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 19:56:26 +0200
Received: from pps.filterd (m0367123.ppops.net [127.0.0.1])
 by mx0a-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67AGEb9Z1908470
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:56:25 GMT
Received: from bl0pr03cu003.outbound.protection.outlook.com
 (mail-eastusazon11012061.outbound.protection.outlook.com [52.101.53.61])
 by mx0a-00498f03.pphosted.com (PPS) with ESMTPS id 4fyha31x2w-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 17:56:24 +0000 (GMT)
Received: from DS1PR04CA0008.namprd04.prod.outlook.com (2603:10b6:8:44f::15)
 by SJ2PR16MB6251.namprd16.prod.outlook.com (2603:10b6:a03:592::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 17:56:19 +0000
Received: from DS2PEPF000061C3.namprd02.prod.outlook.com
 (2603:10b6:8:44f:cafe::26) by DS1PR04CA0008.outlook.office365.com
 (2603:10b6:8:44f::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Mon,
 10 Aug 2026 17:56:19 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 DS2PEPF000061C3.mail.protection.outlook.com (10.167.23.70) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Mon, 10 Aug 2026 17:56:19 +0000
Received: from pps.filterd (m0426315.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67AGFTA3499565
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:56:18 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [3.215.31.156])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxpbshp02-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:56:18 -0400 (EDT)
Received: from localhost ([19.12.92.222]) by cmsmtp with ESMTPSA
 id tUESwf7SGQLYTtUETw1jGb; Mon, 10 Aug 2026 17:56:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=fail header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=Gz6
	pDUp5rLV7SS4lZjhFrNaNaJ+FdUpeMI3ZZ3G7QvE=; b=tX28oPUFqdjZqIBuy7s
	8hO2V0D0Fdxe1+5BmA0I82FucKEr1g3LOcjrrfb4UI1Jzvhq9EHDRksKxEToZZLo
	g1GVOBXLtkbVbJ3tQLU0jH/zStInnS3t4u1X94Hp0+eE/cSEXolhwbMKM+RakZYO
	qBtiwgQjF0OAnOJaJNuHMdLB8WHGHzLaX1zNwF1cx+x+2/qeJvZZ5ysk80mVuQMJ
	SJNqMA8ELD+rHlxEXS9hnhWY1BySUuzDZv3rx4geCiG2VYjiynCNXlsXYe21SjKL
	etQvcPXsCku2VYJ3ANZ3/46eajcc6TW16eo/IGE13EC/71++CHYZ4KUkZBi/udzb
	j/Q==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VZ1LKXPtRVbKqm1hOmFUycC0ZinT1rZHtxollgPIxUoFI++RCMiCPrQlNZ4NFC+swUDaVngGF2bFBrJ4P/AlptCA///Y87J/z3j1BpEQSFjlImA7Op3tjDsgfAiCeQlkss+YDyH0n3cu70zt7ML0u3++LCb0/uuP6R9wlO36Ex7k2TYoHztbB9Ow4aMuMFP3re3lSMtUjlNm05qQ4XWQ657sYudjO6cf/g9cog/orrlO9rgVEaRPnpzgEwrNu0vrbqTamN3A9L18xmB++iOPSB1DUYPShkDCTSND5LLQpY1XFSuEfBTQQWQl5DIQ/eMgxKHOkMSxi7ECL6HfKhZM9g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=90aLdj9xpoZAg+4D/L3YjgL0OFuZL96uidt3wVPvCGE=;
 b=qWhj0UzYYZVp3G2S4/F/7QqkmaO4ExmjOSqVLY+f+xqd4zkjoZrkGdErt5DgMdQUvvhd05FJDs7w8I2dNLDzpdV/su2wCsX3VYz6udRYVnAVjTb+Z/CHwfvfqHI6C2qnB/NvSKfWlG7lRwe29h6fGLSICR7CUHpaSzxfhzLEDscVYvk0iG9IWt95MA35/JOU9X/x6CuixKMXkfESUjCWG+vUnHDh9LbtBzqVri6enAF61q4NkUO4WHSQZzbk9S4b3vyR0956LfyueQkOcHqJtcvYeyfTEEeYJmsR+FKKx4+4nAuXL0nqR0MTN+BkC/zoEka8vUnq3Fr07whz9YTyUQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=90aLdj9xpoZAg+4D/L3YjgL0OFuZL96uidt3wVPvCGE=;
 b=IFwI0mRl5CyJBN34mujWY8FwjF9vuHDOqFoVO+ffUCLIJIqRnkO4nRRRzAoDnTjGMIHHhCZ/MvUfUZ/z38MP6mEHIQFEWHWrZjNLxQZnbQsCI/8HXOO3YSCdGIPhjcjKilaTatZuO7EIeVWK81tg0nLJ3VEgwO4kKWwwEa78pdg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to; s=ppserprodsaar; bh=Gz6pDUp5rLV7SS4lZjhFrNaNaJ+FdUp
	eMI3ZZ3G7QvE=; b=OLdYk/+GyQolBDt6NFuzr+SZEaN7vQ1z8Ures+SvUH0Y31x
	i1eK+1NgKrzXDrd7f7jRMx2K+k2/KztIFdWrE77hMVuHASc2DIsw0A8DJ9xufuPF
	p9Ccw2y0TgU0PpY1PWepdWnfIW9pWEBESjgy+nAiSNCRi2oOe1SrKztwAiMwiO0l
	uJmJkXRLJkfjBdIlqjkVNOJs1d1SiwB+e1XVdU+E/yZKiq1K5bWN7WCtDaJtsnSt
	v/HOnsFDr5Y7R/MCs251lIjgQnTh2oohHf5g4s2pI53i/7KuIlUSG5bQmQJl9lgJ
	N5c9sRQvuaqJZ2ZoTR689vdI13gXCbDneTEG0tQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppfserpocford;
	 bh=Gz6pDUp5rLV7SS4lZjhFrNaNaJ+FdUpeMI3ZZ3G7QvE=; b=I0tzNdRZXj7U
	myx5gR9XNF/qC29a3zRs0vt/24FkwXp/+eOcThd/BZObOCjaJzkvJmNaBHWUEK46
	fqIMqSxZpA08S+QB4AbtPlmkgdSm0VVR3LvmBjOItpxMm0tSek709rgBLYqwxWsX
	+om2fldlkpxCaVoDArPlELW2vN70wgacsnzQn+lk1Ic96VsL+48vWUJJQU3KxEEr
	bFGh2x7dK2/yzDdpcs/87aHi111cO/s1c2MTurlx435n4GgL85HcfyLmJzIk/vAA
	iy0Yw/pJq6axNrG0SjG63vye5gpcScBgy8qLn8o0seBY8Ftqm5CgESIoQZQ1/Pbe
	2Pv1vJm5aw==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: tUESwf7SGQLYTtUETw1jGb
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Mon, 10 Aug 2026 10:56:15 -0700
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
        andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com,
        sstabellini@kernel.org
Subject: Re: [PATCH v4 2/2] xen/console: add compile-time rate-limiting
 controls
Message-ID: <anoQv9sWca/mLWQR@kraken>
References: <20260729072520.1556970-1-dmukhin@ford.com>
 <20260729072520.1556970-3-dmukhin@ford.com>
 <annMNjOodiS3hHp7@macbook.local>
 <annM2322Ig23p4RG@Mac.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <annM2322Ig23p4RG@Mac.lan>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-10_04,2026-08-10_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608100153
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF000061C3:EE_|SJ2PR16MB6251:EE_
X-MS-Office365-Filtering-Correlation-Id: c5900d05-ce6b-475f-0908-08def708ae78
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|23010399003|36860700016|82310400026|18002099003|22082099003|56012099006|11063799006|3023799007|6133799003|10067099003|4143699003;
X-Microsoft-Antispam-Message-Info:
	of+8K6UXo6HVjp/yQGV0USQZWukpLUfxKzy10o43BOsVvRHW2o5yGrXXOfacT2dWTvELFoAzIzxXCMdL22TEVHGrVyyXI+8Cz5YzTcyBzIuN7RTa8n1P6mebnzFQsS3mKjszdtcgT4DOt1LCN8Nm1wpcRoMAQ7XL+GlDVVkgDM3kaheKX9HO5omHwntN1m4gpMCWafil/EY+mJYp+x3pGkdPdHK9aczWjkqHivPDjJtgtSQBzF/3DlRyvF5+9E4KXAEjo+5edq2ysE/2T/QpXixej1GrtdZ6Bgz/OuyqMQHKTqnYk6+VyVDOj8lPp77k+XL1xfP8HukAypXIoWj2u4NS6mDh6RQoIlH6Qhws4vlDADiAio/sTXiZ1Iva+0gfxlTOQfUh/qk8dDg036LSFkNEObH2SJJRDqEC+m8CZ6utWpAxFUGIRQoIdVAW5M2a3nXvsityO+mQSMBUu2mG4YaQGHDp0PfUGuqzb/gUBDQUJnjphV2oYzZ22UsOX8CQicnV2oadsjmeoPsrciCklM5HscKD35pyP0oqM+L55loLwxPTK3gC/HnKG6bEtQei/zV4kVJipI3R6pnhmep1H9C9+3z3u/zWPaa8DyYpyNb/i7EUm02/5ugC8XFOw6E2Sj62yknhA/7381tK7A2gNImtzBeIBnwym4GJxPMy4Oy4Z57cIX+auhVPN6QHcow9x4dVNiyR7BgmZAQjM2Q8aQ==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(36860700016)(82310400026)(18002099003)(22082099003)(56012099006)(11063799006)(3023799007)(6133799003)(10067099003)(4143699003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	mjMwknj/dCb6IVPpUDxCywhz7ZPgeGL1/TUhATS6OzNd64IDymuOFGkhAeofO1FkAwQhwPy3FQXHobP6fICgO6JB3TGjVbZwxEX6BKYUueK/FMB5M1zvK8yTX/UooSm/9uTXoRSc/ZdNDASn2xIfB9bgj7YW1TSgj5RvtfSFkl/FzZ9YQ99I6HfU7TiC+8u8+C76ZnuqgEXja3n01dUCUiIsPFTal3GXZAJmsR26rgR/nJG2CjNuWHHfNO/vnhOi3y7l29UgRjXkUEFYOCVXXtIQKCmpjTLrkBQtOevcJLZ46Zo5Cn+J+W63k921MiIx63VBrgeY5o7Yg8xG2oQq5j/XD+ucuJDr6BDQvnfGrH82J/vEf+uM/7bFo8eCuCCV/8/1u8vGHFbKAb9Cw+tkevOLe0ldL5iJA91lSh+0LxiCnsQoucGElpsSAKe6xSU2
X-Exchange-RoutingPolicyChecked:
	cAMGfj9UUkhjo34bWMXF0gnGvE9ak5Yk11oDnbdtAVCrAdKBblsyVUCMxqE0bDo5mC2p/pKy5trTmsoJk7xhTq5HGGxbqthmFCxyqFMMm8Tk3gwTda3O7tLgrjYidCwQK2k3GrzJ3YOm23XumJlj8cQ3vmIT8dh4+4Rf/wXOMHS3m6UttHjYbF54Be8xfXQLViMWXYtpitHVAcQ6g+WxI75xogAZw2kaGyGAZCcM7Jm6Svu9KDRFyfeB7Df7Y2pqr3p85N+Y/HuZZp7oIPwniOOxGn9nzSgY8zki+8VVVkoWiwhQdk19tGv9aj9iyo6/0/A4fhunwyr7Pz4VQYYybA==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	6IQ2hPZ3WeT0LSG5sCPASC+BmMwkm7orVC/SmvIX6E7iZmgpIUPgYcxzfpb+ywvBmC2bX7hJadoOhMEMMmMn6LL0FhMH7exp/sxhQQGIQLuTN8FNW4Itq0Eyo2ep7zCU/dXy6WtlZRw5Ws3omlh/jq68b3Fk0s7DlPjhGB8ae9NfUijex2St0CTH4SlUQ5/L8DTJFp99z3ej11F1ybfX2T+3cUYq9FZ29kDW0h3Qv7Y6QmGEwCVVL0ssF9CKn1pLlTwJlplV3AYQvQjOC6fV8PZOrGUE/YZhVqsJndHw+2fUxxZGIhanbZyrTejag77AaCMi1uFpDbn/T4J8tkFwjVoXA5qqF+FMwTVI6FWDl23JVMAkXR+K+efcPwZpBngagdD6YVLoYaZGk92kGhCOA2P9bEa12DqBYQLgdVD4L1/P9cJFOUxwCQIYSDTknDaz83qm8oNj1eGEFbvc5GbsKbA056zHLLe53Kb4ZZYgcxxwI4HGwJhdPOPhe8UiMCKMuBA6Y1RPZ2SCmWevGxI0tieeGwetU33ys3ZWAH2erQgHNj1nrf5B5hsH+iDW7aVPJMKqDg1aEumJUElDSmsYF+7otquJrydQT8F43mGLE6PgJ01ObdVpJhIt7q2o1N0oBa5IiseulgFKmaB67ts7hA==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 17:56:19.0102
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c5900d05-ce6b-475f-0908-08def708ae78
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF000061C3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR16MB6251
X-Authority-Analysis: v=2.4 cv=AL134PXh c=1 sm=1 tr=0 ts=6a7a10c8 cx=c_pps
 a=HO36DfDzC3pv6rVb14NK+A==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=8nJEP1OIZ-IA:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=N9_n2FxmZfwfyRXvS9-E:22
 a=VwQbUJbxAAAA:8 a=iox4zFpeAAAA:8 a=cbNQJ9GKAAAA:8 a=7fQNACYqGrSk0fLGjlEA:9
 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10 a=G69WFyCBNqGPyalROSdv:22
 a=WzC6qhA0u3u7Ye7llzcV:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEwMDE1MyBTYWx0ZWRfX3N1ivz/zpM8Y
 KHWjz6nnh3yhq2y4KU2wDXimjCNrJLr7qT6dIBdWUFCdqNxgbdAaucRGEsJDB130g+suHobDA5q
 R34r1ZzonGkXey1/mMwXD8jh7DESsxMSt2zzsoeVHPskolsm2rW/TRlmhkRtSPjTZ+6pgD9fyE8
 lTs3pV+pbAM+yUPhOddSIJKtuVZczOpQcuiG2RvtamT+TF/q4qhXxtoKf14jKPmihYNgNZYzzjf
 0qZ3ySTC4I183cWx/tNiKy7AXtxyVM3X0byeoxJeY+Th/m2uKeJ7APAN4XsroKtj3/ZPL0/TPNW
 VBQampdKIt6B50UXC/CGE7gH/cdxxqj9ebCYYdES2aOSr13d5JH8stsJnSRahlX+0OLTvPu48E5
 ExYfc61LEWV4dsCzylsIdZGJK8IgJDvqRxGOk+JmcWNy93Kn39+2h7DkOLx+GaYWsTv0EdHYVvt
 n7Y9Rb0hpaM5f+qQtaA==
X-Proofpoint-ORIG-GUID: j3-rNN05blIRF6n3b-F9A1nz0TBaf4qP
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEwMDE1MyBTYWx0ZWRfX3UzmaHIIOv88
 F7QQX5eKzCA8Qm7cd+8oPRRdoIDYR3pc0pf5LLYFCmUrjWjRwWdYbzT6RJ+a8pRm1wCTkVMuc3d
 Xubnm5Ub5YzqcclnYVXmI01MAxKtftkqvgunLYMgbzAG5PlCXYKk
X-Proofpoint-GUID: j3-rNN05blIRF6n3b-F9A1nz0TBaf4qP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-10_04,2026-08-10_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 priorityscore=1501 spamscore=0 malwarescore=0 phishscore=0 impostorscore=0
 lowpriorityscore=0 suspectscore=0 clxscore=1015 bulkscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608100153
X-purgate-ID: tlsNG-16d1c6/1786384587-FC20077B-C2303150/0/0
X-purgate-type: clean
X-purgate-size: 3335

On Mon, Aug 10, 2026 at 03:06:35PM +0200, Roger Pau Monn� wrote:
> On Wed, Jul 29, 2026 at 12:25:20AM -0700, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com> 
> > 
> > Introduce CONFIG_PRINTK_RATELIMIT_MS and CONFIG_PRINTK_RATELIMIT_BURST
> > for configuring rate-limiting policy at the compile time.
> > 
> > Use symbols for global rate-limiting initialization in the console driver.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v3:
> > - added note on security support for non-standard configurations
> > - gated menu with EXPERT
> > 
> > I kept both settings for now.
> > ---
> >  xen/common/Kconfig         | 36 ++++++++++++++++++++++++++++++++++++
> >  xen/drivers/char/console.c |  6 ++++--
> >  2 files changed, 40 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > index da80fdba8469..749d3bfb08e0 100644
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -672,4 +672,40 @@ config PM_STATS
> >  	  Enable collection of performance management statistics to aid in
> >  	  analyzing and tuning power/performance characteristics of the system
> >  
> > +menu "Console rate-limiting"
> > +	visible if EXPERT
> 
> No strong opinion, but there's a drivers/char/Kconfig which might be a
> more natural place for those option to live, and then there's no
> reason for the extra menu?

I had the knob initially in drivers/char/Kconfig, but moved to
common/Kconfig to address Jan's feedback:

  https://lore.kernel.org/xen-devel/2eba7de1-a8e2-4c45-affb-8ecb91278707@suse.com/

> 
> > +
> > +config PRINTK_RATELIMIT_MS
> > +	int "printk rate-limiting time window (milliseconds)"
> > +	default 5000
> > +	help
> > +	  Specifies the time window, in milliseconds, for rate-limited [*] printk
> > +	  messages. No more than `CONFIG_PRINTK_RATELIMIT_BURST` messages will be
> > +	  printed within this window.
> > +
> > +	  Setting this value to 0 disables rate-limiting entirely.
> > +
> > +	  Configurations using a value other than the default of 5000 are not
> > +	  security supported.
> > +
> > +	  [*] Rate-limited messages are those controlled by the `loglvl` and
> > +	  `guest_loglvl` command-line parameters.
> > +
> > +config PRINTK_RATELIMIT_BURST
> > +	int "printk rate-limited message burst size"
> > +	default 10
> > +	help
> > +	  Defines the maximum number of rate-limited [*] printk messages that may
> > +	  be printed within each `CONFIG_PRINTK_RATELIMIT_MS` time window.
> > +
> > +	  Setting this value to 0 disables rate-limiting entirely.
> > +
> > +	  Configurations using a value other than the default of 10 are not
> > +	  security supported.
> > +
> > +	  [*] Rate-limited messages are those controlled by the `loglvl` and
> > +	  `guest_loglvl` command-line parameters.
> 
> Is it common to use footnotes in Kconfig options?  It seems a bit
> weird to me, I would probably just expand inside parenthesis if
> needed.

I'll just drop extra text.

> 
> Also, I'm a bit confused by the mention of loglvl and guest_loglvl
> explicitly here: messages outside of the selected level are just
> discarded, and hence it's kind of obvious that just messages inside
> the selected level are controlled by this rate-limiting.


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 18:39:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 18:39:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387758.1628995 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUu0-00044K-6N; Mon, 10 Aug 2026 18:39:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387758.1628995; Mon, 10 Aug 2026 18:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUu0-00044A-3E; Mon, 10 Aug 2026 18:39:12 +0000
Received: by outflank-mailman (input) for mailman id 1387758;
 Mon, 10 Aug 2026 18:39:10 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wtUty-0003vl-AR
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:39:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtUtx-004GdX-Nh
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:39:09 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1ab1-8faa-0a2a0a5109dd-0a2a450cdb52-10
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:09 +0200
Received: from [52.101.70.108]
 (helo=AS8PR04CU009.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1acd-f479-0a2a450c0019-3465466c25df-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:09 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by GVXPR03MB11092.eurprd03.prod.outlook.com (2603:10a6:150:2a9::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 18:39:07 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 18:39:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MkuD/4uC1xz1LgDqjFjLm9BB+pFe8iDtLQSjSZXM2QWKDdVM1RdmJMsOBx8vOx8W4GfD5iMXOAer1k9NOoqEErYMO54CcCiWJMG8AyfLOvLBIAVIwLg8U3/2NutkHV/lGh0jTDw0Uy61O2GOKa/WDoD3YuhHRcoEB9jAhyMdOq/ivqxlty33oAfCvMkd1NUzUzaEPSEsToSib+olYEYCDN4WQ/G63BAVmj2CSIhUlKJimw2Q40du4oL8dn4jmGrZU8WCsz9vlnNpCiRsPzT2wCVhoHo++Nn742Q28A5kkeKxqqUAsuvR6iHXVKUvFsA3z32VRIhELKQQF2j2SiFUQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kVyUwzxHfI4tTSVlImEGxF+daEm0IvBED5qt0xYcoeM=;
 b=a1lvWneZW2ld6z2L4txc4Av537scTG3wBQ0HEn3pWvxgd21Dts0/lp4zJ17yWCjMwMWiWYTvJsVQuQNIL8A3dFtVFsOKXYsoSaJ3g03qv+/IabUMIWdE3+lKzizXSB4QT4jQBfaFNtrxrD+LAWIpzmy1Erdke0TYXInfTNFD68eAQj/Ey9XLeCvZeA6MffSexNZiKpPNd/io8YyLzjq6+DQ8rU4Yvof8dfXRSd90LaWwhP/wqAK7pOZYI/SWWyQHpHVz9Y7RjdqCskhXzPB4yEo/kFjeNLVtrAy5R4nmu6uYQJpG3t6A6H5wJ/dfPto7yuoSEouQtRanPawcc0qUtA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kVyUwzxHfI4tTSVlImEGxF+daEm0IvBED5qt0xYcoeM=;
 b=piJhzkEDpo90vyz5ZbtXC9IGOoBH5okMIm4+4GYVqeDe7z1QXYmZBwWbwXzr0DQl+XtjM3sWwXLWd1596rNW/yhQqYAZ+AfbWCqokq7c1PyJfGF9LsCqxNUQr5SaRL/HMt+kH7ueE7EkwAkrASNUcfDAvRAmOBwP9GJXDOVfJ0VYIWdaMC+2MinsxDYN/hscnD7HQ3DHc43szvh5MIeGvbpgZCpwilVyhxNf8WXQ/t5diIuI5r8DUoI64GAl01dIvomheqne0I1XZyHq+dlPyf4vXCfDKoawKc7lWUVz3LbI4uOSbHFMl2D4Vj82SviVEuCTPMDBzc4UFvJLWCSCEg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2 1/3] xen/arm: validate IRQs before descriptor lookup
Date: Mon, 10 Aug 2026 21:38:45 +0300
Message-ID: <271952244ae71ade885b3619fe161ed4f47777fa.1786385827.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1786385827.git.mykola_kvach@epam.com>
References: <cover.1786385827.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA2P291CA0003.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::7) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GVXPR03MB11092:EE_
X-MS-Office365-Filtering-Correlation-Id: 79716599-33e7-4502-41eb-08def70ea94a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|18002099003|22082099003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	DTnUM2/yO4tjM4VCe3opWtzRa8++oAhrGjQfzYkLtdJjUPPqLBX90BF7HK7JUwdwZbmg53ENtQnt+r0fBKZWOn2SrLu33aEp8zNxz0hzgeUo4VBlUQz4t9ip8VGxTfZNU33wOp9SOlgpJlHIbpWUP0Q4iTucTim2d0hK4ZbOzexE5P7cOuTBI/UBKhFc9vR7AyNACVSDrT/0XPaPUVrCim+CkeRxETL+lfU0i1At8lMJTC7OPYJ8mNGC6muf7NkxIgVwmNu8nxU78af93OkOcXHGr4x2sQ5be/Y4Jn+6nCT15Y+pWNOuOIM3FN2XwRUDME8JfZMbL35nFr+OAMnSdHGvxka7kAhBBGKmz/0EClXD6iZnXJGn1cFogFwMEqRxX6NkMzQaFaU1fq6JGEtz+kiZupNQHCYuJtmZuWNUzSmcmIwiQs2FCh0JfXFYsBcP/JiQadRSIciADhLDU3kHemWJVXFFO/aZa1edAfT4+dA7ui0QbXmDCfNNCkDuFCH+8tA3viBcYcI1t7uGpM/JX/DtMzEGC9V2rw2kqkTd6Av02OM6sDBOt/N4F9OiQv7pbnhyfZ8HTouv6g7bgWCO1CCfSQNwn7krloCQMGsP8+wKSa/UfBZ56kjjjbFG/2TNmHRBIoUoTYHBHW6oe5W7S++jj4uyWQnMrPGspG1rMTQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?8TwRj4t0Dm316TSSixjbA2N+QImoV6fuL2ASZC2X79mr52JBUeIsygCCsLTk?=
 =?us-ascii?Q?j2epDIzrZivut/lnMXwjURk4TAyJshZOKi5fHokUfPMvoVdr5+KzLSdAw7ML?=
 =?us-ascii?Q?vNv5McFPJk/fFUc1x3bDU0kQUYrHKsp2LeJnmqE+Pqt9wzAxsTtPf8UO/j87?=
 =?us-ascii?Q?lp6L7cK2TnLyX34EuejsJnmC9YnHsYGulngsuRqMNn4z6ogYasHPKJwCCADM?=
 =?us-ascii?Q?S74bHXA/OCeexVYurTIGdtN65CKqWCdXhqYlG0mfmllJCRRTTWxquhHvQ8Sf?=
 =?us-ascii?Q?1Vsr0FdYVvJaBxXsaFh6E9hr9qLAiSF+Nw1S20HAzBevjRaCrbFSuh1Wc3Ps?=
 =?us-ascii?Q?pE49w0E0Dn9LlUwLWDWB2+ZDBvp+4hdmSf1HS2EXxkBDfchFEAnTH8FKw8zP?=
 =?us-ascii?Q?S/Xhu4FIZ6WfWnBdfJo0Ff71f0RnhevYj4z6AbXTJWS9o1vbnRem8B0HD4jv?=
 =?us-ascii?Q?6511hXNWoNMhwqYbYkBQ2lUK+R0dSLOat8eNzYfAom7Eo/K7B1BGWSOIiwZ0?=
 =?us-ascii?Q?8NHRPgyf6hOJlHMhZZRfqn1RDNxkhUuDE9lQ0NaBHZTHAPcUGCFqVAgdA9V2?=
 =?us-ascii?Q?mOHb7EXxUjYSnG+14o8eO3mNQYpjMCytBAi81vMl1MqRhXVi0FwO5RMcdK11?=
 =?us-ascii?Q?WVDOXmvsh6s+XJu3jYqeWVEfVxV/Hwd2ArRr1YbQ2D+uxBwZrXNXL8sIZdfr?=
 =?us-ascii?Q?+G8he6vuy2o+PHBbLYAnzkejK1I/31nno6df7GOdxquAxJgHWzE2NPoTDr82?=
 =?us-ascii?Q?UZFD/vOg3ha8LjT/MNfz1cuOFBOcKLExXp7s8PddpSJzcQ9kpE4UiE453I1x?=
 =?us-ascii?Q?XgVesgdVVG9iqvagS9xhofu7b7NxVJMLR8fihhPRzO3Ca94gtBMtWeEJF7Ws?=
 =?us-ascii?Q?GQfNfUuFTn4vk31yGcViRBu3mg0e3i7x20qfw/i4zxYsvaI85GwqIVPfm20z?=
 =?us-ascii?Q?cI+vRo5kG+i5Gw9tIWFGEkd4FBrb6Y9Qc8EZ63upfWhpezykNApG/uCQcOJI?=
 =?us-ascii?Q?PfPcUjxTCJPikQDcrEJ8M4mpP53e1zBAwJsuwVCWawZ/eq0rMVjJO8o4DaC4?=
 =?us-ascii?Q?isBx8vPM1RQxYcJIt2+yj1xgQR1V/F6yR2+mSDXjMVGJLWra+r8cGLX+67gH?=
 =?us-ascii?Q?x08c2ryYStJsH6SWp9TxHNX/nNKU4SkDk7E6CSGwY/jZGbTTUuTkSrtOguAu?=
 =?us-ascii?Q?40kUrPsMVgkTgVGRJRrfx9QVOnVt2ivimUL6nIKEFPDT4HQnuIh/VkPe/4DR?=
 =?us-ascii?Q?RnYzWqJn+DcVQeVa2QResrsKTQZK9FAWaWXxwQIgjZG7CyPbe5J4cWJHm4Lq?=
 =?us-ascii?Q?2gt5z/L7k/cUP2Ck1/w8Snw9+odWmlG7Iqo7lvqPj0el10GcAEIgh1/pJoF0?=
 =?us-ascii?Q?khxh+O+QzaNWj76g9Quzt3sZKs9/GYX3K0dG1dftlg4p56MfvMB3d0xAnbuX?=
 =?us-ascii?Q?TvDOhVhE33r9QfER6LSf6qkOwXdjdiJhBg0F3BN4PxAJO36PZZ5itznjR2xE?=
 =?us-ascii?Q?BymYBkYjnNiQ/6oiIKNjC7dQT865siQaUNWWEgKmRcKY2nK/RdiA2CZwjAJg?=
 =?us-ascii?Q?2ZyZ1oRp8niZ2T0oYuonzmaWAPOnKjMgZ2fnEWXj5ac55tzfqw2mianJ+79t?=
 =?us-ascii?Q?1GZf9a5I6FaW4sNOwHNuHNnA/YboPFybqLLGrKHEniQtvo08tkMvOVhnsRie?=
 =?us-ascii?Q?Zm521yO3L1FmmcVz6k1XwvRmh2j+UfWQHQU/VLnMg0N3uy+vDiCNH+3XnV7w?=
 =?us-ascii?Q?D1+f4dbmdw=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79716599-33e7-4502-41eb-08def70ea94a
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 18:39:07.6512
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Pmxpi/7tZS1iZXG9ZIIbY5b8dD1xyie2gBhHlftMJYOGWGnj1ARdYFPeGvqXZxQqO1mbWlQvOAG+AxHor37qhQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11092
X-purgate-ID: tlsNG-d25034/1786387149-00ACCA5B-B832265C/0/0
X-purgate-type: clean
X-purgate-size: 3677

GICv3 eSPI support makes nr_irqs span the architectural INTID namespace
through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[]
and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs.
INTIDs 1024 through 4095 have no backing descriptors.

Validation based only on nr_irqs accepts an INTID in this gap.
__irq_to_desc() then indexes beyond irq_desc[], and callers may lock or
update unrelated Xen memory.

Reject INTIDs that the GIC reports as unimplemented in setup_irq() before
looking up a descriptor. irq_set_spi_type() can run before the implemented
GIC line counts are available, so validate descriptor-backed ranges there
before looking up a descriptor.

Call is_espi() unconditionally in __irq_to_desc() and provide an
espi_to_desc() stub when eSPI support is disabled. This preserves the
is_espi() debug check for eSPI-range INTIDs when support is disabled.

Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Validate descriptor-backed ranges in irq_set_spi_type().
- Validate implemented GIC lines in setup_irq().
- Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled.
---
 xen/arch/arm/irq.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 73e58a5108..0f5d3496bf 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ?
                                         (ESPI_MAX_INTID + 1) :
                                         NR_IRQS;
 
+static bool irq_has_desc(unsigned int irq)
+{
+    return irq < NR_IRQS ||
+           (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq));
+}
+
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
 
@@ -77,6 +83,12 @@ static int __init init_espi_data(void)
 }
 #else
 
+static struct irq_desc *espi_to_desc(unsigned int irq)
+{
+    ASSERT_UNREACHABLE();
+    return NULL;
+}
+
 static int __init init_espi_data(void)
 {
     return 0;
@@ -90,10 +102,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
     if ( irq < NR_LOCAL_IRQS )
         return &this_cpu(local_irq_desc)[irq];
 
-#ifdef CONFIG_GICV3_ESPI
     if ( is_espi(irq) )
         return espi_to_desc(irq);
-#endif
 
     return &irq_desc[irq-NR_LOCAL_IRQS];
 }
@@ -416,6 +426,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
     struct irq_desc *desc;
     bool disabled;
 
+    if ( !gic_is_valid_line(irq) )
+        return -EINVAL;
+
     desc = irq_to_desc(irq);
 
     spin_lock_irqsave(&desc->lock, flags);
@@ -647,13 +660,19 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new)
 int irq_set_spi_type(unsigned int spi, unsigned int type)
 {
     unsigned long flags;
-    struct irq_desc *desc = irq_to_desc(spi);
+    struct irq_desc *desc;
     int ret = -EBUSY;
 
-    /* This function should not be used for other than SPIs */
-    if ( spi < NR_LOCAL_IRQS )
+    /*
+     * The implemented GIC line counts are not available when early
+     * callers configure IRQ types. Check descriptor storage here; setup_irq()
+     * validates the implemented line before the interrupt is used.
+     */
+    if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) )
         return -EINVAL;
 
+    desc = irq_to_desc(spi);
+
     spin_lock_irqsave(&desc->lock, flags);
 
     if ( !irq_validate_new_type(desc->arch.type, type) )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 18:39:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 18:39:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387757.1628987 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUtx-0003rI-TA; Mon, 10 Aug 2026 18:39:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387757.1628987; Mon, 10 Aug 2026 18:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUtx-0003rB-QC; Mon, 10 Aug 2026 18:39:09 +0000
Received: by outflank-mailman (input) for mailman id 1387757;
 Mon, 10 Aug 2026 18:39:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wtUtw-0003r5-68
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:39:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtUtv-009VLW-J2
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:39:07 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1a9c-e002-0a2a0a5209dd-0a2a450ba360-38
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:07 +0200
Received: from [52.101.70.125]
 (helo=AS8PR04CU009.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1acb-b7e8-0a2a450b0019-3465467d094f-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:07 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by GVXPR03MB11092.eurprd03.prod.outlook.com (2603:10a6:150:2a9::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 18:39:05 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 18:39:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jj06GD4Ya6mMdi1TTCLyxnC2ZcN8Dza/D87t2MSRCtMEqqaT/VXhdioR5GbpsF6yqpZ1A/SqipH6S+FP42VWKDCMfRzqAKzyZWP9RyLaKf48AZpPydhj9rmUI2OZxuwShqDZKqCHxx5ee9IVvnGFmsxO2DgNm6W/yWgDH1B2UNh/E3XETFOHZy/TXg43vJEoKKgRWXWSXywvdrrhFo/6K+6cSRfl4/qVYSGDd6Q8HOrSlSXbCIn+jOE4FLDEJQdUVgCa0DtoUNt475V3ZUs3guc1pEsgbv30TrXovNfKSdlksj4F2PyhL/e5W5/KcD2TVXEA0K3C48InX3yPdfOqpA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ApfjuVvydupd2rUlQk2WyhjFCE9BsKkNyBdZC9YvoY8=;
 b=dXPFgJllcdkfgk+U9eu7g+ScQZvTWOTQ6R+2W3exXnFtnlrKLk9yIfncBYWBRCWZFUsibybGvJmdvayVkG6fAjw1ABGoTgSRNF44kseKpPBrQIqpCg+xYBmiWRqJC2yCLXjuhnODuHSoSrsaP3Oyz1PRrVMq1MECWkZiiIEgdoxXUfU1FgmnfuT7GALifqMrNxQiaPPgrGiWXBBxmchMapzWOk+dbP54Iuopa7h9Xy+U0lFBOks6uOoDvjYnMW5o4tAHn2uib+hWGi36DHFUEpLlH2J+uRDlvunlndrijAt/aMGxU2Ibx3Dhcg9BazYeHF6+0iiqu13oRiod6YO7gw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ApfjuVvydupd2rUlQk2WyhjFCE9BsKkNyBdZC9YvoY8=;
 b=BwexvDA3nCJqyxCDH+K8vrNGkjfDdEqAiqNl1VQnW/p4fPNoduOhi9g10/oqRy1sNfVDxwcu/hOzm091PNyVWzU5koDpeLKqqtB1OMmuupUoxI6OPz0C50EobHg1UIE0E4CjX1js0Mzy4iQ7qck4baFoN4LP/fM6h9FSINARbZMKFzeNqv8u4kj9iysE1jaTfpW3xEbS6ObE8kZprbYQsmClHzJOpwAfXDqD+7xVsohRS9uPxOShoIGJgwL4uARpgnwkyynKXnpsdTl5A0NLaaOoqjwfg2YtzmP0cpknhIzUlwrqzVt1u91vWUoDtjbrhhmteFUxkwukK30tmscyjg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jens Wiklander <jenswi@kernel.org>
Subject: [PATCH v2 0/3] xen/arm: Fix eSPI IRQ handling
Date: Mon, 10 Aug 2026 21:38:44 +0300
Message-ID: <cover.1786385827.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA2P291CA0003.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::7) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GVXPR03MB11092:EE_
X-MS-Office365-Filtering-Correlation-Id: 320c9fd1-d5b5-41a6-31b3-08def70ea796
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|7416014|366016|23010399003|18002099003|11063799006|56012099006|6133799003|10067099003;
X-Microsoft-Antispam-Message-Info:
	qKGKiW4ol7W3hk3YPSqDQOjW/jHbwjwSVHyzVgYrsH/mpyBr3OTZeU3/boPEc3RSBk975QUBXZ8pdL3szIrHs0RXvjmeov+i29u1wrT0NB0lSfvcwiIPYEWg5OkT8humvTEqI6ScZHFMTCTZm+sn4aXuwmXEtceKDN1mgy/+q9dBlAQ9EefXihNpCp40jTaCPbP9FAXBPgBdlT2K0eudnK0bbJiDtOvBlIGuCJ9vTca3LSzeZJNBjB9q+XUpBGe2rZPcdkeOPsjQsCP3z8zdC5jPyOdAONdIl+CSQmgsQYgmw1AGvOwxIuRw3pK4oQG0UckfUXtfIh1U2fuRMXsLOJsCgvR0R9XXoIsfmJTUOz6QmxkHz71pGNXQRg5nOjXOrWryclNI+ViBTHuh9+tv8C8wB2X0FMvfCSVsI0GG0Tnj46mTRrG0uAUNVBu5X+DqqgC4XV2Ze3mqUB2heb5l6gnqIciwDp9sRefp9QCinfp0WVSLVG4YN1tfy6Qy00rR3WJq0sjCXIKyAxgemGQLUlkkNWV933t2UQsyx5eL+8vyRaJCOPF2jaKezGihfwp0QK46xqtGRwOAlkbKXSgWH+h1yVgdzeQ+lN8zsJZraIY=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(23010399003)(18002099003)(11063799006)(56012099006)(6133799003)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?jpIRXTn8qK8h832UI4Doeo7kwPOQPwEKHYsVNTPwYxylw4ubIOviPElKni/0?=
 =?us-ascii?Q?B0lVB9PQr4gMhm3S2hsENLvee5Vos38rST5KZjoPROxu4DUxx6V7FCK8HyuY?=
 =?us-ascii?Q?g65qX9lNDgMLiYsOf6rBJ6u6Ml/5qGar3In7VMka6e+fkFQke+X07+qhge1f?=
 =?us-ascii?Q?HkirX8GzGeOEjIJaGtO3z4xc+iFMkd8HJAVWn/evaUJ5FrjuD3ionOwzZh5i?=
 =?us-ascii?Q?bU9kAAFaho95N2GS4mNeRVx8RlnIFMWjsraHHC4eso9wlEIJrBDcMOJgHY7P?=
 =?us-ascii?Q?VAKZWzGQUBeK1pTkiPquh3vYv0SGuM8VTL/lL12CI4y6/LfK5EJ+LkfNumYD?=
 =?us-ascii?Q?BLHMaUY4S2q+PtCwOeuu7JRoivydZhcYxtxi7SbYEe0aaogGtXAMIADwe8rR?=
 =?us-ascii?Q?lhS0CD39LFlixPG7KeIfjQyOOFtusINJ7ZJ9iq9IUbHE7LhRMM5JB3tlqwJL?=
 =?us-ascii?Q?KZbjEAT/Nztv2YRduLTg6G5oeFIE3gI5zey5RF+AcQLXKav+mBUFMLmYgXp4?=
 =?us-ascii?Q?0McrUZM9LPdBEVJ+v85tEf+3JRxFVxTxm4kBMdtjIvM+Tx2JBZjfHtiYTw7v?=
 =?us-ascii?Q?yqx9m2Li6sjy01e6uuk3aoY9dnsJ1EQSf1UfrUogQAGoo1+042a9jF+eEpk8?=
 =?us-ascii?Q?GxWGS+ZN7QNpebpABHHQJzHJgDGZI7Q+9ayhHPV1gvXwoCawCvP/7GvDzJ+X?=
 =?us-ascii?Q?smjzHdeIXvuIbjMjwjNGMg0Jg+OZAGYi7wk6wxNAw1BioNkvIyOFuhI0jNt1?=
 =?us-ascii?Q?DfNwLxHdO1gAmXC0TptKUyY5bXAdgRaqaAZoRKq7KHWTKZ9LutyCWUlFIWNE?=
 =?us-ascii?Q?STiM+XQhmPBaL6ygTwCgsq0aDrMIgT8ZvIFnXuDu3VaGtQGiI8dE3nCyyc7w?=
 =?us-ascii?Q?lsBI9MrufDcT8thFpQv+OY4niooKTe7IF7dFoRFRF0OJifm7I8ZSdpeik5VC?=
 =?us-ascii?Q?fGdRieitfO5rCv2a3eKrSlUT6vAig60Kj+KIOCQxYooGTJzqFPf/YJPG8M2U?=
 =?us-ascii?Q?kBN8dWb6ISkQO+xFrDXF8CS3W9RgjT5x4Hz1dUG3edKR3RJ+RI98qIirOAKg?=
 =?us-ascii?Q?H1KgCx/TwAXR60HOyfTlShvVJA/dPNNy/FLDXyc+c/wtDb5guEq41SN5GKt/?=
 =?us-ascii?Q?tIxxP/+5o5bs8cofNncDufbhuRJOI71q2OgwjXhvXyg9o0wRwM1LXhcNcvcw?=
 =?us-ascii?Q?14ovykgpiMhKNwAJLpOqgBMSPuDGKFVVcXR/EOO5fl3hIolmRWQPkXlm9kS7?=
 =?us-ascii?Q?IJ3wrFIOe2s2+6GST+7zIPxu1y2qKt29VzWIWFssO8IasQp/7jLP+VoKc5HV?=
 =?us-ascii?Q?99D1Htf0ixkmiPTbIt6rE4e+ZNRbCEsOLI7cyv9rMonl98wHXUdhier0r+Uf?=
 =?us-ascii?Q?c7wMFaIO40VhY2eCfQWCvVHwryO7mpPx0DvzDJJs5pFBzreuyeUBDDFDIEM+?=
 =?us-ascii?Q?lFyab8lMp/lAgol1d+sDUxM1RiJ3LDwEWg35eQc2RB3afGkZMHifktFhbSDA?=
 =?us-ascii?Q?OWtiavUVm9qb9MdSOk9rELNV3T9xFRuM2GFxRpi3RFzK4IunKYYUAdRtrzk9?=
 =?us-ascii?Q?h1brqKg9N1inCiFHoS6pPtGhTxsESruHQZzLFEg320jgrK0xH2DZSb1aA7dU?=
 =?us-ascii?Q?zCVCcB7GnHdyYyJ/Q+L2QHoxa3lI320ydWzWyBlki1+ST7SANZgY7B2gBk+P?=
 =?us-ascii?Q?3BXbzRbx8XAtuaFKMfCkbul9fpCgsM4eTVOH3acoxTNe4nL2eTa3V00wOH6d?=
 =?us-ascii?Q?OMwQUyP1Uw=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 320c9fd1-d5b5-41a6-31b3-08def70ea796
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 18:39:04.9618
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4mU9lD0hsQBYUO+WNhSqACEc/MVrbt1DKKhBWpmZEIMzbGRmkcASGvWO9aWeiVL97EAsZyCs86vsQPRoXWcicQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11092
X-purgate-ID: tlsNG-42698a/1786387147-AB6D29EA-AB4E72D4/0/0
X-purgate-type: clean
X-purgate-size: 2349

This series fixes sparse eSPI INTID handling and checks errors returned by
irq_set_type().

Xen has IRQ descriptors for INTIDs below NR_IRQS and for eSPIs starting at
4096. It has no descriptors for INTIDs 1024 through 4095. Patch 1 checks
INTIDs in setup_irq() and irq_set_spi_type() before these functions look up
a descriptor. irq_set_spi_type() checks descriptor ranges because the GIC
line counts are not known yet. setup_irq() uses the line counts once they
are available.

Patch 2 fixes the vGIC allocation bitmap. Reserving an eSPI used a compact
bitmap index, but freeing it used the raw virtual INTID. This could write
past the bitmap and leave the eSPI reserved.

Patch 3 is new in v2. It checks errors from irq_set_type() in the GTDT,
MADT, SPCR, and FF-A paths. GTDT and MADT could keep a rejected timer or
maintenance INTID and later use it in a direct descriptor lookup. This
patch also fixes MISRA C Rule 17.7 violations.

Tested with:
- Arm64 debug builds with CONFIG_ACPI=y and CONFIG_FFA=y, both with and
  without CONFIG_GICV3_ESPI
- FVP Device Tree boot with 64 eSPIs; Linux dom0 started
- QEMU virt UEFI/ACPI boot to a dom0 initramfs shell; this covered the GTDT,
  GICv3 MADT, and PL011 SPCR paths

Changes in v2:
- Check descriptor ranges in irq_set_spi_type() and implemented GIC lines
  in setup_irq().
- Keep the is_espi() debug check when CONFIG_GICV3_ESPI is disabled.
- Remove a redundant CONFIG_GICV3_ESPI guard from the vGIC code.
- Add patch 3 to check irq_set_type() errors in the GTDT, MADT, SPCR, and
  FF-A paths.
- Target master instead of the 4.22 release.

v1: https://patchew.org/Xen/cover.1783671887.git.mykola._5Fkvach@epam.com/

Mykola Kvach (3):
  xen/arm: validate IRQs before descriptor lookup
  xen/arm: vgic: free eSPIs using the bitmap index
  xen/arm: handle irq_set_type() failures

 xen/arch/arm/gic-v2.c        |  8 ++++++--
 xen/arch/arm/gic-v3.c        |  8 ++++++--
 xen/arch/arm/irq.c           | 29 ++++++++++++++++++++++++-----
 xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++-
 xen/arch/arm/time.c          | 18 ++++++++++++++----
 xen/arch/arm/vgic.c          | 25 ++++++++++++++-----------
 xen/drivers/char/ns16550.c   |  5 ++++-
 xen/drivers/char/pl011.c     |  4 +++-
 8 files changed, 81 insertions(+), 27 deletions(-)

-- 
2.43.0


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 18:39:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 18:39:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387759.1629005 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUu1-0004HA-D6; Mon, 10 Aug 2026 18:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387759.1629005; Mon, 10 Aug 2026 18:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUu1-0004H1-AH; Mon, 10 Aug 2026 18:39:13 +0000
Received: by outflank-mailman (input) for mailman id 1387759;
 Mon, 10 Aug 2026 18:39:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wtUtz-00043z-Tb
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:39:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtUtz-001Qiz-9s
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:39:11 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1a97-bab6-0a2a0a5309dd-0a2a4506e8ae-28
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:11 +0200
Received: from [40.107.162.106]
 (helo=PA4PR04CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1ace-195a-0a2a45060019-286ba26ae5de-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:11 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by GVXPR03MB11092.eurprd03.prod.outlook.com (2603:10a6:150:2a9::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 18:39:09 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 18:39:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q5uBXhzZOluqHZr0P63zd2MnW5MM1HybjByZYGeEQdeVkyWY0vTsEjGbHm3nyJOBdXm5eGKZ4O9VptcC7UF50wGYPDvtDIywmSS2djXXY2/QUdu6XlGspGkE9Q9LxLMM+DCkQ1NnjZE7PzNITArbjH5Btp/U3ZRXNxcvwlVxpM63sLZ7ppSkrreQkmVhH0IJocjqXgIlEvgC6IBYk2NCymoMGGhSQzdqkc58D7IwN6S5cB9vwDtlLPmZSO2fNakfGf8bhC5DW0OgcboVoDPimEbNucdpcj3HkcOrOlnB7Xgp/jU5muGz8tYO1yxLTV7En8+MvgWHhAz1rSSgYkxocw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3oS5+tMpm/5iXbHipLKgLe69zKs89CKb5K72EOJFaZw=;
 b=m7QzPTf1vCaIA+54KwKVqE0+fOyBelUiQ0wdpRCjmREd3E662KF29u+zkjy2dR5OgYf54WCDOz/ytpdG8FUUkAbvXLsCRF5uXwMIQkjfcd7ZCyd2W++UnTqe9BYO8MEjg1sbmPYtf8aY5GSMjW6lXDbAvc+qBBMTg1+aAL7FOBhNe1nj8lLt7EeRXc+v4UW8ENkcAam5Y0HErWOjic5jGmL3Io/dfFId+2DP1bNh5tmUJd47/TUKYY8mm1AwyGQnpj0HIyeYyC2OW7n67hVffbBBVVr5MNPhg15QRRCERfQZxZI4th1JUdx9k1r0jxszBfyktpr7MBvT5SKlc8rhIw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3oS5+tMpm/5iXbHipLKgLe69zKs89CKb5K72EOJFaZw=;
 b=DRg3NnZs4JflfK+CJPbmb3WoQP9Ce8g6/0xsgoEBm9CBUvc9dFcKzxqo2/ntLlZ0f1TvEoFkqAm1I8HDKKlGMHNjBt2QYbEHez6ns+oom0OnOm1lCr3lIpv2vzYNxX4tVLW4zQp+1Jh1FA/8gQDLPiwcdNQuyitxhFIEpGvZxw7zcaDglUt4aT13O6dMcr4Z9FSQOZGzi8ag/zRm5L/gg+wyEJMxxJJlexkrT9jdn6L68lN1LnEYWJxBL/DzT8w5QIYDCQSJqG3lY7NgPfSXCeUmH0ouNjsLKOYqQSgbTP1Lpdjm6BkjXZk9fXoBua+oeJaCPnuF8rM50lQCsJLlKA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2 2/3] xen/arm: vgic: free eSPIs using the bitmap index
Date: Mon, 10 Aug 2026 21:38:46 +0300
Message-ID: <cba18900fa18730e717ac736b4cb4b5826bf6d9a.1786385827.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1786385827.git.mykola_kvach@epam.com>
References: <cover.1786385827.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA2P291CA0003.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::7) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GVXPR03MB11092:EE_
X-MS-Office365-Filtering-Correlation-Id: 45e6ca56-31ff-4682-4be0-08def70eaa60
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|18002099003|22082099003|11063799006|56012099006|6133799003|10067099003;
X-Microsoft-Antispam-Message-Info:
	ypElvmTH0i4qLpafa/XnfNhc3Usilr1pAn27RJImdMSJ8GMjgA+GWl7BCy+U3jK/Vp2eaZ4hcJn+a9Xm5Llr2tHjXLq1UpwzT5+78X6HFeAWN6WSUZfOWT/fosy9tL9QP56bPtynyQQxrrANYzckQsnGW0ZNbMUwn+2GQvExzM8B9WLVeoFCwxkpU6DXMEDpxerzuKNwwxNoZL75ltS9KaVyv8wMlhZd4i/bOIL4KdY9s8Zlk20ruKHCLYjcm96oxVGGsli2CjIOHukKkSVyW7GKFDxCuBbHB3KoXvlfirx0s30qtHLIX0+zzJsVzXyHUV5YRdgrc896Kjcl1eLEmajPAYu7GIjrMlkJeKGMd7U2yOt0qEuWHo4lwpI9okzHc6NTbnCOYz8+Z87Dl6JDbH8kvBAwAZIYYHX5dyiRlkiopMsp3j+Rzrdod+laQH3aFdgXoxyNN74Pzu9kjcAG1ktYjFzMzQFsWo+h26/dMhinvvB4DJQ+SDUHQOskSXWIcgvCffe88qUFI429ud7i7MF/6qyd1VVPCQLU3JvqeKOPEHZ7yOG6yJRxRMpiSazM18S8JeYcNxPabZeLKGTrueazyW6AGx76+tiq0uUCm714gbUIHqY9rd42TmT2NYufem6s1Rbcenw18PuCKi+9izi2Q/W637VF2nWonsk9U5w=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(6133799003)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?UBAFgskfUvGkIrThajlleE2H9fnWTdt1G/nKVeMim5h/G+ovpRyARQJddViC?=
 =?us-ascii?Q?W5cPeVjyBjx/vwOblKlgvk1yVP7wgWTlNBAK562xs5CtWczKBntafvPy0i+p?=
 =?us-ascii?Q?GWR9rGtyK5N+os3wB524WZXFz5OGgSK/DkF356fYdrKU3qrQY/S36PxjbNrc?=
 =?us-ascii?Q?yHKEAflp3nYZR0YIQBBvAw5u8+7qk4lB5Hs45K8neV68/kB9Xp7f22dgfkF5?=
 =?us-ascii?Q?E5ys3MtK8YrTcIqPexM3yT8qgGRZ4V5PNtzZpesjtAsP48yACA4mS5PYfUMF?=
 =?us-ascii?Q?ytvakTFXbtcuU8vYvGVAlARsoNBtDMRCl7f98kuxIyfB+xhJe6PcwUSSiv+e?=
 =?us-ascii?Q?zyjglgIDaQWFZ7OtcYTMAHCfIAcPRgkBTfALAVbGXH/t6CIgyVl24LVE3aIQ?=
 =?us-ascii?Q?pHPAyODG+jS2IFnwlOLvbkCoGGoX2a3qtSju+Gn6yR8foIj8d6SbpZQ0Valx?=
 =?us-ascii?Q?G0OF7d083jve7LB03rgtGYmmaeKRYuBGHXs+hE0k9b/FAsg/7CRIDrnDuF1G?=
 =?us-ascii?Q?gx5KIvxSnu2+DJTvQC/qXvp1NqESWhXQf9agJs94jBzC3ndX1X9t5RmFoGNZ?=
 =?us-ascii?Q?+IJOeoiTkV7n6W023ML39rXYhhoeVW4SYeAfS1fNJdcCoEcAXB+EfjIbeBnG?=
 =?us-ascii?Q?tqHaO+IjVaWE0Zkq31vLNW3n0WNO3Kd67QOQpgqS7FMvBKtzBC3cAoFhzptJ?=
 =?us-ascii?Q?p7IfOenkTxvvWfRRUI1D5y41iFH6Caak4Jzvq4Jq9yt5buaeFQQHbGKj0kMh?=
 =?us-ascii?Q?dbmmEqeSabgZOxr+G9Da802V9dg7IeTu/AsxnU/qWQ28Ny1FRov+l5AWNTg+?=
 =?us-ascii?Q?5tZmQGsOgHej9zeqOtx6MMdJYoJFqd1Mpp4bIEG96yPs+roxc9R18J++aCJV?=
 =?us-ascii?Q?Tt0GnEAkFesX78wkh0ucrXij+oTgwzn0x2pHYaZIYH35QBP4LU3VId65CqR4?=
 =?us-ascii?Q?Y9anxqBFrCe7PbrQ6CDtuXj7O/OoO3jI6elg8kDihgyLk+qrD7QLLWUogYvr?=
 =?us-ascii?Q?fQpWfn0DgN6txKfdhfKLHswEtls55gIF9dbNbEwpFE2teUVXD4pHRQPHn3+c?=
 =?us-ascii?Q?/Wa9sSLuV0qcP+FQku4DA3V/7SDhnxPIx8Qc28/AIVsqDfq7lqYCO2ptRGE4?=
 =?us-ascii?Q?7TbL75uIrgK8LdblPOgG/ZtIUsDXV5z6wFDYFcFwfS194KXKnd/kQB9VX2re?=
 =?us-ascii?Q?gsw0s3cuXWpwoLkTeBVNP2MHWIhYFgQS6LslvVrkJnBkfVc+4HREpHjwBUhq?=
 =?us-ascii?Q?cKSiHnbOBmf6EIxPDeMsZuR5zHLPbhGLVOg1v+HHCCxipVsuW8TdgYWp4N4P?=
 =?us-ascii?Q?z4O/75Tmoy59GX8frO9ksPYsm9uwaJRLSTbskzBS4padX//0vErTtYZ0DsqJ?=
 =?us-ascii?Q?Wur/+qTAhJHuJVD+d9YDHPxt7GehdHH4U+wdmCXymeIVOThyOBvgZBeZ5Bm7?=
 =?us-ascii?Q?60aK3WkP92kX0QzmM8U34CaPBaCnBSJbPQhXVU082oHs/8+trTTZFwkBzFmi?=
 =?us-ascii?Q?ZvemAX3L/GCM3bEF4dEvMS2oBgYLJQrGhsiSsD1E1VJ0VBp1vMc4MflIu/ie?=
 =?us-ascii?Q?EraCPM1XWNiniPbAIjQe9Fe/KeT9O0ADgXL3gs9Up1Qf/7wPtNopecH0Cf2T?=
 =?us-ascii?Q?rgdmHTlcpmpwvFogEJ4u3WtMHKt/SM84Cr+slCwCIwTGQMJRE1dPP2uE85jF?=
 =?us-ascii?Q?do8F58sK/O6HtmQ65s0fzSA7Sb/U4Cja+KQcdTDfNDXiX6/hya7OgOjHZeOf?=
 =?us-ascii?Q?tnMxoxk5AA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 45e6ca56-31ff-4682-4be0-08def70eaa60
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 18:39:09.4525
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nh03eeohrhTeOWSVYDkCxDfTFFFsnccC668bwvh8UmxPXNC5bW+Wb9gROGFqxYC3X0yTku7PRiLo+4IJWuYALQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11092
X-purgate-ID: tlsNG-16d1c6/1786387151-F440377B-99CEB5B5/0/0
X-purgate-type: clean
X-purgate-size: 2611

The allocated_irqs bitmap in the existing vGIC implementation stores eSPI
allocation bits immediately after the regular vIRQ bits.
vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index,
but vgic_free_virq() used the raw INTID.

Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit.
This writes beyond allocated_irqs and leaves the intended eSPI bit set.
Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind,
and during vPL011 teardown.

Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving
and freeing vIRQs. Validate a vIRQ before clearing its allocation bit.

Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Call is_espi() without a configuration guard.
---
 xen/arch/arm/vgic.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e5aca17dcb..c095866709 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -33,6 +33,14 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx)
     return idx;
 }
 
+static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq)
+{
+    if ( is_espi(virq) )
+        return espi_intid_to_idx(virq) + vgic_num_irqs(d);
+
+    return virq;
+}
+
 bool vgic_is_valid_line(struct domain *d, unsigned int virq)
 {
 #ifdef CONFIG_GICV3_ESPI
@@ -848,19 +856,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
 
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
-    unsigned int idx = virq;
-
     if ( !vgic_is_valid_line(d, virq) )
         return false;
 
-    if ( is_espi(virq) )
-    {
-        unsigned int num_regular_irqs = vgic_num_irqs(d);
-
-        idx = espi_intid_to_idx(virq) + num_regular_irqs;
-    }
-
-    return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs);
+    return !test_and_set_bit(virq_to_idx(d, virq),
+                             d->arch.vgic.allocated_irqs);
 }
 
 int vgic_allocate_virq(struct domain *d, bool spi)
@@ -897,7 +897,10 @@ int vgic_allocate_virq(struct domain *d, bool spi)
 
 void vgic_free_virq(struct domain *d, unsigned int virq)
 {
-    clear_bit(virq, d->arch.vgic.allocated_irqs);
+    if ( !vgic_is_valid_line(d, virq) )
+        return;
+
+    clear_bit(virq_to_idx(d, virq), d->arch.vgic.allocated_irqs);
 }
 
 unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 18:39:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 18:39:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387760.1629014 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUu7-0004ZL-JX; Mon, 10 Aug 2026 18:39:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387760.1629014; Mon, 10 Aug 2026 18:39:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtUu7-0004ZE-GA; Mon, 10 Aug 2026 18:39:19 +0000
Received: by outflank-mailman (input) for mailman id 1387760;
 Mon, 10 Aug 2026 18:39:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wtUu5-0004Wm-Ay
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:39:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtUu4-009VLW-Ne
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:39:16 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1ab0-e002-0a2a0a5209dd-0a2a4504df76-26
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:16 +0200
Received: from [52.101.84.111]
 (helo=DB3PR0202CU003.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a1ad4-b57f-0a2a45040019-3465546ff7a9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 20:39:16 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by GVXPR03MB11092.eurprd03.prod.outlook.com (2603:10a6:150:2a9::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 18:39:12 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 18:39:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DkkjgM1zCRqu84KKXeQQrMnc5lhcYnlJ4p3z1131szpuOdKEYi6rkveNK+IlHfSA0hUky+5knXpPgqYVoR292E4YBpcyxyhnb2L8R4zfdvgh2oSKzkN/0XuQ/ir2A/uBXT1h3nDQAMvV0wtOMXAimHssGbQKUPjfMijHho50pYl5zIi7bdFlbRr+OdciNxTuyv4NQwla4FIC6adSJWBtK1gA7QO7ElhfAw6secHtQYMMNpQa+KBZYSQEgWQyFAxzkkt5sN8cza07JxyQ6HU7Iyr1X99fD5jYckPmo8j6d79RkjwOwwsjQj2vfGhRloNn538gdIzDaut6FAOsvPWKww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rDjLrGD/FUY/UDHLWYqh7U+MOkaV3PZOYHp110xkPAI=;
 b=BpJCzoyNePC0uVUWau9rDGPqsTamiKrVEz5GCFr7hj7irCF3sAc4M0DhGORRK2OElJP4h0LrPaicmLZq2GfFGtXpTO+dAFeQX955eZciAAufl6coL/oiYOA4wfNZmi3kuyQinJGi2D3eZcdoEtb77a/FbrsqjdgXVYtzIfEophgrVDIGk25axuwtCvKRAtGWb2XpToK41woC8ieq/5fl9vsPvUgWfJ4/5ehzrhwWqwYPGc1LRd5RJLo0G6kUxVHpmGp3lRtoUWewEoIPa0XIgtLWormcygeKXMN8gFRdtBqhFopCDyxc1uMWYjW9EctV00Bl/84kdX7FSSJ/v9Xlew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rDjLrGD/FUY/UDHLWYqh7U+MOkaV3PZOYHp110xkPAI=;
 b=HW+3Ug3RRUhFXjtQp14lc3aASZPPbFsXMhkdvPWZRphZL6sHg4aoSGmqFGz0ek5R4tFLXPcMQpjLfOUah8MBok88SMHaMtGPfVxxRSLdo0eNbXTCaeL7g8W3tdHOB2+4imR6kI+8pPZaVzbEZgJ0E22Hjm1lQAQHGkY+fky3kEAtJjOLIOcDwIQrzn3UrHu3E4hv9qa+SXpZipIBdP1Rf2fGOb+yIAQi0dIJErIMdIsCjBS/6y4xNc8whW1ZLv4n2meEaFS5nJVfT+/AvkKiOUN7LcdEutPt3uzPCEpWJ5h8D4CWvz6gVU4XYUlXiGeTjoNNbATrarIH8UTqW4S7Xw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jens Wiklander <jenswi@kernel.org>
Subject: [PATCH v2 3/3] xen/arm: handle irq_set_type() failures
Date: Mon, 10 Aug 2026 21:38:47 +0300
Message-ID: <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1786385827.git.mykola_kvach@epam.com>
References: <cover.1786385827.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA2P291CA0003.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::7) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GVXPR03MB11092:EE_
X-MS-Office365-Filtering-Correlation-Id: 47e88541-b80d-49b4-e333-08def70eabd7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|7416014|366016|23010399003|18002099003|22082099003|11063799006|56012099006|6133799003|10067099003;
X-Microsoft-Antispam-Message-Info:
	uJMqOoXTb+FbCoY2yiaYePu95xHg/G0UW74CG6WUc2aW7rJuAKw97DeCbap2Zp3GkQK0Wxey1v1o415gRRHs1vshQOSsZy7K1LzdFx8r6GKoV7dEBLDGtiiZEA1g4r3xqbEdcOsMzlB9H1fNdidXC6dnZswPJQWGwDF/pcHr4ISAs9RUuWAUVBXSvENa6i7TwggttRj+ET0sKsWqONhlb2xFR/rkwOj/1GDwvQK3Km6CLpn64SDgYcvbbJpe45SYs/o8K1csG7CEobeCDW/vtCoalZ6WUm8DW61D3G716MaJ4E77lAOzjUgTriG+PiIgn45zSjXWY1wva5fsN2G0XZzkJj3aA3L4GgCkc9C+JELagDRlw6N2r2cNERZSX0qYUrQpjSO8Qm/1EFb04yYeEC2LM3uywDHHX1PBpm6XO2U/1j1QKj+y4TRrYlzw6RK/7TGrv1a4C382BstfTyhl58gz8rglZDuA0hyLsySmT2/EPzCk6wcA2SzG9Fk7wlhUZ6iFmbEsOxYpXaBEG389IJRyyf7hU7McjCfZAY5H8ZsYz/ABil9/C9959vWWQGw34543oje5TxPXl8wXpnO1uCs5FBte+EL4vWDt6L2axi8Vn0SQFyIOxIUSPWxLolDblYqUonJ4vpB8yxmGr7CsxGbxh9VIzW9jOjctb6MPWLI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(6133799003)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?l/FuCPR1KArHyj4uVex0HQRtYlHdgo5hmiefPb3gKIEPc2QS0QW+puYjsSkB?=
 =?us-ascii?Q?ZfAcwElNDPaW05kTb3TpVFWbFR8BAWGut/1UZPen6SuQPOy46W8ZPLbqLWFb?=
 =?us-ascii?Q?SncFTf6SdsxpcsqVliPIINfdCrIEMyY955wPdU/84y6U4ohwiNT7VFXQOU+1?=
 =?us-ascii?Q?sK9YS0KhxiBvoK4ROdet2u3PxyyrNitL9OEAJfVHffqTrI4GHYwPZfiHDJ6g?=
 =?us-ascii?Q?0aweKGxq988xOdbXWGRDF2ySQkLxavG1h9N7sxKygRW3vUU60OEWcp6M2o7C?=
 =?us-ascii?Q?JyYoWXb+iWUqj/l02if97He2c2zF7/qRcQphaW8fI/5DWCYXo8zV92OncaSy?=
 =?us-ascii?Q?qjLh40iwPbwOhPBuD6HtsEt/XL5CtjZ0ac54nstsUL1AsMSKwH5mg/lLwj8x?=
 =?us-ascii?Q?iJ9pUKgBgJdokHbtLV13CaRmJVzwxBuDAqiDULgNu/Rqel/mPwNKwNNv1VX5?=
 =?us-ascii?Q?zgw/4ACyZVEUF2JLE/TSVuShVFz3jpINMOJehVkM9OXLlxySjfWF5QtJb9y/?=
 =?us-ascii?Q?WCLx7tIAQbtSyR6aLugVqSejpq2t4pB9B12SsWfoQ4/WBtEnA+Ja4Y2qH+g9?=
 =?us-ascii?Q?uhvYdw7V6pGZYinGBq91Br2h5eXNQ30S43fNbwYxAAXYMsFB79oCuq5YxSYy?=
 =?us-ascii?Q?Mrux61rvSd82V1tdp+1CHkk2YroByItxBfU3bHGOkT8pLsuG2edmw31dxrzl?=
 =?us-ascii?Q?00Th7WwRcbFYsAUtt6YZsAJMzqiFegjj1Va/Rq5+htgc2RIheJIApwf9o7mI?=
 =?us-ascii?Q?S7laDTrgaDOLo3ZS/CTaSWJTchReAE8vhiJHmYFlR4GzHuKAIKgXywY4c1Tb?=
 =?us-ascii?Q?VgWTDxBLJNrhCSPqkOznEf6OAqlBC0qvdAWxKTZ0BBMSP+iGImbazhXgA4Gx?=
 =?us-ascii?Q?p5Zm7bkzPlERzdRf1qkruFb/RCYlTNGWRwqynSKKEKNRva802mvh3BtCHqRC?=
 =?us-ascii?Q?xId/nUhJeWXR5L8NDqQA7cWSaXZ4b1+d30C3byAHlu82+6l8RR2pVmp4TvSp?=
 =?us-ascii?Q?q9c9BXJFPi3GsZhsBlBlPZzd9i7ZHeJBE6DE75nGcMgRunXQW7EPak7cd09P?=
 =?us-ascii?Q?F/tZXdFzMuUiUHfCrARJbkTm0ugAkYdaSvZbmsQq5OLwOangndfavezcrN7v?=
 =?us-ascii?Q?mAzzaGH1ABD9wO52/nSkUhvddHWFK2jmouCU5+NCnSeNpInk49+R/g6A8rDN?=
 =?us-ascii?Q?KShV7qh2b93k+4D6PD78mT0LYsbxTeUaAZCb4D97rdRsVE5eplhGkQRJhm96?=
 =?us-ascii?Q?K6Tw61+pafnqLs9ubEh9t5ZcepqbGWOWs44VzzTyWkyIrwz2OAdxFbVFJnz8?=
 =?us-ascii?Q?ktNJPrCYR8kRV2zotFJbYqMN0nEsQEtXLdtA/rWg554EkuefUOMpnP6W9b9F?=
 =?us-ascii?Q?grxsb/788k7SGgKPmr6YDEf1HQdZyUDQRKIPp7u4cam63Vs9A0ASxQP9+dzQ?=
 =?us-ascii?Q?rdZCJGzaJyDDD41tHKBh/omb/hv0A3fVrX1lBXb65mVj5jEVgtEXbyYs/ilj?=
 =?us-ascii?Q?upsfXqfVUylqfhBBvjPqlF0yGNeL4FAQngiVZBYtNGGij8C9/oIsIYVgQPL7?=
 =?us-ascii?Q?ap/1O7royDgzg/K4aUO4KYHDtAlClhIlzwGG/TI+s2GKVouHp8FcbT1IA+YL?=
 =?us-ascii?Q?Setjv7t4pwTzzg44k/0nrDWNj7JMj95q9pf++fNMl4YpI/k0p0TcrYzaX3OT?=
 =?us-ascii?Q?TUpXase6qo3CYC/LipVPUYHCr+nvYpRjQyw9ikQoWYvKsZEG7UYhNPIVPq6F?=
 =?us-ascii?Q?tej3n00jrQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47e88541-b80d-49b4-e333-08def70eabd7
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 18:39:11.9409
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cP677HKJHG0aKoTZVTXUorLx2TcQ5bgwgAIZKBZBF5KZeFUk8saS1KugqqeO/mvbcLZP89NaYokt5OgWHFNvQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB11092
X-purgate-ID: tlsNG-ebf023/1786387156-502E4B50-C89FB731/0/0
X-purgate-type: clean
X-purgate-size: 7395

Several Arm firmware initialization paths discard irq_set_type()'s return
value, violating MISRA C Rule 17.7. If trigger configuration fails,
initialization continues with an IRQ that was not configured as requested.

Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store
timer INTIDs only after successful trigger configuration, make GTDT
parsing failure fatal, and stop UART or notification setup when trigger
configuration fails.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- new patch.
---
 xen/arch/arm/gic-v2.c        |  8 ++++++--
 xen/arch/arm/gic-v3.c        |  8 ++++++--
 xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++-
 xen/arch/arm/time.c          | 18 ++++++++++++++----
 xen/drivers/char/ns16550.c   |  5 ++++-
 xen/drivers/char/pl011.c     |  4 +++-
 6 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 43a379fdda..b8dcbb0bb4 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1157,6 +1157,7 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
                         const unsigned long end)
 {
     static int cpu_base_assigned = 0;
+    int rc;
     struct acpi_madt_generic_interrupt *processor =
                container_of(header, struct acpi_madt_generic_interrupt, header);
 
@@ -1173,9 +1174,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
         gicv2_info.maintenance_irq = processor->vgic_interrupt;
 
         if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
-            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
+            rc = irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
         else
-            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
+            rc = irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
+
+        if ( rc )
+            return rc;
 
         cpu_base_assigned = 1;
     }
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index acdac22953..d92d0b9b3c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1734,6 +1734,7 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
                         const unsigned long end)
 {
     static int cpu_base_assigned = 0;
+    int rc;
     struct acpi_madt_generic_interrupt *processor =
                container_of(header, struct acpi_madt_generic_interrupt, header);
 
@@ -1748,9 +1749,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
         gicv3_info.maintenance_irq = processor->vgic_interrupt;
 
         if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
-            irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
+            rc = irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
         else
-            irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
+            rc = irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
+
+        if ( rc )
+            return rc;
 
         cpu_base_assigned = 1;
     }
diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
index 186e726412..d08d0a3366 100644
--- a/xen/arch/arm/tee/ffa_notif.c
+++ b/xen/arch/arm/tee/ffa_notif.c
@@ -407,7 +407,16 @@ void ffa_notif_init(void)
         irq = resp.a2;
         notif_sri_irq = irq;
         if ( irq >= NR_GIC_SGI )
-            irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
+        {
+            ret = irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
+            if ( ret )
+            {
+                printk(XENLOG_ERR
+                       "ffa: irq_set_type irq %u failed: error %d\n",
+                       irq, ret);
+                return;
+            }
+        }
         ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
         if ( ret )
         {
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 6955b2788f..39b5eabe7c 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -60,20 +60,27 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header)
 {
     u32 irq_type;
     struct acpi_table_gtdt *gtdt;
+    int rc;
 
     gtdt = container_of(header, struct acpi_table_gtdt, header);
 
     /* Initialize all the generic timer IRQ variable from GTDT table */
     irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el1_flags);
-    irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
+    rc = irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
+    if ( rc )
+        return rc;
     timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
 
     irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags);
-    irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
+    rc = irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
+    if ( rc )
+        return rc;
     timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
 
     irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el2_flags);
-    irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
+    rc = irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
+    if ( rc )
+        return rc;
     timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
 
     return 0;
@@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header)
 
 static void __init preinit_acpi_xen_time(void)
 {
-    acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+    int rc = acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+
+    if ( rc )
+        panic("Timer: Failed to configure interrupts from GTDT: %d\n", rc);
 }
 #else
 static void __init preinit_acpi_xen_time(void) { }
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 120ac09d23..4bfdcfebd7 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data)
     struct acpi_table_header *table;
     struct acpi_table_spcr *spcr;
     acpi_status status;
+    int rc;
     /*
      * Same as the DT part.
      * Only support one UART on ARM which happen to be ns16550_com[0].
@@ -1976,7 +1977,9 @@ static int __init ns16550_acpi_uart_init(const void *data)
     uart->reg_width = spcr->serial_port.access_width;
 
     /* The trigger/polarity information is not available in spcr. */
-    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    if ( rc )
+        return rc;
     uart->irq = spcr->interrupt;
 
     uart->vuart.base_addr = uart->io_base;
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index a336241033..97c53c11e0 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -363,7 +363,9 @@ static int __init pl011_acpi_uart_init(const void *data)
             spcr->interface_type == ACPI_DBG2_SBSA_32);
 
     /* trigger/polarity information is not available in spcr */
-    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    res = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    if ( res )
+        return res;
 
     /* TODO - mmio32 proper handling (for now set to true) */
     res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 18:54:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 18:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387795.1629023 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtV8m-0008Lm-W6; Mon, 10 Aug 2026 18:54:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387795.1629023; Mon, 10 Aug 2026 18:54:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtV8m-0008Lf-Sp; Mon, 10 Aug 2026 18:54:28 +0000
Received: by outflank-mailman (input) for mailman id 1387795;
 Mon, 10 Aug 2026 18:54:28 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtV8j-0008Jz-QT
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 18:54:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtV8i-006mZJ-45; Mon, 10 Aug 2026 20:54:25 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7a1e2f-2eae-0a2a0a5409dd-0a2a4504ce24-42
 for <multiple-recipients>; Mon, 10 Aug 2026 20:54:22 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7a1e5e-b57f-0a2a45040019-5a9b3222d564-3
 for <multiple-recipients>; Mon, 10 Aug 2026 20:54:22 +0200
Received: from [2001:8b0:10b:5:9f69:702f:982f:3898]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtUc3-0000000HG3k-3AYW; Mon, 10 Aug 2026 18:20:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=cwmsDUvt8rJ15tvz82X30tj2Exxw0lajDzdZAkLIrAo=; b=eB4pQRc/oCxq/k9xhP6fE1X/5+
	cgCU26qjDrGKMsdjHFbFx8Y05WqwAnQ9IDdjtT/FFNkzLU1iFmsTDvykvNtHt5nivfyCDCuwbBGX5
	ru3glCtl65dgFhVpwyB4+LB5CZ8DeCzMrmbnDfivx5Har0wm5brKX039nvd0M65AXty7HLA+wGelj
	njwFnoI1i3iqlb21T3XV7n6NkiZkE5eggnnUzaji7ktHivc2jgXp4ke3nl3GqkvSeQLivJRUDTtxy
	0wwUmMFlbVPF3p5gBYCiSKJOeCn8wXbRTpgTfwYnuKtOr3GFGFQ96XSZaV9/DrWwUVK/EZVGKjfkx
	s7qeRcTA==;
Message-ID: <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Mon, 10 Aug 2026 19:20:05 +0100
In-Reply-To: <anoOz2rZ02KFk1l-@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-18-dwmw2@infradead.org>
	 <anoOz2rZ02KFk1l-@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-7RnCnZ41sxGpJ6+i13Fq"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-ebf023/1786388062-583C0B50-F1049238/0/0
X-purgate-type: clean
X-purgate-size: 10684


--=-7RnCnZ41sxGpJ6+i13Fq
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2026-08-10 at 10:47 -0700, Sean Christopherson wrote:
> =C2=A0
> > But when the vCPUs merely have a different TSC *offset*, that's not a
> > problem. The offset is applied to that vCPU's kvmclock->tsc_timestamp
> > field, and it all comes out in the wash.
>=20
> It's not though?=C2=A0 The value stored in kvmclock->tsc_timestamp is per=
-VM, not
> per-vCPU, when using the master clock.=C2=A0 It's a little easier to see =
once the
> master clock TSC isn't shoved into host_tsc:
>=20
> 	do {
> 		seq =3D read_seqcount_begin(&ka->pvclock_sc);
> 		use_master_clock =3D ka->use_master_clock;
> 		if (!use_master_clock)
> 			continue;
>=20
> 		if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) {
> 			use_master_clock =3D false;
> 			continue;
> 		}
>=20
> 		master_tsc =3D ka->master_cycle_now;
> 		master_ns =3D ka->master_kernel_ns;
> 	} while (read_seqcount_retry(&ka->pvclock_sc, seq));
>=20
> 	...
>=20
> 	if (use_master_clock) {
> 		hv_clock.tsc_timestamp =3D kvm_read_l1_tsc(v, master_tsc);
> 		hv_clock.system_time =3D master_ns + v->kvm->arch.kvmclock_offset;
> 	} else {
> 		hv_clock.tsc_timestamp =3D tsc_timestamp;
> 		hv_clock.system_time =3D kernel_ns + v->kvm->arch.kvmclock_offset;
> 	}

Meh. I shall have to build a better test case for that one. Thanks.

> To allow different offsets, KVM would need to track a per-vCPU offset to =
the
> master clock and apply that in kvm_guest_time_update() (and maybe other p=
laces?).
> Which is doable, but it's not clear to me why we'd want to support that (=
though
> I haven't fully processed the back half ot his series, so it's very possi=
ble I'm
> missing something obvious).

Because I want to reduce the number of cases where we have to fall back
to non-masterclock mode. Especially the ones which are driven by
*guests* rather than weird choices on the VMM's part.

--=-7RnCnZ41sxGpJ6+i13Fq
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTAxODIwMDVaMC8GCSqGSIb3DQEJBDEiBCDNNAvUs4bOWURrMm2gI30pevwjgws9
iGSh4bXQkoHAXzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIANkNVVbaDFxCGWy2OB065QXS3lk9J2cw936gZgSo0+U/JcyPd+tiB
sX4N+CaocB9IWyKVXVo5SuE3ayvUFqEURzF1YyJwLO0SNyDaxfZkAix6g70Mm3O3oXXuc1+h477p
XQW1NokP1IfBDFPREuPsHblsJCuQQ6FXbYRWSo/FETBNQSlfFrLsvTWWGFtrc0YfuX0vVDCebGH3
7KFDcSx+xwEQ+ZefIPJUTKJ0BEHMd1JQwCbUSYXcIQ6rrzDa+X1OKgcalXfRlC+HXcqrTtEurfjn
VDQMkL0+olbXA9aPBk11Y8EYZ+OMi8WHZLDOdXJmx6oQ0r326XVswAeNuQgZwJxagyA+7XaZ39c8
YrJQLhTGmUraPUOWZJzcWop0aGycS0bSZMq716yjU2Hl3AycP1omssaTWzWzN7NeOW4aI0hdRfEg
Ow+R3Fgo6sWwDkZgSTM0RR7CzrI189q6GLpFPgylNcDUn9LmEputc8MmGB2I/nzsX/pDjQj4lxmS
aA2ybYxgiRcYhFohjVKHB2i+581+g/U1BFP612t4qaHHqmDlJR/JvkS4uOrC6j89m5TfGyhgch0r
VAgeu6HeDeIsGafcUi+QCpJNLMZDoeGuLDIf6VapDqxOz3wFPdnGsTOiu829Hc4uABxuEqINWXdb
WaTyt81hdhO+LXuL6aNMz+4AAAAAAAA=


--=-7RnCnZ41sxGpJ6+i13Fq--


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 19:42:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 19:42:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387809.1629032 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtVso-0007so-Bu; Mon, 10 Aug 2026 19:42:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387809.1629032; Mon, 10 Aug 2026 19:42:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtVso-0007sh-8z; Mon, 10 Aug 2026 19:42:02 +0000
Received: by outflank-mailman (input) for mailman id 1387809;
 Mon, 10 Aug 2026 19:42:01 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wtVsn-0007sb-Jh
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 19:42:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtVsm-000bnd-EF
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 21:42:00 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a2982-8faa-0a2a0a5109dd-0a2a45049c04-6
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 21:42:00 +0200
Received: from [52.101.70.87]
 (helo=AS8PR04CU009.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a2988-b57f-0a2a45040019-3465465768d9-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 21:42:00 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6901.eurprd03.prod.outlook.com (2603:10a6:20b:29e::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 19:41:55 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 19:41:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DyRoJ0slfhLhBnD/C01HVwB1Amckmscdtnld0bBqdZUPM4Jd/NOsk6Mx0/mDCe3OaYtxwzYVM4oZ9wK4sEInPdcqLNyv0Grt2ixgF52mCW2Kfcen1ZMXNLqStoIsCvC6vMhldIsu6OAqKnhXlpHHTqlFx+7KJ1Pg4N5/EPxyL65dTBnirMPFglCf6j0wWiTGCif1RAQgbjbL0sf+d2THxCSqkxPrflXOMv2Fyc6adR5NynZ60pYKn2yNKcNhmkvxscLXiRhnmYH2sHVB03wjatg5cif2IszxfA8tU5ghma57QonxSPeHOTOaNdhlhwlehYy2eIWLRDKBNjdTFcAJxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LP5CLyeqsdAsHC0O/sJbyotX1Vuz1Ex1qdpiNH22STg=;
 b=Y+YbO3f/VE15piHY6niaa4TTfTNdGvOInKLunk9Uj8mmkjYTIrub2o5U693SY/pLoj4S3pp9sIjlV48n1a/qP0WFLM7/OkA+YbSzvqk/4P/7I2ITkRZgZEA5wqF3FfM2Sd+Rlt78HJRHEwuV2HZhmMNMcKPnv+ftpeFTW7gxALEHGFhrgZc+AY+lZxBgSxqayZW9mOf0FCFrB8G7cp9hp61vARd6n6woNDNGkVg78UwcJ5oWtOQ/IDH0Zg+89I9tz6wQF5c1y70CVqNM0N8So7JCs/23LAWJUjFZVTBnv2kJXNM696a9mMflAta1hK1UU3YpkyqkYIfNCyPOCPWNRw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LP5CLyeqsdAsHC0O/sJbyotX1Vuz1Ex1qdpiNH22STg=;
 b=Zj1FrnnlqpW+C51VCWKJqpdFY3PrLNsi6DFRur7EPRh8O9+F8nc8kj9GjzbyW2iiiTN9cUC61KdwZF6PAnp0uQLANuxKR9d1OCbUfsfWPbdBVCcaEsTDHp8CFIZ0brU4FLTL0pX9qbBQObH78U2mL6wIWIGEFSoJJ/Naj0ezp8w5UZF6vSSmJi6xcXFg41H/fTZE+CW+vAEH6D/HXxWKbJDHKrDher6Nq+zsufw6C5lmEUMnzLDX4iqc3Im9uGlyDAtiKvpJ1mpOcxSKISNMfFx35Eb0eO29Al5Ra2UEJGvhSLUCM2DNnjCOChmeDu4saaSJaeD5D5x3XPGfy0bOcQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2] xen/arm: propagate secondary GIC initialization failures
Date: Mon, 10 Aug 2026 22:41:46 +0300
Message-ID: <58b886c992ea72210bb2f32afc392b458efe02f2.1786389451.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0016.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::28) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6901:EE_
X-MS-Office365-Filtering-Correlation-Id: d2149e82-dcc5-4920-b7b8-08def7176ef9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|56012099006|10067099003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	XDEoBbYfVDE92b4IKB+Y6ZvhzR5ZFgDwzgQ31TFj+4sP95qhZ02ngzxbGwgAhTMDdDYOw2liFHRlicM++P1xkFRcBIukMhsjiiOvBIGjX19RqA+bwnGEVHfRR21ksFFgPsRfCb0ton+1W6fIpNz4xZ90zIPe3NKs6YNaFTxNefddbL0mZZaLVxQRO/fOtcJxpjF6twTMEG9m7Zpg4oLOkyB8Lt70oFyoYIo9b7rEF0SCHMS1hpkE2igy9xmKnLmv+3HnsVQa6yfFEVIA+xTvKIeCr0/BipA0epgCx6NvfVpT+2jVgQZk5zt4v2bb4NvelL5MhrqBoHcoYnek/ol0Ja17vOEQe6CHQqq5WEm5WKUufp0U/bXBwe2q6NI/9hpJAB6qYomx1uHFnZaS/lawb8jSHooLdF7NKyNOVc0fRftW5meFaS6GY2ETRZt1GDmXX4WTN4AxrqTT9HWUDuKcCeH0SkMSFWZPS/+I3fD4vyi2n7Q8AKAUpEfIlW5gzM1Bq0YwXUgzd2y7xV4YUmnNzFM39tRFsU72USHZv5ZCDxC2F1jcIpK6rpo5u9yvcCEtndgkSCYhcYnhB3MeOrMPhEv2q4ty6hqe/jaty4GXjk4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(56012099006)(10067099003)(11063799006)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?S4/HplGdZu1sGamQb3PJAAuKXHwm7XuPrJb8miFEejizCZzZjpejMp4D2x8g?=
 =?us-ascii?Q?V9zgAx9tD+ZuoGSTNdepK4P/nyeQvrCoSW/beD/OuUd1Y5BzsJfoYfCd2Cgg?=
 =?us-ascii?Q?xbl+5vaE4SE2UmFZp4E6folsQnPWozQ4ZK3fx9eSbtbeHqEJW37j3k0ozTMQ?=
 =?us-ascii?Q?5851IIkKZciWeOAPG9Js6/rjTcs0s7xchX13dAyI+ZsMalbOVxtq2FHextdM?=
 =?us-ascii?Q?F3jmIdt3yaCSNJ3LrrrxSx7rcN4y41AsZYd7ErvVpA25e1ViknLHKHprGoQO?=
 =?us-ascii?Q?e39igN6uzPeF5UYE/0jUleCP1OOYByTB8hL2vKxMnspxJ339QjPiiZA3cZYZ?=
 =?us-ascii?Q?zbIPmBuB3KtF38KtAjVSHKtjm6C8r96OL/xL8DPvpTgFwxNP40yi0saXwIf/?=
 =?us-ascii?Q?KVdCFrRzYsRh9omp2O7mXNyk7GZWOY8HEj+q5k9yhuv1oPLAS6B+exVs4mw/?=
 =?us-ascii?Q?Pt0/Su9fkwIZbK3gtOOHWLvCvKQlS+VgpCU6pton1rDKwhvYm89lZWHz7O48?=
 =?us-ascii?Q?23EGf2jVepojj6R5gzgvXD+K0npkb/vkr+pgPp3T/zBqjSkCs6By6D2gHE2R?=
 =?us-ascii?Q?cdqDdqYtq97/fefuI9DAxjH46uG7VLXjov3uuUeVOCLHq359ityJNfU5GipC?=
 =?us-ascii?Q?AL0MknKs3Bbm0ot+hDhtU7F3ePXuzMXdKSwMzPGQ716MIq9iJVZjWQabscSP?=
 =?us-ascii?Q?uTiStnw8B4dpWgbAMOVZT16PPqBlvnvYvtVsc+CdQVRalB7LIRDWZpPX/rmo?=
 =?us-ascii?Q?uKXCPnELeKzYzVhJH/9WKrs8rCoqrPXdqoQSA3a+KYAGSohxTTjGr06IIiHZ?=
 =?us-ascii?Q?/l66EG0Kzz4mRBymZ6+dgyBihCx/aV1pRqWw4hy8066gtvoW6gw6Js8oGTDy?=
 =?us-ascii?Q?Ao/Ry39K2OZsCxAuTDulC4F/bbyLOx5Q+p766z8B4mPRgnQZM+TWEPPrUKRz?=
 =?us-ascii?Q?Yk6xvrjFfPpmZRxRGXlhVqsfBGceV5hO5kESlv7VgofADtypR5O2bH7SUTUC?=
 =?us-ascii?Q?ZO66wZueEFMA5T89tKBuSLcKBp41pMfDKQw2mWVS9ICG2lSiqiJ68ICmshng?=
 =?us-ascii?Q?8WIWK9BypMQp8qTPef4hTKVPJCzcfP4O/UGSMW39DQUfdc/6fHCTEGjZl+3Z?=
 =?us-ascii?Q?B/sYoPQ8DpLaQ98nHusUt7aM1ws/Jgfsp6HlFI4iqHmdjuvMH5vwdm2XH5hi?=
 =?us-ascii?Q?oc48QSNwisPKeEmsjDP8g0UMSkz1m4HAU0nZExP0g5CuzHMi2acWh9MU+9Zc?=
 =?us-ascii?Q?OsyuDumJPKoPtGik/uRZAGd8IIQXALRaAuRAJbKbmf0ecKuJn69vxKoExR89?=
 =?us-ascii?Q?dzMnlNlLKfg1ixaghzPvN+fhgLfm0TdTE+pIIzMuus09iHs97l+HbN9S6olu?=
 =?us-ascii?Q?0m97tRxpmQUFxE8la5beiVQTUi3BpSVc9gYKRuQbdD/2b3HTqT/eFOmzCmuH?=
 =?us-ascii?Q?GjZUOTlJYE8EubawQp1wiY0YcTnVM75zfUaLQp1QaqpaJO3q8brsndneNT3r?=
 =?us-ascii?Q?1xPgpp8Z5IqStbwyAgOrB0sgZ3+10pOUU3g3RQ4SbzPReRXt1GEK4ZDGuRN2?=
 =?us-ascii?Q?QyRnlun2bhC3fwUF3nVP3YxWhZvBV0MrwMKVEpMLV3IERcI0XzNXe3pebCpC?=
 =?us-ascii?Q?L/cfu9xAKKSF2KMtB2vX1WlEkVTpeHOa6olzbrxiQneTB1DpZFXpRp5vBkgV?=
 =?us-ascii?Q?FEDDpqaBqk8RQFeO1EURMdx72NXFczOktvDz7P/mq0llAsyCb4ZGIQxlIfBf?=
 =?us-ascii?Q?PC3eME5o9A=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2149e82-dcc5-4920-b7b8-08def7176ef9
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 19:41:55.4162
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: J3yhIAX6o/AGyXFQALfeUEiqxSQEQ6oCLWk/ScN11Di0zr1N2IY9I889xEi1UEYPTBlDBbTXXeOjWZ1qeB8HlA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6901
X-purgate-ID: tlsNG-ebf023/1786390920-C24CBB50-6216521B/0/0
X-purgate-type: clean
X-purgate-size: 3453

The GICv3 secondary_init() callback can fail while discovering or
waking a Redistributor, enabling LPIs, or setting up an ITS collection.
gic_init_secondary_cpu() currently discards that status. start_secondary()
then marks the CPU online even though its per-CPU GIC interface may be
unusable.

Return the callback status through the common GIC layer. Have
start_secondary() report the failure and stop the affected CPU before it
updates system features or is added to cpu_online_map.

Fixes: bc183a0235e0 ("xen/arm: Add support for GIC v3")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Move secondary GIC initialization before updating system features.
- Use smp_processor_id() in the failure message.
- Target master instead of the 4.22 release.

v1: https://patchew.org/Xen/9fd0d0eacf061cc2a32f440e3438c084fa9ca79c.1783678619.git.mykola._5Fkvach@epam.com/
---
 xen/arch/arm/gic.c             | 10 ++++++++--
 xen/arch/arm/include/asm/gic.h |  2 +-
 xen/arch/arm/smpboot.c         | 11 +++++++++--
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ee75258fc3..078049e741 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -282,11 +282,17 @@ void smp_send_state_dump(unsigned int cpu)
 }
 
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
-void gic_init_secondary_cpu(void)
+int gic_init_secondary_cpu(void)
 {
-    gic_hw_ops->secondary_init();
+    int rc = gic_hw_ops->secondary_init();
+
+    if ( rc )
+        return rc;
+
     /* Clear LR mask for secondary cpus */
     clear_cpu_lr_mask();
+
+    return 0;
 }
 
 /* Shut down the per-CPU GIC interface */
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h
index ff22dea40d..ee2c26adb4 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -291,7 +291,7 @@ extern void gic_preinit(void);
 /* Bring up the interrupt controller, and report # cpus attached */
 extern void gic_init(void);
 /* Bring up a secondary CPU's per-CPU GIC interface */
-extern void gic_init_secondary_cpu(void);
+extern int gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
 extern void gic_disable_cpu(void);
 /* setup the gic virtual interface for a guest */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index ba5fd2dd52..1806c47a08 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -319,6 +319,7 @@ smp_prepare_cpus(void)
 void asmlinkage noreturn start_secondary(void)
 {
     unsigned int cpuid = init_data.cpuid;
+    int rc;
 
     memset(get_cpu_info(), 0, sizeof (struct cpu_info));
 
@@ -366,6 +367,14 @@ void asmlinkage noreturn start_secondary(void)
         stop_cpu();
     }
 
+    rc = gic_init_secondary_cpu();
+    if ( rc )
+    {
+        printk(XENLOG_ERR "CPU%u: Failed to initialize the GIC: %d\n",
+               smp_processor_id(), rc);
+        stop_cpu();
+    }
+
     /*
      * system features must be updated only if we do not stop the core or
      * we might disable features due to a non used core (for example when
@@ -373,8 +382,6 @@ void asmlinkage noreturn start_secondary(void)
      */
     update_system_features(&current_cpu_data);
 
-    gic_init_secondary_cpu();
-
     set_current(idle_vcpu[cpuid]);
 
     /* Run local notifiers */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:03:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387819.1629040 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWDF-0003Qt-Vm; Mon, 10 Aug 2026 20:03:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387819.1629040; Mon, 10 Aug 2026 20:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWDF-0003Qm-T9; Mon, 10 Aug 2026 20:03:09 +0000
Received: by outflank-mailman (input) for mailman id 1387819;
 Mon, 10 Aug 2026 20:03:08 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWDE-0003Qg-Ag
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:03:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWDD-000dtK-7Q
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:03:07 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a2e67-2eae-0a2a0a5409dd-0a2a4506a89c-48
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:03:07 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a2e79-195a-0a2a45060019-ac6904fe8b2a-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:03:06 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 1DD11600AD;
 Mon, 10 Aug 2026 20:03:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4920C1F000E9;
 Mon, 10 Aug 2026 20:03:03 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786392184;
	bh=TsswkiVvDPxgcSHZ6yjKKlKm7CgWPEsFg9F0slygfJ8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=lhjkEgVxoW2Qd2naeLDMVfkx7Dnk7Bo7N9Zy1pRcrJi0+YG3uo7Tj2ZZJ5NuJzZEP
	 xCxqQCv7kNqUGUsi7h7mj5ciZ0k6Zs3fVelCiadtWsI0lBJD8EUhFNnWRNwBSuy84b
	 05e2sNDMveWm8LJupQpJ90Vdvr5Yuxn+hqtnW4cV2xTtuz1uNzT6XS4IQHg6lRN37T
	 vuVpJzF0G46LzxG20mh3+P1LcsUyDvOSrxepS8cOzN9sLGyGYNEHMQ9Bt3BJoijkc7
	 7+Q0Y/MVuabkrIaEi4N1EkOad2rSBSKgXZrzt829sDW0wJU69PFI8PTozn/gGCwep/
	 HUElcwCpOoq5A==
Date: Mon, 10 Aug 2026 13:03:02 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 1/7] xen/console: do not use XENCONS_RING_IDX in
 console_init_ring()
In-Reply-To: <20260728065049.1318143-2-dmukhin@ford.com>
Message-ID: <ff4ae51b-858d-4822-217b-bfc7e9bc6e2c@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-2-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-16d1c6/1786392186-F520877B-78F43C6A/0/0
X-purgate-type: clean
X-purgate-size: 1623

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Replace XENCONS_RING_IDX with unsigned int for the console ring indices,
> as the console ring is not a Xen console (XENCONS) ring.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> Changes since v7:
> - new patch
> ---
>  xen/drivers/char/console.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index ea4e3ff34178..37fdda93a4c1 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -463,7 +463,7 @@ static void cf_check conring_dump_keyhandler(unsigned char key)
>  void __init console_init_ring(void)
>  {
>      char *ring;
> -    XENCONS_RING_IDX done, size, n;
> +    unsigned int done, size, n;
>      unsigned int order, memflags;
>      unsigned long flags;
>  
> @@ -484,8 +484,8 @@ void __init console_init_ring(void)
>      size = conringp - conringc;
>      for ( done = 0; done < size; done += n )
>      {
> -        XENCONS_RING_IDX src = (conringc + done) & (conring_size - 1);
> -        XENCONS_RING_IDX dst = (conringc + done) & (opt_conring_size - 1);
> +        unsigned int src = (conringc + done) & (conring_size - 1);
> +        unsigned int dst = (conringc + done) & (opt_conring_size - 1);
>  
>          n = min(opt_conring_size - dst, conring_size - src);
>          n = min(size - done, n);
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:05:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387827.1629049 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWFD-00042C-CY; Mon, 10 Aug 2026 20:05:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387827.1629049; Mon, 10 Aug 2026 20:05:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWFD-000425-9y; Mon, 10 Aug 2026 20:05:11 +0000
Received: by outflank-mailman (input) for mailman id 1387827;
 Mon, 10 Aug 2026 20:05:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWFB-00041v-GP
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:05:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWFA-00FQ90-HW
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:05:08 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a2ef2-bab6-0a2a0a5309dd-0a2a4502e08a-6
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:05:08 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a2ef2-6ca4-0a2a45020019-aceafc1fa41c-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:05:08 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 2716C4359C;
 Mon, 10 Aug 2026 20:05:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59B371F000E9;
 Mon, 10 Aug 2026 20:05:04 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786392306;
	bh=gPnvIhkRdHJGclEh1u0eMnzRQFbglbdwmyBABLRGU7s=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=Ey8QtfK6dSAyGrkb0bImOKnm+SsjeqDG/E7sd+lC0Nq0xabrz/G7oxO+4SH7ZKqJZ
	 b/aXjTNYHO2spAziyjTvCzqr6xKLnvO2XqAK7QxHwhQw8N0UfTxtJr9ud+/Hu4jDxy
	 JZqU22qobir96gZDtFajaHmVgKLJRPkxNXbV+As7t+q9sCHM9/SKf3cIY8pbDUDoDB
	 Z+H4/KC3AEN0HWebMl347Nmdw1vsJj2ufFqXvPcAscJTq+1mwGsEYedotXjqqaVlAN
	 IH4as/xrLy/pg1W9+a6BZH0g8UKUxNW47pFGRIbOsy6PSZSCDOniC/7+M3XEhxrpGY
	 iZNtJHONTj8HA==
Date: Mon, 10 Aug 2026 13:05:03 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 2/7] xen/console: use 'unsigned int' in
 contring_{flush,puts}()
In-Reply-To: <20260728065049.1318143-3-dmukhin@ford.com>
Message-ID: <ce54345e-33b6-5d7d-9b79-0229c1254a3d@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-3-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-720697/1786392308-660A82AC-B355065F/0/0
X-purgate-type: clean
X-purgate-size: 1348

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> contring_puts() and conring_flush() still use 'uint32_t' to access
> indices.
> 
> Switch to 'unsigned int' to as required by CODING_STYLE.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> ---
> Changes since v7:
> - new patch
> ---
>  xen/drivers/char/console.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 37fdda93a4c1..40355c1d14d6 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -375,7 +375,7 @@ static void conring_puts(const char *str, size_t len)
>  long read_console_ring(struct xen_sysctl_readconsole *op)
>  {
>      XEN_GUEST_HANDLE_PARAM(char) str;
> -    uint32_t idx, len, max, sofar, c, p;
> +    unsigned int idx, len, max, sofar, c, p;
>  
>      str   = guest_handle_cast(op->buffer, char),
>      max   = op->count;
> @@ -421,7 +421,7 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
>   */
>  static int conring_flush(unsigned int flags)
>  {
> -    uint32_t idx, len, sofar, c;
> +    unsigned int idx, len, sofar, c;
>      unsigned int order;
>      char *buf;
>  
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:19:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:19:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387836.1629059 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWTF-0006AN-IV; Mon, 10 Aug 2026 20:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387836.1629059; Mon, 10 Aug 2026 20:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWTF-0006AG-Fo; Mon, 10 Aug 2026 20:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1387836;
 Mon, 10 Aug 2026 20:19:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWTD-0006AA-Fi
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:19:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWTC-009fhM-CK
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:19:38 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a325a-8faa-0a2a0a5109dd-0a2a4503bbc4-0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:19:38 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a3259-fae8-0a2a45030019-ac6904fe8354-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:19:38 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 71016600AD;
 Mon, 10 Aug 2026 20:19:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8558F1F000E9;
 Mon, 10 Aug 2026 20:19:34 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786393176;
	bh=EwYj3j/RNOT5w84VixrvYZJ6FaxcWeo4bmm2TSRUaeY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=oj19ParByyAD4WD3xnzZWFAzjhcSyUXXhqsbH5aMgKr/6XO4IkZjuYxYpiqfRbAw4
	 U5W6QncYdRiQ9RT4PatuhMKBtc2zyyeo/SLieBauiOUaH3mR2JAwN/94m6m8VjnWtN
	 vTkzt3TbWiz+w0mkMomtVi7kiJfN1V45yEVOwT7SGiJxXzNDbk/+btm9nEhRp/42pN
	 9lMvdt0eeWA5OTaqv/n7p6ecUuH5mrO+M8vTyFJF31lVaZr8SpHSK2v1Nke2Uu5PtT
	 Lq28kOnO5KwWr2v66tqrUOl2WwKq/bjltk54qEUvh7ylTie3t8Wv5f03wUqiYI2VYJ
	 E1jZ9WtOY9N9Q==
Date: Mon, 10 Aug 2026 13:19:32 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 3/7] xen/console: switch conring runtime allocation
 to xvmalloc
In-Reply-To: <20260728065049.1318143-4-dmukhin@ford.com>
Message-ID: <59a85064-35d9-c3f5-c056-6c05677fc27a@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-4-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-33051d/1786393178-768FA4E9-58A5BD5C/0/0
X-purgate-type: clean
X-purgate-size: 3554

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> The console ring only needs to be virtually contiguous; it does not need
> a naturally aligned or physically contiguous allocation. Replace the
> runtime xenheap allocation in console_init_ring() with an xvmalloc-backed
> buffer.
> 
> Also clamp the user-configured ring size to the supported range and emit
> warning when the requested size is adjusted.
> 
> Drop full stops in all diagnostic messages in console_init_ring() to align
> code with the common code pattern.
> 
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

There is another alloc_xenheap_pages in the same file, in conring_flush.
It would probably need to be changed as well.

> ---
> Changes since v7:
> - Jan's feedback from
>   https://lore.kernel.org/xen-devel/0fefa50c-46aa-4ede-a8e2-8c2c619bc2ab@suse.com/
> ---
>  xen/drivers/char/console.c | 27 +++++++++++++++++++--------
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 40355c1d14d6..09282a7a4f8e 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,6 +33,7 @@
>  #include <asm/setup.h>
>  #include <xen/sections.h>
>  #include <xen/consoled.h>
> +#include <xen/xvmalloc.h>
>  
>  #ifdef CONFIG_X86
>  #include <asm/guest.h>
> @@ -464,20 +465,30 @@ void __init console_init_ring(void)
>  {
>      char *ring;
>      unsigned int done, size, n;
> -    unsigned int order, memflags;
>      unsigned long flags;
>  
>      if ( !opt_conring_size )
>          return;
>  
> -    order = get_order_from_bytes(max(opt_conring_size, conring_size));
> -    memflags = MEMF_bits(crashinfo_maxaddr_bits);

The original code had MEMF_bits(crashinfo_maxaddr_bits).
crashinfo_maxaddr_bits is 64-bit by default but can be changed via
command line options. Now, the memflags is going away and there is no
way to bring it back because xvmalloc_array doesn't take memflags as a
parameter.

Andrew, Jan, is that OK?


> -    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
> +    if ( opt_conring_size < GB(2) )
>      {
> -        BUG_ON(order == 0);
> -        order--;
> +        unsigned int order = get_order_from_bytes(max(opt_conring_size,
> +                                                      conring_size));
> +
> +        opt_conring_size = PAGE_SIZE << order;
> +    }
> +    else
> +    {
> +        printk(XENLOG_WARNING
> +               "Limiting user-configured console ring size to 2 GiB\n");
> +        opt_conring_size = GB(2);
> +    }
> +
> +    while ( (ring = xvmalloc_array(char, opt_conring_size)) == NULL )

It looks like that if opt_conring_size is zero, then xvmalloc_array
would return ZERO_BLOCK_PTR which is != NULL. We need to have a
different check here for that condition


> +    {
> +        BUG_ON(opt_conring_size == 0);
> +        opt_conring_size >>= 1;
>      }
> -    opt_conring_size = PAGE_SIZE << order;
>  
>      nrspin_lock_irqsave(&console_lock, flags);
>  
> @@ -498,7 +509,7 @@ void __init console_init_ring(void)
>      conring_size = opt_conring_size;
>      nrspin_unlock_irqrestore(&console_lock, flags);
>  
> -    printk("Allocated console ring of %u KiB.\n", opt_conring_size >> 10);
> +    printk("Allocated console ring of %u KiB\n", opt_conring_size >> 10);
>  }
>  
>  /*
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:22:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:22:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387843.1629069 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWVa-0007eA-V1; Mon, 10 Aug 2026 20:22:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387843.1629069; Mon, 10 Aug 2026 20: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWVa-0007e3-RB; Mon, 10 Aug 2026 20:22:06 +0000
Received: by outflank-mailman (input) for mailman id 1387843;
 Mon, 10 Aug 2026 20:22:06 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWVa-0007dv-8M
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:22:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWVZ-00FSC8-Cp
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:22:05 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a32c4-e002-0a2a0a5209dd-0a2a450c8e64-36
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:22:05 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a32eb-f479-0a2a450c0019-aceafc1febde-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:22:04 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id E5C3241525;
 Mon, 10 Aug 2026 20:22:02 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1EFC51F000E9;
 Mon, 10 Aug 2026 20:22:00 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786393322;
	bh=TLEf/DOe2uG4L9xiUXANB+Tqddoo5pXA7QKWB02G6Tk=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=lZ0ldktqSfXjFLQ/ohcHyrfS4H5nKI6fWUiwzDUPXsKhQ7NNpEqwPpqwgfALRfTxU
	 Q0KfYqidIN7+CNyn55JMHxI1AwOGWcXgL2xFoQfFHiCSEMTjGqKfFADjFXFUnHVXIb
	 oYsYIOp+epcZABd06xYVUoJfxwpG7cIgutnZerqdVo081uUJJv1qbR9dWdsz31xnFo
	 F/gCZBg5RaD9Zjr76j5B2PBQoDII324WUuJpNTkVTD2jyYUzISQkOpU14aCte68y1l
	 KcblV5RXQqmaO5h355P8iMcSFWsqGMxOuEvV/51h1jc6LLrbThbo2tbaW0MoODD4NT
	 ZAoTk+1BBahpg==
Date: Mon, 10 Aug 2026 13:22:00 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 4/7] xen/serial: switch txbuf runtime allocation to
 xvmalloc
In-Reply-To: <20260728065049.1318143-5-dmukhin@ford.com>
Message-ID: <df8cf013-02a7-9498-003c-e86471c22867@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-5-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-d25034/1786393325-768DDA5B-1F6D54E3/0/0
X-purgate-type: clean
X-purgate-size: 1316

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:

> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Switch 'txbuf' allocation to xvmalloc_array() since there is no
> hard requirement to have buffer physically contiguous.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> Changes since v7:
> - new patch
> ---
>  xen/drivers/char/serial.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index e3c356408987..cf0abf1893e5 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -12,6 +12,7 @@
>  #include <xen/param.h>
>  #include <xen/sections.h>
>  #include <xen/serial.h>
> +#include <xen/xvmalloc.h>
>  
>  #include <asm/processor.h>
>  
> @@ -524,8 +525,7 @@ void __init serial_async_transmit(struct serial_port *port)
>          serial_txbufsz = PAGE_SIZE;
>      while ( serial_txbufsz & (serial_txbufsz - 1) )
>          serial_txbufsz &= serial_txbufsz - 1;
> -    port->txbuf = alloc_xenheap_pages(
> -        get_order_from_bytes(serial_txbufsz), 0);
> +    port->txbuf = xvmalloc_array(char, serial_txbufsz);
>  }
>  
>  /*
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:25:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:25:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387851.1629078 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWYU-0008BI-CZ; Mon, 10 Aug 2026 20:25:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387851.1629078; Mon, 10 Aug 2026 20:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWYU-0008BA-7x; Mon, 10 Aug 2026 20:25:06 +0000
Received: by outflank-mailman (input) for mailman id 1387851;
 Mon, 10 Aug 2026 20:25:05 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWYT-0008B2-Ef
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:25:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWYS-008oBz-Nt
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:25:04 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a338b-e002-0a2a0a5209dd-0a2a450ab88a-48
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:25:04 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a339f-f2d2-0a2a450a0019-ac6904fec464-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:25:04 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 0C188600C8;
 Mon, 10 Aug 2026 20:25:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1170A1F00A3A;
 Mon, 10 Aug 2026 20:25:00 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786393502;
	bh=gxVI8+t6FDLO0exgPZ+hQfCrbo7kQS0z1o3LAYRyTyY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=eHQOo6aIOJxHktTDbJpmx0VK457JDJz76LBHm3iQKr6i0JBDyWkHpuAKYDxPrTCoN
	 wAqN8R04g1Ga2xQa/J32c8StfxaXt+eJSNqks1dbQrTtTd0Zci8kwoE8CJXspeZoOj
	 64hxbvpLdmWtz76CnrKq+2Ig7GA3m34sv+NMp4d1jk4Vx+BMv6v2j+hLKwSgL5IIyh
	 9uYmpnt7VKa0AMlvDeSYthA71IQiZfHQ6T7IQsOWtc352dYIMjuQtsyAfUuLfBlvlR
	 c8inPZwgxYMsP+jwaUPdEzlykqoj9q0wYVaeJU3j29xL5MIA2sOB8RX11hDHRbe9ld
	 lbwyjvXLEgIlA==
Date: Mon, 10 Aug 2026 13:24:59 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 5/7] xen/console: use memcpy() in conring_puts()
In-Reply-To: <20260728065049.1318143-6-dmukhin@ford.com>
Message-ID: <8b114d89-e026-686c-167c-6ebe1006be4c@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-6-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-4011c0/1786393504-5A9D9CFC-38BA3D9D/0/0
X-purgate-type: clean
X-purgate-size: 1757

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Make conring_puts() more efficient by using memcpy()'s, rather than
> copying the ring a byte at a time.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v7:
> - hardended len check in conring_puts()
> ---
>  xen/drivers/char/console.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 09282a7a4f8e..a1b8e5f5b507 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -361,12 +361,24 @@ static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL);
>  /* NB: Do not send conring VIRQs during panic. */
>  static bool conring_no_notify;
>  
> -static void conring_puts(const char *str, size_t len)
> +static void conring_puts(const char *str, unsigned int len)
>  {
> +    unsigned int src = len;
> +
> +    /* There are no callers with strings longer than PAGE_SIZE. */
> +    BUG_ON(len > PAGE_SIZE);

Should be an ASSERT


>      ASSERT(rspin_is_locked(&console_lock));
>  
> -    while ( len-- )
> -        conring[CONRING_IDX_MASK(conringp++)] = *str++;
> +    while ( src < len )

src is initialized to len, so this is a problem?


> +    {
> +        unsigned int dst = CONRING_IDX_MASK(conringp + src);
> +        unsigned int n = min(conring_size - dst, len - src);
> +
> +        memcpy(&conring[dst], &str[src], n);
> +        src += n;
> +    }
> +
> +    conringp += len;
>  
>      if ( conringp - conringc > conring_size )
>          conringc = conringp - conring_size;
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:32:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:32:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387860.1629085 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWfR-0001Zn-Vl; Mon, 10 Aug 2026 20:32:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387860.1629085; Mon, 10 Aug 2026 20:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWfR-0001Zg-TB; Mon, 10 Aug 2026 20:32:17 +0000
Received: by outflank-mailman (input) for mailman id 1387860;
 Mon, 10 Aug 2026 20:32:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWfR-0001Za-18
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:32:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWfQ-001ci2-3G
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:32:16 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a3528-bab6-0a2a0a5309dd-0a2a450bed62-26
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:32:16 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a354e-b7e8-0a2a450b0019-ac6904fe94a4-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:32:15 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 44139600AD;
 Mon, 10 Aug 2026 20:32:14 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 482631F000E9;
 Mon, 10 Aug 2026 20:32:12 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786393934;
	bh=t0DaZoyzF9WrcIzxXm/INYFRzCeVt+f83Z3q3BoGFYg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=WvyypVdQcDCtsCE08K71Ej8WxeS9X1uWhtyYCJigzO9zfP3vupT8oKt8IyDk9c4NR
	 P9N7xMSRZSYISzyxaPIkOz4a6EdXXALcYWg5qGzNK8uQhliDFLQMngV25Z2jE/DXRZ
	 X0cfQW6Qp5U+U5erjcSkhWEePOqI1FLpzvRVjJ7vRS4AmAaIq+wpdkIb5XNLS4amgo
	 Dx8aMxrkJvbFtmuC5Vh5cu/0720Z5vQjKXW3oSzVppTbd7M/+wE7sLQj6uKYHMrNuP
	 WmiK91Yd4J/6U3MhKA7au8wp9KUgQwdIYwr+olg5DlXYyzF828Nrzuj1WERF2gJX5a
	 Bmr8r3qFaGXjA==
Date: Mon, 10 Aug 2026 13:32:11 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 6/7] xen/serial: harden serial_tx_buffer checks
In-Reply-To: <20260728065049.1318143-7-dmukhin@ford.com>
Message-ID: <4b040e58-9020-a519-00cb-816ce2fddaa0@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-7-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-42698a/1786393936-A92CC9EA-47C70C91/0/0
X-purgate-type: clean
X-purgate-size: 1964

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Ensure the user-defined value never crosses 2GB boundary and always
> rounded to the next power of 2 to align logic with console driver
> conring buffer management code.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v7:
> - addressed Jan's feedback:
>   https://lore.kernel.org/xen-devel/89029dbd-df1f-45d4-8a02-720cd6a42cab@suse.com/
> - kept only check for large buffer in serial_async_transmit()
>   and a doc update.
> ---
>  docs/misc/xen-command-line.pandoc | 2 ++
>  xen/drivers/char/serial.c         | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 1c711fa98086..2be8772b329a 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2396,6 +2396,8 @@ accidentally leaking secrets by releasing pages without proper sanitization.
>  
>  Set the serial transmit buffer size.
>  
> +The value provided will be rounded down to the nearest power of 2.
> +
>  ### serrors (ARM)
>  > `= diverse | panic`
>  
> diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
> index cf0abf1893e5..ba1647309ab8 100644
> --- a/xen/drivers/char/serial.c
> +++ b/xen/drivers/char/serial.c
> @@ -523,6 +523,8 @@ void __init serial_async_transmit(struct serial_port *port)
>          return;
>      if ( serial_txbufsz < PAGE_SIZE )
>          serial_txbufsz = PAGE_SIZE;
> +    if ( serial_txbufsz > GB(2) )
> +        serial_txbufsz = CONFIG_SERIAL_TX_BUFSIZE;
>      while ( serial_txbufsz & (serial_txbufsz - 1) )
>          serial_txbufsz &= serial_txbufsz - 1;

My understanding of this loop is that, given that serial_txbufsz is
unsigned int, it is already clamping it to 2GB max


>      port->txbuf = xvmalloc_array(char, serial_txbufsz);
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:42:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:42:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387867.1629094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWoz-0003SX-R5; Mon, 10 Aug 2026 20:42:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387867.1629094; Mon, 10 Aug 2026 20:42:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtWoz-0003SQ-OR; Mon, 10 Aug 2026 20:42:09 +0000
Received: by outflank-mailman (input) for mailman id 1387867;
 Mon, 10 Aug 2026 20:42:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtWoy-0003SK-FX
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:42:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtWox-00FO3G-LH
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:42:07 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a3771-8faa-0a2a0a5109dd-0a2a4506ba70-24
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:42:07 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a379e-195a-0a2a45060019-aceafc1fd302-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:42:07 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 2F35143E3D;
 Mon, 10 Aug 2026 20:42:04 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7147A1F000E9;
 Mon, 10 Aug 2026 20:42:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786394524;
	bh=2pkvEhvOT48AM77G2DSwJ9QzA4kZ/PPRhW9xCuWWTpg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=RUB+QzMp61DRoMlXy1x6ncyrpmfj9Ir1e5EwcbvCatjliNN1gTLerunPeV5aeKasj
	 E5QwUzEHwfZPLBB1G9FqA2BTS6OogEcghhkTZDZ9sGbS281t1HGVfPVKmhtXDT4Gzt
	 PUtZTxBliRY6mUn/GuPUO7YSnpjWR407eoYK0en5DVnGzbpa2tnXuf/iQUJPtdKu/J
	 G+sRDg1tZquXPB+Z5RnRB3fch/5uZj2b8f0mWAT6HGMTrDkQH1RKiZMB+e2yKrNqZL
	 E2pD2zGjf5OteNiMjlrmW1PI9EJBKTjQJ8f1TZVSl4Xv+g9VNDYaTmtyh76W/7ZIcB
	 vyC2fwkhZ1YnQ==
Date: Mon, 10 Aug 2026 13:42:01 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 7/7] xen/console: make console buffer size
 configurable
In-Reply-To: <20260728065049.1318143-8-dmukhin@ford.com>
Message-ID: <3db29635-6c45-8071-53d8-01737e1a7349@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-8-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-16d1c6/1786394527-1EAC277B-66E0B5A8/0/0
X-purgate-type: clean
X-purgate-size: 3767

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Add new CONRING_SHIFT Kconfig parameter to specify the boot console
> buffer size as a power of 2.
> 
> The supported range is [14..27] -> [16KiB..128MiB].
> 
> Set default to 15 (32 KiB).
> 
> Update the documentation for 'conring_size=' command line option.
> 
> Resolves: https://gitlab.com/xen-project/xen/-/issues/185
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v7:
> - n/a
> ---
>  docs/misc/xen-command-line.pandoc |  8 ++++++--
>  xen/drivers/char/Kconfig          | 21 +++++++++++++++++++++
>  xen/drivers/char/console.c        |  6 +++---
>  3 files changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 2be8772b329a..448c9bdb8254 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -425,10 +425,14 @@ The following are examples of correct specifications:
>  ### conring_size
>  > `= <size>`
>  
> -> Default: `conring_size=16k`
> -
>  Specify the size of the console ring buffer.
>  
> +The default console ring buffer size is selected at build-time via
> +`CONFIG_CONRING_SHIFT` setting.
> +
> +The run-time console ring buffer size is the maximum of the build-time value
> +and the value specified by the `conring_size=` command-line option.
> +
>  ### console
>  > `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
>  
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index 8e49a52c735b..a40a9929132b 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -95,6 +95,27 @@ config SERIAL_TX_BUFSIZE
>  
>  	  Default value is 32768 (32KiB).
>  
> +config CONRING_SHIFT
> +	int "Console ring buffer size (power of 2)"
> +	range 14 27

anything above 20 would fail to build on arm


> +	default 15

this is OK but is double than the previous default and would be nice to
keep a note about it in xen-command-line.pandoc


> +	help
> +	  Select the boot console ring buffer size as a power of 2.
> +
> +	  The run-time console ring buffer is the maximum of the build-time
> +	  value and the value specified by the `conring_size=` command-line
> +	  option.
> +
> +	  If `conring_size=` is not specified on the command line, the run-time
> +	  console ring buffer size is the maximum of this value and
> +	  `num_present_cpus() << (9 + xenlog_lower_thresh)`.
> +
> +	    27 => 128 MiB
> +	    26 =>  64 MiB
> +	    ...
> +	    15 =>  32 KiB (default)
> +	    14 =>  16 KiB
> +
>  config XHCI
>  	bool "XHCI DbC UART driver"
>  	depends on X86
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index a1b8e5f5b507..76367c1dd705 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -340,12 +340,12 @@ static void cf_check do_dec_thresh(unsigned char key, bool unused)
>   * ********************************************************
>   */
>  
> -/* conring_size: allows a larger console ring than default (16kB). */
> +/* conring_size: override build-time CONFIG_CONRING_SHIFT setting. */
>  static unsigned int __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);
>  
> -#define _CONRING_SIZE 16384
> -#define CONRING_IDX_MASK(i) ((i)&(conring_size-1))
> +#define _CONRING_SIZE       (1U << CONFIG_CONRING_SHIFT)
> +#define CONRING_IDX_MASK(i) ((i) & (conring_size - 1))
>  static char __initdata _conring[_CONRING_SIZE];
>  static char *__ro_after_init conring = _conring;
>  static unsigned int __ro_after_init conring_size = _CONRING_SIZE;
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 20:56:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 20:56:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387877.1629104 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtX2v-0005TC-1q; Mon, 10 Aug 2026 20:56:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387877.1629104; Mon, 10 Aug 2026 20:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtX2u-0005T5-VK; Mon, 10 Aug 2026 20:56:32 +0000
Received: by outflank-mailman (input) for mailman id 1387877;
 Mon, 10 Aug 2026 20:56:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3-zp6agYKCbQmYUhdWaiiafY.WigrYh-XYpYffcmnm.rYhjlidYWn.ila@flex--seanjc.bounces.google.com>)
 id 1wtX2t-0005Sz-Ne
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 20:56:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtX2r-00FPvO-Nv
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:56:29 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3-zp6agYKCbQmYUhdWaiiafY.WigrYh-XYpYffcmnm.rYhjlidYWn.ila@flex--seanjc.bounces.google.com>)
 id 6a7a3ac0-8faa-0a2a0a5109dd-0a2a4503986e-32
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:56:29 +0200
Received: from [209.85.215.200] (helo=mail-pg1-f200.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3-zp6agYKCbQmYUhdWaiiafY.WigrYh-XYpYffcmnm.rYhjlidYWn.ila@flex--seanjc.bounces.google.com>)
 id 6a7a3afc-fae8-0a2a45030019-d155d7c8bd58-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 22:56:29 +0200
Received: by mail-pg1-f200.google.com with SMTP id
 41be03b00d2f7-cab041eced3so3914743a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 13:56:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786395388; x=1787000188; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=LCgbuv6Vd7zF2bZTNz0VWHu3WJNY8tSX432zegD8YdU=;
        b=u+UO2xODGCGgUrlf/Mr5d0z+0HcYJ0lJhHAi6HmU2+L+FqX2t/v5Sx/lVOeYoXrKiW
         1H+Hy/MwZuEG7glfm8EzJw23z9TtABPeIoyuvR5D+qr5HJleaHMpFExpI5j55bxcEtfM
         TZGNhJb0UG+n63ir7dvKXwew5PninTo36AswGFXS1gjX3wA/vVYkhCg8rzZVeL1635nf
         ufEw5vOrbM7KXtRG+2qzWgjcYoBCuUWBZWEpVrCCTo4HmE1c/bOhllSDHogP89NONUWY
         9aiVKiZIkzOQeRVUgx70/+pSBklp+H0+XBRPfRB/bEwOXPXhQ3b/WCsmD/XsHManELMe
         7bEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786395388; x=1787000188;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LCgbuv6Vd7zF2bZTNz0VWHu3WJNY8tSX432zegD8YdU=;
        b=rICatsTJsTU0C2t2lQmeWvF/daPXwuRAOlfJtZeg5b1jSMYz4W+ZUg31uf6iyWfVmn
         gfC919tHnl6lmQbEI7bxEjbp3ntBPtNeMgPs2paa5ChOWenN2D6zjRioYT7hXlDfgjq8
         j/lXXVhoP6/tFMBa+FLQXI0u/xoRLzc0Joq18yRPePV9k5wbFE8YUxPCkokjAoxyL0J/
         UpITmmp0AhxOpYvWHN3qrQxRXzi0/OBkv5L+5Z4U5FAhJLi216tXEOa2HGg6hMKLuHhP
         WNlFN9dnRFBgo4WWwiFzFC6xZXJoeEwgdAZhpZsfPdN8wq+txp9gpy1KD1LG3z6LIZa6
         dLFA==
X-Forwarded-Encrypted: i=1; AHgh+Rpn75V9jjDQVWOgDSDZA1YZ1lmZXvVj1Z5wYtSqmQ4p4DJMsj4pM3WDGZwvHYdcv5KSXNbLQ72WCdk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAhg7vtRNfJYns70KO/McAoxNEi3zUzjwzAD29ovr8HvvqWOcA
	c8x2NxGP2AV9oVegzG3M4Po05bWeBxzFjAuRdoMcTkwKg6OBQu8obO+vKO+Y8ez7VmTB2PUx+aI
	8Rz1UXA==
X-Received: from pgmc19.prod.google.com ([2002:a63:1c53:0:b0:c98:2639:852e])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:ad1:b0:848:4d1a:9556
 with SMTP id d2e1a72fcca58-84f9c8f6a11mr4384666b3a.11.1786395387317; Mon, 10
 Aug 2026 13:56:27 -0700 (PDT)
Date: Mon, 10 Aug 2026 13:56:26 -0700
In-Reply-To: <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-18-dwmw2@infradead.org>
 <anoOz2rZ02KFk1l-@google.com> <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
Message-ID: <ano6-gIZtqMfipiD@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-33051d/1786395389-6CEDA4E9-3C117D72/0/0
X-purgate-type: clean
X-purgate-size: 2288

On Mon, Aug 10, 2026, David Woodhouse wrote:
> On Mon, 2026-08-10 at 10:47 -0700, Sean Christopherson wrote:
> > =C2=A0
> > > But when the vCPUs merely have a different TSC *offset*, that's not a
> > > problem. The offset is applied to that vCPU's kvmclock->tsc_timestamp
> > > field, and it all comes out in the wash.
> >=20
> > It's not though?=C2=A0 The value stored in kvmclock->tsc_timestamp is p=
er-VM, not
> > per-vCPU, when using the master clock.=C2=A0 It's a little easier to se=
e once the
> > master clock TSC isn't shoved into host_tsc:
> >=20
> > 	do {
> > 		seq =3D read_seqcount_begin(&ka->pvclock_sc);
> > 		use_master_clock =3D ka->use_master_clock;
> > 		if (!use_master_clock)
> > 			continue;
> >=20
> > 		if (!kvm_get_time_and_clockread(&kernel_ns, &host_tsc)) {
> > 			use_master_clock =3D false;
> > 			continue;
> > 		}
> >=20
> > 		master_tsc =3D ka->master_cycle_now;
> > 		master_ns =3D ka->master_kernel_ns;
> > 	} while (read_seqcount_retry(&ka->pvclock_sc, seq));
> >=20
> > 	...
> >=20
> > 	if (use_master_clock) {
> > 		hv_clock.tsc_timestamp =3D kvm_read_l1_tsc(v, master_tsc);
> > 		hv_clock.system_time =3D master_ns + v->kvm->arch.kvmclock_offset;
> > 	} else {
> > 		hv_clock.tsc_timestamp =3D tsc_timestamp;
> > 		hv_clock.system_time =3D kernel_ns + v->kvm->arch.kvmclock_offset;
> > 	}
>=20
> Meh. I shall have to build a better test case for that one. Thanks.
>=20
> > To allow different offsets, KVM would need to track a per-vCPU offset t=
o the
> > master clock and apply that in kvm_guest_time_update() (and maybe other=
 places?).
> > Which is doable, but it's not clear to me why we'd want to support that=
 (though
> > I haven't fully processed the back half ot his series, so it's very pos=
sible I'm
> > missing something obvious).
>=20
> Because I want to reduce the number of cases where we have to fall back
> to non-masterclock mode. Especially the ones which are driven by
> *guests* rather than weird choices on the VMM's part.

But why though?  What is the harm to the host or guest?  E.g. does it make =
it more
difficult to accurately migrate the VM?  I'm not opposed to allowing master=
-clock
mode with diverging offsets, just trying to understand why it matters.



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 21:13:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 21:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387884.1629113 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXJ3-0000Mg-B6; Mon, 10 Aug 2026 21:13:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387884.1629113; Mon, 10 Aug 2026 21:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXJ3-0000MZ-88; Mon, 10 Aug 2026 21:13:13 +0000
Received: by outflank-mailman (input) for mailman id 1387884;
 Mon, 10 Aug 2026 21:13:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wtXJ1-0000MT-Sp
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 21:13:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtXJ0-00FS0Z-A9
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 23:13:10 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a3ee6-2eae-0a2a0a5409dd-0a2a450ad456-0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:13:10 +0200
Received: from [40.107.162.140]
 (helo=PA4PR04CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a7a3ee5-f2d2-0a2a450a0019-286ba28cce99-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:13:10 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by PA1PR03MB11087.eurprd03.prod.outlook.com (2603:10a6:102:4fb::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 21:13:07 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 21:13:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=reVNKDrSwnSwMLwBl3fvobBW/65233a1wXrmuGy0+N1S5cX9VBIfemPENrAyrWU7/hWqOZF+QkQXKeESpWza76Raq1/6ZTAnM+SOuqsVysuSVmHe4yo9WQId7nivsYgxHJZzOjX8oSqJEVRsGWtsFrlqB9Lexh+LUfv3V5g8246bXYbjgeEXRn8gNRoR4dbdCxNbM4s6B1bzNT6zBP/Vq7kF4AzD5swUl45XAlJHsZTFFj1fxM5giZO/LT79o39XOk8hjP9T5/i8/JR2y/GXALSlk/p69c2INaUDGkA2mNsAuwddv+beGAH3+s+utqLzG81sdtfuL0NUCy6itCYMkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LzWm+MoDAj5aNhJ4WndKnYf0eWSbIGtd8eby1BHS21I=;
 b=WjSichy0/m2ciksaS5zMcC79Qq6/DnjN+It3xoFOte8i8H49mQNJMlNrbuXlzNPeibpgUSpxLNxq8qfoAzJtJypiJMFui3kNEC2ZH7cn7iXnN8208P9Pvi01jmasj77We5FohMtAAjxL8egaoI3za7MprbxorhcPP782CmkEOs+j1PPGJveS6TgMnxfEMJtZjbDRkkFTjCfw336y/wckrLmZYYs8hXNuTnJop6o0OZhC/y+Ir+cy5eGVYj+lQ26MEsukM1HqhzbVwlq6k6+uutoLyGofGzbHfeYpxrCBo03/NRSXQRtBUt2f09XZFvK2SqSrAsidwC8R4sUlrNiBkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LzWm+MoDAj5aNhJ4WndKnYf0eWSbIGtd8eby1BHS21I=;
 b=uXKGhYajRPdJh6lzZTNhfqMxpDQKOGIQV32wZEfEAnkob9PFsOUhpmZq1Lrxo8FviMCC371gERvN9Sl+HvHW/X6D2reVm9raOLT5YaF/HP5yxr4FeSKT2uq4ToRJqRPsGRKFV6lJgyexXVRb+5E6PTX+JtYnjq3WVBIuGaJA6eYfIE3aS79GbBdr4q1V79asRscpKtsEVUwwuMIrQNmpU/s9av7DzZ7lx4d7qZ/pGmINhkwD/Jmo217ciUv9MdVeGEbo0BgF/qEtwoHTEp8ua+6vQJkbOV1DKBsVdiGLg2SHqizrI7fW6ygA+S+OqJbKyycUzYJQ4czHTx5Dq5uK4A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2] xen/arm: derive GIC CPU interface ID fields from the vGIC
Date: Tue, 11 Aug 2026 00:12:56 +0300
Message-ID: <f46f9e6ebb12d8402fa72b1641796f33e24c539f.1786395761.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA1PEPF00005B70.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::609) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PA1PR03MB11087:EE_
X-MS-Office365-Filtering-Correlation-Id: 39ddbef3-ac06-4cbd-6d3a-08def7242c95
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|11063799006|10067099003|5023799004|56012099006|6133799003|18002099003;
X-Microsoft-Antispam-Message-Info:
	AMF2SBunzSAL9fG9mIM3vy6oGsdXTEf9dAG4bVWUFKnVyYRH7B1GlZFK3Z7VZ5LGTERxtnvnLjJvf3WHXOHV0VY02829aCyHU3OSVaaSncD60nuxifRo5XtYHwe3Bv8fE85zfhFDd0kBxPxfCpctD0AUbZv4KS0Klg/RWL9mNfpSOarIfobxNfudrg9CVclt5RaeDqjBuIli77BL59R0vX8+qy/NNm6XCtfn5OdvBF4fmJ6RPYYwEuhwP9ywtKjX8JZxQ9dLoeholVoAAxZ3kARERM1wFRTUGI3B18Q0EdlHN6ql0oVXHZxWRiCEKchrle9S+0NlOtoHQDrt5ZtXLcD7//Gv/O2mRFgn3Yf0z5w7p560OZl7/mBgPqthG9UY9xmp49ONy8Hqd90FXLqoiaQ1CtrFqDwpKl8LNJQraMphIb+H4nHbOhFqybXciH/rM+SA00ozySI7hq7sn8SR0qB3XOLVFKvAB52Pf5HEz3Eyubgwf9Doyc08sFJOHAqZ86QVRfKLTXm4FO2O0tKHi6qBlOIis8nCyzIJzYK6zQVwY79R5AsEw6U9eUJg05GT5jSaq7Cyd8umvMFII0rp0zt3fv8a33Lfb53qXAp2A+Q=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(11063799006)(10067099003)(5023799004)(56012099006)(6133799003)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?vyebwNCxMJRZ9UMCSV7ZF0qA5Tga00bMVhakrl3xO574SVmkVLLJaDyxyCe6?=
 =?us-ascii?Q?ziKCpCMNWRG5yXJOmyyJ4svytKVn3gNzXCoX1IhEwYxDv65F1fY9rJy8pwxU?=
 =?us-ascii?Q?BEfdj8qN2nE6WTJS7L9IQzy+rwKG5vVE87o6CJW5tatk53s5JjWLTJ1K4TOS?=
 =?us-ascii?Q?oBeata5KNUsZ1teKcixRm8Z/F+u99+s+c8prjrgCJUZ1xiXbBFs3hEme8XUw?=
 =?us-ascii?Q?ejYi793Lv6aoYVSYnd6y6/0YHc8Fa9sLAyVl1Sj1rr4NouUCvPKkbtMq0RM1?=
 =?us-ascii?Q?CAbcAEGWfYniCb/qw1ARNCEAfiR9IKuSW6cm0Wby1gef3DqGhVi98ZeqAz7/?=
 =?us-ascii?Q?sSPtRichTo6Dz0ESjNYtHS05Fk+LUzGxh9m6ZUvZCeuzBCO/YZisyOZ/M+Cy?=
 =?us-ascii?Q?XQCPj0w9Sa7ZrYQOUaEFSsHhoUeE6Ek68kkF7ollzhoH3pRx1oAPy38Nmul1?=
 =?us-ascii?Q?QHq1lpV3x2lnuKoMQ+ANjcMtGlKO1wwm4g7qdruatnzvaHzkgZD8aBJMIzzT?=
 =?us-ascii?Q?v4ld4hlKeoe4W/owY2V7pPBRiT1oMptVWI0e83kBZcouTQketJCEZUneInY1?=
 =?us-ascii?Q?2SBq1eLpMxA6Ul+mpUKGQISGX9w79IxaOATClzRVS/sFmQpC2tfM8mSAjQkp?=
 =?us-ascii?Q?d/Uex7BRrPlBonF5QZH0sRWjGLjyvFzOhFmKFVHdkmyAYi2F/emnAkS7RE5g?=
 =?us-ascii?Q?vYOeUnleAazSXB3bam7hkUKIRGtvXRl06T298fnkB6h6y3zj8LnARpsRa/q9?=
 =?us-ascii?Q?KVariQc6OcJnvC4fm9Rf9DktAZsUBJhxeZ1ZitFcy4H67iOwETfkO7QAfB7B?=
 =?us-ascii?Q?VinJ6f2a9HkxEdS7TQUAS3x00GVUehUjdXauT5lOPTUaoBciG/k233vP/Chr?=
 =?us-ascii?Q?TOLz2dRVXQvVsKygMmD3O6xcK8xK/PJRHCFWoFTwn/owLwAidrvqzbh4fwOr?=
 =?us-ascii?Q?lifouFrkSul/q4NNbLcgJCo8qTYYU7axWH6lSjeGcy6jXKZMLbbGL8XNoEmS?=
 =?us-ascii?Q?MrkKXEPMPi2C6ydjt/05pQx+U7B3+xC4yR7mLo/fJBmIx+X5Y9Ik48fmEdSm?=
 =?us-ascii?Q?cXG748nLxXQkfQZTjiQiSt+LFgUaOFs6+q1qFlX2sSoe7jHlucw28y2d33bK?=
 =?us-ascii?Q?d2X/RiM3ZrZ0fxqzsWVtHpdBKSo0AqqS9+hKH2k9/tivD6GfEMWIbQz/Yvt2?=
 =?us-ascii?Q?FrX50WQK94BtITjO6a6g7zxNXXM2mooUZB0bcLZUC6TaZJZaCxXfgyrhhQdM?=
 =?us-ascii?Q?rkQRZOhjE+7693tWXMeR5olnXH39vHapKZhjTJQ+wS8LN5rIc5RCegoeSdbu?=
 =?us-ascii?Q?fr0cdUy/vAQVfTAYoobcLh7u89pGn5+l+wncavkK9N1Rk9tA4pStDOrr8x1B?=
 =?us-ascii?Q?8zNV5GVb29fOXyAVQ3GuSXoL2zYvslkz0zBwWfMCSU/5DqllOecsQWA5Guy4?=
 =?us-ascii?Q?fxJHmcNb84P/i3joX+p+wNswe4DdHoDdRTWXm+rBcs/g+8mgoG5R/6rBgN7v?=
 =?us-ascii?Q?vQhVvf4fZee8vEtE86ddsHhlnjKRvoxjct5AyyuyvWZ+yWdbgxEBKgoesbms?=
 =?us-ascii?Q?Mx1/WKG5xJoSjq+0mYN95VQYC/OoVdrTiDOJ0ra/werH6/4i1lEdpsaDbnPv?=
 =?us-ascii?Q?QE+2IAtrS+LYq8vRUasW0wOySYoRt83bA3xjw8zPi6K9JKkwfQzqKl4wjkr4?=
 =?us-ascii?Q?18wupMf0Kx8fBLK5I4bk77KmycpnMj7uZXyZl1NEKgKxx2z5e+WNfHw1Ijxv?=
 =?us-ascii?Q?NYI2RSE1yA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 39ddbef3-ac06-4cbd-6d3a-08def7242c95
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 21:13:07.3404
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Cu7S+oKpRR980ev1+YmiMZR+NUBlJgvHfVTSvKn/i7L7/JMTaZY7pNIjJ/Pqu0ruugBVC05d929A4Wxwu4HG7g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11087
X-purgate-ID: tlsNG-4011c0/1786396390-51CC3CFC-DF4A89C5/0/0
X-purgate-type: clean
X-purgate-size: 6134

Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo,
which is initialized from the sanitized host CPU feature state. This
does not necessarily match the virtual interrupt controller configured
for a domain.

A vGICv2 domain can therefore observe a nonzero GIC field when the host
supports the GIC system register interface, even though Xen disables that
interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can
observe encoding 0b0011, although Xen exposes only its vGICv3 model.

Derive the fields from the domain's vGIC version instead. Expose 0b0000
for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the
ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through
CP15 in AArch32 state. Leave the alias unchanged when AArch32 is
unavailable.

Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Share the GIC ID field helpers between the AArch64 and AArch32 paths.
- Parenthesize the individual ASSERT conditions.
- Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable.
- Target master instead of the 4.22 release.

v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/
---
 xen/arch/arm/arm64/vsysreg.c    | 18 +++++++++++++++++-
 xen/arch/arm/include/asm/vreg.h | 20 ++++++++++++++++++++
 xen/arch/arm/vcpreg.c           | 15 ++++++++++++++-
 3 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index d14258290f..a02ad951f9 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -21,6 +21,7 @@
 #include <asm/arm64/cpufeature.h>
 #include <asm/arm64/sve.h>
 #include <asm/current.h>
+#include <asm/gic.h>
 #include <asm/regs.h>
 #include <asm/traps.h>
 #include <asm/vreg.h>
@@ -304,7 +305,18 @@ void do_sysreg(struct cpu_user_regs *regs,
      * to identify the processor features
      */
     GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
-    GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
+    case HSR_SYSREG_ID_PFR1_EL1:
+    {
+        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
+
+        if ( cpu_feature64_has_el0_32(&domain_cpuinfo) )
+            guest_reg_value = id_reg_set_gic_field(guest_reg_value,
+                                                   ID_PFR1_GIC_SHIFT,
+                                                   v->domain);
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  guest_reg_value);
+    }
     GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
     GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
     GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
@@ -343,6 +355,10 @@ void do_sysreg(struct cpu_user_regs *regs,
             guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask;
         }
 
+        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
+                                               ID_AA64PFR0_GIC_SHIFT,
+                                               v->domain);
+
         return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
                                   guest_reg_value);
     }
diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
index 387ce76e7e..24735aaea1 100644
--- a/xen/arch/arm/include/asm/vreg.h
+++ b/xen/arch/arm/include/asm/vreg.h
@@ -9,6 +9,26 @@ typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
 typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r,
                                    bool read);
 
+#define ID_REG_GIC_WIDTH 4
+
+static inline unsigned int vgic_id_gic_field(const struct domain *d)
+{
+    ASSERT((d->arch.vgic.version == GIC_V2) ||
+           (d->arch.vgic.version == GIC_V3));
+
+    return d->arch.vgic.version == GIC_V3;
+}
+
+static inline register_t id_reg_set_gic_field(register_t val,
+                                               unsigned int shift,
+                                               const struct domain *d)
+{
+    register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift);
+
+    return (val & ~mask) |
+           ((register_t)vgic_id_gic_field(d) << shift);
+}
+
 static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr,
                                      vreg_reg_fn_t fn)
 {
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index e7c484f2c1..d6f9326b71 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -12,6 +12,7 @@
 #include <asm/cpufeature.h>
 #include <asm/cpregs.h>
 #include <asm/current.h>
+#include <asm/gic.h>
 #include <asm/regs.h>
 #include <asm/traps.h>
 #include <asm/vreg.h>
@@ -173,6 +174,8 @@ TVM_REG32(CONTEXTIDR, CONTEXTIDR_EL1)
                                   domain_cpuinfo.field.bits[offset]);\
     }
 
+#define ID_PFR1_GIC_SHIFT 28
+
 /* helper to define cases for all registers for one CRm value */
 #define HSR_CPREG32_TID3_CASES(REG)     case HSR_CPREG32(p15,0,c0,REG,0): \
                                         case HSR_CPREG32(p15,0,c0,REG,1): \
@@ -321,7 +324,17 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
      * to identify the processor features
      */
     GENERATE_TID3_INFO(ID_PFR0, pfr32, 0)
-    GENERATE_TID3_INFO(ID_PFR1, pfr32, 1)
+    case HSR_CPREG32(ID_PFR1):
+    {
+        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
+
+        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
+                                               ID_PFR1_GIC_SHIFT,
+                                               v->domain);
+
+        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1,
+                                  guest_reg_value);
+    }
     GENERATE_TID3_INFO(ID_PFR2, pfr32, 2)
     GENERATE_TID3_INFO(ID_DFR0, dbg32, 0)
     GENERATE_TID3_INFO(ID_DFR1, dbg32, 1)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 21:36:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 21:36:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387892.1629122 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXfQ-0004el-3L; Mon, 10 Aug 2026 21:36:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387892.1629122; Mon, 10 Aug 2026 21:36:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXfQ-0004ee-03; Mon, 10 Aug 2026 21:36:20 +0000
Received: by outflank-mailman (input) for mailman id 1387892;
 Mon, 10 Aug 2026 21:36:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtXfP-0004eY-Cl
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 21:36:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtXfO-009naE-7B
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 23:36:18 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a4452-2eae-0a2a0a5409dd-0a2a450ccc58-0
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:36:18 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7a4450-f479-0a2a450c0019-aceafc1fe26c-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:36:17 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 3438340110;
 Mon, 10 Aug 2026 21:36:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F2111F000E9;
 Mon, 10 Aug 2026 21:36:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786397776;
	bh=Dxn4ZrksVwI2spn1hMaPK022GKaG2Go1NXbLkJDX6Lo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=m8fDnUFYqTYIghoC6HAWYNXjg+hbRmOzAF4f7EVMLXCRAtOUxGyBCHKpah0594Nfl
	 7fe7/VE43EiJ6/r2WuB8a4+yGrG6h3o5E2CTjo7OFP/IfAw+w//ln/GI7uNitgovd+
	 H6ObFYNgB6fOM6IEW3ZmsIauFQRxKP8v1OQCjeHHfazfFaaKcQbhyIBJ7t4zNUr287
	 YGdq1nH2ssbE5nt3AJ5hRjDpGO8ZELAcgM1nxWrAiarqTHjX/B+erK0/vMyh3ifGS0
	 sCjN0o8FJxS68w7cAlZD9fz9TT4qvd7g5u3OVeEIaoBOL/wF3Nfbd2miZXgT/G1AFC
	 kU0ObfLlt5q1w==
Date: Mon, 10 Aug 2026 14:36:13 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: dmukhin@ford.com
cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, 
    anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, 
    michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 5/7] xen/console: use memcpy() in conring_puts()
In-Reply-To: <20260728065049.1318143-6-dmukhin@ford.com>
Message-ID: <e0de78c5-2530-375e-91a3-b1138d2ea6d2@kernel.org>
References: <20260728065049.1318143-1-dmukhin@ford.com> <20260728065049.1318143-6-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-d25034/1786397778-026DEA5B-B99070F0/0/0
X-purgate-type: clean
X-purgate-size: 1732

On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Make conring_puts() more efficient by using memcpy()'s, rather than
> copying the ring a byte at a time.
> 
> No functional change intended.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v7:
> - hardended len check in conring_puts()
> ---
>  xen/drivers/char/console.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 09282a7a4f8e..a1b8e5f5b507 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -361,12 +361,24 @@ static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL);
>  /* NB: Do not send conring VIRQs during panic. */
>  static bool conring_no_notify;
>  
> -static void conring_puts(const char *str, size_t len)
> +static void conring_puts(const char *str, unsigned int len)

Here, I think it would be better to keep it size_t


>  {
> +    unsigned int src = len;
> +
> +    /* There are no callers with strings longer than PAGE_SIZE. */
> +    BUG_ON(len > PAGE_SIZE);
>      ASSERT(rspin_is_locked(&console_lock));
>  
> -    while ( len-- )
> -        conring[CONRING_IDX_MASK(conringp++)] = *str++;
> +    while ( src < len )
> +    {
> +        unsigned int dst = CONRING_IDX_MASK(conringp + src);
> +        unsigned int n = min(conring_size - dst, len - src);
> +
> +        memcpy(&conring[dst], &str[src], n);
> +        src += n;
> +    }
> +
> +    conringp += len;
>  
>      if ( conringp - conringc > conring_size )
>          conringc = conringp - conring_size;
> -- 
> 2.54.0
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 21:37:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 21:37:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387899.1629131 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXgQ-00058w-BP; Mon, 10 Aug 2026 21:37:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387899.1629131; Mon, 10 Aug 2026 21:37:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXgQ-00058o-87; Mon, 10 Aug 2026 21:37:22 +0000
Received: by outflank-mailman (input) for mailman id 1387899;
 Mon, 10 Aug 2026 21:37:21 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wtXgP-00058e-6U
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 21:37:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtXgO-000nkd-82
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 23:37:20 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7a4457-e002-0a2a0a5209dd-0a2a4509abb8-28
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:37:20 +0200
Received: from [40.93.196.65]
 (helo=SA9PR02CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7a448e-be1a-0a2a45090019-285dc4414e10-3
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:37:19 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA2PR03MB5738.namprd03.prod.outlook.com (2603:10b6:806:fb::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 21:37:16 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.024; Mon, 10 Aug 2026
 21:37:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mVJmranwl6HqirYdUYhbdGMocCTXc4aKKfXQRGV87CziVNI2JGI1eLPCgiqlyEG03uSSSp/jmlosQJOKShB8lxlsTxvqY0gskeDgIi4SsSFevsWRWFh1v78hKffKQvJcVnKqOURpBda57MJxThTY9dw5+swe7flZHiYclj7siXCATV8z54E57iDjIzTi+nBszPO+xqmpQJ99FgCv+kaVbZQpPK0BCvhHpG0O8pqSZ7jAtwlHWR288yuuj6M97S0suJSY6mUhjPIeWLyw2Soqvj7RxDo02JX1AmkriiowByIBono2DjUacxSidknQQBCOD5hreEU3/sxnT5xtkI7G/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OM+mAY+O7i3CfxnsDVu/HXx5p6iBiKJNSROZuaBQNjk=;
 b=JE+Yj6aJpa130kCjG4b1AS34Ys8X+lIxvf1zN+lad60pfPtDxxBdIiLBQcU3RyUMbWxAZzpjciK8QRzHE+99ypSUBdOTv7hJ6CrrkEz2FrgKnAohdKsiUTsukONP/MLVsDUowanDECtoZQnhl6sMlMIrXErzEalVaJwc6LkDLLprBxoCKBSmPVqvE6X3/sOJHusKHRKgOjNNTm2vj2qCsgQKfDya5ho+/ytxgUQZOA37BtQUo9kGBYd/y4haSRxZAwQaaijDVsr6j1sDXGrtImOoRW6mIHtV2UhH0CeyYiPqbsRdHWpLK49NgwTfu6GM0U45aMJyObKUumviiinM/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OM+mAY+O7i3CfxnsDVu/HXx5p6iBiKJNSROZuaBQNjk=;
 b=jNjJ5IHaHz474zBYVPmIXcUlOcpaYGQmN9Fjw4ZRCUhILCgQ/rbbs48C/TWbcZWPApHkQsks3nD3zhcKP27uNEV93mStaFg1eUZ8Kdh6S+52E7phvpZNlvZ35FgzYIrldTx4nXRpcwlpoSt44DoFgAFO7SKHOeotCogfZgdHRCk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <90f7a25f-4007-4f9e-b5d1-ab2b18ab59f9@citrix.com>
Date: Mon, 10 Aug 2026 22:37:12 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, anthony.perard@vates.tech,
 jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com,
 roger.pau@citrix.com, sstabellini@kernel.org
Subject: Re: [PATCH v8 5/7] xen/console: use memcpy() in conring_puts()
To: dmukhin@ford.com, xen-devel@lists.xenproject.org
References: <20260728065049.1318143-1-dmukhin@ford.com>
 <20260728065049.1318143-6-dmukhin@ford.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260728065049.1318143-6-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0376.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18e::21) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA2PR03MB5738:EE_
X-MS-Office365-Filtering-Correlation-Id: dd3877b8-4628-4159-7d96-08def7278bf8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|4143699003|11063799006|56012099006|10067099003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	kd7CSzMDEw80YukTjoN8IJ3hGCA/fU4rbv01f8V36Ku4JbNKfNvyGsDiA0JAfmdgq73vvpVdNIRjx+Z42x8LYrkGbh2lKgVcCvinUtKTLcVlM05EaivmEXXMystNk6dwqPg8FVRUykAw3ZezkOX74OtsYbYn4dnOW9GzLZ+NNuv7yxJCgpMxIW7ZpbF1ftFgz6Lq9+O9TdueIBY16Nzcsctj2K/XB4EPg4gcAoi6EnzpFvJH6Cnyl0eTG615H/tnEZMcL2W3talwXZAP+u+M/zoX1dg/iTCrPQGghM9akqUiRyInEXsfyDqHtmmVoLvnhC8CLrbFMZlSwkgtLpt7gdcrgG48dROe6I1di1wk/fAgizHDUOXMQsu9/A2dIaqmMUMFlqL0JAaHmjgDTZmpoBe/CVHtOjs8FKdsKR25oYpgt+wGt2TSno0DXIhJWcJo92h7KXmtt0Cdw7Zsg4mzdtD1vZsS976eJJNBMeFI1ThQdvtYJ01LIUAIFEKVkeRoAaCzbhzfk/D0i17L8xM8E9BEyQuQvg4Bd0CvVhs+GTM5B+//HkX7mOO3aoviuYo8OqFrtYm7/ppbzOZ0BNsmslFNP8oNXMruTra8YRUPl9Vjw+8EmYuvJvIxzM4QIWMQSB/ZPrTdtn6mtNln04WiDv3gwz1z+++XsQFENydjGHA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(4143699003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UjFEejZFb085NWs0dmtUMDZuNGpaTUFGQTFTZnRqaTJFTWJEOFdUNHErZnpr?=
 =?utf-8?B?cXprbFRjajJaZXlDUHhsVU43QnR6U0FsVEpsdDRBeW5uZ2tObzF1NVdIckVY?=
 =?utf-8?B?bDhtR04wVndZTzQyZjMyVEZ5b08wSUFObDhJaHpxNk1YeU1nZUE5TzVoM3Bt?=
 =?utf-8?B?ZkZKeVRSRHI5ZnJ4eWNWOWhPckpvOVo1SVZkRGJxR1FjOGhDcHA5bW9LdjBi?=
 =?utf-8?B?Mi9iTE4vbnZFZGM1V1BPckpBQjFJU3QvbWZab2JjRVhMeWd6L1I1N2dYbGxh?=
 =?utf-8?B?WDJQalpSU3NwNXV2T29aU2lDNisrSUpBSWwrV2d1RjB3OFhxZzM1ZGpvYWdL?=
 =?utf-8?B?WWExakFWSUVXb256cU1wNjZKalVDUzNxU216SW91anRodVZJNktQUzk1KzV2?=
 =?utf-8?B?WERFVC9ZSmMvQ3ZuRWd2K0IxM1hPSW94K2NPdW5QL29WSkVOSTZmSXpKZDZX?=
 =?utf-8?B?TitSSUF2RExNWHlZNHdRVXpKNU12ZCtOMi9WeTBhYmZTcUJMa3dRaU1TSHZl?=
 =?utf-8?B?S0lBQy83NUUvMlVBN2N0S2pZZGwwL253UmU5clBuTHVyRzFISklZL1oxV2Ur?=
 =?utf-8?B?NmVyeWlvVjMzaDRrbXRleUFDajROQW1iZmgvTFNJKy9XMWF4VDFQOGFXWERj?=
 =?utf-8?B?Q2lHOUZ6Nk5BR1prYTdIZjUySzJaTGNKWUJZMXdLUWNoTktCTW95Vzdrd1hn?=
 =?utf-8?B?Mld3YVRXdkltRDJkR1ZwdTlPL1dsc0todUN5MVdSRC9TTjJwTUxtSDNzM0o0?=
 =?utf-8?B?Z0MwZUR1TEs3SjE2R3JFa1VGbnV5QUNUVFZ0QVFPa1BubERUSlFaS2xuWnRJ?=
 =?utf-8?B?cE5WSktYdE1HSUphN3NSNndGRk9nT294QVJBK3ljazE5VUttcHZGc01rL1ZB?=
 =?utf-8?B?N2cwWW1UYThlOWxndE5KakRJVmhHcCs5cmVZL1ArNWtIQ2NLSDRlWjBIZFkv?=
 =?utf-8?B?c1dYV2NoWmg5WVVYREs5VE9ERTZaTkJlSzdCbVkzTWEyMVE5UmJTZ3VaR1NK?=
 =?utf-8?B?VkVUdDRlUStJNSt5ckRiZS81TWhwOUFNM0oyOGEyODEwRW1aTmxoQzU5eEx5?=
 =?utf-8?B?NkluazlWbXJUM08vZ016TEw2SmVoTS96bmRaNUtMVjZPZWZEL21SS3A1U0ZI?=
 =?utf-8?B?ai9maXhlWFRxMmJlSDQrM3czM1l2YWc0TmJoYXNzS2ZydFVYMmxQeGtMRkNZ?=
 =?utf-8?B?OURkdnRocWI2ZURBRmlXOHZ4dlFiT081cjhydmdoRSs0QUxLb0JDUktQeEdX?=
 =?utf-8?B?bVpyYWtpNEdlNXhzOEpCV3NVckZ5QSt2ZEE4dTI4SnFZKzdNTkVDcjdQOXIv?=
 =?utf-8?B?QlR5cmt1TElPZGZ0bC9UN1hMeEJ6bHBkQU4wZWoxWGw1WVlIZ1djYWUzbDhE?=
 =?utf-8?B?R2w4NllYL0tmajU2em1TY0hVWXR2VXduSHpqVElHb243MFBiVDNTcmRhY2hJ?=
 =?utf-8?B?UGw1VmtDV3ZmVURaYTZHanBMb21ySzdobE02Y3ZNdTBUYk1Oa1NrbzZoZW5I?=
 =?utf-8?B?aHRRK0pBS0JUWG4vTXQrUGFQeXpFZzFiSXNnSVZOOVZvTERWNThwZVNmaXJE?=
 =?utf-8?B?OGZ1KzdEOW9FRzVHWW1sTmlpcFNtR3lOZkJ1M2RDMWwzcjIyN1AwYnBCR2Vz?=
 =?utf-8?B?bHAwSitoK0cwZlIzVEJhNmVPVUlLZUk1SHlpYWN4SkV0aEdOZXlGQXUwdnlI?=
 =?utf-8?B?T3B3ektpTUhGTmZZa203YVlRRWFvSHRJSXZ5aDFMYnZPQmYrUjgwS01OcFZH?=
 =?utf-8?B?Y0haZXR2SmhzTk1ScW1JcXNtSWRQWFFIZ0l5aUdoN0xsc2pEZHpkSHBPYTRD?=
 =?utf-8?B?OTU3N1J4aC9aTC9DcnFwZk5RR3JXWjJKOWpZRHJieXNkb05pcFlqNHcvRWJ3?=
 =?utf-8?B?ZExjbUNyaXNURFVyKzNCQmlUa3BhakJSK1RCMThXeXQ4VVdveUJiOUlUeE1G?=
 =?utf-8?B?UGVIdElOcmZNU3I3UzJXRWRBWE1DWGk3UVhtVVg2dXdONitOczl4U0J3eDQ5?=
 =?utf-8?B?WTViUTgydjRVcFQ4QXBTVnJYU29pTU5vd3c4ZUxsc3BvUWJpdWpMR1RRek0w?=
 =?utf-8?B?K1NwR1VhWHFDQngxQldVekNNRXFqWTgxQU5xV3BqaHFaUzdielZyL1FCa3pw?=
 =?utf-8?B?YTRDMjg4aVRhNzBiQm1tTHJreXA3Q2crNXpSbUdJY3NKdm5Va1AwYVpYV0ha?=
 =?utf-8?B?bGpLL09ibjBTWExKMEt0YnNaQTVrN0Y4NXZGU2NCdGFFRWYxdXNTblJCTmtW?=
 =?utf-8?B?MVlHVW9oVVJ4UFZ0VTYvaHh3MkhrcVRPR1hobHVxTDJtZE03QmVLTjBvRytI?=
 =?utf-8?B?cmg4VnlhdVZ1TnJsU29QdzBBZkxYSjE5Q2N2ZjROamZHZnIyWVV4QT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd3877b8-4628-4159-7d96-08def7278bf8
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 21:37:15.9238
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cGczisF4xSrIY2ad4FWh3MSYe3yIgax6l/8AEN2gR9dy3QaHdIcdpnK/FjNSJ4FdD6USDjA/xBsl0c19eNfYZlZ36agqIqOoZEkAj5tAiL8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5738
X-purgate-ID: tlsNG-bad1c0/1786397840-3B8D1034-31B78E67/0/0
X-purgate-type: clean
X-purgate-size: 1698

On 28/07/2026 7:50 am, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
>
> Make conring_puts() more efficient by using memcpy()'s, rather than
> copying the ring a byte at a time.
>
> No functional change intended.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v7:
> - hardended len check in conring_puts()
> ---
>  xen/drivers/char/console.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 09282a7a4f8e..a1b8e5f5b507 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -361,12 +361,24 @@ static DECLARE_SOFTIRQ_TASKLET(conring_tasklet, conring_notify, NULL);
>  /* NB: Do not send conring VIRQs during panic. */
>  static bool conring_no_notify;
>  
> -static void conring_puts(const char *str, size_t len)
> +static void conring_puts(const char *str, unsigned int len)

size_t is the only correct type to be using here.  Anything else is
buggy and a ...

>  {
> +    unsigned int src = len;
> +
> +    /* There are no callers with strings longer than PAGE_SIZE. */
> +    BUG_ON(len > PAGE_SIZE);

... bug waiting to happen.  Switching to ASSERT() ok either; it is fine
to pass more than a page here, and all this does is screw over some
future person who has a complicated debugging scenario.

I have 0 remaining patients for the avoidance of size_t.  I will nack
any further patches I see doing it, as well as any further advise I see
given from anyone in the community.


The rest of the patch is fine.  Please resubmit while keeping len as size_t.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 21:44:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 21:44:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387908.1629140 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXnH-0007G8-3v; Mon, 10 Aug 2026 21:44:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387908.1629140; Mon, 10 Aug 2026 21:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtXnH-0007G0-0f; Mon, 10 Aug 2026 21:44:27 +0000
Received: by outflank-mailman (input) for mailman id 1387908;
 Mon, 10 Aug 2026 21:44:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtXnC-0007F9-JT
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 21:44:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtXnB-000omS-PS; Mon, 10 Aug 2026 23:44:21 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7a460b-bab6-0a2a0a5309dd-0a2a450bbd66-24
 for <multiple-recipients>; Mon, 10 Aug 2026 23:44:21 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+5396a5851e3b06deef68+8387+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7a4635-b7e8-0a2a450b0019-5a9b3222ebec-3
 for <multiple-recipients>; Mon, 10 Aug 2026 23:44:21 +0200
Received: from [2001:8b0:10b:5:9f69:702f:982f:3898]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtXBe-00000002RcN-2aLb; Mon, 10 Aug 2026 21:05:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=SijqBWl9ZkBNE7pHvkxqxYD5xyZpHt3QeS+w+ayHuQ0=; b=pSAchZm53udG9aJjudbXeJ1VD9
	GqwPYq5yU6gefz5TZ2w+NIZZLRqzE/ScTJi6ljnSSGssP69X7Y+M73EdEKX/7Z9u1BFDTYkB0ghea
	Yy06tKCJPPtyRC0HCIKvP0dhWERDAFl0I5Se6QKtJJdKqTRiWuRceZB/dzVvoP5roQAyIO40II86z
	o8zhhKe5GqttVYVFixb2tcAsgdKydF+t6xfg96nzfu8X039L2Ly/gFhIvqAaEKbivWwgWj1bks1tR
	CchsqFNYIuO7ytcqnNMYtySbGfyjLE3eMyEHXFJDdSrKDY/EsQQqjSQOI1oTYWC/RxJUXJuZ49qb1
	jYqnTj6A==;
Message-ID: <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Mon, 10 Aug 2026 22:05:00 +0100
In-Reply-To: <ano6-gIZtqMfipiD@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-18-dwmw2@infradead.org>
	 <anoOz2rZ02KFk1l-@google.com>
	 <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
	 <ano6-gIZtqMfipiD@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-zfkTkyTeIpo4gnwF+EUX"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-42698a/1786398261-A88C99EA-21C86278/0/0
X-purgate-type: clean
X-purgate-size: 10180


--=-zfkTkyTeIpo4gnwF+EUX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2026-08-10 at 13:56 -0700, Sean Christopherson wrote:
> =C2=A0
> > > To allow different offsets, KVM would need to track a per-vCPU offset=
 to the
> > > master clock and apply that in kvm_guest_time_update() (and maybe oth=
er places?).
> > > Which is doable, but it's not clear to me why we'd want to support th=
at (though
> > > I haven't fully processed the back half ot his series, so it's very p=
ossible I'm
> > > missing something obvious).
> >=20
> > Because I want to reduce the number of cases where we have to fall back
> > to non-masterclock mode. Especially the ones which are driven by
> > *guests* rather than weird choices on the VMM's part.
>=20
> But why though?=C2=A0 What is the harm to the host or guest?=C2=A0 E.g. d=
oes it make it more
> difficult to accurately migrate the VM?=C2=A0 I'm not opposed to allowing=
 master-clock
> mode with diverging offsets, just trying to understand why it matters.

Accurate migration without masterclock is hard, yes. The
KVM_SET_CLOCK_GUEST thing relies on it (because the principle is that
you get the *TSC* right, then the KVM clock is just a fixed
mathematical function of that).

That *shouldn't* be difficult with offsets between vCPUs. Just use the
TSC of vCPU0 as the reference for KVM_SET_CLOCK_GUEST and let the
others just have their offset from that.

I'll take another look.


--=-zfkTkyTeIpo4gnwF+EUX
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTAyMTA1MDBaMC8GCSqGSIb3DQEJBDEiBCDGyzf28IxzNQVqwTLbkSt7wGH+znNi
CL7cyxiJFkF6nTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAcJAQV8lArprY4QdX4S70lB2o670kzRmGWlhhV0kL7APeLL1qd7JT
rdLmUaZT5z6m4dn4ASLKJFRBXw8UiZm+Zex1C0He1lRPpv9WwketAuGy3ofwst/gRDpZX5T8LFdd
SjlvSK3Ones17j8U8wwr0X9teLmUlD4Ylh/GONI457BRVvHKLnrHHMOGd3sX7MlpZL6f3MslXJqF
3rDLj10bi6+bsSyxWKlYOq2BIGNQYqfv+VxsWuJxE3a8f/f+MrJIO//qpOzyVbSgszSV/stoG7Ls
O0maR34jfVAJfQ9OIiJTJ0oIgSPuVH6GIQtVvZQ8A5Lchkpq1gs0a8nVW8L95E6ajzNDJ+GBUyGy
5+k7QSoyvVhP8SdxWWnJt8p0hvP8yh2NofC8J8JsDcnP18XnQLue7cw1YNeQ0IPggsYe5A74DVl5
nWtaYMGOYleaSKECZgqPOsGW8+Qky2hDOl99U7AVr+rj5/T+m+mHRGl+2vie6MlMxkORl2UQsD4p
i7ixHIhe2H9xW0OVUkRkKBJPS1NMdAHc75Vis9nGn0LNgUv3MbAE8V0rvODfmGt3ElABEN+Ry5Qd
Ohzfu8zyzgquPXQ0IkUnI1xAaAJPmILp7MAFG9gvnnPs1CwbSTSuk8bMx82DzQMJBdx40OPFSXoH
HoQrwlECdeP8DnxGaGcV018AAAAAAAA=


--=-zfkTkyTeIpo4gnwF+EUX--


From xen-devel-bounces@lists.xenproject.org Mon Aug 10 22:10:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 22:10:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387915.1629149 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtYCc-0003Sq-3D; Mon, 10 Aug 2026 22:10:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387915.1629149; Mon, 10 Aug 2026 22:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtYCb-0003Sj-WB; Mon, 10 Aug 2026 22:10:37 +0000
Received: by outflank-mailman (input) for mailman id 1387915;
 Mon, 10 Aug 2026 22:10:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wtYCZ-0003Sd-SN
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 22:10:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtYCX-00FY55-Ag
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 00:10:33 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7a4c46-8faa-0a2a0a5109dd-0a2a450cba54-30
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 00:10:33 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7a4c59-f479-0a2a450c0019-d155802ded66-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 00:10:33 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49553515a8bso37007495e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 15:10:33 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499740c1f61sm21254325e9.5.2026.08.10.15.10.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2026 15:10:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786399833; x=1787004633; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qJ+Dl9EkivuGED/x2FDHLy1mHCFN96YYc5uGAZKzX8w=;
        b=lUkPremvwM9yA/+xQpUHTgLeo4DZKrLQc+fBtKekqLlAYxMijP+nKoSTfVpuP2HXfM
         Hkn6PWlTVgXgo6VNOYNoGH0hcXK+HdT+CYlTCSjLvm96FJV1if/5gR4aQjeJyvHbjgf6
         bJ96eBvQbk90eKF0o2QnTdaYpBgpxya54pAI8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786399833; x=1787004633;
        h=content-transfer-encoding:content-type:mime-version: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=qJ+Dl9EkivuGED/x2FDHLy1mHCFN96YYc5uGAZKzX8w=;
        b=DQnzONG761Cwm/MR+Y8IU5v5n4bOLs34+LP3eAZoB8Vax7SlpNERPVJNHRXR1M2iyh
         CWuAvY2JA9iWCVrUCs/Ylp+QoKliRmevXAzmqbNwh4QbGyKXuPifchhujtjrVBV/VW57
         B+StFb2xB4XZAgDv8lCaLj5QkWqZ7Xc3LR1qvko3CwZHZj+Yfqjm5nC2Iun9PRfuxqit
         ZToSBxzhtcGtJy36xspyRYX/xadD0D51BFvNfv1sgdHDx2zCahnVYQvhNw7M48mKnHnu
         h1iuo28PzRl9q/BVS3PkH3Zw8UVOO+mKnjJH+9Y0aSy4bcxHgqbp1/fFJ3sZRw9muWya
         4B2Q==
X-Gm-Message-State: AOJu0YyLIiN3A8/psvAFPe1iMjMeLImrxGXEPduur0O4eO+97Uzjwn76
	Vt9njrFdlQ0u6Ji468N8XVFP8+6Pn2JJGRvcN3+AJ6LWg1hCTsZPzU/oDVFiUZgY5Ck+n1ZCW1A
	AU2DCuWQ=
X-Gm-Gg: AR+sD10kTZWlDqr6YiOhpq+hcVHiOTHbtmU5VWTcxjFqt5uo5gF2E9FA+AX0Ozahow0
	HxK0so9vlfl0bfREhBp6shTq51QLikdvTZZ6EHmjQ3NkrKDOHjxBil3hRu2VJeDVSL7N5Nhr/jx
	ANMYAG1JBTU59BICMld/8anNBEQqohRMF0Yn2HUAkQgAdLPJMDvVop18iIAV5/YduisD+iEGsal
	UvANT7pCNnRMSyULT01p4Pc1eJdRnlz5vpXKX6hS8OpdBDXnDjGGE0KwJxW2fqMbRkphmKwVvsO
	GTLLEXoG2qVjOCkJ5hZ2JgRfOd8IV4a0g1PYdFoEDmG56tbDxjeH5JxYzet6GeIrLMsFuo7cQs4
	pc8xAEnwCTgpkzJ71s1kLnlN3+KyohK5MotXgHyNH+db/EJEAwKeNAOpmeoLQnWFxq1mGqXBieR
	Nq5Wx25EU45MjeFyw8p/5eNcO59puUyIrIxhvZtMmq7AeOdVeaeljUKzlXwto92NUu21CQfU5i7
	mpYPDleFDNimvuDUk2gtyyOyY58ZpyWUgBK+aI=
X-Received: by 2002:a05:600c:5795:b0:499:60bf:c6f7 with SMTP id 5b1f17b1804b1-49960bfc7c2mr274411375e9.13.1786399832450;
        Mon, 10 Aug 2026 15:10:32 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/pagewalk: Read guest PTEs with ACCESS_ONCE()
Date: Mon, 10 Aug 2026 23:10:29 +0100
Message-Id: <20260810221029.1520858-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786399833-03ED2A5B-718938D6/0/0
X-purgate-type: clean
X-purgate-size: 4719

This has been a plain C read for as far back as I can trace in history.

Research into invented-loads has flagged it as a possible vulnerability.
After careful analysis, it is believed to be a bug only, not a security
vulnerability.

The code fits the pattern for invented loads, and it is a risk.

The analysis suggests that we can read one value out of the guest, operate on
another, and that this could be an in-guest privliege escalation.  Any entity
in the guest able to modify the pagetables already has full privilege, so
while Xen can potentially malfunction, the effects don't cross a privilege
boundary.

The analysis also suggests that this is worse for shadow guests because we may
put the TOCTOU entry in the shadows, but this is inaccurate.  What we put in
the shadows is still translated under the P2M and refers to guest physical
address space.

Either way, harden the accesses.

Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-ptwalk-RELEASE-4.21.1.md#86-per-candidate-finding
Fixes: 49f7c7364e0a ("Replace shadow pagetable code with shadow2.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

I'm not really sure about the fixes tag.  That's the oldest commit which bares
any reseblence to the current code, and it was a bulk rewrite of the whole
shadow pagetable code.  Prior to that, it was all mixed up and it's not
completely obvious what's (definiely) walking the guest pagetables as opposed
to the shadows.

Bloat-o-meter shows this clearly makes a code-gen difference in all cases:

  add/remove: 0/0 grow/shrink: 1/2 up/down: 16/-19 (-3)
  Function                                     old     new   delta
  guest_walk_tables_2_levels                  1688    1704     +16
  guest_walk_tables_4_levels                  3708    3703      -5
  guest_walk_tables_3_levels                  2233    2219     -14

To start with, l?e_read() looked to be the right helper, but they don't exist
for guest pagetable types, leading to:

arch/x86/mm/guest_walk.c: In function ‘guest_walk_tables_2_levels’:
./arch/x86/include/asm/page.h:135:36: error: incompatible types when assigning to type ‘guest_l2e_t’ from type ‘l2_pgentry_t’
  135 | #define l2e_from_intpte(intpte)    ((l2_pgentry_t) { (intpte_t)(intpte) })
      |                                    ^
---
 xen/arch/x86/mm/guest_walk.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index f48c3ef75f48..df2ccaa67475 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -129,7 +129,7 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain *p2m,
             guest_l4_table_offset(va) * sizeof(gw->l4e);
     if ( !hvmemul_read_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)) )
     {
-        gw->l4e = l4p[guest_l4_table_offset(va)];
+        gw->l4e = (guest_l4e_t){ ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4) };
         hvmemul_write_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e));
     }
     gflags = guest_l4e_get_flags(gw->l4e);
@@ -164,7 +164,7 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain *p2m,
             guest_l3_table_offset(va) * sizeof(gw->l3e);
     if ( !hvmemul_read_cache(v, l3gpa, &gw->l3e, sizeof(gw->l3e)) )
     {
-        gw->l3e = l3p[guest_l3_table_offset(va)];
+        gw->l3e = (guest_l3e_t){ ACCESS_ONCE(l3p[guest_l3_table_offset(va)].l3) };
         hvmemul_write_cache(v, l3gpa, &gw->l3e, sizeof(gw->l3e));
     }
     gflags = guest_l3e_get_flags(gw->l3e);
@@ -264,7 +264,7 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain *p2m,
     l2gpa += guest_l2_table_offset(va) * sizeof(gw->l2e);
     if ( !hvmemul_read_cache(v, l2gpa, &gw->l2e, sizeof(gw->l2e)) )
     {
-        gw->l2e = l2p[guest_l2_table_offset(va)];
+        gw->l2e = (guest_l2e_t){ ACCESS_ONCE(l2p[guest_l2_table_offset(va)].l2) };
         hvmemul_write_cache(v, l2gpa, &gw->l2e, sizeof(gw->l2e));
     }
 
@@ -353,7 +353,7 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain *p2m,
             guest_l1_table_offset(va) * sizeof(gw->l1e);
     if ( !hvmemul_read_cache(v, l1gpa, &gw->l1e, sizeof(gw->l1e)) )
     {
-        gw->l1e = l1p[guest_l1_table_offset(va)];
+        gw->l1e = (guest_l1e_t){ ACCESS_ONCE(l1p[guest_l1_table_offset(va)].l1) };
         hvmemul_write_cache(v, l1gpa, &gw->l1e, sizeof(gw->l1e));
     }
 

base-commit: e888192d133eeec8a94275eaf4194117f198a7e2
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 10 23:05:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Aug 2026 23:05:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387924.1629157 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtZ3b-0003Z2-Tv; Mon, 10 Aug 2026 23:05:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387924.1629157; Mon, 10 Aug 2026 23:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtZ3b-0003Yv-R0; Mon, 10 Aug 2026 23:05:23 +0000
Received: by outflank-mailman (input) for mailman id 1387924;
 Mon, 10 Aug 2026 23:05:22 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wtZ3Z-0003Yp-Tv
 for xen-devel@lists.xenproject.org; Mon, 10 Aug 2026 23:05:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtZ3Y-000xbQ-9i
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 01:05:21 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7a5904-bab6-0a2a0a5309dd-0a2a45098308-14
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 01:05:19 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7a592d-be1a-0a2a45090019-94a38ff16058-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 01:05:18 +0200
Received: from pps.filterd (m0367129.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67AMogSP1811607
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:05:17 GMT
Received: from sa9pr02cu001.outbound.protection.outlook.com
 (mail-southcentralusazon11013053.outbound.protection.outlook.com
 [40.93.196.53])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4fymrs1yay-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 23:05:16 +0000 (GMT)
Received: from BY3PR10CA0028.namprd10.prod.outlook.com (2603:10b6:a03:255::33)
 by LV0PR16MB6940.namprd16.prod.outlook.com (2603:10b6:408:346::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug
 2026 23:05:14 +0000
Received: from SJ1PEPF000026C9.namprd04.prod.outlook.com
 (2603:10b6:a03:255:cafe::34) by BY3PR10CA0028.outlook.office365.com
 (2603:10b6:a03:255::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Mon,
 10 Aug 2026 23:05:13 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 SJ1PEPF000026C9.mail.protection.outlook.com (10.167.244.106) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Mon, 10 Aug 2026 23:05:13 +0000
Received: from pps.filterd (m0426317.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67AMoeMA1320374
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 19:05:13 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkhrj720-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 10 Aug 2026 19:05:13 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id tZ3Owq5eTl3RStZ3PwkwVQ; Mon, 10 Aug 2026 23:05:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=jFi6vT+G3M9XgtperboMkEKVM
	iDctPqboFi4Th2huLY=; b=q/0vVYc1/lUCXIQ6B3VT55FKMnxmRA6/VqdvTCFR3
	XhBfMF1NnIXGGkoMtKq0FmYWa0AQhFoU6A5m15oZznoOxlQxr2xYwA/cyb8xMun4
	0kuoZFNErvWjSOB6SxGsWqtSEZCAFRixwebY58A1dNe8b8m/5FKGtmiqkSPS4X4T
	zFg9Pec5XpHn4F1JQeeYR62HebfKTtMsJwhwCtbHmEN6U/OMKapCjdh0CBAV7wSB
	GWWWY76GtW4jQMQPjzO0OcX9UecC6VGtexDsO+I1FtMjGv/PINzZGn43IV17XYvq
	A7raPYefrXH9vVpMS21Jc5CCEElOdXATapHiWH/E94hvw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CJK4LVYZXNE+jeu8AxTLPM9Eo8FBjGx4fWMU1eHw5lCtNk91o4ITC3KUnblqUKS4YUBlKsb7M10YARtl81K2l/Qejz5bItNc8PdUgjfL6nla/AzRSTNv52cf6SmtPu+HrHQVwxUA02cZeFkbue3AlrCIEFoetZfGaVlg2wS2CQhOpm87B7TnKmTIAYev47E6Lo2I5pvYEf38F5d2iFrJoVk+5DuXdcor8R+ZPaMlI+o8RL3bV5DqCigVLuoYCxqitfnBUXGpe7BtcTsjfRU3kcj48+v1ZPkb5ue90AGktgs/5syhLdqlAP4Txq1n6ag69o/c8xkOErhhZqwzkiVKhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jFi6vT+G3M9XgtperboMkEKVMiDctPqboFi4Th2huLY=;
 b=BkgWCmS5dFtzg/LjBOO2JD1jugSc7hSG6QXRzxtt93ndIT7iPdvPjOEfAoauAbzNv56F+bko2r/zTPgR8ckgPrrVTifvwqjzFEijGr8ICVcz4E/Vug+gTJL6Q4BEjlmU/Zs9soEb9ll0sPuPwXsSCTcikK3/ydAWp+87s4M1f3JBWU/7x1BNb4M3qCEAS9/3Z3Xzxwqom2ZvHI4Cf3mFPndRzzEG08UWDFp1pJczKFSu2GpJeAD6AlyvKUjT6o5VlICbDC/FfPnDkvJ2ToddCjb0tKc6T0wdEcw81URzxTmCgwsowrejaEPU+EiBs5X1x9zweloBnLIUNHJjXaMNcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jFi6vT+G3M9XgtperboMkEKVMiDctPqboFi4Th2huLY=;
 b=lrsHkh3U0YWXqvn4DQ4A+bGMALFlUpq3McldWt6SCiiUsjtOAG3AsPz0UK2NPwqWJoEF2/Xb/h2gatXlIn78bVuGKRCJ4n4HuVOockAw2mzB2I2RVjMIelAHH50/O5S9s/Y7K4wdR55soSc/t63V94xQWb9KdgezkZCxGId7JfM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=jFi6vT+
	G3M9XgtperboMkEKVMiDctPqboFi4Th2huLY=; b=V+VBQ6UIgCo4Uo7dkVS/hTS
	/d88oYYfv8xDkuT6GLYh1m55HjL41ln8MfojgQ4QpQGkUf6G2C2VOvwe9Ds8Xz8/
	Rr8poB9gAL6aYl/k9ezHNYi4l4RnxKScFEpdpvFm2olXLJQhcv5gIwHeFWm/DgNz
	+XSVoG/WRKwas6FcKO+KOGNpbBlEcy5DsDIXugSnajD6G3dfYjnBe+zflc+HmIfc
	Vxi+pRdjOsm9yC+rfOFjN8ofPnQlQTfGvFRS6k/TlGVJe6m5k//2hEG803uLCFQq
	Ah5IEiiMYNeBIODAOllA4hc3fIGkA/MWUCACbVX2aKwKTLF9HGYEBHRpWdqzZcQ=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=jFi6vT+G3M9XgtperboMkEKVMiDctPq
	boFi4Th2huLY=; b=JVzRaU82vKkPHpeV2+yltrENi11ncrXwTdDTALt/fS2cmqx
	S1H2YL9kVHoLNa0HlMkNvPd+v4ssSrNDHe+8L4gYCqZnOJq+LMF8hs4bFNRigMXY
	rPAxhOM82TXl058+pTBqebCl42pqvT9Zbg8MJiTAhreKudF9WmokT1apUvDtXCQb
	vFer2XCCvDfDFAuMsblzlqu7kaRIa9gZn0ZzCeUjLyHm3CUDGlkdy+cM7n8OpsI6
	ol2CL782HJ4qiXR5gNV754rV2i9Szh2fHPazrU9/xlUtm6/RGqbqIELMjXeZjkpb
	fZDiYwbkjgoWltnlkp34fqBY7cIk0QcUMQy/8dQ==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: tZ3Owq5eTl3RStZ3PwkwVQ
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v3] xen/common: add keyhandler to show Xen command line
Date: Mon, 10 Aug 2026 16:04:01 -0700
Message-ID: <20260810230359.671587-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-10_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 spamscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 bulkscore=0
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608100196
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C9:EE_|LV0PR16MB6940:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: c6d0764d-b89f-4265-389f-08def733d5e2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700016|23010399003|82310400026|13003099007|3023799007|11063799006|56012099006|10067099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	vuitvFHZhYrPGf1+gKNrSbzIShxVgKZna+mzKGQGYIcXHZs7TsB4zx5IxB4MScp8CvZms9AtwyRZZZfYgjBhrbsLZfPJ0DhFkF32nqxduB1spWlSzOo9QqV7x3bZpvNAmxH2s6xNMGJb6lfjHBHMZfYLpxzxCUsZum+3gFwiYHOS+OmVjrZt6jvDg6r15m83L3jCnf6G74llYLVih7JxRjfVY1YY1TNY8o5lYFnUswRchPBzNkTjT3p8WU0CFnGVdMLhPLn4RCD+NBfChasTnkaoNi2AeyMQ2+aPAg+UzdZ9V4c5PzWnGNA7EQaQ5mcTcTLepqYRue3geLZTG9D9eLuvoLua7dvHszsYTdl3wFxxRWzwZ2KcPC2lI7xwIVW/5eau2kpb6SDznVTViYzq2tOzl+8D2UVCuoJ+VcoEJeHX7rJrLl9gJasbsHynrV21sD5IPyivVN0cs6DWFeSDh5V1b0j04L1TGCsit9TxQi1Twv6Rtl3duBKIoE3WHiH0nVNj0dz7dqNGAGgrN1G3o8hvZ7mxG5APgEUMh393zsBs14nvV+Yl4J22Edb9XMzKFKNvlqD2+djNSCa6LyDfSYpTzB82PQRhVImTycMX/kyJdtXMipGVSX3eQ8zpZWW1/Mja4af5w8kNuzfES3D9dWdHa7+DmwqkD83gHx26oKh/B8JZAtnJWkIRl07LnGdEo7yy0TmE2CN7zr1zie/e8g==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700016)(23010399003)(82310400026)(13003099007)(3023799007)(11063799006)(56012099006)(10067099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Xh2/dIp+cg1QUh7LAvgK/vF8c0wXH3uVnvhmsv6ZL4mYTU4cAALOefwqtoJT+v5UXGgpQx/3KSX8hp76+8T8oZEfrBcOev6e5XnK/N0BkV9m30HBQ6bBVAyHQIibfZvmRcHf5m1AaCwz1LQS1V8vJqqkauW8meEMG1pAYOEX1E/JdPLOcPf7HzlGnCZ57y12wa9nZONCMQxAm6/9f6ewNm7RPtjqJ/d4eNN3iq5At3NwZiiLeobiipsh8oP9gou8JOLbaD8mXd/786qOzSuhhipwcAzBOnZsggdRaS0/aX0t5k5tqIbGzHNPdGyfaXYyrvrapH+F8+63o1yLN8qX17E6cfnSbgBG9hVNcgVdSbdQf2sGhOff4E0W+alNuLaxA+Ui8ZXj5ofR2oRvjBH73IxXdGbyyhgI5fnj2iW9mBVnCxfDt6d9L7Nsb1ObXYyJ
X-Exchange-RoutingPolicyChecked:
	JMfoK9UkcLjYp2xyCV+YTmMGvu3Up/iWDD+e/3aSnUbsFowLEiZmU6gtemLPVbD1QCE9Z7iHTyl83QZrScprSaatpKkyQnVde3gnT2Bi9oMGytUzGszN14iUnsXxsSrQ7dfOMCaWhlzzJRj5UkSBmtBgTI/+3DJMiyog1qEalbM5/4k6bjmUeWY4d3BavRPL+evw8OAnnhl2hkoaSvfZ80FcGlXZjV8KWEcAeDejsU3VGfUSIeW/2Cxm2Jr2gngTetoF2B6V59eRUSqOdhvDionxtudwWpbh1Lbb7XlQVvFDXYc5epMnZrw02hKFTdT61b7gBNoGaI6GKOikjOdyXA==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	ZUIRppqxaCimA3oxTWYXsXczfbFaMpF4092OkTF6pDdZFVSAAL2ZSYpE3v6k7kdRxT+0bJwzx1rsPPDzPmz7z12ES89qAxelSBojfOXEWCRel54h4cKmCmt3uIWdmBHj6kjue1GEwQIrw0m/cCocItzInE2OsNenq5Vkqe5StjOk7E+6RgbZlcqF6wj4tqhuM0xo+3fK/3SUKmXBb7J6WLSJ+nG287bc4StN4xyiGIRV4qiO9zMY67rYkH9nwFXNSbqbZTLrRaDzh89afnUSFy9vsuAUyW6OMtDvMZIiFWoTI7GzY0jkyfV9KyPywBb9G5/gdURmobjd94BS3cbCsIFMU2Ypt08OZ/M7Yg49P60niqHUJdsuYsJp9zD6H1WVEmTb0A+1OnyLK9zYhK0tiCS8BLdFV7k2Kedvk4pzLbmsk6wsqxUn0iZYNvJR2KWWJCdUvm038DNGXJXsVgIM2lFb9znay+vHEvP564WH/Uc8tm0A5K+VZVIcD6gnYWoiyxbhrzmyiw/ouhq9x83G/w79WTs0i76E+bT5TJpboOx6IvCkpNu+soYfF0BIcZ6KcKcNXc0Z1UjwGit1g2yVGq8BM7/klyhLPKj5+lf8+sqqCH/JSoFFBfHqnL764yFoWOS/RitF7RFQpY/+feR3Nw==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 23:05:13.6425
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c6d0764d-b89f-4265-389f-08def733d5e2
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000026C9.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV0PR16MB6940
X-Authority-Analysis: v=2.4 cv=NtbhtcdJ c=1 sm=1 tr=0 ts=6a7a592c cx=c_pps
 a=5zjvB78PlnLPEzvzEo0MXg==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=X3KReqg2EL6A36SYCKpz:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=IgJ0wlFFhhnA7GDi3u4A:9
 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-ORIG-GUID: cRh6SSY4zNNWz4sP3tox7hMakk_HzU5p
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEwMDE5NiBTYWx0ZWRfX4bkUozXC1RCu
 EqKkQt18PKdj/Iwu1iVuwMcbsrKzGsW802GcxTvM4l8jKz1SNfEvvj9kvWjpv7e948qtjOjphdW
 rRbVvLzsJpNnNSqBFV2scu1w41sR55RdJV7rbN1W6E+bT96VYJ7t
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEwMDE5NiBTYWx0ZWRfX3UvjMoyS0g6u
 4Bl82loIoDqYwcGZgih2vFYmEsQ+HAOrUNKk0YCw6llVdsJOG7BsylcV8/6ya3EpewQfenYxY6e
 6seyXINwnmPrg+OvmFLHGBUdELjiKAI6tUYlXOggpw151aIMJtv/5ggnts7uNqrh9SXDBdIrcyA
 EXCzGPvauYa+NgA+8zei8BTQ2UI7n46eDueBSwX67NTIRxyhO8soAzcnhYo31PPKgd9MWaHOoh1
 WeBNJSxeDWBgfCbxbWXgmK7pFD1UFJcKUq/nI1W5d1xHJdlr/24CNcVde+MjNitS15AlxFkmaFd
 OeWqqjShLA9sGWJp12eElmU5Izlyo9YzraIY9E5dYcurcYiIUK9t9CoJvy1HRgyX33Jb+hOcPrh
 nW2vip5oHJjJ1Hl9sdydKvcgYl039bGLAKhVJ5e4iGr9ukRn88tg2PqL2FBYdE0ZjXkxSMUu/LZ
 JyDE2SHxyL8r1fTC0+g==
X-Proofpoint-GUID: cRh6SSY4zNNWz4sP3tox7hMakk_HzU5p
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-10_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 adultscore=0 suspectscore=0 bulkscore=0 impostorscore=0
 phishscore=0 clxscore=1015 spamscore=0 priorityscore=1501 malwarescore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608100196
X-purgate-ID: tlsNG-bad1c0/1786403119-BECDF034-E28B115F/0/0
X-purgate-type: clean
X-purgate-size: 1712

From: Denis Mukhin <dmukhin@ford.com> 

Currently there's no way to print Xen command line on the emergency
console for debugging purposes when 'xl' is not unavailable.

Add new keyhander 'X' to do command line printout.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v2:
- account for CONFIG_CMDLINE_OVERRIDE case
- use IS_ENABLED()

v2: https://lore.kernel.org/xen-devel/20260803070047.3097846-3-dmukhin@ford.com/
CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2748655201
---
 xen/common/kernel.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d1bef9ac2b2b..54a7ee6f68e5 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -5,6 +5,7 @@
  */
 
 #include <xen/init.h>
+#include <xen/keyhandler.h>
 #include <xen/lib.h>
 #include <xen/errno.h>
 #include <xen/param.h>
@@ -505,6 +506,25 @@ static int __init cf_check param_init(void)
 __initcall(param_init);
 #endif
 
+static void cf_check show_hypervisor_info(unsigned char key)
+{
+    printk("'%c' pressed -> showing hypervisor information\n", key);
+
+    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
+        printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");
+    else
+        printk("Command line: %s\n", saved_cmdline);
+}
+
+static int __init cf_check misc_init(void)
+{
+    register_keyhandler('X', show_hypervisor_info,
+                        "show hypervisor information", 0);
+
+    return 0;
+}
+__initcall(misc_init);
+
 static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xen_varbuf user_str;
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 02:36:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 02:36:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387940.1629167 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtcLd-0000Dl-2l; Tue, 11 Aug 2026 02:36:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387940.1629167; Tue, 11 Aug 2026 02:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtcLc-0000Dd-Tt; Tue, 11 Aug 2026 02:36:12 +0000
Received: by outflank-mailman (input) for mailman id 1387940;
 Tue, 11 Aug 2026 02:36:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ehem@m5p.com>) id 1wtcLa-0000DX-ST
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 02:36:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtcLZ-007ag9-ID; Tue, 11 Aug 2026 04:36:09 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ehem@m5p.com>)
 id 6a7a8a77-bab6-0a2a0a5309dd-0a2a4506c15a-20
 for <multiple-recipients>; Tue, 11 Aug 2026 04:36:09 +0200
Received: from [74.104.188.4] (helo=mailhost.m5p.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ehem@m5p.com>)
 id 6a7a8a97-195a-0a2a45060019-4a68bc04abf2-3
 for <multiple-recipients>; Tue, 11 Aug 2026 04:36:08 +0200
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
 by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 67B2ZxfO029994
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Mon, 10 Aug 2026 22:36:04 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.18.1/8.15.2/Submit) id 67B2ZxqK029993;
 Mon, 10 Aug 2026 19:35:59 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Date: Mon, 10 Aug 2026 19:35:59 -0700
From: Elliott Mitchell <ehem+xen@m5p.com>
To: Cody Zuschlag <cody.zuschlag@xenproject.org>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [ANNOUNCE] - Call for agenda items for August 6 Xen Community
 Call @ 15:00 UTC
Message-ID: <anqKjwU93bMcttNz@mattapan.m5p.com>
References: <CAJbE=KznNsrNRN=pUaDj7-TVW4uCMVBdrPpei_z5nBdjdHnVag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJbE=KznNsrNRN=pUaDj7-TVW4uCMVBdrPpei_z5nBdjdHnVag@mail.gmail.com>
X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS,
	T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no
	version=4.0.2
X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com
X-purgate-ID: tlsNG-16d1c6/1786415769-FDE0E77B-5E2881C8/0/0
X-purgate-type: clean
X-purgate-size: 4863

On Tue, Aug 04, 2026 at 05:30:50PM +0200, Cody Zuschlag wrote:
> *Preparation*
> 
> 👉 Please take a few minutes to review and update the agenda before the
> call:
> 
> https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/
> 
> Feel free to:
> - Add topics or project updates
> - Suggest anything we can drop or defer
> - Include links to patches, mailing list threads, or documentation where
> helpful
> 
> The agenda also includes the meeting link and a link to find your local
> meeting time.
> 
> 
> *Call Details*
> Date: Thursday, 6 August 2026
> Time: 15:00 UTC (agenda starts at 15:05 UTC)
> Join: https://meet.jit.si/XenProjectCommunityCall
> 
> We'll open the room at 15:00 UTC and begin the agenda at 15:05 UTC to give
> everyone a few minutes to join.


Took me a bit of time to consider what had been said in order to come up
with next responses.

I didn't emphasize it during the community call, but the point was
explicit in the most recent posted message:

https://lore.kernel.org/xen-devel/ajr0gN9kmPkLQlGF@mattapan.m5p.com/T/

This was previously allowed by Xen/ARM.  This turned into a bug when the
Xen/ARM team decided to disallow multiple mappings of the shared
information page.  During approval the Xen/ARM team was explicitly asked
to accept the task of updating outside projects to deal with fall-out.

I don't recall the exact wording of the agreement, but this is certainly
fall-out from that change.  As such this IS an adjustment the Xen/ARM
team agreed to aid.

I've already generated a PoC, I had thought the Xen/ARM team would be
better acquainted with whom to ask about getting a patch along those
lines in.  That seems a reasonable ask in light of the team having
accepted the task.



I don't know the Xen developers by voice.  As such I don't know who
mentioned 'firmware = "ovmf"' when I was trying to bring up
Tianocore/EDK2 as bootloader.  Now that I've checked by notes, whomever
brought that up was quite unfamiliar with that I was trying to bring up.

The 'firmware = "ovmf"' setting is part of HVM domain configuration.  In
this environment Tianocore/EDK2 is merely setting up some ACPI tables and
then handling the task of finding and invoking the OS bootloader.  Since
all the hardware is emulated, Tianocore/EDK2-firmware isn't much
different from what it normally does.  I should also note this is fairly
slow.

Despite sharing the codebase, Tianocore/EDK2 as bootloader is very
different from being HVM firmware.  In particular the arm64
Tianocore/EDK2 configuration is "ArmVirtPkg/ArmVirtXen.dsc" and the build
creates the file "XEN_EFI.fd".  Once built the domain configuration is
along the lines of:

type = "pvh"
name = "somename"
kernel = "XEN_EFI.fd"
memory = 256
vcpus = 2
vif = [ "somenet" ]
disk = [ "somedisk" ]

The result is a PVH domain with Tianocore/EDK2 functioning as a pure
bootloader.  In particular it is capable of searching for its preferred
filesystem, then looking for an appropriate filename and then loading
that using the UEFI protocol.  The result is near-ideal.

Of note I'm pretty sure Tianocore/EDK2-bootloader would happily load
EFI-GRUB.  More importantly though OS bootloaders which can handle UEFI
work perfectly in this setup.  I expect this to be superior for *BSD.

There are two problems with Tianocore/EDK2-bootloader though.  First, is
the aforementioned unresolved bug.  Second, this is only implemented for
aarch64 (arm64).

This is a problem for all the paravirtualized bootloaders.  They're all
single-architecture, despite the bootloader supporting multiple
architectures.  On that single-architecture they're quite good, but Xen
really needs them on *all* their architectures.


I didn't get the chance to finish my suggestion during the call, so here
is what I wanted to suggest:

I think the Xen Project really needs some effort aimed at the
paravirtualized bootloaders.  Mostly making them operable on all
architectures they support.

Paravirtualized GRUB is needed for ARM, RISC-V and PowerPC.

I don't believe Tianocore/EDK2 supports PowerPC, but I would really hope
for it to become available for RISC-V and x86.

While U-Boot is difficult to deal with, it would be valuable as a second
paravirtualized bootloader for PowerPC.

Once those 3 were available on their applicable architecture it would be
time to purge PyGRUB.  While I imagine this will take a while I think it
should be on the roadmap/panciled in for the future.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Tue Aug 11 07:06:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 07:06:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387957.1629176 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtgZ4-0003NO-7k; Tue, 11 Aug 2026 07:06:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387957.1629176; Tue, 11 Aug 2026 07:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtgZ4-0003NH-4s; Tue, 11 Aug 2026 07:06:22 +0000
Received: by outflank-mailman (input) for mailman id 1387957;
 Tue, 11 Aug 2026 07:06:20 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wtgZ2-0003NB-8n
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 07:06:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtgZ1-00GoLI-LG
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 09:06:19 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7ac9ea-8faa-0a2a0a5109dd-0a2a4503ab66-8
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 09:06:19 +0200
Received: from [52.101.85.7]
 (helo=BYAPR05CU005.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7ac9e9-fae8-0a2a45030019-346555072a89-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 09:06:18 +0200
Received: from MW4PR03CA0314.namprd03.prod.outlook.com (2603:10b6:303:dd::19)
 by IA4PR12MB9788.namprd12.prod.outlook.com (2603:10b6:208:5d5::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 07:06:13 +0000
Received: from MWH0EPF000C6195.namprd02.prod.outlook.com
 (2603:10b6:303:dd:cafe::7b) by MW4PR03CA0314.outlook.office365.com
 (2603:10b6:303:dd::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Tue,
 11 Aug 2026 07:06:13 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 MWH0EPF000C6195.mail.protection.outlook.com (10.167.249.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Tue, 11 Aug 2026 07:06:13 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 02:06:12 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 02:06:12 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 11 Aug 2026 02:06:11 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kn/M62Z4hW5SAd84ScCcd2mugKjCR8r/W5s4p4k/MV3FwgqWbCezbcFj4ZohgUKKJWDu2yCSKa7xMoJqN2IlXgcTeqFPoM7mnfuO6iHt3FPJHaYYEdCxhe6R0FOX4RFAu4THGXS+NYHb3X0VRb1YkwHFIAmg3cFDB8ns0mYemUjXoA8/3McfzakOOChqXaCRRZ/0u7inKdfFb/To6qVc7/KnMki3IHhG+tuDizhJ7uoX+29sfILNeApSgWXeeLTJqwjuHdQUT5CQKmT9lwks1W7Y8CxaZEVhqXTShRP0sdLmCZv1hKCXqKHc2qAi4atYZhMHXp1wL8BR3ghfNHQbUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=u7Z9+tFRgouVypaJqTuXKRlijZUwRSBavXXjWIWJZOY=;
 b=CzlPH4W5NqDYzZ5/o/N6RuqSIfRBjuhSdFtiyzOzBxcXMgH8mL3fu6BqP9WVG1JgNpq3LVMtdidZNEX6EmcqPRkJzNUl6u54U6W9PPwJqEmAwY+BEIMepk/YSUlj5m9m95CqQBQXWzIIsUJ8Z41jVCiA923vcyVoC35acFatY9eGFPCsEXCf7rSZImuORuHDyz+ZHf4v3J0G7cYI6vpEIZjYyN0417reFQ1FOeT5YPqrCHtM4qF7hNJx2gFPFOKqIL+6alfAga28tnY/vj/dff6YDcPFomEts4zRPu90i0Zm0FR5LyoNNMO1n60OFTzOm4Q91mZgFAypmQ1XziFH7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=u7Z9+tFRgouVypaJqTuXKRlijZUwRSBavXXjWIWJZOY=;
 b=1cjzDSdlscDdBbNBkZ6fvCi9GSUpD5ti44X3VgJZUoEJoRTExsGcL6KAM/qjTEz5b59LURLQinz/SdTmWC5g3ktOlHQ5C+QamcUOBKRrml95ka9qzsaLjmbLbCYgMhRqc7C142gu1mtWnNGs7EBM5V0g1bpZWzRvQ1LhDNm8ij8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <fbc1a296-1e27-4b9d-a37d-47fde4f91c75@amd.com>
Date: Tue, 11 Aug 2026 09:06:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: propagate secondary GIC initialization
 failures
To: Mykola Kvach <mykola_kvach@epam.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>
References: <58b886c992ea72210bb2f32afc392b458efe02f2.1786389451.git.mykola_kvach@epam.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <58b886c992ea72210bb2f32afc392b458efe02f2.1786389451.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000C6195:EE_|IA4PR12MB9788:EE_
X-MS-Office365-Filtering-Correlation-Id: 6bfb14eb-5aac-4d45-8cec-08def777076d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700016|23010399003|1800799024|376014|18002099003|22082099003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	uZTK9wqNnq830Nm3oNLMLg73PLtVOOTFezns9QsgDg+TP5OuB/eIKiXFlALSnKw+8I+TXHXwnHxXdDaaKfnxfQfCW28bi534x9a6zfDusFiPprFBKXMlOv76+QUnj07Qgk9R5YJy24MomIwUglBm4W5Oj8XJ2uY7finJkevAO4BKxALG07EUyVnALkwOTWcubn1PMk+Utm8Zm+equX6g0oXRVjN04r58Mtb5cZlWO3SgtL82qS7cYaXOyZMVKWNzJ5tTbf0krLLmFEybAUsofltVrrgDxe8judbCAGyBHxOBzyqDDUGftPx/VbpzqvRrCxJGipEmRz4XFa0MKc6A8IvTQka2YkKMXHARrGXsvNnr3oexQM4YhFLkbvNQImTbZMZ4QAEQtdOczIn92/gRXrPtxHt+6acIIl3auRut88EODlX7d3nilR7HgExbEQsR6jbXu+zQ+BG86l4iWxldIjgqWBDfVCUwULqEdyGQbJ/KdkYOiE4AsgrVxJI9TBlqQbhZs7KtbhXKkF88Pugk+x61ZOfgLk/astv/8HOrekPaa8voRAvYIoWKMJFx1aOja1q2LoLm7Jsl3MPxIoISAtdhXLP0jNHLuKRh7YM2ZcYrtfNgdhXqQoSxYiOEMXfYmMnnzqzRODP1h5aFdqtD0hebCLuYB5yqWraSfR5x3ZnhOWcOno01yWb6x0JmeLn2JV8E55xrDyvhF4DKLWSCyQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(23010399003)(1800799024)(376014)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	lnwOEEVqIo1uo2pYae/lbgFiFl5km/m4YiIXPVUO6u2zEnaVpkondIxTF0MGjOd5JcygKA0PwfE4Wwkv9ZKULt6+TxAI7Sa3S8kJp/FUQPtZwgDD01ZUJ9X6UqRI6ZSXJfM0ZvQ0WPTzW7nk4D3UVjvqMEG6BHAR3qMzLZ8uH6yRCpmEnVX64O9mIi5n6S+6tjrenXZ8mW1c7sbxlP4DPJ932cbypY9AtxyV2cNzZAmQENnevoWIpA1ZjwAyDX9BSjUEqgyv9uVFEnDB+ednRCwRetoHmRsdTA4QEzkHn069sGHwe1AFSEMagS0Z8zgXK0LIORxyMRO1XjJh5OLDGuc0JT51tXFj4cfSUlZtMkhLZnNY7rO29ADjUR2nGTF9AI1NYQkcRFiHZYqdyoAap/rnUJ4reRNabnGQFB2QQa22BIeOAPVMJz4iAkaGfjNE
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 07:06:13.0212
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6bfb14eb-5aac-4d45-8cec-08def777076d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000C6195.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR12MB9788
X-purgate-ID: tlsNG-33051d/1786431979-6F8C54E9-DC663110/0/0
X-purgate-type: clean
X-purgate-size: 738



On 10-Aug-26 21:41, Mykola Kvach wrote:
> The GICv3 secondary_init() callback can fail while discovering or
> waking a Redistributor, enabling LPIs, or setting up an ITS collection.
> gic_init_secondary_cpu() currently discards that status. start_secondary()
> then marks the CPU online even though its per-CPU GIC interface may be
> unusable.
> 
> Return the callback status through the common GIC layer. Have
> start_secondary() report the failure and stop the affected CPU before it
> updates system features or is added to cpu_online_map.
> 
> Fixes: bc183a0235e0 ("xen/arm: Add support for GIC v3")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 07:48:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 07:48:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387979.1629191 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthDd-00012u-C4; Tue, 11 Aug 2026 07:48:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387979.1629191; Tue, 11 Aug 2026 07:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthDd-00012n-7q; Tue, 11 Aug 2026 07:48:17 +0000
Received: by outflank-mailman (input) for mailman id 1387979;
 Tue, 11 Aug 2026 07:48:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wthDc-00012h-Az
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 07:48:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wthDb-00GI3u-0k;
 Tue, 11 Aug 2026 07:48:14 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wthDa-008A7l-1z;
 Tue, 11 Aug 2026 07:48:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=oXJmNSnU5V7rY/kwedMvqgDw8RAbb8RVEHCCWmM35dg=; b=CvBJMdBsShf/vPkbA7cJP2207t
	qm+6ImerU8RBj+fesqRwM9s0M+rjnlNTA+sLV+KiryUKauBTkYLdTw5IiOISYry8vFEOjwzS8mDJK
	vFhBD+Iil3Zgur+7MEq5Ufq5SL8Saaer32nOAFYtT+o6XhOTed8XxdYQRVRJPnRaKUt0=;
Date: Tue, 11 Aug 2026 09:48:05 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org
Subject: Re: [PATCH v4 2/2] xen/console: add compile-time rate-limiting
 controls
Message-ID: <anrTtS1LKOVbvFwl@macbook.local>
References: <20260729072520.1556970-1-dmukhin@ford.com>
 <20260729072520.1556970-3-dmukhin@ford.com>
 <annMNjOodiS3hHp7@macbook.local>
 <annM2322Ig23p4RG@Mac.lan>
 <anoQv9sWca/mLWQR@kraken>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <anoQv9sWca/mLWQR@kraken>

On Mon, Aug 10, 2026 at 10:56:15AM -0700, dmukhin@ford.com wrote:
> On Mon, Aug 10, 2026 at 03:06:35PM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 29, 2026 at 12:25:20AM -0700, dmukhin@ford.com wrote:
> > > From: Denis Mukhin <dmukhin@ford.com> 
> > > 
> > > Introduce CONFIG_PRINTK_RATELIMIT_MS and CONFIG_PRINTK_RATELIMIT_BURST
> > > for configuring rate-limiting policy at the compile time.
> > > 
> > > Use symbols for global rate-limiting initialization in the console driver.
> > > 
> > > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > > ---
> > > Changes since v3:
> > > - added note on security support for non-standard configurations
> > > - gated menu with EXPERT
> > > 
> > > I kept both settings for now.
> > > ---
> > >  xen/common/Kconfig         | 36 ++++++++++++++++++++++++++++++++++++
> > >  xen/drivers/char/console.c |  6 ++++--
> > >  2 files changed, 40 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > > index da80fdba8469..749d3bfb08e0 100644
> > > --- a/xen/common/Kconfig
> > > +++ b/xen/common/Kconfig
> > > @@ -672,4 +672,40 @@ config PM_STATS
> > >  	  Enable collection of performance management statistics to aid in
> > >  	  analyzing and tuning power/performance characteristics of the system
> > >  
> > > +menu "Console rate-limiting"
> > > +	visible if EXPERT
> > 
> > No strong opinion, but there's a drivers/char/Kconfig which might be a
> > more natural place for those option to live, and then there's no
> > reason for the extra menu?
> 
> I had the knob initially in drivers/char/Kconfig, but moved to
> common/Kconfig to address Jan's feedback:
> 
>   https://lore.kernel.org/xen-devel/2eba7de1-a8e2-4c45-affb-8ecb91278707@suse.com/

OK, as I said, I don't have a strong opinion.  I think we want to keep
drivers/char/Kconfig for console driver specific options, but not
generic console related parameters.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 07:51:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 07:51:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387986.1629199 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthH9-0002cB-Pz; Tue, 11 Aug 2026 07:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387986.1629199; Tue, 11 Aug 2026 07:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthH9-0002c4-Mq; Tue, 11 Aug 2026 07:51:55 +0000
Received: by outflank-mailman (input) for mailman id 1387986;
 Tue, 11 Aug 2026 07:51:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wthH7-0002bw-Po
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 07:51:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wthH6-00ABx2-OW
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 09:51:52 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7ad48c-e002-0a2a0a5209dd-0a2a4507dee8-34
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 09:51:52 +0200
Received: from [40.107.208.22]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7ad496-b4ea-0a2a45070019-286bd016a725-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 09:51:52 +0200
Received: from DS7PR05CA0064.namprd05.prod.outlook.com (2603:10b6:8:57::26) by
 DS7PR12MB9042.namprd12.prod.outlook.com (2603:10b6:8:ed::14) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.292.25; Tue, 11 Aug 2026 07:51:46 +0000
Received: from CY4PEPF0000E9DB.namprd05.prod.outlook.com
 (2603:10b6:8:57:cafe::89) by DS7PR05CA0064.outlook.office365.com
 (2603:10b6:8:57::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Tue,
 11 Aug 2026 07:51:46 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CY4PEPF0000E9DB.mail.protection.outlook.com (10.167.241.74) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Tue, 11 Aug 2026 07:51:46 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 02:51:45 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 02:51:45 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 11 Aug 2026 02:51:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hAGpHAicgx35TO2oCJekulLCgmf/wFMsEfVlioh0qmPkh+gy8ebIOv156gtxE9r8Qw6PygByrUet6TmaU8r/+dZ3s7kVEjLI7GLCfVwjbn16XGK87QsrmSVAa9xLWIQu0sa+MlHHh0gXhipvHeL3mqty1Ufvw1cuIOESiR6TlntR0xlaixuO3snAaS/PptnTsMxvYZUUl9vgn0LGzzgJPepatYvdqozPJKBFy18G/CeGkR9nhQf1t1tSKgAJGsS2xSs/Dyp5nEbZxMrH2S+V7qgReN92leKjOlL+Q1AgUP2wr56ShZyxBlJXog6J1GCnh38337vg8MoOedGlFQJNzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6KvQQPPl6ZqEavxPRXLTuVqBYEjVIkVXiIWArdy3D80=;
 b=vxGwvWmVLcJhR8+XDZWUAryNEpvs67JSfpjnCjWh4DNRRXs+kcGtgZULAofXgl9SqzQTTgb/je9+QWHUUBgJnRFZXT5BVByvncidBraIzOoGiqZsIK45A6n0dR0dYd0KbrVWQLCKMSfmMDWl/Ay/kf+7wujWBNjlRM09T0sm0I5bruYtGA9AySpaHPcerEc3TU0aQYBjv+EHFTuF2RVmkmrAjmuCLj0dfIvgv0r8/IEhdtrmqlkAQKm+yyvVOjfs7J4Rwy0ho3P9c6WpW0jESp6SUOYkGeaaoX7EJ/MC2nrP4BXYj7YLxC6ufB0deicRYR+9qPOks2L3Mlse5TojaA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6KvQQPPl6ZqEavxPRXLTuVqBYEjVIkVXiIWArdy3D80=;
 b=eRYeanvpcLBJIafRtA0qwjh9CK5N3s/lEj90cWpflmtCI/GBgsMJ5mJY9J5SB7rpcdZLCUN4jsaDnqI0gEd1heaOI2Oy/y1dPImZl9DiaoWzBaR/U1+DwV8VRzQcbPU1Qbn0c0CfeF6thG3Nvlxd0MbCgMEb07Yf1/05P3AO0qo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <103a2e50-0391-4bad-b9e7-d00c36c76a54@amd.com>
Date: Tue, 11 Aug 2026 09:51:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: derive GIC CPU interface ID fields from the
 vGIC
To: Mykola Kvach <mykola_kvach@epam.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>
References: <f46f9e6ebb12d8402fa72b1641796f33e24c539f.1786395761.git.mykola_kvach@epam.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <f46f9e6ebb12d8402fa72b1641796f33e24c539f.1786395761.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9DB:EE_|DS7PR12MB9042:EE_
X-MS-Office365-Filtering-Correlation-Id: 738f86e0-adbc-487b-f280-08def77d64b9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|23010399003|36860700016|22082099003|18002099003|5023799004|11063799006|56012099006|10067099003|6133799003;
X-Microsoft-Antispam-Message-Info:
	mP+vpBqCkBJTfalQ8sZaDuLbemAnVXvf5UvtFMzblCl4tp43cylYiklOJnKlPTtR0s2eC2J02+bnUi0MyZnFpe+oWDkTZwEO5PYhyS6+5qLeJqG8Z7weiX1XymH4ngeXFJ2/IOQwgdGcgpRckhCGFIIjrqx2uPc/Ckl0ACIr2GRQ7EGE6LxCO3h6ZhtmZzGE6xHQ35EbTmjd3/EFlGNMJAELo3fonZSKiJ/Z5jpQXvqPe6T/H+Oc27JcIFpoQgFSZlUXFAe11COm+nVYvEXysTw1Zt7sG3C/TmUWLykhi9pA+BTDuRmRxX92wJsAnKQqNfzD1Yx5yJBZ9Nil2FiCNGyJRsVZtQ/U2MzgRl5hBRuXzxP29PoxOXnyaAra5UGr3u874OKA70BoW+DLXvPJncvJlgfSlzqyS/Xk/tfms91w00um0uO0PfwUqbJS9tSjeE8iEAm4jN5JpYtwL9js5fOCmksiX7KcMJ5QCf44Yf4NdtlITYH67MyDVQdEeFpqiS1GTCL3vKVixcWNvxxPgDom/J7G4NE9NWw4ybUBoblMnFiKMCkw7G0UyB8uOfcsOhYvuth3lcYaopt7CG9nMkH01YsbxpZf3mo638c+d7T5IS9Hu837uVHEPqH9fdrVb3hKfVNtpDB4Klv7zvpziw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(23010399003)(36860700016)(22082099003)(18002099003)(5023799004)(11063799006)(56012099006)(10067099003)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	HZijFR9DwWWtItdqM+YSi7OVpkPvphzzFaDr7YR05aP1hjtr8ZDZkskxgw/w7asGmp6OVk2EhO4xJBUoOixi5ojg+rqkY2U/2oBnDpYfMHOEy3mYLg2JJR+k10t/RmEy8QdRBAMqPMvXFcEnKf9rDM1WOwa7SYshRbMCKXUvxrcza3bKkX1sqyYxnwHx4SBOWmaXClIRLSegZWKbLy3vr7GJtclp2EyZKT11vw8yoal9xeqDQprTVdGkDhbXokXhYGAQ6N5bHPX/OGi8tzFMDvroEvE39combWn4izX2+4Udu8VQA/WCuy7/RQyJ5m4Blyx322p6/0pohRFgnNOh+xkw2tB/3eAAaRws0RzDJ0TYulRxMjZD448uaAQo98asvj8/hnuSvyLruyvbOo/tTcoOEnwbZ+cjpINWnhVovMa0tTC63jkn5+ZFMTvPKhCT
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 07:51:46.5181
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 738f86e0-adbc-487b-f280-08def77d64b9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9DB.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9042
X-purgate-ID: tlsNG-ef75cf/1786434712-A46CAAE4-4D7E4F1F/0/0
X-purgate-type: clean
X-purgate-size: 6851



On 10-Aug-26 23:12, Mykola Kvach wrote:
> Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo,
> which is initialized from the sanitized host CPU feature state. This
> does not necessarily match the virtual interrupt controller configured
> for a domain.
> 
> A vGICv2 domain can therefore observe a nonzero GIC field when the host
> supports the GIC system register interface, even though Xen disables that
> interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can
> observe encoding 0b0011, although Xen exposes only its vGICv3 model.
> 
> Derive the fields from the domain's vGIC version instead. Expose 0b0000
> for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the
> ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through
> CP15 in AArch32 state. Leave the alias unchanged when AArch32 is
> unavailable.
> 
> Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
> Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v2:
> - Share the GIC ID field helpers between the AArch64 and AArch32 paths.
> - Parenthesize the individual ASSERT conditions.
> - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable.
> - Target master instead of the 4.22 release.
> 
> v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/
> ---
>  xen/arch/arm/arm64/vsysreg.c    | 18 +++++++++++++++++-
>  xen/arch/arm/include/asm/vreg.h | 20 ++++++++++++++++++++
>  xen/arch/arm/vcpreg.c           | 15 ++++++++++++++-
>  3 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index d14258290f..a02ad951f9 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -21,6 +21,7 @@
>  #include <asm/arm64/cpufeature.h>
>  #include <asm/arm64/sve.h>
>  #include <asm/current.h>
> +#include <asm/gic.h>
Stale include? Nothing references gic.h here anymore.

>  #include <asm/regs.h>
>  #include <asm/traps.h>
>  #include <asm/vreg.h>
> @@ -304,7 +305,18 @@ void do_sysreg(struct cpu_user_regs *regs,
>       * to identify the processor features
>       */
>      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
> -    GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
> +    case HSR_SYSREG_ID_PFR1_EL1:
> +    {
> +        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
> +
> +        if ( cpu_feature64_has_el0_32(&domain_cpuinfo) )
> +            guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> +                                                   ID_PFR1_GIC_SHIFT,
> +                                                   v->domain);
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  guest_reg_value);
> +    }
>      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
>      GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
>      GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
> @@ -343,6 +355,10 @@ void do_sysreg(struct cpu_user_regs *regs,
>              guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask;
>          }
>  
> +        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> +                                               ID_AA64PFR0_GIC_SHIFT,
> +                                               v->domain);
> +
>          return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
>                                    guest_reg_value);
>      }
> diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
> index 387ce76e7e..24735aaea1 100644
> --- a/xen/arch/arm/include/asm/vreg.h
> +++ b/xen/arch/arm/include/asm/vreg.h
> @@ -9,6 +9,26 @@ typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
>  typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r,
>                                     bool read);
>  
> +#define ID_REG_GIC_WIDTH 4
> +
> +static inline unsigned int vgic_id_gic_field(const struct domain *d)
> +{
> +    ASSERT((d->arch.vgic.version == GIC_V2) ||
> +           (d->arch.vgic.version == GIC_V3));
> +
> +    return d->arch.vgic.version == GIC_V3;
> +}
> +
> +static inline register_t id_reg_set_gic_field(register_t val,
> +                                               unsigned int shift,
> +                                               const struct domain *d)
These two are incorrectly indented (off by one to the right).

> +{
> +    register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift);
> +
> +    return (val & ~mask) |
> +           ((register_t)vgic_id_gic_field(d) << shift);
Incorrect indentation: continuation line should be indented +1

> +}
vreg.h does not include any header, so please add appropriate headers for
objects you are adding.

> +
>  static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr,
>                                       vreg_reg_fn_t fn)
>  {
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index e7c484f2c1..d6f9326b71 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -12,6 +12,7 @@
>  #include <asm/cpufeature.h>
>  #include <asm/cpregs.h>
>  #include <asm/current.h>
> +#include <asm/gic.h>
>  #include <asm/regs.h>
>  #include <asm/traps.h>
>  #include <asm/vreg.h>
> @@ -173,6 +174,8 @@ TVM_REG32(CONTEXTIDR, CONTEXTIDR_EL1)
>                                    domain_cpuinfo.field.bits[offset]);\
>      }
>  
> +#define ID_PFR1_GIC_SHIFT 28
Move this to cpregs.h and remove one from arm64/sysregs.h to avoid duplicate
entries.

~Michal

> +
>  /* helper to define cases for all registers for one CRm value */
>  #define HSR_CPREG32_TID3_CASES(REG)     case HSR_CPREG32(p15,0,c0,REG,0): \
>                                          case HSR_CPREG32(p15,0,c0,REG,1): \
> @@ -321,7 +324,17 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
>       * to identify the processor features
>       */
>      GENERATE_TID3_INFO(ID_PFR0, pfr32, 0)
> -    GENERATE_TID3_INFO(ID_PFR1, pfr32, 1)
> +    case HSR_CPREG32(ID_PFR1):
> +    {
> +        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
> +
> +        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> +                                               ID_PFR1_GIC_SHIFT,
> +                                               v->domain);
> +
> +        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1,
> +                                  guest_reg_value);
> +    }
>      GENERATE_TID3_INFO(ID_PFR2, pfr32, 2)
>      GENERATE_TID3_INFO(ID_DFR0, dbg32, 0)
>      GENERATE_TID3_INFO(ID_DFR1, dbg32, 1)



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 07:59:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 07:59:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1387995.1629208 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthO8-0003Rl-Iw; Tue, 11 Aug 2026 07:59:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1387995.1629208; Tue, 11 Aug 2026 07:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthO8-0003Re-GC; Tue, 11 Aug 2026 07:59:08 +0000
Received: by outflank-mailman (input) for mailman id 1387995;
 Tue, 11 Aug 2026 07:59:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wthO7-0003RY-9X
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 07:59:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wthO7-00GIFN-02;
 Tue, 11 Aug 2026 07:59:06 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wthO6-008vX1-19;
 Tue, 11 Aug 2026 07:59:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=yuks5UgbK1jEMp3ty2xIMVbvZYC1PurOFUgY437blUg=; b=57TJr8BonQjCGJ6tMHHE0nz9jV
	rWubFn6Y4BQbVI5PtDj99wuJ+VvkngO0P/ku9qpU2yDKZHM5l8tdu5T+WP1PltI68z/qT6FT5dhIH
	KWTD5Ot/8WcO3l0dbFeF1PzFw6sFDM5bknltOyA66jM3ptQ2NLN+p9H1LwYSq+YWFyKk=;
Date: Tue, 11 Aug 2026 09:58:56 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Jan Beulich <jbeulich@suse.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH] x86/pagewalk: Read guest PTEs with ACCESS_ONCE()
Message-ID: <anrWQL-pw3HicFwS@macbook.local>
References: <20260810221029.1520858-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260810221029.1520858-1-andrew.cooper3@citrix.com>

On Mon, Aug 10, 2026 at 11:10:29PM +0100, Andrew Cooper wrote:
> This has been a plain C read for as far back as I can trace in history.
> 
> Research into invented-loads has flagged it as a possible vulnerability.
> After careful analysis, it is believed to be a bug only, not a security
> vulnerability.
> 
> The code fits the pattern for invented loads, and it is a risk.
> 
> The analysis suggests that we can read one value out of the guest, operate on
> another, and that this could be an in-guest privliege escalation.  Any entity
> in the guest able to modify the pagetables already has full privilege, so
> while Xen can potentially malfunction, the effects don't cross a privilege
> boundary.
> 
> The analysis also suggests that this is worse for shadow guests because we may
> put the TOCTOU entry in the shadows, but this is inaccurate.  What we put in
> the shadows is still translated under the P2M and refers to guest physical
> address space.
> 
> Either way, harden the accesses.
> 
> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-ptwalk-RELEASE-4.21.1.md#86-per-candidate-finding
> Fixes: 49f7c7364e0a ("Replace shadow pagetable code with shadow2.")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Roger Pau Monné <roger@xenproject.org>

> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger@xenproject.org>
> CC: Teddy Astie <teddy.astie@vates.tech>
> 
> I'm not really sure about the fixes tag.  That's the oldest commit which bares
> any reseblence to the current code, and it was a bulk rewrite of the whole
> shadow pagetable code.  Prior to that, it was all mixed up and it's not
> completely obvious what's (definiely) walking the guest pagetables as opposed
> to the shadows.

I'm fine with no Fixes tag if there's no clear introduction point, or
if the introduction is simply that far away (ie: < 4.0) that it's
no really relevant anymore.

> Bloat-o-meter shows this clearly makes a code-gen difference in all cases:
> 
>   add/remove: 0/0 grow/shrink: 1/2 up/down: 16/-19 (-3)
>   Function                                     old     new   delta
>   guest_walk_tables_2_levels                  1688    1704     +16
>   guest_walk_tables_4_levels                  3708    3703      -5
>   guest_walk_tables_3_levels                  2233    2219     -14
> 
> To start with, l?e_read() looked to be the right helper, but they don't exist
> for guest pagetable types, leading to:
> 
> arch/x86/mm/guest_walk.c: In function ‘guest_walk_tables_2_levels’:
> ./arch/x86/include/asm/page.h:135:36: error: incompatible types when assigning to type ‘guest_l2e_t’ from type ‘l2_pgentry_t’
>   135 | #define l2e_from_intpte(intpte)    ((l2_pgentry_t) { (intpte_t)(intpte) })
>       |                                    ^
> ---
>  xen/arch/x86/mm/guest_walk.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
> index f48c3ef75f48..df2ccaa67475 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -129,7 +129,7 @@ guest_walk_tables(const struct vcpu *v, struct p2m_domain *p2m,
>              guest_l4_table_offset(va) * sizeof(gw->l4e);
>      if ( !hvmemul_read_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)) )
>      {
> -        gw->l4e = l4p[guest_l4_table_offset(va)];
> +        gw->l4e = (guest_l4e_t){ ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4) };

I wouldn't mind if this was a macro or static inline function, maybe
that would prevent new usages from forgetting to use ACCESS_ONCE().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 08:05:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 08:05:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388011.1629217 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthUF-0005is-IB; Tue, 11 Aug 2026 08:05:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388011.1629217; Tue, 11 Aug 2026 08:05:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthUF-0005il-EZ; Tue, 11 Aug 2026 08:05:27 +0000
Received: by outflank-mailman (input) for mailman id 1388011;
 Tue, 11 Aug 2026 08:05:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wthUE-0005id-En
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 08:05:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wthUA-00GItK-2a;
 Tue, 11 Aug 2026 08:05:22 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wthUA-009N1g-0Q;
 Tue, 11 Aug 2026 08:05:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=JmpUITwx9KWOwQTi/3Id4eMb0AxNSa+PJhHkXW2LIoo=; b=TUsH5AXAkGBW/N18xE4hFDjZ7B
	JU+Z9qpnm/GZGaKy3zW1EQXhC5ddyhrFEm07S43nNHu5fsHgzkT/nvD6AZviTI6rJW4Ypp0nITVHY
	X2KDo//rjf8yYyf825oKViZ2+e2qHHPJ6LAtsmMCEslzgD7pfbDKy5UYBLg8sq8Jonyo=;
Date: Tue, 11 Aug 2026 10:05:17 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org,
	michal.orzel@amd.com, sstabellini@kernel.org
Subject: Re: [PATCH v3] xen/common: add keyhandler to show Xen command line
Message-ID: <anrXvTfBls4flBqK@macbook.local>
References: <20260810230359.671587-3-dmukhin@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20260810230359.671587-3-dmukhin@ford.com>

On Mon, Aug 10, 2026 at 04:04:01PM -0700, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Currently there's no way to print Xen command line on the emergency
> console for debugging purposes when 'xl' is not unavailable.
> 
> Add new keyhander 'X' to do command line printout.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v2:
> - account for CONFIG_CMDLINE_OVERRIDE case
> - use IS_ENABLED()
> 
> v2: https://lore.kernel.org/xen-devel/20260803070047.3097846-3-dmukhin@ford.com/
> CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2748655201
> ---
>  xen/common/kernel.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index d1bef9ac2b2b..54a7ee6f68e5 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <xen/init.h>
> +#include <xen/keyhandler.h>
>  #include <xen/lib.h>
>  #include <xen/errno.h>
>  #include <xen/param.h>
> @@ -505,6 +506,25 @@ static int __init cf_check param_init(void)
>  __initcall(param_init);
>  #endif
>  
> +static void cf_check show_hypervisor_info(unsigned char key)
> +{
> +    printk("'%c' pressed -> showing hypervisor information\n", key);
> +
> +    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
> +        printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");

Since we are there already, why not print the builtin command line
using CONFIG_CMDLINE?

> +    else
> +        printk("Command line: %s\n", saved_cmdline);
> +}
> +
> +static int __init cf_check misc_init(void)
> +{
> +    register_keyhandler('X', show_hypervisor_info,
> +                        "show hypervisor information", 0);

"show hypervisor information" seems too generic to me, almost all
debug keys could be defined by this sentence TBH.  I think this needs
to be more specific, but I'm not sure what's the plan regarding this
key.  Is there an intention to print more stuff here, or just the
command line?  Knowing the full set of information to be printed might
help come up with a better name.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 08:13:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 08:13:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388018.1629226 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthc9-0007Tv-8f; Tue, 11 Aug 2026 08:13:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388018.1629226; Tue, 11 Aug 2026 08:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthc9-0007To-5t; Tue, 11 Aug 2026 08:13:37 +0000
Received: by outflank-mailman (input) for mailman id 1388018;
 Tue, 11 Aug 2026 08:13:35 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fefe239f8000c4f3@swg.vates.tech>)
 id 1wthc6-0007Tf-UY
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 08:13:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wthc4-00H3UQ-Nv
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 10:13:32 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fefe239f8000c4f3@swg.vates.tech>)
 id 6a7ad9a1-8faa-0a2a0a5109dd-0a2a450a9cbe-48
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:13:32 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fefe239f8000c4f3@swg.vates.tech>)
 id 6a7ad9ab-f2d2-0a2a450a0019-b9ff1c2384ab-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:13:31 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fefe239f8000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 11 Aug 2026 08:13:28 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8F0EE812E3;
 Tue, 11 Aug 2026 10:13:27 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=aoB1eTjT2z4wVpGDNPvLeVwtALQ/pSrK3gx3t7yGMpA=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=OljU4eXRyYpojIIB6q47SGMzJfGOwMr+gXl8Kmx1R9e6n+Yi2K9kDubjI0wOPihqtaABybHmd
 hDMDblIpTRnKoFyFtKZ7e0kAswv+m/TC7AtqY5Cox18qKNmMj8AJNWdNg/Ez1ssr1PHDkQvpENR
 nvb48rOUAJZop/ENCSa8dZQB7e19BmUE2Tuwz5UogNUQO5Mj2jxvKBQeG0PAGl5ukg4IdXHXcGE
 8Jpry8syDQVZ7e3xhVu9R4daq3h+rpJMk9AmWekiV1qAU2b3CDH28ZdZwzsr6xd0GJrrOaD5N0k
 /jpm9YjkJmXNIkqtJ2bdymakCdeTYAXuFVn612hGHNlQ==
X-Zone-Loop: fb89ade2c7f7d53dcc4a6a88abc581905772adc757ec
x-campaign-type: default
x-transaction-id: 06423ebd-9e2c-4e67-b852-b3ec771235ee
x-swg-uid: 01-68685a54-ecb5-401f-bcd4-2dc78b2f18b6
X-Mailer: Sweego
Message-ID:
 <1786436008.8631fc262581453bbf619ec5b2062170.19fefe239f8000c4f3@vates.tech>
x-swg-bid: 1786436008.8631fc262581453bbf619ec5b2062170.19fefe239f8000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v1 02/17] xen/riscv: add basic VGEIN management for AIA
 guests
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <293a08d8-ff96-4726-b713-bc2d14973ca4@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b141b8d976719bb9b76147cacfd5842fb7aac74e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786368748.8631fc262581453bbf619ec5b2062170.19febdfed5f000e099@vates.tech>
 <293a08d8-ff96-4726-b713-bc2d14973ca4@gmail.com>
Date: Tue, 11 Aug 2026 10:13:22 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786436007; l=3715;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=jGG0To3SQ8A2ektFXLw/w53WF2jrX05Bhc1JG2cnuP8=;
 b=i2l9TT7BNVWCKMxwxRhTjf0fbzGEXHJtsjLaTUQ+yP34nN06AR7wLE2jeXyjB+zNhLGK3zGUC
 vDXP4qlHbLsBWUAlnZP4TprWwXWHm8LQZVgchrXtQWHbHMv9gfmsb4F
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786436007777
X-purgate-ID: tlsNG-4011c0/1786436011-536D6CFC-E1FE3249/0/0
X-purgate-type: clean
X-purgate-size: 3719

On 2026-08-10 17:04:43+02:00, Oleksii Kurochko wrote:
> On 8/10/26 3:32 PM, Baptiste Le Duc wrote:
> 
> >> It was decided to add support for IMSIC from the start instead of having APLIC
> > 
> > Add a #include <xen/percpu.h> here instead of in aia.h.
> 
> Sorry, but I’m a little confused here. <asm/aia.h> doesn’t include 
> <xen/percpu.h>.
> 
Yes it is, in xen.git/xen/arch/riscv/asm/aia.h, you added, in this patch
    #include <xen/percpu.h>
Therefore, I think it could be included directly in the aia.c file as it
is the only place where it is used.
> > Could we call this function with a different cpu arg than the current
> > one running? If yes, we would read hgeie of not the cpu we wanted.
> 
> Considering that it touches the CSR_HGIEI register, it can only be 
> called on the currently running CPU.
> 
> That’s why I suggested in one of my replies to Jan B. that I would drop 
> the argument altogether for this function.
> 
> >> +{
> > 
> > 
> > Why `0` rather than smp_processor_id()? As described above vgein_init() reads CSR_HGEIE
> > of the current hart but stores the result into per_cpu(vgein, cpu), so the two
> > must agree.
> 
> aia_init() is executed on boot cpu only so it uses 0 as Xen boot cpu is 
> always 0. But it won't be an issue anymore as I mentioned above an 
> argument of vgein_init() will be dropped anyway so it will be guaranteed 
> that a correct CPU is used.
> 
> > What happens if v->processor change between vgein_assign() and
> > vgein_release? Because it seems in such case the release will hit a
> > different pCPU's bitmap: the original bit will leak and an unrelated
> > CPU's bit will be cleared under another vCPU's feet.
> 
> So, if v->processor changes between the calls to vgein_assign() and 
> vgein_release(), it means that migration has happened. If migration has 
> happened, then it is the responsibility of the migration code to 
> properly assign the new vgein and release the previous one.
> 
> All other cases where vgein_release() is called are when the vCPU is 
> dying, so everything is okay there as migration cannot happen.
> 
> > Potential index error, because above you did:
> > 
> >      vgein->owners = xvzalloc_array(struct vcpu*, vgein->geilen)
> > 
> > so valid index are 0...(vgein->geilen-1). Adopt either
> > one of those two options:
> >      1. vgein->owners[vgein_id-1] = v
> >      2. vgein->owners = xvzalloc_array(struct vcpu *, vgein->geilen+1) in
> >         vgein_init()
> > 
> > I think `2` could be better to have vgein->owners replicated hgeie CSR but
> > it would left the first entry read-only.
> 
> I've found that too during prepare a reply to Jan B. so fixed it already 
> in v2. I've decided to go with what you suggested in 2.
> 
> > VGEIN_DEBUG is not defined anywhere in the patch, please use
> > gdprintk(XENLOG_DEBUG, ...) directly, or drop this branch.
> 
> It is intentionally not defined. If a user needs additional VGEIN debug 
> information, they should define it themselves, as it can produce a 
> pretty large amount of logs due to, for example, the migration process, 
> where vgein_assign() and vgein_release() are used quite actively.
> 
Oh I didn't know it was a common practice, thanks for this explanation.
> > asm/aia.h needs neither <xen/percpu.h> nor <xen/spinlock.h> as struct
> > vgein_ctrl and the per-CPU variable both live in aia.c. Please drop them
> > and add <xen/percpu.h> in aia.c
> 
> Yes, it is redundant code that I missed removing. I’ve already noticed 
> it and removed it in v2.
It's what I wanted to mean in the comment above about <xen/percpu.h>
> Thanks.
Happy to help :)
> 
> ~ Oleksii




From xen-devel-bounces@lists.xenproject.org Tue Aug 11 08:17:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 08:17:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388026.1629236 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthfy-00088p-PH; Tue, 11 Aug 2026 08:17:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388026.1629236; Tue, 11 Aug 2026 08:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wthfy-00088i-Kn; Tue, 11 Aug 2026 08:17:34 +0000
Received: by outflank-mailman (input) for mailman id 1388026;
 Tue, 11 Aug 2026 08:17:33 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@swg.vates.tech>)
 id 1wthfx-00088c-89
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 08:17:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wthfw-00Dd5e-8I
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 10:17:32 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@swg.vates.tech>)
 id 6a7ada96-bab6-0a2a0a5309dd-0a2a4504a5ba-20
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:17:32 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@swg.vates.tech>)
 id 6a7ada9b-b57f-0a2a45040019-b9ff1c229bd5-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:17:32 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19fefe5dbbc000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 11 Aug 2026 08:17:26 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id CD19680B2A;
 Tue, 11 Aug 2026 10:17:25 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=VfuExQmoNgTZXE5+VBkz/9xRzW2zILQKGMuooSznwdY=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=HDgZ/eHyzIztICAkmrRPnX1tPLiK5fXEYrcG4aqurvYkP0nqTynam3YFbw/QJOq9kcXGpDA1t
 JSd74weaza3YiroHSqPREa+EX8RZtU2Jnc0S3p8/pzd5GFGHjMu7EaQUKyk6SWFjLN9dVn50DQt
 4NHbuFn36XzTaTS0vco4wOoSAPUgUyGtPgUpedBTdTUAutRg/tRXvluQtPFC2beou8G0pjNJyUr
 rvuSbq221HWzeH099Daz0taU+EjSiqKkhs1PNOerc7Vr1cf88VQZicXgG9cmFLmHeEzAFqdwr/6
 H/VPlZPVFkJZOIVfOsGAgTUvRp0ywgHUxmr7z2/1DVPA==
X-Zone-Loop: 1d3495b58ea3199696d3fdff1748772b67e1d5f2a59a
x-campaign-type: default
x-transaction-id: 2d9719b5-0336-4957-a9f5-3199505dc255
x-swg-uid: 01-118367d2-c25f-4560-bff3-f1d9c775db70
X-Mailer: Sweego
Message-ID:
 <1786436246.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@vates.tech>
x-swg-bid: 1786436246.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <05283ea0-de82-4160-a3f9-5fc1292a20a5@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
 <05283ea0-de82-4160-a3f9-5fc1292a20a5@gmail.com>
Date: Tue, 11 Aug 2026 10:17:20 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786436245; l=2419;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=WABT/iU4gh03Q3pGmRICfSFFfgjHolSslfi1RQTxhmE=;
 b=nvkbCvR/W6wmC1Tt9FGxWwIQidgRA3QCJVS2t0oXC2SHJkJLOT213HNl6R2TvWyFURqcbbBb8
 2bAPhhTDeERDwuxlqYhFdP9PuIZA1+TzZau9bE7en4AlHQYexDUOYsI
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786436246032
X-purgate-ID: tlsNG-ebf023/1786436252-C12DCB50-7ACB3400/0/0
X-purgate-type: clean
X-purgate-size: 2423

On 2026-08-10 17:36:56+02:00, Oleksii Kurochko wrote:
> On 8/10/26 4:49 PM, Baptiste Le Duc wrote:
> 
> >> diff --git a/xen/arch/riscv/include/asm/mmio.h b/xen/arch/riscv/include/asm/mmio.h
> > 
> > According to coding style, it should be GPL-2.0-only.
> 
> Could you please point me to the line in the coding style document where 
> this is mentioned?
> 
> If you are referring to:
>    New files should start with a single-line SPDX comment to express the
>    license, e.g.:
> 
>    /* SPDX-License-Identifier: GPL-2.0-only */
> 
>    See LICENSES/ for a list of licenses and SPDX tags currently used.
> 
> Then my understanding is that /* SPDX-License-Identifier: GPL-2.0-only 
> */ is used only as an example, and I can choose any license from 
> LICENSES/. There, it is mentioned:
>    Valid-License-Identifier: LGPL-2.0-only
>    Valid-License-Identifier: LGPL-2.0-or-later
> 
> I am pretty sure that I am free to choose any license that does not 
> conflict with the other licenses used in the project.
> 
Oh ok I didn't know, thanks for these explanations. Could you let me
know how do you choose one instead of the other in that case? Is there a
rule from our company to follow somewhere?
> >> +#ifndef RISCV_MMIO_H
> > 
> > Nit: line too long (85)
> 
> I will apply that. Actually I've already fixed that by putting the 
> comment above:
>    /* store: value to write; load: value read (set by handler) */
>    register_t data;
> 
> >> diff --git a/xen/arch/riscv/mmio.c b/xen/arch/riscv/mmio.c
> > Should be GPL-2.0-only.
> 
> Regarding license I've wrote a comment above so lets continue discussion 
> there.
> 
> >> +/*
> > Why have you included a copyright notice here, but not in the other
> > files?
> 
> So I just decided to do that for new files as I am not using corporate 
> e-mail.
But why didn't you do it for all new files of this series?
> 
> I don’t know if you can keep it,
> 
> Good point, I have to ask then someone from our legal department...
> 
>   but I just wanted to point out
> 
> > that there are other files where this type of copyright notice includes
> > the year.
> 
> Before, I used to include the year, but someone pointed out (or perhaps 
> I misunderstood) that there isn’t much point in including it and that it 
> is enough to have just (c) <company name>.
> 
Okay thanks.
> Thanks.
> 
> ~ Oleksii




From xen-devel-bounces@lists.xenproject.org Tue Aug 11 08:39:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 08:39:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388033.1629245 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wti1N-0003FD-EF; Tue, 11 Aug 2026 08:39:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388033.1629245; Tue, 11 Aug 2026 08:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wti1N-0003F5-Ae; Tue, 11 Aug 2026 08:39:41 +0000
Received: by outflank-mailman (input) for mailman id 1388033;
 Tue, 11 Aug 2026 08:39:40 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wti1M-0003Ez-Gb
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 08:39:40 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wti1L-00GJX5-1c;
 Tue, 11 Aug 2026 08:39:39 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wti1K-00BPuT-2n;
 Tue, 11 Aug 2026 08:39:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=rsDj8bg+McL8OBg03w8bUJh1MWTTZ9TNG3sSP2E9cq8=; b=cc3epIAt4zpTNHoKlWHsmMp36+
	/eDUJPCMxN5ki0lGOK5yhGUQI2bTFGWQsEq3JtOGUTbe0hsYZfJKm745+3FlY8+SFCq+Ou8RIKQ2J
	P3izi/L74UVt0/EV/dcsWEBHv/DkJSzC6Q31haCmUSPwwJ3SUlkDU96kyaJDTP41dx38=;
Date: Tue, 11 Aug 2026 10:39:31 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Elliott Mitchell <ehem+xen@m5p.com>
Cc: Cody Zuschlag <cody.zuschlag@xenproject.org>,
	xen-devel@lists.xenproject.org, anthony.perard@vates.tech
Subject: Re: [ANNOUNCE] - Call for agenda items for August 6 Xen Community
 Call @ 15:00 UTC
Message-ID: <anrfqjt69_K900nJ@macbook.local>
References: <CAJbE=KznNsrNRN=pUaDj7-TVW4uCMVBdrPpei_z5nBdjdHnVag@mail.gmail.com>
 <anqKjwU93bMcttNz@mattapan.m5p.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <anqKjwU93bMcttNz@mattapan.m5p.com>

On Mon, Aug 10, 2026 at 07:35:59PM -0700, Elliott Mitchell wrote:
> On Tue, Aug 04, 2026 at 05:30:50PM +0200, Cody Zuschlag wrote:
> > *Preparation*
> > 
> > 👉 Please take a few minutes to review and update the agenda before the
> > call:
> > 
> > https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/
> > 
> > Feel free to:
> > - Add topics or project updates
> > - Suggest anything we can drop or defer
> > - Include links to patches, mailing list threads, or documentation where
> > helpful
> > 
> > The agenda also includes the meeting link and a link to find your local
> > meeting time.
> > 
> > 
> > *Call Details*
> > Date: Thursday, 6 August 2026
> > Time: 15:00 UTC (agenda starts at 15:05 UTC)
> > Join: https://meet.jit.si/XenProjectCommunityCall
> > 
> > We'll open the room at 15:00 UTC and begin the agenda at 15:05 UTC to give
> > everyone a few minutes to join.
> 
> 
> Took me a bit of time to consider what had been said in order to come up
> with next responses.
> 
> I didn't emphasize it during the community call, but the point was
> explicit in the most recent posted message:
> 
> https://lore.kernel.org/xen-devel/ajr0gN9kmPkLQlGF@mattapan.m5p.com/T/
> 
> This was previously allowed by Xen/ARM.  This turned into a bug when the
> Xen/ARM team decided to disallow multiple mappings of the shared
> information page.  During approval the Xen/ARM team was explicitly asked
> to accept the task of updating outside projects to deal with fall-out.
> 
> I don't recall the exact wording of the agreement, but this is certainly
> fall-out from that change.  As such this IS an adjustment the Xen/ARM
> team agreed to aid.
> 
> I've already generated a PoC, I had thought the Xen/ARM team would be
> better acquainted with whom to ask about getting a patch along those
> lines in.  That seems a reasonable ask in light of the team having
> accepted the task.
> 

I don't know what you mean or imply with "accepted the task".  It
sounds a bit selfish to me that you refuse to finish the OVMF work.
It's possible none of us likes the OVMF coding style more than you do,
yet you seem to assume we have some kind of duty to pick this work and
finish it.  That's IMO an unacceptable burden to put on developers of
an open source project.

> 
> I don't know the Xen developers by voice.  As such I don't know who
> mentioned 'firmware = "ovmf"' when I was trying to bring up
> Tianocore/EDK2 as bootloader.  Now that I've checked by notes, whomever
> brought that up was quite unfamiliar with that I was trying to bring up.
> 
> The 'firmware = "ovmf"' setting is part of HVM domain configuration.  In
> this environment Tianocore/EDK2 is merely setting up some ACPI tables and
> then handling the task of finding and invoking the OS bootloader.  Since
> all the hardware is emulated, Tianocore/EDK2-firmware isn't much
> different from what it normally does.  I should also note this is fairly
> slow.
> 
> Despite sharing the codebase, Tianocore/EDK2 as bootloader is very
> different from being HVM firmware.  In particular the arm64
> Tianocore/EDK2 configuration is "ArmVirtPkg/ArmVirtXen.dsc" and the build
> creates the file "XEN_EFI.fd".  Once built the domain configuration is
> along the lines of:
> 
> type = "pvh"
> name = "somename"
> kernel = "XEN_EFI.fd"
> memory = 256
> vcpus = 2
> vif = [ "somenet" ]
> disk = [ "somedisk" ]
> 
> The result is a PVH domain with Tianocore/EDK2 functioning as a pure
> bootloader.  In particular it is capable of searching for its preferred
> filesystem, then looking for an appropriate filename and then loading
> that using the UEFI protocol.  The result is near-ideal.
> 
> Of note I'm pretty sure Tianocore/EDK2-bootloader would happily load
> EFI-GRUB.  More importantly though OS bootloaders which can handle UEFI
> work perfectly in this setup.  I expect this to be superior for *BSD.
> 
> There are two problems with Tianocore/EDK2-bootloader though.  First, is
> the aforementioned unresolved bug.  Second, this is only implemented for
> aarch64 (arm64).

Anthony has done the work for OVMF to work on x86 PVH domains, maybe
he can provide more information about how to set it up and test.

> This is a problem for all the paravirtualized bootloaders.  They're all
> single-architecture, despite the bootloader supporting multiple
> architectures.  On that single-architecture they're quite good, but Xen
> really needs them on *all* their architectures.
> 
> 
> I didn't get the chance to finish my suggestion during the call, so here
> is what I wanted to suggest:
> 
> I think the Xen Project really needs some effort aimed at the
> paravirtualized bootloaders.  Mostly making them operable on all
> architectures they support.
> 
> Paravirtualized GRUB is needed for ARM, RISC-V and PowerPC.
> 
> I don't believe Tianocore/EDK2 supports PowerPC, but I would really hope
> for it to become available for RISC-V and x86.
> 
> While U-Boot is difficult to deal with, it would be valuable as a second
> paravirtualized bootloader for PowerPC.
> 
> Once those 3 were available on their applicable architecture it would be
> time to purge PyGRUB.  While I imagine this will take a while I think it
> should be on the roadmap/panciled in for the future.

In my opinion, it's naive to expect this plan to be realized without
any developer effort behind it from your side.  Leaving aside whether
it's the right call from a technical prospective, I don't think it's
fair to come to an Open Source community, drop a multi-project
multi-architecture plan, and expect others to simply start crunching
on it because "it's the right thing to do".

Most of us already have very thigh deadlines and internal projects by
our employers, and that's always going to take priority.  And then
with whatever little "free" time we have, we might have other goals
and tasks that prefer to pursuit.

In other words, I think if you want to see this making progress you
either have to work on it yourself, or pay some developer(s) to do the
work.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 08:52:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 08:52:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388042.1629253 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtiE1-0006FM-IZ; Tue, 11 Aug 2026 08:52:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388042.1629253; Tue, 11 Aug 2026 08:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtiE1-0006FF-Fn; Tue, 11 Aug 2026 08:52:45 +0000
Received: by outflank-mailman (input) for mailman id 1388042;
 Tue, 11 Aug 2026 08:52:44 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wtiE0-0006F8-Bg
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 08:52:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtiDy-0069x2-8I
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 10:52:42 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7ae2c9-bab6-0a2a0a5309dd-0a2a4506a378-42
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:52:41 +0200
Received: from [52.101.56.42]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7ae2d8-195a-0a2a45060019-3465382a85d2-4
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:52:41 +0200
Received: from BL1PR13CA0142.namprd13.prod.outlook.com (2603:10b6:208:2bb::27)
 by PH8PR12MB8432.namprd12.prod.outlook.com (2603:10b6:510:25b::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 08:51:50 +0000
Received: from MN1PEPF0000F0E4.namprd04.prod.outlook.com
 (2603:10b6:208:2bb:cafe::66) by BL1PR13CA0142.outlook.office365.com
 (2603:10b6:208:2bb::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Tue,
 11 Aug 2026 08:51:49 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 MN1PEPF0000F0E4.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Tue, 11 Aug 2026 08:51:49 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 03:51:49 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 03:51:49 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 11 Aug 2026 03:51:47 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nNBBgTGp1mcTONcPsH8fZGY0lZc28HdvKg8hQ9pk8FMObh3sUYei1sQfG+6Y5Mn9TgjecWnizJwokiYGs3lZRY1LH30k43BR5SxFmmCNQXfkSbKF4Fkva6v2AOfjd9o8gHzsT/VfFEkdJw8N0xEVcFKr1QuwMVwYFjMKyHS4K/yi6lge0ASPvdjbxjQ3F9WVC69BPdv4u7VuarTlx8JpCQQ2yPPFSk6+qSfS0MzSP9CFge8/Ad+zVW1/dPc3bR12ZSPZrIqr1aAMqwhGB3gNE3S7A8NKvw/X9Yj/uXkNxSuX2tA/Z9DpYyhY3SXKAuP9M4C8X+MsNxlkPKDhI/Qdvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ex96CI+X4Y5wRRjVWwfYGvAcs68jgARCp19WLcvYZsI=;
 b=T4ttE2cHsq2wcW3DZaEWf3xy1+MiBeYuUXIPu6L1oUXkmNYALt+3mLwMUrylPEVVktpxLfzsDlRVN4JR1qQkAC+fHChbb7XeJ8nmYWnNkH/B6K9WtjiK4Zyu8AbHLjxvBSWoH4cBgFRiNs5ZNnxbDsZ32RP65P7dXa1eQjEqToj2WsY609PuSpP2/z+xVpq/w1bbbeVfHqNHsXcq58Uiw8IRrEIwKZYV1rwPFicXxDndwWNG/4TB4Ne7QAdLYxzGh6RFFMqDqDQzhNRKLmDOKgml+hmBZyTt1DZdIICvlPq6OVMBOoqN79dKTH5/23UNSIKRclTxeaG7iYl4mNWjYA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ex96CI+X4Y5wRRjVWwfYGvAcs68jgARCp19WLcvYZsI=;
 b=ejc10Io9S2dEo6jWOgQIAI4f/GLdn9wQLo3o2DiGG9vRip5qloWzigc86ykklBQJ4BIL+NjlQqVXqgJK1EpgKxkOTr+1E4uQXHVPKcoHRx4T73hNS1adufXUE0G8YimWJf07XVbjJ7DcuUh2FTwBg/3OYsX5E4aWMk7ncmTdiC0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <272a8622-47c2-4cbb-a98c-8242561cbdb8@amd.com>
Date: Tue, 11 Aug 2026 10:51:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] xen/arm: validate IRQs before descriptor lookup
To: Mykola Kvach <mykola_kvach@epam.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>
References: <cover.1786385827.git.mykola_kvach@epam.com>
 <271952244ae71ade885b3619fe161ed4f47777fa.1786385827.git.mykola_kvach@epam.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <271952244ae71ade885b3619fe161ed4f47777fa.1786385827.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E4:EE_|PH8PR12MB8432:EE_
X-MS-Office365-Filtering-Correlation-Id: d3bff8db-055d-47a9-6ec2-08def785c860
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700016|376014|82310400026|23010399003|10067099003|4143699003|56012099006|11063799006|5023799004|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	Tbba8HwoA0WfeC27HSxYENdPHKCYYIwh3Q7l9kRkKHTo4Tbd/Py8FEdc5lG20SKzXh6zMRPNDs+G1XiAIxZ3VzkiUnigjwLpXEDvzD0QHPebot6Wcma22V1RlHGU0bmPL05pNgW0hT4d8hJfAiAv6PqP0wRuh4WwGLaoqjtVV4dGA3yPoWDnxkavdp/FmXXevyF1Zw4YW95xdQMOSEI5bmDvkcYeWYt07pf/1PyRuA0nPxmtFHwVbl9lseNDwPLkG91vSqv+LcxuFieNmjIl+MMiW+WCCRr2rolJEA/QvwyBLtMw10FQskaFvsrOxZngEulkjQCsOvutEd5R7RXe0VZgHTj1gFCB1YxoxUPvupDZ3wRdjIE0qlTzs8aUNmdS9p+oeYnVxQSmdx25NRJ6M7l/dSYgfcJMjw6K2pGJKK7Mayb7fGFto7KR3zq9/Am0AFd0TV2UesSW59YTDoatGWOgu7GYtw0AIxeCJ0ac3R5PP65RsWFq37ng64QxRGG3hbkjvpzs2Cremh3BeQt+g6b7qdIb5m7Kha9GK6ydhZeTKjbH0+2po3wU1jaAc6pKClG/gb0379oPtNIu7ph1ps0y2lfZhHxMyEgrv+AMkWNsu7isXy6GNbAmuRLmefF03tKnN455yziJPloW9JVBTp8t+3eXxn5dAuGmy294FCcyFZ4HpO+7HKptkIYmc/ADGNN7h8OrpCV1FBcKxBp5vg==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(376014)(82310400026)(23010399003)(10067099003)(4143699003)(56012099006)(11063799006)(5023799004)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	JBlRjzLmERNHwd09iJQtWJbs8nk/lwIkGLyv4ozflVOL8aLxvvsXhuvir4ByH7AD+j9Ma5hstHzVkQOOt8qg2qUv4N0NB6OfC+4LcwAE04fV+4BtUmd1OGuowOSe0coFPjI8dkzXlLCrBbrTKGImLCduZJPtVxEBuMfGAbKyUpEX2b5wdcwb9pVnnPkxo8gbro9b2MurK6rr2PeovHRsynNxdOemzH3N8feVuvzLIUKl1U/LgpJixjlbzvrTR3POduKDyJqurjCXgpRT4tc6VoGxWLqDKcdE3RQaVkCSdvNREa/3mYomun1xV4MAmAoGjXpJfrVnXacFngwAt7Sks1/TEhIjIGXZH308C3G+05y2wT85vHw2BfiJEWp0TPLkt1ng9Ts87xr8LsqKpG3uTqeD+/guxBRCCCyP+T5tsptt/mbqi8ZHpoymvGJyVx+Y
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 08:51:49.7233
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d3bff8db-055d-47a9-6ec2-08def785c860
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000F0E4.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB8432
X-purgate-ID: tlsNG-16d1c6/1786438361-FD00977B-548B2A2C/0/0
X-purgate-type: clean
X-purgate-size: 4762



On 10-Aug-26 20:38, Mykola Kvach wrote:
> GICv3 eSPI support makes nr_irqs span the architectural INTID namespace
> through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[]
> and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs.
> INTIDs 1024 through 4095 have no backing descriptors.
> 
> Validation based only on nr_irqs accepts an INTID in this gap.
> __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or
> update unrelated Xen memory.
> 
> Reject INTIDs that the GIC reports as unimplemented in setup_irq() before
> looking up a descriptor. irq_set_spi_type() can run before the implemented
> GIC line counts are available, so validate descriptor-backed ranges there
> before looking up a descriptor.
> 
> Call is_espi() unconditionally in __irq_to_desc() and provide an
> espi_to_desc() stub when eSPI support is disabled. This preserves the
> is_espi() debug check for eSPI-range INTIDs when support is disabled.
> 
> Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v2:
> - Validate descriptor-backed ranges in irq_set_spi_type().
> - Validate implemented GIC lines in setup_irq().
> - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled.
> ---
>  xen/arch/arm/irq.c | 29 ++++++++++++++++++++++++-----
>  1 file changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 73e58a5108..0f5d3496bf 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ?
>                                          (ESPI_MAX_INTID + 1) :
>                                          NR_IRQS;
>  
> +static bool irq_has_desc(unsigned int irq)
> +{
> +    return irq < NR_IRQS ||
> +           (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq));
This IS_ENABLED reads redundant because is_espi() contains #ifdef
CONFIG_GICV3_ESPI inside. AFAICT you added it here to prevent the !ESPI build
from reaching ASSERT inside is_espi() when the irq is in ESPI range. I don't
like the ASSERT inside is_espi(). I think it does not make much sense in a
helper that should really just tell us whether the IRQ is in ESPI range or not.
It should be up to the caller to decide what to do based on whether ESPI is
compiled in or not. I think this cleanup would be best to be done first. If you
don't want to do that, at least document this in the commit msg because others
may be tempted to drop this IS_ENABLED.

> +}
> +
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
>  
> @@ -77,6 +83,12 @@ static int __init init_espi_data(void)
>  }
>  #else
>  
> +static struct irq_desc *espi_to_desc(unsigned int irq)
> +{
> +    ASSERT_UNREACHABLE();
> +    return NULL;
> +}
> +
>  static int __init init_espi_data(void)
>  {
>      return 0;
> @@ -90,10 +102,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
>      if ( irq < NR_LOCAL_IRQS )
>          return &this_cpu(local_irq_desc)[irq];
>  
> -#ifdef CONFIG_GICV3_ESPI
>      if ( is_espi(irq) )
>          return espi_to_desc(irq);
> -#endif
>  
>      return &irq_desc[irq-NR_LOCAL_IRQS];
Nothing here covers 1024..4095. I think we should add at least:
ASSERT(irq < NR_IRQS) like we discussed some time ago.

>  }
> @@ -416,6 +426,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
>      struct irq_desc *desc;
>      bool disabled;
>  
> +    if ( !gic_is_valid_line(irq) )
> +        return -EINVAL;
> +
>      desc = irq_to_desc(irq);
>  
>      spin_lock_irqsave(&desc->lock, flags);
> @@ -647,13 +660,19 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new)
>  int irq_set_spi_type(unsigned int spi, unsigned int type)
>  {
>      unsigned long flags;
> -    struct irq_desc *desc = irq_to_desc(spi);
> +    struct irq_desc *desc;
>      int ret = -EBUSY;
>  
> -    /* This function should not be used for other than SPIs */
This is an important line that you should keep.

> -    if ( spi < NR_LOCAL_IRQS )
> +    /*
> +     * The implemented GIC line counts are not available when early
> +     * callers configure IRQ types. Check descriptor storage here; setup_irq()
> +     * validates the implemented line before the interrupt is used.
> +     */
> +    if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) )
>          return -EINVAL;
>  
> +    desc = irq_to_desc(spi);
> +
>      spin_lock_irqsave(&desc->lock, flags);
>  
>      if ( !irq_validate_new_type(desc->arch.type, type) )

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 09:22:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 09:22:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388052.1629262 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtig7-0002FK-Oo; Tue, 11 Aug 2026 09:21:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388052.1629262; Tue, 11 Aug 2026 09:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtig7-0002FB-M5; Tue, 11 Aug 2026 09:21:47 +0000
Received: by outflank-mailman (input) for mailman id 1388052;
 Tue, 11 Aug 2026 09:21:46 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@swg.vates.tech>)
 id 1wtig6-0002F4-Ba
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 09:21:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtig5-006FrG-0I
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 11:21:45 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@swg.vates.tech>)
 id 6a7ae99c-bab6-0a2a0a5309dd-0a2a4509c4bc-48
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 11:21:44 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@swg.vates.tech>)
 id 6a7ae9a8-be1a-0a2a45090019-b9ff1c12b6f9-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 11:21:44 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ff020b5cf000c4f3.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 11 Aug 2026 09:21:43 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id A6098836B8;
 Tue, 11 Aug 2026 11:21:42 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=BsDOru5B/HOalntMeTera7gCiEHVoXXf0RUzISNa0hQ=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=p4ZTfclmQMN1CNnwb43L1fye72gokU+LmNGukYDH8eOe8IS0FHFU9By/CpNppc1gEsu1Qg9uN
 DOSl+mwEIFDfgLHvxgH3cM9L9Oy2UscnL7arsNtHTPKWJ6Gtbt8QbYMK9W5Se68sW87hV7mcDgH
 khRbYYHnc5+fgPzzjaueYKEg2YITCxSntW/8ZIlNbjtEx84520af/rrLpz52U0ygNZXJ7j9c5H+
 0/4cswQTTFwtFLvuG6nsr2Swboqr4c2Q05zWdEX70iugdr4qFGs/0WiCycuLtfPOunVep1jiHOJ
 2Z33IMo4l1qpWXV4sdQYPGAkpvfjLUHPGWsemgXJ0t4w==
X-Zone-Loop: 227c7d1a10f88bfa010aaddba4f1d9070cff629807f4
x-campaign-type: default
x-transaction-id: 13ba7e45-6832-423a-80cb-23f843b7583c
x-swg-uid: 01-314b3b3d-7f60-47e3-9ec5-06fad97b9657
X-Mailer: Sweego
Message-ID:
 <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
x-swg-bid: 1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Jan Beulich <jbeulich@suse.com>, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
In-Reply-To: <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
Date: Tue, 11 Aug 2026 11:21:37 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786440102; l=10687;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=gOjMgTrY5afWsvGwKc48ZSHzxOd0PUqzW8ObetQiJ0Q=;
 b=pdma3NXfM4Gv4vvmHCu9so0Xn6DhD6yjAUScqDpL2Yfr/B2KRIQvlKvZRNsNNLg8xpJy+rqQP
 Otj8RljM2++A+xoxgKSueM4FF1Z/Hz4oRJRQgmhuxgkts2LSkQklwQ8
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786440102868
X-purgate-ID: tlsNG-bad1c0/1786440104-3A4DB034-B032E409/0/0
X-purgate-type: clean
X-purgate-size: 10689

On 2026-08-07 18:08:21+02:00, Oleksii Kurochko wrote:
> On 8/6/26 4:28 PM, Jan Beulich wrote:
> 
> > On 20.07.2026 18:02, Oleksii Kurochko wrote:
> > 
> > For this tag to have any meaning, it should move ahead of the --- above;
> > the explanations ...
> > 
> > 
> > ... here rather explain the restriction on the R-b, not its odd placement.
> > 
> > 
> > As this looks to be recurring - please get versioning of your series right.
> > The series is supposedly v1, but here you give the impression of it being
> > v3. If there really was an earlier v2 posting, why isn't the entire series
> > here v3?
> 
> It is v3 before before it was a part of another patch series connected 
> to dom0less config enablement.
> 
> Would it be better to just write in "Change in v3" that it is moved from 
> another patch series + link to that patch series? Or it will be enough 
> just to drop "Changes in v2 and v1" and just start from v1?
> 
> > PLease can you, before submitting, self-review your patches? I'm really
> > getting tired of having to repeatedly point out basic style issues, like
> > the overlong line here.
> 
> Sorry for that, I will write an extra checker for such cases to not miss 
> them.
> 
> > It extends to the other local variables here, but I'll use these two to
> > try to make my point: I'm struggling to associate the names with the
> > values they are set to. Likely "hxw" is an abbreviation of hart index
> > width, but (a) what's the leading 'l' then and (b) why is there no 'g'
> > in "hhxw"? By using hard to grasp names, you make it hard to actually
> > understand the subsequent expressions, in particular ...
> 
> The names it taken directly from AIA spec:
> 
> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low 
> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart 
> Index Width) for determining target addresses for MSIs is described 
> later, in Section 4.9.1.
> 
> The AIA specification interprets the machine-level hart index as a 
> combination of the **group index** (`g`) and the **hart index within the 
> group** (`h`), according to the following formulas:
> 
> ```
> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
> (2) h = machine-level hart index & (2^LHXW − 1)
> ```
> 
> (In our case, the machine-level hart index is equal to `mhartid`, i.e. 
> the hart index.)
Therefore, if I understand correclty, if we take the Hart Index as
defined in the AIA spec, we should have:
Hart Index = (g << LHXW) | h
Is it correct?
> 
> For systems that use IMSIC groups, the IMSIC address layout is defined 
> by the following parameters:
> 
> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the 
> hart number within a group.
> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for 
> the group number.
Is group number appelation equivalent to group index?

I think with if what I wrote above is correct, the proper definition for
`hhxw` and `hhxs` should be:
* `hhxw` (High Hart Index Width, or *j*): the number of bits used for
the `Hart Index` field within the physical address.
> * `hhxs` (High Hart Index Shift): the bit offset of the combined 
> hart/group index field within the physical address.
* `hhxs` (High Hart Index Shift): the bit offset of the `Hart Index`
field within the physical address.
> To extract the group index, we first shift the address by `hhxs` so that 
> the group index bits are aligned, and then apply a mask derived from 
> `hhxw` to isolate those bits.
> 
> The hardware performs the same operation to extract the hart index from 
> the MSI address. However, in our case we already know which hart should 
> receive the interrupt (`hartid`), so there is no need to extract the 
> hart index from the base address. We only need to recover the group 
> index and combine it with `hartid` to construct the value expected by 
> the `target` register.

Why don't we direclty extract the Hart Index as target directly needs it
as explained in the 4.5.16.2 point of the AIA spec:
target[31:18] = Hart Index
target[17:12] = Guest Index
target[10:0] = EEID
It'd be easier as we just have to do shift from HHXS and apply HHXW.
> 
> > ... these last two. As it stands, they may be easier to understand if
> > you didn't have the local variables at all, despite them then getting
> > textually longer.
> 
> With the explanation above, do the variable names make sense?
> 
> To be closer to AIA spec I think it would be better to rename 
> group_index to g and hart_id to h. Does it make sense to you?
> 
> >> +
> > 
> > Wouldn't this applying of a mask better be done in those callers which
> > actually need it? It's not the least the asymmetry with ...
> 
> Agree, that to be in sync, I will drop mask argument and apply it on 
> caller side.
> 
> > ... this which I consider unhelpful.
> > 
> > 
> > As to the comment - this indeed looks to be a field, but ...
> > 
> > 
> > ... these look to be values of some other field which isn't described. Please
> > may I (again) ask that definitions are their commentary at the very least not
> > misguide readers?
> 
> Thanks for pointing this out. You're right, the comment is misleading as 
> written. APLIC_SOURCECFG_D is a field, whereas the APLIC_SOURCECFG_SM_* 
> definitions are values for the source mode (SM) field, and the comment 
> doesn't make that distinction.
> 
> I'll update the comments to describe the fields more accurately:
> 
> #define APLIC_SOURCECFG_BASE            0x0004
> #define APLIC_SOURCECFG_LAST            0x0ffc
> /*
>   * sourcecfg[] register fields:
>   *  - bit 10 (D) selects the layout of the remaining bits;
>   *  - D = 1: bits [9:0] hold the Child Index, i.e. the source is delegated
>   *           to a child domain (unsupported by Xen);
Just to know, what is a child domain?
>   *  - D = 0: bits [2:0] hold the source mode SM (WARL).
>   */
> #define  APLIC_SOURCECFG_D              BIT(10, U)
> /* SM field values (0x2 and 0x3 are reserved): */
> #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
> 
> Does it look better? Probably there is not sense for two extra spaces 
> for APLIC_SOURCECFG_SM_*. I want to show by such identation that it is 
> values for SM field of APLIC_SOURCECFG.
> 
> > And the xxx-es in here mean what exactly? Don't care? Some other, unrelated
> > values? Yet something else?
> 
> The `x` bits denote address bits that are constant across all IMSIC 
> interrupt files. They are not used to encode the group, HART, or guest 
> index; instead, they correspond to the fixed portion of the IMSIC 
> address determined by the platform's memory map.
> 
> For example, consider the IMSIC DT binding:
> 
>      interrupt-controller@28000000 {
>        compatible = "qemu,imsics", "riscv,imsics";
>        interrupts-extended = <&cpu1_intc 9>,
>                              <&cpu2_intc 9>,
>                              <&cpu3_intc 9>,
>                              <&cpu4_intc 9>;
>        reg = <0x28000000 0x2000>, /* Group0 IMSICs */
>              <0x29000000 0x2000>; /* Group1 IMSICs */
>        interrupt-controller;
>        #interrupt-cells = <0>;
>        msi-controller;
>        #msi-cells = <0>;
>        riscv,num-ids = <127>;
>        riscv,group-index-bits = <1>;
>        riscv,group-index-shift = <24>;
>      };
> 
> 
> Here, `hart_index_bits = 2` (4 CPUs) and `guest_index_bits = 0`, so the 
> address layout becomes:
> 
> 31          25 24 23         14 13 12 11          0
> +-------------+-+-------------+-----+-------------+
> | constant    |G|  constant   |HART |    zeros    |
> +-------------+-+-------------+-----+-------------+
> 
> 
> I can update the comment to say:
> "x denotes bits that are constant across all interrupt file addresses."
> 
> or, if you think it's clearer: "x denotes bits whose values are 
> platform-defined and common to all interrupt file addresses."
> 
> Does it make sense any of suggested options?
> 
> > Nit: Indentation.
> 
> I will use the following indentation:
> 
> ... (((irqn) < (d)->arch.vintc->nr_virqs) && \
>       test_bit(irqn, (d)->arch.vintc->used_irqs))
> 
> > Is this really meant to stay?
> 
> For debug purpose it could be useful, so I prefer to have it with 
> changing it to gprintk(XENLOG_DEBUG, ...) to understand which domain is 
> trying to access something wrong.
> 
> > The U suffix is mainly (even if only slightly) obfuscating things, I think.
> 
> Agree, I will drop U.
> 
> > I don't quite understand the need for the cast.
> 
> Functionally it isn't need but it documents that it is expected that 
> translation from unsinged long  to uint32_t will happen. I will drop the 
> cast.
> 
> > Why the cf_check (also for the store counterpart)?
> 
> Missed to drop. Before vaplic_emulate_load() was used to initialize 
> vints_ops. It should be dropped here.
> 
> > You have d as a local variable.
> > 
> > 
> > Use domain_vcpu()?
> 
> It will be better, thanks.
> 
> > Instead of this goto, I think you simply want to move the label here.
> > That'll also make the function more similar to its load counterpart.
> 
> Good point. I am curious how fail label should be aligned:
> 
>      default:
>   fail:
>          gdprintk(XENLOG_WARNING,
>                   "Unhandled APLIC write at offset %#x (value %#x)\n", 
> offset,
>                   value);
> 
>          return rc;
>      }
> 
> or default:
>      fail:
> 
> ?
> 
> > You have v passed in here, but you'd log current. If passing in v is
> > necessary (i.e. here or elsewhere it may be other than current), then you
> > need to either ASSERT(v == current) at the top of the funciton or otherwise
> > handle v != current correctly.
> 
> It makes sense. I will add ASSERT(v == current) here and for 
> vaplic_mmio_write().
> 
> > If all you care about is a boolean result, why not make the function return
> > bool?
> 
> Agree, bool will be enough for vaplic_emulate_load() and 
> vaplic_emulate_save().
> 
> Thanks!
> 
> ~ Oleksii

I will try to draw some schema to make the AIA spec more explicit. Maybe
it could be part of this series, I don't know what is the xen policy
about diagram and stuff like that. Do you know more about that? In order
to not do a job with no needed at all.



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 09:48:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 09:48:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388060.1629271 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtj5Z-0005OE-Ks; Tue, 11 Aug 2026 09:48:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388060.1629271; Tue, 11 Aug 2026 09:48:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtj5Z-0005O7-Ht; Tue, 11 Aug 2026 09:48:05 +0000
Received: by outflank-mailman (input) for mailman id 1388060;
 Tue, 11 Aug 2026 09:48:04 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anshuman.khandual@arm.com>) id 1wtj5Y-0005Mt-4q
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 09:48:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtj5W-00AYhB-OC
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 11:48:03 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7aefb7-2eae-0a2a0a5409dd-0a2a4506b958-20
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 11:48:01 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7aefd0-195a-0a2a45060019-d98c6eacd35c-1
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 11:48:01 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 53CA01682;
 Tue, 11 Aug 2026 02:47:56 -0700 (PDT)
Received: from localhost (a085714.arm.com [10.164.19.28])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8FC363F632;
 Tue, 11 Aug 2026 02:47:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786441680; bh=9BoMtxA4Y0P7/HlT09wIdHqLAsjiBcPF0bOK0SA6y88=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=d6ccwcWanhV2NaMQGyN2LuxorwwpnGJX87UVp3OA/ioC8kalbAN29GEdYDjGMly4L
	 +yi+Q/zEcN/N5K6/AZJJ9VjzIZc7OuAomjl/vPpcEdxNEFoRGn9LR525fZF+bpEreD
	 Ak2C6/i9Np4uONZAT7JjQS//RpxwX0LWi0gAmmt8=
Date: Tue, 11 Aug 2026 15:17:57 +0530
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum@arm.com>, 
	Alexander Gordeev <agordeev@linux.ibm.com>, Jani Nikula <jani.nikula@linux.intel.com>, 
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, 
	Tvrtko Ursulin <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>, 
	Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich <dimitri.sivanich@hpe.com>, 
	Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Muchun Song <muchun.song@linux.dev>, 
	Oscar Salvador <osalvador@suse.de>, Andrew Morton <akpm@linux-foundation.org>, 
	"Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>, 
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, Nick Piggin <npiggin@gmail.com>, 
	Peter Zijlstra <peterz@infradead.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, 
	Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>, 
	Uladzislau Rezki <urezki@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Masami Hiramatsu <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>, 
	Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, 
	Eduard Zingerman <eddyz87@gmail.com>, Kumar Kartikeya Dwivedi <memxor@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>, 
	"Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>, 
	Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>, 
	Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>, 
	Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, 
	pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, 
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, 
	linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, 
	bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 1/9] mm: introduce hw_pte_t for PTE table storage
Message-ID: <u457qwrnkaquvqfn4op2a4wcdflm6d4gzut5ii4ialbeqjiyfj@qpn5fu5kwn4z>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-2-usama.anjum@arm.com>
 <3db8233c-3785-444e-b2eb-3e5fc5cb2f17-agordeev@linux.ibm.com>
 <eef14e97-20cd-4b08-ae22-7636af049b09@arm.com>
 <4a42c498-58ca-46f4-819f-da14cfba154f-agordeev@linux.ibm.com>
 <52b5066c-64f6-40bb-9bce-365a18f24265@arm.com>
 <b40d4359-3156-4d02-9662-73bfeace607c@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b40d4359-3156-4d02-9662-73bfeace607c@kernel.org>
X-purgate-ID: tlsNG-16d1c6/1786441681-FD20877B-C043E738/0/0
X-purgate-type: clean
X-purgate-size: 1266

On Mon, Aug 10, 2026 at 01:20:00PM +0200, David Hildenbrand (Arm) wrote:
> On 8/10/26 12:09, Muhammad Usama Anjum wrote:
> > On 09/08/2026 6:45 pm, Alexander Gordeev wrote:
> >> On Fri, Aug 07, 2026 at 04:24:00PM +0100, Muhammad Usama Anjum wrote:
> >>> Thank you for testing it out on s390.
> >>>
> >>> As __hw_pte_t isn't being used yet in this series, would s390 enablement
> >>> patches add __hw_pte_t to this definition?
> >>
> >> I hope there is a better solution. As I noted m68k, powerpc and sparc
> >> may also be affected, so I would suggest to look into those as well.
> >> I would prefer s390 to use the generic one rather than circumvent a
> >> compile error in a custom way.
> > I've just checked all of these architectures by doing dirty conversion and
> > reached to same conclusion that __hw_pte_t must be defined like:
> >  
> > typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
> > 
> > I'lll add __hw_pte_t to this series. (Initially on last email I'd thought
> > that the first user would add __hw_pte_t. But it seems sensible to add it
> > now)
> 
> Yes, do it as part of the introduction. Also a good idea to mention in the patch
> description *why* that is required.

Agreed.

> 
> -- 
> Cheers,
> 
> David


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 10:15:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 10:15:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388073.1629280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtjVp-0001IG-P1; Tue, 11 Aug 2026 10:15:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388073.1629280; Tue, 11 Aug 2026 10:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtjVp-0001I9-ME; Tue, 11 Aug 2026 10:15:13 +0000
Received: by outflank-mailman (input) for mailman id 1388073;
 Tue, 11 Aug 2026 10:15:13 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anshuman.khandual@arm.com>) id 1wtjVp-0001I3-A2
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 10:15:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtjVo-00DyeO-A2
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 12:15:12 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7af62f-8faa-0a2a0a5109dd-0a2a4508e2b4-0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 12:15:11 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7af62e-f659-0a2a45080019-d98c6eacd970-1
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 12:15:10 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BBBEA1682;
 Tue, 11 Aug 2026 03:15:05 -0700 (PDT)
Received: from localhost (a085714.arm.com [10.164.19.28])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0350C3F86F;
 Tue, 11 Aug 2026 03:15:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786443309; bh=+szcqBCq9eZ2ua7vWX4x/+s1q8ODJlqcpxLyiJuSiwc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=V+Vm46x3ghCefqeO2I1n6DA88n8dnPA9fKF0KOYZamwYwLaVm1b44z72dYIEIsYC0
	 p/UxibT9bkIS6vm2g/03/53REk/x6Bjd7ZTy6XlUazb0cSaz7+p0GyYbiNAyjJgZGx
	 FyXK8Yk5Rfauuo195Y0NDG5YghHuk7t+gElvU4PU=
Date: Tue, 11 Aug 2026 15:45:06 +0530
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>, 
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, 
	Tvrtko Ursulin <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>, 
	Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich <dimitri.sivanich@hpe.com>, 
	Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Muchun Song <muchun.song@linux.dev>, 
	Oscar Salvador <osalvador@suse.de>, Andrew Morton <akpm@linux-foundation.org>, 
	"Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>, 
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, Nick Piggin <npiggin@gmail.com>, 
	Peter Zijlstra <peterz@infradead.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, 
	David Hildenbrand <david@kernel.org>, Pasha Tatashin <pasha.tatashin@soleen.com>, 
	Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>, 
	Uladzislau Rezki <urezki@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Masami Hiramatsu <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>, 
	Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, 
	Eduard Zingerman <eddyz87@gmail.com>, Kumar Kartikeya Dwivedi <memxor@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>, 
	"Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>, 
	Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>, 
	Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>, 
	Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, 
	pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com, 
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, 
	linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, 
	linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, 
	damon@lists.linux.dev
Subject: Re: [PATCH 2/9] mm: make hw_pte_t visible to generic PTE interfaces
Message-ID: <7xbai2nyu6nuyr6otqv556dnphpgwaqsmvwkqwoqwbh5nvj3ns@ddy5ezgvb7w3>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-3-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260806083926.1807279-3-usama.anjum@arm.com>
X-purgate-ID: tlsNG-c1860d/1786443311-CFED287B-77340A4B/0/0
X-purgate-type: clean
X-purgate-size: 2355

On Thu, Aug 06, 2026 at 09:38:40AM +0100, Muhammad Usama Anjum wrote:
> Later conversions use hw_pte_t in page-table checking, generic page-table
> helpers, and vmalloc interfaces. Include linux/pgtable_types.h from the
> headers that declare those interfaces before changing their types.
> 
> For vmalloc.h, replace the direct asm/page.h include with
> linux/pgtable_types.h. The latter includes asm/page.h, so pgprot_t remains
> available. It also provides either the default alias or the opted-in
> hw_pte_t wrapper.

Stand-alone header file updates are not ideal. Why cannot these changes be
folded in, where hw_pte_t gets used first time ever in the above mentioned
places.

> 
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> ---
> Changes since RFC v1:
> - Clarify that the header provides both generic hw_pte_t definitions.
> ---
>  include/linux/page_table_check.h | 2 ++
>  include/linux/pgtable.h          | 1 +
>  include/linux/vmalloc.h          | 2 +-
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/page_table_check.h b/include/linux/page_table_check.h
> index 12268a32e8be1..12ee6d16ad339 100644
> --- a/include/linux/page_table_check.h
> +++ b/include/linux/page_table_check.h
> @@ -7,6 +7,8 @@
>  #ifndef __LINUX_PAGE_TABLE_CHECK_H
>  #define __LINUX_PAGE_TABLE_CHECK_H
>  
> +#include <linux/pgtable_types.h>
> +
>  #ifdef CONFIG_PAGE_TABLE_CHECK
>  #include <linux/jump_label.h>
>  
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8c093c119e5a8..cf595608cc4c4 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -4,6 +4,7 @@
>  
>  #include <linux/pfn.h>
>  #include <asm/pgtable.h>
> +#include <linux/pgtable_types.h>
>  
>  #define PMD_ORDER	(PMD_SHIFT - PAGE_SHIFT)
>  #define PUD_ORDER	(PUD_SHIFT - PAGE_SHIFT)
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index aed121d729b01..b068e6ade4207 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -8,7 +8,7 @@
>  #include <linux/init.h>
>  #include <linux/list.h>
>  #include <linux/llist.h>
> -#include <asm/page.h>		/* pgprot_t */
> +#include <linux/pgtable_types.h>	/* pgprot_t, hw_pte_t */
>  #include <linux/rbtree.h>
>  #include <linux/overflow.h>
>  
> -- 
> 2.47.3
> 


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 10:58:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 10:58:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388092.1629289 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkBT-0006uj-RN; Tue, 11 Aug 2026 10:58:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388092.1629289; Tue, 11 Aug 2026 10:58:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkBT-0006uc-Ob; Tue, 11 Aug 2026 10:58:15 +0000
Received: by outflank-mailman (input) for mailman id 1388092;
 Tue, 11 Aug 2026 10:58:15 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anshuman.khandual@arm.com>) id 1wtkBS-0006uW-VT
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 10:58:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtkBS-006XI1-0E
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 12:58:14 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7b0045-e002-0a2a0a5209dd-0a2a450b874c-2
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 12:58:13 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7b0044-b7e8-0a2a450b0019-d98c6eacb6a2-1
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 12:58:13 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 44D0C1682;
 Tue, 11 Aug 2026 03:58:08 -0700 (PDT)
Received: from localhost (a085714.arm.com [10.164.19.28])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 820043F86F;
 Tue, 11 Aug 2026 03:58:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786445892; bh=E2Q5I65meboDct+4hfaKsQDzSd1S1/tsAKEVH3DzJwo=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=tKGjJivwGyrqmHqJQhgHkKc1NYH5dpUS0DWnYV/mVHQACS1frf2TRd2UhTyMG8JvA
	 Bw0BndUTcgOm1QZBl4JI/V5svJA1QNwOZVE/G2oL5rd2q44W5xc5apxl/s1/v2NISQ
	 JQrQY7r9UAbIHixEwxX6nTsx2ykLpYcEoEZ681SE=
Date: Tue, 11 Aug 2026 16:28:09 +0530
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>, 
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, 
	Tvrtko Ursulin <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>, 
	Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich <dimitri.sivanich@hpe.com>, 
	Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Muchun Song <muchun.song@linux.dev>, 
	Oscar Salvador <osalvador@suse.de>, Andrew Morton <akpm@linux-foundation.org>, 
	"Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>, 
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, Nick Piggin <npiggin@gmail.com>, 
	Peter Zijlstra <peterz@infradead.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, 
	David Hildenbrand <david@kernel.org>, Pasha Tatashin <pasha.tatashin@soleen.com>, 
	Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>, 
	Uladzislau Rezki <urezki@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Masami Hiramatsu <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>, 
	Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, 
	Eduard Zingerman <eddyz87@gmail.com>, Kumar Kartikeya Dwivedi <memxor@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>, 
	"Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>, 
	Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>, 
	Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>, 
	Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, 
	pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com, 
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, 
	linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, 
	linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, 
	damon@lists.linux.dev
Subject: Re: [PATCH 3/9] mm: name pointers to copied PTE values ptentp
Message-ID: <e7osakog3yvdewhdlrk3bsp27pwt2nnhroeb7zihlfxyjotarb@rwxkcb25crh3>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-4-usama.anjum@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260806083926.1807279-4-usama.anjum@arm.com>
X-purgate-ID: tlsNG-42698a/1786445893-1AEDE9EA-943E194E/0/0
X-purgate-type: clean
X-purgate-size: 3571

Subject line is very confusing. Perhaps something like the following.

mm: Rename pointers to copied PTE values as ptentp

But even 'copied PTE values' is not very clear as well.

On Thu, Aug 06, 2026 at 09:38:41AM +0100, Muhammad Usama Anjum wrote:
> The hw_pte_t conversion must retain pte_t * for pointers to standalone PTE

We need to explain what is `standalone PTE values` first.

> values. Name the value parameters ptentp in the install_pte callback,
> write_protect_page(), and guard_install_set_pte() so the later mechanical
> conversion can distinguish them from pointers to PTE table storage.
> 
> Some functions already use the ptentp name, including:
> - madvise_folio_pte_batch()
> - folio_pte_batch_flags()
> No need to convert them.
> 
> This is a naming-only change.

Small nit - s/naming-only/rename

The commit message needs rewrite clearly explaining the following details

- What are standalone PTE values
- How these are different from HW pgtable pointers
- Change is just a rename for pointers into such 'standalone PTE'
- These renamed 'ptentp' here would be used for skip or replaced during
  upcoming mechanical change via a script
- No functional changes intended

> 
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> ---
> Changes since RFC v1:
> - Update the description for the architecture opt-in conversion.
> ---
>  include/linux/pagewalk.h | 2 +-
>  mm/ksm.c                 | 4 ++--
>  mm/madvise.c             | 4 ++--
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
> index b41d7265c01bc..c34d826c5e4a2 100644
> --- a/include/linux/pagewalk.h
> +++ b/include/linux/pagewalk.h
> @@ -89,7 +89,7 @@ struct mm_walk_ops {
>  		       struct mm_walk *walk);
>  	void (*post_vma)(struct mm_walk *walk);
>  	int (*install_pte)(unsigned long addr, unsigned long next,
> -			   pte_t *ptep, struct mm_walk *walk);
> +			   pte_t *ptentp, struct mm_walk *walk);
>  	enum page_walk_lock walk_lock;
>  };
>  
> diff --git a/mm/ksm.c b/mm/ksm.c
> index ad05d7791307e..11d50518d02e9 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -1292,7 +1292,7 @@ static u32 calc_checksum(struct page *page)
>  }
>  
>  static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
> -			      pte_t *orig_pte)
> +			      pte_t *ptentp)
>  {
>  	struct mm_struct *mm = vma->vm_mm;
>  	DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, 0, 0);
> @@ -1371,7 +1371,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
>  
>  		set_pte_at(mm, pvmw.address, pvmw.pte, entry);
>  	}
> -	*orig_pte = entry;
> +	*ptentp = entry;
>  	err = 0;
>  
>  out_unlock:
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 07a21ca31bad4..c324cc991f841 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -1101,12 +1101,12 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr,
>  }
>  
>  static int guard_install_set_pte(unsigned long addr, unsigned long next,
> -				 pte_t *ptep, struct mm_walk *walk)
> +				 pte_t *ptentp, struct mm_walk *walk)
>  {
>  	unsigned long *nr_pages = (unsigned long *)walk->private;
>  
>  	/* Simply install a PTE marker, this causes segfault on access. */
> -	*ptep = make_pte_marker(PTE_MARKER_GUARD);
> +	*ptentp = make_pte_marker(PTE_MARKER_GUARD);
>  	(*nr_pages)++;
>  
>  	return 0;
> -- 
> 2.47.3
>

How did we ensure that the above changes are comprehensive and nothing
else got left in here ?


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 11:26:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 11:26:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388105.1629298 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkcR-0003Jr-Us; Tue, 11 Aug 2026 11:26:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388105.1629298; Tue, 11 Aug 2026 11:26:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkcR-0003Jk-SA; Tue, 11 Aug 2026 11:26:07 +0000
Received: by outflank-mailman (input) for mailman id 1388105;
 Tue, 11 Aug 2026 11:26:06 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wtkcP-0003Je-Ps
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 11:26:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtkcO-002jSk-KT
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:26:04 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7b06ad-bab6-0a2a0a5309dd-0a2a450a9df2-44
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:26:03 +0200
Received: from [52.101.65.33]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7b06ca-f2d2-0a2a450a0019-34654121ed66-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:26:03 +0200
Received: from AS4P191CA0033.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:657::20)
 by AS2PR08MB8747.eurprd08.prod.outlook.com (2603:10a6:20b:55f::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 11:25:57 +0000
Received: from AMS0EPF000001A9.eurprd05.prod.outlook.com
 (2603:10a6:20b:657:cafe::7a) by AS4P191CA0033.outlook.office365.com
 (2603:10a6:20b:657::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Tue,
 11 Aug 2026 11:25:57 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF000001A9.mail.protection.outlook.com (10.167.16.149) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 11:25:57 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16)
 by GV1PR08MB8033.eurprd08.prod.outlook.com (2603:10a6:150:9a::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 11:25:13 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0315.008; Tue, 11 Aug 2026
 11:25:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=LR8XLs2K7Av+AN8MFbA38rp+OtYJPybhHowexY5/w4ouSFJJ7P/yP3vj7Cm2IeTMlZUj1pQ0O/2xjCMBBxbLjGLOU55YHqcINNoh6I/SyXT2Vo8NviLhu9ja9UKLZ/MUPzP2Kz1b2WXJPpwW1Fxm68JpYbJBXvmvh3sW1r9D4hLkQDayxSjkruAHPxmAnkffcN1lRWpMdfWrzDgEFtzrarXmMiFXblxTSucUPpQetKHzyHdwmnPeiPOsTpNg73awK3ttMZ8tT/0KkdliCas5KKrRIIfbM4WvDorehZIAmpcMl1cijjZcpJUC9+61eQBB5En17HO8PVWcxM2YYaNCcA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2Upa8H8lYci2AEeo5pg4WAAxc+FTB6t5I5dTvHmgOG8=;
 b=arhJojw6f6UGnxzfNGNedm3EQ31RL+LDDUtCFjgoxJgxH0RGYktGR8/+2qcqTfubb1JHgR8nHmVO9oOC4zjDWAJq81J1hXJ8TQRMZU/Xd+qMZVtX6Szi1NvtBpGif7CZRlZt06G5UJU3ijGMpdRGZRgKDjDJjDAV0achaWfQ8bXAMxQICwThYJ6+MhlbSbWpy5cT7ZXJ5iJz8Ql3kzozGUMZcYJbC09tm/1mI8nOia3fX5Ed/jQGw0p6HjBIJhV8g3q2fZIvxwKbDG0HTiroHKak2ZXnLMQ0iNBOJgkEXbBp42CIW9wEmUCx91ZFp/Y5npRVsUrr0W7dnu36MqtQ2A==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2Upa8H8lYci2AEeo5pg4WAAxc+FTB6t5I5dTvHmgOG8=;
 b=ZDqaLm7gWhUITSg3PvlCRuHDeaF0jtytI9AB0HVCOFjQL41efiVP1AEJKscTP+JFRYc3f4vwBxX6ZAv4Y4PTsCJUFq4gLgyuAFM1k5WCHt84HzI07ZD2DqdbEand2v5A73ThSJ6I32hkVU7sgGurUuuZJ0gjrk4FBCJjr8mRbic=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rfpSa1oKx33iClOdPa8JCMayv6kb2mS5cLSdASv8gqPN7G9jRNvNZr0BRV4nAn6sr7qPWueIE9ojHmSandXoWV6JVIpWCGw0mabIwDi3hHXaLXz/d09eY9YS/qmXGiad6Nx7LwvsP3kdsAo4tvgS/k3HhLmg2aGodcwlkU1qKK2+WtV5Z5feAlL1aVtakk4g/bMK/rfm4u6YKvP7XXcz9/i8d0vgwi39NfSQ1znyncgm9lObFdDx6hgSgY61WahCZgSNmpzHZZeo5EpCJhHGjpN3AhYm7QSKGEWktVwtPMb8mZ/r7AU9IqrFuiWeqKZGgdDb0JOBgfrWxcD4VVqDPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2Upa8H8lYci2AEeo5pg4WAAxc+FTB6t5I5dTvHmgOG8=;
 b=wPp6P2gJ4yNQDU7fWUD1/g6d6JagwvLy15xCBXNctqNPVJNxT71iw0065K7P6c05Yufxg2vVpUuu1t5vH85kR7TRcPvqyfqE4PpXf6TAwLs89iK9hg0BqavgDwN8+AFGzg+osrO2SGItVo/uJYHvmGhmr1GRm5CljI++dqBRw+wB0W+Td9dzJ9gI8qkjy1cSs7hPwJtlQDELDD7lUnOQFut0LFcDCBf3Y/x99uqfZF2ujpT45Smb/nAIPnrxA1r7ex+SOUNkIqhY2cmz+HO2/YWS3qbYInruq9XQi0dBfnhbKn5vsoPQbFeEi7DmozIPRLvwFmokHwABpcYYEaWsiA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2Upa8H8lYci2AEeo5pg4WAAxc+FTB6t5I5dTvHmgOG8=;
 b=ZDqaLm7gWhUITSg3PvlCRuHDeaF0jtytI9AB0HVCOFjQL41efiVP1AEJKscTP+JFRYc3f4vwBxX6ZAv4Y4PTsCJUFq4gLgyuAFM1k5WCHt84HzI07ZD2DqdbEand2v5A73ThSJ6I32hkVU7sgGurUuuZJ0gjrk4FBCJjr8mRbic=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <85286df7-363a-4671-bce8-8157ae5c8f02@arm.com>
Date: Tue, 11 Aug 2026 12:25:08 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com,
 ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
 intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
 linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
 linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
 linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
 linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 2/9] mm: make hw_pte_t visible to generic PTE interfaces
To: Anshuman Khandual <anshuman.khandual@arm.com>,
 David Hildenbrand <david@kernel.org>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-3-usama.anjum@arm.com>
 <7xbai2nyu6nuyr6otqv556dnphpgwaqsmvwkqwoqwbh5nvj3ns@ddy5ezgvb7w3>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <7xbai2nyu6nuyr6otqv556dnphpgwaqsmvwkqwoqwbh5nvj3ns@ddy5ezgvb7w3>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P265CA0164.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:312::13) To VI1PR08MB3421.eurprd08.prod.outlook.com
 (2603:10a6:803:80::16)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	VI1PR08MB3421:EE_|GV1PR08MB8033:EE_|AMS0EPF000001A9:EE_|AS2PR08MB8747:EE_
X-MS-Office365-Filtering-Correlation-Id: b28951d4-3669-499f-4352-08def79b5085
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|7416014|56012099006|10067099003|4143699003|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info-Original:
 S6S52yYdxtDtrbu3+R3LqA1hBff1nj/2rLzT9GQ0+Ov8ipkmk0O3mjgrS/DUQ1/AFHfZWm9IZqKqqBU43nupYPXdHctB4A1PEZb9VDmjzZVISz3QfTXgSdr/68htGFhRc/j48gtQ4l6+L4ZW1nZja24rc6nWlSCYCtCWwtrMSs9R7h+dNpcLi2YgHViFI9Py9PcceBHI2y1hbD3tgIm9e45D/TvCqL/DDHF12QMIcti8yIvgdyO09z7AYYF74iZeACzU7uBne+6EXxl5OTZFg6QDzYUP73s7GSAEpT8D0uC32vGvMHjG8m+SK/kgAzP+Nmx82vnMrK3xq8uA+VWijeEIKRH0QxmnSwYsuk1AtsGokPKiK6I6K7ncpwqGz621yibL1B1X/TtMxwipICwYVw/YV+fP2FF6t2BPeh9+LOL+/jJ5P4Q0nEQm8VGkWH7CqIW3RZfdDrfhmWwygRbb4FGuEulKGS0Zb9XSJgqJ/zyiqn5W4UNQbXYIOTge5Vv9t0ogYUJ+UEirnawh/Dtsl7J7crALwP6tP+AkARGX3R1W7ZcuiL99OIu2CO3DNYis4WRH+XIaGeh4GtZWlHcy/Q/iSOzNy8TKPbP6PMGBNW2rO6bfWb0+8p3gurQ1AfDE8vOseTc5WWE/ndAm09GMDOSotmNmMi7644PyBtk9BhE=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(7416014)(56012099006)(10067099003)(4143699003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 HcK3rNnbwnlUGSwsDidSABGG1HQSoO72TkmhaC28ctmrJg8jVmz1OTzbiHJyHscmR1RSZ/MVJf3UF+V1Dje2C1z7jQczHvpZZk9NqnA1pIaWUyQ0NJGWUP8OQZQ7BxNR+CvvvJU4JV3+pgE+pVX/LgqCg/GXYo9PNipkTyJMz9mRgXBJrvoOJFLveHRnnNj6ydDRiY+xZEs2n9JOMvPO5HLQY82ufTlmcOJ3FL9PskIALGq/04QKaGj1BuKnnTOeCwktvBeWr/VO5+ier2emXtvzMh/0Yd8zfkfTpnuAfv7qGuIggIUVnYNjisH2v/7Pxh+mGQifH9TryIJK1GhcFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8033
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001A9.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	eedea4c3-0f48-4936-b2b9-08def79b350b
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|36860700016|35042699022|23010399003|1800799024|82310400026|7416014|376014|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	6KeX0Y8hlJ6T8DzdMW1+mLWuzvKwSvsLtVaM1FZSBYQFe2/wJ9AM2jY6ZKYld4Xl2hdLlFmzsPGUB5r4A4gd7B3BDO7zfp+pOAwufqbeXfYmrHSUmyqnHgYGKQTtPxLxVvlkmrZV6SHU2W4jdHN5JitLujQKDD98cTOrNXmnw2rMrGNzhPel/sMCrrxUOwcDyNJzMhjNvTihybUfZEVVS6KX6L7TIuHg6Hrt5ougauduq1FrBUL+6J76wEjtl/xKDnxve5EXBb7d1FXkUSfEgNgAHCwP0vZIRt40S4BHfeSviAlN4pxqH2tUK41SRVj5I7A6f+xUG9WT0yFTvXowhCvXxrlE3eD+2PiLSAOujzLikwzfHMtN9knYkKcDtMFMcq+/iqei+pN0DkXdGTnlV5+aILrwkI5aQvTaP5+NzPWrhEmc3B+TO+4dcPLY1VlERE1j70QDf71kHs4R3st0+eZpsjxeFEOV3sxJo8/V+bdpg8iT81OrvEvWHFyrFBPyta3aIdfh0/WyiKDrN2Lp0d8WTKmHlQFnlvDseOO3dPGPLGROGxMiC/xqCne8h2QWiQKpjdh3pJipAoo3nL0btv/sUspBv1jsoWkKSEk8X3xlhoLcq4AWhm3rWFtoTS3eh1ZCxS7IbIcbzCEVnAAXUrXMliI1AAoko08NSYK6d4Fj3BLijKjNKhwfbDVCGGcgRmz0pcNOwhIIpwUuMdFgsg==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(36860700016)(35042699022)(23010399003)(1800799024)(82310400026)(7416014)(376014)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	PpJWUGBI0WXngUjmkkmjZ8b9gVABqPlGGdB9in5/n5SVZR/asrpHB7LtoHfG4dL4AjWVyKTXpsEwcsX+jvKJYl51kZwclhNMX8lZECOJjm1ho6qMO3JWlgYLZbH1Fq9uRoCjmRSkf89Wu5QQgQiJQn7NgXUp1gxZDG+bm7d6kU7ubZhtxXLe55hhalbMJFecFRP3KRfX1w+j6xBke2NFN/V2E7odXBw/sjlfrNmeBofeAKv/j7gH42MDjAGWfA8EQwUOF8zhAC42fhaPcfmtjCYKn4wJElqHNc37lF105kHubkPzm7VB2ryGNn/JgYeP0MlcOcYG1Dn5KUpILs7lTmk+Xjb5U9iSSjI4JApKKGTiYPMVqrcCIQYYHQEHa09ZjxJEZjARr7DDEpsYzqGq0xo6ca/UhZFYZtmedtQ2phr8KIsEK0Kbi9zCAxauV+9Z
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 11:25:57.5424
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b28951d4-3669-499f-4352-08def79b5085
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF000001A9.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8747
X-purgate-ID: tlsNG-4011c0/1786447563-583CCCFC-6A690844/0/0
X-purgate-type: clean
X-purgate-size: 2742

On 11/08/2026 11:15 am, Anshuman Khandual wrote:
> On Thu, Aug 06, 2026 at 09:38:40AM +0100, Muhammad Usama Anjum wrote:
>> Later conversions use hw_pte_t in page-table checking, generic page-table
>> helpers, and vmalloc interfaces. Include linux/pgtable_types.h from the
>> headers that declare those interfaces before changing their types.
>>
>> For vmalloc.h, replace the direct asm/page.h include with
>> linux/pgtable_types.h. The latter includes asm/page.h, so pgprot_t remains
>> available. It also provides either the default alias or the opted-in
>> hw_pte_t wrapper.
> 
> Stand-alone header file updates are not ideal. Why cannot these changes be
> folded in, where hw_pte_t gets used first time ever in the above mentioned
> places.
That's correct. This patch should be merged with the 3/9 patch. But that patch
is already too much big as it was generated with the help of Coccinelle. So I
kept it separate.

Do you still think we should merge it as its a special case?

> 
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
>> ---
>> Changes since RFC v1:
>> - Clarify that the header provides both generic hw_pte_t definitions.
>> ---
>>  include/linux/page_table_check.h | 2 ++
>>  include/linux/pgtable.h          | 1 +
>>  include/linux/vmalloc.h          | 2 +-
>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/page_table_check.h b/include/linux/page_table_check.h
>> index 12268a32e8be1..12ee6d16ad339 100644
>> --- a/include/linux/page_table_check.h
>> +++ b/include/linux/page_table_check.h
>> @@ -7,6 +7,8 @@
>>  #ifndef __LINUX_PAGE_TABLE_CHECK_H
>>  #define __LINUX_PAGE_TABLE_CHECK_H
>>  
>> +#include <linux/pgtable_types.h>
>> +
>>  #ifdef CONFIG_PAGE_TABLE_CHECK
>>  #include <linux/jump_label.h>
>>  
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index 8c093c119e5a8..cf595608cc4c4 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -4,6 +4,7 @@
>>  
>>  #include <linux/pfn.h>
>>  #include <asm/pgtable.h>
>> +#include <linux/pgtable_types.h>
>>  
>>  #define PMD_ORDER	(PMD_SHIFT - PAGE_SHIFT)
>>  #define PUD_ORDER	(PUD_SHIFT - PAGE_SHIFT)
>> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
>> index aed121d729b01..b068e6ade4207 100644
>> --- a/include/linux/vmalloc.h
>> +++ b/include/linux/vmalloc.h
>> @@ -8,7 +8,7 @@
>>  #include <linux/init.h>
>>  #include <linux/list.h>
>>  #include <linux/llist.h>
>> -#include <asm/page.h>		/* pgprot_t */
>> +#include <linux/pgtable_types.h>	/* pgprot_t, hw_pte_t */
>>  #include <linux/rbtree.h>
>>  #include <linux/overflow.h>
>>  
>> -- 
>> 2.47.3
>>

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 11:28:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 11:28:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388116.1629308 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkeT-0003zK-DZ; Tue, 11 Aug 2026 11:28:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388116.1629308; Tue, 11 Aug 2026 11:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkeT-0003zD-9W; Tue, 11 Aug 2026 11:28:13 +0000
Received: by outflank-mailman (input) for mailman id 1388116;
 Tue, 11 Aug 2026 11:28:11 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wtkeR-0003z2-LU
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 11:28:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtkeR-002jyH-1j
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:28:11 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7b072f-2eae-0a2a0a5409dd-0a2a450ab1f4-42
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:28:10 +0200
Received: from [52.101.69.14]
 (helo=AM0PR83CU005.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7b074a-f2d2-0a2a450a0019-3465450ead9e-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:28:10 +0200
Received: from AM0PR10CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::12)
 by DBAPR08MB5591.eurprd08.prod.outlook.com (2603:10a6:10:1ae::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 11:28:02 +0000
Received: from AMS0EPF00000197.eurprd05.prod.outlook.com
 (2603:10a6:208:17c:cafe::1e) by AM0PR10CA0002.outlook.office365.com
 (2603:10a6:208:17c::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Tue,
 11 Aug 2026 11:28:02 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS0EPF00000197.mail.protection.outlook.com (10.167.16.219) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 11:28:02 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16)
 by AS8PR08MB7790.eurprd08.prod.outlook.com (2603:10a6:20b:527::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 11 Aug
 2026 11:27:27 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0315.008; Tue, 11 Aug 2026
 11:27:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=qoS21m4gqpl2A6mSYODK138AgZwscC6N6PBwKh0DY+U4/TY/d+9O22I+jnT6RZQ1qRmAbHotdmjz24h5HLuMHt2xruX853hADfuN6vM3ogka7+wik6xxKKcTFwHu7PtzYakC6Myv0tXrUbbdk1QdAOhE/6C3RCxk18Z5okURGuqvdXeUhwSCteSgY/PFWRSf/ibAUzhFYrFJFUzMdZYOsC5p7ihZV6k89/8jsGVt5koH2dtKgIS6T9ydUNiqRKgiv/tuhR+Wwz6RUfw8Tgf4hhzLqCY+dDo+bvZwodjNnzpyNCFt70WuLC6WYUXgkPGwTinVi6xnlV43aTLXM4CJzw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jJvqjQtYhPn+5rlwiCulIyzL4lgkY2x9AtSglnQ/lYY=;
 b=QVqwLDL6dU8ENykUrSBX3azgWcaNBU6rqxz+4rZeM+oyBC8GK/x3lCMDcem5YrIRmulghNj6VZuwOTenlfLgwKxoRyvMvv4DcMLhMsYZysLvJ+bXVj/umUVRJ+GXV6RG9+cyZPlmF7smr3sIzUdtipk3EJEAjvh/cCSxy4yW9t6nm4GaD3LzSwVuTpWgTr6IqF2QCAn2ay0QSAMvb6hWnHsdsYwC49R0ozqycBMAzPrkyb8zntGg9EL26TKTJ0RoaOp3AOtfQ7ZObsG5F01dT/jSmt/ufiJ25S0XpCnqXiFUiPX8vCaGjUlPl9KLA7lmU4xdE8T137K9YLQWtx7kyw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jJvqjQtYhPn+5rlwiCulIyzL4lgkY2x9AtSglnQ/lYY=;
 b=ZUpGE89U93omH662/JXtCNc15E3velUKg/MY+8EtCB58awMrAJ55DvQpiyUbXmRWgGbeUbeaF1kB4Mf/vJIUzh9u5D1IYs0UbuSUkN9eR4mUz6yAUzJl+btZ4QsOeyW8mPHysbYosEhYL1r7OxUUxylALgW+wLqgDL+K2823ehs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TtAUGRcJ6AWlPqIQMLOFqdpWYxlTC4E2nUnOT3chDTEIsmQcnbc7C4Y2sSB+uTDKwOvo2ZRT6Em8+BPrJnX7eXUTotZQn8/QVz2bJayIE79ffJW5RQRmoE9taCWO1CRXKXSMtue7nY/k7SBTekqwHh499iyRUbYpsQOFjkQrA0ckSpbIO9s0kAJ7nZE0iUrOiqvUKvT1dA3BtLcz5cjBQsNYUdJq+D9dJ9nsXo7du0pJvj30fC46fGjK2Fb0oDCav9SQ6O8F+n4Ny5fHFBYw4zeGzzIlme6w72w8fxAFJJS2I8DsZiwUGAxrBHih8QF8wD9eb0Gf3vg1RbgJMx1eYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jJvqjQtYhPn+5rlwiCulIyzL4lgkY2x9AtSglnQ/lYY=;
 b=BUubzy05M5a0o/rrnDSXc2KdVNLdPVbJYF1vXwuI3/COJyE/qtHU44Dl3N54SOa/fu/35NVq+uVAGrPBVNXLVeUge3lOZz6SgrGkjDkjsf0CCohtaUm397MMHWHoKlzfgWUPT0NDVZ/OILkn8pomnIoZgwZ7XLrU1HMBt+mc3XClJEnNlKc2NFjlgVA2oaBTo1lN3Mup6A5NInGri1ekKwe78rvvGzamNFBrREnJ2nEKadoQ5NFB3sW9jYunsvp1SIMclM93siICuij+o1E10npQlj8GB80SeLV7W2OsvQivrs79f+K5bjWjAMnQrVdUTAr1zajM6lpYD7FbYq4NXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jJvqjQtYhPn+5rlwiCulIyzL4lgkY2x9AtSglnQ/lYY=;
 b=ZUpGE89U93omH662/JXtCNc15E3velUKg/MY+8EtCB58awMrAJ55DvQpiyUbXmRWgGbeUbeaF1kB4Mf/vJIUzh9u5D1IYs0UbuSUkN9eR4mUz6yAUzJl+btZ4QsOeyW8mPHysbYosEhYL1r7OxUUxylALgW+wLqgDL+K2823ehs=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <00e4f324-18b1-4120-bdd0-2715cb8c8481@arm.com>
Date: Tue, 11 Aug 2026 12:27:24 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com,
 ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
 intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
 linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
 linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
 linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
 linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 2/9] mm: make hw_pte_t visible to generic PTE interfaces
To: Anshuman Khandual <anshuman.khandual@arm.com>,
 David Hildenbrand <david@kernel.org>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-3-usama.anjum@arm.com>
 <7xbai2nyu6nuyr6otqv556dnphpgwaqsmvwkqwoqwbh5nvj3ns@ddy5ezgvb7w3>
 <85286df7-363a-4671-bce8-8157ae5c8f02@arm.com>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <85286df7-363a-4671-bce8-8157ae5c8f02@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0528.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:2c5::10) To VI1PR08MB3421.eurprd08.prod.outlook.com
 (2603:10a6:803:80::16)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	VI1PR08MB3421:EE_|AS8PR08MB7790:EE_|AMS0EPF00000197:EE_|DBAPR08MB5591:EE_
X-MS-Office365-Filtering-Correlation-Id: 844557b4-3d08-49e0-57de-08def79b9ace
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|7416014|1800799024|366016|23010399003|11063799006|56012099006|10067099003|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info-Original:
 MTpsf3IvsMf7LVKWeyhvKaEhr96cF7yvH7aAkJB0bN7Dz2cNvpHXLH1fyHZGxfSN239QNIaI0+Jcok45W8o6dR4xsKN68cgbWwRp1dzQPww8VsZXlkd40hV+KhrcssadBi6n0BtjeK57do7GEQf9oFzJbDCKBGKEr/aV+5jAIFyIZeHeh5kMOB9Qrjk9lo8ssRQA+eChm6iIsXGtD+CSOW4NioxM8SGHVL3AteUAnM8e4g774whpKM+LAnfDDjcLSX4MFF9hSkCzLPofT/OqYQzv+EwMtqda4QQ3+eunavGYKJYsOeegTMveEFkeBGvj6JTMm/hOKqolApr0MUGBdr41GqT/ssdVZNPKYsYEt9xqPyShcC5PyLIgKCnX0v/tTebELHCxdk51b5+2EAOWhVI77v4UDPfelMHZNmq21/aREZCxR9W6n0o5k4YLX5a3uijZLV6UVlfpJNgZ3QuTO2Bc6BphO3IM+ARnj71zys1h3r+Kd1pb9EbS1Jq989xaLY051Ts6i4KRA6aMFZo9LueNV/CeTUhnbiREzQtnXolfLW9GvmLGkm7fnud0MoPESxMefIj4l0ubl/7OWFxpNp2b3IZPQBAFKTvfGCVWSb5hVvqbhexADPkBEFLs81yOY+RJW4pds8/DrhzuSgfKHQo42UznNPz83AM+zvWSmgA=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(23010399003)(11063799006)(56012099006)(10067099003)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 hdQ7nn26YN7Vq0hE6oTx+kKoU45kJvqrMn0abldXFwKud0iJoW85VnYLUJpGpJvIJxgBFh5raADG36uRwV2AaPoefUNSSsVWUW5Y0zg8xQjIC+gS+uPl8TNSAFyKERlMdMsUi0xE67L6J47pXwlISmSbpRVwkLFrYG++90jViVROoUAQ0CjGmPthS/NBEXTu9BnqGOFLyjUMftDMlwsgCQzUj+8ciRZetLxOt7/pjNpvjEIqP4rEUksxKtNuI3nmtRimaXmtBqx+3z5zVXMWLYpAPEr4PTzqyXYAU22s9MqBWyN4hojABhxaeNE2vm0Mc7y2GYdrTtg6FpMnYERIRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7790
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000197.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	18d48398-875e-496f-3753-08def79b8605
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|82310400026|1800799024|14060799003|35042699022|36860700016|23010399003|22082099003|18002099003|11063799006|56012099006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	2EUmajtFjD2DNOQiqDYJhx/duHHhmL0owb4dTyfZ9bsnUL0uoX2XHDDcNEc8ffXH0yXFMc54S3eDdd3FK7Rgvf4oSdqjiuUijkmLVLhvYqiCS6p8fA/HIzvhi6DErNoUOFkJy4QHGrQyelLZh56K5hTOBUnG1R5SLFbyT4aPXHyPwsw8wUBIP9Y9rXgptG6nI/+P7u4RJRImjY27HbdHVXIJgwWS6rL/yVVXlDfZuS4eh/6+ZD5HHB9ucDqX4VFdjRdQxF8HJxek3eSNARe4FG/qKSh70eBDyPnSouR7KyaGJMR/2iMOrQaTK7DsGNaNX9Rm2OyL+30OXWY/2qczX+GyRC5rN9DAiEQhB3Nwo4lOeinyDhdoGapUIK+wGhd2NmJ7dikDhU/t+9ZF/O0XmDzmqlpA16nEikeqk4T9qWAuMIphpCWAnKhVQ0lg0uDbNpFs7KJXbDVsHyPCmrHptMgrtBPYXWY7zodgjZzIcSCYwgXWfLiBRhg6tbathu7RR3dFRTSo4E0WFqB9nQYl46Pyb4ttMR/EQ3BkRR83ob34C+egtvZWEdiZtbTCwt5jBuwjLoWW2cFDMx6CMCdAgWQz9boCtXX+LZNxDTVtT2tu7m0Y3zuKxbu+sK5MaVwhDmgDFOgKIqWUBggriZgqwdFaqZsSSnIl4BQlXlIEigG9yMV6bK1RxorlpjUUuOJJMGm8LrT2Y7fiutRFecm12w==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(82310400026)(1800799024)(14060799003)(35042699022)(36860700016)(23010399003)(22082099003)(18002099003)(11063799006)(56012099006)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	WyhUxGQhEoSVrTLtM6KTQBdls8wJsW8gVWLkbWdx6cT7Xk/GYLPsBmlh93x9ztJFgtKrG41K/BR325MTqhuTQWTOaCrXraK0rMkVwnxR47oSdh9fsdqsKI+B3VpHMqo4o/Hv/BDlEsUXshXASkbsuTmzu1uD1bz0cGpBPcmOfP+Iid0iyfWDi72D4I7Ue+JJkSYEQYbepcZRsEhuGUIVVkfPWqPOga74+qtzICPnzDmuWc7QVcFVVVv0fZsfk7ZGiKMz8epspjJVn9Q/22nE55LUCy6f3tDgfOUCAEc3sw7T0cSYCJK554b7Cfd0iG/qiST8q0ESTYex1eiK8/ENww5D0y1dJNo92UpI+ykfXr+eBR4Azp5L80JDcstN4cax67P2PQm3jW1TJPF8UYWxA82cG2ywWMYG/z97+a9N57pgyA+k9Yizy3VGl1dJjFYh
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 11:28:02.1748
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 844557b4-3d08-49e0-57de-08def79b9ace
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF00000197.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5591
X-purgate-ID: tlsNG-4011c0/1786447690-50ECACFC-EC485AD4/0/0
X-purgate-type: clean
X-purgate-size: 1210

On 11/08/2026 12:25 pm, Muhammad Usama Anjum wrote:
> On 11/08/2026 11:15 am, Anshuman Khandual wrote:
>> On Thu, Aug 06, 2026 at 09:38:40AM +0100, Muhammad Usama Anjum wrote:
>>> Later conversions use hw_pte_t in page-table checking, generic page-table
>>> helpers, and vmalloc interfaces. Include linux/pgtable_types.h from the
>>> headers that declare those interfaces before changing their types.
>>>
>>> For vmalloc.h, replace the direct asm/page.h include with
>>> linux/pgtable_types.h. The latter includes asm/page.h, so pgprot_t remains
>>> available. It also provides either the default alias or the opted-in
>>> hw_pte_t wrapper.
>>
>> Stand-alone header file updates are not ideal. Why cannot these changes be
>> folded in, where hw_pte_t gets used first time ever in the above mentioned
>> places.
> That's correct. This patch should be merged with the 3/9 patch. But that patch
> is already too much big as it was generated with the help of Coccinelle. So I
> kept it separate.
> 
> Do you still think we should merge it as its a special case?

Sorry, I wanted to mention merging this patch and 4/9 patch (instead of 3/9 patch) in
my previous email.

 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 11:37:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 11:37:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388138.1629348 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkn9-0005wR-GS; Tue, 11 Aug 2026 11:37:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388138.1629348; Tue, 11 Aug 2026 11:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkn9-0005wJ-D9; Tue, 11 Aug 2026 11:37:11 +0000
Received: by outflank-mailman (input) for mailman id 1388138;
 Tue, 11 Aug 2026 11:37:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3@swg.vates.tech>)
 id 1wtkn8-0005wD-9p
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 11:37:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtkn7-002mMV-3y
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:37:09 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3@swg.vates.tech>)
 id 6a7b094f-8faa-0a2a0a5109dd-0a2a4508d310-48
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:37:09 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3@swg.vates.tech>)
 id 6a7b0964-f659-0a2a45080019-b9ff1c12b5c7-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:37:08 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ff09caa3e000c4f3.005 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 11 Aug 2026 11:37:06 +0000
Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194])
 (Authenticated sender: anthony.perard)
 by mail2.vates.fr (Postfix) with ESMTPSA id 18AC5836DF;
 Tue, 11 Aug 2026 13:37:06 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=HbKT3tjKmo2Wqu6bcz55wVTzl9OCGMakPKGimwVDDKU=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=rF/snwwMgKIg3PZvgsaKdHFLk475gdhoAK9OVwJoTzPGUhDNeliqWHpB01yK05cKD/dzS3Vff
 O2YN28Pmbr4Vb2NuVlZ2OzbKbzi46HhcB6tFFKEFW7ZawKPF0kCb2iVzAXKFLcKJcaIVyDDAh9l
 WZEqCZ/Em29zECPV6E03tiLKVVEtYFVEkFewto96FoycOulA9vkgToOvwpYSovThDlpNshSvHhY
 Ed1URNcXln4fGn+ptXg0Ve2Twhi7K+pVYaOa25cXZsuf4XsMKc04pqb8VeD2DvgA6Z24NlfvJQ4
 hUSgN8PCrFQWltebIsVtD0YLrB8DOpRN7mYYYlmzI15g==
X-Zone-Loop: 62c2916f754a8d01808af4afdaafaeb541c8b002e9f7
x-campaign-type: default
x-transaction-id: 1dbb7dab-c6b9-4cab-88b0-efd3a2a28ecc
x-swg-uid: 01-2d7a2f89-d12f-43ce-949f-fb2065a5d50d
X-Mailer: Sweego
Message-ID:
 <1786448226.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3@vates.tech>
x-swg-bid: 1786448226.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Tue, 11 Aug 2026 13:37:05 +0200
From: Anthony PERARD <anthony.perard@vates.tech>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: xen-devel@lists.xenproject.org,
	Frediano Ziglio <frediano.ziglio@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH v10 0/10] xenguest optimisations
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20260810103018.54564-1-frediano.ziglio@citrix.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.20dc.8a7aa5d03f4209ef.19ff09ca7b9.38730e8a748c5409=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786448226233
X-purgate-ID: tlsNG-c1860d/1786448228-CC57487B-073DFE6B/0/0
X-purgate-type: clean
X-purgate-size: 1426

---=Part.20dc.8a7aa5d03f4209ef.19ff09ca7b9.38730e8a748c5409=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 10, 2026 at 11:30:03AM +0100, Frediano Ziglio wrote:
> Edwin T=C3=B6r=C3=B6k (3):
>   libs/call: cache up to 4 pages in hypercall bounce buffers
>   libs/guest: allocate various migration arrays just once
> Frediano Ziglio (6):
>   libs/guest: move batch_pfns into a separate structure

I've committed these first three patches=2E

I've notice that `git am` will put the wrong author on your patch, it
would use the gmail addr instead of the citrix one=2E Could you fix your
config so that `git` does the right thing? I think it is just a matter
of changing the config:

    git config sendemail=2Efrom 'Frediano Ziglio <freddy77@gmail=2Ecom>'

(with maybe --global or with an identity added to the config option if
you use that)=2E

This will tell git that the email is send from a different email
address and it will format the patch appropriately=2E Otherwise, gmail
just overwrite the "From:" without telling git=2E The original "From:" is
still available in "X-Google-Original-From:" but it's not something git
should care about=2E

Cheers,


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vate=
s solutions

web: https://vates=2Etech
---=Part.20dc.8a7aa5d03f4209ef.19ff09ca7b9.38730e8a748c5409=---


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 11:49:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 11:49:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388150.1629357 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkzE-00083o-Hu; Tue, 11 Aug 2026 11:49:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388150.1629357; Tue, 11 Aug 2026 11:49:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtkzE-00083h-Eo; Tue, 11 Aug 2026 11:49:40 +0000
Received: by outflank-mailman (input) for mailman id 1388150;
 Tue, 11 Aug 2026 11:49:39 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtkzD-00083b-Mr
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 11:49:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtkzD-006hMg-3L
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:49:39 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7b0c3c-2eae-0a2a0a5409dd-0a2a4503aaf8-30
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:49:39 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7b0c52-fae8-0a2a45030019-d155dd2ae1f1-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 13:49:38 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so2150665f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 04:49:38 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4814a72cea1sm4368958f8f.37.2026.08.11.04.49.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 11 Aug 2026 04:49:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786448978; x=1787053778; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=2dE/foGziw/KGa1/idt3BoTG5ZRQ5Ek4O5T0IJYTeDw=;
        b=qPm9EsXkRCR9SkZeCr3MMnOUxXwO1zRomagA+jG5q1RRj/nsMslTVdcVoF40DK7Avn
         QoYz4J8DnnJ0xMAIJ/cF9zVgo2D8n78QKE7I7h9KjcApsBxrLMY+Qpp8hvyy+lhq07/t
         q7q+TOahNFbpVuOaf9B5TQB7YWhEaPbNrnQgMz80qHemahE6iXHyy09OCFoe/RBgca10
         b/e9dDDgIctsMiAICnPY37SdDiaa0DQRS1C5HH1IznFriVPvMHu7kY4FC56U6jhixlYv
         n47hykl89adphadn3DpnAisSbXLWoRITNAO4TGB75y8uun0ImrMjwE4msQ3Q89s5DtSg
         SuMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786448978; x=1787053778;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=2dE/foGziw/KGa1/idt3BoTG5ZRQ5Ek4O5T0IJYTeDw=;
        b=WmrrWok6+IkOQdiCO2fJ3oiI8TV6JaZ6uLdGDGxfU3gpE3cFEwltJ4bM8iK/8p6vJm
         fRk2nSNUx6/22LTcQJJZBTOG1xDVOW6LEWNJRPzSPKiPzuCmGoau7YJrx++XguFYKbSc
         B8JE1MehSRkPWnJcIkCifw9CrCvQWbNGgSsSZmHpUmOGN80587GCAeAW+iGAQjmaetCu
         LQo8NJNb0M/pIxteOziUXqMgIgjpW4aEv/LjpYvc7KugUSlI5BTTlxbubd/z+w6QT17r
         Irx7jTDmUyL9soIosbnAHU+AKNBcrVAJrt8iP4LVoUUBX8KjGT+6aox9AYdW4DeMwkw/
         lYfA==
X-Gm-Message-State: AOJu0YxtfrRRay+hcgGHbLGBmbB8A3aWqm27bJ4SCqJztrJ0y9XtXhVH
	muSmGUKCZajMDUGOtcHsjFtf8UggNkAKARs6L09RhbucYdcXHZ46njU9
X-Gm-Gg: AR+sD13WD2cmkRxrEJeiYkmMM37OdSacv8XpS2TyEMvtZNimWo6nvUcH27coiWSSg9O
	0M5u5WGRB7+lUPoScmYlTgbDwclPGjtDS3lFeQxNP5Vz1+tnhn0zNcfWuCR7Sh70QJdPZ/2p63Q
	V0TKf2cb0+lQpZzLurWArfQhUotwiDdx6974nZbZbFrEkCxdwEpuEdZD/xr2Kutskp4Ldvwe+Ay
	Oo4EDTw0F8dTMiUR0b/UWMd5yrkpQLnx7uM0wmKUsrmvTm7eIwnQf+DlaTsR/N4gjr68hirM8mj
	8rfYbfdu0l7QV07tMpvpCXNynbE+13BVHKbCrzVhbKTgblk3AFNy9b0GuGQmnIBZy5EteaD6Ac8
	aPGtpougsx+8YYGXy7unJJ8AOj0eoQN7VdS1UVmMfiOh2jjpUQGJ8nTXh0aji7cXTzYCH351vAs
	ylWDNiFvbAqd57wKNm9Tnr2hqxmH1U485dg4BkLj72gp5tseyNQbk3QrwTyz76pNgTzuUjvNOzt
	aaprc6ytrtAwbXRghsOXj3Dhhj1Rtg7sKCA6o4CeYc=
X-Received: by 2002:a5d:5c81:0:b0:47f:8480:4abd with SMTP id ffacd0b85a97d-4814aeec2aemr4394446f8f.29.1786448978236;
        Tue, 11 Aug 2026 04:49:38 -0700 (PDT)
Message-ID: <a58af12e-13f0-48a3-b39d-bff92991ccd1@gmail.com>
Date: Tue, 11 Aug 2026 13:49:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
 <05283ea0-de82-4160-a3f9-5fc1292a20a5@gmail.com>
 <1786436246.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786436246.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786448979-766FB4E9-3F01239B/10/73395122804
X-purgate-type: spam
X-purgate-size: 2375



On 8/11/26 10:17 AM, Baptiste Le Duc wrote:
> On 2026-08-10 17:36:56+02:00, Oleksii Kurochko wrote:
>> On 8/10/26 4:49 PM, Baptiste Le Duc wrote:
>>
>>>> diff --git a/xen/arch/riscv/include/asm/mmio.h b/xen/arch/riscv/include/asm/mmio.h
>>>
>>> According to coding style, it should be GPL-2.0-only.
>>
>> Could you please point me to the line in the coding style document where
>> this is mentioned?
>>
>> If you are referring to:
>>     New files should start with a single-line SPDX comment to express the
>>     license, e.g.:
>>
>>     /* SPDX-License-Identifier: GPL-2.0-only */
>>
>>     See LICENSES/ for a list of licenses and SPDX tags currently used.
>>
>> Then my understanding is that /* SPDX-License-Identifier: GPL-2.0-only
>> */ is used only as an example, and I can choose any license from
>> LICENSES/. There, it is mentioned:
>>     Valid-License-Identifier: LGPL-2.0-only
>>     Valid-License-Identifier: LGPL-2.0-or-later
>>
>> I am pretty sure that I am free to choose any license that does not
>> conflict with the other licenses used in the project.
>>
> Oh ok I didn't know, thanks for these explanations. Could you let me
> know how do you choose one instead of the other in that case? Is there a
> rule from our company to follow somewhere?

I don't know about any specific rule from our company.

In different situations different licenses could/should be used. 
Specifically here I used GPL-2.0-or-later as this code partially is 
based on Arm code which uses this license so I just re-use it.

>>>> +#ifndef RISCV_MMIO_H
>>>
>>> Nit: line too long (85)
>>
>> I will apply that. Actually I've already fixed that by putting the
>> comment above:
>>     /* store: value to write; load: value read (set by handler) */
>>     register_t data;
>>
>>>> diff --git a/xen/arch/riscv/mmio.c b/xen/arch/riscv/mmio.c
>>> Should be GPL-2.0-only.
>>
>> Regarding license I've wrote a comment above so lets continue discussion
>> there.
>>
>>>> +/*
>>> Why have you included a copyright notice here, but not in the other
>>> files?
>>
>> So I just decided to do that for new files as I am not using corporate
>> e-mail.
> But why didn't you do it for all new files of this series?
If there are such cases then I just missed to add it. I will double 
check during preparation of v2.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 12:12:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 12:12:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388177.1629390 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtlKl-0004SL-LO; Tue, 11 Aug 2026 12:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388177.1629390; Tue, 11 Aug 2026 12:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtlKl-0004SE-Ig; Tue, 11 Aug 2026 12:11:55 +0000
Received: by outflank-mailman (input) for mailman id 1388177;
 Tue, 11 Aug 2026 12:11:53 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <david@kernel.org>) id 1wtlKj-0004QX-BH
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 12:11:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtlKi-00BxPI-Eh
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 14:11:52 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <david@kernel.org>)
 id 6a7b117e-2eae-0a2a0a5409dd-0a2a450586ae-26
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 14:11:52 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <david@kernel.org>)
 id 6a7b1186-4cb1-0a2a45050019-aceafc1fb6d2-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 14:11:52 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id AD2A843649;
 Tue, 11 Aug 2026 12:11:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E88261F000E9;
 Tue, 11 Aug 2026 12:11:33 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786450309;
	bh=/fTG1Cghw/RG7+KE3x88oxH8TI74VawrjBf3qjRRniY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To;
	b=oMzFJcn9VOzkFaKMEx9vCYCdx1Pq7igNm3SDyOEjzrOpDudIApIUK8tbQWGyhMTA2
	 t05Mkqhok9RLYIMUol0cpCiu3QthaSWyzaAoYQ2iTd1AckujJZDZf2+JmOHRJ0KvP7
	 mcsYLS8a7sO8YaLXbyWEeOK99DFlaVD5L55J3MTekojG6h3FMWYgpjeoMH//X24lZs
	 5lfWAxjxOdrK+/s8jDuKs0rLQeM8RFflAxNY1JPwZF3i/yhkf94kLkVqbTR4mmJWjo
	 hK2SQwlx7kI/9C/spjKPKM5IkvDG9SLQ6RAQ5o7kkbgcPTchuBQb5gh+4ZPvUgW8mp
	 IkyibBYe3lp/w==
Message-ID: <e9de4158-b829-471b-980c-1999959bbc48@kernel.org>
Date: Tue, 11 Aug 2026 14:11:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/9] mm: convert PTE table entry to pte
To: Muhammad Usama Anjum <usama.anjum@arm.com>,
 Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-7-usama.anjum@arm.com>
 <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
 <5c329236-7761-4e42-a549-b822e43b4358@arm.com>
 <2599c5b3-e8ac-4865-993b-d41e6f060d52-agordeev@linux.ibm.com>
 <f0b0dacb-fb83-4402-b0ea-30072727dfd7@arm.com>
From: "David Hildenbrand (Arm)" <david@kernel.org>
Content-Language: en-US
Autocrypt: addr=david@kernel.org; keydata=
 xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
 dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
 QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
 XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
 Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
 WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
 UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
 jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk
 ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik
 AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN
 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD
 g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz
 ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x
 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7
 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4
 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ
 DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R
 HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC
 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7
 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR
 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt
 VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk
 /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy
 iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ
 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21
 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg
 azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY
 FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D
 sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO
 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e
 EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts
 IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC
 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV
 Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS
 sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx
 yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9
 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg
 r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ
 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ
 CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY
 qIws/H2t
In-Reply-To: <f0b0dacb-fb83-4402-b0ea-30072727dfd7@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1786450312-253192A1-2F56CCD4/0/0
X-purgate-type: clean
X-purgate-size: 2594

On 8/10/26 13:06, Muhammad Usama Anjum wrote:
> On 10/08/2026 7:44 am, Alexander Gordeev wrote:
>> On Fri, Aug 07, 2026 at 05:26:04PM +0100, Muhammad Usama Anjum wrote:
>>> Yes, this is particular line is for non MMU. In this case, CONIFG_ARCH_HAS_HW_PTE
>>> would never be defined. Hence hw_pte_t is just pte_t and direct dereference is
>>> allowed. I'd thought a lot about it; is better to leave direct dereference here
>>> or use some helper. Then used __pte_from_hw() was already being used in generic
>>> ptep_get().
>>
>> But in case CONIFG_ARCH_HAS_HW_PTE=n __pte_from_hw() is still gets called.
>> That looks inconsistent to me. Why not just call ptep_deref() (see below)?
> 
> Agreed. Calling __pte_from_hw() directly exposes the representation
> conversion at the call site. I will introduce ptep_deref() and use it
> here.
> 
>>
>>> There are only two users of __pte_from_hw() at this time. 
>>>
>>> ptep_get_sw() or ptep_get_deref() is better name here?
>>
>> ptep_deref() would be it.
>>
>> Do you agree to the suggested API requirements?
> 
> Yes. hw_pte_t * identifies storage containing hardware-formatted PTEs,
> regardless of whether it is attached. ptep_get() is used for attached
> entries and may provide additional architecture-specific handling.
> ptep_deref() is used for unattached entries and performs only the raw
> storage-to-value conversion.
> 
> For review, this patch would become:
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index bc0b9c65aa1d0..ce900d2652d91 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>  #ifdef CONFIG_MMU
>  	return ptep_get(ptep);
>  #else
> -	return *ptep;
> +	return ptep_deref(ptep);
>  #endif
>  }
>  
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 1768421755a9c..08613593f3320 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -490,6 +490,13 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma,
>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>  #endif
>  
> +#ifndef ptep_deref
> +static inline pte_t ptep_deref(hw_pte_t *ptep)
> +{
> +	return __pte_from_hw(*ptep);
> +}
> +#endif
> +
>  #ifndef ptep_get
>  static inline pte_t ptep_get(hw_pte_t *ptep)
>  {
> 

I mean, how many such users do we expect? 1? :)

Why have a helper for that then, that seems to encourage it's use, when really
people should be using ptep_get() ?

-- 
Cheers,

David


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:01:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:01:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388195.1629407 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtm6w-0003A0-7K; Tue, 11 Aug 2026 13:01:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388195.1629407; Tue, 11 Aug 2026 13:01:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtm6w-00039t-4L; Tue, 11 Aug 2026 13:01:42 +0000
Received: by outflank-mailman (input) for mailman id 1388195;
 Tue, 11 Aug 2026 13:01:40 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wtm6u-00039g-G7
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:01:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtm6r-009LCC-Fz
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:01:38 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b1cec-2eae-0a2a0a5409dd-0a2a4509e918-18
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:01:30 +0200
Received: from [52.101.193.24]
 (helo=CH1PR05CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b1d25-be1a-0a2a45090019-3465c11832eb-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:01:27 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SJ0PR03MB989491.namprd03.prod.outlook.com (2603:10b6:a03:407::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.12; Tue, 11 Aug
 2026 13:01:22 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.024; Tue, 11 Aug 2026
 13:01:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tukdJ7h+jvWFTWG/Rs5CNwcYyKka9m9B7ujc0Gjs6WqZpi+jAbWUT3kN4en1i8m/YLvvlgGVpebo/UvnwZGUJ4u2fIQD3EQk8BYZq2lEzFXQZy1l3WXC4NuWvDbdJQJAtdmnykrOba8Ql80EyQQh7ysnlsEvSrFAowTSITkSYZVihckPqk8t4Jv5O8tr2BXXMBMmuG8pT0KalQ3IzbOFXkGq2/OFDv2KhFZE2EL9vLRTTxiLpZn+VcU7QUCFCFrh1qVyFiIBY/TabVTqRBECTC/wDfhFNp26Y/HfD0scIZzdMqqGzlPB5oZcjQuNBG9IPr0Ts1XRljnO0kR08LaK/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IZ+jG5N07na9TTaIn652mOqplbTmcBrD7nwVlzdekfM=;
 b=MQGN/QJeV7UGBQxCFA3PO5ry+h4x7Q08/eNs03VO3TgtA6G/5yAtIVepCD71/gGECHLRElHZQv8dXE9eewhgMXxxSK+KtumZHuunqwIdWwVz1WgeKTViMSyZJh8H8ikE1ja9+r4Uq3/u+k8QupuqIMnUNv4lL11HcwVl1ernoLv4xCdkgQ1RLjeRPh18AiMmBVl+PY5HPlK9uaJkaudnwIZjZtJUcD4LwQPXxgWwd5q8rTHK/eUwM19ouJ3bYlBZU1066xbuaK7ILKpdZyzVW6UZhOvsXdg/V1Hd5+T+uIQDacOcHrUgEVkkz3l/RH4e8UX+NgxCR5W8XdD4p0noXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IZ+jG5N07na9TTaIn652mOqplbTmcBrD7nwVlzdekfM=;
 b=DZT6Z7wwZt2L2URLA4htGJKPxxMsqj759/mgzu6lkPZJvpMNIbaQaUWyK5RzaU1oSLnlzsfAPMWFGHyQjTcCDP7d7jKpNCi0+/i3vY2s3vdGTApIQ+U3aFHjOT/8hkJVKLbixGuB0WYh8daWIHDopKSc8SinKwgBwLRz3Ky8px0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <7b2d0e8f-5c6c-4002-a123-d96c90030e54@citrix.com>
Date: Tue, 11 Aug 2026 14:01:17 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Jens Wiklander <jenswi@kernel.org>
Subject: Re: [PATCH v2 3/3] xen/arm: handle irq_set_type() failures
To: Mykola Kvach <mykola_kvach@epam.com>, xen-devel@lists.xenproject.org
References: <cover.1786385827.git.mykola_kvach@epam.com>
 <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P302CA0018.GBRP302.PROD.OUTLOOK.COM
 (2603:10a6:600:2c1::14) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB989491:EE_
X-MS-Office365-Filtering-Correlation-Id: 32266a46-e3ca-4b64-a19f-08def7a8a43d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|7416014|23010399003|18002099003|22082099003|6133799003|10067099003|4143699003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	uP40TFpYN+NtvjONtLsfW2by/sdA2/7fOrahfVWxjVqGLVwfMtqMIKhPAMlN8Nh/rXX+6PZMMWBTr8+MRXejj2tVWS/6xwkrPX4IVPR0wD7HTttYHihOQSl4NfINmBWVDUeZCyQkMzlMW98jcVxrXXG5XFAZ7GAD1/jQa4pwKeSnl2PkGjITQ4Y/hwAl6j+OtXCgw2rBHj8Ib5YYJEp1r9mDuleytlmOsRAk18DVZcoXJFhWSdiVzaXGRt8ysf964YlR3O8kT9G9KNNudd/FHzJHU7nS4eydesvaEZ3lDvDhKwj2dH5yNrez7jCk/+8NdqvmzxM2qs3NqLChu2U+NFbtTeEq/fS3unX/7ovoj4bdQyRy+ISkOAcwYGmb1Zkljldj86m9S7e/35VajXw6eJlwBO3HT9MkZvddM8GrsFA4DMK7oGk86JfSERrkaQpFr+L08efXtLPcWcyiaP78ySmJi/N7Sr33S2fWK+wynXtR601bCkOVziFWEAATvZMvMxEDsO8Cblhn8fWFD37sbKyTrvrhT/QkyDiALgo7pF6J3MzqPX84i77tCVoXFh9Kvl6+hqTKVUOdP05Lv/K7MJl5cIJYH1ibhe3p8hNLJ2KZxwOXZgrfwThINSEEURT7r13i22qI4zC31a2ETLNwa6D+Vionk/2rYufLThKKlU4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014)(23010399003)(18002099003)(22082099003)(6133799003)(10067099003)(4143699003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SG5FMkdPMEVrenRwRG9xdGdTdWt6aVp2N0hKeWVydDhjQzYyUWRBSUdVamVE?=
 =?utf-8?B?Yk5QVFl1NTRDNlBGZkNVRlFMK3llQmtsVlVnM0IwSStoVEJ6aGUzVVNkZ2hF?=
 =?utf-8?B?MHRReG1mU3oycS9BeG52WTRXcVVLUWl2Tk1WNFNNTE9OWGgzTFZDQytHcGhP?=
 =?utf-8?B?WDVGVW80Z2IzM3JIUytPaTNtQUtrY2VrcGljWlZ6WXJWVlZXWUVBRFdPczVF?=
 =?utf-8?B?YVpTNkdhZU1mM2lBR1lCYXRHR0U1Uk9KUGJqUEJoVEZld3JjaHI5UmVPNXpD?=
 =?utf-8?B?OWNJaW9wMW5EYnYxaWNEZ1IwU2NUalYxV2ZXTFF4VHhSaHhHL1RnMk5TVS9M?=
 =?utf-8?B?Tm43YlZhKzI0UHd4SW9HM3F0SWRLSjMzNzU5NGJ4YzhScUtUWXhHcEYzTnRu?=
 =?utf-8?B?WUdITGorR0NRVDVVRkJSR2VEMkdua0ttTjB1bDFOdUxnVE9FYzJiUTdQNjZv?=
 =?utf-8?B?OTJWQ2dLSnhlS1IwNWNjdDhIV2VOeGhHSUdnQ040NG9XUnRuTFdnQ0gzd0hZ?=
 =?utf-8?B?UFY3aUUrZDc4T21VVzlxM2NFREN1MWlobFRUM0pYM3JXUDlsaXlzNS9Jbldp?=
 =?utf-8?B?R2Z6TE4wR3ZpcTB2MUhiNkFUaWJsSU4vMEI4eEhRUVR4T3poMm9mek1DMW5h?=
 =?utf-8?B?dWllbWlkNlFCWlFsTUNDQ05XcS9vbDJtWlFPazBWUmFtZ2F0U2E2M21zVnY3?=
 =?utf-8?B?YlFQVWJscytxKzZMYkNmSVFKSGpIM1lGYzB5TElZQTl6MGpCSUVOeWk0UlpO?=
 =?utf-8?B?cTRSdFZNMjZVaUtqbm5acVhrREV6K2dBa0dINFNZdWJTWGxUamVwRDJQeWZR?=
 =?utf-8?B?L2ZFcGNOeGhscFBvanR5NUtjTUIrVmdnQk9MenI0YmtpT3YrelR4SU94ZmV2?=
 =?utf-8?B?QStSTWN4YkVHSmNTKzNpVExVS1FqamhMcUtRMkRZZ2FQQm9FQ09yUUxPc01n?=
 =?utf-8?B?TDZnR0t0N21xSUxrSU1sbnB4bTZ1VFVxUDg0TXdjaDJpdzlNOFRXdUpwaTk2?=
 =?utf-8?B?TzlPK3hPNHlqR2VrSDJCVWNTRTdNOWRBd1F2Z1o3SEoxQStjMGRaZndzVGJs?=
 =?utf-8?B?UlMrdjI5ck9BWEZoN1V3TTQ1bHorTjVjMlpOVXBVWjNnZDZZSnF3S0RjLzUv?=
 =?utf-8?B?cTV1NzVwalR2Uk4zNytPZDNaM0V2MG50Z1FUYUNWN2FhalJRd2lhdU9IaFE1?=
 =?utf-8?B?djEvMWpvNWIrVGhYWnNTTm9aMHRMRDhEYTlOSVNGZDJGTkx3SXhuUVhHYWxW?=
 =?utf-8?B?N1lVditzQjNUbkcxbTlRZ0hDMGdFcE52UVBxY2tFeGZveWlFejRxdGhoRkNP?=
 =?utf-8?B?ajVGYWM0VUpQTWRFWTgvYVhKMEwvSkZWRzZHNlh2OVhFSms3RTAyQThxOUxP?=
 =?utf-8?B?aTRrbm43ZjdRQnV5SndNWU9JRjcwRTV6ODN0T3A3dEFSM0ZGVk0reDU4cU9s?=
 =?utf-8?B?eWlYbklyUklWVGV6dUlZTlpEcjk3S2xUZFlud1U2cWY4T3NJc0MxeDQyUFZo?=
 =?utf-8?B?QkVkSXpScU9BbVQ0eldpeiszSjlSbEh2aHZIY0JLTzZGVjk0cVlRVElHR0Vv?=
 =?utf-8?B?dXU0MTVUSWhiSXBleGF0TU11cFNBcjZEcDc4UkpYVk1NZko3SGM3V1BZYUVy?=
 =?utf-8?B?NEt3VTMxaGlHSGJvdEE0TTB1c3JrRlRIWnN2TzR6M2JBNWEwZXhYL2U1czdK?=
 =?utf-8?B?dzl3SmVOellUQWlFYnd4bDM2OGs1cjdTTGFlOGxhbldYa2RFY0RUYytGVEV2?=
 =?utf-8?B?U29SWkViaW5uNDhEYzJKR0xqY1h4NXpjVnJXdHBrdktrbnF5UGpocGljZXpI?=
 =?utf-8?B?RldwdjJPV1did0tZRzdjOEJER3NzT0JtUkJ2VCtUWkhHU3VuU2pJS3BwWVVJ?=
 =?utf-8?B?eDhmSXpnRWlRa00vK3U3YVNmL0xEaHNyb2EwUGk0R1hJNXhyNkF0UnN2OER3?=
 =?utf-8?B?L3hFSVFndkV1aFB5eThUdGUrbUg1QWtrQjdjTVhheFZLYkVUWWZkeExyWC9F?=
 =?utf-8?B?STZ3bHc5dWJ0QnRlSEpQbXFjMnNpcW5BN1pmL25KdGU0OGRJeGVZTGd6dHFl?=
 =?utf-8?B?SWpWWHBkWWFkZTVkd3p2L0l5UXFlVFJZa0w4YzkxUGRtNVpyTDFoZ0ZnbzZq?=
 =?utf-8?B?eGZTZVpCd29hTUg0UE91WDUyODluWS83cS9jN2hnWkI4cUlPUzlGS0ZEMkdZ?=
 =?utf-8?B?SXpUbTFNbnI5Zjg1SCtibXlXRk1RRjZQZWhnc0xiQnJsRzZ4ZlVTY2doQWt0?=
 =?utf-8?B?aHJMOXdIa25aZWJrTEM5Znp5SmR6V0QvOUkxTWE5QWtyYjJITmVMM3loTWFr?=
 =?utf-8?B?TTZHVzhJR1FnQloxbXBJWFBnejRBZVNUMzhuMjdHbHB1bHdTMGhpcVJ0NjQ5?=
 =?utf-8?Q?X9SwcXxnqRg2XP2k=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 32266a46-e3ca-4b64-a19f-08def7a8a43d
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:01:21.7526
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: K5ED69T5U97wCvbk8mDsugpolr53SiV1Iqs9GBlg6RWVX3oQY2lDWfTytUMQpr6eHI+TZc8lK9KRb8rrLc5Tpjh67zvb4fL3l/Rl4nQr2N4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB989491
X-purgate-ID: tlsNG-bad1c0/1786453287-BC2F4034-51456E6A/0/0
X-purgate-type: clean
X-purgate-size: 2434

On 10/08/2026 7:38 pm, Mykola Kvach wrote:
> Several Arm firmware initialization paths discard irq_set_type()'s return
> value, violating MISRA C Rule 17.7. If trigger configuration fails,
> initialization continues with an IRQ that was not configured as requested.
>
> Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store
> timer INTIDs only after successful trigger configuration, make GTDT
> parsing failure fatal, and stop UART or notification setup when trigger
> configuration fails.
>
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v2:
> - new patch.
> ---
>  xen/arch/arm/gic-v2.c        |  8 ++++++--
>  xen/arch/arm/gic-v3.c        |  8 ++++++--
>  xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++-
>  xen/arch/arm/time.c          | 18 ++++++++++++++----
>  xen/drivers/char/ns16550.c   |  5 ++++-
>  xen/drivers/char/pl011.c     |  4 +++-
>  6 files changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 43a379fdda..b8dcbb0bb4 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1157,6 +1157,7 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>                          const unsigned long end)
>  {
>      static int cpu_base_assigned = 0;
> +    int rc;
>      struct acpi_madt_generic_interrupt *processor =
>                 container_of(header, struct acpi_madt_generic_interrupt, header);
>  
> @@ -1173,9 +1174,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>          gicv2_info.maintenance_irq = processor->vgic_interrupt;
>  
>          if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
> -            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
> +            rc = irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
>          else
> -            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
> +            rc = irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);

I know it was pre-existing, but this is an overly verbose way of writing:

rc = irq_set_type(gicv2_info.maintenance_irq,
          (processor->flags & ACPI_MADT_VGIC_IRQ_MODE)
          ? IRQ_TYPE_EDGE_BOTH
          : IRQ_TYPE_LEVEL_MASK);

I expect the optimiser can transform behind the scenes, but it's better
to make the C simpler for humans too.

~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:08:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:08:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388203.1629425 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmDf-0004BI-79; Tue, 11 Aug 2026 13:08:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388203.1629425; Tue, 11 Aug 2026 13:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmDf-0004BB-3m; Tue, 11 Aug 2026 13:08:39 +0000
Received: by outflank-mailman (input) for mailman id 1388203;
 Tue, 11 Aug 2026 13:08:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wtmDd-0004AT-IR
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:08:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtmDb-00C6un-GR
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:08:35 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7b1ebf-bab6-0a2a0a5309dd-0a2a4504d4c0-10
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:08:34 +0200
Received: from [52.101.61.7]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7b1ed0-b57f-0a2a45040019-34653d07ff69-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:08:33 +0200
Received: from MW4PR04CA0200.namprd04.prod.outlook.com (2603:10b6:303:86::25)
 by CY8PR12MB8216.namprd12.prod.outlook.com (2603:10b6:930:78::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 13:08:24 +0000
Received: from BY1PEPF0001AE19.namprd04.prod.outlook.com
 (2603:10b6:303:86:cafe::19) by MW4PR04CA0200.outlook.office365.com
 (2603:10b6:303:86::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.11 via Frontend Transport; Tue,
 11 Aug 2026 13:08:24 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BY1PEPF0001AE19.mail.protection.outlook.com (10.167.242.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Tue, 11 Aug 2026 13:08:23 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 08:08:23 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 08:08:23 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Tue, 11 Aug 2026 08:08:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pjZTF9x1J7t22vx58dyf98E6h1QUv3O6Tdq4bQ5HtbViEjgWBzppyqZ9Vz/xZ0GyaH6PJ4z1eNkF/+sRC9Ptr4e/gVtQIrmvC+5YOrdMOJBLq/21V+bIHzfxBSjuoaqFvc/aKK6dJEkUtBFhEP20x9kifw7nNfQ8L+h658qdzOohlixN9fjW4NNptt96GTxivM8eFHqK28gju/HbajbZAGbLMlFTTQgzTKIFfEENsaBw1FJXe0wJ4a5iLiz20sv0UVPZbJR6TxJC430evlfUqBg9Hqrf8TbiQKCJJfhQ5BwzIsz0UBS/nfMJMngyMxexzJYJ1zPwFB0wYeqe/WQk1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uL5twoODR7h7tXvISrc2qyc1Omt/iP2tMqUXiS6AdPI=;
 b=Ta5d04Qe+VOXzp6ZdYfV83LJd/NdT9Zqu7L90sNr4S1wz6+saD+oM1b/Lk30LOP/FhhgLddeYq3vQ1mKKaNNOF6vSPwy6pCqx6ZMBBFLSMWlre135Fb21l0kqAuAzwykTKM5NY6T06Bykod7T4C1q6BMkbS4JuGsu7aLml2YAnzKjdO9SCaRU74cM4LsikqdC2ZQ9KL6g48dDmui92PvMRDS73xAnVwmNgYfl+EUAcGBTgx64hvgGOAzv9WcDBv95woUBEcZVqZyORmIeaHdawaizqIZs+ESJ5nSrLmmRlQL9EaqQCYVzgL1m0n4EWdKa3X1+3JYy6HbLxDOSmH9og==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=uL5twoODR7h7tXvISrc2qyc1Omt/iP2tMqUXiS6AdPI=;
 b=BcgWIkaItx4W380piZwuVhTnJnNbQsGRamc5CHvuWRFeSozWUlKVQFamLgsvQ9jJtAqtb4tqnqbPw0vGCB9qZx0VcprAF3MLXgvWnFtyxzSiUNhkTWpsn36FF3+1s3+5GQhCE3dCcRBOJy3rP4TLY/RL8LAEpzvMWq5wUYrHaco=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH 1/2] xen/arm: drop unreachable EL0 check when emulating ACTLR
Date: Tue, 11 Aug 2026 15:08:17 +0200
Message-ID: <20260811130818.123862-2-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260811130818.123862-1-michal.orzel@amd.com>
References: <20260811130818.123862-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE19:EE_|CY8PR12MB8216:EE_
X-MS-Office365-Filtering-Correlation-Id: 48d65d3f-6abd-4c34-73a3-08def7a99fe4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|23010399003|22082099003|18002099003|11063799006|56012099006|3023799007|6133799003|10067099003;
X-Microsoft-Antispam-Message-Info:
	bxGwBHES/iI/G1HZkX+RSdBRLyswPdKzdPRxxAW5Io5B6m5SDAHCHURFOkk8R2C60hPsVwtnvcz76Cm1+j+h/eOyS1haEj1yrOtE7xQSrM/RKGG2sBAT/RRkzvXai6dE6xQGYtk/OKWXpnuc0iqQeTcommWdHSCQLZlClaoTVc/FgParuMtfDUKB4upe7KrA45VMehfi0pXRGLemX1dm3ke8nenR7H6tku0EBp1Leyl+uJSsgEREL7m7MDcR6GvweXaQ9MSD+66r/Qxsx7TG/ACeewLS1ft+xlYU1cIxH/5QIYOcFO+H5rXr/sMM0TV9BODxgxryYHnPw+N8F2Jt/QRCBtlWSy/X1ZeJNusic52AF4k98Brc5BI7EU6yj2k3M+VZwIf14lblW+XhpoFsMMiZvMIBefK4QSAbk9Ud9OFbN0Wjr/XBElRzf0zGun+hcVOQm2xh5WIHuGZ+i3DPVKBreAwhXduDeD0R1fr9TcFvwnmYXi2go68QmztigFDp8yO0t7KlRdO2xxfQxLkPCCN/L/OlUK4alJG0rlyt9+uaayPFDZiY2rQNi+u3hKk00BDppgUBjmDKO36XbBQex1kCPoW7m6nrsE+O1b/KoLQy2W2FnRFDbxWmkUKYZer6bAJnAA4b2NDHPzwMWTzYXR+ND1oZRZOWs8M/UcwPdKevV+rYxcQZVBGqTm7GGqbWKAN75S4S6LVVV9H6CZOgiw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700016)(23010399003)(22082099003)(18002099003)(11063799006)(56012099006)(3023799007)(6133799003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	indfLzljTVZSSWcQfsd/j5+GV0/Mfe/NYSnwZ38n65KOk5I5HIZPBCCesI3rwUNrFpMacuf1FYuDz+FmlD3KlpiSzIIKfe4vhlgIAFtnHN5je4w8fv96O36q9xXB4tnEV9B6UbFRjzhNylDVmyLtxN0SRuo7jk+GFBRKmjZiV+1dT8pmTMLDo0NgKFhwzQOLoIE8ksWfTW8NVq5UPKzt2Z1jEekP3/FmWrzymVp3tZejFchPo+4J/D6lQdE+tWZ6Mdm11y69N0kIOjN8qYangBEh/c2N//Vssm0pF3Z0mjkPJYqCqIAH65rb2w35UIAec7yoJZ/DGoaH5foHyJlWbGoCLRhkFVskhElKjm1gjcph7GqTJnaclUD8SS2b3PWn7Iwz+PC4GYuYk3SzRMpgqCBxNb9RLRuEb320fC4NtWZ/Nkb7HWh5qlh+CBZk4XXF
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:08:23.6179
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 48d65d3f-6abd-4c34-73a3-08def7a99fe4
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BY1PEPF0001AE19.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8216
X-purgate-ID: tlsNG-ebf023/1786453714-520D5B50-70BBE54E/0/0
X-purgate-type: clean
X-purgate-size: 2223

do_sysreg() and do_cp15_32() inject an undefined exception when the
trapped access to ACTLR_EL1 (resp. ACTLR) originates from EL0. That
branch cannot be taken. ACTLR_EL1 can be accessed by EL1 and above, and no
enable makes them accessible at EL0. The only trap covering them,
HCR_EL2.TACR (HCR.TAC on AArch32), applies to accesses from EL1 only.

Refer Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
exceptions": "attempting to execute an instruction that is defined to
never be accessible at the current Exception level and Security state,
regardless of any enables or traps" is priority 18, whereas an exception
taken to EL2 as the result of a configuration control in HCR_EL2 is
priority 24. The former wins, so an access from EL0 is UNDEFINED and the
TACR trap is not taken.

An EL0 access therefore never reaches EL2: it is taken to EL1, as Xen
never sets HCR_EL2.TGE for guests, and it is reported with EC=0x00
(Unknown reason) rather than EC=0x18/0x03.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/arch/arm/arm64/vsysreg.c | 2 --
 xen/arch/arm/vcpreg.c        | 2 --
 2 files changed, 4 deletions(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index a02ad951f9c1..a59848889659 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -95,8 +95,6 @@ void do_sysreg(struct cpu_user_regs *regs,
      * ARMv8 (DDI 0487A.d): D7.2.1
      */
     case HSR_SYSREG_ACTLR_EL1:
-        if ( regs_mode_is_user(regs) )
-            return inject_undef_exception(regs);
         if ( hsr.sysreg.read )
             set_user_reg(regs, regidx, v->arch.actlr);
         break;
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index d6f9326b712c..749ce6d3a57c 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -219,8 +219,6 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
      * ARMv8 (DDI 0487A.d): G6.2.1
      */
     case HSR_CPREG32(ACTLR):
-        if ( regs_mode_is_user(regs) )
-            return inject_undef_exception(regs);
         if ( cp32.read )
             set_user_reg(regs, regidx, v->arch.actlr);
         break;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:08:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:08:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388202.1629416 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmDb-0003xu-T6; Tue, 11 Aug 2026 13:08:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388202.1629416; Tue, 11 Aug 2026 13:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmDb-0003xn-QV; Tue, 11 Aug 2026 13:08:35 +0000
Received: by outflank-mailman (input) for mailman id 1388202;
 Tue, 11 Aug 2026 13:08:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wtmDa-0003xg-Si
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:08:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtmDY-00BAgn-07
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:08:32 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7b1ec0-8faa-0a2a0a5109dd-0a2a45079a22-20
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:08:30 +0200
Received: from [52.101.52.63]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7b1ecc-b4ea-0a2a45070019-3465343f60d9-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:08:29 +0200
Received: from BY1P220CA0016.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::13)
 by BN7PPF8FCE094C0.namprd12.prod.outlook.com
 (2603:10b6:40f:fc02::6d8) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.21; Tue, 11 Aug
 2026 13:08:24 +0000
Received: from BY1PEPF0001AE1A.namprd04.prod.outlook.com
 (2603:10b6:a03:5c3:cafe::2c) by BY1P220CA0016.outlook.office365.com
 (2603:10b6:a03:5c3::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Tue,
 11 Aug 2026 13:08:22 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BY1PEPF0001AE1A.mail.protection.outlook.com (10.167.242.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Tue, 11 Aug 2026 13:08:21 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 08:08:21 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Tue, 11 Aug 2026 08:08:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=c5IuZPCMbt+iP+iOdd6Dvc1zLyHQ8WXZHqYdUxsrqaLgAh+1JVG1ElSTi+rBYNWcr7jQj2s4jOaBIqCVe8PDGb14UjXXy9Jo4MXoJCQR5YfrFFwVxGHqOUvL6spCSXg+8hMjbqA7JBeYhT2uZgohuKR/+EMM9834UjdaUsh6Pj3i6o/G40rWOHo5anB5PbbKY6Z2OGCM6RUNo1iHTkUu3IhSrmrxVcRnFk1L8vUpKzhigRxy5dGKihB/9/ILAi3OcHYs59dhglONzKhz/946Hcil8CnCSozv8Z9WllFZvK52/snzXF1Xb1z27V8MChWEhFcq1RuiJVsAZVYVSCc0kQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XPXk2uXH4OcEznZV95T4XSLF5H38ut8UVpU/X0q01fY=;
 b=fD7X9M7hLkhHhTJ9UB076EOtYvR/bAR6xtgrLA9kpixwj7iJC9HstXPoSjZFiRDkAEOsfzF1vQQbRoZZynhoOdRF+qd/PIYnM5ZEbcDu4oM/jo8L4dU+mt+tyXvaY8wKQ8hB2vvTXf3mggTYLlmZt6S+jT0iTpbWIAoJjzOHhLHwkhs1gh1txa+MvfuGN19Im84Kb5A1ilouoMtStiUfhC1VjWLhUY/FqYVMkK29cDG6CmkZILeFpQ7jdVlCGKXUzGiV4YA0vnkDr3yE6sPXfyRU5fJHx5ooZwvy7mhFgq4SKfbHW9GACV59bGhQoLCuMlvnhAnQVwtijo/Le32AIA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XPXk2uXH4OcEznZV95T4XSLF5H38ut8UVpU/X0q01fY=;
 b=IrKymI/Vl0b2Y7PXNwm1E3hsHyb/2hdIQeL/KXfy4B0hdwlwkQIoY1tGGYmAVbC4eoZk0l0ZZF+MTg0FLvfOkyjd54QEaHCn/TuUhpvaYC0ABKplOR4hJR27Y4lTHJz7W8+tBB3MKHkS8y75QNGlRTImkzo8fdh2Ji9GNctRWwE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH 0/2] xen/arm: remove unreachable EL0 handling from register emulation
Date: Tue, 11 Aug 2026 15:08:16 +0200
Message-ID: <20260811130818.123862-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE1A:EE_|BN7PPF8FCE094C0:EE_
X-MS-Office365-Filtering-Correlation-Id: 0a1b67b9-1c5f-4880-e601-08def7a99ee9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|82310400026|23010399003|1800799024|376014|56012099006|10067099003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	wP2d56Pkap7uAJ4aPDPZmu6dNk/u4ChH6mUeyojQBhIyrlvSo1GVjwl30xKQyyWjCwHOYeviOxUMOpBATo6AEixQMcLKmVqzOX+89wW4RkQDMPlIh3BI7Kf2fWgU6xeqLhoRDZ1BDLMo2QDrQrIuu8cqYsCrfHlbHhPy28NWnE5x74VP4OF3wZa7rd0/jVzQkzwM1SgJJrqPYQ7Sy8nVfrR2m+9yskQYlAgpj+KCe23mh/9CHRLGkBVGIw6lGBxRCUifGRmboYfgP/aoMDYWLBhQVGfi67auwlSrLvI8GUheSxrh+UguDRXUKIq9ewmSh7DW0v93h3CZSrYM40frcmRMg/zkBloc7Q2kRgoBFg9RQq/sBeEGRgG1Ev1mrJ3tlYvr/pD0LAsrsQuwtLJT3vL+CiS8ye3W908FqKa9ZK51DmN7VGMtL+d1wN/WPCV3wH9udqxZEYPoOFP90OwnRkut0TjRRnEsLHfh347i6qD3Nc6QWtxDZbdzS5OC2SMRI7IM8IuNQE2+CPJ9HkDhYlZqUUNY0k1iOL5ZGeF8wR56/g+LIQaOgTgnChzWRqLUa+7quIKYiNto1R3LrkbCDXPnidB+Lz33WCUrVy8xehz+U0lhpJ5XSQxAoUAifrpcgamj/HY1kBJMTdUf+kZBxl9OAcTxUmXzh7yOsIeiz3653mI8pS6DZeuJjGI37FGkwMQqxqPDOtDJhtfn/YaHpQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(82310400026)(23010399003)(1800799024)(376014)(56012099006)(10067099003)(11063799006)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	UpwgALeu9W5u0SdQfu0F4g0KyNDonNlBdGHahwqTsrqAvH8DAoigU0u+nXt6X6/WbBuSm/VUzCEtL9ezvCFv8iNRN/Y4/Zrz95KMJ7GWQGwININSrGvSRjEvhYYtHWJ6K+cD21heUBmPG4P8C1c3AoWa205CNRO9z1H5HjrW40urTYKsTSW28QE7jLs9cP6Itf1x9xhGJrs64vcHnS+FBaYQTC6UjlixNt8N1JVDyPC+J3ju9a5+qxRL7O1PZpc9Qi1ZZcX5tAUVxXXNsL44Fq74RzzDrZMEj8KXLbyVk9MYEmdLbcS/cZFqCjAxWaQEjQRLHnnus0IMJn1MSNTTL7Dyduj66e1RC81IZrVal4nrkbmDmfAFKvlIOaaNGbytnAzt2cLhNl2x8NLcoLjfi1PxdvSoDAbaXG7w/zfSvGD4gVdWtXJbp4F9x35nU+ZT
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:08:21.9155
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a1b67b9-1c5f-4880-e601-08def7a99ee9
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BY1PEPF0001AE1A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF8FCE094C0
X-purgate-ID: tlsNG-ef75cf/1786453709-36CDFAE4-25BD2EF8/0/0
X-purgate-type: clean
X-purgate-size: 344

Noticed while reviewing recent vsysreg patches.

Michal Orzel (2):
  xen/arm: drop unreachable EL0 check when emulating ACTLR
  xen/arm: drop incorrect EL0 accessibility comments for
    PMINTEN{SET,CLR}

 xen/arch/arm/arm64/vsysreg.c | 6 ------
 xen/arch/arm/vcpreg.c        | 3 ---
 2 files changed, 9 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:08:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:08:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388204.1629434 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmDj-0004S5-EK; Tue, 11 Aug 2026 13:08:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388204.1629434; Tue, 11 Aug 2026 13:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmDj-0004Rx-Ae; Tue, 11 Aug 2026 13:08:43 +0000
Received: by outflank-mailman (input) for mailman id 1388204;
 Tue, 11 Aug 2026 13:08:41 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wtmDh-0004PX-De
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:08:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtmDg-009MW2-Li
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:08:40 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7b1eb3-e002-0a2a0a5209dd-0a2a45038ce0-38
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:08:40 +0200
Received: from [52.101.43.24]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a7b1ed6-fae8-0a2a45030019-34652b1869b7-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:08:39 +0200
Received: from MW4PR04CA0205.namprd04.prod.outlook.com (2603:10b6:303:86::30)
 by DS0PR12MB8072.namprd12.prod.outlook.com (2603:10b6:8:dd::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 13:08:27 +0000
Received: from BY1PEPF0001AE19.namprd04.prod.outlook.com
 (2603:10b6:303:86:cafe::3b) by MW4PR04CA0205.outlook.office365.com
 (2603:10b6:303:86::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Tue,
 11 Aug 2026 13:08:25 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BY1PEPF0001AE19.mail.protection.outlook.com (10.167.242.101) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.6 via Frontend Transport; Tue, 11 Aug 2026 13:08:25 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 08:08:25 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 11 Aug
 2026 08:08:24 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Tue, 11 Aug 2026 08:08:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yy3IHdIRV6uSAY3yuBKGyRBwcGgOKMsVMJ1OUAgK7+YZ2virNNgMhkkEtbHLqxscGcOXxI/fZGrAAJuMXCUeIynXFLKK8idJQfsVKTTRkFnQwlCKSijTcqJGMH3CsFAsTF1PGVqpG1wiOngAiLIFRPNW/GWZN/EgfcqBr6BMi1aOf3pX18IK3cXV0ERNFkDwcAkHVrZrq33zH+Z7wmdOhiXc9lmWwjx2uji9GsNyf2qeULEjTr0JJQ/b9L0DcX9mif6c5ShdL8pG8ihazUmZNVAY88DuGJXU5VhaHpy/Xe4p1vRzZBU3cV75IwyL/Z3F4wJMF1GwqIsOKCZsVx4u3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=t2SKxcmYWgXuUTR76GzBaCM/d/NBn5uY75sGmQkZr1g=;
 b=aZKp+Pgbg00aLn7VpRdehZuG2kU3AKAOJzAQTyo85U/nL5Yph5Ey6jdppCq4tsFeSiC5V89qGLtD8Yn3Y7UUeVnzudP+EAJYN1Enjb7OTCnO+nUtzkkzB/it4PnVvj6TDwYKWT44MV8JiqL+pFvN/mlqvVDbVtoQ74Xkl+rqr+QiuqcAEGN1U+N2F6FjCZS5OSy6SSwKtUXEIfbU5/ms8tdQmCmNB40cJj9O6DG34YafRp8Ez72eqdmhk83w3ZOtUyKOCxa4vfgFy1oMcKaU7jmF0SpR5+ij4JmeE0BO2umt7r0599wAx/fMi4yhIncUeQYwkh7htIKyGDIyOqQJgQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=t2SKxcmYWgXuUTR76GzBaCM/d/NBn5uY75sGmQkZr1g=;
 b=rK7XlvLHHmsCUEH4w0qsK8D2kBceaJvCdZ9DgHpVVsM/jpGn1RaTaIVpbD372POpTr8FYJ8sgcX89YDE5p1f2bQuPCgBnY2ntelctSD8onazd4feuUMCE7FcnTKF7CfSAsS5Lhdwf0iL7sUPmJOgZzer0jX9YucE3ivG04TpFf8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH 2/2] xen/arm: drop incorrect EL0 accessibility comments for PMINTEN{SET,CLR}
Date: Tue, 11 Aug 2026 15:08:18 +0200
Message-ID: <20260811130818.123862-3-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260811130818.123862-1-michal.orzel@amd.com>
References: <20260811130818.123862-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE19:EE_|DS0PR12MB8072:EE_
X-MS-Office365-Filtering-Correlation-Id: 58746e1b-f68b-4e02-711c-08def7a9a0e4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|23010399003|82310400026|36860700016|22082099003|18002099003|56012099006|10067099003|11063799006|6133799003;
X-Microsoft-Antispam-Message-Info:
	J2XZbPqGvmm0NBQVhW8WSto4Ng7tUUm0bKcNd8AX8RpfoiBzQa68Fgkr1XQhduV8Sq9tClJiDSl3uiatDT1vF4PhHwWWFNYlb4losAJWYe85SCUHqoPr7vvHFrNNKdIJwfHHbjranvuN5goV4j6axBhDBtropEhKUc4ofQbeyd3UxeFS0ORiQrwgUaqEujiB7FYPM/ynD1PNtsxklAGKTtVo95FpXSMIjcu8YSAYV0V/L1xyMnpy1GR+zYCUfd63p/2DXzuG1rMU0r2iSJX2nMJM8xKk159ntPACr667gHZQGzLKyGyIAg6CAimeoAiLCrDzJA0vwL79/OhBBnHAo/V0MpKzK0vmfKtT4dyu7rv4VohFgXiERGL5VZfhdlURrN0Ljfi+1h78bs+9MnmipStsuTeEa67Se4lUTlBR4QCuVGQA7RukKaAIvpOcjcpb7N6ZA9bmz0oy5ckWSiY13CAE44FXZ30K4gayn8zFGLz9B6EpQPQVXAijk0Tp1DE/RbVVMCZIXEGNDrH8TL6f05bwwh7PXL6+Qc/TXfkHz8LPNIO5aKeK8y5WqA17TX81jHO8movwdRKPz7eEkAd8UIvwkBkzw5mKsx5qeZCtYRbI/WlRWf/MBkfOWuCEL8eBH871kE2pwNPeNaSx5JmcOwSj/YLL9sJ4h3pLcdXbIaXpTOogXCEyzUkUis727SReoKblNX9KyUVVzkkEwvOrtQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(82310400026)(36860700016)(22082099003)(18002099003)(56012099006)(10067099003)(11063799006)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Hg783r01a0go50NxmbIleMxqijc28z0+ZRMoIuBQI8uIrcIHBo2bm4xxHVgYledrfL5Ffx55R5Nqm0M+b9mQSH8wJ9dru3K19Wd7Gu9Y9zzsyeHR97afWbahDfrAl+QkQfkMK0G+eMG1BSgOzX9b75ox1+bOUmjssKNUHhrvwQgYVWlx4K33/Z7jz7Gvkw4czX7ngVEdu4KH0B1liD+iumSXP1P5ZFEJBVJw2DOukIP4FyJcumSBQwQjFA7ARP1KJGwAD5R44e6R5Neg6IahB/aehdtJbh+R+XG4W0l/BFBSrYaCwEQEm/8EE6j5mpK/wz1GOgHI7TbAx4uBvd6Xuy/kwsqC6UKNqAaXDLb3/0en3cC31l/POUzUN3Vrb+7cRWNe3vkooSvqXCPJPPAZy+IH0AwJZSPVF+NvRJ/lO6VQNkSYDtSMfkj3NNGYDeki
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:08:25.2958
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 58746e1b-f68b-4e02-711c-08def7a9a0e4
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BY1PEPF0001AE19.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8072
X-purgate-ID: tlsNG-33051d/1786453720-6D4D74E9-0487D19E/0/0
X-purgate-type: clean
X-purgate-size: 2068

The comments on the PMINTENSET/PMINTENCLR cases claim that an EL0 access
may be trapped to EL2 when MDCR_EL2.TPM is set, and that such a case is
handled. Both are inaccurate. PMINTENSET_EL1/PMINTENCLR_EL1 are accessible
at EL1 and above only, with no enable making them accessible at EL0.

Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
exceptions" orders the two exceptions. An access that is never
accessible at the current Exception level regardless of any enables or
traps is priority 18, whereas an exception taken to EL2 as the result of
a configuration control in MDCR_EL2 is priority 24. An EL0 access is
therefore UNDEFINED and taken to EL1.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/arch/arm/arm64/vsysreg.c | 4 ----
 xen/arch/arm/vcpreg.c        | 1 -
 2 files changed, 5 deletions(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index a59848889659..2ada791f4ea7 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -228,10 +228,6 @@ void do_sysreg(struct cpu_user_regs *regs,
      */
     case HSR_SYSREG_PMINTENSET_EL1:
     case HSR_SYSREG_PMINTENCLR_EL1:
-        /*
-         * Accessible from EL1 only, but if EL0 trap happens handle as
-         * undef.
-         */
         return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
     case HSR_SYSREG_PMUSERENR_EL0:
         /* RO at EL0. RAZ/WI at EL1 */
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index 749ce6d3a57c..b0f3c7759a04 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -295,7 +295,6 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
             return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
     case HSR_CPREG32(PMINTENSET):
     case HSR_CPREG32(PMINTENCLR):
-        /* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
         return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
     case HSR_CPREG32(PMCR):
     case HSR_CPREG32(PMCNTENSET):
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:38:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:38:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388233.1629443 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmgh-0001OM-Jz; Tue, 11 Aug 2026 13:38:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388233.1629443; Tue, 11 Aug 2026 13:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmgh-0001OF-Gu; Tue, 11 Aug 2026 13:38:39 +0000
Received: by outflank-mailman (input) for mailman id 1388233;
 Tue, 11 Aug 2026 13:38:38 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wtmgg-0001O8-MH
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:38:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtmgg-000GUU-2t
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:38:38 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b25bf-e002-0a2a0a5209dd-0a2a450aa71a-34
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:38:37 +0200
Received: from [40.93.194.20]
 (helo=SN4PR0501CU005.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b25d7-f2d2-0a2a450a0019-285dc214c408-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:38:33 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DM4PR03MB6858.namprd03.prod.outlook.com (2603:10b6:8:41::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 11 Aug
 2026 13:38:27 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.024; Tue, 11 Aug 2026
 13:38:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=e0CLk4J2stuWAhXOBoCfQwI/rrEwlLRX/PqHpH1CpXWVoaBs9JODVb4qKOR3ZRa2TR9RAepIWoT3vKcxhRWHvkAqXCLfmZj0QTBN9CcR/Ay+5gTtBdfKGFbYAXGEJLP433QhTQvz+igVnHOnRLCOynt20YkjQ0TuKCeMBwI2q1QeIM1h7ebgmS2iCXMd8i0afs8sB04IW+hH3d1KGmCMw/cYkunDJdExm9NsXSK0InaJuwEbge3f1QgjDVKBbYFEOxarRY28KaON8r+K/sz/bPkfANQw4iurwUITlxP74yLRzHYeaGwPYvyxDRYjWgDLA1UxmHlQdt2eAb9shm3m0w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7QTRLCpkWoX+hi2L0lT2Qf+AYscjDWFwY6R/CRrBUIw=;
 b=Ey1xeMfWbv/jodqZhb9/BYWqE5w8laQPVFxbCTde6D0kjEesNn9zKKPTaCfZpfsofKKddO0BTYP9wHtO7SdszPkOVgwBaE7twaYOQykmp9GZmZKGi8ume9rRtyxDnrpsHPwa8slUIl3YhONnrj3tHRD3SOxjyE1e2cpvg+vEqshSY9jxLnUfeyAi558ERYgTNLwQhdrybHtYM97JfmCYSJRGPsOHKi03cqhUzPp9aBL4DkOVsHGdZZYNZm/U/1O+c0u/BU2M8xikbOTgI5KQjddF10iPrqUyhrXkaOZ9wZSbGTaR7YqobTQZxtjc4GgxIA+XoPhLDTRLLXJ7V8IIuw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7QTRLCpkWoX+hi2L0lT2Qf+AYscjDWFwY6R/CRrBUIw=;
 b=rfiouETIAU7hlB7dsqM2EWo5eTM5xxCw0byw/st6RJ2Mvmc2j4ZMWToKMUqAcG/FfxPlQFUeAhVb6h/KUuoyxEmAIJ1v0usKNtkmcqe4q/R4Krd8MPbnNqmE+0u7/p3R4Y3XIS2zB2N5gc814A56s3hAA7ASWvwhyUJJi1eXTIU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <5c920195-efc6-460d-b2b2-743911d7916d@citrix.com>
Date: Tue, 11 Aug 2026 14:38:18 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Juergen Gross <jgross@suse.com>, Andrii Sultanov
 <andriy.sultanov@vates.tech>,
 Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v3 2/6] ARM/sysctl: Expose the supported guest GIC modes
 in physinfo
To: Julian Vetter <julian.vetter@vates.tech>, xen-devel@lists.xenproject.org
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e427000edb5@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e427000edb5@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0211.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a5::18) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM4PR03MB6858:EE_
X-MS-Office365-Filtering-Correlation-Id: 8ab3a881-a964-4995-43b7-08def7add15c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|366016|6133799003|56012099006|5023799004|4143699003|11063799006|10067099003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	bzLXZtb0FC81lOASNTN3VYXmyM1hYbJwns37ooog+sCugtnl6+bGAQFnclBIw0B4zorVUB9nS1Sim0bhNr8N4qg/Rffygfd0uV5OM5FSKuogOtx0j61AVEsrn2CNTms8TwRq/bNIkuhebjkQW9fINmQevYXHUp4Mf51mnSTP+boCK17CYZssEOWFwGm9l2uO1iHwk6wrT0kZiZI+hDnfLA07UJ1uyKYNktQ3zQD1McIhtWE+xq/vGqpY09zncIKnmIk2kjmkYg4yF+laqbRUZzH77BizeR46AHn60rTQP3RtJE7dsdPizxS06aSYyvpCtdd3cfb0SkbsxkV4zjxfH/YWPoLVxMRCsxTyE5Gn2vacdjftYPC+GnL62rwqadh8WuGi5jMgwObJhu694jTTWA1gQu2xjZZckIUUTqki6KJRsy2EQkeaqXUHl8WFKBCBfxAQ3+XWYlxXZE0pcoFdc5XrMtgF0YPhi8n6f9OX7T3d7wYNU8lDyMm2oWeihLPs5BpjC0Yntnq/bCxBchrMJznj0mJhnQk84tEHrhiR35nSNPkT9FDumkwvOQUSA1+5O/MrDpRzNO16kvow4luetam5HKvLGUKAWiSVMRpdO0kywc6IHJpx72hAzL7aSQf8QQySWZYq0X5xVRxLca1Gt8QUIDlrKbVIhm7kj5UkfRQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(1800799024)(366016)(6133799003)(56012099006)(5023799004)(4143699003)(11063799006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?U3EwYmJWQmdxenlMSFVzYjF6N3ZUVjl6U0t0UGtBRGJ4N0FDNnlIS3ZBa243?=
 =?utf-8?B?M3l5SVFhdUdabGh0QW96eU1jTWNRaGxTdlJMRzlMOFAyWHo2RUFST3BPOWlv?=
 =?utf-8?B?djIraEdXRTNxYW9XWnpmMEdsYzl5ZEtPcHI0eTBFazRpbzg4Sk1ZQTg2dlhT?=
 =?utf-8?B?cTFBYW9ocmNiTVk0enZObTBtYytLYTFKWGpoZE5rUmdqWkp2THorVlRmNHNE?=
 =?utf-8?B?RkZ4OHYyUXA3a0MvZkFSQkwyMVJLcjgzcHRpbzdzQ3laNkNVWHFmUlpoRFVC?=
 =?utf-8?B?dHVzWmdocERzTGZOZEFTaE0yNkNXanFUbzd0TUhneUZrZXMyaFBxdUdtYysw?=
 =?utf-8?B?blllM3JDbHg2M1VPVzNrNHBQZDMxUnduYWpQSzkweW9wOXRhYlo2SytoTUl0?=
 =?utf-8?B?dkNiemdOMGFhMm9LbnVDS2phV0FPTEpCTVZ2ajB3U1ZNc2RBa0FoTG5VM1E5?=
 =?utf-8?B?cGFaQzQrcjRPRzdKUzZaUXNIdDF2VXQvdE9wY05BQzF5UDhzQ1Q3emNtTnhI?=
 =?utf-8?B?YisrLzEwNVNxZmtVb2w1U1pIOFJ0aWdkakZOb1R2V2s3TlRiYllGNk1xTkJ2?=
 =?utf-8?B?dE1SMnNqblFzbGlreGx5RlQ1R1ZQRktjeTZKejgrMHBTelpwa05FaExHUUZj?=
 =?utf-8?B?V3d0bU1EcWsxQUZsSEtUNFRDS3BsdlVRVUZVKzdaOEZocXhHU0E4QWdaNEhR?=
 =?utf-8?B?RG1ubGQxT1huRVVqc1J4N2RWWjRKZ3NQNkJGeGFJbmJJMGhLTXl4cGZqRnpF?=
 =?utf-8?B?WGl6TlltNkNUbm9OQlRsajVha3lHclRyL09YWUFjWEJMS21tWitRdXdMUjFU?=
 =?utf-8?B?U0U3OEl2Z3dZbHYxNXlpNk1TdHlzWXA1RXNRT1NIRVNVTU1DVGpzN1U4Tm9B?=
 =?utf-8?B?R3pyNWJPRDJacm5OdHJZeGdvUUNNbk9mcmtzVWFOSkt6dTgzakZkbEVLZFhT?=
 =?utf-8?B?UzNHZkVNTU1qNUlOYVJaWm1jeDdLcGdSKzJTM3dTbHA1TnpOWmxwSFk2d1Ns?=
 =?utf-8?B?bGUxdE91T1JBb2dhWUJ3NGFPYzlYTUNYbDNWYjlpUVM5T0dBcG5TYUl0SlBq?=
 =?utf-8?B?UUg0OFdwek1oME56QmJQSGpsbnJCTm9uWmdKcm5YOFZpUXpuZXhLSkNrYkpP?=
 =?utf-8?B?OUx2YWk2ZzhKVjJIVHZuT25mWFdTTUJmYnFJQjBCQkZrRmxtZjMzQlJMZnNp?=
 =?utf-8?B?VWt6SnRubDhoUzZJRVhuMERRdmFZQWJ3RkZWaEZrS3NFVHJVaGVkbjdEckFV?=
 =?utf-8?B?WDBNaDIrTHA1c1hPcUJQWEpoMWJnSitIYm5VZXA3eWdjaHBqbzBqbnlSd0Iy?=
 =?utf-8?B?WkVuSHZXV25XTEZBYWZYZGVjUGdOeDBBYTAxcnRLVmh0ZG9sRGNaenZMbk53?=
 =?utf-8?B?KzFCRllsZ3VkNklxUTlDMWpsQU5XQ1BxdXpOUE5mdWQ0VDFSS2grSk9ISld4?=
 =?utf-8?B?Q29EQlYxQTUvVWVuVUNBWG5wUFJQSEF1bTdjV1VEVUEveTlhMHkzOWJGaEkr?=
 =?utf-8?B?bmVESzhPQkJBM3phMlZreUxiQ3NtVnpXZUlnVGFyMmJXWldyU1gxdjhnNzQr?=
 =?utf-8?B?U2lKSnNMS0NUblRJZmFLd1p2SmhSVCtCeVY3TU0zeGhXdkFTR21yWUVwVlFa?=
 =?utf-8?B?OTNvUWFLUVpydmZFdEtLRmljdUNEUDRBdkw4ckhrVnlMTHo0U0srZzZ2T1Nm?=
 =?utf-8?B?VlFhSnNZNTFFUHRVS2picjBYR2lQR1ZsclU5R254NVppalJ4VVVaUHhPa3lz?=
 =?utf-8?B?cjc3anVYdXR5ZGxwKys5RjhvMXZ4aDErRUxEQjRrbUdXZGR0WkZXZnA4SzVn?=
 =?utf-8?B?QlBvWGRoNTlrYW83NElvU3Z6ZUFLNnJ5eENnWE92N083UkxhQmVNQnIrdjk5?=
 =?utf-8?B?aXptbEhQdEdLeXhJNVFJMU05Z1ppVU4zRmN6Ti94VEZCc2VCVW1sb283Z1Zq?=
 =?utf-8?B?eUZFOGFPVWh3U1VuOGE4V0phc1hpVDZYT1ByQ1dtSFFqdGtwU2tKMHlrckZ0?=
 =?utf-8?B?WUxOWDdBR2plbDBENWZjT3k5UzZkdWVyZDU0UXZ4bDBubXRaTGM0NW5IUUhx?=
 =?utf-8?B?UGd5dlNpOHd1SHZTV2o0bTlmZHl0RzdKS1dWWGMvTVRSNldTMXhIUkxxWVY5?=
 =?utf-8?B?R1pQeUU3RmRiMUJnWU5SbHZHNTdKK2FuN0hHckxoYU8zTk9DWXhCdktTbTdR?=
 =?utf-8?B?bWY4OXBNWUtBM0FkNC8zRy9hNnVLK0lRTXowQklBYlBDa284aWpneHlpUGdW?=
 =?utf-8?B?bmFnZzM3WFhXaXA0elhGdWxZMDNNQnV2NkNxMkl4bXQ1UnRsdnNZY015MVRt?=
 =?utf-8?B?c0JjZlNmSStaWDFVMk1hL3dsOStVU01RQ0FXRmJrQUhRK25LWW5Hdz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8ab3a881-a964-4995-43b7-08def7add15c
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:38:26.2007
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: wOMQ7JLq+cB9ctRnJVpPMCzdXp2tYSHn3ly+DfNY2iTUDQB51AWqwJ8bjU3FjFiD/OZoWf0w3j1uWMuQT5Y2ekc0k3tGo6HFBsBu59Mzpg0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6858
X-purgate-ID: tlsNG-4011c0/1786455513-5A9D9CFC-375AD3C8/0/0
X-purgate-type: clean
X-purgate-size: 2109

On 16/07/2026 3:11 pm, Julian Vetter wrote:
> From: Andrew Cooper <andrew.cooper3@citrix.com>

I supposed I should finish the commit message.

"In preparation to simplify the domain creation logic surrounding GIC
version."


> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> Changes in v3:
> - No changes
> ---
>  xen/arch/arm/sysctl.c       | 26 ++++++++++++++++++++++++++
>  xen/include/public/sysctl.h |  2 ++
>  2 files changed, 28 insertions(+)
>
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index 32cab4feff..3b0edf4cec 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -12,7 +12,10 @@
>  #include <xen/dt-overlay.h>
>  #include <xen/errno.h>
>  #include <xen/hypercall.h>
> +
>  #include <asm/arm64/sve.h>
> +#include <asm/gic.h>
> +
>  #include <public/sysctl.h>
>  
>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> @@ -21,6 +24,29 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>  
>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
> +
> +    /*
> +     * The GIC version(s) we're happy creating guests with.  Right now for
> +     * simplicity it is tied to the active hardware version, but this will
> +     * cease to be the case if/when the compatbility modes are enabled.
> +     */
> +    switch ( gic_hw_version() )
> +    {
> +    case GIC_V2:
> +        pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V2;
> +        break;
> +
> +    case GIC_V3:
> +        pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V3;
> +        break;
> +
> +    case GIC_INVALID:
> +        /*
> +         * Running a control domain without having the GIC sorted yet?
> +         * Something's broken, but there's nothing we can do about it here.
> +         */

printk_once(XENLOG_ERR "Unrecognised GIC version %d\n", gic_ver);

We might not be able to do anything useful for the caller, but we can at
least make sure the problem doesn't go unnoticed.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:43:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:43:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388242.1629453 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmlG-0002xU-85; Tue, 11 Aug 2026 13:43:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388242.1629453; Tue, 11 Aug 2026 13:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmlG-0002xN-3N; Tue, 11 Aug 2026 13:43:22 +0000
Received: by outflank-mailman (input) for mailman id 1388242;
 Tue, 11 Aug 2026 13:43:20 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wtmlE-0002xH-LW
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:43:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtmlD-00EaN9-UL
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:43:19 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b26ef-e002-0a2a0a5209dd-0a2a450ae408-36
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:43:19 +0200
Received: from [52.101.43.18]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b26f6-f2d2-0a2a450a0019-34652b12a380-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:43:19 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CO1PR03MB7817.namprd03.prod.outlook.com (2603:10b6:303:26f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 13:43:08 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.024; Tue, 11 Aug 2026
 13:43:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gFnLaDSzHdiBahBBUdGKIrSPyvQRPy2K79WUDL72kH3vOHQ524xbgwxZH+BfaQB5FpjvGLOgTIGRkxX0yPQTu+REqkCIzP/lXw+11xZe9mbJn1rBunExM61BdEy2L6cjuisuCO3Dzj8EhbAd3Za9HEFjuoFWaus73wTg1Nr1GiD9L3Qz6Aeisgca2Z8k/RwHPpdvN/pKJiAjwBjVSWIPpDcG0Gm21G/AQEjwjYfb0D62a3KjegtM0Xvo3XHjmgYK5bZQ++iE2P59PqugPbuF1if1+zcb6hXeYzzfD/pjYaM7rJYwkHtv926cVUKc50kV8qLeTxfXHSHmElGEX7ddQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=j6HJleX/8qOcArZJBfZRiD8XBv61MP4y4fmJda5DMlk=;
 b=yBNaTPTeZ+peQdGu+OrvSYXCwB7CaJXdnHBQuIS8pP0i4BFD/yrEnKyfBotLueRhKiQWAEWi8T3ptITSS5s1Q5vxCJbC8H6scuJfatClkV7MakeV1Vg+ZoOAZZb+GPgTd/QcOH9cviWjxSm6nX2kE7r223YtL6zYcMgBzgLeC+6NdKF+r+UmiWvc3tcy//W/fY3KmVVBSelNzQ3KGdeFXvEYEWRCWmQVRKYv6zEpFD64ORPJq/cEIzAbAovY2bkMYcjZk7yFt4uUP4L90xh6mx+UwY+zHjMp4TG6r51ljtdDzJ1iBzD1Z1v1xHLNMQJff3W+ueQRmH+Qj0GDp8nEqg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=j6HJleX/8qOcArZJBfZRiD8XBv61MP4y4fmJda5DMlk=;
 b=W33IEWJkhvqHmxJBhJ+aD0YZQb3IR2pDEMZCtVgHwFK0A9KpGe5c+czlaN4h43PjXMkX9S4gaZ8/8F0Fydhp7sXeqtAh+OWgly1ic30PDHTvvpbX0t3KfvF84eyzlbYrOy8Lg2ABoOxG85cKhd5XtpnxrZxFhHhbgo3Z1m/TSIU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <a766db65-4c46-4d8e-8677-ce1d8d014436@citrix.com>
Date: Tue, 11 Aug 2026 14:43:03 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Juergen Gross <jgross@suse.com>, Andrii Sultanov
 <andriy.sultanov@vates.tech>,
 Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v3 3/6] tools/arm: choose GIC version explicitly instead
 of relying on GIC_NATIVE
To: Julian Vetter <julian.vetter@vates.tech>, xen-devel@lists.xenproject.org
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211105.8631fc262581453bbf619ec5b2062170.19f6b44e5b6000edb5@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1784211105.8631fc262581453bbf619ec5b2062170.19f6b44e5b6000edb5@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0676.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:351::14) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7817:EE_
X-MS-Office365-Filtering-Correlation-Id: f0db2984-4836-46a8-1904-08def7ae7a0e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|6133799003|4143699003|11063799006|56012099006|10067099003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	ozy4epcRdDZeMaXOPmbsfIv5/Y0y5kO81xhkjVDpFjQy+EwE45JE4QrWk6pnkALqmTGvmDtEXgu2KBsfWlC90AEFCyOiBydLMjcIbmUBaYM5a+8sH/AGAtGfyYX0EUfsbY4rv+3MjatBhB2al3NUd0GQTBhOTeAn8BtnGcZYsdQTHyKZ1MKSwIDebOehRyIJCi9gGaBuxa6eILueslfdDdlwlQdgb92D+V02CvYos2cNjmSVjFkmm7nU2erosrUNwcIPVfrgFbIP8nhunsw12/P++UGcFhH/H6yDwYz2rkUds7yFLhxQZSKOj2fQWyBOrlrAc2tMmjewZUrUtCsuC0E006brgbFKPGNUFl8PBYBB4CFtORUb3YimaK+ewdNWl70eQw2HMfFZ+20OrvhkPPqBzuRN+X89I+3+K3FBJuCQCXUgt6pa2qTTA2cfLagK5LBk4VwC9TfuZ5xEcQn2QomAh0VUJkPKHR8taiUfmlKSk9YxVsAbWv8NfBno0nnDVBaTGq5rWR/Nceb6SiTEjFXCUbDjd5KRb/kdvuDfxICw2D50FW/IrEveuT+nhzM6UeSQKszHttVw2TmRpiwi6HCrtLyl8jYQ52f+HSaMuxsrO0gTRTWEWv/KIygyeaab7yBfsDhLtCaTbyMO85RZ86LwxpRWjrNV82wxmwtdbhE=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(6133799003)(4143699003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NUVrdVBGY0FjMHFVUHRXQTJBUHRzVzdWenpiOTA4MHhXenkwSGwrbHZMRldL?=
 =?utf-8?B?YnNDR2h0MEx1cFpHK0NxT2NjMHFMSlNpOVVJaHFCSEtqelFpYUFSdDdrbzZH?=
 =?utf-8?B?NkI5by95ZStzdUN2cXZuVDNUTXBrSVF6Q25xc1owdmw3a0lPUEJ0TXJuem5s?=
 =?utf-8?B?RkZtamdzenF1dzFDVEFaa1ZqYkc2dzhhb1k2R2Q5Wmp2NjRwY2F0aUZJR1Nu?=
 =?utf-8?B?YWVISjVGVDMydklpWVpnK2dQdnlRbU40N1h3cVZyUVhkQjNXekFMT1pheW5Y?=
 =?utf-8?B?OTZsQWRYaTZkU0ZxdDVjRmowQWwyMlhpWXBjNVQwUGpUaU1PdXhvZkd4Mlho?=
 =?utf-8?B?NkZwT2ZLU3Y0QWtMeFNTSW0rTER0d3FoSGFRQjcydGZrOElHRlppb2lPakF0?=
 =?utf-8?B?VzJOQUxXVWNiK3ZDeU1vZm9DMm9hN3F4aW1SMGR1LzY4Q0ZzNzFEWVBSbG96?=
 =?utf-8?B?UHRGOXlJeVhkdzNCNVY4bURaN1pWSGhMS2piLzRQMFZvT0dVME1QbERXM3Er?=
 =?utf-8?B?aFZEQm5WSXFXTEc4SVNrL3QvaDg4YmFHSEpsWFUzdWk3VEowWnlTUWFwdWFt?=
 =?utf-8?B?Z3RURVpLQTVFQWdIb1FHZlZPcDAvVjUxRFRhM3hBWDR1R0RML01mZG4zSlNl?=
 =?utf-8?B?bFNlejZ3aHlXOFJvZFlURGVuSHJwUU14VU1IMC85ZnB5U01FWlZFcTNsd0dU?=
 =?utf-8?B?Y1pFNkErbzQwbEFjb0JlWml2OTcxY2hWNjZybEVqSjlyZDhjcExkeW5obEJl?=
 =?utf-8?B?ZmhJeWhzRmx4NDd4UWsvMUhWT1AyOEh0cGxJdC9LUG9aUEZNSFl1UGJUZnc0?=
 =?utf-8?B?bEJySjZzemNjZVljSlZBVUdXckNTaHlxRFplTk5hWGlnZml5ZGFZdE5BbVFx?=
 =?utf-8?B?ekZEYmczUVNncWg2UWpOUVc0ZFhtTzZFRVY2N21PMFZzME14OHZINlFuS0FW?=
 =?utf-8?B?WnhLaEVBQTNFaGgxNWtZWGxWdm5jY1pmc1VSRk1vS2M4UGlPMkdubG1KeXpL?=
 =?utf-8?B?RURRSkU3S0JDTnVidFVFOFlaWSt2QWlYcllQbzVRZTRQOU5hdGRBRnJXQVkw?=
 =?utf-8?B?YW1XU0k5NTBzM3N2blhrT1d6RElBVE5aTDQyRWRPbElIb0NoWUxBa3JHcHNB?=
 =?utf-8?B?R080RzFGMk5rNlJtZG51K1QwVm0xSzZIR3ZjMHpuUWMrU1U1QzBJTXlnby9l?=
 =?utf-8?B?VHRJUERVc2ZENkNCYUJNemRjeW84SFgwYXR2dXVBSHZXeUtUeDd3UjJtcldU?=
 =?utf-8?B?azdRMFArT0hCUGFBaWFlN0hEc2hiWEc3L3NzR3UwUUNlSkRjbjNVb0FmSEty?=
 =?utf-8?B?aTdsQTR2OXN3N2RwSW1pemFaNGxxN01zanJSOVh2c3k1UStwWlBEdUJpRzdI?=
 =?utf-8?B?VHZQMmFCRHZNSS9pRTRib0xmYm5YTUxRSEQydXZ3Q2dqNDBPSzFYbWJvRG9R?=
 =?utf-8?B?cDNHaEFzOXhFL0ExSFRZUUdnckhWSFBNa3ZWdWtOcFp0MXZNelhTSWpUTmNN?=
 =?utf-8?B?bHNsRVdMTFM2NE12RUxrWHZlQUJscXE4VzRCTU42SGRYTFhUa2FLR0d2K1Qz?=
 =?utf-8?B?UUNna3d3MnV4dER6QStlNThzem1lb0xRSVNscGZBaW84QXJ1RS83QndwVkZm?=
 =?utf-8?B?V3JBV255V0JGRXAvNUk2TmEzUzV5aUF0WGk4ajQ1ckpYWWExOHJqQmJkK3hG?=
 =?utf-8?B?dTNHazdnK0dLdGk1Rytpb1p1OWpLU3Jpa3laZ1hzRVAwMmlQZmFtWUVRbWs0?=
 =?utf-8?B?QTNsUUF1RlN2aGhrVHkyZDdURXhrMHFOVXliMFYvNFBQQk5LNXllRVQ2empX?=
 =?utf-8?B?SXRZZEM0aU1pWDg3MTJMYnF5VHBSMmxONW9VUjUxaXVOei9ZS3dGb0JkTHNq?=
 =?utf-8?B?RVpkcEVNZUdieHdUeVlwUlJYdEJVNmxwUGtlRGNXZkFvY01hT1VnZ3NYMkVH?=
 =?utf-8?B?WHhyVDJ1UWxJcTNSOWtLejFORUhnbGNGd1F2djkrMGh6dmxZeldPSE5ORS9v?=
 =?utf-8?B?VWVVbFZsYWdWd29OQmg1OStXSVE1c1hsbzlENElmVHJRNFJHVTlBc2R2dE02?=
 =?utf-8?B?bmp0Zm5TK0xFc1dua2FYbkJxaGpRVEs5enZRNVBDUmIwRC9sbnhicHdxWkp6?=
 =?utf-8?B?RG1ROWROVTJiVitaQ3lmSWhZaHFPN25FRVQxeHZNWExYWmtMTEVWUExlOWFM?=
 =?utf-8?B?RjRNUi9NRDJjazhGUUJWT3lxZW9DeEhQd0EzcXh2QmtqcFExcThWZm5iN0lI?=
 =?utf-8?B?MXpJVEJ5OVZzTUJQVkNSTXZCNGNiU0FyQlBGeW1zd080MXdhUU1mWDZ2Wnk3?=
 =?utf-8?B?OUhseThxS0FJRVZmeFNJb0czNWU5TitGQUM3enUvWXpYN0ZVWlNGZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0db2984-4836-46a8-1904-08def7ae7a0e
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:43:08.2244
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ruMlxaLIYkwopAsebD2mE0z3w8wmR1YV9Zv59HnJFp2VfFy16IcWbZxLTfVoPCuyvXKai1PiRxZ3Usn/8Vl+4jIaHYEp4eejJ2uUY2F9RV4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7817
X-purgate-ID: tlsNG-4011c0/1786455799-50CCBCFC-D643FEAD/0/0
X-purgate-type: clean
X-purgate-size: 1100

On 16/07/2026 3:11 pm, Julian Vetter wrote:
> diff --git a/tools/include/xen-tools/arm-arch-capabilities.h b/tools/include/xen-tools/arm-arch-capabilities.h
> index 4aa4c6c34a..6397df696b 100644
> --- a/tools/include/xen-tools/arm-arch-capabilities.h
> +++ b/tools/include/xen-tools/arm-arch-capabilities.h
> @@ -25,4 +26,19 @@ unsigned int arch_capabilities_arm_sve(unsigned int arch_capabilities)
>  #endif
>  }
>  
> +/*
> + * Generic test for any single-bit XEN_SYSCTL_PHYSCAP_ARM_* capability, e.g.
> + * arch_capabilities_arm_has(caps, XEN_SYSCTL_PHYSCAP_ARM_GIC_V2). Multi-bit
> + * fields (like the SVE vector length above) still need their own decoder.
> + */
> +static inline
> +bool arch_capabilities_arm_has(unsigned int arch_capabilities,
> +                               unsigned int mask)
> +{
> +#if defined(__arm__) || defined(__aarch64__)
> +    return !!(arch_capabilities & mask);
> +#else
> +    return false;
> +#endif

You're missing a } here, and I don't see it anywhere else in the series.

> +
>  #endif /* ARM_ARCH_CAPABILITIES_H */

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 13:54:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 13:54:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388250.1629461 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmwB-0004vI-4X; Tue, 11 Aug 2026 13:54:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388250.1629461; Tue, 11 Aug 2026 13:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtmwB-0004vB-1G; Tue, 11 Aug 2026 13:54:39 +0000
Received: by outflank-mailman (input) for mailman id 1388250;
 Tue, 11 Aug 2026 13:54:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wtmw9-0004v3-G0
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 13:54:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtmw8-000Ibh-Sa
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:54:36 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b2998-e002-0a2a0a5209dd-0a2a4502a93c-16
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:54:36 +0200
Received: from [40.107.200.15]
 (helo=CH5PR02CU005.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b299b-6ca4-0a2a45020019-286bc80fb257-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 15:54:36 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by MW4PR03MB6946.namprd03.prod.outlook.com (2603:10b6:303:1bd::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 11 Aug
 2026 13:54:31 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.024; Tue, 11 Aug 2026
 13:54:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zQ11vnaen8GxyLGB5rPZxcD3nqBNiHt9eG/R62XSpqSDBSHFph3znZuzaYZX4X+9znkCrvDpy3JSZIJvCuWNaTHg1DudsHXM3KPTyTB1id3pVsAW6WSEjCQ4NF3LuNCN0gCMk5U/KIXw8dX0cg1KE7EmgVYcwyyrYySkgXepdrLw8equ2UwaosQhOE9AtfAnSjxypua2pn+okES7ok0cRwZSz+tt/0wq1jVQb9gTFRryZqHFON7X+EI6YlmckIjtJgctsqY/XoBPtzSkO1bvsDi0r6bG2JlPyV/1uyD7WN6a9lSX656/tK2nkWr6FxDt2uN1dKDC+4VXWUXLQ9fSkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k0JfVm/dOYCTKg2ATdxxuHJlejduKIiRsz2PKD+ycuE=;
 b=IY7AjNZU5e2IWZThrZjBrJcYwia9YDIlRCh9yQ4KMZZwaUMayQxcXgZ5mHaEmSVDE70+Un6WasDlQ/tbhblzUpHguVSfvYmGfwA7tN66L4SfCpLpfgDUgqueZXevLbSnt/ZN5R9ZDarq5afTJxmLhGHsN0xMOeQAtHOulj98p1htclaJ++OFzYADBglso7zjheHlURAiADOQQgrNA8ngU5nto/BDx9hG/1WGt7N5N7Gy/3Iii34LkimTxV6RvznpgpWBjG6an5r4/33DiO3xxudtoCNflJWw/JW2E2xm6mIeG8/AcdtZPa8siZ9KC7SNRHuHSJuvO9K1QRi+VZgSSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k0JfVm/dOYCTKg2ATdxxuHJlejduKIiRsz2PKD+ycuE=;
 b=0eFDOuddafMykt2IHQjsUH9d8jzmikzP3G0Rbso0wQZboRJsNgX8yD0icyT+dGkzY3pX7H6Pi66j3Xv2jQCk48nzacijdWB8WYSyPTkKzKv1dDhoVMt/sVFof+RnZwE/Xx6qBK4DiFGz/Ct3yRjBXkjv62TDFAHUQZiCUnVqI/w=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <9a3d991c-9b14-4614-8010-e2e03aabcc14@citrix.com>
Date: Tue, 11 Aug 2026 14:54:24 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Juergen Gross <jgross@suse.com>, Andrii Sultanov
 <andriy.sultanov@vates.tech>,
 Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v3 4/6] xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from
 the ABI
To: Julian Vetter <julian.vetter@vates.tech>, xen-devel@lists.xenproject.org
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211105.8631fc262581453bbf619ec5b2062170.19f6b44e7b5000edb5@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1784211105.8631fc262581453bbf619ec5b2062170.19f6b44e7b5000edb5@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0013.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:150::18) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW4PR03MB6946:EE_
X-MS-Office365-Filtering-Correlation-Id: 25593791-7bfb-4a2c-b879-08def7b0109a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|366016|6133799003|56012099006|5023799004|4143699003|11063799006|10067099003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	123vpdbtqxe7ykzKhCH71k6BzwCTihkyLYBpuvKXID0wNRtW+bEzsBmgY6clswoFtE+3Ow6Ll9Vz06AfX1jmyLESmBKwowK+XIt4do3CtKuRlBojCFOat/VFRdWGt1FA1XtUEZeHLshPVMeQxkbcCCvNWKX+tgX73UYtUGg4vjDlOORN4QEXKuYNpbqc2ObGgJGOPRwCkLvouZ7y1AdH7YrZCx7ke1o03+YSbg4QRwJsRcc+IBXsj+rekRw17da480J6pAZsj3gwVz++b//GFEGJRrkeHBvyNR1E2GR/+l3GV4U2YN/vRYzwfKERDFJ6mN9kqtI1QcNMSI6s+IOp3c3XoNY7h0fWeP+hofHEUOL55wt6iWcxOnl1FgYzy4mzvAerwn/xUTgjLdWraUgZ6/eUn0ZdzuafXKqXVsKE878J6zKxJbN+/j9swfxixNV471xTdVRTQ/UJSb5Mt3hvvaR9EqcNrtrg4lDKXPp/twnI5D81r0vf+keyW0wbmdPfNnjdilsEab2CF6+2noh0x6hNmqrDkcF7B0rG013P/IC6pKU5nIfPBqE+TkiK8OUnaTdpWvVpCMhKBD+bbCDJxqA7BD69e3mul+5U/drNWsM=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(1800799024)(366016)(6133799003)(56012099006)(5023799004)(4143699003)(11063799006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VWlwSTErc2dYK0poU0RRUXFYSGlSdHJFWDdacjI1Q3pqdDFnMGMxOGNvRDRM?=
 =?utf-8?B?TklxVXVXTzlkdEZ4cTRRT0ovVFM3T0FKSERNMFVQZTlKMzZjemVUbDVXM2tx?=
 =?utf-8?B?WWFJMUJSYU5zUU5zbHFMdVNtcnE3eERmUWF5cUMyWDQveUM3aFpZZVU3Q0hw?=
 =?utf-8?B?NExhZmpNZzUxK214NWVjWDNIYXdFaEQ3RjZjeGRRWXpvNkt4NEtwVnZlb2xt?=
 =?utf-8?B?b3BCYXF2eURqTnA4d0NSSnMvc0pwKzZMZDRjakhFb3RLT2FtQzNGakhPcFU5?=
 =?utf-8?B?MkZ0NEJtVUg4VmlKdEJCNFZYSmpEaG1kaW55SDU2MnF3YkpQS0VadFFZeVgw?=
 =?utf-8?B?MWZxejFrR0k0MjA3UkZLeGpBSkladXdDalNvWVNnbmovN2ZPUFloUUlZazNV?=
 =?utf-8?B?Um5MVW9JUFpkK21pVTkyNnlkTGJmNlNWN1ZrTXRsdWY3U0NwcmVocFA5Qit5?=
 =?utf-8?B?RWZVTWJnZHlZUXhnbUkvYVJWTUU2Q3pEVTBhNVRIenYyQlRZMjdsZG5nR1lN?=
 =?utf-8?B?RnRiWWdCa1RHdnhqNHZzSUJZY2tDMVQxVXNKVzk0a1dsSWpWNFpGYzhkUnc4?=
 =?utf-8?B?aTZzTGdjQ1NnYXFPU0J5ZmxFcSthMWxuYWJnY2dnOUxYQUJVOHQrU05yQjNy?=
 =?utf-8?B?d1k0eU1XVVUxdkVtVXFEeSszdDlQVXFYWkpoL2ZVODFBY0tmMGRoN2RSL2Z1?=
 =?utf-8?B?RTBnb0h0cFZVQ3BjZ0FZNTRIbTlpRWNmeEpucGFkQmxYdkY3Q3VpemwrdGFI?=
 =?utf-8?B?SEY4cCtrVmwwVnJ2OVZ5QTRWb2VkUGphR1o1TWFQZ0Y4UlhyUlNZTGlDT2xD?=
 =?utf-8?B?dWlUVURFTEh4dXBrcjU4UGVVRERxRHQraUtwa0VqWlFnUEsvMEd4UDNrazVj?=
 =?utf-8?B?SzdPMlR6OEdoUmVEVU9IaGhmZThESUw1eHV1N1I5c2Q4WlB5eXM0bUp3cE9X?=
 =?utf-8?B?SitJc295cDhQWW8rN0VvTmRjdnRBTzU5M3NVZW5Pekp4NDFxVkoySDZVL0FT?=
 =?utf-8?B?NXpGQ1g5WVVKR2hPbHNWcm0zOTZPbDJmQm5sdjVqKzFtTHhMaUcxZm9Gd2Jw?=
 =?utf-8?B?cElnTlNOc2dOU09UTnd2TlB1dUhvbFdhdFNRTm1oUzJzTVlPendwTjhaY1FE?=
 =?utf-8?B?dWxlZUczd0o3dHBuWENHR0tYU2ZwOFIvY3hZaDdmcnBwaDRzaWtrTzJqUENF?=
 =?utf-8?B?TEVRc0N5S0NFellZRW95aitRRVpySS9KM0hvVjhoanp3ajIrZkZVZW82a05y?=
 =?utf-8?B?TldySVdWZnpaU28yck1ScHhkSlJtOXBKZXVuWDcyWVpzbUswMGt5dTRzRmMw?=
 =?utf-8?B?WXM1dGF1TjJ1L0VYNGxNbmRmSFYvaHhvRHJIU1dOU0RrczZNY2VHZ3JuSTdr?=
 =?utf-8?B?VUJJOVBxVTEvWU5yVndwOGgyeDNvakZCMy96THdTbmhEVXFoaE9oUm9pMlpv?=
 =?utf-8?B?THBKMnppcU1UVlMwYUhkK2NSTWZ4dE92ZmVRRXZWUklGclJwSlMzS2JqNjRz?=
 =?utf-8?B?R2poTmhTQVVOejM4SmFkcDd1cVFSZGZZUVVyV0tzMnRLVXo3QlJyUkIzYzNy?=
 =?utf-8?B?UnlieEpWTS84TGZqSjBNOTgxRDhqNXFpdU9RZkl3SVJ6L1Y1VlhOM3hBWitl?=
 =?utf-8?B?N0FCSUVvY2JJa2RYY2t5WWZ4c2MrK3pCV0JvcUs3dlQxZXNLemx4Yzc5T1cx?=
 =?utf-8?B?VmJUdlMrcmdOZ2FhVE1Cb2ViZEUvbHI3RWNPWjBCV3lGZEQ4eVh3NVppVy85?=
 =?utf-8?B?Q3NoR0FjMXJ5M2hrYnlrWlJmRFhJWUdwVnJCRXZGb3VzY25vUlBmZlZ2UUUy?=
 =?utf-8?B?UTNldVZNN3Mzc1NKVGFaazRIRGtpMVRpTE1OL1oxQzc1YS9WY1pobXd3b1Rw?=
 =?utf-8?B?SEo5cGgwOVBVZGtvbjBZY3JzTnBsSkt2MU5MTnRYRTIyL291dDN4OENkMWM0?=
 =?utf-8?B?QXFQeWlBcjB4YWpTYWlzTmtIM0ZGTDh5dzJ3byszT21reUxLTnZLR1U1ZzBR?=
 =?utf-8?B?VWNISHJkU1EzaE92ZUlUZ1ZWeWVINW14RUpBU3JPdnZyRzVZTFo2eUtzTWV3?=
 =?utf-8?B?NE1qRk9CdXozVGtSOHhVZkhEK3BzOTV6QW1OandJTGtZcDI1MHJ5cWd1VlN2?=
 =?utf-8?B?MGJ1VkVwZC9WNDZMaTdLMmQwL0ZCNVNreHR1YktpTy85OWRjWDE0Tnp1WkZW?=
 =?utf-8?B?b1ppaG1uOUtscnlRaGIxV2g5NWlmR2YxRUk4dzE4aDhaOXRBRkpBY2s2ZU1C?=
 =?utf-8?B?OFpxc1VaRExlMXBrRjkzQitBMlB3NjZBNmFUdmFTT21nNFBNUTNONFNUTlI0?=
 =?utf-8?B?bVpDY2ViVnlaYjQxUUZlcGVPMmJjZWRaMVpiYmpRMWFDMkcyTWprZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25593791-7bfb-4a2c-b879-08def7b0109a
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:54:30.8472
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: URj2g2in0RX15UaF7QxOoVT/4IGCYiPVGZ9xLWL7j4lK7qkYEjb3QV3FaJ6PEOFEf+WPsiZDEGzIQ9hn3wAy369072wgKDujIYVtvefDYG4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6946
X-purgate-ID: tlsNG-720697/1786456476-F30B02AC-3D9A5D78/0/0
X-purgate-type: clean
X-purgate-size: 4762

On 16/07/2026 3:11 pm, Julian Vetter wrote:
> Now that the toolstack always resolves a concrete GIC_V2 or GIC_V3
> before calling createdomain, nothing on the Xen side needs to resolve
> GIC_NATIVE either:
>
>  * A new gic_domctl_version() helper returns the XEN_DOMCTL_CONFIG_GIC_*
>    value matching the host's gic_hw_version().
>  * arch_sanitise_domain_config() uses it to validate that the requested
>    version is compatible with the hardware, rather than resolving
>    GIC_NATIVE and writing the result back into config->arch.gic_version.
>    There's currently no support to run a guest on a GIC version other
>    than the host's, so this is just an equality check.
>  * create_dom0() and arch_parse_dom0less_node(), which both always want
>    a vGIC that exactly matches the hardware, use the same helper instead
>    of GIC_NATIVE.
>
> With nothing left resolving or relying on it, drop
> XEN_DOMCTL_CONFIG_GIC_NATIVE from the public ABI. Every caller must now
> request a concrete GIC_V2 or GIC_V3.
>
> This is an incompatible change for any toolstack still passing 0
> (formerly GIC_NATIVE) expecting Xen to auto-select a version, so bump
> XEN_DOMCTL_INTERFACE_VERSION and add a CHANGELOG.md entry.

This is an API change, not an ABI change, so you can leave the
XEN_DOMCTL_INTERFACE_VERSION alone.

>
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v3:
> - Second half of previous patch 3, with only the changes to Xen
> ---
>  CHANGELOG.md                   |  3 +++
>  xen/arch/arm/dom0less-build.c  |  3 ++-
>  xen/arch/arm/domain.c          | 25 +++++++++----------------
>  xen/arch/arm/domain_build.c    |  3 ++-
>  xen/arch/arm/gic.c             | 16 ++++++++++++++++
>  xen/arch/arm/include/asm/gic.h |  6 ++++++
>  xen/include/public/arch-arm.h  |  1 -
>  xen/include/public/domctl.h    |  4 ++--
>  8 files changed, 40 insertions(+), 21 deletions(-)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 356be88351..74f02e91db 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -13,6 +13,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>  ### Added
>  
>  ### Removed
> + - On Arm:
> +   - XEN_DOMCTL_CONFIG_GIC_NATIVE has been removed.  Toolstacks must now
> +     explicitly request GIC_V2 or GIC_V3 when creating a domain.

"Available GIC versions can be queried via XEN_SYSCTL_physinfo."

> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index baa3a5d708..b396d5e615 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -609,23 +609,16 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>          return -EINVAL;
>      }
>  
> -    /* Fill in the native GIC version, passed back to the toolstack. */
> -    if ( config->arch.gic_version == XEN_DOMCTL_CONFIG_GIC_NATIVE )
> +    /*
> +     * The toolstack must pick a specific GIC version. Xen doesn't choose on
> +     * its behalf. It only checks the requested version matches what the
> +     * hardware actually has. There's currently no support to run a guest on a
> +     * GIC version other than the host's.

This is path is used by Xen too, so "toolstack" isn't right. 

Really, this only wants to be the final sentence.  Everything else is
trivially clear from the following logic.

> +     */
> +    if ( config->arch.gic_version != gic_domctl_version() )
>      {
> -        switch ( gic_hw_version() )
> -        {
> -        case GIC_V2:
> -            config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> -            break;
> -
> -        case GIC_V3:
> -            config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> -            break;
> -
> -        default:
> -            ASSERT_UNREACHABLE();
> -            return -EINVAL;
> -        }
> +        dprintk(XENLOG_INFO, "Unsupported GIC version\n");

"Unsupported GIC version %d\n"

When complaining that a value is wrong, state what it is.  That's far
more useful than "something went wrong".  In particular, finding 0 in
this error message means that some caller hasn't been updated to avoid
passing NATIVE.

> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 7d6f87e8b2..6987f5bdf4 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -319,7 +319,6 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>   * struct xen_arch_domainconfig's ABI is covered by
>   * XEN_DOMCTL_INTERFACE_VERSION.
>   */
> -#define XEN_DOMCTL_CONFIG_GIC_NATIVE    0

We tend leave bredcrumbs around when removing constants.

/*      XEN_DOMCTL_CONFIG_GIC_NATIVE    1 - removed in Xen 4.23 */

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 14:00:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 14:00:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388259.1629470 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtn1S-0006l8-QV; Tue, 11 Aug 2026 14:00:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388259.1629470; Tue, 11 Aug 2026 14:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtn1S-0006l0-Mg; Tue, 11 Aug 2026 14:00:06 +0000
Received: by outflank-mailman (input) for mailman id 1388259;
 Tue, 11 Aug 2026 14:00:05 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wtn1R-0006Q7-3U
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 14:00:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtn1Q-003DyQ-0j
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:00:04 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b2ada-bab6-0a2a0a5309dd-0a2a4504eaec-26
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:00:03 +0200
Received: from [40.107.208.23]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7b2ae1-b57f-0a2a45040019-286bd0174e36-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:00:03 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DS0PR03MB8197.namprd03.prod.outlook.com (2603:10b6:8:28e::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 11 Aug
 2026 13:59:59 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0292.024; Tue, 11 Aug 2026
 13:59:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TYZvjBROyI+wII/17UrH9QnzVpyqctauJXG+dvj+CRLM4T4oSOFpc9w+MlMeweylgQGpOlRrXsOY2w+/S87p0TjlL+D+f0g8FSiL0yjlC9MQDlX8Q/fnoV6Ip/d0/mfmlUT19jSNrh2stjOH0sCRiglwe/wuzkRyMhOv+LmX4dAlcSkr3X3fJDSJm5gVDdI5uzy1wJ6g+6btj/tf9alS7O0sPgzHOq66jQSFv8KMae8ykx6zq97A5OtUU+8W/MWvozye8E40/DknmrYKG98sQJeh65bAEYKn0RP12Z5+ZlR3Ja/hql26JJyeaAe37mQixgQWJK30AgdTh4w8PkyCDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n0K66Rlwl8cRN2U2VYrij4lVf/l9gfUC2MKBew1hXig=;
 b=yEi6945I3soIH/ExhEVGu00NmVPuqM8whlK9lrNspuXVAvyH6CuW1E7HBL46ieAmM0nPedF+2+icr/ssJHYowIOmtvsZUZOBxbMmHusRNJe+vGlCb7+UweefIDERnoOfZTT9sVXzDvbzszfz0nUgT6SA25r+7SqBXG9k3mUYE8wYmWKZTqWAGcUd/lyYwTVj6I5bMNHx8DNHTexxK31n1ugnRnJ1YXCWktvFSGr+FckXu5UDKw6BTHlHX6a5C6pJvH345v4mX+/ohKWa3mhSQI88J8H1plEdWsCZkicO61gxpp2pnMJ1pURBn4m7A0cBSUfW5ux5e/KdY8/V/sdY9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n0K66Rlwl8cRN2U2VYrij4lVf/l9gfUC2MKBew1hXig=;
 b=YTKimTGGR9HCkMrPfdy08UuVFMEmFeqFECa+B70Lq6rEh5Mwdy8S9wbdbYQpA0MDM7UH/V4B/TPfTcKV74x1cULmJifmLnJBRQxPpYtperbAEKW2cOGFWANH9qVLc6R7bk0aWQmcbGub2354tnAjwArYVCGicYHUWJAGkyjRySo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <5e314dea-42df-4a5e-b855-f5735760ee66@citrix.com>
Date: Tue, 11 Aug 2026 14:59:50 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Juergen Gross <jgross@suse.com>, Andrii Sultanov
 <andriy.sultanov@vates.tech>,
 Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v3 6/6] xen: make config argument const
To: Julian Vetter <julian.vetter@vates.tech>, xen-devel@lists.xenproject.org
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211106.8631fc262581453bbf619ec5b2062170.19f6b44eb46000edb5@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1784211106.8631fc262581453bbf619ec5b2062170.19f6b44eb46000edb5@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO3P265CA0025.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:387::6) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB8197:EE_
X-MS-Office365-Filtering-Correlation-Id: d034012d-d04d-4910-94b8-08def7b0d3cb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|56012099006|4143699003|11063799006|6133799003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	8bdjZS87W5WBMZOGBGlCvg1eLt3xz1iAJNW6IwCYsUone5O6oHcOP/oh3n9rx3vFcddv/zSZ4nS+u9Tif5Y7yaBoQ5J+kBSswU3Q6H0pB557NjJfCRIQJsragoGtxwey4CBeFL1B1LI7iE/a0pFWTrBgrawdE8oLRsoxTgFsV++8lFLqJDva8nKO0ILEmMOzjuN8tL5PsAqhWs8GsFdBx7vtutz37v7ORrxN24hpEGorVsu3RYneiDPrA8sfq37dJ9/6gW6foRNpvvnUNPU/371MgF+BZy5K70rSUy5f5IJ0ve+eJfxPPEUxaDx0A7NYhkuMJOrV7YSrSH8lHW6flUzw2qvZQwHqgZrX02XajMCtqnuIvfq8BagIy0PqZh5Bctds8HQp4b113BopUNSC9HwW8kZj3BZEpjuV4HFMV2np+LPDzqrFGO9iGLTCjD4XwWG+9dwKBMiPWFTf15slYTpw8YLKwXmsxLuYqrrDx2okIddTcVhxTiKKgsFtJytcCVVrYzE5sfx227l+hmX3m7SICNu05uZFdhlJ1t4oNHPO12J7e48OWitKHU/edXyI95ZW+z5TPF945ankeMPcOPkQP1xgQvFTNX8+JAwrPaYwyf/4zn8BslfjQq3HZLwSMEezLmtGHBd6XlAHdRU+39Gj40lbfNey8Y7nCfCYiHU=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(56012099006)(4143699003)(11063799006)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?bVQ4YjRnQVAydzBERVgrbXBxSS85a1BJNTdwS2xtQWxHcnRoOUNyK3R6WjFG?=
 =?utf-8?B?RG5QL0xHUWFuYi9kZ3U4OStFWkJud1lNWWpKVGNPQzN4Nk9BYkc3S2cxQVBM?=
 =?utf-8?B?RGMzSDNDQnNIb1ZlbVk0Rzd6b29DdUZySXYvdjZHU210Y0I4eE1wUjlFbTl4?=
 =?utf-8?B?aGNQTEg0TDhmeVJXeGZJMy9aNTQ0YlVGeGtjb0Y3ODRJcDc2VkhyM1FncTR6?=
 =?utf-8?B?azhlLzRsdmlQbkVXMi9NSHgvOUNoYndVcnBuN0VQcjhWV3NiT0JyQjBkMTU1?=
 =?utf-8?B?MmtpR0N2eVgzTWN2MGNUbzkrVjhQSktkTzFwNG1vTzRkOWk2RnYxRmphRHJo?=
 =?utf-8?B?M1JaYW9XYWFwdVZpdkJDMnQ3Q0JtcGVQT3c1TFdnS3NMMWhOUXp4bUkzWSsz?=
 =?utf-8?B?Y3lweFBJeEl0NnA1WkdzMm1SNm9JNGNGWFJKczBlRytCaU1Ha2hCZ1pjZTJv?=
 =?utf-8?B?dDYzWFFWNFVMcEoxaFh1YjhYMjB3UDMyUmVDcWFPWTdpKzhkYy9YenVHa2Q5?=
 =?utf-8?B?RHh4TzN1VHY0RHNrYXZCN2Y0ekV1UkJBTk1ackpJUjlXREJoN1AvQUxMbjFE?=
 =?utf-8?B?dml2MzhGM0ZOZUZ5SStWcnZhT1VTVUtINUFlNWJTY2hudnREb01ydG5OMFdP?=
 =?utf-8?B?WU12L2xSM040VzdrbVhmRFVIQnFCbTVINjFaYVFpdVJvOXdLa3F3NmhlVjA3?=
 =?utf-8?B?UDlnMkVYbDB3VHNvVDRMS0M3OFhrS0N3dWs3YXZlemIxbGJ1SnRjY2FTelZF?=
 =?utf-8?B?SGM3QjYyRDBwbkt6eFI4NFQ3c2gvdXJpMk5OUHd1bll2eU5Ybi9tS0g2TmVn?=
 =?utf-8?B?N2xtZldKOFpkcEZTaGtMRkhaVmNxU3ZrUmZYK3VFeVpXTDhuL09tZnhQYjF0?=
 =?utf-8?B?UWs5Sis3R2c5eGNqRyt4TGFiSjhLWDNQeG14NEpjVDVJS2t3ZTV1MitFN0FH?=
 =?utf-8?B?OFdQVFJKMGRhTTZtOGhvdXQyKzErVDBDUmJUUnUzSFNWVE9hZFNMWmd1U3pS?=
 =?utf-8?B?dVRDMGtFUmNvSkJGbXVBSklWQWFnSkRwdFVzbFpzcTZtck5GVkRhRUJxRWdv?=
 =?utf-8?B?TVdqWjRhMFB1OGFOUGY5MmszRFpyUi9CcTJZUXAvWkNheEdGcWE1L3cyMi9p?=
 =?utf-8?B?MHRuYjhzV0FmTGhQOGJNd2pMS1VWN0Erd01lbnJpb2dNTjdoYWJVT1RnVVFn?=
 =?utf-8?B?dXJ6em15SDFPamdJRURoL29XTEYrVU1HOVRvNXdVZy9SdXJEclpDUFdoenJl?=
 =?utf-8?B?YkJ5R3hxRXFuN01IUlRQTkJjK0ZLcndOdDYwRjVKZE9wYmg1a3hoWjMwUmlJ?=
 =?utf-8?B?TUNlQlp6ZnFVY0hEdW1EU0hndko0c2c3QlNOL0Q4emNSMzJPNU5vUlhoMUlQ?=
 =?utf-8?B?T0Rlam40UHhlbWI2T0tvWmdLUXlhMTZab0sxeFNiZmlzSVdwaHNKOCtqQlBh?=
 =?utf-8?B?Sks2VFQ0MFJ4cFUrYXNnSXdodnJLc2hicWZSM1JNRXZ4ZDJkMlcyNk1OSmt1?=
 =?utf-8?B?Q0JmQmRFdU4wQXR1VUNGTUpRdWFGMFVDZENTcS9SY0o0K25vTmVDUEFPclgw?=
 =?utf-8?B?SXY4alV3SDFud1NER0NPTHRPSXcwTWdvQThUdUxNQTEwbHlqdWY0TWppY2po?=
 =?utf-8?B?STF5R1MyS0dmbFFkR1V3TGloU2JtSTdBU2NrR2E1bytOdnJyTDVwYTNnQUV3?=
 =?utf-8?B?OW80Y3crQXBQVzlmTmU5TFNXLytIblJPT1YyRWd2YTVlNzM5Q0N6R2l5Z1lu?=
 =?utf-8?B?cmRFZEl1L0NGWUJMb2xkQzQ1T2ljTUR0NWFWOTVQSm1hRHFXTU0yWVdrclZI?=
 =?utf-8?B?WXZEaVdRelo5eVQ3VzhqU0VKU1ptaU5WWkxFV3ovY1NkRzFsSjdwejFncDZE?=
 =?utf-8?B?SHIwV2NRbGpNRGRkdUU5NzdFRTN4QkpXc3FBa2hjd2xkZUxLUWMydW5vWDFs?=
 =?utf-8?B?SjE1Y2RzOTBPdDluVWlHbUdlZGV0REtwV0dqRGVKdHR6QWxQUmI3NnN2U2lM?=
 =?utf-8?B?NXpHWW5CczAxMy9GYTlnZVJSZjJwWE1oekovK25ma21QcWtDeTFBclJIbmlt?=
 =?utf-8?B?M1ZBd3h2ZzB3K3dJVHArdEE0WUtZWnozV2tPc3h4c0tMMVpmWDE4MnFjbHNh?=
 =?utf-8?B?R1dzck5ndmplNkkzQno0SmRtMVBRSzMzWHZ5MTNCeGRjZ2h6d25sdDNOdk9m?=
 =?utf-8?B?T2diRlZoSGVWb2pVZEc1b3JZY1B4QTAxaGEwdDhrQ2xocm5sMCtQTDVJRVcw?=
 =?utf-8?B?RkN4ZS9UNDExUXB3U081N0paK0hLblBVdVhjS3dhZ0JmSUZjUmtmcnpXcmE2?=
 =?utf-8?B?UFBET05iYTBqeXYwWmpMZTk5bUk2THk5SlpZdktKSnR1SHFTT0NwZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d034012d-d04d-4910-94b8-08def7b0d3cb
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 13:59:58.0736
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uX5YRARdr9daLfABKDZZGZukgg2hy1ub/o8TnUDj3C4fDfaJJOk263QUOuk4a0a/STKE79xtB3buQWZ+zineQ9J74XiFn/oHtV4kREaalPY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8197
X-purgate-ID: tlsNG-ebf023/1786456803-C0AD8B50-D4C55635/0/0
X-purgate-type: clean
X-purgate-size: 992

On 16/07/2026 3:11 pm, Julian Vetter wrote:
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 011292e9f7..66ed7454ba 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -756,9 +756,11 @@ static inline void domain_update_node_affinity(struct domain *d)
>  
>  /*
>   * To be implemented by each architecture, sanity checking the configuration
> - * and filling in any appropriate defaults.
> + * requested by the toolstack. config is not modified: createdomain is
> + * input-only, and the toolstack is expected to have already resolved any
> + * defaults.
>   */

Again, "toostack" is wrong to say here.  I'd suggest finishing the
sentence at "the configuration."

~Andrew

> -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config);
> +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *config);
>  
>  /*
>   * Create a domain: the configuration is only necessary for real domain



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 14:10:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 14:10:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388269.1629478 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnAw-0007sz-LY; Tue, 11 Aug 2026 14:09:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388269.1629478; Tue, 11 Aug 2026 14:09:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnAw-0007ss-IT; Tue, 11 Aug 2026 14:09:54 +0000
Received: by outflank-mailman (input) for mailman id 1388269;
 Tue, 11 Aug 2026 14:09:52 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wtnAu-0007sm-Ax
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 14:09:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtnAt-00BM05-GM
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:09:51 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7b2d15-2eae-0a2a0a5409dd-0a2a45048a64-48
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:09:50 +0200
Received: from [52.101.70.22]
 (helo=AS8PR04CU009.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7b2d2d-b57f-0a2a45040019-346546164084-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:09:50 +0200
Received: from AS9PR05CA0242.eurprd05.prod.outlook.com (2603:10a6:20b:493::26)
 by AS2PR08MB9713.eurprd08.prod.outlook.com (2603:10a6:20b:607::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 14:09:45 +0000
Received: from AMS1EPF00000094.eurprd05.prod.outlook.com
 (2603:10a6:20b:493:cafe::41) by AS9PR05CA0242.outlook.office365.com
 (2603:10a6:20b:493::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.26 via Frontend Transport; Tue,
 11 Aug 2026 14:09:45 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AMS1EPF00000094.mail.protection.outlook.com (10.167.242.91) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 14:09:44 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16)
 by DB9PR08MB9730.eurprd08.prod.outlook.com (2603:10a6:10:462::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 14:09:11 +0000
Received: from VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com
 ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0315.008; Tue, 11 Aug 2026
 14:09:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=xcDPG0hVFOk0AUBj4C159DlzoaguQZmjigOLV2wlFCc1pdTt01jMQKGY/63LO/jOC85zG8fc5G4S/C6LkqRvQq8cGDjsCAp4G0jAx5M6heW70DQpUJHjiGaHTKnlqex+aOAtpgfSFkhVomSobgG26G6LQsP/rlLSbbT9biSftIQAxcHrOrhpc/0mz0VQw2WcUOSxlc7+nk02Fmg58AXbzUzfJrDdq58Wms8TkhdGIF914fbh+45YDgmPICpe3rEcmG8FNY3lmrlAVnxH+OvFs7B5Hh9XDmAxy7tKUofargAwaRLAuSv6YqFDrLtEJYGZ8P+hC53w/NpVCRzM9KBrRA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=spajHA6ointRyLw86RivlHQVOLc0loAJEJ1TlU4g/dk=;
 b=g44y70zFwMxf1rENbj2VFHwbaRyRQgZzGayNR9x0/8MrFLFhqCzljt7pZsMD14Mjeoa2oQINEuzzHsUleIeFCipLAFcZZipBxMdPXY8RPqw+AEb9AiUeIQRyTI3n0Z0036JBosn0LDw/M4rlkL4dFiRVhD7ioWXRsIwQYR5qraJe5t4h49ArxxFG1BIvRemUHWrQBPcUDcd7mf8bDwzF1TTDxCo6+MssXldmesRH7X/ERmExRfyQywBYtlefGWdousS3j0NG7cUg2zL/ozv12GzgfvtaDWsfIlMMLX7AsX1VHSM6P6EnHRFJZiFzUrSylcGJcmY98ej2nd68mQrJMA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=linux.intel.com smtp.mailfrom=arm.com;
 dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com;
 dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=spajHA6ointRyLw86RivlHQVOLc0loAJEJ1TlU4g/dk=;
 b=Of2zMK4AYCmnRWDmgZxXsjcqJPO31mxBQjUoXGVjTGfhVwp3SdIVVi7agOghu8iMGsMktBYOl3wqspqIPSdjK9UxF2eBDJ6bk6sX1c3OJggt0NuQA/Et5PtcevurQjrhzd+EKtrJjoGYBF7cOXsfD+VKGP1nFjdL2BwS8rzk/ik=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HAp0D8fED4BIknp3JzrYjuhx/SQCyUUgLhlHQqssIAq2N6Zbn1so7sXZlziVHIj7d6R6PvF8Ffjtzn5GtAwxsJVYpCiC48lY1FRKuvfiZSsIjOzx5m0rzsNPepoiaPYMUz1G50y3QAq/T9sRgB7BwN9w9N/5R6Z/dvPN6jj2BvCi5es97DYocaURGfL86kcHhZ1Slwc/nSlmXR/BKN/XnrkkkH8IwV9gNY0TdJ1pp7/fHWC6RH/vdaAWVJV5U07z0j2Ijxbtr1LpePU5MZb1DHhnujJir1mlbvttFdbM6COV0mAusxSw6xvcW/kyWYKjFzABD7KH14UKtT0642548w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=spajHA6ointRyLw86RivlHQVOLc0loAJEJ1TlU4g/dk=;
 b=iaBjCOaVhCrKf98DWl2iS/e0DsC7e2a2L3DMyqusEaofhJIZiVQsRraj6DPlUHWjukjnzf+AoDBXBd5Ox9PjTzzPv3+rGqnof+EKhq///cIsuJpOOu7gm5tcXvQs8wLkXbmtqZ/yG17mPwjxEksDitQGwZ3BuZrdYfyLesQWzPqWPhK7kueTmeaMsz7EK+6sUZMOSPcFkkNDWrBv25fa0YsWNMPqFyhGOArj1uD+rr+3ELIXOhc57Dz1C3xjDevg7ocWAmwbS63Ihia7vPkPc9ak4loMKc52jcciVQPoAiesWVhjMqiBGkrR2ZU76WKZ5dv12pZ7rzg4OvzuMYZSAQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=spajHA6ointRyLw86RivlHQVOLc0loAJEJ1TlU4g/dk=;
 b=Of2zMK4AYCmnRWDmgZxXsjcqJPO31mxBQjUoXGVjTGfhVwp3SdIVVi7agOghu8iMGsMktBYOl3wqspqIPSdjK9UxF2eBDJ6bk6sX1c3OJggt0NuQA/Et5PtcevurQjrhzd+EKtrJjoGYBF7cOXsfD+VKGP1nFjdL2BwS8rzk/ik=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <b21c4cc9-84a3-429e-8156-0b9967b2f133@arm.com>
Date: Tue, 11 Aug 2026 15:09:07 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com,
 ryan.roberts@arm.com, linux-kernel@vger.kernel.org,
 intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
 linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
 linux-arch@vger.kernel.org, kasan-dev@googlegroups.com,
 linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
 linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 3/9] mm: name pointers to copied PTE values ptentp
To: Anshuman Khandual <anshuman.khandual@arm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-4-usama.anjum@arm.com>
 <e7osakog3yvdewhdlrk3bsp27pwt2nnhroeb7zihlfxyjotarb@rwxkcb25crh3>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <e7osakog3yvdewhdlrk3bsp27pwt2nnhroeb7zihlfxyjotarb@rwxkcb25crh3>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0197.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a4::22) To VI1PR08MB3421.eurprd08.prod.outlook.com
 (2603:10a6:803:80::16)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	VI1PR08MB3421:EE_|DB9PR08MB9730:EE_|AMS1EPF00000094:EE_|AS2PR08MB9713:EE_
X-MS-Office365-Filtering-Correlation-Id: fff88c87-ef4e-46f1-d491-08def7b231fd
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|366016|23010399003|376014|7416014|1800799024|6133799003|10067099003|4143699003|56012099006|5023799004|11063799006|18002099003|22082099003|3023799007;
X-Microsoft-Antispam-Message-Info-Original:
 X8qvVO1tGgOGc68Tj8e6uYIlEm61fj7Yc+rR2Ay/UJ31hxb3PHm/Vx9ayVx7BXhFCE26lvSj1FVRwdkt9qTwDUf03EfjHj5zTGh3lNmthZUPU0QqKoBPqNCZMmlIdwvntC0ETgEazcLBhiggaaU1oTVhVrF4zZNB+8zbzV+Jd4wX3kEhklK/JQF5PBzEsMQlnX/RA2nh2JKyOqzVqPIP0JRjHOvrNtwouMyn4EApYlEz54M5OIY1sJGVL2DhxYD3bw4zw1/+YIsp0Em0CEamCCEu6TYlPIaaPzdzbep4Q20xFGwIz/vtY0BuDXxxwaquypHlTctA+f8g9C3qAfi604tm9S5lbClK6rgQWc2C7gtm+k/RpQITOlu/8ySU8jRAuLryQLIaU07iwsnyadRcNDbGozKdXF53Sl5vfnr69T1lGLspteufAc2KPwXQegTPnGNpBa3XqVK3I0rj6mCz2fhoS5cgar40oNGDel28oFjLSHmTqLzlgfCXDa/SdbvfGw6kYd7pbX0X6Er0Yoa1pmDs1KkhBG+od3Lm2kLHvxMgPWvVu6+OGVUF/muODby0JcN0Z5kv6Rm9XFuwS+rujtHHfFG+S8WUrGIQGqc1z/gh7bAy38Lj79K19jGGQknUUaoEdzVxQEjI8Btl4hXMy1IFAn4QlZDRT18lnMFWkRU=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(7416014)(1800799024)(6133799003)(10067099003)(4143699003)(56012099006)(5023799004)(11063799006)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 PoID+C9pr8SsNiZRZqrmEF20E8+VyYQrbmNS/atK0zw4H6xYhN8JDWaNyZcuAbKvDXx3md+N466b0729ETpNiHwGFoQQWHtr1wStuHk00WaD7R8uPTqjp9Pek556gM35mQe8FX1aL7Sp2zO09cPHEXYxt6UjkF20b/IyX2c8fU9p9FtV22m3Uikksqe9i+Rbf7inmIUq5CxSfVO/lt6nTQ/RZeCwOhVPzS6fqYMTUAmCwPYjztBlT9Knlw8LjChFicyl5+dVAtGMoyOikQxEQPeOpO5qwUVElOLqNbWdabbXkDPmBevoai7DCbgoVW7V/xraDV24EN08DFdilYcMzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB9730
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF00000094.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	685e73f2-e898-46f2-3da0-08def7b21dbb
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|82310400026|14060799003|36860700016|35042699022|22082099003|18002099003|3023799007|56012099006|10067099003|4143699003|11063799006|6133799003|5023799004;
X-Microsoft-Antispam-Message-Info:
	QrDAuJ2AlDAgvei/zvkJkvfQWUZGGIE48wAeeS/YiIuKQGmvUJdnpoOGxcyZyGvL5v9YQDS11/dPPsMg2cg1TdIBKj/ZPGWerzgyXqYtwORlNDmgfnW1ufsTE6Dd8rVH5Y60KHRVB7gdGtwPo0QRPYxa+19gn2F9ZYAc7vEaMH7O/lMCMTdnVAeZpH3cffXgRvh0z4psptR+jLz5AOW2p95Mp7oEkWASyLHtxgupDKTGEedMTMvp//INjXGo2cWcA/e6GrBUxPqcX5kfCHlTW7LZJVVh7KoMepIb3kvntg0sZB7NL70Gfcia3025jrIEKnF4KqGPNa7L4Wq1HuGXv0mXVwxgNaXb4NK6wEqF20/zC2xOQ03ZEDkzIaO5E8EtDOmMHI3BTAJp19EjbxOnpsbjpZwiRMVYN8hTGfn+phsV7aF1B5A1fxxKzIWNT7TcyDZDNbDBy1fbQToFO5F+i4z/RQolLUS3Wn0ibbXuZ+MygZXiKYKpg6hE3qAiTq+5zd0g/bBOWtNab9jVgdTUMONzw2ZxDG0EgMOHwF0DiCsTueED+SeHwVgZU+GzrMz87g33N5tKbau+TbAQn2QXPF9MxQ6cHwA8s4U9bUxPnpTjQgHdHKTvFvU5aY7Ow1Ob1uTCPhu5ZMh43XcVPfVFoDWZh3bLL6721rPAVQi4Q0ZLIBz69rhhyWPreQ7jy1l9vvLbXjiKTroIq0PcnHoNqA==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(23010399003)(82310400026)(14060799003)(36860700016)(35042699022)(22082099003)(18002099003)(3023799007)(56012099006)(10067099003)(4143699003)(11063799006)(6133799003)(5023799004);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	vJDzeRb927ULnuNkJdCXMZlhivSk2C+D0uSOnJ7V3ytepBxLXm9FF/vHnPjZGBO8nF2u/+cRH8iKRjoTl1m5jFnoKyjflZUcWX7Uxbggm+eXM9hAPxwV4hQPwdlt4m0bJeyYkEMZjtJ+HCNEdOf49hoHllcfXObByHwyeCPEQEmfATo3YQAMseQqQ7nJkmgo6XalANWP4f+Hdn6/bPhbPvRs6gKRx7T3WlexdzGR2IR9A1t+EG24dcOLQcX1a9QiijX+f/ItEgCVcLa2WlN9xjjcH98InlLSbUc2rfQziuUojQeyl1c6FmjcOBGg5upE1sHsKJ1LCXjFA4h57R19kbwEWTeGr3YiuKif/ZnDswdLKZ+f+keUwx3sdcTyYKRVhOGkpjBK2wm3HgH+r5/JTrWf3YKzp7BzmT/1RjYxYw8ipU3vIF94I+n/8KtOtGbE
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 14:09:44.7531
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fff88c87-ef4e-46f1-d491-08def7b231fd
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS1EPF00000094.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9713
X-purgate-ID: tlsNG-ebf023/1786457390-C28C9B50-8B9D17CD/0/0
X-purgate-type: clean
X-purgate-size: 4613

On 11/08/2026 11:58 am, Anshuman Khandual wrote:
> Subject line is very confusing. Perhaps something like the following.
> 
> mm: Rename pointers to copied PTE values as ptentp
> 
> But even 'copied PTE values' is not very clear as well.

Something like:

mm: rename pointers to logical PTE values as ptentp

or

mm: rename pointers to software PTE values as ptentp

> 
> On Thu, Aug 06, 2026 at 09:38:41AM +0100, Muhammad Usama Anjum wrote:
>> The hw_pte_t conversion must retain pte_t * for pointers to standalone PTE
> 
> We need to explain what is `standalone PTE values` first.
> 
>> values. Name the value parameters ptentp in the install_pte callback,
>> write_protect_page(), and guard_install_set_pte() so the later mechanical
>> conversion can distinguish them from pointers to PTE table storage.
>>
>> Some functions already use the ptentp name, including:
>> - madvise_folio_pte_batch()
>> - folio_pte_batch_flags()
>> No need to convert them.
>>
>> This is a naming-only change.
> 
> Small nit - s/naming-only/rename

I'll fix it.

> 
> The commit message needs rewrite clearly explaining the following details
> 
> - What are standalone PTE values
Logical/software PTE is correct and better name here.

> - How these are different from HW pgtable pointers
> - Change is just a rename for pointers into such 'standalone PTE'
> - These renamed 'ptentp' here would be used for skip or replaced during
>   upcoming mechanical change via a script
> - No functional changes intended
I'll update message in more elaborate way.

> 
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
>> ---
>> Changes since RFC v1:
>> - Update the description for the architecture opt-in conversion.
>> ---
>>  include/linux/pagewalk.h | 2 +-
>>  mm/ksm.c                 | 4 ++--
>>  mm/madvise.c             | 4 ++--
>>  3 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
>> index b41d7265c01bc..c34d826c5e4a2 100644
>> --- a/include/linux/pagewalk.h
>> +++ b/include/linux/pagewalk.h
>> @@ -89,7 +89,7 @@ struct mm_walk_ops {
>>  		       struct mm_walk *walk);
>>  	void (*post_vma)(struct mm_walk *walk);
>>  	int (*install_pte)(unsigned long addr, unsigned long next,
>> -			   pte_t *ptep, struct mm_walk *walk);
>> +			   pte_t *ptentp, struct mm_walk *walk);
>>  	enum page_walk_lock walk_lock;
>>  };
>>  
>> diff --git a/mm/ksm.c b/mm/ksm.c
>> index ad05d7791307e..11d50518d02e9 100644
>> --- a/mm/ksm.c
>> +++ b/mm/ksm.c
>> @@ -1292,7 +1292,7 @@ static u32 calc_checksum(struct page *page)
>>  }
>>  
>>  static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
>> -			      pte_t *orig_pte)
>> +			      pte_t *ptentp)
>>  {
>>  	struct mm_struct *mm = vma->vm_mm;
>>  	DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, 0, 0);
>> @@ -1371,7 +1371,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
>>  
>>  		set_pte_at(mm, pvmw.address, pvmw.pte, entry);
>>  	}
>> -	*orig_pte = entry;
>> +	*ptentp = entry;
>>  	err = 0;
>>  
>>  out_unlock:
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index 07a21ca31bad4..c324cc991f841 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -1101,12 +1101,12 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr,
>>  }
>>  
>>  static int guard_install_set_pte(unsigned long addr, unsigned long next,
>> -				 pte_t *ptep, struct mm_walk *walk)
>> +				 pte_t *ptentp, struct mm_walk *walk)
>>  {
>>  	unsigned long *nr_pages = (unsigned long *)walk->private;
>>  
>>  	/* Simply install a PTE marker, this causes segfault on access. */
>> -	*ptep = make_pte_marker(PTE_MARKER_GUARD);
>> +	*ptentp = make_pte_marker(PTE_MARKER_GUARD);
>>  	(*nr_pages)++;
>>  
>>  	return 0;
>> -- 
>> 2.47.3
>>
> 
> How did we ensure that the above changes are comprehensive and nothing
> else got left in here ?

The order of patches and even the code was found out after adding hw_pte_t
structure. Then everything was converted, until some pte_t pointers were left
which didn't require conversion.

If something is left, we'll get build errors when we build a converted architecture.
So the branch mentioned in the cover letter when built, would produce build errors.
(Those patches would be sent separately, after finalization of this series).

Whenever I'm rebasing (on mm-new), I'm rerunning Coccinelle script to see if new code
has arrived which requires conversion or renaming.

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 14:16:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 14:16:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388278.1629488 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnH6-00016U-Dx; Tue, 11 Aug 2026 14:16:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388278.1629488; Tue, 11 Aug 2026 14:16:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnH6-00016N-9r; Tue, 11 Aug 2026 14:16:16 +0000
Received: by outflank-mailman (input) for mailman id 1388278;
 Tue, 11 Aug 2026 14:16:15 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3qy57agYKCVAAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@flex--seanjc.bounces.google.com>)
 id 1wtnH5-00016H-9v
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 14:16:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtnH3-0048Bi-SL
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:16:13 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3qy57agYKCVAAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@flex--seanjc.bounces.google.com>)
 id 6a7b2ead-e002-0a2a0a5209dd-0a2a4502b0a4-0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:16:13 +0200
Received: from [209.85.215.198] (helo=mail-pg1-f198.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3qy57agYKCVAAws51uy66y3w.u64Fw5-vwDw330ABA.Fw57961wuB.69y@flex--seanjc.bounces.google.com>)
 id 6a7b2eac-6ca4-0a2a45020019-d155d7c6ecfb-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:16:13 +0200
Received: by mail-pg1-f198.google.com with SMTP id
 41be03b00d2f7-cbedb8673ceso286302a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 07:16:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786457772; x=1787062572; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0x2URhZVNyLUMnaCJcyZpjyHlUxRNnCvJLXmuoMKMjI=;
        b=mZf5aOBzHwiaCkZo7PLsa6xBUUgMwtBkmxz/pOw4wGgEJxJe93Y1zgff2SZy3GxpOT
         +MW3C+kJ9k0epU1EDBRzmpueDeW67RlvNYpIdq3OwKq6z1w97x/NWebU/0CTIG3Fco4u
         r0IdbgPF0XRkJM2I/tM3uGopEm32j7yrorccuhS4V5NjWPwYO4H4E9N/Hzodr6dFo6s6
         nIGs1oIXuoa/1IZXe2aWNAKKoyvOs2Lh42pxMkvO7ou5tG/g4QMjK0QrDsICLFY7KnOq
         Av2H3qNIPw0LQXTM3GVigbx7amZgVmPrIeXoHrftgJDxrNJqIsC0R4GVBt7mCQ/NIqHu
         QXUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786457772; x=1787062572;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0x2URhZVNyLUMnaCJcyZpjyHlUxRNnCvJLXmuoMKMjI=;
        b=PhQa5OsrZlym/LgSbb5NSbocYBOXdSTKh8YbLecgHiOykOyA9EnlqIFl8NJ2HNup23
         TMgzazTh6kOv2tP2/XY1ojULAlclIWGEYTaYwQu+R0GwN432yH1ZXUGvX5r6McdLJk4w
         iwK0ipuDEBom+3EIZMvqyILKKcInaYV4rCCBXYG2YLZGaioXdv7paeQQ7BbUX3yiyUyQ
         nWsoLd34HP5sj14Qo/Xp4xxe4Q719w883epc0fOgQQ5PQurSzlM9S1MRMd5f3AyWo+Lt
         BN0QmmADqhXtFuBXJ0cxgzwZFj8Q43ulKd6UEdgIYfGYYvr+LTzFzuGyh9MMLf1imOFL
         fkgw==
X-Forwarded-Encrypted: i=1; AHgh+Roc5U+xcPaaE6xEVxWyYfR1WZ9SooJAPBYku0mADqE2sYVAWn4WKCmivAU7dBvw8X8E8fhg77s+/Q4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwefaRWlJqXx+Of77dBHOb4JLfXYJDl0nl/90N2xBSz5+kuZjEY
	GS+t6qrieZ2/GcQDIOGaTL6yiayegt63aqw6SPN75sP0l9Sc9QRI3HJBoauz5Yoehdh9rxVDG9b
	QxZeLGQ==
X-Received: from pfbkm16.prod.google.com ([2002:a05:6a00:3c50:b0:84a:310d:317a])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:f8b:b0:84e:4d6:78fe
 with SMTP id d2e1a72fcca58-84fa86b672amr4014025b3a.3.1786457771384; Tue, 11
 Aug 2026 07:16:11 -0700 (PDT)
Date: Tue, 11 Aug 2026 07:16:10 -0700
In-Reply-To: <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-18-dwmw2@infradead.org>
 <anoOz2rZ02KFk1l-@google.com> <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
 <ano6-gIZtqMfipiD@google.com> <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
Message-ID: <ansuqrD2KwFuLWbV@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-720697/1786457773-F38BC2AC-BCE1BB86/0/0
X-purgate-type: clean
X-purgate-size: 1726

On Mon, Aug 10, 2026, David Woodhouse wrote:
> On Mon, 2026-08-10 at 13:56 -0700, Sean Christopherson wrote:
> > =C2=A0
> > > > To allow different offsets, KVM would need to track a per-vCPU offs=
et to the
> > > > master clock and apply that in kvm_guest_time_update() (and maybe o=
ther places?).
> > > > Which is doable, but it's not clear to me why we'd want to support =
that (though
> > > > I haven't fully processed the back half ot his series, so it's very=
 possible I'm
> > > > missing something obvious).
> > >=20
> > > Because I want to reduce the number of cases where we have to fall ba=
ck
> > > to non-masterclock mode. Especially the ones which are driven by
> > > *guests* rather than weird choices on the VMM's part.
> >=20
> > But why though?=C2=A0 What is the harm to the host or guest?=C2=A0 E.g.=
 does it make it more
> > difficult to accurately migrate the VM?=C2=A0 I'm not opposed to allowi=
ng master-clock
> > mode with diverging offsets, just trying to understand why it matters.
>=20
> Accurate migration without masterclock is hard, yes. The
> KVM_SET_CLOCK_GUEST thing relies on it (because the principle is that
> you get the *TSC* right, then the KVM clock is just a fixed
> mathematical function of that).
>=20
> That *shouldn't* be difficult with offsets between vCPUs. Just use the
> TSC of vCPU0 as the reference for KVM_SET_CLOCK_GUEST and let the
> others just have their offset from that.

Yeah, my only (quite mild) concern is that we would introduce fragility by =
adding
yet another variable that needs to be accounted for, but AFAICT it's litera=
lly
just the tsc_timestamp in the shared data structure that consumes the per-v=
CPU
offset.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 14:33:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 14:33:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388291.1629497 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnY1-0004IR-M3; Tue, 11 Aug 2026 14:33:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388291.1629497; Tue, 11 Aug 2026 14:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnY1-0004IK-Ip; Tue, 11 Aug 2026 14:33:45 +0000
Received: by outflank-mailman (input) for mailman id 1388291;
 Tue, 11 Aug 2026 14:33:44 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3wzJ7agYKCXAgSObXQUccUZS.QcalSb-RSjSZZWghg.lSbdfcXSQh.cfU@flex--seanjc.bounces.google.com>)
 id 1wtnY0-0004IE-SA
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 14:33:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtnXz-00Ejsx-Ox
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:33:43 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3wzJ7agYKCXAgSObXQUccUZS.QcalSb-RSjSZZWghg.lSbdfcXSQh.cfU@flex--seanjc.bounces.google.com>)
 id 6a7b32b5-e002-0a2a0a5209dd-0a2a4502853a-46
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:33:43 +0200
Received: from [209.85.215.199] (helo=mail-pg1-f199.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3wzJ7agYKCXAgSObXQUccUZS.QcalSb-RSjSZZWghg.lSbdfcXSQh.cfU@flex--seanjc.bounces.google.com>)
 id 6a7b32c4-6ca4-0a2a45020019-d155d7c7bc2b-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:33:41 +0200
Received: by mail-pg1-f199.google.com with SMTP id
 41be03b00d2f7-c89704da8c7so4852181a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 07:33:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786458820; x=1787063620; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=wHiT8wO1O96VMhGw9PY7w1Kf2WhC1UcbMKtaZdcKQc8=;
        b=jY9G/FmRYe3cHYCB/IkbdZM8Y7PU+hTNTdVoSYbq+WcQH9Gp+VmqTwPoqBwhJ/TvgO
         IAyejSoz1N5p/nLJ7eGYkeKXPkQGg4Oleg4rEdsVQu/ytJrA64PW5A2jNP9yfmB+bf+j
         vpim/AO++shRJzSHKy8r8iOqnXfcewnCjA5RW7kmpbY5jtZMr+SY8NUeYFnxXrSKNTLf
         aPrGhW2sGd7mBJhiXsdngoPkqgyzjDTdafGABLg7BEQGk8O0NaFnJy6jwvJgcc+GIJLc
         IjnjiT/VJDKW0SH9JtVZjNUVqw9LkPILJiRbzSkgdxzzV0LsaRE7R8IyEKzvNkb+A3Jz
         zIjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786458820; x=1787063620;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wHiT8wO1O96VMhGw9PY7w1Kf2WhC1UcbMKtaZdcKQc8=;
        b=HB4jTJPZ0mSNL49b6+xhz/hxK1pOVFMTyeR9W0j4HS5lWbKSzQbLMRcpIsQtTC+AGs
         xjwm3vQO5EoHHO3TDEGMxHRwRMpekdnElXu2kUGxKWrz7ApEnelAQDtqgr+dGNIB5WgV
         KJN3Z35JsYYfljzZXVPa+NGn5JbFoPeoTtqzJwTJ4AhLy3hRPcnKqjytzgp/n3G0t2DF
         HIfSrvg0iuStVgdbhaBNgKAheSTLzFlTZW/SNdt8vVjMBiy/BNaM6VwIAcTixPqjtkdo
         iF+0O0cDoFq+Yn0/rQWEmJmBF+0pvUo76XjovB9giPpTNMbRu9k7yY78aVZyiIbNh3aG
         RKIw==
X-Forwarded-Encrypted: i=1; AHgh+RoSPVeb4z4vPEX2xtZhEFDfkeOqfOX3nxRBQ3qg9cGTUHbBdhfmw9YnDeOzsUMpDNIrVhjjdwI8GCU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx/6byYGB5vau7St8Z66b9+ls5tOjFQh4vODA8bZn2i5LriYv3w
	bR3hJ4r0bBbaEHRQvAguSm6sTD2rCfqG06fStJyvEAN7A70EsR0PRKBUcY53dl20yeBTDVkbqnt
	UFVeh6w==
X-Received: from pgmo14.prod.google.com ([2002:a63:5d4e:0:b0:cbe:7df7:35b0])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:9f10:b0:3bf:77d7:667d
 with SMTP id adf61e73a8af0-3cc2babdf84mr4904619637.28.1786458819619; Tue, 11
 Aug 2026 07:33:39 -0700 (PDT)
Date: Tue, 11 Aug 2026 07:33:39 -0700
In-Reply-To: <ansuqrD2KwFuLWbV@google.com>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-18-dwmw2@infradead.org>
 <anoOz2rZ02KFk1l-@google.com> <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
 <ano6-gIZtqMfipiD@google.com> <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
 <ansuqrD2KwFuLWbV@google.com>
Message-ID: <ansywxh0VX5rtfWc@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-720697/1786458821-F06A72AC-419BA02C/0/0
X-purgate-type: clean
X-purgate-size: 2735

On Tue, Aug 11, 2026, Sean Christopherson wrote:
> On Mon, Aug 10, 2026, David Woodhouse wrote:
> > On Mon, 2026-08-10 at 13:56 -0700, Sean Christopherson wrote:
> > > =C2=A0
> > > > > To allow different offsets, KVM would need to track a per-vCPU of=
fset to the
> > > > > master clock and apply that in kvm_guest_time_update() (and maybe=
 other places?).
> > > > > Which is doable, but it's not clear to me why we'd want to suppor=
t that (though
> > > > > I haven't fully processed the back half ot his series, so it's ve=
ry possible I'm
> > > > > missing something obvious).
> > > >=20
> > > > Because I want to reduce the number of cases where we have to fall =
back
> > > > to non-masterclock mode. Especially the ones which are driven by
> > > > *guests* rather than weird choices on the VMM's part.
> > >=20
> > > But why though?=C2=A0 What is the harm to the host or guest?=C2=A0 E.=
g. does it make it more
> > > difficult to accurately migrate the VM?=C2=A0 I'm not opposed to allo=
wing master-clock
> > > mode with diverging offsets, just trying to understand why it matters=
.
> >=20
> > Accurate migration without masterclock is hard, yes. The
> > KVM_SET_CLOCK_GUEST thing relies on it (because the principle is that
> > you get the *TSC* right, then the KVM clock is just a fixed
> > mathematical function of that).
> >=20
> > That *shouldn't* be difficult with offsets between vCPUs. Just use the
> > TSC of vCPU0 as the reference for KVM_SET_CLOCK_GUEST and let the
> > others just have their offset from that.
>=20
> Yeah, my only (quite mild) concern is that we would introduce fragility b=
y adding
> yet another variable that needs to be accounted for, but AFAICT it's lite=
rally
> just the tsc_timestamp in the shared data structure that consumes the per=
-vCPU
> offset.

Actually, why are KVM_{G,S}ET_CLOCK_GUEST vCPU-scoped?  Per the documentati=
on,
the API "Sets the KVM clock (for the whole VM) in terms of the vCPU TSC".  =
If
the APIs are VM-scoped instead of vCPU-scoped, then KVM can simply save/res=
tore
what's in the per-VM masterclock state, no?

That would also help address my concerns about sanity checking the TSC freq=
uency
against the kvmclock frequency, as the APIs are much more blatantly about s=
aving
and restoring masterclock state.  For whatever reason, it feels more natura=
l for
me to say that KVM_SET_CLOCK_GUEST will fail if the target frequency doesn'=
t
(fuzzily?) match the frequency at which the masterclock is already configur=
ed.
Probably because use_master_clock directly gates that information?  Whereas=
 the
vCPU's frequency is independently configured but obviously influences maste=
rclock
mode.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 14:36:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 14:36:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388297.1629505 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnaI-0004pz-WD; Tue, 11 Aug 2026 14:36:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388297.1629505; Tue, 11 Aug 2026 14:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtnaI-0004ps-Tb; Tue, 11 Aug 2026 14:36:06 +0000
Received: by outflank-mailman (input) for mailman id 1388297;
 Tue, 11 Aug 2026 14:36:06 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtnaI-0004pm-3m
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 14:36:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtnaH-00CMhI-GD
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:36:05 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7b3355-bab6-0a2a0a5309dd-0a2a4501afb8-0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:36:05 +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 <oleksii.kurochko@gmail.com>)
 id 6a7b3355-5984-0a2a45010019-d1558034dd4e-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:36:05 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so31019625e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 07:36:05 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49977e86b55sm78792885e9.4.2026.08.11.07.36.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 11 Aug 2026 07:36:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786458965; x=1787063765; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=NweeeWU/d1SpjWCrPg1YLxWa7FbW0YsPsbukU44y9t4=;
        b=jkRO52vSpU58kPCjQ6Zk9quN9m7Q8TPgX/ucJRpXhwtT1qIFOH6Pi9SdCqSRJH27Iu
         Y2eD8LItGQYaExP3Rj1WtxubNrcaRIIadOH/C3JQhQWknJyjQlYG921K10/ked+sqVKb
         mWtMXpWp9VcGtN9wRjBfcMapNDujceLpHc+EGLADaID/lKH/7uvMEQOj8K+OIhCQOtz3
         tZqm0l9xCBVRI4atU6hoskuTsQZ//xY+1FM/XSI9kXNYV/vQ6cpkXQ8lGNiEfckhKlBa
         dKqyS6euACRP88yja+ZsWw6OIpmS8o+OFHAsLQK0EDdUtRJ9wujatpq1FZLXl8Yn/3s/
         H7Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786458965; x=1787063765;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=NweeeWU/d1SpjWCrPg1YLxWa7FbW0YsPsbukU44y9t4=;
        b=EVf2HOKv9Y+hyXENpxrnlEBWIxD6zCd8peffTfq1OJ0pf3ApVlLHBZI2UHHoKymAZQ
         ntMFAcWVvNIQpYd0sFYM3X1Xgvib/N/zdd0LBXuPx4IdLLCWr6Hby1/uGRPKQGEPzCzJ
         jajAZ/z8rXcNiQwly90VolrwgCm16aPPLCdT9TJLu0WFaDe/ksJujzZkMMImNWAZStH/
         Huj4hpCDZChYQ1/bJVQcM1nJd8VGX4ldGXjwhEmRc7vlTfxhMKg4w4D2Kn1e9+95hsXD
         L8pJ1YdMEjd9xqbDKkcqBWQKbvSVkDHX8VHGGlp4lsDrYSmxfCtbr9wASDc2bOFhb0ls
         JC+g==
X-Forwarded-Encrypted: i=1; AHgh+RqMH8eWwhnpjvAFlzW4iR0gFGOAWx/aSjNfBuSicXHxxqcnk/NzCfH+jte7rY7HHfN2fNMQNOhO+c0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx3DpRKePAzr6eg2se7qcRAE/+drYvDRTstXBmSaOrDt3FO8Fy7
	XSle6IoMkvZkVAwgoNo9Ut2b34eV65d6WuQAf3qu0GeZHzz9eu66ENB4
X-Gm-Gg: AR+sD11M5YLSIu23KyAAdr7N+9mkuFosyiRVvZbQjyxsylKP1CYTayP99mrC4wEC+B8
	gBTWHUWCU/sr+BDbMYc91IRL1kP1MOkMGPfex3NQ8bXTJ961fv3MKWzQr2ZpJMANPiFr1Uox6vA
	RwBfBp2KpZ0EH4eeCjsq1haitI6dYMtP97tcnSrYOqIfpuk4J2ZknaCDiyzUccGoNDBrDFgeXaM
	M0Rh6ZbKwVEQekvqCCybjh4ncj65aqqx9qE54NkkMYH6WhMHi7hqwUMGwaDQfE7PR72c2LP97u/
	wNyOeVEnpcU6jwDwzPnGfeRNE4SHQ+4WIAPYBwtuJ8KUBs26RRWMfOsvkoL2/SxmrrLRt8CXf9M
	/0LMgBhBZWoCR2+NgftZJ1Bjb7aaKsyuL5rwSd0pisnrU5bZVnHi8wWG+tjHBk+5NJv3Kkq6aXs
	qdu9WfYZ/984WCPOat0OKw3hd4ViUNxOQiOXdXhr13B7s2MSH2LPA7WyuJZ969e2AlBY0xDJgZh
	WpX4/A/QTJoUSz2MOFCrZsU1aNzU8Q5mAl4US969cA=
X-Received: by 2002:a05:600c:45d2:b0:493:a438:7f98 with SMTP id 5b1f17b1804b1-49978485532mr59518495e9.18.1786458964685;
        Tue, 11 Aug 2026 07:36:04 -0700 (PDT)
Message-ID: <2187839d-fef8-4d51-8b98-8c0fb26a9569@gmail.com>
Date: Tue, 11 Aug 2026 16:36:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: Jan Beulich <jbeulich@suse.com>,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
Content-Language: en-US
In-Reply-To: <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1786458965-C475B757-96AE7052/10/73395122804
X-purgate-type: spam
X-purgate-size: 7789



On 8/11/26 11:21 AM, Baptiste Le Duc wrote:
> On 2026-08-07 18:08:21+02:00, Oleksii Kurochko wrote:
>> On 8/6/26 4:28 PM, Jan Beulich wrote:
>>
>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>
>>> For this tag to have any meaning, it should move ahead of the --- above;
>>> the explanations ...
>>>
>>>
>>> ... here rather explain the restriction on the R-b, not its odd placement.
>>>
>>>
>>> As this looks to be recurring - please get versioning of your series right.
>>> The series is supposedly v1, but here you give the impression of it being
>>> v3. If there really was an earlier v2 posting, why isn't the entire series
>>> here v3?
>>
>> It is v3 before before it was a part of another patch series connected
>> to dom0less config enablement.
>>
>> Would it be better to just write in "Change in v3" that it is moved from
>> another patch series + link to that patch series? Or it will be enough
>> just to drop "Changes in v2 and v1" and just start from v1?
>>
>>> PLease can you, before submitting, self-review your patches? I'm really
>>> getting tired of having to repeatedly point out basic style issues, like
>>> the overlong line here.
>>
>> Sorry for that, I will write an extra checker for such cases to not miss
>> them.
>>
>>> It extends to the other local variables here, but I'll use these two to
>>> try to make my point: I'm struggling to associate the names with the
>>> values they are set to. Likely "hxw" is an abbreviation of hart index
>>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
>>> in "hhxw"? By using hard to grasp names, you make it hard to actually
>>> understand the subsequent expressions, in particular ...
>>
>> The names it taken directly from AIA spec:
>>
>> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low
>> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart
>> Index Width) for determining target addresses for MSIs is described
>> later, in Section 4.9.1.
>>
>> The AIA specification interprets the machine-level hart index as a
>> combination of the **group index** (`g`) and the **hart index within the
>> group** (`h`), according to the following formulas:
>>
>> ```
>> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
>> (2) h = machine-level hart index & (2^LHXW − 1)
>> ```
>>
>> (In our case, the machine-level hart index is equal to `mhartid`, i.e.
>> the hart index.)
> Therefore, if I understand correclty, if we take the Hart Index as
> defined in the AIA spec, we should have:
> Hart Index = (g << LHXW) | h
> Is it correct?

Yes.

But note that in the current version of aplic_hart_field(), hart_id is 
passed directly, so there is no need to extract h as described in the 
AIA specification. We only need to concatenate it with the group index 
that we have already extracted.

This is partly because aplic_hart_field() uses only .base_addr, which 
does not contain hart_index.

If we want to follow the AIA specification fully, using its terminology, 
the code should look something like:

static unsigned long aplic_hart_field(unsigned int cpu)
{
     const struct imsic_config *imsic = imsic_get_config();
     const struct imsic_msi *msi = &imsic->msi[cpu];
     unsigned int lhxs = imsic->guest_index_bits;
     unsigned int lhxw = imsic->hart_index_bits;
     unsigned int hhxw = imsic->group_index_bits;
     unsigned int hhxs =
         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 
address.
      */
     paddr_t target_addr = msi->base_addr + msi->offset;
     unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
     unsigned long group_index =
         (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
         APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
     unsigned long hart_index =
         (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) &
         APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);

     return (group_index << lhxw) | hart_index;
}

(note that during writing that I found an issue, it should be really 
passed Xen cpu id, not hartid as msi[] is iterated through Xen cpu id so 
I've taken that into account when wrote an implementation mentioned above)

Generally I think I am okay with both version of how to get hart_index 
(or pass it by an argument or extract it).

>>
>> For systems that use IMSIC groups, the IMSIC address layout is defined
>> by the following parameters:
>>
>> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the
>> hart number within a group.
>> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
>> the group number.
> Is group number appelation equivalent to group index?
> 
> I think with if what I wrote above is correct, the proper definition for
> `hhxw` and `hhxs` should be:
> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
> the `Hart Index` field within the physical address.
>> * `hhxs` (High Hart Index Shift): the bit offset of the combined
>> hart/group index field within the physical address.
> * `hhxs` (High Hart Index Shift): the bit offset of the `Hart Index`
> field within the physical address.
>> To extract the group index, we first shift the address by `hhxs` so that
>> the group index bits are aligned, and then apply a mask derived from
>> `hhxw` to isolate those bits.
>>
>> The hardware performs the same operation to extract the hart index from
>> the MSI address. However, in our case we already know which hart should
>> receive the interrupt (`hartid`), so there is no need to extract the
>> hart index from the base address. We only need to recover the group
>> index and combine it with `hartid` to construct the value expected by
>> the `target` register.
> 
> Why don't we direclty extract the Hart Index as target directly needs it
> as explained in the 4.5.16.2 point of the AIA spec:
> target[31:18] = Hart Index
> target[17:12] = Guest Index
> target[10:0] = EEID
> It'd be easier as we just have to do shift from HHXS and apply HHXW.

 From IMSIC's DT-binding description we have:

   XLEN-1            > (HART Index MSB)                  12    0
   |                  |                                  |     |
   -------------------------------------------------------------
   |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
   -------------------------------------------------------------

If you see there is a set of "xxxxxx" between HART and Group Indexes 
that is the reason why we have to extract HART and Group Index 
separately as when h/w will work with target register it doesn't know 
about "xxxxx" at all so from h/w point of view target's register hart 
field looks like |Group Index|Hart Index|. In other words, h/w will do
the following with TARGET's hart index field:
     group_idx = hart_idx >> lhxw;
     hart_idx &= APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);

and then embed group_idx and hart_idx into the structure above.

Does it make sense?

> 
> I will try to draw some schema to make the AIA spec more explicit. Maybe
> it could be part of this series, I don't know what is the xen policy
> about diagram and stuff like that. Do you know more about that?

Unfortunately, no, I don't.

> In order 
> to not do a job with no needed at all.
> 

IMO, it is enough only AIA spec here to understand. At least, it is 
clear to me.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 15:05:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 15:05:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388307.1629516 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wto2g-0000yK-5H; Tue, 11 Aug 2026 15:05:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388307.1629516; Tue, 11 Aug 2026 15:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wto2g-0000yD-1k; Tue, 11 Aug 2026 15:05:26 +0000
Received: by outflank-mailman (input) for mailman id 1388307;
 Tue, 11 Aug 2026 15:05:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wto2c-0000y7-VI
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:05:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wto2b-000Vaj-R2; Tue, 11 Aug 2026 17:05:21 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b3a28-bab6-0a2a0a5309dd-0a2a45098544-18
 for <multiple-recipients>; Tue, 11 Aug 2026 17:05:20 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b3a30-be1a-0a2a45090019-5a9b3222da72-3
 for <multiple-recipients>; Tue, 11 Aug 2026 17:05:20 +0200
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wto2P-00000000avv-0iNZ; Tue, 11 Aug 2026 15:05:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=C6rkUIL+dM1UFpFpZSm+dPCwsMFKdFomwHvt9iy8cEo=; b=oVq/9ftDEOCy0zT21RIRhInWyA
	xTR9PHbbOmnMF5nK1StXUz7O6WRpcslQPreuEUiQYa1xoJBjIMfSXBEn5zw7slp8C2icWp9oJcoUT
	3S5wy5GI3r+1zGmQjWyCPh/EpD5Oz3ueAuyNDLD/bMrNuXDjK+exsf+WUkQNvMGO8ZjWJSvk9n6xo
	OYRlQ7sHKvNVlu5Vud/NojZJibnz1tL6iby4p0WvwWSSxjx+d4emimsCM57wG1R4cK3BU+xcQY0WZ
	CFWq4sB44UaATIUOZYxJk7m54tmLacdFSZ4aEUikXWc1CDYehcGC6QBoWNQ7Rw2yRPLcfzYf7/99C
	IVStKiMg==;
Message-ID: <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Tue, 11 Aug 2026 16:05:03 +0100
In-Reply-To: <ansywxh0VX5rtfWc@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-18-dwmw2@infradead.org>
	 <anoOz2rZ02KFk1l-@google.com>
	 <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
	 <ano6-gIZtqMfipiD@google.com>
	 <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
	 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-F6kD8Qx0GpTaOeFjxO+8"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-bad1c0/1786460720-BC2F4034-CA10312C/0/0
X-purgate-type: clean
X-purgate-size: 12481


--=-F6kD8Qx0GpTaOeFjxO+8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 07:33 -0700, Sean Christopherson wrote:
>=20
> Actually, why are KVM_{G,S}ET_CLOCK_GUEST vCPU-scoped?=C2=A0 Per the docu=
mentation,
> the API "Sets the KVM clock (for the whole VM) in terms of the vCPU TSC".=
=C2=A0 If
> the APIs are VM-scoped instead of vCPU-scoped, then KVM can simply save/r=
estore
> what's in the per-VM masterclock state, no?

They're vCPU-scoped because they need to be tied to a guest TSC (on
live migration, neither ka->master_cycle_now nor ka->master_kernel_ns
are useful =E2=80=94 those are the "per-VM masterclock state").

Theoretically, guest TSCs can be different on each vCPU (different
offset, different *rate* even. Not that we allow KVM_[GS]ET_CLOCK_GUEST
at different rates, I concede).

So they operate in the context of a given vCPU, and *its* TSC.

And I think I'm going to defend that 'theoretical they can be
different', because I *would* like to eliminate the ways that a *guest*
can force non-masterclock mode, and that does mean allowing the offset-
TSC case.

FWIW in my local tree I've just extended the pvclock_migration_test to
test precisely the thing you were concerned about: three vCPUs with
divergent TSC offsets, migrated by setting each vCPU's TSC and then
invoking KVM_SET_CLOCK_GUEST once, through vCPU0. Masterclock stays
active, TSC_STABLE_BIT is correctly clear, and all three vCPUs'
pvclocks (and KVM_GET_CLOCK) agree to within a nanosecond afterwards.
I'll include that in the next spin.

> That would also help address my concerns about sanity checking the TSC fr=
equency
> against the kvmclock frequency, as the APIs are much more blatantly about=
 saving
> and restoring masterclock state.=C2=A0 For whatever reason, it feels more=
 natural for
> me to say that KVM_SET_CLOCK_GUEST will fail if the target frequency does=
n't
> (fuzzily?) match the frequency at which the masterclock is already config=
ured.
> Probably because use_master_clock directly gates that information?=C2=A0 =
Whereas the
> vCPU's frequency is independently configured but obviously influences mas=
terclock
> mode.

I am perfectly happy to say that the *existing* check as I have coded
it, is matching against the frequency at which the masterclock is
configured. Because we can't *get* there if the guest is not in
masterclock mode, and it can't be in masterclock mode unless all its
vCPUs are running at the same rate, which *is* the master clock rate.
:)

I guess I could even concede to change the actual code rather than just
the comment... (untested)

Still needs the *offset* of the vCPU though.

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3595,15 +3595,15 @@ static int kvm_vcpu_ioctl_set_clock_guest(struct kv=
m_vcpu *v, void __user *argp

 	if (kvm_caps.has_tsc_control)
 		curr_tsc_hz =3D kvm_scale_tsc(curr_tsc_hz,
-					    v->arch.l1_tsc_scaling_ratio);
+					    ka->master_tsc_scaling_ratio);

 	/*
 	 * The mul/shift in the provided pvclock structure encode the guest
 	 * TSC frequency at which it was generated. Sanity-check that it is
-	 * consistent with this vCPU's effective TSC frequency, allowing a
-	 * discrepancy of 1 kHz either way since independently calibrated
-	 * hosts will not measure precisely the same value even for the
-	 * same nominal frequency.
+	 * consistent with the frequency at which the masterclock is
+	 * configured, allowing a discrepancy of 1 kHz either way since
+	 * independently calibrated hosts will not measure precisely the
+	 * same value even for the same nominal frequency.
 	 */
 	if (user_tsc_hz < curr_tsc_hz - 1000 ||
 	    user_tsc_hz > curr_tsc_hz + 1000) {


--=-F6kD8Qx0GpTaOeFjxO+8
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTExNTA1MDNaMC8GCSqGSIb3DQEJBDEiBCDFbSyovApCNUfaxhwvqCaJrltHNSYe
jCXlvMu4NV8iATCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAYrlfhsRcAyFN06G/q2KrfKFrEZEHEpE1+LkSLuzFSfXqkKPU1M/g
HxQYjzaV/xXqt2Bsua58UrT3eIVpE3hRx8JhO1sxyG+E1qWnZ6t6O+9CtHlljcaqQ2VjAoWMOWgH
ZJy8nfX6Fjrf+mDwJImu5B9tWpJNrIyHw6OL9wOJTbDIY6tYBwHHLnSeYYdhz7CLeW6dI0B1Lcx8
LS+te0bQKqSl9JK44er9iNEmdBTD5DtjY5PhaNJLKN9Jkm9KZwnvsqQWisLg/2Y7Mf49BadI/QiE
wQOZsdksfhfJop5ixidC1b8XGLHJXNMan1sbyUq0YpUUHqAvGfQXDpJD9sD4GJkW5v/Y/8I9Qqce
UxBqhQJ+6fyfZx0bNvC8cUKQQpZIgNgqBrMwAsWRM8roga5kfd5RHKux11jmP5xspBO5KE9NpA2C
D8EFh2kLF8IuqTDvUMnRq3dPBSjhAmmbdjy7zgf5zMx/jTcXSfrS/lClj5Qf0ccFAhzPgoimNEEk
br/ofV+rlkJyv177z8AKi4Iqu8j3RrsoM1WTTrFAnmSod3z5YjodaFyYgLDbaqzPMxzbYI+Irz84
l3kdCmolUpt5y23AY19r72axX4WAmUo1ERCh+yt5d9FdSpUIiOV4OcCmpWMuFURA6so8VHXGXqnr
h4FPTROPNaArNi9Wm/TpNrUAAAAAAAA=


--=-F6kD8Qx0GpTaOeFjxO+8--


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 15:29:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 15:29:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388323.1629524 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtoQE-0004Hz-4y; Tue, 11 Aug 2026 15:29:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388323.1629524; Tue, 11 Aug 2026 15:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtoQD-0004Hr-VV; Tue, 11 Aug 2026 15:29:45 +0000
Received: by outflank-mailman (input) for mailman id 1388323;
 Tue, 11 Aug 2026 15:29:44 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@swg.vates.tech>)
 id 1wtoQB-0004Hk-N9
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 15:29:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtoQ9-00EsYU-Ei
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 17:29:41 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@swg.vates.tech>)
 id 6a7b3fc5-bab6-0a2a0a5309dd-0a2a45028760-32
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 17:29:41 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@swg.vates.tech>)
 id 6a7b3fe4-6ca4-0a2a45020019-b9ff1c129f15-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 17:29:40 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ff17189ea000c4f3.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 11 Aug 2026 15:29:37 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id ECAE6836F1;
 Tue, 11 Aug 2026 17:29:36 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=SQYRjrECz2lCt3b7FbSUi/noBU2ON3/HTV+7xPquC2E=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=DY5yScjH0arpvSlVhn0A08tBeSSlNw3gu01+cHbeoD/nZil5Opx24/SCTVyeAlZ8wHPcEHlSr
 xOML9B8IEoQtDSHatMqyLpHnBUFx3u2i7I2xMrD+dS8HiznPibg85DZ/OLsvh8pNWYuurC+KedF
 dY3NKWmF2bkm67j4MgTdrLWT7d9fyg6HYTgdImcWX2FzaLVCopmVN9CV8SAnwuW1WCycnFLtjYr
 06Xlp2oKc06f0Nm7fthGNwK2tdHx6+bOZdbXqWjnRk9cP8PzC0DBKRB6DLRixWOD4E2+26prPHP
 dYE67OVtMqtJuQpp3ucXXqKQ8YzccxlcjOCsTUsrnvUQ==
X-Zone-Loop: 2d8c5759c7009ba8ac5e59768a39ebaa0cba67b9245b
x-campaign-type: default
x-transaction-id: ab04de0a-0762-4216-960c-05e109aa0b74
x-swg-uid: 01-f1f4f613-377d-4850-a4c2-971ca03da645
X-Mailer: Sweego
Message-ID:
 <1786462177.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@vates.tech>
x-swg-bid: 1786462177.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Jan Beulich <jbeulich@suse.com>, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
In-Reply-To: <2187839d-fef8-4d51-8b98-8c0fb26a9569@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
 <2187839d-fef8-4d51-8b98-8c0fb26a9569@gmail.com>
Date: Tue, 11 Aug 2026 17:29:31 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786462176; l=8612;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=WM8w/m+gOxCBN24OL9AIoVIQqmsbVJj3MSsjvLlnUX8=;
 b=dsZMnHtAgw6lRYLsF8uEVSmOo2ETpWwZgR2AwrC2h1jMidMz7XtvdCnQODYeEvZQ3nRTjYknK
 JERa6MGgkH/DyP/NCdb3BuCtMM0wtg627+VGo6WKSzbqNos2jGzu47q
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786462177172
X-purgate-ID: tlsNG-720697/1786462181-307C22AC-00666627/0/0
X-purgate-type: clean
X-purgate-size: 8616

On 2026-08-11 16:36 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/11/26 11:21 AM, Baptiste Le Duc wrote:
> > On 2026-08-07 18:08:21+02:00, Oleksii Kurochko wrote:
> >> On 8/6/26 4:28 PM, Jan Beulich wrote:
> >>
> >>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
> >>>
> >>> For this tag to have any meaning, it should move ahead of the --- above;
> >>> the explanations ...
> >>>
> >>>
> >>> ... here rather explain the restriction on the R-b, not its odd placement.
> >>>
> >>>
> >>> As this looks to be recurring - please get versioning of your series right.
> >>> The series is supposedly v1, but here you give the impression of it being
> >>> v3. If there really was an earlier v2 posting, why isn't the entire series
> >>> here v3?
> >>
> >> It is v3 before before it was a part of another patch series connected
> >> to dom0less config enablement.
> >>
> >> Would it be better to just write in "Change in v3" that it is moved from
> >> another patch series + link to that patch series? Or it will be enough
> >> just to drop "Changes in v2 and v1" and just start from v1?
> >>
> >>> PLease can you, before submitting, self-review your patches? I'm really
> >>> getting tired of having to repeatedly point out basic style issues, like
> >>> the overlong line here.
> >>
> >> Sorry for that, I will write an extra checker for such cases to not miss
> >> them.
> >>
> >>> It extends to the other local variables here, but I'll use these two to
> >>> try to make my point: I'm struggling to associate the names with the
> >>> values they are set to. Likely "hxw" is an abbreviation of hart index
> >>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
> >>> in "hhxw"? By using hard to grasp names, you make it hard to actually
> >>> understand the subsequent expressions, in particular ...
> >>
> >> The names it taken directly from AIA spec:
> >>
> >> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low
> >> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart
> >> Index Width) for determining target addresses for MSIs is described
> >> later, in Section 4.9.1.
> >>
> >> The AIA specification interprets the machine-level hart index as a
> >> combination of the **group index** (`g`) and the **hart index within the
> >> group** (`h`), according to the following formulas:
> >>
> >> ```
> >> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
> >> (2) h = machine-level hart index & (2^LHXW − 1)
> >> ```
> >>
> >> (In our case, the machine-level hart index is equal to `mhartid`, i.e.
> >> the hart index.)
> > Therefore, if I understand correclty, if we take the Hart Index as
> > defined in the AIA spec, we should have:
> > Hart Index = (g << LHXW) | h
> > Is it correct?
> 
> Yes.
> 
> But note that in the current version of aplic_hart_field(), hart_id is 
> passed directly, so there is no need to extract h as described in the 
> AIA specification. We only need to concatenate it with the group index 
> that we have already extracted.
> 
> This is partly because aplic_hart_field() uses only .base_addr, which 
> does not contain hart_index.
> 
> If we want to follow the AIA specification fully, using its terminology, 
> the code should look something like:
> 
> static unsigned long aplic_hart_field(unsigned int cpu)
> {
>      const struct imsic_config *imsic = imsic_get_config();
>      const struct imsic_msi *msi = &imsic->msi[cpu];
Could you please specify how this function will be used and when? It's
hard for me to understand how imsic->msi[cpu] is filled.
>      unsigned int lhxs = imsic->guest_index_bits;
>      unsigned int lhxw = imsic->hart_index_bits;
>      unsigned int hhxw = imsic->group_index_bits;
>      unsigned int hhxs =
>          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 
> address.
>       */
>      paddr_t target_addr = msi->base_addr + msi->offset;
>      unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
>      unsigned long group_index =
>          (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
>          APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
>      unsigned long hart_index =
>          (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) &
>          APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);
> 
>      return (group_index << lhxw) | hart_index;
> }
> 
> (note that during writing that I found an issue, it should be really 
> passed Xen cpu id, not hartid as msi[] is iterated through Xen cpu id so 
> I've taken that into account when wrote an implementation mentioned above)
> 
> Generally I think I am okay with both version of how to get hart_index 
> (or pass it by an argument or extract it).
> 
> >>
> >> For systems that use IMSIC groups, the IMSIC address layout is defined
> >> by the following parameters:
> >>
> >> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the
> >> hart number within a group.
> >> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
> >> the group number.
> > Is group number appelation equivalent to group index?
> > 
> > I think with if what I wrote above is correct, the proper definition for
> > `hhxw` and `hhxs` should be:
> > * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
> > the `Hart Index` field within the physical address.
> >> * `hhxs` (High Hart Index Shift): the bit offset of the combined
> >> hart/group index field within the physical address.
> > * `hhxs` (High Hart Index Shift): the bit offset of the `Hart Index`
> > field within the physical address.
> >> To extract the group index, we first shift the address by `hhxs` so that
> >> the group index bits are aligned, and then apply a mask derived from
> >> `hhxw` to isolate those bits.
> >>
> >> The hardware performs the same operation to extract the hart index from
> >> the MSI address. However, in our case we already know which hart should
> >> receive the interrupt (`hartid`), so there is no need to extract the
> >> hart index from the base address. We only need to recover the group
> >> index and combine it with `hartid` to construct the value expected by
> >> the `target` register.
> > 
> > Why don't we direclty extract the Hart Index as target directly needs it
> > as explained in the 4.5.16.2 point of the AIA spec:
> > target[31:18] = Hart Index
> > target[17:12] = Guest Index
> > target[10:0] = EEID
> > It'd be easier as we just have to do shift from HHXS and apply HHXW.
> 
>  From IMSIC's DT-binding description we have:
> 
>    XLEN-1            > (HART Index MSB)                  12    0
>    |                  |                                  |     |
>    -------------------------------------------------------------
>    |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
>    -------------------------------------------------------------
> 
> If you see there is a set of "xxxxxx" between HART and Group Indexes 
I think I'm missunderstanding the spec, as I wrote before I thought that
[1] `Hart index` = group_idx << LHXW | hart_idx_within_the_group so,
does the Hart Index in the schema refer to hart_idx_within_the_group or
to [1]? The naming makes me a bit confuse.
> that is the reason why we have to extract HART and Group Index 
> separately as when h/w will work with target register it doesn't know 
> about "xxxxx" at all so from h/w point of view target's register hart 
> field looks like |Group Index|Hart Index|. In other words, h/w will do
> the following with TARGET's hart index field:
>      group_idx = hart_idx >> lhxw;
>      hart_idx &= APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);
> 
> and then embed group_idx and hart_idx into the structure above.
> 
> Does it make sense?
> 
> > 
> > I will try to draw some schema to make the AIA spec more explicit. Maybe
> > it could be part of this series, I don't know what is the xen policy
> > about diagram and stuff like that. Do you know more about that?
> 
> Unfortunately, no, I don't.
> 
> > In order 
> > to not do a job with no needed at all.
> > 
> 
> IMO, it is enough only AIA spec here to understand. At least, it is 
> clear to me.
> 
> ~ Oleksii
> 
> 
> 




From xen-devel-bounces@lists.xenproject.org Tue Aug 11 16:24:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 16:24:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388354.1629533 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtpHP-0004l2-Tf; Tue, 11 Aug 2026 16:24:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388354.1629533; Tue, 11 Aug 2026 16:24:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtpHP-0004ku-Qm; Tue, 11 Aug 2026 16:24:43 +0000
Received: by outflank-mailman (input) for mailman id 1388354;
 Tue, 11 Aug 2026 16:24:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wtpHO-0004ko-Tw
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:24:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtpHO-00CdrT-Ai
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 18:24:42 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7b4c88-bab6-0a2a0a5309dd-0a2a450889fa-36
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 18:24:42 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7b4cca-f659-0a2a45080019-d155dd29cc89-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 18:24:42 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47f633e6058so2718442f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 09:24:42 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4814a5ac75dsm5037573f8f.7.2026.08.11.09.24.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 11 Aug 2026 09:24:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786465482; x=1787070282; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=boonSqRRqTnfOis0nzNcGL4sDeoihRNPKVms6bgDfIw=;
        b=q4dyBf1U8Ta5uza7G8ewz5pLoWJofi0GZaOHx1b1+l1BPVmx4gpMjh2qL/tudnWAMX
         Ir46FEgTKvfmUJAEMUj4Gq+BaH4Y2um+Jt0pP/TeDWzQlNeM93s3Y//sROL4AaKHskFq
         5lVnhi7wT+x3zDHWJjsferxPxGVGHKGnDLcN+4A8tEX58UNQq4NiWUUCBFdR4OH220z1
         7GwCq6sXtAFKmwre0N+snCCjzl5GvuV1NPJ2NipUQtfkpJbS+Min8nZJ2g0ROHtDzqAf
         Wro7/qYX5UEAr/oFeE61EkbnDDekPlXdvomYd30YMBrE6cnGrBDTyolu3KyWl6HJBN89
         Q9NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786465482; x=1787070282;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=boonSqRRqTnfOis0nzNcGL4sDeoihRNPKVms6bgDfIw=;
        b=EsSskRrtJF8EvjXRz+h/2RK2ki9TOROI1r8hbdQm4gYTffp6TLYK5Ulcf0SrYqPh8G
         BM3aw650oFpTwiG2QTqBW4JYMwzwI13Yjyv1CX0MZFt7YcEvVJ/cmQ+zz7XmB9BHuLiQ
         OotVekNn1nQ71GoNx0cKU1COP5wCgcu4cLuuB8WcnOTTtcPekbYsKLtaplXVuSYDjHi9
         av2MA7grUDKO2omhB/LdFhAqdXrpgRyt/g5fjQjtalX4KFwtVBCyJWZ4WITuvH9QoLyp
         YE2zZdfTiDoWElHkfTQy5210k+xVzuknmz7SPpDNY+HVrwL2blYUu16mQ8a1EV9c+3jw
         B+WA==
X-Forwarded-Encrypted: i=1; AHgh+Rrj41fzQBqPHjswFsq6UGPHkIoen5cKTV3nAYvcCEVKjOA95EVukVIXphZf299EikBlV1WqMOPvw5U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwL5kHLbkPmGxzzrIeKwlRhQ8gIaYD6KWkod5Mx3p00Zz4UiYGW
	YiZ3G6C2Yyq1ggV3stL8/MkVfbSTXp6/gNqbGF8DlUQJ02Bi12ICsuBh
X-Gm-Gg: AR+sD13nLDk3SnUBfv3RTstmQTVmadyu1Rkhg+IsFqrXCkpPpIN+2/O0O2eVW9jiUXZ
	pLo83cZHEwDtHp1eHLQBvcJkMH5FmsO/bvFRDKmSuurCbygNsj0soCeo0Ih1jg/hFYLk7SJkdmp
	BRTBish6B3GGxszFIn+dvu9/Gdw8VHpqxClhYeUKWBMkzdFMM8SNontACPHCIqu59ryAlTM9ldF
	H50AlroxNI4cm4xbNl36G8ogPvSpw26p0PslMEZw101GLyPCIDdPlblgmd2BtwGb4PnSadAolTs
	32QknfmpogIgDFGIqI50dxw2RvsvZUZ64LsoeftRTUBCHIAhD6QDmW6GB5ykKprGbsdsL+amyJN
	4JedG13n1nl9MhUAGeCqXlS6eyEO42fLXPv1PeRkVjMxa08QhJk3heOuQakS3E9hY1cnC1S7ZoY
	hpMApIhRS4tFBpIIPchX5ceFPDwjlvKIXjtRf+5xs+jXoLyqLhKhLU/CKxOSamE3DpJWwDVgInr
	Ve3MH7AKXLUvVt/rgK2zY30UZyOgTv0kIw93pkR0GM=
X-Received: by 2002:a5d:64e6:0:b0:47f:e721:1f77 with SMTP id ffacd0b85a97d-4814ad94cb6mr7843857f8f.13.1786465481482;
        Tue, 11 Aug 2026 09:24:41 -0700 (PDT)
Message-ID: <70560c6e-17dd-4524-919b-1dad9c774bee@gmail.com>
Date: Tue, 11 Aug 2026 18:24:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: Jan Beulich <jbeulich@suse.com>,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
 <2187839d-fef8-4d51-8b98-8c0fb26a9569@gmail.com>
 <1786462177.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786462177.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1786465482-CF35D87B-140528A0/10/73395122804
X-purgate-type: spam
X-purgate-size: 11871



On 8/11/26 5:29 PM, Baptiste Le Duc wrote:
> On 2026-08-11 16:36 +0200, Oleksii Kurochko wrote:
>>
>>
>> On 8/11/26 11:21 AM, Baptiste Le Duc wrote:
>>> On 2026-08-07 18:08:21+02:00, Oleksii Kurochko wrote:
>>>> On 8/6/26 4:28 PM, Jan Beulich wrote:
>>>>
>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>
>>>>> For this tag to have any meaning, it should move ahead of the --- above;
>>>>> the explanations ...
>>>>>
>>>>>
>>>>> ... here rather explain the restriction on the R-b, not its odd placement.
>>>>>
>>>>>
>>>>> As this looks to be recurring - please get versioning of your series right.
>>>>> The series is supposedly v1, but here you give the impression of it being
>>>>> v3. If there really was an earlier v2 posting, why isn't the entire series
>>>>> here v3?
>>>>
>>>> It is v3 before before it was a part of another patch series connected
>>>> to dom0less config enablement.
>>>>
>>>> Would it be better to just write in "Change in v3" that it is moved from
>>>> another patch series + link to that patch series? Or it will be enough
>>>> just to drop "Changes in v2 and v1" and just start from v1?
>>>>
>>>>> PLease can you, before submitting, self-review your patches? I'm really
>>>>> getting tired of having to repeatedly point out basic style issues, like
>>>>> the overlong line here.
>>>>
>>>> Sorry for that, I will write an extra checker for such cases to not miss
>>>> them.
>>>>
>>>>> It extends to the other local variables here, but I'll use these two to
>>>>> try to make my point: I'm struggling to associate the names with the
>>>>> values they are set to. Likely "hxw" is an abbreviation of hart index
>>>>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
>>>>> in "hhxw"? By using hard to grasp names, you make it hard to actually
>>>>> understand the subsequent expressions, in particular ...
>>>>
>>>> The names it taken directly from AIA spec:
>>>>
>>>> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low
>>>> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart
>>>> Index Width) for determining target addresses for MSIs is described
>>>> later, in Section 4.9.1.
>>>>
>>>> The AIA specification interprets the machine-level hart index as a
>>>> combination of the **group index** (`g`) and the **hart index within the
>>>> group** (`h`), according to the following formulas:
>>>>
>>>> ```
>>>> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
>>>> (2) h = machine-level hart index & (2^LHXW − 1)
>>>> ```
>>>>
>>>> (In our case, the machine-level hart index is equal to `mhartid`, i.e.
>>>> the hart index.)
>>> Therefore, if I understand correclty, if we take the Hart Index as
>>> defined in the AIA spec, we should have:
>>> Hart Index = (g << LHXW) | h
>>> Is it correct?
>>
>> Yes.
>>
>> But note that in the current version of aplic_hart_field(), hart_id is
>> passed directly, so there is no need to extract h as described in the
>> AIA specification. We only need to concatenate it with the group index
>> that we have already extracted.
>>
>> This is partly because aplic_hart_field() uses only .base_addr, which
>> does not contain hart_index.
>>
>> If we want to follow the AIA specification fully, using its terminology,
>> the code should look something like:
>>
>> static unsigned long aplic_hart_field(unsigned int cpu)
>> {
>>       const struct imsic_config *imsic = imsic_get_config();
>>       const struct imsic_msi *msi = &imsic->msi[cpu];
> Could you please specify how this function will be used and when? It's
> hard for me to understand how imsic->msi[cpu] is filled.

imsic->msi[] is filled during IMSIC initialization in imsic_init(), 
based on the MMIO regset specified in the IMSIC node’s reg property and 
the number of parents specified in the interrupts-extended property. 
This is explained to some extent in the comment above local target_addr 
in aplic_hart_field() (a little further down).

I am not 100% sure that I fully understand the connection between your 
question and the sentence after it, but I planned to write the following 
above the function declaration:


/*
  * The arrangement of IMSIC interrupt files in MMIO space follows a 
topology
  * 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|Group Index|xxxxxxxx|Hart Index|xxxx|Guest Index|     0     |
  * -------------------------------------------------------------------
  *
  * - xxxx: the remaining bits of the Base PPN. The specification 
requires the
  *   Base PPN to have zeros in the positions where the indices are OR-ed.
  * - Group Index (g): placed at bit (HHXS + 24) of the physical address.
  * - Hart Index (h): placed at bit (LHXS + 12) of the physical address.
  * - 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 = 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 
number
  *   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 
domain
  * 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-defined
  * Hart Index format to ensure correct MSI targeting.
  */

Does it answer your question?

>>       unsigned int lhxs = imsic->guest_index_bits;
>>       unsigned int lhxw = imsic->hart_index_bits;
>>       unsigned int hhxw = imsic->group_index_bits;
>>       unsigned int hhxs =
>>           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
>> address.
>>        */
>>       paddr_t target_addr = msi->base_addr + msi->offset;
>>       unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
>>       unsigned long group_index =
>>           (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
>>           APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
>>       unsigned long hart_index =
>>           (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) &
>>           APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);
>>
>>       return (group_index << lhxw) | hart_index;
>> }
>>
>> (note that during writing that I found an issue, it should be really
>> passed Xen cpu id, not hartid as msi[] is iterated through Xen cpu id so
>> I've taken that into account when wrote an implementation mentioned above)
>>
>> Generally I think I am okay with both version of how to get hart_index
>> (or pass it by an argument or extract it).
>>
>>>>
>>>> For systems that use IMSIC groups, the IMSIC address layout is defined
>>>> by the following parameters:
>>>>
>>>> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the
>>>> hart number within a group.
>>>> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
>>>> the group number.
>>> Is group number appelation equivalent to group index?
>>>
>>> I think with if what I wrote above is correct, the proper definition for
>>> `hhxw` and `hhxs` should be:
>>> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
>>> the `Hart Index` field within the physical address.
>>>> * `hhxs` (High Hart Index Shift): the bit offset of the combined
>>>> hart/group index field within the physical address.
>>> * `hhxs` (High Hart Index Shift): the bit offset of the `Hart Index`
>>> field within the physical address.
>>>> To extract the group index, we first shift the address by `hhxs` so that
>>>> the group index bits are aligned, and then apply a mask derived from
>>>> `hhxw` to isolate those bits.
>>>>
>>>> The hardware performs the same operation to extract the hart index from
>>>> the MSI address. However, in our case we already know which hart should
>>>> receive the interrupt (`hartid`), so there is no need to extract the
>>>> hart index from the base address. We only need to recover the group
>>>> index and combine it with `hartid` to construct the value expected by
>>>> the `target` register.
>>>
>>> Why don't we direclty extract the Hart Index as target directly needs it
>>> as explained in the 4.5.16.2 point of the AIA spec:
>>> target[31:18] = Hart Index
>>> target[17:12] = Guest Index
>>> target[10:0] = EEID
>>> It'd be easier as we just have to do shift from HHXS and apply HHXW.
>>
>>   From IMSIC's DT-binding description we have:
>>
>>     XLEN-1            > (HART Index MSB)                  12    0
>>     |                  |                                  |     |
>>     -------------------------------------------------------------
>>     |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
>>     -------------------------------------------------------------
>>
>> If you see there is a set of "xxxxxx" between HART and Group Indexes
> I think I'm missunderstanding the spec, as I wrote before I thought that
> [1] `Hart index` = group_idx << LHXW | hart_idx_within_the_group so,
> does the Hart Index in the schema refer to hart_idx_within_the_group or
> to [1]? The naming makes me a bit confuse.

Could you please check my comment above and if it doesn't provide answer 
to your questions I will try to explain it differently.


>> that is the reason why we have to extract HART and Group Index
>> separately as when h/w will work with target register it doesn't know
>> about "xxxxx" at all so from h/w point of view target's register hart
>> field looks like |Group Index|Hart Index|. In other words, h/w will do
>> the following with TARGET's hart index field:
>>       group_idx = hart_idx >> lhxw;
>>       hart_idx &= APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);
>>
>> and then embed group_idx and hart_idx into the structure above.
>>
>> Does it make sense?
>>
~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 16:40:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 16:40:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388372.1629542 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtpWH-0007ps-8W; Tue, 11 Aug 2026 16:40:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388372.1629542; Tue, 11 Aug 2026 16:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtpWH-0007pF-4b; Tue, 11 Aug 2026 16:40:05 +0000
Received: by outflank-mailman (input) for mailman id 1388372;
 Tue, 11 Aug 2026 16:40:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3YVB7agYKCUo4qmzvos00sxq.o0y9qz-pq7qxxu454.9qz130vqo5.03s@flex--seanjc.bounces.google.com>)
 id 1wtpWG-0007bM-6T
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 16:40:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtpWF-00CfYX-Iy
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 18:40:03 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3YVB7agYKCUo4qmzvos00sxq.o0y9qz-pq7qxxu454.9qz130vqo5.03s@flex--seanjc.bounces.google.com>)
 id 6a7b504c-8faa-0a2a0a5109dd-0a2a45039cf6-24
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 18:40:03 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3YVB7agYKCUo4qmzvos00sxq.o0y9qz-pq7qxxu454.9qz130vqo5.03s@flex--seanjc.bounces.google.com>)
 id 6a7b5062-fae8-0a2a45030019-d155d2c5ec51-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 18:40:03 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-848544a8496so79316b3a.0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 09:40:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786466401; x=1787071201; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=1rxRzhkW3E+GRLBK4lU1PGGkM/l3GS9nXng7CK7oPdQ=;
        b=iFb4TgM0doope1zjZ1ISSZoZb5Yj7YA9tgnIZUAoBZ36QvDkrR+WqvKud5etyN6Ecu
         S3Xrfpxcya7dh2bUgN4juNYHqyEPzNTmFiwG+VQl6S4bWmR9nSOX++ChiHSnBKvW+lJu
         VWdDDhaFoyAF+dukZFzdAKqtY/IJQPUi82g//gwvp0HYg6yUNrNzHLipiI8AXj5xhIkf
         1HJN9k6qRHyAjfW7i8pjx9ZGmFBBVFgfoTwSMgeQunBFYQoyUa3K1zaH0Lk17wvT5zwn
         W7kJX0ns2eHnFph7Ht2uZujDeJ5Pacsb7dp5vaFLWiLJU/+8VPcfxJLUKtUhHvOfwdDU
         j/ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786466401; x=1787071201;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1rxRzhkW3E+GRLBK4lU1PGGkM/l3GS9nXng7CK7oPdQ=;
        b=PIkKPY8n0YnIWFl4djRbFLwzy1qtgU/Vy+vE2kR9WWEGezBpxpi5MZlqd0H4arwcNa
         J6e+mhWUZk0rbJiOZHP4OPlo56rS8SV/JLOnGlcYHCt80+K3Fd4gTzKXGXGErtRSwHQ8
         VX3YAWQguANaeX0QHTkOxa0eSTYn9TgTXnK0LsQMEzttWL0987eE5YUjNIUlWEH3NYTl
         1BprqRXi76DgFv23tmxan6V6iORZaGqaYxJKfiAekYzNSHDSFU6WSZGMg+7UjDXEsKbx
         hTSa7JxfsG8ODvtYwPLUds7ZK8S0quhMdJsmcTTa+Mq2VM5ev3eVFXPyH2hVKVvGlvdO
         /R0Q==
X-Forwarded-Encrypted: i=1; AHgh+RqhuNBFvdfM6Si5v8n+EPmNJ3jiedLjldhKKHwq/YPkAZYSN9Z+YAvMeVvznxO1bJVGZ/EsZ3mYfjw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzXOgosu4KiVeqJE19E0lPzX/7aPVs0qDAzhsAuEdnH/lSum+z/
	HCmOnifV6wR8CGqKz550PYSicoEGbeUBL837hJMsMKbkAajO1M44k/2uc4TBfEMMv4tCf0MFLCO
	Eln+/AA==
X-Received: from pfst18.prod.google.com ([2002:aa7:8f92:0:b0:848:8d8a:9463])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:b42:b0:848:30c3:45dd
 with SMTP id d2e1a72fcca58-84fa86e1489mr4667146b3a.11.1786466401012; Tue, 11
 Aug 2026 09:40:01 -0700 (PDT)
Date: Tue, 11 Aug 2026 09:40:00 -0700
In-Reply-To: <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-18-dwmw2@infradead.org>
 <anoOz2rZ02KFk1l-@google.com> <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
 <ano6-gIZtqMfipiD@google.com> <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com> <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
Message-ID: <antQYJvRxJxOjtut@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-33051d/1786466403-6CEDA4E9-E8CA63EC/0/0
X-purgate-type: clean
X-purgate-size: 5347

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 07:33 -0700, Sean Christopherson wrote:
> >=20
> > Actually, why are KVM_{G,S}ET_CLOCK_GUEST vCPU-scoped?=C2=A0 Per the do=
cumentation,
> > the API "Sets the KVM clock (for the whole VM) in terms of the vCPU TSC=
".=C2=A0 If
> > the APIs are VM-scoped instead of vCPU-scoped, then KVM can simply save=
/restore
> > what's in the per-VM masterclock state, no?
>=20
> They're vCPU-scoped because they need to be tied to a guest TSC (on
> live migration, neither ka->master_cycle_now nor ka->master_kernel_ns
> are useful =E2=80=94 those are the "per-VM masterclock state").

But master clock is also tied to guest TSC.

> Theoretically, guest TSCs can be different on each vCPU (different
> offset, different *rate* even. Not that we allow KVM_[GS]ET_CLOCK_GUEST
> at different rates, I concede).

Sure, but not masterclock, and if we're saying that KVM_[GS]ET_CLOCK_GUEST =
is
for migrating masterclock state, then as you concede, vCPUs with TSCs at di=
fferent
frequencies is completely out of scope.

> So they operate in the context of a given vCPU, and *its* TSC.

Yes, but KVM_[GS]ET_CLOCK_GUEST aren't saving/restoring vCPU state, they're
saving/restoring masterclock state, which is VM-scoped.  What I don't like =
about
the proposed uAPI is that it implicitly consumes state, from an arbitrary v=
CPU,
that KVM very explicitly tracks in masterclock.  And AFAICT, there's zero r=
eason
to do so.

E.g. as a strawman, I would expect something like this to migrate masterclo=
ck
state (deliberately avoiding "master" in the uAPI, because checkpatch is al=
ready
screaming too much).  I didn't try too hard to get the math right, I just w=
anted
to highlight that all the state needed to restore the masterclock is availa=
ble
in the masterclock (which seems comically obvious when I type it out).

struct kvm_pvclock {
	__u64 tsc_timestamp;
	__u64 tsc_scaling_ratio;
	__u64 tsc_offset;
	__u64 system_time;
	__u32 tsc_to_system_mul;
	__s8  tsc_shift;
	__u8  pad0;
	__u16 pad1;
	__u32 pad2;
};

#define KVM_SET_PVCLOCK		_IOW(KVMIO, 0xd6, struct kvm_pvclock)
#define KVM_GET_PVCLOCK		_IOR(KVMIO, 0xd7, struct kvm_pvclock)

static int kvm_vcpu_ioctl_set_pvclock(struct kvm *kvm, void __user *argp)
{
	struct kvm_pvclock user_hv_clock;
	struct kvm_arch *ka =3D &kvm->arch;
	u64 curr_tsc_hz, user_tsc_hz;
	u64 user_clk_ns;
	u64 guest_tsc;
	int rc =3D 0;

	if (copy_from_user(&user_hv_clock, argp, sizeof(user_hv_clock)))
		return -EFAULT;

	if (user_hv_clock.pad0 || user_hv_clock.pad1 || user_hv_clock.pad2)
		return -EINVAL;

	if (!user_hv_clock.tsc_scaling_ratio || !user_hv_clock.tsc_to_system_mul)
		return -EINVAL;

	if (user_hv_clock.tsc_shift < -31 || user_hv_clock.tsc_shift > 31)
		return -EINVAL;

	user_tsc_hz =3D hvclock_to_hz(user_hv_clock.tsc_to_system_mul,
				    user_hv_clock.tsc_shift);

	kvm_hv_request_tsc_page_update(kvm);

	/*
	 * kvm_start_pvclock_update() takes tsc_write_lock and opens
	 * the pvclock seqcount; kvm_end_pvclock_update() closes both.
	 * All clock state modifications between them are atomic with
	 * respect to readers in kvm_guest_time_update().
	 */
	kvm_start_pvclock_update(kvm);
	pvclock_update_vm_gtod_copy(kvm);

	if (!ka->use_master_clock) {
		rc =3D -ENODATA;
		goto out;
	}

	curr_tsc_hz =3D (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
	if (unlikely(curr_tsc_hz =3D=3D 0)) {
		rc =3D -EBUSY;
		goto out;
	}

	if (kvm_caps.has_tsc_control)
		curr_tsc_hz =3D kvm_scale_tsc(curr_tsc_hz,
					    user_hv_clock.tsc_scaling_ratio);

	/*
	 * The mul/shift in the provided pvclock structure encode the guest TSC
	 * frequency at which it was generated. Sanity-check that it is
	 * consistent with the existing pvclock information, and by extension
	 * all vCPUs' effective TSC frequenies.  Allow a discrepancy of 1 kHz
	 * either way since independently calibrated hosts will not measure
	 * precisely the same value even for the same nominal frequency.
	 */
	if (user_tsc_hz < curr_tsc_hz - 1000 ||
	    user_tsc_hz > curr_tsc_hz + 1000) {
		rc =3D -ERANGE;
		goto out;
	}

	/*
	 * Calculate the guest TSC at the new reference point, and the
	 * corresponding KVM clock value according to user_hv_clock.
	 * Adjust kvmclock_offset so both definitions agree.
	 */
	guest_tsc =3D user_hv_clock.tsc_offset +
		    kvm_scale_tsc(user_hv_clock.system_time,
				  user_hv_clock.tsc_scaling_ratio);

	if (guest_tsc !=3D user_hv_clock.tsc_timestamp +- ???) {
		rc =3D -EINVAL;
		goto out;
	}

	<fill in masterclock>

out:
	kvm_end_pvclock_update(kvm);
	return rc;
}

> And I think I'm going to defend that 'theoretical they can be
> different', because I *would* like to eliminate the ways that a *guest*
> can force non-masterclock mode, and that does mean allowing the offset-
> TSC case.
>=20
> FWIW in my local tree I've just extended the pvclock_migration_test to
> test precisely the thing you were concerned about: three vCPUs with
> divergent TSC offsets, migrated by setting each vCPU's TSC and then
> invoking KVM_SET_CLOCK_GUEST once, through vCPU0.=20

I wasn't actually concerned about migration, I was concerned about time goi=
ng
backwards from the guest's perspective.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 17:18:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 17:18:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388385.1629551 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtq7N-0004qx-Sj; Tue, 11 Aug 2026 17:18:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388385.1629551; Tue, 11 Aug 2026 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtq7N-0004qq-Pb; Tue, 11 Aug 2026 17:18:25 +0000
Received: by outflank-mailman (input) for mailman id 1388385;
 Tue, 11 Aug 2026 17:18:24 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtq7L-0004qi-9Y
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 17:18:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtq7H-000vrt-9B; Tue, 11 Aug 2026 19:18:19 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b5949-2eae-0a2a0a5409dd-0a2a4503b2b0-16
 for <multiple-recipients>; Tue, 11 Aug 2026 19:18:19 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b5959-fae8-0a2a45030019-5a9b32229468-3
 for <multiple-recipients>; Tue, 11 Aug 2026 19:18:18 +0200
Received: from 54-240-197-235.amazon.com ([54.240.197.235]
 helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtq75-00000000l9e-1Ota; Tue, 11 Aug 2026 17:18:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=yabOVscRtLsJ60EcC+RTYQeed7LX9IVuCx/CQSf7Yo4=; b=ZDXi7rQNBsLe/Fy7S1rXTgOeNK
	TNdcKg8GGTMPvy3ojzbCTsDah366jjbrqurq6/0hPOVAU23O4xaT8uwSJ32yhKGit+t4ckFJtaw6t
	pSZL94DFi8foAJdSsFrbjvKqR0ZTgHShBWuw43ro/MnKpBUOuryTfXEGMZWfaDQ62VBDVFk+aJivU
	yAKYjRa9BXShODtL1rRMqRojXeZNjQcf1QxtnswodmRH0cYME/oSG374xjx5UWdnkQrRVGKs2PteF
	G69jYW9xZfNfNaSsuaG/HpZaWJkV6MbqU/wTiqLxBNgNCBQFZVYFPTbGc7QSvvzqpCLht4rLiFIci
	OTFTKCwg==;
Message-ID: <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Tue, 11 Aug 2026 18:18:01 +0100
In-Reply-To: <antQYJvRxJxOjtut@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-18-dwmw2@infradead.org>
	 <anoOz2rZ02KFk1l-@google.com>
	 <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
	 <ano6-gIZtqMfipiD@google.com>
	 <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
	 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
	 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
	 <antQYJvRxJxOjtut@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-UW2XW6iDoT/p3pb+WhA8"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-33051d/1786468698-6CCDB4E9-E1900AB7/0/0
X-purgate-type: clean
X-purgate-size: 9661


--=-UW2XW6iDoT/p3pb+WhA8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 09:40 -0700, Sean Christopherson wrote:
>=20
> >=20
> > FWIW in my local tree I've just extended the pvclock_migration_test to
> > test precisely the thing you were concerned about: three vCPUs with
> > divergent TSC offsets, migrated by setting each vCPU's TSC and then
> > invoking KVM_SET_CLOCK_GUEST once, through vCPU0.=20
>=20
> I wasn't actually concerned about migration, I was concerned about time g=
oing
> backwards from the guest's perspective.

But KVM_[SG]ET_CLOCK_GUEST is *purely* for migration. And your variant
just added a dependency on wallclock time back into it again, where
wallclock should *only* be used for setting the TSC, and even then
*only* for a live *migration* to a different host, not a live *update*
via kexec/KHO on the same host, where the TSC should be restored as an
offset from the host TSC.

--=-UW2XW6iDoT/p3pb+WhA8
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTExNzE4MDFaMC8GCSqGSIb3DQEJBDEiBCAIXZj3fS22GJnbcx4L55gAK/Z034W2
Xq47EfytMPzvyTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAkck2WAbbnpNl02GPNPwoRRn2HVjNp/+Z0svDg+ArwhpHYwmMbQey
FSeL6L953UShQgnoo5y+CKOzP2DaAzbCh64aouy693nTq2HidDX3ogMyZbAc+i4NmS9r93yAYDFA
Yi0O9pF0Dfpsewa3zBjLgg4L92GASzbl1ApTqskSXALOWyNltZRoGrFh8Jlp1ZmbfH2keoS97F+7
Esf9rC3aZhGZ9G08OS74wOefactcYL5beFOVBgeYE6w6+Rn4TsR2PB3577z0KWRcN3voMs/Ia22F
K49IaMlabNVcJGhnm26A0XG4pav7OWhnJcbyyZevGD7H8T66776u93CgRBo+s4hj3eEGOt0ukeE3
ImzrhdulTw9E4Mv6u7e8pMELl5D9gtqvmXJwhKA94zlv4zIhlMhLIcrkqDxQAdLOE+rCrfgzgxxO
zoxm9iN0pbP8bMW0HLvdpArLuBZNula1bFFHanSEQaSMj08ntrdeoYg/Mgg8ebBHYebB6hJ4ojNQ
Lftedo1tXmsHqG8NSYRoRXhVvXjy5QpZR8pCLLbVibKgRKUQin188GBdTvhLlH3uxBon4esYHfxV
U2aKXJXb50ZrQCh5fBr/tvKTOYgK6xScbR390BukgTPlPpDsvbG30PwTj91vY5Dwi3n4qMzWSlFa
3jt9KdG+cqxHq/ln6zoRp+IAAAAAAAA=


--=-UW2XW6iDoT/p3pb+WhA8--


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 17:29:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 17:29:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388398.1629560 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtqHY-0006px-Qd; Tue, 11 Aug 2026 17:28:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388398.1629560; Tue, 11 Aug 2026 17:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtqHY-0006pq-Mt; Tue, 11 Aug 2026 17:28:56 +0000
Received: by outflank-mailman (input) for mailman id 1388398;
 Tue, 11 Aug 2026 17:28:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <301t7agYKCdIG2yB704CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--seanjc.bounces.google.com>)
 id 1wtqHW-0006pk-V1
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 17:28:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtqHW-000nlV-Ba
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 19:28:54 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <301t7agYKCdIG2yB704CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--seanjc.bounces.google.com>)
 id 6a7b5bd4-2eae-0a2a0a5409dd-0a2a450ccb8e-2
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:28:54 +0200
Received: from [209.85.214.199] (helo=mail-pl1-f199.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <301t7agYKCdIG2yB704CC492.0CAL2B-12J2996GHG.L2BDFC720H.CF4@flex--seanjc.bounces.google.com>)
 id 6a7b5bd4-f479-0a2a450c0019-d155d6c7c082-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:28:54 +0200
Received: by mail-pl1-f199.google.com with SMTP id
 d9443c01a7336-2ce8a76df2dso2289095ad.2
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 10:28:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786469332; x=1787074132; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=kMDt/Sj6YjXvFiWQr62Lu+RNKL1NV+pa3PqCNwc1t5I=;
        b=GQoy05yVlVVZhRt7DEV/1JSGbRSOEVtEaYWBRv7w7tfB0+k0eOa5ia+wQLmnJY8qdY
         POmBroRg1thoPUgK4LUNldRzDx50Nn0l4IZ3tb6ESFm79ZrLYAbSzZvxdRiJU+iBzNOw
         0Kiaz1eKXyd4vaGvIG7+ZfOU/8shLMmx014TzKJ8+hNoteXGBZ15GOpFU9dTnYEYvYh1
         kRv5yByNPIIHSngv14ciFNsEdtlR1kfJMtd5tCs8FSnDmA5QKTCJP22FnhuJI0wKdB3q
         yrcglzUTaWXS2GcDT2NbmVWEKu29suC0wmVVTDMFaz+n3lIrgec8m+oNIp+Luzm3JOje
         si2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786469332; x=1787074132;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=kMDt/Sj6YjXvFiWQr62Lu+RNKL1NV+pa3PqCNwc1t5I=;
        b=HgE0/zyB1fat9dEAstwbHyjpwmBOhoPRTCgm9OTVOOcCxASXl0/GFl1CEEuQh5sJxC
         8rTxqDMsSZmWuGmVBRAEjRVmq4fkSfLDMoP1oCtgnF82b28o/RmWfeIjqpFYzzqINw4h
         hKWHfbYinL/nT7Yc2joY1zUQyHga1pyVJADcOaEeWZSRl7EJVb3/8fZRP+Ca7+feRcLb
         Se3o6h7FOGyuMHWVdQN0dfR2XqE90wCXHB2gRGuWDovQcX/eYBOx30iD1xMT29nSWBU3
         uuB02E8QZRDjstF/Fso8gTQQE5aVEejwaIa7ilNP1iG2ZJ2OiNOcyrXBjx2C/kjmR0qG
         7P3w==
X-Forwarded-Encrypted: i=1; AHgh+RrRBs2djBKYV2UgKC2i/udChumepn1pvs6Nf9cXIQZySTqJxt1wtgnrG7nexEfxI+nYNR5fd1B9HcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKgkGCw4HMZRQmsMzQ+OEOisLOOMSikch4wPuNMA9h/GmI9+nA
	0Ia9p7g/Ar7ADS7tnIURyT6KuD07iwRJ8hNRJVC4HUdMEOB7yrQImjkS6t4iSCfI2cdQ29qOdrr
	HnRgKAQ==
X-Received: from pleu12.prod.google.com ([2002:a17:903:41cc:b0:2cb:97d4:2e28])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:350c:b0:2c9:bf82:dd11
 with SMTP id d9443c01a7336-2d3177f6e83mr61151075ad.7.1786469331912; Tue, 11
 Aug 2026 10:28:51 -0700 (PDT)
Date: Tue, 11 Aug 2026 10:28:51 -0700
In-Reply-To: <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-18-dwmw2@infradead.org> <anoOz2rZ02KFk1l-@google.com>
 <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
 <ano6-gIZtqMfipiD@google.com> <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
 <antQYJvRxJxOjtut@google.com> <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
Message-ID: <antb01WqOrs-tztm@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-d25034/1786469334-018C5A5B-48B8C25F/0/0
X-purgate-type: clean
X-purgate-size: 2978

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 09:40 -0700, Sean Christopherson wrote:
> > 
> > > 
> > > FWIW in my local tree I've just extended the pvclock_migration_test to
> > > test precisely the thing you were concerned about: three vCPUs with
> > > divergent TSC offsets, migrated by setting each vCPU's TSC and then
> > > invoking KVM_SET_CLOCK_GUEST once, through vCPU0. 
> > 
> > I wasn't actually concerned about migration, I was concerned about time going
> > backwards from the guest's perspective.
> 
> But KVM_[SG]ET_CLOCK_GUEST is *purely* for migration. 

Huh?  I raised my concern in the context of "Allow KVM master clock mode when
TSCs are offset from each other", and AFAICT, nothing ensures that won't cause
problems.

Aaah, it clears PVCLOCK_TSC_STABLE_BIT and relies on the guest to clean up the
mess.  So the guest won't see time go backwards, but it could see time stop for
an extended duration, or jump forward.

E.g. if tsc_timestamp is set to a per-VM value, and vCPU0's offset matches the
effectively offset, but vCPU1's offset does not, then vCPU1 could see time that
is either far in the past or far in the future when doing __pvclock_clocksource_read().
If vCPU1 computes time that's in the future, the guest would see a potentially
massive jump forward in time.

And after that, or if vCPU1 computes time that's in the past, if the "future"
vCPU stopped running, the "past" vCPU would see time stop as last_value would be
ahead of the "past" vCPU's current time for a very long while.

	if ((valid_flags & PVCLOCK_TSC_STABLE_BIT) &&
		(flags & PVCLOCK_TSC_STABLE_BIT))
		return ret;

	/*
	 * Assumption here is that last_value, a global accumulator, always goes
	 * forward. If we are less than that, we should not be much smaller.
	 * We assume there is an error margin we're inside, and then the correction
	 * does not sacrifice accuracy.
	 *
	 * For reads: global may have changed between test and return,
	 * but this means someone else updated poked the clock at a later time.
	 * We just need to make sure we are not seeing a backwards event.
	 *
	 * For updates: last_value = ret is not enough, since two vcpus could be
	 * updating at the same time, and one of them could be slightly behind,
	 * making the assumption that last_value always go forward fail to hold.
	 */
	last = raw_atomic64_read(&last_value);
	do {
		if (ret <= last)
			return last;
	} while (!raw_atomic64_try_cmpxchg(&last_value, &last, ret));


> And your variant just added a dependency on wallclock time back into it

Can you elaborate?  I'm guessing I don't entirely understand what you mean by
wallclock time.

> again, where wallclock should *only* be used for setting the TSC, and even
> then *only* for a live *migration* to a different host, not a live *update*
> via kexec/KHO on the same host, where the TSC should be restored as an offset
> from the host TSC.




From xen-devel-bounces@lists.xenproject.org Tue Aug 11 17:32:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 17:32:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388407.1629570 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtqLL-0008QO-Ef; Tue, 11 Aug 2026 17:32:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388407.1629570; Tue, 11 Aug 2026 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtqLL-0008QH-9u; Tue, 11 Aug 2026 17:32:51 +0000
Received: by outflank-mailman (input) for mailman id 1388407;
 Tue, 11 Aug 2026 17:32:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtqLJ-0008QB-RH
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 17:32:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtqLI-000oUg-Hp; Tue, 11 Aug 2026 19:32:48 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b5c9b-2eae-0a2a0a5409dd-0a2a4501c90e-44
 for <multiple-recipients>; Tue, 11 Aug 2026 19:32:48 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b5cbf-5984-0a2a45010019-5a9b3222d9fe-3
 for <multiple-recipients>; Tue, 11 Aug 2026 19:32:48 +0200
Received: from 54-240-197-227.amazon.com ([54.240.197.227]
 helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtqL8-00000000mOf-03wa; Tue, 11 Aug 2026 17:32:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=xUaudyzVAtVFOAuHuBOLpN0ePfnJcuF2YmB5H+89s4I=; b=cZDoMmysvO74lse4HqJleIEcXx
	jQnZBMP0Tt1sU4mZUrgKQrd6OZgh3FMwOMMFFjDIYnukxFmiFdqOEDMpN/X9qKDr9XZd7Z2eYFKET
	oPAp1t/0tfPbVnjRPccy9HnS3g3NjJpMb3Ief3wWtY4zbQdHRszuDzxKoPpX7nMIxf2COoDdoD8+W
	VXquRd3kXXUqXcHYExoszvR1fomIkkCM/tMs7yRqoxkREllvkRVZPlRSOL0PgXMMjvCVQ/ctXAAWI
	rFplhQKoyge1icaZ0l1XJh+NsCb/uf0sK+NBu98qy/erlOWMUj4ZfwX3JuwVb5UPebUHVPwRBTmV0
	3m9fvfQg==;
Message-ID: <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Tue, 11 Aug 2026 18:32:32 +0100
In-Reply-To: <antb01WqOrs-tztm@google.com>
References: <20260728144954.355376-18-dwmw2@infradead.org>
	 <anoOz2rZ02KFk1l-@google.com>
	 <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
	 <ano6-gIZtqMfipiD@google.com>
	 <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
	 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
	 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
	 <antQYJvRxJxOjtut@google.com>
	 <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
	 <antb01WqOrs-tztm@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-MMosgLFBG0M8t4KcrasE"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-d62444/1786469568-BFE68757-C8966BC1/0/0
X-purgate-type: clean
X-purgate-size: 10417


--=-MMosgLFBG0M8t4KcrasE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 10:28 -0700, Sean Christopherson wrote:
> On Tue, Aug 11, 2026, David Woodhouse wrote:
> > On Tue, 2026-08-11 at 09:40 -0700, Sean Christopherson wrote:
> > >=20
> > > >=20
> > > > FWIW in my local tree I've just extended the pvclock_migration_test=
 to
> > > > test precisely the thing you were concerned about: three vCPUs with
> > > > divergent TSC offsets, migrated by setting each vCPU's TSC and then
> > > > invoking KVM_SET_CLOCK_GUEST once, through vCPU0.=20
> > >=20
> > > I wasn't actually concerned about migration, I was concerned about ti=
me going
> > > backwards from the guest's perspective.
> >=20
> > But KVM_[SG]ET_CLOCK_GUEST is *purely* for migration.=20
>=20
> Huh?=C2=A0 I raised my concern in the context of "Allow KVM master clock =
mode when
> TSCs are offset from each other", and AFAICT, nothing ensures that won't =
cause
> problems.
>=20
> Aaah, it clears PVCLOCK_TSC_STABLE_BIT and relies on the guest to clean u=
p the
> mess.=C2=A0 So the guest won't see time go backwards, but it could see ti=
me stop for
> an extended duration, or jump forward.

It shouldn't. Each vCPU gets its *own* pvclock structure, tailored to
*its* offset. They should all see *identical* results.

But yeah, if the guest does that then we can't set the
PVCLOCK_TSC_STABLE_BIT.
>=20
> > And your variant just added a dependency on wallclock time back into it
>=20
> Can you elaborate?=C2=A0 I'm guessing I don't entirely understand what yo=
u mean by
> wallclock time.

The system_time field? The unspecified might-be-UTC-might-have-leap-
seconds one :)

--=-MMosgLFBG0M8t4KcrasE
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTExNzMyMzJaMC8GCSqGSIb3DQEJBDEiBCDLmWKR5XkL6sefsbDpYKfsnZbbkhs4
yIp/MgM26OOFBDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAi75ovcT27uw808LsfAeI4l5fdIAKm/FPJDHXToP/2JK+juzwU/sK
uo1KXvyTgEfSmN0qxwg3IqKunBkEJWUq7VCHoUjmFJ3118FWgnhoCJZgktEu+CTDld19y9h073l4
vxPZySwiSK74gqTUoit8pnjfiQhKbfA3Ka8w812sBxfuM8nk2Bkz5Fpr8pKXlTzvD4s1hZ5f0/ui
NzCrHB5XV5yA7ySidwx4opmlW14u7xDPYZv/PJ/fxyjDZAt9LThzYDRZX7DPuiyS2cEJeGQRgI+L
rMkzTKnIXK61L6AKqfmjvQXJsgb3lg/K4zPehGEnJhRihW2GzeSmCXFfRqRBWywTl9Wq9eexCEec
iP0M0A8Bgd5/vIOZFhO4R5a7HrFW9kezEIGk3zPR5+5/Jb8HTE21WhZ1NHN2ziFc7ZFY+aPklIPO
bf7whTQNXAGAk5zZ1HKsbNQbvg6WLQTu3TpX2av7Qh1Lo6ettKbc9xR3YTxFusBogWXNvXjFmFux
J7Qaa6wn3s+vMxtNRuk0YribtuRvcbhwyRJpvF0oFyRq5FuQ4nKnCUCv3cVIJw6CUYmMp++fU5l+
6sgKs/mPgx09kiodiyXRo72nYfknyri/Z/HkVVF/Y7IcjA/83tcgLX3DntfT+Zjj7UnnoXj+iVRN
+ZrnRTsL4E76XrA+yjhtS44AAAAAAAA=


--=-MMosgLFBG0M8t4KcrasE--


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 18:42:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 18:42:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388435.1629578 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtrQ0-0001VB-5E; Tue, 11 Aug 2026 18:41:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388435.1629578; Tue, 11 Aug 2026 18:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtrQ0-0001V4-1c; Tue, 11 Aug 2026 18:41:44 +0000
Received: by outflank-mailman (input) for mailman id 1388435;
 Tue, 11 Aug 2026 18:41:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <342x7agYKCQYykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 1wtrPy-0001Uy-Kj
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 18:41:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtrPx-00CtZ6-Og
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 20:41:41 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <342x7agYKCQYykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 6a7b6cc1-8faa-0a2a0a5109dd-0a2a4507bc5c-16
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 20:41:41 +0200
Received: from [209.85.210.199] (helo=mail-pf1-f199.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <342x7agYKCQYykgtpimuumrk.ius3kt-jk1krroyzy.3ktvxupkiz.uxm@flex--seanjc.bounces.google.com>)
 id 6a7b6ce4-b4ea-0a2a45070019-d155d2c7bca8-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 20:41:41 +0200
Received: by mail-pf1-f199.google.com with SMTP id
 d2e1a72fcca58-848d21bbb55so290973b3a.0
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 11:41:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786473699; x=1787078499; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=fJOzqFK/vfJSw1ado9uoaagkeuADN2fLa/8s2FkuGPk=;
        b=inzUb2pIGixCuZQ6srCLxR8knMdOLzFg7fWEDT2kx83KyRG8nmjoV58pwVm0W8P3gY
         S1J5f+i3vpaFiDlxSiXa6z6KRZy4wvGn2J1j4P4mLKEmjo+UhEUH26KFH1Yf2QoyEFhj
         /Dn/cfftinBuPITSibSYaefhtoxlO3vkV/YH13IuchaSPhpjCZHPoGgu5jjd9efT3F2i
         HYwpmSoHjRD2nYV1BA/1ywDEQgbdcx2xV+tPwF3YlbyI2rRUiH7Y84FJEtN5YsXwjopS
         kzzCvOWqrhv1eQ8JMfo0fdYZRVkVgSb3V0TngbDZwHZHlq6vNbHbBBxO5dQxAm08dn8M
         IkRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786473699; x=1787078499;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=fJOzqFK/vfJSw1ado9uoaagkeuADN2fLa/8s2FkuGPk=;
        b=hdkVs32Meb9S+llZrxkDx0dOdSc8FPhWfpq0DzWVO6OWGbGmSsmReu7V17+Y1tQu/P
         UpIgZKzkJw/0Shcr1UjRnQRyAq2qucHuagWj2LME+Xqy2ztqWPi5Cvq2JwIjOGHDbJzt
         BY0QBub55MkxGOhzuh3kb3XcybL07fKE7nSvjDsilVILBpJWjLmo+kjZtdowd/uP70hV
         rrf1rM3LUcguJ1EBIkRE1Vj5dMiG5dkXuhCY9uzyZsRmRJkN8VwN+h05bvKlZrmwdaBh
         tdMTx0YcK+6d3R3rgXi3+dYbQlzoFlT6vd8QE+4OrjFQ6GE9MxdcsKCsN38pKJZNWtbC
         zfdg==
X-Forwarded-Encrypted: i=1; AHgh+Rrd52zgiKJNbowc2EWfRSwu5YStF3WcZHY1jujGs9BCDeLOFIh8jqOM/Z4mCDiWWXvswEXUqOWyEDA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzB19O6gbOSCywJYBfJ8MUwfK5dtaLvPS4GoZlufhDAYw4t2kNH
	IMa6hRN+SEkw2kaKyglJLPS6+2uQYNjumMVf98nDBdZ/G4EO2x4diTS6cZpoZyuH1XbHuPSGEsG
	d+coC1A==
X-Received: from pfbih2.prod.google.com ([2002:a05:6a00:8c02:b0:84e:530a:923a])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2355:b0:848:2c6c:dfe3
 with SMTP id d2e1a72fcca58-84fa86c28d9mr5596667b3a.17.1786473699196; Tue, 11
 Aug 2026 11:41:39 -0700 (PDT)
Date: Tue, 11 Aug 2026 11:41:37 -0700
In-Reply-To: <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
Mime-Version: 1.0
References: <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
 <ano6-gIZtqMfipiD@google.com> <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
 <antQYJvRxJxOjtut@google.com> <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
 <antb01WqOrs-tztm@google.com> <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
Message-ID: <ants4VjfAiblaWsl@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-ef75cf/1786473701-376D2AE4-FA9516AF/0/0
X-purgate-type: clean
X-purgate-size: 3744

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 10:28 -0700, Sean Christopherson wrote:
> > On Tue, Aug 11, 2026, David Woodhouse wrote:
> > > On Tue, 2026-08-11 at 09:40 -0700, Sean Christopherson wrote:
> > > >=20
> > > > >=20
> > > > > FWIW in my local tree I've just extended the pvclock_migration_te=
st to
> > > > > test precisely the thing you were concerned about: three vCPUs wi=
th
> > > > > divergent TSC offsets, migrated by setting each vCPU's TSC and th=
en
> > > > > invoking KVM_SET_CLOCK_GUEST once, through vCPU0.=20
> > > >=20
> > > > I wasn't actually concerned about migration, I was concerned about =
time going
> > > > backwards from the guest's perspective.
> > >=20
> > > But KVM_[SG]ET_CLOCK_GUEST is *purely* for migration.=20
> >=20
> > Huh?=C2=A0 I raised my concern in the context of "Allow KVM master cloc=
k mode when
> > TSCs are offset from each other", and AFAICT, nothing ensures that won'=
t cause
> > problems.
> >=20
> > Aaah, it clears PVCLOCK_TSC_STABLE_BIT and relies on the guest to clean=
 up the
> > mess.=C2=A0 So the guest won't see time go backwards, but it could see =
time stop for
> > an extended duration, or jump forward.
>=20
> It shouldn't. Each vCPU gets its *own* pvclock structure, tailored to
> *its* offset. They should all see *identical* results.

OMG, I hate this code.  After literally hours of staring at this, and even =
typing
up a lengthy example of why guest time would go off the rails, I finally sp=
otted
that l1_tsc_offset is accounted for by the call to kvm_read_l1_tsc().  FML.

Thanks for being patient and not flaming me too much :-)

> But yeah, if the guest does that then we can't set the
> PVCLOCK_TSC_STABLE_BIT.
> >=20
> > > And your variant just added a dependency on wallclock time back into =
it
> >=20
> > Can you elaborate?=C2=A0 I'm guessing I don't entirely understand what =
you mean by
> > wallclock time.
>=20
> The system_time field? The unspecified might-be-UTC-might-have-leap-secon=
ds one :)

Ok, I think I finally understand the goal.  I got turned around by the comb=
ination
of the name SET_CLOCK_GUEST and the full pvclock structure being passed to =
the
guest.  I was expecting SET_CLOCK_GUEST to literally set the entire clock, =
e.g.
mul+shift, timestamp, etc.

But all of that metadata is just a means to an end: the one and only goal i=
s to
calculate the per-VM kvmclock_offset for the "new" host's TSC+time snapshot=
, by
computing the nanoseconds delta for the new snapshot as if it the guest obs=
erved
the TSC while running on the old host.

And that is done in the kernel instead of in userspace to minimize the amou=
nt of
slop introduced due to delay between taking the snapshot and computing the =
offset.
And for similar reasons, it's undesirable for userspace to redo the GET on =
the
target to compute the explicit offset, because there would be a massive TOC=
TOU
issue, e.g. if KVM took a new masterclock snapshot between GET and SET.

After working through that, I feel quite strongly that we should have asymm=
etric
names for the GET vs. SET flows, because the actually functionality is also=
 very
asymmetric.  And setting a field, and only that field, that's doesn't have =
a
direct association in the userspace payload is very surprising when the nam=
e of
the ioctl suggests a restoration of the entire payload.

E.g. KVM_GET_REFERENCE_PVCLOCK and then KVM_SET_REFERENCE_PVCLOCK_OFFSET?  =
Or
maybe UPDATE, CALCULATE, REFRESH, or COMPUTE instead of SET?  I think I'd v=
ote
for SET even though it's convoluted, because pretty much everyone associate=
s SET
with the restore side of save/restore.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 20:57:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 20:57:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388579.1629588 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wttWn-0003B3-82; Tue, 11 Aug 2026 20:56:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388579.1629588; Tue, 11 Aug 2026 20:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wttWn-0003Av-2S; Tue, 11 Aug 2026 20:56:53 +0000
Received: by outflank-mailman (input) for mailman id 1388579;
 Tue, 11 Aug 2026 20:56:52 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wttWl-0003Ap-EG
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 20:56:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wttWk-00C9Zw-Jq
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 22:56:50 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7b8c68-2eae-0a2a0a5409dd-0a2a4509c774-22
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 22:56:50 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7b8c91-be1a-0a2a45090019-94a38ff19fd4-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 22:56:50 +0200
Received: from pps.filterd (m0367130.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BJJn0M2001468
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 20:56:48 GMT
Received: from bl2pr02cu003.outbound.protection.outlook.com
 (mail-eastusazon11011026.outbound.protection.outlook.com [52.101.52.26])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4g09ba9du8-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 20:56:48 +0000 (GMT)
Received: from CY5PR13CA0020.namprd13.prod.outlook.com (2603:10b6:930::28) by
 DS5PPFB94A44349.namprd16.prod.outlook.com (2603:10b6:f:fc00::7e2)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 20:56:41 +0000
Received: from CY4PEPF0000EE34.namprd05.prod.outlook.com
 (2603:10b6:930:0:cafe::72) by CY5PR13CA0020.outlook.office365.com
 (2603:10b6:930::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Tue,
 11 Aug 2026 20:56:34 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 CY4PEPF0000EE34.mail.protection.outlook.com (10.167.242.40) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 20:56:34 +0000
Received: from pps.filterd (m0426318.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BJLfCS3908633
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:56:33 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4fxjw5bgvk-8
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:56:33 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id ttWQwfPJzl3RSttWRwAbBm; Tue, 11 Aug 2026 20:56:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=fail header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=IpF
	aWXCS8wKrFCAJX7TdF+E6dLgoZO2PmKlN5PHgGG0=; b=izET5PSllWR/YnY6o3D
	ZEl1/PALRKXoOV8Ljkfah/KB7Ac2Uc52CNSYmzA2X+qG0374t02s+HqUR0JwOjVH
	YRGUkgzw2GDhC4VLoIYVogKFFGD7SErw3rLFk/oUJSQIeMeYqnP6XXnSVvFYiaWU
	9GJOoAe4Eux8xGg2bi84O24gx5zZRIF2OICnuCc0CLOmOqygy2sx41S7J2okK9/w
	Iumb+aQZExb0bdhyu7E4Bv38k/S1Kyv/ab4SbaZYp34/2/xvGs7XlshlAtCnUOvp
	auuIOIlTlxymBxGDx94yXLdFTOKaMDMF7gRL0DQJzvIPl9JCBbLOTsBtKPQrBsyy
	IkQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QJoOPPTQDT/Rh5naPIfHi1ltmGlTuhYVl9R/r7OsTimr+nEmQnehQaAyqQ31ucJdAIMvsTzknmvRc+DmdcR0lGRfWYoXEovYPNSw9974mRt1gLeA52am2Vj0d+wEj9jVsWjEUXbbsuxZ9dSfCE2TIUEhl/PiDbzbWQpyN5uqO8qPDJK40Vun3WODTCS9xM9RN7vj1ANXNoSf5fjFk6C1c9vuhyhDoS5L691YZJ2SRro4JAHhs33+QZ26c/bHYoHxwO91BCh+ipFbjTrq96GqEJYFZDD6/jNt4zM/8Wq+KbFoZAL0BmmNatLDWWDxM+tDdEcA90f7c1/no1o4z1+q3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xaJSCv2lEXMaKDFwipG2L6SrodZaW09V9uuUK67N/dc=;
 b=voS6uiKb3XaJwLynr2rMmEVjKGzoPkL7NYUDMiMMXDC0J/OEqPI8dctiSx9lfiu6oXOX83MQtdeFG6dj3UTmOVAn/Ys+Xumr6CgwJOMud+9XoVnmLjUlUQKpjrmYdyzsbeGzuGxg9UWl5OuSNvNlY6JP5cJ7DmbfOcTgEuI0XO2Q99oKs6GsTjnRU63Sn31Eg4BhqI9+olt//uAOCZ+3x7hlYfASoaSDcbmA6s484wm086tDAbzpyYC35K0+l3hsHkLwlU/+VMe96pK0FmyK1CWn0BzScL7mKqGdFXClHETA0uCu0xixOh7/kZzhYRNiD5u2CRSjcUv+EZrZlduu8Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xaJSCv2lEXMaKDFwipG2L6SrodZaW09V9uuUK67N/dc=;
 b=QrXvJ8czFuON7dpdgzWukIp+GAhrF98wkzMLxYpGH0PYTcHyDDG5JKg7a4sPrx6xa4oAcNE2JEzLTGw6OCyPXl3Q486/PWqrdDxvOrFtKpHnByUGXM2j/du9/cXtVTGhEjZCPGj4K2pZmzvf0AYHyvpaSCZylXKgC9k0W4IaX9s=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to; s=ppserprodsaar; bh=IpFaWXCS8wKrFCAJX7TdF+E6dLgoZO2
	PmKlN5PHgGG0=; b=KYrRV3V0u1gXenMVXpjm8wdHwToNsP/2Jc0A2+buzA25kGb
	PkE1iVVzH5hNV7EYlyXzu/fyU+YCyAANBGOfP9lfS4XE2VYs4Bp/LHLyUq+u0niS
	G9cfz3qJojbm8aPe0X017urXdWkgWlWMbZ9UaB+JKiKv9W38UCDiEuXVysNFzSiY
	h5Z3hxFIe/jk/1YqwWSUoW1CNyV+qL4JEI1fZWisGLQCY9yGU4CO0u3PFms2MVSN
	d51ICdTnqXT4cqNWysMw43OS7BLQE/oKznKQjGk6PVMAToZTgJzEjiQtN1JKT1xZ
	1PiUbcgrzPOh6/m4hyP6mGVeaaKkW1aRzJ5AYqg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppfserpocford;
	 bh=IpFaWXCS8wKrFCAJX7TdF+E6dLgoZO2PmKlN5PHgGG0=; b=Iw1dqGq4QgT8
	kFcFxHF9hqjln4bLWu5OxtT18K5bBBF7KIdc1HVfrQqB3332P4fs0dhmjBdursME
	opuvhBO4arcWZhLY/aI/cBI3Szq85+X0NbdcITtjLQBoeeKtHHfjHK9n+wEGt3uF
	PUfVfcibiXGkqD9tjhFlNt+OIxTl30pNFs7cnjqzMQ+ZkgulMwfuUDMw8xOplPRa
	RswsEYlbLoOxuLsCLJ4sYj1gq6E/FyTkvPfA/j1imLzB5+97D68cT1QGDKRI9vTE
	tJcAI4lRBVkpJY7b3ukdmjpNcgsX79vaIpQHXR3pST+33KgdjxJigkE8scnt7fS8
	EWrsZniwtA==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: ttWQwfPJzl3RSttWRwAbBm
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Tue, 11 Aug 2026 13:56:30 -0700
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
        andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com,
        sstabellini@kernel.org
Subject: Re: [PATCH v3] xen/common: add keyhandler to show Xen command line
Message-ID: <anuMfq/lDjxbR8Om@kraken>
References: <20260810230359.671587-3-dmukhin@ford.com>
 <anrXvTfBls4flBqK@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <anrXvTfBls4flBqK@macbook.local>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_05,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 suspectscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 phishscore=0
 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound
 adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608110176
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE34:EE_|DS5PPFB94A44349:EE_
X-MS-Office365-Filtering-Correlation-Id: db1e8af5-37af-47a6-d463-08def7eb073c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700016|376014|23010399003|13003099007|6133799003|10067099003|4143699003|11063799006|56012099006|22082099003|18002099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	0Iod4o0OXz0Z0KHnKNSnTGIzVax7RO4/o8VuNcRKKoveEsLPmXYO0jiOmzfs/asYjDLIguhQrtzN3eDBwmMnveR0oK7EK075o2z25Ii/OiGXlfEHCMcYRR73CYgfxaUR8NQv2v7wFUiRtcT9b5FWrfgw+Ol0TWFegbAEXnOzoEFpRUT4cLlhDOOhssaLAmGeeJfEx2f8wrsVWNNt26eAB6aa3rDlA5NOKWVZI3Vr/HjnUCHEPZ2wNszJfXP6IKFBIBpRdhyUpe+DoavkO+h4SlGsg3+NRIgQslmfA5up7ay+6nzOjkLwhH3MpUd1lfDUz20VoAyEGBiyYpvVbl3iZVzxmNeglwFUtNE8xfA76Wf7TA4E4WJ68fCUS3xpseNuUsjKmTSKlBgrV+aZa6ME4gYQh3GoUp14ZHWp1mjgJlw0zFRiVzSPqVzoqnTuEDVPSXJc7FFB4zJSNXELGBOgszChHwT5FbLByfRwzZpPSuTJsNxQP3N03c8upsXgCPdAEn7i/8vhpupdSvv9zL6Hjr8F5f1iPq9Iea3NUTVEAmtGQazTsAJWedYCZMaz5koXF+iQsHL9h09juMC6OWGyLUD21Lopw6bUsOA+PjJ2AP/XifGODTf/Is8X2K/76ClMUYJcvoZAEmXXuhpsG8Jp+9jnhvAJnTNcDyw0e7xc/sw8n2czdjoJVxqyozLuMg0OaNncVSoBRKTZEJ+7ZjByYw==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(376014)(23010399003)(13003099007)(6133799003)(10067099003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	J6MpSU20onwor5Xl5d0AVzSHMl8AfVm0ornQ0hn+M0AA9POmCO8Y0IEvp4pATbVXE0TgChTrHF5mAhDyFV73xsD66wmB3t5pGpkTmIONYArktpcBX7qlu+6D1v0KIj9f/x1uzu4bWLRr8USHfxsR8a+uS6uxY4yWL+v7YMQlBVORB80z1RtkbgcN5OY3LQ0X1XLxQt95H5ZMDdzw+UWYrYgWETHFCtFkMNGt+HCQp7+qS21W9KCNroElg7bRCp/oJhBrzIyi+SN3q+Nj+D04D6mJMrGGLcZquvSEianhlHJbCmjWo1/2wKQNdIiFZQaeooeN90Ycqyd700jqYzIRhpjVFE6P7OTjxEhR3m8xHpeQ/JlD18GvV6/Jxs2ZpV5mjlB8I1g19mXOsOUmL0dIjx0J0FI/WHu1iRBfLbUFBZ5wHexsR6eBuVa0jMUTgX89
X-Exchange-RoutingPolicyChecked:
	qh4fB8KPIecNkOqEsqXzsaprcXL9g4bHijGGs4u3kX9lzZGlYHbXBXe4ymqrdPWyozB3ukPzaoQTR3DfsYlDo1Djt85VfpMKDywe5K0D//mVPYTWAYWe56gdJAE3/Ll8RfKS2XALFL0AVxyHww+6yejjoyf19iRjVmFob9RrThbVzPnMkjiVkN6QDw3iIMi7y7OohDIv72j8eQR7GGWaFGwBzeKXvA34M7g6oRsXGmVAelViLiGGk6WsXCojvZcGdEU4jKNogmuGd6cWbkFupWnp1NRiDV9ZnUHx/lHyaMKU907PukVQkHmD0oC6IIcAxDB6o0lkLhDI4VhIKgQH5w==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	Y0IYgfAW+NIIpOi3rKP1laai4RbbhxyutmMRmTa0kKTOfvU11D8BmhTRqlysMhyWOfPuqqmDv7j2dVXSpddmzXSi972eB9VHQJKmVUl2PRhOv+WPU/kmvIBuuYqDr0zhrApcsQ/bcFlutV+tzVUE8cEzRwfhy6Kop4BFv4DTQCfekNFb7fFoIYeq9HEExLLlJg+FxrvRH8T0+Mybgu99lN4JvSVYRbsCY2r61ruhf9esx5zPabxtX9aD4E8lgPOsqr68XptS7icJghEOT52sC8K0hhnLA566DrPYAFCFJQsR3WcvKS/EU4sTtJ1Z43UoO7pxpDU0zPQwOb98eDejSRkbvnEk/21DPvFEmvejvu/5N1wRRdEGYrcsD83Tx0rr1iQNkH8yQLKJuC9WpPdEk/Qkl9Edcdjm+ecxf96A/jko0eKpMDPcWyjy661mqzCj6iRCS/7VzcdhQERxnbLIWmAQ9+ZZJfRLLv08arqvWBUiGZtMihI+hR7Ms+AfCPigKVN2w/bdPDuVNqr4N7cCbo10lGZF4wcNapYpDwzTWvj/dd7c2ihCuPjiZy3gUQuVS8eqIxJl1LE/1Q2GjhNaIB+zeBMMI34J9ISj8vgG5IFQzvTJRHdvU3RczNjSnjPxGgUz9Q8eVgpFjlecwlFx+w==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 20:56:34.2514
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: db1e8af5-37af-47a6-d463-08def7eb073c
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE34.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPFB94A44349
X-Proofpoint-GUID: jehaKD0yGhKd05ZUIIMdUO0dkWpalOsy
X-Proofpoint-Spam-Info: AW1haW4tMjYwODExMDE3NiBTYWx0ZWRfXzwdh4ogVL02q
 DSZVB/EAgWeJtBwhGDvES/YYsd3AibyLhCtdGdDMW1ASGZzyyJIhFJhiDviSxnjiI8JeJ/T6mGs
 jTlm69/bHjb55Cledl9gCLXAY/UJX3tNJSM66SjZEfrGuos7Fa2s
X-Proofpoint-ORIG-GUID: jehaKD0yGhKd05ZUIIMdUO0dkWpalOsy
X-Authority-Analysis: v=2.4 cv=eKojSnp1 c=1 sm=1 tr=0 ts=6a7b8c90 cx=c_pps
 a=hWS9KTtKglmM4LJ/Q12dcg==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=8nJEP1OIZ-IA:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=vnUQfov-gS4s1L7hHvr-:22
 a=VwQbUJbxAAAA:8 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=NaRELG4ay2vD9XK9qR4A:9
 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODExMDE3NiBTYWx0ZWRfX1Xh0Lp5szIkl
 jPMxhNNgydn3rBZ9cEIzi7nWJxkUqCVmp/P9whzVOLvLVBquX/gX0xtwrx3/QCHR8n7wobuhcP6
 LwNoe+jkhmlmD0YqYQxwvI5hqWf8Qeod70H1F5huYWFanL37GgV+Xv8Jl5lH00SQ9tyCx1ypX7A
 HiN5DG5Vd5eudhoJH8kRxqky4mMDYqG1jmw5e4x48IYiLJivqRZ+M9lhyD4DqquxlQUUpnYx3eQ
 LvCDp6W+/82Ohkl/zg5FjOIwhFRS/ovAEG+Sb0Ce1ZxRgmfRheaJjqUGOluo9hD/gnzQ9wAZB9r
 7JCyvkB/pkN8QuTz3bfi8v+MOPS1aZXxYykvnZNWvP+lnppMnZMj6xispqFqexgLwgaEFMgtBT5
 zaWaQLktdRN9d3g2R0LIcb7MgPlaDIouzTC85TSFa13TdmUwrAvdKU93Mh4QoELKdxtkIBaqcfG
 tUwnbZb1LUhbxCIyvyA==
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_05,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 adultscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 clxscore=1015
 impostorscore=0 spamscore=0 suspectscore=0 malwarescore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608110176
X-purgate-ID: tlsNG-bad1c0/1786481810-3A0C5034-66C9842F/0/0
X-purgate-type: clean
X-purgate-size: 2630

Thanks for taking a look!

On Tue, Aug 11, 2026 at 10:05:17AM +0200, Roger Pau Monn� wrote:
> On Mon, Aug 10, 2026 at 04:04:01PM -0700, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com> 
> > 
> > Currently there's no way to print Xen command line on the emergency
> > console for debugging purposes when 'xl' is not unavailable.
> > 
> > Add new keyhander 'X' to do command line printout.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v2:
> > - account for CONFIG_CMDLINE_OVERRIDE case
> > - use IS_ENABLED()
> > 
> > v2: https://lore.kernel.org/xen-devel/20260803070047.3097846-3-dmukhin@ford.com/
> > CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2748655201
> > ---
> >  xen/common/kernel.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> > index d1bef9ac2b2b..54a7ee6f68e5 100644
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -5,6 +5,7 @@
> >   */
> >  
> >  #include <xen/init.h>
> > +#include <xen/keyhandler.h>
> >  #include <xen/lib.h>
> >  #include <xen/errno.h>
> >  #include <xen/param.h>
> > @@ -505,6 +506,25 @@ static int __init cf_check param_init(void)
> >  __initcall(param_init);
> >  #endif
> >  
> > +static void cf_check show_hypervisor_info(unsigned char key)
> > +{
> > +    printk("'%c' pressed -> showing hypervisor information\n", key);
> > +
> > +    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
> > +        printk("Bootloader command line ignored (CONFIG_CMDLINE_OVERRIDE=y)\n");
> 
> Since we are there already, why not print the builtin command line
> using CONFIG_CMDLINE?

Will update.

> 
> > +    else
> > +        printk("Command line: %s\n", saved_cmdline);
> > +}
> > +
> > +static int __init cf_check misc_init(void)
> > +{
> > +    register_keyhandler('X', show_hypervisor_info,
> > +                        "show hypervisor information", 0);
> 
> "show hypervisor information" seems too generic to me, almost all
> debug keys could be defined by this sentence TBH.  I think this needs
> to be more specific, but I'm not sure what's the plan regarding this
> key.  Is there an intention to print more stuff here, or just the
> command line?  Knowing the full set of information to be printed might
> help come up with a better name.

I will update to "show_cmdline" since I originally planed to expose Xen
command line only so it is possible to better debug a system when dom0
becomes almost unresponsive.

> 
> Thanks, Roger.
> 

--
Denis


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 21:00:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 21:00:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388591.1629595 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wttaY-0004qe-MR; Tue, 11 Aug 2026 21:00:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388591.1629595; Tue, 11 Aug 2026 21:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wttaY-0004qX-JW; Tue, 11 Aug 2026 21:00:46 +0000
Received: by outflank-mailman (input) for mailman id 1388591;
 Tue, 11 Aug 2026 21:00:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wttaU-0004qN-7x
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 21:00:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wttaT-00ALeB-9V; Tue, 11 Aug 2026 23:00:41 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b8d70-2eae-0a2a0a5409dd-0a2a45069ac6-24
 for <multiple-recipients>; Tue, 11 Aug 2026 23:00:41 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b8d78-195a-0a2a45060019-5a9b3222ceda-3
 for <multiple-recipients>; Tue, 11 Aug 2026 23:00:41 +0200
Received: from [2001:8b0:10b:5:e09:5b1f:c111:693d]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wttaE-0000000105J-48iN; Tue, 11 Aug 2026 21:00:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=mmyYWtKzdsnw9WFOx22ZcstG8Ar0fvF3/BQLp7xYMvA=; b=p6vw5iz5fkmByvF63Cvl1HY2Co
	NXp9Fax9G2YD5a7ZUr3g9Rz7NVYPvW6BO8Zws3JC1uIDPrhr8OSacffPmwoLLLcrSvlBDAm3+y/Ag
	isQ4YXTrKYbvBu3LQjhFcCoFyd0vxf2XiSYIacbuYnKPYsupX4CAGjhcLhQcSGhujqwMpDa0CmbQn
	xfsd0rtxeYi0nFYtfQUHfpWMBn21Pa/voaKl0TZ4nT/Xg68Xw+fCbuZHNciNNF7w9jFBVhZs4C84Z
	U8QJvdN9e8Gxahy452SdtOEX8EedjNGcLGimHge/98yayerU+tDQMHyZqZikoh8wlV1utvlaC3xx9
	HuxL45Xg==;
Message-ID: <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Tue, 11 Aug 2026 22:00:21 +0100
In-Reply-To: <ants4VjfAiblaWsl@google.com>
References: <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
		 <ano6-gIZtqMfipiD@google.com>
		 <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
		 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
		 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
		 <antQYJvRxJxOjtut@google.com>
		 <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
		 <antb01WqOrs-tztm@google.com>
		 <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
		 <ants4VjfAiblaWsl@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-2dTuJQhVZvx++cPPzOWu"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-16d1c6/1786482041-F580D77B-D5299E7A/0/0
X-purgate-type: clean
X-purgate-size: 12725


--=-2dTuJQhVZvx++cPPzOWu
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 11:41 -0700, Sean Christopherson wrote:
> OMG, I hate this code.=C2=A0 After literally hours of staring at this, an=
d even typing
> up a lengthy example of why guest time would go off the rails, I finally =
spotted
> that l1_tsc_offset is accounted for by the call to kvm_read_l1_tsc().=C2=
=A0 FML.
>=20
> Thanks for being patient and not flaming me too much :-)

Haha, no judgement. We *all* hate this code. That's why I threw my toys
out of the pram and went on this crusade to clean it up a bit.

> > > > And your variant just added a dependency on wallclock time back int=
o it
> > >=20
> > > Can you elaborate?=C2=A0 I'm guessing I don't entirely understand wha=
t you mean by
> > > wallclock time.
> >=20
> > The system_time field? The unspecified might-be-UTC-might-have-leap-sec=
onds one :)
>=20
> Ok, I think I finally understand the goal.=C2=A0 I got turned around by t=
he combination
> of the name SET_CLOCK_GUEST and the full pvclock structure being passed t=
o the
> guest.=C2=A0 I was expecting SET_CLOCK_GUEST to literally set the entire =
clock, e.g.
> mul+shift, timestamp, etc.

That's an implementation detail.=C2=A0

It is literally getting the clock as the guest sees it, and setting it
again on the destination from the same guest-ABI pvclock structure.
=46rom the userspace point of view those actions *are* symmetrical.
I'd actually *like* it to just be a memcpy at both ends, even on the
SET side, just copying what userspace provides into what we offer to
the guest as its pvclock.

But as well as wanting to do some sanity checking, we also live in a
world where we might have to switch to the non-masterclock mode at any
time, and we have to ingest the information into the per-VM kvmclock
setup in a way that the kernel "understands", and that's why it ends up
implemented the way it is.

I looked at rewriting the masterclock base information from what
userspace is providing, but there are *host* TSC values in there, and
it ended up in some cases wanting to set ka->master_cycle_now to a
value which is *negative* on the new host, and I didn't want to
exercise that wrap-around path. So instead we just adjust
ka->kvmclock_offset to give appropriate results based on the existing
masterclock base.

Each vCPU's pvclock is then *regenerated* from the VM-side kvmclock
data, giving rise to that annoying =C2=B11ns discrepancy that I whined abou=
t
a while back, but didn't give in to my perfectionism and eliminate...
yet.

As far as userspace is concerned, KVM_SET_CLOCK_GUEST *does* set the
entire clock (at least the relationship between guest TSC and kvmclock
nanoseconds, which is what it's for). It's just that the kernel then
"tweaks" it a little bit to give a slightly different y=3Dm(x-x')+c
equation which is still within the noise of the original.

And the kernel actually does that kind of 'tweak' all the time.
Although we're working on narrowing them down because "within the
noise" is in the eye of the beholder; Dongli had some patches for that
which I think I rounded up and included?

> But all of that metadata is just a means to an end: the one and only goal=
 is to
> calculate the per-VM kvmclock_offset for the "new" host's TSC+time snapsh=
ot, by
> computing the nanoseconds delta for the new snapshot as if it the guest o=
bserved
> the TSC while running on the old host.

That is currently how it is implemented. It isn't the API contract.

> And that is done in the kernel instead of in userspace to minimize the am=
ount of
> slop introduced due to delay between taking the snapshot and computing th=
e offset.

Huh? There should be no delays here. If *anything* in this new code is
done with something other than a *simultaneous* reading of TSC and
ktime that I sweated blood and tears and got shouted at by Thomas for,
then that *is* something I care about...

--=-2dTuJQhVZvx++cPPzOWu
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTEyMTAwMjFaMC8GCSqGSIb3DQEJBDEiBCAIQWPZQBQHtp4FnkklH/sJgRU34Imr
FFyUqJFj4vRYmTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAYtSKH29DLc4kejRFEd8eEEfJzFj8R/XY4qwoZCxzCN163Ud26g70
euGwuLOudHe4CtzMWnBLi3bfriHL60nVT7wDxyFHs27J9IRV+Fwhcs2wAybTWaBfQJlmF5G60rjY
rJLTlMHmcrU4LT6RkX6fuDHSTX9PyMaLm51wTvuJ2nOt8kHtLfbC53Z4nNu053ypH22iFwNjT/ID
1r9bKqfkUO/fG7u/YiScrxucUb5kx3QoJD66tIi6rU0XJxUNRLEVNV+dlQCXV1fEV7oVTLkF3VHR
atPUelW3bKhv+Hk0o9mGuCXfKp6NwAUA2PPNpZ1LXRzlfNPebrCwYzun6HOWJ7r441gDkauF2DJT
TCpn9415wr1Bervy7yPL6WgC38f1Kwn0FoKWvHKudskV89iqmi4/nxTsMqsliByjXyE6+M7Nel/i
rUPskdOoU5xhZGgF4Th1Z6DV/1arV8qYJz8+dXO7fBbhX1sFz44Bt4qBBlaa+utNUeg9+CDHTSwA
NTdMUX3xqwCRkF89h/mH17Hsl0EQcPfuLG0zXgXQEmF7lXLETUXKpNo+hSFGdQ7b+TZDSOLTKdiB
zSyLDzhdUwqhVkUNObpfhb2sBsLWtYaGdGIO34L0IQlxGr8i2RsCETtIJiSkefeQACbV13cLEBKe
6dY+E8WsXfRv6+oEY1vKX8IAAAAAAAA=


--=-2dTuJQhVZvx++cPPzOWu--


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 21:12:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 21:12:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388600.1629605 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wttld-0006rT-Nl; Tue, 11 Aug 2026 21:12:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388600.1629605; Tue, 11 Aug 2026 21:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wttld-0006rM-Ju; Tue, 11 Aug 2026 21:12:13 +0000
Received: by outflank-mailman (input) for mailman id 1388600;
 Tue, 11 Aug 2026 21:12:11 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wttlb-0006rG-FP
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 21:12:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wttlZ-00FYLW-K1
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:12:10 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7b9027-2eae-0a2a0a5409dd-0a2a4507802e-8
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:12:09 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7b9027-b4ea-0a2a45070019-94a38ff14a50-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:12:08 +0200
Received: from pps.filterd (m0482515.ppops.net [127.0.0.1])
 by m0482515.ppops.net (8.18.1.11/8.18.1.11) with ESMTP id 67BJJpMs1749946
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 14:12:06 -0700
Received: from sn4pr2101cu001.outbound.protection.outlook.com
 (mail-southcentralusazon11012061.outbound.protection.outlook.com
 [40.93.195.61])
 by m0482515.ppops.net (PPS) with ESMTPS id 4g08tysxgj-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 14:12:06 -0700 (PDT)
Received: from CYZPR10CA0022.namprd10.prod.outlook.com (2603:10b6:930:8a::26)
 by PH0PR16MB4261.namprd16.prod.outlook.com (2603:10b6:510:4d::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Tue, 11 Aug
 2026 21:12:03 +0000
Received: from CY4PEPF0000EE36.namprd05.prod.outlook.com
 (2603:10b6:930:8a:cafe::55) by CYZPR10CA0022.outlook.office365.com
 (2603:10b6:930:8a::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.11 via Frontend Transport; Tue,
 11 Aug 2026 21:12:02 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 CY4PEPF0000EE36.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 21:12:02 +0000
Received: from pps.filterd (m0426318.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BJLfHQ3908633
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 17:12:02 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4fxjw5bh9m-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 17:12:01 -0400 (EDT)
Received: from localhost ([19.12.76.221]) by cmsmtp with ESMTPSA
 id ttlPwg8Phl3RSttlPwBqxz; Tue, 11 Aug 2026 21:12:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=E/B4OGTUik0qpSe4TEgfrHllO
	vR0TgzZpKxl3Uotu7Q=; b=Z7Mjxiy80ympdAtELdUAmpQwzBF0LrLogn08fp/Rm
	nmJ9nTcqXezcGw4vIIbD2tpIt2bxIPWHFQ4vja4y6i164gF5friTB6Nv4M4kavTc
	QM5ezmjIyULsUkaZLtf1fTCWgBCIgCRumMZski8JyO6J1EjoZJlpMsb3dF0VjWBw
	VZm7rvega0WhbH4Z3eYT2+VpgJqD4DIGL5pEz8EeI+sTTKFKaPsVactGK7KLBrFV
	J2GsDlAUSsNOMSFwsz1WODLSe/TOzkfEESr/hmPano/ZwCQJD4e1vLIW7TKaGG/T
	7DxbmuLPkJs7po+6U82i1xQy/LDVwnaCKqAQYY456iqrw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cPPNLwU25epAzkQlrV1gaNgLnpQ3G6R2xgC1KKWAluI/86av5Otw34UDpfdRpbGaLk4vqzwNYOJsqefRj/dDerOMrgjbGAk01sirHIbuVNOtriUjKwILPOcTBp34mCcXrRa+DhmX7KT4qxI4MniB3BacATbm3LUn4pUi4TDTFCeW0kjB0yvGLsn+xBoXd50ZctCcLhAhu+jBFChGoXWPxuFSp37QNUFtUaVEcJJXG4CkVHRqPMlAMhKHpDcvjTAF0u4Ux4VSkCemDc3HPihzlok/8w0i9VSUa7EsUsZPxdHCUIvlfWL0zUoAcPuRuD2At9FwkTdMrI2SoeHe70nH2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E/B4OGTUik0qpSe4TEgfrHllOvR0TgzZpKxl3Uotu7Q=;
 b=VxmeU3vtNiFQICwmBEzc+55i9grq6nwezNswWlkfwUywfBKLl/skHzCNmmaitbGmXl7MNylx/GJsOGguaE3szLIgUx/3UlyvY1bb+E+HQFusdueDVq6SoLA7jRK6RXX13KG0JIBclhzpP/UY3ZEA9Y7Ae6D1sFBPOuKvl17nEEe0Nb3KzcPHwKeWRNP9NXBH8VVi+RJKyFBrIwqYhJN1OIteS+buZwP/FaEfOR764vF9m8d0jCvj65zczKKfd4F1kfYYSf16Nw3mafLww2Gr8+LALpPw2GW/Dw5P3MG3LvvJaLuJCDktNZ39K8CHfxdg0m80hAHTu0I+niZIUEFHYg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=E/B4OGTUik0qpSe4TEgfrHllOvR0TgzZpKxl3Uotu7Q=;
 b=RKXapbPqO5HpaM7Ds7r5AXrTmT7yEJzPI1/4nSY75VqL3jWOnrGQOlUh3ocKDmgFU+dkrlfBQFwomnmluxZ8vXgDxKsdnnINMgB0qdgyNOm0zCZ9B3qVLrglVxByO+cv8HxFecEY0D9xb02DHZSXQT5WCcDICerCO0GXHwmM3Yw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=E/B4OGT
	Uik0qpSe4TEgfrHllOvR0TgzZpKxl3Uotu7Q=; b=oiaaopXWFSqrQIxLdQ9kZrU
	m2WCbEBxShB82fo8DondNbvUfEnb6+POXBjK2zitos+NIGEnrv9DKz7gCiZR7ZAd
	BksqrG9l8i/0UUic1dwrXHr3+aW3sb/f3J7AVm/AKGa7q6KsRWVu02ph7BgSsE/8
	n/8PDVGbRREhmT7k31vwZ688nX5ViwDlJ5bdv4OfuvHuLJrtwgnfZHH5LV40RVWM
	Adzgzw597Ti/Q96Z7RRIlxYtLbA4fkB6j7+pcojKwi2fxF+rvSHWbilc7yD5ryKs
	AQ4PqMGo0ogyw0w0uX2UvUWkwYnr0f9zBHRq1ZuD1LQEcjO7D4hh6SGKrS0BcqQ=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=E/B4OGTUik0qpSe4TEgfrHllOvR0Tgz
	ZpKxl3Uotu7Q=; b=i7Zx1Ud9EewzzUW0KR/51TO1gNvV9xBHWg0+hkH55MlKE6f
	oly2KQn0uoEuDeyhouRpBS3MjOQe7yQn15xWgOCaZbi0yZwI+8q/nYXDsmytl9Hk
	UUVvMElBPxNV0KI1ogQPzpwP854v1AN7Mp4KaX2Z8AG9jnJwbKQg+3VGjqF/MGoQ
	g3EgFqoHT5nBBSzx92XVycR6i0NO42bD7/rDT9rsRJrCrfJGHGLrwDfvdNf+x9gf
	YErLCyhZWvidj46RyNtifeXGY6RwHZ1Xqz9g69yx7/64LILCaZGjE5sv7RFX/LMD
	dEwzesSOF3MA4n3YAbPq+uYjm+fREGhzIu9JjXw==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: ttlPwg8Phl3RSttlPwBqxz
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v4] xen/common: add keyhandler to show Xen command line
Date: Tue, 11 Aug 2026 14:09:57 -0700
Message-ID: <20260811210956.3806559-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_05,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 suspectscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 phishscore=0
 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound
 adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608110178
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE36:EE_|PH0PR16MB4261:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: e2853b1c-9538-4571-03ec-08def7ed30a7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|1800799024|82310400026|23010399003|376014|56012099006|11063799006|10067099003|3023799007|18002099003|13003099007;
X-Microsoft-Antispam-Message-Info:
	XnyxGH9V+37T88cz9tZi6piA45r3oCR1om1mYQPIFlyvl6LLuI7atQcUKbutZNn9nq8BAOLdtO8eQjovBlyv6/mQNAnkLwVZAo0HpoIYVZ2zOeyLg4QjTODbHmYBSYmWl3baR6+dRnXLWIXPMxtQMO5sdL8zTPuLBvm5I5CU9/+e5impkyUlq436sTl7hFmxxO8dGYDb6/rvsP0evpnoEHr9I69rG8nO79vjfNXQ2oEDI3fWNzVBsvHOYx6aaDSCD7opPvO8+d4eFaXlko9LbZbUp2ZMS/DsUC0VZ0TLtvoqwAFBLC01XKF/69dScLGhZjtFSZAHVveoRtl7pQZuOOETiLC7ZzGs/9HcSq6yWZXOuOMnBDy0mVfQ06T+XVz8UoenwzzQQueToIFmpA62eMFAXfcW3VleJkMwasJB9C/wvYo0j4cUeAVkpsw2fHz4Mj/V+JOohaV+fAKaI/0P4I9B3AFR5XThNc1DSMTe0l/Qq48V7YgzESlvu6mkk6xEcGl8NxVP8WgnjPUGUJAcFqIOYx438CnmcEapQ5GtoJMfIAxMFps2Wrmgmt44asSubUJyTj2ibCvIbqKnzN79bUMOTqmNrBB4t8w1C10GtEDqBM6cUAuNrE9FOKcMRdp40FYnM7gwuV12UvrpQEqrXdQnjhO4DooakKtNe0TIg8+47Q1E1mCL8xR5+WCPKtZF2UKf3Ny/eVekpUz1jitsLw==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(82310400026)(23010399003)(376014)(56012099006)(11063799006)(10067099003)(3023799007)(18002099003)(13003099007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	aHQUKJlMOyGTwsqNERfRyJMzdcEhSul8DjLnb2hPIDJWg1ncGVnykZYoBZfkVVmsSy0xPThJ9fTQBOARzNrwglZwyONKtv/Wr7Xhso/HdDuNsoXGSVfktL3TLmsxHQJ0OsiBgW0U1hrH/RyTyrUK1kMsyuqeFbon6NInbsKieKAn4zg3Laej6LGePpI2IL+jaM6BoHQ9AopvkFTyVjbY+uToG8j/Pp4aJTfDTjrdFcWeKQn6TXjIaoG6comoMtM/WZNjRw1OzDcyMdNIVhAKuTp1JVy5C0IOjZlpsXcXHrWSC4masmg3nzAhiepfjr/u5uK6fAw/LLIR1qR2UI7lUrl6ZIgAI+RWgEdoMTGjxEdhPu9uApzVFwaJL8g/vxlDA8/FTvIiijpyv7cBI3ZTQe5N5wRyepHZ/nkWJh+UqODqmFUyC11KIVEoH5no0Jya
X-Exchange-RoutingPolicyChecked:
	e7fKk1dTjGUi6pzE5nVHye/+jWMNBpEtUJAYblFAodu5W7AtYXrLMsi7DMJR6vG2psoBxmBsWXlMvdvrGxALrW45XsfmR0/UTC0F2rx0mC8Ead3Ml3DitSJHxLo2PjsvzI/aKUAntL/kPUFnqtGwg99aHMNiBZoYsfCJsvEbRDzEJfi0Qh1BQaUMqUGac1+Tp/FjUcMrgWkykeOoJnDAUrj5+98vYoHMiq+rqRkknksHCpo9ZieMF/bTfEz+PZ9yM9jIFQ8aYzKl9lcc+WGxywWo0zFq7BdHLtec3bEilbBSAfshW0DF/kQuB6tRvzS+9BuwGU3M35mH/CyKIYfe+A==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	pAME+JoQ3SZIjdtBQpLmQMJOlNql0iH09gv5BtJCNwQfAvlSMlAIz9lSGK8PO7jl8X1D8UJ87qli7P4vfspH1Xctg6DPo4vzokrHcQHV3vlXyo9vOzEVzmCYISRgMQ6lf+QLGsJlfGve/tyf6hq+cWEeOSe8WQwV4RIAvTF5Ud3zUxra6zIuk5F7GMwp/Ig5Qh4PBJztb4rbZTz7Y0TmS1UMpxixyqFbgW5ER66y0uMz9QTHRXrA7nATGOto6Ao91aos29jOX4XHw+/eYhazIJDB8C/og/JpCkNy4dUw6H04nDznkELByF/ZU2ZmvMlUtKJuEt78V2vD/3lJggJfTMYTrLfpOZUUAiT/LeVAamFCGtbCK4h1r46RXzKKaPxbH4rH6jCDI/dCUsQ4gw4u26vnSU6FT+QdPbyYG390pURbWWY/T1+2znDdIzYkGTNxY0Lq6+/Q61KZ4J4FZ3kMJid6zHnDRV5BNjFO4H7wbpJDKeiDBsMNJxuWUn1AnAqoQgPAdCGEh12qu0sJXUcps8gEmv8HpOJIJQMHpF9gf5QkFuYEW917rJF1lOUaC53wPCnqIU5eWOJZB3tcy6qKgca5IlawaSXPVsKhPV89UWi2O3MUCn+t3OZ5Pse4PEvRZyi+JM/cJtMdGjZQOEpShA==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 21:12:02.7276
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e2853b1c-9538-4571-03ec-08def7ed30a7
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE36.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR16MB4261
X-Proofpoint-GUID: OYJVD7ZUROFawxw-ZzSUDwsTH0ChL51R
X-Proofpoint-Spam-Info: AW1haW4tMjYwODExMDE3OCBTYWx0ZWRfX2bR0dVe0KFZx
 tRoCzPd5CTusFMFMhlcARzWfAwszE3NNchyZOBdnj8M3MlTA+F4m0mqz8isn8whoRrVw+J3OpR+
 eMAjE/cQdTeYCuMFfiiSjvy58NRlPikjGmj3GkhD4tByvzH/UBdT
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODExMDE3OCBTYWx0ZWRfX9os3kZHwzzry
 Cq50Z4YHzFfE8H3OWYqMyJaT4b2mPcb4A4/IkkV+zYQI+8NSdfnpZm0NxlJIVmE3VVMWjMQ876B
 hS7p00ub2KUql2uEhikoKWgHtmzMSqUFqvGKhJ07McImDulHfp0/tXdkGXH1Ex6jcLcno9vwxu7
 8rhUmHSW9+S2cp0jChQAq1esbUvQ+TCY+DpEc+QVanosvLFAOLJP3qSIrhessTMqbZdDj/VbFbW
 wRw9ohiiVFCN+JptBVdVON1n8+B7Xry6imfrQBMDXlLjxQWOfaQ3NRpijXLn1vxbIM0i49iWNO7
 QBkklg1DfZ/qBYd2+KCLV0lt+WPzvrA9fs6O5OqY8lEmEAxikSEpu0Oblb0duP7ZQMEFzhAT8my
 ROaC1mvnCyC4fTYvAumftLNzJ2oDvh0zPzUpVZyJ/59GIuLUnyDE31889dHN2S1oFXn9qmnHOF5
 gX7PXBJawIkLVe5D7ug==
X-Proofpoint-ORIG-GUID: OYJVD7ZUROFawxw-ZzSUDwsTH0ChL51R
X-Authority-Analysis: v=2.4 cv=aKfAb79m c=1 sm=1 tr=0 ts=6a7b9026 cx=c_pps
 a=N7UEZcGu6nKKiVkixTDHSg==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=0GA0A_IKJoUHBEAzNTkD:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=IgJ0wlFFhhnA7GDi3u4A:9
 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_05,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015
 spamscore=0 phishscore=0 suspectscore=0 adultscore=0 bulkscore=0
 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608110178
X-purgate-ID: tlsNG-ef75cf/1786482729-A58C1AE4-C9FFB066/0/0
X-purgate-type: clean
X-purgate-size: 2003

Currently there's no way to print Xen command line on the emergency
console for debugging purposes when 'xl' is not unavailable.

Add new keyhander 'X' to do command line printout.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- print built-in command line too
- change handler to print command line only

Changes since v2:
- account for CONFIG_CMDLINE_OVERRIDE case

v3: https://lore.kernel.org/xen-devel/20260810230359.671587-3-dmukhin@ford.com/
CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2751523722
---
 xen/common/kernel.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d1bef9ac2b2b..8a43e4421002 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -5,6 +5,7 @@
  */
 
 #include <xen/init.h>
+#include <xen/keyhandler.h>
 #include <xen/lib.h>
 #include <xen/errno.h>
 #include <xen/param.h>
@@ -505,6 +506,37 @@ static int __init cf_check param_init(void)
 __initcall(param_init);
 #endif
 
+static void cf_check show_cmdline(unsigned char key)
+{
+    const char *builtin_cmdline = CONFIG_CMDLINE;
+    const char *cmdline;
+
+    printk("'%c' pressed -> showing hypervisor command line\n", key);
+
+    if ( builtin_cmdline[0] )
+        cmdline = builtin_cmdline;
+    else
+        cmdline = "<NULL>";
+
+    printk("Built-in command line: %s\n", cmdline);
+
+    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
+        cmdline = "<NULL> (CONFIG_CMDLINE_OVERRIDE=y)";
+    else
+        cmdline = saved_cmdline;
+
+    printk("Command line: %s\n", cmdline);
+}
+
+static int __init cf_check misc_init(void)
+{
+    register_keyhandler('X', show_cmdline,
+                        "show hypervisor command line", 0);
+
+    return 0;
+}
+__initcall(misc_init);
+
 static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xen_varbuf user_str;
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 21:46:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 21:46:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388623.1629613 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtuIu-0003Nv-Af; Tue, 11 Aug 2026 21:46:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388623.1629613; Tue, 11 Aug 2026 21:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtuIu-0003No-7Q; Tue, 11 Aug 2026 21:46:36 +0000
Received: by outflank-mailman (input) for mailman id 1388623;
 Tue, 11 Aug 2026 21:46:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3OJh7agYKCbEjVReaTXffXcV.TfdoVe-UVmVccZjkj.oVegifaVTk.fiX@flex--seanjc.bounces.google.com>)
 id 1wtuIt-0003Ng-9G
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 21:46:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtuIs-00DCOd-ME
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:46:34 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3OJh7agYKCbEjVReaTXffXcV.TfdoVe-UVmVccZjkj.oVegifaVTk.fiX@flex--seanjc.bounces.google.com>)
 id 6a7b9832-bab6-0a2a0a5309dd-0a2a450ab5d0-2
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:46:34 +0200
Received: from [209.85.215.197] (helo=mail-pg1-f197.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3OJh7agYKCbEjVReaTXffXcV.TfdoVe-UVmVccZjkj.oVegifaVTk.fiX@flex--seanjc.bounces.google.com>)
 id 6a7b9839-f2d2-0a2a450a0019-d155d7c5b50f-3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:46:34 +0200
Received: by mail-pg1-f197.google.com with SMTP id
 41be03b00d2f7-cbb467e56aaso223346a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 14:46:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786484792; x=1787089592; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=GNP84U5NVANNewsvSEzbCgg+MDCqvRSKiMtE5jPKweo=;
        b=Micf/Ccj7OCe7RGEQxYVcALcLKQzeHnbXv+sqv2hh5TAmfVo52vHpYTyRCnBbT1jV1
         8osw8bMFN58yaoXUbkb8E9PTcleA+hY8l3lwns9b4MBGKS9KkszAXum2ACun78nczwmV
         5D9SBi1cD5vQ503qqHo1Zf6gCTrQDLiJYaTJMrOSi5uytzu1z2UQcmhpduPKH9bDknmE
         yrYww2zsFisNCW01uGBwHOKwUniSd5qEcmxaki5D9t/z27Pz6BLaYhoIHxw5yLb8nDGh
         c/xZV+pPrbYCmEU4wkkc0wDd0pcKGYgdc6qI14LUxOl2E+SPjPVuXLdHsrxolSD3lt14
         +a7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786484792; x=1787089592;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=GNP84U5NVANNewsvSEzbCgg+MDCqvRSKiMtE5jPKweo=;
        b=TT/sxcxwV7E91gUPhymwCPSHeIwBbXUzUnvc5zoNsT0iiiDd9v4Ngt0Yqo/JyVVDQ8
         GgwHtsMjRaCt1m6VpT7Ymhqmg46UK4aBWfnx778YMHs1/oHQWdZwKemA3HyytNgRQ233
         M3bwkTI/Z1JupN9gdV8BkjCUMcEqg5jawMkRMcbiHNICLI9LLeCRQnHU4FTuzg3F942I
         X27BjcMvaUFZBH9MVCRKp4Fg0C6Ncvh+GpJT1DyxrvJTb1TK4AkR2bn0kqQOLhR5nVTo
         AqIZmfHgeKiBfhBDFM0qFTf2HKUhpZ8n0VdrRf0z5t18L1hoRyF6JDgcRi837Y7ZrbK3
         1Gbg==
X-Forwarded-Encrypted: i=1; AHgh+Rq0n2jO0h7aK2HxU6mRiVtOQj0BrxeYxjFLuViObc5ACRx6SbSgzHoKKQTADRZO9OK3ndCJUUpv71o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQLFzasOmAFfhU5Nspx+uNk95/3yq0eo4H44PBhfLof5S9VTXN
	lQEocrgINc5c6zrxIaFrxUzpQo5oM1cJ5vuxB2qlAot+mJrltB0vmMhyZI9zqypv/WHWyohcilf
	o4ULuNw==
X-Received: from pfbgp12.prod.google.com ([2002:a05:6a00:3b8c:b0:84b:4480:8b65])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2ea8:b0:847:98ff:4af5
 with SMTP id d2e1a72fcca58-84fb54c5d00mr290195b3a.26.1786484792108; Tue, 11
 Aug 2026 14:46:32 -0700 (PDT)
Date: Tue, 11 Aug 2026 14:46:31 -0700
In-Reply-To: <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
Mime-Version: 1.0
References: <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
 <antQYJvRxJxOjtut@google.com> <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
 <antb01WqOrs-tztm@google.com> <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
 <ants4VjfAiblaWsl@google.com> <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
Message-ID: <anuYNxD81OE3MrQw@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-4011c0/1786484794-58DC7CFC-57CBBD08/0/0
X-purgate-type: clean
X-purgate-size: 5174

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 11:41 -0700, Sean Christopherson wrote:
> > OMG, I hate this code.=C2=A0 After literally hours of staring at this, =
and even typing
> > up a lengthy example of why guest time would go off the rails, I finall=
y spotted
> > that l1_tsc_offset is accounted for by the call to kvm_read_l1_tsc().=
=C2=A0 FML.
> >=20
> > Thanks for being patient and not flaming me too much :-)
>=20
> Haha, no judgement. We *all* hate this code. That's why I threw my toys
> out of the pram and went on this crusade to clean it up a bit.
>=20
> > > > > And your variant just added a dependency on wallclock time back i=
nto it
> > > >=20
> > > > Can you elaborate?=C2=A0 I'm guessing I don't entirely understand w=
hat you mean by
> > > > wallclock time.
> > >=20
> > > The system_time field? The unspecified might-be-UTC-might-have-leap-s=
econds one :)
> >=20
> > Ok, I think I finally understand the goal.=C2=A0 I got turned around by=
 the combination
> > of the name SET_CLOCK_GUEST and the full pvclock structure being passed=
 to the
> > guest.=C2=A0 I was expecting SET_CLOCK_GUEST to literally set the entir=
e clock, e.g.
> > mul+shift, timestamp, etc.
>=20
> That's an implementation detail.=C2=A0

Yes and no.  If the payload didn't literally have all the assets needed to =
set
the kvmclock fields, then I wouldn't care.  But I don't think I'd be the on=
ly
person to see a GET+SET pair and expect GET to return exactly what was writ=
ten
via SET.

> It is literally getting the clock as the guest sees it, and setting it
> again on the destination from the same guest-ABI pvclock structure.
> From the userspace point of view those actions *are* symmetrical.

Only if userspace holds it just so.

> I'd actually *like* it to just be a memcpy at both ends, even on the
> SET side, just copying what userspace provides into what we offer to
> the guest as its pvclock.
>=20
> But as well as wanting to do some sanity checking, we also live in a
> world where we might have to switch to the non-masterclock mode at any
> time, and we have to ingest the information into the per-VM kvmclock
> setup in a way that the kernel "understands", and that's why it ends up
> implemented the way it is.
>=20
> I looked at rewriting the masterclock base information from what
> userspace is providing, but there are *host* TSC values in there, and
> it ended up in some cases wanting to set ka->master_cycle_now to a
> value which is *negative* on the new host, and I didn't want to
> exercise that wrap-around path. So instead we just adjust
> ka->kvmclock_offset to give appropriate results based on the existing
> masterclock base.
>=20
> Each vCPU's pvclock is then *regenerated* from the VM-side kvmclock
> data, giving rise to that annoying =C2=B11ns discrepancy that I whined ab=
out
> a while back, but didn't give in to my perfectionism and eliminate...
> yet.
>=20
> As far as userspace is concerned, KVM_SET_CLOCK_GUEST *does* set the
> entire clock (at least the relationship between guest TSC and kvmclock
> nanoseconds, which is what it's for). It's just that the kernel then
> "tweaks" it a little bit to give a slightly different y=3Dm(x-x')+c
> equation which is still within the noise of the original.

Again, if and only if the fields match what has been written previoiusly.  =
To
me, that's not a SET operation given the full inputs.

I completely agree that conceptually this is intended to SET the entire clo=
ck,
but as you note above, reality doesn't allow for that.

> And the kernel actually does that kind of 'tweak' all the time.
> Although we're working on narrowing them down because "within the
> noise" is in the eye of the beholder; Dongli had some patches for that
> which I think I rounded up and included?
>=20
> > But all of that metadata is just a means to an end: the one and only go=
al is to
> > calculate the per-VM kvmclock_offset for the "new" host's TSC+time snap=
shot, by
> > computing the nanoseconds delta for the new snapshot as if it the guest=
 observed
> > the TSC while running on the old host.
>=20
> That is currently how it is implemented. It isn't the API contract.
>=20
> > And that is done in the kernel instead of in userspace to minimize the =
amount of
> > slop introduced due to delay between taking the snapshot and computing =
the offset.
>=20
> Huh? There should be no delays here. If *anything* in this new code is
> done with something other than a *simultaneous* reading of TSC and
> ktime that I sweated blood and tears and got shouted at by Thomas for,
> then that *is* something I care about...

Sorry, I didn't mean to imply there would be delay on the SET side.  What I=
 was
trying to say is that if this were punted to userspace, then there _would_ =
be a
ton of slop because it would be practically impossible for userspace to pro=
vide
the correct offset. (I was walking myself through why KVM needed to provide=
 uAPI
to compute the offset, as opposed to provide uAPI to let userspace jam in w=
hatever
value it wanted).


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 21:57:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 21:57:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388633.1629623 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtuTA-0005E2-7G; Tue, 11 Aug 2026 21:57:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388633.1629623; Tue, 11 Aug 2026 21:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtuTA-0005Dv-4c; Tue, 11 Aug 2026 21:57:12 +0000
Received: by outflank-mailman (input) for mailman id 1388633;
 Tue, 11 Aug 2026 21:57:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtuT7-0005Dp-Kg
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 21:57:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtuT6-00CFPK-Nz; Tue, 11 Aug 2026 23:57:08 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b9a66-8faa-0a2a0a5109dd-0a2a4507e1ec-44
 for <multiple-recipients>; Tue, 11 Aug 2026 23:57:07 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7b9ab3-b4ea-0a2a45070019-5a9b3222dbd6-3
 for <multiple-recipients>; Tue, 11 Aug 2026 23:57:07 +0200
Received: from [2001:8b0:10b:5:e09:5b1f:c111:693d]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtuSt-000000013TK-3eSZ; Tue, 11 Aug 2026 21:56:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=oV98QYeUC3NkyosKp2b8pkhzXaPhLuZz65LU9F6UUMU=; b=swfdPiIzvnlnphAddtRqyGnjyf
	uetoNMBDmO8+cSJWH8NKO3a73TXewMx1UJpqpQ3fzyQG60kaEDD36P31m5mWbLSOBd69/HSNtKN/t
	PDMlb1WK29Bi6ZBzFvqOKVryUu2nFv5gUvV7mIXaZc9BX2KtlM2m+F9lOd22HLMUyDzH0U7L0Fh31
	yHrMf49g2B7pnEJqn/6TAFFpCzUHnhEQqLQIoHv84RwMe2zsE4ERefK3nZwFe+wH7xv2zkpM00lrD
	DGA2C0YNoCrUzTB82vHu0W2NkVPi2U1zL+64e87LVECLepcyqhfhBZc77U2h8v16Zsnru5sApgYxf
	SUp0IpfQ==;
Message-ID: <5efe7a3914a3610ee00a487379caff84af6aa731.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Tue, 11 Aug 2026 22:56:50 +0100
In-Reply-To: <anuYNxD81OE3MrQw@google.com>
References: <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
	 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
	 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
	 <antQYJvRxJxOjtut@google.com>
	 <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
	 <antb01WqOrs-tztm@google.com>
	 <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
	 <ants4VjfAiblaWsl@google.com>
	 <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
	 <anuYNxD81OE3MrQw@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-wSSskaTjZd27bgLZsARo"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-ef75cf/1786485427-36AD8AE4-B135864A/0/0
X-purgate-type: clean
X-purgate-size: 10562


--=-wSSskaTjZd27bgLZsARo
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 14:46 -0700, Sean Christopherson wrote:
> On Tue, Aug 11, 2026, David Woodhouse wrote:
> > On Tue, 2026-08-11 at 11:41 -0700, Sean Christopherson wrote:
> >=20
> > >=20
> > > Ok, I think I finally understand the goal.=C2=A0 I got turned around =
by the combination
> > > of the name SET_CLOCK_GUEST and the full pvclock structure being pass=
ed to the
> > > guest.=C2=A0 I was expecting SET_CLOCK_GUEST to literally set the ent=
ire clock, e.g.
> > > mul+shift, timestamp, etc.
> >=20
> > That's an implementation detail.=C2=A0
>=20
> Yes and no.=C2=A0 If the payload didn't literally have all the assets nee=
ded to set
> the kvmclock fields, then I wouldn't care.=C2=A0 But I don't think I'd be=
 the only
> person to see a GET+SET pair and expect GET to return exactly what was wr=
itten
> via SET.

Sure, but right now, even a sequence of GET+GET+GET won't necessarily
return the same answer three times in a row =E2=80=94 not just because we
haven't fully eliminated the non-masterclock mode (which we might never
do) but because the masterclock mode itself isn't truly the first-class
citizen =E2=80=94 so we have to kind of reverse-engineer it into the per-VM
clock data, and then build each vCPU's pvclock back out of that again.

We *ought* to live in a world where that pvclock information *is* the
canonical source of truth, and any series of GET/SET/GET/GET/SET should
never see it change. And we can build our future-looking API around
that model.

I think I do stand by my claim that SET/GET/GET potentially having
*three* slightly different sets of data is an implementation detail
that we will strive to eliminate.

And hey, at *least* they genuinely are within single-digit nanoseconds
now!


--=-wSSskaTjZd27bgLZsARo
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTEyMTU2NTBaMC8GCSqGSIb3DQEJBDEiBCA3i6GIZHaMFaIYxX1XvE4xlMIgwsmI
PzrqFLD0K/SIeDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAiiKfe1ReG0lgLMhx8H9//hNFp6dh7X4fHwJ/L9KB3p30jqB1TzSE
4rMfIk8rCNmIndRP2Db+JBnlfXhZWpMkLuQNzfNnnwmpQmDh3bfbvjdLXEPsgPtwsk60V3IvZakm
WWzY1QuztHV7oBYI09lkz9+uYKN83sNFGiJQXBp95J/3Cq9P+wZnQLOmpJukIS7DP/h3pO02YqST
Q7gkuv1nk2dOI8agWZkYcm4XYxLiy7bI8q2K+mVr40gBOGtgBBr2gHEVJ2X1jkhiesmanBIac6eR
q1BrR5Gl2MJvdrIAFusHeUnF7K3z4tVuyHQZg9qL8yyzqJxmvYhB1B7DIbWI/Yhb+g+1cDxtZgTD
GqmjGLlqcDz8/FVlqbx91Vf40GR+qCe6SzdnWE+yAc2lZVQGMxywtCY0977H01ENUh7VsAdUqbfb
KvMMFpFs7HVJrsJDg/OMMpYRlLzkhKx0o7TZAj9dX6N2hjPlbVrlGPZUkSR6Mh+lblTeTeLVjRz3
b7+K55DlSoqQPtvRQ50OrtXE+neqnH+rBmzsfkMH/eojITV0dTAMbljD+XO8TbEmD+XtngjtnEtJ
tJLpnrplimXqd7ylaz55kNP0fRMX1H6cwTXks+pyDt0Ug1hX5owVyFvVsexbdHe0zl5vj9vm5KpC
fFB77++8lvtvApchR6aj2pIAAAAAAAA=


--=-wSSskaTjZd27bgLZsARo--


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 22:55:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 22:55:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388648.1629632 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtvNw-0005Fb-9k; Tue, 11 Aug 2026 22:55:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388648.1629632; Tue, 11 Aug 2026 22:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtvNw-0005FU-77; Tue, 11 Aug 2026 22:55:52 +0000
Received: by outflank-mailman (input) for mailman id 1388648;
 Tue, 11 Aug 2026 22:55:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtvNu-0005FO-K2
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 22:55:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtvNs-0084Zv-PV
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 00:55:48 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7ba867-8faa-0a2a0a5109dd-0a2a4508d018-10
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:55:48 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7ba873-f659-0a2a45080019-ac6904fe8682-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:55:48 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id DDDD7600AE;
 Tue, 11 Aug 2026 22:55:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9115B1F000E9;
 Tue, 11 Aug 2026 22:55:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786488946;
	bh=jeilZSE5bekOjzuqxWSKXpatSV0ynUXy3CJtzB3XQ4w=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=EVyaTdvkIHbEESE3KOcDzJ6B+XJCHi1efzlaDB6Gdwkzk7p18JFszRRBZKYsUQ5W4
	 p2SzFyDgIrSCP0av9pt7vjsMvAPkCWo4BETSXeLQf0e7M8xhA/qA10yG73Wsw+A1oH
	 RQ+8ua6Q+0y0QZmJLrPtp5AymP/YFfYKppswiJUZmbh4p/6fwRE3u+cC/YX+lxnfFY
	 3m/k8bSczao+MrbsONrOl+Zu6Eoe8F14YL1ituBaR9Owr4zR7RQmBY34s7eekURtRV
	 vorXkkX8sNAi9sPHdmSr2ztweEVKYDgBvztjoUk9r3MXpQ2R+O0FW596Oby8+OMytE
	 PQrgm6RhTBoiw==
Date: Tue, 11 Aug 2026 15:55:40 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Michal Orzel <michal.orzel@amd.com>
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH 1/2] xen/arm: drop unreachable EL0 check when emulating
 ACTLR
In-Reply-To: <20260811130818.123862-2-michal.orzel@amd.com>
Message-ID: <741f0868-d8a3-3839-4088-21a5a61b24ef@kernel.org>
References: <20260811130818.123862-1-michal.orzel@amd.com> <20260811130818.123862-2-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-c1860d/1786488948-DFAD487B-2023C837/0/0
X-purgate-type: clean
X-purgate-size: 2437

On Tue, 11 Aug 2026, Michal Orzel wrote:
> do_sysreg() and do_cp15_32() inject an undefined exception when the
> trapped access to ACTLR_EL1 (resp. ACTLR) originates from EL0. That
> branch cannot be taken. ACTLR_EL1 can be accessed by EL1 and above, and no
> enable makes them accessible at EL0. The only trap covering them,
> HCR_EL2.TACR (HCR.TAC on AArch32), applies to accesses from EL1 only.
> 
> Refer Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
> exceptions": "attempting to execute an instruction that is defined to
> never be accessible at the current Exception level and Security state,
> regardless of any enables or traps" is priority 18, whereas an exception
> taken to EL2 as the result of a configuration control in HCR_EL2 is
> priority 24. The former wins, so an access from EL0 is UNDEFINED and the
> TACR trap is not taken.
> 
> An EL0 access therefore never reaches EL2: it is taken to EL1, as Xen
> never sets HCR_EL2.TGE for guests, and it is reported with EC=0x00
> (Unknown reason) rather than EC=0x18/0x03.
> 
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>


Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/arm/arm64/vsysreg.c | 2 --
>  xen/arch/arm/vcpreg.c        | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index a02ad951f9c1..a59848889659 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -95,8 +95,6 @@ void do_sysreg(struct cpu_user_regs *regs,
>       * ARMv8 (DDI 0487A.d): D7.2.1
>       */
>      case HSR_SYSREG_ACTLR_EL1:
> -        if ( regs_mode_is_user(regs) )
> -            return inject_undef_exception(regs);
>          if ( hsr.sysreg.read )
>              set_user_reg(regs, regidx, v->arch.actlr);
>          break;
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index d6f9326b712c..749ce6d3a57c 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -219,8 +219,6 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
>       * ARMv8 (DDI 0487A.d): G6.2.1
>       */
>      case HSR_CPREG32(ACTLR):
> -        if ( regs_mode_is_user(regs) )
> -            return inject_undef_exception(regs);
>          if ( cp32.read )
>              set_user_reg(regs, regidx, v->arch.actlr);
>          break;
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 22:56:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 22:56:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388652.1629641 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtvOL-0005e5-Lv; Tue, 11 Aug 2026 22:56:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388652.1629641; Tue, 11 Aug 2026 22:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtvOL-0005dy-Hc; Tue, 11 Aug 2026 22:56:17 +0000
Received: by outflank-mailman (input) for mailman id 1388652;
 Tue, 11 Aug 2026 22:56:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1wtvOJ-0005bG-OM
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 22:56:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtvOI-004Bzr-Oo
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 00:56:14 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7ba834-bab6-0a2a0a5309dd-0a2a4509d876-36
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:56:14 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a7ba88d-be1a-0a2a45090019-aceafc1fa13c-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:56:14 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 864DA4013D;
 Tue, 11 Aug 2026 22:56:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67DDC1F000E9;
 Tue, 11 Aug 2026 22:56:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786488972;
	bh=IkPOp1N0D7iEgdaSnEMebWwQ6WObPXykfMcRZByeFSA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=Zm+AT4s0jF5vc3HFtULBSPXSBNxOldZVsui0p89MWT6ltgGYFYa4a0t6J1aHv7+T3
	 u8OMaeBIeF1d8HseJxoV/nBYvjE+jAz1Z7EmnAPkxycjGLlcjleKWia/q0jIJrL7f/
	 2tdtrv+FVWttW/24Gx6A9QYzhfBo5qJxz+OMNqbUWznlyWBZDwrr+H/aKdm5T7a+Q/
	 U/UfBhGX2biB/1ewRML13PuKyB9q5eTcMA0ieQdr6dK/dgUHzMrEc2d0e09LeWBu1M
	 0HgJDVx1TVuXCeahlqCnCKgAZGnpcrHwKK224x16TDYbB7si1h06nqS5s0V5Ue37ww
	 e9RCmgjRYEQkw==
Date: Tue, 11 Aug 2026 15:56:10 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Michal Orzel <michal.orzel@amd.com>
cc: xen-devel@lists.xenproject.org, 
    Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH 2/2] xen/arm: drop incorrect EL0 accessibility comments
 for PMINTEN{SET,CLR}
In-Reply-To: <20260811130818.123862-3-michal.orzel@amd.com>
Message-ID: <84b4221b-be6e-af25-e2ce-2d4aa7d082e0@kernel.org>
References: <20260811130818.123862-1-michal.orzel@amd.com> <20260811130818.123862-3-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-bad1c0/1786488974-BCECE034-A1C5A17A/0/0
X-purgate-type: clean
X-purgate-size: 2270

On Tue, 11 Aug 2026, Michal Orzel wrote:
> The comments on the PMINTENSET/PMINTENCLR cases claim that an EL0 access
> may be trapped to EL2 when MDCR_EL2.TPM is set, and that such a case is
> handled. Both are inaccurate. PMINTENSET_EL1/PMINTENCLR_EL1 are accessible
> at EL1 and above only, with no enable making them accessible at EL0.
> 
> Arm ARM (DDI 0487M.b) D1.4.5.6 "Prioritization of Synchronous
> exceptions" orders the two exceptions. An access that is never
> accessible at the current Exception level regardless of any enables or
> traps is priority 18, whereas an exception taken to EL2 as the result of
> a configuration control in MDCR_EL2 is priority 24. An EL0 access is
> therefore UNDEFINED and taken to EL1.
> 
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/arm/arm64/vsysreg.c | 4 ----
>  xen/arch/arm/vcpreg.c        | 1 -
>  2 files changed, 5 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index a59848889659..2ada791f4ea7 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -228,10 +228,6 @@ void do_sysreg(struct cpu_user_regs *regs,
>       */
>      case HSR_SYSREG_PMINTENSET_EL1:
>      case HSR_SYSREG_PMINTENCLR_EL1:
> -        /*
> -         * Accessible from EL1 only, but if EL0 trap happens handle as
> -         * undef.
> -         */
>          return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
>      case HSR_SYSREG_PMUSERENR_EL0:
>          /* RO at EL0. RAZ/WI at EL1 */
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index 749ce6d3a57c..b0f3c7759a04 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -295,7 +295,6 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
>              return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
>      case HSR_CPREG32(PMINTENSET):
>      case HSR_CPREG32(PMINTENCLR):
> -        /* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
>          return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
>      case HSR_CPREG32(PMCR):
>      case HSR_CPREG32(PMCNTENSET):
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 23:14:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 23:14:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388665.1629650 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtvfg-0000X5-1x; Tue, 11 Aug 2026 23:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388665.1629650; Tue, 11 Aug 2026 23:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtvff-0000Wy-VD; Tue, 11 Aug 2026 23:14:11 +0000
Received: by outflank-mailman (input) for mailman id 1388665;
 Tue, 11 Aug 2026 23:14:11 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3wKx7agYKCWMTFBOKDHPPHMF.DPNYFO-EFWFMMJTUT.YFOQSPKFDU.PSH@flex--seanjc.bounces.google.com>)
 id 1wtvff-0000Ws-4W
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:14:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtvfe-00CNle-Cf
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 01:14:10 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3wKx7agYKCWMTFBOKDHPPHMF.DPNYFO-EFWFMMJTUT.YFOQSPKFDU.PSH@flex--seanjc.bounces.google.com>)
 id 6a7baca6-8faa-0a2a0a5109dd-0a2a4502e3d8-14
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:14:10 +0200
Received: from [209.85.210.199] (helo=mail-pf1-f199.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3wKx7agYKCWMTFBOKDHPPHMF.DPNYFO-EFWFMMJTUT.YFOQSPKFDU.PSH@flex--seanjc.bounces.google.com>)
 id 6a7bacc0-6ca4-0a2a45020019-d155d2c7d108-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:14:10 +0200
Received: by mail-pf1-f199.google.com with SMTP id
 d2e1a72fcca58-84e048a801dso507382b3a.3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:14:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786490048; x=1787094848; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=eTsKS/p1yVC2Lax9wd0GxNhGxmDx0nu+r7cGaHMy4LY=;
        b=iQmIwmk9E0vYHZJ1fWufOQdD6SS2j0lCYKDaQJFEcthvOS7mu3bxSV3HVQJZ5EnWRl
         ENiYmzdk8QswpdGtJG1lWmMeOKM/l0HLH6SDHvJJI7LVVEPT93YR+8CRRrNVOvXSfVgO
         2nwZMEQKsqzEKT3WuLPvUQTueaDCiX7tzBPzskG4+6zAAv3a9aalih7qu4dAelO8NI7f
         VwhnpTty3WSmJ1sygsUKx86bnBx9xkitJHIh3EgbOdohv3MF8gv/4eoUI5sBBByR8ski
         C4lmF8nWCTmPvBUBnO2xKtPzNrmh9jLQa4zYqh1pbQNdLBo1FVn5BLtiBY7Mk50MEDD2
         nlAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786490048; x=1787094848;
        h=content-transfer-encoding:content-type:cc:to:from:subject
         :message-id:references:mime-version:in-reply-to:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=eTsKS/p1yVC2Lax9wd0GxNhGxmDx0nu+r7cGaHMy4LY=;
        b=LLRWj/IeJfGXNlR3WWenoZ/deQ/wNRZ9VioOkSv8w3GOY2zb4yUgnegZpQxY+K1L6c
         9WS5qVObRtXpP8Dm8tewQ2gvJqJwN3RHUm06rVuSXXG5UFIBPPDb7BOjvVNMV03B3e/E
         nhVHzSLHq7fRPuoWKD23lS/CQrS8kWAIYPtLYGFLRq6tm0dUh1hId7h+D56CP5Hq/Iht
         PA5Xq/a747baJiUvB5KF0MA+7/3D8CmW665BcWYNBPEH7B2JX1tMu+k55WQ0AjU71KTQ
         mvCcvqWWTuIxDbFsQDEsT7e+4lrw5KD1CICGxi6nbNRxQwPo6xoAuMIcMtnMuB97twA+
         0AeQ==
X-Forwarded-Encrypted: i=1; AHgh+RrQH8qimuaU+rqB5/pntVdqfxyuMQu6kuSYdN9kgj2+BET9oNUFCGcfnpy1s2/UtqeExu5Bbe2K8C4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxp0hgNbG1YcdgfcL95wxNRvNktlHWTYTtU7jeD2I5zFIv30z7l
	8cjFtVuCkJN3toKp+dBrR2xwnNVMoCP9NJ5CqBpwWFe5EAQuY9df/Mbghih3UsbeHt7XFGCeQGo
	MoI1f1Q==
X-Received: from pgcc19.prod.google.com ([2002:a63:1c13:0:b0:cbe:9dc7:9ef6])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3497:b0:845:e8b9:347
 with SMTP id d2e1a72fcca58-84fb5404a23mr903157b3a.13.1786490048024; Tue, 11
 Aug 2026 16:14:08 -0700 (PDT)
Date: Tue, 11 Aug 2026 16:14:07 -0700
In-Reply-To: <5efe7a3914a3610ee00a487379caff84af6aa731.camel@infradead.org>
Mime-Version: 1.0
References: <ansywxh0VX5rtfWc@google.com> <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
 <antQYJvRxJxOjtut@google.com> <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
 <antb01WqOrs-tztm@google.com> <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
 <ants4VjfAiblaWsl@google.com> <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
 <anuYNxD81OE3MrQw@google.com> <5efe7a3914a3610ee00a487379caff84af6aa731.camel@infradead.org>
Message-ID: <anusv0DloFhLMMoW@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-720697/1786490050-F20A82AC-09EAEFCC/0/0
X-purgate-type: clean
X-purgate-size: 1948

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 14:46 -0700, Sean Christopherson wrote:
> > On Tue, Aug 11, 2026, David Woodhouse wrote:
> > > On Tue, 2026-08-11 at 11:41 -0700, Sean Christopherson wrote:
> > >=20
> > > >=20
> > > > Ok, I think I finally understand the goal.=C2=A0 I got turned aroun=
d by the combination
> > > > of the name SET_CLOCK_GUEST and the full pvclock structure being pa=
ssed to the
> > > > guest.=C2=A0 I was expecting SET_CLOCK_GUEST to literally set the e=
ntire clock, e.g.
> > > > mul+shift, timestamp, etc.
> > >=20
> > > That's an implementation detail.=C2=A0
> >=20
> > Yes and no.=C2=A0 If the payload didn't literally have all the assets n=
eeded to set
> > the kvmclock fields, then I wouldn't care.=C2=A0 But I don't think I'd =
be the only
> > person to see a GET+SET pair and expect GET to return exactly what was =
written
> > via SET.
>=20
> Sure, but right now, even a sequence of GET+GET+GET won't necessarily ret=
urn
> the same answer three times in a row =E2=80=94 not just because we haven'=
t fully
> eliminated the non-masterclock mode (which we might never do) but because=
 the
> masterclock mode itself isn't truly the first-class citizen =E2=80=94 so =
we have to
> kind of reverse-engineer it into the per-VM clock data, and then build ea=
ch
> vCPU's pvclock back out of that again.

True.

> We *ought* to live in a world where that pvclock information *is* the
> canonical source of truth, and any series of GET/SET/GET/GET/SET should n=
ever
> see it change. And we can build our future-looking API around that model.
>=20
> I think I do stand by my claim that SET/GET/GET potentially having *three=
*
> slightly different sets of data is an implementation detail that we will
> strive to eliminate.

I'm not totally opposed to a broader GET, but we should definitely get Paol=
o's
eyes on this sooner than later.


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 23:38:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 23:38:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388675.1629669 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw3b-0003xJ-54; Tue, 11 Aug 2026 23:38:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388675.1629669; Tue, 11 Aug 2026 23:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw3b-0003x7-09; Tue, 11 Aug 2026 23:38:55 +0000
Received: by outflank-mailman (input) for mailman id 1388675;
 Tue, 11 Aug 2026 23:38:53 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wtw3Z-0003rk-Fm
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:38:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtw3X-00Ac6q-M0
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 01:38:52 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7bb25a-2eae-0a2a0a5409dd-0a2a450bada2-16
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:38:48 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7bb286-b7e8-0a2a450b0019-94a39217a844-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:38:47 +0200
Received: from pps.filterd (m0367124.ppops.net [127.0.0.1])
 by mx0a-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BNF3HD2385691
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:38:46 GMT
Received: from mw6pr02cu001.outbound.protection.outlook.com
 (mail-westus2azon11012020.outbound.protection.outlook.com [52.101.48.20])
 by mx0a-00498f03.pphosted.com (PPS) with ESMTPS id 4g07nauru0-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:38:45 +0000 (GMT)
Received: from PH8PR22CA0008.namprd22.prod.outlook.com (2603:10b6:510:2d1::20)
 by LV2PR16MB935061.namprd16.prod.outlook.com (2603:10b6:408:378::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 11 Aug
 2026 23:38:42 +0000
Received: from SN1PEPF000252A4.namprd05.prod.outlook.com
 (2603:10b6:510:2d1:cafe::7e) by PH8PR22CA0008.outlook.office365.com
 (2603:10b6:510:2d1::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Tue,
 11 Aug 2026 23:38:42 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SN1PEPF000252A4.mail.protection.outlook.com (10.167.242.11) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 23:38:41 +0000
Received: from pps.filterd (m0426315.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BNFS1q228402
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:38:40 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxpbskct0-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:38:39 -0400 (EDT)
Received: from localhost ([19.12.92.221]) by cmsmtp with ESMTPSA
 id tw3IwyVxBXy1itw3Jwq5Td; Tue, 11 Aug 2026 23:38:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=Lm1MIZUbcpt9Ppy80hbub2jSV
	/sdSaOmrxo0lRNr5TE=; b=l556u8A3xMQd91qptN3ZOkvbP4GvBpFVJ4zGlYcvX
	6D0mD2eZjlxBfWeWdTeg+/ctqckoGcHBixkadEnozNP9ucILAc0SFOzYYzkjAHdu
	w4aL8HfdDLAyY0jUO1vEXBeHNYFo/Chs7a9q2dkb4rqP2PbnG0tfEPL0I+ZIkRlR
	eoHoqoCP0pjCQsTnsDjvVpfG55V46n1S2OxXJFHgi1grXq+a51uvE5OlGjCwgHEA
	VDMJEWiUIethqsj9rDtLoYBG2JJVHpk7UDxZ9XB7KNXCmd+qwI34MOdz7Mp689Tq
	QWHz3k+WuvCf5RQQCQWdI7+sho/Esz4jo4GZ8eLZdlVIw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CIxMxcRgLj+20DeiA77F5w/a2jnjpgFUlK0Cu/SuIGQ9waWM5m17ChrQIXFplGA4gqjvoKAzxvZ8j4Bksn3We9cILiKqdUSNVyGhCz8+Yux4e7o68XMkYSPREn09JqYUdoV1dnAvP1mOZm22RarMipSBv5c4QfQ8hCUjjh9BLWzDEkFEK0nIjwChKf6SmTUNOa1XM6WHQf8fNnl9nvPkBDVHzcX+UBTtPhEOV19HGbhttGOPvH8siGwebh/eHV2m9tYzoKJCS5NysAJx+pE5ggIJO+99XqiXIgJrxpJN3mzcdVUQ1yPBY0j48/75pMQQca8ElfmDvgn7yyiegJ+SaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Lm1MIZUbcpt9Ppy80hbub2jSV/sdSaOmrxo0lRNr5TE=;
 b=ZIAFO8SK3pYmp4mtBpxl9r/2kWFIjA+x0CkWW3jsJNd3QUlP3U9GbKYleC2y8FPEzI6yVAhpG92ixEUmSg+Z55Hge2AeVuJkQ+Nuu343FBEAT32Bs9jpw9LY/aYmJR8cOPpGzcDsV0IOw5mLlBSP2WnrKJtIumzjsQJfpmIO6bQBsixAarkfj4XLNvTHMQj5Pewn1Z1P/eAxl5m6hjj1ZbQ2rhtj/2wlRe1hT40Ln1IFd9ZxO9ZOuAuncKqcxADql+0ibUcpqj5NOJYod7KcZj3T/FPt6uOVLg6SmVxnGBIdSJYgE49Qr042XQj0XB1k0K2EyWDKYwUjVBxYfiQxaQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Lm1MIZUbcpt9Ppy80hbub2jSV/sdSaOmrxo0lRNr5TE=;
 b=IUbR57kjXpM6eWkOqhEYQokuomAJYG9ioPd/3p6dXuY6r651ev3quCqK6oMx63pb+8fAwJFxo/p5Lu5G2fk1m8TsfHbiLoBN19IWPQ0WkOmiyjbKEXcchWgdoQ8/KBCQKo4k0um3rKjAAteyZbLZ8YmMN8RBx4rE4m5auP9qCkQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=Lm1MIZU
	bcpt9Ppy80hbub2jSV/sdSaOmrxo0lRNr5TE=; b=Q4yJHupJ5WgJOmtyBNR5IhK
	hetTz7vQ3v0ZAL2Xn2tLeJlvZPTGTQjouR7aq1e95/oVkRSAoxQIHuqpvUmThSfr
	3GIKdIesi3dpTP6m6pb/o2HelrEtmbs3Sxa1r4lrHMQqKq7vb9m/ufta7fDfTIY3
	gC0kJVLjwgNeDYzfpcflx4DpSZ95GjwsqH+aUjycAhkqeO5hezp3AUPj+w9PoDI3
	eK6N5V4qSG7cbsFxMaIyLQFBbI1oJGs525+gReTl2KCiH7pZFxTsDQCz30j5H51t
	f6dofxUSNAUFRZOsWRhprZ1gUqEX3cW4LUwW5idUwMN/czhQ2CD+mgKf0pwdcxA=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=Lm1MIZUbcpt9Ppy80hbub2jSV/sdSaO
	mrxo0lRNr5TE=; b=rf7B6diqH4TyXe1I+WfUDW6ftZSLJy0FJUAiSkSxJ7MY/nd
	XvP0J+M3lTZuZrcE/jSifuA2K9dX0ywGSLj88V4Q7CURIRgZ52cGn4MyPhkARX4D
	FI/1hccLsWnXnlxzkTS4aArDg96FqfYqSJFC8jng8i2rZdrroJKrxpax08fvV6xv
	0h6VIzk2hZf4URuLyVgPSz82RpMMfRXi3jZE+qJHckxVH1X2AHEa3TNabc/qJAKU
	ZL6my8K+r/l80WY7NiEieYMiZc777rBsL7f7w47lAnQ004bT88S5po8YYUG0iEi6
	Xc8E263pwhVvMzBTPwkAlr0syU4n/hHPxtHBa5w==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: tw3IwyVxBXy1itw3Jwq5Td
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 0/2] xen/console: updates to rate-limiting
Date: Tue, 11 Aug 2026 16:38:22 -0700
Message-ID: <20260811233824.1874525-1-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608110197
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A4:EE_|LV2PR16MB935061:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 06ca242d-86f4-459e-6439-08def801acf3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700016|1800799024|23010399003|82310400026|13003099007|6133799003|3023799007|56012099006|10067099003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	gsTHsEq/+KgchOnNbqWjw3VahIWen2JXfhDubQe1pUMKzOsu0o8cEnOaGQ9362qJuWeAFQQjmD4EbBEIaVrtlRAZ5SkZE6trZ3z3tw9P4DUXKAZD2QlnzzIqNk8dh019f9QsRthdCjVwITPq6Hw1vKv/Ql001YcS0Yu/8RY+NoIY6pvDs9CvQL25ju5qOq4mMPY+JTGaksGn1ta4u9lrDaFFtbyNCSNTYUGx4LVEb7mJtxSdDKWt3aZHmhcdzpF9fRT4Vt9XB4FR4vf1+JQljGMn6TkzKVxtMK4vlVnS8Mp1nfOeMBzFwBoE9Mv2uhHXMxdugVXfuKugRgHesT0Utnt6vcmwN+Mt3fQ7Nd77ihDIkwUeFEV9SeiCq3CIEYj/Fi5lMKduirIPER5bQtpoCskYEcxtlYBQG//8PefITR2XQf62Wrif/x4fVkGbjkuaR4Hm9P+qIHdapn4zB3do6eZBpk+qbV+mF5nFecDY3jYUvaBxX56M8kjs6PyLmhZfg2aK33+Yogvl535irXwt0cfowvnk8aeIJ62hCDSJuwMdXIGoueNic9El5+HpjYIG+p6wH98vww/6FGZ5PmcmHj4ajQDssjayp7sU4pu5j9EdibPIgwguiKJcvi3EHMCXzayZq8xMsLN+4kpb08nAJ9DLY8nkCzA51AuP2GaO17zCqN6SToZoTRwR8oFE5mqdxEvwf6r7laHB8t6AyNFzYw==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(23010399003)(82310400026)(13003099007)(6133799003)(3023799007)(56012099006)(10067099003)(11063799006)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	+2kQ9r82I9XtR2sWW5CIJtFz613i5np3WRkkAbeb+Ri/bRVg+ezuPAMdLvchbkjn5ZwnK/J2gfzCdO3mJIcDxm8yeAdIHlU4SeGqN7xjMUFe85C/rNAJIklaixzQI4m5ktABBBECh+8J3UzRC5JUeihRY0Ga9Z1tbGVY5LFASK7gdRQMTnyZr/vWrhtwJHMVyqBMFDgvcNKQwhXVnfXVMateCvU11WDN+h3NRGZPsORHjax3Qb+YE0uMcchMz7agUuNnVDjEZRirSX49Y1XDqP3VGDelc27waxyY6I5knO5G1Vv/eIC1vs9OaSp31OFm1kyFoaV4Kl5vaHbFAZzY7FIdXM2tH9U6xpr7Q4G+GMHX9zrcTV5lktwhXVO2w2lBECBJgNT85lqW1EiuOfMflFlHrMK8Z8VfJIb9PfgYCltiOx3Oa8bx2HW8EC7x0m6Y
X-Exchange-RoutingPolicyChecked:
	Fsapvt+5hw6dzzx2I4pRQYW4FyR2L/pIxR11F4oucH5inmVYVvZABXU7hcabAX4kVKIYh2dTml7/EEr54YV48chbQTz/KNKAqzBwUmtV0QSif4gUhri9JpjTJqrN1wH1MwHHqxyZFQ1Xu2iJvZK4ZATmjF+pxL3uhXAG05yQ7lzNG7CC3UYRjwZLOTgcPfMHy8LtMG/f2GnJmJYtLzV+nuvI2fEgFcvHvcrzlP0E8Ti5Qf2p13WpVTqaNFHeQFhcItCKDLD4/BIWvIYrryp2517Z3VfNBcOZ/YbxDoB0/E+lKXG6udMtv52+qLzkbI0qAvWfikVflrCdUVAClGYsCQ==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	nrr9Oxnwl7Criz7dINc5hOgSjJAjHV44QHk/PAlWsuDDd7MnQWR321OsDFWQ51BZ0ysv6iTEEHKIYxWTxscdOdZlk8MXtOHcwkC0/fxPx+fKZEe4R9lwmthtzG2gSOErRsbsdwRpQjZps3o3YiKcv3rQi/zY6FsJ9oAZ7gtFdRrh/LQDbkuxkdQfN1dHVOB5txe9vCg9VFxnrcgIbunoauAfOQ+QaAf1dxRRmJ/6dLQg3WJw1xsPqj/H+KbfaaAqTtto1/Csr+kowjOL6P9JFNBP2EPdzOZVSbRTv+BKUS0hMaRqVwOZWzokECnZt40shG1k9VmpiLmb8XEzTCkKxp2Hlno8JLjrcXHgxi68755L43CaFLQH2mqgKzDK9R8gHkNau4UTQCfkQ5Qgefd8iocy76zp5jSfg8IpHUY+VGrM/zVFoO9RkpUEUe/QYCXZ54KmG0lS3ITdoXLAx3SvuZq6fKbBA4KyPf6h9UPa9Fy6posZM9HZHoKP99xrYGossFeLYC8rCN8rVXyuoHBeh7ysL0QdbESEEqv6Eog/d5gcy3E8BFWOZ1qMacc06QzrBj+HTI/jSfcrhYufRopqxClWJFLjvJRsJdzI63Lv8jyYmRuDhBQkQmWuCU1XuNMJfXC8SBYkV8DPPug3LzDDqA==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 23:38:41.1680
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 06ca242d-86f4-459e-6439-08def801acf3
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR16MB935061
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODExMDE5NyBTYWx0ZWRfX4XTzCkyjGNGB
 ira8tAwnV+oFUoZrbOLugRIW0z+qGWCcM3UCs0ZPaCXY0tAXVEt6XOO3dc7gnfYDAcaogJKbMNW
 iTzr1rljQEaf9uT7VwZxvxCTaczY7+Q2YCLmecy9AqraXptH1QfEScfMvgrqKcSRH+2gudgaz5R
 4fZkvvqxb2Yg9iOzqGi6T2uUmx6ysLtu5pwyXyiBiSBLedbLnvpZhI7WD+TCh9BWcPfOB73XUw2
 0JkQoJjr2IVWpGebowew0EWg0I+yir3a9hrh/OzE3gWHXTPST5vIBdZRxtu6j+gkAWb5wkH/qVr
 4NdpBHeTUC7nzu1HDa5jJboArTN0JD6W1+uVXJC5Nk1ePSniVMGFXLCzG7Nh/oMPdlHw6T/5rDI
 8iHTxWPlSxR6IRcgEfTLzseHxFmEHIo2gCT3iUBx+ceETCjyQVVGCHF34QP9mYU+zThG3t6tLpY
 uCVoQVHCB7U1A1jtcmA==
X-Authority-Analysis: v=2.4 cv=CM4amxrD c=1 sm=1 tr=0 ts=6a7bb285 cx=c_pps
 a=wPn5mG08gX1eKnPfDThLSw==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=YJXg7OVxOWrJwj3yZo-i:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=2bYBL94XiJOHY0pNdiQA:9
 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-GUID: QSnvp4bJtSk2v-AZJ9Ojc63bAXpXnLuh
X-Proofpoint-ORIG-GUID: QSnvp4bJtSk2v-AZJ9Ojc63bAXpXnLuh
X-Proofpoint-Spam-Info: AW1haW4tMjYwODExMDE5NyBTYWx0ZWRfX4y6ZmYPffmi5
 JHTCqWGtipXlssFeaEUl536T4RcDHSb3DLp3IUvFGoM7Uyb8ucYYmGt+zaF2wL2PyH6MhIvss60
 TRrWcaDYC6LlynTEs11bdSOgWzAZf2vy7+dsBDTKrneps2vlF7Wx
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 lowpriorityscore=0 impostorscore=0 clxscore=1015 spamscore=0 bulkscore=0
 malwarescore=0 priorityscore=1501 adultscore=0 phishscore=0 suspectscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608110197
X-purgate-ID: tlsNG-42698a/1786491528-A96C29EA-7602727E/0/0
X-purgate-type: clean
X-purgate-size: 748

The series introduces compile-configuration for diagnostic
messages rate-limiting.

Patch 1 is a fixup for the rate-limiter to adjust to new user-defined
rate-limiting parameters.

Patch 2 introduces compile-time rate-limiting controls.

v4: https://lore.kernel.org/xen-devel/20260729072520.1556970-1-dmukhin@ford.com/
CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2751536715

Denis Mukhin (2):
  xen/console: re-calibrate rate-limiter based on user input
  xen/console: add build-time rate-limiting controls

 xen/common/Kconfig         | 30 ++++++++++++++++++++++++++++++
 xen/drivers/char/console.c | 34 +++++++++++++++++++++++++---------
 2 files changed, 55 insertions(+), 9 deletions(-)

-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 23:38:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 23:38:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388674.1629659 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw3Y-0003kP-Po; Tue, 11 Aug 2026 23:38:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388674.1629659; Tue, 11 Aug 2026 23:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw3Y-0003kH-N6; Tue, 11 Aug 2026 23:38:52 +0000
Received: by outflank-mailman (input) for mailman id 1388674;
 Tue, 11 Aug 2026 23:38:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wtw3X-0003kB-2o
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:38:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtw3V-00Ac6q-U6
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 01:38:49 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7bb209-2eae-0a2a0a5409dd-0a2a450c9bf4-32
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:38:49 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7bb288-f479-0a2a450c0019-94a38ff1935c-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:38:49 +0200
Received: from pps.filterd (m0384717.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BNFklQ2299678
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:38:48 GMT
Received: from sn4pr2101cu001.outbound.protection.outlook.com
 (mail-southcentralusazon11012005.outbound.protection.outlook.com
 [40.93.195.5])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4g09vfsyv7-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:38:48 +0000 (GMT)
Received: from SA9PR13CA0029.namprd13.prod.outlook.com (2603:10b6:806:21::34)
 by SJ0PR16MB4287.namprd16.prod.outlook.com (2603:10b6:a03:32a::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.12; Tue, 11 Aug
 2026 23:38:44 +0000
Received: from SA2PEPF0000150A.namprd04.prod.outlook.com
 (2603:10b6:806:21:cafe::3) by SA9PR13CA0029.outlook.office365.com
 (2603:10b6:806:21::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.11 via Frontend Transport; Tue,
 11 Aug 2026 23:38:43 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SA2PEPF0000150A.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6
 via Frontend Transport; Tue, 11 Aug 2026 23:38:43 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BNF98K145521
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:38:42 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkgcbhbc-4
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:38:42 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id tw3LwyVzXXy1itw3Mwq5Vk; Tue, 11 Aug 2026 23:38:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=aDv
	34aLxTw8bi99AIhF3WJYALFaiu1fRpZYpEJyJrC0=; b=fx6qaIf6H0TEMXOOZkZ
	dYY8ai07IMg9N140fha2w1E/UK40eCc67Q5BkRqk1KqHncLRbyiXlmbXBzM4nKcW
	F5bbSTvf/i76A8AQpnYDzoJH8dbDom6todHCQ+MFc6bgHSgurVsA2pujtskZ0Tfd
	XCtD5TkT7T5GiTmfyNbwcx6LgN9IReuYWbrsXKzHPZ2KrkE9iXObJWiQHr5hXPo0
	12lgPR0t9gNrQ/VYieGIJriiVPd71BjcMbR8fdDReHfeO1pCWHEI4SV4UTU11Onh
	uWIfMYoS0Ue16xPODPmefHFDkRffTc8H7MCVGHk6jmaLAFa6oBXNKy4m5z/En2rN
	Yaw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=slugA1Um1c9GqPRvWyu9mQmYagXeXp3SPz86IpDtCTT3NZh6EMTnXY4HiSzI5hrTFhgbDZByDmwEqtBUxHKLr2j04VQ6HIzf7Gf0gkPAd53baV3yzh28ag9bhZ0ey+VE230UBO5hcnrEStd67jff9Vv3nXwRiIy6LGmo8x4g5Mh3OgK7XMQHQSt4HYh7EntbHJWYjScVf/iVkWBh8AlsynAxIYj/YY39j0iNm2aL0TpHM7R/UGiHVFGCjPEY4DbD3hH9nqFR6snXfxaF9mnrBiEkn+Cc1feRLNdcB8rCUzsV/oKS21Cs+UmI4mSoE/ZOFKdJadAowE30BRWXokvgkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aDv34aLxTw8bi99AIhF3WJYALFaiu1fRpZYpEJyJrC0=;
 b=T7SK/sMVQdXU/Fc4SDfnHAUcIzBS5RbhFbZWlfgpTHkyzMA3Ue81Vi6TpilTKmoKv3JVX7tGAMIZ0QROntMe2zau4a+3WKVWnvo8whj7rKBLYxWUU7P88rAwzx1MzqLlr5B/SjhtXBkrsXJY/Rnj05LHfuWxX6U5Ma/nRtLKOJyR6d0UvRZFLe60wZMJcu3uchxfc3JKKXEcZXaBLw1WiESJyvfv8iScgLYAHYr4nnba/iWxUaM6VxIkh+aFWYr8xstK1mgyWiP1EE5w99GpGyR9OigCqp8VvLwo2MDIAIKePBGs10SAQKqqOvF+HEof0Ydll8+lSRUBnzqAXgFC5Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=aDv34aLxTw8bi99AIhF3WJYALFaiu1fRpZYpEJyJrC0=;
 b=IzFddZgpMswWa3vIfR9IVD5vuoMJjke07EG2qfdWRPH3J24AIAYPLJ22f9Rsf1Nybnl77ilOf95JgAjE3/P46+M9oOT20zDSsHsChXX2FYM+2HwAQDiS10ZTBtQ+fuz9k8JCjRw5fE8ExEJ4hp+5vKgsrEeKWuLHi2WunSMHnsw=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:in-reply-to:message-id:mime-version:references:subject:to; s=
	ppserprodsaar; bh=aDv34aLxTw8bi99AIhF3WJYALFaiu1fRpZYpEJyJrC0=; b=
	jrATgFYJIWNLb6aSwhy78pxaOEzEmH7Jbsn9BYtAgriPC350J0zowiwzQCY3nT4A
	8C97aDnEUow7kWeGhcV/9s9d0R5MIc1hgntHN4DLdOMiaqRvDQw6asAVjh6UK04X
	S6uIrYDBg96cgVlZSDKD6jG3SWGCx9KuvJaCKjhPXaeLC+FOzFTJT+/DNSlyucqk
	fbppUaIrrrQ67eC0Y3NnQNxRFizjDhGXfvS/kTQSbn/QvNw3FfFFVUPMJSV+i0kB
	O5mkWdf0wL/QEwyglRwzAa4iqJ8b4AYsDJBp/6j6p3Ddhmhb4R5OcYl244YVZ8rb
	VYlrrN4ZaQa62SYJD/Lp2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=ppfserpocford; bh=aDv34aL
	xTw8bi99AIhF3WJYALFaiu1fRpZYpEJyJrC0=; b=oQkosJnG0JjxKnuM3bErcpB
	O3xpKFV7x43c6K4jfTDJiTZdvBWHUPmBNCgr4gbYeq8u4KnTityzEjMjMEqIWQY8
	jRx3bZonyPL0EKF0dRz25aY+uCrF9SpKi8s28DeDkGM2JKKImOqyvirve+mMxx4u
	yUDy3sms3gaqhWypf2ckuM4YH4+XHFsGXW97iSuBMc9pvwl996jm+DszoRAW09Of
	y94qRJ1iHviZg2wLIwiJjuTa+Hh4eOXQSjhDk8c+Kz1b1b3GImH8XrCSatVKeGe0
	EkqFuCc+aedIuxBWEMn1FTGX3t0NrNoQzA/vOeNkpFIbo+6wl+yLzGNA8b9QUSA=
	=
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: tw3LwyVzXXy1itw3Mwq5Vk
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 1/2] xen/console: re-calibrate rate-limiter based on user input
Date: Tue, 11 Aug 2026 16:38:23 -0700
Message-ID: <20260811233824.1874525-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260811233824.1874525-1-dmukhin@ford.com>
References: <20260811233824.1874525-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 spamscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608110197
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF0000150A:EE_|SJ0PR16MB4287:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 5eb0cc2b-4d9d-4eb8-6eee-08def801ae2a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700016|23010399003|82310400026|1800799024|56012099006|10067099003|18002099003|22082099003|11063799006;
X-Microsoft-Antispam-Message-Info:
	K310w6ooyelA6HZwbTiKZekKy5Owy/bU2yjgSnPTOKG1dDmGbOzpnakeYqboogjqUTLPiUz+GoWh24UAG4oZEiVyWahjrTo0vnQOFR5kDu/rHTZYKDviBGqrTHmvki2T6wi/G4YHyyEeZ8t4TcSsRd5SsFO4+FJIqsidv9E9uYDqK74Li0IcV0L2+fazcI1x05/xx4JohvFNBAbaDAQgTYqYVXbiAImujcYXyYQzwC6wnL8EoBaUr1yK2mvJRGxAGR8fZ/AberKKItyZ/Tq7sGb8Md3bWlOdjT8l3q2sdE2sx/+1bn8Q/bTYMemN4AKhuiONv8nLfvV7S7sNRsz7Xr1UczSkA6hGdAuKilpQ+CuMn+PHPHrJRiNhB08GQaSILkSKzefNWH49Be+50M8m0p0+iCTT16A0wt/t0QkhK361P4aYyNmd6jwj0v1VwKexknA7CIAGLlCBvCcgFaWvB17X3aIl+4JteP+oHzlPrIlRQknnf1Yt6rQTeGJQ3/D9g++6U2boHLLN/VR+ry47UiJsuALW/mqqERAe40Bqh8kRkytishQ6zB02EPx827HfPC0Fb5L3xTbIyUKrcf7ofpahbOMajJEgWmmAoeRG2hEi9MFCAFqn60KEZUypOyskbs5SR5PxNq2uQZln0UuFCc/pnBPkQuoMUTBlvdRVTNyUbLw030Ylu6GyRNzyfajDkofjXq7AxGngL1jmWMWmNA==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(36860700016)(23010399003)(82310400026)(1800799024)(56012099006)(10067099003)(18002099003)(22082099003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Ao9bHbQnZezSwR03DF2mTrH4O0bG8sEthRJX20QC4gwMaluKJvvWsncsHxe1bmTFGv9J7qc3FTuSAYtfam3+zZiOSwRzvxHYPvwuDl/KBKEXtMOwS0AZ0b+A36ph9R7ISxHUc7VupiWU6j09EW7X21XlU1hYyQx3QpTWHOYYVMZPVs+W4x6u/wQK/S+nhGgGhwoDgNMnKsUy4+3fauYorDKVtjJGSRFHlMrHu0nvvZLCwf4yhj2UJCLD5N4085mgrird5A6goTaw+EtrB5x5PfdiAFmAdvOLMJsw3hOUC9kYoA/eqljyLf1PUfVX56NU3mwvR+OL/S61RsW8HZrahZuLAiYK+5i0a96kbr+Vy8/d9bYtjzEFh0JWw/Q18e1bJLj+CUhchha0Cu6TWkhLzvicJwPNRfXyqbIxfdxkKKQ+UVCHwRJWFHQXZVYE2OiA
X-Exchange-RoutingPolicyChecked:
	qOgLFG6+uLGpqaKHIon8n0pfj2lGs7AjVbcYQh5FHGpxDXaFL198LYyarCvxfNiQanjH/8izaTWHKLs1y3n85ZboG7BDRJskPXvCjaCIsCOd0pzkLcWH6tjx0chhMiijOODE92Twv0u8mA5j9XTH7qhr2Vg5T/7lsFznDy5ZOF7e9pqacg95ZeZoMSlL0+kZK/6NEoQdx0Ihhyjfbu4wxVlmP2EIhDBP2Rznq/YFIYpgE8UHeNv1etpe9de7/+OptAzDm9OmCo5cVUUYJyNaGKmTDzY5ctYe/r+Nyh9Xta46fK/pOT5TG0a0NvZg45P5uCzVqDaQijb66PLtXEGGHQ==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	UjRX8Gejm9jQ3H71qtwdx08X/5KKf9OUK+NezG6kike+CE2Q68rOR9KujI8EpmtGO+NIcTWIPu9Ra7iBVuwQf8bW5VoZ9/L90L/YgyQu/kYZIB4lopz8WWKQt5i20VP6yjPVysZF8x+YtY7RJNSVPUHHw2NAbmkT+w2NwqEdz1B2oqbj5g56zsukGZOL8lV9eYbAoZ5oWWL9oWJi/0qsB7pZbYO4LOj3DMbBVi1UvRePTetwYR+BFB1TiTo2sk9gmotIJkQkrgBj/3NmLeu0S93mWRYbEGqeJf07Znk+rMdvI9bUEfFkUllYihpJagkmwmfI0vqbM135ch+1H5FaGM59cHoQsn2qc0croSiuGYQpacw4c39ns+wPRlQ9aK30EAiyXhdlUJmNQ9ND+6LkbrJOuMXew6phQQPBud8FtfHEYn4xFQci5MKtViqxcqXZ8TBxI7J/foDef289fj4BVomDnAXHQBq99Bk4oBidTCrJZrjyedfTYIwHNWk9C5Z4Ian9MFOkTHDvn1cJBbUMhfQyIEKa3y7RhSio3u7al49Wfom/4Wu/RyWgXrFEnnh45v8/yy6JCuohZs9UMieje9giFtt51xSK902A3c3Y9g+UZVdvWPBcyJtrKGOXbjQop6slr3uU/87VkOA+1XTTiw==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 23:38:43.2292
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5eb0cc2b-4d9d-4eb8-6eee-08def801ae2a
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF0000150A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR16MB4287
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODExMDE5NyBTYWx0ZWRfX8HZRh1u/ENzc
 CgtXjAy2dmMlyxFcrZX/RNpjOdZpKRMGPDJDboy5mZshZp2OThn4dGq8J7EhwnwSMIUzokWn0UC
 2WF46PMIVuG7pSv1fnrzdm1RMquJR2CuS1MM9cDpuPr2LYWZ9/qbcoIdLHgectw8JtIw08vLWjX
 jPRv1ln53Hi2O4VaD07cKtEIQ85VLnZq2R5Zt0LoL0k/lu+sSKriHwON5UdJLE0VrozTJcMt6ld
 ccD2f6ZE1N1skugla1izpDQCdVlmg1UaedGnNSnwA+Kn133Ea4h3dBGFCYMvVujK51lnraKpYIX
 AAavAin64mISVOJdttd0eGiSH6VVYz9cyBqHT00raR6Crm54YKH0MvSm61NkOfyjDLp+Ry2lW/z
 9PBKrVmVMlpuj8Hlj59fBF6Ys5TIIh+ahklUuHxUsnqsPYY0J4MxolhIRdyV2Cw8U5/gT+dyO1j
 XeucRmat/s/s4ivBp5w==
X-Proofpoint-ORIG-GUID: -e5g2b2OAmw3FpNFdoQgMFGtqYokgjgk
X-Authority-Analysis: v=2.4 cv=d5jFDxjE c=1 sm=1 tr=0 ts=6a7bb288 cx=c_pps
 a=Wms0yhV2hyGqr6ZNmSx9tw==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=AHe91QgOk3R4nFVtG5At:22 a=cbNQJ9GKAAAA:8
 a=tqzJaSFn5nTAlFOWASwA:9 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Spam-Info: AW1haW4tMjYwODExMDE5NyBTYWx0ZWRfX5McEQdGOhmwX
 CsFuJ90Pu6isPWVJ9Vsn3t04DqAkGkDi3R2wWua0J7983S3mmPibuVHFxBkxsQUSo2DBl5SuUai
 S99iy37POfrD45HxCySRsADzvPR2d/lcjoNUtI5Iv9O5NDfTbUXL
X-Proofpoint-GUID: -e5g2b2OAmw3FpNFdoQgMFGtqYokgjgk
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 priorityscore=1501 suspectscore=0 lowpriorityscore=0 impostorscore=0
 spamscore=0 bulkscore=0 phishscore=0 clxscore=1015 malwarescore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608110197
X-purgate-ID: tlsNG-d25034/1786491529-038D5A5B-B057826B/0/0
X-purgate-type: clean
X-purgate-size: 2263

From: Denis Mukhin <dmukhin@ford.com> 

Current __printk_ratelimit() relies on hardcoded values 5000 and 10
respectively to program leaky-bucket message limiting.

Use 'ratelimit_ms' and 'ratelimit_burst' variables to re-calibrate
limiter.

Ensure rate limiter is disabled if either 'ratelimit_ms' or
'ratelimit_burst' is 0.

Fixes: 26cf03554a75 ("[XEN] Implement rate-limited logging.")
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v4:
- dropped 'initialized' flag
- updated commit message, including Fixes tag
---
 xen/drivers/char/console.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ea4e3ff34178..56bf111ef181 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -33,6 +33,7 @@
 #include <asm/setup.h>
 #include <xen/sections.h>
 #include <xen/consoled.h>
+#include <xen/xvmalloc.h>
 
 #ifdef CONFIG_X86
 #include <asm/guest.h>
@@ -1286,21 +1287,34 @@ bool __printk_ratelimit(unsigned int ratelimit_ms,
                         unsigned int ratelimit_burst)
 {
     static DEFINE_SPINLOCK(ratelimit_lock);
-    static unsigned long toks = 10 * 5 * 1000;
+    static unsigned long toks = ~0;
     static unsigned long last_msg;
     static unsigned int missed;
+    unsigned long limit;
+    unsigned long elapsed;
     unsigned long flags;
-    unsigned long long now = NOW(); /* ns */
     unsigned long ms;
+    s_time_t now;
 
-    do_div(now, 1000000);
-    ms = (unsigned long)now;
+    if ( !ratelimit_ms || !ratelimit_burst )
+        return true;
+
+    limit = DIM_MUL2(ratelimit_burst, ratelimit_ms);
+
+    now = NOW(); /* ns */
+    do_div(now, MILLISECS(1));
+    ms = now;
 
     spin_lock_irqsave(&ratelimit_lock, flags);
-    toks += ms - last_msg;
+
+    elapsed = ms - last_msg;
+    if ( toks >= limit || elapsed >= limit - toks )
+        toks = limit;
+    else
+        toks += elapsed;
+
     last_msg = ms;
-    if ( toks > (ratelimit_burst * ratelimit_ms))
-        toks = ratelimit_burst * ratelimit_ms;
+
     if ( toks >= ratelimit_ms )
     {
         unsigned int lost = missed;
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 23:38:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 23:38:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388676.1629673 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw3b-00040C-Dq; Tue, 11 Aug 2026 23:38:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388676.1629673; Tue, 11 Aug 2026 23:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw3b-0003zq-7a; Tue, 11 Aug 2026 23:38:55 +0000
Received: by outflank-mailman (input) for mailman id 1388676;
 Tue, 11 Aug 2026 23:38:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wtw3Z-0003kI-Fn
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:38:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtw3Y-004Frg-9x
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 01:38:52 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7bb1e2-bab6-0a2a0a5309dd-0a2a4503ea64-36
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:38:52 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7bb28a-fae8-0a2a45030019-94a38ff1a5a8-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:38:52 +0200
Received: from pps.filterd (m0367128.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BNF7FD2550157
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:38:50 GMT
Received: from bl2pr02cu003.outbound.protection.outlook.com
 (mail-eastusazon11011016.outbound.protection.outlook.com [52.101.52.16])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4g0cat0gsm-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:38:50 +0000 (GMT)
Received: from CH2PR11CA0023.namprd11.prod.outlook.com (2603:10b6:610:54::33)
 by BY1PR16MB6506.namprd16.prod.outlook.com (2603:10b6:a03:4a4::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 11 Aug
 2026 23:38:46 +0000
Received: from DS3PEPF0000C37D.namprd04.prod.outlook.com
 (2603:10b6:610:54:cafe::e) by CH2PR11CA0023.outlook.office365.com
 (2603:10b6:610:54::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.292.25 via Frontend Transport; Tue,
 11 Aug 2026 23:38:46 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 DS3PEPF0000C37D.mail.protection.outlook.com (10.167.23.7) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.6 via
 Frontend Transport; Tue, 11 Aug 2026 23:38:46 +0000
Received: from pps.filterd (m0426318.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67BNFguc174340
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:38:45 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [3.215.31.156])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4fxjw5bn47-2
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:38:45 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id tw3Ow46T2QLYTtw3PwVLgG; Tue, 11 Aug 2026 23:38:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=lfC
	78eHoWgYYe74UlSw1vBBwAHUxfo+fJj/g8JTvi60=; b=Z4x6H+bQFOAprHkQt0r
	2LEnNBOspDJ92HcxU0e77iIz6QtU4S0j0aEldmPz+ImVgSbFaR81QFL05h+a4zLa
	xdZ/pXJ3vR0bYxOKvW30hMmP104pIgn0DR1b/EYCq/JtUqSq5Y3qaHOpZyJt4onH
	v1IE3cLoX2kpdWEjxBG7BbNm1uFDiyr9/BcDag1Z185Pl7gaUozuS9/dJhKlGW4n
	qrn64YkagLm/cld9YFhYLimkVOl4u6Jr0tKMcnnAmPrIbhA7EEwYur4l54wyxeee
	7prDzI0X5MQBPOOIH7tg5KQ+GOkK311EhROYY6yIrlprWO8DJJGvirjzDFTHssyB
	o/g==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F+5jid48BtMC1HBJDL6OMtAgFq6/imvmdrkGQmM08DuTNC+dVxEPFDxp4lD+TfORuij3Vk20cK3NLodTS27ms0MT1iRbR5VxsIS9CqbPzaemej1VWVX5JLK1zoOMqk82dMoyJz49ih3WPEfB76AD/dGqpRHpPuam+7eyFt6H7X1bKk9MMq76AA7Z0sHgUv4QnXKpm8Y6e/3XX+4T7UYeSYnGohGksnL8ZZUdPQwpwnHueSVrxk8pVCximMABawxi3er/51XQIppaOSYdX/jXeiIpdZFaAwE9xN4YRF5T1Jkm5YqOtxvNYWBoY7aOvHA3LO/RH3ln4E4pbQZNeTmoRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lfC78eHoWgYYe74UlSw1vBBwAHUxfo+fJj/g8JTvi60=;
 b=Mqf+Sw3W7jzL3h+h1Ut8BPqO8Kb/TV4p+L7qFauRg27fFlCi1PAP8A8vnlwBLw5JgiKUcmmWVUbsV79PKw32EOBYzQGNh6NEk2uYdyeAqd1PU+kYVoJBmYwOIdSVbG0i1D7TQboo3SW0TrMuMmS4AX3julky+qGI+o16akBSRUDTErk8eVRqh13wIDwxAvXjrp5FciiqMDu3k33xWGR6ybgciVvoFSgraF+2Xdzs1mwB+JTJZTT/1FppEtSb3p8lbpfLhTKeSs8zQIpFkYNse4NbXS5Fkl+8+9hhsJZUaSmMBf7AFYocuArVsJ6SUl1JB+JKS7A9wFWMHnd+REea+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lfC78eHoWgYYe74UlSw1vBBwAHUxfo+fJj/g8JTvi60=;
 b=hL5KTdglM1APsECmTM8+P5l5VfoSdrXu4Lnz5GSdvGtzL0MiRdrl4qDBLtJdtTpJK9guPEPsVFlsGuIV3aPmQUgyr/zU8gIThnPMjSWWV1lFBGsFzhQuZDyN4dzdBCgWR6Bc5NywePFU8L4A/7TjfSzgrOcYtVobZjt0aiZmvV8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:in-reply-to:message-id:mime-version:references:subject:to; s=
	ppserprodsaar; bh=lfC78eHoWgYYe74UlSw1vBBwAHUxfo+fJj/g8JTvi60=; b=
	Olo4GwK5q/KdGPKuVCtXnD1hqQbUYDlWw+Ip0S94xVJCQN75BNuoGoHYwm6LKERx
	ow7zP0ufHPjGFoatPkbF0GW6SldGa77oRzHnMedsUpprZHBMzib3zZEXDfG+c12o
	MmsO3K9h/SYj7h7X3AKg3pr32MfRuaC1AvHQWPHhmULrS8wSKvdE+ntgicpTEbPH
	TaIZOOghnn+GNijDaNCYVvixJtsohOqN3BtHB9gk7aLVOX0UeKGZreg5s5o8uPm6
	pGG7x/l644MgUACOEvZkjbWzwGQo5kcR3TBK6hBSyq5VN1pI21eH8zjxir2neoIQ
	zP+0aefE1B+j73pmGqe0bw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=ppfserpocford; bh=lfC78eH
	oWgYYe74UlSw1vBBwAHUxfo+fJj/g8JTvi60=; b=XunKjxrJqNpYsUKCUH0+p4W
	PPfYvSdn4Kb9SedFBUu+vWEEX4RKdhB8cujc+pGjnzmLDldjHOROvpoUoAQSBCcX
	jvGzToiy2Xnmzwjn6IMoPidd6Jyn6XEWxq0C9SF4EpfpI8BopkE+yA0BAvyrWOTc
	qbN3sZZGWkdgMmGqoZv5G44seNMlv5IZ/pJjOiENdpA4+Yttjf+kiaFlaXPP/TGA
	1Dvg6Q7D//RsgNuH5t9t/SPlnTRjdrmo/6pqhli63PMCHyYcyOBpe3wfnXMhkzyl
	vLV0u+8D8yje5yYaMbelxS01IUCMUBOMXLtCNm6F17/2F7blrghJr5oF5YTadSw=
	=
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: tw3Ow46T2QLYTtw3PwVLgG
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5 2/2] xen/console: add build-time rate-limiting controls
Date: Tue, 11 Aug 2026 16:38:24 -0700
Message-ID: <20260811233824.1874525-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260811233824.1874525-1-dmukhin@ford.com>
References: <20260811233824.1874525-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 suspectscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 phishscore=0
 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound
 adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608110197
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37D:EE_|BY1PR16MB6506:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: ef86380f-366b-407e-358e-08def801afdf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|82310400026|1800799024|376014|36860700016|6133799003|56012099006|10067099003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	IEuKrutZUqu405Z8h2klxpkfs+rVa3Qc2fl3/X4zPUSvAlsrWmPL1YRoFeidFXwPbIf/iECTKGRGqD4R9OBDnuESR/lykITcve8MkUzMYFBIJfVNuzhJg7CR5aQpujdlffW4+ENRMu40Ud85iLhPmArL2i89H4/Pp5NLxQDPX3ZfNzMopU0vJmcO2Sl5yHvabGGEQM/h7NLY9XGxNBp2hGAzZoi6WgoqAqdPxemqkArnldF0RpsQjp35rsWi73UjVg7AcdFXuODMF4LGfNG5L8qKBOPHAdT+AOIMZaZewlv5dVIU4pKoMDOQ9SIODt/TbKLcqQEdkmC00QRCGh6fXcbOmMD5NlszFLsSyKtbyLt634sxEOFHwzyow4KndeS4FKA5CyhMySYUfwfme5U3bDMyY0kYFD0M+YPyZblwdwkHE1Ykkp4bZLh4gVondAS41ZS8Jumm53pirpOBU6ZX0dQeBfM9adaNLt+txfPLo1j8sybodDNoMbf3vbzpZM+qufVQu9ymQL8GhKmhqNIFY70hUxiNCJxdMpSYOD8XGEsafY7+i4x5u715oM7fPBHVyITF+6TiGHVeQRP3sU3sA57uNbFVn7uIT3Dza9SYKG39W0WS1P5CT7JtB00B/EY8QLr16UUbCSPm0qlDjlHBNJnfeXtz2rRzvyCK6tcrEp9chPYryzGp6XslxkR4wdwBqXi9G3eQ066eaB4pZlEq2Q==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(1800799024)(376014)(36860700016)(6133799003)(56012099006)(10067099003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	yuZgVisinybyWRWMXr4HRKa6YQMSAeLiIBoQxQl5RrKTwWHzOGn2d66btwxF94lhRpBRcXAFUjSBEm6Yd5orOJvJxrKAAz+Hz/rHe3gWSQdqushyXn0CF7k/oCsK0cJvDrrsFTj9YjLS7BuuQkOUJapU7lMLtBBbvPLlhmadr9SDveVMcDIgNKLTYeeZcDtJn+xfKq1zikm0DdfVn1QeFPEIh7ooCEn5nW2Uec1KFXHEa42OCrZkk13TmeeVN7ySgEFBoeXKgARSvT4ybG5f1k764ZkWeb8Aa1o4vDG8z6Rq7b9SEkYM/WIe+3/K8C7OvV6okyj1/vV0uFPisgextmtvJDhhnBrbowJQRis5Bpkee2zossuum8XgmaDbXnjT7aeXtF8zBM89Y7YFOXu5k+VaEy+FXYyLKyeWKra6MkahUYLZYW9grt/pikg1y0jH
X-Exchange-RoutingPolicyChecked:
	RhqBtht/5rO7FOjVGMIFFZgjuN4Vvox9WMFatZE62JfHL8ePRAH/fMngG6wcW0jyuOH5kkSBU95iK/UN2xn0X4aQkmYsBxWdckbeNJrUXWQ7f0FxUJK93Ut3FlI6ZFY1bgZ/p3tg2Ha5mHwUVXbZrMWhioJ/H9MxleDpFVV8+Rsq0U0r3SrmANCFxoZu391PC3CM1xFwtV1GmRlRhdi5EYa38dG/5qFTX9qxVqhEm18JmbNHt/oSCxVUYmL/pI+vLp4mc92clyOOne7zEW/lPcMhFO7Fj4Or51MDQDy+PIbVopg8HasKqRCQ+nk1zvFK/FoqZdagvK7t5j2ftfP2/Q==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	cKu5K/FdQvo551snGMCCe0YvsCzqwB6aO32c5a8Fpqo+3GdkLSXZB2PjcFxenvhUmY+j4m3RaJtuVHjpjINdErf3K4jJ42HoObpsppI52KOo7J4xBnm6Db1SLkCLkQy0M3B4TCJ25v/kNKEHorpKVWWV+WJ0dzxEGbMSU/CFDw2QyeFyy5llUjELpx49XWVSphba15oBDd0s4kIF0SCsEEye3+PT2fJhqO2BJHwV9YSJ96BgKCf/XXlBkefMxHy1s1A3z/dMx4pIua1gKMSg6cQSjtzbWb6aLOGdQ+XVJmNACkmR0BqybFmFJ0b2U5utZ8Zdw3XU0we14akA6cX4JFza0OvA9+OH5uNFuCes/+gpJ3QeRapAAnfqfupLhxc5n+k80+KmD5t1ZLLiwwJKEiAuvFEKk8rfIJyzG3UE+Q3j5zq5Dqf/HpinH2EavUUQbEuFyrSwGEdY/w8lH9rid8p8IHIGeqQZbLun0evXdJf61MS08eAVS1b9BUhE6k/bIjd6/7p+5XTvD2miqeCZUxeS++NUFQtLCmMDyx38hBmYnUm/GRS8VVTl4fNvk59Z1xsbuq6XRCib0EcxVEnJ9N9QUpS70gXgFLZYsBqAupBE8XoQADZ6UBGK/xniU+i3AeOv+pM+aO3rgffFzcaEWg==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2026 23:38:46.0314
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ef86380f-366b-407e-358e-08def801afdf
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C37D.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR16MB6506
X-Authority-Analysis: v=2.4 cv=HpVG3UTS c=1 sm=1 tr=0 ts=6a7bb28a cx=c_pps
 a=Nwoz+Mp4en+GxkTyGjE1QQ==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=WER9OelvoqQQjwJToBYG:22 a=cbNQJ9GKAAAA:8
 a=NNVgaHFa0Tc0tJPwRXQA:9 a=G69WFyCBNqGPyalROSdv:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODExMDE5NyBTYWx0ZWRfX/jR1HsgqQpaW
 KQtlxZAYc0nD2FZb7ZmJ5h4HlAhnDd3wfBUrM3e+il0wIg+d2S5/5o7yiAbSlk0ApkmG/H/Bkfp
 a7TGoWQRz9dI3YoGambmFKOsRn9l2+z9jbiBOKcntg47DMqMQHEC1UnNdyDfnaLQrPCLb+70xUP
 DCaCFFbWQlWyxgPuGpocmYitZvfpNa2IZ9VdWXqdp62mPmrid90NVDoFdfoqYGxp0eHmvWx91IG
 Nl4WYFrC5Snr9uvxz+5SNjQOEYuvOA6LNBrVDCJnzUZ68lB4x/SiTPvamZTM/P88iWm0EauwQ2S
 3FkJp3EbmcrdhYwzod0L+cqajmxqwkHFQ0b8XUEOux+lnjCAbPEdHVoPptU9nBBR8gpBR2YlkHo
 bIQBUHnAgvBLHfD6Qlur8ub9+/lucFMsxPI8ADjEDWmXUQnPttqVZ2ErofelKFKyNN2TajlYHqp
 G2gkX2ExFnKnzW2W1NA==
X-Proofpoint-GUID: ChUkaRMPOyQIewr9pTotpSbMg0t9Tagw
X-Proofpoint-Spam-Info: AW1haW4tMjYwODExMDE5NyBTYWx0ZWRfX21k/7+pdzKVl
 G4NXOeMbrvYgrV/xXQcI9z8sAaEls5HFha/hjpoY3MUkfeFxQBpoRsMr+LbPE2bffOspogGL9Ej
 tf5LxsFzjdWjUj6P+5Srcu4GcH2hcqvJBUh8qkGJvN8eb5i+n0Wb
X-Proofpoint-ORIG-GUID: ChUkaRMPOyQIewr9pTotpSbMg0t9Tagw
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-11_06,2026-08-10_03,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 phishscore=0 spamscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0
 suspectscore=0 clxscore=1015 priorityscore=1501 impostorscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608110197
X-purgate-ID: tlsNG-33051d/1786491532-6D4D74E9-987C4E51/0/0
X-purgate-type: clean
X-purgate-size: 2521

From: Denis Mukhin <dmukhin@ford.com> 

Introduce CONFIG_PRINTK_RATELIMIT_MS and CONFIG_PRINTK_RATELIMIT_BURST
for configuring rate-limiting policy at the compile time.

Use symbols for global rate-limiting initialization in the console driver.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v4:
- dropped footnotes in Kconfig options
---
 xen/common/Kconfig         | 30 ++++++++++++++++++++++++++++++
 xen/drivers/char/console.c |  6 ++++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index da80fdba8469..2c80fc7c81a7 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -672,4 +672,34 @@ config PM_STATS
 	  Enable collection of performance management statistics to aid in
 	  analyzing and tuning power/performance characteristics of the system
 
+menu "Console rate-limiting"
+	visible if EXPERT
+
+config PRINTK_RATELIMIT_MS
+	int "printk rate-limiting time window (milliseconds)"
+	default 5000
+	help
+	  Specifies the time window, in milliseconds, for rate-limited printk
+	  messages. No more than `CONFIG_PRINTK_RATELIMIT_BURST` messages will be
+	  printed within this window.
+
+	  Setting this value to 0 disables rate-limiting entirely.
+
+	  Configurations using a value other than the default of 5000 are not
+	  security supported.
+
+config PRINTK_RATELIMIT_BURST
+	int "printk rate-limited message burst size"
+	default 10
+	help
+	  Defines the maximum number of rate-limited printk messages that may
+	  be printed within each `CONFIG_PRINTK_RATELIMIT_MS` time window.
+
+	  Setting this value to 0 disables rate-limiting entirely.
+
+	  Configurations using a value other than the default of 10 are not
+	  security supported.
+
+endmenu
+
 endmenu
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 56bf111ef181..cf1c499f597a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1344,10 +1344,12 @@ bool __printk_ratelimit(unsigned int ratelimit_ms,
 }
 
 /* Minimum time in ms between messages */
-static const unsigned int printk_ratelimit_ms = 5 * 1000;
+static const unsigned int printk_ratelimit_ms =
+    CONFIG_PRINTK_RATELIMIT_MS;
 
 /* Number of messages we send before ratelimiting */
-static const unsigned int printk_ratelimit_burst = 10;
+static const unsigned int printk_ratelimit_burst =
+    CONFIG_PRINTK_RATELIMIT_BURST;
 
 bool printk_ratelimit(void)
 {
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 11 23:40:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 23:40:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388699.1629685 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw58-0006Dq-P2; Tue, 11 Aug 2026 23:40:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388699.1629685; Tue, 11 Aug 2026 23:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtw58-0006Dj-MR; Tue, 11 Aug 2026 23:40:30 +0000
Received: by outflank-mailman (input) for mailman id 1388699;
 Tue, 11 Aug 2026 23:40:29 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <36rJ7agYKCZkL73GC59HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@flex--seanjc.bounces.google.com>)
 id 1wtw57-0006DZ-HA
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:40:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtw56-00FmZa-HL
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 01:40:28 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <36rJ7agYKCZkL73GC59HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@flex--seanjc.bounces.google.com>)
 id 6a7bb2e0-8faa-0a2a0a5109dd-0a2a450ae2ec-8
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:40:28 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <36rJ7agYKCZkL73GC59HH9E7.5HFQ7G-67O7EEBLML.Q7GIKHC75M.HK9@flex--seanjc.bounces.google.com>)
 id 6a7bb2eb-f2d2-0a2a450a0019-d155d2c5a9bd-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:40:28 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84a251c2e3eso1729439b3a.1
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 16:40:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786491626; x=1787096426; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=45PzVi6GlKpHz3+ZRxW2EDnuD1UWmkJmuMSYxMTtVTA=;
        b=bOODZudoKzFHy8Or+ccgMCyQHNA5B8BWzCI3FZUxAt8ohsrCXKjRelnQdB+K+JTMa8
         SR601cGfS6kDP0ZqJo1lK0xplvG3Op4TkyEpxlVArPKH8laAn7hilrGA+844uG1X3UyA
         5iUhKUNPGr/rUimQdNDweFwONnbhz2VUdx7YwwxFxzd5CTp8DoNAUvyfxUg3MrH/SroM
         7CgIepEXbEG7EsaegkuS6imyTnqSyelfc7utPB6IJPwbrSSLB6nTWMP6dDLkbCsI+YBL
         01giiJUeayAKXj2PBjKXsniZS259/ll085NlxJ7Ffx1lxEa/xnlRZuu7g5EEqv0I4QcT
         AEsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786491626; x=1787096426;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=45PzVi6GlKpHz3+ZRxW2EDnuD1UWmkJmuMSYxMTtVTA=;
        b=YOWJXX80gTHLmKPtv+chDhZ1MovLFBIFC6hA/rEIxgE6XY5yjQK8EO8r1rG9clcS1a
         Cu0ujmhjPJaagc7xoxt0qu96pdJsemHRppaBdL1027fD1dnPSJWnluhDcP1PwaHriIyl
         Tx10sQNoqOau453WMkA5BEJqr/q6/ASEKaSwNystl2hmpxiJk5up1hIQQ+tbqI1lZE7G
         sAExVtpXjK3zjDDClc3jtrHnzIj/ibJd5526t9cDYvhmoIFGR8MILD0WqC+lnWBWudcN
         zo7ROn2MiJfzZYxdLgWKSXZuY+ytzdXCKO5XsaplGsERGVqCoxOHPA17EZsGCQHFOrxH
         X/uQ==
X-Forwarded-Encrypted: i=1; AHgh+RpZ0d+qKOR8j3JwrU+u7pZo33J4P2qNTTUORcmGCMcKT0fatgHnjq8Mhl9XqJvhgATMcTLWSoAtQNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJS3VqGI6dLdPVOEEwVeq9JO3bIZc5ZrexXUkoPPloPsMSM2cx
	3uDXez8KDtBM6HeHwyb5DfpeI8qJw0kTK8RNzKJ1rWo2eXQAG9xllEV37QSfRlbGYs4vuAc/O0a
	k4kArLQ==
X-Received: from pghr4.prod.google.com ([2002:a63:e504:0:b0:cbe:3df6:a1aa])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:3d1c:b0:3c4:1916:9d44
 with SMTP id adf61e73a8af0-3cc3f913cbfmr444625637.16.1786491626070; Tue, 11
 Aug 2026 16:40:26 -0700 (PDT)
Date: Tue, 11 Aug 2026 16:40:25 -0700
In-Reply-To: <20260728144954.355376-32-dwmw2@infradead.org>
Mime-Version: 1.0
References: <20260728144954.355376-1-dwmw2@infradead.org> <20260728144954.355376-32-dwmw2@infradead.org>
Message-ID: <anuy6QxUVLcSSVCn@google.com>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-4011c0/1786491628-5A3DCCFC-FE3E35B0/0/0
X-purgate-type: clean
X-purgate-size: 2208

On Tue, Jul 28, 2026, David Woodhouse wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 5c78dd1e4c69..0680332d7d45 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3435,6 +3435,169 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
>  	}
>  }
>  
> +#ifdef CONFIG_X86_64
> +static int kvm_vcpu_ioctl_get_clock_guest(struct kvm_vcpu *v, void __user *argp)
> +{
> +	struct pvclock_vcpu_time_info hv_clock = {};
> +	struct kvm_vcpu_arch *vcpu = &v->arch;
> +	struct kvm_arch *ka = &v->kvm->arch;
> +	unsigned int seq;
> +
> +	/*
> +	 * If KVM_REQ_CLOCK_UPDATE is already pending, or if the pvclock
> +	 * has never been generated at all, call kvm_guest_time_update().
> +	 */
> +	if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, v) || !vcpu->hw_tsc_hz) {
> +		int idx = srcu_read_lock(&v->kvm->srcu);
> +		int ret = kvm_guest_time_update(v);

Invoking kvm_guest_time_update() here is probably a deal-breaker.  Updating the
master clock and other internal state is far from ideal, but should be ok.

However, writing guest memory is not.  Specifically, dirtying memory after the
last KVM_RUN is a non-starter for many usecases, as is modifying state that is
visible via other GET uAPI (though I don't think that applies here?).  E.g. see
commits:

  118964562969 ("KVM: Mark a vCPU as preempted/ready iff it's scheduled out while running")
  e800decd9c0a ("KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN")

One idea would be to simply punt to userspace, i.e. return -EBUSY without trying
to update guest time.  Which is pretty darn ugly, but might be tolerable?  And a
slightly crazy idea to lessen the pain would be to process select requests in
KVM_RUN before bailing for vcpu->run->immediate_exit==true.

That doesn't completely solve things as it's still possible for KVM_REQ_CLOCK_UPDATE
to be set after KVM_RUN, but I think they're mutually exlusive with the majority
of relevant use cases?  And we'd probably want to build on my idea to report that
KVM_RUN needs completion[*], but that'd be a good thing overall.

https://lore.kernel.org/all/20250111012450.1262638-1-seanjc@google.com 


From xen-devel-bounces@lists.xenproject.org Tue Aug 11 23:48:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Aug 2026 23:48:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388707.1629696 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtwCM-00075e-Gp; Tue, 11 Aug 2026 23:47:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388707.1629696; Tue, 11 Aug 2026 23:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtwCM-00075X-D6; Tue, 11 Aug 2026 23:47:58 +0000
Received: by outflank-mailman (input) for mailman id 1388707;
 Tue, 11 Aug 2026 23:47:57 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wtwCK-00073i-6w
 for xen-devel@lists.xenproject.org; Tue, 11 Aug 2026 23:47:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtwCJ-001bL3-Jh; Wed, 12 Aug 2026 01:47:55 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7bb4a1-8faa-0a2a0a5109dd-0a2a4503ad0e-6
 for <multiple-recipients>; Wed, 12 Aug 2026 01:47:54 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+b6a5eba76e218a018a6a+8388+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7bb4aa-fae8-0a2a45030019-5a9b3222b786-3
 for <multiple-recipients>; Wed, 12 Aug 2026 01:47:54 +0200
Received: from [2001:8b0:10b:5:e09:5b1f:c111:693d]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wtwC6-000000019pW-2dt4; Tue, 11 Aug 2026 23:47:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=K9O+zc+iuJrnK7GwdfBAM0RuWn2xcnekJCkifX3QOpQ=; b=XHf7dDf0/CRvkm66ogTBZ8as18
	Cc3enQfly/UEz6C91IZBgXDayswWCRoa1OeHOxKdJZ/feBWe3fMgOe30F5aC40AQneFvWWu0fPXXi
	vik2ha/q+sXY41s6yuEgid6QlDjUeTdAz1mxA5VmBQbcfJRhVIG0AYSo02C7FSh4yknmVdZ+YHqi2
	dJCG2tQCpMx032w9m6Nf7YsJMqxxkZx5uj6HOV6jB3N7WgWT4tlM9sEvU7nggEGRnVvmo1rLZ6b9G
	rfjMADSN+w7/rovSAAcOiRF9dPfHHVA7I8hM+LuxUXtkah9fcmKIkQNgMJPBiSEmTtFstB9Cn6zC5
	vUNbgbVA==;
Message-ID: <b93ca22c776855c36c1d1afec7222233eeea0050.camel@infradead.org>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Wed, 12 Aug 2026 00:47:37 +0100
In-Reply-To: <anuy6QxUVLcSSVCn@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-32-dwmw2@infradead.org>
	 <anuy6QxUVLcSSVCn@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-cOU4kZbVOpr6kbcf3uch"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-33051d/1786492074-774F44E9-85205DD5/0/0
X-purgate-type: clean
X-purgate-size: 10118


--=-cOU4kZbVOpr6kbcf3uch
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 16:40 -0700, Sean Christopherson wrote:
> > +
> > +	/*
> > +	 * If KVM_REQ_CLOCK_UPDATE is already pending, or if the pvclock
> > +	 * has never been generated at all, call kvm_guest_time_update().
> > +	 */
> > +	if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, v) || !vcpu->hw_tsc_hz) {
> > +		int idx =3D srcu_read_lock(&v->kvm->srcu);
> > +		int ret =3D kvm_guest_time_update(v);
>=20
> Invoking kvm_guest_time_update() here is probably a deal-breaker.=C2=A0 U=
pdating the
> master clock and other internal state is far from ideal, but should be ok=
.
>=20
> However, writing guest memory is not.=C2=A0 Specifically, dirtying memory=
 after the
> last KVM_RUN is a non-starter for many usecases, as is modifying state th=
at is
> visible via other GET uAPI (though I don't think that applies here?).=C2=
=A0 E.g. see
> commits:

I don't think we need it written to guest memory; we only need to
generate the in-kernel shadow which is then written to the guest.

I wonder if we can have a boolean 'write_guest' argument to
kvm_guest_time_update() .. but ick.

Or maybe it's OK to just return -EBUSY. Isn't KVM_REQ_CLOCK_UPDATE a
pathological case anyway these day? I'm trying to ignore
kvm_set_guest_paused()...=20

I'll take another look in the morning at the whole thing.

--=-cOU4kZbVOpr6kbcf3uch
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTEyMzQ3MzdaMC8GCSqGSIb3DQEJBDEiBCDNoC5vHmqlr8maBoWOEpK+4ta/agFR
cqNlobKqHax+jjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAYOqI3Y5YvAfqblq3XkUrzzRcTve49+U7HVXTSSNK321mw8eLLi48
a+gzYVEJh6ALXpK2a8f3K5fpsL0d3f6WpXGp0yYMvQ/7v/cfOWdJBeIqX8Yts1Ia8sCoHPoqH706
sHnZKCBghLYY3BlGb6nEyB8L5MtLlQ/pHDb26dwgKNapzc153cmeq1g/fxpfCaDtE7e27pqg+itg
IBtOKQp09tcO/13VyFiMhyXuYrIH7EasG0sQ+f2gaBQpy/JX4QJ18eL83OqbL/Xy3CFbuODB12FO
2hP4YbshtwLuA1uRfMYOU0j8KAjbdwyfx9NevwDV8fR0ll+4farG4xCBfPAmJDNc6R5yDRRt63Gn
IEGS9B4ZafmyjBJlHBx+sahrOKopZ2hhBYsYm2NVM7UjkHu3uGIfbgkbJczyLPj95zb7YhUvbEqm
0PVzFeI340tU/rk6EcH31Xu7t+liC3iMIq/w7/5zegGDAhUm1cASOwSLIfmyEvcAZjN/M6B96dRm
JrKl59O8F0prGwratgXIksPK5ianj9GXRhRMraOfEZi6aPL+BeTiuu8vWxJjrtbklCuf4pcZNlPP
S0qhJODZIM/Ugo0IeGId8CUw0Vd5xw7DWNbh+4JzsoebNTlmR7uoRjJWw4szZfqec5m+5p+8qoK6
5/O2AZlo43jG9o1HEzn8MxcAAAAAAAA=


--=-cOU4kZbVOpr6kbcf3uch--


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 01:34:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 01:34:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388720.1629704 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtxqq-00056r-K5; Wed, 12 Aug 2026 01:33:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388720.1629704; Wed, 12 Aug 2026 01:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtxqq-00056j-FR; Wed, 12 Aug 2026 01:33:52 +0000
Received: by outflank-mailman (input) for mailman id 1388720;
 Wed, 12 Aug 2026 01:33:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <takakura@valinux.co.jp>) id 1wtxqn-00056d-4J
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 01:33:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtxqm-001YjX-7I
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 03:33:48 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <takakura@valinux.co.jp>)
 id 6a7bcd6f-bab6-0a2a0a5309dd-0a2a450cdab0-6
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 03:33:47 +0200
Received: from [40.107.74.117]
 (helo=OS0P286CU010.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <takakura@valinux.co.jp>)
 id 6a7bcd74-f479-0a2a450c0019-286b4a757da2-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 03:33:42 +0200
Received: from TYYP286MB2946.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:30e::6)
 by OSOP286MB4035.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:2f4::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.13; Wed, 12 Aug
 2026 01:33:36 +0000
Received: from TYYP286MB2946.JPNP286.PROD.OUTLOOK.COM
 ([fe80::a377:45d3:a376:f515]) by TYYP286MB2946.JPNP286.PROD.OUTLOOK.COM
 ([fe80::a377:45d3:a376:f515%3]) with mapi id 15.21.0315.011; Wed, 12 Aug 2026
 01:33:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cDKr78VFXaRwfG6RomMg1nyOEEccmgIFyi6ykrgyK+LkGldrDLjPbQUGvij227RNyuul6AVQUpZ+SldvAli7pCQSgUZHU+MqYMsPx6NbzXRB/AzOWeinAmCZ1jDOSETpanB292zaogqkwIF4QusKmbF90qh5tg80CegwJpCcPI/8m4VFtNaO4V0bKVUEYSzm0zJqOPQtly8WNLa97I3xEndzvDCl9RdFf/bElWyzXVJya49Vr8VTpCM0bIEqoufl4BKAlh1WhDCHYWaorLTvBkO51kRdssTJLjsqkGv7cAX2xX1CJMd5rNCoBkeU0PLIBqnb0YQg75BERxUdGvJrHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=V0GQdb4thSn5vBUqAbO/XA2F59p6uNe+goaa1gaQnNA=;
 b=Du8QA5uN39fiOJgzTR6natTRSlmxV4iIFoE+xXkIB5IES6PLMwC7a9iEzFljzxgYk1W+qKQOsZoAgpFFCOQKZErjtDCGt8BYp1dEv8gM1qBE4GyqcsSnjuTfH2jlwkM11dIbcDbyaPPoihYwCSH7vFYbIpxToiWRhe6l2E5FIKFcTKEFu/JelNFIQLQobCnJz3nVPWFsJvWHDmjItkHYjw43vKPqkR0OQieL9dsL+c/uz24/JZcqegWyD8LQnzaf3lrH+FqvZqM4YKosF1X+yUy9BaeSpmSn+Lc6yuO5vccsicZo1juuuIizbVFcqG2Q68wMDQtRZ3ksy3JZR12eoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=V0GQdb4thSn5vBUqAbO/XA2F59p6uNe+goaa1gaQnNA=;
 b=hEJVsdjB6ebwovPSbtoVvJzzo5iTX3aYSEjOEvYa7cxnxN5+bEia480f4Kt2z+0EGKT63eyApCUVxC9cJrsDhS/ZO9zEXlYEDTtiyAotFkNiGodsp/KFJOFozvS8qpABuW2srl5/mAk/KJmON0ab9BJ4KozwNePwEAdNePsAdPs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Ryo Takakura <takakura@valinux.co.jp>
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	roger@xenproject.org,
	ross.lagerwall@citrix.com,
	andrew.cooper3@citrix.com,
	taka@valinux.co.jp,
	den@valinux.co.jp,
	okamoto@valinux.co.jp,
	Ryo Takakura <takakura@valinux.co.jp>
Subject: [RFCv2] xen/arm64: livepatch: enable attaching callbacks
Date: Wed, 12 Aug 2026 10:33:18 +0900
Message-Id: <20260812013318.21860-1-takakura@valinux.co.jp>
X-Mailer: git-send-email 2.34.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4PR01CA0010.jpnprd01.prod.outlook.com
 (2603:1096:405:26e::18) To TYYP286MB2946.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:400:30e::6)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: TYYP286MB2946:EE_|OSOP286MB4035:EE_
X-MS-Office365-Filtering-Correlation-Id: ded35872-9952-4967-0434-08def811bacc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|3023799007|56012099006|6133799003|5023799004|10067099003;
X-Microsoft-Antispam-Message-Info:
	8n7L+jV0+PkOP71f3MDKgF82l1dxmk2oVLqysFDvrruk2Z27kaXjIujpI5O2eaU+qgnDF0x07VWF39wl7AGzzhkBZrBpaWJgVhVrK3Xw7roVfRksSeNwTkeToAHNtrBFi399THc9lDScNvtzSOD04cNo6AJ6sQMUzwbhGfB3ZfQ6IgqoSkJ+AUmM44Bogy/2a9jbZUAP2kXDvHgIu7ecLSQv5pMk88juQzWixUYw/xI+RQKPAoJ4QI4HxcXxoS8SaoUUteF/XDO5uOskVyzQPF1GjObx0ZHh1cuI/qtM04SimoXJXWi4j0HTZwtNATZFbjQbuQJhkjo6hHpr3EAmRMpYSj2NMdzU3H27qXj1SyJFBOL83sn8GMDDuhnEIrCWBbgNg8KrYQrUwhSQEhNr/TVHMDSfnmq5sUAbSQVtrwW+AQPlCxUD+uhGzg+8BtVVtUdv+3G5x3ZReVH53cLLOE/cQOVG6L7D4b8t+sr/N3vxJKtcY3MWXiRUd8i/Z9HS6B1ynqSqwnLIorXViImFV4jouBH/wpF5p+7MYdueJ1xcILHRbQtrKmSKfGS+Oqu+OStEPuD1vtR/yIWdxDRh197bQ2Ee/ae6RkoMh9JqhR1cYjheL8Ts0uG8bvG/4e/F
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYYP286MB2946.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(3023799007)(56012099006)(6133799003)(5023799004)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?xzlt6gxBhejqqw15Y2Wsc5rHnGmnXiPEDjeB7lTYT2d1meDtgukAGe72CIru?=
 =?us-ascii?Q?Kq2ch6B4CzUrU51PTberqZjrchiFv4SdNOqGSA1XEJQU4ZLJbC0eRdnk7ivi?=
 =?us-ascii?Q?cK5Ru0axfI2fAwR5GwXZErgdDuTWfhiPu5u44Wa9S9JJ6QWewUYPlhoEYghr?=
 =?us-ascii?Q?D8iutTEVXCT02XR3mfGttFIFlC75dxOx8+E9b+eckJZo/XNjBM1YaAVXFOhQ?=
 =?us-ascii?Q?7huMOxhjuIHSDoRSEfUCy532sD6y89wbRjUvi7zCTDDCM/gwwyBelM8nvPBt?=
 =?us-ascii?Q?Es0MFYvB9TltO7rwzF47Qh2D76+1In6HjQy54eP7fZjJ3kT8mFOc5lu4osDl?=
 =?us-ascii?Q?/xw3GkUSQmw4SU/XjfUlddDC+yElLLlrxL0H2eHvvlmj+KaNtyfG9bzVulID?=
 =?us-ascii?Q?fMIvrcW1AZsQPh7GZiCl560ZStsliDnfMRXbwKMjHkqqejNjt5zkQJt7rhl/?=
 =?us-ascii?Q?tbZzvSDAATofZtKzu9BR7rL9LbKIHfoa+M7rU9U3b1D8E9ua+bC5Bm+HvAXM?=
 =?us-ascii?Q?8mRHF1JnMbOTB5KLdoHMatRFgcgNxX4WxWViDJlJXbrtQd1QaPDieznUZHVH?=
 =?us-ascii?Q?0SAOW9N3p2FNTVibAalGMXv2WUioiYz/l7JxFX8gM6mz1w7y3t3Ki22sdJiF?=
 =?us-ascii?Q?FGXA7sy/1OOd1ytA1Nn7OFcPt925gtfS+9I8qVDb8kWT4/d1Ydb3HVRkMsZv?=
 =?us-ascii?Q?I7RMtqJgZTxYw9mmQrsL0LMKwipbf6nyckosipbo538cSaLKhGIgunnffl1P?=
 =?us-ascii?Q?0FnqNMPs20reWAoy7WSnPkq20k/aAgmRlMcisYliqKky4kqaqkLNMwGnlz4U?=
 =?us-ascii?Q?8Mvw1nF4CxLycBw8MIhrQvRTbnYJc9yMRyXFgj7FnB34DQiB/Yb0+BBmEn9D?=
 =?us-ascii?Q?IlhVjcUnMX6ovk11nj43seJFlf9DAMUY3+oxD3/Wr2+/xmH43mLBd4EFi11u?=
 =?us-ascii?Q?v7f7nEBGEbV5obkCqeYCkBWPmLP7PLxANX/8wIke3pmTkqUBuc8UPLgVK4vW?=
 =?us-ascii?Q?LiJ9atwTP5dgeEyVO2+oP6N4qcWFXxhfqx0ClNXm0cdank/PLBTNgafP2NzG?=
 =?us-ascii?Q?hu7ADIfK6FpIpscghvgZal5p+la2FcYkgTsJ3ThMQZ0yOVovPYCK+mMBd10E?=
 =?us-ascii?Q?3bLGcyKL0+TQlNXx3DD7w/FTdH2uGovwlbEzHYfY50uJEDNQMe72xhHxzppl?=
 =?us-ascii?Q?MDXON2naGpcE4zuvdZvN6p4qbUAjBKpND6zl5bVr09bW19Fw435K6fl2fAcs?=
 =?us-ascii?Q?C8nZbKJMwylpeY31l4gI1t2fJqLeMjfJmCm2S3FsiIsC7aPfvd49ckclLprn?=
 =?us-ascii?Q?p7LK4OwzAxZL6HNZZicwC+zTlXLrXWL01QmVbSowa3wihxiH/+OPS3egcoyO?=
 =?us-ascii?Q?GZDR2q80QOgbz5me70t9TuO8wshIdXHRJPeSF8FpmIMnvL4DjPFXyDLFweOv?=
 =?us-ascii?Q?XZOjVdmZ8eXapzyP3ov2rilMF/ClHgZ+Dk33QGgLcAg5i8CIQO1hEilqrg2o?=
 =?us-ascii?Q?XCdK2NBNC1f/bHcfuC3dJHqU7CVZG+1baAtO3DIPUB/AsCEnYlkW3XwEt1Z+?=
 =?us-ascii?Q?+RBd2esRwvdqr5xaNhP9/+ilRc3rYqQpTX3oTKMmGvPls6OtUfauu73o256C?=
 =?us-ascii?Q?FKYxQwbnmtXODCfzdE+QcDQVwwTqLPUvBSy78UyB3WRFbCeVpjFbWTbNjd8W?=
 =?us-ascii?Q?/vdyJUsm7nAWGwIeUQhH8ewSSQG2yO+p2grSDXK4UsEp31WORLeRfIjYM5ex?=
 =?us-ascii?Q?LIH2NQVf5g=3D=3D?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: ded35872-9952-4967-0434-08def811bacc
X-MS-Exchange-CrossTenant-AuthSource: TYYP286MB2946.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Aug 2026 01:33:36.6480
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tcn7MphEFEkQh7iBvkLUShab2abtZelSAYuHDeXjo8v1xUd6KZjiWM9zmppoEVesmnvFu7sNxh31n637jpMJrA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSOP286MB4035
X-purgate-ID: tlsNG-d25034/1786498427-770D9A5B-9AB78FA3/0/0
X-purgate-type: clean
X-purgate-size: 17483

Linux ftrace allows registering callbacks which is useful
for debugging and tracing events. On Linux, it is done by
reserving NOPs at function entry points at compile time
which can later be patched to branch to a trampoline.

This patch introduces similar callback feature adopting
linux-like approach of reserving 2 NOPs at function entry
points. When user requests the feature, the NOPs will be
livepatched as:

     mov     x9, lr
     bl      xen_livepatch_trace_caller

where xen_livepatch_trace_caller serves as a trampoline
for saving original lr of the traced function and other
relevant registers before calling the registered tracing
functions.

The tracing functions are called with arguments of:
ip: ip of the traced function
parent_ip: ip where the traced function was called

One can request the feature by specifying the section
for struct livepatch_func as .livepatch.traces.

Signed-off-by: Ryo Takakura <takakura@valinux.co.jp>
---

Hi,

This is a continuation of the previously sent RFC[1].
Thank you Andrew and Roger for the feedback!!

Here are the major updates:
1. Reserve function preamble like Linux using -fpatchable-function-entry=2.
2. No per-callback trampoline generation.
3. Let common code decide whether a patch is a replacement or a preface addition,
   and let arch code provide a handler for each case.

For 2., Andrew suggested avoiding manual generation of trampolines
using the attribute "no_caller_saved_registers". I considered the option
but figured out we still need to save lr before jumping to tracer
function and it requires a trampoline (as far as I understand).
Moreover, the function attribute seems to be only supported on x86...
So I decided to make a common trampoline like linux[2].

Example payload file:

#include <xen/lib.h>
#include <xen/livepatch.h>

static void my_tracer(unsigned long ip, unsigned long parent_ip)
{
    printk("livepatch: do_domctl was called "
           "(ip=%lx, parent_ip=%lx)\n",
           ip, parent_ip);
}

static struct livepatch_func traces[]
    __attribute__((section(".livepatch.traces"))) =
{
    {
        .name = "do_domctl",
        .old_size = 4580,
        .new_addr = my_tracer,
        .version = LIVEPATCH_PAYLOAD_VERSION,
    },
};

I would appreciate any advice or suggestion, Thanks!

Sincerely,
Ryo Takakura

[1] https://lists.xen.org/archives/html/xen-devel/2026-06/msg01442.html
[2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/entry-ftrace.S#n36

---
 xen/arch/arm/Kconfig                  | 12 ++++
 xen/arch/arm/arch.mk                  |  2 +
 xen/arch/arm/arm64/Makefile           |  1 +
 xen/arch/arm/arm64/insn.c             |  5 ++
 xen/arch/arm/arm64/livepatch-asm.S    | 81 +++++++++++++++++++++++++++
 xen/arch/arm/arm64/livepatch.c        | 30 ++++++++++
 xen/arch/arm/include/asm/arm64/insn.h |  1 +
 xen/common/livepatch.c                | 58 +++++++++++++++++--
 xen/include/xen/livepatch.h           |  8 +++
 xen/include/xen/livepatch_payload.h   |  7 ++-
 10 files changed, 198 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/arm/arm64/livepatch-asm.S

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 843a43897e..8d94232248 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -276,6 +276,18 @@ config PCI_PASSTHROUGH
 	help
 	  This option enables PCI device passthrough
 
+config ARM64_PATCHABLE_FUNCTION_ENTRY
+    bool "Reserve two NOPs at function entry for tracing"
+    depends on ARM_64 && LIVEPATCH && $(cc-option,-fpatchable-function-entry=2)
+    default n
+    help
+      This option compiles Xen with -fpatchable-function-entry=2, which
+      reserves two NOP instructions at the beginning of functions. The NOPs
+      will be livepatched with a branch instruction to tracing function
+      registered by user.
+
+      Enable this to use livepatch tracing feature.
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
index dea8dbd18a..e3cad65bef 100644
--- a/xen/arch/arm/arch.mk
+++ b/xen/arch/arm/arch.mk
@@ -19,6 +19,8 @@ endif
 CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
 $(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics)
 
+CFLAGS-$(CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY) += -fpatchable-function-entry=2
+
 ifneq ($(filter command line environment,$(origin CONFIG_EARLY_PRINTK)),)
     $(error You must use 'make menuconfig' to enable/disable early printk now)
 endif
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 6491c5350b..7f52b10e66 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -12,6 +12,7 @@ obj-y += entry.o
 obj-y += head.o
 obj-y += insn.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
+obj-$(CONFIG_ARM64_PATCHABLE_FUNCTION_ENTRY) += livepatch-asm.o
 obj-y += smc.o
 obj-y += smpboot.o
 obj-$(CONFIG_ARM64_SVE) += sve.o sve-asm.o
diff --git a/xen/arch/arm/arm64/insn.c b/xen/arch/arm/arm64/insn.c
index 6b97a84ba7..dc3ddc6351 100644
--- a/xen/arch/arm/arm64/insn.c
+++ b/xen/arch/arm/arm64/insn.c
@@ -218,6 +218,11 @@ u32 __kprobes aarch64_insn_gen_nop(void)
 	return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP);
 }
 
+u32 aarch64_insn_gen_move_reg(uint32_t rd, uint32_t rm)
+{
+    return 0xaa0003e0 | (rm << 16) | rd;
+}
+
 /*
  * Decode the imm field of a branch, and return the byte offset as a
  * signed value (so it can be used when computing a new branch
diff --git a/xen/arch/arm/arm64/livepatch-asm.S b/xen/arch/arm/arm64/livepatch-asm.S
new file mode 100644
index 0000000000..92858bcaa9
--- /dev/null
+++ b/xen/arch/arm/arm64/livepatch-asm.S
@@ -0,0 +1,81 @@
+/*
+ * xen/arch/arm/arm64/livepatch-asm.S
+ *
+ * Trampoline for livepatch tracer.
+ *
+ * Ryo Takakura <takakura@valinux.co.jp>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+/*
+ * If livepatch tracer is enabled, function entries are placed
+ * with two NOPs. Once user requests a functions to be traced,
+ * arch_livepatch_apply_trace() will livepatch those NOPs to:
+ *
+ *     mov     x9, x30
+ *     bl      xen_livepatch_trace_caller
+ *
+ * x9  = traced function's original LR
+ * x30 = traced function + 8
+ */
+FUNC(xen_livepatch_trace_caller)
+        /*
+         * Registers to save/restore:
+         *
+         *   x0-x8          Function arguments
+         *   x9             Original LR
+         *   x29            Original FP
+         *   x30            PC to return
+         */
+        sub     sp, sp, #96
+
+        /* Save function arguments */
+        stp     x0, x1,   [sp, #0]
+        stp     x2, x3,   [sp, #16]
+        stp     x4, x5,   [sp, #32]
+        stp     x6, x7,   [sp, #48]
+        str     x8,       [sp, #64]
+
+        /* Save LR, FP, PC */
+        str     x9,       [sp, #72]
+        str     x29,      [sp, #80]
+        str     x30,      [sp, #88]
+
+        /*
+         * xen_livepatch_trace_dispatcher(ip, parent_ip)
+         *
+         * ip: Instruction pointer of the function being traced.
+         * parent_ip: Instruction pointer of the function which
+         *            called the function being traced.
+         */
+        sub     x0, x30, #8
+        mov     x1, x9
+        bl      xen_livepatch_trace_dispatcher
+
+        /* Restore function arguments */
+        ldp     x0, x1, [sp, #0]
+        ldp     x2, x3, [sp, #16]
+        ldp     x4, x5, [sp, #32]
+        ldp     x6, x7, [sp, #48]
+        ldr     x8,     [sp, #64]
+
+        /* Restore FP, LR, PC */
+        ldr     x29,    [sp, #80]
+        ldr     x30,    [sp, #72]
+        ldr     x9,     [sp, #88]
+
+        /* Restore SP */
+        add     sp, sp, #96
+
+        /* ret x9 */
+        .inst   0xd65f0120
+        sb
+END(xen_livepatch_trace_caller)
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 39159ba8b5..bb6d8affa2 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -14,6 +14,8 @@
 #include <asm/bitops.h>
 #include <asm/insn.h>
 
+extern void xen_livepatch_trace_caller(void);
+
 void arch_livepatch_apply(const struct livepatch_func *func,
                           struct livepatch_fstate *state)
 {
@@ -492,6 +494,34 @@ int arch_livepatch_perform_rela(struct livepatch_elf *elf,
     return -EINVAL;
 }
 
+void arch_livepatch_apply_trace(const struct livepatch_func *trace)
+{
+    uint32_t *new_ptr;
+    uint32_t insns[2];
+
+    new_ptr = trace->old_addr - (void *)_start + vmap_of_xen_text;
+
+    insns[0] = aarch64_insn_gen_move_reg(9, 30); /* mov x9, lr */
+    insns[1] = aarch64_insn_gen_branch_imm((unsigned long)trace->old_addr + ARCH_PATCH_INSN_SIZE,
+                                           (unsigned long)xen_livepatch_trace_caller,
+                                           AARCH64_INSN_BRANCH_LINK);
+
+    memcpy(new_ptr, insns, sizeof(insns));
+    clean_and_invalidate_dcache_va_range(new_ptr, sizeof(insns));
+}
+
+void arch_livepatch_revert_trace(const struct livepatch_func *trace)
+{
+    void *new_ptr = trace->old_addr - (void *)_start + vmap_of_xen_text;
+    uint32_t insns[2] = {
+        aarch64_insn_gen_nop(),
+        aarch64_insn_gen_nop(),
+    };
+
+    memcpy(new_ptr, insns, sizeof(insns));
+    clean_and_invalidate_dcache_va_range(new_ptr, sizeof(insns));
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/include/asm/arm64/insn.h b/xen/arch/arm/include/asm/arm64/insn.h
index ab290030ab..a83d8de0e4 100644
--- a/xen/arch/arm/include/asm/arm64/insn.h
+++ b/xen/arch/arm/include/asm/arm64/insn.h
@@ -82,6 +82,7 @@ u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
 				enum aarch64_insn_branch_type type);
 u32 aarch64_insn_gen_hint(enum aarch64_insn_hint_op op);
 u32 aarch64_insn_gen_nop(void);
+u32 aarch64_insn_gen_move_reg(uint32_t rd, uint32_t rm);
 
 /* Wrapper for common code */
 static inline bool insn_is_branch_imm(u32 insn)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 7515a040ad..6f3c3274ab 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -198,6 +198,37 @@ static const char *cf_check livepatch_symbols_lookup(
     return n;
 }
 
+void xen_livepatch_trace_dispatcher(unsigned long ip, unsigned long parent_ip)
+{
+    const struct payload *data;
+    unsigned int i;
+    const struct livepatch_func *f;
+
+    rcu_read_lock(&rcu_payload_lock);
+
+    list_for_each_entry_rcu ( data, &payload_list, list )
+    {
+        if ( data->state != LIVEPATCH_STATE_APPLIED || !data->is_trace )
+            continue;
+
+        for ( i = 0; i < data->nfuncs; ++i )
+        {
+            f = &data->funcs[i];
+
+            if ( (unsigned long)f->old_addr != ip )
+                continue;
+
+            ASSERT(f->new_addr);
+            ((livepatch_trace_func_t)f->new_addr)(ip, parent_ip);
+
+            goto out;
+        }
+    }
+
+out:
+    rcu_read_unlock(&rcu_payload_lock);
+}
+
 /* Lookup function's old address if not already resolved. */
 static int resolve_old_address(struct livepatch_func *f,
                                const struct livepatch_elf *elf)
@@ -551,6 +582,7 @@ static int check_patching_sections(const struct livepatch_elf *elf)
 {
     unsigned int i;
     static const char *const names[] = { ELF_LIVEPATCH_FUNC,
+                                         ELF_LIVEPATCH_TRACES,
                                          ELF_LIVEPATCH_LOAD_HOOKS,
                                          ELF_LIVEPATCH_UNLOAD_HOOKS,
                                          ELF_LIVEPATCH_PREAPPLY_HOOK,
@@ -688,7 +720,7 @@ static inline int livepatch_check_expectations(const struct payload *payload)
 static int prepare_payload(struct payload *payload,
                            struct livepatch_elf *elf)
 {
-    const struct livepatch_elf_sec *sec;
+    const struct livepatch_elf_sec *func_sec, *trace_sec, *sec;
     const struct payload *data;
     unsigned int i;
     struct livepatch_func *funcs;
@@ -696,7 +728,12 @@ static int prepare_payload(struct payload *payload,
     struct virtual_region *region;
     int rc;
 
-    sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC);
+    func_sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC);
+    trace_sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_TRACES);
+
+    sec = trace_sec ? trace_sec : func_sec;
+    payload->is_trace = !!trace_sec;
+
     if ( sec )
     {
         if ( !section_ok(elf, sec, sizeof(*payload->funcs)) )
@@ -721,6 +758,13 @@ static int prepare_payload(struct payload *payload,
                 return -EOPNOTSUPP;
             }
 
+            if ( payload->is_trace && !f->new_addr )
+            {
+                printk(XENLOG_ERR LIVEPATCH "%s: Trace new_addr is NULL\n",
+                       elf->name);
+                return -EINVAL;
+            }
+
             /* 'old_addr', 'new_addr', 'new_size' can all be zero. */
             if ( !f->old_size )
             {
@@ -1460,7 +1504,10 @@ static int apply_payload(struct payload *data)
             continue;
         }
 
-        arch_livepatch_apply(func, state);
+        if ( data->is_trace )
+            arch_livepatch_apply_trace(func);
+        else
+            arch_livepatch_apply(func, state);
         state->applied = LIVEPATCH_FUNC_APPLIED;
     }
 
@@ -1509,7 +1556,10 @@ int revert_payload(struct payload *data)
             continue;
         }
 
-        arch_livepatch_revert(func, state);
+        if ( data->is_trace )
+            arch_livepatch_revert_trace(func);
+        else
+            arch_livepatch_revert(func, state);
         state->applied = LIVEPATCH_FUNC_NOT_APPLIED;
     }
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 5dc8c61d37..a893f134e0 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -26,6 +26,7 @@ struct xen_sysctl_livepatch_op;
 #define LIVEPATCH             "livepatch: "
 /* ELF payload special section names. */
 #define ELF_LIVEPATCH_FUNC        ".livepatch.funcs"
+#define ELF_LIVEPATCH_TRACES      ".livepatch.traces"
 #define ELF_LIVEPATCH_DEPENDS     ".livepatch.depends"
 #define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends"
 #define ELF_BUILD_ID_NOTE         ".note.gnu.build-id"
@@ -86,6 +87,11 @@ void arch_livepatch_init(void);
 
 int arch_livepatch_verify_func(const struct livepatch_func *func);
 
+typedef void (*livepatch_trace_func_t)(unsigned long ip,
+                                        unsigned long parent_ip);
+void xen_livepatch_trace_dispatcher(unsigned long ip,
+                                    unsigned long parent_ip);
+
 static inline
 unsigned int livepatch_insn_len(const struct livepatch_func *func,
                                 const struct livepatch_fstate *state)
@@ -120,8 +126,10 @@ void arch_livepatch_revive(void);
 
 void arch_livepatch_apply(const struct livepatch_func *func,
                           struct livepatch_fstate *state);
+void arch_livepatch_apply_trace(const struct livepatch_func *trace);
 void arch_livepatch_revert(const struct livepatch_func *func,
                            struct livepatch_fstate *state);
+void arch_livepatch_revert_trace(const struct livepatch_func *trace);
 void arch_livepatch_post_action(void);
 
 void arch_livepatch_mask(void);
diff --git a/xen/include/xen/livepatch_payload.h b/xen/include/xen/livepatch_payload.h
index c6dc7cb5fa..3a81abe0de 100644
--- a/xen/include/xen/livepatch_payload.h
+++ b/xen/include/xen/livepatch_payload.h
@@ -52,9 +52,10 @@ struct payload {
     size_t ro_size;                      /* .. and its size (if any). */
     unsigned int pages;                  /* Total pages for [text,rw,ro]_addr */
     struct list_head applied_list;       /* Linked to 'applied_list'. */
-    const struct livepatch_func *funcs;  /* The array of functions to patch. */
-    struct livepatch_fstate *fstate;     /* State of patched functions. */
-    unsigned int nfuncs;                 /* Nr of functions to patch. */
+    const struct livepatch_func *funcs;  /* The array of functions to patch or trace. */
+    struct livepatch_fstate *fstate;     /* State of patched/traced functions. */
+    unsigned int nfuncs;                 /* Nr of functions to patch or trace. */
+    bool is_trace;                       /* Is a trace payload. */
     const struct livepatch_symbol *symtab; /* All symbols. */
     const char *strtab;                  /* Pointer to .strtab. */
     struct virtual_region region;        /* symbol, bug.frame patching and
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 12 02:33:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 02:33:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388731.1629714 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtymd-00063i-Su; Wed, 12 Aug 2026 02:33:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388731.1629714; Wed, 12 Aug 2026 02:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wtymd-00063b-PB; Wed, 12 Aug 2026 02:33:35 +0000
Received: by outflank-mailman (input) for mailman id 1388731;
 Wed, 12 Aug 2026 02:33:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wtymc-00063U-DK
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 02:33:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wtyma-004Whu-Lp
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 04:33:32 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7bdb7b-e002-0a2a0a5209dd-0a2a4507d0b4-2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 04:33:32 +0200
Received: from [209.85.128.169] (helo=mail-yw1-f169.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7bdb7b-b4ea-0a2a45070019-d15580a9c9f4-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 04:33:32 +0200
Received: by mail-yw1-f169.google.com with SMTP id
 00721157ae682-8201447e8cdso6382187b3.3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 19:33:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786502011; cv=none;
        d=google.com; s=arc-20260327;
        b=cIhNd+2rRBGz+WXj54BeNngJzf+rLqgczaP5n1ZbwQCAxc8kDAdiA9kDQYE+AIqFhk
         8giI6Vets8tRN5ZtgpytCOKM/5dj4KkSWIuqvTeLkvSG+Lp7cw+INhOZLUudE9huwxLr
         FemyOvZVEljvZP8IkSRnjcVl+4+3nkUBYe17qtCQ3EdW1zVHUBSeNWjuq2RPbnuSlNPB
         oihTHKIZETsBI4gWsDH8mTiUggGbSRq/VGmqZav7QxeE8gx+Z1yhIkzz1jKDobrnoNQC
         gynd0LsH7jJvH09TbmK6MH/KHurqzUrQbK/L5IQHBLQis7k26kuBu6WltCNSUNpVMS3J
         OgEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=5TUs5xuISD/vB2CwHDcwdOp26J3qVXBqzemYHGJ3XMM=;
        fh=aU3/UpxH5Blg8M5NzH55q/XY8irYVWQMVJdPeFRWhhg=;
        b=eTr2+kcQH/XqIt6EuybLmKk3Kqt4LI3trqs6RD2xwaNd0d86ceBjulBp3T7PBAn91h
         1L6ovDM5XohrmO1FqkL2GYcCafHeKFviufm/k7R5nH0vRw+aCo8R6Y4/rB+8DuPF6oXO
         TTWq3q9pCvEhpcVjCRW9QiKDJQQxhcwwurYmjQHu9FnnBJIusq1fMmBvgrwHncdm05eV
         So0T1Itot/GveUA2XKiL0BMTP7jAVpUQPWux9DQbYRbyf8tj8Y8+bEKI5KlE2XfrReMu
         Ynnxk6fLc5iuLJjb7YL78cWfDBvcvWip8q3dmA/XI0pRfXqzqoC3DHAAeElVQZU0/SXu
         qv7g==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786502011; x=1787106811; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=5TUs5xuISD/vB2CwHDcwdOp26J3qVXBqzemYHGJ3XMM=;
        b=rUZUmokjascRkwAMWbwgjpMxm8ku6L6B3PFoGnufpY/UMP007pSJ0P8cXxVbtWpqbq
         msojbLddOpmKSTTXPU62no9I8ccWghKW1evSWBdbcHp3zXVeInx5+r/VglafsZnL+Tsl
         /sGgzPD5wA3b2hrEsQSzYvfSk686xGiKqufAlpThrVkwdVQsnMDwTgIJKDD8EZDWMVQx
         IikmMgrL4SXDloHSCZ8F4znv5mW1qdIftYDh27BgARB1UyhwgxN6PIYZx9p23xx+zUUx
         ZPobTVxqRIl4Qi+XWGloHX58SwvHRKZSaHNipPG6pJJ3LJTc4Udx/QicgnKWeZ23fwl6
         jIxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786502011; x=1787106811;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=5TUs5xuISD/vB2CwHDcwdOp26J3qVXBqzemYHGJ3XMM=;
        b=H/4wgYkj1G+GIsuzuZYhpC0kKjXn70y/gAH+W3yIWxz6qoCEoIOqUaT+9Q560jI98b
         zp9wbFRtMdp4/H9vRE42qu4by01UMHPZHiMeDrOvfvJKYOPlTvuIC+DKt0tAWMRRUci8
         AK33rC1u3ODmbS7eHy1jgEls/EkJiD19zgK3/CUavcVV2Ze6RnyiTR040FvtYOECt2R9
         Ubity80DoAmJtbDkxiFfutKtWpPYSNIIn01xexGTHZ4R1JNs8a/GEd/Q2WN7SfTDT1Yo
         akqk6pKRE97cPxiABjpCahOfaXlFkuJIVxyog0k/HBeKq6AYB+UtKwuUxFfKLVKru7xJ
         OKIw==
X-Gm-Message-State: AOJu0YycmPnMzxtzVOOrdlejXnebcXzG+BUxrBRvERulVACWjaFEAUUl
	scDjbsVc6Ng93+ESlWhW3BPoywzFfakLEwfB+LhrA1t7RtEhqqtIQWZNUvnNyiocMPEeRgEOCHN
	TCy1+BBDdD5fhX0+a/mby9SrRpiEJwsU=
X-Gm-Gg: AR+sD10BE2KrBODO6Wa8C5v+Fa60wOfeaTWeVv2nb7PR7D9G/j7ph6mVwQXl/W1lWtN
	75bQQQi2xvGYpwQMbpGpOnNq71syAw0NAfDbkcDDa6qEcGr206VgY8waECgHXib69CRPepkifPd
	l8fthBX9O94YIzO2ogHUEf0oWI+js28yY1JE2ya8kL5ynMHr3D9V3c+4WIKYL7iogneR3nkoc0a
	DkmNA0sl6RjPNkPHXrBWVhJkPQjkfo2x0ztargoV79kw6ilK1/iBe1c9Qx3vs2dFbg7td7j+JDP
	0j/OGZ14MPCA+0ST0mTIfJ9tFT0lYo1UXzC03alQF3f3dJSWBZTlKo7uOpppuIH7OnRP5JF24jJ
	7
X-Received: by 2002:a05:690c:6:b0:814:585f:73c8 with SMTP id
 00721157ae682-830ffffe960mr11281557b3.0.1786502011144; Tue, 11 Aug 2026
 19:33:31 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com> <1786448226.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3@vates.tech>
In-Reply-To: <1786448226.8631fc262581453bbf619ec5b2062170.19ff09caa3e000c4f3@vates.tech>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Wed, 12 Aug 2026 03:33:19 +0100
X-Gm-Features: AUfX_mxxkVhwuyHNB75iPDDuNf68KnVejQqT7vqTVfvexNmx1Ll2Ubf-cpYC5ho
Message-ID: <CAHt6W4fFwNJrKvWW_k9ARs9cJq7uUrqsCqSUb0PdY80=TubVCw@mail.gmail.com>
Subject: Re: [PATCH v10 0/10] xenguest optimisations
To: Anthony PERARD <anthony.perard@vates.tech>
Cc: xen-devel@lists.xenproject.org, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>, Juergen Gross <jgross@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-ef75cf/1786502012-A76D2AE4-8899F052/0/0
X-purgate-type: clean
X-purgate-size: 1348

On Tue, 11 Aug 2026 at 12:37, Anthony PERARD <anthony.perard@vates.tech> wr=
ote:
>
> On Mon, Aug 10, 2026 at 11:30:03AM +0100, Frediano Ziglio wrote:
> > Edwin T=C3=B6r=C3=B6k (3):
> >   libs/call: cache up to 4 pages in hypercall bounce buffers
> >   libs/guest: allocate various migration arrays just once
> > Frediano Ziglio (6):
> >   libs/guest: move batch_pfns into a separate structure
>
> I've committed these first three patches.
>

Thanks.

> I've notice that `git am` will put the wrong author on your patch, it
> would use the gmail addr instead of the citrix one. Could you fix your
> config so that `git` does the right thing? I think it is just a matter
> of changing the config:
>
>     git config sendemail.from 'Frediano Ziglio <freddy77@gmail.com>'
>
> (with maybe --global or with an identity added to the config option if
> you use that).
>
> This will tell git that the email is send from a different email
> address and it will format the patch appropriately. Otherwise, gmail
> just overwrite the "From:" without telling git. The original "From:" is
> still available in "X-Google-Original-From:" but it's not something git
> should care about.
>

Done. Yes, it looks like it is working. An additional "From; xxx" line
is added at the beginning of the body.

> Cheers,
>
>

Frediano


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 04:06:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 04:06:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388739.1629722 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu0EO-0001UR-9A; Wed, 12 Aug 2026 04:06:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388739.1629722; Wed, 12 Aug 2026 04:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu0EO-0001UK-6Z; Wed, 12 Aug 2026 04:06:20 +0000
Received: by outflank-mailman (input) for mailman id 1388739;
 Wed, 12 Aug 2026 04:06:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <anshuman.khandual@arm.com>) id 1wu0EM-0001UC-AN
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 04:06:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu0EK-00Dmsa-KK
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 06:06:16 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7bf10c-8faa-0a2a0a5109dd-0a2a45078e38-46
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 06:06:16 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <anshuman.khandual@arm.com>)
 id 6a7bf137-b4ea-0a2a45070019-d98c6eace702-1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 06:06:15 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B399D1596;
 Tue, 11 Aug 2026 21:06:10 -0700 (PDT)
Received: from localhost (a085714.arm.com [10.164.19.28])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 018DD3F86F;
 Tue, 11 Aug 2026 21:06:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1786507574; bh=IHjypAHsNKjpNGDu8aCRCeoUOQ9LFF7rYITg0sTzbDM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Rg9GEe8ORnIQSzAFzPE9Q3CsOniFeZz3B5DAx1vSbU2ayamMlqi+pdI/abA/SWthR
	 JHd2kD7S7LWpcNIoT65928j5y1fwj3S00eMdlQR9LYSfVNqmGWvx2Jo8nRyP2/XrUC
	 occW+1n2ku+jahULG28ttJSOr0S4qPMQj+wCR/cQ=
Date: Wed, 12 Aug 2026 09:36:11 +0530
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>, 
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, 
	Tvrtko Ursulin <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>, 
	Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich <dimitri.sivanich@hpe.com>, 
	Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>, Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Muchun Song <muchun.song@linux.dev>, 
	Oscar Salvador <osalvador@suse.de>, Andrew Morton <akpm@linux-foundation.org>, 
	"Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>, Will Deacon <will@kernel.org>, 
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, Nick Piggin <npiggin@gmail.com>, 
	Peter Zijlstra <peterz@infradead.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, 
	David Hildenbrand <david@kernel.org>, Pasha Tatashin <pasha.tatashin@soleen.com>, 
	Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>, 
	Uladzislau Rezki <urezki@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, 
	Masami Hiramatsu <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>, 
	Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, 
	Eduard Zingerman <eddyz87@gmail.com>, Kumar Kartikeya Dwivedi <memxor@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>, 
	"Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>, Jason Gunthorpe <jgg@ziepe.ca>, 
	Leon Romanovsky <leon@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>, 
	Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>, 
	Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, ziy@nvidia.com, 
	pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com, 
	linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, 
	linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, 
	linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, 
	linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, 
	damon@lists.linux.dev
Subject: Re: [PATCH 3/9] mm: name pointers to copied PTE values ptentp
Message-ID: <hwkurkpobxysltkid5523qxndufebqqmat4qjaq6zhwno2drmh@efwoegm2huo6>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-4-usama.anjum@arm.com>
 <e7osakog3yvdewhdlrk3bsp27pwt2nnhroeb7zihlfxyjotarb@rwxkcb25crh3>
 <b21c4cc9-84a3-429e-8156-0b9967b2f133@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b21c4cc9-84a3-429e-8156-0b9967b2f133@arm.com>
X-purgate-ID: tlsNG-ef75cf/1786507576-350CDAE4-4482937D/0/0
X-purgate-type: clean
X-purgate-size: 5338

On Tue, Aug 11, 2026 at 03:09:07PM +0100, Muhammad Usama Anjum wrote:
> On 11/08/2026 11:58 am, Anshuman Khandual wrote:
> > Subject line is very confusing. Perhaps something like the following.
> > 
> > mm: Rename pointers to copied PTE values as ptentp
> > 
> > But even 'copied PTE values' is not very clear as well.
> 
> Something like:
> 
> mm: rename pointers to logical PTE values as ptentp
> 
> or
> 
> mm: rename pointers to software PTE values as ptentp

Yeah but we need to get these nomenclature right at the very beginning
and also probably get it documented some where.

> 
> > 
> > On Thu, Aug 06, 2026 at 09:38:41AM +0100, Muhammad Usama Anjum wrote:
> >> The hw_pte_t conversion must retain pte_t * for pointers to standalone PTE
> > 
> > We need to explain what is `standalone PTE values` first.
> > 
> >> values. Name the value parameters ptentp in the install_pte callback,
> >> write_protect_page(), and guard_install_set_pte() so the later mechanical
> >> conversion can distinguish them from pointers to PTE table storage.
> >>
> >> Some functions already use the ptentp name, including:
> >> - madvise_folio_pte_batch()
> >> - folio_pte_batch_flags()
> >> No need to convert them.
> >>
> >> This is a naming-only change.
> > 
> > Small nit - s/naming-only/rename
> 
> I'll fix it.
> 
> > 
> > The commit message needs rewrite clearly explaining the following details
> > 
> > - What are standalone PTE values
> Logical/software PTE is correct and better name here.

Right but we need to define these early on and then be consistent in their usage
afterwards in the entire series.

> 
> > - How these are different from HW pgtable pointers
> > - Change is just a rename for pointers into such 'standalone PTE'
> > - These renamed 'ptentp' here would be used for skip or replaced during
> >   upcoming mechanical change via a script
> > - No functional changes intended
> I'll update message in more elaborate way.
> 
> > 
> >>
> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> >> ---
> >> Changes since RFC v1:
> >> - Update the description for the architecture opt-in conversion.
> >> ---
> >>  include/linux/pagewalk.h | 2 +-
> >>  mm/ksm.c                 | 4 ++--
> >>  mm/madvise.c             | 4 ++--
> >>  3 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
> >> index b41d7265c01bc..c34d826c5e4a2 100644
> >> --- a/include/linux/pagewalk.h
> >> +++ b/include/linux/pagewalk.h
> >> @@ -89,7 +89,7 @@ struct mm_walk_ops {
> >>  		       struct mm_walk *walk);
> >>  	void (*post_vma)(struct mm_walk *walk);
> >>  	int (*install_pte)(unsigned long addr, unsigned long next,
> >> -			   pte_t *ptep, struct mm_walk *walk);
> >> +			   pte_t *ptentp, struct mm_walk *walk);
> >>  	enum page_walk_lock walk_lock;
> >>  };
> >>  
> >> diff --git a/mm/ksm.c b/mm/ksm.c
> >> index ad05d7791307e..11d50518d02e9 100644
> >> --- a/mm/ksm.c
> >> +++ b/mm/ksm.c
> >> @@ -1292,7 +1292,7 @@ static u32 calc_checksum(struct page *page)
> >>  }
> >>  
> >>  static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
> >> -			      pte_t *orig_pte)
> >> +			      pte_t *ptentp)
> >>  {
> >>  	struct mm_struct *mm = vma->vm_mm;
> >>  	DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, 0, 0);
> >> @@ -1371,7 +1371,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio,
> >>  
> >>  		set_pte_at(mm, pvmw.address, pvmw.pte, entry);
> >>  	}
> >> -	*orig_pte = entry;
> >> +	*ptentp = entry;
> >>  	err = 0;
> >>  
> >>  out_unlock:
> >> diff --git a/mm/madvise.c b/mm/madvise.c
> >> index 07a21ca31bad4..c324cc991f841 100644
> >> --- a/mm/madvise.c
> >> +++ b/mm/madvise.c
> >> @@ -1101,12 +1101,12 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr,
> >>  }
> >>  
> >>  static int guard_install_set_pte(unsigned long addr, unsigned long next,
> >> -				 pte_t *ptep, struct mm_walk *walk)
> >> +				 pte_t *ptentp, struct mm_walk *walk)
> >>  {
> >>  	unsigned long *nr_pages = (unsigned long *)walk->private;
> >>  
> >>  	/* Simply install a PTE marker, this causes segfault on access. */
> >> -	*ptep = make_pte_marker(PTE_MARKER_GUARD);
> >> +	*ptentp = make_pte_marker(PTE_MARKER_GUARD);
> >>  	(*nr_pages)++;
> >>  
> >>  	return 0;
> >> -- 
> >> 2.47.3
> >>
> > 
> > How did we ensure that the above changes are comprehensive and nothing
> > else got left in here ?
> 
> The order of patches and even the code was found out after adding hw_pte_t
> structure. Then everything was converted, until some pte_t pointers were left
> which didn't require conversion.
> 
> If something is left, we'll get build errors when we build a converted architecture.
> So the branch mentioned in the cover letter when built, would produce build errors.
> (Those patches would be sent separately, after finalization of this series).
> 
> Whenever I'm rebasing (on mm-new), I'm rerunning Coccinelle script to see if new code
> has arrived which requires conversion or renaming.

But in the early patch where the manual renaming was done for the script to
pick up 'ptentp' patterns needs to be audited again.

> 
> -- 
> Thanks,
> Usama
> 


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 06:29:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 06:29:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388750.1629732 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu2SN-0003v2-Uk; Wed, 12 Aug 2026 06:28:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388750.1629732; Wed, 12 Aug 2026 06:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu2SN-0003uv-QQ; Wed, 12 Aug 2026 06:28:55 +0000
Received: by outflank-mailman (input) for mailman id 1388750;
 Wed, 12 Aug 2026 06:28:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu2SN-0003uo-20
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 06:28:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu2SL-005txm-5b
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:28:53 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c129d-bab6-0a2a0a5309dd-0a2a450aea1c-14
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 08:28:52 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c12a4-f2d2-0a2a450a0019-d155802ed1b9-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 08:28:52 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so4851695e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 11 Aug 2026 23:28:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997abf94c1sm44841725e9.14.2026.08.11.23.28.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 11 Aug 2026 23:28:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786516132; x=1787120932; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=YVg90yFmwII+LbLwDw+Exz3K4H1Lnit4dmi2Gn6xOFs=;
        b=StvGAcyxr+zINClrFGYw6VKq/YEzFdF1z7/m1GzHqmYYq11ONRIxPSOYW6vxs/aYb6
         ARoe+bVow7NP4d+HPU3r+pWn5uu4uETvFKETNCdtH14KnUDto1wwMTx9GGtRc0jyFhu8
         4lj5hXzQ59BzCk5GYSrdOAfln57LgSzuGIT/Lb8tHYDVpNTcIDuk9kQlc4C26YHjlBDN
         yp1pSJZlnJF1xR7jll6IeG2kBthUXCVnWlYIF+T/ng7Yz6tiFaCyrliEzOjvL/8/ClI4
         CKZhuuUQ/JtId7xbVZHG0+JDr4MkxvKsZ7SQhaSNh/DfLqikGQ0kgLfpqTKEVO/KREIu
         ffHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786516132; x=1787120932;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=YVg90yFmwII+LbLwDw+Exz3K4H1Lnit4dmi2Gn6xOFs=;
        b=IJ79q4B7KnizOZK+lsToIcjnYXbDsKpToWkOQDM52palz808hHU0/Ym3og+bkjgpsm
         yQaMQEojaxHfY8umpyIN8ZuEBRes2PhJeOUhzgQZPbMZC191Su6nCxT23op//8Zzas2c
         Pta9aAkXFqWkZA7WUALa7tJFmyzDg8PVlkvPHqSwczhCzfXnQWrqOEFa2xMKHFR+33Ht
         rVbdQNaPNr8otboNkcY3KmuxQjVrEWectr6ro12kcqJdgUlqCHfNkisXv13t4UEK3aDY
         VgoTCN1fzi2ioAyP9QBdi33G2Wd3LygQeLAenZEWrQT5aJBco+EEDR+7U6tL9JPPEnzH
         RxdA==
X-Forwarded-Encrypted: i=1; AHgh+Rq1ESl3C//GnyTHyrah5cVaK6pfDW8bBESgkJKb/2PdjuF0iFP1JFTKVRcKv07XiroqAVup56fcmm0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/pFnR+IWYH30KZTNa2tr3xMkLoqAkO6UIL/LzJgcsmvdAAQhZ
	rOeCcCzo4LnJ+8osnDByieeAMJ4d7hv/d0osbhdnWcPLo/s8imPzz+KCENjak7Lh8A==
X-Gm-Gg: AR+sD13n0w+osOqW03GWNQ/coTOWC72ppR80QB5jFNX2kJt+gPl4IC23320BYzIjL0G
	4nh23fjNA5LAYz7WwFNNGPDulDiA4aoSDCAFhGXgdq8oBU/EwlCZt/d6eGOjrYqjOgqA1NMYD20
	Ab8yPVQD11pF5wRfKvLLRZ9HSyymTUJEvkJFo/bstlGJNopaQ1L1Q4ZZCxA+0SevbnlOt8fkmPj
	jTV73zZWC/b4MY/0D9IzyeOYx1FYmBhCE19wQ6uluRisdBH+hbdjLNtQYt+d8Lo07d9kpo8oxtD
	dXG/CiCRvUCiPGFfANCXOJWFDNkS3MTin/nBIzXLgC56Jh0/KeQAv/8xiz2Fx7E9wC5DJTQxjAG
	Xw3nfwRKi3aOrJROwYVN7mzLHRZ0oBigRU6mHMo9ASDSMnzV+avbPJAzf6vEnsqlJfqiaeD6iyr
	4QMh2Oshr2XFyxPxOklthKOg2W8oJwlv6+rZpwx2juN5ap0K/aLXLHfrACvpm2IMspcZG93dGnB
	/g/SqN4Byr5WKCj5dGQHMROelQ4hszGgSh62OBCDfyvdpcWdWALyJeJtmDBu+c=
X-Received: by 2002:a05:600c:524c:b0:499:7219:122f with SMTP id 5b1f17b1804b1-4997c39ca1emr25119805e9.4.1786516132439;
        Tue, 11 Aug 2026 23:28:52 -0700 (PDT)
Message-ID: <a711a0d1-dbf0-44fb-a419-38abc62480ad@suse.com>
Date: Wed, 12 Aug 2026 08:28:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86/pci: prevent cross-device accesses in
 pci_mmcfg_{read,write}()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-2-roger@xenproject.org>
 <c818745e-6f61-4b32-b7f5-ee5b7ff82981@suse.com>
 <anWQ15K8vi3t1sgF@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <anWQ15K8vi3t1sgF@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786516132-506CECFC-9F9328DC/0/0
X-purgate-type: clean
X-purgate-size: 2296

On 07.08.2026 10:01, Roger Pau Monné wrote:
> On Fri, Aug 07, 2026 at 08:22:44AM +0200, Jan Beulich wrote:
>> On 06.08.2026 17:26, Roger Pau Monne wrote:
>>> Introduce a specific check that prevents an accesses from spilling across
>>> two devices.
>>>
>>> Signed-off-by: Roger Pau Monné <roger@xenproject.org>
>>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> albeit with a remark:
>>
>>> --- a/xen/arch/x86/x86_64/mmconfig_64.c
>>> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
>>> @@ -61,7 +61,8 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
>>>      char __iomem *addr;
>>>  
>>>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
>>> -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
>>> +    if (unlikely((bus > 255) || (devfn > 255) ||
>>> +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE))) {
>>>  err:        *value = -1;
>>>          return -EINVAL;
>>>      }
>>> @@ -91,7 +92,8 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
>>>      char __iomem *addr;
>>>  
>>>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
>>> -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
>>> +    if (unlikely((bus > 255) || (devfn > 255) ||
>>> +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE)))
>>>          return -EINVAL;
>>>  
>>>      addr = pci_dev_base(seg, bus, devfn);
>>
>> In both cases the unlikely() uses won't have the intended effect, from all I
>> know. They would help as used here only if the compiler managed to fold all
>> three parts of the ||-expression into a single conditional branch, which I
>> don't think it would end up doing.
> 
> I don't mind dropping the unlikely() while changing the line.  I tend
> to leave those alone if present, even when I'm not sure they are
> actually helpful.

I think unlikely() is actually reasonable to have here, yet it would need to
be four of them, not just one. Unless reachable from a DomU-accessible path,
converting to BUG_ON() (or ASSERT_UNREACHABLE()) instead would also be an
option.

>  The comment ahead of the check is also not very
> useful IMO, but I've decided to leave it alone.

Indeed, that's an odd thing to survive over 20 years (I think).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:22:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:22:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388760.1629741 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3HZ-000386-Ix; Wed, 12 Aug 2026 07:21:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388760.1629741; Wed, 12 Aug 2026 07: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3HZ-00037z-E6; Wed, 12 Aug 2026 07:21:49 +0000
Received: by outflank-mailman (input) for mailman id 1388760;
 Wed, 12 Aug 2026 07:21:48 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu3HY-00037t-D8
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:21:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3HX-0064TF-1E
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:21:47 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c1f07-2eae-0a2a0a5409dd-0a2a4503d8a2-8
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:21:46 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c1f0a-fae8-0a2a45030019-d155dd31c440-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:21:46 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47fecbbafdaso152514f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:21:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150d702c9sm4852995f8f.34.2026.08.12.00.21.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:21:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786519306; x=1787124106; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=L5vpURs3yad1Td8RhRxntoH7HJSvYuQccNB1curUvwc=;
        b=EuL5wCFg5Md3TKLvlN8yd8FgARGYyHTQCQcBTG7dKBtEo+xoJJqOixpqIHEBCb+5YZ
         oJZZV738rd+hzgKX2njLPL7KAiqt/GEOtLK6AtainfP2D2HiT/Grfz/asPUzKW2pLnH7
         AeDKvu+ghcuIUHiFeQPCjvDBTa3rSaKY3oiEM5bLdWIflOs2WlRIaVd0Eycq+5wP2apW
         OcGE0MCU3rrmrpZwCP0/sST0esa+jjXztnLxR/d7mYMFFl5VIjbersMqLJGP7GgVU/OB
         OSHKGtdblcQoU2sZsCDh5ctk0jddcRvfJQqMzxfOrWiDrX7JKkrXxA0995sBD50S+oBp
         TMJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786519306; x=1787124106;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=L5vpURs3yad1Td8RhRxntoH7HJSvYuQccNB1curUvwc=;
        b=jCv6mvKE8HOgX3VHlu35tjVvLyAsUEo5XNMLiNBEJXeRjimk3s7RFelD4euMuj/5P3
         a5cc3O1CATENHiTyei+ZIwyFTbMJR2buc5V27h31HVXu5oaVfccA0wYyi9vK1JPl4WS+
         WRAgd01dyZh4M69UcHnXegwPHWbwXnN4m5mLpO+FYwLFVjf6RqeKWJKSgrZBItMYcDy1
         qsk4p5DtHh74aNgRFU+hjgctsjrfsDSMw5L+yT6thLSSkyAFbb4NBk65bcrv9Cv6cH7X
         oWdhfAQhIxPiWFyLsDSESD0lC9YID+upS4axPZka9XL1tWwC63x8c6/pgG03L4MihF7Q
         DiyA==
X-Gm-Message-State: AOJu0YwbfA7C6t4aEf8+70riw3NRO92VT6uo3aWQtddFXcrES5xKdmnT
	dzhI8nIFTbOLlPhEMup+SnFshCxgOUSeq/brCdnFwcPLOi/TjgHlwcpOvz9yeZlqog==
X-Gm-Gg: AR+sD11E3niUzq+66z3NIwnf/mgsRMqsSX/oc7wnDzcH2A1P9+OlopG7eKS9LfNuZmp
	7lCjIQ5eqvPmQuivnS91xw/AZG040kGp4hbGxQ4Z2LYzFvcZIMJIvlgOcBn9CjAL/V6tfQH5YrM
	74X1KdoeSwhE6iV0kpWIlFXgo0ZQONtdXYT29KNoLwj/ZQhguZwrJ4ZNmvwc8ehHfAaLvt5+6e8
	kSdKGbaqFoAPiYrAW9Ys6Obk3Tnittxqh5ZjLDspqfHpssGRfTAsEC3dsXXxX0QmQTK075I5n0Z
	nJgkj6TIVIsal5iuHduiim3dBpnc4a3sziydLKg8YLyO2uxvNONOZMk9mUjlrURFRpA/rTwAuDL
	RKpXN/B2Mh1ivJao8asMzG6vrVFLNn/faf86M76NLSnGu6fZO8/FZ8qWMB5LcZU0EgASyo6Xezt
	twVGUswMYUtNg2GReaRupMR+S6aWv/72p13Ofv9MGkQqA0BCm+pjjA8lpJhIsM6zeZsg46N3Ixa
	+WE9dhCxf42VRgJGN6w0VQSx7cpx33BjzeMGThwMmSLkSsgLMWY
X-Received: by 2002:a05:6000:26c9:b0:47f:91e3:3cbf with SMTP id ffacd0b85a97d-48152b03a57mr3521512f8f.19.1786519306253;
        Wed, 12 Aug 2026 00:21:46 -0700 (PDT)
Message-ID: <b7754a86-4602-4b41-a07e-3e6389dac78d@suse.com>
Date: Wed, 12 Aug 2026 09:21:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
 <05283ea0-de82-4160-a3f9-5fc1292a20a5@gmail.com>
 <1786436246.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@vates.tech>
 <a58af12e-13f0-48a3-b39d-bff92991ccd1@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <a58af12e-13f0-48a3-b39d-bff92991ccd1@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786519306-6F8C54E9-3A3F27F8/0/0
X-purgate-type: clean
X-purgate-size: 822

On 11.08.2026 13:49, Oleksii Kurochko wrote:
> On 8/11/26 10:17 AM, Baptiste Le Duc wrote:
>> On 2026-08-10 17:36:56+02:00, Oleksii Kurochko wrote:
>>> On 8/10/26 4:49 PM, Baptiste Le Duc wrote:
>>>>> +/*
>>>> Why have you included a copyright notice here, but not in the other
>>>> files?
>>>
>>> So I just decided to do that for new files as I am not using corporate
>>> e-mail.
>> But why didn't you do it for all new files of this series?
> If there are such cases then I just missed to add it. I will double 
> check during preparation of v2.

Hmm, I'm a little irritated by "missed to add". In past discussions (plural)
the usefulness of such copyright notices in comments was put under question.
They go stale anyway as code moves around. And likely there were other
aspects that I forgot.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:28:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:28:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388770.1629750 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3ON-0003s2-A8; Wed, 12 Aug 2026 07:28:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388770.1629750; Wed, 12 Aug 2026 07:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3ON-0003rv-6c; Wed, 12 Aug 2026 07:28:51 +0000
Received: by outflank-mailman (input) for mailman id 1388770;
 Wed, 12 Aug 2026 07:28:49 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu3OL-0003rp-DM
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:28:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3OK-00BWVC-0v
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:28:48 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c20af-8faa-0a2a0a5109dd-0a2a450289ee-4
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:28:47 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c20af-6ca4-0a2a45020019-d155dd2ac885-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:28:47 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-480033bdcf4so303683f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:28:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150c08982sm4569641f8f.14.2026.08.12.00.28.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:28:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786519727; x=1787124527; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=xwB9N5vVJbxMsrg6ZAAsJzD0IEYTQdn0hmUXkK9isnE=;
        b=MkyGCAlwwbSn8qQ2ZiD6wu2bJcIxoXKWLZzKUhJ95ateth9/NQyt+Tsjhep4C98Dn+
         BhQpZVtCJJezRZ+plS0xdtjeQElfYg+RdumzRBVRLw6rDaYE4RytgF+TD0IqrPYAy1mb
         8kvVL7hZdy4VpGh5oK1I7J8bE8SXygq2TYQ35KEV+DH1Cm8OcjLCFUyIFBS3Z+T2zzHk
         S+Tkdxr7t0bCOu8TpFiiMSg6hxJMQk5P/PPGCpfjMG2olvRJfiWOhFU1hRvhpscmUHP7
         u2thMbd09oRFIUWcs4KeSzMKYpByVy2Jk0qA5ceMAUnOnM8hOk+vLrQuCSNzAfTULuWC
         X1sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786519727; x=1787124527;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=xwB9N5vVJbxMsrg6ZAAsJzD0IEYTQdn0hmUXkK9isnE=;
        b=SMeyUFuPxEqcytqusGWk/CRz4IOhBazmaH2IRXwR3rABpzsICV0/nwonJoZwYV66Wt
         fuWgN+YZzzUN4r/2LotqGFnoe18vFJl8ynNRUTCXL/71NnOjF7EGsXWQ+/ndxRXiHgNn
         Ob3h8H+AjM16UTxxN+PpTiYcfvFZ4ii81dZPDs2d3mGFaFE4F+M1FxS8Olgz1XArRfsL
         o4ATEK/FHYFyiRlwYLQ6MjkMevgTkv39TnrcPXhJlAg2aEm/kM4RdCrPoyTZoDAEUwww
         guBjfH7OWkZVlRx4pDY9teyD8s5wsZ6IVvyZbJxkZ8H41i/b3WBRkDaRDmqmtpltNVWV
         GAAg==
X-Gm-Message-State: AOJu0YxjsK0y6eH3o/9PUaaZLjUTVIrDBVwEN6Ya/R+IoTOePijQFhE0
	nIrbjn/oiUgGzqtUt/KHKYK+ZqqMuNXfqnsViMRWMTH+T4qBuSkY+czmcxL6EhlmCQ==
X-Gm-Gg: AR+sD11YXmJ5QaekoA/P3YWvLxYN35lHvNalfD/r2Y+pX1VQiNilWfvVpc9OB7+Z2XV
	itHBplGyAKxBq6OwM1xLVqb16T627pcy6C7lYijXjZeuMfamqlttZX94B0n7mVpOuD8CK+s6S/5
	JNv+7QRDkp/reeO+hAHtdq69trEyeqW5dfXh+nw1JVRtK2jkOcivkt06xCBJDLmqloqrYtkW5Jr
	WJzLt37hPxOH/wP5PxC6CtuT8jyAQC0aD9fpx3rDwbDHL0sVReQao/Mmo4lvvN5bwDAwD0NQyQE
	wM+a81QrH6JmYjyu01UlluZ6UM/ZtBuGT1g3ynhbSuAR9rGL+Ojc3kPRp7kYySrQkOytmZl7HAT
	0laCKDY15lRabNa2ChgmR7a5IQWTVkuMKp3LIhYxKW3EyDK9g/NfGTxU6Yhk6/J0Qt66+Ws3lAT
	zD6SDN0zpo5TLXwv+J128IH39v+BvOCsbj6wwom/36fq3FEyswFA7KNJ9gqute69QLwE4j2o6Wd
	CYq1WS3GsBkApOZSDcyxRd2/hNQNIJHtnU/CFn+UCCSsFQOtbyPzFMf5FUc+Qw=
X-Received: by 2002:a05:6000:46cc:b0:481:511c:8d3a with SMTP id ffacd0b85a97d-481528bfe55mr2689738f8f.2.1786519727440;
        Wed, 12 Aug 2026 00:28:47 -0700 (PDT)
Message-ID: <ba78a8a1-6862-41b0-a6a5-cae7eada3627@suse.com>
Date: Wed, 12 Aug 2026 09:28:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/common: add keyhandler to show Xen command line
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 sstabellini@kernel.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <20260810230359.671587-3-dmukhin@ford.com>
 <anrXvTfBls4flBqK@macbook.local> <anuMfq/lDjxbR8Om@kraken>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <anuMfq/lDjxbR8Om@kraken>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1786519727-F1CAA2AC-B1F63E74/0/0
X-purgate-type: clean
X-purgate-size: 1297

On 11.08.2026 22:56, dmukhin@ford.com wrote:
> On Tue, Aug 11, 2026 at 10:05:17AM +0200, Roger Pau Monné wrote:
>> On Mon, Aug 10, 2026 at 04:04:01PM -0700, dmukhin@ford.com wrote:
>>> +static int __init cf_check misc_init(void)
>>> +{
>>> +    register_keyhandler('X', show_hypervisor_info,
>>> +                        "show hypervisor information", 0);
>>
>> "show hypervisor information" seems too generic to me, almost all
>> debug keys could be defined by this sentence TBH.  I think this needs
>> to be more specific, but I'm not sure what's the plan regarding this
>> key.  Is there an intention to print more stuff here, or just the
>> command line?  Knowing the full set of information to be printed might
>> help come up with a better name.
> 
> I will update to "show_cmdline" since I originally planed to expose Xen
> command line only so it is possible to better debug a system when dom0
> becomes almost unresponsive.

Yet as indicated already on v1 (I think) - a precious debug key character
for just the command line seems rather wasteful to me. If it's only the
command line, and if that _really_ needs exposing via a debug key (i.e.
if there are reasonable scenarios where "xl info" cannot be used), perhaps
attach it to e.g. the 'h' key output?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:40:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:40:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388780.1629767 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3ZQ-0006x0-Dj; Wed, 12 Aug 2026 07:40:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388780.1629767; Wed, 12 Aug 2026 07:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3ZQ-0006wr-B4; Wed, 12 Aug 2026 07:40:16 +0000
Received: by outflank-mailman (input) for mailman id 1388780;
 Wed, 12 Aug 2026 07:40:14 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu3ZO-0006vw-AJ
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:40:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3VF-00DIx1-R9
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:35:57 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c225a-2eae-0a2a0a5409dd-0a2a4504e6fc-14
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:35:57 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c225d-b57f-0a2a45040019-d1558032e07f-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:35:57 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4956242332dso5506435e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:35:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997ad79e5csm27165225e9.3.2026.08.12.00.35.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:35:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786520157; x=1787124957; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Z1bRtFRY89P4xtwcddqUbTl5+L6bmLdItlBwZdRvoBo=;
        b=fSUVisZYPfgYr81QACXvMPuCsiYVPGYPM3MDSpuYSh0BJsLpOAg97X39HdVeLcvCx0
         1ZewzIUV1g92V39ifFY9YujuthYGNQcjLPdHY4coqEblSZ6h2zCS5GCNPbxCilJrP6Rz
         MxmUD2N3/X9+dckB51Z0onQXzzFNmxUsbivAmOp63LWEZxBTyfRd9Rzx6wmjhw/F9OLU
         vAPRjvCQUSizSP5lnUeqKqs5l6j51jSDKBztjPnNCBzGlxOBdZ10DkH0QCLVgg9dggNc
         0ldocKty8QCH8MNRqScCttuxU6/9iUCwvGLueny6sJyf+nOybTBDvBLeD5M0ivJ1iCoL
         RAEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786520157; x=1787124957;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Z1bRtFRY89P4xtwcddqUbTl5+L6bmLdItlBwZdRvoBo=;
        b=FgHss2ilVPSV7nHzqUDJ+yUNckyPzA/EqjWwryYNLAMz8OHx/NmG5Fr0MLr6IzUei2
         ylqoRdfdVn9m61oVnXqUWINSTSOXzF24F+4SwLFeqb3XSSzCcbugA7P8xnLDvVR363hf
         uT3tIFcpuG7Fvrx7lrOBAfJaC38OkI+jucFDmoiQ7M5W+GzJsuOtqtUcuvmW4MyXuBrW
         3ak8b9D6z+7i5u1h5AJgJ5dvtdWGI/mBG3/YhHA5bFnDNlWGjN0oSe8iiaPPth9GBWil
         s/pzb2Ek/f4RqHJhzH7E+K4+FwMiSehzYj6mqvixaTNCCbKfOcqNsDkrKnKACdcywKIy
         KoVQ==
X-Forwarded-Encrypted: i=1; AHgh+Rqyl5DYl/gZ3hmjvGeE3MmOoQ8YFp7SqBGOjlEyqnnooxFj/4IDtznCxZJ2VF/F/2tAHoCHZvYgmso=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzfXg6w1PMykI1vymW6ValDRrRey3CxzJg0HSHBtIv+lupziT5E
	1l9lkon3PWPTFL7diQBWicuLjlLI3cAJkbJPcfEaQLc/xMY7z33+vvE1Q2QnNBDANg==
X-Gm-Gg: AR+sD121NgG7kMs2AGojWQdjDCl7tEogkmnOnVt3p733zCGtAEzNH/6c5XpOhxn1pAq
	FbmghpucD4ZsCTUdwB912A8dQJg/8FFUVK4DqHt8pUn5oAQJ4YFnkST70f76tTJMimxtNcmgIl0
	BFYrRw71g3W4kLQ7d6cxv7nyOdy13sfELB+pNWnv2Qry0d3hoRAZhsbPZ4zaLdmG9ibbDGaA+JO
	jlCjGgCxGnaCrcNUa2GlnOvJZ1khpG4kDwucdC0ZAIG+18h3LVrWI0slPe5nBb2beYbtGOXC4OC
	GUOXHm1VoaRKhAxhtWgXC1QnSBQL8RKGb+JRi6vc4hahfPYSvxjmmh/5lKuR1HDsI7YwGbdKUHD
	Uj1VH3dozM5/u3/OvdjFLM+heKavtHVdZ0LShYvjeP8U4k8XLixCJFzYsMGMzXDdyEMg3KAoEIN
	D8Pe8OX1gBMF+U/U18rZ/Uq+EWXhhbmkD3ez7r56MlLCY8p0qFCwHwFV0o3INJWNaTnqNpGk2hO
	WeS3JkrVZLu//me4dz2Bt4ssqp7ZWmMaLwDP5hB6p2iFgWv+H386A==
X-Received: by 2002:a05:600c:8209:b0:495:4d88:e630 with SMTP id 5b1f17b1804b1-4997c12b341mr42019485e9.10.1786520156055;
        Wed, 12 Aug 2026 00:35:56 -0700 (PDT)
Message-ID: <3e4526e9-0ce6-4620-820a-c670a3c01201@suse.com>
Date: Wed, 12 Aug 2026 09:35:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen/common: add keyhandler to show Xen command line
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260811210956.3806559-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260811210956.3806559-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786520157-508D9B50-01B8C419/0/0
X-purgate-type: clean
X-purgate-size: 1026

On 11.08.2026 23:09, dmukhin@ford.com wrote:
> @@ -505,6 +506,37 @@ static int __init cf_check param_init(void)
>  __initcall(param_init);
>  #endif
>  
> +static void cf_check show_cmdline(unsigned char key)
> +{
> +    const char *builtin_cmdline = CONFIG_CMDLINE;

Maybe compilers manage to optimize this to the equivalent of

    static const char builtin_cmdline[] = CONFIG_CMDLINE;

yet even then I see no reason why it wouldn't want spelling that way anyway.

Plus this raises the question: Why would we need two instances of the string
in the Xen image? If you need the literal at runtime, re-use
opt_builtin_cmdline[] by dropping __initconst from it.

> +    const char *cmdline;
> +
> +    printk("'%c' pressed -> showing hypervisor command line\n", key);
> +
> +    if ( builtin_cmdline[0] )
> +        cmdline = builtin_cmdline;
> +    else
> +        cmdline = "<NULL>";
> +
> +    printk("Built-in command line: %s\n", cmdline);

What use is this line when <NULL> is shown?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:40:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:40:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388778.1629758 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3ZC-0005wv-8U; Wed, 12 Aug 2026 07:40:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388778.1629758; Wed, 12 Aug 2026 07:40:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3ZC-0005wP-51; Wed, 12 Aug 2026 07:40:02 +0000
Received: by outflank-mailman (input) for mailman id 1388778;
 Wed, 12 Aug 2026 07:40:00 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu3ZA-0005i2-QT
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:40:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3Z7-00GhUG-KN
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:39:57 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c233a-bab6-0a2a0a5309dd-0a2a450acd24-46
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:39:57 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c234d-f2d2-0a2a450a0019-d155dd33e81c-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:39:57 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47f6609c657so265669f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:39:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150c088c9sm5099265f8f.13.2026.08.12.00.39.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:39:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786520397; x=1787125197; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7kvlaIyT3C4mq2SKhDRTcCFghu+creUAQezA8qqNSTM=;
        b=JUITOViiR50TQrStdGe1ZwpRkcRRPkQ1dOqR1T+MRGH8LlOFm2mTxe0gJw3VTe8B+q
         LVEEVSdTkGJEeXPZnYfUULg5/h0lXKmTI4snrWIYotZFcULGwzbMF5HO9HxLNDo7DZaF
         Um7/slFTyhJ5FBt/DIcSTjLm/wIbooglEjjesw8LWX6AU3WiFE1QYM4kTWHXM9+H8vd0
         Sx/XC2FD4SWMsEj4Px77enBsmZhidTD3JSt3VpLUva2mjjI45jU02TMHcj0X7yP2W2Mo
         bol3evaupLe3lhBtPEgt/wkCv70TgpXWg9UDBfSOibCxLfa/rrgMdyUbtxjyNwXwfYv2
         ZwgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786520397; x=1787125197;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=7kvlaIyT3C4mq2SKhDRTcCFghu+creUAQezA8qqNSTM=;
        b=FiU6n9axb0RPx8yPX15M3npcBzVnxmR1jC0AxWckegLOoolcpAbqFemsb5BKsL7N9l
         iSclfhCQngkW+cNa0LoHElrFQNJ0yYHnjaTusjlGsaeRyK7AmC3FQ/unlKrvhCLLt5pQ
         Fw073+AyYWT4snGI3tZmT7ZUAl5Mmcl1pfRiUxcqPuzOPyDAxlkbKWtGaDB4gSIgL/8J
         bpQL4OSqnZqXhvfguQiKMQ0bcdC8hp0rSQYPKnHeh9lrvfv+AZzcSWexL36nRYSBiJ8P
         fOnPDtxPbfTc2AafipWFn83uKX77J8HHvQJTPPbW+pvXt6HGgZId0+vPY8JaQxrBUh9A
         bIKg==
X-Forwarded-Encrypted: i=1; AHgh+Rqz2/RJVa6HrNqDhHsjyIvacO7VQMWEULBK4ekj1ugrAe3GO2lymRc05lyQ17F+esABeEVHUXFltLw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxukcEAzqXkD3t41EqI4+clTaSPETrUzM2Og8hPYqZdSWhHifTg
	tjQQA8+MXCqoMdaoMI70GbEQcc0HUUvsedAmoXTt8DMWLO5mFEoLp10fNnU3dkH27Q==
X-Gm-Gg: AR+sD12rZfeKM2fcwm48GYQaqA1RqMirQIUFTvpsqUJHMyO6qyKWZlySIdk1pTL9LnL
	P335M7AP9JsZpyV5mu+Zwy2CYXukzKwLFM2t6N5+HoILYKjRIxQVqupRpryk7wo13tMlVyKc8fB
	BqO/b0Iz7BLC1RV+OwgINWRbDEABm0TvrPTGaObpbtsqhsSfL3XRFDmEmB7AJbuxg9fPr/zXHUg
	zPrhZ1igjlmquiYwXNGspL1aEA+y/5AlIve+wREJBrwa9iDO+SRHCEZLMtdMX5id7iVSbVS0HNi
	HWlkNcksA9kzPdwjM/yHRCg0/jfS+6PRiNrVymVnY2N+fekSrk02vXnY6MKuSHpt3l4ja0TOAfc
	2egAqAWdbplY4Tfq8QRQ00qSZjy+JWdlAOCrWhKG5icDcBBmF+aqbbijWH21ljUabXYJlG3vsi3
	3c5VH4Yd1zEmlyoOEhLG/Hxlll9qv/4Bc90nGHZNH8wIp4e7FZAmaWt8ifnXKQs1LaKDSIxrzJE
	g3r/Ah9nkLsoGKNnpDmbLry8HEuH1pkNJu0FQJSuLriY9BxytIx
X-Received: by 2002:a5d:5986:0:b0:47f:f4b9:88b7 with SMTP id ffacd0b85a97d-48152c3f68amr3570335f8f.1.1786520396920;
        Wed, 12 Aug 2026 00:39:56 -0700 (PDT)
Message-ID: <68b346b5-e4fe-455c-9f7f-f4c9d2b3ed73@suse.com>
Date: Wed, 12 Aug 2026 09:39:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] xen/arm: handle irq_set_type() failures
To: Mykola Kvach <mykola_kvach@epam.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Jens Wiklander <jenswi@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1786385827.git.mykola_kvach@epam.com>
 <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786520397-4BED2CFC-266AAA42/0/0
X-purgate-type: clean
X-purgate-size: 963

On 10.08.2026 20:38, Mykola Kvach wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data)
>      struct acpi_table_header *table;
>      struct acpi_table_spcr *spcr;
>      acpi_status status;
> +    int rc;
>      /*
>       * Same as the DT part.
>       * Only support one UART on ARM which happen to be ns16550_com[0].
> @@ -1976,7 +1977,9 @@ static int __init ns16550_acpi_uart_init(const void *data)
>      uart->reg_width = spcr->serial_port.access_width;
>  
>      /* The trigger/polarity information is not available in spcr. */
> -    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> +    rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> +    if ( rc )
> +        return rc;

Is erroring out still appropriate when part of ns16550_com[] was already
modified? I.e. doesn't the call need to move up then?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:41:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:41:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388794.1629777 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3b3-0007eT-QK; Wed, 12 Aug 2026 07:41:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388794.1629777; Wed, 12 Aug 2026 07:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3b3-0007eM-MG; Wed, 12 Aug 2026 07:41:57 +0000
Received: by outflank-mailman (input) for mailman id 1388794;
 Wed, 12 Aug 2026 07:41:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu3b2-0007eB-MR
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:41:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3b2-002NrJ-2X
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:41:56 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c23bf-2eae-0a2a0a5409dd-0a2a4507cc34-20
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:41:56 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c23c3-b4ea-0a2a45070019-d1558032bc11-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:41:55 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so4707415e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:41:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997b33e038sm27710045e9.4.2026.08.12.00.41.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:41:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786520515; x=1787125315; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=3UBX0ogQdkSoMnSPy/v+GaVoz34I1SPSZX5Aqejg1Bw=;
        b=FhxKcMnkcXWCEvApssjt6rJIJfezYbrP5fqFT5NAw+2v/UgB9yVvs5Y3IpngfUH6qp
         MbDkgJQQVIF3/LmOxy7mxOIeEZs4qi8R30++AwXgFM5FdiTc/AHV2M9kmV3zHgqRg2Dy
         ay6Isr9shVZJhNEWIn7LNCO9EHg42sElVUynX7ekkv0tl8jP2Wr58hmnDSo52v28n+Q5
         bdyccVRvMx1LgfMl1KOzyzhza+roxR7oR3GtGK4dT0SahDz4BQLkjh/ljqEBqsYRYtll
         6masjiEtb72MKpyqyH5Tn5ruGKdj99dgomcSTORMy9YzlGopPAc97Zlc7q3QquxFpUvA
         9ULA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786520515; x=1787125315;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=3UBX0ogQdkSoMnSPy/v+GaVoz34I1SPSZX5Aqejg1Bw=;
        b=Xxzj8P1b6jXqlfzaVf+RWQMTcGraE1IAjyhkh+ExtpGIu+qMUbmKERj6CGXHCOqZFa
         80u02EpbFL0nB0/wugMPuwZFpWb353i2/Nv9RGtKAunHQJx5q6cB0O4FeNCpQN1vVVME
         p5K9ANFaOJQxP5V7Ea6YyPWbKQsNX0gtAtA9N3tySbKZQZIqiLOZkVmsUqTxqpicxJ9S
         6W5G09HNv9fGaXoCbhHSv9hssZDoRSxP4N2SPLguviSvavA0B1XHrd9fVJKhTH9QPQtO
         I2GEWsVejj/k/gEbmmFLsm8oBuXpVpPI1hLALdUxuY6YLdGvRhVe0YU97a79y+B5NRyh
         s2dQ==
X-Forwarded-Encrypted: i=1; AHgh+RqGcZZu1b0gpSBBzPmyhd7FV0qIkwpgbyESW79GWEvJ9u3qyoOlcnGMyWnLptppZuLclOUfR8BDv2w=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw5Cq65qxAQUqpDBrjzqfmoP8nDvjkyE4VCN5xTcyu/iopywdDb
	87ttp7O5LDSdW98EHTxjEYWkIj2mtaYXdnj/m8Svi0EU2qlgpZLxoeuW184KuJzauw==
X-Gm-Gg: AR+sD10DemBbfd5Mx5L/o4UfNs15hNCi+setKFmP0v5CPdiaBwIsFPnUP6Mu2kvI2BG
	uP7elR8YdP1PDyc+60EOlxQR9EOR9opqWMiiG8LoAY1KHrv0W/lH2sVab3DBicUL51JisRA07yG
	9rh2KhCkls+4kAf3qSO8oi7kRLQSTttKI7xjDKADzXX1H/+FOsobBAPXpzul+cTVj14LpwqA5T+
	WCnrFeo1aCeZ6m9SyBf7tZgAKsLBgjSQaYAPfi3jTg/9jfftF8wAbULVx9YEdEYyeMY0Mw17vbG
	WR+4lSr+McwhtXDE8288e66X89+hi48C2ZVMTMq0kz+IVvYoollHp5apBy9I6IK23uZymTykzpV
	SfS4V+NJTq8sDkju5FFNenzM2TUsDJ8XW0Niff3eOldMqn1VrIyROPDy+m4MjKfMnhyLtUr3ogc
	ShlBpcexI40A6w4ZYwOoDjq+3H/Jfnlcqv9vVX2UEKFeGfzAkbsRbfelk/DfPfPOILajz4NcV0P
	my1panyY59cEf64YQwkojU2wSdVg4hPEdB4PuIk3pKbjIWIKo4l
X-Received: by 2002:a05:600c:4e90:b0:495:6a50:3fb8 with SMTP id 5b1f17b1804b1-4997c0e3721mr28543855e9.1.1786520515072;
        Wed, 12 Aug 2026 00:41:55 -0700 (PDT)
Message-ID: <0189f567-7dbc-4450-b247-371b8de0c874@suse.com>
Date: Wed, 12 Aug 2026 09:41:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/domctl: Fix unitialized copyback in
 XEN_DOMCTL_PSR_GET_*
To: =?UTF-8?Q?Johann_H=C3=B6pfner?= <hoepf@cit.tum.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <anWrDspbnvRYCwGZ@cit.tum.de>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <anWrDspbnvRYCwGZ@cit.tum.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786520515-A58C1AE4-A11205F8/0/0
X-purgate-type: clean
X-purgate-size: 632

On 10.08.2026 00:38, Johann Höpfner wrote:
> domctl_psr_get_val() copies unitialized stack space back if psr_get_val
> fails. Fix by zero-initializing v_.
> 
> Fixes: 03f30dc193c8 ("x86: refactor psr: L3 CAT: implement get value flow.")
> Signed-off-by: Johann Höpfner <hoepf@cit.tum.de>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> Consider instead removing the local variable indirection introduced by
> 03f30dc193c8 and passing &(domctl)->u.psr_alloc.data to psr_get_val
> instead or only conditionally setting copyback true.

Well - the way you've done it is clearly easiest / most obviously correct.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:44:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:44:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388804.1629784 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3dS-0008E8-6i; Wed, 12 Aug 2026 07:44:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388804.1629784; Wed, 12 Aug 2026 07:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3dS-0008E1-47; Wed, 12 Aug 2026 07:44:26 +0000
Received: by outflank-mailman (input) for mailman id 1388804;
 Wed, 12 Aug 2026 07:44:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wu3dR-0008Dv-Et
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:44:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3dQ-00DL5A-R6
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:44:24 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c2451-bab6-0a2a0a5309dd-0a2a45078eee-18
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:44:24 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c2458-b4ea-0a2a45070019-d155802aecba-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:44:24 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-4954dff6536so4883135e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:44:24 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150d709dfsm5027638f8f.35.2026.08.12.00.44.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:44:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786520664; x=1787125464; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Lm/f+ccEM3XgjBsvgUdE+M8tHbe5ngMBnR2I6CsCIeE=;
        b=UUS7FTk34DPzwwyVqiLPDNoWNsaYDfudSb7kx7ZcxzbKCDzpq7W8I7r8oBKkFXvaEv
         8MWY6v0QtAEGkhXmiVuLrdAWCPEKmYXGHITAQFZfYJ/2ckdoU77mL2iXEqzgQRdf/Vo9
         /fP9+Q2kzFzxFYbBLMSfbhdld0mVuke/Qgo7Ojasy6f325sqWmsAUXt0DgzSsH+tZcDP
         k3yBUYJoWlVH/mGSZW+2fWTxeK8LSyckbqDHiwMQkDr41pj0Y6xSr7E3e+cV1pLL3m/X
         V/SjuCFdS57rN8IlCxmT9RPJBQWdH325WBK0xXpqzUC20fU6vHS4GqAZSKs8DBJm0orv
         Jm+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786520664; x=1787125464;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Lm/f+ccEM3XgjBsvgUdE+M8tHbe5ngMBnR2I6CsCIeE=;
        b=PbBCmw6iCQHwE9S6QcU3MMh8FqZfuqMegT/6aWeXiE+gHTtEImqYkBi8dvVdOmUK4U
         VqgdW3vuNRxqIAQ35dbntwJL+fcVSEUoBACc1HBUAPyRudNO3I1/Qcs5puiPcKyzdsm1
         rR8RFZwkIHdChS6hAcpyALcC65gJCvEJcJxalV4HTqica7+eaHUGVy9wy6rsmvnJOda0
         L2oZ5dFCYuFkArz6lUuNk8Vk2FKRCzh3WgGpbW0kOTiWWkyS5ixvzznah15KP13jkMCq
         HGebTO19V2NdUduyvknrvWcH7y6b6Ip2bWXMQJzTj8zW5XYSoPVEcKQ3BNaOguuIEGYR
         ZBiw==
X-Forwarded-Encrypted: i=1; AHgh+Rorcx/iZU7fwh5xVJ5STeU2be1rMN/a5l1HKhRTuMrOw/3BhqQxsHfXArFI51LM0q26rrMN/3fDbfY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzuuyiTt0So8xwvGY0Mh2bdVQ6mx6uwrmJDEB+NiNOUm+T2DBIH
	GlpsudsnDJeeTMFP+ci6PAHisNjaHuiIgX12T1QUBRFIsXOdPF3NjASH
X-Gm-Gg: AR+sD122HTIm3iaCYCaNxuJnT6VqqZwFZrRlxx3kgixkDRxysciDv01Lp2RtN5CX2G5
	+6iRWTCVrHQNFjIzROT5RE0ysKK4sVMh+QbAtZzSRTc3lctBu6ybQpXGt6+LkmpuzDwaanFp3GD
	JTRwCDJMjvSfV+hrpihU7sKFTW1Wj5e4AzW1OMVknmfYHXY1jkMu3Loy1giADi91ECAxxpbfvJT
	NoIjDdZm54glAKHL0RAMrLk0n5wCJiXAWU8/7ZxU2refqoEro7usOJfNhmXWtKrrItdfDj3qVu6
	rZ2HKWzeKZiLjzSHpxmHSZ9Nv1MFqPiNWhE14cqx0fpy9+eyfuOogVUPyiSpADkuuq2v+KlnB2f
	GdQeNTorMt5u6TZ8g03taaLYhZO6V/QBIVIK2xYX9HqRBHD4b3iZk5hjTo7bNh5xl2OBY0TJkOT
	PXfSWu62dtKY2j+HqNqrlovmsdFgA7UyLc56kVzsD0x/y5A5YOs3tKhhCZjHrU6hR5ycQwPvO0L
	5DOrRT/0rlRhnavrSFf0dBQxDygqbAdgHjSyR4A2OE=
X-Received: by 2002:a05:6000:2405:b0:480:d9:ee6d with SMTP id ffacd0b85a97d-48152c62f17mr3427743f8f.19.1786520663929;
        Wed, 12 Aug 2026 00:44:23 -0700 (PDT)
Message-ID: <befa85b4-818d-44f9-af43-0c14f0549154@gmail.com>
Date: Wed, 12 Aug 2026 09:44:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] xen/common: add keyhandler to show Xen command line
To: dmukhin@ford.com, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
 julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
 sstabellini@kernel.org
References: <20260811210956.3806559-2-dmukhin@ford.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20260811210956.3806559-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786520664-36EDEAE4-47C38C69/10/73395122804
X-purgate-type: spam
X-purgate-size: 2705



On 8/11/26 11:09 PM, dmukhin@ford.com wrote:
> Currently there's no way to print Xen command line on the emergency
> console for debugging purposes when 'xl' is not unavailable.

It looks like 'not' should be dropped. 'unavailable' covers 'not' itself.

> 
> Add new keyhander 'X' to do command line printout.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - print built-in command line too
> - change handler to print command line only
> 
> Changes since v2:
> - account for CONFIG_CMDLINE_OVERRIDE case
> 
> v3: https://lore.kernel.org/xen-devel/20260810230359.671587-3-dmukhin@ford.com/
> CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2751523722
> ---
>   xen/common/kernel.c | 32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
> 
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index d1bef9ac2b2b..8a43e4421002 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -5,6 +5,7 @@
>    */
>   
>   #include <xen/init.h>
> +#include <xen/keyhandler.h>
>   #include <xen/lib.h>
>   #include <xen/errno.h>
>   #include <xen/param.h>
> @@ -505,6 +506,37 @@ static int __init cf_check param_init(void)
>   __initcall(param_init);
>   #endif
>   
> +static void cf_check show_cmdline(unsigned char key)
> +{
> +    const char *builtin_cmdline = CONFIG_CMDLINE;
> +    const char *cmdline;
> +
> +    printk("'%c' pressed -> showing hypervisor command line\n", key);
> +
> +    if ( builtin_cmdline[0] )
> +        cmdline = builtin_cmdline;
> +    else
> +        cmdline = "<NULL>";
> +
> +    printk("Built-in command line: %s\n", cmdline);
> +
> +    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
> +        cmdline = "<NULL> (CONFIG_CMDLINE_OVERRIDE=y)";

Won't be better to use <ignored> instead of <NULL>? Also it reflects the 
comment (But if CONFIG_CMDLINE_OVERRIDE is set to y, @cmdline will be 
ignored.) above cmdline_parse() function better.

> +    else
> +        cmdline = saved_cmdline;

IIUC, saved_cmdline could be empty and I think we should take that into 
account too:

     if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
         cmdline = "<ignored> (CONFIG_CMDLINE_OVERRIDE=y)";
     else if ( saved_cmdline[0] )
         cmdline = saved_cmdline;
     else
         cmdline = "<NULL>";

> +
> +    printk("Command line: %s\n", cmdline);
> +}
> +
> +static int __init cf_check misc_init(void)
> +{
> +    register_keyhandler('X', show_cmdline,
> +                        "show hypervisor command line", 0);

Last argument is declared as bool so I think it will be better to use 
false here.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 07:47:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 07:47:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388812.1629793 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3g6-0000JW-Ii; Wed, 12 Aug 2026 07:47:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388812.1629793; Wed, 12 Aug 2026 07:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3g6-0000JP-Fg; Wed, 12 Aug 2026 07:47:10 +0000
Received: by outflank-mailman (input) for mailman id 1388812;
 Wed, 12 Aug 2026 07:47:09 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wu3g5-0000JJ-J4
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 07:47:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3g4-002OsC-Uo
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:47:08 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c24f6-8faa-0a2a0a5109dd-0a2a450bb4b6-8
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:47:08 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c24fc-b7e8-0a2a450b0019-d1558033bdcf-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:47:08 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-49556f97a9dso3373455e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 00:47:08 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150bf412dsm5571774f8f.6.2026.08.12.00.47.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 00:47:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786520828; x=1787125628; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=omH6Psqa+nZQ3VqvSc7ewDfYwdMATazl10IXo7nn/VA=;
        b=R0r8UwY1px3FzhceeJIsbyYQJTRZjNDk2usm34Xr0GV4kyTEYJmRc6+SSvJjlnjmfb
         TZjVTEksgNmUKvfsuk4hVqXW4FWrF2M5Kv9iRUcdM8jo/J6axDTC15qZFsdH4hsXZoMk
         IkOagCJOdMlsakP70l1xJQSJPQmhbnB6LbTNoqXY7o4Vf+Y9fkYGL1+kWO0TYlRYmnLq
         rg3SV5CsGUQ0zcOkf/o/eVmu9TPleTp7xeUgt2sBDwLL0Ni6g+jb/QegX0z5yAsLD7lm
         5GnRqaijXy+kuysvWjFrfK/ugrhCfgCwtxsoD/EGxmGnqOoMiWIDCVq0U15923yzHR2U
         8MoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786520828; x=1787125628;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=omH6Psqa+nZQ3VqvSc7ewDfYwdMATazl10IXo7nn/VA=;
        b=LkdNDwO+HHxIYgmi9AGn2ozMvSGoCvs7cxiXTt89X9CJnlaSlGiMvkOTg8bfYPPuN+
         9R7YQI8rtY3uekp6Jw3fzAteNJt+Xw0lhth8ddMrl116j1h2AUIfH6sfUAAsYKoDbUst
         829KQJ7+sc1QTRUww0eMcbVaY0QW8bogasUd5ivrYw1cJy06ZG5fx+YGG6pIAwVT+Nt3
         +KuEv0K0Y8M/bd2eru73ZbPhX1+8jHTk3lSMc7izwk8biVyoXZtvdiFfO6RBxTlawsxj
         ucGX99IECswzlFOGliRj9dNRPpoWLKbb2FVZ0dG5sXD0lZu8DY+//p7jlfkjXctFc6t5
         UT8A==
X-Gm-Message-State: AOJu0Yzk0SrIIEeHRtAt7e0EPnMNYqepry/wSjN0vFUnMpdSDqWVUVTy
	/mMzCl//5V6QS5tGSiegiyD22gCTJgYJuVS8Ie+Hi7uu/0iH2H/laC8N
X-Gm-Gg: AR+sD11tOwye6t1JriRM5pCtMuBoMoEB1JQ3rDjA7CJfkWGBFGqoZZU/HDDcOcpFR8i
	vJR9S5EvRA1/hczJFz4vm/V7hArZxBxOq9OBI+cq+uUA2O1Sc3/CfJbvd2t3SM2oA6D4oLbDHhp
	+MgwCf2fopqhfRwU1xBrDJb6xAZigLssTGFWxtQl/C5yTHyW/NK+xz35NHSWEV9zsyPQLp7hWIQ
	QQn9aLlzfhVw+ohrwHouzoGjMtvjhn5HaoCyriOftWgUbPrrh6hmHCqD5uNMqC4RnDZk2nOYsDD
	q82/f68gPpVBSlI+XHj/+XQuLCyvs+6QyGgth5RFN/ixNPg8L9ICEXgdVQJQSo532CRQJjxyaKn
	59KUEfCLXG9A/FvMpUYzKrbpwis7sS3udUooio+Z7eRMvhk+TNbi/zEQp5qou/gR0OizISWP2go
	5MNUTuNJiGJxvpVvPK8kqVcacSTS6csiIxUV9WOkdvDai5uUBGfa0kOzqs7RPwRUArtw6Kk355D
	FkmuueOaQPVscYrILcwwq5R5ehBC3hSZH7GuNbBRKI=
X-Received: by 2002:a05:600c:3b11:b0:495:4b42:8677 with SMTP id 5b1f17b1804b1-4997c1721c2mr34926165e9.18.1786520828427;
        Wed, 12 Aug 2026 00:47:08 -0700 (PDT)
Message-ID: <dc0fc4dc-0e03-48be-b186-27139708cba8@gmail.com>
Date: Wed, 12 Aug 2026 09:47:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 04/17] xen/riscv: introduce device-agnostic MMIO
 emulation dispatch
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c12b69710d7b79bfc0c110f3fa043d871d8b8394.1784560663.git.oleksii.kurochko@gmail.com>
 <1786373377.8631fc262581453bbf619ec5b2062170.19fec268e07000e099@vates.tech>
 <05283ea0-de82-4160-a3f9-5fc1292a20a5@gmail.com>
 <1786436246.8631fc262581453bbf619ec5b2062170.19fefe5dbbc000c4f3@vates.tech>
 <a58af12e-13f0-48a3-b39d-bff92991ccd1@gmail.com>
 <b7754a86-4602-4b41-a07e-3e6389dac78d@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <b7754a86-4602-4b41-a07e-3e6389dac78d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786520828-A88C99EA-9520F32F/10/73395122804
X-purgate-type: spam
X-purgate-size: 973



On 8/12/26 9:21 AM, Jan Beulich wrote:
> On 11.08.2026 13:49, Oleksii Kurochko wrote:
>> On 8/11/26 10:17 AM, Baptiste Le Duc wrote:
>>> On 2026-08-10 17:36:56+02:00, Oleksii Kurochko wrote:
>>>> On 8/10/26 4:49 PM, Baptiste Le Duc wrote:
>>>>>> +/*
>>>>> Why have you included a copyright notice here, but not in the other
>>>>> files?
>>>>
>>>> So I just decided to do that for new files as I am not using corporate
>>>> e-mail.
>>> But why didn't you do it for all new files of this series?
>> If there are such cases then I just missed to add it. I will double
>> check during preparation of v2.
> 
> Hmm, I'm a little irritated by "missed to add". In past discussions (plural)
> the usefulness of such copyright notices in comments was put under question.
> They go stale anyway as code moves around. And likely there were other
> aspects that I forgot.

Then lets follow a strategy not to add such copyright notices in comments.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:03:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:03:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388830.1629803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3wF-0004Bd-4i; Wed, 12 Aug 2026 08:03:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388830.1629803; Wed, 12 Aug 2026 08:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3wF-0004BW-1z; Wed, 12 Aug 2026 08:03:51 +0000
Received: by outflank-mailman (input) for mailman id 1388830;
 Wed, 12 Aug 2026 08:03:49 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wu3wD-0004BQ-N3
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:03:49 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wu3wB-000N4t-2f;
 Wed, 12 Aug 2026 08:03:47 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wu3wB-009qz4-0m;
 Wed, 12 Aug 2026 08:03:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=9jlzanOekz2XXAaJ5zcmQ7sOSxIgj5uoNV+7cGh7kj0=; b=jQ43aNnRbjWUw1cVfyusxAd/Vu
	9uijm1P2Hx/Nd/8F7viornmfoyjX7IAcSthaIrPLOmjBJzIbcUqwD3EHxWbQ1B6H++u5aILpFuJCG
	Xpu6Xf9DtWbR6O4zZucR8QNcJbIFYP7bv0kYPMJNyC0i8X+hsranlzBBiLQ7gxlod7eQ=;
Date: Wed, 12 Aug 2026 10:03:37 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	andrew.cooper3@citrix.com, anthony.perard@vates.tech,
	julien@xen.org, michal.orzel@amd.com, sstabellini@kernel.org
Subject: Re: [PATCH v3] xen/common: add keyhandler to show Xen command line
Message-ID: <anwo2QtEh9tObNDD@macbook.local>
References: <20260810230359.671587-3-dmukhin@ford.com>
 <anrXvTfBls4flBqK@macbook.local>
 <anuMfq/lDjxbR8Om@kraken>
 <ba78a8a1-6862-41b0-a6a5-cae7eada3627@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ba78a8a1-6862-41b0-a6a5-cae7eada3627@suse.com>

On Wed, Aug 12, 2026 at 09:28:46AM +0200, Jan Beulich wrote:
> On 11.08.2026 22:56, dmukhin@ford.com wrote:
> > On Tue, Aug 11, 2026 at 10:05:17AM +0200, Roger Pau Monné wrote:
> >> On Mon, Aug 10, 2026 at 04:04:01PM -0700, dmukhin@ford.com wrote:
> >>> +static int __init cf_check misc_init(void)
> >>> +{
> >>> +    register_keyhandler('X', show_hypervisor_info,
> >>> +                        "show hypervisor information", 0);
> >>
> >> "show hypervisor information" seems too generic to me, almost all
> >> debug keys could be defined by this sentence TBH.  I think this needs
> >> to be more specific, but I'm not sure what's the plan regarding this
> >> key.  Is there an intention to print more stuff here, or just the
> >> command line?  Knowing the full set of information to be printed might
> >> help come up with a better name.
> > 
> > I will update to "show_cmdline" since I originally planed to expose Xen
> > command line only so it is possible to better debug a system when dom0
> > becomes almost unresponsive.
> 
> Yet as indicated already on v1 (I think) - a precious debug key character
> for just the command line seems rather wasteful to me. If it's only the
> command line, and if that _really_ needs exposing via a debug key (i.e.
> if there are reasonable scenarios where "xl info" cannot be used), perhaps
> attach it to e.g. the 'h' key output?

I was going to say that we should not overload the 'h' key with
printing a possibly long string, but I see we already print a bunch of
information there, like the buildid and the compiler banner.

One option would be to introduce a new debug character, and move the
printing of the buildid and the banner to that key, together with the
command line.  Then 'h' output will be cleaner and just print the list
of installed handlers.  That would give the new key more content, and
help cleanup the output from the 'h' debug key at the same time.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:04:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:04:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388836.1629812 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3wt-0004cP-Ch; Wed, 12 Aug 2026 08:04:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388836.1629812; Wed, 12 Aug 2026 08:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3wt-0004cI-9X; Wed, 12 Aug 2026 08:04:31 +0000
Received: by outflank-mailman (input) for mailman id 1388836;
 Wed, 12 Aug 2026 08:04:30 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu3ws-0004cA-6n
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:04:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu3wr-006Dex-J5
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:04:29 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c290a-8faa-0a2a0a5109dd-0a2a450884b0-6
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:04:29 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c290d-f659-0a2a45080019-d1558031d0d8-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:04:29 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-495757ccbc1so5820405e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:04:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c98d264sm30733075e9.9.2026.08.12.01.04.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 01:04:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786521869; x=1787126669; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=lPtJR6IQBglLJG1DyZZy4itPX0zMDvXgO3Z2Zp4xWcQ=;
        b=GKQ3FB/5bE5o+mPgIrfjT+BMBkUAYbN+7xiOAlFdQiXcWuLR/FOxv9Ep8RL5STAAFt
         U2G8yIuWz+u2FlqyKqH+xrdM9zWP35v/5YRKdfgDhGXGjcoPu5HDFBIeUnV/TMBsK/qW
         Fiv+fi8lE6tNDMYOwNNoPv+k8TSrYnXjb145qscMX8Vtg2NVi86i/XzT3kNbg+eTEmiE
         7hWHeLm/+UOwMaWPelUFLbZGPdxd+Ij9e7z9Gl8PZF7mpdCx9SZVF+H2gE1lNWQr9dKT
         H7rQjw73GgsAv1kveWQwMuZSpBC9iE+IEZfOo8Cu/0Hs7rR4BK1xYbxiTXmx1E/JXVmp
         uxmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786521869; x=1787126669;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=lPtJR6IQBglLJG1DyZZy4itPX0zMDvXgO3Z2Zp4xWcQ=;
        b=Ij0kyztTtMS1YLsmtZ3jlaicJIgveCkf8IqgLWjdnLgZbGexsACpanx+FgEy0ylESC
         NN+h7jufmQBXtzWDSN9QEfeAngsP+QpSuNJPKNxOfEsj3eqFKUBnEClPHoq4IUhWMYXl
         a5kQ5tXMNmBqPjshostKJWM8Rgl/0ZYOy7HeZySjtiqxGTQhw6LGvLt9ajKr6gA/ZR8p
         2Z5zp3kSJjFSriZY491muEveDMItXynrEiyCtzBQi7JgXPMmPdaznCEJoW78k278OsRn
         FT5gnZDTJZEvvsDMy68SyLZCf5PzvxBo9j42iZF7yVqcAocy1GC7ImOdCXVRq2ntrHsG
         B0+Q==
X-Gm-Message-State: AOJu0YzYn3RGK303NCuLDn/QKhga4XOO+SJ8ctydBcuFZf2pRYYw6Kqn
	ccKDm+748rWw7PXcloyn191Bwu2FuNopZ47isCdmluiYfj7kUFXfm9LWDYXG5F65vhSqt9tJ0DF
	WmQsUHw==
X-Gm-Gg: AR+sD13yZ6VVgHBLs/hAAkVOZQsJBmTVHqhgXn8SuTJ1+q0GTRg4NfJRXzdDUvp0o/s
	tQpsjarPUsvTRgXO8lCEp4hA5KZewTfLcOaRsAvLa1D/+srfftApkGQP2ahZp25D9aw3Op43h0Y
	ey5R92HBWdpyafWO0woPTuje2GSUcbfgMnT+hdUg5F+BdJL8R6UBoFltp6TnXzdJlKGC5z33m+p
	bz2jJOBf0P2PjcwBuO4tLeZZW3QaaYlksCcAWRsMctA2XglBvyXAY89yGZZtobRwOIZeIj4EiO6
	WHzqZyaQimb68Fr3SaBxHra7ieed7qjt9zLmdE/hJov63flJfTMAiCqw4+j9zuGQPnhQrv5BiYs
	c4Zm35QON37f4mphMnUWmo4cP0u6mp5vzPSmPfs8X7fE3ui5mmzxItBw0VJiEq3lDRv1gBpIuW8
	Ta3CrcxWiL0gdipPNrIsyn6iohNTHbPko9QxRu3nl3x3BC1cQEXdrl73bvy64pj7ycAE7QTJRR7
	BKzQI/6+diSmciEOh5CkV8guy7SDRieZsWDp2bWi3aiyPw6qrCLWgWH0A==
X-Received: by 2002:a05:600c:c042:b0:495:4689:1e98 with SMTP id 5b1f17b1804b1-4997c138c3emr23902985e9.10.1786521868894;
        Wed, 12 Aug 2026 01:04:28 -0700 (PDT)
Message-ID: <f80bf49e-4ddf-47f5-a7c4-d4d552c811cb@suse.com>
Date: Wed, 12 Aug 2026 10:04:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 3/7] xen/console: switch conring runtime allocation to
 xvmalloc
To: Stefano Stabellini <sstabellini@kernel.org>, dmukhin@ford.com,
 andrew.cooper3@citrix.com
Cc: xen-devel@lists.xenproject.org, anthony.perard@vates.tech,
 julien@xen.org, michal.orzel@amd.com, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <20260728065049.1318143-1-dmukhin@ford.com>
 <20260728065049.1318143-4-dmukhin@ford.com>
 <59a85064-35d9-c3f5-c056-6c05677fc27a@kernel.org>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <59a85064-35d9-c3f5-c056-6c05677fc27a@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1786521869-D674387B-FF82CFE1/0/0
X-purgate-type: clean
X-purgate-size: 2486

On 10.08.2026 22:19, Stefano Stabellini wrote:
> On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -33,6 +33,7 @@
>>  #include <asm/setup.h>
>>  #include <xen/sections.h>
>>  #include <xen/consoled.h>
>> +#include <xen/xvmalloc.h>
>>  
>>  #ifdef CONFIG_X86
>>  #include <asm/guest.h>
>> @@ -464,20 +465,30 @@ void __init console_init_ring(void)
>>  {
>>      char *ring;
>>      unsigned int done, size, n;
>> -    unsigned int order, memflags;
>>      unsigned long flags;
>>  
>>      if ( !opt_conring_size )
>>          return;
>>  
>> -    order = get_order_from_bytes(max(opt_conring_size, conring_size));
>> -    memflags = MEMF_bits(crashinfo_maxaddr_bits);
> 
> The original code had MEMF_bits(crashinfo_maxaddr_bits).
> crashinfo_maxaddr_bits is 64-bit by default but can be changed via
> command line options. Now, the memflags is going away and there is no
> way to bring it back because xvmalloc_array doesn't take memflags as a
> parameter.
> 
> Andrew, Jan, is that OK?

I don't think it is. While the description of 3355c1a2a60c ("KEXEC: Allocate
crash structures in low memory") only mentions 32-bit, the same split can
occur on 64-bit. The one thing I'm not sure about is why / when dumping
would be limited to parts of memory only (both for the original 32-bit case
and for today's 64-bit only situation) - Andrew?

>> -    while ( (ring = alloc_xenheap_pages(order, memflags)) == NULL )
>> +    if ( opt_conring_size < GB(2) )
>>      {
>> -        BUG_ON(order == 0);
>> -        order--;
>> +        unsigned int order = get_order_from_bytes(max(opt_conring_size,
>> +                                                      conring_size));
>> +
>> +        opt_conring_size = PAGE_SIZE << order;
>> +    }
>> +    else
>> +    {
>> +        printk(XENLOG_WARNING
>> +               "Limiting user-configured console ring size to 2 GiB\n");
>> +        opt_conring_size = GB(2);
>> +    }
>> +
>> +    while ( (ring = xvmalloc_array(char, opt_conring_size)) == NULL )
> 
> It looks like that if opt_conring_size is zero, then xvmalloc_array
> would return ZERO_BLOCK_PTR which is != NULL. We need to have a
> different check here for that condition

But opt_conring_size can't be 0 when making it here, can it? (See the
check early in the function, even visible in context above, plus the
use of max() in the hunk here.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:06:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:06:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388846.1629820 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3yt-0005Ib-NF; Wed, 12 Aug 2026 08:06:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388846.1629820; Wed, 12 Aug 2026 08:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu3yt-0005IU-KV; Wed, 12 Aug 2026 08:06:35 +0000
Received: by outflank-mailman (input) for mailman id 1388846;
 Wed, 12 Aug 2026 08:06:34 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wu3ys-0005IM-9D
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:06:34 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wu3yr-000N71-10;
 Wed, 12 Aug 2026 08:06:33 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wu3yq-00A0y3-2Q;
 Wed, 12 Aug 2026 08:06:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=DNvJgBKv9EcweeG33ndh1gRI6R16bFALRr2RtFjgWPg=; b=FaHNakU0lPRthmb/pyqwxhnCKC
	WCOxssShXRrqhqCjcNGLCTLLnuT/PfrADqgV86vDg4a9poGydzaHe6m1sedSxyTyFzMRFy9HxE7OH
	bQ+/PT72Z4hIFUk60MWzy0jJW2uKvlTIIWQTUX6BvSgFzrPSD3ZM2bC5dkobiUxJsQPQ=;
Date: Wed, 12 Aug 2026 10:06:23 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/2] x86/pci: prevent cross-device accesses in
 pci_mmcfg_{read,write}()
Message-ID: <anwpfyZ4PIbd5m4S@macbook.local>
References: <20260806152619.23881-1-roger@xenproject.org>
 <20260806152619.23881-2-roger@xenproject.org>
 <c818745e-6f61-4b32-b7f5-ee5b7ff82981@suse.com>
 <anWQ15K8vi3t1sgF@macbook.local>
 <a711a0d1-dbf0-44fb-a419-38abc62480ad@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a711a0d1-dbf0-44fb-a419-38abc62480ad@suse.com>

On Wed, Aug 12, 2026 at 08:28:50AM +0200, Jan Beulich wrote:
> On 07.08.2026 10:01, Roger Pau Monné wrote:
> > On Fri, Aug 07, 2026 at 08:22:44AM +0200, Jan Beulich wrote:
> >> On 06.08.2026 17:26, Roger Pau Monne wrote:
> >>> Introduce a specific check that prevents an accesses from spilling across
> >>> two devices.
> >>>
> >>> Signed-off-by: Roger Pau Monné <roger@xenproject.org>
> >>
> >> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> >> albeit with a remark:
> >>
> >>> --- a/xen/arch/x86/x86_64/mmconfig_64.c
> >>> +++ b/xen/arch/x86/x86_64/mmconfig_64.c
> >>> @@ -61,7 +61,8 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus,
> >>>      char __iomem *addr;
> >>>  
> >>>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> >>> -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) {
> >>> +    if (unlikely((bus > 255) || (devfn > 255) ||
> >>> +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE))) {
> >>>  err:        *value = -1;
> >>>          return -EINVAL;
> >>>      }
> >>> @@ -91,7 +92,8 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
> >>>      char __iomem *addr;
> >>>  
> >>>      /* Why do we have this when nobody checks it. How about a BUG()!? -AK */
> >>> -    if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095)))
> >>> +    if (unlikely((bus > 255) || (devfn > 255) ||
> >>> +                 (reg + len > PCI_CFG_SPACE_EXP_SIZE)))
> >>>          return -EINVAL;
> >>>  
> >>>      addr = pci_dev_base(seg, bus, devfn);
> >>
> >> In both cases the unlikely() uses won't have the intended effect, from all I
> >> know. They would help as used here only if the compiler managed to fold all
> >> three parts of the ||-expression into a single conditional branch, which I
> >> don't think it would end up doing.
> > 
> > I don't mind dropping the unlikely() while changing the line.  I tend
> > to leave those alone if present, even when I'm not sure they are
> > actually helpful.
> 
> I think unlikely() is actually reasonable to have here, yet it would need to
> be four of them, not just one. Unless reachable from a DomU-accessible path,
> converting to BUG_ON() (or ASSERT_UNREACHABLE()) instead would also be an
> option.

Hm, let's do that in a separate patch, I don't want to merge it with
the work here.

> >  The comment ahead of the check is also not very
> > useful IMO, but I've decided to leave it alone.
> 
> Indeed, that's an odd thing to survive over 20 years (I think).

I can also take care of the comment there.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:14:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:14:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388859.1629829 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu45z-0007C1-Gf; Wed, 12 Aug 2026 08:13:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388859.1629829; Wed, 12 Aug 2026 08:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu45z-0007Bu-E7; Wed, 12 Aug 2026 08:13:55 +0000
Received: by outflank-mailman (input) for mailman id 1388859;
 Wed, 12 Aug 2026 08:13:54 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu45y-0007Bo-CE
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:13:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu45x-002V6A-ON
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:13:53 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c2b35-2eae-0a2a0a5409dd-0a2a4508b0ba-30
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:13:53 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c2b41-f659-0a2a45080019-d155dd31b5f4-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:13:53 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47f904e80eeso456414f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:13:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150c06b73sm5322608f8f.12.2026.08.12.01.13.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 01:13:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786522433; x=1787127233; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=EhdCkrcPLSxPPiE98EEmkvnOle3t6t516dhdKOJp0mI=;
        b=HPRlkU/MtGil5YOwVQkqrknDM1oY4+jQCCu9cYD7rzfpxHZmCPABuzXhpcwwN9boP3
         CldMUR6EhqPlc8+UXsK7FMQXlTSV3XgNjs6kdxG1NVFE5XfYCoLcWpwr1cVKvb6WIgrg
         r9bnbkNG6sryhqq2iWYKpUYT/VVyt7xX9n6K2HtpeN9B4Zl03K8cE4SwZggF4bLFbwdk
         YeiQrsZtp8YLcFUMVAZFnSaEEmGPzNtWPc7s8GAIxRhDrY1D7qzy+VNOflL9wzLSRMIC
         ZfYUee4lzXAkrdht+qa30SCf8dlsp7kL1JY6FY4oqnjThltpug6fL9oN9CuPDn5/ZmJN
         V/CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786522433; x=1787127233;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=EhdCkrcPLSxPPiE98EEmkvnOle3t6t516dhdKOJp0mI=;
        b=Vv/Ge5sjfsvTZdx2JBMdhjKH6gAjQRD5qvVnXj633ZSw4Gd9kia/pO7/yxx5Wlptjj
         2XORCFfnWKpZvp8jj2yOeEnnzyaiUNnZBRCDmKBlLd/73k0d41eQU9dd4zxTMiVvgNPc
         OugzyhwUEETx0tx43o8Qq86XYDnJQykRoCn/o3+WYqq0k5kxDTAgLNCPZcPNLzalB98z
         fXbR+j96ZyxPNoMAoWUMsrhBlYk6SYbVtHbMCLtfNh2hc6KCJupezVLwoTx2t88dFBYf
         RVRZemSNidUgauK+mEfCJYX6q+rOYuCjzRsIw71W4jFWIogAPU+OOvm+BcMmJ6R+XMOR
         o8MA==
X-Gm-Message-State: AOJu0YywnrB98ZDtd0Aj/152O3xxFIGEfT+VXg00DLZHJ3Rih/YlclKA
	93nSbceao1Tkpyf4wr9iW7WXQ+JEbv98hbJeVwRGtCmMnz84A/dpGMlfTnE6dPM80A==
X-Gm-Gg: AR+sD12130yWHv8Lx8K4uEyuWJXvP+HgOX7/PLmNAAnWz7d0bO4CmVnFMBTC+LrePi+
	xpodKoan1taIauRs1WxD8zJU2aYiXE6lcdWf4VyrwImSvCnWAKLP0tNvIn6+Oo2e2Njo76cXPNa
	Xt1SYAg23iMQ7rkFGDZirBkYcMOsC8KJMijW7/FzKdRkRBmR7dFo5BQxIoBZJ/WCzwg/UwaCLbg
	MTgTAx8bgrCXyBzDuOxCgsom9twBjVfzgmplbclNkhSWnIFSYU4TA0a8kZ/b4/XS9acIovqWPEk
	S3Z5aGu5fwKGT/V/sMFvxjCg/TlW2t4oh8Hyo8MnWn2f4tkMQx+m7G1L7xgmZDy2pZQYkb8ODgN
	26uXUDmyrVe85nFWLBtRmqHIA6MJMF1GASn5pRdNuG1Xk31ZXkVuyO5sm/4Gc4t7KLyIMNXHmEx
	ZNEXqM3Hd9I1waWJo9aGO3JW8PkYTDpDj32W/S5/7gArthG6DB4IJOYRYBpXBTpqwoa0QsmFn3z
	E5HSpEesbRu7dS4CuYWRgrl6h+dWvzx7k1DZNe0NEJlNN+wLpXV
X-Received: by 2002:a05:6000:250e:b0:480:2fd:96a6 with SMTP id ffacd0b85a97d-481528b9df6mr4107867f8f.7.1786522433014;
        Wed, 12 Aug 2026 01:13:53 -0700 (PDT)
Message-ID: <e1a3d71e-8a9f-428b-bcb6-6af3630a6b32@suse.com>
Date: Wed, 12 Aug 2026 10:13:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 6/7] xen/serial: harden serial_tx_buffer checks
To: Stefano Stabellini <sstabellini@kernel.org>, dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
 anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
References: <20260728065049.1318143-1-dmukhin@ford.com>
 <20260728065049.1318143-7-dmukhin@ford.com>
 <4b040e58-9020-a519-00cb-816ce2fddaa0@kernel.org>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <4b040e58-9020-a519-00cb-816ce2fddaa0@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1786522433-D735D87B-FB6483E6/0/0
X-purgate-type: clean
X-purgate-size: 1186

On 10.08.2026 22:32, Stefano Stabellini wrote:
> On Mon, 27 Jul 2026, dmukhin@ford.com wrote:
>> --- a/xen/drivers/char/serial.c
>> +++ b/xen/drivers/char/serial.c
>> @@ -523,6 +523,8 @@ void __init serial_async_transmit(struct serial_port *port)
>>          return;
>>      if ( serial_txbufsz < PAGE_SIZE )
>>          serial_txbufsz = PAGE_SIZE;
>> +    if ( serial_txbufsz > GB(2) )
>> +        serial_txbufsz = CONFIG_SERIAL_TX_BUFSIZE;
>>      while ( serial_txbufsz & (serial_txbufsz - 1) )
>>          serial_txbufsz &= serial_txbufsz - 1;
> 
> My understanding of this loop is that, given that serial_txbufsz is
> unsigned int, it is already clamping it to 2GB max

It would, yes, as long as sizeof(unsigned int) == sizeof(uint32_t). While
we certainly have many instances of that assumption in the code, I think
we're well advised to avoid adding more.

Furthermore (see related comments on patch 5) one may raise the question
whether serial_txbufsz wouldn't better be of type size_t.

What I'm uncertain about is the resetting to CONFIG_SERIAL_TX_BUFSIZE
here: When an overly huge size was requested, shouldn't we give the
biggest we permit?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:17:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:17:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388869.1629840 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu497-0007il-VT; Wed, 12 Aug 2026 08:17:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388869.1629840; Wed, 12 Aug 2026 08:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu497-0007ie-R6; Wed, 12 Aug 2026 08:17:09 +0000
Received: by outflank-mailman (input) for mailman id 1388869;
 Wed, 12 Aug 2026 08:17:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wu496-0007iY-8a
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:17:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu495-002Vwf-KN
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:17:07 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7c2bfa-2eae-0a2a0a5409dd-0a2a450c80aa-32
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:17:07 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7c2c03-f479-0a2a450c0019-c387df839b7c-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:17:07 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id BEB2E3E5A;
 Wed, 12 Aug 2026 08:16:58 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 85C0E779B1;
 Wed, 12 Aug 2026 08:16:58 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id w3uIH/orfGpQNwAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 12 Aug 2026 08:16:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786522622; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=+UjNEb0Wfjfq0TULQLgzkeXjL7nqgRcSI5XYS1L2kWk=;
	b=FI29BnNUeI02wxWMO560SdRrB+pUA1+/iVnhyFOdd3Yql4j/PL8yRrpxgf4L0cP9A6dlRH
	ezjP18JZGHzbVVFPRxcA+QARAtiEHNEDnPGONtLqH+H8CWe/dh25W6+T3ZQmy1i/eopH9n
	BAY4slmDyJwX2GUFDPlYoP8/2P45iBU=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=HGy8Jhwb
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786522618; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=+UjNEb0Wfjfq0TULQLgzkeXjL7nqgRcSI5XYS1L2kWk=;
	b=HGy8JhwbuhI6Iih89b+31QHuTFuTqlCU5cxIJHqpqCANw7IeTzDpYInjW8zBaups23/WMH
	oacmPRMmmAueso7TIE4i4IYT+QpajUz0iSe6+g2ry45WEJnfOIu8P/FjMELPE+YTHxFx+N
	LXL5L7DEqE9duCzmYqC7hCXcKpTuoYo=
Message-ID: <f8481120-00c5-411e-ad66-38ff550bdd47@suse.com>
Date: Wed, 12 Aug 2026 10:16:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/5] stubdom: remove grub-pv
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <20260720081833.4122182-1-jgross@suse.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260720081833.4122182-1-jgross@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------azPQUim8JMMg4gsb7rXqLEBm"
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-0.997];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FROM_HAS_DN(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	DKIM_TRACE(0.00)[suse.com:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]
X-Spam-Flag: NO
X-Spam-Score: -5.41
X-Spam-Level: 
X-Rspamd-Queue-Id: BEB2E3E5A
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-purgate-ID: tlsNG-d25034/1786522627-016C6A5B-C43B2E88/0/0
X-purgate-type: clean
X-purgate-size: 14574

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------azPQUim8JMMg4gsb7rXqLEBm
Content-Type: multipart/mixed; boundary="------------AeOjWSiT0qOlEfDcFYrUoUu0";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-ID: <f8481120-00c5-411e-ad66-38ff550bdd47@suse.com>
Subject: Re: [PATCH v2 0/5] stubdom: remove grub-pv
References: <20260720081833.4122182-1-jgross@suse.com>
In-Reply-To: <20260720081833.4122182-1-jgross@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------AeOjWSiT0qOlEfDcFYrUoUu0
Content-Type: multipart/mixed; boundary="------------CRoskvIA0U2r1ykjecVSz6UA"

--------------CRoskvIA0U2r1ykjecVSz6UA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

QW55IGZlZWRiYWNrPw0KDQpPbiAyMC4wNy4yNiAxMDoxOCwgSnVlcmdlbiBHcm9zcyB3cm90
ZToNCj4gVGhlIGdydWItcHYgc3R1YmRvbXMgKDMyLSBhbmQgNjQtYml0KSBhcmUgZGlzYWJs
ZWQgYnkgZGVmYXVsdCBzaW5jZQ0KPiBzZXZlcmFsIHllYXJzIG5vdy4NCj4gDQo+IFJlbW92
ZSB0aGVtIGluIG9yZGVyIHRvIGVuYWJsZSByZW1vdmluZyBxdWl0ZSBzb21lIG1vcmUgY29k
ZSBmcm9tIFhlbi4NCj4gSW4gY2FzZSBzb21lb25lIGlzIHJlYWxseSBkZXBlbmRpbmcgb24g
Z3J1Yi1wdiwgdGhleSBjYW4gZWFzaWx5IHRha2UgaXQNCj4gZnJvbSBhbiBvbGRlciBYZW4g
YnVpbGQsIGFzIHRoZXJlIGlzIG5vIFhlbiB2ZXJzaW9uIGRlcGVuZGVuY3kgaW4NCj4gZ3J1
Yi1wdiAoYSB2ZXJzaW9uIGJ1aWx0IDMgeWVhcnMgYWdvIGhhcyBiZWVuIHRlc3RlZCB0byBz
dGlsbCB3b3JrDQo+IHdpdGggY3VycmVudCA0LjIzIHN0YWdpbmcgWGVuKS4NCj4gDQo+IE5v
dGUgdGhhdCBhZnRlciB0aGlzIHNlcmllcyBoYXMgYmVlbiBjb21taXR0ZWQsIHNvbWUgYWRk
aXRpb25hbA0KPiBjbGVhbnVwIGlzIHBvc3NpYmxlIGJ5IHJlbW92aW5nIHN0dWJkb20gbGli
cGNpIGFuZCB6bGliIHN1cHBvcnQsIGJ1dA0KPiB0aGlzIHdpbGwgcmVxdWlyZSBhIG1vZGlm
aWNhdGlvbiBvZiBNaW5pLU9TIGRlcGVuZGluZyBvbiB0aGVzZSBwYXRjaGVzLg0KPiANCj4g
Q2hhbmdlcyBpbiBWMjoNCj4gLSBtb3ZlZCBvbmUgaHVuayBmcm9tIHBhdGNoIDIgdG8gcGF0
Y2ggMQ0KPiANCj4gSnVlcmdlbiBHcm9zcyAoNSk6DQo+ICAgIHN0dWJkb206IHJlbW92ZSBz
dXBwb3J0IGZvciBncnViLXB2DQo+ICAgIHN0dWJkb206IHJlbW92ZSBzdXBwb3J0IGZvciBi
dWlsZGluZyBpbiAzMi1iaXQgbW9kZQ0KPiAgICBzdHViZG9tOiByZW1vdmUgYnVpbGRpbmcg
b2YgbGlieGVuZ3Vlc3QgYW5kIGxpYnhlbmN0cmwNCj4gICAgZG9jczogcmVtb3ZlIHN0YWxl
IHN0dWJkb20gZW50cmllcyBmcm9tIHN0dWJkb20udHh0DQo+ICAgIHRvb2xzL2xpYnhlbmd1
ZXN0OiByZW1vdmUgTWluaS1PUyBzcGVjaWZpYyBwYXJ0cw0KPiANCj4gICBNYWtlZmlsZSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA2IC0NCj4gICBjb25m
aWcvU3R1YmRvbS5tay5pbiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAzIC0NCj4g
ICBkb2NzL21pc2Mvc3R1YmRvbS50eHQgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDY5
IC0NCj4gICBzdHViZG9tLy5naXRpZ25vcmUgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fCAgICAxIC0NCj4gICBzdHViZG9tL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgIDY5ICstDQo+ICAgc3R1YmRvbS9jb25maWd1cmUgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICA2NSAtDQo+ICAgc3R1YmRvbS9jb25maWd1cmUuYWMgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgMiAtDQo+ICAgc3R1YmRvbS9ncnViLnBhdGNoZXMv
MDBjdnMgICAgICAgICAgICAgICAgICAgIHwgMTAyMiAtLS0tLQ0KPiAgIHN0dWJkb20vZ3J1
Yi5wYXRjaGVzLzEwZ3JhcGhpY3MuZGlmZiAgICAgICAgICB8IDIyOTcgLS0tLS0tLS0tLS0N
Cj4gICBzdHViZG9tL2dydWIucGF0Y2hlcy8xMWdyYXBoaWNzLWtleWJvYXJkLmRpZmYgfCAg
IDEzIC0NCj4gICBzdHViZG9tL2dydWIucGF0Y2hlcy8yMHByaW50X2Z1bmMuZGlmZiAgICAg
ICAgfCAgIDUyIC0NCj4gICBzdHViZG9tL2dydWIucGF0Y2hlcy8zMHNhdmVkZWZhdWx0LmRp
ZmYgICAgICAgfCAgMTg2IC0NCj4gICAuLi4vZ3J1Yi5wYXRjaGVzLzQwZXh0M18yNTZieXRl
X2lub2RlLmRpZmYgICAgfCAgMTE0IC0NCj4gICBzdHViZG9tL2dydWIucGF0Y2hlcy81MGZz
X2Z1bGxkaXNrLmRpZmYgICAgICAgfCAgIDcyIC0NCj4gICBzdHViZG9tL2dydWIucGF0Y2hl
cy82MGV4dDQuZGlmZiAgICAgICAgICAgICAgfCAgNDc0IC0tLQ0KPiAgIHN0dWJkb20vZ3J1
Yi5wYXRjaGVzLzYxYnRyZnMuZGlmZiAgICAgICAgICAgICB8IDM0OTkgLS0tLS0tLS0tLS0t
LS0tLS0NCj4gICBzdHViZG9tL2dydWIucGF0Y2hlcy83MGNvbXBpbGVyX3dhcm5pbmdzLmRp
ZmYgfCAgIDQ1IC0NCj4gICBzdHViZG9tL2dydWIucGF0Y2hlcy85OW1pbmlvcyAgICAgICAg
ICAgICAgICAgfCAxNTcwIC0tLS0tLS0tDQo+ICAgc3R1YmRvbS9ncnViL01ha2VmaWxlICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICA4OCAtDQo+ICAgc3R1YmRvbS9ncnViL2Jvb3Qt
eDg2XzMyLlMgICAgICAgICAgICAgICAgICAgIHwgIDExMiAtDQo+ICAgc3R1YmRvbS9ncnVi
L2Jvb3QteDg2XzY0LlMgICAgICAgICAgICAgICAgICAgIHwgIDEwOCAtDQo+ICAgc3R1YmRv
bS9ncnViL2NvbmZpZy5oICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAxMiAtDQo+ICAg
c3R1YmRvbS9ncnViL2tleGVjLmMgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDQzNCAt
LQ0KPiAgIHN0dWJkb20vZ3J1Yi9taW5pLW9zLmMgICAgICAgICAgICAgICAgICAgICAgICB8
ICA3NzEgLS0tLQ0KPiAgIHN0dWJkb20vZ3J1Yi9taW5pLW9zLmggICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgIDcgLQ0KPiAgIHN0dWJkb20vZ3J1Yi9taW5pb3MuY2ZnICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgIDQgLQ0KPiAgIHN0dWJkb20vZ3J1Yi9vc2RlcC5oICAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgMzAgLQ0KPiAgIHRvb2xzL2xpYnMvZ3Vlc3QvTWFr
ZWZpbGUuY29tbW9uICAgICAgICAgICAgICB8ICAgMTUgLQ0KPiAgIHRvb2xzL2xpYnMvZ3Vl
c3QveGdfZG9tX2RlY29tcHJlc3NfdW5zYWZlLmMgICB8ICAgNDggLQ0KPiAgIHRvb2xzL2xp
YnMvZ3Vlc3QveGdfZG9tX2RlY29tcHJlc3NfdW5zYWZlLmggICB8ICAgMjggLQ0KPiAgIC4u
Li9ndWVzdC94Z19kb21fZGVjb21wcmVzc191bnNhZmVfYnppcDIuYyAgICB8ICAgMTQgLQ0K
PiAgIC4uLi9saWJzL2d1ZXN0L3hnX2RvbV9kZWNvbXByZXNzX3Vuc2FmZV9sejQuYyB8ICAg
MzkgLQ0KPiAgIC4uLi9ndWVzdC94Z19kb21fZGVjb21wcmVzc191bnNhZmVfbHptYS5jICAg
ICB8ICAgMTQgLQ0KPiAgIC4uLi9ndWVzdC94Z19kb21fZGVjb21wcmVzc191bnNhZmVfbHpv
MXguYyAgICB8ICAgNDQgLQ0KPiAgIC4uLi9saWJzL2d1ZXN0L3hnX2RvbV9kZWNvbXByZXNz
X3Vuc2FmZV94ei5jICB8ICAgNDYgLQ0KPiAgIC4uLi9ndWVzdC94Z19kb21fZGVjb21wcmVz
c191bnNhZmVfenN0ZC5jICAgICB8ICAgNDQgLQ0KPiAgIDM2IGZpbGVzIGNoYW5nZWQsIDEg
aW5zZXJ0aW9uKCspLCAxMTQxNiBkZWxldGlvbnMoLSkNCj4gICBkZWxldGUgbW9kZSAxMDA2
NDQgc3R1YmRvbS9ncnViLnBhdGNoZXMvMDBjdnMNCj4gICBkZWxldGUgbW9kZSAxMDA2NDQg
c3R1YmRvbS9ncnViLnBhdGNoZXMvMTBncmFwaGljcy5kaWZmDQo+ICAgZGVsZXRlIG1vZGUg
MTAwNjQ0IHN0dWJkb20vZ3J1Yi5wYXRjaGVzLzExZ3JhcGhpY3Mta2V5Ym9hcmQuZGlmZg0K
PiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCBzdHViZG9tL2dydWIucGF0Y2hlcy8yMHByaW50X2Z1
bmMuZGlmZg0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCBzdHViZG9tL2dydWIucGF0Y2hlcy8z
MHNhdmVkZWZhdWx0LmRpZmYNCj4gICBkZWxldGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9ncnVi
LnBhdGNoZXMvNDBleHQzXzI1NmJ5dGVfaW5vZGUuZGlmZg0KPiAgIGRlbGV0ZSBtb2RlIDEw
MDY0NCBzdHViZG9tL2dydWIucGF0Y2hlcy81MGZzX2Z1bGxkaXNrLmRpZmYNCj4gICBkZWxl
dGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9ncnViLnBhdGNoZXMvNjBleHQ0LmRpZmYNCj4gICBk
ZWxldGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9ncnViLnBhdGNoZXMvNjFidHJmcy5kaWZmDQo+
ICAgZGVsZXRlIG1vZGUgMTAwNjQ0IHN0dWJkb20vZ3J1Yi5wYXRjaGVzLzcwY29tcGlsZXJf
d2FybmluZ3MuZGlmZg0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCBzdHViZG9tL2dydWIucGF0
Y2hlcy85OW1pbmlvcw0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCBzdHViZG9tL2dydWIvTWFr
ZWZpbGUNCj4gICBkZWxldGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9ncnViL2Jvb3QteDg2XzMy
LlMNCj4gICBkZWxldGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9ncnViL2Jvb3QteDg2XzY0LlMN
Cj4gICBkZWxldGUgbW9kZSAxMDA2NDQgc3R1YmRvbS9ncnViL2NvbmZpZy5oDQo+ICAgZGVs
ZXRlIG1vZGUgMTAwNjQ0IHN0dWJkb20vZ3J1Yi9rZXhlYy5jDQo+ICAgZGVsZXRlIG1vZGUg
MTAwNjQ0IHN0dWJkb20vZ3J1Yi9taW5pLW9zLmMNCj4gICBkZWxldGUgbW9kZSAxMDA2NDQg
c3R1YmRvbS9ncnViL21pbmktb3MuaA0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCBzdHViZG9t
L2dydWIvbWluaW9zLmNmZw0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCBzdHViZG9tL2dydWIv
b3NkZXAuaA0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCB0b29scy9saWJzL2d1ZXN0L3hnX2Rv
bV9kZWNvbXByZXNzX3Vuc2FmZS5jDQo+ICAgZGVsZXRlIG1vZGUgMTAwNjQ0IHRvb2xzL2xp
YnMvZ3Vlc3QveGdfZG9tX2RlY29tcHJlc3NfdW5zYWZlLmgNCj4gICBkZWxldGUgbW9kZSAx
MDA2NDQgdG9vbHMvbGlicy9ndWVzdC94Z19kb21fZGVjb21wcmVzc191bnNhZmVfYnppcDIu
Yw0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCB0b29scy9saWJzL2d1ZXN0L3hnX2RvbV9kZWNv
bXByZXNzX3Vuc2FmZV9sejQuYw0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCB0b29scy9saWJz
L2d1ZXN0L3hnX2RvbV9kZWNvbXByZXNzX3Vuc2FmZV9sem1hLmMNCj4gICBkZWxldGUgbW9k
ZSAxMDA2NDQgdG9vbHMvbGlicy9ndWVzdC94Z19kb21fZGVjb21wcmVzc191bnNhZmVfbHpv
MXguYw0KPiAgIGRlbGV0ZSBtb2RlIDEwMDY0NCB0b29scy9saWJzL2d1ZXN0L3hnX2RvbV9k
ZWNvbXByZXNzX3Vuc2FmZV94ei5jDQo+ICAgZGVsZXRlIG1vZGUgMTAwNjQ0IHRvb2xzL2xp
YnMvZ3Vlc3QveGdfZG9tX2RlY29tcHJlc3NfdW5zYWZlX3pzdGQuYw0KPiANCg0K
--------------CRoskvIA0U2r1ykjecVSz6UA
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------CRoskvIA0U2r1ykjecVSz6UA--

--------------AeOjWSiT0qOlEfDcFYrUoUu0--

--------------azPQUim8JMMg4gsb7rXqLEBm
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp8K/oFAwAAAAAACgkQsN6d1ii/Ey9f
awf8D8TO6kxEcF4Ar69AsZ0hsAYl7PT5h0YXLvbF8aB1U0q3xFk/xjZbS37doDYLymDSHBP6JKxg
fmeJe3aXULSSR+mw8r/TyFb89Wv4FS5ucCjrd/MA2ZYaQuTlCmG/4jzdYAd+eC+IYCv33whT5Bqs
PRNjLnOvWioF3dsR7OxYYCAJEnOYuLPlFEvexLZg8VPPlgeXzYsRu0a1CxSm4/0YJptpbQTEQqGw
TYB9T5S4ncb4Usq81exUxqre3KPIWAoT3Y31vYDzXNePgwSPo6rmv97twtDI8zbKf70rCeQDm7hD
TyZg4zaRPKQjkLLJ+IQoVH66vh8WhLTcn+exNSp+xw==
=iw9k
-----END PGP SIGNATURE-----

--------------azPQUim8JMMg4gsb7rXqLEBm--


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:20:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:20:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388880.1629849 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4Bu-0000KE-Eb; Wed, 12 Aug 2026 08:20:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388880.1629849; Wed, 12 Aug 2026 08:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4Bu-0000Jl-9J; Wed, 12 Aug 2026 08:20:02 +0000
Received: by outflank-mailman (input) for mailman id 1388880;
 Wed, 12 Aug 2026 08:20:00 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu4Bs-0008U0-BU
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:20:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu4Br-009DNy-NW
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:19:59 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c2c9f-2eae-0a2a0a5409dd-0a2a4501bf86-42
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:19:59 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c2cad-5984-0a2a45010019-d155dd36bde6-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:19:57 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-4798bea72f9so311234f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:19:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150c06ab7sm4983563f8f.10.2026.08.12.01.19.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 01:19:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786522797; x=1787127597; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Xbkrj8eRgDwMAbqx9zPbWp+jysgWEKTdlMFuu67rOtA=;
        b=JnoZxiqj0FP5nzDA0fmtKc8wbLlbf9WXWyfGo4Pn4JJS3nsaBMIa9BLCOYwzwjLlOQ
         PHUp/AWmg3haG9X3TGFGZuy1jQ1WyPHCFMCZI5yAo39WQr404tOeJd9jFzadqQCG5iR1
         PehHNzvQBKVBPh1A0whv8BvMt198a4gc9VeI/40OqX4C5D3hrk43ifD0tPnIgkDX/u5I
         OtbpHDUr4zkvwP/+7264yG+ktnfjlVo9AKf5ItlODct49dkGkajtZS9lRplubk8tY8gQ
         MdqbkfptpkEB4MCjOMs+APG2engaLpxiJtZabqy4ZByinWeUU5Ezue51caXP42RRf7y7
         kfxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786522797; x=1787127597;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Xbkrj8eRgDwMAbqx9zPbWp+jysgWEKTdlMFuu67rOtA=;
        b=YgvF/r84KsqqRnfziRkZRyVTyGnwPtHIVZ4QVVpr8BNznEOCxsqlRQA6XWQHpw4t66
         u5zFcdRXY33uDqbB+3dnFIB0Y4Fn9GCoTvGx5dkgWDAe0bovpFehiEwuoZ9ezr2LTGle
         8mk47aPk0Am1yXyf73NLBK63qOoXhFWNubbI1k7nENTPypsriyGYvw/LonkZ98XvA83K
         DPXHBZZWMM3wybjj+W8wnHKMFsOfYd8jUfNglDAQ2hnurqsWa+NO0gyfaA2yXclG5bBP
         gWX5J2PG8eYnJh3WQwdf4YkQZn3qVhy/op1tzC6tuQRuAqIIEa5FE5Vy6lHY1w9fmxa1
         0zTw==
X-Forwarded-Encrypted: i=1; AHgh+Ro0QYjy1LtlcJ8KHQFfPD6ecodwID/cNA5STJIdmxHfDIlrZ9+SWD6NVKhJuhlH3UfUl5QaPajeNSc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx+WpMVBsZIpC7aP9llxCrdnSMO8t63lEaKEdFMlykonvtTgjHN
	jfhL7lNGNfYX4sqUel81CDrHPKGJPUv70VJR+vfWjapZJ+iIF1e2vVM17PanOTSF5g==
X-Gm-Gg: AR+sD11TN+QGh+Jf0DOvKoaUYXGbU2hpNnbNglP1cLsOaGkmzLjxMIllHeN/mQb/Gtl
	P0nX1WW4cgZu8u20DHCW1/guUf2w9pt/9taGKxjD+5YPpCzNcVr9Bv9Mn47f+SOAMUSilw0Dn1N
	TtGIG2nfReRfFWoBhp4fQVDDm5hWOZVLOK+/vYGIWKkiJrWaAwq2E5uaY1+i7TzlHxZ+3fUgYB+
	gxZWFDq9OUk3a0032x3EpWictOpr4My0Jo/p0r0ol+XtmxX/2DlREni3QcLp5L/zuQ3DgDbHnRf
	jsb6Lx/01hIGjULVcCBJcnpJF9cY+90Am1aqx57ht9zngzR+RndPy/UO/icVlq8cR0R3f5wFq7S
	K8LfuCLEvvxIJEpLI6PvNfyksYUnCvVoM8N/oqE5uXOZjXaMD30cDDVYdS9WieGMiDGQvvee7sN
	OsWHayI7ijxfX3TH2qpIWW1CJRwwUiJXaMm0pL7svLU8cBXd4ecEgoZFv2dFLrR3lbvInsjGzDQ
	/kIizYppRHmWlBcbU24PkhMLmhzXD9anM15mC5QFF4769MXzvUe
X-Received: by 2002:a05:6000:1865:b0:47f:b51d:f0ec with SMTP id ffacd0b85a97d-481528d77bemr3615393f8f.15.1786522797232;
        Wed, 12 Aug 2026 01:19:57 -0700 (PDT)
Message-ID: <7ea460ba-e2c8-45a7-9b7c-0cddcce275e5@suse.com>
Date: Wed, 12 Aug 2026 10:19:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/common: add keyhandler to show Xen command line
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
 andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, sstabellini@kernel.org
References: <20260810230359.671587-3-dmukhin@ford.com>
 <anrXvTfBls4flBqK@macbook.local> <anuMfq/lDjxbR8Om@kraken>
 <ba78a8a1-6862-41b0-a6a5-cae7eada3627@suse.com>
 <anwo2QtEh9tObNDD@macbook.local>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <anwo2QtEh9tObNDD@macbook.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1786522797-BC95A757-017B7826/0/0
X-purgate-type: clean
X-purgate-size: 2199

On 12.08.2026 10:03, Roger Pau Monné wrote:
> On Wed, Aug 12, 2026 at 09:28:46AM +0200, Jan Beulich wrote:
>> On 11.08.2026 22:56, dmukhin@ford.com wrote:
>>> On Tue, Aug 11, 2026 at 10:05:17AM +0200, Roger Pau Monné wrote:
>>>> On Mon, Aug 10, 2026 at 04:04:01PM -0700, dmukhin@ford.com wrote:
>>>>> +static int __init cf_check misc_init(void)
>>>>> +{
>>>>> +    register_keyhandler('X', show_hypervisor_info,
>>>>> +                        "show hypervisor information", 0);
>>>>
>>>> "show hypervisor information" seems too generic to me, almost all
>>>> debug keys could be defined by this sentence TBH.  I think this needs
>>>> to be more specific, but I'm not sure what's the plan regarding this
>>>> key.  Is there an intention to print more stuff here, or just the
>>>> command line?  Knowing the full set of information to be printed might
>>>> help come up with a better name.
>>>
>>> I will update to "show_cmdline" since I originally planed to expose Xen
>>> command line only so it is possible to better debug a system when dom0
>>> becomes almost unresponsive.
>>
>> Yet as indicated already on v1 (I think) - a precious debug key character
>> for just the command line seems rather wasteful to me. If it's only the
>> command line, and if that _really_ needs exposing via a debug key (i.e.
>> if there are reasonable scenarios where "xl info" cannot be used), perhaps
>> attach it to e.g. the 'h' key output?
> 
> I was going to say that we should not overload the 'h' key with
> printing a possibly long string, but I see we already print a bunch of
> information there, like the buildid and the compiler banner.
> 
> One option would be to introduce a new debug character, and move the
> printing of the buildid and the banner to that key, together with the
> command line.  Then 'h' output will be cleaner and just print the list
> of installed handlers.  That would give the new key more content, and
> help cleanup the output from the 'h' debug key at the same time.

Hmm, yes, that's definitely an option. May I then further suggest to use
'?' as the key for this? (Or am I overlooking that key already being in
use somewhere?)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:22:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388888.1629857 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4E1-0001WM-Nl; Wed, 12 Aug 2026 08:22:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388888.1629857; Wed, 12 Aug 2026 08:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4E1-0001WF-KW; Wed, 12 Aug 2026 08:22:13 +0000
Received: by outflank-mailman (input) for mailman id 1388888;
 Wed, 12 Aug 2026 08:22:13 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <kevin.lampis@citrix.com>) id 1wu4E0-0001Vy-Oe
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:22:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu4Dz-00DTSM-Me
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:22:11 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <kevin.lampis@citrix.com>)
 id 6a7c2d2c-8faa-0a2a0a5109dd-0a2a4505d506-16
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:22:11 +0200
Received: from [52.101.201.25]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <kevin.lampis@citrix.com>)
 id 6a7c2d30-4cb1-0a2a45050019-3465c919d5b3-4
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:22:10 +0200
Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8)
 by SA5PR03MB8402.namprd03.prod.outlook.com (2603:10b6:806:47b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Wed, 12 Aug
 2026 08:22:03 +0000
Received: from BY1PR03MB7996.namprd03.prod.outlook.com
 ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com
 ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0315.011; Wed, 12 Aug 2026
 08:22:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PiKofyZfKHk7Y6j/BcRGGqbaZcFY4L0t74T5xt5yOhk57dvjfwxYmXIEZYtzVnEneLEV/1looT2NZU7b00zvGz/hCF8928493CyymT/+aIqrxMSfT48NNTpVAyKLjpnrOTPAra4vdmzutxmKvZzlCT36YI16NdMKa2gu+ysJwIy6hLlxlRbJ0vQTuubn9vBZYGls1iHgoRk/cORCYMOsw9jApQ716z09WvRtob7HluoyiI4cRnakc356C3Jvy30IhktTEkY52+UVNd34S1uAuvJNX02xL45Q0/T66vpLJT2qq4f6yuIeQ9DOrxzqiRUnbtCBYW6GQrDKZ7dr7r9iYw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8PUu/HzIHmCgPGEa4oww1wsRdsprVs1lpIQOyApukl8=;
 b=T/RMGaIGXtjHBdEXJLHnC3fb5qh7bs4te4zFlQDiz7e8Ejb5p9Yin4Y3y1WcujFXruiuamjR9zuiwlmPL7zWSPIsnpv6niaSwGof5YhK290m+BR259jmYCjw/1WfQPcxj8bZMYHwxIGrxk+m819Wkvw7FyE2ioDAVLBHiKm96Jh7t4CuXPOFftc8kUatR8Qb7ujlBnVYd3qZtGBWr80fMlquItvYCAZXpzsCIxrLZdYB9EGouPqAzq5arYFX65Yw38gx3Hq7RUqOjxyvPtrp7RpVx1pvy69/yA+B+kyTR0Ckfy90IN/wZ2OQtDprc8QQIMkO3dXtbqOjrkEPOsw4MQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8PUu/HzIHmCgPGEa4oww1wsRdsprVs1lpIQOyApukl8=;
 b=GIEVTF8Q7YJfiwENMEjPZSfF8bx7dz7SCb09jZNncnuj/6yGw2iJw4S1heojyFD+7DLMkXbFsbZIczzWB0B8pfhqj4xdoAwimxZNE6iGZBDncQ2oVC6eQcw6BBgxNf7LBkSy9M9FdhhtkFnvHemfyWkDOQNEyXrzLHo69a+jU7M=
From: Kevin Lampis <kevin.lampis@citrix.com>
To: Teddy Astie <teddy.astie@vates.tech>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] public/xen.h: Update comment on mmu_update sub-command
 size and PTE alignment
Thread-Topic: [PATCH] public/xen.h: Update comment on mmu_update sub-command
 size and PTE alignment
Thread-Index: AQHdJrO8whNB7U0leUOma0sfTU1dNLaaGXsb
Date: Wed, 12 Aug 2026 08:22:03 +0000
Message-ID:
 <BY1PR03MB79967CC42060F5EE8E97A4B0F3DC2@BY1PR03MB7996.namprd03.prod.outlook.com>
References:
 <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
In-Reply-To:
 <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|SA5PR03MB8402:EE_
x-ms-office365-filtering-correlation-id: 15209b41-e978-42b0-671d-08def84ac9f8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|18002099003|22082099003|56012099006|38070700021|11063799006|10067099003;
x-microsoft-antispam-message-info:
 Lj+sXxPss+i0pPauAhEHXIGjJtocW1CyTHQw8FyyIIHdlOsdl9m85/dkANqvkA+GZma0BmdFe8WSsiTr6ZoaW+5XsQZ8nq4KYIR68npNoRXAhdLa9f9mOQxlyS8WiGjE2T8brAEsFLflwVjvidCKihZuFm2pD/V5aLX8ak1tOVEW0jIeCVTVlV3S8kHbue17R3hB1UHsWbWBU+zI5XlaCox3goj37ewgg/y5kD6xs9wOfT7TarJvDRT6igGJa8dS0uHu9/qLxPkAv48bp2F8QBe+bwdp+yEiaIa91WuniO4mzbJRzY2et3NWsgruRuUA4JeCTc509l5cRJRPkEyI4DK9+wamt6/ihykklL62zfCUrLkH1LvDnakFUFuoLkZuKYA2kjhIaz8YCiAcuFVBAgUFtrE6J9XeUDj1/D/9WJHIXZmz5MWnYHZqe6B9KM0c+GDLZO0eLSYbEUPrJ2MGekAcQuLb2zWXHEwEMkp9I25n5KDzSFjtA3FrAxEv2SWaSepl7P6aFwzy9gd/aR5+/n5ldnhLBmmUoXOfwtiucQz0pwSA77tkISY/3M0NMjPIBUkhLuUSGPCSmmfIUMNWmgvZyU+7nZVihhEIr1a3YVopuwLf34W92Z8apMJx/YX6T9kmdiW0zX52XkCx3/N4+CbnPK0HzKjjtNohpH5n3gRuwbb4eRbU8QPwkZCU9nujvwwI1MzQZuVlq4tbtbADDteOokchfiES5c2/agy9hhY=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(18002099003)(22082099003)(56012099006)(38070700021)(11063799006)(10067099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Bjp4229fHsQGXy2APT4VQ/Sc1Xh6JLpC5G42aLkjB0s6lpIxy/cv1E3JWQ?=
 =?iso-8859-1?Q?t+C90qQrtrYoSDas1QPz6QEnC+A3g/ICCvHL7k8+7MBXi+LmwXLCGXf4vh?=
 =?iso-8859-1?Q?2XyMMtrLqLz0pFDw0Nqt/Oj9KHrSOc52U/xc+/aLzXqb72m5DpT+6N90Kl?=
 =?iso-8859-1?Q?sfhra7wDzv/O/SsEsxAcdHd+wGNmjKTfR8UCV96PdUZ1ABA76W4WQ2nmEe?=
 =?iso-8859-1?Q?0tswqqOZ5E3GWodou3Y/liBUf9HNDfZqyqCa15fCkmmvic1rzDlRSrbOnY?=
 =?iso-8859-1?Q?Rvbx5k+H6T9JIuLQ+fX8DxgGGXhNreEGGxRquxOIt4rH+lWwwa7d6RTuNI?=
 =?iso-8859-1?Q?OelRpwJ9m8mqb5momO5UXEpmkE98Vhyad408jKVWn1FbrIXv37esayj2S6?=
 =?iso-8859-1?Q?A7OGekl0ZXxnQWURocZxC5nH3gQxrmDMma1o0my9/SuAyomieBSJfhXFtH?=
 =?iso-8859-1?Q?I8n2WuqGpJC0mPo5fQqaB1Ag2kRaIPMPxkVVKBTRl5VyEctXdAubDMQq9J?=
 =?iso-8859-1?Q?/u+rNvK3/N29el7bT4sCCwkdh0T0GvdX5pIsHbLUIpu6awlhx8/l5xay9f?=
 =?iso-8859-1?Q?p6KrB64xsxdrVUT8h5e5D/AZEJFkXs7ODQZeXYClNTEci5Pp3o3PKJQPZk?=
 =?iso-8859-1?Q?sXZEIYhf4LYZJKDHlhX7sV4cnOZYgOfcXvjuVt3rK6VYtC1j+I9+1jGLBi?=
 =?iso-8859-1?Q?lh8VBscGKLZrTj8Ri85R7Rbl+CuadXtnxYoK5rmcaRWlWxUX/KbTvBDR/U?=
 =?iso-8859-1?Q?D72a/MxfYsHwU6f4cX0byYj4SDIee0HZEQ16FI14fL0gdW4/ehUJYnkCkg?=
 =?iso-8859-1?Q?ZA4JBV1RlY9bMVUx+5Poz3anp/rNs0sH/sV33OARFRdcxe6Ok21f5Up+Of?=
 =?iso-8859-1?Q?xo78EIXQ9XiH3KAF6kGP1Y5gd5KGp/Lrfba1mfy7MItHN+JTSFQLh87SzJ?=
 =?iso-8859-1?Q?A8DZfzPD5FYv14EKSdHUK5dlHacI+6ne1A6LQvvpmGPKiZbrUTUo29Fi39?=
 =?iso-8859-1?Q?qaT8gxwte7xI/H5LcmyzaKmrXd5SuEWauE8lolXuj/mXVjXle5gQzeZq8K?=
 =?iso-8859-1?Q?qEQg5oF6X1ayOJrcisvjMMwPOq3KGJMsxk7lXYAOw44uMpzd5qLYvq7eR2?=
 =?iso-8859-1?Q?5qvcOAQNE76Fi7wfRO9yjamx0fMZQIVRBWHGTaepd8voCE8HS8uS2J+DmF?=
 =?iso-8859-1?Q?2GnAtyVoWwM73hTtfmJ6tZUpy3tsiS1Y5srFwdxeq1TrBkOFXfLaeoXAs0?=
 =?iso-8859-1?Q?iRbXAiY5t2EBNGkySsKpl38y6qzZO1Qf3SobpK1H/LZeEIZ3C94cVTmdhi?=
 =?iso-8859-1?Q?X4xpfns+0VD0qdlBInjqBPauX0o09+f9KOJs0P4CKUY8BCkodkr4Ch95+j?=
 =?iso-8859-1?Q?6HoXHiy9BCMblhJebj8HUaCXVoZkk05hq5En4gFEI2DW3m49LPGhuO+/W/?=
 =?iso-8859-1?Q?pBHa6Lhp5pdnEy2VWa8v8PZtrYwQMQR42Ga+LUEVxd4Ycj3CtVIaO7NbMA?=
 =?iso-8859-1?Q?IbZJYMzjoquCrBFPGnAEa1dtWJYcTGs2tkFvDGi2vxRn7uF8r7Gn7PyhgE?=
 =?iso-8859-1?Q?BewcqqeZ2r97lT1LwfbZY4vf3YbhipbZPXIoS+Q6GhjMPe+t+Dzr5Xj8Zk?=
 =?iso-8859-1?Q?+1iay0ZOWQUTmwsVufc4D7PzByFOMVfDkHB/r8IjQ6R3bm8pV5C3yMPtDi?=
 =?iso-8859-1?Q?aRwDUG48mL3E6Xjp1oZa4+N2TXdnRX16eCm/Df8BDBeJuJTrds9gPcKwIR?=
 =?iso-8859-1?Q?6LVE92urnMqCpgGWCFs2RClUfQ07DeIwlbCs+UEwseuBQx2/fcACpingUe?=
 =?iso-8859-1?Q?r9PJ29ZICg=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 15209b41-e978-42b0-671d-08def84ac9f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2026 08:22:03.2385
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fgNXytxFbUgwcgo2UVuw3Rh5da7Z1rMAVAujlJzSjM3G8Xgiy7+th1+PhlyepaLTIhgU3BkomWsDmXKXEwwcng==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PR03MB8402
X-purgate-ID: tlsNG-c201ff/1786522930-F64B42A1-DDA81F40/0/0
X-purgate-type: clean
X-purgate-size: 235

>CC: Kevin Lampis <kevin.lampis@citrix.com>=0A=
>This now expanded sub-command field can be used for your "unmap_page_range=
 optimisation"=0A=
>series to avoid having to introduce a new dedicated hypercall.=0A=
=0A=
Thank you.=


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:27:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:27:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388898.1629866 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4JO-00029q-8k; Wed, 12 Aug 2026 08:27:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388898.1629866; Wed, 12 Aug 2026 08:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4JO-00029j-5t; Wed, 12 Aug 2026 08:27:46 +0000
Received: by outflank-mailman (input) for mailman id 1388898;
 Wed, 12 Aug 2026 08:27:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu4JM-00029d-PH
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:27:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu4JM-00BjbY-4v
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:27:44 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c2e70-e002-0a2a0a5209dd-0a2a450ae3b4-46
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:27:43 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c2e7f-f2d2-0a2a450a0019-d155dd2fd8a1-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:27:43 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47fecbb7000so314311f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:27:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150d72232sm5450024f8f.37.2026.08.12.01.27.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 01:27:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786523263; x=1787128063; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=AxF9ThbimReP54YPIpZA2L6bkAmldFc0bCkBEL+nZTQ=;
        b=DD+D081h0YNG82rE04uvwGqlGajzG9ODHFMltyjzNctNyaPbbjadtmhgsS0yBbbejf
         1e2y7zlZMierJksm5X1x1LbMml8OFYwa0UxHWzww74h/TeftGc+xWzi2NbdOjZGULhvR
         qGEBpBuhZItidg1lHzaQMi0wsp9QsOjBFsZbC7E9aiptDAToSASp2ArJBDVvDH/U9P++
         Ejc38qzuPS8GBbUwaGgLT1qimHXGD0vA6ghj2ogS71TSNrtRYDqLI5CYn39XrE8as0Pb
         EVokQSCen28p35fl+n5knQW/BhxRVSPul+18MrBarwlpA5s6EdeFYnbX+CTyOwFw/6Sn
         jdHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786523263; x=1787128063;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=AxF9ThbimReP54YPIpZA2L6bkAmldFc0bCkBEL+nZTQ=;
        b=p0bBGxOt4937alsafKe7KO+XrwOKDknayJnrfKYLEFFvYtNI3aF6uoI0MpHOycpOVD
         QEoIC0r1yrJph03Uh3SdLW1zPzEeLrdO1rehQ5kMGAXd6vo/EsUpBTy22eFS5IyUH8EU
         AcIHRkMUgI803gPzXaJWdss4oCoz6PKYpYHyXOYho73RS8oNb5kfFhkNBCqVMkRsZxT4
         LYSkQ/0X+61s48cYz7QxpSm5fiIMRbb20NfghEe5vnU0+7JZmi4GQcPSGUdG8qvutJ2j
         k8rl2qSfSUGhNoSh9d81MabbbAD4YqvWYL4NFoKvs9OfrUaExcBJRMnCsx+DOtc0dn8s
         0bVw==
X-Forwarded-Encrypted: i=1; AHgh+RrjMEUHG/K5YY9E+unpohy6NXoVL81ijmCf3hmh7GqULTWSAC6XLEujaRp/85MwuARnIV4TeG4z3Ec=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxj7myzt9xk7y2ScxIcxsSTSYuiI76bOKWPgKx7bumyB74OnlY9
	SRD3KzC84dnw3akr/PAsRZW6+su9gecCh/uj5DnIfqtXHHyd/ek0mwUGnzIe7nTR0w==
X-Gm-Gg: AR+sD12+s50mEIr96ZlfrhHw50wo37FYtIxeoZgkQX5r+s+5kAeTdkbevu1K1eHVrta
	LwlhFnmNYb/JU5Gs5wo134VkELPSBCprVF7peWkJlfLi205CxXhg5wCGGoj5K9re0yvxGk2ojx3
	II10uF0NoUCGlK9Np53Npzm6cMwGf1D1y1hgaIIuH1QncSBATuMYrS1XgWzbTh02pl/QiSNOzUr
	tq4exnG/gCM8jrrvmn5RZMcjw8Ybb9DR1eE5cWdAfsHYRZ0qAGOVXZ05BmAId4mWdzLFDgApZ30
	1LbBgEmji/5nMPy7ltlvBeHXxSrgLYZw8Ot6fkFnwRZLRoBE1TPQXGVR1a2Rrnx2gNLghAo0Xud
	IpgRIU9iSNkCPi8Ya8JORQsCsmGhNBjuwSBpNU6fl8hfgS8gzeEgX47oAHz1JCnEuKwtXPH2fr2
	RQLZT9Wh9J5HTmXpeu+YxeCU2+SaqxggOz7VgZ/Efu6sVqsgZN8l7u8n7HYsQwaJG81rtunOjs0
	XWV2lkHMlBJPuTMRau6unCvxjG30ZbwYSPqE6cybC3JT1Xvz9mf
X-Received: by 2002:a05:6000:4022:b0:47f:d0fb:ea33 with SMTP id ffacd0b85a97d-48152c75ef4mr4014071f8f.20.1786523263332;
        Wed, 12 Aug 2026 01:27:43 -0700 (PDT)
Message-ID: <193c0981-f5dc-4598-abc6-58ccbbe1a372@suse.com>
Date: Wed, 12 Aug 2026 10:27:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] public/xen.h: Update comment on mmu_update sub-command
 size and PTE alignment
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Kevin Lampis <kevin.lampis@citrix.com>, xen-devel@lists.xenproject.org
References: <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1786138121.8631fc262581453bbf619ec5b2062170.19fde20d3e4000e099@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786523263-506CECFC-B2E5C686/0/0
X-purgate-type: clean
X-purgate-size: 3859

On 07.08.2026 23:28, Teddy Astie wrote:
> HYPERVISOR_mmu_update passes a set of request, where each request has a pointer
> to the PTE along with a sub-command.
> 
> The PTE alignment padding is used to transport the sub-command while the rest
> is used as a address to a PTE entry. The current documentation state that the
> 2 first bits are used for sub-command, hence the other ones for PTE which
> imply here a 4-bytes alignment on PTEs.
> 
> On PV64 and PV32-PAE guests, all pagetable PTEs are 8-bytes aligned, hence
> off-by-4 PTEs addresses are always incorrect. Non-PAE PV32 guests used
> "legacy pagetables" which had 4-byte aligned PTEs. However, support had
> been completely removed since Xen 4.0, and were only available when Xen was
> built in 32-bits non-PAE mode [1].
> 
> Current Xen logic behave as if 3 bits are used as sub-command, thus all
> off-by-4 PTEs are actually rejected as being unknown sub-commands.
> 
> Adjust the documentation to match the current logic implemented in Xen,
> also expanding the documented sub-command parameter to 3 bits.
> 
> [1] 84d54d5d8b31 ("i386: Remove non-PAE hypervisor build target.")
> 
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> This happens to be a complete rewording of [2]. I'm not sure what to do exactly
> regarding the signed-off.

I think the patch here nevertheless should have been v2, with original authorship
retained. It looks largely okay to me (with Frediano's nits addressed). I think,
though that ...

> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -218,16 +218,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   *                     x == 0 => PFD == DOMID_SELF
>   *                     x != 0 => PFD == x - 1
>   *
> - * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command.
> + * Sub-commands: ptr[2:0] specifies the appropriate MMU_* command.
>   * -------------
> - * ptr[1:0] == MMU_NORMAL_PT_UPDATE:
> + * ptr[2:0] == MMU_NORMAL_PT_UPDATE:
>   * Updates an entry in a page table belonging to PFD. If updating an L1 table,
>   * and the new table entry is valid/present, the mapped frame must belong to
>   * FD. If attempting to map an I/O page then the caller assumes the privilege
>   * of the FD.
>   * FD == DOMID_IO: Permit /only/ I/O mappings, at the priv level of the caller.
>   * FD == DOMID_XEN: Map restricted areas of Xen's heap space.
> - * ptr[:2]  -- Machine address of the page-table entry to modify.
> + * ptr[:3]  -- Machine address of the page-table entry to modify.
>   * val      -- Value to write.
>   *
>   * There also certain implicit requirements when using this hypercall. The
> @@ -264,17 +264,17 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
>   * pagetable MUST not be in use (meaning that the cr3 is not set to it).
>   *
> - * ptr[1:0] == MMU_MACHPHYS_UPDATE:
> + * ptr[2:0] == MMU_MACHPHYS_UPDATE:
>   * Updates an entry in the machine->pseudo-physical mapping table.
> - * ptr[:2]  -- Machine address within the frame whose mapping to modify.
> + * ptr[:3]  -- Machine address within the frame whose mapping to modify.
>   *             The frame must belong to the FD, if one is specified.
>   * val      -- Value to write into the mapping entry.
>   *
> - * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
> + * ptr[2:0] == MMU_PT_UPDATE_PRESERVE_AD:
>   * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
>   * with those in @val.
>   *
> - * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE:
> + * ptr[2:0] == MMU_PT_UPDATE_NO_TRANSLATE:
>   * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
>   * page tables.
>   *

... at least retaining some reference to the non-PAE situation would be helpful.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 08:45:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 08:45:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388909.1629875 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4aS-0005J3-QB; Wed, 12 Aug 2026 08:45:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388909.1629875; Wed, 12 Aug 2026 08:45:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4aS-0005Iv-Mm; Wed, 12 Aug 2026 08:45:24 +0000
Received: by outflank-mailman (input) for mailman id 1388909;
 Wed, 12 Aug 2026 08:45:23 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu4aR-0005Ip-77
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 08:45:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu4aP-00DYEO-29
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:45:21 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c3297-bab6-0a2a0a5309dd-0a2a45039c18-18
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:45:20 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c32a0-fae8-0a2a45030019-d1558034c116-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 10:45:20 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4954aff6088so4138665e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 01:45:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c94f4c0sm29465275e9.8.2026.08.12.01.45.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 01:45:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786524320; x=1787129120; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=9kv5repWIREELK5z++PzLzQV26AoA6Wk+m6y/goKMkM=;
        b=Jpd/E1k1arWfpHwRNGM4xqRIRXyzh/oYAO5gOStk4GUoHG6rw3t/nbAx3ecFckdWfI
         /Hv4TlsBsJ5+pKZlSadJDt5TwJldrqjK7cU9y5xyJiHrdN3s2I3TfKLnxOVDXMlu4Tb4
         N+DFEIzj0GoDVreual2uZHhtBXmG6c/3LoeVgK9+tiNmf0kuHufohMP5OW2EcBlOYLo2
         NaIz5x9/X8w1LoO8lkHOA6KFJdS1okR0mkgviTT1okedqVZNtwKhI0XZnZcbi5Y6kbnV
         eTajusqxoQT+CRVRvJDYfB54An5SfGLgrP1WuEsvAGBOulDHest71YfA0fYJ3Kto3lgP
         2N3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786524320; x=1787129120;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=9kv5repWIREELK5z++PzLzQV26AoA6Wk+m6y/goKMkM=;
        b=BhaYwLyLSymNCEil0Ib5pmmjhTKSMTvklmiWmt0gmpyZRXUPoJcJj/pCPvuuCqNN9H
         hd5zd4f6rKOtXDi72i9CXNMHAdekTTLWzKeB/Dm2sYUyL3wrzJXnyEYsDD+IC0DDKsCF
         LUA6TB7m4EL7yRNGQ+4D7XgGFTrl380oZffVRkK8mo7eFOkvdJxbVnO1ValJp26CW6+n
         kGsWNeX4DJPcsXdLK9rkHsNU15J4b0E420Gb/tGKVqOha96yg3GmgYO0VVjPJyLTTMnH
         jR6DSiMCstp0vQ6GvmHV2Vr6IKnebcwkc6vmsIFKU/FqtnNc/8ipEWwmxdahgbK610o8
         P1uQ==
X-Gm-Message-State: AOJu0YzWcF7EuYFUF5xuma1arw2X+q7TCpeg5Kv/TPOI6FydI/UW+Mew
	0SY+NPVRLTgsjEgJBaYgKHWtrCedoYeG49X1j2jKWFR29K1Nff1a+uyJbopXQQ8SAg==
X-Gm-Gg: AR+sD11ZoOdrE7AKSs6NmqMbdeCn7jOII9fUN5G+Ge+wWp6BFUEsoJ2woYYrBmWzcYS
	MC/4gare+ttExwKZxb/ur0ZkxHbA9F+1JlDFO4KpSm2M7E3A8QlSOY5lnDxrTWKt9M9Uzb8VbJV
	RZAZqKRt4WJe/h04xjU0yzokjC8W98JDyuvhAF7W2Zlstxfb39n2ng3QE1AVTbVHcXje2obUFDR
	POJODSpjsvRAiIy+Tkvwrafr0iA4zgZ5p/FL35vxAasaDVulgB9+htTJ3xti+E+KrnvCOdF0L21
	tPno1gCZHr2Xyc3Or2oZdKJD6ron3F1lqSwqVptmayNHVnjdXE2dV0SewMbMkBCP1ZC50RU4G9N
	5J2syzLvI/nFQrQe7QdKNxNKw3u279hGfZ73/GwNRy8GG15id1EwTamLXp6EMN/EY4eLOV3YwI0
	gtegDhwBbR2t61QJVYq/001gApamZ0/mMciswGC33mIToeVKqRbYmQdpvTcS7CWT+Hja5BqJcsl
	cezT0zPZrJ2kwLhEz8XorRvqRZSLT5ELTb5LwY7w/MgJqe0UmVt
X-Received: by 2002:a7b:c7d1:0:b0:493:c634:952 with SMTP id 5b1f17b1804b1-4997c1192c0mr28620185e9.7.1786524320350;
        Wed, 12 Aug 2026 01:45:20 -0700 (PDT)
Message-ID: <023ffc4e-ac21-4220-996a-1b7eaa9f2467@suse.com>
Date: Wed, 12 Aug 2026 10:45:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] vvmx: Fix uninitialised writeback to vmcs12
To: =?UTF-8?Q?Johann_H=C3=B6pfner?= <hoepf@cit.tum.de>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Cc: xen-devel@lists.xenproject.org, Teddy Astie <teddy.astie@vates.tech>
References: <alfcosYs35pOCslN@cit.tum.de>
 <af5dfcaa-8da8-4bd2-ac30-24bc65e65a6e@suse.com> <anWa8ExGlrqsoxfN@cit.tum.de>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <anWa8ExGlrqsoxfN@cit.tum.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1786524320-6C4DF4E9-3DF89E4D/0/0
X-purgate-type: clean
X-purgate-size: 1574

On 07.08.2026 11:32, Johann Höpfner wrote:
> nvmx_handle_vmwrite leaves local eight byte variable 'operand'
> uninitialised to be written as an out-parameter by decode_vmx_inst. In
> cases where the operand to vmwrite is a 32 bit memory operand, the
> invokation of  hvm_copy_from_guest_linear leaves the upper half of
> *poperandS uninitialised. The resulting eight byte value is consequently
> written to the vmcs12 leaking the four uninitialised bytes into guest
> physical memory.
> 
> Initialize the stack-space passed to decode_vmx_inst to avoid this
> issue.
> 
> Fixes: 2b2793d3ae44 ("nEPT: handle invept instruction from L1 VMM")
> Fixes: d4c5b9db5a85 ("Nested VMX: Emulation of guest VMWRITE")
> Fixes: 9ccf55307868 ("nVMX: virutalize VPID capability to nested VMM")
> Signed-off-by: Johann Höpfner <hoepf@cit.tum.de>
> ---
> 
>> In any event - why don't you make your proposed change into a proper patch
>> (primary piece missing is your S-o-b, and perhaps we also would want a
>> suitable Fixes: tag)?
> 
> Sorry to have kept you waiting. Here is the formatted patch. I included
> the invvpid case still, though I believe only vmwrite remains after the
> patch you linked is merged, right?

I think so, yes. Andrew, Roger - any chance of coming to a conclusion on that
much earlier work [1]? Imo that wants to go in first, with the patch here then
shrunk to what's actually still needed (at which point only a single Fixes:
would be left as well).

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2025-06/msg01208.html


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 09:11:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 09:11:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388921.1629884 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4zE-0001PH-Mc; Wed, 12 Aug 2026 09:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388921.1629884; Wed, 12 Aug 2026 09:11:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu4zE-0001PA-Jp; Wed, 12 Aug 2026 09:11:00 +0000
Received: by outflank-mailman (input) for mailman id 1388921;
 Wed, 12 Aug 2026 09:10:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wu4zD-0001P4-6x
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:10:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu4zC-00DcLY-Fn
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 11:10:58 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c3895-bab6-0a2a0a5309dd-0a2a450ba200-30
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 11:10:58 +0200
Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c38a2-b7e8-0a2a450b0019-d155dd30a8e5-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 11:10:58 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-47db714766aso1144464f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 02:10:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c998f27sm30577495e9.15.2026.08.12.02.10.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 02:10:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786525858; x=1787130658; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=DDDJEp9uSsv7WptWGlF1JJxk9/apGRujVzFGqdWvcTY=;
        b=YoiSsaF7mMFGkGAP2cXe8AiPYFoASt8rxXsbybELX+uFgrmpEt/Cq9N5te0UHnxBXN
         SlpV2jpH9/kPAWLeF5CTDij0X8OnA2bv1uVuC5H73lxsUxskeUa0p6pQKAsSJ2Smoz2X
         9SZaErt9A+fO4DwqPlPOkRtGSkXUHTmQMC/vUgK4a6H6/f0eWE6rae23k3fRJ+6BPlpL
         DXcNnfukMnwQAerr1O2OoHlhZWPyX5ofV/1/OI8N6W5DRbDf1HbGOWgRYoyPIu1P7wkY
         N05ocfzTJDFmZyptAyz8yyNlZcdNSxCz8PDo/N5KFQtuO684oySoC1WsZ5qZVtBqBGRy
         Jzeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786525858; x=1787130658;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=DDDJEp9uSsv7WptWGlF1JJxk9/apGRujVzFGqdWvcTY=;
        b=TRf+BLB1kOguWwpBT2y0JPOPWG9vizRCZYUyoSbmWySXhRLpwbiIXRiN2KFBDgHOZq
         6saJrzZWmU0IwxALJLShcMRKP3C4lFArNO0hNut/9LoHOT5ZoQczQREzdUXQ0uCcix4K
         Xdoino27Oe8lQnTtkcbCPDvUni5K3ubymqzbwwzGVQhNIwUC5Fw81nxcDarytDPy90NE
         ZdbVf1KBrrHQDqoNa2s8PA1xFRxQhET8r8WCwppZtRdY814C+FpNImKNEqZ9ktJctddb
         N0sLNwXIQGw6y4K/VF1t1K2GRuLxRqIOpQ0wHBa1VkplCGIUz9x3T2aYR+MwCJbhfPns
         6rXA==
X-Forwarded-Encrypted: i=1; AHgh+RpoEWL6uAK7QULh98DeJSIRMnTULhOiUMa9i0m6HxtN6C1pgtQeIgc4Zqs3eCAA3idKSgTPsfO0KdU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJiEVZ9/nVq+bQbfjSv0eXQ8lVluvcgPPwVyVxI/3DH79U7mtP
	yJOOhf7kLSI9WA6A0wCajwRIU5R97bl1ofRcJXbsf4OcLOMfgSHeuVUmDWz/d58RzQ==
X-Gm-Gg: AR+sD10Pat53aDNbFxOKzujBp4UHYUnvoaYThBz/X80SrB2jxWMJoxkEHivJkm356nH
	4Usl5NfF0tez6eZxRtvPkk7OZBnZqFrXRRt8QJzN9mhv8ZTCalRh0iU372izYZJM0RiaKeE+ETL
	l8Dy+mws4goQjvfDztoqucz98QXdXbzh4mIlywV4sBryL4ymnJg8QUqUkcmJ71prWNucO1Qng6U
	iTJHM/GP7oVNFHyhRp4oWbbdxTN2fGzpatrNTFSmmCq9C45uHNV4u1cCJDA7v5qG+iNHaVbtwDj
	pDdcNXja1sbWNeJyGxXmg3fgSIN2NQo71z5Z25Cy1IwfojZAQe2Nm8p2A9h0KedD9oOl1KbKHY4
	y9KfAehIKA+550kuKW6FpOTSfaIdngh9V2nhUjP6jkTCkO5R+/f9e0mA6M05P05RQsBTovKrszF
	SoK/p7CrSXSzCYo6I3RWcLsQhaTamoq+fVlbbhK0we+U1/wnws4N7yB9JzUvGjpRoW3A0oP157R
	Hwc51IjtEg2EVdssuyE7+GewhAUb1ioRy72YyNkHxZhJz3fHOUH
X-Received: by 2002:a05:600c:3111:b0:499:51ea:fb59 with SMTP id 5b1f17b1804b1-4997c3f15ebmr33839115e9.4.1786525857495;
        Wed, 12 Aug 2026 02:10:57 -0700 (PDT)
Message-ID: <1415f794-2121-4534-9226-97479aa57623@suse.com>
Date: Wed, 12 Aug 2026 11:10:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786525858-ABAD09EA-D696CF80/10/73395122804
X-purgate-type: spam
X-purgate-size: 18216

On 07.08.2026 18:08, Oleksii Kurochko wrote:
> On 8/6/26 4:28 PM, Jan Beulich wrote:
>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>> 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 <Romain.Caritey@microchip.com>
>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>> ---
>>> Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech> # vaplic_mmio_{read,write}
>>
>> For this tag to have any meaning, it should move ahead of the --- above;
>> the explanations ...
>>
>>> The downstream changes related to `vaplic_mmio_{read,write}` were originally
>>> in a separate patch (which was reviewed by Baptiste). However, before
>>> upstreaming, it was decided to merge them into the current patch.
>>> I added `Reviewed-by: Baptiste` in this form for now, but Baptiste will
>>> probably review the remaining changes as well.
>>> Once that happens, I'll simply move the `Reviewed-by` tag up and
>>> remove the `#`.
>>
>> ... here rather explain the restriction on the R-b, not its odd placement.
>>
>>> ---
>>> Changes in v3:
>>
>> As this looks to be recurring - please get versioning of your series right.
>> The series is supposedly v1, but here you give the impression of it being
>> v3. If there really was an earlier v2 posting, why isn't the entire series
>> here v3?
> 
> It is v3 before before it was a part of another patch series connected 
> to dom0less config enablement.
> 
> Would it be better to just write in "Change in v3" that it is moved from 
> another patch series + link to that patch series? Or it will be enough 
> just to drop "Changes in v2 and v1" and just start from v1?

Which part of "never have versions go backwards" was unclear in my earlier
reply?

>>> --- a/xen/arch/riscv/aplic-priv.h
>>> +++ b/xen/arch/riscv/aplic-priv.h
>>> @@ -48,4 +48,6 @@ struct aplic_priv {
>>>    */
>>>   extern unsigned int guest_aplic_num_sources;
>>>   
>>> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, uint32_t base_val);
>>
>> PLease can you, before submitting, self-review your patches? I'm really
>> getting tired of having to repeatedly point out basic style issues, like
>> the overlong line here.
> 
> Sorry for that, I will write an extra checker for such cases to not miss 
> them.

Well, if there was a checker, many more people would like to use it.

>>> @@ -38,6 +39,60 @@ static struct intc_info __ro_after_init aplic_info = {
>>>       .hw_variant = INTC_APLIC,
>>>   };
>>>   
>>> +static unsigned long aplic_hart_field(unsigned long hartid)
>>> +{
>>> +    const struct imsic_config *imsic = imsic_get_config();
>>> +    unsigned int lhxw = imsic->hart_index_bits;
>>> +    unsigned int hhxw = imsic->group_index_bits;
>>
>> It extends to the other local variables here, but I'll use these two to
>> try to make my point: I'm struggling to associate the names with the
>> values they are set to. Likely "hxw" is an abbreviation of hart index
>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
>> in "hhxw"? By using hard to grasp names, you make it hard to actually
>> understand the subsequent expressions, in particular ...
> 
> The names it taken directly from AIA spec:
> 
> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low 
> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart 
> Index Width) for determining target addresses for MSIs is described 
> later, in Section 4.9.1.
> 
> The AIA specification interprets the machine-level hart index as a 
> combination of the **group index** (`g`) and the **hart index within the 
> group** (`h`), according to the following formulas:
> 
> ```
> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
> (2) h = machine-level hart index & (2^LHXW − 1)
> ```
> 
> (In our case, the machine-level hart index is equal to `mhartid`, i.e. 
> the hart index.)
> 
> For systems that use IMSIC groups, the IMSIC address layout is defined 
> by the following parameters:
> 
> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the 
> hart number within a group.
> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for 
> the group number.
> * `hhxs` (High Hart Index Shift): the bit offset of the combined 
> hart/group index field within the physical address.
> 
> To extract the group index, we first shift the address by `hhxs` so that 
> the group index bits are aligned, and then apply a mask derived from 
> `hhxw` to isolate those bits.
> 
> The hardware performs the same operation to extract the hart index from 
> the MSI address. However, in our case we already know which hart should 
> receive the interrupt (`hartid`), so there is no need to extract the 
> hart index from the base address. We only need to recover the group 
> index and combine it with `hartid` to construct the value expected by 
> the `target` register.
> 
>>
>>> +    unsigned int hhxs =
>>> +        imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;
>>> +    unsigned long tppn =
>>> +        imsic->msi[hartid].base_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
>>> +    unsigned long group_index =
>>> +        (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
>>> +        APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
>>> +
>>> +    return (group_index << lhxw) | hartid;
>>
>> ... these last two. As it stands, they may be easier to understand if
>> you didn't have the local variables at all, despite them then getting
>> textually longer.
> 
> With the explanation above, do the variable names make sense?

Yes and ...

> To be closer to AIA spec I think it would be better to rename 
> group_index to g and hart_id to h. Does it make sense to you?

... yes. Question is whether you want to help readers who aren't that
familiar with the AIA spec. If so, maybe add [brief] comments making 
clear what the names say? E.g.

    /* High Hart Index Shift */
    unsigned int hhxs =
        imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;

>>> --- a/xen/arch/riscv/include/asm/aplic.h
>>> +++ b/xen/arch/riscv/include/asm/aplic.h
>>> @@ -28,6 +28,8 @@
>>>   #define APLIC_DOMAINCFG_BE      BIT(0, U)
>>>   
>>>   /* sourcecfg register fields */
>>> +#define APLIC_SOURCECFG_D       BIT(10, U)
>>
>> As to the comment - this indeed looks to be a field, but ...
>>
>>>   #define APLIC_SOURCECFG_SM_INACTIVE     0x0
>>>   #define APLIC_SOURCECFG_SM_DETACH       0x1
>>>   #define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
>>
>> ... these look to be values of some other field which isn't described. Please
>> may I (again) ask that definitions are their commentary at the very least not
>> misguide readers?
> 
> Thanks for pointing this out. You're right, the comment is misleading as 
> written. APLIC_SOURCECFG_D is a field, whereas the APLIC_SOURCECFG_SM_* 
> definitions are values for the source mode (SM) field, and the comment 
> doesn't make that distinction.
> 
> I'll update the comments to describe the fields more accurately:
> 
> #define APLIC_SOURCECFG_BASE            0x0004
> #define APLIC_SOURCECFG_LAST            0x0ffc
> /*
>   * sourcecfg[] register fields:
>   *  - bit 10 (D) selects the layout of the remaining bits;
>   *  - D = 1: bits [9:0] hold the Child Index, i.e. the source is delegated
>   *           to a child domain (unsupported by Xen);
>   *  - D = 0: bits [2:0] hold the source mode SM (WARL).
>   */
> #define  APLIC_SOURCECFG_D              BIT(10, U)
> /* SM field values (0x2 and 0x3 are reserved): */
> #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
> 
> Does it look better? Probably there is not sense for two extra spaces 
> for APLIC_SOURCECFG_SM_*. I want to show by such identation that it is 
> values for SM field of APLIC_SOURCECFG.

Which is fine. All you need to add then is a field definition for the SM
field. Then the extra padding blank will also start to make sense.

>>> --- a/xen/arch/riscv/include/asm/imsic.h
>>> +++ b/xen/arch/riscv/include/asm/imsic.h
>>> @@ -40,6 +40,16 @@ struct imsic_config {
>>>       /* Base address */
>>>       paddr_t base_addr;
>>>   
>>> +    /*
>>> +     * MSI Target Address Scheme
>>> +     *
>>> +     * XLEN-1                                                12     0
>>> +     * |                                                     |     |
>>> +     * -------------------------------------------------------------
>>> +     * |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
>>> +     * -------------------------------------------------------------
>>> +     */
>>
>> And the xxx-es in here mean what exactly? Don't care? Some other, unrelated
>> values? Yet something else?
> 
>   The `x` bits denote address bits that are constant across all IMSIC 
> interrupt files. They are not used to encode the group, HART, or guest 
> index; instead, they correspond to the fixed portion of the IMSIC 
> address determined by the platform's memory map.
> 
> For example, consider the IMSIC DT binding:
> 
>      interrupt-controller@28000000 {
>        compatible = "qemu,imsics", "riscv,imsics";
>        interrupts-extended = <&cpu1_intc 9>,
>                              <&cpu2_intc 9>,
>                              <&cpu3_intc 9>,
>                              <&cpu4_intc 9>;
>        reg = <0x28000000 0x2000>, /* Group0 IMSICs */
>              <0x29000000 0x2000>; /* Group1 IMSICs */
>        interrupt-controller;
>        #interrupt-cells = <0>;
>        msi-controller;
>        #msi-cells = <0>;
>        riscv,num-ids = <127>;
>        riscv,group-index-bits = <1>;
>        riscv,group-index-shift = <24>;
>      };
> 
> 
> Here, `hart_index_bits = 2` (4 CPUs) and `guest_index_bits = 0`, so the 
> address layout becomes:
> 
> 31          25 24 23         14 13 12 11          0
> +-------------+-+-------------+-----+-------------+
> | constant    |G|  constant   |HART |    zeros    |
> +-------------+-+-------------+-----+-------------+
> 
> 
> I can update the comment to say:
> "x denotes bits that are constant across all interrupt file addresses."
> 
> or, if you think it's clearer: "x denotes bits whose values are 
> platform-defined and common to all interrupt file addresses."
> 
> Does it make sense any of suggested options?

Either comment is fine imo. What I'd like to suggest is to not use 'x' then,
but e.g. 'c'.

>>> --- a/xen/arch/riscv/vaplic.c
>>> +++ b/xen/arch/riscv/vaplic.c
>>> @@ -17,6 +17,7 @@
>>>   #include <asm/aia.h>
>>>   #include <asm/imsic.h>
>>>   #include <asm/intc.h>
>>> +#include <asm/mmio.h>
>>>   #include <asm/vaplic.h>
>>>   
>>>   #include "aplic-priv.h"
>>> @@ -27,6 +28,256 @@ unsigned int __ro_after_init guest_aplic_num_sources;
>>>   
>>>   #define FDT_VAPLIC_INT_CELLS 2
>>>   
>>> +#define AUTH_IRQ_BIT(d, irqn) ( \
>>> +    ((irqn) < (d)->arch.vintc->nr_virqs) && \
>>> +    test_bit(irqn, (d)->arch.vintc->used_irqs) )
>>
>> Nit: Indentation.
> 
> I will use the following indentation:
> 
> ... (((irqn) < (d)->arch.vintc->nr_virqs) && \
>       test_bit(irqn, (d)->arch.vintc->used_irqs))

Which as written still doesn't look right. What I can't tell is whether
that's merely because of the use of "...".

Of the three opening prarens on the first line, two have their closing
counterparts on the same line. There's thus one pending closing paren,
meaning there should be one extra indenting blank.

>>> +/*
>>> + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to
>>> + * a 32-bit word index into the allocated_irqs bitmap.  Each word covers 32
>>> + * interrupt sources.  For SOURCECFG and TARGET groups the same division also
>>> + * 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 inline uint32_t generate_auth_mask(const struct domain *d,
>>> +                                          unsigned int word_idx)
>>> +{
>>> +    unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
>>> +
>>> +    if ( word_idx >= DIV_ROUND_UP(d->arch.vintc->nr_virqs,
>>> +                                  sizeof(uint32_t) * BITS_PER_BYTE) )
>>> +    {
>>> +        dprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx);
>>
>> Is this really meant to stay?
> 
> For debug purpose it could be useful, so I prefer to have it with 
> changing it to gprintk(XENLOG_DEBUG, ...) to understand which domain is 
> trying to access something wrong.

gdprintk() implies you're on the vCPU that's the subject of the operation.
If that's always the case here, the function parameter wants to reflect
that as far as possible: "currd" instead of "d".

>>> +        return 0U;
>>> +    }
>>> +
>>> +    return (uint32_t)(d->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >>
>>> +                      (first_bit % BITS_PER_LONG));
>>
>> I don't quite understand the need for the cast.
> 
> Functionally it isn't need but it documents that it is expected that 
> translation from unsinged long  to uint32_t will happen. I will drop the 
> cast.

Thanks. If you really wanted such doc, casts would need adding in many
more places across the code base.

>>> +        if ( !target_vcpu )
>>> +        {
>>> +            dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n");
>>> +
>>> +            /* Ignore such writings */
>>> +            return 0;
>>> +        }
>>> +
>>> +        value = aplic_msi_target_gen(target_vcpu, value);
>>> +
>>> +        break;
>>> +    }
>>> +
>>> +    case APLIC_SETIPNUM:
>>> +    case APLIC_SETIPNUM_LE:
>>> +    case APLIC_CLRIPNUM:
>>> +    case APLIC_SETIENUM:
>>> +    case APLIC_CLRIENUM:
>>> +        if ( !value || !AUTH_IRQ_BIT(d, value) )
>>> +            return 0;
>>> +
>>> +        break;
>>> +
>>> +    case APLIC_DOMAINCFG:
>>> +    {
>>> +        struct vaplic *vaplic = to_vaplic(v->domain);
>>> +
>>> +        /*
>>> +         * The domaincfg register has this format:
>>> +         * bits 31:24 read-only 0x80
>>> +         * bit 8      IE
>>> +         * bit 7      read-only 0
>>> +         * bit 2      DM (WARL)
>>> +         * bit 0      BE (WARL)
>>> +         *
>>> +         * The most interesting bit for us is IE(Interrupt Enable) bit.
>>> +         * At the moment, at least, Linux doesn't use domaincfg.IE bit to
>>> +         * disable interrupts globally, but if one day someone will use it
>>> +         * then extra actions should be done.
>>> +         *
>>> +         * Only DM (bit 2) and IE (bit 8) are writable here. They are assigned
>>> +         * (not OR-ed) so that a write of 0 can also clear them (WARL), and the
>>> +         * read-only high byte (0x80) is always kept set on read-back.
>>> +         */
>>> +        if ( value & ~(APLIC_DOMAINCFG_RO | APLIC_DOMAINCFG_DM |
>>> +                       APLIC_DOMAINCFG_IE) )
>>> +            printk_once("%s: Ignore writes to non-writable domaincfg bits as "
>>> +                        "they are set by aplic during initialization in Xen\n",
>>> +                        __func__);
>>> +
>>> +        vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO |
>>> +                                 (value & (APLIC_DOMAINCFG_DM |
>>> +                                           APLIC_DOMAINCFG_IE));
>>> +
>>> +        return 0;
>>> +    }
>>> +
>>> +    default:
>>> +        goto fail;
>>
>> Instead of this goto, I think you simply want to move the label here.
>> That'll also make the function more similar to its load counterpart.
> 
> Good point. I am curious how fail label should be aligned:
> 
>      default:
>   fail:
>          gdprintk(XENLOG_WARNING,
>                   "Unhandled APLIC write at offset %#x (value %#x)\n", 
> offset,
>                   value);
> 
>          return rc;
>      }
> 
> or default:
>      fail:
> 
> ?

Neither. Labels inside switch() should be indented to same as the
case labels there.

>>> @@ -105,6 +356,50 @@ static const struct vintc_init_ops __initconstrel init_ops = {
>>>       .make_domu_dt_node = vaplic_make_domu_dt_node,
>>>   };
>>>   
>>> +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, mmio_info_t *info,
>>> +                                               register_t *r)
>>> +{
>>> +    uint32_t data = 0;
>>> +
>>> +    if ( info->len != sizeof(uint32_t) ||
>>> +         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
>>> +    {
>>> +        gdprintk(XENLOG_DEBUG,
>>> +                 "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n",
>>> +                 info->gpa, info->len);
>>
>> You have v passed in here, but you'd log current. If passing in v is
>> necessary (i.e. here or elsewhere it may be other than current), then you
>> need to either ASSERT(v == current) at the top of the funciton or otherwise
>> handle v != current correctly.
> 
> It makes sense. I will add ASSERT(v == current) here and for 
> vaplic_mmio_write().

And then further rename the parameter to "curr", please.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 09:16:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 09:16:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388929.1629893 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu54W-00022U-D9; Wed, 12 Aug 2026 09:16:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388929.1629893; Wed, 12 Aug 2026 09:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu54W-00022M-9V; Wed, 12 Aug 2026 09:16:28 +0000
Received: by outflank-mailman (input) for mailman id 1388929;
 Wed, 12 Aug 2026 09:16:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu54U-00022G-SJ
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:16:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu54T-00EcGs-Gu
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 11:16:25 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c39e5-8faa-0a2a0a5109dd-0a2a4504bade-8
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 11:16:25 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c39e9-b57f-0a2a45040019-d155dd32b445-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 11:16:25 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47ffaa8ebbdso577865f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 02:16:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815231c308sm5088833f8f.11.2026.08.12.02.16.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 02:16:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786526185; x=1787130985; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qHjaQpQzkOp5xRhsMS4c1VoBQI2rizbhVyY6r7Ed/rE=;
        b=YlZlIr1ww8PFiFNuj14zPD86om3nO7Ym7UPg8G1Oq1pI5VnKKSIVEK8wFyf3b0Fho1
         fsdpdhHzTJpNZ3eYEc0XpCly0vMx26GqQ1umwQIOMWBHWkJzFfhJNI2uSWr2uvDUUpzY
         PoDO8HA4A/QFm4Azc959Ap6Swb6x35s1pXWe00IhMouC/SP19xejLOB/V5dnoxBEAOGd
         7EY4Ly5O7gZ4HPOUKIUZ5S+g2YvMrB7sGgjnzpRx0iN/Nd1ux5D7NJLks6ImhTdCGGBy
         SbDgcfRmEz+iBxeq88ZpIDoe81bFuMb9TUEdZrYR00KMgNvPfJY5Xvre75QXTqPvhIvC
         EnRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786526185; x=1787130985;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=qHjaQpQzkOp5xRhsMS4c1VoBQI2rizbhVyY6r7Ed/rE=;
        b=INq/q5dNrn+lSPiTvk0zszVWrcrT2cHPwl1bLeAz7HjufmtCfpSIQ1i67ZiHs1/EJ5
         qGWtpQfquWVwWKG3/74Sny3xVNHD15TAK+3pYWVnl4qCsO/TTG0gzoyEaKYqkGsfeWdw
         4o8R/lI3TmZv9QGLp7ZbfHxsod+H2kYgNoRgnW+A9N0sIIvFri68uBJj8e4zIgnIezyU
         oRUIH7F3/GxHob1tWM7RIVoX1Jxaj7VjjkZWFkVmBlKALBA/5pvPw6mWr7p/b7ecTBUE
         ASG+uYKPG5p4iQEq1TQr2awUg/C5CV8TGikVRS4bex+DuU1pCJcjmoAh2PP9b0hSpMyv
         nrgw==
X-Forwarded-Encrypted: i=1; AHgh+Rr/8cS57LezjAcHSHRuZz3zgjUI3uRVpf4GbLJftKjikiu+Kme2LJSlNBIcYAgFUcn1qvDihUnOyXY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yydvvripi46RXjKSr0Ko9CMd1TBWz9RoyX2zWExUgwvcXBL7m6T
	uSvjiqDLHWmExOdNgou5kVZutZBGp64waSgqMvQQXHSzMjxzfvPy6hm/oWc5xkvVtw==
X-Gm-Gg: AR+sD11rjJhKTBhnycdXGVINQLcAlFqNy78bxPGcDkfThxNshLyuvPBhDbh3crZRJCT
	xnXre1uJwSNbm8Q13IbDur1A0J73R1Ny7mf7nk+Y4l5PxRnLbuVRBYKyMCs12t6f6iCdJBIKfmD
	55HGO3ArVkmqATc8tMObms276S4cqU7j2q9C5tPc+ELU4Z+bC1MFcJamJ7UC3L8twKF6+0t5vAX
	GbEt3bPJgc28EhRfdfSS21yp9bkSco3qTQbyGgA3j/uicKY6a3pD3N25Fs4JC4FUmin7e+QpMsj
	cti0i2bKSlOCTDBUeZpXgRQrhOfx+HnoCqYs40+s+E/fhxgoxzcQtDSzEsOIoEk1bCQMPEaJx14
	2SetlAUjeRf4P27FIaskWYr+obKSqsIFUPLE5Y5eNKV4DElYIyTDuFD4peifhXHDsMaIyBamybn
	hpUruS2jCF8s0lYm0rAaF7D9fsgeNc6JleLjd2LnXS3Bk++KLBHt6NkbZ0BUOel534WS6yzTPUj
	6LclkmZm7cb9tbN5SxK2obobw+niKUA3WhC/YNnsuGfhJeH7jI3zK8xNDciAeg=
X-Received: by 2002:a05:6000:1868:b0:47f:6f89:7dae with SMTP id ffacd0b85a97d-481528abe33mr4530880f8f.6.1786526184791;
        Wed, 12 Aug 2026 02:16:24 -0700 (PDT)
Message-ID: <134445c8-b62c-4db4-881a-fdec9545f780@suse.com>
Date: Wed, 12 Aug 2026 11:16:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
 <dda2f05b-2965-4fff-92d9-326619be313b@suse.com>
 <2071e8f2-4994-4b8f-affb-999376250e35@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <2071e8f2-4994-4b8f-affb-999376250e35@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1786526185-50CDFB50-6A3A7B10/0/0
X-purgate-type: clean
X-purgate-size: 1567

On 10.08.2026 10:50, Oleksii Kurochko wrote:
> On 8/6/26 4:48 PM, Jan Beulich wrote:
>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>> +#ifdef IMSIC_DEBUG
>>> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
>>> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
>>> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
>>> +#endif
>>> +
>>> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
>>> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
>>> +                           arch_dt_passthrough_p2m_type());
>>> +    if ( res )
>>> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",
>>> +               __func__, paddr, gaddr);
>>
>> I think you mean to use PRIpaddr with paddr_t (oddly enough there's no
>> PRIgaddr).
> 
> I’m wondering if it wouldn’t be better to use paddr_t for gaddr as well, 
> since technically it is a guest *physical address*. In that case, 
> PRIpaddr could be used to print both paddr and gaddr variables.
> 
> Also, could this be the reason why PRIgaddr doesn’t exist? Basically, a 
> GPA could be considered a physical address, while for a GVA there is 
> already PRIvaddr.

Well. There's nothing wrong with guest {physical,virtual} addresses to be
a different width compared to the host's. They could be both smaller and
(in principle) larger. As long as higher-bitness guests can't be run on a
smaller-bitness hypervisor, using paddr_t for gaddr-s is okay(ish).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 09:47:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 09:47:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388943.1629901 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu5YW-0006dm-Kd; Wed, 12 Aug 2026 09:47:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388943.1629901; Wed, 12 Aug 2026 09:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu5YW-0006df-I6; Wed, 12 Aug 2026 09:47:28 +0000
Received: by outflank-mailman (input) for mailman id 1388943;
 Wed, 12 Aug 2026 09:47:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3@swg.vates.tech>)
 id 1wu5YV-0006dZ-4g
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 09:47:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu5YS-00Eik2-VG
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 11:47:24 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3@swg.vates.tech>)
 id 6a7c4124-2eae-0a2a0a5409dd-0a2a450191be-34
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 11:47:24 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3@swg.vates.tech>)
 id 6a7c412c-5984-0a2a45010019-b9ff1c239de3-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 11:47:24 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ff55e8fe5000c4f3.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 12 Aug 2026 09:47:22 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id F22E9836B2;
 Wed, 12 Aug 2026 11:47:21 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=lBBTfUn9Euh+z+pnSqRcMl9GQyCOW77PRGjEAM5p6RI=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=rqBBKAQimLIdrYESHe70CVPJ3IQvFzla25EWkqTpJpjBauDQw8i+g3GP6kzSwwKJ5Jzie7xpj
 VPR6AzYHjuGgc8eeWd0s76Ka9ikkN7fLzFPY9l1zHPggJ7FHcqWtca7iDrLRdDNRRpFD6vIVk5w
 IFeQqWpPrXEaX5huVxBYe4Pimy+MoxKBed1eStK77VioZiGIDH7GimI0XhEKOwgd1+T7WJIRGrc
 hDxNmoNahO+IHroEV/jFVlrIdCcfDj2bWykGYRuzbGVRsNJNHgvtfJQcw2DrpfhUuqZRvmQ6BYN
 XGDsGK3tM3N3zSwS81e8wH6OgI01BrA8AnX8nieNTung==
X-Zone-Loop: a4165564679c28a40f7570aba4222eceb3f33ce41801
x-campaign-type: default
x-transaction-id: 8d08062b-c3c1-4121-9648-c10155e956cd
x-swg-uid: 01-3ee3b128-76fb-4b71-8799-a8e9d8466732
X-Mailer: Sweego
Message-ID:
 <1786528043.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3@vates.tech>
x-swg-bid: 1786528043.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Jan Beulich <jbeulich@suse.com>, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
In-Reply-To: <70560c6e-17dd-4524-919b-1dad9c774bee@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
 <2187839d-fef8-4d51-8b98-8c0fb26a9569@gmail.com>
 <1786462177.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@vates.tech>
 <70560c6e-17dd-4524-919b-1dad9c774bee@gmail.com>
Date: Wed, 12 Aug 2026 11:47:16 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786528041; l=13828;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=j/SK8+oLvtpILmiogrpZTWfN59gT5pnOrPTbbx6Kjlo=;
 b=ghyYdy8i54HCdAnuh/I5ZvQsm8jfMMpKdBGE44VNWP4LkqD+zzXvp3nuv2Bbh6KYDAh2RhnFh
 rBeo3x2rXJeAjGAqCcFoXtg46g7JrBU3HDvEB8oF1Ozf319woUy8ZjH
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786528042219
X-purgate-ID: tlsNG-d62444/1786528044-1E867757-74260A34/0/0
X-purgate-type: clean
X-purgate-size: 13832

On 2026-08-11 18:24 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/11/26 5:29 PM, Baptiste Le Duc wrote:
> > On 2026-08-11 16:36 +0200, Oleksii Kurochko wrote:
> >>
> >>
> >> On 8/11/26 11:21 AM, Baptiste Le Duc wrote:
> >>> On 2026-08-07 18:08:21+02:00, Oleksii Kurochko wrote:
> >>>> On 8/6/26 4:28 PM, Jan Beulich wrote:
> >>>>
> >>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
> >>>>>
> >>>>> For this tag to have any meaning, it should move ahead of the --- above;
> >>>>> the explanations ...
> >>>>>
> >>>>>
> >>>>> ... here rather explain the restriction on the R-b, not its odd placement.
> >>>>>
> >>>>>
> >>>>> As this looks to be recurring - please get versioning of your series right.
> >>>>> The series is supposedly v1, but here you give the impression of it being
> >>>>> v3. If there really was an earlier v2 posting, why isn't the entire series
> >>>>> here v3?
> >>>>
> >>>> It is v3 before before it was a part of another patch series connected
> >>>> to dom0less config enablement.
> >>>>
> >>>> Would it be better to just write in "Change in v3" that it is moved from
> >>>> another patch series + link to that patch series? Or it will be enough
> >>>> just to drop "Changes in v2 and v1" and just start from v1?
> >>>>
> >>>>> PLease can you, before submitting, self-review your patches? I'm really
> >>>>> getting tired of having to repeatedly point out basic style issues, like
> >>>>> the overlong line here.
> >>>>
> >>>> Sorry for that, I will write an extra checker for such cases to not miss
> >>>> them.
> >>>>
> >>>>> It extends to the other local variables here, but I'll use these two to
> >>>>> try to make my point: I'm struggling to associate the names with the
> >>>>> values they are set to. Likely "hxw" is an abbreviation of hart index
> >>>>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
> >>>>> in "hhxw"? By using hard to grasp names, you make it hard to actually
> >>>>> understand the subsequent expressions, in particular ...
> >>>>
> >>>> The names it taken directly from AIA spec:
> >>>>
> >>>> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low
> >>>> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart
> >>>> Index Width) for determining target addresses for MSIs is described
> >>>> later, in Section 4.9.1.
> >>>>
> >>>> The AIA specification interprets the machine-level hart index as a
> >>>> combination of the **group index** (`g`) and the **hart index within the
> >>>> group** (`h`), according to the following formulas:
> >>>>
> >>>> ```
> >>>> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
> >>>> (2) h = machine-level hart index & (2^LHXW − 1)
> >>>> ```
> >>>>
> >>>> (In our case, the machine-level hart index is equal to `mhartid`, i.e.
> >>>> the hart index.)
> >>> Therefore, if I understand correclty, if we take the Hart Index as
> >>> defined in the AIA spec, we should have:
> >>> Hart Index = (g << LHXW) | h
> >>> Is it correct?
> >>
> >> Yes.
> >>
> >> But note that in the current version of aplic_hart_field(), hart_id is
> >> passed directly, so there is no need to extract h as described in the
> >> AIA specification. We only need to concatenate it with the group index
> >> that we have already extracted.
> >>
> >> This is partly because aplic_hart_field() uses only .base_addr, which
> >> does not contain hart_index.
> >>
> >> If we want to follow the AIA specification fully, using its terminology,
> >> the code should look something like:
> >>
> >> static unsigned long aplic_hart_field(unsigned int cpu)
> >> {
> >>       const struct imsic_config *imsic = imsic_get_config();
> >>       const struct imsic_msi *msi = &imsic->msi[cpu];
> > Could you please specify how this function will be used and when? It's
> > hard for me to understand how imsic->msi[cpu] is filled.
> 
> imsic->msi[] is filled during IMSIC initialization in imsic_init(), 
> based on the MMIO regset specified in the IMSIC node’s reg property and 
> the number of parents specified in the interrupts-extended property. 
> This is explained to some extent in the comment above local target_addr 
> in aplic_hart_field() (a little further down).
> 
> I am not 100% sure that I fully understand the connection between your 
> question and the sentence after it, but I planned to write the following 
> above the function declaration:
> 
> 
> /*
>   * The arrangement of IMSIC interrupt files in MMIO space follows a 
> topology
>   * 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|Group Index|xxxxxxxx|Hart Index|xxxx|Guest Index|     0     |
>   * -------------------------------------------------------------------
>   *
>   * - xxxx: the remaining bits of the Base PPN. The specification 
> requires the
>   *   Base PPN to have zeros in the positions where the indices are OR-ed.
>   * - Group Index (g): placed at bit (HHXS + 24) of the physical address.
>   * - Hart Index (h): placed at bit (LHXS + 12) of the physical address.
>   * - 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.

I think the name `Hart Index` is confusing here. In fact, you previously
confirmed it refers to target[i] bits 31:18, i.e. the packed number
(g << LHXW) | h, but here you say `Hart Index` is equivalent to h, which
makes no sense.

I know this diagram came from Linux (Anup Patel, Nov 2022,
https://lore.kernel.org/all/20240307140307.646078-3-apatel@ventanamicro.com/),
where "HART Index" is simply the name of the riscv,hart-index-bits DT
property. Linux's own APLIC driver then reuses a single hart_index
variable for h and for (g << LHXW) | h in consecutive lines, without a
comment, which is confusing - if I understand correctly, obviously :)

I think this diagram could be better aligned with the AIA spec:

    * 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.

What do you think? It would allow us to keep a single meaning for the
`Hart Index` field, the same one as target[i] bits 31:18 i.e. (g <<
LHXW) | h.

>   * - Bits 11:0: always zero because IMSIC files are 4 KiB page-aligned.
>   *
>   * For wired interrupts in MSI delivery mode (domaincfg.DM = 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 
> number
>   *   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 
> domain
>   * 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-defined
>   * Hart Index format to ensure correct MSI targeting.
>   */
> 
> Does it answer your question?
> 
> >>       unsigned int lhxs = imsic->guest_index_bits;
> >>       unsigned int lhxw = imsic->hart_index_bits;
> >>       unsigned int hhxw = imsic->group_index_bits;
> >>       unsigned int hhxs =
> >>           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
> >> address.
> >>        */
> >>       paddr_t target_addr = msi->base_addr + msi->offset;
> >>       unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
> >>       unsigned long group_index =
> >>           (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
> >>           APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
> >>       unsigned long hart_index =
> >>           (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) &
> >>           APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);
> >>
> >>       return (group_index << lhxw) | hart_index;
> >> }
> >>
> >> (note that during writing that I found an issue, it should be really
> >> passed Xen cpu id, not hartid as msi[] is iterated through Xen cpu id so
> >> I've taken that into account when wrote an implementation mentioned above)
> >>
> >> Generally I think I am okay with both version of how to get hart_index
> >> (or pass it by an argument or extract it).
> >>
> >>>>
> >>>> For systems that use IMSIC groups, the IMSIC address layout is defined
> >>>> by the following parameters:
> >>>>
> >>>> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the
> >>>> hart number within a group.
> >>>> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
> >>>> the group number.
> >>> Is group number appelation equivalent to group index?
> >>>
> >>> I think with if what I wrote above is correct, the proper definition for
> >>> `hhxw` and `hhxs` should be:
> >>> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
> >>> the `Hart Index` field within the physical address.
> >>>> * `hhxs` (High Hart Index Shift): the bit offset of the combined
> >>>> hart/group index field within the physical address.
> >>> * `hhxs` (High Hart Index Shift): the bit offset of the `Hart Index`
> >>> field within the physical address.
> >>>> To extract the group index, we first shift the address by `hhxs` so that
> >>>> the group index bits are aligned, and then apply a mask derived from
> >>>> `hhxw` to isolate those bits.
> >>>>
> >>>> The hardware performs the same operation to extract the hart index from
> >>>> the MSI address. However, in our case we already know which hart should
> >>>> receive the interrupt (`hartid`), so there is no need to extract the
> >>>> hart index from the base address. We only need to recover the group
> >>>> index and combine it with `hartid` to construct the value expected by
> >>>> the `target` register.
> >>>
> >>> Why don't we direclty extract the Hart Index as target directly needs it
> >>> as explained in the 4.5.16.2 point of the AIA spec:
> >>> target[31:18] = Hart Index
> >>> target[17:12] = Guest Index
> >>> target[10:0] = EEID
> >>> It'd be easier as we just have to do shift from HHXS and apply HHXW.
> >>
> >>   From IMSIC's DT-binding description we have:
> >>
> >>     XLEN-1            > (HART Index MSB)                  12    0
> >>     |                  |                                  |     |
> >>     -------------------------------------------------------------
> >>     |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
> >>     -------------------------------------------------------------
> >>
> >> If you see there is a set of "xxxxxx" between HART and Group Indexes
> > I think I'm missunderstanding the spec, as I wrote before I thought that
> > [1] `Hart index` = group_idx << LHXW | hart_idx_within_the_group so,
> > does the Hart Index in the schema refer to hart_idx_within_the_group or
> > to [1]? The naming makes me a bit confuse.
> 
> Could you please check my comment above and if it doesn't provide answer 
> to your questions I will try to explain it differently.
>
>
> 
> >> that is the reason why we have to extract HART and Group Index
> >> separately as when h/w will work with target register it doesn't know
> >> about "xxxxx" at all so from h/w point of view target's register hart
> >> field looks like |Group Index|Hart Index|. In other words, h/w will do
> >> the following with TARGET's hart index field:
> >>       group_idx = hart_idx >> lhxw;
> >>       hart_idx &= APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw);
> >>
> >> and then embed group_idx and hart_idx into the structure above.
> >>
> >> Does it make sense?
> >>
> ~ Oleksii
> 
> 




From xen-devel-bounces@lists.xenproject.org Wed Aug 12 10:05:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 10:05:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388961.1629934 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu5pa-0001WQ-7b; Wed, 12 Aug 2026 10:05:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388961.1629934; Wed, 12 Aug 2026 10:05:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu5pa-0001WJ-51; Wed, 12 Aug 2026 10:05:06 +0000
Received: by outflank-mailman (input) for mailman id 1388961;
 Wed, 12 Aug 2026 10:05:04 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wu5pY-0001WD-8Z
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:05:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu5pX-00C3gn-LL
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 12:05:03 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c4549-8faa-0a2a0a5109dd-0a2a4504d8c8-24
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 12:05:03 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c454e-b57f-0a2a45040019-d155802ab85e-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 12:05:02 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so8512555e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 03:05:02 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997aa3ebe0sm69339105e9.0.2026.08.12.03.05.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 03:05:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786529102; x=1787133902; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=F+bljBm+4VlGqIEjXcnjNEmRLgnVTkLfgoLXsNQ0/UQ=;
        b=leLt8BxCB3VsJyjTD1PywKqZ6d/rxf701Sf/p6/e1TIsshqqTI6KqHNReqLcc8UuSj
         EuqGuRI+T6naTQyWPOTObJG3nzUTMCLNOHZd3A/iMSuB/f2wmOG9PgTvlalzECiFSVxM
         PTVDKLcs/sJHStpkkNKjuasaUywz9h8DPAd+vC8qOpW0JJToiDAXGe7N2ewRM3NUlRSS
         MCb/7JMwMr26ls/FWl5F9jIW9Pzy9PZCYFQ2e04en1aWu0Y74etBTaMSRJZZ4wbEkgcL
         mTJ7VAFcWHupTZJXeNG2Wn6DwZ1+9XD57sVwHDpvGeySP4RWI1FbO5nBt0O+SvhVJFOM
         EcEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786529102; x=1787133902;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=F+bljBm+4VlGqIEjXcnjNEmRLgnVTkLfgoLXsNQ0/UQ=;
        b=Oe+iZx9wKoD0E30tC4NxwrJdKgxHL4OlMvi7tmmsw9QdebuIozyZFjofXvQFJLtnNw
         4jxQem3UVT1NzJeKWwZnKBf00dgzf5aJC/lD4/1xCnJFk1iGWxdCU7Fi3kY3RHJcCU48
         CT3E3e2RvYdqpxQn64zSv7zgwfC1l1qctjFbeL5z97paDzxFbj3MUAuaDDrIu0jL51dg
         dQrq0mjDj8DD9kDM4rPPIzRBAm3Jd3JZH3cFc6yo9bMOA0CImrlyQbBAWEishxoBpEhC
         ncfyWuFUIZ21kRAE0fzMGojv+aZy/mx976bjLGZNjyND6SIowgjy9AHKUMdXCYKyo8d/
         cvkw==
X-Forwarded-Encrypted: i=1; AHgh+RpaqV4Rhhyrv4sfJafYo46AFADHOw/YEmkhuKyk2YPvCd/E2YZbsf51dkbTaHEolHPgXQx6uzR+OFc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgdGQrxdP1rXbFjOZ90ijWyObWQgIxH4CdbXm9duW94lVyqqXk
	YLb7H1Cf1cQ0a2Y8tko8S3PwUjX7ej6Qcj4NCAU7VbI0Z1bdTR38P5CR
X-Gm-Gg: AR+sD13RanXjXPc1TMXj0b+Tq5h4mzNPoNEX5+ZezMexzPwx8ydxno5Sr4c0mIW35NW
	Y49PpIMuIY8rr/wjGoe9cyWdEtkV7vNRdPEwkPQlsiaPHMGMe0MJAoAhzwVLdE6KxYvT0yviqz1
	c+gcBLdG3ghLjdELtinABa3C8KvXuu2VxRCpARQlGOD+0476Gnw6TmxL3+VY9ttI5r1IGQRn/GA
	mawNURLFIKt1s58RyxQqYLdDJNwQ1HCpRl+ZeqROuWIbWyVVPYu0zXa0KXXprBIn8xdX274mSyI
	+tBkU3aTr0MgyXsWV3qP2PMAzTVl/tEhc9diYqvAV4lZ4sGzjlbrVSnw7r1iUYC1vcgAdGvr6cV
	X0jzwCg20SXhXmSf9Yfpkyj8aer5OAaihctdr3k6IzlngueEOdop3CR+EHrydBPMM5V1ueSL+ek
	RvT71kw9tXyL4AMTvsRP0imgUW4RryiiG4xJZ4Tf+p/qRxvcfrMYRap3/FVPmwbqWd9NHmjtt0l
	iDC1QfbdlrE7ALmQIEK1zfBbrSe62BhxjgGuo7pvV0=
X-Received: by 2002:a05:600c:6305:b0:495:6396:8b67 with SMTP id 5b1f17b1804b1-4997c0d7658mr40977495e9.4.1786529102063;
        Wed, 12 Aug 2026 03:05:02 -0700 (PDT)
Message-ID: <69c57858-221c-4abc-8989-a7828353dc0f@gmail.com>
Date: Wed, 12 Aug 2026 12:05:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: Jan Beulich <jbeulich@suse.com>,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1786440103.8631fc262581453bbf619ec5b2062170.19ff020b5cf000c4f3@vates.tech>
 <2187839d-fef8-4d51-8b98-8c0fb26a9569@gmail.com>
 <1786462177.8631fc262581453bbf619ec5b2062170.19ff17189ea000c4f3@vates.tech>
 <70560c6e-17dd-4524-919b-1dad9c774bee@gmail.com>
 <1786528043.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786528043.8631fc262581453bbf619ec5b2062170.19ff55e8fe5000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1786529102-C06DAB50-D64F81D2/10/73395122804
X-purgate-type: spam
X-purgate-size: 8044



On 8/12/26 11:47 AM, Baptiste Le Duc wrote:
> On 2026-08-11 18:24 +0200, Oleksii Kurochko wrote:
>>
>>
>> On 8/11/26 5:29 PM, Baptiste Le Duc wrote:
>>> On 2026-08-11 16:36 +0200, Oleksii Kurochko wrote:
>>>>
>>>>
>>>> On 8/11/26 11:21 AM, Baptiste Le Duc wrote:
>>>>> On 2026-08-07 18:08:21+02:00, Oleksii Kurochko wrote:
>>>>>> On 8/6/26 4:28 PM, Jan Beulich wrote:
>>>>>>
>>>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>>>
>>>>>>> For this tag to have any meaning, it should move ahead of the --- above;
>>>>>>> the explanations ...
>>>>>>>
>>>>>>>
>>>>>>> ... here rather explain the restriction on the R-b, not its odd placement.
>>>>>>>
>>>>>>>
>>>>>>> As this looks to be recurring - please get versioning of your series right.
>>>>>>> The series is supposedly v1, but here you give the impression of it being
>>>>>>> v3. If there really was an earlier v2 posting, why isn't the entire series
>>>>>>> here v3?
>>>>>>
>>>>>> It is v3 before before it was a part of another patch series connected
>>>>>> to dom0less config enablement.
>>>>>>
>>>>>> Would it be better to just write in "Change in v3" that it is moved from
>>>>>> another patch series + link to that patch series? Or it will be enough
>>>>>> just to drop "Changes in v2 and v1" and just start from v1?
>>>>>>
>>>>>>> PLease can you, before submitting, self-review your patches? I'm really
>>>>>>> getting tired of having to repeatedly point out basic style issues, like
>>>>>>> the overlong line here.
>>>>>>
>>>>>> Sorry for that, I will write an extra checker for such cases to not miss
>>>>>> them.
>>>>>>
>>>>>>> It extends to the other local variables here, but I'll use these two to
>>>>>>> try to make my point: I'm struggling to associate the names with the
>>>>>>> values they are set to. Likely "hxw" is an abbreviation of hart index
>>>>>>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
>>>>>>> in "hhxw"? By using hard to grasp names, you make it hard to actually
>>>>>>> understand the subsequent expressions, in particular ...
>>>>>>
>>>>>> The names it taken directly from AIA spec:
>>>>>>
>>>>>> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low
>>>>>> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart
>>>>>> Index Width) for determining target addresses for MSIs is described
>>>>>> later, in Section 4.9.1.
>>>>>>
>>>>>> The AIA specification interprets the machine-level hart index as a
>>>>>> combination of the **group index** (`g`) and the **hart index within the
>>>>>> group** (`h`), according to the following formulas:
>>>>>>
>>>>>> ```
>>>>>> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
>>>>>> (2) h = machine-level hart index & (2^LHXW − 1)
>>>>>> ```
>>>>>>
>>>>>> (In our case, the machine-level hart index is equal to `mhartid`, i.e.
>>>>>> the hart index.)
>>>>> Therefore, if I understand correclty, if we take the Hart Index as
>>>>> defined in the AIA spec, we should have:
>>>>> Hart Index = (g << LHXW) | h
>>>>> Is it correct?
>>>>
>>>> Yes.
>>>>
>>>> But note that in the current version of aplic_hart_field(), hart_id is
>>>> passed directly, so there is no need to extract h as described in the
>>>> AIA specification. We only need to concatenate it with the group index
>>>> that we have already extracted.
>>>>
>>>> This is partly because aplic_hart_field() uses only .base_addr, which
>>>> does not contain hart_index.
>>>>
>>>> If we want to follow the AIA specification fully, using its terminology,
>>>> the code should look something like:
>>>>
>>>> static unsigned long aplic_hart_field(unsigned int cpu)
>>>> {
>>>>        const struct imsic_config *imsic = imsic_get_config();
>>>>        const struct imsic_msi *msi = &imsic->msi[cpu];
>>> Could you please specify how this function will be used and when? It's
>>> hard for me to understand how imsic->msi[cpu] is filled.
>>
>> imsic->msi[] is filled during IMSIC initialization in imsic_init(),
>> based on the MMIO regset specified in the IMSIC node’s reg property and
>> the number of parents specified in the interrupts-extended property.
>> This is explained to some extent in the comment above local target_addr
>> in aplic_hart_field() (a little further down).
>>
>> I am not 100% sure that I fully understand the connection between your
>> question and the sentence after it, but I planned to write the following
>> above the function declaration:
>>
>>
>> /*
>>    * The arrangement of IMSIC interrupt files in MMIO space follows a
>> topology
>>    * 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|Group Index|xxxxxxxx|Hart Index|xxxx|Guest Index|     0     |
>>    * -------------------------------------------------------------------
>>    *
>>    * - xxxx: the remaining bits of the Base PPN. The specification
>> requires the
>>    *   Base PPN to have zeros in the positions where the indices are OR-ed.
>>    * - Group Index (g): placed at bit (HHXS + 24) of the physical address.
>>    * - Hart Index (h): placed at bit (LHXS + 12) of the physical address.
>>    * - 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.
> 
> I think the name `Hart Index` is confusing here. In fact, you previously
> confirmed it refers to target[i] bits 31:18, i.e. the packed number
> (g << LHXW) | h, but here you say `Hart Index` is equivalent to h, which
> makes no sense.
> 
> I know this diagram came from Linux (Anup Patel, Nov 2022,

Not really, this diagram was created from scratch. I think you are 
referring to that one in struct imsic_config but the idea is the same 
and the comment in struct imsic_config should be fixed too. I will 
re-use what we agreed here.

> https://lore.kernel.org/all/20240307140307.646078-3-apatel@ventanamicro.com/),
> where "HART Index" is simply the name of the riscv,hart-index-bits DT
> property. Linux's own APLIC driver then reuses a single hart_index
> variable for h and for (g << LHXW) | h in consecutive lines, without a
> comment, which is confusing - if I understand correctly, obviously :)
> 
> I think this diagram could be better aligned with the AIA spec:
> 
>      * 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.
> 
> What do you think? It would allow us to keep a single meaning for the
> `Hart Index` field, the same one as target[i] bits 31:18 i.e. (g <<
> LHXW) | h.

I agree g and h better describes AIA spec and probably will be easier to 
do a grep in AIA spec.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 10:31:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 10:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1388972.1629943 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu6Ej-00066U-4B; Wed, 12 Aug 2026 10:31:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1388972.1629943; Wed, 12 Aug 2026 10:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu6Ej-00066N-1c; Wed, 12 Aug 2026 10:31:05 +0000
Received: by outflank-mailman (input) for mailman id 1388972;
 Wed, 12 Aug 2026 10:31:03 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu6Eh-00066B-BU
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 10:31:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu6Eg-006fEA-1P
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 12:31:02 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c4b59-8faa-0a2a0a5109dd-0a2a45039e5e-30
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 12:31:01 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c4b65-fae8-0a2a45030019-d1558032f1cb-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 12:31:01 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so7758905e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 03:31:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150bf5f27sm6078649f8f.1.2026.08.12.03.31.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 03:31:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786530661; x=1787135461; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=uaJihWTDEGWNtgMrnyzuOi5l83Je19M2x2j+h7czLhc=;
        b=QaQL6ChCZHGXPYxjDSZCh6KziK+ogF1MO8pVSY9BrhoQWapMhpCQzk3i3pbczxoi7K
         MNQLCWJgIUHsjOTUJ31ZpfV0Jspw6MTtv35qGqtIBsWJTtFAuYvdCO4mmZJfWgm/zcSB
         ev3mwyPjS581LWilM+6cxy1L3AoGtcAzuw855SSSe4OHmqX8ZtkoDwMRimwE1PunsQrM
         8GV4V+2tC9+4lzKpIl+vrPKdr128m1F8c/g2p3DYpwON023sIQ+cojJbapywh1QHEuOA
         KdC6OuchzHZbFUDxgsES6aHK1JHUCF7FYcDczR81+kRlREL1irBg+1eocWl4Aeb5yF+R
         92RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786530661; x=1787135461;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=uaJihWTDEGWNtgMrnyzuOi5l83Je19M2x2j+h7czLhc=;
        b=WYF1cXR511GzHgYQGWgvrThYJ5J1g9SYgOBqSydN6qp8+eIllxrGsixT8lo6x3YOKf
         reCjsw1ofpt4nhMN++zuHMArjbeP2XPbYCacAERubf4EoIK7PhXVdpxYQWlb+u/gmWlU
         5CVETgQB+GxiCcLAm+bi5BTb/mMklxeQYctr0GvZCDmra/DktNMOGnMGcZ3zm01cK9Cq
         0ZFEVw2I5zj5tswxQoDaHIN6c6X56inNaR1bjL9ZlmUbbjbRttvvEYxaTDX2rCA8LLls
         KSlF9rrL8Coxl0Qr03Nl7rqlWfLeyYcqyO9WqhRxcd+OEi/evGdKFGHsLvv5AmdR8Cs3
         /SKw==
X-Forwarded-Encrypted: i=1; AHgh+Ro0Fw9NxCfOxikuF8RgHS293w2dkRqiU2yc919HrIvghcJRLFlBTl9supDdNO/r+vuMd65Peo1c9qU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yymq4baTF/s0EHauor19xGW8O4/6v3Iwki9osMFe2QCH5Qopy+v
	Cf8eEWlUSkUPl/Xq+HebAbDHe9bwyIoIOaY7rYdrMq/IdGkZvyqkr6i9u1ofHLGLVg==
X-Gm-Gg: AR+sD10Da035m+K/8w5HoB30oKFvSRrTy/3zaMNwzJYhXAUG+UMQkoEbRV+dbUfSaJ2
	JDmDO8X8tWNYGuHxmZMVSlM7qADcawbAjmOcjVq49lNZw0R/JQ2XrPLOFQUsTDmC1E66MaUkRwg
	/t4tiXaJ6BQibK1k9hMnc4v4bNrpAPdVAcuZkBq9xU6Ef0fv99nKfL2O+nqC3DUq6pXp4qBVjGH
	nOA0rh10z+0pBRbq0J2Wrn1xH9LQ4Co7Sj4+xioGxtJPy4mcZDExUdyh5cfLXQi+sywzYNw6BWY
	HrEkcBhKgaU2l++iQuUBe5/qG/nCTzlTMzZdTRthN1zqx8JSLN1l8pQP+CaAefia4zewWmVDC9G
	nuOxGpkc/G28nISUyubEDT8DkIQReR4GL5MbeoSSWMy9elJWnZt0FfRTV29f1HVW26g8459sa82
	KU1K9UXTdbaSHYhk5bvgCr8vKwBXXbx7dT9nYrmJrP9bPD30/BGXlvdabdk7yT1QPQXveL2Zkuk
	w7dT+S3stBS/lkwtZMTwum/ns2slUhgr6twANQ+HuBw39o8vH4f
X-Received: by 2002:a05:600c:1f82:b0:499:5c3c:41a5 with SMTP id 5b1f17b1804b1-4997bf88a5emr48649405e9.0.1786530661421;
        Wed, 12 Aug 2026 03:31:01 -0700 (PDT)
Message-ID: <75ed4871-f9ac-41c5-a631-b9894a84f221@suse.com>
Date: Wed, 12 Aug 2026 12:30:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 2/7] xen/console: use 'unsigned int' in
 contring_{flush,puts}()
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260728065049.1318143-1-dmukhin@ford.com>
 <20260728065049.1318143-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260728065049.1318143-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786530661-6D8D54E9-DB610A1B/0/0
X-purgate-type: clean
X-purgate-size: 577

On 28.07.2026 08:50, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> contring_puts() and conring_flush() still use 'uint32_t' to access
> indices.

I took the liberty of adjusting title and description, as ...

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -375,7 +375,7 @@ static void conring_puts(const char *str, size_t len)
>  long read_console_ring(struct xen_sysctl_readconsole *op)

... conring_puts() is referenced only by the hunk header, while it's
read_console_ring() which is being adjusted.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 11:51:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 11:51:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389007.1629976 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu7UO-0001EX-35; Wed, 12 Aug 2026 11:51:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389007.1629976; Wed, 12 Aug 2026 11:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu7UN-0001EP-WD; Wed, 12 Aug 2026 11:51:20 +0000
Received: by outflank-mailman (input) for mailman id 1389007;
 Wed, 12 Aug 2026 11:51:18 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wu7UM-0001EJ-0H
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 11:51:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu7UL-00HRpw-DM
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 13:51:17 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c5e35-e002-0a2a0a5209dd-0a2a4507ea86-2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 13:51:17 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c5e34-b4ea-0a2a45070019-d1558036c4ce-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 13:51:17 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4954df200ddso6205335e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 04:51:17 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997b22784fsm39846245e9.2.2026.08.12.04.51.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 04:51:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786535476; x=1787140276; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=moR6/bA7QMKKeQddssPJ3roFgqPlu6GvRLbxiI9di6Q=;
        b=DDjVsmR0UUHKcTVFO6KhIe8giIYKH1VvXd32Duc3L3VH8bTMtc1gOUT5HQkALGJwZH
         U21erYOi3/nbHw8JsGYVqW+dCM+DdOQAMr6DwoxnPNgN2RbFL5RttKK4+5hgPzIQHDtW
         MbgzFJObxhzRa7CFBZdC/NuUhqBxG5fdNpwZxychLoKEI+3mwvXyi1XlfdGL1/8d2sZW
         qnElxTKIiXg7LsHMd8d1DfTC27tmKj5Sk70UtnIhzMwhDlQS1mARSims7oLQ1cA7WynP
         OijpJy6ghx5v97tqrG15UOaUG9L8ybTEmPa4uxR/+50Ck9B4GmlB1c8kx9rHGMsKL8gg
         mACw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786535476; x=1787140276;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=moR6/bA7QMKKeQddssPJ3roFgqPlu6GvRLbxiI9di6Q=;
        b=fXnFtTJTWTsQ6BWETzjZLpUCHlgLPAveAtnAaIWkzaUBIpXGYq0dZrbko/SN+gnVDZ
         rAWmxshcyOGlScuNQePJ/GdsUwt/21+hfDs3ATDysCh6I5aCLQhqVBOZkFvuOiBwey0u
         8gfML99a2Jy6QtuFRlpXwfu/u2IbDyfXbrTfEs5CezDzmUk/cdk2JJYahGfHnyRvAAb6
         uPhHJ8oYLCeWgDkArZCr4nYYtnDyK4xXasoFt4lvIitJVsSmLDD6iGJw/ffEJ6XDGuVB
         2mtRzauSLbenK5b3DGEjH2n6RtxRQeucU/KUM4DnnsuFqQbIbOzMr91a0d2go/xlew+J
         lXtA==
X-Forwarded-Encrypted: i=1; AHgh+Ro0UWwHkMHcgi0H+1sXf/VtO3Raslam5D8IUdQd4Iu9suEvbC/5PPSoyhSFXyqJyzs9p6CFKeEGJ/g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz45jB3XbAtKyBsswy9VLSEMlL3mZHB+eCC2WFGJ0YByowvf8Q4
	/zv1ewSMlU9AWPQL8flEVqNL/rNmD2gaTAFXv2TurbdGCyO+9TD6mZ1M
X-Gm-Gg: AR+sD136iT/5sCnvMRaEw9a6a/mgcDE4Q2XL5l4WuR5oBK1L81rOtOzOUcM31kCfWwX
	tPYjsn7faRNm3drR4YHWRo74TdJRA01zbsPnGnuXJ7y/iess7WxCdf6meBwBUrvJamqgQe5TJBY
	883vGCN6HUrktq7yOu44/+QFV9+aRH8JsFDz84tjlKrr2aqc5USAH7pGqsdsSr3qdoMnai1+An9
	F4rrl+D9K0xwoa/rEevv3RGlY3PQcxkXk7tMF9u7zwSoVYm0UWU4ffNMXsjG03XnTVPyZ5VS2cB
	gvy4/2LI+PfBmsWp2kvuGpuDB9mBUITxrOkvhR25AJIu7S/hFFk4W0XuoiXMKWT0wn8pv4ByV9u
	L3TpOdyNkcxi/5vjmGWf9z02jmtyAHZ4COwJYhSv14XCGpdbGROcYEAYrz3qiILaxQjoZQizF6+
	tGS4I0kfz1vJTbNNkJGokudmA/SVYc5S9yymwwZqsb0UxJN2jp9/FffAEZ5RbO6WwqrDy95A3tG
	wE+BpvtC+B+aHv2OP9B0KFKpb5C0HvWYi3e39iVDuDoTj9Lb1KGEw==
X-Received: by 2002:a05:600c:4f8e:b0:499:7aa7:8b58 with SMTP id 5b1f17b1804b1-4997c0d6685mr47916615e9.6.1786535476230;
        Wed, 12 Aug 2026 04:51:16 -0700 (PDT)
Message-ID: <c9b12490-1b2f-4024-967b-65107ed6911d@gmail.com>
Date: Wed, 12 Aug 2026 13:51:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1415f794-2121-4534-9226-97479aa57623@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1415f794-2121-4534-9226-97479aa57623@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786535477-A7ED6AE4-0FB2F52E/10/73395122804
X-purgate-type: spam
X-purgate-size: 16948



On 8/12/26 11:10 AM, Jan Beulich wrote:
> On 07.08.2026 18:08, Oleksii Kurochko wrote:
>> On 8/6/26 4:28 PM, Jan Beulich wrote:
>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>> 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 <Romain.Caritey@microchip.com>
>>>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>>> ---
>>>> Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech> # vaplic_mmio_{read,write}
>>>
>>> For this tag to have any meaning, it should move ahead of the --- above;
>>> the explanations ...
>>>
>>>> The downstream changes related to `vaplic_mmio_{read,write}` were originally
>>>> in a separate patch (which was reviewed by Baptiste). However, before
>>>> upstreaming, it was decided to merge them into the current patch.
>>>> I added `Reviewed-by: Baptiste` in this form for now, but Baptiste will
>>>> probably review the remaining changes as well.
>>>> Once that happens, I'll simply move the `Reviewed-by` tag up and
>>>> remove the `#`.
>>>
>>> ... here rather explain the restriction on the R-b, not its odd placement.
>>>
>>>> ---
>>>> Changes in v3:
>>>
>>> As this looks to be recurring - please get versioning of your series right.
>>> The series is supposedly v1, but here you give the impression of it being
>>> v3. If there really was an earlier v2 posting, why isn't the entire series
>>> here v3?
>>
>> It is v3 before before it was a part of another patch series connected
>> to dom0less config enablement.
>>
>> Would it be better to just write in "Change in v3" that it is moved from
>> another patch series + link to that patch series? Or it will be enough
>> just to drop "Changes in v2 and v1" and just start from v1?
> 
> Which part of "never have versions go backwards" was unclear in my earlier
> reply?

Sorry but from your initail reponse it wasn't clear that "never have 
versions go backwards". Now it is clear, thanks for clarification.

> 
>>>> --- a/xen/arch/riscv/aplic-priv.h
>>>> +++ b/xen/arch/riscv/aplic-priv.h
>>>> @@ -48,4 +48,6 @@ struct aplic_priv {
>>>>     */
>>>>    extern unsigned int guest_aplic_num_sources;
>>>>    
>>>> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, uint32_t base_val);
>>>
>>> PLease can you, before submitting, self-review your patches? I'm really
>>> getting tired of having to repeatedly point out basic style issues, like
>>> the overlong line here.
>>
>> Sorry for that, I will write an extra checker for such cases to not miss
>> them.
> 
> Well, if there was a checker, many more people would like to use it.>
>>>> @@ -38,6 +39,60 @@ static struct intc_info __ro_after_init aplic_info = {
>>>>        .hw_variant = INTC_APLIC,
>>>>    };
>>>>    
>>>> +static unsigned long aplic_hart_field(unsigned long hartid)
>>>> +{
>>>> +    const struct imsic_config *imsic = imsic_get_config();
>>>> +    unsigned int lhxw = imsic->hart_index_bits;
>>>> +    unsigned int hhxw = imsic->group_index_bits;
>>>
>>> It extends to the other local variables here, but I'll use these two to
>>> try to make my point: I'm struggling to associate the names with the
>>> values they are set to. Likely "hxw" is an abbreviation of hart index
>>> width, but (a) what's the leading 'l' then and (b) why is there no 'g'
>>> in "hhxw"? By using hard to grasp names, you make it hard to actually
>>> understand the subsequent expressions, in particular ...
>>
>> The names it taken directly from AIA spec:
>>
>> The use of this value and fields HHXS (High Hart Index Shift), LHXS (Low
>> Hart Index Shift), HHXW (High Hart Index Width), and LHXW (Low Hart
>> Index Width) for determining target addresses for MSIs is described
>> later, in Section 4.9.1.
>>
>> The AIA specification interprets the machine-level hart index as a
>> combination of the **group index** (`g`) and the **hart index within the
>> group** (`h`), according to the following formulas:
>>
>> ```
>> (1) g = (machine-level hart index >> LHXW) & (2^HHXW − 1)
>> (2) h = machine-level hart index & (2^LHXW − 1)
>> ```
>>
>> (In our case, the machine-level hart index is equal to `mhartid`, i.e.
>> the hart index.)
>>
>> For systems that use IMSIC groups, the IMSIC address layout is defined
>> by the following parameters:
>>
>> * `lhxw` (Low Hart Index Width, or *k*): the number of bits used for the
>> hart number within a group.
>> * `hhxw` (High Hart Index Width, or *j*): the number of bits used for
>> the group number.
>> * `hhxs` (High Hart Index Shift): the bit offset of the combined
>> hart/group index field within the physical address.
>>
>> To extract the group index, we first shift the address by `hhxs` so that
>> the group index bits are aligned, and then apply a mask derived from
>> `hhxw` to isolate those bits.
>>
>> The hardware performs the same operation to extract the hart index from
>> the MSI address. However, in our case we already know which hart should
>> receive the interrupt (`hartid`), so there is no need to extract the
>> hart index from the base address. We only need to recover the group
>> index and combine it with `hartid` to construct the value expected by
>> the `target` register.
>>
>>>
>>>> +    unsigned int hhxs =
>>>> +        imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;
>>>> +    unsigned long tppn =
>>>> +        imsic->msi[hartid].base_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
>>>> +    unsigned long group_index =
>>>> +        (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
>>>> +        APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
>>>> +
>>>> +    return (group_index << lhxw) | hartid;
>>>
>>> ... these last two. As it stands, they may be easier to understand if
>>> you didn't have the local variables at all, despite them then getting
>>> textually longer.
>>
>> With the explanation above, do the variable names make sense?
> 
> Yes and ...
> 
>> To be closer to AIA spec I think it would be better to rename
>> group_index to g and hart_id to h. Does it make sense to you?
> 
> ... yes. Question is whether you want to help readers who aren't that
> familiar with the AIA spec. If so, maybe add [brief] comments making
> clear what the names say? E.g.
> 
>      /* High Hart Index Shift */
>      unsigned int hhxs =
>          imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;

Good idea with comments. Also, I will apply the comment I suggested in 
reply to one of Baptiste questions which will also provide extra 
information which should help.

> 
>>>> --- a/xen/arch/riscv/include/asm/aplic.h
>>>> +++ b/xen/arch/riscv/include/asm/aplic.h
>>>> @@ -28,6 +28,8 @@
>>>>    #define APLIC_DOMAINCFG_BE      BIT(0, U)
>>>>    
>>>>    /* sourcecfg register fields */
>>>> +#define APLIC_SOURCECFG_D       BIT(10, U)
>>>
>>> As to the comment - this indeed looks to be a field, but ...
>>>
>>>>    #define APLIC_SOURCECFG_SM_INACTIVE     0x0
>>>>    #define APLIC_SOURCECFG_SM_DETACH       0x1
>>>>    #define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
>>>
>>> ... these look to be values of some other field which isn't described. Please
>>> may I (again) ask that definitions are their commentary at the very least not
>>> misguide readers?
>>
>> Thanks for pointing this out. You're right, the comment is misleading as
>> written. APLIC_SOURCECFG_D is a field, whereas the APLIC_SOURCECFG_SM_*
>> definitions are values for the source mode (SM) field, and the comment
>> doesn't make that distinction.
>>
>> I'll update the comments to describe the fields more accurately:
>>
>> #define APLIC_SOURCECFG_BASE            0x0004
>> #define APLIC_SOURCECFG_LAST            0x0ffc
>> /*
>>    * sourcecfg[] register fields:
>>    *  - bit 10 (D) selects the layout of the remaining bits;
>>    *  - D = 1: bits [9:0] hold the Child Index, i.e. the source is delegated
>>    *           to a child domain (unsupported by Xen);
>>    *  - D = 0: bits [2:0] hold the source mode SM (WARL).
>>    */
>> #define  APLIC_SOURCECFG_D              BIT(10, U)
>> /* SM field values (0x2 and 0x3 are reserved): */
>> #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
>>
>> Does it look better? Probably there is not sense for two extra spaces
>> for APLIC_SOURCECFG_SM_*. I want to show by such identation that it is
>> values for SM field of APLIC_SOURCECFG.
> 
> Which is fine. All you need to add then is a field definition for the SM
> field. Then the extra padding blank will also start to make sense.

Sure, I will do then that.

>>>> --- a/xen/arch/riscv/vaplic.c
>>>> +++ b/xen/arch/riscv/vaplic.c
>>>> @@ -17,6 +17,7 @@
>>>>    #include <asm/aia.h>
>>>>    #include <asm/imsic.h>
>>>>    #include <asm/intc.h>
>>>> +#include <asm/mmio.h>
>>>>    #include <asm/vaplic.h>
>>>>    
>>>>    #include "aplic-priv.h"
>>>> @@ -27,6 +28,256 @@ unsigned int __ro_after_init guest_aplic_num_sources;
>>>>    
>>>>    #define FDT_VAPLIC_INT_CELLS 2
>>>>    
>>>> +#define AUTH_IRQ_BIT(d, irqn) ( \
>>>> +    ((irqn) < (d)->arch.vintc->nr_virqs) && \
>>>> +    test_bit(irqn, (d)->arch.vintc->used_irqs) )
>>>
>>> Nit: Indentation.
>>
>> I will use the following indentation:
>>
>> ... (((irqn) < (d)->arch.vintc->nr_virqs) && \
>>        test_bit(irqn, (d)->arch.vintc->used_irqs))
> 
> Which as written still doesn't look right. What I can't tell is whether
> that's merely because of the use of "...".
> 
> Of the three opening prarens on the first line, two have their closing
> counterparts on the same line. There's thus one pending closing paren,
> meaning there should be one extra indenting blank.

To be more precise:

#define AUTH_IRQ_BIT(d, irqn) \
     (((irqn) < (d)->arch.vintc->nr_virqs) && \
      test_bit(irqn, (d)->arch.vintc->used_irqs))

so test_bit(...) is shifted by one indenting blank to be inisde the first (.

> 
>>>> +/*
>>>> + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to
>>>> + * a 32-bit word index into the allocated_irqs bitmap.  Each word covers 32
>>>> + * interrupt sources.  For SOURCECFG and TARGET groups the same division also
>>>> + * 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 inline uint32_t generate_auth_mask(const struct domain *d,
>>>> +                                          unsigned int word_idx)
>>>> +{
>>>> +    unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
>>>> +
>>>> +    if ( word_idx >= DIV_ROUND_UP(d->arch.vintc->nr_virqs,
>>>> +                                  sizeof(uint32_t) * BITS_PER_BYTE) )
>>>> +    {
>>>> +        dprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx);
>>>
>>> Is this really meant to stay?
>>
>> For debug purpose it could be useful, so I prefer to have it with
>> changing it to gprintk(XENLOG_DEBUG, ...) to understand which domain is
>> trying to access something wrong.
> 
> gdprintk() implies you're on the vCPU that's the subject of the operation.
> If that's always the case here, the function parameter wants to reflect
> that as far as possible: "currd" instead of "d".

I will use currd. Then it also makes sense to add ASSERT(v == current) 
in vaplic_emulate_{store,load}().

> 
>>>> +        return 0U;
>>>> +    }
>>>> +
>>>> +    return (uint32_t)(d->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >>
>>>> +                      (first_bit % BITS_PER_LONG));
>>>
>>> I don't quite understand the need for the cast.
>>
>> Functionally it isn't need but it documents that it is expected that
>> translation from unsinged long  to uint32_t will happen. I will drop the
>> cast.
> 
> Thanks. If you really wanted such doc, casts would need adding in many
> more places across the code base.
> 
>>>> +        if ( !target_vcpu )
>>>> +        {
>>>> +            dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n");
>>>> +
>>>> +            /* Ignore such writings */
>>>> +            return 0;
>>>> +        }
>>>> +
>>>> +        value = aplic_msi_target_gen(target_vcpu, value);
>>>> +
>>>> +        break;
>>>> +    }
>>>> +
>>>> +    case APLIC_SETIPNUM:
>>>> +    case APLIC_SETIPNUM_LE:
>>>> +    case APLIC_CLRIPNUM:
>>>> +    case APLIC_SETIENUM:
>>>> +    case APLIC_CLRIENUM:
>>>> +        if ( !value || !AUTH_IRQ_BIT(d, value) )
>>>> +            return 0;
>>>> +
>>>> +        break;
>>>> +
>>>> +    case APLIC_DOMAINCFG:
>>>> +    {
>>>> +        struct vaplic *vaplic = to_vaplic(v->domain);
>>>> +
>>>> +        /*
>>>> +         * The domaincfg register has this format:
>>>> +         * bits 31:24 read-only 0x80
>>>> +         * bit 8      IE
>>>> +         * bit 7      read-only 0
>>>> +         * bit 2      DM (WARL)
>>>> +         * bit 0      BE (WARL)
>>>> +         *
>>>> +         * The most interesting bit for us is IE(Interrupt Enable) bit.
>>>> +         * At the moment, at least, Linux doesn't use domaincfg.IE bit to
>>>> +         * disable interrupts globally, but if one day someone will use it
>>>> +         * then extra actions should be done.
>>>> +         *
>>>> +         * Only DM (bit 2) and IE (bit 8) are writable here. They are assigned
>>>> +         * (not OR-ed) so that a write of 0 can also clear them (WARL), and the
>>>> +         * read-only high byte (0x80) is always kept set on read-back.
>>>> +         */
>>>> +        if ( value & ~(APLIC_DOMAINCFG_RO | APLIC_DOMAINCFG_DM |
>>>> +                       APLIC_DOMAINCFG_IE) )
>>>> +            printk_once("%s: Ignore writes to non-writable domaincfg bits as "
>>>> +                        "they are set by aplic during initialization in Xen\n",
>>>> +                        __func__);
>>>> +
>>>> +        vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO |
>>>> +                                 (value & (APLIC_DOMAINCFG_DM |
>>>> +                                           APLIC_DOMAINCFG_IE));
>>>> +
>>>> +        return 0;
>>>> +    }
>>>> +
>>>> +    default:
>>>> +        goto fail;
>>>
>>> Instead of this goto, I think you simply want to move the label here.
>>> That'll also make the function more similar to its load counterpart.
>>
>> Good point. I am curious how fail label should be aligned:
>>
>>       default:
>>    fail:
>>           gdprintk(XENLOG_WARNING,
>>                    "Unhandled APLIC write at offset %#x (value %#x)\n",
>> offset,
>>                    value);
>>
>>           return rc;
>>       }
>>
>> or default:
>>       fail:
>>
>> ?
> 
> Neither. Labels inside switch() should be indented to same as the
> case labels there.

thanks for clarifying that.

> 
>>>> @@ -105,6 +356,50 @@ static const struct vintc_init_ops __initconstrel init_ops = {
>>>>        .make_domu_dt_node = vaplic_make_domu_dt_node,
>>>>    };
>>>>    
>>>> +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, mmio_info_t *info,
>>>> +                                               register_t *r)
>>>> +{
>>>> +    uint32_t data = 0;
>>>> +
>>>> +    if ( info->len != sizeof(uint32_t) ||
>>>> +         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
>>>> +    {
>>>> +        gdprintk(XENLOG_DEBUG,
>>>> +                 "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%u\n",
>>>> +                 info->gpa, info->len);
>>>
>>> You have v passed in here, but you'd log current. If passing in v is
>>> necessary (i.e. here or elsewhere it may be other than current), then you
>>> need to either ASSERT(v == current) at the top of the funciton or otherwise
>>> handle v != current correctly.
>>
>> It makes sense. I will add ASSERT(v == current) here and for
>> vaplic_mmio_write().
> 
> And then further rename the parameter to "curr", please.

Applied this.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 11:56:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 11:56:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389015.1629986 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu7Zk-0001rN-Ot; Wed, 12 Aug 2026 11:56:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389015.1629986; Wed, 12 Aug 2026 11:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu7Zk-0001rG-LI; Wed, 12 Aug 2026 11:56:52 +0000
Received: by outflank-mailman (input) for mailman id 1389015;
 Wed, 12 Aug 2026 11:56:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu7Zj-0001rA-Ie
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 11:56:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu7Zi-00HSv3-8W
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 13:56:50 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c5f7e-e002-0a2a0a5209dd-0a2a450c85ee-16
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 13:56:50 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c5f81-f479-0a2a450c0019-d155802be07e-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 13:56:50 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-4956242332dso7672785e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 04:56:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c9417bcsm59180305e9.4.2026.08.12.04.56.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 04:56:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786535809; x=1787140609; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=pa29ChL6a2dv9Spb7nqrB7CWUElK/vRgRlZtCll73Hg=;
        b=MhgPWUm+CoRROd8VrZ/ESYOQk2Zc84Qh/ZQokIdUS5cPpC7kUHTWPGRBnFJjDvCSrR
         IERv1RR0ZS/4RW3lZT1EAoifP9F9BEpbD5QPTlzZf9suaO6lk6J+hBwKoMziSBCE9JpE
         1G4umwXlcpZIF/5eFPsC57EBXu3YbUpZlQ6UWS6bTuPuQ5EwNDf/uYbOvy5qo9eryaoV
         3nkjv3BwttA8fxm3eSljE56g66p5rK8NHBD1ZlDDrzpemQI3zDkbDFHKcyu6Tulg7f5m
         JcULEFNuO5a14liIt8hFEt2HhTaTuWo7jv9H/B+tVhqprfD3LMgdNKuyFwqbmGUGytYD
         UdMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786535809; x=1787140609;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=pa29ChL6a2dv9Spb7nqrB7CWUElK/vRgRlZtCll73Hg=;
        b=iRBnQErQziJo+r+IVCK3imRpW+iG7gK3nra50Q726ZSso7UlwBPXFFiss7RuYC0gYu
         Ty0Ovd6AG2wkeSD1U7cgwdSxUUSBNZXoT44Zu4s0ECy9pcuEGMRpyWPAP6D0iUcKCMcv
         FgEEQv753SK5tNURR6n0fKEMkrtVwv2+3XBGGZ/T6IFA5Soaz5tmymmOunbiBSuh4IPy
         GM8hx57Jqk0lt+MXTFIrQn4YUtKzGh9W9W5408cvK1XwG0fTfQMW4JRHlTraTl6cmwAI
         DTL4gN0bh2VNCPY/VtdaycQ64/+PfmL8zpB2nQKTbxRi+i356NlU3pOj6sogsYfeQGkO
         Pe1g==
X-Forwarded-Encrypted: i=1; AHgh+RrT9kqY1kdPxyEwQJHAT+IRRsOBabyRd3pYfRibLsvCC1Vo76137/LhGoZm0t2UW6XWVv8bItwnvCo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCJ9YgE8b8KyKZODxjIpJBSLZv0PfqlmVOVcJWALsliOHHt23r
	Fck6aGBg2byE9DWaURuBMbCtrmGSeU+JuI94ruRX68K8G0pn8h2InCyB7hoGv9YfKA==
X-Gm-Gg: AR+sD12Fs7mrP/A6pbBPcDxFTL2f86cVWHFTUTcCN0N/2gnegirBSThAR730U466cWN
	mdlcU2YAjqPf4kot6ueVwJZF+O81thKnQKdBw9JG1zMdBykw1v5WOEWQlZA8qPIqdTQCGfOeihK
	C8SnkKp2rO8H1Rbr/M4aFIfzsD5g6+x3AnjvQhj7tmbk+vonGFC+eVCDdpdBxpb64fMIqb62l12
	6K2AUUAFiWPlKUg/ntuQHB71NqkNQTw0YkBz5KPV+2lDen7Ss5UAxDGvWNoBJ3lGATLnulGVXB+
	AYD6ofJHDexOloqjQZL/6SC1of3Yomd5EtL+Dm+2sZ+2VuZZ6qnx3K0OqCTggqd2ir45XoVGchd
	Kk7+FlgomCyjE5/KVz8YKTiIo1E/w5EW9M0dkRQBmoSFW+oDdM2b3tbeMN6xR0DBMpVWHl5Ar1r
	vF9bPsDo4tTbXS/VeoaQNKMI7nFnoKC4eGKpDVDOeu1GKtUUaLVZVeWOn1kFWN1CYVclSaZkBjc
	KBl7zHbGKIyKw0+ozJ9ExSUJtYtm0Xn2llqItyAV5JapMlYs51J
X-Received: by 2002:a05:600c:8b43:b0:499:51cc:4e57 with SMTP id 5b1f17b1804b1-4997bf76e08mr54715025e9.0.1786535809579;
        Wed, 12 Aug 2026 04:56:49 -0700 (PDT)
Message-ID: <5b25752b-98ba-4610-b362-89f8c78b39ea@suse.com>
Date: Wed, 12 Aug 2026 13:56:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <57793423-aadd-4786-90fd-2923925b766d@suse.com>
 <4c62661a-f944-4806-824a-e74bcbaea3df@gmail.com>
 <1415f794-2121-4534-9226-97479aa57623@suse.com>
 <c9b12490-1b2f-4024-967b-65107ed6911d@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <c9b12490-1b2f-4024-967b-65107ed6911d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1786535810-51339A5B-E84ABC67/0/0
X-purgate-type: clean
X-purgate-size: 1817

On 12.08.2026 13:51, Oleksii Kurochko wrote:
> On 8/12/26 11:10 AM, Jan Beulich wrote:
>> On 07.08.2026 18:08, Oleksii Kurochko wrote:
>>> On 8/6/26 4:28 PM, Jan Beulich wrote:
>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>> +/*
>>>>> + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to
>>>>> + * a 32-bit word index into the allocated_irqs bitmap.  Each word covers 32
>>>>> + * interrupt sources.  For SOURCECFG and TARGET groups the same division also
>>>>> + * 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 inline uint32_t generate_auth_mask(const struct domain *d,
>>>>> +                                          unsigned int word_idx)
>>>>> +{
>>>>> +    unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
>>>>> +
>>>>> +    if ( word_idx >= DIV_ROUND_UP(d->arch.vintc->nr_virqs,
>>>>> +                                  sizeof(uint32_t) * BITS_PER_BYTE) )
>>>>> +    {
>>>>> +        dprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx);
>>>>
>>>> Is this really meant to stay?
>>>
>>> For debug purpose it could be useful, so I prefer to have it with
>>> changing it to gprintk(XENLOG_DEBUG, ...) to understand which domain is
>>> trying to access something wrong.
>>
>> gdprintk() implies you're on the vCPU that's the subject of the operation.
>> If that's always the case here, the function parameter wants to reflect
>> that as far as possible: "currd" instead of "d".
> 
> I will use currd. Then it also makes sense to add ASSERT(v == current) 
> in vaplic_emulate_{store,load}().

ASSERT(curr == current), that is.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 13:24:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 13:24:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389061.1629994 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu8wY-0005y2-QL; Wed, 12 Aug 2026 13:24:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389061.1629994; Wed, 12 Aug 2026 13:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu8wY-0005xv-NR; Wed, 12 Aug 2026 13:24:30 +0000
Received: by outflank-mailman (input) for mailman id 1389061;
 Wed, 12 Aug 2026 13:24:28 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu8wW-0005xp-HN
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 13:24:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu8wV-00EMEv-Kj
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:24:27 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7405-2eae-0a2a0a5409dd-0a2a45069e9e-28
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:24:27 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c740b-195a-0a2a45060019-d155dd35a45c-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:24:27 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47fde295992so724798f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 06:24:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150d4e260sm7471367f8f.17.2026.08.12.06.24.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 06:24:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Content-Language:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786541067; x=1787145867; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to:content-type;
        bh=JVccR9w/bwY0Ic7GfkQ7xKl3W2XpWX3MtG1+JWOraBM=;
        b=Mw25E9GbCz0+gRf1rjtI9VXf7kg3LCE2zQDDAyG6IUDZ//xoCs6LVAqnWAqgozm+Dq
         8vXQz3DBKaR0ueWQ4NXt2+4x+4UBFsKhdc8zl/rEd/xARz2uwttaauuoBWZbeyg8UtoN
         4FAiM75uPkxkl45piNOre75nYgCTeV8DY/nAvVqCc7braYFniUSWWYHdzZzS3ix39R53
         CHS63r1QoL6+kTldS1e20EUYR6KVamHDCM4E5TpKnX0kjPoOBpjperaT/T893lJjcvL7
         6NY5wK5NvcQ9eMSlTAZYVXAxlxH8lpt435Q7/XSAl1XwsiriWAAvusSff/rtQWgUd68N
         GHSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786541067; x=1787145867;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=JVccR9w/bwY0Ic7GfkQ7xKl3W2XpWX3MtG1+JWOraBM=;
        b=MO8k5GjmwSiXT3dZ7eEngVc7RWy1lmwutCIuFu+J5fncCJQC1DLTwCDpY5RS1HtJxb
         1xEphFm5BNaASUW6nMj1phcDuxL7CRxMDXCJ4bIlijGn8A7DDz4bgXBiS/kJap4xRet9
         58/imz0CvY07Cwuwafic85GHxTin5B7IaEhsrPkV+NMN/1ZYZG+76fD8rbreDIBWnaCR
         Ur+y4jNBJPAM8HUkQFpvDigkZ4XLLXDQ2TN1gXWlkg2yeUyitjCupwue2ECyIM0tERhJ
         M413GKXmwK381Osj4Blo+1AoJSLzbN8GKQPD4i23i2L98MIzSXNfK5HTfkc2IKhMiK+l
         A+fg==
X-Gm-Message-State: AOJu0YyQUzNlQBN3yNMlair+MTQyEAVw74IyoSAiEn+ZFKpSFm11io38
	GHAEszFce5JEyeTFj7hEZIYhtJaYtj9i/f/5ZBGQ/ekNHglb+oTD2sEzY9RzlC/3+/QPApbwOaN
	tiKWIHA==
X-Gm-Gg: AR+sD11zYsfUwEX1hqYvas5cEpoLBKBpffSuHPhPuaUfROXWA3ftur3xGh6eKy2S/44
	cZnkzLTttPUxnJfnQawsldZA0S+FifVtAEQzYt/niUwW8ibvwnVfYrhUEAoZjV23YK+UYHRBJfQ
	e/7wJEIO3m/9nzmpSZPxiDU4/tNmz39B9lEe6QWy1ZwdQ4XKoAuzw69UcpzOaJ1opSKhxIIp00H
	dk6duHpMrVw3O/VCfUUzVEbKfltieESsbbn8P2wdUfUzDrzahFwvwkQPiUVN6VHFelSZr97DYfu
	DBgFOlQ7Uiw+AqQMKq/wjNCkESazVDLwRJ5OjKolEjuN+UAAQotguf/W80sgSbjQmITGlHVn99v
	qyLa8Re2bmgku8SS2X60Fp1r/fCi94+3zhg6bJ5wMYrCPyRSj46mI6BRnHCVtqWON/yuKkYa03x
	0dtZaKX1RYxViEDBjHUbufLaLejRHKLzRwycxSde3H3mJSxeBE0eRtLBH6pGzGzwibBimwjeeCs
	GiGstzZtJdlHyLyFYB1CgksgkAEu6O8hm8ngJUtGFcI/lFHgOs1
X-Received: by 2002:a5d:5f94:0:b0:475:da0e:744d with SMTP id ffacd0b85a97d-48153055113mr6689567f8f.8.1786541066820;
        Wed, 12 Aug 2026 06:24:26 -0700 (PDT)
Message-ID: <f6f7eded-b6a3-49b4-8c68-38d263c3b58e@suse.com>
Date: Wed, 12 Aug 2026 15:24:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2] x86: reduce dependencies on x86_emulate/x86_emulate.h
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786541067-FE87577B-B73DE2C6/0/0
X-purgate-type: clean
X-purgate-size: 13691

Split out struct x86_event to an entirely separate header, and move a few
other items describing the architecture to a new x86-types.h. With a few
forward decls of structures and with a fair number of new #include-s in
.c files, the inclusion of x86_emulate.h (and hence
x86_emulate/x86_emulate.h) can be dropped from all header files except
hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The use in drivers/vpci/msix.c is certainly somewhat bogus, but as long as
X86EMUL_OKAY etc are used directly there, that's the way to go. Like done
for IOREQ, some abstraction will be needed here if this file was to be
re-used by non-x86.
---
v2: Minor comment adjustment ahead of enum x86_segment. Also cover
    hvm/svm/vmcb.h.

--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -305,7 +305,7 @@ $(call cc-option-add,HOSTCFLAGS-x86_64,H
 HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
 
 x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
-                     x86-vendors.h x86-defns.h msr-index.h) \
+                     x86-vendors.h x86-defns.h x86-types.h x86-event.h msr-index.h) \
          $(addprefix $(XEN_ROOT)/tools/include/xen/lib/x86/, \
                      cpu-policy.h cpuid-autogen.h)
 x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h x86_emulate/private.h $(x86.h)
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -38,6 +38,8 @@
 
 #include <xen/asm/msr-index.h>
 #include <xen/asm/x86-defns.h>
+#include <xen/asm/x86-event.h>
+#include <xen/asm/x86-types.h>
 #include <xen/asm/x86-vendors.h>
 
 #include <xen-tools/common-macros.h>
--- a/xen/arch/x86/emul-i8254.c
+++ b/xen/arch/x86/emul-i8254.c
@@ -37,6 +37,7 @@
 #include <asm/hvm/save.h>
 #include <asm/hvm/vpt.h>
 #include <asm/time.h>
+#include <asm/x86_emulate.h>
 
 #define domain_vpit(x) (&(x)->arch.vpit)
 #define vcpu_vpit(x)   (domain_vpit((x)->domain))
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -11,6 +11,8 @@
 #include <asm/current.h>
 #include <asm/hpet.h>
 #include <asm/mc146818rtc.h>
+#include <asm/x86_emulate.h>
+
 #include <xen/sched.h>
 #include <xen/event.h>
 #include <xen/trace.h>
--- a/xen/arch/x86/hvm/mmio.c
+++ b/xen/arch/x86/hvm/mmio.c
@@ -9,6 +9,7 @@
 #include <xen/mm.h>
 
 #include <asm/p2m.h>
+#include <asm/x86_emulate.h>
 
 static int cf_check subpage_mmio_accept(struct vcpu *v, unsigned long addr)
 {
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -11,6 +11,8 @@
 #include <asm/hvm/io.h>
 #include <asm/hvm/save.h>
 #include <asm/acpi.h> /* for hvm_acpi_power_button prototype */
+#include <asm/x86_emulate.h>
+
 #include <public/hvm/params.h>
 
 /* Slightly more readable port I/O addresses for the registers we intercept */
--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -23,12 +23,15 @@
  */
 
 #include <xen/sched.h>
-#include <asm/mc146818rtc.h>
-#include <asm/hvm/vpt.h>
+#include <xen/trace.h>
+
 #include <asm/hvm/io.h>
 #include <asm/hvm/save.h>
+#include <asm/hvm/vpt.h>
 #include <asm/iocap.h>
-#include <xen/trace.h>
+#include <asm/mc146818rtc.h>
+#include <asm/x86_emulate.h>
+
 #include <public/hvm/params.h>
 
 #define USEC_PER_SEC    1000000UL
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -34,6 +34,8 @@
 #include <xen/numa.h>
 #include <xen/paging.h>
 
+#include <asm/x86_emulate.h>
+
 #define VGA_MEM_BASE 0xa0000
 #define VGA_MEM_SIZE 0x20000
 
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -11,6 +11,7 @@
 #include <asm/paging.h> /* paging_mode_hap */
 #include <asm/event.h> /* for local_event_delivery_(en|dis)able */
 #include <asm/p2m.h> /* p2m_get_pagetable, p2m_get_nestedp2m */
+#include <asm/x86_emulate.h>
 
 #include "nestedhvm.h"
 #include "svm.h"
--- a/xen/arch/x86/hvm/svm/vmcb.h
+++ b/xen/arch/x86/hvm/svm/vmcb.h
@@ -4,7 +4,7 @@
 
 #include <xen/types.h>
 
-#include <asm/x86_emulate.h>
+#include <asm/x86-types.h>
 
 struct vcpu;
 
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -38,6 +38,7 @@
 #include <asm/current.h>
 #include <asm/event.h>
 #include <asm/io_apic.h>
+#include <asm/x86_emulate.h>
 
 /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps. */
 #define IRQ0_SPECIAL_ROUTING 1
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -5,6 +5,8 @@
 
 #include <asm/hvm/save.h>
 #include <asm/hvm/viridian.h>
+#include <asm/x86_emulate.h>
+
 #include <public/hvm/params.h>
 
 int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -18,6 +18,7 @@
 #include <asm/msr.h>
 #include <asm/mtrr.h>
 #include <asm/p2m.h>
+#include <asm/x86_emulate.h>
 
 static DEFINE_PER_CPU(u64 *, vvmcs_buf);
 
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -33,6 +33,7 @@
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/io.h>
 #include <asm/hvm/save.h>
+#include <asm/x86_emulate.h>
 
 #define vpic_domain(v) (container_of((v), struct domain, \
                                      arch.hvm.vpic[!(v)->is_master]))
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -8,7 +8,8 @@
 #include <asm/e820.h>
 #include <asm/mce.h>
 #include <asm/vpmu.h>
-#include <asm/x86_emulate.h>
+#include <asm/x86-types.h>
+
 #include <public/vcpu.h>
 #include <public/hvm/hvm_info_table.h>
 
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -16,11 +16,13 @@
 #include <asm/current.h>
 #include <asm/hvm/asid.h>
 #include <asm/msr-index.h>
-#include <asm/x86_emulate.h>
+#include <asm/x86-event.h>
+#include <asm/x86-types.h>
 
 struct pirq; /* needed by pi_update_irte */
 struct hvm_hw_cpu;
 struct xen_domctl_createdomain;
+struct x86_event;
 
 #ifdef CONFIG_HVM_FEP
 /* Permit use of the Forced Emulation Prefix in HVM guests */
--- a/xen/arch/x86/include/asm/hvm/ioreq.h
+++ b/xen/arch/x86/include/asm/hvm/ioreq.h
@@ -8,6 +8,8 @@
 #ifndef __ASM_X86_HVM_IOREQ_H__
 #define __ASM_X86_HVM_IOREQ_H__
 
+#include <asm/x86_emulate.h>
+
 /* This correlation must not be altered */
 #define IOREQ_STATUS_HANDLED     X86EMUL_OKAY
 #define IOREQ_STATUS_UNHANDLED   X86EMUL_UNHANDLEABLE
--- a/xen/arch/x86/include/asm/hvm/vcpu.h
+++ b/xen/arch/x86/include/asm/hvm/vcpu.h
@@ -14,6 +14,8 @@
 #include <asm/hvm/vmx/vvmx.h>
 #include <asm/hvm/svm-types.h>
 #include <asm/mtrr.h>
+#include <asm/x86-event.h>
+
 #include <public/hvm/ioreq.h>
 
 struct hvm_vcpu_asid {
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -9,6 +9,8 @@
 
 #include <xen/mm.h>
 
+#include <asm/x86-types.h>
+
 extern void vmcs_dump_vcpu(struct vcpu *v);
 extern int vmx_vmcs_init(void);
 int cf_check vmx_cpu_up_prepare(unsigned int cpu);
--- a/xen/arch/x86/include/asm/mce.h
+++ b/xen/arch/x86/include/asm/mce.h
@@ -35,6 +35,7 @@ struct vmce {
 
 struct domain;
 struct vcpu;
+struct hvm_vmce_vcpu;
 
 /* Guest vMCE MSRs virtualization */
 extern void vmce_init_vcpu(struct vcpu *v);
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -8,7 +8,6 @@
 #include <asm/io.h>
 #include <asm/page.h>
 #include <asm/uaccess.h>
-#include <asm/x86_emulate.h>
 
 /*
  * Per-page-frame information.
--- /dev/null
+++ b/xen/arch/x86/include/asm/x86-event.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * x86-event.h
+ *
+ * Helper definitions for event handling, which aren't prescribed by the
+ * architecture itself.
+ */
+
+#ifndef X86_X86_EVENT_H
+#define X86_X86_EVENT_H
+
+#ifdef __XEN__
+# include <xen/types.h>
+#else
+# include <stdint.h>
+#endif
+
+#define X86_EVENT_NO_EC (-1)        /* No error code. */
+
+struct x86_event {
+    int16_t       vector;
+    uint8_t       type;         /* X86_ET_* */
+    uint8_t       insn_len;     /* Instruction length */
+    int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
+    union {
+        unsigned long cr2;         /* #PF */
+        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */
+    };
+};
+
+#endif /* X86_X86_EVENT_H */
--- /dev/null
+++ b/xen/arch/x86/include/asm/x86-types.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * x86-types.h
+ *
+ * Type definitions and basic helpers which are more or less directly
+ * describing aspects of the architecture.
+ */
+
+#ifndef X86_X86_TYPES_H
+#define X86_X86_TYPES_H
+
+#ifdef __XEN__
+# include <xen/types.h>
+#else
+# include <stdint.h>
+#endif
+
+/*
+ * Comprehensive enumeration of x86 segment registers.  Various bits of code
+ * rely on this order (general purpose before system, tr at the beginning of
+ * system).
+ */
+enum x86_segment {
+    /* General purpose.  Matches the SReg3 encoding in opcode/ModRM bytes. */
+    x86_seg_es,
+    x86_seg_cs,
+    x86_seg_ss,
+    x86_seg_ds,
+    x86_seg_fs,
+    x86_seg_gs,
+    /* System: Valid to use for implicit table references. */
+    x86_seg_tr,
+    x86_seg_ldtr,
+    x86_seg_gdtr,
+    x86_seg_idtr,
+    /* No Segment: For (system/normal) accesses which are already linear. */
+    x86_seg_sys,
+    x86_seg_none
+};
+
+static inline bool is_x86_user_segment(enum x86_segment seg)
+{
+    unsigned int idx = seg;
+
+    return idx <= x86_seg_gs;
+}
+static inline bool is_x86_system_segment(enum x86_segment seg)
+{
+    return seg >= x86_seg_tr && seg < x86_seg_none;
+}
+
+/*
+ * Full state of a segment register (visible and hidden portions).
+ * Chosen to match the format of an AMD SVM VMCB.
+ */
+struct segment_register {
+    uint16_t   sel;
+    union {
+        uint16_t attr;
+        struct {
+            uint16_t type:4;
+            uint16_t s:   1;
+            uint16_t dpl: 2;
+            uint16_t p:   1;
+            uint16_t avl: 1;
+            uint16_t l:   1;
+            uint16_t db:  1;
+            uint16_t g:   1;
+            uint16_t pad: 4;
+        };
+    };
+    uint32_t   limit;
+    uint64_t   base;
+};
+
+#endif	/* X86_X86_TYPES_H */
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -22,6 +22,7 @@
 #include <asm/p2m.h>
 #include <asm/pv/domain.h>
 #include <asm/setup.h>
+#include <asm/x86_emulate.h>
 #include <asm/xstate.h>
 
 #include <public/hvm/params.h>
--- a/xen/arch/x86/pv/misc-hypercalls.c
+++ b/xen/arch/x86/pv/misc-hypercalls.c
@@ -12,6 +12,7 @@
 #include <asm/debugreg.h>
 #include <asm/fsgsbase.h>
 #include <asm/traps.h>
+#include <asm/x86_emulate.h>
 
 long do_set_debugreg(int reg, unsigned long value)
 {
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -13,6 +13,11 @@
 
 #include <xen/lib/x86/cpu-policy.h>
 
+#ifdef __XEN__
+# include <asm/x86-event.h>
+# include <asm/x86-types.h>
+#endif
+
 #define MAX_INST_LEN 15
 
 #if defined(__i386__)
@@ -25,77 +30,6 @@
 
 struct x86_emulate_ctxt;
 
-/*
- * Comprehensive enumeration of x86 segment registers.  Various bits of code
- * rely on this order (general purpose before system, tr at the beginning of
- * system).
- */
-enum x86_segment {
-    /* General purpose.  Matches the SReg3 encoding in opcode/ModRM bytes. */
-    x86_seg_es,
-    x86_seg_cs,
-    x86_seg_ss,
-    x86_seg_ds,
-    x86_seg_fs,
-    x86_seg_gs,
-    /* System: Valid to use for implicit table references. */
-    x86_seg_tr,
-    x86_seg_ldtr,
-    x86_seg_gdtr,
-    x86_seg_idtr,
-    /* No Segment: For (system/normal) accesses which are already linear. */
-    x86_seg_sys,
-    x86_seg_none
-};
-
-static inline bool is_x86_user_segment(enum x86_segment seg)
-{
-    unsigned int idx = seg;
-
-    return idx <= x86_seg_gs;
-}
-static inline bool is_x86_system_segment(enum x86_segment seg)
-{
-    return seg >= x86_seg_tr && seg < x86_seg_none;
-}
-
-#define X86_EVENT_NO_EC (-1)        /* No error code. */
-
-struct x86_event {
-    int16_t       vector;
-    uint8_t       type;         /* X86_ET_* */
-    uint8_t       insn_len;     /* Instruction length */
-    int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
-    union {
-        unsigned long cr2;         /* #PF */
-        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */
-    };
-};
-
-/*
- * Full state of a segment register (visible and hidden portions).
- * Chosen to match the format of an AMD SVM VMCB.
- */
-struct segment_register {
-    uint16_t   sel;
-    union {
-        uint16_t attr;
-        struct {
-            uint16_t type:4;
-            uint16_t s:   1;
-            uint16_t dpl: 2;
-            uint16_t p:   1;
-            uint16_t avl: 1;
-            uint16_t l:   1;
-            uint16_t db:  1;
-            uint16_t g:   1;
-            uint16_t pad: 4;
-        };
-    };
-    uint32_t   limit;
-    uint64_t   base;
-};
-
 struct x86_emul_fpu_aux {
     unsigned long ip, dp;
     uint16_t cs, ds;
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -25,6 +25,7 @@
 
 #include <asm/msi.h>
 #include <asm/p2m.h>
+#include <asm/x86_emulate.h>
 
 #define VMSIX_ADDR_IN_RANGE(addr, vpci, nr)                               \
     ((addr) >= vmsix_table_addr(vpci, nr) &&                              \


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 13:39:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 13:39:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389074.1630004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9BI-0007pZ-1k; Wed, 12 Aug 2026 13:39:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389074.1630004; Wed, 12 Aug 2026 13:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9BH-0007pS-VA; Wed, 12 Aug 2026 13:39:43 +0000
Received: by outflank-mailman (input) for mailman id 1389074;
 Wed, 12 Aug 2026 13:39:42 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wu9BG-0007pM-IU
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 13:39:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9BF-00EP7H-8r
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:39:41 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7c7796-8faa-0a2a0a5109dd-0a2a450bd61c-16
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:39:41 +0200
Received: from [40.107.201.6]
 (helo=CH4PR04CU002.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7c779b-b7e8-0a2a450b0019-286bc906bdfb-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:39:40 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CO1PR03MB7865.namprd03.prod.outlook.com (2603:10b6:303:26f::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Wed, 12 Aug
 2026 13:39:36 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.012; Wed, 12 Aug 2026
 13:39:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MmZzA9sc+Y005/g/BADJxrJLt5UWeFlztpfgUYOFSBOc+lPa+ZqpCNT1ojqdJvbP5p/+2f5QilinPLCzNBHh5W/LUS5bGb7yNvJmIyevL6Ti1Ldv+INkY95OOP67WYGsgQpMroJNNUhfhwHcIpILU2AtLwAhU/dA7AxAz6sgoE0BSHrqOTCxohtpk1jdkq9HpVqKWX/zoHvFLlr/9xxlWB6WOOl46GpVD5VKdTUxMoo3bgk3tkH5Y1mFHFGd2cv+Lr3qVuBGfoOghzmEYUagP4Liv6uCMnstbyDobxoGQbFrOJSgtvyEYmoKVmsFeTxTPQUR4OrMcwOqOnI1r2v5eQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Oz1woTuVw8O24GNfFSahh4wAX0SG36NHPQJa5rtlOXg=;
 b=WmhgrmbxWgnaNPLPJ9CVsgRtozHhxOZi8DdIgPwnmydbwfDclc/fmR+zCV1R8scxS8UGkTFgav97nqVThpbwPyMb6+87rL7qluukRKKb1wjVwh03yyPq/OexJNVazTvm/53fGaLTRcHUps5uzPGs/r4+7UoblvYvKGl2P9vtmDAEZdSfdIqy6BF5C4kr6ylDsShKu20pGcSEeHKWURbAU2h8VfnADrqv/6gwUYj5QYAUOPxLrLdrza++f4TSEEmvdR3rknVgczhDo4xUXPjl/+eh5JNb0jYqrcnlDxSMWT6oUBMeQG9z/EHcNLoq/9U1dlNM+YJ6ogiykbcbYlsxEQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Oz1woTuVw8O24GNfFSahh4wAX0SG36NHPQJa5rtlOXg=;
 b=W6w8E6tv2ugcIxdEkymjY18FOb7FLbxiAl+ndA7+7lR7ov4pjApf9v4Isr/8IBw7oOZPy3VdT6hDWLdqGjFjRAt+Jav5STNcupJXyH5n5FNmdSKnFujSdbZGoaTSQ/Iu9FpVMgyr1HBU481/YVRT3+ym00qsQLqwvMTBCPHWpno=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <652379aa-dce2-4891-96c6-f9785cb19318@citrix.com>
Date: Wed, 12 Aug 2026 14:39:32 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Subject: Re: [PATCH v2] x86: reduce dependencies on x86_emulate/x86_emulate.h
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f6f7eded-b6a3-49b4-8c68-38d263c3b58e@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <f6f7eded-b6a3-49b4-8c68-38d263c3b58e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0304.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:196::21) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7865:EE_
X-MS-Office365-Filtering-Correlation-Id: fbeccd64-f431-4724-7fc3-08def87725d5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|56012099006|10067099003|5023799004|11063799006|3023799007|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	GDnVer3oCBrsGkZc1YItDrp0Y47QmZleoYHI7PEvON3ClJ9kiq6fWeCml6NPVHYx4dmYEjPEwzBlZsKQh+vIRBfQJ+UXVBsaxCRHcwM1LtUWtjnZdNkM+BoZwJVPaS5q2nvKo9NViIPHcL7xkEFeNxjiLgM/fBV2oZgWQt7NudyU4vm+AnFYSD2O9b1VlnYCJzjXYkB9CCkG+Weom5szQ1nbO1ZcYWi11xuvVKYPpJcYSsMVp8pvf0VVEm/m6brFbW4aLBBGPdbQtgKP8CPXQ8mWPMqK78pUZUn9YhVMvDdMyMnMMjaVX4OKE0PYwNtiEmVMT7peZhdaSzPTNkrlzoVujX1FweGQRcnbITeiG6gcxGoy0jJn7V/vCC1upSwJk0Pi+QtoJKb+w7ScPA423NX07maXR7gKyg77HeMaO8TvKKel5EsSMGGyyObWr0k4vH1eRimzhZTioIY+XYKDHkNdSxfwAAjd2jhUf/ZqUMBpnmd7NjDE5M0XwKkNJB2bL5g0VB0rBChaFWYwShYDxVPOW3iRZ+XpvcjVPStKpeUXUQ8AxJCzEeJMViIhZ9v52m0uVeuZTb6LqjGYSkRU9GP5GboYDd/NdUwNeJiGzLD/v0jj+efog/SlA6iXSUUSqZ/OztFdAmE/PR/DMJ1oMI+WySABkncMh7fffr7vb9w=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(56012099006)(10067099003)(5023799004)(11063799006)(3023799007)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?b2l5YUN5NFdUN0VPOGllK3dLaWN6WEg4NjhjTDB4QnZZUEZ6Tit1V1Y0OUxn?=
 =?utf-8?B?amlVS2F2TWlLakxSNldReERraHZldTIra3g5RDN2Z3VGakRnRWRoRm9oN1BQ?=
 =?utf-8?B?TjE4QllFR1lncVdqb0tXMTJPOTdPR3dYQTZFSUFrM2hmODlMcGNCWE9jUWZt?=
 =?utf-8?B?ODI4K1dwZUJnK2NkNVJzcTZTaFN4QWZVZ3greFh2Q1JCVkdiR1FwaTdTblZk?=
 =?utf-8?B?VzhNWWpaY2ZrNWFVSEM3VFNmZ214b28vcjRoQmlBWGhYM3M4cmVsZkNzZCtD?=
 =?utf-8?B?ZTNTOTAwUUtRUFc5WktsV3liVW1ucGNFdlFaQXh4TUFBTkV0N21PRnZtYzFp?=
 =?utf-8?B?RTluN0F0SFBDWlFJQXcyLzdXNE16amJWRFZUOVZYdlRsOXp4WnU1OXQwdlI3?=
 =?utf-8?B?eUhMM1E0QXBUenhZMXBtTndkUm83VEpDK3ZHVHlWNVlUNXMwbDd0a0d3QldV?=
 =?utf-8?B?TGdzNzBSaVdBKzRITHdVZjRUUEJBbVl6amhhNm9LaWNzNkNPTFBYOWl0Z0NS?=
 =?utf-8?B?MXY5QzcrLzA3UFJFRm9iQ0hmbHVsTVFvdnBuckpJNnFLZFpjWTdxZHR0c1Zn?=
 =?utf-8?B?cWU4OXJRdlJDRVhmMThUa2liWHcrb0E5ZCt6N0hLOHltTzhxbUNIZDVsMERF?=
 =?utf-8?B?SjBJYncxVU9lKzJIODNRT2VxTmJGR1dTMlBuaWpvVzdwV2JUVlRaOElkR2pS?=
 =?utf-8?B?aHBnVjI2aGhMT2tRMmlGdE1iQ2lVNkRlVmc1RldRekV2SldBT3RGekt6Zzhn?=
 =?utf-8?B?WncxcjE3U1ByUWZ4QnZQbWZvVnpkY05mWHc0aVZBSEhlZXhKdlRFbkE2V3Q1?=
 =?utf-8?B?SnFLaFF5SmUxMzY2YzluSnlHQ0VMOE9aUmtnY1JjRjdNMUlpcEltZmovOC9E?=
 =?utf-8?B?UHN4TG5GQk1WOVVvTXRZcjEzVll6ZVBuZHk1WCtYbGRqQkNvdG5GdUJYeXEz?=
 =?utf-8?B?KzE2VCtGTk9DaG9NbjdKVllQanBZdHNYRmlMYUwzTEREcEpUMHV4REFXL3Rt?=
 =?utf-8?B?UlVRVjlETlkrTUNrc05SQmc2YWwyaHRDc1Vsd0tYTGQvVDMwMHBGN29qcXlG?=
 =?utf-8?B?bjNQNXZGaGNuYVJ1b1hnSW13YkRFb1NQRjFja1ZCTlJBTW9PU3RoMmJQQTE3?=
 =?utf-8?B?NU9nZjFXUEd2aThrQ2lQS2VrYWM5Vmx5NGpuNnYzcWMzbWovb2I2cmlEMmll?=
 =?utf-8?B?VnpSbTAxKzBWUTdPK1AwS2RDck9wOGZRbEFxbmVzVytZblZwUjE3cTJjdHJ1?=
 =?utf-8?B?K1IxU1JLQWIvN3FRYVZuNm9sNTk5Y09ja1dDZmlwQ0IxQkMrZlVPbE1kY3li?=
 =?utf-8?B?LzIvd2tPekFiUTY4bkV5TENTK0xyZHNtNWhtT2NHYjcwRnlRWVNZR1RiOEho?=
 =?utf-8?B?R2VWclpJL2lYRFVXblV6N2dUdnVwYnJsU1RJQUx0MnhpZ3VDQ1JqTzZzWlJu?=
 =?utf-8?B?WWQ1eWJyVHhLQldZeFBGTElzbCtndVg3T0tyQlprcUdrak5HbWhMMkpLUDF2?=
 =?utf-8?B?ZzBmTU5SQjFPOWlrYUZEaThHakZXL3Vidnp1S2V2b0lpTlFFbHJMckp3Mk03?=
 =?utf-8?B?NzhlV3hFM2N5SVBGMnRNZmYrNFF6c2VCbnhpWVl1ZE0rNDRjdGZHZnd1dFJl?=
 =?utf-8?B?dzIxR2lVRHpTNWFzZHErR1RiRk1lRE1IRHFXc0MzUFZuVXYvQWttKzhncWNB?=
 =?utf-8?B?WHExaFhvckRDaGhaTUU1OFJOSTVuaERTMDBtMkhhSVpIU0M2UUhBdkdieUx0?=
 =?utf-8?B?dWtaOVVsZU8rMFdRQllZbHBTZkMraDVmUVJhTEZCQ3MvNW5Ec1crMzZnNjQ2?=
 =?utf-8?B?Y0RDS1FUZ3ZTTnk4KzBFRjgrS1o3NVVnc0VKK09PRFFDSEVpVXFvMHZkWGkw?=
 =?utf-8?B?ZjZ6WjNGdHo5Z0ROdURxN2hPNzh1NmhPK2MzeXBCNTlvdFg0Qkh3WU9nYm92?=
 =?utf-8?B?bmxNVDJ0MWZJTFdHLzBNWWVOUXk5YjBSZEMrelBMOUZmSFdaeWpKeWtpZ2ty?=
 =?utf-8?B?R1B1SklhemZiOUN4NGc1eFlHWmJNa0hmeGV0SWErTi9JWjdFMjVjbWttcGRh?=
 =?utf-8?B?RmZsWFpETmhLeXBqdmxaQlhKVCtoakJRTmxLYnN6akZDcVBUTnAreGRiY0lx?=
 =?utf-8?B?L1BBZUVuSDRFTHR4bU9IK2JrQjU3dnlYZVQ3S1ZTa3RkNjRacmQzL1NhOWF1?=
 =?utf-8?B?V2tyakNRTTJqN3NXdElaUjkwOVdpeXpwdGlEOTBFZzhhYk1FMlA2ekVoRWdl?=
 =?utf-8?B?N1dsNExWeFZCREN6M0g0VmFnck1LMlZCZng4ZzluQncvbm1NL0ZTckF0Mnha?=
 =?utf-8?B?NEpNUlJUTlBUc294RTUzOE5QMXduV241bnBicTVZZTFwb0d2eXJuQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fbeccd64-f431-4724-7fc3-08def87725d5
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Aug 2026 13:39:35.3768
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Rgh5d9aBY5qoaDa0gX9mpRfSm0htFvGwuGwh8ouNAajNdLNZ9tc/8AnB057Cf5EW7MErviW1M4hgVvrGTDC7IGsc7NjD9cVjWZ2oDoX0Zu0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7865
X-purgate-ID: tlsNG-42698a/1786541980-1B8D19EA-D461679D/0/0
X-purgate-type: clean
X-purgate-size: 1783

On 12/08/2026 2:24 pm, Jan Beulich wrote:
> Split out struct x86_event to an entirely separate header, and move a few
> other items describing the architecture to a new x86-types.h. With a few
> forward decls of structures and with a fair number of new #include-s in
> .c files, the inclusion of x86_emulate.h (and hence
> x86_emulate/x86_emulate.h) can be dropped from all header files except
> hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/x86-event.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * x86-event.h
> + *
> + * Helper definitions for event handling, which aren't prescribed by the
> + * architecture itself.
> + */
> +
> +#ifndef X86_X86_EVENT_H
> +#define X86_X86_EVENT_H
> +
> +#ifdef __XEN__
> +# include <xen/types.h>
> +#else
> +# include <stdint.h>
> +#endif
> +
> +#define X86_EVENT_NO_EC (-1)        /* No error code. */
> +
> +struct x86_event {
> +    int16_t       vector;
> +    uint8_t       type;         /* X86_ET_* */
> +    uint8_t       insn_len;     /* Instruction length */
> +    int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
> +    union {
> +        unsigned long cr2;         /* #PF */
> +        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */

With the advent of FRED, this probably wants to become event_data (or
just data) and drop the union.

It's also the XFD_ERR mask for #NM, and the NMI Source Bitmap (on
capable hardware), and I think we're better off pointing to the FRED
spec than keeping an out-of-date list of what's in it.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 13:43:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 13:43:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389085.1630012 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9FF-0000w3-Ip; Wed, 12 Aug 2026 13:43:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389085.1630012; Wed, 12 Aug 2026 13:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9FF-0000vw-GA; Wed, 12 Aug 2026 13:43:49 +0000
Received: by outflank-mailman (input) for mailman id 1389085;
 Wed, 12 Aug 2026 13:43:48 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu9FD-0000vq-Rx
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 13:43:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9FD-006LHw-8p
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:43:47 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c788c-2eae-0a2a0a5409dd-0a2a4504bc7a-8
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:43:47 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7892-b57f-0a2a45040019-d155dd32c515-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:43:47 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so552589f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 06:43:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150bf5f27sm7281740f8f.1.2026.08.12.06.43.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 06:43:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786542226; x=1787147026; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=M+i8+ViEsC5vpwz0JKveI/HXy+OJAib0U0kJsEmdazc=;
        b=HWnuaQ5NHk3l+zMkl1NybQxuchlBrlgCNEi1EqzWSpEDF4as6tnc86LbuxX9gL5M6U
         i6cjhZYs6XU5Jcb+EVqrKeaHQIBozT1Ce5kod/7fGxzJm9zXaEyjGI2H3G5EK0ycX8oh
         URB45ZapAEUs/m1DqJn/N4vXk76Bl2q3AsN9o9SfSx4Yf1CcKtuKElUNR8yDWbKIHwxp
         A9J7Yc2X8gL0qS7yAnMAGvhhlGdzO6G1U5CMpwfbSjBev1iH2ltJppvjLQNpmvhVLPPm
         jb8jEzXjGyFZjjWWObPKA7i+5Mc3A5dVFLlwBQ403wdlrHXIiPs0rE7DND0TXrVYLelx
         BjXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786542226; x=1787147026;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=M+i8+ViEsC5vpwz0JKveI/HXy+OJAib0U0kJsEmdazc=;
        b=POIDKvqQuORTzfkM7Q0pFCm+NWa9jX1+vmxay0UbF9gQEB4qZHflYsFbYeC90N9Q0Q
         xo1P1SLQn/rnOnIAwRpUz4E2p1E5M4MmwcG/45a3MbvTuplews3OeUF3G20r9nQ83zJv
         DuOiNE880hAMyg4Q1/hE0Q03TXsJt2Kfvu2kcrV/liY13Pq0LShP4RZ/oxrOy91Hc5Ii
         yhQUaPdya2onuTmWnGHQzIftCOcF/fGjFliMRxLI+ZX4aQmTsTVbznZFClylaNaNaikQ
         IKYAajITNH2oKWodQYYGQ5u6+w/7J57zgvj7KEia1UxTI518IjEu++FH4KtwMDVgH5UQ
         FgVw==
X-Forwarded-Encrypted: i=1; AHgh+RqGj58DjeEP5uoQSf+82h9oYyploxxZVkgWRlsDr34OC4XfZHHsprpZcApbaJgv0op6IRJThZcDSgI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxeDcqsqi8xLT9sN5pidPBoaqooLdgAN8h+InhsZV5vVp2r1i2t
	pAqI7Rly4CMixAbEo9Iaughca7+aZ8sBOKr4b5PmKMW1UeOVNN7mb7ZcPafv7INcRw==
X-Gm-Gg: AR+sD13Q/1hF7NRwP+USiwK2siudfvKlsl7383Z9ZQbwUqyKEBRYiG9gEfPYIsSk1xd
	byXYeEhuoRLu64sSD3vNZJfmFgjEQRBsKwqHYBAizp0Di1lvhrbXsI/xuucBBtbE2JRCod5FmvH
	JBtzwhCbX5zHiuO78SRBxcAmn2CDwbDiklDn+DrRlWrRUpp53eryf26upMzLnpw6f3Lj7zg707j
	5X8xAq6jE6zvwTEYVYnZMGUxEYLyW8pxQaQOnOYnEAuegis04Hh3/Fz3NAHFlqMpWv6YGP48Z3g
	k00MFHywmYMF1docBdIYMLt0cdJGOUWbX852yLhed58TfGjV0UiSKhmTER8MvpYGsgKNqxWUzkf
	Q2KwZYDx3PlSFhMlIIx2y+PmJlb9xxrPLbVhrg7B+jcosEP61Abbt7d+JDS+SprtK3LsMEflDRo
	NKV7bqCBJl361V7uxLetpZqo789zeoVB13Ny8Bgf3O9XMsdedhs0NbEhRoTWyG7jVG3o7KKc8Rv
	6atYV/fHO5WOwiFx+kXDY0t+EVAxnytja4VKoaH9gVk0yl5K0JB
X-Received: by 2002:a05:6000:40cb:b0:45e:e1a4:c4c3 with SMTP id ffacd0b85a97d-48152913c78mr7454500f8f.15.1786542226601;
        Wed, 12 Aug 2026 06:43:46 -0700 (PDT)
Message-ID: <81cdb854-54ac-440b-9459-68f5b61cfe41@suse.com>
Date: Wed, 12 Aug 2026 15:43:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86: reduce dependencies on x86_emulate/x86_emulate.h
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f6f7eded-b6a3-49b4-8c68-38d263c3b58e@suse.com>
 <652379aa-dce2-4891-96c6-f9785cb19318@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <652379aa-dce2-4891-96c6-f9785cb19318@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786542227-52AC8B50-175D19D0/0/0
X-purgate-type: clean
X-purgate-size: 1934

On 12.08.2026 15:39, Andrew Cooper wrote:
> On 12/08/2026 2:24 pm, Jan Beulich wrote:
>> Split out struct x86_event to an entirely separate header, and move a few
>> other items describing the architecture to a new x86-types.h. With a few
>> forward decls of structures and with a fair number of new #include-s in
>> .c files, the inclusion of x86_emulate.h (and hence
>> x86_emulate/x86_emulate.h) can be dropped from all header files except
>> hvm/emulate.h; it needs additionally adding to hvm/ioreq.h though.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/x86-event.h
>> @@ -0,0 +1,31 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * x86-event.h
>> + *
>> + * Helper definitions for event handling, which aren't prescribed by the
>> + * architecture itself.
>> + */
>> +
>> +#ifndef X86_X86_EVENT_H
>> +#define X86_X86_EVENT_H
>> +
>> +#ifdef __XEN__
>> +# include <xen/types.h>
>> +#else
>> +# include <stdint.h>
>> +#endif
>> +
>> +#define X86_EVENT_NO_EC (-1)        /* No error code. */
>> +
>> +struct x86_event {
>> +    int16_t       vector;
>> +    uint8_t       type;         /* X86_ET_* */
>> +    uint8_t       insn_len;     /* Instruction length */
>> +    int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
>> +    union {
>> +        unsigned long cr2;         /* #PF */
>> +        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */
> 
> With the advent of FRED, this probably wants to become event_data (or
> just data) and drop the union.
> 
> It's also the XFD_ERR mask for #NM, and the NMI Source Bitmap (on
> capable hardware), and I think we're better off pointing to the FRED
> spec than keeping an out-of-date list of what's in it.

Yes, perhaps that's going to be better.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 13:57:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 13:57:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389094.1630021 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9Sj-0002zV-My; Wed, 12 Aug 2026 13:57:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389094.1630021; Wed, 12 Aug 2026 13:57:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9Sj-0002zO-K7; Wed, 12 Aug 2026 13:57:45 +0000
Received: by outflank-mailman (input) for mailman id 1389094;
 Wed, 12 Aug 2026 13:57:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu9Si-0002yT-5E
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 13:57:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9Sf-00Ciex-Eu
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:57:41 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7bca-bab6-0a2a0a5309dd-0a2a450ad2e4-30
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:57:41 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7bd5-f2d2-0a2a450a0019-d1558032e50c-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 15:57:41 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4957eefd361so7480865e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 06:57:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c946ce1sm48434765e9.5.2026.08.12.06.57.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 06:57:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786543061; x=1787147861; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=KLVVAA1PM5afo/V1q2fX765yKgxPYKydsPta32vbjmY=;
        b=Tf1AUQCju5aqFW+8CakslmVhAYQh1K0/l7N1Wb1mgKucXMoslqQ+kq+pw+kB7M7PS/
         veqJNaHzwxIYkJaqi1KA1feHLZ/iNLlUZdOhtcd5OtDiZ4MhDypNSsym7anifLmh8pGx
         z5057rCcWLRjk/xPziR+4o8N/2O9M5qaTr47UmnCYx82clHCapCWrozp5++crNT0vF9Q
         oXpcaldinMURnukB7hpDSCW4unI3sKpl10w0LwV//UPcMSJywNdkHvBGpJKI74cIfXel
         u+Y3Kgl+c8eR0SjVwAD6lxv4YzYcw8+j4dO01QIWCmZbsz892N/Qo/VUH+BrvzSrPcGz
         MHFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786543061; x=1787147861;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=KLVVAA1PM5afo/V1q2fX765yKgxPYKydsPta32vbjmY=;
        b=c51ukYieTC46INBZmHEIBdmiYar97J7v45ij4KsqPmIVY2h4sjr6j7I1/TlhddvXvf
         u5dvXAO75tbEVMjUjzrb+vmJt1V+6PaOu+Cb7+CreToaHdomNkGwToplkK8buBY5jI9G
         zm5EubevDyNUho0gh9eSoXVE1EQ8+SfDzuqbxbOZx44+egTn4GdXQoXp3NesIuF17/cX
         LaWsGDH21r9mVjSh1nOKUHMdeeLkbm+7zuyCvAIjK+vmyiZjcNqaMrS0ewDZF8JoNgQn
         6PdPzpLLgDZdYx/dhXESIxh5OnRSxNb4c43i/c0mkNhr1LvtzhDF/NnwQ/yd749hlMqs
         eQkw==
X-Forwarded-Encrypted: i=1; AHgh+Rosymsu3t+1f7rVLGohwJmMqTVflJ6vJ0IZos2GlNIDLY5DNH+c7kNQJ7cu7Zb2pTMHKOeP3B0I0lk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1ehxpkaEw3zC4gQEkxKszglJt9XYskK9cTRNOirJRjeq3Lcr3
	G41PK4fB/sAiiIjNDsfWins5rUQxADVS5IGgAY4gvPEtB25m/3RTS2Yee5UI2T74dA==
X-Gm-Gg: AR+sD12RLQVYPP8P36yJuo7Pq4udSR9Nyb0jXIdVKZEhRUOc73PLszzgEMR6sTI7D9Q
	9pBz6Zc9vmhbbldy7UtoStcNRdsM4kshTGsa/VLstgpgb0izl4l9PWQeJe8DVmQjWdGl2zEIsLd
	hEnQZ3y0FpwD9Zv+so0nt2fdGFiYQYeF80eeajm2CGlb/+hsIgPPi/xfgTnee588nyNeUzKSwSv
	0dO+SPHWm5+bHjE0G9P8uza0XDaC69y1ffBdzJO0nSbVtdfTb4yi/36YJfWNxwoICu5DsRbWy/p
	qaAXB3VTGX88Lmm1HGeN6PLdK5ye7GUcvOCzFBsiLRqE/ux1sFRzHA8Ms70vnGo6kGI8gP8zFxd
	UE+kFexRKc1728X/4SgF7/s+w6SD0cnyj95AgBOgWPwpsXzWOfHsyIlFwn4sVGznKvQiQeVS56R
	7+C/tBrHq9tn7L6bdNAe/uKiLFbEm7y+2IBXFzJzRy/WbYma0H/1xN1G+MR1SGKP+ZPM2cnQzyf
	wddQWPIVk66IYTerLUAvAf6VxoELFxRLoB1yr3v2/l2sRHG8Z73
X-Received: by 2002:a05:600c:620b:b0:499:80d0:8b73 with SMTP id 5b1f17b1804b1-49980d08bbdmr19865025e9.4.1786543060836;
        Wed, 12 Aug 2026 06:57:40 -0700 (PDT)
Message-ID: <698b5cf4-b383-452b-b6b8-fd5c09e41f51@suse.com>
Date: Wed, 12 Aug 2026 15:57:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786543061-58FC6CFC-84BF39E3/0/0
X-purgate-type: clean
X-purgate-size: 1358

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>      return res;
>  }
>  
> +void imsic_state_save(struct vcpu *v)
> +{
> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
> +    unsigned long flags;
> +
> +    /*
> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
> +     * should be done in this case.
> +     */
> +    if ( !vcpu_guest_file_id(v) )
> +        return;

How does the ->vsfile_pcpu sentinel value matter here, when you're checking
->guest_file_id?

And anyway, there being dependencies like this one on the other big series
makes it rather hard to review things.

> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);

As discussed for another patch in this series, this will need to change then
as well.

> +    write_unlock_irqrestore(&imsic_state->vsfile_lock, flags);
> +}
> +
> +void imsic_state_restore(struct vcpu *v)
> +{
> +    /* Nothing to do */
> +}

"save" and "restore" have meaning other than what you intend here, aiui. Once
again without call sites it remains unclear when exactly these functions would
be called. Which makes it close to impossible to suggest better names.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 14:03:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 14:03:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389106.1630031 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9Yd-0004sZ-9h; Wed, 12 Aug 2026 14:03:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389106.1630031; Wed, 12 Aug 2026 14:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9Yd-0004sS-6N; Wed, 12 Aug 2026 14:03:51 +0000
Received: by outflank-mailman (input) for mailman id 1389106;
 Wed, 12 Aug 2026 14:03:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wu9Yb-0004sL-25
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 14:03:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9Ya-000Ej1-F5
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 16:03:48 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff64938f1000c4f3@swg.vates.tech>)
 id 6a7c7d32-bab6-0a2a0a5309dd-0a2a45028be0-32
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:03:48 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ff64938f1000c4f3@swg.vates.tech>)
 id 6a7c7d43-6ca4-0a2a45020019-b9ff1c228a83-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:03:47 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ff64938f1000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 12 Aug 2026 14:03:41 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id B44FC8159B;
 Wed, 12 Aug 2026 16:03:40 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=iLZtSt22vfR2LB7LFYAEOG+oDPKyuUTswtUaaj87lFk=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=UzsZ+3umlvAE4zVXhRUit1W7+xWtjejtaWX4aERvtqHGtO2okhddBmx0iF2NJRfliESWc7Vzo
 /i20cBNvIlcGLOFWW4mAXzOSGHykiGsSfYVj7QfDQaAe5v7kuPG9IRcWm2RP6yOUIDc4lL/Vd/M
 5Wt7m98n1mV6TThhSCD+6QcZg8WH5BWqrhYRkjFGzy4U6wwip09uSJBk9L1CrcQUrJiAFyHdj6C
 8mHcwnD7Ny4CRKsZ8rKUR2mSAhvUEIvC1zQn+ieidyW7Wc3RrAkS02qAPFf3xRAKgc+KX5tid8q
 VEDyFnbUnlJpHrgA2GfSVOWlA8nahavc8CYgO5B2ODHg==
X-Zone-Loop: 6902e8c487a42c68a0aaa4835805e663dc8aa347469e
x-campaign-type: default
x-transaction-id: b882a6e1-5dd0-4cf9-86c6-1bb5dcb6687e
x-swg-uid: 01-4e71573b-4354-4ccf-b120-ee08dd3b00d7
X-Mailer: Sweego
Message-ID:
 <1786543421.8631fc262581453bbf619ec5b2062170.19ff64938f1000c4f3@vates.tech>
x-swg-bid: 1786543421.8631fc262581453bbf619ec5b2062170.19ff64938f1000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
Date: Wed, 12 Aug 2026 16:03:33 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786543420; l=11849;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=MWHi21j2IO4mBaWnIOvUV5BO5/PdlSho/xRfc5nngWo=;
 b=zxkFkM7iQ8HmQbQMi9YB3jNCOJW4jDUNFyMWNRJdv3ZZQ8y86hsF1A0E17LaetgtnT/RXegId
 2177ydpbOP/ABN+cXvtryDGiM0JxjcazqT5sfzUSh8/3H8nq7J4mhPq
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786543420934
X-purgate-ID: tlsNG-720697/1786543427-F28B42AC-D52472E2/10/73395122804
X-purgate-type: spam
X-purgate-size: 11849

> 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 <Romain.Caritey@microchip.com>
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>


















>
> diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
> index 1391837f89..96bc56dbe5 100644
> --- a/xen/arch/riscv/aplic-priv.h
> +++ b/xen/arch/riscv/aplic-priv.h
> @@ -48,4 +48,6 @@ struct aplic_priv {
>   */
>  extern unsigned int guest_aplic_num_sources;
>  
> +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 3681f0669e..87f2134bc5 100644
> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -16,6 +16,7 @@
>  #include <xen/irq.h>
>  #include <xen/mm.h>
>  #include <xen/sections.h>
> +#include <xen/sched.h>
>  #include <xen/spinlock.h>
>  #include <xen/types.h>
>  #include <xen/vmap.h>
> @@ -38,6 +39,60 @@ static struct intc_info __ro_after_init aplic_info = {
>      .hw_variant = INTC_APLIC,
>  };
>  
> +static unsigned long aplic_hart_field(unsigned long hartid)


> +{
> +    const struct imsic_config *imsic = imsic_get_config();
> +    unsigned int lhxw = imsic->hart_index_bits;
> +    unsigned int hhxw = imsic->group_index_bits;
> +    unsigned int hhxs =
> +        imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2;
> +    unsigned long tppn =
> +        imsic->msi[hartid].base_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
> +    unsigned long group_index =
> +        (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
> +        APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
> +
> +    return (group_index << lhxw) | hartid;
> +}
> +
> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, uint32_t base_val)
> +{
> +    unsigned int guest_id = vcpu_guest_file_id(target_vcpu);
> +    unsigned long hart_id = cpuid_to_hartid(target_vcpu->processor);
> +    unsigned long hart_field = aplic_hart_field(hart_id);
> +
> +    base_val &= APLIC_TARGET_EIID_MASK;
> +    base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX_MASK);
> +    base_val |= MASK_INSR(hart_field, APLIC_TARGET_HART_IDX_MASK);
> +
> +    return base_val;
> +}
> +
> +uint32_t aplic_hw_read_reg(unsigned int offset, uint32_t mask)
> +{
> +    unsigned long flags;
> +    uint32_t val;
> +
> +    ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t)));
> +
> +    spin_lock_irqsave(&aplic.lock, flags);
> +    val = readl((volatile void __iomem *)aplic.regs + offset) & mask;
> +    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;
> diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
> index f22622b9a2..4ae5fb8f26 100644
> --- a/xen/arch/riscv/include/asm/aplic.h
> +++ b/xen/arch/riscv/include/asm/aplic.h
> @@ -28,6 +28,8 @@
>  #define APLIC_DOMAINCFG_BE      BIT(0, U)
>  
>  /* sourcecfg register fields */
> +#define APLIC_SOURCECFG_D       BIT(10, U)
> +
>  #define APLIC_SOURCECFG_SM_INACTIVE     0x0
>  #define APLIC_SOURCECFG_SM_DETACH       0x1
>  #define APLIC_SOURCECFG_SM_EDGE_RISE    0x4
> @@ -38,6 +40,16 @@
>  /* target register fields */
>  #define APLIC_TARGET_HART_IDX_SHIFT 18
>  #define APLIC_TARGET_EIID_MASK      0x7ff
> +#define APLIC_TARGET_HART_IDX_MASK  0xfffc0000
> +#define APLIC_TARGET_GUEST_IDX_MASK 0x3f000
> +
> +/* xmsicfgaddr/h register fields */
> +#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_DOMAINCFG         0x0000
>  #define APLIC_SOURCECFG_BASE    0x0004
> @@ -77,6 +89,15 @@
>  #define APLIC_SIZE(nr_cpus)     (APLIC_MIN_SIZE + \
>                                   APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus)))
>  
> +/*
> + * 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))
> +
>  struct aplic_regs {
>      uint32_t domaincfg;         /* 0x0000 */
>      uint32_t sourcecfg[1023];   /* 0x0004 */
> @@ -120,4 +141,7 @@ struct aplic_regs {
>      uint32_t target[1023];      /* 0x3008 */
>  };
>  
> +uint32_t aplic_hw_read_reg(unsigned int offset, uint32_t mask);
> +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/asm/imsic.h
> index e1ec3d03c4..612f503b57 100644
> --- a/xen/arch/riscv/include/asm/imsic.h
> +++ b/xen/arch/riscv/include/asm/imsic.h
> @@ -40,6 +40,16 @@ struct imsic_config {
>      /* Base address */
>      paddr_t base_addr;
>  
> +    /*
> +     * MSI Target Address Scheme
> +     *
> +     * XLEN-1                                                12     0
> +     * |                                                     |     |
> +     * -------------------------------------------------------------
> +     * |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index|  0  |
> +     * -------------------------------------------------------------
> +     */
> +
>      /* 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/asm/vaplic.h
> index 96080bfbc2..7bf9247f4e 100644
> --- a/xen/arch/riscv/include/asm/vaplic.h
> +++ b/xen/arch/riscv/include/asm/vaplic.h
> @@ -26,6 +26,9 @@ struct vaplic_regs {
>  struct vaplic {
>      struct vintc vintc;
>      struct vaplic_regs regs;
> +
> +    paddr_t regs_start;
> +    unsigned int regs_size;
>  };
>  
>  int domain_vaplic_init(struct domain *d);
> diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
> index b07b4aa4d3..a09a720d68 100644
> --- a/xen/arch/riscv/vaplic.c
> +++ b/xen/arch/riscv/vaplic.c
> @@ -17,6 +17,7 @@
>  #include <asm/aia.h>
>  #include <asm/imsic.h>
>  #include <asm/intc.h>
> +#include <asm/mmio.h>
>  #include <asm/vaplic.h>
>  
>  #include "aplic-priv.h"
> @@ -27,6 +28,256 @@ unsigned int __ro_after_init guest_aplic_num_sources;
>  
>  #define FDT_VAPLIC_INT_CELLS 2
>  
> +#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 allocated_irqs bitmap.  Each word covers 32
> + * interrupt sources.  For SOURCECFG and TARGET groups the same division also
> + * 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 inline uint32_t generate_auth_mask(const struct domain *d,
> +                                          unsigned int word_idx)
> +{
> +    unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
> +
> +    if ( word_idx >= DIV_ROUND_UP(d->arch.vintc->nr_virqs,
> +                                  sizeof(uint32_t) * BITS_PER_BYTE) )
> +    {
> +        dprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx);
> +
> +        return 0U;
> +    }
> +
> +    return (uint32_t)(d->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >>
> +                      (first_bit % BITS_PER_LONG));
> +}
> +
> +static int cf_check vaplic_emulate_load(const struct vcpu *v,


> +                                        const unsigned long addr,
> +                                        uint32_t *out)
> +{
> +    const struct domain *d = v->domain;
> +    const struct vaplic *vaplic = to_vaplic(d);
> +    const unsigned int offset = addr & APLIC_REG_OFFSET_MASK;


> +    uint32_t auth_mask;
> +    unsigned int i;
> +
> +    switch ( offset )
> +    {
> +    case APLIC_DOMAINCFG:
> +        *out = vaplic->regs.domaincfg;
> +
> +        return 0;
> +
> +    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 = 0;
> +
> +        return 0;
> +
> +    case APLIC_SETIP_BASE ... APLIC_SETIP_LAST:
> +    case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST:
> +    case APLIC_SETIE_BASE ... APLIC_SETIE_LAST:
> +        i = regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK);
> +        auth_mask = generate_auth_mask(d, 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 = regoffset_to_word_idx(offset - APLIC_GENMSI);
> +
> +        if ( !AUTH_IRQ_BIT(d, i) )
> +        {
> +            *out = 0;
> +
> +            return 0;
> +        }
> +
> +        auth_mask = ~0U;
> +
> +        break;
> +
> +    default:
> +        gdprintk(XENLOG_WARNING, "Unhandled APLIC read at offset %#x\n",
> +                 offset);
> +
> +        return -EINVAL;
> +    }
> +
> +    *out = aplic_hw_read_reg(offset, auth_mask);

I think there is a problem here for the target registers: a read does not
return what the guest wrote.

Consider domU calling request_irq() for source 10, with the interrupt
affinity to vCPU1:

      writel(0x0004000A, GUEST_APLIC_BASE + 0x3028)
      /* hart_idx = 1 (vCPU1), guest_idx = 0, EIID = 10 */

vaplic_emulate_store() passes this through aplic_msi_target_gen(), which
keeps only the EIID and substitutes the physical hart field and the
vCPU's guest interrupt file index, so we write target[10] = 0x001C100A

Therefore, a readl() of the same address returns that raw value (0x001C100A) instead of 0x0004000A, since
auth_mask is ~0U here.

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 14:08:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 14:08:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389115.1630039 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9d2-0005qr-Th; Wed, 12 Aug 2026 14:08:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389115.1630039; Wed, 12 Aug 2026 14:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9d2-0005qk-RA; Wed, 12 Aug 2026 14:08:24 +0000
Received: by outflank-mailman (input) for mailman id 1389115;
 Wed, 12 Aug 2026 14:08:24 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu9d2-0005qe-Bz
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 14:08:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9d1-000FUO-LJ
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 16:08:23 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7e50-2eae-0a2a0a5409dd-0a2a450bd1c4-26
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:08:23 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7e57-b7e8-0a2a450b0019-d155dd34a82f-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:08:23 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47db714766aso1337760f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 07:08:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997aac48f7sm72226255e9.8.2026.08.12.07.08.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 07:08:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786543703; x=1787148503; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wcT3KqzQTF1gmS3YckWdjbwsIjK3lCT3+8p1IAPFu5M=;
        b=PTbO2dHaO9zT8zpfiVNhlmlIfXDa0WYdBHlhHtw9pfPiLOPidhB8KykrKtOOTnXCTq
         5rvWb6afKYX6PZsG3+vCZiuP6vVxOnhxJFwsuF8+7M3NHcIl0zreEM84cSC9dRp3ESYo
         0PveUdYCzxoIIzd56Ca/u0nvpZsd7TjPjNzGSVwPLzpVXloDzcqNmh0QKC3wWiRCjXqJ
         ZPC/42Bwl+5gsK80ALNVRn+qWWE3gLPl4AOP2y3HgkLSofWpqGgmYe6T9kdp6BjHs95T
         /r7e5jJsg/tTZiosqdQNFnK7OBlx2sQePKmtdoIN65CFa0V97EeUaC86TvY1WBVI2f3P
         w9iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786543703; x=1787148503;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=wcT3KqzQTF1gmS3YckWdjbwsIjK3lCT3+8p1IAPFu5M=;
        b=cDR0FVoP2248JhVz1aAFlRaD5W3LOabetit8wRYExJrjAnKIYPZMjs7ptXn8FYPM1o
         IOFxCIOrkzYZ5sZHA6MvQlQtHz1C3Bcmd2hZHKNwPLKpn2W6vNmHDtD8J2IL3G6YzdZw
         MeC1KXeeJ5EMzLHQNbG+ccw4vcRcwyJ6RUsg5tWyK2l9M/vdx1ojN76acKfnyqtCqv4b
         OneFu2s925rBUgJphzYOO2vmEN/vaf+CXu7fDb6MbAoLGkputNIrkyae494ilnRJ/OC1
         pinEEDhw3LI1ZoLFpcw57qLL1zrpjkrXEjwHwfz9vdRSp1P+G7cDJM568MAVw41XsTzq
         BBrQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr37xA60HxFvZHSxAylEl5ZElI+m2v3Hd16HVSqc0fwjTeKn4NSmZ3YfcdPaOaEggHpx8xST4G/kUA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBtLsOaWOzPHEaoHamQeBYMB2JlDOwh30KZ07iAeA9fA1yHTSf
	nc1lExniC3V6HG+AT50XbPlSofrBM1x8ChBzD1RwHG1V6qaKiNxnnPzf/il+7GnHfQ==
X-Gm-Gg: AR+sD10TDGvNY6Ytom2EFBa97Yt/6SE4zCKPM+hPmVZ+8tGFSTfulNHRFtGMQPknInu
	UuRngqwyMspkqqFWYRGI+BLVLFhtp2eNueX0Zeav9qGFgUz0OHK+2JxEndbXeWxgwGe7I9v0z9K
	FwvLHaGIgvAe/JKO10Ibn5VwtosYu4YBQsoNyTM5kKNIJQWVsRD0U61wsWFZO2xr3cxpGkUBwO9
	BxKcR0d/wKA8FlrPpOrTVmtnnEhKAJDl1WOckcgGvwilIgfXrDP2IXvx1QuMyaz1f8o8Fi9Yx7C
	qZs3ivOgWUbiYC4JzlM/JKAUZXODy0geRPF2HeWC2bzpvCutcYulGYc1n4eFKRxfjSE4nAQhUwL
	G6krG9uyxDaO7XlTp2V/zqczUxNsEU7ipScLvniMNqgmHB+5xyK72xspqAdd7/LdEuEt83tBVlZ
	DgqEXNqhD+D1TOqdrD5PWlcLolExuSprR3GEuKTWqlUNn3c4xhrEfcoHIU7W7Vpdo25LECfwOLd
	NndcFCkRi+mHKEni/dE41BU12EN2SCJkVJOjyZw1alzn/4BWTio
X-Received: by 2002:a05:600c:4688:b0:499:728c:a1c7 with SMTP id 5b1f17b1804b1-4997c3f159dmr50023075e9.5.1786543702972;
        Wed, 12 Aug 2026 07:08:22 -0700 (PDT)
Message-ID: <f447591a-5fe8-4e96-8610-e75ae7d1a8e0@suse.com>
Date: Wed, 12 Aug 2026 16:08:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 09/17] xen/riscv: add helper to check APLIC MSI mode
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c6c5b05886520586041ca4f50ae554c3536ee662.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <c6c5b05886520586041ca4f50ae554c3536ee662.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786543703-AA8D99EA-84639A21/0/0
X-purgate-type: clean
X-purgate-size: 1111

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> This helper can be used outside aplic.c to determine whether MSI mode
> is enabled. A follow-up patch uses it to decide whether the guest
> IMSIC state should be saved/restored.

How would this work, when ...

> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -93,6 +93,11 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value)
>      spin_unlock_irqrestore(&aplic.lock, flags);
>  }
>  
> +bool has_msi_support(void)
> +{
> +    return readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM;

... you read a global here? To know what state a guest's vAPLIC is in, you'd
need to read its (virtual) register, wouldn't you?

> +}

I think the name is overly ambiguous, the more that there's also no parameter
the type of which would help disambiguation. Judging from title and description,
maybe aplic_msi_mode_enabled() or simpler aplic_msi_mode() could be more to the
point. (Note that neither "has" nor "available" would really express things
correctly, as the DM field can [aiui] in principle be changed.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 14:13:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 14:13:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389125.1630050 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9iM-0007OX-Gk; Wed, 12 Aug 2026 14:13:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389125.1630050; Wed, 12 Aug 2026 14:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9iM-0007OQ-Ce; Wed, 12 Aug 2026 14:13:54 +0000
Received: by outflank-mailman (input) for mailman id 1389125;
 Wed, 12 Aug 2026 14:13:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu9iL-0007OK-KQ
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 14:13:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9iK-006QIO-Ol
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 16:13:52 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7f8b-2eae-0a2a0a5409dd-0a2a450ad2b8-40
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:13:52 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c7fa0-f2d2-0a2a450a0019-d1558032b1a4-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:13:52 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49545ba3d4eso4983095e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 07:13:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150b78648sm8129426f8f.0.2026.08.12.07.13.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 07:13:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786544032; x=1787148832; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0M5as0ZLYKx2rxQhPfFiOLAGJ/AKNx0o9ufi3U0ONao=;
        b=URTCZbyBvKpo6XLBUXM4PqaGyDMuMN1p3yrVNiWK54K8ut6HROB65Uu2iWbOTnpT1e
         2nS8bRAl9VkyNIi1tN73Xm7J3CEDdhOgzFu8gkINFUBISU6MZ4ykjxCbwZaN3bzLdxy4
         +GcsiDMze0rDkqctXIBiTYfdP8o3s3zCPc/QMO8Kp0gb8NJUCB0z7VQjyg9n52pvwGMT
         /3ILbVmjPK7F1dNZtOrPbvlOAq9uq3CRFzG9FW20XpumxSmUAorERqwCHy4jf1g1KvKB
         l/wP5+mZUDec7B68sVxQUNCFK57919/rUE7xoBw8kyVLsPoviEcntlLkkucHllmklahw
         FHgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786544032; x=1787148832;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=0M5as0ZLYKx2rxQhPfFiOLAGJ/AKNx0o9ufi3U0ONao=;
        b=GabEvdJRoi4ExZY96UJWyeFErMM5Y+lTjryXrRMrRZ+v435n4WSQSdTfYGVyaJ0NRc
         reVK0UpjMY+3LyTTWoBtzMoWxXF+f1zrs0LdL9sM1R0o7FeHGHCGiyV0HrlkJHFFFF08
         d2WcEURLgkwhSwqBDFj3ndF50q8ciYqQJSJ4VpI/ZTyp1b+wPw1QtR/SQywWy0I3+N7Y
         6HahTQSFUuJwluaCIQNE02n5EQlfHcFzxakZ0DwGYS5LPxtvZU5KkMiG9FDEuUrQOirz
         8XBohBf9mrciOY41+0Dkhax8KRNvil7gBCj0U5OeetfuXz5ZJtl9lKlkdhy1sU7MWh1l
         vkWg==
X-Forwarded-Encrypted: i=1; AHgh+Rp3mP/f17XsxOsA+jWmuBeqL4UiUSTInHXj1H34GSZ/rOMsZNLRo46f4hX2GtYgVkFGecR2Th5+qro=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHvyNDYJzlozEJJL7zv2CcEKIXKWmAhWzNZ1ROtiA/4IKAGG2v
	3FHH9brT3OY9f2vt6dklIy+nb1h4laERjRY11p3BSHAtw7h47sw9nvGvwMm78WsdEQ==
X-Gm-Gg: AR+sD13WfTsVJ8TeVVpWa6ghJaHbj9bEqD5ULwQBgFMuXDRHgKBl4qbbn/hM09YDR4r
	hWVcc1RNpi0bJFfJLTs+16KFUcumGoxukYKlsg+C2CAr9Cn30AZZ4FRCNDNbJIhf+mColYdScFb
	zWR3IMNU6R2w4hKNof+2Qy0auUMKRatuUfEQhkxKhTLakqDYrE261KHbq+kunM8Rqx4470fTQVJ
	6vYjb/Pg9PMnjPNC9aV6RPXokYYvLb8R6ifg/mqxBUE2sBslyCjV8RnMibY8N1G6CWCKkmczeGv
	I/WnkT+10hFEfuiurATSW21Ml8lxO+GhxDPYEQxlIopYmwv4i6dol1vcoGbJqvI7oKcm23GUdOB
	4OatsN530wiawaroDCaYsXd6AtfDo/MAgRmVt3DFE+kVg5/E1ZHZQMrKsbH/frrkVDPbIvqKvjm
	84KvJdqqys7sbhXKx3GxioU+YivRGiNv1QU6/7ZK/n5SwKle3ZtNjczJdmwwmvRlrmZH/29f+Lu
	vaXUqwQ7KPiLgtNHP2kwOrIrx2w8QT1lF2q2RDV/HqNbh9zjqGZ+SEMCRvI43s=
X-Received: by 2002:a05:600c:4892:b0:499:8174:9f39 with SMTP id 5b1f17b1804b1-49981749f8bmr645865e9.0.1786544032059;
        Wed, 12 Aug 2026 07:13:52 -0700 (PDT)
Message-ID: <9a4af47f-5209-4fd1-94ed-fcc1b11108e5@suse.com>
Date: Wed, 12 Aug 2026 16:13:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 10/17] xen/riscv: introduce
 vintc_state_{save,restore}()
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786544032-4B6D6CFC-F80BF125/0/0
X-purgate-type: clean
X-purgate-size: 2402

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> Virtual interrupt controller state must be preserved across vCPU context
> switches: for AIA, a vCPU's guest interrupt file lives in the IMSIC of
> the pCPU it runs on, so the related state has to be saved when the vCPU
> is descheduled and re-established when it is scheduled again.
> 
> Introduce vintc_state_save()/vintc_state_restore() wrappers around new
> store_state()/restore_state() hooks in struct vintc_ops, so that the
> context switch path can save/restore this state without knowing which
> vINTC variant a domain uses.

Same issue with naming as mentioned for patch 08.

> No callers are wired up yet: the vAPLIC implementation of the hooks is
> added by the follow-up patch,

Neither "follow-up patch" nor "patch" alone nor "follow-up commit" should
appear in a description. You simply don't know how many other commits are
going to come between the two.

> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -64,6 +64,12 @@ struct vintc_ops {
>  
>      /* Deinitialize some vINTC-related stuff for a vCPU */
>      void (*vcpu_deinit)(struct vcpu *v);
> +
> +    /* Store virtual interrupt controller state */
> +    void (*store_state)(struct vcpu *v);
> +
> +    /* Restore virtual interrupt controller state */
> +    void (*restore_state)(struct vcpu *v);
>  };

The parameters are properly named "v" here. Why ...

> @@ -91,4 +97,7 @@ void domain_vintc_deinit(struct domain *d);
>  
>  bool vintc_reserve_virq(const struct domain *d, unsigned int virq);
>  
> +void vintc_state_save(struct vcpu *vcpu);
> +void vintc_state_restore(struct vcpu *vcpu);

... is it "vcpu" here and ...

> --- a/xen/arch/riscv/intc.c
> +++ b/xen/arch/riscv/intc.c
> @@ -163,3 +163,17 @@ bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
>  
>      return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
>  }
> +
> +void vintc_state_save(struct vcpu *vcpu)
> +{
> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
> +
> +    ops->store_state(vcpu);
> +}
> +
> +void vintc_state_restore(struct vcpu *vcpu)
> +{
> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
> +
> +    ops->restore_state(vcpu);
> +}

... here? Consistent and predictable naming of parameters / variables _is_
important.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 14:19:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 14:19:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389134.1630057 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9np-0008Cv-2S; Wed, 12 Aug 2026 14:19:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389134.1630057; Wed, 12 Aug 2026 14:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wu9no-0008Co-Vu; Wed, 12 Aug 2026 14:19:32 +0000
Received: by outflank-mailman (input) for mailman id 1389134;
 Wed, 12 Aug 2026 14:19:31 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wu9nn-0008Ci-KJ
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 14:19:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wu9nm-006RH2-Aj
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 16:19:30 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c80f1-8faa-0a2a0a5109dd-0a2a4501d118-4
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:19:30 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c80f1-5984-0a2a45010019-d155dd36c5cd-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:19:29 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so584746f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 07:19:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150bf5c13sm7520310f8f.7.2026.08.12.07.19.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 07:19:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786544369; x=1787149169; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=UYIvVHFALMhhhABLu01nMlsX5hc7W0tduk2QlSjUgYE=;
        b=JSDoOsBgKxyEfzHmO4TuOXUzsjNYnB+BhxkzQlSuAzLkDrQUEvPzmO7ylvM2JRlHpA
         MPzxj6yJZKtId4ziqpx442llKAflYJswbM/GWarBjo9z9rZDEFCaOiRxnDMuUw+ThP6U
         n6VTH3CR/f5ixLCMgTS1zmVSDAo7JYkK8RBt8LahDuVBFo4K3nJKkrn+LV1UZUYkt/wj
         KyL2ZvwmZjojLSlLAn5th9ZZyPQ+ZUOh5F0GCNoUq/vcFDyXVq8lyXiGk/dhISyZfNRG
         YrOG2gYBlCmuyfs2+Qv1tyc4aOqjbjDphqMAGzcpFQGW5qPUPbwkrpZkiw4NtOYxgqd0
         RhPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786544369; x=1787149169;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=UYIvVHFALMhhhABLu01nMlsX5hc7W0tduk2QlSjUgYE=;
        b=OeklTL4phc6NJzc4txPL8x78VmES/KM/HLCc9LAOm/kFp4dMf4nOzQgXNAZ9gxKb1H
         acjlUAp74zv/f6cqr/xL4pCJx1YvqNeiT4s6CXjuc2n6ih23gnZN3y1ZgIrcojNL0Hzs
         jcvnJG01pSRj5dCtPexqcXluG2nUkCeveDGTJbXUCgpA0ukXRwez/YzYicjMdQ4iD2qn
         DlB+dTst/VpBOIUeGl/dktGoqY2aMl4+RYnYP2iG81SPCxnUkH4UgdLzjv7HF8CBoUh7
         PM7ClaYD2N3I1HpTIlZgt7FXknPsYRhZP5ZlA2/Re/28YWwcIs0DWJogTUOUCdLwyQT0
         NKRA==
X-Forwarded-Encrypted: i=1; AHgh+RpmQAQQDkMUyAskKW7rHZRnbcv7Oka8br6OobGn1chIJkSS1SzaVpmTfcKOlbrVys3SvtN6qxgLfxo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyrmVChaLx4tkQdePrP5QnfDTIDixiNyNf56M+1L6oV9JWSTsH
	bbaA04QHwe/OfJsySDWkSdrXkJshGXC5tJIMq35Ao8QUZ3TvefD71Nl1rxM3HOlbnQ==
X-Gm-Gg: AR+sD10rJKMfUUUWPD/Ob0jnsaBGHIGukHUNdYtD4i6d5LDx/IHvz0bUMy6ykNfsLJy
	kShUw5wGU1EUBnq+MCwMaTXsK7Ugejlqbk5O915KzXTcejZoHOB/OnXFpn3twRLxghMyLTpiszN
	bShOZ3LWCVcU2rj59JNAl8Dq+3Icp7pTKXqlzR6x9djyCZ5JRfApBUpvdsji0hMO1uL/8QiPx0n
	WLmorpcie/zdWFX/ZepUVJL8KcAYiPFddz/ZWAerEjHKaWpr/rcBP1+fe+6s8miHP+aVNSiKoTg
	J4JTMyhNnenswUsZ/qVgNkpeQrI1DedQ+kS6dn5NT0D4oyJ5E6+G3NlNzprTxj2R4b24/KtIqDE
	K69IzN0+IcCNmnqmyzMPqawTL9Q4QO0/+Ky+PyHlbYTpOM44A185jcvnRCIFlSbmdjZa9dzU1zn
	e/dyW4SjN3PniMUj8WCWYLKNE/GH6p08HmLHTjUuNTylxzTulR5QDa4hF5goQQyTsBexV7IW3L6
	DRRzbvTM9300p3J3rk3ldSuG4iDhXoj+Lg1iGZVVG+Fx7zmgHkfipFYaZgy6TWK
X-Received: by 2002:a5d:64e4:0:b0:475:3a97:8e3c with SMTP id ffacd0b85a97d-48152913c57mr7138948f8f.18.1786544369391;
        Wed, 12 Aug 2026 07:19:29 -0700 (PDT)
Message-ID: <675c8106-a515-4567-ba30-09f2b0631634@suse.com>
Date: Wed, 12 Aug 2026 16:19:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 11/17] xen/riscv: add vAPLIC state save/restore hooks
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b8aad28481520eb241a1f7519336d3e4bc9aff9f.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <b8aad28481520eb241a1f7519336d3e4bc9aff9f.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786544369-C5146757-CEC5108F/0/0
X-purgate-type: clean
X-purgate-size: 1419

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/vaplic.h
> +++ b/xen/arch/riscv/include/asm/vaplic.h
> @@ -34,4 +34,7 @@ struct vaplic {
>  int domain_vaplic_init(struct domain *d);
>  void domain_vaplic_deinit(struct domain *d);
>  
> +void vaplic_state_save(struct vcpu *v);
> +void vaplic_state_restore(struct vcpu *v);

Why would these be needed? Can't ...

> --- a/xen/arch/riscv/vaplic.c
> +++ b/xen/arch/riscv/vaplic.c
> @@ -400,9 +400,27 @@ static const struct mmio_handler_ops vaplic_mmio_ops = {
>      .write = vaplic_mmio_write,
>  };
>  
> +void vaplic_state_save(struct vcpu *v)

... both be static? And don't they want to be cf_check?

> +{
> +    if ( has_msi_support() )
> +        imsic_state_save(v);
> +    else
> +        BUG_ON("unimplemented");
> +}
> +
> +void vaplic_state_restore(struct vcpu *v)
> +{
> +    if ( has_msi_support() )
> +        imsic_state_restore(v);
> +    else
> +        BUG_ON("unimplemented");
> +}

If you're merely forwarding the calls, why can't ...

>  static const struct vintc_ops vintc_ops = {
>      .vcpu_init = vaplic_init,
>      .vcpu_deinit = vaplic_deinit,
> +    .store_state = vaplic_state_save,
> +    .restore_state = vaplic_state_restore,

... imsic_state_{save,restore}() be used directly here? And whatever other
pair of handlers for the case when it's not IMSIC?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 14:37:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 14:37:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389147.1630067 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuA5C-0002tP-GS; Wed, 12 Aug 2026 14:37:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389147.1630067; Wed, 12 Aug 2026 14:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuA5C-0002tI-DL; Wed, 12 Aug 2026 14:37:30 +0000
Received: by outflank-mailman (input) for mailman id 1389147;
 Wed, 12 Aug 2026 14:37:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuA5B-0002tC-7Q
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 14:37:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuA59-007Om6-Ut
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 16:37:27 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c851f-8faa-0a2a0a5109dd-0a2a450b8c12-16
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:37:27 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c8527-b7e8-0a2a450b0019-d155802af12d-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 16:37:27 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so10648335e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 07:37:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48150c08dd7sm7363418f8f.16.2026.08.12.07.37.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 07:37:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786545447; x=1787150247; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=KoMFEZzeboMnsiJyElZO3eCGf2lVPNl1wbVF7BLiQ+I=;
        b=G2EXAdO+zzb5vFIScqAOGowh+lUtk7A2tqh1tNtg1OsVh4EM+BAcz1DGUoaJ920+LQ
         /qp1ON2S6nVB62yNRIU4gbCLCCgmjRYPpIEaNiNG3sup7czOKhN5ZXIocYqnJip4tyeX
         WpDJFdhc25saawHZb09bHV0X+PuyK0ZBmnUJZzYpKDuVYMrLhaUqLAzzDgtJRxF3eZL9
         C+aqZ6u4IPx96m3XZVKc/2BD+H6w45J2MYPPPkQsEXZjJYCd5+Cdo3oLUyXEN20KKPqc
         CeFYH2W7jExuK8N3BR9IJi14aAzMc2QLUQH5S1/P/gVJsexpY9+n105kx3ItuAYyYcDt
         igVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786545447; x=1787150247;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=KoMFEZzeboMnsiJyElZO3eCGf2lVPNl1wbVF7BLiQ+I=;
        b=nw8J36yTTRVgGAaDsEot3bl7zIwvEciu0Cnc61kZeAckdLqb/TS92vNIiweSHVWHWM
         l4my5m9qk1PvxEt009L/IiAuJaoHRzQ83hIrhpb6nw/ESf8lCazaunsB8O92Eocp06W8
         dMds/2iDgo4sFuE6zOFufcREfK/DcYk6AiLBLIm6SM3/XhxWRvYBpahvMFeK9dR/SQuC
         cvXWlTLcslAWyWGZm76IAb1T3SsQ5UQPRb7R8dsPRq9bLiQXZSGJFheUHF8M7YIsY0K1
         RuqSLvIRBbj2pY96p+YmodK2zSXLeSA1Y7JD26Az8fzKurjRKua9LEofYNCeosfqZcC8
         KuYQ==
X-Forwarded-Encrypted: i=1; AHgh+Ro3NtK5p8UHkXDRTJFfE3S/H03ilaAp2jlNGrYR7vwkhlqA/tT+EyRFzn6zjy8PGOhQV/PQPQiK+ag=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxWz14fvfo7LxNG8zxXCixoQVtWa8oWxdlxFZL9W6yEEvn8PEWR
	2YG8s2h0p52SgU1LBZ5JTmj+BTYzInvv4cwu3HkA+Ai0z9wAACx9NOM4nZsHBS8tQw==
X-Gm-Gg: AR+sD1262BqfSAhWVlc/i6bTLxnpjiJyD0q0AWzJtMEl4CJTaTRIlWGD+u9r2jfhptK
	m3POlPNS0WfuohEE/6piv3ECWm05CJprndUGqbRZq++paoB6kBxcNoVREOMmiZrrS6YL/722PNu
	erfXljqrnPOkRAx+fgR47O7KghDCZNZq22rGyKp+FJbDvb5yLlMFxtrclUdQF6zAVBOX0mB2CZD
	XPLF+45kh+TppzMwpKf956LtKhEbQY6ibiWM0NZgjQNRhKPo98QxFotmbXgVd+KNApjFa+tAsID
	EVEY54N0L3jy9RmA8z5dt79Pel1LfC22y6fBb8dsTj+aTmcQ1jgkTgATP4aOQgX8ESPAeSPldpU
	3TQtxCrfKMpEewmIDRlIypTIGSvVdqfGgvxABljVEAm8vb0JrT06WNX/4x8HESAskl9mcAeaSNb
	jWTsblKdkh4aP7TMcFMOpddEfSzjLW52Te8DM/Sg5SBer7JeWmo9Fx27r+A5C8bnV7qCvYBeMOZ
	pRQKC1gBZChiyxSs/NTc0NStaE/iDPrjwFhC8pmPSg39o7u2IKZV7ATqpRjenw=
X-Received: by 2002:a05:600c:1990:b0:499:48bb:417e with SMTP id 5b1f17b1804b1-4997c0fe4ebmr62491525e9.2.1786545447330;
        Wed, 12 Aug 2026 07:37:27 -0700 (PDT)
Message-ID: <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
Date: Wed, 12 Aug 2026 16:37:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786545447-A88C99EA-53675707/0/0
X-purgate-type: clean
X-purgate-size: 4227

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>      regs->sepc = ex_fixup(ex);
>  }
>  
> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
> +                                         unsigned int offset)
> +{
> +    /*
> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
> +     * laid out at the start of struct cpu_user_regs in architectural
> +     * order.
> +     */
> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
> +                 sizeof(unsigned long));
> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
> +                 31 * sizeof(unsigned long));
> +
> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
> +        return 0;

And an offset not divisible by sizeof(unsigned long) is okay?

Returning 0 as error indicator also feels fragile.

> +    return *(unsigned long *)((unsigned long)regs + offset);
> +}
> +
> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
> +                                 struct cpu_user_regs *regs)
> +{
> +    struct trap_info *trap_info =
> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));

Related to the earlier comment: Simply pass just ex->data here, leaving the
multiplication to regs_get_gpr()?

> +    BUG_ON(!trap_info);
> +
> +    trap_info->sepc = csr_read(CSR_SEPC);
> +    trap_info->scause = csr_read(CSR_SCAUSE);
> +    trap_info->stval = csr_read(CSR_STVAL);

Do you really need to re-read all three registers here? Didn't you read at least
scause already, in order to make it here in the first place?

> --- 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
>  
> +#include <asm/gpr-num.h>
> +
> +#define EX_TYPE_FIXUP 0
> +#define EX_TYPE_TRAP_INFO 1
> +
>  #ifdef __ASSEMBLER__
>  
> -#define ASM_EXTABLE(insn, fixup) \
> -    .pushsection .ex_table, "a"; \
> -    .balign     4;               \
> -    .word       (insn) - .;      \
> -    .word       (fixup) - .;     \
> -    .popsection
> +#define ASM_EXTABLE_RAW(insn, fixup, type, data)    \
> +    .pushsection .ex_table, "a";                    \
> +    .balign     4;                                  \
> +    .long       ((insn) - .);                       \
> +    .long       ((fixup) - .);                      \

Why the change from .word to .long? And why the extra pairs of parens?

> +    .short      (type);                             \
> +    .short      (data);                             \

Alongside .word, these then likely want to be .half.

> @@ -23,20 +30,36 @@
>  
>  struct cpu_user_regs;
>  
> -#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"                                \
> +    ".long      ((" insn ") - .)\n"                 \
> +    ".long      ((" fixup ") - .)\n"                \

Same questions here then.

> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/gpr-num.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef RISCV_GPR_NUM_H
> +#define RISCV_GPR_NUM_H
> +
> +/* GPR ABI names, in register-number order (x0 .. x31). */
> +#define GPR_ABI_NAMES                   \
> +    zero, ra, sp, gp, tp, t0, t1, t2,   \
> +    s0, s1, a0, a1, a2, a3, a4, a5,     \
> +    a6, a7, s2, s3, s4, s5, s6, s7,     \
> +    s8, s9, s10, s11, t3, t4, t5, t6
> +
> +#ifdef __ASSEMBLER__
> +
> +    .equ    .L_gpr_num, 0
> +    .irp    name, GPR_ABI_NAMES
> +    .equ    .L_gpr_num_\name, .L_gpr_num
> +    .equ    .L_gpr_num, .L_gpr_num + 1
> +    .endr

So this is emitted no matter whether a .S file actually uses any of the constants.
Perhaps okayish, but somewhat wasteful.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 15:31:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 15:31:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389181.1630077 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuAuu-0003IG-7D; Wed, 12 Aug 2026 15:30:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389181.1630077; Wed, 12 Aug 2026 15:30:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuAuu-0003I9-3a; Wed, 12 Aug 2026 15:30:56 +0000
Received: by outflank-mailman (input) for mailman id 1389181;
 Wed, 12 Aug 2026 15:30:54 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuAus-0003I3-5c
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:30:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuAur-00AUpW-Ey
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 17:30:53 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c9198-e002-0a2a0a5209dd-0a2a450acf38-42
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 17:30:53 +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 <jbeulich@suse.com>)
 id 6a7c91ad-f2d2-0a2a450a0019-d1558033bc49-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 17:30:53 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so9743915e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 08:30:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c993d80sm59444825e9.12.2026.08.12.08.30.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 08:30:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786548653; x=1787153453; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=++9KTmKDTg9+8nnz6QZjHaF1GiqpVBV0WUi+TZWe2Fo=;
        b=TqkLfpryVaPCXSTESHGrmo3PJDhc5L5vSmFaD5Qivh03IBgzfZiH3ryjCwrCO2pJq5
         9DwzEGeYRWOxiFwXBOkKkS/1IYTR3ts09EVQ/n9ArCTeyQszGl2/5WqnOBIt1pD8/GOh
         5FPqIR293qTzY1gfbK8s4Lo/hEHZtRsKv+zyLNP0gcwsKJH8BziNTw6KABWxd1kYzrk7
         RH2zCgYa8h89jDCilsNNbMsgr+Bh/ba1bu/xJQW/3cP+gOB/WTiodIV44K8r4oACZH4D
         UXPFiuOFlSF/oTI15plR0vA0G6N7OToVTtBsGnNkaeIOIW43I/+ByhBwspnP0P6x+exQ
         VSFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786548653; x=1787153453;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=++9KTmKDTg9+8nnz6QZjHaF1GiqpVBV0WUi+TZWe2Fo=;
        b=OY4YC3Gay9GRkz8BfemwKCTJijwhOxXRuaEzZc5UWtFAEpCtko6XzpHDdwEJejz8v8
         FlNy9VkGlBCVG3V8jCpGRcbcU91AnaMxGcc7O9s8IpEP/2x+zOlQvQhXZGl79rhUlavN
         xCHfFme2GVaDfVTkTtwt4QHKkRS5u1x4s9p5IFh+A2+/LKRYBTPTKPLe6hedqpOGVPU/
         bur9f0ykTKNO9AHLgGm1jWxqMC1xAH578MfERkgGFolAGx8J6E/ktUqh0aqacfmei5mt
         qJn/VCB7hRScNFPLflXep0lyhMdsulUMjtTu/DCPPdV2GYatN3ytsZLdSarAlINt3vlL
         2lgg==
X-Forwarded-Encrypted: i=1; AHgh+RrjtGGF4ciFDEzyT48zCnWRHQSrseco4irmzUU+L1a0+uDjijy1R2atLC7cniCzIOkuqGmKRz87GLY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyz5V6WcSYLzDe3jElmYCgdjkDUvEToa++vZpj9Z2d6n2iqagpC
	rsiei5BpZHNUrZNHWo6Yuk7wo4GUMXxoODszh9WjLuPHH3EF2ZW30e1PruX+BEyhGg==
X-Gm-Gg: AR+sD104iyRUQ9fzO+M/DXn1EXA2KK3G4EqJzShsdEX9y6MWA3kbUB3nvCEjgu97oYZ
	9vHUOmTkteYTjGApE6EyxrQpm0JBv2TFX1Px3WgpnsiIDQ9d+KUxFl2cbEc/MItwdlpFtEyK2tw
	GLm/JX6q+/GCdfg6LAXxfDABSu3jHNqvMjxO435WVgK+JJbqJRfbf0SjO0/2gAF52wIJA54xDk7
	VMtvtlgzH0cX3zZhVeudP7gjtq/jd8sQwhxuOgOsv31l2bMJHzT9irB7dmqw8gDIr7PkoQXbwuX
	t9LRUi2zx9p1DR/qoDQD8yjTWgwUqM1QVwmGNH20La3/vvjvr7O1VhO/zxvxkkypCgz//lgjF5u
	HL+zPyAXYQBz9e2PTM0dSJ2pBDN/0U/dSu5ZNzhChUDfR+nf9IMpXbNAghbhtVP98HO8QY9gEZl
	q4Dfb2GUn82YE46HpnP7aCcG3Zqqt1EhnVp6wiGFSvxk8XXkDMmJ1E2P+xwhVVsWHnVTkvfeDkI
	0yhM86oSOmNC+jPdqPb8D1KrgM3zgnu2hy5U/fQTFllxklAPt8FHSpxBMhmz7qO
X-Received: by 2002:a05:600c:8209:b0:495:6e68:5df2 with SMTP id 5b1f17b1804b1-4997c13dd74mr88790695e9.12.1786548652683;
        Wed, 12 Aug 2026 08:30:52 -0700 (PDT)
Message-ID: <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
Date: Wed, 12 Aug 2026 17:30:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786548653-4A9D9CFC-449D4E97/0/0
X-purgate-type: clean
X-purgate-size: 5806

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> Introduce riscv_vcpu_unpriv_read() to allow Xen to safely read guest memory
> using HLV/HLVX instructions while reliably capturing trap context.

Both for the title and the function name: How does "unprivileged" matter here?
The same functions would be use for reading Dom0's memory, wouldn't they?

> @@ -114,3 +115,93 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf,
>      return copy_guest(buf, gpa, len, GPA_INFO(d),
>                        COPY_to_guest | COPY_gpa);
>  }
> +
> +/*
> + * Read machine word from Guest memory
> + *
> + * @read_insn: Flag representing whether we are reading instruction
> + * @guest_addr: Guest address to read
> + * @trap: Output pointer to trap details
> + *
> + * 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.
> + */
> +unsigned long riscv_vcpu_unpriv_read(bool read_insn,
> +                                     unsigned long guest_addr,

Personally for such a function I'd expect the address to be the main (first)
parameter.

> +                                     struct trap_info *trap)
> +{
> +    unsigned long val, tmp;
> +    unsigned long flags, old_hstatus;
> +
> +    /*
> +     * As hstatus is going to be changed we don't want an interrupt to occur
> +     * with guest's hstatus register.
> +     */

I don't think "guest's hstatus register" is something real. hstatus is
entirely the hypervisor's register, controlling the guest.

> +    local_irq_save(flags);
> +
> +    /*
> +     * The hypervisor virtual-machine load and store instructions are valid
> +     * only in M-mode or HS-mode, or in U-mode when hstatus.HU=1. Each
> +     * instruction performs an explicit memory access as though V=1; i.e.,
> +     * with the address translation and protection, and the endianness,
> +     * that apply to memory accesses in either VS-mode or VU-mode.
> +     * Field SPVP of hstatus controls the privilege level of the access.
> +     * The explicit memory access is done as though in VU-mode when SPVP=0,
> +     * and as though in VS-mode when SPVP=1.
> +     *
> +     * So it is necessary to restore vCPU's hstatus before execution of
> +     * hlv* instruction.
> +     */
> +    old_hstatus = csr_swap(CSR_HSTATUS,
> +                           vcpu_guest_cpu_user_regs(current)->hstatus);

As you're limiting use of the function to the current vCPU, why would hstatus
need fiddling with? The fields of interest aren't being altered between exit
from guest and making it here, are they?

Without that IRQs also wouldn't need turning off (what about NMIs, btw, once
supported on Xen?), which would help real-time use cases (latency here can
otherwise be affected by guests, by wait of forcing exceptions to be raised).

> +    if ( read_insn )
> +    {
> +        asm volatile ( "\n"
> +            "1:\n"
> +            "   hlvx.hu %[val], (%[addr])\n"
> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])

Imo labels used for extable entries would better live on the same line as
the insn they mark.

> +            "   andi %[tmp], %[val], 3\n"
> +            "   addi %[tmp], %[tmp], -3\n"
> +            "   bne %[tmp], zero, 3f\n"

Use BNEZ?

> +            "   addi %[addr], %[addr], 2\n"
> +            "\n"
> +            "2:\n"
> +            "   hlvx.hu %[tmp], (%[addr])\n"
> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
> +            "   sll %[tmp], %[tmp], 16\n"
> +            "   add %[val], %[val], %[tmp]\n"

May I suggest OR instead of ADD?

> +            "3:\n"

If this is an insn wider than 32 bits, you won't have fetched all of it.
I think you want to at least add a comment here indicating that e.g. it's
the callers responsibility to deal with that. (How they would do that is
entirely unclear to me, as they can't simply invoke this function again
passing guest_addr + 4.)

> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
> +        : [ti] "r" (trap) : "memory" );

You want to tell the compiler that *trap is written. Instead I don't see
why a memory clobber would be needed: You access a different address space,
i.e. nothing the compiler can make any assumptions about.

You also need to take precautions for not returning an uninitialized "val".
I think the variable wants initializing (perhaps to ~0) and "+r" wants
using as constraint. (Afaik & isn't necessary to use together with +.)

> +        /*
> +         * Although HLVX instructions' explicit memory accesses require execute
> +         * permissions, they still raise the same exceptions as other load
> +         * instructions, rather than raising fetch exceptions instead.
> +         */
> +        if ( trap->scause == CAUSE_LOAD_PAGE_FAULT )
> +            trap->scause = CAUSE_FETCH_PAGE_FAULT;
> +    }
> +    else
> +    {
> +        asm volatile ( "\n"
> +            "1:\n"
> +#ifdef CONFIG_RISCV_64
> +            "hlv.d %[val], (%[addr])\n"
> +#else
> +            "hlv.w %[val], (%[addr])\n"
> +#endif

Once again please use enough care that RV128 would at least obviously fail to
build, rather than building something which then doesn't work.

> +            "2:\n"
> +            ASM_EXTABLE_TRAP_INFO(1b, 2b, %[ti])
> +        : [val] "=&r" (val)
> +        : [addr] "r" (guest_addr), [ti] "r" (trap) : "memory" );
> +    }
> +
> +    csr_write(CSR_HSTATUS, old_hstatus);
> +
> +    local_irq_restore(flags);
> +
> +    return val;
> +}
For both reads and fetches - are there no alignment constraints at all on the
incoming guest_addr?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 15:48:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 15:48:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389196.1630086 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuBBt-0005VS-Io; Wed, 12 Aug 2026 15:48:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389196.1630086; Wed, 12 Aug 2026 15:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuBBt-0005VK-FJ; Wed, 12 Aug 2026 15:48:29 +0000
Received: by outflank-mailman (input) for mailman id 1389196;
 Wed, 12 Aug 2026 15:48:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuBBr-0005VE-Q6
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:48:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuBBq-003o9Z-Pn
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 17:48:26 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c95ca-2eae-0a2a0a5409dd-0a2a4505b826-0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 17:48:26 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c95ca-4cb1-0a2a45050019-d155802bdd57-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 17:48:26 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so10532725e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 08:48:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997ada79a3sm82551175e9.1.2026.08.12.08.48.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 08:48:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786549706; x=1787154506; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=3Y2t0eAdOGCQ68XOTF98/prJiMtMY13yhQEN9YiCxYI=;
        b=RC2zxXQQCHbACFwtBtAa5+aubVJ6FuwhPlJ/CxIvsgt6jg9HXAUfCFQs4RIWSg78Rg
         gpcCqq6ZlBfp9ngZ0KDb5kk4qSiWKXlUCD4W+bjUlhsygXnQfGEYYnBk4JNwk6edZQ8C
         5xARTVyUJjzN7QZykJGlYzdDOQWd4qqVOrYJp0DYRJBiXjqizYhUEMLJBkTxi805K6Sw
         5mGF9x8ldT5Sa2DCNlbqjV77bnYk2Rl50zbWrB4aWKoxAHDQcCmuKIRieGTritfABgh1
         FEGGCKlwXURktYe75IxLytzXRjxzOxQaBl1ulZGzy4lsYE4iSDTrqczDeocBYiVJz9Sz
         9sqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786549706; x=1787154506;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=3Y2t0eAdOGCQ68XOTF98/prJiMtMY13yhQEN9YiCxYI=;
        b=Vu3h3q9PVyADHXUSAKV4Y1wUYulDlDUu26rpecF1t5INH58uuWSOSUkE/uA0RB1Gw0
         0PAPpruv0Z7IfHsRRUB6If9d9Haxv1VY+ED9U03Wief9JRQAIWpd1XliUX77404P6FQv
         bhW0AyBowpkKkIzDkhZva2bVYkEtIc54dhxFDWSlkIOrem+hh7wVCpiXYh1jdLZ0df34
         JADPUaz7fBu3qLusXAjvpIeI8+2lkMDT/3V6RlJMK9erZ/2Nft9puoB0v4ZkhWIBOVkN
         mrJoVjdYnuOaFppyTxAb3+331Zz+L+AaoOEqUS28LyPhPtn/V1iAnR+d2M6jqvxmcFd8
         0osQ==
X-Forwarded-Encrypted: i=1; AHgh+Rpo7+7DYi2Pc6RQNfUge4o/WVweyvK2LLHbXZdu/035F3vtowtAaK9zsDRKnRc2sW1eCa6EmcLOM98=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzhg8ZLTZFJwFpjnmaWy4NMxIEpEBFb1S2WE5BJnPQI8Ar1rbGC
	ZXqGUSHqJansQVd0P/DpjJS5fgbUaqpd+FVPyo/srz3Jk0DQFeSZzuhmhNWRc42mNw==
X-Gm-Gg: AR+sD10hOccuuaiB6WnRRFe6qg2E7dMnCTs7cpumrS6pcUaD+5XdD1+1tgyzrIJpZI5
	Aavq3erEyktTYyqu5NXdytci+M7jOvyw+JUGLC9HHJi6ex4pzTkdJ8GkJRjBk7Om57rwI2E67ku
	AHYc6laEJl4bkIuUH/z+F5xnMLRoXbtTXOuaXzTtrgqc7nF8Ta6cHCzFfM0QjzhWTqpnL5OI7n9
	PqS2X4/CaNHNnjB8fwrXyZ4G5q+jH4n0pWYrRUvwH6ksflbutFWQRHs+9+G0WfDnM4J2BdGmVcI
	4CLbNE2hZa6xL9zPnEzLVuKwSc7uz2Y0rjRsSvYjQGSyXIFas9wT9evE/VNx/Rj8qFwtfZlSEWt
	ud53BQNw+n3B/XoD9eyvugwcFcZid2mBZZE3JPL5vJL/y3T2Vff2PLPMZY1BFuudPiJnB/kpd1r
	UtGF7luhJQK62Z92g9rTmFl1pnUGx/RUvjHWL4NInaOjcYhL+viu+87hdkxCIwko4E9INMT+PPv
	JfJkhUNIAcGRUncJ0zwBxMPHfcKbbHuv7OVRj8pJl0zmKPkr+sG
X-Received: by 2002:a05:600c:68d4:b0:499:49f2:bb86 with SMTP id 5b1f17b1804b1-4997c0f2251mr64846375e9.6.1786549706138;
        Wed, 12 Aug 2026 08:48:26 -0700 (PDT)
Message-ID: <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
Date: Wed, 12 Aug 2026 17:48:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1786549706-F74BC2A1-71D390D8/0/0
X-purgate-type: clean
X-purgate-size: 2056

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/traps.c
> +++ b/xen/arch/riscv/traps.c
> @@ -191,6 +191,67 @@ static void timer_interrupt(void)
>      raise_softirq(TIMER_SOFTIRQ);
>  }
>  
> +static always_inline unsigned long get_faulting_gpa(void)

May I suggest to use always_inline only when inlining is _functionally_
required?

> +{
> +    /*
> +     * According to RISC-V spec:
> +     *  18.2.8. Hypervisor Trap Value Register (htval)
> +     *   ...
> +     *   A guest physical address written to htval is shifted right by 2 bits
> +     *   to accommodate addresses wider than the current XLEN.
> +     *   ...
> +     *   If the least-significant two bits of a faulting guest physical address
> +     *   are needed, these bits are ordinarily the same as the
> +     *   least-significant two bits of the faulting virtual address in stval.
> +     *   For faults due to implicit memory accesses for VS-stage address
> +     *   translation, the least-significant two bits are instead zeros. These
> +     *   cases can be distinguished using the value provided in register htinst.
> +     */
> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);

Well, okay, but instead of not losing the bottom two bits you're now losing
the top two ones.

Also the spec reads as if htval only _may_ hold the original address of the
faulting access. What if htval ends up 0?

Further, nit: There's (once again) no real value in the 0x prefix, I don't
think.

> +static int emulate_load(unsigned long fault_addr, unsigned long htinst)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static int emulate_store(unsigned long fault_addr, unsigned long htinst)
> +{
> +    return -EOPNOTSUPP;
> +}
> +
> +static void handle_guest_page_fault(unsigned long cause,
> +                                    struct cpu_user_regs *regs)
> +{
> +    unsigned long addr;
> +    int rc;
> +
> +    addr = get_faulting_gpa();

Can't this become the initializer of the variable?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 15:59:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 15:59:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389207.1630095 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuBMP-0007Gt-FV; Wed, 12 Aug 2026 15:59:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389207.1630095; Wed, 12 Aug 2026 15:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuBMP-0007Gm-Bo; Wed, 12 Aug 2026 15:59:21 +0000
Received: by outflank-mailman (input) for mailman id 1389207;
 Wed, 12 Aug 2026 15:59:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuBMO-0007Gg-GP
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 15:59:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuBMN-00EkPw-Fd
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 17:59:19 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c9844-2eae-0a2a0a5409dd-0a2a4506c746-46
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 17:59:19 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7c9857-195a-0a2a45060019-d1558033f1f4-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 17:59:19 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so11796845e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 08:59:19 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997c9944ecsm59431915e9.14.2026.08.12.08.59.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 08:59:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786550359; x=1787155159; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=W+NlR5DrkM0LUd0bgKd1POAE63cAyrDlPzkYqiYJ4xE=;
        b=nN6HRoxXkssOUSlfcfmpupFhmJdFsgFommt/WqbNPANG6YovEYhZYGnLgZf793ocdy
         lwVs4q1H5VH9iS8q40rmIoIMTEJIr10msycV/AKrJ5EIpVId5X/PoS1yl/UjEdaong+T
         EIRVAe04u/AxTeEukAhL/ua8CZ2Cn0ALVN9BO+AcUnY4moZn3Db4TvOJ/3WasIxsSPyI
         J2qUBbDX1ORMoFRbRo+REH1stvD5ytExrQNH2dd/L+L4XD3MI1W2C7w1R1beq6l2LmaJ
         BJaCfWWzpUWW0xhI8Ekalac3WyYEHyb9PaQf8zVEKYAq4G7CnT1SQKYSsMnFF1CQJ0oy
         tABA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786550359; x=1787155159;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=W+NlR5DrkM0LUd0bgKd1POAE63cAyrDlPzkYqiYJ4xE=;
        b=XnK4aWgKij86vQpe/HxOsRurM++UVNVpjVpbgvicLHaPxJQv18Y6ExejWwSbDjDaoL
         fD+ciR3/GRyJXKmqyZakAPLcjxc9apf5vNlUEBVlM6ry/o0XY94t7PUYXJB3E9OaVrow
         nZvmD0CPfQpgghw3uTUV0P6DA3xeJwMiGX1qoiD8pAM5UfRn4aDNhEdkBAswnFQCkPPH
         7aSM8NNiO89f8NETTURIlXlWU042LeiTnylwW2osKUT/M5+urj2ebj37ri+svCSBVwSW
         VTpgFDTjay8fpMYGdzdaYMxfoSrl7kro3njIH5yktt2tvD+Ie84jvsCprfJw8p9mPxBR
         88Cw==
X-Gm-Message-State: AOJu0YzXPHM/9ylUipxsVUkmBGBMNraljHZ7770BuMT2k06Oyz5vtA3a
	kRDsjNeVewnHswkugTMLDtSWM5QDyowpEFnU30u3KJwA1unLgKwrVFiD
X-Gm-Gg: AR+sD11RYaqwSVgmW2/MQadW7hX8xPoAtVfyCEBKCmJ59VeRZVUhgfrkMfYJNQS+wl3
	z0PVf9Wzx5G/jz9cajrLug73Fxg8BerrrhtK1b1d295eYOmS9/H0qXTbSoNsg+6YqD35MmugVPG
	6WgjsQX3/b5PfemH1LNhqU4+i5uIX7UwsIxHbwcoYnHataH3sEPpofNV0i1FAq6j7YDqRp25+IP
	dlUe4F7reThNaEMYOZthRCjHpBJV+Ktj7KeaRppBgJHtcEYgfTZcQGvKwZOoFtSm1F0SuB5r8kP
	t3inAdQPJdfbsj0PxMAQ8laqPZHzh+Lkf8wlhL+k4e9WsnPD1GfSIcwuoX7qk5XYBESZYs/Pr7e
	EG88nCLqwLMVSY3qWqS3I+4zWpWEozStl+sUjweF8EO8AvcUHjnphZdSo5D8ga21Y6e5X3ongAu
	6VWk94dpOLLzXLGlVNhJtuhA0y+6+9Hl4gbR1vQKi/7uMG//ccNn3hS8vIZIqJNZrbm+DiQHUrJ
	XAyiu2CNrPqAZvFsmbIyunQmEvIoBcw3HKqrFp/eiY=
X-Received: by 2002:a05:600c:2104:b0:495:7a04:b006 with SMTP id 5b1f17b1804b1-4997c111b2cmr63905795e9.8.1786550358661;
        Wed, 12 Aug 2026 08:59:18 -0700 (PDT)
Message-ID: <1891f28d-dc23-48ba-92fb-9a0ac8ffd13b@gmail.com>
Date: Wed, 12 Aug 2026 17:59:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 05/17] xen/riscv: implement virtual APLIC MMIO
 emulation
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5571644f1d3a4277dc95fe85099563a145d1d935.1784560663.git.oleksii.kurochko@gmail.com>
 <1786543421.8631fc262581453bbf619ec5b2062170.19ff64938f1000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786543421.8631fc262581453bbf619ec5b2062170.19ff64938f1000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786550359-FC40377B-6E90F04B/10/73395122804
X-purgate-type: spam
X-purgate-size: 3290



On 8/12/26 4:03 PM, Baptiste Le Duc wrote:
>> +
>> +static int cf_check vaplic_emulate_load(const struct vcpu *v,
> 
> 
>> +                                        const unsigned long addr,
>> +                                        uint32_t *out)
>> +{
>> +    const struct domain *d = v->domain;
>> +    const struct vaplic *vaplic = to_vaplic(d);
>> +    const unsigned int offset = addr & APLIC_REG_OFFSET_MASK;
> 
> 
>> +    uint32_t auth_mask;
>> +    unsigned int i;
>> +
>> +    switch ( offset )
>> +    {
>> +    case APLIC_DOMAINCFG:
>> +        *out = vaplic->regs.domaincfg;
>> +
>> +        return 0;
>> +
>> +    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 = 0;
>> +
>> +        return 0;
>> +
>> +    case APLIC_SETIP_BASE ... APLIC_SETIP_LAST:
>> +    case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST:
>> +    case APLIC_SETIE_BASE ... APLIC_SETIE_LAST:
>> +        i = regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK);
>> +        auth_mask = generate_auth_mask(d, 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 = regoffset_to_word_idx(offset - APLIC_GENMSI);
>> +
>> +        if ( !AUTH_IRQ_BIT(d, i) )
>> +        {
>> +            *out = 0;
>> +
>> +            return 0;
>> +        }
>> +
>> +        auth_mask = ~0U;
>> +
>> +        break;
>> +
>> +    default:
>> +        gdprintk(XENLOG_WARNING, "Unhandled APLIC read at offset %#x\n",
>> +                 offset);
>> +
>> +        return -EINVAL;
>> +    }
>> +
>> +    *out = aplic_hw_read_reg(offset, auth_mask);
> 
> I think there is a problem here for the target registers: a read does not
> return what the guest wrote.
> 
> Consider domU calling request_irq() for source 10, with the interrupt
> affinity to vCPU1:
> 
>        writel(0x0004000A, GUEST_APLIC_BASE + 0x3028)
>        /* hart_idx = 1 (vCPU1), guest_idx = 0, EIID = 10 */
> 
> vaplic_emulate_store() passes this through aplic_msi_target_gen(), which
> keeps only the EIID and substitutes the physical hart field and the
> vCPU's guest interrupt file index, so we write target[10] = 0x001C100A
> 
> Therefore, a readl() of the same address returns that raw value (0x001C100A) instead of 0x0004000A, since
> auth_mask is ~0U here.
> 

I found this issue while working on support for the IMSIC software 
interrupt file. I already have a fix that I need to port to this code. 
However, I completely missed that this was already an issue and that the 
fix should have been ported earlier.

Thanks!

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Wed Aug 12 16:03:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 16:03:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389217.1630104 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuBQS-00010n-24; Wed, 12 Aug 2026 16:03:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389217.1630104; Wed, 12 Aug 2026 16:03:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuBQR-00010g-UY; Wed, 12 Aug 2026 16:03:31 +0000
Received: by outflank-mailman (input) for mailman id 1389217;
 Wed, 12 Aug 2026 16:03:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuBQR-00010a-7O
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 16:03:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuBQQ-007b8W-KD
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 18:03:30 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c993c-8faa-0a2a0a5109dd-0a2a450387e8-22
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 18:03:30 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7c9952-fae8-0a2a45030019-d1558033e04a-3
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 18:03:30 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4956242332dso10589245e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 09:03:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4997aaae7acsm83944525e9.4.2026.08.12.09.03.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 09:03:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786550610; x=1787155410; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=44tzlAMe2DMRuxp++yVpi01YJeWLEdKk2hvh5JUlNlM=;
        b=cRcSCIfnOFXklscIwvFaERc16vSWHfxzkmKPO0UGLmwpLN56CS3Ff2hweSgdSEs3X1
         TcGv2LuK2CJUiFJv53ocTU5xUuac353CZO+sZf2iozD7JbpuSQOFa02eJj3EFiX+a2YF
         D2+Mx69pepF2S9Pir8m+lev0JEGtmKqN+2jdaURwW4vES5DdbIXKZeIszC+FTEVf3QKM
         E/YDu0zhD8u+Dnj8ZnLvZb/pgUzr9Sto/B9Da93xcd8EoWDaLRuc1dMqalD46Hnco2zj
         ba9GivhKddGVgmNiIhHlGH+mLkgM6iKFzDwk/2eoF25d3pVmp3nDT0C04EBtjiq7IPyp
         raxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786550610; x=1787155410;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=44tzlAMe2DMRuxp++yVpi01YJeWLEdKk2hvh5JUlNlM=;
        b=fmqW7GWkLONhDsWsTylGSkSW8y6RKESVL5d9twB43iyAY/QkILREOqjfaNuuH4Ljtu
         pUl5iQrgTA2wgQd5w5q9x3CeaeAUm18vkXwY4EtjCrMsAdiNjHd3MB5jO7QBm7jUnn/A
         XSWcyc937v1svZwVs3vilpBsdNgwqQ+/Q9nZZCCapk4GgMDdZhHHPyiRCvRpYxFiAMJo
         5pFZj48fvotRjOf8nniNFqhnnk7iBdydomA3j6UKagc7HH6bJqVF0NLtOM2DInJ6gsgz
         sHHvTqA3scw3JFoKTHjjH6oHtSiIeSBo25RfCpiRVfNKywTzrP3FftyLhmcj6xKT5yKo
         uu+g==
X-Forwarded-Encrypted: i=1; AHgh+RphtECMsJ3dUvluvTFfOT6txp77Uv8185uyQodo7LmqF7fKlcG0s14I3FbokLVlGfFqgYRrciBVpVw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz0ve1QYx3mKF2DxVV3V923LH5DR3AH/RhZAoxDbwjQolgAsQc4
	vAtV0PMrCL7MRvnyl6bBxMuY7qeOCgrQUVvQ8PwfrjU0M2Bx1U4adoCzmBrcawKZQw==
X-Gm-Gg: AR+sD10CT7WxlgNRW6T7a9FqBFoZk37JacIY95ARQac/x4FL4iMPdz8/gycwNKnxqS1
	UVeUKI/u9ujxVZFImcdXza7OlYvCzoMiNxe0AseKxYsFpEz2Ugzd5GtIhdkBCHiww+MHufB2j6N
	7GVmmH9jt8j1aa96mmKdzQeyLOk3bTVUxHHZ5T8A7AnIDhcjuGccsB9m1a4Do8yGGdnbA02xKpB
	MNnxPh02xMw1dmhOz5j8BAKsia3zJUeo9/XYF07kq1dkWBR6tuAjyeGo5hcGwka3Nt7HSpjWsBc
	60nG+AfOa3KrG2/EdnHXSVmbLUQIstwJP7+jMf/FS5k85uc3TibXVZpuOBaFhZO37l3/k1A2os8
	9fUFvWs2yW5/VrQByM9B52QspK+h1QYw0vl0SPR9VCBs5eJbOvwglNUCZQ/+8dEVohKPVKT4a1S
	uEsgW5AmhkCqA1A/Z/zuQVUeaCn3/n293TGapjRozLw9a3IdbRdyPosN1ayiFlbxNY2eQL0hure
	+vUNkGxEOK9XN31Vr9mc9pvjGIjVtlPoShQUGWBvlhG1Gq/u5wZ
X-Received: by 2002:a05:600c:470d:b0:499:4d4d:822a with SMTP id 5b1f17b1804b1-4997c16007cmr71221155e9.17.1786550609819;
        Wed, 12 Aug 2026 09:03:29 -0700 (PDT)
Message-ID: <f3ca2cf9-49b9-4515-b634-6de4ae9614ce@suse.com>
Date: Wed, 12 Aug 2026 18:03:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 15/17] xen/riscv: implement trap redirection to a guest
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <8b14a7926e42c7e3308dc7f730334fed56210d81.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <8b14a7926e42c7e3308dc7f730334fed56210d81.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786550610-76CF84E9-90620B63/10/73395122804
X-purgate-type: spam
X-purgate-size: 4367

On 20.07.2026 18:02, Oleksii Kurochko wrote:
> Some traps taken by Xen on behalf of a guest can't or shouldn't be
> handled by the hypervisor and must be forwarded to the guest's own
> S-mode exception handler instead: e.g. when riscv_vcpu_unpriv_read()
> faults while accessing guest memory, or when emulation hits a condition
> only the guest kernel can resolve.

Is the plan to use riscv_vcpu_unpriv_read() also for reading hypercall
buffers? In that case trap redirection shouldn't come into play.

> Introduce riscv_vcpu_trap_redirect() 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.
> 
> 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.

For this last bullet point - how is a reviewer supposed to validate the
assertions added when no caller of the new function exists?

> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
>  xen/arch/riscv/guestcopy.c                | 54 +++++++++++++++++++++++
>  xen/arch/riscv/include/asm/guest_access.h |  2 +
>  2 files changed, 56 insertions(+)

I don't understand this placement - trap redirection has nothing
(directly) to do with accessing guest memory.

> --- a/xen/arch/riscv/guestcopy.c
> +++ b/xen/arch/riscv/guestcopy.c
> @@ -205,3 +205,57 @@ unsigned long riscv_vcpu_unpriv_read(bool read_insn,
>  
>      return val;
>  }
> +
> +/* Redirect trap to Guest. */
> +void riscv_vcpu_trap_redirect(const struct trap_info *trap)
> +{
> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
> +    unsigned long vsstatus = 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 &= ~SSTATUS_SPP;
> +    if ( regs->sstatus & SSTATUS_SPP )
> +        vsstatus |= SSTATUS_SPP;
> +
> +    /* Change Guest SSTATUS.SPIE bit */
> +    vsstatus &= ~SSTATUS_SPIE;
> +    if ( vsstatus & SSTATUS_SIE )
> +        vsstatus |= SSTATUS_SPIE;
> +
> +    /* Clear Guest SSTATUS.SIE bit */
> +    vsstatus &= ~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[1:0] is the vector MODE, 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 = csr_read(CSR_VSTVEC) & ~0x3UL;

Can there be a proper constant please for this mask?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 12 22:57:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Aug 2026 22:57:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389339.1630112 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuHtD-00083M-Me; Wed, 12 Aug 2026 22:57:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389339.1630112; Wed, 12 Aug 2026 22:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuHtD-000838-HK; Wed, 12 Aug 2026 22:57:39 +0000
Received: by outflank-mailman (input) for mailman id 1389339;
 Wed, 12 Aug 2026 22:57:39 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=SB+v=GF=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wuHtC-000832-Qm
 for xen-devel@lists.xenproject.org; Wed, 12 Aug 2026 22:57:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuHtC-007Skv-7c
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 00:57:38 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=SB+v=GF=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a7cfa60-2eae-0a2a0a5409dd-0a2a4503a602-4
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:57:38 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=SB+v=GF=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a7cfa61-fae8-0a2a45030019-8c4da68a975a-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:57:38 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id 8CB78A01BB;
 Thu, 13 Aug 2026 00:57:37 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vm75nda-YOVW; Thu, 13 Aug 2026 00:57:37 +0200 (CEST)
Received: from end (27.107.204.77.rev.sfr.net [77.204.107.27])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 2CAA8A019C;
 Thu, 13 Aug 2026 00:57:37 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wuHt9-00000003UIZ-3pZ6; Thu, 13 Aug 2026 00:57:35 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786575457; bh=K2N/W4F9O6aeQyoVQqNuuZgVgn+TvaMQdX1XBtYLZtY=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=A9uFERs+m/7aYQEcIu7tCCaZgZFaQqvKgBC/jWQJwgh0zMCU/Te/E1pZfFDent98q
	 NoNtCW3YLfLzPZZe6WqrV5zkm3NIHQhJCtDVPqfa+6iNKjIIYKeAOmcb5Q4xGbc3Po
	 2RtXiJ8t+x/43hNF3FYcHSpCmuxGIrvonfo3cTRlEGwxjCtqflW/ghpyU2Wz8Py6Ho
	 f2fS/1XQcVpYTyau9P/GQ4fZCT902m0AGUbztzgGcy20KmCrz+1LXXJNXr0h9tqHD5
	 zE3+4YWG3dTaqHo5NFlRXXwiVpe2vfO+Y2aBMbOgETKDDiGG8pXNxUwpR7tWcgTLfT
	 1AEHfLbFekCOA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786575457; bh=K2N/W4F9O6aeQyoVQqNuuZgVgn+TvaMQdX1XBtYLZtY=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=A9uFERs+m/7aYQEcIu7tCCaZgZFaQqvKgBC/jWQJwgh0zMCU/Te/E1pZfFDent98q
	 NoNtCW3YLfLzPZZe6WqrV5zkm3NIHQhJCtDVPqfa+6iNKjIIYKeAOmcb5Q4xGbc3Po
	 2RtXiJ8t+x/43hNF3FYcHSpCmuxGIrvonfo3cTRlEGwxjCtqflW/ghpyU2Wz8Py6Ho
	 f2fS/1XQcVpYTyau9P/GQ4fZCT902m0AGUbztzgGcy20KmCrz+1LXXJNXr0h9tqHD5
	 zE3+4YWG3dTaqHo5NFlRXXwiVpe2vfO+Y2aBMbOgETKDDiGG8pXNxUwpR7tWcgTLfT
	 1AEHfLbFekCOA==
Date: Thu, 13 Aug 2026 00:57:35 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 0/5] stubdom: remove grub-pv
Message-ID: <anz6XwsWjoNeHBxY@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>
References: <20260720081833.4122182-1-jgross@suse.com>
 <f8481120-00c5-411e-ad66-38ff550bdd47@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f8481120-00c5-411e-ad66-38ff550bdd47@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-33051d/1786575458-6F8C54E9-14F71FC6/0/0
X-purgate-type: clean
X-purgate-size: 5728

Hello,

Juergen Gross, le mer. 12 août 2026 10:16:58 +0200, a ecrit:
> Any feedback?

I'm fine with it: grub0.9x is really old, grub2 works alright in my use
cases and is maintained.

With thanks,
Samuel

> On 20.07.26 10:18, Juergen Gross wrote:
> > The grub-pv stubdoms (32- and 64-bit) are disabled by default since
> > several years now.
> > 
> > Remove them in order to enable removing quite some more code from Xen.
> > In case someone is really depending on grub-pv, they can easily take it
> > from an older Xen build, as there is no Xen version dependency in
> > grub-pv (a version built 3 years ago has been tested to still work
> > with current 4.23 staging Xen).
> > 
> > Note that after this series has been committed, some additional
> > cleanup is possible by removing stubdom libpci and zlib support, but
> > this will require a modification of Mini-OS depending on these patches.
> > 
> > Changes in V2:
> > - moved one hunk from patch 2 to patch 1
> > 
> > Juergen Gross (5):
> >    stubdom: remove support for grub-pv
> >    stubdom: remove support for building in 32-bit mode
> >    stubdom: remove building of libxenguest and libxenctrl
> >    docs: remove stale stubdom entries from stubdom.txt
> >    tools/libxenguest: remove Mini-OS specific parts
> > 
> >   Makefile                                      |    6 -
> >   config/Stubdom.mk.in                          |    3 -
> >   docs/misc/stubdom.txt                         |   69 -
> >   stubdom/.gitignore                            |    1 -
> >   stubdom/Makefile                              |   69 +-
> >   stubdom/configure                             |   65 -
> >   stubdom/configure.ac                          |    2 -
> >   stubdom/grub.patches/00cvs                    | 1022 -----
> >   stubdom/grub.patches/10graphics.diff          | 2297 -----------
> >   stubdom/grub.patches/11graphics-keyboard.diff |   13 -
> >   stubdom/grub.patches/20print_func.diff        |   52 -
> >   stubdom/grub.patches/30savedefault.diff       |  186 -
> >   .../grub.patches/40ext3_256byte_inode.diff    |  114 -
> >   stubdom/grub.patches/50fs_fulldisk.diff       |   72 -
> >   stubdom/grub.patches/60ext4.diff              |  474 ---
> >   stubdom/grub.patches/61btrfs.diff             | 3499 -----------------
> >   stubdom/grub.patches/70compiler_warnings.diff |   45 -
> >   stubdom/grub.patches/99minios                 | 1570 --------
> >   stubdom/grub/Makefile                         |   88 -
> >   stubdom/grub/boot-x86_32.S                    |  112 -
> >   stubdom/grub/boot-x86_64.S                    |  108 -
> >   stubdom/grub/config.h                         |   12 -
> >   stubdom/grub/kexec.c                          |  434 --
> >   stubdom/grub/mini-os.c                        |  771 ----
> >   stubdom/grub/mini-os.h                        |    7 -
> >   stubdom/grub/minios.cfg                       |    4 -
> >   stubdom/grub/osdep.h                          |   30 -
> >   tools/libs/guest/Makefile.common              |   15 -
> >   tools/libs/guest/xg_dom_decompress_unsafe.c   |   48 -
> >   tools/libs/guest/xg_dom_decompress_unsafe.h   |   28 -
> >   .../guest/xg_dom_decompress_unsafe_bzip2.c    |   14 -
> >   .../libs/guest/xg_dom_decompress_unsafe_lz4.c |   39 -
> >   .../guest/xg_dom_decompress_unsafe_lzma.c     |   14 -
> >   .../guest/xg_dom_decompress_unsafe_lzo1x.c    |   44 -
> >   .../libs/guest/xg_dom_decompress_unsafe_xz.c  |   46 -
> >   .../guest/xg_dom_decompress_unsafe_zstd.c     |   44 -
> >   36 files changed, 1 insertion(+), 11416 deletions(-)
> >   delete mode 100644 stubdom/grub.patches/00cvs
> >   delete mode 100644 stubdom/grub.patches/10graphics.diff
> >   delete mode 100644 stubdom/grub.patches/11graphics-keyboard.diff
> >   delete mode 100644 stubdom/grub.patches/20print_func.diff
> >   delete mode 100644 stubdom/grub.patches/30savedefault.diff
> >   delete mode 100644 stubdom/grub.patches/40ext3_256byte_inode.diff
> >   delete mode 100644 stubdom/grub.patches/50fs_fulldisk.diff
> >   delete mode 100644 stubdom/grub.patches/60ext4.diff
> >   delete mode 100644 stubdom/grub.patches/61btrfs.diff
> >   delete mode 100644 stubdom/grub.patches/70compiler_warnings.diff
> >   delete mode 100644 stubdom/grub.patches/99minios
> >   delete mode 100644 stubdom/grub/Makefile
> >   delete mode 100644 stubdom/grub/boot-x86_32.S
> >   delete mode 100644 stubdom/grub/boot-x86_64.S
> >   delete mode 100644 stubdom/grub/config.h
> >   delete mode 100644 stubdom/grub/kexec.c
> >   delete mode 100644 stubdom/grub/mini-os.c
> >   delete mode 100644 stubdom/grub/mini-os.h
> >   delete mode 100644 stubdom/grub/minios.cfg
> >   delete mode 100644 stubdom/grub/osdep.h
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c
> >   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
> > 
> 






-- 
Samuel
 RR> Ce que je cherche à démontrer, c'est qu'il est injuste de faire
 RR> l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
 un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
 -+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 03:18:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 03:18:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389401.1630121 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuLxT-00013m-7b; Thu, 13 Aug 2026 03:18:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389401.1630121; Thu, 13 Aug 2026 03:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuLxT-00013e-2G; Thu, 13 Aug 2026 03:18:19 +0000
Received: by outflank-mailman (input) for mailman id 1389401;
 Thu, 13 Aug 2026 03:18:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wuLxR-00013W-NZ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 03:18:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuLxJ-00FqZc-HE
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 05:18:15 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7d3747-2eae-0a2a0a5409dd-0a2a4509dd6e-28
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:18:09 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7d376e-be1a-0a2a45090019-94a39217c19e-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:18:07 +0200
Received: from pps.filterd (m0482517.ppops.net [127.0.0.1])
 by m0482517.ppops.net (8.18.1.11/8.18.1.11) with ESMTP id 67D2JWXZ2260180
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 20:18:05 -0700
Received: from cy7pr03cu001.outbound.protection.outlook.com
 (mail-westcentralusazon11010020.outbound.protection.outlook.com
 [40.93.198.20])
 by m0482517.ppops.net (PPS) with ESMTPS id 4g11q1sqe8-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 20:18:05 -0700 (PDT)
Received: from SJ0PR05CA0179.namprd05.prod.outlook.com (2603:10b6:a03:339::34)
 by SJ2PR16MB5796.namprd16.prod.outlook.com (2603:10b6:a03:56d::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Thu, 13 Aug
 2026 03:18:02 +0000
Received: from SJ1PEPF00001CDC.namprd05.prod.outlook.com
 (2603:10b6:a03:339:cafe::76) by SJ0PR05CA0179.outlook.office365.com
 (2603:10b6:a03:339::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Thu,
 13 Aug 2026 03:18:02 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SJ1PEPF00001CDC.mail.protection.outlook.com (10.167.242.4) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Thu, 13 Aug 2026 03:18:01 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67D2Kjqf3241892
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 23:18:01 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [44.208.76.22])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkgccvt0-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 23:18:00 -0400 (EDT)
Received: from localhost ([19.12.92.222]) by cmsmtp with ESMTPSA
 id uLx9w2NBcRJvquLx9wFQfv; Thu, 13 Aug 2026 03:18:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppford; bh=4343t8Syuieu+BnOI9GiZfKdRgH
	7XpgQgORJoVmSd2U=; b=FWwrPGZUuS3nA98LGKOwP7Qh8h7w8mihYhbAETvuexn
	GHEiOPnsWV0WoJDlTieBdLsStDXWI5bXCuPVbV5cspJ/w4kau8A4bfo++vTzzz7a
	h1nsc9tfleNku49fHEwpT+rUSjlWqhWS80qmNCwGykA3LQRFkbShViBEfONGBKn8
	2tg9DqXcuxv8IKzBZbM1ePq4zqKeCkAlb2RIyEkGZ8Ch2RGMFp3om4aY6o2xIp61
	9O4e+jZv/0X12AUGE8wg9d3cCxD6m22oFBtGw/dJuBnLLrpGLhPxOoHTBoapJJjC
	QGFRb1xrkwMdD6hMflBemX9+0Kf79gbxUSpU/4H7Fjg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ifg5YD5+Pmjr/YNRuMJ4L+c3roq5d4UA4bxJsUW9H6Wynr2FN4zgY3I/dPnR9ENDH4bVTFvU525mse7ako9q89kIvajRlj7s13P/53qZWzi+/uTDnt44+PGG+DEHRJz+L2MbmVK6BtjZJroRFpO7MlZ0eU7pOjHzTw47D6rAxAjiluCmNpoFSnXBGqmkz9zW1etJnbvH4zrpuU8m4Pk9BeNSCudorKu+tlbprHd5T2SF6re3AcXnG0YaIrlyj4fhro3fwl2kCKNrDzgh9wEvHDrNEdqtUwLZMQMUi3u5KjaJGl+Y0tzSeWjilkYAW+5rrsUsDvpqtiBwR7QL58t1Bg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4343t8Syuieu+BnOI9GiZfKdRgH7XpgQgORJoVmSd2U=;
 b=OAsyoCz1PJmRTwGx0jqjRIPZFNZBR+O0mteRdVSW8MY0Iu4ezpieI3IzGF+I7PdomY1lWBPJ9BdhZmq4I7unsLt2UPWzykvAOo4YABLp3M504gajLXYCSc2X9T+oeY7JK1tj5Q4xwOTeJ89Id0pZ1TzUmwbN3XEhxwJUcEDEBZreXNELG9kUrTdIae7UGPVFd8gfdmOOtQZE/Au8i8glsa3DRjtZtTOlK+GodtX5AYzJA+hekkBjMx1hjP42uk3FN2Z1W8N/UN7P2UUlMa4oKz/H1IwmgXApMmxWad8e3EXiaRB7GZ6z1rUHQO0bDudVE5p30673xqwzQ9ed9v9tXA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4343t8Syuieu+BnOI9GiZfKdRgH7XpgQgORJoVmSd2U=;
 b=jTeHiv84nwAD2F7Z+eW0RC+C1Aec+5SAwEizgTPpNaAIf4IweqDdRwQjNxiy2wrVuro0VUp90Ao7JAza2dw8HMfMbjT5nuFZNyaxhUMZ8HchLivlcYYfRXLFqUa11Y8nU6I3XhqxeNm7J/dpMPu9bRN90ySShecvOButHy163i4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppserprodsaar;
	 bh=4343t8Syuieu+BnOI9GiZfKdRgH7XpgQgORJoVmSd2U=; b=Jz1BaaWEhE8S
	6lISUyGM8G3Y+oQ8FW8tIFdQLu/iZiHo85ljkFGaW+AFg/1y0BDdd7xAcQDXjtnL
	Lw5W2HNyMzdM1llxScnu/+oB28GGtu1I8L2qHwQQFlh/mCuvuDcsHs+x3m7sWDws
	sfliBz+ecXYJVl8tLrYhikqn3Xe8f+CLId7iTiCnDMWN3oUMOdCqq9XTrr9nLoTz
	TL9y3GIWHhlJPeI/92YYQOlACCL4JcEVMGmIle8rJtEweutN21W0why6WLUOJ04a
	rk2IphOoT92jxpXODeEBTO+eWdrnAVUvE0dJ9NaNJjcNNCyNtbiGOFTBtFNI0FJk
	RFAV4VLA4A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppfserpocford; bh=4343t8Syuieu+BnOI9Gi
	ZfKdRgH7XpgQgORJoVmSd2U=; b=GPeqJHJTKS9kDzWnWO4IpYMYHZF0zzmsbNgf
	+0FKiKYZH9RP/u97B4UF8NcSsf0P1qv8CJK/zgOeBdDpk/S/TufVguMuqlFXVBlR
	gu6TILCdt+TkEr+28RwANcKhEadkAeH5sjvx2AG3N3y/iUHUWp1Ug9iITICUwy9u
	yoQOurIbRsHWIgXCNgx31yiFxJbB46Q8M1S67UIPxVVN6mqTIdI8MZYIt3e9EKBB
	iyENEhP0DpOoU7GTMxLIv91bALUiKD+qcgVS36WnnONni61AQu4uaG8VneA6EExB
	p/W6C2zt6axLUQ0c+swbXcW5oG9kgi2536aFK7CDqv8DmfYZww==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: uLx9w2NBcRJvquLx9wFQfv
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Wed, 12 Aug 2026 20:17:58 -0700
To: Jan Beulich <jbeulich@suse.com>
Cc: dmukhin@ford.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com,
        sstabellini@kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v8 2/7] xen/console: use 'unsigned int' in
 contring_{flush,puts}()
Message-ID: <an03ZgUB8AdMjT0x@kraken>
References: <20260728065049.1318143-1-dmukhin@ford.com>
 <20260728065049.1318143-3-dmukhin@ford.com>
 <75ed4871-f9ac-41c5-a631-b9894a84f221@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <75ed4871-f9ac-41c5-a631-b9894a84f221@suse.com>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 spamscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608130020
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CDC:EE_|SJ2PR16MB5796:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c2ec9fa-24c4-4058-02e9-08def8e97bde
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700016|23010399003|82310400026|22082099003|18002099003|56012099006|11063799006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	HcmiLmTlVN8t5N3ds155JDKDYDOKzcPIwnLb/sAUdL2FyBrbdTkaV1bwX0os3yR1Z2M4Hh3KZpVqp6tno6XBeke7ZatUdw3FfgKezy7OMwo5pyVonn+zkl5l9RfG+d8elivoFX9BVp5PcNkZi61NuO1vyRB6f3M8rX8MC5F++wb10Q9lZsx5ArYQLqwtaeT/Yk7CTPWEVbMLPShs6C0ZEiwhXuBEXD6iTsnig+I5Xlzk1h+tJUnOxePVgQ5oiHlwmKRXv043wEZxOXGVQt0358651PuUb8Ugqj6KSKehRkykHfVquHyEgNVeMh36u+0JyREpMRjCJmfyT9SwZkq9C5udA5P7LA2U2gzCHRNz1fVjaf3QlCPLiuLiEvroHZ7ArFef1lHV+ITZrn2b3GOPmzMKN3OEn9xfdwcI6K1Zc0pECnrYO0DJR0rN853ELlY3OsXiZJk+ezWsSZKRCO3BdW5hej48d/LzSrIfzPOe5dUc4hRRPurHYBh83QmJVzJ2eQBPS06K3iHpTBElfC8j8VP+XEBxzlZOaOtnEUcWdYlAFS8/DpLkwosU6VK0jlqNjd1LZ8h1VgMcWSWhCRFb3ipslkmT/P/b1yLO3JWt0WNOwD73OmVNy9By1IUyvZbgTKsOLeHgqKHTEFpKEapl99ESmaPRy2/PmA0iBST+f/yV4kByz5IdWdbJS6h56G080RwI0VAjz4PJtEQZa/m8dA==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700016)(23010399003)(82310400026)(22082099003)(18002099003)(56012099006)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	PkUrI9E7W3f/luVTCHZqAe5flxnEl6aceT8IzZQln/oRXDL3PcVVfFqQAQNeIFAF3wnEo5RpVCnNybIYBt6T12V8qGopquObXOE8HZy8Z86cz5d6rC7zMhe0arLZ5wBTRlemiquHFj/FGsu8TLqjgt4Twl50a88aLiRpi1ZJW7eCmsoyD08AJGmODzY/pgbCSIZNDC8RV5qBxrKrDtgqBFYx1c4aJPCIQcKkScdCXRi3noMDGrUkVds2CBWT1kS/0WVEq6A5UjDa02Jpb5PNq0iBrz6M+ySXAQFytAnaZ/9Girph5ryRygSkxF5OR+y1GC6t1rIh0NnuNi4y+PVwQlBTPFk7CayGv/XQ2vzNC+4LODxYqlgEQRFgrVWqeBMtXhFjeByo3UaxBMfsKYVy04/zjnsZ5rjTUAGGnmK9w2QtHAVYkIcbaLbrgbulb3iN
X-Exchange-RoutingPolicyChecked:
	jkFC6Vr5snA4+U5bTDEMnWOgZukZIJbXYYR6J0+HXLZUe2HtBGGxhalDxkNCzCGdwGm1NaVl823tCzMsKfPSBGmF5YZCaNaAVKCDHGghE+F3cHx0x+CYA2FHPHs/O/jIa9JStHrt8yxNgR6bDX+JUkcsjk++L/lNY+Rt1iTiICPaX0cklsELMZ8yHizEUP9h9eeA31nn7PRJvQFQn2Hzty9+Wx74QnLV94i/l1rQ4qM1KXKZNxUEROfFe7dJJIdGx6jarhBRLUKi8KMBV300H5NZSBsCoZBohosbPbcIKjwfI8q2EwBVGfx1XoREUGv+LhVZEZMgBbc/G8biXfezpQ==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	R42oWNzTfsbpnJdYnHJ4Tl8JbpDM6OqpZ/P9cdacgzj6ZU3+GhRAYnfy0I2jYf1QLpSz0ptlOTNm7ievFeqYiu4B/xd6Ke+pY/MFPpK0rdI8SkmKO/9D644/EENDP+PnwAvW3jw9ZiHSv+vt1Jxt4fdXxlY03ajwd8UB3P+0FQ86wDY9IC761WWZ6m5GOllFTYm/N+LmCFf0IGkeghhDfOZ1WGiOz9DOkFAO6GHEldY2FtFrp31QZaXxNGOimShZnvfMgYfaiJpZP3DaolOBOLJDcroVT5zzFkJ9zALz49xP46ESaWBVGxgO+6k4wMbs+8kbNaSDH3G5UwzBzsHhVv3z8zHG6/3kxVFyGKmHzPmFDUrIKPWH6lLOlSSnoI0fVz9RP2Jr3DDzrSITUzEwX8yyZyAhqWylNcADuLwJ1oEmNHBur5YR4IkFyh/NFUAPWdoz8SoQXe2W6dFHxFv4loflo2ex8OU4Pluu/62BRm15dI1MUxhlExBggO4EqeTYaYCEkuDcDvjxBgRagCFuTrHzN6V57DbI1CweT6DoOdpvTt5QISnV4vQKn2gt0NWsVkQsiumudQJiOCo/ezc8j+dkmOAJf0PRhlRWAUV5Vpy9W4nVcBAtQmGEZi/UzjRlFoPGMda6EnjUdY4VTaXJSw==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 03:18:01.9611
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c2ec9fa-24c4-4058-02e9-08def8e97bde
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00001CDC.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR16MB5796
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEzMDAyMCBTYWx0ZWRfXxw86Y0I0qATz
 Sk/9GGeDQzHyPCp8cVVz0v/HDWtbl6zZomN8RUGHd8/3L0VKSKcX2zRl9f4GimZ5u4E4jlEzFif
 GxQVGSyeEkxsD/SbOUKEPLPsP9qA0gQFY2z7Fuau8xfJCpFUnSZJwi+VRYrg+65JHWJqKv6jON8
 T1i5fTa4fZSN1AShENjGD1QWJRePkpLhAtx/gro7uiePlJxwj9VUskHZC5WHtdRoJqSQNrZpa0D
 tQMKFLYohj5CrqxzcW/jmuzsYa/XzLJ9kNuhnnhdF+mt05qhzM/alaOKE5ogl80KH0LF6UfKEIm
 XxYQcbPaGZ21EReiXxrAhWZhWebytWjBDYTxMoRKC6+2jCpKwp4EkV9P9HDfJdO4/T/JVgWOF0Z
 rNfbY7Gdli6S/Ot6LMeje362HllzWdklsuajodAKfLdjDn5deo8T/Gu9LYUznm4x2W6BdvKE3DJ
 7Yb44nS+bD0/raB6m0A==
X-Proofpoint-GUID: XL9RE7S9IsDDoRIXIUEogsE8IAcKZONy
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEzMDAyMCBTYWx0ZWRfX7FnNAziX7Pe7
 9g095VufEzSbE3nZ58w+3xfM0TLjKXFyZfEUbZsM63dmdqVMvy/S+O7WmMmRevSFiZSEnMzWuFu
 +J2ZPPRrHZm/nthpPfxdWKBrpRjWYSJSzn9WL4cSv00P3MIqfWpW
X-Proofpoint-ORIG-GUID: XL9RE7S9IsDDoRIXIUEogsE8IAcKZONy
X-Authority-Analysis: v=2.4 cv=G+ss1dk5 c=1 sm=1 tr=0 ts=6a7d376d cx=c_pps
 a=6EvF431pKSa3MhyLnoL1tg==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=MLwXIh1eZMowsRZfVxRb:22
 a=cbNQJ9GKAAAA:8 a=2CfHQkRvY1sBYW4dv3IA:9 a=CjuIK1q_8ugA:10 a=zZCYzV9kfG8A:10
 a=3whSkbs7g9Me0DR5EJEX:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 spamscore=0 malwarescore=0 clxscore=1015 priorityscore=1501 impostorscore=0
 lowpriorityscore=0 phishscore=0 suspectscore=0 bulkscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608130020
X-purgate-ID: tlsNG-bad1c0/1786591089-BE0C5034-89EF6A28/0/0
X-purgate-type: clean
X-purgate-size: 693

On Wed, Aug 12, 2026 at 12:30:59PM +0200, Jan Beulich wrote:
> On 28.07.2026 08:50, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com> 
> > 
> > contring_puts() and conring_flush() still use 'uint32_t' to access
> > indices.
> 
> I took the liberty of adjusting title and description, as ...
> 
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -375,7 +375,7 @@ static void conring_puts(const char *str, size_t len)
> >  long read_console_ring(struct xen_sysctl_readconsole *op)
> 
> ... conring_puts() is referenced only by the hunk header, while it's
> read_console_ring() which is being adjusted.

Thank you!

> 
> Jan
> 


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 03:19:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 03:19:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389411.1630131 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuLyy-0001cm-KE; Thu, 13 Aug 2026 03:19:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389411.1630131; Thu, 13 Aug 2026 03:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuLyy-0001cf-GZ; Thu, 13 Aug 2026 03:19:52 +0000
Received: by outflank-mailman (input) for mailman id 1389411;
 Thu, 13 Aug 2026 03:19:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wuLyw-0001cV-RZ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 03:19:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuLyv-001cUk-Hz
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 05:19:49 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7d37a0-2eae-0a2a0a5409dd-0a2a45028cec-22
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:19:49 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7d37d3-6ca4-0a2a45020019-94a39217bf30-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:19:49 +0200
Received: from pps.filterd (m0384718.ppops.net [127.0.0.1])
 by mx0a-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67D2JTGX2097940
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 03:19:47 GMT
Received: from sa9pr02cu001.outbound.protection.outlook.com
 (mail-southcentralusazon11013029.outbound.protection.outlook.com
 [40.93.196.29])
 by mx0a-00498f03.pphosted.com (PPS) with ESMTPS id 4g116n9x9j-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 03:19:47 +0000 (GMT)
Received: from PH0PR07CA0004.namprd07.prod.outlook.com (2603:10b6:510:5::9) by
 DM4PR16MB5435.namprd16.prod.outlook.com (2603:10b6:8:185::5) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.315.14; Thu, 13 Aug 2026 03:19:43 +0000
Received: from CY4PEPF0000FCC3.namprd03.prod.outlook.com
 (2603:10b6:510:5:cafe::5c) by PH0PR07CA0004.outlook.office365.com
 (2603:10b6:510:5::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.14 via Frontend Transport; Thu,
 13 Aug 2026 03:19:42 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 CY4PEPF0000FCC3.mail.protection.outlook.com (10.167.242.105) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Thu, 13 Aug 2026 03:19:41 +0000
Received: from pps.filterd (m0426315.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67D2K6163320449
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 23:19:41 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [34.209.42.160])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxpbsmr9y-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 23:19:40 -0400 (EDT)
Received: from localhost ([19.12.92.222]) by cmsmtp with ESMTPSA
 id uLyjwFwkcgWOHuLykwlu9W; Thu, 13 Aug 2026 03:19:39 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=fail header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=ZOM
	sx2hzZFceQKaRJRDftcMORB/FxgXZ+8Bbs2Qgpwo=; b=Z6XvUIDQ+4X1oGpkMbk
	1oUImWORI88ITEzCINEm2uVZ131RlGl51nB/3nODZEYyi0ZZpxax2NuL0eK78sUt
	CTxF7WBY4UOFQ5rAepZ/rb6p/+iU7hoEBWHK9OdMN+Q7+y0sSt28EzDcUDpUwh1R
	9byCLxo/zSYMCmZpG35b2sW50E/hRSWz0no5T3a8XIYeE8E5DQWLSp7sEOrVw+5T
	vITf2fRV2ScF6Yos+stehVyNqct4DScLZKJGxr6vurGA5g7xug31mig4qqdcu2+3
	debB9L/J20vpEdq91lKjYb1u+EPpNbNoMdX+SrA4VKc0cVpIfCWM+60p+aUiHGth
	e4Q==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EnG7zXX5FKde4ZvjaC9AGTZuG12DRfovBFfOiHw2QM6ajBNGMmhaDWZlvsQRx5AUVa07bfZ/4UexFYdWRpFQAj0HuTHhbeKnbtaXxjn/nY+q9pI2XObgPAUyFbQ3pE/9sM6l01QlUyq7GXt/RM8kuQqt+6TLS9DLx7oI7V5llcxcVUy8bHE4O9H3F/Cfmf3K5v+zvnwGkeMyzxEHmckJwGgIKi3/nam2HROQRreclJfzj0pNjro2wFxhcZZEoXlaV1ssmmhYwVYecXcf604GqYVqtIwuulz1dO6BBXd8qJ4grspcLd49RHbdliVEipgaUKjvAjICDZqu8SuOp7U7yg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LMqnLhC3fHEBZQ89VJQmiBEAGMJpD8dQA2/BoKcwN7U=;
 b=og3CzP6Ih4nE0AGrLaYigj+5lTv/ilKtfU1uZz5XM8zHL2Bt5pGrTJY6MSMOvad3sOXF1KknlQSBNLMJNjsLPTnpi1DbGXr+M23yHLuvBxSdqhAGcpkcRjCIliKM6mLOWlPa7aP+MgU8PNBlhLkBHLViRfuUfyufEfzvkF5vgytvY8CD6ts+C79a4vMeJ2ijKmCN9mPFeKjTS8+/eRvdY5P4yT37DgfDyBY+0JZWe6B0zjPnYtHW+pmpZW8SsNzOynrTSQKVsKg6DAWunlepa/UGtFeQwWWZVHNHq/jvpC0ycp4yr2hlNKvDYfxG8doruOLMXKm0EYQlaJZ6Fatowg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LMqnLhC3fHEBZQ89VJQmiBEAGMJpD8dQA2/BoKcwN7U=;
 b=IfV5LRtMveBw8q1FrHa04iu3HA+Icq1BYOxtlH69Q9f9BepL1nmEvYHg4G7S1N0gWlMFAxQq0MqhGbcG2IdZiH3/crQRsuzBjXuH8DXcm8vin6TjEcgJOaQ+ef3ZjBSUCt8VKo68q4LjNyA/wt1QKbRLOMqe2v0gMynnOGjVs5c=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to; s=ppserprodsaar; bh=ZOMsx2hzZFceQKaRJRDftcMORB/FxgX
	Z+8Bbs2Qgpwo=; b=UEQ5ckJsSfgzL0zSZMsw83RfbMPc/Txw5L3JLcal9WwtneQ
	JyBRfLtNTj/png8rr4rGV+cuSZBILMrg8gvHIEW9iXpyzOQwMDc3wjCJdBCrz7dM
	H6qUcsWpRjpHpKj8jeA6xJecoTu146ROUIkpgKevu2oVW4fa+NE3ywJaY8rEj0em
	au4+HzFK0YAVHNl2/iaojZ5bbr0Ot4oicFJYyztQyR3UlUh+SECPcD+p/oOpqXBn
	BI5MczWmQDSyCh/jwwpfa7PpsjlEL9njUPOUluBn/9cfJMJ2vo92lnwVsCn8d2Ub
	cbnu3yRz6fiyH8TN01+4dVpdvMuLA+BlWrnNdLQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppfserpocford;
	 bh=ZOMsx2hzZFceQKaRJRDftcMORB/FxgXZ+8Bbs2Qgpwo=; b=feG+aNEaZPDu
	/UijusRCIL+DZ+C6JJG6pskn2Q/PCuH/C+uY+w5M3NgYxw9nbxp2I3rptHD3NM3N
	rD1hnc+4KmQXGC6wSvyYrNa80tdEMslcfgFnWKyglGS5y6dhHjL0HxQFmGhh/usk
	G0y8FGAPyILcxx1CO9r7EtgrS5kvOSn8de4xNX7bouY1Me/GVnFUaDUkQNcblWgS
	6R39BwbxPzPFvadwHhuu7usrA45R7tgXnk2/cJo0f/BJqh14xvtJqKv/2oxBF8Cb
	2e4hqCp1AG0lThONr1FoVlQroCUMGmBUKQHAHJ8d5o+BeSmiBIHcEPiLXfQyuKSV
	WF5b2iUTbA==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: uLyjwFwkcgWOHuLykwlu9W
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Wed, 12 Aug 2026 20:19:36 -0700
To: Jan Beulich <jbeulich@suse.com>
Cc: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
        dmukhin@ford.com, xen-devel@lists.xenproject.org,
        andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
        michal.orzel@amd.com, sstabellini@kernel.org
Subject: Re: [PATCH v3] xen/common: add keyhandler to show Xen command line
Message-ID: <an03yMkWnZa6qcMR@kraken>
References: <20260810230359.671587-3-dmukhin@ford.com>
 <anrXvTfBls4flBqK@macbook.local>
 <anuMfq/lDjxbR8Om@kraken>
 <ba78a8a1-6862-41b0-a6a5-cae7eada3627@suse.com>
 <anwo2QtEh9tObNDD@macbook.local>
 <7ea460ba-e2c8-45a7-9b7c-0cddcce275e5@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7ea460ba-e2c8-45a7-9b7c-0cddcce275e5@suse.com>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0
 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608130021
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC3:EE_|DM4PR16MB5435:EE_
X-MS-Office365-Filtering-Correlation-Id: d851d3e9-98bf-4017-1433-08def8e9b74f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700016|82310400026|23010399003|18002099003|22082099003|6133799003|11063799006|4143699003|3023799007|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	aglB3rq+r2y73cj23/mN6LRnrFSGfUR/mJ49Q2C3k2pyrWUIhP2Vvewn6akRfP1qFIbEr9BFGVcTQBDKDMuPWB3ryE41f2VPN8kRDWeFCfILpJNQERJecFcz3yuomnybpzLoZfOlHY7VNeHR0lDvlivJL1C8oKdW5KzObzNLBfRkVCL/EXxOpP4Mq1IDXqvDETpPhJwhBxu/LXd6S3JG1LevYuA4RmhreX3AVK54z9iVN5wGEIo+PZL/OdjRcuheyNij9J4ai2AovZ7qf9ACkEnFpLw0vrRlRnw11XrMtFaZrl7CfG0pCVMvJb2MgZJzmF7blRRKdGPG88WdIwHPvj6Th0yxI3wn+Y59Cjo/KuioeVvq5umRAz2juFMSN8p0xWsCVI1y1paxejZGrbdRRuQ9fXeimUum8+y/11L/hM0aUQi8ZnHU9F66XrJ5DJgF257NMB0kRuCOlvZ+EQsVeAxli5t7qad/gzP6f7VwNW2/0mPQJoqnrTYnboUQvga4yKdgfJPG3CYr+WpXNRoP+QU21wDKqo7mtI2TekiT8/1a41olL1ByN2NINKZGBGPaJHsSWgPixFAbySmA1YTOFLfmKo9u6Ia7KCF/2lPFqW2KqXOrT6twTRmN4TuaqdQgmD80G7NHK6Vq+vO/Co0aJ+dAmUFXQ37Ff9KZmHmakad+Oo7F/8H3FTdJnsabTCLAN11RlW4O4VwzB0Craquv/Q==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700016)(82310400026)(23010399003)(18002099003)(22082099003)(6133799003)(11063799006)(4143699003)(3023799007)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	L978hhN0/QVsq2T6UpEvux7LupaCLoZL8vTzRT+p1boPR1GbimSbCJmMyWOniZuGVEi0Gcr1lJvAbYaqK+zgtwrBCVC9Eci+L8AYB4k0eFfwGMW0AYyZVctvVacuBlNyHeHAFv3yEhRkYHbiur5JTju1VeG4DFSnSSYhViMZG0J2nv3DHamfEj5oixPNrpiQHfMbmflJbiuYDBuGu/sI615n7P78BzwmTzBBeCUHa327tdytjxkeRMdOhbREXnnHR592ey5az+Oief5xP7BCoE/SkpFTDIIn0V4Q6fbpgjEU7+vnzciOVAUmPUKE3V+n5sEzagVXOivQbW6Tn0p5VOWrfzxghNfHDpOpXC1Nlgx9wByrBuFdnv3vzdJMhbWhbIKsqBbRlOpMz7NnoETde0u9AfTy7LPtPNTalif5Lhtkylakp/Gt/wgUzlLFLQHP
X-Exchange-RoutingPolicyChecked:
	n0r0eioBFAQ+1dBR99KSwTaqdUXOsJGQI6401FwJpXJhKozIcs7v72EKwnoklXG0oKnKvJ38nO/Et8dZMdghPuYysk/4/w+KnbjvWdfxfXXrdp6VQ/a0oU1h/hYVHVGA5aX+HXNhJlaAG83yyx1DC38JY8aST9mvV7nI+he8xZ+hu1BT1wC0R8LwwbFkgNYijf/aj6Vhw2g/PWL1h32H5bmPI0xRUEMzw0Q38ZvD1fSlJWj8H11AiAnvHscoCIhShF8mDZq7UNpH5EdiHOyg9aqU2S41g7oM6pRdfym1cMxY+NKh8zrMLqUC3OqaNDJwhGBnaN0GcMwWaSL9+jDrfw==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	aaO9OtIiEhirSYXo2No5zGRMOkeK+sugGJNYXL2owu0ObIWsVbaFLNkTvRDBxGc/SGSFIBsPH9KwdsiwttxG9f5Q+qRfICALH0BX389snlZoKetFzNoa0ePWpSwNZF1X+U8SpzbWDc261PAmKjSPQvkkekRccXB/FXJCus9J48tBIxNk7K4+9JJXdmLFVzwPiCrBCHiEgzKPQLF2XrGdsatrD8jefcKxyKN8KcDCIsMits1eBjtUHjUybSGKGtoRoZejNYGsRHUjkpi1crxIPpsXWBt5q0lNikVFBe/91SiRgvyldX25o6aLnkEDuenqD9dmj6g3Yos9da6CXIM8w17/bBJvVroFQv/91ca2YkGkD++CymvHrPrro6+MEDGIVXnd0P9Bp7i/sCCFzjXg92mSosmeaFcWea1pM74LnpzQweyzoIOCNhxhqPQ7FOnscKwJ1XgzQN7OyHwckzhIvCPZHAqtGVqKYsJjcVNKtmRYZvhFz14GUsvOP61QRrrEz6hnbKyBSaOxkvhxskBsC9YfzLWkVXXfLRJduofBl0QMG9Ji7kbwMRPyoi0ZROTWQizpCvUM7FrNDc2qbKFDBM9PueYpSFR0Xoznsxv0LUK5736QW9ADV2Vsl48dUEdUdTvYiX83vjSNeHqeITeqcA==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 03:19:41.7735
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d851d3e9-98bf-4017-1433-08def8e9b74f
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000FCC3.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR16MB5435
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEzMDAyMSBTYWx0ZWRfX1nuaTZMgbIqM
 wcgFfzBFTnVWz8u1A6drUXTnqwlZ78cAq28126y21hZJPBSbhm/iK1rWA30KjK0GSW26NgR9f0l
 CC7n9hWPo3ZuXX5lJtrSNR3d8UaZmCeHO+HbyeWwLO7lnxxr987v
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEzMDAyMSBTYWx0ZWRfX+QWbSgqfdBiF
 wukgoQDjLR/y1eCytSLLgqT0w7VusaS6PqitFoC1dihaz5xMkiqqpJL6znqYdsqjGEjExkX51C4
 Vnt0Cz1OMK3AInvmIuyL4Ctqia+YOOCjIFoksrnCxmqW2emYraazTCNQ1s+6Oebf0packmlLAeS
 spkfNaScmX6sCA5kkmYPIeNc6wCcNJ+k/wviPRkbUovxJokuEMAFDKXni3avbCcH7vbh+mfP8aL
 SU1vZlJ6wRL2qvA69i5dexyzZqSVs8u6U+b7A7WtRwsVJsE5k4Gm4YFAnepqw1V4ma9Qwz6hNFb
 Yssjn0vVQW8Rr7XV1e6OFKtUW6B0840grHBea+lftmCmm4nng1YnbYFDLqSWV7stxHJtfCiihEV
 StjLpLp0KMj1o+lg98+FL9zxq1YQgMnE/2KHlefFnACEg7qVm4uLCDPGvUfW1PZczXtlr/EKMxJ
 Qj2dmb8XwQqhFSStKTg==
X-Proofpoint-ORIG-GUID: ifhfFWXUTLwGe20AbpTVANeOv2uP_aGi
X-Proofpoint-GUID: ifhfFWXUTLwGe20AbpTVANeOv2uP_aGi
X-Authority-Analysis: v=2.4 cv=R9Qz39RX c=1 sm=1 tr=0 ts=6a7d37d3 cx=c_pps
 a=y599upwrfiZ3HV94zaFOUg==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=8nJEP1OIZ-IA:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=ARvDHhclS48edyKYUbLB:22
 a=cbNQJ9GKAAAA:8 a=NLsUbDrCpKz5by7Mb1gA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
 a=P0bj-C3X3jJDpopQwM1U:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 priorityscore=1501 suspectscore=0 spamscore=0 bulkscore=0 impostorscore=0
 malwarescore=0 adultscore=0 phishscore=0 lowpriorityscore=0 clxscore=1015
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608130021
X-purgate-ID: tlsNG-720697/1786591189-F12A12AC-530FF18A/0/0
X-purgate-type: clean
X-purgate-size: 2442

On Wed, Aug 12, 2026 at 10:19:55AM +0200, Jan Beulich wrote:
> On 12.08.2026 10:03, Roger Pau Monn� wrote:
> > On Wed, Aug 12, 2026 at 09:28:46AM +0200, Jan Beulich wrote:
> >> On 11.08.2026 22:56, dmukhin@ford.com wrote:
> >>> On Tue, Aug 11, 2026 at 10:05:17AM +0200, Roger Pau Monn� wrote:
> >>>> On Mon, Aug 10, 2026 at 04:04:01PM -0700, dmukhin@ford.com wrote:
> >>>>> +static int __init cf_check misc_init(void)
> >>>>> +{
> >>>>> +    register_keyhandler('X', show_hypervisor_info,
> >>>>> +                        "show hypervisor information", 0);
> >>>>
> >>>> "show hypervisor information" seems too generic to me, almost all
> >>>> debug keys could be defined by this sentence TBH.  I think this needs
> >>>> to be more specific, but I'm not sure what's the plan regarding this
> >>>> key.  Is there an intention to print more stuff here, or just the
> >>>> command line?  Knowing the full set of information to be printed might
> >>>> help come up with a better name.
> >>>
> >>> I will update to "show_cmdline" since I originally planed to expose Xen
> >>> command line only so it is possible to better debug a system when dom0
> >>> becomes almost unresponsive.
> >>
> >> Yet as indicated already on v1 (I think) - a precious debug key character
> >> for just the command line seems rather wasteful to me. If it's only the
> >> command line, and if that _really_ needs exposing via a debug key (i.e.
> >> if there are reasonable scenarios where "xl info" cannot be used), perhaps
> >> attach it to e.g. the 'h' key output?
> > 
> > I was going to say that we should not overload the 'h' key with
> > printing a possibly long string, but I see we already print a bunch of
> > information there, like the buildid and the compiler banner.
> > 
> > One option would be to introduce a new debug character, and move the
> > printing of the buildid and the banner to that key, together with the
> > command line.  Then 'h' output will be cleaner and just print the list
> > of installed handlers.  That would give the new key more content, and
> > help cleanup the output from the 'h' debug key at the same time.
> 
> Hmm, yes, that's definitely an option. May I then further suggest to use
> '?' as the key for this? (Or am I overlooking that key already being in
> use somewhere?)

I did not find '?' being used, will update the key mapping.

Thanks for the suggestion!

> 
> Jan
> 


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 03:30:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 03:30:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389420.1630138 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuM8p-00042e-Fz; Thu, 13 Aug 2026 03:30:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389420.1630138; Thu, 13 Aug 2026 03:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuM8p-00041w-DB; Thu, 13 Aug 2026 03:30:03 +0000
Received: by outflank-mailman (input) for mailman id 1389420;
 Thu, 13 Aug 2026 03:30:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wuM8n-0003id-EH
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 03:30:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuM8m-004vYM-5v
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 05:30:00 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a7d3a37-bab6-0a2a0a5309dd-0a2a450ba816-0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:29:59 +0200
Received: from [52.101.228.89]
 (helo=OS0P286CU011.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a7d3a34-b7e8-0a2a450b0019-3465e4595a32-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:29:58 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by TYCP286MB3775.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:38a::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Thu, 13 Aug
 2026 03:29:53 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0315.014; Thu, 13 Aug 2026
 03:29:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FJkNJmBS2FEbY+pOT1gsKau/IabBHdZhJCF9Jytq2xjrXWkJ8k0aSL+VlE52e6lamZ65Bw8VxlVOfRSYpR1uz+l8cieZcMz8492CWPU1WlrexlitVZwnC513iLx+Zr/u5TK/eQDoOOln/1RXrdtyEpy43/6yULtTW32X2DrWqRI23EQuZJ91ZoidZfJ3YnBqD6c817jKVNfLnRJtFNbimxSK25It6qTCiiK/3IBZ0E5X+lRc98m8pC4H5pdEXuG7iOdgD8rBImlS7SBxV5AJ56efzlXMdifr/mjuHd0o8Hgw6MxRlK46KoEZT7xzQr9UrDXOVHFExC4TXjeBwN101Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7WipkpWDrbE7BODlTk0euccFKA1zrmHMzqo5hICcRN0=;
 b=QdaCO/ARd3yvjx/Msg8KT4iMjmVEFHfmnWs8Ey4L/NJJqYgOdTHIc4bQILFQY9SCfqqIkP7cvHrpTSrVV1vzHc8J4dKs39iXSPzrAtyGzs/Q/QmGrXyxAybU86HZjIGUPjzPhkX9x1Rt2qCfRsBi7bNCozS44f9mvUetd00rVy1c2mm4iLn7rl6dLlNXlS9dBroX24IZY+i2U5v//jQEqLVlcqxfVz2OAlSXrgiWltcmudR9nI80vRJ7NQWcsZyT22QzWoeaIq16eHhuDiAcaeiz4My6eLmffSWH4aHJJfk401Kvqt02TtgGFffNJ6WW8K5Lb33ZdSymvzbWutUtrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7WipkpWDrbE7BODlTk0euccFKA1zrmHMzqo5hICcRN0=;
 b=dAllqf0dYdDs23K6o0wrogSnF9ErB8xlVSMBpdvU98F0fcpBIBbRwhLEdD0xs3y42KW4v9tdVruPY/YssdEfqPQXOZs+m3lbRZBPY2ihHenp1UpZTpNHRaTaOlR6zkdYgZUm178y3iGnn8QLY0LvFdGX6RqWg3ll4J5inSvXT7s=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: xen-devel@lists.xenproject.org
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2] xen/arm: Hide PMU registers from the guest, when the vPMU feature is disabled.
Date: Thu, 13 Aug 2026 12:29:38 +0900
Message-ID: <20260813032938.3946-1-taka@valinux.co.jp>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4PR01CA0126.jpnprd01.prod.outlook.com
 (2603:1096:405:379::9) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:458::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYCP286MB3775:EE_
X-MS-Office365-Filtering-Correlation-Id: b6463876-1a64-4697-6baa-08def8eb2379
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|10070799003|18002099003|56012099006|6133799003|10067099003;
X-Microsoft-Antispam-Message-Info:
	cAjUeMAobtXQ7KO2zEbt7uXusQvKMSNmZK/kyjPEWE2sgg4wGHGx8MSkohB20H6fy0i6XYcR2YutGzB4OfRz0zrIu3r+rtlOCj0vnyj0OiXHto8lTFK0dBmcSH1n9gzxS99QBrPNjWpWXi9EKuN8b0K7XTT61Td/0kTchvpjsEtzpKt8ULYNXP7EhMbDCOS4FWP/GFwUsvui6pfCR5KltCkgy4WIDkTSb0t89wc4AwHJJPxjKhsBnFgTBwyV3zahQccV9vz9k0QjsusS4Fg/KiWmO13g5dtxuFm75CszyPkIXnFxShvaLiPRyjr9Ee7+kzncfpcsYeK/hjfYV7dZyX7MEAn1jg+kREhELb4BnS0UMmmOxXYZy+NeYJTJbEplIoLG5gtTbLS3uTJZWJlB4DW7UDbxz4pqset0C0hLMbnnswlgfkP14pJ9ucgUhDVk5ONuKX2iTO13Sv5/05BmKZ9ldumntVAjLcrNiHBXn+T22t8fn8/JLmIhuYBIbkUylcq3GApnDW0TS06LPBYzWCQY29IRUZSXB1SteqM/OqJ5dRUP5wu/fAgoq7cTZqDQW/D5UBSoumcdm9LFR2KhxHr2pnEowRuzc9456HRAu+CRBcV7J0MXuIOBCWLbar5Yda/T1fU7BE9sZFzFi/JObqS0Xl04OTGOWttKgrYvPLA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(10070799003)(18002099003)(56012099006)(6133799003)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?8zxqoIDSyXobM/DaTz8NjB8JLQ/6kptkp5vlNfTtmoJ071WJOJjq834TT+Gg?=
 =?us-ascii?Q?QOp+hX2ljVL4XERJw3Y0IWZh9WoIFncz/imFpePaZn/khufrELfOMBo72pFn?=
 =?us-ascii?Q?Cve30jxMfIBhWH+iJ9K1XQr2FR/KUTl13k22akcUGQC+lpV+GVdU6+MKSZLK?=
 =?us-ascii?Q?U6gCrZ8r5EzApM2cK5feiqe+H8FZbtpabL1qiyXMgRlL++Au97adtqFTEed4?=
 =?us-ascii?Q?PsdG9lPizxZRBU/jjHXnKxw5n8FkiCD834NoV4UXRxyE90rV049Uk//TQLee?=
 =?us-ascii?Q?ursOWSLa/18fCz5H3+GAksyaHN4CwsLKFGgF7MPHXEsKbQH09fRzXl7mybeX?=
 =?us-ascii?Q?jmlgQHG5y8pwA+Q2UhopEIypXVTx33rqMz60P6VkCMC+uBqwenhX23uqxL74?=
 =?us-ascii?Q?PqwK+6dP7LYTUZ6SYlbdtLbWbgwsWct6Khw3mfjY1oNrWcnuizZ/DeP7XvMq?=
 =?us-ascii?Q?+sPfk5p1xA0+50xfKfTLfs9YunghmdYHArUmkjhB2Q5PL3imzKhvCcBirKaJ?=
 =?us-ascii?Q?LIo4oAQrZDzXGTuzhsd7OiqxEb1iV1flDgRbzZxqh1KGSjzjX1dFKBkeMNx0?=
 =?us-ascii?Q?DaGVKmnxAZfDd6adShXgr70QeLJJrpYFbHEk6qsH+QQ4XPIECp1Twu9+YOLZ?=
 =?us-ascii?Q?WHRUb8FmIaS6J2SQdmk6502mZPR7sNPbG5kQXcCOo8FuOJ1uNAkzNNrZUjqR?=
 =?us-ascii?Q?YHE/JoYpqg8bJ6Icn8QeL6wf3S/TWCkHBb9av+aLubIXsUPkl5A1Svruq23u?=
 =?us-ascii?Q?24KMhqg6QxcKVfJ6JAEVrqup7UGk+AsXNTQoJwzD7ZsakDYcb+InOKXhJnCj?=
 =?us-ascii?Q?gD5ju4q/r8WH+OlXy/GiNR9ngVIMWdhdaregvs5naUI4f4N13ceorPmF8/zW?=
 =?us-ascii?Q?i7LWxyRFU5Ft6B8FAiM23McMG91izXORfxNA6T24ffRA9Y2b39p0kvHFDAzT?=
 =?us-ascii?Q?nVRWktWw+5/Zn369VeYwqLJl5tV+b/TVIB39mqRd95iz/FWasP2r0I4bxkhR?=
 =?us-ascii?Q?gosW5rITwPzIGDaWk0jt0muvGstiUHxNcjplkfxEe9chXRQV86ijVsu5yA69?=
 =?us-ascii?Q?XegVNpWJbZ+6tVxH14z3Eb1LlVdkR/alSb1vYqAwpmYgyczWBvH9npRi+32W?=
 =?us-ascii?Q?i03Luzg4alwyYLqD7NErBtET4HrfNfj4LZSdCRRPZsqeya79UkL6yJwj09f2?=
 =?us-ascii?Q?xF0BLMTttriJrF3P4pECEHFvSWn0ePGtTJVnPGeUYA7wS5vzzPOPuug77TrM?=
 =?us-ascii?Q?d4qj2beSd9kysAKXbRhQcpdqaJhm2IOaPz3xa/b0OxMT8fz0gOp3jdZG8UpU?=
 =?us-ascii?Q?t4MLFgR8fELjBRx3QdkcaEei83TuNuo22skoBlUWhpc7k5jlS/EWRbmRFxAD?=
 =?us-ascii?Q?gjJmyZVdY0bvzcnQxYDGrwT2KxGw5o6RIObve7mgKLeMa7EEN3Z8gR9UCGAG?=
 =?us-ascii?Q?A/BUPsZl9Jawrlb3pUHsrlMDjHaJfmGYRyGmXe47qwmsK1tM0h5B0NqscVb3?=
 =?us-ascii?Q?Wlx9+EhydZM5elfooXnqTVQDXBdyG7u8hUxtQAJMdAYfSVMN4I4wbSWXgMrE?=
 =?us-ascii?Q?ityP2ZIltHS32WqPNzFyKdVkPOMLId86rTk90UZqfW0KJXuW2SDo1DhgfMsA?=
 =?us-ascii?Q?WRjti6kB8slqWddAF4hYeYKlZVsxOVQFBG+vd3Hw8Aerp3tDNG8jnDjhOSu/?=
 =?us-ascii?Q?EGw8VqGGQ9Xmo58g6EeSFJ5n5s+hBbKXu0JCLYxAEF+hRyfiLnKw760VwfQr?=
 =?us-ascii?Q?AP2O4c4wcn1dpMJU/Cx6FmBub4q1DA+dM2Q+16pSCLZI2h/sFX8nid70t6UU?=
X-MS-Exchange-AntiSpam-MessageData-1: gAyiCeuZk45tcQ==
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: b6463876-1a64-4697-6baa-08def8eb2379
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 03:29:53.0454
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uX6uBw0NR2a6OkkmhjLSRMuNcQ87y0mHwbPnNlKWz7jE4jJ44ga30gzAbb3mSx12hejB8AiLEx5OIdJKGexA2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB3775
X-purgate-ID: tlsNG-42698a/1786591799-1A4DB9EA-25C7BC07/0/0
X-purgate-type: clean
X-purgate-size: 7048

On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
causes the domain to probe advanced PMU feature based on system ID
register ID_AA64DFR0_EL1.During this probe, Linux accesses PMMIR_EL1,
which causes unhandled register traps and crashes the domain.

To address this issue, I implement the following:

- Hide PMU registers from a guest domain when its vPMU feature is
  disabled.
- Proactively make SPE, TRBE, BRBE, and Trace Extensions inaccessible
  to guest domains, as they could potentially cause similar issues.
- Add emulation for PMMIR_EL1 register accesses performed by a guest
  domain when vPMU is enabled. However, similar to reads from other
  PMU registers, the read value returns zero (note that this is a
  temporary implementation).
- Emulation for PMSS (PMU Snapshot) register accesses is not yet
  implemented, because PMSS support is not available in
  qemu-system-aarch64 and could not be verified.

Fixes: 07b9acea116e "xen/arm: Add handler for ID registers on arm64"
Fixes: 3669a1cb9598 "xen/arm: create a cpuinfo structure for guest"
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
---
Changes in v2:
 * Instead of unconditionally hiding the PMU feature from guests,
   we now determine whether to expose PMU to a guest domain based on
   its configuration.

 xen/arch/arm/arm64/vsysreg.c          | 31 +++++++++++++++++++++++++--
 xen/arch/arm/cpufeature.c             |  8 +++++++
 xen/arch/arm/include/asm/arm64/hsr.h  |  1 +
 xen/arch/arm/include/asm/cpufeature.h | 14 ++++++------
 4 files changed, 46 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index d14258290f..520faa02ca 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -229,6 +229,7 @@ void do_sysreg(struct cpu_user_regs *regs,
      */
     case HSR_SYSREG_PMINTENSET_EL1:
     case HSR_SYSREG_PMINTENCLR_EL1:
+    case HSR_SYSREG_PMMIR_EL1:
         /*
          * Accessible from EL1 only, but if EL0 trap happens handle as
          * undef.
@@ -306,7 +307,6 @@ void do_sysreg(struct cpu_user_regs *regs,
     GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
     GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
     GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
-    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
     GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
     GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
     GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
@@ -326,6 +326,18 @@ void do_sysreg(struct cpu_user_regs *regs,
     GENERATE_TID3_INFO(MVFR1_EL1, mvfr, 1)
     GENERATE_TID3_INFO(MVFR2_EL1, mvfr, 2)
 
+    case HSR_SYSREG_ID_DFR0_EL1:
+    {
+        struct domain *d = current->domain;
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !(d->options & XEN_DOMCTL_CDF_vpmu) )
+            info_dbg32.perfmon = 0;
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[0]);
+    }
+
     case HSR_SYSREG_ID_AA64PFR0_EL1:
     {
         register_t guest_reg_value = domain_cpuinfo.pfr64.bits[0];
@@ -348,7 +360,6 @@ void do_sysreg(struct cpu_user_regs *regs,
     }
 
     GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
-    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
     GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
     GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
     GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
@@ -358,6 +369,22 @@ void do_sysreg(struct cpu_user_regs *regs,
     GENERATE_TID3_INFO(ID_AA64AFR0_EL1, aux64, 0)
     GENERATE_TID3_INFO(ID_AA64AFR1_EL1, aux64, 1)
 
+    case HSR_SYSREG_ID_AA64DFR0_EL1:
+    {
+        struct domain *d = current->domain;
+        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
+
+        if ( !(d->options & XEN_DOMCTL_CDF_vpmu) )
+        {
+            info_dbg64.pmu_ver = 0;
+            info_dbg64.mtpmu = 0;
+            info_dbg64.pmss = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg64.bits[0]);
+    }
+
     case HSR_SYSREG_ID_AA64ZFR0_EL1:
     {
         /*
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 94d14fb6a9..0e9bf15ca5 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -219,6 +219,14 @@ static int __init create_domain_cpuinfo(void)
     domain_cpuinfo.isa64.api = 0;
     domain_cpuinfo.isa64.gpa = 0;
     domain_cpuinfo.isa64.gpi = 0;
+
+    /* Hide SPE, TRBE, BRBE, and Trace Extensions */
+    domain_cpuinfo.dbg64.pms_ver = 0;
+    domain_cpuinfo.dbg64.trace_ver = 0;
+    domain_cpuinfo.dbg64.trace_filt = 0;
+    domain_cpuinfo.dbg64.trace_buffer = 0;
+    domain_cpuinfo.dbg64.ext_trc_buff = 0;
+    domain_cpuinfo.dbg64.brbe = 0;
 #endif
 
     /* Hide AMU support */
diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h
index 1495ccddea..ed18184cc7 100644
--- a/xen/arch/arm/include/asm/arm64/hsr.h
+++ b/xen/arch/arm/include/asm/arm64/hsr.h
@@ -84,6 +84,7 @@
 #define HSR_SYSREG_FAR_EL1        HSR_SYSREG(3,0,c6, c0,0)
 #define HSR_SYSREG_PMINTENSET_EL1 HSR_SYSREG(3,0,c9,c14,1)
 #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
+#define HSR_SYSREG_PMMIR_EL1      HSR_SYSREG(3,0,c9,c14,6)
 #define HSR_SYSREG_MAIR_EL1       HSR_SYSREG(3,0,c10,c2,0)
 #define HSR_SYSREG_AMAIR_EL1      HSR_SYSREG(3,0,c10,c3,0)
 #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index bf902a3970..ce8b58458f 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -208,7 +208,7 @@ struct cpuinfo_arm {
         };
     } pfr64;
 
-    union {
+    union cpuinfo_dbg64 {
         register_t bits[2];
         struct {
             /* DFR0 */
@@ -216,16 +216,18 @@ struct cpuinfo_arm {
             unsigned long trace_ver:4;
             unsigned long pmu_ver:4;
             unsigned long brps:4;
-            unsigned long __res0:4;
+            unsigned long pmss:4;
             unsigned long wrps:4;
-            unsigned long __res1:4;
+            unsigned long sebep:4;
             unsigned long ctx_cmps:4;
             unsigned long pms_ver:4;
             unsigned long double_lock:4;
             unsigned long trace_filt:4;
-            unsigned long __res2:4;
+            unsigned long trace_buffer:4;
             unsigned long mtpmu:4;
-            unsigned long __res3:12;
+            unsigned long brbe:4;
+            unsigned long ext_trc_buff:4;
+            unsigned long hpmn0:4;
 
             /* DFR1 */
             unsigned long __res4:64;
@@ -408,7 +410,7 @@ struct cpuinfo_arm {
         };
     } pfr32;
 
-    union {
+    union cpuinfo_dbg32 {
         register_t bits[2];
         struct {
             /* DFR0 */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 04:00:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 04:00:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389432.1630147 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuMcR-0001bj-PQ; Thu, 13 Aug 2026 04:00:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389432.1630147; Thu, 13 Aug 2026 04:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuMcR-0001bc-Mj; Thu, 13 Aug 2026 04:00:39 +0000
Received: by outflank-mailman (input) for mailman id 1389432;
 Thu, 13 Aug 2026 04:00:38 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wuMcP-0001bV-1H
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 04:00:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuMcN-00EFYg-UZ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 06:00:35 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7d414c-bab6-0a2a0a5309dd-0a2a4509c92c-48
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 06:00:35 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7d415e-be1a-0a2a45090019-94a38ff1716c-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 06:00:31 +0200
Received: from pps.filterd (m0367128.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67D2JjY62466407
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 04:00:30 GMT
Received: from mw6pr02cu001.outbound.protection.outlook.com
 (mail-westus2azon11012020.outbound.protection.outlook.com [52.101.48.20])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4g10gyjeau-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 04:00:30 +0000 (GMT)
Received: from BL1PR13CA0223.namprd13.prod.outlook.com (2603:10b6:208:2bf::18)
 by LV3PR16MB6285.namprd16.prod.outlook.com (2603:10b6:408:1e2::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Thu, 13 Aug
 2026 04:00:22 +0000
Received: from BL6PEPF0001AB4E.namprd04.prod.outlook.com
 (2603:10b6:208:2bf:cafe::64) by BL1PR13CA0223.outlook.office365.com
 (2603:10b6:208:2bf::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.4 via Frontend Transport; Thu, 13
 Aug 2026 04:00:22 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 BL6PEPF0001AB4E.mail.protection.outlook.com (10.167.242.72) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Thu, 13 Aug 2026 04:00:22 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67D2K48e3240332
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:00:22 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [44.208.76.22])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkgccwyp-7
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:00:21 -0400 (EDT)
Received: from localhost ([19.12.92.222]) by cmsmtp with ESMTPSA
 id uMc7wagibyclKuMc8w5CsA; Thu, 13 Aug 2026 04:00:21 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=w35yOHQhu7JjGROZ/wB0BoyrS
	+uIi0AjDCqAd9qs7nM=; b=DkdgVH8JBayMIhve7E1vU8OatbCKJXy3n9n1qiSXx
	5GxGexY008U/yTGRfWJSd/+/lz006KRU0oKFf/gmO8mupXrvIEULJdvJ8GpoeixD
	T2PebOONUlb/4TioQzBYC3ltsOLAmULOef1wqaa11JINi6riqJHEXUVdl1iGxYtt
	6ohoS4C58QyO7zRXX59L9HRAJ+YGpAuUgfn2u/8R5RD9j2MbL2K+yj8jNfvdlC1s
	YG/pkvg/CqviZyMXIodUfv6+iQH5N6STGvGYFASjs1yCy/m+CWcUkH6lZpdCjdro
	Ga2ykzUd97dZr+VC2VGeWUeSFx2Ql0LPxa66q2Z0d9QNg==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UrsqtMRAuMCTZOOZKP+r10orgVRnAqUg0hpKAm5JZRZHYn0xYjhmcFOSe67IiAwzMOV+kSAhMmlD7SuX53SxIGjLKcLZH4FwJFABKua6s+b6xxOoYMYs6oA/O14D7qU0kVg9fEmx2QmaDdjfMQ6EH3s+SbMrpZm12muruXk3m+b/YpJ01AG3FJ+MTeDR7UkktmXSO/U18NvW4/ej0NfWGpILDEaPQukDZbc71rhRyU40eZO6RMCRLOiSq3gPb7VhWHxAKbFVaPc2bp8+iL7al25kvFGWm5M4ppYeotJ1NFB/4dWLibP4rO3R//HQomSrOaxDnuRJmGlS7pyCH78qXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=w35yOHQhu7JjGROZ/wB0BoyrS+uIi0AjDCqAd9qs7nM=;
 b=lhY0IHZjKIuBg2yu18LQPbMOvmgU0rwxzA3mlgDfMle2n4ldvNYKDFYDlB04IgK6Gj2neNO5qEFo3Op2E45GUBqABi2tqFLsPES16gFFFLI49wcVnpFVHGR5Bm8Tdczu7VBoeB+dXWj8cjUYhA5MUylQIfu6PNZ+Yr2fPasZS3ynWGhJjlMaGBoZlsfiqwu3AUt1HZP0zMQ4ajZkJBhe1zfqeuXamxSU9TysBqGuvoue3pZ3gqTosTRXdgADzVfVruNXR6wQHoEZd3Wx462rtT/h0Dm2AXEsWTEkOs3+duk8DElK/ASwpmzhD/MFnhqcLpIFOUadWfl9XGYeTtPoYg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=w35yOHQhu7JjGROZ/wB0BoyrS+uIi0AjDCqAd9qs7nM=;
 b=QXvM8W9edFJzIU9x1dfFh3adlfl8HX7m91DL4Ed+a6pCnP+VGQ6loe7Opgvn40gj6SYa2WzVReMG6PuzgD+mnisJX67xIangW+2+doLNvshzM+TY5PWPd/eH5Zdj1XyTryTjMaBmrUsRPcI6BoVS7QdbYA5aptzEokOCdzaaH/w=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=w35yOHQ
	hu7JjGROZ/wB0BoyrS+uIi0AjDCqAd9qs7nM=; b=mu2b57oE55iFfQFhMI92qul
	y8fad0p6HjI43/jI7+Vae7QUmxP/U+hSGuOONn8V1rKPAo1sp6ACvcZrd/8yFR7v
	SNBs6lKFa4urabrRZGXQscb5LBjPw0flpYCiaEtCoyHG3quyezIek7NMLyVuo93R
	RhZVbcGWbZj+loInwz3E0G8K3NNAEOnFX2PyPcCUSVlo1kYDBgLvzFVcoUZpsJfH
	TOQcz9Qob/z/2WtnUzktGN/Gu0y/y0wu0k6HK68LKHeckzdJjb9FC8vo+RbhhO+7
	a3SZSmIoU85Sm+dwOtBwFcq2k+eK91Gd8H8fq7kmtWNhwkC9/TlfMQllMJaGsNQ=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=w35yOHQhu7JjGROZ/wB0BoyrS+uIi0A
	jDCqAd9qs7nM=; b=lFg80uZx9yHsGwTosdmWP9nbU6UbGKrX5RNLWwqO8l2g8Xv
	CtOEmEzBL9YDKFV9hE+oeEAGJwEpeMGXtO1LyEMtHUrE5WqbtOzV7GqmnfB1c09B
	lupIXhIR34B3PsFmXBEwpLgPTu4dbcsR4/+aEjGdRQt9stoxw3U3HADZyKflU7Jw
	2o0CPphaC6e8vKQxWqSEzsCaF1Cy783KXeqi1sS6fWVVIO3rESQB7Txwg3jwWM4T
	LaIlk4aZz9DIgZ5JY3DuLehTs5veTNx1CfHhDQzT2GAa3whWtewGab2QQ820aBHd
	No5vOaO2+J+nXWnYvweiFyAEZhCRaZfyOhmx+4Q==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: uMc7wagibyclKuMc8w5CsA
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v5] xen/common: add keyhandler to show Xen command line
Date: Wed, 12 Aug 2026 20:51:40 -0700
Message-ID: <20260813035139.915536-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 spamscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608130024
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4E:EE_|LV3PR16MB6285:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 39b9de99-2fa2-4305-9493-08def8ef6604
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700016|23010399003|18002099003|11063799006|56012099006|3023799007|13003099007|10067099003;
X-Microsoft-Antispam-Message-Info:
	71tdEDgUZmPE9wScuy+7ihE8fyF8PrJqNTvT6iajrkAy3jvIgkcnYRa1DjcvhmQV7ypa5GLnqnPmlF1HDtIh3kt+i6cihoBWeRdCQQ/XQDKJIffqghkwPgGstnlMtrp+T82/BMzg6jm8eby4/DVQ3hJJIHXAJKf3IwumwmQHtOLx0pavF0Elu7b6JuTN4/YY6eYLk+5bUYhnnJOUiUv0vzjUcGEBSsy10mo8QgREvevFLqAUoLa0czL9+xtGUPiHmHuuKj+m9DsQfWoh0E4vuBTc2a1fa9XBjoHkMTEYAyRMi6io0KfLcuM/rpzhsco3P8xtvm4SiLq752QHxWSK6cqdeEvIex4XOx8EhC3+cKHjrkYSiy+rO9ySZHp7yHZCLeyJ/FE4tFhEekMFpV3xxOPKZFXHcGHr3gvsaUycki4X1hJmohKXgRyFyWaY1QeGv6op0CrxrzaJA396IgnSkdbAGTJMyGEbvjkWGTx+SlXsgogU+IW9OKAnrPopopIVDEm9M8RAzNxhRsK5c4MQ25VvAB8Nw8izdUoBkJl+cx5tZAXIKHj9TJKnr4pOg9fhahV4bhJuEIa8B5Qm+uexGLFt4l5cgN1pn62ci6Shaf6p78h9ZWp7EBT1mjNjLY8nyDdplfgng/dd12edX9iE9oBc+1YQfRXSmHsncjZs7lcSZkFp8d39ER3PnNX5Q1gPYF56jomzt6cQq1mGe2iPmg==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700016)(23010399003)(18002099003)(11063799006)(56012099006)(3023799007)(13003099007)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	PW+uKFoNNV3aHKdmB52ektWuwjvlohM0464HrtxzbRbPDVIOzvtsYRLJqSlEY+MYsT48Asxtq1A3drfDyWjxPdwPAIsUMApzG84Q1S/IXpH98udBmssWKqRm2AU1OFq8bnnhnodmRuHa6Q7EJTbZ/xewQ0nqiAhi7/WVyouEKsL3Zwkpvp0isOgjYCcFm6DfFDLr1Hzd6OcglPWkZPmLOtmeczPsIUZCVgqyYfqu755ITxQ7jma+q7OkleK1xFifZAKwWLPK349TogT9WPb3ut+F1/71V65+DO3E0/rq5lIgi/41RzqV6mzGZNHJ2eMSlbx34An5gl1VAK57vvbzGd1IDp6S/1YYJNtO17wwlUSA8xUCO0tHnljgMeQq0x4Lh1pvjxQolf/1HeskwIzavZ1wYQyVtBwqppXTlaiynHJeJUdrGqHPGg8ehrNcioeu
X-Exchange-RoutingPolicyChecked:
	Pvq+uDQ1IFzeKAMZckJt1hfq+WkS7uVZCLxIpfiGosUswKxhlIiVwrlTrU4OX6ufczJjX8IXs4Y6Oah0obvGAsBbtFEpIbu4JjOG8etBFWeFJjSCZthWjSCvvLAsn8lh4DyVpuHtRmwhqoe4lyF6tTwg+DCgRkNMIoke48CEEER+c4JU3W2l9p9lsA+ZpkI/na4rNt6/jOfdA+Mq1G2oG+nJc1CaAUjwZbi4eGGu7NdSnRMEDwncpZxS+ASv3rqRcCRoRv+UWYmMv0Qw9iOTpzvKkF7/A9xGSj0FkJrSAzlXPlX1/Ree70fRwg8j13cbk9ql+clrGyewmVEltL95yw==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	ZYVPvPlKNk3KABJE8a6ehjOvqUeYznzuLfZcYKitAWRht5hDLNKCdTkrQs8WAxFXlCzwLIIiIXIZXFMgE1wsahCeCuwUe1kLT0dKUxui/Jw819BiH8iPWYKRQYkTXoVUdbqVPn8vqgXjmlpdOA09+l82atD1Fjs7o0G0MC+lPyhKJkIYxkvsFh8dLqXYznBbcjzFNz4hxSv2GWvXo3aqG8a0Qh9JpZypxpy9yxiAuucFEcR3Sp++Lz0UiZe6zYPydFU6ic0629qjrcPlUuaeeEo9WhGQ2vzCjyAZIKjJl36L7tnMat7jeyhSi2iOrLQ66t571HRzo1o+0vf9lBdTzdKSXzEDjqb4on5re+4Ntd54khFVi9z9gU51VFsTtqIvUwsZ78FiPOzgN1vX1rpECTIduMCnT+2wWojPuaK8wZma9NpEOYvndZ7GHP4UaUEU6qIy5+sLbolfi3UU021HCqan2nqwoXJMNCxNjtPMpmricpOCF48Vk0uEdeFVeQClw4IIKRZLW9SvAZMgsHaZwDvnCc3J9lFuDAAC6Xc417fpJmHygnP8JSBBfS/ggBLpCILCVKNM6e1LZ+tJx8nUZUNKFenmiFzqR8OW+xZt608hPvqUQc/pRLNOeIDagkth8KeXBzfxIwnuPLzTMKVQQg==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 04:00:22.4628
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 39b9de99-2fa2-4305-9493-08def8ef6604
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB4E.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR16MB6285
X-Proofpoint-ORIG-GUID: _l281Y64Yn4NFJ5hrHjz5HAKmyJyFHWS
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEzMDAyNCBTYWx0ZWRfX4nDWwOUyTLkO
 LaBhmgp0cv20fiBR0xl9O8JwMHCw75RhGQosJ3adk5iJ+c+pMZGsuYnEtMspLn5N2Pz5X/Hubd4
 EcrfAiPTc9iDzFBrIFuFP6BUXM20AuwD/UrgHkn6Bctv3Swm5JR74INdS3AnrJ+V5d4AJRilHGY
 v56psGmIfOYHqD1+pmlMEKS8bc/2sxNRJ3IreLWZFareoSMFo1TcfxD4HKewyt1krPmzfQGMtp2
 DXa8I/coT5zo2FPaEGgFzYb5qZdISIn5a1smGltCokFIpSSQNerE/1d8MAmoXf1Q279zfhLdcK8
 1aezkyd9AI7T42Z4lJQZ4v6jxqQUsyOKIaHKp+cfKMHUm+nlNb18ssXXF3B9dAYFR4GeuP+emH5
 HTg9mFoZnI5e//fB/TS4OIK2f8/4RW9aXYcTdjSFzfM376BHIOuK1PUIPFZfADyjUwktOvcy8JV
 idbj0dEE7GjYPm7vLDg==
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEzMDAyNCBTYWx0ZWRfX8qPP4UkylvQW
 zLezukWu03886iI57X194QfnvNlqZqomonDbzY20DWiWtoAi56LZt6ViOtq417fHOjLVcXA/Gcp
 yJBq4cZYyc14O96c+d5RfG7Z4jNof5pQSjA1LygwnPgvoubHmUgc
X-Authority-Analysis: v=2.4 cv=O58Jeh9W c=1 sm=1 tr=0 ts=6a7d415e cx=c_pps
 a=wPn5mG08gX1eKnPfDThLSw==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=WER9OelvoqQQjwJToBYG:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=LJ2BZIJmTNxky85jOzAA:9
 a=3whSkbs7g9Me0DR5EJEX:22
X-Proofpoint-GUID: _l281Y64Yn4NFJ5hrHjz5HAKmyJyFHWS
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
 priorityscore=1501 impostorscore=0 suspectscore=0 bulkscore=0 adultscore=0
 clxscore=1015 phishscore=0 spamscore=0 malwarescore=0 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608130024
X-purgate-ID: tlsNG-bad1c0/1786593632-BE8D9034-CD7FC179/0/0
X-purgate-type: clean
X-purgate-size: 2714

From: Denis Mukhin <dmukhin@ford.com> 

Currently there's no way to print Xen command line on the emergency
console for debugging purposes when 'xl' is unavailable.

Add new keyhander '?' to do command line printout.

To allow built-in command printout, drop __initconst in
'opt_builtin_cmdline' declaration.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v4:
- promote opt_builtin_cmdline to __ro_after_init and use it for
  built-in command line reporting
- account for empty saved_cmdline
- adjust register_keyhandler() call - use '?'

Changes since v3:
- print built-in command line too
- change handler to print command line only

Changes since v2:
- account for CONFIG_CMDLINE_OVERRIDE case

v4: https://lore.kernel.org/xen-devel/20260811210956.3806559-2-dmukhin@ford.com/
CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2756104826
---
 xen/common/kernel.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d1bef9ac2b2b..1afda2a68f3e 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -5,6 +5,7 @@
  */
 
 #include <xen/init.h>
+#include <xen/keyhandler.h>
 #include <xen/lib.h>
 #include <xen/errno.h>
 #include <xen/param.h>
@@ -35,7 +36,7 @@ boolean_param("dit", opt_dit);
 #endif
 
 static xen_commandline_t __ro_after_init saved_cmdline;
-static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
+static const char opt_builtin_cmdline[] = CONFIG_CMDLINE;
 char __ro_after_init xen_cap_info[128];
 
 static int assign_integer_param(const struct kernel_param *param, uint64_t val)
@@ -505,6 +506,35 @@ static int __init cf_check param_init(void)
 __initcall(param_init);
 #endif
 
+static void cf_check show_cmdline(unsigned char key)
+{
+    const char *cmdline;
+
+    printk("'%c' pressed -> showing hypervisor command line\n", key);
+
+    if ( opt_builtin_cmdline[0] )
+        printk("Built-in command line: %s\n", opt_builtin_cmdline);
+
+    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
+        cmdline = "<ignored> (CONFIG_CMDLINE_OVERRIDE=y)";
+    else if ( saved_cmdline[0] )
+        cmdline = saved_cmdline;
+    else
+        cmdline = NULL;
+
+    if ( cmdline )
+        printk("Command line: %s\n", cmdline);
+}
+
+static int __init cf_check misc_init(void)
+{
+    register_keyhandler('?', show_cmdline,
+                        "show hypervisor command line", false);
+
+    return 0;
+}
+__initcall(misc_init);
+
 static long xenver_varbuf_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xen_varbuf user_str;
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 05:54:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 05:54:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389448.1630158 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuOOq-00012Q-HO; Thu, 13 Aug 2026 05:54:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389448.1630158; Thu, 13 Aug 2026 05:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuOOq-00012J-DS; Thu, 13 Aug 2026 05:54:44 +0000
Received: by outflank-mailman (input) for mailman id 1389448;
 Thu, 13 Aug 2026 05:54:43 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuOOp-00012D-It
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 05:54:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuOOn-00BuFp-Nf
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 07:54:41 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d5c16-e002-0a2a0a5209dd-0a2a4506cd4c-10
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 07:54:41 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d5c21-195a-0a2a45060019-d155dd2ca808-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 07:54:41 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47db714766aso302100f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 22:54:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5613e2sm4222287f8f.6.2026.08.12.22.54.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 22:54:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786600481; x=1787205281; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=pOb5i/C6y9XsFnyr2iObH380nZD0yDVY14kfNgsUQdY=;
        b=LlT2rbQC2VCk+qYXEc+o1rNNjkPcsFAjfz50i6C5uWIAih9myULD3zMlpcCmMM3ymh
         m299W3lA3t8cxroYc8/E1jWAei2U62Y7R18a1Yz1yGtg+BmUyYm9jpdvOL3a0lSmLY66
         8JeUb62E+3po5scpg6aToYjkmRL61onaf9eKxGlYs5ECpkDFGyash8aT8ba4zukprJmH
         vp8T1RRCtkaaI0Z4r0fS/Q12Ss5dcQaB5eHE7rd2Ys/BqwmBwQT4M59M80wibBqEco/z
         Ls8KCi0Ud/1ap0cFnrRTZYppGiyxU3D9uyQmbxBnfWounicQ1Y0TEUpjdqST3D/oPEb9
         Ju3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786600481; x=1787205281;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=pOb5i/C6y9XsFnyr2iObH380nZD0yDVY14kfNgsUQdY=;
        b=U6NGDtFehtiLaT+ShUhNPizIi28GyhY0AJMv6Vl0n/N5hEAdOTRsxG8kDDxVLoN2ii
         JO8lvbnRrnyNJ89bQOlD21hWgL5F9GHLfnxJ8yFTSqvQrjoHPI5ukmB/ss7yoUOgUgqP
         oC4lFX33H1BljHQYvqkY4pV91Cbwa6gv3z2UNwYUXnPW+pZ6GPZWUmyjw4zICVzkKsGj
         bhgvNvcgVUKzPy3THDKh6RBxCdls4bwi38A0pEi7v0LkOivmjmTKIyE1xAc6Qd+QgabB
         6HtP3y3PHUhj6Q/E16JaMrQMl+rLoYTHQhFLArGbxGZonKOM+W2IqI1BPov9u9jSIDyY
         dr3Q==
X-Gm-Message-State: AOJu0Ywu2mL6DJ92u0jRQTeH3P3O0r6WNdQiL9UQ/CsZ9tBKfAJnilCp
	ODF8ibZ6Il3KyOKRbiIfL9s6CnZy9qu7Va7gmbLQm2ECH+rgK8CntQorjJgmTMY4pA==
X-Gm-Gg: AR+sD13HcIf6RnZVd2Vftugt1mH/xEt+o+JbFrYNSntfFx0PYrIAxHwCaQXS8oZ+2dS
	xH+T8HoXRzTotOCgpqesAQtjg7b48Tq/dDFcXi8iX6HkyY4KF9/L4nzIrKg7PKHhoV9e5rY9nE7
	kUcau+d+DlTwXAm9fJzGigfvf+vMDua9COElvzt+VqzQIvNU58b+sZ1mZEwzBE9sjv1okt/2pYC
	c/00PRbhV4RLTVoJLUAYvRSMlXA5P3AzqKwQu4ktC3Qo4x5rSa+Ysjbizus9d+12OTSIpO8gouO
	0eq56uyJBepfSk3MHKMNAvyBpqHgT2Ggy0QqsNxNze7sqBnfuuCD4z+w344aqKUhKZmlDqE9fKq
	WVp0mAN/z3izA7nKhxcvwi+8PyQM4v002li6NEevQgqvegwikKMvs5+JVg5XVTjtzx9MK/PtG6j
	Co/Wc3At1BRMt5Oi5nF77elkJztkGSrMjxctkJw8xJ50IV26Z6+92oIwuWcthhb1DQYh6ZDj38c
	AZXzQmMTYNrU4yp4DxC0TIScFosfWSoy97xli1SIzLxjP4IWYjf
X-Received: by 2002:a5d:584e:0:b0:481:57de:df20 with SMTP id ffacd0b85a97d-4815a5436ffmr3193230f8f.15.1786600481054;
        Wed, 12 Aug 2026 22:54:41 -0700 (PDT)
Message-ID: <2f2cc724-92d8-476d-bd85-5529fb365389@suse.com>
Date: Thu, 13 Aug 2026 07:54:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/5] stubdom: remove grub-pv
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <20260720081833.4122182-1-jgross@suse.com>
 <f8481120-00c5-411e-ad66-38ff550bdd47@suse.com> <anz6XwsWjoNeHBxY@end>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org, Juergen Gross <jgross@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <anz6XwsWjoNeHBxY@end>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786600481-FEC7777B-7A41D998/0/0
X-purgate-type: clean
X-purgate-size: 5503

On 13.08.2026 00:57, Samuel Thibault wrote:
> Juergen Gross, le mer. 12 août 2026 10:16:58 +0200, a ecrit:
>> Any feedback?
> 
> I'm fine with it: grub0.9x is really old, grub2 works alright in my use
> cases and is maintained.

Was this perhaps meant to be / include an Acked-by: ?

Jan

>> On 20.07.26 10:18, Juergen Gross wrote:
>>> The grub-pv stubdoms (32- and 64-bit) are disabled by default since
>>> several years now.
>>>
>>> Remove them in order to enable removing quite some more code from Xen.
>>> In case someone is really depending on grub-pv, they can easily take it
>>> from an older Xen build, as there is no Xen version dependency in
>>> grub-pv (a version built 3 years ago has been tested to still work
>>> with current 4.23 staging Xen).
>>>
>>> Note that after this series has been committed, some additional
>>> cleanup is possible by removing stubdom libpci and zlib support, but
>>> this will require a modification of Mini-OS depending on these patches.
>>>
>>> Changes in V2:
>>> - moved one hunk from patch 2 to patch 1
>>>
>>> Juergen Gross (5):
>>>    stubdom: remove support for grub-pv
>>>    stubdom: remove support for building in 32-bit mode
>>>    stubdom: remove building of libxenguest and libxenctrl
>>>    docs: remove stale stubdom entries from stubdom.txt
>>>    tools/libxenguest: remove Mini-OS specific parts
>>>
>>>   Makefile                                      |    6 -
>>>   config/Stubdom.mk.in                          |    3 -
>>>   docs/misc/stubdom.txt                         |   69 -
>>>   stubdom/.gitignore                            |    1 -
>>>   stubdom/Makefile                              |   69 +-
>>>   stubdom/configure                             |   65 -
>>>   stubdom/configure.ac                          |    2 -
>>>   stubdom/grub.patches/00cvs                    | 1022 -----
>>>   stubdom/grub.patches/10graphics.diff          | 2297 -----------
>>>   stubdom/grub.patches/11graphics-keyboard.diff |   13 -
>>>   stubdom/grub.patches/20print_func.diff        |   52 -
>>>   stubdom/grub.patches/30savedefault.diff       |  186 -
>>>   .../grub.patches/40ext3_256byte_inode.diff    |  114 -
>>>   stubdom/grub.patches/50fs_fulldisk.diff       |   72 -
>>>   stubdom/grub.patches/60ext4.diff              |  474 ---
>>>   stubdom/grub.patches/61btrfs.diff             | 3499 -----------------
>>>   stubdom/grub.patches/70compiler_warnings.diff |   45 -
>>>   stubdom/grub.patches/99minios                 | 1570 --------
>>>   stubdom/grub/Makefile                         |   88 -
>>>   stubdom/grub/boot-x86_32.S                    |  112 -
>>>   stubdom/grub/boot-x86_64.S                    |  108 -
>>>   stubdom/grub/config.h                         |   12 -
>>>   stubdom/grub/kexec.c                          |  434 --
>>>   stubdom/grub/mini-os.c                        |  771 ----
>>>   stubdom/grub/mini-os.h                        |    7 -
>>>   stubdom/grub/minios.cfg                       |    4 -
>>>   stubdom/grub/osdep.h                          |   30 -
>>>   tools/libs/guest/Makefile.common              |   15 -
>>>   tools/libs/guest/xg_dom_decompress_unsafe.c   |   48 -
>>>   tools/libs/guest/xg_dom_decompress_unsafe.h   |   28 -
>>>   .../guest/xg_dom_decompress_unsafe_bzip2.c    |   14 -
>>>   .../libs/guest/xg_dom_decompress_unsafe_lz4.c |   39 -
>>>   .../guest/xg_dom_decompress_unsafe_lzma.c     |   14 -
>>>   .../guest/xg_dom_decompress_unsafe_lzo1x.c    |   44 -
>>>   .../libs/guest/xg_dom_decompress_unsafe_xz.c  |   46 -
>>>   .../guest/xg_dom_decompress_unsafe_zstd.c     |   44 -
>>>   36 files changed, 1 insertion(+), 11416 deletions(-)
>>>   delete mode 100644 stubdom/grub.patches/00cvs
>>>   delete mode 100644 stubdom/grub.patches/10graphics.diff
>>>   delete mode 100644 stubdom/grub.patches/11graphics-keyboard.diff
>>>   delete mode 100644 stubdom/grub.patches/20print_func.diff
>>>   delete mode 100644 stubdom/grub.patches/30savedefault.diff
>>>   delete mode 100644 stubdom/grub.patches/40ext3_256byte_inode.diff
>>>   delete mode 100644 stubdom/grub.patches/50fs_fulldisk.diff
>>>   delete mode 100644 stubdom/grub.patches/60ext4.diff
>>>   delete mode 100644 stubdom/grub.patches/61btrfs.diff
>>>   delete mode 100644 stubdom/grub.patches/70compiler_warnings.diff
>>>   delete mode 100644 stubdom/grub.patches/99minios
>>>   delete mode 100644 stubdom/grub/Makefile
>>>   delete mode 100644 stubdom/grub/boot-x86_32.S
>>>   delete mode 100644 stubdom/grub/boot-x86_64.S
>>>   delete mode 100644 stubdom/grub/config.h
>>>   delete mode 100644 stubdom/grub/kexec.c
>>>   delete mode 100644 stubdom/grub/mini-os.c
>>>   delete mode 100644 stubdom/grub/mini-os.h
>>>   delete mode 100644 stubdom/grub/minios.cfg
>>>   delete mode 100644 stubdom/grub/osdep.h
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
>>>
>>
> 
> 
> 
> 
> 
> 



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 06:00:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 06:00:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389458.1630166 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuOUD-00038D-4m; Thu, 13 Aug 2026 06:00:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389458.1630166; Thu, 13 Aug 2026 06:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuOUD-000386-2I; Thu, 13 Aug 2026 06:00:17 +0000
Received: by outflank-mailman (input) for mailman id 1389458;
 Thu, 13 Aug 2026 06:00:16 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuOUC-000380-9q
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 06:00:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuOUA-00HHpz-IJ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 08:00:14 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d5d6e-8faa-0a2a0a5109dd-0a2a450ab96a-0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:00:14 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d5d6d-f2d2-0a2a450a0019-d155dd2da95f-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:00:13 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-4813ea321cdso335782f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 12 Aug 2026 23:00:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5af453sm3538680f8f.23.2026.08.12.23.00.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 12 Aug 2026 23:00:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786600813; x=1787205613; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0tddkDMvtOF7kURPiW+G9b+uW98uVQMk/Chv5QXRQOY=;
        b=eexl5Sr875ZZh0DtFp+CeSorWs1M6RvOt6GUoZSpDaKbRWA8ndF9T/VRg/7Za8EEVR
         sHtKj/50OgNsu7CY0Ck3tUW6W+WsubLc37ZdCEzWmllj/ecGNFlxtf+nd/3mzpiVI7/c
         8t66vEcBEhuWpAhXbRRiLCTalDHa5W2vGifXh6Jjyh7ijA4f08ved6j5en3+PIj4b837
         yxujYq/2ZVGn1GpCRcCUgEonVtS3/NkptDT2wbPleEQzzSUdCn/HEKEbFR1ljHnJDJaS
         eYRzixanHoKFHMTMgI0ltQ5uSNoNb+zSdJpj78EwSW3iNYYN0lyIDCojip+IiJVHui4h
         zZrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786600813; x=1787205613;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=0tddkDMvtOF7kURPiW+G9b+uW98uVQMk/Chv5QXRQOY=;
        b=a780vvIwEyx7Tv/Zj7wdbajbThCqD2p6IWoqzq1AUHfth2xg5v6q09wtPLk0KDUgfN
         WHnDNy6AuA/Py1b4cxJNBsZtG0Y0ng2bUqq82V9gVpqwQ/HfkSjS8zHPCQulQqg39wti
         r92T+DaSvr5EjwCtoGKXZzlg1XJtDcQIFqXaXNmakmq9dscYtQ10zSH/jnvbwzsUvy/c
         37luPkh6sjT18UR1jTPD3AqHAhY6Et1qfwMQG1gke0LesyCvAumuY+xRy+dZh4PDk6Nk
         hsHIBVBG5mFTcOmlFZCDnHQlhnn+otFzK/8FdNxlj9LcD/c6PMelYo6a025YdzdLiWUM
         bm9Q==
X-Forwarded-Encrypted: i=1; AHgh+Rpi4saKsjZBwEAISogTx+DM1cZmv25QpS21+gwz+FJk4mPdrdyfXyagFGX6AK04KctBwbymeIM6k0I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyi7pUqtArsJenm4TOgVH6faEgoP30bJQbF73QcTM7eTeTZFfMl
	4A3ZKEKmp03XM/hAqDJtw2ZEni9lAxlTb8j84lqaOVeTlSEKrKDyknQ2fo2e6gnYeg==
X-Gm-Gg: AR+sD12t9coK6S00hXxrC244f5T1m5H6AFIFmqsKTwO/ov6zJHqugQtIUk3uwqk3iDZ
	WW7wIzX7kl4cmnz6/YnouRpeMYRYdaqyULSOFgXa2uxPPXDW8tMeommOE+CtVMk5DBoAJPb8CCp
	KjDTKN+ajN2xdLhPbRYRm6i6KYgFDKUUxVAQPHfaCFNAThWxTogIeCPc66+Czqwys4NcxeGiS0X
	Hj5y33cgmltwqntizYfAfvYXQnplDnmetj4VC3F3ygcD+iEKyBPzxPanF7TGOAZ2PKHEDaFwYGz
	RXBYbP6vgghXMbv9kmkJ5cSN/ZhU5GCv6VGFL8Cj5nx71DQZUImw3gBH8LSt+zliKjDwX6bh6IL
	ohLFsAmM2TADBVLxw3KUyQaG5FYI4zJdLfRGPPd6T990+AWDBJNZA9yijxg3DGZRTBTU9NOlv83
	WGMDxVBB60WXa7Y4uKXx3+5jzIM6j6MgdDTejEbyl1F5COd7qdQ3z0HQMulrNhI+kiWzJjh7n8w
	y6RrqGMOTDpRmD0EZ7J1VzeBmb50Uih1oyCop2nv2pX4FpNm0S2
X-Received: by 2002:a05:6000:41ea:b0:481:2fff:2a09 with SMTP id ffacd0b85a97d-4815a540db2mr3593771f8f.14.1786600813140;
        Wed, 12 Aug 2026 23:00:13 -0700 (PDT)
Message-ID: <04442bf7-7a19-4eb6-be86-8332da2a5958@suse.com>
Date: Thu, 13 Aug 2026 08:00:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] xen/common: add keyhandler to show Xen command line
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260813035139.915536-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260813035139.915536-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786600813-532D8CFC-328428B0/0/0
X-purgate-type: clean
X-purgate-size: 1178

On 13.08.2026 05:51, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 
> 
> Currently there's no way to print Xen command line on the emergency
> console for debugging purposes when 'xl' is unavailable.
> 
> Add new keyhander '?' to do command line printout.
> 
> To allow built-in command printout, drop __initconst in
> 'opt_builtin_cmdline' declaration.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v4:
> - promote opt_builtin_cmdline to __ro_after_init and use it for
>   built-in command line reporting
> - account for empty saved_cmdline
> - adjust register_keyhandler() call - use '?'

This isn't quite what I was expecting, following the feedback you got on
v4. My expectation was that we'd see a 2-patch series, first patch moving
non-help stuff out of the 'h' handler, second patch adding the dumping of
the command line. Naturally the new handler then wouldn't be named
show_cmdline(). I'd then further expect tat no new use of
register_keyhandler() would be necessary: The handler itself would live
in keyhandler.c, and print_version() would then be accompanied by a new
print_cmdline().

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 07:16:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 07:16:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389469.1630174 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuPfJ-00063C-6O; Thu, 13 Aug 2026 07:15:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389469.1630174; Thu, 13 Aug 2026 07:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuPfJ-000635-3T; Thu, 13 Aug 2026 07:15:49 +0000
Received: by outflank-mailman (input) for mailman id 1389469;
 Thu, 13 Aug 2026 07:15:47 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuPfH-00062z-PZ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 07:15:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuPfH-00C86Q-67
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:15:47 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d6f22-2eae-0a2a0a5409dd-0a2a450bbf40-6
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:15:47 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d6f22-b7e8-0a2a450b0019-d1558030c903-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:15:47 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so2384835e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:15:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4998212a3a1sm38823815e9.6.2026.08.13.00.15.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 00:15:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786605346; x=1787210146; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=yLelFGhfhRKesr9TWUjL/w6WQht4LGUF6dac6pMJHt0=;
        b=DfgXWkEW3X6HLBDkycQy677dnS76OtiqdfWPKgqScH+QEIh/wFv/79m3tQNce8gNi8
         66YUaaHYyI//GzQzg6Se4KncaO7hleNAq9cPXom6NTMsdIRAxmbbauJ9/A0UtfaHGRnP
         17Q2fAbCJ0KWOVSVU5mLalXKc7ey2rB3yebTcnBd3mskCQAjmKY66+zQIopERt1S1k1f
         t3zhXWMpcWk+3GStPUWL3/GyAos5ELzuES31cAjXvrewEoFql7rf5hXPfTSD/cE38alv
         YGDvK4oUI4IEjV9gpA4QkJE19wz/3cm0lvvopjMNCjnYtOYGMk35TuXV3H5VSn5FcDpe
         tpzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786605346; x=1787210146;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=yLelFGhfhRKesr9TWUjL/w6WQht4LGUF6dac6pMJHt0=;
        b=SlxT99kMB3ezKokGucd/H7Okxf6a9+IKJ2knN9pJtaDoTw9qzP8o4ZdWX59OHMPZMv
         HQ7bKjqO6zb2FDFtvPLrHsa4qDpS+4H5K7J6aKTW8k2nk2OzP8VxiEq2bc4G/X+xg9Tu
         baUV7jzi7oa6O242dn70xWxKZXF0Hu141kEKHsxGE+XZ9ch5fRrBdh9sgmG+Qf2qOFMF
         VdPacmMedTpsRR1lUuQ8JYrynrX/yXPctV04beWzFP3nfpTiJGcvsSR8pctFtyl13Xx4
         i+6TWyPuy+PRXVgChpTZ2i/ygBEEC5Hoe3LOLg0edVZdhW64hiy84waF7ErhBDrYDZgM
         5Tvw==
X-Forwarded-Encrypted: i=1; AHgh+Rprrex1ta/hXjdNpmcl/scqmctyquZuclokhdkM/LpiXfB86S6Kp9yjPwu3qDakGQasYLx/XeYKUb0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzd/pTRwCdyAx/6SY7/uY7XxvUo9z4C8bfAaALKB1P+R1RXQvjg
	xL3cfiOnA8yw3s3SwjVyZy/Mobdbk4WWY8cbmnycMC2FSCzFtGrC1CaccQG7GvkuUQ==
X-Gm-Gg: AR+sD10t9p3gNY81yx9jkLnrbGGdUGcBvAxK2sSbx5qejSlTnwVoQTFDBw8ma/DUSGl
	IohxaUAE0/4JC/J4POHSpy2etSgKsGr2IKJ8kfwzdzIy1wSWNRK3E5LndX8CuGhEXVAiNLvNeoz
	y/SC9ig5Rkf+LcA0CQVYgv50qS1eo+GMXhgBnT7/RTXxSNYlJOXdzH/j2VnwnWudl+UZ1FVRQDW
	6S7WCasG1AzfagyXp8uNLqd4mDKkSI4qtn/rLHt/R8UhhahgrHKZZp+zGUyTh778GBKoqCazs3x
	Y5a6hC2duVG+GyRXRnw0M2fF201Osbbik2geGuhzIXakGpc9aCaBIK/j0KpyVNJOIcM8cZ+JauE
	Bu1eRSaIepBZFFuz/tWL80/NYLN9ZAJYOiWN32+pOJCbuqGZxrgztOeTn4nsgt0yraaqARbaTox
	pOx2xJcI4WH8yqEd2nyLvLDGIDSE9VijJDqgUrqKRwY+nomBSEyrCUlmQD/coGRI2+ZopbSKZGS
	RMj88OZ59mT/NgkkQOj9CQ5zMEyhaweW2Bx3Wnc/2/FVESE6+6j+Mb/7Q==
X-Received: by 2002:a05:600c:4e4c:b0:499:726c:50e with SMTP id 5b1f17b1804b1-499821f9223mr42700255e9.14.1786605346428;
        Thu, 13 Aug 2026 00:15:46 -0700 (PDT)
Message-ID: <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
Date: Thu, 13 Aug 2026 09:15:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786605347-1A4DB9EA-D2945707/0/0
X-purgate-type: clean
X-purgate-size: 9446

On 29.07.2026 15:40, Oleksii Kurochko wrote:
> Introduce emulate_load() to decode and emulate guest load instructions
> that fault due to MMIO accesses. This provides the basic infrastructure
> required for MMIO emulation on RISC-V.
> 
> The instruction decode (decode_trapped_insn() and the mask/match chain
> for standard and compressed load encodings) is adapted from Linux's KVM
> RISC-V implementation. The completion path differs from KVM's,
> since Xen dispatches MMIO synchronously to an in-hypervisor handler via
> try_handle_mmio() and has no userspace exit/return step equivalent to
> KVM's kvm_io_bus_read() / KVM_EXIT_MMIO / kvm_riscv_vcpu_mmio_return()
> split.
> 
> A fault taken while re-reading the trapped instruction is handled
> depending on the faulting translation stage:
>  - A VS-stage fault is the guest's own fault (e.g. it modified its page
>    tables from another vCPU) and, as in KVM, is redirected to the
>    guest's trap vector, with the cause remapped to
>    CAUSE_FETCH_PAGE_FAULT since HLVX reports execute-permission failures
>    as load faults.
>  - A G-stage fault would mean the P2M mapping of the instruction page
>    disappeared after the instruction was fetched. KVM must handle this
>    by resuming the guest and retrying, as Linux MM can invalidate
>    G-stage mappings at any time. Xen does not remove P2M mappings of a
>    running domain at the moment, so this case is asserted unreachable with
>    BUG_ON(); it will need to be revisited once such removal is implemented.

I don't see why this cannot be implemented correctly right away. The behavior
should be that of an access to unpopulated space on bare hardware, whatever
that behavior is on RISC-V.

> @@ -13,6 +14,11 @@ struct trap_info {
>      register_t stval;
>  };
>  
> +static inline bool is_load_guest_page_fault(unsigned long scause)
> +{
> +    return (scause == CAUSE_LOAD_GUEST_PAGE_FAULT);
> +}

Is something like this really a useful wrapper to have? It doesn't really
shorten anything, nor does (imo) it aid readability.

> @@ -191,6 +193,11 @@ static void timer_interrupt(void)
>      raise_softirq(TIMER_SOFTIRQ);
>  }
>  
> +static always_inline void advance_pc(struct cpu_user_regs *regs, int step)

See my earlier remark regarding always_inline. Also - why plain int? Are
there (going to be) cases where PC is moved backwards (in which case
"advance" isn't suitable naming)?

> +{
> +    regs->sepc += step;
> +}
> +
>  static always_inline unsigned long get_faulting_gpa(void)
>  {
>      /*
> @@ -210,9 +217,162 @@ static always_inline unsigned long get_faulting_gpa(void)
>      return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>  }
>  
> +/*
> + * Determine the trapped instruction which caused a guest MMIO trap.
> + *
> + * Returns true if the trap was redirected to the guest, in which case
> + * the caller must stop emulation and return success. Otherwise *insn
> + * and *insn_len are filled in and the caller should continue decoding.
> + */
> +static bool decode_trapped_insn(unsigned long htinst, unsigned long *insn,
> +                                unsigned int *insn_len)
> +{
> +    if ( htinst & 0x1 )
> +    {
> +        /*
> +         * Bit[0] == 1 implies trapped instruction value is
> +         * transformed instruction or custom instruction.
> +         */
> +        *insn = htinst | INSN_16BIT_MASK;
> +        *insn_len = (htinst & BIT(1, UL)) ? INSN_LEN(*insn) : 2;

In the if() you don't use BIT(), while here you do. Please be consistent.

Why the use of INSN_LEN(), when due to the earlier assignment it'll always
yield 4 here?

Finally, how would the caller know whether it looks at a transformed insn
or (as fetched below) a "normal" one?

> +    }
> +    else
> +    {
> +        struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);

Pointer-to-const.

> +        struct trap_info utrap = { 0 };

Just {} please.

> +        /*
> +         * Bit[0] == 0 implies trapped instruction value is
> +         * zero or special value.
> +         */

How come you get away without dealing with pseudoinsns? The insn pointed at
by regs->sepc is of no interest for faults caused by implicit memory accesses
originating from VS-stage address translation.

> +        *insn = riscv_vcpu_unpriv_read(true, regs->sepc, &utrap);
> +        if ( utrap.scause )
> +        {
> +            /*
> +             * A G-stage fault here would mean the P2M mapping of the page
> +             * containing the trapped instruction disappeared after it was
> +             * fetched.

Does it? What about, again, faults from VS-stage address translation while
hardware was trying to fetch an insn? That is ...

> Nothing removes P2M mappings of a running domain yet,
> +             * so this cannot happen.

... the necessary P2M mapping may never have been there.

> +             * TODO: Revisit once P2M mappings can be removed at runtime.
> +             */
> +            BUG_ON(is_load_guest_page_fault(utrap.scause));
> +
> +            utrap.sepc = regs->sepc;
> +            utrap.stval = utrap.sepc;

How do you know the fault was at .sepc? A 32-bit insn crossing a page boundary
(implying the C extension is available) may well fault only on its higher half.

> +            riscv_vcpu_trap_redirect(&utrap);
> +
> +            return true;
> +        }
> +
> +        *insn_len = INSN_LEN(*insn);
> +    }
> +
> +    return false;
> +}
> +
> +/*
> + * Check alignment and dispatch a decoded MMIO access to a registered
> + * handler. On success (0), info->data holds the read value for loads.
> + */
> +static int do_mmio(mmio_info_t *info, unsigned long fault_addr,
> +                   unsigned int len)
> +{
> +    /* Fault address should be aligned to length of MMIO */
> +    if ( fault_addr & (len - 1) )
> +        return -EIO;
> +
> +    info->gpa = fault_addr;
> +    info->len = len;
> +
> +    switch ( try_handle_mmio(info) )
> +    {
> +    case IO_HANDLED:
> +        return 0;
> +    case IO_ABORT:
> +        return -EIO;
> +    default:
> +        return -EOPNOTSUPP;
> +    }
> +}

And there's no indication of "retry needed", e.g. when something changed
between find_mmio_handler() and handle_{read,write}()?

Also, nit: Blank lines please between non-fall-through case blocks.

>  static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>  {
> -    return -EOPNOTSUPP;
> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
> +    mmio_info_t info = { .is_write = false };
> +    unsigned long insn;
> +    unsigned int shift = 0, len, insn_len;
> +    bool is_unsigned = false;
> +    int rc;
> +
> +    if ( decode_trapped_insn(htinst, &insn, &insn_len) )
> +        return 0;
> +
> +    /* Decode length of MMIO and whether it is a sign- or zero-extending load */
> +    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
> +        len = 1;
> +    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
> +    {
> +        len = 1;
> +        is_unsigned = true;
> +    }
> +    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
> +        len = 2;
> +    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
> +    {
> +        len = 2;
> +        is_unsigned = true;
> +    }
> +    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
> +        len = 4;

Already up to here this demonstrates a weakness of the INSN_MASK_*
set of #define-s (which I similarly observe in binutils, and I expect it
all has the same questionable origin). All INSN_MASK_L* and INSN_MASK_FL*
(also INSN_MASK_S* and INSN_MASK_FS*) are identical, allowing for a nice
switch() to be used here in principle. That said, with access width
nicely encoded in FUNCT3, it's not even clear whether a switch() would
end up being needed / efficient.

Otoh none of these masks cover the pseudoinsns that htinst may supply.

Further, what about A-extension insns? Some (if not all) of them can
plausibly be used on MMIO, I think.

> +#ifndef CONFIG_RISCV_32
> +    else if ( (insn & INSN_MASK_LWU) == INSN_MATCH_LWU )

First: Better use IS_ENABLED() in favor of #if{,n}def, whenever possible.
And then this depends not only on CONFIG_RISCV_32, but also on guest
bitness.

> +    {
> +        len = 4;
> +        is_unsigned = true;
> +    }
> +#endif
> +    else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW )
> +    {
> +        len = 4;
> +        insn = RVC_RS2S(insn) << SH_RD;
> +    }
> +    else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
> +              RV_X(insn, SH_RD, 5) )
> +        len = 4;
> +#ifndef CONFIG_RISCV_32
> +    else if ( (insn & INSN_MASK_LD) == INSN_MATCH_LD )
> +        len = 8;
> +    else if ( (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD )
> +    {
> +        len = 8;
> +        insn = RVC_RS2S(insn) << SH_RD;
> +    }
> +    else if ( (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
> +              RV_X(insn, SH_RD, 5) )
> +        len = 8;
> +#endif
> +    else
> +        return -EOPNOTSUPP;

Because you don't permit F/D/Q for guests (yet), FL* and FS* aren't
covered, I expect? I wonder how easy it is going to be to spot the places
needing adjustment once support is to be added. Same perhaps for Zilsd in
RV32 guests.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 07:19:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 07:19:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389477.1630184 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuPig-0006h0-LV; Thu, 13 Aug 2026 07:19:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389477.1630184; Thu, 13 Aug 2026 07:19:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuPig-0006gt-IP; Thu, 13 Aug 2026 07:19:18 +0000
Received: by outflank-mailman (input) for mailman id 1389477;
 Thu, 13 Aug 2026 07:19:16 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuPie-0006gn-NI
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 07:19:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuPid-00C8e1-WE
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:19:16 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d6fed-bab6-0a2a0a5309dd-0a2a4504d4c8-24
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:19:15 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d6ff2-b57f-0a2a45040019-d155dd2ba916-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:19:14 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-4813ea321cdso379999f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:19:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981e37525sm39494875e9.3.2026.08.13.00.19.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 00:19:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786605554; x=1787210354; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Tg1x7LxiP1yJoKuSPAYkuKrDaCunc0z5kTYlqCAXgVA=;
        b=AaYMH7R1ZctJaa6/XjBMKijtUEFKZXinYTO5GbHuJ75yO+Hzn3Xb8ozU8ZkwV+FzgY
         tY53bqRu3JIgbfAP6JDuv4oIGPURVIiGQkplm89RRMJSinYtGNmLKPdxyv8lsQLNkuMO
         AdXcxNVTLqmSLczzPaGVIvfVViw0I5ZLqV5fc5PULIgwerzcltr5cj5e0LlfH/rhiik4
         e0rzBGyYv1aetUFzh3N/Xo+xujaYDb3JgcEBb6JlZkPIpl/XrQEJkwZW4g9J3dmln+y4
         rImAQKaTeQ74cQdPiMV9q84PdfRHcSzQ55c4O79Lsb63F9aA3b4ygWr804RRoME1/7po
         NhKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786605554; x=1787210354;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Tg1x7LxiP1yJoKuSPAYkuKrDaCunc0z5kTYlqCAXgVA=;
        b=H+jxs0teEpEQFfYiHIecM7hWV43DlyZcxwF5cTkgWDr4CeanqX+YlEdTVARVE7aphv
         6CvdIO4GoET6trPxmnnAuWQHMwtlIfTbQhqzEq0k8fn6g5K8Dj+xHsQR0KTsjfj7aMW/
         vyESkIgnwvNOvIE6jtWnZ+c0BLWfWulkWl6OspAsY+DRpNQh8T0WVkOBSfNyeW2gHNeu
         xbJRFSAaAhPo4Uwe7FT1Ij0HfzsvCu6Vo36iy74AuNnvqN1vrQs/vK+kXatLqRs2bR0I
         5GesAAbBm9isEf2CO3xtk19PPdToZM2pVglh6ZNGYuA2BtakhaQLJ0s49MbGLk0xR1hw
         XI+Q==
X-Forwarded-Encrypted: i=1; AHgh+Rp40HMMSgSKQjzXq4E6KNEhPu3j5YuY6g3PKLAiCRol/qzuSU30bprKYYSdRSnX7mpI/hyncQ583Dg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxzk/5zGH8a6vkVAU6iSdZ1v5tn4N0A5Ij2qbPXbKCtt6j6hnZU
	U4XR/udPLINCFEiBBY+XTmpHXY+y7MzK2y0MpreZp/guAg26g++LEcX9kaY7zHM5Sw==
X-Gm-Gg: AR+sD12LVECGqbGeD59z8zUh9Ae21ABUTKro+VmVm9Ar7MmDmrgg4AVxl5wjfGSd7Yn
	nWMkv1Agh2jlaB2prLQ7hgPFgcADxuHOu8OuD5oIiOWL9QJUlzcx+nt9p0JQN9d1iWSshJ3YDG+
	aTmFGBztOHyfcKA3RXXeAgiwdjBj0RPu+atMhVQ+VzG6qOFsFu2Y8wQh2aHJVMHdWRWwyplaR1h
	2e2XyvAIb7SDn70klMqH9tlBJOInTMmYb5+pOuu+Oe7/vyyTG8SfHegMazV+GWUnWQCcuH6+hEJ
	yaHlfnhrTOyiQJAJLlTftv07MrvD/SL25IlShVRT0P1dbSZj3UUlgobcw5sc2cCedsWtx3lG+mY
	ITe/BrdElypNWtoYFsqQ7CJh/lL+RzJBUFJQUYyzQ2V6eLOY+sevsl23stQMwDBozFQLPlo4BiP
	GTRJBvNRvpFRCjj33XfYrfhGCZUt7JBWOewlpeUyov7mBNHOUlB9la5LEcG9tA71XtRK90yzB+r
	+PPegNogJc3R12wOfVFRBV5Xd2isLmwONU9+jp2yW2aLmyzCi7k
X-Received: by 2002:a05:600c:1546:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-4998220bc5fmr27088225e9.7.1786605554432;
        Thu, 13 Aug 2026 00:19:14 -0700 (PDT)
Message-ID: <3bb59f64-7ff1-4bdc-b951-cfb78671e8f9@suse.com>
Date: Thu, 13 Aug 2026 09:19:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/20] xen/riscv: introduce guest riscv,isa string
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786605554-538C1B50-04E74C1E/0/0
X-purgate-type: clean
X-purgate-size: 2621

On 04.08.2026 17:47, Oleksii Kurochko wrote:
> @@ -120,29 +148,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
>   * and strncmp() is used in match_isa_ext() to compare extension names instead
>   * of strncasecmp().
>   */
> -const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
> -    RISCV_ISA_EXT_DATA(i),
> -    RISCV_ISA_EXT_DATA(m),
> -    RISCV_ISA_EXT_DATA(a),
> -    RISCV_ISA_EXT_DATA(f),
> -    RISCV_ISA_EXT_DATA(d),
> -    RISCV_ISA_EXT_DATA(q),
> -    RISCV_ISA_EXT_DATA(c),
> -    RISCV_ISA_EXT_DATA(h),
> -    RISCV_ISA_EXT_DATA(zicntr),
> -    RISCV_ISA_EXT_DATA(zicsr),
> -    RISCV_ISA_EXT_DATA(zifencei),
> -    RISCV_ISA_EXT_DATA(zihintpause),
> -    RISCV_ISA_EXT_DATA(zihpm),
> -    RISCV_ISA_EXT_DATA(zba),
> -    RISCV_ISA_EXT_DATA(zbb),
> -    RISCV_ISA_EXT_DATA(zbs),
> -    RISCV_ISA_EXT_DATA(smaia),
> -    RISCV_ISA_EXT_DATA(smstateen),
> -    RISCV_ISA_EXT_DATA(ssaia),
> -    RISCV_ISA_EXT_DATA(sstc),
> -    RISCV_ISA_EXT_DATA(svade),
> -    RISCV_ISA_EXT_DATA(svpbmt),
> +static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
> +    RISCV_ISA_EXT_ENTRY(i,            true),
> +    RISCV_ISA_EXT_ENTRY(m,            true),
> +    RISCV_ISA_EXT_ENTRY(a,            true),
> +    RISCV_ISA_EXT_ENTRY(f,            false),
> +    RISCV_ISA_EXT_ENTRY(d,            false),
> +    RISCV_ISA_EXT_ENTRY(q,            false),
> +    RISCV_ISA_EXT_ENTRY(c,            true),
> +    RISCV_ISA_EXT_ENTRY(v,            false),
> +    RISCV_ISA_EXT_ENTRY(h,            false),
> +    RISCV_ISA_EXT_ENTRY(zicntr,       true),
> +    RISCV_ISA_EXT_ENTRY(zicsr,        true),
> +    RISCV_ISA_EXT_ENTRY(zifencei,     true),
> +    RISCV_ISA_EXT_ENTRY(zihintpause,  true),
> +    RISCV_ISA_EXT_ENTRY(zihpm,        true),
> +    RISCV_ISA_EXT_ENTRY(zba,          true),
> +    RISCV_ISA_EXT_ENTRY(zbb,          true),
> +    RISCV_ISA_EXT_ENTRY(zbs,          true),
> +    RISCV_ISA_EXT_ENTRY(smaia,        true),
> +    RISCV_ISA_EXT_ENTRY(smstateen,    true),
> +    RISCV_ISA_EXT_ENTRY(ssaia,        true),
> +    RISCV_ISA_EXT_ENTRY(sstc,         false),
> +    RISCV_ISA_EXT_ENTRY(svade,        false),
> +    RISCV_ISA_EXT_ENTRY(svpbmt,       false),
>  };

Just as an independent, up front remark after having looked at patch 16/17 of
the other series: Is a mere boolean going to suffice in the longer run? I could
see some extensions wanting exposing to only RV32 or only RV64 guests. E.g.
Zilsd is RV32-only, while Zqinx quite likely would want restricting to RV64.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 07:29:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 07:29:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389489.1630194 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuPrx-00004x-LT; Thu, 13 Aug 2026 07:28:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389489.1630194; Thu, 13 Aug 2026 07:28:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuPrx-00004q-GW; Thu, 13 Aug 2026 07:28:53 +0000
Received: by outflank-mailman (input) for mailman id 1389489;
 Thu, 13 Aug 2026 07:28:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuPrv-0008WQ-N9
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 07:28:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuPru-00CAmA-Hd
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:28:50 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d7227-8faa-0a2a0a5109dd-0a2a4506e366-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:28:50 +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 <jbeulich@suse.com>)
 id 6a7d7232-195a-0a2a45060019-d1558030c9dc-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:28:50 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so2472815e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 00:28:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5af45fsm4173392f8f.18.2026.08.13.00.28.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 00:28:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786606130; x=1787210930; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=WnKfuhOpN9cEpBpCnJX7qk1wPx4868zb1MjUnE+BZe8=;
        b=CIGqrYt+p6L5/ZyHbekR9B9B7klv2r2Fqp45fMrrofpM4v9ZoH19qDgikekwl/Glm3
         guDnvWxc1VUDNYjXoqge7ebqCBZaIcvV0fkxORR/f9LAJFVmhtfNN1dmUEWYKlVbD8M5
         p6KjP0tTdEFGFN9u6OGb3Le3LYpq5EPYmbLURl7i/4ZdqC0cK2Y3lWa7r7vc38m14t1h
         9ULUOG50q+0+1wuUMhyFeU9BlJOxu+dgpux0VOKhng6/J0/r8x7FehQxcrw097GTQcMC
         Q/STE7e1TuSTmsIK/u4VrkXGjLrF/sMAksF870oPG7l99ZJ7u5X59wdJ//zyN+DlEbW8
         jNmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786606130; x=1787210930;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=WnKfuhOpN9cEpBpCnJX7qk1wPx4868zb1MjUnE+BZe8=;
        b=tJMvpSm2pVAKUIHZ/4SPNzgOLx3IiXDgFE1n3QYqdF5xokrvNsj88fpMPK/PB2c2tT
         QuzELt7lC3QwXab3cmGBRqfqidemq5rZMmb39q4hmQ43ZGsUz2LhpzpSrenzZbanVCyj
         jk12/YGWYlMu462Y+/FphdrF5vxgA/YrbPq3PPit/VkFt2YRrfAs31/Ob1ir+bZ5OnBx
         ktc8OO0Cl0EawaVJQoYQih62D21H3yla1eIuViM0vq2rONIYkKfeyPgleRXbXZAutOQR
         gGZaVCHevLXAqMqWXseR83CF9i1GNRNEcFB3n7LHa61Ntkg/2IGm8bUkiY9hltOubMfe
         B/3Q==
X-Forwarded-Encrypted: i=1; AHgh+RpziUi2b07/KxePtr9lg+qRpHdgI1KBG9hbJyHgQbNZJcAw8sdS2igJE+dwUqYi6pXNjQg/0wMKvpY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyLE8uvB5jaUzLdrEqzfHjFoRCsbnBqodCd5vkk7yUwVATaRFWL
	lVz2wml6O8eslGvrf0xMUEPNA7x2MqcITwI1h7XaZOI9I3xRCY2OKiRNJ8QS7Y1zdw==
X-Gm-Gg: AR+sD112IKdW2oBSp8VO97I3I9W4mG9cnx376irgbZyzfNQEZ6KPN3xHNUeNPRHcAvE
	GvtEfd5jUGe/lBulkCMrmFkuyctlwaPudvH0OfDuAAYRWsLViwues/ihDB2c+jI6I9v000Iz9BP
	nrntRzjZqjROe48eHFgmLyyPEKdduiYYLBU49o9p3tvVXexDDSa5iEaU0PxWeQmWzhsWKx/97FF
	wLGHI5EFbciMuPRS3/YARfe6JcvlawDDhCvx6rmX9ZLfbTCq3rzh0TgQ6GGzZD+ft+Kjrc+7SCN
	jzUNyH5I7PS4j928mPY8Wi7WlIdzxl6bAx3d7d/UuBawSoBPMkOhIAOp7dc1If+hnX+7iXvtsf4
	2MppzKWgdAF9dcHBuqfXywet2ShsMBcKJPb+8YBo00l7gSMMBNBnWxTqsC5V6JXTb8+0wo3QpBw
	0XwbeFItPXcyr6DHEi2iJHOe3QkPyPone+Vlle0uLAEXwHaJztqIL2QgPrS8ZSgLGT2s0ud3nwM
	IEdeRE+loRBSMM+omWHXH1brB6uGmsoOajuVsy8eNDHO/XZIIZD
X-Received: by 2002:a05:600c:1c24:b0:496:bbcb:b0bb with SMTP id 5b1f17b1804b1-49982206f28mr44422525e9.18.1786606129910;
        Thu, 13 Aug 2026 00:28:49 -0700 (PDT)
Message-ID: <20a4599a-f14e-4c7f-a765-52c1ab667516@suse.com>
Date: Thu, 13 Aug 2026 09:28:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
From: Jan Beulich <jbeulich@suse.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
 <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786606130-F460277B-6FD9AA58/0/0
X-purgate-type: clean
X-purgate-size: 2032

On 13.08.2026 09:15, Jan Beulich wrote:
> On 29.07.2026 15:40, Oleksii Kurochko wrote:
>>  static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>>  {
>> -    return -EOPNOTSUPP;
>> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>> +    mmio_info_t info = { .is_write = false };
>> +    unsigned long insn;
>> +    unsigned int shift = 0, len, insn_len;
>> +    bool is_unsigned = false;
>> +    int rc;
>> +
>> +    if ( decode_trapped_insn(htinst, &insn, &insn_len) )
>> +        return 0;
>> +
>> +    /* Decode length of MMIO and whether it is a sign- or zero-extending load */
>> +    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
>> +        len = 1;
>> +    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
>> +    {
>> +        len = 1;
>> +        is_unsigned = true;
>> +    }
>> +    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
>> +        len = 2;
>> +    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
>> +    {
>> +        len = 2;
>> +        is_unsigned = true;
>> +    }
>> +    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
>> +        len = 4;
> 
> Already up to here this demonstrates a weakness of the INSN_MASK_*
> set of #define-s (which I similarly observe in binutils, and I expect it
> all has the same questionable origin). All INSN_MASK_L* and INSN_MASK_FL*
> (also INSN_MASK_S* and INSN_MASK_FS*) are identical, allowing for a nice
> switch() to be used here in principle. That said, with access width
> nicely encoded in FUNCT3, it's not even clear whether a switch() would
> end up being needed / efficient.
> 
> Otoh none of these masks cover the pseudoinsns that htinst may supply.
> 
> Further, what about A-extension insns? Some (if not all) of them can
> plausibly be used on MMIO, I think.

Because of the further additions that are going to be needed, may I also
suggest to consider putting emulation code in its own file (emulate.c
perhaps), rather than directly in traps.c?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 08:12:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 08:12:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389510.1630202 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuQYU-0007X9-2j; Thu, 13 Aug 2026 08:12:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389510.1630202; Thu, 13 Aug 2026 08:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuQYT-0007X2-W6; Thu, 13 Aug 2026 08:12:49 +0000
Received: by outflank-mailman (input) for mailman id 1389510;
 Thu, 13 Aug 2026 08:12:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuQYT-0007Wv-6U
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 08:12:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuQYS-0006ec-4s
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:12:48 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d7c6c-2eae-0a2a0a5409dd-0a2a450c93f0-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 10:12:47 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d7c7f-f479-0a2a450c0019-d1558035d1bb-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 10:12:47 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so4111025e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 01:12:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49982130365sm45347505e9.7.2026.08.13.01.12.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 01:12:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786608767; x=1787213567; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=3QPl/G8phE1E3cAg+rCD1JXfC2gmx306uakT5JXiUhQ=;
        b=YZBavGGw3fUjw/A1RpdYHuYlbIfQQe5TJlY5037ldI57LfOYhHdaX7krRp+YgborvK
         jE9D23Katmtn/c4gv64Zo4F/ovJ1UIGL7TVlM+zaxCzvLs2p5r3QWlBIOJww4eSpVCh/
         WsV7LkpbLIpigNCJzDnNM68zFJTM+Ws7/x53OnEhlTHFl9wdy5PM/9XhokIuffa/J0VY
         YfV/oEEoy21apWeXz9sl6tKIRqElIeP4OANwIn16yOTdyn9D0IMZNJUTbBk1+4MM99tF
         Lxwfr0QUD04iLal7+INX3evD0E9fvj7klkf03Sb8TNRcOAMFl7C+kMkd1vZS691yD1WD
         tTJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786608767; x=1787213567;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=3QPl/G8phE1E3cAg+rCD1JXfC2gmx306uakT5JXiUhQ=;
        b=bua1G+WYUZ4RPBwx4WwU12hi9XL69lJU469LXN2Dm3EDq7KP2vmisBbFsI/uiyRFf0
         OQG+GLswYZG0fnIpRrGFHyjTz7lsJ+jTUnVA9hXgAGAePDodAnWZlzLIAKdtxGFwtRCk
         6xqFvUQ1LAVtqp9urNNEUHBi6/naR3LHrzGrw3ou/oG27c+8HggRGHlZyWhiIIxHDZ0g
         aQCJNqFw2dwin9rX52ODRt309wd70Glndml3IPZKz3J1/lsht928E/TmRXD1DG74BD/n
         8UjVixXVJ25uAbuJcHAcU83eBDAmIC3HhmnbcuuR0ZJUo476bhillNYPplmrRbauyoKT
         Ro0w==
X-Forwarded-Encrypted: i=1; AHgh+RrgVhfSCdoszXLMqMA6000Xr+fPpCUvcWxtT52hEV7K0F5ei8zSwvsYABJ6FxEsJBoJH4D1V/OMpRo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWc6eiGk5Di0+2rhfu9Ko3MSSJnMf/JDx3TVGYpwk1dV34QCHL
	h/Zcp1tk1oggmRxgXsmZq93znF4pYV8Cj1Z7/aRBN+8hI3d/HI3EPRh9Yu2w7cqp+g==
X-Gm-Gg: AR+sD11J7XlRLeeu9Db9I9G2UsclHCBjHbHihLYXe04YDzYHwHIpqEMiqroGE03Fgde
	NVGHvKf4dGSSquioaf2w6Y+cs7AI8Hf8tdzeZLIAERHYklsQjHPbOmo1xn0zt7u01Ma/qOo7cdb
	L3V5PQa+LRrSLOIkfwnnf0hpFmEzFtUHcwYEnpwLtOvnD+LIGOekxCNMz+fHu/a/bR7p9n/U/Lg
	FzPxZ63iTwRyhZODfIKHkkBZAuRWJ/uh0E5kUxWsMfa7LBjFral/kUnOxLXrzm0PAOYqjo6mH7a
	5b22cp3KPpdqWRiohhkaT0exubNijMC81hy2q8MkrEqUbzrH6ZloJwGd4bvslNZfpYeRnuozCTZ
	GxUYNunuf6KFRfOREdr++RchZtsYuPprWkE3P+/KCu4sqvmHKl2kRI94PgFVCem14Y3YwIN4QWs
	y41irueDTXSx9ogeKnWHnkkdBghdwaHv0s5OPjIsINVWIgOrRyPhbc3lPIGPu4QOBHHT5agf17H
	2ZFZgLh4v28BHJ1mYJLMBJYpC5MMYLjxKv2fk5WRm9l35lqDfoL
X-Received: by 2002:a05:600c:8284:b0:499:6a92:fff1 with SMTP id 5b1f17b1804b1-499821989abmr48826045e9.18.1786608766987;
        Thu, 13 Aug 2026 01:12:46 -0700 (PDT)
Message-ID: <affe36be-1638-4ff1-bbc1-d970f3547abe@suse.com>
Date: Thu, 13 Aug 2026 10:12:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/nSVM: Check injected event consistency
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786608767-76EDAA5B-C1727113/0/0
X-purgate-type: clean
X-purgate-size: 4616

On 06.08.2026 19:23, Abdelkareem Abdelsaamad wrote:
> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has
> debugging complications, security and performance implications. The APM
> volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that
> result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are
> • Reserved values of TYPE have been specified.
> • TYPE = 3 (exception) has been specified with a vector that does not
>   correspond to an exception (this includes vector 2, which is an NMI, not
>   an exception).
> 
> Extend the VMCB validation to check for such inconsistency.
> 
> The collection of the invalid exception vectors are ported from the upstream
> KVM commit
> ("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust
> the checks from the commit to align with the APM Volume #2 and Volume #3
> (40332—Rev. 4.40—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which

Isn't this 4.10, just like you have it further up?

> should not be valid on the x86 64-bit (long mode) platforms. The adjustment is
> posted to the KVM mailing commit patch thread
> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/
> 
> Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
> ---
> Changes in v3:
> - Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to 
>   non-64-bit guests to prevent impossible guest-mode state injections
>   per AMD APM Volumes 2 & 3.
> - Refactored exception vector validation from if-conditions to a switch
>   statement to improve readability and extensibility.
> - Restricted X86_EXC_CP (21) vector injection to hosts with enabled CET
>   to prevent VMRUN failures on hardware without CET support.

When reading this, I was puzzled, but the code below is correct: It's not
the host you check, but the guest's CR4.

> --- a/xen/arch/x86/hvm/svm/vmcb.c
> +++ b/xen/arch/x86/hvm/svm/vmcb.c
> @@ -320,6 +320,41 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
>      svm_dump_sel("  TR", &vmcb->tr);
>  }
>  
> +static bool is_valid_svm_vmcb_injected_exception_vector(

Is in particular "svm" but perhaps also "vmcb" really relevant in the name
here (which is a static helper)?

> +    const struct vmcb_struct *vmcb, uint8_t vmcb_injected_vector)
> +{
> +    switch ( vmcb_injected_vector )
> +    {
> +    case X86_EXC_DE:
> +    case X86_EXC_DB:
> +    case X86_EXC_BP:
> +    case X86_EXC_UD:
> +    case X86_EXC_NM:
> +    case X86_EXC_DF:
> +    case X86_EXC_TS:
> +    case X86_EXC_NP:
> +    case X86_EXC_SS:
> +    case X86_EXC_GP:
> +    case X86_EXC_PF:
> +    case X86_EXC_MF:
> +    case X86_EXC_AC:
> +    case X86_EXC_MC:
> +    case X86_EXC_XM:

Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set?

> +    case X86_EXC_HV:
> +    case X86_EXC_SX:

Are #HV and #SX really permitted without any constraints?

> +        return true;
> +    case X86_EXC_OF:
> +    case X86_EXC_BR:
> +        return !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l);

Nit: No need for parentheses on the rhs of the ||.

> +    case X86_EXC_VC:
> +        return vmcb_get_sev_es(vmcb);
> +    case X86_EXC_CP:
> +        return !!(vmcb_get_cr4(vmcb) & X86_CR4_CET);

No need for !! when converting to bool.

> +    default:
> +        return false;
> +    }

Throughout: Blank lines please between non-fall-through case blocks.

> @@ -392,6 +433,16 @@ bool svm_vmcb_isvalid(
>          PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
>                 vmcb->event_inj.raw);
>  
> +    if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) )
> +        PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n",
> +               vmcb_injected_type);
> +
> +    if ( (vmcb_injected_type == X86_ET_HW_EXC) &&
> +         !is_valid_svm_vmcb_injected_exception_vector(
> +             vmcb, vmcb_injected_vector) )

Nit: Indentation is off by one here. The anchor on the earlier line isn't the
'!' but the 'i'.

> +        PRINTF("eventinj: Invalid Injected Event. Exception type: (%#"PRIx8"),"
> +               " with a vector: (%#"PRIx8") does not belong to an exception on"
> +               " the platform \n", vmcb_injected_type, vmcb_injected_vector);

This message is quite a bit too long. There's also a stray blank ahead of the
\n. And further arguments after one that was already wrapped across lines want
to start on a separate line.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 08:40:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 08:40:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389524.1630212 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuQz6-0003Vf-4a; Thu, 13 Aug 2026 08:40:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389524.1630212; Thu, 13 Aug 2026 08:40:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuQz6-0003VY-12; Thu, 13 Aug 2026 08:40:20 +0000
Received: by outflank-mailman (input) for mailman id 1389524;
 Thu, 13 Aug 2026 08:40:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuQz4-0003VP-EP
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 08:40:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuQz3-005fwJ-RS
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:40:17 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d82ef-e002-0a2a0a5209dd-0a2a4506a920-6
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 10:40:17 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d82f1-195a-0a2a45060019-d155802cb8eb-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 10:40:17 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so22040855e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 01:40:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5612b8sm3760695f8f.1.2026.08.13.01.40.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 01:40:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786610417; x=1787215217; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ioN0GcUgDupZWMnqex7h46Dzd0XGzkRzLaOePnGqE5k=;
        b=XdO5w/QmFHtWZ9Pk171nEx9FVdIEvaJd4NkZW+Pic3DnfXiRuPPO85Tp754s7s2brq
         r4a4DEskDJ9W7035HiqVDjiCySU4yEMLXY/MRg24MyucG2iHD4Z2/skG5hvGD7P/DK2+
         d9r00iOv5pSh/fVD/wfjV15yBoj4QnNytogHrKPU+KrsEFUqzMzwJk5NXcA9aQ8rNIE4
         cgUGARzSMT0MXtQfoQsTkQigU0a2Z6wihi9cBlveOq4xh+rR/EC+meLfCxJhNkjV/U6B
         oNtQMZW49sUBwVbANgjSszX3kiu6ibYPeFGM3pkpkcg+/xnqmNVjs8IVI4hyTx5QVT4J
         DaZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786610417; x=1787215217;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ioN0GcUgDupZWMnqex7h46Dzd0XGzkRzLaOePnGqE5k=;
        b=eLBkW31yQZki/apVTa2gQscBpuZ4FCwuealOKTNkEGmjFQ3zr16bf8UfN712tsIBZF
         WqSuZBIcua0n5LfIelHUnRvbbwgI79dReXerQMQnGxH9qyXMf29uKHxJCe/mfK00O8XN
         TtQoVBiP/jv9LkbItCnDsHpsLwj1G2scE/r7Dxh2EdVStsMMUCsWdfmTyeeWOFF5Yp8M
         Lyg2AhBpOJm/K00h+Cgi+kDrT+ulVYJFnWon2ntAKMIlCUkXIc9MT4tWaJvx7RpgCnS7
         9gJ7a7MgpgCEv2aB+YknU4DjT8P+0bkrR8o+2Xgwpl9lSSr7C6rfR0mrxaCIj9nUbPo9
         G1yw==
X-Forwarded-Encrypted: i=1; AHgh+RqeZsMP1j/pmTMNeV+yTsXOJ3k1VSrNGcADHQUCJYl/JmFvRVe8bmZISH0so7iijV1yMeJ2tstn67M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzfRVTp577SJ6LVIaCNcszc7ad/jUP2bQN/c800f1N64qGmqq8C
	8XllJ4tPu8+y352X69XfeKPLDJsDM5uiTvETjNCvWjoG/E0RsCGHee2mMabusO1Tng==
X-Gm-Gg: AR+sD11YfPIR202S2KLm0quRz8Q1an+fDf2V6lVdUHb0yxxyBooAP8xrqJfkbc0kJvq
	kCsLN30SD89PfsIqNpoSqKzdUi3XXCzbIuFAU6MXlRGmw0AHUP8ZvSsyQrZUnXEChv4Zwaoo2fn
	dBmYt5kQn07f00N+iTTG1s6vcQWitpjZIV6vjPxMMgtFKyVqgjTRFy2NcoXS7FqqRen8cfDKls4
	V3+v9KolGH+FWNnkB0p7dgsQS5X84uQrepz8D77+v2+TPRtHGpHFupHhTFoWWxRTwWZFdekXIBW
	ZMsHfLHSDLkIzMjYAnPFue7OqZVKarK0ySKlqyPgnZQIS7m0RfvaOrwHGzzKsvr2RdATLLOpgqU
	I8EhBqpwLfA9lXFuqvAvY4IeCm6b7++IpP6zBEZC9gdLmIiivzgl2Aaoy3HLb3tQjGAv+/qIKQp
	5dY1VxMMSZqqF22sJV1lJWNzNps4qM49TIFnj7x6rYwyyQ78SxB27wRlvzbKkpBYhWWfYzBRpfV
	Rhj+8v9vH+4x6uyDQBGDENTVazXD7PyV3DSvRCySXuCTVZc7dB1
X-Received: by 2002:a05:600c:e48a:b0:495:5045:39e6 with SMTP id 5b1f17b1804b1-499821fefb3mr30044825e9.17.1786610417106;
        Thu, 13 Aug 2026 01:40:17 -0700 (PDT)
Message-ID: <0cec914c-e52f-41ee-873b-6bdbc1d1ed82@suse.com>
Date: Thu, 13 Aug 2026 10:40:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/nSVM: Check the L1 IOPM_BASE assigned physical
 address
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <f97fdc50622e4db559ce059091d0ebf2028e2f2e.1786114518.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <f97fdc50622e4db559ce059091d0ebf2028e2f2e.1786114518.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786610417-F420077B-8B32B6B8/0/0
X-purgate-type: clean
X-purgate-size: 2360

On 07.08.2026 17:58, Abdelkareem Abdelsaamad wrote:
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -18,6 +18,7 @@
>  
>  #define NSVM_ERROR_VVMCB        1
>  #define NSVM_ERROR_VMENTRY      2
> +#define IOPM_PAGES_COUNT        3

This new item is separate from the NSVM_ERROR_* values and hence wants separating
by a blank line. Especially with the three numbers being in sequence, not doing
so could end up being confusing.

Considering the constant is used exactly once - do we actually need a constant?
Can't we ...

> @@ -294,6 +295,15 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>      enum hvm_translation_result ret;
>      unsigned long *ns_viomap;
>      bool ioport_80 = true, ioport_ed = true;
> +    gfn_t ns_iopm_end =
> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), IOPM_PAGES_COUNT - 1);

... use a suitable expression here, e.g. PFN_DOWN((0xffff + 3) / 8)?

> +    if ( !gfn_valid(v->domain, ns_iopm_end) )
> +    {
> +        gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n",
> +                 __func__, ns_vmcb->_iopm_base_pa);
> +        return NSVM_ERROR_VVMCB;
> +    }
>  
>      ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
>  
> @@ -302,13 +312,12 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>      if ( ret != HVMTRANS_okay )
>      {
>          gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret);
> -        return 1;
> +        return NSVM_ERROR_VVMCB;
>      }
>  
>      /* Check l1 guest io permission map and get a shadow one based on
>       * if l1 guest intercepts io ports 0x80 and/or 0xED.
>       */
> -    svm->ns_oiomap_pa = svm->ns_iomap_pa;
>      svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
>  
>      ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT, 0);

In the description you say "without any sanity checks", yet
hvm_map_guest_frame_ro() -> _hvm_map_guest_frame() ->
check_get_page_from_gfn() won't allow unsuitable GFNs to be mapped. Since
here only the first page is mapped, some extra checking may indeed be
warranted, but the description then wants updating.

As to that part of the description, "directly to valid host address" also
doesn't look to adequately describe what's going on.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 08:45:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 08:45:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389534.1630219 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuR3p-00046n-N6; Thu, 13 Aug 2026 08:45:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389534.1630219; Thu, 13 Aug 2026 08:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuR3p-00046g-K0; Thu, 13 Aug 2026 08:45:13 +0000
Received: by outflank-mailman (input) for mailman id 1389534;
 Thu, 13 Aug 2026 08:45:12 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+dce20e51c50ea6bf637d+8390+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wuR3n-00046Y-Ii
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 08:45:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuR3l-005uSk-SJ; Thu, 13 Aug 2026 10:45:10 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+dce20e51c50ea6bf637d+8390+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7d8412-8faa-0a2a0a5109dd-0a2a4506cd88-12
 for <multiple-recipients>; Thu, 13 Aug 2026 10:45:09 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+dce20e51c50ea6bf637d+8390+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7d8414-195a-0a2a45060019-5a9b3222dee2-3
 for <multiple-recipients>; Thu, 13 Aug 2026 10:45:08 +0200
Received: from [2001:8b0:10b:5:9e94:e235:608c:ebeb]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wuR3T-00000003Hlx-3NEH; Thu, 13 Aug 2026 08:44:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=avnQtZManE1idvoUdPEQ7Vvjtfl50S261IhWnhrjKkY=; b=VpJzI+jqai9Vs4833VhnuCf/XA
	S5NcLnF+Y61SHbIs2NhaMGUm18oeDjUw4Oq400MV+UtcWmpp8FwxKWu/NJq7to631/8vUeSkQJa0D
	tvdZC1Z0rBYhuvXdnkYu5Mzw/QQMnAw0Bhsuqv18l0Es9IvsZdT93bbfGk0yQtGwIZc5p5X9QLFJ2
	wfIH+FYviBBOfYNCVJC+KEgeZbjplYksK+szPlBiTzD/ar0nAATk6bwO/8hWBkx7TXAhuNT2cMNaD
	ICg9+SWeJC4xNjISoxacxjcGJjdyGKdYzhLJ5ain82ZsccQeMS8j1ko2/A6eneRI5D1qxbdSPTJfb
	NT9sgeLg==;
Message-ID: <69b0cc5aa1032d708700bd2367b43d6238fc4079.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Thu, 13 Aug 2026 09:44:43 +0100
In-Reply-To: <ants4VjfAiblaWsl@google.com>
References: <acd9b32617f75d188c370a464a922af0d650d4f5.camel@infradead.org>
	 <ano6-gIZtqMfipiD@google.com>
	 <bb9a12cc663130eb2caa8e839d0f6ca53d722d1c.camel@infradead.org>
	 <ansuqrD2KwFuLWbV@google.com> <ansywxh0VX5rtfWc@google.com>
	 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
	 <antQYJvRxJxOjtut@google.com>
	 <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
	 <antb01WqOrs-tztm@google.com>
	 <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
	 <ants4VjfAiblaWsl@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-phlfi6ZPB3X+KU4yReB7"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-16d1c6/1786610709-FCE0677B-D79138E8/0/0
X-purgate-type: clean
X-purgate-size: 12987


--=-phlfi6ZPB3X+KU4yReB7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 11:41 -0700, Sean Christopherson wrote:
> > > > And your variant just added a dependency on wallclock time back int=
o it
> > >=20
> > > Can you elaborate?=C2=A0 I'm guessing I don't entirely understand wha=
t you mean by
> > > wallclock time.
> >=20
> > The system_time field? The unspecified might-be-UTC-might-have-leap-sec=
onds one :)
>=20
> Ok, I think I finally understand the goal.=C2=A0 I got turned around by t=
he combination
> of the name SET_CLOCK_GUEST and the full pvclock structure being passed t=
o the
> guest.=C2=A0 I was expecting SET_CLOCK_GUEST to literally set the entire =
clock, e.g.
> mul+shift, timestamp, etc.

Apologies, I don't think I was paying enough attention; mostly my mind
was in the GPC/RCU thing. The system_time field I picked out was
actually the *guest* nanoseconds-since-boot, and there's nothing wrong
with that per se. I was wrong to pick on that specifically.

I think I still stand by my gut reaction, but it deserves a more
coherent analysis...

You had:

struct kvm_pvclock {
        __u64 tsc_timestamp;      // GUEST =E2=80=94 guest TSC cycles at sn=
apshot
        __u64 tsc_scaling_ratio;  // HOST  =E2=80=94 guest cycles per *host=
* cycle
        __u64 tsc_offset;         // HOST  =E2=80=94 guest TSC minus scaled=
 *host* TSC
        __u64 system_time;        // GUEST =E2=80=94 guest kvmclock ns at s=
napshot
        __u32 tsc_to_system_mul;  // GUEST =E2=80=94 guest ns per guest cyc=
le (with shift)
        __s8  tsc_shift;          // GUEST =E2=80=94 ditto
        __u8  pad0;
        __u16 pad1;
        __u32 pad2;
};

There are two kinds of fields in that =E2=80=94 the ones I've annotated as
GUEST vs. HOST. This approach is conflating two things: Setting the
guest TSC, and setting the guest's kvmclock.

The guest part gives the y=3Dm(x=E2=88=92x=E2=80=B2)+c relationship of the =
guest TSC to
its kvmclock. It means exactly the same thing on any host, and it's
precisely what Jack's KVM_[GS]ET_CLOCK_GUEST already passes.

The other two fields are host-relative: guest-cycles-per-host-cycle,
and guest-TSC-minus-scaled-host-TSC.=C2=A0You could use them to set the
guest TSC (its offset *and* its rate)... but you don't. You just kind
of assume this redundant information is true =E2=80=94 which it can't possi=
bly
be if this is a migration to a new host =E2=80=94 and trust what userspace
provides in precisely the two places where Jack's code was using actual
true data from a vCPU.

It's better without the redundant information.

We *know* how to set the guest TSC. We either restore the=C2=A0*offset* for
a live update, or it's the *one* time we're ever allowed to use
wallclock time, in the case of a live migration=C2=B9. That part lives
nowhere near here.

All we need is to express the relationship between guest TSC and the
kvmclock. And that's precisely what the existing pvclock_vcpu_time_info
ABI structure does.

You are right that with the current implementation, the *precise*
bitwise values of those fields might change (you can change the x' and
the c in the equation and have the same line). That's because there's
redundancy in the pvclock_vcpu_time_info structure already. If I
understand correctly, that's where your concern about asymmetry between
GET and SET comes from? I suppose we *could* make a new structure which
doesn't have the redundancy, but it seemed better to use the existing
ABI. (And has the added bonus that userspace can fish it out of the
guest memory even when migrated from a kernel that didn't have this
support. Yes, we've done that).

And again, I don't *like* it when KVM refreshes masterclock and changes
both the x' and the c in the equation... I *want* kvmclock to remain
bit-constant for the whole *lifetime* of a guest, even the redundant
parts. So I'd actually *prefer* our long-term userspace ABI to
accommodate that and not eliminate the "redundancy".


=C2=B9 (And with the stuff I've done on exposing the raw TSC values to=C2=
=A0
  userspace through PTP, even *migrations* can be done better by
  letting userspace calculate then set an offset).



--=-phlfi6ZPB3X+KU4yReB7
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTMwODQ0NDNaMC8GCSqGSIb3DQEJBDEiBCAYjEvGWiZsww5+SWWTmlASq9eT4YiP
B3zy6r4eT8V/ITCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIA1zQFDqHcBLSqVapQLwh+Wtad613mgSlb2cp5En34byHcL7IF341S
Ady0/xmFtfFMjBViQaGrFGMzsUc7LlQAVvWJdSJYt4Mf/l/5xNdu+sT/+pSAJP/gZHoIWotuqpKt
GIeQ0Xdpi4J+ifw3cVUpKexM1X7vS/iF0UAIa6hq7RarEZIYgiKBZLHIC6UGdd7leN+SB6H+WkDU
GbPQ/e/e1PzLDQqlQCUi5wYeEgnj2I29Dslm+1CIiaGnR5bHD97jYAi6em6Q8+dBjvMjZrzajgEy
bZaUYa4dijUPaOb5RFlk1aYA1zQjlPtUQXKYNnK4HwPLlNAm6rBmOyPU+4zfd4qEcE4I2pm9u70g
H5M6Kee9qsA1PNmhKZAsHqgwoPzdhtWOZ7nvw0RgbSjCQDQkFB96Nh2rcHFWJVhdhwH6Cx5+Bqen
lZVt1l5QwLhHiaQ7V3fOCRYZdgZLRj5Yy4J8x1rmM2SEPxIodTQgXcMZ/hJt83X1Swg289X0Cis6
wC2SieNEgbWbuPIzZ+almt8VA3Mtb7QDqLMxwOTa3ZikF7gCFbDFEAPVSJ2pdo6HNsth7lV8a2wP
m/2PvqEsPbd6SHLghfKMgGOvQhbnjJ/3JD9YHierishYpEWVDg1F5BIzAJWQXJb6Inmz1DdoQJ0C
RLXbMQQH9PcT/yHVPV7HiM8AAAAAAAA=


--=-phlfi6ZPB3X+KU4yReB7--


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:06:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:06:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389553.1630229 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuROj-0007Xh-Ad; Thu, 13 Aug 2026 09:06:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389553.1630229; Thu, 13 Aug 2026 09:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuROj-0007Xa-7h; Thu, 13 Aug 2026 09:06:49 +0000
Received: by outflank-mailman (input) for mailman id 1389553;
 Thu, 13 Aug 2026 09:06:48 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuROh-0007XU-UT
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:06:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuROh-00F57j-5L
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:06:47 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@swg.vates.tech>)
 id 6a7d891d-8faa-0a2a0a5109dd-0a2a4501a408-42
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:06:46 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@swg.vates.tech>)
 id 6a7d8926-5984-0a2a45010019-b9ff1c2383fb-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:06:46 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ffa5fb46a000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 13 Aug 2026 09:06:43 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 284178337E;
 Thu, 13 Aug 2026 11:06:43 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=mb3aF9fsNapQk9bhHnsbQAzh0C1Cb0F9INHpu5k1y+8=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=ISOzIdlsriY96lBqx+dop/NlaZvXiVQXRCxlpfXDpdci9FEju4P0UlrsTsnlxPQY6x5V4FjFy
 bS0WIp0JUzCgHDzMyRAzknJ2wSbpEyhRI6/F7FBeq5oWSdtXDyLrAdnvF8CRwcFn+QkvllDdxRb
 23b6nEJQ9kO+ARAKKKHp+fc7lM32SHkPB7NptwCv3AWuzH9ZzSWHscvfL8OHaXPaOu3txFTmuXj
 I0ROuMXYhLxK2AbutmSRZs2FcCIkO5BW0GFDmoqNHbyjepQg+aAjA3RyBrZIfREIL5rpU2qNNpi
 R0rIzbIsZrOJK6yJmi5wWtGpFS04jsY5W9QCQFovI5ug==
X-Zone-Loop: 1e03d96a5c2fdae23f3e2529dbb670ce0e95b4a1190c
x-campaign-type: default
x-transaction-id: d34a51b2-cb96-4f74-b62a-867821cf71aa
x-swg-uid: 01-303e70d8-1554-45bc-95df-076fd19a18e0
X-Mailer: Sweego
Message-ID:
 <1786612004.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@vates.tech>
x-swg-bid: 1786612004.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
Date: Thu, 13 Aug 2026 11:06:35 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786612003; l=4328;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=Apr05Wrtqcj294z4XLIqFbDmQ7hgfz39PF8WMsRa88o=;
 b=gTTGGPQIu/adbxjVaQ+MtX4l4HndJjq02GrfWB2cj3pJsuAcD8dtlJZ+UbCpsIud5lxxTPLqq
 Waup7+2kJJBD/djfI9cE0HrfCd5pvOa/eW6XeWqLj2+1qI6yYU0Ssfp
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786612003356
X-purgate-ID: tlsNG-d62444/1786612006-1E664757-52F39B0D/10/73395122804
X-purgate-type: spam
X-purgate-size: 4328

> 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 <oleksii.kurochko@gmail.com>


>
> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
> index ffce77209c..c5ae74e456 100644
> --- a/xen/arch/riscv/imsic.c
> +++ b/xen/arch/riscv/imsic.c
> @@ -25,7 +25,9 @@
>  #include <xen/spinlock.h>
>  #include <xen/xvmalloc.h>
>  
> +#include <asm/aia.h>
>  #include <asm/imsic.h>
> +#include <asm/p2m.h>
>  
>  #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ)
>  
> @@ -342,6 +344,67 @@ static int __init imsic_parse_node(const struct dt_device_node *node,
>      return 0;
>  }
>  
> +/*
> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU v
Nit: What is this `v`?
> + * 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 block,
> + * 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 hart.
> + *
> + * Xen pins each vCPU to a pCPU (v->processor) and assigns it a physical


> + * guest file index (guest_file_id) from the vGEIN allocator. A guest_file_id
> + * of 0 indicates that no hardware guest file is selected (matching the
> + * architectural behavior where vGEIN = 0 in the hstatus CSR selects no
> + * guest external interrupt source), requiring the VS-file to be emulated
> + * in software.
> + *
> + * 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 current pCPU.
> + */
> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
> +{
> +    int res = 0;
> +    struct domain *d = v->domain;
> +    unsigned int cpu = v->processor;
> +    vaddr_t gaddr = imsic_cfg.base_addr + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);

The variable holds a guest-physical address, so vaddr_t is the wrong
type should be either paddr_t or gaddr_t.

> +    paddr_t paddr;
> +    unsigned long guest_stride;
> +
> +    /* Nothing to map in the case of sw interrupt file. */

There is no software interrupt file implementation in this series, patch 11
turns the non-MSI path into a BUG_ON(). So "vsfile_id == 0" today means "this
vCPU gets no external interrupts at all and nothing tells anybody". Worth
saying so plainly here rather than implying a fallback exists.

> +    if ( !vsfile_id )
> +        return res;
> +
> +    guest_stride = vsfile_id * IMSIC_MMIO_PAGE_SZ;


> +
> +    paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset +
> +            guest_stride;


> +
> +#ifdef IMSIC_DEBUG

> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
> +#endif
> +
> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
> +                           arch_dt_passthrough_p2m_type());
> +    if ( res )
> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",

Maybe a use of dprintk() would be more appropriate?

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:25:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:25:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389604.1630255 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRgH-0003F1-3t; Thu, 13 Aug 2026 09:24:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389604.1630255; Thu, 13 Aug 2026 09:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRgH-0003Eu-0M; Thu, 13 Aug 2026 09:24:57 +0000
Received: by outflank-mailman (input) for mailman id 1389604;
 Thu, 13 Aug 2026 09:24:56 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRgG-0003Eo-6X
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:24:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRgF-008t9D-JX
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:24:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@swg.vates.tech>)
 id 6a7d8d62-8faa-0a2a0a5109dd-0a2a45089db0-14
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:24:55 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@swg.vates.tech>)
 id 6a7d8d67-f659-0a2a45080019-b9ff1c23a7c3-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:24:55 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ffa7047d4000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 13 Aug 2026 09:24:50 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 82038820C4;
 Thu, 13 Aug 2026 11:24:49 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=qb0xSwzsCVyssFu1XzN4sx3kGU/TAgxBEQvr3YS1vxk=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=mkMDaOe3/GpHPXgjxZdJ/VBEsfptyU/xWq3jysmz1t48GjXb/5C0mKmyqda8J/3yqj9Aa3kNS
 e2iYbYMheKmm/i1GLFnSJmxSpWMoIDjw/Zy8pUfHk4xy4s7W0oOOZven30aSqbrE5j/+9bDRcDh
 WRcpsH/N/5YTISRcgCk176hypc2JcgTadgdeWk2iXJojwlt5aVjDpwsM9+rKRtWITQvxxXlgo8o
 eqTr+SPqKLeEWNMjrw7T/AenWxGWjl3tTCvVIpC/41ojiX9/E9eHoaUlBKnUZPnY6EG1FlgZjXN
 02Nh4uFZ2EOJTHfUs7FcwjjEwmvoIhfUf7GrnZAmGJeA==
X-Zone-Loop: 22d62b376a1622a04d04648e5511686d44d1911a9985
x-campaign-type: default
x-transaction-id: 87e009f2-676b-43b5-be56-f2f9ac5d7ef7
x-swg-uid: 01-a8324a37-b3ae-498b-9797-df6497246a0e
X-Mailer: Sweego
Message-ID:
 <1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@vates.tech>
x-swg-bid: 1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
Date: Thu, 13 Aug 2026 11:24:43 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786613089; l=2700;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=ODzn7JwdxQAl0iItLtBLmdVGm38Bg1JjHeQObX6i2pk=;
 b=aC1FrFTxPzQn0vf7KVlfEAN0jWA+pwJ/nDRItUpuDuFausReGFrGS4SptF19+S88RiIvEcD0L
 KAyfR6EDUapCz1/fUCat7zf6mj2gMAnWteDoOuEi5WEBTKWWDM4d3hW
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786613089840
X-purgate-ID: tlsNG-c1860d/1786613095-D634587B-27D0D98D/10/73395122804
X-purgate-type: spam
X-purgate-size: 2700

> Introduce vcpu_aia_init() 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, vcpu_aia_init() will instead be
> called from a later point in the scheduling path (e.g.
> continue_to_new_vcpu()), to be introduced in a follow-up patch. 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 <oleksii.kurochko@gmail.com>
>
> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c
> index 4f7f46f58f..ed19600d46 100644
> --- a/xen/arch/riscv/aia.c
> +++ b/xen/arch/riscv/aia.c
> @@ -14,6 +14,7 @@
>  #include <asm/cpufeature.h>
>  #include <asm/csr.h>
>  #include <asm/current.h>
> +#include <asm/imsic.h>
>  
>  struct vgein_ctrl {
>      unsigned long bmp;
> @@ -36,6 +37,35 @@ bool aia_usable(void)
>      return _aia_usable;
>  }
>  
> +void vcpu_aia_init(struct vcpu *v)
> +{
> +    unsigned int new_vsfile_id;
> +    int rc;
> +
> +    if ( !aia_usable() )
> +        return;
> +
> +    new_vsfile_id = vgein_assign(v);
> +
> +    /*
> +     * vgein_assign() returns 0 when no free h/w guest interrupt file is
> +     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
> +     * in that case.
> +     */
> +    rc = imsic_map_guest_file(v, new_vsfile_id);
> +    if ( rc )
> +    {
> +        /* Can't continue w/o correctly mapped IMSIC interrupt file */
> +        domain_crash(v->domain);

The vgein id assigned a few lines up is not released here. The domain is dying
anyway, but the guest interrupt file stays marked in use on that pCPU forever,
since nothing else ever calls vgein_release(). A vgein_release(v,
new_vsfile_id) before the domain_crash() would fix it.

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:30:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:30:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389627.1630263 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRlm-0005A8-Ob; Thu, 13 Aug 2026 09:30:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389627.1630263; Thu, 13 Aug 2026 09:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRlm-0005A1-LJ; Thu, 13 Aug 2026 09:30:38 +0000
Received: by outflank-mailman (input) for mailman id 1389627;
 Thu, 13 Aug 2026 09:30:36 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRlk-00059v-UE
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:30:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRlj-00FADr-PS
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:30:35 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@swg.vates.tech>)
 id 6a7d8ebb-e002-0a2a0a5209dd-0a2a450ce42a-2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:30:35 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@swg.vates.tech>)
 id 6a7d8ebb-f479-0a2a450c0019-b9ff1c229a83-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:30:35 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ffa7577c9000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 13 Aug 2026 09:30:30 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 617E0815F8;
 Thu, 13 Aug 2026 11:30:29 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=lA9l696Zhw5G7iBZqTE7zluJ/Dc+9NB/c0K+v0ZqFJM=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=lkILRolV4qSvAiSbLnYShdrJUGA5/6Hr6tZb5HyKbMUxj6oL8LPlBHOd8rr7eUfgbf2OpDGkb
 DTCdXUJsfeokFRFxm0aSbuAs9QEtHFr8Om9cLv/b4WdfB8/YlW0wOIeDfm70QDhit5yloC4fgjL
 emllzKgY2FXlsAJLZnjf+EffXfHWu1Inq9te7t/Az0gYQtAE9febFNRga1R4bESYrVZR6w409yn
 neng70cP9yHWKn7KuS+UNPAn2fIZYEVsS7msaWPfPm+8swtkPYwi2WAvCTLaSOEKxhCXycmcyLV
 5VjxzQMxSur9vaT04wQeXKZzguDqvq/0mTUEhYL/eieg==
X-Zone-Loop: fb24413355519def26821c14deba7719a77926e529ab
x-campaign-type: default
x-transaction-id: f2012e9d-f77e-43bf-a633-4f32694a6d5c
x-swg-uid: 01-5fb208d5-3e36-4de2-bf09-fd2640f9efc8
X-Mailer: Sweego
Message-ID:
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
x-swg-bid: 1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
Date: Thu, 13 Aug 2026 11:30:22 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786613429; l=2338;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=bTaGYD/I2YNpv8P6YZhuklJ7/hph1PB1J2ttcJOAoyY=;
 b=PalooVOuQnvxJd5nR6Es0i/F/2BOcv9TJidOAe/TyjeBM/69iFFOZFuua0cJKrKCNQxBLPExs
 SQylRhvmCpYDM6kfXJSU8KginFxq9x4kfPAadYrNIfFQbghuexZ2mSB
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786613429713
X-purgate-ID: tlsNG-d25034/1786613435-52132A5B-365BB47C/10/73395122804
X-purgate-type: spam
X-purgate-size: 2338

> IMSIC state is currently needed only to track which physical CPU owns a
> vCPU's IMSIC interrupt file. This is required because the physical CPU
> ID is part of the physical address used to map the IMSIC file.
> 
> Add imsic_state_save() to record the current pCPU for a vCPU. When the
> vCPU is migrated to a different pCPU, the mapping will need to be updated.
> 
> When imsic_state_restore() is called, VGEIN is already assigned to the
> vCPU and the guest interrupt file is already mapped, and, as only h/w
> interrupt files are used for now, nothing specific needs to be done.
> Action is only required when the vCPU is moved to a different pCPU, which
> requires recalculating VGEIN and the mapping for the new guest interrupt
> file. That will be handled separately by vcpu_move_irqs(), which is
> introduced in a follow-up patch; until then this case is guarded by a
> BUG_ON(), which is fine.
> 
> Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>
> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
> index 2a792e756c..406bc68cbc 100644
> --- a/xen/arch/riscv/imsic.c
> +++ b/xen/arch/riscv/imsic.c
> @@ -20,6 +20,7 @@
>  #include <xen/init.h>
>  #include <xen/libfdt/libfdt.h>
>  #include <xen/macros.h>
> +#include <xen/rwlock.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <xen/spinlock.h>
> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>      return res;
>  }
>  
> +void imsic_state_save(struct vcpu *v)
> +{
> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
> +    unsigned long flags;
> +
> +    /*
> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
> +     * should be done in this case.
> +     */
> +    if ( !vcpu_guest_file_id(v) )
> +        return;


> +
> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);

How will you detect a migration is needed? Don't you need to first know
if ->vsfile_pcpu is different to cpuid_to_hartid(v->processor)? (I
didn't take a look to other patchs for the moment, so the
explanations might be later.)

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:32:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:32:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389635.1630271 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRn7-0005lf-1y; Thu, 13 Aug 2026 09:32:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389635.1630271; Thu, 13 Aug 2026 09:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRn6-0005lY-V7; Thu, 13 Aug 2026 09:32:00 +0000
Received: by outflank-mailman (input) for mailman id 1389635;
 Thu, 13 Aug 2026 09:31:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRn5-0005lQ-LG
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:31:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRn4-008ufH-VY
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:31:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d8f0a-e002-0a2a0a5209dd-0a2a4507dad4-16
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:31:58 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d8f0e-b4ea-0a2a45070019-d1558036d9fe-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:31:58 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4954a32cf1eso2178215e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:31:58 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a56981csm4885578f8f.10.2026.08.13.02.31.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:31:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786613518; x=1787218318; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=J3pQVDJwue280RgZMADMBv/5TFGknjyJyQDo6ue2b8k=;
        b=HLqVLw0LBnXssupZXIvy0PODjveniYpMBS+nG6CIPcsGmjb6MfD0s/ON+1/pPgRE4E
         5L18R0ArNdHnM/PUNgwSp7414YX+aJHtuzQGa6M0Gcdmh+9J2uhKUkUmApfvEyGGHDZC
         fSfV5h2o1wv0eZFYBogzVgnEdhh5znDPjl9OoipB6MMRn/8fVm6U7sUewCCE3WpyWmjy
         o2xwAaRDagJwnZEng9Ig4RiaChhzVIE2K/ctEGW/gnguaSBcQubrMgz7/qVPu0kQtXJo
         PZJyLVFoRAPkQ9RoKzIf0yC+H/Z/jbK/khVIyDHvoGUE6Dj1XGCXfQ9yNmhG9iAZYB0f
         rqCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786613518; x=1787218318;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=J3pQVDJwue280RgZMADMBv/5TFGknjyJyQDo6ue2b8k=;
        b=YYpYPWsgBIt/1wzczgoMhcnLorQd4UomBIVMkJ+wLRER3HmgVw2ztkcMtDhSxHvaZN
         fi3JJ/KH+JReorojJmRIoWlYPk+Gz14sOTcJ/mxiaiynH1k4mmJELNJqlUT0BFR80CLq
         bvcgYttPeRNx1CDK195zOW0hIHowB8AKkEDNHdLoBahlwsE3HkbwNQ27BFq3vBJpGpDa
         Dmh+sbpi+S8d4soF+Uh6zRm0P68R0oNq66LqnUHox87svZs8bqX8Ccvzr4ES+03DTHlT
         0gXycVvc3b5UZeIPngO7BSiQRToI6/5xBbz3kFI7tkDws6/ZgAz0sc2RL+QdA9/1xpac
         Te3w==
X-Gm-Message-State: AOJu0Yyik6nTSZ/ofxdPy2SMuhjiWZqYSrSf9qJohjoqdx/2wD+oITF6
	MGWozO/oXjZHnx8U/L9ApJ3R5nfwcVYrWzM8eH7wT+2NEOAyMZf63oDB
X-Gm-Gg: AR+sD13atBWn2Q9t49WNzatq0riAir4CvSAgVhjXpDGSffj2GbyTuXpBTu8jxbvSFvK
	4brFerMuC3MWpXWSqE89Yn3sAnDx5xiCEhT06fUzSC6mwCKTq4qq8PK73Ap2WTVl12CjyhdQCL7
	0aBwAKtKhjWG0YMttTGU6x7YAU66GpF+JXGBRZEUu0BB6Zmw9ER81+7y+4Ajy2M1dmn1vWrEd9Y
	ir49C0FZJZ8kTTBp2lWyT4DyayIGE2j7KB+XWvdm6Pn1VNpMAruFeaVrU27EUbKfYUK4vPp5pYK
	Ht6wsREViI2iAILKIupeCNRSq4aWj5O4xGIqlJTQihbwrbuV/iUKgh7nLPMmfdwvXty/kmnnouu
	cFdJPMsHj3apjbwBAFE4vb5iP0OOzsFE1/fgQzYfreP1plbEmrFNI1Gvrc0ZHnQHo2uzwAltvzC
	26r9wBhdJYyXVTXYjo2ultAzvzpW5L9D1QDF5us/2zyos+tN21iXYvhVzke6wkKNJIRTZzWxVU8
	3F62kZRrnqhvuPLK/vr9qh0ABCNLufUyalgkn9sces=
X-Received: by 2002:a05:600c:4585:b0:499:726a:a017 with SMTP id 5b1f17b1804b1-499821bcfecmr46986805e9.1.1786613518164;
        Thu, 13 Aug 2026 02:31:58 -0700 (PDT)
Message-ID: <2eedac12-74a8-4b7d-91d4-e8c4cb280529@gmail.com>
Date: Thu, 13 Aug 2026 11:31:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786613518-354C3AE4-64A70EDB/10/73395122804
X-purgate-type: spam
X-purgate-size: 2905



On 8/13/26 11:24 AM, Baptiste Le Duc wrote:
>> Introduce vcpu_aia_init() 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, vcpu_aia_init() will instead be
>> called from a later point in the scheduling path (e.g.
>> continue_to_new_vcpu()), to be introduced in a follow-up patch. 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 <oleksii.kurochko@gmail.com>
>>
>> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c
>> index 4f7f46f58f..ed19600d46 100644
>> --- a/xen/arch/riscv/aia.c
>> +++ b/xen/arch/riscv/aia.c
>> @@ -14,6 +14,7 @@
>>   #include <asm/cpufeature.h>
>>   #include <asm/csr.h>
>>   #include <asm/current.h>
>> +#include <asm/imsic.h>
>>   
>>   struct vgein_ctrl {
>>       unsigned long bmp;
>> @@ -36,6 +37,35 @@ bool aia_usable(void)
>>       return _aia_usable;
>>   }
>>   
>> +void vcpu_aia_init(struct vcpu *v)
>> +{
>> +    unsigned int new_vsfile_id;
>> +    int rc;
>> +
>> +    if ( !aia_usable() )
>> +        return;
>> +
>> +    new_vsfile_id = vgein_assign(v);
>> +
>> +    /*
>> +     * vgein_assign() returns 0 when no free h/w guest interrupt file is
>> +     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
>> +     * in that case.
>> +     */
>> +    rc = imsic_map_guest_file(v, new_vsfile_id);
>> +    if ( rc )
>> +    {
>> +        /* Can't continue w/o correctly mapped IMSIC interrupt file */
>> +        domain_crash(v->domain);
> 
> The vgein id assigned a few lines up is not released here. The domain is dying
> anyway, but the guest interrupt file stays marked in use on that pCPU forever,
> since nothing else ever calls vgein_release(). A vgein_release(v,
> new_vsfile_id) before the domain_crash() would fix it.
> 

Yes, agree with that vgein_release() is missed. I've mentioned that 
before in reply to Jan B.

Thanks!

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:34:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:34:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389642.1630282 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRpW-0006Jm-Ei; Thu, 13 Aug 2026 09:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389642.1630282; Thu, 13 Aug 2026 09:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRpW-0006Jf-AR; Thu, 13 Aug 2026 09:34:30 +0000
Received: by outflank-mailman (input) for mailman id 1389642;
 Thu, 13 Aug 2026 09:34:30 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRpW-0006JZ-11
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:34:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRpU-009jnL-Oy
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:34:28 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d8f98-8faa-0a2a0a5109dd-0a2a450abea4-44
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:34:28 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d8fa4-f2d2-0a2a450a0019-d155dd35e5f7-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:34:28 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-4815bce4652so197707f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:34:28 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5af453sm5229112f8f.23.2026.08.13.02.34.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:34:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786613668; x=1787218468; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1W1dY6FXTFT07DGJUMkU4P+XkErLbGXiTCzqyWLpuec=;
        b=ocsEOE3296AUONAVojEIIMl1lXxJLsoCKK3hZTAGapg7bVPbwgF4yYxYeCviPwmBur
         W8ID/5ti7XEI/B4cj1v59acdz6qWDc29FnIwHK3Esf3JUKjw4jxVOoXEU67/6M4aFA7B
         xo4KzWiF/avbMeQTpzVPwISxRgi0i6d5UtgWt5cRQF8ZjDJtsjnAWnMGhgzW3Y7QWly9
         WPBdgP//V+zbS87Int6u6Q22nVPYqqEcyhkxezCVZrc7Ze9d/J5sp9JCL7ABVL1tv3zC
         ErwnkAjbvIwj18Ernveydf8OoXo9vC5pdu4mh8+Wgfu1YvI9Bz3dReAD0lYJ/1Yrljde
         aV9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786613668; x=1787218468;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=1W1dY6FXTFT07DGJUMkU4P+XkErLbGXiTCzqyWLpuec=;
        b=ZNbTZ75387wz8BUx6u0FHePDBWs0UyvwVYsa1INAQRhNeOaP3OHOEKRQMCDwZGFimi
         ax7q65KYMjJvsZLcea4upN8R+3F2eUa9yoyx9HuzTMj/0i7uJUHvCBnH6GklNaMxKRm0
         dldr+QS9ognRHyImsee4RDVHEeCx8QuP+eeCyEapSg7tk4vfmAfvaCRdw6d9rmxGpnbM
         x9uFEwDn9UgpJ8A3Hnl8Pf+CdSsMNPLt5f8uNi05RXV/pTcXKOrxOe36isWZqcrvb+fQ
         fCWRC+kjuety4rFYRMzNC3ScdNUvzn6+PukPJuq8OF4DKe+D/kroi4mLbF/2ikF1eCve
         ss5w==
X-Gm-Message-State: AOJu0YzORX064946Qo8wQV8mIppkwYDMH+Ga1xzSmAsgvM91BZEJf7pM
	uM3zCQPnZ4MrOJ9apjEkm2ZlIkIZ6rlM+Q2OiKjLb1A3pfMWgwfQkgdp
X-Gm-Gg: AR+sD13yhpc3+ElWEf1lNGYueLYsEGuOj0ledUR77PjHxZE7s849746vU6ImcxFmHAH
	5l3zyErQSP8JZ0AUUFohuPuAxNC8yWN6c7qtfen2md0Y9a45b0EEZ1B4Cjhhv85Z5fZEbZK7NNe
	zH+sHAAJbU/nxVB3wXVo6YAg5ZculKMyUcmwD4coH/Et9dyd/Z4qiWJJk/xDcP/I/TYQjpG9+iF
	7cCiZkrQmflup4fiGQJxsC+OPqThkcILhcLYcdHgh6ca9pk1Cc2uW2CtPAJty4JdHsABtuDdvcN
	LHU9JNfWfdZrXi2Q6fuxbSEZJU1enhBU3PpBCQeUFQsIJKiZjU/wKXtFXDLu9Efz36G0q6ZlzXs
	oH6FVcfHAsRyPruanBxVZO/HgKQRQnjr7BKjlip0gamtgwYYZoj7+NMZ6XES+xJqgJbEzLEflJf
	ubG/Il4zRyy2o5KW08e9mgjzvs/9iudFj4LnaXN5/tpo+YNANkcYDJn6AjJyERy/f1H+WnL9FJa
	srsWlOlkc+UfWTDfqer1kDXcZ+K6lQ//B09DCE6PcE=
X-Received: by 2002:adf:f8c4:0:b0:481:4ee4:e49 with SMTP id ffacd0b85a97d-4815a03ecfemr4721827f8f.25.1786613667975;
        Thu, 13 Aug 2026 02:34:27 -0700 (PDT)
Message-ID: <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
Date: Thu, 13 Aug 2026 11:34:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786613668-520C1CFC-53E25DBB/10/73395122804
X-purgate-type: spam
X-purgate-size: 2563



On 8/13/26 11:30 AM, Baptiste Le Duc wrote:
>> IMSIC state is currently needed only to track which physical CPU owns a
>> vCPU's IMSIC interrupt file. This is required because the physical CPU
>> ID is part of the physical address used to map the IMSIC file.
>>
>> Add imsic_state_save() to record the current pCPU for a vCPU. When the
>> vCPU is migrated to a different pCPU, the mapping will need to be updated.
>>
>> When imsic_state_restore() is called, VGEIN is already assigned to the
>> vCPU and the guest interrupt file is already mapped, and, as only h/w
>> interrupt files are used for now, nothing specific needs to be done.
>> Action is only required when the vCPU is moved to a different pCPU, which
>> requires recalculating VGEIN and the mapping for the new guest interrupt
>> file. That will be handled separately by vcpu_move_irqs(), which is
>> introduced in a follow-up patch; until then this case is guarded by a
>> BUG_ON(), which is fine.
>>
>> Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>>
>> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
>> index 2a792e756c..406bc68cbc 100644
>> --- a/xen/arch/riscv/imsic.c
>> +++ b/xen/arch/riscv/imsic.c
>> @@ -20,6 +20,7 @@
>>   #include <xen/init.h>
>>   #include <xen/libfdt/libfdt.h>
>>   #include <xen/macros.h>
>> +#include <xen/rwlock.h>
>>   #include <xen/sched.h>
>>   #include <xen/smp.h>
>>   #include <xen/spinlock.h>
>> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>       return res;
>>   }
>>   
>> +void imsic_state_save(struct vcpu *v)
>> +{
>> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
>> +    unsigned long flags;
>> +
>> +    /*
>> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
>> +     * should be done in this case.
>> +     */
>> +    if ( !vcpu_guest_file_id(v) )
>> +        return;
> 
> 
>> +
>> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
>> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);
> 
> How will you detect a migration is needed? Don't you need to first know
> if ->vsfile_pcpu is different to cpuid_to_hartid(v->processor)? (I
> didn't take a look to other patchs for the moment, so the
> explanations might be later.)
> 

Migration (if you are speaking about migration of vCPU from one pCPU to 
another) is completely different path. Look at sched_move_irqs().

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:34:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:34:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389644.1630289 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRpm-0006cg-KD; Thu, 13 Aug 2026 09:34:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389644.1630289; Thu, 13 Aug 2026 09:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRpm-0006cZ-HV; Thu, 13 Aug 2026 09:34:46 +0000
Received: by outflank-mailman (input) for mailman id 1389644;
 Thu, 13 Aug 2026 09:34:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRpm-0006bS-2T
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:34:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRpl-009juZ-FZ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:34:45 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa7951ae000c4f3@swg.vates.tech>)
 id 6a7d8fb5-8faa-0a2a0a5109dd-0a2a4503a7a6-0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:34:45 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa7951ae000c4f3@swg.vates.tech>)
 id 6a7d8fb5-fae8-0a2a45030019-b9ff1c23a159-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:34:45 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ffa7951ae000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 13 Aug 2026 09:34:42 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id CD5FD837F9;
 Thu, 13 Aug 2026 11:34:41 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=GskiaxqdkrlcdOiUXu6b1xpI2QLiQHgPglgAiJ59n8k=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=QHJ21ilA3WoRB5qAKBZl96GlK8TpfZ+vXXaIE28/o2/iIXNEUiY8G6HUAT5K9emnr3UotLcEq
 wnJP0Z3e0+K0XtMk2bu7LJvx17wtFh36b83bBuGBrB4NWfX17NwV2klKKI/GH3HpoaEPcf7qXHe
 PLODwMX4YNAuikjuuKRPsxt7L8WdUxjFY/gH5TDqqi3Ie/usthOL7Z3udyzz3K8DGTApfI7Kvf0
 WBmVP2NHM0EaR20oWLIqYu+Zz21norSX4hW0mkFlk4JZsfXdjKIYemTsahJxhPkQyQYcn1HVJ5u
 8r/ubuzz0gkefJVzJD4F3/TmIgNx3ho4mMB6mhusxr1A==
X-Zone-Loop: 0b054c96b9c8278cfaab841e6baf246e4f097528be57
x-campaign-type: default
x-transaction-id: 40c86708-0bbc-495f-841e-fc42a0246376
x-swg-uid: 01-822a02e5-2575-49b2-9dc3-78e987e429b0
X-Mailer: Sweego
Message-ID:
 <1786613682.8631fc262581453bbf619ec5b2062170.19ffa7951ae000c4f3@vates.tech>
x-swg-bid: 1786613682.8631fc262581453bbf619ec5b2062170.19ffa7951ae000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 09/17] xen/riscv: add helper to check APLIC MSI mode
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <c6c5b05886520586041ca4f50ae554c3536ee662.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <c6c5b05886520586041ca4f50ae554c3536ee662.1784560663.git.oleksii.kurochko@gmail.com>
Date: Thu, 13 Aug 2026 11:34:35 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786613681; l=958;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=PVXSiJS+OyVYMIfE0rv3jMxdorfOOnHJHGgntD5zt2U=;
 b=I8965h4JAnoA3pBmQXbFhS01naEAW8hQ+pJT2MI8ITTSPmmTu205oLxxJ5TaZavk03405k8Jk
 pWXucQp4e0zC1ZTxkELMyViId9txSuRiqi4OcUDZMliXYOSkP+3hzZx
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786613682145
X-purgate-ID: tlsNG-33051d/1786613685-6ECCB4E9-5A08A62E/10/73395122804
X-purgate-type: spam
X-purgate-size: 958

> This helper can be used outside aplic.c to determine whether MSI mode
> is enabled. A follow-up patch uses it to decide whether the guest
> IMSIC state should be saved/restored.


> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>
> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
> index 87f2134bc5..1ce844cd21 100644
> --- a/xen/arch/riscv/aplic.c
> +++ b/xen/arch/riscv/aplic.c
> @@ -93,6 +93,11 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value)
>      spin_unlock_irqrestore(&aplic.lock, flags);
>  }
>  
> +bool has_msi_support(void)

It does a readl() of the physical APLIC on every call. Patch 11 puts it on
the vCPU context switch path (vaplic_state_save/restore), so this becomes an
uncached MMIO read per switch to read a value that aplic_init_hw_interrupts()
sets once and nothing ever changes. Please cache it at init
time.

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:41:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:41:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389658.1630298 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRw5-0000J8-E2; Thu, 13 Aug 2026 09:41:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389658.1630298; Thu, 13 Aug 2026 09:41:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRw5-0000J1-BR; Thu, 13 Aug 2026 09:41:17 +0000
Received: by outflank-mailman (input) for mailman id 1389658;
 Thu, 13 Aug 2026 09:41:16 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuRw4-0000Iv-1p
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:41:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRw3-000OVo-4G
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:41:15 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d912c-8faa-0a2a0a5109dd-0a2a45018372-42
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:41:14 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d9136-5984-0a2a45010019-d1558031b538-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:41:10 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49557167508so15610835e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:41:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4998216cf97sm48143745e9.14.2026.08.13.02.41.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:41:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786614070; x=1787218870; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=235ToJM7LQTx124aPcBAU/l2Xa19Gnprl8aR2ZpGdVM=;
        b=EAF52ZtixKhG2Xd+/xUCQcBFaZ5npMOxNFffZ9pbfiwK7KCSTl00ose37tAPGeIU/n
         JWFrt/rf3+HzK+jBcGqiBki5f4VSqJqo4W5ihM8VMOaUnN7XvE/jmfEiMddSyC8yDkGJ
         y2sWTx0EUQCi8S007AGd6ESBBYsvq/lU7BoE6fqv+LLnwzrwwwVr9d3MPhXrm8eWNRfQ
         AMI/SF5qO9i5e2wwwGsSZlr7LZhCkbvbkxLaFBpOpmdjb3Duw074ZpJmNWDE2ocwES5/
         bgAqm25i8E0AgzfnnAiiSWJ9wFy2Ql3ol7Mfv0OHzeJgGCGZxDH971POGznTP9bF5lna
         TnzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786614070; x=1787218870;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=235ToJM7LQTx124aPcBAU/l2Xa19Gnprl8aR2ZpGdVM=;
        b=FheIBCv0YuIS201PWHqP/WsZhtNwLAYuo7JhGHoudLDBOd1aarEEsLvaPvbgaM0OpG
         oL+DVyYp7t+ZdCNN+GsqAu5j7teH/E+QtkoavyOVCre//d0ZeEcpYVHSwoCEKOV3yCYF
         +jdKEdv9I8IJpeMcOapgSTpwq8Vxh4mtLGpRKNjbchKLXxMZWwpDCzrGzbJ7VVs/Xue8
         pIP5pL3swF3Eccisid1Z++cuhiE+b56m9FzW7i9OSSzHeI+ljU34SdJZhZifJ2l0ymsR
         0a1ane6SzPeK/nMADqzyiicdz6eZLLkVxI/BM8Tl16iCK3WEOCNdsICLfWYiaiptiFWO
         qVSw==
X-Forwarded-Encrypted: i=1; AHgh+Rquujw/GvjtXetxdzoQlFzHAYORtIEgedYwKlNkteoANEC0eV0DHv2sqgD8jJXjMh9nyNjr/+jQFHo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw73LFuS/nx25WXfOz1K1UtMzm/6l48PomCaYY3CLpyVxKzh1/j
	2lbOJ8mrdtKtiYZ5C8XvMKSgJgWGiEupo8jwO0hskjC8PP0yH0XbWJ6PWc1RW5Ui+g==
X-Gm-Gg: AR+sD13pIbst+rSfU08gfFWS3uX1hWxvHLOpXnCJtOHdioYDLYYn39bfXW9NhW9zw2m
	cZ9cDWC+DKlA2WGTPzsL1seJhc4RMMpC+dlsCDni1vgHDzcEAASm5eo1wbk1YKbIjf+b4Dz6vCk
	N/zyEqL6w2gLcRqjQIq3vnpthKkrFjHc5zufgjcosvHc9jaXlBdgnSDbOdZYjKkCoyPNDoX2o+C
	hXiRS/ZpmDwGdRgt0dggjt1eHbEHFLdpSu8NE+i4j6l7r9iNY6uSS7DCOFxQlTSY4mSinWYBcyJ
	kABXFkecVaCJOl6mpoU/YoVwzvfEIA/UhprgPzmi4ORxct5YE2y1KzH5zxvQnw8xZYJOQPqrIN8
	doj4l89KlyQWf9Cd4CB2Hlsds4+jvQBvYlOIfedHO+D14KCebIhLCSbDgpwGf1IfhCGESrKdkXa
	zPJyWoXdXwVL4bRnOKfF1p0J9LXId1XRd81b8JKKuGFBX66Kg22VR2F5P5UcSI1TZvoneLQqIWr
	faVqvKD6M7KAVRo5qkpwceTtC9EiYt7YLBJkFoRnQJCCzmlRktW
X-Received: by 2002:a05:600c:8183:b0:499:50ec:a3fd with SMTP id 5b1f17b1804b1-4998220bca2mr52593085e9.19.1786614069907;
        Thu, 13 Aug 2026 02:41:09 -0700 (PDT)
Message-ID: <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
Date: Thu, 13 Aug 2026 11:41:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Frediano Ziglio <freddy77@gmail.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>,
 "Daniel P . Smith" <dpsmith@apertussolutions.com>,
 xen-devel@lists.xenproject.org
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260810103018.54564-8-frediano.ziglio@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786614070-1D272757-6E735CB5/0/0
X-purgate-type: clean
X-purgate-size: 10614

On 10.08.2026 12:30, Frediano Ziglio wrote:
> Add a sub hypercall to __HYPERVISOR_memory_op to allow to read/write
> memory from/to a foreign domain.
> 
> Extending MMUEXT_COPY_PAGE seems better on first sight but considering
> that MMUEXT is meant for PV only and trying to change that sub-op this
> solution is better.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

First: Can you please update your recipient list before sending a new version?
Roger's move pre-dates this submission by quite a few days.

Then: The asymmetry of the new sub-op also continues to have no justification
at all. If you insist on not using two (domid,list-of-gfns) tuples to describe
the buffers, despite multiple maintainers having asked you to do so, please
put down a word explaining that decision.

> ---
>  xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
>  xen/include/public/memory.h |  45 ++++++++++-
>  xen/include/xsm/dummy.h     |  14 ++++
>  xen/include/xsm/hooks.h     |   2 +
>  xen/xsm/flask/hooks.c       |  10 +++
>  5 files changed, 219 insertions(+), 1 deletion(-)

As before: If you insist on not implementing the compat case, that decision
wants justifying in the description. Without that it'll look like an
oversight.

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1548,6 +1548,141 @@ static int acquire_resource(
>      return rc;
>  }
>  
> +/*
> + * The "noinline" qualifier avoids the compiler to create a large function
> + * consuming quite a lot of stack.
> + */
> +static int noinline mem_foreigncopy(

I'm wondering: Is the "mem" prefix really meaningful for a static function in
a file named memory.c?

> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
> +{
> +    struct domain *d, *const currd = current->domain;

With the comment on the new XSM hooks (below) in mind: currd wants to be
pointer-to-const.

> +    xen_foreigncopy_t copy;
> +    int rc, direction;

Plain int for rc is fine of course, but direction can't go negative, can it?

> +    if ( copy_from_guest(&copy, arg, 1) )
> +        return -EFAULT;
> +
> +    if ( copy.flags & ~XENMEM_foreigncopy_direction )
> +        return -EINVAL;
> +
> +    direction = copy.flags & XENMEM_foreigncopy_direction;
> +
> +    d = rcu_lock_domain_by_any_id(copy.domid);
> +    if ( !d )
> +        return -ESRCH;
> +
> +    /*
> +     * Check we are allowed to map and access these foreign pages.
> +     */

This really means to be a single-line comment.

> +    if ( direction == XENMEM_foreigncopy_from )
> +        rc = xsm_foreigncopy_from(XSM_TARGET, currd, d);
> +    else
> +        rc = xsm_foreigncopy_to(XSM_TARGET, currd, d);
> +    if ( rc )
> +        goto out;
> +
> +    while ( copy.nr_frames )
> +    {
> +        /*
> +         * Arbitrary size.  Not too much stack space, and a reasonable stride
> +         * for continuation checks.
> +         */
> +        xen_pfn_t gfn_list[32];
> +        unsigned int todo = MIN(ARRAY_SIZE(gfn_list), copy.nr_frames);
> +
> +        rc = -EFAULT;
> +        if ( copy_from_guest(gfn_list, copy.frame_list, todo) )
> +            goto out;
> +
> +        for ( unsigned int i = 0; i < todo; i++ )
> +        {
> +            struct page_info *foreign_page;
> +            mfn_t foreign_mfn;
> +            void *foreign;
> +            p2m_type_t p2mt;
> +            p2m_query_t q = (direction == XENMEM_foreigncopy_to) ?
> +                            P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
> +
> +            foreign_page = get_page_from_gfn(d, gfn_list[i], &p2mt, q);

Is there a reason check_get_page_from_gfn() can't or shouldn't be used here?
That would then also make this code properly deal with shared pages, and
refuse use against MMIO ones.

> +            if ( unlikely(p2m_is_paged(p2mt)) )
> +            {
> +                if ( foreign_page )
> +                    put_page(foreign_page);
> +                p2m_mem_paging_populate(d, _gfn(gfn_list[i]));
> +                p2mt = p2m_ram_paging_in;
> +                foreign_page = NULL;
> +            }
> +
> +            if ( unlikely(!foreign_page) )
> +            {
> +                rc = -ENOENT;
> +                if ( p2mt != p2m_ram_paging_in )
> +                {
> +                    gdprintk(XENLOG_WARNING,
> +                             "Error accessing foreign gfn %" PRI_gfn "\n",
> +                             gfn_list[i]);
> +                    rc = -EINVAL;
> +                }
> +                copy.nr_frames -= i;
> +                guest_handle_add_offset(copy.frame_list, i);
> +                goto out;
> +            }
> +
> +            foreign_mfn = page_to_mfn(foreign_page);
> +
> +            /* A page is dirtied when it's being copied to. */
> +            if ( direction == XENMEM_foreigncopy_to )
> +                paging_mark_dirty(d, foreign_mfn);

This may better be folded into the "else" below.

> +            foreign = map_domain_page(foreign_mfn);
> +            if ( direction == XENMEM_foreigncopy_from )
> +                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
> +            else
> +                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);

What I continue to be missing prior to this is the obtaining of a writable
page ref. That's, as previously said, imperative for PV guests and at the
very least advisable for HVM ones. (I really wonder how many more times I
need to comment on this.)

> +            unmap_domain_page(foreign);
> +            put_page(foreign_page);
> +
> +            if ( unlikely(rc) )
> +            {
> +                gdprintk(XENLOG_WARNING,
> +                         "Error %d copying gfn %" PRI_gfn "\n",
> +                         rc, gfn_list[i]);
> +                copy.nr_frames -= i;
> +                guest_handle_add_offset(copy.frame_list, i);
> +                goto out;

rc at this point holds the number of bytes which could not be copied. That's
not suitable as a return value from this function. (Strictly speaking this
is also an abuse of rc, as copy_{to,from}_*() return unsigned quantities.)

> +            }
> +
> +            guest_handle_add_offset(copy.buffer, PAGE_SIZE);
> +        }
> +
> +        copy.nr_frames -= todo;
> +        guest_handle_add_offset(copy.frame_list, todo);
> +
> +        if ( copy.nr_frames && hypercall_preempt_check() )
> +        {
> +            rc = hypercall_create_continuation(
> +                __HYPERVISOR_memory_op, "lh", XENMEM_foreigncopy, arg);

Nit: Indentation (the anchor point is the start of the function name, not
the start of the statement).

> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
>  typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>  
> -/* Next available subop number is 29 */
> +/*
> + * Copy memory from/to a given domain.
> + * This calls is meant to replace expensive operations during migration which

Nit: "This call is ..." However, is ...

> + * are only supported for PV guests.

... this entire sentence really worth to have here (it looks more like
something to have in the description)? For it to be possible to find if
someone considered using those "expensive operations", I think it would need
to be less vague and name those operations. Furthermore, if those other
operations were supported only for PV guests, how would migration work for
non-PV ones?

> + */
> +#define XENMEM_foreigncopy 29
> +struct xen_foreigncopy {
> +    /* IN - The domain whose memory is to be copied. */
> +    domid_t domid;
> +
> +    /* IN - Flags. */
> +#define XENMEM_foreigncopy_from 0
> +#define XENMEM_foreigncopy_to 1
> +#define XENMEM_foreigncopy_direction 1
> +    uint16_t flags;
> +
> +    /*
> +     * IN/OUT
> +     *
> +     * As an IN parameter number of frames of the domain to be copied.

I think there's a comma wanted after "parameter".

> +     * On output updated number of frames left (0 if success).

I further think that adding "to" after "updated" would help here.

> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -569,6 +569,20 @@ static XSM_INLINE int cf_check xsm_map_gmfn_foreign(
>      return xsm_default_action(action, d, t);
>  }
>  
> +static XSM_INLINE int cf_check xsm_foreigncopy_from(
> +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)

I think these and ...

> +{
> +    XSM_ASSERT_ACTION(XSM_TARGET);
> +    return xsm_default_action(action, d, t);
> +}
> +
> +static XSM_INLINE int cf_check xsm_foreigncopy_to(
> +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)

... want to be pointer-to-const right away, requiring to re-base over "XSM:
make Argo hooks well-formed ones" (or alternatively requiring to split out
the change there to xsm_default_action()). We really should avoid gaining
...

> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -58,6 +58,8 @@ XSM_HOOK(int, add_to_physmap, struct domain *, struct domain *)
>  XSM_HOOK(int, remove_from_physmap, struct domain *, struct domain *)
>  XSM_HOOK(int, map_gmfn_foreign, struct domain *, struct domain *)
>  XSM_HOOK(int, claim_pages, struct domain *)
> +XSM_HOOK(int, foreigncopy_from, struct domain *, struct domain *);
> +XSM_HOOK(int, foreigncopy_to, struct domain *, struct domain *);

... new hooks with non-const-correct parameters.

Further: Why two new hooks? See e.g. "XSM: fold xsm_{,un}map_domain_pirq()
hooks", "XSM: fold xsm_{,un}map_domain_irq() hooks", or "XSM: fold
xsm_{,un}bind_pt_irq() hooks": We'd like to reduce the number of hooks, to
reduce (when non-dummy XSM is in use) the number of cf_check entry points.

> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1368,6 +1368,16 @@ static int cf_check flask_map_gmfn_foreign(struct domain *d, struct domain *t)
>      return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
>  }
>  
> +static int cf_check flask_foreigncopy_from(struct domain *d, struct domain *t)
> +{
> +    return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ);
> +}
> +
> +static int cf_check flask_foreigncopy_to(struct domain *d, struct domain *t)
> +{
> +    return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);

Why both READ and WRITE?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:42:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:42:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389666.1630307 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRxC-0000oO-NO; Thu, 13 Aug 2026 09:42:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389666.1630307; Thu, 13 Aug 2026 09:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRxC-0000oH-KY; Thu, 13 Aug 2026 09:42:26 +0000
Received: by outflank-mailman (input) for mailman id 1389666;
 Thu, 13 Aug 2026 09:42:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRxB-0000nY-8U
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:42:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRx9-0065eb-2M
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:42:23 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d916b-e002-0a2a0a5209dd-0a2a450a95c0-34
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:42:22 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d917e-f2d2-0a2a450a0019-d155dd2edda7-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:42:22 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47f7854678cso1316647f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:42:22 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5b6f94sm4817483f8f.32.2026.08.13.02.42.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:42:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786614142; x=1787218942; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=CyOYrhfgrxIpzOCV2xKFjexz7vJ6XUTd9Ie2cmJb4Qc=;
        b=h+8kysbS11LOmCO2WY5JF37PeSu7ZuMdbmdbwQg1bBMf5XFOIXwEsmTh3psOVBuFjq
         yybbSDezbwSRHCIVYdTGkiKW2zwt2qji1k5nbg7IHeYWT7dtgcECZKeCcogDoLlrUn+i
         SqNCrBETfpXgYgXvAf2g78t2/84NCnlccAIvJu2CgQtRi2YtXk2e63sYItGv1JFEyZUu
         FDQFwrX1hCAfR3femH3pWuUpMvBpg2BgO5lc/+iEXVPrQzubK8JBcQlRnTznoJZjtlx3
         51gO40pWDkM4moxFA6wwCtZfVsls3eOYPzhrye8BWlPwyARDJImWp2szdjlC+e8cVhBi
         w33w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786614142; x=1787218942;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=CyOYrhfgrxIpzOCV2xKFjexz7vJ6XUTd9Ie2cmJb4Qc=;
        b=MisFoQ5gPDBfViqvRepVkXL/ylAaiEQgv+BluAlV4af3OflFQw4WgYMup2EvNKXsTy
         Zfb7qLT/Ef19ce2U6WbbIxcIWe0AsYEgsvQRDWF5XyHuEfDmngVwCJXUzoZsATSpilFG
         Ht/r12z0N04t+kOqmj7LpC3VMVVi+zo0BEwE9nlZq8cswvfsPDgXTaZSAhs5hXjYbY5H
         HfJBm2YO+Ff9BVAMoLUsXADMMrd9j8aSY0hhzOBwMG4BgjonjlMmOpjpOeSP85HqpXYd
         EpoP1bcIf542UEa7MDVH18bvQW5yw3dOKi7jV2vqGowHzpvIW0JYx03XpP3P3BqxzCLC
         yVEw==
X-Gm-Message-State: AOJu0YwRQMw4+ku2hytaH/pP4nzDea05zR2YU12Jw6r2NIL5DZYAOCHO
	b6HeaV0Bygnwbf8pigYBymCXqd/Rus2HzXwWTI5k93JeHCaZNZLy/oEqq2oNQw==
X-Gm-Gg: AR+sD121ygVoEF+7WQ5CT57hcLywm+3InrIW1SE/ZeicHRYoxYmKX+KILiGX/WDDC+P
	lsYl1F22G/PzT/U85SR0a/anRX5vTGD5TPkm0ZWwRf7XsYfVlHUGZyrQi8j5v86L4jOz6xS8g9j
	tFSHGEyDCQX8qJF0AvE6VhVP/Zj3thihWtSSNxj1nA6NRy0MPn4oY8WA2+LxwtRTqVDrbs/gUrt
	qKwwWxyI3eOMLUFINupIw8qz3J+OpfCVN5dl6Kc70onKC9XMncrSwTU0BH200bHYAg4bLl823cC
	CN3bDcDY5Pzut9VTmJOGtI7Ow03tpoBGBIvZtKwHm9ODftymjglaxPyJxEoCH/PNoxSSwkqkgUC
	bYvOKjsXwhwz6GcmxX784DT2kdHGurcImhIqx+tuMyhsJi0RLeGHd3GNcYwzm5lkGkxXwn+5f19
	caVO8uM3pGbbY/EOYTsM9C0E26P6doXfi//Q7x9qhjGYxmKT4X5a0La/PXTnua+dZcfvkNTh8T5
	kmiFctmrvrpG1juvhkNVZqm54L/3sgn+M22rKRQ6sM=
X-Received: by 2002:a05:6000:25fa:b0:47f:8810:cc64 with SMTP id ffacd0b85a97d-48159fe3f70mr6788744f8f.19.1786614141465;
        Thu, 13 Aug 2026 02:42:21 -0700 (PDT)
Message-ID: <5ea1202d-7635-46f7-8238-e3d54b588afd@gmail.com>
Date: Thu, 13 Aug 2026 11:42:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786612004.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786612004.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786614142-524DFCFC-DF2C9FC8/10/73395122804
X-purgate-type: spam
X-purgate-size: 4972



On 8/13/26 11:06 AM, Baptiste Le Duc wrote:
>> 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 <oleksii.kurochko@gmail.com>
> 
> 
>>
>> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
>> index ffce77209c..c5ae74e456 100644
>> --- a/xen/arch/riscv/imsic.c
>> +++ b/xen/arch/riscv/imsic.c
>> @@ -25,7 +25,9 @@
>>   #include <xen/spinlock.h>
>>   #include <xen/xvmalloc.h>
>>   
>> +#include <asm/aia.h>
>>   #include <asm/imsic.h>
>> +#include <asm/p2m.h>
>>   
>>   #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ)
>>   
>> @@ -342,6 +344,67 @@ static int __init imsic_parse_node(const struct dt_device_node *node,
>>       return 0;
>>   }
>>   
>> +/*
>> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU v
> Nit: What is this `v`?

A function argument. But I will just drop v from the comment.

>> + * 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 block,
>> + * 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 hart.
>> + *
>> + * Xen pins each vCPU to a pCPU (v->processor) and assigns it a physical
> 
> 
>> + * guest file index (guest_file_id) from the vGEIN allocator. A guest_file_id
>> + * of 0 indicates that no hardware guest file is selected (matching the
>> + * architectural behavior where vGEIN = 0 in the hstatus CSR selects no
>> + * guest external interrupt source), requiring the VS-file to be emulated
>> + * in software.
>> + *
>> + * 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 current pCPU.
>> + */
>> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>> +{
>> +    int res = 0;
>> +    struct domain *d = v->domain;
>> +    unsigned int cpu = v->processor;
>> +    vaddr_t gaddr = imsic_cfg.base_addr + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);
> 
> The variable holds a guest-physical address, so vaddr_t is the wrong
> type should be either paddr_t or gaddr_t.

Agree, paddr_t will be better what was mentioned in thread with Jan B.

> 
>> +    paddr_t paddr;
>> +    unsigned long guest_stride;
>> +
>> +    /* Nothing to map in the case of sw interrupt file. */
> 
> There is no software interrupt file implementation in this series, patch 11
> turns the non-MSI path into a BUG_ON(). So "vsfile_id == 0" today means "this
> vCPU gets no external interrupts at all and nothing tells anybody". Worth
> saying so plainly here rather than implying a fallback exists.

I would ask then different question will this function change when IMSIC 
interrupt file support will be added? I think - no as in the case of 
IMSIC interrupt file we don't need any stage-2 mapping. So here it is 
just a check that nothing should be mapped for non-hw-assisted interrupt 
files.

> 
>> +    if ( !vsfile_id )
>> +        return res;
>> +
>> +    guest_stride = vsfile_id * IMSIC_MMIO_PAGE_SZ;
> 
> 
>> +
>> +    paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset +
>> +            guest_stride;
> 
> 
>> +
>> +#ifdef IMSIC_DEBUG
> 
>> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
>> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
>> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
>> +#endif
>> +
>> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
>> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
>> +                           arch_dt_passthrough_p2m_type());
>> +    if ( res )
>> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",
> 
> Maybe a use of dprintk() would be more appropriate?
> 
Agree, dprintk() will be better.

Thanks.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:43:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:43:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389674.1630317 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRxl-0001GN-UQ; Thu, 13 Aug 2026 09:43:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389674.1630317; Thu, 13 Aug 2026 09:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuRxl-0001GG-Rl; Thu, 13 Aug 2026 09:43:01 +0000
Received: by outflank-mailman (input) for mailman id 1389674;
 Thu, 13 Aug 2026 09:43:00 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuRxk-0001G2-AY
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:43:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuRxj-008wub-Ms
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:42:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@swg.vates.tech>)
 id 6a7d9196-8faa-0a2a0a5109dd-0a2a4507b010-42
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:42:59 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@swg.vates.tech>)
 id 6a7d91a3-b4ea-0a2a45070019-b9ff1c239a29-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:42:59 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ffa80d28a000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 13 Aug 2026 09:42:54 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 836E28220A;
 Thu, 13 Aug 2026 11:42:53 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=h/ypzQ1qRuJcef4sANwVi/+OW7XxeGhQlNwQty2cXgI=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=Wb5N1H06JLVo/+5W0op7qTtJVpzAEMLMon3RlWe3u+KYFFRoCxkCQz+tv621DLq8Rh46E4SBj
 zm2qqVKIDzKLi+oKgtLtV1qZ+ZQXHiQkySALk1ofzv2opVzSVQuQcDC67goyhn8aIbJBF+b8Tl1
 7PISXN24rWXl17RKnq6LqMirnnN/p5EXHI7caZkByOQptejrX93a5EWUQUvl3npmzAdRWqOTkWR
 qGvfNgmtI6Y6BGb/TR3a8YIKci7JB2bSq4gM5maf4rSCngLTUXEnBaKVAdSUkGsZQ1MmO7lP8z6
 FNalSDdBEZ9CUa1Cz3MGt09B/tNl+GS2rUhoxbOLDlSg==
X-Zone-Loop: fed377fdb2487f537e17ef7d1851f97f560eb6d9c239
x-campaign-type: default
x-transaction-id: 1e9f8f56-0e76-4e9a-a834-3d2d358783b8
x-swg-uid: 01-31e80262-3334-409d-98d9-4d05d87c0cad
X-Mailer: Sweego
Message-ID:
 <1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@vates.tech>
x-swg-bid: 1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 10/17] xen/riscv: introduce
 vintc_state_{save,restore}()
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
Date: Thu, 13 Aug 2026 11:42:46 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786614173; l=2526;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=GhgZ6vMvKdO+oq9Y1BEW1KDxH9FfRP6JyD9r8UfhwKE=;
 b=JF+Mi+akL0r5vWZGOugPSCRKxozTpmeUgqrR9X7/zfdWQjVZHpwEel0RrF/hpu2H8mUplTM0C
 hbXVg3bNjl9CC4zfZuyM0VzRwMbxUZXqvoOXUWbE9ThDGeElVW/AJyd
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786614173842
X-purgate-ID: tlsNG-ef75cf/1786614179-376D2AE4-5AD7CC58/10/73395122804
X-purgate-type: spam
X-purgate-size: 2526

> Virtual interrupt controller state must be preserved across vCPU context
> switches: for AIA, a vCPU's guest interrupt file lives in the IMSIC of
> the pCPU it runs on, so the related state has to be saved when the vCPU
> is descheduled and re-established when it is scheduled again.
> 
> Introduce vintc_state_save()/vintc_state_restore() wrappers around new
> store_state()/restore_state() hooks in struct vintc_ops, so that the
> context switch path can save/restore this state without knowing which
> vINTC variant a domain uses.


> 
> No callers are wired up yet: the vAPLIC implementation of the hooks is


> added by the follow-up patch, and the calls from the context switch path
> will be introduced together with vCPU context switch support.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>
> diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
> index 2ee5d1533c..f4f0ce365c 100644
> --- a/xen/arch/riscv/include/asm/intc.h
> +++ b/xen/arch/riscv/include/asm/intc.h
> @@ -64,6 +64,12 @@ struct vintc_ops {
>  
>      /* Deinitialize some vINTC-related stuff for a vCPU */
>      void (*vcpu_deinit)(struct vcpu *v);
> +
> +    /* Store virtual interrupt controller state */
> +    void (*store_state)(struct vcpu *v);
> +
> +    /* Restore virtual interrupt controller state */
> +    void (*restore_state)(struct vcpu *v);
>  };


>  
>  struct vintc {
> @@ -91,4 +97,7 @@ void domain_vintc_deinit(struct domain *d);
>  
>  bool vintc_reserve_virq(const struct domain *d, unsigned int virq);
>  
> +void vintc_state_save(struct vcpu *vcpu);


> +void vintc_state_restore(struct vcpu *vcpu);


> +
>  #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
> index 372c8d3a20..879d513374 100644
> --- a/xen/arch/riscv/intc.c
> +++ b/xen/arch/riscv/intc.c
> @@ -163,3 +163,17 @@ bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
>  
>      return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
>  }
> +
> +void vintc_state_save(struct vcpu *vcpu)
> +{
> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
Is there a situation where ops could be NULL? If yes, add a check.
> +
> +    ops->store_state(vcpu);
> +}
> +
> +void vintc_state_restore(struct vcpu *vcpu)
> +{
> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
Same as above

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:50:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:50:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389685.1630327 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuS4Z-0002cZ-Q3; Thu, 13 Aug 2026 09:50:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389685.1630327; Thu, 13 Aug 2026 09:50:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuS4Z-0002c6-LT; Thu, 13 Aug 2026 09:50:03 +0000
Received: by outflank-mailman (input) for mailman id 1389685;
 Thu, 13 Aug 2026 09:50:02 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuS4Y-0002Ej-ED
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:50:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuS4X-00CbGr-EW
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:50:01 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa87495f000c4f3@swg.vates.tech>)
 id 6a7d933f-e002-0a2a0a5209dd-0a2a4502b2c4-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:50:01 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.19ffa87495f000c4f3@swg.vates.tech>)
 id 6a7d9349-6ca4-0a2a45020019-b9ff1c239e5f-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:50:01 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 19ffa87495f000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 13 Aug 2026 09:49:57 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 2089B80272;
 Thu, 13 Aug 2026 11:49:57 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=NPqZPX6/ZqPWIGR3WctQKZt5kCZfDYrnw4Tq7Z4I7J0=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=IHaaPEpwmtub9ej4gdnnVcGlFfy03hajeSqa8x/KslKYIGBEb4cMxeNCvCdJeh9U2/TW7a+Pb
 DOULLUjktRE34TYoq7GeZXAtHhH5T0tD9RYmGYpU/wXcjjybF4Xijeyd7LkcVnjHis7HYKt/dx9
 AMmaDkmUq045/obsL5tTPreqixdf6B8Rkk0Jl23EFg7xgkofMVSUPquShPoZ68NqR5rdxXVyy2d
 LYC4+tH3FXZivE8Rcg638ce5YiycH6YvmxXKUgnY2ZXqxT4f6OKTy39AIghJpyIL9qbYsck/Wev
 5wzsC2m/F0xNHYqP7B1Rv2w+X7VpyoRD9ubHarQJfPJg==
X-Zone-Loop: a870f0d987d863c2df42a265577ec54076a38534070c
x-campaign-type: default
x-transaction-id: d5dd0a3f-ac19-4824-88cc-1fdddf2da98b
x-swg-uid: 01-5b564f3a-9c35-4972-a9e9-7d19f14c3f4a
X-Mailer: Sweego
Message-ID:
 <1786614598.8631fc262581453bbf619ec5b2062170.19ffa87495f000c4f3@vates.tech>
x-swg-bid: 1786614598.8631fc262581453bbf619ec5b2062170.19ffa87495f000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <5ea1202d-7635-46f7-8238-e3d54b588afd@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786612004.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@vates.tech>
 <5ea1202d-7635-46f7-8238-e3d54b588afd@gmail.com>
Date: Thu, 13 Aug 2026 11:49:51 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786614597; l=5411;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=MIDT3TxqJ+iHOmwxSTp6i9jHP/P7WauNQOtPNS2v7dw=;
 b=aKMzpNzXKSg2aq8NgQIplIYBgPiNO6OLZ3IEJTCfCkGDXGoetxva+f9diYjWtEfQhccWUsqU+
 k9pcmIXwAvsAq1FCJOGW54XTC8iogX7coFoCjDzAk35RicFbb/imFuE
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786614597434
X-purgate-ID: tlsNG-720697/1786614601-F2EB32AC-BF15E589/10/73395122804
X-purgate-type: spam
X-purgate-size: 5415

On 2026-08-13 11:42 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/13/26 11:06 AM, Baptiste Le Duc wrote:
> >> 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 <oleksii.kurochko@gmail.com>
> > 
> > 
> >>
> >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
> >> index ffce77209c..c5ae74e456 100644
> >> --- a/xen/arch/riscv/imsic.c
> >> +++ b/xen/arch/riscv/imsic.c
> >> @@ -25,7 +25,9 @@
> >>   #include <xen/spinlock.h>
> >>   #include <xen/xvmalloc.h>
> >>   
> >> +#include <asm/aia.h>
> >>   #include <asm/imsic.h>
> >> +#include <asm/p2m.h>
> >>   
> >>   #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ)
> >>   
> >> @@ -342,6 +344,67 @@ static int __init imsic_parse_node(const struct dt_device_node *node,
> >>       return 0;
> >>   }
> >>   
> >> +/*
> >> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU v
> > Nit: What is this `v`?
> 
> A function argument. But I will just drop v from the comment.
> 
> >> + * 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 block,
> >> + * 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 hart.
> >> + *
> >> + * Xen pins each vCPU to a pCPU (v->processor) and assigns it a physical
> > 
> > 
> >> + * guest file index (guest_file_id) from the vGEIN allocator. A guest_file_id
> >> + * of 0 indicates that no hardware guest file is selected (matching the
> >> + * architectural behavior where vGEIN = 0 in the hstatus CSR selects no
> >> + * guest external interrupt source), requiring the VS-file to be emulated
> >> + * in software.
> >> + *
> >> + * 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 current pCPU.
> >> + */
> >> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
> >> +{
> >> +    int res = 0;
> >> +    struct domain *d = v->domain;
> >> +    unsigned int cpu = v->processor;
> >> +    vaddr_t gaddr = imsic_cfg.base_addr + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);
> > 
> > The variable holds a guest-physical address, so vaddr_t is the wrong
> > type should be either paddr_t or gaddr_t.
> 
> Agree, paddr_t will be better what was mentioned in thread with Jan B.
> 
> > 
> >> +    paddr_t paddr;
> >> +    unsigned long guest_stride;
> >> +
> >> +    /* Nothing to map in the case of sw interrupt file. */
> > 
> > There is no software interrupt file implementation in this series, patch 11
> > turns the non-MSI path into a BUG_ON(). So "vsfile_id == 0" today means "this
> > vCPU gets no external interrupts at all and nothing tells anybody". Worth
> > saying so plainly here rather than implying a fallback exists.
> 
> I would ask then different question will this function change when IMSIC 
> interrupt file support will be added? I think - no as in the case of 
Did you forget s/w word? If not it's weird as IMSIC interrupt file is
the current topic of this patch series.
> IMSIC interrupt file we don't need any stage-2 mapping. So here it is 
here too.
> just a check that nothing should be mapped for non-hw-assisted interrupt 
> files.
> 
> > 
> >> +    if ( !vsfile_id )
> >> +        return res;
> >> +
> >> +    guest_stride = vsfile_id * IMSIC_MMIO_PAGE_SZ;
> > 
> > 
> >> +
> >> +    paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset +
> >> +            guest_stride;
> > 
> > 
> >> +
> >> +#ifdef IMSIC_DEBUG
> > 
> >> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
> >> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
> >> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
> >> +#endif
> >> +
> >> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
> >> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
> >> +                           arch_dt_passthrough_p2m_type());
> >> +    if ( res )
> >> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",
> > 
> > Maybe a use of dprintk() would be more appropriate?
> > 
> Agree, dprintk() will be better.
> 
> Thanks.
> 
> ~ Oleksii
> 
> 
> 




From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:50:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:50:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389692.1630334 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuS5H-0003gq-Vz; Thu, 13 Aug 2026 09:50:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389692.1630334; Thu, 13 Aug 2026 09:50:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuS5H-0003gj-TU; Thu, 13 Aug 2026 09:50:47 +0000
Received: by outflank-mailman (input) for mailman id 1389692;
 Thu, 13 Aug 2026 09:50:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuS5G-0003gX-Lh
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:50:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuS5G-009muO-1r
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:50:46 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d9369-8faa-0a2a0a5109dd-0a2a4501db02-38
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:50:45 +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 <jbeulich@suse.com>)
 id 6a7d92c1-5984-0a2a45010019-d1558034d1b0-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:47:45 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so4956365e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:47:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981b1bd61sm49932925e9.8.2026.08.13.02.47.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:47:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786614465; x=1787219265; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=rnYMFDlAdA0MjjYhLDJNo9oUGcqFZKY+VX+ctoUp8Gc=;
        b=RupJz0muy4NktoqsnsQ60P3rGSLrpd3UiqFihAsA51YpMwQNzaXTQQ6O2mYwKnxeDH
         YkoPq3MJCQI9CC+FspgXZCC2wxq3FLCmvGf2Kpzn0Km+UBThPTEGc1YEgmpkFrrTyXPt
         fmFPhTu/kFH0iScopkz+XU5UT2mLycUEjexTdTpcMk+0NJxmSQi2OoxGcxiQEhohMAER
         eiO22xMPxUH01OgR1F/ClqnWQ68f8XyxTBgVROMk/QlIXL8mvj8pWro9DUYhLs1PlL+T
         0Pz3HKzgYC9ErDXr01gN+KeBESkjdXxpysDwGoJUuhqNK19dxtr8p4hxSMmH9RXJmom/
         i9BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786614465; x=1787219265;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=rnYMFDlAdA0MjjYhLDJNo9oUGcqFZKY+VX+ctoUp8Gc=;
        b=aiBQt7jYxW/3mJYpb4EHxs9aJ3fHMPiyowX/Stm2T/bw6SEcIuLkBbJMO32/xHGW7s
         OmsqlF5ceB5LE/RzvTTQSgqtwz+RmV2IMS4UNIUZ7Vy8xVJvk+iTSl22my3mxK9mqkq/
         DEDQJdGsweVrlKhJkRe2vthhkKr3bTEOCTbOpAuC2Itz0MzqkurdbKhG5U0NiXiVT0q4
         mU9XejZlCGzi3qxSaR2sHjJsBmjDnqoqnasyeYhm1zROokPkmVmnxjtFUuvXmNvWCLPq
         7H+1to2zF7tBtxCNJF+rMosiQQUSdK3Y6oAaISrMPVb4A8KiJ2OsEUG95Odcc5ls/lU/
         fNKg==
X-Gm-Message-State: AOJu0Yw4ut0XVRNDVMIcVF8imKAOoDarcu/MZcmu8jEl6cPilZDNLvmi
	nhierW+gih6h2pSuThnIYwZHkyKWaM3fV7pf4J9VLlgHFGzOQQthHCdW0fkcuhX4IQ==
X-Gm-Gg: AR+sD133YnMbx2Jcm+KVx35qPdJovSMKfG4QHh8KLFk/xS8ycU3BZzTnFJQZFIhDus2
	g54oNNFZi7vWoIaZ2SycjLGn9u1pjlhxZVjTp+Rkw75S+llzGzYLQb8qUyq7/GWN8ZlVe5N0bdA
	+FzVbsGX4pvUxQyI1YP5baVoV6541Wg3i0H01HE835UGhEpJ7TNQ/AGAM55skoCeaGxXDPE/K12
	ry16SdDmaZlxph8KWiiQrmEerEDCVUR0crfjsFrEnHtav/acBXQBtCItGOy0BzZHWvQTrShKuaC
	rtTZl77PDGak89zR1oEyM5/Y6aGzaYFFgI2kLB3Wm6WrENE9CeGBc73oYqqbN7Bvjsa9rR073Nn
	vKukICUm38VPXC3Lh2AulgHAXny852WXCJEBWidaTty9go/kaZKh7O0eThZ8OupUMLJnPlsBJCe
	VSieUmTGv1NAD6a4bHD/laQL8wVbOv+en3UI7kiuVoJLYvYTyreOpBhvwi9gKyg3sr5uh2i3cGb
	h/koE+7MG6h/+82O4W4mCV+NsQAy0tITRfcwI7RNobJ3a+EmOyK
X-Received: by 2002:a05:600c:8706:b0:499:5f7a:7ea2 with SMTP id 5b1f17b1804b1-49982185170mr60983185e9.12.1786614464862;
        Thu, 13 Aug 2026 02:47:44 -0700 (PDT)
Message-ID: <8273fde5-98b5-4b23-9f3b-9a7cc3749716@suse.com>
Date: Thu, 13 Aug 2026 11:47:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786614465-1F063757-D877F4E3/13/0
X-purgate-type: spam
X-purgate-size: 1649

On 13.08.2026 11:24, Baptiste Le Duc wrote:
>> --- a/xen/arch/riscv/aia.c
>> +++ b/xen/arch/riscv/aia.c
>> @@ -14,6 +14,7 @@
>>  #include <asm/cpufeature.h>
>>  #include <asm/csr.h>
>>  #include <asm/current.h>
>> +#include <asm/imsic.h>
>>  
>>  struct vgein_ctrl {
>>      unsigned long bmp;
>> @@ -36,6 +37,35 @@ bool aia_usable(void)
>>      return _aia_usable;
>>  }
>>  
>> +void vcpu_aia_init(struct vcpu *v)
>> +{
>> +    unsigned int new_vsfile_id;
>> +    int rc;
>> +
>> +    if ( !aia_usable() )
>> +        return;
>> +
>> +    new_vsfile_id = vgein_assign(v);
>> +
>> +    /*
>> +     * vgein_assign() returns 0 when no free h/w guest interrupt file is
>> +     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
>> +     * in that case.
>> +     */
>> +    rc = imsic_map_guest_file(v, new_vsfile_id);
>> +    if ( rc )
>> +    {
>> +        /* Can't continue w/o correctly mapped IMSIC interrupt file */
>> +        domain_crash(v->domain);
> 
> The vgein id assigned a few lines up is not released here. The domain is dying
> anyway, but the guest interrupt file stays marked in use on that pCPU forever,
> since nothing else ever calls vgein_release(). A vgein_release(v,
> new_vsfile_id) before the domain_crash() would fix it.

Instead of (or in addition to) doing that here, wouldn't releasing better be part
of the normal cleanup path? Whether "instead of" or "in addition to" depends on
the implications of deferring the release. But to guarantee no leak, domain
cleanup will want to either do the release, or have an explicit check that is was
done.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:51:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:51:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389695.1630344 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuS5Z-00042C-6X; Thu, 13 Aug 2026 09:51:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389695.1630344; Thu, 13 Aug 2026 09:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuS5Z-000422-3R; Thu, 13 Aug 2026 09:51:05 +0000
Received: by outflank-mailman (input) for mailman id 1389695;
 Thu, 13 Aug 2026 09:51:03 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuS5X-00040I-ME
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:51:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuS5X-009n1K-2r
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:51:03 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d9378-8faa-0a2a0a5109dd-0a2a4501e90a-28
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:51:03 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d9386-5984-0a2a45010019-d155802cd48d-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:51:02 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-49954b88fffso5731485e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:51:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4998216d082sm50735065e9.13.2026.08.13.02.51.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:51:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786614662; x=1787219462; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=M5OfhvD3pYYO8/RQB3SMAqSpCVkJqg0fNsO1T2bjuhk=;
        b=eIeisjF/ABKHV/XMkDkyc3o5UYndmvLeRILFG+lrWY2s91PPxjxrJuBYdUizj7TaLU
         cQvqkHV/XGn0PvllLa1NfBZbdYEcbwI9ekoYHBMf6bQjITIgZVieC2ZmDQtzv08AtTIV
         Qei48RIFAzIj7Ag84pOKXoKWIGO/0JRCmQ1Ch4/gspBmDUSYKUgS+YumD8hFAO6biceb
         SQm97RMSj99TCq5zLCnLr7KkIRzH0fLAvHOeTveThBsl+VYPJgYs+2NsuMJhN9dnRnVp
         Mm6uvjAnIWL29w50q8/po0v4QqGo3OcEFWfHHwkcbD2JDMCLkMJioR0uc6OSNQZ1b9wU
         t0/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786614662; x=1787219462;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=M5OfhvD3pYYO8/RQB3SMAqSpCVkJqg0fNsO1T2bjuhk=;
        b=dT07BGjOmHB2x1iBkQ3gOU0MjChM5bEeYyChyOgrO/wzctINKc41J9gLMhNO6AZWRD
         QkXNPVBVuSEBkW5ZaXSnkvkk1zu7DMWdaUCM+ILnGBsC3vjatud/uIw9XSQX/eZ8FQo5
         m/RqsJe4TiooOkjZAXFa+wwBu9UG58WZxAGhPKKhfHSqjJ/zw8VWg7DT5AFye8y3iRc9
         BUrjW8v0WUae0JmY4IFwRHJM7b2oA1sJKxZ7oiFih0GWMNIJw6yZ+xBCGMV0tD2EPAnx
         uhfS89XMRVgJa4uG92YywZCDvaLX6hJMNhEufLIyviXiaHGgvF+OiFtVbU3sv0dRb01p
         1FvQ==
X-Gm-Message-State: AOJu0YyHRdOhfmP5uHDJUUty0LNOSaQ7562x82XG7OOw/j9H4Z522iZX
	9Rf7af9SC24h/EPMMK6VY/wjrB9SQ8kGpsrG2/nljFV7Jy/xW0fOvtiFbd643q+OOA==
X-Gm-Gg: AR+sD13uty3reGMJ0ejCuzCWvm427HP4VLx8Wr82MlGd9WkKxqAwE6WoQIacnBxt9ly
	KNPXqoLWXNOHjsrsbUpsjSe+tLe7n6l8/2qXhKVsNXNB7w3Tc0OlONbJM9pp2Kvo2QiLRjvZZG1
	CTgsezdeR1rtc8oqNZ1atOXx/ONDRSC1WZbXkfGOMQ2o/szeDj14ghl6wB4TtLckL9EDRw2H/c2
	WvXIJvVYWqomNVnUGWW4+XQN0BRSf+ZKje+I0X/FrhGh3kblPZ3RABCuhf0CMN2MMhD/6+zdEOE
	vKeiU2tB4k333GiAGuhLyi14DIQG11pCCMMD0mmruhjD77TZdhfT/JatkR1XDA6hlWBaoyRrBY1
	AGdxWvSBwU6PLbtyfCeDrJJKoQVNavZ0LU31JJboBHA7+iE85nC7sF1ehHq4hW8cPDzNE2jyvuU
	lJOHyEFecbqhkLC2M/oY1j8OHVKU7UQzNY+3lIsVkFXL593qsjNQN5CAxlngID2jRv6ZAQfnIfo
	EpZFLzKDvshVZ/5EGe8N1B+PMKrVxYQK8v6aemAfDkTPiHfMPn5
X-Received: by 2002:a05:600c:1f8b:b0:499:81ae:1020 with SMTP id 5b1f17b1804b1-499821e7fa8mr49580415e9.11.1786614662417;
        Thu, 13 Aug 2026 02:51:02 -0700 (PDT)
Message-ID: <82011389-489e-4076-9d3a-8c393e4a8e76@suse.com>
Date: Thu, 13 Aug 2026 11:51:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
 <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786614662-BE27A757-E041E5D1/0/0
X-purgate-type: clean
X-purgate-size: 1688

On 13.08.2026 11:34, Oleksii Kurochko wrote:
> On 8/13/26 11:30 AM, Baptiste Le Duc wrote:
>>> --- a/xen/arch/riscv/imsic.c
>>> +++ b/xen/arch/riscv/imsic.c
>>> @@ -20,6 +20,7 @@
>>>   #include <xen/init.h>
>>>   #include <xen/libfdt/libfdt.h>
>>>   #include <xen/macros.h>
>>> +#include <xen/rwlock.h>
>>>   #include <xen/sched.h>
>>>   #include <xen/smp.h>
>>>   #include <xen/spinlock.h>
>>> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>>       return res;
>>>   }
>>>   
>>> +void imsic_state_save(struct vcpu *v)
>>> +{
>>> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
>>> +    unsigned long flags;
>>> +
>>> +    /*
>>> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
>>> +     * should be done in this case.
>>> +     */
>>> +    if ( !vcpu_guest_file_id(v) )
>>> +        return;
>>
>>
>>> +
>>> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
>>> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);
>>
>> How will you detect a migration is needed? Don't you need to first know
>> if ->vsfile_pcpu is different to cpuid_to_hartid(v->processor)? (I
>> didn't take a look to other patchs for the moment, so the
>> explanations might be later.)
> 
> Migration (if you are speaking about migration of vCPU from one pCPU to 
> another) is completely different path. Look at sched_move_irqs().

See how terminology is important. As said elsewhere, "save state" and
"restore state" don't make clear at all in which situation they're to be
used.

Also, can both of you please adjust Roger's email address when replying?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 09:57:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 09:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389708.1630353 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSBD-0004uY-Qy; Thu, 13 Aug 2026 09:56:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389708.1630353; Thu, 13 Aug 2026 09:56:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSBD-0004uQ-NA; Thu, 13 Aug 2026 09:56:55 +0000
Received: by outflank-mailman (input) for mailman id 1389708;
 Thu, 13 Aug 2026 09:56:54 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuSBB-0004uK-VT
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 09:56:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSBB-00Ccdy-Bh
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:56:53 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d94df-bab6-0a2a0a5309dd-0a2a45059082-18
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:56:53 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d94e5-4cb1-0a2a45050019-d155802ca445-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:56:53 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so7355035e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 02:56:53 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5af191sm5155864f8f.19.2026.08.13.02.56.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 02:56:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786615013; x=1787219813; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cwdb1JYdUGUcACicI7KC+FpkcuYvtYj8h89cYh8zen4=;
        b=IItf/1ltCqkvtqR4OPCwpBD3Iq3lhj2H9le8twDPphgfNcblk35Krp6vMe200nEe5q
         nTaxOfRtxR1xD+SVBEzqNA+3EMTyOw5Eu0ADIo93k6gW8SkfpyPP4up9uwc8I2zd9Yj3
         MeluqaBkuGUHPp6iEbiTQRF6G4t4e6yJ01cbY6AsvhbMUZVyZTTd+MwDkcnw4nyRJNIt
         teVimsRvegPYdmAP5PozpPuTvpeUjmvXnOi0llteQnWlAxERdvLcM/GMiNU2+vat69wX
         Cd0whK7DAA2xQ/fgepNM323pns0BwXS9G1uPCem7a0+VNM+Pb9E6LMpJvTOFV+A8Lp6e
         D8Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786615013; x=1787219813;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=cwdb1JYdUGUcACicI7KC+FpkcuYvtYj8h89cYh8zen4=;
        b=PQtU7V5Snydeig2MBqQN9iVjaNFNAw23j+f6vr0W3sgURWoA3JrEwrL7fifrcg2pUQ
         5w4zxtTpOQYPv5gw3hlG2lNpr+poI5xHZQUI6RoIOkirXQfUQ5j0pvFwckYZpN7ANo1s
         zTD9t0Go85wHCaSkglqE7HCFKh8yn4veu31ZXM4qkfbOrNYAcu+zdsCoBczUbTo3bNpM
         CKVJgHYBrCi2ksqJIhuCL7TEV1errs4R9oleLthhNrx3N/pfEEpv+ziz0MgwPO07Caih
         w2IhKHayeLE/niXK+z/79zzjmOMEVLZG1P5+wHTC3373R2ZH25RzOQ4zR/j/nhq48ZbF
         aSqQ==
X-Gm-Message-State: AOJu0YxlxBpVn+e83yY1LtjbtoGeSjTrIeqAGMEtPst9Bv0D6695b/CG
	N89c7Tt/Jf9noFbcibkCurEtm0WjUQge8Ki+hPEl9IfJnm8TdIucFH+7
X-Gm-Gg: AR+sD10WUCcJWBckqYVtvTPGF0KHGye+dyBsGplc+2TDxU/7MnjaeSujevNGZUreX0J
	02G4ZsCBo+1wLFXXSWGHQqrMJ3ZyhVW2Q+In8HMJ2XhkgnLG6zL9vY1o3oALuf4v64bJB0Hqev4
	MFEuRidHrWevBk2vp9aL+kWZkT1dHlVY9b/kH/Gi7yvZMKTGJLQR1YyRqQhY6UjamjzzPIfOEXB
	MlKtTmUr/N5Ij1LEl/TC7graNasrZMitty2TAwTfOnzAAnxVm97aouRJARhHlbqXQXRVUnCgIZy
	dnxLyEakzbFv1sC54HWFffbYGYb9qPfVydNcC4P/SJdlmFlcGM+puov019hVkJxo4nI+oS6oXvd
	wAbdiiGXql/VRMl4zKB/rlv+3yXmWKYIR+aJ5MPEGeaFJieFmgcKz4QufHTHfpCq+aFP0HAN0XX
	2UNc88Jfh67AOF2xDHBGkI9xOjauDcVHQTE+XvouZ9ptqDR6V8B4KNmfe2cQohEUQ0JJk+0ZMqw
	CJThFtyYL9JMXUoXAD7m96FvhjAeTPD2XNmoJbs9/0=
X-Received: by 2002:a05:600c:231a:b0:495:58fe:88e5 with SMTP id 5b1f17b1804b1-4998215464cmr42086965e9.2.1786615012684;
        Thu, 13 Aug 2026 02:56:52 -0700 (PDT)
Message-ID: <fb31ba29-14a3-434e-a3e8-ba4f5057b45c@gmail.com>
Date: Thu, 13 Aug 2026 11:56:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 06/17] xen/riscv: map IMSIC interrupt file for vCPUs
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <254f470ae2e2b2a4affa7c405be8c07a7d8b300e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786612004.8631fc262581453bbf619ec5b2062170.19ffa5fb46a000c4f3@vates.tech>
 <5ea1202d-7635-46f7-8238-e3d54b588afd@gmail.com>
 <1786614598.8631fc262581453bbf619ec5b2062170.19ffa87495f000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786614598.8631fc262581453bbf619ec5b2062170.19ffa87495f000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1786615013-F7EB92A1-2DDF0C1C/10/73395122804
X-purgate-type: spam
X-purgate-size: 4164



On 8/13/26 11:49 AM, Baptiste Le Duc wrote:
> On 2026-08-13 11:42 +0200, Oleksii Kurochko wrote:
>>>> +/*
>>>> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU v
>>> Nit: What is this `v`?
>>
>> A function argument. But I will just drop v from the comment.
>>
>>>> + * 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 block,
>>>> + * 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 hart.
>>>> + *
>>>> + * Xen pins each vCPU to a pCPU (v->processor) and assigns it a physical
>>>
>>>
>>>> + * guest file index (guest_file_id) from the vGEIN allocator. A guest_file_id
>>>> + * of 0 indicates that no hardware guest file is selected (matching the
>>>> + * architectural behavior where vGEIN = 0 in the hstatus CSR selects no
>>>> + * guest external interrupt source), requiring the VS-file to be emulated
>>>> + * in software.
>>>> + *
>>>> + * 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 current pCPU.
>>>> + */
>>>> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>>> +{
>>>> +    int res = 0;
>>>> +    struct domain *d = v->domain;
>>>> +    unsigned int cpu = v->processor;
>>>> +    vaddr_t gaddr = imsic_cfg.base_addr + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);
>>>
>>> The variable holds a guest-physical address, so vaddr_t is the wrong
>>> type should be either paddr_t or gaddr_t.
>>
>> Agree, paddr_t will be better what was mentioned in thread with Jan B.
>>
>>>
>>>> +    paddr_t paddr;
>>>> +    unsigned long guest_stride;
>>>> +
>>>> +    /* Nothing to map in the case of sw interrupt file. */
>>>
>>> There is no software interrupt file implementation in this series, patch 11
>>> turns the non-MSI path into a BUG_ON(). So "vsfile_id == 0" today means "this
>>> vCPU gets no external interrupts at all and nothing tells anybody". Worth
>>> saying so plainly here rather than implying a fallback exists.
>>
>> I would ask then different question will this function change when IMSIC
>> interrupt file support will be added? I think - no as in the case of
> Did you forget s/w word? If not it's weird as IMSIC interrupt file is
> the current topic of this patch series.
>> IMSIC interrupt file we don't need any stage-2 mapping. So here it is
> here too.

Yes, sorry, I missed s/w word.

>> just a check that nothing should be mapped for non-hw-assisted interrupt
>> files.
>>
>>>
>>>> +    if ( !vsfile_id )
>>>> +        return res;
>>>> +
>>>> +    guest_stride = vsfile_id * IMSIC_MMIO_PAGE_SZ;
>>>
>>>
>>>> +
>>>> +    paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset +
>>>> +            guest_stride;
>>>
>>>
>>>> +
>>>> +#ifdef IMSIC_DEBUG
>>>
>>>> +    printk("%s: %pv: ga(%#lx) -> pa(%#lx), cpu(%#x), guest_file_id(%d) "
>>>> +           "base_addr(%#lx) offset(%#lx)\n", __func__, v, gaddr, paddr, cpu,
>>>> +           vsfile_id, imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset);
>>>> +#endif
>>>> +
>>>> +    res = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
>>>> +                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
>>>> +                           arch_dt_passthrough_p2m_type());
>>>> +    if ( res )
>>>> +        printk("%s: Failed to map %#lx to the guest at %#lx\n",
>>>

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:22:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:22:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389725.1630363 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSZr-0002LI-Qp; Thu, 13 Aug 2026 10:22:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389725.1630363; Thu, 13 Aug 2026 10:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSZr-0002LB-NR; Thu, 13 Aug 2026 10:22:23 +0000
Received: by outflank-mailman (input) for mailman id 1389725;
 Thu, 13 Aug 2026 10:22:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuSZq-0002L5-2y
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:22:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSZo-005zR7-TA
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:22:20 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d9ad2-2eae-0a2a0a5409dd-0a2a45018bec-32
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:22:20 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7d9adc-5984-0a2a45010019-d155dd36c03a-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:22:20 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-480001972b8so737673f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 03:22:20 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5612b8sm4422783f8f.1.2026.08.13.03.22.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 03:22:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786616540; x=1787221340; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LwvSv0aW7xqOLgjKxaJSTejj2jZhn+Htr+waJUIGb2g=;
        b=Blpz2Bkp0FJ/9O7r5M/O4GTVXI4qwwUOYKFijdTkujjRhoc532m0HOCaSW2WQPm9cY
         Bx9LfFlJ1j+hZFDrZKxeF3d+u7bzic3y9uR/Mw53cCPlWtBXQFlDFsJnZXloXnUlpvuV
         Y+WrXx3DNAfjd08QMrsKo+h3AZJUpZ2Yw8NzGDlci2WmzXMcfjzOCBU26zYLIQ5UrOuw
         dVEpQrRqSKN8H9m7DrYEstRPz927xc/hydxL6cI+wPnPnY9IYfds3Tmp/qxDjBStGhTq
         pibxQTvjgt4NDFI2vgLyGAa/BokjqqiTfNyYvfNxA6gZXgnEWxChdJZ2pNczYCwHikoc
         YAIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786616540; x=1787221340;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LwvSv0aW7xqOLgjKxaJSTejj2jZhn+Htr+waJUIGb2g=;
        b=Bh6IC9JkH4nmxbX3/AWQiSHSN7xv2SBw8UlDUXqsr0OTeBqzUrBr0qlUa0s6cdKsXz
         Q5LKeAlyDfCZU+8oORBLBmsMdMl5/s2yk3EZTO8kAK2D5K4vjo+Rg+izEACevoAsdG+g
         b469MRqE456j7lKd85Cs22AWnB6LlNGNg1VgiiWqpKc/SC2TPp03EwCvmHpJegQtFAtg
         wMxIqC90e5R91Jb3PwFqYc5XCKvFAc6r1tWYJKvxCvZaIXWhhfVPzIQKzuS793FCTsp8
         nzcBsOvL9zUXQXBYR/uilVuFsMlVKFEGbzRQXKtcv8RaPz8krADLThu95KEcn284dZbs
         7eAg==
X-Gm-Message-State: AOJu0YxcKREK9+Cco9DqJPK4tB8iQTmhozRrUpfQNloD8ZO34JiMo1rj
	yAzf9lUXf4KBxAR6RAwn35n4TqTIw/WjSH0GpaRR2EXOsTayJjSSy7wS
X-Gm-Gg: AR+sD12VqnwNMHfcEw4MQfKGIVfRK8sVt3c7/ZJ0AOyvtV9PfMcigpEsflua+d6vtit
	PbUYieXsNAxnNJk5pSeT6Vgnna+RsHgMv30u4qLa7YwH5Dd/srwZdYsFdnPXOt6BGObVH+wa9yy
	mFwi800jSoaHpdJ2RZWZvlS7zLwdrQb0vj/ogliPTCl/gnSE2uiWvTw74JUUtgp7TtG26YBksaq
	ZPeItjlH3t/bjnmsUgu1LpKlZ0ezBPYH2vlDfVcq2vIusfyRsIDnk20OXhl8s8/Y6VPUUy0tBo6
	DR2iq54GmA9RY60Av60gP9MVq3LimsJts3L2kUCY0eLHIwdMdp/Uay4btHAEPfysRSDyaQz8S5V
	bQ+YzuJ80KE1vwBBYOGE5zaMTlz7wPeSNVgeHm3oxiezEmDMN40G+zmnQyIHSg6bFnR7W8K4Pe+
	rq4ExuIEr22YxMYmINcT8M2wuAYUvguHRRqX5N+OioMSUkjSQ1BgT+U17JYL1O8s7bq3TyNxjo9
	TB12nbJwpAI+jgDZ9KHhFWsE/RxBVdjZQBoQgmbOSg=
X-Received: by 2002:a05:6000:4b0b:b0:47f:96f9:a99f with SMTP id ffacd0b85a97d-48159eb91c7mr6627269f8f.13.1786616540231;
        Thu, 13 Aug 2026 03:22:20 -0700 (PDT)
Message-ID: <bf2c9455-dd88-444a-8a94-a3a519d951e2@gmail.com>
Date: Thu, 13 Aug 2026 12:22:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Jan Beulich <jbeulich@suse.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
 <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
 <82011389-489e-4076-9d3a-8c393e4a8e76@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <82011389-489e-4076-9d3a-8c393e4a8e76@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786616540-BF063757-B53D6F5B/10/73395122804
X-purgate-type: spam
X-purgate-size: 2844



On 8/13/26 11:51 AM, Jan Beulich wrote:
> On 13.08.2026 11:34, Oleksii Kurochko wrote:
>> On 8/13/26 11:30 AM, Baptiste Le Duc wrote:
>>>> --- a/xen/arch/riscv/imsic.c
>>>> +++ b/xen/arch/riscv/imsic.c
>>>> @@ -20,6 +20,7 @@
>>>>    #include <xen/init.h>
>>>>    #include <xen/libfdt/libfdt.h>
>>>>    #include <xen/macros.h>
>>>> +#include <xen/rwlock.h>
>>>>    #include <xen/sched.h>
>>>>    #include <xen/smp.h>
>>>>    #include <xen/spinlock.h>
>>>> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>>>        return res;
>>>>    }
>>>>    
>>>> +void imsic_state_save(struct vcpu *v)
>>>> +{
>>>> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
>>>> +    unsigned long flags;
>>>> +
>>>> +    /*
>>>> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
>>>> +     * should be done in this case.
>>>> +     */
>>>> +    if ( !vcpu_guest_file_id(v) )
>>>> +        return;
>>>
>>>
>>>> +
>>>> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
>>>> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);
>>>
>>> How will you detect a migration is needed? Don't you need to first know
>>> if ->vsfile_pcpu is different to cpuid_to_hartid(v->processor)? (I
>>> didn't take a look to other patchs for the moment, so the
>>> explanations might be later.)
>>
>> Migration (if you are speaking about migration of vCPU from one pCPU to
>> another) is completely different path. Look at sched_move_irqs().
> 
> See how terminology is important. As said elsewhere, "save state" and
> "restore state" don't make clear at all in which situation they're to be
> used.

I totally agree that it is important.

Just to clarify it now (before I started to re-shuffle and/or adding 
extra patches to have better context how this functions will be called) 
I will add some information here. So imsic_state_save() and 
imsic_state_restore() is going to be called from context_switch() 
function when one vCPU is de-scheduled and new vCPU is scheduled (so no 
migration here at all, yes it could happen but it is still a separate 
path and so separate question). Considering that my understanding that 
during context_switch() I have to save state of IMSIC which corresponds 
to vCPU which is going to be de-scheduled and restore a state of IMSIC 
of vCPU which is going to be scheduled.

With the current context is imsic_state_save() and imsic_state_restore() 
are correct names?

> 
> Also, can both of you please adjust Roger's email address when replying?

Could you please clarify what is wrong with it? For example, in this 
patch series:
   [PATCH v2 0/2] vpci: allow unaligned accesses by the hardware domain

This one is used: Roger Pau Monne <roger@xenproject.org>

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:35:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:35:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389739.1630371 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSmN-0004zD-So; Thu, 13 Aug 2026 10:35:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389739.1630371; Thu, 13 Aug 2026 10:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSmN-0004z6-PS; Thu, 13 Aug 2026 10:35:19 +0000
Received: by outflank-mailman (input) for mailman id 1389739;
 Thu, 13 Aug 2026 10:35:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuSmN-0004yz-1i
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:35:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSmM-00Cib1-3r
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:35:18 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d9dd9-2eae-0a2a0a5409dd-0a2a45028afa-26
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:35:18 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7d9de5-6ca4-0a2a45020019-d155802dc0f2-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:35:17 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4996f1ee4a4so12712365e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 03:35:17 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981e47441sm41360855e9.4.2026.08.13.03.35.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 03:35:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786617317; x=1787222117; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=E6bsn9NFfxkJnh520dPejRsEERuDcuHfX7DObfEzi1s=;
        b=EnxqSR12+erbI/CSSGzxTgtsU5blJRCnqtGUAbKLQiAVG2jnehxJLK5IazsJv3u1cR
         fwrXbFFx4JIe2yIzFeefBIMd3sEEdK181zk9Z4eVh8+v9z9bdIeBQMbvyuebXUxFrCHT
         LVx98GoA3RL+mYVx1/ScGwU0ZwT2pVb24KREhPW2LxugnaWjsclMhkBvQ/G0TQ6SR96n
         XL4TA4uCKfDPJbdiEfbEKSLiIaIepSOHed31whZyHDKiDe6PDsqUY0FiEN1A86nX63fG
         G3cm9pozbY8p0URT9WIm9+w9oCT7pzMMK39szq2sRTOkW3c7Qkq5xfl5Fk+pPRpUDxXp
         eHpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786617317; x=1787222117;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=E6bsn9NFfxkJnh520dPejRsEERuDcuHfX7DObfEzi1s=;
        b=Jc7magfvl7qD5RomLGEYqq7tuTT7Qn08E6xWgiuO4snviES/U5+YGfK2hh2eU5kHKk
         OX/uwafcaY3phgIqQ+c9XioJU8XxdgXV00CJo08A1vrbZLoXGT2tq8z9Bhhp9K/kK9ho
         iYg08+jk2CvlVPhYILhQF50wuOU8S0OXGF4j9tR6FeAHhHns4ZuxW7KiMFlSwIyk433p
         w6YCy9vvwGyXZ1wcUORh/CbadvVDWbZQP2JbTGmKFvAut6VSSCCdQ7cQCLWsHlTf+qLO
         XV9snbyfV2gZyQyMhSV7NvxTuainwItP2U/ZRkd1jZEafLAKbvcmwkrIFXzdHcBq2jZR
         iVtg==
X-Forwarded-Encrypted: i=1; AHgh+RqSSb5Dw1Op3yLzDMGtgDN88uGAWFXq9EXg+omJ2Pi4w3vxLolUv0ZDrbIvrdRrOlB2RwvfgZiT6Qs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWsLJT7M3tQr4TLor+4qNpZkLzXNvtJI442U65VUixSHeeKFb5
	DB83OXgGTooLon81WOx6RoLrlLotik0+MZaf5/clhuWJQzQCZ1ocV6laFBVpqyUnwA==
X-Gm-Gg: AR+sD12mdMXCn3YjhuNIIg+9n/WD36iV1s2k7ZjFwCFa4ZO3kdb8xwLBkbJ+1hrV8SZ
	ukVdZrSSKJ1dacZvtpmE87BOrcOO+jPHoddBf6+Ou9dwCfOf1+7OQeQDOBQa4NzA7u/fLHiWN1T
	m7Dy2mVOVs8sZrDthpg2raOZegmuWzmV5tSEMqARR0qDcf3aKuRYCt+jPRpkjCmZPO7OcNiSaU7
	H7YOCk322Szo7ruHbNH/2aAFTphx/3Tic6PiIIttpkx8Cxax4n/39epjDgWWgT1vuaYuyV9aAjQ
	1JVDKdVxHkS0D1s1cu1+ktKzUUjuUpdEShwUvozVRLZOG38xOyT+gYPeBIjboHW8/HftClt2zJZ
	1yec7GxvM5UnBPAiSnLu21iQVyRaEYM8nvVc36DnuTx4MuUEctJG0387cwDbXLiIs+1IcyslsHS
	Oq6kgFuHOnggNIotS4oVoqE5nID6hn/iFvbBkdQnRhIPphO7R+Ouc5MY016Qy2CoOTNVjK7dGZd
	IstOn16P3RzNMm0Iy4CwFSX/XXxSI+MMgTugi0B5nt0Y3bJWdym
X-Received: by 2002:a05:600c:3113:b0:493:c634:952 with SMTP id 5b1f17b1804b1-499821aa438mr45883185e9.7.1786617317332;
        Thu, 13 Aug 2026 03:35:17 -0700 (PDT)
Message-ID: <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
Date: Thu, 13 Aug 2026 12:35:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260802050824.10554-1-brchuckz@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786617318-674BE2AC-592EE1DA/0/0
X-purgate-type: clean
X-purgate-size: 14275

On 02.08.2026 07:08, Chuck Zmudzinski wrote:
> Modern Intel IGD devices do not work well with the current
> implementation of support for the Intel IGD in hvmloader because
> it lacks support for an extended video bios table (VBT).
> 
> Code 43 errors in Windows guests and failure of the guest screen
> to light up are some of the problems that occur with the
> current implementation.
> 
> To address this problem, this patch implements support for
> Intel IGD devices with an extended VBT and OpRegion version 2
> and higher which is required for most modern Intel IGD devices.

First of all: Where's the spec of all of this?

> ---
>[...]
> 
>  tools/firmware/hvmloader/Makefile         |   1 +
>  tools/firmware/hvmloader/config.h         |  15 +-
>  tools/firmware/hvmloader/e820.c           |   4 +-
>  tools/firmware/hvmloader/intel_opregion.c | 297 ++++++++++++++++++++++

Nit: Please use dashes in favor of underscores in new files' names.

> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -35,6 +35,7 @@ OBJS += smp.o cacheattr.o xenbus.o vnuma.o
>  OBJS += e820.o pci.o pir.o ctype.o
>  OBJS += hvm_param.o
>  OBJS += ovmf.o seabios.o
> +OBJS += intel_opregion.o

While this list isn't well sorted, I think your addition still wants to move
up by a line.

> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -7,9 +7,6 @@
>  enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
>  extern enum virtual_vga virtual_vga;
>  
> -extern unsigned long igd_opregion_pgbase;
> -#define IGD_OPREGION_PAGES 3
> -
>  struct bios_config {
>      const char *name;
>  
> @@ -43,6 +40,18 @@ extern struct bios_config ovmf_config;
>  
>  #define PAGE_SHIFT 12
>  #define PAGE_SIZE  (1ul << PAGE_SHIFT)
> +#define IGD_OPREGION_PAGES 3
> +#define IGD_OPREGION_SIZE ((IGD_OPREGION_PAGES - 1) << PAGE_SHIFT)

This is odd, and hence wants a comment.

> +#define IGD_OPREGION_RVDA 0x3ba
> +#define IGD_OPREGION_RVDS 0x3c2
> +#define IGD_OPREGION_VERSION 0x16
> +#define IGD_OPREGION_MASK 0xfff
> +#define IGD_OPREGION2_SUPPORT_MASK 0x1
> +#define IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
> +#define IGD_VBT_SIGNATURE "$VBT"
> +extern unsigned long igd_opregion_pgbase;
> +extern uint32_t igd_opregion_e820_pages;
> +void intel_opregion_setup(uint32_t vga_devfn);

Blank lines please ahead of the new #define-s you add and between those new
#define-s and the new decls.

For igd_opregion_e820_pages I further cannot spot any use which would justify
the use of a fixed-width type; unsigned int will do, and will then be in line
with ./CODING_STYLE.

> --- a/tools/firmware/hvmloader/e820.c
> +++ b/tools/firmware/hvmloader/e820.c
> @@ -243,11 +243,11 @@ int build_e820_table(struct e820entry *e820,
>          nr++;
>  
>          e820[nr].addr = igd_opregion_base;
> -        e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE;
> +        e820[nr].size = igd_opregion_e820_pages * PAGE_SIZE;
>          e820[nr].type = E820_NVS;
>          nr++;
>  
> -        e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE;
> +        e820[nr].addr = igd_opregion_base + igd_opregion_e820_pages * PAGE_SIZE;

Are these new multiplications at risk of overflowing? I.e. how many pages can
there be in an extreme case?

> --- /dev/null
> +++ b/tools/firmware/hvmloader/intel_opregion.c
> @@ -0,0 +1,297 @@
> +/*
> + * intel_opregion.c: HVM Intel OpRegion setup.
> + *
> + * Leendert van Doorn, leendert@watson.ibm.com
> + * Copyright (c) 2005, International Business Machines Corporation.
> + *
> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.

What do these cover?

> + * Copyright (c) 2026, Charles Zmudzinski.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; If not, see <http://www.gnu.org/licenses/>.
> + */

Please use an SPDX line instead in new files.

> +#include "util.h"
> +#include "config.h"
> +#include "pci_regs.h"
> +
> +unsigned long igd_opregion_pgbase = 0;
> +uint32_t igd_opregion_e820_pages = IGD_OPREGION_PAGES;
> +
> +static bool verify_opregion(const uint32_t addr)
> +{
> +    const char *opregion_signature = IGD_OPREGION_SIGNATURE;
> +    if ( memcmp((const void *)addr, (const void *)opregion_signature, 16) )
> +        return false;
> +    return true;
> +}

Style: Blank line please between declaration(s) and statement(s) as well as
ahead of the main "return" of a function. There further isn't really a need
for an if() or two return statements here. Also please avoid casts wherever
possible. Finally, the local variable isn't really needed here either - the
string literal can be passed directly to memcmp(). All of this helps
readability as well.

> +static bool verify_vbt(const uint32_t addr)
> +{
> +    const char *vbt_signature = IGD_VBT_SIGNATURE;
> +    if ( memcmp((const void *)addr, (const void *)vbt_signature, 4) )
> +        return false;
> +    return true;
> +}

Same comments here, obviously (and potentially elsewhere).

> +void intel_opregion_setup(uint32_t vga_devfn)
> +{
> +    uint32_t igd_guest_opregion;
> +    uint32_t pages_needed; /* for OpRegion + VBT */

The former probably wants to be fixed-width, but for the latter I see no need.

> +    void *opregion_scratch;
> +    void *vbt_scratch;
> +    void *vbt_source;
> +    /*
> +     * absolute value in the host/guest except
> +     * as noted in the comments
> +     */

Nit: Comment style (see ./CODING_STYLE).

> +    static unsigned long rvda_host;
> +    static unsigned long rvda_guest;

Why static? The function can't be called more than once, if I'm not mistaken.

> +    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
> +    /*
> +     * Tentative value for the number of pages to reserve
> +     * in the E820 map for the OpRegion and VBT.
> +     *
> +     * This will be the final value for the E820 map if
> +     * the device model lacks support for OpRegion 2 or
> +     * if the host OpRegion version is < 2 or if we never
> +     * allocate more pages in the E820 map for the VBT.
> +     */
> +    igd_opregion_e820_pages = IGD_OPREGION_PAGES;
> +
> +    /*
> +     * Read the value the device model is initialized with.
> +     * If the device model supports OpRegion 2, it will
> +     * return the host IGD OpRegion address. If not, it
> +     * will return 0. If the device model does not support
> +     * OpRegion 2, the device model expects us to give it
> +     * the address to which it will map the OpRegion in the
> +     * guest and then expects us to do nothing more to setup
> +     * the OpRegion, so that is all we will do in that case.
> +     */

Hmm, exposing the host opregion to a guest certainly feels like an issue.

> +    const uint32_t igd_host_opregion = pci_readl(vga_devfn,
> +                                                 PCI_INTEL_OPREGION);
> +    if ( !igd_host_opregion ) {

Nit (style) Brace placement (throughout).

> +        printf("device model lacks extended VBT "
> +               "support. Continuing with legacy support only\n");

This message can easily confuse / worry people. (If it was to be kept, it
would also need style adjustment.)

> +        /*
> +         * Write the the OpRegion offset to give the OpRegion
> +         * address to the device model. The device model will trap
> +         * and map the OpRegion at the give address.
> +         */
> +        pci_writel(vga_devfn, PCI_INTEL_OPREGION,
> +                   igd_opregion_pgbase << PAGE_SHIFT);
> +        return;
> +    } else {

No need for "else" after an unconditional "return".

> +        printf("host OpRegion address: 0x%x\n",

The shorter %#x please (also elsewhere).

> +               igd_host_opregion);
> +    }
> +
> +    const uint32_t igd_host_opregion_page_offset =
> +                   igd_host_opregion & IGD_OPREGION_MASK;

I think like in the hypervisor we don't want to mix declarations and
statements just yet.

> +    igd_guest_opregion = (igd_opregion_pgbase << PAGE_SHIFT) |
> +                          igd_host_opregion_page_offset;
> +
> +    /*
> +     * We know at this point the device model supports
> +     * OpRegion 2.
> +     *
> +     * Indicate to the device model that we support
> +     * OpRegion 2 by setting the least significant bit
> +     * of the address we give to the device model.
> +     * The device model will notice this bit set and
> +     * respond appropriately to our writes to the
> +     * register where the OpRegion address is stored.
> +     */

Specifically noticeable here: Please make better use of line length in
long(ish) comments.

> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
> +               (igd_opregion_pgbase << PAGE_SHIFT) |
> +                IGD_OPREGION2_SUPPORT_MASK);

This looks to imply qemu is the only possible device model.

> +    printf("guest OpRegion tentative "
> +           "address: 0x%x\n", igd_guest_opregion);
> +
> +    if ( !verify_opregion(igd_guest_opregion) ) {
> +        printf("error: IGD OpRegion signature "
> +               "not found.\n");

No full stop in messages please.

> +        BUG();
> +    }
> +
> +    opregion_scratch = scratch_alloc(IGD_OPREGION_SIZE, 0);
> +    memcpy(opregion_scratch, (const void *)igd_guest_opregion,
> +           IGD_OPREGION_SIZE);
> +
> +    /* Read OpRegion version, rvda_host, and rvds */
> +    const uint16_t version = *(uint16_t *)(opregion_scratch +
> +                                           IGD_OPREGION_VERSION);
> +    printf("OpRegion version: 0x%x\n", version);
> +    if ( version >= 0x0200 ) {
> +        rvda_host = *(unsigned long *)(opregion_scratch +
> +                                       IGD_OPREGION_RVDA);
> +        /* It is convenient to make rvda_host absolute */
> +        if ( version > 0x0200 )
> +            rvda_host += igd_host_opregion;
> +        printf("host VBT address: 0x%lx\n", rvda_host);
> +    } else {
> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
> +        rvda_host = 0;
> +    }
> +    const uint32_t rvda_host_page_offset = rvda_host &
> +                                           IGD_OPREGION_MASK;

Why host_page_offset here when ...

> +    const uint32_t rvds = *(uint32_t *)(opregion_scratch +
> +                                        IGD_OPREGION_RVDS);
> +    const uint32_t rvds_page_offset = rvds & IGD_OPREGION_MASK;

... it's just page_offset here, and when further you use it below to set
rvda_guest?

> +    printf("VBT size: 0x%x\n", rvds);
> +
> +    if ( !rvds || !rvda_host ) {
> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
> +        rvda_host = 0;
> +    }
> +    /*
> +     * Write rvda_host as 2 successive 32-bit values
> +     * to communicate location of the VBT to the device
> +     * model. If rvda_host is not 0, The device model
> +     * unmaps the OpRegion and eventually maps the VBT
> +     * after we also write the guest address where the
> +     * VBT will be mapped.
> +     *
> +     * If we send rvda_host = 0 to the device model, it
> +     * will assume we do not need OpRegion 2 support and
> +     * it will not unmap the OpRegion.
> +     */
> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
> +               (uint32_t)(rvda_host & 0xfffffffful));
> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
> +               (uint32_t)rvda_host_upper_32);

Why would you need to communicate a host property to the DM?

> +    /* In this case, we use the mapped OpRegion */
> +    if ( !rvda_host )
> +        return;
> +
> +    /*
> +     * Update the number of pages the device model
> +     * needs to map for us to get a copy of the VBT.
> +     *
> +     * N.B.: Here, igd_opregion_pgbase is really the page
> +     * base of the location where the device model will
> +     * map the VBT.
> +     */
> +    uint32_t vbt_pages_needed = rvds >> PAGE_SHIFT;
> +    if ( rvds & IGD_OPREGION_MASK )
> +        vbt_pages_needed++;
> +    if ( vbt_pages_needed > igd_opregion_e820_pages ) {
> +        igd_opregion_pgbase = mem_hole_alloc
> +                              (vbt_pages_needed - igd_opregion_e820_pages);

Nit: Indentation.

> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -43,7 +43,6 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>  #define BAR_RELOC_THRESH GB(1)
>  
>  enum virtual_vga virtual_vga = VGA_none;
> -unsigned long igd_opregion_pgbase = 0;
>  
>  /* Check if the specified range conflicts with any reserved device memory. */
>  static bool check_overlap_all(uint64_t start, uint64_t size)
> @@ -190,14 +189,7 @@ void pci_setup(void)
>                  virtual_vga = VGA_pt;
>                  if ( vendor_id == 0x8086 )
>                  {
> -                    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
> -                    /*
> -                     * Write the the OpRegion offset to give the opregion
> -                     * address to the device model. The device model will trap 
> -                     * and map the OpRegion at the give address.
> -                     */
> -                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
> -                               igd_opregion_pgbase << PAGE_SHIFT);
> +                    intel_opregion_setup(vga_devfn);
>                  }

With this preferably also drop the figure braces.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:40:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:40:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389747.1630379 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSqy-0006BX-Do; Thu, 13 Aug 2026 10:40:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389747.1630379; Thu, 13 Aug 2026 10:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSqy-0006Ax-Av; Thu, 13 Aug 2026 10:40:04 +0000
Received: by outflank-mailman (input) for mailman id 1389747;
 Thu, 13 Aug 2026 10:40:02 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wuSqw-0005jF-H7
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:40:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSqv-00Cj9y-Oy
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:40:01 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7d9f01-bab6-0a2a0a5309dd-0a2a4502a20a-0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:40:01 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7d9f01-6ca4-0a2a45020019-c387df82a8e2-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:40:01 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 834FA8262A;
 Thu, 13 Aug 2026 10:39:52 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 259FE77D97;
 Thu, 13 Aug 2026 10:39:51 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id m4H9B/eefWpBaQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 13 Aug 2026 10:39:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786617596; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=mby0JMgwZ0EWkWrXcLy1dExsgwJl7Ejt0AYuo/6h5Vo=;
	b=r+6bX+6AWVMSGnXZwwGsjPOwKRWDz4mLOKQAL27A98lhztNodMiwfm4ZmMPVBPB1VO/r3F
	TK0wWbhHXPT1Dw530qkI9vEwXAwKZn2kNoSQbU6sdDxWvatlk1yQjiWeMHDy9lXEoz7V7f
	vuh70kZAUJRiXAzxYvRonjRzltGWiis=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786617592; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=mby0JMgwZ0EWkWrXcLy1dExsgwJl7Ejt0AYuo/6h5Vo=;
	b=bK52L1D3K9mbxDOsdWNSb6O2/celtH2wKe70H4hnLOMq9n9cltPsYMfOJgZy6oPXQT7jGH
	BKVxeZ4Y0Hxxjxw6tw6mfoX1eoUfx1+oVM2F0ZBpdCoIUKCUe+adwArqJWvT5+Q2DGIcAY
	6UyBb5DtERLTA68VybMXZzHKZWXBF1w=
Message-ID: <47c411e5-5321-4343-9aae-9e16dbaedfad@suse.com>
Date: Thu, 13 Aug 2026 12:39:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 9/9] xen: use hw_pte_t for PTE range callbacks
To: Muhammad Usama Anjum <usama.anjum@arm.com>,
 Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
 Helge Deller <deller@gmx.de>, Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com,
 ryan.roberts@arm.com
Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-10-usama.anjum@arm.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260806083926.1807279-10-usama.anjum@arm.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ypKYePDac7DgsbAphlTma6Kr"
X-Spamd-Result: default: False [-3.69 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	SUSPICIOUS_RECIPS(1.50)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.19)[-0.968];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FREEMAIL_TO(0.00)[arm.com,linux.intel.com,intel.com,ursulin.net,gmail.com,ffwll.ch,hpe.com,arndb.de,linuxfoundation.org,HansenPartnership.com,gmx.de,kernel.org,linux.dev,suse.de,linux-foundation.org,infradead.org,soleen.com,tencent.com,goodmis.org,iogearbox.net,redhat.com,suse.cz,ziepe.ca,huawei.com,gentwo.org,cmpxchg.org,nvidia.com,linux.ibm.com];
	RCVD_TLS_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com,gmx.de];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLs8zjbsb63jxdha39bidwa4y3)];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_GT_50(0.00)[66];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email,arm.com:email]
X-Spam-Flag: NO
X-Spam-Score: -3.69
X-Spam-Level: 
X-purgate-ID: tlsNG-720697/1786617601-666B72AC-26AE1ABB/0/0
X-purgate-type: clean
X-purgate-size: 8833

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ypKYePDac7DgsbAphlTma6Kr
Content-Type: multipart/mixed; boundary="------------c720gI9EPuLmVtPBwUUV3q9s";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Muhammad Usama Anjum <usama.anjum@arm.com>,
 Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
 Helge Deller <deller@gmx.de>, Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 David Hildenbrand <david@kernel.org>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com,
 ryan.roberts@arm.com
Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Message-ID: <47c411e5-5321-4343-9aae-9e16dbaedfad@suse.com>
Subject: Re: [PATCH 9/9] xen: use hw_pte_t for PTE range callbacks
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-10-usama.anjum@arm.com>
In-Reply-To: <20260806083926.1807279-10-usama.anjum@arm.com>

--------------c720gI9EPuLmVtPBwUUV3q9s
Content-Type: multipart/mixed; boundary="------------N4sVlTeyaJaCa2dXXYReUSgH"

--------------N4sVlTeyaJaCa2dXXYReUSgH
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDYuMDguMjYgMTA6MzgsIE11aGFtbWFkIFVzYW1hIEFuanVtIHdyb3RlOg0KPiBHZW5l
cmljIFBURSByYW5nZSBhbmQgcmVtYXBwaW5nIGhlbHBlcnMgbm93IHBhc3MgcG9pbnRlcnMg
dG8gUFRFIHRhYmxlDQo+IHN0b3JhZ2UgYXMgaHdfcHRlX3QgKi4gVXBkYXRlIHRoZSBYZW4g
Y2FsbGJhY2tzIHRvIG1hdGNoIHRob3NlIGludGVyZmFjZXMuDQo+IA0KPiBLZWVwIGxvZ2lj
YWwgUFRFIHZhbHVlcyBhcyBwdGVfdCBhbmQgY29udGludWUgdG8gYWNjZXNzIHRoZW0gdGhy
b3VnaCB0aGUNCj4gZXhpc3RpbmcgUFRFIGhlbHBlcnMuIFRoaXMgaXMgcmVxdWlyZWQgd2hl
biBYZW4gaXMgYnVpbHQgZm9yIGFuDQo+IGFyY2hpdGVjdHVyZSB0aGF0IHNlbGVjdHMgdGhl
IGRpc3RpbmN0IGh3X3B0ZV90IHdyYXBwZXIuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBNdWhh
bW1hZCBVc2FtYSBBbmp1bSA8dXNhbWEuYW5qdW1AYXJtLmNvbT4NCg0KUmV2aWV3ZWQtYnk6
IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------N4sVlTeyaJaCa2dXXYReUSgH
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------N4sVlTeyaJaCa2dXXYReUSgH--

--------------c720gI9EPuLmVtPBwUUV3q9s--

--------------ypKYePDac7DgsbAphlTma6Kr
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp9nvYFAwAAAAAACgkQsN6d1ii/Ey+y
sQf8DyaOHOavz2N3DHzJxUcqzEKPvct49YGYUyCWLiVDfpU/dpETsiy0py0gy/1OdKNz9fB5DRbe
8Lm9XXR/UA/+mo2ngOV0fERizvAf0WXGi+VEEW7PDzNBMu5+fTyUHBsdVauem3ZGFNpeLgtOb0MM
EcqgvRhDtW/55HrfdAsGA9Q4ivaZcEuTMIFI3ojyqkHxgNQikEPueD43Bxa3EM+YOonkbXl2mQUx
xH2+0EIyIOPaED6aafGCFJfGlEgXupdjwl0OO/KOkyheUpsriWyps3GfVCjT7AyeOZuvtUVi4Shh
FWH5ZonhLSGDNLa3ew45F4gx0bBMXKT8CAuY/VKjPg==
=OUNy
-----END PGP SIGNATURE-----

--------------ypKYePDac7DgsbAphlTma6Kr--


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:43:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:43:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389757.1630389 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSuV-0007NG-1O; Thu, 13 Aug 2026 10:43:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389757.1630389; Thu, 13 Aug 2026 10:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSuU-0007N9-UB; Thu, 13 Aug 2026 10:43:42 +0000
Received: by outflank-mailman (input) for mailman id 1389757;
 Thu, 13 Aug 2026 10:43:41 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <james@dingwall.me.uk>) id 1wuSuT-0007N3-8c
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:43:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSuS-000b5G-IJ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:43:40 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7d9fc7-bab6-0a2a0a5309dd-0a2a4502a6c4-48
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:43:40 +0200
Received: from [212.23.1.21] (helo=smarthost01b.ixn.mail.zen.net.uk)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7d9fdc-6ca4-0a2a45020019-d4170115bb06-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:43:40 +0200
Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk)
 by smarthost01b.ixn.mail.zen.net.uk with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97)
 (envelope-from <james@dingwall.me.uk>) id 1wuSuR-00000000pRW-38cJ;
 Thu, 13 Aug 2026 10:43:39 +0000
Received: from localhost (localhost [IPv6:::1])
 by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id 4BE83F0908C;
 Thu, 13 Aug 2026 11:43:39 +0100 (BST)
Received: from mail0.xen.dingwall.me.uk ([IPv6:::1])
 by localhost (mail0.xen.dingwall.me.uk [IPv6:::1]) (amavis, port 10024)
 with ESMTP id cyE5uZ0aws-j; Thu, 13 Aug 2026 11:43:39 +0100 (BST)
Received: from ghoul.dingwall.me.uk (ghoul.dingwall.me.uk
 [IPv6:2a02:8010:698e:302::c0a8:1c8])
 by dingwall.me.uk (Postfix) with ESMTP id 1739CF09089;
 Thu, 13 Aug 2026 11:43:39 +0100 (BST)
Received: by ghoul.dingwall.me.uk (Postfix, from userid 1000)
 id EEB477F6; Thu, 13 Aug 2026 11:43:38 +0100 (BST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
X-Virus-Scanned: Debian amavis at dingwall.me.uk
From: James Dingwall <james@dingwall.me.uk>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH] libxl: use libxl__qemu_qmp_path() instead of open coding
Date: Thu, 13 Aug 2026 11:41:08 +0100
Message-ID: <20260813104325.489224-1-james@dingwall.me.uk>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Originating-smarthost01b-IP: [217.155.64.189]
Feedback-ID: 217.155.64.189
X-purgate-ID: tlsNG-720697/1786617820-F04A62AC-AD4D8D80/0/0
X-purgate-type: clean
X-purgate-size: 273

Hi,

I was tracing a problem with the qmp socket and found two open coded
definitions of the path when a helper function is available via
libxl_internal.h which is already included.  The 'const' was needed to
build with the Ubuntu 26.04 tool chain.

Thanks,
James


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:44:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:44:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389765.1630397 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSvb-0007qt-9k; Thu, 13 Aug 2026 10:44:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389765.1630397; Thu, 13 Aug 2026 10:44:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSvb-0007qm-6j; Thu, 13 Aug 2026 10:44:51 +0000
Received: by outflank-mailman (input) for mailman id 1389765;
 Thu, 13 Aug 2026 10:44:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuSvZ-0007qa-W8
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:44:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSvZ-002pM6-Ch
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:44:49 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7da00e-e002-0a2a0a5209dd-0a2a4509b3b2-36
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:44:49 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7da020-be1a-0a2a45090019-d1558029b490-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:44:48 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4998590d392so307735e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 03:44:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49982121649sm52334015e9.1.2026.08.13.03.44.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 03:44:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786617888; x=1787222688; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=UonC9YJvP/LKADLtGvllmu1ErX663GL20fYvqcpJvLQ=;
        b=BUippESn3HD/odUZYNhLTq/4qiqvYE/BewoFLnoHGD1kXXyPmvgURXc5iLp9stnEea
         MxQBYiYm/uHpq8stG9gpl/hQem0/vyZXpGBFcLDdztvxx3shsnPV/EwrYx30BKj0B5ba
         AUj0zzHzVxFvX3U27QRylyIcnFujwmNDRXZWRDUKarb+17W/FaibvZeDefRtDqRYg7Rs
         ek/vxsujIraJdXLalZ/lalq3gy70DQKXdmvvFLARv2qwD71OLlkPAxamAvHp1fxQxyT0
         uh2ddQfrsoB8ppDiYaPbnIQxiVoNqcBTQtZtw+ev5RYZzH3KkqSfBDmTe9gajxUQ8Z/8
         8dUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786617888; x=1787222688;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=UonC9YJvP/LKADLtGvllmu1ErX663GL20fYvqcpJvLQ=;
        b=CelkqWyjHBladysv1sbF2sRhRx3TnSuVyv5aBsAE7JoRJNSPAPoBCjoX6wflFtNuq4
         T2nHSwR8zesxsjBJqbl1AphN/zPn8henUq+g1+gHD9ryGS97jnxQ7m5nLUzikeiTGt5N
         nDzx+iU83v4RiQgQNIsUS37jzJTKQTItctnFdstYU+2MS/grTpLatNu91YMh0LSFWClE
         s7iQJSUJlNHnNpxpWcl/sFm89hPCfH99hduJWHqRoZJ5Ja6FBAu2RFJQCXc1XvHMHk2q
         0Mf7qVBBWCZd6tZ3iKa99iV3FsiQgUK6+R69285/vXDMBGbSoP/yU4dfC01o/dHpgwlB
         eKoQ==
X-Gm-Message-State: AOJu0Yzr4ta7aoy1m442midb6XO7MRnPLxQKi/8vn+K6ck72/jgwraaE
	PBkNnfpS9LmK5q6OL6l9qOj9srcb1Kg7yRpLmzAwVy9J8CZn5PhPaJDe63QxpkzwHA==
X-Gm-Gg: AR+sD12dpRLgZbQtwjrY4uOooDMX7wd0maO3EM1SkxxFMvjYpuDNSqaicazE55eZoO2
	uYVughDYQ2vwznbnQpMz4FkXU0nRzL+IGX/AzT7Fw3zOhEWharKTw/tU2H9J+zHrEApukaCfq83
	SoRj6KGPV8RSODHdQ7eoDtHUOICRABSMjUZtPKmVz5d7GW40apJSYtGqN7yQPJq/XcGA09uJWQ+
	2bED0yPVB5itgOYTTjy5K7p1JfmZWliI+EWpHoSEKpihNiuKWvbtFtMJ8J8y73g9v/4ep0me+5o
	imfgH5nTo9SvlHRQeHqlHMLPei5fWFGhEvXigNPbgwilcOZCFR9fPowbkjAFgjqqxxpTnTRi9NW
	GbCS6r0GxB411daZdPGN35rMspa6t0UApvX9CKX4WqSRV/Y1ZV9ccVxVO8Z4WFVOe1O1sq3CNEY
	jDALoIvlBdvLQlRHpIg4+8xZXzmVCPQrhhh7lPXepmlifcPtqwsmvx/q/r36crPJAB6J3BtfI2L
	UkLNHzsZHhCbBXYJeaRiuU8qtnqu5F+ybEy/1qF/777lV1rE92A
X-Received: by 2002:a05:600c:5494:b0:499:83f1:398 with SMTP id 5b1f17b1804b1-49983f10706mr25110665e9.9.1786617887020;
        Thu, 13 Aug 2026 03:44:47 -0700 (PDT)
Message-ID: <a88930bc-e11a-4da1-b545-9474b5295d84@suse.com>
Date: Thu, 13 Aug 2026 12:44:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
 <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
 <82011389-489e-4076-9d3a-8c393e4a8e76@suse.com>
 <bf2c9455-dd88-444a-8a94-a3a519d951e2@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <bf2c9455-dd88-444a-8a94-a3a519d951e2@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1786617888-BD2CC034-B93389E2/0/0
X-purgate-type: clean
X-purgate-size: 3499

On 13.08.2026 12:22, Oleksii Kurochko wrote:
> On 8/13/26 11:51 AM, Jan Beulich wrote:
>> On 13.08.2026 11:34, Oleksii Kurochko wrote:
>>> On 8/13/26 11:30 AM, Baptiste Le Duc wrote:
>>>>> --- a/xen/arch/riscv/imsic.c
>>>>> +++ b/xen/arch/riscv/imsic.c
>>>>> @@ -20,6 +20,7 @@
>>>>>    #include <xen/init.h>
>>>>>    #include <xen/libfdt/libfdt.h>
>>>>>    #include <xen/macros.h>
>>>>> +#include <xen/rwlock.h>
>>>>>    #include <xen/sched.h>
>>>>>    #include <xen/smp.h>
>>>>>    #include <xen/spinlock.h>
>>>>> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>>>>        return res;
>>>>>    }
>>>>>    
>>>>> +void imsic_state_save(struct vcpu *v)
>>>>> +{
>>>>> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
>>>>> +    unsigned long flags;
>>>>> +
>>>>> +    /*
>>>>> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
>>>>> +     * should be done in this case.
>>>>> +     */
>>>>> +    if ( !vcpu_guest_file_id(v) )
>>>>> +        return;
>>>>
>>>>
>>>>> +
>>>>> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
>>>>> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);
>>>>
>>>> How will you detect a migration is needed? Don't you need to first know
>>>> if ->vsfile_pcpu is different to cpuid_to_hartid(v->processor)? (I
>>>> didn't take a look to other patchs for the moment, so the
>>>> explanations might be later.)
>>>
>>> Migration (if you are speaking about migration of vCPU from one pCPU to
>>> another) is completely different path. Look at sched_move_irqs().
>>
>> See how terminology is important. As said elsewhere, "save state" and
>> "restore state" don't make clear at all in which situation they're to be
>> used.
> 
> I totally agree that it is important.
> 
> Just to clarify it now (before I started to re-shuffle and/or adding 
> extra patches to have better context how this functions will be called) 
> I will add some information here. So imsic_state_save() and 
> imsic_state_restore() is going to be called from context_switch() 
> function when one vCPU is de-scheduled and new vCPU is scheduled (so no 
> migration here at all, yes it could happen but it is still a separate 
> path and so separate question). Considering that my understanding that 
> during context_switch() I have to save state of IMSIC which corresponds 
> to vCPU which is going to be de-scheduled and restore a state of IMSIC 
> of vCPU which is going to be scheduled.
> 
> With the current context is imsic_state_save() and imsic_state_restore() 
> are correct names?

No. "save" and "restore" would best be limited to migration paths (migration
of guests between hosts, that is). I can only once again suggest that you
look at existing naming in the code base. You'll find e.g.
svm_ctxt_switch_from() or vmx_ctxt_switch_to() under x86/hvm/.

>> Also, can both of you please adjust Roger's email address when replying?
> 
> Could you please clarify what is wrong with it? For example, in this 
> patch series:
>    [PATCH v2 0/2] vpci: allow unaligned accesses by the hardware domain
> 
> This one is used: Roger Pau Monne <roger@xenproject.org>

Whereas in your mail it was still Roger Pau Monné <roger.pau@citrix.com>.
When you originally posted the series, that was still correct. But in the
meantime it has changed (and I expect sending mail to the old address
wouldn't reach him anymore).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:46:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:46:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389775.1630407 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSxZ-0008Oz-Jw; Thu, 13 Aug 2026 10:46:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389775.1630407; Thu, 13 Aug 2026 10:46:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuSxZ-0008Os-H4; Thu, 13 Aug 2026 10:46:53 +0000
Received: by outflank-mailman (input) for mailman id 1389775;
 Thu, 13 Aug 2026 10:46:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wuSxX-0008Om-96
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:46:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuSxV-006GyL-Id
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:46:49 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7da070-bab6-0a2a0a5309dd-0a2a450ce822-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:46:49 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7da099-f479-0a2a450c0019-c387df82b286-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:46:49 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id CA65D827F4;
 Thu, 13 Aug 2026 10:46:40 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 85E9977D99;
 Thu, 13 Aug 2026 10:46:40 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id wAB+H5CgfWpUbwAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 13 Aug 2026 10:46:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786618005; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=eof/nfc31sgCwmRQPsxrHnqus+/FTvS0U4LGExSxNNM=;
	b=SEvoXk4YTNxEOKYK8dvFQgtMZL9rb4+IXNUxOGyK2fNE1VdVYJOEQxcv4YG+8lGKMSNOS3
	rk4525cyGlrapZTx0KEagcpKGTDGMwZ5gEmb747BZN7ibLGApJ1ZgC2Zx5vbkEy1ZS2vdU
	SPCjThLDNHPjQn2z44XuUteoY2uH3NQ=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786618000; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=eof/nfc31sgCwmRQPsxrHnqus+/FTvS0U4LGExSxNNM=;
	b=pPL+9LHdHVkbQjRc8osgpaMi0SA3FytEk5w0wCdfnh6nQLVb1YYQWKyqIT2JHwiCB3y0TF
	glgZCmoJ1kAgQU0BriKzpUpFq0NG771sciJZ8+SKkWIvoTf0ADs6UtPYxgGMpJmnZnr1dP
	xbtY/VsF6DXVT4HF8eHN1YIdXuaS/ro=
Message-ID: <85897ca5-77ae-4b05-89c2-8b1619845c48@suse.com>
Date: Thu, 13 Aug 2026 12:46:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] xenbus: Unregister reboot notifier on init failure
To: Yuho Choi <dbgh9129@gmail.com>
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 thorsten.blum@linux.dev, jason.andryuk@amd.com, alhouseenyousef@gmail.com,
 kees@kernel.org, darwi@linutronix.de, jpoimboe@kernel.org,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 alhouseenyoursef@gmail.com
References: <20260807032326.940377-1-dbgh9129@gmail.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260807032326.940377-1-dbgh9129@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------GZiVdMBhiTJ209aQF9aZo81v"
X-Spam-Score: -5.20
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-5.20 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWELVE(0.00)[12];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[kernel.org,epam.com,linux.dev,amd.com,gmail.com,linutronix.de,lists.xenproject.org,vger.kernel.org];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid]
X-purgate-ID: tlsNG-d25034/1786618009-030D9A5B-B647A40E/0/0
X-purgate-type: clean
X-purgate-size: 6786

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------GZiVdMBhiTJ209aQF9aZo81v
Content-Type: multipart/mixed; boundary="------------8ROkd0MUYfh0EpH70IIJUEeu";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Yuho Choi <dbgh9129@gmail.com>
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 thorsten.blum@linux.dev, jason.andryuk@amd.com, alhouseenyousef@gmail.com,
 kees@kernel.org, darwi@linutronix.de, jpoimboe@kernel.org,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 alhouseenyoursef@gmail.com
Message-ID: <85897ca5-77ae-4b05-89c2-8b1619845c48@suse.com>
Subject: Re: [PATCH v1] xenbus: Unregister reboot notifier on init failure
References: <20260807032326.940377-1-dbgh9129@gmail.com>
In-Reply-To: <20260807032326.940377-1-dbgh9129@gmail.com>

--------------8ROkd0MUYfh0EpH70IIJUEeu
Content-Type: multipart/mixed; boundary="------------eLAxOCDRsSM0i99I3BJZHq2J"

--------------eLAxOCDRsSM0i99I3BJZHq2J
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDcuMDguMjYgMDU6MjMsIFl1aG8gQ2hvaSB3cm90ZToNCj4geHNfaW5pdCgpIHJlZ2lz
dGVycyB4c19yZWJvb3RfbmIgYmVmb3JlIGluaXRpYWxpemluZyBYZW5TdG9yZQ0KPiBjb21t
dW5pY2F0aW9ucyBhbmQgc3RhcnRpbmcgeGVud2F0Y2guIElmIGVpdGhlciBvcGVyYXRpb24g
ZmFpbHMsIHRoZQ0KPiBub3RpZmllciByZW1haW5zIHJlZ2lzdGVyZWQgYW5kIGEgbGF0ZXIg
aW5pdGlhbGl6YXRpb24gYXR0ZW1wdCBjYW4gaGl0IGENCj4gZHVwbGljYXRlIHJlZ2lzdHJh
dGlvbi4NCj4gDQo+IENoZWNrIHRoZSBub3RpZmllciByZWdpc3RyYXRpb24gcmVzdWx0IGFu
ZCB1bnJlZ2lzdGVyIGl0IG9uIGV2ZXJ5DQo+IHN1YnNlcXVlbnQgZmFpbHVyZSBwYXRoLg0K
PiANCj4gRml4ZXM6IGZkOGFhOTA5NWE5NSAoInhlbjogb3B0aW1pemUgeGVuYnVzIGRyaXZl
ciBmb3IgbXVsdGlwbGUgY29uY3VycmVudCB4ZW5zdG9yZSBhY2Nlc3NlcyIpDQo+IFNpZ25l
ZC1vZmYtYnk6IFl1aG8gQ2hvaSA8ZGJnaDkxMjlAZ21haWwuY29tPg0KDQpSZXZpZXdlZC1i
eTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg==
--------------eLAxOCDRsSM0i99I3BJZHq2J
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------eLAxOCDRsSM0i99I3BJZHq2J--

--------------8ROkd0MUYfh0EpH70IIJUEeu--

--------------GZiVdMBhiTJ209aQF9aZo81v
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp9oJAFAwAAAAAACgkQsN6d1ii/Ey8a
vwf7Bw0Y1q++So0vlIT9kQ0dx40Luac4OM8d5KGmGM9FKV0oWhoOdUawa+lSV8lKK4t2oZLyoQxV
k8BN9GjEsBA7gDOCJG3N7bTzCAprOiueREcq301aW2BToLyfLrG0rmO7ttwn0seqZt2308TutPha
A5u+Z+BIS16tKOcdd0d/j7s6adRvxNq0bo9mCeus5v1pKXhVMihXtJRKcAjhg7UDUzLvJkgo4gBu
KA2xbr/A5NV+2AQPL0cMTzMGy7q3h3FvnHnZl6psuQFYysq5SQiqJAMjzvEyb9gFu13lDq8pOXfi
4vpLgVpEor/UaJ4IHVT5iOcRIU/+zErqQv12IQiu7Q==
=bs0G
-----END PGP SIGNATURE-----

--------------GZiVdMBhiTJ209aQF9aZo81v--


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 10:57:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 10:57:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389791.1630416 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuT7L-0001yp-EM; Thu, 13 Aug 2026 10:56:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389791.1630416; Thu, 13 Aug 2026 10:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuT7L-0001yi-B2; Thu, 13 Aug 2026 10:56:59 +0000
Received: by outflank-mailman (input) for mailman id 1389791;
 Thu, 13 Aug 2026 10:56:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuT7K-0001yc-Ay
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 10:56:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuT7J-000d1j-JR
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:56:57 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7da2dd-bab6-0a2a0a5309dd-0a2a450bbd6c-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:56:57 +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 <oleksii.kurochko@gmail.com>)
 id 6a7da2f9-b7e8-0a2a450b0019-d155802ee492-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 12:56:57 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso14071745e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 03:56:57 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981b03e70sm65595265e9.3.2026.08.13.03.56.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 03:56:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786618617; x=1787223417; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=w8tZY1MJk7duy9iK7oKaGRxHeYhvpqf9/RuUCJ7FDHs=;
        b=mEQroc2NKz6oWg1hqsKN9/7vCm6MOK9045FBYWmPfkW7cXtnFFYtRvLYB8duvzuPgi
         xC6rrQ/T3ygTc1ViirsF504g9Mf99yNo9iKFNenutbwRGOLpnSilZSng8+c42I88Z1kn
         CFsIO2TfOSMjuXHWyGt6031f79GKDmub2XDrf0A1C2Wg3M1leBp8AZ6OHdayi8AT8B6G
         6YHjsJY9gfOpRROXXZRrDFHQg4h2Dc7yfS/yEUhu0Y36Wg8u5UFhdHztgTLEZTiHdv7r
         4KbR95QksKN3FgM5XSNL34d3bqw2QafEeXXF/GLqV9az/1VeMS65I2IW2I2+MaHYnJm0
         5VyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786618617; x=1787223417;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=w8tZY1MJk7duy9iK7oKaGRxHeYhvpqf9/RuUCJ7FDHs=;
        b=lr0W8S1PJKyV78aY1PiaaY5VX+AupjF0LL0fICFp1CgvSN8d7QpnzqWgTWAW4NeqRH
         IE+UW8KH5ItDzKmJNw1VpFTKSXTDCWuNb10kL9dOHo/m6BL6qeNABIsuwMif33nXpVQy
         8rn+uNs9d1vTey8slV1yCDOfBrdxSrHmYcm+7IIHFGIxdnw50u3vvPnR4+SaebT2/eTr
         dsuryaE1tlhsjiNd8Ljh6S8mM0zdFxsBeFrefX1IxpBNvy4rrabBwtoowM/IU0GEYB9u
         VPVC8uOpyDQXFImmx76X+EcL7/p48ncuRJTClOjRrnJrPlL61Zq3NiT6PJ270qyUvk6G
         TyUg==
X-Gm-Message-State: AOJu0Ywjr8pL8395SA8mbDaDYA62XwT+WpIQNxpuUsfM9CsMwc0mM+lY
	/jL8P9Fe4T/H31myGB4yQars/OZssIxDOkDTL4idMWrzR6P6Q6rqfirY
X-Gm-Gg: AR+sD10Eje7y6klV7Po2zKX6m/LaUOhc6p5DAV3OsNKoExGV8/6bdqfaww7rda/BTE0
	Grf17oVkPq7JpTOdT93dQ8JWJ+VEbZ/Xr/8EMjGgubnB8ERV84OYcSzxNjJBvOXv4lyMt35Hix3
	CbYY61jdd1X125EMKPsSCcobnWTF/dtp5TMSSo4zHsjswXtqgUIYUMcLXRaYYCTRqdm1ybozbuz
	jVL2fX+4n9t2nT11pRE4lw/XmhDHcqPvSQ0P2KfgUO+1EhE4xI9UVHEY/b0GNmWsMjbvG2wgry7
	gSmq/CSVgG3cLynJSRRJQNwkeZn3gqLxbVT1JKC8TaEbveaA1CRZL+oSWuR+gxKxP/+MnRADxZJ
	HTpCGlsudnlceW0jvZXqrlIW/L7zfuKLhp8FApZWxoDLc1L9+QpIXw7RH0u3XPXMMWdFVpgbmb+
	eQlkUs7I5VHZFS7hjIz2Pf1OsUjAYKSouz70B3iLd8h6e0CW3if8bWRLtoZ2HCR5+ChCH/FYwh2
	aVIF4YYrvGX3BXchuCZJebUc04BiXbQZsYE4wNT9cwn79kmddEslg==
X-Received: by 2002:a05:600c:4690:b0:499:7410:545 with SMTP id 5b1f17b1804b1-4998218ee77mr56335695e9.12.1786618616905;
        Thu, 13 Aug 2026 03:56:56 -0700 (PDT)
Message-ID: <fa8d8a9d-04ce-4ce8-80e0-8164fea774ff@gmail.com>
Date: Thu, 13 Aug 2026 12:56:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
 <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
 <82011389-489e-4076-9d3a-8c393e4a8e76@suse.com>
 <bf2c9455-dd88-444a-8a94-a3a519d951e2@gmail.com>
 <a88930bc-e11a-4da1-b545-9474b5295d84@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <a88930bc-e11a-4da1-b545-9474b5295d84@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786618617-A82F49EA-6ED33CAD/10/73395122804
X-purgate-type: spam
X-purgate-size: 735



On 8/13/26 12:44 PM, Jan Beulich wrote:
>>> Also, can both of you please adjust Roger's email address when replying?
>> Could you please clarify what is wrong with it? For example, in this
>> patch series:
>>     [PATCH v2 0/2] vpci: allow unaligned accesses by the hardware domain
>>
>> This one is used: Roger Pau Monne<roger@xenproject.org>
> Whereas in your mail it was still Roger Pau Monné<roger.pau@citrix.com>.
> When you originally posted the series, that was still correct. But in the
> meantime it has changed (and I expect sending mail to the old address
> wouldn't reach him anymore).

Thank for claryfing, that e-mail was added by ./add_mainterners.pl so it 
returns incorrect e-mail...


~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:04:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:04:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389804.1630425 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTEh-00043t-7B; Thu, 13 Aug 2026 11:04:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389804.1630425; Thu, 13 Aug 2026 11:04:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTEh-00043m-4L; Thu, 13 Aug 2026 11:04:35 +0000
Received: by outflank-mailman (input) for mailman id 1389804;
 Thu, 13 Aug 2026 11:04:34 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuTEg-00043g-7G
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:04:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTEf-00FSq7-Gr
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:04:33 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7da4bf-2eae-0a2a0a5409dd-0a2a4503c442-8
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:04: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 <jbeulich@suse.com>)
 id 6a7da4c1-fae8-0a2a45030019-d155dd2dade9-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:04:33 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47fe377a217so1221588f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 04:04:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5af441sm6217610f8f.22.2026.08.13.04.04.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 04:04:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786619073; x=1787223873; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Bd+Zntht+ldhKQihKRW1iwzhN5kFLSBmJy8vG/MddVY=;
        b=DYpcJEfVW0hvmqVgN9mkUImhg81teJdtkzqo2WTYXZr4DSUWUWbW1OtF9hXqIvS15n
         0Kp7Z174u9AsgxGjy4dFlprD7Ol4T2qloIQMr7xjVYqukJDIvBzUl9a5bKFEnqCB5FCQ
         C8h/NGBBDMmJ74fYBU6rJUbXQqNUTRF7SF0Yb3XiIKcj0u3yorP2cINcGQ7oUrA6pkhe
         wDdUstRKaiebWxEgtKMZprPKp8dZMJF138r2V1bAgqEeyGgc3v8IhhGAge48Wv+gWpYJ
         DQPPCv6Ha45+FloqP1DZIC5rgQIeSJWa8jRThWzur/hDhWNqWBcHrI2XACHzhwMhyqaY
         NygQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786619073; x=1787223873;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Bd+Zntht+ldhKQihKRW1iwzhN5kFLSBmJy8vG/MddVY=;
        b=j7Yavb9zm1T+8+uY5PLo0p1Wdcfq8TVKgKjEGBBZPEdJxZuB/5N9/ea+spWSLv339P
         b9jxwjYiKBAumNTuavfIlGi7+ZR6Bqq8qcQOPnhOjZnm7fJIvi+XNSWUrCMW/PZdfMSI
         LV0Mr4GQpBHvT7c4U1uUEFXm6tK84TsleL4X3LMoeyOh3lWIm0ST7KWJHknuLscnVFNG
         mAG8pMR1MMK0VE2e1yUJn+NfUlAm1JWQdSM4u4r6d6dvinU+IXoX/m2nbxGhl/X6cpQd
         /i3fxmDFg9xnUz/KQOA0ZLC3OGnBZNgnZ22qkobHLyfyQALB0ktvROq6b8q8RU8pu0GI
         DZCA==
X-Gm-Message-State: AOJu0YzTRHnsEtd84gmdT2vdHFccv+VazZ+px8rfl/wrcxFYw2jc8rNF
	8NJob9U/Xupk5cgwxke0oy/Ep9xrVKodtW8d8P+meiJC1hdfFw2wyX0k4MNTlCqOhQ==
X-Gm-Gg: AR+sD13PHuygeONXJgMVeFxyD/7uhqC5c63API+Awgzcrdf3KvdV0qOFWMDfkkwE767
	uqPjOfGzt+AkxXevMlPPRxcL6eSEQeyD1r+7DG8U6Pe4Mp8MyA419f5UcicIXZDsoDcusyEyS/Y
	HCVDGT34aC8Hq1ERZJkKt3UKEQRyUaIv43HMBdgrUiuJ7ksogNa1noI/W2OWyCQ3j8F6wAYQxUP
	kGzULPGdQvRbfkMi4YxIvorE4h4tSkP2Tv6XaRDSc5zEwFbh4qxKShXmYBiDbRaY06LEOWwZB2l
	2WMN0eHY4RN1kPTXctTi7pCkZx17UzP0QVJY9mHlU8hj/nhxYG60FovkGROgJE+CV9U1Y4waHnq
	Ie2JACJYEvumXUZ++a8ocVW2+XCZOqul5NBxAAYaQjQU2M38FcdH1Kc37lBCinFIJj2yRmwI2oo
	+8csTxnzchv99uN4PKhsF/D+yViPspK6wOwctn5gF3PMcuzRUwP7DnrCNvnXbT4kQeXkCEZBQFa
	PkHx81tFJka6RnhsInuIHzY3VR6CC6qi6jkuMTOTJPxEU+YlHeD
X-Received: by 2002:a05:6000:144a:b0:481:98d:b24 with SMTP id ffacd0b85a97d-48159eecc97mr7251160f8f.19.1786619072878;
        Thu, 13 Aug 2026 04:04:32 -0700 (PDT)
Message-ID: <988bf876-e30a-4dcf-9935-ffe7e1b82920@suse.com>
Date: Thu, 13 Aug 2026 13:04:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613430.8631fc262581453bbf619ec5b2062170.19ffa7577c9000c4f3@vates.tech>
 <9724c838-6713-4f29-89ab-54f50ec4fe8e@gmail.com>
 <82011389-489e-4076-9d3a-8c393e4a8e76@suse.com>
 <bf2c9455-dd88-444a-8a94-a3a519d951e2@gmail.com>
 <a88930bc-e11a-4da1-b545-9474b5295d84@suse.com>
 <fa8d8a9d-04ce-4ce8-80e0-8164fea774ff@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fa8d8a9d-04ce-4ce8-80e0-8164fea774ff@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1786619073-6E8CD4E9-D6708A63/0/0
X-purgate-type: clean
X-purgate-size: 1078

On 13.08.2026 12:56, Oleksii Kurochko wrote:
> On 8/13/26 12:44 PM, Jan Beulich wrote:
>>>> Also, can both of you please adjust Roger's email address when replying?
>>> Could you please clarify what is wrong with it? For example, in this
>>> patch series:
>>>     [PATCH v2 0/2] vpci: allow unaligned accesses by the hardware domain
>>>
>>> This one is used: Roger Pau Monne<roger@xenproject.org>
>> Whereas in your mail it was still Roger Pau Monné<roger.pau@citrix.com>.
>> When you originally posted the series, that was still correct. But in the
>> meantime it has changed (and I expect sending mail to the old address
>> wouldn't reach him anymore).
> 
> Thank for claryfing, that e-mail was added by ./add_mainterners.pl so it 
> returns incorrect e-mail...

No, I don't think it does. See commit ed3df2522ac7 from 2026-07-21. Your
series was sent a day earlier, so correctly with the Citrix address. But
when replying, people want to try to remember to switch stale email
addresses (in general; Roger merely happens to be affected right now).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:08:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:08:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389813.1630435 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTIQ-0004dX-Me; Thu, 13 Aug 2026 11:08:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389813.1630435; Thu, 13 Aug 2026 11:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTIQ-0004dQ-JB; Thu, 13 Aug 2026 11:08:26 +0000
Received: by outflank-mailman (input) for mailman id 1389813;
 Thu, 13 Aug 2026 11:08:24 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wuTIO-0004d1-PK
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:08:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTIN-009DCR-TP
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:08:23 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7da591-bab6-0a2a0a5309dd-0a2a4505bcb0-38
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:08:23 +0200
Received: from [40.107.208.37]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7da5a6-4cb1-0a2a45050019-286bd025e58c-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:08:23 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PH0PR03MB5943.namprd03.prod.outlook.com (2603:10b6:510:30::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Thu, 13 Aug
 2026 11:08:19 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.014; Thu, 13 Aug 2026
 11:08:18 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=K304yXvN0DbrSsP/Ph1r3Z0SrbowSVfhJCULuowEZ8yWx5hlix1bRwFDj8eQXJtpoKgrQ0gVCqmDubfyQhnKhAwEXajC/gT3K0vRnYiOIM0VzuATa1aU84+spcvkccx4XKhZmAtXKLtU5zWKG3tMiS1rT3gDCLZfFUD9u6qbRkRZxyMw41RaGHQaW+2UZLQV8TMXylR7Btv+ayvVNhT+a+Og7o/KdWcSUn2k2jIo0HKRoO/rxFRculTKKb4zCR4kIzmRjrPXb5LFk6oP5WQzcRqvP9Jko/bBMva5n7V2Az0VIRqZLJxgkdhC90CSHl3rt0etgD2LYzcdjvfNbQScCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fP4Dn4jJEnXWShuvzhONrYUAYiSFmhWmuI9URrlL1xc=;
 b=lVI1RGryOAwSbi5OzenhhsuIUtZ00QZyyCYl12wG5ej2Mdk30jCxp2eOmdEpNxURbDQ9uTQD5DqXgGVED+YXZIuMo5lSgpw5z7zDtL8QJVErGT0MLUAPMniPaT1Z4OWU2sOotvm5xO/MCKWly4pbk+O1mUP84WkKEPEXsaf4fFarA9jmFm70oxL4PUxtT6J7rOYfpqhflRLW7A1gFs+ZWCI7B9FigSxQmgtI/l0V+IvN2hGb/gIvNTrvT3taEVsnvx750ENzaFXxe2pZI27OBz+1zi4ZuYAQyUXWqMNUipi5PEJmTSAjh8s9WFgNs+LbzdulwZjTHmrMDXrnBL+8iQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fP4Dn4jJEnXWShuvzhONrYUAYiSFmhWmuI9URrlL1xc=;
 b=AytohIxFfP6RDPtSmMDajELvS48zQZIH7p3uM20ifXwsGRpZCXej75GWsx/C7aGt1pxDwq8/65y/WJClZJ7Tyf7LFr6mrR5pFQDZkLVYYxReTC7hIDIRvf4lHdA/3MBUs2EH71qPJeJB85lNKUMEjSAO4Om5E5Lyaz9nCRfaooc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <d41d0fa2-7273-4723-a5e0-6424d030cf0a@citrix.com>
Date: Thu, 13 Aug 2026 12:08:14 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich
 <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH v10 2/10] libs/guest: move batch_pfns into a separate
 structure
To: Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-3-frediano.ziglio@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260810103018.54564-3-frediano.ziglio@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0317.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:197::16) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5943:EE_
X-MS-Office365-Filtering-Correlation-Id: 4ca0d4b1-8cd0-486f-0c27-08def92b2e0c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|22082099003|6133799003|4143699003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	3hlIQ6rviX5XzZxzYzJ2Dlhh1L7muI7A7OklvgYMnKMN0PMjVMuFA/2pye8GfXMUH67Nb2rBI8vq/587XCmOw2dz4qY0J5rPSuXtP42Eh/X49uMeWXou5u9W+WhjsaFVMKuJYL0fGFEC5Kk4NsPvBmYSHZpuy/gfTNnrvSOR/Atv+C0J1J7tHImxkFDp+weO2BQTsYRbFmnuLvI7ImWtmMFb6k8yPd2EWgYPFvQ5cqWGtt6XbA7BWE83MUVdclAneP62ZfQRJoHokpWHYRCz19VX8U/0ZjGYWCBpaCziFuYjvZ0OohIVjEjv05RaehqaxDvbjZR9fAtC/naOuh4OhYduZRRVRNg3nstKSm/OpoH17onYHcb3vAgpNqQJV7atNe7zMSOSV0JRg06YPAXEORIq5eActSMSE8nq6kCmN1843eukevRjar6GiThvViHBYGpada2Qqzd4m4CWlJ7yKLPzML5jeFB31snLLTCrczFMQtNyrRwfJgI1gUGjZ55C3y8KxNn/CwvNBYiuwxUp9RCZQiD4J2E7icZWKhDh3DE/Ze678whCvhBu7u82Mg/jox1KoVu6fMLstf/mL/jCAxEgZVXNmVucj8hJzwSZ1MeV8RUHycp6i5eB283ztHE1KsHaEsx9lvB7d90yCV+zIW+C1fbfT3Xth9kbMkMsMKs=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(22082099003)(6133799003)(4143699003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?TUxIbEhZSjZpelNsVkUvRzNFcU1ueWVrZ21WbFRSR3JrcUgyaytqeWZJQ284?=
 =?utf-8?B?RHVJSVVac3F2Z25qcHpkTzVsVFdvSnRCc2JHZ204TkN2blFvbklJTzd0ay80?=
 =?utf-8?B?TER2RUs1cml1WHdBZCtjaUV6UU8wN1doelpTUm5RUG4ycTZEKzE2cHFYelNF?=
 =?utf-8?B?U0x6RzVzcktUVHhHSDl0YTVqNGJMaWFRSlh2WExQc3JNV1V1TmlKSVJkQVkz?=
 =?utf-8?B?OGR5OW1ZWkxxY1N4Yy9tS0VYWmswSVQ1S1llWm5mUnhXVjdmODhMbCtWblVm?=
 =?utf-8?B?WjBZZUZZSHZ4S3pHREpvUzV0MXVnZXVtaHpTWm1GcEplbUVCMXlUQm14Yisv?=
 =?utf-8?B?SjQ3b3gyeVg3UUtMdnR4bFNMdm1YL2JmY1dLbVlyMTBQTkdoNHpUQ3B0SU8y?=
 =?utf-8?B?TTdVSnZ5eUU3VmRjSjVZd0tKd0FiM0VYdHQ3dE1pS004dlVFUFFOM1BGa0Yz?=
 =?utf-8?B?QWR5M3RJVUhsNmY5WStUUWFmbFFONWFLUTBJZDNpOWpEN2R2ejlFQnNzVVNF?=
 =?utf-8?B?SnRVelkxQytXLzV4NmVYcVJhVkRIM05uQXB6b1Evb1ljeVpVL3hYTFM5bFE4?=
 =?utf-8?B?Tit1aXc4K1NIcTR3cTdtYkhwVlFsRGZkL1BpRktMVmlqRUNqS1BBeGs4cUZE?=
 =?utf-8?B?NDU0anpKWkNLekJVUE4rVElKMFgzYVBxMEsrbmJNVHU4RDVhUC8xZWQwVms4?=
 =?utf-8?B?U3pieFZLUFMzMENGVzRzazF2b3doZlZzNTR0VVFQVUdNdU9oMUhhWGx6OThU?=
 =?utf-8?B?S3p5SkZYbk5kaXg0aXI2TFlnQW5vRXI0MnhLelE1RitmQWdBOUlyQjdWVGth?=
 =?utf-8?B?V3VWMUZMUXZpdlV6Z3pxWExzMThzRjRJbk5vRy9xb08rREY2cmtvQ3RzR2lH?=
 =?utf-8?B?Qm9yQjVORnpoQTJpWHY0QmZLdG9rZC9BcjFMeHoyOWlMRXVVQlhyd1dyeTNv?=
 =?utf-8?B?cGxlU2crclVoOGl1RE9GM1FYME5sUFJqN3Voc0c3SVlZRWMyRUNsbzd5UDdQ?=
 =?utf-8?B?b0hRL0J4ZUdERTkwWVVxeUtnY3RBZm9WYzA3S2Ftd0s0WFIrM3ZIejlXTWw0?=
 =?utf-8?B?a3U5R1R0b1h0RzlEaWhuK2IvZ2pZLzFERFFNTEwwVWsrd213NGRWR1cvYm9q?=
 =?utf-8?B?eHFLaGh0VGxCcHlaLys2Z3lPZERicWtveEw1cFBJckRzYWFmWnRDZXQvTTYr?=
 =?utf-8?B?SFh0YUJRcXlPd2ViQ1hBbXpoOWp2c0VpYi8rL1crSkVJUVNlK2xXL29qNEx2?=
 =?utf-8?B?T2tZMUdlTVBhU1EvQ3lZcm1DWXlPU1dXbzk0MzhZNmVMa090bWY4ajJIbDc2?=
 =?utf-8?B?eUFwZFRuY010RkdlUWsrYjA2VnZIYlppZGNSZ29NZFUza1JtSmZ4cDBMYjFs?=
 =?utf-8?B?V3BXKzB2blk2L3BDTnN2ODFYVityN1FoVExQMjc1TjU5TXE4dGhpSlRPUTZz?=
 =?utf-8?B?UzNhbDJEeUI3Y3FJLzJJenBBelROejJYekRLdklnYkFDcXFOYnVwRElTQVp1?=
 =?utf-8?B?ZnpBUEZ3dVI5TWp0eWNzZC9NdnRPMGhiWUdYdkZKRnRmOFZtaDducitnNGtW?=
 =?utf-8?B?Y2dFM2pDeVJKZXJyUkQwbm4rdEgzZU1LOHdxZFhMdWhtSTZjQmtacXU4OXhm?=
 =?utf-8?B?bjdubU1iblY3VkxFRDJsOTBSbU9WWlU4NTFIOW1CZ2xBazM0MWhjSTg4OXZ6?=
 =?utf-8?B?M3dsZmE4OERiOTdUTGtlYVlQcnF3Mk92c1hOa2haOEdEWDhBby95S3V1aVRW?=
 =?utf-8?B?dmVseFJoYVZyRGp5NmJOUkJkRXNFbUNQTWxGa1BxWVVkWFhyYzVNV3dFdVlD?=
 =?utf-8?B?clBVdVdaaHNRWWxLVEduWk82bDA1Vi93dUhERmhQeXY5aVB6WnlNa1dhVTZG?=
 =?utf-8?B?NDRla3AycEpwMUw4VFJ0MlpuOTJFRWlDVXZmMGk1L3NVYnlkU0U0M1Y2dGNp?=
 =?utf-8?B?UzNQenlmbklzaDZHTWE3eHN0SFlZRUlsNjJSWWpycDJzeFVDMGhYcnNicVl3?=
 =?utf-8?B?OHlKM0JVdXpGblBZRnl1VXhud3pQSXc1UDRrSkdqY1BPN1RDVlI4QUpKMGR6?=
 =?utf-8?B?T2FmY3d3MlNLRjB2ZkRpV0ZkNXlLMXZIV0pOWDhpSWpheVROZmgrWk9DVzZK?=
 =?utf-8?B?VTluejhkY2hXZU1CdHVYMEF0QUF3RkNzMGlnak1odFhGenU2R3Q2dnd6WW9V?=
 =?utf-8?B?di8vc0FadXN0TlNVYTJBdWF4YnRiUmJJYkdKYTdTbjF3WU1NVTRZMldyaHBP?=
 =?utf-8?B?Y1hITG0zdVRaSWxQLzk2dnpuaDNHemlvNXcwSEduYWNVYThnYnhDWG14UXQ2?=
 =?utf-8?B?UjlhTmpwZ3hpSUpOZ29TOXBrSHBQcVJnTk9ZMDc2Mk1JbVNEaDFlUEx3cklj?=
 =?utf-8?Q?5gyAfHtXkHkH/m3M=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ca0d4b1-8cd0-486f-0c27-08def92b2e0c
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 11:08:18.6530
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cyAvn0a+3+Q/IhF7uVRRXSZwIALgzyHvrr5N77Fh0FSPZKLAbsgcKFcxkGWE56KciCTtBf4Q65Eq5aK3R3h66Z8PNVZaVVKtG2qatbsqWOs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5943
X-purgate-ID: tlsNG-c201ff/1786619303-714AC2A1-88F47882/0/0
X-purgate-type: clean
X-purgate-size: 1507

On 10/08/2026 11:30 am, Frediano Ziglio wrote:
> Preparation for a followup patch "libs/guest: allocate various migration
> arrays just once".
>
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>

Coverity thinks this change has memory corruption.  I have to admit that
I'm not completely sure why it's noticed now; possibly because now it
can see the size of batch_pfns[] where previously it couldn't

** CID 1700057:       Memory - corruptions  (OVERRUN)
/tools/libs/guest/xg_sr_save.c: 284           in add_to_batch()
_____________________________________________________________________________________________
*** CID 1700057:         Memory - corruptions  (OVERRUN)
/tools/libs/guest/xg_sr_save.c: 284             in add_to_batch()
278         int rc = 0;
279     
280         if ( ctx->save.nr_batch_pfns == MAX_BATCH_SIZE )
281             rc = flush_batch(ctx);
282     
283         if ( rc == 0 )
>>>     CID 1700057:         Memory - corruptions  (OVERRUN)
>>>     Overrunning array "(*ctx).save.buffers->batch_pfns" of 1024 8-byte elements at element index 1024 (byte offset 8199) using index "(*ctx).save.nr_batch_pfns++" (which evaluates to 1024).
284             ctx->save.buffers->batch_pfns[ctx->save.nr_batch_pfns++] = pfn;
285     
286         return rc;
287     }
288     
289     /*


~Andrew



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:27:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:27:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389829.1630442 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTaV-0008C9-4D; Thu, 13 Aug 2026 11:27:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389829.1630442; Thu, 13 Aug 2026 11:27:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTaV-0008C2-13; Thu, 13 Aug 2026 11:27:07 +0000
Received: by outflank-mailman (input) for mailman id 1389829;
 Thu, 13 Aug 2026 11:27:05 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuTaT-0008Bu-61
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:27:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTaQ-00H6uI-VD
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:27:02 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7da9fd-8faa-0a2a0a5109dd-0a2a45059ece-22
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:27:02 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7daa06-4cb1-0a2a45050019-d155802fcd62-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:27:02 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-498028b3d5eso6681495e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 04:27:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981b62894sm56065245e9.13.2026.08.13.04.27.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 04:27:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786620422; x=1787225222; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LF1FxIO16lZ95Yvt+36L44TtVDGW1s2HRYpmZYcZF7M=;
        b=Ffrhhj1vk2WlRHRXWQ874NayK0DTpcNgjnYt2bE5rCIzumTX1tmmejQaMlRv/QEkWT
         GLfuMzxbLEWkVmTexibIIjxk1O25fQUulmWtReImrf8MDmpIPRFPRVVaXU/mtDiauwQm
         sDQ+Syo5uQSn9h8bVBAeiJBFxycU+CVPHpfxtvOhR5eY7p8M8bdvlSYYkVuUNhPtIjzp
         +48rAwG/ZhrTPgG65t3S2otQzCqR0kFYWYsFGbOHyw52r61reJrqGR0O2p4qdQEHWDsa
         TxPpHNSLO/P1MFe9m3WoI+ecMF+vex3/lTaV96LgZu0/6bWQmR9CDJwy+1Zz0ERTDXxb
         WWzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786620422; x=1787225222;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LF1FxIO16lZ95Yvt+36L44TtVDGW1s2HRYpmZYcZF7M=;
        b=Pi6ukTlYGjilE2scAd0SV5Rq8oPFdnjwHH3fTy3I/dUPAKAoc4VzhnzndlqnP3E7U9
         GKaQuz0l4y9P2y4662OK+RBOt+v3CXSdz3ob2CyeZbozmX8RU7m2P7PjfPPZNT+ZxlwB
         /sw3jdKbqIq6TthtI/gHjnfF/ealjRP5D7sN84wOKh9GjYfU40hGITqggnYDZxADarz4
         N39r828CBYELHmvueWlRfvxvS8YQjbTsb8wJI/beZ8wr7/UHtvlRHr7OakcnNeNpahcX
         LvGHnErNMHM14+ZbPwqKtjbckodEhO41VcBoog2a+p8LrRYHufAU1MspdOPWr8uXc+gg
         Z27A==
X-Forwarded-Encrypted: i=1; AHgh+RoQSm7T+aMRantJdTE6sI91J/hnPz5eeYAdjjb7BH2bSQ8W22Zzx7GunbxBt2tiC+7JxQegLcGkfzk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlUl3fj2nt125WEaocq+t/Ckt1Nl7EZIgxFOfbV/fXVG5k4BEm
	BW1bidvzWJf79stvQ0jZXIOH0PR9LqeabWGKmLqPL8zQDNp/qzWTY4ntWzJ4jMVqIA==
X-Gm-Gg: AR+sD11ReNHpYpUH+gcl2xllnvc34N8wQmaefMbkFN6GvY2WA213dEaF6Z4xesHBI9L
	AESYPX8dT3sYT60u2FLJvjvVfq8f1+C+l+PubtzriYIB7N2v1IjuBvn2z3iv0imufgfXDFdeYOd
	ahZD9NeETff4SPT0sZoZpQhE9t8aM5Nt830tr5+CqiL5a7vwuSr5RWJoJzAob6FcNuiPzfU1ACO
	/zX6dh5LRiIdwD8hRsHNRtKmR6G7jTqhhKZg70sfRuTnLq0fuR3SAHSOO/0/d0bee1UTeu0ZPGv
	qQFejKrZkxwhU7MGuhgF4zzaj8yq9hrpFfYrnjWrFANF7rBifzRJpBAa8cR0VtVFWcWw1u3yLOe
	x3SnO2wyOFu8yG/i6Y8MWYJRh5jLDTWFzMAKt3/2xK5RSlx3sHx/YrYuX7YyTEurCx6nhv1K8tC
	bZzPEae9j2W6ApKvAYSJLZx+UOFllz1YCZl9d65bI9+IqVjGAR7LKVR+xwTgZz/kTu60Ihmcv9K
	3y9pCYRxwVUVNh3b1NJE89N5shMJRPdT1rHFa0blSAdoVqJudD/
X-Received: by 2002:a05:600c:1c07:b0:497:ff73:68d5 with SMTP id 5b1f17b1804b1-49982108004mr62463775e9.0.1786620422371;
        Thu, 13 Aug 2026 04:27:02 -0700 (PDT)
Message-ID: <1101df6e-bb36-4766-9b11-365d1043342b@suse.com>
Date: Thu, 13 Aug 2026 13:27:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 2/10] libs/guest: move batch_pfns into a separate
 structure
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>,
 Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-3-frediano.ziglio@citrix.com>
 <d41d0fa2-7273-4723-a5e0-6424d030cf0a@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <d41d0fa2-7273-4723-a5e0-6424d030cf0a@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1786620422-F52A32A1-0462A273/0/0
X-purgate-type: clean
X-purgate-size: 1823

On 13.08.2026 13:08, Andrew Cooper wrote:
> On 10/08/2026 11:30 am, Frediano Ziglio wrote:
>> Preparation for a followup patch "libs/guest: allocate various migration
>> arrays just once".
>>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
> 
> Coverity thinks this change has memory corruption.  I have to admit that
> I'm not completely sure why it's noticed now; possibly because now it
> can see the size of batch_pfns[] where previously it couldn't

I had looked into that too, and I'm puzzled that ...

> ** CID 1700057:       Memory - corruptions  (OVERRUN)
> /tools/libs/guest/xg_sr_save.c: 284           in add_to_batch()
> _____________________________________________________________________________________________
> *** CID 1700057:         Memory - corruptions  (OVERRUN)
> /tools/libs/guest/xg_sr_save.c: 284             in add_to_batch()
> 278         int rc = 0;
> 279     
> 280         if ( ctx->save.nr_batch_pfns == MAX_BATCH_SIZE )
> 281             rc = flush_batch(ctx);

... the tool can't spot that flush_batch() resets ctx->save.nr_batch_pfns
to 0 in the success case. And ...

> 283         if ( rc == 0 )

... only the success case is what matters.

Jan

>>>>      CID 1700057:         Memory - corruptions  (OVERRUN)
>>>>      Overrunning array "(*ctx).save.buffers->batch_pfns" of 1024 8-byte elements at element index 1024 (byte offset 8199) using index "(*ctx).save.nr_batch_pfns++" (which evaluates to 1024).
> 284             ctx->save.buffers->batch_pfns[ctx->save.nr_batch_pfns++] = pfn;
> 285     
> 286         return rc;
> 287     }
> 288     
> 289     /*
> 
> 
> ~Andrew
> 



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:27:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:27:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389834.1630453 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTb0-0000GR-Fl; Thu, 13 Aug 2026 11:27:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389834.1630453; Thu, 13 Aug 2026 11:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTb0-0000GI-C3; Thu, 13 Aug 2026 11:27:38 +0000
Received: by outflank-mailman (input) for mailman id 1389834;
 Thu, 13 Aug 2026 11:27:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuTay-0000Fy-UB
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:27:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTay-00H70j-Au
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:27:36 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7daa1d-8faa-0a2a0a5109dd-0a2a450ad17a-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:27:36 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7daa26-f2d2-0a2a450a0019-888fbc3352c6-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:27:35 +0200
Received: by mx.zohomail.com with SMTPS id 1786620441386524.7328948269907;
 Thu, 13 Aug 2026 04:27:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786620444; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=fHqdvGRcb6wrzMOoIRam9IX4ayEptkdTGCKNWohYrJU4BqG1+mLBmvNybRkgz2QDjjWUvxQhpz2raE5OuRKjlUPUev55Jd4COXEMqMn2zwRq2g983fuXHmrDixmnPt96BtP4Grkc/6pZaNfYrCrLdZNgZ1Uhv+o0p3/ENmg/HrM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786620444; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=stczR2Ah1DqG8rzItUsURRBptW8wxv4DGN+dWLU5PWM=; 
	b=f7nZREIlTBdfZQ2a+41ctsjHonO3fo+Nc0xSTgLRQHq4grEOTb4Jyca/x3IMreewRd864SwT8mTbaN6v6DClaklhaNO3zqEibuQoA7SHKPV8ajl2/WH78yxPOAiMY+GpmKY7k3RXUVoZKdbnGwtd89iN4f/cUWzA5IvYT0o6Yyk=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786620444;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=stczR2Ah1DqG8rzItUsURRBptW8wxv4DGN+dWLU5PWM=;
	b=XGyH+lNHeovSvzwoFtikmvrvKs70gAFC0XwG1+qoeaDHV0SNRAI6Z2hOo7jgREiY
	HpDOuYQeJkGOy0sB+a9PGxfpbZZcwTaAWFDBezyMm3t7YnZY5IDStTPccugH+hV4NnP
	i538yNfSnl5TDtWCcBhwaJb79EG9tGObQXhzWD/4=
Message-ID: <de3d9929-d14e-4d51-854a-ed0c94801ea5@apertussolutions.com>
Date: Thu, 13 Aug 2026 07:27:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 23/24] XSM: fold xsm_{,un}map_domain_irq() hooks
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <e2e0a2d4-0b18-400a-a5aa-4507c1e8a7b2@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <e2e0a2d4-0b18-400a-a5aa-4507c1e8a7b2@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-4011c0/1786620456-526DECFC-9FFB6084/0/0
X-purgate-type: clean
X-purgate-size: 4794

On 7/28/26 9:26 AM, Jan Beulich wrote:
> Like other resource management hooks they are (now) mainly different in
> "add resource" vs "remove resource". Hence like in other cases a single
> hook can easily serve both purposes, with minor tweaking of
> flask_map_domain_irq(). While adjusting that function, also defer the
> setting of local variables only needed in the "map" case.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -100,7 +100,7 @@ long arch_do_domctl(struct xen_domctl *d
>            * done by the 2 hypercalls for consistency with other
>            * architectures.
>            */
> -        rc = xsm_map_domain_irq(XSM_HOOK, d, irq, NULL);
> +        rc = xsm_map_domain_irq(XSM_HOOK, d, irq, NULL, true);
>           if ( rc )
>               return rc;
>   
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2214,7 +2214,7 @@ int map_domain_pirq(
>           return 0;
>       }
>   
> -    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi ? &msi->sbdf : NULL);
> +    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi ? &msi->sbdf : NULL, true);
>       if ( ret )
>       {
>           dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
> @@ -2441,8 +2441,8 @@ int unmap_domain_pirq(struct domain *d,
>        * domain.  Skip the XSM check since this is a Xen-initiated action.
>        */
>       if ( !d->is_dying )
> -        ret = xsm_unmap_domain_irq(XSM_HOOK, d, irq,
> -                                   msi_desc ? &msi_desc->dev->sbdf : NULL);
> +        ret = xsm_map_domain_irq(XSM_HOOK, d, irq,
> +                                 msi_desc ? &msi_desc->dev->sbdf : NULL, false);
>   
>       if ( ret )
>           goto done;
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -470,7 +470,8 @@ static XSM_INLINE int xsm_map_domain_pir
>   #endif /* CONFIG_HAS_PIRQ */
>   
>   static XSM_INLINE int xsm_map_domain_irq(
> -    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
> +    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf,
> +    bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_HOOK);
>       return xsm_default_action(action, current->domain, d);
> @@ -490,13 +491,6 @@ static XSM_INLINE int xsm_unbind_pt_irq(
>       return xsm_default_action(action, current->domain, d);
>   }
>   
> -static XSM_INLINE int xsm_unmap_domain_irq(
> -    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
> -{
> -    XSM_ASSERT_ACTION(XSM_HOOK);
> -    return xsm_default_action(action, current->domain, d);
> -}
> -
>   static XSM_INLINE int xsm_irq_permission(
>       XSM_DEFAULT_ARG struct domain *d, int pirq, bool allow)
>   {
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -71,8 +71,7 @@ XSM_HOOK(int, schedop_shutdown, struct d
>   XSM_HOOK(int, map_domain_pirq, struct domain *, bool)
>   #endif
>   
> -XSM_HOOK(int, map_domain_irq, struct domain *, int, const pci_sbdf_t *)
> -XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const pci_sbdf_t *)
> +XSM_HOOK(int, map_domain_irq, struct domain *, int, const pci_sbdf_t *, bool)
>   XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
>   
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1063,12 +1063,11 @@ static uint32_t flask_iommu_resource_use
>   }
>   
>   static int cf_check flask_map_domain_irq(
> -    struct domain *d, int irq, const pci_sbdf_t *sbdf)
> +    struct domain *d, int irq, const pci_sbdf_t *sbdf, bool access)
>   {
> -    uint32_t sid, dsid;
> +    uint32_t sid, dsid, dperm;
>       int rc = -EPERM;
>       struct avc_audit_data ad;
> -    uint32_t dperm = flask_iommu_resource_use_perm(d);
>   
>       if ( irq >= nr_static_irqs && sbdf )
>           rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
> @@ -1078,33 +1077,16 @@ static int cf_check flask_map_domain_irq
>       if ( rc )
>           return rc;
>   
> -    dsid = domain_sid(d);
> -
> -    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
> -    if ( rc )
> +    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE,
> +                              access ? RESOURCE__ADD_IRQ : RESOURCE__REMOVE_IRQ,
> +                              &ad);
> +    if ( rc || access )

You've got this inverted. When `access == true`, i.e. the map operation, 
you are exiting here. When in fact the rest of the function is the 
final,and required perm check for map, but is now being enforced on the 
unmap operation where it is not needed.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:32:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:32:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389848.1630461 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTfy-0002Ps-0f; Thu, 13 Aug 2026 11:32:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389848.1630461; Thu, 13 Aug 2026 11:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTfx-0002Pl-UC; Thu, 13 Aug 2026 11:32:45 +0000
Received: by outflank-mailman (input) for mailman id 1389848;
 Thu, 13 Aug 2026 11:32:44 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuTfw-0002Pf-RN
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:32:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTfv-00H7r5-U6
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:32:43 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dab55-2eae-0a2a0a5409dd-0a2a4508e3d0-20
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:32:43 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dab5a-f659-0a2a45080019-888fbc335273-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:32:43 +0200
Received: by mx.zohomail.com with SMTPS id 1786620748906836.2619879631395;
 Thu, 13 Aug 2026 04:32:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786620751; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=E8QbpsG5rBg0+3mfZnmH7Hufa3kn2wZmrAz4MFqt7ZvcDyHGCqBg+CAGyX4IUZiviQ7XE6U9Z7VmykW0q5mafXe/qWZ6lZortUnPacadjDOa7mCiouMv/S668Eyr8Fy0O1xwy+VGg8D8n6G2WTzUWrHvdXTvvL1rUTRfntI7bNI=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786620751; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=KzQjx3T8ymqhNwfDiqzmKmkPXuphZZD9f7yVPKtNnD8=; 
	b=FEzM4Tqz9byet8G72Nw5LztHwJVNLNxP0bhVoVrDlBzGbX136gUZt39qEhEkKrcqg3Nu7fg9KPybcfDQqKx66uTud00L3NUjAqdb+ra9OCx5Zdp6CCsvoOMXnrjlislSBrH4FB8EAl8MATtrwjFZSlcuyx3x4PXSjv3/3PIPnRE=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786620751;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=KzQjx3T8ymqhNwfDiqzmKmkPXuphZZD9f7yVPKtNnD8=;
	b=n0PAdj0t5U2j0UUW+lnx4PIt2WRXCu1XtXiCtTu1EAQz7ueKAP0YoGBWiXAdW1BS
	uvERuG9/f3PvbaxTi8h9SwN3S505ibgqqyZAgek20PeCQ4C8kBzploITNo5GYw3tzYE
	xrkdE9ajOBNt3RmYxXKzujCAUGtAaNBCN0kItii4=
Message-ID: <2a04c020-1adc-4c1a-8d64-bc737781c1ad@apertussolutions.com>
Date: Thu, 13 Aug 2026 07:32:30 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 24/24] XSM: fold xsm_{,un}bind_pt_irq() hooks
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <03d4456b-9e85-469c-a2a1-769faad67bb0@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <03d4456b-9e85-469c-a2a1-769faad67bb0@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-c1860d/1786620763-CDF4787B-1E2E42E9/0/0
X-purgate-type: clean
X-purgate-size: 3923



On 7/28/26 9:26 AM, Jan Beulich wrote:
> Like other resource management hooks they are mainly different in "add
> resource" vs "remove resource". Hence like in other cases a single hook
> can easily serve both purposes, with minor tweaking of
> flask_bind_pt_irq(). While adjusting that function, also defer the setting
> of "dperm", which is only needed in the "map" case.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -104,7 +104,7 @@ long arch_do_domctl(struct xen_domctl *d
>           if ( rc )
>               return rc;
>   
> -        rc = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind);
> +        rc = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind, true);
>           if ( rc )
>               return rc;
>   
> @@ -140,7 +140,7 @@ long arch_do_domctl(struct xen_domctl *d
>           if ( irq != virq )
>               return -EINVAL;
>   
> -        rc = xsm_unbind_pt_irq(XSM_DM_PRIV, d, bind);
> +        rc = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind, false);
>           if ( rc )
>               return rc;
>   
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -622,7 +622,7 @@ long arch_do_domctl(
>           if ( !is_hvm_domain(d) )
>               break;
>   
> -        ret = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind);
> +        ret = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind, true);
>           if ( ret )
>               break;
>   
> @@ -660,7 +660,7 @@ long arch_do_domctl(
>           if ( !is_hvm_domain(d) )
>               break;
>   
> -        ret = xsm_unbind_pt_irq(XSM_DM_PRIV, d, bind);
> +        ret = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind, false);
>           if ( ret )
>               break;
>   
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -478,14 +478,8 @@ static XSM_INLINE int xsm_map_domain_irq
>   }
>   
>   static XSM_INLINE int xsm_bind_pt_irq(
> -    XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind)
> -{
> -    XSM_ASSERT_ACTION(XSM_DM_PRIV);
> -    return xsm_default_action(action, current->domain, d);
> -}
> -
> -static XSM_INLINE int xsm_unbind_pt_irq(
> -    XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind)
> +    XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind,
> +    bool allow)
>   {
>       XSM_ASSERT_ACTION(XSM_DM_PRIV);
>       return xsm_default_action(action, current->domain, d);
> --- a/xen/include/xsm/hooks.h
> +++ b/xen/include/xsm/hooks.h
> @@ -72,8 +72,8 @@ XSM_HOOK(int, map_domain_pirq, struct do
>   #endif
>   
>   XSM_HOOK(int, map_domain_irq, struct domain *, int, const pci_sbdf_t *, bool)
> -XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
> -XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
> +XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *,
> +                           bool)
>   
>   XSM_HOOK(int, irq_permission, struct domain *, int, bool)
>   XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, bool)
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1090,16 +1090,15 @@ static int cf_check flask_map_domain_irq
>   }
>   
>   static int cf_check flask_bind_pt_irq(
> -    struct domain *d, struct xen_domctl_bind_pt_irq *bind)
> +    struct domain *d, struct xen_domctl_bind_pt_irq *bind, bool access)
>   {
> -    uint32_t dsid, rsid;
> +    uint32_t dsid, rsid, dperm;
>       int rc = -EPERM;
>       int irq;
>       struct avc_audit_data ad;
> -    uint32_t dperm = flask_iommu_resource_use_perm(d);
>   
> -    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
> -    if ( rc )
> +    rc = current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
> +    if ( rc || access )

Same as on patch 23, check is inverted.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:35:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:35:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389858.1630469 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTie-00030R-Cm; Thu, 13 Aug 2026 11:35:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389858.1630469; Thu, 13 Aug 2026 11:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTie-00030K-9j; Thu, 13 Aug 2026 11:35:32 +0000
Received: by outflank-mailman (input) for mailman id 1389858;
 Thu, 13 Aug 2026 11:35:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuTid-00030E-5w
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:35:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTic-00CtMy-Ir
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:35:30 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7dabf4-bab6-0a2a0a5309dd-0a2a4508a2d8-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:35:30 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7dac02-f659-0a2a45080019-d155da36ec44-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:35:30 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c2022323c37so288139166b.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 04:35:30 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a37f8d28adsm796883a12.29.2026.08.13.04.35.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 04:35:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786620930; x=1787225730; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=SeH0PcL1dLiHSbmICpL1bAmjxscHG6k7vXWYQjDDUak=;
        b=ii7tkNERJU/NlJdxZCIa+ybN9bBwLOqw/nl7/lguqnkbQ2GP5q3oGmsB6cjYe2AqUl
         t9uzWn56Ow8ZGVSbMSdcc51GZ9I3icMvbtQ4mZ7B5lHND60d9R8he8/y8RBZXwt7dMxO
         BjPgxhT4gbuBrwBUp4V7uS7gFd5BH66rWlwb6RrcQGB06hYdK4o2K54xfQv4zIOFmgnw
         uAeVgx+R/ScT7UFNg0+tW07nD4tgzZ/+eRs0M8MGlt/JkeTpJgm+ilrUJrDNYIQpdoPt
         tMWoWeHLsXOslXP2GIuHUGhcZB+dpYu5dUAkIQkZfOQs+pGFB2GEEoLj6p7QdbgEtyHU
         Fjqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786620930; x=1787225730;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=SeH0PcL1dLiHSbmICpL1bAmjxscHG6k7vXWYQjDDUak=;
        b=SntiPuVEEaTGu1kfXi6rFXSokyYzNbWWNqNiXw/PL7s+kHC9fxDeQenux7lgGLBIAA
         m0q2MCCtiuea5N4llVE88TNOEKL0Ajg4LF4+gh9UKQmPW1VKKsRSD0xJKQz3+hudETlk
         dItUUY9JOOek4HVMot9uMgA2BfFpODeO9wi8Vc/Bi+CL2S/hJx5xUhUJS2iPYBARCv8k
         t/KG/W2jdYel/WOxlEm6yBvI+HyIQ54VR4zzB1LhoG4JYtFqtw5PRS2USGZX++HXMzY6
         CDcS1s+CVrUF0th+AH1ESbpm1bqOxe8naUhd3eTDDMNTGsf3FtMCz47u6u5nInyJNnqt
         /eWA==
X-Gm-Message-State: AOJu0YwTaVL/odisxsxmmzE/aNKTbFshuuDvSNU0MdUREFQXxWjJvqm6
	KSALVXodgmI6w5zqh+pNyuKIKdLDO5X08lhs7t+iyZ+6KanlHiLjBMJL
X-Gm-Gg: AR+sD10RVTV80Cdpa3W/3Wi7towJ/BMaMNmi2SL5jAUaEaF/+LWYhf7mWSMdfMZY2Ui
	ydrEAwaCVB7BmOs2hzqpRVAT4zmyUEhy5lRLxzfnW3cYUchuf/GrA37JwhPUEcfODxPOB2D6WIP
	GbJSt3b7IHWKqCnzgq65VcaZQ4qjVW4971UpDI4IVjdVTxQtulEnJCS2ww+9rerCW5CYQtN9cbH
	TyLeGISvj6oraCP7OTmSfCI7xmIjsTVJxP76IkR6sBmaDZHFaf/niPla5F6c6hiBM0w6Xrg1Ms5
	G/JOUBZM0xw9Yv93nafCuaHMmv0KaoJ0f51aMQfiGXNZQvOldFLk8Rqh1Po5wK0bVTAN3fV7Tiu
	+yPR2EG1s1hgLllGMPCvIanufL5WB+fBozasiQs7/SkQ/ha+O9yZTIINlGas7QXuRGsmGDquOV8
	bzUCXuIT7FonroQR9ykEV2jYbqSCIu5ZWmREF10cVO5kycNX9/DYSZ4TK+aWBwjV1jU+DD1Cryz
	ioSJ15pi86FENSPxMAvYzsfYfCMJT9E0tg4+CqBkYo=
X-Received: by 2002:a17:906:4790:b0:c15:db5c:7127 with SMTP id a640c23a62f3a-c2108fb4a6dmr218733066b.20.1786620929964;
        Thu, 13 Aug 2026 04:35:29 -0700 (PDT)
Message-ID: <b5013cc2-eb63-45ea-b8fc-bd97c94ac305@gmail.com>
Date: Thu, 13 Aug 2026 13:35:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 07/17] xen/riscv: introduce vCPU AIA initialization
To: Jan Beulich <jbeulich@suse.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b3aca8278dfd70bf6ce888bfcb0a3fbc32bb4971.1784560663.git.oleksii.kurochko@gmail.com>
 <1786613090.8631fc262581453bbf619ec5b2062170.19ffa7047d4000c4f3@vates.tech>
 <8273fde5-98b5-4b23-9f3b-9a7cc3749716@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <8273fde5-98b5-4b23-9f3b-9a7cc3749716@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1786620930-CC57487B-E2F6D969/20/8830180247
X-purgate-type: spam
X-purgate-size: 2085



On 8/13/26 11:47 AM, Jan Beulich wrote:
> On 13.08.2026 11:24, Baptiste Le Duc wrote:
>>> --- a/xen/arch/riscv/aia.c
>>> +++ b/xen/arch/riscv/aia.c
>>> @@ -14,6 +14,7 @@
>>>   #include <asm/cpufeature.h>
>>>   #include <asm/csr.h>
>>>   #include <asm/current.h>
>>> +#include <asm/imsic.h>
>>>   
>>>   struct vgein_ctrl {
>>>       unsigned long bmp;
>>> @@ -36,6 +37,35 @@ bool aia_usable(void)
>>>       return _aia_usable;
>>>   }
>>>   
>>> +void vcpu_aia_init(struct vcpu *v)
>>> +{
>>> +    unsigned int new_vsfile_id;
>>> +    int rc;
>>> +
>>> +    if ( !aia_usable() )
>>> +        return;
>>> +
>>> +    new_vsfile_id = vgein_assign(v);
>>> +
>>> +    /*
>>> +     * vgein_assign() returns 0 when no free h/w guest interrupt file is
>>> +     * available (including GEILEN == 0); imsic_map_guest_file() maps nothing
>>> +     * in that case.
>>> +     */
>>> +    rc = imsic_map_guest_file(v, new_vsfile_id);
>>> +    if ( rc )
>>> +    {
>>> +        /* Can't continue w/o correctly mapped IMSIC interrupt file */
>>> +        domain_crash(v->domain);
>>
>> The vgein id assigned a few lines up is not released here. The domain is dying
>> anyway, but the guest interrupt file stays marked in use on that pCPU forever,
>> since nothing else ever calls vgein_release(). A vgein_release(v,
>> new_vsfile_id) before the domain_crash() would fix it.
> 
> Instead of (or in addition to) doing that here, wouldn't releasing better be part
> of the normal cleanup path? Whether "instead of" or "in addition to" depends on
> the implications of deferring the release. But to guarantee no leak, domain
> cleanup will want to either do the release, or have an explicit check that is was
> done.

I think vgein_release() should be here, as when the IMSIC software 
interrupt file is supported, it will mean that domain_crash() can 
generally be dropped (there is no need to call imsic_map_guest_file() 
for s/w IMSIC interrupt file) and the vCPU can use the software 
interrupt file instead of killing the domain.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:49:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:49:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389869.1630478 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTva-0005IR-FR; Thu, 13 Aug 2026 11:48:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389869.1630478; Thu, 13 Aug 2026 11:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTva-0005IK-Ch; Thu, 13 Aug 2026 11:48:54 +0000
Received: by outflank-mailman (input) for mailman id 1389869;
 Thu, 13 Aug 2026 11:48:52 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wuTvY-0005IE-Kc
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:48:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTvY-0031IV-0k
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:48:52 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7daf1d-e002-0a2a0a5209dd-0a2a4501b24a-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:48:51 +0200
Received: from [40.107.208.53]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7daf21-5984-0a2a45010019-286bd0357d2c-4
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:48:51 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BN9PR03MB5964.namprd03.prod.outlook.com (2603:10b6:408:135::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Thu, 13 Aug
 2026 11:48:48 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.014; Thu, 13 Aug 2026
 11:48:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f+X4ZVQfy28x7aU3xQMvEFOpTZh/oBiC7pqQljLLTs3cJru35VjOFrNWLm8sqiU9I9vW1imzh1fBpu36ZPE6AZ3BX02fbUu7lan4NUGYKAVsbspSwQ7ULLUNFUf70A5d0yjkr9nJupjlmnRQGqTfMC/R+Mfcj9S7ZWyfrEcb639H9Guoh0nc2QF9INxbLzaXDMR2TMhKFeGlmAgyGY8L8z96x+WQ+F/hloPHnVkJ2d06pAa1Ky8R+iHPmWPPxK/ia66BqFBo3t693OJeBZwVaWsUE+qwZW7gqRwLIBNGaYiRMDsL3zp7a7pSeCVFtnIO1T/dScAO8FmHXZniAeIN3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rNr4ycQHg4kH4UcLusuVXOWNigth+KTRd8vT/BJeAnA=;
 b=Brd9waN0ev7OgVCsShqs7M9OH63Ut6FFjw9HpAAqY1PdW9CLr1ad0JkCTZSvzFMCOvy2WeMi5eX0jZOpPH6s4DwIXny2MD5fNWht9YkDxEDjriYI5gTDTQ0oxXv79oGJLc0Hjr//6vGWw8Bhp1ARk6k0/jmStOQKC91mchorKrgpfwuyU9s8udAboWdHbpXEPm2mXWjpMykFPnX+QtIr9GhaW7eM/VeyaYW5N6ZRU2P5f9tdN9NwfFsgqRO5LWJPcNItWxabF829N7XaFgSS14pE9dcyNa0C71L3MdV7t7hE1AWv//HGUkUM9y7F2UxfJ4Ki9Y3moI61tF5QpsG1yw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rNr4ycQHg4kH4UcLusuVXOWNigth+KTRd8vT/BJeAnA=;
 b=FhKt/YTxD6XMSqitCdvOzssibTA65FvSGri7gmvUJxDGYoLtlKppNf6iJIdD/tKZnitESRlAh7hfITV8ve4K2HIc8dDj8flaOSrmz1SKCtC3b0Ufwz7MbBBrx/N7ClMBZlA9zgq++GcszImIJ2fuKP0yeO2hqWo7hXUnYrgELnI=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <c76d69db-f976-4c7a-b653-ab1f13854db3@citrix.com>
Date: Thu, 13 Aug 2026 12:48:43 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Frediano Ziglio <frediano.ziglio@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>,
 Frediano Ziglio <freddy77@gmail.com>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v10 2/10] libs/guest: move batch_pfns into a separate
 structure
To: Jan Beulich <jbeulich@suse.com>
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-3-frediano.ziglio@citrix.com>
 <d41d0fa2-7273-4723-a5e0-6424d030cf0a@citrix.com>
 <1101df6e-bb36-4766-9b11-365d1043342b@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1101df6e-bb36-4766-9b11-365d1043342b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0291.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:38f::20) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN9PR03MB5964:EE_
X-MS-Office365-Filtering-Correlation-Id: 17369e5f-ccc0-4e0e-2a60-08def930d5b7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|6133799003|10067099003|4143699003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	RsBrXtc6nPpl8pjUKiHKlDQJGKqc5mW+GuC6l4QcJzKOvSN5D1i5fmoWI6f6RWO/ngf4u4Y/is8rQ7EtI0TJ7j6i8NF7yFuPp+WLVfbKjEcLbIK8XOHhcn8L0Ctw42u5Ot/Y+uc2km6RUPdjnFPo9J3q80FzSXiFhr6NQzRdqZEerw04rQrgvhcYiQkalaKJP72pHm9aRC1fRMpDeC64BvLfxK7vftMbSMDy4GndX1Dqg5jH9A8Lsi0kihJf5WvlzW2gMHM2DlJOOcTT/MJykxD3WxIv2eGAkFdaS+uU4hwvO+6hFL7ALwNvWDF9LPbAuGMg7102xnwTnuC6ISGa507IJr2TiM+KtvFQb9A3tO14uOD207zs4KK4EXxFUEuEU27dpbR6YevYxRXcMThgp6GQZEaPWJ6ysg7C4ZI14lZdsrX3cLX6F1rggON3eXGAF1gVIuSRUH+YxDOU7DXtC+9Fj5jr5wpS8eyHJNbG37BJVhZ9QUgmwE0mtpeShS6DRwY69Tl5W0DhyyDHO1IPnVJoglVSXzQ6Z8Jwful77BKkL9xo7dGhIHzgSNgjhVjKc8+G/ew8vMTglNjINZRYWIHVQoFl7fZv8mh0BEUCBL/60B4Z4Nwwyz52yx1LGnkxA7wj6F3d8s3V2mHfpdA6yPygbpgHklTBFwYCOmIQwpQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(6133799003)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YWJWcCswU1cxVWlqazdtKzR3QU1qN3lDZEgzVmtEdkZvdS9ablF4Rk5BVWl6?=
 =?utf-8?B?bUlDcmcvdkhZYVY3VDV6ZjJqS0hVRi9vQnFFWmoyYm5oZkROdHZqM0FYTHZG?=
 =?utf-8?B?QUcyeEJ1WlpmNXNBUXBNZEpoNHpsbEtnWFI0cnpFZGtPVkVpYWJkVXVqNlY0?=
 =?utf-8?B?K2dQdURTYzl3WDlJNEN1Q1RlOWdrd29jSFJJdWJoVmtkYnArNy9mMEFTTlRI?=
 =?utf-8?B?VlBjNzNabzVLNStPTHpHWE9FbUpWSmFKNTFMYmpKbHc0V2l0aFkxL1l0aVQ3?=
 =?utf-8?B?d1JMOXhPSWZCdWZ2bjNpYkRHRHJDdkNSdVMxVUNSSGVyWUNQTFhzWitPaDZC?=
 =?utf-8?B?ejBmSGVwRWl3ZDhFUExJbFZPTUVjVUl6Z1lPbEd4ZTg5cFFMeFJxQ0lyNXJM?=
 =?utf-8?B?NTZWZHJjbVpVczNxaHZVZjFlMStTT0d0Yy8yb25FanVZUndwa1ZWUklZY01x?=
 =?utf-8?B?ZDQzWXRwbHY4SWpDR2YrVkVHcjVUKzl0OFRSdzViN2ZXTGpaeE9RbFZyUlFK?=
 =?utf-8?B?aFoydWxPQ2w0cThMQkF5UHVtaXdGRlhIUEdoYzZIK0YrTTFlaWYxUTliZjBW?=
 =?utf-8?B?RnQvemU4Qkc4bVBBU2RvN1A1V1E5UnVRaWYyOFB5TFZnMEowajhFT2I2Rndi?=
 =?utf-8?B?OFdySkw0TmNleGZpTWRvOXFiRjFMd1hSSFU2SVFIa3F0VEJna1V1ajQ2SUhw?=
 =?utf-8?B?YTA4eEpOa3J6QzczVVV0YnFXMFZ5RzdXWVN4L1F6dENyRVBLVjN5Y3YvVXNY?=
 =?utf-8?B?SmNabFozVHVaWlplUEp2NFV1Sm5CT01qQ3dqOXc5azlVL09LMlJPVEkyUHVL?=
 =?utf-8?B?bkJIK0pHMEdoNEx1YzVtVE0xZ0doR29FcUhraXF0VWhyM1I4RzJhZ2FVSTJ5?=
 =?utf-8?B?WDNLQUxWUFZuMzVPUmpxUWx3UWZxNTYzcC9sc0hDMG5RaUtobTV6aHJZOVRB?=
 =?utf-8?B?MDN1a0F3b0d1WHE5SEpzaC8xRytFYWJFY2dtbDhZeTFNWTNickljQ1ZFdTQy?=
 =?utf-8?B?TWdkUmZXNEhkSlJMRFN6UWFvd0duUXlBTkdqQnRnSnJhNk9EVjE0eDl1NzI1?=
 =?utf-8?B?RmFWRVErUlJtNXBWOFVBYlNWK3hESWRwaHcwSEM3NURqY3pMaVlHM1RoQmJF?=
 =?utf-8?B?cmN3OFpISGhzVW1tUllUdFg4YlhJU2ZweGNKNndFV1k1dmdYTVVtZ20wN0pY?=
 =?utf-8?B?WkdXVHZmbHpCL1hWckh6Z0N4cnZ1a0x1NWVFVmplandJcEdsRnh2SE40UHNL?=
 =?utf-8?B?RWF2RjF4Q05Qa0tFcjdmSWtvb1JnNDczNld5a2NFQ3VvS3B6YXNvWlJiWVYz?=
 =?utf-8?B?YisxQVdyWUdwTjF5K0ZVZHRodDRQNW1BYUszc0QzVWpRRVNLTWN0WDdwUHhR?=
 =?utf-8?B?TUlaNlpSMy91SlZKdmQ4dWIwV1dSclVTeHlBcjYxK3ViMUl0NWpxczJMYVJ4?=
 =?utf-8?B?RzYyL0Z0cXAxdDJIcGNjaUI1SXdPTWNMaWJpMmNtUVcwdU1mWjRPSmVHNWNW?=
 =?utf-8?B?VERBQ3lxVkZMRk43UjVQa1lKYUhkdHlkQkxtazlldEVrRW0zMFFsNVRjSUFr?=
 =?utf-8?B?d01UMFN1VFlTQUlCdXJvYjFnYjRkbUNLblBsZTBUcDJUVWxLc2N5dmw0RVlj?=
 =?utf-8?B?Vk55dCswbWptcFkyMTRiK3RhY3o5TFVaWk1UNjRsY1Q5Q1RydkU5SEtzV2ht?=
 =?utf-8?B?S2k3MXNXWEFpaUJMUGFiZUFKVW1jQ1dhWWh6SDkxSWxFMHFDZGF3VFJvVFVP?=
 =?utf-8?B?eFZVTFJTdk8vR214eWxydXVyL0Z5eFB4ZEF1cGlLa3c5Ym1zdHovVlpFL2VW?=
 =?utf-8?B?VTlzR0pIY0VQamlORTJnU1JZR1FyaE9xS1ZpQk4rUE1XcytLRjhFclA4VDNK?=
 =?utf-8?B?NVZqL3NsMnZkQUIvWWxiRm5jdy82QUdTb3RVRkpwSXBUVjZ1eUZSUDMvQWJx?=
 =?utf-8?B?alNkNU1wRW51QVp2SkxxQ1Q1L3dRMHg1UE95Ny9iTzhWWW1WTnRUbEYveEZk?=
 =?utf-8?B?RTJSbmVXam1mRmhnTDNRZFlvTXpJWGJsVDBjQ0dkQVROeFY0blFLd1Jmazdi?=
 =?utf-8?B?aXZrS3BWdFRJcVM3MXJvdzdmdzZQNmFXdFI1ck1sdVByU21PelFvSnR4V0hD?=
 =?utf-8?B?Wkl1NEVtRWpmQ3Qvc2c4eGM4NjVja3gzTjUzOVM3cVhuSGwyUVd4Wk0zT3U4?=
 =?utf-8?B?OW90WXBoSHkvZ2xVUXVCTm55RzRXa3JneldRTWdGYWZCanF4blpyVmljQW52?=
 =?utf-8?B?K0JCbWE3ZExwR2d0NkNsRG52ek1qRnhNVk5BamV0NzlpWjROeW1mZDRjWGJl?=
 =?utf-8?B?bnAveitrOFFjMk8zVjUzYU5DWHVLY1FidUpSbFo0UmJRL1RjdjlPUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 17369e5f-ccc0-4e0e-2a60-08def930d5b7
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 11:48:47.3251
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: MBW5NGpAYEUj6xR9//j/bplzJCci/mTmgYl3ybW/R/e0yX2cwxwB25QMq1kSsn6z8FNMyAIzZ9Mc6Sa0dVNWWkNwj7dspMKVOcQYoU45k0U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB5964
X-purgate-ID: tlsNG-d62444/1786621731-1D87F757-8F111398/0/0
X-purgate-type: clean
X-purgate-size: 1821

On 13/08/2026 12:27 pm, Jan Beulich wrote:
> On 13.08.2026 13:08, Andrew Cooper wrote:
>> On 10/08/2026 11:30 am, Frediano Ziglio wrote:
>>> Preparation for a followup patch "libs/guest: allocate various migration
>>> arrays just once".
>>>
>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>>> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
>> Coverity thinks this change has memory corruption.  I have to admit that
>> I'm not completely sure why it's noticed now; possibly because now it
>> can see the size of batch_pfns[] where previously it couldn't
> I had looked into that too, and I'm puzzled that ...
>
>> ** CID 1700057:       Memory - corruptions  (OVERRUN)
>> /tools/libs/guest/xg_sr_save.c: 284           in add_to_batch()
>> _____________________________________________________________________________________________
>> *** CID 1700057:         Memory - corruptions  (OVERRUN)
>> /tools/libs/guest/xg_sr_save.c: 284             in add_to_batch()
>> 278         int rc = 0;
>> 279     
>> 280         if ( ctx->save.nr_batch_pfns == MAX_BATCH_SIZE )
>> 281             rc = flush_batch(ctx);
> ... the tool can't spot that flush_batch() resets ctx->save.nr_batch_pfns
> to 0 in the success case. And ...
>
>> 283         if ( rc == 0 )
> ... only the success case is what matters.

Hmm.  Both flush_batch() and write_batch() are static, so fully visible
to Coverity.

I guess this means that Coverity failed to figure out the properties of
write_batch(); it is a complicated function, even if it has become less
complicated recently.

I'm still advocating to remove the Valgrind logic rather than extend it
in patch 3, and that will remove flush_batch() which might simplify things.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 11:52:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 11:52:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389883.1630488 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTyl-0006wM-W6; Thu, 13 Aug 2026 11:52:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389883.1630488; Thu, 13 Aug 2026 11:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuTyl-0006wE-SP; Thu, 13 Aug 2026 11:52:11 +0000
Received: by outflank-mailman (input) for mailman id 1389883;
 Thu, 13 Aug 2026 11:52:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuTyk-0006w7-LL
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 11:52:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuTyk-006ElJ-1K
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:52:10 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dafd1-e002-0a2a0a5209dd-0a2a4501d4f2-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:52:09 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dafe7-5984-0a2a45010019-888fbc3352ca-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 13:52:09 +0200
Received: by mx.zohomail.com with SMTPS id 1786621916845447.51828945348825;
 Thu, 13 Aug 2026 04:51:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786621919; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=KwItdb5ZuNsg+q/yt7Bycy/sDqtQlm7BAtPrQOcQ4QIK5ewK+pvSCPS0m4486360pZ8ncr56cLA+wRmDh22hATR5Ysb8w8B0I+qNyZf9OIaNQg3pTHcFd4FlDHF6Qv2aJPcVrulpR6GemFWNjiqTRYOAZ7bDWauK9CG9Ig0QqbM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786621919; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=Brmj6kD7q7zLBYdskHDr3VnIZX9DfS8N1MF6VyKYuAk=; 
	b=VlPMCvl7aj0xevvWHczV+uBs/WMpFlSybTEqAxMseo3+ekKppp86n3w1+jneICZ4pO77NVvAmwdZ1aW9pL3L5R2UI8bI/HoVUZgRt0qn3JUliFmAp6+zZ/zebOPnRqxmA9yATfVZzpGvhmS7PhlodypVTHhQrbzTZnGJ07nZKJE=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786621919;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Brmj6kD7q7zLBYdskHDr3VnIZX9DfS8N1MF6VyKYuAk=;
	b=iDr/Ro6B4PbOgTsRjR7XcWdO7o1I5hP6WDg0uHk3a309Rk6MB4NL4N/Qzcjyg592
	P1DHSS+sA/34hBS0KscUGLJTbmHakxa/P6/ntUfamCsCh2Wk3Rvkl1yG0aJ1tBPi7Jr
	7D158AGNbvFLUe+jbGgy9YRnaPK4jqG00mekKYPE=
Message-ID: <e5799ee9-6a97-4ad8-b1c4-6b54e43b7a4d@apertussolutions.com>
Date: Thu, 13 Aug 2026 07:51:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <07e90200-95b5-413f-9259-7f0481d36521@suse.com>
 <4531d02a-3a37-4c57-ba17-32034ba08cf9@apertussolutions.com>
 <b742fec6-730a-4138-b5f5-7197f24df247@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <b742fec6-730a-4138-b5f5-7197f24df247@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-d62444/1786621929-BF063757-1557C914/0/0
X-purgate-type: clean
X-purgate-size: 3139

On 8/3/26 6:11 AM, Jan Beulich wrote:
> On 02.08.2026 17:55, Daniel P. Smith wrote:
>> On 7/28/26 9:18 AM, Jan Beulich wrote:
>>> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
>>> With the function compiled out, its dedicated XSM hook also becomes
>>> unreachable, so it is similarly guarded.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> It feels suspicious that the .priv_mapping() check is used for HVM guests
>>> in shadow mode, but not for ones in HAP mode.
>>
>> I believe a hint to it is laying in the comment,
>>
>>    /*
>>     * Let privileged domains transfer the right to map their target
>>     * domain's pages. This is used to allow stub-domain pvfb export to
>>     * dom0, until pvfb supports granted mappings. At that time this
>>     * minor hack can go away.
>>     */
>>
>> Correct me if I am wrong, but get_page_from_l1e() is only used by PV and
>> HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done
>> through p2m_get_foreign() which will then be covered by
>> xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check.
> 
> Yes, sure; that wasn't the point of my comment. The point was that I'd
> expect _the same_ hook to be used by the other path. Aiui if you make a
> policy, you want same situations dealt with the same. Hence there shouldn't
> be a need to express the same thing two ways.
> 

But it's not the same, the enforcement mechanism is different. FLASK is 
an evaluation of Subject/Object/Predicate. In this case the mechanism 
(software enforced access) that provides the Predicate has enough risk 
that it warranted itself a separate check to allow fine grained 
assignment of the operation to a specific domain which was driven by a 
specific use case.

>> I think the question is how to address the TARGET_HACK situation.
> 
> I fear I don't really know what exactly you mean here.
> 

Is this path still needed for the pvfb or is it now in use by other use 
cases. If the former, then close the ability otherwise TARGET_HACK 
should be renamed to something sensible for general case. Some code 
documentation might be necessary to help understand why/

>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -837,6 +837,8 @@ static int cf_check print_mmio_emul_rang
>>>    }
>>>    #endif
>>>    
>>> +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
>>> +
>>>    /*
>>>     * get_page_from_l1e returns:
>>>     *   0  => success (page not present also counts as such)
>>> @@ -1038,6 +1040,8 @@ get_page_from_l1e(
>>>        return -EBUSY;
>>>    }
>>>    
>>> +#endif /* CONFIG_PV || CONFIG_SHADOW_PAGING */
>>> +
>>
>> Would it also not be prudent to #ifdef out the declaration in asm/mm.h?
> 
> Ah, yes, this looks possible for this function - the decl isn't needed for any
> DCE-ing by the compiler.
> 
>> I think it would be a good defensive approach to condition out the
>> header declaration. Otherwise,
>>
>> Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
> Thanks, also for all the others.
> 
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:02:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:02:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389904.1630497 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuU8J-0000fQ-4P; Thu, 13 Aug 2026 12:02:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389904.1630497; Thu, 13 Aug 2026 12:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuU8J-0000fJ-0t; Thu, 13 Aug 2026 12:02:03 +0000
Received: by outflank-mailman (input) for mailman id 1389904;
 Thu, 13 Aug 2026 12:02:02 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuU8H-0000fD-SB
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:02:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuU8H-0033Jh-8g
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:02:01 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7db235-2eae-0a2a0a5409dd-0a2a4501dd2e-16
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:02:01 +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 <jbeulich@suse.com>)
 id 6a7db238-5984-0a2a45010019-d155802fddae-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:02:00 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so20078415e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:02:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a569c1fsm6004857f8f.15.2026.08.13.05.01.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 05:01:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786622520; x=1787227320; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=sAKI3VAre4My91BL1HkZHsv/aK/WZK4PntFfiIBBQrU=;
        b=IQErONNh82/qPBcbE6EM7+tU2hHS8U6qjBQiqpwXFHJRfHUOI4/glVYTDpnKOX86KE
         8OnaJSDvnXhOI1oyPwou6Q3c3eGlMZy1ZUGqaLZuNytwvGcXN165TrCblnhXVGKpKg7C
         86LROURGgxn5moXhzUD+fb6hXA3wI5vIbWEPKAqhymDURxgDqxy+zNSZ5MgKOJKxoDvj
         wKvTP95yBCOGKG6Sicp9Qu6gpo0W+WzVKg/CFRpxfJ+Y2DBy5kFZ/gdhTMRgce2skARQ
         4B0mKGQmfP+RzoGQPcqYVVq8WoFnCRGOeqnHm8OCHqpUtmTAY2cDECyr21drng6FZZbd
         J/hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786622520; x=1787227320;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=sAKI3VAre4My91BL1HkZHsv/aK/WZK4PntFfiIBBQrU=;
        b=BuYlJ46g0WGWlIqRWw09AmRTF0fWE3XRsfF+0cYSxJ2I1pJ5rKpSzNLs6RyZR+4fxr
         QfQzeTMvZOci0bfivC3MoDPFtUjfKFhARNf8hOQ/NxXh554+UooPPLoNqYbTRqLZqkOC
         OMwnctVgUI08bIDlChpknbqpJWjORWMGDFRB2B6HljtQU4w1RVAzl7qiLhwlF0IFP0GM
         b+GMH1QKfkYvtrasTN5leCjHAPCtIUrjz2vyT+QQwuIR4/GDJELGMkzoOPxEqpTicGjw
         Xos0QKsIlKtezwivdvtjWsxXrTXTw8LQcA3PZmJ4dwFUHU4lRMeLTJB+d4jF999Ctuwe
         9A9w==
X-Forwarded-Encrypted: i=1; AHgh+RrYusdnU7ObE2fkCHAnrioxoWIPTftoshiLFiW/9ViC3Nps9QdK/iLVE81SDe3YuUaxNW78BRK7XGY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwxXGIn1SvDW3TZpcWSul/R2PbNBB53gcsWCiPwplYHZXN8JxSH
	Bmr2K8Oqgsfk49xtUOBancw50J8/lj+IGRYx38G4J7ZOGd+Yul15R0lcmOcHiloniQ==
X-Gm-Gg: AR+sD13i09mWSjha7+L1SblneWAJTeAUpSNCaj25zUE1WY4PIsEz3K4maN7gAK/xcF5
	uQYZd2LXzJZ+u62Ge2VCi4aWfCMyMo7hEAemz/eBkp/t8YdOtomBbyn9niQtiRCv0i6xvQ0LPcT
	Hls2gfu95LSvLgLnWMhSHQ1gzxOnLtarMPtucbN/x0aUe24+yObNWJ0WUI69/taj11/M9Aeymz5
	i2sfFPMvooFD1r9Nb9LUhUWIH0fKyNFRzG3Qo2UPg29DBEBs93kl/y7qS5ETyUADbp4cdZE8iN/
	Ypb7GvlrCNgYMsSQnXKbZYaA9K++mmOGsK/PiYWQE5QcGGKhKxW0jhCk9jiW+6sod1yOycqxSpl
	mD4k1wszwsjvDdUdzFnMMrxMLXvyZG8W+esuMXTZ9Uv8qs+205JTTfHb7ySr7Z/iYzZMWJvQGWQ
	UhuyB2i3r4NAzy1zCnnCrW/KmDd+2GwBFuybni47bw+97bU/o70+A6PKpTRDU3zJF69IfUtWbA4
	Y+1DIkCSKkLqAfR7pmSJjjqld/1bbHOGScAC5Nv7qYKg8y6F0povFEfkU3+M+A=
X-Received: by 2002:a05:600c:4f87:b0:499:8191:62c7 with SMTP id 5b1f17b1804b1-499821d7e83mr57365835e9.18.1786622518812;
        Thu, 13 Aug 2026 05:01:58 -0700 (PDT)
Message-ID: <6166e2ac-3b8b-4702-ac15-357d1c1a4c56@suse.com>
Date: Thu, 13 Aug 2026 14:01:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] x86: extend update_intpte() to support atomic
 get-and-update
To: Kevin Lampis <kevin.lampis@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, xen-devel@lists.xenproject.org
References: <20260727150615.1373200-1-kevin.lampis@citrix.com>
 <20260727150615.1373200-2-kevin.lampis@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260727150615.1373200-2-kevin.lampis@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786622520-BDE78757-D8B7D4E0/0/0
X-purgate-type: clean
X-purgate-size: 14260

On 27.07.2026 17:06, Kevin Lampis wrote:
> --- a/xen/arch/x86/pv/mm.h
> +++ b/xen/arch/x86/pv/mm.h
> @@ -66,13 +66,14 @@ static inline intpte_t paging_cmpxchg_guest_entry(
>   * How to write an entry to the guest pagetables.
>   * Returns false for failure (pointer not valid), true for success.
>   */
> -static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new,
> -                                 mfn_t mfn, struct vcpu *v, bool preserve_ad)
> +static inline bool update_intpte(intpte_t *p, intpte_t *old, intpte_t new,
> +                                 mfn_t mfn, struct vcpu *v, bool preserve_ad,
> +                                 bool use_cmpxchg)

No 2nd boolean parameter, please. (use_cmpxchg also doesn't look to be an
overly good name; "swap" maybe?) As you switch old to being a pointer, and
as ...

>  {
>      bool rv = true;
>  
>  #ifndef PTE_UPDATE_WITH_CMPXCHG
> -    if ( !preserve_ad )
> +    if ( !preserve_ad && !use_cmpxchg )
>          paging_write_guest_entry(v, p, new, mfn);

... *old isn't used here, having callers pass in NULL in that case may be
one option.

(In any event, old becoming a pointer imo needs commenting upon, as otherwise
one might expect this to be only an output.)

Alternatively I have an old patch lying around which looks to apply cleanly,
and which may be useful here; see at the bottom.

> @@ -82,30 +83,36 @@ static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new,
>              intpte_t _new = new, t;
>  
>              if ( preserve_ad )
> -                _new |= old & (_PAGE_ACCESSED | _PAGE_DIRTY);
> +                _new |= *old & (_PAGE_ACCESSED | _PAGE_DIRTY);
>  
> -            t = paging_cmpxchg_guest_entry(v, p, old, _new, mfn);
> +            t = paging_cmpxchg_guest_entry(v, p, *old, _new, mfn);
>  
> -            if ( t == old )
> +            if ( t == *old )
>                  break;
>  
>              /* Allowed to change in Accessed/Dirty flags only. */
> -            BUG_ON((t ^ old) & ~(intpte_t)(_PAGE_ACCESSED|_PAGE_DIRTY));
> +            BUG_ON((t ^ *old) & ~(intpte_t)(_PAGE_ACCESSED|_PAGE_DIRTY));
>  
> -            old = t;
> +            *old = t;
>          }
>      }
>      return rv;
>  }
>  
> +static inline bool _update_intpte(intpte_t *p, intpte_t old, intpte_t new,
> +                                  mfn_t mfn, struct vcpu *v, bool preserve_ad)
> +{
> +    return update_intpte(p, &old, new, mfn, v, preserve_ad, false);
> +}
> +
>  /*
>   * Macro that wraps the appropriate type-changes around update_intpte().
>   * Arguments are: type, ptr, old, new, mfn, vcpu
>   */
>  #define UPDATE_ENTRY(_t,_p,_o,_n,_m,_v,_ad)                         \
> -    update_intpte(&_t ## e_get_intpte(*(_p)),                       \
> -                  _t ## e_get_intpte(_o), _t ## e_get_intpte(_n),   \
> -                  (_m), (_v), (_ad))
> +    _update_intpte(&_t ## e_get_intpte(*(_p)),                      \
> +                   _t ## e_get_intpte(_o), _t ## e_get_intpte(_n),  \
> +                   (_m), (_v), (_ad))

Like the patch below does - if already this last line needs touching, I
think the excess parentheses then also want dropping.

Tangentially: We will want to consider dropping the function's return
value, since as of 1bc30c076a7f ("x86/mm:
{paging, sh}_{cmpxchg, write}_guest_entry() cannot fault") it only ever
returns true.

Jan

x86: make UPDATE_ENTRY() allow for multiple operation flags

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2149,10 +2149,9 @@ static void l3t_unlock(struct page_info
 
 /* Update the L1 entry at pl1e to new value nl1e. */
 static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e,
-                        mfn_t gl1mfn, unsigned int cmd,
+                        mfn_t gl1mfn, unsigned int update_flags,
                         struct vcpu *pt_vcpu, struct domain *pg_dom)
 {
-    bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD);
     l1_pgentry_t ol1e = l1e_read(pl1e);
     struct domain *pt_dom = pt_vcpu->domain;
     int rc = 0;
@@ -2172,7 +2171,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
         }
 
         /* Translate foreign guest address. */
-        if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+        if ( !(update_flags & PTE_UPDATE_NO_TRANSLATE) &&
              paging_mode_translate(pg_dom) )
         {
             p2m_type_t p2mt;
@@ -2213,7 +2212,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
         if ( !l1e_has_changed(ol1e, nl1e, ~FASTPATH_FLAG_WHITELIST) )
         {
             rc = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
-                              preserve_ad);
+                              update_flags);
             if ( page )
                 put_page(page);
             return rc ? 0 : -EBUSY;
@@ -2237,7 +2236,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
             put_page(page);
 
         if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
-                                    preserve_ad)) )
+                                    update_flags)) )
         {
             ol1e = nl1e;
             rc = -EBUSY;
@@ -2246,7 +2245,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
     else if ( pv_l1tf_check_l1e(pt_dom, nl1e) )
         return -ERESTART;
     else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu,
-                                     preserve_ad)) )
+                                     update_flags)) )
     {
         return -EBUSY;
     }
@@ -2260,7 +2259,7 @@ static int mod_l1_entry(l1_pgentry_t *pl
 static int mod_l2_entry(l2_pgentry_t *pl2e,
                         l2_pgentry_t nl2e,
                         mfn_t mfn,
-                        int preserve_ad,
+                        unsigned int update_flags,
                         struct vcpu *vcpu)
 {
     l2_pgentry_t ol2e;
@@ -2292,7 +2291,7 @@ static int mod_l2_entry(l2_pgentry_t *pl
         /* Fast path for sufficiently-similar mappings. */
         if ( !l2e_has_changed(ol2e, nl2e, ~FASTPATH_PDE_FLAG_WHITELIST) )
         {
-            if ( UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, preserve_ad) )
+            if ( UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags) )
                 return 0;
             return -EBUSY;
         }
@@ -2301,7 +2300,7 @@ static int mod_l2_entry(l2_pgentry_t *pl
             return rc;
 
         if ( unlikely(!UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu,
-                                    preserve_ad)) )
+                                    update_flags)) )
         {
             ol2e = nl2e;
             rc = -EBUSY;
@@ -2310,7 +2309,7 @@ static int mod_l2_entry(l2_pgentry_t *pl
     else if ( pv_l1tf_check_l2e(d, nl2e) )
         return -ERESTART;
     else if ( unlikely(!UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu,
-                                     preserve_ad)) )
+                                     update_flags)) )
     {
         return -EBUSY;
     }
@@ -2324,7 +2323,7 @@ static int mod_l2_entry(l2_pgentry_t *pl
 static int mod_l3_entry(l3_pgentry_t *pl3e,
                         l3_pgentry_t nl3e,
                         mfn_t mfn,
-                        int preserve_ad,
+                        unsigned int update_flags,
                         struct vcpu *vcpu)
 {
     l3_pgentry_t ol3e;
@@ -2354,7 +2353,7 @@ static int mod_l3_entry(l3_pgentry_t *pl
         /* Fast path for sufficiently-similar mappings. */
         if ( !l3e_has_changed(ol3e, nl3e, ~FASTPATH_PDE_FLAG_WHITELIST) )
         {
-            rc = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, preserve_ad);
+            rc = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags);
             return rc ? 0 : -EFAULT;
         }
 
@@ -2364,7 +2363,7 @@ static int mod_l3_entry(l3_pgentry_t *pl
         rc = 0;
 
         if ( unlikely(!UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu,
-                                    preserve_ad)) )
+                                    update_flags)) )
         {
             ol3e = nl3e;
             rc = -EFAULT;
@@ -2373,7 +2372,7 @@ static int mod_l3_entry(l3_pgentry_t *pl
     else if ( pv_l1tf_check_l3e(d, nl3e) )
         return -ERESTART;
     else if ( unlikely(!UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu,
-                                     preserve_ad)) )
+                                     update_flags)) )
     {
         return -EFAULT;
     }
@@ -2386,7 +2385,7 @@ static int mod_l3_entry(l3_pgentry_t *pl
 static int mod_l4_entry(l4_pgentry_t *pl4e,
                         l4_pgentry_t nl4e,
                         mfn_t mfn,
-                        int preserve_ad,
+                        unsigned int update_flags,
                         struct vcpu *vcpu)
 {
     struct domain *d = vcpu->domain;
@@ -2416,7 +2415,7 @@ static int mod_l4_entry(l4_pgentry_t *pl
         /* Fast path for sufficiently-similar mappings. */
         if ( !l4e_has_changed(ol4e, nl4e, ~FASTPATH_PDE_FLAG_WHITELIST) )
         {
-            rc = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, preserve_ad);
+            rc = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags);
             return rc ? 0 : -EFAULT;
         }
 
@@ -2426,7 +2425,7 @@ static int mod_l4_entry(l4_pgentry_t *pl
         rc = 0;
 
         if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu,
-                                    preserve_ad)) )
+                                    update_flags)) )
         {
             ol4e = nl4e;
             rc = -EFAULT;
@@ -2435,7 +2434,7 @@ static int mod_l4_entry(l4_pgentry_t *pl
     else if ( pv_l1tf_check_l4e(d, nl4e) )
         return -ERESTART;
     else if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu,
-                                     preserve_ad)) )
+                                     update_flags)) )
     {
         return -EFAULT;
     }
@@ -4135,18 +4134,23 @@ long do_mmu_update(
 
             if ( page_lock(page) )
             {
+                unsigned int update_flags = (cmd == MMU_PT_UPDATE_PRESERVE_AD)
+                                            ? PTE_UPDATE_PRESERVE_AD
+                                            : (cmd == MMU_PT_UPDATE_NO_TRANSLATE)
+                                              ? PTE_UPDATE_NO_TRANSLATE : 0;
+
                 switch ( page->u.inuse.type_info & PGT_type_mask )
                 {
                 case PGT_l1_page_table:
                     rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
-                                      cmd, v, pg_owner);
+                                      update_flags, v, pg_owner);
                     break;
 
                 case PGT_l2_page_table:
                     if ( unlikely(pg_owner != pt_owner) )
                         break;
                     rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
-                                      cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
+                                      update_flags, v);
                     if ( !rc )
                         flush_linear_pt = true;
                     break;
@@ -4155,7 +4159,7 @@ long do_mmu_update(
                     if ( unlikely(pg_owner != pt_owner) )
                         break;
                     rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn,
-                                      cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
+                                      update_flags, v);
                     if ( !rc )
                         flush_linear_pt = true;
                     break;
@@ -4164,7 +4168,7 @@ long do_mmu_update(
                     if ( unlikely(pg_owner != pt_owner) )
                         break;
                     rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
-                                      cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
+                                      update_flags, v);
                     if ( !rc )
                         flush_linear_pt = true;
                     if ( !rc && pt_owner->arch.pv.xpti )
--- a/xen/arch/x86/pv/mm.h
+++ b/xen/arch/x86/pv/mm.h
@@ -62,17 +62,20 @@ static inline intpte_t paging_cmpxchg_gu
 #undef PTE_UPDATE_WITH_CMPXCHG
 #endif
 
+#define PTE_UPDATE_PRESERVE_AD  (1u << 0)
+#define PTE_UPDATE_NO_TRANSLATE (1u << 1)
+
 /*
  * How to write an entry to the guest pagetables.
  * Returns false for failure (pointer not valid), true for success.
  */
 static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new,
-                                 mfn_t mfn, struct vcpu *v, bool preserve_ad)
+                                 mfn_t mfn, struct vcpu *v, unsigned int flags)
 {
     bool rv = true;
 
 #ifndef PTE_UPDATE_WITH_CMPXCHG
-    if ( !preserve_ad )
+    if ( !(flags & PTE_UPDATE_PRESERVE_AD) )
         paging_write_guest_entry(v, p, new, mfn);
     else
 #endif
@@ -81,7 +84,7 @@ static inline bool update_intpte(intpte_
         {
             intpte_t _new = new, t;
 
-            if ( preserve_ad )
+            if ( flags & PTE_UPDATE_PRESERVE_AD )
                 _new |= old & (_PAGE_ACCESSED | _PAGE_DIRTY);
 
             t = paging_cmpxchg_guest_entry(v, p, old, _new, mfn);
@@ -102,10 +105,10 @@ static inline bool update_intpte(intpte_
  * Macro that wraps the appropriate type-changes around update_intpte().
  * Arguments are: type, ptr, old, new, mfn, vcpu
  */
-#define UPDATE_ENTRY(_t,_p,_o,_n,_m,_v,_ad)                         \
+#define UPDATE_ENTRY(_t ,_p ,_o ,_n ,_m ,_v , fl)                   \
     update_intpte(&_t ## e_get_intpte(*(_p)),                       \
                   _t ## e_get_intpte(_o), _t ## e_get_intpte(_n),   \
-                  (_m), (_v), (_ad))
+                  _m, _v, fl)
 
 static always_inline l1_pgentry_t adjust_guest_l1e(l1_pgentry_t l1e,
                                                    const struct domain *d)



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:10:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:10:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389918.1630506 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUFx-0001qr-S7; Thu, 13 Aug 2026 12:09:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389918.1630506; Thu, 13 Aug 2026 12:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUFx-0001qk-OZ; Thu, 13 Aug 2026 12:09:57 +0000
Received: by outflank-mailman (input) for mailman id 1389918;
 Thu, 13 Aug 2026 12:09:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuUFw-0001qe-BC
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:09:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUFv-0034bu-O9
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:09:55 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7db400-2eae-0a2a0a5409dd-0a2a45079526-38
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:09:55 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7db411-b4ea-0a2a45070019-888fbc3352cb-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:09:55 +0200
Received: by mx.zohomail.com with SMTPS id 1786622985898102.77676751425997;
 Thu, 13 Aug 2026 05:09:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786622989; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=NDzEYYXGJr+SH3bZ+rJdIu+rU1G3M5dY9cCNIgYib/zV3diHUpb6XhostGRMM++Rq/pLA0Yoy1WPP8WCF7N2RolsgxP5p5HBQR8VSRtji0YztG3wPtUSMurC68OV2H3PZDvjjCm0oRcSTsH1RycMC39duccW+V/cLZrAQi+mBCs=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786622989; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=YG/t+HcpcQUGet+1b50CemxLkna65I9PHKw42uyrhHc=; 
	b=krJzygKomXeCOsduImVgQilha6gxoKgUgnx2b1EqUqB7caICh7PhcTBoLEyXUMDx823z70RXWxzI+BTn9oB6R4hEBMcjKxFVmLxRSBILp21YYj8TqRTmxO7XhQPVgeHWoNea68T5SmYcs13cHz5ggIJiviEttB5uzbRdeINKEsw=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786622989;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=YG/t+HcpcQUGet+1b50CemxLkna65I9PHKw42uyrhHc=;
	b=UV2qW899BJxJM2CuI5lUZDoNuYN+Naqj2O53IC5BCKfYPRloIiS01Sn9PUoOl0TQ
	/Yh+GKNMKRotw2osI8oSQCSv6KzgD3oJJP8SInVK/SLZ1eZW78aJH6tigY0JFhkdBDK
	MQm+erpGNc5YyqFNibM6EgL80a36QD9f1sfowIHg=
Message-ID: <684d46e1-4f10-4034-93c1-d0bbb495e5ab@apertussolutions.com>
Date: Thu, 13 Aug 2026 08:09:46 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: Jason Andryuk <jason.andryuk@amd.com>, Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <6991badc-dcc4-44b9-a048-29eb67c46d2e@apertussolutions.com>
 <7762513c-0d3a-465a-abd9-73e3ba586556@suse.com>
 <29546ca9-1875-4c20-b42b-39c886f3d41c@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <29546ca9-1875-4c20-b42b-39c886f3d41c@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-ef75cf/1786622995-A6CDFAE4-C5D0CF00/0/0
X-purgate-type: clean
X-purgate-size: 2890

On 8/6/26 10:09 AM, Jason Andryuk wrote:
> On 2026-08-06 03:16, Jan Beulich wrote:
>> On 06.08.2026 01:02, Daniel P. Smith wrote:
>>> On 7/28/26 9:22 AM, Jan Beulich wrote:
>>>> @@ -2307,7 +2308,7 @@ argo_init(struct domain *d)
>>>>    {
>>>>        struct argo_domain *argo;
>>>> -    if ( !opt_argo || xsm_argo_enable(d) )
>>>> +    if ( !opt_argo || xsm_argo_enable(XSM_HOOK, d) )
>>>
>>> This question came up on another thread, so thought I might point it out
>>> that when FLASK is in use this can return a nubmer of error codes beyond
>>> an access deny. While I know it's the existing behavior, but if the
>>> error code is anything other than -EPERM, then it's not that the policy
>>> denied the access but something cause a fault in the security server. In
>>> that case the domain is still being allowed to construct with the
>>> assumption that it was a policy deny. At a minimum should the error code
>>> at least get reported, and perhaps it should be passed up to domain
>>> construction to allowing it to make an informed decision on 
>>> construction?
>>
>> Sounds plausible, but definitely wants doing in a separate patch.
> 
> I think this is a mis-use of xsm_argo_enable().  As I wrote in [1], this 
> isn't an access decision, but an ~optimization to skip initializing argo 
> data structures when a domain is not allowed to use argo.
> 

I would have to respectfully disagree. The operation is to initialize 
the domain for argo usage and the access check says do not allow 
initialization if the domain does not have the privilege. This basic 
defense in depth, do not initialize for some thing you should not have 
access to, and thus not just relying on the later checks.

> With Flask, this prints an AVC denial during domain construction when 
> the domain doesn't have argo enabled.  That is misleading as it isn't 
> the domain's action causing the access.  In OpenXT, I wrote a patch to 
> add a noaudit variant to hide the denial.  I didn't upstream it because 
> I didn't really like it.
> 

The customer has ran OpenXT through the code evaluation models that they 
have access to and your patch was flagged. Not for being technically 
incorrect, but raised policy questions on whether is was desirable to 
silence the event.

> The issue is really the conditional initialization of d->argo.  It seems 
> like it would be simpler to always initialized argo for all domains. 
> xsm_argo_enable() would still prevent using it, but internal checking of 
> d->argo could be removed.
> 

Defense in depth is about minimizing risk at cost of a degree of 
overhead. The dance will always be about how to balance the two.

> Regards,
> Jason
> 
> [1] https://lore.kernel.org/xen-devel/758c8410- 
> a18e-45dc-8944-5913e5832397@suse.com/T/ 
> #m149e1571b819a0cf481eea558c6220a5a24d5285



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:14:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:14:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389927.1630516 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUKg-0003yE-Ca; Thu, 13 Aug 2026 12:14:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389927.1630516; Thu, 13 Aug 2026 12:14:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUKg-0003y7-9D; Thu, 13 Aug 2026 12:14:50 +0000
Received: by outflank-mailman (input) for mailman id 1389927;
 Thu, 13 Aug 2026 12:14:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuUKe-0003y1-W4
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:14:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUKd-00D0Us-Vh
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:14:47 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7db531-2eae-0a2a0a5409dd-0a2a45078298-16
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:14:43 +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 <jbeulich@suse.com>)
 id 6a7db533-b4ea-0a2a45070019-d1558035d05c-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:14:43 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-495757ccbc1so5632465e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:14:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5b6616sm6356246f8f.25.2026.08.13.05.14.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 05:14:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786623283; x=1787228083; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=L+02jV2mSv+XtLJQcx8eh646sKwH/hfWr7h2bSp194M=;
        b=VYNlO6LMu771xOlJfb152kFqPxgxCecdvKV2TJ/rhkQQKYIRdIjmX95r7tkNtTw/s/
         DViRm62WTt9ReD6o0k8PWoiKurTj55PUkjJGOaVjLG3GPt1yQw0e4rRs4QtWSQfPE+sW
         jGplsmGbnZLMKJdIFA0H9UO0HOfzauBal9DnHRFVlfvlzZnLg7qIBOj2jz6h481kn7OM
         DUvarNL4uF0EbfzJsqbivVm5CiXoh3Dxcce/xL3nfg7bO/u/JOumXyS9InpKVuFmcQSa
         0Sl8me4F1yyE3MPKFin59YtXy45r0Q+aSj40L73TEKCYV6cWEIlLRoTW49cYV46D9OKX
         WIPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786623283; x=1787228083;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=L+02jV2mSv+XtLJQcx8eh646sKwH/hfWr7h2bSp194M=;
        b=IVO5bDUd/VaQxAoRHMYnErA05LG8BA+xk4m1sADxejVNcHN9XCKXfjLQpatXhLjg0T
         RkloAN+pYK1V1f5or4h+0qe8zslNij+iHMcGhT0G5OsiWi/xUzV8tjIBVKlLczznCzdg
         5UkyXatrCfhFP72WA7pS1IobKKD0oovxYzRu/QcyCoj1tAcOj47Mt4MD8fEo88E7+kzz
         2iVavpIFdIyTJtBGOBTWmtERpASJEHcQISnKN8Ip/s06YWsGi+ypHoSreCvSROorI3d9
         wQcuWfPQi5c+gC3Bi4M3j9HDRIUGNf/EQKiUtB3Luf9Kok3OH+SARmdKtAbbVhs87FEP
         A2bg==
X-Forwarded-Encrypted: i=1; AHgh+RpPUHG4AyN+c/8h8AyeLoAcO1o0uXRatUbGU5MlJkNXhombPdNOlRg03ZverQ4UK98j0Uz5vEK4zAM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxqcRvVaYrKYu8TKQdFyElunLsFXHaUPIagrhiQBvV5BG88FhBI
	d64cwnd0GBjLWB/tt69w8Iddsrn29WlJD3To0BNlJb+UOTxkWE+5eZAVMK5yYmzjTA==
X-Gm-Gg: AR+sD12RuMTzn8We+4kYMHq5bvomofDnCxV/fkZdoeEybfH6lie1CVeh7DcnA+DmCD/
	bV9A1tlPmmIwNKWkjJBM9iA0peOUo+YFzZIBivzo6d2I2ejbT4pY1VQExn6etwrA3KrjiVyoi6P
	9Jo318nnR2XDQS82q0ocMh8KRoyjzkOqhdqjpn15Og65bDIe9Xs3W4ikU89ZZ9i61wqz2+zSkhO
	dAkeltF7AwtFXgmfdUQ8yBCE6dvoTAsdB0ju0lyOVW+WD72tJj1WyKDL+2NlTMQshikeFQcVefZ
	bRzxM31kjzGV8Or0+tdtdeM+JdnklmIsO7DQBqhf8kAvpCtBnzEMRxlgl6Gc+4x8WPb4I3zN/rL
	uJdrc10GZ0UcJgonuCkyUE8N1CXj9DksI0+S+jFOUofCcknnJHWOCYMr3DAXxjlgICUCuJs4unB
	HpjdGckR6DF+EOcyXiUmC/lbNDhGm06yZSyQt8LCx4G4vVlMGdGU8fDCz1c5oNQsxqzs8DIaEln
	Zc27OZRAM7JK+lEFK2Yeo2GEIE2ry0XJkxg3uLuwU7s7WRkOCSV
X-Received: by 2002:a05:600c:3b93:b0:498:ee7:e407 with SMTP id 5b1f17b1804b1-499821985d7mr72175245e9.17.1786623282965;
        Thu, 13 Aug 2026 05:14:42 -0700 (PDT)
Message-ID: <a83cf90c-142a-41ee-a80b-4e849cc804f3@suse.com>
Date: Thu, 13 Aug 2026 14:14:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <07e90200-95b5-413f-9259-7f0481d36521@suse.com>
 <4531d02a-3a37-4c57-ba17-32034ba08cf9@apertussolutions.com>
 <b742fec6-730a-4138-b5f5-7197f24df247@suse.com>
 <e5799ee9-6a97-4ad8-b1c4-6b54e43b7a4d@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <e5799ee9-6a97-4ad8-b1c4-6b54e43b7a4d@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786623283-A5EC6AE4-4BD5C710/0/0
X-purgate-type: clean
X-purgate-size: 2969

On 13.08.2026 13:51, Daniel P. Smith wrote:
> On 8/3/26 6:11 AM, Jan Beulich wrote:
>> On 02.08.2026 17:55, Daniel P. Smith wrote:
>>> On 7/28/26 9:18 AM, Jan Beulich wrote:
>>>> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
>>>> With the function compiled out, its dedicated XSM hook also becomes
>>>> unreachable, so it is similarly guarded.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> ---
>>>> It feels suspicious that the .priv_mapping() check is used for HVM guests
>>>> in shadow mode, but not for ones in HAP mode.
>>>
>>> I believe a hint to it is laying in the comment,
>>>
>>>    /*
>>>     * Let privileged domains transfer the right to map their target
>>>     * domain's pages. This is used to allow stub-domain pvfb export to
>>>     * dom0, until pvfb supports granted mappings. At that time this
>>>     * minor hack can go away.
>>>     */
>>>
>>> Correct me if I am wrong, but get_page_from_l1e() is only used by PV and
>>> HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done
>>> through p2m_get_foreign() which will then be covered by
>>> xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check.
>>
>> Yes, sure; that wasn't the point of my comment. The point was that I'd
>> expect _the same_ hook to be used by the other path. Aiui if you make a
>> policy, you want same situations dealt with the same. Hence there shouldn't
>> be a need to express the same thing two ways.
> 
> But it's not the same, the enforcement mechanism is different. FLASK is 
> an evaluation of Subject/Object/Predicate. In this case the mechanism 
> (software enforced access) that provides the Predicate has enough risk 
> that it warranted itself a separate check to allow fine grained 
> assignment of the operation to a specific domain which was driven by a 
> specific use case.

I don't understand this. What mode a guest is run in (HAP vs shadow)
shouldn't affect what permissions it has. Two distinct hooks means the
guest might change behavior when flipped between hap=0 and hap=1. Which
absolutely shouldn't happen, imo.

>>> I think the question is how to address the TARGET_HACK situation.
>>
>> I fear I don't really know what exactly you mean here.
> 
> Is this path still needed for the pvfb or is it now in use by other use 
> cases. If the former, then close the ability otherwise TARGET_HACK 
> should be renamed to something sensible for general case. Some code 
> documentation might be necessary to help understand why/

Only after grep-ing it has become apparent that TARGET_HACK is something
in Flask. It's entirely invisible outside of Flask, e.g. at the call site
of the hook.

I think the comment is stale in referencing only pvfb, but I'm not really
sure. It is too long ago that I last saw the log message issued there,
and hence I don't recall under what (buggy guest?) conditions it could
surface.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:22:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:22:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389945.1630525 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUSB-00062w-5o; Thu, 13 Aug 2026 12:22:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389945.1630525; Thu, 13 Aug 2026 12:22:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUSB-00062p-2B; Thu, 13 Aug 2026 12:22:35 +0000
Received: by outflank-mailman (input) for mailman id 1389945;
 Thu, 13 Aug 2026 12:22:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wuUS9-00062j-5N
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:22:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUS8-000t8q-IA
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:22:32 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7db705-2eae-0a2a0a5409dd-0a2a450c9b20-2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:22:32 +0200
Received: from [40.107.200.68]
 (helo=CH5PR02CU005.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7db707-f479-0a2a450c0019-286bc8446ea1-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:22:32 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA2PR03MB5788.namprd03.prod.outlook.com (2603:10b6:806:11b::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.12; Thu, 13 Aug
 2026 12:22:29 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.014; Thu, 13 Aug 2026
 12:22:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SJ//nk70yEqCRCrrFqsk9hDBtJrNpjb19sWlLpIdtf2LZ0aTSEVYcRtOt9MxCvUX2PjQB3HJ1em85zfUvOgPOBK+tsM18r8NXLR1Z9mkB0heHosYMNcMkTu7XU0eIC9xlF4Qv7Vdhb1hacJh+5dn/t/MyPHoYTdlPxRGAIq3GoB681qmCwRIzEcHFgKNc6GVLlykSuShR6XRFTv4cwmPfLw1CMBadM4TbI13TJSIBWovFVEvsNzacnJlp57Yo6l3JfA4PQJlLhUn5TeQEUfFIoYWOfxNgFVgm1xEQCDGdloC/dhCPVY8wGnVsfJV6r6Jb73PgaTPcP1GHXX+OWOHrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=McZ5SVT6shrDS5/Lw+9osd/kd9UaN7QK0vOnmdwylYA=;
 b=y0U9yCc/at1CJDFy4fXpFzycM0AEUmFsssFlIJ+xkq9c7RQFdAIxJ3OeRl5ZCgO199UrbDtY+GeETXD8SxzoOtgW5siY12Tp73MVMPf9+WkavoBVeNpHKrwGs8NnkhBTxrLo1RdbZ+fxqfaRIDIjWdDtCT7N0t4jBZJdIWtKf298dmg5w3gMuYOP1TsRh/qRTIN9UTq0bz8hc4GdGAOtG1jcjSEYzdtMi5UlwzdQpDtlNU+JbZ1eJT9Ml5IZX9XOm78ZH8pv4TG3dOxjv9EruRBI5UlwdtI+6EgiUEl3IwRev7+f3+HQhy2vff6AbnkpEKAxSDYIHFHK3yc8bd7CUQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=McZ5SVT6shrDS5/Lw+9osd/kd9UaN7QK0vOnmdwylYA=;
 b=UBWL1S+5aD6m96VQ/zEq15vr7xaXKwoOTwKYTX/4PoMSsM+ADmRU3ZClihCXTIIfOQmmgo8SW8U+ApGGBFkcRjoH3RX0IPu9lMUHRF2Nbw/h3PBZ64R1JV8H4hVd5YRCCBFjabkrBP4tx013N8KIILqT4MUj81dQTYhMjyD0Pt4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <4d9931dd-9369-4b87-9064-aa484ef5a570@citrix.com>
Date: Thu, 13 Aug 2026 13:22:25 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/4] x86: extend update_intpte() to support atomic
 get-and-update
To: Jan Beulich <jbeulich@suse.com>, Kevin Lampis <kevin.lampis@citrix.com>
References: <20260727150615.1373200-1-kevin.lampis@citrix.com>
 <20260727150615.1373200-2-kevin.lampis@citrix.com>
 <6166e2ac-3b8b-4702-ac15-357d1c1a4c56@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <6166e2ac-3b8b-4702-ac15-357d1c1a4c56@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0057.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:153::8) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA2PR03MB5788:EE_
X-MS-Office365-Filtering-Correlation-Id: 10e8ca07-d8f9-4225-b85a-08def9358a7d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|11063799006|56012099006|10067099003|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	WYODp4j/x/b1Jtg6R1M4azS3DFqcDWkZ27kgMXCXf9x3lj/rdv77+0TbsHwVY0GVe0C3YRhsGuloUIO1F9gZdqz5L6Fo6HkQi0MtU8LdoBmWplghK17yCoUy4syj8eXDqACAWQI0sXtM7njnYU9BIaKqFTDPlz72c+RwBhXIjPUWblA3zHjvTBQHiNmHpZAdKVdgOsSyDq67h/rVEwGo2lhLsZE5A2Hxg/Lp7YHlyi3Lm6L8UcAah9Cz+aGij3x4XJAY9SLH5ged7TwosquUWTM13sYMGiQHnfbaGPAiwM0uXgplsoQ8ClZvPg00BPxQyjE7it1DF7xtPfNr7U/BGnRoTsiZevBCW70ftUNdzGDFcPJOfZ0qINBiIb8fV0Mk3y1qukDHz7K8T4ZNtK7MvHQwoPOIgWshBKOMxrELbSDWfPuwhVIz3f06Gjo6QS6MQeT7zFqWyKgAZySflT+3vM/7F0daBccpDzlk8ZCmuQZzn+mr4GDX8+v4LA4IMcM9euLm6xkvH5xpNoidS2dLX+6S9Q1pkXsDiGxEp3QmuWLfd6AkrdgxM1oilB5Uq98bogLjd7146cQVndb9G4gIhDNCzQXn6K1rEElosMrLCQBjFS+zNKbVKhhkJtUTYWylKuzMwwIrtal9rtUWs7Bmhek6ujBc7H8qd5foixYetz8=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Tk9TOUNvK2gzOXljQWNjS1pSdS9DVEdUZWE4U1UyelhldzlQK3ZpU3ZsOEVT?=
 =?utf-8?B?Qm4vTE1qbkMxR0QvU3RkS2xqSzg1aE9jd3NyNWFVeHlCQ0xzamtGNHRUcDdm?=
 =?utf-8?B?dnVwZFdMVmZ5dW9qeC8xb21iWFNwc040dTVxd3R5OGtKR3hOMGc5WS9GZ3Vi?=
 =?utf-8?B?SHNBQWd4bEJwSXhneUlVcm5ZdmVFbWpqanRVTTk1V24wdDNXdm9MQUFMZXhq?=
 =?utf-8?B?RDVJRkhyNXM2Ky93Wi9NVmFQclM1Y25JN3RMZ0ZSZU1iVFV6YlFRRVZ4bmtV?=
 =?utf-8?B?bnBQa2F3LzQrMW1sWm9rOHFpZGNTTjJYUWNDaXVhOVBwSXF5MzVSMHcwUGtr?=
 =?utf-8?B?dmJTazl6N2FyZEg5VDV4bWI2ZVRmbC9wKzJnQ2s0MTdIYWhHckJWNGQ4QS92?=
 =?utf-8?B?Z2FoZWd0WS9oNVBBNUlLMVBVOUZObGtxbXJQQXpZVllKZFNBbDRya2xQYVFS?=
 =?utf-8?B?SVZ6eDF1TDJSSU9rcmdhakZkUFRpZW04K1lnRDU4N2JSWnduVHJxbWxNUzgx?=
 =?utf-8?B?UmJDK1JTVVJOeWdtS1U5bmx3OE5tbnJwd2xlMk9BOWw3dWRZczdPRURGYjZS?=
 =?utf-8?B?Vlc3NjYrdEthVHhIcDlVbDM2eWlRWXlxbDJrMU5wcitnd0dXRTF0ZWsvUktx?=
 =?utf-8?B?MFlUMHgvMUdNb2pBY2lBbUM1TEx3S2xmUjlqS0Q3a01uMnFvdlNyTUZFUC9U?=
 =?utf-8?B?Z2dBdkZKbjh6eUpTcDBwNGhHajRRN3BEdVdobXJMY2YxMHRieElJSTZ1d0RB?=
 =?utf-8?B?NEhoYktDUm95cmUvQW50UUQzMFBoV3hnNFBJRCtJTmhzL1p6cmorY2NidHZF?=
 =?utf-8?B?Y0dyOUtFM2JaZ2xyajVlUGNNcDhVSU5ERzR0VmZhNm53YmpkU3ZLR05acFVp?=
 =?utf-8?B?VnZXTDFmNWRpL3FWVHlBOWo5YVB0VGkxQStwcUdzdDEzbjBJQlJrejJLcExV?=
 =?utf-8?B?SkU2bVQ1SklmZHBpeTkybGJzSzNJV1pmcEtLUlcxR084WDNqM3YyZ1hKS3RK?=
 =?utf-8?B?M2dMUXE2RDIzMW10VXZvTUpmbUVrd2RuV1hQTExrbHdWNmJmUU5XRkhXYzgz?=
 =?utf-8?B?TXBOUjNmNjlLeWdjSldVaVZVMGN5Q1htVm5CTHVXR3cwN1licXVKYXNHcmZF?=
 =?utf-8?B?YUgzcldtTy9UNFBuTGoyQVo1SFpDclJpYnFFbmtuNGh6OC9uNnNBV1ZrUmsr?=
 =?utf-8?B?L2FtQ0pidlVaeWw2Ujk2dnZOYityb0RMSUxISUxkU09qRC9BSHRrWDVXelZF?=
 =?utf-8?B?S1VEcTJmZ0w0SjdxWWJEb1JpemVacHNuUG1LTDJKM1RWVkRhcmNPQjAzU252?=
 =?utf-8?B?RXpjcTNVbEYvZnJ4SDJ5b0xuT3JoakpMaXpUMzJRZ1Z0Z3kxTDcyVXNZVmt3?=
 =?utf-8?B?SUIwMWQrL2xEZy9zaHVBd0p4TlEvTlpmbmExbXdFT0o1cGJjaTcydFpZT2Z0?=
 =?utf-8?B?Mm00TnYvWkl0eG15U2hDakluZDZSdkN6Z0I4SnRCQm0rbmplYjNtKzdRRVMv?=
 =?utf-8?B?RkxjdGtiY2M5ZE9sWGZwcXUxSUt5MGtKYXBWZFd0TklITWVaOHhZMnZwK1hs?=
 =?utf-8?B?ek5wZlpqZzdvR2tDYk96MDVpODBIZDMyMzhoUCtSV0JEeHZPZjB5cEo3ZWo5?=
 =?utf-8?B?elBWUVJWTWJXVnY4TUU2Lzc2dTlyTzREWDZCU2dEUTUzUnd6WGVYbDFrRFUw?=
 =?utf-8?B?RGduOTRnME5md0FTaG00ZVN0a1dGT1dXdExxcU5JMCtLRzhoeDlxaGEzVjlp?=
 =?utf-8?B?UTl1OVBTVHRPYlZlTk5jbDQ5SEp4amlXT0VLaWh2d0VZTkNxK3lwNUlhem9x?=
 =?utf-8?B?WUZweEVWR2FKWS9uSDRZamdLS29sM040RVJLQm1DODM4Zi8rRmNpYnBDSlRy?=
 =?utf-8?B?SFVEZUloMnUvOVRjeEFnQjhYWWtrUDdLM1NnT0wwVER3NnFVNitmZlhZQVJu?=
 =?utf-8?B?U1NHMVJiLzlKT09MOWJReUUzQStYaTVFbzV4OUsxck11c1A3WENZdGVoU1Z5?=
 =?utf-8?B?WktwR2NMTW1XUWtOUFdzdVlPY0JwNlIwV2R5L1FXWjlDNGZNWVArQTNDaWpt?=
 =?utf-8?B?YW5XOCtvMVRDOEM1MFNObGRjaGhGdlg4YndsdmlabHhMWkhzV3RNQndNRG0y?=
 =?utf-8?B?eFg1eU9xZGZ5U0ViU3VVNUFFS3dHZlhGVStrakFrS1g3VU1xV05ZbFpVWkVr?=
 =?utf-8?B?VEdSb2tvUFVMMU5SdER0YmpMMDFQS1pRVjlPdENaNytPbUMybVdIYUdSQldk?=
 =?utf-8?B?bzdRb0FBSHArR2pBcHNYUmtmdUlGVi95WExnOTBOYXVVemdTcHlROVVJT0Yz?=
 =?utf-8?B?ZUlUaWVmVW1Tay8yaXBIYWkrOEgzdm5jekpycHNpS0ZONmtYMk5uQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 10e8ca07-d8f9-4225-b85a-08def9358a7d
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 12:22:28.6310
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 563N4qF8X6uYfL0LoZBHnf03yauAXOCqeaTHngyCkA2vmg0X3si4T9VF7mA7Vrsq9yk1oj/QzW+Qun6h5oKXDINXOcuITmVusuCpOZ3uEz8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5788
X-purgate-ID: tlsNG-d25034/1786623752-50B3DA5B-01066367/0/0
X-purgate-type: clean
X-purgate-size: 2003

On 13/08/2026 1:01 pm, Jan Beulich wrote:
> On 27.07.2026 17:06, Kevin Lampis wrote:
>> --- a/xen/arch/x86/pv/mm.h
>> +++ b/xen/arch/x86/pv/mm.h
>> @@ -66,13 +66,14 @@ static inline intpte_t paging_cmpxchg_guest_entry(
>>   * How to write an entry to the guest pagetables.
>>   * Returns false for failure (pointer not valid), true for success.
>>   */
>> -static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new,
>> -                                 mfn_t mfn, struct vcpu *v, bool preserve_ad)
>> +static inline bool update_intpte(intpte_t *p, intpte_t *old, intpte_t new,
>> +                                 mfn_t mfn, struct vcpu *v, bool preserve_ad,
>> +                                 bool use_cmpxchg)
> No 2nd boolean parameter, please. (use_cmpxchg also doesn't look to be an
> overly good name; "swap" maybe?)

This is half of a patch that's been in the XenServer queue for decades
for other purposes.  (TLB-flush avoidance based on A/D being clear, for
which you must use some form of atomic, but it relies on dom0 being
trusted not to clear the A/D bits in isolation.)

I agree that we don't want more booleans.  Your flags proposal looks
like the right way to go.

XenServer's pre-existing usecase could get away with XCHG.  I think it
was wired into CMPXCHG simply because that already existed.  This new
usecase probably wants to be XCHG too.  I don't think "please preserve
AD while swapping X for Y and also tell the the old value you found"
makes much sense at the hypercall level at least.

Furthermore, now that the return value is unused, we could return the
actual old value to anyone who cares, which avoids turning the input
"old" value into a pointer.

~Andrew

P.S. looking at the preserve_ad logic, I think it ought to be tightened
to only permit A/D becoming set, because that's the only direction that
hardware will move the bits.  A/D becoming clear is a race against
something which is not the pagewalker.


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:42:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:42:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389960.1630533 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUlg-0000yq-N4; Thu, 13 Aug 2026 12:42:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389960.1630533; Thu, 13 Aug 2026 12:42:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUlg-0000yj-KC; Thu, 13 Aug 2026 12:42:44 +0000
Received: by outflank-mailman (input) for mailman id 1389960;
 Thu, 13 Aug 2026 12:42:44 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuUlg-0000yd-0W
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:42:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUlf-00HLcK-DF
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:42:43 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dbbc0-2eae-0a2a0a5409dd-0a2a4509d5a4-20
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:42:43 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dbbc1-be1a-0a2a45090019-888fbc335271-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:42:43 +0200
Received: by mx.zohomail.com with SMTPS id 1786624949098989.6670064198162;
 Thu, 13 Aug 2026 05:42:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786624952; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=gaHJa66Rjuhi6xoH52Jgiw/U4Juq8kTHXEs64E9hqfZ7UO7wlLPV6spF0dfvjO7kIW1omcxc313Pvd9ecP6XZ9rJwCQVxn1qsx+bF0H7ajAApDhNpyLTOVoIHIHHSj8xY+Y9WIBSA/xjcaz87EgQIXf6N/OZ1Q0pHE457OPR0P0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786624952; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=Za9EcdLJWXnTEiY37uj/GrBDPCX3LBcarDK7TVNkNuQ=; 
	b=PCZj+AvVcRfbhH+CQz2GtXK6tQ/qGacvOmuBINsa4KV0Vsf/i2O+RpezaAjF2Rpazd2lusO8qyJEjQik9ptvx6ZPitoCoMMyJUU2ZdNsU57n9xdCovmflfdfqLjKEhhb1MwY/W3WB5AFIXX9glOeYTgsAhDyoojEhSv1JUWyQMg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786624952;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Za9EcdLJWXnTEiY37uj/GrBDPCX3LBcarDK7TVNkNuQ=;
	b=D6WfJgJajg3aewcKKyLV5eDLK2q6e7fn62R/HKdrAGXy5hOOjAk+h67sNxuLwlME
	Zpjf98BtxjJWxCSXP3/924a0LQr8csdiLItofctDjSM86fh1tevZMzU67jrw51T+sNX
	hOcu6TvHY1j+FLCOaiG5BibhWxNluQIvAFrsTgJI=
Message-ID: <7828588f-38d7-4039-95c3-8ffd386a8509@apertussolutions.com>
Date: Thu, 13 Aug 2026 08:42:30 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
 <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
 <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-bad1c0/1786624963-39CC7034-F1FD7D18/0/0
X-purgate-type: clean
X-purgate-size: 2464



On 8/6/26 3:36 AM, Jan Beulich wrote:
> On 06.08.2026 03:10, Daniel P. Smith wrote:
>> On 7/28/26 9:23 AM, Jan Beulich wrote:
>>> --- a/xen/xsm/flask/hooks.c
>>> +++ b/xen/xsm/flask/hooks.c
>>> @@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
>>>    
>>>    #ifdef CONFIG_HAS_PIRQ
>>>    
>>> -static int cf_check flask_map_domain_pirq(struct domain *d)
>>> +static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
>>>    {
>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
>>> -}
>>> -
>>> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
>>> -{
>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>>> +    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>>>    }
>>>    
>>>    #endif /* CONFIG_HAS_PIRQ */
>>>
>>
>> I am not opposed to collapsing the calls as long as the semantic is not
>> lost, which I feel the reuse of the xsm_map_domain_pirq does looses it
>> much less provides an opportunity for confusion. Something like
>> xsm_domain_pirq(..., access) makes more semantic sense to me, as it
>> would read, grant domain pirq access T/F.
> 
> In fact I was as well wondering about naming (and a possible name change)
> here. I decided against it because of the other hooks (touched by patch
> 19), which all follow a similar model of their names really more expressing
> the "positive" form than the "negative" one. Further, entirely losing "map"
> from the name also doesn't look quite right, as physdev_{,un}map_pirq() is
> where they're called from. To follow the naming of some of the other hook,
> maybe xsm_domain_pirq_mapping(..., bool map)? Possibly even with "domain"
> dropped from the name, fully fitting xsm_io{mem,port}_mapping()? Which
> would then further raise the question whether patch 19 should maybe rename
> the parameters of those two hooks to "map" at the same time.
> 

Sound like you and I were running through the same argument with 
ourselves, except you went right and I went left.

For me, I find the false case of xsm_map_domain_pirq(..., access) reads 
a bit weird, "Can the target map domain pirq access=false?" I do like 
your mapping suggestion along with the parameter rename to map. It 
changes the reading to "Is target allowed map(true)/unmap(false) for the 
domain pirq mapping?" This could be carried through to the other cases.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:44:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:44:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389969.1630542 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUn0-0001SW-19; Thu, 13 Aug 2026 12:44:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389969.1630542; Thu, 13 Aug 2026 12:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUmz-0001SP-Tv; Thu, 13 Aug 2026 12:44:05 +0000
Received: by outflank-mailman (input) for mailman id 1389969;
 Thu, 13 Aug 2026 12:44:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wuUmy-0001SH-S8
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:44:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUmx-000x9u-W7
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:44:04 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7dbc12-8faa-0a2a0a5109dd-0a2a4501eb28-4
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:44:03 +0200
Received: from [209.85.128.177] (helo=mail-yw1-f177.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7dbc12-5984-0a2a45010019-d15580b1e56e-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:44:03 +0200
Received: by mail-yw1-f177.google.com with SMTP id
 00721157ae682-81dfdbd86d1so20356327b3.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:44:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786625042; cv=none;
        d=google.com; s=arc-20260327;
        b=jGoRatopwTF0sl/RYwDmfsQzV/ism8ldZ4Vo4w1ECcgNJG2naStg3MU0CP2SZNZ+ym
         mDNqcnDKc4ZfDG8gLFyLTLmYU+347DU2oz7PmVHKb67srYkBVXBn6Fg4OAKZW87Ziugh
         u5xJX8B4+l91JN14hvaQQ2DO07LZax6g9ODddrxiPd7hVWRcVWjv/Kat8JkUIb8DhRBK
         QV54AG/S5uQ1lqBEW5z0P5BX5Txgs/lduE56NGr3zPJKy6lDxPxVOPdyWh2NPbdT9KKS
         QAZ8B/cfjDpqSRKdKUn1ETtgU0YSNt+coWMS/oFuyf3nXd9L4BFBV05Mxs/EmnE9ztE0
         OyLQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=4/Rde2C4jxdMN8BwFIfhLNo8P5/cVcL0piK60vZwB34=;
        fh=BuXLlZlolQM134F1k1/sGsHUv8OnQcq1/qbdathgLBE=;
        b=H+IRO3ZspGLE8GCvAnEU+f8NAnMvBMx6/LZ1HuxBJOC5ITTK+nRrpVhfDnwO0y0Sg3
         1DZuFnRrIwDPVhSik8VGXaNPX+TkqB1q7NVJF6p80UBL6tF5rqnG5EPk29oLmxOIrFL/
         grTPiL45c58RXtAAE9x/NV5GULFuvrfHvD6bSEz+OcXb64RcsR3McLhQKc0JThoP5a74
         XaV/sxcA4a1D3fw6Uh4wSPjMTpBedNL5oDhozRJMin1NYVABgzgGxB4QBtUexhoYhmkM
         /XRVM2xHDOL3TgkcIn+DIEij4z3umk1Klo2cOrylE0Qwmmug/PRHbrZq/HpvLYfWOWsV
         MYrA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786625042; x=1787229842; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=4/Rde2C4jxdMN8BwFIfhLNo8P5/cVcL0piK60vZwB34=;
        b=L4Iu+RVWTi+PWu57r0JLFhYo/LbnaWBm/K5VbJk0luZtDBUvhmCKDzD81LX/erGzJZ
         XX92YQipSu4TN/96kPcyrpWet/uINlwObzxMDsWyeCohEsOfwvcTNTtxmb2nx/vRF0Kx
         iKP+He4U+SnZJssyodJ2bnDwxqTcuMn5LD4URj8y0CZY0sYCA/n+Wgdg7S0xb4ehku2k
         oml6U3WRQf/3QC0Pu2PlqHI3cnvFqq9JBkLT2A8mPEYAFFaS9Uq2Wzqw2MP21/Ic9bPM
         RHrmCSNwN1Ep/quyBVpGT6/wfEvkHnZJ1PdgU+cgt30lPM2pibM8gPQNh7sNeWicZDB9
         DHnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786625042; x=1787229842;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=4/Rde2C4jxdMN8BwFIfhLNo8P5/cVcL0piK60vZwB34=;
        b=KMPY8I7re4aUdoPun1KSjDQ+kos5o/ZQ6CTjwTkKZgVywKPW38uo/NF6p/CjXogQW0
         V2aN2MU1vpxD9fzUHlmO5WBTUKjD51g43cliSTimyhmI+yGIuh0egDiQAodmv2K1sABb
         vT2h2sE/uhkq3hIkM1Pnfeb6/eWXwQuNU2BEwhoO3yWt9Sjx+6LtS8+vf+ZepOz54l7G
         Ye7fOv5DkpCeHx+Uz7Z55jkypehcCqJFCIG4AiacRTZC9dlnSL2R4GwiR/lneTB0Ao82
         zIMK5cth/sJsJ1VVRucIHcVaxht2H9fBWhqfQBaZyp1OA3gOP2WWjA8ylmbB/Re4/k2l
         geJw==
X-Gm-Message-State: AOJu0YweKB0DFuNci5w6n4g1Xq+rmzUXAYMQNQewxiIk1uoVOzTkbZ8c
	bkA2feteo1Axt/rMZ8H9F1GalMHcX6gmZOyvx3DDXUb0QnI1Isp3pvQnqKwWOewpmgOHjP8J5tP
	O4B7z7qiFSg42LBM5JK1ebFGIqXSL4bIcqpys
X-Gm-Gg: AR+sD12olbwWJnqD17oE/p2+CqywhnTkWS+o6rFCoHWqtE16X2EIJjfpws3IvaGAJ+z
	VNPPaXIGp52HWMvy6EYOS2ZW+NEdLVhW06PlSbK8WLvueN5UlmeetNHfu+Rw2Wc0XoWI9APOZQh
	AwhpPbEL83+Umow/xbcAf6QErG4iqfLryL5SYvVQzvM6mDgI8+myxkqF2jywyhjtBAeuAKMcjxX
	SdZcUcyF1OHA9/q0CU5fg1spn0Qg3y/qxvB3sbxL+mM2h9i5wXEqL0btDm7b1jcONHkwhOqVibl
	BhzVRxwEdKayd+Vv2Dppp+eY7qSSHhYip1Pv7HQTn+W1C8KdAmCbeMmAHXo23DrnxFOsI51fxJ1
	5ut7ODHCvxn9K
X-Received: by 2002:a05:690c:c747:b0:826:8128:3ba8 with SMTP id
 00721157ae682-8347577f07emr20014587b3.17.1786625042378; Thu, 13 Aug 2026
 05:44:02 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com> <20260810103018.54564-11-frediano.ziglio@citrix.com>
In-Reply-To: <20260810103018.54564-11-frediano.ziglio@citrix.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Thu, 13 Aug 2026 13:43:48 +0100
X-Gm-Features: AUfX_mzECzi-eavEjyTnQbPDuGeff0qS1iKApcxrAJ42SApVi4Jq65zwmjtRAAk
Message-ID: <CAHt6W4cQZRfwdWSOzf8vkBgn+m2N+tp+aOA6YKnD1ndA8rObCQ@mail.gmail.com>
Subject: Re: [PATCH Linux v6 10/10] xen/privcmd: Add new ABI to allow copying
 foreign memory
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-d62444/1786625043-BDA7E757-777B5805/0/0
X-purgate-type: clean
X-purgate-size: 407

On Mon, 10 Aug 2026 at 11:30, Frediano Ziglio <freddy77@gmail.com> wrote:
>
> This new ABI allows to copy foreign domain memory to/from a buffer.
> This avoids having to map/copy/unmap foreign memory which is
> expensive.
> This operation is done particularly when migrating VMs.
>
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Typo in subject line, it's v10, not v6.

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:51:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:51:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389977.1630551 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUuH-0003XC-NO; Thu, 13 Aug 2026 12:51:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389977.1630551; Thu, 13 Aug 2026 12:51:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUuH-0003X5-K5; Thu, 13 Aug 2026 12:51:37 +0000
Received: by outflank-mailman (input) for mailman id 1389977;
 Thu, 13 Aug 2026 12:51:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuUuG-0003Wx-18
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:51:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUuE-003Bmt-Nu
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:51:34 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dbdc5-bab6-0a2a0a5309dd-0a2a45049c1e-26
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:51:30 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dbdd2-b57f-0a2a45040019-d1558035b97e-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:51:30 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4954a2e73a9so12595125e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:51:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49982131261sm105839415e9.8.2026.08.13.05.51.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 05:51:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786625490; x=1787230290; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=fmsAuvA1xU0GopwYnrPDvUMnEhRCq6saU29mAJvlakI=;
        b=fIJNotv52tdAvDzsnIkxfQeeJ5N0spIkWNHGGnPBuuMwlmHewOZbbII/PfV3IRjxWx
         8RpsKmlR6+zROy7p18+Af37XSwy66IZrmiwuuOehsDYdnz9rGUAO1Gm+MIVce4vW8V+9
         JmiojSmB3sS5kRg5YVPW1T6B8PFL4COruRtRdnegyV2pNhOSl7AroLiwpPOyz+H9SzI3
         i7kTTeY6B/430VwdzteasZdLOQKnHa4O5G6OS2yRYSpPJLf3vztsKjzXmed8SE3Ydnjo
         ZcrX2J2H0REBvcP4QLUjz3NIbAxB1k3QOEXIKRQl97XTJlLc4cAN6zThxlDI+qeF0UnK
         nKqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786625490; x=1787230290;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=fmsAuvA1xU0GopwYnrPDvUMnEhRCq6saU29mAJvlakI=;
        b=KB0bk8yJyEvYaI2bH93o23wRY/yFzXK4yC8N2Oxqc+jUArWq1vdv6rW//jqIf8itx8
         NN4zwWxtyukrQIlFrS1qnI0dejZkCGSYre31zykNS7fU+5pEO0+6NswPEpAcALb+hBct
         rtUUJ5Eo7e4S87t3sL2U6YEnEhsR4KcaTp/Y37RLOjrZ5LLxil8xOcNHyHV0jMuhTReS
         myBuqEaCf5uQI0GE9xOKYgfueRfm4vdeoSvBe9fiuVT3uNg+eW1sze8HbcEAuiGkSujO
         DyHkpv6xNawLDNHLgZ7N0EKJh13Id0okYTuncrCU6NXJev6CVp0I+Oe1UMIu5thgsf3+
         VTiA==
X-Forwarded-Encrypted: i=1; AHgh+RqoY0uT9cSNjYV9joBTw3/LCZtgKRw+HTP4Dj+51P7qJWMT1fem0dWwUdoUJq9t4zWu42ud3Y47GDI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyn59pBgylJTdevJMqFTQ2IMj5Fp/yZuG4mMrmsXhYfviJhod45
	4jerrCQ6d7HWiSjLJoWczBKxOz8d9oxOTXgonkYTPttH8thVbt2/+67sxf/3fgpdhw==
X-Gm-Gg: AR+sD10eDgWKpIA4bBRMk9UBWaP4JjXFXOYVuf6R8kV7fHsP109ZDlRSSFt11u6KK53
	luZPHLxIc4Y2tAg/hS2kw9VTtDutaWOioiahmpx8NT7MQVHUAYtyXkofIKj41DrhXEGzCsxZelx
	Tvg9UgCpz6ydfPLziNxv9Jdbjkhtksxi5O09iiIT1l75SaCwoFuyuJfPQy66exEBuXJHO3uKEGe
	3zylyjqrZzMQKPo0hVWM5jt/7XrmJVtwhTQcE0Wt1y8RHkN+6tWtKIbDJKjA0rzB/4o4cqksRQh
	4qH8Brkf81dhKR4R1jgg3gEiki2UW50K/fdIPFWqZg6nYMqwudJ3zb0UumVeZWg0RJCJ2GQsH4w
	i+odNBxFW+nbxqJERhTQ0LHa8X6KxJFeBii7SyC8VNE5cf18YK/RrGjtMicOn5b0ChmeOkNmJUb
	QsodPr64B0VBg7BKCUVtBzVnY2WD+tqmEchUJiOE8NgNvH35PjkraqqT1X2iEdFkjZzOE9mdooe
	zsJEV2trx+dW4a7BAx86zPeH2QBWpcKJugIEOu/45er+ZD28uSR
X-Received: by 2002:a05:600c:5494:b0:499:83f1:398 with SMTP id 5b1f17b1804b1-49983f10706mr35687265e9.9.1786625489979;
        Thu, 13 Aug 2026 05:51:29 -0700 (PDT)
Message-ID: <630afaa0-f4b4-474f-8763-fa6ee377f34c@suse.com>
Date: Thu, 13 Aug 2026 14:51:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] x86: extend do_mmu_update() to support returning the
 old PTE value
To: Kevin Lampis <kevin.lampis@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, xen-devel@lists.xenproject.org
References: <20260727150615.1373200-1-kevin.lampis@citrix.com>
 <20260727150615.1373200-4-kevin.lampis@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260727150615.1373200-4-kevin.lampis@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786625490-51AD0B50-0381B76D/0/0
X-purgate-type: clean
X-purgate-size: 4403

On 27.07.2026 17:06, Kevin Lampis wrote:
> A new parameter write_back_old when set will return the old PTE value.
> 
> - The new PTE value in req.val must be 0, this is for clearing only.

As per Teddy's comment it needs to be determined whether we really want to
limit this to "clear". Even if we do for now, naming of the new sub-op may
want to be such that relaxing later is an option.

> - The PRESERVE_AD flag is rejected with -EINVAL because preserving
>   Accessed/Dirty bits into a zero'ed PTE doesn't make sense.
> 
> - Only l1 PTEs are supported because they are the most frequent and have the
>   biggest performance impact.
> 
> - The old PTE value is passed back to the guest through the req.val field
> 
> If the write_back_old flag is not set then the old behavior is preserved
>   do_mmu_update -> mod_l1_entry -> UPDATE_ENTRY -> paging_write_guest_entry
> 
> The new get_and_clear call chain looks like this
>   do_mmu_update -> mod_l1_entry -> update_intpte -> paging_cmpxchg_guest_entry
> 
> Signed-off-by: Kevin Lampis <kevin.lampis@citrix.com>

Apart from the above only a couple of cosmetic comments, as based on other
replies to this series things will likely change quite a bit here.

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3988,11 +3988,12 @@ long do_mmuext_op(
>      return rc;
>  }
>  
> -long do_mmu_update(
> +static long __do_mmu_update(

No need for two leading underscores (making the identifier a reserved one),
when one will do. In fact with this becoming a local helper, I question the
need for a prefix altogether: Just mmu_update() would likely do.

> @@ -4144,13 +4145,41 @@ long do_mmu_update(
>                  switch ( page->u.inuse.type_info & PGT_type_mask )
>                  {
>                  case PGT_l1_page_table:
> -                    rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
> -                                      cmd, v, pg_owner, NULL);
> +                {

Why this curly brace, when there are no declarations?

> +                    if ( !write_back_old )
> +                        rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
> +                                          cmd, v, pg_owner, NULL);

Even this little bit of churn could be avoided if you inserted ...

> +                    else

                    if ( write_back_old )

... above the existing code, and ...

> +                    {
> +                        l1_pgentry_t ol1e;
> +                        if ( unlikely(req.val != 0 ||
> +                                      cmd == MMU_PT_UPDATE_PRESERVE_AD) )
> +                        {
> +                            rc = -EINVAL;
> +                            break;
> +                        }
> +
> +                        rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
> +                                          cmd, v, pg_owner, &ol1e);
> +
> +                        if ( !rc )
> +                        {
> +                            req.val = ol1e.l1;
> +                            if ( unlikely(copy_to_guest(ureqs, &req, 1)) )
> +                                rc = -EFAULT;
> +                        }

... a separate "break" here.

> +                    }
>                      break;
> +                }
>  
>                  case PGT_l2_page_table:
>                      if ( unlikely(pg_owner != pt_owner) )
>                          break;
> +                    if ( unlikely(write_back_old) )
> +                    {
> +                        rc = -EINVAL;

rc already is -EINVAL when make it here, isn't it? That's also leveraged by
the owner check visible in context. (Same for the further cases below,
obviously.)

> @@ -4198,6 +4237,11 @@ long do_mmu_update(
>                      break;
>  
>                  case PGT_writable_page:
> +                    if ( unlikely(write_back_old) )
> +                    {
> +                        rc = -EINVAL;
> +                        break;
> +                    }
>                      perfc_incr(writable_mmu_updates);
>                      paging_write_guest_entry(v, va, req.val, mfn);
>                      rc = 0;

Below here there's a copy of this PGT_writable_page handling, which looks
as if it also wants to reject write_back_old being true.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:55:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:55:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389989.1630560 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUyN-0004Ae-8O; Thu, 13 Aug 2026 12:55:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389989.1630560; Thu, 13 Aug 2026 12:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUyN-0004AX-5Q; Thu, 13 Aug 2026 12:55:51 +0000
Received: by outflank-mailman (input) for mailman id 1389989;
 Thu, 13 Aug 2026 12:55:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuUyL-0004AR-Sz
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:55:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUyK-00AK3W-3J
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:55:48 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dbed0-2eae-0a2a0a5409dd-0a2a4501829a-18
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:55:48 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dbed3-5984-0a2a45010019-d155dd2ee1af-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:55:48 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so1933319f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:55:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5af19fsm6188778f8f.24.2026.08.13.05.55.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 05:55:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786625747; x=1787230547; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0/9D/zXrSjiAs3KCpNbEnQiiqOUli4vpiLhHO3g9Q80=;
        b=AE8BlLf9Yu1bIMFaQjGZOZPeWlFYRHTO0WiEN5erh6CYkvVKql9uFaeEqJAAl1B0zr
         7G/SOdoqYl+BXAvOVYUaXTR3ddatfm9HtVp7VK417FuPIlQgVRwS3uOuwGB51kT/hibQ
         IlV6IZyLPaR5jnMDZO2YKc8GYI8sMkIBLo6T4XDzHE9kMOWshf0otTAS2NWFEzXYEf7I
         wObTWtpeq5fAnatfIKGZAL/KynhN5IHwdhYdXPvrJyj8eALaxAOO1PuXcwOvH2RuqzDg
         +2mQSBk+dKq63PuC0pUk8QymqZxsToURIaaQID//h4hWIOzGzzoXcEdqVHk5wuq/X6HA
         2BBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786625747; x=1787230547;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=0/9D/zXrSjiAs3KCpNbEnQiiqOUli4vpiLhHO3g9Q80=;
        b=AKlYA0MyJd7Qp4knyxTxfEZ6BlfoizWobeEIRjyUKugW8ZwCuvFYmy91HpEw+oDx0d
         UcCJNIlSFT9vbwo7Nmn4rdVkFREUxl7HexYYGskHUawBkOAvG5XaHOZdlfiQ08JeP0Pa
         pliVOk8v2rW/p8UJmXd7kmk4JmbRBwn1+S390A6xRr5neBXydGJOeb5RsobJzShHScDo
         hSR1N5vlIQK1xxbA06agHUidonaxQVTOgmDZK3qE4fHvgDUW43WTPKzdjZdRInzrXhFy
         IWtalR6k/uVDC8RwY8s9hItGVHCYJQtWXCAeWrwnBGMGJos0w8BHt1ICZLjkSjFd3hkg
         P9Og==
X-Forwarded-Encrypted: i=1; AHgh+RpG2g6PY4TGBJuld824y+/ERhGatFAoprswkC/+036Pltmw2nSEjFFjk3TpFqXG7q1Jc+E1h4MJpis=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjRRoj0GnIgLSFNmnoSSoo4Cep+MhCbqYtAL3ePt/XeQWSb5AR
	N31NrTOkNxu3QDscUpaW660jiu0sPPHLTgPr3DX2W/D8doBVRcRQR+Hc9bntHZzDkQ==
X-Gm-Gg: AR+sD13qaKvOtvjw4NnJJdd9DTaDavVoMu6JuEuyIoYqcYB+BvJnbWzuIn36GlGSZ+X
	h4cg2lTw3okj+ysddjOyFGDGYHXpdyrdBUAT4lZszK7FFuhVz1zCqXtG3J36jWjjyLEnMFTDBjP
	kT4Z8xwMYz3S37NgyhKkumLo5gIFBUuLilxaDNhPdX3g1e/UR6ojCC3TA13MOhCOM2YDZhcmONm
	ik1tJuifYzpMzuIbd6q2FY0J2nbY0/WawfzaL3NG1yWxAdpobgAn20CXBKY3kxmYCLdppYRCvM6
	3EnjnqJmazIxTcC+WSq/vn1QtQXC30JPJOPLCiF1r87LXLVfq3DT94C6Nxm4CHMFN+BkG6+Ui7K
	Obn3+fheAzAOu3zSkchxVljHao2kQ4Rt1MlWv8OWYlbDeNO8xFQ8H/Td/iUMEAZ4w0y9I58YI/m
	L85LS6SE7KAeSChKfYyKQRLVoDYyq9FvesVLvMj6uC/32HOvytjAXvDjiLfZ8X2KL8rmQcFJZ4T
	MjiZ8M7+4Z1g6TsJh+qndVikTvE7Oy9AZU5H8jNksh5lyMpIJFR
X-Received: by 2002:a05:6000:25c2:b0:47f:8fb6:c32f with SMTP id ffacd0b85a97d-48159fffba3mr6991817f8f.24.1786625747535;
        Thu, 13 Aug 2026 05:55:47 -0700 (PDT)
Message-ID: <328a151a-2989-4357-93c0-fb36dbe2d688@suse.com>
Date: Thu, 13 Aug 2026 14:55:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/4] x86: add new pte_get_and_clear hypercall
To: Kevin Lampis <kevin.lampis@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, xen-devel@lists.xenproject.org
References: <20260727150615.1373200-1-kevin.lampis@citrix.com>
 <20260727150615.1373200-5-kevin.lampis@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260727150615.1373200-5-kevin.lampis@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786625748-1D272757-F71463DE/0/0
X-purgate-type: clean
X-purgate-size: 499

On 27.07.2026 17:06, Kevin Lampis wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3993,6 +3993,7 @@ static long __do_mmu_update(
>      unsigned int count,
>      XEN_GUEST_HANDLE_PARAM(uint) pdone,
>      unsigned int foreigndom,
> +    unsigned int op,
>      bool write_back_old)
>  {

Likely irrelevant anyway when this becomes a new sub-op instead of a new
top-level hypercall, but: "op" is redundant with "write_back_old". Such
redundancy wants avoiding.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 12:56:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 12:56:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1389996.1630570 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUzA-0004c5-Gv; Thu, 13 Aug 2026 12:56:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1389996.1630570; Thu, 13 Aug 2026 12:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuUzA-0004by-Ct; Thu, 13 Aug 2026 12:56:40 +0000
Received: by outflank-mailman (input) for mailman id 1389996;
 Thu, 13 Aug 2026 12:56:38 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wuUz8-0004bf-IA
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 12:56:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuUz7-00AKGB-QH
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:56:37 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7dbef6-bab6-0a2a0a5309dd-0a2a450a998a-20
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:56:37 +0200
Received: from [209.85.128.181] (helo=mail-yw1-f181.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7dbf04-f2d2-0a2a450a0019-d15580b5cdba-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:56:37 +0200
Received: by mail-yw1-f181.google.com with SMTP id
 00721157ae682-824af9535c8so12438057b3.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 05:56:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786625796; cv=none;
        d=google.com; s=arc-20260327;
        b=ks2xryQh1+UQUU4XEQawZAy72cfItU+PUrJKKOYQO7rH4QHFudzTsPyKJnTDuBEKwF
         hGK9PisWM7D0kLLaNxlYYR1A66AP+NaenmcdVosMG25sAcT+ZrNFPIp4FxykkMrYdI4r
         3aXVst4KHnU+UsD0VvrsDne+7Qwdi/g3ajKP5L7a55J6mPW4qIINZSJPygWsPkIs0r1V
         ZB3noKfvxMIoyPMjPVVGKcSmI15qCeaDuhsKYvo+f8F+I16ml+/3wPSeROM8L9MTiFl0
         MI/d5zm4rM+zs/RS95PhO2LFgzptexlTifIM7Mz3/iAL9Z8eSO5hb7L+zm+JKOhXujwY
         83EQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=wBkVfFa3I1a4xw0FRjxrPE/2JG7Xw2hq+rikZWfqA0M=;
        fh=9Qi9GuP6RaIdUPqcByINS4Lh6Dqx/46KOIm9RXXqrVw=;
        b=dzQM58jv1Pi55+cz4rAoFrm4Z48D07SpHcN3eHw568/GYUbt47gspWuFZuQBdJuRgt
         0ROJnQP05JziYKdVLjr4a3BWRbSvUPaRBAEdrsxw+TpPGDE2xac1jMrIV+8yDNr0CJp5
         M1DgjOP2J8YohePFTRWLwouua4MuTPxMXfauoCCvM707ewPC3WgCajbozgEmfWldDqwv
         rVfMPu45frH9jIMK5mPwm387yXCJFVhUVFOn/kcMtQkgy8ZEWGVVqGSps9icTK3QEX5j
         jBb9bdKQRj4mmKHoQFaaaup9ibwTB8SzsWMDtxQ6iILF8zxV0gfnBRYl4fFSQR30kyo8
         Sq6g==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786625796; x=1787230596; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wBkVfFa3I1a4xw0FRjxrPE/2JG7Xw2hq+rikZWfqA0M=;
        b=pwXFiYmDo2s5oBzs9+tSNRqelhrYv2fvYM2FdD+hGu9smhTrvuEGUNboNQZbM08Biz
         XbRV6abeRKQhoQUpbQ+1QrRp86m9moO/BkjMPaO8LA4X+iVNF7zUnJ/td+rY52oLpFtk
         mPHqBMSz0eo+J/lr+RkWslkD6BV2vaAC9F2qyA6MDFB+O1Qznn9Grv1fD8wVqhoWuavv
         /evn0HiuyDW/rmd/7YtYaiCuoKcZmsxu7Vu1sxb63/oZwWxMbMttSnHAgCBBl95q0e5M
         fQph7SBReNP+QfMdMOpZXCMvkcRSZKNQ4eYaWOH9RlfqmrNHuzY8PDJKMVxyLvt2uk8Q
         oNFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786625796; x=1787230596;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=wBkVfFa3I1a4xw0FRjxrPE/2JG7Xw2hq+rikZWfqA0M=;
        b=XPmhhVfnLd0ND/2jWU6UKZcXzwEknFfU9TlkRNM+EANlGaldz87uOS7cR3q7rBe7o7
         GxvUdhjRjUgoqZUssXltaJoxQqwU+kz5763wVjc20uecZj7Un+1/a9LknNA8Jwbp+U71
         9AiGYOYz2oFQoh5NEvLFmpDE7p8QsMSkg/zcMvh0//2V7e7Uouf7ztwcE2vjIIE5JyDG
         Taxhdj2lNEelY6d4BKDEsL3z15UXDexO3QSFtd3wDmjRP6YDySf2YH0O9fTQ+t3jmjBi
         udXZn4wNPUNc0pHBO/73kTUHii6j3ebGd9FEuC1n4gbH7JxRcl4Mb7Iw22+1VLvy4PK4
         huaw==
X-Forwarded-Encrypted: i=1; AHgh+RoKa3JCvGcO+89bgqDSsryztfz2Bc3grzpg9q0JeFSJOwXb6HzvxwZ8BQ078BN7M0l5Vvgz6r6JPZ8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNU2cZ575Dl+blaZPtum78L1Xak8baldLJdjFcjBzBGjlXlTzG
	U3AYRXpDvFfyFrfCvRKAikBjNZPD7Na235mG1+1TscfGAuTH+r0VgrBWrq7LVY9QG1+g3N3qP1H
	RBxwaB/pivE4wVtjRgnYDAyI1SxUlOzg=
X-Gm-Gg: AR+sD11PX8MGxRwR8QWKxEKMGHsT9sst3jixTpnGMN7YP7mQuq2rwSoc04WoFSP7BtJ
	MsURc2VaCA6wYAcGTAAzIInkiXanuQImFKswK1UiiEsTd57yXNnn6zAb4Hi/VxDX8Wmnlt83a0n
	5SbheMM7qpTp6P7kOv5StgAzPX28vrcI0mf87EMBMERWvBm0jd7jZ4FSIWULv8eEqmYv1HnJmNY
	sFWC9+EYCTAqXNBmJAnItHZLps7BfEepZnf36Z7rxHlXG14nGY0P5E4TXrjy1TyuS82WFpzzMwl
	GeO8MWHWt2KM418wWxeeDT6BAnw1dLnfEF2kXEej0L/7e49QZRIbBiC8f5XSE3jkVxldxoVqnse
	Y
X-Received: by 2002:a05:690c:7482:b0:80b:de9c:8a2c with SMTP id
 00721157ae682-83471fe4b47mr31617347b3.8.1786625796241; Thu, 13 Aug 2026
 05:56:36 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-3-frediano.ziglio@citrix.com> <d41d0fa2-7273-4723-a5e0-6424d030cf0a@citrix.com>
 <1101df6e-bb36-4766-9b11-365d1043342b@suse.com> <c76d69db-f976-4c7a-b653-ab1f13854db3@citrix.com>
In-Reply-To: <c76d69db-f976-4c7a-b653-ab1f13854db3@citrix.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Thu, 13 Aug 2026 13:56:25 +0100
X-Gm-Features: AUfX_myvkcqCRqFABV5n8e6MqkECT5YiSTPHktqS8DcTG2KFnh2SXs156X5LrsY
Message-ID: <CAHt6W4dBBKDeSTQnDzjmngU7An_ncJri_oBoTpChz_xQcfsrfQ@mail.gmail.com>
Subject: Re: [PATCH v10 2/10] libs/guest: move batch_pfns into a separate structure
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, Frediano Ziglio <frediano.ziglio@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786625797-4B0D9CFC-1B8CCA08/0/0
X-purgate-type: clean
X-purgate-size: 2333

On Thu, 13 Aug 2026 at 12:48, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 13/08/2026 12:27 pm, Jan Beulich wrote:
> > On 13.08.2026 13:08, Andrew Cooper wrote:
> >> On 10/08/2026 11:30 am, Frediano Ziglio wrote:
> >>> Preparation for a followup patch "libs/guest: allocate various migration
> >>> arrays just once".
> >>>
> >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> >>> Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
> >> Coverity thinks this change has memory corruption.  I have to admit that
> >> I'm not completely sure why it's noticed now; possibly because now it
> >> can see the size of batch_pfns[] where previously it couldn't
> > I had looked into that too, and I'm puzzled that ...
> >
> >> ** CID 1700057:       Memory - corruptions  (OVERRUN)
> >> /tools/libs/guest/xg_sr_save.c: 284           in add_to_batch()
> >> _____________________________________________________________________________________________
> >> *** CID 1700057:         Memory - corruptions  (OVERRUN)
> >> /tools/libs/guest/xg_sr_save.c: 284             in add_to_batch()
> >> 278         int rc = 0;
> >> 279
> >> 280         if ( ctx->save.nr_batch_pfns == MAX_BATCH_SIZE )
> >> 281             rc = flush_batch(ctx);
> > ... the tool can't spot that flush_batch() resets ctx->save.nr_batch_pfns
> > to 0 in the success case. And ...
> >
> >> 283         if ( rc == 0 )
> > ... only the success case is what matters.
>
> Hmm.  Both flush_batch() and write_batch() are static, so fully visible
> to Coverity.
>
> I guess this means that Coverity failed to figure out the properties of
> write_batch(); it is a complicated function, even if it has become less
> complicated recently.
>
> I'm still advocating to remove the Valgrind logic rather than extend it
> in patch 3, and that will remove flush_batch() which might simplify things.
>
> ~Andrew

Hi,
   as said by Jan this is a false positive from Coverity.

It's not guaranteed that Coverity will detect that it's not an issue
if either valgrind macro is not called and/or flush_batch calling
write_batch, I would either test the change or simply add an explicit
Coverity comment.
If we decide to remove support for valgrind then what about the
valgrind patch on the series (4/10) ?

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 13:00:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 13:00:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390007.1630579 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV2g-0006Wy-VU; Thu, 13 Aug 2026 13:00:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390007.1630579; Thu, 13 Aug 2026 13:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV2g-0006Wr-RU; Thu, 13 Aug 2026 13:00:18 +0000
Received: by outflank-mailman (input) for mailman id 1390007;
 Thu, 13 Aug 2026 13:00:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MYTl=GG=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wuV2f-0006Wl-4r
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:00:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuV2e-00ALGa-Hn
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:00:16 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=MYTl=GG=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a7dbfd9-bab6-0a2a0a5309dd-0a2a4508e752-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:00:16 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=MYTl=GG=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a7dbfe0-f659-0a2a45080019-8c4da68ad59c-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:00:16 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id CDF19A017F;
 Thu, 13 Aug 2026 15:00:15 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id cOvAuh6-fCEF; Thu, 13 Aug 2026 15:00:15 +0200 (CEST)
Received: from end (144.105.204.77.rev.sfr.net [77.204.105.144])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 6F159A017E;
 Thu, 13 Aug 2026 15:00:15 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wuV2c-00000003c1A-0bBL; Thu, 13 Aug 2026 15:00:14 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786626015; bh=kzaD9UzPodCXgkww/e8Ygm7kqHXy/jA1wRppLTsEiQM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Hm7j4elDc4QEEssDYs1zmeKzsqMPUsl/nfJhtYndlt7PCb7W1I0rLP9XxMFp+MvKx
	 6oeFvNvtwuMbjbCQXE7BqGoQCN4hxc0VneXygKwkKhlrFdROafbb0xVN3hFsOG2CXK
	 7er4BQGHxrmxrfAlhp6k/abxJjoRVOwf6UAd8TZWZ8f8EDtvsdBCJlqRGYHjNMePGa
	 QZiPNLVN75DKyq9jzaHi1xeYnh4ij/D4GUV272pf7lAQa0QEJ2aef+KNy//i4DFpJ3
	 bX7gC8/lGKk68pK0YVE2OVAM6vV8/n0hQHzMmtY+5qVtYMpBqjbAc7LaBaek3SWe2+
	 Ju1VriP1uSE9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786626015; bh=kzaD9UzPodCXgkww/e8Ygm7kqHXy/jA1wRppLTsEiQM=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=Hm7j4elDc4QEEssDYs1zmeKzsqMPUsl/nfJhtYndlt7PCb7W1I0rLP9XxMFp+MvKx
	 6oeFvNvtwuMbjbCQXE7BqGoQCN4hxc0VneXygKwkKhlrFdROafbb0xVN3hFsOG2CXK
	 7er4BQGHxrmxrfAlhp6k/abxJjoRVOwf6UAd8TZWZ8f8EDtvsdBCJlqRGYHjNMePGa
	 QZiPNLVN75DKyq9jzaHi1xeYnh4ij/D4GUV272pf7lAQa0QEJ2aef+KNy//i4DFpJ3
	 bX7gC8/lGKk68pK0YVE2OVAM6vV8/n0hQHzMmtY+5qVtYMpBqjbAc7LaBaek3SWe2+
	 Ju1VriP1uSE9g==
Date: Thu, 13 Aug 2026 15:00:14 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 0/5] stubdom: remove grub-pv
Message-ID: <an2_3vPMvBFFtMW-@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org,
	Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
References: <20260720081833.4122182-1-jgross@suse.com>
 <f8481120-00c5-411e-ad66-38ff550bdd47@suse.com>
 <anz6XwsWjoNeHBxY@end>
 <2f2cc724-92d8-476d-bd85-5529fb365389@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2f2cc724-92d8-476d-bd85-5529fb365389@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-c1860d/1786626016-CFED287B-A28234F0/0/0
X-purgate-type: clean
X-purgate-size: 5999

Jan Beulich, le jeu. 13 août 2026 07:54:39 +0200, a ecrit:
> On 13.08.2026 00:57, Samuel Thibault wrote:
> > Juergen Gross, le mer. 12 août 2026 10:16:58 +0200, a ecrit:
> >> Any feedback?
> > 
> > I'm fine with it: grub0.9x is really old, grub2 works alright in my use
> > cases and is maintained.
> 
> Was this perhaps meant to be / include an Acked-by: ?

Yes, it is an

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Thanks

> Jan
> 
> >> On 20.07.26 10:18, Juergen Gross wrote:
> >>> The grub-pv stubdoms (32- and 64-bit) are disabled by default since
> >>> several years now.
> >>>
> >>> Remove them in order to enable removing quite some more code from Xen.
> >>> In case someone is really depending on grub-pv, they can easily take it
> >>> from an older Xen build, as there is no Xen version dependency in
> >>> grub-pv (a version built 3 years ago has been tested to still work
> >>> with current 4.23 staging Xen).
> >>>
> >>> Note that after this series has been committed, some additional
> >>> cleanup is possible by removing stubdom libpci and zlib support, but
> >>> this will require a modification of Mini-OS depending on these patches.
> >>>
> >>> Changes in V2:
> >>> - moved one hunk from patch 2 to patch 1
> >>>
> >>> Juergen Gross (5):
> >>>    stubdom: remove support for grub-pv
> >>>    stubdom: remove support for building in 32-bit mode
> >>>    stubdom: remove building of libxenguest and libxenctrl
> >>>    docs: remove stale stubdom entries from stubdom.txt
> >>>    tools/libxenguest: remove Mini-OS specific parts
> >>>
> >>>   Makefile                                      |    6 -
> >>>   config/Stubdom.mk.in                          |    3 -
> >>>   docs/misc/stubdom.txt                         |   69 -
> >>>   stubdom/.gitignore                            |    1 -
> >>>   stubdom/Makefile                              |   69 +-
> >>>   stubdom/configure                             |   65 -
> >>>   stubdom/configure.ac                          |    2 -
> >>>   stubdom/grub.patches/00cvs                    | 1022 -----
> >>>   stubdom/grub.patches/10graphics.diff          | 2297 -----------
> >>>   stubdom/grub.patches/11graphics-keyboard.diff |   13 -
> >>>   stubdom/grub.patches/20print_func.diff        |   52 -
> >>>   stubdom/grub.patches/30savedefault.diff       |  186 -
> >>>   .../grub.patches/40ext3_256byte_inode.diff    |  114 -
> >>>   stubdom/grub.patches/50fs_fulldisk.diff       |   72 -
> >>>   stubdom/grub.patches/60ext4.diff              |  474 ---
> >>>   stubdom/grub.patches/61btrfs.diff             | 3499 -----------------
> >>>   stubdom/grub.patches/70compiler_warnings.diff |   45 -
> >>>   stubdom/grub.patches/99minios                 | 1570 --------
> >>>   stubdom/grub/Makefile                         |   88 -
> >>>   stubdom/grub/boot-x86_32.S                    |  112 -
> >>>   stubdom/grub/boot-x86_64.S                    |  108 -
> >>>   stubdom/grub/config.h                         |   12 -
> >>>   stubdom/grub/kexec.c                          |  434 --
> >>>   stubdom/grub/mini-os.c                        |  771 ----
> >>>   stubdom/grub/mini-os.h                        |    7 -
> >>>   stubdom/grub/minios.cfg                       |    4 -
> >>>   stubdom/grub/osdep.h                          |   30 -
> >>>   tools/libs/guest/Makefile.common              |   15 -
> >>>   tools/libs/guest/xg_dom_decompress_unsafe.c   |   48 -
> >>>   tools/libs/guest/xg_dom_decompress_unsafe.h   |   28 -
> >>>   .../guest/xg_dom_decompress_unsafe_bzip2.c    |   14 -
> >>>   .../libs/guest/xg_dom_decompress_unsafe_lz4.c |   39 -
> >>>   .../guest/xg_dom_decompress_unsafe_lzma.c     |   14 -
> >>>   .../guest/xg_dom_decompress_unsafe_lzo1x.c    |   44 -
> >>>   .../libs/guest/xg_dom_decompress_unsafe_xz.c  |   46 -
> >>>   .../guest/xg_dom_decompress_unsafe_zstd.c     |   44 -
> >>>   36 files changed, 1 insertion(+), 11416 deletions(-)
> >>>   delete mode 100644 stubdom/grub.patches/00cvs
> >>>   delete mode 100644 stubdom/grub.patches/10graphics.diff
> >>>   delete mode 100644 stubdom/grub.patches/11graphics-keyboard.diff
> >>>   delete mode 100644 stubdom/grub.patches/20print_func.diff
> >>>   delete mode 100644 stubdom/grub.patches/30savedefault.diff
> >>>   delete mode 100644 stubdom/grub.patches/40ext3_256byte_inode.diff
> >>>   delete mode 100644 stubdom/grub.patches/50fs_fulldisk.diff
> >>>   delete mode 100644 stubdom/grub.patches/60ext4.diff
> >>>   delete mode 100644 stubdom/grub.patches/61btrfs.diff
> >>>   delete mode 100644 stubdom/grub.patches/70compiler_warnings.diff
> >>>   delete mode 100644 stubdom/grub.patches/99minios
> >>>   delete mode 100644 stubdom/grub/Makefile
> >>>   delete mode 100644 stubdom/grub/boot-x86_32.S
> >>>   delete mode 100644 stubdom/grub/boot-x86_64.S
> >>>   delete mode 100644 stubdom/grub/config.h
> >>>   delete mode 100644 stubdom/grub/kexec.c
> >>>   delete mode 100644 stubdom/grub/mini-os.c
> >>>   delete mode 100644 stubdom/grub/mini-os.h
> >>>   delete mode 100644 stubdom/grub/minios.cfg
> >>>   delete mode 100644 stubdom/grub/osdep.h
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c
> >>>   delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
> >>>
> >>
> > 
> > 
> > 
> > 
> > 
> > 
> 

-- 
Samuel
Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux...
(By cbbrown@io.org, Christopher Browne)


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 13:02:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 13:02:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390016.1630586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV4V-00072V-9H; Thu, 13 Aug 2026 13:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390016.1630586; Thu, 13 Aug 2026 13:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV4V-00072O-6X; Thu, 13 Aug 2026 13:02:11 +0000
Received: by outflank-mailman (input) for mailman id 1390016;
 Thu, 13 Aug 2026 13:02:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuV4U-00072G-8X
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:02:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuV4T-00HOjM-0K
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:02:09 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dc044-e002-0a2a0a5209dd-0a2a4509ae9e-14
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:02:08 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dc050-be1a-0a2a45090019-d1558029a90b-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:02:08 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4954a9e8490so5544525e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 06:02:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981b03d07sm73221975e9.2.2026.08.13.06.02.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 06:02:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786626128; x=1787230928; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=oM3Rke40yRt7mpEL6FbNRO3FcRJa7m4vqYv1zr9ftyM=;
        b=FvT/E+2NeYtaPMDwQ3SZVXVw4Ubcv4ijrObAMhx0bdti4TcF9FpWM11bHsDFNJ7h6s
         PXsZnnpuUCNBX+gUQwpT1ElO6aDz0+alYfi36WU9Kd2QvIApOrUhEZWEewAa8QuOGfkR
         9U843KqUrD4Huml/9+XCUrtR2VwBtuOUacf3RKDMLmHBRBWpyKDb0OI1N5Tg52nDsPmR
         3bsuPdVW/7kTq9IOtVf/kTZMAUh29EZ8BSZohRJHQj6IGlLgYmf5yot3YVxs1p3FHMhx
         cS69ccO2kkzQ0j0FzREPGB31dU/7NJGyDHhgsMNkBnXNvUyZ9z4BlUhI7OoYaZCEEpvm
         gqgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786626128; x=1787230928;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=oM3Rke40yRt7mpEL6FbNRO3FcRJa7m4vqYv1zr9ftyM=;
        b=MF6CsZC92+nachMR518X7mnRBMR2SU9UNzwOjSElVBDVXmKLwonhtombj7nTqz9LRg
         bIHwYiwUlEwJLDIaJ2e6oUxKw2igUcweqmHy9FFLXN4TLMT3FGfjB0FUVSHuZXHVQWn1
         QtrGRt7ZrfvtK9+BS0fZv2PTuD4+Fvj5Og31bhj/KKa4NokyPp7fJ2JY1bu2oMJQutF7
         Zb2UROO4Uuq3ywlblPhrq3kCuo5C/kjMhmoVfVtWOCH6qjBJfW21BPew3Pzueb4c5b1a
         /vdLfdPqJOb6aoiG4ImS7iFzLgsWytNX9qRCDHT75pJFd7VrZV4iE4d/ePimVz0GGbZQ
         T9GA==
X-Forwarded-Encrypted: i=1; AHgh+RpjhkdWgrVws4aoWVYPnrBhRp+Eihg45dLn/eAd6HS1ZJrZag4d2SxOzSzmYRrnYGr2L1ZueIf+Tg0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzzLHNkq9CD1poP/33P4si+S+lekjMfpej2Lm0o8aSQ3danH/lV
	Go5b2/0hI/IkgFOEyyzaBOJTvcxTxiEWyL8xOhPBdPQlw1efqyGSMY4MdelkXen3zQTwnIls+D7
	mJZ6XIA==
X-Gm-Gg: AR+sD10IWRNdkC06FEGgUOngJMi3cscYZBwYsynffTwodSpRds0b5TvzWp8BCebjVM0
	cWNRtkG/DSiWA5eFZOfjnzR26GVFdvQ3d1QRA8uBS+RjkYpHDmRNHzjnTN/6xGjDbsPZ2phkZVv
	bRIqtfl4C0NaNtoXs27qx6DnkqDD+NzWvSCNwHze2G8zs+tV3zt3kcaIvub56lRTlD1Vu+ydlqo
	QqIwNt0jjOGyoSc3ydtLE8fjlCuYbukgfuuqxjhzqS56deVDteP03qW8jr/SZaZYjrpfYblt3Ky
	fW+SI9jmLRpMIPCyfiRCayEnzHLnJ8d9SJnBv4Tf127eXjmLXZGXZxWB4UsjrsGJU9BnTMnZ/9X
	idtfBqlf4lUkEfYUASbGSGvrIDsNHqvJuCwVL0t6bIly/oxjPYLala2rdYJ3aRTuQbVSjC9x3yE
	Q/7rLbTfC7bsWa0IgadLqyqka6gDXEIihKIsEp1TnaqATVzTVuD3TO05h8JM1hfEvSV12I/GIe7
	JmZdZCT4Wv0Bqqu0nX/yfs+6fTWpIJPb08gjEmd3c60GbD49Tbi
X-Received: by 2002:a05:600c:4708:b0:499:596b:2e91 with SMTP id 5b1f17b1804b1-49982200a77mr54607905e9.3.1786626127708;
        Thu, 13 Aug 2026 06:02:07 -0700 (PDT)
Message-ID: <9e1a3252-c126-4c09-8425-feee14a1237b@suse.com>
Date: Thu, 13 Aug 2026 15:02:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
 <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
 <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
 <7828588f-38d7-4039-95c3-8ffd386a8509@apertussolutions.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7828588f-38d7-4039-95c3-8ffd386a8509@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786626128-BF4D3034-82BADE70/0/0
X-purgate-type: clean
X-purgate-size: 2770

On 13.08.2026 14:42, Daniel P. Smith wrote:
> On 8/6/26 3:36 AM, Jan Beulich wrote:
>> On 06.08.2026 03:10, Daniel P. Smith wrote:
>>> On 7/28/26 9:23 AM, Jan Beulich wrote:
>>>> --- a/xen/xsm/flask/hooks.c
>>>> +++ b/xen/xsm/flask/hooks.c
>>>> @@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
>>>>    
>>>>    #ifdef CONFIG_HAS_PIRQ
>>>>    
>>>> -static int cf_check flask_map_domain_pirq(struct domain *d)
>>>> +static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
>>>>    {
>>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
>>>> -}
>>>> -
>>>> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
>>>> -{
>>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>>>> +    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>>>>    }
>>>>    
>>>>    #endif /* CONFIG_HAS_PIRQ */
>>>>
>>>
>>> I am not opposed to collapsing the calls as long as the semantic is not
>>> lost, which I feel the reuse of the xsm_map_domain_pirq does looses it
>>> much less provides an opportunity for confusion. Something like
>>> xsm_domain_pirq(..., access) makes more semantic sense to me, as it
>>> would read, grant domain pirq access T/F.
>>
>> In fact I was as well wondering about naming (and a possible name change)
>> here. I decided against it because of the other hooks (touched by patch
>> 19), which all follow a similar model of their names really more expressing
>> the "positive" form than the "negative" one. Further, entirely losing "map"
>> from the name also doesn't look quite right, as physdev_{,un}map_pirq() is
>> where they're called from. To follow the naming of some of the other hook,
>> maybe xsm_domain_pirq_mapping(..., bool map)? Possibly even with "domain"
>> dropped from the name, fully fitting xsm_io{mem,port}_mapping()? Which
>> would then further raise the question whether patch 19 should maybe rename
>> the parameters of those two hooks to "map" at the same time.
> 
> Sound like you and I were running through the same argument with 
> ourselves, except you went right and I went left.
> 
> For me, I find the false case of xsm_map_domain_pirq(..., access) reads 
> a bit weird, "Can the target map domain pirq access=false?" I do like 
> your mapping suggestion along with the parameter rename to map. It 
> changes the reading to "Is target allowed map(true)/unmap(false) for the 
> domain pirq mapping?" This could be carried through to the other cases.

Will do. As to patch 19: I'm inclined to leave the parameters as "allow"
in dummy.h, but change at least the flask_io{mem,port}_mapping() ones to
"map". Will that be okay with you? Else what scheme would you prefer?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 13:02:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 13:02:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390025.1630596 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV5C-0007bO-KR; Thu, 13 Aug 2026 13:02:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390025.1630596; Thu, 13 Aug 2026 13:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV5C-0007bG-HQ; Thu, 13 Aug 2026 13:02:54 +0000
Received: by outflank-mailman (input) for mailman id 1390025;
 Thu, 13 Aug 2026 13:02:54 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuV5B-0007b5-Uo
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:02:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuV5B-00HOxz-BY
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:02:53 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dc072-e002-0a2a0a5209dd-0a2a450899ee-40
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:02:53 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dc078-f659-0a2a45080019-888fbc3352b8-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:02:50 +0200
Received: by mx.zohomail.com with SMTPS id 1786626154505860.584720482219;
 Thu, 13 Aug 2026 06:02:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786626157; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=LO7naBJAVJPHMMZ+jEBMpA11LsMd5Zn4ZHhMxVSvaKfCPH7zeUFwy56eAsrxkq6tGbAU1K84mm30DrJSD3IiNSJtDb0w3Khil9+7ZotTWyASeMz1i49oz2B8JgEUZ0uj4L1Z7687incXCQ8fJHXf/TOb7iYx9wk+kS4ThH6YUsU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786626157; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=jaBbrgXVN92ZqCMwNK561lgwvvP8N+6PwEbaM1sPxAk=; 
	b=fpTkP1W0GYeySeJ9NvvN/D/H24x5tGn0Eq4FQikFraO5iwy7sRsXdyUcZXop+JxiTEgyvgSG0DGGcAXEjdcFWy46mn2mrqqzqOwNL8KvaJvLMkpnZasgV3M5HJrYqe2v8E6950b1KslU9GuhNG1/lSWU9uIYn8DvM5fLSeh62f8=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786626157;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=jaBbrgXVN92ZqCMwNK561lgwvvP8N+6PwEbaM1sPxAk=;
	b=U+ZJq57lSVSTtOLBiiSxdP5H3RDAZg0ge9TFwaGIe1qvnuCFf/0K6/IoFbk6kC6G
	gcpuMTf7dv7UlVm/E92go77x/MbsB44kqA9BHODIAnAKI8NSCvCfpN9FxJSbDJk6usI
	1UDSJMnFRDvVZkOXYuyoSXxm39iD3duicaZWuezg=
Message-ID: <f7ff827b-fb15-432c-8a5b-d5e73531a526@apertussolutions.com>
Date: Thu, 13 Aug 2026 09:02:35 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <07e90200-95b5-413f-9259-7f0481d36521@suse.com>
 <4531d02a-3a37-4c57-ba17-32034ba08cf9@apertussolutions.com>
 <b742fec6-730a-4138-b5f5-7197f24df247@suse.com>
 <e5799ee9-6a97-4ad8-b1c4-6b54e43b7a4d@apertussolutions.com>
 <a83cf90c-142a-41ee-a80b-4e849cc804f3@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <a83cf90c-142a-41ee-a80b-4e849cc804f3@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-c1860d/1786626170-CED4087B-732F5D25/0/0
X-purgate-type: clean
X-purgate-size: 3852



On 8/13/26 8:14 AM, Jan Beulich wrote:
> On 13.08.2026 13:51, Daniel P. Smith wrote:
>> On 8/3/26 6:11 AM, Jan Beulich wrote:
>>> On 02.08.2026 17:55, Daniel P. Smith wrote:
>>>> On 7/28/26 9:18 AM, Jan Beulich wrote:
>>>>> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
>>>>> With the function compiled out, its dedicated XSM hook also becomes
>>>>> unreachable, so it is similarly guarded.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> It feels suspicious that the .priv_mapping() check is used for HVM guests
>>>>> in shadow mode, but not for ones in HAP mode.
>>>>
>>>> I believe a hint to it is laying in the comment,
>>>>
>>>>     /*
>>>>      * Let privileged domains transfer the right to map their target
>>>>      * domain's pages. This is used to allow stub-domain pvfb export to
>>>>      * dom0, until pvfb supports granted mappings. At that time this
>>>>      * minor hack can go away.
>>>>      */
>>>>
>>>> Correct me if I am wrong, but get_page_from_l1e() is only used by PV and
>>>> HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done
>>>> through p2m_get_foreign() which will then be covered by
>>>> xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check.
>>>
>>> Yes, sure; that wasn't the point of my comment. The point was that I'd
>>> expect _the same_ hook to be used by the other path. Aiui if you make a
>>> policy, you want same situations dealt with the same. Hence there shouldn't
>>> be a need to express the same thing two ways.
>>
>> But it's not the same, the enforcement mechanism is different. FLASK is
>> an evaluation of Subject/Object/Predicate. In this case the mechanism
>> (software enforced access) that provides the Predicate has enough risk
>> that it warranted itself a separate check to allow fine grained
>> assignment of the operation to a specific domain which was driven by a
>> specific use case.
> 
> I don't understand this. What mode a guest is run in (HAP vs shadow)
> shouldn't affect what permissions it has. Two distinct hooks means the
> guest might change behavior when flipped between hap=0 and hap=1. Which
> absolutely shouldn't happen, imo.
> 

Oh, it most certainly does affect how a security policy wants to be 
written. Certain mechanisms have properties that provide certain 
assurances and the security architect/policy writer may not want to 
allow the access via mechanisms deemed to have an unacceptable risk.

>>>> I think the question is how to address the TARGET_HACK situation.
>>>
>>> I fear I don't really know what exactly you mean here.
>>
>> Is this path still needed for the pvfb or is it now in use by other use
>> cases. If the former, then close the ability otherwise TARGET_HACK
>> should be renamed to something sensible for general case. Some code
>> documentation might be necessary to help understand why/
> 
> Only after grep-ing it has become apparent that TARGET_HACK is something
> in Flask. It's entirely invisible outside of Flask, e.g. at the call site
> of the hook.
> 

Correct.

> I think the comment is stale in referencing only pvfb, but I'm not really
> sure. It is too long ago that I last saw the log message issued there,
> and hence I don't recall under what (buggy guest?) conditions it could
> surface.
> 

Agreed, that's why I was trying to say that it appears to have been 
created based on that specific situation. My question is, did this 
situation evolve to no longer be a one-off or can we close the ability 
to map memory this way. The comment alludes that it was a temporary 
method of access, but I haven't studied the path to this check or what 
situations could follow that path today. I have a suspicion that it's no 
longer a one-off situation.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 13:06:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 13:06:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390036.1630604 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV8J-0008Jh-0h; Thu, 13 Aug 2026 13:06:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390036.1630604; Thu, 13 Aug 2026 13:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuV8I-0008Ja-UL; Thu, 13 Aug 2026 13:06:06 +0000
Received: by outflank-mailman (input) for mailman id 1390036;
 Thu, 13 Aug 2026 13:06:05 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wuV8H-0008JU-Pp
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 13:06:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuV8H-00D9y6-6V
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:06:05 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dc123-bab6-0a2a0a5309dd-0a2a4504c416-40
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:06:05 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a7dc137-b57f-0a2a45040019-888fbc3352c1-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 15:06:01 +0200
Received: by mx.zohomail.com with SMTPS id 1786626347572260.334875759615;
 Thu, 13 Aug 2026 06:05:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1786626350; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=LiUSGrmhk2ZhvxRfEFpgKDlczechpijQwejuBUmUWCPqyEK6UBWozlhj4js6lPZYf97Om800VALQ2PW2VLypI2FhG0E0Pl4NA8cL5IqMmQWDmJjKPQuCEsGeJ3tdLrahkk1F8ryONfIws3tOQ1x6BTwzCkF8oivl2yvTJxFbEnQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1786626350; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=kXW7GqtSaqRdViB1IIgSUOxZ0Dvm1wRhEC//zZj7GcU=; 
	b=AQD+gDfYuxVRq9BmzFBOj6u/ZWVbnSpnsh5by0/h/KjMyH3FknXohcAr/wklynOpeOVCRIZjfZCkMN5NULR2Rzo6TnKI4uSEwIh10Fk7uLVnYDMyNPbhymp61bepq7kJUb+qtVZVY75ChMwnLe2c52MXJHJCW9fR6HAipjWc9+g=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1786626349;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=kXW7GqtSaqRdViB1IIgSUOxZ0Dvm1wRhEC//zZj7GcU=;
	b=SvcSVIoFzMq1Gku6+lMtOnAAcUaoquc3hKti12y30KQBKPjfQukuoaZgtMsK9JMQ
	4UkM94c6YoF+jG60df/T6c7YZo0UahxVC6UglrGF0ceZ/LhiQgwYTAu4YL0SJPYoZgD
	XSxsiD1cyM3n6sRfRRrIOF19KpaPEVJtbvLT8egM=
Message-ID: <7b70fa40-0b1b-4c84-b6a7-d4505e2af0de@apertussolutions.com>
Date: Thu, 13 Aug 2026 09:05:49 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <c973c612-153d-413b-a6c8-aeacd25f28a8@suse.com>
 <f99a285e-bd3d-4d8d-94ef-997c238c7f85@apertussolutions.com>
 <274a27cb-13f0-47c3-aa73-1534925dc350@suse.com>
 <7828588f-38d7-4039-95c3-8ffd386a8509@apertussolutions.com>
 <9e1a3252-c126-4c09-8425-feee14a1237b@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <9e1a3252-c126-4c09-8425-feee14a1237b@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-ebf023/1786626361-C26CAB50-B76F904E/0/0
X-purgate-type: clean
X-purgate-size: 3023



On 8/13/26 9:02 AM, Jan Beulich wrote:
> On 13.08.2026 14:42, Daniel P. Smith wrote:
>> On 8/6/26 3:36 AM, Jan Beulich wrote:
>>> On 06.08.2026 03:10, Daniel P. Smith wrote:
>>>> On 7/28/26 9:23 AM, Jan Beulich wrote:
>>>>> --- a/xen/xsm/flask/hooks.c
>>>>> +++ b/xen/xsm/flask/hooks.c
>>>>> @@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
>>>>>     
>>>>>     #ifdef CONFIG_HAS_PIRQ
>>>>>     
>>>>> -static int cf_check flask_map_domain_pirq(struct domain *d)
>>>>> +static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
>>>>>     {
>>>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
>>>>> -}
>>>>> -
>>>>> -static int cf_check flask_unmap_domain_pirq(struct domain *d)
>>>>> -{
>>>>> -    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
>>>>> +    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
>>>>>     }
>>>>>     
>>>>>     #endif /* CONFIG_HAS_PIRQ */
>>>>>
>>>>
>>>> I am not opposed to collapsing the calls as long as the semantic is not
>>>> lost, which I feel the reuse of the xsm_map_domain_pirq does looses it
>>>> much less provides an opportunity for confusion. Something like
>>>> xsm_domain_pirq(..., access) makes more semantic sense to me, as it
>>>> would read, grant domain pirq access T/F.
>>>
>>> In fact I was as well wondering about naming (and a possible name change)
>>> here. I decided against it because of the other hooks (touched by patch
>>> 19), which all follow a similar model of their names really more expressing
>>> the "positive" form than the "negative" one. Further, entirely losing "map"
>>> from the name also doesn't look quite right, as physdev_{,un}map_pirq() is
>>> where they're called from. To follow the naming of some of the other hook,
>>> maybe xsm_domain_pirq_mapping(..., bool map)? Possibly even with "domain"
>>> dropped from the name, fully fitting xsm_io{mem,port}_mapping()? Which
>>> would then further raise the question whether patch 19 should maybe rename
>>> the parameters of those two hooks to "map" at the same time.
>>
>> Sound like you and I were running through the same argument with
>> ourselves, except you went right and I went left.
>>
>> For me, I find the false case of xsm_map_domain_pirq(..., access) reads
>> a bit weird, "Can the target map domain pirq access=false?" I do like
>> your mapping suggestion along with the parameter rename to map. It
>> changes the reading to "Is target allowed map(true)/unmap(false) for the
>> domain pirq mapping?" This could be carried through to the other cases.
> 
> Will do. As to patch 19: I'm inclined to leave the parameters as "allow"
> in dummy.h, but change at least the flask_io{mem,port}_mapping() ones to
> "map". Will that be okay with you? Else what scheme would you prefer?

I am good with that. Those weren't bad, it was this one that I found 
that the original name really didn't work well with the collapse.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Thu Aug 13 14:03:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 14:03:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390073.1630613 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuW1g-0003RE-2l; Thu, 13 Aug 2026 14:03:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390073.1630613; Thu, 13 Aug 2026 14:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuW1g-0003R7-01; Thu, 13 Aug 2026 14:03:20 +0000
Received: by outflank-mailman (input) for mailman id 1390073;
 Thu, 13 Aug 2026 14:03:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wuW1e-0003R1-5n
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:03:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuW1d-00HZiu-3n
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:03:17 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7dce9f-bab6-0a2a0a5309dd-0a2a45099be2-28
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:03:16 +0200
Received: from [209.85.128.172] (helo=mail-yw1-f172.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7dcea3-be1a-0a2a45090019-d15580acc893-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:03:16 +0200
Received: by mail-yw1-f172.google.com with SMTP id
 00721157ae682-81f36179dd5so10605467b3.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 07:03:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786629795; cv=none;
        d=google.com; s=arc-20260327;
        b=igB5IDyzr93WiYxNuj293fS883n6MSY0S382ujMN4ATe1J5O3L480z1og1u4hwQcSL
         X26CsN4luZ0qWFsLBtsLwqjgFmJF2BypdWNPAB23aSEVe9/Ht0XmzyBTA6ETHNYcrpIp
         5c8sDXi5F20UWV96YvggRoyqKZA/rpsBIpnPX+liLsv//BNJ5tu0Dr/Twc+xGsuNWlYM
         4486zZAaoeoaV9+D9QJJofR+OR6t+9ZbWZYJgDDmyqBK+Thq39YBTWcGJdOfNywXrpKS
         awxAnebrQ3ovr3EcDXY+vT1zvTJPFv5Te0LUiCZ8djkY+B2Rj9+5Q7Yz92P9q8l6dDdf
         kd5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=Of5rvemQeCFqBmvYnQWhIYlZsk0aVpfQH25dAfabLow=;
        fh=hGIdO2/3uysETl3h1Zw8zyADHc9dFoxunl2fWgcPhGY=;
        b=lwrrDXZTX9f+XqIPLNSvpxY9vgofBuietpFfC3JFu/3Jn28+AvC0WUWK8/i5EpGig4
         F42Rt9GqIJ3infxjvmlnPQLiTn9MS3a8RCXW6Xw8DDcWVKOQuBQO4Mtn5ZCtRNid01ld
         tT0kAs3M1jfPQ+tdf5UOoTcMZDVPCiuyfVHAsL2ut6jsJVKlPYd52SGhKE1T11RGrcnC
         RvEvMPSQcaXQlJl2lH0RXIv4XG2wGBxnCZD/yknE0aAniE/BoZfpRJ3lgib3N3VonTWP
         h3b6Z2JJIBPRSWa5YXxs42ElyVasOKmqDPDRV44OLz9u5GZ7pqgXDXVBbe5YHhrczJm+
         E7cA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786629795; x=1787234595; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Of5rvemQeCFqBmvYnQWhIYlZsk0aVpfQH25dAfabLow=;
        b=fAEesbBpIKJQyybFwNR/h3m67r8ObxjTEWXy1C8p3soDJyYZDnFWjoiMFrDwyqi+4j
         RodIWmqDX0Zpg/iAPKTEm7TAUP/Cwzb2Gb0c/H8R3zIWU3JU6fKsnNbsX4mxVGb285Mo
         tEcEU1JKzgqgq4Foa4ijbd2qpKkmsS7M8z0nYiqfrGHupdbSDOWH4/kbsFjdNmX1QTWF
         oPrO/ETTnxS1eku70fKzF3bg+A9kpS2rySHdfUz0O6GsGSfaxHqqTQv5vqw0Pm2H1zep
         VvZsYu2s2sZ3UfzX6KiViRjm8peODoLVvYx46lcX1b5JtLZM13xXUNRW1YxqsyfQHna7
         MozA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786629795; x=1787234595;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Of5rvemQeCFqBmvYnQWhIYlZsk0aVpfQH25dAfabLow=;
        b=KJph3d3qAFabqQR1eWvJQGv6V13UIddo8/3b3b0JACEHcxoIyfSx3Qf+9HVb+GPuxI
         Op5YnLOCWWuWuUpOnLWVZKBB9YgZ1WWz1kdV/9ggOvjBEtcRwaY/DkkuXhebSnRnxPwv
         c9FkBdAJClNpONwlDbjIKI5njurPDarF1Cdh8N6IA01KNa04gnqMDvxZ7Saj26bHQEx3
         +5Uj8r+7k1Q7hMfZpGc/1PzCchCxVKnxiBAn2YpNNR5nK9gbKMVBx73+ImB1WuVtC1kb
         nstkufOPVEPf0VctV/HMK2iYd0gz7C9+uibUw2lQZ3FRtwAnA7G+QpTx4ShpkWxAKDnT
         T6fQ==
X-Forwarded-Encrypted: i=1; AHgh+RpdUKtw6/wqicjRPYNnaGjHD1h/+LCgE7X4llunyhBtAoYj1aW+oAXPqL/r9DJo2/x0lE3UFKLnoks=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyt/7YEtVsQYHOteYoyIm2Tpe0XHKB3E1b20X69zqg4DXSRfpTJ
	IQtyqvl8jscwnhQ2mP+z00Eu142eWGXxApp56CkJVcmvZC3jXV4S9ZbYM1bkrRGAR9ev9mxE2Vo
	2Yko+FIRBTW5UMn8cvVBv1GskyWuPQD8=
X-Gm-Gg: AR+sD104hUf/BIY/nEI21rQP0mpHhjksLvS6MpJf1keaoBPkLEKmTtFs9LZNsM0PFoK
	o0CJc1xIFaGXBL1DUIa08XF9tQOiwl4hxmkOjhXRUu9Zf/yV65TyJ6wKBgWvbWAo5YhJfit+32l
	as+9bXSjGrzYP9bv8vUTCj7LhEkIBe6HXxA3d3ymDZ5TZF4hf9AwsDruNvLhPSxmaidHd8lCPln
	dewuof2bfSrkxSqjS9XbqYbhgP2/Kb8BJCWt9uKWkRfh/n1iyaXwY7EKdCoFEb0lPWqL8yWd97w
	kRkZgZno7tbzvecJE8ndljejguItj3JZisk2IYOjpmymISOzpWiEodR8uHk1qsJh29lRtyUjdR4
	f
X-Received: by 2002:a05:690c:60c5:b0:81e:8d96:a64 with SMTP id
 00721157ae682-83471fe8113mr32081087b3.13.1786629793581; Thu, 13 Aug 2026
 07:03:13 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com> <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
In-Reply-To: <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Thu, 13 Aug 2026 15:03:01 +0100
X-Gm-Features: AUfX_mzgHJiRrj_LcYCGgnUsfNRft_1T6cArPcQpli6QahfyG6F8nZA_51o4DCA
Message-ID: <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Jan Beulich <jbeulich@suse.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>, "Daniel P . Smith" <dpsmith@apertussolutions.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-bad1c0/1786629796-FC212034-A10C5EA6/0/0
X-purgate-type: clean
X-purgate-size: 14403

On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 10.08.2026 12:30, Frediano Ziglio wrote:
> > Add a sub hypercall to __HYPERVISOR_memory_op to allow to read/write
> > memory from/to a foreign domain.
> >
> > Extending MMUEXT_COPY_PAGE seems better on first sight but considering
> > that MMUEXT is meant for PV only and trying to change that sub-op this
> > solution is better.
> >
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>
> First: Can you please update your recipient list before sending a new version?
> Roger's move pre-dates this submission by quite a few days.
>

Yes, updated, I realized it after sending it.

> Then: The asymmetry of the new sub-op also continues to have no justification
> at all. If you insist on not using two (domid,list-of-gfns) tuples to describe
> the buffers, despite multiple maintainers having asked you to do so, please
> put down a word explaining that decision.
>

All other maintainers, after replying to their comments didn't
disagree with me, and this was different versions before, so stop
counting them, it's only you that don't like this at the moment.
I already explained why this is consistent with all other current hypercall.
I asked for a practical change to the API and nobody (including you)
has a proposal. I made a proposal and nobody replied to it.
If the issue is just adding a comment in the commit message I can do it.

> > ---
> >  xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
> >  xen/include/public/memory.h |  45 ++++++++++-
> >  xen/include/xsm/dummy.h     |  14 ++++
> >  xen/include/xsm/hooks.h     |   2 +
> >  xen/xsm/flask/hooks.c       |  10 +++
> >  5 files changed, 219 insertions(+), 1 deletion(-)
>
> As before: If you insist on not implementing the compat case, that decision
> wants justifying in the description. Without that it'll look like an
> oversight.
>

Yes, I was just going to reply.
I spent multiple days trying to implement the compat case or simply
HVM support with an issue after the other:
- multiple distributions removed the 32 bit support so it was hard to
have a setup;
- the original hypercall this PR is trying to optimise is supported
only in PV (so no HVM or compat guests);
- migration and other operations can work only on PV (like dm_op
operation) due to the usage of userspace handles used.
I tried to bypass the above limitations to have the new hypercall
tested and I manage to have 64 bit HVM working but the result is a
collection of nasty hacks and supporting them properly is a different
bigger task.
Surely a comment in the commit message on this is worth it.

> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -1548,6 +1548,141 @@ static int acquire_resource(
> >      return rc;
> >  }
> >
> > +/*
> > + * The "noinline" qualifier avoids the compiler to create a large function
> > + * consuming quite a lot of stack.
> > + */
> > +static int noinline mem_foreigncopy(
>
> I'm wondering: Is the "mem" prefix really meaningful for a static function in
> a file named memory.c?
>

Changed

> > +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
> > +{
> > +    struct domain *d, *const currd = current->domain;
>
> With the comment on the new XSM hooks (below) in mind: currd wants to be
> pointer-to-const.
>

Just rebased on master, all XSM hooks accept no-const pointers to domains.
So the suggested change would create warnings.

> > +    xen_foreigncopy_t copy;
> > +    int rc, direction;
>
> Plain int for rc is fine of course, but direction can't go negative, can it?
>

No, but the default type for constants is int and "flags" is promoted to int.

> > +    if ( copy_from_guest(&copy, arg, 1) )
> > +        return -EFAULT;
> > +
> > +    if ( copy.flags & ~XENMEM_foreigncopy_direction )
> > +        return -EINVAL;
> > +
> > +    direction = copy.flags & XENMEM_foreigncopy_direction;
> > +
> > +    d = rcu_lock_domain_by_any_id(copy.domid);
> > +    if ( !d )
> > +        return -ESRCH;
> > +
> > +    /*
> > +     * Check we are allowed to map and access these foreign pages.
> > +     */
>
> This really means to be a single-line comment.
>

Changed.

> > +    if ( direction == XENMEM_foreigncopy_from )
> > +        rc = xsm_foreigncopy_from(XSM_TARGET, currd, d);
> > +    else
> > +        rc = xsm_foreigncopy_to(XSM_TARGET, currd, d);
> > +    if ( rc )
> > +        goto out;
> > +
> > +    while ( copy.nr_frames )
> > +    {
> > +        /*
> > +         * Arbitrary size.  Not too much stack space, and a reasonable stride
> > +         * for continuation checks.
> > +         */
> > +        xen_pfn_t gfn_list[32];
> > +        unsigned int todo = MIN(ARRAY_SIZE(gfn_list), copy.nr_frames);
> > +
> > +        rc = -EFAULT;
> > +        if ( copy_from_guest(gfn_list, copy.frame_list, todo) )
> > +            goto out;
> > +
> > +        for ( unsigned int i = 0; i < todo; i++ )
> > +        {
> > +            struct page_info *foreign_page;
> > +            mfn_t foreign_mfn;
> > +            void *foreign;
> > +            p2m_type_t p2mt;
> > +            p2m_query_t q = (direction == XENMEM_foreigncopy_to) ?
> > +                            P2M_ALLOC | P2M_UNSHARE : P2M_ALLOC;
> > +
> > +            foreign_page = get_page_from_gfn(d, gfn_list[i], &p2mt, q);
>
> Is there a reason check_get_page_from_gfn() can't or shouldn't be used here?
> That would then also make this code properly deal with shared pages, and
> refuse use against MMIO ones.
>

It seems sensible, I didn't know it, I'll try it.

> > +            if ( unlikely(p2m_is_paged(p2mt)) )
> > +            {
> > +                if ( foreign_page )
> > +                    put_page(foreign_page);
> > +                p2m_mem_paging_populate(d, _gfn(gfn_list[i]));
> > +                p2mt = p2m_ram_paging_in;
> > +                foreign_page = NULL;
> > +            }
> > +
> > +            if ( unlikely(!foreign_page) )
> > +            {
> > +                rc = -ENOENT;
> > +                if ( p2mt != p2m_ram_paging_in )
> > +                {
> > +                    gdprintk(XENLOG_WARNING,
> > +                             "Error accessing foreign gfn %" PRI_gfn "\n",
> > +                             gfn_list[i]);
> > +                    rc = -EINVAL;
> > +                }
> > +                copy.nr_frames -= i;
> > +                guest_handle_add_offset(copy.frame_list, i);
> > +                goto out;
> > +            }
> > +
> > +            foreign_mfn = page_to_mfn(foreign_page);
> > +
> > +            /* A page is dirtied when it's being copied to. */
> > +            if ( direction == XENMEM_foreigncopy_to )
> > +                paging_mark_dirty(d, foreign_mfn);
>
> This may better be folded into the "else" below.
>

Changed

> > +            foreign = map_domain_page(foreign_mfn);
> > +            if ( direction == XENMEM_foreigncopy_from )
> > +                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
> > +            else
> > +                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);
>
> What I continue to be missing prior to this is the obtaining of a writable
> page ref. That's, as previously said, imperative for PV guests and at the
> very least advisable for HVM ones. (I really wonder how many more times I
> need to comment on this.)
>

Unfortunately that does not work.
The code is coherent with MMU_UPDATE.
I'll write a comment.

> > +            unmap_domain_page(foreign);
> > +            put_page(foreign_page);
> > +
> > +            if ( unlikely(rc) )
> > +            {
> > +                gdprintk(XENLOG_WARNING,
> > +                         "Error %d copying gfn %" PRI_gfn "\n",
> > +                         rc, gfn_list[i]);
> > +                copy.nr_frames -= i;
> > +                guest_handle_add_offset(copy.frame_list, i);
> > +                goto out;
>
> rc at this point holds the number of bytes which could not be copied. That's
> not suitable as a return value from this function. (Strictly speaking this
> is also an abuse of rc, as copy_{to,from}_*() return unsigned quantities.)
>

Yes, add an "uncopied" variable and return -EFAULT.

> > +            }
> > +
> > +            guest_handle_add_offset(copy.buffer, PAGE_SIZE);
> > +        }
> > +
> > +        copy.nr_frames -= todo;
> > +        guest_handle_add_offset(copy.frame_list, todo);
> > +
> > +        if ( copy.nr_frames && hypercall_preempt_check() )
> > +        {
> > +            rc = hypercall_create_continuation(
> > +                __HYPERVISOR_memory_op, "lh", XENMEM_foreigncopy, arg);
>
> Nit: Indentation (the anchor point is the start of the function name, not
> the start of the statement).
>

Changed.

> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
> >  typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
> >
> > -/* Next available subop number is 29 */
> > +/*
> > + * Copy memory from/to a given domain.
> > + * This calls is meant to replace expensive operations during migration which
>
> Nit: "This call is ..." However, is ...
>
> > + * are only supported for PV guests.
>
> ... this entire sentence really worth to have here (it looks more like
> something to have in the description)? For it to be possible to find if
> someone considered using those "expensive operations", I think it would need
> to be less vague and name those operations. Furthermore, if those other
> operations were supported only for PV guests, how would migration work for
> non-PV ones?
>

Maybe:
    This call is meant to replace expensive operations (mmap/copy/munmap) during
    migration which can only be issued from PV guests.

You can migrate any domain. Just from a PV guest (this is not a regression).

> > + */
> > +#define XENMEM_foreigncopy 29
> > +struct xen_foreigncopy {
> > +    /* IN - The domain whose memory is to be copied. */
> > +    domid_t domid;
> > +
> > +    /* IN - Flags. */
> > +#define XENMEM_foreigncopy_from 0
> > +#define XENMEM_foreigncopy_to 1
> > +#define XENMEM_foreigncopy_direction 1
> > +    uint16_t flags;
> > +
> > +    /*
> > +     * IN/OUT
> > +     *
> > +     * As an IN parameter number of frames of the domain to be copied.
>
> I think there's a comma wanted after "parameter".
>
> > +     * On output updated number of frames left (0 if success).
>
> I further think that adding "to" after "updated" would help here.
>

Updated to

    /*
     * IN/OUT
     *
     * As an IN parameter, number of frames of the domain to be copied.
     * On output updated to the number of frames left (0 if successful).
     */
    uint32_t nr_frames;

    /*
     * IN/OUT
     *
     * Frames to be copied.
     * On output updated to the point to the first frame unhandled, if any.
     */
    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;

    /*
     * IN/OUT
     *
     * Guest buffer to read/write from.
     * On output updated to point to the first page pointer unhandled.
     */
    XEN_GUEST_HANDLE(uint8) buffer;


> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -569,6 +569,20 @@ static XSM_INLINE int cf_check xsm_map_gmfn_foreign(
> >      return xsm_default_action(action, d, t);
> >  }
> >
> > +static XSM_INLINE int cf_check xsm_foreigncopy_from(
> > +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>
> I think these and ...
>
> > +{
> > +    XSM_ASSERT_ACTION(XSM_TARGET);
> > +    return xsm_default_action(action, d, t);
> > +}
> > +
> > +static XSM_INLINE int cf_check xsm_foreigncopy_to(
> > +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>
> ... want to be pointer-to-const right away, requiring to re-base over "XSM:
> make Argo hooks well-formed ones" (or alternatively requiring to split out
> the change there to xsm_default_action()). We really should avoid gaining
> ...
>
> > --- a/xen/include/xsm/hooks.h
> > +++ b/xen/include/xsm/hooks.h
> > @@ -58,6 +58,8 @@ XSM_HOOK(int, add_to_physmap, struct domain *, struct domain *)
> >  XSM_HOOK(int, remove_from_physmap, struct domain *, struct domain *)
> >  XSM_HOOK(int, map_gmfn_foreign, struct domain *, struct domain *)
> >  XSM_HOOK(int, claim_pages, struct domain *)
> > +XSM_HOOK(int, foreigncopy_from, struct domain *, struct domain *);
> > +XSM_HOOK(int, foreigncopy_to, struct domain *, struct domain *);
>
> ... new hooks with non-const-correct parameters.
>

It would honestly make sense if they were all const.
However at the moment this would not be coherent with the current code.
For instance these functions call "xsm_default_action" which does not
accept constant domains (xen/include/xsm/dummy.h).
I think the most clean thing would be first to change xsm arguments to
const first.
But it looks a bit out of scope with this PR.

> Further: Why two new hooks? See e.g. "XSM: fold xsm_{,un}map_domain_pirq()
> hooks", "XSM: fold xsm_{,un}map_domain_irq() hooks", or "XSM: fold
> xsm_{,un}bind_pt_irq() hooks": We'd like to reduce the number of hooks, to
> reduce (when non-dummy XSM is in use) the number of cf_check entry points.
>

It was a comment from Daniel.

> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -1368,6 +1368,16 @@ static int cf_check flask_map_gmfn_foreign(struct domain *d, struct domain *t)
> >      return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
> >  }
> >
> > +static int cf_check flask_foreigncopy_from(struct domain *d, struct domain *t)
> > +{
> > +    return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ);
> > +}
> > +
> > +static int cf_check flask_foreigncopy_to(struct domain *d, struct domain *t)
> > +{
> > +    return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
>
> Why both READ and WRITE?
>

Usually for memory you don't have write-only due to cache reasons.
But I suppose in this case only writint can work.
I'll change and test.

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 14:22:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 14:22:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390096.1630642 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWKQ-0007Vy-V9; Thu, 13 Aug 2026 14:22:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390096.1630642; Thu, 13 Aug 2026 14: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWKQ-0007Vr-S7; Thu, 13 Aug 2026 14:22:42 +0000
Received: by outflank-mailman (input) for mailman id 1390096;
 Thu, 13 Aug 2026 14:22:42 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuWKQ-0007Vl-2E
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:22:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuWKO-009mxD-Uo
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:22:40 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dd32b-2eae-0a2a0a5409dd-0a2a4504c994-8
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:22:40 +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 <jbeulich@suse.com>)
 id 6a7dd330-b57f-0a2a45040019-d155802de0cd-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:22:40 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4956242332dso19990745e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 07:22:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49982165351sm65074155e9.10.2026.08.13.07.22.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 07:22:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786630960; x=1787235760; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ECr555QZLT6kRJTA0iO1Xz3kSXCmzKIzM06GCqF+zV4=;
        b=SxdX19xOWcrgKP3z+m8THWkm8N8y5b4Me2Xcw6/Ru0EF9i8UQiFnrziH8agkkIIK+Q
         IxaogdPmh/c+SqaBqwTvnJgqGuwrmKCNwtZj0VPbly7H4Icpuc+SnHhPHsGN7yTNH3FT
         oTXfKKQFGD4TUjsP4cskvbOfDR/qeA/YUIX7Mcg7a23/ZxG2PwijhzC/pZoftWv/V0dg
         QL/N/U6aXsmWc9gdwQhwuJK0FkJT9tXQKUEMtD7GRraCxsgNB9jaiTtspGKGvvTNHGgW
         Y2MeE43bzL7hkd1RwTEXrwLmqxRAwFoNbfSoCL3BHRQpr2D9WqQuhevGiIulGj/9Sj/P
         OzDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786630960; x=1787235760;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ECr555QZLT6kRJTA0iO1Xz3kSXCmzKIzM06GCqF+zV4=;
        b=HFrzH+SPcFgeMIXBxzR/R52N00qOfWBhNwiH04M4eUcEpb7XUJN5+XcsJ0tO24y9EG
         pmnDb6K0/UQBJRuBCpg8eSWwymNLgK6Y4rwwIbWVTav2vcXAVLLjaj7up9kYBqPxupJx
         vt+ySLVQqO2cteI1rwxWciGFiWtCDAwt8T1gdXve0/Xu8eEv1PUsMGoWyng+kp8ZlNN8
         PD6JesogdDCgROwERIj0cT+B3g5K/XWbLgrS9grFJbHAvhih2k1wzQBa3Rg1BsbpT94T
         VEArBPRwYzw1iRYWsSyBnYApEqw9PW8NAvtVAutm5dolYydrJdLI70mM9Fvjp+NUpeHN
         ZeYg==
X-Forwarded-Encrypted: i=1; AHgh+Rp+CQ3TwiJINsyp8ICGX9UXA2c6roIqMJvseWg/ll6Sx4vsqQMos8c4aJYLzU7+jdKa6KLKWFlumtU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqQJx3by+5qH9AFjYby6t3K9GZR5zB7CDaNdpmmGu3wPEW/0Zn
	OdRFZSd9inprj9fy2db2xmrsZnJf7w/1Ack4YRenD79N7R1rpyvObTisdv8A7+/MQQ==
X-Gm-Gg: AR+sD13EQZncqwXhTDKaldLD6K3tz2oXEsBde42loMK3OOYMYqoQd31iuhBl6QRpKNd
	YbmUvfiBksuX0qApUKMrF/R6X0tLafDS9/5L6yLkWjSR9LXcrVVwDeAZZN9mBYoT27xWZHStIin
	Covu8oAyNPQxRL7/ThX67rRRfFXOoply1Ac6tEHIZrXlYSbDXQHzsbbmavysmr4Usngu5VLyNhd
	QAUP0CMuQN9pTDJIuUTcQRmUUAOWPEgwAhDMzu48fhLuo//o9l5UF1bYaq13ELoOnTI1XkfJpXa
	7WRy/Ac4kX6V0MEwQcj7QmsUq6ZIpNJ0H72oma1Ts2vRrqJSmatMPeM+wezkLI11zJJ+JHRlNdU
	sCdT32BHKx5HzkBqzQCY1i6lCA/l3zq92CxX62hxSwnk6lu2Z8u7AJ0/nUNs0ktSD+4htmDkvkc
	9Eezz+LChqYogASrZwkgQKQlaa4bNHgZ40gLxxd6xMpDKTeK7e2QzLOifXyQisE/aNVVTjuTk0s
	551Nd5UgWnfLxZI8uB585F6Cddl7ig4SJrBe+yWJSK7iT/JouOB
X-Received: by 2002:a05:600c:3b9f:b0:499:4d4d:822a with SMTP id 5b1f17b1804b1-499821d77f5mr70254415e9.17.1786630960055;
        Thu, 13 Aug 2026 07:22:40 -0700 (PDT)
Message-ID: <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com>
Date: Thu, 13 Aug 2026 16:22:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Frediano Ziglio <freddy77@gmail.com>,
 "Daniel P . Smith" <dpsmith@apertussolutions.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>,
 xen-devel@lists.xenproject.org
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com>
 <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
 <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786630960-C16D2B50-1F815ECC/0/0
X-purgate-type: clean
X-purgate-size: 9830

On 13.08.2026 16:03, Frediano Ziglio wrote:
> On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
>> On 10.08.2026 12:30, Frediano Ziglio wrote:
>>> Add a sub hypercall to __HYPERVISOR_memory_op to allow to read/write
>>> memory from/to a foreign domain.
>>>
>>> Extending MMUEXT_COPY_PAGE seems better on first sight but considering
>>> that MMUEXT is meant for PV only and trying to change that sub-op this
>>> solution is better.
>>>
>>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>>
>> First: Can you please update your recipient list before sending a new version?
>> Roger's move pre-dates this submission by quite a few days.
>>
> 
> Yes, updated, I realized it after sending it.
> 
>> Then: The asymmetry of the new sub-op also continues to have no justification
>> at all. If you insist on not using two (domid,list-of-gfns) tuples to describe
>> the buffers, despite multiple maintainers having asked you to do so, please
>> put down a word explaining that decision.
> 
> All other maintainers, after replying to their comments didn't
> disagree with me, and this was different versions before, so stop
> counting them, it's only you that don't like this at the moment.

None of this happened in public, though? In which case, how would I know?

>>> ---
>>>  xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
>>>  xen/include/public/memory.h |  45 ++++++++++-
>>>  xen/include/xsm/dummy.h     |  14 ++++
>>>  xen/include/xsm/hooks.h     |   2 +
>>>  xen/xsm/flask/hooks.c       |  10 +++
>>>  5 files changed, 219 insertions(+), 1 deletion(-)
>>
>> As before: If you insist on not implementing the compat case, that decision
>> wants justifying in the description. Without that it'll look like an
>> oversight.
>>
> 
> Yes, I was just going to reply.
> I spent multiple days trying to implement the compat case or simply
> HVM support with an issue after the other:
> - multiple distributions removed the 32 bit support so it was hard to
> have a setup;
> - the original hypercall this PR is trying to optimise is supported
> only in PV (so no HVM or compat guests);
> - migration and other operations can work only on PV (like dm_op
> operation) due to the usage of userspace handles used.

I don't understand how use of guest (not userspace) handles would get in
the way of anything.

> I tried to bypass the above limitations to have the new hypercall
> tested and I manage to have 64 bit HVM working but the result is a
> collection of nasty hacks and supporting them properly is a different
> bigger task.
> Surely a comment in the commit message on this is worth it.

Thanks.

>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -1548,6 +1548,141 @@ static int acquire_resource(
>>>      return rc;
>>>  }
>>>
>>> +/*
>>> + * The "noinline" qualifier avoids the compiler to create a large function
>>> + * consuming quite a lot of stack.
>>> + */
>>> +static int noinline mem_foreigncopy(
>>
>> I'm wondering: Is the "mem" prefix really meaningful for a static function in
>> a file named memory.c?
>>
> 
> Changed
> 
>>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
>>> +{
>>> +    struct domain *d, *const currd = current->domain;
>>
>> With the comment on the new XSM hooks (below) in mind: currd wants to be
>> pointer-to-const.
>>
> 
> Just rebased on master, all XSM hooks accept no-const pointers to domains.
> So the suggested change would create warnings.

Well, as per below, I pointed you at a particular pending patch, a single
hunk of which could be broken out.

>>> +    xen_foreigncopy_t copy;
>>> +    int rc, direction;
>>
>> Plain int for rc is fine of course, but direction can't go negative, can it?
> 
> No, but the default type for constants is int and "flags" is promoted to int.

Doesn't really matter. Unsigned types want using for values which can only
be non-negative. IF nothing else, then for consistency and doc purposes.

>>> +            foreign = map_domain_page(foreign_mfn);
>>> +            if ( direction == XENMEM_foreigncopy_from )
>>> +                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
>>> +            else
>>> +                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);
>>
>> What I continue to be missing prior to this is the obtaining of a writable
>> page ref. That's, as previously said, imperative for PV guests and at the
>> very least advisable for HVM ones. (I really wonder how many more times I
>> need to comment on this.)
> 
> Unfortunately that does not work.
> The code is coherent with MMU_UPDATE.

How's that relevant? That's operating on page tables, when here we want to
_prevent_ to copy into page tables (or descriptor ones, for that matter).

>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
>>>  typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
>>>  DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>>>
>>> -/* Next available subop number is 29 */
>>> +/*
>>> + * Copy memory from/to a given domain.
>>> + * This calls is meant to replace expensive operations during migration which
>>
>> Nit: "This call is ..." However, is ...
>>
>>> + * are only supported for PV guests.
>>
>> ... this entire sentence really worth to have here (it looks more like
>> something to have in the description)? For it to be possible to find if
>> someone considered using those "expensive operations", I think it would need
>> to be less vague and name those operations. Furthermore, if those other
>> operations were supported only for PV guests, how would migration work for
>> non-PV ones?
>>
> 
> Maybe:
>     This call is meant to replace expensive operations (mmap/copy/munmap) during
>     migration which can only be issued from PV guests.
> 
> You can migrate any domain. Just from a PV guest (this is not a regression).

Both Andrew and Roger confirm that this is supposed to work also from PVH
Dom0 (not sure why you keep saying "guest"), and also used to work. If it
doesn't, it would be a regression, and it would help if you supplied more
detail on the observed failure.

>>> + */
>>> +#define XENMEM_foreigncopy 29
>>> +struct xen_foreigncopy {
>>> +    /* IN - The domain whose memory is to be copied. */
>>> +    domid_t domid;
>>> +
>>> +    /* IN - Flags. */
>>> +#define XENMEM_foreigncopy_from 0
>>> +#define XENMEM_foreigncopy_to 1
>>> +#define XENMEM_foreigncopy_direction 1
>>> +    uint16_t flags;
>>> +
>>> +    /*
>>> +     * IN/OUT
>>> +     *
>>> +     * As an IN parameter number of frames of the domain to be copied.
>>
>> I think there's a comma wanted after "parameter".
>>
>>> +     * On output updated number of frames left (0 if success).
>>
>> I further think that adding "to" after "updated" would help here.
>>
> 
> Updated to
> 
>     /*
>      * IN/OUT
>      *
>      * As an IN parameter, number of frames of the domain to be copied.
>      * On output updated to the number of frames left (0 if successful).
>      */
>     uint32_t nr_frames;
> 
>     /*
>      * IN/OUT
>      *
>      * Frames to be copied.
>      * On output updated to the point to the first frame unhandled, if any.

Nit: There's now a stray "the".

>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>> @@ -569,6 +569,20 @@ static XSM_INLINE int cf_check xsm_map_gmfn_foreign(
>>>      return xsm_default_action(action, d, t);
>>>  }
>>>
>>> +static XSM_INLINE int cf_check xsm_foreigncopy_from(
>>> +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>>
>> I think these and ...
>>
>>> +{
>>> +    XSM_ASSERT_ACTION(XSM_TARGET);
>>> +    return xsm_default_action(action, d, t);
>>> +}
>>> +
>>> +static XSM_INLINE int cf_check xsm_foreigncopy_to(
>>> +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
>>
>> ... want to be pointer-to-const right away, requiring to re-base over "XSM:
>> make Argo hooks well-formed ones" (or alternatively requiring to split out
>> the change there to xsm_default_action()). We really should avoid gaining
>> ...
>>
>>> --- a/xen/include/xsm/hooks.h
>>> +++ b/xen/include/xsm/hooks.h
>>> @@ -58,6 +58,8 @@ XSM_HOOK(int, add_to_physmap, struct domain *, struct domain *)
>>>  XSM_HOOK(int, remove_from_physmap, struct domain *, struct domain *)
>>>  XSM_HOOK(int, map_gmfn_foreign, struct domain *, struct domain *)
>>>  XSM_HOOK(int, claim_pages, struct domain *)
>>> +XSM_HOOK(int, foreigncopy_from, struct domain *, struct domain *);
>>> +XSM_HOOK(int, foreigncopy_to, struct domain *, struct domain *);
>>
>> ... new hooks with non-const-correct parameters.
> 
> It would honestly make sense if they were all const.
> However at the moment this would not be coherent with the current code.
> For instance these functions call "xsm_default_action" which does not
> accept constant domains (xen/include/xsm/dummy.h).
> I think the most clean thing would be first to change xsm arguments to
> const first.
> But it looks a bit out of scope with this PR.

I'm not asking that you tidy up other hooks. What I'm asking is that new
hooks please be const-correct. Yet of course I'm not a maintainer of XSM,
so Daniel may tell you otherwise.

>> Further: Why two new hooks? See e.g. "XSM: fold xsm_{,un}map_domain_pirq()
>> hooks", "XSM: fold xsm_{,un}map_domain_irq() hooks", or "XSM: fold
>> xsm_{,un}bind_pt_irq() hooks": We'd like to reduce the number of hooks, to
>> reduce (when non-dummy XSM is in use) the number of cf_check entry points.
> 
> It was a comment from Daniel.

Daniel, can you clarify this please?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 14:35:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 14:35:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390108.1630656 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWXA-0001lM-3Y; Thu, 13 Aug 2026 14:35:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390108.1630656; Thu, 13 Aug 2026 14:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWXA-0001l0-0H; Thu, 13 Aug 2026 14:35:52 +0000
Received: by outflank-mailman (input) for mailman id 1390108;
 Thu, 13 Aug 2026 14:35:50 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>)
 id 1wuWX8-0001kZ-NE; Thu, 13 Aug 2026 14:35:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuWX7-0004VE-NA; Thu, 13 Aug 2026 16:35:49 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7dd633-2eae-0a2a0a5409dd-0a2a4502d682-18
 for <multiple-recipients>; Thu, 13 Aug 2026 16:35:49 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7dd645-6ca4-0a2a45020019-c387df838a24-3
 for <multiple-recipients>; Thu, 13 Aug 2026 16:35:49 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 9B1273E9E;
 Thu, 13 Aug 2026 14:35:40 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7930477E7A;
 Thu, 13 Aug 2026 14:35:40 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Ha1uHDzWfWrJSQAAD6G6ig
 (envelope-from <jgross@suse.com>); Thu, 13 Aug 2026 14:35:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786631744; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=XHifLB69AMRTLIpKxXHstN48NDghgiv9aUOhYqCq+fI=;
	b=XvZZDZKtQSkSBkCyGAFOdT+lQquq2J7JWAb5ZaYobwN/3qpM+JmPKLjHG+k1FDuYyWOvvZ
	EvIV0RsgeP20GJQXJbzGVBVC2yiScSIuG1EiislZmHmozHTx4IU8Y4MucdFEvjc+NF3juI
	eO7r7/L+pMMGFNvJ1Idrm7Z+K1fkV3I=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=bSiAhVrY
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786631740; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=XHifLB69AMRTLIpKxXHstN48NDghgiv9aUOhYqCq+fI=;
	b=bSiAhVrYX0JnOkA7W2YJHCtO3XGqJj6cAQ3a3TbbKJoyUax5QoJG6k4myiWTH33cNOCqpU
	EERQ3jJGU5Zf9tVfy2t0svItXdAh9xqtJ2od4vIOxg+J2gDag234gS+oHgDP12nM5jtUT9
	0m8E1pCS0I/esvtn2GehGJlFW88ptjI=
From: Juergen Gross <jgross@suse.com>
To: minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
Cc: samuel.thibault@ens-lyon.org,
	Juergen Gross <jgross@suse.com>
Subject: [MINI-OS PATCH] build: don't add -lm -lpci -lz to APP_LDLIBS
Date: Thu, 13 Aug 2026 16:35:36 +0200
Message-ID: <20260813143536.3607406-1-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.01 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,suse.com:dkim,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_THREE(0.00)[4];
	DKIM_TRACE(0.00)[suse.com:+]
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level: 
X-Rspamd-Queue-Id: 9B1273E9E
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-purgate-ID: tlsNG-720697/1786631749-303C42AC-4F976244/0/0
X-purgate-type: clean
X-purgate-size: 768

libm, libpci and libz are not always needed, so don't add them to
APP_LDLIBS just because libc is selected.

In case they will be needed by someone, they should be added via a
dedicated CONFIG option.

Note that none of the currently supported Xen stubdoms is using them.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Makefile b/Makefile
index a64913a..7510d5d 100644
--- a/Makefile
+++ b/Makefile
@@ -164,9 +164,6 @@ ifeq ($(CONFIG_LIBXENMANAGE),y)
 APP_LDLIBS += -L$(MANAGE_PATH) -whole-archive -lxenmanage -no-whole-archive
 LIBS += $(MANAGE_PATH)/libxenmanage.a
 endif
-APP_LDLIBS += -lpci
-APP_LDLIBS += -lz
-APP_LDLIBS += -lm
 LDLIBS += -lc
 endif
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 14:54:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 14:54:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390132.1630665 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWoe-0005zL-GW; Thu, 13 Aug 2026 14:53:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390132.1630665; Thu, 13 Aug 2026 14:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWoe-0005zE-DB; Thu, 13 Aug 2026 14:53:56 +0000
Received: by outflank-mailman (input) for mailman id 1390132;
 Thu, 13 Aug 2026 14:53:55 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wuWod-0005z8-EX
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:53:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuWoa-0007rv-LJ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:53:52 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7dda7f-e002-0a2a0a5209dd-0a2a450cbb48-8
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:53:52 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7dda80-f479-0a2a450c0019-d155802dd801-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:53:52 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-496b7622a83so5826545e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 07:53:52 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a569325sm7522217f8f.14.2026.08.13.07.53.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 13 Aug 2026 07:53:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786632832; x=1787237632; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qP1IXauP7ML7c9SNkCfOyG0xRsXsVlbjOA1DSnkJNLo=;
        b=WWJ6F3+lFLH4jMVvKn4KYKM0nhbvFKgQ6+DDay66JIi/OPJqJMMupuk5hOIxEMZsPI
         /8RFdWEVZlcIu2i2yY8+2GSNYJ5ASuHdy74eN8b6tC+2wRqD/g0KEKuO23Legd0hANaj
         +QZoqG3aEOWDUG4gpeOjXxYz2E8gAEX4BoKNE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786632832; x=1787237632;
        h=content-transfer-encoding:content-type:mime-version: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=qP1IXauP7ML7c9SNkCfOyG0xRsXsVlbjOA1DSnkJNLo=;
        b=QRA/61yYvmqkg6QJPpmECd00cnDuoTtHrZXuwQPuITs9FzMSxFijnYkj16GdBGNx9+
         Ee0/vr/vZ+t5DHf18RMm2MIi+cKYp5S9Bkp0GwkSE2Vu/WyAYgSY7gFchBk6mlXwnQ4G
         Z/ab9QtF+trBzpKnbKu182QtUOYLssYGOe8JFm/JVjkvTP9E6StvnpmzVjNB4n75e50l
         umOE7xCcUvnMHwYD4TSlSIQzZ2rX0Pfu2KButq+DRTwxx8SAVIjNV1S+j9cwUzE8WVcM
         XpLM+5OOI1O3uXr27YceOKgbOA8CWlCfi6NjO14OAOWeEddxN3hShkulG1vbGqME8Lg5
         B8Sw==
X-Gm-Message-State: AOJu0YzW3Gpj5RfTFQtkpGzT2G6jGAenE7rXjrHZUUdTgJzdC2wAA9iE
	vt1a70nW4s5DX3IBGX8uz4O4qn74KaSO6mf5WCYRKsMEw6rAP42Xxj0OHA8Q0/aCHlS9MiNziH7
	9p+8d
X-Gm-Gg: AR+sD12MC8SteyNrNz6H9B9ZUUmLHRh8G1t3ZhSbVG2HDsxAaRY4mFKFXBk1rZ65ou9
	61yofQot4A0P6Vl28qNkHI0BXj1nXYvtYwoSUkVV1aWHDVdQESjZ1qEgoVmKdSMpr7bETtSFupr
	kk5lPBTL8inb5k70sOLCCyv6apy/YSl36LorvVM80QquA3rXy5znFsdQXVuDl7by2WPIoew8gWr
	fymZkpsyXFdLwBxhRPqAm6vnGBXsfcI0b2YmtrIk+MR5AhxTXIvrwXjVB9mCP5y4yoFct+K0A88
	R9D5W5Ts/sXeo69pOyPzWs4QRwOww9RoekPzI4Hv0lhve/+gyZqNmt24xOcqgrdBYmSHvQ8YZE7
	vdTRNhp8FABuIlMYx7JBslVrxqRzSpSsF+AvWChj63NSz1tklMhxU+dVKv/D9w1x6nuyL20nyA9
	d5UZDlrZlzeyETKzoBnOG/TLbFPQ3uXDy8yeOdEr6nz/FEslaJ75syMMG8Pnzvl+DBchvkf+aph
	PU+Ffd84tLGfFwp9Q+YoSWazEVUcoONRNwCSIg=
X-Received: by 2002:a05:600c:3e15:b0:495:503f:cf9a with SMTP id 5b1f17b1804b1-499821e8021mr78723355e9.9.1786632831501;
        Thu, 13 Aug 2026 07:53:51 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/cpu: Rewrite initialize_cpu_data() for clarity
Date: Thu, 13 Aug 2026 15:53:49 +0100
Message-Id: <20260813145349.1656699-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786632832-012C8A5B-FB4CCADB/0/0
X-purgate-type: clean
X-purgate-size: 1501

Without passing opinion on the behaviour of this function, it is deceptive to
read (I've twice now mistaken it for resetting boot_cpu_data), and
inefficient.

Instead of having a 256 byte object on the stack and a double copy, copy
boot_cpu_data directly, then reset parts of cpu_data[cpu] in place.  Leave
some comments behind explaining what's happening.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

Pulled out of separate series.
---
 xen/arch/x86/smpboot.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 84e9e4beed60..cede2b886f33 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -94,12 +94,14 @@ void *stack_base[NR_CPUS];
 
 void initialize_cpu_data(unsigned int cpu)
 {
-    struct cpuinfo_x86 c = boot_cpu_data;
+    struct cpuinfo_x86 *c = &cpu_data[cpu];
 
-    /* Must not partially clear the BSP's collected data. */
+    /* First, inherit from boot_cpu_data */
+    *c = boot_cpu_data;
+
+    /* Second, reset most of it, except if we're the BSP at early boot. */
     if ( cpu || system_state > SYS_STATE_smp_boot )
-        reset_cpuinfo(&c, true);
-    cpu_data[cpu] = c;
+        reset_cpuinfo(c, true);
 }
 
 static bool smp_store_cpu_info(unsigned int id)
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 14:54:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 14:54:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390136.1630675 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWp4-0006MJ-OZ; Thu, 13 Aug 2026 14:54:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390136.1630675; Thu, 13 Aug 2026 14:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWp4-0006M9-K0; Thu, 13 Aug 2026 14:54:22 +0000
Received: by outflank-mailman (input) for mailman id 1390136;
 Thu, 13 Aug 2026 14:54:20 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuWp2-0006KU-QQ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:54:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuWp2-003WX6-77
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:54:20 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dda8a-2eae-0a2a0a5409dd-0a2a450cb208-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:54:20 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dda9b-f479-0a2a450c0019-d155dd2de9c1-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:54:20 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f7027ca11so1441212f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 07:54:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815a5c2308sm7956847f8f.33.2026.08.13.07.54.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 07:54:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786632859; x=1787237659; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=+Yy7VwkW6yRnyt+6I2jAVDOVkLebeVXof2iwUiH5Mdc=;
        b=THyPYbZOJkb1vuUoIh5buLbkX+mviNYf9zf1+kN5Ty3rGVXxpi1SL5A3fNGsTWgKrS
         jZym2d94+8BYYYOqFw6WMpiPB5WsurTsJjn9HIAkx1OjifTpD1+dC4ATcUCuOBzDjyL9
         ySK8s6tIaIhkidgZmv0iLAz2i7W+iUkCmanzwf9X8/CfDz22EWZPOahEIaXVGI6eCzNX
         1OStMNbwSM3ZsBD+ek0KEILg7a1zbEkqMrcPf6B8av7fsO45nPj6/15Vh5IrNokUu94Y
         7FF93rMYbPPX4+lVfXNIZE9mSSiEgNyu3EskuixQRpMABJNUVo4wk77iuzOyoJZ1YtmG
         amTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786632859; x=1787237659;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=+Yy7VwkW6yRnyt+6I2jAVDOVkLebeVXof2iwUiH5Mdc=;
        b=gOuoyaR4C6xx7iZXBHILDgcw7NrITP0qHhnt6ZSdSDiqaxWduP6jqDsM5fzX2XKVxP
         7RPiCOA5W4PIVGA9wVwB2znXoyJ2RfjHvxi6bx6qaOW0lFj8bSReX1qhcnHHrjJTlCuo
         148qXdkXklk+GDkn/XafcYf79zrMG0wTvBDHjzNZMLU+cj9482EbcGR4CLQdKK+BEDvm
         psUjBA+sBwccut+OWTBlq3rIsx1aYD9j9tciqcJVDI8z/K+FVNOkLWmDOlyCnvu3bZYR
         JFaaBwyykYDPy1vxYkD0wphK3bHK4m/aGnjmFSTb+I0uy2bRITGNGkQJkDkNdTde3fjW
         qkIg==
X-Forwarded-Encrypted: i=1; AHgh+RprFDE84myn6HWmtsPxhXB4uPwWvvcAKJqQ7Rjjxg//eyO8beS94DVWmGFoQFeJ3+DLoJo3c7yWIkk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyd8fu0lLWq8AlgYEDimhqN+3LVLTWEwWIa7J1CsCdZUQ6MHdAT
	QXNkyeBOacn1k2Riu9ibeLqLi/xSChMyNboWJUQj6IWcVMFzOsbEYWi3dKr/e2xn2g==
X-Gm-Gg: AR+sD11LrgzIZVkSoQOckD7nzngamek2RmluWjF9YWiWzFO74CAJaSFc42i9XnwAzTy
	Lpyz3z8LLeF0xUxiiCjM8cQ4ahxFq7nhKbIaQP8d2CMMgwk7zaFtgjdWn037qzrLJaZlQRz4WhJ
	3me8ENy3yl5ipedlGZxyBXXM/ndVjzCBEKoIA1C45xbg68H5H+TD78S3h43CZCqXJlPcB54OlSU
	sILyWA1YvgqzxhSerhroTRnqStU+U2fd3jqKYFwFqqtl9kf9/4CYGZuA6bORgGN1rBGeIsnPUXA
	OBmLYXkgUIcQYl59XBWaKEG7VoY5lxFKqPMApIqgw9h9Mtq+09RrJFH20ZIa/imF0gjq0gZW7/1
	ERyHD4za+qaopf3Iq+0onlpc3RLykmmB4383wwbyyEXotKSk1ts+u8pUg8xbQbnBXmiRa9t4N3s
	5UzZYf6uZT/iBjI+OMSvnO9KZYxhSq3CXbHACyoLBtfs1fhcFJ3CEo4lUxYdMzyXzieTVaLEFI3
	O6yOkCR9qw6UUa8epEKhVKYEToQafabWiHLhfNVEUfiJWyXKmza
X-Received: by 2002:a05:6000:4815:b0:47f:e9fd:80d8 with SMTP id ffacd0b85a97d-4815a031208mr10584737f8f.21.1786632859445;
        Thu, 13 Aug 2026 07:54:19 -0700 (PDT)
Message-ID: <3bd3a9d5-444b-4bb5-9a4c-8353f98802a9@suse.com>
Date: Thu, 13 Aug 2026 16:54:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs
 without a shared page
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <ed247fcc594346ad20a3d12e5d49c8f48ba6792a.1785836421.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ed247fcc594346ad20a3d12e5d49c8f48ba6792a.1785836421.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1786632860-77CD3A5B-4C183E36/10/73395122804
X-purgate-type: spam
X-purgate-size: 7655

On 04.08.2026 17:47, Oleksii Kurochko wrote:
> On architectures that run guests in dom0less mode without the PV ABI
> (currently RISC-V), no shared_info page is allocated and d->shared_info
> remains NULL throughout the domain lifetime. Several places in common
> code access d->shared_info through the shared_info() macro or directly,
> causing UBSAN null-pointer errors on such architectures.
> 
> Rather than adding runtime NULL guards that are logically unreachable
> on x86 and Arm (where shared_info is always allocated), introduce a new
> Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm.
> 
> On !HAS_SHARED_INFO the shared_info() macro expands to a dereference
> of shared_info_absent, an extern pointer that is declared but
> intentionally never defined.  Any use of shared_info() that is not
> dead-code-eliminated will therefore cause a link-time failure, making
> missed guards impossible to overlook.
> 
> The 2L event-channel ops call shared_info() and must not be compiled on
> architectures without a shared_info page, so event_2l.o is gated on
> CONFIG_HAS_SHARED_INFO. On such architectures evtchn_init() installs the
> FIFO ops as a placeholder instead, so that a later guest opt-in to the
> FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO
> support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated
> no-op evtchn_port_ops_none table is installed instead, so that
> d->evtchn_port_ops is never NULL. evtchn_fifo_word_from_port() is
> guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe
> before evtchn_fifo_init_control() is called by the guest.
> 
> With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global
> dummy_vcpu_info, so writes through vcpu_info() could leak data between
> vCPUs. Reviewing the write paths in common code: the write in
> map_guest_area() stores the constant ~0 so nothing serious would happen
> if it were leaked; the event_2l.c paths are not compiled on
> !HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the
> write in vcpu_info_populate() targets the new mapping buffer, not
> dummy_vcpu_info.
> 
> Outside common code, the remaining writes are x86 PV-specific, for which
> CONFIG_HAS_SHARED_INFO=y. No code changes are needed.
> 
> Finally, struct domain's shared_info field itself is gated on
> CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL
> pointer: every user of it is either arch code for an architecture that
> selects HAS_SHARED_INFO, or common code already guarded by the same
> Kconfig symbol.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>
albeit still with a number of comments / requests:

> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -40,6 +40,41 @@
>  
>  #define consumer_is_xen(e) (!!(e)->xen_consumer)
>  
> +#if !defined(CONFIG_HAS_SHARED_INFO) && !defined(CONFIG_EVTCHN_FIFO)
> +/*
> + * Placeholder ops for domains with neither a shared_info page nor a FIFO
> + * control block (CONFIG_HAS_SHARED_INFO=n and CONFIG_EVTCHN_FIFO=n). Such

I'd omit the part in parentheses - it only repeats what the #if already
has.

> + * a domain has no ABI to record event state in, so these are reachable
> + * whenever an event is delivered to (or queried on) one of its ports; they
> + * just discard/no-op it.  They exist to keep d->evtchn_port_ops non-NULL.
> + */
> +static void cf_check evtchn_none_set_pending(
> +    struct vcpu *v, struct evtchn *evtchn) {}
> +static void cf_check evtchn_none_noop(
> +    struct domain *d, struct evtchn *evtchn) {}
> +static bool cf_check evtchn_none_false(
> +    const struct domain *d, const struct evtchn *evtchn) { return false; }
> +static void cf_check evtchn_none_print_state(
> +    struct domain *d, const struct evtchn *evtchn) {}
> +
> +static const struct evtchn_port_ops evtchn_port_ops_none = {
> +    .set_pending   = evtchn_none_set_pending,
> +    .clear_pending = evtchn_none_noop,
> +    .unmask        = evtchn_none_noop,
> +    .is_pending    = evtchn_none_false,
> +    .is_masked     = evtchn_none_false,
> +    .print_state   = evtchn_none_print_state,
> +};
> +
> +static void evtchn_none_init(struct domain *d)
> +{
> +    d->evtchn_port_ops = &evtchn_port_ops_none;
> +}
> +#else
> +/* Declaration only; the calls below are DCE'd unless both configs are off. */
> +void evtchn_none_init(struct domain *d);
> +#endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */

I think the (inverted) comment would be more valuable on the #else line.

> @@ -1324,9 +1359,15 @@ int evtchn_reset(struct domain *d, bool resuming)
>          rc = -EAGAIN;
>      else if ( d->evtchn_fifo )
>      {
> -        /* Switching back to 2-level ABI. */
>          evtchn_fifo_destroy(d);
> -        evtchn_2l_init(d);
> +
> +        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
> +            /* Switching back to 2-level ABI. */
> +            evtchn_2l_init(d);
> +        else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
> +            evtchn_fifo_init_ops(d);
> +        else
> +            evtchn_none_init(d);

This being the same as ...

> @@ -1625,7 +1666,13 @@ void evtchn_check_pollers(struct domain *d, unsigned int port)
>  
>  int evtchn_init(struct domain *d, unsigned int max_port)
>  {
> -    evtchn_2l_init(d);
> +    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
> +        evtchn_2l_init(d);
> +    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
> +        evtchn_fifo_init_ops(d);
> +    else
> +        evtchn_none_init(d);

... this: Maybe have a small helper (evtchn_preinit()?), to reduce the
duplication? Would require comment updates then as well.

> --- a/xen/common/event_fifo.c
> +++ b/xen/common/event_fifo.c
> @@ -62,6 +62,9 @@ static inline event_word_t *evtchn_fifo_word_from_port(const struct domain *d,
>       */
>      smp_rmb();
>  
> +    if ( unlikely(!d->evtchn_fifo) )
> +        return NULL;
> +
>      if ( unlikely(port >= d->evtchn_fifo->num_evtchns) )
>          return NULL;
>  
> @@ -419,6 +422,19 @@ static const struct evtchn_port_ops evtchn_port_ops_fifo =
>      .print_state   = evtchn_fifo_print_state,
>  };
>  
> +/*
> + * evtchn_fifo_init_ops()'s only call sites are in the
> + * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branches of evtchn_init() and

Perhaps better drop "dead" from here; those branches are dead only when ...

> + * evtchn_reset(), which are never reached on HAS_SHARED_INFO=y builds
> + * because of DCE.

... HAS_SHARED_INFO=y, not generally.

> --- a/xen/include/xen/shared.h
> +++ b/xen/include/xen/shared.h
> @@ -43,7 +43,13 @@ typedef struct vcpu_info vcpu_info_t;
>  
>  extern vcpu_info_t dummy_vcpu_info;
>  
> -#define shared_info(d, field)      __shared_info(d, (d)->shared_info, field)
> +#ifdef CONFIG_HAS_SHARED_INFO
> +#define shared_info(d, field) __shared_info(d, (d)->shared_info, field)

Is there a reason this line cannot simply be kept as it was?

> --- a/xen/include/xen/time.h
> +++ b/xen/include/xen/time.h
> @@ -66,7 +66,11 @@ struct tm wallclock_time(uint64_t *ns);
>  #define version_update_begin(v) (((v) + 1) | 1)
>  #define version_update_end(v)   ((v) + 1)
>  extern void update_vcpu_system_time(struct vcpu *v);
> +#ifdef CONFIG_HAS_SHARED_INFO
>  extern void update_domain_wallclock_time(struct domain *d);
> +#else
> +static inline void update_domain_wallclock_time(struct domain *d) {}
> +#endif

Perhaps best to insert a blank line ahead of the #ifdef.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:00:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:00:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390159.1630703 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWuT-000818-Nc; Thu, 13 Aug 2026 14:59:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390159.1630703; Thu, 13 Aug 2026 14:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuWuT-000811-Jj; Thu, 13 Aug 2026 14:59:57 +0000
Received: by outflank-mailman (input) for mailman id 1390159;
 Thu, 13 Aug 2026 14:59:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wuWuS-00080v-M2
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 14:59:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuWuR-001Kgn-Rt
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:59:55 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a7ddbd5-2eae-0a2a0a5409dd-0a2a450aa06a-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:59:55 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a7ddbea-f2d2-0a2a450a0019-a0658308e3c8-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 16:59:55 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 61CE544DC0E4;
 Thu, 13 Aug 2026 10:58:12 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger.pau@citrix.com,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>
Subject: [PATCH v1] x86/nSVM: Expose the FlushByASID CPU Capability to L1 guests
Date: Thu, 13 Aug 2026 15:56:18 +0100
Message-ID: <05107cae0af8ea9cd66c133200296d3f667c8295.1786630293.git.abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786633195-520C1CFC-785A0ED8/0/0
X-purgate-type: clean
X-purgate-size: 2359

On the AMD platforms, the Xen hypervisor requires the FlushByASID CPU
capability to support HVM nested virtualization (see start_nested_svm).
Consequently, the L1 hypervisor must report FlushByASID CPU capability support
when intercepting CPUID instruction for the CPU feature from the L2 guest to
support nested virtualization levels beyond L1. Extend the exposed HVM CPU
policy to surface this CPU feature support for the guests.

While at it remove the dangling `exitinfo1 = ns_vmcb->exitinfo1;` assignment
inside the nested exit handling of svm_vmexit_handler().

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Testing:
 - Using a locally developed XTF test to call cpuid_edx(0x8000000aU);
   - without the change, EDX returns 0x4AB (the FlushByASID 6th bit is not
     set).
   - with the change, EDX returns 0x4EB (the FlushByASID 6th bit set).
 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2757859821
---
 xen/arch/x86/cpu-policy.c  | 1 +
 xen/arch/x86/hvm/svm/svm.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index eddcd9778f..48a3185eed 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -843,6 +843,7 @@ static void __init calculate_hvm_max_policy(void)
         p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
                                (1u << SVM_FEATURE_LBRV) |
                                (1u << SVM_FEATURE_NRIPS) |
+                               (1u << SVM_FEATURE_FLUSHBYASID) |
                                (1u << SVM_FEATURE_PAUSEFILTER) |
                                (1u << SVM_FEATURE_DECODEASSISTS));
         /* Enable features which are always emulated. */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 38c61db1d7..2f62981305 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2561,7 +2561,6 @@ void asmlinkage svm_vmexit_handler(void)
          * nestedsvm_check_intercepts() expects to have the correct
          * exitinfo1 value there.
          */
-        exitinfo1 = ns_vmcb->exitinfo1;
         ns_vmcb->exitinfo1 = vmcb->exitinfo1;
         nsret = nestedsvm_check_intercepts(v, regs, exit_reason);
         switch ( nsret )
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:07:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:07:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390182.1630711 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuX1q-0001Sd-Bx; Thu, 13 Aug 2026 15:07:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390182.1630711; Thu, 13 Aug 2026 15:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuX1q-0001SW-96; Thu, 13 Aug 2026 15:07:34 +0000
Received: by outflank-mailman (input) for mailman id 1390182;
 Thu, 13 Aug 2026 15:07:32 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuX1o-0001SP-Ra
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:07:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuX1o-003Z4Q-7t
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:07:32 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ddda2-bab6-0a2a0a5309dd-0a2a450bcfb4-46
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:07:32 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dddb3-b7e8-0a2a450b0019-d155802bb5d1-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:07:32 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49557167508so205735e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:07:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499820c2897sm134876285e9.0.2026.08.13.08.07.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:07:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786633651; x=1787238451; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wR38hHyS68/61PMDdPsBtmYQNagF/8h/0Ls5CFsUM7g=;
        b=e/mTLoVRqpHcJo1GLkqB7serJHh7EQgQLF8N2Z9qekyug4SItBJFXykS5kHOJ5Cm/t
         rlXqgNFuIQHGdrK+aXBwXodrgJSLP37Q7mjHUCD8Rfpw7Q7VPbRn3tnE/WhXv1EyIxKV
         sy8YjvKV3yu+kPRiT7ZWnqkA5RmCqxZ7FFHb2rtVgw5uN1fj5/uSZGHojeJusLkGfHYo
         dfTpqTx9eys5DCIVCyy32C8hhD7GVbTlDALwQVjTWZTRrz0MKR4PbqO01DXNWhqg8kLw
         5P3XAsOSb4A0z17OBNva7tR/LKmWMLl660bcpJsDMoKF9SC21rxzVmbmOPUfi3bGYHZA
         DqLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786633651; x=1787238451;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=wR38hHyS68/61PMDdPsBtmYQNagF/8h/0Ls5CFsUM7g=;
        b=Y7j23ZXcNH5BvSIDVljiT1hswQJwYfyCrrZXnCFF2g+ckxHtsb4vuVSAC2JCgfHKlX
         xuv7gVCah0YoWyHYyclGz8ZeVxNR/qJnyaOF6ZW6+DJao8DUkIdRWjYBOFNZB4UxeqcK
         aU62QtkJnSj8kNIqBbAMdvpqGEcUdHYbocJuIjiGcRuFGGwHTd1duSuUsbHjP/DlbLYP
         KJX5svgMA2FmCH1SZ/Q4j1ZIN7j2JwRSbPJvcNlXAHhFMk/9gaSF55NehrWdkG/qhZ1O
         l2gphrYPIrFqxl8cwYWWNUvM1vNyVQEjaZHkDRjLWAIBUmrPKeCsIbMDHhHCpoBKnGDZ
         EXGQ==
X-Forwarded-Encrypted: i=1; AHgh+RrsyfA6Pd53B5mvmAbnFbEFF2DOjQj3Cme0cNmAqdYq3Scf5sw89v5Lpc0JKf00KhkX8E7/sqHmH18=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx010yliwkdoaRYV2/CZnRI7NMetnqZx3tkC+jFKJei0LF1BpFo
	nZuTT5uI5s+x7R+HgKJCLMWJsXo75XrjZ7F2bofUsprgLcBzQB0LV4xgxW9jjIBV+g==
X-Gm-Gg: AR+sD10VhXXxoUM9Rti5KaUf96d8JlRA3HQI7T8VniW6l/gnOXkjIOy2VgsT2MchvIe
	BNzPZ6b9Xm73HxVnQtNyhqyzixVnobYs4j1sFevwh0/OOlAFkWelGAi2q3+7iJSUhmZhm1KYbHJ
	pNr/ePJQ3zdO9bl9Dbice6bul0oxHPoxwJSFX73AeqfqB2hT+jmT3OVGJMSZiWNjdQl1Dcw2Qlv
	fmt+TxPAzPXs76v5Jde+ZUTJbltnJQYqaYpJ3JIa+aDtl4RxJ4iTkQi1yEVR+UoPi9Oq+GgdyJV
	8quzXtYSR+QiYZRLzDf0PkB3CQ/UkhczVnaW1OlycTdknpj1CbtHnTKiJNvT/sZNL7wAYSMgKmj
	JZcs1YdoquUrQxFjrp/27yR8ajgRBc1+trgTM6fHpEO8Qg+LGDzR+h4Ai+OeOpjFohsqK/DJlfD
	kqTnNwTkUZawMyJrXCK7+Xorr4VLd0g43OSlNeH7LDwY2e6LHtYhZKHVH3vu8hLYR6QVgmwIJ6w
	KaGJvMI+GxU4NKHXqcmPF3hqvc3tUypIVJyv4NteCpVEV80YiZcpK6phg==
X-Received: by 2002:a05:600c:1f91:b0:496:bbce:fc with SMTP id 5b1f17b1804b1-499821f0030mr67756155e9.12.1786633651506;
        Thu, 13 Aug 2026 08:07:31 -0700 (PDT)
Message-ID: <90c76782-c44f-4f0e-a187-0625373c8d2a@suse.com>
Date: Thu, 13 Aug 2026 17:07:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/cpu: Rewrite initialize_cpu_data() for clarity
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260813145349.1656699-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260813145349.1656699-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786633652-1BED69EA-52BF1EB4/0/0
X-purgate-type: clean
X-purgate-size: 638

On 13.08.2026 16:53, Andrew Cooper wrote:
> Without passing opinion on the behaviour of this function, it is deceptive to
> read (I've twice now mistaken it for resetting boot_cpu_data), and
> inefficient.
> 
> Instead of having a 256 byte object on the stack and a double copy, copy
> boot_cpu_data directly, then reset parts of cpu_data[cpu] in place.  Leave
> some comments behind explaining what's happening.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

While I think it was good enough before, I also don't mind the change:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:29:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:29:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390210.1630721 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXMx-00062t-02; Thu, 13 Aug 2026 15:29:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390210.1630721; Thu, 13 Aug 2026 15:29:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXMw-00062m-SG; Thu, 13 Aug 2026 15:29:22 +0000
Received: by outflank-mailman (input) for mailman id 1390210;
 Thu, 13 Aug 2026 15:29:21 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuXMv-00062g-Iv
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:29:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXMu-0072YA-SQ
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:29:20 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de2b1-bab6-0a2a0a5309dd-0a2a4504ca34-42
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:29:20 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de2d0-b57f-0a2a45040019-d155dd2be4a6-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:29:20 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47f703a9d05so1574920f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:29:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f20051esm165872f8f.7.2026.08.13.08.29.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:29:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786634960; x=1787239760; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=hCHZX0GXymXgC2X3W51AHc2x34jZNDZpsT8/tP8znWs=;
        b=KQlHCoe4rC8dNFX3zxfj7AwMEcYaQ05/z7qTbg5pVfaXN1xiV+BFIy2WbOm5zbYNU2
         ResNKCm2ZcEZYydzL7rxeL2FMkSU0zpmdV7ZYV125u3QLjBb8hq18kQ3ulSl7VVhvKGX
         N+dH+uaF1a54AixbyUwoh11G8lUYafplLE5gxLjTf696wdzQ8aX5mYaIZIz7nRShzSkd
         4XgHfsmI2bSxDa+9Ixg6aaacloC7ahAfb0eMUOx7bHA2t/d7jkCTk7cSahNM0+Y59N/S
         3AZl0kTvTO5nyTC83rfYCJU165stPNIAZ3iwLoxrqjNPsGAzji3iXLjD/rtF24Na0NJJ
         zRyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786634960; x=1787239760;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=hCHZX0GXymXgC2X3W51AHc2x34jZNDZpsT8/tP8znWs=;
        b=TOWCFRo6IpeiBY5gqHDFq2H59CKW/crnr+DDgA6tQbc0FOEJcWQ67GlD6KddLl0qsb
         5axXLJNNIIfUwj3YfUR/b2cKfyy6z0M58+HraKWsHA2YFVDC0x8BdWCFJe+FAg+6gxnM
         u50fLPzh7FXVb135qQwjHFONEFXWaGr1/mpPQ6AEvljjoEbXi6OJZOgqhFSFp9NT77tD
         gYmkwnaqGML9TAsM56XVmQb+JXhsvc7gSBXvullHSnIi83LlVCeatGhUejiqA/1XyxZG
         TprAhBBMTec/mBxuqb1j0sJ+w+o7lwFpDYL+ao76sphVVuFXoTwbRHdMmggAlWBrPKvv
         bYTQ==
X-Forwarded-Encrypted: i=1; AHgh+Rqb+5pmBSYmffv9ZuqYFm39IWZY6uvYnCQjq/4sNJGSp0Qvg0WzGnmWMTL19Lgp3yMQOHBb3t+48rM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfgJaFso9ZDVNqqwp1VCdo3SXkCxLdLN8LjsqotUkLPmqaeaId
	i6VZJXGCsq7IPkxU7GmY+YrN3uxv+/xakxkrxND1Z7IHYf2sqT4F9XdNxbAclfPJ8g==
X-Gm-Gg: AR+sD11EYYblMaVEjQdl+5ItKtAYkNoOs599unpmnAavCQx6E94LuxSeFWbwfTAQtWv
	8F2aKMEkVhLFZ8TmhDpGH/ZJN6DZdqpCaDPnofAXQRqMjKQrhXDMBA3D/XRnK5JlBHsFBh+QIk3
	AXFyS7+CB6Sa9ivAJRtzn9tfVfErCFJmfPHFhfSYgA5H79aFyIjOWeRmg7iYKWvYQ6wfmQt7DEZ
	DEb58PIXrzZzCAmCxs2YlSHicsVjpq9uxhGbsZI4iNNWFYSu1Sby0W9sm4UiLjjruu80qvAUfSv
	o5jq9vB50Pk5/8Rlt/CrxmnOa+aArmyRrP5/WZ8JbS5ctVvyT39Mz+U152U8uiT5bPOsbSGEYGx
	hVEeWyzOjqiteg+2xqIsKhU0AycYwMWMEAPq6sz4bqMQ9HHiB/y4PcCCEP3TAVSK1Ub0n3BHBxO
	0GlruE8jDyP7huTHXJFOoCMFBJqvllCGUn6s6qjB4Uiw4qBVzVftIxCoTQ+4ZTcSq8F4Doplwxh
	nlltQkaVnVsZnLcGaca1iNuzBrNJbR1Nntah/3NAQSCe+mV6D/Y
X-Received: by 2002:a05:6000:1363:b0:47f:8fc8:a8b1 with SMTP id ffacd0b85a97d-4815a0223c2mr8378512f8f.14.1786634960237;
        Thu, 13 Aug 2026 08:29:20 -0700 (PDT)
Message-ID: <73e2a6fd-8cd9-4dc1-9a83-e48baec6c13e@suse.com>
Date: Thu, 13 Aug 2026 17:29:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] x86/nSVM: Expose the FlushByASID CPU Capability to L1
 guests
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <05107cae0af8ea9cd66c133200296d3f667c8295.1786630293.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <05107cae0af8ea9cd66c133200296d3f667c8295.1786630293.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786634960-C38C1B50-09A1CA75/0/0
X-purgate-type: clean
X-purgate-size: 1676

On 13.08.2026 16:56, Abdelkareem Abdelsaamad wrote:
> On the AMD platforms, the Xen hypervisor requires the FlushByASID CPU
> capability to support HVM nested virtualization (see start_nested_svm).
> Consequently, the L1 hypervisor must report FlushByASID CPU capability support
> when intercepting CPUID instruction for the CPU feature from the L2 guest to
> support nested virtualization levels beyond L1. Extend the exposed HVM CPU
> policy to surface this CPU feature support for the guests.

While the change makes sense, I have to admit that I consider it a stretch
to justify changes by multi-level nesting, when a single level of nesting
is in need of a lot of work to actually behave sensibly. Further, "to
support nested virtualization levels beyond L1" looks pretty Xen-centric:
Other hypervisors may permit this without the feature.

> While at it remove the dangling `exitinfo1 = ns_vmcb->exitinfo1;` assignment
> inside the nested exit handling of svm_vmexit_handler().

Unrelated adjustments to somewhat nearby or related code are generally
okay, but here you're touching a different file and entirely unrelated
code. I think the two changes want splitting.

> Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
> ---
> Testing:
>  - Using a locally developed XTF test to call cpuid_edx(0x8000000aU);
>    - without the change, EDX returns 0x4AB (the FlushByASID 6th bit is not
>      set).
>    - with the change, EDX returns 0x4EB (the FlushByASID 6th bit set).

And the CPUID test that XTF has wasn't suitable?

Finally: Can you please drop Roger's old email address that you still
had on Cc?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:35:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:35:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390222.1630730 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXTC-0007g7-Jf; Thu, 13 Aug 2026 15:35:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390222.1630730; Thu, 13 Aug 2026 15:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXTC-0007g0-Gy; Thu, 13 Aug 2026 15:35:50 +0000
Received: by outflank-mailman (input) for mailman id 1390222;
 Thu, 13 Aug 2026 15:35:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuXTB-0007fu-Ex
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:35:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXTA-001QSb-29
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:35:48 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de432-bab6-0a2a0a5309dd-0a2a4502d8aa-48
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:35:47 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de453-6ca4-0a2a45020019-d1558033e022-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:35:47 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4956242332dso493365e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:35:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49982129643sm65544965e9.4.2026.08.13.08.35.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:35:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786635347; x=1787240147; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=XIqw+W7WkEX/+hWJ6iBh8AtT2mQZXh7BV5wOkX8rIiY=;
        b=RR7BrjNQtB3UPaYuyFLwbwI9JhIQCdne8B2Y1NYpa7yFU++0PBxG1+kc8vmwp4U8ln
         1wIcVCob0RRruF0D83pjRvmELzMejb1mP9T/Ej2Bftu5J3+ng6GJQuVk0GxTfjFEKWgv
         VKYOOGgHdxRtesIP4JwGlgGOb6lOSFWZvwSnZUYl/0wAD3jAdIZPVj5yxOsxv3JFP74r
         nCzGrDOtCL6ZLlT/Shb49UDfJ1PTFrrpgZOyj4RpHSRBzJx7OX0Gspw9jdMU2MPkkfs2
         82wtbw2RrRzeQF4GiSrLxPg+DkN3KsnTY/lIFUBmAH5HSWNafIKzEPHvqtM3wvK17NYA
         XqxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635347; x=1787240147;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=XIqw+W7WkEX/+hWJ6iBh8AtT2mQZXh7BV5wOkX8rIiY=;
        b=fuRLeP97BUjv00yNqQYdpBpDt4UJTgLWYQg8e2ECBdxjc0yWDx4NgO0UcglI4eY1+v
         6rcqn0XnBL6NHcwfab2tNjpafO8XtmYKJ+WU62mfesk5d0i71/wDaO38hEoDEwKI5jIZ
         HPyBVFMamYdaxU+3s1zfoCUwJe3pe1UQpwHllU0CFjqQYgYQtCcVSSP+lV3TR75IZGyF
         z3F3NKeM0MzKbBjJsdKa74P469NG3oCFVuRmQBD/fXYcxwWzJygR48lvFbNEG/f2WtHp
         PbTjm0CnbS4t4ZdIj6cFdTEI0Yd2oz2k1TDfOS19Q9pbFIoXZdX65W9mdGEbTk8301XD
         hPuA==
X-Forwarded-Encrypted: i=1; AHgh+RoNFC3ipMG5WNP2wmznJ7YG3d6vjgJakjXRPWuneADhi1mm9SJZnLWc1/JPIqUJ5B6BM2NBxpEf8c4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw77bOMw809TyvMH3OFMWkM+bPdLXDvP8fztEi6zqbPycfCkcIA
	+s90ub74PSKoO07zvMzxnAZ18I15pAeaWNMIifUzIfj66jX7puje9N2CiQcASNVUog==
X-Gm-Gg: AR+sD122bRZcdAZvkbJ3bqchjgoDkatw1xzuGZrfuCi7eoEJ3ONwgGPV26MPYdwkLNK
	6NF0iqyT5HzpVGIjL7/GWl14UkCCaeUN8MqpftXgEK8uHeaYxPeVU7mCd6Qr2F977kZTqlBJqru
	QENRKXqyEW8uDD3O9EKQEvFHqkO0K1SD09d3UMmIQZEfjWlczzsSaZrVMGripL7X+233KlnuYoI
	QZWiSIrrjU4NYnqzsLWbd/QStk9IZ0cGp1eYW2ToJwm5xpTXe0Blqj6BOFUvP6ZXVvVHNro2eMk
	SMmfh1Jo+FTRrbhSIadv7Lky0Kgx9fA0oA4UDIvpfx3j3mj5XUNG0KJ14qLY8CXmivBtvDtcLeu
	dTNU38gduAEuu2ahj2/tOvWd+43+77RMx2Wztm7UADsXyTy0if1VohHynnE+d6ku2ZEP2PNZHen
	7zburgb4L+VG/BmNG31toc7nhmT1f+JTaZ70jvSCKpiiqS+4a+XJ15qvzNptPsGDgrj/OguThlk
	5XWD5m7Bs7xLEPn2rVyVgzXQNuyIO+hFnXav06ov5nMoWFFcmPL
X-Received: by 2002:a05:600c:3b9f:b0:499:4d4d:822a with SMTP id 5b1f17b1804b1-499821d77f5mr77258935e9.17.1786635347292;
        Thu, 13 Aug 2026 08:35:47 -0700 (PDT)
Message-ID: <450b45d6-bb22-44e5-816a-4a22243fa175@suse.com>
Date: Thu, 13 Aug 2026 17:35:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/20] xen/riscv: introduce guest riscv,isa string
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786635347-319CB2AC-E0C4F56F/0/0
X-purgate-type: clean
X-purgate-size: 1446

On 04.08.2026 17:47, Oleksii Kurochko wrote:
> @@ -34,9 +36,35 @@ struct riscv_isa_ext_data {
>      .name = #ext_name,                          \
>  }
>  
> +struct riscv_isa_ext_entry {
> +    unsigned int id;
> +    const char *name;
> +    bool guest_supported;
> +};
> +
> +#define RISCV_ISA_EXT_ENTRY(ext_name, guest_supp)       \
> +{                                                       \
> +    .id              = RISCV_ISA_EXT_ ## ext_name,      \
> +    .name            = #ext_name,                       \
> +    .guest_supported = guest_supp,                      \
> +}
> +
>  /* Host ISA bitmap */
>  static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
>  
> +/*
> + * ISA bitmap handed out to every guest.
> + *
> + * All guests are given the same extensions for the time being, so this is
> + * computed once out of riscv_isa_ext[] and riscv_isa, rather than redoing
> + * the walk for every domain created.  Should per-domain ISA policy ever be
> + * introduced, this will need to become per-domain again.
> + */
> +static __ro_after_init DECLARE_BITMAP(guest_isa, RISCV_ISA_EXT_MAX);
> +
> +/* "riscv,isa" string corresponding to guest_isa, shared by all domains. */
> +static char *__ro_after_init guest_isa_str;

This would better be pointer-to-const, as nothing should alter the string
anymore once it was built. Then:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:37:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:37:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390232.1630745 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXUc-0008Kv-91; Thu, 13 Aug 2026 15:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390232.1630745; Thu, 13 Aug 2026 15:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXUc-0008Kj-4U; Thu, 13 Aug 2026 15:37:18 +0000
Received: by outflank-mailman (input) for mailman id 1390232;
 Thu, 13 Aug 2026 15:37:17 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuXUb-0008I3-2D
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:37:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXUa-00DYu7-FL
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:37:16 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7de496-8faa-0a2a0a5109dd-0a2a450b8a4c-26
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:37:16 +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 <oleksii.kurochko@gmail.com>)
 id 6a7de4ac-b7e8-0a2a450b0019-d155802eb415-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:37:16 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4998590d392so737645e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:37:16 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981b0f6b1sm71714325e9.4.2026.08.13.08.37.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:37:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786635436; x=1787240236; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=saE5g8Am/lNHGtqQTN89TgfreqlX+yvOtgKlUJ85WoQ=;
        b=BTHiipQBcrT+c1ethwJPXDUBfW+NoDrSbwmIo8RQR6HVP+1jeFNAMei3obaGg5qui0
         iikASwWvKvmomqL6KdjFJh5TUoxiqUCZdk3eO/qZZO6CrqfxPnKWq54w5zPuSMSQXOKE
         pBpwlF+AFjj/T4mtNpldf+/EuJQbjju2S5lBIXT5QsXgPI9/YkUMOH1Z3tNCviWU58KG
         q/2YDmS2T0w9i2bwCa3DtShySeamSNVcMF8/ABOiUNqYg4wVfOJAip/m0OLBUHCw24ID
         TQ9J5TngKGxrvvuB60ddHmQ5Z3iFJG2knDPCyDFqF0e35HqViR2Uq/KTPwlfyfXzTMtt
         o59Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635436; x=1787240236;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=saE5g8Am/lNHGtqQTN89TgfreqlX+yvOtgKlUJ85WoQ=;
        b=q7AhayH2Pd+SS1NDsFVzHWiZjPrl/IJeQQWIFzkvSUoCctgCr0thyuelWcJjnaOlW5
         Zx3UG5tw4R8O3ah/J275+rrSIxnZ9L968QupasurpuI/9bOvdCDUCD0kWF4DuQrLEuxt
         bRF5mFBfOTsaIeEywoYH4MmrH5I1C13F8kcn8nhreF4WU3/ud78mTgpjXLqZ7sBtxl/v
         0uGZ4/o6qAHAanUXgtZbe3WKQtvxJOso+UaC6kJFPHuq2xj4xDSKbqJF4gHxRKZTDg75
         SxaPsEIamNMiOvMTMjHDU21p1Adx5s0oUVYYYiU8IiIJ1B91BBbjpwCS5E9bWe1vHfs3
         Gyng==
X-Forwarded-Encrypted: i=1; AHgh+RoLffeMsym390EB9BwgeWcaa430E1wfY/EFs6JtyN6BDu6dK+BLnaIllqNh9SHZvUaVIJqCSLqZ4/0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzfI9MOBj5zUp1gaq38DQIZOjInGtQWz5uCfmOmRYVF9s+RHb5P
	neR6ttiniS5d01wLO7pUtqfSuZlNPBytlrZsQzyqhSJc/33A9OiMdEQG
X-Gm-Gg: AR+sD12AA3FBTdj6i+vDQdWmifChNO3Ki0VK3fHVM3GiM8GDcRLvLJG6i4h8Q/88YTx
	SxaF5dDp7Z5/5rd+6MIXp1BQPOhHAFdpCIH4U04/mgM5rdJdksXUgmj+8c4qF5ot6/DejkG2bmG
	5txoRKUpQcyXJGNgJD5TveR0c+qjxssGgan6M8LZ6V+OSqFXhiBPwVbi3/t/Dy5kFz+zdPbTWLv
	Ss/kHjykVhM1gLSIUgooQ+CMQx2SzSXPh2cTe8cP9T4VebeexlXscGZSfg3Z3E9E0Kzogq4REAh
	41p0UpqxViDFYnp9ZMjZaAOQoisdiL/KLRtLVFQy75bAd/TgOEdHbnRW6zc8joQNKOkVlgslgwA
	qdgx5TWocZj9eIOX4a6hWF+IuOfNGayw+Vz/BKOD8v2rswlJ916Yq6nl9uR6qwYChgPIu6rQPdS
	gooH3T9KEsffnm01DlnVUBLyZU+WlDh2mgW/jY+BdAY3wXLak2jikv7ckJq2kmQjwoOCHjZJCxf
	hZqh4vLNl1XUIed26+3/uNJmsdxDtOxgBJaag1gKHM=
X-Received: by 2002:a05:600c:c054:b0:499:7aa7:eaa7 with SMTP id 5b1f17b1804b1-499821fa293mr63218975e9.15.1786635435706;
        Thu, 13 Aug 2026 08:37:15 -0700 (PDT)
Message-ID: <9abc0091-43e5-475e-ae61-697f480dda5e@gmail.com>
Date: Thu, 13 Aug 2026 17:37:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/20] xen/riscv: introduce guest riscv,isa string
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
 <3bb59f64-7ff1-4bdc-b951-cfb78671e8f9@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <3bb59f64-7ff1-4bdc-b951-cfb78671e8f9@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786635436-1A6DA9EA-C47A66DF/10/73395122804
X-purgate-type: spam
X-purgate-size: 9730



On 8/13/26 9:19 AM, Jan Beulich wrote:
> On 04.08.2026 17:47, Oleksii Kurochko wrote:
>> @@ -120,29 +148,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
>>    * and strncmp() is used in match_isa_ext() to compare extension names instead
>>    * of strncasecmp().
>>    */
>> -const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
>> -    RISCV_ISA_EXT_DATA(i),
>> -    RISCV_ISA_EXT_DATA(m),
>> -    RISCV_ISA_EXT_DATA(a),
>> -    RISCV_ISA_EXT_DATA(f),
>> -    RISCV_ISA_EXT_DATA(d),
>> -    RISCV_ISA_EXT_DATA(q),
>> -    RISCV_ISA_EXT_DATA(c),
>> -    RISCV_ISA_EXT_DATA(h),
>> -    RISCV_ISA_EXT_DATA(zicntr),
>> -    RISCV_ISA_EXT_DATA(zicsr),
>> -    RISCV_ISA_EXT_DATA(zifencei),
>> -    RISCV_ISA_EXT_DATA(zihintpause),
>> -    RISCV_ISA_EXT_DATA(zihpm),
>> -    RISCV_ISA_EXT_DATA(zba),
>> -    RISCV_ISA_EXT_DATA(zbb),
>> -    RISCV_ISA_EXT_DATA(zbs),
>> -    RISCV_ISA_EXT_DATA(smaia),
>> -    RISCV_ISA_EXT_DATA(smstateen),
>> -    RISCV_ISA_EXT_DATA(ssaia),
>> -    RISCV_ISA_EXT_DATA(sstc),
>> -    RISCV_ISA_EXT_DATA(svade),
>> -    RISCV_ISA_EXT_DATA(svpbmt),
>> +static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
>> +    RISCV_ISA_EXT_ENTRY(i,            true),
>> +    RISCV_ISA_EXT_ENTRY(m,            true),
>> +    RISCV_ISA_EXT_ENTRY(a,            true),
>> +    RISCV_ISA_EXT_ENTRY(f,            false),
>> +    RISCV_ISA_EXT_ENTRY(d,            false),
>> +    RISCV_ISA_EXT_ENTRY(q,            false),
>> +    RISCV_ISA_EXT_ENTRY(c,            true),
>> +    RISCV_ISA_EXT_ENTRY(v,            false),
>> +    RISCV_ISA_EXT_ENTRY(h,            false),
>> +    RISCV_ISA_EXT_ENTRY(zicntr,       true),
>> +    RISCV_ISA_EXT_ENTRY(zicsr,        true),
>> +    RISCV_ISA_EXT_ENTRY(zifencei,     true),
>> +    RISCV_ISA_EXT_ENTRY(zihintpause,  true),
>> +    RISCV_ISA_EXT_ENTRY(zihpm,        true),
>> +    RISCV_ISA_EXT_ENTRY(zba,          true),
>> +    RISCV_ISA_EXT_ENTRY(zbb,          true),
>> +    RISCV_ISA_EXT_ENTRY(zbs,          true),
>> +    RISCV_ISA_EXT_ENTRY(smaia,        true),
>> +    RISCV_ISA_EXT_ENTRY(smstateen,    true),
>> +    RISCV_ISA_EXT_ENTRY(ssaia,        true),
>> +    RISCV_ISA_EXT_ENTRY(sstc,         false),
>> +    RISCV_ISA_EXT_ENTRY(svade,        false),
>> +    RISCV_ISA_EXT_ENTRY(svpbmt,       false),
>>   };
> 
> Just as an independent, up front remark after having looked at patch 16/17 of
> the other series: Is a mere boolean going to suffice in the longer run? I could
> see some extensions wanting exposing to only RV32 or only RV64 guests. E.g.
> Zilsd is RV32-only, while Zqinx quite likely would want restricting to RV64.

Good point generally.

Right now the distinction can't be observed: RV32 isn't buildable 
(#error "RV32 isn't supported" in asm/config.h), and guest XLEN is 
hard-wired to host XLEN — build_guest_isa_str() emits the rv32/rv64 
prefix from the Kconfig symbol, and riscv_isa_parse_string() rejects a 
host ISA string of the other width.

On top of that, extensions with an architectural XLEN restriction are 
already filtered out for free: compute_guest_isa() masks the table 
against the host bitmap, so an RV32-only extension like Zilsd can't have 
its bit set on an RV64 build regardless of what the table says. The 
boolean only ever subtracts from what the host actually reports.

That leaves purely policy-driven per-XLEN restrictions — e.g. exposing 
Zqinx to RV64 guests but not RV32 ones, since Zqinx is architecturally 
defined for both. Those only become meaningful once guest XLEN can 
differ from host XLEN (i.e. hstatus.VSXL support), and at that point the 
shared guest_isa bitmap has to become per-domain as well, as the comment 
above it already notes.

So I'd rather keep the plain bool for now and widen it to a flags field 
when there's an actual case; it's a mechanical change to the struct, the 
macro and the single test in compute_guest_isa(), all local to 
cpufeature.c. I can add a comment stating the "guest XLEN == host XLEN" 
assumption so the reason is on record. If you'd prefer it as flags from 
the start I don't mind doing it now either. I just don't have a way to 
give either value a meaning yet. So if to do that now I would suggest 
the following:


+/*
+ * Which guests an extension may be handed out to, by guest XLEN.
+ *
+ * These flags express Xen's policy, not the ISA's rules: extensions which
+ * are architecturally tied to one XLEN (Zilsd on RV32, say) need no 
special
+ * treatment here, as they can only ever appear in the "riscv,isa" of a 
host
+ * of that XLEN, and guest_isa is masked against the host ISA bitmap 
anyway.
+ * They are only of use for extensions Xen chooses not to expose to 
guests of
+ * a given width despite the hardware implementing them.
+ */
+#define RISCV_ISA_EXT_GUEST_NONE 0
+#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0)
+#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1)
+#define RISCV_ISA_EXT_GUEST_ANY  (RISCV_ISA_EXT_GUEST_RV32 | \
+                                  RISCV_ISA_EXT_GUEST_RV64)
+
+/*
+ * Guests are of the same width as Xen itself for the time being; once 
guest
+ * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain
+ * property, just as guest_isa below does.
+ */
+#if defined(CONFIG_RISCV_32)
+#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32
+#elif defined(CONFIG_RISCV_64)
+#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64
+#else
+# error "Unsupported RISC-V bitness"
+#endif
+
  struct riscv_isa_ext_entry {
      unsigned int id;
      const char *name;
-    bool guest_supported;
+    unsigned int guest_flags;
  };

-#define RISCV_ISA_EXT_ENTRY(ext_name, guest_supp)       \
+#define RISCV_ISA_EXT_ENTRY(ext_name, guest_flgs)       \
  {                                                       \
-    .id              = RISCV_ISA_EXT_ ## ext_name,      \
-    .name            = #ext_name,                       \
-    .guest_supported = guest_supp,                      \
+    .id          = RISCV_ISA_EXT_ ## ext_name,          \
+    .name        = #ext_name,                           \
+    .guest_flags = guest_flgs,                          \
  }

  /* Host ISA bitmap */
@@ -149,29 +178,29 @@ static int __init dt_get_cpuid_from_node(const 
struct dt_device_node *cpu,
   * of strncasecmp().
   */
  static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
-    RISCV_ISA_EXT_ENTRY(i,            true),
-    RISCV_ISA_EXT_ENTRY(m,            true),
-    RISCV_ISA_EXT_ENTRY(a,            true),
-    RISCV_ISA_EXT_ENTRY(f,            false),
-    RISCV_ISA_EXT_ENTRY(d,            false),
-    RISCV_ISA_EXT_ENTRY(q,            false),
-    RISCV_ISA_EXT_ENTRY(c,            true),
-    RISCV_ISA_EXT_ENTRY(v,            false),
-    RISCV_ISA_EXT_ENTRY(h,            false),
-    RISCV_ISA_EXT_ENTRY(zicntr,       true),
-    RISCV_ISA_EXT_ENTRY(zicsr,        true),
-    RISCV_ISA_EXT_ENTRY(zifencei,     true),
-    RISCV_ISA_EXT_ENTRY(zihintpause,  true),
-    RISCV_ISA_EXT_ENTRY(zihpm,        true),
-    RISCV_ISA_EXT_ENTRY(zba,          true),
-    RISCV_ISA_EXT_ENTRY(zbb,          true),
-    RISCV_ISA_EXT_ENTRY(zbs,          true),
-    RISCV_ISA_EXT_ENTRY(smaia,        true),
-    RISCV_ISA_EXT_ENTRY(smstateen,    true),
-    RISCV_ISA_EXT_ENTRY(ssaia,        true),
-    RISCV_ISA_EXT_ENTRY(sstc,         false),
-    RISCV_ISA_EXT_ENTRY(svade,        false),
-    RISCV_ISA_EXT_ENTRY(svpbmt,       false),
+    RISCV_ISA_EXT_ENTRY(i,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(m,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(a,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(f,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(d,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(q,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(c,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(v,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(h,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(zicntr,       RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zicsr,        RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zifencei,     RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zihintpause,  RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zihpm,        RISCV_ISA_EXT_GUEST_ANY),
+    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(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),
+    RISCV_ISA_EXT_ENTRY(sstc,         RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(svade,        RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(svpbmt,       RISCV_ISA_EXT_GUEST_NONE),
  };

  static const struct riscv_isa_ext_data __initconst 
required_extensions[] = {
@@ -572,7 +601,7 @@ static void __init compute_guest_isa(void)
      {
          const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];

-        if ( ext->guest_supported &&
+        if ( (ext->guest_flags & RISCV_ISA_EXT_GUEST_XLEN) &&
               riscv_isa_extension_available(NULL, ext->id) )
              __set_bit(ext->id, guest_isa);
      }

Will you be okay with such changes or it could be postponed to a time 
when it will be really needed?

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:37:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:37:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390231.1630739 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXUc-0008II-0z; Thu, 13 Aug 2026 15:37:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390231.1630739; Thu, 13 Aug 2026 15:37:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXUb-0008IB-Th; Thu, 13 Aug 2026 15:37:17 +0000
Received: by outflank-mailman (input) for mailman id 1390231;
 Thu, 13 Aug 2026 15:37:16 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuXUa-0008Hx-K5
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:37:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXUZ-00DYu7-Cw
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:37:15 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de496-8faa-0a2a0a5109dd-0a2a450b8a4c-22
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:37:15 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de4ab-b7e8-0a2a450b0019-d1558034c5fb-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:37:15 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4980dc26022so663055e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:37:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49981de6a05sm102960845e9.1.2026.08.13.08.37.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:37:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786635435; x=1787240235; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=RKAGAixFLV9gD6GkQXyL6Hw2GTwqq6djfeYD+nY3O0o=;
        b=UDTKXItSXEuhOAKvN5CovW08JQUU0BbxBe3BEy/hehrh7DRir+jkoIYdRg3d5zDbQC
         4ZUzQuSr9qdOI0WdGmZp3DqXMa87+UlbGAd2gsbwf2VEU8EEpBy4tOyTADhOHiPtZbGL
         MXJYOQaSQDhrctUm13c6v2HzfphG9Vnlhm9ts1mL2jHpy36ia4/+JK81hB8iAsSdf66Z
         /IFDrU8KpJyWV3dWd08gl3tyk0Wh2usxheggzPhrv7jOnxBuZJdf2rJeVyYdLd2JlOoS
         ny+5sRbKcRHajlHsBuw47drAUhnxZu3r3B0FD+2yDLHV9mO2k8m4e7VVyedmWc7ktEil
         qixQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635435; x=1787240235;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=RKAGAixFLV9gD6GkQXyL6Hw2GTwqq6djfeYD+nY3O0o=;
        b=ceRYMh3+Hfv7wnslFkuc4vCx2BvPV6r2rp3DN1FyWu5SSkvFZBBmE5MOdXHfHqS2ZW
         6py4bYgxWB45bM+Pk6dT8uh4ODunm9zdF72bl7dRqqaGPT0Y0uw8IrY8kgmHMYTh77nQ
         BB3MrIuRlEH+Ql78HdEGl7+7RXfiMmFtSYVBEsBZZ+UQ2HAVWqaXFXgUIpRgLv/69gmz
         mYUD02aaj+uEmWMqIrbTe8Rwmjh4SC4Bs/e/6wGDMR3EZQGNd2DKCKhWypxf8M5S3U2U
         Ae/WR1nKczzHFBfPZqh/taImgylI830FaNdGQfsRz83vgsEZO5weMdIFHUToOQli3HGf
         5nKw==
X-Forwarded-Encrypted: i=1; AHgh+RpgDsNT3r3HLbe37VGJcg1osprApyd1POT/cgxrYp708W3awp+6BSLMn76Gwd/DHEOtj/caCF9WNG0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJH1yT8DdFGXYVJ6ywSKXob3o/bOiIGWPrRP0MZpHMPK8XY6pW
	5DB0V1XHbUozsF9ub9CcUCGymhjSPRF+w7pyQD9UK9r2EGi3c2nVmqO8GybPX1vYlg==
X-Gm-Gg: AR+sD10PQktp9phgIBueyzo4jaBgtR3vjSyfS6Xvw5Nl609sVxfdoFqgo6St4j6V7mD
	0HP1wAYirn9paoRLfNflnuyDxX3KHoZ4TTD7Z8FcwWbw6IJc7yvwnCS6jrbiA6+4X+9N+ZBMcHA
	9ZV9OADpPK7iJsNVC5ZLsokLYiouYLi/jTOvPZSCUDKObMR6VpAFIs16/W2I2zvpHio5OFEGICS
	AY1jUc3wOlIss6IVzT/rYpCewYstqbUVHnEoFai+2eyUfYWV1rGAr7dJtxKO7xmUwrfnqBMXbkj
	XXUBSaS5hXhYzT1WAlcpxaPkxuBA1Y0MruGsbY6yp0RRGCvDfpNZ0g2teLIO93qp01Xn5lNKfYK
	5/pfzDaJAV7oAN7erTBIALrX52qnfrZckmtL5p5KC3oJ4fjAIRuQ6gUw6XPbxoU3zolAyRD1bRG
	4QIWmhu5HgLeKVVFatOjKtl2EAzxBibCLWlOaxYOwEDH2vSKjHD1D1JzTxwtGMUE80yPqFvix5x
	tjUxItXKZQzBeJo4I0fEgTxVvOrVlrcW5biQaozoN4BCgl+Rn3L
X-Received: by 2002:a05:600c:470d:b0:499:484a:81d0 with SMTP id 5b1f17b1804b1-499821f1ebbmr70895205e9.9.1786635434812;
        Thu, 13 Aug 2026 08:37:14 -0700 (PDT)
Message-ID: <f20d3d30-96d3-4713-982d-4b27474de5f3@suse.com>
Date: Thu, 13 Aug 2026 17:37:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 05/20] xen/riscv: implement make_cpus_node()
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <4df84f91703588ca55c2c0fa73cadb9f94437571.1785836421.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <4df84f91703588ca55c2c0fa73cadb9f94437571.1785836421.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786635435-ABAD09EA-CBDA9A7E/10/73395122804
X-purgate-type: spam
X-purgate-size: 326

On 04.08.2026 17:47, Oleksii Kurochko wrote:
> Implement make_cpus_node() to create cpus node for a guest domain.
> 
> This function is going to be use by common dom0less code during
> construction domain.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:40:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:40:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390249.1630757 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXXF-0001Zq-Lh; Thu, 13 Aug 2026 15:40:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390249.1630757; Thu, 13 Aug 2026 15:40:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXXF-0001Za-Hh; Thu, 13 Aug 2026 15:40:01 +0000
Received: by outflank-mailman (input) for mailman id 1390249;
 Thu, 13 Aug 2026 15:40:00 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuXXE-0001ZJ-Cm
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:40:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXXD-00GDxd-Px
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:39:59 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7de541-2eae-0a2a0a5409dd-0a2a4504cc0c-16
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:39:59 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7de54f-b57f-0a2a45040019-d155802ff08d-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:39:59 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so435735e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:39:59 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499851141bfsm22865015e9.2.2026.08.13.08.39.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:39:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786635599; x=1787240399; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=N4q0fxP5wBDJlq2VjCkO83xALUPClcrEWGu0tlrgm1w=;
        b=Hd6ZvHASK0pAM8GUtKVWo71QmxZC3OR9qGjetiNtERJLnKQCUSScPenLaK8nq5iplE
         BIRkOI7tbcVVwy5tAPlzi7K7/plL0h7RDLZ4QSfN3xjuHC5i019MrQ6UtzBrSV/KqzLo
         K7ZntQWgWjCPbXROHkpZsnYnhAuuR4bU4QN7H0hbgrZuRIz+V1EXLDsTFh1qVWy/FClR
         ZOtxgImtShPe91Bnh6QCg00nUEm18DBvdHxxTSdx4b3yPQnjOcAZMDm0IqGbMwrB+UCF
         lEmtwyDrlhh4g5aoQw6YG2P62WhkN0qokuUwQ36yjXgCCvByv3VGccZBbVZGrBrMsdz8
         Au0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635599; x=1787240399;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=N4q0fxP5wBDJlq2VjCkO83xALUPClcrEWGu0tlrgm1w=;
        b=nuVqf7Wo6vkz2OIZzgs/wrO07ZIPqZC2SbnnHzAkDYCkBEZenzbwlsBGSChBYBhJAP
         SLk2tTatoVYjTFtDcjociykLlK8g7ZEuwE1IVv08MbzlvVvx18wqpNb2CwZf3u8jrYSv
         oidPhwsak+UsOKn/m35CJcFtGEBWZ/xmiOKLdkIzH0fOGKIoLM9L7Dt46wX2krYHLLrY
         xYxGyynUJuqqZFPq7DB16oPPLUsj9ccdKWUVy/leasXCAAcOYkfrKbMUDUcY1mdJPj26
         Azm4ZySpVpADJqsE0XRkW2lP7RZmZ3u8zAPx1SaVmSwFYqVjm1RO8hxmicX1wJ1Z+77y
         J/yw==
X-Gm-Message-State: AOJu0YxpPFgGbDCIZ0zeM27PGUVhB5bJDWujhAta2mTLiD0AFtrfqtle
	cQwiLx3POJgYu8dani8lhIiAlL4J5JmQVH9TGGgYZMKUx0bFZQ7Ez7NcElTRNA==
X-Gm-Gg: AR+sD10T7XOHz2dmblTWitYKNjJT+A8ZYjR4Nko6PLny/WrBPPcPOdoiEE4wW8lNn9x
	MPVMzuH8Z6+BiklkqqDtcoMhGiIbiOBW31RRhzjWkmfUBLFMDX7QZ7sGflzGsEker7cafBUED+7
	RT/wj+OuNAcDk82cnfGYCJ6fWy+oPA5fbhWYse70rajh/Wew7PaotK85LOARQevWzvc/uZmsp+e
	Eny2XKbC1bGk7gAATSxXNKRIKFPy1JtK4p/zs7Npj7tc7mgyPnbzNFBJElj3gSdvyiIAEdniivs
	3d6+q+t6rOY+r6hsGkngKGsrh1Y367gpzubXRzvh3/HtoXZvoQgdVBldOpWMf0iFV2txlpQyklc
	HSCWbunHzzCQYiPhZR1sKn1dimbCq7m1R03Qu7bYU4WTXx9gQ4mvpUHER4k9A53VKa5PSDu0QzD
	HU5EfnhKLean72dHNHxKdcHpVp8EHHzIqDNsqp5Q/q/RKM6kpizo3bAHJhRyiMNVbEPsk8pOl8w
	dRlBBJ1Nt5c9HrTqxvUxK5KhhfbCVyDha+9lCnav+w=
X-Received: by 2002:a05:600c:e558:20b0:499:518d:ebd6 with SMTP id 5b1f17b1804b1-49984ad90cemr39588075e9.17.1786635598925;
        Thu, 13 Aug 2026 08:39:58 -0700 (PDT)
Message-ID: <efc18770-3889-4d87-969d-c75ad82cfbc0@gmail.com>
Date: Thu, 13 Aug 2026 17:39:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 11/20] xen/riscv: introduce per-vCPU IMSIC state
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <d78555b8b7b683f72a2668d8d2e2da3f89a4fc06.1785836421.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <d78555b8b7b683f72a2668d8d2e2da3f89a4fc06.1785836421.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786635599-510DDB50-0B5A2297/10/73395122804
X-purgate-type: spam
X-purgate-size: 5092



On 8/4/26 5:48 PM, Oleksii Kurochko wrote:
> Each vCPU interacting with the IMSIC requires state to track the
> associated guest interrupt file and its backing context.
> 
> Introduce a per-vCPU structure to hold IMSIC-related state, including
> the guest interrupt file identifier and the CPU providing the backing
> VS-file. Access to the guest file identifier is protected by a lock.
> 
> Initialize this structure during vCPU setup and store it in arch_vcpu.
> The initial state marks the VS-file as software-backed until it becomes
> associated with a physical CPU.
> 
> Add helper to retrieve the guest interrupt file identifier:
> - vcpu_guest_file_id() is going to be used during update of APLIC's
>    target register with the pair of information <guest_file_id, cpu_id>
>    (to have MSI delivery mode work properly) when guest is trying to
>    access vAPLIC's target register.
> It will be used in the follow up patches.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> ---
> Changes in v6-7:
>   - Nothing changed. Only rebase.
> ---
> Changes in v5:
>   - Move v->arch.vimsic_state = imsic_state; after full initialization of
>     the struct, so the pointer only becomes globally visible once all
>     fields are set up.
>   - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
> ---
> Changes in v4:
> -  s/w vs h/w IMSIC VS-file commentary for struct vimsic_state:
>     - fix the vsfile_pcpu h/w condition:
>       "vsfile_pcpu >= 0" -> "vsfile_pcpu < NR_CPUS"
>       (the old wording conflicted with the s/w "== NR_CPUS" case).
>     - reorder both comment blocks to the "s/w ... / h/w ..." form for readability.
>   - drop IMPOSSIBLE_GUEST_FILE_ID: the s/w IMSIC VS-file is always available
>     and corresponds to guest_file_id == 0, which xvzalloc() already provides,
>     so the explicit initializer in vcpu_imsic_init() and the macro itself
>     are unneeded.
> ---
> Changes in v3:
>   - Drop const from imsic_set_guest_file_id() and vcpu_imsic_deinit() as
>     it only works due to vimsic_state being a pointer member.
>   - Use XVFREE() in vcpu_imsic_deinit() to make it idempotent.
>   - Fix SW-file typo in struct vimsic_state comments; should be VS-file.
>   - Drop imsic_set_guest_file_id() here, it will be added later when it
>     will be nessary to initialise guest file id as the correspondendt code
>     in this patch series was reworked and there is no need to use this
>     function in arch_vcpu_create().
>   - Introduce IMPOSSIBLE_GUEST_FILE_ID and init with it ->guest_file_id.
> ---
> Changes in v2:
>   - Rename imsic_state to vimsic_state.
>   - Use 'unsigned int' for vsfile_pcpu.
>   - Drop initialzation of ->guest_file_id as it will be by default zero.
>   - Add the comment about ->guest_file_id field.
>   - Drop __init for vcpu_imsic_init() as it could be used during post-boot
>     vCPU creation.
>   - Update the commit message.
>   - Drop locks around ->guest_file_id() in  vcpu_guest_file_id() and imsic_set_guest_file_id().
> ---
> ---
>   xen/arch/riscv/imsic.c              | 35 +++++++++++++++++++++++++++++
>   xen/arch/riscv/include/asm/domain.h |  2 ++
>   xen/arch/riscv/include/asm/imsic.h  | 22 ++++++++++++++++++
>   3 files changed, 59 insertions(+)
> 
> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
> index f7b70a8da09e..5a5758e45dc2 100644
> --- a/xen/arch/riscv/imsic.c
> +++ b/xen/arch/riscv/imsic.c
> @@ -16,6 +16,7 @@
>   #include <xen/errno.h>
>   #include <xen/init.h>
>   #include <xen/macros.h>
> +#include <xen/sched.h>
>   #include <xen/smp.h>
>   #include <xen/spinlock.h>
>   #include <xen/xvmalloc.h>
> @@ -56,6 +57,11 @@ do {                            \
>       csr_clear(CSR_SIREG, v);    \
>   } while (0)
>   
> +unsigned int vcpu_guest_file_id(const struct vcpu *v)
> +{
> +    return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id);
> +}
> +
>   void __init imsic_ids_local_delivery(bool enable)
>   {
>       if ( enable )
> @@ -312,6 +318,35 @@ static int imsic_parse_node(const struct dt_device_node *node,
>       return 0;
>   }
>   
> +int vcpu_imsic_init(struct vcpu *v)
> +{
> +    struct vimsic_state *imsic_state;
> +
> +    /* Allocate IMSIC context */
> +    imsic_state = xvzalloc(struct vimsic_state);
> +    if ( !imsic_state )
> +        return -ENOMEM;
> +
> +    /* Setup IMSIC context  */
> +    rwlock_init(&imsic_state->vsfile_lock);
> +
> +    /*
> +     * xvzalloc() already cleared the context, so guest_file_id == 0, i.e. the
> +     * always-available s/w IMSIC VS-file. Only vsfile_pcpu needs an explicit
> +     * initializer as its s/w VS-file value is NR_CPUS rather than 0.
> +     */
> +    imsic_state->vsfile_pcpu = NR_CPUS;
> +
Considering our conversation in another patch series vsfile_cpu would be 
better name. Don't you mind if I will change vsfile_pcpu -> vsfile_cpu 
and everywhere it is needed in this patch with saving of your Acked-by?

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:43:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:43:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390262.1630767 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXaU-00038L-5m; Thu, 13 Aug 2026 15:43:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390262.1630767; Thu, 13 Aug 2026 15:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXaU-00038E-1s; Thu, 13 Aug 2026 15:43:22 +0000
Received: by outflank-mailman (input) for mailman id 1390262;
 Thu, 13 Aug 2026 15:43:20 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuXaS-000388-Iq
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:43:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXaR-00DZXO-Vi
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:43:19 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de617-e002-0a2a0a5209dd-0a2a45048056-6
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:43:19 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de617-b57f-0a2a45040019-d1558035e8ef-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:43:19 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4954f5e8020so299975e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:43:19 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f2c6115sm210937f8f.32.2026.08.13.08.43.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:43:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786635799; x=1787240599; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=TWsqFzALJKPZBNysmY/yHO0BLhVYAJqhpdVrSsud/3s=;
        b=Chzw7kgmbD+b2+R9HNwIbEusaNU/Je3oSm40wYwOwyaJIViuqJ+HwxxF6j5m6pvk2o
         Xthuk4jmWk/et+pv4Ru/p4y/4rd9F7Z9TwEP0fPGhguW0nAAGZ/+GNRPBeIBINzIVZIV
         cfesvzT6dnTMIyGRZBrO52NlWaeXF6O7yOvoVqXmQ5yHH20rUbZ8wtefj3dTbeYSQP5G
         sBSVsA4S3/zPMFroExkMflX96XZHnXFaFkkRRk3zEkx4PjJJY/Gza9U4cSuf7IExEeUq
         NtI2SIiSbCvbQX+PmNzvCKPrcC2aEd3w02QxlpJKIGaWR9Nntt6Gt6TsBn3e5LgzziMO
         gd+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635799; x=1787240599;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=TWsqFzALJKPZBNysmY/yHO0BLhVYAJqhpdVrSsud/3s=;
        b=q3BhH4l1IM+OYV1sw1TYrmrHyuYEbLRBJBsPnpfq3s9M20bCh/wAJE3ghoFmSrhOjN
         2j61pkdSZV/kta1LjxKXfdIX9cgkNPNrqWvl9UP4Odd4K9ESHOCSzcPRTqLo0zQSD0xN
         GiDdgU+4LigSU9DZOIVbJHv8u0fSXRZd1TQ5fFKDhxJYH7hgXs6FLCUqv16ESC9Npa9p
         vbbofaRPpop8ldslHFGe5W12DhuKpALTUsy74eOgT62AC2uVHlZ8pxJdZD4XvkJrSff8
         IHwrkqQC10oXpnBQf7fVZEchi5tVHR5OJBWXeWP55Hge6B+T+xxslTV7Q9maqGs3pfzB
         B8uQ==
X-Forwarded-Encrypted: i=1; AHgh+RqP2imOficYmU0kakZTnq5WnaGskeDDdv3BZECdWebWsdZcY7CSg70SYZQORP2gPfJ54fZXUccYdtw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzO4ejhG5A9tVQqLqhXl682Hxy691qix9dxlj9kvXNBmWAHhWRK
	4yK+08M+Je0MF0NRj3FstPLwZFyRhROjK1XhL0Yz8Y16EKbKiz2GntKw7xjzsKV2IA==
X-Gm-Gg: AR+sD12WZ2rmi/YaG80RyMvKOgnCymUfIPvOOSRaJxQm8DlVhpBQUSSlqpRxIIt2JRG
	V9HXP+F2rn/Qr13k1IJbZf36YIcS7BXnuyJGnVu2pdpM7Wps31dZ4xsHti7SkvbSYbY3DXBEiw+
	466XujGzdkdVy49JZJngX+cADYw4dVxd3U1bi/yQwzLiaQ73gIGxI1DkJVX0ux/fV7MGbp1F7gw
	ZoKP7uW6js7nRveGaxziziHj+pzWoniYRVXqI0VRc9cKl7xNgUZcsKFVJw7a1LY6dZ4JX3rl7l4
	CUnG0yMDUtRhRQI7vs77XweqSXVbA4r/U1mGvv7JD/TxcmmgnNVC6FrczCCPPXGSMJ9ICiZl3aq
	4rzIHVhA7RFfGQQGFIYEhdTgHJUvCS5Tjn1nD1BVX/thPoD/iit0l8ScB9Ur7CKcxWat5vwSVsx
	AUffs9bFAq8QpsB1WVjWv2pSCwBjnl13Z/MctLQDib2QsG4WauQdBxYQNafm78jESZxEd8ZMaeB
	z/GYRP4/+EAyo6kRzQjmAZ3i2Dn6NnbdP5Iy/rQnqc5Zw4N2NFa
X-Received: by 2002:a7b:cb07:0:b0:499:8743:77c8 with SMTP id 5b1f17b1804b1-4998743785dmr7017325e9.8.1786635799048;
        Thu, 13 Aug 2026 08:43:19 -0700 (PDT)
Message-ID: <1d154b5a-a053-40e6-b0d6-36dc9baa2ade@suse.com>
Date: Thu, 13 Aug 2026 17:43:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/20] xen/riscv: introduce guest riscv,isa string
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
 <3bb59f64-7ff1-4bdc-b951-cfb78671e8f9@suse.com>
 <9abc0091-43e5-475e-ae61-697f480dda5e@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9abc0091-43e5-475e-ae61-697f480dda5e@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1786635799-504DBB50-48D81178/0/0
X-purgate-type: clean
X-purgate-size: 4844

On 13.08.2026 17:37, Oleksii Kurochko wrote:
> On 8/13/26 9:19 AM, Jan Beulich wrote:
>> On 04.08.2026 17:47, Oleksii Kurochko wrote:
>>> @@ -120,29 +148,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
>>>    * and strncmp() is used in match_isa_ext() to compare extension names instead
>>>    * of strncasecmp().
>>>    */
>>> -const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
>>> -    RISCV_ISA_EXT_DATA(i),
>>> -    RISCV_ISA_EXT_DATA(m),
>>> -    RISCV_ISA_EXT_DATA(a),
>>> -    RISCV_ISA_EXT_DATA(f),
>>> -    RISCV_ISA_EXT_DATA(d),
>>> -    RISCV_ISA_EXT_DATA(q),
>>> -    RISCV_ISA_EXT_DATA(c),
>>> -    RISCV_ISA_EXT_DATA(h),
>>> -    RISCV_ISA_EXT_DATA(zicntr),
>>> -    RISCV_ISA_EXT_DATA(zicsr),
>>> -    RISCV_ISA_EXT_DATA(zifencei),
>>> -    RISCV_ISA_EXT_DATA(zihintpause),
>>> -    RISCV_ISA_EXT_DATA(zihpm),
>>> -    RISCV_ISA_EXT_DATA(zba),
>>> -    RISCV_ISA_EXT_DATA(zbb),
>>> -    RISCV_ISA_EXT_DATA(zbs),
>>> -    RISCV_ISA_EXT_DATA(smaia),
>>> -    RISCV_ISA_EXT_DATA(smstateen),
>>> -    RISCV_ISA_EXT_DATA(ssaia),
>>> -    RISCV_ISA_EXT_DATA(sstc),
>>> -    RISCV_ISA_EXT_DATA(svade),
>>> -    RISCV_ISA_EXT_DATA(svpbmt),
>>> +static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
>>> +    RISCV_ISA_EXT_ENTRY(i,            true),
>>> +    RISCV_ISA_EXT_ENTRY(m,            true),
>>> +    RISCV_ISA_EXT_ENTRY(a,            true),
>>> +    RISCV_ISA_EXT_ENTRY(f,            false),
>>> +    RISCV_ISA_EXT_ENTRY(d,            false),
>>> +    RISCV_ISA_EXT_ENTRY(q,            false),
>>> +    RISCV_ISA_EXT_ENTRY(c,            true),
>>> +    RISCV_ISA_EXT_ENTRY(v,            false),
>>> +    RISCV_ISA_EXT_ENTRY(h,            false),
>>> +    RISCV_ISA_EXT_ENTRY(zicntr,       true),
>>> +    RISCV_ISA_EXT_ENTRY(zicsr,        true),
>>> +    RISCV_ISA_EXT_ENTRY(zifencei,     true),
>>> +    RISCV_ISA_EXT_ENTRY(zihintpause,  true),
>>> +    RISCV_ISA_EXT_ENTRY(zihpm,        true),
>>> +    RISCV_ISA_EXT_ENTRY(zba,          true),
>>> +    RISCV_ISA_EXT_ENTRY(zbb,          true),
>>> +    RISCV_ISA_EXT_ENTRY(zbs,          true),
>>> +    RISCV_ISA_EXT_ENTRY(smaia,        true),
>>> +    RISCV_ISA_EXT_ENTRY(smstateen,    true),
>>> +    RISCV_ISA_EXT_ENTRY(ssaia,        true),
>>> +    RISCV_ISA_EXT_ENTRY(sstc,         false),
>>> +    RISCV_ISA_EXT_ENTRY(svade,        false),
>>> +    RISCV_ISA_EXT_ENTRY(svpbmt,       false),
>>>   };
>>
>> Just as an independent, up front remark after having looked at patch 16/17 of
>> the other series: Is a mere boolean going to suffice in the longer run? I could
>> see some extensions wanting exposing to only RV32 or only RV64 guests. E.g.
>> Zilsd is RV32-only, while Zqinx quite likely would want restricting to RV64.
> 
> Good point generally.
> 
> Right now the distinction can't be observed: RV32 isn't buildable 
> (#error "RV32 isn't supported" in asm/config.h), and guest XLEN is 
> hard-wired to host XLEN — build_guest_isa_str() emits the rv32/rv64 
> prefix from the Kconfig symbol, and riscv_isa_parse_string() rejects a 
> host ISA string of the other width.
> 
> On top of that, extensions with an architectural XLEN restriction are 
> already filtered out for free: compute_guest_isa() masks the table 
> against the host bitmap, so an RV32-only extension like Zilsd can't have 
> its bit set on an RV64 build regardless of what the table says. The 
> boolean only ever subtracts from what the host actually reports.
> 
> That leaves purely policy-driven per-XLEN restrictions — e.g. exposing 
> Zqinx to RV64 guests but not RV32 ones, since Zqinx is architecturally 
> defined for both.

Is it? Can you point me at a spec, as I wasn't able to find any?

> Those only become meaningful once guest XLEN can 
> differ from host XLEN (i.e. hstatus.VSXL support), and at that point the 
> shared guest_isa bitmap has to become per-domain as well, as the comment 
> above it already notes.

Not necessarily - you could have an RV64 one and an RV32 one.

> So I'd rather keep the plain bool for now and widen it to a flags field 
> when there's an actual case; it's a mechanical change to the struct, the 
> macro and the single test in compute_guest_isa(), all local to 
> cpufeature.c. I can add a comment stating the "guest XLEN == host XLEN" 
> assumption so the reason is on record. If you'd prefer it as flags from 
> the start I don't mind doing it now either. I just don't have a way to 
> give either value a meaning yet. So if to do that now I would suggest 
> the following:

I'm fine with a comment, and I'd also be fine with the more extensive
logic. Main question being whether "guest XLEN < host XLEN" support is
meant to be added within the foreseeable future.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 15:46:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 15:46:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390273.1630775 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXd6-0003fq-H6; Thu, 13 Aug 2026 15:46:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390273.1630775; Thu, 13 Aug 2026 15:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXd6-0003fj-E9; Thu, 13 Aug 2026 15:46:04 +0000
Received: by outflank-mailman (input) for mailman id 1390273;
 Thu, 13 Aug 2026 15:46:02 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuXd4-0003fd-F6
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:46:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXd3-00DZxS-KN
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:46:01 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de6b2-2eae-0a2a0a5409dd-0a2a450380b6-22
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:46:01 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7de6b9-fae8-0a2a45030019-d1558033c105-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:46:01 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4954aff6088so582215e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:46:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499821652dbsm72151245e9.9.2026.08.13.08.45.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 08:46:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786635961; x=1787240761; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=BeLyY3tc1GZGkQymfgswaTEayfpXt6RYygApgC17uGE=;
        b=Hn13d7B4BkQj/FHV+yQZSwvdH4Gw5yY4a8U5Q1OzpaZyRGeBAa1hOwHXzYx14RBCIy
         7QZOPDarZx4v/2t6FDroPZ76yKy68S+13IUGmvueb5oaDEPP8vKG8C9T39Q1NXy7ka3+
         Hza1aZ0eR112+5T8XOEFrx/oh0RPbZ6ptfCxWGAAxdSIpHWp7jFeLXdjdGhx34UEamkt
         3iDqRjKYyZJDzcYmxeJWbRbHY5MHj8Drt4T1UlstJqG9xzAQuRNkBtF/nDvDmkW8GQiB
         kuVqdl3FFB5XLtDXMZISSTQhKUmF7PWldtpz83k2KpnK/41+ESaoADVxkC1m2co+VsUo
         UhfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635961; x=1787240761;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=BeLyY3tc1GZGkQymfgswaTEayfpXt6RYygApgC17uGE=;
        b=iFIf99T0s3+Uq6cxN1gOoTiVwsG6pLVkbno9LofQK5Npgch+DZ077ACxry+eBRmMD0
         nVwpTVpMLXPr9hGOblTtEceN4JcfSAOWdw4dK5coAUuE5jPtusRnDMX/SZdpLN9WuytT
         sn4fPZ39bvTqwVvwUV8dFdsD2IxlJ7QAOYQ6OojArwKKUOVLl6BPwaalksdikpHMwq0Y
         CL3I/htB3PTwWu/BzN/mOGeMvDU8G3XHpJmZ9BI38EIj9CtS9uxtwL+droBJYbYXfCdp
         T0UiFbBaaaZH6PK8fp+oPsFn7GwhIVQs6hQmvjpm2ubXdolLNts7l4Y7+7GPB5K0kgvM
         HLjQ==
X-Forwarded-Encrypted: i=1; AHgh+RqJUz0UYwxmFQpOmD+3vSal+UrOChiaqA7W3yL80BLD7pRXHP6Xbo3rvPBVBgQDTK41x7CS5Xp1x7k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz3+mfoCo5E4+ohvvO3CLGUEIr68PZyywHpReyLss6JSo3yWaem
	d7mF1J7Cw9VLw394dHpaK8vfnoH8bCdbyqORxvoHrErYfeK4k+rPj5NJl4Xss6gINA==
X-Gm-Gg: AR+sD10kgy9sp+/38oY1FZ4Azf7+Adzs8WIEDm5oJSstX4aspAVxPBSkBoQGPqFrGKE
	pQELYK81wmtStxrvDhP8NTRIlg/ApFpH5GcW6jAUvqFh21rwa/ddE/Uas0kc3HjE9hk8xOXbsPH
	n5C0Ckih2t8ZnVVYAAZ7t5Est55jjW6qc0K5XVaNjmMSqqeKi9WE7Okrr8IweaDpsHViTGIth7p
	rJZAgOV9OfQfDfrGP+pDgffb1/qRWTwcYHGPkaMfNVIfzNUMe/ahFBJ+wbW2OvgI7QiCXIJ0W7B
	+ZvnlR9eYgpwaZAX3kW03POKvp8oZHnRNmFOnzzNmZix8Xmw6w9gw3arpXCo4vw1qWnVoF4zgpg
	cmCO3ORxpxExgyrM/tS0DedEMA9ub797NvucLMCDhyivp7LNa843GEnaEwA1/b9zekuOa8TFsxV
	2qOLvadiduOGr3TwzP1IsseyDBMeStJS42wYZykBXhKERvG8E1h5go6pF+q25/xNhzDHW1zYbR0
	RvnlvcmDJ1Yb2amjNbiAAq0R69NstypjIh49av1EIfSAans1UfY
X-Received: by 2002:a05:600c:3113:b0:493:c634:952 with SMTP id 5b1f17b1804b1-499821aa438mr75304445e9.7.1786635961072;
        Thu, 13 Aug 2026 08:46:01 -0700 (PDT)
Message-ID: <3a4c363b-d847-4fc6-a44e-7484c7f650d3@suse.com>
Date: Thu, 13 Aug 2026 17:45:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 11/20] xen/riscv: introduce per-vCPU IMSIC state
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <d78555b8b7b683f72a2668d8d2e2da3f89a4fc06.1785836421.git.oleksii.kurochko@gmail.com>
 <efc18770-3889-4d87-969d-c75ad82cfbc0@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <efc18770-3889-4d87-969d-c75ad82cfbc0@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786635961-75C804E9-4D7E2F50/0/0
X-purgate-type: clean
X-purgate-size: 1301

On 13.08.2026 17:39, Oleksii Kurochko wrote:
> On 8/4/26 5:48 PM, Oleksii Kurochko wrote:
>> @@ -312,6 +318,35 @@ static int imsic_parse_node(const struct dt_device_node *node,
>>       return 0;
>>   }
>>   
>> +int vcpu_imsic_init(struct vcpu *v)
>> +{
>> +    struct vimsic_state *imsic_state;
>> +
>> +    /* Allocate IMSIC context */
>> +    imsic_state = xvzalloc(struct vimsic_state);
>> +    if ( !imsic_state )
>> +        return -ENOMEM;
>> +
>> +    /* Setup IMSIC context  */
>> +    rwlock_init(&imsic_state->vsfile_lock);
>> +
>> +    /*
>> +     * xvzalloc() already cleared the context, so guest_file_id == 0, i.e. the
>> +     * always-available s/w IMSIC VS-file. Only vsfile_pcpu needs an explicit
>> +     * initializer as its s/w VS-file value is NR_CPUS rather than 0.
>> +     */
>> +    imsic_state->vsfile_pcpu = NR_CPUS;
>> +
> Considering our conversation in another patch series vsfile_cpu would be 
> better name. Don't you mind if I will change vsfile_pcpu -> vsfile_cpu 
> and everywhere it is needed in this patch with saving of your Acked-by?

Such a rename won't invalidate my ack. What's important is that (here and/or
elsewhere) you make sure you only ever store CPU numbers there, not - like
you had it somewhere - hart IDs.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 16:00:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 16:00:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390291.1630783 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXr5-0000GF-MZ; Thu, 13 Aug 2026 16:00:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390291.1630783; Thu, 13 Aug 2026 16:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXr5-0000G8-JQ; Thu, 13 Aug 2026 16:00:31 +0000
Received: by outflank-mailman (input) for mailman id 1390291;
 Thu, 13 Aug 2026 16:00:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuXr3-0000Ap-Kn
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:00:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXr1-00Aq4D-Tz
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 18:00:27 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7dea0c-8faa-0a2a0a5109dd-0a2a4506d55c-30
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:00:22 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7dea16-195a-0a2a45060019-d155dd2ca571-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:00:22 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47de008b020so696711f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:00:22 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f2c07c6sm257685f8f.28.2026.08.13.09.00.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 09:00:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786636822; x=1787241622; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=8ZTDPsgS73No+3d60nDd1vgt69wGi4UR5uFziqx+4Fc=;
        b=C3F7HhnznmG3l0VjhRTLRP+NhlfFQgnZJnFsRtxA7zhx2fde2EchbNEXT0zA5mZ/wG
         IAnOwTalRcN+YdFlyingKsXAZXk4aYaw92qNStDH+SjD0gGu4CxndHrb0Of3RVujtKeA
         /xNcOqeoWybsiwSIByqKAMox2V3R1cwr3yGaGgUi3a+vtdy6YGWTO1iDK8j2qv+hfAOD
         8YHOw4zMPX0lCDOLh17pXTcQb6MQEvT+OAs1MxeYhBtbH2TQPZfgM9fGzkevbp9t5AYF
         dwlsDUkDiCzwtGN3iDupsXQvGWFI0QsS7ETJsH8vs6V80PRoDf7noXHE/GPdFtBsiaa9
         YcCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786636822; x=1787241622;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=8ZTDPsgS73No+3d60nDd1vgt69wGi4UR5uFziqx+4Fc=;
        b=Q2Vg+iqKf6TDlXg7l4B+NRWCjVf1NtZHhTRihje60QLCndN0muCcGI6xTWfz/NFfmQ
         Hm/JcQpknwni0EBT+Yj9huFNCI8Yu+acEibZ+3E+hwhgk1Ch3UG+5e3gs6nh7ve+Tqe4
         xnC8C9RgLiRWaUqmlXqGtkIunp7dbaQFePHgZMcRlJYt++RU3mKcA1oIpUVzK/nQV4UC
         XmU9+PV14cj3rxj5rLUi6DrCCCghp+OMOWHKiytBAojeXkEf/62ml/CaBLET4DZcrIB2
         buGgdcqjycDMLQMP9BhVdIBG24t6IwY13utVhz/yrTpVkCiiY9hr+giw/xA4W1/o7Kvv
         XqxQ==
X-Forwarded-Encrypted: i=1; AHgh+Rrh6+UJ3Jjap/lL2s9J74G+Ycgv8d1EcTr5afAZwD1Hk8o6ox7BgyPMNsZ6jPbH/uEQJlJtCoEYsTk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzW+qWg4rLoHQ+r9m4N6zpc8XTt2vJxWThsQTAYLwWohxlaBCbR
	+JGA4SMcStiEgMj7npjbp1h0aucV1oehV5bX42pMkh+LmxerJ7vc28Pz
X-Gm-Gg: AR+sD11LZonmoItSBrDAwadeP+EtDqWPaI4UVz0tn5nqdc1c7y6TC1MQ6+rojTii1rw
	JFQq6txSpO8n4cnlHCwRvx4tdkpfE6JsVu4CstAp5m2R3vv1g6moMgEBF/dkLQKfm5lNzj9Nrpk
	sQS/5oERvn2eb7mM4S/vJgc+Q6D7ho7jHRo265UxjE+1LGvHc0T0R40ythAq8VK9Eb7vz/nUCpZ
	HVP2KdycpNUDfhhxPrRq+BVNW0+PAEzFAj9JMaO0v8CIQy8Bsa3Ia0TKe/NYonjTpN/NJBPNXxP
	r5D+lmp0JnNT/u3FXfDPBJt43fLDY55Jshqw8UKzP2WFWCfjFWPXAVoRPeI2eEwdz6PCKGjuVpE
	bodRMmjkwZP/rMCE29YvgH02vDTPfA1Q9dTysQaeJuHkaq+urtAFr2bBGFhWkbBskJDL5/62i6u
	1sUYterm5Bg22KLS/NxpZRqssYnvzzzEH815ay5AB9cWZaBNAi9RmopnO277WQmPL8XcF6nZCS6
	7C8HNE/GyFPPLQUzw7N/KJUWFRG2HwPcylZjVOAh5OWoXmHo+VkuQ==
X-Received: by 2002:a05:6000:71b:b0:47f:86af:8fd8 with SMTP id ffacd0b85a97d-4815a52bd25mr10524941f8f.11.1786636821576;
        Thu, 13 Aug 2026 09:00:21 -0700 (PDT)
Message-ID: <42ad8111-d5e4-4f63-810a-95eb8038d4dc@gmail.com>
Date: Thu, 13 Aug 2026 18:00:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 04/20] xen/riscv: introduce guest riscv,isa string
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <59b5b69f53ef81d68fd279d9ee0c03f5ffbbc2ae.1785836421.git.oleksii.kurochko@gmail.com>
 <3bb59f64-7ff1-4bdc-b951-cfb78671e8f9@suse.com>
 <9abc0091-43e5-475e-ae61-697f480dda5e@gmail.com>
 <1d154b5a-a053-40e6-b0d6-36dc9baa2ade@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1d154b5a-a053-40e6-b0d6-36dc9baa2ade@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786636822-FE47377B-9D713E99/10/73395122804
X-purgate-type: spam
X-purgate-size: 5374



On 8/13/26 5:43 PM, Jan Beulich wrote:
> On 13.08.2026 17:37, Oleksii Kurochko wrote:
>> On 8/13/26 9:19 AM, Jan Beulich wrote:
>>> On 04.08.2026 17:47, Oleksii Kurochko wrote:
>>>> @@ -120,29 +148,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
>>>>     * and strncmp() is used in match_isa_ext() to compare extension names instead
>>>>     * of strncasecmp().
>>>>     */
>>>> -const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
>>>> -    RISCV_ISA_EXT_DATA(i),
>>>> -    RISCV_ISA_EXT_DATA(m),
>>>> -    RISCV_ISA_EXT_DATA(a),
>>>> -    RISCV_ISA_EXT_DATA(f),
>>>> -    RISCV_ISA_EXT_DATA(d),
>>>> -    RISCV_ISA_EXT_DATA(q),
>>>> -    RISCV_ISA_EXT_DATA(c),
>>>> -    RISCV_ISA_EXT_DATA(h),
>>>> -    RISCV_ISA_EXT_DATA(zicntr),
>>>> -    RISCV_ISA_EXT_DATA(zicsr),
>>>> -    RISCV_ISA_EXT_DATA(zifencei),
>>>> -    RISCV_ISA_EXT_DATA(zihintpause),
>>>> -    RISCV_ISA_EXT_DATA(zihpm),
>>>> -    RISCV_ISA_EXT_DATA(zba),
>>>> -    RISCV_ISA_EXT_DATA(zbb),
>>>> -    RISCV_ISA_EXT_DATA(zbs),
>>>> -    RISCV_ISA_EXT_DATA(smaia),
>>>> -    RISCV_ISA_EXT_DATA(smstateen),
>>>> -    RISCV_ISA_EXT_DATA(ssaia),
>>>> -    RISCV_ISA_EXT_DATA(sstc),
>>>> -    RISCV_ISA_EXT_DATA(svade),
>>>> -    RISCV_ISA_EXT_DATA(svpbmt),
>>>> +static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
>>>> +    RISCV_ISA_EXT_ENTRY(i,            true),
>>>> +    RISCV_ISA_EXT_ENTRY(m,            true),
>>>> +    RISCV_ISA_EXT_ENTRY(a,            true),
>>>> +    RISCV_ISA_EXT_ENTRY(f,            false),
>>>> +    RISCV_ISA_EXT_ENTRY(d,            false),
>>>> +    RISCV_ISA_EXT_ENTRY(q,            false),
>>>> +    RISCV_ISA_EXT_ENTRY(c,            true),
>>>> +    RISCV_ISA_EXT_ENTRY(v,            false),
>>>> +    RISCV_ISA_EXT_ENTRY(h,            false),
>>>> +    RISCV_ISA_EXT_ENTRY(zicntr,       true),
>>>> +    RISCV_ISA_EXT_ENTRY(zicsr,        true),
>>>> +    RISCV_ISA_EXT_ENTRY(zifencei,     true),
>>>> +    RISCV_ISA_EXT_ENTRY(zihintpause,  true),
>>>> +    RISCV_ISA_EXT_ENTRY(zihpm,        true),
>>>> +    RISCV_ISA_EXT_ENTRY(zba,          true),
>>>> +    RISCV_ISA_EXT_ENTRY(zbb,          true),
>>>> +    RISCV_ISA_EXT_ENTRY(zbs,          true),
>>>> +    RISCV_ISA_EXT_ENTRY(smaia,        true),
>>>> +    RISCV_ISA_EXT_ENTRY(smstateen,    true),
>>>> +    RISCV_ISA_EXT_ENTRY(ssaia,        true),
>>>> +    RISCV_ISA_EXT_ENTRY(sstc,         false),
>>>> +    RISCV_ISA_EXT_ENTRY(svade,        false),
>>>> +    RISCV_ISA_EXT_ENTRY(svpbmt,       false),
>>>>    };
>>>
>>> Just as an independent, up front remark after having looked at patch 16/17 of
>>> the other series: Is a mere boolean going to suffice in the longer run? I could
>>> see some extensions wanting exposing to only RV32 or only RV64 guests. E.g.
>>> Zilsd is RV32-only, while Zqinx quite likely would want restricting to RV64.
>>
>> Good point generally.
>>
>> Right now the distinction can't be observed: RV32 isn't buildable
>> (#error "RV32 isn't supported" in asm/config.h), and guest XLEN is
>> hard-wired to host XLEN — build_guest_isa_str() emits the rv32/rv64
>> prefix from the Kconfig symbol, and riscv_isa_parse_string() rejects a
>> host ISA string of the other width.
>>
>> On top of that, extensions with an architectural XLEN restriction are
>> already filtered out for free: compute_guest_isa() masks the table
>> against the host bitmap, so an RV32-only extension like Zilsd can't have
>> its bit set on an RV64 build regardless of what the table says. The
>> boolean only ever subtracts from what the host actually reports.
>>
>> That leaves purely policy-driven per-XLEN restrictions — e.g. exposing
>> Zqinx to RV64 guests but not RV32 ones, since Zqinx is architecturally
>> defined for both.
> 
> Is it? Can you point me at a spec, as I wasn't able to find any?

Well, it is not defined now but in the spec 
(unpriv-isa-asciidoc_20240411.pdf) it is mentioned:

In the future, an RV64Zqinx quad-precision extension could be defined 
analogously to RV32Zdinx. An RV32Zqinx extension could also be defined 
but would require quad-register groups.

> 
>> Those only become meaningful once guest XLEN can
>> differ from host XLEN (i.e. hstatus.VSXL support), and at that point the
>> shared guest_isa bitmap has to become per-domain as well, as the comment
>> above it already notes.
> 
> Not necessarily - you could have an RV64 one and an RV32 one.>
>> So I'd rather keep the plain bool for now and widen it to a flags field
>> when there's an actual case; it's a mechanical change to the struct, the
>> macro and the single test in compute_guest_isa(), all local to
>> cpufeature.c. I can add a comment stating the "guest XLEN == host XLEN"
>> assumption so the reason is on record. If you'd prefer it as flags from
>> the start I don't mind doing it now either. I just don't have a way to
>> give either value a meaning yet. So if to do that now I would suggest
>> the following:
> 
> I'm fine with a comment, and I'd also be fine with the more extensive
> logic. Main question being whether "guest XLEN < host XLEN" support is
> meant to be added within the foreseeable future.

We don't have such plans at the moment so it won't be in the nearest 
future even in downstream.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 16:02:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 16:02:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390300.1630793 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXso-0000qU-4E; Thu, 13 Aug 2026 16:02:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390300.1630793; Thu, 13 Aug 2026 16:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuXso-0000qN-1E; Thu, 13 Aug 2026 16:02:18 +0000
Received: by outflank-mailman (input) for mailman id 1390300;
 Thu, 13 Aug 2026 16:02:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wuXsn-0000qH-84
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 16:02:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXsm-001UMH-LA
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 18:02:16 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dea6d-e002-0a2a0a5209dd-0a2a4507ac88-42
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:02:16 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7dea88-b4ea-0a2a45070019-d155802be1fd-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:02:16 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49554ebb87dso696395e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 09:02:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499820c2897sm139554995e9.0.2026.08.13.09.02.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 09:02:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786636936; x=1787241736; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=QARw4/9fNbhPmIYnuVBMQ+PAynfQgdSQs7OwkdGP4y0=;
        b=fbjYBQxR/GYADZhJ4+atcb0ww5LT6zA4F+NVmMnvx/XCchKlgfjSrrNMafnkIC3jBf
         lXWOLEbTnlS0tYQ5LP6iWXkkbXqG+fTQWQPn66hoz/yKx373UGVr652zeG/ae0maA5hT
         5Bq+Q3qU6bquVBqbkqTMzftPFP1lyO7y3Xfnw8OkbblI4DZ+EATQMkbIjRrw4T/QU84b
         Z/Omr1fjeMLdYIjlyRqkveNRpkUh9Cup5B+DghmwTUdukhAEvzdoCs8osDTswfb8SYHK
         TOxwneBoODRnaYkN/QBL8VmGnMmW74V6DIbHNMUhjV88x0LXaZmO57QjjuAPH+y2yznv
         CjSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786636936; x=1787241736;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=QARw4/9fNbhPmIYnuVBMQ+PAynfQgdSQs7OwkdGP4y0=;
        b=SBKHRjeMuKBmsgr9BS3eZozSbk5BrhLSbHGh3Kw0xJl0Q77wy/t8+MEzor7sHv5AKL
         8tYs3ShfkEh/a6RpLNbKQ15y397KxqlvmCPcTV5ahQ66mbaSa0SZS72TJAuEbZJMbn61
         d3Wb6r+Q/C2uL/TIeQsP3T+IeE1H+1IF+bjlsJNnzVImErGvS0USwznVLKUA1LA6FVFY
         YTCzA7HPTfiD7RyZHSWvyRZlb+RrhTjyOjiGLW3MJa0toxsgm5AIZ/eh0bw3x4s19D2Q
         1QQ5d0ncAzbgAhM2pDgeoabnzAABgLQ4YTiZbaqtRo9p+QNy8UCZ9lfU0sj4QS+Cm6iX
         T3VA==
X-Forwarded-Encrypted: i=1; AHgh+RqmxT/qttw8eSfjAIoiX8VF3LfYiKCrW3cBD4RfvmAdtypyrbasucx1p3K5rMQrTXdhIvJ5YigJGFk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhpsW69yV/TfIPybn6IPAlt4HWe7D6TWf1hgYIdDLpsDT61Kzm
	YjtgjSSJaMUxhTD9vhwTBpMwA1ajpLBH3AS/rO9xz4yHebQ4uY0zLVG7z0QhqVfdNg==
X-Gm-Gg: AR+sD11M23cB38/6+aj5+55MtUOT/fytsupnHhhBlQI+kn2LgUiPDKvSsKJupMlKEO2
	NjmlQ1ne+BzbqlsXxn1box3WUtXSruvmvE0XjHePHlFxNfM1uhLixNAXmz2Ebgm3tG1cSZepzxf
	TOSBZIRElynYna6pfRsPUoDsxCnDcT/AOwJw5xcdLvfxcBwBrbmzR51fiBHxSCtHrI3c01WCO1I
	2eyF4cmdGezcKkjaTDz5quqUbHrLIVwPIF528QceJRJk71oUHXXAq/HcxR70SR82Wkx/3pgu3cQ
	msQbATUGgcemhK2vga9M25qfX6HuFmYphfdGMTIICthEiuojEnLdW9wu3y6RpPm/zfVo7U1DV8a
	PRJpOc+3Wx4p7DNDG/a0TyXvyForICLA/wurBsjqin4eir0qoKmV6AYLcKDFHYST59GcyC/jnVH
	xx1jNXNZeCpDgPk933fKovEcZoRp3n275CKF2lyyn9e/jmBrqMW+/VjQvWA5K2WnrlCdJsstsAh
	lvYleqDJJN9aUW6/ZeiermcmXt9QffzcKRuheoAbp8tcZ76TzcLg1RBKoGiyD8I
X-Received: by 2002:a05:600c:a00d:b0:493:cefc:d113 with SMTP id 5b1f17b1804b1-499821a1e0emr93501285e9.5.1786636935707;
        Thu, 13 Aug 2026 09:02:15 -0700 (PDT)
Message-ID: <46210477-e225-4f1b-93c4-758912eee9b0@suse.com>
Date: Thu, 13 Aug 2026 18:02:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 1/2] xen/console: re-calibrate rate-limiter based on
 user input
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260811233824.1874525-1-dmukhin@ford.com>
 <20260811233824.1874525-2-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260811233824.1874525-2-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786636936-A5CC7AE4-6943FEBC/0/0
X-purgate-type: clean
X-purgate-size: 1800

On 12.08.2026 01:38, dmukhin@ford.com wrote:
> From: Denis Mukhin <dmukhin@ford.com> 

First: What user input is the subject talking about?

> Current __printk_ratelimit() relies on hardcoded values 5000 and 10
> respectively to program leaky-bucket message limiting.

Which doesn't change, as ...

> Use 'ratelimit_ms' and 'ratelimit_burst' variables to re-calibrate
> limiter.

... the values of the two static variables never change.

> Ensure rate limiter is disabled if either 'ratelimit_ms' or
> 'ratelimit_burst' is 0.
> 
> Fixes: 26cf03554a75 ("[XEN] Implement rate-limited logging.")

I don't think anything is being fixed here.

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,6 +33,7 @@
>  #include <asm/setup.h>
>  #include <xen/sections.h>
>  #include <xen/consoled.h>
> +#include <xen/xvmalloc.h>

This shouldn't be needed, as ...

> @@ -1286,21 +1287,34 @@ bool __printk_ratelimit(unsigned int ratelimit_ms,
>                          unsigned int ratelimit_burst)
>  {
>      static DEFINE_SPINLOCK(ratelimit_lock);
> -    static unsigned long toks = 10 * 5 * 1000;
> +    static unsigned long toks = ~0;
>      static unsigned long last_msg;
>      static unsigned int missed;
> +    unsigned long limit;
> +    unsigned long elapsed;
>      unsigned long flags;
> -    unsigned long long now = NOW(); /* ns */
>      unsigned long ms;
> +    s_time_t now;
>  
> -    do_div(now, 1000000);
> -    ms = (unsigned long)now;
> +    if ( !ratelimit_ms || !ratelimit_burst )
> +        return true;
> +
> +    limit = DIM_MUL2(ratelimit_burst, ratelimit_ms);

... this helper shouldn't be (ab)used here. I further wonder whether we
really want differing behavior here for 32- and 64-bit hosts.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 17:03:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 17:03:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390350.1630803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuYq7-0004iP-Dy; Thu, 13 Aug 2026 17:03:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390350.1630803; Thu, 13 Aug 2026 17:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuYq7-0004iH-AI; Thu, 13 Aug 2026 17:03:35 +0000
Received: by outflank-mailman (input) for mailman id 1390350;
 Thu, 13 Aug 2026 17:03:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wuYq5-0004iA-KE
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:03:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuYq4-007DaN-JY
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 19:03:32 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7df8e2-bab6-0a2a0a5309dd-0a2a450bb2d2-4
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 19:03:32 +0200
Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a7df8e4-b7e8-0a2a450b0019-d155dd30a4b0-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 19:03:32 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-47fde295992so23576f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 10:03:32 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f2b27bfsm646246f8f.23.2026.08.13.10.03.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 13 Aug 2026 10:03:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786640612; x=1787245412; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qCw4fyOxR5RxseyWR8QPKYGo5XGTtX8NNzKul/VV0tk=;
        b=AoByQ5oWMuD/UGjXhlPd6Z40BHHomBT/b4eFyCgpBWLQMQ5RiksolX+ueFZ9vJeDCL
         0sl2gKrrGfZYGCiw2Y4iX4wcdsKoIPX9lQu/aS3aOQwXq53jSeuekK8iseplXebNNSLb
         3SlvbG3jYKdGtb/sZWEw7vbEF/yv2gOtZh2SqwTbqRg8pHnaUn8AbATSA+X7BgfNBFu8
         tfQ6IF6m56dZlkI2uHzfOa32kix3t3+yrTCuUUsr9yiXxsdZw+2LmScUNVn0Luh6ONrp
         Vmcf3MsDtwWGZUTkarPsg/oBYSiE6SkZxENkw4fL7OOw+WZ3dK9TB9IGRia539ppbZY3
         3Nag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786640612; x=1787245412;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=qCw4fyOxR5RxseyWR8QPKYGo5XGTtX8NNzKul/VV0tk=;
        b=lY7zJR/Yhqihb0XhMfAVWrGRby7VsKvFfx9ecCSdRxUp96uoVIWr8106F9zAgR14MR
         v9YjRMq7Ovmv+98KMXBzLJTfRxbueTBHHNxiTakSRaM+G1j4OQbfc4dK1RZ+Ke1sEPOT
         fwIEIi6K6ni5Sgew8gSgOuoKcTgnorsYoHFkHHfDOIsFJG9unH8B/EbOhFraw70degE4
         KKCuIWqy155DOER8+NVu5L1T7R01LcOgMSbP1wBMrNXK0I4oHNCla6ZGpzxi/CJGRGid
         tuKb1PhPjPT1oB11X4av+D0qFZ1pnoTZAWPww6kHl9epib3yzvbrMxWit5r/UMhUN6Vv
         +SXA==
X-Forwarded-Encrypted: i=1; AHgh+Rp3N3o2LikGaK+o0hM7bsB+fjd7ETxg20lkOfGOrUGr35UKHAMUJIZ/9syCiIHfz1JvneRmAIbo6MA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVtS+aS8lXHRrvvi+0iETF0a6o9F+4NSs7sYWXRUfygKt5QPib
	/fjBBxKKAAQ7iCa3ittOVlXK7OHjDybsbnFYxrA49Ua9ID/dlXL7UDp2R5xRsQ==
X-Gm-Gg: AR+sD12gmO2N0owe0MMHfdXYdOA4ZfCqpA2yIr6JsWmThgU2/hd8vgDv24WUFke8U68
	yD+AUYZ05lMK8Xw3VCl3WBpu/4c/5NGV8QOATf3f/Hssop2z6IoMngKnYRfh7I8tbw1MccdGOi1
	wjfKcdVQqtWsYLugrbsSrDyt/DUvhFvkOA8cszSTtJZI5ZTUKbCnFA8EFI5JC4jl5j+9/qn0+XI
	me+PmAXrQz9PWr4R3BPx6Trapux/gpIKCfWFGYbzw/+jk6/ILB+OvWM9UyyU03+46VMW5SLh+xo
	W91NHq4Q6Cu6J4swK0c76+gfb+1w6x1T4ghcMJ6IsrtCArqHfkbUaTcpCCJ64J2VEz+8dKAYLBL
	JdkFxAQnlEIUM9AcCVSlzaEuMiwClSNRw34bcvRd42yrG5UR7S6e44luEp94x6tGx3x8l7MtqZj
	0DOjQ+BXTei1lKHjVBFD6S1lr/taHIxp6L5fcZg0/W0N/OF+hMvo03N2GadYnnhdW0run6tpviH
	B29xYEJdyTu7/7xPWvUAih2mISITgcs/9UHUqbf4l4=
X-Received: by 2002:a05:6000:491e:b0:47f:7ea0:6c20 with SMTP id ffacd0b85a97d-4815a5f80c7mr11242611f8f.15.1786640611658;
        Thu, 13 Aug 2026 10:03:31 -0700 (PDT)
Message-ID: <31674604-d595-4706-b5b6-cb3e9ed4d148@gmail.com>
Date: Thu, 13 Aug 2026 19:03:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs
 without a shared page
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <ed247fcc594346ad20a3d12e5d49c8f48ba6792a.1785836421.git.oleksii.kurochko@gmail.com>
 <3bd3a9d5-444b-4bb5-9a4c-8353f98802a9@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <3bd3a9d5-444b-4bb5-9a4c-8353f98802a9@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786640612-18ECE9EA-68665AC1/10/73395122804
X-purgate-type: spam
X-purgate-size: 12149



On 8/13/26 4:54 PM, Jan Beulich wrote:
> On 04.08.2026 17:47, Oleksii Kurochko wrote:
>> On architectures that run guests in dom0less mode without the PV ABI
>> (currently RISC-V), no shared_info page is allocated and d->shared_info
>> remains NULL throughout the domain lifetime. Several places in common
>> code access d->shared_info through the shared_info() macro or directly,
>> causing UBSAN null-pointer errors on such architectures.
>>
>> Rather than adding runtime NULL guards that are logically unreachable
>> on x86 and Arm (where shared_info is always allocated), introduce a new
>> Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm.
>>
>> On !HAS_SHARED_INFO the shared_info() macro expands to a dereference
>> of shared_info_absent, an extern pointer that is declared but
>> intentionally never defined.  Any use of shared_info() that is not
>> dead-code-eliminated will therefore cause a link-time failure, making
>> missed guards impossible to overlook.
>>
>> The 2L event-channel ops call shared_info() and must not be compiled on
>> architectures without a shared_info page, so event_2l.o is gated on
>> CONFIG_HAS_SHARED_INFO. On such architectures evtchn_init() installs the
>> FIFO ops as a placeholder instead, so that a later guest opt-in to the
>> FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO
>> support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated
>> no-op evtchn_port_ops_none table is installed instead, so that
>> d->evtchn_port_ops is never NULL. evtchn_fifo_word_from_port() is
>> guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe
>> before evtchn_fifo_init_control() is called by the guest.
>>
>> With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global
>> dummy_vcpu_info, so writes through vcpu_info() could leak data between
>> vCPUs. Reviewing the write paths in common code: the write in
>> map_guest_area() stores the constant ~0 so nothing serious would happen
>> if it were leaked; the event_2l.c paths are not compiled on
>> !HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the
>> write in vcpu_info_populate() targets the new mapping buffer, not
>> dummy_vcpu_info.
>>
>> Outside common code, the remaining writes are x86 PV-specific, for which
>> CONFIG_HAS_SHARED_INFO=y. No code changes are needed.
>>
>> Finally, struct domain's shared_info field itself is gated on
>> CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL
>> pointer: every user of it is either arch code for an architecture that
>> selects HAS_SHARED_INFO, or common code already guarded by the same
>> Kconfig symbol.
>>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks.

> albeit still with a number of comments / requests:
> 
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -40,6 +40,41 @@
>>   
>>   #define consumer_is_xen(e) (!!(e)->xen_consumer)
>>   
>> +#if !defined(CONFIG_HAS_SHARED_INFO) && !defined(CONFIG_EVTCHN_FIFO)
>> +/*
>> + * Placeholder ops for domains with neither a shared_info page nor a FIFO
>> + * control block (CONFIG_HAS_SHARED_INFO=n and CONFIG_EVTCHN_FIFO=n). Such
> 
> I'd omit the part in parentheses - it only repeats what the #if already
> has.

Sure, I will drop then.

> 
>> + * a domain has no ABI to record event state in, so these are reachable
>> + * whenever an event is delivered to (or queried on) one of its ports; they
>> + * just discard/no-op it.  They exist to keep d->evtchn_port_ops non-NULL.
>> + */
>> +static void cf_check evtchn_none_set_pending(
>> +    struct vcpu *v, struct evtchn *evtchn) {}
>> +static void cf_check evtchn_none_noop(
>> +    struct domain *d, struct evtchn *evtchn) {}
>> +static bool cf_check evtchn_none_false(
>> +    const struct domain *d, const struct evtchn *evtchn) { return false; }
>> +static void cf_check evtchn_none_print_state(
>> +    struct domain *d, const struct evtchn *evtchn) {}
>> +
>> +static const struct evtchn_port_ops evtchn_port_ops_none = {
>> +    .set_pending   = evtchn_none_set_pending,
>> +    .clear_pending = evtchn_none_noop,
>> +    .unmask        = evtchn_none_noop,
>> +    .is_pending    = evtchn_none_false,
>> +    .is_masked     = evtchn_none_false,
>> +    .print_state   = evtchn_none_print_state,
>> +};
>> +
>> +static void evtchn_none_init(struct domain *d)
>> +{
>> +    d->evtchn_port_ops = &evtchn_port_ops_none;
>> +}
>> +#else
>> +/* Declaration only; the calls below are DCE'd unless both configs are off. */
>> +void evtchn_none_init(struct domain *d);
>> +#endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */
> 
> I think the (inverted) comment would be more valuable on the #else line.

I will do that.

> 
>> @@ -1324,9 +1359,15 @@ int evtchn_reset(struct domain *d, bool resuming)
>>           rc = -EAGAIN;
>>       else if ( d->evtchn_fifo )
>>       {
>> -        /* Switching back to 2-level ABI. */
>>           evtchn_fifo_destroy(d);
>> -        evtchn_2l_init(d);
>> +
>> +        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
>> +            /* Switching back to 2-level ABI. */
>> +            evtchn_2l_init(d);
>> +        else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
>> +            evtchn_fifo_init_ops(d);
>> +        else
>> +            evtchn_none_init(d);
> 
> This being the same as ...
> 
>> @@ -1625,7 +1666,13 @@ void evtchn_check_pollers(struct domain *d, unsigned int port)
>>   
>>   int evtchn_init(struct domain *d, unsigned int max_port)
>>   {
>> -    evtchn_2l_init(d);
>> +    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
>> +        evtchn_2l_init(d);
>> +    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
>> +        evtchn_fifo_init_ops(d);
>> +    else
>> +        evtchn_none_init(d);
> 
> ... this: Maybe have a small helper (evtchn_preinit()?), to reduce the
> duplication? Would require comment updates then as well.

I think then it will be needed to fix a lot of comments. My suggestion 
is the following:

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 0911808fe861..809638ce4bfd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -71,10 +71,23 @@ static void evtchn_none_init(struct domain *d)
      d->evtchn_port_ops = &evtchn_port_ops_none;
  }
  #else
-/* Declaration only; the calls below are DCE'd unless both configs are 
off. */
+/*
+ * Declaration only; the call in evtchn_preinit() is DCE'd unless both
+ * configs are off.
+ */
  void evtchn_none_init(struct domain *d);
  #endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */

+static void evtchn_preinit(struct domain *d)
+{
+    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
+        evtchn_2l_init(d);
+    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
+        evtchn_fifo_init_ops(d);
+    else
+        evtchn_none_init(d);
+}
+
  /*
   * Lock an event channel exclusively. This is allowed only when the 
channel is
   * free or unbound either when taking or when releasing the lock, as any
@@ -1359,15 +1372,9 @@ int evtchn_reset(struct domain *d, bool resuming)
          rc = -EAGAIN;
      else if ( d->evtchn_fifo )
      {
+        /* Switching back to the default ABI. */
          evtchn_fifo_destroy(d);
-
-        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
-            /* Switching back to 2-level ABI. */
-            evtchn_2l_init(d);
-        else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
-            evtchn_fifo_init_ops(d);
-        else
-            evtchn_none_init(d);
+        evtchn_preinit(d);
      }

      write_unlock(&d->event_lock);
@@ -1666,12 +1673,7 @@ void evtchn_check_pollers(struct domain *d, 
unsigned int port)

  int evtchn_init(struct domain *d, unsigned int max_port)
  {
-    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
-        evtchn_2l_init(d);
-    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
-        evtchn_fifo_init_ops(d);
-    else
-        evtchn_none_init(d);
+    evtchn_preinit(d);

      d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX);

diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h
index c8ee09807008..156514fefff6 100644
--- a/xen/common/event_channel.h
+++ b/xen/common/event_channel.h
@@ -71,8 +71,8 @@ static inline void evtchn_fifo_destroy(struct domain *d)
  #endif /* CONFIG_EVTCHN_FIFO */

  /*
- * Declaration only when !CONFIG_EVTCHN_FIFO; the (dead) calls in
- * evtchn_init() and evtchn_reset() are DCE'd in that case.
+ * Declaration only when !CONFIG_EVTCHN_FIFO; the (dead) call in
+ * evtchn_preinit() is DCE'd in that case.
   */
  void evtchn_fifo_init_ops(struct domain *d);

diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
index 3b6e619c5278..f11c4c16efa3 100644
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -423,10 +423,9 @@ static const struct evtchn_port_ops 
evtchn_port_ops_fifo =
  };

  /*
- * evtchn_fifo_init_ops()'s only call sites are in the
- * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branches of evtchn_init() and
- * evtchn_reset(), which are never reached on HAS_SHARED_INFO=y builds
- * because of DCE.
+ * evtchn_fifo_init_ops()'s only call site is the
+ * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branch of evtchn_preinit(), which is
+ * never reached on HAS_SHARED_INFO=y builds because of DCE.
   */
  #ifndef CONFIG_HAS_SHARED_INFO
  void evtchn_fifo_init_ops(struct domain *d)
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 930190054cf0..595dedf0792c 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -211,7 +211,7 @@ static bool evtchn_usable(const struct evtchn *evtchn)

  void evtchn_check_pollers(struct domain *d, unsigned int port);

-/* Close all event channels and reset to 2-level ABI. */
+/* Close all event channels and reset to the default ABI. */
  int evtchn_reset(struct domain *d, bool resuming);

Does it look good for you?

> 
>> --- a/xen/common/event_fifo.c
>> +++ b/xen/common/event_fifo.c
>> @@ -62,6 +62,9 @@ static inline event_word_t *evtchn_fifo_word_from_port(const struct domain *d,
>>        */
>>       smp_rmb();
>>   
>> +    if ( unlikely(!d->evtchn_fifo) )
>> +        return NULL;
>> +
>>       if ( unlikely(port >= d->evtchn_fifo->num_evtchns) )
>>           return NULL;
>>   
>> @@ -419,6 +422,19 @@ static const struct evtchn_port_ops evtchn_port_ops_fifo =
>>       .print_state   = evtchn_fifo_print_state,
>>   };
>>   
>> +/*
>> + * evtchn_fifo_init_ops()'s only call sites are in the
>> + * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branches of evtchn_init() and
> 
> Perhaps better drop "dead" from here; those branches are dead only when ...
> 
>> + * evtchn_reset(), which are never reached on HAS_SHARED_INFO=y builds
>> + * because of DCE.
> 
> ... HAS_SHARED_INFO=y, not generally.

Agree, we could drop it.

> 
>> --- a/xen/include/xen/shared.h
>> +++ b/xen/include/xen/shared.h
>> @@ -43,7 +43,13 @@ typedef struct vcpu_info vcpu_info_t;
>>   
>>   extern vcpu_info_t dummy_vcpu_info;
>>   
>> -#define shared_info(d, field)      __shared_info(d, (d)->shared_info, field)
>> +#ifdef CONFIG_HAS_SHARED_INFO
>> +#define shared_info(d, field) __shared_info(d, (d)->shared_info, field)
> 
> Is there a reason this line cannot simply be kept as it was?

No, I will fix that.

> 
>> --- a/xen/include/xen/time.h
>> +++ b/xen/include/xen/time.h
>> @@ -66,7 +66,11 @@ struct tm wallclock_time(uint64_t *ns);
>>   #define version_update_begin(v) (((v) + 1) | 1)
>>   #define version_update_end(v)   ((v) + 1)
>>   extern void update_vcpu_system_time(struct vcpu *v);
>> +#ifdef CONFIG_HAS_SHARED_INFO
>>   extern void update_domain_wallclock_time(struct domain *d);
>> +#else
>> +static inline void update_domain_wallclock_time(struct domain *d) {}
>> +#endif
> 
> Perhaps best to insert a blank line ahead of the #ifdef.

Sure, I will add.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 17:43:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 17:43:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390372.1630811 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuZSg-000616-7H; Thu, 13 Aug 2026 17:43:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390372.1630811; Thu, 13 Aug 2026 17:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuZSg-00060z-4E; Thu, 13 Aug 2026 17:43:26 +0000
Received: by outflank-mailman (input) for mailman id 1390372;
 Thu, 13 Aug 2026 17:43:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wuZSe-00060t-VI
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:43:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuZSd-0076Yx-P2
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 19:43:23 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7e0213-2eae-0a2a0a5409dd-0a2a4505a17e-44
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 19:43:23 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7e023b-4cb1-0a2a45050019-d155802aacdb-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 19:43:23 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-495590dde14so2725585e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 10:43:23 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49987779a11sm3878065e9.2.2026.08.13.10.43.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 13 Aug 2026 10:43:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786643003; x=1787247803; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7YMFuJMms+V3nzbvUzla9kD+AeHM+vlytqXfkk0/IRs=;
        b=Zdfm+8MQF0VEja0J3JPBRLP8vf1Qj30g76YIFjvgGsFpxI5moMUB+g3gfBpscY7hmN
         CBppsr+F77WAo9Z3uCHVjpBbtweomRBFPBwYt6s6CGPi4Dyw3P/sLjsXfdbkGDF+cKVY
         haWlMpSVyUZJRpHwKJVw3j+HlCyRU8flHbZKs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786643003; x=1787247803;
        h=content-transfer-encoding:content-type:mime-version: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=7YMFuJMms+V3nzbvUzla9kD+AeHM+vlytqXfkk0/IRs=;
        b=k4Bpycur29aBBnrpns/kcAU+csF+YQ95LUPP5wDKhpK4Z+oZdz0i62GLeHKGQjYp3B
         xoSch1lx5EhmWMdKyRdPGLXJgfL17pRId1vHNApgGvmXCi6CPTi1XwVyEFiGNxuVi8mb
         /Mc1kE4FnHN3+8WTvuTItjMJWv5xAIrhjVrm+nWES/njDwC7PvWhhokTniElHu41v7p6
         oGpxfTEjfVg9S3WIQlgaxn080bZcHqPovsCejfXkvMYrT0zoFxt2cTn7nBXHh0u6ExIL
         5eNaEyKPFqHUmeGB3bcODZRY0/Ro6MhUr0Y9kt4ylGZykHFfSMdXAofSlH2oguw8jEAn
         FJLw==
X-Gm-Message-State: AOJu0YyD39PthZlPNWyXq3v/uwLw5tBqH+1yWYagAxqd3coOsY5X4DPR
	oqpvDc72QHh8Q7YkMovQc5y+/bBSLFwPVrtrZ9xjjfH1IK1FjPYjEnpyPBhjeUH59yFT5VasLZu
	/bAIE/94=
X-Gm-Gg: AR+sD1128hn85A26n/QkOMAkbBsEvO4wJMtJn/w2ZMkffDFkaF/MAKloMXraMVAT5bC
	sMlsztVGXWmSiBYzwy88pCbBySOLUAdDueQWrWrV9RBfzi03VlG+61lV6ciSbbwJ7tz67Yw7fYv
	FvqyjZzluIBEZvYSEz6sCCROpoLb2ZEi4mEZwQlfivwZZOYjT9rYjAnAztRAlTwEhnMnbmu3BPP
	JuMvBde8JiYFr4hGAd4GAGC+hoev1/siit6hPQA0QvBOYLzFrXDCvVfpgKJ39z+vxHzSNltNfXD
	CCTtoLrlhCHsMbNPsyiM3WAPe5IZi4yl9qR2pMLZnjRw1dAYue8nKJRHIz5JvNRtgSv1C+buqB0
	gNPIeufu+lb6Na7KxPnjO/sUB1mgsw4XsgQrpDrHTa6ULxRnNPKHjmKlD4NG+73WkdUaMrEj+p7
	6z5d0ECS3qrDrtypMpVcR0fuzh6isLYH6WDPKPnE429h4MGWoIIeO2BLQyo+kP18dhEy5isXWdX
	deWIcERsAMMVWfqtIyy6wINkdkrKyZSdXSTWmU=
X-Received: by 2002:a05:600c:1d89:b0:499:726a:117c with SMTP id 5b1f17b1804b1-499879bf7d0mr780895e9.19.1786643002850;
        Thu, 13 Aug 2026 10:43:22 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/nmi: Fix mis-classification of watchdog NMIs
Date: Thu, 13 Aug 2026 18:43:19 +0100
Message-Id: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1786643003-F70B22A1-D099A82B/0/0
X-purgate-type: clean
X-purgate-size: 3211

It used to be the case that cpu_data[] inherited the BSP's cpuid_level until
the AP had calculated it itself.  Following the rework, cpuid_level has a
placeholder 1 until it is caluclated propely.

setup_apic_nmi_watchdog() happens to be called on the BSP after SMP bringup,
meaning that the first call is on CPU1.  It is also positioned in the window
where cpu_data[] is garbage.

As a result, setup_p6_watchdog()'s one-time calculation of the performance
counter width falls back into Pentium compatibility mode assuming 32bit
counters.  This causes a watchdog NMI which is delayed a little (e.g. from an
SMI), to appear as if it hadn't overflowed, and therefore be (mis)classifed as
not a watchdog NMI.  On systems where unknown NMIs are treated as fatal, this
results in a spurious crash.

Switch setup_p6_watchdog() to use boot_cpu_data.cpuid_level, which is how this
is checked almost everywhere else.

core2_vpmu_init() used the same pattern to look at leaf 0xa.  Despite being
init code and only running on the BSP, {boot,current}_cpu_data are different
objects, so switch it over to checking boot_cpu_data.cpuid_level too.

Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

Found on a system where:

   [root@box ~]# time xen-ucode ./blob

   real    0m9.166s
   user    0m0.001s
   sys     0m9.165s

is changing several expectations, and spurious crashes from mis-classified
watchdog NMIs is just one part of the problem.

I hate this fix, but it's the only thing which I consider remotely safe to
backport.  Recent attempts to alter CPUID ordering have 0 success at being
bug-free.

I have not investigated what else was broken by the cpu_data[] change, owing
to a lack of time on my part.  I would be amazed if this is the only thing.
---
 xen/arch/x86/cpu/vpmu_intel.c | 2 +-
 xen/arch/x86/nmi.c            | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index ed9f62b9366d..af6cb0a85cdd 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -896,7 +896,7 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void)
     unsigned int version = 0;
     unsigned int i;
 
-    if ( current_cpu_data.cpuid_level >= 0xa )
+    if ( bsp_cpu_data.cpuid_level >= 0xa )
         version = MASK_EXTR(cpuid_eax(0xa), PMU_VERSION_MASK);
 
     switch ( version )
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 91f95fe6d080..ec85516609b0 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -321,7 +321,7 @@ static void setup_p6_watchdog(unsigned counter)
 {
     unsigned int evntsel;
 
-    if ( !nmi_p6_event_width && current_cpu_data.cpuid_level >= 0xa )
+    if ( !nmi_p6_event_width && boot_cpu_data.cpuid_level >= 0xa )
         nmi_p6_event_width = MASK_EXTR(cpuid_eax(0xa), P6_EVENT_WIDTH_MASK);
     if ( !nmi_p6_event_width )
         nmi_p6_event_width = P6_EVENT_WIDTH_MIN;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 18:05:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 18:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390219.1630819 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuZnW-00029Z-Tf; Thu, 13 Aug 2026 18:04:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390219.1630819; Thu, 13 Aug 2026 18:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuZnW-00029S-Qm; Thu, 13 Aug 2026 18:04:58 +0000
Received: by outflank-mailman (input) for mailman id 1390219;
 Thu, 13 Aug 2026 15:31:46 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ruoyuw560@gmail.com>) id 1wuXPG-0007Wt-K9
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 15:31:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuXPF-009x93-KM
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 17:31:45 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ruoyuw560@gmail.com>)
 id 6a7de349-bab6-0a2a0a5309dd-0a2a450bc1c0-48
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:31:45 +0200
Received: from [209.85.214.169] (helo=mail-pl1-f169.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ruoyuw560@gmail.com>)
 id 6a7de360-b7e8-0a2a450b0019-d155d6a9cdb0-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 17:31:45 +0200
Received: by mail-pl1-f169.google.com with SMTP id
 d9443c01a7336-2cc97653887so1076835ad.1
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 08:31:45 -0700 (PDT)
Received: from haichao.tail057a43.ts.net
 ([2001:da8:e000:1206:3b7:6da1:c188:d14f])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2d37c4e8098sm11911405ad.84.2026.08.13.08.31.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 13 Aug 2026 08:31:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786635103; x=1787239903; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=5PO43KtK1vinlhveejSpb/w0mOz3aVvtFpKxNKIjn3Q=;
        b=SZtONlbgC7aXywlk40MDcZG3OJDcYKUoLLxnE6mleBj0KH5TjvBhfNp2c/3Kl16iW4
         nUvcR21mgpXUcOZdkepV82hNg3Ypzh/gSPuiGdVISnYjZ+qfVOM25T6xumLaBujDS4pK
         IcVakOSmE40DkP/ii4ZZW27fINI1oO109eqIhBOeWcffRq16DhLP8pvapI0XDALEv7vz
         eyT4R2Tfr0OSpOCE6w3NEPxTjn9vYTMI07lYS/yfrPH2K+BEVk3gOxZIVxzyAYodTwPk
         SIfk3wEDGMGKOLySVDXVSlV3O1NFJSRT4ZNgwTaquad0Msu4j+KE+1UUVmCi7pkjLjF/
         Eaig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786635103; x=1787239903;
        h=content-transfer-encoding:mime-version: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=5PO43KtK1vinlhveejSpb/w0mOz3aVvtFpKxNKIjn3Q=;
        b=cdNYPuwy5ecECcAg9i35V99or2NuoCuiPg6Euc9GTK9blPAJsYL9cJSTySzYpH1nlK
         fhnno7wEkfVNTa5JC6FyaoQTs+jr5HeybIdyaH40ge/IeLCMmY3rNDa07BOc/4moyqr9
         St4rwPic6DtKHxfNLnVmgcwMV2gIRznGfQ52PAg8mR3IxDey5nhu17HzSZiX75cSfVeR
         KTKIWa03/v8aBruP4JvwCqgi0YQ7mGA71UrV6ZJiWfMzhM3gh+XuKqkBQBGSC01xZX5d
         SRtVrPLnMa7PVzMVkJ4sKNOj8QQUuY/tICjxtmfh2rg1TmQyXNQ72Ivqkaj1tveWHmlT
         2w0w==
X-Gm-Message-State: AOJu0YxnjNQQiSpuPiDPWW49+bOPJX7zjVi9lbJjNLhhls/J1IVEZxsW
	z1CQdWizj5OYxwU/VTJUwZzR1w5QdsT4fPy+5cU2ebz0iSdCjSTgD1G05D4oJAYjztA=
X-Gm-Gg: AR+sD10JFGJLPuW/kV6bkr/rfGUdJCtIskiJfAbz9tek6gabZKnVc1PIvRi8Gfgr4/0
	Aletpk03/071Q3foeU2ideg0rpMDSu647yKBSrda5FVn/uR6flYGh6knnOVKkmKoTo1QSWI7LM7
	vSjxNzF8MUkaKPGJu/KmlG9WEdiy9AoYtBEmePv9dDY/dYc4YYj02LsY0wkULwzWDY6iHpHVDl8
	0iJ1dwzcxsARC10ERqBVWWjgCtqFXHn1IypjO4LH0EeGObVch8Nek4Ec4wXnwCAD6vf10eFdvg8
	pUDmzrznNzsz2CQBbd2T8+T2toAavdoOZWQ2gZtlTzEFeh0nzyYJn0mVWjXU5Mr7Gv7F1omjOay
	oJP3EJ/0621/tTfRuI6c/LTiwo+9MfD4Y/mrgnqOvbGY9bbmOhwTqoblDBe1Lrn17CA3VkhaQ9y
	S1uTJ7WGhBraCD8P7lYIVuFONmrThvpf9g9F1XRgp07CxQMJtIk9zKYRegq0sgEYhmtByMxMoZl
	ce8iFcV
X-Received: by 2002:a17:902:ea0b:b0:2c9:9a19:df with SMTP id d9443c01a7336-2d37ebb174cmr71789975ad.18.1786635103360;
        Thu, 13 Aug 2026 08:31:43 -0700 (PDT)
From: Ruoyu Wang <ruoyuw560@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com,
	bhelgaas@google.com,
	linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Ruoyu Wang <ruoyuw560@gmail.com>
Subject: [PATCH] xen/pcifront: Fix PCI device reference leak in AER handling
Date: Thu, 13 Aug 2026 23:31:38 +0800
Message-ID: <20260813153138.3953222-1-ruoyuw560@gmail.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786635105-18CCF9EA-38E32766/0/0
X-purgate-type: clean
X-purgate-size: 2422

pci_get_domain_bus_and_slot() increments the reference count of the
returned PCI device. pcifront_common_process() drops that reference only
when the device or its driver is missing. All paths for a bound device
either return directly after invoking an error recovery callback or fall
through without calling pci_dev_put(). Consequently, each AER request for
a bound device leaks a reference and can keep the device allocated after
removal.

Store the callback result, release the reference after callback dispatch,
and then return the result. This keeps the device alive while its callback
runs and balances the lookup on every successful path.

This issue was found by a static analysis checker and confirmed by manual
source review.

Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
 drivers/pci/xen-pcifront.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index cffc32d6603277..07263dfe22d538 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -575,6 +575,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
 						struct pcifront_device *pdev,
 						pci_channel_state_t state)
 {
+	pci_ers_result_t result = PCI_ERS_RESULT_NONE;
 	struct pci_driver *pdrv;
 	int bus = pdev->sh_info->aer_op.bus;
 	int devfn = pdev->sh_info->aer_op.devfn;
@@ -597,21 +598,25 @@ static pci_ers_result_t pcifront_common_process(int cmd,
 		pci_dbg(pcidev, "trying to call AER service\n");
 		switch (cmd) {
 		case XEN_PCI_OP_aer_detected:
-			return pdrv->err_handler->error_detected(pcidev, state);
+			result = pdrv->err_handler->error_detected(pcidev, state);
+			break;
 		case XEN_PCI_OP_aer_mmio:
-			return pdrv->err_handler->mmio_enabled(pcidev);
+			result = pdrv->err_handler->mmio_enabled(pcidev);
+			break;
 		case XEN_PCI_OP_aer_slotreset:
-			return pdrv->err_handler->slot_reset(pcidev);
+			result = pdrv->err_handler->slot_reset(pcidev);
+			break;
 		case XEN_PCI_OP_aer_resume:
 			pdrv->err_handler->resume(pcidev);
-			return PCI_ERS_RESULT_NONE;
+			break;
 		default:
 			dev_err(&pdev->xdev->dev,
 				"bad request in aer recovery operation!\n");
 		}
 	}
 
-	return PCI_ERS_RESULT_NONE;
+	pci_dev_put(pcidev);
+	return result;
 }
 
 
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 13 18:36:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 18:36:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390403.1630829 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuaI2-0008V0-65; Thu, 13 Aug 2026 18:36:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390403.1630829; Thu, 13 Aug 2026 18:36:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuaI2-0008Ut-2w; Thu, 13 Aug 2026 18:36:30 +0000
Received: by outflank-mailman (input) for mailman id 1390403;
 Thu, 13 Aug 2026 18:36:29 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wuaI0-0008UU-Q2
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 18:36:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuaHz-00GbK2-VY
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 20:36:28 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e0e9c-8faa-0a2a0a5109dd-0a2a4506990a-12
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 20:36:27 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e0ea8-195a-0a2a45060019-94a392176f4e-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 20:36:26 +0200
Received: from pps.filterd (m0482516.ppops.net [127.0.0.1])
 by m0482516.ppops.net (8.18.1.11/8.18.1.11) with ESMTP id 67DHinV7636690
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:36:24 -0700
Received: from ph0pr06cu001.outbound.protection.outlook.com
 (mail-westus3azon11011040.outbound.protection.outlook.com [40.107.208.40])
 by m0482516.ppops.net (PPS) with ESMTPS id 4g1h88hqmf-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 11:36:24 -0700 (PDT)
Received: from SJ0PR05CA0073.namprd05.prod.outlook.com (2603:10b6:a03:332::18)
 by LV0PR16MB7012.namprd16.prod.outlook.com (2603:10b6:408:346::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Thu, 13 Aug
 2026 18:36:22 +0000
Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com
 (2603:10b6:a03:332:cafe::6a) by SJ0PR05CA0073.outlook.office365.com
 (2603:10b6:a03:332::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.12 via Frontend Transport; Thu,
 13 Aug 2026 18:36:22 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Thu, 13 Aug 2026 18:36:21 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67DI1svF554887
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:36:21 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkgcdtxv-2
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:36:20 -0400 (EDT)
Received: from localhost ([19.12.76.221]) by cmsmtp with ESMTPSA
 id uaHpwoa0QgCzquaHqwVyLk; Thu, 13 Aug 2026 18:36:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppford; bh=J93gNFg1w6xPup5L3QkkJfytNmz
	x+IO6XyrvU4tXMxU=; b=BNPWmNTqd90I3TmDw/YPdHgfmJOh5qm6dpqttrjwnbK
	MI0acxXrYOyQXq/S+udcJU+enPFJIzICbzzzZD/3b6AsoNO2BakB3VhHpViUkXJC
	srjRDH1xnNSlY88hDlo4JyVwVmqsHNghyf4RYuuFjh/svnECIt2gkWMEC1iBnVaq
	r79y9UjD03TNcR8Bl0ttBApB8jik4u4oPAyVv/4PA0Pjkaq7S1gwGuTC681zD8gc
	ZVeWfm6GFWMK+JwNfv4P6DDaSDkybtj6b3kVLkB0+GyoceZ6YXrF47oPGYjwfZJu
	KlSAtbAGfGjUrQ522ovl1zSlTr75dFZZjQ6u0Ao4cbQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VjUTI02AYe7ZViRSHRsnmjtpNv2EaV/bssWP/uUMhIqbhO39rtr/k51vvHIuaYK7KmDMke+38KTPsZ3fPfKgF6sdZMsmDVi32l+bQ6oIKZYVfcv2XKDD9FF3W+kvoKVIspQQBQ37NWPMnFfDR4Qu8HveLZFt8OjxnQ9BN4t+1/0r+nFRl5Kt23HSnwwUrZma36/TKCXF+jdMmQNPegQ91uFCBIJr3jsrWui2Ij525OBXSwW8+yJBfUYiBCePdRd4Smx9TTRPD+wyWOyU7Hv12Bu7FnYj5wyj5ChqwX4DTadar7KIlE3EsrN4YCtnpA3v0m2UgK8nDGaW2APTs4vygw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J93gNFg1w6xPup5L3QkkJfytNmzx+IO6XyrvU4tXMxU=;
 b=SYDYPmQKvq6/AbxQmvItAw6t4K7K8oaNHjX6dV9QY3m4swaEInenFBlhRDNBQbecWCbHwQ8lEDx2kKDYU0SHlh6YcclSM/wsxOpdDpImSScfFywrhuF5E8OtZ+8P6LVSeeptS0KFNIOFY7LqAEJL2SNGhkTVZotfE2ALnaEH1tlGiSFDe7wT1SROxYbi/e51gwvuUI2wHULK/Udh46JnjU3lSx0/e1HKsItE3v2SLmxYajx06QFPhKS3srMG+U4e5AuE//pU7OAwrq7+f1hLmI925swIuepqvIINPaE2gMXUP+5SznbXXQY4d5MMEu4WjPb6QpH35gJK8RNOYk/2GQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=J93gNFg1w6xPup5L3QkkJfytNmzx+IO6XyrvU4tXMxU=;
 b=O0wRUOjBz5uLXrtakKEx+LYSO9jtIyGmPQg6gtEE81sBIoGEEmlonJ0Ld5Uz0NptzXOvcx4b8Vl/FSjRxFJudOo8N9lK3z/yPr5dYWkJZJca64SVQLwRgwBqfQFI1vftnV8f5Pa8Q9Q9eUNl4kBmSFyxAQjcioj8kuE7CYzswjo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppserprodsaar;
	 bh=J93gNFg1w6xPup5L3QkkJfytNmzx+IO6XyrvU4tXMxU=; b=gnpLU5qgJsnT
	kqMrA5ilbjx/Q4d9Z9FB+Q08J5bihhlKj8WCJDy6v17W9hC6SF7TpeMRVC9E5Yqf
	r8L2MugH5WPGzDGd06rSWGg6DWnd2ShSWDl656jRA5nSW1tWVtbQIiHJIP1hwzcy
	7Go8CMVjAdVCUf5xP5KmK+eZ2rMonuEK9hAOCXD2X6syZmanjAYPTNKSE7l8U38T
	zzL7Tnj8R42RaNC/x7ukmAHzS0ymMhAcjrADbNmA1DEWWF7NCbZ30ScfDrjwywe5
	uAG88ooFOzwloVJM0kK9RAwQ2OAL6N/uLux0C9WGkrqDh+bMoyZ0kNEjHMJZEbTM
	SffjThYN8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppfserpocford; bh=J93gNFg1w6xPup5L3Qkk
	JfytNmzx+IO6XyrvU4tXMxU=; b=W40eK51zrkFQNlhcB84VaMBYgQyIE19Rheyr
	J40d+6/S0Z0px7O/sIOdonu5ra/lXUFJ5PTt/8FE3L+cyZOEjyd2v5YYNafGcH2y
	zM4odWKnJCaaBRvaOQzTAvY145QkGaZ4rG9oJ3U2me20Opu5QNG79usF4C82pWDY
	/2UOza/+qtGN+tgL+Hs/u1jDWUXx0txASl7P+6d9iz7kTfAVvXDeAI5VbnoYEBM4
	yNJdzg1JScMfJIVG+7zK3K8rVX8khLfIvZlulhMT2j0Z8/I0T12rnFkKMUnoGAIz
	wXn2rBU19hKWBlqLtiZl05hkupo8tHsSwrhluORbsN9Uu8ozRQ==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: uaHpwoa0QgCzquaHqwVyLk
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Thu, 13 Aug 2026 11:36:17 -0700
To: Jan Beulich <jbeulich@suse.com>
Cc: dmukhin@ford.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5] xen/common: add keyhandler to show Xen command line
Message-ID: <an4OofEH50hEi5Vm@kraken>
References: <20260813035139.915536-2-dmukhin@ford.com>
 <04442bf7-7a19-4eb6-be86-8332da2a5958@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04442bf7-7a19-4eb6-be86-8332da2a5958@suse.com>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_05,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 spamscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608130134
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CE:EE_|LV0PR16MB7012:EE_
X-MS-Office365-Filtering-Correlation-Id: 654e7aad-cdd0-464a-5b8f-08def969c5f9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|36860700016|376014|1800799024|82310400026|6133799003|10067099003|4143699003|11063799006|56012099006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	oBKQjyY6cSt7kiEVywK+av64k+CNGYPMTAcd+CUz0VSRXtN9yfuYbW7mO3jYUr+Wlz+Xzb+mJxsqtazYN0LzjU83ZKvHjqr0TqTIFbBrkgHZdvB/X1A181omy5m6wW28qz1KwFugQMOu9tOkUC1ZMJow4pqrXWADdlYc/5bPfsZudQK/Q7mvavYbHyrQzkA4SqEks/FWDRPhE+dr5ZT9HwDE44gt3gljKv2faaiiPteD/7HZUPFegxvvLXUtoLLDf/ek7tCi+JXa6Hs/DE+f/m9iE3ah864nCV4B5e429GyY5+VPS+lZIn3fcB4PydtNzsnEbXM58HUy037d/rFBE80IAIMS40kx5rGo5uL4iPbEWhVmzVmYMsKiBvZDRm8QM5zki52GOqmCoBkuLPcE5BtQu/0jPLQL5WEM3Cx/ZQt838KrMRXraH1yuT9EBi24JITRMta8/Ld5Y898GRis4lbe6lwUoJusJDRJnqzRy7VFpNnE4fkf9fhBpwFl1pKJ1H/KOUXzc8yByKWX2oT1Gim0IXTBYXIXGUu6R9fahjYAxYHtrjIZIarCkexwMH/F71BPbovP+Nqf2Lw0d3VTTGV4VwP5F48XSOMKk6DIQFtVEcox8l8vnEZTepH4e+vhUwV+XLyl1DXHDaPoXdGxkoRQIhMJK/ggTcaftn9S1bqAT4qJnmpGxoUw5wCSGf1KuCtYBmwBcIUK9L/WVH3yiw==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(376014)(1800799024)(82310400026)(6133799003)(10067099003)(4143699003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	chF6W3dKBU3QJvMVWQQ2eQAcp4JN5d+C3kc/Jj87HJ5DKaYfTeGYAfVpGtYBW+AgYe+GFlgfYiMFA6j5zLogRLwfMJaxFgaXuDA5gieu8cwQh2KOpdxyDQCZ+D3KiDCrQfheyynskuHCnOi0aPZuH8IOJiUDZ6JPA3QcPXpUHnvRmd+XxqyOXxmV5IQosfmx2F8pVDG50ASRnEMXuWEZtmIAoO18hplgSjGr26XlXGHNi7V9PqydVqvKKAKuET9R/M6hP8yNosdvg5zHRx7GULfOPwmH948caKBdFsEtB7IwK6MwpyqHjjFi5+Ip30gu9B7b0otjISH6L87JT5V1XgLBL7dCWWisfF67N12beTR/yyJyq7I1VUrgKSqGTKPgUdpwdzk1stQ15wM210Ck+HOD6GgFlRg1BzsNt9RZ8Vn7d7L9ahzk73FnqeNFyo3J
X-Exchange-RoutingPolicyChecked:
	S5JcBFINmzCb9AxAo3CRyd8rhyYAnN3R+XgnzUM6EOLp/fZyq7lMwi3/YaZKohlNTcfrA8WS9mHPoa2vtbDg8rcZzbY8IgZ+AOv5UtjSBSxoExfzXuZpaC9I35eozYKo/NvVuXO+wqS4Dpz8SG1Rza1x1PoOOsYwVky3YzZtgQmH+eXFTpJnqFSjaohPD8wh9SaE2uZynPG+UjzW6CdK6wAonXsf6aSDEnUvnbZ2cBH7TxEzBQba1jGyBqZQcfWRrOLmA/AG4AUFTuI6UUZ5YpsByRytHDwo4We/eSfCVoqTb89AIy/GNbbLjAGpug3QAwS2svdpAh/EqmyS1rTdSg==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	iOpHPzRRYRfDD31uuzbTswDMamEDrqXf5+TaC9rw6XYUkf+klFMt1qiksGq4t7CPOFnwsMdhbAmnkQfqJKqPSC1SXvbTjE3ZERPr4rtjH6krBOlrbqx+KAmYCJdNjAGBpSonKgfJ3kXnB4FtIt4kr9yiA4EiYspfVSXzYPD1zbF+4d3gxOnJMPdBe0aVgEgQLPwIBEKYAitOov3c/rsCWwQHqW4y1MU4KgHrGkbiBD5Va9d0SjyGm3RPTyLdb5nnDWukECKB8rnHmgsP+Xf1SHcGNC+FAaNCEcSAKuIZcGKAkTckMsuqZUkUvPDemDRtO95i+Hz37UFqKdCk5FOCCBpTjF8pgcucWXHoYKkpk2FvuIABrE++8hF7+SP2F2uLgz+3gH4aGIav9n3NRhZUy+EYItvRobQQqfBVovot4Mun2GUUWbPVkpHtbNAq+9tg9FzPVJRnmYXw/gi4sz0UCsn6AdANJrbwWl9+kz79gAYdIze+hv5lIuzmSw3kdtU4FR0LSYRjPZ3HP7d1CCO7JY0j54Y8TEvN19Ava/oFC285bOkEZRyfwalrcCIYc6L821BsPA2teFRWWAFjnUp3NSQ70yylPArdwsSy49AKpxoqWR2+msnGd0Yol0tgsuLVs7GoTLg+pLYV/HIsw5fELQ==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Aug 2026 18:36:21.8858
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 654e7aad-cdd0-464a-5b8f-08def969c5f9
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF000023CE.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV0PR16MB7012
X-Proofpoint-Spam-Info: AW1haW4tMjYwODEzMDEzNCBTYWx0ZWRfX38uTVQyrF4+J
 dMgRqu3ooDzUHv3hMnigSdpeG3HxLdxXKugg4STKi/BH9RJ8cZy3Qh6lJfllk2Zcjrdu71B6WYL
 sI5PbULy2zq7aC8JaHQWTETLy4xGiXokHVgEeIq52Q73URJp0VF7
X-Proofpoint-ORIG-GUID: BwzB0R1difCG4Y7p-egCaFtbSQ5IFl-w
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEzMDEzNCBTYWx0ZWRfX/hgCiHuSjWKF
 rf6jv7M4UzfkLeg8dJROry5/V0ZEImaaAyFlNhruOISQtVP6Il+W2FKlZ7d5zzVybDbyh0DvqmA
 3eapHbLAv+3P5CjZQPSjVGXCqAl/04D54sijPN6v1Ab0cvPDjHUgo98WIOUFLjZLdAg19mYueK9
 QCxxPR497A8l1i+IP0Vz0EWJTy3FG6Wcgru6iiJK/SI+odRDEKfcAh9PtGtY1gzqKdWxor8Buh7
 heHkXOxWhYnQPmmDEA/xnDnYjO9ge8Zu+cc9VGMEcZt+TjzwAA13AN2YcSuKx9rWQtwscFn6yhw
 x1BuavBweCBOAJ/1+fkyqO18Ma5LASKDs/4ul4JJtuAxwCpQpdpc93pbu5r3+ff3Rv5HjoJnZ/r
 Hgg6DQ8FrVDMJ1o/955ttoq1JxrwqFTBSpZKb8u1lRLOxsjm7lbBYVNUb71qlbu0aHgLK6101HS
 OUHwvTO7/IWdXRdqPOg==
X-Proofpoint-GUID: BwzB0R1difCG4Y7p-egCaFtbSQ5IFl-w
X-Authority-Analysis: v=2.4 cv=Xda5Co55 c=1 sm=1 tr=0 ts=6a7e0ea8 cx=c_pps
 a=SygfnsF0+onPdWEB+AKh+Q==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=NvsXeTrgx-CJMFV-xl94:22
 a=cbNQJ9GKAAAA:8 a=29axmnuJF_3FvSqT780A:9 a=CjuIK1q_8ugA:10
 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_05,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 impostorscore=0
 spamscore=0 priorityscore=1501 clxscore=1015 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608130134
X-purgate-ID: tlsNG-16d1c6/1786646187-F480577B-BC634AB4/0/0
X-purgate-type: clean
X-purgate-size: 1327

On Thu, Aug 13, 2026 at 08:00:11AM +0200, Jan Beulich wrote:
> On 13.08.2026 05:51, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com> 
> > 
> > Currently there's no way to print Xen command line on the emergency
> > console for debugging purposes when 'xl' is unavailable.
> > 
> > Add new keyhander '?' to do command line printout.
> > 
> > To allow built-in command printout, drop __initconst in
> > 'opt_builtin_cmdline' declaration.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v4:
> > - promote opt_builtin_cmdline to __ro_after_init and use it for
> >   built-in command line reporting
> > - account for empty saved_cmdline
> > - adjust register_keyhandler() call - use '?'
> 
> This isn't quite what I was expecting, following the feedback you got on
> v4. My expectation was that we'd see a 2-patch series, first patch moving
> non-help stuff out of the 'h' handler, second patch adding the dumping of
> the command line. Naturally the new handler then wouldn't be named
> show_cmdline(). I'd then further expect tat no new use of
> register_keyhandler() would be necessary: The handler itself would live
> in keyhandler.c, and print_version() would then be accompanied by a new
> print_cmdline().

I see, will update.

> 
> Jan
> 


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 21:18:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 21:18:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390469.1630839 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wucoq-0000e6-5y; Thu, 13 Aug 2026 21:18:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390469.1630839; Thu, 13 Aug 2026 21:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wucoq-0000do-1c; Thu, 13 Aug 2026 21:18:32 +0000
Received: by outflank-mailman (input) for mailman id 1390469;
 Thu, 13 Aug 2026 21:18:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MYTl=GG=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wucop-0000dA-3n; Thu, 13 Aug 2026 21:18:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wucoo-00EBEX-4T; Thu, 13 Aug 2026 23:18:30 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=MYTl=GG=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a7e3478-e002-0a2a0a5209dd-0a2a4509c816-34
 for <multiple-recipients>; Thu, 13 Aug 2026 23:18:30 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=MYTl=GG=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a7e34a5-be1a-0a2a45090019-8c4da68ac932-3
 for <multiple-recipients>; Thu, 13 Aug 2026 23:18:29 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id 78800A03D6;
 Thu, 13 Aug 2026 23:18:29 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Biosfp3CpO7b; Thu, 13 Aug 2026 23:18:29 +0200 (CEST)
Received: from end (127.106.204.77.rev.sfr.net [77.204.106.127])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 2ABFAA027F;
 Thu, 13 Aug 2026 23:18:29 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wucoh-00000003dtV-1E53; Thu, 13 Aug 2026 23:18:23 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786655909; bh=eUm/BKILMvafmrYaAKy7p85VbQYkTASxN3IRiK88RCk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=O7Nyy3Zu6kR+j1p4jHFpbmgUkRh6di5+NZQm+LZqghGXRNyB1PtS2w6GqqJ/KHX1w
	 bXmqWvdmM1E6Hk6mEJgFLbfIuv2nk/9DgO4BI3BrVp/Ipq7jvXvBFfJbCdFXA4Ogl/
	 VAmynStpYlZ3jFWv+L7gj6CCHG8YRLzwLJi18IkBzBLacXo+V0en3NMAI7oNpoXYoO
	 BgJFeGNJBiGJhl9uxAwNTpPi5N3aK/Vi10MA/KNR1Q/EGDWoNZW7u37UTvPq3CoUie
	 zFX5UAL9P1eSsq4yene0VCj9rSR3M5dKqT5GpXY+I36LE+AYBt65MFMIMBVcqqKVqb
	 comsu6HoYYRew==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786655909; bh=eUm/BKILMvafmrYaAKy7p85VbQYkTASxN3IRiK88RCk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=O7Nyy3Zu6kR+j1p4jHFpbmgUkRh6di5+NZQm+LZqghGXRNyB1PtS2w6GqqJ/KHX1w
	 bXmqWvdmM1E6Hk6mEJgFLbfIuv2nk/9DgO4BI3BrVp/Ipq7jvXvBFfJbCdFXA4Ogl/
	 VAmynStpYlZ3jFWv+L7gj6CCHG8YRLzwLJi18IkBzBLacXo+V0en3NMAI7oNpoXYoO
	 BgJFeGNJBiGJhl9uxAwNTpPi5N3aK/Vi10MA/KNR1Q/EGDWoNZW7u37UTvPq3CoUie
	 zFX5UAL9P1eSsq4yene0VCj9rSR3M5dKqT5GpXY+I36LE+AYBt65MFMIMBVcqqKVqb
	 comsu6HoYYRew==
Date: Thu, 13 Aug 2026 23:18:23 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Cc: minios-devel@lists.xenproject.org, xen-devel@lists.xenproject.org
Subject: Re: [MINI-OS PATCH] build: don't add -lm -lpci -lz to APP_LDLIBS
Message-ID: <an40n9t6ut_3eNUe@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Juergen Gross <jgross@suse.com>, minios-devel@lists.xenproject.org,
	xen-devel@lists.xenproject.org
References: <20260813143536.3607406-1-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260813143536.3607406-1-jgross@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-bad1c0/1786655910-BDEC6034-117D67ED/0/0
X-purgate-type: clean
X-purgate-size: 967

Juergen Gross, le jeu. 13 août 2026 16:35:36 +0200, a ecrit:
> libm, libpci and libz are not always needed, so don't add them to
> APP_LDLIBS just because libc is selected.
> 
> In case they will be needed by someone, they should be added via a
> dedicated CONFIG option.
> 
> Note that none of the currently supported Xen stubdoms is using them.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Agreed,

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  Makefile | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index a64913a..7510d5d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -164,9 +164,6 @@ ifeq ($(CONFIG_LIBXENMANAGE),y)
>  APP_LDLIBS += -L$(MANAGE_PATH) -whole-archive -lxenmanage -no-whole-archive
>  LIBS += $(MANAGE_PATH)/libxenmanage.a
>  endif
> -APP_LDLIBS += -lpci
> -APP_LDLIBS += -lz
> -APP_LDLIBS += -lm
>  LDLIBS += -lc
>  endif
>  
> -- 
> 2.55.0
> 


From xen-devel-bounces@lists.xenproject.org Thu Aug 13 23:41:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Aug 2026 23:41:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390484.1630851 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuf2X-0005FZ-VT; Thu, 13 Aug 2026 23:40:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390484.1630851; Thu, 13 Aug 2026 23:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuf2X-0005FR-SY; Thu, 13 Aug 2026 23:40:49 +0000
Received: by outflank-mailman (input) for mailman id 1390484;
 Thu, 13 Aug 2026 21:27:45 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrewprecious388@gmail.com>) id 1wucxl-0002fz-1M
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 21:27:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wucxk-007fFh-1q
 for xen-devel@lists.xenproject.org; Thu, 13 Aug 2026 23:27:44 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a7e367b-2eae-0a2a0a5409dd-0a2a4507d592-32
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 23:27:44 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a7e36cf-b4ea-0a2a45070019-d155dd29d90f-3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 23:27:44 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47f71156e1aso122954f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 14:27:43 -0700 (PDT)
Received: from debian.debian ([102.213.48.6]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f2b1d90sm2411674f8f.22.2026.08.13.14.27.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 13 Aug 2026 14:27:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786656463; x=1787261263; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=1IsaaZEM5AbAGdu6Vn3gDX/VJhjYFIvgg6s6SuZB6TQ=;
        b=fnBtVyObovRfdQkrXPeOtEC616VfsEmXWTwepePeHCdiSZ8J0KTuWpZB6ZcgMUPzZ1
         ZIbtKctbDJQiGm6EoHDyby8J8/43gMtLMSbHDxpK9fmT/XhEofb7ufFHWok6jR3vDP61
         0xBM0OjDpihd3/UN+PXYFid/XDXAhDV0wrrjCM6Uzg67W6XnEyBZQvia8v200/mF8aaH
         FGpmMClGZ82UoBuBIngvtarxfqluBk/gUMFnSE5dUitbzNDHDZoiIRHb8j0Mnf68cfiS
         vgiJw4LzhSUgcOPyAFVKl4G2HtgTjixfgy4R6gp52DB4DrnrJtRsgPTLit0GKc1x8gl9
         ieNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786656463; x=1787261263;
        h=content-transfer-encoding:mime-version: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=1IsaaZEM5AbAGdu6Vn3gDX/VJhjYFIvgg6s6SuZB6TQ=;
        b=UNz9Unxvg1zTLxJFZ7uZp7Ro70516+6KEanlEPzwHkjD3CDCj7Y+FzAI6F0isvBybp
         VSqyrtm02huDtTbiuvtiBXferc8J8QlRu8Y+EAD3bXiXEtv2XCddH3sOYcE9X51xK9Ta
         Q5dQVmKBl06RSYGSWuqe/n2unXe7MFqvcoaDYnK35J8GksUP45GMmrCPWei+0EVvXM2N
         52fRICe7U9Nko8A4RrO4y2ycIJ4OvfsrDGRBWFnbi1bHDfEuiweiGWaBT9g+SH+BxILi
         B5Iy7DJOU624eYx4pgyDUCOXHi7Lox4emDrABTs9/6IKyicrkuizBHu8xvmw2osJikbJ
         Gj2g==
X-Gm-Message-State: AOJu0YzK9zxyAHw6ychx/9L7NPs8hZpKOHEpImVoqx/4EvE8hfhh7S2P
	iBz31DhR700E8vTJnHN273JwF0uklQeThMR7FEfKqu5qkvSLzYdmfD7UhcYlfa7eK6c=
X-Gm-Gg: AR+sD10X6mHVvHYEMP/0hszS+P1qbhd/4yvmQ40lSZRhoYCgH1sYLQitkbKT0KY7dqg
	cyjvkB3aOg649e6hmqu+dVeWZcObTGUCklPQiqASUebwBJscVI/Vlu/71XWpwiaLZsNwLKbrWtz
	MSiP4N5FdRGi3tB8vDwLmCeJN3NuVZPbt0CUj84mUdKc9vuN9M+GH0jpx6unE1PPvh0Nf6eeGAT
	M1n4WnG/Lkm6egrxrlFR53dyU4p/Np/OPvJ9AqhSJn5Jjl2pspx/P2Uhf+tiefDBMGluMADuFrS
	UwFxDeMJTxxXqOcVNo/MXUWyH2kxuU6vtRcHBu3AY0GfBHMovyKOeUM/yH0c/8eb3KGtdCjwHq/
	zkOBTy50Abj3JqwGAEMUz7E7nLwM35Lp8HECKGwlUc+hVmWVuqisYN5PTdvUMgTBTp+7EhL7jij
	OwHaefMBvQR0jUQ0EHB1if15spIkb1F+qgQ9d+uck3iba0D/Sws4WeWolHPgBpODJ4YjVMlNYpL
	byO2ss=
X-Received: by 2002:a05:6000:22c5:b0:481:3124:c71f with SMTP id ffacd0b85a97d-481607487bdmr1383300f8f.17.1786656463465;
        Thu, 13 Aug 2026 14:27:43 -0700 (PDT)
From: Andrew Mbugua <andrewprecious388@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: anthony.perard@vates.tech,
	Andrew Mbugua <andrewprecious388@gmail.com>
Subject: [XEN PATCH] tools/console/daemon: fix log_dir memory leak in xenconsoled
Date: Fri, 14 Aug 2026 00:27:23 +0300
Message-ID: <20260813212724.2607832-1-andrewprecious388@gmail.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786656464-36AD8AE4-C6653229/0/0
X-purgate-type: clean
X-purgate-size: 1709

Valgrind reports that 21 bytes are "still reachable" from the (XEN_LOG_DIR "/console") allocation:

HEAP SUMMARY:
    in use at exit: 21 bytes in 1 blocks
    total heap usage: 9 allocs, 8 frees, 4,799 bytes allocated

Since the dynamic memory allocation for the default log directory path happens before the process
forks into the background, the parent and intermediate processes exit during daemonize()
with the memory still reachable.

Move the strdup() allocation down below the daemonize() block. This ensures only the final
background daemon allocates the default path, matching the lifetime of the free(log_dir)
cleanup loop at the exit of main().

With this change, Valgrind reports a clean heap summary

HEAP SUMMARY:
    in use at exit: 0 bytes in 0 blocks
    total heap usage: 8 allocs, 8 frees, 4,778 bytes allocated

Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
---
 tools/console/daemon/main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c
index aac7233a48..9f81d73164 100644
--- a/tools/console/daemon/main.c
+++ b/tools/console/daemon/main.c
@@ -181,10 +181,6 @@ int main(int argc, char **argv)
 		}
 	}
 
-	if (!log_dir) {
-		log_dir = strdup(XEN_LOG_DIR "/console");
-	}
-
 	if (geteuid() != 0) {
 		fprintf(stderr, "%s requires root to run.\n", argv[0]);
 		exit(EPERM);
@@ -201,6 +197,10 @@ int main(int argc, char **argv)
 		daemonize(pidfile ? pidfile : XEN_RUN_DIR "/xenconsoled.pid");
 	}
 
+	if (!log_dir) {
+                log_dir = strdup(XEN_LOG_DIR "/console");
+        }
+
 	if (!xen_setup())
 		exit(1);
 
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 00:45:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 00:45:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390550.1630861 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wug38-0001Ui-PO; Fri, 14 Aug 2026 00:45:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390550.1630861; Fri, 14 Aug 2026 00:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wug38-0001Ua-L3; Fri, 14 Aug 2026 00:45:30 +0000
Received: by outflank-mailman (input) for mailman id 1390550;
 Fri, 14 Aug 2026 00:45:29 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@netscape.net>) id 1wug37-0001U3-43
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 00:45:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wug36-004Xuk-0e
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 02:45:28 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a7e6505-e002-0a2a0a5209dd-0a2a45039198-14
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 02:45:27 +0200
Received: from [98.137.65.206] (helo=sonic311-25.consmr.mail.gq1.yahoo.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@netscape.net>)
 id 6a7e6525-fae8-0a2a45030019-628941ce864d-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 02:45:26 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Aug 2026 00:45:24 +0000
Received: by hermes--production-bf1-54b5569bdc-bf8lf (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID c68ffe5c704d55fdb9e81073ff8d3cd9; 
 Fri, 14 Aug 2026 00:45:22 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=netscape.net header.i="@netscape.net" header.h="Date:From:Subject:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netscape.net; s=a2048; t=1786668324; bh=med8W4SJgsW4Ig9i60JVAUshGqMBQhKmKaNcqyw34Uo=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=GnFE0wEjl8TLFVgdgdoLeKo4SO8SFHLpLiLXXKgcblQoQD9GremCIya7ThPztxieROEqmd4UtQ1EFUkqnLnhCh+nI+95JJ7i15PnZej87iPJKtnhjoyt3wFFJJD+WyLhfBEA/th1Y+OahU2iP91zlHOW4ZFVvoK9L/v+yndUa3aQw1yqavtEw1mI3zuWkeh3lQb74IC/JkFZu0pDRMPipOEyUh2RqU9IapWQwBaBy4Rq87BgGPfZuzsmzpZ3WR0tnRJFszUL6o6WrjkyeQDsnngaV38poD88ceNnunnJhJi04XCIXn48dAG56AAuNehiuNagNQEy5MjczG9ibhg1ZQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786668324; bh=ty85poDP6eVDUAo7KTHE7uQndVo+Sjj+5dgt6tVZ+bm=; h=X-Sonic-MF:Date:From:Subject:To:From:Subject; b=JHZCRW/anWFB2RVfzWFTfq9Qj46suCFPalapPdjh81qyi8QyiOhkIrEITHUapbjvwfLHcshx9CtvsIgrgEK0hTVrhsU+X2j+RZ8CXjX8FvMI6wj+y2/50w7UVHVY5YYHBwC0mHhm5TW9SpaCw0JLI+7Vb4JH0VE58wyjvTaBfl8ifupX2LLZTHyw0lJne4FhGjfybjFepCzBG7XiHSz/ir9TRRP2/sFDbzfVSu17i/PBHuvg1gliUislk5PENaDfkd2US52JWHAR0Gbp7t9OcoGPWBhYEXWEMN4v+I+kbIyp3UVwkeIeYnj+yBxep97/CiQ+Y+lN0A6RFYwxtotz0w==
X-YMail-OSG: 477.2F0VM1lV8ulneowsKkjEQVFnxPmwkXHyZf5Ypm9eOiBCwIGgL15.UcLC2dt
 OkezSuUxQC2s3I6OjBo77emUL8qHYU0ZQSJzItaLDjfnja4crqonD1V4dovIf48.bSMEAxKixpQ4
 s7qYlAUkqlux643P682YBYo4O3.JyDr3i7aHN9ZrI3LOr.xAFrG3oA1azrQphlfUz7PuqaJmwXof
 jE0uCGwZFoLtCVcsHDqNfVnLIf46jr5GzC.Ri2EHyKb54v72BBRbUOmrsy0QG2u7vLGmgz3A8ZpB
 vDD5NCZ_20lCtI4TOlQfVelWi8RisEClBRMDS5wQ6P0xi48FCGce1cjr84lIYMcdli4bMx3b1fpZ
 D3YWHnLhQCj3sxmycqUKkshVtW0zpycDKXlO_VwP46.vsFEsU_arqYIWuUxsaZh7KdyyXf6zeaMc
 nnsXN1ZBEUA3QZKYKeCnuGat1DLNKCVH04fGPfFtcS.FaJ5qvittjsrLZYNa.D6iN1vdicQgNY2w
 JQ.1IDVr7TSB..jFT5LYGQUZu5pua6GPEfNqQDjGFjzlhFnnp74gpq3AiUeeIIXTK5V.VlK5P_NT
 1pQtfGvG4JukU3jdxrcsZWyUf_boRUC.nqmp0xmFUwpmX64yxA6N1NXUTmKRLyUfvKIUy6TrGag7
 GMb79hi_.FG4qbt0p7rMQKD3CUYnnIdGuYozR31kzXiifg6oUBevRkiBAHpLchRSim3_BrXriy9l
 8vaNEpzp5CqSUcwtWgzJ6SikxH.soILygMtLEX.RpsUKP_ya4.LTyrIiz3715Km8my0V23pRPun9
 pXLNEvqGx4GACxptAWvvWOfnG6JNk7dYweIhfWcRmGXQi0FjgT7mGhQYhTQPS7chbhUmng25kGdr
 owQu5Ey4x9aiTQcNYGhAFOUSOnPpC8D1q8d2RTQbTvGKj6mTp.KIR8GvZ9oQglVe7sZKdIrQOuBq
 LaM0BiwRfJqOcGPys5NJryKyARMD3bIN4ocmW48G7wMNBPK4MM1pCJ95IrVLm4mCEKBsZ9d3NELb
 BFvDGpDl_Ednda2ImSf2pnRDNN6a2Dzax_tojsqvrm4y3Y81hN3MleL892shG658VMUGjvpYeYX4
 V6uvjkwYUY3ZDiJGCvTkph2VZ53yZ1b4ghtafsQ.iigUw5zLhawGuD8ZUZbqzC9Ini0yI12L4u80
 Scj37U7MPvsxghVd.WThOH_Y3ddQWx86u7OK1G0iiW71TPVvxtsC9b00yW2ILqJNwNx_hDTUNmC0
 YoQYNIS2.3MvMfijJKuohu9R2hFmvG_UHL0bsPmfCi86BHdjN.vJTE.NEg4eEuGxWr6vXWZMxcAm
 kZhEczaeVrd5OmfrDRHcY4EuHk9wPSN319bBdh3OAx3JoBPGR2HrPRP7O.86gnkN2yUr3EyCSI6J
 bWgWBWLpXh6sDkMAAB3tMpZelrcf7R3C0Y2o6Dt8kILeQoWISqw.sBR5rUUUcXVbICGjPHCZSxIK
 BNDVtoycpCSYyJWf9qYGKc6OWSbrCCudm0z3nUrmJ8h05QrJtUhd7qAj1LVTeNctZhAnyZLIk_47
 V82en2.qs9n43gzm7Qj_lRUMn.w9k2zbNFhv_tGBGlDb6K7n9_IKjl1SX8JkGlnV5tLTBhjrP_dC
 WZNTLl7zkBOgwOyQSjlTpxAjborJhXI8xpeMqe2wxncqi6nw4aFn3RCG7xGATj.da7agYTV_i.s4
 qImf0mdwEUgyOoILpFXJRX5Y2uNbceW1hXOP5Wmm64j9OFOZS45Umg72W5IPZhr1NrmY2Z8yBGva
 K5HsDkMOEvL33JGD4oFDQ0S1hChjpR2Fpnq1px.krzt60kBxL8ScS3YfWm7LRWXTpiKAbGrlOne7
 oJBZisT2MQAWLjdr_Kq64QJJ8UormUn7Rr_7cF3cRHT0VeUWxPt7C5.vHALPm2R0Y06tbDa_18xs
 Nzes76xtrnfleyocMTvDwNIlrbM5xktSyrXmIlDtLJvXm8zpGbu7_IQYRJjz0Mb3P_6eW2ZnSecw
 dr.Vk2a_plcjIwvUBVGqY3zzsmtmjWi6AfpsM2YuV5pRvGAfoQInOGy.a_e7P7YvdbFWFwnVPvti
 cwowGa3rt0Zzehy0CdN6VRszJn_2C5Y9eSnjbLUhCfit6c8kw7Qk7_PlimrRkpbZB3H6W6oiw8Rn
 3A.pEnJp25vYMqwpTD7W0sIEkeoxADVeKXn_37w_Ausv2NrVGDX5rO6VcO7byz.5zqJXo9MPBx5S
 2ME.uNamyuOiuHG0FwoyVutcmufzGIAP7MuiZTlWDAoE-
X-Sonic-MF: <brchuckz@netscape.net>
X-Sonic-ID: 627afcf6-d3c6-44e4-93b4-0916a4facba5
Message-ID: <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
Date: Thu, 13 Aug 2026 20:45:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Chuck Zmudzinski <brchuckz@netscape.net>
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
Content-Language: en-US
In-Reply-To: <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 24570
X-purgate-ID: tlsNG-33051d/1786668327-6F2C84E9-D74C44AF/0/0
X-purgate-type: clean
X-purgate-size: 25176

On 8/13/2026 6:35 AM, Jan Beulich wrote:
> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>> -- snip --
>> To address this problem, this patch implements support for
>> Intel IGD devices with an extended VBT and OpRegion version 2
>> and higher which is required for most modern Intel IGD devices.
> 
> First of all: Where's the spec of all of this?

Hi Jan,

Thank you for your review.

Well, your first question is quite provocative. Certainly more
social/legal than technical.

I presume by "all this" you mean code in this patch such as:

#define IGD_OPREGION_RVDA 0x3ba
#define IGD_OPREGION_RVDS 0x3c2
#define IGD_OPREGION_VERSION 0x16

which defines the offsets of the rvda, rvds, and version fields from
the base address of the Intel OpRegion.

Also, I presume that "all this" includes the meaning of the 8-byte
rvda value, the meaning of the 4-byte rvds value, and the meaning of
the 2-byte version value.

So my answer is as follows:

I do not have access to the official spec that defines "all this" but
I do have access, as does the general public, to the Linux kernel's
implementation of support for the Intel IGD from many sources such as
git.kernel.org. The Linux kernel has enough accurate information about
the spec of "all this" to provide very good support for the Intel IGD
on bare metal.

To elaborate a bit more, the spec of "all this" can be derived from the
Linux kernel code that supports the Intel IGD. It would certainly be better
to have the official spec from Intel, but alas, as far as I can tell, it
is a proprietary spec that is most likely only available to Intel's OEM
customers who need the spec to write the firmware for these devices. Of
course we could ask Intel for the spec because we write firmware for these
Intel IGD devices too. How do you think that would go? You, as the maintainer
of Xen firmware that (at least implicitly in xl.cfg man pages, etc.) claims
to support the Intel IGD, certainly have the right to ask them for the spec.
Me, as a lowly customer/user of a handful of their devices at most, probably
has less of a right to ask them for the spec.

The situation here is analogous to Xen support for the Processor Properties
Topology Table referenced in a commit that you Acked [1] just a few weeks
ago. I presume you Acked that commit not because it is based on an official,
open spec of the Processor Properties Topology Table that is available to
the public, but because it is based on Linux kernel code that supports
the Processor Properties Topology Table.

[1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=99794c8a8ff8b1d277c09d4736384fd5bb94f2d6

So it was acceptable to use a spec of the Processor Properties Topology
Table derived from Linux kernel code as the basis for a commit to the Xen
codebase just a few weeks ago. Why would it not also be acceptable to use
an updated spec for the Intel IGD OpRegion and VBT derived from Linux kernel
code in the code for tools/hvmloader in the Xen codebase that already
has code that is based on the spec for older versions of the Intel IGD
OpRegion and VBT?

> 
>> ---
>>[...]
>> 
>>  tools/firmware/hvmloader/Makefile         |   1 +
>>  tools/firmware/hvmloader/config.h         |  15 +-
>>  tools/firmware/hvmloader/e820.c           |   4 +-
>>  tools/firmware/hvmloader/intel_opregion.c | 297 ++++++++++++++++++++++
> 
> Nit: Please use dashes in favor of underscores in new files' names.

Ok.

> 
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -35,6 +35,7 @@ OBJS += smp.o cacheattr.o xenbus.o vnuma.o
>>  OBJS += e820.o pci.o pir.o ctype.o
>>  OBJS += hvm_param.o
>>  OBJS += ovmf.o seabios.o
>> +OBJS += intel_opregion.o
> 
> While this list isn't well sorted, I think your addition still wants to move
> up by a line.

Ok.

> 
>> --- a/tools/firmware/hvmloader/config.h
>> +++ b/tools/firmware/hvmloader/config.h
>> -- snip -- 
>>  #define PAGE_SHIFT 12
>>  #define PAGE_SIZE  (1ul << PAGE_SHIFT)
>> +#define tools/hvmloader/pci.c3
>> +#define IGD_OPREGION_SIZE ((IGD_OPREGION_PAGES - 1) << PAGE_SHIFT)
> 
> This is odd, and hence wants a comment.

Yes, I could add a comment, probably a long one, to explain this
oddity. It is a problem of backward compatibility where we have a
definition, IGD_OPREGION_PAGES, that is currently set to 3 both here
in hvmloader and in the Qemu DM, but should be 2 because the OpRegion
size is really exactly two pages but the current implementation set it
to 3 because the host OpRegion is not always aligned on a 4k page
boundary so three pages are needed to map the entire host OpRegion to
the guest. I could re-write the patch setting IGD_OPREGION_PAGES to 2
and avoid a comment here, but that would complicate the logic of how
igd_opregion_e820_pages is calculated and probably introduce the need
for comments in other places. 

I am open to suggestions about how best to handle the backward compatibility
problem and the problem of ensuring compatibility between hvmloader support
for Intel IGD passthrough and DM support for that same feature. For now,
however, I am trying to keep what is applicable to the current implementation,
and this odd value of 3 for IGD_OPREGION_PAGES is one of those things
I am keeping for backward compatibility.

Perhaps the best solution would be to presume there are so few current
users of this feature that we do not need to worry about backward
compatibility and breaking existing setups. I say this because the code
here in hvmloader and in Qemu upstream to support Intel IGD passthrough
is very badly bit rotten and I doubt there are very many, if any, working
implementations currently in the wild based on unpatched vanilla Xen/Qemu
upstream code, particularly with more modern Intel IGD devices and more
recent versions of Qemu. If you give your blessing, then I can rework the
patch without worrying so much about backward compatibility and about what
happens when a guest is configured with a version of hvmloader that has
this patch and a version of the DM that lacks the compatible patch, and vice
versa, that is, when hvmloader lacks support instead of the DM lacking
support. Then we could completely remove this oddity of setting
IGD_OPREGION_PAGES to 3 in the current implementation in both hvmloader
and the Qemu DM as well as many other oddities that result from the current
implementation.

> 
>> +#define IGD_OPREGION_RVDA 0x3ba
>> +#define IGD_OPREGION_RVDS 0x3c2
>> +#define IGD_OPREGION_VERSION 0x16
>> +#define IGD_OPREGION_MASK 0xfff
>> +#define IGD_OPREGION2_SUPPORT_MASK 0x1
>> +#define IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
>> +#define IGD_VBT_SIGNATURE "$VBT"
>> +extern unsigned long igd_opregion_pgbase;
>> +extern uint32_t igd_opregion_e820_pages;
>> +void intel_opregion_setup(uint32_t vga_devfn);
> 
> Blank lines please ahead of the new #define-s you add and between those new
> #define-s and the new decls.
> 
> For igd_opregion_e820_pages I further cannot spot any use which would justify
> the use of a fixed-width type; unsigned int will do, and will then be in line
> with ./CODING_STYLE.

Ok I will pay more attention to CODING_STYLE. I know that libxl
has a specific CODING_STYLE document. Is there a specific one
for hvmloader? I do not see one in the tools/firmware/hvmloader
directory. I assume the one that matters for hvmloader is the
one at the top level of the Xen code source tree, not the libxl one.

> 
>> --- a/tools/firmware/hvmloader/e820.c
>> +++ b/tools/firmware/hvmloader/e820.c
>> @@ -243,11 +243,11 @@ int build_e820_table(struct e820entry *e820,
>>          nr++;
>>  
>>          e820[nr].addr = igd_opregion_base;
>> -        e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE;
>> +        e820[nr].size = igd_opregion_e820_pages * PAGE_SIZE;
>>          e820[nr].type = E820_NVS;
>>          nr++;
>>  
>> -        e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE;
>> +        e820[nr].addr = igd_opregion_base + igd_opregion_e820_pages * PAGE_SIZE;
> 
> Are these new multiplications at risk of overflowing? I.e. how many pages can
> there be in an extreme case?

We are allocating down, so as igd_opregion_e820_pages grows, igd_opregion_base
will shrink. The danger is that igd_opregion_base will go below the minimum
possible value that is compatible with our memory map. I could add a check for
that. I think our memory map allows for tens if not hundreds of pages in the
region where the OpRegion and VBT are located, and typically the OpRegion + VBT
is only about 4 or 5 pages. It should probably be a BUG() if somehow we detected
a VBT whose size was large enough to cause this problem.

> 
>> --- /dev/null
>> +++ b/tools/firmware/hvmloader/intel_opregion.c
>> @@ -0,0 +1,297 @@
>> +/*
>> + * intel_opregion.c: HVM Intel OpRegion setup.
>> + *
>> + * Leendert van Doorn, leendert@watson.ibm.com
>> + * Copyright (c) 2005, International Business Machines Corporation.
>> + *
>> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
> 
> What do these cover?

I am considering this new file to be a modified/derived version of
tools/hvmloader/pci.c, so if I understand correctly this file needs
to retain the copyright information of tools/hvmloader/pci.c. At the
very least, the #include statements at the top of this new file which
are from tools/hvmloader/pci.c are covered by these copyrights. I also
consider the statements that are moved from tools/hvmloader/pci.c to
this new file to be covered by these copyrights. IANAL, so to be safe,
I include these copyrights even though the covered code is relatively
small compared to the rest of the file.

> 
>> + * Copyright (c) 2026, Charles Zmudzinski.
>> + *  -- snip --
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program; If not, see <http://www.gnu.org/licenses/>.
>> + */
> 
> Please use an SPDX line instead in new files.

OK.

> 
>> +#include "util.h"
>> +#include "config.h"
>> +#include "pci_regs.h"
>> +
>> +unsigned long igd_opregion_pgbase = 0;
>> +uint32_t igd_opregion_e820_pages = IGD_OPREGION_PAGES;
>> +
>> +static bool verify_opregion(const uint32_t addr)
>> +{
>> +    const char *opregion_signature = IGD_OPREGION_SIGNATURE;
>> +    if ( memcmp((const void *)addr, (const void *)opregion_signature, 16) )
>> +        return false;
>> +    return true;
>> +}
> 
> Style: Blank line please between declaration(s) and statement(s) as well as
> ahead of the main "return" of a function. There further isn't really a need
> for an if() or two return statements here. Also please avoid casts wherever
> possible. Finally, the local variable isn't really needed here either - the
> string literal can be passed directly to memcmp(). All of this helps
> readability as well.

OK.

> 
>> +static bool verify_vbt(const uint32_t addr)
>> +{
>> +    const char *vbt_signature = IGD_VBT_SIGNATURE;
>> +    if ( memcmp((const void *)addr, (const void *)vbt_signature, 4) )
>> +        return false;
>> +    return true;
>> +}
> 
> Same comments here, obviously (and potentially elsewhere).

OK.

> 
>> +void intel_opregion_setup(uint32_t vga_devfn)
>> +{
>> +    uint32_t igd_guest_opregion;
>> +    uint32_t pages_needed; /* for OpRegion + VBT */
> 
> The former probably wants to be fixed-width, but for the latter I see no need.

OK.

> 
>> +    void *opregion_scratch;
>> +    void *vbt_scratch;
>> +    void *vbt_source;
>> +    /*
>> +     * absolute value in the host/guest except
>> +     * as noted in the comments
>> +     */
> 
> Nit: Comment style (see ./CODING_STYLE).

OK.

> 
>> +    static unsigned long rvda_host;
>> +    static unsigned long rvda_guest;
> 
> Why static? The function can't be called more than once, if I'm not mistaken.

I think you are right that we only do the setup once so I will
drop static here. I still think if I drop static I will want to
initialize these to zero later, because (correct me if I am wrong)
only static variables are initialized to zero if not explicitly
initialized, and without either static or an initialized value,
these would be initialized to some undetermined random value
until explicitly set to the desired initial value. Of the two,
I think that the more important one to intitialize to zero is
rvda_host, because I use an initial value of zero for that variable
to test for the case when we do not need extended VBT support.

> 
>> +    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
>> +    /*
>> +     * Tentative value for the number of pages to reserve
>> +     * in the E820 map for the OpRegion and VBT.
>> +     *
>> +     * This will be the final value for the E820 map if
>> +     * the device model lacks support for OpRegion 2 or
>> +     * if the host OpRegion version is < 2 or if we never
>> +     * allocate more pages in the E820 map for the VBT.
>> +     */
>> +    igd_opregion_e820_pages = IGD_OPREGION_PAGES;
>> +
>> +    /*
>> +     * Read the value the device model is initialized with.
>> +     * If the device model supports OpRegion 2, it will
>> +     * return the host IGD OpRegion address. If not, it
>> +     * will return 0. If the device model does not support
>> +     * OpRegion 2, the device model expects us to give it
>> +     * the address to which it will map the OpRegion in the
>> +     * guest and then expects us to do nothing more to setup
>> +     * the OpRegion, so that is all we will do in that case.
>> +     */
> 
> Hmm, exposing the host opregion to a guest certainly feels like an issue.

Well, that is how it is now. I am only retaining it to maintain backward
compatiblily with DM versions that do not support the extended VBT and
OpRegion 2+. My previous comment about backward compatibilty and DM
compatibility also applies here. If we don't worry about that, we can do
away with any cases where we are permanently mapping the host opregion to
the guest and implement this new approach of always exposing a copy of
the OpRegion and VBT to the guest instead.

> 
>> +    const uint32_t igd_host_opregion = pci_readl(vga_devfn,
>> +                                                 PCI_INTEL_OPREGION);
>> +    if ( !igd_host_opregion ) {
> 
> Nit (style) Brace placement (throughout).

Ok. I see this is not the proper coding style.

> 
>> +        printf("device model lacks extended VBT "
>> +               "support. Continuing with legacy support only\n");
> 
> This message can easily confuse / worry people. (If it was to be kept, it
> would also need style adjustment.)

I think some message is needed here to indicate the incompatibility of
versions of the DM that do not support the extended VBT with versions
of hvmloader that do, especially if we are not going to worry as much
about the backward compatibility / DM compatibility problem I mentioned
multiple times in previous comments above.

This message could encourage upgrading the DM to a version that supports
the extended VBT instead of just giving this scary notification.

Also, I will more carefully read CODING_STYLE and try to fix all those
issues you have pointed out (and any others I might find).

> 
>> +        /*
>> +         * Write the the OpRegion offset to give the OpRegion
>> +         * address to the device model. The device model will trap
>> +         * and map the OpRegion at the give address.
>> +         */
>> +        pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>> +                   igd_opregion_pgbase << PAGE_SHIFT);
>> +        return;
>> +    } else {
> 
> No need for "else" after an unconditional "return".

Ok.

> 
>> +        printf("host OpRegion address: 0x%x\n",
> 
> The shorter %#x please (also elsewhere).

Ok.

> 
>> +               igd_host_opregion);
>> +    }
>> +
>> +    const uint32_t igd_host_opregion_page_offset =
>> +                   igd_host_opregion & IGD_OPREGION_MASK;
> 
> I think like in the hypervisor we don't want to mix declarations and
> statements just yet.

The only way I could separate the declaration from the statement would be
to drop the const modifier because if I do:

    const uint32_t igd_host_opregion_page_offset;
...
    igd_host_opregion_page_offset = igd_host_opregion &
                                    IGD_OPREGION_MASK;

The compiler will report an error. If I drop the const modifier from
the declaration, the compiler will not report an error but I lose the
protection the compiler gives me from making mistakes by modifying a
variable's value that should be constant.

I am not a C guru but some research indicates that while it is legal in
C to declare a variable with the const modifier without also assigning
it a value at the same time with a statement, it is not recommended to
do this because the variable will be initialized with some undefined
random value that cannot be changed because we used the const modifier
in the declaration. This implies strict enforcemnt of the rule "we
don't mix declarations and statements" results also in the corollary
rule "we never use the const modifier for variables in C."

> 
>> +    igd_guest_opregion = (igd_opregion_pgbase << PAGE_SHIFT) |
>> +                          igd_host_opregion_page_offset;
>> +
>> +    /*
>> +     * We know at this point the device model supports
>> +     * OpRegion 2.
>> +     *
>> +     * Indicate to the device model that we support
>> +     * OpRegion 2 by setting the least significant bit
>> +     * of the address we give to the device model.
>> +     * The device model will notice this bit set and
>> +     * respond appropriately to our writes to the
>> +     * register where the OpRegion address is stored.
>> +     */
> 
> Specifically noticeable here: Please make better use of line length in
> long(ish) comments.

Ok.

> 
>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>> +                IGD_OPREGION2_SUPPORT_MASK);
> 
> This looks to imply qemu is the only possible device model.

Yeah, this is an issue. Other device models that intend to support
the Intel IGD with hvmloader will also have to be compatible with this.
It would be easier if we did not have to worry about backward
compatibility and supporting what we had in the codebase for many years
in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
in that case. Instead, we would just completely deprecate all previous
implementations of the Intel IGD passthrough feature in both hvmloader and
the Qemu DM as unsupported. So my previous comments about backward
compatibility apply here again.

> 
>> +    printf("guest OpRegion tentative "
>> +           "address: 0x%x\n", igd_guest_opregion);
>> +
>> +    if ( !verify_opregion(igd_guest_opregion) ) {
>> +        printf("error: IGD OpRegion signature "
>> +               "not found.\n");
> 
> No full stop in messages please.

Would it be OK to just get rid of the error message here?

> 
>> +        BUG();
>> +    }
>> +   --snip --
>> +        rvda_host = 0;
>> +    }
>> +    const uint32_t rvda_host_page_offset = rvda_host &
>> +                                           IGD_OPREGION_MASK;
> 
> Why host_page_offset here when ...
> 
>> +    const uint32_t rvds = *(uint32_t *)(opregion_scratch +
>> +                                        IGD_OPREGION_RVDS);
>> +    const uint32_t rvds_page_offset = rvds & IGD_OPREGION_MASK;
> 
> ... it's just page_offset here, and when further you use it below to set
> rvda_guest?

The size of the VBT, rvds, is the same on both host and guest, so we do not
need to specify host or guest, but the base address of the VBT, rvda, is
not the same on the guest as it is on the host, so we need to specify which
one for rvda. I can change this to rvds_host_page_offset because it is
not wrong, but it might be confusing because I use that value later on
for computations involving the guest also.

Actually, I only use rvds_page_offset below to help decide whether or not to
retain the host OpRegion page offset in the guest. I don't know if this is
necessary, though, and I could test without retaining the same page offset in
the guest and always place the both the OpRegion and the VBT on a page
boundary in the guest (if I place the OpRegion on a page boundary and
also always place the VBT contiguous after the OpRegion, the VBT will
always be placed exactly two pages after the base of the OpRegion and thus
also on a page boundary). All the devices I test have enough room to retain
the page offset of the host in the guest without requiring allocation of
an extra page, so if there are regressions I will notice them in my testing.
If always placing OpRegion and VBT on a page boundary works with no regressions,
then I could completely remove rvds_page_offset from the code. I will still
need rvda_host_page_offset though, because it is needed to get the exact
location of the VBT in the guest when the DM temporarily maps the host VBT
to the guest.

> 
>> +    printf("VBT size: 0x%x\n", rvds);
>> +
>> +    if ( !rvds || !rvda_host ) {
>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>> +        rvda_host = 0;
>> +    }
>> +    /*
>> +     * Write rvda_host as 2 successive 32-bit values
>> +     * to communicate location of the VBT to the device
>> +     * model. If rvda_host is not 0, The device model
>> +     * unmaps the OpRegion and eventually maps the VBT
>> +     * after we also write the guest address where the
>> +     * VBT will be mapped.
>> +     *
>> +     * If we send rvda_host = 0 to the device model, it
>> +     * will assume we do not need OpRegion 2 support and
>> +     * it will not unmap the OpRegion.
>> +     */
>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>> +               (uint32_t)(rvda_host & 0xfffffffful));
>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>> +               (uint32_t)rvda_host_upper_32);
> 
> Why would you need to communicate a host property to the DM?

The DM cannot access the host rvda value because it is only accessible
from the host kernel, and the DM is only a user-space process on the host.
The KVM/vfio solution is to have the kernel vfio driver provide rvda to
Qemu, and I think it would be possible for the xen-pciback kernel driver
to also expose rvda to the DM, but that would likely require patches to
the kernel xen-pciback driver and probably also to libxl or other toolstack
which uses QMP to plug the Xen PCI passthrough devices into the PCI bus
provided by the DM. This solution avoids needing to touch libxl and kernel
drivers.

> 
>> +    /* In this case, we use the mapped OpRegion */
>> +    if ( !rvda_host )
>> +        return;
>> +
>> +    /*
>> +     * Update the number of pages the device model
>> +     * needs to map for us to get a copy of the VBT.
>> +     *
>> +     * N.B.: Here, igd_opregion_pgbase is really the page
>> +     * base of the location where the device model will
>> +     * map the VBT.
>> +     */
>> +    uint32_t vbt_pages_needed = rvds >> PAGE_SHIFT;
>> +    if ( rvds & IGD_OPREGION_MASK )
>> +        vbt_pages_needed++;
>> +    if ( vbt_pages_needed > igd_opregion_e820_pages ) {
>> +        igd_opregion_pgbase = mem_hole_alloc
>> +                              (vbt_pages_needed - igd_opregion_e820_pages);
> 
> Nit: Indentation.

Ok. It should always be a multiple of four spaces, I presume. I admit I did
not check that.

> 
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -43,7 +43,6 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>>  #define BAR_RELOC_THRESH GB(1)
>>  
>>  enum virtual_vga virtual_vga = VGA_none;
>> -unsigned long igd_opregion_pgbase = 0;
>>  
>>  /* Check if the specified range conflicts with any reserved device memory. */
>>  static bool check_overlap_all(uint64_t start, uint64_t size)
>> @@ -190,14 +189,7 @@ void pci_setup(void)
>>                  virtual_vga = VGA_pt;
>>                  if ( vendor_id == 0x8086 )
>>                  {
>> -                    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
>> -                    /*
>> -                     * Write the the OpRegion offset to give the opregion
>> -                     * address to the device model. The device model will trap 
>> -                     * and map the OpRegion at the give address.
>> -                     */
>> -                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>> -                               igd_opregion_pgbase << PAGE_SHIFT);
>> +                    intel_opregion_setup(vga_devfn);
>>                  }
> 
> With this preferably also drop the figure braces.

Ok.

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 01:02:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 01:02:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390564.1630872 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wugJW-0004tO-D5; Fri, 14 Aug 2026 01:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390564.1630872; Fri, 14 Aug 2026 01:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wugJW-0004sT-9l; Fri, 14 Aug 2026 01:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1390564;
 Fri, 14 Aug 2026 01:02:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wugJV-0004qV-9o
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 01:02:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wugJU-004ZR0-7S
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 03:02:24 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e6917-e002-0a2a0a5209dd-0a2a4506d2f8-20
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 03:02:24 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e691e-195a-0a2a45060019-94a38ff1c354-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 03:02:23 +0200
Received: from pps.filterd (m0367127.ppops.net [127.0.0.1])
 by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67E0ND46118465
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 01:02:22 GMT
Received: from byapr05cu005.outbound.protection.outlook.com
 (mail-westusazon11010044.outbound.protection.outlook.com [52.101.85.44])
 by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4g1nf99pc2-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 01:02:21 +0000 (GMT)
Received: from SJ0PR13CA0234.namprd13.prod.outlook.com (2603:10b6:a03:2c1::29)
 by PH7PR16MB6259.namprd16.prod.outlook.com (2603:10b6:510:314::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.15; Fri, 14 Aug
 2026 01:02:18 +0000
Received: from SJ5PEPF00000205.namprd05.prod.outlook.com
 (2603:10b6:a03:2c1:cafe::35) by SJ0PR13CA0234.outlook.office365.com
 (2603:10b6:a03:2c1::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3 via Frontend Transport; Fri, 14
 Aug 2026 01:02:18 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 SJ5PEPF00000205.mail.protection.outlook.com (10.167.244.38) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Fri, 14 Aug 2026 01:02:18 +0000
Received: from pps.filterd (m0426317.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67E0VKjP1381261
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 21:02:17 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [34.209.42.160])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkhrpbkc-9
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 21:02:17 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id ugJKwnavi6i5qugJLwgwSn; Fri, 14 Aug 2026 01:02:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=ym3
	9jgrPTUF3kll+dsbU0hDpU2DP9K6eoXmXHXDMKrM=; b=GiQDohpLbeWo7qJtChG
	/iwwWXumqy3FF2m+y7sXE45TI5dnipPTRpcb9I5p0K4zoDretLFbrqOBpjPkIM8h
	M3JpTH6AnFhCIxbJGPAiqilFyOSMXbCyY0/qfmAaU/DhrYk9VuQSqrzzeKWrsXNk
	rPHVnkOMtvX3psUDC9F6Ukka7kNDQPDmvea5/y76bj56bD+Xt8BSENk3vktksH2u
	VYsJ573CfUsxqpI1VDGiYLAw6oe8yrVbXXgvzxoLs7DZlJXal3GDfqMMfisHUOow
	6Flm2MTudtLDWBwBVtYJXiekTokHcZGVpEAuWUQTPr3n3BI9TYkCD9E+zYeKLkGA
	Euw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F7QyzzZYvcv8G6E666bR9mHjsXFEpZ/SUdEVaLl7bmfUEXMhOrm/yvvGOU0RCEeDJkgSLpOfynasyUWEv5BuUzdGlCRLP/Bc9+9wpXjPySFVxwL6/3Xl6yx53jhIoP9KWJmIQ4eY2r2LKbJrwukZUn6ihZL2d4NWnkCb3s4v+m2+mfIhomJR1WuMEnB17dyJW9YHk4lYKh45LP9aGmJVz6Tn02BHMIRSc3NcWGCR9raTs+n3rikwfA5/ShDyYdJNC6msjiYFVxVVlKGSGMjtWYZoLwE0GdK0keRXQGZ84lUTrgR5/S8xevebxLuHxxn8s4DQUHf9UbbPeJ5PJ11rcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ym39jgrPTUF3kll+dsbU0hDpU2DP9K6eoXmXHXDMKrM=;
 b=RNftpO05V+1wzyFUFTzco7Dy90IhFoiwLFTUlHSOy5Fo4cBt3bhD94ELUhQqplLNH7ypF0AoMCl+DVd1dqBLI9q4Hw8cuUPRMhKQmin4f3sAgZ9JY36LxveyO+kgRAnqq0/Ab9O54HGdbsJ6ITiOQr55xGprsY+7S5WLwdV0Wt+vKIK5h7NvWb30IHv+PEQaEl4IGSC/S4hy2L8/PG++dGV9KD3jWmKWJo4nkjFGyz8Z/kI6/3FGFvPah+d1j5lD256L6XxWFjwL0nv29XcpesXubxBJKffJTVxQxVMFQK03J0xrIWDrSw9uL9KuDWIxQ//dpy64Raqp18RqiLJopg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ym39jgrPTUF3kll+dsbU0hDpU2DP9K6eoXmXHXDMKrM=;
 b=ISkchdlzmH/prhT7qig7nMjL4N4uZFDsYHpCSt5K9CedHVFY1INOFvvjZ8EcuVtPLfn8bB+MSoPEy1O8yVWBZ9LQNgSEfiqhoRPrkNnoMwQHZOvVLHgNsxclNs2IxslgTr5ljvWkRYoqjckZz3L28f9QaDtVVSpO+IyVyfZSJM4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:in-reply-to:message-id:mime-version:references:subject:to; s=
	ppserprodsaar; bh=ym39jgrPTUF3kll+dsbU0hDpU2DP9K6eoXmXHXDMKrM=; b=
	ojNv3p3+MRGKNnFDm1zuRVyvyQ7RcQNonWRhbMhWxVhCX00LP7SbvKJMc3zB+kH5
	narKWxpH30j1IHgexeCho5feq86712z6cT4WRlAdqcjYCTKU4JZUL7P6r4R2NJJK
	rhNyPFYtTFYjXNo2x1/E1237l59YOGotIOZVCTl7BGLcVdX1DI3b8R0BSWqs0jD2
	ACEx7GgdACMpx8YYapjh7RyVhlC6kQSJsiKGSIRdvKAeuQ3nSzkWsXSDpLz71jUX
	Y8n8AgoZ6uGzZjEvXqHEnykF1D84CVJFIqivx2NlzT+M+w+TPVbDoZJqgPtPFk7X
	BUdJ07tNkQSkP8BoWGha1Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=ppfserpocford; bh=ym39jgr
	PTUF3kll+dsbU0hDpU2DP9K6eoXmXHXDMKrM=; b=BLdsi9d/zod9DRRJ+gHWOqX
	l170JyojyB3ZPdgwN2OF9WYeVHqSy2T8cTlGvB8aUz8gT1eAxDjL1r528g3KrQMh
	K5mNeiuqXQA37wg5adlR5GhR3tzfBiMfAz55TfJijmqHs0PCM7StmDqYatTPbHy1
	Cd2RL1y7K/nYHUrQcDfos1RgGGVRrTL/kiAdwBgOc6yz1nDvmshcHYb9tWuAV30L
	+2k3Aw1X0KVvadRVskQUvora8jitMKlHnxUHpVe9KtLcuvM6s4aEQ30X+CAGc1Xw
	RwBF7mLR1bKB/24+aYBDEzoZGuxv7RPMvnOJtpawIWVJAayr4z9KguzKdS7/6Kg=
	=
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: ugJKwnavi6i5qugJLwgwSn
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v6 2/2] xen/common: move version printout under '?' keyhandler
Date: Thu, 13 Aug 2026 18:02:06 -0700
Message-ID: <20260814010206.1321724-3-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260814010206.1321724-1-dmukhin@ford.com>
References: <20260814010206.1321724-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_07,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 spamscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 bulkscore=0
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608140006
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF00000205:EE_|PH7PR16MB6259:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: c672446f-1f50-49f2-6e39-08def99faffa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|23010399003|36860700016|22082099003|18002099003|56012099006|11063799006|10067099003;
X-Microsoft-Antispam-Message-Info:
	2EhhgzMCvYMXlMs9GiwOLGQ751EHjVEfs7I7X9O4AXt5flpQG7zJcjf2ZG4LwoujLcABHhsLAfP82BGhZRhidN8y4lwkRoV71p1q2Fph3njJHvAyt+w58o0JRhEF/4Sw9MtRNnnkNsF6501gzqjL7sOUzNStP1hYiPIMxGPD6ryGjOswrCgQg8Gq9VGUDMgtfbFur8dH2w6QYGsNtqFGm5jVbI01rJvY/QVRDbEjWC2whO2He2kiJsUHU187OuF5zzn2vI47htBeswGfcWHtl3+X+cpbN5456v2EHBZYhFlwm2HaHJCJFvIscLOnWT5Er+Q36h1XyAssdjbQzQOdbVFbnzscZT+8XqU1fdjyRAJGDNZoTPGQf6imzKfGbv0Id8CWikYzaiGQE6UWZcqvCAhCptKNb2jN+UMbyp9x0fks97F/ip5vb32ZQYdIpntj8tHOUxLyBpYo+jNlU+2r1lJLK7M859HX7NSixNYJNkPXNaqIjuE9ULYeqM2lKmm+aT9nbJ8Yhiw5X0Rmu4T8aEDN6s+07LLDIQ1ZP5xSsl0wxpHPArUttfd74zUU8XGKnqAJpfGYsAcng5mE43HN92bjPLJ7LY9qFLWTVFrDEXo+LPoWGW9mz7Rq0JPXrabQpnTNP8/smJRz9EFtyCm6gABB2uqeulrBevy4ulUEJObY55DsJ1vKUoIPKkH8p7o7i361CAuE9hwy+Avnkm2sOA==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(23010399003)(36860700016)(22082099003)(18002099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	HGWb687IB+PiK9MICnz+iN3RI5PQjPAny4gvc16W0sYA/7S28z6445BcH+Dphnl/PnWKziAGjGhPbrlCeWx3SvMrolbNhkhowko7jLmYXqKUJ28SPVLCYvJUU8J0N42zKbx4npxTG6Wd7IG7jynei8hlNe0J94Oz4rOyB60ZesLptikGbiJa3fCuXyxBSwUEbmngYz8d3SRAreVHgLgjWppbxcXIWpqfrDtM5iPEx0dLzXA4Vhcq0MnDkZ4FJ8+xmDAyU0cwzoegIo/wrIzcmPwHg3v00rRvx+68WGQUQmYCRghWYQj0HTmXeAV5niT6gvg478C7egKc/KOusapvjpBdr8DMGA0iFH4S3MlP8tyvbbAMqfJpW19O/0Xt2asO1oGrwaY11a1yRFkPUwf7vI9o59AQNKfxgoMid4AIUFWgQAnu8qmPZh9608COCzpi
X-Exchange-RoutingPolicyChecked:
	HIlJPFgy+9cancdKFvLPoR/Jcz1g48kX2XdefmgMITuRZNt2PYPQRI+X4ApySHGZ/DfvfxodggvKfVugJrZsOO7cNGIHOQy1bKN295hRcDAY4gvhYpPaEn+w4KZxKA7In6Rcb5R/Jwwg0MJzl4A3XThzaPH9RIEEn/quKVHRELhu9CTInxp8GUcEqWQ8s3Myhw1zHQOF7y8d7eSe93SWtlRWlyFEm8f9P/XlfRIpvFNlVGhpVtUcNz+sd+q1NeBOz5HdqTRQBoML3qC9fJm6Vf7yzfpnQHAUEabgPN5K9FfY6xSY7XnbPZyoha93j+WDsUnh5dDYGHsLRlerQka15w==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	7Lvhspx2SBuzD1lTmZpxxqClDXI67H27wQgMp10G+Lt9/WAsAop2moQ7yfeyPr0s0sbG+40vw4pia30IBjZH+SxV4rAJ+CZg1/Hunz+iZ9RzJeAIQWIXqeNOG0aKajeSp6K45Wqwj5AWer41Y/SkFSfPYYgFixv2/d4Q55j3dHxGovlqxSTo4H41tH7fWssZhcU7TUabaH0OGUfyp6a04wn6iy9TlAP136NO6bWqk8f1qtzOh9i3jyWz3QgzwtrfsYVwYrTw6djBpez71UrJVh3HKEOi+IYJOHCCKXTkwtiEmal8RI2S5ql/tW3eJ+RK/VhPhej2yDN6iEXSa+FYr1szw99tQ8H5ZOX4TpVZkbTww6/o/na+QXMu/Au4kh6921ZwscyMVjzCz97GwtPCqDd5fOIsfuPclBedDsHAO9AzUwqWXT70fySmaecaB8K0zRGCaAe2P3slfWQ8dg0IRWtoTeBSsRCug+azq65RMkEbeg1xBr5TX6h9Q389wOP4yV5Dp0EDte87bWXi6QKm9oAbnFCWJ7mGaxaJ1cJbpzbjMkiyQEODd6tF/dyUFTTUFzvBgeArLctf0NDmd4+Jb5tKRVPMl8wbCS850nOpIZYZg+E3jDxVWstlWAF4nnwfTk0i7f+XB5YVKjB5MkRSuA==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2026 01:02:18.0197
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c672446f-1f50-49f2-6e39-08def99faffa
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF00000205.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR16MB6259
X-Authority-Analysis: v=2.4 cv=HopG3UTS c=1 sm=1 tr=0 ts=6a7e691d cx=c_pps
 a=iil3+hz40n0Eqb4YezF7BQ==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=dw5MciS7gY-znkhJuOLE:22 a=cbNQJ9GKAAAA:8
 a=wqtWwZHT87S4RQOpVD4A:9 a=P0bj-C3X3jJDpopQwM1U:22
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE0MDAwNiBTYWx0ZWRfX54G2pQwF+qiO
 Yu+L/wgu1C2/HBrliNw3i8aNbGGWweh5e+xw8h/kp9PRb+WSSdaac3tkrZxJ0MaBotQmEvXu7LP
 PKV8RgCRPsxOgOOAy+fbTKpdkWWwmIjqk0KKa8RSqvcdSx7374ra
X-Proofpoint-GUID: m_ci5wSKQBnGTiV65zdYnhuVYHPkI7BA
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE0MDAwNiBTYWx0ZWRfX2j2y1TNkApn7
 P9LkchB6BKK4hJ8E+2ZZY8SbLtIyoiIRqmYIUGFtfIDGoeYo6Mubjmy7lqxxSXRp15GNRHBDmU0
 OZeuzOv7wGT/PIoJ5XiBH8nxP353QmnJuGSr/qQIDQLGg7ketxfKc2TYqKSiUDwapb5tpT0H2mW
 KMWOWTapQCfrSWwPEzI8eAR1qN5eCKvie4tSeGV+FH/GS3H3vYDASy72pPQQoaSOXyrxdYbiVfe
 x7kOtp3DU2dcwsYQSaDLemhXKCLFnn8yG0ovsIh8dSkxQzCx82MIaXSTI9cviYJfLYe5vaIXhqv
 RzpkFNAR0LI8gCTP5DsPFaFPuTa/YnS27+iddDcCCt3ursZhsw0Wbdu1NE5hmIuKNY1/D5WLP7s
 +SRQZQEphlUrNlYuFmJDjMtuCH0C2ggQ/g5AFwJH1YQEGgLIQtGzOASHozjX481dIvogp6MXswW
 Eiww1EQlTXq/zVNO11A==
X-Proofpoint-ORIG-GUID: m_ci5wSKQBnGTiV65zdYnhuVYHPkI7BA
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_07,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 impostorscore=0 priorityscore=1501 suspectscore=0 malwarescore=0
 clxscore=1015 bulkscore=0 lowpriorityscore=0 spamscore=0 adultscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608140006
X-purgate-ID: tlsNG-16d1c6/1786669343-1FCCD77B-EFFE146C/0/0
X-purgate-type: clean
X-purgate-size: 1009

From: Denis Mukhin <dmukhin@ford.com> 

Move Xen version printout from 'h' keyhandler to the new dedicated
handler '?'.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v5:
- new patch
---
 xen/common/keyhandler.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 92b0573d8b3a..03ecc4d5187a 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -131,8 +131,6 @@ static void cf_check show_handlers(unsigned char key)
 
     printk("'%c' pressed -> showing installed handlers\n", key);
 
-    print_version();
-
     for ( i = 0; i < ARRAY_SIZE(key_table); i++ )
         if ( key_table[i].fn )
             printk(" key '%c' (ascii '%02x') => %s\n",
@@ -143,6 +141,8 @@ static void cf_check show_system_info(unsigned char key)
 {
     printk("'%c' pressed -> showing system information\n", key);
 
+    print_version();
+
     print_cmdline();
 }
 
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 01:02:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 01:02:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390565.1630886 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wugJY-0005GW-Nx; Fri, 14 Aug 2026 01:02:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390565.1630886; Fri, 14 Aug 2026 01:02:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wugJY-0005GP-L7; Fri, 14 Aug 2026 01:02:28 +0000
Received: by outflank-mailman (input) for mailman id 1390565;
 Fri, 14 Aug 2026 01:02:26 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wugJV-0004qg-PU
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 01:02:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wugJV-00Ax13-6K
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 03:02:25 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e6901-2eae-0a2a0a5409dd-0a2a4502d3e6-12
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 03:02:25 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e691f-6ca4-0a2a45020019-94a38ff1d05e-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 03:02:24 +0200
Received: from pps.filterd (m0482515.ppops.net [127.0.0.1])
 by m0482515.ppops.net (8.18.1.11/8.18.1.11) with ESMTP id 67E0NPsM1611567
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:02:23 -0700
Received: from bn8pr05cu002.outbound.protection.outlook.com
 (mail-eastus2azon11011017.outbound.protection.outlook.com [52.101.57.17])
 by m0482515.ppops.net (PPS) with ESMTPS id 4g1nbh9sf9-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:02:23 -0700 (PDT)
Received: from SJ0PR13CA0160.namprd13.prod.outlook.com (2603:10b6:a03:2c7::15)
 by PH0PR16MB4117.namprd16.prod.outlook.com (2603:10b6:510:52::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.15; Fri, 14 Aug
 2026 01:02:18 +0000
Received: from CO1PEPF00012E5F.namprd05.prod.outlook.com
 (2603:10b6:a03:2c7:cafe::94) by SJ0PR13CA0160.outlook.office365.com
 (2603:10b6:a03:2c7::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3 via Frontend Transport; Fri, 14
 Aug 2026 01:02:16 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 CO1PEPF00012E5F.mail.protection.outlook.com (10.167.249.68) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Fri, 14 Aug 2026 01:02:15 +0000
Received: from pps.filterd (m0426316.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67DLVf4K1262541
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 21:02:14 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxkgce5q3-33
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 21:02:14 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id ugJHwhMUDXy1iugJIwoMpX; Fri, 14 Aug 2026 01:02:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppford; bh=B2C
	eXgWbeWAKBBRE8vrqNf21nSh2X7vYMlI+F7Op07I=; b=RInRJ0v0wQg5Bwsy+J2
	y3uKmH6I4yOHISreKqSDZfTsAd+XVsoO0oF2PApqgTpJ18++hIcS1qo+tpWdHXJb
	JlF+82AKdSOy0tlt2uA3acNAn/60JR96nz2qFx+STJ/SEVDM5+sZy7hQhu7RKEVJ
	/q4BVXLqP/nWW0+xCJu2P1jRDnTRXAY6Ws8EUml1ukHWufTA5hMzRc5VsTyt5tmz
	TESvolo/Ewond6+w/8ZjfA7tRr0c2PVp1GJBajQ9JrUsmJtwWTSp5eofN5Jd7LXB
	BKJqELiw/cXyfCXDI1MiLFK2iEwvjU6/FCRm6rymQrqU8nNXRnOXFzB752UJXXkl
	HPQ==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EjFM+bMEyrFxLUd3oSCaI6+dQZPuHW6+xagaOk7xHj95parbIESanvfM6gB3xsMvv5VQCvh2pb3STeRJSFZGPDg1UM8qjcUPO4mKcYSG8yGRROFQ+DiMcB2g267t4ya5sFI6QPqICn93+VLb3wFC5z/+vyItkdcRpTVbzgMQPrsljVFuW1BxZEksmmGcAxcZd4rXvMcHWSIoH90IMLxdzFBgOMR7qBPrWYCRxOKyG3XUKy9/VWSUaFiRenF+EEEhny99Mxf5t/Er7G8nvkNunlfZH4USs0w2ZmiHiOUgbYB8LH9jOp456e1ncx+cYkcRKEVET1Ymb3/0AQhS/hiftA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=B2CeXgWbeWAKBBRE8vrqNf21nSh2X7vYMlI+F7Op07I=;
 b=ZbNfVtC5vD7aR7A6N0Bj5TUEJwbm4uXsaUsf9cEVAZvEPXus6LJ8ju8Dm5kZ1UeVbms+5CAp+62bY8CIkb/I022dHr7ANjMWJm3RN8GQdWopIcO1wqJ4DQaR4dXL1kh1sz169W0z10cSJeKYOcY8fFXKkaGNFnl7aLD/gUodN2rjkulOGLL+J8JIE8dlJbuRWB85g4erlQaWdzfP1EPlL20EIwyY8uQ3BKIIB6dBtoE9m8AUncfoz378lJZGeoVa5DArCIhul+YqC8+aTjcgP4hvIXclrPQur2CLZpYHHlj7rao9kiiybXHeFyIB7SrRsZkxBhwQ0wugLQNtad5bRw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=B2CeXgWbeWAKBBRE8vrqNf21nSh2X7vYMlI+F7Op07I=;
 b=b4eAczSnWznOGzfzJSe6TII5tQ7YWnKAhbEEXjfEOAaVzacLdr02QNFO2PHf+I++QYETtxc7+5fqmI/qgcUCod526Z6jZGt4/ILDslzWXgUV7aNcCDrvwmmnwy8AfXVtkKag6oaIIQX/nD36kx72XtXGnCR0DdKbvw+Nm29VKdo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:in-reply-to:message-id:mime-version:references:subject:to; s=
	ppserprodsaar; bh=B2CeXgWbeWAKBBRE8vrqNf21nSh2X7vYMlI+F7Op07I=; b=
	k8pICEF93n+zhhbWANQa7c692MkubiQ5+oGDLZJ2BCG04JL+t6kVClKufBXoF80p
	PQzbxHpNy40e9dTU4MSswbX3s+N7Guxhaiee3K3IdWhK7lBjdynZkbGbdCLp5DJM
	sZV9lDAZ90iPxyk98PVPq+4qabCBix3IO+9oBOujAONjJTkVqtsaFGGQf9/ALUz1
	iZ1qQRJuRE9+P9lyonenNRQCz4gR21d1AZMZapQTni/QVu+tbAUTCd9wrb2BGGZx
	PUQndMWCsVvoHrRER6R4JGTFcBfWCEXMqNIfsyKbpmgAA3EeeMCXgvXwmWEt73Z0
	nT6BvCX1XKjWR3gnR1t7MQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=ppfserpocford; bh=B2CeXgW
	beWAKBBRE8vrqNf21nSh2X7vYMlI+F7Op07I=; b=Ew5TLz2qh3ycspVIw8DpKzR
	KDpl9CG28PCyb22TbTlbWih0hiXbx5xSAFUMIC9g08miNiZb6kcIF4FReps/3BqC
	JNCyKp837XQPD6G0RcS7csh4RpB9dIRzTwOCl42uZaHLOyqMJsi5DyDl88TJ1QED
	fU/0UB6cBLArVNmfydoBvWz1N0h+FD9anZylv6kmeLpNFsH4fXLWB5VXa/gwbYDv
	8lEko05hP0Q9nO7GD4QDQ9iIv7CcvFd57f5AuvxRjSMwnusjRyY5BrHGd+6QwFUk
	M3kn3DAGVuzh10IMxBd61fJkCi5+kazJ04G3T54DQBJC28BrnI6zAcYz8ORhqsg=
	=
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: ugJHwhMUDXy1iugJIwoMpX
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v6 1/2] xen/common: add keyhandler to show Xen command line
Date: Thu, 13 Aug 2026 18:02:05 -0700
Message-ID: <20260814010206.1321724-2-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
In-Reply-To: <20260814010206.1321724-1-dmukhin@ford.com>
References: <20260814010206.1321724-1-dmukhin@ford.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_07,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 spamscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608140006
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF00012E5F:EE_|PH0PR16MB4117:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: f1abb889-f102-41c9-77c3-08def99faea9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|23010399003|36860700016|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	CKLFUa2NOKf+7J7UMRce74kQVhdMFbLMKRPS9G7jZD6aHjd6bVUDiR9Y2DKJfMxV+8vrtfn0lo0yZ4WCHMu7Xha6hMPx83s/vqa5tJgHSitt1axp+zjv1I/8TretlzMf1LWiXnJldh4WwfjlY7qzIl/4ydQNHntnzjOCdNSnwv72GDDTINImv9WyyS8rR61WG19QYs57TWKzpi5XPVWxs7zaUyEA0/kN9mJkNrMkIa8T7Owi72bU/CkuGg5gHIBWKEID5Yo51THBNaxNzjkEIHA2OKHuTAlnwydi31wx3k12crMAtveGttccwwNqy3CTzBqV5vD+65HKQPG8a9U/kfY65/1itTxekm0/lQGSYcrvuBRr+tJDQgxEpeqrh3cnn0Q6imnzhtfjejrNZa9BsAKWMRkReFHNk5Dzl6uazzX0FkpPe2vTvoMoPN4GZJA2ZJGlejiT0VXl2IQIINVrwNjB3V8FcseRzxAncbq0DHCvyDpHa/C/p/egsWMVq6lJdUcNmZDY05ex1YwzthDsKoO+HCuyQc73zj4nJK4X5XOB8M0vd1Ml8OPUlYUDJDoWLqw0MVdVKQN4rhezq7/ea0rrtCu49xs/8kgjBj18e9PljtIp9Wa6th6D+8AI7dHs+YqK9bipjZ8T2m63T9KtNzxQ3k6zC2b7gUw86gwp07HM33415gf/GROtg8EXCimqAfKeXPkkl7KRBdSPfFyPHQ==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(23010399003)(36860700016)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	PfsFnMPVNgR1AZBB3Z5MfH1dpxuG9j09nXgLqQpLFjQIoYtd3/jjbEvvRU9mNhDmcJjvgWCd2Z5Q4Q8UKbHJ0Ob35kyx0ehheDF87gSUxjE+iHMyD1nBPAMez+aJy9k9WW3WpSlebjZbCxyMDnbIFYFTBilWAT7rqtdr0Yk21yicdUAoCC6yTM9cKe6w+3/hyaPtrh//omNF8tJ5joEOHDqwcZluPYF5s9RSrYt7ffbeNN8ga751oTyyMSr6TxeimpCjQjauTrhaXDE5/ic6+CX5pD42TO2qPEajmM2X1yaG9Ie0ZfgzQVO1AlajeAbJvlZmnwr1u2OpNzPBONXhJvd3z5dXy0GEjPboEEKQJ/PappLM0773Th6ectTFJow5cKPirGLwIqtjzaKtlPlHJ4w4hzK+m96taZNwPq8lltZSLELHOJKUy1qqUa4Owplv
X-Exchange-RoutingPolicyChecked:
	mHLUYisf9ngTFQEKbBCl/p5HNPB4lEYEDY0xMtXOF6e4dyg5rRYwngBuPw4cuxq7MSs/agrQJ84fxw8BBDKb9unPYDKZbAMAqwXFZyxLby1EvF28lWgwG43w/D1pdV4gtHxvsXwP3K3DR16DAGOF6tavzY/mSSWwd1O4FbOsjFUwxsRDx3d18+sD6CYDfcdCvA42+qNwGk/Id9e5o+giQOZBbzy5F9tL6bwloOHHq67mlpHMOhSC5l9BYeIhyL+duMBqangSISSkHPUO7iV5YCxuZcK3EMZCyPUVm1yDWcT3eSskjTpEWKFgfZH/sQaFxb/Po5UfwBAFTEX2AiPtqw==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	rDXuicLg6vHADDLLwmbxI+NZi1JYeyu8By1uIxqRSZr6icY3nXpA6aj9IjsSZJR1n7VID3lT70wLdKiOBcjta9Jv6ALZwIiU9KVUUhEWli7Sp6na6faXBcuEn44QdPrSwBIzh2j4I/OWm2xqK35Lbq1YgsJlAnHoQFKaK/qkD3tBfynFBtWqgyhIiqCMHQrK12ylGpCDHNZKxzHhWKS85cyb/PxEQfz9cwy0Vnq9eXnOriC7EK1F8Et93cHKnd1KaTrEVOjQyvWgUTiCLfSXkrIkRPC3ma95Y0PIcGmUm+GSeHMzvzSZpbtx4upFz1tSxQsJuCiyvJIpSakp5R0Ja5CL3oedSoI3AMYM+8Hi2NdVVBdZV1x95hLMjK4HTtUcy+LTBRpHtQvpk83NRhkLm5EUWlVuQm2Z7tUhis0qo7/zTINMq791sIsI8JLw7AcSxXsZusgsPCi6drm8xXIaBzLVxwvpIBfBiQ6mm30omwYqnHlpfBvUTrqiPyTi9fuA1TdIAiaUeLFpLj+LZsbtKvKJ0uQrEWexc06ayKutzKjXTOT442xoxCLXS0ZeVUo8VdD/QL593LpO8i0sCPIQG4NHSmEgarP0ewWvddZLCD1Y+MF1IgLPrIL6mFRfSkUCnc3DWQOyCnUDI57oiCJz0w==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2026 01:02:15.6385
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f1abb889-f102-41c9-77c3-08def99faea9
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF00012E5F.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR16MB4117
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE0MDAwNiBTYWx0ZWRfX5cxP4x+t/eQQ
 /c6iA/ZdsTh5nL2Q4Tv8RyhLUW0DZ//Z6IRoyBn+pb4nsQbkyhBrrjnzIxFNbe9g4OkkgNUuNI0
 yl/b+hpWnXq6MVpg3UAeqd4j+W1xfo+hG/kWhfJ0Jc99Dr+rZifdKnf8O5pRDexd2nmptifFnT+
 VlowNQTFq9icsRwrwTkh2yG4qSCKcdfzGcEVH4ml1P2P6dG79xvZpeme5mJ6AgrT4+j9+n8a4lF
 dgm+udOB4yA62HGzTxGVkUD+YKNmuyieWhckFQxrpTwQBBUMkdkzSdiLVnYmL0g4glxIzlQknGy
 +cCWFruykqMZUsfWbmSnTWc7ejS8BOKPW4fXdu2d2nrnCtMMrnsvniFPJARGwgSsW3If3WIy2EG
 Rz0VIg6v5nRYTJMIiIbDCNLUlOd+OjTEjtFmt1NjYpvS5wgclXzUl3/YUImzAMRPC2qHe3h15kA
 JAluSRAq6ZbYf5KpMQA==
X-Proofpoint-ORIG-GUID: NrCIyg0YD84yJRC5z6KAEplVibVQJcaD
X-Proofpoint-GUID: NrCIyg0YD84yJRC5z6KAEplVibVQJcaD
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE0MDAwNiBTYWx0ZWRfX5lhif/sDbtiJ
 ECzONgiz5OiO+w8mwWq6c2ZkK6lPHQHtqx5HaN4XvM+K2v8rcrVCBQHu1erWO6hUt1EgNIGbzHH
 X8j4i2ngBfIphKtKzb8dEpWSfh3R9cXq6hIGLOb/d0feAWDJbvNv
X-Authority-Analysis: v=2.4 cv=KZHidwYD c=1 sm=1 tr=0 ts=6a7e691f cx=c_pps
 a=tlTDY7m+LisZJGavll/kMg==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=0GA0A_IKJoUHBEAzNTkD:22 a=cbNQJ9GKAAAA:8
 a=j_BhcJ1dFLyuv6WhtioA:9 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_07,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 clxscore=1015 malwarescore=0 suspectscore=0 priorityscore=1501 phishscore=0
 bulkscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608140006
X-purgate-ID: tlsNG-720697/1786669345-F0CA22AC-2EEE7370/0/0
X-purgate-type: clean
X-purgate-size: 4217

From: Denis Mukhin <dmukhin@ford.com> 

Currently there's no way to print Xen command line on the emergency
console for debugging purposes when 'xl' is unavailable.

Add new print_cmdline() function to print both built-in and run-time
command lines on the console.

To allow built-in command printout, drop __initconst in
'opt_builtin_cmdline' declaration.

Add new keyhander '?' to show command line printout.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v5:
- drop version printout from 'h'
- add new handler for system information

Changes since v4:
- promote opt_builtin_cmdline to __ro_after_init and use it for
  built-in command line reporting
- account for empty saved_cmdline
- adjust register_keyhandler() call - use '?'

Changes since v3:
- print built-in command line too
- change handler to print command line only

Changes since v2:
- account for CONFIG_CMDLINE_OVERRIDE case
---
 xen/common/kernel.c     | 20 +++++++++++++++++++-
 xen/common/keyhandler.c | 10 +++++++++-
 xen/include/xen/lib.h   |  1 +
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index d1bef9ac2b2b..f4bbd8818fa8 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -35,7 +35,7 @@ boolean_param("dit", opt_dit);
 #endif
 
 static xen_commandline_t __ro_after_init saved_cmdline;
-static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
+static const char opt_builtin_cmdline[] = CONFIG_CMDLINE;
 char __ro_after_init xen_cap_info[128];
 
 static int assign_integer_param(const struct kernel_param *param, uint64_t val)
@@ -758,6 +758,24 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
     return -ENOSYS;
 }
 
+void print_cmdline(void)
+{
+    const char *cmdline;
+
+    if ( opt_builtin_cmdline[0] )
+        printk("Built-in command line: %s\n", opt_builtin_cmdline);
+
+    if ( IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) )
+        cmdline = "<ignored> (CONFIG_CMDLINE_OVERRIDE=y)";
+    else if ( saved_cmdline[0] )
+        cmdline = saved_cmdline;
+    else
+        cmdline = NULL;
+
+    if ( cmdline )
+        printk("Command line: %s\n", cmdline);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index cb6df2823b00..92b0573d8b3a 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -28,7 +28,7 @@ static unsigned char keypress_key;
 static bool alt_key_handling;
 
 static keyhandler_fn_t cf_check show_handlers, cf_check dump_hwdom_registers,
-    cf_check dump_domains, cf_check read_clocks;
+    cf_check dump_domains, cf_check read_clocks, cf_check show_system_info;
 static irq_keyhandler_fn_t cf_check do_toggle_alt_key, cf_check dump_registers,
     cf_check reboot_machine, cf_check run_all_keyhandlers;
 
@@ -58,6 +58,7 @@ static struct keyhandler {
         KEYHANDLER('t', read_clocks, "display multi-cpu clock info", 1),
         KEYHANDLER('0', dump_hwdom_registers, "dump Dom0 registers", 1),
     IRQ_KEYHANDLER('*', run_all_keyhandlers, "print all diagnostics", 0),
+        KEYHANDLER('?', show_system_info, "show system information", false),
 
 #ifdef CONFIG_PERF_COUNTERS
     KEYHANDLER('p', perfc_printall, "print performance counters", 1),
@@ -138,6 +139,13 @@ static void cf_check show_handlers(unsigned char key)
                    isprint(i) ? i : ' ', i, key_table[i].desc);
 }
 
+static void cf_check show_system_info(unsigned char key)
+{
+    printk("'%c' pressed -> showing system information\n", key);
+
+    print_cmdline();
+}
+
 static cpumask_t dump_execstate_mask;
 
 void cf_check dump_execstate(const struct cpu_user_regs *regs)
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 3c545ff33c61..618e37b920e3 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -48,6 +48,7 @@ int parse_signed_integer(const char *name, const char *s, const char *e,
 int cmdline_strcmp(const char *frag, const char *name);
 
 void print_version(void);
+void print_cmdline(void);
 
 #ifdef CONFIG_DEBUG_TRACE
 extern void debugtrace_dump(void);
-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 01:02:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 01:02:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390563.1630870 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wugJW-0004qt-8D; Fri, 14 Aug 2026 01:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390563.1630870; Fri, 14 Aug 2026 01:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wugJW-0004ql-2d; Fri, 14 Aug 2026 01:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1390563;
 Fri, 14 Aug 2026 01:02:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wugJU-0004qU-9S
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 01:02:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wugJS-00Ax13-LO
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 03:02:22 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e68dd-2eae-0a2a0a5409dd-0a2a4504a1e6-40
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 03:02:18 +0200
Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a7e6918-b57f-0a2a45040019-94a38ff184f0-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 03:02:17 +0200
Received: from pps.filterd (m0482515.ppops.net [127.0.0.1])
 by m0482515.ppops.net (8.18.1.11/8.18.1.11) with ESMTP id 67E0NNAK1611249
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:02:15 -0700
Received: from dm1pr04cu001.outbound.protection.outlook.com
 (mail-centralusazon11010070.outbound.protection.outlook.com [52.101.61.70])
 by m0482515.ppops.net (PPS) with ESMTPS id 4g1nbh9seb-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 18:02:15 -0700 (PDT)
Received: from MN0PR04CA0020.namprd04.prod.outlook.com (2603:10b6:208:52d::19)
 by MW3PR16MB3643.namprd16.prod.outlook.com (2603:10b6:303:4d::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.13; Fri, 14 Aug
 2026 01:02:12 +0000
Received: from MN1PEPF0000ECD9.namprd02.prod.outlook.com
 (2603:10b6:208:52d:cafe::40) by MN0PR04CA0020.outlook.office365.com
 (2603:10b6:208:52d::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.15 via Frontend Transport; Fri,
 14 Aug 2026 01:02:12 +0000
Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by
 MN1PEPF0000ECD9.mail.protection.outlook.com (10.167.242.138) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Fri, 14 Aug 2026 01:02:12 +0000
Received: from pps.filterd (m0373461.ppops.net [127.0.0.1])
 by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67E10X5I1155656
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 21:02:11 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com
 [50.112.124.217])
 by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4fxk37p5pt-24
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Thu, 13 Aug 2026 21:02:11 -0400 (EDT)
Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA
 id ugJEw3oHNgCzqugJFwvxzb; Fri, 14 Aug 2026 01:02:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:content-type:date:from:message-id
	:mime-version:subject:to; s=ppford; bh=dPlCYlfRqOhy/3ft3EqkHC5b0
	wVGtmZIu46YJD3f2eE=; b=ERAK38olTBjQOygXVkYM1q7fYNSzEdAIBfzfjqmGl
	SnDuheXkODoE3WdSxL7meIAvZnMFWcThEytRqUBRtzdLdHOzLpAqEXyledDyUBzA
	fVYVDs23WrmKEaqjNE6NJkfpIDImFw07KyGOEC4wqDQMFiK3VukzmNAKHB0UzD7h
	p9j8kbIFV0p6Tlp0Ke/tkFOcjlhoT3ougTqEfGEawz7vPTD27f6cAfFwaY/tCkLw
	k3xOp7RllSkFBj2uXkGUfQK0VXXLqjruaf+6poB1XHAYkHHc4zrhJkVtA7b+O+I3
	2aMIj8DB4jSkdI5/vXpOKgFGzyIIvqWna5HPIq3xsrYhw==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PkFmc7XHBQmKhOtYKJjDgbDDU1h6fVBFrfC+xk2h7vOjhR1qLgitOap+glNZGNozUusDn9pCAamumHkrSoqQJ+p60s+t4QTXuBHh4yOyawIJDfwwCCZ9UIP2oyRozHkA7WF8C22Fx/vZ/S979CclL+hgKOhB4vSnk+/YAa/jPij7ypQbjMML6lGZtsGbSDKR9jYTJtLLu7543JvV5vhEKtXkMBxvejX6QM1etCJ16BunItIFSlK0fJj2kx/nR+h/VGLIwqJxWiTwjNeQl6ywlryoxSDWeVG0iOLF0GLmSuR9dwEHXM824kiSjYMKg0hqMhA6fY95vydrO/CD60kWgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dPlCYlfRqOhy/3ft3EqkHC5b0wVGtmZIu46YJD3f2eE=;
 b=Sxc3+8Y94qYeaXPSHzcFuiEhHRdj0vcZyIlnFFLaFKx+pL04e2jneuo/R2YZyZTFl4i47Bv1rV0gM3pmw5CizezhVZqe4ihjvspez/lhy1KBkMWltec8Yaki232AsEKIadI6vkewI0q/ooSFbjCZZFLw8fp9053ZuEM6B4yh2q0l1v2CXzIAYser7LkAWwa0wuW6culiIJKET5gmIwYvQRIVNw1l1jkrkm0Lbr8zOClm358Vmg7JwrycGTx/sffjkhpSBfuox5KH43ejwTOKRmTnIp4jneqGY03bF0YVts+Mwu/PkeQzDC05/bcHQEw71TlV5zSMgMq537GNupfSgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dPlCYlfRqOhy/3ft3EqkHC5b0wVGtmZIu46YJD3f2eE=;
 b=EJgbWCb9xJWXHn2g5QhZmWp55JbhF50VCY0wb0rW5oCVj1ds9lV7fkVnHym4IJtwD1gQhdfPJ9GFnZpX7hqNrOmsGwpPSbWnt9VKChd2ryHGvoi5d2+zu5pDfK6YITVk9GoKkiRGez1gdhTfAhCJ/lvyHttmnQ0/JMesRJC3mlg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 148.163.138.245 as permitted sender) receiver=protection.outlook.com;
 client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-transfer-encoding:date:from
	:message-id:mime-version:subject:to; s=ppserprodsaar; bh=dPlCYlf
	RqOhy/3ft3EqkHC5b0wVGtmZIu46YJD3f2eE=; b=jyyTCRSlK3ZxXeJXYc8gR6R
	e1w6DwgWEphGde6rIxJkMqB3fT4nbU+eIzD3tAC5mZaWgGWMr7++/0YZbmFV3F+W
	TlrjQhRNDz2AuiWIDNnqHVhP9FFZ5Hbv8vIcCvhT0BWVVsFE/UsRzRZtG4Bzi/12
	fmSgee4BMm+OLpLCAtZV5Nc+/d45X52mJr7WzZBRHl7x+xO2bObkfNI7gdvd0cKm
	1eHZXUz0bPngNlb7iY45RMeDWA/gY+mXHuGjJ0hN3fWu5jzKxtESSm8ZcdqMEx82
	1vGyOPwh6GC41n7lq39G2wJfPeSqpA9ivB7faRw0ybRa9Rk4l8Iic5+/MfjYtEw=
	=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=ppfserpocford; bh=dPlCYlfRqOhy/3ft3EqkHC5b0wVGtmZ
	Iu46YJD3f2eE=; b=ULtLA1za7c2RVYF7IDTO5GDwjiUK7ibqSPgM2FDFnZO2uTR
	RqOdUxveTZokdHLzsiSyoJzzVfB/F2bSUWmNmxA1Dk6jzKtmhABdpdDmo0MKk+tR
	RFUn3NdHMXVigANBP/K5Z3LjFUiwh6knJDyENxd3DZVbK1LwlI3U1coS67isYw7A
	CLnPFJHG+DGLKahIF4WiixX0v7oixSHKMFdcVumO5j+WacpCmfYIxOc8uoic7q/j
	7dwCNXwmMSauwPaz+3Lt6fb+3J+mxcRDZaI76dWfIH1l97liozVE4DmmrJJ+e/FI
	iCS6VKJCE6iWzRo2V04wnlD1zQO5re67chw0Ujw==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: ugJEw3oHNgCzqugJFwvxzb
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
To: xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, dmukhin@ford.com
Subject: [PATCH v6 0/2] add keyhandler to show Xen command line
Date: Thu, 13 Aug 2026 18:02:04 -0700
Message-ID: <20260814010206.1321724-1-dmukhin@ford.com>
X-Mailer: git-send-email 2.54.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_07,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 adultscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 phishscore=0
 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound
 adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608140006
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD9:EE_|MW3PR16MB3643:EE_
Content-Type: text/plain
X-MS-Office365-Filtering-Correlation-Id: 88e64606-c2d6-4b31-605e-08def99fac8d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|23010399003|36860700016|1800799024|10067099003|56012099006|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	ZGprwLDv7Cj5voNdeKjaf1jRwqWsKZ2wJZKun5w7ToM2k5toZx1PHiEqdooKMNX56xg3sn9aMfA908rSpVRIT0c1llCdvNY3mX9q+hQR5tncoKZHM5UT4bYvK0cEmzfAkeTm4EQG+ItNCQiCLmz0TTjk40jfSwAw6ziUBLNP7qCxk00NQE2XccK5HTGeFMhjKx8EkMZHo0bmy/26Lo0Vz+kxW1XB+Myfe/kWByVxTxAppbLP56w875U+7PA+/64oJN9FYVcm+qySbqiiDs5KWYfBgn/qjEgHKr9JH/apB+h47qq6MPooQKAbCfU4JT4Lh7TK9sXsbXgz5Y5oEFEfN6sIdh5txiWQ5WjZu/JUDhRUkWdXR3KQp/pYtGlCbon+pNF+6/4kYXYfsM0LanudfduyYTXq7CG78FsFe2C8L9o61XaHhmlpTq/FqjvARd0N3/2f+xF8FyL74bAfutmn3dOo1K15paaFFp3U7yFviKkDQk8F2DcwhXSmPqGBWhYx3Lswb35V+C0hQpqL9xQLXgUR5ipPs+AFoX1qCjmCCf/dNT4pzx6YwCSEiv+FWoElYhPsV6K9f1Q4jbyZDRM1Y3yyXLzwi6ldMDCvVpREtUNr0w9VJYN+g//8UycbemYfDwi/PRF1uA9r1AjF0vPOq7kR/XZMDiKJRLEyBDSxEhmZWvYiBkgmM3F/p18cZADEEKSl5kcb7cblwNdidqB0Ow==
X-Forefront-Antispam-Report:
	CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(82310400026)(23010399003)(36860700016)(1800799024)(10067099003)(56012099006)(11063799006)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	exe2U+konhNI8Q+M2EUlJZuteS9LFpuau+tr4p+piMWgnw7uzC81ldEtAfimSY2toxkyJDUS/9AH/rhv0NuIbHBl9DbcJc/Wae9Py0VudQHdVF/ueVDpgaHIhQ6IjjRo9PvQ76UdrtiiflKixAD4FEDNbyztSMbKpIRrk1XonjAhpnsPt5jqrs5fDAW+R79Y3zuBZNw/IiFFcFbWqTkLd6uYrwoFMkYOvBpEqENTgXp2kCs9XAviaVeOjESC7C8oCsGRA0uCboyZdAXdjLNyYywTJhX8Os9ACuW1z5Hqf0r4oFXGGffVwL2vj/ulUYRlWc2qaI1vBmrY2GEyciFYm+s/fJ6j2lwpUjv8TtYiXyn2hbcryYk3cMLLchvThRZEGkc4U4c1jKqKg7IOedmGtzRELsAhLNAsOn7Ifd6RsFseHtYdUgX2zagVkBJHjCFT
X-Exchange-RoutingPolicyChecked:
	cexAKZlNM0810BcOgaYC27Y8KMDYdG9ODw5AS1+vDekaliMCwgY/wck2ZacCzwXfFOWrueJ3AWGMEQpZttS+ts55Pg78smeKki21DZYHHuGTkC4uSra8SyXVJx41CVrReZncYWNio9B2z0rsebmFHaUB9rq634Q8L4a+F/n+//rRu4ZiM8K18e3M+KlEcU/c44UQMjqsAlzW0qbLNWm9W7fuA0Et1z2d9FtathB5Jp7YAitXa+ToqDIMWF1UVXvngy3vkKUkP0S/JYAo8IzgKUrwoLtRx4hoeH6RoKVuRJyDIqa9lsiYMrA6SgXq5pGiFev1+1F21+qLv4jdg2JKuQ==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	cCoVt/nCynbwLztaYDYi+UJho3fYrwq/+429FtzgHYH5oM+HcQhgbg0Ya/K+ucYSf/i1DZTAlCVD8TADFTaJ6puwcAa174EAeV7ZivSZS50yf4S8Ubst2Kvv6HpNgGJFKSxlRM8MSmE1H0ymosi2D9WNiTldAKgP8EBlkXMC+KTncoD5QDAy/mgTCcnrPpvvSlP7verjustTrQltmLZpFJUCgt6HX+7bIlo2HzvIeHKBMGHdkHdWG5hKYy6PivdsOdfrJwxiDaYQh0PcLlD1UahYe93IGQ2wSUNJmMlGXDBpvWOWoCt+KmhumdKVv2P7KFIb/h6UOAqNkUn5pwrJWX0scsiNxr0ddV1DtPJjS2iyC+RwAI6iyuN/a0XwSiLuB7esQjmTmVD1RAhRTZzYZIMLV5eetmapf+6Lt04q3JWaRHX3OuSKzgn4AS+cW4TTBerN2SLkrI5ZFMIdUiXcnpZqYbhqfQxYIR8LSPmUrwmJWZaDmeOGgAoNczepuh+jMiLfPHelTHzmAWNWzuCLOCpb/EA6megGQ8/JU7GacnZYpQrvCeLp867AlIQTddcUKll6pJOBieOscPsO7Dq3TYVYFtm5Xty0kIbXFMbgmei9l0h0WgR9EZgxzP/KVYOg/X8Px0L7lpv+Ni+LixncSw==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2026 01:02:12.2206
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 88e64606-c2d6-4b31-605e-08def99fac8d
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000ECD9.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR16MB3643
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE0MDAwNiBTYWx0ZWRfX/c36BpTmXkvC
 JkiGTBvQOPtx+IS71enAkRPBC3RrM5fkcC/gZU+cLzvqY2Qr0ZzlMajNBXcKiDE4wVrB+ZSG6DO
 P1T/P5J4AF2WYIEvz4QsvOTlujnSEglfwRcSw/XzfCXjO2UBcV1BPXEVSCFUyC+socJSylKi5pT
 5C4HTJvlXmgGe1Bd3a5IszBvnu3w+FGvLbj4s5Gix9m/EaV0SY478owSbbQevWiQrHcJwsAB7mv
 qjhyR44rUTFinJPiTte52OjXtLWT72JFQ6X5QPaxduz+MoQ47dnJ41OThYnRmYdMv8nDAR5VPWv
 AWBfgV0b3A8viIfeWzSU5GaMP6/nQo6Wy02xN1DznbhrSXdwIeath952g8wh62JYnktzEW6aRoi
 fNnJ16RQLNSDLJJJ3k2o0EOadelch3INutPbWU3JCW0LAhZ+QZ2514IFkTJoBDIPqJCoQyCP/bH
 lsVMOVZdf+QQZNRhoAQ==
X-Proofpoint-ORIG-GUID: uYiG-cXXEA2A1q1b5PWJhQTAywcwZd_F
X-Proofpoint-GUID: uYiG-cXXEA2A1q1b5PWJhQTAywcwZd_F
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE0MDAwNiBTYWx0ZWRfX15gTEhqYjrWy
 HWsqk1USTnQeGYdxbt78gg8+qnRBuET0xYSnsaS1QmWvHF9ixqBeb6GEL20tkzhGdZSr3GFWGlD
 JIO8ZHTefOzR56Y9WCTGA6aPzVv9iYUV001eWQO+OW4rc4mNH87D
X-Authority-Analysis: v=2.4 cv=KZHidwYD c=1 sm=1 tr=0 ts=6a7e6917 cx=c_pps
 a=xHwt0NLWInP9jDJIu2hPAg==:117 a=b7IhknPlfT0FN1EembXvig==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Sv0fKeRqtYgA:10 a=3PXLN80vpJUA:10
 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=P_n1zlmtWsCQbjROFjcg:22 a=0GA0A_IKJoUHBEAzNTkD:22 a=VwQbUJbxAAAA:8
 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=wqEq80CTKEgO30SQpmUA:9
 a=DqJYxgmhk6moR-_7_KoZ:22
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-13_07,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 clxscore=1015 malwarescore=0 suspectscore=0 priorityscore=1501 phishscore=0
 bulkscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608140006
X-purgate-ID: tlsNG-ebf023/1786669338-C0CDFB50-D0417E68/0/0
X-purgate-type: clean
X-purgate-size: 609

Mini-series to add new keyhander '?' for showing system information,
including command line and version info.

v5: https://lore.kernel.org/xen-devel/20260813035139.915536-2-dmukhin@ford.com/
CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2758940285

Denis Mukhin (2):
  xen/common: add keyhandler to show Xen command line
  xen/common: move version printout under '?' keyhandler

 xen/common/kernel.c     | 20 +++++++++++++++++++-
 xen/common/keyhandler.c | 14 +++++++++++---
 xen/include/xen/lib.h   |  1 +
 3 files changed, 31 insertions(+), 4 deletions(-)

-- 
2.54.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 03:10:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 03:10:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390709.1630895 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuiJR-000482-Dh; Fri, 14 Aug 2026 03:10:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390709.1630895; Fri, 14 Aug 2026 03:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuiJR-00047u-9n; Fri, 14 Aug 2026 03:10:29 +0000
Received: by outflank-mailman (input) for mailman id 1390709;
 Fri, 14 Aug 2026 03:10:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ehem@m5p.com>) id 1wuiJQ-00047o-Dh
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 03:10:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuiJP-00EgYN-Ne
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 05:10:27 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ehem@m5p.com>)
 id 6a7e8716-8faa-0a2a0a5109dd-0a2a4507ebac-4
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 05:10:27 +0200
Received: from [74.104.188.4] (helo=mailhost.m5p.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ehem@m5p.com>)
 id 6a7e8722-b4ea-0a2a45070019-4a68bc047e80-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 05:10:27 +0200
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:8ac4:0:0:0:0:f7])
 by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPS id 67E3AHc7064974
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Thu, 13 Aug 2026 23:10:22 -0400 (EDT) (envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
 by m5p.com (8.18.1/8.15.2/Submit) id 67E3AGgl064973;
 Thu, 13 Aug 2026 20:10:16 -0700 (PDT) (envelope-from ehem)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Date: Thu, 13 Aug 2026 20:10:16 -0700
From: Elliott Mitchell <ehem+xen@m5p.com>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>
Cc: Cody Zuschlag <cody.zuschlag@xenproject.org>,
        xen-devel@lists.xenproject.org, anthony.perard@vates.tech
Subject: Re: [ANNOUNCE] - Call for agenda items for August 6 Xen Community
 Call @ 15:00 UTC
Message-ID: <an6HGMxZDd-Uv61d@mattapan.m5p.com>
References: <CAJbE=KznNsrNRN=pUaDj7-TVW4uCMVBdrPpei_z5nBdjdHnVag@mail.gmail.com>
 <anqKjwU93bMcttNz@mattapan.m5p.com>
 <anrfqjt69_K900nJ@macbook.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <anrfqjt69_K900nJ@macbook.local>
X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS,
	T_SPF_HELO_PERMERROR,T_SPF_PERMERROR autolearn=no autolearn_force=no
	version=4.0.2
X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on mattapan.m5p.com
X-purgate-ID: tlsNG-ef75cf/1786677027-362C4AE4-F438937D/0/0
X-purgate-type: clean
X-purgate-size: 8378

On Tue, Aug 11, 2026 at 10:39:31AM +0200, Roger Pau Monné wrote:
> On Mon, Aug 10, 2026 at 07:35:59PM -0700, Elliott Mitchell wrote:
> > On Tue, Aug 04, 2026 at 05:30:50PM +0200, Cody Zuschlag wrote:
> > > *Preparation*
> > > 
> > > 👉 Please take a few minutes to review and update the agenda before the
> > > call:
> > > 
> > > https://cryptpad.fr/pad/#/2/pad/edit/eqPXghB7GwT4OuySCjSQRyVD/
> > > 
> > > Feel free to:
> > > - Add topics or project updates
> > > - Suggest anything we can drop or defer
> > > - Include links to patches, mailing list threads, or documentation where
> > > helpful
> > > 
> > > The agenda also includes the meeting link and a link to find your local
> > > meeting time.
> > > 
> > > 
> > > *Call Details*
> > > Date: Thursday, 6 August 2026
> > > Time: 15:00 UTC (agenda starts at 15:05 UTC)
> > > Join: https://meet.jit.si/XenProjectCommunityCall
> > > 
> > > We'll open the room at 15:00 UTC and begin the agenda at 15:05 UTC to give
> > > everyone a few minutes to join.
> > 
> > 
> > Took me a bit of time to consider what had been said in order to come up
> > with next responses.
> > 
> > I didn't emphasize it during the community call, but the point was
> > explicit in the most recent posted message:
> > 
> > https://lore.kernel.org/xen-devel/ajr0gN9kmPkLQlGF@mattapan.m5p.com/T/
> > 
> > This was previously allowed by Xen/ARM.  This turned into a bug when the
> > Xen/ARM team decided to disallow multiple mappings of the shared
> > information page.  During approval the Xen/ARM team was explicitly asked
> > to accept the task of updating outside projects to deal with fall-out.
> > 
> > I don't recall the exact wording of the agreement, but this is certainly
> > fall-out from that change.  As such this IS an adjustment the Xen/ARM
> > team agreed to aid.
> > 
> > I've already generated a PoC, I had thought the Xen/ARM team would be
> > better acquainted with whom to ask about getting a patch along those
> > lines in.  That seems a reasonable ask in light of the team having
> > accepted the task.
> 
> I don't know what you mean or imply with "accepted the task".  It
> sounds a bit selfish to me that you refuse to finish the OVMF work.
> It's possible none of us likes the OVMF coding style more than you do,
> yet you seem to assume we have some kind of duty to pick this work and
> finish it.  That's IMO an unacceptable burden to put on developers of
> an open source project.

When the decision was made to disallow mapping the shared information
page multiple times on ARM there was a discussion.  The issue of the
change breaking existing implementations was brought up and there was
some level of agreement the ARM team would do some work on that (though
there may have been an expectation it wouldn't need much).

I recall this being sometime around 2020-2023, but so far search engines
have failed me.  As such I don't have exactly what was typed handy.

Tianocore/EDK2 worked fine with Xen/ARM 4.14 (before the change), but
was broken with 4.17.  It isn't exactly Tianocore/EDK2, but it leaving
its mapping behind breaking the loaded OS.

> > I don't know the Xen developers by voice.  As such I don't know who
> > mentioned 'firmware = "ovmf"' when I was trying to bring up
> > Tianocore/EDK2 as bootloader.  Now that I've checked by notes, whomever
> > brought that up was quite unfamiliar with that I was trying to bring up.
> > 
> > The 'firmware = "ovmf"' setting is part of HVM domain configuration.  In
> > this environment Tianocore/EDK2 is merely setting up some ACPI tables and
> > then handling the task of finding and invoking the OS bootloader.  Since
> > all the hardware is emulated, Tianocore/EDK2-firmware isn't much
> > different from what it normally does.  I should also note this is fairly
> > slow.
> > 
> > Despite sharing the codebase, Tianocore/EDK2 as bootloader is very
> > different from being HVM firmware.  In particular the arm64
> > Tianocore/EDK2 configuration is "ArmVirtPkg/ArmVirtXen.dsc" and the build
> > creates the file "XEN_EFI.fd".  Once built the domain configuration is
> > along the lines of:
> > 
> > type = "pvh"
> > name = "somename"
> > kernel = "XEN_EFI.fd"
> > memory = 256
> > vcpus = 2
> > vif = [ "somenet" ]
> > disk = [ "somedisk" ]
> > 
> > The result is a PVH domain with Tianocore/EDK2 functioning as a pure
> > bootloader.  In particular it is capable of searching for its preferred
> > filesystem, then looking for an appropriate filename and then loading
> > that using the UEFI protocol.  The result is near-ideal.
> > 
> > Of note I'm pretty sure Tianocore/EDK2-bootloader would happily load
> > EFI-GRUB.  More importantly though OS bootloaders which can handle UEFI
> > work perfectly in this setup.  I expect this to be superior for *BSD.
> > 
> > There are two problems with Tianocore/EDK2-bootloader though.  First, is
> > the aforementioned unresolved bug.  Second, this is only implemented for
> > aarch64 (arm64).
> 
> Anthony has done the work for OVMF to work on x86 PVH domains, maybe
> he can provide more information about how to set it up and test.

I've run into mentions of this, but I've yet to see anything working.  I
really hope for something very similar to "ArmVirtXen.dsc" as that is
nearly perfect.

IMNSHO calling all x86 output files "OVMF.fd" was quite unhelpful.
Problem is "OVMF" can refer to any one of 3-5+ build configurations
causes quite a bit of confusion.  I distinctly prefer the "XEN_EFI.fd" as
the filename itself hints at what it is.

> > This is a problem for all the paravirtualized bootloaders.  They're all
> > single-architecture, despite the bootloader supporting multiple
> > architectures.  On that single-architecture they're quite good, but Xen
> > really needs them on *all* their architectures.
> > 
> > 
> > I didn't get the chance to finish my suggestion during the call, so here
> > is what I wanted to suggest:
> > 
> > I think the Xen Project really needs some effort aimed at the
> > paravirtualized bootloaders.  Mostly making them operable on all
> > architectures they support.
> > 
> > Paravirtualized GRUB is needed for ARM, RISC-V and PowerPC.
> > 
> > I don't believe Tianocore/EDK2 supports PowerPC, but I would really hope
> > for it to become available for RISC-V and x86.
> > 
> > While U-Boot is difficult to deal with, it would be valuable as a second
> > paravirtualized bootloader for PowerPC.
> > 
> > Once those 3 were available on their applicable architecture it would be
> > time to purge PyGRUB.  While I imagine this will take a while I think it
> > should be on the roadmap/panciled in for the future.
> 
> In my opinion, it's naive to expect this plan to be realized without
> any developer effort behind it from your side.  Leaving aside whether
> it's the right call from a technical prospective, I don't think it's
> fair to come to an Open Source community, drop a multi-project
> multi-architecture plan, and expect others to simply start crunching
> on it because "it's the right thing to do".
> 
> Most of us already have very thigh deadlines and internal projects by
> our employers, and that's always going to take priority.  And then
> with whatever little "free" time we have, we might have other goals
> and tasks that prefer to pursuit.
> 
> In other words, I think if you want to see this making progress you
> either have to work on it yourself, or pay some developer(s) to do the
> work.

My goal is to provide a recommendation of where effort should be focussed
and provide insight into what most users want.

I'm presently trying to get another OS on Xen/ARM and figure I should
finish that before taking on other things.  Perhaps I may try to see how
difficult being cross-architecture is for GRUB next.  I'm doing what I
can, but my bandwidth is very limited.

(yes, I know everyone says that; just be glad you almost certainly lack
my type of life challenge)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




From xen-devel-bounces@lists.xenproject.org Fri Aug 14 06:05:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 06:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390742.1630906 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wul2E-0006l9-6T; Fri, 14 Aug 2026 06:04:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390742.1630906; Fri, 14 Aug 2026 06:04:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wul2E-0006kw-1p; Fri, 14 Aug 2026 06:04:54 +0000
Received: by outflank-mailman (input) for mailman id 1390742;
 Fri, 14 Aug 2026 06:04:52 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <james@dingwall.me.uk>) id 1wul2C-0006kq-UR
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 06:04:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wul2C-002uN7-BM
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 08:04:52 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7eafeb-8faa-0a2a0a5109dd-0a2a450a9076-36
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 08:04:52 +0200
Received: from [212.23.1.22] (helo=smarthost01c.ixn.mail.zen.net.uk)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7eb003-f2d2-0a2a450a0019-d41701169d92-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 08:04:52 +0200
Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk)
 by smarthost01c.ixn.mail.zen.net.uk with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97)
 (envelope-from <james@dingwall.me.uk>) id 1wul2B-00000000B81-20DT;
 Fri, 14 Aug 2026 06:04:51 +0000
Received: from localhost (localhost [IPv6:::1])
 by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id 45B32F0985C;
 Fri, 14 Aug 2026 07:04:51 +0100 (BST)
Received: from mail0.xen.dingwall.me.uk ([IPv6:::1])
 by localhost (mail0.xen.dingwall.me.uk [IPv6:::1]) (amavis, port 10024)
 with ESMTP id Ie_Y05KXr7I6; Fri, 14 Aug 2026 07:04:51 +0100 (BST)
Received: from ghoul.dingwall.me.uk (ghoul.dingwall.me.uk [192.168.1.200])
 by dingwall.me.uk (Postfix) with ESMTP id 01FF3F09859;
 Fri, 14 Aug 2026 07:04:50 +0100 (BST)
Received: by ghoul.dingwall.me.uk (Postfix, from userid 1000)
 id D8FAA8F2; Fri, 14 Aug 2026 07:04:50 +0100 (BST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
X-Virus-Scanned: Debian amavis at dingwall.me.uk
From: James Dingwall <james-xen@dingwall.me.uk>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>
Subject: tools/hotplug: fix invalid frontend path for set_mtu
Date: Fri, 14 Aug 2026 07:03:49 +0100
Message-ID: <20260814060441.923061-1-james-xen@dingwall.me.uk>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Originating-smarthost01c-IP: [217.155.64.189]
Feedback-ID: 217.155.64.189
X-purgate-ID: tlsNG-4011c0/1786687492-5A9D9CFC-66E29EDF/0/0
X-purgate-type: clean
X-purgate-size: 426


Hi,

This is a resubmission of patches previously discussed in this thread:

https://lists.xen.org/archives/html/xen-devel/2022-04/msg02209.html

It appears they fell down a crack after review and never made it to git.
This is a fix for reading a custom interface mtu from xenstore when the
interface is given a non-default name along with an adjustment to the
check that the value read is >=68.

Thanks,
James


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 06:05:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 06:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390744.1630913 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wul2T-00073e-BA; Fri, 14 Aug 2026 06:05:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390744.1630913; Fri, 14 Aug 2026 06:05:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wul2T-00073X-8W; Fri, 14 Aug 2026 06:05:09 +0000
Received: by outflank-mailman (input) for mailman id 1390744;
 Fri, 14 Aug 2026 06:05:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <james@dingwall.me.uk>) id 1wul2R-00072v-GK
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 06:05:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wul2Q-008Jrg-T7
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 08:05:06 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7eb004-2eae-0a2a0a5409dd-0a2a4501a102-42
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 08:05:06 +0200
Received: from [212.23.1.21] (helo=smarthost01b.ixn.mail.zen.net.uk)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7eb012-5984-0a2a45010019-d417011593cc-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 08:05:06 +0200
Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk)
 by smarthost01b.ixn.mail.zen.net.uk with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97)
 (envelope-from <james@dingwall.me.uk>) id 1wul2Q-00000003X2U-1X0j;
 Fri, 14 Aug 2026 06:05:06 +0000
Received: from localhost (localhost [IPv6:::1])
 by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id F0E77F09860;
 Fri, 14 Aug 2026 07:05:05 +0100 (BST)
Received: from mail0.xen.dingwall.me.uk ([IPv6:::1])
 by localhost (mail0.xen.dingwall.me.uk [IPv6:::1]) (amavis, port 10024)
 with ESMTP id 9s8zgJlwCVpw; Fri, 14 Aug 2026 07:05:05 +0100 (BST)
Received: from ghoul.dingwall.me.uk (ghoul.dingwall.me.uk [192.168.1.200])
 by dingwall.me.uk (Postfix) with ESMTP id BE51FF0985D;
 Fri, 14 Aug 2026 07:05:05 +0100 (BST)
Received: by ghoul.dingwall.me.uk (Postfix, from userid 1000)
 id B00DC5F0; Fri, 14 Aug 2026 07:05:05 +0100 (BST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
X-Virus-Scanned: Debian amavis at dingwall.me.uk
From: James Dingwall <james-xen@dingwall.me.uk>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	James Dingwall <james@dingwall.me.uk>
Subject: [PATCH 1/2] tools/hotplug: fix invalid frontend path for set_mtu
Date: Fri, 14 Aug 2026 07:03:50 +0100
Message-ID: <20260814060441.923061-2-james-xen@dingwall.me.uk>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260814060441.923061-1-james-xen@dingwall.me.uk>
References: <20260814060441.923061-1-james-xen@dingwall.me.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Originating-smarthost01b-IP: [217.155.64.189]
Feedback-ID: 217.155.64.189
X-purgate-ID: tlsNG-d62444/1786687506-C5540757-EF70DABE/0/0
X-purgate-type: clean
X-purgate-size: 1935

From: James Dingwall <james@dingwall.me.uk>

The set_mtu() function of xen-network-common.sh currently has this code:

        if [ ${type_if} = vif ]
        then
            local dev_=${dev#vif}
            local domid=${dev_%.*}
            local devid=${dev_#*.}

            local FRONTEND_PATH="/local/domain/$domid/device/vif/$devid"

            xenstore_write "$FRONTEND_PATH/mtu" ${mtu}
        fi

This works fine if the device has its default name but if the xen config
defines the vifname parameter the FRONTEND_PATH is incorrectly constructed.
Learn the frontend path by reading the appropriate value from the backend.

Also change use of `...` to $(...) for a consistent style in the script.

Signed-off-by: James Dingwall <james@dingwall.me.uk>
---
 tools/hotplug/Linux/xen-network-common.sh | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/hotplug/Linux/xen-network-common.sh b/tools/hotplug/Linux/xen-network-common.sh
index 0150a4840e..f83eeef030 100644
--- a/tools/hotplug/Linux/xen-network-common.sh
+++ b/tools/hotplug/Linux/xen-network-common.sh
@@ -161,7 +161,7 @@ set_mtu () {
     local mtu=$(xenstore_read_default "$XENBUS_PATH/mtu" "")
     if [ -z "$mtu" ]
     then
-        mtu="`ip link show dev ${bridge}| awk '/mtu/ { print $5 }'`"
+        mtu="$(ip link show dev ${bridge}| awk '/mtu/ { print $5 }')"
         if [ -n "$mtu" ]
         then
             log debug "$bridge MTU is $mtu"
@@ -174,11 +174,7 @@ set_mtu () {
 
         if [ ${type_if} = vif ]
         then
-            local dev_=${dev#vif}
-            local domid=${dev_%.*}
-            local devid=${dev_#*.}
-
-            local FRONTEND_PATH="/local/domain/$domid/device/vif/$devid"
+            local FRONTEND_PATH="$(xenstore_read "$XENBUS_PATH/frontend")"
 
             xenstore_write "$FRONTEND_PATH/mtu" ${mtu}
         fi
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 06:05:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 06:05:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390746.1630922 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wul2Y-0007MU-Ho; Fri, 14 Aug 2026 06:05:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390746.1630922; Fri, 14 Aug 2026 06:05:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wul2Y-0007MJ-Eo; Fri, 14 Aug 2026 06:05:14 +0000
Received: by outflank-mailman (input) for mailman id 1390746;
 Fri, 14 Aug 2026 06:05:13 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <james@dingwall.me.uk>) id 1wul2X-0007K3-Dc
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 06:05:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wul2W-0006DM-AS
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 08:05:12 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7eb015-8faa-0a2a0a5109dd-0a2a450cd480-10
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 08:05:12 +0200
Received: from [212.23.1.21] (helo=smarthost01b.ixn.mail.zen.net.uk)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <james@dingwall.me.uk>)
 id 6a7eb018-f479-0a2a450c0019-d41701158232-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 08:05:12 +0200
Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk)
 by smarthost01b.ixn.mail.zen.net.uk with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97)
 (envelope-from <james@dingwall.me.uk>) id 1wul2V-00000003X3F-4BtL;
 Fri, 14 Aug 2026 06:05:12 +0000
Received: from localhost (localhost [IPv6:::1])
 by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id B567BF09864;
 Fri, 14 Aug 2026 07:05:11 +0100 (BST)
Received: from mail0.xen.dingwall.me.uk ([127.0.0.1])
 by localhost (mail0.xen.dingwall.me.uk [127.0.0.1]) (amavis, port 10024)
 with ESMTP id rf9CWZLGjV3g; Fri, 14 Aug 2026 07:05:11 +0100 (BST)
Received: from ghoul.dingwall.me.uk (ghoul.dingwall.me.uk [192.168.1.200])
 by dingwall.me.uk (Postfix) with ESMTP id 8D79FF09861;
 Fri, 14 Aug 2026 07:05:11 +0100 (BST)
Received: by ghoul.dingwall.me.uk (Postfix, from userid 1000)
 id 8A5CCAC8; Fri, 14 Aug 2026 07:05:11 +0100 (BST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
X-Virus-Scanned: Debian amavis at dingwall.me.uk
From: James Dingwall <james-xen@dingwall.me.uk>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	James Dingwall <james@dingwall.me.uk>
Subject: [PATCH 2/2] tools/hotplug: validate mtu read from xenstore against RFC 791 minimum
Date: Fri, 14 Aug 2026 07:03:51 +0100
Message-ID: <20260814060441.923061-3-james-xen@dingwall.me.uk>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260814060441.923061-1-james-xen@dingwall.me.uk>
References: <20260814060441.923061-1-james-xen@dingwall.me.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Originating-smarthost01b-IP: [217.155.64.189]
Feedback-ID: 217.155.64.189
X-purgate-ID: tlsNG-d25034/1786687512-5093EA5B-062069C2/0/0
X-purgate-type: clean
X-purgate-size: 1280

From: James Dingwall <james@dingwall.me.uk>

RFC 791 sets the minimum acceptable mtu to 68:

    Every internet module must be able to forward a datagram of 68
    octets without further fragmentation.  This is because an internet
    header may be up to 60 octets, and the minimum fragment is 8 octets.

In the Linux kernel source:

include/net/ip.h:#define IPV4_MIN_MTU           68              /* RFC 791 */

While there is no reason to expect a value <68 to be read from xenstore or
from the bridge make the value test require a number >= this minimum.

Signed-off-by: James Dingwall <james@dingwall.me.uk>
---
 tools/hotplug/Linux/xen-network-common.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/xen-network-common.sh b/tools/hotplug/Linux/xen-network-common.sh
index f83eeef030..344730cb42 100644
--- a/tools/hotplug/Linux/xen-network-common.sh
+++ b/tools/hotplug/Linux/xen-network-common.sh
@@ -167,7 +167,7 @@ set_mtu () {
             log debug "$bridge MTU is $mtu"
         fi
     fi
-    if [ -n "$mtu" ] && [ "$mtu" -gt 0 ]
+    if [ -n "$mtu" ] && [ "$mtu" -ge 68 ]
     then
         log debug "setting $dev MTU to $mtu"
         ip link set dev ${dev} mtu ${mtu} || :
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:02:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:02:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390773.1630933 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wulvu-0000cu-Jn; Fri, 14 Aug 2026 07:02:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390773.1630933; Fri, 14 Aug 2026 07:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wulvu-0000cn-Fj; Fri, 14 Aug 2026 07:02:26 +0000
Received: by outflank-mailman (input) for mailman id 1390773;
 Fri, 14 Aug 2026 07:02:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+04c67277bee7a825e0be+8391+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wulvs-0000ch-0i
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:02:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wulvp-00BeEA-Q7; Fri, 14 Aug 2026 09:02:21 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+04c67277bee7a825e0be+8391+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7ebd74-8faa-0a2a0a5109dd-0a2a450abc4e-48
 for <multiple-recipients>; Fri, 14 Aug 2026 09:02:21 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+04c67277bee7a825e0be+8391+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7ebd7c-f2d2-0a2a450a0019-5a9b32229a3a-3
 for <multiple-recipients>; Fri, 14 Aug 2026 09:02:21 +0200
Received: from [2001:8b0:10b:5:84af:4c52:575c:6551]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wulva-00000004mKe-3eC2; Fri, 14 Aug 2026 07:02:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=GALK1RxRiXQgyLss6FcjsjjkccYATFPtuqlET9PD8TY=; b=YFu7T01jc4h7HwAPbbwrSDM0bc
	WcNQUwOsz0TxVSfzXGiQ2qZy4zksUd5M4j/juh5rqGI7A0dRFzJmBBo9Th4Q1yZ6+Mx5ksBuITnfs
	NlBh6PqgWyhtjZvWEt2f6fi+xWQZIgJ47N4Vku1sYoaxoVX8x1Fyy2bs9HyCPD2b7C75HoHiw18jG
	Ez38xozW6aHUO79EFj0kI9L4jeTsjUirMP/Hei6Mse7y9374JhEKZyAxP+wDmRbHaJkr/CJjvPrO+
	1RUkdqLrz2Rv0MssrWlQ7VYfrMMRIIgwBi0sAZROHJ0tND7pOEVyWmr+LD7hFGA6lb9WzIY6SoWLa
	W+h6tJWw==;
Message-ID: <c5c532e01309c8c73de2b0f393539b608c495f1f.camel@infradead.org>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when
 TSCs are offset from each other
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Fri, 14 Aug 2026 08:01:57 +0100
In-Reply-To: <anusv0DloFhLMMoW@google.com>
References: <ansywxh0VX5rtfWc@google.com>
	 <e256fa4af96e916ba30019cbba501fa896025fb0.camel@infradead.org>
	 <antQYJvRxJxOjtut@google.com>
	 <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
	 <antb01WqOrs-tztm@google.com>
	 <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
	 <ants4VjfAiblaWsl@google.com>
	 <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
	 <anuYNxD81OE3MrQw@google.com>
	 <5efe7a3914a3610ee00a487379caff84af6aa731.camel@infradead.org>
	 <anusv0DloFhLMMoW@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-B3TdkSrYLCzPBl0c8lic"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-4011c0/1786690941-506CECFC-2F5F2CD2/0/0
X-purgate-type: clean
X-purgate-size: 9074


--=-B3TdkSrYLCzPBl0c8lic
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 16:14 -0700, Sean Christopherson wrote
> I'm not totally opposed to a broader GET, but we should definitely get Pa=
olo's
> eyes on this sooner than later.

We've been saying that for two years. Shall I bring a net and a whip to
KVM Forum? Or Plumbers? :)

--=-B3TdkSrYLCzPBl0c8lic
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTQwNzAxNTdaMC8GCSqGSIb3DQEJBDEiBCDY4/ERSUTpTLyeS7nE9KdwXTjFRTBd
qp3APQTen0bgxTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAdtYfp6vz+Wp2i6L11jBiKHSOuC0jJGuae5eEUZCzyQoIfc6ebgPZ
DyQhxlkyKKrlKuUITksUbBbW2i0RHXRW0pxTub5+Zsv4jDRUFGiFBN6PFGJ5ybA+WRdTElV6jBHJ
X+0bopeQqgFqE4L4HILDbEiP9EF5phPOQEmrLy8SekTz1/TxhyR06WSmV0p8KqMwYfvf/SM8ccZl
bb1Jq0Ik7FcJvRNUXP27/SixzDMcpeEEfgLQPcp3YyVKS8FNftTfWidvpCVSerEYP2l1NyhEza1I
pBjMOzfTg++qug0vSa9yIdYKZnQ6Rpdy//ajHk7LX5M/tnRRND8CwUTPpkMiIispfZQDp7h1B42y
Cu5/xxOai0aMRXhATsJxl+FHQxmGxWbhMv1SX6IIN/CmU2UQtpqvp/JZX0w6zY2bSla0n8DbzqG1
nTHnHRTwwtSSUdgINxHxExZtVRoSM1E2mQj5WE62RneD9oIMA+hkuj/E7foXjJ+klbUEct1vGdt0
ct7qFiBj/gnxzY//JW4LCRSOtoO42kWYVzNOlhXmS0Qq13fsNH13Ni0wxtRQTigv1oMLKGpXWYkF
k7+TeAteGbmMhT9rEMKnWjYD4RQQ/BzVPzUjbshLgv1LRtennC4JL+J+jVaWSFqIa3QMj+jBDtAC
tbgUZzrtp6FWHVrGjSnQPMcAAAAAAAA=


--=-B3TdkSrYLCzPBl0c8lic--


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:27:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:27:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390785.1630941 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumKN-0004Zi-AU; Fri, 14 Aug 2026 07:27:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390785.1630941; Fri, 14 Aug 2026 07:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumKN-0004Zb-79; Fri, 14 Aug 2026 07:27:43 +0000
Received: by outflank-mailman (input) for mailman id 1390785;
 Fri, 14 Aug 2026 07:27:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+04c67277bee7a825e0be+8391+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1wumKL-0004ZV-9H
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:27:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumKJ-0038bI-OT; Fri, 14 Aug 2026 09:27:39 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+04c67277bee7a825e0be+8391+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7ec354-2eae-0a2a0a5409dd-0a2a450ae13a-26
 for <multiple-recipients>; Fri, 14 Aug 2026 09:27:39 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+04c67277bee7a825e0be+8391+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a7ec36b-f2d2-0a2a450a0019-5a9b32228eee-3
 for <multiple-recipients>; Fri, 14 Aug 2026 09:27:39 +0200
Received: from [2001:8b0:10b:5:84af:4c52:575c:6551]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1wumK8-00000004oGV-1zYP; Fri, 14 Aug 2026 07:27:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=XgbACiF0VbZQ3qTHeTv3h3pqeu4o7TCVK0pEMR7P+5Q=; b=n9M+1nUZlJt8tJ67mjvev4cQFd
	sYq7ADrcn5SliAXKKRtIA97idnKt8ci6mvXXyN8bTgh5qfyRpQU5AGTkiVfN+PaA6iXJiMBJpKgtp
	FLhBo8ORKw9nrU0IbeS7hyyAcGRmfl42TqhbAU3b++ilVruvKF7kaH7eJUmcSe1UTcGBl//vZeV4K
	iitnGvLVzwy6sMQO7msIbZWSFBS3t+3mO3wgyjvXCTBkbMPlAVsgcCyl4kkd1DqQmn4M9MBJQjxlY
	DbMRHQunsmo5E4hyR/GnixqWJcJP32keo2WGJgQthe3KV8IJuZpu20wk7N14HkUfciJhnk9YyhPYA
	DY5INBig==;
Message-ID: <4420099fedce20021d6cc5aeb1aa270c7951c552.camel@infradead.org>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Fri, 14 Aug 2026 08:27:19 +0100
In-Reply-To: <anuy6QxUVLcSSVCn@google.com>
References: <20260728144954.355376-1-dwmw2@infradead.org>
	 <20260728144954.355376-32-dwmw2@infradead.org>
	 <anuy6QxUVLcSSVCn@google.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-i/xjFyj0sIBrhyIUdgpg"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-4011c0/1786692459-4B2D8CFC-C7B73550/0/0
X-purgate-type: clean
X-purgate-size: 15349


--=-i/xjFyj0sIBrhyIUdgpg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2026-08-11 at 16:40 -0700, Sean Christopherson wrote:
>=20
> Invoking kvm_guest_time_update() here is probably a deal-breaker.=C2=A0 U=
pdating the
> master clock and other internal state is far from ideal, but should be ok=
.
>=20
> However, writing guest memory is not.=C2=A0 Specifically, dirtying memory=
 after the
> last KVM_RUN is a non-starter for many usecases, as is modifying state th=
at is
> visible via other GET uAPI (though I don't think that applies here?).=C2=
=A0 E.g. see
> commits:

Ack. Calling kvm_guest_time_update() is also *entirely* pointless. We
are in masterclock mode, by definition, as this ioctl only works in
masterclock mode. So kvm_guest_time_update() isn't actually creating
any new information; it just calculates the same per-VM tsc_shift/mul.
And kvm_vcpu_ioctl_get_clock_guest() could just use those directly.
Even better, it can do so *inside* the seqcount loop.

Fixup below (not amending commits while you're co-opting the tree, as
we'd both go insane). I'll push it to the top of=20
https://git.infradead.org/?p=3Dusers/dwmw2/linux.git;a=3Dshortlog;h=3Drefs/=
heads/kvmclock9-part2
on top of with the offset test which is already there.

>  And we'd probably want to build on my idea to report that
> KVM_RUN needs completion[*], but that'd be a good thing overall.
>=20
> https://lore.kernel.org/all/20250111012450.1262638-1-seanjc@google.com=C2=
=A0

Aha... *that* is why I found that lore thread open in my browser
yesterday; I was confused about how I'd got there. It's missing
KVM_EXIT_XEN btw. (Of which, KVM_EXIT_XEN_HYPERCALL is the only
subtype. I suspect Jo=C3=A3o originally expected that there would be more).

=46rom d2e54f439f0a5c0f2bddeaead916b23daedb2b2f Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@amazon.co.uk>
Date: Fri, 14 Aug 2026 07:56:58 +0100
Subject: [PATCH] fixup! KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate K=
VM
 clock migration

Make KVM_GET_CLOCK_GUEST stateless, never writing guest memory.

Invoking kvm_guest_time_update() from the GET ioctl writes the guest's
pvclock pages, and dirtying guest memory after the final KVM_RUN breaks
migration flows which have already completed their last dirty-log pass.

There is no need for it. The only outputs previously taken from the
vCPU's shadow pvclock were tsc_shift and tsc_to_system_mul, and in
master clock mode (which this ioctl requires; it returns -ENODATA
otherwise) those are identical to the master clock's own mul/shift:
both are computed by kvm_get_time_scale() from the same guest TSC
frequency, which all vCPUs share. Use ka->master_tsc_{shift,mul}
directly, which pvclock_update_vm_gtod_copy() precomputed for exactly
this kind of vCPU-less consumer.

The only remaining per-vCPU input is kvm_read_l1_tsc(), which is a pure
read, translating the master clock snapshot into the vCPU's own TSC
domain.

This also removes the -EBUSY case and the special handling of a vCPU
which has never run: the master clock state exists from VM creation,
so the pvclock can always be constructed. And it moves the reads of
tsc_shift, tsc_to_system_mul and flags inside the seqcount loop, where
they should have been all along: previously they could tear against a
concurrent master clock update.

A KVM_REQ_CLOCK_UPDATE pending on the vCPU is now left pending rather
than being consumed: the pvclock returned here is anchored to the
current master clock snapshot and describes the same linear function
of the guest TSC as the guest-visible copy, so there is nothing to
refresh. The guest's own pages are updated, as ever, only from KVM_RUN.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kvm/x86.c | 37 ++++++++++++++++---------------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8eb73e3ada66..4de98cc16751 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3460,27 +3460,22 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcp=
u *vcpu,
 static int kvm_vcpu_ioctl_get_clock_guest(struct kvm_vcpu *v, void __user =
*argp)
 {
 	struct pvclock_vcpu_time_info hv_clock =3D {};
-	struct kvm_vcpu_arch *vcpu =3D &v->arch;
 	struct kvm_arch *ka =3D &v->kvm->arch;
 	unsigned int seq;
=20
 	/*
-	 * If KVM_REQ_CLOCK_UPDATE is already pending, or if the pvclock
-	 * has never been generated at all, call kvm_guest_time_update().
-	 * Its only failure mode is transient (the TSC frequency of the
-	 * current CPU is momentarily unknown), so return -EBUSY to tell
-	 * userspace to try again.
-	 */
-	if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, v) || !vcpu->hw_tsc_hz) {
-		guard(srcu)(&v->kvm->srcu);
-
-		if (kvm_guest_time_update(v))
-			return -EBUSY;
-	}
-
-	/*
-	 * Reconstruct the pvclock from the master clock state, matching
-	 * exactly what kvm_guest_time_update() writes to the guest.
+	 * Construct the pvclock purely from the master clock state. The
+	 * master mul/shift are computed for the guest TSC frequency, which
+	 * in master clock mode is the frequency of every vCPU; only the
+	 * tsc_timestamp is per-vCPU, translating the master snapshot into
+	 * this vCPU's TSC domain via its scaling ratio and offset.
+	 *
+	 * Note, this deliberately does NOT invoke kvm_guest_time_update(),
+	 * which would write the guest's pvclock pages: dirtying guest
+	 * memory after the final KVM_RUN would break post-copy migration
+	 * flows. The pvclock returned here describes the same clock as the
+	 * guest-visible copy (the same linear function of the guest TSC),
+	 * anchored at the current master clock snapshot.
 	 */
 	do {
 		seq =3D read_seqcount_begin(&ka->pvclock_sc);
@@ -3490,12 +3485,12 @@ static int kvm_vcpu_ioctl_get_clock_guest(struct kv=
m_vcpu *v, void __user *argp)
=20
 		hv_clock.tsc_timestamp =3D kvm_read_l1_tsc(v, ka->master_cycle_now);
 		hv_clock.system_time =3D ka->master_kernel_ns + ka->kvmclock_offset;
+		hv_clock.tsc_shift =3D ka->master_tsc_shift;
+		hv_clock.tsc_to_system_mul =3D ka->master_tsc_mul;
+		hv_clock.flags =3D ka->all_vcpus_matched_tsc ?
+				 PVCLOCK_TSC_STABLE_BIT : 0;
 	} while (read_seqcount_retry(&ka->pvclock_sc, seq));
=20
-	hv_clock.tsc_shift =3D vcpu->pvclock_tsc_shift;
-	hv_clock.tsc_to_system_mul =3D vcpu->pvclock_tsc_mul;
-	hv_clock.flags =3D ka->all_vcpus_matched_tsc ? PVCLOCK_TSC_STABLE_BIT : 0=
;
-
 	if (copy_to_user(argp, &hv_clock, sizeof(hv_clock)))
 		return -EFAULT;
=20
--=20
2.43.0


--=-i/xjFyj0sIBrhyIUdgpg
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MTQwNzI3MTlaMC8GCSqGSIb3DQEJBDEiBCD9/V0PYjtIsN8hkvnIw00hfzTt7k0s
lNNxMG1uhXHS4zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAORes4VKcEBpHFpPKAayLdwwGcY9XJ7wh++CNMHtMuzPgbGwitPo8
2k3wRPfhhhdaVTJOLDz76c6e0JObweBrnSqc01SFBMvoW3Kp7f6NSUXqM6xAf8Vopuhp1HQXVXas
JoWZRF+hAORBrLtceADeVfqLN9+eytiTdZJ/7UTZm2W/7AuMEuYDPKywVhOyElb4/1Nj6IUXmKl3
izAKQ6YGUzU9brH4QOeKEkPgas/GwkYh1o1qs1Nvz2GzAKTVEMGXc2SATaAjzkKhdnBv0aIqueGD
tKnzzJUMjWy1wbXR1yQgwa6JRAXg6OpiEwPkyJnPHBcD0aFcHYRrtfWfzbJHWDqhXe5yiRCsx6BS
8/9lWwN/TK+kzof+Muij13Mf5sngjz0eIDiG5HsrRGodG7DXHhpVoWQ0v+i1iFjuFvJKedX3s6je
UKrEx59toY3Tpm15BaMEaesOEyYVkm4uub6EKk7PvcHjgPCuq0Imo1ZXRrPQNdDTfQ85kA8kBTzG
mNAjHPAj+ifKAXDxfptBCdFy5aVkzZHw46RJkc97H6WXjOYU4wAz7qFs4XfNm64aOa0enPSL6qUr
Nhou3rterPV7zZhHNVU2acZNb7zE95FkT9cBmEvD6zsLd8FrFb5VSSsin3a8Kbgb4WDAc/mNup1a
b3A3X/0eYkDc0iK6F8STZroAAAAAAAA=


--=-i/xjFyj0sIBrhyIUdgpg--


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:36:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:36:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390866.1630985 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumSL-0006q2-Gi; Fri, 14 Aug 2026 07:35:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390866.1630985; Fri, 14 Aug 2026 07:35:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumSL-0006pv-Du; Fri, 14 Aug 2026 07:35:57 +0000
Received: by outflank-mailman (input) for mailman id 1390866;
 Fri, 14 Aug 2026 07:35:55 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wumSJ-0006pi-K5
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:35:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumSJ-00Bjgv-0n
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 09:35:55 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec54d-2eae-0a2a0a5409dd-0a2a4505c0ee-40
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:35:54 +0200
Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec55a-4cb1-0a2a45050019-d155dd36dd93-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:35:54 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-47f7854678cso540045f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 00:35:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49988ae8b62sm30359785e9.5.2026.08.14.00.35.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 00:35:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786692954; x=1787297754; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=//W0xE+KXcv0hvKuNpwMOS45XeEjTCRExbM8a2HcfqM=;
        b=fYk0vl/cVeLZ3/aFFwBsHtPiXs5JlC8afGRVBeTPzv1uQ/weixAD2WYzT/SsrWZcTR
         yVor+4NVxQe7xSY/cDuaAKAxR/wmHlphU0+1v/hq4YfKjX9HLpIbLYh6XJ8o7VQ0Dbc2
         wLqIMIcEg657YLp3dcWjWgmsDMk0ZcDNKNcJzlM5UB6PgMPhkcYz8roNqaub8hBLZ3D4
         393Yyz6GBLG0byidkq/34XSOjz6Fa8UkH4GRimqdfl6NpJLvjjN7woIZugq4tXh65AkO
         rX9j2dzmEdfxKRPi399BJ52lduvXgSL9tsVva9WIBe67iTfDiGHg03uBAwDWi3eEc7Gw
         bbSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786692954; x=1787297754;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=//W0xE+KXcv0hvKuNpwMOS45XeEjTCRExbM8a2HcfqM=;
        b=Sc39tGwvRGb5qXC2buT1JQZL5y7pHRgKY6WmXgk7uF/WPjSJUdNpi+4hYFkY10MEIj
         9CawFFZyNFPgNAKlK85vE3JAJ/bDgBLV39k98CJfnbyyMoFJWTxVCN9NKeDZCJptc9SF
         Xr6/Fi/G87dCqlPzqIhf42n2SBE/zfSAU7keqUVTRbDaWZYdiIsS5PlBzDyMYy/fhiXB
         vIXIh5AWQr83uQiLRZO4nyAEnYpBy33ESdavjyIqRIPvl9zx2caZfE4mLh4AKVrrblyF
         18BqEuxx0sYxhI+hG5+as6ZnwCvFt0XMMkY7mYKKsAcnfJBDn1xykxTm2CKrStrj5S1B
         Q9lw==
X-Forwarded-Encrypted: i=1; AHgh+RqEIwL6Wj7q8wgurYYAWtqh1nf8Z/SiYKKPcQZgs0GvTSUzPpxjY4Kb2VTy9S5aE3lSzZeGENu/fyM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxRmoBF/OynrKWthd80GcAtK+iNyJUeE5cBqfT2nYEwU8KbvbNE
	9tpX0Ap4/wgUWUcknliE5y82AE7t8+SJC+q08LobEta87hmnDvHShAOYEONzxSVSIQ==
X-Gm-Gg: AR+sD11S2PUYuGHMaOQJpcjNFS/lNx8uDA8umXZ89HATHr5M4jBGVHjZ9Y6npux6/zQ
	DCAfWzRYauo3fc2vCLEsHHra/yFfIb4aej8WVAeV7ns0FhSpQNhwbYp0ZaolOe/Uf0rcNLlIgyd
	L9OJ2S1bSoAXaRSRIeXnnfFWqqbOGd44S2p2JkC0V3+iTsLlBSFbIkX47uVnK6r9x6zdP6ZU7Ma
	GY2yyD0zfoezS86+0m7tiagrtvE8L6HnJ/ultBuU4Hx2wgQUicdEDshkWX5kMfnhyw/uU3Hurmc
	aRcHnPcQZhqFdmLteubDH4SeK8AmohwLtNmwQUJq0qpQPs75MEPbSGebTOSJnxeEB6/5AM8ajcJ
	TlpEyoRc8KXeMB5dC7yh+igV4KztDFeBwLKHZO1MutWL4pBSZ/QZ/vKvcGjlI83VJ3MCbr+cmga
	LndQ1F5blIaD77afRa5c12CGaEyg/XXVYpCjmKMFSazrBSn1TlWIUef19i0KjH9VJBW5Zigj3Wm
	1sW1Kw/L2Wtk3FOqAaVFbDaUf8zFtaKDb2Rl5BTC40ZuFpgdmLm
X-Received: by 2002:a05:600c:6089:b0:499:86ce:465e with SMTP id 5b1f17b1804b1-49987941e38mr58172775e9.4.1786692953973;
        Fri, 14 Aug 2026 00:35:53 -0700 (PDT)
Message-ID: <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
Date: Fri, 14 Aug 2026 09:35:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@netscape.net>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1786692954-F68B62A1-71866F53/0/0
X-purgate-type: clean
X-purgate-size: 17648

On 14.08.2026 02:45, Chuck Zmudzinski wrote:
> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>> -- snip --
>>> To address this problem, this patch implements support for
>>> Intel IGD devices with an extended VBT and OpRegion version 2
>>> and higher which is required for most modern Intel IGD devices.
>>
>> First of all: Where's the spec of all of this?
> 
> Well, your first question is quite provocative. Certainly more
> social/legal than technical.

Well, it was very much meant to be technical. I've had a hard time following
what your new code does, and having a spec to hand would likely have helped.

> I presume by "all this" you mean code in this patch such as:
> 
> #define IGD_OPREGION_RVDA 0x3ba
> #define IGD_OPREGION_RVDS 0x3c2
> #define IGD_OPREGION_VERSION 0x16
> 
> which defines the offsets of the rvda, rvds, and version fields from
> the base address of the Intel OpRegion.
> 
> Also, I presume that "all this" includes the meaning of the 8-byte
> rvda value, the meaning of the 4-byte rvds value, and the meaning of
> the 2-byte version value.

"All this" certainly goes beyond this, i.e. also covering the intended
interactions.

> So my answer is as follows:
> 
> I do not have access to the official spec that defines "all this" but
> I do have access, as does the general public, to the Linux kernel's
> implementation of support for the Intel IGD from many sources such as
> git.kernel.org. The Linux kernel has enough accurate information about
> the spec of "all this" to provide very good support for the Intel IGD
> on bare metal.
> 
> To elaborate a bit more, the spec of "all this" can be derived from the
> Linux kernel code that supports the Intel IGD.

So you expect every reader to locate and decipher the underlying information
from a (afaik) pretty large piece of code in the Linux kernel? If the Linux
kernel sources are the reference, please can you at least provide pointers
into there?

>>> --- a/tools/firmware/hvmloader/config.h
>>> +++ b/tools/firmware/hvmloader/config.h
>>> -- snip -- 
>>>  #define PAGE_SHIFT 12
>>>  #define PAGE_SIZE  (1ul << PAGE_SHIFT)
>>> +#define tools/hvmloader/pci.c3
>>> +#define IGD_OPREGION_SIZE ((IGD_OPREGION_PAGES - 1) << PAGE_SHIFT)
>>
>> This is odd, and hence wants a comment.
> 
> Yes, I could add a comment, probably a long one, to explain this
> oddity. It is a problem of backward compatibility where we have a
> definition, IGD_OPREGION_PAGES, that is currently set to 3 both here
> in hvmloader and in the Qemu DM, but should be 2 because the OpRegion
> size is really exactly two pages but the current implementation set it
> to 3 because the host OpRegion is not always aligned on a 4k page
> boundary so three pages are needed to map the entire host OpRegion to
> the guest. I could re-write the patch setting IGD_OPREGION_PAGES to 2
> and avoid a comment here, but that would complicate the logic of how
> igd_opregion_e820_pages is calculated and probably introduce the need
> for comments in other places. 
> 
> I am open to suggestions about how best to handle the backward compatibility
> problem and the problem of ensuring compatibility between hvmloader support
> for Intel IGD passthrough and DM support for that same feature. For now,
> however, I am trying to keep what is applicable to the current implementation,
> and this odd value of 3 for IGD_OPREGION_PAGES is one of those things
> I am keeping for backward compatibility.

Personally I don't view breaking backward compatibility as an option. Hence
a comment is going to be needed, and preferably not an overly long one.

>>> +#define IGD_OPREGION_RVDA 0x3ba
>>> +#define IGD_OPREGION_RVDS 0x3c2
>>> +#define IGD_OPREGION_VERSION 0x16
>>> +#define IGD_OPREGION_MASK 0xfff
>>> +#define IGD_OPREGION2_SUPPORT_MASK 0x1
>>> +#define IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
>>> +#define IGD_VBT_SIGNATURE "$VBT"
>>> +extern unsigned long igd_opregion_pgbase;
>>> +extern uint32_t igd_opregion_e820_pages;
>>> +void intel_opregion_setup(uint32_t vga_devfn);
>>
>> Blank lines please ahead of the new #define-s you add and between those new
>> #define-s and the new decls.
>>
>> For igd_opregion_e820_pages I further cannot spot any use which would justify
>> the use of a fixed-width type; unsigned int will do, and will then be in line
>> with ./CODING_STYLE.
> 
> Ok I will pay more attention to CODING_STYLE. I know that libxl
> has a specific CODING_STYLE document. Is there a specific one
> for hvmloader? I do not see one in the tools/firmware/hvmloader
> directory. I assume the one that matters for hvmloader is the
> one at the top level of the Xen code source tree, not the libxl one.

Yes, hvmloader follows (better: ought to follow) hypervisor style.


>>> --- /dev/null
>>> +++ b/tools/firmware/hvmloader/intel_opregion.c
>>> @@ -0,0 +1,297 @@
>>> +/*
>>> + * intel_opregion.c: HVM Intel OpRegion setup.
>>> + *
>>> + * Leendert van Doorn, leendert@watson.ibm.com
>>> + * Copyright (c) 2005, International Business Machines Corporation.
>>> + *
>>> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
>>
>> What do these cover?
> 
> I am considering this new file to be a modified/derived version of
> tools/hvmloader/pci.c, so if I understand correctly this file needs
> to retain the copyright information of tools/hvmloader/pci.c. At the
> very least, the #include statements at the top of this new file which
> are from tools/hvmloader/pci.c are covered by these copyrights. I also
> consider the statements that are moved from tools/hvmloader/pci.c to
> this new file to be covered by these copyrights. IANAL, so to be safe,
> I include these copyrights even though the covered code is relatively
> small compared to the rest of the file.

Nowadays our preferred option is to omit such copyright statements
altogether, but we wouldn't insist on the omission. I further don't think
#include-s are copyrightable. 

>>> +    static unsigned long rvda_host;
>>> +    static unsigned long rvda_guest;
>>
>> Why static? The function can't be called more than once, if I'm not mistaken.
> 
> I think you are right that we only do the setup once so I will
> drop static here. I still think if I drop static I will want to
> initialize these to zero later, because (correct me if I am wrong)
> only static variables are initialized to zero if not explicitly
> initialized, and without either static or an initialized value,
> these would be initialized to some undetermined random value
> until explicitly set to the desired initial value. Of the two,
> I think that the more important one to intitialize to zero is
> rvda_host, because I use an initial value of zero for that variable
> to test for the case when we do not need extended VBT support.

Well, like all variables, these ones also will need to be sensibly
initialized. That's entirely unrelated to the use of static; all
static gets you in this regard is that there's implicit default
initialization. Yet that alone is no reason to use static.

>>> +    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
>>> +    /*
>>> +     * Tentative value for the number of pages to reserve
>>> +     * in the E820 map for the OpRegion and VBT.
>>> +     *
>>> +     * This will be the final value for the E820 map if
>>> +     * the device model lacks support for OpRegion 2 or
>>> +     * if the host OpRegion version is < 2 or if we never
>>> +     * allocate more pages in the E820 map for the VBT.
>>> +     */
>>> +    igd_opregion_e820_pages = IGD_OPREGION_PAGES;
>>> +
>>> +    /*
>>> +     * Read the value the device model is initialized with.
>>> +     * If the device model supports OpRegion 2, it will
>>> +     * return the host IGD OpRegion address. If not, it
>>> +     * will return 0. If the device model does not support
>>> +     * OpRegion 2, the device model expects us to give it
>>> +     * the address to which it will map the OpRegion in the
>>> +     * guest and then expects us to do nothing more to setup
>>> +     * the OpRegion, so that is all we will do in that case.
>>> +     */
>>
>> Hmm, exposing the host opregion to a guest certainly feels like an issue.
> 
> Well, that is how it is now. I am only retaining it to maintain backward
> compatiblily with DM versions that do not support the extended VBT and
> OpRegion 2+. My previous comment about backward compatibilty and DM
> compatibility also applies here. If we don't worry about that, we can do
> away with any cases where we are permanently mapping the host opregion to
> the guest and implement this new approach of always exposing a copy of
> the OpRegion and VBT to the guest instead.

How does "permanently mapping" matter? hvmloader runs inside the guest, so
exposure just to copy the data isn't any better in terms of this being a
layering violation. The more correct thing to do might be for the DM to
put in place a copy before the guest (i.e. hvmloader) even gains control.
(How in turn the DM would learn of the contents of the opregion is a
separate question then.)

>>> +    const uint32_t igd_host_opregion = pci_readl(vga_devfn,
>>> +                                                 PCI_INTEL_OPREGION);
>>> +    if ( !igd_host_opregion ) {
>>
>> Nit (style) Brace placement (throughout).
> 
> Ok. I see this is not the proper coding style.
> 
>>
>>> +        printf("device model lacks extended VBT "
>>> +               "support. Continuing with legacy support only\n");
>>
>> This message can easily confuse / worry people. (If it was to be kept, it
>> would also need style adjustment.)
> 
> I think some message is needed here to indicate the incompatibility of
> versions of the DM that do not support the extended VBT with versions
> of hvmloader that do, especially if we are not going to worry as much
> about the backward compatibility / DM compatibility problem I mentioned
> multiple times in previous comments above.
> 
> This message could encourage upgrading the DM to a version that supports
> the extended VBT instead of just giving this scary notification.

But someone expecting legacy behavior could be misguided by the message
(e.g. into wondering whether there's something wrong.)

>>> +    const uint32_t igd_host_opregion_page_offset =
>>> +                   igd_host_opregion & IGD_OPREGION_MASK;
>>
>> I think like in the hypervisor we don't want to mix declarations and
>> statements just yet.
> 
> The only way I could separate the declaration from the statement would be
> to drop the const modifier because if I do:
> 
>     const uint32_t igd_host_opregion_page_offset;
> ...
>     igd_host_opregion_page_offset = igd_host_opregion &
>                                     IGD_OPREGION_MASK;
> 
> The compiler will report an error. If I drop the const modifier from
> the declaration, the compiler will not report an error but I lose the
> protection the compiler gives me from making mistakes by modifying a
> variable's value that should be constant.
> 
> I am not a C guru but some research indicates that while it is legal in
> C to declare a variable with the const modifier without also assigning
> it a value at the same time with a statement, it is not recommended to
> do this because the variable will be initialized with some undefined
> random value that cannot be changed because we used the const modifier
> in the declaration. This implies strict enforcemnt of the rule "we
> don't mix declarations and statements" results also in the corollary
> rule "we never use the const modifier for variables in C."

Indeed we rarely use const on variables (or parameters) themselves. It's
primary use is on pointed-to types.

>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>>> +                IGD_OPREGION2_SUPPORT_MASK);
>>
>> This looks to imply qemu is the only possible device model.
> 
> Yeah, this is an issue. Other device models that intend to support
> the Intel IGD with hvmloader will also have to be compatible with this.
> It would be easier if we did not have to worry about backward
> compatibility and supporting what we had in the codebase for many years
> in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
> in that case. Instead, we would just completely deprecate all previous
> implementations of the Intel IGD passthrough feature in both hvmloader and
> the Qemu DM as unsupported. So my previous comments about backward
> compatibility apply here again.

As said, I don't think backward compatibility can be dropped. My comment
also didn't really mean to hint in that direction. Instead I was wondering
in how far, even if perhaps by only a few #define-s, the necessary
interfacing couldn't be put down in a public header, for any DM to consume.

>>> +    printf("guest OpRegion tentative "
>>> +           "address: 0x%x\n", igd_guest_opregion);
>>> +
>>> +    if ( !verify_opregion(igd_guest_opregion) ) {
>>> +        printf("error: IGD OpRegion signature "
>>> +               "not found.\n");
>>
>> No full stop in messages please.
> 
> Would it be OK to just get rid of the error message here?

That would then leave ...

>>> +        BUG();

... an un-annotated BUG(), which generally isn't very nice.

>>> +    }
>>> +   --snip --
>>> +        rvda_host = 0;
>>> +    }
>>> +    const uint32_t rvda_host_page_offset = rvda_host &
>>> +                                           IGD_OPREGION_MASK;
>>
>> Why host_page_offset here when ...
>>
>>> +    const uint32_t rvds = *(uint32_t *)(opregion_scratch +
>>> +                                        IGD_OPREGION_RVDS);
>>> +    const uint32_t rvds_page_offset = rvds & IGD_OPREGION_MASK;
>>
>> ... it's just page_offset here, and when further you use it below to set
>> rvda_guest?
> 
> The size of the VBT, rvds, is the same on both host and guest, so we do not
> need to specify host or guest, but the base address of the VBT, rvda, is
> not the same on the guest as it is on the host, so we need to specify which
> one for rvda. I can change this to rvds_host_page_offset because it is
> not wrong, but it might be confusing because I use that value later on
> for computations involving the guest also.

Why not simply drop the "host" infix, when it's not relevant?

>>> +    printf("VBT size: 0x%x\n", rvds);
>>> +
>>> +    if ( !rvds || !rvda_host ) {
>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>> +        rvda_host = 0;
>>> +    }
>>> +    /*
>>> +     * Write rvda_host as 2 successive 32-bit values
>>> +     * to communicate location of the VBT to the device
>>> +     * model. If rvda_host is not 0, The device model
>>> +     * unmaps the OpRegion and eventually maps the VBT
>>> +     * after we also write the guest address where the
>>> +     * VBT will be mapped.
>>> +     *
>>> +     * If we send rvda_host = 0 to the device model, it
>>> +     * will assume we do not need OpRegion 2 support and
>>> +     * it will not unmap the OpRegion.
>>> +     */
>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>> +               (uint32_t)rvda_host_upper_32);
>>
>> Why would you need to communicate a host property to the DM?
> 
> The DM cannot access the host rvda value because it is only accessible
> from the host kernel, and the DM is only a user-space process on the host.

I don't follow this: Anything the guest can access should also be accessible
by its DM.

>>> +    /*
>>> +     * Update the number of pages the device model
>>> +     * needs to map for us to get a copy of the VBT.
>>> +     *
>>> +     * N.B.: Here, igd_opregion_pgbase is really the page
>>> +     * base of the location where the device model will
>>> +     * map the VBT.
>>> +     */
>>> +    uint32_t vbt_pages_needed = rvds >> PAGE_SHIFT;
>>> +    if ( rvds & IGD_OPREGION_MASK )
>>> +        vbt_pages_needed++;
>>> +    if ( vbt_pages_needed > igd_opregion_e820_pages ) {
>>> +        igd_opregion_pgbase = mem_hole_alloc
>>> +                              (vbt_pages_needed - igd_opregion_e820_pages);
>>
>> Nit: Indentation.
> 
> Ok. It should always be a multiple of four spaces, I presume. I admit I did
> not check that.

Not quite. Within a wrapped expression, you need to determine what I like
to call the "anchor point". In a function call that's the start of the
function name. The wrapped part of the expression would then start one
extra level (4 spaces) deeper than the anchor point. Things are different
when there are pending open parentheses: There the wrapped part of an
expression starts with as many extra spaces as there are pending open
parentheses, with the outermost pending open parenthesis being the anchor
point. E.g. (taking the example above and adding extra wrapping in the
function argument expression just for demonstration purposes):

        igd_opregion_pgbase = mem_hole_alloc
                                  (vbt_pages_needed -
                                   igd_opregion_e820_pages);

Or alternatively

        igd_opregion_pgbase =
            mem_hole_alloc(vbt_pages_needed - igd_opregion_e820_pages);

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:37:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:37:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390876.1630995 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumUE-0007NM-RF; Fri, 14 Aug 2026 07:37:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390876.1630995; Fri, 14 Aug 2026 07:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumUE-0007NF-OL; Fri, 14 Aug 2026 07:37:54 +0000
Received: by outflank-mailman (input) for mailman id 1390876;
 Fri, 14 Aug 2026 07:37:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wumUD-0007N9-MK
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:37:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumUC-001upz-LB
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 09:37:52 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec5c2-8faa-0a2a0a5109dd-0a2a4502dbe2-36
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:37:49 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec5cd-6ca4-0a2a45020019-d155dd35c539-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:37:49 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so422451f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 00:37:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f200752sm6220606f8f.1.2026.08.14.00.37.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 00:37:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786693068; x=1787297868; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=q5ywdEJtyMtVKN+jZ3Sl6j/K2PxgNHzvC0RucKg8v/4=;
        b=IZnIZSqSMoy6s/9jc1DwpiMUbXP6ZrXvS7DGtX7VhClW+ICT+wppgYq6s19P2mpsMW
         7V+OlXcNovDqnQupry+fFVe4ixS57PfSeK0kC+o5SAL/aOBLQTC8jZLFPbzQS6VQT5F6
         iYo4Rjgy+Z4vsVs6hWrvQ4d19ZOzVPHZZP0X9exVS2lQisLb8bTPFhPgXfWgX68rcMDE
         31Q5z8THS+3u60R0ZKRd+k1mGnut8YiqgBP85+YOmVewr1DTu2KK3+0OgYFmsUn9osCk
         InMeV6qOZ2snyLTqm0YiyxEpWgBdC9gq8imLu8fF0/6f7hj5xyeJNPgRessPY8ws9Vo+
         zapQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786693068; x=1787297868;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=q5ywdEJtyMtVKN+jZ3Sl6j/K2PxgNHzvC0RucKg8v/4=;
        b=EsapNLRgsoq7zL8qez/OXii/noThzSQjh8o5pxMHden5MJaojC/y0g11iEq09IbRFr
         xYMk7dDsx33lu4x6PxoxuOuz6/6R2so7izb9JiQlLDv72GD6otwwMxYSoWdCoaJ3rk4L
         jTA2uHx2adlJAPosVALe0vMvm8qABnxKotIE5bucgE+eGWREy96xOFxvquYV+blN/gBK
         ySc2puFxQxuQ1eDJ+V3WbaGnAcrzRb49wGDFSpGyQCYgFkzZ20XqGDBjQ9utwRE8EuPi
         3EsmTu4IcnpKWqr4VX+3Enh6MqzVQPtALVNplY0LBCtW5ayh1+3GE5SLh/in2h+XyWpM
         IZKw==
X-Forwarded-Encrypted: i=1; AHgh+RqBISP12bHA50WsZlbVfcxMtDOJlGghakee+Lynn4geo9EPcUjVipktawXSpjLOxXbM6NwrAbIs6mo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzLiXke/oYVE2d4w1vXI9ezmM83LRswCw6dYA3i96HeepI1sBJu
	jLNA5BFoVL0PRxH0vr+6AnLXV9+DMDzVj2lvDiuJlWvf9ORV/mat55NJ6YJ8Y41ycA==
X-Gm-Gg: AR+sD11d2fZOktHm795+GGIVo/I8+ySUs5kNYo8/O5bQ/adurncxoM9nuQ4Ko3Yii8R
	thE5JlIdIpenjMbd61d5Drgx7Iy4D3j5SEr9Z2rTWutTcD9oNV5+G3CJ6WqsjnJF7AP3eDss2kS
	nSfxDVWZQpT2FTD+8FNpLtoPy2LGTTWOaM4HmtH+8B0jIjG5M7zFXYKMrx1Y7pEe6Vqt0iW8DOU
	LY8hvJc8T5xyLGc2kWaefqqpoA7mHd94thLqjPUGuH3Gk/JnJc4gYEBjDlm6HbobRCWfCLUsC/D
	tllfLoeD/78qWJy5hXE2KVdELPech+mBpS67Qnue65aa+dfEXyWJzQN6FRv7werY2ZsM14p4uVZ
	VPlSx1cFiAqSjJ8BggKiG7IlT7e/NzQBv112cId8WQFkn4HzIUA3+254XoxDE5MWDDL9c+IJu8z
	G1+bmR8rA9cLIpE9wmwv7jKxUshXlkiuxTeGvYSCS7e7NQO2PJ77waPZRO3730OKzjy3tt2ahA8
	YwI1xHD1lfm3VDbhAe4qKbTZ9qVthijD7VOEx64Ul3DVnnYTgMVn9VpPGy7I14=
X-Received: by 2002:a05:6000:41ee:b0:481:51ce:542f with SMTP id ffacd0b85a97d-4816076f7a6mr5190548f8f.21.1786693068585;
        Fri, 14 Aug 2026 00:37:48 -0700 (PDT)
Message-ID: <8cecaca1-f717-423d-a852-8378599a478d@suse.com>
Date: Fri, 14 Aug 2026 09:37:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs
 without a shared page
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <ed247fcc594346ad20a3d12e5d49c8f48ba6792a.1785836421.git.oleksii.kurochko@gmail.com>
 <3bd3a9d5-444b-4bb5-9a4c-8353f98802a9@suse.com>
 <31674604-d595-4706-b5b6-cb3e9ed4d148@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <31674604-d595-4706-b5b6-cb3e9ed4d148@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786693069-F2EB32AC-C348E66F/0/0
X-purgate-type: clean
X-purgate-size: 5650

On 13.08.2026 19:03, Oleksii Kurochko wrote:
> On 8/13/26 4:54 PM, Jan Beulich wrote:
>> On 04.08.2026 17:47, Oleksii Kurochko wrote:
>>> @@ -1324,9 +1359,15 @@ int evtchn_reset(struct domain *d, bool resuming)
>>>           rc = -EAGAIN;
>>>       else if ( d->evtchn_fifo )
>>>       {
>>> -        /* Switching back to 2-level ABI. */
>>>           evtchn_fifo_destroy(d);
>>> -        evtchn_2l_init(d);
>>> +
>>> +        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
>>> +            /* Switching back to 2-level ABI. */
>>> +            evtchn_2l_init(d);
>>> +        else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
>>> +            evtchn_fifo_init_ops(d);
>>> +        else
>>> +            evtchn_none_init(d);
>>
>> This being the same as ...
>>
>>> @@ -1625,7 +1666,13 @@ void evtchn_check_pollers(struct domain *d, unsigned int port)
>>>   
>>>   int evtchn_init(struct domain *d, unsigned int max_port)
>>>   {
>>> -    evtchn_2l_init(d);
>>> +    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
>>> +        evtchn_2l_init(d);
>>> +    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
>>> +        evtchn_fifo_init_ops(d);
>>> +    else
>>> +        evtchn_none_init(d);
>>
>> ... this: Maybe have a small helper (evtchn_preinit()?), to reduce the
>> duplication? Would require comment updates then as well.
> 
> I think then it will be needed to fix a lot of comments. My suggestion 
> is the following:
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 0911808fe861..809638ce4bfd 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -71,10 +71,23 @@ static void evtchn_none_init(struct domain *d)
>       d->evtchn_port_ops = &evtchn_port_ops_none;
>   }
>   #else
> -/* Declaration only; the calls below are DCE'd unless both configs are 
> off. */
> +/*
> + * Declaration only; the call in evtchn_preinit() is DCE'd unless both
> + * configs are off.
> + */
>   void evtchn_none_init(struct domain *d);
>   #endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */
> 
> +static void evtchn_preinit(struct domain *d)
> +{
> +    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
> +        evtchn_2l_init(d);
> +    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
> +        evtchn_fifo_init_ops(d);
> +    else
> +        evtchn_none_init(d);
> +}
> +
>   /*
>    * Lock an event channel exclusively. This is allowed only when the 
> channel is
>    * free or unbound either when taking or when releasing the lock, as any
> @@ -1359,15 +1372,9 @@ int evtchn_reset(struct domain *d, bool resuming)
>           rc = -EAGAIN;
>       else if ( d->evtchn_fifo )
>       {
> +        /* Switching back to the default ABI. */
>           evtchn_fifo_destroy(d);
> -
> -        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
> -            /* Switching back to 2-level ABI. */
> -            evtchn_2l_init(d);
> -        else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
> -            evtchn_fifo_init_ops(d);
> -        else
> -            evtchn_none_init(d);
> +        evtchn_preinit(d);
>       }
> 
>       write_unlock(&d->event_lock);
> @@ -1666,12 +1673,7 @@ void evtchn_check_pollers(struct domain *d, 
> unsigned int port)
> 
>   int evtchn_init(struct domain *d, unsigned int max_port)
>   {
> -    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
> -        evtchn_2l_init(d);
> -    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
> -        evtchn_fifo_init_ops(d);
> -    else
> -        evtchn_none_init(d);
> +    evtchn_preinit(d);
> 
>       d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX);
> 
> diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h
> index c8ee09807008..156514fefff6 100644
> --- a/xen/common/event_channel.h
> +++ b/xen/common/event_channel.h
> @@ -71,8 +71,8 @@ static inline void evtchn_fifo_destroy(struct domain *d)
>   #endif /* CONFIG_EVTCHN_FIFO */
> 
>   /*
> - * Declaration only when !CONFIG_EVTCHN_FIFO; the (dead) calls in
> - * evtchn_init() and evtchn_reset() are DCE'd in that case.
> + * Declaration only when !CONFIG_EVTCHN_FIFO; the (dead) call in
> + * evtchn_preinit() is DCE'd in that case.
>    */
>   void evtchn_fifo_init_ops(struct domain *d);
> 
> diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
> index 3b6e619c5278..f11c4c16efa3 100644
> --- a/xen/common/event_fifo.c
> +++ b/xen/common/event_fifo.c
> @@ -423,10 +423,9 @@ static const struct evtchn_port_ops 
> evtchn_port_ops_fifo =
>   };
> 
>   /*
> - * evtchn_fifo_init_ops()'s only call sites are in the
> - * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branches of evtchn_init() and
> - * evtchn_reset(), which are never reached on HAS_SHARED_INFO=y builds
> - * because of DCE.
> + * evtchn_fifo_init_ops()'s only call site is the
> + * IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branch of evtchn_preinit(), which is
> + * never reached on HAS_SHARED_INFO=y builds because of DCE.
>    */
>   #ifndef CONFIG_HAS_SHARED_INFO
>   void evtchn_fifo_init_ops(struct domain *d)
> diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
> index 930190054cf0..595dedf0792c 100644
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -211,7 +211,7 @@ static bool evtchn_usable(const struct evtchn *evtchn)
> 
>   void evtchn_check_pollers(struct domain *d, unsigned int port);
> 
> -/* Close all event channels and reset to 2-level ABI. */
> +/* Close all event channels and reset to the default ABI. */
>   int evtchn_reset(struct domain *d, bool resuming);
> 
> Does it look good for you?

Yes, thanks.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:48:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:48:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390889.1631004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumeJ-00018g-Qm; Fri, 14 Aug 2026 07:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390889.1631004; Fri, 14 Aug 2026 07:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumeJ-00018Z-Nm; Fri, 14 Aug 2026 07:48:19 +0000
Received: by outflank-mailman (input) for mailman id 1390889;
 Fri, 14 Aug 2026 07:48:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wumeI-00013c-J2
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:48:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumeH-00Blrz-8F
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 09:48:17 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec82a-e002-0a2a0a5209dd-0a2a4501c954-44
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:48:17 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec83f-5984-0a2a45010019-d155802af1a7-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:48:17 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so7557645e9.3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 00:48:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49987b2e6b6sm31853825e9.3.2026.08.14.00.48.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 00:48:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786693695; x=1787298495; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=u8USBfCyP2EQaBisKnXCIX7wTTLpE4ngLpwbAIM3xM8=;
        b=Vo2h456eU1SElh+dCcGGVqAKzwCizgjk4h1kwi+HFAe849pvdzSNwOX5zQOevRjOjL
         Nfr3+ci6UDmQux/IXs1mXr4Hv0zRGXh91ceANR+RyA9Otqu91pX6zU0VrZYljMSIsS6y
         VAcW6WWgbyYNfli1RPIl+C39jdIv1Vs5xH9X/enCSzmjeuPXmflxS05Sr3NF/QSVQnAK
         HrH6QKd/2YfUQy3j+kjUhydUTKSALv1/IwWnaVGaOPzI1xTywgxSbAGDdOQ5DQDorjRN
         4Az+NwitN0e54lc5xhzlF23ard4OO5LjNErrkRgnq3KJDHNKFjn+5FlJMn1fIAnIx2Ss
         D8bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786693695; x=1787298495;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=u8USBfCyP2EQaBisKnXCIX7wTTLpE4ngLpwbAIM3xM8=;
        b=SKWgVHY1skT4PL5UViUdGiuXxsnkMIHZNKig2zCKY1JJGt3nq5VkOVREqVn4yln+8+
         IGrJNcXbJIdX+vSvTv3H7vlS3hmPy2cpoKz+uEpeiMlo/p3ymeAQ9dcgu2oAUOTO6+DK
         yAovWESti2fmuxnt5in75VePg3M2NGNGRPEbCp3JPatCwhFBpiSbY7pogsVhYd7Q12FO
         GaOn3hNJcJKN2pxaDDp1earP2AFAU9ieDOHwS0Y9YQOOFNMyR5nqI7LZ+CYlG14yfcRC
         M1JY3E+/oirTnPGqBVdYxsW+Z53UW50mXMD9rF8pFC6Su9oa3m4w5Jp61VOmq+fxAfwU
         WywQ==
X-Forwarded-Encrypted: i=1; AHgh+RqWiQzEbW3bpY5nNAWUfgOG7Ehep8YIpoKa8PfKr8z50mv1Gl+92zQe1ULwk6+2585/gnAuOJCI3us=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcqAlD+4QMaH7nK7ssmEihbzqPeTDsz4LJsCQ/HffhwmKa7+5M
	nZd9+GbmRbk8K+I1xyfyn38A+lHRL4ZHBAj9pun7x6aRJVyPrhzZBkMmluveJoA691pBK6jAkdU
	2d5NdAw==
X-Gm-Gg: AR+sD12hW1U8jzvVbxT8C1LITWMrK10cI+wHshOZxsIqmCu6tIbgd8GFviKCxSw46SQ
	9fvh2OKO3JzoI+TMWCVh0AiOP7kMbWWXgWXVBpoUEWA6I/qjflrLe5dl6kMQXjcsz7ys9W2HAgs
	QCiQ0dYAwm1oLb4i5UuZcjWKF10EbmVeHeQl1kD9mrvffyM5JypNnLBzf3XWs0azHDkANgiWB7O
	zDl1PkIlOHuf1rkVRAK2OpUYCFCIZKJ0J8es9qyzsk7DUzIC06O9TiWlJo3myaPJgZ+Gtefy6Z3
	xxYIC0Xp+FjCL2wvVAFktBu0lCjQDW0ocSL5Q1p8LLYLpdh8dZnX4AqXaitzZGNyApXx0Ej+nZU
	rXAU+NdR6MzgysXFYKZApyWaHKzyhnaDz5cp+e6dfOpDCr72WaiAI0CQiLBxwiugVXc1R0eTy/M
	YPD3mLaKdWUsA6lvtsudtyolj1itJ8VDx7yzML8hUVDxAxFtHRHoqQQHG20XHPClj5cptjvSfDu
	hBfzoU9o41Ud4Zi5quDFnliqPzh8i6qDVm0pIHcQbYvgo5cK1vp
X-Received: by 2002:a05:600c:8714:b0:499:8704:242c with SMTP id 5b1f17b1804b1-499878ca13bmr61276965e9.0.1786693695466;
        Fri, 14 Aug 2026 00:48:15 -0700 (PDT)
Message-ID: <50553714-94be-42f7-b8db-f176cb328059@suse.com>
Date: Fri, 14 Aug 2026 09:48:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: tools/hotplug: fix invalid frontend path for set_mtu
To: James Dingwall <james-xen@dingwall.me.uk>
Cc: Anthony PERARD <anthony.perard@vates.tech>, xen-devel@lists.xenproject.org
References: <20260814060441.923061-1-james-xen@dingwall.me.uk>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260814060441.923061-1-james-xen@dingwall.me.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786693697-1EC61757-CB8A7AE3/0/0
X-purgate-type: clean
X-purgate-size: 563

On 14.08.2026 08:03, James Dingwall wrote:
> This is a resubmission of patches previously discussed in this thread:
> 
> https://lists.xen.org/archives/html/xen-devel/2022-04/msg02209.html
> 
> It appears they fell down a crack after review and never made it to git.

Indeed, and I think you could validly have retained Anthony's R-b on patch 1.
Now that you've re-sent without it, I think it's better for him to re-supply
the tag. He's now also in the position to actually commit the change.

I can't spot any earlier R-b for patch 2, though.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:52:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:52:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390898.1631014 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumiA-0002rA-Ax; Fri, 14 Aug 2026 07:52:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390898.1631014; Fri, 14 Aug 2026 07:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumiA-0002r3-6K; Fri, 14 Aug 2026 07:52:18 +0000
Received: by outflank-mailman (input) for mailman id 1390898;
 Fri, 14 Aug 2026 07:52:16 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wumi8-0002qx-FE
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:52:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumi7-008mGh-S4
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 09:52:15 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec91a-bab6-0a2a0a5309dd-0a2a4506e2b8-48
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:52:15 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ec92f-195a-0a2a45060019-d155dd2ee4e3-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:52:15 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47f703a9d05so466336f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 00:52:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f21a24esm6871979f8f.11.2026.08.14.00.52.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 00:52:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786693935; x=1787298735; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ZFLNgY0JxYKIiTRaUMoV3Afc2p0SQXaOzr8uKvrRO8o=;
        b=VuoYyh+7er/xjfGuNx8MCFfVJl33JV4MmlPeC1rtGVfPB0q8jQ3NjFWtfTA0TBC/e8
         DSpFr/K0EagkY0lUOjzQAwPkudJqXfS4g/oSXIUvrFw9/Bnpr5vRofol/UD+5V3gfnio
         eyTeVfvYD7UPnYem5rJ58NHL5lhHxPBM7q7NSTRSye6IBnBEnYQrtACjlzTF87Ywmti8
         Y4ppJu2Y9G+An7YoxiRMp3qAioPPRePIB4URydYgFTUx9dTz312lmL/Oo+FpvYrOom/h
         Sp8wTqr9Rbp0e/16XQ9oOU3j0XSQGy8tl5IaTX7fOLgZeCoj6QSH7xJQteULzzNTGdFC
         i8dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786693935; x=1787298735;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ZFLNgY0JxYKIiTRaUMoV3Afc2p0SQXaOzr8uKvrRO8o=;
        b=J5PMXMfzF0m3dbrYKczNRQ9RJ9HINXRlOlgOA2WG+F3W8X3Y2FOMfH+nnmVd8bWXYV
         NLFuuEBCxTe22HxaLRocX9CkY/ubeMZEITC5clcz9NFfHtFZfEWVqd5zB0vM0mdo5lKq
         Ml36OCk8YccuqSvoIzAE4IIrD2Tn7CaqLv7SKZdb7Eqcv08ErDFEu+sC1RtL4HKFVxGf
         anwkis9qR1aoTV5Jx3nHuyfZlPVbjAtFcWIiiM/3F0cRXtk7NDsx1Xh9cnlvxcCUo2uf
         5ApfactHnRD3g6imioxCFiPjEbOJ5mcWuVq3vmpoy9kDo6tC4fxzqmqEuxhCsMJxZpMN
         57kg==
X-Forwarded-Encrypted: i=1; AHgh+RrLNPL4xsfHIFKsA0+oI2pzWg/k3s/KVYxLB/t21ij637YP/jnARdaHeyIWBHvS31iiKLd1q6AOoQw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+Gs0uv763OqOv6QL+g467nTHFzy9b87+FM2ZVMHdVg1BWbtFG
	z3mDkC2TI5xS7Sh2FFE3FhO9mdG6vraTEIGEWjy3I79bxZs49swniWmAFOwdF63rez9WOqlLRE+
	LxezxFw==
X-Gm-Gg: AR+sD101ZVyRq8PkvFUUyiZ1M7GzaE233x8VIwmSnkapIvIdLnFD1Ebok6HrBCPUKH6
	yq6Aq3ELs0nVxfZFLuHBgd1cZiakcab+uKFquv4huP4P+s1RJD69AUBofNv+ADSLzVUjpUhl97e
	6beXSYjE/FG+Cj6gb32gs/78VW00aLA9PLEXsDI1wzDLwPwKkxRBAJXd1OsxDXrHEEqzf6F71C4
	WwzJ4IICG4TOzSGd/mSDFvAmk0zK76trS7RQKXwzeT3py8kzvPXs3hVq20DvfGVtDcdo5Put/op
	C4kgXgjFg3mLCG2Yx8mRTGoyR08ESTlYTZDn1mhlShKKwWB06QoCrsoBvFmakU+3Qm8a7obI84m
	MlZasQ/JKvdjx8hCfSOoPxlNZ7hvtccOOHVk5TXEvYnGH+/5V0No9AIJt8Pb+YssnPLJZ6B+kXm
	bLP2X+Rf2E1xspeQlIlkhNkZjTMJPq6gvNzUuh+Vd1xIx5iwdSr3dEHKiu8ng7ikmiXKHCIerqF
	a42MyIHPEQANb1xojVnTkmTNm+1UCh8LKSNGFY14Clco6WXMfs+
X-Received: by 2002:a05:600c:4f56:b0:499:7312:2d5f with SMTP id 5b1f17b1804b1-4998799eb7dmr51887875e9.19.1786693935258;
        Fri, 14 Aug 2026 00:52:15 -0700 (PDT)
Message-ID: <a34ad4ec-28dc-4494-8798-f2a6b0fe7bae@suse.com>
Date: Fri, 14 Aug 2026 09:52:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] tools/console/daemon: fix log_dir memory leak in
 xenconsoled
To: Andrew Mbugua <andrewprecious388@gmail.com>
Cc: anthony.perard@vates.tech, xen-devel@lists.xenproject.org
References: <20260813212724.2607832-1-andrewprecious388@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260813212724.2607832-1-andrewprecious388@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786693935-F560A77B-02A071B9/0/0
X-purgate-type: clean
X-purgate-size: 1809

On 13.08.2026 23:27, Andrew Mbugua wrote:
> Valgrind reports that 21 bytes are "still reachable" from the (XEN_LOG_DIR "/console") allocation:
> 
> HEAP SUMMARY:
>     in use at exit: 21 bytes in 1 blocks
>     total heap usage: 9 allocs, 8 frees, 4,799 bytes allocated
> 
> Since the dynamic memory allocation for the default log directory path happens before the process
> forks into the background, the parent and intermediate processes exit during daemonize()
> with the memory still reachable.
> 
> Move the strdup() allocation down below the daemonize() block. This ensures only the final
> background daemon allocates the default path, matching the lifetime of the free(log_dir)
> cleanup loop at the exit of main().
> 
> With this change, Valgrind reports a clean heap summary
> 
> HEAP SUMMARY:
>     in use at exit: 0 bytes in 0 blocks
>     total heap usage: 8 allocs, 8 frees, 4,778 bytes allocated
> 
> Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>

Looks all plausible (albeit a little unnecessary, as memory is freed at
program exit anyway), except that ...

> --- a/tools/console/daemon/main.c
> +++ b/tools/console/daemon/main.c
> @@ -181,10 +181,6 @@ int main(int argc, char **argv)
>  		}
>  	}
>  
> -	if (!log_dir) {
> -		log_dir = strdup(XEN_LOG_DIR "/console");
> -	}
> -
>  	if (geteuid() != 0) {
>  		fprintf(stderr, "%s requires root to run.\n", argv[0]);
>  		exit(EPERM);
> @@ -201,6 +197,10 @@ int main(int argc, char **argv)
>  		daemonize(pidfile ? pidfile : XEN_RUN_DIR "/xenconsoled.pid");
>  	}
>  
> +	if (!log_dir) {
> +                log_dir = strdup(XEN_LOG_DIR "/console");
> +        }
... can you please not screw up indentation? All you want is to move the
code, without converting tabs to blanks.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 07:59:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 07:59:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390908.1631021 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumpF-0003wd-Uy; Fri, 14 Aug 2026 07:59:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390908.1631021; Fri, 14 Aug 2026 07:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumpF-0003wW-S7; Fri, 14 Aug 2026 07:59:37 +0000
Received: by outflank-mailman (input) for mailman id 1390908;
 Fri, 14 Aug 2026 07:59:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrewprecious388@gmail.com>) id 1wumpE-0003wQ-NX
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 07:59:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumpD-001yFf-QU
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 09:59:35 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a7ecadd-bab6-0a2a0a5309dd-0a2a450288ae-26
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:59:35 +0200
Received: from [209.85.215.175] (helo=mail-pg1-f175.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a7ecae6-6ca4-0a2a45020019-d155d7afd5bd-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:59:35 +0200
Received: by mail-pg1-f175.google.com with SMTP id
 41be03b00d2f7-ca7c1176317so582976a12.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 00:59:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786694373; cv=none;
        d=google.com; s=arc-20260327;
        b=C0cdHd/swJJP1NfdKBcDZkibSwG6xPTitxCmXdx+gdXrWR8s1IwY5K2M0zS8tOKVaV
         4ArttC6DFVZgs8DH0N8AXcujV9/t6Mq9zHMBeAJ8V0xpqBbHlrmby9rvakiXW+e6UQS9
         b2AyAV1KcigZqPH3BOFDkztv6RHQkKxs98wo/DQKfFkSmxaxbPv4eCUBfwJYJUxaXKkz
         akwjpJ1GTA+XNP0gcYVZxrP4c/AVHUyzZnNgRydqOLERN55E6BOegP+KST3QOdSJJjqC
         V9uW51GLaEaoVI8cRLPcKYeOW51Kd8SxA+8Hd577wFH/ulHFxCTkNj1yqCcEHmhI8Xh3
         YcYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=fRktlHtqQOXAxFnJpAxi5xc9vkIb0dW+AHLsSX4rpLU=;
        fh=UpFTLnCwSi0lAZgmDcfXF/u4JodY0u9pjARRJLeoR/A=;
        b=VAk9zbbEFiTUiTZLzMVPXYeh19OVoMK9ZmsU8ttZF49ySQx0sbz1HS/rtQL/N00tzq
         lkLq2Mnn+eR+IzNZv9g9K22J9wrFtRHKzPkXkEqx1jbjoYIEn2FLsWyftphL/g0QFdOT
         ToUT6K3k/zSKVnhdjzdkZJAy+1FVcWrFzvDt0an7wwcajxW7xmAGvsVAg8/0s4niEooO
         k+W0eUXg8Z+asLUfg+BSN/fHftFB01SA1R2jzde3gMgw7ZvTF02iBeuaSAHp/KqNNCBC
         3NZPPbtpkbTvWA7UT8wCrXJa0zGv5JpwKHZTsvyi9FlMfqV1Tc8wSG+cI4YQKNcaKa/f
         wmLA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786694373; x=1787299173; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=fRktlHtqQOXAxFnJpAxi5xc9vkIb0dW+AHLsSX4rpLU=;
        b=sJBoCPYpMellz1DPEQcW1deS/aLkNuo7vF4yHJ5qpTP1c7RC3VRVTq828UJfnuGHto
         9PAcPMIoW2+lihK3654rmZUqDR9WvDFOy4J7FIM8Y/cpEnW6bmzoIwXxguJsU1g8tjMJ
         2WmSqC+HBINueo9tON1TP7gTC8LtITWR9quqX6+jnDz/CmXQ4bzZBZuMMMwyYGiHFJrH
         WK/QdD2CBht4q84M7SJstKYOEEjmBoin6A9oTkqMGcvajR1656d2mukZjpGfKt95db1F
         d6hGzSaEgHRaSbdUQTe5CIBVHmfPyvyD2ua0W8Z9e3RePHFH5YZB4bb76OlwmXs+DQMu
         e1Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786694373; x=1787299173;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=fRktlHtqQOXAxFnJpAxi5xc9vkIb0dW+AHLsSX4rpLU=;
        b=IkX48wW8vW5PGdGrCXiIt/GEJKb/OM3x8ESoAVqBZQ1/zj9O0f5IAX0Mji/ZjFN8oD
         mepvYJCEM8W9CprN6tBixwNW//HiILBz24cD4J6I2xUpTn6e6bspRQLxlQqbYA8HQSWZ
         R+20DcF1up1xWqzuP3/PAGeT/rgshBqZF6J4TgVk0TUGZW0Z+g63OwBa9TULQ2vmZhkm
         eW0vngTZrVZr2LyXcPCtUZNfIt/a/ClKMLV1dyJB8rED1lpjJbh+clD+crGy1sz/2ldM
         i5GyTPIhwbAkiaHAKfYQWoaUbrnS0hqMKJf+4+pK11mArCVgFVC1g50AUoUXtUp7pJQz
         X3LQ==
X-Forwarded-Encrypted: i=1; AHgh+RqvWSI/QsSbjH75LxvbXmgjiJn2YDmS1VC7Ua2izuOBhvEowXPKhuvMM+aQZCwyb5vdsEhxFxPVW40=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWpcR1tZLlGrsWqzo6HFfrLTXqPqpF8rvqz3Jfvo0V4G0woNML
	W7cTG+L3aYkZS0uAC+Lg0JUWlXFn+qenOxF49GXii7o7rFPVKlD5S5p68QIRHdL0CzgTR7JurhY
	+ndlW1jtuNSo3xr9BUYTWTAllrmZnDfs=
X-Gm-Gg: AR+sD11ead/I6fbXzEVQOWSd3/U1mOr7KiQW6A7sPnekzHWNq72XI+SosY9enRBmLHA
	uo3rRHabPj0EdOKggqb+lI7TvMHhbL3PVYtp8A82dzt1GNtUZvEMIX0p73hJT9f38/xKiY6OIhR
	xe1WmrshfDKWWOl5K23GxVfWrFf1tt7tV7d7GDkcWTfj3H7cyG0/P3oLy8jGZbAMXnEuRvmaapS
	aRiL/RtRxN4WE2mWdL5Wc7jElMbsQcWBxZg09y0I0G0i003ddEPrwnFKWl9++wc+AbPT46EYGuI
	CdGkKi9xw2FYY2rFE10511vsCXC2Ww1CGymN0fB34lk=
X-Received: by 2002:a05:6a21:48d:b0:3c0:b766:74f4 with SMTP id
 adf61e73a8af0-3cc71e17eacmr4327067637.31.1786694373351; Fri, 14 Aug 2026
 00:59:33 -0700 (PDT)
MIME-Version: 1.0
References: <20260813212724.2607832-1-andrewprecious388@gmail.com> <a34ad4ec-28dc-4494-8798-f2a6b0fe7bae@suse.com>
In-Reply-To: <a34ad4ec-28dc-4494-8798-f2a6b0fe7bae@suse.com>
From: Andrew Precious <andrewprecious388@gmail.com>
Date: Fri, 14 Aug 2026 10:59:22 +0300
X-Gm-Features: AUfX_mxZgyL-2QM-GISwLOcHrcGW1PoxWjy_llXOpUqwkZ7kmy_X_KQb7H2jZ34
Message-ID: <CAF14T9n3QXEKHse-=7hr_=VzMc9ca7xkoSnVmGE1aZ_vsFNM2Q@mail.gmail.com>
Subject: Re: [XEN PATCH] tools/console/daemon: fix log_dir memory leak in xenconsoled
To: Jan Beulich <jbeulich@suse.com>
Cc: anthony.perard@vates.tech, xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="00000000000072232d0658fd33d2"
X-purgate-ID: tlsNG-720697/1786694375-323D42AC-4592BABA/0/0
X-purgate-type: clean
X-purgate-size: 5819

--00000000000072232d0658fd33d2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Noted,it's my 1st first time contributing.

Should I generate a version 2 patch for this?

On Fri, Aug 14, 2026 at 10:52=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wr=
ote:

> On 13.08.2026 23:27, Andrew Mbugua wrote:
> > Valgrind reports that 21 bytes are "still reachable" from the
> (XEN_LOG_DIR "/console") allocation:
> >
> > HEAP SUMMARY:
> >     in use at exit: 21 bytes in 1 blocks
> >     total heap usage: 9 allocs, 8 frees, 4,799 bytes allocated
> >
> > Since the dynamic memory allocation for the default log directory path
> happens before the process
> > forks into the background, the parent and intermediate processes exit
> during daemonize()
> > with the memory still reachable.
> >
> > Move the strdup() allocation down below the daemonize() block. This
> ensures only the final
> > background daemon allocates the default path, matching the lifetime of
> the free(log_dir)
> > cleanup loop at the exit of main().
> >
> > With this change, Valgrind reports a clean heap summary
> >
> > HEAP SUMMARY:
> >     in use at exit: 0 bytes in 0 blocks
> >     total heap usage: 8 allocs, 8 frees, 4,778 bytes allocated
> >
> > Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
>
> Looks all plausible (albeit a little unnecessary, as memory is freed at
> program exit anyway), except that ...
>
> > --- a/tools/console/daemon/main.c
> > +++ b/tools/console/daemon/main.c
> > @@ -181,10 +181,6 @@ int main(int argc, char **argv)
> >               }
> >       }
> >
> > -     if (!log_dir) {
> > -             log_dir =3D strdup(XEN_LOG_DIR "/console");
> > -     }
> > -
> >       if (geteuid() !=3D 0) {
> >               fprintf(stderr, "%s requires root to run.\n", argv[0]);
> >               exit(EPERM);
> > @@ -201,6 +197,10 @@ int main(int argc, char **argv)
> >               daemonize(pidfile ? pidfile : XEN_RUN_DIR
> "/xenconsoled.pid");
> >       }
> >
> > +     if (!log_dir) {
> > +                log_dir =3D strdup(XEN_LOG_DIR "/console");
> > +        }
> ... can you please not screw up indentation? All you want is to move the
> code, without converting tabs to blanks.
>
> Jan
>

--00000000000072232d0658fd33d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Noted,it&#39;s my 1st first time contributing.<div><br></d=
iv><div>Should I generate a version 2 patch for this?</div></div><br><div c=
lass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_=
attr">On Fri, Aug 14, 2026 at 10:52=E2=80=AFAM Jan Beulich &lt;<a href=3D"m=
ailto:jbeulich@suse.com">jbeulich@suse.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">On 13.08.2026 23:27, Andrew Mbugu=
a wrote:<br>
&gt; Valgrind reports that 21 bytes are &quot;still reachable&quot; from th=
e (XEN_LOG_DIR &quot;/console&quot;) allocation:<br>
&gt; <br>
&gt; HEAP SUMMARY:<br>
&gt;=C2=A0 =C2=A0 =C2=A0in use at exit: 21 bytes in 1 blocks<br>
&gt;=C2=A0 =C2=A0 =C2=A0total heap usage: 9 allocs, 8 frees, 4,799 bytes al=
located<br>
&gt; <br>
&gt; Since the dynamic memory allocation for the default log directory path=
 happens before the process<br>
&gt; forks into the background, the parent and intermediate processes exit =
during daemonize()<br>
&gt; with the memory still reachable.<br>
&gt; <br>
&gt; Move the strdup() allocation down below the daemonize() block. This en=
sures only the final<br>
&gt; background daemon allocates the default path, matching the lifetime of=
 the free(log_dir)<br>
&gt; cleanup loop at the exit of main().<br>
&gt; <br>
&gt; With this change, Valgrind reports a clean heap summary<br>
&gt; <br>
&gt; HEAP SUMMARY:<br>
&gt;=C2=A0 =C2=A0 =C2=A0in use at exit: 0 bytes in 0 blocks<br>
&gt;=C2=A0 =C2=A0 =C2=A0total heap usage: 8 allocs, 8 frees, 4,778 bytes al=
located<br>
&gt; <br>
&gt; Signed-off-by: Andrew Mbugua &lt;<a href=3D"mailto:andrewprecious388@g=
mail.com" target=3D"_blank">andrewprecious388@gmail.com</a>&gt;<br>
<br>
Looks all plausible (albeit a little unnecessary, as memory is freed at<br>
program exit anyway), except that ...<br>
<br>
&gt; --- a/tools/console/daemon/main.c<br>
&gt; +++ b/tools/console/daemon/main.c<br>
&gt; @@ -181,10 +181,6 @@ int main(int argc, char **argv)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 <br>
&gt; -=C2=A0 =C2=A0 =C2=A0if (!log_dir) {<br>
&gt; -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0log_dir =3D strdup(XE=
N_LOG_DIR &quot;/console&quot;);<br>
&gt; -=C2=A0 =C2=A0 =C2=A0}<br>
&gt; -<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0if (geteuid() !=3D 0) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fprintf(stderr, =
&quot;%s requires root to run.\n&quot;, argv[0]);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exit(EPERM);<br>
&gt; @@ -201,6 +197,10 @@ int main(int argc, char **argv)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0daemonize(pidfil=
e ? pidfile : XEN_RUN_DIR &quot;/xenconsoled.pid&quot;);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 <br>
&gt; +=C2=A0 =C2=A0 =C2=A0if (!log_dir) {<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 log_dir =3D s=
trdup(XEN_LOG_DIR &quot;/console&quot;);<br>
&gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
... can you please not screw up indentation? All you want is to move the<br=
>
code, without converting tabs to blanks.<br>
<br>
Jan<br>
</blockquote></div>

--00000000000072232d0658fd33d2--


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 08:03:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 08:03:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390926.1631031 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumsx-00062e-Q3; Fri, 14 Aug 2026 08:03:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390926.1631031; Fri, 14 Aug 2026 08:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wumsx-00062X-MM; Fri, 14 Aug 2026 08:03:27 +0000
Received: by outflank-mailman (input) for mailman id 1390926;
 Fri, 14 Aug 2026 08:03:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wumsw-00062Q-BP
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 08:03:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wumsv-008dVh-2S
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 10:03:25 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ecbcc-8faa-0a2a0a5109dd-0a2a4509a368-2
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 10:03:24 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7ecbcc-be1a-0a2a45090019-d1558031ac91-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 10:03:24 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-495590dde14so9594495e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 01:03:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499899b5f86sm9615415e9.5.2026.08.14.01.03.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 01:03:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786694604; x=1787299404; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=XjICsrA5cb4iwjJ9PiwOXzn3br1MovIHw+uDab9cNZU=;
        b=WpGzeHzOE1bunT55Pw13bNL/jlzKijwuY58PeKOjx9nd4fflfJy0+wKq9lcrUeM1lE
         w/Al0GoNrzsOwuQNNzk1Eg2hxIHlDlfycODiKIwjEyhqzk1V9UUSc2OhjjttyBZzOA1m
         7U/Pc/+bDI6M4QwKW42z25y8IVlZXHxPB2IGEGU1XcJHcjgFGpRtpIYtUr2+uTBk04cw
         lU7lrUnt3ioXhHgpWJ24PIB0JN8P5YGXQP87pplcb+wm+OvP4hsvgiideRa1p3JSHWPQ
         eMpwSBOZxxLDVaWcOOlOJXZI8RSPIjNJOZ1Qbh+DAFYgHNd0hNOZWuz/7rDUAj9x/m2C
         gWDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786694604; x=1787299404;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=XjICsrA5cb4iwjJ9PiwOXzn3br1MovIHw+uDab9cNZU=;
        b=MLAGTQH7/vvwWBQW2htr7SEj1MPVRHkVgoASCq+WTHJU//jadrIn6MthRBsm1gAIXz
         JD58xtInt25yZezoDyIECHmDZKRaUb5wjczzPyfUlzD9fm2oRq0ld9NM7d88bkylQIud
         No4vgD8/UywXquktnl9UUeDz9QWNF7h7mIQvlmt3+xlEVCk5BiDRPDZoGLz7lDLyg0A8
         IlWT+REctHvoPEj620yMkgXgnC9W6/8oOUKYEHDIzTDbdaQYOrnDGCK4GoybEUfO8uAy
         ROrDkLkLql4J40tHQZw8tvNFdDZOcD3L5XEf2dmpZwtjLSsMxvai+YwSwpCM7ZZUS9Lh
         sveg==
X-Forwarded-Encrypted: i=1; AHgh+RrPxwXKVE13b3ZzgBR4n+3P2T383p8FpjxB7PtQeJQ24IGqCmx9wIU9xAqO+rySSsxSmaf1AAyAcCQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzB+GuUqMEhdJKnYQPfHQtGYa37+/LV8KAFiAJJRJVZXqxq4GGA
	7xWBULorhHm8JB1Jp13pZ1tzW6tMnTjsuLq4QMD21+cEi0BIZ2A9hlLRmul0NlqntjqJIkhBLmN
	p5HM/Dg==
X-Gm-Gg: AR+sD13iHntDxkhPY8n+4tMhzgVvMz3CZSpp/Uy8F3qoZQqZRrjIbzrRLCyV2GS74jb
	boGtNW4+OWdrmueXKwAvol4rAgWDAuIHLlBUNZecd+Rntup0Z+YRTRNyUU0jlme2ZGt9IWvKx4G
	8vPDQfcb+b17b/Vefb8SK0eO1+5fhBcTm8RrEqArGFE0lKbSdMcgsLifL4MyoGueHMhavcZjN9Y
	kKH7HRHnkO58LhRejzKrDMP0rJEziraSJLQ+fsup1Z1dS0ePFDx5JsTnZWOnqkdB6knI6EU69nt
	goJBIamV6z8HLLHFzzQ4+JChdOk5SPpIis5hgpleTE/NxV7ZKTlUOElBlaJvAHXJ7FSQ3nrwdFP
	e7DvrCvlo4kztcTrf6Cw1I8mi9FuPjkySs0/ArtGyBPmqUjoevjXHyGo+1ZsAmidcpwPExuUUkB
	Opkjk/ihaxxDy4yHAEvlPHfrVAGKYZy0crW0R/5J2tzPX4dnllZQsICEHeKAU7tBW9i3T9u5gDN
	xtisAr41HtLbKaYExJprcVtLnYg7QIPmkGHIYXUwqdFwpN3kRP1
X-Received: by 2002:a05:600c:3e15:b0:495:6b55:f938 with SMTP id 5b1f17b1804b1-4998797328cmr54577055e9.10.1786694604229;
        Fri, 14 Aug 2026 01:03:24 -0700 (PDT)
Message-ID: <2f247bc8-5179-4b56-9585-37be6f5c80c8@suse.com>
Date: Fri, 14 Aug 2026 10:03:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] tools/console/daemon: fix log_dir memory leak in
 xenconsoled
To: Andrew Precious <andrewprecious388@gmail.com>
Cc: anthony.perard@vates.tech, xen-devel@lists.xenproject.org
References: <20260813212724.2607832-1-andrewprecious388@gmail.com>
 <a34ad4ec-28dc-4494-8798-f2a6b0fe7bae@suse.com>
 <CAF14T9n3QXEKHse-=7hr_=VzMc9ca7xkoSnVmGE1aZ_vsFNM2Q@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAF14T9n3QXEKHse-=7hr_=VzMc9ca7xkoSnVmGE1aZ_vsFNM2Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786694604-BF4D3034-939CED41/0/0
X-purgate-type: clean
X-purgate-size: 276

On 14.08.2026 09:59, Andrew Precious wrote:
> Noted,it's my 1st first time contributing.
> 
> Should I generate a version 2 patch for this?

May not be necessary, the edit may be possible to do by the committer. Best
wait for the maintainer to provide feedback.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 09:30:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 09:30:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390959.1631040 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuoEt-0003Qb-Kx; Fri, 14 Aug 2026 09:30:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390959.1631040; Fri, 14 Aug 2026 09:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuoEt-0003QU-IF; Fri, 14 Aug 2026 09:30:11 +0000
Received: by outflank-mailman (input) for mailman id 1390959;
 Fri, 14 Aug 2026 09:30:10 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wuoEs-0003QO-2k
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 09:30:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuoEq-005gex-No
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 11:30:08 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7ee01e-e002-0a2a0a5209dd-0a2a450391be-8
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 11:30:08 +0200
Received: from [52.101.193.53]
 (helo=CH1PR05CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a7ee01a-fae8-0a2a45030019-3465c135e55b-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 11:30:03 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PHXPR03MB989208.namprd03.prod.outlook.com (2603:10b6:510:3cc::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Fri, 14 Aug
 2026 09:29:59 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.014; Fri, 14 Aug 2026
 09:29:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=orqWp8BaFpIEZJ/R5oiCM2Iv5ivnLRQvbk5krN63uSD/n3AQGhq7Ixvemg7EU5mn7Xfk1WnO1OhIjy21g55l9CO3stDvf5eGlBY/w4LS0EPDzW562VPMO0idOq67KGV0R2XNTjNonPEZor2aJo0OFJdwv0b82y3JumtZErYCs0MI8zpUrUL7WSvVlrhIn7tVqN68rdYdH+I47HSnCRrlYwdMAm15CjCLQmSBdbuhS2qxCBAdH8Fw8V5klR7BQ/fawzvkJwhzVy+vVeqzjf+szyTwl031E0fk3DpWoOQWel7hziFSmhZJCYRhde1B5XgvZLRLbBygjd5ekHW0EQmAbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZPZ+wEMd7iQZnQWPYOwnXmHCthqDB4Vq6R1ntqFV5RE=;
 b=Cr0TtJI2oIUivXBL9hauEUK9t/hWEu/787DLNmkYgDBWGYW7IGcnSzhiKMFEWcxbMfEmWwYGXrSFKpV1soMUFzoBgB/gPfiUvOy602UoQvhL2RX00B1VwwmpjA1WvxMhxMDnY1Xa0X4b+e/uZEPf3BSnpc78Vby+1XqRpFelqEtIm3LbdVEn5+V4O/a6eepSjzFRGqKZM/XFHOKljiw/4cwcNkAF4nXod8s9/6xZ2RyeLZR4UabVvlPyUzspONTr1cdNIxTlxHWJTmgYYkBFbc1+kjwTiWC1iPDM9a3rDZEme9nBfN/mVIcTd3wF92bqxKxJ3UMp7EP9XnfJAQMi3g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZPZ+wEMd7iQZnQWPYOwnXmHCthqDB4Vq6R1ntqFV5RE=;
 b=l9U3aAiOLFrfcZ2GgFbHfbMwpbReKaptqgLl3bNVcpHWf6cdoNxk0Ltm+tMLYXp3nXkhEM4eSqe8e9Kaiqn9yFXv/+U2739ujUkbK6sgK4mEQ9FIhBmWw4UY3hSN83nByjkdzVasPfbK/Ov0mfTpu05Q6IfJRAxuJ4XQklIYERg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <74777a38-125d-422a-9114-b147edca903d@citrix.com>
Date: Fri, 14 Aug 2026 10:29:56 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich
 <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH] x86/nmi: Fix mis-classification of watchdog NMIs
To: Xen-devel <xen-devel@lists.xenproject.org>
References: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0288.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:38f::16) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PHXPR03MB989208:EE_
X-MS-Office365-Filtering-Correlation-Id: 8bbd75d7-4bb7-4421-1101-08def9e69c33
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|56012099006|11063799006|10067099003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	o8KkCm7pdlUvoqS/4XYuoLhQnkdWy0C7BcsydqETvuJnaPgS9APLa7GWU4aKKcFX3pSyAHfdD/R3Pna6sjK6tmvX517AD8VjpRnZ0bJbFR5FTDAOIr/QK7bkyPl7Qmyk+pkX5R7P0srRXiOPjz6atGVpkDnoK/eDqgMFlKW3hsS7D8OTjoP26B9OgTEXcKMnLwhErSRNppw0iKC8+xR1dC6o/iFgft+QiKFk2ZCXY/oTtHKjlep2lgMzHruFX/5AhneMuyYs5U+igpLFHH0GN4IwqOmG8iAhF70Tov/ca2ophc9otIKZdichz9nHKCGtowCM8MiwZYjQijLDWfp+wXk0oZXUfX0avNnVIjVsyt/mqRCy/LQwwVStcWgIdH4Q/E2lKh0KjmsdHugg8si6XZE2w20vVySqdtfNtt4FeEJf4RofpQu7NNU0U6kJHb/TaLEp2J3YIq6iWqBA6EvBafJJUiPbHmaHKa2maToK81AF4qke6VypyN0nmqg10Cqv4Nv7h8wIPV8ZCip8kEIgcI5tvK7rVqLnx0Aqc+cU2xdQQV/Do6fcbuIfNh+HkPTcRuykLFk9HRECI4Rl4o7gHchWjsvP7w23mBxlmQnu0iaZGY9klybh7h4WCogXp07ouETtRY6w+7OEx8iA8EFVVJkUQXTgB5Zw2A6Io02yC20=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aDg1SE11cG5CQkVyK1JIUnMrWmFvUjV5dmtrV3Z2OXk2N3lWL0VJZzc2QU1X?=
 =?utf-8?B?ZWhLa0h5eERqWXRLeTVpZWZ1L1A5aGtrTkNCcEpzYlpaeWo3cjcwTStqRTRH?=
 =?utf-8?B?aUp6NUtPc2hUSndNMDBZTGpPRXdNdkdNTlRBUUpWRlNQWUtaTFloZTBZdGJv?=
 =?utf-8?B?WUxLSTFJakZRdWJ6Tyt2YkxHRlpqMEtqNU5qaFl3UnBvdWVjMWpVc1pLeERZ?=
 =?utf-8?B?M3Jvb2p4WFAvNUcra3Vwc1pjSnJrbmd0YXFtSnUwQytROWFLRTBVUTlkUFk3?=
 =?utf-8?B?VkNoSkZWYWdtaDI5dXF4SlVXUkpzR2RtTHh3SzdJemlKRDVNMklOMHd5emVN?=
 =?utf-8?B?a0RHYU5CUDlZMU9TRDgvRmJtQWJDMnJEb045cEN4UklJOGZHWGJZWDRnVFhD?=
 =?utf-8?B?cHZ5empDSjA3V2IvU285WmFBdjE0bXJRRmFPV2JESkZXMzRSa2RqR09rYkwv?=
 =?utf-8?B?Q3Z1emdMdjhFTXRCaWRXcnNZem5hcnpBMnJUTFNwUHo0UThMVGl4RDQ2S0Rw?=
 =?utf-8?B?T2xyeHU5aFMyMW54bFgrLzlWV29QU1hpaFZyS3FETXlXRzdYa2EzL093Ylhu?=
 =?utf-8?B?Wk1Fb3R1M1hXRWdqaWY0M0NsaGRYMU56M2Q5YTdSZkxpcXVRTHUwVjlRUndz?=
 =?utf-8?B?WmtrZkZadThYd1lVYmFRTWYrMk5lQ01XNjdJN2NlN3lnSVI4L2F5bUU2dGRL?=
 =?utf-8?B?dzY5ODA3d1NncW5mQnl1dkgwR29PNnZHb2xtTU13S3pibVZuYlpJTDdrT0M1?=
 =?utf-8?B?RU9UYUc2Lyt4U2VwSjV3NDZHSDduUk1DODlPNTBlME5PZU0ra3ByZGhOcFVS?=
 =?utf-8?B?NkZPTEl0d0NSbjBNNHZXOCs1eG10NncxS0Ria1V1Q2cwWDhKVkQzOFVjeGkv?=
 =?utf-8?B?NTdieDYxcXdsNTFWRjFoTkVTTHZpSE9od2JJRWJ6Wk5qbHJ5OGVyUlNHeW8w?=
 =?utf-8?B?cnJvM1YxbkxlUmtGOUhXMWdkWUljZ0EvbStpQnMyd3U3MzYxRUVuV3BLRlgz?=
 =?utf-8?B?eDRiSktRTWV5VmlrOXdhQjZTU1I1WktWR2g0SU1tcm4ybjBZYVU2ay9uL1dq?=
 =?utf-8?B?Y0NSQnJxeTB0andOVFRZOHJhVkRBZDJVbzBpdjJJVVVJeVJLOXI3b3N0dEdM?=
 =?utf-8?B?ZER4MHNoRzA4Zm9UTUkvZ3BaRzRXamh4UzJpY2x0RndUblc0WWNNNkNpTEkx?=
 =?utf-8?B?K0lCQWYxZFpoMEJOVE95b0ZMcW8yU2xDUVRvSEhpMVM5aVUxS1l5Q3NGc2NM?=
 =?utf-8?B?VXczREw1eWhobmNLbkE5dEtKTmRPcUdRaWsyL2Z6TktOdVV4bXNlTXN5dGFi?=
 =?utf-8?B?MXFiZTErS0VSdG5mVDNrSmtXMWQyQ1hWQk1QSEdzSnZvV1pBWUtXTFNrYTRY?=
 =?utf-8?B?eU1ySWRvQms3L2IycXk5SytUTTIrbVhDeHdpWDdsR0FjS3EyNm9RZlJXc3M2?=
 =?utf-8?B?akpsMzZwRlBuQ0w0cjRaelZyRXVJRmNEdFZxeDBUMWNFdWRxOGpSaWQvRTJr?=
 =?utf-8?B?UUlaV3dTVm1aYi9DRmZYM3NiZm05bTFQWUdGaUJFN0xsMlY4eXR2NDBqZjFv?=
 =?utf-8?B?dzZtWTEzVklwWFpkd290YURLUnhnMGZhT2hob083RjZzYU1DTkVsYUNkVEZj?=
 =?utf-8?B?bC95TkU5Z2xoVExwaUphcnp6d3RnRWp5RndoeUhVOUpya283S1J3eWlNOXZU?=
 =?utf-8?B?djkyZzQ4SU5BM1hYMEpHcVJmMnp3a2ZRMnBySzdUVlEyM3BhRCtTczJMdm1v?=
 =?utf-8?B?bnBwU2JRUUZSVEROWG1QeEdsVHlIYkJlQ01KQm14c1BNRUJTaFVycUM4M3Ry?=
 =?utf-8?B?Y1IxQXRjdlpFMmwyRHhLVmdiME1EK0hScDBQeXJ2Z3JkT05sRTJYN25CR052?=
 =?utf-8?B?NkJGYWlETTIybTY0UE1YcmQ0eFhoa05hRmpVd2NFZ05DTkhBZEoyUld5Y2tM?=
 =?utf-8?B?SmIwaEEwZjR1eDAxTm1NRmN4cDdsdVBVbVJzREhoeTN2UDJBTmZVSGlqSG5z?=
 =?utf-8?B?MUJwMWVBMWR1WjVTR0twL1VFWU1XMjc4QzFRR3VZNTh2djdUZlp1TUh5bjJS?=
 =?utf-8?B?UW5lMUo5bXBaMCtaOStLWkh5TXVLUkRiZmxycEw4N0lDVGVsVFZjVUZNSkxi?=
 =?utf-8?B?MERoaW1wSTFBOG41aTBpb1FDVWM3WFVzSTU5MWtiQk9haExlUWxKVGtGb2lV?=
 =?utf-8?B?SW9Yb3dwL0FtWDNNUDJuNy92MEcyS0dTVitLNHpyWVpIQys2SGNUVUdBWVZR?=
 =?utf-8?B?cnMyU2Y4bHFUdWsvK1BINkR0dERIQ1lBbWVBN3Erb29SNUorcmtyNzZFUTBv?=
 =?utf-8?B?UFUrczFpNHJrNCtTQmFRb0ZUUWcveDVGYlRFTE0zWkxNRFZzU1NRUWJ5a0lP?=
 =?utf-8?Q?YbC90Rrx8arJKImA=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8bbd75d7-4bb7-4421-1101-08def9e69c33
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2026 09:29:59.3353
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TOSLZgpvfiqIQD4rgZRfRiIpdlqPG2VtFnlJLtCNve6RkF4nNZ8LNQMERUxqetT0HF8Mohj/rvejEhJaGJ5WyMdyXp5tiJVIeu8dcGuf9BE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR03MB989208
X-purgate-ID: tlsNG-33051d/1786699808-6D2D84E9-A840F72A/0/0
X-purgate-type: clean
X-purgate-size: 3458

On 13/08/2026 6:43 pm, Andrew Cooper wrote:
> It used to be the case that cpu_data[] inherited the BSP's cpuid_level until
> the AP had calculated it itself.  Following the rework, cpuid_level has a
> placeholder 1 until it is caluclated propely.
>
> setup_apic_nmi_watchdog() happens to be called on the BSP after SMP bringup,
> meaning that the first call is on CPU1.  It is also positioned in the window
> where cpu_data[] is garbage.
>
> As a result, setup_p6_watchdog()'s one-time calculation of the performance
> counter width falls back into Pentium compatibility mode assuming 32bit
> counters.  This causes a watchdog NMI which is delayed a little (e.g. from an
> SMI), to appear as if it hadn't overflowed, and therefore be (mis)classifed as
> not a watchdog NMI.  On systems where unknown NMIs are treated as fatal, this
> results in a spurious crash.
>
> Switch setup_p6_watchdog() to use boot_cpu_data.cpuid_level, which is how this
> is checked almost everywhere else.
>
> core2_vpmu_init() used the same pattern to look at leaf 0xa.  Despite being
> init code and only running on the BSP, {boot,current}_cpu_data are different
> objects, so switch it over to checking boot_cpu_data.cpuid_level too.
>
> Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger@xenproject.org>
> CC: Teddy Astie <teddy.astie@vates.tech>
>
> Found on a system where:
>
>    [root@box ~]# time xen-ucode ./blob
>
>    real    0m9.166s
>    user    0m0.001s
>    sys     0m9.165s
>
> is changing several expectations, and spurious crashes from mis-classified
> watchdog NMIs is just one part of the problem.
>
> I hate this fix, but it's the only thing which I consider remotely safe to
> backport.  Recent attempts to alter CPUID ordering have 0 success at being
> bug-free.
>
> I have not investigated what else was broken by the cpu_data[] change, owing
> to a lack of time on my part.  I would be amazed if this is the only thing.
> ---
>  xen/arch/x86/cpu/vpmu_intel.c | 2 +-
>  xen/arch/x86/nmi.c            | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
> index ed9f62b9366d..af6cb0a85cdd 100644
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -896,7 +896,7 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void)
>      unsigned int version = 0;
>      unsigned int i;
>  
> -    if ( current_cpu_data.cpuid_level >= 0xa )
> +    if ( bsp_cpu_data.cpuid_level >= 0xa )
>          version = MASK_EXTR(cpuid_eax(0xa), PMU_VERSION_MASK);

Hmm, this is a stale copy of the patch.  Fixed locally.

~Andrew

>  
>      switch ( version )
> diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
> index 91f95fe6d080..ec85516609b0 100644
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -321,7 +321,7 @@ static void setup_p6_watchdog(unsigned counter)
>  {
>      unsigned int evntsel;
>  
> -    if ( !nmi_p6_event_width && current_cpu_data.cpuid_level >= 0xa )
> +    if ( !nmi_p6_event_width && boot_cpu_data.cpuid_level >= 0xa )
>          nmi_p6_event_width = MASK_EXTR(cpuid_eax(0xa), P6_EVENT_WIDTH_MASK);
>      if ( !nmi_p6_event_width )
>          nmi_p6_event_width = P6_EVENT_WIDTH_MIN;



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 10:07:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 10:07:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1390984.1631065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuood-0000cn-Cx; Fri, 14 Aug 2026 10:07:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1390984.1631065; Fri, 14 Aug 2026 10:07:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuood-0000cg-9j; Fri, 14 Aug 2026 10:07:07 +0000
Received: by outflank-mailman (input) for mailman id 1390984;
 Fri, 14 Aug 2026 10:07:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Usama.Anjum@arm.com>) id 1wuoob-0000cY-79
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 10:07:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuooa-00CxDu-JY
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 12:07:04 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7ee8b8-8faa-0a2a0a5109dd-0a2a450aa414-20
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 12:07:03 +0200
Received: from [52.101.70.35]
 (helo=AS8PR04CU009.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Usama.Anjum@arm.com>)
 id 6a7ee8c7-f2d2-0a2a450a0019-346546231ba5-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 12:07:03 +0200
Received: from DU7P250CA0018.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:54f::31)
 by DU0PR08MB9420.eurprd08.prod.outlook.com (2603:10a6:10:423::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.13; Fri, 14 Aug
 2026 10:06:56 +0000
Received: from DB1PEPF00050A00.eurprd03.prod.outlook.com
 (2603:10a6:10:54f:cafe::5d) by DU7P250CA0018.outlook.office365.com
 (2603:10a6:10:54f::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.15 via Frontend Transport; Fri,
 14 Aug 2026 10:06:56 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DB1PEPF00050A00.mail.protection.outlook.com (10.167.242.42) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Fri, 14 Aug 2026 10:06:56 +0000
Received: from AM6PR08MB3414.eurprd08.prod.outlook.com (2603:10a6:20b:49::10)
 by AS2PR08MB10111.eurprd08.prod.outlook.com (2603:10a6:20b:62d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.15; Fri, 14 Aug
 2026 10:06:22 +0000
Received: from AM6PR08MB3414.eurprd08.prod.outlook.com
 ([fe80::dde8:bf0b:1dc:2a2]) by AM6PR08MB3414.eurprd08.prod.outlook.com
 ([fe80::dde8:bf0b:1dc:2a2%2]) with mapi id 15.21.0315.014; Fri, 14 Aug 2026
 10:06:22 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=xDBuWPymd45tbtSJsM5zIQ7ovzGXD+AGiS6ED8icHhxGxVT76M6DstGxkVHkqZFrKZ985/4ylndA6OkpO7KApT4x8A9VoWXIUF7ol+hnVj8p9InHzAwMyVHfnKoHZOy0STBUIWB2yo7sa+gulPrTLvj9KR5/g+JJ0LaFg4m2WMV0GZnLHXfdLtAkTv04NadcewuXeVcvS9PxpcizH7DD2JNdWOxdpz8AUK4jC8UjZjjx2jVcWfCBmRMksbO7bq08/ZKY22a5fuJ7oHkIKekVik6zDgN9xwDX6CwML+4n1YKATCfnob9SNIv4bmxK1dOzh93tLos5zLU3l1hYIdSSUw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T3KhvsxEoEP9z6JNj1aBx70Nx6X3XBZOUekklW3rbtQ=;
 b=PyqtN1JNJudVv4ZYrE1LAlvnCEJ9YizG8w2qpKARDgPno8P2z0qNluL59nw8K5h/EdPXXJbXfFM/fB8OTlRfbZl7GjRfyLD6A6TdNZOQSwunFyleIE1EpEkPcnVlUPybP0ZBxym/muZ7y1YnawaISEyunpHgL/KMMxwVE/c/1d/3m7cvTVqn1k2gjKXmUxoBejgFo/9KsetJjU27CUNrxDZ07lPKBtsGPSO/GGCkeNfCp4CT3XjBatR91gj25FKk9Bi9EADX8XUESx98U1/UZTUbc6MxXnJOSU0IbmcgLWItKlGVQFta2tayKA7kP9UXLCivv/rRKRUIo2Rt01oiPQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=T3KhvsxEoEP9z6JNj1aBx70Nx6X3XBZOUekklW3rbtQ=;
 b=Xa73x8VOqP9SORkdx0HmJjWkb3uz57kANXUAB9hdYEYAtYJmLeE2YabwJREVIDuEv1ACZhPpSmNzQNZDThV0g18zfFCpkViSg2f9AxMSAyzqyY06lO8Q2enl3N0PSPGUuhiDSwh7mZg8yBwj6DT6IUdeWHq5TOnreBTaN+Uj0Dg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PHmEnvHlnGBw4IwdJs7esLlclPRGZD2862Rk8b9wsf+poJ2rYvaUBfHOPunvQWGY5sYkl8wYrAn/QYbHHAtQyGPCTEJkGD2TJ4WhFQsPsx33YtXlw1LwXYRwVz3fOWwJiquTf1z6MxUiF5BgTZHG98PEkygMOeAHsS1rt199eD6O+gDgJTLzIHiZPgDkLFGccCmeryNn/dgQ7ZvlIPEKY9Hak1474QAC75YTnYzI50qA4wALw96kqICvycaCYHRE7Z/nP5nk8K3GeAC9f+/2oCuJaTM0OlcH7BBFyvc9cJ9DlaqACd/QE3coMzFmhKVnDfFiUHlD5oT+MsOS2gJLgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T3KhvsxEoEP9z6JNj1aBx70Nx6X3XBZOUekklW3rbtQ=;
 b=HTDEjnorGVlYrFORYmJdgvFchCM37g7vDTzt/byP84USaAURmmENe49RTl34SlC1zzHl6D2b+A7QmIrit+m8GN3JvghoHHjvQor0ke8o0TdXvyBSlm9HFG2tZkamq4qtJb1+n5TSDY0Pl0Ufjg7M/usWMZGI68M2+vhuGQD+KDPyWTY4vuDbimg4VR9OHJH8h5o7vpz2F5ilzIcp3fP0qqbBtmqN81mvB9WWkMPMg0McxLex/XZ4Xx9Lw3JTJ9aehR62XBuqz0omqE/zj00Fvtc5jtGUquybb5+N2V/NwDpoZwFWI3zGsjUH34t+FLowH8NNpN8wIoaj+G0ZCKR0fg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=T3KhvsxEoEP9z6JNj1aBx70Nx6X3XBZOUekklW3rbtQ=;
 b=Xa73x8VOqP9SORkdx0HmJjWkb3uz57kANXUAB9hdYEYAtYJmLeE2YabwJREVIDuEv1ACZhPpSmNzQNZDThV0g18zfFCpkViSg2f9AxMSAyzqyY06lO8Q2enl3N0PSPGUuhiDSwh7mZg8yBwj6DT6IUdeWHq5TOnreBTaN+Uj0Dg=
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
Message-ID: <99eac5ca-d5c6-4777-b16c-5a20fae95f5d@arm.com>
Date: Fri, 14 Aug 2026 11:06:20 +0100
User-Agent: Mozilla Thunderbird
Cc: usama.anjum@arm.com, Jani Nikula <jani.nikula@linux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin
 <tursulin@ursulin.net>, David Airlie <airlied@gmail.com>,
 Simona Vetter <simona@ffwll.ch>, Dimitri Sivanich
 <dimitri.sivanich@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
 Helge Deller <deller@gmx.de>, Juergen Gross <jgross@suse.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Muchun Song <muchun.song@linux.dev>, Oscar Salvador <osalvador@suse.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 "Liam R. Howlett" <liam@infradead.org>, Lorenzo Stoakes <ljs@kernel.org>,
 Will Deacon <will@kernel.org>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
 Nick Piggin <npiggin@gmail.com>, Peter Zijlstra <peterz@infradead.org>,
 Andrey Ryabinin <ryabinin.a.a@gmail.com>,
 Pasha Tatashin <pasha.tatashin@soleen.com>, Chris Li <chrisl@kernel.org>,
 Kairui Song <kasong@tencent.com>, Uladzislau Rezki <urezki@gmail.com>,
 Steven Rostedt <rostedt@goodmis.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
 Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,
 Eduard Zingerman <eddyz87@gmail.com>,
 Kumar Kartikeya Dwivedi <memxor@gmail.com>, Ingo Molnar <mingo@redhat.com>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, SJ Park <sj@kernel.org>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jan Kara <jack@suse.cz>,
 Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
 Miaohe Lin <linmiaohe@huawei.com>, Dennis Zhou <dennis@kernel.org>,
 Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
 Mike Rapoport <rppt@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
 ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com,
 linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
 dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-mm@kvack.org,
 linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
 kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
 bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev
Subject: Re: [PATCH 6/9] mm: convert PTE table entry to pte
To: "David Hildenbrand (Arm)" <david@kernel.org>,
 Alexander Gordeev <agordeev@linux.ibm.com>
References: <20260806083926.1807279-1-usama.anjum@arm.com>
 <20260806083926.1807279-7-usama.anjum@arm.com>
 <fab9fc78-1e1d-4d5b-a9ca-92f3ebd04108-agordeev@linux.ibm.com>
 <5c329236-7761-4e42-a549-b822e43b4358@arm.com>
 <2599c5b3-e8ac-4865-993b-d41e6f060d52-agordeev@linux.ibm.com>
 <f0b0dacb-fb83-4402-b0ea-30072727dfd7@arm.com>
 <e9de4158-b829-471b-980c-1999959bbc48@kernel.org>
From: Muhammad Usama Anjum <usama.anjum@arm.com>
Content-Language: en-US
In-Reply-To: <e9de4158-b829-471b-980c-1999959bbc48@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0374.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18e::19) To AM6PR08MB3414.eurprd08.prod.outlook.com
 (2603:10a6:20b:49::10)
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
	AM6PR08MB3414:EE_|AS2PR08MB10111:EE_|DB1PEPF00050A00:EE_|DU0PR08MB9420:EE_
X-MS-Office365-Filtering-Correlation-Id: 63e47786-f4fc-4bc2-1a14-08def9ebc5eb
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|366016|23010399003|7416014|376014|18002099003|22082099003|56012099006|3023799007|6133799003|10067099003|4143699003|11063799006;
X-Microsoft-Antispam-Message-Info-Original:
 FdM+vYM//Rs5TUwEEHIcmgNLmFMgPcbIWudfucKOtLwbQHuQH4LsRsLWhZbhUHVwlsUZ2MW/QlqZEBRFZOotGFq9ElB1fBk0T2wDM9eJxSONOc0eBnNbJCrYXcdL413Ax+OyfkfEoxy+7p6xfO/Gp0ULezU0rryPMHDxdW+WSS5rUULaD/qtxpsaexe4gAKKlRwpoKiMYC0kk6mOSF6nV//6DKRqnn8jaUxss4Jb7rpTjNrDntvBromiOXkyH+u738mcKX2mQvUwgMLXPwSoUcHl2FYCYlRXOtzbXYvxFs4S2yuivsokOQ+SAGvWRCMRzXK/QnoVKcb0xUY8+gZ88apENk0piPBxngMRBECCAR61rRcrJLUNQtlEB8HBbq/YpCmGNjePl8g7rSF97nWWZn5uqDznbnx9lhon+2zPAyx5mE7R4B8g1+I/ayLySqAwyOQtrDcO7Utgw3QJ5V1LabHy5H4Zq+RZu+yoYeVUyWvQxqZvBXrOzp8rjCTsZcVr6KY7JAdQq4tl5Ps/qB9tRiPALRaFbOG7P370QXOXENe/wCCzLSQ1wcD8BOuVSU5Yk2Obd7lxvCHq2207TdfFyw6gpkOv+e49mmqVZhxXI356CRSby/7mB6IuGiTs4sLL6Lcof90Lpfy9gfrzTaZ12kmtz9OQ0y9Jt1KAXQnZMIU=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3414.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(7416014)(376014)(18002099003)(22082099003)(56012099006)(3023799007)(6133799003)(10067099003)(4143699003)(11063799006);DIR:OUT;SFP:1101;
X-Exchange-RoutingPolicyChecked:
 hg0VAWoj1GcWWsk+NJy5Vc8BjrpZSBqh8S30aINiN6NxTNaP4iTTkJ91o6iF1/+Zwjb+/AU1X6UV8XTM3bUxU3Q8BCdzlOCy7kOyF2/QY5swJ6ur7BBbFXmGFS6NpT/ac5AA3biozKgSIVWQ+BMglFcO2/q00U6bDY7FjrezA7vmmaMQsVLMPQbt67FGkKdB2XVwe9vKRY6AHj6SJA5C8LJnCN/kIC4nQUKWP63TP6aMafYf/b5odoc4YiM9oEHhWuIHKuJJWkzrwup6r5XiD7ifQ667mLFzrHqBBcKWLla6YAbKP70dp40wmHUcEMJMSgsfMU8tyCfetML6h6+siw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10111
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF00050A00.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	330ecdb8-6c41-4eca-4e97-08def9ebb11e
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|36860700016|35042699022|14060799003|1800799024|23010399003|82310400026|6133799003|4143699003|10067099003|11063799006|22082099003|18002099003|56012099006|3023799007;
X-Microsoft-Antispam-Message-Info:
	VjS2yHJRJ6FIIV5VKfG/RwNRqdqbt3Pw64Il+TSsQGYNJXdp7YbLVWSVHkDcN2Te0SodvhigFS0HUT6l/N+WF/VM69XgCun7ZWE5XvidEFCSmujGCh99x+s19goBj1LtThgEcHLltVEzVBAbA8a2qghQ5UbPjLZ44PJ1xqUu23wBz0wqTb8Axr4boImcWSCfUcvUav0HEwqkvKauBpWHGPIiwyxfB0y7TegHzWNbyVim5M7bkh68zoD/iXLJtn4r43vg2f7dSOHK4cfcCiLrA801zYhzAeRz7Rc4tfr5QNHdS43R6dQUZdKtzCyh2E3K09xHkaulD+pYhLi+JNGpNSQW31hV2HdAo7IrrejyTAkZXxrzkkv96tBOjZg1YD5xUj8cZ0UfG5oFSJUSCEMe/8MvRZBQT0tZztt40vP1eHgQJm1iufXi7qdatBrOu9RbHszUSbXrdutpLIdIE5l9zHhM3KQ9WMFXrktOuVW21AXgnz0oD4iEsVeh1SMGUl8U2pEIv01AsGyf2/ZS43Tez5ahziTbYoN5cLgwTyw66AIPPr6cG37TeG6HgK0IaRZlYnzqGHHMmR0fOdJWRCDPKzcuZqOe5zfLLL+OgRNQOl4GbgukmSyfZx/XWVRQclsPXRxxAVRh7CKFo8KKdCziEvaFeR+12MumIMvkJKrLf925bD5emz55ZgRWNJ7FDxyKDyVmMBJDeM4ilL+UWM7iAw==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(36860700016)(35042699022)(14060799003)(1800799024)(23010399003)(82310400026)(6133799003)(4143699003)(10067099003)(11063799006)(22082099003)(18002099003)(56012099006)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	pvMM/dJiD/B/1LdIJH1K8JbPFKXwEhVh9l8eVP26ZwENbQXm6ngpU4Rk/Ns4b3guGJ9Ivy86+rD/m4sStrCfxLyVcStcdW1pEMK2s5aLAyp3fn9xco2MbDSJqcAvvsvb1QZ4iiH048VUfUHvrclD1oVmg/CzcrAFnajPe8PToT6sJ61rWJdiYyi/vZNajaHBOfZAQeKx7dCJBHhLdm91fQ5+8DlZgBqyfxw4iAbVxkX0hpAylYE4/LSVaLMwPi0RRDg5i0liPY/VVuqNnL+DkB0KUp0zc+y/qtSu1z/okjH9xHPS2hFuB5+86KHOYYoemfOSDysVkP3fDshHDZ8RhJ/fvIsydMSzU0isAHIY5ZgtVINWQ73F6SrL1tpO8wqizQZ+ns4pFVtccu9gwAFH5rTwScC/HayBRHU0PAjukOwNT3Xhow54yht9ACpYav6T
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2026 10:06:56.5509
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 63e47786-f4fc-4bc2-1a14-08def9ebc5eb
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB1PEPF00050A00.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9420
X-purgate-ID: tlsNG-4011c0/1786702023-50CCBCFC-26C4A163/0/0
X-purgate-type: clean
X-purgate-size: 3001

On 11/08/2026 1:11 pm, David Hildenbrand (Arm) wrote:
> On 8/10/26 13:06, Muhammad Usama Anjum wrote:
>> On 10/08/2026 7:44 am, Alexander Gordeev wrote:
>>> On Fri, Aug 07, 2026 at 05:26:04PM +0100, Muhammad Usama Anjum wrote:
>>>> Yes, this is particular line is for non MMU. In this case, CONIFG_ARCH_HAS_HW_PTE
>>>> would never be defined. Hence hw_pte_t is just pte_t and direct dereference is
>>>> allowed. I'd thought a lot about it; is better to leave direct dereference here
>>>> or use some helper. Then used __pte_from_hw() was already being used in generic
>>>> ptep_get().
>>>
>>> But in case CONIFG_ARCH_HAS_HW_PTE=n __pte_from_hw() is still gets called.
>>> That looks inconsistent to me. Why not just call ptep_deref() (see below)?
>>
>> Agreed. Calling __pte_from_hw() directly exposes the representation
>> conversion at the call site. I will introduce ptep_deref() and use it
>> here.
>>
>>>
>>>> There are only two users of __pte_from_hw() at this time. 
>>>>
>>>> ptep_get_sw() or ptep_get_deref() is better name here?
>>>
>>> ptep_deref() would be it.
>>>
>>> Do you agree to the suggested API requirements?
>>
>> Yes. hw_pte_t * identifies storage containing hardware-formatted PTEs,
>> regardless of whether it is attached. ptep_get() is used for attached
>> entries and may provide additional architecture-specific handling.
>> ptep_deref() is used for unattached entries and performs only the raw
>> storage-to-value conversion.
>>
>> For review, this patch would become:
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index bc0b9c65aa1d0..ce900d2652d91 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>>  #ifdef CONFIG_MMU
>>  	return ptep_get(ptep);
>>  #else
>> -	return *ptep;
>> +	return ptep_deref(ptep);
>>  #endif
>>  }
>>  
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index 1768421755a9c..08613593f3320 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -490,6 +490,13 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma,
>>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>>  #endif
>>  
>> +#ifndef ptep_deref
>> +static inline pte_t ptep_deref(hw_pte_t *ptep)
>> +{
>> +	return __pte_from_hw(*ptep);
>> +}
>> +#endif
>> +
>>  #ifndef ptep_get
>>  static inline pte_t ptep_get(hw_pte_t *ptep)
>>  {
>>
> 
> I mean, how many such users do we expect? 1? :)
> 
> Why have a helper for that then, that seems to encourage it's use, when really
> people should be using ptep_get() ?

There is only 1 direct dereference case and even that is for non-MMU case.
That's really good point. I'll keep using __pte_from_hw() and put a comment
in huge_ptep_clear_flush() that use of this must be avoided at all cost. An
API can be introduced in case more users arrive.

-- 
Thanks,
Usama



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 11:21:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 11:21:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391040.1631093 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wupyV-0005Ws-Qo; Fri, 14 Aug 2026 11:21:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391040.1631093; Fri, 14 Aug 2026 11:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wupyV-0005Wl-OE; Fri, 14 Aug 2026 11:21:23 +0000
Received: by outflank-mailman (input) for mailman id 1391040;
 Fri, 14 Aug 2026 11:21:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wupyU-0005Wf-Ez
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 11:21:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wupyT-003oz4-RQ
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 13:21:21 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7efa15-2eae-0a2a0a5409dd-0a2a45068f82-44
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 13:21:21 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7efa31-195a-0a2a45060019-c387df83e944-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 13:21:21 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 1B7543E9F;
 Fri, 14 Aug 2026 11:21:13 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EDF3178354;
 Fri, 14 Aug 2026 11:21:12 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ukDxOCj6fmrsVQAAD6G6ig
 (envelope-from <jgross@suse.com>); Fri, 14 Aug 2026 11:21:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786706477; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=uqM+SEeoIgGsnc9b8j5Cm/QgrCM55AP/V7MNXproo6Q=;
	b=k7J07LnzSenGkjy1owYUPpn/6yssnzVpe917xf/pHjA1lWPi0+K/qR4MvIZXz5tCVv7/qU
	yVFUU0HaS523rvB+95Wd4V89ZkK3bhi8iHdhWgeldPe+S8BWMEHvga01Wubh9DLfE6iKOS
	RAuyQJUCQAPNR7u1pyx2/0wfHLBzgLE=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786706473; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=uqM+SEeoIgGsnc9b8j5Cm/QgrCM55AP/V7MNXproo6Q=;
	b=gu3chl3WGQ+r2CZoQfe0No34y0j17cAJ6XwrcVBjiuydGsiHRA75gGU4P3yUfc41XUdzsb
	HHKMgTlHSQu/tWgMYrdzketbAACc/oA18PgSG+Bu+yhVhyOatGOE9UU6S4V8W2vj8qJ5Xl
	lVGPFnfwNx79yVxRa9WoUXrlQ89IHuY=
From: Juergen Gross <jgross@suse.com>
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	sstabellini@kernel.org
Subject: [GIT PULL] xen: branch for v7.3-rc1
Date: Fri, 14 Aug 2026 13:21:11 +0200
Message-ID: <20260814112112.4042845-1-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -3.30
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-3.30 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]
X-purgate-ID: tlsNG-16d1c6/1786706481-F4A0477B-982D1407/0/0
X-purgate-type: clean
X-purgate-size: 2155

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.3-rc1-tag

xen: branch for v7.3-rc1

It contains the following changes:

- A small cleanup patch of the Xen ACPI pad driver

- A small cleanup patch of the Xen gnttab driver

- A 2 patch series fixing an issue with Xen PV device initialization seen
  with QubesOS tests

- A fix of the Xen balloon driver

- A small series simplifying Xen related kernel configuration

- A fix of the xenbus driver


Thanks.

Juergen

 arch/x86/include/asm/idtentry.h   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  |  2 +-
 arch/x86/xen/Kconfig              | 12 ++----------
 arch/x86/xen/Makefile             | 11 +++++------
 arch/x86/xen/time.c               |  2 --
 arch/x86/xen/xen-ops.h            |  4 ----
 drivers/xen/Kconfig               |  6 ------
 drivers/xen/Makefile              |  2 +-
 drivers/xen/balloon.c             | 29 +++++++++++++++++++----------
 drivers/xen/events/events_base.c  |  7 -------
 drivers/xen/grant-table.c         |  4 ++--
 drivers/xen/privcmd.c             |  4 ++--
 drivers/xen/xen-acpi-pad.c        |  5 -----
 drivers/xen/xenbus/xenbus_probe.c |  8 +++++---
 drivers/xen/xenbus/xenbus_xs.c    | 16 ++++++++++++----
 include/xen/platform_pci.h        |  6 +++---
 include/xen/xen-ops.h             | 22 ----------------------
 17 files changed, 53 insertions(+), 89 deletions(-)

Jan Beulich (1):
      Xen/gnttab: adjust two uses of sizeof()

Juergen Gross (4):
      x86/xen: Remove redundant config dependency on X86_LOCAL_APIC
      xen: Drop CONFIG_XEN_PVHVM
      xen: Drop CONFIG_XEN_AUTO_XLATE
      x86/xen: Drop CONFIG_XEN_PVHVM_SMP

Marek Marczykowski-Górecki (2):
      xen/xenbus: log more information when device state got reset
      xen/xenbus: check otherend_id only after it has been initialized

Rafael J. Wysocki (1):
      ACPI: PAD: xen: Stop setting acpi_device_name/class()

Roger Pau Monne (1):
      x86/xen: fix init of balloon stats again

Yuho Choi (1):
      xenbus: Unregister reboot notifier on init failure


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 13:19:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 13:19:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391126.1631111 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuro4-0004da-T7; Fri, 14 Aug 2026 13:18:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391126.1631111; Fri, 14 Aug 2026 13:18:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuro4-0004dT-QG; Fri, 14 Aug 2026 13:18:44 +0000
Received: by outflank-mailman (input) for mailman id 1391126;
 Fri, 14 Aug 2026 13:18:43 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wuro3-0004dM-DW
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 13:18:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuro1-001IQc-Vh
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 15:18:42 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f15ad-e002-0a2a0a5209dd-0a2a45098340-20
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:18:41 +0200
Received: from [98.137.68.147] (helo=sonic302-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f15af-be1a-0a2a45090019-62894493a09d-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:18:41 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Aug 2026 13:18:39 +0000
Received: by hermes--production-ne1-6dbcb84f44-rfx9b (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 417548e2e1190c980fd08d9070b940d0; 
 Fri, 14 Aug 2026 13:18:34 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786713519; bh=rzNM7wrNIM1ZAo3lFVCGJnUCLF2XiQRYvmh/CjNxmIE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=lHsvcmtBIBHevgRJpwopk/WC7UXs3NCDIkL6ZQsWCPxEoQevEbOl7uSGCO8azpJZDvwqrZXmL0e4BeQz2MgIgncwsh/47kKFXlQxJ700byMQL/Y5BrVUdOwsh6R2Pa4t9y506SpoLZj1FIh9IgMlbMcrI60Sp9fP3cs6S2fCgVQn6oCvKvbEMRlMkYQWtZyvggRJiIyOf9hiH7321shwjPKUa6VsmKA7NcfyVkBuvqLi5Hmb/5hRd7h4JsvlRMGqRJnIXEaTc+OILfKMoTY1lQH9OxRupX3XYWOHg2ADqAFmM4faHA/GuijbaTTVk/iP5d6Gb0HAebsfp+68KOnLog==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786713519; bh=SRfdPmMEftdtgGI8CmKwgeoibl5WUmfX+908MSE94Qi=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=Sc6t4Oz+3fYeQA2N07uB9QpC2p9sVApB8SzAgDOYwa1osnVhVsrwBddgIAy7Axyj6RwEUjm/23awi95wtovyiLXUOINUgSoY9JsPFumVQT7UwkJWoSkvOvbyYElf7h+kOT99xdWb8sXc+N6M3h3Yk1zAlMsav7Sm1Op69nmFlgDXetH7AJhT4tHZDKzuDkwXpDSMRwPqJaDn1MZnhVWGtlcqoohUrjotfOg99YDEtELtql5FJEK7Ce5EhHRSO8RUZRc7B3oHmt38WEBFyhNeO9Mxyia6sE/gHIEj6+TRvokOuBlZB62CCqAN2ogn4lhYzQeW9t01GtegLpEQNv5Y1g==
X-YMail-OSG: kTBiCAoVM1mEGyd65SZUN0OSW9oZm4N3pVBq1xF73yCSm3yoXQW4Juu4J6yAazc
 CaOR3jTd5TgchZn0RXO4UJoVDPg9cbld06ETA2XZ9s0jItjW6w8o6syH4MqBtDcg9Xp5shjw7vRB
 9ilxgKx61446vKf6.bwARyTbAfLcMDztwB.vZubVvS2pkm9S0bJ5cHdC117.AwDD0xMJ4Cx_m5y1
 gvem_WkqFbcnJy7E75AEeIn_3v062DkFQTvx5uH4_jYgGf_PikzsX9ECZ8i3gayp6Es66qv_7jpu
 v_v9rBS85c0TYHS_xqEoAJUXGOs6EyH8LkY7OEW3PkY44wVX2IUSIefK4GHDAAJ1_FcmNvrNrhjY
 c6V120T8H5Dzl1WSJSzgq3iVlu4ADY5hk3oOwtYO.hR2M0zIyg46pyMv7h2uIhFdu8iOexX0Yuwf
 c.eYlBn9vNrVacHY7oL_0LsHuoYmkPzKbsHfYBgbKWKoPArpB3cT.gaV4Td9xseINTZDmI7xe9Jc
 3E8JT3kOJ_39FS11Y7868Rb9.11ABGcpOg5uIBu5y7c0bqdtOpvVBN9nVX.3XXTJQyY_REMuWDN_
 y5RMAhusNA49_JE3XNi0qUhcFgGTqvPJd9s_vg18MfMGN9o2N_5j3nmxtxFNaEOeFwqaCNUF34vF
 HH2UpUSOfusu4o0FNpqxbeCeA2l9CoHY9sEUF9RlxOLNy1X9iWORHONbHqdXLLeX7hob4iB8Kld6
 87j94ea2kf2Yl_R6.ub0oYYQHhMBEaR_YIL7Z4KgVQXtFXkT8n0i6wzo.TPHEBbG0gvUy8VWAdgA
 7XcMN3kVABXVS9K5hSlAYAZyhEeRAGBob8AFe05CaE.cJFedYfnriB1A_BFzcWPNlodEbAE0Bdrb
 NFOdNWRRjmrMpvAqA0YIqOE2Qz0yTILY.ozXyv0cSHPgM6cye5ru.YyJv4nFwdoQ0pGGqpvjCuCb
 vDq2EsiI9Awpk2MbeP6ZjnRwpBvalj4L.nbONgQ1_Y6mVDc7O1vkmbwDsoGkdPtUEmblwyVhIZYu
 9Mq8GaR2OL.56A36l0bpzSxiesZb1Q4qiOyMhSDa9zoRILDPTj43uOWGSamh2J4OylWkzM1jq84Q
 LEIARn00q9eBnnLZhV6K.jspVh5gBbI1Lybwky.5XFtnxm_aYOMk2i7p0KGWa5Ofcca11hDgYy4a
 OkhG0cRuO2S7ZQmoY6cJl4eFyGHMdtiwFuJnRhz1C4XFiwXb_aHhQFdfmvaY28xdaY5qVPe45Hz0
 lcygru.2A7LRtT6AmI3SL29OuJZYNZC9Y3Do3bZRIV1IXuwh8pzqFCTps4pA_L2lJ2iJnPiL9sUx
 EoESvng2LfULg60LgdjgPjtzavOuky86jkLEgb0_KfBVVNb6gTlQy61I29cXDbPFZGs2yWNsET4j
 3E02M85ilR8qtFbEdIjysxkzIrBaXeoyXLTiIo3OmTb.xRNl_aQp_MjqHidqU_lJDYAc2c7zoJG2
 uQW9DD7bQ7EXjauX5UgBpgTuBLdD5DTG.C_GiGFRdlSrM2T9E9Adwnvx3ru.7NNFKBNSeM9mmf4O
 _gb90USbJPIbq_vSj5u8xzGozR3cLElpMgRTsDTi52VeyMnK7_JyMPwy2HpPZ_dO3aJEgo3Ok8XW
 OsBM36KDle5Ax_uTd3ue8JBh_1GRqfDomS.yejKr0lLwyOB1eLtMhVU00ZfF8KUiONtbBFAmDTv4
 ReYE7vVwrbwqvGLzBgufgSD6wmcFK7aHH7Gf69sGgY8SzJIyXzHI3ed9ISO.JeRGzb599cSHFVxu
 7_uVA3GwBLhGSeMlfaCQnQRc6FzDi5XGJFf6_ZZEOY65Y3sXa2DQp605NoKyCn9FpJuJ7AgWwwVI
 2yhy8y_p8Zp9DGpThv9roYerjbdx8Hd_KmOKmsF8lnIB_QjzL9Drqjh3RQkHP6eQ0.wMJJBEUwVn
 o7ZGxu_nMOY38q4hGiNDE5UoN5IsTqFCt8Gu.dqr596hqvKM0FysIBSRls6CnbWNKluakl6laXv3
 AYlnOSbWx5Np2DgIfGptPe6UOKYqIps0nfunCpLozB2xBOjqYBNETe5hxE5.8Wsn6PK63Tgb_x7J
 XTqMat_7_o7FvN68XfV5UJ6Aotf3OFQt8ZZiZnmGj_r0FqxvSbcV.FcQBk1iztEk4h6l6VSXzQUS
 hNu4kW.oy1T0k6jdzQ4rcIwRdUZ8CG1NvB0rst0M6.JAxTQQhOKwqm6xCrTYZINjNcHUxrlYIv8e
 uPqJaLvei4AcIihtwQp1aoYu_lElP3rsnsws7dgwQ9.6klTgd
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: bbc3b853-d096-4694-a59f-59507dee7903
Message-ID: <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
Date: Fri, 14 Aug 2026 09:18:34 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>, Chuck Zmudzinski <brchuckz@netscape.net>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 21058
X-purgate-ID: tlsNG-bad1c0/1786713521-BD8C1034-5BC8A910/0/0
X-purgate-type: clean
X-purgate-size: 21544

On 8/14/2026 3:35 AM, Jan Beulich wrote:
> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>> -- snip --
>>>> To address this problem, this patch implements support for
>>>> Intel IGD devices with an extended VBT and OpRegion version 2
>>>> and higher which is required for most modern Intel IGD devices.
>>>
>>> First of all: Where's the spec of all of this?
>> 
>> Well, your first question is quite provocative. Certainly more
>> social/legal than technical.
> 
> Well, it was very much meant to be technical. I've had a hard time following
> what your new code does, and having a spec to hand would likely have helped.

I agree that having the spec at hand would be better. To be more precise, I
can say that what this patch essentially does is port the support for
the extended VBT with OpRegion 2+ for the Intel IGD passthrough that exists
in KVM/vfio to Xen. Should I explicitly say in the title of the commit
message that this is a port of KVM/vfio support for extended VBT to Xen?

> 
>> I presume by "all this" you mean code in this patch such as:
>> 
>> #define IGD_OPREGION_RVDA 0x3ba
>> #define IGD_OPREGION_RVDS 0x3c2
>> #define IGD_OPREGION_VERSION 0x16
>> 
>> which defines the offsets of the rvda, rvds, and version fields from
>> the base address of the Intel OpRegion.
>> 
>> Also, I presume that "all this" includes the meaning of the 8-byte
>> rvda value, the meaning of the 4-byte rvds value, and the meaning of
>> the 2-byte version value.
> 
> "All this" certainly goes beyond this, i.e. also covering the intended
> interactions.
> 
>> So my answer is as follows:
>> 
>> I do not have access to the official spec that defines "all this" but
>> I do have access, as does the general public, to the Linux kernel's
>> implementation of support for the Intel IGD from many sources such as
>> git.kernel.org. The Linux kernel has enough accurate information about
>> the spec of "all this" to provide very good support for the Intel IGD
>> on bare metal.
>> 
>> To elaborate a bit more, the spec of "all this" can be derived from the
>> Linux kernel code that supports the Intel IGD.
> 
> So you expect every reader to locate and decipher the underlying information
> from a (afaik) pretty large piece of code in the Linux kernel? If the Linux
> kernel sources are the reference, please can you at least provide pointers
> into there?

No, I do not expect every reader to decipher the underlying information...

That is why I provided these two links at the bottom of the commit message.
Perhaps you did not notice them:

Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/

They are the patches to the vfio kernel driver that added support for the
extended VBT for KVM/vfio guests. I could provide links to more patches, such
as the ones in Qemu, Seabios, and patches provided by Intel to support extended
VBT in builds of OVMF for the Qemu/KVM platform, but I thought the two patches
above are sufficient for the purpose of this patch. For example, in those patches,
the #defines I added to config.h in hvmloader are included in the two links
I added to the bottom of the commit message.

I think adding more patches to the commit message would make it more difficult to
decipher the essential information needed to do this port of support from KVM/vfio
to Xen. Those two patches are not so large and they do provide the information
needed to add support for the extended VBT on a virtualization platform such
as KVM or Xen. How best to implement such support for the current Xen platform
is what we should focus on in these discussion.

> 
>>>> --- a/tools/firmware/hvmloader/config.h
>>>> +++ b/tools/firmware/hvmloader/config.h
>>>> -- snip -- 
>>>>  #define PAGE_SHIFT 12
>>>>  #define PAGE_SIZE  (1ul << PAGE_SHIFT)
>>>> +#define tools/hvmloader/pci.c3
>>>> +#define IGD_OPREGION_SIZE ((IGD_OPREGION_PAGES - 1) << PAGE_SHIFT)
>>>
>>> This is odd, and hence wants a comment.
>> 
>> Yes, I could add a comment, probably a long one, to explain this
>> oddity. It is a problem of backward compatibility where we have a
>> definition, IGD_OPREGION_PAGES, that is currently set to 3 both here
>> in hvmloader and in the Qemu DM, but should be 2 because the OpRegion
>> size is really exactly two pages but the current implementation set it
>> to 3 because the host OpRegion is not always aligned on a 4k page
>> boundary so three pages are needed to map the entire host OpRegion to
>> the guest. I could re-write the patch setting IGD_OPREGION_PAGES to 2
>> and avoid a comment here, but that would complicate the logic of how
>> igd_opregion_e820_pages is calculated and probably introduce the need
>> for comments in other places. 
>> 
>> I am open to suggestions about how best to handle the backward compatibility
>> problem and the problem of ensuring compatibility between hvmloader support
>> for Intel IGD passthrough and DM support for that same feature. For now,
>> however, I am trying to keep what is applicable to the current implementation,
>> and this odd value of 3 for IGD_OPREGION_PAGES is one of those things
>> I am keeping for backward compatibility.
> 
> Personally I don't view breaking backward compatibility as an option. Hence
> a comment is going to be needed, and preferably not an overly long one.

OK.

> 
>>>> +#define IGD_OPREGION_RVDA 0x3ba
>>>> +#define IGD_OPREGION_RVDS 0x3c2
>>>> +#define IGD_OPREGION_VERSION 0x16
>>>> +#define IGD_OPREGION_MASK 0xfff
>>>> +#define IGD_OPREGION2_SUPPORT_MASK 0x1
>>>> +#define IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
>>>> +#define IGD_VBT_SIGNATURE "$VBT"
>>>> +extern unsigned long igd_opregion_pgbase;
>>>> +extern uint32_t igd_opregion_e820_pages;
>>>> +void intel_opregion_setup(uint32_t vga_devfn);
>>>
>>> Blank lines please ahead of the new #define-s you add and between those new
>>> #define-s and the new decls.
>>>
>>> For igd_opregion_e820_pages I further cannot spot any use which would justify
>>> the use of a fixed-width type; unsigned int will do, and will then be in line
>>> with ./CODING_STYLE.
>> 
>> Ok I will pay more attention to CODING_STYLE. I know that libxl
>> has a specific CODING_STYLE document. Is there a specific one
>> for hvmloader? I do not see one in the tools/firmware/hvmloader
>> directory. I assume the one that matters for hvmloader is the
>> one at the top level of the Xen code source tree, not the libxl one.
> 
> Yes, hvmloader follows (better: ought to follow) hypervisor style.

OK.

> 
> 
>>>> --- /dev/null
>>>> +++ b/tools/firmware/hvmloader/intel_opregion.c
>>>> @@ -0,0 +1,297 @@
>>>> +/*
>>>> + * intel_opregion.c: HVM Intel OpRegion setup.
>>>> + *
>>>> + * Leendert van Doorn, leendert@watson.ibm.com
>>>> + * Copyright (c) 2005, International Business Machines Corporation.
>>>> + *
>>>> + * Copyright (c) 2006, Keir Fraser, XenSource Inc.
>>>
>>> What do these cover?
>> 
>> I am considering this new file to be a modified/derived version of
>> tools/hvmloader/pci.c, so if I understand correctly this file needs
>> to retain the copyright information of tools/hvmloader/pci.c. At the
>> very least, the #include statements at the top of this new file which
>> are from tools/hvmloader/pci.c are covered by these copyrights. I also
>> consider the statements that are moved from tools/hvmloader/pci.c to
>> this new file to be covered by these copyrights. IANAL, so to be safe,
>> I include these copyrights even though the covered code is relatively
>> small compared to the rest of the file.
> 
> Nowadays our preferred option is to omit such copyright statements
> altogether, but we wouldn't insist on the omission. I further don't think
> #include-s are copyrightable.

Ok.

> 
>>>> +    static unsigned long rvda_host;
>>>> +    static unsigned long rvda_guest;
>>>
>>> Why static? The function can't be called more than once, if I'm not mistaken.
>> 
>> I think you are right that we only do the setup once so I will
>> drop static here. I still think if I drop static I will want to
>> initialize these to zero later, because (correct me if I am wrong)
>> only static variables are initialized to zero if not explicitly
>> initialized, and without either static or an initialized value,
>> these would be initialized to some undetermined random value
>> until explicitly set to the desired initial value. Of the two,
>> I think that the more important one to intitialize to zero is
>> rvda_host, because I use an initial value of zero for that variable
>> to test for the case when we do not need extended VBT support.
> 
> Well, like all variables, these ones also will need to be sensibly
> initialized. That's entirely unrelated to the use of static; all
> static gets you in this regard is that there's implicit default
> initialization. Yet that alone is no reason to use static.

Ok.

> 
>>>> +    igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
>>>> +    /*
>>>> +     * Tentative value for the number of pages to reserve
>>>> +     * in the E820 map for the OpRegion and VBT.
>>>> +     *
>>>> +     * This will be the final value for the E820 map if
>>>> +     * the device model lacks support for OpRegion 2 or
>>>> +     * if the host OpRegion version is < 2 or if we never
>>>> +     * allocate more pages in the E820 map for the VBT.
>>>> +     */
>>>> +    igd_opregion_e820_pages = IGD_OPREGION_PAGES;
>>>> +
>>>> +    /*
>>>> +     * Read the value the device model is initialized with.
>>>> +     * If the device model supports OpRegion 2, it will
>>>> +     * return the host IGD OpRegion address. If not, it
>>>> +     * will return 0. If the device model does not support
>>>> +     * OpRegion 2, the device model expects us to give it
>>>> +     * the address to which it will map the OpRegion in the
>>>> +     * guest and then expects us to do nothing more to setup
>>>> +     * the OpRegion, so that is all we will do in that case.
>>>> +     */
>>>
>>> Hmm, exposing the host opregion to a guest certainly feels like an issue.
>> 
>> Well, that is how it is now. I am only retaining it to maintain backward
>> compatiblily with DM versions that do not support the extended VBT and
>> OpRegion 2+. My previous comment about backward compatibilty and DM
>> compatibility also applies here. If we don't worry about that, we can do
>> away with any cases where we are permanently mapping the host opregion to
>> the guest and implement this new approach of always exposing a copy of
>> the OpRegion and VBT to the guest instead.
> 
> How does "permanently mapping" matter? hvmloader runs inside the guest, so
> exposure just to copy the data isn't any better in terms of this being a
> layering violation. The more correct thing to do might be for the DM to
> put in place a copy before the guest (i.e. hvmloader) even gains control.
> (How in turn the DM would learn of the contents of the opregion is a
> separate question then.)

OK.

> 
>>>> +    const uint32_t igd_host_opregion = pci_readl(vga_devfn,
>>>> +                                                 PCI_INTEL_OPREGION);
>>>> +    if ( !igd_host_opregion ) {
>>>
>>> Nit (style) Brace placement (throughout).
>> 
>> Ok. I see this is not the proper coding style.
>> 
>>>
>>>> +        printf("device model lacks extended VBT "
>>>> +               "support. Continuing with legacy support only\n");
>>>
>>> This message can easily confuse / worry people. (If it was to be kept, it
>>> would also need style adjustment.)
>> 
>> I think some message is needed here to indicate the incompatibility of
>> versions of the DM that do not support the extended VBT with versions
>> of hvmloader that do, especially if we are not going to worry as much
>> about the backward compatibility / DM compatibility problem I mentioned
>> multiple times in previous comments above.
>> 
>> This message could encourage upgrading the DM to a version that supports
>> the extended VBT instead of just giving this scary notification.
> 
> But someone expecting legacy behavior could be misguided by the message
> (e.g. into wondering whether there's something wrong.)

It may take a while to arrive at what exactly the message should say here.
I will think about it and propose what seems reasonable in the next version.

> 
>>>> +    const uint32_t igd_host_opregion_page_offset =
>>>> +                   igd_host_opregion & IGD_OPREGION_MASK;
>>>
>>> I think like in the hypervisor we don't want to mix declarations and
>>> statements just yet.
>> 
>> The only way I could separate the declaration from the statement would be
>> to drop the const modifier because if I do:
>> 
>>     const uint32_t igd_host_opregion_page_offset;
>> ...
>>     igd_host_opregion_page_offset = igd_host_opregion &
>>                                     IGD_OPREGION_MASK;
>> 
>> The compiler will report an error. If I drop the const modifier from
>> the declaration, the compiler will not report an error but I lose the
>> protection the compiler gives me from making mistakes by modifying a
>> variable's value that should be constant.
>> 
>> I am not a C guru but some research indicates that while it is legal in
>> C to declare a variable with the const modifier without also assigning
>> it a value at the same time with a statement, it is not recommended to
>> do this because the variable will be initialized with some undefined
>> random value that cannot be changed because we used the const modifier
>> in the declaration. This implies strict enforcemnt of the rule "we
>> don't mix declarations and statements" results also in the corollary
>> rule "we never use the const modifier for variables in C."
> 
> Indeed we rarely use const on variables (or parameters) themselves. It's
> primary use is on pointed-to types.

Ok.

> 
>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>>>> +                IGD_OPREGION2_SUPPORT_MASK);
>>>
>>> This looks to imply qemu is the only possible device model.
>> 
>> Yeah, this is an issue. Other device models that intend to support
>> the Intel IGD with hvmloader will also have to be compatible with this.
>> It would be easier if we did not have to worry about backward
>> compatibility and supporting what we had in the codebase for many years
>> in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
>> in that case. Instead, we would just completely deprecate all previous
>> implementations of the Intel IGD passthrough feature in both hvmloader and
>> the Qemu DM as unsupported. So my previous comments about backward
>> compatibility apply here again.
> 
> As said, I don't think backward compatibility can be dropped. My comment
> also didn't really mean to hint in that direction. Instead I was wondering
> in how far, even if perhaps by only a few #define-s, the necessary
> interfacing couldn't be put down in a public header, for any DM to consume.

Ok. Perhaps the IGD_* defines could be moved to a public header to define the
interface to be used to support the Intel IGD. Would it be OK to move those
to a separate igd.h header and include it in hvmloader/config.h?

> 
>>>> +    printf("guest OpRegion tentative "
>>>> +           "address: 0x%x\n", igd_guest_opregion);
>>>> +
>>>> +    if ( !verify_opregion(igd_guest_opregion) ) {
>>>> +        printf("error: IGD OpRegion signature "
>>>> +               "not found.\n");
>>>
>>> No full stop in messages please.
>> 
>> Would it be OK to just get rid of the error message here?
> 
> That would then leave ...
> 
>>>> +        BUG();
> 
> ... an un-annotated BUG(), which generally isn't very nice.

I don't think I understand what you mean by "No full stop in messages..."

We have code like this in hvmloader/e820.c:

    if ( rc || !nr_entries )
    {
        printf("Get guest memory maps[%d] failed. (%d)\n", nr_entries, rc);
        BUG();
    }

> 
>>>> +    }
>>>> +   --snip --
>>>> +        rvda_host = 0;
>>>> +    }
>>>> +    const uint32_t rvda_host_page_offset = rvda_host &
>>>> +                                           IGD_OPREGION_MASK;
>>>
>>> Why host_page_offset here when ...
>>>
>>>> +    const uint32_t rvds = *(uint32_t *)(opregion_scratch +
>>>> +                                        IGD_OPREGION_RVDS);
>>>> +    const uint32_t rvds_page_offset = rvds & IGD_OPREGION_MASK;
>>>
>>> ... it's just page_offset here, and when further you use it below to set
>>> rvda_guest?
>> 
>> The size of the VBT, rvds, is the same on both host and guest, so we do not
>> need to specify host or guest, but the base address of the VBT, rvda, is
>> not the same on the guest as it is on the host, so we need to specify which
>> one for rvda. I can change this to rvds_host_page_offset because it is
>> not wrong, but it might be confusing because I use that value later on
>> for computations involving the guest also.
> 
> Why not simply drop the "host" infix, when it's not relevant?

Ok.

> 
>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>> +
>>>> +    if ( !rvds || !rvda_host ) {
>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>> +        rvda_host = 0;
>>>> +    }
>>>> +    /*
>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>> +     * to communicate location of the VBT to the device
>>>> +     * model. If rvda_host is not 0, The device model
>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>> +     * after we also write the guest address where the
>>>> +     * VBT will be mapped.
>>>> +     *
>>>> +     * If we send rvda_host = 0 to the device model, it
>>>> +     * will assume we do not need OpRegion 2 support and
>>>> +     * it will not unmap the OpRegion.
>>>> +     */
>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>> +               (uint32_t)rvda_host_upper_32);
>>>
>>> Why would you need to communicate a host property to the DM?
>> 
>> The DM cannot access the host rvda value because it is only accessible
>> from the host kernel, and the DM is only a user-space process on the host.
> 
> I don't follow this: Anything the guest can access should also be accessible
> by its DM.

I think the host OpRegion is not currently accessible by the DM. On the KVM
platform, this is made possible via the kernel vfio driver and then Qemu exposes
the OpRegion to the guest using the Qemu FwCfg device interface. How should we make
the OpRegion and VBT accessible to the device model and then, to the guest, on Xen?
I think it could be done via the xen-pciback kernel driver. Should we do that
instead? I think to do that we would have to convince the kernel developers that
the Intel OpRegion, as you say, "should" be accessible by the Xen device model.
I can imagine them saying, why not use the vfio driver?

Teddy Astie, on the Cc: list for this patch, is actually working on this:

https://xcp-ng.org/blog/2024/04/18/iommu-paravirtualization-for-xen/

These decisions about the best approach to support the Intel IDG on Xen are
above my pay grade, obviously. I need some guidance here, please.

> 
>>>> +    /*
>>>> +     * Update the number of pages the device model
>>>> +     * needs to map for us to get a copy of the VBT.
>>>> +     *
>>>> +     * N.B.: Here, igd_opregion_pgbase is really the page
>>>> +     * base of the location where the device model will
>>>> +     * map the VBT.
>>>> +     */
>>>> +    uint32_t vbt_pages_needed = rvds >> PAGE_SHIFT;
>>>> +    if ( rvds & IGD_OPREGION_MASK )
>>>> +        vbt_pages_needed++;
>>>> +    if ( vbt_pages_needed > igd_opregion_e820_pages ) {
>>>> +        igd_opregion_pgbase = mem_hole_alloc
>>>> +                              (vbt_pages_needed - igd_opregion_e820_pages);
>>>
>>> Nit: Indentation.
>> 
>> Ok. It should always be a multiple of four spaces, I presume. I admit I did
>> not check that.
> 
> Not quite. Within a wrapped expression, you need to determine what I like
> to call the "anchor point". In a function call that's the start of the
> function name. The wrapped part of the expression would then start one
> extra level (4 spaces) deeper than the anchor point. Things are different
> when there are pending open parentheses: There the wrapped part of an
> expression starts with as many extra spaces as there are pending open
> parentheses, with the outermost pending open parenthesis being the anchor
> point. E.g. (taking the example above and adding extra wrapping in the
> function argument expression just for demonstration purposes):
> 
>         igd_opregion_pgbase = mem_hole_alloc
>                                   (vbt_pages_needed -
>                                    igd_opregion_e820_pages);
> 
> Or alternatively
> 
>         igd_opregion_pgbase =
>             mem_hole_alloc(vbt_pages_needed - igd_opregion_e820_pages);

Ok.

Thanks,

Chuck

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 13:25:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 13:25:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391136.1631120 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuruj-0006Dv-JE; Fri, 14 Aug 2026 13:25:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391136.1631120; Fri, 14 Aug 2026 13:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuruj-0006Do-Fg; Fri, 14 Aug 2026 13:25:37 +0000
Received: by outflank-mailman (input) for mailman id 1391136;
 Fri, 14 Aug 2026 13:25:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wuruh-0006Df-Ik
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 13:25:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wurug-00CihR-VS
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 15:25:34 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a7f1730-e002-0a2a0a5209dd-0a2a45079726-36
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:25:34 +0200
Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a7f174e-b4ea-0a2a45070019-d155da2fdd51-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:25:34 +0200
Received: by mail-ej1-f47.google.com with SMTP id
 a640c23a62f3a-c15b1da6b82so122782866b.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 06:25:34 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c212339636fsm104236366b.2.2026.08.14.06.25.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 06:25:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786713934; x=1787318734; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=wMEaVxlhuns8hkig2UsUJQAIUbQ2e1I1Zup33AB/514=;
        b=gX1Yk6MrJZ0YSD1Ryseb7B0cu/KZBQaZJJG+p8ww+shEHU5xna81L8IxWTsIqsUYDE
         TdIbCGkhXuYKUsu4nvdvGYf7jxwspM1g3pUvSU6EgO2mPdMfneAg1vip6nNAPzKj9mwF
         DI1AnmQYA0dspvFFcAv82Z5tMrtqLfaD/ArTkFzJwfYwR2evRHyd4QYsT+0re8bnzruA
         bZ3eGuujVfnbcnINwg40zmFmeFyjOuCx9mKM62UbzGcdqfUD9L5YohOgelqUOrzr4HNF
         yGSwMMXiJUu1VPDxsSCZ2p8+T994I12rniP6klbGcqrR/DzzggrzXg/uba+rLcvvNLHF
         3lHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786713934; x=1787318734;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wMEaVxlhuns8hkig2UsUJQAIUbQ2e1I1Zup33AB/514=;
        b=rp2nRiPLT+gjJh95C23cSojjoctIaRZ1Vd23JFpCmLDuIzbW7vl97Ol4s0d+Ke/z/F
         Qy7/YQ53bSD/wh8XAhRQU3b8e6QQIAZWB+840DBvvht5BaA0fx+AVtGiKFpMTrPumM3R
         v0VU3XFL3HFRNI8EbyEQmbOW5a5Ry+eeqEN/+km0igCvGde1Vu8ru52q7V+JprFTFGD1
         k57g0vtC5h5UUcF+fGKxcO1a+hf92DL0L1suwqzPPl+1VpVnBhzOgW1fPZfKchMamjGe
         t4EOAF+WyB6+JSGEtCWAJELb0SWAB8IJ5Gik78yqvG4dyDmPonYGm8kj8hQ1INdl3jtI
         mC4g==
X-Forwarded-Encrypted: i=1; AHgh+RqLxjucAgOPeh+/7OxQvnKNr+EXfqx/qUxs/u2LQm7HiWW0oKvtX4u/FPifqwtR54NcPqITdcBoLPo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxSQmyZsYSp4VT24LCin2oUzCp+JCHsO7/gC7ia00cRSJYCZdAP
	kFDyefvB5Ah10YTo/Xomsc7PdPyWhPlAoaVkIafJQ9gihYmh+9ZCyACoi8HJw2SqmZQ=
X-Gm-Gg: AR+sD12ugDA2DEKHS9nOkSU/LDCQglRpwujYHptoPIKUG2OaPySwN0kebBsQTTAaTTV
	kUQVo9kMH+jlxkknA9dnZ79aJH9jx0VUnjsqQ6aKyLarHr1n4TD8qMmzcqfhSrxjfnOTDOXilUC
	CxJw2Xlgoa/l8ugzZeF6lDWOhoxl3hToVLfbAZ5TbdK87Qgl6VbPwWqZmx5FzpuYuzl3bTFjd8W
	MJm9mL/Qz5iYzHmKZawl1trdCGyi6K+QCFxrOYaN2lJJZr1FyLhw3xxyUKvZrxLCeapSpYQ1aCR
	bqD32iUoaIY5x6Z6npyn8VSlyXquCyn2xomp0NoBwKgfCFwynBSYZQdm34p+HlxIuFAdWlFoAM0
	+wZH33v+VFLUFjw3AwmVnW7swje87/UCKtOCPu70e92bWGb19fsX6IfWy3h+dff0pCemsUks/m9
	ZZBDVBiwtrPolgVKv7tFo4aJAQUbXDzLr9wB0T0OA3RbCmBqxMMHx+9JDFjVtPn+08wi3o6KvUx
	9rIirDCn5oNOR+nBpGcSYxEAuljRmWA48LCO9dnkCNx5I4hYgtLEYAp4ExKoaBQrTC/kYDuhDq2
	AKvsdC9jfgycjA==
X-Received: by 2002:a17:906:fe43:b0:c1c:5c90:1bad with SMTP id a640c23a62f3a-c212a154559mr268829266b.14.1786713934359;
        Fri, 14 Aug 2026 06:25:34 -0700 (PDT)
Message-ID: <4b7ee4e9-7a38-401d-9b9e-371173e8165c@suse.com>
Date: Fri, 14 Aug 2026 15:25:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/pcifront: Fix PCI device reference leak in AER
 handling
To: Ruoyu Wang <ruoyuw560@gmail.com>, xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 bhelgaas@google.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20260813153138.3953222-1-ruoyuw560@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260813153138.3953222-1-ruoyuw560@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------QkHGccM4PCCVbRXCFyU4NGNi"
X-purgate-ID: tlsNG-ef75cf/1786713934-A68D9AE4-E15D3077/0/0
X-purgate-type: clean
X-purgate-size: 7259

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------QkHGccM4PCCVbRXCFyU4NGNi
Content-Type: multipart/mixed; boundary="------------IAEm0KX69fq5JmryQhnoqDqx";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Ruoyu Wang <ruoyuw560@gmail.com>, xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 bhelgaas@google.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Message-ID: <4b7ee4e9-7a38-401d-9b9e-371173e8165c@suse.com>
Subject: Re: [PATCH] xen/pcifront: Fix PCI device reference leak in AER
 handling
References: <20260813153138.3953222-1-ruoyuw560@gmail.com>
In-Reply-To: <20260813153138.3953222-1-ruoyuw560@gmail.com>

--------------IAEm0KX69fq5JmryQhnoqDqx
Content-Type: multipart/mixed; boundary="------------e6EjXp9l0KI8S0BNgoOoL0MO"

--------------e6EjXp9l0KI8S0BNgoOoL0MO
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTMuMDguMjYgMTc6MzEsIFJ1b3l1IFdhbmcgd3JvdGU6DQo+IHBjaV9nZXRfZG9tYWlu
X2J1c19hbmRfc2xvdCgpIGluY3JlbWVudHMgdGhlIHJlZmVyZW5jZSBjb3VudCBvZiB0aGUN
Cj4gcmV0dXJuZWQgUENJIGRldmljZS4gcGNpZnJvbnRfY29tbW9uX3Byb2Nlc3MoKSBkcm9w
cyB0aGF0IHJlZmVyZW5jZSBvbmx5DQo+IHdoZW4gdGhlIGRldmljZSBvciBpdHMgZHJpdmVy
IGlzIG1pc3NpbmcuIEFsbCBwYXRocyBmb3IgYSBib3VuZCBkZXZpY2UNCj4gZWl0aGVyIHJl
dHVybiBkaXJlY3RseSBhZnRlciBpbnZva2luZyBhbiBlcnJvciByZWNvdmVyeSBjYWxsYmFj
ayBvciBmYWxsDQo+IHRocm91Z2ggd2l0aG91dCBjYWxsaW5nIHBjaV9kZXZfcHV0KCkuIENv
bnNlcXVlbnRseSwgZWFjaCBBRVIgcmVxdWVzdCBmb3INCj4gYSBib3VuZCBkZXZpY2UgbGVh
a3MgYSByZWZlcmVuY2UgYW5kIGNhbiBrZWVwIHRoZSBkZXZpY2UgYWxsb2NhdGVkIGFmdGVy
DQo+IHJlbW92YWwuDQo+IA0KPiBTdG9yZSB0aGUgY2FsbGJhY2sgcmVzdWx0LCByZWxlYXNl
IHRoZSByZWZlcmVuY2UgYWZ0ZXIgY2FsbGJhY2sgZGlzcGF0Y2gsDQo+IGFuZCB0aGVuIHJl
dHVybiB0aGUgcmVzdWx0LiBUaGlzIGtlZXBzIHRoZSBkZXZpY2UgYWxpdmUgd2hpbGUgaXRz
IGNhbGxiYWNrDQo+IHJ1bnMgYW5kIGJhbGFuY2VzIHRoZSBsb29rdXAgb24gZXZlcnkgc3Vj
Y2Vzc2Z1bCBwYXRoLg0KPiANCj4gVGhpcyBpc3N1ZSB3YXMgZm91bmQgYnkgYSBzdGF0aWMg
YW5hbHlzaXMgY2hlY2tlciBhbmQgY29uZmlybWVkIGJ5IG1hbnVhbA0KPiBzb3VyY2UgcmV2
aWV3Lg0KPiANCj4gRml4ZXM6IDk1NmE5MjAyY2QxMiAoInhlbi1wY2lmcm9udDogWGVuIFBD
SSBmcm9udGVuZCBkcml2ZXIuIikNCj4gU2lnbmVkLW9mZi1ieTogUnVveXUgV2FuZyA8cnVv
eXV3NTYwQGdtYWlsLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9z
c0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------e6EjXp9l0KI8S0BNgoOoL0MO
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------e6EjXp9l0KI8S0BNgoOoL0MO--

--------------IAEm0KX69fq5JmryQhnoqDqx--

--------------QkHGccM4PCCVbRXCFyU4NGNi
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmp/F00FAwAAAAAACgkQsN6d1ii/Ey9I
yQgAju8yaOfqsyi6C4ahXULTuTk5AvglXAwL3z2+BD8jSyFkX5+zN4N4izExwQt85obHCcFRbKzL
jWuvSaIC5NR4v1YJDydGZeDdiR2wP4C0XTHEafps/quX58OkLOqVCnz61J7KPpaZAKWicUmtdTUX
3QDbVRjsiz4qpUe31kxlN8nNi33KZ7WM1BNHcg4wDVjTnIErTjQ3Nw8+X3/ErTexNcBxPO3Ed8JP
ErYudznnqO8oCXz5jRhA5YK/r6OsKu7kj8z7Vh/SqumIVzxGN5EoNVe4D2PPa5wsW7WBYSZJrbe/
YtGFT5Q4mYvLHSby4wBM2CGl1aSDTNkcdhiGZ2j5Ag==
=sLha
-----END PGP SIGNATURE-----

--------------QkHGccM4PCCVbRXCFyU4NGNi--


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 13:46:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 13:46:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391163.1631129 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wusEe-0000vJ-8J; Fri, 14 Aug 2026 13:46:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391163.1631129; Fri, 14 Aug 2026 13:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wusEe-0000vB-5I; Fri, 14 Aug 2026 13:46:12 +0000
Received: by outflank-mailman (input) for mailman id 1391163;
 Fri, 14 Aug 2026 13:46:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wusEc-0000v5-QU
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 13:46:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wusEc-00Dbhl-78
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 15:46:10 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7f1c1b-2eae-0a2a0a5409dd-0a2a4504aee6-12
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:46:10 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7f1c21-b57f-0a2a45040019-d155dd33bc63-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:46:10 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47f96c5b722so648093f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 06:46:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49989ae1ef2sm27190105e9.9.2026.08.14.06.46.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 06:46:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786715169; x=1787319969; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0YsDTahv4URfKLt37kOy8jHhvTySEzNjHEH99JLGqhY=;
        b=XPTdU5exn4vHdhLUxCbbpSVc3Vyc4lylfaGU/1BfyG343TUXUvLIsOZFIwyWRujQIN
         oJsYzhLI/yYGXgNt3/6vzGHVnw7XZ11M1x7I2ctMma9ePNpepBNlFVWPGU9dNzGTh+CS
         SODS3dEqJZQm+wfjiSb39JnWGbZC8bMNuXIbNyWKQbBdc9Y07gdPWonRicQLH/f53R5e
         1h1IYlmFHOdj3uplhG9GSlcUIdJtdfj3PkE03iwcJt6RiRhTw24mhjG/hg/c7zL4oB1c
         D9lG71OMtUmNDQapkP/RLOaOylzUrG7DdIObZWHpRDRzBD572ZGe0aau2C5BLcs25XQJ
         UdMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786715169; x=1787319969;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=0YsDTahv4URfKLt37kOy8jHhvTySEzNjHEH99JLGqhY=;
        b=DtJRI+rleNP5IRmqlODsaOMYiZrTy603IkYsp/keaEiIstfkzHR/3MftVvzG/KvbJ9
         qF7SMQYBWi4p4BVO6fBcLgQ3uN6q7s2hEPk+AJGqKoqqzNoXjU9Dz5IvfYG6PrCdWjw6
         sd3zewoorxIvY9k79Bw+/yal2/uxdVD8/ORpnDpoc7VZJXtRGo4ukY2Btpcq9vaiBsWe
         9pN+9AVmVkqmGepuPlkwFaP20RZOHjnCnq/5V5J66GVr92pGseiM1FFjQtZ9LWpIMpl0
         Dij4FYBB38Jusx9JSfg5STIhWVpt+mOIpw7awq2kCa1NMmiB5VOgN6tE+5MghF0RvPhj
         OG0w==
X-Forwarded-Encrypted: i=1; AHgh+RovVH5s9x2t6AnEceLGJLmR8dzHQJIEgwvYKHQFAD6Zucbyz2i3SmpAu+/5PzSIB0TnB5GM+p1L8TU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2oBmhuh0bdPe7D48TshTTSgr8QlxETY7DlSLy6sYfCJEwuWoK
	E4Y5d2ocmL8DO9BqOk5ajqmNiHhfBMK4/EL8UyNL961wUd2INyEhaG9PTZVEfmpGAQ==
X-Gm-Gg: AR+sD12FBCz5N+ILirf8rhY5EKnewtHjfFz1qKRPNIb0MQjMcxBvMXXDQXe2BJqFs2E
	x3MY4Dh5HEeaMdtmKTXZKA1k02L89GcctPEbdwKe3Q6lkqW70FodjzWjlzS6wuwstRTw7otcv3b
	NXvSkKoyWAR7Nw2SME8i/UCXDi04iREQEXN8m3q67V88nMEDTSwxvhoYA1HCtuZ/XM9RViUIS5e
	oXzIGrYHAbwHQGaVnQNLRowbCcXCWSD5lUvgbC0j+4KuR515i0UFHFbhUn8zPbzOhmkkbXVaBwC
	SPg6SBh3KmlD0dqBrDxddflk6cF6+XqUt3sXaf7TB/g8KclOUnxAd7+yc+K+Di57BsAori6Vx7S
	rb6PZZOiftBn5soE6KLumEt5Pr41ykxuyb8+ZnlJe5QkTkisFRv1Az+xlYIUfidwlx7TiUUi/2B
	OQaMIB/kA5Of9wK455CqzPWYJcJjH332lGWjOh+D+fNqA6INP7htx199/ATX4+B5egC3BxQR9o8
	m9aNhHQgl3MLvv8vs19Fh4U40FPVz5wct0Xkuthv2hAFBhsjVy6
X-Received: by 2002:a05:600c:620a:b0:495:6bc9:62b0 with SMTP id 5b1f17b1804b1-499879b9c2fmr88881595e9.17.1786715169438;
        Fri, 14 Aug 2026 06:46:09 -0700 (PDT)
Message-ID: <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
Date: Fri, 14 Aug 2026 15:46:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>,
 Anthony PERARD <anthony.perard@vates.tech>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org, Chuck Zmudzinski <brchuckz@netscape.net>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786715170-C14D3B50-1E78E41C/0/0
X-purgate-type: clean
X-purgate-size: 7894

On 14.08.2026 15:18, Chuck Zmudzinski wrote:
> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>> -- snip --
>>>>> To address this problem, this patch implements support for
>>>>> Intel IGD devices with an extended VBT and OpRegion version 2
>>>>> and higher which is required for most modern Intel IGD devices.
>>>>
>>>> First of all: Where's the spec of all of this?
>>>
>>> Well, your first question is quite provocative. Certainly more
>>> social/legal than technical.
>>
>> Well, it was very much meant to be technical. I've had a hard time following
>> what your new code does, and having a spec to hand would likely have helped.
> 
> I agree that having the spec at hand would be better. To be more precise, I
> can say that what this patch essentially does is port the support for
> the extended VBT with OpRegion 2+ for the Intel IGD passthrough that exists
> in KVM/vfio to Xen. Should I explicitly say in the title of the commit
> message that this is a port of KVM/vfio support for extended VBT to Xen?

Not in the title, as that would likely make it too long, but perhaps in the
description.

>>> So my answer is as follows:
>>>
>>> I do not have access to the official spec that defines "all this" but
>>> I do have access, as does the general public, to the Linux kernel's
>>> implementation of support for the Intel IGD from many sources such as
>>> git.kernel.org. The Linux kernel has enough accurate information about
>>> the spec of "all this" to provide very good support for the Intel IGD
>>> on bare metal.
>>>
>>> To elaborate a bit more, the spec of "all this" can be derived from the
>>> Linux kernel code that supports the Intel IGD.
>>
>> So you expect every reader to locate and decipher the underlying information
>> from a (afaik) pretty large piece of code in the Linux kernel? If the Linux
>> kernel sources are the reference, please can you at least provide pointers
>> into there?
> 
> No, I do not expect every reader to decipher the underlying information...
> 
> That is why I provided these two links at the bottom of the commit message.
> Perhaps you did not notice them:
> 
> Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
> Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
> 
> They are the patches to the vfio kernel driver that added support for the
> extended VBT for KVM/vfio guests.

Patches can still be in flight, so provide only limited help. Would it be a
problem to instead reference commits, or the actual localtion in Linux
sources?

>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>>>>> +                IGD_OPREGION2_SUPPORT_MASK);
>>>>
>>>> This looks to imply qemu is the only possible device model.
>>>
>>> Yeah, this is an issue. Other device models that intend to support
>>> the Intel IGD with hvmloader will also have to be compatible with this.
>>> It would be easier if we did not have to worry about backward
>>> compatibility and supporting what we had in the codebase for many years
>>> in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
>>> in that case. Instead, we would just completely deprecate all previous
>>> implementations of the Intel IGD passthrough feature in both hvmloader and
>>> the Qemu DM as unsupported. So my previous comments about backward
>>> compatibility apply here again.
>>
>> As said, I don't think backward compatibility can be dropped. My comment
>> also didn't really mean to hint in that direction. Instead I was wondering
>> in how far, even if perhaps by only a few #define-s, the necessary
>> interfacing couldn't be put down in a public header, for any DM to consume.
> 
> Ok. Perhaps the IGD_* defines could be moved to a public header to define the
> interface to be used to support the Intel IGD. Would it be OK to move those
> to a separate igd.h header

This may require input by others, as in the given situation I'm not quite
sure what is best. Anthony - do you possibly have any suggestion here?

> and include it in hvmloader/config.h?

I don't see why that would be needed. The few files which need the #define-s
can include that new public header, without impacting anything else.

>>>>> +    printf("guest OpRegion tentative "
>>>>> +           "address: 0x%x\n", igd_guest_opregion);
>>>>> +
>>>>> +    if ( !verify_opregion(igd_guest_opregion) ) {
>>>>> +        printf("error: IGD OpRegion signature "
>>>>> +               "not found.\n");
>>>>
>>>> No full stop in messages please.
>>>
>>> Would it be OK to just get rid of the error message here?
>>
>> That would then leave ...
>>
>>>>> +        BUG();
>>
>> ... an un-annotated BUG(), which generally isn't very nice.
> 
> I don't think I understand what you mean by "No full stop in messages..."

That's the period at the end of a sentence (when in log messages the term
"sentence" is of questionable nature).

> We have code like this in hvmloader/e820.c:
> 
>     if ( rc || !nr_entries )
>     {
>         printf("Get guest memory maps[%d] failed. (%d)\n", nr_entries, rc);
>         BUG();
>     }

Well, you'll almost always be able to find bad pre-existing examples.

>>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>>> +
>>>>> +    if ( !rvds || !rvda_host ) {
>>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>>> +        rvda_host = 0;
>>>>> +    }
>>>>> +    /*
>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>> +     * to communicate location of the VBT to the device
>>>>> +     * model. If rvda_host is not 0, The device model
>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>> +     * after we also write the guest address where the
>>>>> +     * VBT will be mapped.
>>>>> +     *
>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>> +     * it will not unmap the OpRegion.
>>>>> +     */
>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>
>>>> Why would you need to communicate a host property to the DM?
>>>
>>> The DM cannot access the host rvda value because it is only accessible
>>> from the host kernel, and the DM is only a user-space process on the host.
>>
>> I don't follow this: Anything the guest can access should also be accessible
>> by its DM.
> 
> I think the host OpRegion is not currently accessible by the DM.

Can you explain to me how the region becomes accessible to the guest?
That would then (hopefully) help me understand why the DM would not have
access. Fundamentally any MMIO and any I/O ports that are assigned to a
guest are also assigned to its DM.

> On the KVM
> platform, this is made possible via the kernel vfio driver and then Qemu exposes
> the OpRegion to the guest using the Qemu FwCfg device interface. How should we make
> the OpRegion and VBT accessible to the device model and then, to the guest, on Xen?
> I think it could be done via the xen-pciback kernel driver. Should we do that
> instead? I think to do that we would have to convince the kernel developers that
> the Intel OpRegion, as you say, "should" be accessible by the Xen device model.
> I can imagine them saying, why not use the vfio driver?

I can't answer this; all I can say is that it feels wrong to involve e.g.
xen-pciback here.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 13:47:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 13:47:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391171.1631137 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wusGB-0001QW-H3; Fri, 14 Aug 2026 13:47:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391171.1631137; Fri, 14 Aug 2026 13:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wusGB-0001QP-EO; Fri, 14 Aug 2026 13:47:47 +0000
Received: by outflank-mailman (input) for mailman id 1391171;
 Fri, 14 Aug 2026 13:47:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wusGA-0001QH-QQ
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 13:47:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wusGA-004CpO-7L
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 15:47:46 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7f1c4f-8faa-0a2a0a5109dd-0a2a450a9788-38
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:47:46 +0200
Received: from [209.85.128.173] (helo=mail-yw1-f173.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7f1c81-f2d2-0a2a450a0019-d15580adb8cb-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 15:47:46 +0200
Received: by mail-yw1-f173.google.com with SMTP id
 00721157ae682-836cd7310f4so14792377b3.2
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 06:47:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786715264; cv=none;
        d=google.com; s=arc-20260327;
        b=ekF/Wjy8/9BcJBtpbrhmYgd6eOcqlsgwwr2i6GiIvdXFrtpqRZ8k8Ol1JeX2Onpl1A
         T2//6Nkx3NZat9PQR/Ivkzc4x07LYeTsJ9QzkRTQa2i+LoKff2Afu4YkFtW97UiwmhEk
         VMW+OX1KQ7LwpUE+CMKRvEQm4YsT0DVZn1YT6iW2/iI6IL9kdrqbBusYyH9f0hy0lOtr
         D3oV90zJm2TQIZwcPt+ZCEhrgSw2lsC1dl0Yfzmv2a+uWSR9bFO2nikwoAISz15XuBfv
         gp0hQCc497fAc6x1NUHafIvI/rw/QijuMKpwW8wWm43IaLrqsogIUNvWNQ4hTrKFEs0q
         KHSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=W2YadiQYSzgyYJ9IK/rYVW4O2YXcHVheqwPBtyy4/vE=;
        fh=XLNOpo6s19qwRxdIwryUTiROZT17MZF7LmKEa/QUxms=;
        b=mvYosD1o5VJW0a1YzjdoDyxTTj1Vjf52fAMoQBMVQEo0E3d+JRmhw3CZo+OdCjAzUd
         Qgwf9njh7y97FGrWtCLhHq9odH551LRGweNZ/WScAXivsTbIHwTOroKWkUJEMavwi7j7
         apHGKiQoiSxgAY0A2JFkzpRH292f+kC4PkXZbQhjZ/Dx0qAI5amw8RfJNAFmUm7g5j2W
         hSVQd0uCOy4d7tUv5tWgwiz8zok136geJfe11/J5IswrF3Vmf2wXZudipRbFZnbv5RNB
         tp77x0/vp23bOu+KuSrFu+oq7p2eZmABhG/epvOI4jZBM3eCMKluc5huIecPbN3Xg8Wx
         72Wg==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786715264; x=1787320064; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=W2YadiQYSzgyYJ9IK/rYVW4O2YXcHVheqwPBtyy4/vE=;
        b=Tbgq3naGbGK0YgkVd796wUlZxilMl/N5ALNipsozNs30kyrGWKRIx/5oAoretBXKML
         WTVD3qLjP88cy/wwL3GbohPjclTm6oBpZTZcPmJ8Y207+R1RDvLRAGKMR3ITnJg6s3/t
         80n3Lmj1+O5Pq05xPBoYW9RpVHtE8/71pmIwzrxHR72XfkZNVrdZteAUbIGTg43OSyVF
         jOBqE6J6fO982NSneauHz70FvVpP+8c0pVDgY9/zwX6c5BN24wWcPZveWvZFUMnjLyYa
         JjQ5pEbo7h72ilZTj/QKhhWHqAk55jHoKEixWARdXVANQHOi52A3qk8k6yLxd/GJ5pn+
         0yBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786715264; x=1787320064;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=W2YadiQYSzgyYJ9IK/rYVW4O2YXcHVheqwPBtyy4/vE=;
        b=oDYlOdjRoOI+nEZiHk9MtHg3lQVyhkLw6Avmxrb0SaF8/eg3ofSWhzJM/zRDqac//M
         5to5PK1wMgTZFWllrpWVLD54FsWBuiZE/t8KRxl/kJBHI6/DI5+/H30CqXiF3xK/HY/A
         kPE9cUapOEfCTH2c+DlrWEjBShdJEwaWfuAXKV8bZaC85HUcA5cWC40nAPpT31R2mQyn
         1BUVxyImtB/KTQyj7sAc6EIikj21LU8qEN67ocDBYLW3Kmt9dM/efQ0pjIWs8NQrKSSE
         DX+/NMdN/IPNVsWl8rx9UkMGjNRvrZGrGJXNDp+EEop6PR21ocXhtrsVk5UmMjfGVvMA
         3CkA==
X-Forwarded-Encrypted: i=1; AHgh+RrvVUPXfR+AVEuOsoGv4YVMALWYIcjHx5GVKo94o9psC6YjFt00tFdKUUVzrD9ti2ev27XyRCvnqX0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEsOzVmYzgasb+IHvaLsIonU0hYcIp/irUAMQEtW4rNS/av3O/
	fZzZ9JKmP5IF2RzYqXfWcliFyPsiJA6z2oc4cu8uoCISR0f7yt5T+iwMoYYW3Itkv0KPMGbPXni
	dbgKyDpQDups4HqrSCo9JdYC03DcA9AY=
X-Gm-Gg: AR+sD10YkBvQqUVxLlBEtkXkFVl+BaZkXVSiPHItyGtxfpzfdHWrtLaBu3+B/EDDcuD
	A2QF54pt1cMBfA90s4lM3KXKkUIuYPouCtCJxAgp3nkdDuVTMCfGD2pcIZBDg4o/fMMlVXCbh/1
	tyUe/uQW8JZGUgoQxG3DASWqsVjgJaL29dhYs/W4Hz6IYo23fp7KozLEBBU6C0J9DwAlGmGz9/p
	+o911p4kIj07HlIhNkcmJRuZ+iCxvoYWFkcEFq04H8YXvQNP9VUSWvphQSQhbxVM1Masa5Ddq39
	PfktU/rXSOFL7nwuJyJ5AqPNixTkZa1eLqgli3CxVFELGgT77AIaenrV1URlaZdSpaPh7vOOFHy
	+
X-Received: by 2002:a05:690c:6201:b0:81f:64cf:2c44 with SMTP id
 00721157ae682-8370e7827d3mr25159547b3.14.1786715264344; Fri, 14 Aug 2026
 06:47:44 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com> <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
 <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com> <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com>
In-Reply-To: <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Fri, 14 Aug 2026 14:47:32 +0100
X-Gm-Features: AUfX_mzzgD4tkUt6nS94v_gjfxJ98h07eQZao88M1BbKnnnC7DbMDEyB-JgKkds
Message-ID: <CAHt6W4dWQvSg1_XtkKowTcznUWs=-ApbvatV4YrQSKR8zJTA0A@mail.gmail.com>
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P . Smith" <dpsmith@apertussolutions.com>, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-4011c0/1786715266-52EDACFC-576CCCCA/0/0
X-purgate-type: clean
X-purgate-size: 11688

On Thu, 13 Aug 2026 at 15:22, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.08.2026 16:03, Frediano Ziglio wrote:
> > On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
> >> On 10.08.2026 12:30, Frediano Ziglio wrote:
> >>> Add a sub hypercall to __HYPERVISOR_memory_op to allow to read/write
> >>> memory from/to a foreign domain.
> >>>
> >>> Extending MMUEXT_COPY_PAGE seems better on first sight but considering
> >>> that MMUEXT is meant for PV only and trying to change that sub-op this
> >>> solution is better.
> >>>
> >>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> >>
> >> First: Can you please update your recipient list before sending a new version?
> >> Roger's move pre-dates this submission by quite a few days.
> >>
> >
> > Yes, updated, I realized it after sending it.
> >
> >> Then: The asymmetry of the new sub-op also continues to have no justification
> >> at all. If you insist on not using two (domid,list-of-gfns) tuples to describe
> >> the buffers, despite multiple maintainers having asked you to do so, please
> >> put down a word explaining that decision.
> >
> > All other maintainers, after replying to their comments didn't
> > disagree with me, and this was different versions before, so stop
> > counting them, it's only you that don't like this at the moment.
>
> None of this happened in public, though? In which case, how would I know?
>

The discussion with Terry happened in public. The ones with Roger
probably not, but as you knew it means that whoever reported to you
reported only half of it (or maybe at the time it was reported he
didn't know).

> >>> ---
> >>>  xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
> >>>  xen/include/public/memory.h |  45 ++++++++++-
> >>>  xen/include/xsm/dummy.h     |  14 ++++
> >>>  xen/include/xsm/hooks.h     |   2 +
> >>>  xen/xsm/flask/hooks.c       |  10 +++
> >>>  5 files changed, 219 insertions(+), 1 deletion(-)
> >>
> >> As before: If you insist on not implementing the compat case, that decision
> >> wants justifying in the description. Without that it'll look like an
> >> oversight.
> >>
> >
> > Yes, I was just going to reply.
> > I spent multiple days trying to implement the compat case or simply
> > HVM support with an issue after the other:
> > - multiple distributions removed the 32 bit support so it was hard to
> > have a setup;
> > - the original hypercall this PR is trying to optimise is supported
> > only in PV (so no HVM or compat guests);
> > - migration and other operations can work only on PV (like dm_op
> > operation) due to the usage of userspace handles used.
>
> I don't understand how use of guest (not userspace) handles would get in
> the way of anything.
>

In this case userspace is not a typo. For HVM
copy_from_user_hvm/copy_to_user_hvm are used and these functions
accept only kernel space pointers.

> > I tried to bypass the above limitations to have the new hypercall
> > tested and I manage to have 64 bit HVM working but the result is a
> > collection of nasty hacks and supporting them properly is a different
> > bigger task.
> > Surely a comment in the commit message on this is worth it.
>
> Thanks.
>
> >>> --- a/xen/common/memory.c
> >>> +++ b/xen/common/memory.c
> >>> @@ -1548,6 +1548,141 @@ static int acquire_resource(
> >>>      return rc;
> >>>  }
> >>>
> >>> +/*
> >>> + * The "noinline" qualifier avoids the compiler to create a large function
> >>> + * consuming quite a lot of stack.
> >>> + */
> >>> +static int noinline mem_foreigncopy(
> >>
> >> I'm wondering: Is the "mem" prefix really meaningful for a static function in
> >> a file named memory.c?
> >>
> >
> > Changed
> >
> >>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
> >>> +{
> >>> +    struct domain *d, *const currd = current->domain;
> >>
> >> With the comment on the new XSM hooks (below) in mind: currd wants to be
> >> pointer-to-const.
> >>
> >
> > Just rebased on master, all XSM hooks accept no-const pointers to domains.
> > So the suggested change would create warnings.
>
> Well, as per below, I pointed you at a particular pending patch, a single
> hunk of which could be broken out.
>

Yes, but my changes would have to have casts from const pointers to
no-const pointers to avoid warnings and the patch you are pointing to
would have to remove these casts. I find this less clean than having
one patch using the current code style (that is no-const pointers) and
another that changes the style entirely.
But obviously this is just my opinion.

> >>> +    xen_foreigncopy_t copy;
> >>> +    int rc, direction;
> >>
> >> Plain int for rc is fine of course, but direction can't go negative, can it?
> >
> > No, but the default type for constants is int and "flags" is promoted to int.
>
> Doesn't really matter. Unsigned types want using for values which can only
> be non-negative. IF nothing else, then for consistency and doc purposes.
>

Changed.

> >>> +            foreign = map_domain_page(foreign_mfn);
> >>> +            if ( direction == XENMEM_foreigncopy_from )
> >>> +                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
> >>> +            else
> >>> +                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);
> >>
> >> What I continue to be missing prior to this is the obtaining of a writable
> >> page ref. That's, as previously said, imperative for PV guests and at the
> >> very least advisable for HVM ones. (I really wonder how many more times I
> >> need to comment on this.)
> >
> > Unfortunately that does not work.
> > The code is coherent with MMU_UPDATE.
>
> How's that relevant? That's operating on page tables, when here we want to
> _prevent_ to copy into page tables (or descriptor ones, for that matter).
>

This new ABI is to better support migration.
We are migrating all the VM status including page tables... how can we
not be able to write them but migrate them from one  host to another ?
You are basically explaining why changing the check the migration fails.

> >>> --- a/xen/include/public/memory.h
> >>> +++ b/xen/include/public/memory.h
> >>> @@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
> >>>  typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> >>>  DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
> >>>
> >>> -/* Next available subop number is 29 */
> >>> +/*
> >>> + * Copy memory from/to a given domain.
> >>> + * This calls is meant to replace expensive operations during migration which
> >>
> >> Nit: "This call is ..." However, is ...
> >>
> >>> + * are only supported for PV guests.
> >>
> >> ... this entire sentence really worth to have here (it looks more like
> >> something to have in the description)? For it to be possible to find if
> >> someone considered using those "expensive operations", I think it would need
> >> to be less vague and name those operations. Furthermore, if those other
> >> operations were supported only for PV guests, how would migration work for
> >> non-PV ones?
> >>
> >
> > Maybe:
> >     This call is meant to replace expensive operations (mmap/copy/munmap) during
> >     migration which can only be issued from PV guests.
> >
> > You can migrate any domain. Just from a PV guest (this is not a regression).
>
> Both Andrew and Roger confirm that this is supposed to work also from PVH
> Dom0 (not sure why you keep saying "guest"), and also used to work. If it
> doesn't, it would be a regression, and it would help if you supplied more
> detail on the observed failure.
>

Indeed I tested the migration of various domains (PV, HVM, PV-in-PVH),
but only access to added hypercall from PV and HVM. I should add a
test from a PVH guest.
I say guest because to test HVM I used a hack to allow all guests (not
only dom0).

> >>> + */
> >>> +#define XENMEM_foreigncopy 29
> >>> +struct xen_foreigncopy {
> >>> +    /* IN - The domain whose memory is to be copied. */
> >>> +    domid_t domid;
> >>> +
> >>> +    /* IN - Flags. */
> >>> +#define XENMEM_foreigncopy_from 0
> >>> +#define XENMEM_foreigncopy_to 1
> >>> +#define XENMEM_foreigncopy_direction 1
> >>> +    uint16_t flags;
> >>> +
> >>> +    /*
> >>> +     * IN/OUT
> >>> +     *
> >>> +     * As an IN parameter number of frames of the domain to be copied.
> >>
> >> I think there's a comma wanted after "parameter".
> >>
> >>> +     * On output updated number of frames left (0 if success).
> >>
> >> I further think that adding "to" after "updated" would help here.
> >>
> >
> > Updated to
> >
> >     /*
> >      * IN/OUT
> >      *
> >      * As an IN parameter, number of frames of the domain to be copied.
> >      * On output updated to the number of frames left (0 if successful).
> >      */
> >     uint32_t nr_frames;
> >
> >     /*
> >      * IN/OUT
> >      *
> >      * Frames to be copied.
> >      * On output updated to the point to the first frame unhandled, if any.
>
> Nit: There's now a stray "the".
>

Removed, thanks

> >>> --- a/xen/include/xsm/dummy.h
> >>> +++ b/xen/include/xsm/dummy.h
> >>> @@ -569,6 +569,20 @@ static XSM_INLINE int cf_check xsm_map_gmfn_foreign(
> >>>      return xsm_default_action(action, d, t);
> >>>  }
> >>>
> >>> +static XSM_INLINE int cf_check xsm_foreigncopy_from(
> >>> +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
> >>
> >> I think these and ...
> >>
> >>> +{
> >>> +    XSM_ASSERT_ACTION(XSM_TARGET);
> >>> +    return xsm_default_action(action, d, t);
> >>> +}
> >>> +
> >>> +static XSM_INLINE int cf_check xsm_foreigncopy_to(
> >>> +    XSM_DEFAULT_ARG struct domain *d, struct domain *t)
> >>
> >> ... want to be pointer-to-const right away, requiring to re-base over "XSM:
> >> make Argo hooks well-formed ones" (or alternatively requiring to split out
> >> the change there to xsm_default_action()). We really should avoid gaining
> >> ...
> >>
> >>> --- a/xen/include/xsm/hooks.h
> >>> +++ b/xen/include/xsm/hooks.h
> >>> @@ -58,6 +58,8 @@ XSM_HOOK(int, add_to_physmap, struct domain *, struct domain *)
> >>>  XSM_HOOK(int, remove_from_physmap, struct domain *, struct domain *)
> >>>  XSM_HOOK(int, map_gmfn_foreign, struct domain *, struct domain *)
> >>>  XSM_HOOK(int, claim_pages, struct domain *)
> >>> +XSM_HOOK(int, foreigncopy_from, struct domain *, struct domain *);
> >>> +XSM_HOOK(int, foreigncopy_to, struct domain *, struct domain *);
> >>
> >> ... new hooks with non-const-correct parameters.
> >
> > It would honestly make sense if they were all const.
> > However at the moment this would not be coherent with the current code.
> > For instance these functions call "xsm_default_action" which does not
> > accept constant domains (xen/include/xsm/dummy.h).
> > I think the most clean thing would be first to change xsm arguments to
> > const first.
> > But it looks a bit out of scope with this PR.
>
> I'm not asking that you tidy up other hooks. What I'm asking is that new
> hooks please be const-correct. Yet of course I'm not a maintainer of XSM,
> so Daniel may tell you otherwise.
>
> >> Further: Why two new hooks? See e.g. "XSM: fold xsm_{,un}map_domain_pirq()
> >> hooks", "XSM: fold xsm_{,un}map_domain_irq() hooks", or "XSM: fold
> >> xsm_{,un}bind_pt_irq() hooks": We'd like to reduce the number of hooks, to
> >> reduce (when non-dummy XSM is in use) the number of cf_check entry points.
> >
> > It was a comment from Daniel.
>
> Daniel, can you clarify this please?
>
> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 14:13:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 14:13:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391197.1631147 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wusej-0005xv-Kf; Fri, 14 Aug 2026 14:13:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391197.1631147; Fri, 14 Aug 2026 14:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wusej-0005xn-HD; Fri, 14 Aug 2026 14:13:09 +0000
Received: by outflank-mailman (input) for mailman id 1391197;
 Fri, 14 Aug 2026 14:13:08 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wusei-0005xh-7p
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 14:13:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuseh-001RlB-0X
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:13:07 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7f2269-bab6-0a2a0a5309dd-0a2a4507c9ae-32
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 16:13:06 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a7f2272-b4ea-0a2a45070019-d155dd32a4f3-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 16:13:06 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47fde295992so799676f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 07:13:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f2c0a75sm9086953f8f.25.2026.08.14.07.13.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 14 Aug 2026 07:13:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786716786; x=1787321586; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=HIDgOlv81eXCnx4SEzDwYbaT0RePCbYVs8ke2n1X8Gc=;
        b=Vd6WtSS7n/zdJklaYORJuf9fwJ9Han7PumiXqpzj0gzts/B5/QSTI6BzIDuEbqGQBO
         w9bFwV7RSzmMBWkefCt3GG5sM3LvLEtViQjjGwQVf5KrbwQOG/z1suMszCTsDBqTCDIy
         u3oEKjCucmGl0FoKd4QyF/vS4Q4UGhqqCYRmWxNZCAvqoGOkcK402Yo22zTl7fLW1zx3
         1+JeQzXkdA6BgOsH5GcOm6YU59TQ9VfMrXRNVgtFU5UTlUCy8onmPLT33jTKCDyTN2Yr
         8bd1D/Qiaev4FNXGDHaSOzWhxZkk/hsVV1z5c+ump+nv8tFX5Owj3crzrd1qBwFYsXvx
         9JxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786716786; x=1787321586;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=HIDgOlv81eXCnx4SEzDwYbaT0RePCbYVs8ke2n1X8Gc=;
        b=BQPtnRibPAIBPVgoi6ZNWBVckmQbfTvihgQh0I97OZbiwp2P8m7MFWqE7yntsJcfDK
         7Pd5wzVQbpbjDcrZDNpf6XZOIetoY428CCAatue9vhI7Pe0bR6Q7BotHjqVa5eGbVCFg
         pAFwLghnN815Tzwo8jC/Y1k46gey2DegkzbGCvUxii+M1uAU9C6+MxgPd5vgh+7aOpgZ
         Cx8n7uxSOMNRjEBwXvfbdSwG87mEScO8hEraLTaKGFMyRWQNlGe+Z+LRSlcxHxZuAgIY
         Uq1N3931+k9aV0CBrfLZc7miA5m186MF6/gvAjzlIBWDLBolVkssHdiCcYrk2E60SGCk
         fDug==
X-Forwarded-Encrypted: i=1; AHgh+RpIkN69KzD19NTd2PHhDZsIzY5jwdnEAXC3qbuY7/7/JsIPG4NyKeYLxQ8OjiwIe/jDejrmYt855YU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySCr4AiV2YPi/od9y822RsdR8RE8x9pJJJEuybJcbS2pIXWSKj
	RCY5q9BTTodYOyjIcbX2VLL0HmZMnSQ3i6hkv8g8e+UqdW+5XAVkoYcyd40GLGJ+ng==
X-Gm-Gg: AR+sD138dpkV1MK6dCtzkbwSM7NAtlAz7y+dh7pgpz1Tgeu4anoOePUgEeMYlYuXwtV
	DgqbXKBh2wYQ+B/A2Y3PEAnBUNQISbrQHWbkfouapLyoTrZFyoKRBB77I34skJubDlUcXDNqZA1
	8pArV60ThQM7CSIH9vHj+MmmfPLKNUXCIsWignnlk4utWJ2CXLH/MmNaT5gNTixY4viBJB7to0S
	0Oxbn3LkFIOvzWZhds8Jzt5lO5KFl+gmwh9elM/TWb+V2wvqub+m73nsf4ii0p/9A3fr8iQlzBo
	AUWXvgx6xIkQQwO9CBdzJQweS9K642p0Xoa/kz7cBiOGIdGjsGMtD+to2i63sjtmynC9wgJINWO
	rtDXPM89Qds/8Vs/pErD0rH3MOYof3L7v0fTvpSzsV51mf1B8XOshicd5q0Q+BJkyOY111mH0gc
	irDcdUrWzoAg8BrbE2Q11JOk8Qg8NeBaNHHiYhQlwcLL3kho618EryPEBQ5d3ivm4vouNQZkwfe
	tUMlLU0oBXNI3VWuTi/y4xsSp5opolH8hc2S+V1r5P+V60vTIWS
X-Received: by 2002:adf:e189:0:b0:47f:ec53:1d2d with SMTP id ffacd0b85a97d-4815a4f981fmr21197989f8f.7.1786716786240;
        Fri, 14 Aug 2026 07:13:06 -0700 (PDT)
Message-ID: <e3d4f0a8-e95a-4dc3-8ca0-df857725d60d@suse.com>
Date: Fri, 14 Aug 2026 16:13:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Frediano Ziglio <freddy77@gmail.com>
Cc: "Daniel P . Smith" <dpsmith@apertussolutions.com>,
 Frediano Ziglio <frediano.ziglio@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>,
 xen-devel@lists.xenproject.org
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com>
 <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
 <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
 <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com>
 <CAHt6W4dWQvSg1_XtkKowTcznUWs=-ApbvatV4YrQSKR8zJTA0A@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAHt6W4dWQvSg1_XtkKowTcznUWs=-ApbvatV4YrQSKR8zJTA0A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786716786-A5EC6AE4-B1D0E8A0/0/0
X-purgate-type: clean
X-purgate-size: 6688

On 14.08.2026 15:47, Frediano Ziglio wrote:
> On Thu, 13 Aug 2026 at 15:22, Jan Beulich <jbeulich@suse.com> wrote:
>> On 13.08.2026 16:03, Frediano Ziglio wrote:
>>> On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 10.08.2026 12:30, Frediano Ziglio wrote:
>>>>> ---
>>>>>  xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
>>>>>  xen/include/public/memory.h |  45 ++++++++++-
>>>>>  xen/include/xsm/dummy.h     |  14 ++++
>>>>>  xen/include/xsm/hooks.h     |   2 +
>>>>>  xen/xsm/flask/hooks.c       |  10 +++
>>>>>  5 files changed, 219 insertions(+), 1 deletion(-)
>>>>
>>>> As before: If you insist on not implementing the compat case, that decision
>>>> wants justifying in the description. Without that it'll look like an
>>>> oversight.
>>>>
>>>
>>> Yes, I was just going to reply.
>>> I spent multiple days trying to implement the compat case or simply
>>> HVM support with an issue after the other:
>>> - multiple distributions removed the 32 bit support so it was hard to
>>> have a setup;
>>> - the original hypercall this PR is trying to optimise is supported
>>> only in PV (so no HVM or compat guests);
>>> - migration and other operations can work only on PV (like dm_op
>>> operation) due to the usage of userspace handles used.
>>
>> I don't understand how use of guest (not userspace) handles would get in
>> the way of anything.
> 
> In this case userspace is not a typo. For HVM
> copy_from_user_hvm/copy_to_user_hvm are used and these functions
> accept only kernel space pointers.

I fear you've now completely lost me.

>>>>> --- a/xen/common/memory.c
>>>>> +++ b/xen/common/memory.c
>>>>> @@ -1548,6 +1548,141 @@ static int acquire_resource(
>>>>>      return rc;
>>>>>  }
>>>>>
>>>>> +/*
>>>>> + * The "noinline" qualifier avoids the compiler to create a large function
>>>>> + * consuming quite a lot of stack.
>>>>> + */
>>>>> +static int noinline mem_foreigncopy(
>>>>
>>>> I'm wondering: Is the "mem" prefix really meaningful for a static function in
>>>> a file named memory.c?
>>>>
>>>
>>> Changed
>>>
>>>>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
>>>>> +{
>>>>> +    struct domain *d, *const currd = current->domain;
>>>>
>>>> With the comment on the new XSM hooks (below) in mind: currd wants to be
>>>> pointer-to-const.
>>>>
>>>
>>> Just rebased on master, all XSM hooks accept no-const pointers to domains.
>>> So the suggested change would create warnings.
>>
>> Well, as per below, I pointed you at a particular pending patch, a single
>> hunk of which could be broken out.
> 
> Yes, but my changes would have to have casts from const pointers to
> no-const pointers to avoid warnings and the patch you are pointing to
> would have to remove these casts. I find this less clean than having
> one patch using the current code style (that is no-const pointers) and
> another that changes the style entirely.
> But obviously this is just my opinion.

Such casts would be unacceptable. What instead I have been trying to convey:
Your patch wants to gain a dependency on my patch. And if my patch would
take too long to make it in, that one hunk could be broken out into a
separate, easy to get in patch.

>>>>> +            foreign = map_domain_page(foreign_mfn);
>>>>> +            if ( direction == XENMEM_foreigncopy_from )
>>>>> +                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
>>>>> +            else
>>>>> +                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);
>>>>
>>>> What I continue to be missing prior to this is the obtaining of a writable
>>>> page ref. That's, as previously said, imperative for PV guests and at the
>>>> very least advisable for HVM ones. (I really wonder how many more times I
>>>> need to comment on this.)
>>>
>>> Unfortunately that does not work.
>>> The code is coherent with MMU_UPDATE.
>>
>> How's that relevant? That's operating on page tables, when here we want to
>> _prevent_ to copy into page tables (or descriptor ones, for that matter).
> 
> This new ABI is to better support migration.
> We are migrating all the VM status including page tables... how can we
> not be able to write them but migrate them from one  host to another ?
> You are basically explaining why changing the check the migration fails.

No, what I'm trying to explain is that without such a check, you introduce
a security issue (of privilege escalation kind). I hope you agree that we
cannot knowingly allow such code to be committed.

To migrate-in page tables, you'd need to copy their contents before they
obtain their PGT_l<N>_page_table type, so that upon being converted to page
tables, they can be properly audited by the mm.c functions we have for that
exact purpose.

>>>>> --- a/xen/include/public/memory.h
>>>>> +++ b/xen/include/public/memory.h
>>>>> @@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
>>>>>  typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
>>>>>  DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
>>>>>
>>>>> -/* Next available subop number is 29 */
>>>>> +/*
>>>>> + * Copy memory from/to a given domain.
>>>>> + * This calls is meant to replace expensive operations during migration which
>>>>
>>>> Nit: "This call is ..." However, is ...
>>>>
>>>>> + * are only supported for PV guests.
>>>>
>>>> ... this entire sentence really worth to have here (it looks more like
>>>> something to have in the description)? For it to be possible to find if
>>>> someone considered using those "expensive operations", I think it would need
>>>> to be less vague and name those operations. Furthermore, if those other
>>>> operations were supported only for PV guests, how would migration work for
>>>> non-PV ones?
>>>>
>>>
>>> Maybe:
>>>     This call is meant to replace expensive operations (mmap/copy/munmap) during
>>>     migration which can only be issued from PV guests.
>>>
>>> You can migrate any domain. Just from a PV guest (this is not a regression).
>>
>> Both Andrew and Roger confirm that this is supposed to work also from PVH
>> Dom0 (not sure why you keep saying "guest"), and also used to work. If it
>> doesn't, it would be a regression, and it would help if you supplied more
>> detail on the observed failure.
> 
> Indeed I tested the migration of various domains (PV, HVM, PV-in-PVH),
> but only access to added hypercall from PV and HVM. I should add a
> test from a PVH guest.
> I say guest because to test HVM I used a hack to allow all guests (not
> only dom0).

And why would testing from PVH Dom0 not do?

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 14:51:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 14:51:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391229.1631159 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wutFE-00030l-C3; Fri, 14 Aug 2026 14:50:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391229.1631159; Fri, 14 Aug 2026 14:50:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wutFE-00030e-9V; Fri, 14 Aug 2026 14:50:52 +0000
Received: by outflank-mailman (input) for mailman id 1391229;
 Fri, 14 Aug 2026 14:50:50 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wutFC-00030X-GB
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 14:50:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wutFB-00Cvij-Hn
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:50:49 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7f2b29-2eae-0a2a0a5409dd-0a2a450990d8-34
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 16:50:49 +0200
Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a7f2b48-be1a-0a2a45090019-d15580b6c125-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 16:50:49 +0200
Received: by mail-yw1-f182.google.com with SMTP id
 00721157ae682-80c5cb9a888so11315017b3.3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 07:50:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786719048; cv=none;
        d=google.com; s=arc-20260327;
        b=FzH0G1BT+VXYGPqXKuAjUb0hvlaqowE6qxKV7goMjxqHOqjyHSWvjYk0+c2Qu4s3CT
         6hF4Ag5hII9YCEkCFCrisiCoOATfFGRZR9rPjf9HSN340VQrk8/v7h6YN44p/X7fdzDS
         tSaRgfw1R3yebrigma6SY86UbJK6z0AuoT+D7XKWMskw8W1GxIFc9cpyC/KWgo9VltER
         k+uXSCZPYiqP+ildSi4lkiaLZD3CO1o6515zM9o8qIZjzh2lFHc4dBn/Ku1RYqbHWnr/
         sPoK4wiBMd5LLtioTs0ZAO4EZH+OzvyU/UXT7Fe/eVqLIIXgvRy5wtXhlg300L7f8ts+
         yWvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=E/4yGc1GO/4xhyAkR/ReVly2tZXCtuDF0va2XZ3XnU0=;
        fh=+8uuvvAtGuYzkIe1S/eNSmuGQdVeF4D76F90SYKR0TE=;
        b=FPVB6n95kQL1X6UqQYu1sQjxA8ew7/qzZa7MmtqqFPz3AZcuucqxjaRvGTPslmj2RD
         RwYDHWsMKPdxXJM3ZlOlBvY89MjbwgaSnRRZp/gThXxjCeVBF/P8rpnQEPNKFurcmomm
         2FbMIOoPYF2dNyeTFIyEdb+LOrsdoR3SNrzbL3g9HiFCHUiTQ2XjpcMTtsE8qFpkZ+Vi
         hOqbWOu1xxjXqi+fTJAGUYfpUfTEQk6K/k0Timnze/CVl+n8JaniO4Nsmj+V23o5XsSy
         w7CHYJzj2116pTJIrhydS0hqm+3BSDI6a55NH8u6bwxZ6MC2BEhIEf6z3BdW06XPOCCI
         YxeA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786719048; x=1787323848; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=E/4yGc1GO/4xhyAkR/ReVly2tZXCtuDF0va2XZ3XnU0=;
        b=WsuJSwClN6yrCDxQa8IYxmmuIt1gZNBqR6WEYLfbWdrRoPJEqO7CB71DgFbldnAcqf
         gH7EdhOqKjf0RTusEMndEaaKm3+xL2KgOqo4Hz2710dAFLF3gJFeBL8lfjt/JEJD1af/
         tGRMQ4PrRul8GzbqyVxHv/B/TfXvdKHl8a9rIoFFHfAnNmO1IqcNEnYrp/onKffIoMrg
         ak8rl7iz4sWzDwJQC3gnO+nwn7UZy4N/Z1elNeMZ4z84ANtCFZ1Bh7SJv79SYeKlLqah
         FCv2NFWUGdPAGYZFASgitETIpB6kY3KAq/eHpsUBloZtKc2aVnZSSzbIFPtgSq8PKYiw
         j/xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786719048; x=1787323848;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=E/4yGc1GO/4xhyAkR/ReVly2tZXCtuDF0va2XZ3XnU0=;
        b=VgoURGPmadBacIikXbGfEd+DdYMgoOOQJRFNJ/s1k5ga1tJpyiWXWXu8UftM0OxBRC
         zropicdKseJA/ba6KwqaH/u04bbzhrOy0BvaIyca6XKhZ8k7zluO0OhAgBQRnhB3ghOz
         +ttq3hSdW8OUCkwsD/eJg9+bh8ze/SGhzpVGagoWDk6zPuQf+GuziK8XR9PbU0sd6km7
         bS90ePCVlPwOngZIJq9Abea1CeVqKiBaH4bY/kKPfjRAXGsciKx3LBAX1/2sZcGl+0/D
         qgwd/cbMrKPuZtdhSdMRBnRBhU44moR2thVv51oGWWcXtfpOQYcRqoH/DWgjwEIA3b4N
         YFIQ==
X-Forwarded-Encrypted: i=1; AHgh+RpFVjPbP+E/L7BuoAlvvlQs/klWfxrPf0I89XIP2LrNANCj8DV1ZNww4fyfJYBeJuttnIS+P3KXRzM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzZNdt7XEmPDk+DXZqbN+wwvx/5bMnR/nubeFyGVEoKoslB9cSO
	QpDOxtj+R4gBLviY5iQsJJNADofw1FMytlKrpDLs9R9ji+aUj8Mso2VqVpURxRoHBGKoraRphe+
	KDC5poZNsm40gL+dxZ5etG77S0CcGfJ4=
X-Gm-Gg: AR+sD10Xn7SAOP134Cwb4jQStWAsigOnAcY1CEFOmLeP+aE7AYJA0CrVKf7gdSxK3UT
	LzebLgXsITmEWuxrAJW+crbg7O7MBmGboe10A/TATb6sHibnyJOM7LLmscaaL11k0/xdFcR7xwR
	/KkWWuLhQ1OeQPCMM/o08DLKocyLBjMlevozlFJwro1s9+Fo/9iK6InmwNG6zFwq7+nVLJDLqkl
	augoxvZiMLdw6wNmxIRBJwLFGZ0zrhiO+e1Xa869ey9LurwjwU3tBpFc+k+ZcUdxqJdSDz0ZLFo
	VkLERXU975FHSUuquENzvw6nfb/3JmF9+UCjeQ+HCqMpDKh67YX08YzWnxoYjkTe589Vw6VF4Go
	G
X-Received: by 2002:a05:690c:6f07:b0:81e:98d3:cac7 with SMTP id
 00721157ae682-8370e1a4f82mr30979037b3.12.1786719047751; Fri, 14 Aug 2026
 07:50:47 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com> <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
 <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
 <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com> <CAHt6W4dWQvSg1_XtkKowTcznUWs=-ApbvatV4YrQSKR8zJTA0A@mail.gmail.com>
 <e3d4f0a8-e95a-4dc3-8ca0-df857725d60d@suse.com>
In-Reply-To: <e3d4f0a8-e95a-4dc3-8ca0-df857725d60d@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Fri, 14 Aug 2026 15:50:36 +0100
X-Gm-Features: AUfX_mxvtpWf_8OU8VEG4jSe6KsYbHmTadYhbDzZVsnYQd6VOrBl-wQLjkmnRnk
Message-ID: <CAHt6W4ftLMsk41zdwYUXEwN_JzzXHQG01vhSqutkgk8PO6xAQw@mail.gmail.com>
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P . Smith" <dpsmith@apertussolutions.com>, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-bad1c0/1786719049-FC212034-A753EA0D/0/0
X-purgate-type: clean
X-purgate-size: 8768

On Fri, 14 Aug 2026 at 15:13, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.08.2026 15:47, Frediano Ziglio wrote:
> > On Thu, 13 Aug 2026 at 15:22, Jan Beulich <jbeulich@suse.com> wrote:
> >> On 13.08.2026 16:03, Frediano Ziglio wrote:
> >>> On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 10.08.2026 12:30, Frediano Ziglio wrote:
> >>>>> ---
> >>>>>  xen/common/memory.c         | 149 ++++++++++++++++++++++++++++++++++++
> >>>>>  xen/include/public/memory.h |  45 ++++++++++-
> >>>>>  xen/include/xsm/dummy.h     |  14 ++++
> >>>>>  xen/include/xsm/hooks.h     |   2 +
> >>>>>  xen/xsm/flask/hooks.c       |  10 +++
> >>>>>  5 files changed, 219 insertions(+), 1 deletion(-)
> >>>>
> >>>> As before: If you insist on not implementing the compat case, that decision
> >>>> wants justifying in the description. Without that it'll look like an
> >>>> oversight.
> >>>>
> >>>
> >>> Yes, I was just going to reply.
> >>> I spent multiple days trying to implement the compat case or simply
> >>> HVM support with an issue after the other:
> >>> - multiple distributions removed the 32 bit support so it was hard to
> >>> have a setup;
> >>> - the original hypercall this PR is trying to optimise is supported
> >>> only in PV (so no HVM or compat guests);
> >>> - migration and other operations can work only on PV (like dm_op
> >>> operation) due to the usage of userspace handles used.
> >>
> >> I don't understand how use of guest (not userspace) handles would get in
> >> the way of anything.
> >
> > In this case userspace is not a typo. For HVM
> > copy_from_user_hvm/copy_to_user_hvm are used and these functions
> > accept only kernel space pointers.
>
> I fear you've now completely lost me.
>

Try to pass a handle to a userspace page and the functions above will
fail because they won't accept userspace pages.

In guest_walk_tables you have:

    if ( walk & PFEC_user_mode ) /* Requested a user access. */
    {
        if ( !(ar & _PAGE_USER) )
            /* Got a supervisor walk?  Unconditional fail. */
            goto out;

        if ( (walk & PFEC_write_access) && !(ar & _PAGE_RW) )
            /* Requested a write and only got a read? Fail. */
            goto out;
    }
    else /* Requested a supervisor access. */
    {
        if ( ar & _PAGE_USER ) /* Got a user walk. */
        {
            if ( (walk & PFEC_insn_fetch) && guest_smep_enabled(v) )
                /* User insn fetch and smep? Fail. */
                goto out;

            if ( !(walk & PFEC_insn_fetch) && guest_smap_enabled(v) &&
                 ((walk & PFEC_implicit) ||
                  !(guest_cpu_user_regs()->eflags & X86_EFLAGS_AC)) )
                /* User data access and smap? Fail. */
                goto out;
        }

        if ( (walk & PFEC_write_access) && !(ar & _PAGE_RW) &&
             guest_wp_enabled(v) )
            /* Requested a write, got a read, and CR0.WP is set? Fail. */
            goto out;
    }

and we don't have a PFEC_user_mode set.

> >>>>> --- a/xen/common/memory.c
> >>>>> +++ b/xen/common/memory.c
> >>>>> @@ -1548,6 +1548,141 @@ static int acquire_resource(
> >>>>>      return rc;
> >>>>>  }
> >>>>>
> >>>>> +/*
> >>>>> + * The "noinline" qualifier avoids the compiler to create a large function
> >>>>> + * consuming quite a lot of stack.
> >>>>> + */
> >>>>> +static int noinline mem_foreigncopy(
> >>>>
> >>>> I'm wondering: Is the "mem" prefix really meaningful for a static function in
> >>>> a file named memory.c?
> >>>>
> >>>
> >>> Changed
> >>>
> >>>>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
> >>>>> +{
> >>>>> +    struct domain *d, *const currd = current->domain;
> >>>>
> >>>> With the comment on the new XSM hooks (below) in mind: currd wants to be
> >>>> pointer-to-const.
> >>>>
> >>>
> >>> Just rebased on master, all XSM hooks accept no-const pointers to domains.
> >>> So the suggested change would create warnings.
> >>
> >> Well, as per below, I pointed you at a particular pending patch, a single
> >> hunk of which could be broken out.
> >
> > Yes, but my changes would have to have casts from const pointers to
> > no-const pointers to avoid warnings and the patch you are pointing to
> > would have to remove these casts. I find this less clean than having
> > one patch using the current code style (that is no-const pointers) and
> > another that changes the style entirely.
> > But obviously this is just my opinion.
>
> Such casts would be unacceptable. What instead I have been trying to convey:
> Your patch wants to gain a dependency on my patch. And if my patch would
> take too long to make it in, that one hunk could be broken out into a
> separate, easy to get in patch.
>

Okay, then the only choice that's left is the code producing warnings
as const pointers are passed to functions requiring no-const pointers.
Is this acceptable? Apparently as you are suggesting it it is.

> >>>>> +            foreign = map_domain_page(foreign_mfn);
> >>>>> +            if ( direction == XENMEM_foreigncopy_from )
> >>>>> +                rc = copy_to_guest(copy.buffer, foreign, PAGE_SIZE);
> >>>>> +            else
> >>>>> +                rc = copy_from_guest(foreign, copy.buffer, PAGE_SIZE);
> >>>>
> >>>> What I continue to be missing prior to this is the obtaining of a writable
> >>>> page ref. That's, as previously said, imperative for PV guests and at the
> >>>> very least advisable for HVM ones. (I really wonder how many more times I
> >>>> need to comment on this.)
> >>>
> >>> Unfortunately that does not work.
> >>> The code is coherent with MMU_UPDATE.
> >>
> >> How's that relevant? That's operating on page tables, when here we want to
> >> _prevent_ to copy into page tables (or descriptor ones, for that matter).
> >
> > This new ABI is to better support migration.
> > We are migrating all the VM status including page tables... how can we
> > not be able to write them but migrate them from one  host to another ?
> > You are basically explaining why changing the check the migration fails.
>
> No, what I'm trying to explain is that without such a check, you introduce
> a security issue (of privilege escalation kind). I hope you agree that we
> cannot knowingly allow such code to be committed.
>

Then the security issue is already present in the code without my changes.

> To migrate-in page tables, you'd need to copy their contents before they
> obtain their PGT_l<N>_page_table type, so that upon being converted to page
> tables, they can be properly audited by the mm.c functions we have for that
> exact purpose.
>

That makes sense.

> >>>>> --- a/xen/include/public/memory.h
> >>>>> +++ b/xen/include/public/memory.h
> >>>>> @@ -740,7 +740,50 @@ struct xen_vnuma_topology_info {
> >>>>>  typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
> >>>>>  DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
> >>>>>
> >>>>> -/* Next available subop number is 29 */
> >>>>> +/*
> >>>>> + * Copy memory from/to a given domain.
> >>>>> + * This calls is meant to replace expensive operations during migration which
> >>>>
> >>>> Nit: "This call is ..." However, is ...
> >>>>
> >>>>> + * are only supported for PV guests.
> >>>>
> >>>> ... this entire sentence really worth to have here (it looks more like
> >>>> something to have in the description)? For it to be possible to find if
> >>>> someone considered using those "expensive operations", I think it would need
> >>>> to be less vague and name those operations. Furthermore, if those other
> >>>> operations were supported only for PV guests, how would migration work for
> >>>> non-PV ones?
> >>>>
> >>>
> >>> Maybe:
> >>>     This call is meant to replace expensive operations (mmap/copy/munmap) during
> >>>     migration which can only be issued from PV guests.
> >>>
> >>> You can migrate any domain. Just from a PV guest (this is not a regression).
> >>
> >> Both Andrew and Roger confirm that this is supposed to work also from PVH
> >> Dom0 (not sure why you keep saying "guest"), and also used to work. If it
> >> doesn't, it would be a regression, and it would help if you supplied more
> >> detail on the observed failure.
> >
> > Indeed I tested the migration of various domains (PV, HVM, PV-in-PVH),
> > but only access to added hypercall from PV and HVM. I should add a
> > test from a PVH guest.
> > I say guest because to test HVM I used a hack to allow all guests (not
> > only dom0).
>
> And why would testing from PVH Dom0 not do?
>

Just that it's easier for me testing from a different guest.

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 15:24:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 15:24:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391253.1631169 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wutlA-0007ds-P5; Fri, 14 Aug 2026 15:23:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391253.1631169; Fri, 14 Aug 2026 15:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wutlA-0007dl-MF; Fri, 14 Aug 2026 15:23:52 +0000
Received: by outflank-mailman (input) for mailman id 1391253;
 Fri, 14 Aug 2026 15:23:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wutl8-0007df-Re
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 15:23:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wutl8-009zeZ-1H
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 17:23:50 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f3305-8faa-0a2a0a5109dd-0a2a4502ac6a-0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 17:23:49 +0200
Received: from [98.137.68.31] (helo=sonic308-55.consmr.mail.gq1.yahoo.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f3303-6ca4-0a2a45020019-6289441fabb9-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 17:23:49 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Aug 2026 15:23:47 +0000
Received: by hermes--production-ne1-6dbcb84f44-xtsvv (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID d1d2b98acc5c03388ed30a9ee0960e39; 
 Fri, 14 Aug 2026 15:23:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:References:From:Cc:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786721027; bh=kWABo+M8UTCM8OR7VjnLl19mzMxfmSiG8dC6uCq4Ie8=; h=Date:Subject:To:References:From:Cc:In-Reply-To:From:Subject:Reply-To; b=JTKBpC7w61n4lwWyzhlzKW32T8K134hxvSqWhYyki1r8MRXmzLy1NKl/m9W1twN0e0XI9jNX5Slq59xOFtaCaoL2GhoTJ1HRYVPM90vSLQtS0E35U1hkGpMmydKsqFEIprObkHKo2dxQ1wTF4zHm1u+rHQu7GLeMfS++nzGkC8jtexa7fR20ezLijgwS/oGFQ7pVO+hJCYKDCAbJg6tfoMJ04IFEqLRY4bo8tEUh+Ez9O1UrLM5EqqH9jVfTheRO9MaARO9yzpwr8xrbnR0+uVoLSb0Ba0/ijfH4eSMOZmJRk64G6W6xGMmjP3dZ4Z2RlwdU9AfhEe6EBtWAmv/1nA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786721027; bh=9X576LiXnRvQdmdVNRAnjKREUeBFxrVd8qV7sjoPk19=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=JA2HV5PZ71fw1ssYa2s/Z7gTJbaQvlQ6OTL5k01ibEV65vcMWQJhGGWOhAAtJGqC5AMx9kT3suHS4J3holqhc106c4AT8JMS+x0lfR+FsYlygHd5QqbfvGCCv/0SY0S/I8zyS9PjW/4Oc1xpBBcjXX8LuUifZkt+TxohpTc6B4AOWb1fe3p7FViBK/hUWMP4pEnS3Cv+vNuthshbeuf37rtmhNZUso2n7w9leBXW4T8m7mRJ7/hmVFYOZ1hAfa74x0S/9S//izxL5qWWwGsd4P3z6mVlJRxO8Bj/pqGZsJDp2rxAkyqC7egss1khSv3ilDM1sPrZr5do9mQCspbjNg==
X-YMail-OSG: X7iH8.8VM1mJ7dS_Szv82CuzafYlwVhKwEQPARIG6Tc6VtCAWIeA1KjV1nTTHYe
 bp50W0shTvTdVysfXAn0cUKJo7aejrmPH2rPaCcY9efNeQAHj2pwzV0rkYJHAwYU36Ra00BpAMFh
 eR1I6Zu5eWgX5ZjM3nnIKAW8hnFfuGgl2CHTVEwygrXuvl1Y6NfGRnZ4ubxAdTyQ6m9ZxNIt.GvU
 kY3FgXoAswASuaTN3zl0osIlohYhhxqvabnUaz.bzhfOiPukOu9f8X0ACHCKOXyFP.3C2r3q07pk
 oj3WPboPoQ0aQMRX.6S9oUO0qOfkr_VHgdgxLTK3zsVpZxx2FM0ehrxRuhS5CN45t1.Z4REJWnVU
 71DL8FCMnfIlfjZIafVFwuE6NOtBrLLddr0af80v5MMgl3Fb910s.d__StrrExrsH25xHUUPwd19
 4l7lXcuNQLJwzBcOYpeGCLHrCUI5Aa1YzY476TTGnid4fK7X0lLfcRmMQMX9m39iQY6baCSngMPl
 IsTW7psujJ6mIjaUMN1qn9U2_E501ctzbqU9s4yXYjSG45jlph11qjkRUW4W8KtEBYA751_wLSZ_
 8u21K23o1GbVcFzhRtLBBajkvzJIV3u.EJ7fE1CSDVmldbFbs0rk_Cx77vs0mCuAa4V0_xFFvwKi
 DHh.MBs8BXLPOucckixi5nRGN9642Pha5eEt9H51rTOx7w82Oy3Zk9C2iF9N62EnwWPJfla7eM.o
 SSlmotKbte2VQknzQFGEPoEGCjvS1n7LFzozoO.KDvDotugKrqVGhIwugs9NkJxXnrIgJ0XZvpBB
 .dwkBnNi8JO2ZTcZUpj0GXbn794u.nzpN969xiBXjoG.iiEGUdM7FC0ADR9zOtdLJU0t3iDe0mkm
 wtQouroEIIv.gwjCojqapksHlPqOKkWkh_bYp7Lwz62HLNghbFAgrMuVf_jbjnQtil8GOP132l0F
 BZcWF.jqxKGlo.zuXuGb4.xV84CYeFjXdWrwvs5Syzrt6B5Jj9OQeIIk5oIRquBHN6cwUXQEBYX3
 Mdd7p2hnOG7ltmhBTarHeiy8rLUvI5PSY1NN9dO2RJfJ2Tg2dxDi0QraiNqElkLDNMbMEn6sCfNJ
 IFrnCs.xGPkS72.xGmt8OLjxHi3hAasxFJe3TBI6vQZovr_iAg8AkOT9kOhde8165zsh14W.LqR1
 6yDTn8ypFCHekZYJVReWyKSHTQhB9pMd6ZAXQgHChsWu31mBieUTv4B0asjApLMWGEAgNRLzeO6i
 aSPLeZ0tzEaKSz2w1UlA4_t_iaXgmYAR7dA2BjZ6AVcVuz_B7wQBdbkeZITqozJdIBgl5PdKxPOT
 Y64vUlT4TIKQD4.wsahLGfQDtEIeYLCVSo8iRs5sFddSar.E3wfB46dg6QH5lhQy7.woFwsC1gW5
 NROxQnYHi.B_EpizyGivp0Fn7HT6S45lgf7mwL.Rhl1ggB3tA5TeW5_EjbNqzjSdcP_WPHJvjJF0
 idKIgvJQcgLFh4zNupeJn2g7XQ3JJys8IQ6Be1LrxlDbTyB3bis.Zmy3y3MalT7BpEZ1ZZWMVxEt
 fcAuLXZN_ja.9v4PcDywO79fli1jy7ppd5ylKTMvNhDKStM2WIhO5FHqCSNtPZxNmixTOur4L6Fm
 vUSGwTaAEp1s2eYg3EWFeia0iWprnmS1o5n7a1LZtv6jK_V6n4JsRXIXgKXW_9i4eI2D9bN5fldc
 v.AGtsHSp6yjsNr6nwu98oso4JI7xfY4I5E5j5pPDb5va_FAnGrd8fFmZ1y1xSsk9MtY_MW8M2Pa
 l1TuXX8Kz1w1D5gP55_cFyfrc52J23chrX2WD1.iqmGjFQEg.LVVNgdc3N7pgFR5Y_y3q5UXpHsw
 Si29mdyH42FmHEYSO.sy2PrNfytZAcZYBdEgGBmdpOHo19DAjHKTFu_NRzr1.kSsHBgQJ5k1338J
 HH9Wvn0kVxlc3XCbBUSv8gdeEMMK4JScnE0QyZxB5Bf67A3ttF3nnm8pnu2NuwViMSL5PBiYbw8q
 q7kpdW_zWFllX_xxvH66QDpfssrtwbi3jR3XtZtWWxjKoYbp8UihwybpvSPyUreANS2AWpsyp_pu
 fyjXKdF9pbpWhTMsR4INNLLRtHQoQRJtCB0YivNT3SpYU7ByWQnBySQ9nOchDkX.bep9RT2IJBdc
 24qCTzxc1W8xbvMu9N6CnnnljwfV36lep6XG95P74UdqtSCrEeJAnZQc4mzUbGjoy34O3SLn7IRm
 IUsADlNmE7tFp81zdhAgA8bNY8PrL8QouPBL8l9ldtYo7_SU-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 3bcd5e70-24d2-4964-8f13-551d301ac199
Message-ID: <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Date: Fri, 14 Aug 2026 11:23:44 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
In-Reply-To: <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 10453
X-purgate-ID: tlsNG-720697/1786721029-F10A02AC-9DECB10D/0/0
X-purgate-type: clean
X-purgate-size: 10689

On 8/14/2026 9:46 AM, Jan Beulich wrote:
> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>> -- snip --
>>>>>> To address this problem, this patch implements support for
>>>>>> Intel IGD devices with an extended VBT and OpRegion version 2
>>>>>> and higher which is required for most modern Intel IGD devices.
>>>>>
>>>>> First of all: Where's the spec of all of this?
>>>>
>>>> Well, your first question is quite provocative. Certainly more
>>>> social/legal than technical.
>>>
>>> Well, it was very much meant to be technical. I've had a hard time following
>>> what your new code does, and having a spec to hand would likely have helped.
>> 
>> I agree that having the spec at hand would be better. To be more precise, I
>> can say that what this patch essentially does is port the support for
>> the extended VBT with OpRegion 2+ for the Intel IGD passthrough that exists
>> in KVM/vfio to Xen. Should I explicitly say in the title of the commit
>> message that this is a port of KVM/vfio support for extended VBT to Xen?
> 
> Not in the title, as that would likely make it too long, but perhaps in the
> description.

Ok.

> 
>>>> So my answer is as follows:
>>>>
>>>> I do not have access to the official spec that defines "all this" but
>>>> I do have access, as does the general public, to the Linux kernel's
>>>> implementation of support for the Intel IGD from many sources such as
>>>> git.kernel.org. The Linux kernel has enough accurate information about
>>>> the spec of "all this" to provide very good support for the Intel IGD
>>>> on bare metal.
>>>>
>>>> To elaborate a bit more, the spec of "all this" can be derived from the
>>>> Linux kernel code that supports the Intel IGD.
>>>
>>> So you expect every reader to locate and decipher the underlying information
>>> from a (afaik) pretty large piece of code in the Linux kernel? If the Linux
>>> kernel sources are the reference, please can you at least provide pointers
>>> into there?
>> 
>> No, I do not expect every reader to decipher the underlying information...
>> 
>> That is why I provided these two links at the bottom of the commit message.
>> Perhaps you did not notice them:
>> 
>> Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
>> Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
>> 
>> They are the patches to the vfio kernel driver that added support for the
>> extended VBT for KVM/vfio guests.
> 
> Patches can still be in flight, so provide only limited help. Would it be a
> problem to instead reference commits, or the actual localtion in Linux
> sources?

No problem. I will format references to kernel commits the way it was done in
this commit message of commit 99794c8a8ff8 in the Xen tree that references
some Linux kernel commits unless you suggest a better way to reference Linux
kernel commits:

 xen/acpi: Import PPTT definitions from Linux

Import the Processor Properties Topology Table (PPTT) definitions
from the Linux kernel header (include/acpi/actbl2.h) into Xen.

Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git b8355bcac253
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git e62f8227851d
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 091c4af3562d


> 
>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>>>>>> +                IGD_OPREGION2_SUPPORT_MASK);
>>>>>
>>>>> This looks to imply qemu is the only possible device model.
>>>>
>>>> Yeah, this is an issue. Other device models that intend to support
>>>> the Intel IGD with hvmloader will also have to be compatible with this.
>>>> It would be easier if we did not have to worry about backward
>>>> compatibility and supporting what we had in the codebase for many years
>>>> in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
>>>> in that case. Instead, we would just completely deprecate all previous
>>>> implementations of the Intel IGD passthrough feature in both hvmloader and
>>>> the Qemu DM as unsupported. So my previous comments about backward
>>>> compatibility apply here again.
>>>
>>> As said, I don't think backward compatibility can be dropped. My comment
>>> also didn't really mean to hint in that direction. Instead I was wondering
>>> in how far, even if perhaps by only a few #define-s, the necessary
>>> interfacing couldn't be put down in a public header, for any DM to consume.
>> 
>> Ok. Perhaps the IGD_* defines could be moved to a public header to define the
>> interface to be used to support the Intel IGD. Would it be OK to move those
>> to a separate igd.h header
> 
> This may require input by others, as in the given situation I'm not quite
> sure what is best. Anthony - do you possibly have any suggestion here?
> 
>> and include it in hvmloader/config.h?
> 
> I don't see why that would be needed. The few files which need the #define-s
> can include that new public header, without impacting anything else.

So I would just include it in the new intel-opregion.c file. Also, maybe igd-related
declarations should be moved there too, such as the currently existing extern variable
igd_opregion_pgbase and my newly proposed extern variable igd_opregion_e820_pages,
which would mean the new header would also need to be included in hvmloader/e820.c.

> 
>>>>>> +    printf("guest OpRegion tentative "
>>>>>> +           "address: 0x%x\n", igd_guest_opregion);
>>>>>> +
>>>>>> +    if ( !verify_opregion(igd_guest_opregion) ) {
>>>>>> +        printf("error: IGD OpRegion signature "
>>>>>> +               "not found.\n");
>>>>>
>>>>> No full stop in messages please.
>>>>
>>>> Would it be OK to just get rid of the error message here?
>>>
>>> That would then leave ...
>>>
>>>>>> +        BUG();
>>>
>>> ... an un-annotated BUG(), which generally isn't very nice.
>> 
>> I don't think I understand what you mean by "No full stop in messages..."
> 
> That's the period at the end of a sentence (when in log messages the term
> "sentence" is of questionable nature).

Ok. I thought you were referring to the BUG() statement which fully stops
the guest.

> 
>> We have code like this in hvmloader/e820.c:
>> 
>>     if ( rc || !nr_entries )
>>     {
>>         printf("Get guest memory maps[%d] failed. (%d)\n", nr_entries, rc);
>>         BUG();
>>     }
> 
> Well, you'll almost always be able to find bad pre-existing examples.
> 
>>>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>>>> +
>>>>>> +    if ( !rvds || !rvda_host ) {
>>>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>>>> +        rvda_host = 0;
>>>>>> +    }
>>>>>> +    /*
>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>> +     * to communicate location of the VBT to the device
>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>> +     * after we also write the guest address where the
>>>>>> +     * VBT will be mapped.
>>>>>> +     *
>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>> +     * it will not unmap the OpRegion.
>>>>>> +     */
>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>
>>>>> Why would you need to communicate a host property to the DM?
>>>>
>>>> The DM cannot access the host rvda value because it is only accessible
>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>
>>> I don't follow this: Anything the guest can access should also be accessible
>>> by its DM.
>> 
>> I think the host OpRegion is not currently accessible by the DM.
> 
> Can you explain to me how the region becomes accessible to the guest?
> That would then (hopefully) help me understand why the DM would not have
> access. Fundamentally any MMIO and any I/O ports that are assigned to a
> guest are also assigned to its DM.

Currently, in the device model (Qemu) we have:

    ret = xc_domain_memory_mapping(xen_xc, xen_domid,
            (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
            XEN_PCI_INTEL_OPREGION_PAGES,
            DPCI_ADD_MAPPING);

That statement is in the igd_write_opregion(...) function in the
hw/xen/xen_pt_graphics.c file of the upstream Qemu source.

If I understand our current implementation correctly, this statement
is what gives the guest access to the host OpRegion (3 pages as defined
by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
in hvmloader code). I don't think this statement makes the host OpRegion
accessible to the device model, though, so I think, if I understand your
comment in an earlier about my patch resulting in what you called a "layering
violation" correctly, that our current implementation is also guilty of this
same kind of "layering violation."

So, how do you suggest we fix that?

> 
>> On the KVM
>> platform, this is made possible via the kernel vfio driver and then Qemu exposes
>> the OpRegion to the guest using the Qemu FwCfg device interface. How should we make
>> the OpRegion and VBT accessible to the device model and then, to the guest, on Xen?
>> I think it could be done via the xen-pciback kernel driver. Should we do that
>> instead? I think to do that we would have to convince the kernel developers that
>> the Intel OpRegion, as you say, "should" be accessible by the Xen device model.
>> I can imagine them saying, why not use the vfio driver?
> 
> I can't answer this; all I can say is that it feels wrong to involve e.g.
> xen-pciback here.

Ok. I guess we need to wait for other experts to weigh in here. I have never looked
carefully at what xen-pciback does. I suppose one of it's jobs is to hide access to
the resources of the passed through device from the dom0 kernel but I am just
guessing about that.

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 16:18:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 16:18:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391282.1631177 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuuc8-0006ez-Jt; Fri, 14 Aug 2026 16:18:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391282.1631177; Fri, 14 Aug 2026 16:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuuc8-0006es-HN; Fri, 14 Aug 2026 16:18:36 +0000
Received: by outflank-mailman (input) for mailman id 1391282;
 Fri, 14 Aug 2026 16:18:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wuuc7-0006em-ON
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:18:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuuc6-00GbkN-Ey
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:18:34 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f3fc6-bab6-0a2a0a5309dd-0a2a4503c846-24
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:18:33 +0200
Received: from [98.137.64.148] (helo=sonic301-22.consmr.mail.gq1.yahoo.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f3fd8-fae8-0a2a45030019-6289409497e9-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:18:33 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Aug 2026 16:18:31 +0000
Received: by hermes--production-bf1-54b5569bdc-z2x8g (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 4cc625440026d205cb1396754a1ab4df; 
 Fri, 14 Aug 2026 16:18:27 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786724311; bh=sZ2U0ZHbr1dOUcGv8Quuw66Z7ftlvoQtcvfayzdgWQw=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=Jvgo/H+jlQPsdqphZXsdSX/FlYIHbhT9JUyxuNlQKMwfWNZVEGe7Fct/xnz8DOycCW2YEK5+Sz45GuW7S3kLrMcS7qe5GJd/nLcYUndtdHcrxhRuAKqPh8ljlCWq/8KbGiT5aNryFmbF736Z84OFeZcQV9kUQgEwdm/373OpvQZwB5OSNex6HaofmaRqry7Jtr9cP318bIGIGXxVz30v0RCiqD5BcadjKyuN456XuKVUv5mXF3RY5drMC1zkIooDmXv5+q47pZlvvGI4L+TUvNViPPsII0bC879AwauILGDtfagbFPL+anJwo6C6pXfBp/XXvW/zD1Yw1F+VMIDRuA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786724311; bh=UTWYcY0Ukx5zq3PjBqv7g7E/uZqyleHthvEJnpNUFcc=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=Qw1NJVsUJmr4wc7AioDXdMRjq747ZgtNgLWXYTvgehC0vWLaMSmJzmRKdDMq1zeEJzYIa20rVbXpydF+hmIz6G7QxI0glBS3tKPjBBzHSQz/GNcWF6+m8fJ5TCTad9U4rAgKePI5ih+ng27EBmEtK7RswjVRwi9H80/7FXUn92P6LY4P8rCW7H3q5zQ9BrYYzkSC+FKUvc8oHnefWxBSvPzMHhZs10+jep8MD7+yFJonzV/ea9QjbKNVOQ7+s6kaggOLBW1+5eF5I0GtUWknn3hX55QnAubI887G7Jz25TzyAl202pn5C0ZzJER8oZU0fAm2OVP/4ppVJ1M1fUnIjQ==
X-YMail-OSG: Os7DNC8VM1kKN70GE6kcUT8_Oq835oQDRm_ae4i03DweMwSJspxFt_NrIvUblkT
 EMXlDa.wrDjdnLIKFWYNZeQXQDLHQvGl7pR892Y2Sqewz18pDgakFbVKOODOaZCCjazNpF_eJ0QN
 kTt0A6iRAtIVkh9RtRV0Raj_Vr0jG_7EZL7g0P2AXWfVKnh.PW1vyuUDYG_nM0WFlWNu2igwMexg
 n.JhxGqdkNVxVaF9y7_KMnRbvIto84__vw60j2xr51Ni.qZxh2UKK4taUOqRS45R_lgSbQHR5ec8
 m5HUFT2n6pOdKqJDqwCWxI6uMYqZHnKt1Tnb1pbJkwpqpO1_a5CIZUYI68FUffeNmfKj88oC96VZ
 aR5K1qn5IIsYqjPaMfloaW329SkLm2M0clML_DNhQU18AhRd4wJqLumbsD.ZkW5kf0.FVHmWobgt
 e47yl.vuhfa1e0yWk1x5nozpe2FZbD2mUqx9R_h0_6dgdXc68PhM20UUgCOayepGecsb2_d2eLLZ
 ZCTZqSkT_Kp.KeM4aUHxl1zIEfwaemyRjmPsF78h91HnLZtSci7U.jrM.5T41JG6hVHIu_vMit_C
 mliiFlfjniU9QuSphtkWnFEWJCbuwFKQDqtb3x50vCg9EuONEDy7ltQfuFBmXT2tJr3hOP2wpcLR
 eZewrDphCWDukD5lxYiUEnMPVATSRZQyQ1JCkO_nNGvDZCwQ4r9CYWH6STwh0MA4d0YU7vGBs_Vv
 yWscYisX_mdcp2VcB0J8rqVJuv3T1QQV.pnjIoa8LmTsgjjt.BErlNWCk5wmNfc6dcX5bT4ux0ec
 YFMo740wnDzuSbxuoTXLjPjrdVKAXsaISnD22q1gDnwiLu4NUI0JWzs253UG6NUYMm6XLVSzcsXG
 kQV5Qz_87t1LpmXW2VgsNO82hMsqoCUd9wL6racK8mAUEomXvhq1Accx8KTjrIk_Bc3lwnf_CfMs
 K9YgQw9CuKYwhIzgHADP7EuIaHZsdXKRPPm5lcHSR_2yvhrD3ebo0zCdtQvrAjfbe_E.FQk2xIlK
 gAvNh2Uihs1.0KlwKE0zKHuYyJcbajU7ix9ijTAcdb3NcwV5R6VKpI.g6kQ06ERTmjCF3BHyZa1e
 22DqvsxhtVnlh5deI6SWmestCKzSDFBcWLJCUH9rRcxzDcCRZEvnXA3DPtPnkfUQ02T2dKZqErN.
 nRC4kHraHIkjeCgKOgs9Nmk7Qy50r6vlmqoKwFv9GmwjvMbfZkqYF5vaK_Sxsir3nPTD72aF7U6D
 X3YSGzKatVc.ttXU77aEp5CSv_24MyfAUlcQF8DPUR3spzfZBdV2ROoIdtXaI2J_O_NgnajqRWZ4
 Z7Wt9HOI7kq4f4zgm_IGnuPiD78yBjBIgpTn8I0x_tI865ZJgh3UnwA3FHOceXt9vna9Liov.3V3
 .ZZNUoF9_iaJg.NSukllRKMPAsA34dElIHxUpYAeOAS3bB2MMV1ngfmnfhPk7gDjGgBbnJeyFELe
 9gt8rhGJMdSPohKnYdeCI7tyY5.52ldpoBtOQz7_8TFy4A14g6P.DLKeoqYT5jxkmH4T2olmOIwa
 SwdB33U41SL7XX8wb2v85g.dgdxW5TUXYBDeLf1LQCSEqe8F3A6gMMuICCgHJMFpg4gtjTSW6fxB
 FEORjJkuhXmPBBQ3tHfMRd9x0UCHByKcou.zsirOzocOGqU8kP2zQFIlSsdzTqqjq7zX_kC1Njs.
 BVgOyYXeG353j1tVisCXvbcKN4.FvXKnWLO93apxLqjJr7lC83rF7LGwv0dLctXl.YeOrjufru2Z
 aUc3fyahR3mMfn_TloHA.YySi34EA14R3oIYtvPY.52VT4HsIoBT4P4jRH16Kwt0LCr2DKQnJaMs
 n68HxaxiTBPCKJB9reZvcE3P02hGbfztlRLTbeajagXH8UF4ESU0vNYOezLWPQGmwCyGOX.EfEMy
 NN.lRZRyHtAZQCPak5BEEp4Gq5gg1DMfDtJLZ.Rl_HnnxeREkasSWQDg4rttWrlBvKS3o8FjWqkq
 Lpb89l8bE5IVDYYTyz3ULMrGmaY6RsHAOa3rQepAJ7fwjMXZffCNBARD3d3hSxnckohu0n1VvOvI
 5aDUHnQ9nVVmmqHatNAvmhbdnz3YhUq7aRukyWtW7aLyYVoJAZ_xQQ1b.qmLVoUjXam1l2ee4hJd
 dHpnL3MWXDAL4KFJmJClOeSl_JPTB0xb3OGqkcRrA.yOg8swos.UbYOr91vbgYQ8ZmzVLpQWuw.Z
 Ajh5WwouIBj2lwD8oXKCgRZJkC.HL_B_GjRzO_W2fuA--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: b8452a40-21fd-4249-b0e5-ba6658385c4b
Message-ID: <1522d7a3-eb9d-40df-9a34-7b1cfeb3680e@aol.com>
Date: Fri, 14 Aug 2026 12:18:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Anthony PERARD <anthony.perard@citrix.com>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Content-Language: en-US
In-Reply-To: <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 2158
X-purgate-ID: tlsNG-33051d/1786724313-7428D4E9-007C5BBF/0/0
X-purgate-type: clean
X-purgate-size: 2209

On 8/14/2026 11:23 AM, Chuck Zmudzinski wrote:
> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>> -- snip --
>>>>
>>>> I don't follow this: Anything the guest can access should also be accessible
>>>> by its DM.
>>> 
>>> I think the host OpRegion is not currently accessible by the DM.
>> 
>> Can you explain to me how the region becomes accessible to the guest?
>> That would then (hopefully) help me understand why the DM would not have
>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>> guest are also assigned to its DM.
> 
> Currently, in the device model (Qemu) we have:
> 
>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>             XEN_PCI_INTEL_OPREGION_PAGES,
>             DPCI_ADD_MAPPING);
> 
> That statement is in the igd_write_opregion(...) function in the
> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.

I forgot to mention: In our current implementation, this statement is
executed in the DM when hvmloader executes this statement, currently in
hvmloader/pci:

                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
                               igd_opregion_pgbase << PAGE_SHIFT);



> 
> If I understand our current implementation correctly, this statement
> is what gives the guest access to the host OpRegion (3 pages as defined
> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
> in hvmloader code). I don't think this statement makes the host OpRegion
> accessible to the device model, though, so I think, if I understand your
> comment in an earlier about my patch resulting in what you called a "layering
> violation" correctly, that our current implementation is also guilty of this
> same kind of "layering violation."
> 
> So, how do you suggest we fix that?
> 
...


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 17:04:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 17:04:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391303.1631203 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004ts-TG; Fri, 14 Aug 2026 17:04:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391303.1631203; Fri, 14 Aug 2026 17:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004rr-M5; Fri, 14 Aug 2026 17:04:18 +0000
Received: by outflank-mailman (input) for mailman id 1391303;
 Fri, 14 Aug 2026 16:26:01 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wuujJ-0008H9-Qq
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:26:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuujJ-00GchW-7i
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:26:01 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f418b-e002-0a2a0a5209dd-0a2a4502c19c-8
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:26:01 +0200
Received: from [209.85.215.172] (helo=mail-pg1-f172.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f418e-6ca4-0a2a45020019-d155d7aca958-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:51 +0200
Received: by mail-pg1-f172.google.com with SMTP id
 41be03b00d2f7-cbe6295f05bso1697696a12.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:25:51 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2d3aeb29f62sm12585735ad.38.2026.08.14.09.25.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 09:25:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786724750; x=1787329550; 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=oQ2MamIsZ2KeLKkmmqjUHALpj5utjzxXi4uD6i0RX6I=;
        b=XHImwinSQiCwRKAPYBp9NiB5dTlp0XnOkr+5BZgr7+y4tEd1ooUipd1W87Do3hKFym
         DMlorPMJLORJnwj4bYb8TgkWYwfkONfABCOMnA2/4h/T8wGTaFMKyyM4lmsPigBXGwP6
         lnB/6rcLBXC1N9d89cLqa1ME6gh7CbXLDppmtZN4VrSI5RjnKZp9q/cfexTHx7rhaBz0
         OnYUYaRyIf35GQUoTUXhrPjVtofO4dh76O/F+3CiuoOgWsr0IGwjpfsuiLOjt2d01fJ3
         MDjLNpUyrsWeNjE6BnKikh4diwpsZBfalBlVu4fW0l0WRq8fQeA2zfxJtoJEkGT5U2Qr
         57QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786724750; x=1787329550;
        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=oQ2MamIsZ2KeLKkmmqjUHALpj5utjzxXi4uD6i0RX6I=;
        b=pTnyrUk41dGPQqMtm+HYVs3IPxsT8Zk2AkrXpZTq8GrQOlg4J2KZtyNsxmT05T8bIV
         UmsxzmtuZL9Dy8kjvyPL+2CH4LHWDXixwDPeIoRLlesVsPUQlN7XrGdqssuX4eZwD9Oq
         OFQW2yzu8NW0/+LNn0yVO1R8klP9VjJx569B+ZURcW8r740mYIeumiP7nTZ/+QgRAfPe
         LBkiuQcTLuXcOoI6WB93KNxgnZ2AkmCOFm8LpaPdqXGKU8U+KVUs2MgqgcE7pElT55x+
         WcEZZcVjzKK+UiruD8IqCH1HR2EnS2ZIM+v0v/jf6D6ls1ykGGdn7DZSKuD6/soHev6J
         2n5Q==
X-Gm-Message-State: AOJu0YwWApHprJd5IwK49yMas/6cv8XKPuPYNDf/1SPDFsJ21LjZevam
	hvA1CXTIg0zi+7PzemEX6ZCEVu80jRx0OevBnxcCfeUEM0zCSl/TGgKV7TbIDH5I
X-Gm-Gg: AR+sD107ELJm0UdLz6muR3Dd201Mq9gVxV+6iTpw3SZWfPNcmHgAuIEkRsZrSzg6Zkx
	fNyuKtQHHv9O4GRebvJAngh8vE7WIz7b5SM29zmuWXQeaHihO4TD5OYRFnmlQNCeTeAe3vmu1E2
	D5NSDyesDG9s3iLhievghqTKE4Gi5+ZJyNJQ+pKc0hs04FSfrhMAeZDpMbN8kTyOMHcJUnHT0yf
	hUr1VdRP8DW6nZV+M9oDXPAdMHuNDm7Vlesuy134D5VsHdMb7nBudaQfB6jBqTGCgBATuV1Es0N
	6WoIRQlUTqzeJ3tbeiA3/n1TwBB4gMLAhqd6z6kovYKwCRFA73YPkh0Rem6Iz42FzUkBYZ5mqEZ
	GRv/A8X5DvsK6MW1ChWdJt5pcgeWTdLl9voBa+Ev51ffN/JWO0u9Upgnyk9BtGX9T9PG09X01bF
	N5LEWSkrQiuCX04xH75qXdy4A6u0NLNi5W/9zd5Kl/Lvi7b6K95+6qfM/RA6kgRzFMRivGB18Mb
	6kuwJfsLEb1uNaffZSq3A+y2id2tcSh
X-Received: by 2002:a17:903:1aa3:b0:2cc:89ce:2f07 with SMTP id d9443c01a7336-2d3afdacd25mr70506165ad.1.1786724749790;
        Fri, 14 Aug 2026 09:25:49 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH 1/3] xen/char: add classic i.MX UART driver
Date: Sat, 15 Aug 2026 00:25:33 +0800
Message-ID: <20260814162535.331459-2-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260814162535.331459-1-onlywig@gmail.com>
References: <20260814162535.331459-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1786724752-F16AF2AC-B7559739/0/0
X-purgate-type: clean
X-purgate-size: 10603

Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
compatible), as found on the i.MX6/7/8M families.  Baudrate and pin
configuration are inherited from the bootloader; the driver only
enables the transmitter/receiver and wires up the RX/TX interrupts,
mirroring the existing imx-lpuart driver.

This is needed for the i.MX8M family, whose UART IP differs from the
LPUART used on i.MX8QM/8QXP.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 xen/arch/arm/include/asm/imx-uart.h |  62 ++++++++
 xen/drivers/char/Kconfig            |   8 +
 xen/drivers/char/Makefile           |   1 +
 xen/drivers/char/imx-uart.c         | 227 ++++++++++++++++++++++++++++
 4 files changed, 298 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/drivers/char/imx-uart.c

diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
new file mode 100644
index 0000000000..ad4b0b06ff
--- /dev/null
+++ b/xen/arch/arm/include/asm/imx-uart.h
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/include/asm/imx-uart.h
+ *
+ * Register definitions for the classic i.MX UART IP
+ * ("fsl,imx6q-uart" compatible, used on i.MX6/7/8M families).
+ *
+ * Register layout taken from Linux drivers/tty/serial/imx.c.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#ifndef __ASM_ARM_IMX_UART_H__
+#define __ASM_ARM_IMX_UART_H__
+
+#define URXD0           0x00   /* Receiver Register */
+#define URTX0           0x40   /* Transmitter Register */
+#define UCR1            0x80   /* Control Register 1 */
+#define UCR2            0x84   /* Control Register 2 */
+#define UCR3            0x88   /* Control Register 3 */
+#define UCR4            0x8c   /* Control Register 4 */
+#define UFCR            0x90   /* FIFO Control Register */
+#define USR1            0x94   /* Status Register 1 */
+#define USR2            0x98   /* Status Register 2 */
+#define UTS             0xb4   /* Test Register */
+
+#define URXD_CHARRDY    (1U << 15)
+#define URXD_RX_DATA    0xff
+
+#define UCR1_UARTEN     (1U << 0)
+#define UCR1_RRDYEN     (1U << 9)   /* Receiver ready interrupt enable */
+#define UCR1_TRDYEN     (1U << 13)  /* Transmitter ready interrupt enable */
+#define UCR1_RXDMAEN    (1U << 8)
+#define UCR1_TXDMAEN    (1U << 3)
+#define UCR1_ATDMAEN    (1U << 2)
+
+#define UCR2_SRST       (1U << 0)   /* 0 = issue software reset */
+#define UCR2_RXEN       (1U << 1)
+#define UCR2_TXEN       (1U << 2)
+
+#define USR1_RRDY       (1U << 9)   /* Receiver ready */
+#define USR1_TRDY       (1U << 13)  /* Transmitter ready */
+
+#define USR2_RDR        (1U << 0)   /* Receive data ready */
+#define USR2_ORE        (1U << 1)   /* Overrun error */
+#define USR2_TXDC       (1U << 3)   /* Transmission complete */
+#define USR2_TXFE       (1U << 14)  /* Transmit FIFO empty */
+
+#define UTS_TXFULL      (1U << 4)
+#define UTS_RXEMPTY     (1U << 5)
+#define UTS_TXEMPTY     (1U << 6)
+
+#endif /* __ASM_ARM_IMX_UART_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 8e49a52c73..f237c0220d 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -30,6 +30,14 @@ config HAS_IMX_LPUART
 	help
 	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
 
+config HAS_IMX_UART
+	bool "i.MX UART driver"
+	default y
+	depends on ARM_64
+	help
+	  This selects the classic i.MX UART. If you have an i.MX8M family
+	  based board, say Y.
+
 config HAS_MVEBU
 	bool "Marvell MVEBU UART driver"
 	default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 8cbbffdca8..039f566926 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
 obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_XHCI) += xhci-dbc.o
 obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
+obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
 obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
 obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
 obj-y += serial.o
diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
new file mode 100644
index 0000000000..5ae8c13c40
--- /dev/null
+++ b/xen/drivers/char/imx-uart.c
@@ -0,0 +1,227 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/drivers/char/imx-uart.c
+ *
+ * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), as found on
+ * the i.MX6/7/8M families (e.g. i.MX8MP).
+ *
+ * Baudrate and pin configuration are inherited from the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/serial.h>
+#include <asm/device.h>
+#include <asm/imx-uart.h>
+#include <asm/io.h>
+
+#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
+#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
+
+static struct imx_uart {
+    uint32_t irq;
+    char __iomem *regs;
+    struct irqaction irqaction;
+    struct vuart_info vuart;
+} imx8m_com;
+
+static void imx_uart_interrupt(int irq, void *data)
+{
+    struct serial_port *port = data;
+    struct imx_uart *uart = port->uart;
+
+    if ( imx_uart_read(uart, USR2) & USR2_RDR )
+        serial_rx_interrupt(port);
+
+    if ( imx_uart_read(uart, USR1) & USR1_TRDY )
+        serial_tx_interrupt(port);
+}
+
+static void __init imx_uart_init_preirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1, ucr2;
+
+    /*
+     * Reuse the bootloader baudrate/format settings: only make sure the
+     * UART and both directions are enabled, DMA and interrupts are off.
+     */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_RXDMAEN | UCR1_TXDMAEN |
+              UCR1_ATDMAEN);
+    ucr1 |= UCR1_UARTEN;
+    imx_uart_write(uart, UCR1, ucr1);
+
+    ucr2 = imx_uart_read(uart, UCR2);
+    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
+    imx_uart_write(uart, UCR2, ucr2);
+}
+
+static void __init imx_uart_init_postirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    uart->irqaction.handler = imx_uart_interrupt;
+    uart->irqaction.name = "imx_uart";
+    uart->irqaction.dev_id = port;
+
+    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
+    {
+        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %d\n", uart->irq);
+        return;
+    }
+
+    /* Enable the receiver ready interrupt */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 |= UCR1_RRDYEN;
+    imx_uart_write(uart, UCR1, ucr1);
+}
+
+static int imx_uart_tx_ready(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return !(imx_uart_read(uart, UTS) & UTS_TXFULL);
+}
+
+static void imx_uart_putc(struct serial_port *port, char c)
+{
+    struct imx_uart *uart = port->uart;
+
+    while ( imx_uart_read(uart, UTS) & UTS_TXFULL )
+        cpu_relax();
+
+    imx_uart_write(uart, URTX0, c);
+}
+
+static int imx_uart_getc(struct serial_port *port, char *pc)
+{
+    struct imx_uart *uart = port->uart;
+
+    if ( !(imx_uart_read(uart, USR2) & USR2_RDR) )
+        return 0;
+
+    *pc = imx_uart_read(uart, URXD0) & URXD_RX_DATA;
+
+    if ( imx_uart_read(uart, USR2) & USR2_ORE )
+        imx_uart_write(uart, USR2, USR2_ORE);
+
+    return 1;
+}
+
+static int __init imx_uart_irq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return ((uart->irq > 0) ? uart->irq : -1);
+}
+
+static const struct vuart_info *imx_uart_vuart_info(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return &uart->vuart;
+}
+
+static void imx_uart_start_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 | UCR1_TRDYEN);
+}
+
+static void imx_uart_stop_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 & ~UCR1_TRDYEN);
+}
+
+static struct uart_driver __read_mostly imx_uart_driver = {
+    .init_preirq = imx_uart_init_preirq,
+    .init_postirq = imx_uart_init_postirq,
+    .tx_ready = imx_uart_tx_ready,
+    .putc = imx_uart_putc,
+    .getc = imx_uart_getc,
+    .irq = imx_uart_irq,
+    .start_tx = imx_uart_start_tx,
+    .stop_tx = imx_uart_stop_tx,
+    .vuart_info = imx_uart_vuart_info,
+};
+
+static int __init imx_uart_init(struct dt_device_node *dev, const void *data)
+{
+    const char *config = data;
+    struct imx_uart *uart;
+    int res;
+    paddr_t addr, size;
+
+    if ( strcmp(config, "") )
+        printk("WARNING: UART configuration is not supported\n");
+
+    uart = &imx8m_com;
+
+    res = dt_device_get_paddr(dev, 0, &addr, &size);
+    if ( res )
+    {
+        printk("imx-uart: Unable to retrieve the base address of the UART\n");
+        return res;
+    }
+
+    res = platform_get_irq(dev, 0);
+    if ( res < 0 )
+    {
+        printk("imx-uart: Unable to retrieve the IRQ\n");
+        return -EINVAL;
+    }
+    uart->irq = res;
+
+    uart->regs = ioremap_nocache(addr, size);
+    if ( !uart->regs )
+    {
+        printk("imx-uart: Unable to map the UART memory\n");
+        return -ENOMEM;
+    }
+
+    uart->vuart.base_addr = addr;
+    uart->vuart.size = size;
+    uart->vuart.data_off = URTX0;
+    uart->vuart.status_off = UTS;
+    uart->vuart.status = UTS_TXEMPTY | UTS_RXEMPTY;
+
+    /* Register with generic serial driver */
+    serial_register_uart(SERHND_DTUART, &imx_uart_driver, uart);
+
+    dt_device_set_used_by(dev, DOMID_XEN);
+
+    return 0;
+}
+
+static const struct dt_device_match imx_uart_dt_compat[] __initconst =
+{
+    DT_MATCH_COMPATIBLE("fsl,imx6q-uart"),
+    { /* sentinel */ },
+};
+
+DT_DEVICE_START(imx_uart, "i.MX UART", DEVICE_SERIAL)
+    .dt_match = imx_uart_dt_compat,
+    .init = imx_uart_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 17:04:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 17:04:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391300.1631192 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004kH-Cl; Fri, 14 Aug 2026 17:04:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391300.1631192; Fri, 14 Aug 2026 17:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004k8-88; Fri, 14 Aug 2026 17:04:18 +0000
Received: by outflank-mailman (input) for mailman id 1391300;
 Fri, 14 Aug 2026 16:25:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wuujE-0008GX-MJ
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:25:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuujE-006hmA-3L
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:25:56 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f4190-2eae-0a2a0a5409dd-0a2a4506afde-4
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:56 +0200
Received: from [209.85.214.171] (helo=mail-pl1-f171.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f4192-195a-0a2a45060019-d155d6abb008-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:55 +0200
Received: by mail-pl1-f171.google.com with SMTP id
 d9443c01a7336-2d5335cf904so3017855ad.2
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:25:55 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2d3aeb29f62sm12585735ad.38.2026.08.14.09.25.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 09:25:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786724754; x=1787329554; 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=jcuSXhXunYsiZRxzXY1y0OZN0WvmTzxBkolAPYMDdmA=;
        b=sQHPcxWM0mi3kvu5QDlWR22xDXI78wrZCLn0ZS7ZY8XVAAHaAF/XsQ8IJzmcRcZ3Cl
         Rrl4kQMQ4ggTZt4aQfGEMmpgOwLCGXJ2d3wYB0XeoWq/ZJYNki9imXqjVY55UeH5nthk
         jT/bcHrgmrvfZDFwqiqCuNfOoWMa3MlhMebAz4Ita82bB9jIkSbq97piGjiATYUx72H/
         CdPeG4AZvqFT93MrGssGcMgrmPxynxPTJvNmyzQkyAUA3JljEWpVcAYi62UZvUIef8vn
         MbF47qkxXoujeCeuVoFnBdRmtQ7vN0E2vjw84JE0Bj/y1PreTy7iJvvrkd0irMuVl0Pu
         iQEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786724754; x=1787329554;
        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=jcuSXhXunYsiZRxzXY1y0OZN0WvmTzxBkolAPYMDdmA=;
        b=cw4+QvUzj636ZNk4aKtgJU+pqE283blBMLtyPjj09nQGKlpQb8Zl+lupJ5BblZxKYy
         aH8D77fSFdgS2XTYKx8ts1ISs5W+SZz9lWr8TWFJc+1XJ4A2R93fr24XfuEm4AxNO6FX
         XSIrV2mwEg8hKxbG7d2Bl37pJvCIJL64GWtucZWYHOWbZbKhiDDu8AIIS1unR5qmk7ur
         7vuARHUsrKPv8T8bSVHcHtOHvrucCdaVUHJaAdDcQOBX+u5EGIn5sb0KBN4BbD9UoJ6P
         XRF7/o9YbqJojnp2mQreYZps6NOeOgSRF7qLOBCz/7IGw2m9MrhSryohZPHccIG/WHpr
         8ybg==
X-Gm-Message-State: AOJu0YzjrL+G0rEdLSsSL1axnpAo8BmCmnywZ++TNDEHaEmHVsBRS/h+
	Wh+7SR6gGmawU8rKwxt47uer6mlAn9cTMpL5EJtCJ8bpgj/aTwGJzMMSvaajeWL4
X-Gm-Gg: AR+sD10xawtm20mU4nrW9IRth/mWCO2LUykqWW+xrMz2B4/0NUm7RLrSpo6wvYjfCNW
	ffUffZQs0iwIS4otDGqyIiVWhfPJkn/4d0umYT2j97HRMtkQVmL/iHRN8HWTajLFRbru8lX00FJ
	A6TD6CCCw+khIqv6fo5As3IWzL0r6NtltlQn5dqJBqZjBvS/9MuEZL3vhEBQ2tW8FRb1R1pj3Fo
	Uf0Cc7UX6j9Ti7L+42e3e6D3PZo8hbAfFg7qSkGhBhsOl5pxz+i45jCk0wuXrcupsEAy5Fr7pY5
	sneWLYijlhcLtVtw502hD/LSfHMQ11TF3NmcESAahd8G1mZms9b/xYQYaqo1mWH/TB4mgSpMB9e
	tHxg0bXLNDmlK5shLnkBM70+3+BVe7dgbgIugBlDF5So5DAB39umV1vndZrwH/t/gAxa43iwTQR
	u/4iIkN6nD68ImhDPMvlRnY1ohW429aYUGla0gOYmn2WRVO+mfw5X6I9caK3WiqsA+OWBYmgrWy
	SZ5XIVV6uVDlOIckgRv/JqFxMlYE3Ew
X-Received: by 2002:a17:902:d552:b0:2ca:caa5:9c04 with SMTP id d9443c01a7336-2d3b0d2c159mr94259235ad.23.1786724753801;
        Fri, 14 Aug 2026 09:25:53 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH 2/3] xen/arm64: add early printk for the classic i.MX UART
Date: Sat, 15 Aug 2026 00:25:34 +0800
Message-ID: <20260814162535.331459-3-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260814162535.331459-1-onlywig@gmail.com>
References: <20260814162535.331459-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786724756-F627077B-F0519CC6/0/0
X-purgate-type: clean
X-purgate-size: 3066

Add an early printk implementation for the classic i.MX UART IP,
selectable via EARLY_UART_CHOICE_IMX_UART.  The UART is expected to be
fully initialized by the bootloader.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 xen/arch/arm/Kconfig.debug            | 12 +++++++++
 xen/arch/arm/arm64/debug-imx-uart.inc | 39 +++++++++++++++++++++++++++
 2 files changed, 51 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc

diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 5a03b220ac..63a34b813a 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -44,6 +44,14 @@ choice
 		  Say Y here if you wish the early printk to direct their
 		  output to a i.MX LPUART.
 
+	config EARLY_UART_CHOICE_IMX_UART
+		select EARLY_UART_IMX_UART
+		depends on ARM_64
+		bool "Early printk via i.MX UART"
+		help
+		  Say Y here if you wish the early printk to direct their
+		  output to the classic i.MX UART (i.MX8M family).
+
 	config EARLY_UART_CHOICE_LINFLEX
 		select EARLY_UART_LINFLEX
 		depends on ARM_64
@@ -97,6 +105,9 @@ config EARLY_UART_EXYNOS4210
 config EARLY_UART_IMX_LPUART
 	select EARLY_PRINTK
 	bool
+config EARLY_UART_IMX_UART
+	select EARLY_PRINTK
+	bool
 config EARLY_UART_LINFLEX
 	select EARLY_PRINTK
 	bool
@@ -185,6 +196,7 @@ config EARLY_PRINTK_INC
 	default "debug-cadence.inc" if EARLY_UART_CADENCE
 	default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
 	default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
+	default "debug-imx-uart.inc" if EARLY_UART_IMX_UART
 	default "debug-linflex.inc" if EARLY_UART_LINFLEX
 	default "debug-meson.inc" if EARLY_UART_MESON
 	default "debug-mvebu.inc" if EARLY_UART_MVEBU
diff --git a/xen/arch/arm/arm64/debug-imx-uart.inc b/xen/arch/arm/arm64/debug-imx-uart.inc
new file mode 100644
index 0000000000..80ac647f5e
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-imx-uart.inc
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/arm64/debug-imx-uart.inc
+ *
+ * Early printk for the classic i.MX UART IP (i.MX6/7/8M families).
+ * The UART is expected to be fully initialized by the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <asm/imx-uart.h>
+
+/*
+ * Wait for the UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb, c
+1:
+        ldr   w\c, [\xb, #UTS]        /* <- Test register */
+        tst   w\c, #UTS_TXFULL        /* Check TX FIFO full bit */
+        bne   1b                      /* Wait until there is room */
+.endm
+
+/*
+ * UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb, wt
+        str   \wt, [\xb, #URTX0]      /* -> Transmitter register */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 17:04:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 17:04:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391302.1631198 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004oW-Kj; Fri, 14 Aug 2026 17:04:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391302.1631198; Fri, 14 Aug 2026 17:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004n9-EV; Fri, 14 Aug 2026 17:04:18 +0000
Received: by outflank-mailman (input) for mailman id 1391302;
 Fri, 14 Aug 2026 16:26:00 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wuujI-0008H0-9x
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:26:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuujH-006hmA-N6
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:25:59 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f4188-2eae-0a2a0a5409dd-0a2a4505d3be-14
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:59 +0200
Received: from [209.85.214.179] (helo=mail-pl1-f179.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f4196-4cb1-0a2a45050019-d155d6b3e940-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:59 +0200
Received: by mail-pl1-f179.google.com with SMTP id
 d9443c01a7336-2ce7d2adef4so21025855ad.3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:25:59 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2d3aeb29f62sm12585735ad.38.2026.08.14.09.25.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 09:25:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1786724758; x=1787329558; 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=pANIpxy73mwji3KETZ0SQ4NuCZV/pLf/fluSXSojwX0=;
        b=bv5hcZOBpC8NxwXfQFp5eC6/oYyoISXaCw/FAe5ISCfYNR1pWJIR4axA6bWuxpkmEO
         odzIsEi0C2AKCutMsyxv8iHwTsw/cYtJakBB2enEq2IaEPeoJg5vs1bcc8aZiMnPe477
         u9D9vHudsiQO7kAanqQhzgA1DsiWDyFsD8BWkigATyLWfXfZueCqdKZvNqRhUjCK09k7
         MMjIjgF5ojj+ZFordewlofj3WJRk+UewLIdjiMYKm4js6xvxBCUd7BcRZq4uhvsfqFlo
         BqXmYGa2uoFd+qtHjI9CQD+9qujnlGbZJhpM6gotJ90eTem4R6gnvn4YLULomMCYUr3B
         hv4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786724758; x=1787329558;
        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=pANIpxy73mwji3KETZ0SQ4NuCZV/pLf/fluSXSojwX0=;
        b=HEX4ECJaZQjS5GUKijDAWNA2J2R1dLBaMafS2rYd7CqAR6YPpblhX2Cke4fZuhmDER
         OTRSdehB4fs/nuYJGlv6HTETMA7G3TSgFDnkMpwpEtW7UQu9oiJ3DbO/Xd1Wh6mwHICO
         hfO9nryXzzKgSeY9+W307r35IwKgOSHMQjK3Kb2w1xVrWLjlEVqfcWNcud6zLhQ39FEB
         KzJqk+sfb5CdGJpq0VrzjqC8VkFcFRs5s2K6OXxvOuLrWO0McSV00rEdjWhvS+26Pt+0
         ZN6z/yZvz5WFr9fwVF8nETxHjh7NYp7E6tcP46vbr3ARQ0HfDUaco1dAt2/eO8tliFPg
         ji4w==
X-Gm-Message-State: AOJu0YxRkd9IE6sCrJE+2x2eQS5gSC0WfGNbe6fcAfEJWZHAyXuUOk1E
	Ctq4q/EXHL78aThum1MOCR35i41SmNg+UlTDHWQHOP9+00dtusmXRh5NsnazCIkG
X-Gm-Gg: AR+sD101eE5x5DvFWHGBRgpP9x9Fk+VXMsR5utNnBQaJ40SFK2JQnSZ1NVPk7/90QeA
	RTbGGUagIxAsZjvutozV/9MmAAQNO5lQPFhWHKuLQMb0cm5d8BXLrj1nFMCR5Bv4f79+lsyukog
	R7IUZtjIr9xYpN7I9F/FpZoIALy3l8h+X+E7395RcOa+TuuwJpQO2wpmeXMXenxskIE2aIhe7Fm
	CQw8wiqld8FuwKIws11mEFbNBv4KHck0nEPhQCTuJh1blp6PIHhbRGEhl7Wy+xGT/bN0m8d5LwY
	MmiB7wIr2vPZdpM9vQwMC8zPpL6OdVsGV/pweGsKBYQJ/eJ7KCA4G4wdebaBM/dwD/G2VXYFx4z
	7T4WnmyaDFHLBsVNswTfJTVwbI6T1wlkYs//wBwDOPuCuzD9ZshGinGm3TnltKqLTVVGNGxCISL
	7txpIt69HQFbVpF0/RbyrLWrbQ3gNCQWnZRc5x9qtD05refbf/jYMuSc6Tfzwr8nNmpJnl0F2Z8
	uPduDa/z8Kk/EexBuHDF0ob63wZTQmZ
X-Received: by 2002:a17:903:1103:b0:2c1:98b7:ecf3 with SMTP id d9443c01a7336-2d3b0cd3392mr88100305ad.23.1786724757484;
        Fri, 14 Aug 2026 09:25:57 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH 3/3] xen/arm: add i.MX8M platform support
Date: Sat, 15 Aug 2026 00:25:35 +0800
Message-ID: <20260814162535.331459-4-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260814162535.331459-1-onlywig@gmail.com>
References: <20260814162535.331459-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1786724759-738BE2A1-0552155B/0/0
X-purgate-type: clean
X-purgate-size: 5089

Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).

When Linux is used as dom0 a number of drivers make SiP SMC calls into
TF-A to manage hardware: GPC power domains, DDR frequency scaling, SRC
(M-core remoteproc), SoC info, NoC QoS and BBSM tamper status.  There
is no public specification for these calls; the function IDs are taken
from the upstream and vendor kernels.

Forward this reviewed set of calls from the hardware domain, following
the whitelist model of the i.MX8QM platform.  CPU frequency scaling is
denied because the hardware domain cannot make an informed decision,
and any unknown function ID is rejected.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/imx8m.c  | 116 ++++++++++++++++++++++++++++++++
 2 files changed, 117 insertions(+)
 create mode 100644 xen/arch/arm/platforms/imx8m.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index bec6e55d1f..cdf936c50d 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
 obj-$(CONFIG_ALL64_PLAT) += thunderx.o
 obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
 obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8m.o
 obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
new file mode 100644
index 0000000000..dc49e754ee
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8m.c
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/platforms/imx8m.c
+ *
+ * i.MX 8M family setup
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/sched.h>
+#include <asm/platform.h>
+#include <asm/smccc.h>
+
+static const char * const imx8m_dt_compat[] __initconst =
+{
+    "fsl,imx8mp",
+    "fsl,imx8mq",
+    "fsl,imx8mm",
+    "fsl,imx8mn",
+    NULL
+};
+
+/*
+ * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
+ * public specification for these; the IDs and names are extracted from
+ * the upstream and vendor kernels (see drivers/soc/imx, drivers/devfreq,
+ * drivers/remoteproc, drivers/firmware/imx).
+ */
+#define IMX_SIP_GPC         0xC2000000  /* GPC power-domain control */
+#define IMX_SIP_CPUFREQ     0xC2000001
+#define IMX_SIP_DDR_DVFS    0xC2000004  /* DRAM frequency scaling */
+#define IMX_SIP_SRC         0xC2000005  /* SRC: M-core remoteproc start/stop */
+#define IMX_SIP_GET_SOC_INFO 0xC2000006
+#define IMX_SIP_NOC         0xC2000008  /* NoC QoS priority setup */
+#define IMX_SIP_BBSM        0xC200000D  /* BBSM tamper status */
+
+static bool imx8m_smc(struct cpu_user_regs *regs)
+{
+    uint32_t function_id = get_user_reg(regs, 0);
+    struct arm_smccc_res res;
+
+    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+    {
+        printk_once(XENLOG_WARNING
+                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
+
+        return false;
+    }
+
+    /* Only the hardware domain may use the SiP calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
+        return false;
+    }
+
+    switch ( function_id )
+    {
+    /*
+     * All of these manage hardware that belongs to the hardware domain
+     * (power domains, DRAM controller, M-core, NoC, secure RTC) or are
+     * read-only queries.  Forward them.
+     */
+    case IMX_SIP_GPC:
+    case IMX_SIP_DDR_DVFS:
+    case IMX_SIP_SRC:
+    case IMX_SIP_GET_SOC_INFO:
+    case IMX_SIP_NOC:
+    case IMX_SIP_BBSM:
+        break;
+
+    /*
+     * CPU frequency scaling: the hardware domain does not see the whole
+     * system and cannot make an informed decision, so deny it (matches
+     * the i.MX8QM platform).
+     */
+    case IMX_SIP_CPUFREQ:
+        return false;
+
+    default:
+        gprintk(XENLOG_WARNING, "imx8m: smc: Unknown function id %x\n",
+                function_id);
+        return false;
+    }
+
+    arm_smccc_1_1_smc(function_id,
+                      get_user_reg(regs, 1),
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+}
+
+PLATFORM_START(imx8m, "i.MX 8M")
+    .compatible = imx8m_dt_compat,
+    .smc = imx8m_smc,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 17:04:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 17:04:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391298.1631187 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004hb-3p; Fri, 14 Aug 2026 17:04:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391298.1631187; Fri, 14 Aug 2026 17:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvKM-0004hU-1B; Fri, 14 Aug 2026 17:04:18 +0000
Received: by outflank-mailman (input) for mailman id 1391298;
 Fri, 14 Aug 2026 16:25:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wuuj6-0008G1-C7
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 16:25:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuuj5-006hns-PA
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:25:47 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f416c-8faa-0a2a0a5109dd-0a2a45018f30-42
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:47 +0200
Received: from [209.85.214.181] (helo=mail-pl1-f181.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a7f418a-5984-0a2a45010019-d155d6b5d95a-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 18:25:47 +0200
Received: by mail-pl1-f181.google.com with SMTP id
 d9443c01a7336-2cab973140bso20226625ad.3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 09:25:47 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-2d3aeb29f62sm12585735ad.38.2026.08.14.09.25.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 09:25:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786724745; x=1787329545; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=hewASw0YES1004X+TmHWipBlBUBhlbOj1JEjiurEJeU=;
        b=ZzMyywEv0yOKF6G638s4nkMvRSO817PuQkiCV2BPsjqmGrB1dqBRhFYLtX8HUdCZ9c
         0jxInmAQ61f03FlrbTByPAgqSFyItPl8jVmT5Tt151Dkc+v3zsYN8tuaiM7gFVZKVPxM
         BCVL2Hk6+YFXoo7byl2/96rcNrdQoVGBhHE9Qo0KmvW1CNCiTMhoSDDAKoM08tZItt5I
         vHVPall/HHrCqGXuPJYN/xndCYOjsOTucQ1iknpz8RQq2crxMYREp2fuDlxVU9eOWpGx
         QD43Zfu9DF4Oa+WMOLWZ25xrLwKxYUVi4fDdBmKphtceoG0XYG+gwVSEUUYhoevUzZ+o
         q6yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786724745; x=1787329545;
        h=content-transfer-encoding:mime-version: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=hewASw0YES1004X+TmHWipBlBUBhlbOj1JEjiurEJeU=;
        b=NUGjEAgSumW+smhmtuZdunG3SZqjh3/EKX/YwNh33c70pW3lZs78YmX5plU60yFEEp
         7BKDw1x9kcbR8MItmlQlc/B9DxUH3l0aq30bORqarKukfbmYlP+BWeErCI/hzQ4uhRL5
         j75kgVqGyNlan5T/wlGhk74PP+qWZeyo5GqUl+rD4eJcTCnW42dfYvjmN5HWey/uhsnE
         w0iYouydcUkmawa/1VpkfdHC/Lj7g60KEyodot+khZ354cKDrsO5XC1KXT5Nl+wu0/ny
         SmSqcH9dkVbRYINT5ZAjPSTHjUr1xIYqWzJJy/YRIHfIUu0c1WI9ENDvwoNKuW6STabu
         mkWw==
X-Gm-Message-State: AOJu0Yyk1aEDZkLkou1JCgakowFYhgarsS1duBwL9VStBSKzj5nR/Mfg
	M/qIUc+/HD0WjwEWPSQZgAyDAJlkdn1iI81fU2iLaw3vTO4B/fYmw2AkQbDr2poQ
X-Gm-Gg: AR+sD12hsVvCrjVUHZ7uDo8IxM/i0ttGEwvSuI5GvSSjRIBTvI4u9CWgiUiktOCe/QZ
	R+N8N8a5BaR+K+lwytKxChlTabUiJPyij+L2R2Mrp9HTrOmRdsr2LhDwEKhk8ckHqZxNfxvz6d9
	iIxCFV029pqzq5y94svgV9WS40Njha4FdSj203gUTWaIYNqysZbp4sdc92xH0E8lCJCaUxrhTwM
	skGF+VzxAWw+OIWB74I1fwVJxV75pMxZhYCjgPJi34OrvYTyh3OzO6EUw/rPNNuLmwjZyZQAB8/
	maujVYLCoAFepHzjr+j66ET+yBNWRWhm96AUMZoKp86TodToOBuZSqy/f42txNDVii0OAGy/WE4
	fnSNrkFWmOB8V8qKlm/vn8N4HoQgF9yO1eR4U1gJ0waMX3su8g4+x8tZXVBPo0cAbBQ/RjR4/Lh
	xfPoago+Y1dQBV2tWRYtdTa5EJ+c5SKHyyktPVb6IKf5na2YLa/4X0PgNshKQOelJVF6GvzsC6t
	6mpUt7K1Lh3NlUBnsQqgdVnuDdusPp/
X-Received: by 2002:a17:902:d549:b0:2cc:6018:f030 with SMTP id d9443c01a7336-2d3b0c6832dmr87106425ad.14.1786724745458;
        Fri, 14 Aug 2026 09:25:45 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH 0/3] xen/arm: add i.MX8M platform and UART support
Date: Sat, 15 Aug 2026 00:25:32 +0800
Message-ID: <20260814162535.331459-1-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1786724747-1DC79757-D3965F9C/0/0
X-purgate-type: clean
X-purgate-size: 1901

This series adds Xen support for the NXP i.MX8M family (i.MX8MP / MQ /
MM / MN).  It provides the console UART driver, its early printk, and
the platform glue (SiP SMC whitelist for the calls the dom0 kernel
issues to TF-A).

Tested on i.MX8MP (4x Cortex-A53, GICv3): dom0 boots to login on the
hypervisor console, and a domU starts with a PV disk and virtio
devices running a full Wayland distro.  This addresses the concern
raised on the 2019 i.MX8MQ RFC that only a ramfs dom0 had been shown.

Notes for reviewers:

- Unlike i.MX8MQ, the i.MX8MP device tree uses the GIC as the root
  interrupt controller (interrupt-parent = <&gic>), so no device-tree
  workaround is needed and power domains keep working.

- The i.MX8M family has no SMMU, so device passthrough relies on the
  1:1 direct-mapped hardware domain.

- The SiP SMC whitelist forwards only the function IDs the dom0 kernel
  actually issues (extracted from the upstream and vendor kernels);
  no call outside the whitelist was observed at runtime.


Wig Cheng (3):
  xen/char: add classic i.MX UART driver
  xen/arm64: add early printk for the classic i.MX UART
  xen/arm: add i.MX8M platform support

 xen/arch/arm/Kconfig.debug            |  12 ++
 xen/arch/arm/arm64/debug-imx-uart.inc |  39 +++++
 xen/arch/arm/include/asm/imx-uart.h   |  62 +++++++
 xen/arch/arm/platforms/Makefile       |   1 +
 xen/arch/arm/platforms/imx8m.c        | 116 +++++++++++++
 xen/drivers/char/Kconfig              |   8 +
 xen/drivers/char/Makefile             |   1 +
 xen/drivers/char/imx-uart.c           | 227 ++++++++++++++++++++++++++
 8 files changed, 466 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/arch/arm/platforms/imx8m.c
 create mode 100644 xen/drivers/char/imx-uart.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 17:07:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 17:07:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391359.1631224 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvNo-0006rU-Dg; Fri, 14 Aug 2026 17:07:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391359.1631224; Fri, 14 Aug 2026 17:07:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuvNo-0006rN-A4; Fri, 14 Aug 2026 17:07:52 +0000
Received: by outflank-mailman (input) for mailman id 1391359;
 Fri, 14 Aug 2026 17:07:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wuvNm-0006rH-S8
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 17:07:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuvNm-00GhUV-8s
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 19:07:50 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f4b37-8faa-0a2a0a5109dd-0a2a4503aae4-36
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 19:07:49 +0200
Received: from [98.137.64.205] (helo=sonic303-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f4b63-fae8-0a2a45030019-628940cdad36-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 19:07:49 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Aug 2026 17:07:47 +0000
Received: by hermes--production-ne1-6dbcb84f44-2jkrk (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID fcaea302a7739d9747edaf46b5414c24; 
 Fri, 14 Aug 2026 17:07:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786727267; bh=UY+I4UqGSnIpDiJN8AUplsskjws3Y+OSbvdRYW7JPno=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=BfbomtQlNSINKeR60rhpLziDP1DxAHD6ngEt/Gff5VH97iO3hTsCGgI2KJ+ym1uc/yWmbySncIwRADbSiZpqr9FfN7YW5fajUCuiD9vMtcLe8LxE4f9GGYwiZ+eoLjSXT5xu34ZItjgnaAEI8+5FDpBpJ85RBWy5bzB34UaDR0iyWCxMtS8RKgsifJmCp6e7OrPBwavlfUGJWUdpeXkFqbjCF5jEM1hr7Z5+JIq+bsSr28zVw3laKd+K5e41eSjvdOTzoCqItrGVcD8n62QgtVdRyrcIMJUWbWoR4cR3V2ZmEjg1vBP0cDTirTek5p7FA7lGajzZsgTuAooYfklh4Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786727267; bh=c39lbYaGJJoIE/qhea/ao2CxkL7OjjLdrbSLzWVUHJs=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=hNDy+a5sYYtLgboIHCp1Qcq0ohES12nsJh4n1yTM3tHBpXw5USle3m/qVodP0aXpDC5ZhPDQ9tqTHvkw0l0IX88pcx681PXPXsZuQ4Y9ZhnXxAClvbnx5NHmAN3QnwLv9tDBkEiyjuyjXAai9sG10OK9+jw+GWqmLQU/cISHzFB2JxFCKkyOaKBIfuAhq3oRt7k2OKDD7I/5G6zQTADCR8n25vztQgy2qDrSVXM9YisNXzNOCV+I+FH1tB6K9GbkPusFBb4Sf2vyR4SwXeykjxv/xruKhqKP3JTqyAW7s1RyOhXG+pgDvChG5Sqn1A+hoXIB1xZuayl4gQ9D8JqCBQ==
X-YMail-OSG: 8a2iFRQVM1lC0evxH.V2EkutHKBoXV3brFfmIDV7qQdtN5HbXc6Qi7Ov7kQiIiR
 UsbvpIRtPBz.uUgwf4Redp6xLr_DgmrIGmbMMVgQ13W2s96wLlNJJFjGQ.uSd9ZdPbN86l1CU7Db
 VdWLVICOwP5kb5ZYjG3O5MKeQIxRfQgkOpFIcSSunNieNGteF8V01DdHQDNougx7nIy8SqmcFwO5
 NlFRVaelWgP5f42Lgdmjl.VOgPzhgaPLp0R.9OnGD_c4P7ZBufVdk55JRJTkGWlGt_.t3KexRy1k
 z1IysH8oBWtI4m4asf7u914_PHoMbZyfdLbsQj9ET9uP605LdHxt5fEduNlDFUIPYQZfSkGuk6kk
 7lMjbJkaZ8qKflcdGE4aKmdEPOdoVDiIhoRKmy36BstJMS9M299Kw86glkEsbyQ7YjXRhRQRIxVR
 jPQ9oewICB5Kb07gNwtVweKv5_ahSw7DmwCEJaYgc2T94.awdXZTthhgWCqG4RwR0QQ.DsQp1mAZ
 Vlsf3DoEOEShsAyFkkhv3ifHNGaTsVSFHbH0Z19C4jri0DDBQO_EnJfhQFHxreLbXwm6Z7SoviI5
 q2mf0bmPDXi2cO3wjZOwd7rV2ZNr.Pzo4UuCox6VwpmrjYp34AKrPf2ExyBm7ZRm2on.LRZuPvLM
 VoY.KNZUjh5JpJyNXeQ1s85qAXY__TsGMidIvz8jYS9MsG.VuMga8NriuiklZxP9PB.VlXQ_MN_f
 Kvh2OPfH_qajbrzCNi2KBogpZFzrrm7re8QoULFNKD3E.Uu_noPWJX37h.GQUMLbgJXGhohucRqq
 nzNcX.4Z8EXgsUYuEqy8h1Isw3_8ribF6PSlWeLjyFr9GfjN7TKx0WxuU6P_PkJtq1_Fi2TcpEuo
 E7yvcHinxQBmLodID5mYvl39j8RgZtvgccIBSbxfXcbVZxuS_r6_s3dS_XtGWoEk7Hn040_CY3a4
 360F5JBdawUqL1UCSZ0aJA_TyRsgDFok89DcAoURetVx_5HJNIKkABN8.nRS7ZrpcwLSQPiAwIRn
 QNMzlBCCaOgW82MrbSdcHuBjD3.zHmieY6BaxugMIvT1eCsO74ysr6ed7FqAIhJ7pNDtxWItfcD5
 09w_tNV3jeWkAW5QxlMA7XG2BNnuDUR2kYQF6BUX0OMy8qRVZYvOb8vAQBaMCl_r4_OJwtFd9s7p
 wSQjAdzVC418z5.PzeP41UFtpmqsK6vRx7NFrzeZe2SrMVdgFp0IvgZh.fk5OeC7sfVomPJYnNVB
 XE4md11OY18SC2MhBieestlKn4rcAvPrFx9H7xPo_sDGFc5ksN.Nd.qRJ2cyWZeyrzsUuP.DJsRr
 dFpsTAZBUqgddIYi34rAgv__xpWN3mSnskebwdrETpwp9tD6SdyaCtrskRya.WrLxgpn4vgTCsPD
 IHAxbIXxzbhpApmKckdzgdLCNf3U6s2x55vd5_ddJyfoNegK4QhbeHiaLgjzhk18W03YtQDlnK0y
 cPBPMr3CEWGzLPppHvmVKWNAoGSWq4nNMSxPRJ.AY.WxpNW.RSZrwxAPrGtEzzqgN1RueR5Pg8Yd
 R8Ud0xWuwODjgZ9U6dMklXbH7hjUC_A..C0AkRMvNA8uhKsGJV55EyoNCLS5FjpC9GG19YqR2bWv
 M417BEaATPsT6XItbTpUVStn2o3.QPP3uMVLeQtAQTqZesWGQb5RxlRGITLtfHvJKe8Y1EgAAYpI
 qW9XrydEZH5U_YlNb6oLYFEDJrJgK8qvn8yXRIk40ipnFIH8mNGFL48keEnThRQarLaVRbZF9MkK
 QfYTckSiOWTsGWZH22reXk4xSHXDjaqqq4qs0_pcBhi2pVANhjNG3eGtIDo6FzKlX3203_YU3FeV
 jtb3RQhnBo9AKAAlp_kM23E.8oWCTg9wtRQaCBSN0HN6px0bCiuZo7dVcqKxYEQyNnPAg3fBCIKW
 ZJAiezeOYfKEnHTzJ0LZkKHW0AN37W58agpBFURz0LbXPpKkyXFLFeDeVfSdTDy.bKhBY_IogS6n
 ULp0UdbxYGlag.G8SoL2a4gPaINd9Sl3T3pDAltOIMTc3H8b7qVWSgiJ10LiXzY6ndtJIiMuy5DA
 PFKFLOYqZKmGRo3XNpKasHL8_OxvieKcmp0u3AvAf91oqY6jTRnLamgtIp3V8o9GSWxOy4ihsQaH
 75.JyPrD750BqFWotqESvwmz74Q329v0M6cjtGmgnfoDyC86zZNDi_IJTNUXTnmEsYiA0aoObW0e
 lrAGln2VeJhM8LWnsh4IJJoHaVcycgPJOSasV3fixQu7_ibQ-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 18dd4469-32e4-4583-9cc9-9f8238f17af1
Message-ID: <416caa9d-b658-4ba8-a401-babf477c0afe@aol.com>
Date: Fri, 14 Aug 2026 13:07:43 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Content-Language: en-US
In-Reply-To: <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 3336
X-purgate-ID: tlsNG-33051d/1786727269-778C54E9-EE706EEB/0/0
X-purgate-type: clean
X-purgate-size: 3395

On 8/14/2026 11:23 AM, Chuck Zmudzinski wrote:
> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>> -- snip --
>> 
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>>>>>>> +                IGD_OPREGION2_SUPPORT_MASK);
>>>>>>
>>>>>> This looks to imply qemu is the only possible device model.
>>>>>
>>>>> Yeah, this is an issue. Other device models that intend to support
>>>>> the Intel IGD with hvmloader will also have to be compatible with this.
>>>>> It would be easier if we did not have to worry about backward
>>>>> compatibility and supporting what we had in the codebase for many years
>>>>> in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
>>>>> in that case. Instead, we would just completely deprecate all previous
>>>>> implementations of the Intel IGD passthrough feature in both hvmloader and
>>>>> the Qemu DM as unsupported. So my previous comments about backward
>>>>> compatibility apply here again.
>>>>
>>>> As said, I don't think backward compatibility can be dropped. My comment
>>>> also didn't really mean to hint in that direction. Instead I was wondering
>>>> in how far, even if perhaps by only a few #define-s, the necessary
>>>> interfacing couldn't be put down in a public header, for any DM to consume.
>>> 
>>> Ok. Perhaps the IGD_* defines could be moved to a public header to define the
>>> interface to be used to support the Intel IGD. Would it be OK to move those
>>> to a separate igd.h header
>> 
>> This may require input by others, as in the given situation I'm not quite
>> sure what is best. Anthony - do you possibly have any suggestion here?
>> 
>>> and include it in hvmloader/config.h?
>> 
>> I don't see why that would be needed. The few files which need the #define-s
>> can include that new public header, without impacting anything else.
> 
> So I would just include it in the new intel-opregion.c file. Also, maybe igd-related
> declarations should be moved there too, such as the currently existing extern variable
> igd_opregion_pgbase and my newly proposed extern variable igd_opregion_e820_pages,
> which would mean the new header would also need to be included in hvmloader/e820.c.

Actually, those igd-related declarations do not need to be in a public header. But I
think if we go to a public header for any DM to consume, we need to fixup oddities
like the current definition of IGD_OPREGION_PAGES of 3 when the actual number of pages
in the OpRegion is exactly 2. So I propose the next version of this patch should
add a preliminary patch to cleanup the oddities in the current implementation such as
having IGD_OPREGION_PAGES set to 3 without introducing any functional change by
redefining IGD_OPREGION_PAGES to the value it should be, which is 2. Then we can
include IGD_OPREGION2_SUPPORT_MASK, IGD_OPREGION_PAGES, etc. as defines in a public
header for any DM to consume. I can probably build such a public header directly from
IGD-related header files in use in the Linux kernel or in the Qemu/vfio IGD-related
headers files.

Chuck


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 17:54:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 17:54:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391383.1631233 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuw6z-0005JI-Ng; Fri, 14 Aug 2026 17:54:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391383.1631233; Fri, 14 Aug 2026 17:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuw6z-0005JB-K8; Fri, 14 Aug 2026 17:54:33 +0000
Received: by outflank-mailman (input) for mailman id 1391383;
 Fri, 14 Aug 2026 17:54:32 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3VVZ_agYKCVoK62FB48GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--seanjc.bounces.google.com>)
 id 1wuw6y-0005J5-Ep
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 17:54:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuw6x-003QFF-Gc
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 19:54:31 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3VVZ_agYKCVoK62FB48GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--seanjc.bounces.google.com>)
 id 6a7f562c-e002-0a2a0a5209dd-0a2a450bc922-28
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 19:54:31 +0200
Received: from [209.85.210.198] (helo=mail-pf1-f198.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3VVZ_agYKCVoK62FB48GG8D6.4GEP6F-56N6DDAKLK.P6FHJGB64L.GJ8@flex--seanjc.bounces.google.com>)
 id 6a7f5655-b7e8-0a2a450b0019-d155d2c6b4e0-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 19:54:31 +0200
Received: by mail-pf1-f198.google.com with SMTP id
 d2e1a72fcca58-848568a6f62so1366672b3a.0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 10:54:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786730069; x=1787334869; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LfaLWAErtycI8626dIr9iK18/ZV1rhd51zLN5VGW8CI=;
        b=c7kdra7Qck2cMP+Rs7XLWwxDNaODFcGhMm7v69w2bQac/EseFbMDosYDJBKAnfGokF
         4QDJiRdp/0HctWr7MP8NPPDcCZxn30aDYkAHkDSiDwfyyr4lLVW1XD82dkgWZAeqZZcc
         Zrw7mNH8aB1P5DC8dZQFi8We6NlpfOBREEiCPLxZRH3XWMA9e0x0Fe8VDlUpDI9gcbXd
         x2eM8hqq5/VW8u6Sukhby+TNmtXwLNpNn95AnAa2iWuNZ9bekqTQb7MYtiiKnK6r4J0C
         QDA687+ojQcsaYaFXYk1RmMXQEOsOkhRWm/zfcC88z6Sxe+fJQ2ivcnFqfACcN2p9ikb
         Y6Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786730069; x=1787334869;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LfaLWAErtycI8626dIr9iK18/ZV1rhd51zLN5VGW8CI=;
        b=Yntk64VHh/YyrVqCUmLHpvMa2dPwrVZGQLCjOzYJHmlt+Uq4BQ3Ifd4ic/Nw4zuSA9
         hkqTY+yTveialGb2EbWVEbLOrXqOIPq5vR7g2OwgLIXB9CgZ1Ca/l97J/w699vH+2YqX
         oAtmLUzNAwqDPe6Z/0JG3lT1OeN3aPJFlopAZ5TJpBqRpG92O8VkPRj094VxhMmOVFr1
         oh2d7vsaHO4n40ePnlo7S5c7IQJiwuHMhyX2a6Qe/RrELNEUOrPqEfDjGcewgUoHd/mY
         V9bNRgdFGHJZhRiwnon+KhUYhWCONbXp2yeylAoI595Qh73RftN6fv98MQd/zCybi68N
         JUVg==
X-Forwarded-Encrypted: i=1; AHgh+Rr2LRfmKjf8wttWoeAz1/OTTvxDPngxnnqSO3icJfZ2bwt9WmhLHJq9TYqp74jxPrzC9FKncv7wVqg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyo3dYijjzCXfZefjRb+kEwCy/Iw8OBtI6J40Cya9XtGFa5hE/S
	pNgAquUCyy+jrZhgrxggLIyd8btgSp9Iuw87iZmaSWoPbF3m3hSM07qLRPHESktGnz66i9/rhs5
	EdzpSYw==
X-Received: from pge22.prod.google.com ([2002:a05:6a02:2d16:b0:cbe:e919:f4bc])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:88c3:0:b0:848:4d1a:9554
 with SMTP id d2e1a72fcca58-84fde32cb70mr7530427b3a.38.1786730069038; Fri, 14
 Aug 2026 10:54:29 -0700 (PDT)
Date: Fri, 14 Aug 2026 10:54:28 -0700
In-Reply-To: <c5c532e01309c8c73de2b0f393539b608c495f1f.camel@infradead.org>
Mime-Version: 1.0
References: <antQYJvRxJxOjtut@google.com> <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org>
 <antb01WqOrs-tztm@google.com> <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org>
 <ants4VjfAiblaWsl@google.com> <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org>
 <anuYNxD81OE3MrQw@google.com> <5efe7a3914a3610ee00a487379caff84af6aa731.camel@infradead.org>
 <anusv0DloFhLMMoW@google.com> <c5c532e01309c8c73de2b0f393539b608c495f1f.camel@infradead.org>
Message-ID: <an9WVBHSsy5W0PUk@google.com>
Subject: Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs
 are offset from each other
From: Sean Christopherson <seanjc@google.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
	Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross <jgross@suse.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>, 
	Jonathan Cameron <jic23@kernel.org>, Sascha Bischoff <Sascha.Bischoff@arm.com>, 
	Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, 
	Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-42698a/1786730071-190CD9EA-958C6DEE/0/0
X-purgate-type: clean
X-purgate-size: 820

On Fri, Aug 14, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 16:14 -0700, Sean Christopherson wrote
> > I'm not totally opposed to a broader GET, but we should definitely get Paolo's
> > eyes on this sooner than later.
> 
> We've been saying that for two years. Shall I bring a net and a whip to
> KVM Forum? Or Plumbers? :)

I pointed at this thread in the "clocks" pull request, so then should be now,
soon.  And if that doesn't work, I'll just rename the getter to
KVM_GET_PAOLO_PAOLO_PAOLO and send a pull request.  Either that will get his
attention, or we'll have a source of amusement for years to come :-)

Joking aside, this would be a good PUCK topic if we need/want a synchronous
session to sort things out.

[*] https://lore.kernel.org/all/20260812213206.1564354-2-seanjc@google.com


From xen-devel-bounces@lists.xenproject.org Fri Aug 14 18:59:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 18:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391430.1631250 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7L-0005Bl-Hh; Fri, 14 Aug 2026 18:58:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391430.1631250; Fri, 14 Aug 2026 18:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7L-0005Be-EP; Fri, 14 Aug 2026 18:58:59 +0000
Received: by outflank-mailman (input) for mailman id 1391430;
 Fri, 14 Aug 2026 18:58:58 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wux7K-00051t-Mp
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:58:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wux7K-003WkB-3h
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 20:58:58 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6541-e002-0a2a0a5209dd-0a2a450ca5e2-30
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:58 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6571-f479-0a2a450c0019-d155dd2fb89c-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:58 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47362928f65so1275884f8f.2
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 11:58:58 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f229681sm8682153f8f.16.2026.08.14.11.58.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 11:58:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786733937; x=1787338737; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=H8CEnLypOeiEHj/KssqxJXig/KwJTFmcmbXdDvWWB3I=;
        b=nfjLlvjMPuTRzIM01KfrmBgOE0M8n/L1O81Bgaf2ZorNW5mttMVyie3OQ0yuVKAoOo
         8rBe2zaqTsT90uNJ8yyi1BiAnziQJuDMDNqFFQecvM2LWBy9gRBA6BTDm5i2Os3nA5sW
         xVna6jZNu7S9LMQrScKz0YDupj84h0ygmvJUM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786733937; x=1787338737;
        h=content-transfer-encoding:content-type: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=H8CEnLypOeiEHj/KssqxJXig/KwJTFmcmbXdDvWWB3I=;
        b=nn/GXuZGoR5M2tBF9y9sdaPu3lLjzdEMPckRPyqE6kEupZxOMIi7k3f9rxg8xURXfr
         t41TApX5lQW6WseH4jKYOKeGnc5sTrw3iCcqk8rp8VX+DkWcbEbyYOhL6R4uuXwO/WpY
         AG2fz37OOpN5T8cpNuFaVoY/+JJWOdJPf82sVqmYqm0Tvb+7nNyw34ftL5S0rAohJ5al
         x6BUnSZhxLMH3Xf8M36eJe/+pVmbS20TN/doC0foN2glMG5OJ5Gx9VW/gdxq0gPJ1qME
         MINvbks0Iee8YCOWb3kkc/1NZE9vCLP8YrLTD9nJXAsieM0b/0rcpvvz6U3ffvryI13A
         aXdg==
X-Gm-Message-State: AOJu0YyaTsJbMD0FeBkJJyVyHzW9uFWitvuta2ybIXLcu9OY3gFFtdoV
	vDFjmnR6mOM4YXmA29tveun457xyudhBL0hJF5QXa7Mwm1Ihm4o1kv3qeqanY7ZOAQ6Y9Dq7CDD
	hyV7r
X-Gm-Gg: AR+sD11v2B5kb1PfPDtKcjJ0kEazO9P9e0tryz2otk6aVz2hC3qTUTy5fMK4nxlq81C
	nzYDHlkKtxf/qhN/ZKRTfwG1d5eea1kL2hwASoGEuNQ35uuM4X+SK0toEdZZRNgzagQhvPKvCis
	yzQFSc7uz21z/cvk3U1mYuBBALm1MVTB83ciYi/hnvyUhEulD2t1WPGkfXNXVRRDbDQJTu+Oi/x
	bzeqNqLinOHB8FvgNnHMEU5SNAokuMZOBSmrefyMCurxJ9CLgUhGU2ExDTGHgBWhzrVkKY/djNu
	zR2np/5h5iAjBCV5oWpp9HaWhlUEWzUv8Lwp6mi09ccs/T1KRwIvjBn9upeuOS/8U0mHkkVY3oO
	knBRBO3NdEK+od4lXrpJ7Y03dI9+vU8RwKhynemA0bCBTPG6QPYDEE++zPIwcOIxzvBhmnJH7iN
	3gnAHruZt2nO8jyqmLGNAfVdNf1Fft198Aljgpymj2350KQUaFHKKinj8uLaK3G6T4CSLqqn0oz
	1kjsfrN8o/9FsiaqnYF6h9cQPQ7u5bxIlG8Qect
X-Received: by 2002:a05:6000:2206:b0:47f:7aee:ed3c with SMTP id ffacd0b85a97d-481606fbddamr13030909f8f.5.1786733937018;
        Fri, 14 Aug 2026 11:58:57 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 1/3] x86/emul: Adjust comments in x86-types.h
Date: Fri, 14 Aug 2026 19:58:39 +0100
Message-Id: <20260814185841.1757421-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786733938-024DFA5B-D205CDE3/0/0
X-purgate-type: clean
X-purgate-size: 1295

x86_segment enumerates segments, not segment registers.  Adjust the comment to
make this clearer.

Fix a stray tab with the closing #endif.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/include/asm/x86-types.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/include/asm/x86-types.h b/xen/arch/x86/include/asm/x86-types.h
index 1c43421885f7..26b06aeac380 100644
--- a/xen/arch/x86/include/asm/x86-types.h
+++ b/xen/arch/x86/include/asm/x86-types.h
@@ -16,9 +16,10 @@
 #endif
 
 /*
- * Comprehensive enumeration of x86 segment registers.  Various bits of code
- * rely on this order (general purpose before system, tr at the beginning of
- * system).
+ * x86 Segments.
+ *
+ * Various areas of code rely on this order (general purpose before system, tr
+ * at the beginning of system).
  */
 enum x86_segment {
     /* General purpose.  Matches the SReg3 encoding in opcode/ModRM bytes. */
@@ -73,4 +74,4 @@ struct segment_register {
     uint64_t   base;
 };
 
-#endif	/* X86_X86_TYPES_H */
+#endif /* X86_X86_TYPES_H */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 18:59:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 18:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391432.1631265 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7O-0005R2-2v; Fri, 14 Aug 2026 18:59:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391432.1631265; Fri, 14 Aug 2026 18:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7N-0005QI-Qq; Fri, 14 Aug 2026 18:59:01 +0000
Received: by outflank-mailman (input) for mailman id 1391432;
 Fri, 14 Aug 2026 18:59:00 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wux7M-0005JE-7R
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:59:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wux7L-001zlG-KO
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 20:58:59 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6542-8faa-0a2a0a5109dd-0a2a450b959a-34
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:59 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6573-b7e8-0a2a450b0019-d155dd33b5c7-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:59 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47f904e80eeso1316615f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 11:58:59 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f229681sm8682153f8f.16.2026.08.14.11.58.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 11:58:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786733939; x=1787338739; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=xCFz+bswAcxSZNQCcoi1kMR/ZsUCGcovta9jkJRC0lc=;
        b=idJWDXTDSbwVnlimw9JFwOJHt5UAxqh1/l4noCVyO/bnK3XDJxWlyXooDAmCR8HUvw
         u5lBMZA18KG47RDT8vxbCUe4sCNoBKH9iNz8LCP1i3aV5uvjGKJD3f/FSLj4JjkWgQLd
         TAe3CzZNebx1E2R0Iw/S5Owgkf9HE/+3aZlxk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786733939; x=1787338739;
        h=content-transfer-encoding:content-type: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=xCFz+bswAcxSZNQCcoi1kMR/ZsUCGcovta9jkJRC0lc=;
        b=KVvQex1wzKvWFZmq/Z3kv7nprzq5g3B0tKBo7XG/XafgzxudVf90wbs2gvXIOfq+6z
         I/AeZDFzyJX9sw6jWQoxwzqOJdgAe5Bq3kA4mgw7ePelSMuAk/5KYUgWmraRZ5BAjuAq
         1M9A8sDN1+yv7qjxqJ0h4pG409n/46XNPMyph8ZA2bucWAS+hziDotlJhRR+g4kbgAJO
         DQQpV3Ulk5E5Kylp7Yg2PVO9Lxzobx2UktYyPj++VYOpcpKd/eH47hUB+QiCJ2NxB/eE
         BghkTjpjqm0vtyBXOYF2IO1oD74JQzdy/yJzYV2iogi/QzfjAkZtvMEW5BB1b3RCuHbS
         eByA==
X-Gm-Message-State: AOJu0Yx58P491ygX7qhqvjzq9lqEufKqBNBtvRpU0mmQP0Yo21qmTQIH
	ev8tcXRuBYKcIE5lHUF6OSIry3hhNrCu787zeE9V6ySxF+U51VA9uT+hfd3p0cBgBD9QL6E2zT8
	6LXVYlpY=
X-Gm-Gg: AR+sD12rzfexMEtCDWKCBLRCR7ksGBV1gUTzl/dnAK0gwNQyIhh47/EuYqOhO7ud1Cv
	z93AYPzWcQrM0EOqVbupCnbbhgS0fNGWyQdNFuPFTjKkTyTWwqS2TFK4BMfWqUa2OW1jRvPHuVF
	k9pon2e7x7blhAV46hmGj0IP7BMGLgVe83WRkb0SWybCO6Umcj7q8qJjR/i2opumPcm6vb8v+qx
	fk8atoxVaNqdaGiBAXFCmsNCXCU2qY2cKyg4tfQxdI3G4/3ZhHErpoquU2sC+S+vOUfaGF3j9D+
	776YAXaE8jntNkmAmHG3CmkBDc3SHjpgDkoLkl3r+r+cZ3VQq+R4sP2KCYW+MfScFB2grCz/NEN
	AcQPUTb85cc8GYxBVD90jzUNo7OWEWeBGo40Thq4zLQtOWzRLNzcVzisr4qpCSFrT6KXgAxNhlJ
	Pnvf45HlZcOOair6LBsiVw8yEhBK5aBT+1Z6NMDp9/Ofu4qSTTZuucqPjH5HoWVTK7NIe7udojx
	j0acbX0zGiUNLvaoJFKnui+5woydnJuIQzYF2E=
X-Received: by 2002:a05:6000:2c09:b0:47f:9760:4d2e with SMTP id ffacd0b85a97d-481607618e8mr10222640f8f.24.1786733938786;
        Fri, 14 Aug 2026 11:58:58 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 3/3] x86/emul: Drop the union in x86_event had have a single data field
Date: Fri, 14 Aug 2026 19:58:41 +0100
Message-Id: <20260814185841.1757421-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786733939-A9EC69EA-3C395450/0/0
X-purgate-type: clean
X-purgate-size: 9111

FRED has formalised the event_data field.  It already has more uses than
given (e.g. the NMI Source Bitmap), and further uses are expected in the
future.

Collapse the union into a single field called 'data' as the struct has event
in it's name, as well as 'event' being the common name for the variable.
Refer to the FRED spec rather than keeping an out-of-date list of uses.

Adjust all users of the old names.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/hvm/dm.c                  |  2 +-
 xen/arch/x86/hvm/hvm.c                 |  4 ++--
 xen/arch/x86/hvm/svm/nestedsvm.c       |  2 +-
 xen/arch/x86/hvm/svm/svm.c             |  8 ++++----
 xen/arch/x86/hvm/vmx/vmx.c             |  2 +-
 xen/arch/x86/include/asm/domain.h      |  6 ++----
 xen/arch/x86/include/asm/hvm/hvm.h     |  3 +--
 xen/arch/x86/include/asm/x86-event.h   | 14 ++++++++++----
 xen/arch/x86/pv/traps.c                | 10 +++++-----
 xen/arch/x86/x86_emulate/x86_emulate.h |  2 +-
 10 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 1f44fff12a21..91f6ca669b2b 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -315,7 +315,7 @@ static int inject_event(struct domain *d,
     v->arch.hvm.inject_event.type = data->type;
     v->arch.hvm.inject_event.insn_len = data->insn_len;
     v->arch.hvm.inject_event.error_code = data->error_code;
-    v->arch.hvm.inject_event.cr2 = data->cr2;
+    v->arch.hvm.inject_event.data = data->cr2;
     smp_wmb();
     v->arch.hvm.inject_event.vector = data->vector;
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b7d5ba126b1e..64845e210b6c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -513,7 +513,7 @@ void hvm_migrate_pirqs(struct vcpu *v)
 
 static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
 {
-    info->cr2 = v->arch.hvm.guest_cr[2];
+    info->data = v->arch.hvm.guest_cr[2];
 
     return alternative_call(hvm_funcs.get_pending_event, v, info);
 }
@@ -555,7 +555,7 @@ void hvm_do_resume(struct vcpu *v)
         if ( hvm_get_pending_event(v, &info) )
         {
             hvm_monitor_interrupt(info.vector, info.type, info.error_code,
-                                  info.cr2);
+                                  info.data);
             v->arch.monitor.next_interrupt_enabled = false;
         }
     }
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 91c906072001..0845e9f77879 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -775,7 +775,7 @@ int cf_check nsvm_vcpu_vmexit_event(
     ASSERT(vcpu_nestedhvm(v).nv_vvmcx != NULL);
 
     nestedsvm_vmexit_defer(v, VMEXIT_EXCEPTION_DE + event->vector,
-                           event->error_code, event->cr2);
+                           event->error_code, event->data);
     return NESTEDHVM_VMEXIT_DONE;
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index eab8c735cf25..2219f9c4911e 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1177,7 +1177,7 @@ static void svm_emul_swint_injection(struct x86_event *event)
         {
             fault = X86_EXC_PF;
             ec = pfinfo.ec;
-            event->cr2 = pfinfo.linear;
+            event->data = pfinfo.linear;
         }
 
         goto raise_exception;
@@ -1270,8 +1270,8 @@ static void cf_check svm_inject_event(const struct x86_event *event)
 
     case X86_EXC_PF:
         ASSERT(_event.type == X86_ET_HW_EXC);
-        curr->arch.hvm.guest_cr[2] = _event.cr2;
-        vmcb_set_cr2(vmcb, _event.cr2);
+        curr->arch.hvm.guest_cr[2] = _event.data;
+        vmcb_set_cr2(vmcb, _event.data);
         break;
     }
 
@@ -1354,7 +1354,7 @@ static void cf_check svm_inject_event(const struct x86_event *event)
 
     if ( _event.vector == X86_EXC_PF && _event.type == X86_ET_HW_EXC )
         TRACE(TRC_HVM_PF_INJECT64, _event.error_code,
-              _event.cr2, _event.cr2 >> 32);
+              _event.data, _event.data >> 32);
     else
         TRACE(TRC_HVM_INJ_EXC, _event.vector, _event.error_code);
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b0d5ad6981b3..6ff4aeb70d41 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2106,7 +2106,7 @@ static void cf_check vmx_inject_event(const struct x86_event *event)
 
     case X86_EXC_PF:
         ASSERT(_event.type == X86_ET_HW_EXC);
-        curr->arch.hvm.guest_cr[2] = _event.cr2;
+        curr->arch.hvm.guest_cr[2] = _event.data;
         break;
     }
 
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 50c048adb5ad..2d0a91541034 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -747,10 +747,9 @@ static inline void pv_inject_DB(unsigned long pending_dbg)
         .vector      = X86_EXC_DB,
         .type        = X86_ET_HW_EXC,
         .error_code  = X86_EVENT_NO_EC,
+        .data        = pending_dbg,
     };
 
-    event.pending_dbg = pending_dbg;
-
     pv_inject_event(&event);
 }
 
@@ -760,10 +759,9 @@ static inline void pv_inject_page_fault(int errcode, unsigned long cr2)
         .vector = X86_EXC_PF,
         .type = X86_ET_HW_EXC,
         .error_code = errcode,
+        .data = cr2,
     };
 
-    event.cr2 = cr2;
-
     pv_inject_event(&event);
 }
 
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index 0ce7d5d78350..16383e1084ee 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -569,10 +569,9 @@ static inline void hvm_inject_page_fault(int errcode, unsigned long cr2)
         .vector = X86_EXC_PF,
         .type = X86_ET_HW_EXC,
         .error_code = errcode,
+        .data = cr2,
     };
 
-    event.cr2 = cr2;
-
     hvm_inject_event(&event);
 }
 
diff --git a/xen/arch/x86/include/asm/x86-event.h b/xen/arch/x86/include/asm/x86-event.h
index a8823c7cfc31..b0543c9e3715 100644
--- a/xen/arch/x86/include/asm/x86-event.h
+++ b/xen/arch/x86/include/asm/x86-event.h
@@ -22,10 +22,16 @@ struct x86_event {
     uint8_t       type;         /* X86_ET_* */
     uint8_t       insn_len;     /* Instruction length */
     int32_t       error_code;   /* X86_EVENT_NO_EC if n/a */
-    union {
-        unsigned long cr2;         /* #PF */
-        unsigned long pending_dbg; /* #DB (new DR6 bits, positive polarity) */
-    };
+
+    /*
+     * As per the FRED spec.
+     *
+     * A subset of uses occur in IDT mode as well:
+     * - #PF: CR2
+     * - #DB: PENDING_DBG (DR6 with positive polarity)
+     * - #NM: XFD_ERR (AMX)
+     */
+    unsigned long data;
 };
 
 #endif /* X86_X86_EVENT_H */
diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index c863ab9d372a..21a1f4b7174a 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -58,20 +58,20 @@ void pv_inject_event(const struct x86_event *event)
     switch ( vector | -(event->type == X86_ET_SW_INT) )
     {
     case X86_EXC_PF:
-        curr->arch.pv.ctrlreg[2] = event->cr2;
-        arch_set_cr2(curr, event->cr2);
+        curr->arch.pv.ctrlreg[2] = event->data;
+        arch_set_cr2(curr, event->data);
 
         /* Re-set error_code.user flag appropriately for the guest. */
         error_code &= ~PFEC_user_mode;
         if ( !guest_kernel_mode(curr, regs) )
             error_code |= PFEC_user_mode;
 
-        trace_pv_page_fault(event->cr2, error_code);
+        trace_pv_page_fault(event->data, error_code);
         break;
 
     case X86_EXC_DB:
         curr->arch.dr6 = x86_merge_dr6(curr->domain->arch.cpu_policy,
-                                       curr->arch.dr6, event->pending_dbg);
+                                       curr->arch.dr6, event->data);
         fallthrough;
     default:
         trace_pv_trap(vector, regs->rip, use_error_code, error_code);
@@ -94,7 +94,7 @@ void pv_inject_event(const struct x86_event *event)
                 vector, vector_name(vector), error_code);
 
         if ( vector == X86_EXC_PF )
-            show_page_walk(event->cr2);
+            show_page_walk(event->data);
     }
 }
 
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h b/xen/arch/x86/x86_emulate/x86_emulate.h
index 534b1c46fad3..da1051a0f9e7 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -758,7 +758,7 @@ static inline void x86_emul_pagefault(
     ctxt->event.vector = X86_EXC_PF;
     ctxt->event.type = X86_ET_HW_EXC;
     ctxt->event.error_code = error_code;
-    ctxt->event.cr2 = cr2;
+    ctxt->event.data = cr2;
 
     ctxt->event_pending = true;
 }
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 18:59:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 18:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391431.1631259 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7N-0005Ol-NL; Fri, 14 Aug 2026 18:59:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391431.1631259; Fri, 14 Aug 2026 18:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7N-0005Oe-Kb; Fri, 14 Aug 2026 18:59:01 +0000
Received: by outflank-mailman (input) for mailman id 1391431;
 Fri, 14 Aug 2026 18:59:00 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wux7M-0005Bd-3p
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:59:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wux7K-006yQi-SW
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 20:58:58 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6523-2eae-0a2a0a5409dd-0a2a4508a910-40
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:58 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6572-f659-0a2a45080019-d1558029bcf3-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:58 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so11788405e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 11:58:58 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f229681sm8682153f8f.16.2026.08.14.11.58.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 11:58:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786733938; x=1787338738; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=QtmaY6E0WOh6bcecniAklvM6olukym04Ax7bxpV8h4U=;
        b=tdr+QCxNTyBanaaGNRl5MN19QQdO6L7TUKu/rImuqgN0MmV/Hoc5plwtVd68Ta2i5s
         klYksnHrqiPc9JmMNWPTKEoMHFmaas3/NNO3XRnx3gOQixwd/I6H0fWRUC/nuxgGjr0c
         Dp6tieGu2mZxnESFW6eJU0h7n0lakNu64cGbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786733938; x=1787338738;
        h=content-transfer-encoding:content-type: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=QtmaY6E0WOh6bcecniAklvM6olukym04Ax7bxpV8h4U=;
        b=nSlj6C59eJKbLCK4HT8VcfAF8v3D7+mbjWSeF+R22T4qAQqeKZE+iCRjI3qYXKxWOk
         gD9q+gNgg2C5JJYJ4IrsumAwBQ1p3O5FTaokbVfyu8hcjhu8r0vD6lC7PkymiBytEPnV
         Sa/sK7dviuipj5STptOoTvaGdL0O60BSceuk0rgIK7hxI72hpbFaf9xSwWUnm58FLPin
         PqhbzfuPnKi0woQoflXfRCXhw2uLZ+fyfIomVaXdnLXmUCsWjrcG0+p7El7nh78X/hdQ
         rcNKercTljKmC+miBneuKpOxvgOck9z73Re0ngNHzMSlwbvPDInezZzEQ0hAtZ+KRRzM
         dGSg==
X-Gm-Message-State: AOJu0YzjD16fM2GhSCFWA6FXUsewDYZPZMSGUTiqOBwnriCpu1Vkt7ad
	pUXi5NRgU5f02OI4xCFCKP5FwsLXWa2ONLawtleNsKpT6gzia7psIDsEIt4wjy9XCXURlgIu9fp
	x+7gI
X-Gm-Gg: AR+sD13Ok5JtmJlIeDwGVMx2A21YnPOA0kyPtEi0ovUt+da3opx26FUdg9MsEzmttRa
	tczq1AdzYgZuubAqHpIUy7c2zPsZWC5e24jT+Q4wps1mmJ7+Yboc+PyJdB2ZmwTcyxbqtDE2sUB
	kk/RNFV7RpyjXj/vn8UrQL8oyAQlbGSiAV8yhS0k7n/g9IsZl6AkES1tLS07aCV6IBvt49G5t8Y
	4IC7m8FedtIR46RhtO2YibdF9GSp8MygDwSkltLvWZJGCQMBJiKDaq9EkySTOC2QMWZydYl1x8V
	qqSL4AMm//a1BJFhZRO5EdAzmIyGMATL438vhgnfE14a1sh3BcnqKY0/ZqHN8eoL5pQ0ikfJq+O
	GImPyz7o9HvLbQLTsQaLtohLoQ+E4HpwyBQMuCbNi3vz/sOfB2pWYp4ih8yTZ08a4PhAKdJihes
	of40OwoPDAz6d+D/do+FhNUpBY/izOYP/118rfVnmIjDgCWSy7yWc4OtQWCpuN+bPK6yiz7fNrY
	jXWyAW1ayUytuyd/fGwz4LhPZfhv5u1C28DClk=
X-Received: by 2002:a05:600c:3491:b0:498:952:e276 with SMTP id 5b1f17b1804b1-499879653bbmr122153255e9.8.1786733937704;
        Fri, 14 Aug 2026 11:58:57 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 2/3] x86/emul: Drop trailing r from x86_seg_[lgi]dt names
Date: Fri, 14 Aug 2026 19:58:40 +0100
Message-Id: <20260814185841.1757421-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1786733938-CC97287B-4C0DD2D5/0/0
X-purgate-type: clean
X-purgate-size: 16940

These refer to the segment, not to the segment registers.  TR is the
odd-one-out having "register" in it's name.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 .../fuzz/x86_instruction_emulator/fuzz-emul.c |  2 +-
 tools/tests/x86_emulator/test_x86_emulator.c  |  4 +-
 xen/arch/x86/hvm/hvm.c                        | 42 +++++++++----------
 xen/arch/x86/hvm/svm/svm.c                    | 22 +++++-----
 xen/arch/x86/hvm/vmx/realmode.c               |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c                    | 22 +++++-----
 xen/arch/x86/include/asm/x86-types.h          |  6 +--
 xen/arch/x86/vm_event.c                       |  4 +-
 xen/arch/x86/x86_emulate/0f01.c               |  2 +-
 xen/arch/x86/x86_emulate/x86_emulate.c        |  6 +--
 10 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 2b9b72df3584..ebe085465aae 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -362,7 +362,7 @@ static int fuzz_cmpxchg(
     if ( is_x86_user_segment(seg) )
         assert(ctxt->addr_size == 64 || !(offset >> 32));
     else
-        assert((seg == x86_seg_gdtr || seg == x86_seg_ldtr) && !(offset >> 16));
+        assert((seg == x86_seg_gdt || seg == x86_seg_ldt) && !(offset >> 16));
 
     return maybe_fail(ctxt, "cmpxchg", true);
 }
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c b/tools/tests/x86_emulator/test_x86_emulator.c
index 31391f1bf790..61b2840ee058 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -559,7 +559,7 @@ static int read(
     {
         uint64_t value;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         /* Fake system segment type matching table index. */
         if ( (offset & 7) || (bytes > 8) )
             return X86EMUL_UNHANDLEABLE;
@@ -579,7 +579,7 @@ static int read(
         memcpy(p_data, &value, bytes);
         return X86EMUL_OKAY;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         /* Fake user segment type matching table index. */
         if ( (offset & 7) || (bytes > 8) )
             return X86EMUL_UNHANDLEABLE;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a75ccb57bf04..b7d5ba126b1e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -879,11 +879,11 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
     /* Architecture-specific vmcs/vmcb bits */
     alternative_vcall(hvm_funcs.save_cpu_ctxt, v, &ctxt);
 
-    hvm_get_segment_register(v, x86_seg_idtr, &seg);
+    hvm_get_segment_register(v, x86_seg_idt, &seg);
     ctxt.idtr_limit = seg.limit;
     ctxt.idtr_base = seg.base;
 
-    hvm_get_segment_register(v, x86_seg_gdtr, &seg);
+    hvm_get_segment_register(v, x86_seg_gdt, &seg);
     ctxt.gdtr_limit = seg.limit;
     ctxt.gdtr_base = seg.base;
 
@@ -929,7 +929,7 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
     ctxt.tr_base = seg.base;
     ctxt.tr_arbytes = seg.attr;
 
-    hvm_get_segment_register(v, x86_seg_ldtr, &seg);
+    hvm_get_segment_register(v, x86_seg_ldt, &seg);
     ctxt.ldtr_sel = seg.sel;
     ctxt.ldtr_limit = seg.limit;
     ctxt.ldtr_base = seg.base;
@@ -1129,11 +1129,11 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 
     seg.limit = ctxt.idtr_limit;
     seg.base = ctxt.idtr_base;
-    hvm_set_segment_register(v, x86_seg_idtr, &seg);
+    hvm_set_segment_register(v, x86_seg_idt, &seg);
 
     seg.limit = ctxt.gdtr_limit;
     seg.base = ctxt.gdtr_base;
-    hvm_set_segment_register(v, x86_seg_gdtr, &seg);
+    hvm_set_segment_register(v, x86_seg_gdt, &seg);
 
     seg.sel = ctxt.cs_sel;
     seg.limit = ctxt.cs_limit;
@@ -1181,7 +1181,7 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
     seg.limit = ctxt.ldtr_limit;
     seg.base = ctxt.ldtr_base;
     seg.attr = ctxt.ldtr_arbytes;
-    hvm_set_segment_register(v, x86_seg_ldtr, &seg);
+    hvm_set_segment_register(v, x86_seg_ldt, &seg);
 
     if ( ctxt.flags & XEN_X86_FPU_INITIALISED )
         vcpu_setup_fpu(v, &ctxt.fpu_regs);
@@ -2875,11 +2875,11 @@ static int task_switch_load_seg(
     }
 
     /* LDT descriptor must be in the GDT. */
-    if ( (seg == x86_seg_ldtr) && (sel & 4) )
+    if ( (seg == x86_seg_ldt) && (sel & 4) )
         goto fault;
 
     hvm_get_segment_register(
-        v, (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr, &desctab);
+        v, (sel & 4) ? x86_seg_ldt : x86_seg_gdt, &desctab);
 
     /* Segment not valid for use (cooked meaning of .p)? */
     if ( !desctab.p )
@@ -2897,7 +2897,7 @@ static int task_switch_load_seg(
         desc = *pdesc;
 
         /* LDT descriptor is a system segment. All others are code/data. */
-        if ( (desc.b & (1u<<12)) == ((seg == x86_seg_ldtr) << 12) )
+        if ( (desc.b & (1 << 12)) == ((seg == x86_seg_ldt) << 12) )
             goto fault;
 
         dpl = (desc.b >> 13) & 3;
@@ -2920,7 +2920,7 @@ static int task_switch_load_seg(
             if ( (dpl != cpl) || (dpl != rpl) )
                 goto fault;
             break;
-        case x86_seg_ldtr:
+        case x86_seg_ldt:
             /* LDT system segment? */
             if ( (desc.b & _SEGMENT_TYPE) != (2u<<8) )
                 goto fault;
@@ -3035,7 +3035,7 @@ void hvm_task_switch(
     unsigned int token = hvmemul_cache_disable(v);
     struct tss32 tss;
 
-    hvm_get_segment_register(v, x86_seg_gdtr, &gdt);
+    hvm_get_segment_register(v, x86_seg_gdt, &gdt);
     hvm_get_segment_register(v, x86_seg_tr, &prev_tr);
 
     if ( ((tss_sel & 0xfff8) + 7) > gdt.limit )
@@ -3120,7 +3120,7 @@ void hvm_task_switch(
     tss.fs = segr.sel;
     hvm_get_segment_register(v, x86_seg_gs, &segr);
     tss.gs = segr.sel;
-    hvm_get_segment_register(v, x86_seg_ldtr, &segr);
+    hvm_get_segment_register(v, x86_seg_ldt, &segr);
     tss.ldt = segr.sel;
 
     rc = hvm_copy_to_guest_linear(prev_tr.base + offsetof(typeof(tss), eip),
@@ -3146,7 +3146,7 @@ void hvm_task_switch(
 
     new_cpl = tss.eflags & X86_EFLAGS_VM ? 3 : tss.cs & 3;
 
-    if ( task_switch_load_seg(x86_seg_ldtr, tss.ldt, new_cpl, 0) )
+    if ( task_switch_load_seg(x86_seg_ldt, tss.ldt, new_cpl, 0) )
         goto out;
 
     rc = hvm_set_cr3(tss.cr3, false, true);
@@ -4011,14 +4011,14 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip)
     hvm_set_segment_register(v, x86_seg_ss, &reg);
 
     reg.attr = 0x82; /* LDT */
-    hvm_set_segment_register(v, x86_seg_ldtr, &reg);
+    hvm_set_segment_register(v, x86_seg_ldt, &reg);
 
     reg.attr = 0x8b; /* 32-bit TSS (busy) */
     hvm_set_segment_register(v, x86_seg_tr, &reg);
 
     reg.attr = 0;
-    hvm_set_segment_register(v, x86_seg_gdtr, &reg);
-    hvm_set_segment_register(v, x86_seg_idtr, &reg);
+    hvm_set_segment_register(v, x86_seg_gdt, &reg);
+    hvm_set_segment_register(v, x86_seg_idt, &reg);
 
     /* Sync AP's TSC with BSP's. */
     v->arch.hvm.cache_tsc_offset =
@@ -5294,8 +5294,8 @@ void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
         reg->p = 1;
         break;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         /*
          * Treat GDTR/IDTR as being present system segments.  This avoids them
          * needing special casing for segmentation checks.
@@ -5394,7 +5394,7 @@ void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
             ASSERT(!"%tr typecheck failure");
         break;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         if ( reg->p )
         {
             ASSERT(!reg->s);                         /* System segment. */
@@ -5404,8 +5404,8 @@ void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
         }
         break;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         ASSERT(is_canonical_address(reg->base));
         ASSERT((reg->limit >> 16) == 0);             /* Upper bits clear. */
         break;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 38c61db1d71d..eab8c735cf25 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -627,15 +627,15 @@ static void cf_check svm_get_segment_register(
         *reg = vmcb->tr;
         break;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         *reg = vmcb->gdtr;
         break;
 
-    case x86_seg_idtr:
+    case x86_seg_idt:
         *reg = vmcb->idtr;
         break;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         svm_sync_vmcb(v, vmcb_in_sync);
         *reg = vmcb->ldtr;
         break;
@@ -664,15 +664,15 @@ static void cf_check svm_set_segment_register(
         vmcb->cleanbits.seg = false;
         break;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         vmcb->cleanbits.dt = false;
         break;
 
     case x86_seg_fs:
     case x86_seg_gs:
     case x86_seg_tr:
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         if ( v == current )
             svm_sync_vmcb(v, vmcb_needs_vmload);
         break;
@@ -698,17 +698,17 @@ static void cf_check svm_set_segment_register(
         vmcb->tr = *reg;
         break;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         vmcb->gdtr.base = reg->base;
         vmcb->gdtr.limit = reg->limit;
         break;
 
-    case x86_seg_idtr:
+    case x86_seg_idt:
         vmcb->idtr.base = reg->base;
         vmcb->idtr.limit = reg->limit;
         break;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         vmcb->ldtr = *reg;
         break;
 
@@ -1163,8 +1163,8 @@ static void svm_emul_swint_injection(struct x86_event *event)
      * this entry, even though we don't look at all the words read.
      */
     hvm_get_segment_register(curr, x86_seg_cs, &cs);
-    hvm_get_segment_register(curr, x86_seg_idtr, &idtr);
-    if ( !hvm_virtual_to_linear_addr(x86_seg_idtr, &idtr, idte_offset,
+    hvm_get_segment_register(curr, x86_seg_idt, &idtr);
+    if ( !hvm_virtual_to_linear_addr(x86_seg_idt, &idtr, idte_offset,
                                      idte_size, hvm_access_read,
                                      &cs, &idte_linear_addr) )
         goto raise_exception;
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index ff44ddcfa627..0a3ee0bb9e2c 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -34,7 +34,7 @@ static void realmode_deliver_exception(
     uint16_t frame[3];
     unsigned int last_byte;
 
-    idtr = hvmemul_get_seg_reg(x86_seg_idtr, hvmemul_ctxt);
+    idtr = hvmemul_get_seg_reg(x86_seg_idt, hvmemul_ctxt);
     csr  = hvmemul_get_seg_reg(x86_seg_cs,   hvmemul_ctxt);
     __set_bit(x86_seg_cs, &hvmemul_ctxt->seg_reg_dirty);
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 269ca5643346..b0d5ad6981b3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1227,19 +1227,19 @@ static void cf_check vmx_get_segment_register(
     }
 
     /*
-     * Xen's x86_seg_* enumeration *almost* matches the VMCS encoding order.
+     * Xen's x86_segment encoding *almost* matches the VMCS encoding order.
      *
-     * tr and ldtr are reversed, and other areas of code rely on this, so we
+     * tr and ldt are reversed, and other areas of code rely on this, so we
      * can't just re-enumerate.
      */
     BUILD_BUG_ON(x86_seg_tr   != 6);
-    BUILD_BUG_ON(x86_seg_ldtr != 7);
-    BUILD_BUG_ON(x86_seg_gdtr != 8);
-    BUILD_BUG_ON(x86_seg_idtr != 9);
+    BUILD_BUG_ON(x86_seg_ldt  != 7);
+    BUILD_BUG_ON(x86_seg_gdt  != 8);
+    BUILD_BUG_ON(x86_seg_idt  != 9);
     switch ( tmp_seg = seg )
     {
     case x86_seg_tr:
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         tmp_seg ^= 1; /* Flip tr and ldtr so GUEST_SEG_*() works. */
         fallthrough;
 
@@ -1248,8 +1248,8 @@ static void cf_check vmx_get_segment_register(
         __vmread(GUEST_SEG_AR_BYTES(tmp_seg), &attr);
         fallthrough;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         __vmread(GUEST_SEG_LIMIT(tmp_seg),    &limit);
         __vmread(GUEST_SEG_BASE(tmp_seg),     &reg->base);
         break;
@@ -1368,7 +1368,7 @@ static void cf_check vmx_set_segment_register(
     switch ( seg )
     {
     case x86_seg_tr:
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         seg ^= 1; /* Flip tr and ldtr so GUEST_SEG_*() works. */
         fallthrough;
 
@@ -1377,8 +1377,8 @@ static void cf_check vmx_set_segment_register(
         __vmwrite(GUEST_SEG_AR_BYTES(seg), attr);
         fallthrough;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         __vmwrite(GUEST_SEG_LIMIT(seg),    limit);
         __vmwrite(GUEST_SEG_BASE(seg),     base);
         break;
diff --git a/xen/arch/x86/include/asm/x86-types.h b/xen/arch/x86/include/asm/x86-types.h
index 26b06aeac380..488dc2b0cdaa 100644
--- a/xen/arch/x86/include/asm/x86-types.h
+++ b/xen/arch/x86/include/asm/x86-types.h
@@ -31,9 +31,9 @@ enum x86_segment {
     x86_seg_gs,
     /* System: Valid to use for implicit table references. */
     x86_seg_tr,
-    x86_seg_ldtr,
-    x86_seg_gdtr,
-    x86_seg_idtr,
+    x86_seg_ldt,
+    x86_seg_gdt,
+    x86_seg_idt,
     /* No Segment: For (system/normal) accesses which are already linear. */
     x86_seg_sys,
     x86_seg_none
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 112d2ef66dc7..efafb4e4bc14 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -183,7 +183,7 @@ static void vm_event_pack_segment_register(enum x86_segment segment,
         reg->es_sel = seg.sel;
         break;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         reg->gdtr_base = seg.base;
         reg->gdtr_limit = seg.limit;
         break;
@@ -248,7 +248,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
     vm_event_pack_segment_register(x86_seg_ss, &req->data.regs.x86);
     vm_event_pack_segment_register(x86_seg_ds, &req->data.regs.x86);
     vm_event_pack_segment_register(x86_seg_es, &req->data.regs.x86);
-    vm_event_pack_segment_register(x86_seg_gdtr, &req->data.regs.x86);
+    vm_event_pack_segment_register(x86_seg_gdt, &req->data.regs.x86);
 
     req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
     req->data.regs.x86.dr6 = ctxt.dr6;
diff --git a/xen/arch/x86/x86_emulate/0f01.c b/xen/arch/x86/x86_emulate/0f01.c
index d2a106557d36..ff39aefd0382 100644
--- a/xen/arch/x86/x86_emulate/0f01.c
+++ b/xen/arch/x86/x86_emulate/0f01.c
@@ -22,7 +22,7 @@ int x86emul_0f01(struct x86_emulate_state *s,
                  struct x86_emulate_ctxt *ctxt,
                  const struct x86_emulate_ops *ops)
 {
-    enum x86_segment seg = (s->modrm_reg & 1) ? x86_seg_idtr : x86_seg_gdtr;
+    enum x86_segment seg = (s->modrm_reg & 1) ? x86_seg_idt : x86_seg_gdt;
     int rc;
 
     switch ( s->modrm )
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index e15ab3775854..24db9fd175d0 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -891,7 +891,7 @@ protmode_load_seg(
     const struct x86_emulate_ops *ops)
 {
     const struct cpu_policy *cp = ctxt->cpu_policy;
-    enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr;
+    enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldt : x86_seg_gdt;
     struct { uint32_t a, b; } desc, desc_hi = {};
     uint8_t dpl, rpl;
     int cpl = x86emul_get_cpl(ctxt, ops);
@@ -992,7 +992,7 @@ protmode_load_seg(
         if ( (dpl != cpl) || (dpl != rpl) )
             goto raise_exn;
         break;
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         /* LDT system segment? */
         if ( (desc.b & (15u<<8)) != (2u<<8) )
             goto raise_exn;
@@ -2914,7 +2914,7 @@ x86_emulate(
         break;
 
     case X86EMUL_OPC(0x0f, 0x00): /* Grp6 */
-        seg = (modrm_reg & 1) ? x86_seg_tr : x86_seg_ldtr;
+        seg = (modrm_reg & 1) ? x86_seg_tr : x86_seg_ldt;
         generate_exception_if(!in_protmode(ctxt, ops), X86_EXC_UD);
         switch ( modrm_reg & 6 )
         {
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 18:59:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 18:59:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391429.1631240 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7K-0004zA-AV; Fri, 14 Aug 2026 18:58:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391429.1631240; Fri, 14 Aug 2026 18:58:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wux7K-0004z3-7m; Fri, 14 Aug 2026 18:58:58 +0000
Received: by outflank-mailman (input) for mailman id 1391429;
 Fri, 14 Aug 2026 18:58:58 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wux7J-0004yx-Se
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 18:58:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wux7J-003WkB-9K
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 20:58:57 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6541-e002-0a2a0a5209dd-0a2a450ca5e2-26
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:57 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a7f6571-f479-0a2a450c0019-d155dd2eed4c-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 20:58:57 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47ddf7b09e5so1222848f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 11:58:57 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4815f229681sm8682153f8f.16.2026.08.14.11.58.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 14 Aug 2026 11:58:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786733937; x=1787338737; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=lbqIDU5qqia2cTs+RqhS404ZmRB6enkb3DZiZgMZOVk=;
        b=VhLgyhH+fD5xgCbEHWYNVtb4e3RqX1VisTUpxClLxZb02VgWQoK1OQi85gg6XLIZbv
         rhBROEuXB6ruWsDUeRKjN/Bkq68T+9LphosYhTTmTEw3IyALbQbf/r05PrsNlGX1OGGg
         r1kbv/z391deDQ+XUbE2zX4Amdlke0lLb8Loc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786733937; x=1787338737;
        h=content-transfer-encoding:content-type:mime-version: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=lbqIDU5qqia2cTs+RqhS404ZmRB6enkb3DZiZgMZOVk=;
        b=CV5SL9WnukWNLSsdrlxppyjn4v8rxnmjsv0JdBuihcNKNUWVRACm9ukv36NplW8vaV
         +7bb0JVJCMvks5hkfpugD8ROfwLx0sbBZ/rjGf9dwijqUsw70JTNzueUMZqsw/5cukVR
         36kb3jLt3/S7ngdNCu0/jQCdYlnZqr35YkPK/5toeQFV+p3BUHs+nZ4p2WIDY3uVQxhq
         YkphwUB3cVdgsAg/asrjMpuO3HmoJeNN2a75cK/y+uOaSDUDnhj8ZGX3Jdsoi+sQrUSJ
         1jNPiPPuGWgy1fOnYX3BFazPKhH5zDsZEetBhhS/zOsZSMz4jUrm6vmfwrct/MjGP6Gb
         8cDg==
X-Gm-Message-State: AOJu0YxmfVgCVrEK8ez05QY4Myv2abU4OnsIuYpXqO2ZhZgGbLWlmxfc
	xQMB0d5HWuUQToK/FYeQsb/4bXKI23zHGgpnfusXDlhErgIw503oGSPfSTM9YFWNzHpAlBPZvvo
	NSjfQ/nM=
X-Gm-Gg: AR+sD10zu4o+qeDUg3cESZdUFATuoUravT8uE9cZ2TqdzI1VHtcFxuZmnkZbIX2o1We
	7TiKjUm7LkgB3t2UEKigcDlteCGfPggIptyQLzY9hv6KBVm+4SkVmtNEB1LdNdoyx1q9B/BmVyQ
	cYjSwXolalF8ILkqcYPPs4pi3ctOSnr49PzAng5T5OOYJ1tlcc9tGdwjBSMGz9B8OUUB0v7o+2x
	1Caa0M47qjEvxWrDsWG/EORyFckeW9LKd6twf7jS7enFpDLdCSZ9+AHVNzv7789iy2+G25eNVX9
	bh3KFZXuRGRgdX+8CMcryBOdZQ9Rr1bcNVEe4uyCdwXoWaEsh95viZPc224edrgcHI3n7+g9G2O
	RXDUxtozexLTqVNH+CGX7CmvMJ+dBuwWDkHeWZb0NrMd8XsAXlV8CWM6/lBV9c0MdGCSe1CH4+v
	Ykbk0TlH+wPfnKkfjkgVd7Hk0DagYew/JuE4mM8oVxxJKULMWuzF9Ziu4o/UeHbnfkS0EsrVeRH
	qIEYLFnVJezoAn8pD4EMXkzJRGVlGFlk3LCtvA=
X-Received: by 2002:a05:6000:2913:b0:47f:9266:9bde with SMTP id ffacd0b85a97d-481606f5992mr10023090f8f.4.1786733936396;
        Fri, 14 Aug 2026 11:58:56 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 0/3] x86/emul: Cleanup
Date: Fri, 14 Aug 2026 19:58:38 +0100
Message-Id: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786733937-030D9A5B-4BFF1EE7/0/0
X-purgate-type: clean
X-purgate-size: 1522

Cleanup from recent observations.

>From a future backporting perspective, now is about the least bad time to take
patchs 2 and 3, at the point we're doing all the other structural
rearrangements.

Andrew Cooper (3):
  x86/emul: Adjust comments in x86-types.h
  x86/emul: Drop trailing r from x86_seg_[lgi]dt names
  x86/emul: Drop the union in x86_event had have a single data field

 .../fuzz/x86_instruction_emulator/fuzz-emul.c |  2 +-
 tools/tests/x86_emulator/test_x86_emulator.c  |  4 +-
 xen/arch/x86/hvm/dm.c                         |  2 +-
 xen/arch/x86/hvm/hvm.c                        | 46 +++++++++----------
 xen/arch/x86/hvm/svm/nestedsvm.c              |  2 +-
 xen/arch/x86/hvm/svm/svm.c                    | 30 ++++++------
 xen/arch/x86/hvm/vmx/realmode.c               |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c                    | 24 +++++-----
 xen/arch/x86/include/asm/domain.h             |  6 +--
 xen/arch/x86/include/asm/hvm/hvm.h            |  3 +-
 xen/arch/x86/include/asm/x86-event.h          | 14 ++++--
 xen/arch/x86/include/asm/x86-types.h          | 15 +++---
 xen/arch/x86/pv/traps.c                       | 10 ++--
 xen/arch/x86/vm_event.c                       |  4 +-
 xen/arch/x86/x86_emulate/0f01.c               |  2 +-
 xen/arch/x86/x86_emulate/x86_emulate.c        |  6 +--
 xen/arch/x86/x86_emulate/x86_emulate.h        |  2 +-
 17 files changed, 89 insertions(+), 85 deletions(-)


base-commit: 0a249bcb0279a99b7ddad683fcc84a5e256c13f1
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Aug 14 19:13:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Aug 2026 19:13:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391465.1631277 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuxLS-00012r-8U; Fri, 14 Aug 2026 19:13:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391465.1631277; Fri, 14 Aug 2026 19:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wuxLS-00012k-5c; Fri, 14 Aug 2026 19:13:34 +0000
Received: by outflank-mailman (input) for mailman id 1391465;
 Fri, 14 Aug 2026 19:13:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wuxLP-00012e-RB
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 19:13:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wuxLO-004soJ-T6
 for xen-devel@lists.xenproject.org; Fri, 14 Aug 2026 21:13:30 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f68aa-8faa-0a2a0a5109dd-0a2a4505cad0-36
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 21:13:30 +0200
Received: from [98.137.65.205] (helo=sonic311-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7f68d8-4cb1-0a2a45050019-628941cd8711-3
 for <xen-devel@lists.xenproject.org>; Fri, 14 Aug 2026 21:13:30 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Aug 2026 19:13:28 +0000
Received: by hermes--production-bf1-54b5569bdc-bl9f6 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 1ccd2e992eb17031340ef65d0eddba97; 
 Fri, 14 Aug 2026 19:13:25 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786734808; bh=N5mOhM3pcLYxdtmPCBlPtPi8tMcEy9IQ0eVheW8E5UU=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=XIKpz409dKAEE+vxWMLVrkmW42Rwnqb3TSUSAiPkcb8WQgFZQkwqfwrWJMJoUX0El3l+ebga7DKEf/jfuNqAfgYLM4jaSseGWP8/NMscfzdqq06qbgsrVA0uXg9byp14njB7JBHbupGSXz8Gn17IpZBXi1xrEOr8vbmelmZcyCGVxL8IW8Uqw1eYKPQo2b7XirvgS/ePl95iKHk2eh9IrdoiUMNlQ/XYS321R+ofmb2gURNTBONbzUH+N465Mpd0nnL8ZwgKVtCaA2z1Vl+KeJ62Eun1fRpau+VNMn/w2OBqWY0UtcZvTf4kWg3/wWQz1Xd35JUp5HQAiw6FQcBJ7A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786734808; bh=W2GOJvWm0oO20Hcw38oTUdca3Leq4Wzq6VMhVFb8EY5=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=kbpn/uOAcFJG5q7w6zEIGJElWZ7r87ql24PIq/BCNqyoSNRvWKuslz2CWHPZotKZLSxjqcmNOskCLpapdFmnRjPInhXxnxe9nGdM+sPg4PgvCLhVKctpxMq3t4jsNE8riLckWCIa+/Sn3RIl5rpBHmlbyFLVPR8m590QPm/deQFAFf4pg3I90ZSNBnLGiHvARkDkmgyCqKyDuCqGD6amPKJJNa42De2c6F7C3NdCgU8eGRJxguXAXfSfB0VeAhLgq1K0N1TWlSW250/wBEb/HR3iy9QRi8GBJECH6BW7VU9yeYkacU4MbhFtjC13+oWwwqY+uhugRy3cZ2KAKi7Abg==
X-YMail-OSG: odNvy4wVM1nwqvG_z1AEeE6RgFZbu0hYKl3eOTRJrKUNm2lZOFmXGVFN0yha3Cj
 4FSwEKb2iYImKMO8eBnus6aNOQSRVdeveieDG_lpAK7TmZ5Y2d0Wlzwgc7DS79wj.0zaB0pTZ2cU
 ve20aJ3cRIaFaduambdkkG_kA5xoubaNRv8mA9aQNc0G_SSUWNTeIyxxx4x.nipY3NlxTMsVbffq
 e0fM3UnOQpQLyKV4MbTMcrUIYPb_6frE5jBVplUa_FN2ai.1qFHAp0SJbmHQPgPqdoLgfl.1di3Y
 KkRQWTOVZWhe6C.SV_JFGde30EwsH2v_gXJW05U9XfQJ6pomfLSSnuXof7bSQSDdpk9jsd40LxSl
 WtI1PhpJYLwgCbdfnXpR9W9NRF3wmc6H.85uJx1pqwbIMR87bs8Nr49f11CGGNuQVnw6ZSU1z_mQ
 hyOxZDRfKDTdpdduIq8Q5BuNBsJLse3yB3D5lnhsDdt8HEA4idOzWw_T9AIbYwqEoUsm_Nrlxb5o
 2julYMdgTrEG5SulcDKlm8GwzsNTcxaw8R5UQ1sRQj8DIFYK3nG0KvSKfJVslqBiWOwIs4w90Pp4
 KpBV8IH6FR_bBAUCvW1_j9E0xcAizcZ_ZmU6xG1UdqFnjG.VUXMlqmEnoleni86NaAB5bnKSeY5r
 GfL2Jul0VvRCnJwoqHqCtkPiKE384hKWsWk.wWVLwZFR5DKVTT.TS.CiXRpuQ.tNXB7NCpNGBr9W
 pXQng6SRqUE4NUeMZM.hH3mwAk3xid4pWOyIm_oN.B9jFt4gIDHzhaqbP8k5YBsFCWBaMwjykGGB
 SU80gI4fVT6DOOB7THvylvTnEqoWjF_Oi2IIBRU6MCYz3M0hXMb3V9hhl06ASfSNfygm2LVBCZpA
 ildzE3RpKYbgKnrponecBmtHeYM7YIzH6pTjIIUEB_Nc3_pzQ28PuoEm13hPMwEB9xNBoBme4toO
 607CBneSf3ratd._AeiOba4x_cDLHFpRKxnzP2ClfUd2ZmjnJ6XxwZbvTAOEr51h70wsJXEPLnTa
 C_p_mrnKy6Z7PTbib6NVEhB1xhdshMt.fAFThQ7cSGLimVf3_ARWY7R1SWVoZGzPuHUVt_2b.DaS
 WMfbdiSkBs0DcOIzA6F6bty7Pie77dLG1VpS87hEw4hZJqfK0IHlacWJTTK5WYR_sSjgUUlOdmy6
 erllfM5w7GiLsQhjRUS7pOZ8.6JP7blhtqGdAQhXMjy9D7wtjaqzqVf2aZC0eWEr47wjYS9i6w1j
 SwgqTrS87._ZEaR6sCy8fS4ZIpQbSB_eV.3jpK7FSeR6N6Hwl0sT0cqekG1g71CA7L43x2sM8L2F
 1PE3jWPx5PtSerYnKurNx5p0_AOoyP_p9ttPKk.6RVshhH_G51GDRNsNYT4cRlax1C.cHCRJjXNK
 PO3kV5flrL1OfKWEPDsVn6PxpVZj2.4iGOcqwuaHlZ7.vHiJn6xMZ4SzPXU9_cip3kSCjsGhNEWF
 SriNnGWvWd0niC8qBGI0jkCwzRN6Ikpr3uTBsLyYG.Rw_djkpY.qSKg4bgYQKPRlCvEqCNjttuL4
 9S5ZzHgU5X_bMdlxk4Ty7eJGb4R5RRPNEdBQTtYqB6DKTYydFrrCO2VJ0kZaSSLcPAI_rwVGZUfV
 pmgT0gCYYhSeN3VbrP2Ko94GQGgKvauNE39npwZ1Bzqhz2ATSCBihYQfrAXPeVadN4TUi0U3zczV
 YHU3CVV7AWgqyGqq08j3q75nyVcLpm1UIRUtumGDwk.mFmzNJ9yM6fP_rOzvdF9Dlx2Oi_IP2m39
 oyfaSKUKE1DnVmEjXKVY_56aXkkstUabd7yyLTn71qeR61laFmZ33SEcX3KrvsjDU.yfeewV1iub
 vSUL58409BDv2AOUEr1RumQ1B2JDYZVnhqRl.UV6HFMyUS6Gh8G4nUZTgsEIZktkpDKrbnKfW0Gc
 _Xf7Om2B2QNJvm.ndk.8_Uimhe3ksVvDyxtV6GYZDn84Pxjfvu9z2dM2Rd6.OXtxViJqFEAhWv.D
 K_RwhRpOFKTW_67Ty0.OzJYgvY5VqLQmLrUBQaNAXdD6q2eKmuS9natcopC7mlEjAJ4JWVoJG39N
 NYUNOqU_z7GV8KbRycs.HpC302RXsqe7RfmhLxmziJLM3WbOpZVc5.9DU18Lcib7oWBi8ICqSs3U
 LySoSojXkESmXM.XyL46HoGxLWvaasAkD2hAaK5LwyXm4k6Dg5PJgM1497iiBOS3BYCu3hDtf5GS
 qZT98tFsOEe1LVZDp_XBMBfwJwZ3VYGPde7uGK_Xb4so-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: eb36d364-e082-4610-afec-7ad2f07bf6fe
Message-ID: <7a3b86dc-2036-47ac-a696-bfb15b648b73@aol.com>
Date: Fri, 14 Aug 2026 15:13:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <1522d7a3-eb9d-40df-9a34-7b1cfeb3680e@aol.com>
Content-Language: en-US
In-Reply-To: <1522d7a3-eb9d-40df-9a34-7b1cfeb3680e@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 7902
X-purgate-ID: tlsNG-c201ff/1786734810-F66B52A1-82A47CBE/0/0
X-purgate-type: clean
X-purgate-size: 8055

On 8/14/2026 12:18 PM, Chuck Zmudzinski wrote:
> On 8/14/2026 11:23 AM, Chuck Zmudzinski wrote:
>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>> -- snip --
>>>>>
>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>> by its DM.
>>>> 
>>>> I think the host OpRegion is not currently accessible by the DM.
>>> 
>>> Can you explain to me how the region becomes accessible to the guest?
>>> That would then (hopefully) help me understand why the DM would not have
>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>> guest are also assigned to its DM.
>> 
>> Currently, in the device model (Qemu) we have:
>> 
>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>             DPCI_ADD_MAPPING);
>> 
>> That statement is in the igd_write_opregion(...) function in the
>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
> 
> I forgot to mention: In our current implementation, this statement is
> executed in the DM when hvmloader executes this statement, currently in
> hvmloader/pci:
> 
>                     pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>                                igd_opregion_pgbase << PAGE_SHIFT);
> 
> 
> 
>> 
>> If I understand our current implementation correctly, this statement
>> is what gives the guest access to the host OpRegion (3 pages as defined
>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>> in hvmloader code). I don't think this statement makes the host OpRegion
>> accessible to the device model, though, so I think, if I understand your
>> comment in an earlier about my patch resulting in what you called a "layering
>> violation" correctly, that our current implementation is also guilty of this
>> same kind of "layering violation."
>> 
>> So, how do you suggest we fix that?

Well, that is a difficult question to answer, and if no one gives an answer
then I ask, what is the harm in making the unorthodox mapping of the OpRegion
from the host to the guest temporary for the purpose of allowing hvmloader
to setup the OpRegion properly for newer devices with new and updated specs
for the OpRegion and VBT when our current implementation permanently maps
the host OpRegion into the guest in the same unorthodox way also, that is,
without following the normal PCI MMIO interfaces?

I think the fundamental problem is the fact that the Intel IGD is an
unorthodox PCI device that does not follow the normal PCI specs and
requires adherence to Intel's proprietary specs instead.

Would that be a fair description of your problem with this patch? Are
the unorthodox requirements of the Intel IGD at the root of your issue
with this patch?

I think the reason this was allowed in the Xen codebase many years ago, I think
over 10 years ago now, is simply because the Intel IGD is such an ubiquitous
device that an exception for it was allowed.

So, to summarize what I am being asked to do in this thread, I propose the
next version of this patch should:

1. Fix style problems in this version.
2. provide a public header to define two protocols for providing
   Intel IGD support via interaction between the DM and hvmloader.
   The first protocol is the legacy protocol version, and it
   is the version that our current implementation follows. The second
   version is the new proposed protocol that is able to allow
   support for an extended VBT, which is required for newer Intel
   IGD devices.

3. For now, since only hvmloader currently has access to the host
   OpRegion in both our current implementation and the proposed new
   protocol, hvmloader will drive the decision about which protocol
   version to use for setting up the guest OpRegion. First, if the
   device model lacks support for the new protocol proposed here that
   supports the extended VBT, then hvmloader has no choice but to
   implement the current legacy protocol. Even in that case, instead
   of just printing a scary or confusing message about lack of support
   for extended VBT and continuing, which is what this version of this
   patch does, we can read the OpRegion and then print an error message
   and BUG() (or just a WARN?) only in the case when extended VBT
   support is needed for this hardware but such support is not available
   in the device model. The message could say something like:

   IGD: error: This device requires extended VBT support in the device model.
   Please upgrade the device model to a version with extended VBT support
   and try again.

   If the device does not require extended VBT support, we silently continue
   and can expect the guest will operate correctly if all else is also good.

   Now for the case when the device model does support extended VBT but the
   device is a legacy device that does not need an extended VBT. In that
   case, I think it is better to, instead of implementing the current
   legacy protocol which unconditionally maps 3 host pages into the guest
   when only 2 pages are actually needed, so an extra page from the host
   of unknown content is being exposed to the guest, we implement the new
   protocol proposed here that will reserve only two pages for the OpRegion
   in the E820 map and use a copy of the two-page OpRegion in the guest instead.
   This will be a change from this v2 of this patch which just uses the three-page
   mapped region in this case.

   Then there is the fourth case when the device model supports extended VBT
   and the device needs such support.

   To understand the approach to this problem that I have implemented in this
   patch and plan to implement in future versions until a better alternative
   is proposed, please refer to these Linux kernel commits which added support
   for extended VBT for KVM/vfio guests and which explain why this patch is
   needed for the newer Intel IGD devices that need an extended VBT:

   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git bab2c1990b78 ("vfio/pci: Add support for opregion v2.1+")
   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 49ba1a2976c8 ("vfio/pci: Add OpRegion 2.0+ Extended VBT support.")

   So, in this case, we have to implement some means for exposing both the
   OpRegion and the VBT to the guest, and we may need to also modify the
   OpRegion in some cases. Specifically, the value of the rvda field in the
   OpRegion needs to be modified in at least two cases:

   A) Host OpRegion version is 2.0. In this case, rvda is the absolute address
      of the VBT and will need to have a different value in the guest than its
      value in the host.

   B) OpRegion version is 2.1 or higher. In this case, rvda is the VBT address
      relative to the OpRegion base but if our memory map does not allow us to
      maintain the same relative offset of the VBT from the OpRegion base on the
      host, rvda will need to have a different value in the guest than its value
      in the host.
     
   For now, until a better way is proposed to expose the OpRegion and VBT to the
   guest in a way that allows the guest OpRegion to be modified as described above,
   I plan to propose the same approach of temporarily mapping the host IGD OpRegion
   and VBT so that hvmloader can obtain a copy of each region and configure the
   OpRegion and VBT appropriately for the guest that I have use in this patch,
   despite Jan's objections which, as far as I can tell, also apply to our current
   implementation.

Thanks,

Chuck


From xen-devel-bounces@lists.xenproject.org Sat Aug 15 01:13:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Aug 2026 01:13:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391558.1631287 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wv2xR-0003mk-Kp; Sat, 15 Aug 2026 01:13:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391558.1631287; Sat, 15 Aug 2026 01:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wv2xR-0003mV-Fb; Sat, 15 Aug 2026 01:13:09 +0000
Received: by outflank-mailman (input) for mailman id 1391558;
 Sat, 15 Aug 2026 01:13:07 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wv2xP-0003mP-3s
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 01:13:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wv2xO-0043rO-Gw
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 03:13:06 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a7fbd1a-bab6-0a2a0a5309dd-0a2a450ac54c-2
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 03:13:06 +0200
Received: from [40.107.209.11]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a7fbd1e-f2d2-0a2a450a0019-286bd10b1fd3-4
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 03:13:04 +0200
Received: from CH5PR05CA0020.namprd05.prod.outlook.com (2603:10b6:610:1f0::13)
 by DS0PR12MB8245.namprd12.prod.outlook.com (2603:10b6:8:f2::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Sat, 15 Aug
 2026 01:12:58 +0000
Received: from CH3PEPF0000000A.namprd04.prod.outlook.com
 (2603:10b6:610:1f0:cafe::96) by CH5PR05CA0020.outlook.office365.com
 (2603:10b6:610:1f0::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.6 via Frontend Transport; Sat, 15
 Aug 2026 01:12:58 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH3PEPF0000000A.mail.protection.outlook.com (10.167.244.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Sat, 15 Aug 2026 01:12:58 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 14 Aug
 2026 20:12:58 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 14 Aug
 2026 20:12:58 -0500
Received: from [172.20.244.139] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Fri, 14 Aug 2026 20:12:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FdMlHHQdYy3OaTXVlMtl4RXnWaPP250VmbGuzjQ0JMtYWu9SggbQf+T5HCYtyHfL3PkCQTLBtdyNHAADBl+oobqUo8gkti4vP3JMk8UBTSPVg1IYcO3ZouCmys+C6SMT+D5wrdB4O5rAERj+p7DujD6hQOEngxVnhmzkEG9TKzszG9pLQf5ppgXwW67OA/PPCRfpbb0zeov9sVrSBT4zJPsqftYBQNYxA7h+SP7f2QkfaLMGejfOMmly9R6djYtvUQqx0ckbFKEydzWL7nNfjvMYMOSv2rvI9WuxnYJuYgE3WObPJxIseLjO4Yavq33VuCRVlawPJbabMFLIEQBvrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E+kegObjj3WTG9wSOOgkd8oQrCwJzZV6VEpn0ATfgCM=;
 b=VPpj5/PZXrwJiWjMQ/B1D+7IjDxQeZpdPIZk5nVVz8DVCrNKFIQxai79CpTRn/0f0B6HTFJbwqfygDyoZNFPjjldJeP2ZasFGFPva0JFNeRivJUQMTsXK+5iPLEhg2jQTeAIJDTgerhnkTaEP1YZsJMl70UqRbhRRLqLmpL9TJUKKX7p9t7X0lltBeDV6E2k/WHUG5WXi6IDBJ/N+ikmT1S+pn2aRsVpbm1ccs4FtlRLzZPsPO2XNphoCu45/0rDArkLt8CALV2vQDUV63C1QiDQjVqgzg89CaJejZthfDDglnGAgp3gFZhj3jNFShVZJzZYFlujG4i3yXHHRIC87A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.com smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=E+kegObjj3WTG9wSOOgkd8oQrCwJzZV6VEpn0ATfgCM=;
 b=xoh/RXenN6qULyc3S8NiwLGPFJprwmv/gGC5GUIvQFI8d/GcIUbSsH2RflNzNLmXC4Z0fQdMAwbRtSejRutTaxwRadvCJnIev6VQdSbB++KaAb9ShGUAgEEOi21hQqw3zSPOpx4Xf1DDYLcNIiZPW9QZgl+8b4uUuhjrvMGA/NA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <9e940641-ce6b-4e8b-b731-34e87f824d9b@amd.com>
Date: Fri, 14 Aug 2026 21:12:55 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 17/24] XSM: make Argo hooks well-formed ones
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>, Jan Beulich
	<jbeulich@suse.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <758c8410-a18e-45dc-8944-5913e5832397@suse.com>
 <4bd4e7f7-e005-45b4-a543-98597a9de707@suse.com>
 <6991badc-dcc4-44b9-a048-29eb67c46d2e@apertussolutions.com>
 <7762513c-0d3a-465a-abd9-73e3ba586556@suse.com>
 <29546ca9-1875-4c20-b42b-39c886f3d41c@amd.com>
 <684d46e1-4f10-4034-93c1-d0bbb495e5ab@apertussolutions.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <684d46e1-4f10-4034-93c1-d0bbb495e5ab@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000A:EE_|DS0PR12MB8245:EE_
X-MS-Office365-Filtering-Correlation-Id: f6c4f26e-ec79-414d-8e12-08defa6a5828
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700016|376014|23010399003|82310400026|4143699003|6133799003|10067099003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	tvKEQ/7jxg182tDQASUXUi5dj1yR3U8QZwPJz0nDdiZhpW+0IsV+o+ZKbYQWtgp7h5QyHScVNsMB7ldhBxJV9+pac5deH6e9dh7vdlJacQcRwItcjjGOqiEFcvRUI1LoYc7AOU2DcTakkmztLf41emXeqeehaiilkv1UzVyRi532WhEBzh/I2fBOVxIH2WwNKtunVQuMszWXpROxWkRdYeWN2HvZ6dOoL1QEu4YInbIwKzLh+ofAWx2HajDqXVt1QpSL1FRJNUVncv3cp1Nynk6hkp/9kLNawEBH74YBm8M55p/TItTM3UVmGw5UJKm+YCSs/GcKTZ/V+pj1bnBtPZkF53qWFrraV0zixCAWltQESTC9Ai3ZYWczx/Z+ekS0Uizuc2NzSxiQtEoGMHLcU1a9bIG6fPk/T/zPbtab5dwqa/OiQBs242sMTQmhwcPpe4dZjug0UfNb5OSr+z98jOdVsF+S1PwHf6ZgNg/OeUsmuSYmlMCgbYMkVXO6QoD4A4H2KBHIMKCpCpl4YA5JGA1MO2O6qjwTEVsFEBYTT1NEg05XpdNj6CHOhznLzQV7EzLfSUnDSHylHyc1QqlWZmxP6rWcZapgPuK3T7ujN7wXx0/uj3uBafnlOag5NiftN0+hPL5Bw/CQ1s0DM49B13T09NEbxehjIQP1x19NZaAZAS2NIveRg20NQZ2HiUr4h8eYzRKv7xB+7qtH8BTxMg==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(376014)(23010399003)(82310400026)(4143699003)(6133799003)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	JrNFdewOGFhOd+AEUTfdZxsF2EWniiahPlW63OSgS83wYxb9/EEJU0nhFe3+fzjIoA1AOP1OwnuTJfN/NrPRifN2lPwPPkqETSjBXqwCj/S3kjo+YPhpuIE3jxs0Qlxrs9pNMEGaDsLZ3dsO93dosGJRxRrSJ00Y53IekCYLbCBG386vLJ8i6BQ6pCUFwz7N90JpQ079miopClQUWUi74x53joFIjNwWBTthi+Gxf4Bt2qdzN2ClsTeqG6s+niyPVtctkG6BX746wgJgx0nxCeO2HDeVQ0TZ0ntchv8dtZhCiVvEgQs4xlhBJ/fUUUIpc3loea88Mwe16nbeduPZnO7+YMx1AueMdAe3S8+/2/ILcE8rbGG2gdw3jjoDoJa4Yn/ZWFfEMITqDT8ArqOnsvKHndZOGHC/89ERoPfX9GK5zwyBiZrrKlTqHPtfjlHN
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2026 01:12:58.5169
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f6c4f26e-ec79-414d-8e12-08defa6a5828
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8245
X-purgate-ID: tlsNG-4011c0/1786756384-599C1CFC-0CA981B8/0/0
X-purgate-type: clean
X-purgate-size: 3031

On 2026-08-13 08:09, Daniel P. Smith wrote:
> On 8/6/26 10:09 AM, Jason Andryuk wrote:
>> On 2026-08-06 03:16, Jan Beulich wrote:
>>> On 06.08.2026 01:02, Daniel P. Smith wrote:
>>>> On 7/28/26 9:22 AM, Jan Beulich wrote:
>>>>> @@ -2307,7 +2308,7 @@ argo_init(struct domain *d)
>>>>>    {
>>>>>        struct argo_domain *argo;
>>>>> -    if ( !opt_argo || xsm_argo_enable(d) )
>>>>> +    if ( !opt_argo || xsm_argo_enable(XSM_HOOK, d) )
>>>>
>>>> This question came up on another thread, so thought I might point it 
>>>> out
>>>> that when FLASK is in use this can return a nubmer of error codes 
>>>> beyond
>>>> an access deny. While I know it's the existing behavior, but if the
>>>> error code is anything other than -EPERM, then it's not that the policy
>>>> denied the access but something cause a fault in the security 
>>>> server. In
>>>> that case the domain is still being allowed to construct with the
>>>> assumption that it was a policy deny. At a minimum should the error 
>>>> code
>>>> at least get reported, and perhaps it should be passed up to domain
>>>> construction to allowing it to make an informed decision on 
>>>> construction?
>>>
>>> Sounds plausible, but definitely wants doing in a separate patch.
>>
>> I think this is a mis-use of xsm_argo_enable().  As I wrote in [1], 
>> this isn't an access decision, but an ~optimization to skip 
>> initializing argo data structures when a domain is not allowed to use 
>> argo.
>>
> 
> I would have to respectfully disagree. The operation is to initialize 
> the domain for argo usage and the access check says do not allow 
> initialization if the domain does not have the privilege. This basic 
> defense in depth, do not initialize for some thing you should not have 
> access to, and thus not just relying on the later checks.

I was thinking of it as robustness.  If you always initialize argo, then 
you don't have to check ->argo for NULL for each domain.  Though, if you 
want to selectively allow argo for individual domains, you have to check 
something anyway.

>> With Flask, this prints an AVC denial during domain construction when 
>> the domain doesn't have argo enabled.  That is misleading as it isn't 
>> the domain's action causing the access.  In OpenXT, I wrote a patch to 
>> add a noaudit variant to hide the denial.  I didn't upstream it 
>> because I didn't really like it.
>>
> 
> The customer has ran OpenXT through the code evaluation models that they 
> have access to and your patch was flagged. Not for being technically 
> incorrect, but raised policy questions on whether is was desirable to 
> silence the event.
Again, xsm_argo_enable(d) is used for two purposes:
  - Access to the argo_op hypercall: current == d
  - This argo_init(d) call: current != d

Domain create always goes through argo_init().  current triggers the 
denial, but it is logged against d.  This is misleading as d did not 
perform any operation.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Sat Aug 15 02:23:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Aug 2026 02:23:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391588.1631295 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wv42m-0004iE-Qn; Sat, 15 Aug 2026 02:22:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391588.1631295; Sat, 15 Aug 2026 02: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wv42m-0004i7-O4; Sat, 15 Aug 2026 02:22:44 +0000
Received: by outflank-mailman (input) for mailman id 1391588;
 Sat, 15 Aug 2026 02:22:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wv42l-0004i1-Tg
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 02:22:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wv42k-00B37O-IG
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 04:22:42 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7fcd72-bab6-0a2a0a5309dd-0a2a4501a464-0
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 04:22:42 +0200
Received: from [98.137.69.84] (helo=sonic314-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a7fcd70-5984-0a2a45010019-62894554a320-3
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 04:22:41 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Aug 2026 02:22:39 +0000
Received: by hermes--production-ne1-6dbcb84f44-46ggn (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID a5e795f747df51b797a85135c10a6553; 
 Sat, 15 Aug 2026 02:22:37 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786760559; bh=CLpGYCy7VH9tbCFcx31pYD25f1NCaJP0agxFleGx21w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=hPUs3/T220imsYRwTnTs3SNyEy29C9a4YXSDp9BxfEPmPg+p7ZDlFYDDU5GIw0scjBep0WbNhImUJtMZ+s3Dv26ep12nvailMqPCBgGkFcSZiKfIVnJBlJ/E36WJ5juxiLKNCGry93lZgp6+4lT6AK4yDJCXm/E09P5mgJ1fbYHeK0oAG0UwGrVgybsIS1+FTHJR1gv/uiHwner6avhLdseF8dmltuPMEAMCB5eUxHPal4PWOHmzHmmCIWJCLoCABocKvV4jYPsI2CJ4wY6UDscuOn6OESlTJ524u/yN0PD+/eQZ8eVpPI54wVIp0KfKW6jNd5BzxrIFoNBhjzTkBw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786760559; bh=h96SNf96bcHIDxH1RsNcztY/Vg4ZK3Hcpqd89dIfhgn=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=Z/ekAq26F0eH12LalJNV6fgSf6IZuMcQdqQlW80dVKdvrFnvHUE8EY3gjHT+Vb+TPlFTSbTum65uSvC3/rC9IE1/K8WCw/H/pcpalInUfnXNNu4u5Rxd4HImJYK02QI0awN+SEldJIUGZZb2qbAJe83/tLO4+lZCHeS9O+FW5vqSixlT2FJO2rodfqsL9GDgM1fmvpgHHdmPJkHRyE3e+VYhz0sHvQSOHF3jQDWWqAohT5fqIze3cjfF1txatfHeATGz8JEV6Lv18pAUp9NmL9H2uzvyRkwkk9tgfCIajCDHANTs+Oh3LWzdtA8Q9zkrUyFgR5VVcFrW3Rr+mgxRNw==
X-YMail-OSG: kyDeJDUVM1m5N.EDhqlg8Zjz2pz7Gg81Re3vcuDClo5eDZlDUL07aTzgrL6TDjb
 7BXAYOovtrgs.0ocyyCeJdnKGgU9bSoMhehaaOhosrdrWFdoTkkoR.B7paQWHooB3FkbivnRhpPE
 5fG6AbfwtDkvKjuh67gUiWkf5ZoTPFIkzJ5Pb2f_XNiCsHmzOI.o0lx39oAHM_FrDvLwDcWvsdcd
 rNZjXrIsTrspMZih5rKjojkqlFr7vgjxSCkCRK1XssYYObb1VfFRU6G9fTw6GAqmMT.E_NgWVGi5
 B6tAiHoQWY0hf3eUXJ9wKIK2I.rImQvMTW3Ihd0D8e97Hv.lE67JfHpVihaZLXIl9kb1OL6gjuk.
 _A7S5y18dpflgPaxtOJRLvTEsLyHjHpKM7OI7hWQMG96e4DlC0EBQ__nM91LVqnBeGGSh5nlD8qH
 lbdoPbEpzDvXU2K.lTm.hTPmpco055hX3IIAdy1MvvS6V_hOoeNUasksD3naR1g0q2zr6mbVFaMf
 LwmQ.EYSZA4kJu2c9cBvLVQFKO8LdchHXd_C4xkkLbFvMTaDpIWJBjcguYiNl4gN02YcpY2Jdk6s
 _9zm5rhA2pLjfDOT8nvPzO.pwQ2Vo5wE5TFVNxEZ6B4XvnQfOrMAB04G2AVXVIjHCip8hamX9Pu9
 87dyxQuwGvWsbtvfAdYQb3JRkCC029FioteDecD7ULfNKAlySg_jY.YIHVCOIKGxVsejthF3myfm
 Wiy7YWCLr5NIHIstZ_zCmhRH7TX4f_s6f_tzpxBvA0CQRKY1DmCwc5fJQjO1NXFRBop71N6v0d6p
 0k0Hq79oKpbpe3ealU0NDFqMfXkQ4cY3UpW_.AOG7CJnwcX0rd3TpodPRusQvxxD4XeD_wMACDg3
 iNsz5j_HUTQdHisAqzXOzvDQhtIDRFHjPjxzFIqd.hv9sagBngHocWGlNm9SKNlOYjeX6lqQH53d
 u9G_s7hjvGQxo0akid4OaM99jVyHYNW6AgHfNvKp.R_m94Ih0tKX52CVLTdVGwV7kLpr7jSjEChr
 97hky5csWo02Iw_1G37GPGQLhgEiP8TBC4jjJO5E9GY3XhCXE0EmjjixwQNkdKocO_Kq6OhDj76N
 bfAkiOhrXz2iOEKQFZQtxvzfjqh_oSSaaN24AsQIm3mStUMkEhDLvZAAw2PfuaE3vMUbYg4Jvkh.
 t9b9nt6WJBkMg..9sp46NaHdt5jv.d2Rh4K70Spfrf69l7UXkYoMtEdhYmHGZqhL3C88BGEgbiWW
 EewFUzEeFORs28jAvJMOnZYGR_pTbCKJ5CnTeYDqBe0Q289i5PdhjlzquJYq4BNr9tRTi6FY4z4j
 9jY.F09gk5XhIVz7_.5vo_4K_JKgUEazmccSJEQyya1Og3GFYxJ2SkooqHKE55HtDm4wFuzNaE4K
 IbN4QVfluL8i2O6bEis9ZKlQpl0DwsHE0j5DOTTMA.GkbdQZG29RomROpWFUy74vspQTHpnMZZ9U
 1WJHGTAfvWqr4189j_kfxKAAhu0_VY2.znku1_PMfAhAs4ar19xlevsh5q.ib4KFOrsxUsho73Pk
 GnC9hpL0q.zwnb5XaK7vGHkgHadcVZcMxFm19ebgqlDZN_Y49JoA4eHsV2CzFOXufxFXuoXhR_AR
 JD7WyWPZhYtxo0GChvYLcJ0N2VrUpf1f6OQ7CMRO_SrssvlEiYxK1eHAqg0j.CVxnHmwc7xaFpO7
 ASdeYABxe7a64lUjvqnFZSc4iNlu90OJ5affqIMa8XQbUaDw2o3CrUGYgf14XZIRrWlWBykaQpkH
 EXOMCNf6JnWMPcu7oLZaGo126YLQQOBds1KnHvOOCUOtESPXjCdMz8DTSxjh0zhvuMJt_SXlw5hv
 Fa531zAA7yah7xL5M6Ryq6rXpYESIrlwTe74EGxJrCySHQmMcpuPiDILR2P.2.Hgs0GEb_75rkjW
 uY2.NOmNYWZLlgIqpwAENfL_31t9u5sha6GNJyiaBw1JE6ycBUdyXFNfVjgfhs4cLCiVRbFKXAI7
 aLDJfMqkiqVa2i5H.ls9Yjr7o0y46fBRzyUw6QQEnJS8OP_dZ5ptOeJ_DFIktEZhcTOdifqumfWA
 _ZlZp9xHZOfbJCciSLTvSjd5bRCgeJjDNqIMtSayKBa3xwitzCBZQMEWA5n_OMLcWo3i0ueG8NHD
 w9iFuRAlI52pD5NsqHzCj9.cH4tPYJqg3E0.91ZSrWVWdhzhEA4VsrlTTwcsgx1s_bc3UrZivG67
 v6p8_QwFdkboyfP3hBxvpQI3oT8O3.hPJKGaYuKE2.94kZDY-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: a9182707-1c7c-4e68-8f12-489dc0538d02
Message-ID: <9cf5c34b-65a9-4e19-8dfb-9f1264988d5b@aol.com>
Date: Fri, 14 Aug 2026 22:22:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 12878
X-purgate-ID: tlsNG-d62444/1786760562-BDE78757-F1CCB040/0/0
X-purgate-type: clean
X-purgate-size: 13159

On 8/14/2026 9:46 AM, Jan Beulich wrote:
> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>> -- snip --
>>>>>> To address this problem, this patch implements support for
>>>>>> Intel IGD devices with an extended VBT and OpRegion version 2
>>>>>> and higher which is required for most modern Intel IGD devices.
>>>>>
>>>>> First of all: Where's the spec of all of this?
>>>>
>>>> Well, your first question is quite provocative. Certainly more
>>>> social/legal than technical.
>>>
>>> Well, it was very much meant to be technical. I've had a hard time following
>>> what your new code does, and having a spec to hand would likely have helped.
>> 
>> I agree that having the spec at hand would be better. To be more precise, I
>> can say that what this patch essentially does is port the support for
>> the extended VBT with OpRegion 2+ for the Intel IGD passthrough that exists
>> in KVM/vfio to Xen. Should I explicitly say in the title of the commit
>> message that this is a port of KVM/vfio support for extended VBT to Xen?
> 
> Not in the title, as that would likely make it too long, but perhaps in the
> description.
> 
>>>> So my answer is as follows:
>>>>
>>>> I do not have access to the official spec that defines "all this" but
>>>> I do have access, as does the general public, to the Linux kernel's
>>>> implementation of support for the Intel IGD from many sources such as
>>>> git.kernel.org. The Linux kernel has enough accurate information about
>>>> the spec of "all this" to provide very good support for the Intel IGD
>>>> on bare metal.
>>>>
>>>> To elaborate a bit more, the spec of "all this" can be derived from the
>>>> Linux kernel code that supports the Intel IGD.
>>>
>>> So you expect every reader to locate and decipher the underlying information
>>> from a (afaik) pretty large piece of code in the Linux kernel? If the Linux
>>> kernel sources are the reference, please can you at least provide pointers
>>> into there?
>> 
>> No, I do not expect every reader to decipher the underlying information...
>> 
>> That is why I provided these two links at the bottom of the commit message.
>> Perhaps you did not notice them:
>> 
>> Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
>> Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
>> 
>> They are the patches to the vfio kernel driver that added support for the
>> extended VBT for KVM/vfio guests.
> 
> Patches can still be in flight, so provide only limited help. Would it be a
> problem to instead reference commits, or the actual localtion in Linux
> sources?
> 
>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>> +               (igd_opregion_pgbase << PAGE_SHIFT) |
>>>>>> +                IGD_OPREGION2_SUPPORT_MASK);
>>>>>
>>>>> This looks to imply qemu is the only possible device model.
>>>>
>>>> Yeah, this is an issue. Other device models that intend to support
>>>> the Intel IGD with hvmloader will also have to be compatible with this.
>>>> It would be easier if we did not have to worry about backward
>>>> compatibility and supporting what we had in the codebase for many years
>>>> in both hvmloader and Qemu and we would not need IGD_OPREGION2_SUPPORT_MASK
>>>> in that case. Instead, we would just completely deprecate all previous
>>>> implementations of the Intel IGD passthrough feature in both hvmloader and
>>>> the Qemu DM as unsupported. So my previous comments about backward
>>>> compatibility apply here again.
>>>
>>> As said, I don't think backward compatibility can be dropped. My comment
>>> also didn't really mean to hint in that direction. Instead I was wondering
>>> in how far, even if perhaps by only a few #define-s, the necessary
>>> interfacing couldn't be put down in a public header, for any DM to consume.
>> 
>> Ok. Perhaps the IGD_* defines could be moved to a public header to define the
>> interface to be used to support the Intel IGD. Would it be OK to move those
>> to a separate igd.h header
> 
> This may require input by others, as in the given situation I'm not quite
> sure what is best. Anthony - do you possibly have any suggestion here?
> 
>> and include it in hvmloader/config.h?
> 
> I don't see why that would be needed. The few files which need the #define-s
> can include that new public header, without impacting anything else.
> 
>>>>>> +    printf("guest OpRegion tentative "
>>>>>> +           "address: 0x%x\n", igd_guest_opregion);
>>>>>> +
>>>>>> +    if ( !verify_opregion(igd_guest_opregion) ) {
>>>>>> +        printf("error: IGD OpRegion signature "
>>>>>> +               "not found.\n");
>>>>>
>>>>> No full stop in messages please.
>>>>
>>>> Would it be OK to just get rid of the error message here?
>>>
>>> That would then leave ...
>>>
>>>>>> +        BUG();
>>>
>>> ... an un-annotated BUG(), which generally isn't very nice.
>> 
>> I don't think I understand what you mean by "No full stop in messages..."
> 
> That's the period at the end of a sentence (when in log messages the term
> "sentence" is of questionable nature).
> 
>> We have code like this in hvmloader/e820.c:
>> 
>>     if ( rc || !nr_entries )
>>     {
>>         printf("Get guest memory maps[%d] failed. (%d)\n", nr_entries, rc);
>>         BUG();
>>     }
> 
> Well, you'll almost always be able to find bad pre-existing examples.
> 
>>>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>>>> +
>>>>>> +    if ( !rvds || !rvda_host ) {
>>>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>>>> +        rvda_host = 0;
>>>>>> +    }
>>>>>> +    /*
>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>> +     * to communicate location of the VBT to the device
>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>> +     * after we also write the guest address where the
>>>>>> +     * VBT will be mapped.
>>>>>> +     *
>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>> +     * it will not unmap the OpRegion.
>>>>>> +     */
>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>
>>>>> Why would you need to communicate a host property to the DM?
>>>>
>>>> The DM cannot access the host rvda value because it is only accessible
>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>
>>> I don't follow this: Anything the guest can access should also be accessible
>>> by its DM.
>> 
>> I think the host OpRegion is not currently accessible by the DM.
> 
> Can you explain to me how the region becomes accessible to the guest?
> That would then (hopefully) help me understand why the DM would not have
> access. Fundamentally any MMIO and any I/O ports that are assigned to a
> guest are also assigned to its DM.

This is what I don't understand about your objection to how both the current
implementation and my proposed changes makes the host OpRegion accessible to
the guest. What do you mean when you say any MMIO and I/O ports assigned to
a guest are also assigned to its DM? What does it mean to assign an MMIO
region to a DM? Is it the DM you mean or the DM domain, which need not be
dom0 if we are running the device model in an unprivileged domain. I also
am presuming you know that dom0 for Intel IGD passthrough is a PV dom0,
not a PVH dom0. I have never tried Intel IGD passthrough with a PVH dom0,
because as far as I can tell vt-d is not supported with PVH dom0.

Take a look at this code from our current implementation in qemu-xen. This
is from the current master branch of qemu-xen on xenbits.xen.org, the
hw/xen/xen_pt_graphics.c file, the igd_write_opregion function:

--- snip ---

#define XEN_PCI_INTEL_OPREGION_PAGES 0x3
#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
{
    int ret;

    if (igd_guest_opregion) {
        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
                   val);
        return;
    }

    /* We just work with LE. */
    xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
            (uint8_t *)&igd_host_opregion, 4);
    igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
                            | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK);

    ret = xc_domain_iomem_permission(xen_xc, xen_domid,
            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
            XEN_PCI_INTEL_OPREGION_PAGES,
            XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);

    if (ret) {
        XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
                    " 0x%lx.\n", ret,
                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)),
        igd_guest_opregion = 0;
        return;
    }

    ret = xc_domain_memory_mapping(xen_xc, xen_domid,
            (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
            XEN_PCI_INTEL_OPREGION_PAGES,
            DPCI_ADD_MAPPING);

    if (ret) {
        XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
                    " guest opregion:0x%lx.\n", ret,
                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
        igd_guest_opregion = 0;
        return;
    }

    XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
}

--- snip ---

This function is called when the guest (i.e. hvmloader, seabios/ovmf, or
guest kernel code) tries to access (write to) what is known as the ASLS
register in the PCI config space of the Intel IGD. The config space is
256 bytes long, and the ASLS register is the last four bytes of that space
according to the proprietary spec from Intel for the OpRegion. So the address
for the ASLS register in the config space is 0xfc, and the four bytes stored
there is supposed to be the address of the OpRegion according to Intel's spec.
That is fundamentally what we are trying to do here - program that ASLS register
so it points to the location, in the guest, of the OpRegion. If you examine
the code above, you will notice the call to xen_host_pci_get_block(), with
XEN_PCI_INTEL_OPREGION as one of the parameters. Did you look up its value?
It is 0xfc, the value for the ASLS register in the Intel spec. How does the
DM, qemu-xen, get the value stored there? Well, the xen_host_pci_get_block()
function accesses the PCI config space from the device model not directly as
kernel code or platform firmware code such as hvmloader or OVMF/Seabios could,
but only indirectly, through the 256-byte config file that is exposed by the
Linux kernel sysfs interface at /sys/bus/pci/devices/0000:00:02.0/config in
the Linux host filesystem. If you don't believe me, take a look at the code
in hw/xen/xen-host-pci-device.c where the xen_host_pci_get_block() function is
implemented in qemu-xen.

So the device model can, indirectly, access the PCI device's config space
because the Linux kernel exposes it via the sysfs interface. The point is,
the DM's access to these resources of the passed through PCI device has
nothing to do with MMIO or I/O port mappings, but is entirely dependent on
the host dom0 kernel for access. But sysfs does not provide access to the
OpRegion, that is, the actual two pages that comprise the OpRegion whose
base address is the value stored in the ASLS register. That is fundamentally
why the DM does not have access to the OpRegion.

Do you understand now?

Chuck

> 
>> On the KVM
>> platform, this is made possible via the kernel vfio driver and then Qemu exposes
>> the OpRegion to the guest using the Qemu FwCfg device interface. How should we make
>> the OpRegion and VBT accessible to the device model and then, to the guest, on Xen?
>> I think it could be done via the xen-pciback kernel driver. Should we do that
>> instead? I think to do that we would have to convince the kernel developers that
>> the Intel OpRegion, as you say, "should" be accessible by the Xen device model.
>> I can imagine them saying, why not use the vfio driver?
> 
> I can't answer this; all I can say is that it feels wrong to involve e.g.
> xen-pciback here.
> 
> Jan



From xen-devel-bounces@lists.xenproject.org Sat Aug 15 07:03:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Aug 2026 07:03:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391641.1631304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wv8QE-0006lo-Hz; Sat, 15 Aug 2026 07:03:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391641.1631304; Sat, 15 Aug 2026 07:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wv8QE-0006lh-Eq; Sat, 15 Aug 2026 07:03:14 +0000
Received: by outflank-mailman (input) for mailman id 1391641;
 Sat, 15 Aug 2026 07:03:12 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+eb7931f7a775907bc3a1+8392+infradead.org+dwmw2@desiato.srs.infradead.org>)
 id 1wv8QA-0006lb-7J
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 07:03:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wv8Q8-00BTdy-SL; Sat, 15 Aug 2026 09:03:08 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+eb7931f7a775907bc3a1+8392+infradead.org+dwmw2@desiato.srs.infradead.org>)
 id 6a800f22-bab6-0a2a0a5309dd-0a2a45098f72-12
 for <multiple-recipients>; Sat, 15 Aug 2026 09:03:08 +0200
Received: from [90.155.92.199] (helo=desiato.infradead.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+eb7931f7a775907bc3a1+8392+infradead.org+dwmw2@desiato.srs.infradead.org>)
 id 6a800f2b-be1a-0a2a45090019-5a9b5cc7802c-3
 for <multiple-recipients>; Sat, 15 Aug 2026 09:03:07 +0200
Received: from [2001:8b0:10b:5:7c22:1ec7:eff1:386] (helo=ehlo.thunderbird.net)
 by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat
 Linux)) id 1wv8Pq-0000000HLvs-34jQ; Sat, 15 Aug 2026 07:02:51 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=desiato.20200630 header.d=infradead.org header.i="@infradead.org" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:References:In-Reply-To:Subject:CC:To:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type
	:MIME-Version:Message-ID:References:In-Reply-To:Subject:CC:To:From:Date:
	Sender:Reply-To:Content-ID:Content-Description;
	bh=vFwW/KzeZkxEAcxvRpsV5UXDgsa9npf+qs5mLhHNQNY=; b=TsD1aUT9ojH/4Tct9skCWNvTNK
	44l/zqLlBlmWFlgdrwDQL+FMgjnMoP0yx3NOB7d9rJBr53GW31p08+qK+W2brToWlxephG84Sc8M5
	H6FypLYnkl7SD9j8MaG/fk02wZd8XFEHuVGH1LWuVpp7W0mFejD8hMadvmTujPJJcWI4j7zUWt3+S
	XXWdfZOILX8K2+HYBXOhHPRton/Ccb6kh4LYCx5btBO/6krUhpL7kG/PAjChXLP6/O3NylmzF/A6p
	IQSlksnb0p5VogSmZYY9d6HdgEb/LBK8cSzoJnOUmOjf1nmcxPz0T652yJzGp7G1US43ALjYn90F5
	h58OfAcw==;
Date: Sat, 15 Aug 2026 08:02:50 +0100
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
CC: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
 Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
 "H. Peter Anvin" <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>,
 Juergen Gross <jgross@suse.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul Durrant <paul@xen.org>,
 Jonathan Cameron <jic23@kernel.org>,
 Sascha Bischoff <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>,
 Joey Gouly <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>,
 Dongli Zhang <dongli.zhang@oracle.com>, joe.jin@oracle.com,
 kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v7_17/36=5D_KVM=3A_x86=3A_Allow_KVM_master?=
 =?US-ASCII?Q?_clock_mode_when_TSCs_are_offset_from_each_other?=
User-Agent: K-9 Mail for Android
In-Reply-To: <an9WVBHSsy5W0PUk@google.com>
References: <antQYJvRxJxOjtut@google.com> <f5dc701cf3319a7b3c8fd1497f26d051aa9fa3ba.camel@infradead.org> <antb01WqOrs-tztm@google.com> <6ab49538675d97f1f4bf01574b1b066aae0bc05c.camel@infradead.org> <ants4VjfAiblaWsl@google.com> <3dc73f745b6abfd1eb53e7d3fce2067eaa3b3c92.camel@infradead.org> <anuYNxD81OE3MrQw@google.com> <5efe7a3914a3610ee00a487379caff84af6aa731.camel@infradead.org> <anusv0DloFhLMMoW@google.com> <c5c532e01309c8c73de2b0f393539b608c495f1f.camel@infradead.org> <an9WVBHSsy5W0PUk@google.com>
Message-ID: <606ECD8E-2EED-48B9-A440-62D2444FBE22@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-bad1c0/1786777388-BE6DA034-CF6530A3/0/0
X-purgate-type: clean
X-purgate-size: 1160

On 14 August 2026 18:54:28 BST, Sean Christopherson <seanjc@google=2Ecom> w=
rote:
>On Fri, Aug 14, 2026, David Woodhouse wrote:
>> On Tue, 2026-08-11 at 16:14 -0700, Sean Christopherson wrote
>> > I'm not totally opposed to a broader GET, but we should definitely ge=
t Paolo's
>> > eyes on this sooner than later=2E
>>=20
>> We've been saying that for two years=2E Shall I bring a net and a whip =
to
>> KVM Forum? Or Plumbers? :)
>
>I pointed at this thread in the "clocks" pull request, so then should be =
now,
>soon=2E  And if that doesn't work, I'll just rename the getter to
>KVM_GET_PAOLO_PAOLO_PAOLO and send a pull request=2E  Either that will ge=
t his
>attention, or we'll have a source of amusement for years to come :-)
>
>Joking aside, this would be a good PUCK topic if we need/want a synchrono=
us
>session to sort things out=2E
>
>[*] https://lore=2Ekernel=2Eorg/all/20260812213206=2E1564354-2-seanjc@goo=
gle=2Ecom

I prefer https://lore=2Ekernel=2Eorg/all/69b0cc5aa1032d708700bd2367b43d623=
8fc4079=2Ecamel@infradead=2Eorg/ as the summary over the one you picked, bu=
t happy to reach a solution either way :)


From xen-devel-bounces@lists.xenproject.org Sat Aug 15 13:53:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Aug 2026 13:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1391828.1631313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvEp7-0006Tp-Ay; Sat, 15 Aug 2026 13:53:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1391828.1631313; Sat, 15 Aug 2026 13:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvEp7-0006Th-75; Sat, 15 Aug 2026 13:53:21 +0000
Received: by outflank-mailman (input) for mailman id 1391828;
 Sat, 15 Aug 2026 13:53:20 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <philmd@oss.qualcomm.com>) id 1wvEp5-0006Ta-VO
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 13:53:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvEp5-00C8ZG-CK
 for xen-devel@lists.xenproject.org; Sat, 15 Aug 2026 15:53:19 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a806f22-2eae-0a2a0a5409dd-0a2a45098056-24
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 15:53:19 +0200
Received: from [205.220.168.131] (helo=mx0a-0031df01.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a806f4d-be1a-0a2a45090019-cddca8837854-3
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 15:53:18 +0200
Received: from pps.filterd (m0279866.ppops.net [127.0.0.1])
 by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67FDMGoG219108
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 13:53:16 GMT
Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com
 [209.85.222.198])
 by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g2hd7rxtw-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 13:53:16 +0000 (GMT)
Received: by mail-qk1-f198.google.com with SMTP id
 af79cd13be357-936d067836eso196910285a.0
 for <xen-devel@lists.xenproject.org>; Sat, 15 Aug 2026 06:53:16 -0700 (PDT)
Received: from [192.168.69.229] (pmd666.hd.free.fr. [88.187.86.199])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499899b5f86sm115714325e9.5.2026.08.15.06.53.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 15 Aug 2026 06:53:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:Cc:To:Content-Language:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=
	cc:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=
	2QVIRMmy6CwNjWFI8w4TaBxFhy+gC22lWK+qfX3lm84=; b=bIMiGvozReWfRNFq
	uChwj2wozeU5DMnQHusId0X2qHQ6FtcA2S21wm1WDQ8ZrCW2YoOzTVhyWltG3OQi
	DGy6Px21Sa0C1tpbf+Kgf2tI+8wdshEn1oc/NLhcHPguLHoCHrqNfpwVUr3wOI/c
	aVgjjh+hp/lM7zWD/WziDmoIgj2RyrSd7WbzwzRCeaGasODOWu9krbtvK3gOvSw3
	5CBhh9HYjWYwqXup2PnAcCpq878RIBr699gJSpYHsz0Ku0aHlnXASPuy9rOItn3W
	r15akix/H6wpt+cfE7V1qBukBpGvhevD0G8H3S1viD4NtmX9DdVP2823BN4YkR++
	4CHCCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=oss.qualcomm.com; s=google; t=1786801995; x=1787406795; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=2QVIRMmy6CwNjWFI8w4TaBxFhy+gC22lWK+qfX3lm84=;
        b=iN6/sxO78q8in+HP+DUgsZZcjpIgzdsmm7gGdeNDjZ/Sy4iZousWjPhxuaUOljyTKn
         LNX88FLBPqn8HB5NNHWLtxpm2HsKBpbCMpFbg/ehqkdXVdmS3EVyi7vWfe25RUwrKNSA
         3NdgJ7cod/LWXuTVyLTFNA08xh5LNeGxrGzcog8OOOXGyCXafdCvZKYXee97AtU9cKfe
         SE/0Ymq/Eb188r4AvEXCd7fmo++xvS2zH1HobVECX3b7C3Awqwpf9iRUOxDsNKKyUPBs
         sCa6nTz+cYtKa1q2lCoPs+CJtQbO1Ty4IyrJgc9pAvuxLzBqDyVud6UR4MPLdtSSzXfb
         IRag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786801995; x=1787406795;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=2QVIRMmy6CwNjWFI8w4TaBxFhy+gC22lWK+qfX3lm84=;
        b=S98GDOp9wWPPEGbNDctkO4FDlJQtDT49GCFdStCSy4ScdhKKvYLZcOi7+kh7iAj2CN
         J3NZRbTjciJXCduhUYdvZvtx3IJyqIHbdvWSDdFZ/5EEqmN4dQ8ew5btwV28wPBxtres
         llTzAvDJ98QWmzr0Nt3SwUczflNaeM6zskf8AcS0IH4rt/e1P3gOpGRcUM0e08KbtSvc
         2TN5SwIW9BP/obxyeT6SY3zahIrYJAaNIsl4jVkNB9QzSmM8/rmNgZYXPEHlsFVW4oQF
         0Ubh7vN6+Ifp4TYYRVElrYB1RzqiKh46o89ZOMjFMPVfDAjXHm4c8f5lWii3YeXvd42K
         vnsA==
X-Forwarded-Encrypted: i=1; AHgh+RpLo1cYEFzBG2+2KSm5AWWCu/Jpektb94yOS4mZdIU5EiPqgAmf8i/WP59fR/yTrFJ4W0w1q+gNU5I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyAtQnhV3sRCcvTGWPGZy3Q4+T/+1XHv/qEbF6NKCYwghMprRjx
	NnZRtDXiHcpE7gyr/b9EQQ+gxJ+a7G5XnTVnXz5D2wp90V1EPy4qd/SLVEok28KtKknjxJwUbr6
	e4MCYDHGqkKRUOmVht5ohqo9JNjfqOBn6KNv8pVsFrDcvXCb77w7tRrflMf8TxGiECLVR6A==
X-Gm-Gg: AR+sD1017rNiujzdUSviQqcqzQWJixpPUx0l4khIVzmlpbqNUMow0pT8J475tDXHdQN
	v+E0WUsflG9IsfyQnaWiS/kyKgFWFwQwhjzSePPHKvV+58nES93I/0ffgU40RXnmIhCiaXnTrat
	4l6YvNW3l9S/p9sjIdibZwtaxCDveyIEqXqi3nZXAOKT/i8gg9jTrLQE8EZdcVsF0h0BFpcLbO4
	PYYyz6W5paqWVkpWzlg95ZW+mto5Gw8TEhuQUnPs+GdkHUUrAAPNNwVbzXvIf9T4gItkY/bHPYN
	DgR40LPWJt8XCEAV1utXs24KibGOfGD64mctVZGC5BStqSFF0LsJUJ2skycv4RrTkK6fTS9sF+J
	xigAvWa2enoYQ1IO7JRnQQCBbsbbMijoCYMI=
X-Received: by 2002:a05:620a:3d01:b0:915:a111:86ae with SMTP id af79cd13be357-936d238c318mr914137185a.35.1786801995565;
        Sat, 15 Aug 2026 06:53:15 -0700 (PDT)
X-Received: by 2002:a05:620a:3d01:b0:915:a111:86ae with SMTP id af79cd13be357-936d238c318mr914135185a.35.1786801995124;
        Sat, 15 Aug 2026 06:53:15 -0700 (PDT)
Message-ID: <fa0c9b5c-81c5-4289-92b4-2d77329cbde4@oss.qualcomm.com>
Date: Sat, 15 Aug 2026 15:53:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] hw/i386/pc: xen: reinstate the "xenfv" machine alias
Content-Language: en-US
To: Dario Faggioli <dfaggioli@suse.com>, qemu-devel@nongnu.org
Cc: philmd@linaro.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org,
        anthony@xenproject.org, paul@xen.org,
        Paolo Bonzini <pbonzini@redhat.com>,
        Richard Henderson <richard.henderson@linaro.org>,
        "Michael S. Tsirkin" <mst@redhat.com>
References: <20260730162238.3308286-1-dfaggioli@suse.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>
In-Reply-To: <20260730162238.3308286-1-dfaggioli@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE1MDEwMCBTYWx0ZWRfXxIunQVPBwaqE
 RYlf2ZhjsNQIkich1pd4GByVR6DbhSA6mwjxf7kxUHuUErmXqIaWIsIl+PAEUoLAxW9t/SMh0dy
 bKdIQPmXjSR02JRtAipy+LVb/cDq75NbqpsBIbWgUd7szpKMUjagDsM4AwmLXvx7IKG/r/wEUNq
 X0cahRAzr6fWQxq1X44J5Oy2mXopfTLzucnvoX2X2617DBY/J8inNbZkqC5D6uycbmAWxRJynBk
 N0T1KzTaVkl3UEFMws9lo7a3KBEyptIV9nDTjCahLur1+NhdB+/YpaIV8EduqlZKuR0WarK6Ay/
 R8EIwefd/AAiuxwzqF6+WkWyht4GAvONmcKX7JvxxD6Hb9txaqeONSoIU9SbtYa3elDcgNAyKcG
 MlLsbMn+DFB6OMRZf1EsUX1VpjnXRgGJdpiyXDdqiap+5hJbr8gaUfrhRDGjnPq2RI0vU/0KBZY
 DkzoSEgn3G6+zyZh22w==
X-Proofpoint-GUID: VADGCNYQOU3lPmmVvKdQS-BorU6mZdfQ
X-Authority-Analysis: v=2.4 cv=Ja2Ma0KV c=1 sm=1 tr=0 ts=6a806f4c cx=c_pps
 a=qKBjSQ1v91RyAK45QCPf5w==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=YMgV9FUhrdKAYTUUvYB2:22
 a=iox4zFpeAAAA:8 a=EUspDBNiAAAA:8 a=KGrwjuuvIC_z2q61s9oA:9 a=3ZKOabzyN94A:10
 a=QEXdDO2ut3YA:10 a=NFOGd7dJGGMPyQGDc5-O:22 a=WzC6qhA0u3u7Ye7llzcV:22
X-Proofpoint-ORIG-GUID: VADGCNYQOU3lPmmVvKdQS-BorU6mZdfQ
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE1MDEwMCBTYWx0ZWRfX2XEps0kSeQSZ
 3++s4B/lQ7ms8A7Haa8iMvUiXUM6f5SjSylXFFZcoSiZT5ZJpYmZYUJeuNszymqm/dK3epU9UDe
 OrRKvtyBTZ7BRTvdzta3H2NAWywjIGM=
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-15_04,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 priorityscore=1501 malwarescore=0 spamscore=0 suspectscore=0 adultscore=0
 bulkscore=0 impostorscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608150100
X-purgate-ID: tlsNG-bad1c0/1786801999-3A8D9034-DB1FA6E5/0/0
X-purgate-type: clean
X-purgate-size: 1383

On 30/7/26 18:22, Dario Faggioli wrote:
> Commit 7d2778dea32a4924a469f1cc5767042c8f5b4eea ("hw/i386/pc:
> Remove deprecated pc-q35/pc-i440fx/xenfv 3.1 machines") removed
> the Xen machine type that was providing the "xenfv" alias. As a
> consequence, since the tools are apparently relying on such alias,
> we're getting this, as soon as one tries to start a Xen (HVM) VM:
> 
>    qemu-system-i386: unsupported machine type: "xenfv"
>    Use -machine help to list supported machines
> 
> Reinstate the alias and let it point to the only Xen machine we
> still have.
> 
> Fixes: 7d2778dea3 hw/i386/pc: Remove deprecated pc-q35/pc-i440fx/xenfv 3.1 machines
> Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
> ---
>   hw/i386/pc_piix.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 82457bdb16..0a911ce59e 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -658,6 +658,7 @@ static void xenfv_machine_4_2_options(MachineClass *m)
>   {
>       pc_i440fx_machine_4_2_options(m);
>       m->desc = "Xen Fully-virtualized PC";
> +    m->alias = "xenfv";
>       m->max_cpus = HVM_MAX_VCPUS;
>       m->default_machine_opts = "accel=xen,suppress-vmdesc=on";
>   }

Oops.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>

Queued adding the @stable tag for backport.


From xen-devel-bounces@lists.xenproject.org Sun Aug 16 05:15:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 05:15:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392068.1631322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvTCp-0000Al-Ei; Sun, 16 Aug 2026 05:14:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392068.1631322; Sun, 16 Aug 2026 05:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvTCp-0000AW-9j; Sun, 16 Aug 2026 05:14:47 +0000
Received: by outflank-mailman (input) for mailman id 1392068;
 Sun, 16 Aug 2026 05:14:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <lukas@wunner.de>) id 1wvTCo-0000AQ-8V
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 05:14:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvTCn-00DDZC-Df
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 07:14:45 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <lukas@wunner.de>)
 id 6a81472d-e002-0a2a0a5209dd-0a2a450be98a-8
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 07:14:45 +0200
Received: from [83.223.95.204] (helo=mailout1.hostsharing.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <lukas@wunner.de>)
 id 6a814745-b7e8-0a2a450b0019-53df5fcc8837-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 07:14:45 +0200
Received: from h08.hostsharing.net (h08.hostsharing.net
 [IPv6:2a01:37:1000::53df:5f1c:0])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384
 client-signature ECDSA (secp384r1) client-digest SHA384)
 (Client CN "*.hostsharing.net",
 Issuer "GlobalSign GCC R6 AlphaSSL CA 2025" (verified OK))
 by mailout1.hostsharing.net (Postfix) with ESMTPS id DB15E574;
 Sun, 16 Aug 2026 07:14:44 +0200 (CEST)
Received: by h08.hostsharing.net (Postfix, from userid 100393)
 id B8E36629CE21; Sun, 16 Aug 2026 07:14:44 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Date: Sun, 16 Aug 2026 07:14:44 +0200
From: Lukas Wunner <lukas@wunner.de>
To: Ruoyu Wang <ruoyuw560@gmail.com>
Cc: xen-devel@lists.xenproject.org, jgross@suse.com, sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com, bhelgaas@google.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xen/pcifront: Fix PCI device reference leak in AER
 handling
Message-ID: <aoFHREl-0XGl0uNG@wunner.de>
References: <20260813153138.3953222-1-ruoyuw560@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260813153138.3953222-1-ruoyuw560@gmail.com>
X-purgate-ID: tlsNG-42698a/1786857285-19CC79EA-08CB6568/0/0
X-purgate-type: clean
X-purgate-size: 871

On Thu, Aug 13, 2026 at 11:31:38PM +0800, Ruoyu Wang wrote:
> pci_get_domain_bus_and_slot() increments the reference count of the
> returned PCI device. pcifront_common_process() drops that reference only
> when the device or its driver is missing. All paths for a bound device
> either return directly after invoking an error recovery callback or fall
> through without calling pci_dev_put(). Consequently, each AER request for
> a bound device leaks a reference and can keep the device allocated after
> removal.
> 
> Store the callback result, release the reference after callback dispatch,
> and then return the result. This keeps the device alive while its callback
> runs and balances the lookup on every successful path.

Please use __free(pci_dev_put) instead, it'll simplify this patch
and the resulting function considerably.

Thanks,

Lukas


From xen-devel-bounces@lists.xenproject.org Sun Aug 16 16:39:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 16:39:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392289.1631331 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvdsu-0006pS-E8; Sun, 16 Aug 2026 16:38:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392289.1631331; Sun, 16 Aug 2026 16:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvdsu-0006pK-9f; Sun, 16 Aug 2026 16:38:56 +0000
Received: by outflank-mailman (input) for mailman id 1392289;
 Sun, 16 Aug 2026 16:38:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wvdst-0006pE-AT
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 16:38:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvdss-003RFk-1H
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 18:38:54 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a81e71f-bab6-0a2a0a5309dd-0a2a4507c4c6-42
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 18:38:53 +0200
Received: from [98.137.65.205] (helo=sonic311-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a81e79b-b4ea-0a2a45070019-628941cdad21-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 18:38:53 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 16 Aug 2026 16:38:51 +0000
Received: by hermes--production-ne1-6dbcb84f44-59qmb (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID a7c0d4753902ab36fdd683af5fb0813d; 
 Sun, 16 Aug 2026 16:38:48 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786898331; bh=C0sJATbIEzCXBKFkvm1mIxHiLUKgF5Nx8A6WCamwvOU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=geP8y+qxiQc/Q0qWRmkbHjDVdDzIrnSKmPMfpuycf1VUquHTRmK/6MssLQL2aGjYE/wBwApclK+/y3J53Ff6woow3lLy4KWEsgMUuBudjiGfvzXwLhzsD+FMd8gbWWfLwhe2boXLFAZPYzRIOX4MwBhuIhU6uks7dGR5sqFc3fdhu2yZV4DLvbJuduflqk5Kl+dY6HWPk3NbPp/WVMmtyWpLaM+GSnf4enYPs8Rm/46/D84uwNRgUr0QQrnj/akQ1D3fo7U/TnJ4WRyovX+rigdbZ6YjK51PLtIquGo7SfSqbIxrqzeJ4stppps0ZJYBjdPNzPxNZKUTJDOPoQMIOA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786898331; bh=LigkW4p4Zw3dbQlrMjr+JkyCTSTy9CFpcs3vR5j07M4=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=DJq1pGZe3+7u9AMsvWnZs69Gkrtj5nD4882/rdNnI22PsIb89xUFwOaYAKrfcSgeG4MYCp+WIAF/bIv+naxE1rKiDYzCGXHe51ciSjtacB5gt2KmwZhveAJRZ2IDT6heJr70DsXHxRbKbxiwOVs4SweO2AfLdAPNoW+c/cmIa7IBI+FDLcskRqC24RGekiStNLgVE3KbS23J0LDYBf+6w7IPrnN6IzgN7VQ9a+dKumZQvDudpsvB22KfOSXl79SjdGuU163/BkK4D9DgS3QyFqeP0QkMDOrnTc7Vt/8BjKetBSLH/vc0cW9B4sH9Do7e/XJS5J9/rMbpkezRYcKo9g==
X-YMail-OSG: mi1Fjr4VM1mKXdfSGDTmPLedmUrd3u9GsxEXg7sL4hkdA0ZlPYLC0qSwancAxiq
 8dRCAOqzD7xesGAddhnGczRWcjdinVI0k3oW5ZQyJu_m.FvQUVsVnfKHgadsx77tWQuQVIxkWsdu
 6p94pMZp.Hvx07jZ6CSO__VgAaACRRMDa1AYy5fnMsDoYV7nrN_B6DZPbKAWrqFBwahjPMLY.T59
 cqVTk4gMEzDiH.Z2HMQIOfDnsTph_GnMS1UZgJB2yi.MJa_XIPnPZemRcbWEJX6VkE800vZ4RXaS
 078qFWZj8A_xSYjdlfn2MeM7u1HnaYrEREwfHYdC8DlX4GBF3rnCXA8TLtELu6mY9hOJ0Q01rO0z
 AJKaqDlAWckp7Z7TkB4_0eBbRsGblisdt0kpOjXKzyWl0G1c71bnlSM5Pv5SI33dYqJCiaC10moq
 B.oGAAhyyV6s9XFaWYKA4sipGiOp0DTimcP5TVyURxPzVvvCbbxqQYDQVwAVbk7Wws0CfOGdgSCv
 odb5NbWUwvvOnBbXylUjtcloESzMHl3Wy4yTwGE860GBkFWCsd4gr1tn3t3Y6TqgNOxh6cvhXxrG
 2.YW1z9.uT5I_mEhKd7EfSZMhSLmPOiC2xPyuecRLYZkIcqBsYO2TRs.gZus3EMOQmFOcF0VZCIG
 eo1DLEVaKmHUrpk62Ys0UvPeqcWSs75UKIwkmQF0V6Oev5hABWu3KmPk4VjfTOiPYk8i5OJ1X3NI
 SlI3r4X.8Cp.D_k2DAbOR_ZSVubXLVOXfRtWXTiyzrpkbl0xBoYPDABfmfHHTd.TTKTXWtHR7e6C
 tvh1mrzWBywe3c1kEXpgkcNDPfltkwKsfQ6CJxJwTcIvEoXap5iHvtwh7RH9OEUoQrG4Ca3y6WOz
 INtwJdvbIo4VQ.NhbWHXdEumpsn.6wdKBnwU4YPuQnI7sk_mqChAjgoWNZa3k.aUYuDPXDzyTPCh
 9njwCn7qJhsPYgLE3ajeja5guu2YSTIqUerRqC.rAfFcdX8BbVxCgz.GBo_4IyG8Rl7RBRLripGX
 _j25y5h03jf2F0qLRan1qXChl33zVqT8mu_Thuic9VN1tR9wx7OuMe8YcxkAO.YK9qLqT5iNyDYg
 XkFA8ojOsN6OOXa10SwawfTftaX3yQqPqzbgZJ7UFDRnup8zScG0vlkPQgzQAy72PB1k2Ok9wZZe
 GeCUWCahlW2G0SzvHL3SG17geuJbfrGpJmxpkquqN0d5ca2kGb_Cuz4deaKpwhLN4H.HYiqKRrvt
 CjSIhWZEPRZ7ZTHzIgz33hsDMjdzsu1vnqIshXkYv.xaNR73mzSSUiavZAuK36sk1g7wb25Xh1Q2
 CK8kxYnIo3UAxrqeY_9NUGFqwwbvW8hoNQBqe1wAvUVdpKimInzAiwJQHdy04dfNLexsuSBe3.3X
 o9qv8Z5Kok_FE4OeFIowMxWNOPY199iDi7upMEvCVDnNPL7PjGTH6dwwZVZeheMPa.0hUyl7FBzt
 yHP2WnWmmE8pE8o8ObmdutkqeXWxdyl4_MZXjrk5RFWkwHXjnmFxaxnQUnkGT8YzAciI.WIXTJg5
 1Y.eLbslrwJgnYMV9jyX7E2inpR4LVZIqfeBvSTh7tf75KRsPcZKaDPHcF4m9n.6mamAPtymigDz
 Fzi3q1cNFXnfSnexrRMogce6tr8H9tVa2lr_CM6.axTfsohbJl.MbvstlH_msya4HiwgJvjhZL58
 kTFrlKuVBy86Wt9XHtaktGGYWapWRDa7CHjH8d_gjr.FhZ9C3mJwLA93rNkow5_fDegzoa3w70Um
 _8j4Kpnm9iWHICOiTr0Y5aCr41BXy8Afdg_8Hgnnop1wBX7rtI.BYiU4ULpW95oZcwVGxO4LXrYO
 bzq_FUKviEPtmlAOeySnBQ19mLzO3qWrypLAc4jnPdpISCzVtFbA3lcDPUuXOfgjJszh5m.0Kp2W
 SX8_MKcf_Lq28ge6mZbCecrePap9nJEpgDDj86.V8jR76mGqDqy.TI_ACpr60BWIu8l5BUUT4kCF
 mzwuvz6MorPmHogNz9_deBRqAq_J5Mbx5k99W2JpDfmGaXTDKu__pOnUHgAJ_UgjOh0cu6ZF4q6F
 MOEnFyIto7jLW3.lmLo9DZQnIHX_YqHNKBlPF2vtIBNj2IddNeOW5kPBHMylUWzG5RFceHfZhzpe
 elm0NqsT7GzOKQuQjIar1VsLMzrFgV3uaRllqCCXfkPcTb63ln2ZfxT98znlSQZ9iDRdnPSaQTzr
 d_jlfj4Ls0OUTFi2oq5lx0YOMUW0jHOkqaqlw.WJO
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 28290891-21d0-464f-b5ba-54585c5604a9
Message-ID: <a98b7e5f-240b-4642-b488-fac69846b3f8@aol.com>
Date: Sun, 16 Aug 2026 12:38:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 5107
X-purgate-ID: tlsNG-ef75cf/1786898333-A54C3AE4-753FB63F/0/0
X-purgate-type: clean
X-purgate-size: 5209

On 8/14/2026 3:35 AM, Jan Beulich wrote:
> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>> -- snip --
>>>> +    /*
>>>> +     * Read the value the device model is initialized with.
>>>> +     * If the device model supports OpRegion 2, it will
>>>> +     * return the host IGD OpRegion address. If not, it
>>>> +     * will return 0. If the device model does not support
>>>> +     * OpRegion 2, the device model expects us to give it
>>>> +     * the address to which it will map the OpRegion in the
>>>> +     * guest and then expects us to do nothing more to setup
>>>> +     * the OpRegion, so that is all we will do in that case.
>>>> +     */
>>>
>>> Hmm, exposing the host opregion to a guest certainly feels like an issue.
>> 
>> Well, that is how it is now. I am only retaining it to maintain backward
>> compatiblily with DM versions that do not support the extended VBT and
>> OpRegion 2+. My previous comment about backward compatibilty and DM
>> compatibility also applies here. If we don't worry about that, we can do
>> away with any cases where we are permanently mapping the host opregion to
>> the guest and implement this new approach of always exposing a copy of
>> the OpRegion and VBT to the guest instead.
> 
> How does "permanently mapping" matter? hvmloader runs inside the guest, so
> exposure just to copy the data isn't any better in terms of this being a
> layering violation. The more correct thing to do might be for the DM to
> put in place a copy before the guest (i.e. hvmloader) even gains control.
> (How in turn the DM would learn of the contents of the opregion is a
> separate question then.)

Hi Jan,

I am working on v3 of this patch and I want v3 to address this problem of a
"layering violation" that you mentioned here, but I do not understand exactly
what you mean. Do you mean to say that the current code we have in place and
have had in place for over the past 10 years [1] in the Qemu DM that traps and
maps the OpRegion into the guest is a "layering violation?"

[1] https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=5cec8aa38cc
("xen, gfx passthrough: add opregion mapping")

>>>> +    /*
>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>> +     * to communicate location of the VBT to the device
>>>> +     * model. If rvda_host is not 0, The device model
>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>> +     * after we also write the guest address where the
>>>> +     * VBT will be mapped.
>>>> +     *
>>>> +     * If we send rvda_host = 0 to the device model, it
>>>> +     * will assume we do not need OpRegion 2 support and
>>>> +     * it will not unmap the OpRegion.
>>>> +     */
>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>> +               (uint32_t)rvda_host_upper_32);
>>>
>>> Why would you need to communicate a host property to the DM?
>> 
>> The DM cannot access the host rvda value because it is only accessible
>> from the host kernel, and the DM is only a user-space process on the host.
> 
> I don't follow this: Anything the guest can access should also be accessible
> by its DM.

I also don't follow your comment here so permit me to comment and ask some
questions for clarification.

I was thinking it is enough for the domain the DM is running in to have
access to the resource for it to be legitimate for the DM to map the resource
into the guest. So I also think that whether or not the DM itself can access
the resource is irrelevant to the question. But you seem to be saying, no,
that is not enough, the DM itself should be able to access the resource
before it can be allowed to map the resource to its guest. Is that what you
are saying?

Perhaps your comment here is related to the concept of a "layering violation"
mentioned above. Are you saying it is a layering violation for the DM to
map an MMIO resource to its guest unless it actually has access to that
resource? If so, what kind of access to those device resources should the
DM have? Read access? Read/Write access?

If the specs only say the DM "should" have access to the resources it maps
into its guest, then I would think it would not be a layering violation.
But if the specs say the DM "must" have access before it asks the hypervisor
to map the resource to the guest, then I would admit that yes, we have a
layering violation because the DM is mapping the OpRegion to the guest
even though it does not have access to the OpRegion.

So, where are the specs for what the DM can and cannot do? Are they publicly
available, or are they proprietary or only available to members of the Linux
Foundation and/or the Xen Project? If the specs are publicly available, then
if possible, please show me the specific place in the specs where the Qemu DM
is violating the specs when it maps the OpRegion to its guest.

Thanks,

Chuck


From xen-devel-bounces@lists.xenproject.org Sun Aug 16 19:15:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 19:15:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392343.1631339 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgJu-00023M-SI; Sun, 16 Aug 2026 19:14:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392343.1631339; Sun, 16 Aug 2026 19:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgJu-00023F-PQ; Sun, 16 Aug 2026 19:14:58 +0000
Received: by outflank-mailman (input) for mailman id 1392343;
 Sun, 16 Aug 2026 19:14:56 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wvgJs-000239-KM
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 19:14:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvgJr-00Emcq-5d
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 21:14:55 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c12-8faa-0a2a0a5109dd-0a2a450cc58a-6
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:14:54 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c2d-f479-0a2a450c0019-aa0a817cbed1-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:14:54 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-331-z92NXEkZMoqJj0Kwrh29Ng-1; Sun,
 16 Aug 2026 15:14:49 -0400
Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 4C310180086F; Sun, 16 Aug 2026 19:14:47 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 9326B1956041; Sun, 16 Aug 2026 19:14:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1786907693;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=29Cd1MkKHFXGJOIFN77UUpfOSmWLs5aRZxGgmBwR2hM=;
	b=aPFq7JJEBN/ZcHDKwfQQEtU+lFSA+QLHg6N/OxLWsTZE+LwLRW/V70LzkH6XhzYKIyixG+
	M8vKhjBb91nxwVkfsZXqeIEA3mYwQngv0Nhcfwid/VbdjtR2kXI0NAFUtXKTlMBvpzfftO
	3l3TN/QcVZJzYA/1Wrf4JHJsL1a55q8=
X-MC-Unique: z92NXEkZMoqJj0Kwrh29Ng-1
X-Mimecast-MFC-AGG-ID: z92NXEkZMoqJj0Kwrh29Ng_1786907687
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sun, 16 Aug 2026 23:12:57 +0400
Subject: [PATCH v3 30/49] monitor: isolate HMP declarations in hmp.h
MIME-Version: 1.0
Message-Id: <20260816-qemu-no-hmp-v3-30-e53fc35bc550@redhat.com>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
In-Reply-To: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
 "Michael S. Tsirkin" <mst@redhat.com>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 "Dr. David Alan Gilbert" <dave@treblig.org>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Jason Wang <jasowangio@gmail.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=15760;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=lsf9mg6WFQhbEoyc7nCPI/4kkgRjXQJY5QWnI4e34zM=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqgguz2JplENevptot8NnAkDfYIJ5h+RL3Jgc2M
 7gQ64J6GOeJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaoILswAKCRDa6OEJdZac
 5cdsEACjja4Rml6Moi8e/UgJOf2s68LY0fob2xDJm7Lh6z8hgQ6vKXpzgmzaWBpSw4bUYcZqrAu
 LS1cxllZ2BuYJkEWD68GKmUeCA/pB51MIiAFEAkRssMEMsoYKLZ1MsEN5y5k7LPagYcokAdF3gp
 rLwu2wl8o1711y1P+WhkqHbn5Rv4pi06EU/5RBZ9IHl+S1IMQBINPuKTbyqaH8aJIeLl1PApFPY
 k7UNK5WSE5/qUoRROq1TupbMt6otu6aYtMP62SQmjHnFtaa5g31q7XR6ZL5ZjwJsKZWN5G4VAnc
 TkcWJ+0MqPpqCncxDAzCGpqcHn3+TnP8JG9vGN8GPQqPzbDSGldaL+lAuIj9gDuMMeEN7QlRGsZ
 q+v5c3Uug5MRQLlkagEdq5Ekt8qLDWQmHdHSKmcutwGIUcKjnTTmBMNvca/UDSemaJn9Ur8Ophj
 cLIGa++6Fm2ADk1fuphMBjTrONMRFNTTZemGe/wXu+rVr0JLcTrE6f4xDaudfBnrnUq3JnQt83E
 qLWEX648V6xZF5YgYxYZAzBJRrbgSF2EZUE8srBQc91JV0FXmC3vG2woStTIBPx5F7XME9yExgC
 QJR0I72lI/dh1By0oy6zQPIf24Vhp9bFsTwbFh3Q7ckgj07VyX3mGT2xNEuBGmJ7ezO0gCWnzp+
 G6mKU1/x24h7BxA==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17
X-Mimecast-MFC-PROC-ID: ZcCo5DK1sa0gNTKXm8xymQNgIAZtDhydKmHE9S8ykFM_1786907687
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786907694-51538A5B-942D3E6B/0/0
X-purgate-type: clean
X-purgate-size: 15762

Also rename password & commands with hmp in the name, while at it.
Other functions need larger changes which we will take care of next.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 accel/accel-system.c           |  1 +
 accel/tcg/monitor.c            |  1 +
 chardev/char.c                 |  2 +-
 disas/disas-mon.c              |  1 +
 gdbstub/system.c               |  2 +-
 hw/char/virtio-serial-bus.c    |  1 +
 hw/core/machine-hmp-cmds.c     |  1 -
 hw/core/sysbus.c               |  1 +
 hw/hexagon/hexagon_tlb.c       |  1 +
 hw/misc/auxbus.c               |  1 +
 hw/usb/bus.c                   |  1 +
 hw/usb/host-libusb.c           |  1 +
 hw/xen/xen-bus.c               |  1 +
 include/monitor/hmp.h          | 21 +++++++++++++++++++++
 include/monitor/monitor.h      | 18 ------------------
 monitor/hmp.c                  |  8 ++++----
 monitor/monitor-internal.h     |  1 +
 net/slirp.c                    |  1 +
 stubs/monitor-core.c           |  1 +
 stubs/monitor-internal.c       |  2 +-
 target/rx/disas.c              |  1 +
 tests/unit/test-util-sockets.c |  1 +
 tools/qemu-vnc/stubs.c         |  1 +
 trace/trace-hmp-cmds.c         |  1 -
 ui/ui-hmp-cmds.c               |  4 ++--
 util/error-report.c            |  2 +-
 util/qemu-print.c              |  1 +
 27 files changed, 48 insertions(+), 30 deletions(-)

diff --git a/accel/accel-system.c b/accel/accel-system.c
index 9176665202d2..977804c4048a 100644
--- a/accel/accel-system.c
+++ b/accel/accel-system.c
@@ -28,6 +28,7 @@
 #include "qom/compat-properties.h"
 #include "qapi/qapi-commands-accelerator.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "hw/core/boards.h"
 #include "hw/core/cpu.h"
 #include "accel/accel-ops.h"
diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
index be5c1950177c..74170ddef708 100644
--- a/accel/tcg/monitor.c
+++ b/accel/tcg/monitor.c
@@ -11,6 +11,7 @@
 #include "qapi/type-helpers.h"
 #include "qapi/qapi-commands-machine.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/tcg.h"
 #include "tcg/tcg.h"
 #include "internal-common.h"
diff --git a/chardev/char.c b/chardev/char.c
index c6c8133f5c1d..9da0911e503c 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -24,7 +24,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "monitor/qmp-helpers.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index 9c693618c277..bc9dec3a7761 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -10,6 +10,7 @@
 #include "system/memory.h"
 #include "hw/core/cpu.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 /*
  * Get LENGTH bytes from info's buffer, at target address memaddr.
diff --git a/gdbstub/system.c b/gdbstub/system.c
index 070bc26f416c..8a1cdb11db36 100644
--- a/gdbstub/system.c
+++ b/gdbstub/system.c
@@ -29,7 +29,7 @@
 #include "hw/core/boards.h"
 #include "chardev/char.h"
 #include "chardev/char-fe.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "internals.h"
 
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index c1973f0248fc..02604740f86a 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -25,6 +25,7 @@
 #include "qemu/module.h"
 #include "migration/qemu-file-types.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/queue.h"
 #include "hw/core/qdev-properties.h"
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 686304bafab5..1c700aad3587 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -15,7 +15,6 @@
 
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-builtin-visit.h"
 #include "qapi/qapi-commands-accelerator.h"
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 3e1160ee921d..13df7cbafe10 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -21,6 +21,7 @@
 #include "qapi/error.h"
 #include "hw/core/sysbus.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index b6d4aff389e5..2d878cee736d 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -12,6 +12,7 @@
 #include "hw/core/resettable.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 877f34560626..ac2525b90fec 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -33,6 +33,7 @@
 #include "hw/misc/auxbus.h"
 #include "hw/i2c/i2c.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 
 #ifndef DEBUG_AUX
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 3b6fbd46ac3f..9b9b2e7c2f8f 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -9,6 +9,7 @@
 #include "system/system.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "qemu/cutils.h"
 
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index b9f3ad3f66dd..af67d5dfeb10 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -48,6 +48,7 @@
 #include "qapi/error.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "qemu/module.h"
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index dfad2bc5085f..a563f6066bb4 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -17,6 +17,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/xen/xen-bus-helper.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "qobject/qdict.h"
 #include "system/system.h"
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 9258a049bffb..166cd4100c63 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -18,6 +18,9 @@
 #include "qapi/qapi-types-common.h"
 #include "monitor/monitor.h"
 
+#define TYPE_MONITOR_HMP "monitor-hmp"
+OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
+
 #define HMP_STUB(cmd) \
     void hmp_##cmd(Monitor *mon, const QDict *qdict) \
     { \
@@ -30,6 +33,24 @@ struct MonitorDef {
     int64_t (*get_value)(Monitor *mon, const MonitorDef *md, int offset);
 };
 
+void monitor_new_hmp(const char *id, const char *chardev_id,
+                     bool use_readline, Error **errp);
+
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+    G_GNUC_PRINTF(2, 0);
+int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_printc(Monitor *mon, int ch);
+
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque);
+
+void monitor_register_hmp(const char *name, bool info,
+                          void (*cmd)(Monitor *mon, const QDict *qdict));
+void monitor_register_hmp_info_hrt(const char *name,
+                                   HumanReadableText *(*handler)(Error **errp));
+
+
 CPUArchState *mon_get_cpu_env(Monitor *mon);
 CPUState *mon_get_cpu(Monitor *mon);
 
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 9f048ba103b5..72a8f6ea5b4f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -10,9 +10,6 @@
 #define TYPE_MONITOR "monitor"
 OBJECT_DECLARE_TYPE(Monitor, MonitorClass, MONITOR);
 
-#define TYPE_MONITOR_HMP "monitor-hmp"
-OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
-
 #define TYPE_MONITOR_QMP "monitor-qmp"
 OBJECT_DECLARE_TYPE(MonitorQMP, MonitorQMPClass, MONITOR_QMP);
 
@@ -30,8 +27,6 @@ void monitor_init_globals_core(void);
 char *monitor_compat_id(void);
 void monitor_new_qmp(const char *id, const char *chardev_id,
                      bool pretty, Error **errp);
-void monitor_new_hmp(const char *id, const char *chardev_id,
-                     bool use_readline, Error **errp);
 int monitor_new(MonitorOptions *opts, bool allow_hmp, Error **errp);
 int monitor_new_opts(QemuOpts *opts, Error **errp);
 void monitor_cleanup(void);
@@ -43,28 +38,15 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp);
 int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp);
 
 int monitor_puts(Monitor *mon, const char *str);
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
 void monitor_flush(Monitor *mon);
 int monitor_get_cpu_index(Monitor *mon);
 
 int monitor_puts_locked(Monitor *mon, const char *str);
 void monitor_flush_locked(Monitor *mon);
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt);
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque);
-
 AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
                                 const char *opaque, Error **errp);
 int monitor_fdset_dup_fd_add(int64_t fdset_id, int flags, Error **errp);
 void monitor_fdset_dup_fd_remove(int dup_fd);
 
-void monitor_register_hmp(const char *name, bool info,
-                          void (*cmd)(Monitor *mon, const QDict *qdict));
-void monitor_register_hmp_info_hrt(const char *name,
-                                   HumanReadableText *(*handler)(Error **errp));
-
 #endif /* MONITOR_H */
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 8134dfaad4bb..b4d05d47c4bf 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -136,7 +136,7 @@ static void monitor_command_cb(void *opaque, const char *cmdline,
     monitor_resume(&hmp->parent_obj);
 }
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt)
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt)
 {
     if (!hmp->rs) {
         return;
@@ -148,8 +148,8 @@ void monitor_read_command(MonitorHMP *hmp, int show_prompt)
     }
 }
 
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque)
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque)
 {
     if (hmp->rs) {
         readline_start(hmp->rs, "Password: ", 1, readline_func, opaque);
@@ -1647,7 +1647,7 @@ static void monitor_hmp_complete(UserCreatable *uc, Error **errp)
                                     monitor_readline_flush,
                                     hmp,
                                     monitor_find_completion);
-            monitor_read_command(hmp, 0);
+            monitor_hmp_read_command(hmp, 0);
         }
 
         qemu_chr_fe_set_handlers(&hmp->parent_obj.chr,
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index fdeeeb853636..ee9ba0c8231e 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -27,6 +27,7 @@
 
 #include "chardev/char-fe.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 #include "qapi/qapi-types-control.h"
 #include "qapi/qapi-types-qom.h"
diff --git a/net/slirp.c b/net/slirp.c
index 517dd23be14b..9bf09a2c8bc9 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -36,6 +36,7 @@
 #include "clients.h"
 #include "hub.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/sockets.h"
 #include <libslirp.h>
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index a7c32297c90a..b0c7002bd406 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 
 Monitor *monitor_cur(void)
diff --git a/stubs/monitor-internal.c b/stubs/monitor-internal.c
index 731fad221ecc..6f69f1f14ae4 100644
--- a/stubs/monitor-internal.c
+++ b/stubs/monitor-internal.c
@@ -1,6 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
 {
diff --git a/target/rx/disas.c b/target/rx/disas.c
index 67b932882914..0eb2ee6f4507 100644
--- a/target/rx/disas.c
+++ b/target/rx/disas.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 #include "disas/dis-asm.h"
 #include "qemu/bitops.h"
+#include "monitor/hmp.h"
 #include "cpu.h"
 
 typedef struct DisasContext {
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index ab3f39c3efb5..b2a884529598 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -24,6 +24,7 @@
 #include "qapi/error.h"
 #include "socket-helpers.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 static void test_fd_is_socket_bad(void)
 {
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 1c82d8cff430..26597fefaa99 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -9,6 +9,7 @@
 #include "system/runstate.h"
 #include "hw/core/qdev.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "migration/vmstate.h"
 
 bool runstate_is_running(void)
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 390173095cff..c8f0133abecf 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -25,7 +25,6 @@
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
 #include "monitor/hmp-completion.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-trace.h"
 #include "qobject/qdict.h"
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 806a7bece7cb..4ef459490ba2 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -327,7 +327,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
                                 void *readline_opaque)
 {
     qmp_change_vnc_password(password, NULL);
-    monitor_read_command(opaque, 1);
+    monitor_hmp_read_command(opaque, 1);
 }
 
 void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
@@ -344,7 +344,7 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
     }
     if (!arg) {
         MonitorHMP *hmp = MONITOR_HMP(mon);
-        monitor_read_password(hmp, hmp_change_read_arg, NULL);
+        monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
     }
diff --git a/util/error-report.c b/util/error-report.c
index f333af9249b9..aaa15bc79827 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -11,7 +11,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 
 /*
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 7b9591035e57..a2d1f0244168 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -12,6 +12,7 @@
 
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/qemu-print.h"
 
 /*

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Sun Aug 16 19:15:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 19:15:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392348.1631349 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgKV-0002Te-AI; Sun, 16 Aug 2026 19:15:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392348.1631349; Sun, 16 Aug 2026 19:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgKV-0002TX-72; Sun, 16 Aug 2026 19:15:35 +0000
Received: by outflank-mailman (input) for mailman id 1392348;
 Sun, 16 Aug 2026 19:15:33 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wvgKT-0002T4-Fi
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 19:15:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvgKS-003gUE-SZ
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 21:15:32 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c1c-2eae-0a2a0a5409dd-0a2a450bdee2-2
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:15:32 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c53-b7e8-0a2a450b0019-aa0a857c7edb-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:15:32 +0200
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-130-3qm0RnTJOAibztlqk4yKIg-1; Sun,
 16 Aug 2026 15:15:27 -0400
Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id EEDD219560A2; Sun, 16 Aug 2026 19:15:20 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id A1E0C423; Sun, 16 Aug 2026 19:15:16 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1786907731;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Nhcs5kFxRmDDBHARyXBJo1YaXoZWDvdCjupeG2jyQsc=;
	b=WPPMmbipsnniT4wubzRYxsvBMWnUUgLVN1NHY761Ijey4y0w0PcTd04dsnzH0h3jQrHc+w
	UplLf4O+fI66agsHukH9OIu/OIhN4y8eDxG0u+KjOk7iFYPmn8PEXYHlwGWMiJLD5CPJaU
	p1sCNqbclCafEllrHzu3pOZSrxtruhA=
X-MC-Unique: 3qm0RnTJOAibztlqk4yKIg-1
X-Mimecast-MFC-AGG-ID: 3qm0RnTJOAibztlqk4yKIg_1786907721
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sun, 16 Aug 2026 23:13:04 +0400
Subject: [PATCH v3 37/49] monitor: tighten monitor_printf*()
MIME-Version: 1.0
Message-Id: <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
In-Reply-To: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, 
 "Gonglei (Arei)" <arei.gonglei@huawei.com>, 
 zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>, 
 Hanna Reitz <hreitz@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Ani Sinha <anisinha@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Marcelo Tosatti <mtosatti@redhat.com>, 
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, 
 Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>, 
 Halil Pasic <pasic@linux.ibm.com>, 
 Christian Borntraeger <borntraeger@linux.ibm.com>, 
 Jason Herne <jjherne@linux.ibm.com>, Cornelia Huck <cohuck@redhat.com>, 
 Eric Farman <farman@linux.ibm.com>, Matthew Rosato <mjrosato@linux.ibm.com>, 
 Ilya Leoshkevich <iii@linux.ibm.com>, David Hildenbrand <david@kernel.org>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 "Dr. David Alan Gilbert" <dave@treblig.org>, 
 Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>, 
 Fabiano Rosas <farosas@suse.de>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Stefan Berger <stefanb@linux.vnet.ibm.com>, Zhao Liu <zhao1.liu@intel.com>, 
 Nicholas Piggin <npiggin@gmail.com>, Chinmay Rath <rathc@linux.ibm.com>, 
 Glenn Miles <milesg@linux.ibm.com>, 
 Harsh Prateek Bora <harshpb@linux.ibm.com>, 
 Palmer Dabbelt <palmer@dabbelt.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Weiwei Li <liwei1518@gmail.com>, 
 Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, 
 Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
 Chao Liu <chao.liu@processmission.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, 
 kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, 
 xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=268373;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=1bJXUnQzbOJBHG9RmXY0RR6uArdDrhXQAg5hT70VL4g=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqgguzr4z/HK8VTRbx3wJ52hDUo5iNXjld4+CHK
 J+43SGMcIOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaoILswAKCRDa6OEJdZac
 5SYgEACmCXFNKzQ26QsynhAa1sJ9/3lt5lC5LRsootO+nBuyusgwU+H6xDCto996tcAvhD+2tdG
 vdKQl9pAqpe1yY0ER34XZK/mNMJ8gPHnnGLsCSgXMRz+rvgi+Cj8e89WnmIksZ9o72R2+XZR1VN
 5n40suQs7qJEYSaEVl5tS87H6i7G57F73uX1YAJr+ChXw1lO5BWGkXj95u0jBnu1xYEWNMV46a7
 ktXEJr9b6wOwUsHPgcYBbNzKApLscHHHch8ErcpEX7xdR9H3XfN9EqjQ035mBczVCekkZmm3KEn
 Ndcz3CyCOmfbX7IXLVcD+V+k8VO0BtJJucTy44WxRTCiaMI4FlAfXN+Xojz5Uvyv8Gb6H6GncWP
 7CSVIKGWwB5t+vCrg10/l4hkTMwta8vCFNeBXK/9MlMsAlkbOetoBuOEkdIXFC+0cQQ2CuJEaf8
 hWLk/Pk0UYzQ/RxZZfu3aYCPJwaqicVLSZ8iGmFeH9jt4i3MfhqmaH+8gI93cuBd/GpRUnZbOqd
 Zza8C6wY1pdXgktxEqj7LL+YFWdwCNB/PTyl+iPBQ2ludL8iVPyRmuM0tt+DWWyZ3XAiGXFFbPH
 FD+yX3wtaG8Xw0LfFFZnZxn7xrcgVTauLwUj9ladCAMNNAK1w6mIVRN4M158ThePSvKBEJQYZdQ
 piBp+BxADajy/sg==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95
X-Mimecast-MFC-PROC-ID: eOv4-GWIQVZG-03GZVXYIkiEYMbsAtRsFssa-Rjezx4_1786907721
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786907732-A84CBA4A-40BD4DDB/0/0
X-purgate-type: clean
X-purgate-size: 268375

Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
the first parameter from Monitor * to MonitorHMP * to enforce type
safety. The implementation is also simplified: monitor_hmp_vprintf now
directly calls g_strdup_vprintf + monitor_puts, removing the virtual
dispatch via moncls->vprintf.

The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
cast, they are fixed in the following commits.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 audio/audio-hmp-cmds.c                  |   6 +-
 backends/cryptodev-hmp-cmds.c           |   9 +-
 block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
 chardev/char-hmp-cmds.c                 |  12 +-
 disas/disas-mon.c                       |  10 +-
 docs/devel/style.rst                    |   2 +-
 docs/devel/writing-monitor-commands.rst |   8 +-
 dump/dump-hmp-cmds.c                    |   5 +-
 hw/char/virtio-serial-bus.c             |  10 +-
 hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
 hw/core/sysbus.c                        |   5 +-
 hw/hexagon/hexagon_tlb.c                |  44 ++---
 hw/i386/kvm/xen-stubs.c                 |   6 +-
 hw/i386/kvm/xen_evtchn.c                |  21 +--
 hw/i386/sgx-hmp-stub.c                  |   3 +-
 hw/i386/sgx.c                           |  29 ++-
 hw/misc/auxbus.c                        |   9 +-
 hw/misc/mos6522-stub.c                  |   3 +-
 hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++-------
 hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
 hw/pci/pci-stub.c                       |   3 +-
 hw/s390x/s390-skeys.c                   |   9 +-
 hw/s390x/s390-stattrib.c                |  20 +--
 hw/uefi/ovmf-log.c                      |   5 +-
 hw/usb/bus.c                            |  11 +-
 hw/usb/host-libusb.c                    |  21 ++-
 hw/virtio/virtio-hmp-cmds.c             | 297 +++++++++++++++----------------
 hw/xen/xen-bus.c                        |   5 +-
 include/disas/disas.h                   |   4 +-
 include/monitor/hmp.h                   |  12 +-
 migration/dirtyrate.c                   |  46 +++--
 migration/migration-hmp-cmds.c          | 305 ++++++++++++++++----------------
 monitor/hmp-cmds.c                      | 141 +++++++--------
 monitor/hmp.c                           | 143 +++++++--------
 monitor/monitor-internal.h              |   6 -
 monitor/monitor.c                       |  33 ++--
 net/net-hmp-cmds.c                      |  31 ++--
 net/slirp.c                             |  31 ++--
 qom/qom-hmp-cmds.c                      |  27 ++-
 replay/replay-debugging.c               |   5 +-
 stats/stats-hmp-cmds.c                  |  57 +++---
 stubs/hmp-cmd-info_sev.c                |   3 +-
 stubs/monitor-core.c                    |   2 +-
 system/dirtylimit-hmp-cmds.c            |  10 +-
 system/qdev-monitor.c                   |  19 +-
 system/runstate-hmp-cmds.c              |  16 +-
 system/tpm-hmp-cmds.c                   |  29 ++-
 target/i386/cpu-apic.c                  |   3 +-
 target/i386/monitor.c                   | 152 ++++++++--------
 target/i386/sev.c                       |  35 ++--
 target/m68k/monitor.c                   |   3 +-
 target/ppc/monitor.c                    |   3 +-
 target/riscv/monitor.c                  |  55 +++---
 target/sh4/monitor.c                    |  29 ++-
 target/sparc/monitor.c                  |   3 +-
 target/xtensa/monitor.c                 |   3 +-
 tests/unit/test-util-sockets.c          |   2 +-
 tools/qemu-vnc/clipboard.c              |   4 +-
 tools/qemu-vnc/stubs.c                  |   2 +-
 trace/trace-hmp-cmds.c                  |  12 +-
 ui/ui-hmp-cmds.c                        | 115 ++++++------
 util/error-report.c                     |   2 +-
 util/qemu-print.c                       |   4 +-
 63 files changed, 1214 insertions(+), 1329 deletions(-)

diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
index 4d326ec99fdf..94182fe1d71f 100644
--- a/audio/audio-hmp-cmds.c
+++ b/audio/audio-hmp-cmds.c
@@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
 
 void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     CaptureState *s;
 
     warn_report_once("'info capture' is deprecated since v10.2, to be removed");
 
     for (s = capture_head.lh_first, i = 0; s; s = s->entries.le_next, ++i) {
-        monitor_printf(mon, "[%d]: ", i);
+        monitor_hmp_printf(hmp, "[%d]: ", i);
         s->ops.info (s->opaque);
     }
 }
@@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     int freq = qdict_get_try_int(qdict, "freq", 44100);
     int bits = qdict_get_try_int(qdict, "bits", 16);
@@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
     s = g_malloc0 (sizeof (*s));
 
     if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
-        monitor_printf(mon, "Failed to add wave capture\n");
+        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
         g_free (s);
         return;
     }
diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
index fb62428d795a..aafa4b970d24 100644
--- a/backends/cryptodev-hmp-cmds.c
+++ b/backends/cryptodev-hmp-cmds.c
@@ -19,7 +19,6 @@
 
 void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     QCryptodevInfoList *il;
     QCryptodevBackendServiceTypeList *sl;
     QCryptodevBackendClientList *cl;
@@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
                 services = tmp_services;
             }
         }
-        monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
+        monitor_hmp_printf(hmp, "%s: service=[%s]\n", info->id, services);
 
         for (cl = info->client; cl; cl = cl->next) {
             QCryptodevBackendClient *client = cl->value;
-            monitor_printf(mon, "    queue %" PRIu32 ": type=%s\n",
-                           client->queue,
-                           QCryptodevBackendType_str(client->type));
+            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=%s\n",
+                               client->queue,
+                               QCryptodevBackendType_str(client->type));
         }
     }
 
diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-cmds.c
index a2666e2f1b9b..7bae4d425c6d 100644
--- a/block/monitor/block-hmp-cmds.c
+++ b/block/monitor/block-hmp-cmds.c
@@ -89,7 +89,6 @@ out:
 
 void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     DriveInfo *dinfo;
     QemuOpts *opts;
@@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 
     switch (dinfo->type) {
     case IF_NONE:
-        monitor_printf(mon, "OK\n");
+        monitor_hmp_printf(hmp, "OK\n");
         break;
     default:
         error_setg(&err, "Can't hot-add drive to type %d", dinfo->type);
@@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdict)
     hmp_handle_error(hmp, err);
 }
 
-static void print_block_info(Monitor *mon, BlockInfo *info,
+static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
                              BlockDeviceInfo *inserted, bool verbose)
 {
+    Monitor *mon = MONITOR(hmp);
     ImageInfo *image_info;
 
     assert(!info || !info->inserted || info->inserted == inserted);
@@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     if (info && *info->device) {
         monitor_puts(mon, info->device);
         if (inserted && inserted->node_name) {
-            monitor_printf(mon, " (%s)", inserted->node_name);
+            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
         }
     } else {
         assert(info || inserted);
@@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (inserted) {
-        monitor_printf(mon, ": %s (%s%s%s%s)\n",
-                       inserted->file,
-                       inserted->drv,
-                       inserted->ro ? ", read-only" : "",
-                       inserted->encrypted ? ", encrypted" : "",
-                       inserted->active ? "" : ", inactive");
+        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
+                           inserted->file,
+                           inserted->drv,
+                           inserted->ro ? ", read-only" : "",
+                           inserted->encrypted ? ", encrypted" : "",
+                           inserted->active ? "" : ", inactive");
     } else {
-        monitor_printf(mon, ": [not inserted]\n");
+        monitor_hmp_printf(hmp, ": [not inserted]\n");
     }
 
     if (info) {
         if (info->qdev) {
-            monitor_printf(mon, "    Attached to:      %s\n", info->qdev);
+            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info->qdev);
         }
         if (info->has_io_status && info->io_status != BLOCK_DEVICE_IO_STATUS_OK) {
-            monitor_printf(mon, "    I/O status:       %s\n",
-                           BlockDeviceIoStatus_str(info->io_status));
+            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
+                               BlockDeviceIoStatus_str(info->io_status));
         }
 
         if (info->removable) {
-            monitor_printf(mon, "    Removable device: %slocked, tray %s\n",
-                           info->locked ? "" : "not ",
-                           info->tray_open ? "open" : "closed");
+            monitor_hmp_printf(hmp, "    Removable device: %slocked, tray %s\n",
+                               info->locked ? "" : "not ",
+                               info->tray_open ? "open" : "closed");
         }
     }
 
@@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
         return;
     }
 
-    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
-                   inserted->cache->writeback ? "writeback" : "writethrough",
-                   inserted->cache->direct ? ", direct" : "",
-                   inserted->cache->no_flush ? ", ignore flushes" : "");
+    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
+                       inserted->cache->writeback ? "writeback" : "writethrough",
+                       inserted->cache->direct ? ", direct" : "",
+                       inserted->cache->no_flush ? ", ignore flushes" : "");
 
     if (inserted->backing_file) {
-        monitor_printf(mon,
-                       "    Backing file:     %s "
-                       "(chain depth: %" PRId64 ")\n",
-                       inserted->backing_file,
-                       inserted->backing_file_depth);
+        monitor_hmp_printf(hmp,
+                           "    Backing file:     %s "
+                           "(chain depth: %" PRId64 ")\n",
+                           inserted->backing_file,
+                           inserted->backing_file_depth);
     }
 
     if (inserted->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF) {
-        monitor_printf(mon, "    Detect zeroes:    %s\n",
+        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
                 BlockdevDetectZeroesOptions_str(inserted->detect_zeroes));
     }
 
     if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
         inserted->iops || inserted->iops_rd || inserted->iops_wr)
     {
-        monitor_printf(mon, "    I/O throttling:   bps=%" PRId64
+        monitor_hmp_printf(hmp, "    I/O throttling:   bps=%" PRId64
                         " bps_rd=%" PRId64  " bps_wr=%" PRId64
                         " bps_max=%" PRId64
                         " bps_rd_max=%" PRId64
@@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (verbose) {
-        monitor_printf(mon, "\nImages:\n");
+        monitor_hmp_printf(hmp, "\nImages:\n");
         image_info = inserted->image;
         while (1) {
             bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, false);
@@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
 
 void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockInfoList *block_list, *info;
     BlockDeviceInfoList *blockdev_list, *blockdev;
     const char *device = qdict_get_try_str(qdict, "device");
@@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (info != block_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, info->value, info->value->inserted,
+        print_block_info(hmp, info->value, info->value->inserted,
                          verbose);
         printed = true;
     }
@@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (blockdev != blockdev_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, NULL, blockdev->value, verbose);
+        print_block_info(hmp, NULL, blockdev->value, verbose);
     }
     qapi_free_BlockDeviceInfoList(blockdev_list);
 }
 
 void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockStatsList *stats_list, *stats;
 
     stats_list = qmp_query_blockstats(false, false, NULL);
@@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
 
-        monitor_printf(mon, "%s%s: idle_time_ns=%" PRId64 "\n",
-                       stats != stats_list ? "\n" : "",
-                       stats->value->device,
-                       stats->value->stats->idle_time_ns);
-        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
-                       "operations", "total_time_ns", "merged");
-        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->rd_bytes,
-                       stats->value->stats->rd_operations,
-                       stats->value->stats->rd_total_time_ns,
-                       stats->value->stats->rd_merged);
-        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->wr_bytes,
-                       stats->value->stats->wr_operations,
-                       stats->value->stats->wr_total_time_ns,
-                       stats->value->stats->wr_merged);
-        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
-                       "",
-                       stats->value->stats->flush_operations,
-                       stats->value->stats->flush_total_time_ns);
+        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=%" PRId64 "\n",
+                           stats != stats_list ? "\n" : "",
+                           stats->value->device,
+                           stats->value->stats->idle_time_ns);
+        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes",
+                           "operations", "total_time_ns", "merged");
+        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->rd_bytes,
+                           stats->value->stats->rd_operations,
+                           stats->value->stats->rd_total_time_ns,
+                           stats->value->stats->rd_merged);
+        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->wr_bytes,
+                           stats->value->stats->wr_operations,
+                           stats->value->stats->wr_total_time_ns,
+                           stats->value->stats->wr_merged);
+        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
+                           "",
+                           stats->value->stats->flush_operations,
+                           stats->value->stats->flush_total_time_ns);
     }
 
     qapi_free_BlockStatsList(stats_list);
@@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockJobInfoList *list;
 
     list = qmp_query_block_jobs(&error_abort);
 
     if (!list) {
-        monitor_printf(mon, "No active jobs\n");
+        monitor_hmp_printf(hmp, "No active jobs\n");
         return;
     }
 
     while (list) {
         if (list->value->type == JOB_TYPE_STREAM) {
-            monitor_printf(mon, "Streaming device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Streaming device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         } else {
-            monitor_printf(mon, "Type %s, device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           JobType_str(list->value->type),
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               JobType_str(list->value->type),
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         }
         list = list->next;
     }
@@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockDriverState *bs, *bs1;
     BdrvNextIterator it1;
     QEMUSnapshotInfo *sn_tab, *sn;
@@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     nb_sns = bdrv_snapshot_list(bs, &sn_tab);
 
     if (nb_sns < 0) {
-        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
+        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_sns);
         return;
     }
 
@@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (no_snapshot) {
-        monitor_printf(mon, "There is no snapshot available.\n");
+        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
         return;
     }
 
@@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
             }
         }
     }
-    monitor_printf(mon, "List of snapshots present on all disks:\n");
+    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n");
 
     if (total > 0) {
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         for (i = 0; i < total; i++) {
             sn = &sn_tab[global_snapshots[i]];
             /*
@@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
              */
             pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
             bdrv_snapshot_dump(sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     } else {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
     }
 
     QTAILQ_FOREACH(image_entry, &image_list, next) {
         if (QTAILQ_EMPTY(&image_entry->snapshots)) {
             continue;
         }
-        monitor_printf(mon,
-                       "\nList of partial (non-loadable) snapshots on '%s':\n",
-                       image_entry->imagename);
+        monitor_hmp_printf(hmp,
+                           "\nList of partial (non-loadable) snapshots on '%s':\n",
+                           image_entry->imagename);
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) {
             bdrv_snapshot_dump(&snapshot_entry->sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
@@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     g_free(global_snapshots);
 }
 
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp)
 {
diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
index 71017fd2d19e..fb0560054b7b 100644
--- a/chardev/char-hmp-cmds.c
+++ b/chardev/char-hmp-cmds.c
@@ -26,12 +26,11 @@
 
 void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     ChardevInfoList *char_info, *info;
 
     char_info = qmp_query_chardev(NULL);
     for (info = char_info; info; info = info->next) {
-        monitor_printf(mon, "%s: filename=%s\n", info->value->label,
+        monitor_hmp_printf(hmp, "%s: filename=%s\n", info->value->label,
                                                  info->value->filename);
     }
 
@@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *chardev = qdict_get_str(qdict, "device");
     char *data;
@@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
         unsigned char ch = data[i];
 
         if (ch == '\\') {
-            monitor_printf(mon, "\\\\");
+            monitor_hmp_printf(hmp, "\\\\");
         } else if ((ch < 0x20 && ch != '\n' && ch != '\t') || ch == 0x7F) {
-            monitor_printf(mon, "\\u%04X", ch);
+            monitor_hmp_printf(hmp, "\\u%04X", ch);
         } else {
-            monitor_printf(mon, "%c", ch);
+            monitor_hmp_printf(hmp, "%c", ch);
         }
 
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     g_free(data);
 }
 
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index bc9dec3a7761..32e4220181a8 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
 }
 
 /* Disassembler for the monitor.  */
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical)
 {
     int count, i;
@@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
     s.info.buffer_vma = pc;
 
     if (s.info.cap_arch >= 0 && cap_disas_monitor(&s.info, pc, nb_insn)) {
-        monitor_puts(mon, ds->str);
+        monitor_puts(MONITOR(hmp), ds->str);
         return;
     }
 
     if (!s.info.print_insn) {
-        monitor_printf(mon, "0x%08" PRIx64
-                       ": Asm output not supported on this arch\n", pc);
+        monitor_hmp_printf(hmp, "0x%08" PRIx64
+                           ": Asm output not supported on this arch\n", pc);
         return;
     }
 
@@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
         pc += count;
     }
 
-    monitor_puts(mon, ds->str);
+    monitor_puts(MONITOR(hmp), ds->str);
 }
diff --git a/docs/devel/style.rst b/docs/devel/style.rst
index 6c5f94cc5098..6876d3a59ec7 100644
--- a/docs/devel/style.rst
+++ b/docs/devel/style.rst
@@ -754,7 +754,7 @@ Error handling and reporting
 Reporting errors to the human user
 ----------------------------------
 
-Do not use printf(), fprintf() or monitor_printf().  Instead, use
+Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
 error_report() or error_vreport() from error-report.h.  This ensures the
 error is reported in the right place (current monitor or stderr), and in
 a uniform format.
diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
index 7ae7efe32759..baf94cbdefab 100644
--- a/docs/devel/writing-monitor-commands.rst
+++ b/docs/devel/writing-monitor-commands.rst
@@ -479,7 +479,7 @@ The HMP command
 
 Here's the HMP counterpart of the query-option-roms command::
 
- void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
+ void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
  {
      Error *err = NULL;
      OptionRomInfoList *info_list, *tail;
@@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-roms command::
 
      for (tail = info_list; tail; tail = tail->next) {
          info = tail->value;
-         monitor_printf(mon, "%s", info->filename);
+         monitor_hmp_printf(mon, "%s", info->filename);
          if (info->has_bootindex) {
-             monitor_printf(mon, " %" PRId64, info->bootindex);
+             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
          }
-         monitor_printf(mon, "\n");
+         monitor_hmp_printf(mon, "\n");
      }
 
      qapi_free_OptionRomInfoList(info_list);
diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
index 104ab5d2a53a..c7045c2d7314 100644
--- a/dump/dump-hmp-cmds.c
+++ b/dump/dump-hmp-cmds.c
@@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DumpQueryResult *result = qmp_query_dump(NULL);
 
     assert(result && result->status < DUMP_STATUS__MAX);
-    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status));
+    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->status));
 
     if (result->status == DUMP_STATUS_ACTIVE) {
         float percent = 0;
         assert(result->total != 0);
         percent = 100.0 * result->completed / result->total;
-        monitor_printf(mon, "Finished: %.2f %%\n", percent);
+        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
     }
 
     qapi_free_DumpQueryResult(result);
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 02604740f86a..33fdc0846ac3 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
-                   indent, "", port->id,
-                   port->guest_connected ? "on" : "off",
-                   port->host_connected ? "on" : "off",
-                   port->throttled ? "on" : "off");
+    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+                       indent, "", port->id,
+                       port->guest_connected ? "on" : "off",
+                       port->host_connected ? "on" : "off",
+                       port->throttled ? "on" : "off");
 }
 
 /* This function is only used if a port id is not provided by the user */
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 702c798ccc56..10a633af0780 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -27,7 +27,6 @@
 
 void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CpuInfoFastList *cpu_list, *cpu;
 
     cpu_list = qmp_query_cpus_fast(NULL);
@@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
             active = '*';
         }
 
-        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
-                       cpu->value->cpu_index);
-        monitor_printf(mon, " thread_id=%" PRId64 " model=%s\n",
-                       cpu->value->thread_id, cpu_model);
+        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
+                           cpu->value->cpu_index);
+        monitor_hmp_printf(hmp, " thread_id=%" PRId64 " model=%s\n",
+                           cpu->value->thread_id, cpu_model);
     }
 
     qapi_free_CpuInfoFastList(cpu_list);
@@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     HotpluggableCPUList *l = qmp_query_hotpluggable_cpus(&err);
     HotpluggableCPUList *saved = l;
@@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Hotpluggable CPUs:\n");
+    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
     while (l) {
-        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
-        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
-                       l->value->vcpus_count);
+        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
+        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
+                           l->value->vcpus_count);
         if (l->value->qom_path) {
-            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_path);
+            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->qom_path);
         }
 
         c = l->value->props;
-        monitor_printf(mon, "  CPUInstance Properties:\n");
+        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
         if (c->has_node_id) {
-            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
+            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
         }
         if (c->has_drawer_id) {
-            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
+            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
         }
         if (c->has_book_id) {
-            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
+            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
         }
         if (c->has_socket_id) {
-            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
+            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
         }
         if (c->has_die_id) {
-            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
+            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
         }
         if (c->has_cluster_id) {
-            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
-                           c->cluster_id);
+            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n",
+                               c->cluster_id);
         }
         if (c->has_module_id) {
-            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
-                           c->module_id);
+            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n",
+                               c->module_id);
         }
         if (c->has_core_id) {
-            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
+            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
         }
         if (c->has_thread_id) {
-            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
+            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
         }
 
         l = l->next;
@@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemdevList *memdev_list = qmp_query_memdev(&err);
     MemdevList *m = memdev_list;
@@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
     while (m) {
         v = string_output_visitor_new(false, &str);
         visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_abort);
-        monitor_printf(mon, "memory backend: %s\n", m->value->id);
-        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
-        monitor_printf(mon, "  merge: %s\n",
-                       m->value->merge ? "true" : "false");
-        monitor_printf(mon, "  dump: %s\n",
-                       m->value->dump ? "true" : "false");
-        monitor_printf(mon, "  prealloc: %s\n",
-                       m->value->prealloc ? "true" : "false");
-        monitor_printf(mon, "  share: %s\n",
-                       m->value->share ? "true" : "false");
+        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
+        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->size);
+        monitor_hmp_printf(hmp, "  merge: %s\n",
+                           m->value->merge ? "true" : "false");
+        monitor_hmp_printf(hmp, "  dump: %s\n",
+                           m->value->dump ? "true" : "false");
+        monitor_hmp_printf(hmp, "  prealloc: %s\n",
+                           m->value->prealloc ? "true" : "false");
+        monitor_hmp_printf(hmp, "  share: %s\n",
+                           m->value->share ? "true" : "false");
         if (m->value->has_reserve) {
-            monitor_printf(mon, "  reserve: %s\n",
-                           m->value->reserve ? "true" : "false");
+            monitor_hmp_printf(hmp, "  reserve: %s\n",
+                               m->value->reserve ? "true" : "false");
         }
-        monitor_printf(mon, "  policy: %s\n",
-                       HostMemPolicy_str(m->value->policy));
+        monitor_hmp_printf(hmp, "  policy: %s\n",
+                           HostMemPolicy_str(m->value->policy));
         visit_complete(v, &str);
-        monitor_printf(mon, "  host nodes: %s\n", str);
+        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
 
         g_free(str);
         visit_free(v);
         m = m->next;
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_MemdevList(memdev_list);
     hmp_handle_error(hmp, err);
@@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     KvmInfo *info;
 
     info = qmp_query_kvm(NULL);
-    monitor_printf(mon, "kvm support: ");
+    monitor_hmp_printf(hmp, "kvm support: ");
     if (info->present) {
-        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disabled");
+        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "disabled");
     } else {
-        monitor_printf(mon, "not compiled\n");
+        monitor_hmp_printf(hmp, "not compiled\n");
     }
 
     qapi_free_KvmInfo(info);
@@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     AcceleratorInfo *info;
     AcceleratorList *accel;
 
@@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
     for (accel = info->present; accel; accel = accel->next) {
         char trail = accel->next ? ' ' : '\n';
         if (info->enabled == accel->value) {
-            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->value), trail);
         } else {
-            monitor_printf(mon, "%s%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->value), trail);
         }
     }
 
@@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     UuidInfo *info;
 
     info = qmp_query_uuid(NULL);
-    monitor_printf(mon, "%s\n", info->UUID);
+    monitor_hmp_printf(hmp, "%s\n", info->UUID);
     qapi_free_UuidInfo(info);
 }
 
 void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BalloonInfo *info;
     Error *err = NULL;
 
@@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
+    monitor_hmp_printf(hmp, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
 
     qapi_free_BalloonInfo(info);
 }
@@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *filename = qdict_get_str(qdict, "filename");
     uint64_t addr = qdict_get_int(qdict, "val");
@@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
     int cpu_index = monitor_hmp_get_cpu_index(hmp);
 
     if (cpu_index < 0) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
@@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryDeviceInfoList *info_list = qmp_query_memory_devices(&err);
     MemoryDeviceInfoList *info;
@@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
             case MEMORY_DEVICE_INFO_KIND_NVDIMM:
                 di = value->type == MEMORY_DEVICE_INFO_KIND_DIMM ?
                      value->u.dimm.data : value->u.nvdimm.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               di->id ? di->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->addr);
-                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot);
-                monitor_printf(mon, "  node: %" PRId64 "\n", di->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size);
-                monitor_printf(mon, "  memdev: %s\n", di->memdev);
-                monitor_printf(mon, "  hotplugged: %s\n",
-                               di->hotplugged ? "true" : "false");
-                monitor_printf(mon, "  hotpluggable: %s\n",
-                               di->hotpluggable ? "true" : "false");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   di->id ? di->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di->addr);
+                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->slot);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
+                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
+                                   di->hotplugged ? "true" : "false");
+                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
+                                   di->hotpluggable ? "true" : "false");
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
                 vpi = value->u.virtio_pmem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vpi->id ? vpi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size);
-                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vpi->id ? vpi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
                 vmi = value->u.virtio_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vmi->id ? vmi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node);
-                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
-                               vmi->requested_size);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size);
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->max_size);
-                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
-                               vmi->block_size);
-                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vmi->id ? vmi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->node);
+                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "\n",
+                                   vmi->requested_size);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", vmi->max_size);
+                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
+                                   vmi->block_size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
                 se = value->u.sgx_epc.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               se->id ? se->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size);
-                monitor_printf(mon, "  node: %" PRId64 "\n", se->node);
-                monitor_printf(mon, "  memdev: %s\n", se->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   se->id ? se->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->size);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->node);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
                 hi = value->u.hv_balloon.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               hi->id ? hi->id : "");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   hi->id ? hi->id : "");
                 if (hi->has_memaddr) {
-                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
-                                   hi->memaddr);
+                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n",
+                                       hi->memaddr);
                 }
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->max_size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", hi->max_size);
                 if (hi->memdev) {
-                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
+                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memdev);
                 }
                 break;
             case MEMORY_DEVICE_INFO_KIND_SP_MEM:
                 spmi = value->u.sp_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               spmi->id ? spmi->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->addr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->size);
-                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   spmi->id ? spmi->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spmi->addr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev);
                 break;
             default:
                 g_assert_not_reached();
@@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     GuidInfo *info = qmp_query_vm_generation_id(&err);
     if (info) {
-        monitor_printf(mon, "%s\n", info->guid);
+        monitor_hmp_printf(hmp, "%s\n", info->guid);
     }
     hmp_handle_error(hmp, err);
     qapi_free_GuidInfo(info);
@@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryInfo *info = qmp_query_memory_size_summary(&err);
     if (info) {
-        monitor_printf(mon, "base memory: %" PRIu64 "\n",
-                       info->base_memory);
+        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
+                           info->base_memory);
 
         if (info->has_plugged_memory) {
-            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
-                           info->plugged_memory);
+            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
+                               info->plugged_memory);
         }
 
         qapi_free_MemoryInfo(info);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 13df7cbafe10..82130ba04698 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
     for (i = 0; i < s->num_mmio; i++) {
         size = memory_region_size(s->mmio[i].memory);
-        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                       indent, "", s->mmio[i].addr, size);
+        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                           indent, "", s->mmio[i].addr, size);
     }
 }
 
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index 2d878cee736d..576929ff224b 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t entry)
 
 bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
+
     if (GET_PTE_V(entry)) {
         uint64_t PA = hex_tlb_phys_addr(entry);
         uint64_t VA = hex_tlb_virt_addr(entry);
-        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
-        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
-                       " A1:%" PRId64 " A0:%" PRId64,
-                       GET_PTE_V(entry),
-                       GET_PTE_G(entry),
-                       GET_PTE_ATR1(entry),
-                       GET_PTE_ATR0(entry));
-        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
-                       GET_PTE_ASID(entry), VA);
-        monitor_printf(mon,
-                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
-                       " U:%" PRId64 " C:%" PRId64,
-                       GET_PTE_X(entry),
-                       GET_PTE_W(entry),
-                       GET_PTE_R(entry),
-                       GET_PTE_U(entry),
-                       GET_PTE_C(entry));
-        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
-                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
-                       hex_tlb_page_size_bytes(entry));
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
+        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
+                           " A1:%" PRId64 " A0:%" PRId64,
+                           GET_PTE_V(entry),
+                           GET_PTE_G(entry),
+                           GET_PTE_ATR1(entry),
+                           GET_PTE_ATR0(entry));
+        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
+                           GET_PTE_ASID(entry), VA);
+        monitor_hmp_printf(hmp,
+                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
+                           " U:%" PRId64 " C:%" PRId64,
+                           GET_PTE_X(entry),
+                           GET_PTE_W(entry),
+                           GET_PTE_R(entry),
+                           GET_PTE_U(entry),
+                           GET_PTE_C(entry));
+        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
+                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
+                           hex_tlb_page_size_bytes(entry));
+        monitor_hmp_printf(hmp, "\n");
         return true;
     }
 
diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
index ab1eb14f99e0..5ed71583281a 100644
--- a/hw/i386/kvm/xen-stubs.c
+++ b/hw/i386/kvm/xen-stubs.c
@@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 00dff6ee8760..b2135020f27f 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **errp)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     EvtchnInfoList *iter, *info_list;
     Error *err = NULL;
 
@@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
     for (iter = info_list; iter; iter = iter->next) {
         EvtchnInfo *info = iter->value;
 
-        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info->vcpu,
-                       EvtchnPortType_str(info->type));
+        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, info->vcpu,
+                           EvtchnPortType_str(info->type));
         if (info->type != EVTCHN_PORT_TYPE_IPI) {
-            monitor_printf(mon,  "(");
+            monitor_hmp_printf(hmp,  "(");
             if (info->remote_domain) {
-                monitor_printf(mon, "%s:", info->remote_domain);
+                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
             }
-            monitor_printf(mon, "%d)", info->target);
+            monitor_hmp_printf(hmp, "%d)", info->target);
         }
         if (info->pending) {
-            monitor_printf(mon, " PENDING");
+            monitor_hmp_printf(hmp, " PENDING");
         }
         if (info->masked) {
-            monitor_printf(mon, " MASKED");
+            monitor_hmp_printf(hmp, " MASKED");
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_EvtchnInfoList(info_list);
@@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int port = qdict_get_int(qdict, "port");
     Error *err = NULL;
 
@@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
     if (err) {
         hmp_handle_error(hmp, err);
     } else {
-        monitor_printf(mon, "Delivered port %d\n", port);
+        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
     }
 }
-
diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
index a4848ae1d1a7..b7afb26886a8 100644
--- a/hw/i386/sgx-hmp-stub.c
+++ b/hw/i386/sgx-hmp-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SGX is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
 }
diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
index 77b41d234c9f..634e33e819ce 100644
--- a/hw/i386/sgx.c
+++ b/hw/i386/sgx.c
@@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     SgxEpcSectionList *section_list, *section;
     g_autoptr(SgxInfo) info = qmp_query_sgx(&err);
@@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
         error_report_err(err);
         return;
     }
-    monitor_printf(mon, "SGX support: %s\n",
-                   info->sgx ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX1 support: %s\n",
-                   info->sgx1 ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX2 support: %s\n",
-                   info->sgx2 ? "enabled" : "disabled");
-    monitor_printf(mon, "FLC support: %s\n",
-                   info->flc ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX support: %s\n",
+                       info->sgx ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
+                       info->sgx1 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
+                       info->sgx2 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "FLC support: %s\n",
+                       info->flc ? "enabled" : "disabled");
 
     section_list = info->sections;
     for (section = section_list; section; section = section->next) {
-        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
-                       section->value->node);
-        monitor_printf(mon, "size=%" PRIu64 "\n",
-                       section->value->size);
+        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
+                           section->value->node);
+        monitor_hmp_printf(hmp, "size=%" PRIu64 "\n",
+                           section->value->size);
         size += section->value->size;
     }
-    monitor_printf(mon, "total size=%" PRIu64 "\n",
-                   size);
+    monitor_hmp_printf(hmp, "total size=%" PRIu64 "\n",
+                       size);
 }
 
 bool check_sgx_support(void)
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ac2525b90fec..ffa76f83016b 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                   indent, "",
-                   object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
-                   memory_region_size(s->mmio));
+    monitor_hmp_printf(MONITOR_HMP(mon),
+                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                       indent, "",
+                       object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
+                       memory_region_size(s->mmio));
 }
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
index 6a7d76292f00..154cd32ed88b 100644
--- a/hw/misc/mos6522-stub.c
+++ b/hw/misc/mos6522-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU\n");
 }
diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp-cmds.c
index 6405ce26dd65..5099d59cc620 100644
--- a/hw/net/rocker/rocker-hmp-cmds.c
+++ b/hw/net/rocker/rocker-hmp-cmds.c
@@ -22,7 +22,6 @@
 
 void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_str(qdict, "name");
     RockerSwitch *rocker;
     Error *err = NULL;
@@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "name: %s\n", rocker->name);
-    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
-    monitor_printf(mon, "ports: %d\n", rocker->ports);
+    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
+    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
+    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
 
     qapi_free_RockerSwitch(rocker);
 }
 
 void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerPortList *list, *port;
     const char *name = qdict_get_str(qdict, "name");
     Error *err = NULL;
@@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "            ena/    speed/ auto\n");
-    monitor_printf(mon, "      port  link    duplex neg?\n");
+    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
+    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
 
     for (port = list; port; port = port->next) {
-        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
-                       port->value->name,
-                       port->value->enabled ? port->value->link_up ?
-                       "up" : "down" : "!ena",
-                       port->value->speed == 10000 ? "10G" : "??",
-                       port->value->duplex ? "FD" : "HD",
-                       port->value->autoneg ? "Yes" : "No");
+        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
+                           port->value->name,
+                           port->value->enabled ? port->value->link_up ?
+                           "up" : "down" : "!ena",
+                           port->value->speed == 10000 ? "10G" : "??",
+                           port->value->duplex ? "FD" : "HD",
+                           port->value->autoneg ? "Yes" : "No");
     }
 
     qapi_free_RockerPortList(list);
@@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaFlowList *list, *info;
     const char *name = qdict_get_str(qdict, "name");
     uint32_t tbl_id = qdict_get_try_int(qdict, "tbl_id", -1);
@@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
+    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
 
     for (info = list; info; info = info->next) {
         RockerOfDpaFlow *flow = info->value;
@@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         RockerOfDpaFlowAction *action = flow->action;
 
         if (flow->hits) {
-            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
-                           key->priority, key->tbl_id, flow->hits);
+            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
+                               key->priority, key->tbl_id, flow->hits);
         } else {
-            monitor_printf(mon, "%-4d %-3d     ",
-                           key->priority, key->tbl_id);
+            monitor_hmp_printf(hmp, "%-4d %-3d     ",
+                               key->priority, key->tbl_id);
         }
 
         if (key->has_in_pport) {
-            monitor_printf(mon, " pport %d", key->in_pport);
+            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
             if (mask->has_in_pport) {
-                monitor_printf(mon, "(0x%x)", mask->in_pport);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
             }
         }
 
         if (key->has_vlan_id) {
-            monitor_printf(mon, " vlan %d",
-                           key->vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " vlan %d",
+                               key->vlan_id & VLAN_VID_MASK);
             if (mask->has_vlan_id) {
-                monitor_printf(mon, "(0x%x)", mask->vlan_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
             }
         }
 
         if (key->has_tunnel_id) {
-            monitor_printf(mon, " tunnel %d", key->tunnel_id);
+            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
             if (mask->has_tunnel_id) {
-                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
             }
         }
 
         if (key->has_eth_type) {
             switch (key->eth_type) {
             case 0x0806:
-                monitor_printf(mon, " ARP");
+                monitor_hmp_printf(hmp, " ARP");
                 break;
             case 0x0800:
-                monitor_printf(mon, " IP");
+                monitor_hmp_printf(hmp, " IP");
                 break;
             case 0x86dd:
-                monitor_printf(mon, " IPv6");
+                monitor_hmp_printf(hmp, " IPv6");
                 break;
             case 0x8809:
-                monitor_printf(mon, " LACP");
+                monitor_hmp_printf(hmp, " LACP");
                 break;
             case 0x88cc:
-                monitor_printf(mon, " LLDP");
+                monitor_hmp_printf(hmp, " LLDP");
                 break;
             default:
-                monitor_printf(mon, " eth type 0x%04x", key->eth_type);
+                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_type);
                 break;
             }
         }
@@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_src, "01:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
             } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any ucast>");
+                monitor_hmp_printf(hmp, " src <any ucast>");
             } else {
-                monitor_printf(mon, " src %s", key->eth_src);
+                monitor_hmp_printf(hmp, " src %s", key->eth_src);
                 if (mask->eth_src) {
-                    monitor_printf(mon, "(%s)", mask->eth_src);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
                 }
             }
         }
@@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_dst, "01:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
             } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any ucast>");
+                monitor_hmp_printf(hmp, " dst <any ucast>");
             } else {
-                monitor_printf(mon, " dst %s", key->eth_dst);
+                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
                 if (mask->eth_dst) {
-                    monitor_printf(mon, "(%s)", mask->eth_dst);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
                 }
             }
         }
 
         if (key->has_ip_proto) {
-            monitor_printf(mon, " proto %d", key->ip_proto);
+            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
             if (mask->has_ip_proto) {
-                monitor_printf(mon, "(0x%x)", mask->ip_proto);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
             }
         }
 
         if (key->has_ip_tos) {
-            monitor_printf(mon, " TOS %d", key->ip_tos);
+            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
             if (mask->has_ip_tos) {
-                monitor_printf(mon, "(0x%x)", mask->ip_tos);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
             }
         }
 
         if (key->ip_dst) {
-            monitor_printf(mon, " dst %s", key->ip_dst);
+            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
         }
 
         if (action->has_goto_tbl || action->has_group_id ||
             action->has_new_vlan_id) {
-            monitor_printf(mon, " -->");
+            monitor_hmp_printf(hmp, " -->");
         }
 
         if (action->has_new_vlan_id) {
-            monitor_printf(mon, " apply new vlan %d",
-                           ntohs(action->new_vlan_id));
+            monitor_hmp_printf(hmp, " apply new vlan %d",
+                               ntohs(action->new_vlan_id));
         }
 
         if (action->has_group_id) {
-            monitor_printf(mon, " write group 0x%08x", action->group_id);
+            monitor_hmp_printf(hmp, " write group 0x%08x", action->group_id);
         }
 
         if (action->has_goto_tbl) {
-            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
+            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaFlowList(list);
@@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaGroupList *list, *g;
     const char *name = qdict_get_str(qdict, "name");
     uint8_t type = qdict_get_try_int(qdict, "type", 9);
@@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "id (decode) --> buckets\n");
+    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
 
     for (g = list; g; g = g->next) {
         RockerOfDpaGroup *group = g->value;
         bool set = false;
 
-        monitor_printf(mon, "0x%08x", group->id);
+        monitor_hmp_printf(hmp, "0x%08x", group->id);
 
-        monitor_printf(mon, " (type %s", group->type == 0 ? "L2 interface" :
+        monitor_hmp_printf(hmp, " (type %s", group->type == 0 ? "L2 interface" :
                                          group->type == 1 ? "L2 rewrite" :
                                          group->type == 2 ? "L3 unicast" :
                                          group->type == 3 ? "L2 multicast" :
@@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
                                          "unknown");
 
         if (group->has_vlan_id) {
-            monitor_printf(mon, " vlan %d", group->vlan_id);
+            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
         }
 
         if (group->has_pport) {
-            monitor_printf(mon, " pport %d", group->pport);
+            monitor_hmp_printf(hmp, " pport %d", group->pport);
         }
 
         if (group->has_index) {
-            monitor_printf(mon, " index %d", group->index);
+            monitor_hmp_printf(hmp, " index %d", group->index);
         }
 
-        monitor_printf(mon, ") -->");
+        monitor_hmp_printf(hmp, ") -->");
 
         if (group->has_set_vlan_id && group->set_vlan_id) {
             set = true;
-            monitor_printf(mon, " set vlan %d",
-                           group->set_vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " set vlan %d",
+                               group->set_vlan_id & VLAN_VID_MASK);
         }
 
         if (group->set_eth_src) {
             if (!set) {
                 set = true;
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " src %s", group->set_eth_src);
+            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
         }
 
         if (group->set_eth_dst) {
             if (!set) {
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " dst %s", group->set_eth_dst);
+            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
         }
 
         if (group->has_ttl_check && group->ttl_check) {
-            monitor_printf(mon, " check TTL");
+            monitor_hmp_printf(hmp, " check TTL");
         }
 
         if (group->has_group_id && group->group_id) {
-            monitor_printf(mon, " group id 0x%08x", group->group_id);
+            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_id);
         }
 
         if (group->has_pop_vlan && group->pop_vlan) {
-            monitor_printf(mon, " pop vlan");
+            monitor_hmp_printf(hmp, " pop vlan");
         }
 
         if (group->has_out_pport) {
-            monitor_printf(mon, " out pport %d", group->out_pport);
+            monitor_hmp_printf(hmp, " out pport %d", group->out_pport);
         }
 
         if (group->has_group_ids) {
             struct uint32List *id;
 
-            monitor_printf(mon, " groups [");
+            monitor_hmp_printf(hmp, " groups [");
             for (id = group->group_ids; id; id = id->next) {
-                monitor_printf(mon, "0x%08x", id->value);
+                monitor_hmp_printf(hmp, "0x%08x", id->value);
                 if (id->next) {
-                    monitor_printf(mon, ",");
+                    monitor_hmp_printf(hmp, ",");
                 }
             }
-            monitor_printf(mon, "]");
+            monitor_hmp_printf(hmp, "]");
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaGroupList(list);
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 51d95d76620e..500f821246a9 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -24,54 +24,55 @@
 #include "qapi/qapi-commands-pci.h"
 #include "qemu/cutils.h"
 
-static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
+static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *dev)
 {
+    Monitor *mon = MONITOR(hmp);
     PciMemoryRegionList *region;
 
-    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
-    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n",
-                   dev->slot, dev->function);
-    monitor_printf(mon, "    ");
+    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
+    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 ":\n",
+                       dev->slot, dev->function);
+    monitor_hmp_printf(hmp, "    ");
 
     if (dev->class_info->desc) {
         monitor_puts(mon, dev->class_info->desc);
     } else {
-        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_class);
+        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q_class);
     }
 
-    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
-                   dev->id->vendor, dev->id->device);
+    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
+                       dev->id->vendor, dev->id->device);
     if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
-        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
-                       dev->id->subsystem_vendor, dev->id->subsystem);
+        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
+                           dev->id->subsystem_vendor, dev->id->subsystem);
     }
 
     if (dev->has_irq) {
-        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
-                       dev->irq, (char)('A' + dev->irq_pin - 1));
+        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
+                           dev->irq, (char)('A' + dev->irq_pin - 1));
     }
 
     if (dev->pci_bridge) {
-        monitor_printf(mon, "      BUS %" PRId64 ".\n",
-                       dev->pci_bridge->bus->number);
-        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->secondary);
-        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->subordinate);
+        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
+                           dev->pci_bridge->bus->number);
+        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->secondary);
+        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->subordinate);
 
-        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
-                       dev->pci_bridge->bus->io_range->base,
-                       dev->pci_bridge->bus->io_range->limit);
+        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
+                           dev->pci_bridge->bus->io_range->base,
+                           dev->pci_bridge->bus->io_range->limit);
 
-        monitor_printf(mon,
-                       "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->memory_range->base,
-                       dev->pci_bridge->bus->memory_range->limit);
+        monitor_hmp_printf(hmp,
+                           "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->memory_range->base,
+                           dev->pci_bridge->bus->memory_range->limit);
 
-        monitor_printf(mon, "      prefetchable memory range "
-                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->prefetchable_range->base,
-                       dev->pci_bridge->bus->prefetchable_range->limit);
+        monitor_hmp_printf(hmp, "      prefetchable memory range "
+                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->prefetchable_range->base,
+                           dev->pci_bridge->bus->prefetchable_range->limit);
     }
 
     for (region = dev->regions; region; region = region->next) {
@@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
         addr = region->value->address;
         size = region->value->size;
 
-        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->bar);
+        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->value->bar);
 
         if (!strcmp(region->value->type, "io")) {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "I/O at 0x%04" PRIx64
+                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
                                     " [0x%04" PRIx64 "]\n",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "I/O (not mapped)\n");
+                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
             }
         } else {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
+                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRIx64
                                    " [0x%08" PRIx64 "]\n",
                                region->value->mem_type_64 ? 64 : 32,
                                region->value->prefetch ? " prefetchable" : "",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
-                               region->value->mem_type_64 ? 64 : 32,
-                               region->value->prefetch ? " prefetchable" : "");
+                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\n",
+                                   region->value->mem_type_64 ? 64 : 32,
+                                   region->value->prefetch ? " prefetchable" : "");
             }
         }
     }
 
-    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
+    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
 
     if (dev->pci_bridge) {
         if (dev->pci_bridge->has_devices) {
             PciDeviceInfoList *cdev;
             for (cdev = dev->pci_bridge->devices; cdev; cdev = cdev->next) {
-                hmp_info_pci_device(mon, cdev->value);
+                hmp_info_pci_device(hmp, cdev->value);
             }
         }
     }
@@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
 
 void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     PciInfoList *info_list, *info;
 
     info_list = qmp_query_pci(&error_abort);
@@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
         PciDeviceInfoList *dev;
 
         for (dev = info->value->devices; dev; dev = dev->next) {
-            hmp_info_pci_device(mon, dev->value);
+            hmp_info_pci_device(hmp, dev->value);
         }
     }
 
@@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
@@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
         snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
     }
 
-    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
-                   "pci id %04x:%04x (sub %04x:%04x)\n",
-                   indent, "", ctxt, pci_dev_bus_num(d),
-                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                   pci_get_word(d->config + PCI_VENDOR_ID),
-                   pci_get_word(d->config + PCI_DEVICE_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
+    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
+                       "pci id %04x:%04x (sub %04x:%04x)\n",
+                       indent, "", ctxt, pci_dev_bus_num(d),
+                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+                       pci_get_word(d->config + PCI_VENDOR_ID),
+                       pci_get_word(d->config + PCI_DEVICE_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
         if (!r->size) {
             continue;
         }
-        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
-                       " [0x%"FMT_PCIBUS"]\n",
-                       indent, "",
-                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
-                       r->addr, r->addr + r->size - 1);
+        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
+                           " [0x%"FMT_PCIBUS"]\n",
+                           indent, "",
+                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
+                           r->addr, r->addr + r->size - 1);
     }
 }
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *id = qdict_get_str(qdict, "id");
     const char *error_name;
@@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
     }
 
 
-    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
-                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
-                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
+                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
+                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
 
 out:
     hmp_handle_error(hmp, err);
diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
index a80e34175462..7e2797300ba0 100644
--- a/hw/pci/pci-stub.c
+++ b/hw/pci/pci-stub.c
@@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "PCI devices not supported\n");
+    monitor_hmp_printf(hmp, "PCI devices not supported\n");
 }
 
 /* kvm-all wants this */
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index d8afaf730639..b5e56a16cce1 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
 
 void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390SKeysState *ss = s390_get_skeys_device();
     S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 
     /* Quick check to see if guest is using storage keys*/
     if (!skeyclass->skeys_are_enabled(ss)) {
-        monitor_printf(mon, "Error: This guest is not using storage keys\n");
+        monitor_hmp_printf(hmp, "Error: This guest is not using storage keys\n");
         return;
     }
 
     if (!address_space_access_valid(&address_space_memory,
                                     addr & TARGET_PAGE_MASK, TARGET_PAGE_SIZE,
                                     false, MEMTXATTRS_UNSPECIFIED)) {
-        monitor_printf(mon, "Error: The given address is not valid\n");
+        monitor_hmp_printf(hmp, "Error: The given address is not valid\n");
         return;
     }
 
     r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s\n", strerror(-r));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
         return;
     }
 
-    monitor_printf(mon, "  key: 0x%X\n", key);
+    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
 }
 
 void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index b4a405455901..644298f7f0b2 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -61,7 +61,6 @@ void s390_stattrib_init(void)
 
 void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t what = qdict_get_int(qdict, "mode");
@@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 
     r = sac->set_migrationmode(sas, what, &local_err);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
+        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_err));
         error_free(local_err);
     }
 }
 
 void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 
     vals = g_try_malloc(buflen);
     if (!vals) {
-        monitor_printf(mon, "Error: %s\n", strerror(errno));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
         return;
     }
 
     len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
     if (len < 0) {
-        monitor_printf(mon, "Error: %s", strerror(-len));
+        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
         goto out;
     }
 
-    monitor_printf(mon, "  CMMA attributes, "
-                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
-                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
+    monitor_hmp_printf(hmp, "  CMMA attributes, "
+                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
+                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
     for (cx = 0; cx < len; cx++) {
         if (cx % 8 == 7) {
-            monitor_printf(mon, "%02x\n", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
         } else {
-            monitor_printf(mon, "%02x", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x", vals[cx]);
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
 out:
     g_free(vals);
diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
index 0d59a74ad60e..0249eea2cfe9 100644
--- a/hw/uefi/ovmf-log.c
+++ b/hw/uefi/ovmf-log.c
@@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_size, uint64_t max_size,
 
 void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autofree gchar *log_esc = NULL;
     g_autofree guchar *log_out = NULL;
     Error *err = NULL;
@@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 
     if (log->version) {
         g_autofree gchar *esc = g_strescape(log->version, NULL);
-        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
+        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
     }
 
     log_out = g_base64_decode(log->log, &log_len);
     log_esc = g_strescape((gchar *)log_out, "\r\n");
-    monitor_printf(mon, "%s\n", log_esc);
+    monitor_hmp_printf(hmp, "%s\n", log_esc);
 }
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 9b9b2e7c2f8f..fe3dbfa2227c 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
 
 static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
-    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
-                   indent, "", bus->busnr, dev->addr,
-                   dev->port ? dev->port->path : "-",
-                   usb_speed(dev->speed), dev->product_desc,
-                   dev->attached ? ", attached" : "");
+    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
+                       indent, "", bus->busnr, dev->addr,
+                       dev->port ? dev->port->path : "-",
+                       usb_speed(dev->speed), dev->product_desc,
+                       dev->attached ? ", attached" : "");
 }
 
 static char *usb_get_dev_path(DeviceState *qdev)
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index c02343d3a655..9b9f26a1078e 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
 
 void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     libusb_device **devs = NULL;
     struct libusb_device_descriptor ddesc;
     char port[16];
@@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
         usb_host_get_port(devs[i], port, sizeof(port));
-        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
-                       libusb_get_bus_number(devs[i]),
-                       libusb_get_device_address(devs[i]),
-                       port,
-                       speed_name[libusb_get_device_speed(devs[i])]);
-        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
-        monitor_printf(mon, " USB device %04x:%04x",
-                       ddesc.idVendor, ddesc.idProduct);
+        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
+                           libusb_get_bus_number(devs[i]),
+                           libusb_get_device_address(devs[i]),
+                           port,
+                           speed_name[libusb_get_device_speed(devs[i])]);
+        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass);
+        monitor_hmp_printf(hmp, " USB device %04x:%04x",
+                           ddesc.idVendor, ddesc.idProduct);
         if (ddesc.iProduct) {
             libusb_device_handle *handle;
             if (libusb_open(devs[i], &handle) == 0) {
@@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
                                                    ddesc.iProduct,
                                                    name, sizeof(name));
                 libusb_close(handle);
-                monitor_printf(mon, ", %s", name);
+                monitor_hmp_printf(hmp, ", %s", name);
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
     libusb_free_device_list(devs, 1);
 }
diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
index fb36c8b9274c..e5da6f00699d 100644
--- a/hw/virtio/virtio-hmp-cmds.c
+++ b/hw/virtio/virtio-hmp-cmds.c
@@ -12,77 +12,76 @@
 #include "qobject/qdict.h"
 
 
-static void hmp_virtio_dump_protocols(Monitor *mon,
+static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
                                       VhostDeviceProtocols *pcol)
 {
     strList *pcol_list = pcol->protocols;
     while (pcol_list) {
-        monitor_printf(mon, "\t%s", pcol_list->value);
+        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
         pcol_list = pcol_list->next;
         if (pcol_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (pcol->has_unknown_protocols) {
-        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
-                       pcol->unknown_protocols);
+        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n",
+                           pcol->unknown_protocols);
     }
 }
 
-static void hmp_virtio_dump_status(Monitor *mon,
+static void hmp_virtio_dump_status(MonitorHMP *hmp,
                                    VirtioDeviceStatus *status)
 {
     strList *status_list = status->statuses;
     while (status_list) {
-        monitor_printf(mon, "\t%s", status_list->value);
+        monitor_hmp_printf(hmp, "\t%s", status_list->value);
         status_list = status_list->next;
         if (status_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (status->has_unknown_statuses) {
-        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
-                       status->unknown_statuses);
+        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n",
+                           status->unknown_statuses);
     }
 }
 
-static void hmp_virtio_dump_features(Monitor *mon,
+static void hmp_virtio_dump_features(MonitorHMP *hmp,
                                      VirtioDeviceFeatures *features)
 {
     strList *transport_list = features->transports;
     while (transport_list) {
-        monitor_printf(mon, "\t%s", transport_list->value);
+        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
         transport_list = transport_list->next;
         if (transport_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     strList *list = features->dev_features;
     if (list) {
         while (list) {
-            monitor_printf(mon, "\t%s", list->value);
+            monitor_hmp_printf(hmp, "\t%s", list->value);
             list = list->next;
             if (list != NULL) {
-                monitor_printf(mon, ",\n");
+                monitor_hmp_printf(hmp, ",\n");
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (features->has_unknown_dev_features) {
-        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
-                       features->unknown_dev_features2,
-                       features->unknown_dev_features);
+        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
+                           features->unknown_dev_features2,
+                           features->unknown_dev_features);
     }
 }
 
 void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     VirtioInfoList *list = qmp_x_query_virtio(&err);
     VirtioInfoList *node;
@@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (list == NULL) {
-        monitor_printf(mon, "No VirtIO devices\n");
+        monitor_hmp_printf(hmp, "No VirtIO devices\n");
         return;
     }
 
     node = list;
     while (node) {
-        monitor_printf(mon, "%s [%s]\n", node->value->path,
-                       node->value->name);
+        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
+                           node->value->name);
         node = node->next;
     }
     qapi_free_VirtioInfoList(list);
@@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     VirtioStatus *s = qmp_x_query_virtio_status(path, &err);
@@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:             %s %s\n",
-                   s->name, s->vhost_dev ? "(vhost)" : "");
-    monitor_printf(mon, "  device_id:               %d\n", s->device_id);
-    monitor_printf(mon, "  vhost_started:           %s\n",
-                   s->vhost_started ? "true" : "false");
-    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name);
-    monitor_printf(mon, "  broken:                  %s\n",
-                   s->broken ? "true" : "false");
-    monitor_printf(mon, "  disabled:                %s\n",
-                   s->disabled ? "true" : "false");
-    monitor_printf(mon, "  disable_legacy_check:    %s\n",
-                   s->disable_legacy_check ? "true" : "false");
-    monitor_printf(mon, "  started:                 %s\n",
-                   s->started ? "true" : "false");
-    monitor_printf(mon, "  use_started:             %s\n",
-                   s->use_started ? "true" : "false");
-    monitor_printf(mon, "  start_on_kick:           %s\n",
-                   s->start_on_kick ? "true" : "false");
-    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
-                   s->use_guest_notifier_mask ? "true" : "false");
-    monitor_printf(mon, "  vm_running:              %s\n",
-                   s->vm_running ? "true" : "false");
-    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
-    monitor_printf(mon, "  queue_sel:               %d\n",
-                   s->queue_sel);
-    monitor_printf(mon, "  isr:                     %d\n", s->isr);
-    monitor_printf(mon, "  endianness:              %s\n",
-                   s->device_endian);
-    monitor_printf(mon, "  status:\n");
-    hmp_virtio_dump_status(mon, s->status);
-    monitor_printf(mon, "  Guest features:\n");
-    hmp_virtio_dump_features(mon, s->guest_features);
-    monitor_printf(mon, "  Host features:\n");
-    hmp_virtio_dump_features(mon, s->host_features);
-    monitor_printf(mon, "  Backend features:\n");
-    hmp_virtio_dump_features(mon, s->backend_features);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
+                       s->name, s->vhost_dev ? "(vhost)" : "");
+    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->device_id);
+    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
+                       s->vhost_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_name);
+    monitor_hmp_printf(hmp, "  broken:                  %s\n",
+                       s->broken ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disabled:                %s\n",
+                       s->disabled ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
+                       s->disable_legacy_check ? "true" : "false");
+    monitor_hmp_printf(hmp, "  started:                 %s\n",
+                       s->started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_started:             %s\n",
+                       s->use_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
+                       s->start_on_kick ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
+                       s->use_guest_notifier_mask ? "true" : "false");
+    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
+                       s->vm_running ? "true" : "false");
+    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
+    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
+                       s->queue_sel);
+    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr);
+    monitor_hmp_printf(hmp, "  endianness:              %s\n",
+                       s->device_endian);
+    monitor_hmp_printf(hmp, "  status:\n");
+    hmp_virtio_dump_status(hmp, s->status);
+    monitor_hmp_printf(hmp, "  Guest features:\n");
+    hmp_virtio_dump_features(hmp, s->guest_features);
+    monitor_hmp_printf(hmp, "  Host features:\n");
+    hmp_virtio_dump_features(hmp, s->host_features);
+    monitor_hmp_printf(hmp, "  Backend features:\n");
+    hmp_virtio_dump_features(hmp, s->backend_features);
 
     if (s->vhost_dev) {
-        monitor_printf(mon, "  VHost:\n");
-        monitor_printf(mon, "    nvqs:           %d\n",
-                       s->vhost_dev->nvqs);
-        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
-                       s->vhost_dev->vq_index);
-        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
-                       s->vhost_dev->max_queues);
-        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
-                       s->vhost_dev->n_mem_sections);
-        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
-                       s->vhost_dev->n_tmp_sections);
-        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
-                       s->vhost_dev->backend_cap);
-        monitor_printf(mon, "    log_enabled:    %s\n",
-                       s->vhost_dev->log_enabled ? "true" : "false");
-        monitor_printf(mon, "    log_size:       %"PRId64"\n",
-                       s->vhost_dev->log_size);
-        monitor_printf(mon, "    Features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->features);
-        monitor_printf(mon, "    Acked features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
-        monitor_printf(mon, "    Protocol features:\n");
-        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features);
+        monitor_hmp_printf(hmp, "  VHost:\n");
+        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
+                           s->vhost_dev->nvqs);
+        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
+                           s->vhost_dev->vq_index);
+        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
+                           s->vhost_dev->max_queues);
+        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
+                           s->vhost_dev->n_mem_sections);
+        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
+                           s->vhost_dev->n_tmp_sections);
+        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
+                           s->vhost_dev->backend_cap);
+        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
+                           s->vhost_dev->log_enabled ? "true" : "false");
+        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
+                           s->vhost_dev->log_size);
+        monitor_hmp_printf(hmp, "    Features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
+        monitor_hmp_printf(hmp, "    Acked features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
+        monitor_hmp_printf(hmp, "    Protocol features:\n");
+        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features);
     }
 
     qapi_free_VirtioStatus(s);
@@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s (vhost)\n",
-                   s->name);
-    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick);
-    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call);
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
-    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
-                   s->desc_phys);
-    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
-    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
-                   s->avail_phys);
-    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size);
-    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
-                   s->used_phys);
-    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
+                       s->name);
+    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->kick);
+    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->call);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
+    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
+                       s->desc_phys);
+    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_size);
+    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
+                       s->avail_phys);
+    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_size);
+    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
+                       s->used_phys);
+    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_size);
 
     qapi_free_VirtVhostQueueStatus(s);
 }
 
 void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s\n", s->name);
-    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index);
-    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
-    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
-    monitor_printf(mon, "  signalled_used:       %d\n",
-                   s->signalled_used);
-    monitor_printf(mon, "  signalled_used_valid: %s\n",
-                   s->signalled_used_valid ? "true" : "false");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
+    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_index);
+    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
+    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_idx);
+    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
+                       s->signalled_used);
+    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
+                       s->signalled_used_valid ? "true" : "false");
     if (s->has_last_avail_idx) {
-        monitor_printf(mon, "  last_avail_idx:       %d\n",
-                       s->last_avail_idx);
+        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
+                           s->last_avail_idx);
     }
     if (s->has_shadow_avail_idx) {
-        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
-                       s->shadow_avail_idx);
+        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
+                           s->shadow_avail_idx);
     }
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num);
-    monitor_printf(mon, "    num_default:  %"PRId32"\n",
-                   s->vring_num_default);
-    monitor_printf(mon, "    align:        %"PRId32"\n",
-                   s->vring_align);
-    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
-                   s->vring_desc);
-    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
-                   s->vring_avail);
-    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
-                   s->vring_used);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_num);
+    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
+                       s->vring_num_default);
+    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
+                       s->vring_align);
+    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
+                       s->vring_desc);
+    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
+                       s->vring_avail);
+    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
+                       s->vring_used);
 
     qapi_free_VirtQueueStatus(s);
 }
 
 void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name: %s\n", e->name);
-    monitor_printf(mon, "  index:   %d\n", e->index);
-    monitor_printf(mon, "  desc:\n");
-    monitor_printf(mon, "    descs:\n");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
+    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
+    monitor_hmp_printf(hmp, "  desc:\n");
+    monitor_hmp_printf(hmp, "    descs:\n");
 
     list = e->descs;
     while (list) {
-        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
-                       list->value->addr, list->value->len);
+        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
+                           list->value->addr, list->value->len);
         if (list->value->flags) {
             strList *flag = list->value->flags;
-            monitor_printf(mon, " (");
+            monitor_hmp_printf(hmp, " (");
             while (flag) {
-                monitor_printf(mon, "%s", flag->value);
+                monitor_hmp_printf(hmp, "%s", flag->value);
                 flag = flag->next;
                 if (flag) {
-                    monitor_printf(mon, ", ");
+                    monitor_hmp_printf(hmp, ", ");
                 }
             }
-            monitor_printf(mon, ")");
+            monitor_hmp_printf(hmp, ")");
         }
         list = list->next;
         if (list) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
-    monitor_printf(mon, "  avail:\n");
-    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
-    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
-    monitor_printf(mon, "  used:\n");
-    monitor_printf(mon, "    flags: %d\n", e->used->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
+    monitor_hmp_printf(hmp, "\n");
+    monitor_hmp_printf(hmp, "  avail:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
+    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
+    monitor_hmp_printf(hmp, "  used:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
 
     qapi_free_VirtioQueueElement(e);
 }
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index a563f6066bb4..4075b5b001ae 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -103,10 +103,11 @@ abort:
 
 static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
-    monitor_printf(mon, "%*sname = '%s' frontend_id = %u\n",
-                   indent, "", xendev->name, xendev->frontend_id);
+    monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
+                       indent, "", xendev->name, xendev->frontend_id);
 }
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
diff --git a/include/disas/disas.h b/include/disas/disas.h
index c702b1effc1c..47daa9b4d2df 100644
--- a/include/disas/disas.h
+++ b/include/disas/disas.h
@@ -1,13 +1,15 @@
 #ifndef QEMU_DISAS_H
 #define QEMU_DISAS_H
 
+#include "monitor/hmp.h"
+
 /* Disassemble this for me please... (debugging). */
 #ifdef CONFIG_TCG
 void disas(FILE *out, const void *code, size_t size);
 void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db);
 #endif
 
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical);
 
 #ifdef CONFIG_PLUGIN
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 3fd17048b319..f10bf83df86d 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *chardev_id,
 
 MonitorHMP *monitor_cur_hmp(void);
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
     G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_hmp_printc(MonitorHMP *mon, int ch);
 
 void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
 int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
@@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
 int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
 
 bool hmp_handle_error(MonitorHMP *hmp, Error *err);
-void hmp_help_cmd(Monitor *mon, const char *name);
+void hmp_help_cmd(MonitorHMP *hmp, const char *name);
 strList *hmp_split_at_comma(const char *str);
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
@@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_change(MonitorHMP *hmp, const QDict *qdict);
 #ifdef CONFIG_VNC
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp);
 #endif
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp);
 void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 3c0931796ce2..bdbb2aaa99db 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool has_calc_time_unit,
 
 void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyRateInfo *info = query_dirty_rate_info(TIME_UNIT_SECOND);
 
-    monitor_printf(mon, "Status: %s\n",
-                   DirtyRateStatus_str(info->status));
-    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
-                   info->start_time);
+    monitor_hmp_printf(hmp, "Status: %s\n",
+                       DirtyRateStatus_str(info->status));
+    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
+                       info->start_time);
     if (info->mode == DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
-        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
-                       info->sample_pages);
+        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
+                           info->sample_pages);
     }
-    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
-                   info->calc_time);
-    monitor_printf(mon, "Mode: %s\n",
-                   DirtyRateMeasureMode_str(info->mode));
-    monitor_printf(mon, "Dirty rate: ");
+    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
+                       info->calc_time);
+    monitor_hmp_printf(hmp, "Mode: %s\n",
+                       DirtyRateMeasureMode_str(info->mode));
+    monitor_hmp_printf(hmp, "Dirty rate: ");
     if (info->has_dirty_rate) {
-        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
+        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate);
         if (info->has_vcpu_dirty_rate) {
             DirtyRateVcpuList *rate, *head = info->vcpu_dirty_rate;
             for (rate = head; rate != NULL; rate = rate->next) {
-                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
-                               " (MB/s)\n", rate->value->id,
-                               rate->value->dirty_rate);
+                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
+                                   " (MB/s)\n", rate->value->id,
+                                   rate->value->dirty_rate);
             }
         }
     } else {
-        monitor_printf(mon, "(not ready)\n");
+        monitor_hmp_printf(hmp, "(not ready)\n");
     }
 
     qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
@@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t sec = qdict_get_try_int(qdict, "second", 0);
     int64_t sample_pages = qdict_get_try_int(qdict, "sample_pages_per_GB", -1);
     bool has_sample_pages = (sample_pages != -1);
@@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
     Error *err = NULL;
 
     if (!sec) {
-        monitor_printf(mon, "Incorrect period length specified!\n");
+        monitor_hmp_printf(hmp, "Incorrect period length specified!\n");
         return;
     }
 
     if (dirty_ring && dirty_bitmap) {
-        monitor_printf(mon, "Either dirty ring or dirty bitmap "
-                       "can be specified!\n");
+        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
+                           "can be specified!\n");
         return;
     }
 
@@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Starting dirty rate measurement with period %"PRIi64
-                   " seconds\n", sec);
-    monitor_printf(mon, "[Please use 'info dirty_rate' to check results]\n");
+    monitor_hmp_printf(hmp, "Starting dirty rate measurement with period %"PRIi64
+                       " seconds\n", sec);
+    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check results]\n");
 }
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index 73a974259478..6fe189471899 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -36,23 +36,23 @@
 #include "options.h"
 #include "migration.h"
 
-static void migration_global_dump(Monitor *mon)
+static void migration_global_dump(MonitorHMP *hmp)
 {
     MigrationState *ms = migrate_get_current();
 
-    monitor_printf(mon, "Globals:\n");
-    monitor_printf(mon, "  store-global-state: %s\n",
-                   ms->store_global_state ? "on" : "off");
-    monitor_printf(mon, "  only-migratable: %s\n",
-                   only_migratable ? "on" : "off");
-    monitor_printf(mon, "  send-configuration: %s\n",
-                   ms->send_configuration ? "on" : "off");
-    monitor_printf(mon, "  send-section-footer: %s\n",
-                   ms->send_section_footer ? "on" : "off");
-    monitor_printf(mon, "  send-switchover-start: %s\n",
-                   ms->send_switchover_start ? "on" : "off");
-    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
-                   ms->clear_bitmap_shift);
+    monitor_hmp_printf(hmp, "Globals:\n");
+    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
+                       ms->store_global_state ? "on" : "off");
+    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
+                       only_migratable ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
+                       ms->send_configuration ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
+                       ms->send_section_footer ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
+                       ms->send_switchover_start ? "on" : "off");
+    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
+                       ms->clear_bitmap_shift);
 }
 
 static const gchar *format_time_str(uint64_t us)
@@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
     return g_strdup_printf("%"PRIu64" %s", us, units[index]);
 }
 
-static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
+static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *info)
 {
     if (info->has_postcopy_blocktime) {
-        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
-                       info->postcopy_blocktime);
+        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\n",
+                           info->postcopy_blocktime);
     }
 
     if (info->has_postcopy_vcpu_blocktime) {
@@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency) {
-        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_latency);
+        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_latency);
     }
 
     if (info->has_postcopy_non_vcpu_latency) {
-        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_non_vcpu_latency);
+        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_non_vcpu_latency);
     }
 
     if (info->has_postcopy_vcpu_latency) {
@@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency_dist) {
         uint64List *item = info->postcopy_latency_dist;
         int count = 0;
 
-        monitor_printf(mon, "Postcopy Latency Distribution:\n");
+        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
 
         while (item) {
             g_autofree const gchar *from = format_time_str(1UL << count);
             g_autofree const gchar *to = format_time_str(1UL << (count + 1));
 
-            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
-                           from, to, item->value);
+            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
+                               from, to, item->value);
             item = item->next;
             count++;
         }
@@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
 
 void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool show_all = qdict_get_try_bool(qdict, "all", false);
     MigrationInfo *info;
 
@@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 
     if (info->blocked_reasons) {
         strList *reasons = info->blocked_reasons;
-        monitor_printf(mon, "Outgoing migration blocked:\n");
+        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
         while (reasons) {
-            monitor_printf(mon, "  %s\n", reasons->value);
+            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
             reasons = reasons->next;
         }
     }
 
     if (info->has_status) {
-        monitor_printf(mon, "Status: \t\t%s",
-                       MigrationStatus_str(info->status));
+        monitor_hmp_printf(hmp, "Status: \t\t%s",
+                           MigrationStatus_str(info->status));
         if ((info->status == MIGRATION_STATUS_FAILED ||
              info->status == MIGRATION_STATUS_POSTCOPY_PAUSED) &&
             info->error_desc) {
-            monitor_printf(mon, " (%s)\n", info->error_desc);
+            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
         } else {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
         if (info->total_time) {
-            monitor_printf(mon, "Time (ms): \t\ttotal=%" PRIu64,
-                           info->total_time);
+            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=%" PRIu64,
+                               info->total_time);
             if (info->has_setup_time) {
-                monitor_printf(mon, ", setup=%" PRIu64,
-                               info->setup_time);
+                monitor_hmp_printf(hmp, ", setup=%" PRIu64,
+                                   info->setup_time);
             }
             if (info->has_expected_downtime) {
-                monitor_printf(mon, ", exp_down=%" PRIu64,
-                               info->expected_downtime);
+                monitor_hmp_printf(hmp, ", exp_down=%" PRIu64,
+                                   info->expected_downtime);
             }
             if (info->has_downtime) {
-                monitor_printf(mon, ", down=%" PRIu64,
-                               info->downtime);
+                monitor_hmp_printf(hmp, ", down=%" PRIu64,
+                                   info->downtime);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
     if (info->has_remaining) {
         g_autofree char *remaining = size_to_str(info->remaining);
-        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
+        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
     }
 
     if (info->has_socket_address) {
         SocketAddressList *addr;
 
-        monitor_printf(mon, "Sockets: [\n");
+        monitor_hmp_printf(hmp, "Sockets: [\n");
 
         for (addr = info->socket_address; addr; addr = addr->next) {
             char *s = socket_uri(addr->value);
-            monitor_printf(mon, "\t%s\n", s);
+            monitor_hmp_printf(hmp, "\t%s\n", s);
             g_free(s);
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->ram) {
@@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
         g_autofree char *str_multifd = size_to_str(info->ram->multifd_bytes);
         g_autofree char *str_postcopy = size_to_str(info->ram->postcopy_bytes);
 
-        monitor_printf(mon, "RAM info:\n");
-        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
-                       info->ram->mbps);
-        monitor_printf(mon, "  Sizes: \t\tpagesize=%s, total=%s\n",
-                       str_psize, str_total);
-        monitor_printf(mon, "  Transfers: \t\ttransferred=%s, remain=%s\n",
-                       str_transferred, str_remaining);
-        monitor_printf(mon, "    Channels: \t\tprecopy=%s, "
-                       "multifd=%s, postcopy=%s",
-                       str_precopy, str_multifd, str_postcopy);
+        monitor_hmp_printf(hmp, "RAM info:\n");
+        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
+                           info->ram->mbps);
+        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=%s, total=%s\n",
+                           str_psize, str_total);
+        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=%s, remain=%s\n",
+                           str_transferred, str_remaining);
+        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=%s, "
+                           "multifd=%s, postcopy=%s",
+                           str_precopy, str_multifd, str_postcopy);
 
         if (info->vfio) {
             g_autofree char *str_vfio = size_to_str(info->vfio->transferred);
 
-            monitor_printf(mon, ", vfio=%s", str_vfio);
+            monitor_hmp_printf(hmp, ", vfio=%s", str_vfio);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "    Page Types: \tnormal=%" PRIu64
-                       ", zero=%" PRIu64 "\n",
-                       info->ram->normal, info->ram->duplicate);
-        monitor_printf(mon, "  Page Rates (pps): \ttransfer=%" PRIu64,
-                       info->ram->pages_per_second);
+        monitor_hmp_printf(hmp, "    Page Types: \tnormal=%" PRIu64
+                           ", zero=%" PRIu64 "\n",
+                           info->ram->normal, info->ram->duplicate);
+        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=%" PRIu64,
+                           info->ram->pages_per_second);
         if (info->ram->dirty_pages_rate) {
-            monitor_printf(mon, ", dirty=%" PRIu64,
-                           info->ram->dirty_pages_rate);
+            monitor_hmp_printf(hmp, ", dirty=%" PRIu64,
+                               info->ram->dirty_pages_rate);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "  Others: \t\tdirty_syncs=%" PRIu64,
-                       info->ram->dirty_sync_count);
+        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=%" PRIu64,
+                           info->ram->dirty_sync_count);
         if (info->ram->postcopy_requests) {
-            monitor_printf(mon, ", postcopy_req=%" PRIu64,
-                           info->ram->postcopy_requests);
+            monitor_hmp_printf(hmp, ", postcopy_req=%" PRIu64,
+                               info->ram->postcopy_requests);
         }
         if (info->ram->downtime_bytes) {
-            monitor_printf(mon, ", downtime_bytes=%" PRIu64,
-                           info->ram->downtime_bytes);
+            monitor_hmp_printf(hmp, ", downtime_bytes=%" PRIu64,
+                               info->ram->downtime_bytes);
         }
         if (info->ram->dirty_sync_missed_zero_copy) {
-            monitor_printf(mon, ", zerocopy_fallbacks=%" PRIu64,
-                           info->ram->dirty_sync_missed_zero_copy);
+            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=%" PRIu64,
+                               info->ram->dirty_sync_missed_zero_copy);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (!show_all) {
         goto out;
     }
 
-    migration_global_dump(mon);
+    migration_global_dump(hmp);
 
     if (info->xbzrle_cache) {
-        monitor_printf(mon, "XBZRLE: size=%" PRIu64
-                       ", transferred=%" PRIu64
-                       ", pages=%" PRIu64
-                       ", miss=%" PRIu64 "\n"
-                       "  miss_rate=%0.2f"
-                       ", encode_rate=%0.2f"
-                       ", overflow=%" PRIu64 "\n",
-                       info->xbzrle_cache->cache_size,
-                       info->xbzrle_cache->bytes,
-                       info->xbzrle_cache->pages,
-                       info->xbzrle_cache->cache_miss,
-                       info->xbzrle_cache->cache_miss_rate,
-                       info->xbzrle_cache->encoding_rate,
-                       info->xbzrle_cache->overflow);
+        monitor_hmp_printf(hmp, "XBZRLE: size=%" PRIu64
+                           ", transferred=%" PRIu64
+                           ", pages=%" PRIu64
+                           ", miss=%" PRIu64 "\n"
+                           "  miss_rate=%0.2f"
+                           ", encode_rate=%0.2f"
+                           ", overflow=%" PRIu64 "\n",
+                           info->xbzrle_cache->cache_size,
+                           info->xbzrle_cache->bytes,
+                           info->xbzrle_cache->pages,
+                           info->xbzrle_cache->cache_miss,
+                           info->xbzrle_cache->cache_miss_rate,
+                           info->xbzrle_cache->encoding_rate,
+                           info->xbzrle_cache->overflow);
     }
 
     if (info->has_cpu_throttle_percentage) {
-        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
-                       info->cpu_throttle_percentage);
+        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
+                           info->cpu_throttle_percentage);
     }
 
     if (info->has_dirty_limit_throttle_time_per_round) {
-        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n",
-                       info->dirty_limit_throttle_time_per_round);
+        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 "\n",
+                           info->dirty_limit_throttle_time_per_round);
     }
 
     if (info->has_dirty_limit_ring_full_time) {
-        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
-                       info->dirty_limit_ring_full_time);
+        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
+                           info->dirty_limit_ring_full_time);
     }
 
-    migration_dump_blocktime(mon, info);
+    migration_dump_blocktime(hmp, info);
 out:
     qapi_free_MigrationInfo(info);
 }
 
 void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationCapabilityStatusList *caps, *cap;
 
     caps = qmp_query_migrate_capabilities(NULL);
 
     if (caps) {
         for (cap = caps; cap; cap = cap->next) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationCapability_str(cap->value->capability),
-                           cap->value->state ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationCapability_str(cap->value->capability),
+                               cap->value->state ? "on" : "off");
         }
     }
 
     qapi_free_MigrationCapabilityStatusList(caps);
 }
 
-static void monitor_print_cpr_exec_command(Monitor *mon, strList *args)
+static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *args)
 {
-    monitor_printf(mon, "%s:",
+    monitor_hmp_printf(hmp, "%s:",
         MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
 
     while (args) {
-        monitor_printf(mon, " %s", args->value);
+        monitor_hmp_printf(hmp, " %s", args->value);
         args = args->next;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationParameters *params;
     MigrationState *s = migrate_get_current();
 
     params = qmp_query_migrate_parameters(NULL);
 
     if (params) {
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIAL),
             params->announce_initial);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
             params->announce_max);
-        monitor_printf(mon, "%s: %" PRIu64 "\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS),
             params->announce_rounds);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
             params->announce_step);
         assert(params->has_throttle_trigger_threshold);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD),
             params->throttle_trigger_threshold);
         assert(params->has_cpu_throttle_initial);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
             params->cpu_throttle_initial);
         assert(params->has_cpu_throttle_increment);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
             params->cpu_throttle_increment);
         assert(params->has_cpu_throttle_tailslow);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW),
             params->cpu_throttle_tailslow ? "on" : "off");
         assert(params->has_max_cpu_throttle);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTLE),
             params->max_cpu_throttle);
         assert(params->tls_creds);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
                        params->tls_creds->u.s);
         assert(params->tls_hostname);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
                        params->tls_hostname->u.s);
         assert(params->tls_authz);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
                        params->tls_authz->u.s);
         assert(params->has_max_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
             params->max_bandwidth);
         assert(params->has_avail_switchover_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVER_BANDWIDTH),
             params->avail_switchover_bandwidth);
         assert(params->has_max_postcopy_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH),
             params->max_postcopy_bandwidth);
         assert(params->has_downtime_limit);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
             params->downtime_limit);
         assert(params->has_x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u ms\n",
+        monitor_hmp_printf(hmp, "%s: %u ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
             params->x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
             params->multifd_channels);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRESSION),
             MultiFDCompression_str(params->multifd_compression));
         assert(params->has_zero_page_detection);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETECTION),
             qapi_enum_lookup(&ZeroPageDetection_lookup,
                 params->zero_page_detection));
-        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
             MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
             params->xbzrle_cache_size);
 
         if (s->has_block_bitmap_mapping) {
             const BitmapMigrationNodeAliasList *bmnal;
 
-            monitor_printf(mon, "%s:\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
+            monitor_hmp_printf(hmp, "%s:\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
 
             for (bmnal = params->block_bitmap_mapping;
                  bmnal;
@@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
                 const BitmapMigrationNodeAlias *bmna = bmnal->value;
                 const BitmapMigrationBitmapAliasList *bmbal;
 
-                monitor_printf(mon, "  '%s' -> '%s'\n",
-                               bmna->node_name, bmna->alias);
+                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
+                                   bmna->node_name, bmna->alias);
 
                 for (bmbal = bmna->bitmaps; bmbal; bmbal = bmbal->next) {
                     const BitmapMigrationBitmapAlias *bmba = bmbal->value;
 
-                    monitor_printf(mon, "    '%s' -> '%s'\n",
-                                   bmba->name, bmba->alias);
+                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
+                                       bmba->name, bmba->alias);
                 }
             }
         }
 
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
         MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD),
         params->x_vcpu_dirty_limit_period);
 
-        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT),
             params->vcpu_dirty_limit);
 
         assert(params->has_mode);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MODE),
             qapi_enum_lookup(&MigMode_lookup, params->mode));
 
         if (params->has_direct_io) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_DIRECT_IO),
-                           params->direct_io ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_DIRECT_IO),
+                               params->direct_io ? "on" : "off");
         }
 
         if (params->has_x_rdma_chunk_size) {
-            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
-                           params->x_rdma_chunk_size);
+            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
+                               params->x_rdma_chunk_size);
         }
 
         assert(params->has_cpr_exec_command);
-        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
+        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
     }
 
     qapi_free_MigrationParameters(params);
@@ -857,12 +854,12 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
     if (uri_cpr) {
         if (migrate_mode() != MIG_MODE_CPR_TRANSFER) {
             error_setg(&err, "-c can only be used in cpr-transfer mode");
-            hmp_handle_error(mon, err);
+            hmp_handle_error(hmp, err);
             return;
         }
 
         if (!migrate_uri_parse(uri_cpr, &channel_cpr, &err)) {
-            hmp_handle_error(mon, err);
+            hmp_handle_error(hmp, err);
             return;
         }
 
@@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
         HMPMigrationStatus *status;
 
         if (!hmp->use_readline) {
-            monitor_printf(mon, "terminal does not allow synchronous "
-                           "migration, continuing detached\n");
+            monitor_hmp_printf(hmp, "terminal does not allow synchronous "
+                               "migration, continuing detached\n");
             return;
         }
         monitor_suspend(mon);
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 89cc19c2431d..1834e3c1f697 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     NameInfo *info;
 
     info = qmp_query_name(NULL);
     if (info->name) {
-        monitor_printf(mon, "%s\n", info->name);
+        monitor_hmp_printf(hmp, "%s\n", info->name);
     }
     qapi_free_NameInfo(info);
 }
 
 void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VersionInfo *info;
 
     info = qmp_query_version(NULL);
 
-    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
-                   info->qemu->major, info->qemu->minor, info->qemu->micro,
-                   info->package);
+    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+                       info->qemu->major, info->qemu->minor, info->qemu->micro,
+                       info->package);
 
     qapi_free_VersionInfo(info);
 }
@@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
 
     if (op == NULL) {
         bool on = qsp_is_enabled();
 
-        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off");
+        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "off");
         return;
     }
     if (!strcmp(op, "on")) {
@@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index;
 
     /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands that
             use it are converted to the QAPI */
     cpu_index = qdict_get_int(qdict, "index");
     if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
-        monitor_printf(mon, "invalid CPU index\n");
+        monitor_hmp_printf(hmp, "invalid CPU index\n");
     }
 }
 
@@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *device = qdict_get_str(qdict, "device");
     const char *target = qdict_get_str(qdict, "target");
     const char *arg = qdict_get_try_str(qdict, "arg");
@@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
     if (strcmp(device, "vnc") == 0) {
-        hmp_change_vnc(mon, device, target, arg, read_only, force, &err);
+        hmp_change_vnc(hmp, device, target, arg, read_only, force, &err);
     } else
 #endif
     {
-        hmp_change_medium(mon, device, target, arg, read_only, force, &err);
+        hmp_change_medium(hmp, device, target, arg, read_only, force, &err);
     }
 
     hmp_handle_error(hmp, err);
@@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
     IOThreadInfoList *info;
     IOThreadInfo *value;
 
     for (info = info_list; info; info = info->next) {
         value = info->value;
-        monitor_printf(mon, "%s:\n", value->id);
-        monitor_printf(mon, "  thread_id=%" PRId64 "\n", value->thread_id);
-        monitor_printf(mon, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
-        monitor_printf(mon, "  poll-grow=%" PRId64 "\n", value->poll_grow);
-        monitor_printf(mon, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
-        monitor_printf(mon, "  poll-weight=%" PRId64 "\n", value->poll_weight);
-        monitor_printf(mon, "  aio-max-batch=%" PRId64 "\n",
-                       value->aio_max_batch);
+        monitor_hmp_printf(hmp, "%s:\n", value->id);
+        monitor_hmp_printf(hmp, "  thread_id=%" PRId64 "\n", value->thread_id);
+        monitor_hmp_printf(hmp, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
+        monitor_hmp_printf(hmp, "  poll-grow=%" PRId64 "\n", value->poll_grow);
+        monitor_hmp_printf(hmp, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
+        monitor_hmp_printf(hmp, "  poll-weight=%" PRId64 "\n", value->poll_weight);
+        monitor_hmp_printf(hmp, "  aio-max-batch=%" PRId64 "\n",
+                           value->aio_max_batch);
     }
 
     qapi_free_IOThreadInfoList(info_list);
@@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
+    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
 }
 
 void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /*
      * Send an ANSI escape sequence:
      * "\x1b[H" - move cursor to top-left
      * "\x1b[2J" - clear visible screen
      * "\x1b[3J" - clear scrollback
      */
-    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
+    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
 }
 
 void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, "info");
+    hmp_help_cmd(hmp, "info");
 }
 
 void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
@@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     const char *str;
 
@@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
         if (!str) {
             break;
         }
-        monitor_printf(mon, "%d: '%s'\n", i, str);
+        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
         i++;
     }
 }
@@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int mask;
     const char *items = qdict_get_str(qdict, "items");
     Error *err = NULL;
@@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
     } else {
         mask = qemu_str_to_log_mask(items);
         if (!mask) {
-            hmp_help_cmd(mon, "log");
+            hmp_help_cmd(hmp, "log");
             return;
         }
     }
@@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *device = qdict_get_try_str(qdict, "device");
 
@@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
     if (!gdbserver_start(device, &err)) {
         error_report_err(err);
     } else if (strcmp(device, "none") == 0) {
-        monitor_printf(mon, "Disabled gdbserver\n");
+        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
     } else {
-        monitor_printf(mon, "Waiting for gdb connection on device '%s'\n",
-                       device);
+        monitor_hmp_printf(hmp, "Waiting for gdb connection on device '%s'\n",
+                           device);
     }
 }
 
 void hmp_print(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int format = qdict_get_int(qdict, "format");
     hwaddr val = qdict_get_int(qdict, "val");
 
     switch(format) {
     case 'o':
-        monitor_printf(mon, "%#" HWADDR_PRIo, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
         break;
     case 'x':
-        monitor_printf(mon, "%#" HWADDR_PRIx, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
         break;
     case 'u':
-        monitor_printf(mon, "%" HWADDR_PRIu, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
         break;
     default:
     case 'd':
-        monitor_printf(mon, "%" HWADDR_PRId, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
         break;
     case 'c':
-        monitor_printc(mon, val);
+        monitor_hmp_printc(hmp, val);
         break;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t addr;
     uint16_t sum;
     uint32_t start = qdict_get_int(qdict, "start");
@@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
         sum = (sum >> 1) | (sum << 15);
         sum += val;
     }
-    monitor_printf(mon, "%05d\n", sum);
+    monitor_hmp_printf(hmp, "%05d\n", sum);
 }
 
 void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int size = qdict_get_int(qdict, "size");
     int addr = qdict_get_int(qdict, "addr");
     int has_index = qdict_haskey(qdict, "index");
@@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
         suffix = 'l';
         break;
     }
-    monitor_printf(mon, "port%c[0x%04x] = 0x%0*x\n",
-                   suffix, addr, size * 2, val);
+    monitor_hmp_printf(hmp, "port%c[0x%04x] = 0x%0*x\n",
+                       suffix, addr, size * 2, val);
 }
 
 void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
@@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *local_err = NULL;
     const char *bootdevice = qdict_get_str(qdict, "bootdevice");
 
@@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "boot device list now set to %s\n", bootdevice);
+        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bootdevice);
     }
 }
 
@@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
+    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
 }
 #endif
 
@@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
 
 void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
     int vcpu = qdict_get_try_int(qdict, "vcpu", -1);
     CPUState *cs;
 
     if (all_cpus) {
         CPU_FOREACH(cs) {
-            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
             cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
         }
     } else {
@@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 
         if (!cs) {
             if (vcpu >= 0) {
-                monitor_printf(mon, "CPU#%d not available\n", vcpu);
+                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu);
             } else {
-                monitor_printf(mon, "No CPU available\n");
+                monitor_hmp_printf(hmp, "No CPU available\n");
             }
             return;
         }
 
-        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
         cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
     }
 }
@@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                         uint64_t addr, bool is_physical)
 {
-    Monitor *mon = MONITOR(hmp);
     int l, line_size, i, max_digits, len;
     uint8_t buf[16];
     uint64_t v;
@@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     const bool big_endian = target_big_endian();
 
     if (!cs && (format == 'i' || !is_physical)) {
-        monitor_printf(mon, "Can not dump without CPU\n");
+        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
         return;
     }
 
     if (format == 'i') {
-        monitor_disas(mon, cs, addr, count, is_physical);
+        monitor_disas(hmp, cs, addr, count, is_physical);
         return;
     }
 
@@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     }
 
     while (len > 0) {
-        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
+        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
         l = len;
         if (l > line_size) {
             l = line_size;
@@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
             MemTxResult r = address_space_read(as, addr,
                                                MEMTXATTRS_UNSPECIFIED, buf, l);
             if (r != MEMTX_OK) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         } else {
             if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         }
@@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                 v = (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
                 break;
             }
-            monitor_printf(mon, " ");
+            monitor_hmp_printf(hmp, " ");
             switch (format) {
             case 'o':
-                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
+                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
                 break;
             case 'x':
-                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
+                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v);
                 break;
             case 'u':
-                monitor_printf(mon, "%*" PRIu64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
                 break;
             case 'd':
-                monitor_printf(mon, "%*" PRId64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
                 break;
             case 'c':
-                monitor_printc(mon, v);
+                monitor_hmp_printc(hmp, v);
                 break;
             }
             i += wsize;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         addr += l;
         len -= l;
     }
@@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
-                   " (%s) is %p\n",
-                   addr, mr->name, ptr);
+    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
+                       " (%s) is %p\n",
+                       addr, mr->name, ptr);
 
     memory_region_unref(mr);
 }
 
 void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     vaddr addr = qdict_get_int(qdict, "addr");
     CPUState *cs = monitor_hmp_get_cpu(hmp);
     TranslateForDebugResult tres;
 
     if (!cs) {
-        monitor_printf(mon, "No cpu\n");
+        monitor_hmp_printf(hmp, "No cpu\n");
         return;
     }
 
     if (!cpu_translate_for_debug(cs, addr, &tres)) {
-        monitor_printf(mon, "Unmapped\n");
+        monitor_hmp_printf(hmp, "Unmapped\n");
     } else {
-        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
+        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
     }
 }
 
@@ -806,7 +786,6 @@ out:
 
 void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRIx
-                       " (%s) is 0x%" PRIx64 "\n",
-                       addr, mr->name, (uint64_t) physaddr);
+        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR_PRIx
+                           " (%s) is 0x%" PRIx64 "\n",
+                           addr, mr->name, (uint64_t) physaddr);
     }
 
     memory_region_unref(mr);
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 2484a2310dff..e5f8b9c576e0 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, bool val, Error **errp)
     hmp->use_readline = val;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
 static void monitor_hmp_accept_input(Monitor *mon);
 static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
 static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp);
@@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, const void *data)
                                    monitor_hmp_get_readline,
                                    monitor_hmp_set_readline);
 
-    moncls->vprintf = monitor_hmp_vprintf;
     moncls->accept_input = monitor_hmp_accept_input;
 
     ucc->complete = monitor_hmp_complete;
@@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
     hmp->use_readline = true;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-{
-    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
-    return monitor_puts(mon, buf);
-}
-
 static void monitor_hmp_accept_input(Monitor *mon)
 {
     qemu_mutex_lock(&mon->mon_lock);
@@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
         /* prompt is printed on return from the command handler */
         return 0;
     } else {
-        monitor_printf(&hmp->parent_obj,
-                       "terminal does not support password prompting\n");
+        monitor_hmp_printf(hmp, "terminal does not support password prompting\n");
         return -ENOTTY;
     }
 }
@@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
     return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
 }
 
-static void help_cmd_dump_one(Monitor *mon,
+static void help_cmd_dump_one(MonitorHMP *mon,
                               const HMPCommand *cmd,
                               char **prefix_args,
                               int prefix_args_nb)
@@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
     }
 
     for (i = 0; i < prefix_args_nb; i++) {
-        monitor_printf(mon, "%s ", prefix_args[i]);
+        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
     }
-    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
+    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
 }
 
 /* @args[@arg_index] is the valid command need to find in @cmds */
-static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
+static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
                           char **args, int nb_args, int arg_index)
 {
     const HMPCommand *cmd;
@@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
     }
 
     /* Command not found */
-    monitor_printf(mon, "unknown command: '");
+    monitor_hmp_printf(mon, "unknown command: '");
     for (i = 0; i <= arg_index; i++) {
-        monitor_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
+        monitor_hmp_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
     }
 }
 
-void hmp_help_cmd(Monitor *mon, const char *name)
+void hmp_help_cmd(MonitorHMP *mon, const char *name)
 {
     char *args[MAX_ARGS];
     int nb_args = 0;
@@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
         /* special case for log, directly dump and return */
         if (!strcmp(name, "log")) {
             const QEMULogItem *item;
-            monitor_printf(mon, "Log items (comma separated):\n");
-            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs");
+            monitor_hmp_printf(mon, "Log items (comma separated):\n");
+            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all logs");
             for (item = qemu_log_items; item->mask != 0; item++) {
-                monitor_printf(mon, "%-15s %s\n", item->name, item->help);
+                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item->help);
             }
 #ifdef CONFIG_TRACE_LOG
-            monitor_printf(mon, "trace:PATTERN   enable trace events\n");
-            monitor_printf(mon, "\nUse \"log trace:help\" to get a list of "
-                           "trace events.\n\n");
+            monitor_hmp_printf(mon, "trace:PATTERN   enable trace events\n");
+            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a list of "
+                               "trace events.\n\n");
 #endif
             return;
         }
@@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
 static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char *name);
 
 static G_NORETURN G_GNUC_PRINTF(2, 3)
-void expr_error(Monitor *mon, const char *fmt, ...)
+void expr_error(MonitorHMP *mon, const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(mon, fmt, ap);
-    monitor_printf(mon, "\n");
+    monitor_hmp_vprintf(mon, fmt, ap);
+    monitor_hmp_printf(mon, "\n");
     va_end(ap);
     siglongjmp(expr_env, 1);
 }
@@ -475,9 +465,9 @@ static void next(void)
     }
 }
 
-static int64_t expr_sum(Monitor *mon);
+static int64_t expr_sum(MonitorHMP *mon);
 
-static int64_t expr_unary(Monitor *mon)
+static int64_t expr_unary(MonitorHMP *mon)
 {
     int64_t n;
     char *p;
@@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
                 pch++;
             }
             *q = 0;
-            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
-                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
+            if (!gdb_get_register(mon, &reg, buf)
+                && get_monitor_def(mon, &reg, buf) < 0) {
                 expr_error(mon, "unknown register");
             }
             n = reg;
@@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
     return n;
 }
 
-static int64_t expr_prod(Monitor *mon)
+static int64_t expr_prod(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
     return val;
 }
 
-static int64_t expr_logic(Monitor *mon)
+static int64_t expr_logic(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
     return val;
 }
 
-static int64_t expr_sum(Monitor *mon)
+static int64_t expr_sum(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
     return val;
 }
 
-static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
+static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
 {
     pch = *pp;
     if (sigsetjmp(expr_env, 0)) {
@@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
     return 0;
 }
 
-static int get_double(Monitor *mon, double *pval, const char **pp)
+static int get_double(MonitorHMP *mon, double *pval, const char **pp)
 {
     const char *p = *pp;
     char *tailp;
@@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval, const char **pp)
 
     d = strtod(p, &tailp);
     if (tailp == p) {
-        monitor_printf(mon, "Number expected\n");
+        monitor_hmp_printf(mon, "Number expected\n");
         return -1;
     }
     if (d != d || d - d != 0) {
         /* NaN or infinity */
-        monitor_printf(mon, "Bad number\n");
+        monitor_hmp_printf(mon, "Bad number\n");
         return -1;
     }
     *pval = d;
@@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
                                                const char **cmdp,
                                                HMPCommand *table)
 {
-    Monitor *mon = &hmp->parent_obj;
     const char *p;
     const HMPCommand *cmd;
     char cmdname[256];
@@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
 
     cmd = search_dispatch_table(table, cmdname);
     if (!cmd) {
-        monitor_printf(mon, "unknown command: '%.*s'\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
     if (!cmd_available(cmd)) {
-        monitor_printf(mon, "Command '%.*s' not available "
-                            "until machine initialization has completed.\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "Command '%.*s' not available "
+                           "until machine initialization has completed.\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
 
@@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
  * Else, insert command arguments into a QDict, and return it.
  * Note: On success, caller has to free the QDict structure.
  */
-static QDict *monitor_parse_arguments(Monitor *mon,
+static QDict *monitor_parse_arguments(MonitorHMP *mon,
                                       const char **endp,
                                       const HMPCommand *cmd)
 {
@@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 if (ret < 0) {
                     switch (c) {
                     case 'F':
-                        monitor_printf(mon, "%s: filename expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: filename expected\n",
+                                           cmd->name);
                         break;
                     case 'B':
-                        monitor_printf(mon, "%s: block device name expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: block device name expected\n",
+                                           cmd->name);
                         break;
                     default:
-                        monitor_printf(mon, "%s: string expected\n", cmd->name);
+                        monitor_hmp_printf(mon, "%s: string expected\n", cmd->name);
                         break;
                     }
                     goto fail;
@@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 next:
                     if (*p != '\0' && !qemu_isspace(*p)) {
-                        monitor_printf(mon, "invalid char in format: '%c'\n",
-                                       *p);
+                        monitor_hmp_printf(mon, "invalid char in format: '%c'\n",
+                                           *p);
                         goto fail;
                     }
                     if (format < 0) {
@@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 /* Check if 'i' is greater than 32-bit */
                 if ((c == 'i') && ((val >> 32) & 0xffffffff)) {
-                    monitor_printf(mon, "\'%s\' has failed: ", cmd->name);
-                    monitor_printf(mon, "integer is for 32-bit values\n");
+                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd->name);
+                    monitor_hmp_printf(mon, "integer is for 32-bit values\n");
                     goto fail;
                 } else if (c == 'M') {
                     if (val < 0) {
-                        monitor_printf(mon, "enter a positive value\n");
+                        monitor_hmp_printf(mon, "enter a positive value\n");
                         goto fail;
                     }
                     val *= MiB;
@@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 ret = qemu_strtosz_MiB(p, &end, &val);
                 if (ret < 0 || val > INT64_MAX) {
-                    monitor_printf(mon, "invalid size\n");
+                    monitor_hmp_printf(mon, "invalid size\n");
                     goto fail;
                 }
                 qdict_put_int(qdict, key, val);
@@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 }
                 if (*p && !qemu_isspace(*p)) {
-                    monitor_printf(mon, "Unknown unit suffix\n");
+                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
                     goto fail;
                 }
                 qdict_put(qdict, key, qnum_from_double(val));
@@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 } else if (p - beg == 3 && !memcmp(beg, "off", p - beg)) {
                     val = false;
                 } else {
-                    monitor_printf(mon, "Expected 'on' or 'off'\n");
+                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n");
                     goto fail;
                 }
                 qdict_put_bool(qdict, key, val);
@@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     p++;
                     if (c != *p) {
                         if (!is_valid_option(p, typestr)) {
-                            monitor_printf(mon, "%s: unsupported option -%c\n",
-                                           cmd->name, *p);
+                            monitor_hmp_printf(mon, "%s: unsupported option -%c\n",
+                                               cmd->name, *p);
                             goto fail;
                         } else {
                             skip_key = 1;
@@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                         }
                         ret = get_str(buf, sizeof(buf), &p);
                         if (ret < 0) {
-                            monitor_printf(mon, "%s: value expected for -%c\n",
-                                           cmd->name, *tmp);
+                            monitor_hmp_printf(mon, "%s: value expected for -%c\n",
+                                               cmd->name, *tmp);
                             goto fail;
                         }
                         qdict_put_str(qdict, key, buf);
@@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 len = strlen(p);
                 if (len <= 0) {
-                    monitor_printf(mon, "%s: string expected\n",
-                                   cmd->name);
+                    monitor_hmp_printf(mon, "%s: string expected\n",
+                                       cmd->name);
                     goto fail;
                 }
                 qdict_put_str(qdict, key, p);
@@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
             break;
         default:
         bad_type:
-            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
+            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
             goto fail;
         }
         g_free(key);
@@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
         p++;
     }
     if (*p != '\0') {
-        monitor_printf(mon, "%s: extraneous characters at the end of line\n",
-                       cmd->name);
+        monitor_hmp_printf(mon, "%s: extraneous characters at the end of line\n",
+                           cmd->name);
         goto fail;
     }
 
@@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const char *cmdline)
 
     if (!cmd->cmd && !cmd->cmd_info_hrt) {
         /* FIXME: is it useful to try autoload modules here ??? */
-        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not available.\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
-    qdict = monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd);
+    qdict = monitor_parse_arguments(hmp, &cmdline, cmd);
     if (!qdict) {
         while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
             cmdline--;
         }
-        monitor_printf(&hmp->parent_obj,
-                       "Try \"help %.*s\" for more information\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp,
+                           "Try \"help %.*s\" for more information\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
@@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint8_t *buf, int size)
         }
     } else {
         if (size == 0 || buf[size - 1] != 0) {
-            monitor_printf(&hmp->parent_obj, "corrupted command\n");
+            monitor_hmp_printf(hmp, "corrupted command\n");
         } else {
             handle_hmp_command(hmp, (char *)buf);
         }
@@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEvent event)
         break;
 
     case CHR_EVENT_OPENED:
-        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
-                       "information\n", QEMU_VERSION);
+        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for more "
+                           "information\n", QEMU_VERSION);
         qemu_mutex_lock(&mon->mon_lock);
         hmp->reset_seen = 1;
         if (!mon->mux_out && hmp->use_readline) {
@@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_printf(void *opaque,
     MonitorHMP *hmp = opaque;
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(&hmp->parent_obj, fmt, ap);
+    monitor_hmp_vprintf(hmp, fmt, ap);
     va_end(ap);
 }
 
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index afdda1386080..c198c12eaa00 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -108,12 +108,6 @@ typedef struct HMPCommand {
 struct MonitorClass {
     ObjectClass parent_class;
 
-    /*
-     * If non-NULL, the monitor is able to print messages
-     * for attention of the client user
-     */
-    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
-        G_GNUC_PRINTF(2, 0);
     /*
      * If non-NULL, the monitor is able to send event
      * notifications back to the client
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 8528af6f79b8..da76e6e4ac19 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
     return monitor_puts_locked(mon, str);
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
-    MonitorClass *moncls;
+    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
 
     if (!mon) {
         return -1;
     }
 
-    moncls = MONITOR_GET_CLASS(mon);
-    if (!moncls->vprintf) {
-        return -1;
-    }
-
-    return moncls->vprintf(mon, fmt, ap);
+    return monitor_puts(MONITOR(mon), buf);
 }
 
-int monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
 {
     int ret;
 
     va_list ap;
     va_start(ap, fmt);
-    ret = monitor_vprintf(mon, fmt, ap);
+    ret = monitor_hmp_vprintf(mon, fmt, ap);
     va_end(ap);
     return ret;
 }
 
-void monitor_printc(Monitor *mon, int c)
+void monitor_hmp_printc(MonitorHMP *mon, int c)
 {
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
     switch(c) {
     case '\'':
-        monitor_printf(mon, "\\'");
+        monitor_hmp_printf(mon, "\\'");
         break;
     case '\\':
-        monitor_printf(mon, "\\\\");
+        monitor_hmp_printf(mon, "\\\\");
         break;
     case '\n':
-        monitor_printf(mon, "\\n");
+        monitor_hmp_printf(mon, "\\n");
         break;
     case '\r':
-        monitor_printf(mon, "\\r");
+        monitor_hmp_printf(mon, "\\r");
         break;
     default:
         if (c >= 32 && c <= 126) {
-            monitor_printf(mon, "%c", c);
+            monitor_hmp_printf(mon, "%c", c);
         } else {
-            monitor_printf(mon, "\\x%02x", c);
+            monitor_hmp_printf(mon, "\\x%02x", c);
         }
         break;
     }
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
 }
 
 static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
index 5b1c678f5d89..0d718d78aef9 100644
--- a/net/net-hmp-cmds.c
+++ b/net/net-hmp-cmds.c
@@ -28,26 +28,25 @@
 #include "qemu/help_option.h"
 #include "qemu/option.h"
 
-static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
+static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *ci)
 {
     NetFilterInfoList *f;
 
-    monitor_printf(mon, "%s: index=%" PRIu32 ",type=%s,%s\n",
-                   ci->name, ci->queue_index,
-                   NetClientDriver_str(ci->type), ci->info_str);
+    monitor_hmp_printf(hmp, "%s: index=%" PRIu32 ",type=%s,%s\n",
+                       ci->name, ci->queue_index,
+                       NetClientDriver_str(ci->type), ci->info_str);
     if (ci->filters) {
-        monitor_printf(mon, "filters:\n");
+        monitor_hmp_printf(hmp, "filters:\n");
         for (f = ci->filters; f; f = f->next) {
-            monitor_printf(mon, "  - %s: type=%s%s%s\n",
-                           f->value->name, f->value->type,
-                           f->value->info[0] ? "," : "", f->value->info);
+            monitor_hmp_printf(hmp, "  - %s: type=%s%s%s\n",
+                               f->value->name, f->value->type,
+                               f->value->info[0] ? "," : "", f->value->info);
         }
     }
 }
 
 void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     g_autoptr(NetworkInfo) info = qmp_x_query_network(&err);
     NetHubInfoList *h;
@@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
     for (h = info->hubs; h; h = h->next) {
         NetHubPortInfoList *p;
 
-        monitor_printf(mon, "hub %d\n", (int)h->value->id);
+        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
         for (p = h->value->ports; p; p = p->next) {
             if (p->value->peer) {
-                monitor_printf(mon, " \\ %s: ", p->value->name);
-                hmp_print_client_info(mon, p->value->peer);
+                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
+                hmp_print_client_info(hmp, p->value->peer);
             } else {
-                monitor_printf(mon, " \\ %s\n", p->value->name);
+                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
             }
         }
     }
@@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
         NetworkClientInfo *ci = entry->value;
 
         if (!ci->peer || ci->type == NET_CLIENT_DRIVER_NIC) {
-            hmp_print_client_info(mon, ci);
+            hmp_print_client_info(hmp, ci);
         } /* else it's a netdev connected to a NIC, printed with the NIC */
         if (ci->peer && ci->type == NET_CLIENT_DRIVER_NIC) {
-            monitor_printf(mon, " \\ ");
-            hmp_print_client_info(mon, ci->peer);
+            monitor_hmp_printf(hmp, " \\ ");
+            hmp_print_client_info(hmp, ci->peer);
         }
     }
 }
diff --git a/net/slirp.c b/net/slirp.c
index d5c190b48b76..6fbefa9ed1d7 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -711,22 +711,22 @@ error:
     return -1;
 }
 
-static SlirpState *slirp_lookup(Monitor *mon, const char *id)
+static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
 {
     if (id) {
         NetClientState *nc = qemu_find_netdev(id);
         if (!nc) {
-            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
+            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", id);
             return NULL;
         }
         if (strcmp(nc->model, "user")) {
-            monitor_printf(mon, "invalid device specified\n");
+            monitor_hmp_printf(hmp, "invalid device specified\n");
             return NULL;
         }
         return DO_UPCAST(SlirpState, nc, nc);
     } else {
         if (QTAILQ_EMPTY(&slirp_stacks)) {
-            monitor_printf(mon, "user mode network stack not in use\n");
+            monitor_hmp_printf(hmp, "user mode network stack not in use\n");
             return NULL;
         }
         return QTAILQ_FIRST(&slirp_stacks);
@@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const char *id)
 
 void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /* TODO: support removing unix fwd */
     struct sockaddr_in host_addr = {
         .sin_family = AF_INET,
@@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         src_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         src_str = arg1;
     }
     if (!s) {
@@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     err = slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr, host_port);
 #endif
 
-    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
-                   err ? "not found" : "removed");
+    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_str,
+                       err ? "not found" : "removed");
     return;
 
  fail_syntax:
-    monitor_printf(mon, "invalid format\n");
+    monitor_hmp_printf(hmp, "invalid format\n");
 }
 
 static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
@@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
 
 void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *redir_str;
     SlirpState *s;
     const char *arg1 = qdict_get_str(qdict, "arg1");
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         redir_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         redir_str = arg1;
     }
     if (s) {
@@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **errp)
 
 void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autoptr(UsernetInfoList) list = NULL;
     UsernetInfoList *entry;
 
     list = qmp_x_query_usernet(&error_abort);
     for (entry = list; entry; entry = entry->next) {
         UsernetInfo *ui = entry->value;
-        monitor_printf(mon, "Hub %d (%s):\n%s",
-                       ui->has_hub_id ? (int)ui->hub_id : -1,
-                       ui->hub_name, ui->info);
+        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
+                           ui->has_hub_id ? (int)ui->hub_id : -1,
+                           ui->hub_name, ui->info);
     }
 }
 
diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
index 2e2eb33371e2..bbf5980332a4 100644
--- a/qom/qom-hmp-cmds.c
+++ b/qom/qom-hmp-cmds.c
@@ -20,13 +20,12 @@
 
 void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(qdict, "path");
     ObjectPropertyInfoList *list;
     Error *err = NULL;
 
     if (path == NULL) {
-        monitor_printf(mon, "/\n");
+        monitor_hmp_printf(hmp, "/\n");
         return;
     }
 
@@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
         while (list != NULL) {
             ObjectPropertyInfo *value = list->value;
 
-            monitor_printf(mon, "%s (%s)\n",
-                           value->name, value->type);
+            monitor_hmp_printf(hmp, "%s (%s)\n",
+                               value->name, value->type);
             list = list->next;
         }
         qapi_free_ObjectPropertyInfoList(start);
@@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     const char *property = qdict_get_str(qdict, "property");
     Error *err = NULL;
@@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 
     if (err == NULL) {
         GString *str = qobject_to_json_pretty(obj, true);
-        monitor_printf(mon, "%s\n", str->str);
+        monitor_hmp_printf(hmp, "%s\n", str->str);
         g_string_free(str, true);
     }
 
@@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
     int indent;
 } QOMCompositionState;
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent);
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent);
 
 static int qom_composition_compare(const void *a, const void *b)
 {
@@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj, void *opaque)
     return 0;
 }
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent)
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent)
 {
     GArray *children = g_array_new(false, false, sizeof(Object *));
     const char *name;
@@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
     } else {
         name = object_get_canonical_path_component(obj);
     }
-    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
-                   object_get_typename(obj));
+    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
+                       object_get_typename(obj));
 
     object_child_foreach(obj, insert_qom_composition_child, children);
     g_array_sort(children, qom_composition_compare);
 
     for (i = 0; i < children->len; i++) {
-        print_qom_composition(mon, g_array_index(children, Object *, i),
+        print_qom_composition(hmp, g_array_index(children, Object *, i),
                               indent + 2);
     }
     g_array_free(children, TRUE);
@@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
 
 void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(dict, "path");
     Object *obj;
     bool ambiguous = false;
@@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
     if (path) {
         obj = object_resolve_path(path, &ambiguous);
         if (!obj) {
-            monitor_printf(mon, "Path '%s' could not be resolved.\n", path);
+            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\n", path);
             return;
         }
         if (ambiguous) {
-            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", path);
+            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\n", path);
             return;
         }
     } else {
         obj = qdev_get_machine();
     }
-    print_qom_composition(mon, obj, 0);
+    print_qom_composition(hmp, obj, 0);
 }
 
 void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index ef69d23ff507..965565715ef2 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -33,11 +33,10 @@ bool replay_running_debug(void)
 
 void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     if (replay_mode == REPLAY_MODE_NONE) {
-        monitor_printf(mon, "Record/replay is not active\n");
+        monitor_hmp_printf(hmp, "Record/replay is not active\n");
     } else {
-        monitor_printf(mon,
+        monitor_hmp_printf(hmp,
             "%s execution '%s': instruction count = %"PRId64"\n",
             replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
             replay_get_filename(), replay_get_current_icount());
diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
index cd1f1deb58bc..3d556c745d61 100644
--- a/stats/stats-hmp-cmds.c
+++ b/stats/stats-hmp-cmds.c
@@ -14,11 +14,11 @@
 #include "qobject/qdict.h"
 #include "qapi/error.h"
 
-static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
+static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue *value)
 {
     const char *unit = NULL;
-    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(value->type),
-                   value->has_unit || value->exponent ? ", " : "");
+    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str(value->type),
+                       value->has_unit || value->exponent ? ", " : "");
 
     if (value->has_unit) {
         if (value->unit == STATS_UNIT_SECONDS) {
@@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
     if (unit && value->base == 10 &&
         value->exponent >= -18 && value->exponent <= 18 &&
         value->exponent % 3 == 0) {
-        monitor_puts(mon, si_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
     } else if (unit && value->base == 2 &&
                value->exponent >= 0 && value->exponent <= 60 &&
                value->exponent % 10 == 0) {
 
-        monitor_puts(mon, iec_binary_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent));
     } else if (value->exponent) {
         /* Use exponential notation and write the unit's English name */
-        monitor_printf(mon, "* %d^%d%s",
-                       value->base, value->exponent,
-                       value->has_unit ? " " : "");
+        monitor_hmp_printf(hmp, "* %d^%d%s",
+                           value->base, value->exponent,
+                           value->has_unit ? " " : "");
         unit = NULL;
     }
 
     if (value->has_unit) {
-        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
+        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->unit));
     }
 
     /* Print bucket size for linear histograms */
     if (value->type == STATS_TYPE_LINEAR_HISTOGRAM && value->has_bucket_size) {
-        monitor_printf(mon, ", bucket size=%d", value->bucket_size);
+        monitor_hmp_printf(hmp, ", bucket size=%d", value->bucket_size);
     }
-    monitor_printf(mon, ")");
+    monitor_hmp_printf(hmp, ")");
 }
 
 static StatsSchemaValueList *find_schema_value_list(
@@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
     return NULL;
 }
 
-static void print_stats_results(Monitor *mon, StatsTarget target,
+static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
                                 bool show_provider,
                                 StatsResult *result,
                                 StatsSchemaList *schema)
@@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
     StatsList *stats_list;
 
     if (!schema_value_list) {
-        monitor_printf(mon, "failed to find schema list for %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
+                           StatsProvider_str(result->provider));
         return;
     }
 
     if (show_provider) {
-        monitor_printf(mon, "provider: %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "provider: %s\n",
+                           StatsProvider_str(result->provider));
     }
 
     for (stats_list = result->stats; stats_list;
@@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
         /* Find schema entry */
         while (!g_str_equal(stats->name, schema_value->name)) {
             if (!schema_value_list->next) {
-                monitor_printf(mon, "failed to find schema entry for %s\n",
-                               stats->name);
+                monitor_hmp_printf(hmp, "failed to find schema entry for %s\n",
+                                   stats->name);
                 return;
             }
             schema_value_list = schema_value_list->next;
             schema_value = schema_value_list->value;
         }
 
-        print_stats_schema_value(mon, schema_value);
+        print_stats_schema_value(hmp, schema_value);
 
         if (stats_value->type == QTYPE_QNUM) {
-            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scalar);
+            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.scalar);
         } else if (stats_value->type == QTYPE_QBOOL) {
-            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "yes" : "no");
+            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ? "yes" : "no");
         } else if (stats_value->type == QTYPE_QLIST) {
             uint64List *list;
             int i;
 
-            monitor_printf(mon, ": ");
+            monitor_hmp_printf(hmp, ": ");
             for (list = stats_value->u.list, i = 1;
                  list;
                  list = list->next, i++) {
-                monitor_printf(mon, "[%d]=%" PRId64 " ", i, list->value);
+                monitor_hmp_printf(hmp, "[%d]=%" PRId64 " ", i, list->value);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 }
@@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target, const char *names,
 
 void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *target_str = qdict_get_str(qdict, "target");
     const char *provider_str = qdict_get_try_str(qdict, "provider");
     const char *names = qdict_get_try_str(qdict, "names");
@@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 
     target = qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &err);
     if (err) {
-        monitor_printf(mon, "invalid stats target %s\n", target_str);
+        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_str);
         goto exit_no_print;
     }
     if (provider_str) {
         provider = qapi_enum_parse(&StatsProvider_lookup, provider_str, -1, &err);
         if (err) {
-            monitor_printf(mon, "invalid stats provider %s\n", provider_str);
+            monitor_hmp_printf(hmp, "invalid stats provider %s\n", provider_str);
             goto exit_no_print;
         }
     }
@@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
         goto exit;
     }
     for (entry = stats; entry; entry = entry->next) {
-        print_stats_results(mon, target, provider_str == NULL, entry->value, schema);
+        print_stats_results(hmp, target, provider_str == NULL, entry->value, schema);
     }
 
 exit:
     if (err) {
-        monitor_printf(mon, "%s\n", error_get_pretty(err));
+        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
     }
 exit_no_print:
     error_free(err);
diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
index 6f2b87d1ad10..c9c1d10c165c 100644
--- a/stubs/hmp-cmd-info_sev.c
+++ b/stubs/hmp-cmd-info_sev.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SEV is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
 }
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index b0c7002bd406..094b80721003 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
 {
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     /*
      * Pretend 'g_test_message' is our monitor console to
diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.c
index 75194add7931..fb9338e9aef6 100644
--- a/system/dirtylimit-hmp-cmds.c
+++ b/system/dirtylimit-hmp-cmds.c
@@ -17,7 +17,6 @@
 
 void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index = qdict_get_try_int(qdict, "cpu_index", -1);
     Error *err = NULL;
 
@@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query "
-                   "dirty limit for virtual CPU]\n");
+    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to query "
+                       "dirty limit for virtual CPU]\n");
 }
 
 void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
@@ -50,13 +49,12 @@ out:
 
 void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyLimitInfoList *info;
     g_autoptr(DirtyLimitInfoList) head = NULL;
     Error *err = NULL;
 
     if (!dirtylimit_in_service()) {
-        monitor_printf(mon, "Dirty page limit not enabled!\n");
+        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
         return;
     }
 
@@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (info = head; info != NULL; info = info->next) {
-        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
+        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
                             " current rate %"PRIi64 " (MB/s)\n",
                             info->value->cpu_index,
                             info->value->limit_rate,
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 5c2de2f53cc9..3860ada2a237 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
     return ret;
 }
 
-#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ## __VA_ARGS__)
+#define qdev_printf(fmt, ...) \
+    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
 
-static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
+static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
                              int indent)
 {
     for (int i = 0, n = dc->props_count_; i < n; ++i) {
@@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int ind
     }
 }
 
-static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
+static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
+    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
     }
     class = object_get_class(OBJECT(dev));
     do {
-        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
+        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
     bus_print_dev(dev->parent_bus, mon, dev, indent);
 }
 
-static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
+static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)
 {
     BusChild *kid;
 
@@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
         qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
                     dev->id ? dev->id : "");
         if (details) {
-            qdev_print(mon, dev, indent + 2);
+            qdev_print(hmp, dev, indent + 2);
         }
         QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
-            qbus_print(mon, child_bus, indent + 2, details);
+            qbus_print(hmp, child_bus, indent + 2, details);
         }
     }
 }
@@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
 
 void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool details = !qdict_get_try_bool(qdict, "brief", false);
 
     if (sysbus_get_default()) {
-        qbus_print(mon, sysbus_get_default(), 0, details);
+        qbus_print(hmp, sysbus_get_default(), 0, details);
     }
 }
 
diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
index 051ee45ee74c..ad70b53f8abf 100644
--- a/system/runstate-hmp-cmds.c
+++ b/system/runstate-hmp-cmds.c
@@ -25,33 +25,31 @@
 
 void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     StatusInfo *info;
 
     info = qmp_query_status(NULL);
 
-    monitor_printf(mon, "VM status: %s",
-                   info->running ? "running" : "paused");
+    monitor_hmp_printf(hmp, "VM status: %s",
+                       info->running ? "running" : "paused");
 
     if (!info->running && info->status != RUN_STATE_PAUSED) {
-        monitor_printf(mon, " (%s)", RunState_str(info->status));
+        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_StatusInfo(info);
 }
 
 void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *option = qdict_get_try_str(qdict, "option");
     AccelState *accel = current_accel();
     bool newval;
 
     if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
-        monitor_printf(mon,
-                       "This accelerator does not support setting one-insn-per-tb\n");
+        monitor_hmp_printf(hmp,
+                           "This accelerator does not support setting one-insn-per-tb\n");
         return;
     }
 
@@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
     } else if (!strcmp(option, "off")) {
         newval = false;
     } else {
-        monitor_printf(mon, "unexpected option %s\n", option);
+        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
         return;
     }
     /* If the property exists then setting it can never fail */
diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
index 094c3f16cf50..35406e24d2c3 100644
--- a/system/tpm-hmp-cmds.c
+++ b/system/tpm-hmp-cmds.c
@@ -13,7 +13,6 @@
 
 void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
 #ifdef CONFIG_TPM
     TPMInfoList *info_list, *info;
     Error *err = NULL;
@@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 
     info_list = qmp_query_tpm(&err);
     if (err) {
-        monitor_printf(mon, "TPM device not supported\n");
+        monitor_hmp_printf(hmp, "TPM device not supported\n");
         error_free(err);
         return;
     }
 
     if (info_list) {
-        monitor_printf(mon, "TPM device:\n");
+        monitor_hmp_printf(hmp, "TPM device:\n");
     }
 
     for (info = info_list; info; info = info->next) {
         TPMInfo *ti = info->value;
-        monitor_printf(mon, " tpm%d: model=%s\n",
-                       c, TpmModel_str(ti->model));
+        monitor_hmp_printf(hmp, " tpm%d: model=%s\n",
+                           c, TpmModel_str(ti->model));
 
-        monitor_printf(mon, "  \\ %s: type=%s",
-                       ti->id, TpmType_str(ti->options->type));
+        monitor_hmp_printf(hmp, "  \\ %s: type=%s",
+                           ti->id, TpmType_str(ti->options->type));
 
         switch (ti->options->type) {
         case TPM_TYPE_PASSTHROUGH:
             tpo = ti->options->u.passthrough.data;
-            monitor_printf(mon, "%s%s%s%s",
-                           tpo->path ? ",path=" : "",
-                           tpo->path ?: "",
-                           tpo->cancel_path ? ",cancel-path=" : "",
-                           tpo->cancel_path ?: "");
+            monitor_hmp_printf(hmp, "%s%s%s%s",
+                               tpo->path ? ",path=" : "",
+                               tpo->path ?: "",
+                               tpo->cancel_path ? ",cancel-path=" : "",
+                               tpo->cancel_path ?: "");
             break;
         case TPM_TYPE_EMULATOR:
             teo = ti->options->u.emulator.data;
-            monitor_printf(mon, ",chardev=%s", teo->chardev);
+            monitor_hmp_printf(hmp, ",chardev=%s", teo->chardev);
             break;
         case TPM_TYPE__MAX:
             break;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         c++;
     }
     qapi_free_TPMInfoList(info_list);
 #else
-    monitor_printf(mon, "TPM device not supported\n");
+    monitor_hmp_printf(hmp, "TPM device not supported\n");
 #endif /* CONFIG_TPM */
 }
diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
index 3ae20f004b64..5d69ece15034 100644
--- a/target/i386/cpu-apic.c
+++ b/target/i386/cpu-apic.c
@@ -82,7 +82,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
 
 void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUState *cs;
 
     if (qdict_haskey(qdict, "apic-id")) {
@@ -98,7 +97,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 
 
     if (!cs) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 72bcab131f77..46762540ba65 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
     return addr;
 }
 
-static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
+static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
                       hwaddr pte, hwaddr mask)
 {
     addr = addr_canonical(env, addr);
 
-    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
-                   " %c%c%c%c%c%c%c%c%c\n",
-                   addr,
-                   pte & mask,
-                   pte & PG_NX_MASK ? 'X' : '-',
-                   pte & PG_GLOBAL_MASK ? 'G' : '-',
-                   pte & PG_PSE_MASK ? 'P' : '-',
-                   pte & PG_DIRTY_MASK ? 'D' : '-',
-                   pte & PG_ACCESSED_MASK ? 'A' : '-',
-                   pte & PG_PCD_MASK ? 'C' : '-',
-                   pte & PG_PWT_MASK ? 'T' : '-',
-                   pte & PG_USER_MASK ? 'U' : '-',
-                   pte & PG_RW_MASK ? 'W' : '-');
+    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
+                       " %c%c%c%c%c%c%c%c%c\n",
+                       addr,
+                       pte & mask,
+                       pte & PG_NX_MASK ? 'X' : '-',
+                       pte & PG_GLOBAL_MASK ? 'G' : '-',
+                       pte & PG_PSE_MASK ? 'P' : '-',
+                       pte & PG_DIRTY_MASK ? 'D' : '-',
+                       pte & PG_ACCESSED_MASK ? 'A' : '-',
+                       pte & PG_PCD_MASK ? 'C' : '-',
+                       pte & PG_PWT_MASK ? 'T' : '-',
+                       pte & PG_USER_MASK ? 'U' : '-',
+                       pte & PG_RW_MASK ? 'W' : '-');
 }
 
-static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 /* 4M pages */
-                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
+                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1));
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
+                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
                                   pte & ~PG_PSE_MASK,
                                   ~0xfff);
                     }
@@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
     }
 }
 
-static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 if (pde & PG_PRESENT_MASK) {
                     if (pde & PG_PSE_MASK) {
                         /* 2M pages with PAE, CR4.PSE is ignored */
-                        print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
+                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), pde,
                                   ~((hwaddr)(1 << 20) - 1));
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
@@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             pte = address_space_ldq_le(as, pt_addr + l3 * 8,
                                                        attrs, NULL);
                             if (pte & PG_PRESENT_MASK) {
-                                print_pte(mon, env, (l1 << 30) + (l2 << 21)
+                                print_pte(hmp, env, (l1 << 30) + (l2 << 21)
                                           + (l3 << 12),
                                           pte & ~PG_PSE_MASK,
                                           ~(hwaddr)0xfff);
@@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
 }
 
 #ifdef TARGET_X86_64
-static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
+static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as,
         uint64_t l0, uint64_t pml4_addr)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
@@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
             if (pdpe & PG_PSE_MASK) {
                 /* 1G pages, CR4.PSE is ignored */
-                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
+                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
                         pdpe, 0x3ffffc0000000ULL);
                 continue;
             }
@@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
                 if (pde & PG_PSE_MASK) {
                     /* 2M pages, CR4.PSE is ignored */
-                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
+                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
                             (l3 << 21), pde, 0x3ffffffe00000ULL);
                     continue;
                 }
@@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
                     pte = address_space_ldq_le(as, pt_addr + l4 * 8,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
+                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
                                 (l2 << 30) + (l3 << 21) + (l4 << 12),
                                 pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
                     }
@@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
     }
 }
 
-static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     uint64_t l0;
@@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
     for (l0 = 0; l0 < 512; l0++) {
         pml5e = address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, NULL);
         if (pml5e & PG_PRESENT_MASK) {
-            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL);
+            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL);
         }
     }
 }
@@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                tlb_info_la57(mon, env, as);
+                tlb_info_la57(hmp, env, as);
             } else {
-                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
+                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
             }
         } else
 #endif
         {
-            tlb_info_pae32(mon, env, as);
+            tlb_info_pae32(hmp, env, as);
         }
     } else {
-        tlb_info_32(mon, env, as);
+        tlb_info_32(hmp, env, as);
     }
 }
 
-static void mem_print(Monitor *mon, CPUArchState *env,
+static void mem_print(MonitorHMP *hmp, CPUArchState *env,
                       hwaddr *pstart, int *plast_prot,
                       hwaddr end, int prot)
 {
@@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     prot1 = *plast_prot;
     if (prot != prot1) {
         if (*pstart != -1) {
-            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
-                           HWADDR_FMT_plx " %c%c%c\n",
-                           addr_canonical(env, *pstart),
-                           addr_canonical(env, end),
-                           addr_canonical(env, end - *pstart),
-                           prot1 & PG_USER_MASK ? 'u' : '-',
-                           'r',
-                           prot1 & PG_RW_MASK ? 'w' : '-');
+            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
+                               HWADDR_FMT_plx " %c%c%c\n",
+                               addr_canonical(env, *pstart),
+                               addr_canonical(env, end),
+                               addr_canonical(env, end - *pstart),
+                               prot1 & PG_USER_MASK ? 'u' : '-',
+                               'r',
+                               prot1 & PG_RW_MASK ? 'w' : '-');
         }
         if (prot != 0)
             *pstart = end;
@@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     }
 }
 
-static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 prot = pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
@@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     } else {
                         prot = 0;
                     }
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
-static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     if (pde & PG_PSE_MASK) {
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                       PG_PRESENT_MASK);
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             } else {
                                 prot = 0;
                             }
-                            mem_print(mon, env, &start, &last_prot, end, prot);
+                            mem_print(hmp, env, &start, &last_prot, end, prot);
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
 
 #ifdef TARGET_X86_64
-static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                                        PG_PRESENT_MASK);
                         prot &= pml4e;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pd_addr = pdpe & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                     prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                                   PG_PRESENT_MASK);
                                     prot &= pml4e & pdpe;
-                                    mem_print(mon, env, &start,
+                                    mem_print(hmp, env, &start,
                                               &last_prot, end, prot);
                                 } else {
                                     pt_addr = pde & 0x3fffffffff000ULL;
@@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                         } else {
                                             prot = 0;
                                         }
-                                        mem_print(mon, env, &start,
+                                        mem_print(hmp, env, &start,
                                                   &last_prot, end, prot);
                                     }
                                 }
                             } else {
                                 prot = 0;
-                                mem_print(mon, env, &start,
+                                mem_print(hmp, env, &start,
                                           &last_prot, end, prot);
                             }
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
 }
 
-static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
         end = l0 << 48;
         if (!(pml5e & PG_PRESENT_MASK)) {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
             continue;
         }
 
@@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
             end = (l0 << 48) + (l1 << 39);
             if (!(pml4e & PG_PRESENT_MASK)) {
                 prot = 0;
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
                 continue;
             }
 
@@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 end = (l0 << 48) + (l1 << 39) + (l2 << 30);
                 if (pdpe & PG_PRESENT_MASK) {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                             PG_PRESENT_MASK);
                     prot &= pml5e & pml4e;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
                     if (pde & PG_PRESENT_MASK) {
                         prot = 0;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                 PG_PRESENT_MASK);
                         prot &= pml5e & pml4e & pdpe;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         } else {
                             prot = 0;
                         }
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     }
                 }
             }
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
 }
 #endif /* TARGET_X86_64 */
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                mem_info_la57(mon, env, as);
+                mem_info_la57(hmp, env, as);
             } else {
-                mem_info_la48(mon, env, as);
+                mem_info_la48(hmp, env, as);
             }
         } else
 #endif
         {
-            mem_info_pae32(mon, env, as);
+            mem_info_pae32(hmp, env, as);
         }
     } else {
-        mem_info_32(mon, env, as);
+        mem_info_32(hmp, env, as);
     }
 }
 
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 4473d02981ff..36a62e58be95 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -756,33 +756,32 @@ SevInfo *qmp_query_sev(Error **errp)
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SevInfo *info = sev_get_info();
 
     if (!info || !info->enabled) {
-        monitor_printf(mon, "SEV is not enabled\n");
+        monitor_hmp_printf(hmp, "SEV is not enabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
-    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
-    monitor_printf(mon, "build: %d\n", info->build_id);
-    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
-                   info->api_minor);
+    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->sev_type));
+    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
+    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
+    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
+                       info->api_minor);
 
     if (sev_snp_enabled()) {
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
-                                                                       : "off");
-        monitor_printf(mon, "SMT allowed: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
-                                                                       : "off");
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
+                                                                           : "off");
+        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
+                                                                           : "off");
     } else {
-        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
-        monitor_printf(mon, "key-sharing: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
+        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
+        monitor_hmp_printf(hmp, "key-sharing: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
     }
 
 out:
diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
index 5645a5d4d4f5..23c25283b27a 100644
--- a/target/m68k/monitor.c
+++ b/target/m68k/monitor.c
@@ -12,11 +12,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
index 5769829bdd7e..6e8a075f5a41 100644
--- a/target/ppc/monitor.c
+++ b/target/ppc/monitor.c
@@ -13,11 +13,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
index 4c9c0c793b36..59cc04b3d0fb 100644
--- a/target/riscv/monitor.c
+++ b/target/riscv/monitor.c
@@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, target_ulong addr)
     return addr;
 }
 
-static void print_pte_header(Monitor *mon)
+static void print_pte_header(MonitorHMP *hmp)
 {
-    monitor_printf(mon, PTE_HEADER_FIELDS);
-    monitor_printf(mon, PTE_HEADER_DELIMITER);
+    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
+    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
 }
 
-static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
+static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr,
                       hwaddr paddr, target_ulong size, int attr)
 {
     /* sanity check on vaddr */
@@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
         return;
     }
 
-    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
-                   " %c%c%c%c%c%c%c\n",
-                   addr_canonical(va_bits, vaddr),
-                   paddr, size,
-                   attr & PTE_R ? 'r' : '-',
-                   attr & PTE_W ? 'w' : '-',
-                   attr & PTE_X ? 'x' : '-',
-                   attr & PTE_U ? 'u' : '-',
-                   attr & PTE_G ? 'g' : '-',
-                   attr & PTE_A ? 'a' : '-',
-                   attr & PTE_D ? 'd' : '-');
+    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
+                       " %c%c%c%c%c%c%c\n",
+                       addr_canonical(va_bits, vaddr),
+                       paddr, size,
+                       attr & PTE_R ? 'r' : '-',
+                       attr & PTE_W ? 'w' : '-',
+                       attr & PTE_X ? 'x' : '-',
+                       attr & PTE_U ? 'u' : '-',
+                       attr & PTE_G ? 'g' : '-',
+                       attr & PTE_A ? 'a' : '-',
+                       attr & PTE_D ? 'd' : '-');
 }
 
-static void walk_pte(Monitor *mon, AddressSpace *as,
+static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
                      hwaddr base, target_ulong start,
                      int level, int ptidxbits, int ptesize, int va_bits,
                      target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
@@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 if ((*last_attr != attr) ||
                     (*last_paddr + *last_size != paddr) ||
                     (last_start + *last_size != start)) {
-                    print_pte(mon, va_bits, *vbase, *pbase,
+                    print_pte(hmp, va_bits, *vbase, *pbase,
                               *last_paddr + *last_size - *pbase, *last_attr);
 
                     *vbase = start;
@@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 *last_size = pgsize;
             } else {
                 /* pointer to the next level of the page table */
-                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, ptesize,
+                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, ptesize,
                          va_bits, vbase, pbase, last_paddr,
                          last_size, last_attr);
             }
@@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
 
 }
 
-static void mem_info_svxx(Monitor *mon, CPUArchState *env)
+static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
 {
     AddressSpace *as = env_cpu(env)->as;
     int levels, ptidxbits, ptesize, vm, va_bits;
@@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     va_bits = PGSHIFT + levels * ptidxbits;
 
     /* print header */
-    print_pte_header(mon);
+    print_pte_header(hmp);
 
     vbase = -1;
     pbase = -1;
@@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     last_attr = 0;
 
     /* walk page tables, starting from address 0 */
-    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
+    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
              &vbase, &pbase, &last_paddr, &last_size, &last_attr);
 
     /* don't forget the last one */
-    print_pte(mon, va_bits, vbase, pbase,
+    print_pte(hmp, va_bits, vbase, pbase,
               last_paddr + last_size - pbase, last_attr);
 }
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!riscv_cpu_cfg(env)->mmu) {
-        monitor_printf(mon, "S-mode MMU unavailable\n");
+        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
         return;
     }
 
     if (riscv_cpu_mxl(env) == MXL_RV32) {
         if (!(env->satp & SATP32_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     } else {
         if (!(env->satp & SATP64_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     }
 
-    mem_info_svxx(mon, env);
+    mem_info_svxx(hmp, env);
 }
 
 #ifdef CONFIG_TCG
diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
index 4e443152bf56..62998a9a57cb 100644
--- a/target/sh4/monitor.c
+++ b/target/sh4/monitor.c
@@ -26,33 +26,32 @@
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
 
-static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
+static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
 {
-    monitor_printf(mon, " tlb%i:\t"
-                   "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
-                   "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
-                   "dirty=%hhu writethrough=%hhu\n",
-                   idx,
-                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
-                   tlb->v, tlb->sh, tlb->c, tlb->pr,
-                   tlb->d, tlb->wt);
+    monitor_hmp_printf(hmp, " tlb%i:\t"
+                       "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
+                       "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
+                       "dirty=%hhu writethrough=%hhu\n",
+                       idx,
+                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
+                       tlb->v, tlb->sh, tlb->c, tlb->pr,
+                       tlb->d, tlb->wt);
 }
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env = monitor_hmp_get_cpu_env(hmp);
     int i;
 
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
-    monitor_printf (mon, "ITLB:\n");
+    monitor_hmp_printf(hmp, "ITLB:\n");
     for (i = 0 ; i < ITLB_SIZE ; i++)
-        print_tlb (mon, i, &env->itlb[i]);
-    monitor_printf (mon, "UTLB:\n");
+        print_tlb(hmp, i, &env->itlb[i]);
+    monitor_hmp_printf(hmp, "UTLB:\n");
     for (i = 0 ; i < UTLB_SIZE ; i++)
-        print_tlb (mon, i, &env->utlb[i]);
+        print_tlb(hmp, i, &env->utlb[i]);
 }
diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
index e826e584a918..36f109cbb568 100644
--- a/target/sparc/monitor.c
+++ b/target/sparc/monitor.c
@@ -29,11 +29,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
index b7b7387706f3..b9c4089b0fb1 100644
--- a/target/xtensa/monitor.c
+++ b/target/xtensa/monitor.c
@@ -28,11 +28,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index b2a884529598..530a3fee3c13 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
  */
 Monitor *monitor_cur(void) { return cur_mon; }
 Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort(); }
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) { abort(); }
 
 #ifndef _WIN32
 static void test_socket_fd_pass_name_good(void)
diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
index f62b2f294952..81a09ec5adfa 100644
--- a/tools/qemu-vnc/clipboard.c
+++ b/tools/qemu-vnc/clipboard.c
@@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboardRequest *req)
         "Cancelled clipboard request");
 
     g_clear_object(&req->invocation);
-    g_clear_handle_id(&req->timeout_id, g_source_remove);;
+    g_clear_handle_id(&req->timeout_id, g_source_remove);
 }
 
 static gboolean
@@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *info)
         vnc_dbus_clipboard_complete_request(
             req->invocation, info, req->type);
         g_clear_object(&req->invocation);
-        g_clear_handle_id(&req->timeout_id, g_source_remove);;
+        g_clear_handle_id(&req->timeout_id, g_source_remove);
         return;
     }
 
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 26597fefaa99..0aa50a901d37 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
     return NULL;
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     return -1;
 }
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 5a8158f4f4b6..a68f5b900d7c 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_TRACE_SIMPLE
 void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
     const char *arg = qdict_get_try_str(qdict, "arg");
 
@@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
             st_set_trace_file(arg);
         }
     } else {
-        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
-        hmp_help_cmd(mon, "trace-file");
+        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
+        hmp_help_cmd(hmp, "trace-file");
     }
 }
 #endif
 
 void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_try_str(qdict, "name");
     TraceEventInfoList *events;
     TraceEventInfoList *elem;
@@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (elem = events; elem != NULL; elem = elem->next) {
-        monitor_printf(mon, "%s : state %u\n",
-                       elem->value->name,
-                       elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
+        monitor_hmp_printf(hmp, "%s : state %u\n",
+                           elem->value->name,
+                           elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
     }
     qapi_free_TraceEventInfoList(events);
 }
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 186209fd0234..f611dd7ee457 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MouseInfoList *mice_list, *mouse;
 
     mice_list = qmp_query_mice(NULL);
     if (!mice_list) {
-        monitor_printf(mon, "No mouse devices connected\n");
+        monitor_hmp_printf(hmp, "No mouse devices connected\n");
         return;
     }
 
     for (mouse = mice_list; mouse; mouse = mouse->next) {
-        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
-                       mouse->value->current ? '*' : ' ',
-                       mouse->value->index, mouse->value->name,
-                       mouse->value->absolute ? " (absolute)" : "");
+        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
+                           mouse->value->current ? '*' : ' ',
+                           mouse->value->index, mouse->value->name,
+                           mouse->value->absolute ? " (absolute)" : "");
     }
 
     qapi_free_MouseInfoList(mice_list);
@@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
 /* Helper for hmp_info_vnc_clients, _servers */
-static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
+static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
                                   const char *name)
 {
-    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
-                   name,
-                   info->host,
-                   info->service,
-                   NetworkAddressFamily_str(info->family),
-                   info->websocket ? " (Websocket)" : "");
+    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
+                       name,
+                       info->host,
+                       info->service,
+                       NetworkAddressFamily_str(info->family),
+                       info->websocket ? " (Websocket)" : "");
 }
 
 /* Helper displaying and auth and crypt info */
-static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
+static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent,
                                    VncPrimaryAuth auth,
                                    VncVencryptSubAuth *vencrypt)
 {
-    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
-                   VncPrimaryAuth_str(auth),
-                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
+    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
+                       VncPrimaryAuth_str(auth),
+                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
 }
 
-static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *client)
+static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *client)
 {
     while (client) {
         VncClientInfo *cinfo = client->value;
 
-        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Client");
-        monitor_printf(mon, "    x509_dname: %s\n",
-                       cinfo->x509_dname ?: "none");
-        monitor_printf(mon, "    sasl_username: %s\n",
-                       cinfo->sasl_username ?: "none");
+        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Client");
+        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
+                           cinfo->x509_dname ?: "none");
+        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
+                           cinfo->sasl_username ?: "none");
 
         client = client->next;
     }
 }
 
-static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
+static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *server)
 {
     while (server) {
         VncServerInfo2 *sinfo = server->value;
-        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "Server");
-        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
+        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "Server");
+        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
                                sinfo->has_vencrypt ? &sinfo->vencrypt : NULL);
         server = server->next;
     }
@@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
 
 void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VncInfo2List *info2l, *info2l_head;
     Error *err = NULL;
 
@@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
     if (!info2l) {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
         return;
     }
 
     while (info2l) {
         VncInfo2 *info = info2l->value;
-        monitor_printf(mon, "%s:\n", info->id);
-        hmp_info_vnc_servers(mon, info->server);
-        hmp_info_vnc_clients(mon, info->clients);
+        monitor_hmp_printf(hmp, "%s:\n", info->id);
+        hmp_info_vnc_servers(hmp, info->server);
+        hmp_info_vnc_clients(hmp, info->clients);
         if (!info->server) {
             /*
              * The server entry displays its auth, we only need to
              * display in the case of 'reverse' connections where
              * there's no server.
              */
-            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
+            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
                                info->has_vencrypt ? &info->vencrypt : NULL);
         }
         if (info->display) {
-            monitor_printf(mon, "  Display: %s\n", info->display);
+            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
         }
         info2l = info2l->next;
     }
@@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_SPICE
 void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SpiceChannelList *chan;
     SpiceInfo *info;
     const char *channel_name;
@@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
     info = qmp_query_spice(NULL);
 
     if (!info->enabled) {
-        monitor_printf(mon, "Server: disabled\n");
+        monitor_hmp_printf(hmp, "Server: disabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "Server:\n");
+    monitor_hmp_printf(hmp, "Server:\n");
     if (info->has_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
-                       info->host, info->port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
+                           info->host, info->port);
     }
     if (info->has_tls_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
-                       info->host, info->tls_port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n",
+                           info->host, info->tls_port);
     }
-    monitor_printf(mon, "    migrated: %s\n",
-                   info->migrated ? "true" : "false");
-    monitor_printf(mon, "        auth: %s\n", info->auth);
-    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
-    monitor_printf(mon, "  mouse-mode: %s\n",
-                   SpiceQueryMouseMode_str(info->mouse_mode));
+    monitor_hmp_printf(hmp, "    migrated: %s\n",
+                       info->migrated ? "true" : "false");
+    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
+    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_version);
+    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
+                       SpiceQueryMouseMode_str(info->mouse_mode));
 
     if (!info->has_channels || info->channels == NULL) {
-        monitor_printf(mon, "Channels: none\n");
+        monitor_hmp_printf(hmp, "Channels: none\n");
     } else {
         for (chan = info->channels; chan; chan = chan->next) {
-            monitor_printf(mon, "Channel:\n");
-            monitor_printf(mon, "     address: %s:%s%s\n",
-                           chan->value->host, chan->value->port,
-                           chan->value->tls ? " [tls]" : "");
-            monitor_printf(mon, "     session: %" PRId64 "\n",
-                           chan->value->connection_id);
-            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "\n",
-                           chan->value->channel_type, chan->value->channel_id);
+            monitor_hmp_printf(hmp, "Channel:\n");
+            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
+                               chan->value->host, chan->value->port,
+                               chan->value->tls ? " [tls]" : "");
+            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
+                               chan->value->connection_id);
+            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId64 "\n",
+                               chan->value->channel_type, chan->value->channel_id);
 
             channel_name = "unknown";
             if (chan->value->channel_type > 0 &&
@@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
                 channel_name = channel_names[chan->value->channel_type];
             }
 
-            monitor_printf(mon, "     channel name: %s\n", channel_name);
+            monitor_hmp_printf(hmp, "     channel name: %s\n", channel_name);
         }
     }
 
@@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
     monitor_hmp_read_command(opaque, 1);
 }
 
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp)
 {
@@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
         return;
     }
     if (!arg) {
-        MonitorHMP *hmp = MONITOR_HMP(mon);
         monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
@@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t key_length)
 
 void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *keys = qdict_get_str(qdict, "keys");
     KeyValue *v = NULL;
     KeyValueList *head = NULL, **tail = &head;
@@ -432,7 +427,7 @@ out:
     return;
 
 err_out:
-    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
+    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, keys);
     goto out;
 }
 
diff --git a/util/error-report.c b/util/error-report.c
index 70cbd174ffae..c20e157780fa 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -38,7 +38,7 @@ error_vprintf_mon(const char *fmt, va_list ap)
     MonitorHMP *hmp = monitor_cur_hmp();
 
     if (hmp) {
-        return monitor_vprintf(MONITOR(hmp), fmt, ap);
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
 
     return vfprintf(stderr, fmt, ap);
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 0eecc05b0330..aabe670fda01 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -23,7 +23,7 @@ int qemu_vprintf(const char *fmt, va_list ap)
 {
     MonitorHMP *hmp = monitor_cur_hmp();
     if (hmp) {
-        return monitor_vprintf(MONITOR(hmp), fmt, ap);
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vprintf(fmt, ap);
 }
@@ -54,7 +54,7 @@ int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
 {
     if (!stream) {
         MonitorHMP *hmp = monitor_cur_hmp();
-        return hmp ? monitor_vprintf(MONITOR(hmp), fmt, ap) : -1;
+        return hmp ? monitor_hmp_vprintf(hmp, fmt, ap) : -1;
     }
     return vfprintf(stream, fmt, ap);
 }

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Sun Aug 16 19:15:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 19:15:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392351.1631357 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgKb-0002lZ-Td; Sun, 16 Aug 2026 19:15:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392351.1631357; Sun, 16 Aug 2026 19:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgKb-0002lS-Qe; Sun, 16 Aug 2026 19:15:41 +0000
Received: by outflank-mailman (input) for mailman id 1392351;
 Sun, 16 Aug 2026 19:15:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wvgKa-0002kn-38
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 19:15:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvgKZ-000W25-GT
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 21:15:39 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c12-8faa-0a2a0a5109dd-0a2a450cc58a-16
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:15:39 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c5a-f479-0a2a450c0019-aa0a857cbbb1-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:15:39 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-318-7f96DjF8Pgm4b6YL4EVX9A-1; Sun,
 16 Aug 2026 15:15:29 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id F308118009B9; Sun, 16 Aug 2026 19:15:27 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id AB84B195608A; Sun, 16 Aug 2026 19:15:26 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1786907738;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=g46sAmq3ha3DYCK2UfYcBYOEhlaJmE0VJpMuNI3hBc0=;
	b=Vw3Z6FAf3eVfYKpXnnE3ry9w0YTXPiFb+W7ArswLWqoXh0jxmk8pQog7hRoCrl8nvPFa5M
	Gmoc8+B94ixGC25HkdVuMeQgg9wWyHHbq8UB8HZuRbXOdI6RS6pWVzb/vGLtF1ATJY9dhN
	M3nCxdDEgDWGrG9MbSoV0789aHbqjHQ=
X-MC-Unique: 7f96DjF8Pgm4b6YL4EVX9A-1
X-Mimecast-MFC-AGG-ID: 7f96DjF8Pgm4b6YL4EVX9A_1786907728
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sun, 16 Aug 2026 23:13:06 +0400
Subject: [PATCH v3 39/49] qdev-monitor: make print_dev() callback take
 MonitorHMP
MIME-Version: 1.0
Message-Id: <20260816-qemu-no-hmp-v3-39-e53fc35bc550@redhat.com>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
In-Reply-To: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=8734;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=cx2OSLe23AC3qAPOuez5hwYS/HxH2LycawW7o4xWb/s=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqggu0colGAL5Urj3/4h6eSdW96XE2/1InxU1CL
 lbwnRPnuiKJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaoILtAAKCRDa6OEJdZac
 5YsCD/9d6LecLqyFpUAiOjySTCaIn4pgwvHvAM5YCSI7WTFHDMhzfyNfks15weyh5Q2vcwxXdBe
 ApjrTS4/4pAayYDBCw37akCTxBfLuu8hH7gPzsM/miXzSxmITm3z51cd8IGDwNKX2WP1xXWYgRr
 uW3+prn7q7hA/f6+fiVSjUS8btJgFfzKzQ5DnB7xtSxMHvI6JZI7gkcSzqtJ4wWWz9Oz733x9VS
 upQplMPXLnncEnxxiTgyzY6iQWicVnr8gLJ9hq5tAjVw+0FRYTL4K75OjssHbREjjPqhA6cCQfG
 puHlPZ+p4HDk5BOb9/DKbiQG2gRvjvv/ZMJLK130EPMPaK4wZpEuNdmYYXzoxWr8ogUbhuR3tyt
 v1qj7Al73J7oi0mXTJTTV4r4JWwtwbiOFmVpYZkPACHEjQ2cwwEqzfCgNjoCQ9LlEQuFDO9MyLF
 y5EF3lYu1yINwa72YD6Jc39Az7QNelcnOehkOVLNNgN590FuvP8diG/9FH97fJonwp/8dPbkyog
 zV0evM9ui0n1lFFvPOnNtBz4mnH7DeXpMtt/SjYUpzSgOBnDZigqBzGBoWE8vbPeGJvWIGiaMmS
 A4XaQ8Zt+1/tSbZeEkTMx4/oRrPz3RSQsDnRDG3uSlZIo0VRRwWL4LxI46Zfdwdv5nlenC9N9Wg
 FrEHvaJmEMecCyA==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12
X-Mimecast-MFC-PROC-ID: UPaWkOcRGBCD-CdOiAYDmozhIUVnst6SrkkDj9QKZH4_1786907728
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786907739-024DFA5B-CE964D28/0/0
X-purgate-type: clean
X-purgate-size: 8736

The callback is specific to HMP context, avoid unsafe MONITOR_HMP()
cast.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/char/virtio-serial-bus.c | 6 +++---
 hw/core/sysbus.c            | 5 ++---
 hw/misc/auxbus.c            | 7 +++----
 hw/pci/pci-hmp-cmds.c       | 3 +--
 hw/pci/pci-internal.h       | 2 +-
 hw/usb/bus.c                | 5 ++---
 hw/xen/xen-bus.c            | 3 +--
 include/hw/core/qdev.h      | 3 ++-
 system/qdev-monitor.c       | 7 +++----
 9 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 33fdc0846ac3..4dcc4516e45e 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -834,11 +834,11 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+    monitor_hmp_printf(hmp, "%*sport %d, guest %s, host %s, throttle %s\n",
                        indent, "", port->id,
                        port->guest_connected ? "on" : "off",
                        port->host_connected ? "on" : "off",
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 82130ba04698..31c4fdf79d48 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,7 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -249,10 +249,9 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ffa76f83016b..0bb89c5a60ab 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,7 +47,7 @@
 } while (0)
 
 
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
@@ -288,7 +288,7 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
     AUXSlave *s;
@@ -300,8 +300,7 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon),
-                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+    monitor_hmp_printf(hmp, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
                        indent, "",
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 500f821246a9..bcccfaf07f4d 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,9 +135,8 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
diff --git a/hw/pci/pci-internal.h b/hw/pci/pci-internal.h
index a7d6d8a7324e..b7231fab5dc9 100644
--- a/hw/pci/pci-internal.h
+++ b/hw/pci/pci-internal.h
@@ -16,7 +16,7 @@ extern PCIHostStateList pci_host_bridges;
 
 const pci_class_desc *get_class_desc(int class);
 PCIBus *pci_find_bus_nr(PCIBus *bus, int bus_num);
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+void pcibus_dev_print(MonitorHMP *mon, DeviceState *dev, int indent);
 
 int pcie_aer_parse_error_string(const char *error_name,
                                 uint32_t *status, bool *correctable);
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index fe3dbfa2227c..8bd25a9d872a 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,7 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -544,9 +544,8 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 4075b5b001ae..b81a067e7753 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,9 +101,8 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
-static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
+static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 37f7d3355193..1391dc060caf 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -10,6 +10,7 @@
 #include "qom/object.h"
 #include "hw/core/hotplug.h"
 #include "hw/core/resettable.h"
+#include "monitor/hmp.h"
 
 /**
  * DOC: The QEMU Device API
@@ -323,7 +324,7 @@ struct BusClass {
     ObjectClass parent_class;
 
     /* FIXME first arg should be BusState */
-    void (*print_dev)(Monitor *mon, DeviceState *dev, int indent);
+    void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 3860ada2a237..13ac9f8f3be1 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -790,18 +790,17 @@ static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
     }
 }
 
-static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int indent)
+static void bus_print_dev(BusState *bus, MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     BusClass *bc = BUS_GET_CLASS(bus);
 
     if (bc->print_dev) {
-        bc->print_dev(mon, dev, indent);
+        bc->print_dev(hmp, dev, indent);
     }
 }
 
 static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -828,7 +827,7 @@ static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
         qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
-    bus_print_dev(dev->parent_bus, mon, dev, indent);
+    bus_print_dev(dev->parent_bus, hmp, dev, indent);
 }
 
 static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Sun Aug 16 19:19:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 19:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392367.1631366 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgOd-0003mx-Bp; Sun, 16 Aug 2026 19:19:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392367.1631366; Sun, 16 Aug 2026 19:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvgOd-0003mq-9H; Sun, 16 Aug 2026 19:19:51 +0000
Received: by outflank-mailman (input) for mailman id 1392367;
 Sun, 16 Aug 2026 19:19:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wvgOb-0003mk-RD
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 19:19:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvgOb-003gvQ-81
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 21:19:49 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820cea-e002-0a2a0a5209dd-0a2a450c83da-40
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:19:49 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a820c63-f479-0a2a450c0019-aa0a857c9b2b-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 21:15:48 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-488-gT1D9E1CPqyZIVbIv-Pseg-1; Sun,
 16 Aug 2026 15:15:44 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id A4EE4180035C; Sun, 16 Aug 2026 19:15:42 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id C118418005BB; Sun, 16 Aug 2026 19:15:41 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1786907747;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=S+aPoqqisu2J1a6Pr1LukLQArfAFqh3ZKUjQId9ja9Q=;
	b=AbFcKZ7QUA/Sjp5Y8Qvj0mXu5cYOlJ7B+kXbWhMaPSZII8pDwwQjXrZn0EuI8PgJCsomei
	EeZV5kiLRukpqNBWBFIsPCQMQnAMKEUFjhZSj/Plc3rtTd+dMRQHZ5UARB3HvF3Nah+jmh
	yZSdVBQ5o4LbvrpAiU6ZhOg1Lpn/Mv0=
X-MC-Unique: gT1D9E1CPqyZIVbIv-Pseg-1
X-Mimecast-MFC-AGG-ID: gT1D9E1CPqyZIVbIv-Pseg_1786907742
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sun, 16 Aug 2026 23:13:10 +0400
Subject: [PATCH v3 43/49] hw: guard BusClass::print_dev with CONFIG_HMP
MIME-Version: 1.0
Message-Id: <20260816-qemu-no-hmp-v3-43-e53fc35bc550@redhat.com>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
In-Reply-To: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=9448;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=DXclgUj/8CLlvYxtSJ1BdyFBBPgVkYBaEJYVSnhsRxE=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqggu03GEqM9u1lu43NiKgaNHGoOA1go7taxyi+
 dqIU23XHySJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaoILtAAKCRDa6OEJdZac
 5Sz4D/0RiBypoUdxuRw/F+B/mUi+BaEAu4ujWxKKO6MUcbPkirsbNSwCHAYGgpuZpp3mIDw5TS4
 ICozSRXzzE8xjNBngzE+E0wfpzKNovACKPeNZSYVDlLdlrhp1Ebbydh6EU8ygmH4PM8kQl4xsRf
 ZmF8o4m/5U/1K6d7xXByF/Zzpa6g7iYG62HjEcRsrZD4PN/eCzXfZpZD/VQ1fx9zv3R0pmr5Bor
 aRzxXCSussVZ/HOcHNbyZC1zqPeRSmsbscVqWgoem8Zio9t7pAjXuZKSIO8548w3C1XssvCf7iF
 8Z4aFNKgKKawTRlOP4386LspSUzJYP/KHHIb8pA31a0nAkUSy2oVB5pCVa1mhS5SEUff+wsGBlA
 GaDwAuxUmA9ux4o4vL2+kBXAZWgBZISP7PqGeDGNxU3xfd7NxxvAoJybJpUDs6cu6ztGEaz9jyH
 UHmFUtiQVcacC0ovMccHPchRYr5u+7aXB8xyMDzLfQx/0Ej21HwJ1rQahlShNmdUIyutLWjXbwQ
 9Fq9IAJVrAwFFjzdNrGtGTdUYECO4iTMXC/BypTDFo8q+jx9lWrboDLdrjfCExFPay389rXDQSq
 2E2k6TKfyPvTIx8/NXx5gKsWEsGyZYrvtVAYXMa0deMTVkxpRL0+Z3UczA4vspHv8ZMqtIKbH75
 4CgqI1VyIH7zdvg==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: zj-NHutQ9KM1RRzvduw_v6KLBAHf1BAIg5aFTCDColU_1786907742
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786907748-022C0A5B-2C48E110/13/0
X-purgate-type: clean
X-purgate-size: 9450

The print_dev callback is only used by HMP 'info qtree'. Guard the field
in BusClass, all implementations, and the caller with CONFIG_HMP.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/char/virtio-serial-bus.c |  6 ++++++
 hw/core/sysbus.c            |  6 ++++++
 hw/misc/auxbus.c            | 16 +++++++++++-----
 hw/pci/pci-hmp-cmds.c       |  2 ++
 hw/pci/pci.c                |  2 ++
 hw/usb/bus.c                |  6 ++++++
 hw/xen/xen-bus.c            |  4 ++++
 include/hw/core/qdev.h      |  2 ++
 8 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 4dcc4516e45e..83a033ce8555 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,9 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -823,8 +825,10 @@ static const Property virtser_props[] = {
 
 static void virtser_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
     k->print_dev = virtser_bus_dev_print;
+#endif
 }
 
 static const TypeInfo virtser_bus_info = {
@@ -834,6 +838,7 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
@@ -844,6 +849,7 @@ static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent
                        port->host_connected ? "on" : "off",
                        port->throttled ? "on" : "off");
 }
+#endif
 
 /* This function is only used if a port id is not provided by the user */
 static uint32_t find_free_port_id(VirtIOSerial *vser)
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 31c4fdf79d48..fe8f867a8d9c 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,9 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -76,7 +78,9 @@ static void system_bus_class_init(ObjectClass *klass, const void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = sysbus_dev_print;
+#endif
     k->get_fw_dev_path = sysbus_get_fw_dev_path;
 }
 
@@ -249,6 +253,7 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
@@ -261,6 +266,7 @@ static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            indent, "", s->mmio[i].addr, size);
     }
 }
+#endif
 
 static char *sysbus_get_fw_dev_path(DeviceState *dev)
 {
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 0bb89c5a60ab..3f17784d9b8a 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,18 +47,22 @@
 } while (0)
 
 
+#ifdef CONFIG_HMP
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
 static void aux_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
 
     /* AUXSlave has an MMIO so we need to change the way we print information
      * in monitor.
      */
     k->print_dev = aux_slave_dev_print;
+#endif
 }
 
 AUXBus *aux_bus_init(DeviceState *parent, const char *name)
@@ -91,11 +95,6 @@ void aux_map_slave(AUXSlave *aux_dev, hwaddr addr)
     memory_region_add_subregion(bus->aux_io, addr, aux_dev->mmio);
 }
 
-static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
-{
-    return (dev == DEVICE(bus->bridge));
-}
-
 I2CBus *aux_get_i2c_bus(AUXBus *bus)
 {
     return aux_bridge_get_i2c_bus(bus->bridge);
@@ -288,6 +287,12 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
+#ifdef CONFIG_HMP
+static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
+{
+    return (dev == DEVICE(bus->bridge));
+}
+
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
@@ -305,6 +310,7 @@ static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
 }
+#endif
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
 {
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index bcccfaf07f4d..879011da1384 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,6 +135,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
+#ifdef CONFIG_HMP
 void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     PCIDevice *d = (PCIDevice *)dev;
@@ -170,6 +171,7 @@ void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            r->addr, r->addr + r->size - 1);
     }
 }
+#endif
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d3191609e283..9e5db9529379 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -290,7 +290,9 @@ static void pci_bus_class_init(ObjectClass *klass, const void *data)
     ResettableClass *rc = RESETTABLE_CLASS(klass);
     FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = pcibus_dev_print;
+#endif
     k->get_dev_path = pcibus_get_dev_path;
     k->get_fw_dev_path = pcibus_get_fw_dev_path;
     k->realize = pci_bus_realize;
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 8bd25a9d872a..5cc5ffec33a1 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,9 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -32,7 +34,9 @@ static void usb_bus_class_init(ObjectClass *klass, const void *data)
     BusClass *k = BUS_CLASS(klass);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = usb_bus_dev_print;
+#endif
     k->get_dev_path = usb_get_dev_path;
     k->get_fw_dev_path = usb_get_fw_dev_path;
     hc->unplug = qdev_simple_device_unplug_cb;
@@ -544,6 +548,7 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     USBDevice *dev = USB_DEVICE(qdev);
@@ -555,6 +560,7 @@ static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
                        usb_speed(dev->speed), dev->product_desc,
                        dev->attached ? ", attached" : "");
 }
+#endif
 
 static char *usb_get_dev_path(DeviceState *qdev)
 {
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index b81a067e7753..1762816bf469 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,6 +101,7 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
+#ifdef CONFIG_HMP
 static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     XenDevice *xendev = XEN_DEVICE(dev);
@@ -108,6 +109,7 @@ static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
                        indent, "", xendev->name, xendev->frontend_id);
 }
+#endif
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
 {
@@ -386,7 +388,9 @@ static void xen_bus_class_init(ObjectClass *class, const void *data)
     BusClass *bus_class = BUS_CLASS(class);
     HotplugHandlerClass *hotplug_class = HOTPLUG_HANDLER_CLASS(class);
 
+#ifdef CONFIG_HMP
     bus_class->print_dev = xen_bus_print_dev;
+#endif
     bus_class->get_dev_path = xen_bus_get_dev_path;
     bus_class->realize = xen_bus_realize;
     bus_class->unrealize = xen_bus_unrealize;
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 1391dc060caf..f054a214fc6a 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -323,8 +323,10 @@ DECLARE_OBJ_CHECKERS(BusState, BusClass,
 struct BusClass {
     ObjectClass parent_class;
 
+#ifdef CONFIG_HMP
     /* FIXME first arg should be BusState */
     void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
+#endif
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Sun Aug 16 20:21:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Aug 2026 20:21:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392385.1631377 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvhMP-0004gB-Og; Sun, 16 Aug 2026 20:21:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392385.1631377; Sun, 16 Aug 2026 20:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvhMP-0004g4-K5; Sun, 16 Aug 2026 20:21:37 +0000
Received: by outflank-mailman (input) for mailman id 1392385;
 Sun, 16 Aug 2026 20:21:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dg@treblig.org>) id 1wvhMN-0004fv-Qj
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 20:21:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvhMM-009b13-Ly
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 22:21:34 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dg@treblig.org>)
 id 6a821b4d-bab6-0a2a0a5309dd-0a2a450ada1e-28
 for <multiple-recipients>; Sun, 16 Aug 2026 22:21:34 +0200
Received: from [46.235.229.95] (helo=mx.treblig.org)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dg@treblig.org>)
 id 6a821bcd-f2d2-0a2a450a0019-2eebe55fca52-3
 for <multiple-recipients>; Sun, 16 Aug 2026 22:21:34 +0200
Received: from dg by mx.treblig.org with local (Exim 4.98.2)
 (envelope-from <dg@treblig.org>) id 1wvhMJ-00000002ON7-1Cyz;
 Sun, 16 Aug 2026 20:21:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=bytemarkmx header.d=treblig.org header.i="@treblig.org" header.h="Content-Type:MIME-Version:Message-ID:Subject:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org
	; s=bytemarkmx; h=Content-Type:MIME-Version:Message-ID:Subject:From:Date:From
	:Subject; bh=w6aSpRQj1hAs1JWzLlIrrg1SAUYOR2a6cJIoLPmAv1U=; b=SODqR9Y+8R31jQEh
	2JrtBlSYx2abT02vRzl0eT+kIqffQQq5XgDnaNsOo52lR3hZYkF6fySHiTgNjRbtWVL30IvxJ8BfJ
	ed7hvfx7jRDRZAzE5yPoks/TsiXQ7GD2EuoRQDDvrocmp8UuSzuVC8k3Ss/LSbpien84nLPiOe76D
	D+R8x9P7kWfM+Vf8HU69vXAI2u+Bhzblr1mX+Z93KXXdYTKQQhJLz2M0pKE7JRC1dC6gqfZJ7g2uz
	t3F/lrr9efDoFO7XqJhvefVD8UBp3nObyPe+VaXWQ/ynUOqe6c/TG1/WiJp+Nt5F5R6R7hDF5CdWE
	5v14zvhnW50+NFBUCg==;
Date: Sun, 16 Aug 2026 20:21:31 +0000
From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org,
	Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <philmd@mailo.com>,
	Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= <berrange@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alex =?iso-8859-1?Q?Benn=E9e?= <alex.bennee@linaro.org>,
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Brian Cain <brian.cain@oss.qualcomm.com>,
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Jason Wang <jasowangio@gmail.com>,
	Yoshinori Sato <yoshinori.sato@nifty.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 30/49] monitor: isolate HMP declarations in hmp.h
Message-ID: <aoIby2_fIJXLxISu@gallifrey>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
 <20260816-qemu-no-hmp-v3-30-e53fc35bc550@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260816-qemu-no-hmp-v3-30-e53fc35bc550@redhat.com>
X-Chocolate: 70 percent or better cocoa solids preferably
X-Operating-System: Linux/6.12.101+deb13-amd64 (x86_64)
X-Uptime: 20:21:27 up 9 days, 23:59,  2 users,  load average: 0.07, 0.03, 0.01
User-Agent: Mutt/2.2.13 (2024-03-09)
X-purgate-ID: tlsNG-4011c0/1786911694-4BCD3CFC-6216638C/0/0
X-purgate-type: clean
X-purgate-size: 17098

* Marc-Andr� Lureau (marcandre.lureau@redhat.com) wrote:
> Also rename password & commands with hmp in the name, while at it.
> Other functions need larger changes which we will take care of next.
> 
> Signed-off-by: Marc-Andr� Lureau <marcandre.lureau@redhat.com>

Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>

> ---
>  accel/accel-system.c           |  1 +
>  accel/tcg/monitor.c            |  1 +
>  chardev/char.c                 |  2 +-
>  disas/disas-mon.c              |  1 +
>  gdbstub/system.c               |  2 +-
>  hw/char/virtio-serial-bus.c    |  1 +
>  hw/core/machine-hmp-cmds.c     |  1 -
>  hw/core/sysbus.c               |  1 +
>  hw/hexagon/hexagon_tlb.c       |  1 +
>  hw/misc/auxbus.c               |  1 +
>  hw/usb/bus.c                   |  1 +
>  hw/usb/host-libusb.c           |  1 +
>  hw/xen/xen-bus.c               |  1 +
>  include/monitor/hmp.h          | 21 +++++++++++++++++++++
>  include/monitor/monitor.h      | 18 ------------------
>  monitor/hmp.c                  |  8 ++++----
>  monitor/monitor-internal.h     |  1 +
>  net/slirp.c                    |  1 +
>  stubs/monitor-core.c           |  1 +
>  stubs/monitor-internal.c       |  2 +-
>  target/rx/disas.c              |  1 +
>  tests/unit/test-util-sockets.c |  1 +
>  tools/qemu-vnc/stubs.c         |  1 +
>  trace/trace-hmp-cmds.c         |  1 -
>  ui/ui-hmp-cmds.c               |  4 ++--
>  util/error-report.c            |  2 +-
>  util/qemu-print.c              |  1 +
>  27 files changed, 48 insertions(+), 30 deletions(-)
> 
> diff --git a/accel/accel-system.c b/accel/accel-system.c
> index 9176665202d2..977804c4048a 100644
> --- a/accel/accel-system.c
> +++ b/accel/accel-system.c
> @@ -28,6 +28,7 @@
>  #include "qom/compat-properties.h"
>  #include "qapi/qapi-commands-accelerator.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "hw/core/boards.h"
>  #include "hw/core/cpu.h"
>  #include "accel/accel-ops.h"
> diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
> index be5c1950177c..74170ddef708 100644
> --- a/accel/tcg/monitor.c
> +++ b/accel/tcg/monitor.c
> @@ -11,6 +11,7 @@
>  #include "qapi/type-helpers.h"
>  #include "qapi/qapi-commands-machine.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "system/tcg.h"
>  #include "tcg/tcg.h"
>  #include "internal-common.h"
> diff --git a/chardev/char.c b/chardev/char.c
> index c6c8133f5c1d..9da0911e503c 100644
> --- a/chardev/char.c
> +++ b/chardev/char.c
> @@ -24,7 +24,7 @@
>  
>  #include "qemu/osdep.h"
>  #include "qemu/cutils.h"
> -#include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "monitor/qmp-helpers.h"
>  #include "qemu/config-file.h"
>  #include "qemu/error-report.h"
> diff --git a/disas/disas-mon.c b/disas/disas-mon.c
> index 9c693618c277..bc9dec3a7761 100644
> --- a/disas/disas-mon.c
> +++ b/disas/disas-mon.c
> @@ -10,6 +10,7 @@
>  #include "system/memory.h"
>  #include "hw/core/cpu.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  
>  /*
>   * Get LENGTH bytes from info's buffer, at target address memaddr.
> diff --git a/gdbstub/system.c b/gdbstub/system.c
> index 070bc26f416c..8a1cdb11db36 100644
> --- a/gdbstub/system.c
> +++ b/gdbstub/system.c
> @@ -29,7 +29,7 @@
>  #include "hw/core/boards.h"
>  #include "chardev/char.h"
>  #include "chardev/char-fe.h"
> -#include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "trace.h"
>  #include "internals.h"
>  
> diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
> index c1973f0248fc..02604740f86a 100644
> --- a/hw/char/virtio-serial-bus.c
> +++ b/hw/char/virtio-serial-bus.c
> @@ -25,6 +25,7 @@
>  #include "qemu/module.h"
>  #include "migration/qemu-file-types.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qemu/error-report.h"
>  #include "qemu/queue.h"
>  #include "hw/core/qdev-properties.h"
> diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
> index 686304bafab5..1c700aad3587 100644
> --- a/hw/core/machine-hmp-cmds.c
> +++ b/hw/core/machine-hmp-cmds.c
> @@ -15,7 +15,6 @@
>  
>  #include "qemu/osdep.h"
>  #include "monitor/hmp.h"
> -#include "monitor/monitor.h"
>  #include "qapi/error.h"
>  #include "qapi/qapi-builtin-visit.h"
>  #include "qapi/qapi-commands-accelerator.h"
> diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> index 3e1160ee921d..13df7cbafe10 100644
> --- a/hw/core/sysbus.c
> +++ b/hw/core/sysbus.c
> @@ -21,6 +21,7 @@
>  #include "qapi/error.h"
>  #include "hw/core/sysbus.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "system/address-spaces.h"
>  
>  static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
> diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
> index b6d4aff389e5..2d878cee736d 100644
> --- a/hw/hexagon/hexagon_tlb.c
> +++ b/hw/hexagon/hexagon_tlb.c
> @@ -12,6 +12,7 @@
>  #include "hw/core/resettable.h"
>  #include "migration/vmstate.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qapi/error.h"
>  #include "exec/page-protection.h"
>  #include "exec/target_page.h"
> diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
> index 877f34560626..ac2525b90fec 100644
> --- a/hw/misc/auxbus.c
> +++ b/hw/misc/auxbus.c
> @@ -33,6 +33,7 @@
>  #include "hw/misc/auxbus.h"
>  #include "hw/i2c/i2c.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qapi/error.h"
>  
>  #ifndef DEBUG_AUX
> diff --git a/hw/usb/bus.c b/hw/usb/bus.c
> index 3b6fbd46ac3f..9b9b2e7c2f8f 100644
> --- a/hw/usb/bus.c
> +++ b/hw/usb/bus.c
> @@ -9,6 +9,7 @@
>  #include "system/system.h"
>  #include "migration/vmstate.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "trace.h"
>  #include "qemu/cutils.h"
>  
> diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> index b9f3ad3f66dd..af67d5dfeb10 100644
> --- a/hw/usb/host-libusb.c
> +++ b/hw/usb/host-libusb.c
> @@ -48,6 +48,7 @@
>  #include "qapi/error.h"
>  #include "migration/vmstate.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qemu/error-report.h"
>  #include "qemu/main-loop.h"
>  #include "qemu/module.h"
> diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> index dfad2bc5085f..a563f6066bb4 100644
> --- a/hw/xen/xen-bus.c
> +++ b/hw/xen/xen-bus.c
> @@ -17,6 +17,7 @@
>  #include "hw/xen/xen-bus.h"
>  #include "hw/xen/xen-bus-helper.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qapi/error.h"
>  #include "qobject/qdict.h"
>  #include "system/system.h"
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 9258a049bffb..166cd4100c63 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -18,6 +18,9 @@
>  #include "qapi/qapi-types-common.h"
>  #include "monitor/monitor.h"
>  
> +#define TYPE_MONITOR_HMP "monitor-hmp"
> +OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
> +
>  #define HMP_STUB(cmd) \
>      void hmp_##cmd(Monitor *mon, const QDict *qdict) \
>      { \
> @@ -30,6 +33,24 @@ struct MonitorDef {
>      int64_t (*get_value)(Monitor *mon, const MonitorDef *md, int offset);
>  };
>  
> +void monitor_new_hmp(const char *id, const char *chardev_id,
> +                     bool use_readline, Error **errp);
> +
> +int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> +    G_GNUC_PRINTF(2, 0);
> +int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
> +void monitor_printc(Monitor *mon, int ch);
> +
> +void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
> +int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> +                              void *opaque);
> +
> +void monitor_register_hmp(const char *name, bool info,
> +                          void (*cmd)(Monitor *mon, const QDict *qdict));
> +void monitor_register_hmp_info_hrt(const char *name,
> +                                   HumanReadableText *(*handler)(Error **errp));
> +
> +
>  CPUArchState *mon_get_cpu_env(Monitor *mon);
>  CPUState *mon_get_cpu(Monitor *mon);
>  
> diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
> index 9f048ba103b5..72a8f6ea5b4f 100644
> --- a/include/monitor/monitor.h
> +++ b/include/monitor/monitor.h
> @@ -10,9 +10,6 @@
>  #define TYPE_MONITOR "monitor"
>  OBJECT_DECLARE_TYPE(Monitor, MonitorClass, MONITOR);
>  
> -#define TYPE_MONITOR_HMP "monitor-hmp"
> -OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
> -
>  #define TYPE_MONITOR_QMP "monitor-qmp"
>  OBJECT_DECLARE_TYPE(MonitorQMP, MonitorQMPClass, MONITOR_QMP);
>  
> @@ -30,8 +27,6 @@ void monitor_init_globals_core(void);
>  char *monitor_compat_id(void);
>  void monitor_new_qmp(const char *id, const char *chardev_id,
>                       bool pretty, Error **errp);
> -void monitor_new_hmp(const char *id, const char *chardev_id,
> -                     bool use_readline, Error **errp);
>  int monitor_new(MonitorOptions *opts, bool allow_hmp, Error **errp);
>  int monitor_new_opts(QemuOpts *opts, Error **errp);
>  void monitor_cleanup(void);
> @@ -43,28 +38,15 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp);
>  int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp);
>  
>  int monitor_puts(Monitor *mon, const char *str);
> -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> -    G_GNUC_PRINTF(2, 0);
> -int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
> -void monitor_printc(Monitor *mon, int ch);
>  void monitor_flush(Monitor *mon);
>  int monitor_get_cpu_index(Monitor *mon);
>  
>  int monitor_puts_locked(Monitor *mon, const char *str);
>  void monitor_flush_locked(Monitor *mon);
>  
> -void monitor_read_command(MonitorHMP *hmp, int show_prompt);
> -int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> -                          void *opaque);
> -
>  AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
>                                  const char *opaque, Error **errp);
>  int monitor_fdset_dup_fd_add(int64_t fdset_id, int flags, Error **errp);
>  void monitor_fdset_dup_fd_remove(int dup_fd);
>  
> -void monitor_register_hmp(const char *name, bool info,
> -                          void (*cmd)(Monitor *mon, const QDict *qdict));
> -void monitor_register_hmp_info_hrt(const char *name,
> -                                   HumanReadableText *(*handler)(Error **errp));
> -
>  #endif /* MONITOR_H */
> diff --git a/monitor/hmp.c b/monitor/hmp.c
> index 8134dfaad4bb..b4d05d47c4bf 100644
> --- a/monitor/hmp.c
> +++ b/monitor/hmp.c
> @@ -136,7 +136,7 @@ static void monitor_command_cb(void *opaque, const char *cmdline,
>      monitor_resume(&hmp->parent_obj);
>  }
>  
> -void monitor_read_command(MonitorHMP *hmp, int show_prompt)
> +void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt)
>  {
>      if (!hmp->rs) {
>          return;
> @@ -148,8 +148,8 @@ void monitor_read_command(MonitorHMP *hmp, int show_prompt)
>      }
>  }
>  
> -int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> -                          void *opaque)
> +int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> +                              void *opaque)
>  {
>      if (hmp->rs) {
>          readline_start(hmp->rs, "Password: ", 1, readline_func, opaque);
> @@ -1647,7 +1647,7 @@ static void monitor_hmp_complete(UserCreatable *uc, Error **errp)
>                                      monitor_readline_flush,
>                                      hmp,
>                                      monitor_find_completion);
> -            monitor_read_command(hmp, 0);
> +            monitor_hmp_read_command(hmp, 0);
>          }
>  
>          qemu_chr_fe_set_handlers(&hmp->parent_obj.chr,
> diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
> index fdeeeb853636..ee9ba0c8231e 100644
> --- a/monitor/monitor-internal.h
> +++ b/monitor/monitor-internal.h
> @@ -27,6 +27,7 @@
>  
>  #include "chardev/char-fe.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qapi/qapi-emit-events.h"
>  #include "qapi/qapi-types-control.h"
>  #include "qapi/qapi-types-qom.h"
> diff --git a/net/slirp.c b/net/slirp.c
> index 517dd23be14b..9bf09a2c8bc9 100644
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -36,6 +36,7 @@
>  #include "clients.h"
>  #include "hub.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qemu/error-report.h"
>  #include "qemu/sockets.h"
>  #include <libslirp.h>
> diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
> index a7c32297c90a..b0c7002bd406 100644
> --- a/stubs/monitor-core.c
> +++ b/stubs/monitor-core.c
> @@ -1,5 +1,6 @@
>  #include "qemu/osdep.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qapi/qapi-emit-events.h"
>  
>  Monitor *monitor_cur(void)
> diff --git a/stubs/monitor-internal.c b/stubs/monitor-internal.c
> index 731fad221ecc..6f69f1f14ae4 100644
> --- a/stubs/monitor-internal.c
> +++ b/stubs/monitor-internal.c
> @@ -1,6 +1,6 @@
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
> -#include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  
>  int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
>  {
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 67b932882914..0eb2ee6f4507 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -19,6 +19,7 @@
>  #include "qemu/osdep.h"
>  #include "disas/dis-asm.h"
>  #include "qemu/bitops.h"
> +#include "monitor/hmp.h"
>  #include "cpu.h"
>  
>  typedef struct DisasContext {
> diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
> index ab3f39c3efb5..b2a884529598 100644
> --- a/tests/unit/test-util-sockets.c
> +++ b/tests/unit/test-util-sockets.c
> @@ -24,6 +24,7 @@
>  #include "qapi/error.h"
>  #include "socket-helpers.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  
>  static void test_fd_is_socket_bad(void)
>  {
> diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
> index 1c82d8cff430..26597fefaa99 100644
> --- a/tools/qemu-vnc/stubs.c
> +++ b/tools/qemu-vnc/stubs.c
> @@ -9,6 +9,7 @@
>  #include "system/runstate.h"
>  #include "hw/core/qdev.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "migration/vmstate.h"
>  
>  bool runstate_is_running(void)
> diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
> index 390173095cff..c8f0133abecf 100644
> --- a/trace/trace-hmp-cmds.c
> +++ b/trace/trace-hmp-cmds.c
> @@ -25,7 +25,6 @@
>  #include "qemu/osdep.h"
>  #include "monitor/hmp.h"
>  #include "monitor/hmp-completion.h"
> -#include "monitor/monitor.h"
>  #include "qapi/error.h"
>  #include "qapi/qapi-commands-trace.h"
>  #include "qobject/qdict.h"
> diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
> index 806a7bece7cb..4ef459490ba2 100644
> --- a/ui/ui-hmp-cmds.c
> +++ b/ui/ui-hmp-cmds.c
> @@ -327,7 +327,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
>                                  void *readline_opaque)
>  {
>      qmp_change_vnc_password(password, NULL);
> -    monitor_read_command(opaque, 1);
> +    monitor_hmp_read_command(opaque, 1);
>  }
>  
>  void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
> @@ -344,7 +344,7 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
>      }
>      if (!arg) {
>          MonitorHMP *hmp = MONITOR_HMP(mon);
> -        monitor_read_password(hmp, hmp_change_read_arg, NULL);
> +        monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
>      } else {
>          qmp_change_vnc_password(arg, errp);
>      }
> diff --git a/util/error-report.c b/util/error-report.c
> index f333af9249b9..aaa15bc79827 100644
> --- a/util/error-report.c
> +++ b/util/error-report.c
> @@ -11,7 +11,7 @@
>   */
>  
>  #include "qemu/osdep.h"
> -#include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qemu/error-report.h"
>  
>  /*
> diff --git a/util/qemu-print.c b/util/qemu-print.c
> index 7b9591035e57..a2d1f0244168 100644
> --- a/util/qemu-print.c
> +++ b/util/qemu-print.c
> @@ -12,6 +12,7 @@
>  
>  #include "qemu/osdep.h"
>  #include "monitor/monitor.h"
> +#include "monitor/hmp.h"
>  #include "qemu/qemu-print.h"
>  
>  /*
> 
> -- 
> 2.55.0.543.g5ebe2ebe4ea8
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 03:49:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 03:49:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392437.1631385 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvoL8-0001QP-5E; Mon, 17 Aug 2026 03:48:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392437.1631385; Mon, 17 Aug 2026 03:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvoL8-0001QH-02; Mon, 17 Aug 2026 03:48:46 +0000
Received: by outflank-mailman (input) for mailman id 1392437;
 Mon, 17 Aug 2026 03:48:44 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <philmd@oss.qualcomm.com>) id 1wvoL5-0001QB-Sm
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 03:48:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvoL3-001Kd2-Q2
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 05:48:41 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a82842e-bab6-0a2a0a5309dd-0a2a4507df8e-46
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 05:48:41 +0200
Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a828498-b4ea-0a2a45070019-cddcb483d6f6-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 05:48:41 +0200
Received: from pps.filterd (m0279871.ppops.net [127.0.0.1])
 by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67GLEe9J666108
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 03:48:39 GMT
Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com
 [209.85.222.197])
 by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g2ghnw1wc-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 03:48:39 +0000 (GMT)
Received: by mail-qk1-f197.google.com with SMTP id
 af79cd13be357-92ec3146553so536746985a.1
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 20:48:39 -0700 (PDT)
Received: from [192.168.69.229] (pmd666.hd.free.fr. [88.187.86.199])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499877d20fdsm211481035e9.1.2026.08.16.20.48.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 16 Aug 2026 20:48:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:Cc:To:Content-Language:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=
	cc:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=
	EsLBxE7C6yuhliAVoQd5K4lTOTwWVs9jvIfglrYIGMA=; b=o+X6ZC7uDJU5eoci
	SKIQVjxFklujwGmjdKBaWfO1wyHWaXJjiEk5w7+cAyYpAROjqSDN0ncVMR4jh8C4
	35Xb/F3xs0F8UCoUlncKQjWs8dVmNXnoio7RFSuy/5Qgo9BcQVQkO5o56mK0PUiA
	KgLURGkqDnCN4OTMhbon/TxK9rpbKEyIY1LyD7Trj9z8Eu0NgD6EZrFXS/Hxj7JM
	I3Pp0/d4sM+tpn9P7674VoN8GJYhfI5iZK12I+Jg7N005xDhPlu3hzt6s8zdKOXG
	B/B+WD39v5UtfL0URsncKi0WXIrMr/VOr2pmNv05+GVz/rpwBAQUZ2/Vjw9waXO6
	qPC5Sw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=oss.qualcomm.com; s=google; t=1786938519; x=1787543319; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=EsLBxE7C6yuhliAVoQd5K4lTOTwWVs9jvIfglrYIGMA=;
        b=DaR+0wVNe+SXrNMPS8XUuI4s4YY7flZVAcbL/T/W9I69CEC5hgaWIoOPEKuQtDLha4
         pfUaGtWCdBSNQH7LN3lDHSggr8ROvZkJDvb7LqIz/b2siNsY/dTOaO29kVNy3rkdaqdI
         tQOhszEnGAP3L5ZBWuWt40FqfJOUaN3mgIWflGdElY1uPm3ckUQ0JBrmLSNVVr6Lrep5
         65TJv8C7ZeFgVJi/+F3/NDX13y2TC+Ru7OWB4LLB2z2I/iNmANDuv5kP5v2q2Jb3+ee0
         Pc94uGb6e64T42GJ/88I/q1Y6TJwnmDnNzdV8wUIW6gW1tCHuo8jQGcGghfffKCmRtRP
         D4NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786938519; x=1787543319;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=EsLBxE7C6yuhliAVoQd5K4lTOTwWVs9jvIfglrYIGMA=;
        b=GoQOPOZBxTxCtZgTlPhEFpkIQSzqBeBwlWFn54Xo522tQDmXtfPLE80+DZuIgOSJO9
         /66wxDCw2Nv1WuFqzmKywGRNcOALXQprcWon//tTU6pWUrVSKWoxVC9oA7cqdVKfIr22
         JVaS42Bq5931pkE0USoWFf0iaC4vxJg4Bdh1gunD2C2iOgfko+FqefbBISsXDJ8P6+xd
         Shgpr28IXE7G2Ru2yWp9yVtsuimCTgM6KiO85NUSluT7MbEQ2Vyy18i5ZNIVzGXF6q78
         qwlFnLDiYH1D+XpvW1xfsRx3jDIUMGFdEGDSVcESTg0Sv8TlyZ7AjqAS/6FJzYpVjPFM
         CygQ==
X-Forwarded-Encrypted: i=1; AHgh+RruOCj33UDacfcED+2tH65iqJ/4IU0/zmE/nmpt9nzW8T4VX46oGeuBllptfFx3ic4GBlRHskR+v1w=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyLdHao8aQG7gtnWpxrSMYOBxHMUGFzGsUOJ7HDGOFgITJ2DDtQ
	P8rANr5qyXAO5+rbuqJRhkExFvpiZ9yUoZjM40Igk8M4RVehFpTYWm5S6V/iNXnvw4xncCM8EyO
	2FyOxQ7N5Oy8hmNPgE+D0K7jO14dqUEAni5BYw9QOmt0jSTAsgRbiesBKe2NLTgSS7DN7Hg==
X-Gm-Gg: AR+sD103mru3/F7bSasK7+hqliLX7sCCBVLjI0AlNZD7CPIJZh8fVTBPaxQ+CtG8jDZ
	2aiH9oi7Pu8UYDJxMb1EJUdjbttwgBoKeSFvYFCqT/n20PZGnw/ZroTpqpeKVh1yyJk1eV6Zf+c
	JYWfc5mOG9fVTC9tgzQbjj5tliChjFNlKJbY5BzJuek/f/xH+yGRtUZPvpNzNLbz/sk5YFcU4M9
	UFbvW3o3kPdJp/JnVkqryw828SYQE0im5O3hjxHQ8qx/fcip2kwD6XlolwJyxAtT1w+Ow1jnhyJ
	T/R310TAIMiMA3qZK1YCaoikkLPYYLz8v8SP58BjRP6x1758/U0W4VwGkkuvHzYvkK032OEmwtq
	u4GhuJto70XVbF+ImWM7yoQue2PjVTlNbwSU=
X-Received: by 2002:a05:620a:2683:b0:936:bcd8:8650 with SMTP id af79cd13be357-936d230591cmr2147907385a.38.1786938518828;
        Sun, 16 Aug 2026 20:48:38 -0700 (PDT)
X-Received: by 2002:a05:620a:2683:b0:936:bcd8:8650 with SMTP id af79cd13be357-936d230591cmr2147905285a.38.1786938518479;
        Sun, 16 Aug 2026 20:48:38 -0700 (PDT)
Message-ID: <a0efd5c6-6af4-482f-9646-b917efa0ae29@oss.qualcomm.com>
Date: Mon, 17 Aug 2026 05:48:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 39/49] qdev-monitor: make print_dev() callback take
 MonitorHMP
Content-Language: en-US
To: =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>,
        qemu-devel@nongnu.org
Cc: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
        Markus Armbruster <armbru@redhat.com>,
        "Michael S. Tsirkin"
 <mst@redhat.com>,
        Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Anthony PERARD <anthony@xenproject.org>,
        "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
        xen-devel@lists.xenproject.org
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
 <20260816-qemu-no-hmp-v3-39-e53fc35bc550@redhat.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>
In-Reply-To: <20260816-qemu-no-hmp-v3-39-e53fc35bc550@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE3MDAyNiBTYWx0ZWRfX9hboK0dusMM4
 P+wrhQ6v8Kc4/iBUZV4dmRIPJIg9dnxcBMLWjgH3mIh7PAaK0+Zb9Da2y77A9rCbUKD5Y6iTqNn
 IZrc403gjZw1Bxm+2gO8MoykABU9PsBL6c/hY2aixwvB6wph6jzW3FEqQ7Bin2GdtYjIjrgaz/M
 adW2LzeoXt5lsWydRyo6iD15Z5UKlKmukuPfrRgY8zUhLfkR2EZW1eXThy8q8uJkOTxTqZVCo2T
 B2WKnnd/RK2Lkjy6fhJnpK0DgOgTRTZBXlJCWEz818MbUTlIdgbwXIFJEpoEeOf8RT7ueuq8SlQ
 ULVybPOJvpx86p4vrjLFEl2L5i8eJuUd/nI95zYUleiUMbhmxKv8wrGn2d4sxlZwFXOAse375N/
 qzqMgRMApiQGRuEpGdGfVGFR/ZGAOfaN2fxBvVfIVyDTpXtzx7VRmZPfBts+QAaUOzRLJpkoBT/
 azZcUkiJZN51Ze7XV+A==
X-Proofpoint-ORIG-GUID: LPK5b3tc17CM4LF3tVnPOxTV4ofMLaFr
X-Authority-Analysis: v=2.4 cv=QN5YgALL c=1 sm=1 tr=0 ts=6a828497 cx=c_pps
 a=50t2pK5VMbmlHzFWWp8p/g==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22
 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=1tSEMpTH9XP_W59IOagA:9 a=3ZKOabzyN94A:10
 a=QEXdDO2ut3YA:10 a=zZCYzV9kfG8A:10 a=IoWCM6iH3mJn3m4BftBB:22
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE3MDAyNiBTYWx0ZWRfX/zXbql4JAjMY
 nP+rlxAoCkSdXAzvSKZJXmSsFDThzLfMKmTpOgTh6lX3a8gCquwOycZNBjFGRP1I263g++SP7pC
 Q1IZPi9v1QGoV9JAm5uQQL9bxjihIGM=
X-Proofpoint-GUID: LPK5b3tc17CM4LF3tVnPOxTV4ofMLaFr
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-16_06,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 spamscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0
 clxscore=1015 priorityscore=1501 malwarescore=0 bulkscore=0 phishscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608170026
X-purgate-ID: tlsNG-ef75cf/1786938521-A46CAAE4-374341D7/0/0
X-purgate-type: clean
X-purgate-size: 710

On 16/8/26 21:13, Marc-André Lureau wrote:
> The callback is specific to HMP context, avoid unsafe MONITOR_HMP()
> cast.
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>   hw/char/virtio-serial-bus.c | 6 +++---
>   hw/core/sysbus.c            | 5 ++---
>   hw/misc/auxbus.c            | 7 +++----
>   hw/pci/pci-hmp-cmds.c       | 3 +--
>   hw/pci/pci-internal.h       | 2 +-
>   hw/usb/bus.c                | 5 ++---
>   hw/xen/xen-bus.c            | 3 +--
>   include/hw/core/qdev.h      | 3 ++-
>   system/qdev-monitor.c       | 7 +++----
>   9 files changed, 18 insertions(+), 23 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 05:02:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 05:02:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392403.1631394 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvpUb-0003A5-8O; Mon, 17 Aug 2026 05:02:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392403.1631394; Mon, 17 Aug 2026 05:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvpUb-00039x-3Q; Mon, 17 Aug 2026 05:02:37 +0000
Received: by outflank-mailman (input) for mailman id 1392403;
 Sun, 16 Aug 2026 21:38:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <davydov-max@yandex-team.ru>) id 1wviZ4-0005ah-Fv
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 21:38:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wviZ3-00ElU8-Kq
 for xen-devel@lists.xenproject.org; Sun, 16 Aug 2026 23:38:45 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <davydov-max@yandex-team.ru>)
 id 6a822d00-e002-0a2a0a5209dd-0a2a450cd670-22
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 23:38:44 +0200
Received: from [178.154.239.72] (helo=forwardcorp1a.mail.yandex.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <davydov-max@yandex-team.ru>)
 id 6a822de3-f479-0a2a450c0019-b29aef48902e-3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 23:38:44 +0200
Received: from mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net
 (mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net
 [IPv6:2a02:6b8:c1f:3a87:0:640:845c:0])
 by forwardcorp1a.mail.yandex.net (postfix) with ESMTPS id 4843FC04B1;
 Mon, 17 Aug 2026 00:38:43 +0300 (MSK)
Received: from [IPV6:2a02:6bf:8080:d7d::1:36] (unknown
 [2a02:6bf:8080:d7d::1:36])
 by mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net (smtpcorp) with ESMTPSA
 id dcbpcP7WMGk0-PuYxShe7; Mon, 17 Aug 2026 00:38:42 +0300
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID"
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru;
	s=default; t=1786916322;
	bh=s7HcjQ73f1ZgIcnWaPQZHhDiaXl1DsseYtimaK/ef9o=;
	h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID;
	b=1EmW++UpFleYRX06kyKiftI59lLPaM4PFEKfv9Jmm9rhNokSq1pNou5tw0+HPmPfO
	 qmQ8e3vRCmSD5lH56597DsCXvtLegbox74YhTR3svKed+E/U4G5GxLG1Ac/Cl3q7RB
	 SK6n7VHiAjNBdT+15kEWI/E3qFJUcj3T2QcUTjRI=
Authentication-Results: mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru
Message-ID: <ef3b56bf-8df0-4a40-82c7-bd2d65eec71e@yandex-team.ru>
Date: Mon, 17 Aug 2026 00:38:39 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 21/51] x86/kvm: Obtain TSC frequency from PV CPUID if
 present
To: Sean Christopherson <seanjc@google.com>, Kiryl Shutsemau
 <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Jan Kiszka <jan.kiszka@siemens.com>,
 Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski
 <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
 Juergen Gross <jgross@suse.com>, Daniel Lezcano <daniel.lezcano@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, John Stultz <jstultz@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd
 <sboyd@kernel.org>, Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org,
 linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 Michael Kelley <mhklinux@outlook.com>, Tom Lendacky
 <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>,
 David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>,
 Thomas Gleixner <tglx@linutronix.de>
References: <20260806233609.212337-1-seanjc@google.com>
 <20260806233609.212337-22-seanjc@google.com>
Content-Language: en-US
From: Maksim Davydov <davydov-max@yandex-team.ru>
In-Reply-To: <20260806233609.212337-22-seanjc@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1786916324-52132A5B-95AB9657/0/0
X-purgate-type: clean
X-purgate-size: 6520



On 8/7/26 02:35, Sean Christopherson wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> In https://lkml.org/lkml/2008/10/1/246 a proposal was made for generic
> CPUID conventions across hypervisors. It was mostly shot down in flames,
> but the leaf at 0x40000010 containing timing information didn't die.
> 
> It's used by XNU and FreeBSD guests under all hypervisors¹² to determine
> the TSC frequency, and also exposed by the EC2 Nitro hypervisor (as
> well as, presumably, VMware). FreeBSD's Bhyve is probably just about
> to start exposing it too.
> 
> Use it under KVM to obtain the TSC frequency more accurately, instead of
> reverse-calculating the frequency from the mul/shift values in the KVM
> clock.  Use the information to get the CPU frequency as well (kvmclock
> feeds in kvm_get_tsc_khz() for both TSC and CPU calibration), as the info
> from CPUID is superior in every way; whether or not kvmclock should be
> overriding CPU calibration in the first place is an entirely different
> question.
> 
> Use the info from CPUID even if the user explicitly disables kvmclock, or
> if it's unsupported.  The PV CPUID leaf has no dependency on kvmclock, and
> is in fact more useful if kvmclock is disabled since the kernel won't be
> able to use kvmclock to derive a derive the TSC frequency.
> 
> Before:
> [    0.000020] tsc: Detected 2900.014 MHz processor
> 
> After:
> [    0.000020] tsc: Detected 2900.015 MHz processor
> 
> $ cpuid -1 -l 0x40000010
> CPU:
>    hypervisor generic timing information (0x40000010):
>       TSC frequency (Hz) = 2900015
>       bus frequency (Hz) = 1000000
> 
> Note!  *Independently* query for non-null get_{cpu,tsc}_khz() overrides so
> that kvmclock doesn't clobber x86_init.hyper.get_cpu_khz() if/when KVM adds
> support for getting the CPU frequency separately from the TSC frequency.
> 
> ¹ https://github.com/apple/darwin-xnu/blob/main/osfmk/i386/cpuid.c
> ² https://github.com/freebsd/freebsd-src/commit/4a432614f68
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  arch/x86/kernel/kvm.c      | 33 +++++++++++++++++++++++++++++++++
>  arch/x86/kernel/kvmclock.c |  6 ++++--
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 5b554e480c0e..8ed02f4f5775 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -49,6 +49,8 @@
>  #include <asm/svm.h>
>  #include <asm/e820/api.h>
>  
> +static unsigned int kvm_tsc_khz_cpuid __initdata;
> +
>  DEFINE_STATIC_KEY_FALSE_RO(kvm_async_pf_enabled);
>  
>  static int kvmapf = 1;
> @@ -913,6 +915,21 @@ bool kvm_para_available(void)
>  }
>  EXPORT_SYMBOL_GPL(kvm_para_available);
>  
> +static u32 __init kvm_cpuid_timing_info_leaf(void)
> +{
> +	u32 base = kvm_cpuid_base();
> +
> +	if (!base || cpuid_eax(base) < (base | KVM_CPUID_TIMING_INFO))
> +		return 0;
> +
> +	return base | KVM_CPUID_TIMING_INFO;
> +}
> +
> +static unsigned int __init kvm_get_tsc_khz(void)
> +{
> +	return kvm_tsc_khz_cpuid;
> +}
> +
>  unsigned int kvm_arch_para_features(void)
>  {
>  	return cpuid_eax(kvm_cpuid_base() | KVM_CPUID_FEATURES);
> @@ -962,6 +979,7 @@ static void __init kvm_init_platform(void)
>  		.mask_lo = (u32)(~(SZ_4G - tolud - 1)) | MTRR_PHYSMASK_V,
>  		.mask_hi = (BIT_ULL(boot_cpu_data.x86_phys_bits) - 1) >> 32,
>  	};
> +	u32 timing_info_leaf;
>  
>  	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
>  	    kvm_para_has_feature(KVM_FEATURE_MIGRATION_CONTROL)) {
> @@ -1009,6 +1027,21 @@ static void __init kvm_init_platform(void)
>  			wrmsrq(MSR_KVM_MIGRATION_CONTROL,
>  			       KVM_MIGRATION_READY);
>  	}
> +
> +	/*
> +	 * If KVM advertises the frequency directly in CPUID, use that instead
> +	 * of reverse-calculating it from the KVM clock data, or worse, trying
> +	 * to calibratate the TSC using an emulated device.
> +	 */
> +	timing_info_leaf = kvm_cpuid_timing_info_leaf();
> +	if (timing_info_leaf) {
> +		kvm_tsc_khz_cpuid = cpuid_eax(timing_info_leaf);
> +		if (kvm_tsc_khz_cpuid) {
> +			x86_init.hyper.get_tsc_khz = kvm_get_tsc_khz;
> +			x86_init.hyper.get_cpu_khz = kvm_get_tsc_khz;
> +		}
> +	}
> +
>  	kvmclock_init();
>  	x86_platform.apic_post_init = kvm_apic_init;
>  
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index 29ca37e9a3bc..f55d0305d1f3 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -342,8 +342,10 @@ void __init kvmclock_init(void)
>  	flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
>  	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
>  
> -	x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
> -	x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
> +	if (!x86_init.hyper.get_tsc_khz)
> +		x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
> +	if (!x86_init.hyper.get_cpu_khz)
> +		x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
>  	x86_platform.get_wallclock = kvm_get_wallclock;
>  	x86_platform.set_wallclock = kvm_set_wallclock;
>  #ifdef CONFIG_X86_LOCAL_APIC


I cannot test this right now as I lack two servers with different CPU
base frequencies, but it seems that this patch might break something in
guests:
After migrating a VM (QEMU + KVM) from a host with one base frequency to
another host with a different base frequency, the value in CPUID leaf
0x40000010 EAX changes and becomes the same as the destination host base
frequency instead of remaining the source base frequency.
The main reason for this behaviour is that setting the TSC frequency via
ioctl(KVM_SET_TSC_KHZ) doesn't change the value in CPUID leaf 0x40000010
EAX and these two entities are still not connected.
I saw this behaviour with QEMU 7, but I've checked the code of the
latest version and it seems that the described behaviour still exists.
So, in that case, it's possible that with these changes a VM will use
the wrong TSC frequency from CPUID leaf 0x40000010 EAX if it's migrated
and then rebooted.

Putting it all together, after the previous patch ("KVM: x86: Officially
define CPUID 0x40000010 as PV Timing Info (TSC and Bus)") a new way to
show the guest that CPUID leaf 0x40000010 is valid should be implemented
and only then this leaf can be used to get the TSC frequency.

-- 
Best regards,
Maksim Davydov



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 06:11:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 06:11:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392459.1631403 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvqZB-0003Ve-TL; Mon, 17 Aug 2026 06:11:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392459.1631403; Mon, 17 Aug 2026 06:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvqZB-0003VW-Pa; Mon, 17 Aug 2026 06:11:25 +0000
Received: by outflank-mailman (input) for mailman id 1392459;
 Mon, 17 Aug 2026 06:11:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvqZA-0003V7-Su
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 06:11:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvqZ9-007O62-6l
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:11:23 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82a608-bab6-0a2a0a5309dd-0a2a4506a842-4
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:11:22 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82a60a-195a-0a2a45060019-d155dd2ce5b0-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:11:22 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-4815bce4652so1820259f8f.1
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 23:11:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b487sm1232263f8f.10.2026.08.16.23.11.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 16 Aug 2026 23:11:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786947082; x=1787551882; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=e3u9tF4r2QuCHyVAtgu30y4b/QROcSH9MWoc0U1I/88=;
        b=DtzU91DL4x+IrVQqLPVCpW8xILRGNOaDJuYQntSvP/unG3CBUwxBXnKPGDlVKS6wbb
         osQInDGlz1C0hQedYok72bp/EsWJS8G0Cgy8GS83/VGjbAMbMzOnhVJBn7LirfNn3L5g
         mRg3sOp3f14yIMN6xsrlHU2/2M9ML8+tlfQ79nJfoeO1SYwfaoE4l5l6Wy35gItupCPH
         sz55fYMLHmshgq6EbTfOEGhsOdyCoikPT/7oixwDCHGgumPD91clTU/c1ybbTLGVEldE
         K59QN4j5cqaYAhT3HklW7GWxEf7dJZ0QcvCnKPLJ5r+4db6Jajn7DgVueNHeiS35yZXx
         nIjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786947082; x=1787551882;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=e3u9tF4r2QuCHyVAtgu30y4b/QROcSH9MWoc0U1I/88=;
        b=Sy/yl99AozDbxXDxAbVDGcbhf6HnbyQss5zQyB/7txj9HLNMv41eXiIHIA/Pr/I73u
         awaWpMrR97mw17MMQEIKUEEAkyTB0XpKuVckI7jZ5BI15ZuMAvIVgL/dBKn7/bLi0bLK
         iWZ1ycdwOg3Wfh6GqME1YzblYj9Ci/AbEGBm8ucGQ2oGIV+sXLft3pamn+ff1xD3L8nB
         XSM9y7rR2/EtvrfErepu/DIENdiAxG2YTA2x5/hNAR9DxnkCPMHrKkzBRcLfwc8THNxo
         trHrMaHoR9W5+AOOw8gkgrdVOG93jAzQLnGt7V7Efw/1xK7lAZmoDNj9ipMOP5/PggeO
         GDJw==
X-Forwarded-Encrypted: i=1; AHgh+Rrgq6tZWrAHCYbD6U/2S2VMNV9GSsZIFr6LDR4/VYXPeeKKkbuuo2J/pRnBblNkcrbOzRaiijxMjdk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWdi80915JPqe8+WtyPd4D2afa/ZdQrUjCXtd3BEanUp4ipv+S
	bJ8y2TDHudxm8chcxrBKHLBTyfeRQu3d6RiUS8RKJpwJaYfSLEaZeUMQslyrB8Jx1w==
X-Gm-Gg: AR+sD11wOAqOmVAqkS+SEnqVMQkB8Ad0ppdCkaBtiE+r9OhA/p/sCge7qfLqmjoSdIB
	VbHltMZIhjIwQByo8lTXfghfc5sHFTcRlxdm/hmB5ALBlqxtIvMj5G/KqJKaowtwOzn1Sdtug4l
	lhVvaQlgAEnwwstesYYaAK0BuxRVnWCCsv81iS/CxxKbc00R7GJ0R/ExEuzaSGOzPiwrdfOL1ab
	4HKfWRDVl4NOrXDYP4Bebme29T815dC9e5fCYjCcozl6FPTdv5FNCga0ApHLGYa4Mu3616FfB/j
	Id0QJfq8D3rwK/HiTvbTCvftWq6yiQUOx1VuaVmqeU8MOAJAME0eP8wrZI7F3pErjy/QSpU5Fzu
	aIXxnStuTcZY8BgOk75pwFafQG42Xj8yGOdbVTS0CJRBjmx4mEkUFADqJlwAK46eI2R+yN/em+z
	0FOUG8v2fzLLf1BH30Kd6th9RqUZ4qpIYbav8LD3BmitNenkWT0CWtbRq68VF6zt4C6CiemtLpO
	rirP15BjGvDqhFzU/pGQC37kqMgxOzf7BotfOureTaaqk/L2f5M
X-Received: by 2002:a05:6000:4024:b0:481:5829:3f28 with SMTP id ffacd0b85a97d-48160723c18mr35113110f8f.5.1786947082436;
        Sun, 16 Aug 2026 23:11:22 -0700 (PDT)
Message-ID: <cf1eb6ef-763c-44d3-ab86-d9dd431cf606@suse.com>
Date: Mon, 17 Aug 2026 08:11:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] x86/emul: Adjust comments in x86-types.h
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
 <20260814185841.1757421-2-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260814185841.1757421-2-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786947082-1ECC577B-C7552A37/0/0
X-purgate-type: clean
X-purgate-size: 894

On 14.08.2026 20:58, Andrew Cooper wrote:
> x86_segment enumerates segments, not segment registers.  Adjust the comment to
> make this clearer.
> 
> Fix a stray tab with the closing #endif.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

I wonder though if we wouldn't better ...

> --- a/xen/arch/x86/include/asm/x86-types.h
> +++ b/xen/arch/x86/include/asm/x86-types.h
> @@ -16,9 +16,10 @@
>  #endif
>  
>  /*
> - * Comprehensive enumeration of x86 segment registers.  Various bits of code
> - * rely on this order (general purpose before system, tr at the beginning of
> - * system).
> + * x86 Segments.

... insert "(kind of)" here: "sys" and "none" aren't really "segments", and
iirc we said we may need to gain one more such pseudo-segment here to deal
with WR{,U}SS.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 06:15:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 06:15:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392466.1631411 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvqdM-00045V-BN; Mon, 17 Aug 2026 06:15:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392466.1631411; Mon, 17 Aug 2026 06:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvqdM-00045O-8b; Mon, 17 Aug 2026 06:15:44 +0000
Received: by outflank-mailman (input) for mailman id 1392466;
 Mon, 17 Aug 2026 06:15:43 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvqdL-00045H-DH
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 06:15:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvqdK-00CXgd-Cs
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:15:42 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82a6eb-e002-0a2a0a5209dd-0a2a4504a7b2-34
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:15:42 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82a70e-b57f-0a2a45040019-d155802cb1fa-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:15:42 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-49545ba3d4eso13687095e9.3
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 23:15:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499961098cdsm137930665e9.6.2026.08.16.23.15.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 16 Aug 2026 23:15:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786947342; x=1787552142; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=PT+OZyuzZ2o1GZ+8tM9e+W5ICceT+jrGPbX9GFZvH2I=;
        b=S52uaFZprncKhBy/soY33rRPJBzEpLhqBzoQq/5ebgQVekcjgCBRJZdXrIOEgPE0Wl
         CHvZ8XqTjAUHlpXa5mliKta7ILfjmLdE+hy9JDE71XqyFBWWrCsnN8xfi4JXorFPEIYc
         Rk8G8VYnUGdcUsSMjHbAT1OXm+s05+X3cBw6HdIcv6peyChdUtUf/Hsm61OL50DyWiYf
         BKVE9BNHBRuFE+ktbp3TInquEL4IJtoDtI+g/qdMZIHd/gRigvm3Tblf0QmVChoMq8At
         1wUrQTi35boPXM4Cl6C2qNPWIQ4KOd5V1+fEdmg5a02itDxvigDXXsgcNMzvT3vD5l63
         /dtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786947342; x=1787552142;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=PT+OZyuzZ2o1GZ+8tM9e+W5ICceT+jrGPbX9GFZvH2I=;
        b=RQaWlxTsfmkT13xeDVeHKBOasHIUx/23AfTS7zxpjSzxDk72o7h5bkwnZIVdZVG4ZE
         56ZcX7Z4AJeRXAOfhZGFg5S0NSehp6dPMM2wWsur5ORbQuQGayFTs0fDaPTd1RM0ovTF
         fCnamN2a3irrYgT4X1xQdaFsfdkulLvAAt0KTj8u44QiNdgUsKMwYaYtwvjfgF3kG6Jg
         Y6IqUc/hbgXKyQK0nBegVQ21kWqV0t28GV/oOjWw3NLJ8HBAsG73vyqdSTzrV9Co8jDi
         2ahKaoO/vS2aIJofNnF3zI2uYN/+NOJnHwzXliDqmoT+JpPoL4JTJ72K+0HzhtRfz4Ye
         K0gg==
X-Forwarded-Encrypted: i=1; AHgh+Rrg8zHDw6qSwGijooTdI3eOMe40I02Ehv1+9mWip66FFeWiFNEErgCc96+XIsC5ldUh6hSOEvQPy/Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxc/E2R/QV9cgaSq6v7sMYtWvzgO+3r1fOjpbMGotqQ4GxYIcGU
	5EutGYgJ/H+bIm/rIqQ+vifRbwKMaFnFrmy36FeVKsYaFxwzschtTYHXhC353AnySQ==
X-Gm-Gg: AR+sD119qqaBcfCQXC+HtGnFts3jnu5h97e2k0M0XtrIpSYhuRJODfiGp3pOwtuEEcf
	lrKtL4HC+WY3JQ/n2+nVfqekhmCa0xIdyU1zzCItFSZEfZV9gxKcjE5DUEwDWaOHR/4+iw6iLBm
	aKbGsTQkP1TueF9jTiaTL1OGsmDX2Nfja/najXzwvHPluYo6EVT81AErzhYR//tjj6+tkdapK8a
	yhY5s4h9UPwkXNZowVTHwxklO9OtF44tNYb5T+Db7otAyFs6Tyz60aPYxqw7jTpfIDAXs4r23kX
	eQCP7tg09dNPcC32pFcecBpK+u6/suW9bFTbbgXa1nJ0X9m/qzbVTi+eqV3wyRulv2skMLzMnyn
	JtXn3fxq5Oc2nf7tdg9HMt35BWNIn1tXmm7ckBGlNIwXhZLHRwhhIf1XCj0kqi7uq6cacVRTXeF
	W1066iC9VQUyUulkm/wmeSsQMo6k6ePsEDf9CpLrm2ICGpmBFUtOrMhuW7EpSYgBq57U0Z/t4iy
	VG0GlyCym6IOnazUy0q370ROrBoKastFpfkgZuXYRcuSkf9qtXt
X-Received: by 2002:a05:600c:34ca:b0:499:7f38:d77 with SMTP id 5b1f17b1804b1-49988cab011mr354235075e9.6.1786947341845;
        Sun, 16 Aug 2026 23:15:41 -0700 (PDT)
Message-ID: <2f65ee41-7a7d-4d86-9cdd-82ac4ccedb08@suse.com>
Date: Mon, 17 Aug 2026 08:15:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] x86/emul: Drop trailing r from x86_seg_[lgi]dt names
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
 <20260814185841.1757421-3-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260814185841.1757421-3-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1786947342-538C1B50-3DC8237B/0/0
X-purgate-type: clean
X-purgate-size: 236

On 14.08.2026 20:58, Andrew Cooper wrote:
> These refer to the segment, not to the segment registers.  TR is the
> odd-one-out having "register" in it's name.

The more consistent naming would then appear to be x86_seg_tss?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 06:20:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 06:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392475.1631420 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvqiF-0005kS-Vd; Mon, 17 Aug 2026 06:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392475.1631420; Mon, 17 Aug 2026 06:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvqiF-0005kL-T2; Mon, 17 Aug 2026 06:20:47 +0000
Received: by outflank-mailman (input) for mailman id 1392475;
 Mon, 17 Aug 2026 06:20:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvqiE-0005kF-0n
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 06:20:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvqiD-002O9N-D7
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:20:45 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82a83a-e002-0a2a0a5209dd-0a2a45028ec2-8
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:20:45 +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 <jbeulich@suse.com>)
 id 6a82a83d-6ca4-0a2a45020019-d155802bdd57-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:20:45 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so31184125e9.1
 for <xen-devel@lists.xenproject.org>; Sun, 16 Aug 2026 23:20:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d0876b8sm19008015e9.8.2026.08.16.23.20.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 16 Aug 2026 23:20:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786947645; x=1787552445; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LoPRYGKOdrmTSJeGVeMsw3VubSe563rmLkb2pXYgk7Q=;
        b=NdmxHkpKc6Cav8tHQ8a0URxqNJF+4pyw8AlS6l6IyFFHFENPdxUPQO0Hq6KbHwDDsx
         KODxjudrOizKWOLK3xFmeChCv1Io+XacahetFolZBwhbW87DjwsmXI9RKeEvpdN7Vgbs
         vqHNAIW1PqCL3UquOi6hBA5ne4eL/j5OAURF4YAgNg3vr6wQ5Qc7ge/MI2TtFjd9IgfY
         n9K4v29RI9K3VRdfAQnzW/iRINL0WE9MUlM7WTGYZdKjbcgAte3yyBuHaxuEqo9Pmb9i
         aPHHOUNdVU0YOYeL6+oZjloUwLzQVwQQgu2TJfFA4R4rfhwLlG7UhpVq4mw1VQMvQ0qb
         aaVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786947645; x=1787552445;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LoPRYGKOdrmTSJeGVeMsw3VubSe563rmLkb2pXYgk7Q=;
        b=TnlnaasF9dxZuik3pdWbyUyuWK4m8gO8WTtuKqAACMEkfjktXARzU8D5zhC8EWGfDl
         PS7VMoBpT1IJ4YrO0RqAJuaxXRX2b+N69GWIHaKnJxraOIjrAmYRGEG6ApkhCii1I+J8
         TkTYbZJt21KJaDAAg9/XKTUHQ4Q/AC2DiomJm+/tuPIVQmMLoCW944XjiOm56ADKC+Ub
         lSzSqOpuCfMCgeANQQd7oa254lcZvzV5KKNst67l9xGATGMcCToVCTfpeGHlTQwgs/y4
         z4F/wmeGqYJ8nf7IgWLL/D71kdvQevHnL7n+IhmfBw4fA4Sslp94I/wAB6mfl7GfDAsN
         3aKQ==
X-Forwarded-Encrypted: i=1; AHgh+Rqq/ViSXC72O6zHEuvLupPJi2STG+onJN+DSN660t+lWh1ZVR2ITnUEIAG1d3Q4gBzZt+jhvbllJKk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxbWb1rVSNtqWsTyTacVH2g1CHtRkZ7RuhdUU6YpR0Ci98/MdwP
	3dqMEhAEqmb0yqXJMzQ5/ofglVqymbyV3gI0fT3V/ROwxylehfJhZPXt07GIr5PT0w==
X-Gm-Gg: AR+sD11o3fPNLHYdzWZuOdizuT1PRhoqAKeYll6xrwhDibNzg3/+NwP2oZeIIXiNi1t
	RnEr4y7c0KgQ0bsWfexII52ygBFGl8hLw/Geh+O37cAROem1GX5Z5HHuQoo5C646/1J/jEGsw/d
	hATMJSQVpNM6rvZeZRd9ZX/DwTeO8ALSFpbocPD5bHvz2M4Qzi/5Hdut+I0BdburGGeBYkxuzru
	AnBFsxHtXa9yUsCPO3ankNNcqmVV4H9NvV48p8jL4P05QHJ6Y0lVWFUeBETwcZ1/87QweBYhsB3
	lWanBWFcOdxsyQ07qGcg2dr0FC7I/ueUs/8bq2/zeqCNs6m3wBaIjzjFlAVXHTyy6mHCXTAOSEZ
	z2eO0S0pM4ZJFCE4ohH9iVCd9P5YK0X25GlXNn6KFQGhcedm6Ch2CkvaaUcWUPnAjiE2MNvvZFu
	OhXc0p6vebBn2uNDzj5/SB8fYS56PEzGi2Mb0qljxPfUd36tNmazfSdpRGXDx3GV4jKg2QzPYC3
	kKh8YBaQ6JUSi80wFxFD+EQSfRg2YD8V9hQnatECFssT6/1AdIB
X-Received: by 2002:a05:600c:4e0a:b0:496:c378:6420 with SMTP id 5b1f17b1804b1-49987956c76mr375518665e9.8.1786947643870;
        Sun, 16 Aug 2026 23:20:43 -0700 (PDT)
Message-ID: <35f89482-53f2-4010-9692-612092246393@suse.com>
Date: Mon, 17 Aug 2026 08:20:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] x86/emul: Drop the union in x86_event had have a
 single data field
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
 <20260814185841.1757421-4-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260814185841.1757421-4-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786947645-F32B12AC-6588FCB8/0/0
X-purgate-type: clean
X-purgate-size: 621

On 14.08.2026 20:58, Andrew Cooper wrote:
> FRED has formalised the event_data field.  It already has more uses than
> given (e.g. the NMI Source Bitmap), and further uses are expected in the
> future.
> 
> Collapse the union into a single field called 'data' as the struct has event
> in it's name, as well as 'event' being the common name for the variable.
> Refer to the FRED spec rather than keeping an out-of-date list of uses.
> 
> Adjust all users of the old names.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:00:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:00:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392485.1631434 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrKp-0002q9-RQ; Mon, 17 Aug 2026 07:00:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392485.1631434; Mon, 17 Aug 2026 07:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrKp-0002q2-Ou; Mon, 17 Aug 2026 07:00:39 +0000
Received: by outflank-mailman (input) for mailman id 1392485;
 Mon, 17 Aug 2026 07:00:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvrKo-0002pv-U0
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:00:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrKn-002V4W-Ge
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:00:37 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82b18f-e002-0a2a0a5209dd-0a2a450bc594-12
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:00:36 +0200
Received: from [52.101.52.62]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82b193-b7e8-0a2a450b0019-3465343e46a9-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:00:36 +0200
Received: from BN9PR03CA0144.namprd03.prod.outlook.com (2603:10b6:408:fe::29)
 by PH7PR12MB7844.namprd12.prod.outlook.com (2603:10b6:510:27b::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 07:00:28 +0000
Received: from MN1PEPF0000ECD5.namprd02.prod.outlook.com
 (2603:10b6:408:fe:cafe::a5) by BN9PR03CA0144.outlook.office365.com
 (2603:10b6:408:fe::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Mon,
 17 Aug 2026 07:00:28 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 MN1PEPF0000ECD5.mail.protection.outlook.com (10.167.242.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Mon, 17 Aug 2026 07:00:27 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 02:00:27 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 02:00:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IqFgICb//lhB1/UstvqW82JrH/wMO95QyN+mb5jpRDKkGnuGGQCACaUL7Ch5KJ6AsGU4cEzmbIdhIHKH07tqMtwz2xlGrW6Qkx/0IdPA6XMbOC5IE/hN9MJhjJtyyTvqvEDHmuhdwt2B2GPK7alhwsRD5nPO8x8ib2rVwU5mAt43HXyMPZth1jdLAsve724Ny1/QQl81bw5+ifgZKTMJc7sJaCeVXe4jUsbG6wVCvdcU28wrDyjCZBmslJNPCxiQsHmfRT5UcpJotRhEwv3M3lM/3tuR9B7bDCOaiCPHuzY5fQ89GuruKkcNRa4u/ajlfhDy2Z/F9BjTxWARqsWlvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5RMwhhctxyiEppC1UIO+FGB5fkFikiJdZztxKlN7w5E=;
 b=PPfmKa15TVDOOaq96ZNjzYxJU6KZTeJPhPRI7axoyfYq+EADlQx3pssfRqVlXBkQ0Bv5AXIuTCXePdXmF+esRX+qdBl3c1UVSLtQT7KuIFWgBUBkEpFziNwFw6WvSwEvOUYUH1v7/DVWXUzyard1HlJ3DBZyutbVWPO6vBTeI37UnMERfKfjAQphGm8d3KM4uDtcDb3O9T1EV1ByWFgTV2CT7eWsm9CU3StIuCi0qh4M7RmaoeYv50YmwdWsHMUBVr0yPvZUHIMJe64XvZCyCPHooWotSAS3a9jnxKdaqu9yH3/8nGJucABZzgJWoD7J8P3vvM2YNjtMOj6X74PapQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=valinux.co.jp smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=5RMwhhctxyiEppC1UIO+FGB5fkFikiJdZztxKlN7w5E=;
 b=vZ4KwcJd8TtIpKa0Q8J+Q5OrqujhKcn7VhIsEBnOmadajFGI40kLdGEVbP+l/vm9hvTFlXtiMq38RNimg3/jEuBLHV/H45KMKw1mLspAEfbXHTPJ7Yp7romUWtvVGEJf/Yf4ErSoMbhsoulCWBoBVuew1cBUe6runPWwAtM95Rs=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <37b2d119-7ff9-4862-9bcd-acb0b7ff4c9d@amd.com>
Date: Mon, 17 Aug 2026 09:00:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
To: Hirokazu Takahashi <taka@valinux.co.jp>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260813032938.3946-1-taka@valinux.co.jp>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260813032938.3946-1-taka@valinux.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD5:EE_|PH7PR12MB7844:EE_
X-MS-Office365-Filtering-Correlation-Id: a30f1f1d-80e1-4333-208b-08defc2d3815
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|23010399003|1800799024|376014|82310400026|6133799003|10067099003|11063799006|56012099006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	Pi3sbSdR6sTVYpWfRysz3IZo7ZQ/1cRh0WLjmepQNEjCfUdGqQDOjf7xZoQulHRlYyoOc2Uvl0reyOCm1Ro6ixMWx4Y8FeJcoNLUEcIHCMvwfmp9uTQGoY5noDHsK6BxIrxHYtH8IWL6jsG9QrEqBiQBMHKe4eLUavCNF/oFpLlRI51w9p/bgePMGyvZbkhLytuQSUSxOA/XmUDghYkBIPUref0JNsfNmTL3I4FIxEWogeTi+kcxDK9eExJkfFFJV2gffV2/jvq3OoIRDIqjbjFKWAft714UdMXKrW68SATqhXCrQcjMLY0s56GeGRvJ0tbgN8Q9Rm4ur6jLUJe+VF1sQWb3UhnF+8zUBnrgVMm3pLx6BqVzohCG5/OdoxFLZ7jZDWyGrNelpOyOFUa6kCRR5UZ7WHF2O+/N0Yj1sSEDxbXIQ7vt5uRjz5Jr09k5HLKRI4zmddrDECK+jM3lDmkxPX5LuDGSXl/4QOhA6ev1FHoG1S5CFGwMkj5aLFJyRr5EhObYy36a11lvFiIZsN72gNVJjE48PeXjSPd4YjjrvE4mp0txQvtZebv0Mb1K9o7XNb9AxxlOaJqSDmBwu/ZnLiijGRHez+KYQ1GNfsXVpfAiIzfWZxNFTPcUkk50HYUzp9z8ycLfcT4Jr7qFMkyEqhx1FgTAwKvX8Fizn68LllBHssSjtVZVn/CZnhT1dJRtpMklVK4H6sIzfI6e4Q==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(1800799024)(376014)(82310400026)(6133799003)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	4YQ6FSlSrwegjtpQoYzV0q+b+Ej8jqceCHUBfNhfcMXDoPmgbJkEg4Sp+ViZ1xpn1viq4P9LhaDpLtcRMGh0DROmxpCXvUZgPvLwTnJPkRT+d22q5qAQh9Cp6kSehE9zQBpcjCFzcelCwO4JtFEXdcFQ0tTQoFW4elfa6oktzJluHOv45k6QQQqd+3e7IX+uQiboRpV+C8cToWjJU0+Hv5vDByofXt4M7Glv2GHWThMxme3hxnjL9jtDOUgwJMEqT9D/bcE2e1FiUB1t5EV6FR2HZXJtdjQ6GOAQazpH0K/jZe3hWJw1Ap/3dXSL2GoJ+Z/R2oMaN6mC057NKjSt0KOiSdjGFqw1HY3qdYWF3XNka0uRxQPUCPfgSBvUg2OtVri1RvJLglteuEH8v7nEpbPSJAt+ol2kLeq6qH3/hp3TaLay5uBu7kKjiq1mnkPF
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 07:00:27.7381
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a30f1f1d-80e1-4333-208b-08defc2d3815
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000ECD5.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7844
X-purgate-ID: tlsNG-42698a/1786950036-A8ECE9EA-6A37AD35/0/0
X-purgate-type: clean
X-purgate-size: 8255



On 13-Aug-26 05:29, Hirokazu Takahashi wrote:
> On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
> causes the domain to probe advanced PMU feature based on system ID
> register ID_AA64DFR0_EL1.During this probe, Linux accesses PMMIR_EL1,
> which causes unhandled register traps and crashes the domain.
> 
> To address this issue, I implement the following:
Please use the imperative mood

> 
> - Hide PMU registers from a guest domain when its vPMU feature is
>   disabled.
> - Proactively make SPE, TRBE, BRBE, and Trace Extensions inaccessible
>   to guest domains, as they could potentially cause similar issues.
> - Add emulation for PMMIR_EL1 register accesses performed by a guest
>   domain when vPMU is enabled. However, similar to reads from other
When vPMU is enabled, there is no trap/emulation

>   PMU registers, the read value returns zero (note that this is a
>   temporary implementation).
> - Emulation for PMSS (PMU Snapshot) register accesses is not yet
>   implemented, because PMSS support is not available in
>   qemu-system-aarch64 and could not be verified.
> 
> Fixes: 07b9acea116e "xen/arm: Add handler for ID registers on arm64"
> Fixes: 3669a1cb9598 "xen/arm: create a cpuinfo structure for guest"
Fixes commit title needs to be in brackets ()

> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
> ---
> Changes in v2:
>  * Instead of unconditionally hiding the PMU feature from guests,
>    we now determine whether to expose PMU to a guest domain based on
>    its configuration.
> 
>  xen/arch/arm/arm64/vsysreg.c          | 31 +++++++++++++++++++++++++--
>  xen/arch/arm/cpufeature.c             |  8 +++++++
>  xen/arch/arm/include/asm/arm64/hsr.h  |  1 +
>  xen/arch/arm/include/asm/cpufeature.h | 14 ++++++------
>  4 files changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index d14258290f..520faa02ca 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -229,6 +229,7 @@ void do_sysreg(struct cpu_user_regs *regs,
>       */
>      case HSR_SYSREG_PMINTENSET_EL1:
>      case HSR_SYSREG_PMINTENCLR_EL1:
> +    case HSR_SYSREG_PMMIR_EL1:
What about AArch32 PMMIR?

>          /*
>           * Accessible from EL1 only, but if EL0 trap happens handle as
>           * undef.
> @@ -306,7 +307,6 @@ void do_sysreg(struct cpu_user_regs *regs,
>      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
>      GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
>      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
> -    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
>      GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
>      GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
>      GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
> @@ -326,6 +326,18 @@ void do_sysreg(struct cpu_user_regs *regs,
>      GENERATE_TID3_INFO(MVFR1_EL1, mvfr, 1)
>      GENERATE_TID3_INFO(MVFR2_EL1, mvfr, 2)
>  
> +    case HSR_SYSREG_ID_DFR0_EL1:
You only cover AArch64. What about AArch32 DFR0?

> +    {
> +        struct domain *d = current->domain;
Use v->domain instead like the surrounding code

> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !(d->options & XEN_DOMCTL_CDF_vpmu) )
> +            info_dbg32.perfmon = 0;
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg32.bits[0]);
> +    }
> +
>      case HSR_SYSREG_ID_AA64PFR0_EL1:
>      {
>          register_t guest_reg_value = domain_cpuinfo.pfr64.bits[0];
> @@ -348,7 +360,6 @@ void do_sysreg(struct cpu_user_regs *regs,
>      }
>  
>      GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
> -    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
>      GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
What about DFR1 fields like PMICNTR? They suffer from the same problem.

>      GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
>      GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
> @@ -358,6 +369,22 @@ void do_sysreg(struct cpu_user_regs *regs,
>      GENERATE_TID3_INFO(ID_AA64AFR0_EL1, aux64, 0)
>      GENERATE_TID3_INFO(ID_AA64AFR1_EL1, aux64, 1)
>  
> +    case HSR_SYSREG_ID_AA64DFR0_EL1:
Please adhere to the order in which the cases were originally placed
> +    {
> +        struct domain *d = current->domain;
> +        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
> +
> +        if ( !(d->options & XEN_DOMCTL_CDF_vpmu) )
To avoid duplication, please introduce is_vpmu_domain
> +        {
> +            info_dbg64.pmu_ver = 0;
> +            info_dbg64.mtpmu = 0;
> +            info_dbg64.pmss = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg64.bits[0]);
> +    }
> +
>      case HSR_SYSREG_ID_AA64ZFR0_EL1:
>      {
>          /*
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 94d14fb6a9..0e9bf15ca5 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -219,6 +219,14 @@ static int __init create_domain_cpuinfo(void)
>      domain_cpuinfo.isa64.api = 0;
>      domain_cpuinfo.isa64.gpa = 0;
>      domain_cpuinfo.isa64.gpi = 0;
> +
> +    /* Hide SPE, TRBE, BRBE, and Trace Extensions */
> +    domain_cpuinfo.dbg64.pms_ver = 0;
> +    domain_cpuinfo.dbg64.trace_ver = 0;
> +    domain_cpuinfo.dbg64.trace_filt = 0;
> +    domain_cpuinfo.dbg64.trace_buffer = 0;
> +    domain_cpuinfo.dbg64.ext_trc_buff = 0;
> +    domain_cpuinfo.dbg64.brbe = 0;
>  #endif
>  
>      /* Hide AMU support */
> diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h
> index 1495ccddea..ed18184cc7 100644
> --- a/xen/arch/arm/include/asm/arm64/hsr.h
> +++ b/xen/arch/arm/include/asm/arm64/hsr.h
> @@ -84,6 +84,7 @@
>  #define HSR_SYSREG_FAR_EL1        HSR_SYSREG(3,0,c6, c0,0)
>  #define HSR_SYSREG_PMINTENSET_EL1 HSR_SYSREG(3,0,c9,c14,1)
>  #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
> +#define HSR_SYSREG_PMMIR_EL1      HSR_SYSREG(3,0,c9,c14,6)
>  #define HSR_SYSREG_MAIR_EL1       HSR_SYSREG(3,0,c10,c2,0)
>  #define HSR_SYSREG_AMAIR_EL1      HSR_SYSREG(3,0,c10,c3,0)
>  #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index bf902a3970..ce8b58458f 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -208,7 +208,7 @@ struct cpuinfo_arm {
>          };
>      } pfr64;
>  
> -    union {
> +    union cpuinfo_dbg64 {
>          register_t bits[2];
>          struct {
>              /* DFR0 */
> @@ -216,16 +216,18 @@ struct cpuinfo_arm {
>              unsigned long trace_ver:4;
>              unsigned long pmu_ver:4;
>              unsigned long brps:4;
> -            unsigned long __res0:4;
> +            unsigned long pmss:4;
>              unsigned long wrps:4;
> -            unsigned long __res1:4;
> +            unsigned long sebep:4;
Where did you take this field from? I can't see it in the latest Arm ARM:
https://support.arm.com/documentation/ddi0487/mc/-Part-D-The-AArch64-System-Level-Architecture/-Chapter-D24-AArch64-System-Register-Descriptions/-D24-2-General-system-control-registers/-D24-2-79-ID-AA64DFR0-EL1--AArch64-Debug-Feature-Register-0?lang=en

>              unsigned long ctx_cmps:4;
>              unsigned long pms_ver:4;
>              unsigned long double_lock:4;
>              unsigned long trace_filt:4;
> -            unsigned long __res2:4;
> +            unsigned long trace_buffer:4;
>              unsigned long mtpmu:4;
> -            unsigned long __res3:12;
> +            unsigned long brbe:4;
> +            unsigned long ext_trc_buff:4;
> +            unsigned long hpmn0:4;
>  
>              /* DFR1 */
>              unsigned long __res4:64;
> @@ -408,7 +410,7 @@ struct cpuinfo_arm {
>          };
>      } pfr32;
>  
> -    union {
> +    union cpuinfo_dbg32 {
>          register_t bits[2];
>          struct {
>              /* DFR0 */

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:19:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:19:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392494.1631450 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrcX-0004rv-Bv; Mon, 17 Aug 2026 07:18:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392494.1631450; Mon, 17 Aug 2026 07:18:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrcX-0004ro-9C; Mon, 17 Aug 2026 07:18:57 +0000
Received: by outflank-mailman (input) for mailman id 1392494;
 Mon, 17 Aug 2026 07:18:56 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wvrcV-0004ri-Tp
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:18:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrcU-001rF9-B4
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:18:54 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5bb-e002-0a2a0a5209dd-0a2a4509a8f4-34
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:18:54 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5de-be1a-0a2a45090019-c387df82e082-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:18:54 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 86D3683E91;
 Mon, 17 Aug 2026 07:18:45 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 394687933D;
 Mon, 17 Aug 2026 07:18:45 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id sUBrDNW1gmqfPwAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 17 Aug 2026 07:18:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951129; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=jSulumChUlq0Y5pej5oMnSH2oDsNiG345A5cdtm1VEk=;
	b=PDvsHaBl0Va1DlesTfsjQsV8nf/AMcC8JWRoYdtsHQhatMD6EWDU7z1eFOl5iYUwrKC8eN
	3+fB75inUfeHWv31jidk5I4wQ/U3qE7hhhm/isLWLSEY6K1/t6T07SIHBE2lfVv7DpYd38
	ngFUok18jKAKd8kbaEDGVLECiTcMP4c=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951125; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=jSulumChUlq0Y5pej5oMnSH2oDsNiG345A5cdtm1VEk=;
	b=Kodbygtmw8wtOXnTAsVDGgMXa6UKLzhfThVoTmF8RhP2pFb2aVD0wvtRftUeCRs9Bw4/p3
	iwnkFqsUPiT1/SCarKwLeHUHSjNyGxpv/zj1JEVUOOJF1gPIwTqInauONn1ZHP79XPRzoa
	mkuXINLW3/C0PsF2pizkrzqYi/KEx1Q=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Community Manager <community.manager@xenproject.org>
Subject: [PATCH 0/4] stubdom: remove building unused libraries
Date: Mon, 17 Aug 2026 09:18:39 +0200
Message-ID: <20260817071843.114898-1-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.30
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-1.30 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_CONTAINS_FROM(1.00)[];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_CC(0.00)[suse.com,citrix.com,vates.tech,amd.com,xen.org,xenproject.org,kernel.org,ens-lyon.org,gmail.com];
	RCPT_COUNT_TWELVE(0.00)[12];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TAGGED_RCPT(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[changelog.md:url,suse.com:mid,config.mk:url,imap1.dmz-prg2.suse.org:helo];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-purgate-ID: tlsNG-bad1c0/1786951134-BC4CB034-5B9AF485/0/0
X-purgate-type: clean
X-purgate-size: 907

Pciutils and zlib are no longer used by any stubdom since removal of
grub-pv, so they can be removed from the stubdom build system.

Juergen Gross (4):
  Config: update Mini-OS commit id
  stubdom: remove pciutils
  stubdom: remove build of zlib
  CHANGELOG: add removal of grub-pv

 CHANGELOG.md              |   2 +
 Config.mk                 |   2 +-
 config/Stubdom.mk.in      |   6 -
 stubdom/.gitignore        |   2 -
 stubdom/Makefile          |  53 +------
 stubdom/configure         |  36 -----
 stubdom/configure.ac      |   2 -
 stubdom/libpci.config.h   |   5 -
 stubdom/libpci.config.mak |   7 -
 stubdom/pciutils.patch    | 298 --------------------------------------
 10 files changed, 4 insertions(+), 409 deletions(-)
 delete mode 100644 stubdom/libpci.config.h
 delete mode 100644 stubdom/libpci.config.mak
 delete mode 100644 stubdom/pciutils.patch

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:19:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:19:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392497.1631478 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrci-0005Z8-3k; Mon, 17 Aug 2026 07:19:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392497.1631478; Mon, 17 Aug 2026 07:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrci-0005Yy-0U; Mon, 17 Aug 2026 07:19:08 +0000
Received: by outflank-mailman (input) for mailman id 1392497;
 Mon, 17 Aug 2026 07:19:06 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wvrcf-0005SL-OJ
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:19:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrcf-00Fq6W-4u
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:19:05 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5e9-8faa-0a2a0a5109dd-0a2a4507ce94-0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:05 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5e8-b4ea-0a2a45070019-c387df82a520-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:05 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 87DEE83EA1;
 Mon, 17 Aug 2026 07:18:56 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 66A547933D;
 Mon, 17 Aug 2026 07:18:56 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id q4X0F+C1gmqwPwAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 17 Aug 2026 07:18:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951140; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jz9nxDviL3DwVV7FG8Py1n1l8eGXnnA2gyfKebkXks0=;
	b=LO2GD1GsZAke8p0iuYt8iZ/n97H4LPgBLCDLCmmsrJYuz4uy8JxQ5HmEFBNM0Q5tvd39rV
	Trnl9yhhMianKdbwegyXaTGLghYn6VAxGQrtu9A2tPdv/CwwvS1mrGE8IpX79Ywm+A6+Uj
	zIeEGpPdj/sZQ+D0JB/br/Wyi+xCRI0=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951136; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=jz9nxDviL3DwVV7FG8Py1n1l8eGXnnA2gyfKebkXks0=;
	b=uaGT8T4fKbfFSj07IXgCCJIeYvXvbIhyVTBM7fSDXVKqof+cnVMxdlwD82vviCSUC/NWzb
	71f2nUeKFRQzFaQC/G6UBkl7Oyhq2QBP+9YTbrU5/piHVKRidLdePZVXg4jIlcPu9BGsQn
	zEZeneZt4lWXR0s/UL4nliYgOiWyQ1M=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: [PATCH 2/4] stubdom: remove pciutils
Date: Mon, 17 Aug 2026 09:18:41 +0200
Message-ID: <20260817071843.114898-3-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260817071843.114898-1-jgross@suse.com>
References: <20260817071843.114898-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,sourceware.org:url,gnu.org:url,imap1.dmz-prg2.suse.org:helo];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Score: -6.80
X-Spam-Level: 
X-purgate-ID: tlsNG-ef75cf/1786951145-A6CDFAE4-C61C9F2C/0/0
X-purgate-type: clean
X-purgate-size: 16091

There is no user of libpci left in stubdoms.

Remove libpci from the stubdom build system.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 config/Stubdom.mk.in      |   3 -
 stubdom/.gitignore        |   1 -
 stubdom/Makefile          |  33 +----
 stubdom/configure         |  21 ---
 stubdom/configure.ac      |   1 -
 stubdom/libpci.config.h   |   5 -
 stubdom/libpci.config.mak |   7 -
 stubdom/pciutils.patch    | 298 --------------------------------------
 8 files changed, 2 insertions(+), 367 deletions(-)
 delete mode 100644 stubdom/libpci.config.h
 delete mode 100644 stubdom/libpci.config.mak
 delete mode 100644 stubdom/pciutils.patch

diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in
index 0d70d03941..b90eaee75a 100644
--- a/config/Stubdom.mk.in
+++ b/config/Stubdom.mk.in
@@ -14,9 +14,6 @@ STUBDOM_INSTALL     := @STUBDOM_INSTALL@
 ZLIB_VERSION        := @ZLIB_VERSION@
 ZLIB_URL            := @ZLIB_URL@
 
-LIBPCI_VERSION      := @LIBPCI_VERSION@
-LIBPCI_URL          := @LIBPCI_URL@
-
 NEWLIB_VERSION      := @NEWLIB_VERSION@
 NEWLIB_URL          := @NEWLIB_URL@
 
diff --git a/stubdom/.gitignore b/stubdom/.gitignore
index 08f2e9b432..8c6dc00f83 100644
--- a/stubdom/.gitignore
+++ b/stubdom/.gitignore
@@ -23,7 +23,6 @@
 /mk-headers-*
 /newlib-1.*
 /newlib-x86*
-/pciutils-*
 /pkg-config/*
 /polarssl-*
 /tpm_emulator-*
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 40b6ececf1..f542a4295a 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -122,34 +122,6 @@ $(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE)
 	  $(MAKE) DESTDIR= libz.a && \
 	  $(MAKE) DESTDIR= install )
 
-##############
-# Cross-libpci
-##############
-
-pciutils-$(LIBPCI_VERSION).tar.bz2:
-	$(FETCHER) $@ $(LIBPCI_URL)/$@
-
-pciutils-$(XEN_TARGET_ARCH): pciutils-$(LIBPCI_VERSION).tar.bz2
-	tar xjf $<
-	mv pciutils-$(LIBPCI_VERSION) $@
-	patch -d $@ -p1 < pciutils.patch
-	touch $@
-
-LIBPCI_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libpci.a
-.PHONY: cross-libpci
-cross-libpci: $(LIBPCI_STAMPFILE)
-$(LIBPCI_STAMPFILE): pciutils-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) $(ZLIB_STAMPFILE)
-	( cd $< && \
-	  cp ../libpci.config.h lib/config.h && \
-	  chmod u+w lib/config.h && \
-	  echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \
-	  ln -sf ../../libpci.config.mak lib/config.mk && \
-	  $(MAKE) DESTDIR= CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \
-	  $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ && \
-	  $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \
-	  $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \
-	)
-
 ######
 # lwIP
 ######
@@ -250,7 +222,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE)
 #######
 
 .PHONY: $(CROSS_ROOT)
-$(CROSS_ROOT): cross-newlib cross-zlib cross-libpci
+$(CROSS_ROOT): cross-newlib cross-zlib
 
 #######
 # libraries under tools/libs
@@ -477,7 +449,7 @@ clean:
 crossclean: clean
 	rm -fr $(CROSS_ROOT)
 	rm -fr newlib-$(XEN_TARGET_ARCH)
-	rm -fr zlib-$(XEN_TARGET_ARCH) pciutils-$(XEN_TARGET_ARCH)
+	rm -fr zlib-$(XEN_TARGET_ARCH)
 	rm -fr libs-$(XEN_TARGET_ARCH)
 	rm -fr xenstore xenstorepvh
 	rm -fr gmp-$(XEN_TARGET_ARCH)
@@ -502,7 +474,6 @@ downloadclean: patchclean
 	rm -f zlib-$(ZLIB_VERSION).tar.gz
 	rm -f gmp-$(GMP_VERSION).tar.bz2
 	rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz
-	rm -f pciutils-$(LIBPCI_VERSION).tar.bz2
 	rm -f lwip-$(LWIP_VERSION).tar.gz
 	rm -f polarssl-$(POLARSSL_VERSION)-gpl.tgz
 
diff --git a/stubdom/configure b/stubdom/configure
index 689ff4d6ed..f3d63dceff 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -634,8 +634,6 @@ LWIP_VERSION
 LWIP_URL
 NEWLIB_VERSION
 NEWLIB_URL
-LIBPCI_VERSION
-LIBPCI_URL
 ZLIB_VERSION
 ZLIB_URL
 INSTALL_DATA
@@ -725,7 +723,6 @@ LDFLAGS
 LIBS
 CPPFLAGS
 ZLIB_URL
-LIBPCI_URL
 NEWLIB_URL
 LWIP_URL
 GMP_URL
@@ -1376,7 +1373,6 @@ Some influential environment variables:
   CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
               you have headers in a nonstandard directory <include dir>
   ZLIB_URL    Download url for zlib
-  LIBPCI_URL  Download url for libpci
   NEWLIB_URL  Download url for newlib
   LWIP_URL    Download url for lwip
   GMP_URL     Download url for libgmp
@@ -4038,23 +4034,6 @@ ZLIB_VERSION="1.2.3"
 
 
 
-if test "x$LIBPCI_URL" = "x"
-then :
-
-	if test "x$extfiles" = "xy"
-then :
-  LIBPCI_URL=\$\(XEN_EXTFILES_URL\)
-else $as_nop
-  LIBPCI_URL="https://mirrors.edge.kernel.org/pub/software/utils/pciutils"
-fi
-
-fi
-LIBPCI_VERSION="2.2.9"
-
-
-
-
-
 if test "x$NEWLIB_URL" = "x"
 then :
 
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index 6ff3ab0ee9..d3d2a840d3 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -39,7 +39,6 @@ AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake])
 
 # Stubdom libraries version and url setup
 AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3])
-AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], [https://mirrors.edge.kernel.org/pub/software/utils/pciutils])
 AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib])
 AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip])
 AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive])
diff --git a/stubdom/libpci.config.h b/stubdom/libpci.config.h
deleted file mode 100644
index 28c2f6ab31..0000000000
--- a/stubdom/libpci.config.h
+++ /dev/null
@@ -1,5 +0,0 @@
-#define PCI_OS_MINIOS
-#define PCI_HAVE_STDINT_H
-#define PCI_PATH_IDS_DIR "."
-#define PCI_COMPRESSED_IDS
-#define PCI_IDS "pci.ids.gz"
diff --git a/stubdom/libpci.config.mak b/stubdom/libpci.config.mak
deleted file mode 100644
index 5c8632cf07..0000000000
--- a/stubdom/libpci.config.mak
+++ /dev/null
@@ -1,7 +0,0 @@
-LIBZ=-lz
-LDLIBS+=$(LIBZ)
-PCI_OS_MINIOS=1
-PCI_HAVE_STDINT_H=1
-PCI_PATH_IDS_DIR=.
-PCI_COMPRESSED_IDS=1
-PCI_IDS=pci.ids.gz
diff --git a/stubdom/pciutils.patch b/stubdom/pciutils.patch
deleted file mode 100644
index 5ab84d6cce..0000000000
--- a/stubdom/pciutils.patch
+++ /dev/null
@@ -1,298 +0,0 @@
-diff -urN pciutils-2.2.9.orig/lib/access.c pciutils-2.2.9/lib/access.c
---- pciutils-2.2.9.orig/lib/access.c	2007-02-06 11:59:43.000000000 +0000
-+++ pciutils-2.2.9/lib/access.c	2008-06-30 19:07:09.713187000 +0100
-@@ -57,6 +57,11 @@
- #else
-   NULL,
- #endif
-+#ifdef PCI_OS_MINIOS
-+  &pm_minios,
-+#else
-+  NULL,
-+#endif
- };
- 
- struct pci_access *
---- pciutils-2.2.9.orig/lib/pci.h	2006-09-09 13:46:06.000000000 +0100
-+++ pciutils-2.2.9/lib/pci.h	2008-06-30 18:56:15.350111000 +0100
-@@ -33,6 +33,7 @@
-   PCI_ACCESS_NBSD_LIBPCI,		/* NetBSD libpci */
-   PCI_ACCESS_OBSD_DEVICE,		/* OpenBSD /dev/pci */
-   PCI_ACCESS_DUMP,			/* Dump file (params: filename) */
-+  PCI_ACCESS_MINIOS,			/* MiniOS */
-   PCI_ACCESS_MAX
- };
- 
---- pciutils-2.2.9.orig/lib/internal.h	2006-09-09 11:52:47.000000000 +0100
-+++ pciutils-2.2.9/lib/internal.h	2008-07-01 10:46:24.968202000 +0100
-@@ -37,4 +37,4 @@
- 
- extern struct pci_methods pm_intel_conf1, pm_intel_conf2, pm_linux_proc,
- 	pm_fbsd_device, pm_aix_device, pm_nbsd_libpci, pm_obsd_device,
--	pm_dump, pm_linux_sysfs;
-+	pm_dump, pm_linux_sysfs, pm_minios;
---- pciutils-2.2.9.orig/lib/Makefile	2007-10-19 13:41:34.000000000 +0100
-+++ pciutils-2.2.9/lib/Makefile	2008-07-01 12:13:14.400525000 +0100
-@@ -46,6 +46,12 @@
- PCILIB=libpciutils.a
- endif
- 
-+ifdef PCI_OS_MINIOS
-+XEN_ROOT=$(CURDIR)/../../..
-+include $(XEN_ROOT)/Config.mk
-+OBJS += minios.o
-+endif
-+
- all: $(PCILIB) $(PCILIBPC)
- 
- $(PCILIB): $(OBJS)
---- pciutils-2.2.9.orig/lib/types.h    2009-07-14 18:18:59.000000000 +0200
-+++ pciutils-2.2.9/lib/types.h 2009-07-14 18:19:16.000000000 +0200
-@@ -20,10 +20,12 @@ typedef DWORD u32;
- typedef uint8_t u8;
- typedef uint16_t u16;
- typedef uint32_t u32;
-+typedef uint64_t u64;
- #else
- typedef u_int8_t u8;
- typedef u_int16_t u16;
- typedef u_int32_t u32;
-+typedef u_int64_t u64;
- #endif
-
- #ifdef PCI_HAVE_64BIT_ADDRESS
- 
---- pciutils-2.2.9.orig/lib/minios.c	1970-01-01 01:00:00.000000000 +0100
-+++ pciutils-2.2.9/lib/minios.c	2008-07-01 12:31:40.554260000 +0100
-@@ -0,0 +1,106 @@
-+/*
-+ *	The PCI Library -- MiniOS PCI frontend access
-+ *
-+ *	Samuel Thibault <samuel.thibault@eu.citrix.com>, 2008
-+ *
-+ *	Can be freely distributed and used under the terms of the GNU GPL.
-+ */
-+
-+#include <os.h>
-+#include <pcifront.h>
-+#include <xenbus.h>
-+#include "internal.h"
-+
-+static int
-+minios_detect(struct pci_access *a)
-+{
-+  return 1;
-+}
-+
-+static void
-+minios_init(struct pci_access *a)
-+{
-+}
-+
-+static void
-+minios_cleanup(struct pci_access *a)
-+{
-+  shutdown_pcifront(NULL);
-+}
-+
-+static void
-+minios_scan(struct pci_access *a)
-+{
-+  void func(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-+  {
-+    struct pci_dev *d = pci_alloc_dev(a);
-+
-+    d->domain = domain;
-+    d->bus = bus;
-+    d->dev = slot;
-+    d->func = fun;
-+
-+    pci_link_dev(a, d);
-+  }
-+
-+  pcifront_scan(NULL, func);
-+}
-+
-+static int
-+minios_read(struct pci_dev *d, int pos, byte *buf, int len)
-+{
-+  unsigned int val;
-+  switch (len) {
-+    case 1:
-+      if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val))
-+        return 0;
-+      * buf = val;
-+      return 1;
-+    case 2:
-+      if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val))
-+        return 0;
-+      *(u16 *) buf = cpu_to_le16((u16) val);
-+      return 1;
-+    case 4:
-+      if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val))
-+        return 0;
-+      *(u32 *) buf = cpu_to_le32((u32) val);
-+      return 1;
-+    default:
-+      return pci_generic_block_read(d, pos, buf, len);
-+  }
-+}
-+
-+static int
-+minios_write(struct pci_dev *d, int pos, byte *buf, int len)
-+{
-+  unsigned int val;
-+  switch (len) {
-+    case 1:
-+      val = * buf;
-+      break;
-+    case 2:
-+      val = le16_to_cpu(*(u16 *) buf);
-+      break;
-+    case 4:
-+      val = le32_to_cpu(*(u32 *) buf);
-+      break;
-+    default:
-+      return pci_generic_block_write(d, pos, buf, len);
-+  }
-+  return !pcifront_conf_write(NULL, d->domain, d->bus, d->dev, d->func, pos, len, val);
-+}
-+
-+struct pci_methods pm_minios = {
-+  "MiniOS-device",
-+  NULL,                                 /* config */
-+  minios_detect,
-+  minios_init,
-+  minios_cleanup,
-+  minios_scan,
-+  pci_generic_fill_info,
-+  minios_read,
-+  minios_write,
-+  NULL,                                 /* dev_init */
-+  NULL                                  /* dev_cleanup */
-+};
---- pciutils-2.2.9/lib/generic.c	2007-02-06 12:00:05.000000000 +0000
-+++ pciutils-2.2.9-mine/lib/generic.c	2008-07-01 19:13:52.289949000 +0100
-@@ -74,6 +74,19 @@
-   pci_generic_scan_bus(a, busmap, 0);
- }
- 
-+static u32 pci_size(u32 base, u32 maxbase, u32 mask)
-+{
-+  u32 size = mask & maxbase;
-+  if (!size)
-+    return 0;
-+  size = (size & ~(size-1)) - 1;
-+
-+  if (base == maxbase && ((base | size) & mask) != mask)
-+    return 0;
-+
-+  return size + 1;
-+}
-+
- int
- pci_generic_fill_info(struct pci_dev *d, int flags)
- {
-@@ -114,23 +127,61 @@
- 	      if (!x || x == (u32) ~0)
- 		continue;
- 	      if ((x & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO)
--		d->base_addr[i] = x;
--	      else
-+                {
-+                  d->base_addr[i] = x & PCI_BASE_ADDRESS_IO_MASK;
-+                  if (flags & PCI_FILL_SIZES)
-+                    {
-+                      u32 size;
-+                      pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0);
-+                      d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_IO_MASK);
-+                      pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x);
-+                    }
-+                }
-+              else
- 		{
- 		  if ((x & PCI_BASE_ADDRESS_MEM_TYPE_MASK) != PCI_BASE_ADDRESS_MEM_TYPE_64)
--		    d->base_addr[i] = x;
-+                    {
-+                      d->base_addr[i] = x & PCI_BASE_ADDRESS_MEM_MASK;
-+                      if (flags & PCI_FILL_SIZES)
-+                        {
-+                          u32 size;
-+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0);
-+                          d->size[i] = pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4);
-+                          d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_MEM_MASK);
-+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x);
-+                        }
-+                    }
- 		  else if (i >= cnt-1)
- 		    a->warning("%04x:%02x:%02x.%d: Invalid 64-bit address seen for BAR %d.", d->domain, d->bus, d->dev, d->func, i);
- 		  else
- 		    {
- 		      u32 y = pci_read_long(d, PCI_BASE_ADDRESS_0 + (++i)*4);
- #ifdef PCI_HAVE_64BIT_ADDRESS
--		      d->base_addr[i-1] = x | (((pciaddr_t) y) << 32);
-+		      d->base_addr[i-1] = (x | (((pciaddr_t) y) << 32)) & PCI_BASE_ADDRESS_MEM_MASK;
-+                      if (flags & PCI_FILL_SIZES)
-+                        {
-+                          u32 size;
-+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0);
-+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0);
-+                          d->size[i-1] = pci_size(y, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4) | 
-+                                         pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), 0xffffffff );
-+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x);
-+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, y);
-+                        }
- #else
- 		      if (y)
- 			a->warning("%04x:%02x:%02x.%d 64-bit device address ignored.", d->domain, d->bus, d->dev, d->func);
- 		      else
--			d->base_addr[i-1] = x;
-+                        {
-+                          d->base_addr[i-1] = x & PCI_BASE_ADDRESS_MEM_MASK;
-+                          if (flags & PCI_FILL_SIZES)
-+                            {
-+                              u32 size;
-+                              pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0);
-+                              d->size[i-1] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4), PCI_BASE_ADDRESS_MEM_MASK);
-+                              pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x);
-+                            }
-+                        }
- #endif
- 		    }
- 		}
-@@ -154,10 +205,19 @@
- 	{
- 	  u32 u = pci_read_long(d, reg);
- 	  if (u != 0xffffffff)
--	    d->rom_base_addr = u;
-+            {
-+              d->rom_base_addr = u;
-+              if (flags & PCI_FILL_SIZES)
-+                {
-+                  u32 size;
-+                  pci_write_long(d, reg, ~0);
-+                  d->rom_size = pci_read_long(d, reg);
-+                  pci_write_long(d, reg, u);
-+                }
-+            }
- 	}
-     }
--  return flags & ~PCI_FILL_SIZES;
-+  return flags;
- }
- 
- static int
-diff -uNpbE -uNpbEr pciutils-2.2.9.orig/lib/sysdep.h pciutils-2.2.9/lib/sysdep.h
---- pciutils-2.2.9.orig/lib/sysdep.h	2007-02-06 12:00:18.000000000 +0000
-+++ pciutils-2.2.9/lib/sysdep.h	2009-07-22 16:26:30.000000000 +0100
-@@ -32,6 +32,10 @@ typedef u16 word;
- 
- #else
- 
-+#ifdef PCI_OS_MINIOS
-+#include <machine/endian.h>
-+#endif
-+
- #ifdef PCI_OS_LINUX
- #include <endian.h>
- #define BYTE_ORDER __BYTE_ORDER
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:19:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:19:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392495.1631460 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrcd-00055a-Ma; Mon, 17 Aug 2026 07:19:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392495.1631460; Mon, 17 Aug 2026 07:19:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrcd-00055R-JS; Mon, 17 Aug 2026 07:19:03 +0000
Received: by outflank-mailman (input) for mailman id 1392495;
 Mon, 17 Aug 2026 07:19:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wvrcb-00054j-UB
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:19:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrca-00Fq1S-6m
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:19:00 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5cf-2eae-0a2a0a5409dd-0a2a4504abe0-44
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:00 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5e3-b57f-0a2a45040019-c387df83eb62-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:18:59 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 1EF993E22;
 Mon, 17 Aug 2026 07:18:51 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CEB7B79340;
 Mon, 17 Aug 2026 07:18:50 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id cuJHMdq1gmqpPwAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 17 Aug 2026 07:18:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951135; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=JQLgiM06Stpg2JnRvBMMMCddiNu89pqkhfZS0XLLlhI=;
	b=eYtCD6w29p5Toq6OdpSu1bNkb3pycSUEp9ESdbQm/5OvBOiW9GMlbWRWk0KbMrNX0rLl/e
	JFS2aoGNqVvCZvL6Fhn1+EppQs9MeeDhNE5eQTBALDO3WX1t04oyFlLwFv7jdYQsm0H0Ua
	8M2DyqTgXqI01IPQjKjTKYnusHQJZLc=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951131; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=JQLgiM06Stpg2JnRvBMMMCddiNu89pqkhfZS0XLLlhI=;
	b=opWbS6WChP8WlcHZ53S+OcK58DqgfJ+phMCKDibhjjAkoyDj2cK6wULFdth02DW0OXPDcN
	iV6PA/qc9jhkZ+hnOCXYN3VWu2N0LiDvq5dHS8MYblRMW9dv7iBf8pqIufhDNIQ3GGijVq
	uUhpTLUnyBgC+W5aZHcX5sT3mp3gbD0=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 1/4] Config: update Mini-OS commit id
Date: Mon, 17 Aug 2026 09:18:40 +0200
Message-ID: <20260817071843.114898-2-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260817071843.114898-1-jgross@suse.com>
References: <20260817071843.114898-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.80
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,config.mk:url,suse.com:email,suse.com:mid];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-purgate-ID: tlsNG-ebf023/1786951139-50EDEB50-B3304850/0/0
X-purgate-type: clean
X-purgate-size: 725

Use the newest Mini-OS.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index b3d48e49c7..b2dcc729f3 100644
--- a/Config.mk
+++ b/Config.mk
@@ -217,7 +217,7 @@ QEMU_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/qemu-xen.git
 QEMU_UPSTREAM_REVISION ?= master
 
 MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git
-MINIOS_UPSTREAM_REVISION ?= b6f79f5f44cf69044079c042b88fe9d75367642e
+MINIOS_UPSTREAM_REVISION ?= 26ceb2daf95dd9e7fed9c83d36be3aaf1a0fa8a1
 
 SEABIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/seabios.git
 SEABIOS_UPSTREAM_REVISION ?= rel-1.17.0
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:19:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:19:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392496.1631469 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrce-0005IU-Ri; Mon, 17 Aug 2026 07:19:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392496.1631469; Mon, 17 Aug 2026 07:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrce-0005IN-Ov; Mon, 17 Aug 2026 07:19:04 +0000
Received: by outflank-mailman (input) for mailman id 1392496;
 Mon, 17 Aug 2026 07:19:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wvrcc-00055D-Sd
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:19:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrcc-002YtT-9e
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:19:02 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5e2-2eae-0a2a0a5409dd-0a2a4509ad96-6
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:02 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5e6-be1a-0a2a45090019-c387df83b234-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:02 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id F2D763E0F;
 Mon, 17 Aug 2026 07:19:01 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D2BC179340;
 Mon, 17 Aug 2026 07:19:01 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id c9ViMuW1gmq3PwAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 17 Aug 2026 07:19:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Authentication-Results: smtp-out2.suse.de;
	none
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: [PATCH 3/4] stubdom: remove build of zlib
Date: Mon, 17 Aug 2026 09:18:42 +0200
Message-ID: <20260817071843.114898-4-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260817071843.114898-1-jgross@suse.com>
References: <20260817071843.114898-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Rspamd-Queue-Id: F2D763E0F
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spam-Flag: NO
X-Spam-Score: -4.00
X-Spam-Level: 
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-purgate-ID: tlsNG-bad1c0/1786951142-BC8C9034-5E764E0C/0/0
X-purgate-type: clean
X-purgate-size: 4435

The last users of zlib for stubdoms have been removed.

Remove zlib from the stubdom build system, too.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 config/Stubdom.mk.in |  3 ---
 stubdom/.gitignore   |  1 -
 stubdom/Makefile     | 24 +-----------------------
 stubdom/configure    | 15 ---------------
 stubdom/configure.ac |  1 -
 5 files changed, 1 insertion(+), 43 deletions(-)

diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in
index b90eaee75a..dc0a3b54b3 100644
--- a/config/Stubdom.mk.in
+++ b/config/Stubdom.mk.in
@@ -11,9 +11,6 @@ STUBDOM_TARGETS     := @STUBDOM_TARGETS@
 STUBDOM_BUILD       := @STUBDOM_BUILD@
 STUBDOM_INSTALL     := @STUBDOM_INSTALL@
 
-ZLIB_VERSION        := @ZLIB_VERSION@
-ZLIB_URL            := @ZLIB_URL@
-
 NEWLIB_VERSION      := @NEWLIB_VERSION@
 NEWLIB_URL          := @NEWLIB_URL@
 
diff --git a/stubdom/.gitignore b/stubdom/.gitignore
index 8c6dc00f83..e5d5744361 100644
--- a/stubdom/.gitignore
+++ b/stubdom/.gitignore
@@ -29,4 +29,3 @@
 /vtpm/vtpm_manager.h
 /xenstore
 /xenstorepvh
-/zlib-*
diff --git a/stubdom/Makefile b/stubdom/Makefile
index f542a4295a..8830deebce 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -102,26 +102,6 @@ $(NEWLIB_STAMPFILE): mk-headers-$(XEN_TARGET_ARCH) newlib-$(NEWLIB_VERSION)
 	  $(MAKE) DESTDIR= && \
 	  $(MAKE) DESTDIR= install )
 
-############
-# Cross-zlib
-############
-
-zlib-$(ZLIB_VERSION).tar.gz:
-	$(FETCHER) $@ $(ZLIB_URL)/$@
-
-zlib-$(XEN_TARGET_ARCH): zlib-$(ZLIB_VERSION).tar.gz 
-	tar xzf $<
-	mv zlib-$(ZLIB_VERSION) $@
-
-ZLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libz.a
-.PHONY: cross-zlib
-cross-zlib: $(ZLIB_STAMPFILE)
-$(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE)
-	( cd $< && \
-	  CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf && \
-	  $(MAKE) DESTDIR= libz.a && \
-	  $(MAKE) DESTDIR= install )
-
 ######
 # lwIP
 ######
@@ -222,7 +202,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE)
 #######
 
 .PHONY: $(CROSS_ROOT)
-$(CROSS_ROOT): cross-newlib cross-zlib
+$(CROSS_ROOT): cross-newlib
 
 #######
 # libraries under tools/libs
@@ -449,7 +429,6 @@ clean:
 crossclean: clean
 	rm -fr $(CROSS_ROOT)
 	rm -fr newlib-$(XEN_TARGET_ARCH)
-	rm -fr zlib-$(XEN_TARGET_ARCH)
 	rm -fr libs-$(XEN_TARGET_ARCH)
 	rm -fr xenstore xenstorepvh
 	rm -fr gmp-$(XEN_TARGET_ARCH)
@@ -471,7 +450,6 @@ patchclean: crossclean
 .PHONY: downloadclean
 downloadclean: patchclean
 	rm -f newlib-$(NEWLIB_VERSION).tar.gz
-	rm -f zlib-$(ZLIB_VERSION).tar.gz
 	rm -f gmp-$(GMP_VERSION).tar.bz2
 	rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz
 	rm -f lwip-$(LWIP_VERSION).tar.gz
diff --git a/stubdom/configure b/stubdom/configure
index f3d63dceff..1a5687d32b 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -634,8 +634,6 @@ LWIP_VERSION
 LWIP_URL
 NEWLIB_VERSION
 NEWLIB_URL
-ZLIB_VERSION
-ZLIB_URL
 INSTALL_DATA
 INSTALL_SCRIPT
 INSTALL_PROGRAM
@@ -722,7 +720,6 @@ CFLAGS
 LDFLAGS
 LIBS
 CPPFLAGS
-ZLIB_URL
 NEWLIB_URL
 LWIP_URL
 GMP_URL
@@ -1372,7 +1369,6 @@ Some influential environment variables:
   LIBS        libraries to pass to the linker, e.g. -l<library>
   CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
               you have headers in a nonstandard directory <include dir>
-  ZLIB_URL    Download url for zlib
   NEWLIB_URL  Download url for newlib
   LWIP_URL    Download url for lwip
   GMP_URL     Download url for libgmp
@@ -4023,17 +4019,6 @@ fi
 # Stubdom libraries version and url setup
 
 
-if test "x$ZLIB_URL" = "x"
-then :
-
-	ZLIB_URL=\$\(XEN_EXTFILES_URL\)
-fi
-ZLIB_VERSION="1.2.3"
-
-
-
-
-
 if test "x$NEWLIB_URL" = "x"
 then :
 
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index d3d2a840d3..34a47c95e1 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -38,7 +38,6 @@ AC_PROG_INSTALL
 AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake])
 
 # Stubdom libraries version and url setup
-AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3])
 AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib])
 AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip])
 AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive])
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:19:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:19:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392501.1631488 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrcr-00062F-GP; Mon, 17 Aug 2026 07:19:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392501.1631488; Mon, 17 Aug 2026 07:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrcr-000626-CN; Mon, 17 Aug 2026 07:19:17 +0000
Received: by outflank-mailman (input) for mailman id 1392501;
 Mon, 17 Aug 2026 07:19:16 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wvrcq-0005xz-I4
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:19:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrcp-00G3tD-V2
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:19:15 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5e7-bab6-0a2a0a5309dd-0a2a4504ccb6-40
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:15 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a82b5f3-b57f-0a2a45040019-c387df82bd4c-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:19:15 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 7338683E99;
 Mon, 17 Aug 2026 07:19:07 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 48DFD7933D;
 Mon, 17 Aug 2026 07:19:07 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id nVmoEOu1gmq/PwAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 17 Aug 2026 07:19:07 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951151; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=rJBC93oeDjibAmlMfbYh+ITd4umiwKFoqqHnj9UduOs=;
	b=E8OOUrkhhIkjm6Ru6EyxEuyqgveSBW8/jO2xGKSA886zXpgBzVEgJdmLI6ktv5YCDX0z6q
	TfGBQbapOgNpxtINtPKeQbXKFTq3+0Vc+DJciyohLeeGyF8oCfD0Wa4MRUluska3XNA9RC
	PbpB6z2rkJoTn5syQuUHCV0g99uj//Y=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786951147; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=rJBC93oeDjibAmlMfbYh+ITd4umiwKFoqqHnj9UduOs=;
	b=YSC2yFpOCS0bWZAr6a6EBQpKvPEiNU8HcO11E4vg4v1ZJwdgdUGadITZUpq3vrk/DjbTp8
	nRjZ6FtJquU9/75bRFmeUjP3/YI7jiHzuViobEp3N91gAwf8m4k10279Se+n7ZH27KpHEs
	eF9sll8zptwPeg+YJfEmosW2kvHfsGA=
From: Juergen Gross <jgross@suse.com>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Community Manager <community.manager@xenproject.org>
Subject: [PATCH 4/4] CHANGELOG: add removal of grub-pv
Date: Mon, 17 Aug 2026 09:18:43 +0200
Message-ID: <20260817071843.114898-5-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260817071843.114898-1-jgross@suse.com>
References: <20260817071843.114898-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -5.30
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[99.99%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[suse.com,gmail.com,xenproject.org];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[xenproject.org:url,imap1.dmz-prg2.suse.org:helo,keepachangelog.com:url,suse.com:email,suse.com:mid,changelog.md:url];
	RCPT_COUNT_THREE(0.00)[4];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FREEMAIL_ENVRCPT(0.00)[gmail.com]
X-purgate-ID: tlsNG-ebf023/1786951155-524CBB50-523B1BCD/0/0
X-purgate-type: clean
X-purgate-size: 782

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index aa1a777dd4..a2dd01037b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -23,6 +23,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      The only known user was the classic-xen fork of Linux.  This does not
      affect Xen kexec support in the kexec-tools package.
    - The example stubdom "c-stubdom" has been removed.
+   - The grub-pv stubdom has been removed.  A grub-pv stubdom from an older
+     Xen version (e.g. 4.22) will still work with Xen 4.23.
 
 ## [4.22.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging) - 2026-07-30
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:30:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:30:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392535.1631496 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrnd-0001IU-Em; Mon, 17 Aug 2026 07:30:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392535.1631496; Mon, 17 Aug 2026 07:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvrnd-0001I7-BL; Mon, 17 Aug 2026 07:30:25 +0000
Received: by outflank-mailman (input) for mailman id 1392535;
 Mon, 17 Aug 2026 07:30:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wvrnb-0001I1-L4
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:30:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvrna-007bzz-Ks
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:30:22 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a82b888-8faa-0a2a0a5109dd-0a2a4501d222-24
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:30:22 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a82b88e-5984-0a2a45010019-8c4da68a984a-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:30:22 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id EAA43A1AB6;
 Mon, 17 Aug 2026 09:30:21 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1G9Lepkvo8Yi; Mon, 17 Aug 2026 09:30:21 +0200 (CEST)
Received: from end (lfbn-orl-1-1611-126.w90-107.abo.wanadoo.fr
 [90.107.165.126])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 9B5E5A0176;
 Mon, 17 Aug 2026 09:30:21 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wvrnZ-0000000BrZ1-0pUi; Mon, 17 Aug 2026 09:30:21 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786951822; bh=FnxL0SCDI1us44bkr5Es65JQS1FP9jHcif92WAvg7Gg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=BjGTCX0zEnL52Mz+T0RAzcFdiRZXYk6a9gfa9iyAQVUgjIjAmr0+YmxhI+EdTgo7F
	 sZ6yFSWVSHG521naqt550ZwoqOM1yQa9atuSLOBcUYavJz6jfovO4LPkQG0QC5pc7I
	 oAxCX9VXynLw+lkOdlcjH+THMGs8uxyt/2HhwRshRrL9Zjq81ssn3kbeiz6dgvao4S
	 iOhj0zWxxLizT6NuiDBu9aYUg5AjRihWVN4zpAeBjuA6voIef7npBB8EIYennRar8E
	 l6RjzsDDbjIE0Ww14zSNKl/n2nZGMjzpYdI8IJBvGfCUhzlnftRNWvCKaRAgYMTwTA
	 mNWFPE9JMYhrA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786951821; bh=FnxL0SCDI1us44bkr5Es65JQS1FP9jHcif92WAvg7Gg=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=TNWHUNV6LT69EF8RzJ1wsLHu0KsQIQ6GFev+P1NQB2Afx7UPNGii4UDqlKKL0UhK1
	 XJE1aUheqBHf9L6ShzlR30mvMrz5gMFm5GTYNBhswaLPM7/bdhlTdtTQbD+XjoXLU0
	 Q+j0v2ykAYzr6p8aJBK5uf4pEs3E65NZfHPfdy8zwqrgD0EmqXs7agzZ/H8A/kug4+
	 hMs5NDSsHg+lv+r6725ETtsjs/rSQMv9xC94kWe0dE9DXFCPfbL7N29jrAKv8fvDot
	 9YGYpXpmBGQNu5T2hQIPiBckh39Inyqh1QkavjJltcnt94ftqDPYuFylRZXGGaD/n1
	 XQmnL4aN31lww==
Date: Mon, 17 Aug 2026 09:30:21 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 3/4] stubdom: remove build of zlib
Message-ID: <aoK4jSY6RUOXrZbl@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-4-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260817071843.114898-4-jgross@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-d62444/1786951822-BDE78757-2C62515B/0/0
X-purgate-type: clean
X-purgate-size: 4949

Juergen Gross, le lun. 17 août 2026 09:18:42 +0200, a ecrit:
> The last users of zlib for stubdoms have been removed.
> 
> Remove zlib from the stubdom build system, too.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> ---
>  config/Stubdom.mk.in |  3 ---
>  stubdom/.gitignore   |  1 -
>  stubdom/Makefile     | 24 +-----------------------
>  stubdom/configure    | 15 ---------------
>  stubdom/configure.ac |  1 -
>  5 files changed, 1 insertion(+), 43 deletions(-)
> 
> diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in
> index b90eaee75a..dc0a3b54b3 100644
> --- a/config/Stubdom.mk.in
> +++ b/config/Stubdom.mk.in
> @@ -11,9 +11,6 @@ STUBDOM_TARGETS     := @STUBDOM_TARGETS@
>  STUBDOM_BUILD       := @STUBDOM_BUILD@
>  STUBDOM_INSTALL     := @STUBDOM_INSTALL@
>  
> -ZLIB_VERSION        := @ZLIB_VERSION@
> -ZLIB_URL            := @ZLIB_URL@
> -
>  NEWLIB_VERSION      := @NEWLIB_VERSION@
>  NEWLIB_URL          := @NEWLIB_URL@
>  
> diff --git a/stubdom/.gitignore b/stubdom/.gitignore
> index 8c6dc00f83..e5d5744361 100644
> --- a/stubdom/.gitignore
> +++ b/stubdom/.gitignore
> @@ -29,4 +29,3 @@
>  /vtpm/vtpm_manager.h
>  /xenstore
>  /xenstorepvh
> -/zlib-*
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index f542a4295a..8830deebce 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -102,26 +102,6 @@ $(NEWLIB_STAMPFILE): mk-headers-$(XEN_TARGET_ARCH) newlib-$(NEWLIB_VERSION)
>  	  $(MAKE) DESTDIR= && \
>  	  $(MAKE) DESTDIR= install )
>  
> -############
> -# Cross-zlib
> -############
> -
> -zlib-$(ZLIB_VERSION).tar.gz:
> -	$(FETCHER) $@ $(ZLIB_URL)/$@
> -
> -zlib-$(XEN_TARGET_ARCH): zlib-$(ZLIB_VERSION).tar.gz 
> -	tar xzf $<
> -	mv zlib-$(ZLIB_VERSION) $@
> -
> -ZLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libz.a
> -.PHONY: cross-zlib
> -cross-zlib: $(ZLIB_STAMPFILE)
> -$(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE)
> -	( cd $< && \
> -	  CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf && \
> -	  $(MAKE) DESTDIR= libz.a && \
> -	  $(MAKE) DESTDIR= install )
> -
>  ######
>  # lwIP
>  ######
> @@ -222,7 +202,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE)
>  #######
>  
>  .PHONY: $(CROSS_ROOT)
> -$(CROSS_ROOT): cross-newlib cross-zlib
> +$(CROSS_ROOT): cross-newlib
>  
>  #######
>  # libraries under tools/libs
> @@ -449,7 +429,6 @@ clean:
>  crossclean: clean
>  	rm -fr $(CROSS_ROOT)
>  	rm -fr newlib-$(XEN_TARGET_ARCH)
> -	rm -fr zlib-$(XEN_TARGET_ARCH)
>  	rm -fr libs-$(XEN_TARGET_ARCH)
>  	rm -fr xenstore xenstorepvh
>  	rm -fr gmp-$(XEN_TARGET_ARCH)
> @@ -471,7 +450,6 @@ patchclean: crossclean
>  .PHONY: downloadclean
>  downloadclean: patchclean
>  	rm -f newlib-$(NEWLIB_VERSION).tar.gz
> -	rm -f zlib-$(ZLIB_VERSION).tar.gz
>  	rm -f gmp-$(GMP_VERSION).tar.bz2
>  	rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz
>  	rm -f lwip-$(LWIP_VERSION).tar.gz
> diff --git a/stubdom/configure b/stubdom/configure
> index f3d63dceff..1a5687d32b 100755
> --- a/stubdom/configure
> +++ b/stubdom/configure
> @@ -634,8 +634,6 @@ LWIP_VERSION
>  LWIP_URL
>  NEWLIB_VERSION
>  NEWLIB_URL
> -ZLIB_VERSION
> -ZLIB_URL
>  INSTALL_DATA
>  INSTALL_SCRIPT
>  INSTALL_PROGRAM
> @@ -722,7 +720,6 @@ CFLAGS
>  LDFLAGS
>  LIBS
>  CPPFLAGS
> -ZLIB_URL
>  NEWLIB_URL
>  LWIP_URL
>  GMP_URL
> @@ -1372,7 +1369,6 @@ Some influential environment variables:
>    LIBS        libraries to pass to the linker, e.g. -l<library>
>    CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
>                you have headers in a nonstandard directory <include dir>
> -  ZLIB_URL    Download url for zlib
>    NEWLIB_URL  Download url for newlib
>    LWIP_URL    Download url for lwip
>    GMP_URL     Download url for libgmp
> @@ -4023,17 +4019,6 @@ fi
>  # Stubdom libraries version and url setup
>  
>  
> -if test "x$ZLIB_URL" = "x"
> -then :
> -
> -	ZLIB_URL=\$\(XEN_EXTFILES_URL\)
> -fi
> -ZLIB_VERSION="1.2.3"
> -
> -
> -
> -
> -
>  if test "x$NEWLIB_URL" = "x"
>  then :
>  
> diff --git a/stubdom/configure.ac b/stubdom/configure.ac
> index d3d2a840d3..34a47c95e1 100644
> --- a/stubdom/configure.ac
> +++ b/stubdom/configure.ac
> @@ -38,7 +38,6 @@ AC_PROG_INSTALL
>  AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake])
>  
>  # Stubdom libraries version and url setup
> -AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3])
>  AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib])
>  AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip])
>  AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive])
> -- 
> 2.55.0
> 

-- 
Samuel
Accroche-toi au terminal, j'enlève le shell...
 -+- nojhan -+-


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392545.1631506 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvs5A-0003KP-Ro; Mon, 17 Aug 2026 07:48:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392545.1631506; Mon, 17 Aug 2026 07:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvs5A-0003KI-NK; Mon, 17 Aug 2026 07:48:32 +0000
Received: by outflank-mailman (input) for mailman id 1392545;
 Mon, 17 Aug 2026 07:48:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wvs59-0003KC-OI
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:48:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvs58-002elg-MR
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:48:30 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a82bcc2-2eae-0a2a0a5409dd-0a2a4503b280-42
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:48:30 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a82bcce-fae8-0a2a45030019-8c4da68a8642-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:48:30 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id 1AF63A1A90;
 Mon, 17 Aug 2026 09:48:30 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7CuBQUkflgoT; Mon, 17 Aug 2026 09:48:30 +0200 (CEST)
Received: from end (lfbn-orl-1-1611-126.w90-107.abo.wanadoo.fr
 [90.107.165.126])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id D9935A017F;
 Mon, 17 Aug 2026 09:48:29 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wvs57-0000000BsRc-1soM; Mon, 17 Aug 2026 09:48:29 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786952910; bh=0ByJzqXOBXfucz5dqyG4+tO5WyPtI4O40so7/UY9C3U=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=WyfaWnBMShoIH6RYxw7YPAb02UffqTe7/H/hDV7C7utkws/CqAwg6MHPKHVPn1dB3
	 tYh+3yES8ca2IjAkg+KoAhamOr5zfunIJJYLCmBmulVQO8LyeppUj6TPxLlQClBCOi
	 95U5c/jCDedrfUxMqAfeRvvJ7jYtuMZuRZizkE5Kl9Phd52sR3KgJ9y7kTvmBxMVQ5
	 aF4qyO8p9olN16VxyojJWV4L7sa/SaBD4IUCnuMPQ0tYpyhjYZQZh/cLi6b0VyIhJY
	 WzFIvRNJm/tLijSs+yRjAlrcACZslPGs4aHnlQoOldb3kNRwVUGc0NvENyz6/OPha/
	 Cz3JueWT0W5VQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786952909; bh=0ByJzqXOBXfucz5dqyG4+tO5WyPtI4O40so7/UY9C3U=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=n+0Kiq1uX5a7bHAiXatbWjvmXjlBkICXvdc3O20kVY70T2205OeR5wCF270mN384F
	 Ie72yW4W3on9AwPsVc1q18kAvksi4dXf2rUmTwEkTdM33ezNfhpFGpze/PKhnCVzM0
	 7pULO6lhLGSVIGs7cgIe3+yVDtLJulrOGtCLyAxcc+3AlOdsGcyy6yAIawziNTZVH8
	 pC/Hc9goxQ/C6R745LOMZzGrMnKBmGJ3nifrr9KNSefyVs0MLZhMRMbvExLeEI9LYp
	 rzMqfeEXEMS9T1lbVRz2gmJUEwol5hYzyImgC96IoLltEeTDD7umpj0jCcxxvEBav2
	 haP8IEz7S3zzA==
Date: Mon, 17 Aug 2026 09:48:29 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
Message-ID: <aoK8zVAP0C0ksD_0@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260817071843.114898-3-jgross@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-33051d/1786952910-6E2D04E9-BF884B23/0/0
X-purgate-type: clean
X-purgate-size: 8752

Hello,

Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
> There is no user of libpci left in stubdoms.
> 
> Remove libpci from the stubdom build system.

Wouldn't it be useful to keep this for anybody who would want to drive a
PCI card from a stubdomain?

I mean, in the zlib case, it's really a mere question of build & link,
so we don't need to ship it, people can do it themselves easily like for
any other library.

But here there is actual porting work, that we'd better not lose but
keep shipping.

Samuel

> ---- pciutils-2.2.9.orig/lib/minios.c	1970-01-01 01:00:00.000000000 +0100
> -+++ pciutils-2.2.9/lib/minios.c	2008-07-01 12:31:40.554260000 +0100

> -@@ -0,0 +1,106 @@
> -+/*
> -+ *	The PCI Library -- MiniOS PCI frontend access
> -+ *
> -+ *	Samuel Thibault <samuel.thibault@eu.citrix.com>, 2008
> -+ *
> -+ *	Can be freely distributed and used under the terms of the GNU GPL.
> -+ */
> -+
> -+#include <os.h>
> -+#include <pcifront.h>
> -+#include <xenbus.h>
> -+#include "internal.h"
> -+
> -+static int
> -+minios_detect(struct pci_access *a)
> -+{
> -+  return 1;
> -+}
> -+
> -+static void
> -+minios_init(struct pci_access *a)
> -+{
> -+}
> -+
> -+static void
> -+minios_cleanup(struct pci_access *a)
> -+{
> -+  shutdown_pcifront(NULL);
> -+}
> -+
> -+static void
> -+minios_scan(struct pci_access *a)
> -+{
> -+  void func(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
> -+  {
> -+    struct pci_dev *d = pci_alloc_dev(a);
> -+
> -+    d->domain = domain;
> -+    d->bus = bus;
> -+    d->dev = slot;
> -+    d->func = fun;
> -+
> -+    pci_link_dev(a, d);
> -+  }
> -+
> -+  pcifront_scan(NULL, func);
> -+}
> -+
> -+static int
> -+minios_read(struct pci_dev *d, int pos, byte *buf, int len)
> -+{
> -+  unsigned int val;
> -+  switch (len) {
> -+    case 1:
> -+      if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val))
> -+        return 0;
> -+      * buf = val;
> -+      return 1;
> -+    case 2:
> -+      if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val))
> -+        return 0;
> -+      *(u16 *) buf = cpu_to_le16((u16) val);
> -+      return 1;
> -+    case 4:
> -+      if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val))
> -+        return 0;
> -+      *(u32 *) buf = cpu_to_le32((u32) val);
> -+      return 1;
> -+    default:
> -+      return pci_generic_block_read(d, pos, buf, len);
> -+  }
> -+}
> -+
> -+static int
> -+minios_write(struct pci_dev *d, int pos, byte *buf, int len)
> -+{
> -+  unsigned int val;
> -+  switch (len) {
> -+    case 1:
> -+      val = * buf;
> -+      break;
> -+    case 2:
> -+      val = le16_to_cpu(*(u16 *) buf);
> -+      break;
> -+    case 4:
> -+      val = le32_to_cpu(*(u32 *) buf);
> -+      break;
> -+    default:
> -+      return pci_generic_block_write(d, pos, buf, len);
> -+  }
> -+  return !pcifront_conf_write(NULL, d->domain, d->bus, d->dev, d->func, pos, len, val);
> -+}
> -+
> -+struct pci_methods pm_minios = {
> -+  "MiniOS-device",
> -+  NULL,                                 /* config */
> -+  minios_detect,
> -+  minios_init,
> -+  minios_cleanup,
> -+  minios_scan,
> -+  pci_generic_fill_info,
> -+  minios_read,
> -+  minios_write,
> -+  NULL,                                 /* dev_init */
> -+  NULL                                  /* dev_cleanup */
> -+};
> ---- pciutils-2.2.9/lib/generic.c	2007-02-06 12:00:05.000000000 +0000
> -+++ pciutils-2.2.9-mine/lib/generic.c	2008-07-01 19:13:52.289949000 +0100
> -@@ -74,6 +74,19 @@
> -   pci_generic_scan_bus(a, busmap, 0);
> - }
> - 
> -+static u32 pci_size(u32 base, u32 maxbase, u32 mask)
> -+{
> -+  u32 size = mask & maxbase;
> -+  if (!size)
> -+    return 0;
> -+  size = (size & ~(size-1)) - 1;
> -+
> -+  if (base == maxbase && ((base | size) & mask) != mask)
> -+    return 0;
> -+
> -+  return size + 1;
> -+}
> -+
> - int
> - pci_generic_fill_info(struct pci_dev *d, int flags)
> - {
> -@@ -114,23 +127,61 @@
> - 	      if (!x || x == (u32) ~0)
> - 		continue;
> - 	      if ((x & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO)
> --		d->base_addr[i] = x;
> --	      else
> -+                {
> -+                  d->base_addr[i] = x & PCI_BASE_ADDRESS_IO_MASK;
> -+                  if (flags & PCI_FILL_SIZES)
> -+                    {
> -+                      u32 size;
> -+                      pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0);
> -+                      d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_IO_MASK);
> -+                      pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x);
> -+                    }
> -+                }
> -+              else
> - 		{
> - 		  if ((x & PCI_BASE_ADDRESS_MEM_TYPE_MASK) != PCI_BASE_ADDRESS_MEM_TYPE_64)
> --		    d->base_addr[i] = x;
> -+                    {
> -+                      d->base_addr[i] = x & PCI_BASE_ADDRESS_MEM_MASK;
> -+                      if (flags & PCI_FILL_SIZES)
> -+                        {
> -+                          u32 size;
> -+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0);
> -+                          d->size[i] = pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4);
> -+                          d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_MEM_MASK);
> -+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x);
> -+                        }
> -+                    }
> - 		  else if (i >= cnt-1)
> - 		    a->warning("%04x:%02x:%02x.%d: Invalid 64-bit address seen for BAR %d.", d->domain, d->bus, d->dev, d->func, i);
> - 		  else
> - 		    {
> - 		      u32 y = pci_read_long(d, PCI_BASE_ADDRESS_0 + (++i)*4);
> - #ifdef PCI_HAVE_64BIT_ADDRESS
> --		      d->base_addr[i-1] = x | (((pciaddr_t) y) << 32);
> -+		      d->base_addr[i-1] = (x | (((pciaddr_t) y) << 32)) & PCI_BASE_ADDRESS_MEM_MASK;
> -+                      if (flags & PCI_FILL_SIZES)
> -+                        {
> -+                          u32 size;
> -+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0);
> -+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0);
> -+                          d->size[i-1] = pci_size(y, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4) | 
> -+                                         pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), 0xffffffff );
> -+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x);
> -+                          pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, y);
> -+                        }
> - #else
> - 		      if (y)
> - 			a->warning("%04x:%02x:%02x.%d 64-bit device address ignored.", d->domain, d->bus, d->dev, d->func);
> - 		      else
> --			d->base_addr[i-1] = x;
> -+                        {
> -+                          d->base_addr[i-1] = x & PCI_BASE_ADDRESS_MEM_MASK;
> -+                          if (flags & PCI_FILL_SIZES)
> -+                            {
> -+                              u32 size;
> -+                              pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0);
> -+                              d->size[i-1] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4), PCI_BASE_ADDRESS_MEM_MASK);
> -+                              pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x);
> -+                            }
> -+                        }
> - #endif
> - 		    }
> - 		}
> -@@ -154,10 +205,19 @@
> - 	{
> - 	  u32 u = pci_read_long(d, reg);
> - 	  if (u != 0xffffffff)
> --	    d->rom_base_addr = u;
> -+            {
> -+              d->rom_base_addr = u;
> -+              if (flags & PCI_FILL_SIZES)
> -+                {
> -+                  u32 size;
> -+                  pci_write_long(d, reg, ~0);
> -+                  d->rom_size = pci_read_long(d, reg);
> -+                  pci_write_long(d, reg, u);
> -+                }
> -+            }
> - 	}
> -     }
> --  return flags & ~PCI_FILL_SIZES;
> -+  return flags;
> - }
> - 
> - static int
> -diff -uNpbE -uNpbEr pciutils-2.2.9.orig/lib/sysdep.h pciutils-2.2.9/lib/sysdep.h
> ---- pciutils-2.2.9.orig/lib/sysdep.h	2007-02-06 12:00:18.000000000 +0000
> -+++ pciutils-2.2.9/lib/sysdep.h	2009-07-22 16:26:30.000000000 +0100
> -@@ -32,6 +32,10 @@ typedef u16 word;
> - 
> - #else
> - 
> -+#ifdef PCI_OS_MINIOS
> -+#include <machine/endian.h>
> -+#endif
> -+
> - #ifdef PCI_OS_LINUX
> - #include <endian.h>
> - #define BYTE_ORDER __BYTE_ORDER
> -- 
> 2.55.0


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 07:56:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 07:56:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392552.1631514 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsCT-0004tb-Gb; Mon, 17 Aug 2026 07:56:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392552.1631514; Mon, 17 Aug 2026 07:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsCT-0004tU-Dr; Mon, 17 Aug 2026 07:56:05 +0000
Received: by outflank-mailman (input) for mailman id 1392552;
 Mon, 17 Aug 2026 07:56:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvsCR-0004tJ-JE
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 07:56:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvsCQ-007gmq-DJ
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:56:02 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82be81-e002-0a2a0a5209dd-0a2a4507af8e-48
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:56:02 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82be92-b4ea-0a2a45070019-d155dd35f16d-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:56:02 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47f7872abb6so1683202f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 00:56:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b51asm1816281f8f.11.2026.08.17.00.56.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 00:56:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786953362; x=1787558162; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=sFCUkMv3GpQ40PwNsMuGVFNvWtlkQzWO5EkN+a9wFOQ=;
        b=Wv+MVVJ5RCkrY2N4humStusJh3VvX85uuLxGGPogvFz9bzYnatM7iPXUzaIHk18IBA
         LM9/ZF3/pi+FoRCpPftwRbP/uGMtbnL0NKfysdb65rMm1/wtoCW0gk/amtTryZ0TC3Q3
         4FIzN81Uger6XRgfNVuch5E+axs58QqYs0zU64lWJ36QQcGn1pYGzNQjKRUC6mSzWaKJ
         r+cqkWLE3AoNHAta+hMj/lrwy2TG/aTpelxGQaPbU/213/jP69XQyUIu9bD/Ek1ENCxM
         pUpHB9njaAXSiqmUWOIg/RyEJ5xI3wHBpvwoLv2COTgcMp0M5Cb/gveApEAQfOyquuV7
         6lXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786953362; x=1787558162;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=sFCUkMv3GpQ40PwNsMuGVFNvWtlkQzWO5EkN+a9wFOQ=;
        b=dIBrjZN9Gfjhbq8dSSHWbt7ObbAgFlK0scZYnLHsE5qfdYVCgyBBfATaPOH5o3oLL5
         W2uXSxE7Ef5OF+8tHLL1MWpEPsMdrzCsFXbGp66RM+ApphWGuP/7/GZoOvwiSHRiN0pR
         eiiyZYQlnUHPX8untZi4TO+UH2riM6zlQxAw1B4M2V3ZARr50fdCL1Jhl6MA1Q0NWiS1
         GfgEsd+crTvVC1EKJfg6hgp48AR1YMAfKo90qTnojK4mYlRhGsT77BU0Lt3D4g+B2ETG
         NYWYsIRB+69Qat6vfbVyrqU+QZgiUVeIKCGoi0iIegSp6IHx20pK8IMkQRCc9+XQPfeB
         jTqA==
X-Forwarded-Encrypted: i=1; AHgh+RopiTAOyPHCU8oin1ua0nloZv62BEFQk26+nu7meXXVAUMe8qS63ub6cA6he7RHt5BVfE/rzjyncX0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdR+4mxAw8W335iXeHBQBbAe9u2ZikYOug8aeufsO6/NMtJDf/
	46w73ywKxB7viZODMRCGLCrDwJUcVT9fwKA35QYoVHtycFEpAPUI8blaEKjDnmN02Q==
X-Gm-Gg: AR+sD12oSVqLfN9rBPlwmTadOMJXFJIyUak7ViasNeqaZC5Vs0aq2nIT075JpEqQadF
	zLAUFuzMpm0uJ075A8EbTXUkDIICOoulKPdNweLLtD5LQYmzfUfs0E65V8K4bs1aDgC5oDHkTnD
	0QDYM8azxXaQASCD88kX0K3ZFdbsiXkzFU6u68qi1iF1jfqwo+EtUobOMpLVeQBrPNsYhsbyJFS
	e5idyliUhGyfa+Ru7rCe8Ha2LZErVLfbVz0KWe5NCKTj03oACDX8pnxgOX2Rrr5YEKqSxrRsCUy
	1jE2Rn1tJmD8zLmsZaV2LBgK/DQ7pbHnD5czK8ILDv5d7DQV/ZxbyjfXrpDFVcK5VjMud8dkLrJ
	L1mcExKSEk4U6DYHlt5tlD8ZYpCVTkzcZArs5wdBhw1CIvZzXYShtYxlVn6RtE2gbJSrMxA7cX+
	6XID9o0j83AaXCHfZ/MEoqHay8NgxAsz5FMYjJgsdaiVnbevr5MfreX0fby0obABBJmL00/gRlO
	4pnnfo88OiVpVFYZY9PfxEBKrGk3s92D1ZFSbpTFwqqCDaxhV63
X-Received: by 2002:a05:6000:401e:b0:47f:34ba:2d0d with SMTP id ffacd0b85a97d-48160705173mr32034788f8f.8.1786953361727;
        Mon, 17 Aug 2026 00:56:01 -0700 (PDT)
Message-ID: <aab2b1da-afc0-45fc-bffd-769993e6808e@suse.com>
Date: Mon, 17 Aug 2026 09:56:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] Config: update Mini-OS commit id
To: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-2-jgross@suse.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260817071843.114898-2-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1786953362-A46CAAE4-87FD5C9D/0/0
X-purgate-type: clean
X-purgate-size: 171

On 17.08.2026 09:18, Juergen Gross wrote:
> Use the newest Mini-OS.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:04:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:04:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392572.1631523 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsKR-0007Gx-Qf; Mon, 17 Aug 2026 08:04:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392572.1631523; Mon, 17 Aug 2026 08:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsKR-0007Gq-NL; Mon, 17 Aug 2026 08:04:19 +0000
Received: by outflank-mailman (input) for mailman id 1392572;
 Mon, 17 Aug 2026 08:04:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvsKQ-0007Gk-0I
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:04:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvsKO-00B0S6-Ut
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:04:16 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82c07e-e002-0a2a0a5209dd-0a2a4501e0cc-10
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:04:16 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82c080-5984-0a2a45010019-d1558035e911-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:04:16 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-499840a2575so22781665e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:04:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4998777a4bdsm194504845e9.0.2026.08.17.01.04.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:04:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786953856; x=1787558656; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ZwA+s9SCvQuxMCv5Ld0oS/Efv+CDqAxMJOLLQr5GkoE=;
        b=cwLn2t5Cn9VZGJTZ+2TzKnea00elVqPGPSdihcUmgcfDEeb6cZ8qlzJ2Vd/BB6297s
         sJFC7dj7f/Qtf6uOOyLm3Eo8XklSLwHprSLjXNZAi89VraRpBBJ5hOCzkymIt38hSjYL
         pRhIeEMe2vNVHE0sEsConDocx5wiOXkAnRVzj+doZcqbCY3G/UjsLSdUONwLVgZdUgJs
         uiQpXJnF+5nKS7qvbiT0crpXRsSjR3K3J5WsGkijqRssf5VwkNXLVOg88EFp4RvTbhHc
         nBLMB8M8LBO0hA6T4SD486AQmVCG6IV+hXYRwGEJ7rUkE6aZbWZIc4lTRvCiHz0g+BB8
         8bVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786953856; x=1787558656;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ZwA+s9SCvQuxMCv5Ld0oS/Efv+CDqAxMJOLLQr5GkoE=;
        b=S1ZqYjmb9QENCDOqid7XEGUo4IV1YXYPxOhKoXcNOi0XgVgYx0KUVAtVKsASf0mxKr
         4A9sD1bWkmkhB8RSLqiZoSoMi4pvgApUiLNFceYrbomc6SulKnyRWFs3A+ZlI+uvNqwc
         yljkfwp5CQnUHrdJEyy4KzJf/Y2dnf/Uzq+RVRoEk/VVWPJlouOkGk+qoIXiwKPjxgnG
         hM9evRoMXo8XXEtI6D1uM1PONZaT6jFXSAupN43yiJxVSBfM2Rg6zuVmmVjS7tJz2KXc
         8LI+9YTmbJm5rH4XAWrZR/4kn9u5T7oXbSXXJU2aeo4ZP4bbe7LhivpYuR6ULSiUDjRS
         eQkQ==
X-Forwarded-Encrypted: i=1; AHgh+Ro5cDgu6OXSBJst3suUlnezNfU7engu8QIqRN7b48OWkUwe8zWIFZ2zZiLZk7oekL149wP8+y77gIc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywmgs4b0p/IgM2pRvb7G6iceuG8hjuO88qijTO+5aLwuaUUGDHJ
	/8eu37gCUolDx07WS65A9gj8EhOaDOWaPSFxEO9XY6cujOA6pTlHo1mduKoy734HYg==
X-Gm-Gg: AR+sD11NVo0oKjHefKrvqBCx/MFlsp66zHgKgUzyhpHDHblKDzPpOkXfj3iIz3ZBZJy
	AimKTHieeqFGRzGre7KXlmT7QMeNYxXqB0eXGO5Brpxe1huafciDNl4BaNw4mzDRdqJ45LdUngp
	0wK7+jedIDTxsAIRfscAEf3QkM/FoRWI9xabV2tC1ZS750oVWNkn/MacCyz3/5PoH/xyQUi+vSO
	ixo3OPaSrZzh+vJXamF2LVSV6uj2NnwZ3cDosf9GlFkhT8YMWgyHI679hvASIDpNG+Y0WPBlgpr
	RanonG5sz//GCu+QJwzDn7OqvOkqD72WAyi9rwihW7dGp14CeDsrFJ0eGbigDWthvRNOo1oOEBD
	Xglov/kdxPY4LJPwrR9yneh4bFBH2iKeY6eYC6OQ9nhhXuySc8YyO8ZdUzJxkc5LBJAIBklM7ME
	m1BJLPsYMgiVMZxU8xpn3MdpGz1/P4ijzibyEkS3nqIwBZFlxsigWRF/Uk+5Rfm72QnbHmEB4tt
	Wsgk84d/mAMV4lTY1my90kUnue4dPukbNYkIn2JzoLD5lHIapZPAU/ZUCpGpWAX+VvobX5pM2s=
X-Received: by 2002:a05:600c:4e04:b0:499:9069:c2c9 with SMTP id 5b1f17b1804b1-4999069cf2bmr290885915e9.11.1786953856189;
        Mon, 17 Aug 2026 01:04:16 -0700 (PDT)
Message-ID: <e697b132-8c6a-411b-b91d-2fedba02a9ae@suse.com>
Date: Mon, 17 Aug 2026 10:04:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Frediano Ziglio <freddy77@gmail.com>
Cc: "Daniel P . Smith" <dpsmith@apertussolutions.com>,
 Frediano Ziglio <frediano.ziglio@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>, Juergen Gross <jgross@suse.com>,
 xen-devel@lists.xenproject.org
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com>
 <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
 <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
 <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com>
 <CAHt6W4dWQvSg1_XtkKowTcznUWs=-ApbvatV4YrQSKR8zJTA0A@mail.gmail.com>
 <e3d4f0a8-e95a-4dc3-8ca0-df857725d60d@suse.com>
 <CAHt6W4ftLMsk41zdwYUXEwN_JzzXHQG01vhSqutkgk8PO6xAQw@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAHt6W4ftLMsk41zdwYUXEwN_JzzXHQG01vhSqutkgk8PO6xAQw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786953856-1D87F757-F9A4BB25/0/0
X-purgate-type: clean
X-purgate-size: 2858

On 14.08.2026 16:50, Frediano Ziglio wrote:
> On Fri, 14 Aug 2026 at 15:13, Jan Beulich <jbeulich@suse.com> wrote:
>> On 14.08.2026 15:47, Frediano Ziglio wrote:
>>> On Thu, 13 Aug 2026 at 15:22, Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 13.08.2026 16:03, Frediano Ziglio wrote:
>>>>> On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>> On 10.08.2026 12:30, Frediano Ziglio wrote:
>>>>>>> --- a/xen/common/memory.c
>>>>>>> +++ b/xen/common/memory.c
>>>>>>> @@ -1548,6 +1548,141 @@ static int acquire_resource(
>>>>>>>      return rc;
>>>>>>>  }
>>>>>>>
>>>>>>> +/*
>>>>>>> + * The "noinline" qualifier avoids the compiler to create a large function
>>>>>>> + * consuming quite a lot of stack.
>>>>>>> + */
>>>>>>> +static int noinline mem_foreigncopy(
>>>>>>
>>>>>> I'm wondering: Is the "mem" prefix really meaningful for a static function in
>>>>>> a file named memory.c?
>>>>>>
>>>>>
>>>>> Changed
>>>>>
>>>>>>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
>>>>>>> +{
>>>>>>> +    struct domain *d, *const currd = current->domain;
>>>>>>
>>>>>> With the comment on the new XSM hooks (below) in mind: currd wants to be
>>>>>> pointer-to-const.
>>>>>>
>>>>>
>>>>> Just rebased on master, all XSM hooks accept no-const pointers to domains.
>>>>> So the suggested change would create warnings.
>>>>
>>>> Well, as per below, I pointed you at a particular pending patch, a single
>>>> hunk of which could be broken out.
>>>
>>> Yes, but my changes would have to have casts from const pointers to
>>> no-const pointers to avoid warnings and the patch you are pointing to
>>> would have to remove these casts. I find this less clean than having
>>> one patch using the current code style (that is no-const pointers) and
>>> another that changes the style entirely.
>>> But obviously this is just my opinion.
>>
>> Such casts would be unacceptable. What instead I have been trying to convey:
>> Your patch wants to gain a dependency on my patch. And if my patch would
>> take too long to make it in, that one hunk could be broken out into a
>> separate, easy to get in patch.
> 
> Okay, then the only choice that's left is the code producing warnings
> as const pointers are passed to functions requiring no-const pointers.
> Is this acceptable? Apparently as you are suggesting it it is.

That's not acceptable, the more that due to -Werror this would break the
build. But that's also not what I said, and I'm having a hard time seeing
how what I said can be mis-interpreted. What exactly is not clear in "Your
patch wants to gain a dependency on my patch"?

Btw, I'm about to submit v2 of that XSM series, where I've broken out that
hunk (for the change to then hopefully go in quickly, allowing you to
simply re-base rather than carrying a prereq patch).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:24:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:24:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392582.1631540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsdi-0002Cj-DJ; Mon, 17 Aug 2026 08:24:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392582.1631540; Mon, 17 Aug 2026 08:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsdi-0002Cc-AI; Mon, 17 Aug 2026 08:24:14 +0000
Received: by outflank-mailman (input) for mailman id 1392582;
 Mon, 17 Aug 2026 08:24:12 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wvsdg-0002CU-R1
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:24:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvsdf-00Cwvp-PO
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:24:11 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a82c521-bab6-0a2a0a5309dd-0a2a450488d2-38
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:24:11 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a82c52b-b57f-0a2a45040019-c387df82a062-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:24:11 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id E898783ED9;
 Mon, 17 Aug 2026 08:24:02 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C43247937E;
 Mon, 17 Aug 2026 08:24:02 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ZY3hLSLFgmqhfQAAD6G6ig
 (envelope-from <jgross@suse.com>); Mon, 17 Aug 2026 08:24:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786955047; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=ZMNR1wQu/pT8RiZlwkIHqExelD3Hr7Xlt5SbMFVCQuw=;
	b=Wcq0RVfPrd18khRBWz17lGs8Eh4kfSkhUGa7s0T13hlqTgUe2irIqqWIw+Rdtwc4tlK3hV
	QGotgvuSARy0D/EUF6QPgWhQSUiayKign0h7drdGaAHIiMgeJZEIja7dpuW4IqIe7Sw0LQ
	BlxlD8DUJMsCgqBg9mVhOfYfUDSGJaY=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1786955042; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=ZMNR1wQu/pT8RiZlwkIHqExelD3Hr7Xlt5SbMFVCQuw=;
	b=quhQAu0VXnG1LrG/WBBCOnPLQd9wF+23VjXR16ljZbpCr/dDSDFDrdZoiKZ+OgtkT5rhFE
	q8WvAHvVCa0+Dy9NHKSpPPxeRZaj7n63zTsXpO2EYKgSxtR/bjHi1jlBJ3COfdRqjELYKo
	wUeX2Qe7U+KdMTRJe8l1wnIuUDe/G54=
Message-ID: <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
Date: Mon, 17 Aug 2026 10:24:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <aoK8zVAP0C0ksD_0@end>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------bW3o9ct3mqyTP1DnzqyCOLYY"
X-Spam-Score: -6.00
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-6.00 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-0.86)[-0.862];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.14)[-0.681];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]
X-purgate-ID: tlsNG-ebf023/1786955051-C38C1B50-CA0D3480/0/0
X-purgate-type: clean
X-purgate-size: 6784

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------bW3o9ct3mqyTP1DnzqyCOLYY
Content-Type: multipart/mixed; boundary="------------B50nzAZWygYP0uudQ00wfzvU";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
Message-ID: <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
In-Reply-To: <aoK8zVAP0C0ksD_0@end>

--------------B50nzAZWygYP0uudQ00wfzvU
Content-Type: multipart/mixed; boundary="------------gCcXk55xLaNt0GVNKAA9cDMc"

--------------gCcXk55xLaNt0GVNKAA9cDMc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTcuMDguMjYgMDk6NDgsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4gSGVsbG8sDQo+
IA0KPiBKdWVyZ2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIwMjYgMDk6MTg6NDEgKzAy
MDAsIGEgZWNyaXQ6DQo+PiBUaGVyZSBpcyBubyB1c2VyIG9mIGxpYnBjaSBsZWZ0IGluIHN0
dWJkb21zLg0KPj4NCj4+IFJlbW92ZSBsaWJwY2kgZnJvbSB0aGUgc3R1YmRvbSBidWlsZCBz
eXN0ZW0uDQo+IA0KPiBXb3VsZG4ndCBpdCBiZSB1c2VmdWwgdG8ga2VlcCB0aGlzIGZvciBh
bnlib2R5IHdobyB3b3VsZCB3YW50IHRvIGRyaXZlIGENCj4gUENJIGNhcmQgZnJvbSBhIHN0
dWJkb21haW4/DQo+IA0KPiBJIG1lYW4sIGluIHRoZSB6bGliIGNhc2UsIGl0J3MgcmVhbGx5
IGEgbWVyZSBxdWVzdGlvbiBvZiBidWlsZCAmIGxpbmssDQo+IHNvIHdlIGRvbid0IG5lZWQg
dG8gc2hpcCBpdCwgcGVvcGxlIGNhbiBkbyBpdCB0aGVtc2VsdmVzIGVhc2lseSBsaWtlIGZv
cg0KPiBhbnkgb3RoZXIgbGlicmFyeS4NCj4gDQo+IEJ1dCBoZXJlIHRoZXJlIGlzIGFjdHVh
bCBwb3J0aW5nIHdvcmssIHRoYXQgd2UnZCBiZXR0ZXIgbm90IGxvc2UgYnV0DQo+IGtlZXAg
c2hpcHBpbmcuDQoNClRoaXMgaXMgYWxsIHN0aWxsIGF2YWlsYWJsZSB2aWEgZ2l0Lg0KDQpJ
J20gbm90IGluIGZhdm9yIGtlZXBpbmcgdW51c2VkIGNvZGUgaW4gb3VyIG1hc3RlciBicmFu
Y2guDQoNCg0KSnVlcmdlbg0K
--------------gCcXk55xLaNt0GVNKAA9cDMc
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------gCcXk55xLaNt0GVNKAA9cDMc--

--------------B50nzAZWygYP0uudQ00wfzvU--

--------------bW3o9ct3mqyTP1DnzqyCOLYY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqCxSIFAwAAAAAACgkQsN6d1ii/Ey86
ygf+KFV39dG1Jc4RBTUI08EKUAmV1PhwZe/2A0RrIRDpJa2MXVR+NL/yLV+wMUJZ0xpjvOldm4n0
ZmFRZ2zNhfwfbZwWsQwW9b72s3PMkTFpUjMsmWbrs+fIyks3K5wOpsb9XiZPD+YYkqhWEgUPgUvB
NaVDQVqT6CvPXXlrkX4j95rd67RMrlylPl3kAfAQTEzgFAf8inKGOUVAyS6Dn74tjVAZvZTLCJ2D
P/LZWOzN6A3TEII1h8IhsivomfoiSGV5GMc8+X79j9mJJTVvaV6jwyLpYPygDC2/NeeXlxE5zEhc
X2ONe8zdflCL+cBPeOpsyLvsFL7hnxiy7pdfAONPlg==
=aZqg
-----END PGP SIGNATURE-----

--------------bW3o9ct3mqyTP1DnzqyCOLYY--


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:30:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:30:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392589.1631548 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsjV-0003t3-Vz; Mon, 17 Aug 2026 08:30:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392589.1631548; Mon, 17 Aug 2026 08:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsjV-0003sw-TQ; Mon, 17 Aug 2026 08:30:13 +0000
Received: by outflank-mailman (input) for mailman id 1392589;
 Mon, 17 Aug 2026 08:30:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvsjU-0003sq-Cp
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:30:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvsjT-00B6Bw-Kk
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:30:11 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82c68c-e002-0a2a0a5209dd-0a2a45039626-36
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:30:11 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82c693-fae8-0a2a45030019-d155dd35e4c1-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:30:11 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47f703a9d05so2026001f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:30:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b572sm2042703f8f.13.2026.08.17.01.30.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:30:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786955411; x=1787560211; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LH92ElShDin2r1KuNlfB+hn91KLMq+rpk5+sB/ghXic=;
        b=Tnz2wxXPzQhLIYNfY/0i9uVb99HmUK9sy3MquQwz6bPH8ZYjY6MOioH4dlPJ1HT1Sv
         MtiuoeQSKm/pOGPi4mwK2vsFlBt6ke0iCjJ0dNmpaIdXXIDEr7VDoxuMt08L5Ia1/Lpr
         FepUoP+UtXZ79I/1b6kaMrQP1I85OZqUECr1d8XUMPELZdBPzUuEr7mJStkD1yY+2ZMp
         XzVb+jMxd5eOh56TXWr4GciOp5THBF+2mG1oE1WNlkaavLYMRKpjKSEgKtqo1B3G39mS
         abEm4whAOKP6atLpFzg1qoysSvcyC4FI2p45ezZ0773Xbe3GHF/Dy3IfgtW+7dG+rGrA
         mbEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786955411; x=1787560211;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LH92ElShDin2r1KuNlfB+hn91KLMq+rpk5+sB/ghXic=;
        b=ZGW688oGu5ANi1fMDd1eUFDxKwKteP0BffRXM33aMtnpmtM+OdP2LISLELfQmaiRCt
         38hnuJ6Cc53EkBwBrC56ZEH0d/z+CnJvMFiRoFfAsmDZ7QT5mXYOHZMuL4/FnH5LL+5+
         ovE0wb0SBVjmHvXKFuJBqdFAcuOwi92RBfgHgHWp8lPAHHdgEJjX8I2DEBgLJoUighgA
         o8/puexAzEOEpj8CUitILmcR3b87qL0F8lggt/De2JAi4WI6cp6YzUk03+Vor0S1rpAM
         /MvL0gB3lG+Gi4sCjxz5oYk3kSmJBXTxULdHAXLvLozDvXU0xqxJg0mH4hMTUSZpiHSl
         XsVg==
X-Forwarded-Encrypted: i=1; AHgh+RoWmpeaL/CpO3rc0/JHtjLpNkmXPZqfSznb7y1m+2Ubz3NiBPc0UASFU1/OfudC4pz3ol7cuO2A7rA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzvocUuginxruPIiVktvVkV5jm8xkoc4prvI/LjylmKCJWQGfYt
	SaHHby+SdcizRSuQPuN2Jwh/C7sARhxirNU50LqDdNZ+vNg1mFhE6bBBuI8N60b8Ig==
X-Gm-Gg: AR+sD10D/p1LAejemjM80eu6175YmQ1W87KsplclU+dp36Z/H3bfAdvnL8Jk67TgHX7
	jhKocD+tTBOC7wPqQ657Y8AB1nTNV9/27n3zxoPFU9o0IC0oUq0tHtugpTdiGL8J775e+OBd60r
	91c4MU5sV8/6qlkToXACQkj5FRwdNad0jX3NF2MQYZ1umOGMSOn5l3h8xvHHC0kOimEmI8sx4wt
	ED6+aWHTscNRiSJpfmQj2FjjkldzmR8ehwDOcvEDc92/DnC42+PSpjg+tMefpnqTdgSGS3r8Iq3
	ALNkJU8CYMO6wYECoZoIsgzNb3owlBk2x4kjfXTSTF7R/oqLPVDrWp8cXVTpJn18xjHMqUYl/43
	iMZbNrq2npFCGQTDxacjZ/R44nhfiR+4hMeUBUDnAkjdPYByuZhVNFMpu1gzW5hO6bas5Yz8lH1
	6q0QJoJHgSWA5UwymmKUtwMNfFst8XlwMJeW90EABvW6mUlkE8YvFfPde0mQ12rhQGIAPTB+7D8
	Ocif7F2DdxTdGz6yhCVE+lu3bFygzHZsg1ntZ9KzrjyZQ0bumuZq+neBUxg/2c=
X-Received: by 2002:a05:6000:98d:b0:47f:d072:87d7 with SMTP id ffacd0b85a97d-4816073a090mr41468130f8f.9.1786955410833;
        Mon, 17 Aug 2026 01:30:10 -0700 (PDT)
Message-ID: <4f58e236-c40b-4fcc-82e8-5b6f3eafe656@suse.com>
Date: Mon, 17 Aug 2026 10:30:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/nmi: Fix mis-classification of watchdog NMIs
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786955411-74C884E9-903F39FC/0/0
X-purgate-type: clean
X-purgate-size: 2288

On 13.08.2026 19:43, Andrew Cooper wrote:
> It used to be the case that cpu_data[] inherited the BSP's cpuid_level until
> the AP had calculated it itself.  Following the rework, cpuid_level has a
> placeholder 1 until it is caluclated propely.
> 
> setup_apic_nmi_watchdog() happens to be called on the BSP after SMP bringup,
> meaning that the first call is on CPU1.  It is also positioned in the window
> where cpu_data[] is garbage.
> 
> As a result, setup_p6_watchdog()'s one-time calculation of the performance
> counter width falls back into Pentium compatibility mode assuming 32bit
> counters.  This causes a watchdog NMI which is delayed a little (e.g. from an
> SMI), to appear as if it hadn't overflowed, and therefore be (mis)classifed as
> not a watchdog NMI.  On systems where unknown NMIs are treated as fatal, this
> results in a spurious crash.
> 
> Switch setup_p6_watchdog() to use boot_cpu_data.cpuid_level, which is how this
> is checked almost everywhere else.
> 
> core2_vpmu_init() used the same pattern to look at leaf 0xa.  Despite being
> init code and only running on the BSP, {boot,current}_cpu_data are different
> objects, so switch it over to checking boot_cpu_data.cpuid_level too.
> 
> Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> I hate this fix, but it's the only thing which I consider remotely safe to
> backport.  Recent attempts to alter CPUID ordering have 0 success at being
> bug-free.

How that? Collecting CPUID output should be doable almost first thing. There
are no (or in case of doubt: there should not be any) dependencies on about
anything else. Of course re-collecting may still be necessary after ucode
loading. Yet from what you say I must be missing something crucial.

With that in mind, I'm also questioning the Fixes: tag (without this being a
request to drop or change it): Using another CPU's data isn't much better
than using partially unset data. Unless we assumed full symmetry, at which
point re-obtaining of most data on the APs would be entirely useless. Hence
the issue was pre-existing, with one bug there hiding the issue addressed
here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:31:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:31:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392598.1631559 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsko-0004PV-G0; Mon, 17 Aug 2026 08:31:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392598.1631559; Mon, 17 Aug 2026 08:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsko-0004PO-Aa; Mon, 17 Aug 2026 08:31:34 +0000
Received: by outflank-mailman (input) for mailman id 1392598;
 Mon, 17 Aug 2026 08:31:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvskm-0004PG-TX
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:31:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvskm-007oS7-A0
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:31:32 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82c6e3-2eae-0a2a0a5409dd-0a2a45028de6-6
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:31:32 +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 <oleksii.kurochko@gmail.com>)
 id 6a82c6e4-6ca4-0a2a45020019-d1558036c5b8-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:31:32 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4980dc26022so30876465e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:31:32 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49987b3a6dcsm116211305e9.1.2026.08.17.01.31.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:31:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786955492; x=1787560292; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=89+/G83egPDzhAja1d+D/ziiHDRVhmgqyaj/E6jrZbo=;
        b=hDaBsnN+EFo9T32cv85usg1Ps0H+6AulZ+XxbTcK4XRo6AaYQcqDkoS4ZS95g0IfUv
         FbGveqambWa5Op2rTu3j4CdiR6f2SHvLryprWHqWT1zCBWB9wOrXPZipA0yxkKMjZK8X
         B33o9J8kIrCCgPXuWnIni1UKOpm7ZpdpttFT7lgLwoEoPsqq/omXHbYjki7Jd0ld6z92
         ATMSdD8wCffxX1uEaUOw9eSgAMbw3E4dZwiwhQT+lNof8ZYQCwrMWeSUc/thos7K/Qel
         RCfADiuRplH+DkhCb8A3LzZlBJeV8TcFCa+/X7xxUOv78Js3etNUf8zmEEcuq6ESzxF4
         poHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786955492; x=1787560292;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=89+/G83egPDzhAja1d+D/ziiHDRVhmgqyaj/E6jrZbo=;
        b=kkMGKF5DA2YBJa/GSthky3XJVyf8NzXdg/flQ4UP7nxMjqTu1BrnuwrqE8mhoU1cbk
         jUKguAjRSdt2yAXc063mZA5PiCUay7j7VKAJYCT40HIVl8RrCqLtDcMP8Jq0AB/giTFx
         S9jFPVAzXPrtozFqIPM68qQoTPrrvnHnXrkkK56Www84ULhdkwKZec41UiutyIpXU3QZ
         jWmMsMB+x3SoUi8cQBPHmeB1LFozFSkF6mPrqYNE+06k1asO5oI2jcL6coMjbMhZ2eyk
         FTalMKs1Ibc9d+3EMCkVhxxgC9+RlbvXxxebmQuMW0o+/kyTdw9R8ruQFgS5eo/K96cU
         fvTQ==
X-Gm-Message-State: AOJu0YwtozhjRMHWVVSq9lc3YbXy5VTkd7qxJ/S/sLRJu7LXSmHXemso
	NWknfjEKKbMMTUgMFeMa2s427HbvMuyX4HPVa1NkPz+n8x2ukbIHdsz2
X-Gm-Gg: AR+sD1108Rjj+g5ovxYObMuIavOG5RnF94UwK50jQ/DdkJU1RVzC7TyjxRKREr9rA09
	ABGx6yzKtktnvmxYdQ9ER4zGDhG4bFyu5NKGkaXWkPycVrvUr6IyWPaU51OBo8jNKsOAk/kAzfJ
	8iL3yJ7G6JNVpTagA+cLWdxLXao7wgUKsVj16/kyngJ8OJeBDe/KJDqYFQ0X+kEJZ0ThpfKzSsw
	XHL0SCNqQDoZd2XR2MLUcXCDeQOnxuzAsCAzoZpYFt14tYyL0J08/59Tzeigouou9T+PmIq222F
	ylpz0Y0Rdm9aW5DuVzOdrW0AQjSPiPZFnFGYs88wrTVUnTO7VZkseWfCLLVTeSRgP9b5vz4uNDW
	tilI/SgdCe3LvbAmf5vxFKxjgl4qAd6zCK69LZG31yFUXSRzatWcCF+TV6WCbBBJde+4sX2TnQi
	tQ7sQaCW+jS+qut/pSypOCzxxxCngoV20CyqqyFdqj3HrpTwsXIBPFNcBLPP8Vg7FUOHZXa8G1D
	a9WjnnXSYki9DeqedGiG6bDqNv90aP2GKMD0FDVKeo=
X-Received: by 2002:a05:600c:564a:b0:498:ff3:71ed with SMTP id 5b1f17b1804b1-49987993affmr277094525e9.17.1786955491555;
        Mon, 17 Aug 2026 01:31:31 -0700 (PDT)
Message-ID: <cae4c5ef-cc4a-47a0-90fa-2f84c00ba4a6@gmail.com>
Date: Mon, 17 Aug 2026 10:31:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 10/17] xen/riscv: introduce
 vintc_state_{save,restore}()
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
 <1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786955492-F1AAD2AC-A298BED0/10/73395122804
X-purgate-type: spam
X-purgate-size: 1398



On 8/13/26 11:42 AM, Baptiste Le Duc wrote:
>>   #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
>> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
>> index 372c8d3a20..879d513374 100644
>> --- a/xen/arch/riscv/intc.c
>> +++ b/xen/arch/riscv/intc.c
>> @@ -163,3 +163,17 @@ bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
>>   
>>       return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
>>   }
>> +
>> +void vintc_state_save(struct vcpu *vcpu)
>> +{
>> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
> Is there a situation where ops could be NULL? If yes, add a check.

It is unlikely that there is nothing to do during a context switch for 
vINTC, so vINTC should provide an implementation for saving and 
restoring its context. This also ensures that a NULL pointer dereference 
will lead to a trap, allowing us to catch cases where a 
context-switch/restore handler is missing.

Even if it turns out that vINTC does not need to perform any actions 
during a context switch, it is perfectly fine to provide an empty 
implementation. However, as mentioned above, this is unlikely. 
Therefore, having a NULL pointer dereference here is intentional: it 
helps catch cases where someone adds a new interrupt controller driver 
but forgets to implement the corresponding context switch functionality.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:37:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:37:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392608.1631566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsqN-00052P-WB; Mon, 17 Aug 2026 08:37:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392608.1631566; Mon, 17 Aug 2026 08:37:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsqN-00052I-TA; Mon, 17 Aug 2026 08:37:19 +0000
Received: by outflank-mailman (input) for mailman id 1392608;
 Mon, 17 Aug 2026 08:37:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvsqM-00052C-R2
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:37:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvsqL-00Czfz-QG
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:37:17 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82c834-8faa-0a2a0a5109dd-0a2a4507e292-36
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:37:17 +0200
Received: from [40.93.194.46]
 (helo=SN4PR0501CU005.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82c83c-b4ea-0a2a45070019-285dc22e3b12-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:37:17 +0200
Received: from SJ0PR05CA0179.namprd05.prod.outlook.com (2603:10b6:a03:339::34)
 by IA1PR12MB6412.namprd12.prod.outlook.com (2603:10b6:208:3af::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 08:37:12 +0000
Received: from MWH0EPF000A6735.namprd04.prod.outlook.com
 (2603:10b6:a03:339:cafe::81) by SJ0PR05CA0179.outlook.office365.com
 (2603:10b6:a03:339::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Mon, 17
 Aug 2026 08:37:11 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 MWH0EPF000A6735.mail.protection.outlook.com (10.167.249.27) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Mon, 17 Aug 2026 08:37:11 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 03:37:10 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 03:37:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=De4xZ41pAxskTvd8zzrsfCjraSG44fNNFZRe6iLh7c8ixsSxFshWFbeO+7K3KBrkq+P7zcS/6s4/GQwEAY17SHEYyNgr+XHFTbQzAnWS4VBx+pQqIOqU+3mapeF7UujIuIcxd6rXJDJN8bbE9jdZQAgFEiqQEALWq8k1LL4WjG+KvWvHihkodFsURC97H5Fd11N9jS8ao0+9lob9al0ViWbNtuYq4hLKpyWBdSPddlXtZfSnQZobDylGZKQegiW/utGfulPvhwQJpb5/SPno7oZtHeT/YPbP2yhl9T6Og5jWI/x+VOiFnzH8EU1UonXVhAqvpILCUUtWh/t/Tai1Fw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i4+tSok4Pnje7Wo8DoBwkNvCvPh1TY4Of3DJzT7jiAE=;
 b=u1vhzmRc25IDMpzAi7ZZSI+D1iJzPdPfoK8CAwutTCaYJJHM/GnJI5CHZ83vonQcQvgQOnFaK3HApa3mORwbpRIZW9L2/D2B7YpiSZ9kCepiZ4vmR9GuNBH3oK8WxikUWQZpwLsbYv7S/WLWyfTLUuWj5Ar2QvQ+6bCL+wZSx0pjILWEkwXSllIKX9CnUOtxebaKvritG6VIMo85oBDtAlnTtQtVEmDhuDAGqipHMYxQRg9XOEaH1Me4BU/Bz7mIuh3yS9Gl74C4AtDSfK4/RVDgb5axGUuUl4ED9pjesdyMCr2bUdjeYOmvUAxZO95b/250ktLMuSBoHjOT7k0nzA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=i4+tSok4Pnje7Wo8DoBwkNvCvPh1TY4Of3DJzT7jiAE=;
 b=BaMksD5OJQITTjAwCdczZHY0Dg5VH7Kc1gTNGLwAF2vMC0QIkPv4hR3mN5S4FAa6seMZKCHRpMaMNAFUg4d1LkFueZPPkkFbGiGpdKmroSq87J8XYnl7M9T/YO5mI3InH1/SQyBixlgkGZQxpew8/Mu/inJX1i3iVj5JyLqVuV4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <701ab3f8-b455-44a2-947b-2e1cc8cedea9@amd.com>
Date: Mon, 17 Aug 2026 10:37:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/3] xen/arm64: add early printk for the classic i.MX UART
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260814162535.331459-1-onlywig@gmail.com>
 <20260814162535.331459-3-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260814162535.331459-3-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A6735:EE_|IA1PR12MB6412:EE_
X-MS-Office365-Filtering-Correlation-Id: 8c814d3b-c696-4784-14aa-08defc3abb92
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|36860700016|82310400026|1800799024|376014|56012099006|10067099003|3023799007|22082099003|18002099003|4143699003|11063799006;
X-Microsoft-Antispam-Message-Info:
	TKBe7U2tJBYBzp2cMIzBjZM3ux39I/DcfP0a4WGxGkKfrTwkPnekqwdFGOVIsWM1fdoe2r/JtmoZUe645vfXmkHZ8UEhNRR/lIoqsnGjvKr+CACT4RecmHQ1VSFFq8EypEcOfHbGBr0LD0JT+qyBf5tcxASz6DZ4N9OaCHN8o5bHGuJnYfH2t4zQxrLsSW/n5X4IDTvsPrhRF4GIpw0yE/AokxgQjVFjPSlt0NTppTjsoiVQMzbSFaCx0pqjDMzt5E2MXENo2oJU6hqqUj+4AIG5Tu+XcxCRooX3LPOWoN09Mab2cA2j65kNm2AgO443weunMYlUe9405y14LXCAZegSD2S6rL9iR8GKX6GHrEcP93k+qTvKnQ4LD+8pf8Ecc4GeYm1kRCWQJsh/XYoEnOlBocyMph3DYaB0Opxw78Veg2icwFXi4Lu5YhDA9F3dEF/Ycg53L3hjSw7omPqjrrxl0TEPtrmp/h+tUVsL7UTAYwqh2lSljdg1pIk+yOiKk+H+DAnVtnU4Wq0jQUbKjbnD42eDyBWa+4s4s0zWXv9T3df5ANbLVZp2KfX5wKHIkwnmgAxdfItzOaTJ5nO5jDaT55ZI4tZBgbYMoKW63izaCvcUqQA1tlpuHR0Yp3XruhV4fczM6aAFsTwrDthR3IFIYi0EpifcUVcmDC2mJIbBseZ2/qQllJgDUBL71wwunVpF0Kfwb0HPCzAXqBre5Q==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(82310400026)(1800799024)(376014)(56012099006)(10067099003)(3023799007)(22082099003)(18002099003)(4143699003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Z+Nud6/IX5E0CNHBkP4Y3rivGYnKtCvAAxEt/iJ/ym9mvuyQ9alCk76tLez8vgAomBO2u3PEH4Rj91i+TnJTiLbBcs0M96/fVPKFi7NUNaneHkeJTnGlSfGEFXb7A6un93sKipYC6KUAEcOx/t+QIx42uaeMF7sf/uHN54XJZmSzRt3iDRxePCwysFE1Es3iro+fHRlUgJ/xSDTEpBW7Ki4S9VmN27Ht64etYnfgBZGkJ+WLCK1kbn+Udc0WKMPBo3WqBu8vAwXMD3esEAe19wk3b4N2nYcmzg1kv6pFf3oi2ihyehS5r3wcb5BHQQvrrfwJp9TM8HOvgFgZEBkYLD3aiq8mGFx0memRayV3jyNfd4bUbftRY/lxlQ30UJiJdZ8gp+icR8e5YWg1dq7sYBCg36RwUhhSZuF6F/O5AjhPGBwZ0Lv3RhGwi8mbkqKz
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 08:37:11.7058
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8c814d3b-c696-4784-14aa-08defc3abb92
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000A6735.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6412
X-purgate-ID: tlsNG-ef75cf/1786955837-A70DDAE4-E13ABF40/0/0
X-purgate-type: clean
X-purgate-size: 3484



On 14-Aug-26 18:25, Wig Cheng wrote:
> Add an early printk implementation for the classic i.MX UART IP,
> selectable via EARLY_UART_CHOICE_IMX_UART.  The UART is expected to be
> fully initialized by the bootloader.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/Kconfig.debug            | 12 +++++++++
>  xen/arch/arm/arm64/debug-imx-uart.inc | 39 +++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
> 
> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> index 5a03b220ac..63a34b813a 100644
> --- a/xen/arch/arm/Kconfig.debug
> +++ b/xen/arch/arm/Kconfig.debug
> @@ -44,6 +44,14 @@ choice
>  		  Say Y here if you wish the early printk to direct their
>  		  output to a i.MX LPUART.
>  
> +	config EARLY_UART_CHOICE_IMX_UART
> +		select EARLY_UART_IMX_UART
> +		depends on ARM_64
> +		bool "Early printk via i.MX UART"
> +		help
> +		  Say Y here if you wish the early printk to direct their
> +		  output to the classic i.MX UART (i.MX8M family).
> +
>  	config EARLY_UART_CHOICE_LINFLEX
>  		select EARLY_UART_LINFLEX
>  		depends on ARM_64
> @@ -97,6 +105,9 @@ config EARLY_UART_EXYNOS4210
>  config EARLY_UART_IMX_LPUART
>  	select EARLY_PRINTK
>  	bool
> +config EARLY_UART_IMX_UART
> +	select EARLY_PRINTK
> +	bool
>  config EARLY_UART_LINFLEX
>  	select EARLY_PRINTK
>  	bool
> @@ -185,6 +196,7 @@ config EARLY_PRINTK_INC
>  	default "debug-cadence.inc" if EARLY_UART_CADENCE
>  	default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
>  	default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
> +	default "debug-imx-uart.inc" if EARLY_UART_IMX_UART
>  	default "debug-linflex.inc" if EARLY_UART_LINFLEX
>  	default "debug-meson.inc" if EARLY_UART_MESON
>  	default "debug-mvebu.inc" if EARLY_UART_MVEBU
> diff --git a/xen/arch/arm/arm64/debug-imx-uart.inc b/xen/arch/arm/arm64/debug-imx-uart.inc
> new file mode 100644
> index 0000000000..80ac647f5e
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-imx-uart.inc
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * xen/arch/arm/arm64/debug-imx-uart.inc
This can go stale. Please drop.

> + *
> + * Early printk for the classic i.MX UART IP (i.MX6/7/8M families).
Don't mention 6 and 7 in a arm64 driver.

> + * The UART is expected to be fully initialized by the bootloader.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <asm/imx-uart.h>
This header contains non-asm compatible macros. Please fix.

> +
> +/*
> + * Wait for the UART to be ready to transmit
> + * xb: register which contains the UART base address
> + * c: scratch register
> + */
> +.macro early_uart_ready xb, c
> +1:
> +        ldr   w\c, [\xb, #UTS]        /* <- Test register */
> +        tst   w\c, #UTS_TXFULL        /* Check TX FIFO full bit */
> +        bne   1b                      /* Wait until there is room */
b.ne please

> +.endm
> +
> +/*
> + * UART transmit character
> + * xb: register which contains the UART base address
> + * wt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb, wt
> +        str   \wt, [\xb, #URTX0]      /* -> Transmitter register */
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */

Other than that, it looks good.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:43:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:43:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392615.1631576 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsvt-0006ko-I9; Mon, 17 Aug 2026 08:43:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392615.1631576; Mon, 17 Aug 2026 08:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvsvt-0006kg-Ee; Mon, 17 Aug 2026 08:43:01 +0000
Received: by outflank-mailman (input) for mailman id 1392615;
 Mon, 17 Aug 2026 08:43:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvsvs-0006kY-1R
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:43:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvsvr-002pCb-1H
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:42:59 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82c988-e002-0a2a0a5209dd-0a2a45069bea-34
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:42:58 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82c991-195a-0a2a45060019-d155dd2de4fe-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:42:58 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f703a9d05so2034754f8f.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:42:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a6c449dbsm897264f8f.8.2026.08.17.01.42.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:42:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956177; x=1787560977; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=x622Wrre38R1Vn44VSt++jkbOnTxGwZvj5cTSBQsfXw=;
        b=EUB05vIL9UqYAKwIXK3esOQTmKylagFxLfdR9WgH/7pY92TrzXPX88xjcTqaRYsOYX
         n13ltFfo0QJqeMxnl2C5Re2fMSjzAJHo+WJ8//Q8ljNGlEdMJgbPSbIaX2WOxoYOxJfj
         smnBKehDm1MC82PZbXSd1AwVnNxE8pcKAMWUkZaqS3fokK22UnyDihCw584OX5BE1Y7R
         BEE2mAInB+GMOgCVa3Bjk9t8pSMoRtbtiylZO0Qh8wB2rWcaM7X9TM4/qgM/5yVrW0Dq
         ApojTREoLPNoeUipM1N9hk/WXaPzsS2pTZgsQIhBV+1/6nmDp+GyakH8tSvQcudfKl1B
         WMJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956177; x=1787560977;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=x622Wrre38R1Vn44VSt++jkbOnTxGwZvj5cTSBQsfXw=;
        b=iwTAJozx5FSLNZ3uhkFiI9SouNmRTK56d8OYYqACrIYh4SlE4mOlEl8sV0nzbIon5b
         0xRnKZ7SsgYuues/g4gseSsRSTFuNpGbjfJpQ9kDJv7QetLCZFi/eq3cKCc1c+QpsdtN
         2rZU+PQlVDCOvpHHTR+QfN8F2SSzKTzBkPb8QZwJ9svy2z4cx/xgwk5jqQ+YXm410DdE
         gsFw45r4iy7ehjlB8VcQZcCJY53ncFnNuZD7UmSThVkH6BwWVLVc2ThB6282eBtJOwZG
         Es9cIkGFcn8abodKAr3fXUDHgIorMvlOkvQsxbvhLSBaKr8cjRt8CtbtWZ4Nl73lZ8hc
         x1kg==
X-Forwarded-Encrypted: i=1; AHgh+RoVrr3r4UdIerVXXVMv57D9b+jC4gV98DGDoo//pTlh5SePVnb9PywdNSIiFBXct+MTuF5wP3aVWo0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy45H7NBc/4xjY5pmY0KsGyAseGH7ChL9s9LIjQ1w0PB1xWnyIm
	tEEpFPO5M9RuG1Fv31PzcWyBuH5UjiHWiWxTrRZ423bsPy10m3Uwn8ku7sr0BftykA==
X-Gm-Gg: AR+sD10n4Q9y6SpZKCeZudfjQgGgEriLYZ1Oev+FIXsM91C6C7oQbbPstGRnsi9dBtc
	+XY2bY8Dy2HPj/9y1kguzu6McI7Nph9Qp08+hX/KVUptlfv0yAQqd4W6PTGAjLb746bWYrwVVlb
	97mT//VuKTLeXxC2iq8HzqR8e7JeDXIiJBsAkJ50vTGZIdDoIxXqOeyheawyOlF18X4JpRToDDt
	RO7v75Pxje8gvXuJeXXln1iUnHtRe+ySBFDqqyOgsRN5+gd+tVtZZXgh7RIdg+e/VFzMGkxP5R8
	E/Gy+EupCOGzQHEJaBQftgOvMeGjOD52F7DsnDeeWUkIbXWKufkBOo3QEKOOAoHOhwB/tp0F/sj
	jNZVWGcV3hWgEf5+Yp/AkRuqtt8qTTFvSEOD094fKsbAaNsPpyd9+QSa+TI1DiKRWWwXRffASJy
	sHTi11AMhl9DaCrTEPdVi5JR7rYR8lZ64p9xfZDIeKTesSYXLOAEfOrLH0w6kryYjQ9VJ639LBi
	XUUDkOJRu9ukpjhNwTnjG7o4ECECNt5fF4qvm+DvnrLaOJhSWJJ
X-Received: by 2002:a05:6000:46c9:b0:481:5eab:e1ba with SMTP id ffacd0b85a97d-481607bb9f7mr26744691f8f.30.1786956177425;
        Mon, 17 Aug 2026 01:42:57 -0700 (PDT)
Message-ID: <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
Date: Mon, 17 Aug 2026 10:42:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786956178-F76C877B-29EE13D5/0/0
X-purgate-type: clean
X-purgate-size: 7394

On 14.08.2026 17:23, Chuck Zmudzinski wrote:
> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>> -- snip --
>>>>>>> To address this problem, this patch implements support for
>>>>>>> Intel IGD devices with an extended VBT and OpRegion version 2
>>>>>>> and higher which is required for most modern Intel IGD devices.
>>>>>>
>>>>>> First of all: Where's the spec of all of this?
>>>>>
>>>>> Well, your first question is quite provocative. Certainly more
>>>>> social/legal than technical.
>>>>
>>>> Well, it was very much meant to be technical. I've had a hard time following
>>>> what your new code does, and having a spec to hand would likely have helped.
>>>
>>> I agree that having the spec at hand would be better. To be more precise, I
>>> can say that what this patch essentially does is port the support for
>>> the extended VBT with OpRegion 2+ for the Intel IGD passthrough that exists
>>> in KVM/vfio to Xen. Should I explicitly say in the title of the commit
>>> message that this is a port of KVM/vfio support for extended VBT to Xen?
>>
>> Not in the title, as that would likely make it too long, but perhaps in the
>> description.
> 
> Ok.
> 
>>
>>>>> So my answer is as follows:
>>>>>
>>>>> I do not have access to the official spec that defines "all this" but
>>>>> I do have access, as does the general public, to the Linux kernel's
>>>>> implementation of support for the Intel IGD from many sources such as
>>>>> git.kernel.org. The Linux kernel has enough accurate information about
>>>>> the spec of "all this" to provide very good support for the Intel IGD
>>>>> on bare metal.
>>>>>
>>>>> To elaborate a bit more, the spec of "all this" can be derived from the
>>>>> Linux kernel code that supports the Intel IGD.
>>>>
>>>> So you expect every reader to locate and decipher the underlying information
>>>> from a (afaik) pretty large piece of code in the Linux kernel? If the Linux
>>>> kernel sources are the reference, please can you at least provide pointers
>>>> into there?
>>>
>>> No, I do not expect every reader to decipher the underlying information...
>>>
>>> That is why I provided these two links at the bottom of the commit message.
>>> Perhaps you did not notice them:
>>>
>>> Link: https://lore.kernel.org/kvm/20211012124855.52463-1-colin.xu@gmail.com/
>>> Link: https://lore.kernel.org/kvm/20210325170953.24549-1-fred.gao@intel.com/
>>>
>>> They are the patches to the vfio kernel driver that added support for the
>>> extended VBT for KVM/vfio guests.
>>
>> Patches can still be in flight, so provide only limited help. Would it be a
>> problem to instead reference commits, or the actual localtion in Linux
>> sources?
> 
> No problem. I will format references to kernel commits the way it was done in
> this commit message of commit 99794c8a8ff8 in the Xen tree that references
> some Linux kernel commits unless you suggest a better way to reference Linux
> kernel commits:
> 
>  xen/acpi: Import PPTT definitions from Linux
> 
> Import the Processor Properties Topology Table (PPTT) definitions
> from the Linux kernel header (include/acpi/actbl2.h) into Xen.
> 
> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git b8355bcac253
> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git e62f8227851d
> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 091c4af3562d

I expect though that Origin: tags would be questionable to use in your case.
Can't you simply use URLs pointing at the commits in Lunus'es tree?

>>>>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>>>>> +
>>>>>>> +    if ( !rvds || !rvda_host ) {
>>>>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>>>>> +        rvda_host = 0;
>>>>>>> +    }
>>>>>>> +    /*
>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>> +     * after we also write the guest address where the
>>>>>>> +     * VBT will be mapped.
>>>>>>> +     *
>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>> +     */
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>
>>>>>> Why would you need to communicate a host property to the DM?
>>>>>
>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>
>>>> I don't follow this: Anything the guest can access should also be accessible
>>>> by its DM.
>>>
>>> I think the host OpRegion is not currently accessible by the DM.
>>
>> Can you explain to me how the region becomes accessible to the guest?
>> That would then (hopefully) help me understand why the DM would not have
>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>> guest are also assigned to its DM.
> 
> Currently, in the device model (Qemu) we have:
> 
>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>             XEN_PCI_INTEL_OPREGION_PAGES,
>             DPCI_ADD_MAPPING);
> 
> That statement is in the igd_write_opregion(...) function in the
> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
> 
> If I understand our current implementation correctly, this statement
> is what gives the guest access to the host OpRegion (3 pages as defined
> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
> in hvmloader code).

No, it introduces mappings of those pages into the guest's P2M.

> I don't think this statement makes the host OpRegion
> accessible to the device model, though, so I think, if I understand your
> comment in an earlier about my patch resulting in what you called a "layering
> violation" correctly, that our current implementation is also guilty of this
> same kind of "layering violation."

That code, if it can be successfully executed, indeed doesn't grant any
permissions (to the DM or the guest). Instead it proves that the DM has the
needed permissions to access the pages itself. This is what the handling of
XEN_DOMCTL_memory_mapping has in this regard:

        ret = -EPERM;
        if ( !iomem_access_permitted(current->domain, mfn, mfn_end) )
            /* Nothing. */;

Subsequently we check that the guest is also permitted access:

        else if ( iomem_access_permitted(d, mfn, mfn_end) )

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:43:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:43:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392618.1631585 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvswH-00077p-Rf; Mon, 17 Aug 2026 08:43:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392618.1631585; Mon, 17 Aug 2026 08:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvswH-00077g-Ou; Mon, 17 Aug 2026 08:43:25 +0000
Received: by outflank-mailman (input) for mailman id 1392618;
 Mon, 17 Aug 2026 08:43:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvswG-000767-7z
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:43:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvswF-00G6uu-Ky
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:43:23 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82c996-bab6-0a2a0a5309dd-0a2a4509ddda-18
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:43:23 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82c9ab-be1a-0a2a45090019-d155dd2dad2c-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:43:23 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47fe377a217so2059547f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:43:23 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a7c55bsm2148710f8f.20.2026.08.17.01.43.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:43:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786956203; x=1787561003; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=07Vo9BSt6zO4QvTI9S+sSquddls5IYIUVjcjR1j18+c=;
        b=KJib6L4THdaL/HGSeerKPjjkvzqbBma2rhrnDjSt5vrUakw5uxfcKrWT2rDeEyelSO
         OJZskNcbZZQYfI40SUeM0wozYkwX03Vzkqjin04Tka80GEv3RmMo7OCiReQTDqtX2qCs
         nRfCj2JNEHOpbw71psxBpUByFNU2C5KgYrxgiG2DHy3PeyqSiEv2Cnm33gjkdF5Xwb4c
         y4o7wwyadkJUhPUbApJBQCyBiTBBNnbJqTc0G/21tChjA3nr1w/pw0I+XHBDfDm8kxUr
         uXYVYPqtD/xIGd5jkKwYhV2KPVrCMXLfCMJ8HCRBSd15JAPSCTHACYxNW3hjYJZZDjju
         Drgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956203; x=1787561003;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=07Vo9BSt6zO4QvTI9S+sSquddls5IYIUVjcjR1j18+c=;
        b=B+eL+zSr0qzhI7gVc3Jq2i9zI/n/986rkV9jIV7QQpm5Ib1aDnzi5MXH1U524dOLpf
         +T2f8kd+3X2uaj/p4xLBZO0cM+zhWgAuqsaN9m8xW6aYWtlV2h17qR53oLGug4gfCuCq
         aSaXlKe2Nu9ycscRg3CdZ0/rAY8ZFZGsjqaTXcUW6SytFtxx+TUj6G3oSIjMLlJHypr5
         8bnDe6NfsE+xv7rLx8S1iizI9V03vetgBFVK6mO60D65j+V07/pOS+S7ZYzuezVE96Ls
         4FoC7/PkWTG6VO8ery7Czzk5x5mMi19RtZoLCDSNKRKVRInR7V7a3tiHjy6BTYSLC3Af
         Qvpg==
X-Forwarded-Encrypted: i=1; AHgh+RpADh4MX8oDTxJ9YOecBByn+B5RSxpIoLGoY56GVm4/uqq3+Y3xG2GL37iIaXLKrjgYddnhEmzEweE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyMVX39dYQSzOv498kJ2L03uDbBGnEjqF6a4g/ZFQ8BEcCa4UjW
	rfknaxET6sjXeIHfbOdxqhRl75ARqktqBn2sXq+rcewYmczS65D53tXP
X-Gm-Gg: AR+sD123ytXIzPMXGdb5SIrGwSjZVsGrA7QOj6TuQA4p+PiN/Z3JYwGcjrWFeQIQqPd
	dgqmEljzyD7KLtQVoaYAMOpkbCpJALywg0Kv+yq0uz/7941KQcxpL6S026TPIeOMKD0TGNstokt
	2hoIL5nAEEN1+aZrQw7BWG70s+f1XNu4bcwZa9M+pWXGLjKPZAPAErfVEWK7WMguD7rHGJg89GR
	bBBXNxiBi7NKJjNS5aUEFDWiDKUlqFMlt34Quh9WQoONA3Vmb1PWnCJKlD74hMBRMM5sR94WAKy
	nuVPwHN+mCjhvvhMSMqJWX+J+f8fWyabz0ezgW6tMNQa6bkfSFkKHux0MXl3GiOdLyWtEM7BP7Y
	o2+z8z+kjjUJ/u2Z0xOAkzGgeZB+iv7qdicxfaKxe/QxXsHcWrJI12IvzaAFEw3PVai6jgACKjR
	ErFfHuY0mKumbpf3Xc8gIDkLp110HQUjSd0cadfBskNs7gc1Rjb3UQCa0jPobH6TJf+KCw3IJDm
	nKjqpRPAbWL7q4Bnnmkpl2EV2lUH+exTdZhhah6pw8=
X-Received: by 2002:a05:6000:1844:b0:481:5ba5:994c with SMTP id ffacd0b85a97d-4816077aab7mr36040760f8f.20.1786956202932;
        Mon, 17 Aug 2026 01:43:22 -0700 (PDT)
Message-ID: <eb97f777-3700-43e0-b200-8250bdae2311@gmail.com>
Date: Mon, 17 Aug 2026 10:43:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 11/17] xen/riscv: add vAPLIC state save/restore hooks
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <b8aad28481520eb241a1f7519336d3e4bc9aff9f.1784560663.git.oleksii.kurochko@gmail.com>
 <675c8106-a515-4567-ba30-09f2b0631634@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <675c8106-a515-4567-ba30-09f2b0631634@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786956203-BD8C1034-6F772AA5/10/73395122804
X-purgate-type: spam
X-purgate-size: 1793



On 8/12/26 4:19 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/vaplic.h
>> +++ b/xen/arch/riscv/include/asm/vaplic.h
>> @@ -34,4 +34,7 @@ struct vaplic {
>>   int domain_vaplic_init(struct domain *d);
>>   void domain_vaplic_deinit(struct domain *d);
>>   
>> +void vaplic_state_save(struct vcpu *v);
>> +void vaplic_state_restore(struct vcpu *v);
> 
> Why would these be needed? Can't ...
> 
>> --- a/xen/arch/riscv/vaplic.c
>> +++ b/xen/arch/riscv/vaplic.c
>> @@ -400,9 +400,27 @@ static const struct mmio_handler_ops vaplic_mmio_ops = {
>>       .write = vaplic_mmio_write,
>>   };
>>   
>> +void vaplic_state_save(struct vcpu *v)
> 
> ... both be static? 

They are only needed to cover potentially two cases (w/ MSI and w/o MSI 
support) but I see a sense two follow your suggestion below ...

> And don't they want to be cf_check?

Agree, cf_check should be used here.

> 
>> +{
>> +    if ( has_msi_support() )
>> +        imsic_state_save(v);
>> +    else
>> +        BUG_ON("unimplemented");
>> +}
>> +
>> +void vaplic_state_restore(struct vcpu *v)
>> +{
>> +    if ( has_msi_support() )
>> +        imsic_state_restore(v);
>> +    else
>> +        BUG_ON("unimplemented");
>> +}
> 
> If you're merely forwarding the calls, why can't ...
> 
>>   static const struct vintc_ops vintc_ops = {
>>       .vcpu_init = vaplic_init,
>>       .vcpu_deinit = vaplic_deinit,
>> +    .store_state = vaplic_state_save,
>> +    .restore_state = vaplic_state_restore,
> 
> ... imsic_state_{save,restore}() be used directly here? And whatever other
> pair of handlers for the case when it's not IMSIC?

... It could be done in that way. I will follow it.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:49:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:49:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392632.1631594 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt21-00085F-F9; Mon, 17 Aug 2026 08:49:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392632.1631594; Mon, 17 Aug 2026 08:49:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt21-000858-C4; Mon, 17 Aug 2026 08:49:21 +0000
Received: by outflank-mailman (input) for mailman id 1392632;
 Mon, 17 Aug 2026 08:49:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt1z-000852-GO
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:49:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt1y-00G8Es-Pp
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:49:18 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82caf6-e002-0a2a0a5209dd-0a2a4503b196-48
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:49:18 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cb0e-fae8-0a2a45030019-d155dd32c91e-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:49:18 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47fd4531020so1852085f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:49:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b572sm2159848f8f.13.2026.08.17.01.49.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:49:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Content-Language:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956558; x=1787561358; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to:content-type;
        bh=+Of7X9K1yGzrlBthhfqPFesBMb3c7qDgIQCv8Ns03xY=;
        b=BiUdOPYXg3vfOSh15PUCGZzKJk6wSZtKpoBgOYS7IF90slZZ2HvkT9keMglbz/jcY8
         wj7PSDOzjJ1jVeUevvZ0zMRjGTpdnAS0YA+NE4ZjvX9Obhg02dSbdnCLp2A0LNhgwa9w
         HabDFyW6afANpk0T/aMySei0dIcceWr0W4tTbLjE+cTuDuZ2cuaQMCthFCg/FvkwMeTr
         XVEoqiil03ZXHwe3qrBI/cpQDs1tPpAvGYdG88oqxrOafMBe4Zjpy+/eyK9UpCCShaG4
         UokY/KQS4TkLCo3jiC+VHTdmEsIQg7vkglivKtcocMC/SiGhRM1IlRW4iZp+ZuJpcqL/
         7Egw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956558; x=1787561358;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=+Of7X9K1yGzrlBthhfqPFesBMb3c7qDgIQCv8Ns03xY=;
        b=SggmhPgNWx7tJ5xWOyvwGFPMQ0qnuQCZPpVa2nVKm4mDNJWr/g/tSyuNNjm1oRWRbX
         RFyPkTUXm69cjVV9k5GeSorbQ1rDz8sd+iU4TfJdO1FCChyTJKJTSWp0Sxi8OHlqzh7e
         vzxZHxBMkpgLXxqFvt24Xg/vlR9660TkBQMTgXzvKojXQqGbC8N+YZsu0qXJuZrTyWb1
         6ntitmYFpSzdOiTBBUB+EXU+RnybdpIvv7b3q91lLP2xXsPJ/J1Yr5wXDrxz4dfXdMyB
         w4N2UObpLGKoKRc3KKJAMNQAcFCssCRKdQCAQ8ki7hoZV1Sr5t9rFVhBemswdTfJCpKb
         hU4A==
X-Gm-Message-State: AOJu0YzNhWTrS+RjwDG6jMJQjv+UBUie7pcfWf6AAwhMCw0/+7fhS0FT
	UQjolQpGCX7zXW/Jdt7BWoAiuhCnY5gemJaXprZpOj/5gGobcW505+kq921BUogdXstBFGQgRr8
	ex3yPeg==
X-Gm-Gg: AR+sD13Jyz5HUsYZXqERf0IdXa3Co3Rqluk85EFsd8JHqtYbalXVFAKFONipyoZjqwm
	OR3SoOfGJA7XUtsDQVhtgtarCS43P5ABgU0SeGS7VkChS0MOjX48T5lgMqUHrVTnshTYJtNW6Oh
	75mafATrHXVob6+tnt9YThUZ4Fqh0Hqm2F5S0bQD9lwlhzAl8cZV2K29UkjlpmuNKLqQPz2T1sR
	esmF7bXZfqrNw7wvLUVpGp5Z02G2ELOFFP6ePyImyhPFUz8hv3TZ9WNfCAvRQp3YFJKOIeHOhkp
	xF2xrBFIQA+b+GxMHy/ql7IYvcQEjqzoS/0Hzd9KqFnbmUWaKhcuCoAgOnRBEnkPCxgIdAr0H99
	TBNoT+7k3mtv5GbkSqnOqgKwx5PyROOE7GvwkdXMkZ1VDvzgUSBvBKO4QvWShxee+c/ncCthqrT
	JwZwy4NMpWwrdTFZUULPeaOYJAaFWW1TX71HDlN7EbZ69mp/MP/SG/rcdyfWFiQ0e0N4t1V9492
	leqpGonb82SoLWgAqWXBQibMDF6zLNXiavA073mq++YPoLLDBIm
X-Received: by 2002:a05:6000:430a:b0:474:530:9d with SMTP id ffacd0b85a97d-4816072d2d1mr35078741f8f.13.1786956558088;
        Mon, 17 Aug 2026 01:49:18 -0700 (PDT)
Message-ID: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Date: Mon, 17 Aug 2026 10:49:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 00/14] XSM: follow-on to XSAs 492 and 499
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1786956558-776F34E9-6EE5205F/0/0
X-purgate-type: clean
X-purgate-size: 1122

Working on those XSAs made pretty apparent that there's a lot of redundancy,
requiring changes in too many separate places if e.g. adding / altering /
removing a hook. Obviously while dealing with that, some other, smaller
tidying opportunities turned up as well, which is what is being dealt with
here.

v2 addresses review feedback and includes a few new patches. See individual
patches for details.

01: XSM: make xsm_default_action() const-correct
02: XSM: convert "allow" (Flask: "access") parameters to bool
03: x86/mm: get_page_from_l1e() is PV-or-shadow-only
04: x86: restrict PHYSDEVOP_* when PV=n
05: XSM: make Argo hooks well-formed ones
06: XSM: fold xsm_{,un}map_domain_pirq() hooks
07: x86: type-correct last parameter of map_domain_pirq()
08: XSM: pass just SBDF to xsm_{,un}map_domain_irq()
09: XSM: fold xsm_{,un}map_domain_irq() hooks
10: XSM: fold xsm_{,un}bind_pt_irq() hooks
11: XSM: convert remaining event channel hooks
12: XSM: convert remaining domain-related hooks
13: XSM: convert remaining miscellaneous hooks
14: XSM: avoid fragile assumptions in xsm_fixup_ops()

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:51:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:51:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392639.1631602 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt3e-000193-PU; Mon, 17 Aug 2026 08:51:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392639.1631602; Mon, 17 Aug 2026 08:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt3e-00018w-Mx; Mon, 17 Aug 2026 08:51:02 +0000
Received: by outflank-mailman (input) for mailman id 1392639;
 Mon, 17 Aug 2026 08:51:01 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt3d-00018o-Ny
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:51:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt3c-009PrU-Nk
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:51:00 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cb69-8faa-0a2a0a5109dd-0a2a4501dc7a-42
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:51:00 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cb74-5984-0a2a45010019-d155dd2fdde4-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:51:00 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-482938466a7so1803982f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:51:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a315bfsm2197432f8f.1.2026.08.17.01.50.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:50:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956660; x=1787561460; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=eZ6SZ4ba4nhrBe95M28NmTJI8Qq1jIqB20FYpZGCsQQ=;
        b=e2nFJh2dXohPstzE60uVMhHMmtscwe76LwHEuByRI2K7JsoBnm+m38He3fnBPwUL4n
         tNOLKchVbISjav9s4qrO4YJi23n+k2DjelKInWBhbF3mz4lPGYIl5ZbhP6C+eqiYF6+2
         HOIb599NllZktUytTV1RCr87w4Kku5SGlpHA9JIo98a/3sjqC77t0Pc/VePGSdYoLw8h
         kVh5Qr9nInWuhjj/vloC+JZOajj9lJcIHZHi5MxG5P9AiLdl5LNqRaIEdztXB9/2nKX1
         qv1cah6M9/BMypMKQMPMUS0vFAVmtwIdz7CZuksDQdOfc1kHMdmVO1Pj7kZBHG6VXCVK
         GnDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956660; x=1787561460;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=eZ6SZ4ba4nhrBe95M28NmTJI8Qq1jIqB20FYpZGCsQQ=;
        b=r0DbxGitXgUBLSQIhzkJBH/nC+DR08x9D8lx5lueRwvKl+obgryb3xFaamy8z/4/W8
         AyqPyKfbmgHFeh8kkUM7X4FDdEdWQ+ZhLwro0xe27H0shTJZRzIIfx4b2U0p/Qybcbjm
         9E0EU4EkvIxMq2yqZt+EPXpQ8T5EoaoG/kYwpCovCkPhWvc/+CwhIowDD1CQe/54RRyL
         AF6yqN2m4ZkBmkDeJd2efYFM4eMw3PmAM8edGXlm9Q/ljcFkhJjUIuv8m+TPQ6egOBGx
         9smnbNSdXEUKprzwFuUsZg26bvIBD6L0Z8J1jH2KPEnjSap3tvkDRozlNpkEUOHys7ko
         nbDg==
X-Gm-Message-State: AOJu0YwVYEbSIg5bPkMMYuzcq6O3gn7zwS5H0/WTbPHtEMC/cL9Lb8Bk
	ZYCDvKtbM9897Vq1K/yelEVPRLMFkdK/QKvl7abwAa7HZQiSrlxnlj2KYP0Suk0bNQJSxfa7VQr
	Nfr3UQw==
X-Gm-Gg: AR+sD12h7wY3sH3JDlXbOnCcKhRKeDHTqgfzl/rvtcrCBYKsydRCy/+t1yL1+RpFTnQ
	NvGm6CV7YDFmi31CO8obVCMmAe7HN3+jhypPP1n7UjcA0dRpUIK3mQDCPgN28scm3Rc5m/bPQbg
	HyGQ2Osc7qYFFGn23DiaccN1qbZenG6MTJOcqj0GkHD8h+zB4otgH4nkBSgTGMBBLNBTK9eqP/v
	nLZuPFAfivjSIekbikiEirXzJrs4jtXdog+ITra16mhfB8yUYlScq24seakrYFGy72vJIArqKdu
	fsbEo22z+m/+NtAhzuoLc70Duxxhm6APE4YXHhmtg3zYvcoRMabB/9GoQ2NIg9w0k86AcEB5wy8
	Fi9ZEnTgNXPnfQGq0D8gMANGe4mQYmSkXq0aXxUhIuPbXIyYgtGm0L3XYMYEUDRNY5MUof8SQeV
	enSqvYayzgfIrhawscxqnspi83RTAg5LEtLrveJmV3NkLPEP1KLj8enw8Usm+T0zuYhdDKjoauU
	SZMi9CGHsH7LOEfwIcVCY7d77xwNGODFGzgW3wlZrr1y2nwTEDgJrSyjXhGnvQ=
X-Received: by 2002:a05:6000:29da:b0:47f:c648:e274 with SMTP id ffacd0b85a97d-4816070be36mr27859706f8f.5.1786956660114;
        Mon, 17 Aug 2026 01:51:00 -0700 (PDT)
Message-ID: <8df4fd76-2f19-436c-937f-e1cce371bbc5@suse.com>
Date: Mon, 17 Aug 2026 10:51:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 01/14] XSM: make xsm_default_action() const-correct
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Frediano Ziglio <frediano.ziglio@cloud.com>,
 Jason Andryuk <jason.andryuk@amd.com>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786956660-BFA6E757-E0AC9521/0/0
X-purgate-type: clean
X-purgate-size: 651

To be able to properly use const on dummy hook function parameters, add
const to both domain pointers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
---
v2: Split off from Argo patch.

--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -76,7 +76,7 @@ void __xsm_action_mismatch_detected(void
 #endif /* CONFIG_XSM */
 
 static always_inline int xsm_default_action(
-    xsm_default_t action, struct domain *src, struct domain *target)
+    xsm_default_t action, const struct domain *src, const struct domain *target)
 {
     switch ( action ) {
     case XSM_HOOK:



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:51:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392645.1631612 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt47-0001aB-0T; Mon, 17 Aug 2026 08:51:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392645.1631612; Mon, 17 Aug 2026 08:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt46-0001a4-U3; Mon, 17 Aug 2026 08:51:30 +0000
Received: by outflank-mailman (input) for mailman id 1392645;
 Mon, 17 Aug 2026 08:51:29 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt45-0001Zu-Hf
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:51:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt44-00GMDv-UI
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:51:28 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cb76-e002-0a2a0a5209dd-0a2a4501d510-46
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:51:28 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cb90-5984-0a2a45010019-d155dd2ee9ae-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:51:28 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47f7027ca11so1885740f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:51:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996100073sm153443635e9.3.2026.08.17.01.51.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:51:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956688; x=1787561488; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=0/b/DUjZscGxl9LgcIBjaXV0FG4JzY7JAueSN3/ZjzM=;
        b=VcOU5bV+okLK/R72shYSIdSZOOtRxE3TzDRxZCwcBhuHfPH06TqUgWg6Xz2Q9Kb6K7
         e1oHSL0icWkhbz6MoIAlxyl7OPqNwvLWleVmXO+2xGGuG3J7f5tRM+i3zoqCkolVd4Sz
         RKxTirDrM77+7Lx4ncGKZgUmALO9L15yWtHaRoKqbr90D7D6zBSTiWFoTQJAZAtpR78G
         X72PA+/zWOK0lOM9oA6UCDMaJgYeljUGplpmTKSyTS29twEfrg4JbUtYaaCNxh3JVwGN
         wOQni3HswMYbHgPw5ZgijKRcSG++ycJoYtAsWXlnRrOWhTwU5l0xZGKqfiSGsY6MoFHO
         lE0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956688; x=1787561488;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0/b/DUjZscGxl9LgcIBjaXV0FG4JzY7JAueSN3/ZjzM=;
        b=TivNCezgy9IMi8v4lY3ISDazLjQ2n5JBnOdue27gieswpK+Er1mLpjJJVsXUh10VGV
         QzxMlqWWUAxwfbvtWjM/JDPwzXZ1RFo3MLbFvwfNnDB38zTJvvn1oSZXZ7wrgCyKiWw1
         PBe8DD5Nu5Ph49vOFgaOwyIq4Tq3G4Z3HXnojv0PFdwpXIl3bCx9BLkcYK0yS+a1c+Jh
         c/tAidK8Q+dl/+sI/ev12CbGNUYd2x+lwXRd4gWgWNyQYH8sA/co/j/juXOOlRN4Gc20
         ySfaXa9GfvXr+bbOOL99VfzkuTjCjuihK4AcoWaMBJ3lc2f0Qj0BLvJgSVT1ZjyXSQha
         2Ivg==
X-Gm-Message-State: AOJu0YxlIQ2hWfAObhabgG34CWDxBuDHxXe5b20ILuXqonL+vCRZnJMd
	Phwv5Z0odjnDmsX/T/qu3KaCBDiCpxK8Ja3BnyQ0vRTpS+bgjDLMe4BSE0rCxYzKV2fCx4++bPF
	fSXOSEQ==
X-Gm-Gg: AR+sD10IdGNBONBtU/hcBzwKSckh+jjz/o3pGpeHEXpmRkCpyt+XSNcBagGoZXpGPyR
	zBM3cgG9/ailjQBWkdMYOCpo7T2CSPBpIbyKPcEGf04+YWM5khXucp5hDGd/m8f1scC+SJmTdhd
	7q2/e5nYRJN50eisQPQaFpxOK4/XprOy111MJLi1+Im33dV/Ew5i39f3zPXexHpOCph7NUlSUgm
	JoeTc82EmyQpmWilL444JBX/OGN9vsoLH90uxWd5Fu8O1jLk1RDe0GHFc/8CNv9gq8PpsTiHciB
	6sh4S2S+Skt8OUb0TZzUK8/ynkZ4Vh02HqJlXVqg8ZD7hJf4BI71xzk3jz/dEoem0GfwBtIL/Jb
	8NuKhOnU7/YfP2KmnFi1U+91JDC5E8g5k2x1nHF239y2lFetoonf2CxZipSpfxIxvCtXxGCXRac
	/NLB86Zz5QigBGwnP7VyiKfcpssxd5IqFVylu8+r/kw7FgPvOCLNxLDEnnxDZ5ne9PLpG+T/Lyq
	+jRj7uXoTnH0hgr3tfhR+HMJhTgBc/lMBj4dZZvw8CFz+P6KJSt
X-Received: by 2002:a05:600c:1c21:b0:499:90f3:13b8 with SMTP id 5b1f17b1804b1-49990f315e9mr185511605e9.12.1786956688264;
        Mon, 17 Aug 2026 01:51:28 -0700 (PDT)
Message-ID: <1a4dd743-a64d-4657-b3c2-c9759799a36b@suse.com>
Date: Mon, 17 Aug 2026 10:51:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 02/14] XSM: convert "allow" (Flask: "access") parameters to
 bool
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786956688-BCD44757-12059775/0/0
X-purgate-type: clean
X-purgate-size: 9742

These are boolean, so they should always have used bool (originally
bool_t), not uint8_t. Leverage recent changes to arrange for this with
(now) fewer places which need changing (within the XSM machinery itself).
Adjust call sites as well, where the conversion wasn't done so far.

While doing this, rename flask_io{port,mem}_mapping()'s last parameters to
"map".

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
Why is it that Arm doesn't use xsm_irq_permission() at all? Same for Arm64
vs xsm_pci_config_permission().
---
v2: Rename flask_io{port,mem}_mapping()'s last parameters to "map".

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -235,7 +235,7 @@ long arch_do_domctl(
     {
         unsigned int fp = domctl->u.ioport_permission.first_port;
         unsigned int np = domctl->u.ioport_permission.nr_ports;
-        int allow = domctl->u.ioport_permission.allow_access;
+        bool allow = domctl->u.ioport_permission.allow_access;
 
         ret = -EINVAL;
         if ( (fp + np) <= fp || (fp + np) > MAX_IOPORTS )
@@ -306,7 +306,8 @@ long arch_do_domctl(
             break;
         }
 
-        ret = xsm_irq_permission(XSM_PRIV, d, irq, flags);
+        ret = xsm_irq_permission(XSM_PRIV, d, irq,
+                                 flags & XEN_DOMCTL_GSI_ACTION_MASK);
         if ( ret )
             break;
 
@@ -687,7 +688,7 @@ long arch_do_domctl(
         unsigned int fgp = domctl->u.ioport_mapping.first_gport;
         unsigned int fmp = domctl->u.ioport_mapping.first_mport;
         unsigned int np = domctl->u.ioport_mapping.nr_ports;
-        unsigned int add = domctl->u.ioport_mapping.add_mapping;
+        bool add = domctl->u.ioport_mapping.add_mapping;
         struct hvm_domain *hvm;
         struct g2m_ioport *g2m_ioport;
         int found = 0;
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -78,7 +78,7 @@ int pci_conf_write_intercept(unsigned in
 {
     struct pci_dev *pdev;
     int rc = xsm_pci_config_permission(XSM_HOOK, current->domain, bdf,
-                                       reg, reg + size - 1, 1);
+                                       reg, reg + size - 1, true);
 
     if ( rc < 0 )
         return rc;
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -260,7 +260,7 @@ static bool pci_cfg_ok(struct domain *cu
 
     return !write ?
            xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf,
-                                     start, start + size - 1, 0) == 0 :
+                                     start, start + size - 1, false) == 0 :
            pci_conf_write_intercept(0, machine_bdf, start, size, write) >= 0;
 }
 
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -505,21 +505,21 @@ static XSM_INLINE int xsm_unmap_domain_i
 }
 
 static XSM_INLINE int xsm_irq_permission(
-    XSM_DEFAULT_ARG struct domain *d, int pirq, uint8_t allow)
+    XSM_DEFAULT_ARG struct domain *d, int pirq, bool allow)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
 
 static XSM_INLINE int xsm_iomem_permission(
-    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, bool allow)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
 
 static XSM_INLINE int xsm_iomem_mapping(
-    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, bool allow)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
@@ -527,7 +527,7 @@ static XSM_INLINE int xsm_iomem_mapping(
 
 #ifdef CONFIG_HAS_VPCI
 static XSM_INLINE int xsm_iomem_mapping_vpci(
-    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+    XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, bool allow)
 {
     XSM_ASSERT_ACTION(XSM_HOOK);
     return xsm_default_action(action, current->domain, d);
@@ -537,7 +537,7 @@ static XSM_INLINE int xsm_iomem_mapping_
 #ifdef CONFIG_HAS_PCI
 static XSM_INLINE int xsm_pci_config_permission(
     XSM_DEFAULT_ARG struct domain *d, uint32_t machine_bdf, uint16_t start,
-    uint16_t end, uint8_t access)
+    uint16_t end, bool access)
 {
     XSM_ASSERT_ACTION(XSM_HOOK);
     return xsm_default_action(action, current->domain, d);
@@ -709,14 +709,14 @@ static XSM_INLINE int xsm_priv_mapping(
 }
 
 static XSM_INLINE int xsm_ioport_permission(
-    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, bool allow)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
 
 static XSM_INLINE int xsm_ioport_mapping(
-    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+    XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, bool allow)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -77,12 +77,12 @@ XSM_HOOK(int, unmap_domain_irq, struct d
 XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
 XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
 
-XSM_HOOK(int, irq_permission, struct domain *, int, uint8_t)
-XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, uint8_t)
+XSM_HOOK(int, irq_permission, struct domain *, int, bool)
+XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, bool)
 
-XSM_HOOK(int, iomem_mapping, struct domain *, uint64_t, uint64_t, uint8_t)
+XSM_HOOK(int, iomem_mapping, struct domain *, uint64_t, uint64_t, bool)
 #ifdef CONFIG_HAS_VPCI
-XSM_HOOK(int, iomem_mapping_vpci, struct domain *, uint64_t, uint64_t, uint8_t)
+XSM_HOOK(int, iomem_mapping_vpci, struct domain *, uint64_t, uint64_t, bool)
 #endif
 
 #if defined(CONFIG_HAS_PASSTHROUGH) && defined(CONFIG_HAS_PCI)
@@ -97,7 +97,7 @@ XSM_HOOK(int, resource_setup_misc)
 XSM_HOOK(int, resource_setup_pci, uint32_t)
 XSM_HOOK(int, resource_setup_gsi, int)
 XSM_HOOK(int, pci_config_permission, struct domain *, uint32_t, uint16_t,
-                                     uint16_t, uint8_t)
+                                     uint16_t, bool)
 #endif
 
 #ifdef CONFIG_HYPFS
@@ -142,8 +142,8 @@ XSM_HOOK(int, mmuext_op, struct domain *
 XSM_HOOK(int, update_va_mapping, struct domain *, struct domain *, l1_pgentry_t)
 #endif /* CONFIG_PV */
 XSM_HOOK(int, priv_mapping, struct domain *, struct domain *)
-XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, uint8_t)
-XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, uint8_t)
+XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, bool)
+XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, bool)
 XSM_HOOK(int, pmu_op, struct domain *, unsigned int)
 #endif /* CONFIG_X86 */
 
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -998,7 +998,7 @@ static int cf_check flask_sysctl(const s
 }
 #endif /* CONFIG_SYSCTL */
 
-static inline uint32_t resource_to_perm(uint8_t access)
+static inline uint32_t resource_to_perm(bool access)
 {
     if ( access )
         return RESOURCE__ADD;
@@ -1166,7 +1166,7 @@ static int cf_check flask_unbind_pt_irq(
 }
 
 static int cf_check flask_irq_permission(
-    struct domain *d, int pirq, uint8_t access)
+    struct domain *d, int pirq, bool access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
     return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
@@ -1199,7 +1199,7 @@ static int cf_check _iomem_has_perm(
 }
 
 static int cf_check flask_iomem_permission(
-    struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+    struct domain *d, uint64_t start, uint64_t end, bool access)
 {
     struct iomem_has_perm_data data;
     int rc;
@@ -1221,16 +1221,17 @@ static int cf_check flask_iomem_permissi
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
-static int cf_check flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+static int cf_check flask_iomem_mapping(
+    struct domain *d, uint64_t start, uint64_t end, bool map)
 {
-    return flask_iomem_permission(d, start, end, access);
+    return flask_iomem_permission(d, start, end, map);
 }
 #define flask_iomem_mapping_vpci flask_iomem_mapping
 
 #ifdef CONFIG_HAS_PCI
 static int cf_check flask_pci_config_permission(
     struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end,
-    uint8_t access)
+    bool access)
 {
     uint32_t dsid, rsid;
     int rc = -EPERM;
@@ -1709,7 +1710,7 @@ static int cf_check _ioport_has_perm(
 }
 
 static int cf_check flask_ioport_permission(
-    struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+    struct domain *d, uint32_t start, uint32_t end, bool access)
 {
     int rc;
     struct ioport_has_perm_data data;
@@ -1733,9 +1734,9 @@ static int cf_check flask_ioport_permiss
 }
 
 static int cf_check flask_ioport_mapping(
-    struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+    struct domain *d, uint32_t start, uint32_t end, bool map)
 {
-    return flask_ioport_permission(d, start, end, access);
+    return flask_ioport_permission(d, start, end, map);
 }
 
 #ifdef CONFIG_MEM_SHARING



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:52:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:52:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392653.1631622 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt4e-000261-D8; Mon, 17 Aug 2026 08:52:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392653.1631622; Mon, 17 Aug 2026 08:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt4e-00025u-8Z; Mon, 17 Aug 2026 08:52:04 +0000
Received: by outflank-mailman (input) for mailman id 1392653;
 Mon, 17 Aug 2026 08:52:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt4d-00025k-E6
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:52:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt4c-00GMOB-RE
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:52:02 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cbb0-e002-0a2a0a5209dd-0a2a4502c5ea-8
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:52:02 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cbb2-6ca4-0a2a45020019-d155dd34ede4-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:52:02 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47ddf7b09e5so3185593f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:52:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7cd38sm2338219f8f.32.2026.08.17.01.52.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:52:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956722; x=1787561522; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=K2Unx129q4eX6PMvb4yv3itragzYIlcm4Wp+G/Yi98I=;
        b=L8XZFSbcoa2DGBjoFKPXeDoMPB61/F3oNkl4mlUfUzaUpWwsGo3mzY9HcNCY7GaWPg
         199juwsootLOVb90tGjrxwMGz/tfvHnKwXDNixlCkb4LwuMB8K77y8ciCBZc8vtaIDCM
         a5pHgf4qFQHyh7pibsqCjqyMz5J4QEfBxSrnbTjFRxvVSa6rlFrVpfNm81Yl1x4RFkdj
         JBjgOogQiVFvIQdupqpDjED23OLGzLTEnsT7cO5OgUglgDgIphshT2JtErZ1BRRsnFdp
         ehKiOWcz3sNOKe5apET+UOhsCNkuvUs6aHMFDX0YNOs6K3gWljO6Yw+5mgUPUNpf7Q67
         sPmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956722; x=1787561522;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=K2Unx129q4eX6PMvb4yv3itragzYIlcm4Wp+G/Yi98I=;
        b=IdbN07rpyhrRMQK+dps+jUZH3g/9/QZP3j1h6DQRlBlwdRrvs4S45WpC9nmGYDKtEW
         R4bCifRt4qM3+ovWdeS83NjdDoeHUJ6ohGU82weyIkhl4cgx8BRt0MAzeiKbFx+EZG5o
         zmFGjp5EkbWTh6fI5iUjAQDQvr7TeuqcIvBrt3n0OBKNoFtuUJdcgi8fQ9M6r8g9NJJN
         tWYv/Hoox63m+9NxIIxjGa9qTl4OQn5daQi5LLiqO5ZEgDyhNS3k/F6nr00xnf8KtlSp
         36AdpTHVZK9QUTmS7Dr16VfUsJ1Fje8hbkNaNupZfV1X+sP4JvkRZYfkSPmmhCSmxTrh
         Q1jg==
X-Gm-Message-State: AOJu0YwOM+He4Cp5EP6tdgBtserRXxURsn1LLglpaRCFi7va1/kJug75
	POUF8QSbPOZCObIGmvP5rReVfjqWOse2cgx8YRytsAkC6q9aNw1+WflngcDhWVkZF8NM4/hP/Yz
	OtN85pA==
X-Gm-Gg: AR+sD13D3fbF34G28gs+qj2EzOfP6+3y/RzC3Wz2l2y7SIBA6F90HVSrcEU1ezOEyh7
	jxzv023zRG4hwnngAeTZHVtArcpy3EexZpzdL6dHIjNRu/aTo/sCtEzGnH5Vwv6ZhCFdIjGU2UH
	L04IXR6EeUwjafgcMhN8fuIA6T01oXUbvhhe05t4dT2wAmQOAXxZ4ex300plC7fxlf6PmMOF6v3
	FQtT8I9PpAGznDV2S4bL5S5KAzMWDTp/VEy5ET56BYFq2+SUkNGmd/I6HYBw3JTUysUKVYe1oc6
	2r8DicYsc9CDuSTQY0dKEhEJb4Dh2U+br4Cd4/0DmURSrxJgciJOYivi7bFWncMNOpdnkJuMT6o
	A93Ylanxfwn2p3Lvn1r+FJ/+msGm4UdTAm+tgO2S+AEL8XhrPAg2DrGD7TVByUtHwabGnnyuydP
	iDEpJqyxEDBN2oKE7DXJGc/jU18/FUCLEOiUi++JWPoOk7apxITshgpi3EWlf+VDi4JpmzbiYuu
	vhVTUIFovczeEkmhwUsndUptcK6NLtFOG/76kb2uV51eZm8Lc7anQqgxhLIy8Y=
X-Received: by 2002:a05:6000:230f:b0:47f:f1ab:9075 with SMTP id ffacd0b85a97d-4816074ccd8mr32295966f8f.20.1786956722292;
        Mon, 17 Aug 2026 01:52:02 -0700 (PDT)
Message-ID: <4f7a34b6-b522-4d8f-a678-304ef4c0f916@suse.com>
Date: Mon, 17 Aug 2026 10:52:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 03/14] x86/mm: get_page_from_l1e() is PV-or-shadow-only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786956722-303C42AC-3D3C2DEA/0/0
X-purgate-type: clean
X-purgate-size: 3450

Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
With the function compiled out, its dedicated XSM hook also becomes
unreachable, so it is similarly guarded.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
It feels suspicious that the .priv_mapping() check is used for HVM guests
in shadow mode, but not for ones in HAP mode.
---
v2: Also conditionalize the declaration.

--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -404,10 +404,13 @@ int  get_page_type(struct page_info *pag
 int  put_page_type_preemptible(struct page_info *page);
 int  get_page_type_preemptible(struct page_info *page, unsigned long type);
 int  put_old_guest_table(struct vcpu *v);
-int  get_page_from_l1e(
-    l1_pgentry_t l1e, struct domain *l1e_owner, struct domain *pg_owner);
 void put_page_from_l1e(l1_pgentry_t l1e, struct domain *l1e_owner);
 
+#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
+int get_page_from_l1e(
+    l1_pgentry_t l1e, struct domain *l1e_owner, struct domain *pg_owner);
+#endif
+
 static inline struct page_info *get_page_from_mfn(mfn_t mfn, struct domain *d)
 {
     struct page_info *page = mfn_to_page(mfn);
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -836,6 +836,8 @@ static int cf_check print_mmio_emul_rang
 }
 #endif
 
+#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
+
 /*
  * get_page_from_l1e returns:
  *   0  => success (page not present also counts as such)
@@ -1037,6 +1039,8 @@ get_page_from_l1e(
     return -EBUSY;
 }
 
+#endif /* CONFIG_PV || CONFIG_SHADOW_PAGING */
+
 /*
  * The following flags are used to specify behavior of various get and
  * put commands.  The first is also stored in page->partial_flags to
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -701,12 +701,14 @@ static XSM_INLINE int xsm_update_va_mapp
 
 #endif /* CONFIG_PV */
 
+#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
 static XSM_INLINE int xsm_priv_mapping(
     XSM_DEFAULT_ARG struct domain *d, struct domain *t)
 {
     XSM_ASSERT_ACTION(XSM_TARGET);
     return xsm_default_action(action, d, t);
 }
+#endif
 
 static XSM_INLINE int xsm_ioport_permission(
     XSM_DEFAULT_ARG struct domain *d, uint32_t s, uint32_t e, bool allow)
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -141,7 +141,9 @@ XSM_HOOK(int, mmu_update, struct domain
 XSM_HOOK(int, mmuext_op, struct domain *, struct domain *)
 XSM_HOOK(int, update_va_mapping, struct domain *, struct domain *, l1_pgentry_t)
 #endif /* CONFIG_PV */
+#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
 XSM_HOOK(int, priv_mapping, struct domain *, struct domain *)
+#endif
 XSM_HOOK(int, ioport_permission, struct domain *, uint32_t, uint32_t, bool)
 XSM_HOOK(int, ioport_mapping, struct domain *, uint32_t, uint32_t, bool)
 XSM_HOOK(int, pmu_op, struct domain *, unsigned int)
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1829,10 +1829,12 @@ static int cf_check flask_update_va_mapp
 
 #endif /* CONFIG_PV */
 
+#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING)
 static int cf_check flask_priv_mapping(struct domain *d, struct domain *t)
 {
     return domain_has_perm(d, t, SECCLASS_MMU, MMU__TARGET_HACK);
 }
+#endif
 
 static int cf_check flask_pmu_op(struct domain *d, unsigned int op)
 {



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:52:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:52:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392659.1631629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt53-0002YX-JK; Mon, 17 Aug 2026 08:52:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392659.1631629; Mon, 17 Aug 2026 08:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt53-0002YQ-GL; Mon, 17 Aug 2026 08:52:29 +0000
Received: by outflank-mailman (input) for mailman id 1392659;
 Mon, 17 Aug 2026 08:52:28 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt52-0002X2-95
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:52:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt51-002rSu-MA
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:52:27 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cbc5-8faa-0a2a0a5109dd-0a2a450c89e0-18
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:52:27 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cbcb-f479-0a2a450c0019-d155802ea579-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:52:27 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-495437bb891so28915185e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:52:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d06167csm23897685e9.3.2026.08.17.01.52.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:52:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956747; x=1787561547; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=hicPJ0lkpk7PVJS0MRWq/kXZnKXC4WFY9rX0q730ZTg=;
        b=Q18UK3pnmIklxtKxthIIrwZG+DAxCyxYHogHDQOlKRSfw+F3JrX1eae3vEEIQTyzWQ
         TePOmpjok13S+I4aBWj/c9AgsxjB0j1cN+MdrRyVtAbDxC8jlavsYx0eg9rCIoEyOMQT
         uFee7zo2XkaQPfdOrBPPMiCThTYt5StEWOzdDeJ/m7cS+ZVtbU7u1G3LJCGPzCOsmxGN
         Cx3YqGa5G7zb5XrECPdNwb6LB7xM2wnRZFPC5oq/8NcS+LkPttjLDAIH6GfMchS5GLGL
         2DIPXPJ807ngKDNOD7uTtU/tm7kNcTmy7IZMVIIyY7vmKwzdF7QRggUSspCiw0H30z/x
         JIEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956747; x=1787561547;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=hicPJ0lkpk7PVJS0MRWq/kXZnKXC4WFY9rX0q730ZTg=;
        b=nQ+CYMUktopTBTnzUjSD83fiKIeUUprHqpcJPFE/SmFrxOKos54wR2dW5GrICkk8m5
         DyUiXIffQ2xHBOGT8CqUmbuCJn1KZPzBvbelTZFYTGSHXxVWA5jSF7K0zhN6qZnCUEoi
         rgXMq4fFeBLcBPlKWPju8awP0u87ig1u2pqkNeOdFsKlJHRSKFvfpK4pcEZi6/nfU13z
         AWSK71bYSajx2366gVsYqVUtx1r6l1LbwgcBK889hMYhwAz1dKF4di3EOmozPl1SnrPv
         nMO9rR3o7lGXesh6evROLHXulRhjjJOUEDHouNM/1XDTSJHfxd6D+EJEcARySslWmzwU
         hHIg==
X-Gm-Message-State: AOJu0Yz/S1cg3LX3N2Z3GYbejFCl6BsyDGCmPfXzuYICz/68rOWIDk+Z
	3yyFGkzBoiI3iw9k/LwoVnHYZH1H+R3Wf791dnM6NkUd9gg3yUV50O72QsdO3RnvlpsrgJNrfrH
	f/P4yyA==
X-Gm-Gg: AR+sD10Wf3Q2TxSb/0P//3baopwYEqeJRRZRoKKZ5JAz0jcfqmfOMlhP37LTX+VMKr9
	8pCEF8t8uU3x5/GpowQFkpkoNDcmhEPicaaLLV/t9UO+8e1z1Ze/2jMuuhTgGSlwl/n6tQKIBYd
	iHLrwjf7zlKwkQ68uUunUlGiwXxtchQ3CdTUDvASd0WfehGTdbE1nWEyIGZnZ48X8Tqqn9/ap1g
	Elq5CYxiReM5PGMYySxUt931rEE3r1saGp7SmCAFomBzW8Nzv0nRPnGm/GpnsglhRJCXfYDcmap
	tRFDdiKs5m44N5b//h7R7SEN3E/ziaOFoQGGJlrQp7WYefCA3YUvyV3YGs+8w3J+A2PWTdPP2zE
	AjU2hfwBEJKoih8UN7VZVwCt5ss/ZOgWBBUi20ymQ7L8CBD3nmGdoivkKB5yTFtEz4aodivYhB6
	wccv++SL+9xn1xDH5yNziPcYfgH+TYOCFmJyTfYFekty0VqqpnmowJSl7AtlqvEvLjvhMsPZjxi
	mtGbfWvYFvgAOfaUBW3lN4zuKawqS7JFbLTD393sJyCzwCgd2Xs3D14ZIuimVc=
X-Received: by 2002:a05:600c:5643:b0:499:77ba:4b6 with SMTP id 5b1f17b1804b1-49987ad988emr253624925e9.9.1786956747083;
        Mon, 17 Aug 2026 01:52:27 -0700 (PDT)
Message-ID: <664d2a63-2745-4c33-9748-283aefce2433@suse.com>
Date: Mon, 17 Aug 2026 10:52:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 04/14] x86: restrict PHYSDEVOP_* when PV=n
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1786956747-026DEA5B-B044AD98/0/0
X-purgate-type: clean
X-purgate-size: 4589

hvm_physdev_op() permits through only a subset of sub-ops. The code
handling other sub-ops is therefore unreachable when PV=n, violating MISRA
C:2012 rule 2.1. With that the XSM .apic() hook also becomes unreachable /
dead when PV=n.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
At least for the sub-ops using xsm_apic() IS_ENABLED() cannot be used.
Therefore #ifdef is used throughout.
---
v2: Re-base over re-ordering of series.

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -233,6 +233,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+#ifdef CONFIG_PV
+
     case PHYSDEVOP_pirq_eoi_gmfn_v2:
     case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
@@ -281,6 +283,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+#endif /* CONFIG_PV */
+
     case PHYSDEVOP_irq_status_query: {
         struct physdev_irq_status_query irq_status_query;
         ret = -EFAULT;
@@ -379,6 +383,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+#ifdef CONFIG_PV
+
     case PHYSDEVOP_apic_read: {
         struct physdev_apic apic;
         ret = -EFAULT;
@@ -526,6 +532,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+#endif /* CONFIG_PV */
+
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
@@ -560,6 +568,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+#ifdef CONFIG_PV
+
     case PHYSDEVOP_restore_msi: {
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
@@ -591,6 +601,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+#endif /* CONFIG_PV */
+
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
@@ -610,6 +622,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
                               setup_gsi.polarity);
         break; 
     }
+
     case PHYSDEVOP_get_free_pirq: {
         struct physdev_get_free_pirq out;
 
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -644,13 +644,6 @@ static XSM_INLINE int xsm_mem_sharing_op
     return xsm_default_action(action, current->domain, cd);
 }
 
-static XSM_INLINE int xsm_apic(
-    XSM_DEFAULT_ARG struct domain *d, int cmd)
-{
-    XSM_ASSERT_ACTION(XSM_PRIV);
-    return xsm_default_action(action, d, NULL);
-}
-
 static XSM_INLINE int xsm_machine_memory_map(XSM_DEFAULT_VOID)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
@@ -666,6 +659,13 @@ static XSM_INLINE int xsm_domain_memory_
 
 #ifdef CONFIG_PV
 
+static XSM_INLINE int xsm_apic(
+    XSM_DEFAULT_ARG struct domain *d, int cmd)
+{
+    XSM_ASSERT_ACTION(XSM_PRIV);
+    return xsm_default_action(action, d, NULL);
+}
+
 static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
 {
     XSM_ASSERT_ACTION(XSM_PRIV);
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -131,10 +131,10 @@ XSM_HOOK(int, mem_sharing_op, struct dom
 XSM_HOOK(int, platform_op, uint32_t)
 
 #ifdef CONFIG_X86
-XSM_HOOK(int, apic, struct domain *, int)
 XSM_HOOK(int, machine_memory_map)
 XSM_HOOK(int, domain_memory_map, struct domain *)
 #ifdef CONFIG_PV
+XSM_HOOK(int, apic, struct domain *, int)
 XSM_HOOK(int, do_mca)
 XSM_HOOK(int, mmu_update, struct domain *, struct domain *, struct domain *,
                           uint32_t)
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1750,6 +1750,19 @@ static int cf_check flask_mem_sharing_op
 }
 #endif
 
+static int cf_check flask_machine_memory_map(void)
+{
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP,
+                                NULL);
+}
+
+static int cf_check flask_domain_memory_map(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
+}
+
+#ifdef CONFIG_PV
+
 static int cf_check flask_apic(struct domain *d, int cmd)
 {
     uint32_t perm;
@@ -1770,18 +1783,6 @@ static int cf_check flask_apic(struct do
     return domain_has_xen(d, perm);
 }
 
-static int cf_check flask_machine_memory_map(void)
-{
-    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
-}
-
-static int cf_check flask_domain_memory_map(struct domain *d)
-{
-    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
-}
-
-#ifdef CONFIG_PV
-
 static int cf_check flask_do_mca(void)
 {
     return domain_has_xen(current->domain, XEN__MCA_OP);



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:53:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:53:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392668.1631640 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt5g-00032y-S8; Mon, 17 Aug 2026 08:53:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392668.1631640; Mon, 17 Aug 2026 08:53:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt5g-00032q-OA; Mon, 17 Aug 2026 08:53:08 +0000
Received: by outflank-mailman (input) for mailman id 1392668;
 Mon, 17 Aug 2026 08:53:07 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt5f-00032Y-1Q
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:53:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt5e-00D2zY-EY
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:53:06 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cbed-2eae-0a2a0a5409dd-0a2a450bdbc8-28
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:53:06 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cbf2-b7e8-0a2a450b0019-d155802bac30-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:53:06 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-495590dde14so38912005e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:53:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996183b89sm157259195e9.12.2026.08.17.01.53.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:53:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956786; x=1787561586; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=yG72bC7P9bK/t0BCXT48RBUcpJmBlidVDBFgV61UuIM=;
        b=SA8/kGTH9IlTOzeDdqpJrhKbFKgq5u/9PG9qe2xOLx+CbJeSO2mpVU6pX9eWnN8UAb
         b/6FRvs8woGtHUrzGeuSyscxzbr82ecLhYM2AwPgpJUmf72n2pQY0KmDn4t4IdNiFvcM
         9Hiei/njh6UVNjnKJzGLu4rlaLQWV8Y6jl94odPDiRgbtVsGp9T8pEcFUjfGsOupFCJK
         SDEYOkLMAuEAZXfX2WhtSlyFZV9QhSMY3CSoRhhbakQUgv5DOy4WDV4eZdHDT5ytowJp
         G/mcUBcukc/v29F2uDM55C7ke0IkbdLifBmY3Qnj/OiFzOyibkmXWT8gVt1+KzZm3NvG
         iVfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956786; x=1787561586;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=yG72bC7P9bK/t0BCXT48RBUcpJmBlidVDBFgV61UuIM=;
        b=eeOm372wa/2/OdYWzCUk7EsrsWrBQ5PHwshdQbEAoHp6ZZcBxooUwsnOlYc76B3VEQ
         h0uJGP5+Zi5bcK/0iQ6mhKmSZ/9X+xk+mzhH4yYTSplmmy8Auij2qv8JMILvUO+Bgevk
         jZ2nBW1mSdWq3UKh6WVoCD/818RX0VmAYtaW2v/s1HZ6aGgEHZhTMcPZlOHUt4Vgo98h
         Gof1gCbvVUmdht6hGdxDg2O/LzmZQPhRr48FGndVeK5OEtenqZ7639qkJyX59TKZF77i
         q9brxTS/qArY2f3J4vO9tfCD5JJRLpV8VoGkzM9fRplqSg/rqeYTpAr60pD+l3ZRe2/C
         AwpQ==
X-Gm-Message-State: AOJu0YwRcriih+R6oa2gKVmEOoCwcBJIkDUDk34hDY0ieAmklTlOKzv6
	MTAtcwjZyb6MhMLk44EjrPUzvwczWjWgQi+N8XUBXZ3AFYtkFIKMmWUc6UwkJkxYl3giFU26Cak
	rITcfVg==
X-Gm-Gg: AR+sD131ZZx6FCzSmVn/3P5czIjlF3UQslISQlwUITqw3WqUg92YtiusnC22d/508yf
	Iysld0eS7soNcDlhbPJyaXH39gbAWPeRvEFAa6C/VDENa/Qu6DxJj4zcwzrABD7pxG4XvXkfiK0
	orYZBxsqXdshYihRfOHBuYdvrNkwTGweaMet7Zm+/joq+n5VuJutFcedeUS0RhB9BS38UylyRw2
	kt6rtnYhWHxtTJqwhofHObWN4LID2ZyyjDKr/5xY7wfrVa7WocuG9x3sgoSQ6MEp0Zl6XxMoEr1
	DEd5tNZ3OYyx4K+IPtpUysTGrLw/S2NbKbnKG5kTVaZ+KXZ6ChhmtZrBCoG+7sjaDOayi6+H4R/
	lb8C07zF4NrsifPsAz/ytaH+5e2VFjmQQtOm7qYwGZ9Ky1xn/HVLmrmYORmW3VEI8sUUfvW39f6
	xvHRlIyWgHMPou/0QUJi0K+6SoBzo6w+eE7xsjmStriluIhW2L9wSu2+kb3jyGhpWA5paxNMTnn
	QorCn2eNaoGeZ6+lvVqvFHxPSo3Nq9o5ZMlOaUZE2WT6/VXvLj+
X-Received: by 2002:a05:600c:4754:b0:499:7e2b:8e5 with SMTP id 5b1f17b1804b1-4999a2f9ec3mr69341345e9.5.1786956785706;
        Mon, 17 Aug 2026 01:53:05 -0700 (PDT)
Message-ID: <e73894ff-7ef7-4db0-9d91-45870b0d3c83@suse.com>
Date: Mon, 17 Aug 2026 10:53:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 05/14] XSM: make Argo hooks well-formed ones
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Jason Andryuk <jason.andryuk@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786956786-A88C99EA-BF76762A/0/0
X-purgate-type: clean
X-purgate-size: 7573

For whatever reason they didn't have an xsm_default_t first argument (to
cope with XSM=n mode), making it impossible to (easily) cover them in
xsm/hooks.h.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
---
v2: Drop uses of current->domain from dummy handlers. Move const-ification
    in xsm_default_action() to a separate patch. Re-base over re-ordering
    of series.

--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -1341,7 +1341,7 @@ fill_ring_data(const struct domain *curr
      * Don't supply information about rings that a guest is not
      * allowed to send to.
      */
-    ret = xsm_argo_send(currd, dst_d);
+    ret = xsm_argo_send(XSM_HOOK, currd, dst_d);
     if ( ret )
         goto out;
 
@@ -1666,8 +1666,9 @@ register_ring(struct domain *currd,
 
     if ( reg.partner_id == XEN_ARGO_DOMID_ANY )
     {
-        ret = opt_argo_mac_permissive ? xsm_argo_register_any_source(currd) :
-                                        -EPERM;
+        ret = opt_argo_mac_permissive
+              ? xsm_argo_register_any_source(XSM_HOOK, currd)
+              : -EPERM;
         if ( ret )
             return ret;
     }
@@ -1680,7 +1681,7 @@ register_ring(struct domain *currd,
             return -ESRCH;
         }
 
-        ret = xsm_argo_register_single_source(currd, dst_d);
+        ret = xsm_argo_register_single_source(XSM_HOOK, currd, dst_d);
         if ( ret )
             goto out;
 
@@ -2002,7 +2003,7 @@ sendv(struct domain *src_d, xen_argo_add
     if ( !dst_d )
         return -ESRCH;
 
-    ret = xsm_argo_send(src_d, dst_d);
+    ret = xsm_argo_send(XSM_HOOK, src_d, dst_d);
     if ( ret )
     {
         gprintk(XENLOG_ERR, "argo: XSM REJECTED %i -> %i\n",
@@ -2100,7 +2101,7 @@ do_argo_op(unsigned int cmd, XEN_GUEST_H
     if ( unlikely(!opt_argo) )
         return -EOPNOTSUPP;
 
-    rc = xsm_argo_enable(currd);
+    rc = xsm_argo_enable(XSM_HOOK, currd);
     if ( rc )
         return rc;
 
@@ -2242,7 +2243,7 @@ compat_argo_op(unsigned int cmd, XEN_GUE
     if ( unlikely(!opt_argo) )
         return -EOPNOTSUPP;
 
-    rc = xsm_argo_enable(currd);
+    rc = xsm_argo_enable(XSM_HOOK, currd);
     if ( rc )
         return rc;
 
@@ -2307,7 +2308,7 @@ argo_init(struct domain *d)
 {
     struct argo_domain *argo;
 
-    if ( !opt_argo || xsm_argo_enable(d) )
+    if ( !opt_argo || xsm_argo_enable(XSM_HOOK, d) )
     {
         argo_dprintk("argo disabled, domid: %u\n", d->domain_id);
         return 0;
@@ -2365,8 +2366,8 @@ argo_soft_reset(struct domain *d)
         wildcard_rings_pending_remove(d);
 
         /*
-         * Since neither opt_argo or xsm_argo_enable(d) can change at runtime,
-         * if d->argo is true then both opt_argo and xsm_argo_enable(d) must be
+         * Since neither opt_argo nor xsm_argo_enable() can change at runtime,
+         * if d->argo is true then both opt_argo and xsm_argo_enable() must be
          * true, and we can assume that init is allowed to proceed again here.
          */
         argo_domain_init(d->argo);
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -751,27 +751,32 @@ static XSM_INLINE int xsm_dm_op(XSM_DEFA
 #endif
 
 #ifdef CONFIG_ARGO
-static XSM_INLINE int xsm_argo_enable(const struct domain *d)
+
+static XSM_INLINE int xsm_argo_enable(XSM_DEFAULT_ARG const struct domain *d)
 {
-    return 0;
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, d, NULL);
 }
 
 static XSM_INLINE int xsm_argo_register_single_source(
-    const struct domain *d, const struct domain *t)
+    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
 {
-    return 0;
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, d, t);
 }
 
 static XSM_INLINE int xsm_argo_register_any_source(
-    const struct domain *d)
+    XSM_DEFAULT_ARG const struct domain *d)
 {
-    return 0;
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, d, NULL);
 }
 
 static XSM_INLINE int xsm_argo_send(
-    const struct domain *d, const struct domain *t)
+    XSM_DEFAULT_ARG const struct domain *d, const struct domain *t)
 {
-    return 0;
+    XSM_ASSERT_ACTION(XSM_HOOK);
+    return xsm_default_action(action, d, t);
 }
 
 #endif /* CONFIG_ARGO */
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -161,6 +161,14 @@ XSM_HOOK(int, do_xsm_op, XEN_GUEST_HANDL
 XSM_HOOK(int, do_compat_op, XEN_GUEST_HANDLE_PARAM(void))
 #endif
 
+#ifdef CONFIG_ARGO
+XSM_HOOK(int, argo_enable, const struct domain *)
+XSM_HOOK(int, argo_register_single_source, const struct domain *,
+                                           const struct domain *)
+XSM_HOOK(int, argo_register_any_source, const struct domain *)
+XSM_HOOK(int, argo_send, const struct domain *, const struct domain *)
+#endif
+
 #undef XSM_HOOK0
 #undef XSM_HOOK1
 #undef XSM_HOOK2
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -85,14 +85,6 @@ struct xsm_ops {
     char *(*show_security_evtchn)(struct domain *d, const struct evtchn *chn);
 
     char *(*show_irq_sid)(int irq);
-
-#ifdef CONFIG_ARGO
-    int (*argo_enable)(const struct domain *d);
-    int (*argo_register_single_source)(const struct domain *d,
-                                       const struct domain *t);
-    int (*argo_register_any_source)(const struct domain *d);
-    int (*argo_send)(const struct domain *d, const struct domain *t);
-#endif
 };
 
 #ifdef CONFIG_XSM
@@ -196,30 +188,6 @@ static inline char *xsm_show_irq_sid(int
     return alternative_call(xsm_ops.show_irq_sid, irq);
 }
 
-#ifdef CONFIG_ARGO
-static inline int xsm_argo_enable(const struct domain *d)
-{
-    return alternative_call(xsm_ops.argo_enable, d);
-}
-
-static inline int xsm_argo_register_single_source(
-    const struct domain *d, const struct domain *t)
-{
-    return alternative_call(xsm_ops.argo_register_single_source, d, t);
-}
-
-static inline int xsm_argo_register_any_source(const struct domain *d)
-{
-    return alternative_call(xsm_ops.argo_register_any_source, d);
-}
-
-static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
-{
-    return alternative_call(xsm_ops.argo_send, d, t);
-}
-
-#endif /* CONFIG_ARGO */
-
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -35,13 +35,6 @@ static const struct xsm_ops __initconst_
     .show_security_evtchn          = xsm_show_security_evtchn,
 
     .show_irq_sid                  = xsm_show_irq_sid,
-
-#ifdef CONFIG_ARGO
-    .argo_enable                   = xsm_argo_enable,
-    .argo_register_single_source   = xsm_argo_register_single_source,
-    .argo_register_any_source      = xsm_argo_register_any_source,
-    .argo_send                     = xsm_argo_send,
-#endif
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1972,13 +1972,6 @@ static const struct xsm_ops __initconst_
     .show_security_evtchn = flask_show_security_evtchn,
 
     .show_irq_sid = flask_show_irq_sid,
-
-#ifdef CONFIG_ARGO
-    .argo_enable = flask_argo_enable,
-    .argo_register_single_source = flask_argo_register_single_source,
-    .argo_register_any_source = flask_argo_register_any_source,
-    .argo_send = flask_argo_send,
-#endif
 };
 
 const struct xsm_ops *__init flask_init(



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:53:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:53:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392677.1631649 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt6E-0003ZJ-7g; Mon, 17 Aug 2026 08:53:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392677.1631649; Mon, 17 Aug 2026 08:53:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt6E-0003ZC-41; Mon, 17 Aug 2026 08:53:42 +0000
Received: by outflank-mailman (input) for mailman id 1392677;
 Mon, 17 Aug 2026 08:53:41 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt6D-0003Z0-0w
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:53:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt6B-002rjM-Ox
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:53:39 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc03-bab6-0a2a0a5309dd-0a2a45018c1e-36
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:53:39 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc13-5984-0a2a45010019-d155802bf15e-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:53:39 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so36449895e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:53:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d063a68sm21461775e9.2.2026.08.17.01.53.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:53:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956819; x=1787561619; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=tEmpas18PFX7DYvL8q0Gls2b5mj4VJSxRmZe4a/2YYU=;
        b=g5lNjz8PGPpAkSmHydPPNTtB8oBTtVUukxo1pAfiFXldLSHeK1NBIxg2WuPTJNdaOB
         4AMgaNiHAFHuMUEW+j9EAmqyBFJHtx5CoJ3HnR2aMuH0d53iLz1TLtWh++JMpix2EOG/
         SYoUp69KCZe6j7hyiY3fcx+nvf7F2gQWTqJiEedVIvr8Vg6np6kdkIs+UtQ50G98SeHl
         mJJBpnAaCQSZss+we5NXwCOVm1Pne58VJMlcI45d50SfMwwJ4HKj750Ho5tccOjj1ReZ
         8B1HA9ZPN/KChkDC2i4EwKTwwWfQlwLH10weRtpdn3BOpaI0/2lAAKGGhHA4jLcacosk
         bdCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956819; x=1787561619;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=tEmpas18PFX7DYvL8q0Gls2b5mj4VJSxRmZe4a/2YYU=;
        b=sdwHc2uLNoZ97EdMxHCcquj8Xa/xaGpkPd53bAi1AzgSBnHybeXtVB2cXlOnIy14Td
         bkjvrXvxYUl70DJhwOnqPF4o0NojOXI1Pmq7a8doRBCegQKXjGjvnphL/kW6DEviZ7ae
         IGSEhUXm8uLxR75h76MGeb+7wUA8Kwf5smSFJwsb7dlLsDSz086/dmkmkspdjpvdkF57
         HX3DEboXor/UEuO8701AprwZtizyLGOIeyVpXcoGab8T96sRgkNmVnKRp0j/FbAUBv0j
         UDq+hZNYGepmS2+pEqq7hJWVhAG33oXFRAenjA0q8mQSMnyDFw01sJOCDEd/inrr3YNT
         DItw==
X-Gm-Message-State: AOJu0YyNHMTFEQtPP1eMwveZa4teJHj2NQA1G+vuy54ceWP7fnbxhlR5
	YDRWB5gnRCsW6MXY6VruDRbQ6fD6bSuY61ygfniKVZy5yhfnltpg1PBKDK41Ir7/fF+wycF6XPG
	0QNO0dg==
X-Gm-Gg: AR+sD1250wEwWtHkY8vv+xv2riaSycMNEy0DCo+qju/6dqKgH3fNUfm8pXzwNJp6KGn
	l5zfuhMapKWcsFXX5Rtf6PmydKDtZRBjP8mYGTiEHqSrTLQqZDpZFA7N7QNP/lgFNMfxFp3lbW+
	ykiTGGOrWcF1j7JLKIYk1d9DroE8NM5dF/vo2z+qkChjOizreKEFeXJ996d9kK4AxbM8OOqpwOX
	RQn6l9/AMshUqgv+55JXAKxZYj/58yvhRplsq0Ftky+V8kyiH+T6xRrJYjV7YDmPQtizyxoDUzJ
	h6KTfzlSqsUjBFs1lHyG988Tf+1lnHsNBD9mDbs3V010iU3esVE6aYgB3M1Ae472SgQK7SzziOT
	8Qc63p6hfkRdOv92MC5GMiGEns4jE8aynhvEaRb4GTxQNwnNB1+Ddoc1KFqrWtsMYiC/ZvdvhBl
	bybuHJJ27C3iXoyBwOLYp/Mk7MSEs26mpBYG9LtSYjqgIopX0geSYAZBW67VvRbdB2JqChzVSEw
	x0T7EgM4OMzZVhepOKybfI3rkklnk9XM9MPC5f7lY3sHgggryl2
X-Received: by 2002:a05:600c:3b23:b0:499:8ae1:b900 with SMTP id 5b1f17b1804b1-4998ae1bb69mr276680605e9.12.1786956819212;
        Mon, 17 Aug 2026 01:53:39 -0700 (PDT)
Message-ID: <236a8612-d431-4972-92b3-4d62e8f10bb4@suse.com>
Date: Mon, 17 Aug 2026 10:53:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 06/14] XSM: fold xsm_{,un}map_domain_pirq() hooks
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786956819-1F66C757-D5D940F0/0/0
X-purgate-type: clean
X-purgate-size: 2676

Like other resource management hooks they are different in just "add
resource" vs "remove resource". Hence like in other cases a single hook
can easily serve both purposes. Rename hook and functions to fit
xsm_io{mem,port}_mapping().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Rename hook, functions, and new parameter.

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -109,7 +109,7 @@ int physdev_map_pirq(struct domain *d, i
         return physdev_hvm_map_pirq(d, type, index, pirq_p);
     }
 
-    ret = xsm_map_domain_pirq(XSM_DM_PRIV, d);
+    ret = xsm_pirq_mapping(XSM_DM_PRIV, d, true);
     if ( ret )
         return ret;
 
@@ -142,7 +142,7 @@ int physdev_unmap_pirq(struct domain *d,
     int ret = 0;
 
     if ( d != current->domain || !is_hvm_domain(d) || !has_pirq(d) )
-        ret = xsm_unmap_domain_pirq(XSM_DM_PRIV, d);
+        ret = xsm_pirq_mapping(XSM_DM_PRIV, d, false);
     if ( ret )
         return ret;
 
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -460,15 +460,8 @@ static XSM_INLINE char *xsm_show_irq_sid
 
 #ifdef CONFIG_HAS_PIRQ
 
-static XSM_INLINE int xsm_map_domain_pirq(
-    XSM_DEFAULT_ARG struct domain *d)
-{
-    XSM_ASSERT_ACTION(XSM_DM_PRIV);
-    return xsm_default_action(action, current->domain, d);
-}
-
-static XSM_INLINE int xsm_unmap_domain_pirq(
-    XSM_DEFAULT_ARG struct domain *d)
+static XSM_INLINE int xsm_pirq_mapping(
+    XSM_DEFAULT_ARG struct domain *d, bool map)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -68,8 +68,7 @@ XSM_HOOK(int, kexec)
 XSM_HOOK(int, schedop_shutdown, struct domain *, struct domain *)
 
 #ifdef CONFIG_HAS_PIRQ
-XSM_HOOK(int, map_domain_pirq, struct domain *)
-XSM_HOOK(int, unmap_domain_pirq, struct domain *)
+XSM_HOOK(int, pirq_mapping, struct domain *, bool)
 #endif
 
 XSM_HOOK(int, map_domain_irq, struct domain *, int, const void *)
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
 
 #ifdef CONFIG_HAS_PIRQ
 
-static int cf_check flask_map_domain_pirq(struct domain *d)
+static int cf_check flask_pirq_mapping(struct domain *d, bool map)
 {
-    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
-}
-
-static int cf_check flask_unmap_domain_pirq(struct domain *d)
-{
-    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(map));
 }
 
 #endif /* CONFIG_HAS_PIRQ */



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:54:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:54:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392684.1631656 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt6l-00042z-Eq; Mon, 17 Aug 2026 08:54:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392684.1631656; Mon, 17 Aug 2026 08:54:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt6l-00042s-C9; Mon, 17 Aug 2026 08:54:15 +0000
Received: by outflank-mailman (input) for mailman id 1392684;
 Mon, 17 Aug 2026 08:54:13 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt6j-00042b-Px
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:54:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt6j-00G9eg-6a
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:54:13 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc34-e002-0a2a0a5209dd-0a2a450180da-4
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:54:13 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc34-5984-0a2a45010019-d155dd2bc8a8-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:54:13 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-480033bdcf4so1813602f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:54:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a7168bbesm601201f8f.0.2026.08.17.01.54.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:54:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956852; x=1787561652; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=31bEzBE374yqE4es14uilqJ/7IGdLVYHPRoJ2VGKJ8Y=;
        b=WXt+b+gYYg4YFkF2fWb0JmKsSl1WVwET5afkOCkxhzw8f5MB21g4p4toYiq7QeUWog
         3j/XPqd+TzC4Fntgo+JOMXasBY30f6lEk3K4itisvwA25nN/dlhiwSVmXgJwlvbXGdbr
         mG9DtFwbea1GXd50meUJYBrCHERb1vP9JW4Em4gnri5mcdbRuNq43X71nP72BtyqpVOW
         /aJTczmMN5RsuFL24c5NKvi3ENsCcjThatKb6UzE0L6T4dXMra8EUPVnwrffl7QiLwJl
         2lf1Bnmadouq1U+F6RvcSFexf/SEmaY6tSsj13eiIYBMp99G8SGL6JkOR6Bm5DNF1P9R
         6DEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956852; x=1787561652;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=31bEzBE374yqE4es14uilqJ/7IGdLVYHPRoJ2VGKJ8Y=;
        b=bsoBDI61SGBFUVWW3W1LRHGcOzRlCd61ZufOD0tDGFFAz53aBt/jG1g/h4v9zQQ8r8
         XD3FJpQ1nFQiIi+mepgCQ9X8we8NodA6kLb+fbhjolELg/LFJxO/DVbEF1odabv0E8xX
         dYnlm1F4oRBM+QPulY82r+Bv0e/YUYmwTKDhjminDhBUHEnRZ3LpyO8Qo/XcbCYKFZX2
         CqHvlVBoaqe6JWhwqx46uuphVQUCfekOFhjy57eBtNfeHvl5KSVP8lLCDb3Xl85roU7K
         eO5bmEy5eVVwyAR4hLLQt99JELoq8DSXglWjwD6q047tXU/xPQP4tDwIostqpq/nWSG6
         hROA==
X-Gm-Message-State: AOJu0Yx0iPtoNKPGniYfxgmmE2CgmipyQOBeX0tzprKYBHiY4zfIg+uI
	EARdQEaMIOrKABttu7xlkXYYZ9tZf2yhlIuyvXIL3o49KPBQoIXkZg/1JP0aldxd5ru9rN+siNM
	ytFRfEA==
X-Gm-Gg: AR+sD13gM5RkO3e1mtfJ0WIkkZgEyhRnphTcn9XBvuFIW4DDTb3fiXDk3qMllhZq5Q8
	yIyWxftT6MjsJYQlcQPpTCHTgIy+ZgS5DCnwyZWpyOAF8ex6N+5wZ2+jRYzMNT7pmHmWtGF3Xbn
	pOYGKCDAjmYGQu/fb/Akzoni4S0shQ5o9f8jn/VSdwaZgEORbGYKCfxT3dk//IuPAT2U5GIRCFd
	lt7l+aqihuG42b+D99cm1BZVH3XH4nFaGW8mI+Sc6iOVBSVFZNaJR4GROyRgavDvvDDSjne0SRx
	fj2XdETcV6n7LVBJr1XCa1ychZcs7ZXhJnwXEdIjld5mBXJEv7WaouUOvvE1kDbFvj8vdKa2IYW
	n8WzYR7tuRVSHLz8RJnE9uE4RikghFvHtGSr+khWuVGhitS9g+qOQdNvVo7ADVWaMRf5H0vWbfB
	/nDm1AjaP+O2mhSIgroQsiaBYW0dolkonSNuuIGOyWA9Sg3VwWhBx64LoYCV78bYKu8uuJjak79
	nrpeXergiQ5kRXKzm3WTcQflwWa+XMv8Cm7XpGx1iSoght7ujCd
X-Received: by 2002:a05:6000:46db:b0:47f:7759:89df with SMTP id ffacd0b85a97d-4816071004bmr28042923f8f.3.1786956852540;
        Mon, 17 Aug 2026 01:54:12 -0700 (PDT)
Message-ID: <3c118229-c591-4f5a-afe5-7a2e95fbbdac@suse.com>
Date: Mon, 17 Aug 2026 10:54:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 07/14] x86: type-correct last parameter of
 map_domain_pirq()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786956853-BC359757-19041175/0/0
X-purgate-type: clean
X-purgate-size: 2091

This was meant to allow for non-MSI data to be passed if necessary, but
the way XSM/Flask uses the (propagated) argument that's not going to work
anyway without further adjustments. As no secondary use has surfaced in
many years, switch to using the correct type.

Leave XSM alone, as that'll be changed subsequently anyway (to then also
no longer use plain void).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -27,6 +27,7 @@ typedef struct {
 } vmask_t;
 
 struct irq_desc;
+struct msi_info;
 
 /*
  * Xen logic for moving interrupts around CPUs allows manipulating interrupts
@@ -161,7 +162,7 @@ struct arch_pirq {
 int pirq_shared(struct domain *d , int pirq);
 
 int map_domain_pirq(struct domain *d, int pirq, int irq, int type,
-                           void *data);
+                    struct msi_info *msi);
 int unmap_domain_pirq(struct domain *d, int pirq);
 int get_free_pirq(struct domain *d, int type);
 int get_free_pirqs(struct domain *d, unsigned int nr);
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2180,7 +2180,7 @@ int get_free_pirqs(struct domain *d, uns
 #define MAX_MSI_IRQS 32 /* limited by MSI capability struct properties */
 
 int map_domain_pirq(
-    struct domain *d, int pirq, int irq, int type, void *data)
+    struct domain *d, int pirq, int irq, int type, struct msi_info *msi)
 {
     int ret = 0;
     int old_irq, old_pirq;
@@ -2214,7 +2214,7 @@ int map_domain_pirq(
         return 0;
     }
 
-    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, data);
+    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi);
     if ( ret )
     {
         dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
@@ -2245,7 +2245,6 @@ int map_domain_pirq(
 
     if ( type == MAP_PIRQ_TYPE_MSI || type == MAP_PIRQ_TYPE_MULTI_MSI )
     {
-        struct msi_info *msi = (struct msi_info *)data;
         struct msi_desc *msi_desc;
         struct pci_dev *pdev;
         unsigned int nr = 0;



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:54:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392691.1631666 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt7H-0004XV-Mt; Mon, 17 Aug 2026 08:54:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392691.1631666; Mon, 17 Aug 2026 08:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt7H-0004XO-K5; Mon, 17 Aug 2026 08:54:47 +0000
Received: by outflank-mailman (input) for mailman id 1392691;
 Mon, 17 Aug 2026 08:54:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt7F-0004X5-TH
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:54:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt7F-00BAbm-7q
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:54:45 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc49-8faa-0a2a0a5109dd-0a2a4501aab2-32
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:54:45 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc55-5984-0a2a45010019-d155802be4b8-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:54:45 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso23114225e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:54:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d078523sm26211435e9.6.2026.08.17.01.54.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:54:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956884; x=1787561684; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=cPYUEycXx4QXrkSBKGzwPTxbJ3B4xNT3wDshow8ZLw4=;
        b=L+P6faDBgCuHYZIv59p1LQcFscXb22cIUGFCUawWhCM+SXGws0yORdU1WEwCFmSwqk
         3iZlzUmHTvm9mPvs3t6SGqdnK16XILlgwsXAhMEH1nyjSRsokJ0OX4iNhz4HKZw39JS0
         xSL5OYvEAMTLfmkcLVBBTSTQwvq7PJQTqV4SeWIhhtL7NxVFvpKtMhBbniUckd0++NOc
         VcsDTMq/UCiCYBZ3ittCvktB6Dco+TEGJHjXnkkksxqzJtyYo13pwSP6xMKQHQct5vDx
         tf1GkoM6XB2y4fg9eM05VXTJHOMhmnJ5VoKh+V8tcm1Ap7gkafI7r/ZbPD/0wGcfYo2U
         vDaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956885; x=1787561685;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=cPYUEycXx4QXrkSBKGzwPTxbJ3B4xNT3wDshow8ZLw4=;
        b=d10QfquDMoFO8L8hzW2Tz7q3wsCttuOOynVY/QBPlKmdadeRL+KEeYeGd6ZfBfy04n
         iBmYbuTWwkenhr/MM6sQqJTxKvqFeaS9FRQw+uJzIWRUtqAJz7ct4HzInOFRbzHrjNuH
         6NtsXmlznzPMQ7nBN1UTE604n8M32fQiaJIw+rJ0xiBrGAjVYUMgxjD7VDwiucHnqUIl
         NTCUdusDljafU5kdG1dQf8QTyMdNfefZ5dfuHWwzZ/6r/UpAYOKoNzEaeLbFNhvURadU
         vZut7HAeqbC7JFm8PUZwgGfAUOgbXj1jpKaY9S8MxkCD6g7espVwVFcFncPxN+iuS1Ex
         FY1w==
X-Gm-Message-State: AOJu0YxkQA/FJiKJ1SzgQVt6Qu3y0x1c7SzmKxjc65fcxXaAmHcOB5Et
	/Uy06p2II/hGOFmnEdq0wJ65tVH1mlQcEelZzlVIZzMbub0/YTWFxDqKhgAebRqi+iaF1dC9rqr
	bMa+o3w==
X-Gm-Gg: AR+sD11lcHKPth0/6iKZAw4ejJFYKAhLhdyANB4Ea/CHvYgcgLLR31w47nKi/TscuSW
	W5KYpAeEL4ZnX3/69w8x4f8eLMVtDwyJ4fEVjlP7jt7UGQ1Lp3DIqa3kg0j22eBokmfDDU++WPR
	5WXHa7QWFVjnHmpcpFTBJg10qQur5UgN3Awoi4RPv0T1AcOpRThjLQbqpr0LJXDAa2QuuHvl4T9
	dPf8dXGxeXHy3kGZYVXsKHGDz7j7GWVZmSrf9ZikzhsjASNeO+cwkSWoD9ZSop/VSGugXxb1fbU
	PTFYfYpPhfIqWDCsOHU/YKElbFtfO/3yTA+5LKLYauiHBH2FnsZfqoQ8W7BmIH7NirpdQnqwKpY
	dlwLYK20MtxWhh9E7oLqco1MVrjD9M85Zfta7RC/fuW4JaxrDD+HvlW9eiy7+BV71Rl8CM8DsNu
	0d1CCHZEimefsyPlRw+hQTH/yPu/J8xRRgnqbJWQiUfBcTGEcC3+Z0pvGGJRcN23saJXdrNv5Tj
	iNh8prF9WwB2lI1eojidl7xS3klqWsxDecJnPkDiPvTQdIazg+e
X-Received: by 2002:a05:600c:4614:b0:499:858f:2653 with SMTP id 5b1f17b1804b1-49987929193mr238357775e9.2.1786956884595;
        Mon, 17 Aug 2026 01:54:44 -0700 (PDT)
Message-ID: <f72a1f61-b258-4f7d-b61a-6ba04cb11207@suse.com>
Date: Mon, 17 Aug 2026 10:54:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 08/14] XSM: pass just SBDF to xsm_{,un}map_domain_irq()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786956885-BF46D757-85A595FB/0/0
X-purgate-type: clean
X-purgate-size: 4874

That's what Flask needs, and by unifying the hooks flask_map_domain_msi()
can then also serve both flask_{,un}map_domain_irq().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
How come Arm doesn't use xsm_unmap_domain_irq()?

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2214,7 +2214,7 @@ int map_domain_pirq(
         return 0;
     }
 
-    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi);
+    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi ? &msi->sbdf : NULL);
     if ( ret )
     {
         dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
@@ -2442,7 +2442,7 @@ int unmap_domain_pirq(struct domain *d,
      */
     if ( !d->is_dying )
         ret = xsm_unmap_domain_irq(XSM_HOOK, d, irq,
-                                   msi_desc ? msi_desc->dev : NULL);
+                                   msi_desc ? &msi_desc->dev->sbdf : NULL);
 
     if ( ret )
         goto done;
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -470,7 +470,7 @@ static XSM_INLINE int xsm_pirq_mapping(
 #endif /* CONFIG_HAS_PIRQ */
 
 static XSM_INLINE int xsm_map_domain_irq(
-    XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
+    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
 {
     XSM_ASSERT_ACTION(XSM_HOOK);
     return xsm_default_action(action, current->domain, d);
@@ -491,7 +491,7 @@ static XSM_INLINE int xsm_unbind_pt_irq(
 }
 
 static XSM_INLINE int xsm_unmap_domain_irq(
-    XSM_DEFAULT_ARG struct domain *d, int irq, const void *data)
+    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
 {
     XSM_ASSERT_ACTION(XSM_HOOK);
     return xsm_default_action(action, current->domain, d);
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -71,8 +71,8 @@ XSM_HOOK(int, schedop_shutdown, struct d
 XSM_HOOK(int, pirq_mapping, struct domain *, bool)
 #endif
 
-XSM_HOOK(int, map_domain_irq, struct domain *, int, const void *)
-XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const void *)
+XSM_HOOK(int, map_domain_irq, struct domain *, int, const pci_sbdf_t *)
+XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const pci_sbdf_t *)
 XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
 XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
 
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1030,17 +1030,14 @@ static int cf_check flask_pirq_mapping(s
 #endif /* CONFIG_HAS_PIRQ */
 
 static int flask_map_domain_msi (
-    struct domain *d, int irq, const void *data, uint32_t *sid,
+    struct domain *d, int irq, pci_sbdf_t sbdf, uint32_t *sid,
     struct avc_audit_data *ad)
 {
 #ifdef CONFIG_HAS_PCI_MSI
-    const struct msi_info *msi = data;
-    uint32_t machine_bdf = msi->sbdf.sbdf;
-
     AVC_AUDIT_DATA_INIT(ad, DEV);
-    ad->device = machine_bdf;
+    ad->device = sbdf.sbdf;
 
-    return security_device_sid(machine_bdf, sid);
+    return security_device_sid(sbdf.sbdf, sid);
 #else
     return -EINVAL;
 #endif
@@ -1066,15 +1063,15 @@ static uint32_t flask_iommu_resource_use
 }
 
 static int cf_check flask_map_domain_irq(
-    struct domain *d, int irq, const void *data)
+    struct domain *d, int irq, const pci_sbdf_t *sbdf)
 {
     uint32_t sid, dsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
     uint32_t dperm = flask_iommu_resource_use_perm(d);
 
-    if ( irq >= nr_static_irqs && data )
-        rc = flask_map_domain_msi(d, irq, data, &sid, &ad);
+    if ( irq >= nr_static_irqs && sbdf )
+        rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
     else
         rc = get_irq_sid(irq, &sid, &ad);
 
@@ -1091,32 +1088,15 @@ static int cf_check flask_map_domain_irq
     return rc;
 }
 
-static int flask_unmap_domain_msi (
-    struct domain *d, int irq, const void *data, uint32_t *sid,
-    struct avc_audit_data *ad)
-{
-#ifdef CONFIG_HAS_PCI_MSI
-    const struct pci_dev *pdev = data;
-    uint32_t machine_bdf = (pdev->seg << 16) | (pdev->bus << 8) | pdev->devfn;
-
-    AVC_AUDIT_DATA_INIT(ad, DEV);
-    ad->device = machine_bdf;
-
-    return security_device_sid(machine_bdf, sid);
-#else
-    return -EINVAL;
-#endif
-}
-
 static int cf_check flask_unmap_domain_irq(
-    struct domain *d, int irq, const void *data)
+    struct domain *d, int irq, const pci_sbdf_t *sbdf)
 {
     uint32_t sid;
     int rc = -EPERM;
     struct avc_audit_data ad;
 
-    if ( irq >= nr_static_irqs && data )
-        rc = flask_unmap_domain_msi(d, irq, data, &sid, &ad);
+    if ( irq >= nr_static_irqs && sbdf )
+        rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
     else
         rc = get_irq_sid(irq, &sid, &ad);
 



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:55:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:55:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392704.1631692 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt84-0005CE-An; Mon, 17 Aug 2026 08:55:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392704.1631692; Mon, 17 Aug 2026 08:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt84-0005Bz-5W; Mon, 17 Aug 2026 08:55:36 +0000
Received: by outflank-mailman (input) for mailman id 1392704;
 Mon, 17 Aug 2026 08:55:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt82-0005BI-LR
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:55:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt82-009Qt6-26
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:55:34 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc84-bab6-0a2a0a5309dd-0a2a4501b900-4
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:55:33 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cc85-5984-0a2a45010019-d155802aa5b2-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:55:33 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-495437bb891so28949605e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:55:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d0876b8sm32206315e9.8.2026.08.17.01.55.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:55:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956933; x=1787561733; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=XcRV9DpoQXKVy9yGwvj7aXR3BN5ZksQ4Op6sLkbWN6Y=;
        b=adaeBuAON58+6L7oGF3FxHS7yAzsylsI6RkjtoBAn9j73oRnQBHYjpKk6K3Jshmavq
         8j+u6Y3bhX7skZ03uyV1HPuKH+kEfWn8f8Q9kueIsQZWAsji/ac2nFEkSYVE+IiYlwzp
         hAJCVdOhR1/c0QHl3x6BJ1ntThD6aVf/L1qlQp5FTNzl6fNcSiapoS8x6It6vx4rY85+
         tAhEojX7W9nQLsEEp1ckL0yTEIdJKpxV3kygcplE5PMeSA0PSu+Xn0RzRrgHAauS3G35
         6GBq73O+05a8SrMGEefXcP+X4+LMqqO/AtfePeRebU9TKPZskLB8cjm1TmaoMLutigkX
         QhZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956933; x=1787561733;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=XcRV9DpoQXKVy9yGwvj7aXR3BN5ZksQ4Op6sLkbWN6Y=;
        b=sInItS6bJaHP1R2u8fpxlLHuBrKnEq3bWvn8M7iiXP3owmV/DbRq5fwX5Y6gx59bDa
         DIFEsj7ly9ymUJTdAecHO+/1eRG+DJeEO2mzua20/PajZ0/yqARvrS26OqbGIfsA8r0R
         vI9AVmF2ddnIdNHhu5ZFE8UWbD7tmvOCiphIW36wGg9Fg0FY+wGluiE7omfmpd0SD4er
         e3NSk97cshpqRdjKeHmBbvdPan0U1xHdey9UO7MlR6YM7e9xon1gZoUrxxivb+6nwz0n
         dxuCLIhIh3AJ2jxKsgNivgjiIlw75TX/xtIqwRrCuY5NYCXGBJgf+7iUQLHROARV7hzL
         KWDA==
X-Gm-Message-State: AOJu0Yykxd5NAIHNSa0dkTinZFsM8H2IZj1ReVjZqmISd6KbqhK3TL8O
	MAP9/hHu9nYvcZwa7TwqsUhCuDmqcweLsD5/vWk0ZOUKQDapiBBhZLEWmVao1bLrByCMhhl+gM1
	gcKw0YA==
X-Gm-Gg: AR+sD13vL0e46h7cd9kLbZe13bDefVCKvNYw6IUmpVKt7oZUcmW1F0oxIn3lmx155nU
	K0ZimYA7zrQ+2N8JKBHpGWh7hf3CR0g05Ep1la8QJKUGHwc6VdFMk5lrZmZSO+mLihN3vjqb6m2
	AId2+ktQbfcp3nuvy6Yh9vrj9g3g0c7gYYChW2+23A6MrsIY+V8Gu66i8lMEIZm3+JDMyzuVdqJ
	/0tsgMvUra2THQ0m4Yh1apfBG9kqlcdl1G6IAdqUwcGoaae5GTHsBY6pCgm4wnIl4rMNYzXx2Y0
	t47Blq4TIclH8AJv3XX0cIFbRjVr6B//AYY2oVlE6Pnsu9SvRGx+of41yfna+D3V4zZ+F4yARo3
	0/PH4fxAKOO31Jk1HKI+TO2rmTR0+CPWtllZ6Fp7m0UqO0LBSzcHEz/N44ymostRY1KvcQryFXU
	/zdboMwne3rUzg+pCZlSbbMap02y6sMljjLMOjfCO1m27UJN0qBbwgWPVSv+ZQJlayZFTHEU5ai
	c7yEu0e3nbZJxRUIYgjz4AD/PPtjHMJG2mn9GUIT5dQWj5TsM9CmI0u/C/E2b0=
X-Received: by 2002:a05:600c:3b90:b0:499:59fd:dbfc with SMTP id 5b1f17b1804b1-49987a4f131mr309975285e9.1.1786956933400;
        Mon, 17 Aug 2026 01:55:33 -0700 (PDT)
Message-ID: <9fa10fe2-8bd6-4652-b3ff-0aa49005e411@suse.com>
Date: Mon, 17 Aug 2026 10:55:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 09/14] XSM: fold xsm_{,un}map_domain_irq() hooks
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786956933-BE465757-1E8E0C3D/0/0
X-purgate-type: clean
X-purgate-size: 5280

Like other resource management hooks they are (now) mainly different in
"add resource" vs "remove resource". Hence like in other cases a single
hook can easily serve both purposes, with minor tweaking of
flask_map_domain_irq(). While adjusting that function, also defer the
setting of local variables only needed in the "map" case.

Rename hook and functions to fit xsm_{io{mem,port},pirq}_mapping().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Fix inverted part of conditional in flask_map_domain_irq(). Rename
    hook, functions, and new parameter.

--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -100,7 +100,7 @@ long arch_do_domctl(struct xen_domctl *d
          * done by the 2 hypercalls for consistency with other
          * architectures.
          */
-        rc = xsm_map_domain_irq(XSM_HOOK, d, irq, NULL);
+        rc = xsm_irq_mapping(XSM_HOOK, d, irq, NULL, true);
         if ( rc )
             return rc;
 
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2214,7 +2214,7 @@ int map_domain_pirq(
         return 0;
     }
 
-    ret = xsm_map_domain_irq(XSM_HOOK, d, irq, msi ? &msi->sbdf : NULL);
+    ret = xsm_irq_mapping(XSM_HOOK, d, irq, msi ? &msi->sbdf : NULL, true);
     if ( ret )
     {
         dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
@@ -2441,8 +2441,8 @@ int unmap_domain_pirq(struct domain *d,
      * domain.  Skip the XSM check since this is a Xen-initiated action.
      */
     if ( !d->is_dying )
-        ret = xsm_unmap_domain_irq(XSM_HOOK, d, irq,
-                                   msi_desc ? &msi_desc->dev->sbdf : NULL);
+        ret = xsm_irq_mapping(XSM_HOOK, d, irq,
+                              msi_desc ? &msi_desc->dev->sbdf : NULL, false);
 
     if ( ret )
         goto done;
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -469,8 +469,9 @@ static XSM_INLINE int xsm_pirq_mapping(
 
 #endif /* CONFIG_HAS_PIRQ */
 
-static XSM_INLINE int xsm_map_domain_irq(
-    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
+static XSM_INLINE int xsm_irq_mapping(
+    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf,
+    bool map)
 {
     XSM_ASSERT_ACTION(XSM_HOOK);
     return xsm_default_action(action, current->domain, d);
@@ -490,13 +491,6 @@ static XSM_INLINE int xsm_unbind_pt_irq(
     return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int xsm_unmap_domain_irq(
-    XSM_DEFAULT_ARG struct domain *d, int irq, const pci_sbdf_t *sbdf)
-{
-    XSM_ASSERT_ACTION(XSM_HOOK);
-    return xsm_default_action(action, current->domain, d);
-}
-
 static XSM_INLINE int xsm_irq_permission(
     XSM_DEFAULT_ARG struct domain *d, int pirq, bool allow)
 {
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -71,8 +71,7 @@ XSM_HOOK(int, schedop_shutdown, struct d
 XSM_HOOK(int, pirq_mapping, struct domain *, bool)
 #endif
 
-XSM_HOOK(int, map_domain_irq, struct domain *, int, const pci_sbdf_t *)
-XSM_HOOK(int, unmap_domain_irq, struct domain *, int, const pci_sbdf_t *)
+XSM_HOOK(int, irq_mapping, struct domain *, int, const pci_sbdf_t *, bool)
 XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
 XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
 
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1062,13 +1062,12 @@ static uint32_t flask_iommu_resource_use
     return perm;
 }
 
-static int cf_check flask_map_domain_irq(
-    struct domain *d, int irq, const pci_sbdf_t *sbdf)
+static int cf_check flask_irq_mapping(
+    struct domain *d, int irq, const pci_sbdf_t *sbdf, bool map)
 {
-    uint32_t sid, dsid;
+    uint32_t sid, dsid, dperm;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    uint32_t dperm = flask_iommu_resource_use_perm(d);
 
     if ( irq >= nr_static_irqs && sbdf )
         rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
@@ -1078,33 +1077,16 @@ static int cf_check flask_map_domain_irq
     if ( rc )
         return rc;
 
-    dsid = domain_sid(d);
-
-    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
-    if ( rc )
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE,
+                              map ? RESOURCE__ADD_IRQ : RESOURCE__REMOVE_IRQ,
+                              &ad);
+    if ( rc || !map )
         return rc;
 
-    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, dperm, &ad);
-    return rc;
-}
-
-static int cf_check flask_unmap_domain_irq(
-    struct domain *d, int irq, const pci_sbdf_t *sbdf)
-{
-    uint32_t sid;
-    int rc = -EPERM;
-    struct avc_audit_data ad;
-
-    if ( irq >= nr_static_irqs && sbdf )
-        rc = flask_map_domain_msi(d, irq, *sbdf, &sid, &ad);
-    else
-        rc = get_irq_sid(irq, &sid, &ad);
-
-    if ( rc )
-        return rc;
+    dsid = domain_sid(d);
+    dperm = flask_iommu_resource_use_perm(d);
 
-    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
-    return rc;
+    return avc_has_perm(dsid, sid, SECCLASS_RESOURCE, dperm, &ad);
 }
 
 static int cf_check flask_bind_pt_irq(



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:56:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:56:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392712.1631700 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt9D-0005jc-HY; Mon, 17 Aug 2026 08:56:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392712.1631700; Mon, 17 Aug 2026 08:56:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt9D-0005jV-Ei; Mon, 17 Aug 2026 08:56:47 +0000
Received: by outflank-mailman (input) for mailman id 1392712;
 Mon, 17 Aug 2026 08:56:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt9C-0005jN-76
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:56:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt9B-00BBIF-Je
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:56:45 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82ccbc-8faa-0a2a0a5109dd-0a2a450a85b6-38
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:56:45 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cccd-f2d2-0a2a450a0019-d155dd31e152-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:56:45 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so2795532f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:56:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7cd38sm2374589f8f.32.2026.08.17.01.56.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:56:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786957005; x=1787561805; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=uyRZNfEKi5kGEi7GsXb+f9FRAExy/jFd4bMa55xJlqk=;
        b=QnaCWDSZ0PrHXpkeNFzz5fBrP/IHB7LHsQO8cEPSLrr8PDAeOi6/HEae4d8Lpp+rkt
         cYqPv5oPcee3Ccvm5VLvQpJb/laqQQM5wyRe6nlwPesu+ss8o82K3OMl998X3kqiZnuq
         kz6BhFJabH0UIspXvoJMnaaXPG0Annan5puj1jDs/g+LwHmYx0+RMWPbHf6bqeD9qsJJ
         jKtU82A0+NtEDnAda/mRXdtxFUTJbITUo87luoGXdz0037NKFy+J4Iv4BgmOJkl1oc7k
         SnOwelZiGfbErZ/2goxKZ/998S25+ZgHtg2KzOO1tmLQXZ1HGrEwmNH4BbytzgZDSXx/
         LygQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786957005; x=1787561805;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=uyRZNfEKi5kGEi7GsXb+f9FRAExy/jFd4bMa55xJlqk=;
        b=TjRkYeGU1pgCvDgLNS0BJ3ysi+UaJZGz3QnJai4zbPkWogE6q82paHtvVCxINNhmaM
         h0iN5rpNm9yCZmsrik8Qiycu3j+5OdiPnCXWQyamb6FuZeYNJmfkAbop6qdE6c31Q397
         CAvlp+KaoA4PhJ1gTL57YOsbOMCbO5JYGLprbiYKSh0JjqtOoF302Np4wewrU/eFHUt0
         17eJLik07raWw1Ms4W3Br2U6NmaeEC+/diJG4Ig4ytMUhKQnL11cH1DgtiY/OGVYZcpU
         YmPZESkuKsOTPjVf81ZLy9aPGH0gygBWzQGclk6+SY0vGtnqjz9hfQNpV/KRLkwakS+m
         Z1CQ==
X-Gm-Message-State: AOJu0YwTTWxSyYqYFux4/jyE4MTIktFxpS94KoPE7i+chrjyvtwBVIvX
	Rli5bqet9OCOrnwmOfyov4MrRBLOnKax0ntHEE+zQZO/3d2z4quhgz7zz0mOeU7KpqzZRrgft5u
	KXibaeg==
X-Gm-Gg: AR+sD10xkEAtbvzb6GYWd3r4TbF4cG8eZcU4IlPJLWOXs7d79AwqI1hmGWRCXJKc/h4
	3Jkr16dtJJV6WuLtMOB8hNrSM6Kg+ccWLFbeSap+6dKhMsuwWZ7e7MEZO4VAtEvQe0yNHHMi7pn
	1GlSmj5Edxa1dohMBF4glw7NZw7HzPmemBvCFtdFnWYWohFsIznhI2yQz6Zw4BFFmuF1qMt2jp7
	bMzRlU8eICvOm/TgY+4w1qGmjauW1rZD4JhpjfFQ0LvF45KUf6YotPyObM7MNFnxd3jWkLO76Gz
	3jaYKzBiXmByQavac7r//48zGD/xoFYcY4eC3irQEZmOyU3dwwhWuWOGodn/HXyFzCN86T20DYp
	XmyX3azKtnBr9hHfPlyoQ6Ff3KeRHs60HdQJhJNt8D1dvflL4rGsmwHwQSZ3dl1auyeBp6JcfmD
	gGuaJcgJBXa7mU3cgs7TjnQZxHQvrGmRFiOtYf+9lqxpcN124usXSsar1zryL++AH5FXVU8PvWh
	Jhv5fSqqJUvBu+V5zpqjKlICV4y6q8LZ/RHOFZVJNZ8/X/PLCYLUA==
X-Received: by 2002:adf:f3ce:0:b0:47f:8480:4abd with SMTP id ffacd0b85a97d-4816079d16bmr26232842f8f.29.1786957004957;
        Mon, 17 Aug 2026 01:56:44 -0700 (PDT)
Message-ID: <ada7e383-560a-4168-8d39-b6622ab804d7@suse.com>
Date: Mon, 17 Aug 2026 10:56:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 11/14] XSM: convert remaining event channel hooks
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1786957005-52CDBCFC-607E69A7/0/0
X-purgate-type: clean
X-purgate-size: 7123

Make them follow the standard scheme, i.e. taking xsm_default_t as first
argument at call sites. This way they can be covered by the recently
introduced hook machinery.

While there, uniformly convert struct evtchn chn[] notation to pointer
form, as the (nicer) array representation is harder to make usable with
the hooks.h logic.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,7 +159,7 @@ static void free_evtchn_bucket(struct do
     if ( !bucket )
         return;
 
-    xsm_free_security_evtchns(bucket, EVTCHNS_PER_BUCKET);
+    xsm_free_security_evtchns(XSM_HOOK, bucket, EVTCHNS_PER_BUCKET);
     xfree(bucket);
 }
 
@@ -172,7 +172,7 @@ static struct evtchn *alloc_evtchn_bucke
     if ( !chn )
         goto err;
 
-    if ( xsm_alloc_security_evtchns(chn, EVTCHNS_PER_BUCKET) )
+    if ( xsm_alloc_security_evtchns(XSM_HOOK, chn, EVTCHNS_PER_BUCKET) )
         goto err;
 
     for ( i = 0; i < EVTCHNS_PER_BUCKET; i++ )
@@ -297,7 +297,7 @@ void evtchn_free(struct domain *d, struc
     chn->notify_vcpu_id = 0;
     chn->xen_consumer   = 0;
 
-    xsm_evtchn_close_post(chn);
+    xsm_evtchn_close_post(XSM_HOOK, chn);
 }
 
 static int evtchn_get_port(struct domain *d, evtchn_port_t port)
@@ -1779,7 +1779,7 @@ static void domain_dump_evtchn_info(stru
             break;
         }
 
-        ssid = xsm_show_security_evtchn(d, chn);
+        ssid = xsm_show_security_evtchn(XSM_HOOK, d, chn);
         if (ssid) {
             printk(" Z=%s\n", ssid);
             xfree(ssid);
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -311,8 +311,10 @@ static XSM_INLINE int xsm_evtchn_interdo
     return xsm_default_action(action, d1, d2);
 }
 
-static XSM_INLINE void xsm_evtchn_close_post(struct evtchn *chn)
-{}
+static XSM_INLINE void xsm_evtchn_close_post(XSM_DEFAULT_ARG struct evtchn *chn)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+}
 
 static XSM_INLINE int xsm_evtchn_send(
     XSM_DEFAULT_ARG struct domain *d, struct evtchn *chn)
@@ -336,18 +338,22 @@ static XSM_INLINE int xsm_evtchn_reset(
 }
 
 static XSM_INLINE int xsm_alloc_security_evtchns(
-    struct evtchn chn[], unsigned int nr)
+    XSM_DEFAULT_ARG struct evtchn *chn, unsigned int nr)
 {
+    XSM_ASSERT_ACTION(XSM_HOOK);
     return 0;
 }
 
 static XSM_INLINE void xsm_free_security_evtchns(
-    struct evtchn chn[], unsigned int nr)
-{}
+    XSM_DEFAULT_ARG struct evtchn *chn, unsigned int nr)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+}
 
 static XSM_INLINE char *xsm_show_security_evtchn(
-    struct domain *d, const struct evtchn *chn)
+    XSM_DEFAULT_ARG struct domain *d, const struct evtchn *chn)
 {
+    XSM_ASSERT_ACTION(XSM_HOOK);
     return NULL;
 }
 
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -34,6 +34,11 @@ XSM_HOOK(int, evtchn_interdomain, struct
 XSM_HOOK(int, evtchn_send, struct domain *, struct evtchn *)
 XSM_HOOK(int, evtchn_status, struct domain *, struct evtchn *)
 XSM_HOOK(int, evtchn_reset, struct domain *, struct domain *)
+XSM_HOOK(void, evtchn_close_post, struct evtchn *)
+XSM_HOOK(int, alloc_security_evtchns, struct evtchn *, unsigned int)
+XSM_HOOK(void, free_security_evtchns, struct evtchn *, unsigned int)
+XSM_HOOK(pchar_t, show_security_evtchn, struct domain *,
+                                        const struct evtchn *)
 
 #ifdef CONFIG_GRANT_TABLE
 XSM_HOOK(int, grant_mapref, struct domain *, struct domain *, uint32_t)
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,6 +21,9 @@
 /* policy magic number (defined by XSM_MAGIC) */
 typedef uint32_t xsm_magic_t;
 
+/* Auxiliary type(s) for use in hook definitions. */
+typedef char *pchar_t;
+
 #ifdef CONFIG_XSM_FLASK
 #define XSM_MAGIC 0xf97cff8cU
 #else
@@ -76,13 +79,8 @@ struct xsm_ops {
 
 #include "hooks.h"
 
-    void (*evtchn_close_post)(struct evtchn *chn);
-
     int (*alloc_security_domain)(struct domain *d);
     void (*free_security_domain)(struct domain *d);
-    int (*alloc_security_evtchns)(struct evtchn chn[], unsigned int nr);
-    void (*free_security_evtchns)(struct evtchn chn[], unsigned int nr);
-    char *(*show_security_evtchn)(struct domain *d, const struct evtchn *chn);
 
     char *(*show_irq_sid)(int irq);
 };
@@ -104,8 +102,9 @@ static inline void xsm_security_domainin
     alternative_vcall(xsm_ops.security_domaininfo, d, info);
 }
 
-#define XSM_ALT_void alternative_vcall
-#define XSM_ALT_int  return alternative_call
+#define XSM_ALT_void      alternative_vcall
+#define XSM_ALT_int       return alternative_call
+#define XSM_ALT_pchar_t   return alternative_call
 
 #define XSM_HOOK0(rtype, name) \
 static inline rtype xsm_ ## name(xsm_default_t def) \
@@ -150,11 +149,6 @@ static inline rtype xsm_ ## name( \
 
 #include "hooks.h"
 
-static inline void xsm_evtchn_close_post(struct evtchn *chn)
-{
-    alternative_vcall(xsm_ops.evtchn_close_post, chn);
-}
-
 static inline int xsm_alloc_security_domain(struct domain *d)
 {
     return alternative_call(xsm_ops.alloc_security_domain, d);
@@ -165,24 +159,6 @@ static inline void xsm_free_security_dom
     alternative_vcall(xsm_ops.free_security_domain, d);
 }
 
-static inline int xsm_alloc_security_evtchns(
-    struct evtchn *chn, unsigned int nr)
-{
-    return alternative_call(xsm_ops.alloc_security_evtchns, chn, nr);
-}
-
-static inline void xsm_free_security_evtchns(
-    struct evtchn *chn, unsigned int nr)
-{
-    alternative_vcall(xsm_ops.free_security_evtchns, chn, nr);
-}
-
-static inline char *xsm_show_security_evtchn(
-    struct domain *d, const struct evtchn *chn)
-{
-    return alternative_call(xsm_ops.show_security_evtchn, d, chn);
-}
-
 static inline char *xsm_show_irq_sid(int irq)
 {
     return alternative_call(xsm_ops.show_irq_sid, irq);
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -26,13 +26,8 @@ static const struct xsm_ops __initconst_
 
 #include <xsm/hooks.h>
 
-    .evtchn_close_post             = xsm_evtchn_close_post,
-
     .alloc_security_domain         = xsm_alloc_security_domain,
     .free_security_domain          = xsm_free_security_domain,
-    .alloc_security_evtchns        = xsm_alloc_security_evtchns,
-    .free_security_evtchns         = xsm_free_security_evtchns,
-    .show_security_evtchn          = xsm_show_security_evtchn,
 
     .show_irq_sid                  = xsm_show_irq_sid,
 };
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1915,13 +1915,8 @@ static const struct xsm_ops __initconst_
 
 #include <xsm/hooks.h>
 
-    .evtchn_close_post = flask_evtchn_close_post,
-
     .alloc_security_domain = flask_domain_alloc_security,
     .free_security_domain = flask_domain_free_security,
-    .alloc_security_evtchns = flask_alloc_security_evtchns,
-    .free_security_evtchns = flask_free_security_evtchns,
-    .show_security_evtchn = flask_show_security_evtchn,
 
     .show_irq_sid = flask_show_irq_sid,
 };



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:57:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:57:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392717.1631708 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt9h-0006Bg-P2; Mon, 17 Aug 2026 08:57:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392717.1631708; Mon, 17 Aug 2026 08:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvt9h-0006BZ-LZ; Mon, 17 Aug 2026 08:57:17 +0000
Received: by outflank-mailman (input) for mailman id 1392717;
 Mon, 17 Aug 2026 08:57:16 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvt9g-0006BP-F0
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:57:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvt9f-005GNP-Rx
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:57:15 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cce5-8faa-0a2a0a5109dd-0a2a450b8f80-24
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:57:15 +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 <jbeulich@suse.com>)
 id 6a82cceb-b7e8-0a2a450b0019-d155802fa4c7-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:57:15 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so27566865e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:57:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d0fb872sm34010115e9.9.2026.08.17.01.57.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:57:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786957035; x=1787561835; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=o8SOdb+AsZMjG0+VwY3YOWVBWdSQ5EYwU96aNxkx4tc=;
        b=AnQxLYS6hTUir/nPEnrqBvrblfqVkMZgcSl8h41ugMg/mXZRwbyEO9gtQoXSTWbbLx
         eJZUC8+ecMlgVhpQfRSMh6Fnrt3euv0LbStNDPqnrDbxvHiponymJR9rkr8h1x5L48WN
         CXzSoL8i0RCFYNcUFHY/WwUe7sHoR3Gq+MCZl42BWCL+WoW9l+MjlaVlN6SjFk74cQzu
         bd44/WD6WdeQbbiMR5OUgsPHh5hkSKOYzTUpqbNaP61BO34sP0I5/S3ew95wfnywVzSI
         psnrWZYGc6dv6cy9gXjqVMlkPjgkA/etLpLQjzE1P6L6bYHrcKUuirJbkyoQEjkYTzjh
         ng2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786957035; x=1787561835;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=o8SOdb+AsZMjG0+VwY3YOWVBWdSQ5EYwU96aNxkx4tc=;
        b=Ke1298nwxwO/RtWvWkGGGvdViY0ShrMHx/+1t+Vwgu4ctjH7/wPFIG1kuONhqpU0i3
         6vgn9yAeUIO8NN6TJqDU3FBlY4s9JPJ3nipP0Xhzfi9QpTiLprlDW5XjXnLKoBhAS5+3
         DmdCgKQryUJ0UO7ybUPq3/lL3wZ60sz0BIrdymtTMV7CGNQtB5AOdxObSzArh4/TMEkr
         jQNN5Kgcz1cvCY0OO0yHXQ6vnoWoqdr+7FqR7zIpCC+60DD+g1ifEsTSKmMkH5X56Oz5
         SpLCU20gwZ+HIYTuZsstiM1J0Obnj3/dUFVAJJ3Y+LI5fDf1v9gqUZpoOA1HI6pjuQF2
         LxgA==
X-Gm-Message-State: AOJu0YzrgyKF9iPZbYqvfLkvqy9FQj7fmOQC58LCxnS6jsVCajGrkuHU
	fSM8g5b+01wbCi4RwryvEcxmFIkvzhNEofzudK2dctj1cAzIUryU4ZdrJQ7j8Bg+lkBYLtr10Cz
	AJagZog==
X-Gm-Gg: AR+sD103jpAJ8WuHUVEb0DAUZjmvaIv4XaMN5niA2f1BjWXF8au/XN78v9sCIM8IMXQ
	JeN6Svq8bxzT9xk1m2chymCVH0kQWriMgzJit6iJREhMbGF4w+htiwrL/S2YYJZ1hZyR5Q7EaZY
	scP0Erahhp4sXnHkq1uTi1n5+sGmqpbMXemCJXEOajzVnWni8p1GuYE/UYa5r8PvasTRO+4nZLb
	kKyLKIThhiDPRdnfx366n0x3urk/mCXkhblFAf5U8947Cn1KK3Q32tQOrF9JCqjADrw6LVbCdfQ
	u12gILfo5UwcmFPlSADrMa9zzZ/CRnyOni037tJch/UGyk508nlFaQ5uvbJnzIIdh77LeZESbui
	dj75ceWn1+bGe/dSmlmc++iq8hjeZDV2Gp/aD380fLf19wEV74iWJ9HxrjSeM58u5CpxtaYdS4o
	yWtTVsV1cG0EoFtvE1lEOUq54v9TBkHD1lp78F2EfWMzU6KZ9AVmnPYHrQ7+j3hqeJcJgOYR6dS
	qwZSKOMyU+JSjjJXuxW95Nv9b5yhJhWQI3i3rOvB0YQB7YhPXk8
X-Received: by 2002:a05:600d:117:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-49987ab4e1bmr230477815e9.7.1786957035231;
        Mon, 17 Aug 2026 01:57:15 -0700 (PDT)
Message-ID: <d8d26338-810c-473d-91c5-0202b6dcac76@suse.com>
Date: Mon, 17 Aug 2026 10:57:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 12/14] XSM: convert remaining domain-related hooks
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786957035-A8AC89EA-D7B6E5A8/0/0
X-purgate-type: clean
X-purgate-size: 6831

Make them follow the standard scheme, i.e. taking xsm_default_t as first
argument at call sites. This way they can be covered by the recently
introduced hook machinery.

While there,
- rename flask_domain_{alloc,free}_security() to fit the corresponding
  hook names,
- add const to .security_domaininfo()'s first parameter.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -760,7 +760,7 @@ static void _domain_destroy(struct domai
 
     free_cpumask_var(d->dirty_cpumask);
 
-    xsm_free_security_domain(d);
+    xsm_free_security_domain(XSM_HOOK, d);
 
     lock_profile_deregister_struct(LOCKPROF_TYPE_PERDOM, d);
 
@@ -987,7 +987,7 @@ struct domain *domain_create(domid_t dom
         d->max_vcpus = config->max_vcpus;
     }
 
-    if ( (err = xsm_alloc_security_domain(d)) != 0 )
+    if ( (err = xsm_alloc_security_domain(XSM_HOOK, d)) != 0 )
         goto fail;
 
     err = -ENOMEM;
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -91,7 +91,7 @@ void getdomaininfo(struct domain *d, str
         (is_hvm_domain(d)               ? XEN_DOMINF_hvm_guest : 0) |
         d->shutdown_code << XEN_DOMINF_shutdownshift;
 
-    xsm_security_domaininfo(d, info);
+    xsm_security_domaininfo(XSM_HOOK, d, info);
 
     info->tot_pages         = domain_tot_pages(d);
     info->max_pages         = d->max_pages;
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -122,8 +122,11 @@ static XSM_INLINE int xsm_set_system_act
 }
 
 static XSM_INLINE void xsm_security_domaininfo(
-    struct domain *d, struct xen_domctl_getdomaininfo *info)
-{}
+    XSM_DEFAULT_ARG const struct domain *d,
+    struct xen_domctl_getdomaininfo *info)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+}
 
 static XSM_INLINE int xsm_domain_create(
     XSM_DEFAULT_ARG struct domain *d, uint32_t ssidref)
@@ -179,13 +182,18 @@ static XSM_INLINE int xsm_sysctl(
     return xsm_default_action(action, current->domain, NULL);
 }
 
-static XSM_INLINE int xsm_alloc_security_domain(struct domain *d)
+static XSM_INLINE int xsm_alloc_security_domain(
+    XSM_DEFAULT_ARG struct domain *d)
 {
+    XSM_ASSERT_ACTION(XSM_HOOK);
     return 0;
 }
 
-static XSM_INLINE void xsm_free_security_domain(struct domain *d)
-{}
+static XSM_INLINE void xsm_free_security_domain(
+    XSM_DEFAULT_ARG struct domain *d)
+{
+    XSM_ASSERT_ACTION(XSM_HOOK);
+}
 
 #ifdef CONFIG_GRANT_TABLE
 
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -20,6 +20,10 @@
 XSM_HOOK(int, domain_create, struct domain *, uint32_t)
 XSM_HOOK(int, getdomaininfo, struct domain *)
 XSM_HOOK(int, get_domain_state, struct domain *)
+XSM_HOOK(void, security_domaininfo, const struct domain *,
+                                    struct xen_domctl_getdomaininfo *)
+XSM_HOOK(int, alloc_security_domain, struct domain *)
+XSM_HOOK(void, free_security_domain, struct domain *)
 
 #ifdef CONFIG_SYSCTL
 XSM_HOOK(int, sysctl, const struct xen_sysctl *)
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -62,8 +62,6 @@ typedef enum xsm_default xsm_default_t;
  */
 struct xsm_ops {
     int (*set_system_active)(void);
-    void (*security_domaininfo)(struct domain *d,
-                                struct xen_domctl_getdomaininfo *info);
 
 #define XSM_HOOK0(rtype, name) rtype (*name)(void);
 #define XSM_HOOK1(rtype, name, type1) \
@@ -79,9 +77,6 @@ struct xsm_ops {
 
 #include "hooks.h"
 
-    int (*alloc_security_domain)(struct domain *d);
-    void (*free_security_domain)(struct domain *d);
-
     char *(*show_irq_sid)(int irq);
 };
 
@@ -96,12 +91,6 @@ static inline int xsm_set_system_active(
     return alternative_call(xsm_ops.set_system_active);
 }
 
-static inline void xsm_security_domaininfo(
-    struct domain *d, struct xen_domctl_getdomaininfo *info)
-{
-    alternative_vcall(xsm_ops.security_domaininfo, d, info);
-}
-
 #define XSM_ALT_void      alternative_vcall
 #define XSM_ALT_int       return alternative_call
 #define XSM_ALT_pchar_t   return alternative_call
@@ -149,16 +138,6 @@ static inline rtype xsm_ ## name( \
 
 #include "hooks.h"
 
-static inline int xsm_alloc_security_domain(struct domain *d)
-{
-    return alternative_call(xsm_ops.alloc_security_domain, d);
-}
-
-static inline void xsm_free_security_domain(struct domain *d)
-{
-    alternative_vcall(xsm_ops.free_security_domain, d);
-}
-
 static inline char *xsm_show_irq_sid(int irq)
 {
     return alternative_call(xsm_ops.show_irq_sid, irq);
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -15,7 +15,6 @@
 
 static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .set_system_active             = xsm_set_system_active,
-    .security_domaininfo           = xsm_security_domaininfo,
 
 #define XSM_HOOK0(rtype, name) .name = xsm_ ## name,
 #define XSM_HOOK1(rtype, name, ...) XSM_HOOK0(rtype, name)
@@ -26,9 +25,6 @@ static const struct xsm_ops __initconst_
 
 #include <xsm/hooks.h>
 
-    .alloc_security_domain         = xsm_alloc_security_domain,
-    .free_security_domain          = xsm_free_security_domain,
-
     .show_irq_sid                  = xsm_show_irq_sid,
 };
 
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -188,7 +188,7 @@ static int avc_unknown_permission(const
     return rc;
 }
 
-static int cf_check flask_domain_alloc_security(struct domain *d)
+static int cf_check flask_alloc_security_domain(struct domain *d)
 {
     struct domain_security_struct *dsec;
 
@@ -256,7 +256,7 @@ static int cf_check flask_set_system_act
     return 0;
 }
 
-static void cf_check flask_domain_free_security(struct domain *d)
+static void cf_check flask_free_security_domain(struct domain *d)
 {
     struct domain_security_struct *dsec = d->ssid;
 
@@ -549,7 +549,7 @@ static int cf_check flask_schedop_shutdo
 }
 
 static void cf_check flask_security_domaininfo(
-    struct domain *d, struct xen_domctl_getdomaininfo *info)
+    const struct domain *d, struct xen_domctl_getdomaininfo *info)
 {
     info->ssidref = domain_sid(d);
 }
@@ -1904,7 +1904,6 @@ static int cf_check flask_get_domain_sta
 
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
-    .security_domaininfo = flask_security_domaininfo,
 
 #define XSM_HOOK0(rtype, name) .name = flask_ ## name,
 #define XSM_HOOK1(rtype, name, ...) XSM_HOOK0(rtype, name)
@@ -1915,9 +1914,6 @@ static const struct xsm_ops __initconst_
 
 #include <xsm/hooks.h>
 
-    .alloc_security_domain = flask_domain_alloc_security,
-    .free_security_domain = flask_domain_free_security,
-
     .show_irq_sid = flask_show_irq_sid,
 };
 



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:58:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:58:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392726.1631718 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtAT-0006z3-4D; Mon, 17 Aug 2026 08:58:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392726.1631718; Mon, 17 Aug 2026 08:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtAT-0006yw-1Q; Mon, 17 Aug 2026 08:58:05 +0000
Received: by outflank-mailman (input) for mailman id 1392726;
 Mon, 17 Aug 2026 08:58:03 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvtAR-0006xn-Ol
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:58:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtAR-009RUc-5R
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:58:03 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cd1b-2eae-0a2a0a5409dd-0a2a450baa0e-0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:58:03 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cd1a-b7e8-0a2a450b0019-d155dd2ae830-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:58:02 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47f6609c657so1474512f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:58:02 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a31396sm2279394f8f.2.2026.08.17.01.58.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:58:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786957082; x=1787561882; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=8QVewtRw+TwFKfjqe5upIsoN/acNO1D5x9ht9JMPqQM=;
        b=EPu+UbRKbFFBoDP2pn29coHY9xhdEERQ3jCxcAru/9iN+sQusNc4vAn5hnalitVMI0
         JuRTcdqHqf6sK/hKqJ0KEJV5MV1XxSST3UwLOfsJ7QjatahiC5fcj0KQ79/TFcAqliwj
         CF5deqzKxRb57cQ4XFtvB5iyn7giOXpSPX5jQspwyDaI/vlcXYN1UgQxvemcvEePP02i
         PS6yUb1cY9UMNUTs8LHnQO8cBzrDVBLdPQHlFUT5W+Fgpa6Ldx9FvM29RX4JoOt6mKzh
         cdDSBthLJ80oAxPok3srArHX911JRyPwMMGmrQo8PhikH8mwE7g+YovS5JV5rdZkcOZJ
         AwUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786957082; x=1787561882;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=8QVewtRw+TwFKfjqe5upIsoN/acNO1D5x9ht9JMPqQM=;
        b=hWdbVfdW7ReBDJqJf9ncNwi7n7egR9XY8GwW9y8gXBjX3chdkrijlwE3LsYeVZVXvj
         FZSIXI9K4mFkcwAdCPbRFs4u/uO37HDtD3SFmOx8Wj/X8ZIrYyuwuyUYz8ZibyPOSelH
         k0RTsBEaaLVpJvNFuCwDo+y1aI5QxSWP2lxAGFf4PlnEWj+tuAqzlBpeh4ZnRoj9sKlP
         Ljj0/3Jg68b/5uaQA2kQS4UENyInjeKyAi4WWWHSQNX6ZJo8WGeTr9LBsESKzUQPAnaN
         mUKFza/7IjeZU0NtmopDlIoCKUxLZQ3q1FcXRM53LBqubocjCwaw5a8ghTX6PM0iiDZU
         fl8A==
X-Gm-Message-State: AOJu0YyWGECmjmRigHK6ytFqhU8ZEKlG7LQ/Wc7/IDWW3TLIy7VV+5AW
	+R3C263GhEpcMwR6gS4u8Z3aX2bbHjEKWjXgfe7BBLCZ6Ao/iHtcP7Ov3DEW+ISPhxhYMiUVrNc
	HHGHykA==
X-Gm-Gg: AR+sD10SmzfaX+8DV2IoQaEHbHx/QSw+9rPfyR0xuyFYZ5GS5SeIgC4pwTeZDRAC3P1
	pYtFMOdX/wUrjs4Vd9yvT8v5wsN+AK+PrmWqYW5chZ/+WqB+WihZXOHY2lPmsmzcp8kVWiVnN8J
	ItuvZblqtD7vSMhVSkSnscBL62bfG2af3sqYj5TRg76F6JACo21HmcG+adnKveApak/NNKxK3Nb
	aMwvDh4pa36OW3vQCVCUeuzY3XC2GASsQc918iU3ffcvTTDCGP4xPlirXmijYIsjM2HhmUTrchF
	chUQJVa+mU3pjjDFIgDpjA+3HA63qrffZ6m6Rl2SO6WfR8EuGcDDh08WhDyObzr2Fi/uruWTSiQ
	Q9eWBEc3dEWlkv0HdPwoWOKxxMKjIF4sRQx7CG5tiJBjZdAD3fliEoBCduE1cBcN8gEROY8kRxh
	ynIJrzhNPq1lifcRv89rhjqkjGeinkIs6vJm0tRRfb5Eu8KI4epEY15xUFip8uUO8A6mQai7lN+
	ChV2IfR8hMjq9sPygmqY9Lg397ccWnI6sDzL09tjZ5H9IglvD6E
X-Received: by 2002:a05:6000:240c:b0:47f:e9fd:80d8 with SMTP id ffacd0b85a97d-481607947e2mr34071751f8f.21.1786957082432;
        Mon, 17 Aug 2026 01:58:02 -0700 (PDT)
Message-ID: <aac7d8fa-ef0d-4146-883f-deb9ec04a519@suse.com>
Date: Mon, 17 Aug 2026 10:58:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 13/14] XSM: convert remaining miscellaneous hooks
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>, Julien Grall
 <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1786957082-A8ECE9EA-746152B0/0/0
X-purgate-type: clean
X-purgate-size: 5160

Make the ones left also follow the standard scheme, i.e. taking
xsm_default_t as first argument at call sites. This way they can be
covered by the recently introduced hook machinery.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Interestingly .show_irq_sid() is unused on Arm. Oddly there's no use of
register_keyhandler() there at all. (IOW I think it would be wrong to make
the hook x86-only.)
---
v2: New.

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -497,7 +497,7 @@ void asmlinkage __init noreturn start_xe
     /* Hide UART from DOM0 if we're using it */
     serial_endboot();
 
-    if ( (rc = xsm_set_system_active()) != 0 )
+    if ( (rc = xsm_set_system_active(XSM_HOOK)) != 0 )
         panic("xsm: unable to switch to SYSTEM_ACTIVE privilege: %d\n", rc);
 
     system_state = SYS_STATE_active;
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2549,7 +2549,7 @@ static void cf_check dump_irqs(unsigned
         if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
             continue;
 
-        ssid = in_irq() ? NULL : xsm_show_irq_sid(irq);
+        ssid = in_irq() ? NULL : xsm_show_irq_sid(XSM_HOOK, irq);
 
         spin_lock_irqsave(&desc->lock, flags);
 
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -835,7 +835,7 @@ static void noreturn init_done(void)
     unsigned long start, end;
     int err;
 
-    if ( (err = xsm_set_system_active()) != 0 )
+    if ( (err = xsm_set_system_active(XSM_HOOK)) != 0 )
         panic("xsm: unable to switch to SYSTEM_ACTIVE privilege: %d\n", err);
 
     system_state = SYS_STATE_active;
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -104,10 +104,12 @@ static always_inline int xsm_default_act
     }
 }
 
-static XSM_INLINE int xsm_set_system_active(void)
+static XSM_INLINE int xsm_set_system_active(XSM_DEFAULT_VOID)
 {
     struct domain *d = current->domain;
 
+    XSM_ASSERT_ACTION(XSM_HOOK);
+
     ASSERT(d->is_privileged);
 
     if ( d->domain_id != DOMID_IDLE )
@@ -467,8 +469,9 @@ static XSM_INLINE int xsm_do_compat_op(X
 
 #endif /* CONFIG_XSM */
 
-static XSM_INLINE char *xsm_show_irq_sid(int irq)
+static XSM_INLINE char *xsm_show_irq_sid(XSM_DEFAULT_ARG int irq)
 {
+    XSM_ASSERT_ACTION(XSM_HOOK);
     return NULL;
 }
 
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -17,6 +17,8 @@
 
 #endif /* XSM_HOOK */
 
+XSM_HOOK(int, set_system_active)
+
 XSM_HOOK(int, domain_create, struct domain *, uint32_t)
 XSM_HOOK(int, getdomaininfo, struct domain *)
 XSM_HOOK(int, get_domain_state, struct domain *)
@@ -84,6 +86,8 @@ XSM_HOOK(int, irq_mapping, struct domain
 XSM_HOOK(int, pt_irq_binding, struct domain *, struct xen_domctl_bind_pt_irq *,
                               bool)
 
+XSM_HOOK(pchar_t, show_irq_sid, int)
+
 XSM_HOOK(int, irq_permission, struct domain *, int, bool)
 XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, bool)
 
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -61,7 +61,6 @@ typedef enum xsm_default xsm_default_t;
  * !!! WARNING !!!
  */
 struct xsm_ops {
-    int (*set_system_active)(void);
 
 #define XSM_HOOK0(rtype, name) rtype (*name)(void);
 #define XSM_HOOK1(rtype, name, type1) \
@@ -77,7 +76,6 @@ struct xsm_ops {
 
 #include "hooks.h"
 
-    char *(*show_irq_sid)(int irq);
 };
 
 #ifdef CONFIG_XSM
@@ -86,11 +84,6 @@ extern struct xsm_ops xsm_ops;
 
 #ifndef XSM_NO_WRAPPERS
 
-static inline int xsm_set_system_active(void)
-{
-    return alternative_call(xsm_ops.set_system_active);
-}
-
 #define XSM_ALT_void      alternative_vcall
 #define XSM_ALT_int       return alternative_call
 #define XSM_ALT_pchar_t   return alternative_call
@@ -138,11 +131,6 @@ static inline rtype xsm_ ## name( \
 
 #include "hooks.h"
 
-static inline char *xsm_show_irq_sid(int irq)
-{
-    return alternative_call(xsm_ops.show_irq_sid, irq);
-}
-
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -14,7 +14,6 @@
 #include <xsm/dummy.h>
 
 static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
-    .set_system_active             = xsm_set_system_active,
 
 #define XSM_HOOK0(rtype, name) .name = xsm_ ## name,
 #define XSM_HOOK1(rtype, name, ...) XSM_HOOK0(rtype, name)
@@ -25,7 +24,6 @@ static const struct xsm_ops __initconst_
 
 #include <xsm/hooks.h>
 
-    .show_irq_sid                  = xsm_show_irq_sid,
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1903,7 +1903,6 @@ static int cf_check flask_get_domain_sta
 }
 
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
-    .set_system_active = flask_set_system_active,
 
 #define XSM_HOOK0(rtype, name) .name = flask_ ## name,
 #define XSM_HOOK1(rtype, name, ...) XSM_HOOK0(rtype, name)
@@ -1914,7 +1913,6 @@ static const struct xsm_ops __initconst_
 
 #include <xsm/hooks.h>
 
-    .show_irq_sid = flask_show_irq_sid,
 };
 
 const struct xsm_ops *__init flask_init(



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 08:58:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 08:58:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392733.1631728 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtBB-0007gq-D1; Mon, 17 Aug 2026 08:58:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392733.1631728; Mon, 17 Aug 2026 08:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtBB-0007gj-9U; Mon, 17 Aug 2026 08:58:49 +0000
Received: by outflank-mailman (input) for mailman id 1392733;
 Mon, 17 Aug 2026 08:58:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvtB9-0007gT-Vn
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 08:58:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtB8-005H11-Jl
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 10:58:46 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cd38-8faa-0a2a0a5109dd-0a2a4509baf2-32
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:58:46 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82cd46-be1a-0a2a45090019-d155dd2eb887-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:58:46 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47362928f65so3040073f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:58:46 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d11f073sm28466565e9.15.2026.08.17.01.58.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:58:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786957126; x=1787561926; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=JTfzh5nMGjglXFSQtaFq+GPWNKgrY8T3kAqW5LSmjgc=;
        b=cgTUpKGY5VsugGAI0/KhXS+MYDhS3vL+p82T7JjpaUifAttT7566OfO8qkG6IQzOL3
         Y8TZXRVZxYlN8+FYh2s4IoKBZfBwdnpg2S9l3xxkk8hgMKaGUfYLg45Js2KJHLVZ2+V7
         upp/VLkU1gjq7oJJt9riTI+RMCSKbWsMsTcr8h1duU3vbtecOYEsFnM4O5vUUBnON8Sr
         ScWypRu9zkaVl6RyMCrJDXP9WnZPcV7a3w+ZrvqYktfN9t443M+5U2h0U2z8Z2+pl3zc
         QonP3/pTmBwmLgzAmW1X+CBVxbIsidTeCptk8hZoRSBS3YovcY/k67ePniNHvVFd+5ig
         UJgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786957126; x=1787561926;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=JTfzh5nMGjglXFSQtaFq+GPWNKgrY8T3kAqW5LSmjgc=;
        b=UQy0Vbzgtyy10xhWxak45rrLZQJ4JD4vN64Hs44i6BoZuxi6d2UYitjIKF3ZLhrrtD
         LbEUVAE8PxSRE+Gwj02lCJ8xMvBvuvo2MEe4bzg8ZxWuHxebpsWu7lh28B+cZ29LXTPW
         +7EXIey5pJVlTgMu71Iu5cUxKqR5IenJ3MpNkVESHNVZ1x6l9Mc9clD1n15Rf4Io5pVH
         +9NY4Opi22zC17r6DlP+EjTV05V6VqdEIy6B+g4yQw+dJpJsAqcxRzR0FTv8jvL9GZwe
         NEnOaAxAo1jhqn+RCZUa+kaG2C4u4wrt2dRJ2BnOoUH70p6SO4FkqVJjDoj/814X/5gq
         y2pA==
X-Gm-Message-State: AOJu0Yxr/P/cbAsVomNKzPdL4GKKxjePChedHtC8q36Ty/no8aCPYx7F
	3Fp0rTfnGZc6f2+Qy/q8Kv0Ot98/1XIOJAL+LDu149NjSHY7hpXRMO8IDTD0YQ0BntvAlcdz47c
	nC956yQ==
X-Gm-Gg: AR+sD12ZTIq4dlEFOmbqG1NCISa0NI5ISajzaxl59jnk1Mf0EfOE78Vlc6E5dpHMSaj
	2OzsdAiwPp9hycKRNXOJWD43z+82owUEAZlRHvQJz3h1BAEBK5sjbLQ1t7/sNPY498V+PGWNns+
	BnOn/nVJv1CkY19i3E6ActiEqXvBqH4/v5uo8aoUz9IPbgEKhx8JhQ7RjoYqBeidmnD8+4eNt7j
	ikWpyZvA+B7JhyowntHw2kHEijqK4gk3KJ7ANt4B+0GAdh3tK/LXUtw0codBWAVoDUJw4jCD1hP
	tnEoJwhEtRwAoSt2CXFNl895yvveUaU+OOnANViNBpmnYZs8FxixVSamO3A8FKiXVO4pDrj8zvC
	7mwyNwAYKpnH/AFs1RjUYy8h6jGd1M7CsMgxsIW7DAYBrmD0t0BVC5Lze0HDUR8XCW4pdmc/1+H
	cj6+TzztS8SJtMKOlkfxBoqXNxrZBNLszIdhd9wasxrDIbL+3H8RTH2bSM7OVw7JekMuaS9RT+z
	lFRVmfDRSjxaYd3K7by8qYmAhn+iPwMkps+PMlCltns2u5tNvTbzQ==
X-Received: by 2002:a05:600c:3585:b0:499:9eb7:4558 with SMTP id 5b1f17b1804b1-4999eb7462amr4762655e9.10.1786957126079;
        Mon, 17 Aug 2026 01:58:46 -0700 (PDT)
Message-ID: <0511f8a7-7790-44c3-addd-67a969f4f5c1@suse.com>
Date: Mon, 17 Aug 2026 10:58:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH RFC v2 14/14] XSM: avoid fragile assumptions in
 xsm_fixup_ops()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786957126-BD8C1034-97BB62B4/0/0
X-purgate-type: clean
X-purgate-size: 3645

Using the recently introduced hook machinery, the assumptions made can be
avoided, at the expense of a significant code size increase.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: Of course the significantly increased code size isn't nice. Yet then
     it's all .init.text bloat only.

RFC: The asm() is somewhat like RELOC_HIDE(), with an offset of 0. It
     didn't feel quite right to use that macro here, though.

The generated code I've looked at (both for x86 and Arm64) it is clear
that a similar weakness in codegen exists for the recurring accesses to
_{s,e}text[] by is_kernel_text(): A register variable each would shrink
code size significantly, yet that doesn't appear to happen at -O1. Yet
open-coding isn't an option, imo.
---
v2: New.

--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -51,15 +51,6 @@ typedef enum xsm_default xsm_default_t;
 #define XSM_MMU_MACHPHYS_UPDATE  8
 #endif /* CONFIG_X86 */
 
-/*
- * !!! WARNING !!!
- *
- * For simplicity, xsm_fixup_ops() expects that this structure is made
- * exclusively of function pointers to non-init functions.  Think carefully
- * before deviating from the pattern.
- *
- * !!! WARNING !!!
- */
 struct xsm_ops {
 
 #define XSM_HOOK0(rtype, name) rtype (*name)(void);
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -28,29 +28,35 @@ static const struct xsm_ops __initconst_
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
 {
+    const struct xsm_ops *dops = &dummy_ops;
+
     /*
-     * We make some simplifying assumptions about struct xsm_ops; that it is
-     * made exclusively of function pointers to non-init text.
-     *
-     * This allows us to walk over struct xsm_ops as if it were an array of
-     * unsigned longs.
+     * To limit the size of generated code (by avoiding the compiler using
+     * dummy_ops directly for every access), hide the relationship between
+     * dops and dummy_ops.
      */
-    unsigned long *dst = _p(ops);
-    const unsigned long *src = _p(&dummy_ops);
+    asm ( "" : "+r" (dops) );
 
-    for ( ; dst < (unsigned long *)(ops + 1); src++, dst++ )
-    {
-        /*
-         * If you encounter this BUG(), then you've most likely added a new
-         * XSM hook but failed to provide the default implementation in
-         * dummy_ops.
-         *
-         * If not, then perhaps a function pointer to an init function, or
-         * something which isn't a function pointer at all.
-         */
-        BUG_ON(!is_kernel_text(*src));
+    /*
+     * If you encounter the BUG() below, then you've most likely added a
+     * new XSM hook but failed to provide the default implementation in
+     * dummy_ops.
+     *
+     * If not, then perhaps a function pointer to an init function, or
+     * (less likely) something which isn't a function pointer at all.
+     */
+#define XSM_HOOK0(rtype, name)                    \
+    do {                                          \
+        typeof(xsm_ ## name) *dummy = dops->name; \
+        BUG_ON(!is_kernel_text(dummy));           \
+        if ( !ops->name )                         \
+            ops->name = dummy;                    \
+    } while ( false );
+#define XSM_HOOK1(rtype, name, ...) XSM_HOOK0(rtype, name)
+#define XSM_HOOK2(rtype, name, ...) XSM_HOOK0(rtype, name)
+#define XSM_HOOK3(rtype, name, ...) XSM_HOOK0(rtype, name)
+#define XSM_HOOK4(rtype, name, ...) XSM_HOOK0(rtype, name)
+#define XSM_HOOK5(rtype, name, ...) XSM_HOOK0(rtype, name)
 
-        if ( !*dst )
-            *dst = *src;
-    }
+#include <xsm/hooks.h>
 }



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 09:11:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 09:11:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392743.1631736 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtND-0002a1-DF; Mon, 17 Aug 2026 09:11:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392743.1631736; Mon, 17 Aug 2026 09:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtND-0002Zu-A8; Mon, 17 Aug 2026 09:11:15 +0000
Received: by outflank-mailman (input) for mailman id 1392743;
 Mon, 17 Aug 2026 09:11:13 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvtNB-0002Zo-JN
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:11:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtNA-00GDeY-5g
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:11:12 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82d02b-bab6-0a2a0a5309dd-0a2a450994e6-28
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:11:11 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82d02f-be1a-0a2a45090019-d155802ecd53-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:11:11 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-498028b3d5eso40026965e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 02:11:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999610966dsm172724165e9.5.2026.08.17.02.11.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 02:11:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786957871; x=1787562671; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=h0XiEa/dg7Ps/rOaNVwO3/fLFGtu4AMy8RPHfE0rkwQ=;
        b=Rw84ZXIecgPgPqlXT1/zrOsqL+3qWrkjMdP1FmimJo1GES+/ucNOR6rmiiZkRCGWc0
         YTY/hl5wUiVn+dxPmqWQV8tgE887x/YFYaFQfNGwmZvH53nMmWTA+x0pK+ggNSAksGXI
         dBpSPXgqxQRojlWqcK7mCLf/wj17wR1aRH97y350t3GDGvqy6y2CrxLO7KAiHm003b+5
         0LJQ8ZUDiClAbnGaa60lBZvrQCKD7cghQP+AADOsujqtD7AJgvvpV2KXje4vkpl2wxQm
         eTHAjYEZWlLmhQ3pEfasN4K//VgMO8JMxKRNK0rqboDJjvKnt3sc5czcWTkVLUF8hmNZ
         C5tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786957871; x=1787562671;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=h0XiEa/dg7Ps/rOaNVwO3/fLFGtu4AMy8RPHfE0rkwQ=;
        b=geR/Q+KV0/fm/Flck67MK67M7UMZZJFJH5hK6D+8cBXhOf3zviz3Nl8GKtFVhSXlen
         adVJNhDB8HvfL9LSVIFdqMka+MrPCX+JgNrn6SlXzQl26r50QCUftCquFteDeVbegE1G
         od5V6369XsawLbZRcVDDf9JJyUBlXHA07jBITGqETKwSzs1SJDfDOFWiHbFRf9mitQUY
         dul3ZN23ek5tPpNWt6mtDMxfMEBouHrUHd6H32//JmgV217LMWYxE+OjbKEp87mFWM7l
         XiJj2rfu7g0otDwY3lIJJzqgyQlXjnNvph56DmJGNZgd+rEAzjNh5gcbZcBXkwMz+lBM
         KjYA==
X-Forwarded-Encrypted: i=1; AHgh+RrxCSssgEh9TsaPKL+V2VT9BQ9xYP8+MT2YEo5LwzJbfDliX1e0xGHCgQ5wBfvQ5p5otqxodKFKpW4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YztTX5H1vKRC7hETj4DitKSKSKRp8P/BGMP1VTV3ysxG9Q+xVb2
	XIrlJcRTLza/0A9RyCzCLsYigT6BWQzCaTjW7GrZEiyMLmehun28X+tUa3Xh4S/0Yw==
X-Gm-Gg: AR+sD10qP4AcNSQjSzTlvkvPun5GPqlGi9XEVSggqnax3T0cRcnml1/W1p5iVQ7jbiE
	O9h6qW6t0mKSnYiXy9vibHxmpAdOEib/2FDBjX6yLzVG45Ct4JoZjyDRFCuGKH1BDaXqppN+lIK
	qxd0/kJ7sutPnC9hZ9aISJJkynFbMjDuQ4Q7Nyc6okC0PxYIhfMrIt32arVVEcKYXD9jrvKbIy+
	TLo8H2APg2bOt2UEtvRm7SLwNCL4fTIa3tVVcdPWtbLNqEVK8SVSVKDt/bMTy1tr1uYafQqxcro
	GJ/ugJBVd+mHKrD3yGxcEjgnS6pgQZdnAk/pq52la+UinmY0W/W+j6I419lm4eyU2Jn54VC0Bt2
	DhZXP1xW+iglICumyZ+cLmJYwlp4KCdqGvKFmi/z27u3+pU8x/wiD/ITXay3kW7gi1FGH92fWRH
	vHYSmsIv0x2dZnUp+//t4G676XPhH/UMy0wEWpKcmZ1C9b0jos7r17mgXiqG6QjT/Mmf+y+xCYO
	rOluwg4r6z/gma6tToOl6WI8OiPsoHpC1pfm+voevGNShUtYP5B4Q==
X-Received: by 2002:a05:600c:3398:b0:499:52dd:c1f0 with SMTP id 5b1f17b1804b1-499879298c4mr237379625e9.1.1786957871379;
        Mon, 17 Aug 2026 02:11:11 -0700 (PDT)
Message-ID: <4f2c7c16-74b8-4a93-868e-94628bb9fa78@suse.com>
Date: Mon, 17 Aug 2026 11:11:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <9cf5c34b-65a9-4e19-8dfb-9f1264988d5b@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9cf5c34b-65a9-4e19-8dfb-9f1264988d5b@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786957871-BD0CD034-5E65DE5A/0/0
X-purgate-type: clean
X-purgate-size: 5882

On 15.08.2026 04:22, Chuck Zmudzinski wrote:
> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>>>>> +
>>>>>>> +    if ( !rvds || !rvda_host ) {
>>>>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>>>>> +        rvda_host = 0;
>>>>>>> +    }
>>>>>>> +    /*
>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>> +     * after we also write the guest address where the
>>>>>>> +     * VBT will be mapped.
>>>>>>> +     *
>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>> +     */
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>
>>>>>> Why would you need to communicate a host property to the DM?
>>>>>
>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>
>>>> I don't follow this: Anything the guest can access should also be accessible
>>>> by its DM.
>>>
>>> I think the host OpRegion is not currently accessible by the DM.
>>
>> Can you explain to me how the region becomes accessible to the guest?
>> That would then (hopefully) help me understand why the DM would not have
>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>> guest are also assigned to its DM.
> 
> This is what I don't understand about your objection to how both the current
> implementation and my proposed changes makes the host OpRegion accessible to
> the guest. What do you mean when you say any MMIO and I/O ports assigned to
> a guest are also assigned to its DM? What does it mean to assign an MMIO
> region to a DM? Is it the DM you mean or the DM domain, which need not be
> dom0 if we are running the device model in an unprivileged domain.

The DM domain is what I meant. I thought that was clear / unambiguous here,
but apparently it wasn't: Sorry. Beyond that I hope that my reply to your
earlier mail provides sufficient further context.

> I also
> am presuming you know that dom0 for Intel IGD passthrough is a PV dom0,
> not a PVH dom0. I have never tried Intel IGD passthrough with a PVH dom0,
> because as far as I can tell vt-d is not supported with PVH dom0.

I don't see why PVH Dom0 would start to matter here all of the sudden.

> Take a look at this code from our current implementation in qemu-xen. This
> is from the current master branch of qemu-xen on xenbits.xen.org, the
> hw/xen/xen_pt_graphics.c file, the igd_write_opregion function:
> 
> --- snip ---
> 
> #define XEN_PCI_INTEL_OPREGION_PAGES 0x3
> #define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
> void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
> {
>     int ret;
> 
>     if (igd_guest_opregion) {
>         XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
>                    val);
>         return;
>     }
> 
>     /* We just work with LE. */
>     xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
>             (uint8_t *)&igd_host_opregion, 4);
>     igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
>                             | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK);
> 
>     ret = xc_domain_iomem_permission(xen_xc, xen_domid,
>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>             XEN_PCI_INTEL_OPREGION_PAGES,
>             XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);

So this is where permissions are granted (wrongly imo, as I think permissions
for MMIO or I/O ports should only ever be granted by the control domain).

>     if (ret) {
>         XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
>                     " 0x%lx.\n", ret,
>                     (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)),
>         igd_guest_opregion = 0;
>         return;
>     }
> 
>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>             XEN_PCI_INTEL_OPREGION_PAGES,
>             DPCI_ADD_MAPPING);

This is where, as said in the earlier reply, a mapping is installed in the
guest's P2M.

>     if (ret) {
>         XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
>                     " guest opregion:0x%lx.\n", ret,
>                     (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>                     (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
>         igd_guest_opregion = 0;
>         return;
>     }
> 
>     XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
>                     (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>                     (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
> }
> 
> [...]
> 
> Do you understand now?

Yes, and as said in the earlier reply: This demonstrates that the DM does
have permission to access the pages in question.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 09:15:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 09:15:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392753.1631745 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtR4-0003EY-Um; Mon, 17 Aug 2026 09:15:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392753.1631745; Mon, 17 Aug 2026 09:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtR4-0003ER-Rv; Mon, 17 Aug 2026 09:15:14 +0000
Received: by outflank-mailman (input) for mailman id 1392753;
 Mon, 17 Aug 2026 09:15:14 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvtR4-0003EJ-Aj
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:15:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtR3-007wvY-3J
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:15:13 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82d11b-bab6-0a2a0a5309dd-0a2a450581b6-16
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:15:13 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82ccab-4cb1-0a2a45050019-d1558029d47f-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:56:12 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-49954b88fffso35273405e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 01:56:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d078523sm26288775e9.6.2026.08.17.01.56.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 01:56:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786956971; x=1787561771; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=AEdc8GQ0X7pW91c3IJ6VKmtma1QrK/AiK+09OB1ma3I=;
        b=DoBInu21q/5nILPbRnbDGqbwzxbg5Vsv5E05GQacq+UUcTO1sepRNwOa5HzSht9Nqt
         WOVrNG6Pm3EfssQgremI3YuinivuMxGGtumUe16eKxBRmcQ2PrQLqWOLDZ0s5+nei0ts
         IME+iYmdKV8os1nqVg6in8AdXOqDFxK74fMwImH8QRv+rHnP0spOuP71AGTYg9JYCtPb
         17Ue0yV/GvK5xDQ+dekpdmCZkhrERMpEqt0y4SVsrXPl5NyR9IOaX9DS7fQt2FrgfkEu
         YOHea3H7q6Oq9lPXphFUa0lA1nl9JMghQ7Mn2oNUqtpTCu0SwdiuO9cdQbkNB66xxvbE
         WQWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786956971; x=1787561771;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=AEdc8GQ0X7pW91c3IJ6VKmtma1QrK/AiK+09OB1ma3I=;
        b=TH1yijPr8KwZb1aW1YeewoOc0b3/0FI2miai4j0FLCX3Rahi4Wy47W5UTwQVgz/tAy
         IwgJ5w0N99Tm5xwnpoTS62yxGHwXv+gCyg9YGZL+b4a4Ha3tT3h4Gvx5VRv30pHjde5x
         SbtyuVXLs/yJWN/h5Up5VAf7AMgmJsYo80NIUtMxwWXsCndtHyk0xRSkQiKigENhQVA7
         EuJqs24xM0Y4RUBOUqToE8n7q/po6k5YWQ5z8XRDkF2aGizik9cizTrTLIMkz3dtIVd2
         C+zBW6/jsSspmB7+yam0VIsI0u9qy4/zN3FM3cUhzneFF0tH1gvwNrXu0ozCEFR3zf5H
         L7ZQ==
X-Gm-Message-State: AOJu0Ywxdajk2TmpH1/7OvSo9Bp2hB0a05kIQ6D6+uCRrn2uyUgavT8O
	JPSnmoXVwIHUySf2JW9ynd8HDLJfqbd/M5NBEOJ9Bw1e/l3us9fq0CESaqMyvrkmOmlNMHRxhvS
	h7wDExg==
X-Gm-Gg: AR+sD13APOL4AYPBDqc9NCjuKwyfxxzevkZUZipzYmir9NjGa1tV4RGYg0KlhkGypVB
	BcHHNoU4lOrCKp3VsuYbejs4Btny9CStm5GqbIMxjbaUzUwYWsPbyM655aQSnZNsbai4C3iAW4Q
	tbjk91SwGbIxfT01wsGJhh9UPwMCgDFo+sgpiQ6n2wTHkGcEmOBaZz5zTwhjNC8SvfDNeEtiKyN
	hhbqz+Szx9kYcKIJNL8fEzFwZhf8tAfK8jEgIxYbBXhc8/pw/QcR1RHQv5TiZQJfbdVkIvhSeTJ
	g6nsTW80Nbo72f3X2cO+XmrjauAfLHVaF498RUj0hCqCu22n+m8R70ElXKMZIZkO08DR63KJ82p
	K0NgZVGJYfwuA2EKxggrt46Rjtc0vQ/8QGpcwG/hLHBP0Yob1MMk2U/TyGSxqR0kSn9BeijxKfp
	giZIWnR2yiG71/VheJO0L5rWLwZpedmSz6aGcn2GiXFE1GdjLATAet1UkMSsnubjbPMMqTU92Zu
	CSSAXpWSyP6Bc9BH/JzpwuwNzGUnYOxcYSMaPriL/+FQLxz5mxL
X-Received: by 2002:a05:600c:3114:b0:495:63e4:7f78 with SMTP id 5b1f17b1804b1-49987971986mr337054185e9.10.1786956971404;
        Mon, 17 Aug 2026 01:56:11 -0700 (PDT)
Message-ID: <51370c2d-89dd-4c82-9cc6-53a560d1c9ac@suse.com>
Date: Mon, 17 Aug 2026 10:56:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 10/14] XSM: fold xsm_{,un}bind_pt_irq() hooks
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Daniel Smith <dpsmith@apertussolutions.com>, Julien Grall
 <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1786956972-714AC2A1-26582E4F/19/8833835083
X-purgate-type: clean
X-purgate-size: 4607

Like other resource management hooks they are mainly different in "add
resource" vs "remove resource". Hence like in other cases a single hook
can easily serve both purposes, with minor tweaking of
flask_bind_pt_irq(). While adjusting that function, also defer the setting
of "dperm", which is only needed in the "map" case.

Rename hook and functions to fit xsm_{io{mem,port},{p,}irq}_mapping().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Fix inverted part of conditional in flask_bind_pt_irq(). Rename hook,
    functions, and new parameter.

--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -104,7 +104,7 @@ long arch_do_domctl(struct xen_domctl *d
         if ( rc )
             return rc;
 
-        rc = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind);
+        rc = xsm_pt_irq_binding(XSM_DM_PRIV, d, bind, true);
         if ( rc )
             return rc;
 
@@ -140,7 +140,7 @@ long arch_do_domctl(struct xen_domctl *d
         if ( irq != virq )
             return -EINVAL;
 
-        rc = xsm_unbind_pt_irq(XSM_DM_PRIV, d, bind);
+        rc = xsm_pt_irq_binding(XSM_DM_PRIV, d, bind, false);
         if ( rc )
             return rc;
 
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -622,7 +622,7 @@ long arch_do_domctl(
         if ( !is_hvm_domain(d) )
             break;
 
-        ret = xsm_bind_pt_irq(XSM_DM_PRIV, d, bind);
+        ret = xsm_pt_irq_binding(XSM_DM_PRIV, d, bind, true);
         if ( ret )
             break;
 
@@ -660,7 +660,7 @@ long arch_do_domctl(
         if ( !is_hvm_domain(d) )
             break;
 
-        ret = xsm_unbind_pt_irq(XSM_DM_PRIV, d, bind);
+        ret = xsm_pt_irq_binding(XSM_DM_PRIV, d, bind, false);
         if ( ret )
             break;
 
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -477,15 +477,9 @@ static XSM_INLINE int xsm_irq_mapping(
     return xsm_default_action(action, current->domain, d);
 }
 
-static XSM_INLINE int xsm_bind_pt_irq(
-    XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    XSM_ASSERT_ACTION(XSM_DM_PRIV);
-    return xsm_default_action(action, current->domain, d);
-}
-
-static XSM_INLINE int xsm_unbind_pt_irq(
-    XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+static XSM_INLINE int xsm_pt_irq_binding(
+    XSM_DEFAULT_ARG struct domain *d, struct xen_domctl_bind_pt_irq *bind,
+    bool map)
 {
     XSM_ASSERT_ACTION(XSM_DM_PRIV);
     return xsm_default_action(action, current->domain, d);
--- a/xen/include/xsm/hooks.h
+++ b/xen/include/xsm/hooks.h
@@ -72,8 +72,8 @@ XSM_HOOK(int, pirq_mapping, struct domai
 #endif
 
 XSM_HOOK(int, irq_mapping, struct domain *, int, const pci_sbdf_t *, bool)
-XSM_HOOK(int, bind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
-XSM_HOOK(int, unbind_pt_irq, struct domain *, struct xen_domctl_bind_pt_irq *)
+XSM_HOOK(int, pt_irq_binding, struct domain *, struct xen_domctl_bind_pt_irq *,
+                              bool)
 
 XSM_HOOK(int, irq_permission, struct domain *, int, bool)
 XSM_HOOK(int, iomem_permission, struct domain *, uint64_t, uint64_t, bool)
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1089,17 +1089,16 @@ static int cf_check flask_irq_mapping(
     return avc_has_perm(dsid, sid, SECCLASS_RESOURCE, dperm, &ad);
 }
 
-static int cf_check flask_bind_pt_irq(
-    struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+static int cf_check flask_pt_irq_binding(
+    struct domain *d, struct xen_domctl_bind_pt_irq *bind, bool map)
 {
-    uint32_t dsid, rsid;
+    uint32_t dsid, rsid, dperm;
     int rc = -EPERM;
     int irq;
     struct avc_audit_data ad;
-    uint32_t dperm = flask_iommu_resource_use_perm(d);
 
-    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
-    if ( rc )
+    rc = current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(map));
+    if ( rc || !map )
         return rc;
 
     irq = domain_pirq_to_irq(d, bind->machine_irq);
@@ -1113,13 +1112,9 @@ static int cf_check flask_bind_pt_irq(
         return rc;
 
     dsid = domain_sid(d);
-    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, dperm, &ad);
-}
+    dperm = flask_iommu_resource_use_perm(d);
 
-static int cf_check flask_unbind_pt_irq(
-    struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, dperm, &ad);
 }
 
 static int cf_check flask_irq_permission(



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 09:18:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 09:18:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392760.1631753 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtUI-0003ys-Bj; Mon, 17 Aug 2026 09:18:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392760.1631753; Mon, 17 Aug 2026 09:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtUI-0003yl-94; Mon, 17 Aug 2026 09:18:34 +0000
Received: by outflank-mailman (input) for mailman id 1392760;
 Mon, 17 Aug 2026 09:18:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wvtUG-0003yc-So
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:18:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtUG-009WZX-0o
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:18:32 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82d1c7-e002-0a2a0a5209dd-0a2a45018378-44
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:18:31 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a82d1e7-5984-0a2a45010019-d155802ed089-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:18:31 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-495757ccbc1so28326695e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 02:18:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d0876b8sm33985065e9.8.2026.08.17.02.18.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 02:18:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1786958311; x=1787563111; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=hbkYtSJwMzBKBO/qIaZ9S5VqcBP390ZyMFSdmF8cAK0=;
        b=HZW+lrLUP8XfqZMrufWIQqXczD6KQ8tZKte70SBoVZ04aFfa3GcmlmQBUFwn+B+FtS
         oANGw9VguK2yLWG3X9LmFOeGI+6iryx+2SemZ6ImQVCrM53IW0gfGBZ01FmoblJOT4PE
         MeHgyHJ98JvvciO0EJHb4SHEfTf2eUMH74OWrhDtk3P8AjjjPtWttO1Kbt4ffUV/rQ5G
         1WjHjiTu2qCRIWyocDgiGKG/q0EsLtC34yR4fDNPz7/BPANa4ll081apyWril4eq6flC
         SJ/PfYF8X5lSL20Qap0v1x2aRR/rzPANIleDFytblyaLYFnoDTPIumzOq4K/2IpYJr5L
         sj2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786958311; x=1787563111;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=hbkYtSJwMzBKBO/qIaZ9S5VqcBP390ZyMFSdmF8cAK0=;
        b=jM1J7KT3Q2vmdwX1CpwtnPwgyu9ke8vHGVyBlyAFbSKKU2fqKNJfva4pXKJJvhRQtQ
         t87g/lXfT3ZjKjnSDvYn/ooU9CA2Rw2X5533FTx2RGZrQiA7XSTKXraXmtZZ4m0Zc6uR
         gM7ylr5P3NsJL68tcRlT0yHWHTcZ47JnUlduuZx66gGpORgx5YMpQne2JlTbi8M7hE4e
         9805zvJ+kg0EJQ7NWeaBvmdOPg5PtFU9LlmiBYNK+YAdEcabzcYZ4mvJzFNac0NoJ3aQ
         HC6DWCvsolLhrLA8AgfLExLe1cbIrq8NjZRoWvMizPl8/htmoBapOWrH4EDJnFkyc6zk
         7lxA==
X-Forwarded-Encrypted: i=1; AHgh+RpYEhsdNsidaQoJIYdmdYmux+E+pSZTcM1l+CIo/MhkQwUIPX7m0twEiuO1t7LEkGuqrCnZGPSpkgQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw9R0zEbIXKmmGxyRAOv4APT1QH9l//v79PGUZmMhUjTXYvXDyD
	o39gwiKo+yBt7SKNbwr/1wCLnyN5VARBVAD5EYHhDS8+iKCXd+29eI4RoPfIlwpGpw==
X-Gm-Gg: AR+sD12lttRieYdQsPTrFvcjVH+9CYDjS7wkFk3ZqVtmTM6RbXzgHo9G/w2e/ICMn8Q
	kzqBDXHhV0MJVvVAgnwzCHs9FAbXJ53ZdJEfyGOEH4oFOW6fEJWVo1a5t2yJhG+VP5wQDXNVmmO
	8jyozbpsgicHFcW1ScHzKC1LvcWXI1QahauCEdlgPYjkWYGUrXWFjOHzSAJdEk7LscmIG2gOyfi
	bI/uLQ47GFdTcUGK40V9kMAdp0BN3vpsswLX4QiNThcbDPp3+I3RGpo4kn1m2cpjtmre3wiINqQ
	MOHaZd6OoRhu1fN2/wAXLb2//aEKORgobhDp2iPy+9y3WxdRmU0DmSucQTroju1Lwv+JjIkWCyF
	7V6v8vUKUcvdK1aoDe0fJ0mLZ4qNCfEcSbDPczUEU6bPeRaHgfnMmux1Dhtdp7o+BLIk/snui4f
	HbrvkI6yA4tn3oo7S5Uh1y6LYEE8J+yWmp7dgo/Gz6OBPorOszY4d94OZIIJsrYhSMI4ZYSZLO5
	YkO71XY4V+QhVFDqEogqNpq0BZAKXk6CHzw36gqPeKnTuDYU8G4AyJY226PNhQ=
X-Received: by 2002:a05:600c:871b:b0:499:8b00:5261 with SMTP id 5b1f17b1804b1-4998b0052cdmr336753065e9.8.1786958311160;
        Mon, 17 Aug 2026 02:18:31 -0700 (PDT)
Message-ID: <0086d141-f434-41ef-8048-078882bf3818@suse.com>
Date: Mon, 17 Aug 2026 11:18:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <a98b7e5f-240b-4642-b488-fac69846b3f8@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <a98b7e5f-240b-4642-b488-fac69846b3f8@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1786958311-1E465757-1433EE64/0/0
X-purgate-type: clean
X-purgate-size: 6056

On 16.08.2026 18:38, Chuck Zmudzinski wrote:
> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>> -- snip --
>>>>> +    /*
>>>>> +     * Read the value the device model is initialized with.
>>>>> +     * If the device model supports OpRegion 2, it will
>>>>> +     * return the host IGD OpRegion address. If not, it
>>>>> +     * will return 0. If the device model does not support
>>>>> +     * OpRegion 2, the device model expects us to give it
>>>>> +     * the address to which it will map the OpRegion in the
>>>>> +     * guest and then expects us to do nothing more to setup
>>>>> +     * the OpRegion, so that is all we will do in that case.
>>>>> +     */
>>>>
>>>> Hmm, exposing the host opregion to a guest certainly feels like an issue.
>>>
>>> Well, that is how it is now. I am only retaining it to maintain backward
>>> compatiblily with DM versions that do not support the extended VBT and
>>> OpRegion 2+. My previous comment about backward compatibilty and DM
>>> compatibility also applies here. If we don't worry about that, we can do
>>> away with any cases where we are permanently mapping the host opregion to
>>> the guest and implement this new approach of always exposing a copy of
>>> the OpRegion and VBT to the guest instead.
>>
>> How does "permanently mapping" matter? hvmloader runs inside the guest, so
>> exposure just to copy the data isn't any better in terms of this being a
>> layering violation. The more correct thing to do might be for the DM to
>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>> (How in turn the DM would learn of the contents of the opregion is a
>> separate question then.)
> 
> I am working on v3 of this patch and I want v3 to address this problem of a
> "layering violation" that you mentioned here, but I do not understand exactly
> what you mean. Do you mean to say that the current code we have in place and
> have had in place for over the past 10 years [1] in the Qemu DM that traps and
> maps the OpRegion into the guest is a "layering violation?"
> 
> [1] https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=5cec8aa38cc
> ("xen, gfx passthrough: add opregion mapping")

All I can say is that this at least smells like a layering violation. It maybe
wouldn't have if, in your patch, you didn't demonstrate that the machine page
range doesn't really need mapping, as copying the data and providing that to
the guest is sufficient. In such a case, the machine range should (imo) never
have been exposed. After all the guest then can fiddle with it, potentially
breaking later guests that are to also use the region.

>>>>> +    /*
>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>> +     * to communicate location of the VBT to the device
>>>>> +     * model. If rvda_host is not 0, The device model
>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>> +     * after we also write the guest address where the
>>>>> +     * VBT will be mapped.
>>>>> +     *
>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>> +     * it will not unmap the OpRegion.
>>>>> +     */
>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>
>>>> Why would you need to communicate a host property to the DM?
>>>
>>> The DM cannot access the host rvda value because it is only accessible
>>> from the host kernel, and the DM is only a user-space process on the host.
>>
>> I don't follow this: Anything the guest can access should also be accessible
>> by its DM.
> 
> I also don't follow your comment here so permit me to comment and ask some
> questions for clarification.
> 
> I was thinking it is enough for the domain the DM is running in to have
> access to the resource for it to be legitimate for the DM to map the resource
> into the guest. So I also think that whether or not the DM itself can access
> the resource is irrelevant to the question. But you seem to be saying, no,
> that is not enough, the DM itself should be able to access the resource
> before it can be allowed to map the resource to its guest. Is that what you
> are saying?

That depends on what you mean by "access": The prereq is that the DM have
permission to access the pages. It may not have an active mapping thereof.

> Perhaps your comment here is related to the concept of a "layering violation"
> mentioned above. Are you saying it is a layering violation for the DM to
> map an MMIO resource to its guest unless it actually has access to that
> resource? If so, what kind of access to those device resources should the
> DM have? Read access? Read/Write access?

No, I'm trying to bring across that (as said above) access to machine pages
should not be granted when that isn't necessary. As in here: A copy of the
pages looks to suffice, so simply give the guest access to a copy.

> If the specs only say the DM "should" have access to the resources it maps
> into its guest, then I would think it would not be a layering violation.
> But if the specs say the DM "must" have access before it asks the hypervisor
> to map the resource to the guest, then I would admit that yes, we have a
> layering violation because the DM is mapping the OpRegion to the guest
> even though it does not have access to the OpRegion.
> 
> So, where are the specs for what the DM can and cannot do? Are they publicly
> available, or are they proprietary or only available to members of the Linux
> Foundation and/or the Xen Project?

Sadly the source code (of Xen and/or qemu) is the spec.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 09:23:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 09:23:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392768.1631762 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtZ0-0005rX-ST; Mon, 17 Aug 2026 09:23:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392768.1631762; Mon, 17 Aug 2026 09:23:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtZ0-0005rQ-PP; Mon, 17 Aug 2026 09:23:26 +0000
Received: by outflank-mailman (input) for mailman id 1392768;
 Mon, 17 Aug 2026 09:23:26 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvtZ0-0005r1-3l
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:23:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtYz-00GSv4-GJ
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:23:25 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82d2f9-e002-0a2a0a5209dd-0a2a4506972e-38
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:23:25 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82d30d-195a-0a2a45060019-d155dd32ad16-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:23:25 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47fe377a217so2092098f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 02:23:25 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783basm2381022f8f.30.2026.08.17.02.23.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 02:23:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786958605; x=1787563405; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=9BrctE81Qr1yl9EY7Q6HBkiNpNb0gAbctXwpRnjLcBk=;
        b=lh9fN8upDDynTS3JLLDcKxyQeRyE0o+bAI+3RdMMJEQggxm01vVr2HYRG4nFYt3qd/
         NQqoqlucmjTFxAmuxkjdMN7rUe1DjHUj1jcpcK/3tUSMIIEt4F4cetiZyOgMZoYdETE3
         YTzIRvhheVZ9fY9v8i4XEyCzxhFnScVjBdXnrQjcC6AjIgPERW6FzXc+exLpxzbpIr04
         pwsIlRxKie1MsGYbwdlOMlzappX99Z7Bm/lzJBHc4AJ1/ywmXNt6+25hyRXqX+KU3kUf
         lmzU/Wqj5P5apNXyjRIRItsb00Lcxd0VsTxUWBboeFzc0di8Dskc1AG/7bZn/M+lHAaU
         bUjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786958605; x=1787563405;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=9BrctE81Qr1yl9EY7Q6HBkiNpNb0gAbctXwpRnjLcBk=;
        b=oK6BHOcLjETB0vC3pn/M49+e0rhDMMlNBZ9zX/mZa+vQ1oM4bhEnjYkKafrMv1xIYs
         J/UDT/DXiWsPXkFEP7MdGN/IbBLqd9uTaulOJW9LitF/S5GT7xMAGIuW1wOHQTcmZPMv
         VmixWeN2GAb6+3aBYQYYw4Uu7dqloI0ZgJWqrj9BgjyXqFT5FxHo0WgPJ0X5VtkwPONQ
         YOeFDX8Jlpovv0pUff9ycSC5CtsaQ+kafzC2s1X9vCLBpgzWGquOyh6fSC4jRftmi/Z/
         U+ltY1qvjB+pgz582nDEJaRlBzrSvkbKcXQXTbSIj16heb3WqtLQREvJzfv7RrVonLuJ
         RDuQ==
X-Forwarded-Encrypted: i=1; AHgh+RqRGl7eUaSxmW5YjwN1z0ttqroIPv5GFOap/FA8yKM+QKF6pF2ughX0KI1FKExOM0xYjH7G3a8vRqk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxVsIY1KU9HP1WjiDq1rAgiAnO0yIPGUItEWXOw0QyPiLbOHKIG
	K2JeH9AsfxmT6ew5xjq8aFZMHIeA3r8wbQxvI9zPTb9OiTjj+BsATT7N
X-Gm-Gg: AR+sD13sA8a6XoSuO0Afy8r3f/+aGSG0Th+5dEMeNl0OiOSFiGagQDEeNySpnW/AA2Z
	mWBuKfKSoQIRAQs+SxaFBP+peyrSk0hZOX55hxhcKE1HVBLTE7wqAb9pUkCv0+26rG0bhPnDpXY
	xvqEe4duSwxeT8vMWppf4OHsRqX3un+0mDl5zfiD7v6eTAGxW63JIlsDcV5N70ImvMVQLV9Snpp
	QY7Fc9itpbsq8f/AB5zsrWI5LarGeLtcgVUZJUsMiJZlM5dUA3hIM/BSBTp5fAsT09LFCmBExTW
	GFicEGrMWu3Ul4Y1n474cDVFRzkuYy8NBt8ceY6JGeqqIpe6ypn6Fz4PHn+IcQLaFgfIqFg4K75
	TrM63GpAWtZBvSc6CsTNo/YFx9vvDEP2ChTKv+zKikIZvPgDP+XDZg73zngnQgpcS/edj3RqS4V
	MfBdcIHZB8wBE4DBxAFWaoA+DL9xvSQwQrWDskubj9n8eU9DScWk8wbjDTsOQ3IgQfD054IcbdZ
	T88kMS4gayoyuX7BIeCcwCOkR1zwHfYCVyJRVNoPD0=
X-Received: by 2002:a05:6000:250a:b0:47f:7e8f:d62d with SMTP id ffacd0b85a97d-48160732f09mr32714993f8f.10.1786958604721;
        Mon, 17 Aug 2026 02:23:24 -0700 (PDT)
Message-ID: <9936c0d7-7daf-4fba-9bf9-40074fc31f7c@gmail.com>
Date: Mon, 17 Aug 2026 11:23:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 08/17] xen/riscv: add IMSIC state save/restore
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <5e3df9ea4bafc5666d1885dfd40f534f8349879e.1784560663.git.oleksii.kurochko@gmail.com>
 <698b5cf4-b383-452b-b6b8-fd5c09e41f51@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <698b5cf4-b383-452b-b6b8-fd5c09e41f51@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1786958605-FD40B77B-71B958DE/10/73395122804
X-purgate-type: spam
X-purgate-size: 1765



On 8/12/26 3:57 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> @@ -418,6 +419,28 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id)
>>       return res;
>>   }
>>   
>> +void imsic_state_save(struct vcpu *v)
>> +{
>> +    struct vimsic_state *imsic_state = v->arch.vimsic_state;
>> +    unsigned long flags;
>> +
>> +    /*
>> +     * SW interrupt file always has ->vsfile_pcpu = NR_CPUS so nothing specific
>> +     * should be done in this case.
>> +     */
>> +    if ( !vcpu_guest_file_id(v) )
>> +        return;
> 
> How does the ->vsfile_pcpu sentinel value matter here, when you're checking
> ->guest_file_id?

Comment is incorrect. I will fix it.

> 
> And anyway, there being dependencies like this one on the other big series
> makes it rather hard to review things.
> 
>> +    write_lock_irqsave(&imsic_state->vsfile_lock, flags);
>> +    imsic_state->vsfile_pcpu = cpuid_to_hartid(v->processor);
> 
> As discussed for another patch in this series, this will need to change then
> as well.

I will update that properly.

> 
>> +    write_unlock_irqrestore(&imsic_state->vsfile_lock, flags);
>> +}
>> +
>> +void imsic_state_restore(struct vcpu *v)
>> +{
>> +    /* Nothing to do */
>> +}
> 
> "save" and "restore" have meaning other than what you intend here, aiui. Once
> again without call sites it remains unclear when exactly these functions would
> be called. Which makes it close to impossible to suggest better names.

I will add some extra context and/or re-shuffle patches to make it more 
clearer. Anyway as you explained me in another thread a name is really 
incorrect. I will use imsic_ctxt_switch_{to,from}() instead.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 09:26:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 09:26:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392777.1631772 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtcB-0006Wd-DE; Mon, 17 Aug 2026 09:26:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392777.1631772; Mon, 17 Aug 2026 09:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvtcB-0006WW-9y; Mon, 17 Aug 2026 09:26:43 +0000
Received: by outflank-mailman (input) for mailman id 1392777;
 Mon, 17 Aug 2026 09:26:42 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvtcA-0006WK-7L
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 09:26:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvtc8-00GTFz-KN
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:26:40 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82d3ca-8faa-0a2a0a5109dd-0a2a4506e298-28
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:26:40 +0200
Received: from [40.107.201.17]
 (helo=CH4PR04CU002.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82d3ce-195a-0a2a45060019-286bc9117c69-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 11:26:40 +0200
Received: from CH2PR03CA0029.namprd03.prod.outlook.com (2603:10b6:610:59::39)
 by DS0PR12MB9038.namprd12.prod.outlook.com (2603:10b6:8:f2::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 09:26:31 +0000
Received: from CH1PEPF0000AD7F.namprd04.prod.outlook.com
 (2603:10b6:610:59:cafe::a6) by CH2PR03CA0029.outlook.office365.com
 (2603:10b6:610:59::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Mon,
 17 Aug 2026 09:26:31 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH1PEPF0000AD7F.mail.protection.outlook.com (10.167.244.88) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Mon, 17 Aug 2026 09:26:31 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 04:26:30 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 04:26:30 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 04:26:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iXAGuYWeunkmgeBK//chsjOk/y2+0kEuBP4euZh0gi9m59GcNmvDOrokhc+BGrWzJM/rH/CnmIzob7l2HRB1eq89TPNIg8WsfuL5W4UtZ0axtoBRAwyHHsyZ8MmMil1+bdP9oKZQMqclsoILrrSybMy0XypB/n2UdMM+y4MX2irjJ+3fUN6PGFIKeQn1hKrIPF8aqLsa1JB7lTAZIea2AXCBwAdKpNjmnaE5XoHJ0XdLBX1TNJqqVYGbMP7fC/saiU1oLthSyfpoLHlNkIfQU3vxocuy9UXSA3fZUghjHVq2kZMFkFjIhcW3uFIRz+cgZR5q71H6SuBjM4NoKBZhCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Uq3nSvYDaCGlbi4Gy5VEjm+C0xdTvLFJRvNtXR92NOE=;
 b=SiBiEOnKhegfMrQ9/OW53T1l73s4d6DEUOdrrchVKfR0I36ZWFnFlSt9bFDHRtDOl/5OL3wyP2jaIKkJzZ7xr5w/riV/VRuYPjfj52cmVfMdzToqJ2g8NAgRWWsuapJou5rKP8S23tYJNYkknWK9I23GxlBctwtvOdLMKFtfgK9Uz27NuNbS3Jp25JexjVrbVvQLQlQDlvN+jaxo02j7k615Qufn6Me4oU4Kvdx4p8+ReqzCO2wdWr1aMxliUP4N6Z/xH5RUEou97YJazN9I+xFc1qK2mP9CAUCjAfjdjcGuws/bKKauUrN+bonZ73nF+QTh8JcNasKAs5UY8vrgBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Uq3nSvYDaCGlbi4Gy5VEjm+C0xdTvLFJRvNtXR92NOE=;
 b=Rb3Shn81E14DdOrh5v7GFf5Z0NlpuKa1sliJBViFC5lKO9D5MTxlcB6mcWBWSulxSyUVO8j/REcfOM+1Xk229Jw7w/8jzCSRUSp8if7An0Gu8cLrGRhxLZylvXPH3AIjrEg6ajZ/NBXislM/6bJIiHCazrHt8GgGgPdILM7cuJE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <4649c965-2b4f-448e-9a71-082f687d378d@amd.com>
Date: Mon, 17 Aug 2026 11:26:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/3] xen/char: add classic i.MX UART driver
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260814162535.331459-1-onlywig@gmail.com>
 <20260814162535.331459-2-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260814162535.331459-2-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7F:EE_|DS0PR12MB9038:EE_
X-MS-Office365-Filtering-Correlation-Id: 8dda39f1-c488-495d-2a4b-08defc419f6e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700016|23010399003|6133799003|3023799007|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	OMU80sKN/hQLgGXSH+keSCSwuftAgKjFhFyuh56sbx6VMWSGopdb9Y0LdxMx9MBFErVhD+7GWslcsgZvNA8K94Q+i1ZAxDy0DsUL6EerzejZX0m9wql6ooTYLE0Wax9igEsYJj35KL6RAwbIkosut//ujqXzMiaG0cAUD7yxNwcZjz/CzCa6JGpifasA3Tr592Cs79ijuyWd2MluRk4ffRetgNnNSMbZUxnJQ3dqzedcFUY3YBPWbauxKJZlCXgiq/1Mg2kvgYwlgu1+VFJBvMaADv5wiT3NnlpfeoNoHbELbVEF8m7fJ8BSPPbGUBREeROw7rEHGrc9oV3BsE/c595b/kp0YFY1sRD0+1gYKoMp7cXTLv7beGjtd1+eUL6gjhecXsglwDLB6yYRVdsadx0KutDONZTsNk3ZYGxQ2BlwhrU1ASN8RQZvrjZdrhishovRUbU4rULBQ2gxo2ZrD6jPQETPphn+5lAZrHQoztBqmpyiEUKqGkRpxITaAIrj7vH0jPLKtmFUERueCS+d7MaO8nuXJTMmgUYD3MwKc55yMGG19DAZGvtfUo8pDHaMUGS/C6z57Xrh1AL1vIOEZ2y5EumTVMv7ExTa+EBlR/jsdS+8grb4FrqW360rFv83ZSii+vh1y6I2/0xxH+sDHRyIV37nYTkp0gdHhUCfDC7mydzzB4r7ByZLXXzeapR55j0LvBsu9I1sUF6MPx6RGw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700016)(23010399003)(6133799003)(3023799007)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	/2upCiWPNPutWXawGNUGdff48bAK0hiYPw2b08Vb4jbmnWGc4HpINkqjowiM1WP5JK3J1UYiKeqkeUcFxKIabZ7a475xSfaWfVZHAIlf0ev2NRM6O7QaJLixxPMk4XYcoTLqakGV3ssYdKqSjm5P/9Ifv3pb6I5pt8vW4uxaTiv+ZsnvbdNJ8Ak2nPJjueqd8MyZ7Qatj13GRzKzScLF0pZZOb3U0XvTjQ2ly7lmQDTvLeBzw4eYxTiIeIYL/Vry7+A8jK1oyrDyGODJTMcPC2oewmv91DNm1F5I/om7u2FfIBRbCV06AQG/1Z6aucuIdCbYsl2XrEk0iHo+wjGKowv5jRN3gnwyajiDghZwBWoY8k4H0fXNpwcqYqCGORcpT7quihiOFhtMNfCZMAncjrA/P4OQRACltyNmODk1WRF0sH2bVCtqKLRZzPV1OGLS
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 09:26:31.0522
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 8dda39f1-c488-495d-2a4b-08defc419f6e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD7F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9038
X-purgate-ID: tlsNG-16d1c6/1786958800-FC60277B-71CC3B42/0/0
X-purgate-type: clean
X-purgate-size: 7250



On 14-Aug-26 18:25, Wig Cheng wrote:
> Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
> compatible), as found on the i.MX6/7/8M families.  Baudrate and pin
You often mention i.MX 6 and 7 but guard the driver on Arm64. Please do not
mention them if you only intend to support/test i.MX 8.

> configuration are inherited from the bootloader; the driver only
> enables the transmitter/receiver and wires up the RX/TX interrupts,
> mirroring the existing imx-lpuart driver.
> 
> This is needed for the i.MX8M family, whose UART IP differs from the
> LPUART used on i.MX8QM/8QXP.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/include/asm/imx-uart.h |  62 ++++++++
>  xen/drivers/char/Kconfig            |   8 +
>  xen/drivers/char/Makefile           |   1 +
>  xen/drivers/char/imx-uart.c         | 227 ++++++++++++++++++++++++++++
Please add entry to MAINTAINERS for this file under ARM

>  4 files changed, 298 insertions(+)
>  create mode 100644 xen/arch/arm/include/asm/imx-uart.h
>  create mode 100644 xen/drivers/char/imx-uart.c
> 
> diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
> new file mode 100644
> index 0000000000..ad4b0b06ff
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/imx-uart.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
Can this be GPL-2.0 only?
> +/*
> + * xen/arch/arm/include/asm/imx-uart.h
This can go stale. Please drop.

> + *
> + * Register definitions for the classic i.MX UART IP
> + * ("fsl,imx6q-uart" compatible, used on i.MX6/7/8M families).
> + *
> + * Register layout taken from Linux drivers/tty/serial/imx.c.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#ifndef __ASM_ARM_IMX_UART_H__
Should be ASM_IMX_UART_H

> +#define __ASM_ARM_IMX_UART_H__
> +
> +#define URXD0           0x00   /* Receiver Register */
> +#define URTX0           0x40   /* Transmitter Register */
> +#define UCR1            0x80   /* Control Register 1 */
> +#define UCR2            0x84   /* Control Register 2 */
> +#define UCR3            0x88   /* Control Register 3 */
Given that this is not a verbatim 1:1 copy from Linux (no need for it to be),
please do not define macros that are unused.

> +#define UCR4            0x8c   /* Control Register 4 */
> +#define UFCR            0x90   /* FIFO Control Register */
> +#define USR1            0x94   /* Status Register 1 */
> +#define USR2            0x98   /* Status Register 2 */
> +#define UTS             0xb4   /* Test Register */
> +
> +#define URXD_CHARRDY    (1U << 15)
Please use BIT(n, U)

> +#define URXD_RX_DATA    0xff
> +
> +#define UCR1_UARTEN     (1U << 0)
> +#define UCR1_RRDYEN     (1U << 9)   /* Receiver ready interrupt enable */
> +#define UCR1_TRDYEN     (1U << 13)  /* Transmitter ready interrupt enable */
> +#define UCR1_RXDMAEN    (1U << 8)
> +#define UCR1_TXDMAEN    (1U << 3)
> +#define UCR1_ATDMAEN    (1U << 2)
> +
> +#define UCR2_SRST       (1U << 0)   /* 0 = issue software reset */
> +#define UCR2_RXEN       (1U << 1)
> +#define UCR2_TXEN       (1U << 2)
> +
> +#define USR1_RRDY       (1U << 9)   /* Receiver ready */
> +#define USR1_TRDY       (1U << 13)  /* Transmitter ready */
> +
> +#define USR2_RDR        (1U << 0)   /* Receive data ready */
> +#define USR2_ORE        (1U << 1)   /* Overrun error */
> +#define USR2_TXDC       (1U << 3)   /* Transmission complete */
> +#define USR2_TXFE       (1U << 14)  /* Transmit FIFO empty */
> +
> +#define UTS_TXFULL      (1U << 4)
> +#define UTS_RXEMPTY     (1U << 5)
> +#define UTS_TXEMPTY     (1U << 6)
> +
> +#endif /* __ASM_ARM_IMX_UART_H__ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index 8e49a52c73..f237c0220d 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -30,6 +30,14 @@ config HAS_IMX_LPUART
>  	help
>  	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
>  
> +config HAS_IMX_UART
> +	bool "i.MX UART driver"
> +	default y
> +	depends on ARM_64
> +	help
> +	  This selects the classic i.MX UART. If you have an i.MX8M family
> +	  based board, say Y.
> +
>  config HAS_MVEBU
>  	bool "Marvell MVEBU UART driver"
>  	default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 8cbbffdca8..039f566926 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
>  obj-$(CONFIG_XHCI) += xhci-dbc.o
>  obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
> +obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
>  obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
>  obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
> new file mode 100644
> index 0000000000..5ae8c13c40
> --- /dev/null
> +++ b/xen/drivers/char/imx-uart.c
> @@ -0,0 +1,227 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * xen/drivers/char/imx-uart.c
This can go stale. Please drop.

> + *
> + * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), as found on
> + * the i.MX6/7/8M families (e.g. i.MX8MP).
> + *
> + * Baudrate and pin configuration are inherited from the bootloader.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/irq.h>
> +#include <xen/mm.h>
> +#include <xen/serial.h>
> +#include <asm/device.h>
> +#include <asm/imx-uart.h>
> +#include <asm/io.h>
> +
> +#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
> +#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
> +
> +static struct imx_uart {
> +    uint32_t irq;
> +    char __iomem *regs;
> +    struct irqaction irqaction;
> +    struct vuart_info vuart;
> +} imx8m_com;
> +
> +static void imx_uart_interrupt(int irq, void *data)
> +{
> +    struct serial_port *port = data;
> +    struct imx_uart *uart = port->uart;
> +
> +    if ( imx_uart_read(uart, USR2) & USR2_RDR )
> +        serial_rx_interrupt(port);
> +
> +    if ( imx_uart_read(uart, USR1) & USR1_TRDY )
> +        serial_tx_interrupt(port);
> +}
> +
> +static void __init imx_uart_init_preirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1, ucr2;
> +
> +    /*
> +     * Reuse the bootloader baudrate/format settings: only make sure the
> +     * UART and both directions are enabled, DMA and interrupts are off.
> +     */
> +    ucr1 = imx_uart_read(uart, UCR1);
> +    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_RXDMAEN | UCR1_TXDMAEN |
> +              UCR1_ATDMAEN);
What about TXMPTYEN?

> +    ucr1 |= UCR1_UARTEN;
> +    imx_uart_write(uart, UCR1, ucr1);
Only UCR1's enables are cleared, while other UCRs interrupt enables keep
whatever the bootloader left. Either mention UCR1 only or clear others too.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 11:24:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 11:24:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392829.1631797 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvRj-0005yh-FR; Mon, 17 Aug 2026 11:24:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392829.1631797; Mon, 17 Aug 2026 11:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvRj-0005yZ-CK; Mon, 17 Aug 2026 11:24:03 +0000
Received: by outflank-mailman (input) for mailman id 1392829;
 Mon, 17 Aug 2026 11:24:02 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wvvRh-0005yO-V2
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:24:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvvRg-00GqBS-EY
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 13:24:00 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a82ef49-8faa-0a2a0a5109dd-0a2a45099c7e-22
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:24:00 +0200
Received: from [52.101.193.67]
 (helo=CH1PR05CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a82ef4e-be1a-0a2a45090019-3465c143c619-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:23:59 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PH0PR03MB6496.namprd03.prod.outlook.com (2603:10b6:510:a8::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 11:23:56 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026
 11:23:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FDc4MI1Zks4ByhqpngtvNwSBxdgseDqYIy0np8k/hz6CyGZOrKjXMM1upJ6b5bBPvkyPFREcmO8QjLqDs4cwzIyfGzsOoLb+97ytcNW1wcDOhvIg+mFq4qS+SyXZbUGxCEuD2pGSVBEVoZCMmFxUZPDLh30TqCnzqQoFEVLHg1ENXLv8OvhAYXAXh/ZTf/Q8cTH7kjhzRJ4OmifrS8Yg9bDn87PkUIFibGwVjVTpbT7n95uHKj55wRg8ChoJ3Fh/2pJ+bqrr1V87g6fFhjRWUd+WZHyiCLWlA7JWBfn8plJcnxnuufWpYy84fEafCFbJYjfH2hh697ioN4v1oREl5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7AhNRs50oxqYZpAaHuaYHb9wMA2dbv3cU0k7cmZe4Z0=;
 b=cRF0yhNNBWoMkx74PmCJpT7TxSqsM8iUqhA56s4IxcTVpwKsHp6Ex0FUScSZ76+JVLxSjsbDsOXZjQ0zW0+YNRy4+jrpOzrBL2yhdTIJojg72yXr6OZZ4wLPCz239UskKtAnJQqwtACAP2haRInCsbTevI+SbJBbegrnBz6PYqaLoKR9CthwUpUaoOVj3H4mFpaCbz6H9C2Gp4ZD+ul5ijtxmy6giwUTFmxZvZVzO07LUm1P7khfZ9Qp8A2sskKzldC7a4u1jbRqUU54OHgu9pwXycwKARFvIwo/M/6ExZF52sTlcXmiOOJq5Y4a9jtlo3B/F6LbezAkHvxErT+DyQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7AhNRs50oxqYZpAaHuaYHb9wMA2dbv3cU0k7cmZe4Z0=;
 b=fv22JlE/ARULYcy4ryrfBC+jtRA7OZ7a0u/Q+oeYAbz1/kRXo1qLqxotFJy7MlGGuQ6ajmVAbWwtFwxvu6esetVLwquYDxHbv8+ei/2YkTplfBbnn7DqT6Z3bC7XE6BoJTBYhCVJbtlhZYqb9WKv1EGDS79BQ/lmldx3ctSxmNo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <461580b0-fdc6-46d0-8f5c-626434e5ce32@citrix.com>
Date: Mon, 17 Aug 2026 12:23:52 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 1/3] x86/emul: Adjust comments in x86-types.h
To: Jan Beulich <jbeulich@suse.com>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
 <20260814185841.1757421-2-andrew.cooper3@citrix.com>
 <cf1eb6ef-763c-44d3-ab86-d9dd431cf606@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <cf1eb6ef-763c-44d3-ab86-d9dd431cf606@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO6P123CA0036.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:2fe::10) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB6496:EE_
X-MS-Office365-Filtering-Correlation-Id: d0c88add-89c4-4222-6173-08defc52067f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|4143699003|10067099003|56012099006|11063799006|3023799007|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	V+GjeclD1GJpjVZMhjtzM6ZsW+YXDFrXUaUUcCOgu83RMI7y6OeLNnwl0LJzldtT98e6Gm3d/7X0OAS8vLzgxqtZThH7n02AclSpmROfOWIPj7ct8HwdpdvT98+jqkkqh1n/0q0h1ZEavZD6YXYB5RMuuyjXcwEgk7f85TFYZJ2Ds6nWqkgQ+NDKoHzUox9tGx8WHGoQEiA9GQv74LZNZNsV5zrXZdlWewh3mytAe3JpXb52dgeMnNnbHkmUtxmIl384Fj4lTa5Whzm26KaNscYp/Lvx9ZLLUKSHvstwFuDDWgy87TAXj0OgvWjLS2YGlzKsJCQ2dTbIqpBY3+AsRZ6NArW1TcWM7mxwgc+fx7y52/+DlmwoRM+Ojkip5DeljidqQwgrixx3xTngSX+Tp0LlsnYeSdBJUlP8uO9n5gdHuPxs9Ucuu8F2qmA+kKCEgUCtVQPTBYkQYNGx6CIcCk0s3pTT/vok02qL8OlJTDokQl3QpaUbCjtGtIsIn/czIpdLidPx4vkAFP99nS+L9kgc/V/wdgdaw1rV6rvovT/FxiqGSPNZ7xfPR52qrvqoTyEdDShHMYpxn+l5QYJy5UaI3yxqDMvuPSg3oabJd/T6SyrAd+6l7Qa9MZHEZtzCPb+V0FaT4p4vfjzfx3FUf7ovlgNSAIDHAtpb9OW6UyQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(4143699003)(10067099003)(56012099006)(11063799006)(3023799007)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a1ZmNnlqenhhMjBtMWthekJTUjZ5WDY1d0UzbEpoNzVQN294RmVmamJJVkFG?=
 =?utf-8?B?MEF0V25XTXkyRkdUSmtoU1c1cTBGY3V2M1JMczJ3Y3JWcUdpZHF4am1JQmlF?=
 =?utf-8?B?WTF6Qmd0Tys0Y1BoQWUzTnlsY2FXclBaa1ZWajdZWVJOZE9NaXl6SGlSNCtZ?=
 =?utf-8?B?RXpPTlZFQ2twL1FyK1VTMVRSSWtrdXNhQUVIUTc0dWhaRDB6QWlGS2g4QVdN?=
 =?utf-8?B?Wk1qQi82ajBIM2E4ZTdtamk4VnF2amFEMkk0QkgyTld5YkhFcmNRZ0VtNzRU?=
 =?utf-8?B?VXE4U3lxVUNUZ0l5eDR0RkZ5eUpMQXFWVm9EY0xoQVZrcXBwN2c4UXdhdHY0?=
 =?utf-8?B?TWlPY0ZzalgvOFZ1MklqQjIvdXBZajNlMXc2RVowZ3JzRjhWQ055eXdvVUdM?=
 =?utf-8?B?dHRWL3NWRU9ieEJlM3FtcWw4cENnemhsaGFVeGFHUzY1UkRmY3JCSkw1b2tW?=
 =?utf-8?B?ZWh3bkE5a0VHbTRPVUM4QVZiVnU5eTJoeDVwcEI0eWZLejl1dUd2SFRSVTBa?=
 =?utf-8?B?YjVPbit2Wnl5OTIzUmNNRjY2NVhWaE9HTS9vSitqSzhqN0lPWXV2Y0tZUEtE?=
 =?utf-8?B?Q2lhM3VIU0JKM1lPUE5XZkZheWN1TE1xUDliUEFhb3h2QUNwSVdrUFZzakZS?=
 =?utf-8?B?VHk2eGVsZzhMSnIwaFMxMVJFeG1lUHlwam1zckJaNGltVlN4cjlUeHByemNP?=
 =?utf-8?B?dVFnUG9NY2hLRllmVmRJR3N0b3NYU0RlcWJHSldZcnkySE80dHEvOUw1bE1E?=
 =?utf-8?B?NlcrQ3E1bTh0K0JYeVFlNTZDdDJ3ejJ0OXVtZnQrNDQwalZqRmNCVXVvUWtZ?=
 =?utf-8?B?cXBpSFZva1ExVzdtYk9ubHR3TmpJTjJ2TE5BVG94MFQxTTBYM3ZqVlhzUkRx?=
 =?utf-8?B?MTA1NFBvMjArb01MUzc2MnpweDdEN1VySWlhTTQ4K0o1WHJCWVBaV3V0RVlD?=
 =?utf-8?B?UXdjWU8wVGpBSjZCY0tKck12TXFaWmI4VENXWnBZWUFhSTFtektsdlFUWllk?=
 =?utf-8?B?S3V6MzhBZ3BlN3hNM3ljNDlTeGF2ejFUVHVWWWpNTmFFaFIyQ3dMbldlNGNF?=
 =?utf-8?B?UDZGWU5iSU9mQUUxTUpNVU9QemVFMloreXErOGpmVUJRZnhWY2FwcURvcW8x?=
 =?utf-8?B?UGZaa29lYU1GZkhZRk1aTmVOb0xhd3N6bkhpNFVtOEM5dzdVdUd5YVQvbmsr?=
 =?utf-8?B?TE9CSkRFZjhHODl3NnlxbkRQWC9zbk4rSGhXTXR1QnpUS0dFWmU5cnJ5SnRO?=
 =?utf-8?B?V01odWxEQ0R2TU05T1hvRFgycFJtNmxsdkM1UHR5bEFhWUMrOEN6S3Qxdk9O?=
 =?utf-8?B?TFpJejI4RjlzSUwyMHpiQVJWVjFxMjhaNzY4RS9GQ0NwUGRQQkQ5cVgrc2FT?=
 =?utf-8?B?ZnFPOENKK0VEcHRZWEZjU0pySnpnNEQveDA4dUIvMzZSZTIrY2Rlc1lRK3FO?=
 =?utf-8?B?QW10NEllVXFlbTFvakZmL1JVMUFielhPTHl3ZjI1bzVTTFFpZCtvNC82cmlX?=
 =?utf-8?B?MTVPcDdkTjJBRXZSdmptbVcraW1vbUwxQVdwZTZWNDFyVTY1UVdJRk9TSUYz?=
 =?utf-8?B?c2pWUFhNM1lqU1VkNEdDYmpnS0hKdkpPcDRTVm1yYzNnOXhBRUNHRWF4Unds?=
 =?utf-8?B?dzduZHRuVzd5bDZQMTZiQlNSYlRQS1VObHFRRXlaS0Vuc0RxaG81VGREVGlC?=
 =?utf-8?B?NWZZTnh6ZmhnMXJzb25yeG94aExKMU9DQm9aOEVTcFZtcVBxdmNLbkhvcmlv?=
 =?utf-8?B?blVQWk91eHcyVCt3NGxpQ0hWN0FJS1l5WmNzWkxlaHpQc1M0S3VTK2dRRVNF?=
 =?utf-8?B?TExXRytUQk9zcVJ6S3FZdjBnbGh4UWUrOHlmMk9vQ2MxMjY2RjFodnpqUW9V?=
 =?utf-8?B?SUsxRzdtT2FUTW93djJSWHVXNnNmZ3F2aEZvSEZsVTQwMDhBOVVianFZWmx5?=
 =?utf-8?B?QmhQS3NMTHlscUJZYzlTcFh3UUlHWUJhdVN4dkJJMzkvUlFYaFRKaHVVbjRk?=
 =?utf-8?B?TllDODYyQ1prMGovYmlxM1FodW1LMksvTFRGVCtIZFpMVGhzdVpoRC9IbDVD?=
 =?utf-8?B?Sm1GOVAwUk9EN2ZvaG85aVlVZ1FNbTl1NVhKTzdNK21wSjcwTktWZDFJSENk?=
 =?utf-8?B?eExDNGxMTUNzdmp0VkM5VGhPRkQ5dzRMY2ZaOFFPV3dqVWhLTUVJMWY4REt5?=
 =?utf-8?B?V2s5THUxTklWd2cvTTErNjJvbStQZ2VrM3I4WWFVd2pCWDlYdGxMNGJVbDRL?=
 =?utf-8?B?VU9MNmlNcjEvQVZ5UElsTHdNZ1d4K1pOTUtLb0FMMzNqcmhOeGsrdkFLbnZL?=
 =?utf-8?B?dXplQW55U2wvM2RTYWJGbEY3SURBYTdRa0piK1BONVJMQlVyV0pXQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d0c88add-89c4-4222-6173-08defc52067f
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 11:23:56.1933
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nzX7kxjn7qMUA1+ZfIjhsY362l717EL4iI+6h0pt25oow1oQnaRyxGOl/Ue7WFcJl53Exwf/gZuabx/J2HDv/MeJnTWQFbKrC/tk3VNI0a8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6496
X-purgate-ID: tlsNG-bad1c0/1786965840-BD0CD034-BD23CC76/0/0
X-purgate-type: clean
X-purgate-size: 1670

On 17/08/2026 7:11 am, Jan Beulich wrote:
> On 14.08.2026 20:58, Andrew Cooper wrote:
>> x86_segment enumerates segments, not segment registers.  Adjust the comment to
>> make this clearer.
>>
>> Fix a stray tab with the closing #endif.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

>
> I wonder though if we wouldn't better ...
>
>> --- a/xen/arch/x86/include/asm/x86-types.h
>> +++ b/xen/arch/x86/include/asm/x86-types.h
>> @@ -16,9 +16,10 @@
>>  #endif
>>  
>>  /*
>> - * Comprehensive enumeration of x86 segment registers.  Various bits of code
>> - * rely on this order (general purpose before system, tr at the beginning of
>> - * system).
>> + * x86 Segments.
> ... insert "(kind of)" here: "sys" and "none" aren't really "segments",

System segments absolutely are segments.  The VMCB/VMCS layouts hint at
it, and various bits of microcode reverse engineering show explicitly
that they're considered segments (or at least, address spaces) at the
microarchitecture level.

"none" is fine without further explanation.   "linear" is the weird one
but there's a comment explaining it.

> and iirc we said we may need to gain one more such pseudo-segment here to deal
> with WR{,U}SS.

Most likely yes, but again that's going to come with a comment.

We're probably going to need a phys segment at some point too, depending
on how exactly we want to fit VMLOAD/VMSAVE into the emulator.  This too
is a segment as far as microcode is concerned.

I don't think qualifying "(kind of)" is an improvement here.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 11:24:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 11:24:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392835.1631806 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvSH-0006OP-SD; Mon, 17 Aug 2026 11:24:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392835.1631806; Mon, 17 Aug 2026 11:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvSH-0006Nf-Ot; Mon, 17 Aug 2026 11:24:37 +0000
Received: by outflank-mailman (input) for mailman id 1392835;
 Mon, 17 Aug 2026 11:24:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wvvSH-0006NA-1L
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:24:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvvSG-002h43-ES
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 13:24:36 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a82ef6a-bab6-0a2a0a5309dd-0a2a450bac24-12
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:24:36 +0200
Received: from [52.101.57.54]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a82ef73-b7e8-0a2a450b0019-34653936cb61-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:24:36 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PH0PR03MB6496.namprd03.prod.outlook.com (2603:10b6:510:a8::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 11:24:33 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026
 11:24:33 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NMhXTt8R/eCEQr9eZVne47mX7jpiozH8Ph0d5iiJOv0x6uKMUEndQS6C6GRGoILmrIm6SM1vdZbXMbdT9TMhnNHDLzZ//dhYbj7m6J5Pyjw0+znvBYqXwVm3KxY8+7AbdludjRQpFhS1EthvNGUAMme0okt4Ram731lwvopM488qdGEPxfvJM1jC0m+GdL2pHk+PvY7MfvFXnGmx3vFOApWpLP/QigUJxUt/UYwcJ94Gx9hY2fZZYAPUiDVI2fYDmU7FpzScGyp+abJZZrmPhqhgL2TyqL5lPJw5PSTlWHLA2bdLS1TRJ5snUzjOcfTrnmnRDXH+/ZSZwv5w7B9yiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J/4wWT0j6wo1VIZ76/D6EgFLGuEOmmP3To6IzYW/E14=;
 b=XKmUyZy+3Sw7tMP/3lDr2uRPC6bGG48qNn1O35DlaeG1MEBXcc5UW6cVsUpTuiDWo7Hr4yKRmqTPtmcwfgvN5MQ8bLWJqEYECiQBX6I4Fs3h8qxTx5+YnIP3HDwHBvkvHRs+6yUkPDKDo9xY5C0yG1hZkBW4qbyIgeEEWrrIpFVKRO9Rclpob0qL1cl1nVBaMPOWi6Ogsa1nZz3LquFAeU8WRPyHIMnBrzz5jMRZ9n+B9PotXUjNtxpxfSbyj7J4XEVCbgr5dkmRM09Qp3PnsLL6/R4aPFXkA1Di9W/EZu/AoLwCrnT3XQ9WmftnO+lAHXQgHpObkFnUVGYLgw4eoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=J/4wWT0j6wo1VIZ76/D6EgFLGuEOmmP3To6IzYW/E14=;
 b=0aPDO/LkGmjnBJcGkFWMj9NwDVVTZTWS9be5YWOEOREds12h9LaLeNtvbRlxts2/juIJYOdkSqQT5UR3snADeuA0xqJb32RZyBOIn/WeUXKGHlVD/UiYsPBRDkLaM3KnmtFFwgRAZjR8/5SeBgYm3oc7FEek/E2xkzCDpQ+LfpY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <76224e3f-791c-40ea-a5c1-ba3bd7fa6572@citrix.com>
Date: Mon, 17 Aug 2026 12:24:30 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/3] x86/emul: Drop trailing r from x86_seg_[lgi]dt names
To: Jan Beulich <jbeulich@suse.com>
References: <20260814185841.1757421-1-andrew.cooper3@citrix.com>
 <20260814185841.1757421-3-andrew.cooper3@citrix.com>
 <2f65ee41-7a7d-4d86-9cdd-82ac4ccedb08@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2f65ee41-7a7d-4d86-9cdd-82ac4ccedb08@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO6P123CA0035.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:2fe::8) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB6496:EE_
X-MS-Office365-Filtering-Correlation-Id: b539194f-79c8-4b6b-f4c4-08defc521cfc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|4143699003|10067099003|56012099006|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	/YfBA4/M0zR8IwR94TLc8mO7NHZrVu08b7oGpfy3O/dLtgCa2SrfY+t8wlVup5GewkLaROdARVyOYYkSaaXQ55PfRZtTMy7Z9cTwBP6vwf0QLm158YOvrW+/cgww2kqfHvp6t/Xjt2RsQHxly5uA4UErrSot2SY+gvb5dFLtBvAv6j/Y/4HSBQoAyUZQgAeW1JbsJ8QOHMCZLXUSXaeVqCZ40hUXZQZ4RmK4C/YI4mpmWOVyLK3B4oBAeSLL1KzgpdrEKgCcp0lfa2CQ1ylWStqPAUS0RpB6R40jHbX91AtbmpaFCQgoOYlI9wJgBiedU9XOjRpS8YQC2qngqAL6JpIF9C5UROobA/37OYaPbf6mvqUodJXthMCv4yzOdcUSTaUHW0nEiUNJH5A5YCg8KpJuiwyztSj3iVgQhYYf/iN7WvaBCffxdiNBgmU0U6gCZpTY8m592Y2zJWdmJixhuXGyXtxPMIhQ9AKG/XXMVhKt4HNnpkg69MlhbtLmP2kjFQJppOpMzutVk1crBcABa50WD8n1P/DRY9jvDOt/NZIGZ6a4gyUD1TLlFZfRjgADjmq2+RIgnMXRsZIR8cAq1+YULsFl/8J3RlOQA32iJqcUneaa9ypoWQc8jVNzBfJOjeZaXmE/cJKQ+dpf0KXUYFFoK3hpTvWm+u6ordIsFlY=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(4143699003)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?djVKUUVSTFVpNEUyenN1TEdkNDVCeWpTME9FbTN0em0xUXMwWldXMnpaN2pR?=
 =?utf-8?B?bzJTM2U3c0pFR1VXMEJwZVVZQWN4K2JUVFJNTXNDZnp3OElHRWdlaUEwSVpv?=
 =?utf-8?B?Z01MamxGMzNwNjA3aWtKdDkrdllDYnRRVmIzb05NSitReDFDV2xIMlBZT3p3?=
 =?utf-8?B?emo1ZEdCRGRNVGRrV3RmRkFPT2pnWFF6a0tjTlBKVk9PYVZQS1RVZEdrK1hZ?=
 =?utf-8?B?WWRFTFlSWUU3ZExMU2U5SXF5Q3NWdFFSUWJEbTJSaUM0bXpEZ01yWk02WCt6?=
 =?utf-8?B?dVdhcERFZ1ZEV0VWZjJaTFdTc29sdDZQRjhCNVgxMVBVeUsrUkt4T2k4elBj?=
 =?utf-8?B?ZDI5MkVCWXZ2Ykl3NytZcFFzZGE0aFpOV05UNkRySFBCZVJpTXlXM2oyR1RF?=
 =?utf-8?B?RTcrUVU4eHNkazZvYVBnaGFHb0tqbGI2dSs5S0FzbkwyM1hYMWtVbjJNdkE0?=
 =?utf-8?B?bXNncEVCRmU5S0x1R0xkWklMVkswMUFqUENVaVZKSXBublNvWXlZeE5BOUJ0?=
 =?utf-8?B?azRGY1UxL2NXNUJGL1VOVThnQ1FNOFRZSTBYampHVjYzYk9aSExsb3lXY2Qx?=
 =?utf-8?B?T2xsOHk1NGRDSnZZTGVXYm9GaXNMQU1ZcG85VHdLeTZvbmh4b0NLakZ5S0VI?=
 =?utf-8?B?OHRPR2l3Rlc0WUovUUFic2ZpZzgyZFpJbWZjWkV6TFIvSHlLV3dhR3l1M2t0?=
 =?utf-8?B?aGhMRjg5M3phSURRblFuWUtOMWRqeS9jUzgxdXIwdTkxSnAveGZlTWt0QXFT?=
 =?utf-8?B?UWFxK2RCT1lOS2NLUXpWb2hvZzlxcEJkZERtaytCMzFzK3NKUytFU2RLM004?=
 =?utf-8?B?c0VJeU1uLzFwc0MzM00vbjdJb0loZXNZU0ROTlFaVm1TZ2ZUYzY3SklCZWVh?=
 =?utf-8?B?N0ptME5oaTZOWER6b01PaGNQS1JFNDRieklZM0ZRK3IwZEw3NUM2VDdxTUNu?=
 =?utf-8?B?OXk1Y0w5aE5JYTlCeEdZdE5Tb1pMeUJ3d2grTHBvRkthSkxxbmJDTnNGTk1k?=
 =?utf-8?B?UUsvTmpOemc2cjR4UGdwR0taNGw0NzJVYnVDbnhTQlVKVTBkRlNtYUxBSHR3?=
 =?utf-8?B?N2dFbk5pMUhuN2c0S2JpcTJnWGltdUJXL2w3YzU1RzZNSW5wQ1NLSnBzRzNJ?=
 =?utf-8?B?aElXZFIwNnlpNGpBZFRNOFRhbkc3RHZQU2oyUDBSd2gyR2hSSkRyQ1hrUDFx?=
 =?utf-8?B?Vndla1V0bmE4WnlReW1aSWJuSUZsMXR3aUFhM1QwU25lYzE1Y2pCYVRMMFBT?=
 =?utf-8?B?K2R3aHp4ZERaSCt3OFp4bUh6aHZxcFdRYWphazZlSXNQUGNEODhGTDJraVVl?=
 =?utf-8?B?c0RtWnVSSlB3SlJEY2hXVFlBOGRJSmd1b3dHQ05WTHU2RTdUdG95R1R3Tmx1?=
 =?utf-8?B?L3dzTG5Bc0tUdVNEMGxQNGxuMG5LTnFMdUFUMDdYWTVCWGcrNmx6QXBxdURY?=
 =?utf-8?B?QXhRWE91SHBpRXNOUHVMZHR2U2lzYmUrWFNPTzBwekkxQXY0NWNmR1JWSDdJ?=
 =?utf-8?B?dUJRUkM5M2NNUU5JV2FPZWtLNnhVb0ZXM0kzTHVMamJXWkxWTHJaMFd1cmxU?=
 =?utf-8?B?TUd0NS83YlpGaVBmSGR1blUzM2J6d1hzZEcvY3hhUElHaVBVRTU2eWtkYnc0?=
 =?utf-8?B?dUZ3SFBHRmtXSTNkRkN3YlhHOFdYV3ZOVFU4VEtjWXMvclZMaHNLdVk5eFJX?=
 =?utf-8?B?akNKLzVKSzJYRFdYMEwyaitmUDE0a3cyN2dtNmJ0U3NyaXNPZnVjRXBKR1Mv?=
 =?utf-8?B?TjFHSmNpeTVjOUkrM0RPNTR4VzBlQ2Y4NDNwVjU5b1ZKNmhybzVEYzN4eVQ4?=
 =?utf-8?B?ZHNxRXdPdVhHaGQzTTBPT3ZyZ05LYThwU2pLUDgrQTIyTmNwY2pRbkh2NVdz?=
 =?utf-8?B?dmFXVytwcytQMjcyc1BGWHRaWms0VG9sUmF0OEdJSTZZcmFjR1d1ZHB6Y2N2?=
 =?utf-8?B?QWV2R1RtYWZKc0VwZ1pRYURyWlZsOU9IM0h1UWc4NUZic0xMeXQ5d2ZJRDh6?=
 =?utf-8?B?QWRxZVppM0xva2FkRjh2enREREJzY0VoQlFsV0hSMnRDNE9BL3JSenpNWGZ4?=
 =?utf-8?B?RjhMc240TWFhcDlLcDJEN3NIYWNoaEZlTHEwVmlyeUVyYmNjSkQrQzlxN09l?=
 =?utf-8?B?QW8rWlZZT0JiakRVb2lPTXVHTVZFaVZKdUJQOWVlYXdOSWtBaWRDNUFINWMy?=
 =?utf-8?B?ZW5CNnZ0Sm5pakszdGdxTWZ6MnIzUkZGdGhiZkZPMVg3OGEvZWExWjYwZDho?=
 =?utf-8?B?RCtnQitRMHN1MVZ4d3JKODUzWHR3V1RaaFUvM2UrakFRKzhuRm9kYmlPMkZQ?=
 =?utf-8?B?bDc5eE0rOS9SVXN2ZlUrT1lkMnZNa21GNDgxcDdwREl6YnNBNklnUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b539194f-79c8-4b6b-f4c4-08defc521cfc
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 11:24:33.7768
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Rukl+wDHSwhCnoWNHqVaxoQCyU14TF0MrTWD5VE1Jk68eJ53YZ7mWDl9piuEHlZfySqAO9+qSD12pdCZHQxjucWvqpt01212V1ZOCcPsOGc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6496
X-purgate-ID: tlsNG-42698a/1786965876-A98C19EA-A28C32AD/0/0
X-purgate-type: clean
X-purgate-size: 365

On 17/08/2026 7:15 am, Jan Beulich wrote:
> On 14.08.2026 20:58, Andrew Cooper wrote:
>> These refer to the segment, not to the segment registers.  TR is the
>> odd-one-out having "register" in it's name.
> The more consistent naming would then appear to be x86_seg_tss?

I was debating doing this, and you're now the second person to suggest it.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 11:33:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 11:33:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392850.1631815 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvaS-0008HV-JU; Mon, 17 Aug 2026 11:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392850.1631815; Mon, 17 Aug 2026 11:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvaS-0008HO-Gq; Mon, 17 Aug 2026 11:33:04 +0000
Received: by outflank-mailman (input) for mailman id 1392850;
 Mon, 17 Aug 2026 11:33:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvvaR-0008HI-Nk
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:33:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvvaR-008LEW-4C
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 13:33:03 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82f162-2eae-0a2a0a5409dd-0a2a45099a84-8
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:33:03 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82f16e-be1a-0a2a45090019-d155dd33ada1-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:33:03 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47fe377a217so2194792f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 04:33:03 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7cd38sm3623402f8f.32.2026.08.17.04.33.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 04:33:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786966382; x=1787571182; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=a5E/dpWHVWMicXfmC4k6Vyuy2D8lsuqK70W0AlsfajI=;
        b=fZIQrEDykI87JG9uDNlkMA5AVLUh2pnF+tAmwqr8+tVB38AQM1Vf4GrX830mJFrbnk
         gPRdNzoYua1Avc/DtudRN1fFnsGGzMr3PgEjsi3eLZ4QQw9Fx2CvWs116qRpGZ+faYvk
         E8cPLXc2dC+TkCnkOuScFrHhr9vt1KLHp4ZVMr1lRA9/9iITSloN6DWG70zIqiFPUL62
         NXppzIFW7C5tLuldmInVajbscBjb5Ukgzo7YszKezxM66WcaZXPqvb2mIe346tZNhL2H
         g9OcTKZl0VsyeOczsMT4JfcVjwubii5nDstugxGDT8BpJbRRzFvqNCujNra/FSgnElIt
         6f+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786966382; x=1787571182;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=a5E/dpWHVWMicXfmC4k6Vyuy2D8lsuqK70W0AlsfajI=;
        b=ewTnFHm4itWL6qXz/bKuVkIzkIQCQRaQ02pGulzAcL3GtLagqWtCzIQcUlkQVYqDrx
         X8QEHj8Th19PHCG62Di+8SUBPXVAl9KCCvbasOOa0PYtKUgfn8kFWlbHHVOzKY6r2/SJ
         4+yn3nuAGIl68HqOTp/FDK/yMSwIaUbL4OOgb0/gJg3TAqZPlhas4U2QLFzlxZfLkbrp
         lUM3xUAqmRSs5i64cGJA80RjCcDPk4SGXHc5DDm7UG2MtJaXFVMifpZXREw/GWLPzdSf
         VHb0lDWUUPG81HdaAyJ5Ga6rBJEncB0+X30rtfb5HEhPCj328VeH0GfYiSlBbFPN/tpk
         bgnQ==
X-Forwarded-Encrypted: i=1; AHgh+RqELttJqVvko863SXccC3y/kg107HxGyCs6FkeIQLfL0pSd1uZ7SwhIblWPcokdc5LL6wJYbvZu0kw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzlGlsBUiqpbwHnalUjTNkEDGN2utuJLg5QIHCALA9RkDs5ooZK
	7qGms5/YzT48MaKeTCFK1ab0SmIG1q/+lK9kAWEN0CdVExiCtyWFJES+p10j1w==
X-Gm-Gg: AR+sD13DZQUgAjUu2b1jwFJmgiQ4JHGAlUr5XL4lB6a+opjaLrC4Eu5CBIKJVvOnvGl
	9nDO/iop5397gIzEXwb75z9ZYCsPGcWqz3gXcolrmQMymUCc9tqOtT4v/BsvwxhRADb3Eby9nDP
	4AipzKahSaZyOClxceQ+huSPciDUw44fGA2XJsVkUfYAf+LykpUEgRQf4R8H/PJPP4gJrp9ehuc
	4PAsEEfe4VVHWxw3+gOD2lO6lYOpDJOVym/i3Zt3UaZTdE6P/5+XpwwryfZC9P4T6b379perRsx
	s3NJgIQRTHAxsPBe5wC+TbcjnF+6Wr5Kq7/VJFVwZgwrqIOvYPlkN+u6V7+f1drzvB2j5muXRiO
	EcVhcusIZDbBQpCpPc7qr76OIpecwsQvaPiUW4Yz3hY+yRneoMz49GLyKy95umnjdrdD/IWVBjx
	sq+v+99ZgE1OSO7v8XPEG7+vkUbk6NWRpYllA8uLhyssq5F883+cK8vpitNuY0fuEivWBAFZ0mD
	jo/KbhX97OJ/0JlCjrf9UR9noMijHTN0tCrDiNQAWsVsGKzv7q5Isg=
X-Received: by 2002:a05:6000:288d:b0:481:5bce:44b3 with SMTP id ffacd0b85a97d-481607708femr34679018f8f.16.1786966382286;
        Mon, 17 Aug 2026 04:33:02 -0700 (PDT)
Message-ID: <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
Date: Mon, 17 Aug 2026 13:33:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1786966383-FCC15034-400428E6/10/73395122804
X-purgate-type: spam
X-purgate-size: 6305



On 8/12/26 4:37 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>>       regs->sepc = ex_fixup(ex);
>>   }
>>   
>> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
>> +                                         unsigned int offset)
>> +{
>> +    /*
>> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
>> +     * laid out at the start of struct cpu_user_regs in architectural
>> +     * order.
>> +     */
>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
>> +                 sizeof(unsigned long));
>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
>> +                 31 * sizeof(unsigned long));
>> +
>> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
>> +        return 0;
> 
> And an offset not divisible by sizeof(unsigned long) is okay?

No, it isn't okay. I will apply your comment ...

> 
> Returning 0 as error indicator also feels fragile.

With what I suggested below returning could be just dropped.

> 
>> +    return *(unsigned long *)((unsigned long)regs + offset);
>> +}
>> +
>> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
>> +                                 struct cpu_user_regs *regs)
>> +{
>> +    struct trap_info *trap_info =
>> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));
> 
> Related to the earlier comment: Simply pass just ex->data here, leaving the
> multiplication to regs_get_gpr()?

... It would be better to move the multiplication inside regs_get_gpr().

Your comment made me think about whether the multiplication is needed at 
all (regardless of where it is done). In other words, ex->data contains 
the register number, so we could just write:

static unsigned long regs_get_gpr(const struct cpu_user_regs *regs,
                                   unsigned int num)
{
     /*
      * The GPR number -> offset arithmetic below relies on x0..x31 being
      * laid out at the start of struct cpu_user_regs in architectural 
order.
      */
     BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) != sizeof(unsigned 
long));
     BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) != 31 * 
sizeof(unsigned long));

     ASSERT(num && (num < 32));

     return ((const unsigned long *)regs)[num];
}

Probably, we want to consider this function out of context (for now 
context is that we use it to recieve a pointer to trap_info which can't 
be obviously stored in x0 as it should be always hardwired zero). In 
that case, there is no need to check that num is 0.

So, it probably makes sense to just have:
   ASSERT(num < 32);

ASSERT() is fine here as I don't think that compiler will use incorrect 
number during register allocation.
> 
>> +    BUG_ON(!trap_info);
>> +
>> +    trap_info->sepc = csr_read(CSR_SEPC);
>> +    trap_info->scause = csr_read(CSR_SCAUSE);
>> +    trap_info->stval = csr_read(CSR_STVAL);
> 
> Do you really need to re-read all three registers here? Didn't you read at least
> scause already, in order to make it here in the first place?

Agree, ->scause and ->sepc are already read.


> 
>> --- 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
>>   
>> +#include <asm/gpr-num.h>
>> +
>> +#define EX_TYPE_FIXUP 0
>> +#define EX_TYPE_TRAP_INFO 1
>> +
>>   #ifdef __ASSEMBLER__
>>   
>> -#define ASM_EXTABLE(insn, fixup) \
>> -    .pushsection .ex_table, "a"; \
>> -    .balign     4;               \
>> -    .word       (insn) - .;      \
>> -    .word       (fixup) - .;     \
>> -    .popsection
>> +#define ASM_EXTABLE_RAW(insn, fixup, type, data)    \
>> +    .pushsection .ex_table, "a";                    \
>> +    .balign     4;                                  \
>> +    .long       ((insn) - .);                       \
>> +    .long       ((fixup) - .);                      \
> 
> Why the change from .word to .long? And why the extra pairs of parens?

I don't see any sense now in changing type and of extra pairs of parens.
This part of changes will be reverted.

> 
>> +    .short      (type);                             \
>> +    .short      (data);                             \
> 
> Alongside .word, these then likely want to be .half.

.half will be better if .word is used.

> 
>> @@ -23,20 +30,36 @@
>>   
>>   struct cpu_user_regs;
>>   
>> -#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"                                \
>> +    ".long      ((" insn ") - .)\n"                 \
>> +    ".long      ((" fixup ") - .)\n"                \
> 
> Same questions here then.

I will revert these changes too.

> 
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/gpr-num.h
>> @@ -0,0 +1,33 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef RISCV_GPR_NUM_H
>> +#define RISCV_GPR_NUM_H
>> +
>> +/* GPR ABI names, in register-number order (x0 .. x31). */
>> +#define GPR_ABI_NAMES                   \
>> +    zero, ra, sp, gp, tp, t0, t1, t2,   \
>> +    s0, s1, a0, a1, a2, a3, a4, a5,     \
>> +    a6, a7, s2, s3, s4, s5, s6, s7,     \
>> +    s8, s9, s10, s11, t3, t4, t5, t6
>> +
>> +#ifdef __ASSEMBLER__
>> +
>> +    .equ    .L_gpr_num, 0
>> +    .irp    name, GPR_ABI_NAMES
>> +    .equ    .L_gpr_num_\name, .L_gpr_num
>> +    .equ    .L_gpr_num, .L_gpr_num + 1
>> +    .endr
> 
> So this is emitted no matter whether a .S file actually uses any of the constants.
> Perhaps okayish, but somewhat wasteful.

I can move #include <asm/gpr-num.h> inside "#else /* __ASSEMBLER__ */" 
in asm/extable.h and it will be enough for now. Or just drop declaration 
of .L_gpr_num for assembler code until it will be needed by it.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 11:37:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 11:37:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392859.1631825 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvf7-0000Xj-8H; Mon, 17 Aug 2026 11:37:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392859.1631825; Mon, 17 Aug 2026 11:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvf7-0000Xc-4T; Mon, 17 Aug 2026 11:37:53 +0000
Received: by outflank-mailman (input) for mailman id 1392859;
 Mon, 17 Aug 2026 11:37:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvvf5-0000XG-Ii
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:37:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvvf4-003Nqo-FK
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 13:37:50 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82f279-2eae-0a2a0a5409dd-0a2a450be034-42
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:37:50 +0200
Received: from [40.93.195.16]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82f28c-b7e8-0a2a450b0019-285dc3108a18-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:37:49 +0200
Received: from BN0PR04CA0038.namprd04.prod.outlook.com (2603:10b6:408:e8::13)
 by PH0PR12MB5629.namprd12.prod.outlook.com (2603:10b6:510:141::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 11:37:44 +0000
Received: from BN3PEPF0000B06E.namprd21.prod.outlook.com
 (2603:10b6:408:e8:cafe::60) by BN0PR04CA0038.outlook.office365.com
 (2603:10b6:408:e8::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Mon,
 17 Aug 2026 11:37:44 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN3PEPF0000B06E.mail.protection.outlook.com (10.167.243.73) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.0 via Frontend Transport; Mon, 17 Aug 2026 11:37:44 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 06:37:44 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 06:37:42 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bLLYVsEwC3V6kXSlq27VhRVlZHEVF929Arw95MY1Wayt4qHpsGXVDcoRzbfCFaHAktFg1WGWnsaLF+qcq2GW1QOL1TCdAshTTDAKZG1TfvDIg2b0Ymdurtkg6/Fpq6ZEal9RQe0dUpj/nUKWrjBzxw9HKhKScgmvNlF5M/eBddIGGtcHfEIe2LmW51WJONuBRtgEIVVBNHbWB2/xeBnClismP96ZQ8v13/uCE5y8iOaq0TFZqryrbZAIfGOnY9RysTY/vTMiuOdYzI7WzaZsv2uFf/NFJWqc7bSKru0Ud9GcQZYBQfdmz1AVW+dXYb/lobmVeEB9Z4IR/ihD5M0NeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+Biei+yh1U5imaqv4qa4tb64kIMDwlCDUJi9sft3RFc=;
 b=L7edlkLrSXnCn7PcaCwlKruW6tvsZUzr2G6hJNsj/pY8hrChHBUEUYPHqTvmSyBJoXLpwZwqEUaiiqqVMaX5riFtnqlTvpfBvCKei+6nNX4WkJWKbXroeVRXGCZblyIGFcMNf090JFyarniKe+7yU/ITu8cz0FR6P+yrwGElccgcYL1L1cGD7260ogV80jqzI+qxWO1nZMbwJuosb91i/MLmqnSeUWuE/ezLRwOZaoScgJ4awyJh8hj/zhT7CNugjx01MQSm7ISMKD7ETtE7Zeh0CU9n7lwEqg4CwdYUTIu3s+vXE0cWJNWtNsJ1a7Bh4i/Gp2rQ8aYu+aFoAlr3uQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+Biei+yh1U5imaqv4qa4tb64kIMDwlCDUJi9sft3RFc=;
 b=HDyVVcVjaEU5YOjPDTi30tcFZSLlnlEfclRGA3FUBsIC+MR1zhH/2j+KliC8Naanrz3fC94T43eM7TmNyofCrWwPtafdEfp3scAgQA9YldEJNO6qO/M5U9aRozK9Gn3AY46CpyJ4EPXILa2MM9UMunah7O1HpEyryXBzVVvgXO8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <9da86b28-0604-45b7-9aae-7d46f4898d6d@amd.com>
Date: Mon, 17 Aug 2026 13:37:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/3] xen/arm: add i.MX8M platform support
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260814162535.331459-1-onlywig@gmail.com>
 <20260814162535.331459-4-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260814162535.331459-4-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06E:EE_|PH0PR12MB5629:EE_
X-MS-Office365-Filtering-Correlation-Id: 3e31cce1-ac4f-4ba8-87af-08defc53f453
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|23010399003|22082099003|18002099003|11063799006|56012099006|4143699003|10067099003|6133799003;
X-Microsoft-Antispam-Message-Info:
	3lQRelWc0Qzevrn/snAK1e9iGHE7DcCyobCUzLR3e6MSmtpnY7NM6oxwM2re9Q6voDzCWuIOVC9xCJ8apQ6YKI3mH/orvc1ARJODdrhU6xEbo808eoZv9W36cnx1RHDutm+4ZQs/zXLZkQfZ2aQ+vyikqT7VWtSRSSYXSWWoWrnk5sglxiWlKuauP5bS54rADu98XqpgudE/XwtkAuxS0DSVFm6+7zseqVaDt/7WWMwVE4w2R5yXVV3NmzizCjbDqW50/IYsIBbF2FsDN0A9X1Uy3O+BCn2Hie9EWTrZg+MX0YBeqViGrgt+uvN60Gc1qEnBX5F93HCIG1yEWnUyI4BmEs+emQx994DWDbcc0G1K5KtySLPSpBGFUc65ywqbyiiRZaHOVcgVKYze8CTSMK/NKKpPrARCoZFEwHG6FSi4h0Qcv8eRcyePkW8yAXPbZEpGAoWVkLEDwOgitdPrCP0FEbo/cSeZaZ1Dm8Yq3Zn9kcjdDUN9JibBMdQ3fMjwqv4VEcP4B0y5HjFaJEbaeiVmQgHT4PI1sp2xY6XJDCJMUL+82l01nqYM0NpHTXaumyGnVlaNPRIewI2v7TgsmlaCw82HJp/METYFDHqaicUPM7ajWcyoSUuxCs5M0vYMZMpe2JdzhKqS4yFAnuMoOlVFn75V5uXYqZK6qV7M6OExfr8n/WUQTq7P5qacQyJfZqpj+CaGT1tiuMifACmwdw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700016)(23010399003)(22082099003)(18002099003)(11063799006)(56012099006)(4143699003)(10067099003)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	P4nfGcNlhRRL+Ya3O8k/xe7MzUpeYJ9Y1OFLdm3y1JWuZt7AnuM4id1n81DwZ5gjC5T7FgX/XcRnxPW0D/kE2gYC+Ee2EKVzpCfz4jYWnVt8MZ6zYsiwp5rGCYCnc+zMZxnnhLON3llS0N8pgUQkRQFKaJkgxI4JKr4MGwRwrZf3LMgmeK0EfsZH8PHTuk96VzPhSz19xAGXUT5RE4Fk/FtIV7Tm8y5KeQ/2pQpNVb4lnQXXm70lPK4lOmKb/Ta9FaZOEBnM2V7GdLyyKSmqTbSw4iXKuKNFkNxKoctgo4wxtFWMyJP4Wjh5jPwozVYokBaFdINdOW2a0s+gvw7bLsck+VOnGiSZ5v9/vqRF/EM8o9/hfl+lrt+Nxi9Yh0AXrK/73MGOUOdi9nH4YaEbBQWhNhWQ3+PneQpAo0l41d3R+KpHN/bZp/3Zl4LyqZVd
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 11:37:44.4362
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e31cce1-ac4f-4ba8-87af-08defc53f453
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06E.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5629
X-purgate-ID: tlsNG-42698a/1786966669-1AAD89EA-B2121D8A/0/0
X-purgate-type: clean
X-purgate-size: 6203



On 14-Aug-26 18:25, Wig Cheng wrote:
> Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).
> 
> When Linux is used as dom0 a number of drivers make SiP SMC calls into
> TF-A to manage hardware: GPC power domains, DDR frequency scaling, SRC
> (M-core remoteproc), SoC info, NoC QoS and BBSM tamper status.  There
> is no public specification for these calls; the function IDs are taken
> from the upstream and vendor kernels.
> 
> Forward this reviewed set of calls from the hardware domain, following
> the whitelist model of the i.MX8QM platform.  CPU frequency scaling is
> denied because the hardware domain cannot make an informed decision,
> and any unknown function ID is rejected.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/platforms/Makefile |   1 +
>  xen/arch/arm/platforms/imx8m.c  | 116 ++++++++++++++++++++++++++++++++
>  2 files changed, 117 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/imx8m.c
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index bec6e55d1f..cdf936c50d 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
>  obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>  obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>  obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
> +obj-$(CONFIG_ALL64_PLAT) += imx8m.o
>  obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
> diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
> new file mode 100644
> index 0000000000..dc49e754ee
> --- /dev/null
> +++ b/xen/arch/arm/platforms/imx8m.c
> @@ -0,0 +1,116 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
Any specific reason for 2+? Can it be just GPLv2 only? We tend to prefer the
former as some companies are wary of v3.

> +/*
> + * xen/arch/arm/platforms/imx8m.c
Please remove this line. It does not add any useful information and can quickly
go stale.

> + *
> + * i.MX 8M family setup
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/sched.h>
> +#include <asm/platform.h>
> +#include <asm/smccc.h>
> +
> +static const char * const imx8m_dt_compat[] __initconst =
> +{
> +    "fsl,imx8mp",
> +    "fsl,imx8mq",
> +    "fsl,imx8mm",
> +    "fsl,imx8mn",
> +    NULL
> +};
> +
> +/*
> + * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
> + * public specification for these; the IDs and names are extracted from
> + * the upstream and vendor kernels (see drivers/soc/imx, drivers/devfreq,
> + * drivers/remoteproc, drivers/firmware/imx).
> + */
> +#define IMX_SIP_GPC         0xC2000000  /* GPC power-domain control */
Please create a macro utilizing ARM_SMCCC_CALL_VAL same as i.MX 8QM platform
driver (or EEMI) so that these values denote actual functions

> +#define IMX_SIP_CPUFREQ     0xC2000001
> +#define IMX_SIP_DDR_DVFS    0xC2000004  /* DRAM frequency scaling */
> +#define IMX_SIP_SRC         0xC2000005  /* SRC: M-core remoteproc start/stop */
> +#define IMX_SIP_GET_SOC_INFO 0xC2000006
All values should be equally indented

> +#define IMX_SIP_NOC         0xC2000008  /* NoC QoS priority setup */
> +#define IMX_SIP_BBSM        0xC200000D  /* BBSM tamper status */
> +
> +static bool imx8m_smc(struct cpu_user_regs *regs)
> +{
> +    uint32_t function_id = get_user_reg(regs, 0);
> +    struct arm_smccc_res res;
> +
> +    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
> +    {
> +        printk_once(XENLOG_WARNING
> +                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
> +
> +        return false;
> +    }
> +
> +    /* Only the hardware domain may use the SiP calls */
> +    if ( !is_hardware_domain(current->domain) )
> +    {
> +        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
> +        return false;
> +    }
> +
> +    switch ( function_id )
> +    {
> +    /*
> +     * All of these manage hardware that belongs to the hardware domain
> +     * (power domains, DRAM controller, M-core, NoC, secure RTC) or are
You mention RTC but there's no call for it. Did you miss it?

> +     * read-only queries.  Forward them.
Stray space before `Forward`

> +     */
> +    case IMX_SIP_GPC:
> +    case IMX_SIP_DDR_DVFS:
> +    case IMX_SIP_SRC:
> +    case IMX_SIP_GET_SOC_INFO:
> +    case IMX_SIP_NOC:
> +    case IMX_SIP_BBSM:
> +        break;
> +
> +    /*
> +     * CPU frequency scaling: the hardware domain does not see the whole
> +     * system and cannot make an informed decision, so deny it (matches
> +     * the i.MX8QM platform).
> +     */
> +    case IMX_SIP_CPUFREQ:
> +        return false;
> +
> +    default:
> +        gprintk(XENLOG_WARNING, "imx8m: smc: Unknown function id %x\n",
> +                function_id);
> +        return false;
> +    }
The difference between this driver and QM is that the latter whitelists
subfunctions whereas you whitelist whole services which seems like a lot. I
don't want to go into details of TF-A, Linux but I would recommend you looking
at subfunctions dom0 actually needs.

~Michal

> +
> +    arm_smccc_1_1_smc(function_id,
> +                      get_user_reg(regs, 1),
> +                      get_user_reg(regs, 2),
> +                      get_user_reg(regs, 3),
> +                      get_user_reg(regs, 4),
> +                      get_user_reg(regs, 5),
> +                      get_user_reg(regs, 6),
> +                      get_user_reg(regs, 7),
> +                      &res);
> +
> +    set_user_reg(regs, 0, res.a0);
> +    set_user_reg(regs, 1, res.a1);
> +    set_user_reg(regs, 2, res.a2);
> +    set_user_reg(regs, 3, res.a3);
> +
> +    return true;
> +}
> +
> +PLATFORM_START(imx8m, "i.MX 8M")
> +    .compatible = imx8m_dt_compat,
> +    .smc = imx8m_smc,
> +PLATFORM_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 11:39:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 11:39:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392869.1631833 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvgm-00017J-LH; Mon, 17 Aug 2026 11:39:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392869.1631833; Mon, 17 Aug 2026 11:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvvgm-00017C-Ig; Mon, 17 Aug 2026 11:39:36 +0000
Received: by outflank-mailman (input) for mailman id 1392869;
 Mon, 17 Aug 2026 11:39:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvvgl-000176-Ax
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 11:39:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvvgk-00Bh4W-O3
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 13:39:34 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82f2f0-8faa-0a2a0a5109dd-0a2a4507d4f8-22
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:39:34 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a82f2f6-b4ea-0a2a45070019-d155802aad71-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:39:34 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49558ce01afso25177645e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 04:39:34 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49987b2a176sm279487905e9.4.2026.08.17.04.39.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 04:39:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786966774; x=1787571574; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=FFKDuF1pjDgkaULm2rvBb1rJibgRJcOekByrNFPlH3c=;
        b=Zf1Ccuog/Kg6yymt600Vp9DhAiTBghlD+C8fsqjMbJHPQlUN7WEWYH0m23uTwtRqW2
         ijpxzLRozONuOvYiF9izLvzdX1hkg2/z3eTt3KIY6pV7fxqzmK0sxtirSMM7Lcso/746
         bbyWOUhJeZs+VW2ybJfu+WEY5qb7CTKqf3byjCC/7NhzvlJJGiitnIxcnd9gqiXfD2ET
         NgpTqJ0dVcseNb0jCEUjrL4sx3PUjIK7F1EQfauRyCYYXUyYOzY/MWONhh32iP+IjtSb
         1APM8n2+bUsO7Tg6naE8vKxcmLaKoTkNSw92K/EQW9ASBQVpqSdtWt6B7pgExgcMupng
         T/tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786966774; x=1787571574;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=FFKDuF1pjDgkaULm2rvBb1rJibgRJcOekByrNFPlH3c=;
        b=VJiqVsP6vjZQLShLld8WWTfYBFcf6NhQ3HxFc0WlFr+azOD7GALnV4drR7q4mah4gW
         MwyjRnU2gLYDUaSYOa0YUWC3yd+FoKb341LlaHd4octv1FxggbXCqALWzQ8/a4pMgt6r
         BgLsE2nou6UQhYLGJOYt6qv9i6mIKVM2VBBXAs9xQztSSvSbDnSLLviaZ2mUg8WAjJAv
         D2q3I579vPR5dqPkKk0u7TZq+vGXXFIaXlvQpnLam49MMOCLtI1xvAPRyboKHLfTBvuv
         I0bndlV0D5bOG+tj13zOaYxpPaXVIGH4+ibz20GVRyknyx7R1ym1iSNTg3gaDHQsLBEP
         aydA==
X-Forwarded-Encrypted: i=1; AHgh+RrA/ysfite2rSs4+/PEGbJdVFAzjFHCJQuhP7DsRiMrTOcVKFDo+ulP/Ejv0AnKfv+te1cFA0QKsZs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWXTyB1jjCOL/6OAd7xU6X89R/1Ub7/N7xwe+u8t8j3GFAqQSZ
	B0qiDuJnLlWiObLw5gTWjcX12iTNLbVrg9ZrO1IorhOWe7slyo8A7kbc
X-Gm-Gg: AR+sD10JOvduvVXS8uqugqZ3pu2vtZtMj4Fxqp3MURwbk/6Gb++5eXcu6guOBQTvzJu
	KPwYJv2YZdH+djmARqkDpTTx6fG0vIY1t8cx6fwc8heJ3TelWn18IgRllXor8m0VtKjG0v9oY8/
	owtf4LR4+OzzR5XHxQAfl4luji/Dzf/f9R12/uF3Lb7AN9P2Mw0WWsrDdcHKVUTJnO3kmT29Wtg
	pMjxjvGmtk33CeqiQmercuutZVi0KDqiLmJ9lWelSNMgBqhqiyepesIe0JHvMr5Qz871mBjD4jK
	0z/KILlbwn4Kgouv78JXX4kvWqoYroKaeJ1l7Ea7gYvE+mO2JkbCrTNxtgkt2Tm+jmw7+Oud8Mh
	2I4mEBOLxLIoim2MQfy//nCELPE4p7+giGutRgypnK8b0/D0lvEJvu2FaZ5bNYwjY7Fgl+QgXxs
	m7o+2U9f9UJq1CHaU+Kxe/I71nDW8ewVFP3nNz5Qvd7pyZfw1r5uRVbuN56g3b3NlYT4VxB8J4/
	++B2muQIlrwQZ+sslVgCYnjBW18I6DZTqwOp2/EPCIKTRxKMjU0eA==
X-Received: by 2002:a7b:cb1a:0:b0:498:519:e660 with SMTP id 5b1f17b1804b1-49987935847mr238140225e9.4.1786966774135;
        Mon, 17 Aug 2026 04:39:34 -0700 (PDT)
Message-ID: <87339fc0-fbf7-44eb-8b08-cc95ac7d1cb6@gmail.com>
Date: Mon, 17 Aug 2026 13:39:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
Content-Language: en-US
In-Reply-To: <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1786966774-36AD8AE4-0C3AB9A6/10/73395122804
X-purgate-type: spam
X-purgate-size: 561



On 8/17/26 1:33 PM, Oleksii Kurochko wrote:
>>
>>> +    BUG_ON(!trap_info);
>>> +
>>> +    trap_info->sepc = csr_read(CSR_SEPC);
>>> +    trap_info->scause = csr_read(CSR_SCAUSE);
>>> +    trap_info->stval = csr_read(CSR_STVAL);
>>
>> Do you really need to re-read all three registers here? Didn't you 
>> read at least
>> scause already, in order to make it here in the first place?
> 
> Agree, ->scause and ->sepc are already read.

scause should be re-reaad as we don't save it inside cpu_user_regs 
structure.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 12:11:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 12:11:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392883.1631846 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwBm-00072g-7Z; Mon, 17 Aug 2026 12:11:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392883.1631846; Mon, 17 Aug 2026 12:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwBm-00072Z-4T; Mon, 17 Aug 2026 12:11:38 +0000
Received: by outflank-mailman (input) for mailman id 1392883;
 Mon, 17 Aug 2026 12:11:37 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wvwBk-00072T-Vp
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 12:11:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvwBj-005sHB-HJ
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:11:35 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a82fa6e-2eae-0a2a0a5409dd-0a2a450aa3f0-32
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:11:35 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a82fa77-f2d2-0a2a450a0019-d1558032d150-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:11:35 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so31568605e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 05:11:35 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7840esm3121758f8f.29.2026.08.17.05.11.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 05:11:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786968695; x=1787573495; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=mm8rYwJ94WoMy2zl46KL0OvoZuAPqnQ3iss5Dazj+AY=;
        b=Lf8C2e8t3ssGPz/ombKBE6jYiiu4wzQRkOwWM/6+Un/7T/GOpPU+CYUSGwwRv2xKnH
         /1/kF73HTQHrV5lXjlhg7FGvlf56KNSlh2l/nHeoHP6pMd3t9gtqnD+7t2Kjdo0zyVYJ
         I1+kypmiu6bYWSI694ej3nbfenB04UecMgUlg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786968695; x=1787573495;
        h=content-transfer-encoding:content-type: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=mm8rYwJ94WoMy2zl46KL0OvoZuAPqnQ3iss5Dazj+AY=;
        b=qBGM3gsoU3xK3J2TD4UwVNIaN/SsCxRd6xyv1HixhawN5SWER1JSlIeA5Qpj/r41fx
         GRMUAbaL+zbR8w9C/9lJMKw5qhVwfI6HezvVQqXSTZ59YwqwvHReZrQdCp0NwSOwtbDO
         4mk2FmwY6yH2MxyiiCLJhAN1V/hCuxCe6sR/+zRLZhzQOb5uBNSV1CvTNKfClgccs9cC
         mhIIpWqvck1AHAjwgsU4/79hobVgzEKmCDDVSCL5QqlF6nxgIvnCZedDomJeZZl4QOT1
         6qwe5ibO4x7nTJLZv2Smq/ErqE1+6jDzbzx0Zg1y03Fzz+AlLTh6JPGFjoBiiI6RGaHD
         xVfg==
X-Gm-Message-State: AOJu0Yy889E4RXWOhMR5QyKS6Jj7ONf1G/hgDoT9+SLS4pkjd0QgvwaC
	HH/wr53XGgTmaIUIzw0zQh/i4p4pbk+tCl52/X/uQg8P3OarCNYGQ4/8Ak3BGP+Fkc0nnPkMghp
	gjLW1Tj4=
X-Gm-Gg: AR+sD13QdxRGPW/dXilN9KsiywY+WBaetjr9h168zXu27zupt4VxWTy5ae47oEfDRPt
	wJrKdj5q7WkBHR4jz4pBLyWoTTCjWag4Gl31mDoHr/FSaoaR+TY/yT4s8bYAUwchw7qG39yS+Bp
	i4nBdvXU6F/7125mBDsTZUnj04bIXoJZqTxY2qtBs4ZFM8zay0BcDS+ygnyku0O5ZH7uI6g2E7A
	aEZzHY6aFMrmPbE2UOQQb8S0nzvLLs2G8t5AC0skHd0VWkkYgQh3meF7p9WoE7Tx3ozAh6NWT+6
	e6d+bWKoYIbkgf/K4/sYP/JKv3FkNOPSUoiwKbhRnD7YoVbUBn+bO9Msgx4SF1SLawprMFHEQVG
	4HLb5ltNfQfhKruFe139r5HS6jLxYUiVGvGo/pLS59fpATWbL1RfDP3m9SvgfLXWIDNC93PxSrM
	lhnTX2Ws6mX0BzUc+0e9p32NfOrOk8KmhN3KSpXDp090v810siRXOMjFxdNbNOsLXwEOEN1nMXA
	o5mB6chjRiu8wvG1Y+c73hMghN/gRZCr1HosgA=
X-Received: by 2002:a05:600c:8b37:b0:497:ff73:68d5 with SMTP id 5b1f17b1804b1-499878cf9bamr364886625e9.0.1786968694285;
        Mon, 17 Aug 2026 05:11:34 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v2 2/3] x86/emul: Rename the x86_seg_* system segments
Date: Mon, 17 Aug 2026 13:11:29 +0100
Message-Id: <20260817121129.1787344-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260814185841.1757421-3-andrew.cooper3@citrix.com>
References: <20260814185841.1757421-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786968695-520C1CFC-34B20C49/0/0
X-purgate-type: clean
X-purgate-size: 27715

These refer to the segments themsevles, not to the registers, even if there is
a tight coupling between the two.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

v2:
 * Rename x86_seg_tr => x86_seg_tss too.
 * Fix up a couple of comments refering to the old names.
---
 .../fuzz/x86_instruction_emulator/fuzz-emul.c |  4 +-
 tools/tests/x86_emulator/test_x86_emulator.c  |  4 +-
 xen/arch/x86/hvm/domain.c                     | 15 +++--
 xen/arch/x86/hvm/hvm.c                        | 56 +++++++++----------
 xen/arch/x86/hvm/svm/svm.c                    | 28 +++++-----
 xen/arch/x86/hvm/vmx/realmode.c               |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c                    | 44 +++++++--------
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h       |  2 +-
 xen/arch/x86/include/asm/x86-types.h          | 10 ++--
 xen/arch/x86/pv/emul-priv-op.c                |  2 +-
 xen/arch/x86/vm_event.c                       |  4 +-
 xen/arch/x86/x86_emulate/0f01.c               |  2 +-
 xen/arch/x86/x86_emulate/x86_emulate.c        | 16 +++---
 xen/arch/x86/x86_emulate/x86_emulate.h        |  2 +-
 14 files changed, 97 insertions(+), 94 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
index 2b9b72df3584..a797d17fe536 100644
--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -173,7 +173,7 @@ static int fuzz_read(
     /* Reads expected for all user and system segments. */
     if ( is_x86_user_segment(seg) )
         assert(ctxt->addr_size == 64 || !(offset >> 32));
-    else if ( seg == x86_seg_tr )
+    else if ( seg == x86_seg_tss )
         /*
          * The TSS is special in that accesses below the segment base are
          * possible, as the Interrupt Redirection Bitmap starts 32 bytes
@@ -362,7 +362,7 @@ static int fuzz_cmpxchg(
     if ( is_x86_user_segment(seg) )
         assert(ctxt->addr_size == 64 || !(offset >> 32));
     else
-        assert((seg == x86_seg_gdtr || seg == x86_seg_ldtr) && !(offset >> 16));
+        assert((seg == x86_seg_gdt || seg == x86_seg_ldt) && !(offset >> 16));
 
     return maybe_fail(ctxt, "cmpxchg", true);
 }
diff --git a/tools/tests/x86_emulator/test_x86_emulator.c b/tools/tests/x86_emulator/test_x86_emulator.c
index 31391f1bf790..61b2840ee058 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -559,7 +559,7 @@ static int read(
     {
         uint64_t value;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         /* Fake system segment type matching table index. */
         if ( (offset & 7) || (bytes > 8) )
             return X86EMUL_UNHANDLEABLE;
@@ -579,7 +579,7 @@ static int read(
         memcpy(p_data, &value, bytes);
         return X86EMUL_OKAY;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         /* Fake user segment type matching table index. */
         if ( (offset & 7) || (bytes > 8) )
             return X86EMUL_UNHANDLEABLE;
diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
index a0e811ea47a0..414ece94922f 100644
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -34,7 +34,7 @@ static int check_segment(struct segment_register *reg, enum x86_segment seg)
         return 0;
     }
 
-    if ( seg == x86_seg_tr )
+    if ( seg == x86_seg_tss )
     {
         if ( reg->s )
         {
@@ -88,7 +88,7 @@ static int check_segment(struct segment_register *reg, enum x86_segment seg)
         }
         break;
 
-    case x86_seg_tr:
+    case x86_seg_tss:
         break;
 
     default:
@@ -131,18 +131,21 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
 #define SEG(s, r) ({                                                        \
     s = (struct segment_register)                                           \
         { 0, { (r)->s ## _ar }, (r)->s ## _limit, (r)->s ## _base };        \
-    /* Set accessed / busy bit for present segments. */                     \
+    /* Set accessed bit for present segments. */                            \
     if ( (s).p )                                                            \
-        (s).type |= (x86_seg_ ## s != x86_seg_tr ? 1 : 2);                  \
+        (s).type |= 2;                                                      \
     check_segment(&(s), x86_seg_ ## s); })
 
         rc = SEG(cs, regs);
         rc |= SEG(ds, regs);
         rc |= SEG(ss, regs);
         rc |= SEG(es, regs);
-        rc |= SEG(tr, regs);
 #undef SEG
 
+        tr = (struct segment_register){
+            0, { regs->tr_ar | 1 /* Busy */ }, regs->tr_limit, regs->tr_base };
+        rc |= check_segment(&tr, x86_seg_tss);
+
         if ( rc != 0 )
             return rc;
 
@@ -307,7 +310,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
     hvm_set_segment_register(v, x86_seg_ds, &ds);
     hvm_set_segment_register(v, x86_seg_ss, &ss);
     hvm_set_segment_register(v, x86_seg_es, &es);
-    hvm_set_segment_register(v, x86_seg_tr, &tr);
+    hvm_set_segment_register(v, x86_seg_tss, &tr);
 
     /* Sync AP's TSC with BSP's. */
     v->arch.hvm.cache_tsc_offset =
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a75ccb57bf04..5cb4c348ec75 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -879,11 +879,11 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
     /* Architecture-specific vmcs/vmcb bits */
     alternative_vcall(hvm_funcs.save_cpu_ctxt, v, &ctxt);
 
-    hvm_get_segment_register(v, x86_seg_idtr, &seg);
+    hvm_get_segment_register(v, x86_seg_idt, &seg);
     ctxt.idtr_limit = seg.limit;
     ctxt.idtr_base = seg.base;
 
-    hvm_get_segment_register(v, x86_seg_gdtr, &seg);
+    hvm_get_segment_register(v, x86_seg_gdt, &seg);
     ctxt.gdtr_limit = seg.limit;
     ctxt.gdtr_base = seg.base;
 
@@ -923,13 +923,13 @@ static int cf_check hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
     ctxt.gs_base = seg.base;
     ctxt.gs_arbytes = seg.attr;
 
-    hvm_get_segment_register(v, x86_seg_tr, &seg);
+    hvm_get_segment_register(v, x86_seg_tss, &seg);
     ctxt.tr_sel = seg.sel;
     ctxt.tr_limit = seg.limit;
     ctxt.tr_base = seg.base;
     ctxt.tr_arbytes = seg.attr;
 
-    hvm_get_segment_register(v, x86_seg_ldtr, &seg);
+    hvm_get_segment_register(v, x86_seg_ldt, &seg);
     ctxt.ldtr_sel = seg.sel;
     ctxt.ldtr_limit = seg.limit;
     ctxt.ldtr_base = seg.base;
@@ -1129,11 +1129,11 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 
     seg.limit = ctxt.idtr_limit;
     seg.base = ctxt.idtr_base;
-    hvm_set_segment_register(v, x86_seg_idtr, &seg);
+    hvm_set_segment_register(v, x86_seg_idt, &seg);
 
     seg.limit = ctxt.gdtr_limit;
     seg.base = ctxt.gdtr_base;
-    hvm_set_segment_register(v, x86_seg_gdtr, &seg);
+    hvm_set_segment_register(v, x86_seg_gdt, &seg);
 
     seg.sel = ctxt.cs_sel;
     seg.limit = ctxt.cs_limit;
@@ -1175,13 +1175,13 @@ static int cf_check hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
     seg.limit = ctxt.tr_limit;
     seg.base = ctxt.tr_base;
     seg.attr = ctxt.tr_arbytes;
-    hvm_set_segment_register(v, x86_seg_tr, &seg);
+    hvm_set_segment_register(v, x86_seg_tss, &seg);
 
     seg.sel = ctxt.ldtr_sel;
     seg.limit = ctxt.ldtr_limit;
     seg.base = ctxt.ldtr_base;
     seg.attr = ctxt.ldtr_arbytes;
-    hvm_set_segment_register(v, x86_seg_ldtr, &seg);
+    hvm_set_segment_register(v, x86_seg_ldt, &seg);
 
     if ( ctxt.flags & XEN_X86_FPU_INITIALISED )
         vcpu_setup_fpu(v, &ctxt.fpu_regs);
@@ -2875,11 +2875,11 @@ static int task_switch_load_seg(
     }
 
     /* LDT descriptor must be in the GDT. */
-    if ( (seg == x86_seg_ldtr) && (sel & 4) )
+    if ( (seg == x86_seg_ldt) && (sel & 4) )
         goto fault;
 
     hvm_get_segment_register(
-        v, (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr, &desctab);
+        v, (sel & 4) ? x86_seg_ldt : x86_seg_gdt, &desctab);
 
     /* Segment not valid for use (cooked meaning of .p)? */
     if ( !desctab.p )
@@ -2897,7 +2897,7 @@ static int task_switch_load_seg(
         desc = *pdesc;
 
         /* LDT descriptor is a system segment. All others are code/data. */
-        if ( (desc.b & (1u<<12)) == ((seg == x86_seg_ldtr) << 12) )
+        if ( (desc.b & (1 << 12)) == ((seg == x86_seg_ldt) << 12) )
             goto fault;
 
         dpl = (desc.b >> 13) & 3;
@@ -2920,7 +2920,7 @@ static int task_switch_load_seg(
             if ( (dpl != cpl) || (dpl != rpl) )
                 goto fault;
             break;
-        case x86_seg_ldtr:
+        case x86_seg_ldt:
             /* LDT system segment? */
             if ( (desc.b & _SEGMENT_TYPE) != (2u<<8) )
                 goto fault;
@@ -3035,8 +3035,8 @@ void hvm_task_switch(
     unsigned int token = hvmemul_cache_disable(v);
     struct tss32 tss;
 
-    hvm_get_segment_register(v, x86_seg_gdtr, &gdt);
-    hvm_get_segment_register(v, x86_seg_tr, &prev_tr);
+    hvm_get_segment_register(v, x86_seg_gdt, &gdt);
+    hvm_get_segment_register(v, x86_seg_tss, &prev_tr);
 
     if ( ((tss_sel & 0xfff8) + 7) > gdt.limit )
     {
@@ -3120,7 +3120,7 @@ void hvm_task_switch(
     tss.fs = segr.sel;
     hvm_get_segment_register(v, x86_seg_gs, &segr);
     tss.gs = segr.sel;
-    hvm_get_segment_register(v, x86_seg_ldtr, &segr);
+    hvm_get_segment_register(v, x86_seg_ldt, &segr);
     tss.ldt = segr.sel;
 
     rc = hvm_copy_to_guest_linear(prev_tr.base + offsetof(typeof(tss), eip),
@@ -3146,7 +3146,7 @@ void hvm_task_switch(
 
     new_cpl = tss.eflags & X86_EFLAGS_VM ? 3 : tss.cs & 3;
 
-    if ( task_switch_load_seg(x86_seg_ldtr, tss.ldt, new_cpl, 0) )
+    if ( task_switch_load_seg(x86_seg_ldt, tss.ldt, new_cpl, 0) )
         goto out;
 
     rc = hvm_set_cr3(tss.cr3, false, true);
@@ -3193,7 +3193,7 @@ void hvm_task_switch(
     }
 
     tr.type = 0xb; /* busy 32-bit tss */
-    hvm_set_segment_register(v, x86_seg_tr, &tr);
+    hvm_set_segment_register(v, x86_seg_tss, &tr);
 
     v->arch.hvm.guest_cr[0] |= X86_CR0_TS;
     hvm_update_guest_cr(v, 0);
@@ -4011,14 +4011,14 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, uint16_t ip)
     hvm_set_segment_register(v, x86_seg_ss, &reg);
 
     reg.attr = 0x82; /* LDT */
-    hvm_set_segment_register(v, x86_seg_ldtr, &reg);
+    hvm_set_segment_register(v, x86_seg_ldt, &reg);
 
     reg.attr = 0x8b; /* 32-bit TSS (busy) */
-    hvm_set_segment_register(v, x86_seg_tr, &reg);
+    hvm_set_segment_register(v, x86_seg_tss, &reg);
 
     reg.attr = 0;
-    hvm_set_segment_register(v, x86_seg_gdtr, &reg);
-    hvm_set_segment_register(v, x86_seg_idtr, &reg);
+    hvm_set_segment_register(v, x86_seg_gdt, &reg);
+    hvm_set_segment_register(v, x86_seg_idt, &reg);
 
     /* Sync AP's TSC with BSP's. */
     v->arch.hvm.cache_tsc_offset =
@@ -5278,7 +5278,7 @@ void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
             reg->db = 0;
         break;
 
-    case x86_seg_tr:
+    case x86_seg_tss:
         /*
          * SVM doesn't track %tr.B. Architecturally, a loaded TSS segment will
          * always be busy.
@@ -5294,8 +5294,8 @@ void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
         reg->p = 1;
         break;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         /*
          * Treat GDTR/IDTR as being present system segments.  This avoids them
          * needing special casing for segmentation checks.
@@ -5382,7 +5382,7 @@ void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
         }
         break;
 
-    case x86_seg_tr:
+    case x86_seg_tss:
         ASSERT(reg->p);                              /* Usable. */
         ASSERT(!reg->s);                             /* System segment. */
         ASSERT(!(reg->sel & 0x4));                   /* !TI. */
@@ -5394,7 +5394,7 @@ void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
             ASSERT(!"%tr typecheck failure");
         break;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         if ( reg->p )
         {
             ASSERT(!reg->s);                         /* System segment. */
@@ -5404,8 +5404,8 @@ void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
         }
         break;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         ASSERT(is_canonical_address(reg->base));
         ASSERT((reg->limit >> 16) == 0);             /* Upper bits clear. */
         break;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 38c61db1d71d..fb9ddf70dc75 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -622,20 +622,20 @@ static void cf_check svm_get_segment_register(
             reg->dpl = vmcb_get_cpl(vmcb);
         break;
 
-    case x86_seg_tr:
+    case x86_seg_tss:
         svm_sync_vmcb(v, vmcb_in_sync);
         *reg = vmcb->tr;
         break;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         *reg = vmcb->gdtr;
         break;
 
-    case x86_seg_idtr:
+    case x86_seg_idt:
         *reg = vmcb->idtr;
         break;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         svm_sync_vmcb(v, vmcb_in_sync);
         *reg = vmcb->ldtr;
         break;
@@ -664,15 +664,15 @@ static void cf_check svm_set_segment_register(
         vmcb->cleanbits.seg = false;
         break;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         vmcb->cleanbits.dt = false;
         break;
 
     case x86_seg_fs:
     case x86_seg_gs:
-    case x86_seg_tr:
-    case x86_seg_ldtr:
+    case x86_seg_tss:
+    case x86_seg_ldt:
         if ( v == current )
             svm_sync_vmcb(v, vmcb_needs_vmload);
         break;
@@ -694,21 +694,21 @@ static void cf_check svm_set_segment_register(
         vmcb->sreg[seg] = *reg;
         break;
 
-    case x86_seg_tr:
+    case x86_seg_tss:
         vmcb->tr = *reg;
         break;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         vmcb->gdtr.base = reg->base;
         vmcb->gdtr.limit = reg->limit;
         break;
 
-    case x86_seg_idtr:
+    case x86_seg_idt:
         vmcb->idtr.base = reg->base;
         vmcb->idtr.limit = reg->limit;
         break;
 
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         vmcb->ldtr = *reg;
         break;
 
@@ -1163,8 +1163,8 @@ static void svm_emul_swint_injection(struct x86_event *event)
      * this entry, even though we don't look at all the words read.
      */
     hvm_get_segment_register(curr, x86_seg_cs, &cs);
-    hvm_get_segment_register(curr, x86_seg_idtr, &idtr);
-    if ( !hvm_virtual_to_linear_addr(x86_seg_idtr, &idtr, idte_offset,
+    hvm_get_segment_register(curr, x86_seg_idt, &idtr);
+    if ( !hvm_virtual_to_linear_addr(x86_seg_idt, &idtr, idte_offset,
                                      idte_size, hvm_access_read,
                                      &cs, &idte_linear_addr) )
         goto raise_exception;
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index ff44ddcfa627..9787a7bdcfb8 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -34,7 +34,7 @@ static void realmode_deliver_exception(
     uint16_t frame[3];
     unsigned int last_byte;
 
-    idtr = hvmemul_get_seg_reg(x86_seg_idtr, hvmemul_ctxt);
+    idtr = hvmemul_get_seg_reg(x86_seg_idt,  hvmemul_ctxt);
     csr  = hvmemul_get_seg_reg(x86_seg_cs,   hvmemul_ctxt);
     __set_bit(x86_seg_cs, &hvmemul_ctxt->seg_reg_dirty);
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 269ca5643346..c2a76d691e34 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1227,20 +1227,20 @@ static void cf_check vmx_get_segment_register(
     }
 
     /*
-     * Xen's x86_seg_* enumeration *almost* matches the VMCS encoding order.
+     * Xen's x86_segment encoding *almost* matches the VMCS encoding order.
      *
-     * tr and ldtr are reversed, and other areas of code rely on this, so we
+     * TSS and LDT are reversed, and other areas of code rely on this, so we
      * can't just re-enumerate.
      */
-    BUILD_BUG_ON(x86_seg_tr   != 6);
-    BUILD_BUG_ON(x86_seg_ldtr != 7);
-    BUILD_BUG_ON(x86_seg_gdtr != 8);
-    BUILD_BUG_ON(x86_seg_idtr != 9);
+    BUILD_BUG_ON(x86_seg_tss != 6);
+    BUILD_BUG_ON(x86_seg_ldt != 7);
+    BUILD_BUG_ON(x86_seg_gdt != 8);
+    BUILD_BUG_ON(x86_seg_idt != 9);
     switch ( tmp_seg = seg )
     {
-    case x86_seg_tr:
-    case x86_seg_ldtr:
-        tmp_seg ^= 1; /* Flip tr and ldtr so GUEST_SEG_*() works. */
+    case x86_seg_tss:
+    case x86_seg_ldt:
+        tmp_seg ^= 1; /* Flip TSS and LDT so GUEST_SEG_*() works. */
         fallthrough;
 
     case x86_seg_es ... x86_seg_gs:
@@ -1248,8 +1248,8 @@ static void cf_check vmx_get_segment_register(
         __vmread(GUEST_SEG_AR_BYTES(tmp_seg), &attr);
         fallthrough;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         __vmread(GUEST_SEG_LIMIT(tmp_seg),    &limit);
         __vmread(GUEST_SEG_BASE(tmp_seg),     &reg->base);
         break;
@@ -1272,11 +1272,11 @@ static void cf_check vmx_get_segment_register(
         (!(attr & (1u << 16)) << 7) | (attr & 0x7f) | ((attr >> 4) & 0xf00);
 
     /* Adjust for virtual 8086 mode */
-    if ( v->arch.hvm.vmx.vmx_realmode && seg <= x86_seg_tr
+    if ( v->arch.hvm.vmx.vmx_realmode && seg <= x86_seg_tss
          && !(v->arch.hvm.vmx.vm86_segment_mask & (1u << seg)) )
     {
         struct segment_register *sreg = &v->arch.hvm.vmx.vm86_saved_seg[seg];
-        if ( seg == x86_seg_tr ) 
+        if ( seg == x86_seg_tss )
             *reg = *sreg;
         else if ( reg->base != sreg->base || seg == x86_seg_ss )
         {
@@ -1312,12 +1312,12 @@ static void cf_check vmx_set_segment_register(
     base = reg->base;
 
     /* Adjust CS/SS/DS/ES/FS/GS/TR for virtual 8086 mode */
-    if ( v->arch.hvm.vmx.vmx_realmode && seg <= x86_seg_tr )
+    if ( v->arch.hvm.vmx.vmx_realmode && seg <= x86_seg_tss )
     {
         /* Remember the proper contents */
         v->arch.hvm.vmx.vm86_saved_seg[seg] = *reg;
         
-        if ( seg == x86_seg_tr ) 
+        if ( seg == x86_seg_tss )
         {
             const struct domain *d = v->domain;
             uint64_t val = d->arch.hvm.params[HVM_PARAM_VM86_TSS_SIZED];
@@ -1367,9 +1367,9 @@ static void cf_check vmx_set_segment_register(
 
     switch ( seg )
     {
-    case x86_seg_tr:
-    case x86_seg_ldtr:
-        seg ^= 1; /* Flip tr and ldtr so GUEST_SEG_*() works. */
+    case x86_seg_tss:
+    case x86_seg_ldt:
+        seg ^= 1; /* Flip TSS and LDT so GUEST_SEG_*() works. */
         fallthrough;
 
     case x86_seg_es ... x86_seg_gs:
@@ -1377,8 +1377,8 @@ static void cf_check vmx_set_segment_register(
         __vmwrite(GUEST_SEG_AR_BYTES(seg), attr);
         fallthrough;
 
-    case x86_seg_gdtr:
-    case x86_seg_idtr:
+    case x86_seg_gdt:
+    case x86_seg_idt:
         __vmwrite(GUEST_SEG_LIMIT(seg),    limit);
         __vmwrite(GUEST_SEG_BASE(seg),     base);
         break;
@@ -1738,9 +1738,9 @@ static void cf_check vmx_update_guest_cr(
              (realmode != v->arch.hvm.vmx.vmx_realmode) )
         {
             enum x86_segment s;
-            struct segment_register reg[x86_seg_tr + 1];
+            struct segment_register reg[x86_seg_tss + 1];
 
-            BUILD_BUG_ON(x86_seg_tr != x86_seg_gs + 1);
+            BUILD_BUG_ON(x86_seg_tss != x86_seg_gs + 1);
 
             /* Entering or leaving real mode: adjust the segment registers.
              * Need to read them all either way, as realmode reads can update
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index f85a8c8bbaba..d0716e97d25c 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -174,7 +174,7 @@ struct vmx_vcpu {
     /* Bitmask of segments that we can't safely use in virtual 8086 mode */
     uint16_t             vm86_segment_mask;
     /* Shadow CS, SS, DS, ES, FS, GS, TR while in virtual 8086 mode */
-    struct segment_register vm86_saved_seg[x86_seg_tr + 1];
+    struct segment_register vm86_saved_seg[x86_seg_tss + 1];
     /* Remember EFLAGS while in virtual 8086 mode */
     uint32_t             vm86_saved_eflags;
     int                  hostenv_migrated;
diff --git a/xen/arch/x86/include/asm/x86-types.h b/xen/arch/x86/include/asm/x86-types.h
index 26b06aeac380..d11fe036b435 100644
--- a/xen/arch/x86/include/asm/x86-types.h
+++ b/xen/arch/x86/include/asm/x86-types.h
@@ -30,10 +30,10 @@ enum x86_segment {
     x86_seg_fs,
     x86_seg_gs,
     /* System: Valid to use for implicit table references. */
-    x86_seg_tr,
-    x86_seg_ldtr,
-    x86_seg_gdtr,
-    x86_seg_idtr,
+    x86_seg_tss,
+    x86_seg_ldt,
+    x86_seg_gdt,
+    x86_seg_idt,
     /* No Segment: For (system/normal) accesses which are already linear. */
     x86_seg_sys,
     x86_seg_none
@@ -47,7 +47,7 @@ static inline bool is_x86_user_segment(enum x86_segment seg)
 }
 static inline bool is_x86_system_segment(enum x86_segment seg)
 {
-    return seg >= x86_seg_tr && seg < x86_seg_none;
+    return seg >= x86_seg_tss && seg < x86_seg_none;
 }
 
 /*
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 1a3e3012e23c..7bebd2ccdc21 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -504,7 +504,7 @@ static int cf_check read_segment(
     struct x86_emulate_ctxt *ctxt)
 {
     /* Check if this is an attempt to access the I/O bitmap. */
-    if ( seg == x86_seg_tr )
+    if ( seg == x86_seg_tss )
     {
         switch ( ctxt->opcode )
         {
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 112d2ef66dc7..efafb4e4bc14 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -183,7 +183,7 @@ static void vm_event_pack_segment_register(enum x86_segment segment,
         reg->es_sel = seg.sel;
         break;
 
-    case x86_seg_gdtr:
+    case x86_seg_gdt:
         reg->gdtr_base = seg.base;
         reg->gdtr_limit = seg.limit;
         break;
@@ -248,7 +248,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
     vm_event_pack_segment_register(x86_seg_ss, &req->data.regs.x86);
     vm_event_pack_segment_register(x86_seg_ds, &req->data.regs.x86);
     vm_event_pack_segment_register(x86_seg_es, &req->data.regs.x86);
-    vm_event_pack_segment_register(x86_seg_gdtr, &req->data.regs.x86);
+    vm_event_pack_segment_register(x86_seg_gdt, &req->data.regs.x86);
 
     req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
     req->data.regs.x86.dr6 = ctxt.dr6;
diff --git a/xen/arch/x86/x86_emulate/0f01.c b/xen/arch/x86/x86_emulate/0f01.c
index d2a106557d36..ff39aefd0382 100644
--- a/xen/arch/x86/x86_emulate/0f01.c
+++ b/xen/arch/x86/x86_emulate/0f01.c
@@ -22,7 +22,7 @@ int x86emul_0f01(struct x86_emulate_state *s,
                  struct x86_emulate_ctxt *ctxt,
                  const struct x86_emulate_ops *ops)
 {
-    enum x86_segment seg = (s->modrm_reg & 1) ? x86_seg_idtr : x86_seg_gdtr;
+    enum x86_segment seg = (s->modrm_reg & 1) ? x86_seg_idt : x86_seg_gdt;
     int rc;
 
     switch ( s->modrm )
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index e15ab3775854..7de646083639 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -814,13 +814,13 @@ static int ioport_access_check(
      * X86EMUL_DONE coming back here may be used to defer the port
      * permission check to the respective ioport hook.
      */
-    if ( (rc = ops->read_segment(x86_seg_tr, &tr, ctxt)) != 0 )
+    if ( (rc = ops->read_segment(x86_seg_tss, &tr, ctxt)) != 0 )
         return rc == X86EMUL_DONE ? X86EMUL_OKAY : rc;
 
     /* Ensure the TSS has an io-bitmap-offset field. */
     generate_exception_if(tr.type != 0xb, X86_EXC_GP, 0);
 
-    switch ( rc = read_ulong(x86_seg_tr, 0x66, &iobmp, 2, ctxt, ops) )
+    switch ( rc = read_ulong(x86_seg_tss, 0x66, &iobmp, 2, ctxt, ops) )
     {
     case X86EMUL_OKAY:
         break;
@@ -834,7 +834,7 @@ static int ioport_access_check(
     }
 
     /* Read two bytes including byte containing first port. */
-    switch ( rc = read_ulong(x86_seg_tr, iobmp + first_port / 8,
+    switch ( rc = read_ulong(x86_seg_tss, iobmp + first_port / 8,
                              &iobmp, 2, ctxt, ops) )
     {
     case X86EMUL_OKAY:
@@ -891,7 +891,7 @@ protmode_load_seg(
     const struct x86_emulate_ops *ops)
 {
     const struct cpu_policy *cp = ctxt->cpu_policy;
-    enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr;
+    enum x86_segment sel_seg = (sel & 4) ? x86_seg_ldt : x86_seg_gdt;
     struct { uint32_t a, b; } desc, desc_hi = {};
     uint8_t dpl, rpl;
     int cpl = x86emul_get_cpl(ctxt, ops);
@@ -912,7 +912,7 @@ protmode_load_seg(
                 break;
             /* fall through */
         case x86_seg_cs:
-        case x86_seg_tr:
+        case x86_seg_tss:
             goto raise_exn;
         }
         if ( seg == x86_seg_none || !_amd_like(cp) || vcpu_has_nscb() ||
@@ -992,13 +992,13 @@ protmode_load_seg(
         if ( (dpl != cpl) || (dpl != rpl) )
             goto raise_exn;
         break;
-    case x86_seg_ldtr:
+    case x86_seg_ldt:
         /* LDT system segment? */
         if ( (desc.b & (15u<<8)) != (2u<<8) )
             goto raise_exn;
         a_flag = 0;
         break;
-    case x86_seg_tr:
+    case x86_seg_tss:
         /* Available TSS system segment? */
         if ( (desc.b & (15u<<8)) != (9u<<8) )
             goto raise_exn;
@@ -2914,7 +2914,7 @@ x86_emulate(
         break;
 
     case X86EMUL_OPC(0x0f, 0x00): /* Grp6 */
-        seg = (modrm_reg & 1) ? x86_seg_tr : x86_seg_ldtr;
+        seg = (modrm_reg & 1) ? x86_seg_tss : x86_seg_ldt;
         generate_exception_if(!in_protmode(ctxt, ops), X86_EXC_UD);
         switch ( modrm_reg & 6 )
         {
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h b/xen/arch/x86/x86_emulate/x86_emulate.h
index 534b1c46fad3..d86ed7b3e0c9 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -51,7 +51,7 @@ struct x86_emul_fpu_aux {
  /*
   * Operation fully done by one of the hooks:
   * - validate(): operation completed (except common insn retire logic)
-  * - read_segment(x86_seg_tr, ...): bypass I/O bitmap access
+  * - read_segment(x86_seg_tss, ...): bypass I/O bitmap access
   * - read_io() / write_io(): bypass GPR update (non-string insns only)
   * Undefined behavior when used anywhere else.
   */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 12:19:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 12:19:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392892.1631855 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwJV-0007jU-1D; Mon, 17 Aug 2026 12:19:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392892.1631855; Mon, 17 Aug 2026 12:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwJU-0007jN-Ul; Mon, 17 Aug 2026 12:19:36 +0000
Received: by outflank-mailman (input) for mailman id 1392892;
 Mon, 17 Aug 2026 12:19:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvwJT-0007jH-On
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 12:19:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvwJS-00GnZq-QB
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:19:34 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82fc54-e002-0a2a0a5209dd-0a2a4504c778-4
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:19:34 +0200
Received: from [52.101.43.21]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a82fc54-b57f-0a2a45040019-34652b157a11-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:19:34 +0200
Received: from BN9PR03CA0378.namprd03.prod.outlook.com (2603:10b6:408:f7::23)
 by CY8PR12MB8194.namprd12.prod.outlook.com (2603:10b6:930:76::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 12:19:25 +0000
Received: from MN1PEPF0000F0E2.namprd04.prod.outlook.com
 (2603:10b6:408:f7:cafe::58) by BN9PR03CA0378.outlook.office365.com
 (2603:10b6:408:f7::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Mon,
 17 Aug 2026 12:19:24 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 MN1PEPF0000F0E2.mail.protection.outlook.com (10.167.242.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Mon, 17 Aug 2026 12:19:24 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 07:19:24 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 07:19:21 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=whkLmkd0PAf58XYwjI8SftWaaMEgfcWC+yqqqlVpcz3gF/WJpXLz+fxYeUe54iFYrxGrag1pAsotWGdJPMUOftRmG9V6MzCDm0k+36p/wqhEVqZHIrJDzjX+E3DMMLgBdwC5U0iEUVvRdp6yGACMzOnurj+C1yzCt6pJP3q/FSoN+NWYJ6N45pZo3tVkkd56k1/+I930514AIGmWF9mDCW3i8teY0B8aid3naIPgAzbgAvPKCVdbDqt586zo2ShqzrEhokFBuexMWV5vgkpA6M7vic8waQlH3MNRz9Bl0uGSN1BRVAoR0mclMywJJDRKABASRehbsRUsgaQJCN3J8w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Xe80fhEQSwjndlQz7q67yiDsbz9eJTHhOn+Pkvtb0/8=;
 b=rLI8byiECUhBgzKtOMH6dP8C8oHf0sgvUAyFQZ9dfvSlp3wSSAyRmb30STZ0P0vTKHCmBu/a2zzhgly6xk3pfMZ3uDcdvbHTGrGO74HfrUm2eAkyfdvG9Iew3HdvadbvGlvQzsnEKQiSlyMBTCF02rkiaAKlupt6u4VMzwajCPSSe8Kx0qp+sMDcQko7DJQsUb4iye51+4XK5UlWy76nETmDr+J0kwiKBFm5KHFJPnY8uoxzSE91CSYmCJ8tFpLsIPDsH5Joa8Jn1I0ntxvwvcy5e5+TLYnSNkMEtA3lnWdxaPD695r6yi3V+a/X6QIk55WaCGVirI+nxp+1rEKvSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Xe80fhEQSwjndlQz7q67yiDsbz9eJTHhOn+Pkvtb0/8=;
 b=mmXJ5kVZv2fiBP/iRxbwEd7WhTqHw4ZZqG2SJ+AYoqZZXcwhvA4zVUk0vJJojHTOnDLikFtWRT77jgcfiQF9/zVc6aGWJuaW96G5EBy2txh1rXNsB1Lh4h06rurEeYABfQgbE8K5dhozuLf0G9QdxZAP1xfqzR564TumaMLV/tc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <e052ac27-1ea9-4f30-9e6b-3dc879708262@amd.com>
Date: Mon, 17 Aug 2026 14:19:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] xen/arm: report proper GIC version via
 XEN_DOMCTL_getdomaininfo
To: Julian Vetter <julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, Oleksii
 Kurochko <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e2b5000edb5@vates.tech>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e2b5000edb5@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E2:EE_|CY8PR12MB8194:EE_
X-MS-Office365-Filtering-Correlation-Id: 98223a4b-abce-462b-7fa6-08defc59c693
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|23010399003|376014|7416014|82310400026|1800799024|6133799003|10067099003|4143699003|11063799006|56012099006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	OGmrqXPFbYhKsF1iLj1aRmFAtO5UtGF/xa/9PH7yl/E+sRVBAvoTy9/FBCMKhgFDoip8B70P3oyn1FvECi1yoPSmCXJ+rytwvP6ZCU8Q7KbHBCslu2xanHjMI8nLnW5Gwdl3MwVZxi6MPBuUWudnWBZlnAz6RJNAOQ+hpBec5ZFREhtWYHGhMzokR+svs5QxWHdyk0JK6APOosFxcg7CiIk0CSA2G6qZ1gwJHrmUupgvGJaDoNOY6L7GTqEl1jzhXtbTGE378Be7w8xTNh/eFR5jtrIVTtkPpsQ1GqMdJ5M3fdhrNp9/D0X79+ITGQq6EDJ675tFCqKR7v15QiBC2cCxOJ5EAIEVaMPy1N5ak1QfvC/B0lkqZO/THNqtST/oACG3MUkvcgXz9aUzCFq2oQ3vBvFhK9wKK9/W1oth01PEdZsTib3LfkJ2AHRP5g8vydjKfiDMJsIfdl8qqjfJ0FKzNQGAxwlk0b/suZz/Pixnc+doRtwdjBPzSqkWVPuHSqvn87TGobK2mb2z+MpiQQveFIrXFOlssQNoT0k93Kv9uEeQuRBBSBBQjHPia/IjUgP8cpXVEFw/RmVVXSS9MFVwg9l3kS27D9J7j1LgOtVPu2GjUAwex83VQJluEzLkjxBnn+tF85/FGfNdzY3/Kf3kwf5JoehSA7Ar2IlJKfFVFMMHX6bmE8c7238GuqlKr5bgINtfUBwXgRn0KosRKA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(376014)(7416014)(82310400026)(1800799024)(6133799003)(10067099003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	24j0TbTIb6RrmtiZDcfJJQmlojVLWm69gAyBqKmPwX8q6chCnzvIa/ngZtPaF3+EV7BUBL/ZKl7gGKzaR5GrbhkPQ/GGQu24k9z/9LAqRUCILAxDOdsugOGYwWGvTEXaGxprWwAso2778IYRAMZjmWa1vMff/0GSujCWHz3+rSO/Cb9gJvf89ngc/IYTlXYgr/VtaLqnqFpGL7LKmAXPfzhNNR/K8TRTBx56UPVkdTEf9PZjm/e+MaFbaMkhx2WwD8bnqI7hCVkLb2HMk0lOfdL4whmdgbwIXGghFB/9V2mK4e+hlUT0rM2IRj2Wrlz0NKphRhD1XzJBNhY/+rvniAJY8BPj52uddjKplxbflNVoaUaxNGZ3uxXQWhtpcIJWwC4evlPioTXwX21aUx6CVIVbV/yKYYTGGETbaVsakAE/OhgTs9AbYzixdT9OPW/O
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 12:19:24.6600
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 98223a4b-abce-462b-7fa6-08defc59c693
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000F0E2.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8194
X-purgate-ID: tlsNG-ebf023/1786969174-C0EDEB50-4A0F3524/0/0
X-purgate-type: clean
X-purgate-size: 1168



On 16-Jul-26 16:11, Julian Vetter wrote:
> When creating a domain on ARM, and passing XEN_DOMCTL_CONFIG_GIC_NATIVE
> for the gic_version field in the struct xen_arch_domainconfig,
> arch_sanitise_domain_config() resolves this to the approrpiate GIC_V2 or
> GIC_V3 version the domain actually has, based on the host's
> gic_hw_version(). That value is stored in the domain as
> d->arch.vgic.version, but can't be queried through any other domctl
> later. Toolstacks that create and build a domain in the same call
> already have this info from the createdomain reply and never need to ask
> again.
> 
> Toolstacks that create a domain and build it later from a separate
> process do need to ask again. But, the ARM implementation only fills in
> info->flags and info->gpaddr_bits. info->arch_config is left zeroed, so
> XEN_DOMCTL_getdomaininfo always reports gic_version as
> XEN_DOMCTL_CONFIG_GIC_NATIVE (0) regardless of what was actually
> configured earlier.
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 12:40:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 12:40:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392906.1631864 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwd3-0002AW-M7; Mon, 17 Aug 2026 12:39:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392906.1631864; Mon, 17 Aug 2026 12:39:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwd3-0002AO-IJ; Mon, 17 Aug 2026 12:39:49 +0000
Received: by outflank-mailman (input) for mailman id 1392906;
 Mon, 17 Aug 2026 12:39:48 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvwd2-0002AI-6p
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 12:39:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvwd1-00Bt6H-Jj
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:39:47 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a83010c-8faa-0a2a0a5109dd-0a2a4506df86-12
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:39:47 +0200
Received: from [52.101.46.52]
 (helo=CO1PR03CU002.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a83010c-195a-0a2a45060019-34652e34fc3a-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:39:42 +0200
Received: from BN9PR03CA0353.namprd03.prod.outlook.com (2603:10b6:408:f6::28)
 by CHXPR12MB999221.namprd12.prod.outlook.com (2603:10b6:610:2fa::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Mon, 17 Aug
 2026 12:39:33 +0000
Received: from BN3PEPF0000B36D.namprd21.prod.outlook.com
 (2603:10b6:408:f6:cafe::5e) by BN9PR03CA0353.outlook.office365.com
 (2603:10b6:408:f6::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Mon,
 17 Aug 2026 12:39:33 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BN3PEPF0000B36D.mail.protection.outlook.com (10.167.243.164) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.0 via Frontend Transport; Mon, 17 Aug 2026 12:39:33 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 07:39:33 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 07:39:33 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 07:39:29 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PAg/ZIM6eL665tU4oTPAjrVkgAkeQMNEImPfHp1lAaIwQYkPRVt1YkEUUd5rvBKrUejBA0qFKGhv5YhVe4IxbjC+XPfOFKBjS/QbjWxi7jbtiLZKAUdv/rcCln4SwSJW1CUKPQS6OtxJtHPVaSAU6Bv/Vsyra/j5ZBe9bWs+PlfwfNXWPxzKbshjW2EVbmCwlClMNRVaMYZ0R0aoVDyk4LXXejTip7uCLxgtT7amyyS2SyI0Z8AuSXnyilebdvMVZ4u/AgfFxERldRGebzDyPsjBDtPo3N6bjo7rUszl25VKWUCaDPNOZqSWIzfBINyX0sK+36hbkk2L062DsvTIPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=y3u6Db12QY4PhKMFWPD5Y/+VusXMFIdi/b0QbYsJf84=;
 b=xo/O1VWvyi189LtXzd0ydExjjW56S9ywgb+WTtDsydlivGHDeh5vLP1DR7mBasRSw+x7R5ckCVwcW0j4aaDBeN7kjWKnYjZYqKCs+dZzgh3D6flC38jgNxJvhUXV98BLmK8iHU8oI4crQKQjuFOHhRi3hpcPZa2qNFfbfeOFjRvA1wslT/cS1MP3mlXRHshumyF26I9L2o0fzk8KDrifxO+f3Y1vyQQFkyqq5zTxj7kLJbrnG4W2ME72ZI9tvCBMzOo3i1Cqs+C7j6jv/RHCp+FOd2KHj8EcLcw0VHkdZkUrq3VglvjG/hq7pDzT31c2IDhCaD+2ImS/13T5wmQmew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=y3u6Db12QY4PhKMFWPD5Y/+VusXMFIdi/b0QbYsJf84=;
 b=OsX5e8YF4RtMMjb7E3s9zn6pci4izW5W3Fop5GoXsHz8PXkJKsV3UtpXCx0VbvMrAfHfrvCfbNwsd/UXU3UW2HZa0ghZYIEdIvZmt88RlczGOZMIGmqymndH2jd0zv0bACqQJXUp+nmxSNTMT7se4rqmsY5RSOt+/hGo77kdMzk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <ee383990-f688-4244-b817-5df4c2f8decc@amd.com>
Date: Mon, 17 Aug 2026 14:39:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/6] ARM/sysctl: Expose the supported guest GIC modes
 in physinfo
To: Julian Vetter <julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, "Oleksii
 Kurochko" <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e427000edb5@vates.tech>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e427000edb5@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B36D:EE_|CHXPR12MB999221:EE_
X-MS-Office365-Filtering-Correlation-Id: 33411fc7-3661-4350-f83a-08defc5c9720
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700016|7416014|376014|1800799024|23010399003|56012099006|4143699003|5023799004|11063799006|10067099003|18002099003|6133799003|22082099003;
X-Microsoft-Antispam-Message-Info:
	CAMrLQV7BkdhyZHblKvmwpItkkKBIc+J3kQZGNzHp/REjvqFp5X91EE50fAGdOniJt5hsyjhdw9u6mhWqXz0tAIKW6WsOTV8t5zAeQE+rteNgOixyyK6rCYE/vZXoS3O5jxkoddSkfliCUwHUT51uvfW5CIM+hImscbdarpYk1hTk4zFqkMF52IaJzdCxzX98uaujhR+1ktMLoZ4FGXQ5EXc/HqWBgelsnLCslLHbXEixoWPupPiq3RF0WQwh+pwP+ZvIF2TKbvIvIXSdjLWnvlYy2j0v65LpEDYWjyw18NcPKvo1T4nVpCtXLX2b63WPYnU+i+pTvWJM36BjOlzvRZIOoTXoW3OhGF7yGVa7MwgZCRQep2lu4x/GUmTaOw0bO3d9GtJbiCaKr/k+8YdGqueAbkS9Ob21saM1yZfkZlbT44e69KuSIY8cJ/P80NUMhiHqN240Cq58rixmOeqEQCWnm808A0xbFY9SgWfphrCtmdk1gcIY7pv91e4NWZ3F0kKIwVp2PO5aLRylU2QSqxX25OXzlS29++Ra8j9P1hS+aRKwGLn7ZjE9VaCs8XKaTUgFfStzkiExdBE7StgbJXCKgryvBpiYmwm9cjuot763pWpSq8ahsjOtKms+G3n4IEmL3ixDc3erHsrTvRkAaBAarZaOAbaQeE6qhWUTZ2VEnk3YGQkqmkIoswHNPANGbkrZDmX42LuUNtp/lU8tQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(7416014)(376014)(1800799024)(23010399003)(56012099006)(4143699003)(5023799004)(11063799006)(10067099003)(18002099003)(6133799003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	SyuUwcO9XRBSTMm8WGXjOFbKxP/se0P42etSVs4B1W+bRq7LPtWr8//sjJSouLV1utwH9151vF0tvK3yJKZ1yX1xA00eAIYQ8ojakcvjognFaHAcQJUBmyRtQ7q/CiiB2EiIPxFTzpouFujhzvUUDGArz0T+Kva2U3JwzYngRRzwdRy3rKHYbXO1rhuMRxRkSH2bAwKwX44/cOvW7XPJdsdGbt3lvyWOOQT9G0c7NqWiL7xYoU7F4oAhGH+0kAwRuBCI6nQKe36iz/XZprP6AjBMdEYZkCwb0OFy0HtKeW8HAymAtR/PWHNjgn4W/wlrzfwzAng00awZfKNttvmh5FltEEraIGOyUR+wnzN4m/jEwuTEAQHr4TtftV+RWE9eigBTnGmDnQu08xXJSJhKEjecHV/8N0CfCdh7Pg6t5DyS9JnHb7YzYuFjZ/8ahO16
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 12:39:33.5455
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 33411fc7-3661-4350-f83a-08defc5c9720
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B36D.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CHXPR12MB999221
X-purgate-ID: tlsNG-16d1c6/1786970387-FCA0477B-1DFCFFD5/0/0
X-purgate-type: clean
X-purgate-size: 2579



On 16-Jul-26 16:11, Julian Vetter wrote:
> From: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> Changes in v3:
> - No changes
> ---
>  xen/arch/arm/sysctl.c       | 26 ++++++++++++++++++++++++++
>  xen/include/public/sysctl.h |  2 ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index 32cab4feff..3b0edf4cec 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -12,7 +12,10 @@
>  #include <xen/dt-overlay.h>
>  #include <xen/errno.h>
>  #include <xen/hypercall.h>
> +
>  #include <asm/arm64/sve.h>
> +#include <asm/gic.h>
> +
>  #include <public/sysctl.h>
>  
>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> @@ -21,6 +24,29 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>  
>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
> +
> +    /*
> +     * The GIC version(s) we're happy creating guests with.  Right now for
> +     * simplicity it is tied to the active hardware version, but this will
> +     * cease to be the case if/when the compatbility modes are enabled.
s/compatbility/compatibility/

GICv3 may support GICv2 and we support libxl guest requesting GICv2 on a GICv3
host. Why are we not exposing this information here?

> +     */
> +    switch ( gic_hw_version() )
> +    {
> +    case GIC_V2:
> +        pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V2;
> +        break;
> +
> +    case GIC_V3:
> +        pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V3;
> +        break;
> +
> +    case GIC_INVALID:
> +        /*
> +         * Running a control domain without having the GIC sorted yet?
> +         * Something's broken, but there's nothing we can do about it here.
> +         */
Add ASSERT_UNREACHABLE here.

> +        break;
> +    }
>  }
>  
>  long arch_do_sysctl(struct xen_sysctl *sysctl,
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index c7cd9b4eb0..d20ebf3644 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -106,6 +106,8 @@ struct xen_sysctl_tbuf_op {
>  
>  #if defined(__arm__) || defined(__aarch64__)
>  #define XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK  (0x1FU)
> +#define XEN_SYSCTL_PHYSCAP_ARM_GIC_V2    (1U << 5)
> +#define XEN_SYSCTL_PHYSCAP_ARM_GIC_V3    (1U << 6)
>  #endif
>  
>  struct xen_sysctl_physinfo {

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 12:40:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 12:40:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1392912.1631873 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwds-0003aX-UZ; Mon, 17 Aug 2026 12:40:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1392912.1631873; Mon, 17 Aug 2026 12:40:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvwds-0003aQ-Re; Mon, 17 Aug 2026 12:40:40 +0000
Received: by outflank-mailman (input) for mailman id 1392912;
 Mon, 17 Aug 2026 12:40:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wvwdr-0003aJ-DP
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 12:40:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvwdq-00BtKZ-LT
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:40:38 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a830143-8faa-0a2a0a5109dd-0a2a450485d0-6
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:40:38 +0200
Received: from [40.93.201.43]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a830144-b57f-0a2a45040019-285dc92b5d79-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 14:40:38 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CH2PR03MB5302.namprd03.prod.outlook.com (2603:10b6:610:9f::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 12:40:34 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026
 12:40:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=og7kMu/QaAwbC6m/sySy/N1YIqyaQwmfTjQcoJCpIbBpB9VQeR8q05IeUY+EyePBInjX0goYwy7ymon3pf+zrTxKkiTsb8AkW4WXH7Fqqm+oHfaxK0KAHHhvl18WLgF6vGVEcGgETfTPBggVOW8GXpHa27fxSgEu/nYTTTdXXy75fQud1JWj4wT8KjGEsQXdlQ9DbtydqiuStxcC4BPTu5vWOfeHlx69K5oz/ZQWQ7jB9fDJ1FMfZzd2yRfA7wdGji/TRaTiVRDnTscqz9nAm/GCIkjJZKv7qAnC4CGel532fVZ/0H8Hw1peVugZaO5YHsmZyUR6IgW4Lc3qlsB+Zg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CCVDK/pH+N6pkNmAz4FOIbG+CD4VwbAdBV3xJJbNKIc=;
 b=EGhqakFCO5djhchzvPxllMjjzMVW/q68l2GLkY2ohCXfXD8JUpdTWi3H9rPtu9ijRq9l8HAo3+k99J0xGJV0ERCacIZJ01xicbD4sJaAjpE3O8H1QqsZsKitLqpiZMa3PAu/qR6I0qm5E3baQZwCmtczOyWXxUGGup8riLLsKU9gzVyFrY1NTJX4XGHygXnTgxkJJtGTaOXasTTDBA0+vUS7lBEeQ2ZeP+S84pjLTb2jgJ7cGchjv1iBOITHNNUleOfxKCZC2ow/MV+8JLR9qxYvZCohnMoIlM5TCvZ2uxJyGW/A7jYvVQho8sChxG/febvi0n4eD9MRdOnYFOFyGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CCVDK/pH+N6pkNmAz4FOIbG+CD4VwbAdBV3xJJbNKIc=;
 b=qSMfrf2V6L8pEMfTpxEvrQiGOuiDr2lJJTDvL5PK1mWtiqt9hmaztb1fuMjuLaji5dpJzHh/UO4pCaHvCtHxa1nBtPH8IK5IbdyDukJIOFZRPR+WS0te1bulSnbKn45HrlAkDvgsQk6cpTkQxzmd9AwlODbFespW/YEuaHl30Sg=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <5b358558-1b17-49b2-af5e-37981d11094f@citrix.com>
Date: Mon, 17 Aug 2026 13:40:31 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 2/5] tests/x86: Introduce a userspace test harness for
 x86_decode_lite()
To: Jan Beulich <jbeulich@suse.com>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-3-andrew.cooper3@citrix.com>
 <dd065a33-0105-4527-92f5-f3f127422ee6@suse.com>
 <21d3fae8-e9b0-4c8a-a7b9-483a0257e44e@citrix.com>
 <b76b3fa9-cac9-401f-adc7-88f6881a64f6@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <b76b3fa9-cac9-401f-adc7-88f6881a64f6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P302CA0007.GBRP302.PROD.OUTLOOK.COM
 (2603:10a6:600:2c2::14) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH2PR03MB5302:EE_
X-MS-Office365-Filtering-Correlation-Id: b27bee48-6340-4106-06a2-08defc5cbb5d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|4143699003|11063799006|5023799004|56012099006|22082099003|18002099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	5BJQQJLxExrJx/yuOriO0PgdctSqJG7KVVpJaifGBBrc70j2yGpSsKALqCyNsSXuLllB3nkEs1cTZu98V854EUnGGpLlxHsG+cDseGet8cErcT+888F0eO/weltIgTroi6G8QaJ63+F1OQlA/UsqA1fUoGuoiYkyfKGkALrH+QaFxjX1uuW/3G+aX5EyHMMT91avtdZz6wNIFiA5NS3vE+7hVa+2HfeycDWyhnK1fIBiBym3khGgC6Uo1bhFO4MbDdWqQb6Z3Njj8OtdFRDZn4K5pKzoxZJNtV78VZZoFZEKPTa6B9c97Wi7ybL0r5TJkHXr9363WPj+fFrNoS1pTvBYhaj5GjPFuYJG5dciUcYu8MlON37/7S0dpmUkWkP8uiSDa3jVrl2gSdNZGA5fZpEUyUZC1hnPGzf+uX4aAlxGp2rWFGteav1q+JDs15qHm74hTVYBErgZUUu8QC6gwPYgT5zxB1cg39xaB15qSGFFOCU2/sWGFDTEf7UcmRkmBKxhsQ1yZCCwAUKmPpAdVBO6oMs8NLXcc1oDU5m8rrJWj2x39qeniZ2ZnGNbidTGsK6KfQyTuFe+Or6pQmxidCAdf4uT3i5CwzQnXHn4i7nFmQpbnnOxcA027sPThxh1kQtyhUawGIXaqV8IjSgImq0ZRLGu5NugjCaHkd2OoKo=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(10067099003)(4143699003)(11063799006)(5023799004)(56012099006)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UGh4bS9rZW5VTitIQU9kVXhzQTVNRmhDNGFnT2EvOGk4SWlTbzVXWWFjVG5F?=
 =?utf-8?B?NnFUYU11WnZpRGhHZDl6WDJHeWhieStuNjZSZjVpUVFpVjBha05qK2NKT0xL?=
 =?utf-8?B?aTRKald2TmtJcDJ4dUp6Q2VlOXlwYkJPSGRjQnpWUmF1QloxdVFQTHdmcWc5?=
 =?utf-8?B?TVU4Q1o0OXl4NUFrZ3VxVjFRYjBzMVFRUFZETzl6KzAxMVBqcTFqU05CU0hE?=
 =?utf-8?B?aHZ6cDRwNzFjMTZNRzRGdTlqREtOcStBNS9aVitzQStENnpQVk82Wk1CaVpD?=
 =?utf-8?B?YzR1NzczT1NZdjhHYnp1Z05UME9DWWZ6cWpHS1I2NEprYnFJY0VGMmNrZTEx?=
 =?utf-8?B?NjNlNXR1L1VpdTg5cWFUbGp5d2FRVEpQVU1LMit4TE52N0FIWHlXSVFXYlNR?=
 =?utf-8?B?L2RrNHd5UlN5RVdFdUx6U2hydU5jWGhZcE9vdkFNeGtURkxMc0FpR3pXY2tw?=
 =?utf-8?B?VVBNQXpQeElJTmlidmF2WlZqcGM0RVhPMjFCbHgwRFYzNWNydDlHRm1Gd3g5?=
 =?utf-8?B?SC8reWtIMTlVR3dPamZvMXFXUXl0YVRXNHBRRXFxdXdyZnhzUU8zMkNMK1I0?=
 =?utf-8?B?WDR4WTJoa2tJazF4WlVEajNPUEg3dlJRcjdQZzAxYjZNVW1NZ2x4WmtsTWQw?=
 =?utf-8?B?OG94U1pqamljTGNISTdPM2RKMXlUbkJQeTljZmVkUFJNZm9sYUFhUCtENXBv?=
 =?utf-8?B?WFd2b2pYQStwbWc1cWJGVldubW83NUNPSk5NRlo1Tk5Hdnp6VDNJTko2cTBW?=
 =?utf-8?B?dWlOaUZTaGV6MnlXWkNJRUFZS01FTlhxL2NBOGlmUDd3VEZOc1EyS1NsSTZ2?=
 =?utf-8?B?cUdEYUFYVnY5RjBsemgyaG15Q3NHR0RSaUZ5NDIvVVo1MFgzNXFFdkFINkZv?=
 =?utf-8?B?TWkrS2N6UGJTZFlmTFZrZ1BYeVU3Y25wTGJRMTFOOG1Bb2pBK1FWSFJLWEh1?=
 =?utf-8?B?dFlGVElZQmNEQXNWZEw4Zk9VQVc5b0RsRU9IKzFScXcwZC8zNEdVNFUrSzBO?=
 =?utf-8?B?dTJJajYwWnFEUmE3blZBRmN5RTlWeGhTOGlyaTFDaVlRVFlBMy9TT2pyb2E4?=
 =?utf-8?B?QmpSblNCWlhQYUNqeURYRU1LRW5tNXBPeTBrM25WTnRTeUU3akRZZGhDWHNa?=
 =?utf-8?B?aUZqTkR0Yk5uNDhhWU5oTHJVSFZveWRtNWF0RFBJQTlYTGVZbFU1Q0RMWHB0?=
 =?utf-8?B?MWlncGRSdXlRblBVakQ2WWRwa2I3VGswSWZOL2laU2tWanNjK0FjZUtrSko4?=
 =?utf-8?B?cStPT1dCekIvVmtSQi9PdXhqSlREVkM2cGhGTUZIK3dyMHB4U25yZ3F3RnVL?=
 =?utf-8?B?VnJXejhtbjEvQ0pYN2lOZkl4WjJTREswR0ZlSkZEL3ZqM2RGNTU3ZGNZOC9j?=
 =?utf-8?B?N0xFWFNPNGg2akR4MTl5MzRFLzJESlFnbXJFOGl0YlgvSGNZdzI2Y0Q5ZStK?=
 =?utf-8?B?Wk9EUHNpNTJtZzlzcWlibGptdDRhYkJzYitRSkpidTgxNGNKSktxWjFlRGV1?=
 =?utf-8?B?TTJITlpOTmdWWUdMT09aSE9xaFhrcTBXa3Z2SXJYZG5nUldBQzJzRGUrcDdV?=
 =?utf-8?B?dzlqMlE5YlEvN1lhQi9uM2s0ZGZXNXFPL3RzRGhSenJDQ0tWcFZydDBuOVQ1?=
 =?utf-8?B?SzViZDJuUjFxNzBTNDJDNmZwTGpKRkFFMXBFRVlyendsRW5XckthYVpXb29F?=
 =?utf-8?B?aUt1djdWNllVU0RZSDdiZCt6c0h1NVhqQ1hSTko1OCtpM0NlKzFqQmxCUlJJ?=
 =?utf-8?B?MVEzMTZOS2oxeFBDUFBOdXFteEdURW00Skc3a2l0d0xWZ0NyWS9neDJaVDM5?=
 =?utf-8?B?ejAvakZQbkRvaERrTDRudS9Da1JwbmVuc2xacXhncGlxUURUaTdWeENUMjUz?=
 =?utf-8?B?c2JQUXo3QnM0aW5idHUvdE0zVlduSmhKZzR1M2w2ZVFmTkpoSVpXYjRqTXhM?=
 =?utf-8?B?b1N1cCtiMU5XRUhldGZjQWlJWWczekhtK2RzWlczK2Z4bVJpTVhxN04vKzNO?=
 =?utf-8?B?a3hNWHhqZXk2M3hFRE9RbmdBbWgzMm5wZE1UYjJyVnEyeVdTeG80ZWEvdUQy?=
 =?utf-8?B?Q2dFVnZ2WkV2NXhFSTQ1QlorMVNBcEgvK216VTJ6Mm44NlVkZ3BaSHpXSlFN?=
 =?utf-8?B?Sm9mY3FFVVNheXpRMWY2aDZsd1RVdW5CNnhRTGZLbTcrL2hwdWdhc2phRE10?=
 =?utf-8?B?bU9lZTYwRkovbnFITUhJTXptUUFuSTJBT2wzcHhnc3I4Umw5NDd1YW5VbFFh?=
 =?utf-8?B?RTV0Wk9TYjdJZVZvNjRDaGZWUlJSQ21TVm5rRDd0STNsL3pFc1QvSGljVjht?=
 =?utf-8?B?dU43SjdNeERSb2hEMWxxYjhKSExrc1VIckQrNyt3c2V0R04xczhYeUxDZ1dJ?=
 =?utf-8?Q?ve/+AVkSJ8gaL/SU=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b27bee48-6340-4106-06a2-08defc5cbb5d
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 12:40:34.4889
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7xLHUuUMpoLzYjMWSqxsWNRRC+3GpRGA5FeRCcLSZeGe8GZgn6q9qr8pQF3gl+nFqflW8+4leZYL/y+JH/lnsFSdGtwl/AdHgR9Un7/2ObU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5302
X-purgate-ID: tlsNG-ebf023/1786970438-C3EC6B50-036035FB/0/0
X-purgate-type: clean
X-purgate-size: 6861

On 05/08/2026 7:45 am, Jan Beulich wrote:
> On 04.08.2026 21:37, Andrew Cooper wrote:
>> On 03/08/2026 5:03 pm, Jan Beulich wrote:
>>> On 03.08.2026 09:20, Andrew Cooper wrote:
>>>> --- /dev/null
>>>> +++ b/tools/tests/x86-decode-lite/insns.S
>>>> @@ -0,0 +1,703 @@
>>>> +#include "macro-magic.h"
>>>> +
>>>> +        .code64
>>>> +
>>>> +        .allow_index_reg
>>>> +
>>>> +        .text
>>>> +
>>>> +DECL(tests_rel0)
>>>> +modrm:
>>>> +        /* Mod=0, Reg=0, RM {0..f} */
>>>> +        _ add %al, (%rax)
>>>> +        _ add %al, (%rcx)
>>>> +        _ add %al, (%rdx)
>>>> +        _ add %al, (%rbx)
>>>> +        _ add %al, (%rsp) /* SIB */
>>>> +        /*add %al, (%rbp)    RIP --> tests_rel4 */
>>>> +        _ add %al, (%rsi)
>>>> +        _ add %al, (%rdi)
>>>> +        _ add %al, (%r8)
>>>> +        _ add %al, (%r9)
>>>> +        _ add %al, (%r10)
>>>> +        _ add %al, (%r11)
>>>> +        _ add %al, (%r12) /* SIB */
>>>> +        /*add %al, (%r13)    RIP --> tests_rel4 */
>>>> +        _ add %al, (%r14)
>>>> +        _ add %al, (%r15)
>>>> +
>>>> +        /* Mod=1, Reg=0, RM {0..f} */
>>>> +        _ add %al, 0x01(%rax)
>>>> +        _ add %al, 0x01(%rcx)
>>>> +        _ add %al, 0x01(%rdx)
>>>> +        _ add %al, 0x01(%rbx)
>>>> +        _ add %al, 0x01(%rsp) /* SIB */
>>>> +        _ add %al, 0x01(%rbp)
>>>> +        _ add %al, 0x01(%rsi)
>>>> +        _ add %al, 0x01(%rdi)
>>>> +        _ add %al, 0x01(%r8)
>>>> +        _ add %al, 0x01(%r9)
>>>> +        _ add %al, 0x01(%r10)
>>>> +        _ add %al, 0x01(%r11)
>>>> +        _ add %al, 0x01(%r12) /* SIB */
>>>> +        _ add %al, 0x01(%r13)
>>>> +        _ add %al, 0x01(%r14)
>>>> +        _ add %al, 0x01(%r15)
>>>> +
>>>> +        /* Mod=2, Reg=0, RM {0..f} */
>>>> +        _ add %al, 0x7f000001(%rax)
>>>> +        _ add %al, 0x7f000001(%rcx)
>>>> +        _ add %al, 0x7f000001(%rdx)
>>>> +        _ add %al, 0x7f000001(%rbx)
>>>> +        _ add %al, 0x7f000001(%rsp) /* SIB */
>>>> +        _ add %al, 0x7f000001(%rbp)
>>>> +        _ add %al, 0x7f000001(%rsi)
>>>> +        _ add %al, 0x7f000001(%rdi)
>>>> +        _ add %al, 0x7f000001(%r8)
>>>> +        _ add %al, 0x7f000001(%r9)
>>>> +        _ add %al, 0x7f000001(%r10)
>>>> +        _ add %al, 0x7f000001(%r11)
>>>> +        _ add %al, 0x7f000001(%r12) /* SIB */
>>>> +        _ add %al, 0x7f000001(%r13)
>>>> +        _ add %al, 0x7f000001(%r14)
>>>> +        _ add %al, 0x7f000001(%r15)
>>>> +
>>>> +        /* Mod=3, Reg=0, RM {0..f} */
>>>> +        _ add %al, %al
>>>> +        _ add %al, %cl
>>>> +        _ add %al, %dl
>>>> +        _ add %al, %bl
>>>> +        _ add %al, %ah
>>>> +        _ add %al, %ch
>>>> +        _ add %al, %dh
>>>> +        _ add %al, %dl
>>> Perhaps also include %bpl, %sil, and %dil?
>> They're not relevant to this test, and interfere with the intentional
>> pattern set up.
> Hmm, how does a particular pattern matter here? I don't think you test those
> cases (or more generally an empty REX prefix) anywhere else.

There's nothing structurally interesting about those; I'm not testing
the assembler, and x86_decode_lite() doesn't decode registers.

The ModRM byte has multiple structurally interesting interactions with
REX prefixes, hence the coverage of Mod and RM value.

The patten makes it trivial to look at the disassembled result and check
the coverage.  (And spot the bug that's hiding in plain sight above.)

>>>> --- /dev/null
>>>> +++ b/tools/tests/x86-decode-lite/main.c
>>>> @@ -0,0 +1,111 @@
>>>> +/*
>>>> + * Userspace test harness for x86_decode_lite().
>>>> + */
>>>> +#include <stdio.h>
>>>> +
>>>> +#include "x86-emulate.h"
>>>> +
>>>> +static unsigned int nr_failures;
>>>> +#define fail(t, fmt, ...)                                       \
>>>> +({                                                              \
>>>> +    const unsigned char *insn = (t)->ip;                        \
>>>> +                                                                \
>>>> +    nr_failures++;                                              \
>>>> +                                                                \
>>>> +    (void)printf("  Fail '%s' [%02x", (t)->name, *insn);        \
>>>> +    for ( unsigned int i = 1; i < (t)->len; i++ )               \
>>>> +        printf(" %02x", insn[i]);                               \
>>>> +    printf("]\n");                                              \
>>>> +                                                                \
>>>> +    (void)printf(fmt, ##__VA_ARGS__);                           \
>>>> +})
>>>> +
>>>> +struct test {
>>>> +    const char *name;
>>>> +    void *ip;
>>>> +    unsigned long len;
>>>> +};
>>>> +
>>>> +extern const struct test
>>>> +/* Defined in insns.S, ends with sentinel */
>>>> +    tests_rel0[], /* No relocatable entry */
>>>> +    tests_rel1[], /* disp8 */
>>>> +    tests_rel4[], /* disp32 or RIP-relative */
>>>> +    tests_unsup[]; /* Unsupported instructions */
>>>> +
>>>> +static inline void run_tests(const struct test *tests, unsigned int rel_sz)
>>>> +{
>>>> +    printf("Test rel%u\n", rel_sz);
>>>> +
>>>> +    for ( unsigned int i = 0; tests[i].name; ++i )
>>>> +    {
>>>> +        const struct test *t = &tests[i];
>>>> +        x86_decode_lite_t r;
>>>> +
>>>> +        /*
>>>> +         * Don't end strictly at t->len.  This provides better diagnostics if
>>>> +         * too many bytes end up getting consumed.
>>>> +         */
>>>> +        r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
>>> For the excess bytes to at least be legitimate to access (not causing UB),
>>> shouldn't finish_arr emit enough filler bytes?
>> finish_arr is the wrong place, but I've folded in:
>>
>> diff --git a/tools/tests/x86-decode-lite/insns.S b/tools/tests/x86-decode-lite/insns.S
>> index e52c2934c8d8..dc017016b2d2 100644
>> --- a/tools/tests/x86-decode-lite/insns.S
>> +++ b/tools/tests/x86-decode-lite/insns.S
>> @@ -695,6 +695,13 @@ unsup_insn: /* Instructions that would complicated decode, or shouldn't be used
>>  
>>  END(tests_unsup)
>>  
>> +        /*
>> +         * For improved diagnostics, we allow some overreading of the
>> +         * instruction under test.  Ensure there are good bytes to read.
>> +         */
>> +overread_padding:
>> +        .skip 20
>> +
>>          /* This is here to cause jmps to use their disp32 form. */
>>          .section .text.other_section, "ax", @progbits
>>  other_section:
> How would this help? run_tests() is never invoked with tests_unsup[] as
> argument. And run_tests_unsup() wants to only fetch up to t->len.

Oh, in which case nothing is needed at all.  I'll take it back out.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 13:08:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 13:08:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393011.1631922 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvx4u-0007Pa-Hn; Mon, 17 Aug 2026 13:08:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393011.1631922; Mon, 17 Aug 2026 13:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvx4u-0007PT-Ek; Mon, 17 Aug 2026 13:08:36 +0000
Received: by outflank-mailman (input) for mailman id 1393011;
 Mon, 17 Aug 2026 13:08:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wvx4s-0007PL-RW
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 13:08:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvx4s-00GwjQ-18
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 15:08:34 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8307ca-bab6-0a2a0a5309dd-0a2a450aac74-12
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 15:08:33 +0200
Received: from [40.107.209.41]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8307d0-f2d2-0a2a450a0019-286bd1293038-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 15:08:33 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SN4PR03MB989380.namprd03.prod.outlook.com (2603:10b6:806:216::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 13:08:25 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026
 13:08:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q8yZp6L/93Dhb2EinVYmCN+SQYH8JHgqN+Ag8VGTmf/d5b9MH9uup44E5ySsZ5NOMjWlwG2ze+a9JI4DdQoCi7Si2FUoibCD2/NW3KBR4kD7ao4STQYpHVpJFmn1PjE2+mApudsC9epPRMNMr3EGbh5tvGyEiv1coTVb5v8v+Lgq4qYmIim4+KIFV3IcZVbKwHntkgywztLiGuhrOjqm/IFqX8vXK51skltlkawaPtTxEUWbJg9b/aBIBsynyOBfes5623SRpPM+YZUVXrJaDNfkruPrwBXzmqctoAighET+irdSBOiynUGzydjDnXmYaOlLl1/0Bh+PFXo4vLX6kA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=JfBim/D1WrHJiuKX4bGy8SY/mlkevzkIn6lffNvC3C4=;
 b=qaAQaQoGfzq1tkh7WDiiH84LzAQfiC9Sh4dd3BFufJfkyPgEw8jHtpPPc6LS6JmIchfuBuR3gxiKRkjBzrHJsdANt/9G7+VPXf5LYYARJsUH8CykHnjlAy6u+C6yzS0nNNTSHopMN7PATCrmJo99pZI6Uj4YAIjjUAXG2fx7NtVvjqAKwcwxyecudQc2+51uBui8sFImLSxPh/NtaAmcs95YWQmMY+f1s8/7n8bo+aZVVXvvwbZja52WO4U/chm2b4o4y9OggdMShNOFqI+Th5J8LZEnTcBkDFPSjsst6vQjHma0+EtNAT4GetWDiTK1YwVnQnZma9DYx/9rGsMziA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JfBim/D1WrHJiuKX4bGy8SY/mlkevzkIn6lffNvC3C4=;
 b=U5HJSqiJ1INXpErQyQ+UPupUM0uF+jSCCQu/ACO1PN63mnQULy+tk9vI1guKfpmjUnRnx+tgRJ4sxz3n2EevuiwGDAejIyuWVV91BgoM9vf5l86Pol2CAakoKKmU+dIsPocOrDFd4+MZ5Xrh0+mhoyaJMXfAoa2d6Jdv+qfcmqc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <732ee2f6-0091-45d3-bf98-e8f21b70ca0d@citrix.com>
Date: Mon, 17 Aug 2026 14:08:20 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger.pau@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>,
 Juergen Gross <jgross@suse.com>, Andrii Sultanov
 <andriy.sultanov@vates.tech>,
 Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH v3 2/6] ARM/sysctl: Expose the supported guest GIC modes
 in physinfo
To: "Orzel, Michal" <michal.orzel@amd.com>,
 Julian Vetter <julian.vetter@vates.tech>, xen-devel@lists.xenproject.org
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e427000edb5@vates.tech>
 <ee383990-f688-4244-b817-5df4c2f8decc@amd.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <ee383990-f688-4244-b817-5df4c2f8decc@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P302CA0011.GBRP302.PROD.OUTLOOK.COM
 (2603:10a6:600:2c2::7) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SN4PR03MB989380:EE_
X-MS-Office365-Filtering-Correlation-Id: 5a7a3d9b-4445-4c90-fbef-08defc609f83
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|18002099003|22082099003|56012099006|6133799003|11063799006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	r8ZNBbEpchyJMIK1triFW5KRe+F2fnzXKaP+rT84OFbpFl5JPYPb9l/bLwtB9ZlIrcurFumiCme42FHT0v5/q+E5Tg+5YBXqNeuKBp7C4jZLPSCOQDQt6Ndrqs6z3kYH/vFHvhETkGU8cKpUv2FqFHSduNdIbT9fMt33pqqKmdSAZzPOYfpR5Cjcp/qgLU6sPuxIo6br25R2TVv0P28w1SKYaZvmrA6nRRTPgaXRaSsY+ZuzK6ms5iahEkASFCDXKMYPzWChzFwUQKpEKPY+gWbYxSePq167DFA9QHyY9+ynxf23+NvWs9DKF27gy+YtgSDGcecMxiI4uwEJwYCU2v8POZZmXjZxoFEEJxHFp3T+eM4RpGc/+wvsTuo+88QSIjFQgI0N1KUZLAHpK62DOGYF9hVTs7OYUM87gfGfLZ8JMivfmMTbZivnECHxIDjQQa9SJXMERzj2U30gexs6ClbWJ8A1DjufERH67hBYAOue+d5mHFq7Oit9XrU0yqRAg3L+XaAxtT3tc8CCJ1bcgDyquh+Zt6km4SUp1LT7gVjHvdVgB6UmpZ8WdOoDe+dtOytDHcp8eJofkANhmDEEMestvSQL91JNun6Ll2/8IPLwZjnwQwZksAnyigwg6rvndp5Yc3htmfvnOMXNIEAKk3bICF8yVWrNjzL64FpBz+4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(18002099003)(22082099003)(56012099006)(6133799003)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NDg1QWc1L2hadHViaWZOWFAxMXlnNFBCczlnYnJzbHEwMllRUzBZZ2tPSEpF?=
 =?utf-8?B?ckhsSnBkNWpYNGpVT21udmEwdmpZZTZ2dWhKTzhvNVQ1c2VFSHlUUlBUaHhn?=
 =?utf-8?B?TkJuTllhbjFWdGJMZVhBT3lwcXV4dmhMQ0VvSkgvQ29HWm5NY2tvZUxHVy9O?=
 =?utf-8?B?R3JFY3FoU1VnNGpOcDdJTHVrbDhuaWJJU0pCMVQvcWZYaGZYSGxoYVVzKzk5?=
 =?utf-8?B?TVFBbHkzLy9nOFBYbHJOUThtbklJU0NLNm9aNlhkcnpXWWNabHp1ajQ0S2FR?=
 =?utf-8?B?SnY3SHNYdHhxZXJIblhpcm9vT3BJUlQ2Nk9ORmRnV2VsK0lTL0lBeGt4RFBY?=
 =?utf-8?B?TjZSdEtodUdUeHdmbHRXUE1zc0d1d0w5YnJJVnljRmNTbmpNajBJYnlQR3BB?=
 =?utf-8?B?eFQwVTllSDZpZVgxOUlSbmpEa1I1RGc4bURORW1XQ3ZnU3hQZThOVndXWXhS?=
 =?utf-8?B?bVdBNitheHh3dkpuTlc0cklTbnp6bHRhL0Z1ZURHTVFCNTUwOGZreDgzSjBT?=
 =?utf-8?B?WGU3MW8xclowR3BDMXhVKzZCZEgzRmRHNjhIdW4reWMzcktMZDU5L0g3d2NH?=
 =?utf-8?B?SU5iQ3J1bjhMdGJxMnZqS2p5Q0R3Ukw4MlRvakNEa1FyS1d5bXQxSlNTTVZB?=
 =?utf-8?B?WlRsR2JaS0pTVUdmeWNJU3F4YjJvelhaVm5WUmQ5QVFZYS9pWTdLbk1KRnd1?=
 =?utf-8?B?UzRwTUV6VzBadm5tYXBhVDdLdWZoeVdMNW1BUlBaTUxDTHp3cWIvdkF0MHZu?=
 =?utf-8?B?WThFVXYyN2VRTkRWNmtUV2dQc3ZYa0ZOWFlDbGRtTVBFWHlSOGtYUVZiUTZv?=
 =?utf-8?B?SVlEWkZaeHlIa0hUTEs1em9OZ3JwWnRsL3FtaUZTVWJvZmxPb2ZXWEg0MjZn?=
 =?utf-8?B?WC80RnBjYU82T0YrcVlmS3JaWWhVZWlzQThyelpEWGR4SjBLUEw2bWV4ekxh?=
 =?utf-8?B?SFc0c0ZiYmNBNE9RTFR3eWRCdEtzNTFmUis2OWh5MFNlTmlRRUM4a0F5bkdI?=
 =?utf-8?B?SlVmbk4wWU8xVkxiVGFNVFQzbjRiNkhjdGd0U1VZZkRPbDROblp5SnViZmxq?=
 =?utf-8?B?MWd0YjNCdFowS1ZERHBjeTFmcGpMakJTSmRnQkhQaHdWQkNobVkyeHJhYUI4?=
 =?utf-8?B?eU5pblJlWnpjeGVnYzFSNkpNbmVIcVliaVFiM1VOSXBLcVI4ME1IRGZTYURY?=
 =?utf-8?B?YjJPbytRa0ZaUmZ3anF0QnVVd2JoSVlFdHFlYXU2RDJIQVRNWVp2YTY2Ymh1?=
 =?utf-8?B?NTFJc3NYTGVGaTNWZThtYzh2ZkZYNjJaR2ZlN0dEczM4cVo5R1FhZnBMaVVp?=
 =?utf-8?B?VUsxQTNWSnlHZzVVVzZ0Ti9TcDhnTm90dk90Y0NkKzhmTUhsYWdnYUpYN1Bl?=
 =?utf-8?B?L2FnRmJ1V2NpVmJjRXIralBvRWoycjBpRVZ4Y2k5ZXJPOWU1bFkyMXlRK1dz?=
 =?utf-8?B?eWFqeGxXRzZNNVEzaXF3MlRzR2IxMzNZSkx4bU5jQ0xOL0JodjdOZENHZndD?=
 =?utf-8?B?UGsrR0dzWlZWRDZlUE5yUmUvRVlmS3RMWUhObzFjaDFpVjU1eitVUHRLSFhj?=
 =?utf-8?B?azYxN051TWNhTHJjWGwrSEdUZGFsREZ1clAyNk5OMVlnSHM0WXVRUFFLaXRG?=
 =?utf-8?B?TUxpTWNYbDVBbmViT1p5eUNwRjBGVWY1SkJ5dWN3eVViS1VxYTcwalNscFoy?=
 =?utf-8?B?TnVSTVFRTEFScUR3WnZKeXlyZFRGa3ZaaEtoeVh1dlJJdXdGd2N2QXN5b3gz?=
 =?utf-8?B?anFiUmVqNlhXSlJ0WUQ1N3Fkc2xvK1VjTkdxQnFieTRZTFBLRyt3MDdIM1Fi?=
 =?utf-8?B?UTFlMTRUczBVdnFtQm5oZ0h1VVlvTkJqbHQ4N2dIYkthMGQrTXQwWEFMblVt?=
 =?utf-8?B?b2NNRnlrUnVuaWVRRHV2VUZZMFBFQjRuL0U1anJJTjBTbXM1TzFsM3VDS0Nw?=
 =?utf-8?B?ODRRcnpPTllDSXRXUlhGUFdBWWQ1ZS9OUkR6U2xic2dEbGhNNkRmOThnang0?=
 =?utf-8?B?aWxYenJoVk9NTjIyL1ZoM2poSTh1aEh5WVhPV3k3WHhwVHJ0ejBoUnhPTStE?=
 =?utf-8?B?ZEJzQW02L3NralNTWWtDZkFZQTFDc0dBZ05uUExKVFBpU3hXeTAwYit6dWc3?=
 =?utf-8?B?dkhsNkoyWTdtbHg4NnR4YUlqMDNlQm80RUxNUUdGN2gwUnRZejdQbndZOE52?=
 =?utf-8?B?VkpnZE9BV2tOSHMvdHE5WXZMN2pKWTdYZ3IzbGxiSk9EWElrRS9FK3N3anlC?=
 =?utf-8?B?Q1MxQ3ptSXVJZFFIQ2o2VVVMSiswUHJnck5SZGo4Y1FWdnBLM2RLUVFJbkdm?=
 =?utf-8?B?bDFFU3kwZy9IUFJCZ1lPbE9SNW1mcnlaR3E1SXJMbml3VFhBMWVUQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a7a3d9b-4445-4c90-fbef-08defc609f83
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 13:08:25.8316
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: p2JxvSrj/7hpeA9yQk97sHq0wqvEU6EM/msaDc9c0bOXT5fSNZV2gDsGi1tG70zbV+kb4d2WguwNN5dYalom5VtOszPSZBTnjc7iOG+ouBo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR03MB989380
X-purgate-ID: tlsNG-4011c0/1786972113-514C7CFC-1746F484/0/0
X-purgate-type: clean
X-purgate-size: 1717

On 17/08/2026 1:39 pm, Orzel, Michal wrote:
> On 16-Jul-26 16:11, Julian Vetter wrote:
>> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
>> index 32cab4feff..3b0edf4cec 100644
>> --- a/xen/arch/arm/sysctl.c
>> +++ b/xen/arch/arm/sysctl.c
>> @@ -21,6 +24,29 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>>  
>>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>> +
>> +    /*
>> +     * The GIC version(s) we're happy creating guests with.  Right now for
>> +     * simplicity it is tied to the active hardware version, but this will
>> +     * cease to be the case if/when the compatbility modes are enabled.
> s/compatbility/compatibility/
>
> GICv3 may support GICv2 and we support libxl guest requesting GICv2 on a GICv3
> host. Why are we not exposing this information here?

Hmm.  That wasn't my reading of the logic at the time I wrote this.

Looking at it again, we probably should be advertising the result of
vgic_v2_hw.enabled alongside the main GIC version.  (Plus whatever
ifdefary is required to make this build.)


The domain create side is even more wonky. 
arch_sanitise_domain_config() takes the toolstack choice of vGIC
versions and asks whether the number of CPUs is compatible, but it's
midway through arch_domain_create() which first notices if the requested
vGIC version isn't compatible with hardware.

There really wants to be an __ro_after_init supported_vgic_versions
(name subject to improvement) which is filled in by the various GIC
initialisation routines, rather than a set of backbacks into disjoint
drivers.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 14:01:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 14:01:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393029.1631931 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvxtu-0006Nt-B4; Mon, 17 Aug 2026 14:01:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393029.1631931; Mon, 17 Aug 2026 14:01:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvxtu-0006Nm-84; Mon, 17 Aug 2026 14:01:18 +0000
Received: by outflank-mailman (input) for mailman id 1393029;
 Mon, 17 Aug 2026 14:01:16 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wvxts-0006Ng-9V
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:01:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvxtr-006Bk0-5S
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:01:15 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a831429-bab6-0a2a0a5309dd-0a2a4509acb2-10
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 16:01:15 +0200
Received: from [209.85.128.182] (helo=mail-yw1-f182.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a83142a-be1a-0a2a45090019-d15580b6b0dc-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 16:01:14 +0200
Received: by mail-yw1-f182.google.com with SMTP id
 00721157ae682-81e6f0b4610so34893427b3.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 07:01:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1786975273; cv=none;
        d=google.com; s=arc-20260327;
        b=L13CqX1/vjfMbCpzbNco1joDiVgOreL1izUBbnrZKmPmHRnNtnnL+kgpOrx+s2vlQr
         Y0KxBRYDdKLO8yHfM2/vAFfOasO+3DAu4spaL6dKc+psDlITUe1eD4ghxVCQUtXRfo2r
         ukCTd3oCLOgnkrcC25N4gXAxChgnlw9L1LvMVsxYO0DSBwBoO0cn9RdCalscWAIuTby2
         P5Quq/7aMaCg6b32v4v5waDSHd/d5hE9nTwjhpFcAeTV/kdwk5BpR8Aw4SsE2mDtphFf
         geh9SL0R/GnR40MnbRJ3hXLoGT+WeR/YiFZu89IatRBjARCanGL3GM/qBbwJWjQU+UTP
         HZBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=L8HykWJpsrqIcHbdJMVChSi6jRdfa7iHZ0zT1YCTlM8=;
        fh=9nAqNi8urBxrfozKAqk+9srfdEwt95QqXLH0w/zVALY=;
        b=KGKLrAylGwTieCYycLckelSvsNo9xH4bm/oBzlydSb2Qi8y0Rq3oQubqGL+GvO6q4m
         ZSRUCV6bJ0hEcXkaPgswzasO4FqYv7yf7l61mkEoSofzlCVjx/ph6ycEdZ8k2d/prPgz
         2LLwr8KFBkQLQCY/q0m8sQKOWYK80lFVEvFpHiqFWRzf2QavYHuCMF44hPlMzpT5kSjk
         7Zid3VYjdGV0sLQsHxwiRNfAoOWS1BDL//14uMnaGjnzkVyt2WFU0hqa3gX+BMeKgyjC
         uEL2eJW0wN5PfD1nWuh2V71L4oLiklSQ3MRFxxOzQRH0xPBkGPheX0wMQ9iAxFp8gJzP
         R9YQ==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786975273; x=1787580073; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=L8HykWJpsrqIcHbdJMVChSi6jRdfa7iHZ0zT1YCTlM8=;
        b=pScw4foNnxeR5WFhvtYVfGtX2qLwbPrAItTKy2N+VpOJNy1E9GrOp9t9fT7tK3t5ev
         fMTL64afhDi5vHQ5oFBdSB0GfkRxujFAONbcBPXTvU/4RultY8id95CqhR6LZw6nChKB
         fP9jS0f70sXl9UxHf2hqoCMO3drsBgc3R4x7DeiPdohb7k80pimZTwlCcS1Op6PlUAv8
         ZrF/P8cuiS4Z8GFjfCATa/owAOvmSoKYtA+w62tqO/zlsOAU9LU08wk+uSaOZYQIVmmS
         5pOz+vkDrTyhhZ1sjT5gSNWehHyhNqQkqgTir0J4kFW5DZtfKWnIInZonZI/uhEj5VZb
         tBzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786975273; x=1787580073;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=L8HykWJpsrqIcHbdJMVChSi6jRdfa7iHZ0zT1YCTlM8=;
        b=EG2UQ/xUHlsWUBNzEdkF35Y65vZ9LkQuHT6V8ZSfu6uTS7aXUvzRMeS5M0371tj7Dp
         LndCMAFmgFNWF/4dw2sfZH70udqZWsoaF6ZnCvDn9qGd+twO56hgdRJlMksQOwXjfoJu
         1xDaM8vH8qHWfPMjStSpDtHmKe2FjuUCYL7iPRmSi0MeDP9Jl4hGq2R59BPwGjSE9ECz
         GO1VhflMjeSCwMiyE7RroR3FXrD36Y0VzsrB/rpLTysS96S6Te/v1SQByc8Zfo19ffmk
         LTDFsmqNjpRhYEJSNJaeGuydnnpykL9KHMv2EoqhbEGPcuxjc4lIUcTI4D3NNoh2OPJr
         vjJg==
X-Forwarded-Encrypted: i=1; AHgh+RrNOVQ9i0TnOGPSxZZ41RQH6ws+AH9yQUKwk6iNGHl9sV3WJTOZa/1mfqbafPq7HngkcD4QortFWLE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQBvDu1KdwaoH35Z6RA7qn/MB5tMija0g56NIHQBAb0XCJPmrf
	akAcn2ZBEaDdEcuPy0PZT3CENHgDnGyB54sJ4975Bq07dCWCSWaTf6joJej1zz6/5NDN6kXBtW9
	yMLBVIBTizECjmQECA+p6MVR1zKbvKbp7Zecx6jg=
X-Gm-Gg: AR+sD12EQ9lJ+PtlaS4EuijQDcUWIyd/k4nJelsgOLczxYUnccae2q/wgGnSsKZA5Ra
	mfOhBtrnYW0YfIi+EQskAnQS6WRWP4NMuQytDlxyjBtYlwBvQv3u1dhDNIv5wTnYAAkAST4U8+f
	/k9pZQTqtTPxo9bZwaFkL5Uls3Mm7zuF9bzIwgBvT4FbB/QkiEb1wohg9oiqT/pfoG0CIsfiPjW
	BOX0Omkf/mHOfcVcmM88rqE2PhPzqsAeQSlSy5a9QztIGDe93UBVNoFyKWgHv6zL4UFb8zq/Flt
	kNaskYOFWWBcvHLxe5vDz6/Bzwik6R7yDPpRRTLFC2ScZf3kHF7JKPq0p6EO9hBYPrlmo41dSaA
	xgED3yLBLEpE=
X-Received: by 2002:a05:690c:e3ea:b0:820:a7c:7495 with SMTP id
 00721157ae682-8412cd49584mr3820827b3.3.1786975270637; Mon, 17 Aug 2026
 07:01:10 -0700 (PDT)
MIME-Version: 1.0
References: <20260810103018.54564-1-frediano.ziglio@citrix.com>
 <20260810103018.54564-8-frediano.ziglio@citrix.com> <43d1ce4a-3a49-42c9-b277-47a89698513f@suse.com>
 <CAHt6W4enamC9rVMK98+q=pWCuXQL1DPgNTCGWMVR-Q2NvX8uTw@mail.gmail.com>
 <b10dbef6-a467-49d0-858e-d88f268e2dfd@suse.com> <CAHt6W4dWQvSg1_XtkKowTcznUWs=-ApbvatV4YrQSKR8zJTA0A@mail.gmail.com>
 <e3d4f0a8-e95a-4dc3-8ca0-df857725d60d@suse.com> <CAHt6W4ftLMsk41zdwYUXEwN_JzzXHQG01vhSqutkgk8PO6xAQw@mail.gmail.com>
 <e697b132-8c6a-411b-b91d-2fedba02a9ae@suse.com>
In-Reply-To: <e697b132-8c6a-411b-b91d-2fedba02a9ae@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Mon, 17 Aug 2026 15:00:59 +0100
X-Gm-Features: AcwNN1UmMg5O30ftsHfwarH9HZoBcZITt0ns_skJIZ3FY2qtP-8Pnutv3ilTMyE
Message-ID: <CAHt6W4dUe6ozg==rzBcY0zTciXVd0k3sotsTvsHkQrWM1ALWvQ@mail.gmail.com>
Subject: Re: [PATCH v10 7/10] xen: implement new foreign copy hypercall
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P . Smith" <dpsmith@apertussolutions.com>, 
	Frediano Ziglio <frediano.ziglio@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-bad1c0/1786975275-BD2CC034-B8EA972B/0/0
X-purgate-type: clean
X-purgate-size: 3407

On Mon, 17 Aug 2026 at 09:04, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.08.2026 16:50, Frediano Ziglio wrote:
> > On Fri, 14 Aug 2026 at 15:13, Jan Beulich <jbeulich@suse.com> wrote:
> >> On 14.08.2026 15:47, Frediano Ziglio wrote:
> >>> On Thu, 13 Aug 2026 at 15:22, Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 13.08.2026 16:03, Frediano Ziglio wrote:
> >>>>> On Thu, 13 Aug 2026 at 10:41, Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>> On 10.08.2026 12:30, Frediano Ziglio wrote:
> >>>>>>> --- a/xen/common/memory.c
> >>>>>>> +++ b/xen/common/memory.c
> >>>>>>> @@ -1548,6 +1548,141 @@ static int acquire_resource(
> >>>>>>>      return rc;
> >>>>>>>  }
> >>>>>>>
> >>>>>>> +/*
> >>>>>>> + * The "noinline" qualifier avoids the compiler to create a large function
> >>>>>>> + * consuming quite a lot of stack.
> >>>>>>> + */
> >>>>>>> +static int noinline mem_foreigncopy(
> >>>>>>
> >>>>>> I'm wondering: Is the "mem" prefix really meaningful for a static function in
> >>>>>> a file named memory.c?
> >>>>>>
> >>>>>
> >>>>> Changed
> >>>>>
> >>>>>>> +    XEN_GUEST_HANDLE_PARAM(xen_foreigncopy_t) arg)
> >>>>>>> +{
> >>>>>>> +    struct domain *d, *const currd = current->domain;
> >>>>>>
> >>>>>> With the comment on the new XSM hooks (below) in mind: currd wants to be
> >>>>>> pointer-to-const.
> >>>>>>
> >>>>>
> >>>>> Just rebased on master, all XSM hooks accept no-const pointers to domains.
> >>>>> So the suggested change would create warnings.
> >>>>
> >>>> Well, as per below, I pointed you at a particular pending patch, a single
> >>>> hunk of which could be broken out.
> >>>
> >>> Yes, but my changes would have to have casts from const pointers to
> >>> no-const pointers to avoid warnings and the patch you are pointing to
> >>> would have to remove these casts. I find this less clean than having
> >>> one patch using the current code style (that is no-const pointers) and
> >>> another that changes the style entirely.
> >>> But obviously this is just my opinion.
> >>
> >> Such casts would be unacceptable. What instead I have been trying to convey:
> >> Your patch wants to gain a dependency on my patch. And if my patch would
> >> take too long to make it in, that one hunk could be broken out into a
> >> separate, easy to get in patch.
> >
> > Okay, then the only choice that's left is the code producing warnings
> > as const pointers are passed to functions requiring no-const pointers.
> > Is this acceptable? Apparently as you are suggesting it it is.
>
> That's not acceptable, the more that due to -Werror this would break the
> build. But that's also not what I said, and I'm having a hard time seeing
> how what I said can be mis-interpreted. What exactly is not clear in "Your
> patch wants to gain a dependency on my patch"?
>
> Btw, I'm about to submit v2 of that XSM series, where I've broken out that
> hunk (for the change to then hopefully go in quickly, allowing you to
> simply re-base rather than carrying a prereq patch).
>
> Jan

Okay, being dependent on
https://lists.xenproject.org/archives/html/xen-devel/2026-08/msg00768.html
would be acceptable.
What was not was being dependent on other large series.
That is more in line to what I proposed multiple times, that is having
a preparation patch for constification and code using const pointer on
my patch.

Frediano


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 14:08:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 14:08:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393036.1631941 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvy0g-00071i-1q; Mon, 17 Aug 2026 14:08:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393036.1631941; Mon, 17 Aug 2026 14:08:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvy0f-00071b-UR; Mon, 17 Aug 2026 14:08:17 +0000
Received: by outflank-mailman (input) for mailman id 1393036;
 Mon, 17 Aug 2026 14:08:17 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <3zBWDagYKCV8PB7KG9DLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--seanjc.bounces.google.com>)
 id 1wvy0f-00071V-AI
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:08:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvy0d-00HJwc-4d
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:08:15 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <3zBWDagYKCV8PB7KG9DLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--seanjc.bounces.google.com>)
 id 6a8315cf-8faa-0a2a0a5109dd-0a2a450b8562-0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 16:08:15 +0200
Received: from [209.85.215.198] (helo=mail-pg1-f198.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <3zBWDagYKCV8PB7KG9DLLDIB.9LJUBK-ABSBIIFPQP.UBKMOLGB9Q.LOD@flex--seanjc.bounces.google.com>)
 id 6a8315cd-b7e8-0a2a450b0019-d155d7c6ed57-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 16:08:14 +0200
Received: by mail-pg1-f198.google.com with SMTP id
 41be03b00d2f7-cbef1d25500so3633759a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 07:08:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1786975693; x=1787580493; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=K+H/tJA5lC7k+sRi7jSoRnwTUnMixNT0suJnv/pAfq4=;
        b=iPMx71jhH1nU/w+KcwU6+8eXzO2/L7L3kx1bJNrZd52+FAibsIIlDK2vLlwecqN08Y
         sQyx7ot/5dSxUZMtWG9QjpQ+fQVupC7ClPV7WHKaudKh7JuvaR8NmZ2pyriN7CMV2RgQ
         9P0A3AI1oNZPtGjbVXBuVkJoXZbYYDN+1Pil/Ii5akjAFl8LPmOPcDLagtiwMcW2PKQi
         X18T61FOxwzXG5MZbukYdE6K06TMOarkhQBBHrXYjDEZKgPHH6qk9D5ZowUjal9UMk5a
         rJigCu14ykyPjIIcHM95eZgsg52Qakx5321tBfX8fI0LjhkfIYXIUmT0BMPH3PGt+Cqr
         FVAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786975693; x=1787580493;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=K+H/tJA5lC7k+sRi7jSoRnwTUnMixNT0suJnv/pAfq4=;
        b=K0nIOfHRXRWLwDsmFD8/aEUNLSkvtYzSrKHwpFtfcqXWDZx6H1aCD0ebYtsIn3BKym
         KXrziNs3I7b2MJ7gcieH4l5DJRQ1YQIrTrFJwabmWREcRi7OatmmgblBxAH+1ZkMqQjl
         WdE9oqmf8SG03J/B4V7LbrEs9JimxxqAF2Qy7d4r/9jqdCPOgcDtcx+v6HO+7yyWJPHP
         J1CyMjfsJ1Vs3z+qc7E+ABb1vls0PQClBX/xAN1qskgSL0nfGxDlwjmeqyqJ+GLsSZ7j
         xgDoX1UISomEsampy1FzF9G7vFtDX6yt+vnEcf13M/T1NUv3roa+FYkUHj1CZDeRc//8
         /FDA==
X-Forwarded-Encrypted: i=1; AHgh+Rro+szerAKrBIFwLl7VAeuucTGOc9xoB09aShGlA/a0YmApNPj86baqLq3ll54D/eJl9JlQT7PEWYw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxm255XA/5fFX9WZH7mSamVslfUVqAMViTR0mp3eVeGF2SOTK4L
	B10TSyB5ioHvaLav5LnOTAdmAnwiJXOsi51B6aOzshcuxCwIy55wHzk/6s1MFL1EJu2R17yG2q8
	btp9zFA==
X-Received: from pgcz4.prod.google.com ([2002:a63:7e04:0:b0:c92:29d5:1f29])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:12d2:b0:3c3:9746:1fcb
 with SMTP id adf61e73a8af0-3cc71dc524bmr27787783637.35.1786975692489; Mon, 17
 Aug 2026 07:08:12 -0700 (PDT)
Date: Mon, 17 Aug 2026 07:08:11 -0700
In-Reply-To: <ef3b56bf-8df0-4a40-82c7-bd2d65eec71e@yandex-team.ru>
Mime-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com> <20260806233609.212337-22-seanjc@google.com>
 <ef3b56bf-8df0-4a40-82c7-bd2d65eec71e@yandex-team.ru>
Message-ID: <aoMVy4VB1sq4T-ys@google.com>
Subject: Re: [PATCH v6 21/51] x86/kvm: Obtain TSC frequency from PV CPUID if present
From: Sean Christopherson <seanjc@google.com>
To: Maksim Davydov <davydov-max@yandex-team.ru>
Cc: Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, "K. Y. Srinivasan" <kys@microsoft.com>, 
	Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-42698a/1786975695-2C59A9EA-EF93815E/0/0
X-purgate-type: clean
X-purgate-size: 3137

On Mon, Aug 17, 2026, Maksim Davydov wrote:
> On 8/7/26 02:35, Sean Christopherson wrote:
> > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> > index 29ca37e9a3bc..f55d0305d1f3 100644
> > --- a/arch/x86/kernel/kvmclock.c
> > +++ b/arch/x86/kernel/kvmclock.c
> > @@ -342,8 +342,10 @@ void __init kvmclock_init(void)
> >  	flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
> >  	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
> >  
> > -	x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
> > -	x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
> > +	if (!x86_init.hyper.get_tsc_khz)
> > +		x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
> > +	if (!x86_init.hyper.get_cpu_khz)
> > +		x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
> >  	x86_platform.get_wallclock = kvm_get_wallclock;
> >  	x86_platform.set_wallclock = kvm_set_wallclock;
> >  #ifdef CONFIG_X86_LOCAL_APIC
> 
> 
> I cannot test this right now as I lack two servers with different CPU
> base frequencies, but it seems that this patch might break something in
> guests:
> After migrating a VM (QEMU + KVM) from a host with one base frequency to
> another host with a different base frequency, the value in CPUID leaf
> 0x40000010 EAX changes and becomes the same as the destination host base
> frequency instead of remaining the source base frequency.

That's a bug in whatever is orchestrating the migration, and/or QEMU if QEMU is
handing the upper layers a loaded footgun.

> The main reason for this behaviour is that setting the TSC frequency via
> ioctl(KVM_SET_TSC_KHZ) doesn't change the value in CPUID leaf 0x40000010
> EAX and these two entities are still not connected.

And they never will be.  It's userspace's responsibility to fill the correct
values for 0x40000010.

But AFAICT, QEMU does the right thing.  env->tsc_khz is used for both the CPUID
leaf and for KVM_SET_TSC_KHZ.

kvm_arch_init_vcpu():

        c = &cpuid_data.entries[cpuid_i++];
        c->function = KVM_CPUID_SIGNATURE | 0x10;
        c->eax = env->tsc_khz;
        c->ebx = env->apic_bus_freq / 1000; /* Hz to KHz */
        c->ecx = c->edx = 0;

kvm_arch_set_tsc_khz():

    r = set_ioctl ?
        kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz) :
        -ENOTSUP;

> I saw this behaviour with QEMU 7, but I've checked the code of the
> latest version and it seems that the described behaviour still exists.
> So, in that case, it's possible that with these changes a VM will use
> the wrong TSC frequency from CPUID leaf 0x40000010 EAX if it's migrated
> and then rebooted.
> 
> Putting it all together, after the previous patch ("KVM: x86: Officially
> define CPUID 0x40000010 as PV Timing Info (TSC and Bus)") a new way to
> show the guest that CPUID leaf 0x40000010 is valid should be implemented
> and only then this leaf can be used to get the TSC frequency.

No, there are already non-Linux kernels that consume 0x40000010, e.g. FreeBSD.
In my very strong opinion, if this problematic for a deployment, then that
deployment needs to urgently fix their broken setup.


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 14:37:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 14:37:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393046.1631949 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvySf-0002lq-84; Mon, 17 Aug 2026 14:37:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393046.1631949; Mon, 17 Aug 2026 14:37:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvySf-0002lj-52; Mon, 17 Aug 2026 14:37:13 +0000
Received: by outflank-mailman (input) for mailman id 1393046;
 Mon, 17 Aug 2026 14:37:12 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wvySe-0002ld-7i
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 14:37:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvySc-008sg9-F2
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:37:10 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a831c76-bab6-0a2a0a5309dd-0a2a4506d440-48
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 16:37:09 +0200
Received: from [52.101.62.64]
 (helo=DM5PR21CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a831c94-195a-0a2a45060019-34653e40437a-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 16:37:09 +0200
Received: from CH0PR03CA0367.namprd03.prod.outlook.com (2603:10b6:610:119::24)
 by CH2PR12MB9459.namprd12.prod.outlook.com (2603:10b6:610:27d::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.16; Mon, 17 Aug
 2026 14:37:00 +0000
Received: from DS2PEPF000061C2.namprd02.prod.outlook.com
 (2603:10b6:610:119:cafe::36) by CH0PR03CA0367.outlook.office365.com
 (2603:10b6:610:119::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Mon,
 17 Aug 2026 14:37:00 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 DS2PEPF000061C2.mail.protection.outlook.com (10.167.23.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Mon, 17 Aug 2026 14:37:00 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 17 Aug
 2026 09:37:00 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 17 Aug 2026 09:36:56 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tDHxkP/w+AyrmXX2AOBdAaSox41Yc893yH2OCzjyvlf9el+QdeMHAYNCZx83+20zJJNpZSg2Wi//bwtp6+KX4O63NZYJ84efa4I/m4q8yM8hCnZtTBWJH2/uqBMCGgGx01ZoGXQ6NhSydZDqlXOMgpZaVva7T+wHHEYsDJHRcPEfPwOym9dKrVf5qN5DR0HAWNrd73gTug2PZ7K4MiANDR/AveCDSpy2uJ711Fh2B2598hrmpLq3C7C1vD21CgfcFudzCUlx4Lq7l8nf3YJfHFTI0p1jH1HVJSaqYpk+OX4KxwteWCUfkdhl/lmbg6AepxJw5+QzZzBuybET1z+ZGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NV2lAk3hJ3iJJZP8403qZOXtIotAkZzFnoFFkwdRvRY=;
 b=tQBDELk22V0u6hS4paVsU+/8lI1suVyfqIyb6OxeOV9y6vYgoaQfgVpesnTIHqx9pc/ikMD4ipJ7yG9dKTGXoKH5JPVLGwDsl5RbkZl1cF1RgdYjVZfghJqolaNN2roFvLXJR8BX/aimLqA05UAgr9/S99HYOoMQhgQla7Fv2VTAt2LuvjLMKYT10kfUxJeLv/Hlo9SdIHXo9k1OWzelczfm1C65q/S4Vh54yHawLecpm2sbiruj55sxqhL/sgan0aHdheEs3MoBoIk+4Xw3XUlag5vJ1yidPAH18uO2OrulhLDqxt2Tn6P6eARvj8YSYC+BMxGDXW6x/3F7OpeBkw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NV2lAk3hJ3iJJZP8403qZOXtIotAkZzFnoFFkwdRvRY=;
 b=R0rTYGIkR5q/QIioyWR3QOsyZ1iEioYw8XOAgObwHSaEMd/u0LRUuYvptSaRVrUgUZV5GPdjBLp5BiK8UrdrCSFGtdeacsPUMU2oStfODPeJrs9fTQYdFOLd1WVlKu4xvSX4+a7LcbQOpZGiisog/06hpTykcq10Kx5quoXq0Zk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <1e53ea73-0f9e-48ca-978c-d22fb04c4d45@amd.com>
Date: Mon, 17 Aug 2026 16:36:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/6] ARM/sysctl: Expose the supported guest GIC modes
 in physinfo
To: Andrew Cooper <andrew.cooper3@citrix.com>, Julian Vetter
	<julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich
	<jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>, Andrii Sultanov
	<andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, Oleksii
 Kurochko <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <1784210820.8631fc262581453bbf619ec5b2062170.19f6b408bba000edb5@vates.tech>
 <20260716141138.88265-1-julian.vetter@vates.tech>
 <1784211104.8631fc262581453bbf619ec5b2062170.19f6b44e427000edb5@vates.tech>
 <ee383990-f688-4244-b817-5df4c2f8decc@amd.com>
 <732ee2f6-0091-45d3-bf98-e8f21b70ca0d@citrix.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <732ee2f6-0091-45d3-bf98-e8f21b70ca0d@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF000061C2:EE_|CH2PR12MB9459:EE_
X-MS-Office365-Filtering-Correlation-Id: 5ecc2694-eeaf-4c03-3200-08defc6cff72
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700016|23010399003|1800799024|7416014|376014|6133799003|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	DPmMVHgP6ZY9h7+/TvQyXXoNe561MYqx0zYohWBurWIo1DdtxQ40iXqx+aVUKf33kGQWdDC1egu3AMYVJDDJaRbB++1mx42iZ0v8fGiBIbGUBKIsMLV85WsICHPGoTxqYZ7EkTDtAidKt6sGh+eBx15XpyBlFXTcsD3fKxep5aDiYZprhmY5baHNgcgqV5FwdhGZcuASrQW1Df5tJh450DRHQ22uvBptUoT+TPGtYbOHh8SE1wv+fPJGZa4YtgSBuSiH+3WAZLatHn0QagdkOWeyPyy/BRnxIFmbhYv56pOiIoZylbchSj6w8MnJrtZpGOHYqE+biBR2kOcpPR0fYlANhG1eRKxWPEC8fy7JcDLqbOsZnIZDg7GZhOL4T5zqaq2VTzOyfFZTZrJlEyKJXpWmb3IH/LTeJXg8Jl4d1jnpqPMaEBonc60Tm/vq42eW5LftK/L3wSys5HMZlIiqEJ3nUQjvZ/lnsdf92UkZaljz7RrzVxowwynElNfVm0aBrntKjK5rSC2pkQVi2ViHoHfmGFi1uIVKbfEWA77mFu+jAn6ueYBha4P8KTIHf6W4uvefagJLgUiE4BQocnts9lqGneWrnTfdtI0BlIf0r8fZ/7kbD9dI39UlRApAvxk9rNLcduqeQcDdTC9xFsUHMprM/EogTN1jypv5HVl264vjGSilLdd3p+96dtHS5HdICJCxfiVNUY8NtMZteyFPKw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(23010399003)(1800799024)(7416014)(376014)(6133799003)(10067099003)(56012099006)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	G25AiOwmshJhW4lU2KrnVEXOwGNU+NfaGZEA4ek/oGgDfNLEd+1JcDriBhF0OaDsu9qDG+8LVw/+dHmHjdR7QZocNiApzBjpkNL5m935UDmQkvi1ZpC49AhzNEqsWkz75O5yyLd32Ywqou+Es6VdeOI2nxAKprx71kj0cmrbLtdH0gLWdbWe5dlg9t4M8TWXV2tV/LJ6neXrWIEReVN4FY0b6boNBeqI0gUf34tEhJMzwySMYrXUdFTQ44+XXzsDQHsRy8q2R4YygP3RuHX9hMfRhQjZ9mnoC3VDv2jTtfBNmP7zsFqJvjQ4Db4sSRR3SQgAcKcg2x7O/ZgJ72HPymD9wiphjNAw+ZNcNzedRsRdgWZPYM8AxsUFEeD3k+4nWjgWvQPqCDNg+Ne4b7JVIfAPAU0lc2ikk20QjNaIkf0cCHSFkx0eJ1300n6rBIzp
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 14:37:00.4732
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ecc2694-eeaf-4c03-3200-08defc6cff72
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF000061C2.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9459
X-purgate-ID: tlsNG-16d1c6/1786977429-F4A0477B-71B31ABA/0/0
X-purgate-type: clean
X-purgate-size: 1844



On 17-Aug-26 15:08, Andrew Cooper wrote:
> On 17/08/2026 1:39 pm, Orzel, Michal wrote:
>> On 16-Jul-26 16:11, Julian Vetter wrote:
>>> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
>>> index 32cab4feff..3b0edf4cec 100644
>>> --- a/xen/arch/arm/sysctl.c
>>> +++ b/xen/arch/arm/sysctl.c
>>> @@ -21,6 +24,29 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>>>  
>>>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>>>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>>> +
>>> +    /*
>>> +     * The GIC version(s) we're happy creating guests with.  Right now for
>>> +     * simplicity it is tied to the active hardware version, but this will
>>> +     * cease to be the case if/when the compatbility modes are enabled.
>> s/compatbility/compatibility/
>>
>> GICv3 may support GICv2 and we support libxl guest requesting GICv2 on a GICv3
>> host. Why are we not exposing this information here?
> 
> Hmm.  That wasn't my reading of the logic at the time I wrote this.
> 
> Looking at it again, we probably should be advertising the result of
> vgic_v2_hw.enabled alongside the main GIC version.  (Plus whatever
> ifdefary is required to make this build.)
Yes.

~Michal

> 
> 
> The domain create side is even more wonky. 
> arch_sanitise_domain_config() takes the toolstack choice of vGIC
> versions and asks whether the number of CPUs is compatible, but it's
> midway through arch_domain_create() which first notices if the requested
> vGIC version isn't compatible with hardware.
> 
> There really wants to be an __ro_after_init supported_vgic_versions
> (name subject to improvement) which is filled in by the various GIC
> initialisation routines, rather than a set of backbacks into disjoint
> drivers.
> 
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 15:24:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 15:24:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393067.1631962 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzCF-0000zx-MR; Mon, 17 Aug 2026 15:24:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393067.1631962; Mon, 17 Aug 2026 15:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzCF-0000zq-IG; Mon, 17 Aug 2026 15:24:19 +0000
Received: by outflank-mailman (input) for mailman id 1393067;
 Mon, 17 Aug 2026 15:24:18 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01052c27d000c4f3@swg.vates.tech>)
 id 1wvzCD-0000zk-Lf
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 15:24:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvzCD-008zaL-2P
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:24:17 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01052c27d000c4f3@swg.vates.tech>)
 id 6a832790-8faa-0a2a0a5109dd-0a2a4507b772-22
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 17:24:16 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01052c27d000c4f3@swg.vates.tech>)
 id 6a8327a0-b4ea-0a2a45070019-b9ff1c239e15-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 17:24:16 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01052c27d000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 17 Aug 2026 15:24:14 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id A67F982AC1;
 Mon, 17 Aug 2026 17:24:13 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=iyqTLxcoIuoA4+nTrE3S4JUxsdOAaqzYNJRVcQ8jxik=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=rO/p2aKr5iY77v9vZ7oKMWS59Gu446IHEzS0K7IvxaaarNr7wsTXShXVIz5r8bcbvAAaIZuTg
 +SdlCDv85Rr1bV6N7nFqT3Vv//5aMro+AR7csopxfijOEkPwetNuugheSa7Lz9/BhMGZokOU9P8
 FErpSsXU3+O6OMFhuvHexHv3ICyGkL1Gjvix1wIItniUrHJjXgCrSi40SJXmkK7ByZSS5H9B4Bs
 MMsBUvKd7K58kBbl0/FfFNM1bl1gAUyG00ogdM6PAoz7e0HERBFdq/e7i/LBT4a30N+oH8XlEBp
 IAKNUefmI05GTQmYv+LjPKkzDd/OLyJ8MEzGoxXyfFPg==
X-Zone-Loop: 8aea3a39ae41bfed07e789345454f9576ff56d6f4821
x-campaign-type: default
x-transaction-id: 5b67da8b-c8b1-42b5-b1bf-08de250e2704
x-swg-uid: 01-7a2d0b22-da37-4573-8447-c27ca7094380
X-Mailer: Sweego
Message-ID:
 <1786980254.8631fc262581453bbf619ec5b2062170.1a01052c27d000c4f3@vates.tech>
x-swg-bid: 1786980254.8631fc262581453bbf619ec5b2062170.1a01052c27d000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH 6/6] CI: run the riscv64 smoke test via QTB framework
 console-test
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org, Doug Goldstein <cardoe@cardoe.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <1786378215.8631fc262581453bbf619ec5b2062170.19fec705e62000e099@vates.tech>
References: <20260810155543.927954-1-baptiste.le-duc@vates.tech>
 <1786378215.8631fc262581453bbf619ec5b2062170.19fec705e62000e099@vates.tech>
Date: Mon, 17 Aug 2026 17:24:08 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1786980253; l=5466;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=iiVmNSOS82JHHFiKvvn7jK2GS2U81E53XodF+7Mstfk=;
 b=Im9yeNErabqwmpR5ZhDe2y75BwleX2/kXwcC+7r/9p1UTGfQ4IYlF9GZ6YM+iAu+BhBROZ0I1
 6js18SWLgKhDvpuqwaiEXhVctsw6riUBQYlU54tiaBmHPv6OorfWyoW
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1786980253755
X-purgate-ID: tlsNG-ef75cf/1786980256-366DAAE4-8F5DFC8D/0/0
X-purgate-type: clean
X-purgate-size: 5470

On 2026-08-10 18:09 +0200, Baptiste Le Duc wrote:

During an internal review, Zheng Zhang (zhangzheng@iscas.ac.cn) pointed
out that this patch series defines the qemu-9.0.0 in riscv64-test-needs
of test.yaml, whereas we should use the QEMU bundled in the
13-qtb-riscv64 container.

I will fix this in v2 by resolving qemu-system-riscv64 from $PATH, since the
test runs inside the 13-qtb-riscv64 container.

As a consequence, the OpenSBI path in `binaries` in config.yaml is no longer
needed either: qemu-system-riscv64 uses the firmware bundled with it.

> qemu-smoke-riscv64-gcc drove QEMU through
> automation/scripts/qemu-smoke-riscv64.sh, an expect wrapper whose machine
> description (cpus, memory, device tree, console wiring) lived in the script
> itself. The QTB framework now owns all of that: machines come from the
> shared catalog, expectations from the test type's own YAML.
> 
> Turn .qemu-riscv64 into a template running qemu_smoke_riscv64.py <type> run
> <test> in the qtb-riscv64 container, machine and test picked per job
> through QTB_TEST_TYPE/QTB_TEST. The container comes from the test-artifacts
> registry, hence the new ARTIFACTS_REGISTRY next to the existing
> ARTIFACTS_REPO/ARTIFACTS_BRANCH. QTB_BINARIES_DIR points at the artifacts
> of the job in the new .riscv64-test-needs anchor (QEMU and its firmware),
> and QTB_LOG_DIR collects the per-console logs, kept on failure and on
> success.
> 
> Point qemu-smoke-riscv64-gcc at that template, running the console-test
> type on dom0less-1smp-0domu-1vcpu-aplic-imsic-null: a Xen-only machine, so
> the smoke check is Xen's own "All set up" on console 0, the same string the
> expect script waited for.
> 
> Drop automation/scripts/qemu-smoke-riscv64.sh as it has no caller left in
> the CI after this patch and drop smoke.serial from the .qemu-riscv64
> artifacts since no riscv64 job uses it anymore, the logs are now kept under
> QTB_LOG_DIR.
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> ---
>  .gitlab-ci.yml                           |  3 +++
>  automation/gitlab-ci/test.yaml           | 26 ++++++++++++++++++------
>  automation/scripts/qemu-smoke-riscv64.sh | 19 -----------------
>  3 files changed, 23 insertions(+), 25 deletions(-)
>  delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index f42a9abeaa..15f93b8634 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -11,6 +11,9 @@ variables:
>    ARTIFACTS_BRANCH:
>      description: "Branch in test-artifacts to use"
>      value: master
> +  ARTIFACTS_REGISTRY:
> +    description: "Registry holding the test-artifacts containers"
> +    value: registry.gitlab.com/xen-project/hardware/test-artifacts
>    LINUX_JOB_X86_64:
>      description: "Job name in test-artifacts to use for Linux x86_64"
>      value: linux-6.6.56-x86_64
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index 61adc1baff..4775d2cc4e 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -5,6 +5,11 @@
>    - if: $CI_JOB_NAME =~ $SELECTED_JOBS_ONLY
>      when: on_success
>  
> +.riscv64-test-needs: &riscv64-test-needs
> +  - project: $ARTIFACTS_REPO
> +    job: qemu-9.0.0-riscv64
> +    ref: $ARTIFACTS_BRANCH
> +
>  .arm64-test-needs: &arm64-test-needs
>    - project: $ARTIFACTS_REPO
>      job: $LINUX_JOB_ARM64
> @@ -72,14 +77,21 @@
>      TEST_TIMEOUT_OVERRIDE: 120
>  
>  .qemu-riscv64:
> +  image: ${ARTIFACTS_REGISTRY}/${CONTAINER}
>    extends: .test-jobs-common
>    variables:
> -    CONTAINER: debian:13-riscv64
> -    LOGFILE: qemu-smoke-riscv64.log
> +    CONTAINER: debian:13-qtb-riscv64
> +    QTB_LOG_DIR: qtb-logs
> +    QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries
> +  script:
> +    - ./automation/scripts/qemu_smoke_riscv64.py
> +      ${QTB_TEST_TYPE}
> +      run
> +      ${QTB_TEST}
> +      --log-dir ${QTB_LOG_DIR}
>    artifacts:
>      paths:
> -      - smoke.serial
> -      - '*.log'
> +      - ${QTB_LOG_DIR}
>      when: always
>    tags:
>      - x86_64
> @@ -779,9 +791,11 @@ qemu-xtf-argo-x86_64-gcc-debug:
>  
>  qemu-smoke-riscv64-gcc:
>    extends: .qemu-riscv64
> -  script:
> -    - ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE}
> +  variables:
> +    QTB_TEST_TYPE: console-test
> +    QTB_TEST: dom0less-1smp-0domu-1vcpu-aplic-imsic-null
>    needs:
> +    - *riscv64-test-needs
>      - debian-13-riscv64-gcc-debug
>  
>  qemu-smoke-ppc64le-powernv9-gcc:
> diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh
> deleted file mode 100755
> index c0b1082a08..0000000000
> --- a/automation/scripts/qemu-smoke-riscv64.sh
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -#!/bin/bash
> -
> -set -ex -o pipefail
> -
> -# Run the test
> -rm -f smoke.serial
> -
> -export TEST_CMD="qemu-system-riscv64 \
> -    -M virt,aia=aplic-imsic \
> -    -cpu rv64,svpbmt=on \
> -    -smp 1 \
> -    -nographic \
> -    -m 2g \
> -    -kernel binaries/xen"
> -
> -export TEST_LOG="smoke.serial"
> -export PASSED="All set up"
> -
> -./automation/scripts/console.exp |& sed 's/\r\+$//'
> 
> 
> -- 
> Baptiste Le Duc | Vates Hypervisor & Kernel Engineer
> 
> XCP-ng & Xen Orchestra - Vates solutions
> 
> web: https://vates.tech




From xen-devel-bounces@lists.xenproject.org Mon Aug 17 15:36:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 15:36:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393078.1631974 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzNx-0002lO-Oa; Mon, 17 Aug 2026 15:36:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393078.1631974; Mon, 17 Aug 2026 15:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzNx-0002lH-Kd; Mon, 17 Aug 2026 15:36:25 +0000
Received: by outflank-mailman (input) for mailman id 1393078;
 Mon, 17 Aug 2026 15:36:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvzNv-0002lA-H4
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 15:36:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvzNu-00HZGS-9z
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:36:22 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a832a74-bab6-0a2a0a5309dd-0a2a45028f1c-6
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 17:36:22 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a832a76-6ca4-0a2a45020019-d155dd2ed0aa-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 17:36:22 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-4799b3f7c83so2509214f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 08:36:22 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b896sm4829015f8f.16.2026.08.17.08.36.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 08:36:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786980982; x=1787585782; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=APmx+OQyjJW2Ssi7kcgtOEycsmzzm5MjhN44NhTcf0M=;
        b=UDnqy6Efwb6uI03Hv5ea+YPirTmP/wfcLC1Yh4N1hu8oLqSVXIYIOIy/XDH7KQREQa
         vP8SQrJ+HFQwXsH6Ehv4wNB3kjLcJmryAKmkwLVRrT+UdFqXi5P7i4/EsdACUxDWHDgK
         X7rF8WWRQaSyRVUPg2Iy1It/8fmGCKZnR9EkMjAcDZ69UYtGfYpY5rlTex1AwBTRtvmw
         TAm/y6kgN/33FvRJuCBEonvKrinGqNKhFLKEfC/v+/Iz6XqewVTKPiL3dl4w3j4zdj4+
         aC/CSs9JE5sLJy8ZerzieGEdAgAHHPnXsLlMDCWjF/Us5NhoF4tJjnqS3eqvnMI7yyyX
         KqKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786980982; x=1787585782;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=APmx+OQyjJW2Ssi7kcgtOEycsmzzm5MjhN44NhTcf0M=;
        b=IPtUyguk9j8lrS2CovTmd87Axp90kayM30+1byRPXYpGlpzCkNDSHdNuQtLhOWOZgQ
         Rt+nyv3Y6+absw3E7QpkTrSFOfkCekWCf7EpE5p5gafe6L0ef1HLMhkR1aj8LsS4+I3h
         25afHKjybr4sdhfPycpVgCTXXH/4wIH9o5VQAxJsa/yujlLIvmmIW27niOm2KNRcxOXp
         TGRwEA00R+ptkoXTJr05IDP+K3giA2FoYadf5uK7YQRZ65n0oDbCSXEep0VZmgN6waGu
         kNO6c72iM7fndRzTjaRd53RlFxpqXMMlXGedKOG9L3p4Q1kJbi2vVQr8RcER1VuSRJOa
         PpTw==
X-Forwarded-Encrypted: i=1; AHgh+RpQEW4gvaQM/clntwmmFyO4bv6Pgu8y/uwO9ZjULYjfN9yzDeEmoG7gw+qpMSiHoiICVtjjF/9jGAw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSl6A75JsujuYo5F/UtZCMBHBOJBuc1dAWMvkPuYvJ4nKb9FYw
	crRjZ4PlrUMdZ/pMXdrjl81U9iF/XjZ+1f/uIM5GXPLJSOXUnhdGwxnc
X-Gm-Gg: AR+sD12dTo6toDFsXf1LCjIFL/fCk480fuz6zmll9G7BykIFNBbEGH1LiQi2XLhFFXT
	2dVpax8qyPf31XwRjvQTia80wLN6NIv/qfjGIzbGeggCxWbQXWklqwbFL5IQawED6CN4IAmifn7
	PybdcyyS6Is4p8Wz6uMPUJ/gZHKDL0nEoiQzw/uOBYzBkPNC/MLDlMCCe/9b0H5s7zTTnVkFgdD
	YDC8WgkOYNDzWH2LK4/3Jj/aYMJ7MH6pwj0u0Ij3vbnhRakdXMdFeoeOYm29cuPWmt0s8B/vbCx
	kZcnnXU1KRhOBGEzcc0Ogohoi09T9L6ADAxTYJ7JDXb7bO8EK3j6h4RF/hw6u7EHSFJJPEs3Q8u
	yrKezD6dre80XsIM8ee/sSdkUx0/Ds7caIhUL+iikTs+4//Vkd4yZEKXCy3c12HXqzj94xu1FRd
	olgeSkZPTJ9zyiHsa2glL20RJqoiRURah4Sq+BdjjFSK2jxInomuhf/iNiy8bxk7ri4wGUbtI0X
	pKt6df+6B2coIBYi7uzW2keEpPIKjAt/sHdHdsPks4srH1l
X-Received: by 2002:a05:6000:46cd:b0:47f:9486:810b with SMTP id ffacd0b85a97d-4816074ac41mr30202251f8f.7.1786980981406;
        Mon, 17 Aug 2026 08:36:21 -0700 (PDT)
Message-ID: <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
Date: Mon, 17 Aug 2026 17:36:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
 <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
Content-Language: en-US
In-Reply-To: <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786980982-F02992AC-11CB2D4C/10/73395122804
X-purgate-type: spam
X-purgate-size: 13869



On 8/12/26 5:30 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> Introduce riscv_vcpu_unpriv_read() to allow Xen to safely read guest memory
>> using HLV/HLVX instructions while reliably capturing trap context.
> 
> Both for the title and the function name: How does "unprivileged" matter here?

Unprivileged because HLV/HLVX reads guest memory as if it were accessed 
from a less-privileged (guest) context, rather than by the hypervisor in 
HS mode.

I think I am okay generally to drop "unpriv..." from the function name.

> The same functions would be use for reading Dom0's memory, wouldn't they?

Yes, I don't see any issue to let this function to read DomO's memory 
too. But Dom0 could be counted as "unprivileged" too as it is executed 
in VS-mode which is less-privileged then HS-mode.

> 
>> @@ -114,3 +115,93 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf,
>>       return copy_guest(buf, gpa, len, GPA_INFO(d),
>>                         COPY_to_guest | COPY_gpa);
>>   }
>> +
>> +/*
>> + * Read machine word from Guest memory
>> + *
>> + * @read_insn: Flag representing whether we are reading instruction
>> + * @guest_addr: Guest address to read
>> + * @trap: Output pointer to trap details
>> + *
>> + * 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.
>> + */
>> +unsigned long riscv_vcpu_unpriv_read(bool read_insn,
>> +                                     unsigned long guest_addr,
> 
> Personally for such a function I'd expect the address to be the main (first)
> parameter.

Agree, it will be better. I will update prototype of the function.

> 
>> +                                     struct trap_info *trap)
>> +{
>> +    unsigned long val, tmp;
>> +    unsigned long flags, old_hstatus;
>> +
>> +    /*
>> +     * As hstatus is going to be changed we don't want an interrupt to occur
>> +     * with guest's hstatus register.
>> +     */
> 
> I don't think "guest's hstatus register" is something real. hstatus is
> entirely the hypervisor's register, controlling the guest.

Agree, the wording is incorrect what I meant it is that we don't want to 
corrupt hstatus which was saved during guest exit to hypervisor.

I will just put the following comment "As hstatus is going to be changed 
we don't want an interrupt to change it".

> 
>> +    local_irq_save(flags);
>> +
>> +    /*
>> +     * The hypervisor virtual-machine load and store instructions are valid
>> +     * only in M-mode or HS-mode, or in U-mode when hstatus.HU=1. Each
>> +     * instruction performs an explicit memory access as though V=1; i.e.,
>> +     * with the address translation and protection, and the endianness,
>> +     * that apply to memory accesses in either VS-mode or VU-mode.
>> +     * Field SPVP of hstatus controls the privilege level of the access.
>> +     * The explicit memory access is done as though in VU-mode when SPVP=0,
>> +     * and as though in VS-mode when SPVP=1.
>> +     *
>> +     * So it is necessary to restore vCPU's hstatus before execution of
>> +     * hlv* instruction.
>> +     */
>> +    old_hstatus = csr_swap(CSR_HSTATUS,
>> +                           vcpu_guest_cpu_user_regs(current)->hstatus);
> 
> As you're limiting use of the function to the current vCPU, why would hstatus
> need fiddling with? The fields of interest aren't being altered between exit
> from guest and making it here, are they?

You're right, it doesn't. handle_trap() only saves hstatus into the trap 
frame on entry and restores it before sret; nothing in between installs 
a hypervisor-specific value. So the guest's hstatus (in particular SPVP, 
the only field HLV cares about here (HU only matters in U-mode) ) is 
still live when we get here. Traps taken from HS-mode update only SPV 
and GVA, neither of which affects HLV.

> 
> Without that IRQs also wouldn't need turning off (what about NMIs, btw, once
> supported on Xen?), which would help real-time use cases (latency here can
> otherwise be affected by guests, by wait of forcing exceptions to be raised).

Correct, and I'll drop local_irq_save() too. In fact it is already a 
no-op at both call sites: do_trap() runs with interrupts disabled by the 
trap entry itself. And even with the hstatus write in place it would not 
have been needed: any nested trap goes through the same entry path, 
which saves and restores hstatus (an NMI path built the same way would 
be safe for the same reason, rather than relying on interrupts being 
masked).

What I will do instead is document and assert the actual precondition: 
the function may only be called on the trap-handling path of the current 
vCPU, before returning to the guest. That is where hstatus, vsatp and 
hgatp are guaranteed to still be that vCPU's. do_trap() reaches 
check_for_pcpu_work(), and hence any reschedule, only after handling is 
done.

The following check I will add instead csr_swap() and local_irq_save():
   ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV);

> 
>> +    if ( read_insn )
>> +    {
>> +        asm volatile ( "\n"
>> +            "1:\n"
>> +            "   hlvx.hu %[val], (%[addr])\n"
>> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])
> 
> Imo labels used for extable entries would better live on the same line as
> the insn they mark.
> 
>> +            "   andi %[tmp], %[val], 3\n"
>> +            "   addi %[tmp], %[tmp], -3\n"
>> +            "   bne %[tmp], zero, 3f\n"
> 
> Use BNEZ?
> 
>> +            "   addi %[addr], %[addr], 2\n"
>> +            "\n"
>> +            "2:\n"
>> +            "   hlvx.hu %[tmp], (%[addr])\n"
>> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
>> +            "   sll %[tmp], %[tmp], 16\n"
>> +            "   add %[val], %[val], %[tmp]\n"
> 
> May I suggest OR instead of ADD?
> 
>> +            "3:\n"
> 
> If this is an insn wider than 32 bits, you won't have fetched all of it.
> I think you want to at least add a comment here indicating that e.g. it's
> the callers responsibility to deal with that. 

I will add the following comment above the function:

  * At most two halfwords are fetched when @read_insn is true, i.e. 
encodings
  * wider than 32 bits are not supported. Such an encoding cannot be 
completed
  * 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.

> (How they would do that is
> entirely unclear to me, as they can't simply invoke this function again
> passing guest_addr + 4.)

Then it will be needed to update the code of riscv_unpriv_read().

For now we could something like:

        /*
          * Only two halfwords are fetched, so an encoding wider than 32 
bits
          * would have been truncated. Report it as illegal with a zero 
stval:
          * a nonzero one would have to hold the actual faulting 
instruction,
          * whereas zero simply means the value isn't provided.
          */
         if ( !INSN_IS_16BIT(insn) && !INSN_IS_32BIT(insn) )
             return truly_illegal_insn(v, 0);

> 
>> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
>> +        : [ti] "r" (trap) : "memory" );
> 
> You want to tell the compiler that *trap is written. Instead I don't see
> why a memory clobber would be needed: You access a different address space,
> i.e. nothing the compiler can make any assumptions about.

memory clobber tells the compiler that the assembly code performs memory 
reads or writes to items other than those listed in the input and output 
operands and so I don't tell here that *trap will be changed.

Why this understanding is wrong?

Alternative, I think, could be:
         : [val] "+r" (val), "+m" (*trap)
         : [addr] "r" (guest_addr), [ti] "r" (trap) );
And then memory clobber could be dropped.



> 
> You also need to take precautions for not returning an uninitialized "val".
> I think the variable wants initializing (perhaps to ~0) and "+r" wants
> using as constraint. (Afaik & isn't necessary to use together with +.)

I agree with '+' if we will initialize val with some value.

Regarding, '&' my understanding is that I have to use it always when

> 
>> +        /*
>> +         * Although HLVX instructions' explicit memory accesses require execute
>> +         * permissions, they still raise the same exceptions as other load
>> +         * instructions, rather than raising fetch exceptions instead.
>> +         */
>> +        if ( trap->scause == CAUSE_LOAD_PAGE_FAULT )
>> +            trap->scause = CAUSE_FETCH_PAGE_FAULT;
>> +    }
>> +    else
>> +    {
>> +        asm volatile ( "\n"
>> +            "1:\n"
>> +#ifdef CONFIG_RISCV_64
>> +            "hlv.d %[val], (%[addr])\n"
>> +#else
>> +            "hlv.w %[val], (%[addr])\n"
>> +#endif
> 
> Once again please use enough care that RV128 would at least obviously fail to
> build, rather than building something which then doesn't work.

Sure, I will do the following:

#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)
>> +        : [addr] "r" (guest_addr), [ti] "r" (trap) : "memory" );
>> +    }
>> +
>> +    csr_write(CSR_HSTATUS, old_hstatus);
>> +
>> +    local_irq_restore(flags);
>> +
>> +    return val;
>> +}
> For both reads and fetches - are there no alignment constraints at all on the
> incoming guest_addr?
> 

For the fetch path there is an implicit constraint, but the architecture
guarantees it: guest_addr is always the guest's sepc, and IALIGN is 16
bits (32 without the C extension), so it cannot be odd, the guest would
have taken an instruction-address-misaligned exception before we ever 
saw this trap. hlvx.hu is then a naturally aligned halfword access, and
advancing by 2 preserves that.

For the data read there is deliberately no constraint: HLV behaves as 
the guest's own access would, so on a hart which handles misaligned 
accesses it simply works, and on one which doesn't it raises 
load-address-misaligned, which the exception table turns into 
trap->scause for the caller to redirect.

But then it will be need to:

--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -565,51 +565,73 @@ static void do_unexpected_trap(const struct 
cpu_user_regs *regs)
  void do_trap(struct cpu_user_regs *cpu_regs)
  {
      register_t pc = cpu_regs->sepc;
      unsigned long cause = csr_read(CSR_SCAUSE);

+    /*
+     * A synchronous trap taken while Xen itself was running may come 
from an
+     * access done on a vCPU's behalf, e.g. the hlv/hlvx sequences in
+     * riscv_vcpu_unpriv_read(). Those accesses are covered by 
exception table
+     * entries which record the fault details for the caller and resume
+     * execution past the faulting instruction.
+     *
+     * Interrupts must be excluded here: one taken at an address which 
happens
+     * to be listed in the exception table would otherwise be "fixed 
up" as 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 ( !(cause & CAUSE_IRQ_FLAG) && !(cpu_regs->hstatus & HSTATUS_SPV) &&
+         fixup_exception(cpu_regs) )
+        return;
+
      switch ( cause )
      {
      case CAUSE_VIRTUAL_SUPERVISOR_ECALL:
          /* CAUSE_VIRTUAL_SUPERVISOR_ECALL should come from VS-mode */
          BUG_ON(!(cpu_regs->hstatus & HSTATUS_SPV));

          vsbi_handle_ecall(cpu_regs);
          break;

      case CAUSE_LOAD_GUEST_PAGE_FAULT:
      case CAUSE_STORE_GUEST_PAGE_FAULT:
+        /*
+         * Anything not recovered by the exception table above must 
have come
+         * from the guest: a G-stage fault taken in Xen context, e.g. by an
+         * hlv/hlvx not covered by an entry, is a bug.
+         */
+        BUG_ON(!(cpu_regs->hstatus & HSTATUS_SPV));
+
          handle_guest_page_fault(cause, cpu_regs);
          break;

      case CAUSE_VIRTUAL_INST_FAULT:
      {
          int ret;

          BUG_ON(!(cpu_regs->hstatus & HSTATUS_SPV));

          ret = handle_virt_instruction_fault(current);
          if ( ret < 0 )
              /* TODO: crash only domain instead of Xen? */
              /* domain_crash(current->domain); */
              panic("couldn't handle CAUSE_VIRTUAL_INST_FAULT: %d\n", ret);
          break;
      }

      case CAUSE_ILLEGAL_INSTRUCTION:
          if ( do_bug_frame(cpu_regs, pc) >= 0 )
          {
              if ( !(is_kernel_text(pc) || is_kernel_inittext(pc)) )
              {
                  printk("Something wrong with PC: %#lx\n", pc);
                  die();
              }

              cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc);

              break;
          }

-        if ( fixup_exception(cpu_regs) )
-            break;
-
          fallthrough;
      default:
          if ( cause & CAUSE_IRQ_FLAG )
          {
              /* Handle interrupt */

Does it make sense?

Thanks.

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Mon Aug 17 15:56:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 15:56:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393088.1631982 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzgx-0005jr-Bm; Mon, 17 Aug 2026 15:56:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393088.1631982; Mon, 17 Aug 2026 15:56:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzgx-0005jk-8q; Mon, 17 Aug 2026 15:56:03 +0000
Received: by outflank-mailman (input) for mailman id 1393088;
 Mon, 17 Aug 2026 15:56:02 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wvzgw-0005je-6v
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 15:56:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvzgv-003TcE-5l
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:56:01 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a832ef4-e002-0a2a0a5209dd-0a2a4503b05a-46
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 17:56:01 +0200
Received: from [40.107.201.51]
 (helo=CH4PR04CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a832f0a-fae8-0a2a45030019-286bc933b61a-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 17:55:55 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BL4PR03MB8105.namprd03.prod.outlook.com (2603:10b6:208:58f::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 15:55:52 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026
 15:55:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kfkttt0AuGQQIjSUnpj36YLc4Z7mdSoNx2tqCAPGjxn5APCXkuw9nuNWaCPxa9N/Fx5gniCE9umM09T8UwWwgaYCoO12qR8qvso9y5PPzlPpbeZkySyZppdrFNw40UW+bSReZ95ixgUjr297W+B+o2dRIi9Ze0oxLq7KLzHH6Sgl4W7NUALODuBYvkJ9VzCAZNP6vFB4RIRmYy1X0q2bXplx+EeJDwoRV8hHRsyJ0laPFzg/FDKYy/fGgKxurkEElgNTiEYSPq9b4+DhOaB6UUef8sItkJfxERGxUkak0xumNzUgw1WB+YwTCKqY3ScvdnpWWWEhkxAhMAHE38pv/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gzTyTjOryEThhLGo2ffDznBm8Dy2ZHnhlRwu6jqfVIo=;
 b=N7qtQfbjI/Dw1ZubTpnDI+xep5x/QesVEvNvbDWjr3UvH7f5lVubOn23z5SQ52cFo62S58AgbIz+3DV+ZYwFT/3LhhZzv7b7c60SO0SioWbH74ZeXx2YpA1rVwvAknsC8bWAPlt5BJbRDv7brUNv9hxHPtrtZfPwL/zjjbSDMqqfQ43YqLKBM1i75DWTm7WqX8ZqWIkbO5Pu2Xd4dw4gRNRK/diGSnMUqzVSt1KlPwQp8cRAEZS2jmfMaCEq5gJdJY6+4E1/QBghL93m2oxqJl7C35OpwwH9Ezl9is7t6xjONpRw6kx2qdbM+qJfpe2eLiYk3h1ShkFKnzfILVpgjQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gzTyTjOryEThhLGo2ffDznBm8Dy2ZHnhlRwu6jqfVIo=;
 b=QgaxA56OS9ZVriGbwDaZnuW7SkkSadBqDjUO+AD7t4Xv1XW750S1z9k1AYCOBunBuJ3Fae8d7n/V66q5b3KkmccQzMWv6na2MmE5zV2oU2fdmlrGRQCCrQT1iHTBSHQJh2k3N+ptX8xnCgc8Qib6WnT7CAXy+Q8BPjLlzWRWweA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <33aab2bd-db13-43f6-9616-5e75fd79b81d@citrix.com>
Date: Mon, 17 Aug 2026 16:55:48 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/nmi: Fix mis-classification of watchdog NMIs
To: Jan Beulich <jbeulich@suse.com>
References: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
 <4f58e236-c40b-4fcc-82e8-5b6f3eafe656@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <4f58e236-c40b-4fcc-82e8-5b6f3eafe656@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO6P123CA0032.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:2fe::7) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BL4PR03MB8105:EE_
X-MS-Office365-Filtering-Correlation-Id: 4cd22daf-1ae4-4d22-b034-08defc7803a4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|18002099003|22082099003|3023799007|10067099003|4143699003|56012099006|11063799006;
X-Microsoft-Antispam-Message-Info:
	Nqb99md9urF6Q6Pw/cDyEPnLw9N8goGKFyZwJliyz9ks30nj1wtng9AJgzuEV2OLfX2XaL9SP2KbmmC+ucuWhxNlWIruvRQeYuDTt6lPS5MOOZVglDnGbO5aRysnha94Ewejq5f90V4u0NLEPKpQjtD07J7Pc0oJfvMZg5rV3h9q1XaxqUeNwsipznfLuzn2AwCLPaFQLUO36AbVqFOGt6qY+0ympjYK1DwWNK5FpiQez7hyrD6K3yMTAubCP7SncDCJtwiWIH9aMymrHsR2WXYi6VIHLEJCkPdqmRzPCAKqyOteA9ngxMHtJR9DET/APlsAJCo1TfJMjerNthBlH0Qo5UCzskOVuLCfWykNU34ctWsADzQynLNqAlP6m+4oEwgQ6B+GGIiLb4hm/J5REFwfqg+5pJAdHXeDVJUdL96wYbCLWBrOtDFAv6VPpza5nFH/Y4HlIas2jFDX0KlHI8hPIaS9sRlsG0v3ucY+tMhh5r/9h1xSdw4YuYwV7JvWpVipS0skaTTVfAS3Ld0lNTJcph6tvG/CKy8Py0uxLw+irK0QAMHKBKQEGZWLG6BnG5jIWtzjtpItAN6pugkFGS3svr86MKl4KZ9MMBSESgBJinN1YJJqWMcSkHHI3iVF3AMZ8yLRkSN23lNw3LfGiSXTR1ACgq5K0OhE01isfHo=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(18002099003)(22082099003)(3023799007)(10067099003)(4143699003)(56012099006)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WGs2ai9DeVlKYjNJbDlKTEhwbWF5M2Npc050ckNEdWI4NWM1T01hUTBBN3J4?=
 =?utf-8?B?NG1QK3ZKL2JmQnlaQmNuRHBWSTAraTQweUtOZEZkTGhrREtGY205MWtsVkIy?=
 =?utf-8?B?TkFtSDR3ZjlhaDV2dEdtbWFqSVdrRFQvdDBiSGY3cXNpRm9KV2wwYStXMzhr?=
 =?utf-8?B?SmVvUVV5RUZzMjA3NWhuUjBnNXJLUTVuNEVQcG05TjcyNXNkMzFlYXZYdDda?=
 =?utf-8?B?MkRyUStIa3JDajExa1doVXlnYUVwZHM3TE1FZjZVaVpJc3Y1ZDlxeDJ6emN6?=
 =?utf-8?B?bzA2YzBXaU83N2I3bVUxdGtKYU1PbGRYRG8wbjVoZTVSQ3M2ZkExcEVuQ2Na?=
 =?utf-8?B?R1NPOHlDbTFobzVaVjJkeERiUEo0Sy9QNUdHSXk3Z1ZjM3ZVTHpycGMvYU1L?=
 =?utf-8?B?UFdtY2E1QjZ2VGxHc1BuY0tWYXpVYVFIY2YrRVdtZ0VVWmNKcEc4QStwWS9R?=
 =?utf-8?B?dHlVeUU2QVZsMzVkVVJxVmFxbWtiUHRaTUgwZzBheVNmZmtLOGN5UTBTWHN1?=
 =?utf-8?B?enRrbE1BODYwUGs1bEZvRnlVQmY4L2Vjc1JuWWRuK3JoMXF0VjFNR1RCSlNs?=
 =?utf-8?B?WkRmai9jTkF6VjQrSURETExVYkpOeklhd3FlV1JoZHowb2tyclREa2NENkk5?=
 =?utf-8?B?aDNZWGt2clJEWS9ZOCtXblhPQzlYZ0t4cWY0UTBTeFNyYWE0dmw0VUVtd0lz?=
 =?utf-8?B?S0RrQno0ZDd2aktUc29zbXh3RGovK3duM0lTakdhQktDeitjbGtTeVErSDdW?=
 =?utf-8?B?K1dybnBWM0hOWTJkSjJVaGNrZXIrS1dIbHlZNVhPZlZlUm1VbDB0YmE2RzhW?=
 =?utf-8?B?RFZPZHRXV1ZuMm9RcHVKZWQzcnpWQ2lSVjZUSi91ZkMwY0pFMXBWVWs2ckpQ?=
 =?utf-8?B?dGx5alFsaFZuc0NoTHdCOXlxeUI4OHM4Qm16RWhhdW9Zb2t5SjV0N25CQ1hE?=
 =?utf-8?B?TXdhRnVBMGZpRFJhQXJVSnVaMm5kR3d4bTJhUnhsZnhCQk1uRWY5SnBzdnFw?=
 =?utf-8?B?TlNLc2RqZDhSTVhRUXBRVU9KTmlQTUxGejZtSjdsVUI1SU1kUU9EVGhXdStS?=
 =?utf-8?B?QmZMczB3dThPUXVJd0l1emVDR3JQT2JLeGNwOEF3UTg3Y2EzSzNQdEU5ZjhI?=
 =?utf-8?B?YXhpZmpFK2hzTXFObFhldVk0SHh2THEydERUZzkyRi92WXJpSVg2Q3JrRDRH?=
 =?utf-8?B?SDRqMnpJd3F1UjYzcndXUC9ISkRScDJlYS8vZVBSZnlVSlBhazNkRzRYeVhr?=
 =?utf-8?B?LzRTekVVbUEvT2VOeTN6cGl5TVcxL0x0L1pZbDMwbENjUUtKWnRnMGxueDNE?=
 =?utf-8?B?dk9kMzZMTEY1eHl0bmQ3VzB5a2VCbFlTY1g1YjlxWUU1T1VoVG1yQzl6WWh3?=
 =?utf-8?B?OTVya2QrWTZlSWtOQ1laNGF5RTREM1JiS0FLaXZlU2dIYW5hblN6ckh1SWMw?=
 =?utf-8?B?aTNVZ3F0c0NzSERET3hUT3Iwc2F0OWZ5L0NualpMUUhiSmVPOUJlbTlVOFhE?=
 =?utf-8?B?Rm9PQlkwS1dsVHMwT3l3c2RwdXVQNlhTK3M0dHNxWjZyVzd4UWk4bVdINjhS?=
 =?utf-8?B?SjhkMTJQbzRTck5JVFh0clB6VkhkTDE0K0NBWURwWlF3VjlmaG9BUyt5UHkw?=
 =?utf-8?B?ODdxU3Ard0dQbE9mQk1VaC9KSm0vVndPNHZZK0dJTkx0ZE94c3U0V3BjVHdH?=
 =?utf-8?B?MW1kcWpRL0tOU3dxb1Y1Y3hVaUJ2ZE1lSmFtT3h2SmNkSzFGOWllTThYbFhm?=
 =?utf-8?B?Rms5K0xENkI4NlIrRDliWmR0QkIyM3FMQ0ZDUVNab0RoOUY3d044aEFrUFMv?=
 =?utf-8?B?dGZTejJPVWVDeUxFWFlwd2I3RHR1S2ZmUmNScTA3MGg5NHk3aUowWnprVU0r?=
 =?utf-8?B?U3N2bFNEa1hRMXRqSmpQM0xZQklndzhvdnR2cHRCcEpnQThGUEl6aWJnY0p6?=
 =?utf-8?B?RjR2TXZkenIrK21uMFJhZHYvM21MNHhENnN3YWdIeHVSSkhXSlZWMHhTL3Ay?=
 =?utf-8?B?VGc0emwvd0FIWFBwbjJvZVN4VVdxaWxoOFRVL0hyaGozL3ZFL0lReFB1WWJ1?=
 =?utf-8?B?TjZURFFrTnNpRGpiV1cxbjhKRDJ5RjZ5NEdCcU5NanRKQ1drNGt0d0RHOVl3?=
 =?utf-8?B?dUhvUE1URHh2MDBTRkVIT0NZTWJaZjVHb3IvUytpNVJXWkNyd0sxNzFyN2xn?=
 =?utf-8?B?QmRraTZndWR0dG5IZkVLU3M0SXhWTVpINy81ZWlkOEtaU0dWZWtOVHhtY2ZD?=
 =?utf-8?B?dUpmSUZGSWFTR2cwd3pnREsrcVhyMDAwYTVESWlFVVU3UUVYcGJaK0g3N01D?=
 =?utf-8?B?R2k4eU1nS1cxUlFrTzBuN2lqVXphOHJBNU4wUjMyTlEvcVE5UlBkQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4cd22daf-1ae4-4d22-b034-08defc7803a4
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 15:55:52.2752
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KF+StwbMba8iwEAahkCqEPh7K0ilcQbqFzBR+1V7wmsUynlUIbErJ127jf6lUJnjMvXzhfrM4JExCaLWNuZXNYnkM5VAnWjTevgxMahJpOg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8105
X-purgate-ID: tlsNG-33051d/1786982161-76EF74E9-9F7A61D9/0/0
X-purgate-type: clean
X-purgate-size: 3073

On 17/08/2026 9:30 am, Jan Beulich wrote:
> On 13.08.2026 19:43, Andrew Cooper wrote:
>> It used to be the case that cpu_data[] inherited the BSP's cpuid_level until
>> the AP had calculated it itself.  Following the rework, cpuid_level has a
>> placeholder 1 until it is caluclated propely.
>>
>> setup_apic_nmi_watchdog() happens to be called on the BSP after SMP bringup,
>> meaning that the first call is on CPU1.  It is also positioned in the window
>> where cpu_data[] is garbage.
>>
>> As a result, setup_p6_watchdog()'s one-time calculation of the performance
>> counter width falls back into Pentium compatibility mode assuming 32bit
>> counters.  This causes a watchdog NMI which is delayed a little (e.g. from an
>> SMI), to appear as if it hadn't overflowed, and therefore be (mis)classifed as
>> not a watchdog NMI.  On systems where unknown NMIs are treated as fatal, this
>> results in a spurious crash.
>>
>> Switch setup_p6_watchdog() to use boot_cpu_data.cpuid_level, which is how this
>> is checked almost everywhere else.
>>
>> core2_vpmu_init() used the same pattern to look at leaf 0xa.  Despite being
>> init code and only running on the BSP, {boot,current}_cpu_data are different
>> objects, so switch it over to checking boot_cpu_data.cpuid_level too.
>>
>> Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks.

>
>> I hate this fix, but it's the only thing which I consider remotely safe to
>> backport.  Recent attempts to alter CPUID ordering have 0 success at being
>> bug-free.
> How that? Collecting CPUID output should be doable almost first thing. There
> are no (or in case of doubt: there should not be any) dependencies on about
> anything else. Of course re-collecting may still be necessary after ucode
> loading. Yet from what you say I must be missing something crucial.

I was referring to commits in Xen rearranging the boot sequence with
respect to feature handling.  There have been many failures recently.

> With that in mind, I'm also questioning the Fixes: tag (without this being a
> request to drop or change it): Using another CPU's data isn't much better
> than using partially unset data. Unless we assumed full symmetry, at which
> point re-obtaining of most data on the APs would be entirely useless. Hence
> the issue was pre-existing, with one bug there hiding the issue addressed
> here.

Copying the BSP is less bad than the current behaviour.  It's not
necessarily ideal, but it's a damsight better default than the arbitrary
1 that this patch puts in place.

Even with the very old 64bit systems where mixing steppings was
commonplace, I'm not aware of a vendor supported combination where
max_leaf was different.


The issue was not prexisting.  Prior to your rearrangement, the NMI
watchdog setup found the counter width in CPUID and used it, without
falling back into original Pentium compatibility mode.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 16:04:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 16:04:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393096.1631992 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzpR-0007xJ-5a; Mon, 17 Aug 2026 16:04:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393096.1631992; Mon, 17 Aug 2026 16:04:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzpR-0007xB-1z; Mon, 17 Aug 2026 16:04:49 +0000
Received: by outflank-mailman (input) for mailman id 1393096;
 Mon, 17 Aug 2026 16:04:48 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wvzpQ-0007x5-0b
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:04:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvzpO-0046wv-Go
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 18:04:46 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a8330fc-e002-0a2a0a5209dd-0a2a450abe00-46
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:04:45 +0200
Received: from [98.137.65.147] (helo=sonic309-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a833115-f2d2-0a2a450a0019-62894193b44c-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:04:38 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Aug 2026 16:04:36 +0000
Received: by hermes--production-ne1-6dbcb84f44-46rwf (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 98ae4e748b194883b83f02ba26d804c6; 
 Mon, 17 Aug 2026 16:04:34 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786982676; bh=kW5c3iq1F6UiN1+G4AWz6LGpAojyDpS6Xdqm9qTL/OM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=hpAxfWv6Gb2a8QcO+Dte9x4fOxzG5Pr6Fdd024s/I/OEywi4AUJh8ee2qNIOX4Vyt7ba95h7ZooSZ9oj42o4ZjCdhmpQAEJtEVRNJGN3EsRd28lgttmNT9ES9nyP/GQlfZ8sXW6FVwPvHwDxpV63bSJleeMkaSI5Np1rfHs3v9M13Ir1ABlg2X8cozpnfeKHHIERZMuOIM1PO58KKjV5ywL9Aqwm/jyPtS5kC5GoORzf2XRw+yiYj3+QGADZ9LmiTS7RIK3c2yRebDe4ezzWGs12cCxc496qLBSW8tYl6qMYyi3jjboBhG7O/+A/90WZV9le5AolpooakRHU3blKPw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786982676; bh=NsuSy2jgaze1RNyCPmJ/TICjkp37hf9r0mtC19/DrcU=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=FctgtNKRR6HKWoLV9khJk2Xy29ZVlR1klnaG0sAWnPeO4HSgFMBS8MF6vMyIz5mxZm/69tYKiv9ulYqv0rhHZcCAJV/5dQDz9G3yD2oquOgxpvfS06J0hM8aP7Tqxl9GU5Uh9ITP4XG7oIPUypePyonwe98zaTN7ka9OuyGg8GYGNJRl7gTcUIXmqn+Z/0APlQYdq0tJMeJveoppbiO0Zlp02eBV908wI+8Cco9wyk98w93eLdbweJLH8C85ygjp8a99rKQzp1/4ecfq7bMKfgCL6phMPB+t1Pp8X49PkbGLd5uwCmulmIgR/1AfLIn4bkLPfustdow+CzredzAjIg==
X-YMail-OSG: nsFWtHQVM1maVCM_WIfpU.FdUWH6_7poqfjBjmtUjJ2ahZXT3SB_cCwkxZM1Kt1
 wtvgbJomoUQRNV5VfGii5S95KNhfu96JiB7mxBWYfjqIpgUwy.6O9iZCwrKcASSYVGJbBU9fcSBW
 eawx4vQKgAnn31bRI3vQuG3ES8iPqbpCJWCho3sqwmLWe6LpONtke59cMYlfSXAD.K.BReNsucwF
 iYTZk4uSep3mWkW.E0PWNWI_mJptAgLjID1dMdncOmxDwaDSjIF.qBsZcb_be5AaPhxcmyRQkwb5
 QkXmbGK9W6dYf0nz18EzlQJjU.cOhoYCVN7l._DOw9i0n1KN.YBIo.qBPy6RuNsBtiuvSaNNXsxx
 DqWZmYyq6rDsqKVlIQpKnXGMQULsO2QYh1nN8dGBVQ_c4YyLCcbE7RDe5yh.SSBikDU_b0TglDGH
 1ksIXUz5dnWwsvSmzzl2C2ZT5bKB13aysIo9n0b1I5Yysc.KKoAe85jy7_lKXgPy9rZmpJkj80cN
 jrKZo_gTp0xu9SMRlYlHF4lRjH9tb4sS1g1xxSoeAPDEC6Gh7n9TVwOXVZsxb04vdcySNZ57QyoP
 FQHw86V9PFxgjSPY1mGeyRJCmwxtkMBHos.m41_AIi_swP_apTuFF2KjKryO2benBSh.EVI3hHzL
 NoP2zUPYn8r1APrC6FapsWIH_SQiP6W4T7MDbKqAKY9e8IV4.YX4NpjSv9nFyecg.52m.FNXM2tr
 ol.lWOexVwkV1Ym.tIM4syT3x0BcVwfEdyJhxXM08.r0.dW_fn3aPGIoz0j7C32uEVCbnHbO.TdA
 27DIJNowBUNfhgQOgQ2Y3Tvc5.75yMAMz0MPIdmolfmzftjQh4jqRcKtH8X3zRZMM7i7Q5mRp_Ml
 eyQ3t9b4kFn1FyyTPWKniqGi7LpSL60u7ZGBhOrPQWoPjYYjpwNyud94Ka4EEq.UjkjigaLS_yjm
 pZ2W0bND50gO10mMbcE1KYIXGzqcLRpPMrZSYSwBgiImtKhbpawYq1wXk2OWhd_bKsVpWjFR1S7Z
 EZdqbh7rfxISnCrsxRMJHUJYDYBvGPUMmG8pUrdVb9meoI1C1pN_Z2Gry2_Kq9lUhRMgjhvxRxmq
 iggm8j8FoIRxrAvHVb7uBOAcu76g_I5vIJoIJFi5aEDm3DN6gA9QdIdQXUgfY1jFxEWTQubtpZxC
 p_sOyf4ICjlwio45.Njcn9gzVYSLOgQeXo4z0czae2Liq.wDcTowWSe6Q5BHNZrIqAVupyzPYgBM
 MViQTPDxNu6PIcY8bGUJ3rspCef054DI82gk0inGuiT2T1IXoJqci587ymIjuGEJLz3QEyUflk6r
 4WZ3ebEoMtaiouOrglzqetR.HuhwuWhTHSyo3gm5_BuBqRuRlkqBOEh2nyvjFiMEUxrEgFWHtAlv
 1c4BcHduZqEgcG5BKyzTErGE0lJKq4QRSdiMdaab57iV9aFs2G1VXXpvmgDQ8svEV7C5a_5xNYJp
 FslFWjyl9LqDgO0bPrKxfTcZT1vQV.OZDhNt4HnuQTFOXpMpsNtHjORZh_jlmp7vXXOC8s_i6ODR
 g7cLRX0cdoiuYctPaAGIS153rM5Z4lpSjy_hFJFgGr322J_wRqa8Q6lzL4Stk5HwVQmzjuiPAVO.
 _OfjRSMJtRCwn.ByPM9YNCy..Zwo1qul7XemewH2wt7IEEtPeX1qdG8zESxSB_TayGIbxV3aj4Be
 7swS_R.pfWZHTFb_SZsb1XDrvBE958BNeZsSZ3FjHaJdGrFbEXTGhxRk7hWigBnqNCYNn8klWMdV
 mReNf.nzN0dE2RfIN5t.MExj4InVnHZAuRLkLNUPb2UIO8k_mPPD0uaR0m1GQmSpw5fR58jAkbHC
 E_5OCfB1zA5fVIogAERWK2VwUxq.26uWMikobRvpoR28QuBdrBBeEtfgJcJr47A3tWCNgGk7eVXX
 j2HYk6.bAE2Us98mjPjTKlyMTICJiDzMfx8Lf98bQPcYxkwaLiRnQCw1tAwAeiyu1JRs4RnQrx71
 ZgMGFYS_QJKA0pdyXwkVZNDfa7hfhE_sPQ8_PafKsvkW6hjk8UFhX9GXfeRDZVvedpcdoYr4Mdz2
 GK4AH9xDWNwyFI5ZrNBTj74pGuOXmFOjC3vPv6RF1x7LhNbmXVyfJGPgaIOs4s4d7tOpGS5cZXjg
 MhjQ.XTVAR8FOWhO7F_wNQpRWI407GM7zWS6qgseeTxnKjOs1AedIcvtS.lrPUlUooOpgqIFQoHH
 BXsHEwZM09egMih1R.jCd92ovEqXw3JamRf96KIpTKbE-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 9e1a9e8c-efa5-495a-a07f-bf24d83300bf
Message-ID: <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
Date: Mon, 17 Aug 2026 12:04:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 4421
X-purgate-ID: tlsNG-4011c0/1786982678-4A9D9CFC-D28EC325/0/0
X-purgate-type: clean
X-purgate-size: 4525

On 8/17/2026 4:42 AM, Jan Beulich wrote:
> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>> -- snip --
>>>>>>>> +    /*
>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>> +     * after we also write the guest address where the
>>>>>>>> +     * VBT will be mapped.
>>>>>>>> +     *
>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>> +     */
>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>
>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>
>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>
>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>> by its DM.
>>>>
>>>> I think the host OpRegion is not currently accessible by the DM.
>>>
>>> Can you explain to me how the region becomes accessible to the guest?
>>> That would then (hopefully) help me understand why the DM would not have
>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>> guest are also assigned to its DM.
>> 
>> Currently, in the device model (Qemu) we have:
>> 
>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>             DPCI_ADD_MAPPING);
>> 
>> That statement is in the igd_write_opregion(...) function in the
>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>> 
>> If I understand our current implementation correctly, this statement
>> is what gives the guest access to the host OpRegion (3 pages as defined
>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>> in hvmloader code).
> 
> No, it introduces mappings of those pages into the guest's P2M.
> 
>> I don't think this statement makes the host OpRegion
>> accessible to the device model, though, so I think, if I understand your
>> comment in an earlier about my patch resulting in what you called a "layering
>> violation" correctly, that our current implementation is also guilty of this
>> same kind of "layering violation."
> 
> That code, if it can be successfully executed, indeed doesn't grant any
> permissions (to the DM or the guest). Instead it proves that the DM has the
> needed permissions to access the pages itself.

So, are you saying it should be possible, without any patches to either Xen or
the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?

I think I could implement what you proposed in an earlier message and do
all (or most) of this in the DM instead of here in hvmloader:

> The more correct thing to do might be for the DM to
> put in place a copy before the guest (i.e. hvmloader) even gains control.
> (How in turn the DM would learn of the contents of the opregion is a
> separate question then.)

Actually, when I was developing this patch, I tried first to do it that
way, but the problem was, I could not find a way to get a pointer to the
host OpRegion in Qemu.

So, how can I get a pointer to the host OpRegion in Qemu?

This is what the handling of
> XEN_DOMCTL_memory_mapping has in this regard:
> 
>         ret = -EPERM;
>         if ( !iomem_access_permitted(current->domain, mfn, mfn_end) )
>             /* Nothing. */;
> 
> Subsequently we check that the guest is also permitted access:
> 
>         else if ( iomem_access_permitted(d, mfn, mfn_end) )





> 
> Jan



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 16:10:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 16:10:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393103.1632000 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzv9-0001IX-O4; Mon, 17 Aug 2026 16:10:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393103.1632000; Mon, 17 Aug 2026 16:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wvzv9-0001IP-Ki; Mon, 17 Aug 2026 16:10:43 +0000
Received: by outflank-mailman (input) for mailman id 1393103;
 Mon, 17 Aug 2026 16:10:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wvzv8-0001IJ-2Y
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:10:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wvzv7-0047pO-86
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 18:10:41 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a833276-2eae-0a2a0a5409dd-0a2a450294e2-18
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:10:41 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a833281-6ca4-0a2a45020019-d155dd2cd181-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:10:41 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-471eeac43bfso3155889f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:10:41 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a6c449dbsm4118368f8f.8.2026.08.17.09.10.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 09:10:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1786983041; x=1787587841; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=S5Lu+q0GTBbHqPkp+c6So3t9yaUIszgkEcgQDMo0x/M=;
        b=Sd5Sod+io4Gir8N7fyWs0P8CZkpWoemqWVD0oondLxrBtlER7l0+vvvP+0TJbBgg+0
         CdbWrCoCPgMZA98AtFoIBMWd9lwbzNQbHsSvdIa52SFpfrQq3B/UpxyG7MszQwwOiNfd
         6rqDWiFJpQsA8sW7dj4JfucZKSnKThWDNYjnwnMvqeDImCCRJ+AOMMiiA2ilOuu1wk6f
         er2HOXeolu+O8da6+XTisMi6+3LsKj1MH5B2VkUIzTFcl3pB98xBblMDLsF4if9oeRMl
         lwjGMtO9uDLs9lNi75umiG3zTz5X/4QmQPQJxNvU8W4CIfVvGmZXZ16Yw5nqBvYTl2oW
         nz9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786983041; x=1787587841;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=S5Lu+q0GTBbHqPkp+c6So3t9yaUIszgkEcgQDMo0x/M=;
        b=fKYt//STtvz33AIkc1+WAw1x59ZMhkBWxBl8IV+3iHbLwvBGYPndEfGP+qAtpiezSY
         hmwDiX25NGR7QsY64F6OTidB6r9bXlxiLl4NL2gNaB6ZA+TiSXRjS3kvhhDhrG2NscK8
         rZUH8VWmJitVX9S0WS+X6X6sVcCxmEcEbJrP/h6kCACP93IzC34iKGrjEJqrdUmQqFHw
         cGQ1saqXXb19H7yyKkT2tqhuCjZpk5w4S4ywJ7Ft8MuUlS2SkVbbl6mDdZQ5su9BxXDo
         P0d6N2Z9btIWPSwiz0YGy5Mo22/JzS3ClQ/h6wIarviMHWe7p+VKfB3nixyznpHm6Sci
         A7Ug==
X-Forwarded-Encrypted: i=1; AHgh+RpAaN0Jkn60IJLI8qFnplmQNeWlYuOGadCpjF31T5Ikam1yJTh4RJsgjpFlvOLUWnPyzVUNREBTZC4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHS1Jcr/i1lUUxXFcx7l+lct+eQ+LxOu2+DFOKtxxPh5vlAKyQ
	1Z7HQB9AHefLPJ4CtIlEXlLLA1dgzhaiBCsDELdbGq+ShgDx0p7S391d
X-Gm-Gg: AR+sD12Eck+EvRttNjWc6pY0de899AyCSq5lb3OXn8aXYY+4BaulAVLTTUCuGuxGWtr
	9wx6ZSuGqdxNvzJgfnILVhQrhnC2a3Y89oBdwPMgFeseTjc4zLHM+Ws8jQcayg7L4gqnmK8epD6
	ntfUpLgC9qUEXxhDpD8jjP6hi/y+kyUv3v0L2vcz2Oawy0LXWh+ib8HrKI1HjkByjqgkw6tZQm0
	gLYDPBc+w5xRgOG817Bs5fb+JaOSIqisjrt/hf41BKybokqttuIlSazWvUU0o7qr5vWux6dj+c0
	5ROkfISPnb6S6xKdpBbJSkdaZd1ssrg5u9AEQStWU/P+gAvIP5xY+EE9GPsOS1ho/hJWMqcL7jT
	y08g6Gw+Kzu/tZegkYQFApZ01RTgPl+drmfZWsZ6dPhaKQMYLZVhcL72dIbsTjh8O+wY8QflQMv
	keFp1NQyNA9jhrQmTx2OBk4lNBrWbfNHiMwZZcZjvI4Uqnk/PkuNGFNBNSl1CqV+OekT4Ld9hpG
	Dzfc97aqEFt20Nj/ncwdcUTv8wLRkNeSwvRL9Zw11w=
X-Received: by 2002:a05:6000:65b:b0:47f:943a:45fa with SMTP id ffacd0b85a97d-481607c0725mr42091138f8f.29.1786983040513;
        Mon, 17 Aug 2026 09:10:40 -0700 (PDT)
Message-ID: <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
Date: Mon, 17 Aug 2026 18:10:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
 <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1786983041-666B72AC-4AA59E4B/10/73395122804
X-purgate-type: spam
X-purgate-size: 3693



On 8/12/26 5:48 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/traps.c
>> +++ b/xen/arch/riscv/traps.c
>> @@ -191,6 +191,67 @@ static void timer_interrupt(void)
>>       raise_softirq(TIMER_SOFTIRQ);
>>   }
>>   
>> +static always_inline unsigned long get_faulting_gpa(void)
> 
> May I suggest to use always_inline only when inlining is _functionally_
> required?

Sure. But it ins't clear to me why it isn't a case here? Is it connected 
to that function is static and too simple so a compiler will do by itself?

> 
>> +{
>> +    /*
>> +     * According to RISC-V spec:
>> +     *  18.2.8. Hypervisor Trap Value Register (htval)
>> +     *   ...
>> +     *   A guest physical address written to htval is shifted right by 2 bits
>> +     *   to accommodate addresses wider than the current XLEN.
>> +     *   ...
>> +     *   If the least-significant two bits of a faulting guest physical address
>> +     *   are needed, these bits are ordinarily the same as the
>> +     *   least-significant two bits of the faulting virtual address in stval.
>> +     *   For faults due to implicit memory accesses for VS-stage address
>> +     *   translation, the least-significant two bits are instead zeros. These
>> +     *   cases can be distinguished using the value provided in register htinst.
>> +     */
>> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
> 
> Well, okay, but instead of not losing the bottom two bits you're now losing
> the top two ones.

Oh, right, I will add a cast ((uint64_t)csr_read(CSR_HTVAL) << 2) | ...

It will cover all the cases RV32 which has 34-bit guest address and it 
will be enough for RV64 where GPA is 59bit (the highest possible for Sv59).

> 
> Also the spec reads as if htval only _may_ hold the original address of the
> faulting access. What if htval ends up 0?

good point. then we have to emulate fault instruction and get an address 
from an instruction. I think that for now it will be enough just to 
support platforms which always write GPA to HTVAL.

If I understand correctly if htval is supported by platform then htval 
will be always filled for guest page fault. To verify if HTVAL is 
supported we could do:

'Unless it has reason to assume otherwise (such as a platform standard), 
software that writes a value to htval should read back from htval to 
confirm the stored value.'

And is it true because:
```
A value of zero in mtval signifies either that the feature is not 
supported, or an illegal zero instruction was fetched.
```
(yes, it is about mtval but I asssume that htval has the same behaviour').

Otherwise if it won't work then we can't distinguish if it is zero 
because h/w doesn't update htval or it zero because faulty GPA is zero.

So we could add this check under #ifdef CONFIG_DEBUG here and if HTVAL 
isn't supported then we can't work on this platform.

> 
> Further, nit: There's (once again) no real value in the 0x prefix, I don't
> think.

Sure I will drop then.

> 
>> +static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>> +{
>> +    return -EOPNOTSUPP;
>> +}
>> +
>> +static int emulate_store(unsigned long fault_addr, unsigned long htinst)
>> +{
>> +    return -EOPNOTSUPP;
>> +}
>> +
>> +static void handle_guest_page_fault(unsigned long cause,
>> +                                    struct cpu_user_regs *regs)
>> +{
>> +    unsigned long addr;
>> +    int rc;
>> +
>> +    addr = get_faulting_gpa();
> 
> Can't this become the initializer of the variable?

Sure, it can. I will do that.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 16:19:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 16:19:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393114.1632009 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww03s-0002Aa-JH; Mon, 17 Aug 2026 16:19:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393114.1632009; Mon, 17 Aug 2026 16:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww03s-0002AT-GM; Mon, 17 Aug 2026 16:19:44 +0000
Received: by outflank-mailman (input) for mailman id 1393114;
 Mon, 17 Aug 2026 16:19:43 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1ww03r-0002AN-0q
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:19:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww03p-003XRs-VM
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 18:19:41 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a833482-bab6-0a2a0a5309dd-0a2a450c848a-12
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:19:41 +0200
Received: from [40.93.201.50]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a83349c-f479-0a2a450c0019-285dc932276a-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:19:41 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA1PR03MB7074.namprd03.prod.outlook.com (2603:10b6:806:33b::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug
 2026 16:19:38 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026
 16:19:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZiUDlM/TqwMRKOmabTwGi6/bwtU4Vdi01BLTLiSS4R1Yt6MkcpF+/6Y5KyQpbWRnAf4IaHnkie3ft8cT007YeibGZZPYYb9Q6mwdVlGCSeFD6iUCls27s9AB26gtMkI19sCL08OE570YsdhO25LVfaooqjWjF1+N6NU9lIx9WTzU0AM4KFCKCvN+YiZdTZZjSPpZGNyZ/wfgeZRd8KFwKz9vl9Q6Tkh27R/HALPIHyisg6cBH1mt02wjGGqv3JAngxFgTVZmVBItXusXu88diTujzBhkudWgLfpQhWSsI1c8X/xXF9f0gGt8UIMJPZksPf5HAy6MdkMQufJeNwDcgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=I+rCYubIYCA+/98dtToTiiG2983eNW+kp9TEJmrHWMk=;
 b=WIbk2h13RsVgZDW20ujV8JBbHCVn8ScaD40Iv29IF6KkSE8vtYwt56AZKkuV16v1HqrIyhOQNMbeEvckT0HgthQ23LVkgEu67SYJBiEvd1kpCpgWbaRCLdLC2umhd4S9Frm91J7vLKObdlErvzO8JfSRzP0zDgkTHZOkdOnRM4Eg+Z/PrhabfVcUttplw0m56X51koOiFWlpS8r6l/ncLUxNj2znS9wsgfLDaILFFoCrBr2N3CXwl6tBcElEnw4528XuY9xzJ/SJ22Tp1eH3qhodhP5sMgxp+fk84BNwT6LLPceR2rh9tXwqIJgU8WW7X/WCaL2Jqu9jqFb9N88yYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=I+rCYubIYCA+/98dtToTiiG2983eNW+kp9TEJmrHWMk=;
 b=XepI+jamsQGDDXuWLpOtEZZbxCdXDQjjBoNZZ302z2Rbqrddrr+/ZgUmOa/hgsqdIkkRSHJahRvdnxUno5+nRH1HMtDhpZ+wm97WDDyQvtRjqCSBSbLhA0ymKvMgEXw3FF3B26ee1vd3u79ce3ZO5zn3a3S0MMk5xgTzRmK33no=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <9d7ecb39-e2a9-4433-a051-29efc5c682f3@citrix.com>
Date: Mon, 17 Aug 2026 17:19:34 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/5] x86/nmi: Misc style fixes
To: Jan Beulich <jbeulich@suse.com>
References: <20260805124525.105457-1-andrew.cooper3@citrix.com>
 <20260805124525.105457-4-andrew.cooper3@citrix.com>
 <3e414c79-26cd-4fe4-a48e-73d80b02b4e2@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <3e414c79-26cd-4fe4-a48e-73d80b02b4e2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0479.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a8::16) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA1PR03MB7074:EE_
X-MS-Office365-Filtering-Correlation-Id: 27da3914-8a17-4aeb-9f46-08defc7b5595
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|10067099003|4143699003|5023799004|11063799006|56012099006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	J4Cs94d8A7AfJtqsCh073qeCmm6dfUS91NkjIjD6gUH15p9wAbfXDTT3JceqAKZh0yu+5i87yyqpvii5aW25Xd/O1Ny6qjSq25wFX7S8cgBS44IP5950JSaTT0fU4cepSxIdu7sE+uigMr9K32NNuX+Mw6qRz5XE9wZqnWpEls+7oVacS5EJ3UmE06bBgqPClZyQAl3iQ/B32qaUQYrtegSGApGaRQ4Y5JN3iuIkU2Vxyr3h65eyLNqXVB8satlffCdJ0QJFepQyvE98hAP6jmth+OPoNnyQzsBzVUSqO/n0IzgcEQe4bF4P8r5/blj02yjZOkpMGWxBTd0S2gF3bGYam1wZIiskHhuofeNA807KiIwIc8/DSVSk9U9sIdGWPtpso1Zo6fxoZVKZwudk7n3auWGGOPU6D7uVV6EFwkMBIl8bNX+cm5cj9xxXTuw192WGSrYYhgbgU98w+2t6h52JM/+GEGA3RsrfhXs/SbHlAGF4ZOfAg0a5h1nwmeb/cPSYdQskDFr4xiYCWNDiO7gHX+izTy7Q500Ssaf/pJ7hCj93VcJTDFAkscG0698nci/S+W9uuS/TNjuNcm/R9RMyslr7V/QJ2wQEnjh/Kp3UjZdT24gR4oH0AVv7f+jlKCUVj/492P2MxKdWkddL7T2BKU3zR0U0W9vhIM+1H8Q=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(10067099003)(4143699003)(5023799004)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aG84dTA4VTZOTHVxZFZGNERucEUvRHF1cjZHRE1Wa0ZvRnpITDNzcUhMejZu?=
 =?utf-8?B?NFNSQW1CSGw4c0ExQ0FnSGRsK0VEZng5bGMxMkZRWkFXdStvdFNUcnFkeGVU?=
 =?utf-8?B?cWE2dlAySkdIdGVsS3lXWXlWQVJWS2RxYVFnWlV3TUFMVWRJWG1yWGRaZ3pN?=
 =?utf-8?B?VzlGaGF3ZEZWZ0Q3ZmNDbERRQkczWE1xb1NQUnNSYXFvdkVWSngzWGQ4NWNJ?=
 =?utf-8?B?eGNCZ2dDTWZsRmtvQi9FUkxrQS9oUzk3RUgvZGpBRVFJN3RQTlJDeFNVN2Zx?=
 =?utf-8?B?NWZrQTNxNUhzenJ0YXM3Q1NIVGlnTlZwbWNRaldUNFJpei80bm1ZdTQrNjhH?=
 =?utf-8?B?SVBMZGtvYVZXMkxYSjRSMDI3UlpISmQxKzlTR0VDdFVRbktoTU5PbVV3eXBC?=
 =?utf-8?B?b2xKYmdXUDJMOFVKKys4ckpJdFUzaUNZSFJkYmtpQmMwNVJyT3dLbi92azdR?=
 =?utf-8?B?azh2YWNaNnNuVi9tNmVDME1PSkkzamRNN1UxSGNhQ0pVOTJJZGRqc0wwU3J1?=
 =?utf-8?B?Yy9DeVVHN05UY0hLTmhreTFJbVlHTzZBajNmVjR3aDBHbkdDNmFFRSszcXZm?=
 =?utf-8?B?TWhxYW11S1l3SkFzQmMxK3RXTmxPdmtnNmNGM0liK2ZncCszQkJhMThXN1JX?=
 =?utf-8?B?WkJVbnF0NFBUNXhySEUwRW0rbVhpOW54cnMzeWxZNklnSmcySTgxRmFJeUdm?=
 =?utf-8?B?SFpOazdhWnBsWEdZdkJ5WVJobTZTVzJsb05TZEhlVGlKNVFwQTJ3NjFMSU1s?=
 =?utf-8?B?Y2EyZVBnVUtVMUZ0WGlkUUFyemlpdkhXNFErQWVHWHFUSWJhYjNZS2h5R0FN?=
 =?utf-8?B?Z0tEYTBQVVBrOVI3V1lsOWNSNG5Jd0tUZVhrbnlWYjFEQ2xUcUJWZTdPQWRr?=
 =?utf-8?B?RGRIVXZ5clc2N3F5WHpPczJTT3JHSjZPMkF2MVVDeHQ1V0tVaHRjZTNuNDlF?=
 =?utf-8?B?enhRZ1FCakRTdHVLMGJKVTlNZk5JYUpUS3FIQ2hNSmdXZEhoN0owY09qd3dR?=
 =?utf-8?B?NzRFaFFVSkczQlVYNTUzWXI2Z2VxNmxpbWM4R1V1bDhrUGNIdHAwTGZOcWlF?=
 =?utf-8?B?QklucTEvMzVrQzM1R2pqVjgxVG1GWjM0aEs1QTE2RzZPWFNTTDFkcEVzS0lr?=
 =?utf-8?B?TTc2Qkl2L24xSGNybzl5OE1DbUdZMUlxQ3ZSZXpwb3BPRXF0U2tnRG04OElM?=
 =?utf-8?B?TVdXSmowT3VWM0VMYXcxMWJ0VE5ZWVJ2ckdiUHROS3RSWnpMb1A3VjRuWkhX?=
 =?utf-8?B?b0VvMisrMHZpS0krTWdVajdsS2wvVkRUcnBBZlFPeVJCcUllejVKZHp3MWVp?=
 =?utf-8?B?Wm1OWWhSbThZWDQ5RkdvR2JQM1o3ZFBtT0o2MUllLzRKSUhKMVl2Niswc1Ba?=
 =?utf-8?B?OEhSZ0FGWDdaYUYyMzJGakU2WFh2V0d1VTRIVWphc1NkS2J1UHBVbHNSZ0Zh?=
 =?utf-8?B?VE9JOWI2NVhkNENGRlEwWU1nUXczUFFxOXJrL00wR2ZpUzJ2ckptL1VFQU5H?=
 =?utf-8?B?MUdKa1I3MytxWXdoOERzQ3lQYVhyQ2lPRkZRVFV2STVnNzVkaWpQWWRpTDVl?=
 =?utf-8?B?M2RHbWpweTdnNVhaWjJyd01nU0E4d3ZFNGVSc3pKc2U1VlBwbzlNV3hIV2tD?=
 =?utf-8?B?NDhRRlkvaHVUbU1mcXlLc083aS9mMXVCTGk4K2lLWThpYUVRb0tJTWZRRVQ5?=
 =?utf-8?B?NmhNUDU4bXlaZjhiQUk4NnhaUHVnWWVWOFlJZFQ3cTdFbjhuQmYyZStVR2RB?=
 =?utf-8?B?UTJ2UURZTmJSL0FtNFNXVGtPNVZlalpoeVBadlNrYXBGZ09tSjNDMmlYUkd4?=
 =?utf-8?B?K3dYOURtaWJQeFlvWVRLZ1RUZnA4T0UxZm8yL2lxck5SQVBGU01wTFhTMFpl?=
 =?utf-8?B?NWpUY3FwTnZHRndxNTM0YXRhTXE4a08xQ0UxV2xGUE8xcjZvTThmK0xwd2Nk?=
 =?utf-8?B?SDV6RWFUU1NjTEJhRFdOT0lJQll5Z04wSUtMVi9DNHk1dEJMemZHa0JEUXNL?=
 =?utf-8?B?Q2VNc3lEd1dtelZWSnRKd2NxNkZnSnVHUGhWSVdicm5CeGM5ZGhTeHhZNk9x?=
 =?utf-8?B?WDZzNnhCZjViVGJoMUxBYUtVUmpxVG1sbjZyalRpMFZNZlFHQ3BxbXdUU3JW?=
 =?utf-8?B?R2RTNWRNcTNNVHRsbGdoY210WmxwWWI0UzYwaFRRb2ZTMWZucGd3d25mbitG?=
 =?utf-8?B?aDhoU2dvQjZVVDV6UlhzNGV5SEpkM1N1ZE5ZWEI3VTZ6NTJsMWVTQkJGYWhD?=
 =?utf-8?B?R2RpRjVIbnQzbTJHaWdrenZmQVBqcDI2Y3lSN0RYSy81NDJockg5VjhERlBT?=
 =?utf-8?B?RXV6VGFqWEZ3TGpyR3N3ZHlOTWxmYUFESGpBd3lYVGM3VlBXUzRCQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 27da3914-8a17-4aeb-9f46-08defc7b5595
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 16:19:38.1865
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /NHzZMNjrTMtKzlVEzUniKOKmlhQKO0ICJwqdr5E56MoOSzznaMofgcTtDpFpb3ACAsLdDV2fpPUX1W8GqJpZcsJcA6CmaQ1tDtI9I6bexw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB7074
X-purgate-ID: tlsNG-d25034/1786983581-51538A5B-DD141510/0/0
X-purgate-type: clean
X-purgate-size: 1443

On 05/08/2026 2:52 pm, Jan Beulich wrote:
> On 05.08.2026 14:45, Andrew Cooper wrote:
>>  * Drop trailing whitespace
>>  * Sort includes, dropping asm/mc146818rtc.h and asm/div64.h as unused
>>  * Brace position, and types
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

> albeit I would have suggested ...
>
>> @@ -310,15 +308,18 @@ static void setup_p4_watchdog(void)
>>      if ( boot_cpu_data.x86_num_siblings == 2 )
>>          nmi_p4_cccr_val |= P4_CCCR_OVF_PMI1;
>>  
>> -    if (!(misc_enable & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL))
>> +    if ( !(misc_enable & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL) )
>>          clear_msr_range(0x3F1, 2);
>>      /* MSR 0x3F0 seems to have a default value of 0xFC00, but current
>>         docs doesn't fully define it, so leave it alone for now. */
>> -    if (boot_cpu_data.model >= 0x3) {
>> +    if ( boot_cpu_data.model >= 0x3 )
>> +    {
>>          /* MSR_P4_IQ_ESCR0/1 (0x3ba/0x3bb) removed */
>>          clear_msr_range(0x3A0, 26);
>>          clear_msr_range(0x3BC, 3);
>> -    } else {
>> +    }
>> +    else
>> +    {
>>          clear_msr_range(0x3A0, 31);
>>      }
> ... to instead drop the figure braces here.

There's an easier fix.  Model 3 was the first 64bit-capable P4.

I'll do a separate patch to take out the entire else clause.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 16:24:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 16:24:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393124.1632018 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww08i-0003gM-4F; Mon, 17 Aug 2026 16:24:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393124.1632018; Mon, 17 Aug 2026 16:24:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww08i-0003gF-1K; Mon, 17 Aug 2026 16:24:44 +0000
Received: by outflank-mailman (input) for mailman id 1393124;
 Mon, 17 Aug 2026 16:24:42 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1ww08g-0003g9-DB
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:24:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww08f-006VoA-DG
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 18:24:41 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a833596-bab6-0a2a0a5309dd-0a2a45018ae6-34
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:24:41 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a8335c9-5984-0a2a45010019-d155dd2ded97-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:24:41 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47ddf7b09e5so3684274f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 09:24:41 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a7c568sm5176015f8f.18.2026.08.17.09.24.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 09:24:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786983881; x=1787588681; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=jE5KjnNcwYC3J+TyGV7Y75JAuXasrwsc9h5J/vaOkf0=;
        b=Ii3/9G6z5ZrFnzHUpSJ1FQnfVRV8cGgHoFdTjmoZfQy805h7zGJpJweGtiY/SiTOFx
         Ls3Jo0g9FFKa2ZqttFW4LJs2b8+F9LDDIdt1U6wgJWOD/4BM9jbDmDpzrM+HSAgYdBKb
         T4utxmRdxsrMDC5y1ssc6kcLfFZMt2bT3wQys=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786983881; x=1787588681;
        h=content-transfer-encoding:content-type: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=jE5KjnNcwYC3J+TyGV7Y75JAuXasrwsc9h5J/vaOkf0=;
        b=UGKAl7a0rI/p5SpXjmkc4NaFD2mi4MTmTN1AUbMg+AcXQyk18qCO94GWOm6oojJX3B
         dspu+hQzL8zVxUsPDuAys2TapLhk0DayjxQrQ+ge7r9x2BTK5rgfjw+ljnmfCFQF6GaJ
         I3M08gKVG72E9u3Gg9k5T/b5snGK8lVWuMEIkWuLSPEhTcyOpYORTnzzB3Hk9ZVB8NK2
         v4WwN3AKjqiqVwLZUVA9T8bcpiVGHxhrbwwoZnSbaVvkl+OseJtyvsnLeb+abC0A4LxV
         Yea/Na7E6voCtOqE6t34lT2TH0kgueUWNELf3PxlrzKehYqTcOjA8QdUOpsmf6hCOCPX
         MkbQ==
X-Gm-Message-State: AOJu0Yy0DnVNvOSMRZX/JPpDcqLGK+/ARuRupfQtKSrgwjKXfq/NQoHa
	YcbXvpEriOO42nVVcE2UHsVL6nOsHDztTJSWJ9VZ+nh8aa41HgJiHL8O7hm3VOmW1NaxMdwG5Hc
	/I91ggWE=
X-Gm-Gg: AR+sD10LVLaCb/YGnAnE6IZHe+nfwWjVKtSSdhvKuDkZAtAKtq/yGxWHU4TwehE1FUq
	e88RcfZUrH2NdnB/+nCE/1wxAVZqusPw0U6MxEySIWzc6x0kzLpAiDE0xM0Fa8kokcfBi/c9EMh
	XfRSYBzHN8XFLAncdP4ToOPwmcIpsajGtFUBxpG+WmzsCUaip2XoxcqHjt9NPefAZL7d7b326S2
	41PY2SRjBsq9+sE2rHiSxvqv1dThzExB6RkeO7XwBYEyPrqQ7+u8Z138BcXf1KV6SC+oQWnjcLG
	R8f4NUGRRYsRAKHmQziKz0R7lpbi5CwLo19hSQRo3pQuJGjm2Cw6I28E1gSqcn4XmLAjtY5ltkz
	S8S1ghssKv0IjBbLmogJFP33runQUOBvrA59MZCCm+B7u+zHiUemYsvuwIy25HSl/HRUU6BNR5c
	tjsKRX7WbXf6DC9FwY78mA8tLIs9ojdQuhNRzuCF0HgEmq3aw9D/eQgdfD+ewEVSQCiR0yNWqBo
	r/bfb/K3sk2uwjTDN7X2iUpYL/cavgdxJRpgz8=
X-Received: by 2002:a05:6000:46cc:b0:47f:f3f9:ae37 with SMTP id ffacd0b85a97d-48160705704mr28763963f8f.7.1786983880510;
        Mon, 17 Aug 2026 09:24:40 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 2.5/5] x86/nmi: Remove logic for pre-64bit Pentium 4 CPUs
Date: Mon, 17 Aug 2026 17:24:32 +0100
Message-Id: <20260817162432.1833803-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260805124525.105457-3-andrew.cooper3@citrix.com>
References: <20260805124525.105457-3-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1786983881-C5540757-78FDC8B9/0/0
X-purgate-type: clean
X-purgate-size: 1264

Model 3 was the first 64bit-capable P4.  Xen won't be booting on anything
older, so remove the condition.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/nmi.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index b71bf4363586..d614641386c7 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -314,13 +314,9 @@ static void setup_p4_watchdog(void)
         clear_msr_range(0x3F1, 2);
     /* MSR 0x3F0 seems to have a default value of 0xFC00, but current
        docs doesn't fully define it, so leave it alone for now. */
-    if (boot_cpu_data.model >= 0x3) {
-        /* MSR_P4_IQ_ESCR0/1 (0x3ba/0x3bb) removed */
-        clear_msr_range(0x3A0, 26);
-        clear_msr_range(0x3BC, 3);
-    } else {
-        clear_msr_range(0x3A0, 31);
-    }
+    /* MSR_P4_IQ_ESCR0/1 (0x3ba/0x3bb) removed */
+    clear_msr_range(0x3A0, 26);
+    clear_msr_range(0x3BC, 3);
     clear_msr_range(0x3C0, 6);
     clear_msr_range(0x3C8, 6);
     clear_msr_range(0x3E0, 2);
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 16:37:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 16:37:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393131.1632027 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww0Kq-0005Wv-5h; Mon, 17 Aug 2026 16:37:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393131.1632027; Mon, 17 Aug 2026 16:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww0Kq-0005Wo-2G; Mon, 17 Aug 2026 16:37:16 +0000
Received: by outflank-mailman (input) for mailman id 1393131;
 Mon, 17 Aug 2026 16:37:15 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1ww0Kp-0005Wi-O5
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 16:37:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww0Ko-0099ew-Cb
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 18:37:14 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a833885-bab6-0a2a0a5309dd-0a2a450c8b8a-34
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:37:14 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=MkDe=GK=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a8338b9-f479-0a2a450c0019-8c4da68ab6b6-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 18:37:14 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id B9E60A1AB6;
 Mon, 17 Aug 2026 18:37:13 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id O95i-BvYQ_GZ; Mon, 17 Aug 2026 18:37:13 +0200 (CEST)
Received: from end (lfbn-orl-1-1611-126.w90-107.abo.wanadoo.fr
 [90.107.165.126])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 856E8A1A90;
 Mon, 17 Aug 2026 18:37:13 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1ww0Kn-0000000Crmt-0NVk; Mon, 17 Aug 2026 18:37:13 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786984633; bh=ZWx2q5QHX8DeCiM3ATZX3m7E39EtQ/oytXNyWT0yTKs=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=gJ80pqWHW8AOgE6jhXEMsLjSDqkwouFYkH3ww7O3BshFBKr+04plfmXrTsydBQLAa
	 iXUP+Z73QDzfh8upufYwQ3yKRmdO8uJc38pgaYc8HWidTUGatXDlweN/O+mlciPW1B
	 9Y44qHXty9pNlKnzxeZaIy5xJ0ZfOvAW/o/mAh0ArpVsgp7QvOVGB3bUKdax8/DI8e
	 RHuGDIyqfJi1v+iLDLOseA66wdSAxCywbbN2QPXdPCDXnhAnj115nyRleyf8bHBsbS
	 dvJOdhDfCcfPBwhEI8EIvjci+5n/+iP03D1aNMsxyB29Nmbswpz23zrW4DymaIMmqa
	 0XOuorsTHV5hQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1786984633; bh=ZWx2q5QHX8DeCiM3ATZX3m7E39EtQ/oytXNyWT0yTKs=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=gJ80pqWHW8AOgE6jhXEMsLjSDqkwouFYkH3ww7O3BshFBKr+04plfmXrTsydBQLAa
	 iXUP+Z73QDzfh8upufYwQ3yKRmdO8uJc38pgaYc8HWidTUGatXDlweN/O+mlciPW1B
	 9Y44qHXty9pNlKnzxeZaIy5xJ0ZfOvAW/o/mAh0ArpVsgp7QvOVGB3bUKdax8/DI8e
	 RHuGDIyqfJi1v+iLDLOseA66wdSAxCywbbN2QPXdPCDXnhAnj115nyRleyf8bHBsbS
	 dvJOdhDfCcfPBwhEI8EIvjci+5n/+iP03D1aNMsxyB29Nmbswpz23zrW4DymaIMmqa
	 0XOuorsTHV5hQ==
Date: Mon, 17 Aug 2026 18:37:13 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
Message-ID: <aoM4ufGg8QO51XB9@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com>
 <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-d25034/1786984634-5290EA5B-8FA1C616/0/0
X-purgate-type: clean
X-purgate-size: 936

Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
> On 17.08.26 09:48, Samuel Thibault wrote:
> > Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
> > > There is no user of libpci left in stubdoms.
> > > 
> > > Remove libpci from the stubdom build system.
> > 
> > Wouldn't it be useful to keep this for anybody who would want to drive a
> > PCI card from a stubdomain?
> > 
> > I mean, in the zlib case, it's really a mere question of build & link,
> > so we don't need to ship it, people can do it themselves easily like for
> > any other library.
> > 
> > But here there is actual porting work, that we'd better not lose but
> > keep shipping.
> 
> This is all still available via git.

No, it is not really.

I keep reading this argument, but people will not know that something
exists in the git history, and will just assume that it does not exist
and has to be written.

Samuel


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 17:04:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 17:04:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393142.1632036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww0ke-0001GI-3k; Mon, 17 Aug 2026 17:03:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393142.1632036; Mon, 17 Aug 2026 17:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww0ke-0001GB-0g; Mon, 17 Aug 2026 17:03:56 +0000
Received: by outflank-mailman (input) for mailman id 1393142;
 Mon, 17 Aug 2026 17:03:54 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1ww0kc-0001G5-S6
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:03:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww0kb-009Cj2-Nl
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 19:03:53 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a833ed9-e002-0a2a0a5209dd-0a2a450ae7b6-42
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:03:53 +0200
Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a833ef8-f2d2-0a2a450a0019-a0658309d3f2-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:03:53 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id B578A82E3127;
 Mon, 17 Aug 2026 13:01:57 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Subject: [PATCH v4] x86/nSVM: Validate the L1 IOPM physical address range
Date: Mon, 17 Aug 2026 17:59:56 +0100
Message-ID: <8302fc9800d6d5ffe8341ccf1a5f8cc0ee19540c.1786984508.git.abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1786986233-536D6CFC-77FDC0BC/0/0
X-purgate-type: clean
X-purgate-size: 5216

The Xen nested virtualization code does not validate that the physical address
range assigned by the L1 guest, for IOPM, resides within the valid guest
physical memory. Add a sanity check to properly validate the IOPM is in the
valid L1 guest address range. This check also makes the behaviour compliant
with the hardware handling of the assigned address. The hardware is expected to
trigger VMEXIT_INVALID if the address of the last byte in the IOPM is greater
than or equal to the maximum supported physical address, see the APM
volume #2 (40332—Rev. 4.40—July 2026).

While at it, clean up the code. Remove the unused bool viopm and the
svm_vcpu::ns_oiomap_pa. Change nsvm_vmrun_permissionmap return error from
literal 1 to NSVM_ERROR_VVMCB.

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Changes in V4:
- Replace the IOPM_PAGES_COUNT constant with an expression calculating the
  actual page span of the IO permission map.
- Rephrase the commit message to better describe the changes.
Changes in V3:
- Switch to using gfn_valid() instead of domain_get_maximum_gpfn() to align
  with what is told to the guest in the CPUID.
- Drop MSRPM validation as it is already validated.
- Change nsvm_vmrun_permissionmap return error from literal 1 to
  NSVM_ERROR_VVMCB.
- Remove parentheses (IOPM_PAGES_COUNT - 1).
Changes in V2:
- Rename IOPM_MAX_PAGES_DIFF and MSRPM_MAX_PAGES_DIFF constants to
  IOPM_PAGES_COUNT and MSRPM_PAGES_COUNT.
- Drop the 2-pages for domain check.
- Change the IOPM and MSRPM boundary checks.
- Use gaddr_to_gfn instead of open-coding >> PAGE_SHIFT.
- Use __func__ instead of hardcoding raw function names.
---
Testing:
 - Using a locally developed XTF nested virt setup, I manually tested VMRUN
   instruction handling with the address value (0xffffffffffffffffUL) assigned
   to VMCB::iopm_base_pa:
   - Without the changes the address is mapped by the Xen code to the address
     0x604b634000 and it completes the execution without any reported errors.
   - With the changes, the VMRUN execution fails and VMEXIT_INVALID is reported
     back in the ns_vmexit.exitcode.
 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2766682638
---
 xen/arch/x86/hvm/svm/nestedsvm.c         | 18 ++++++++++++++----
 xen/arch/x86/include/asm/hvm/svm-types.h |  2 +-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index b06124c2c9..b176e6000a 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -282,7 +282,7 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
     return 0;
 }
 
-static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
+static int nsvm_vmrun_permissionmap(struct vcpu *v)
 {
     struct svm_vcpu *arch_svm = &v->arch.hvm.svm;
     struct nestedsvm *svm = &vcpu_nestedsvm(v);
@@ -294,6 +294,17 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
     enum hvm_translation_result ret;
     unsigned long *ns_viomap;
     bool ioport_80 = true, ioport_ed = true;
+    /* IOPM is structured as a linear array of 64K+3 bits. */
+    const unsigned long nr_iopm_additional_pages = PFN_DOWN((0x10000 + 8) / 8 - 1);
+    gfn_t ns_iopm_end =
+        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), nr_iopm_additional_pages);
+
+    if ( !gfn_valid(v->domain, ns_iopm_end) )
+    {
+        gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n",
+                 __func__, ns_vmcb->_iopm_base_pa);
+        return NSVM_ERROR_VVMCB;
+    }
 
     ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
 
@@ -302,13 +313,12 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
     if ( ret != HVMTRANS_okay )
     {
         gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret);
-        return 1;
+        return NSVM_ERROR_VVMCB;
     }
 
     /* Check l1 guest io permission map and get a shadow one based on
      * if l1 guest intercepts io ports 0x80 and/or 0xED.
      */
-    svm->ns_oiomap_pa = svm->ns_iomap_pa;
     svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
 
     ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT, 0);
@@ -418,7 +428,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs)
     n2vmcb->_tsc_offset = n1vmcb->_tsc_offset + ns_vmcb->_tsc_offset;
 
     /* Nested IO permission bitmaps */
-    rc = nsvm_vmrun_permissionmap(v, clean.iopm);
+    rc = nsvm_vmrun_permissionmap(v);
     if ( rc )
         return rc;
 
diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h
index 8acadb9dcc..beab9a3af2 100644
--- a/xen/arch/x86/include/asm/hvm/svm-types.h
+++ b/xen/arch/x86/include/asm/hvm/svm-types.h
@@ -51,7 +51,7 @@ struct nestedsvm {
     unsigned long *ns_merged_msrpm;
 
     /* guest physical address of virtual io permission map */
-    paddr_t ns_iomap_pa, ns_oiomap_pa;
+    paddr_t ns_iomap_pa;
     /* Shadow io permission map */
     unsigned long *ns_iomap;
 
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 17:04:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 17:04:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393156.1632045 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww0lW-0001mr-FE; Mon, 17 Aug 2026 17:04:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393156.1632045; Mon, 17 Aug 2026 17:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww0lW-0001mj-BL; Mon, 17 Aug 2026 17:04:50 +0000
Received: by outflank-mailman (input) for mailman id 1393156;
 Mon, 17 Aug 2026 17:04:49 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1ww0lU-0001mT-T9
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:04:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww0lU-0009Fr-9o
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 19:04:48 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a833f0c-8faa-0a2a0a5109dd-0a2a450b97ac-48
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:04:47 +0200
Received: from [98.137.64.148] (helo=sonic301-22.consmr.mail.gq1.yahoo.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a833f2e-b7e8-0a2a450b0019-6289409499b9-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:04:47 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Aug 2026 17:04:45 +0000
Received: by hermes--production-bf1-54b5569bdc-z2x8g (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 4afd9ff1b6f04a95f703b0a0ed0588a5; 
 Mon, 17 Aug 2026 17:04:42 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1786986285; bh=dKCFa0rAtVsUjE9N0GIBIR9kWQqOCx0gZuyJuHmbClo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=EqZOWt9rp4kr0xE2+G240h12ep/4D5tUP+5FXxkaZ1NfbAL3rb4KK97DNfN17zwYTw5eeQy1fsUZSLE1A3qSQ+xy/6nlDiRTB6wZCrUzFlVk6fcEWN3tXrnvVyLQMnA223VBlLIoK7zE65XXhn//Pwb+NoDPn00GCQaZ/Bp3TyL0tm5R4EtLy7D/pcPpNXr084zJoXKV6Aq0m7xd+KUTBmJXJ8KsUY9mOvyRfGgvRt/jZT4aeSIYZx/RG4u8IX1HgvpColO+mPO/UxeudL5p2w+dSrOEWXFQ7OJt9vweon9cASxJcW2xz1+ItJ/yaeVRMeYMW7+I/am6pN/nubBWNg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1786986285; bh=YMugPLm0BjCU7MzeFkJmnzvlixlt5tHRiUI8AtnehZj=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=pVAIs/n/5HfDadYtzdPAISb2JmvqXAfHszFD0aFOVzqEL9uj7rlw+sKTGrdSeo3NHxSJ1U7sJzwNWg6O1km3V54b8RLs4/z4iEpFU0pxUpnk/l9/Hrm55fE+oOpb7t8kPVY0FhyK5L8hSHWsFeVDTnc+ykxVzzeG6SWMJL6DOOAbXtr8+D3vafz6fYYmrmksfT6NcZnVn8V8jnIJDXrI02NSxpN0uqKQ0Wiv5LD56BQG+mYkYMRHvNJ0v0v5WW+olSUXhKQikmfla9ppedw36JomjFROlpcf+6ttFwq1nIKLx2GW8ckV56t1kM2QoS/xEKie2vVlolK2A3v1CG8w7w==
X-YMail-OSG: qSONq3sVM1lckBhJ74iZ_Z7xf9_0ur2G_QgE9cGPHyXXRxNvzRf1aEJVjOFkw7x
 PF7bIk4ER2Wx4tCOVE2X4uMYtNGYr36nirrlNrwNQmrE358mu.AWMi5eo6J4a2N5q8GcfRlhfab3
 mEBsoU_ZkZrSz72cvAUw7rSGilF6ZnG_kkPAIkoK1odJCmrBTtLKNL.PcT1Z4Z3IDu4zNQGEyevB
 WaiRgL.Uv7jpPQ_t7hVwTiHMMw5tsK0HfKyw.Oja85XY1cf_7wQLJ7Im7qeEjTp11VXRirZvHlKE
 E94d2QCx0LyL9fVEeznDpqjBc9sr_Z3_sruh841JwP0GUXJ45LvDYEYoFfqWehPrh0YrzmUcEYoe
 sVNDgDtphl_3wv2.P5x5i6CQ8VVhcRr6095tzj9dC8_WKCXKYWaJ7KJ529GUrGtKwS126q6.R3fl
 nsrgPYkemmADk2BsChiM0dK1xMwzVuw5sIEUM9fFC.6lNpNb7w4O8B64qNunocAh..1aBHQ8d3pX
 tysL8ITyzrCcUVWJ2WcgyFSnHJnmOd4ppYdk4ZNd_1ejTNKDAkPK2aLBWR7j9iLkwViGAt9tltO8
 Z2Xxa7j5py47pTh7QPpy_RWQ_B4ca324nhg8z4fR7gAF0W9j8HRnTzxCOSS_MyNZdQj1gpg3e1w.
 BYjfDYlc0bZxLPKlEEywWLJOx1rmyEqI4QE3iUMUqO.rrZF5ylnO0ghb1p5xx.4BM5e9q2RKVHGk
 mwBJ8bWl2eFEH3LVVatv55ierRLZX4hV8ZjQuyMysvcD1rC2a5WGktqwwomiFIy8wF_b7KB8t264
 oOiQ0YPxNy8KfAcQeMVaLFHDvdvuG9gN0FNBVYwr_Q2YXYvH._jkvX3xuoGngfpiPstdMvSVfnOA
 PQR1UmMeJzcK7HbYPJy2RwFApfYwLu_Tawlx7xpQXtonSgEkKHadzAeSUFoGr8xzAhND_m_nTgh8
 m8lOVCJjaCD0TDIvYu1ufDLozYdtXal_0RaLlMYJ2ddk2wYoIXCA6D2Xgt.TczkVMK5C8iWi_eWk
 o9yd50PRUl95terARdX_TDAl6wNXT5GQLbwlj_DYtVe3wZU21NxLId_QV1BpO2Ve1ZwxFlUaHazr
 XwKmLcoBH4huVP6brXd64.6ZpHjcgg5uIRMV7xYZbdBxmAMzZ_FL.QkRLTo6JjArfHR0yxFgYkh4
 Z5SRT9uTE.XhuKmT42tJJkS6mMM53GskKfzi6fgqvMzASjEnGp0kw5NXtcWreL7mjbKWCH2Jpel6
 pG9iJhTurVNJKtMUMQM8tsU3lER9RRFFauPbuh.Oe64.jkVeOMwIXMl_Cn4i7W7CVJow3Fnio3wX
 nuIAQBbzmY0pAM9EU0PwJgNxAa6gguKJOeFxcXJFiDDJQY3Amv4DMm_SZqVyn5rEqJnMt5idRiH.
 x6eIb_tyqedEyQVhVHrbha.AcwNGPPyLfpRowahr6RArwjdr9q.8euyF9kebeysbWVzhrtRUVVNd
 UPRQitf2zR35Okh5NlMvGDXIvGM9j_WbeAI9QJ_r4FsQUae0JlWteTImHuy65i4hkxKsgA2EH2MQ
 v1eS7Tm9KKmrdM7eQjQkD4JG6JRwFZPlePCtnVfWmcqkHCpE_SCUe3pIm99USh9GnUrKsDkS5XyD
 ERWVRUTZdNhqdvbUFNdLTiYPmga3u.WxrLCiBRdx7f85huccBdCUrrf.1Njm9lvnT7bDWhHfCXNH
 rkIFlszzQbMYowQRu19wX0NpVy3hL7l4rst63Vxh.F924N794UxoJ6g9CLt2zrHB7rtktqBmOAek
 vppbYrjz_NJ.QyuD9RqOPDByKLhdSl_4xA9i.XFFJYCxMRxa3UaJ_QsVNaFjxtXM.ErtNmdrXMYD
 B4JDIsk9wk.dk0wr5.bXSpEDwRNMtsUytLu0c8SmY.XUBBmoVZetjUoC1rYRbsVdeb10ysJTsY7i
 C36t6J2p_1OMLimM4zkC3KdhMGjuhtQYzbamprg30._v_mxrkG2f08SPcXlh.p4nqGQZTDlNwUaO
 V7j_S.1w18L_iQiRB73bMtYqJrNi8_Tb269SVyxU62hc8MMw6BDwrEHfv8Wn3sNy7ifj5c2sb3CP
 aW_DjgX2K0UXC0VO4Zr76FPYyUeh7t8Qk6NvVRM4EiIpR930kr3GfSyVeMtXWTDwggwi4X34S36j
 Pndv45hVrDvwZx4vD1ur6gkGPsFoZGD5vcm8M9EeYwUVo9wdPv8pxaF3FIuXNbAYdoCEVYguiWzq
 Tb7UFl9buywcNznLssytPO1mCxZg76p4icFAOiAFRZXdZJQ--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: ab4fd652-7052-4c36-ba60-b8fd1f94624a
Message-ID: <5e2e43f3-812b-47ab-a54d-ae0973e08880@aol.com>
Date: Mon, 17 Aug 2026 13:04:41 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
Content-Language: en-US
In-Reply-To: <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 6035
X-purgate-ID: tlsNG-42698a/1786986287-1B6D29EA-4D0B7644/0/0
X-purgate-type: clean
X-purgate-size: 6185

On 8/17/2026 12:04 PM, Chuck Zmudzinski wrote:
> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>> -- snip --
>>>>>>>>> +    /*
>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>> +     *
>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>> +     */
>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>
>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>
>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>
>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>> by its DM.
>>>>>
>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>
>>>> Can you explain to me how the region becomes accessible to the guest?
>>>> That would then (hopefully) help me understand why the DM would not have
>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>> guest are also assigned to its DM.
>>> 
>>> Currently, in the device model (Qemu) we have:
>>> 
>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>             DPCI_ADD_MAPPING);
>>> 
>>> That statement is in the igd_write_opregion(...) function in the
>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>> 
>>> If I understand our current implementation correctly, this statement
>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>> in hvmloader code).
>> 
>> No, it introduces mappings of those pages into the guest's P2M.
>> 
>>> I don't think this statement makes the host OpRegion
>>> accessible to the device model, though, so I think, if I understand your
>>> comment in an earlier about my patch resulting in what you called a "layering
>>> violation" correctly, that our current implementation is also guilty of this
>>> same kind of "layering violation."
>> 
>> That code, if it can be successfully executed, indeed doesn't grant any
>> permissions (to the DM or the guest). Instead it proves that the DM has the
>> needed permissions to access the pages itself.
> 
> So, are you saying it should be possible, without any patches to either Xen or
> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
> 
> I think I could implement what you proposed in an earlier message and do
> all (or most) of this in the DM instead of here in hvmloader:
> 
>> The more correct thing to do might be for the DM to
>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>> (How in turn the DM would learn of the contents of the opregion is a
>> separate question then.)
> 
> Actually, when I was developing this patch, I tried first to do it that
> way, but the problem was, I could not find a way to get a pointer to the
> host OpRegion in Qemu.
> 
> So, how can I get a pointer to the host OpRegion in Qemu?
> 

I also think that if we use a fully emulated copy of the OpRegion
instead of passing it through, we might not need to allocate space for
it in the RESERVED region and allocate it instead contiguous with the
rest of the NVS region. This means we might be able to avoid needing
to split the REVERSED region in hvmloader/e820.c which is currently
done like this:

    /*
     * If igd_opregion_pgbase we need to split the RESERVED region in two.
     */

    if ( igd_opregion_pgbase )
    {
        uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;

        e820[nr].addr = acpi_mem_end;
        e820[nr].size = igd_opregion_base - acpi_mem_end;
        e820[nr].type = E820_RESERVED;
        nr++;

        e820[nr].addr = igd_opregion_base;
        e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE;
        e820[nr].type = E820_NVS;
        nr++;

        e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE;
        e820[nr].size = (uint32_t)-e820[nr].addr;
        e820[nr].type = E820_RESERVED;
        nr++;
    }
    else
    {
        e820[nr].addr = acpi_mem_end;
        e820[nr].size = (uint32_t)-e820[nr].addr;
        e820[nr].type = E820_RESERVED;
        nr++;
    }

I am not sure this would work but I think the need to map the OpRegion
to the RESERVED region arises from the fact that currently it is passed
directly mapped from the host. I think I will try it out and see if that
would work.

>> This is what the handling of
>> XEN_DOMCTL_memory_mapping has in this regard:
>> 
>>         ret = -EPERM;
>>         if ( !iomem_access_permitted(current->domain, mfn, mfn_end) )
>>             /* Nothing. */;
>> 
>> Subsequently we check that the guest is also permitted access:
>> 
>>         else if ( iomem_access_permitted(d, mfn, mfn_end) )
> 
> 
> 
> 
> 
>> 
>> Jan
> 



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 17:24:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 17:24:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393180.1632053 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww13z-00055t-TW; Mon, 17 Aug 2026 17:23:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393180.1632053; Mon, 17 Aug 2026 17:23:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww13z-00055m-Qk; Mon, 17 Aug 2026 17:23:55 +0000
Received: by outflank-mailman (input) for mailman id 1393180;
 Mon, 17 Aug 2026 17:23:54 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1ww13y-00055f-OH
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:23:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww13x-00AqJI-Ij
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 19:23:53 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a834384-2eae-0a2a0a5409dd-0a2a4506c276-44
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:23:53 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a8343a9-195a-0a2a45060019-d155802da9d7-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:23:53 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4954a9e8490so711395e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 10:23:53 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a7c55bsm5230075f8f.20.2026.08.17.10.23.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 10:23:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786987433; x=1787592233; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=zRlBNNI6Xa6oRSrW4KLRLLjMEyfQSDmzFTllxiPoCsQ=;
        b=nR7dRCjnOKsOuOXKQO5WyTLKp9Dnbx45DfpGrejKr1Ofr91rPMkK3QniPgiUhQUroV
         5elv9QzoON9ouwcBlXgBEaYn8ERK9q6hSmPdqgD3U1pSJCEW9Rr8zbdZ/ef8/kUVsBOR
         Fpj7/CxZMxqTdO2Wh53Wclmx9XjjtVRUJ4J+A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786987433; x=1787592233;
        h=content-transfer-encoding:content-type: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=zRlBNNI6Xa6oRSrW4KLRLLjMEyfQSDmzFTllxiPoCsQ=;
        b=fd0wHOQfSyMvYiZ0b7uGIFSK564ArQQdC0WGbgQrJ12u8etl4fylqwwQj4w4zTo40P
         xKGa9GrbQumJR6EiJlz0iyWEX89HIYmD1vc30YQWlT296Ebu8+sYI8qS5rGeqY5C7voI
         ohmMaTJlIwBcbwbGJDWjcFTazuGaCo5TyNtnIJkh5LB4R2jCus2KfO4glF2jpoWIJ8yG
         2ooF3x7IqF+zAoJIw0zGOoQ3GPUaOMC4wglxNs7nuzV1IXiWrBHaKnlcXFVh+POXJFZN
         5+u/3GGiLtkp5ZzUbdh9DMZBX8Xk+v4//BrdO5g3MQijzlQL3frYysG0iaDHOEjU0mXy
         Pgpw==
X-Gm-Message-State: AOJu0YwmRkDbZXL5apXea5DfmPCSttyWjR2d2w2MQLeuO73uKL+mO4U/
	JUi9cYHnhl8ttNLLGnwydbpzwKmaznEQF7gjTr5dNmMZ39kAZidJqEDC8Oaiv5+WBMwC5wkDtmH
	UvxYRacg=
X-Gm-Gg: AR+sD12dpnSGkXNGPNjEL9L9uGu+u3pX1N0VS2fVJ6Vie4T4t1v7/psQXs3kFLjpel0
	ybjSGALgmwe31eH+GuL96RtTins7PezA1TS9QLfB4qhL+xq0xQELydN43rSjLB6vXkC/bHWK/P6
	NxUFMKx3rLu37w89btQ1jcssXLXZWbdBuAwqRjT6+pk2cUBHHS0uutnQ5EMwLw+UNfB+RsvhZx6
	STYfhOIMvmRNOYKOLBXfhMwSgvj93flf8Wvye8wbfAtVRCQWHx0CYNWrshhakoo7JzskXlYnQaW
	zFKEJ6Y7wl//pXgKxgmyx0+wLKvHGCnFq9SQutV6I6/Uz9x/A7lk9seszWsW4K45rgXT/QgGEf3
	PltQgYOaMxsTRcoQSPnnU6ERr/+4K2mRG8iqoxY6Xj0Dn01I1g38o3IwuKzogRoQlbdXHbmPcdy
	6mZvG1hETnDWT7FNbLYB6ZpX3PyJPk22cXpRFSurkCoTrwBYCTiyyUDV4ugPnc9I/0b46mULJSC
	uUuvKDjkXkAMCJjFp0Wf6ehuVZSbq9DsLtGPgMjNm76v7dhnII=
X-Received: by 2002:a05:600c:34c7:b0:499:8afd:4a9f with SMTP id 5b1f17b1804b1-499a05ac869mr18044615e9.0.1786987432740;
        Mon, 17 Aug 2026 10:23:52 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH 6/5] x86/nmi: Support watchdogs on Intel Fam18/19 CPUs
Date: Mon, 17 Aug 2026 18:23:48 +0100
Message-Id: <20260817172348.1839547-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260805124525.105457-6-andrew.cooper3@citrix.com>
References: <20260805124525.105457-6-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786987433-FC20077B-DC0A1FA2/0/0
X-purgate-type: clean
X-purgate-size: 1355

It is the Pentium 4 (Fam15) which is the odd-one-out.  The counter indicies
used in the P6 went on to be declared architectural, and Fam18/19 continue
using the architectural indices.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

This wants backporting to 4.21.  So does "Check MSR_MISC_ENABLE for all Intel
platforms" on which it texturally depends.
---
 xen/arch/x86/nmi.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index b3d18270b13a..0a03ef68b586 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -329,17 +329,12 @@ void setup_apic_nmi_watchdog(void)
             break;
         }
 
-        switch ( boot_cpu_data.family )
-        {
-        case 6:
+        if ( boot_cpu_data.family == 15 )
+            setup_p4_watchdog(misc);
+        else
             setup_p6_watchdog((boot_cpu_data.model < 14)
                               ? P6_EVENT_CPU_CLOCKS_NOT_HALTED
                               : CORE_EVENT_CPU_CLOCKS_NOT_HALTED);
-            break;
-        case 15:
-            setup_p4_watchdog(misc);
-            break;
-        }
         break;
     }
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 17:27:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 17:27:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393191.1632064 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww16r-0005cI-AV; Mon, 17 Aug 2026 17:26:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393191.1632064; Mon, 17 Aug 2026 17:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww16r-0005cB-6s; Mon, 17 Aug 2026 17:26:53 +0000
Received: by outflank-mailman (input) for mailman id 1393191;
 Mon, 17 Aug 2026 17:26:52 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1ww16q-0005c5-4l
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:26:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww16n-00Cabu-VN
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 19:26:49 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a83442c-8faa-0a2a0a5109dd-0a2a45029fcc-26
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:26:49 +0200
Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a834458-6ca4-0a2a45020019-a0658309d8b2-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:26:49 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id 0B35982E492B;
 Mon, 17 Aug 2026 13:24:53 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Subject: Re: Re: [PATCH v3] x86/nSVM: Check the L1 IOPM_BASE assigned physical address
Date: Mon, 17 Aug 2026 18:22:59 +0100
Message-ID: <20260817172259.2743705-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <0cec914c-e52f-41ee-873b-6bdbc1d1ed82@suse.com>
References: <0cec914c-e52f-41ee-873b-6bdbc1d1ed82@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1786987609-F04A62AC-A0E2E694/14/0
X-purgate-type: clean.empty-body
X-purgate-size: 0



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 17:58:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 17:58:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393224.1632072 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww1as-0001Zw-Gc; Mon, 17 Aug 2026 17:57:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393224.1632072; Mon, 17 Aug 2026 17:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww1as-0001Zp-Dk; Mon, 17 Aug 2026 17:57:54 +0000
Received: by outflank-mailman (input) for mailman id 1393224;
 Mon, 17 Aug 2026 17:57:53 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1ww1ar-0001Zj-6Z
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 17:57:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww1aq-00EUdc-05
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 19:57:52 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a834b87-bab6-0a2a0a5309dd-0a2a450b83c4-14
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:57:51 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a834b9e-b7e8-0a2a450b0019-a0658308d0d0-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:57:51 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 9EE1D4459EAC;
 Mon, 17 Aug 2026 13:56:06 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech
Subject: Re: Re: [PATCH v3] x86/nSVM: Check the L1 IOPM_BASE assigned physical address
Date: Mon, 17 Aug 2026 18:53:56 +0100
Message-ID: <20260817175356.2744006-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <0cec914c-e52f-41ee-873b-6bdbc1d1ed82@suse.com>
References: <0cec914c-e52f-41ee-873b-6bdbc1d1ed82@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1786989471-AB2DC9EA-35F9E115/0/0
X-purgate-type: clean
X-purgate-size: 2452

On ,13.08.2026  10:40 Jan Beulich wrote:
>On 07.08.2026 17:58, Abdelkareem Abdelsaamad wrote:
>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
>> @@ -18,6 +18,7 @@
>>  
>>  #define NSVM_ERROR_VVMCB        1
>>  #define NSVM_ERROR_VMENTRY      2
>> +#define IOPM_PAGES_COUNT        3
>
>This new item is separate from the NSVM_ERROR_* values and hence wants separating
>by a blank line. Especially with the three numbers being in sequence, not doing
>so could end up being confusing.
>
>Considering the constant is used exactly once - do we actually need a constant?
>Can't we ...
>
>> @@ -294,6 +295,15 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>>      enum hvm_translation_result ret;
>>      unsigned long *ns_viomap;
>>      bool ioport_80 = true, ioport_ed = true;
>> +    gfn_t ns_iopm_end =
>> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), IOPM_PAGES_COUNT - 1);
>
>... use a suitable expression here, e.g. PFN_DOWN((0xffff + 3) / 8)?
OK. I will change it like that in V4.
>> @@ -302,13 +312,12 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>>      if ( ret != HVMTRANS_okay )
>>      {
>>          gdprintk(XENLOG_ERR, "hvm_copy_from_guest_phys msrpm %u\n", ret);
>> -        return 1;
>> +        return NSVM_ERROR_VVMCB;
>>      }
>>  
>>      /* Check l1 guest io permission map and get a shadow one based on
>>       * if l1 guest intercepts io ports 0x80 and/or 0xED.
>>       */
>> -    svm->ns_oiomap_pa = svm->ns_iomap_pa;
>>      svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
>>  
>>      ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT, 0);
>
>In the description you say "without any sanity checks", yet
>hvm_map_guest_frame_ro() -> _hvm_map_guest_frame() ->
>check_get_page_from_gfn() won't allow unsuitable GFNs to be mapped. Since
>here only the first page is mapped, some extra checking may indeed be
>warranted, but the description then wants updating.
It (the first page) is actually not mapped. It properly fails. However, the Xen
code continues without any issues. The code continues with an internal Xen
allocated memory shadow_io_bitmap in nestedhvm_vcpu_iomap_get.
>
>As to that part of the description, "directly to valid host address" also
>doesn't look to adequately describe what's going on.
I will rephrase the commit message for better clarity in v4.
>--Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 17 20:34:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 20:34:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393290.1632104 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww420-00056I-Uj; Mon, 17 Aug 2026 20:34:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393290.1632104; Mon, 17 Aug 2026 20:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww420-00056B-S7; Mon, 17 Aug 2026 20:34:04 +0000
Received: by outflank-mailman (input) for mailman id 1393290;
 Mon, 17 Aug 2026 20:34:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1ww41z-000565-Is
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 20:34:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww41y-009Yc6-SM
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 22:34:02 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a836ff4-e002-0a2a0a5209dd-0a2a450685c4-46
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 22:34:02 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a83703a-195a-0a2a45060019-d1558034ed93-3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 22:34:02 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4998b5a63e2so31927075e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 13:34:02 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a7c55bsm6213951f8f.20.2026.08.17.13.34.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 13:34:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1786998842; x=1787603642; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=NdcOM830pkGFrMyGyV5CVvecsj2tsUbGgnES/OJNsnQ=;
        b=XKF5fR+IUHRdfxY0yai0uUU8TXbksQgiF5N0Kk5UpCkFZMz6Sw+Fj9VnvM4BAG9EWV
         iT1qsCRrI6smcrb1LSwf2y7qy/zlwT65m42ctkFet7zaox96YhzW15Ejq2SRRYH2qMQ1
         +PKtXJkaDd+32Nie+znzh4ahUfmvI/QZtJNsk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1786998842; x=1787603642;
        h=content-transfer-encoding:mime-version: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=NdcOM830pkGFrMyGyV5CVvecsj2tsUbGgnES/OJNsnQ=;
        b=Q4YTkJw2+QX37qfbNLIHOFHRKk+AhP9PrQtER6oky7M2CV6NpQaSUcbtdHjTLdCJ8s
         GKSqF9j7Ooj+gFVPMxMV6GMBenFK7RYSXVra0Yfxb00MBIg0RULtOwdtgBvRkQGnoRoY
         gumMITBS5R0QOSaD043dHKh2M0njJpUiQpzJH3Ltf7PorpUab5dwspD9YkJegAsiIJks
         piL2JuGWJp2Zq0obEdXSt9dtRr673e0rvSH6CC1jF0xawbeZQXcUXuMIRMlbKGBTyAYN
         nf+IKmChhzmYYVi8yfJevH2SGgSrg0hj6hE6Jpm8ZjxQI2tNDFQzlnfZxd1Sh9c1wKGY
         Ipsg==
X-Gm-Message-State: AOJu0YxvT8j+GMe1XQifwkzI4rr1HASKIgUW+VJ6M58eJWBKMUgPjCnm
	AlLbHVNOj8m8QnZ7jcse5PmvZDcLSocRsFwcdzZKYRlEnTCEKtLSXztMz1Wq9g89f0M+A1ai4N9
	ru7k01qU=
X-Gm-Gg: AR+sD13DHzxJnWW0YaGvxAxAE5DZzx8bKKCP0/dDPmx0SRD0t0SHIqzhOnbTp8uE0kH
	rQRdubxBizxtBf2hmhPGkrYM0GoHMDRenREU87rCYYVlQrjKKCfvDvGfZz5fq9Jm4FE7UGDq9sP
	tN/WOZraCUAOjvR1aWplHJXdgPQPox7eG0KOpiHl/q/pRzLFK/AHr0jksvW19Jh+ap/GUJA3GRK
	WrWmzzntJZg5+Z8D5F2YJyQ5basEdVTHBpOM4xaACf2WX1GKiAqaR2spMdKJnAh8Wi0IQYKOQ0X
	kIMoT9QfD+aB77zV6jOET2aS6ykydm/vyEY9HMSreaCPROS4zZIQm/FdZ4HQw8JeLGui2clr9Vf
	GSsJKuClyPdmnDRRW0IWISl6V9W8HhFjc+LY+0LYiLh4sVgfJ3tVdV7b9VEg6SRR2Av2dOxqtNP
	cjGm6fHS9WvV0LsuO2FiwWTCoyKZjf58e3+BoS0hQvgKod4mj+5iHXcMmIQ3/BYDO9Lmivl6Emo
	rBDK+sevohIKgDMCMJnAKeDjZ0mO4hH5Vs/GKA=
X-Received: by 2002:a05:600c:8714:b0:499:8704:242c with SMTP id 5b1f17b1804b1-499878ca13bmr498099745e9.0.1786998841777;
        Mon, 17 Aug 2026 13:34:01 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: [PATCH] ARM/vgic: Clean up vgic_v2_setup_hw()
Date: Mon, 17 Aug 2026 21:33:59 +0100
Message-Id: <20260817203359.1881963-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1786998842-FC20077B-D0A61DE3/0/0
X-purgate-type: clean
X-purgate-size: 1726

vgic_v2_setup_hw()'s callers are __init, so it should be too.  vgic_v2_hw is
written once during init and unmodified thereafter, so make it
__ro_after_init.  Reposition 'bool enabled' to fit in the tail padding,
removing 8 bytes from the structure.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>

Found when looking at the code while reviewing something else.  Only compile
tested.
---
 xen/arch/arm/vgic-v2.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 642407fd5b05..3446d521de2d 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -25,7 +25,6 @@
 #include <asm/vreg.h>
 
 static struct {
-    bool enabled;
     /* Distributor interface address */
     paddr_t dbase;
     /* CPU interface address & size */
@@ -36,10 +35,12 @@ static struct {
 
     /* Offset to add to get an 8kB contiguous region if GIC is aliased */
     uint32_t aliased_offset;
-} vgic_v2_hw;
+    bool enabled;
+} vgic_v2_hw __ro_after_init;
 
-void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
-                      paddr_t vbase, uint32_t aliased_offset)
+void __init vgic_v2_setup_hw(
+    paddr_t dbase, paddr_t cbase, paddr_t csize, paddr_t vbase,
+    uint32_t aliased_offset)
 {
     vgic_v2_hw.enabled = true;
     vgic_v2_hw.dbase = dbase;

base-commit: ebc00c30c65023bd1498ae20dc511c4e39f6c0f7
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 22:16:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 22:16:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393313.1632113 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww5cx-0000qO-SB; Mon, 17 Aug 2026 22:16:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393313.1632113; Mon, 17 Aug 2026 22:16:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww5cx-0000qH-P9; Mon, 17 Aug 2026 22:16:19 +0000
Received: by outflank-mailman (input) for mailman id 1393313;
 Mon, 17 Aug 2026 22:16:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <davydov-max@yandex-team.ru>) id 1ww5cw-0000p6-0S
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 22:16:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww5cu-000Sw6-Kx
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 00:16:16 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <davydov-max@yandex-team.ru>)
 id 6a8387dd-8faa-0a2a0a5109dd-0a2a4506c7d0-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:16:16 +0200
Received: from [178.154.239.72] (helo=forwardcorp1a.mail.yandex.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <davydov-max@yandex-team.ru>)
 id 6a83882f-195a-0a2a45060019-b29aef48d734-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:16:15 +0200
Received: from mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net
 (mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net
 [IPv6:2a02:6b8:c2d:3530:0:640:eca4:0])
 by forwardcorp1a.mail.yandex.net (postfix) with ESMTPS id DB311C0A13;
 Tue, 18 Aug 2026 01:16:14 +0300 (MSK)
Received: from [IPV6:2a02:6bf:8080:636::1:14] (unknown
 [2a02:6bf:8080:636::1:14])
 by mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net (smtpcorp) with ESMTPSA
 id AGdauh9aNOs0-b6cs1GW7; Tue, 18 Aug 2026 01:16:14 +0300
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID"
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru;
	s=default; t=1787004974;
	bh=b0Z0/tXuCNUd1fMwZ+IpDj+Wo0HtUhiZ0PxFs9YzGJE=;
	h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID;
	b=Bqo7B2+OcvbL6jkoeu5ZtQ58ESgMa5yx1X9ZY/km3cBov6qCeQ5SDsgsZ0U86Rt5d
	 uYvDSlYKTy4SV0n31y+JkkPZM+aJbk85EmEmmi+5ZG2KRLadsxdZofEw9k/LGvaPc2
	 rA3R7E8/1y06BWknqf88/HkaFxTe9jLnAMqszcpg=
Authentication-Results: mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru
Message-ID: <0d1f0afe-74f0-4adb-a7cf-2d4efd001de3@yandex-team.ru>
Date: Tue, 18 Aug 2026 01:16:10 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 21/51] x86/kvm: Obtain TSC frequency from PV CPUID if
 present
To: Sean Christopherson <seanjc@google.com>
Cc: Kiryl Shutsemau <kas@kernel.org>,
 Rick Edgecombe <rick.p.edgecombe@intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Jan Kiszka <jan.kiszka@siemens.com>,
 Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski
 <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
 Juergen Gross <jgross@suse.com>, Daniel Lezcano <daniel.lezcano@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, John Stultz <jstultz@google.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd
 <sboyd@kernel.org>, Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org,
 linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 Michael Kelley <mhklinux@outlook.com>, Tom Lendacky
 <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>,
 David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>,
 Thomas Gleixner <tglx@linutronix.de>
References: <20260806233609.212337-1-seanjc@google.com>
 <20260806233609.212337-22-seanjc@google.com>
 <ef3b56bf-8df0-4a40-82c7-bd2d65eec71e@yandex-team.ru>
 <aoMVy4VB1sq4T-ys@google.com>
Content-Language: en-US
From: Maksim Davydov <davydov-max@yandex-team.ru>
In-Reply-To: <aoMVy4VB1sq4T-ys@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787004976-F687577B-414A5A40/0/0
X-purgate-type: clean
X-purgate-size: 3812



On 8/17/26 17:08, Sean Christopherson wrote:
> On Mon, Aug 17, 2026, Maksim Davydov wrote:
>> On 8/7/26 02:35, Sean Christopherson wrote:
>>> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
>>> index 29ca37e9a3bc..f55d0305d1f3 100644
>>> --- a/arch/x86/kernel/kvmclock.c
>>> +++ b/arch/x86/kernel/kvmclock.c
>>> @@ -342,8 +342,10 @@ void __init kvmclock_init(void)
>>>  	flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
>>>  	kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
>>>  
>>> -	x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
>>> -	x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
>>> +	if (!x86_init.hyper.get_tsc_khz)
>>> +		x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
>>> +	if (!x86_init.hyper.get_cpu_khz)
>>> +		x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
>>>  	x86_platform.get_wallclock = kvm_get_wallclock;
>>>  	x86_platform.set_wallclock = kvm_set_wallclock;
>>>  #ifdef CONFIG_X86_LOCAL_APIC
>>
>>
>> I cannot test this right now as I lack two servers with different CPU
>> base frequencies, but it seems that this patch might break something in
>> guests:
>> After migrating a VM (QEMU + KVM) from a host with one base frequency to
>> another host with a different base frequency, the value in CPUID leaf
>> 0x40000010 EAX changes and becomes the same as the destination host base
>> frequency instead of remaining the source base frequency.
> 
> That's a bug in whatever is orchestrating the migration, and/or QEMU if QEMU is
> handing the upper layers a loaded footgun.
> 
>> The main reason for this behaviour is that setting the TSC frequency via
>> ioctl(KVM_SET_TSC_KHZ) doesn't change the value in CPUID leaf 0x40000010
>> EAX and these two entities are still not connected.
> 
> And they never will be.  It's userspace's responsibility to fill the correct
> values for 0x40000010.
> 
> But AFAICT, QEMU does the right thing.  env->tsc_khz is used for both the CPUID
> leaf and for KVM_SET_TSC_KHZ.
> 
> kvm_arch_init_vcpu():
> 
>         c = &cpuid_data.entries[cpuid_i++];
>         c->function = KVM_CPUID_SIGNATURE | 0x10;
>         c->eax = env->tsc_khz;
>         c->ebx = env->apic_bus_freq / 1000; /* Hz to KHz */
>         c->ecx = c->edx = 0;
> 
> kvm_arch_set_tsc_khz():
> 
>     r = set_ioctl ?
>         kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz) :
>         -ENOTSUP;
> 

Agreed.
However, kvm_arch_set_tsc_khz() is also used at the end of migration
(qemu_loadvm_state -> cpu_synchronize_post_init).
So, the new value of env->tsc_khz from the source host can be loaded
during migration via KVM_SET_TSC_KHZ. However, the frequency in CPUID
leaf 0x40000010 remains the same as on the destination host (the TSC
frequency can differ from the source host's frequency). Thus, it's
possible to have unsynchronized CPUID leaf 0x40000010 when using default
QEMU parameters.

>> I saw this behaviour with QEMU 7, but I've checked the code of the
>> latest version and it seems that the described behaviour still exists.
>> So, in that case, it's possible that with these changes a VM will use
>> the wrong TSC frequency from CPUID leaf 0x40000010 EAX if it's migrated
>> and then rebooted.
>>
>> Putting it all together, after the previous patch ("KVM: x86: Officially
>> define CPUID 0x40000010 as PV Timing Info (TSC and Bus)") a new way to
>> show the guest that CPUID leaf 0x40000010 is valid should be implemented
>> and only then this leaf can be used to get the TSC frequency.
> 
> No, there are already non-Linux kernels that consume 0x40000010, e.g. FreeBSD.
> In my very strong opinion, if this problematic for a deployment, then that
> deployment needs to urgently fix their broken setup.

-- 
Best regards,
Maksim Davydov



From xen-devel-bounces@lists.xenproject.org Mon Aug 17 22:26:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Aug 2026 22:26:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393320.1632123 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww5mP-0002T8-IS; Mon, 17 Aug 2026 22:26:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393320.1632123; Mon, 17 Aug 2026 22:26:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww5mP-0002T1-Ev; Mon, 17 Aug 2026 22:26:05 +0000
Received: by outflank-mailman (input) for mailman id 1393320;
 Mon, 17 Aug 2026 22:26:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jmattson@google.com>) id 1ww5mN-0002Sq-SR
 for xen-devel@lists.xenproject.org; Mon, 17 Aug 2026 22:26:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww5mN-000Tg6-1i
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 00:26:03 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jmattson@google.com>)
 id 6a838a6f-2eae-0a2a0a5409dd-0a2a4509ea6e-8
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:26:02 +0200
Received: from [209.85.208.43] (helo=mail-ed1-f43.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jmattson@google.com>)
 id 6a838a7a-be1a-0a2a45090019-d155d02b8cbb-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:26:02 +0200
Received: by mail-ed1-f43.google.com with SMTP id
 4fb4d7f45d1cf-69fec8b4638so3712a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 15:26:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787005562; cv=none;
        d=google.com; s=arc-20260327;
        b=sWCiS0tcUQEsHgjIjWOzoFvGbU/8RD2FC/S9ExUrG2MnDlp8OIg5CsMYTSrqMd2V4P
         CvoX49AfHI6V9rrR4HcPnjctBhOwaFdJQnY+qG8pwxU0wgQD5nvP3Y4Vhw/b7FXbA15x
         IPoLj229hU5HQj1zHtGVSUu1GNuLenXOU06H8Pvzznf/AkpjCHgmsip3JVV/c6ZbFCac
         LZHGJ/ZeVJJjTcEcTgXS1C8JX5ydIQ94vSdaBPqqY8i3bvqKrjksItsCYNbBxk3tq/Jt
         7siwoFZKWioPrHQGQ+T3s1BLRHYDR00GzIWxlj1n7eI8ohaCJtElQa9quoRPIfaba26P
         Af+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=hENxuN5mzaES0wxF2BepwjZBV79XeYKjjyJElzU8XaI=;
        fh=XDdWa2L7dmoQEvgDRagQwfUFhzYUD8dnu++QNaWdEII=;
        b=OVKfBaeDWrGekKD9yVXganr5n+yIevG7ukFLnjMGqBp5KxicK9fGPIjGz3EaJmKEHa
         1v76+3P1FKZZphMnR9ALVrs9qceqZZ3MohCzS52c43+iBif63xsyJoyZr+ZjQwgoxrFW
         HYam3F/tonA+GgNm4t+cjkw7MdtF722ih8m8w2eaGOzArYYOkJAM0D+zfP0ceW/11UIT
         A6COhcH74IkMrQXzNyyUlQVP7uONk52AJjyZF4TJWDVRsL3fqPP2hlUagnM75M7xvTku
         6/883nsV1Itiza4XLsqk/W1f+nMbZuLTSzwc9FzthMovw1Y8soegwKzT1aLEHgOSJGxb
         ubJA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1787005562; x=1787610362; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=hENxuN5mzaES0wxF2BepwjZBV79XeYKjjyJElzU8XaI=;
        b=MHQaMFjs3yO4SRttpWxSDtJn0Mq349MPn9KtGePNc9tAiD7p2p6zsCLaaayTPjloTd
         hLfOEiGrX6i9hhSkYwL5bqKi7+2R1YF/+OV8IaJKUeApsmwPoG17+diB6duSraUGlBj9
         Ng8kwozapcA+z+yWMduPS8cSbSjl38v4cYzUmzY0vQSqpj32W3NwMcL/rDh1CoswrQvU
         Q/dI5Fv0Iyl9AJ2uoW3HVIvq41X0sO9XSaoaB2ker2ztaSHzyR02ahgIfNKuJzfQguDl
         Fy4zGcaViItwYPnfmIFJ/hTsMPFIXK1IWgUY4W2Pe/jymoI1uz8711pKEy0q62swpOIU
         c4/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787005562; x=1787610362;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=hENxuN5mzaES0wxF2BepwjZBV79XeYKjjyJElzU8XaI=;
        b=smrl3pxwUai6PVbiRka47mFaZGsSoLW5+5etdX+Nn69mOpcUR8L0LquXGRvtufzcDd
         CDkfIVGT+jsOcrHhH++C1/NCDmkyn3gSP6CEZqDqXSfX/kh+zpGCzzVBP5SrhMTCHWgG
         YP8bwrakcAkjxXM27vrm23yIQGN6MIRHI0J56Bzt86wDQTu71wham01+2mfp3oJlDlYw
         PXyUtWms+XKiRA2vkxxO3h6r6PFqTlY67BEO8EuMZKlHY5wwiSVwnqYasKNZFCNP+WLq
         MuxD0UkeLNPhAJosT7ffwPJYiOmqGnuw7GgzGmvrNdj287dL8XQOxPY5yBgfMsMBb2QI
         KEng==
X-Forwarded-Encrypted: i=1; AHgh+RrGwwqAf2Wu+P1ZRmFswQ9IfWtTFnj4PvpYukmgTnNsR1Er+mQstTmAocV5y2gu7aeiHT+lrNzkuxg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw1ROXtWUar3ampynbw5lZD8cpTcVzfhDwtjrDcZz2FfqCGO0P1
	wNXFsWHf2910wxx9reN6UoLw/xV63yB3yss6m8Um2cvtb+fVfIXhi03koJWksQP+Uyyinm6vSUS
	Jh+lSSlfHut1ZFOxe8xtqUxLeOLCTZ17V8NieZrUk
X-Gm-Gg: AR+sD12/apxM/nUVFTmr1IaKUlPCoE/D/A1ZrK33tI/JTuUbmI3QlRfLqxgdatQ8zNk
	FAF5Zd/97ZppTzR0m4U0UXyLFeITBJgKdSGwkzaYzVwb8WKHYwJwQl687fjHcXdYiO53o0aJna6
	EgEf7gVM+voOegmKF2PJzvDWa3Ho4MRtdtoKxI7MKazkOi4Uvb0/9SHusH62oDnFygbi+bYW1aJ
	UEW2CkXSNq47OGcRdFoRfGXdK4QIdj0eNY0nsukJIdfIqDLdp5mcSIX8m/nyN4zEpZNqONXedGo
	+opKLl7xWU6IDa8msR15al1Tp5Uc5PXnSHtF5tNY8bs/
X-Received: by 2002:aa7:db55:0:b0:698:ac70:31b9 with SMTP id
 4fb4d7f45d1cf-6a3eb34835bmr2896a12.5.1787005561938; Mon, 17 Aug 2026 15:26:01
 -0700 (PDT)
MIME-Version: 1.0
References: <20260806233609.212337-1-seanjc@google.com> <20260806233609.212337-22-seanjc@google.com>
 <ef3b56bf-8df0-4a40-82c7-bd2d65eec71e@yandex-team.ru> <aoMVy4VB1sq4T-ys@google.com>
 <0d1f0afe-74f0-4adb-a7cf-2d4efd001de3@yandex-team.ru>
In-Reply-To: <0d1f0afe-74f0-4adb-a7cf-2d4efd001de3@yandex-team.ru>
From: Jim Mattson <jmattson@google.com>
Date: Mon, 17 Aug 2026 15:25:50 -0700
X-Gm-Features: AcwNN1WdnB6ezAOkUjWvrMa9sQkEiE5NQZNmLUZ6exeGRBIrQHFr5mGJRwWtIb4
Message-ID: <CALMp9eQRW22S6zSrhkxc+8PgSuOJJOB-jh_W1iyr7c0j5SBLow@mail.gmail.com>
Subject: Re: [PATCH v6 21/51] x86/kvm: Obtain TSC frequency from PV CPUID if present
To: Maksim Davydov <davydov-max@yandex-team.ru>
Cc: Sean Christopherson <seanjc@google.com>, Kiryl Shutsemau <kas@kernel.org>, 
	Rick Edgecombe <rick.p.edgecombe@intel.com>, Paolo Bonzini <pbonzini@redhat.com>, 
	"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Jan Kiszka <jan.kiszka@siemens.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juergen Gross <jgross@suse.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
	John Stultz <jstultz@google.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd <sboyd@kernel.org>, 
	Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org, linux-coco@lists.linux.dev, 
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, Michael Kelley <mhklinux@outlook.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>, 
	David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>, 
	Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-bad1c0/1787005562-BD6C2034-38BF12EF/0/0
X-purgate-type: clean
X-purgate-size: 3357

On Mon, Aug 17, 2026 at 3:20=E2=80=AFPM Maksim Davydov
<davydov-max@yandex-team.ru> wrote:
>
>
>
> On 8/17/26 17:08, Sean Christopherson wrote:
> > On Mon, Aug 17, 2026, Maksim Davydov wrote:
> >> On 8/7/26 02:35, Sean Christopherson wrote:
> >>> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> >>> index 29ca37e9a3bc..f55d0305d1f3 100644
> >>> --- a/arch/x86/kernel/kvmclock.c
> >>> +++ b/arch/x86/kernel/kvmclock.c
> >>> @@ -342,8 +342,10 @@ void __init kvmclock_init(void)
> >>>     flags =3D pvclock_read_flags(&hv_clock_boot[0].pvti);
> >>>     kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
> >>>
> >>> -   x86_init.hyper.get_tsc_khz =3D kvmclock_get_tsc_khz;
> >>> -   x86_init.hyper.get_cpu_khz =3D kvmclock_get_tsc_khz;
> >>> +   if (!x86_init.hyper.get_tsc_khz)
> >>> +           x86_init.hyper.get_tsc_khz =3D kvmclock_get_tsc_khz;
> >>> +   if (!x86_init.hyper.get_cpu_khz)
> >>> +           x86_init.hyper.get_cpu_khz =3D kvmclock_get_tsc_khz;
> >>>     x86_platform.get_wallclock =3D kvm_get_wallclock;
> >>>     x86_platform.set_wallclock =3D kvm_set_wallclock;
> >>>  #ifdef CONFIG_X86_LOCAL_APIC
> >>
> >>
> >> I cannot test this right now as I lack two servers with different CPU
> >> base frequencies, but it seems that this patch might break something i=
n
> >> guests:
> >> After migrating a VM (QEMU + KVM) from a host with one base frequency =
to
> >> another host with a different base frequency, the value in CPUID leaf
> >> 0x40000010 EAX changes and becomes the same as the destination host ba=
se
> >> frequency instead of remaining the source base frequency.
> >
> > That's a bug in whatever is orchestrating the migration, and/or QEMU if=
 QEMU is
> > handing the upper layers a loaded footgun.
> >
> >> The main reason for this behaviour is that setting the TSC frequency v=
ia
> >> ioctl(KVM_SET_TSC_KHZ) doesn't change the value in CPUID leaf 0x400000=
10
> >> EAX and these two entities are still not connected.
> >
> > And they never will be.  It's userspace's responsibility to fill the co=
rrect
> > values for 0x40000010.
> >
> > But AFAICT, QEMU does the right thing.  env->tsc_khz is used for both t=
he CPUID
> > leaf and for KVM_SET_TSC_KHZ.
> >
> > kvm_arch_init_vcpu():
> >
> >         c =3D &cpuid_data.entries[cpuid_i++];
> >         c->function =3D KVM_CPUID_SIGNATURE | 0x10;
> >         c->eax =3D env->tsc_khz;
> >         c->ebx =3D env->apic_bus_freq / 1000; /* Hz to KHz */
> >         c->ecx =3D c->edx =3D 0;
> >
> > kvm_arch_set_tsc_khz():
> >
> >     r =3D set_ioctl ?
> >         kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz) :
> >         -ENOTSUP;
> >
>
> Agreed.
> However, kvm_arch_set_tsc_khz() is also used at the end of migration
> (qemu_loadvm_state -> cpu_synchronize_post_init).
> So, the new value of env->tsc_khz from the source host can be loaded
> during migration via KVM_SET_TSC_KHZ. However, the frequency in CPUID
> leaf 0x40000010 remains the same as on the destination host (the TSC
> frequency can differ from the source host's frequency). Thus, it's
> possible to have unsynchronized CPUID leaf 0x40000010 when using default
> QEMU parameters.

I don't use qemu, but isn't the qemu solution for this general
situation to mark leaf 40000010H as 'unmigratable'?


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 02:52:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 02:52:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393348.1632172 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wf-0001ze-Je; Tue, 18 Aug 2026 02:52:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393348.1632172; Tue, 18 Aug 2026 02:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wf-0001zX-Fk; Tue, 18 Aug 2026 02:52:57 +0000
Received: by outflank-mailman (input) for mailman id 1393348;
 Tue, 18 Aug 2026 02:52:56 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1ww9we-0001yE-5S
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 02:52:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww9wd-0015Oq-Il
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 04:52:55 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8e3-2eae-0a2a0a5409dd-0a2a4505b2d2-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:55 +0200
Received: from [209.85.215.169] (helo=mail-pg1-f169.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c906-4cb1-0a2a45050019-d155d7a9e116-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:55 +0200
Received: by mail-pg1-f169.google.com with SMTP id
 41be03b00d2f7-cbee3777e1cso2310403a12.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:52:55 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d3b40basm4333605a91.14.2026.08.17.19.52.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 19:52:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787021573; x=1787626373; 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=Bjcs/pOZ08cE/dRMsQLU7rzeUl8ZNFGFfdNRoYL0AWQ=;
        b=eoV32anN7ryIN5hp+TFDhtPsqX51VbbIEBoh0FmeZWCqCBQ43WoAQSMjVTO5KMsWPQ
         sa79iRbFdF7JG2M0WfvCRmwvR/8NwzJGR9zz4QyMnSExo8VVHpgkZBH5BhIvUcd8pGLJ
         oVseWynis7RsR1pn7i9hRCBB4FAfhfNvkZb3kSOLxVXP4ItcDAld+t7D3JHFQJxfIOwJ
         m09n+0DhqlcWozOWDx2yreJJqperUmvOVScSUqeNrm6O9vRjnDRs1zUePZj0XMb+z7Vg
         qz6BxDFliUDLBcUjmB67ORR3FVHny5eI2VZmZ1/nJNJcyph34Tq2sTXM1pOpcBgV4NX3
         eWTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787021573; x=1787626373;
        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=Bjcs/pOZ08cE/dRMsQLU7rzeUl8ZNFGFfdNRoYL0AWQ=;
        b=GnFLl7vm1G+GbU1Z/G5WK1nDt76wep2QEYmLk0fsvtWHED4x/aMtKxs9gaOFBMpxZ7
         q08sk2pXZhLZwUQwUGYUP8YVAOPWk6b/NOMMuQN6EfBXNcBrZdf1zCrA8U7jrH7F+Bkm
         joHb/HeAHfFiw3KXIgSCBubr0Rt+pnIkZ+E8KHxAKKMKZjjnjNfhFDYd+EU+7jQ36Nm2
         14G4eJEvUbwy0VHry4FYWZKmIyVZYvNCY5RzKUHteYz3tW/mYVAeVc02HZp+j5y+iibP
         cD3skkmHSflGstVwYiN6y2un6W8AvBh69H4ZskcU9luEPiACiqZmE1YOyb1oWvftZGOq
         0oAQ==
X-Gm-Message-State: AOJu0YwQ5HZjHJ6sxGTJCb7mkA1ejlE+BwiavMdnNBQDM9zmf23Pf4rW
	QQxk5GmP7TlbKrPfhOH/kwCbwhK5Bl22tjFK9p/nE2fwyqBFbsi79JAQockBpVrW
X-Gm-Gg: AR+sD128h53r5foSgjUp2d1/bida4V8762fgaeZ0dkQ97PSe9anVgTQiRhomRQqr09F
	IwdND/hJOuHj+yUP/6aihDoAoYrwAykoKmJ1XYFIKlOopyixwvfM/OuDtVAw3J9UL7GzJ+fB22E
	3WpLgDIx9WuFexVsqr/Ums8lxnLDmzf36J/jArPtU9bM0d3kCY3BrFU3Jm/cyUuuJZgveBumU8z
	iTc07CVqkVods9QfsGDbFTp0Dz7/uo/la0m107pXkqCSeCTU/HbJx1QfJQiFym0HXUKqo4rLpfR
	ugekDNSrRO/KIflrU5lA2sgMAnfOnabrStJ6oQAC1Ht6Xg9t8GRyW5SCPqfClOvFrFLI/4+vl5P
	HV+72Yzm5mdDaNBwI341d/Q9jkpMwXpyEuYjOrVk9XkGR2YgVJgl+lx1Eml9oPBYeEXcB6jLPQr
	GgbdoTW9OvLjb5mUw+QLsdVL8AMvpgDD0CKpeZUsZXw/a3gi0Uf8yuFHs60e/9uUnITwScfgkIh
	Xu8MRTp2XZGQggLzo6Mrh0tX2+fUg/8
X-Received: by 2002:a17:90a:da8f:b0:380:21b7:e727 with SMTP id 98e67ed59e1d1-3933b95e327mr30350317a91.14.1787021573357;
        Mon, 17 Aug 2026 19:52:53 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v2 3/4] xen/arm: add i.MX8M platform support
Date: Tue, 18 Aug 2026 10:52:23 +0800
Message-ID: <20260818025224.4165503-4-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818025224.4165503-1-onlywig@gmail.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787021575-738BE2A1-CAC23869/0/0
X-purgate-type: clean
X-purgate-size: 6551

Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).

When Linux is used as dom0 a number of drivers make SiP SMC calls into
TF-A to manage hardware: GPC power domains, DDR frequency scaling, SRC
(M-core remoteproc), SoC info and NoC QoS.  There is no public
specification for these calls; the function IDs and their subfunctions
are taken from the vendor kernel call sites.

Forward only the specific subfunctions the hardware domain issues,
following the whitelist model of the i.MX8QM platform.  Where a service
has a fixed set of subfunctions (GPC, SRC, NoC) they are filtered; DDR
DVFS is left at service level because its reg1 is a frequency setpoint
rather than a fixed subfunction id, and the SoC info call is a read-only
query.  CPU frequency scaling is denied because the hardware domain
cannot make an informed decision, and any unknown function ID is
rejected.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/imx8m.c  | 152 ++++++++++++++++++++++++++++++++
 2 files changed, 153 insertions(+)
 create mode 100644 xen/arch/arm/platforms/imx8m.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index bec6e55d1f..cdf936c50d 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
 obj-$(CONFIG_ALL64_PLAT) += thunderx.o
 obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
 obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8m.o
 obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
new file mode 100644
index 0000000000..fcf01298d8
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8m.c
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * i.MX 8M family setup
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/sched.h>
+#include <asm/platform.h>
+#include <asm/smccc.h>
+
+static const char * const imx8m_dt_compat[] __initconst =
+{
+    "fsl,imx8mp",
+    "fsl,imx8mq",
+    "fsl,imx8mm",
+    "fsl,imx8mn",
+    NULL
+};
+
+#define IMX_SIP_FID(fid) \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+                       ARM_SMCCC_CONV_64, \
+                       ARM_SMCCC_OWNER_SIP, \
+                       (fid))
+
+/*
+ * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
+ * public specification for these; the IDs and their subfunctions are
+ * extracted from the vendor kernel call sites (see drivers/soc/imx,
+ * drivers/devfreq, drivers/remoteproc).
+ */
+#define IMX_SIP_F_GPC       0x0   /* GPC power-domain control */
+#define IMX_SIP_F_CPUFREQ   0x1
+#define IMX_SIP_F_DDR_DVFS  0x4   /* DRAM frequency scaling */
+#define IMX_SIP_F_SRC       0x5   /* SRC: M-core remoteproc start/stop */
+#define IMX_SIP_F_SOC_INFO  0x6   /* read-only SoC info query */
+#define IMX_SIP_F_NOC       0x8   /* NoC QoS priority setup */
+
+#define IMX_SIP_GPC_SF_PM_DOMAIN    0x03
+
+#define IMX_SIP_SRC_SF_M4_START     0x00
+#define IMX_SIP_SRC_SF_M4_STOP      0x02
+
+#define IMX_SIP_NOC_SF_LCDIF        0x00
+#define IMX_SIP_NOC_SF_PRIORITY     0x01
+
+static bool imx8m_smc(struct cpu_user_regs *regs)
+{
+    uint32_t function_id = get_user_reg(regs, 0);
+    uint32_t subfunction_id = get_user_reg(regs, 1);
+    struct arm_smccc_res res;
+
+    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+    {
+        printk_once(XENLOG_WARNING
+                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
+
+        return false;
+    }
+
+    /* Only the hardware domain may use the SiP calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
+        return false;
+    }
+
+    /*
+     * Forward only the subfunctions the dom0 kernel actually issues.  All
+     * of these manage hardware that belongs to the hardware domain (power
+     * domains, DRAM controller, M-core, NoC) or are read-only queries.
+     */
+    switch ( function_id )
+    {
+    case IMX_SIP_FID(IMX_SIP_F_GPC):
+        if ( subfunction_id != IMX_SIP_GPC_SF_PM_DOMAIN )
+            goto deny_subfunction;
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_SRC):
+        if ( subfunction_id > IMX_SIP_SRC_SF_M4_STOP )
+            goto deny_subfunction;
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_NOC):
+        if ( subfunction_id > IMX_SIP_NOC_SF_PRIORITY )
+            goto deny_subfunction;
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
+        /*
+         * For DDR DVFS reg1 is a frequency setpoint index (or the
+         * GET_FREQ_COUNT / GET_FREQ_INFO query), not a fixed subfunction
+         * id, so it is not filtered here.
+         */
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_SOC_INFO):
+        break;
+
+    /*
+     * CPU frequency scaling: the hardware domain does not see the whole
+     * system and cannot make an informed decision, so deny it (matches
+     * the i.MX8QM platform).
+     */
+    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
+        return false;
+
+    default:
+        gprintk(XENLOG_WARNING, "imx8m: smc: Unknown function id %x\n",
+                function_id);
+        return false;
+    }
+
+    arm_smccc_1_1_smc(function_id,
+                      subfunction_id,
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+
+ deny_subfunction:
+    gprintk(XENLOG_WARNING,
+            "imx8m: smc: function %x: denied subfunction %x\n",
+            function_id, subfunction_id);
+    return false;
+}
+
+PLATFORM_START(imx8m, "i.MX 8M")
+    .compatible = imx8m_dt_compat,
+    .smc = imx8m_smc,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 02:52:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 02:52:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393346.1632162 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wb-0001kB-Dc; Tue, 18 Aug 2026 02:52:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393346.1632162; Tue, 18 Aug 2026 02:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wb-0001k3-9Z; Tue, 18 Aug 2026 02:52:53 +0000
Received: by outflank-mailman (input) for mailman id 1393346;
 Tue, 18 Aug 2026 02:52:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1ww9wZ-0001jC-SF
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 02:52:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww9wZ-005CSk-96
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 04:52:51 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8da-8faa-0a2a0a5109dd-0a2a4501ccf4-10
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:51 +0200
Received: from [209.85.216.52] (helo=mail-pj1-f52.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c901-5984-0a2a45010019-d155d834bcb4-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:51 +0200
Received: by mail-pj1-f52.google.com with SMTP id
 98e67ed59e1d1-38dc4553f62so5373900a91.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:52:50 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d3b40basm4333605a91.14.2026.08.17.19.52.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 19:52:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787021569; x=1787626369; 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=/ebcWQVd73jtJSn4IlaXws2VNwFd+9+DtXjs8Yvf8FE=;
        b=XUt3quO4ReRqKk5Rd6VJr7lbbb1Zmf0121O/2DPz+RlOJoeOx9pdq42z/Sk0bmkelZ
         uNSB5jS5QO8pRsY+XXjI9T4AE3vapReJQU/AuwjfdLwM9e4sHeywM/WgWg8GOPJHbaYF
         jSVzGQejCbF9liDSwWDe5hZb3NwzJKpX8DTQvwUnF3K/93wEOMKM8OQ5zkW7Zll1u1cP
         MKnTdZHnf+nNmQxNB8TfVYYGvigs77NRN7BmYJaj1JwhbFbbIAjP6s6dzDt9LSl6PBXj
         CLXwS8YNQhlPbI0gRNwLeDXKREEtvO1R9HTYR1OLX26Qw+773mPNMnhadbDgFkS4cMHn
         tjbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787021569; x=1787626369;
        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=/ebcWQVd73jtJSn4IlaXws2VNwFd+9+DtXjs8Yvf8FE=;
        b=HFSsI5CQdY5iTnnqinZdCRNRyNns8wugYhV+kdvPKuAeFL9MSx7vIx8fwCGwYEk9v2
         1Pj5RNF1Gc/0zZDe9qkHtJT9NTezhZmcZeAo48iiZ4g1XlA24wC+POmUZTfgvi3ytpfc
         fiWsajVpE39wfgGgAZszYIY0L/FAokcfM924/Wza/6gdzCHUuJ+dHO4Pd5d0SPkH8arQ
         q2X1687fsREGMWKqPn0XO3p7k0IXn7OlmfvXcfAGy9WqIMNRFVnZbY8+FblPwTpyyDlk
         h4TupoVGQBC5Af6bt0vBx1NywqmMy27CF2LaI/Q0z02Ae6XOWS5WEAri86RXxpmY8RW2
         TQsA==
X-Gm-Message-State: AOJu0YxJ40MNK+vGgFcf+H6CeUWTZB+TUxnhkkLoLTLuTVZuVC9ImdOE
	te2zdFJClj5CREyPhjjd3NpQNG4uiBpwzp+FWHEcN0in513rWVGomW1ABMHQO+fU
X-Gm-Gg: AR+sD12vwfE3YjSQc6gDEDiyL017rM5Ykrs8+b33V+M4C1XshI8MKnyAgintMx7unLA
	is+8ZzNhlpZkB/eNGfh9R4Tas2eJXwACwkme6S+ebqt3skpt/yig2ZTeKxNsEAWaeEBzmWOoLmr
	v4nTKXUBocNYj7cgJAj0ZLEfZjmmiHdzuEGKnht4juZvxJJXN4Io48LTDj8vW6bXqOPjNb4KQnb
	L81mPdvHglv1nXFDTTO9aOlJmAkv0KLQyEsFwRrKyk7Rh/mDwPVf7aPc4ocb2eACz5PwtOAm6CJ
	WSIuCOhrfjJOrruz2OV78ZPlCSiLnaOnMqX7LZW47QngppGIGL3p44c/B62ZSOhkSXD/Ly2NwHR
	clU1C3nrrpxfn2BuNg87sH9CrSvQsQ/F8TU0eBZuR6t8jO/dErKV8bx1PkyxsIUk7oOyX9FMyNM
	f97JefwVnzSwZi/n8nwR/eiQ7h3Rutkkc+uiSU4+euwCjzhHLc7fbjj1FcM4wF8CvHABFUsEyW8
	g32bmfv7V1zEc/Ep9RiM4jdo8mFBMXc
X-Received: by 2002:a17:90b:52cf:b0:37f:ed7e:7e42 with SMTP id 98e67ed59e1d1-3955a7d1a16mr5076420a91.14.1787021569081;
        Mon, 17 Aug 2026 19:52:49 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v2 2/4] xen/arm64: add early printk for the classic i.MX UART
Date: Tue, 18 Aug 2026 10:52:22 +0800
Message-ID: <20260818025224.4165503-3-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818025224.4165503-1-onlywig@gmail.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787021571-1F66C757-A423DD34/0/0
X-purgate-type: clean
X-purgate-size: 3008

Add an early printk implementation for the classic i.MX UART IP,
selectable via EARLY_UART_CHOICE_IMX_UART.  The UART is expected to be
fully initialized by the bootloader.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 xen/arch/arm/Kconfig.debug            | 12 +++++++++
 xen/arch/arm/arm64/debug-imx-uart.inc | 37 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc

diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 5a03b220ac..63a34b813a 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -44,6 +44,14 @@ choice
 		  Say Y here if you wish the early printk to direct their
 		  output to a i.MX LPUART.
 
+	config EARLY_UART_CHOICE_IMX_UART
+		select EARLY_UART_IMX_UART
+		depends on ARM_64
+		bool "Early printk via i.MX UART"
+		help
+		  Say Y here if you wish the early printk to direct their
+		  output to the classic i.MX UART (i.MX8M family).
+
 	config EARLY_UART_CHOICE_LINFLEX
 		select EARLY_UART_LINFLEX
 		depends on ARM_64
@@ -97,6 +105,9 @@ config EARLY_UART_EXYNOS4210
 config EARLY_UART_IMX_LPUART
 	select EARLY_PRINTK
 	bool
+config EARLY_UART_IMX_UART
+	select EARLY_PRINTK
+	bool
 config EARLY_UART_LINFLEX
 	select EARLY_PRINTK
 	bool
@@ -185,6 +196,7 @@ config EARLY_PRINTK_INC
 	default "debug-cadence.inc" if EARLY_UART_CADENCE
 	default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
 	default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
+	default "debug-imx-uart.inc" if EARLY_UART_IMX_UART
 	default "debug-linflex.inc" if EARLY_UART_LINFLEX
 	default "debug-meson.inc" if EARLY_UART_MESON
 	default "debug-mvebu.inc" if EARLY_UART_MVEBU
diff --git a/xen/arch/arm/arm64/debug-imx-uart.inc b/xen/arch/arm/arm64/debug-imx-uart.inc
new file mode 100644
index 0000000000..19b1679020
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-imx-uart.inc
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Early printk for the classic i.MX UART IP (i.MX8M family).
+ * The UART is expected to be fully initialized by the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <asm/imx-uart.h>
+
+/*
+ * Wait for the UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb, c
+1:
+        ldr   w\c, [\xb, #UTS]        /* <- Test register */
+        tst   w\c, #UTS_TXFULL        /* Check TX FIFO full bit */
+        b.ne  1b                      /* Wait until there is room */
+.endm
+
+/*
+ * UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb, wt
+        str   \wt, [\xb, #URTX0]      /* -> Transmitter register */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 02:52:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 02:52:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393345.1632153 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wX-0001WA-2v; Tue, 18 Aug 2026 02:52:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393345.1632153; Tue, 18 Aug 2026 02:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wW-0001W3-Vo; Tue, 18 Aug 2026 02:52:48 +0000
Received: by outflank-mailman (input) for mailman id 1393345;
 Tue, 18 Aug 2026 02:52:48 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1ww9wW-0001M6-9P
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 02:52:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww9wV-000sOh-Mp
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 04:52:47 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8b3-e002-0a2a0a5209dd-0a2a4507d062-24
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:47 +0200
Received: from [209.85.216.51] (helo=mail-pj1-f51.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8fe-b4ea-0a2a45070019-d155d833a45a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:47 +0200
Received: by mail-pj1-f51.google.com with SMTP id
 98e67ed59e1d1-38e3efab7e0so458350a91.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:52:47 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d3b40basm4333605a91.14.2026.08.17.19.52.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 19:52:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787021565; x=1787626365; 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=eNEbZb8d3EIW7+AuEqsJziYT7kLVDhA14GbIEAzFYfE=;
        b=gveSBXEbaN/WdbiPoDk7RRstyviiHje+GPK79+yTJWrQQHRShm3tVicpvkY6VrwpnQ
         fr5nFjM8nhL5FkVheLc5pl9NCJ/Vdzfe8vpTt8R1KLG8mayOX+v2dqzf/Tl+3XqHJFub
         Ne3w0u46Zhno/Jy99Jz2QLZCmeKkfWmlMc45XMI4hFH7zxWmLOuwBUlHxhpR2CP+l7MM
         1R0Ckb8zrOPTIq5aXxZIUVh9XkjFpLHkZKNojbS20WVSx5iCg1dTvJCPzU82mPXOLjB4
         1doJTYO+FrOoo5X64v0eVVZolUePB1r7grYBg45uUCLjhjaT2q/PufOzcPwSRwDwXWcX
         upMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787021565; x=1787626365;
        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=eNEbZb8d3EIW7+AuEqsJziYT7kLVDhA14GbIEAzFYfE=;
        b=BRTxyngJDAk7iGugh2ISTEux4S+TbSZPQFQRus2i9Mf/1asd8gqzuXpK2QKSHv07uU
         skhTFLsgYduV5ySBMR5MyCOrmDQXYnnGcZPlua+KyfWFifbzcszRAUl54TQ9Gl2Bn6G5
         saXXijbTxoIfDtEJ+ne+gjwJlu5wdZDgE8Iu+B1JgNOjWFzZkrddRqYajuW73sxggBWu
         DcVDVRUQmC+1V68h7QK6xUtnhAsXzxWfT0rsca/oPAIA+IZzBijQjD1LcH/79rqwXRU1
         C1Nkhh1/jnvlFnCFVyuDBCVgXyyI+K/sZMKmRGDdN5p6y2xbkCTNbgjhSj2ZuaSv+Gj6
         Cyww==
X-Gm-Message-State: AOJu0YwxZYikkbIgO96HQdOznXHCJCI9/gvUkFox3FBjDUxEImCUbApU
	X7heRKsuw3z+NwstHkFjNw+R58yU+fi0mFOmVI4FH0Km41Cx3/mMEmkfgWg8/y19
X-Gm-Gg: AR+sD11lzCEtMsgr0JwS9D2GEaz17Y3OwaMgZqyW7O/qhuCmY2M8VjHWVQMg6ZfIjVO
	N91Ry/jTJkb4mllfT9BI6dHFrNK+VpUqiyqDJJqBeRZ7hYbuPLaprYI9VD1N8m8XGPDIqzNNEJG
	w/SmMM95u4TCO5DPENlGYqoaWgXnJ99y5arZ3UxtRJwEmberQnKhb6Yf8kCtUIDU5Njk5lGAK4s
	EA/xo/vTdE7Mgp65AZJU2KajsPbM656uXAsL0Xv1WViylp6HxqtjlEnDgPY3asP3a5wKOAhltHC
	Z2zgXjcYDoMVwNXSIYv1Y0k/a/WJB0vmwdzxoQdM/Jgw1vPn0oexJ3gmlQKdiqRTVHlbUPSPz+j
	zfitDySbps3iEMOFaczqAfDO1nlWh1ZOqPZCgUAo1nN3vuHLhaXZxkn+8jTE00lviTNev+29R8+
	LPdus/r3tNzT/OcN5ZiRKmNUtVuUmQKIV0GMRLPv/ch7bkKEmb12RMd9B5y3YkC+1NHdgZZxtEY
	RIBvEwxS7g3Frr5VaMp2aLbF+9giac3QBR96g==
X-Received: by 2002:a17:90b:58e8:b0:385:3ab:fecb with SMTP id 98e67ed59e1d1-39563853b56mr1747770a91.4.1787021565402;
        Mon, 17 Aug 2026 19:52:45 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v2 1/4] xen/char: add classic i.MX UART driver
Date: Tue, 18 Aug 2026 10:52:21 +0800
Message-ID: <20260818025224.4165503-2-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818025224.4165503-1-onlywig@gmail.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787021567-A5CC7AE4-03F6A728/0/0
X-purgate-type: clean
X-purgate-size: 10556

Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
compatible), used as the console UART on the i.MX8M family.  Baudrate
and pin configuration are inherited from the bootloader; the driver
only enables the transmitter/receiver and wires up the RX/TX
interrupts, mirroring the existing imx-lpuart driver.

The i.MX8M family's UART IP differs from the LPUART used on
i.MX8QM/8QXP, so a separate driver is needed.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 xen/arch/arm/include/asm/imx-uart.h |  57 +++++++
 xen/drivers/char/Kconfig            |   8 +
 xen/drivers/char/Makefile           |   1 +
 xen/drivers/char/imx-uart.c         | 226 ++++++++++++++++++++++++++++
 4 files changed, 292 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/drivers/char/imx-uart.c

diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
new file mode 100644
index 0000000000..a3892020e6
--- /dev/null
+++ b/xen/arch/arm/include/asm/imx-uart.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Register definitions for the classic i.MX UART IP
+ * ("fsl,imx6q-uart" compatible), used as the console UART on the
+ * i.MX8M family.
+ *
+ * Register layout taken from Linux drivers/tty/serial/imx.c.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#ifndef ASM_IMX_UART_H
+#define ASM_IMX_UART_H
+
+#include <xen/const.h>
+
+#define URXD0           0x00   /* Receiver Register */
+#define URTX0           0x40   /* Transmitter Register */
+#define UCR1            0x80   /* Control Register 1 */
+#define UCR2            0x84   /* Control Register 2 */
+#define USR1            0x94   /* Status Register 1 */
+#define USR2            0x98   /* Status Register 2 */
+#define UTS             0xb4   /* Test Register */
+
+#define URXD_RX_DATA    0xff
+
+#define UCR1_UARTEN     BIT(0, U)   /* UART enable */
+#define UCR1_ATDMAEN    BIT(2, U)   /* Aging DMA timer enable */
+#define UCR1_TXDMAEN    BIT(3, U)   /* Transmitter ready DMA enable */
+#define UCR1_TXMPTYEN   BIT(6, U)   /* Transmitter empty interrupt enable */
+#define UCR1_RXDMAEN    BIT(8, U)   /* Receiver ready DMA enable */
+#define UCR1_RRDYEN     BIT(9, U)   /* Receiver ready interrupt enable */
+#define UCR1_TRDYEN     BIT(13, U)  /* Transmitter ready interrupt enable */
+
+#define UCR2_SRST       BIT(0, U)   /* 0 = issue software reset */
+#define UCR2_RXEN       BIT(1, U)   /* Receiver enable */
+#define UCR2_TXEN       BIT(2, U)   /* Transmitter enable */
+
+#define USR1_TRDY       BIT(13, U)  /* Transmitter ready */
+
+#define USR2_RDR        BIT(0, U)   /* Receive data ready */
+#define USR2_ORE        BIT(1, U)   /* Overrun error */
+
+#define UTS_TXFULL      BIT(4, U)   /* TX FIFO full */
+#define UTS_RXEMPTY     BIT(5, U)   /* RX FIFO empty */
+#define UTS_TXEMPTY     BIT(6, U)   /* TX FIFO empty */
+
+#endif /* ASM_IMX_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 8e49a52c73..f237c0220d 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -30,6 +30,14 @@ config HAS_IMX_LPUART
 	help
 	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
 
+config HAS_IMX_UART
+	bool "i.MX UART driver"
+	default y
+	depends on ARM_64
+	help
+	  This selects the classic i.MX UART. If you have an i.MX8M family
+	  based board, say Y.
+
 config HAS_MVEBU
 	bool "Marvell MVEBU UART driver"
 	default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 8cbbffdca8..039f566926 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
 obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_XHCI) += xhci-dbc.o
 obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
+obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
 obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
 obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
 obj-y += serial.o
diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
new file mode 100644
index 0000000000..fd34b0cd11
--- /dev/null
+++ b/xen/drivers/char/imx-uart.c
@@ -0,0 +1,226 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), used as the
+ * console UART on the i.MX8M family (e.g. i.MX8MP).
+ *
+ * Baudrate and pin configuration are inherited from the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/serial.h>
+#include <asm/device.h>
+#include <asm/imx-uart.h>
+#include <asm/io.h>
+
+#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
+#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
+
+static struct imx_uart {
+    uint32_t irq;
+    char __iomem *regs;
+    struct irqaction irqaction;
+    struct vuart_info vuart;
+} imx8m_com;
+
+static void imx_uart_interrupt(int irq, void *data)
+{
+    struct serial_port *port = data;
+    struct imx_uart *uart = port->uart;
+
+    if ( imx_uart_read(uart, USR2) & USR2_RDR )
+        serial_rx_interrupt(port);
+
+    if ( imx_uart_read(uart, USR1) & USR1_TRDY )
+        serial_tx_interrupt(port);
+}
+
+static void __init imx_uart_init_preirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1, ucr2;
+
+    /*
+     * Reuse the bootloader settings; only enable the UART and both
+     * directions.  The console uses UCR1 interrupts (RRDYEN/TRDYEN)
+     * exclusively, so just clear UCR1's interrupt and DMA enables.
+     */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_TXMPTYEN | UCR1_RXDMAEN |
+              UCR1_TXDMAEN | UCR1_ATDMAEN);
+    ucr1 |= UCR1_UARTEN;
+    imx_uart_write(uart, UCR1, ucr1);
+
+    ucr2 = imx_uart_read(uart, UCR2);
+    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
+    imx_uart_write(uart, UCR2, ucr2);
+}
+
+static void __init imx_uart_init_postirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    uart->irqaction.handler = imx_uart_interrupt;
+    uart->irqaction.name = "imx_uart";
+    uart->irqaction.dev_id = port;
+
+    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
+    {
+        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %d\n", uart->irq);
+        return;
+    }
+
+    /* Enable the receiver ready interrupt */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 |= UCR1_RRDYEN;
+    imx_uart_write(uart, UCR1, ucr1);
+}
+
+static int imx_uart_tx_ready(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return !(imx_uart_read(uart, UTS) & UTS_TXFULL);
+}
+
+static void imx_uart_putc(struct serial_port *port, char c)
+{
+    struct imx_uart *uart = port->uart;
+
+    while ( imx_uart_read(uart, UTS) & UTS_TXFULL )
+        cpu_relax();
+
+    imx_uart_write(uart, URTX0, c);
+}
+
+static int imx_uart_getc(struct serial_port *port, char *pc)
+{
+    struct imx_uart *uart = port->uart;
+
+    if ( !(imx_uart_read(uart, USR2) & USR2_RDR) )
+        return 0;
+
+    *pc = imx_uart_read(uart, URXD0) & URXD_RX_DATA;
+
+    if ( imx_uart_read(uart, USR2) & USR2_ORE )
+        imx_uart_write(uart, USR2, USR2_ORE);
+
+    return 1;
+}
+
+static int __init imx_uart_irq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return ((uart->irq > 0) ? uart->irq : -1);
+}
+
+static const struct vuart_info *imx_uart_vuart_info(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return &uart->vuart;
+}
+
+static void imx_uart_start_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 | UCR1_TRDYEN);
+}
+
+static void imx_uart_stop_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 & ~UCR1_TRDYEN);
+}
+
+static struct uart_driver __read_mostly imx_uart_driver = {
+    .init_preirq = imx_uart_init_preirq,
+    .init_postirq = imx_uart_init_postirq,
+    .tx_ready = imx_uart_tx_ready,
+    .putc = imx_uart_putc,
+    .getc = imx_uart_getc,
+    .irq = imx_uart_irq,
+    .start_tx = imx_uart_start_tx,
+    .stop_tx = imx_uart_stop_tx,
+    .vuart_info = imx_uart_vuart_info,
+};
+
+static int __init imx_uart_init(struct dt_device_node *dev, const void *data)
+{
+    const char *config = data;
+    struct imx_uart *uart;
+    int res;
+    paddr_t addr, size;
+
+    if ( strcmp(config, "") )
+        printk("WARNING: UART configuration is not supported\n");
+
+    uart = &imx8m_com;
+
+    res = dt_device_get_paddr(dev, 0, &addr, &size);
+    if ( res )
+    {
+        printk("imx-uart: Unable to retrieve the base address of the UART\n");
+        return res;
+    }
+
+    res = platform_get_irq(dev, 0);
+    if ( res < 0 )
+    {
+        printk("imx-uart: Unable to retrieve the IRQ\n");
+        return -EINVAL;
+    }
+    uart->irq = res;
+
+    uart->regs = ioremap_nocache(addr, size);
+    if ( !uart->regs )
+    {
+        printk("imx-uart: Unable to map the UART memory\n");
+        return -ENOMEM;
+    }
+
+    uart->vuart.base_addr = addr;
+    uart->vuart.size = size;
+    uart->vuart.data_off = URTX0;
+    uart->vuart.status_off = UTS;
+    uart->vuart.status = UTS_TXEMPTY | UTS_RXEMPTY;
+
+    /* Register with generic serial driver */
+    serial_register_uart(SERHND_DTUART, &imx_uart_driver, uart);
+
+    dt_device_set_used_by(dev, DOMID_XEN);
+
+    return 0;
+}
+
+static const struct dt_device_match imx_uart_dt_compat[] __initconst =
+{
+    DT_MATCH_COMPATIBLE("fsl,imx6q-uart"),
+    { /* sentinel */ },
+};
+
+DT_DEVICE_START(imx_uart, "i.MX UART", DEVICE_SERIAL)
+    .dt_match = imx_uart_dt_compat,
+    .init = imx_uart_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 02:52:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 02:52:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393344.1632143 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wV-0001Ja-Rr; Tue, 18 Aug 2026 02:52:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393344.1632143; Tue, 18 Aug 2026 02:52:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wV-0001JT-PF; Tue, 18 Aug 2026 02:52:47 +0000
Received: by outflank-mailman (input) for mailman id 1393344;
 Tue, 18 Aug 2026 02:52:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1ww9wT-0001JN-Mq
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 02:52:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww9wR-00DVhL-Er
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 04:52:43 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8af-bab6-0a2a0a5309dd-0a2a4508976c-22
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:43 +0200
Received: from [209.85.216.44] (helo=mail-pj1-f44.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8f9-f659-0a2a45080019-d155d82cdc00-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:52:43 +0200
Received: by mail-pj1-f44.google.com with SMTP id
 98e67ed59e1d1-38de840f2f0so3438473a91.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:52:42 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d3b40basm4333605a91.14.2026.08.17.19.52.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 19:52:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787021561; x=1787626361; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=bQe/YNeMzslWflwKz05RqhD/PfB8cMsJmRD4V0ONpOI=;
        b=FEmlDpDYA5Clrp8wPHl/IFQ/IwHxtTqYCl2chyj6bUNYluKpaaYY3bxGSWj7+WG7Va
         7kHM4DMkcqZ6HVQnK9/bq9nY7iaZTwNR+P2Vj+zkZnCFQYvtaoSl5aNwwZ9+KR1W/tjb
         Z+XYnbhx7B1l2hbf/Zx9Uni30PW4Xv3HHQoTynxxP+w7B0C6E369/upcXUZvsvR8BzWQ
         Z8XMP31Czjp3t/Skm6ONeosXiu17aDSMsCv00YLAwltbek/QM4+LMlhC+U8ayWD16lKk
         ev5m70Zj9RX+ZvGqqmW9euhDH0gYQzTX6bfhKx1sjOT5OQUZ8s6GRvMtT80h+5m5GEkE
         haDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787021561; x=1787626361;
        h=content-transfer-encoding:mime-version: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=bQe/YNeMzslWflwKz05RqhD/PfB8cMsJmRD4V0ONpOI=;
        b=YmgkU+s1BTN5yOPtF6uvIF9IrMFEaIffMyohusE6+pkZqJoa+/GRBYQ6fkuWVDDXto
         9gyffNesp9zTOu1/iiuVDYZnfx7bwiyehfI7eh4m60sXw033t6gnatlZUHzrtiJ3hXUa
         5pH05WcwAotzEAcK8muT729cWVFEpi8bfV/I+mEhrYpktgkERfBd/Qp/1gFAEho2thQK
         Xp7Q08v7V3qs2avnEUVxJEHrsYzIn2KksVJrzPjQWb4fENPICbiiV8rlMeM41cElaimd
         Y7G/jRmacxtAhtj/Yz5bWV+Y1FjiEnnnq4lIc+aSBYbY0AukjFA5+vJtoOuDxOEZazHN
         nbjQ==
X-Gm-Message-State: AOJu0YxLlpWdHyquKbgLnuf2Be6nerTDjs+u2b9iU911UzDLAMHRLrmV
	SNM8e7z+eHtyWApy30aSMkskEalFJ4EFYD5EkyHSZCOJe3AT+/OB1p+gdek9sUyq
X-Gm-Gg: AR+sD13atb2wJDzpF/DtM9F9xDHWUNfXkAQX90EJekbkPZyQE6EvmTbkx3LvdMH3sVJ
	MrgYannnEE0bmLHSyAEIvKT/kSgb8eTXfTXMDR2Y4fsealLnZGRV2zkMwOs2nwmcIlgdsOW2Uuq
	+puAVZH3w/kwquiLn97PDp1DvkCDFpb8XmDZ1FUHrk6q59qsbuqkVmaaYN/sYq73tQyjzPzj8b2
	Lx2bXINVwVJ2zByBKWM3SIYyVrNbfdOZIjCHPvHi+1rFeoKNX+aVeBUr1jy5m1j/fDhZ2TJCLGJ
	9yGtw+yZFLHXt/8V4E1B5dNhpGQDySJsgZy5UQX02i4qwNgWcsuDD9iHAjqMfc4MBVCUILupL/l
	c/TxJzjprwB6EH82LyOhmGscJopyqUUQ/3hP6sXHAiyRbP5HIEdVusvWuWOBxMoMvD31QepICbr
	676xgEwIYVACo+euJNhfR8AyPAfmLl3lwMWpIu7JaLPQWeN+B00Djto7ZmMC1CLMtQln6kNqnIz
	0au8Vv+obfhXEcmcSrmwve6YNv3EO6Bx1g9/KOkmy4=
X-Received: by 2002:a17:90b:5884:b0:38f:efed:5445 with SMTP id 98e67ed59e1d1-3933b7c3b7cmr32452216a91.4.1787021561039;
        Mon, 17 Aug 2026 19:52:41 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v2 0/4] xen/arm: add i.MX8M platform and UART support
Date: Tue, 18 Aug 2026 10:52:20 +0800
Message-ID: <20260818025224.4165503-1-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787021563-D775B87B-0E7FC015/0/0
X-purgate-type: clean
X-purgate-size: 3115

Following Michal Orzel's review of v1, this series adds Xen support for
the NXP i.MX8M family (i.MX8MP / MQ / MM / MN).  It provides the console
UART driver, its early printk, the platform glue (SiP SMC whitelist for
the calls the dom0 kernel issues to TF-A), and a MAINTAINERS entry.

Tested on i.MX8MP (4x Cortex-A53, GICv3) with the vendor kernel 6.18:
dom0 boots to login on the hypervisor console, and a domU starts with a
PV disk and virtio devices running a full Wayland distro.

Notes for reviewers:

- Unlike i.MX8MQ, the i.MX8MP device tree uses the GIC as the root
  interrupt controller (interrupt-parent = <&gic>), so no device-tree
  workaround is needed and power domains keep working.

- The i.MX8M family has no SMMU, so device passthrough relies on the
  1:1 direct-mapped hardware domain.

- The SiP SMC whitelist forwards only the specific subfunctions the
  dom0 kernel issues, extracted from the vendor kernel call sites.
  DDR DVFS is left at service level because its reg1 is a frequency
  setpoint rather than a fixed subfunction id.  No call was denied at
  runtime.

Changes since v1:

Patch 1 (UART driver):
- Documentation narrowed to the i.MX8M family (dropped i.MX6/7).
- Relicensed the new files as GPL-2.0-only.
- Dropped the stale file-path lines from the file headers.
- Renamed the header guard to ASM_IMX_UART_H.
- Removed unused register/bit macros; header is now asm-safe (BIT(n, U)).
- Also clear UCR1_TXMPTYEN on init; documented that the console is
  driven entirely through UCR1.

Patch 2 (early printk):
- bne -> b.ne.

Patch 3 (platform):
- Build the SiP function IDs with ARM_SMCCC_CALL_VAL (IMX_SIP_FID),
  matching the i.MX8QM platform.
- Whitelist per subfunction (GPC, SRC, NoC) instead of whole services;
  DDR DVFS and SoC info kept at service level with a comment on why.
- Dropped the BBSM call, which is not issued on i.MX8M.
- Fixed the misleading "secure RTC" comment and a stray space.

Patch 4 (new):
- MAINTAINERS entry, as a separate patch.

v1: https://lore.kernel.org/xen-devel/20260814162535.331459-1-onlywig@gmail.com/


Wig Cheng (4):
  xen/char: add classic i.MX UART driver
  xen/arm64: add early printk for the classic i.MX UART
  xen/arm: add i.MX8M platform support
  MAINTAINERS: add myself as reviewer of i.MX8M related patches

 MAINTAINERS                           |   7 +
 xen/arch/arm/Kconfig.debug            |  12 ++
 xen/arch/arm/arm64/debug-imx-uart.inc |  37 +++++
 xen/arch/arm/include/asm/imx-uart.h   |  57 +++++++
 xen/arch/arm/platforms/Makefile       |   1 +
 xen/arch/arm/platforms/imx8m.c        | 152 +++++++++++++++++
 xen/drivers/char/Kconfig              |   8 +
 xen/drivers/char/Makefile             |   1 +
 xen/drivers/char/imx-uart.c           | 226 ++++++++++++++++++++++++++
 9 files changed, 501 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/arch/arm/platforms/imx8m.c
 create mode 100644 xen/drivers/char/imx-uart.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 02:53:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 02:53:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393351.1632181 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wk-0002Hq-RH; Tue, 18 Aug 2026 02:53:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393351.1632181; Tue, 18 Aug 2026 02:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1ww9wk-0002Hj-Mx; Tue, 18 Aug 2026 02:53:02 +0000
Received: by outflank-mailman (input) for mailman id 1393351;
 Tue, 18 Aug 2026 02:53:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1ww9wj-0002GO-Ep
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 02:53:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1ww9wi-005CSk-SC
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 04:53:00 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c8da-8faa-0a2a0a5109dd-0a2a4501ccf4-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:53:00 +0200
Received: from [209.85.216.53] (helo=mail-pj1-f53.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a83c90b-5984-0a2a45010019-d155d835f059-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:53:00 +0200
Received: by mail-pj1-f53.google.com with SMTP id
 98e67ed59e1d1-38ec1402b05so3260515a91.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 19:53:00 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d3b40basm4333605a91.14.2026.08.17.19.52.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 19:52:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787021579; x=1787626379; 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=LmPSKrMbhSlQ3VAakH/YeUU+H9erldiN9BSC2cOsGzs=;
        b=PBD2mBRLaLdWw6vmRafQK40MMX80kHCZi+f/X7sfgFychshAgLi4FH7QR/mmqmj66Q
         y8x5KYyPakO7u4eLVYMjzDidS2KtogeLzJchpvLKZuPwQrx+zbg4X/yPFbA62SXvMzhg
         1S/2wgMFK9+Q42t/G9OJT9ZUr4HFr/mKEuLKhpKRkbwDy67563Lk+FY09mnoVbcXi/R2
         N16i5jYKxCjriIbowcb5Wpme+c1AhOwtumMJQvz2nU4iwIIdNswej2+J3nc09Z1FQn7u
         8RjGIGf2hzDoGyOomoBgHLfvT9I8fCVgoJpVrcks9Wj4tV1o0AqF7iCQWi7aXXT3ltZG
         HOdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787021579; x=1787626379;
        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=LmPSKrMbhSlQ3VAakH/YeUU+H9erldiN9BSC2cOsGzs=;
        b=TxWVB11TgKzbosmqQ+BJU0kU7K/ZMsajCZCzwmS6GAsvMjuPwopv95H99RN2MWF4Y6
         dYMlgc+iD2W8d32xae8pKyCj2vjGNV5sn0KJD07XZCIr2jvLY/bjAtUKN6T+eITPX/Lp
         5LndtmxeQP+50ihw2/7f/bYNxzDi3MH2SIMwtAFr+GApB6tWXNcMPBqgu7UatBXigy54
         n5NU7HiPFb5n7ebti1OB00s8T6zp8LK0fQWgp8roHdhB2QambEvkJfFg5Mzus2GFTLyQ
         NkT1LYIe1JEm4YkbmG+ACUVq2O4lzncuUONmjRI7fQ5ZeTsVUxRxhn5JG4y2UPgiGeZI
         OOxg==
X-Gm-Message-State: AOJu0YyaZ4Q13TXcTPvrNm2lGwwspQj72l+OLvu1T+F0LLfgKiy2Yaui
	qz4CCesYpAWpWclSqut5U73f1GHIl5WoX+y7fgHHlZkka0RbdXzAQmkTo93r8BB9
X-Gm-Gg: AR+sD12wtHXhJaDWh6VN4FeoA32v8aNoZj4SmtnsZNZ+gqF1MXM2Up/gUsy2uZH2rGu
	yxK80yzzrF/Yt3pJ6PGJrWVHrOaUtchB7QrzqAsTD8AaynnCyiuP0P+mJQM1RsWMsJ6SV/VjuN7
	7nHUSAPt+POsYUIDxek3ZtMlIAtCKAF0I3U4WMwGmIQSZHINLqLph4oWg/NV8Ym9jaXGN6evPBR
	2+bzXtS3ayTyo7bREIwvwlz4D709V54ESO7ZcUWCp8D5u5D2sSExY9JMW+AQbWruZkn14PLsIJS
	MB76rGpQkUY+ErrtJu+dOgbnl834mmxQhTW0rbltgpSbHTKZh5zyRnKYOy5XtJuhEHX1TyakVHn
	bqGF2EPPzpFjnHWJjh0U1hVFQ8fi8qdcrGciraI1kczm2ysl81LlqFJpKRTAo/Xs9ZkRzevq5fr
	578c8jGAVVStnU0q/O7XyazqRpqBpGSAPJ2bQIOr4qhsW/eegC9lJQcurRR0kP6WMeu2BKvMbQT
	n5wAgbtQJxQ9PY3OfdXYYIKqaItfVIs
X-Received: by 2002:a17:90b:224e:b0:38e:6a44:671b with SMTP id 98e67ed59e1d1-3933b506db9mr25497993a91.0.1787021578702;
        Mon, 17 Aug 2026 19:52:58 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v2 4/4] MAINTAINERS: add myself as reviewer of i.MX8M related patches
Date: Tue, 18 Aug 2026 10:52:24 +0800
Message-ID: <20260818025224.4165503-5-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818025224.4165503-1-onlywig@gmail.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787021580-1FE68757-D59D1D7C/0/0
X-purgate-type: clean
X-purgate-size: 752

I wrote the i.MX8M platform and UART support and can help review
patches touching these areas.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ed0ffa608f..0434377fe1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -364,6 +364,13 @@ F:	tools/misc/xenhypfs.c
 F:	xen/common/hypfs.c
 F:	xen/include/xen/hypfs.h
 
+IMX8M SUPPORT
+R:	Wig Cheng <onlywig@gmail.com>
+F:	xen/arch/arm/arm64/debug-imx-uart.inc
+F:	xen/arch/arm/include/asm/imx-uart.h
+F:	xen/arch/arm/platforms/imx8m.c
+F:	xen/drivers/char/imx-uart.c
+
 IMX8QM/QXP SUPPORT
 R:	John Ernberg <john.ernberg@actia.se>
 F:	xen/arch/arm/platforms/imx8qm.c
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 05:43:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 05:43:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393391.1632188 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCbq-0007Jr-0G; Tue, 18 Aug 2026 05:43:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393391.1632188; Tue, 18 Aug 2026 05:43:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCbp-0007Jk-Tu; Tue, 18 Aug 2026 05:43:37 +0000
Received: by outflank-mailman (input) for mailman id 1393391;
 Tue, 18 Aug 2026 05:43:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwCbo-0007Je-U3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 05:43:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwCbn-00DqME-P8
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:43:35 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a83f0f8-bab6-0a2a0a5309dd-0a2a4501de26-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:43:35 +0200
Received: from [209.85.208.44] (helo=mail-ed1-f44.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a83f107-5984-0a2a45010019-d155d02ce835-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:43:35 +0200
Received: by mail-ed1-f44.google.com with SMTP id
 4fb4d7f45d1cf-6a3efa2b38aso54370a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 22:43:35 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c217fecb5basm135337566b.24.2026.08.17.22.43.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 22:43:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787031815; x=1787636615; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=uj5ouZ8w73nv2SuftarM6ZvYwcksL+tx8lGaHlWS118=;
        b=WySCVVyTbcQXpLlMsN+PmoPywiXNeEnahkKDe8DsM49aukYCgx4pGpezm9AMeGgz/T
         VEyF1HnF4iCJd7BaR2QZo47ZpuQbDOIWHF+WVMWLZ6MwaAPRnmxAs+FMRhZb+9rUASlt
         nbSZZR0C8TWEEB/FNCiCRl3zbdgP2W5iM9jx6SN777csZm7dUa4zHxI+/A0B6pvAUK2a
         YpGHxUr2HtnlsfhlYVpW80MTKVxQJ/ZSzzOPiZNebt0lSNgNpLSs7fam3xAwUTrcbWU/
         K49744cOcUg2ehrGr+VcU8XunoFfBnvbzbGpWakRo7TCzDUEqWEYEyVhRLTkha+FYH/r
         4DKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787031815; x=1787636615;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=uj5ouZ8w73nv2SuftarM6ZvYwcksL+tx8lGaHlWS118=;
        b=q/yXT91XtXhS+wUuUZac83ij4xTqWEj/Tl4pI6ggcvj9IyNQuQ1pWYcyeeEVPm6r7T
         j8mEFGaJVMRw3hjba9FX4l7EcjYq8DfLV/L9RJvxlbj7KquG0TXXYbGcWcjcMiJcm/qn
         4WLOmMmQAcNWjQ+aly3wNNAF1ZsSlHpReYgnVvSEsVUFqreZ1qgIklIA5TmrSPTeCAHY
         a4GTjjhn0dHo1rcIHX7lAY2SDBI2HxqehU4lppWm7xnPbMyeTtcF5SIFsXXyUgeXPC6C
         TQ6LWVJWfkItg0lcRBz0N8cN8vnyojQTKGzsy/BN1KDNmlhYQE6NGXB+oCjH0+3z9tgH
         VTxQ==
X-Forwarded-Encrypted: i=1; AHgh+Rp8ChoByE1usxoounRm/PILmIJYq9s6bU+1lQFxKvLpgMaBl8HQbxIlO2mFAgfhc/LxxeL9k77rf7c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHYGKkNfj3WPEAmk6V0PTaHkh67rlpjFYVVlBMbu7ohsrl7eJl
	0O8er8RTdj0TRqCactcE6SXDMjGABhVMG2Bm6ptTHcg5Sm2+aY4tHNkvzlkKCLHvRSU=
X-Gm-Gg: AR+sD11lq5tOfcEB03gkXCzz5FF8hkKcoIKeepnL5aAx0XQktBx9bXpr7hvOhSWDZ0A
	z04PDbvLKsrtbaDDWZjY/hTiu+ct7dn3RJpo4tCvStBsh/vdLFg/Q+mjeqE8IHV5ObXZXwoVdsi
	ovcE03JRXmSyU6wYyXQBVo+CWAJIEmLqskeSF5J/C8blDCKBKjidlfZwv0OPR2OIMFTW0IHBSlK
	3QvC4M5lmMpTjAVo8E9peT2IETh08hiZJ4NLrkweMysPY/xYQpUi2jZVfWqYs/mvX6vuOg2RfzV
	+IJa0rgblUQdzavqjwUDCezngVhegKEwBNSc9GpN7YYA4+qLh431PJNx5/s3upPPPpen/hzMnXw
	CmEkUzrrDBLqA7zhcdnEfAxuawdMKfZZk2ReqweF/sLTGz+tM5ezCmaarw08uL9dLOfgpl0H7N3
	Eg/4wgXEEfiPO0CF/0lwLx2rNpvMEPsf2cm2dzYBjyurt2/Z9kOVIHIHb0tYiOgL8Yj3OWhY7q8
	48efEbLE6tu8/dx0cHG78Zfw0+21Bx2LtjJNYpUSL2oXRpm7xvBWrnW5F2eaAVjrbfQ2VSoBWoV
	q6QsUNhATZ7rU9OJBLYLjqRz
X-Received: by 2002:a17:907:f448:b0:c16:8adf:f183 with SMTP id a640c23a62f3a-c212a0443cfmr1374879966b.14.1787031814968;
        Mon, 17 Aug 2026 22:43:34 -0700 (PDT)
Message-ID: <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com>
Date: Tue, 18 Aug 2026 07:43:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <aoM4ufGg8QO51XB9@end>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------tQB5j0FSmt5iRAzDX8p0gRza"
X-purgate-ID: tlsNG-d62444/1787031815-C495A757-FBF61EC0/0/0
X-purgate-type: clean
X-purgate-size: 7644

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------tQB5j0FSmt5iRAzDX8p0gRza
Content-Type: multipart/mixed; boundary="------------6bVqFvJnMDP0UEC8xwTKNt0t";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
Message-ID: <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
In-Reply-To: <aoM4ufGg8QO51XB9@end>

--------------6bVqFvJnMDP0UEC8xwTKNt0t
Content-Type: multipart/mixed; boundary="------------kZsM7JLqna0GOsHQvKS1f2o0"

--------------kZsM7JLqna0GOsHQvKS1f2o0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTcuMDguMjYgMTg6MzcsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4gSnVlcmdlbiBH
cm9zcywgbGUgbHVuLiAxNyBhb8O7dCAyMDI2IDEwOjI0OjAyICswMjAwLCBhIGVjcml0Og0K
Pj4gT24gMTcuMDguMjYgMDk6NDgsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4+PiBKdWVy
Z2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIwMjYgMDk6MTg6NDEgKzAyMDAsIGEgZWNy
aXQ6DQo+Pj4+IFRoZXJlIGlzIG5vIHVzZXIgb2YgbGlicGNpIGxlZnQgaW4gc3R1YmRvbXMu
DQo+Pj4+DQo+Pj4+IFJlbW92ZSBsaWJwY2kgZnJvbSB0aGUgc3R1YmRvbSBidWlsZCBzeXN0
ZW0uDQo+Pj4NCj4+PiBXb3VsZG4ndCBpdCBiZSB1c2VmdWwgdG8ga2VlcCB0aGlzIGZvciBh
bnlib2R5IHdobyB3b3VsZCB3YW50IHRvIGRyaXZlIGENCj4+PiBQQ0kgY2FyZCBmcm9tIGEg
c3R1YmRvbWFpbj8NCj4+Pg0KPj4+IEkgbWVhbiwgaW4gdGhlIHpsaWIgY2FzZSwgaXQncyBy
ZWFsbHkgYSBtZXJlIHF1ZXN0aW9uIG9mIGJ1aWxkICYgbGluaywNCj4+PiBzbyB3ZSBkb24n
dCBuZWVkIHRvIHNoaXAgaXQsIHBlb3BsZSBjYW4gZG8gaXQgdGhlbXNlbHZlcyBlYXNpbHkg
bGlrZSBmb3INCj4+PiBhbnkgb3RoZXIgbGlicmFyeS4NCj4+Pg0KPj4+IEJ1dCBoZXJlIHRo
ZXJlIGlzIGFjdHVhbCBwb3J0aW5nIHdvcmssIHRoYXQgd2UnZCBiZXR0ZXIgbm90IGxvc2Ug
YnV0DQo+Pj4ga2VlcCBzaGlwcGluZy4NCj4+DQo+PiBUaGlzIGlzIGFsbCBzdGlsbCBhdmFp
bGFibGUgdmlhIGdpdC4NCj4gDQo+IE5vLCBpdCBpcyBub3QgcmVhbGx5Lg0KPiANCj4gSSBr
ZWVwIHJlYWRpbmcgdGhpcyBhcmd1bWVudCwgYnV0IHBlb3BsZSB3aWxsIG5vdCBrbm93IHRo
YXQgc29tZXRoaW5nDQo+IGV4aXN0cyBpbiB0aGUgZ2l0IGhpc3RvcnksIGFuZCB3aWxsIGp1
c3QgYXNzdW1lIHRoYXQgaXQgZG9lcyBub3QgZXhpc3QNCj4gYW5kIGhhcyB0byBiZSB3cml0
dGVuLg0KDQpXaGF0IGFib3V0IGFkZGluZyBhIGNvbW1lbnQgdG8gdGhlIHN0dWJkb20gTWFr
ZWZpbGUgaW4gYSBzZXBhcmF0ZSBwYXRjaCwgbGlrZToNCg0KIyBwY2l1dGlscyBzdXBwb3J0
IGhhcyBiZWVuIHJlbW92ZWQgd2l0aCBjb21taXQgPGNvbW1pdC1pZD4sIHJldmVydCB0aGF0
IHBhdGNoDQojIGluIGNhc2UgaXQgaXMgbmVlZGVkIGFnYWluLg0KDQpJIHRoaW5rIHRoaXMg
d291bGQgYmUgcHJlZmVyYWJsZSBvdmVyIHVudXNlZCBhbmQgcHJvYmFibHkgYml0LXJvdHRl
biBjb2RlIGluDQp0aGUgcmVwb3NpdG9yeS4NCg0KDQpKdWVyZ2VuDQo=
--------------kZsM7JLqna0GOsHQvKS1f2o0
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------kZsM7JLqna0GOsHQvKS1f2o0--

--------------6bVqFvJnMDP0UEC8xwTKNt0t--

--------------tQB5j0FSmt5iRAzDX8p0gRza
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB4BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqD8QYFAwAAAAAACgkQsN6d1ii/Ey+O
KQf3cE0awkimgMkVGuPlyZHJKpE67HDAcz0BFRMDEresolAZrJfiNh3hl6hVIL+VcRc019huIoPx
gsPTILajwsSHNVeWd1ojXUEtMrDMbSGdx4N4lDp4gnxlzv00ygBYS4rYC5h5MunYTUN/u4jp/8+v
8tLVrX/m+E93wx6tXPiRvW9mssts194O6B2U9jNozuVChKACCQl3J6D2VD29PhPgFhw2x592nPbf
2Up+HjsyYvMHm0rn2t5Pc4X5Y/LH4CjPr1mkuJc6ak4EZxOueI0SELV3buGiO45n0whLmshJjKV3
NUtbEFtc/i2rZhuipJol0vkR3AD3j47TaFiNwOBH
=uv3p
-----END PGP SIGNATURE-----

--------------tQB5j0FSmt5iRAzDX8p0gRza--


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 05:54:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 05:54:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393400.1632197 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCm4-0000aQ-0i; Tue, 18 Aug 2026 05:54:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393400.1632197; Tue, 18 Aug 2026 05:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCm3-0000aJ-UE; Tue, 18 Aug 2026 05:54:11 +0000
Received: by outflank-mailman (input) for mailman id 1393400;
 Tue, 18 Aug 2026 05:54:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwCm2-0000aC-6w
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 05:54:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwCm0-001CzV-Pn
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:54:08 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83f364-8faa-0a2a0a5109dd-0a2a4502985e-26
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:54:08 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83f380-6ca4-0a2a45020019-d1558035b556-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:54:08 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-49557167508so42514895e9.1
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 22:54:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a5684e06sm6300675e9.1.2026.08.17.22.54.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 22:54:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787032448; x=1787637248; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=td5FVs7/u7fTQ6+B+MfIwHKV96K7nJhHdTi0XeTAmzA=;
        b=WFiA+cCZWPijBxCl6rFc7G6LyOlXkUx7I5aq/EgezFT636sRvcmCZffBVD+hsUeIu5
         lD7Nxil+HMoqunBLcrXtaUxY6kX1cAaJa7aM2FXkPizIohspBc2ep83L52/C7rsAiSkZ
         ATvwFpulJyXMwt/zx9fYmvvT4+1i0HDKItoVATmMIsKFwEB5lBVHRz24Qzwfy/KSG/6o
         h0sEOgoHlPHb3RaQ7DNgNEZ7W7CmENXO/1deg393KytbkFORNFh6XIALNvaTw6hMVL7j
         0NVd+2QTE6ll9lUsjQjHJfAnRjfEF2h+slCiquAyMIZ76WAp+WbxfNW4afeyWH6y8I2R
         JwaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787032448; x=1787637248;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=td5FVs7/u7fTQ6+B+MfIwHKV96K7nJhHdTi0XeTAmzA=;
        b=hiaQ6eIIoaGco40jENPg5oHdvu8RCW3isUqV2Y593Os175ztDtG4XOg941T7TyeFP9
         D8ELuUGSSe8cI7+XW4w/bZt41BKPOo3jFuDVla7mfh5oGInu/UGdiRWp45N1sUWMckiX
         L7jOhuwRub9iS5HRev1seqZuW2dT1oVKaBIxrBeOIqOwBBRiw2jn+9SS0oA93ted83Kz
         9H8qJYTeiY8GlIAiov2T8o7+II3JBZIT4lqWaCfcN0CgMqfvcx5OoGfijFA+kBhUY+Ij
         UYKeuOP6kOQz7fZSaMY/7A+ZT1qZgOEpG+MJqL7bD3wv7JN0u8ghI0q8iBm5pKSof+8H
         o6YQ==
X-Forwarded-Encrypted: i=1; AHgh+RrpK+4Z9770PFIFBUYdm25+oWpTXUChRur6tqdfk8yAqj434oIwTTOPTlJpV6KRkY+0sIjSGmpcVmY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyNUAO9r8bfbMx2o8cSrNo4idQY6xzngOOeJIP7LwQnsaz26mTY
	gKuD+0CosFrz483feKxVaj0ZAA+yOwaWhDsFvOpOoQINVjRd/+eAO0aWIzAQAYt3/w==
X-Gm-Gg: AR+sD10Q0Iry79MKuOjaEETBa2CNcyrf/2pcIXzNo8W7WRVPiH9aMe48jUCs+Bs0AdY
	804P5UH4FQ9zQyspUGX3RKYEkPx2xJUNHlbJtXab/CHhwaSCQ4DxR7nx9HM7+qIb9R8j+PtloQw
	ZHHFNxCrAevjS0nZlhanpvZ6FV1vTU/ird21cgw5yLQUJSh/uJNRzY6L7pnt4/8xrmLEWaSkP3e
	hKx+yyymE4KIgv+Iow7eiqCscr1JYVTUFK/BokpK7c/LhmlZeh/DHr5Zxfhi1qK54lmmOJzNijF
	fvgNm437MYDiemvVbCKj4wOz4EiMJpC7iKl2T8N0dhq/lIO20lF8IoyHnAsm07DITPQEvZQsj7J
	Ex3zurK+5UsGwdJR2LnvtoRDyI3KN51U5Ydb3rs8xw3fJxJvTIPCdHLudyBvtZVffuEFvgqJ1OC
	2ZgFRTrKOl1zsk3KTCjwgyG+QqdwkZbAciJaYHJaJSncPgnR0lqSOCeHIrJ7lgNccJXZa/GFXe6
	kp9AsMYRAIucECCfP+J3yL1mLknEDpXCNJtYa852DQk1wTJuu2y
X-Received: by 2002:a05:600c:358a:b0:496:c06b:9fb4 with SMTP id 5b1f17b1804b1-4999fb940c5mr88707925e9.14.1787032448167;
        Mon, 17 Aug 2026 22:54:08 -0700 (PDT)
Message-ID: <d51362ab-e004-43b7-8825-d315c1cb41f9@suse.com>
Date: Tue, 18 Aug 2026 07:54:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/nmi: Fix mis-classification of watchdog NMIs
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260813174319.1682009-1-andrew.cooper3@citrix.com>
 <4f58e236-c40b-4fcc-82e8-5b6f3eafe656@suse.com>
 <33aab2bd-db13-43f6-9616-5e75fd79b81d@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <33aab2bd-db13-43f6-9616-5e75fd79b81d@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787032448-F2EB32AC-24742BF9/0/0
X-purgate-type: clean
X-purgate-size: 3335

On 17.08.2026 17:55, Andrew Cooper wrote:
> On 17/08/2026 9:30 am, Jan Beulich wrote:
>> On 13.08.2026 19:43, Andrew Cooper wrote:
>>> It used to be the case that cpu_data[] inherited the BSP's cpuid_level until
>>> the AP had calculated it itself.  Following the rework, cpuid_level has a
>>> placeholder 1 until it is caluclated propely.
>>>
>>> setup_apic_nmi_watchdog() happens to be called on the BSP after SMP bringup,
>>> meaning that the first call is on CPU1.  It is also positioned in the window
>>> where cpu_data[] is garbage.
>>>
>>> As a result, setup_p6_watchdog()'s one-time calculation of the performance
>>> counter width falls back into Pentium compatibility mode assuming 32bit
>>> counters.  This causes a watchdog NMI which is delayed a little (e.g. from an
>>> SMI), to appear as if it hadn't overflowed, and therefore be (mis)classifed as
>>> not a watchdog NMI.  On systems where unknown NMIs are treated as fatal, this
>>> results in a spurious crash.
>>>
>>> Switch setup_p6_watchdog() to use boot_cpu_data.cpuid_level, which is how this
>>> is checked almost everywhere else.
>>>
>>> core2_vpmu_init() used the same pattern to look at leaf 0xa.  Despite being
>>> init code and only running on the BSP, {boot,current}_cpu_data are different
>>> objects, so switch it over to checking boot_cpu_data.cpuid_level too.
>>>
>>> Fixes: 7126b7f806d5 ("x86/CPU: re-work populating of cpu_data[]")
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Thanks.
> 
>>
>>> I hate this fix, but it's the only thing which I consider remotely safe to
>>> backport.  Recent attempts to alter CPUID ordering have 0 success at being
>>> bug-free.
>> How that? Collecting CPUID output should be doable almost first thing. There
>> are no (or in case of doubt: there should not be any) dependencies on about
>> anything else. Of course re-collecting may still be necessary after ucode
>> loading. Yet from what you say I must be missing something crucial.
> 
> I was referring to commits in Xen rearranging the boot sequence with
> respect to feature handling.  There have been many failures recently.
> 
>> With that in mind, I'm also questioning the Fixes: tag (without this being a
>> request to drop or change it): Using another CPU's data isn't much better
>> than using partially unset data. Unless we assumed full symmetry, at which
>> point re-obtaining of most data on the APs would be entirely useless. Hence
>> the issue was pre-existing, with one bug there hiding the issue addressed
>> here.
> 
> Copying the BSP is less bad than the current behaviour.  It's not
> necessarily ideal, but it's a damsight better default than the arbitrary
> 1 that this patch puts in place.
> 
> Even with the very old 64bit systems where mixing steppings was
> commonplace, I'm not aware of a vendor supported combination where
> max_leaf was different.
> 
> 
> The issue was not prexisting.  Prior to your rearrangement, the NMI
> watchdog setup found the counter width in CPUID and used it, without
> falling back into original Pentium compatibility mode.

FTAOD - with "pre-existing" I meant the using of the (possibly) wrong data,
not the particular issue of the NMI watchdog being affected.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:01:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:01:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393407.1632207 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCtA-0002JS-MB; Tue, 18 Aug 2026 06:01:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393407.1632207; Tue, 18 Aug 2026 06:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCtA-0002JL-Jb; Tue, 18 Aug 2026 06:01:32 +0000
Received: by outflank-mailman (input) for mailman id 1393407;
 Tue, 18 Aug 2026 06:01:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwCt9-0002JF-Ih
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:01:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwCt8-00Fgci-JJ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:01:30 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83f53a-bab6-0a2a0a5309dd-0a2a45088aa2-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:01:30 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83f534-f659-0a2a45080019-d1558029d87c-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:01:24 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4998e0916faso23063665e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:01:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d10ba73sm105465885e9.13.2026.08.17.23.01.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 23:01:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787032884; x=1787637684; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=NOp3YRdEs0Br3Bo1DJ4Emf3CGg1rsxA93QX7Vcmweq0=;
        b=gM8imaItgNuuoVDfAJGx0qPuDFvytYxvXBc2d/ZGVfcBUUhCHs2kJDqLuQiucWfjzf
         hUlNVajWimJqYWQxgzQVGuoA5wuds/4ZUQ/jPvn4lZnhEGHl1/Uum2oLde3fceudEQTN
         oWrhwl2cqkPzMpzf1tbskcdoEaMk3Xu5IiomoNSbE3aAIpXU3F7vpxjYoROwQrZq8QEf
         ySEfQ9lUEVLMD6+XzLBm+im3QgaU+tsP8Qphxx6AbbJgPweY3cwVEEwS6zcvipQ7OITT
         /zsl8FETowhXpXEsRMS/8bPG0z4HMyogbfZbg8tu000MBSKpxrcPQwYECEMoJXrTgBmZ
         msTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787032884; x=1787637684;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=NOp3YRdEs0Br3Bo1DJ4Emf3CGg1rsxA93QX7Vcmweq0=;
        b=JIlPZZPKx0B4KpzZm0g0dlzVDAodXa+Vm7V+ZE4akc60vNyYEU/taBDjjOWrR7STYh
         c3Fdqg9zylYm5RNZI4uEGs/Be9uP8wU0MJ25TWcnFt6oErWaJp5IwUKq7hxYDxoMO0jJ
         CPA7zf3aEjHhc/qTy5x/RzR5UJf8j4SxCoyavT9llEd8aaHGJUyc2irOXGmiTiYcbjOr
         Vd2hBPrAE444Y5AX8kuNdkQoJEVdTVQX7pno2SqKASFYZWf5fUsLvx+EqMIS62IRHI21
         k5Z/Z2n1UIqTdyOqCA7Mb/hy7o6503+K6nBpJQUCez8XBP7cmYlXd/dMQT8SkaHExIE2
         vHRA==
X-Forwarded-Encrypted: i=1; AHgh+Rq7bF1xf5W5a7KUBeUjuQBFZ7nYFj16AKL7UG0d7nCUHT9Gq+YYmSdrKoSsmWL+/PeU1LeDIvb7gUM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxF5vZstmnVSKQ+JSoefqNw+/k6G1w4h2EOfdZdD3Mc0uiayE0y
	IbRLJJWkIzAY1N4onK9W3tPZ/rgA3rafL69rg5Ownu6fF6Yi/jQlYOU/swHPOPUMsw==
X-Gm-Gg: AR+sD10RE7rD70B1stvqM70S/smZtTasP6+9tmCuAJlexkz7cgDYPJU4l/ksua1ibDp
	/OeASKpLfmksHqwRgKdKATdFvVa+rdlZNuVpdZ46leKbaSwJ8bDNre0P8MAn6+sg3ooLS0JEBzp
	DoNSXBKEZV6IN6pClmOHab9bD6EUSUrUlUUvpB1awCBrNy/8+J5a44VLtN9ga+SjnMqdl8rAyis
	dRO9qRrWfX8vHwnLO+Oo72B7yc5J+IL0FHLlqZ3en7Yk54Vw1UzcOprQhPsIZX5jR4qSYLbc+KQ
	X2+A2Pu14fkrF4B47UIOQz46sj42kIFSE7G2szg4jy0E/DkoaFW9RA4aJEUL4Umq2OmBsZNN2Vn
	CpF2aT6pKYdBmmV+r2cpORCi4rf2yhRnU3AwB5IVMkYhVhpFs/rANZ2KDLxZDRAAsEoNb+iCYqh
	hlSQGtNgDhsKD0zOoY5peRW7hQHDz+0YdnYpir0ytL7SWyCMdWupjYMQHRYRkw7OsnwHrnAgsnG
	F8aaQgRyQI6JfGxLl+OkokQ1XiV11qTLl3BtZWTLyxkbDDnf3Vv
X-Received: by 2002:a05:600c:820d:b0:499:7a36:88b with SMTP id 5b1f17b1804b1-4998794402emr532729175e9.5.1787032884143;
        Mon, 17 Aug 2026 23:01:24 -0700 (PDT)
Message-ID: <f40229a5-6108-4d92-b612-a9daa2c83474@suse.com>
Date: Tue, 18 Aug 2026 08:01:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/5] tests/x86: Introduce a userspace test harness for
 x86_decode_lite()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260803072006.9678-1-andrew.cooper3@citrix.com>
 <20260803072006.9678-3-andrew.cooper3@citrix.com>
 <dd065a33-0105-4527-92f5-f3f127422ee6@suse.com>
 <21d3fae8-e9b0-4c8a-a7b9-483a0257e44e@citrix.com>
 <b76b3fa9-cac9-401f-adc7-88f6881a64f6@suse.com>
 <5b358558-1b17-49b2-af5e-37981d11094f@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5b358558-1b17-49b2-af5e-37981d11094f@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787032889-D477387B-7D8B61CE/0/0
X-purgate-type: clean
X-purgate-size: 7307

On 17.08.2026 14:40, Andrew Cooper wrote:
> On 05/08/2026 7:45 am, Jan Beulich wrote:
>> On 04.08.2026 21:37, Andrew Cooper wrote:
>>> On 03/08/2026 5:03 pm, Jan Beulich wrote:
>>>> On 03.08.2026 09:20, Andrew Cooper wrote:
>>>>> --- /dev/null
>>>>> +++ b/tools/tests/x86-decode-lite/insns.S
>>>>> @@ -0,0 +1,703 @@
>>>>> +#include "macro-magic.h"
>>>>> +
>>>>> +        .code64
>>>>> +
>>>>> +        .allow_index_reg
>>>>> +
>>>>> +        .text
>>>>> +
>>>>> +DECL(tests_rel0)
>>>>> +modrm:
>>>>> +        /* Mod=0, Reg=0, RM {0..f} */
>>>>> +        _ add %al, (%rax)
>>>>> +        _ add %al, (%rcx)
>>>>> +        _ add %al, (%rdx)
>>>>> +        _ add %al, (%rbx)
>>>>> +        _ add %al, (%rsp) /* SIB */
>>>>> +        /*add %al, (%rbp)    RIP --> tests_rel4 */
>>>>> +        _ add %al, (%rsi)
>>>>> +        _ add %al, (%rdi)
>>>>> +        _ add %al, (%r8)
>>>>> +        _ add %al, (%r9)
>>>>> +        _ add %al, (%r10)
>>>>> +        _ add %al, (%r11)
>>>>> +        _ add %al, (%r12) /* SIB */
>>>>> +        /*add %al, (%r13)    RIP --> tests_rel4 */
>>>>> +        _ add %al, (%r14)
>>>>> +        _ add %al, (%r15)
>>>>> +
>>>>> +        /* Mod=1, Reg=0, RM {0..f} */
>>>>> +        _ add %al, 0x01(%rax)
>>>>> +        _ add %al, 0x01(%rcx)
>>>>> +        _ add %al, 0x01(%rdx)
>>>>> +        _ add %al, 0x01(%rbx)
>>>>> +        _ add %al, 0x01(%rsp) /* SIB */
>>>>> +        _ add %al, 0x01(%rbp)
>>>>> +        _ add %al, 0x01(%rsi)
>>>>> +        _ add %al, 0x01(%rdi)
>>>>> +        _ add %al, 0x01(%r8)
>>>>> +        _ add %al, 0x01(%r9)
>>>>> +        _ add %al, 0x01(%r10)
>>>>> +        _ add %al, 0x01(%r11)
>>>>> +        _ add %al, 0x01(%r12) /* SIB */
>>>>> +        _ add %al, 0x01(%r13)
>>>>> +        _ add %al, 0x01(%r14)
>>>>> +        _ add %al, 0x01(%r15)
>>>>> +
>>>>> +        /* Mod=2, Reg=0, RM {0..f} */
>>>>> +        _ add %al, 0x7f000001(%rax)
>>>>> +        _ add %al, 0x7f000001(%rcx)
>>>>> +        _ add %al, 0x7f000001(%rdx)
>>>>> +        _ add %al, 0x7f000001(%rbx)
>>>>> +        _ add %al, 0x7f000001(%rsp) /* SIB */
>>>>> +        _ add %al, 0x7f000001(%rbp)
>>>>> +        _ add %al, 0x7f000001(%rsi)
>>>>> +        _ add %al, 0x7f000001(%rdi)
>>>>> +        _ add %al, 0x7f000001(%r8)
>>>>> +        _ add %al, 0x7f000001(%r9)
>>>>> +        _ add %al, 0x7f000001(%r10)
>>>>> +        _ add %al, 0x7f000001(%r11)
>>>>> +        _ add %al, 0x7f000001(%r12) /* SIB */
>>>>> +        _ add %al, 0x7f000001(%r13)
>>>>> +        _ add %al, 0x7f000001(%r14)
>>>>> +        _ add %al, 0x7f000001(%r15)
>>>>> +
>>>>> +        /* Mod=3, Reg=0, RM {0..f} */
>>>>> +        _ add %al, %al
>>>>> +        _ add %al, %cl
>>>>> +        _ add %al, %dl
>>>>> +        _ add %al, %bl
>>>>> +        _ add %al, %ah
>>>>> +        _ add %al, %ch
>>>>> +        _ add %al, %dh
>>>>> +        _ add %al, %dl
>>>> Perhaps also include %bpl, %sil, and %dil?
>>> They're not relevant to this test, and interfere with the intentional
>>> pattern set up.
>> Hmm, how does a particular pattern matter here? I don't think you test those
>> cases (or more generally an empty REX prefix) anywhere else.
> 
> There's nothing structurally interesting about those; I'm not testing
> the assembler, and x86_decode_lite() doesn't decode registers.
> 
> The ModRM byte has multiple structurally interesting interactions with
> REX prefixes, hence the coverage of Mod and RM value.

If covering _every_ bit pattern of ModR/M.rm is of interest, I simply find
I hard to see why also covering them empty-REX case should be of no
interest at all.

> The patten makes it trivial to look at the disassembled result and check
> the coverage.  (And spot the bug that's hiding in plain sight above.)

Oh, I see (now).

>>>>> --- /dev/null
>>>>> +++ b/tools/tests/x86-decode-lite/main.c
>>>>> @@ -0,0 +1,111 @@
>>>>> +/*
>>>>> + * Userspace test harness for x86_decode_lite().
>>>>> + */
>>>>> +#include <stdio.h>
>>>>> +
>>>>> +#include "x86-emulate.h"
>>>>> +
>>>>> +static unsigned int nr_failures;
>>>>> +#define fail(t, fmt, ...)                                       \
>>>>> +({                                                              \
>>>>> +    const unsigned char *insn = (t)->ip;                        \
>>>>> +                                                                \
>>>>> +    nr_failures++;                                              \
>>>>> +                                                                \
>>>>> +    (void)printf("  Fail '%s' [%02x", (t)->name, *insn);        \
>>>>> +    for ( unsigned int i = 1; i < (t)->len; i++ )               \
>>>>> +        printf(" %02x", insn[i]);                               \
>>>>> +    printf("]\n");                                              \
>>>>> +                                                                \
>>>>> +    (void)printf(fmt, ##__VA_ARGS__);                           \
>>>>> +})
>>>>> +
>>>>> +struct test {
>>>>> +    const char *name;
>>>>> +    void *ip;
>>>>> +    unsigned long len;
>>>>> +};
>>>>> +
>>>>> +extern const struct test
>>>>> +/* Defined in insns.S, ends with sentinel */
>>>>> +    tests_rel0[], /* No relocatable entry */
>>>>> +    tests_rel1[], /* disp8 */
>>>>> +    tests_rel4[], /* disp32 or RIP-relative */
>>>>> +    tests_unsup[]; /* Unsupported instructions */
>>>>> +
>>>>> +static inline void run_tests(const struct test *tests, unsigned int rel_sz)
>>>>> +{
>>>>> +    printf("Test rel%u\n", rel_sz);
>>>>> +
>>>>> +    for ( unsigned int i = 0; tests[i].name; ++i )
>>>>> +    {
>>>>> +        const struct test *t = &tests[i];
>>>>> +        x86_decode_lite_t r;
>>>>> +
>>>>> +        /*
>>>>> +         * Don't end strictly at t->len.  This provides better diagnostics if
>>>>> +         * too many bytes end up getting consumed.
>>>>> +         */
>>>>> +        r = x86_decode_lite(t->ip, t->ip + /* t->len */ 20);
>>>> For the excess bytes to at least be legitimate to access (not causing UB),
>>>> shouldn't finish_arr emit enough filler bytes?
>>> finish_arr is the wrong place, but I've folded in:
>>>
>>> --- a/tools/tests/x86-decode-lite/insns.S
>>> +++ b/tools/tests/x86-decode-lite/insns.S
>>> @@ -695,6 +695,13 @@ unsup_insn: /* Instructions that would complicated decode, or shouldn't be used
>>>  
>>>  END(tests_unsup)
>>>  
>>> +        /*
>>> +         * For improved diagnostics, we allow some overreading of the
>>> +         * instruction under test.  Ensure there are good bytes to read.
>>> +         */
>>> +overread_padding:
>>> +        .skip 20
>>> +
>>>          /* This is here to cause jmps to use their disp32 form. */
>>>          .section .text.other_section, "ax", @progbits
>>>  other_section:
>> How would this help? run_tests() is never invoked with tests_unsup[] as
>> argument. And run_tests_unsup() wants to only fetch up to t->len.
> 
> Oh, in which case nothing is needed at all.  I'll take it back out.

Yet then, as previously indicated, the possible overrun in run_tests()'
fetching will want covering. Hence why I suggested the particular other
place to put extra padding.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:03:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:03:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393414.1632216 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCvU-0002sE-1d; Tue, 18 Aug 2026 06:03:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393414.1632216; Tue, 18 Aug 2026 06:03:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwCvT-0002s7-Uy; Tue, 18 Aug 2026 06:03:55 +0000
Received: by outflank-mailman (input) for mailman id 1393414;
 Tue, 18 Aug 2026 06:03:54 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwCvS-0002s0-7C
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:03:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwCvR-00DvT5-KB
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:03:53 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83f5be-2eae-0a2a0a5409dd-0a2a4509ee06-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:03:53 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83f5c9-be1a-0a2a45090019-d1558030f17a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:03:53 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so49603825e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:03:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996188217sm485317795e9.13.2026.08.17.23.03.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 23:03:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787033033; x=1787637833; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=LabPGz6IlAPikEkXQ50zGIPTM2WVsLsnc+T4zZgumK4=;
        b=JIBheYvhz9nVafARBo5SNRNt1eEu4xabs5hHZLzfHBoILlNLOSQZzQyKtUNAvtdCet
         n+V+WOY2ruD3/c5UwwjKKo8Pks5WQglZAQ2d4fnH0aWuLoGh6IbtEtdSK8059IxQj8Uk
         1cIKHlEOjhnIuESOAkjeMgc5HDZ54HtazEivjapPl3dMQB+nxq+kPh1v1+Z0kNmAIJU+
         BCX+2WDX4e/x7s6P6e7Qcp4ccnUvdR353Afyb9PPlrQBmpUjyK7HeiNgYaRraBGpr+RT
         3YXZxl1c8E7rm8TXBF6CCe2jj2OLi6VlJE6bYyn4/zPEX4DniwDaJcHt9PhziaIg3Hbh
         y3Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787033033; x=1787637833;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=LabPGz6IlAPikEkXQ50zGIPTM2WVsLsnc+T4zZgumK4=;
        b=VDaKHBIeqJh8Mk4R8FrsdAOee6+FLwPML/YVbxJs8AyogMSP7uOxAS8dUHuVmIVHlY
         uguKloWtx6Jnnp0YprlmAlwSyEE4l59jLXYrCyuLRPrvaMIvSML6cmTbUjz+e2lME1eL
         3sXFEvTQ28doHV01JKZcrAJwunUgBWp4zAaN8FBiae7UbXL482auh/gcjDJwKmWt3jtk
         a/1qfP6ZoM36ivMsqtBHZQWcjOq9GCZfB4bVqywMSaTe0Iy7C4grwoJcIS/uJ2Poc7ew
         EB9jehB6kp3zsuJ7wI3qtR6zyr30K01VfHSI+REkoH9gmgYXgxK25n0NTDlb2aRP0q0A
         AChw==
X-Forwarded-Encrypted: i=1; AHgh+RqNUui6D4b5owZ9mB8fjf1eb+sodflbko8YY5w5JdfaH9v1zUg6qfNGB4B5UKRiJAYoCrlBsS4icMc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx14apSzAIEz3qE4g+d8sZ3SQAmZRYANwWbDMz1dm2sd+ywDmbz
	fJFnq005ukfA2HexZ1kf+QmYGapuWFlBLl9esiAQOSL7W91KmDLbP+9tM6QiGwaWHg==
X-Gm-Gg: AR+sD139tBiF5BLl5JQP1PCOVLM52blqNq/6+tuYUDBFs2ICqXQn7Wx6//+38eHlcJK
	L52BH0OEVN/LTRqDSavyLQk1Qpa0FT3LwKQ73X4pCPx3Wnuq8/UWYV4x7zTqViYCMxIwOtl7wym
	laeMBfFC5L2Ltg/C8HIx0mJCwmU2UPm+uDthw3cC29MlEnzar6pZ7KaC1MdbXCc6DmK4tg9tO/J
	dvKea0Dq6PVPPtF/A/f55RFA9PFHiSWi6vye9IF9kGJ+JL4pdVKTBswtn2YO3tgfaF+WNs7yfYo
	+kJsYGI03F5Q9Eg4NHd+qg9xLjv/iXwF6SnoUlnvFcA9pE2e96QJTpVAe4kKjRcdZFpvbk8RZjp
	LI1U/R8dx2aIEjCHUk8e+HB0PL0M0tLLB/O+b7UVP3BaOXRXFQVo7VphaPUh/20eZQAYbk/jSZO
	AcymSYmMYQBxUU34ygGaodgI9qun29N/MxHl6x8L8eN9dRaYHHUJU2SGylHrL/x7FS5QebBRoUZ
	bKxlNfCw2YpaCGkSA0V3Ze05sLhxuk3o1FjMYWHGNM/8mqWta3u
X-Received: by 2002:a05:600c:528d:b0:499:900c:9c69 with SMTP id 5b1f17b1804b1-499900c9e99mr361143465e9.9.1787033032884;
        Mon, 17 Aug 2026 23:03:52 -0700 (PDT)
Message-ID: <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com>
Date: Tue, 18 Aug 2026 08:03:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
Content-Language: en-US
Cc: Juergen Gross <jgross@suse.com>,
 Anthony PERARD <anthony.perard@vates.tech>, xen-devel@lists.xenproject.org
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <aoM4ufGg8QO51XB9@end>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787033033-3A8D9034-AB072B27/0/0
X-purgate-type: clean
X-purgate-size: 1029

On 17.08.2026 18:37, Samuel Thibault wrote:
> Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
>> On 17.08.26 09:48, Samuel Thibault wrote:
>>> Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
>>>> There is no user of libpci left in stubdoms.
>>>>
>>>> Remove libpci from the stubdom build system.
>>>
>>> Wouldn't it be useful to keep this for anybody who would want to drive a
>>> PCI card from a stubdomain?
>>>
>>> I mean, in the zlib case, it's really a mere question of build & link,
>>> so we don't need to ship it, people can do it themselves easily like for
>>> any other library.
>>>
>>> But here there is actual porting work, that we'd better not lose but
>>> keep shipping.
>>
>> This is all still available via git.
> 
> No, it is not really.

Question is - does this matter in the first place? If someone wanted to
drive e.g. a USB device, would we include USB code? I'm with Jürgen that
we should have in the upstream tree only what is also used in-tree.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:09:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:09:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393422.1632225 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwD0Y-0003bP-N6; Tue, 18 Aug 2026 06:09:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393422.1632225; Tue, 18 Aug 2026 06:09:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwD0Y-0003bI-JN; Tue, 18 Aug 2026 06:09:10 +0000
Received: by outflank-mailman (input) for mailman id 1393422;
 Tue, 18 Aug 2026 06:09:09 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwD0X-0003bC-Fl
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:09:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwD0W-007qFP-PI
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:09:08 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a83f6ee-bab6-0a2a0a5309dd-0a2a450b95ec-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:09:08 +0200
Received: from [40.107.200.53]
 (helo=CH5PR02CU005.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a83f702-b7e8-0a2a450b0019-286bc83534ad-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:09:08 +0200
Received: from SJ0PR13CA0146.namprd13.prod.outlook.com (2603:10b6:a03:2c6::31)
 by MW6PR12MB8959.namprd12.prod.outlook.com (2603:10b6:303:23c::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 06:09:02 +0000
Received: from SJ5PEPF000001F0.namprd05.prod.outlook.com
 (2603:10b6:a03:2c6:cafe::cd) by SJ0PR13CA0146.outlook.office365.com
 (2603:10b6:a03:2c6::31) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 06:09:02 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ5PEPF000001F0.mail.protection.outlook.com (10.167.242.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 06:09:02 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 01:08:52 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 01:08:15 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 01:08:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JmLLfrqz4A1i6NWktH1nDD24T5jyXRX/0lz++52f1PHiM3h1/4eZK0AM8Qwp11mLYnLAOd6I1Nku/8aY8GDh75KWa4/Y4nSldnqSmno9F6Y6AgK5vMxjyOXbXBZU1SUPtI04yh1xgi4C6PPDYKGvpjWaeszpa7xqoYxOt1LLrc64r3YMRdpcHeUGXGRDldI0CYFmV2N3Id1T/3lkkpLma+/nnR6on5zHT/u93/HBMBKIOj1OiG9GSBdRxpaCeKSa3g0E0S+DC3hmBhTxIdh0f3dFJKhfa9t07YmeDuaFXaNaxbnJN/HXZZRFMrLls0yjPn+WJWQGYiAQE6riDFDudQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lGcbDcYXfhuE0JJ4fFBtDFcKBGtAJuzfkmjZyxbaVCg=;
 b=acprK7vIJaYynTOUTdOnWGAAzirEGeV6VBzNiptt7FqCYzYEQyx1c90l3isRAvtD5eSo9+hPDBpOnVTkyztnnmYvGebsjJblCxKfLb/YGvAzpAQxLSlcbxwrj1FpaSYP/m9AdrFIvDlJexuu/ZsFa5s5TmUb91h0rq0HwwODckLfn7jT0PPMAhKWXwA8nqP6WaIidsmZ/q9gRIz2wGAz/O6Utl009sC7a55XO6w3yeYoujjUuWQ10fgKOq24PGZBivY0JsrybHTuDVW1ThBnly9v2HX9qQsRaouICzzsmL7ljAPl5SGpdsnufUJxDxC7VoBh3dlxJk2N80IL+Yq6dw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lGcbDcYXfhuE0JJ4fFBtDFcKBGtAJuzfkmjZyxbaVCg=;
 b=A0zwaqr8Jy8/Z8OyKLkpBOC1Iz/xdABX+ZD6qURhOcr0SJDnvygqQ8Sbm3OEf1J7obCKIq3HGD/lDpcc30YP6VuEKYgpHom3PbPfhFWdFenH4Jy1sJFb7IEV1nxal0VzCP6WMYKZawo4x6n0SD7rffhA/gvkYMOdt1GPex8CNaM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <b0d66de4-61bc-4c4f-9fbc-57c2a6d1a192@amd.com>
Date: Tue, 18 Aug 2026 08:08:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] ARM/vgic: Clean up vgic_v2_setup_hw()
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, "Bertrand
 Marquis" <bertrand.marquis@arm.com>
References: <20260817203359.1881963-1-andrew.cooper3@citrix.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260817203359.1881963-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F0:EE_|MW6PR12MB8959:EE_
X-MS-Office365-Filtering-Correlation-Id: e60d1b15-df6c-4069-b560-08defcef33b5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|1800799024|82310400026|36860700016|18002099003|22082099003|56012099006|11063799006|10067099003;
X-Microsoft-Antispam-Message-Info:
	oBjW+zmwtQ5/jVx/v/Fy3jm0RTwyJrJmgkllv+IeQedaw261VkEgdetq7l5K/2Gff2TUlNg1iVRAB/N4Mtlcbo/G4KPycKchCJaH4qUl09EwdkQMIyBFEGknxokUIhu/FG9GDvxCRbtMsHCVrjAdW10erH2dHSMvXxGgu3Xm9vqyNiUpwqOt/UHQxWAmFAr4dT9x4+yknBeMtjgK5n5UXCBo2+3pSI2onGqfh8lYGcwNHPUyYVJHfvTETiIfOKwF+sto54IYD/l4iomtEmgiBfbqx16AzZsaLgeyhMT+6paXmirTqpQ8uGWSHrDxx3uCb2pFbD9cuu2WPBIUah9HEetqeRAeBqSRGTAwWwzYQZDix0YBlPgg9I9nK5v8iyrTPTEdD05Jnnat+iQmr1Ik759dkYuU1cUUPihMo3E5PHyvZWYuKdDZN0/8e+NxBDhduU6dHoDmCfUj72yX6hYi//EsmL20DccdFKB2SitP52YQ0ONFhUROtvGUFBxmpoWSSh4ghxVZMmotYVU4f4dTeGEwwVrQ6eHDQV1Z205bU05K+XpKkFQR0S1kXVJq6vT2aC8x7oNaLuYMTsvSyTQPAErOdXwqVD3iKCQIl6PIbhkvQ8nY2tO062EC46xZwgPHRVOg7xMFFF2IBVpzJZ1yx6VloOkqgbWulDqVNBdfCukK5bY1z9xKemWcrrseGsiDnUw1+PVw5HxbVS1XbUQ3/w==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(82310400026)(36860700016)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	y7lDLYKRLl8rBx9EAHwVQ/TF723TONs0mBVkcsWaAVjVwKPP0qbBzdEwfC4tDhagZvygdbQMHGAIc64bvhXt/CRy/ycL9aqgYt8tUgLEbzsrQv0LC+GI/5wWkmcRxfWHuAvbSrg7AfpeXk6faehDyu5oG1e0CX9lIp1r8naYPG7QSIhRi9VOn/tEDRgJ3dhZs/q/t+KNhq+yQpgQfVPV8YKzH0zkj3vkAavrBKvsxKOyJh0BMgAuABvYUp4xS9wgKMi5hisOSR4EsknIHrPSzKw8zD2TjcU3exf2HzD1vunLZ8iKIA+YZB8S9Qr75Lg6Dor4+/MhMIknYvA7G8ecDSD5CeHikNEDuHCh8/yISvf1cd2C5kyEQHEoGyFkgYO4TFIzRD2a4oamOzmqLl1Nmjytr1mmw4hT42L9w8M7b+BkMdcPUaLtmKpW+YORFwQM
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 06:09:02.7124
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e60d1b15-df6c-4069-b560-08defcef33b5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F0.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8959
X-purgate-ID: tlsNG-42698a/1787033348-184CB9EA-423233C0/0/0
X-purgate-type: clean
X-purgate-size: 2204



On 17-Aug-26 22:33, Andrew Cooper wrote:
> vgic_v2_setup_hw()'s callers are __init, so it should be too.  vgic_v2_hw is
> written once during init and unmodified thereafter, so make it
> __ro_after_init.  Reposition 'bool enabled' to fit in the tail padding,
> removing 8 bytes from the structure.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The patch is good but exactly the same cleanup should be done for new vGICv2's
`gic_v2_hw_data` + `vgic_v2_setup_hw()` and vGICv3's `vgic_v3_hw` +
`vgic_v3_setup_hw()`. I can do the follow-up in which case for this patch:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
or you can bundle everything in one patch. Let me know.

~Michal
> ---
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Michal Orzel <michal.orzel@amd.com>
> 
> Found when looking at the code while reviewing something else.  Only compile
> tested.
> ---
>  xen/arch/arm/vgic-v2.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index 642407fd5b05..3446d521de2d 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -25,7 +25,6 @@
>  #include <asm/vreg.h>
>  
>  static struct {
> -    bool enabled;
>      /* Distributor interface address */
>      paddr_t dbase;
>      /* CPU interface address & size */
> @@ -36,10 +35,12 @@ static struct {
>  
>      /* Offset to add to get an 8kB contiguous region if GIC is aliased */
>      uint32_t aliased_offset;
> -} vgic_v2_hw;
> +    bool enabled;
> +} vgic_v2_hw __ro_after_init;
>  
> -void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
> -                      paddr_t vbase, uint32_t aliased_offset)
> +void __init vgic_v2_setup_hw(
> +    paddr_t dbase, paddr_t cbase, paddr_t csize, paddr_t vbase,
> +    uint32_t aliased_offset)
>  {
>      vgic_v2_hw.enabled = true;
>      vgic_v2_hw.dbase = dbase;
> 
> base-commit: ebc00c30c65023bd1498ae20dc511c4e39f6c0f7



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:28:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:28:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393431.1632234 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDJa-0006aF-8B; Tue, 18 Aug 2026 06:28:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393431.1632234; Tue, 18 Aug 2026 06:28:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDJa-0006a8-4z; Tue, 18 Aug 2026 06:28:50 +0000
Received: by outflank-mailman (input) for mailman id 1393431;
 Tue, 18 Aug 2026 06:28:48 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwDJY-0006a2-Lu
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:28:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDJX-005eW6-1l
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:28:47 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a83fb9e-8faa-0a2a0a5109dd-0a2a4508cb2a-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:28:46 +0200
Received: from [40.107.208.70]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a83fb9d-f659-0a2a45080019-286bd046dc8f-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:28:46 +0200
Received: from BL1PR13CA0338.namprd13.prod.outlook.com (2603:10b6:208:2c6::13)
 by CY1PR12MB9627.namprd12.prod.outlook.com (2603:10b6:930:104::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 06:28:41 +0000
Received: from BN2PEPF000044A8.namprd04.prod.outlook.com
 (2603:10b6:208:2c6:cafe::d) by BL1PR13CA0338.outlook.office365.com
 (2603:10b6:208:2c6::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 06:28:41 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN2PEPF000044A8.mail.protection.outlook.com (10.167.243.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 06:28:40 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 01:28:39 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 01:28:39 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 01:28:38 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=h6lYdSQ+9WiTrzhtcGrqy7JDdXLt6bBpM/SEtFV88YE/p8LQf9SP697gzeOlv5Fez2+HFbG2wyqh9SIZmUc6hMI6iVuiEjHSlGwK4TgkB5OybBebb6LRm6Nmr5/mdvtzdTlLfw01/8k4wtI19twIFa88CnIgVxVW7AGK/3B19nsRi15QYoO9TUgaS3a86fq9znyUA943iMljH1V6uIAByvRDLIcalAihdUlUSyO+BAEUzLgCNxuqpkyiXt0DuH86BZMyMd56NE36FPyzuqd8NkUufVqjj6JhP4I3SvNLSF/8CxMYFP0TxF2+nilCCqhsImqzsCX3P+lvVa8PcxaZFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ArIBkWypTrCrcUcT7JGOxsY7XolsZfaVO9t9RQk02vU=;
 b=cK1iQr/P2kEyjPOxrUoNsc8ewZv0K/SEz71IC9ju3aCf980sR6t1ISkNli24DtjFId5SuW6yk/kWn7lhxIntID0s2sgTQakhIgQuOu+xj52M18IHb7nFvhcfjH2JV+fNMZ/mgJXi7zQqiyRdex2bDq9we36wQfSzvkeAwhfCUG+lfr5m7hnnVCAOlwgH0plFImhR1J2ilWmh0cUhhoMBhlxmEA04GM695GpJKmwOpsYv2BwA++h4+9dGP+5QAwJgFBJbgiuQARGiirzhZFkZeGNbOD9X5VLz/iOdOXDBc7wku5/MoF7jusC9NJIa70CZ2latkSVR06orzbe3LCv9Cg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ArIBkWypTrCrcUcT7JGOxsY7XolsZfaVO9t9RQk02vU=;
 b=hsl44DSdPQNC6o/1Ayg+upM8dpedh2TJVs6J5jbNFxtT/r0sDbp2hE1vA+6UDrC/nrdBgWlHV415/CEDfksXdsBY6AznK7l+WV/VrPUqFvqFE0mj0Gvbevl26raxWptRnr5tVjjCMS8EQewlJ5UcUvIyo+Sg0oKP6s/MGPnBi54=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <26c0b60f-053a-4b01-8b74-2cec0d72b389@amd.com>
Date: Tue, 18 Aug 2026 08:28:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/4] xen/arm: add i.MX8M platform and UART support
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-1-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044A8:EE_|CY1PR12MB9627:EE_
X-MS-Office365-Filtering-Correlation-Id: 0956c3ef-934c-4cd8-707d-08defcf1f1f1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|36860700016|1800799024|23010399003|6133799003|56012099006|10067099003|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	Xd/NjSqneSM/lzQfnMQoihupzX4qMwsEqwL/3gmlPrwf684aQpr9CQ+v8mlQZ6lT23W6h446JIxVvlxGXF6i3u4SJI1cqqOahOPbOEgPzfm626WJ/TX5R33xg8HQLrbLWirTOTC6E1DmlHzuygN7hlv8UdGsQ8Q89N+UMMtdmXPwBSAVWXXyEXaURw/OT0bqjMUG8nQ0vH6G3gE5qbcAAU8XiyiSInhBN0Tw4GGGtFMVLz5nc8+me8qfXsB4voP6F4oHEnx9qY8933IQypkLclylB4+fb/WBj7bto3lFNXNAIn0RZR42b0kz4w6/FdRRGOAoUyJNlx2uxQr1mh782/eUdjVoekZPI6vZ/UP8qNpjUi4abjssEovR8tD7T8iMRknIb/x2/oUAFzmW3BoTC3ziLPcy9GtP/OJIMoFjQ/q4GuNIGWD5tO1SgAML+1ravPrR11Ng4z15eLWyoIfPKiEv+450Yhpg04Bei+llhHt8olaEqlRXgJQOpFdk9NqhRwCJhFIM87ZUW3u+B4bqFPIRZ2v+Zd2NMDw1tV8LXvOtodUiah3Eg4YEAabPCzP+xdVbix/5rXG4ylxKQA6vDpUKQlD96FXNGldomp69OrrtgZZWxCpHVAm4mv7q5hBxw3CrgciFQxJheH4h0oCToENWo1q+qB7gXfLw9A9pK7GkxmUqiQvnP0L9ooglCCa/5cyoMUw0UrmBJtzfE+qUqw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700016)(1800799024)(23010399003)(6133799003)(56012099006)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	pybFiMBvV0g4pktASm8KXdXid2c3Jo2O+z3WisaKF1ci0YdPpg+tdx0oMCmRRtEWbXnHI8bNeGUM391YbNXiLaSriatYC4Y3Y9snan3YmFGREc/Pl+HlPmRdbFWWkhZ26PyueK/lgGjYQm4fXBdfR7ux02MUXj73Wc889g/DrVVMVcFQUFd40O5gH6jE0ECSM8HitU/oIfRhx3gi12wm37lbj5zKTJNZT30TCXV6NxQzVBghN4QZ6ZQETjUq0BZi3gJcw51LXudPPUxHsrukhX3f8w2Wfo6xPp3jPKISAU0zdeHbMl0OXEiqHDaIKsjJITpW+fPcSgSF94YT6gLgpDxTrdZtml2y136Rxr4YxdNeY1pOT7ZJOSWqr1DgcBsGtuX6S7bmVKHgETDCjXkfF7lq5Ib2NlvTmH5d+dYM95QeyfaGO47jVL/RWg8Kx94U
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 06:28:40.9209
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0956c3ef-934c-4cd8-707d-08defcf1f1f1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044A8.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9627
X-purgate-ID: tlsNG-c1860d/1787034526-D6B4187B-52DE3A5A/0/0
X-purgate-type: clean
X-purgate-size: 3457



On 18-Aug-26 04:52, Wig Cheng wrote:
> Following Michal Orzel's review of v1, this series adds Xen support for
> the NXP i.MX8M family (i.MX8MP / MQ / MM / MN).  It provides the console
> UART driver, its early printk, the platform glue (SiP SMC whitelist for
> the calls the dom0 kernel issues to TF-A), and a MAINTAINERS entry.
> 
> Tested on i.MX8MP (4x Cortex-A53, GICv3) with the vendor kernel 6.18:
> dom0 boots to login on the hypervisor console, and a domU starts with a
> PV disk and virtio devices running a full Wayland distro.
> 
> Notes for reviewers:
> 
> - Unlike i.MX8MQ, the i.MX8MP device tree uses the GIC as the root
>   interrupt controller (interrupt-parent = <&gic>), so no device-tree
>   workaround is needed and power domains keep working.
> 
> - The i.MX8M family has no SMMU, so device passthrough relies on the
>   1:1 direct-mapped hardware domain.
> 
> - The SiP SMC whitelist forwards only the specific subfunctions the
>   dom0 kernel issues, extracted from the vendor kernel call sites.
>   DDR DVFS is left at service level because its reg1 is a frequency
>   setpoint rather than a fixed subfunction id.  No call was denied at
>   runtime.
> 
> Changes since v1:
> 
> Patch 1 (UART driver):
> - Documentation narrowed to the i.MX8M family (dropped i.MX6/7).
> - Relicensed the new files as GPL-2.0-only.
> - Dropped the stale file-path lines from the file headers.
> - Renamed the header guard to ASM_IMX_UART_H.
> - Removed unused register/bit macros; header is now asm-safe (BIT(n, U)).
> - Also clear UCR1_TXMPTYEN on init; documented that the console is
>   driven entirely through UCR1.
For the future, please include the changeset in the individual patches. This way
it's easier for us to review without having to switch between e-mails.

~Michal

> 
> Patch 2 (early printk):
> - bne -> b.ne.
> 
> Patch 3 (platform):
> - Build the SiP function IDs with ARM_SMCCC_CALL_VAL (IMX_SIP_FID),
>   matching the i.MX8QM platform.
> - Whitelist per subfunction (GPC, SRC, NoC) instead of whole services;
>   DDR DVFS and SoC info kept at service level with a comment on why.
> - Dropped the BBSM call, which is not issued on i.MX8M.
> - Fixed the misleading "secure RTC" comment and a stray space.
> 
> Patch 4 (new):
> - MAINTAINERS entry, as a separate patch.
> 
> v1: https://lore.kernel.org/xen-devel/20260814162535.331459-1-onlywig@gmail.com/
> 
> 
> Wig Cheng (4):
>   xen/char: add classic i.MX UART driver
>   xen/arm64: add early printk for the classic i.MX UART
>   xen/arm: add i.MX8M platform support
>   MAINTAINERS: add myself as reviewer of i.MX8M related patches
> 
>  MAINTAINERS                           |   7 +
>  xen/arch/arm/Kconfig.debug            |  12 ++
>  xen/arch/arm/arm64/debug-imx-uart.inc |  37 +++++
>  xen/arch/arm/include/asm/imx-uart.h   |  57 +++++++
>  xen/arch/arm/platforms/Makefile       |   1 +
>  xen/arch/arm/platforms/imx8m.c        | 152 +++++++++++++++++
>  xen/drivers/char/Kconfig              |   8 +
>  xen/drivers/char/Makefile             |   1 +
>  xen/drivers/char/imx-uart.c           | 226 ++++++++++++++++++++++++++
>  9 files changed, 501 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
>  create mode 100644 xen/arch/arm/include/asm/imx-uart.h
>  create mode 100644 xen/arch/arm/platforms/imx8m.c
>  create mode 100644 xen/drivers/char/imx-uart.c
> 



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:31:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:31:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393438.1632243 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDMB-00085K-LE; Tue, 18 Aug 2026 06:31:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393438.1632243; Tue, 18 Aug 2026 06:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDMB-00085D-Gl; Tue, 18 Aug 2026 06:31:31 +0000
Received: by outflank-mailman (input) for mailman id 1393438;
 Tue, 18 Aug 2026 06:31:30 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwDMA-000854-Br
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:31:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDM9-00Fm39-2h
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:31:29 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83fc37-2eae-0a2a0a5409dd-0a2a45069a56-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:31:28 +0200
Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83fc40-195a-0a2a45060019-d155dd30d19f-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:31:28 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-471eeac43bfso3681093f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:31:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d0fb867sm122553415e9.10.2026.08.17.23.31.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 23:31:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787034688; x=1787639488; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=lyDZfjycO+TTdRa1W0Sw5Qj3fcufPDCKiGcdnnbOdM4=;
        b=J6rb29liKALwB/VIl9civCOEMeDDxSTVA1EdHKPYkq1aAwkFAROcagYsGOB1UabaOQ
         mo4+1CFES3qZ+sA25MmUNoEOkzAaUMe07F/RjTCd1Ke+TcfOAemhDxmLd+0QHQJWYB8J
         s0PB1y2LGoApV43GMcxG7UXABJsfGO97VHqlAQZ+Cq3hxjGU6thdb9KezlD0Hm3W0ZtN
         SykVfWlXjC7o7OkuKyQbnI/IKH7GwTp+heB9bKV3jHCKBSCUNY7DJEGfYgnPwNbY1zCj
         wwTA9jIHNNJ2azO449e6bsigToF5qzW5CYsdCMNFzfNb8Qf+tqeaLm+4EDxzXc8HUFUM
         Kxxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787034688; x=1787639488;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=lyDZfjycO+TTdRa1W0Sw5Qj3fcufPDCKiGcdnnbOdM4=;
        b=GK+A/IRjaqsWIoLNSW/3xomiX1PjuCxl0JMxGKyqUFw71rS+XED2bWrfaca6Ofhsr8
         CcJJ+WDZr1OInKO89KHZrAs3dsxPmiFtH3mYSg5AwbTjT1fEjVbsWpPXdr9WU4ss+IQu
         kOrV7ZZn3eFKL9RtVUNIwXGN4DN2BmXqOjJcvzu55LifvN3UyyE8F7GTyPJ+vKIEbBWk
         rODlA6IM/l8XgtRDMsEmDTfseS0lwvE9OrgDsnQZkEBe+U2f8CLfsokhoAF/T4SCnc5D
         k/hHAJpcrP3hoYChHtH7rJF0tuoCtK0UiFHB4bGqvFoxr1VgVOWsbdDailUq2sLkL/PR
         C8Ng==
X-Forwarded-Encrypted: i=1; AHgh+Rp59qLliUe7UB4ZvSVjR+LrHniwq/7Koa8yguTWYg0A479peMXEjh8tZeS3wLbtuat9YnVMkewqkmk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2yrMzzLviwj39qwqjwjgVGFlWgh3MrKx1tR3UoMtmuQePgOnd
	MBdFjdX8AJ6MaMjgyYWbrwe4GfYl/wJH9fXIiMV14Zqdzl9jiOhM7C1nwQaT490HIC6FvgzizH2
	+Rf4BiQ==
X-Gm-Gg: AR+sD10YCXkI5HfCx3U0XBFZtaNzWtOopXslH4RYHMTnZss98alkQPgnYI9yHX9X07P
	MIrd1EOpyEiLIDiu+LqqFYPggjmZt84Md+Qcqj5DYnRO78shlhCJxesDGYWPjHXRvh7ud1bZrc7
	iiF0Jv6mCxpH8oClT0lo717tmNDTnru0aD1IB4YukcR4IVh8hl2swDWHQn6qkLNY/H1URYvVJcC
	WNgCU8fxnZPfZ0NF9gjkKqEKGietmm1G4Xo+jAuhq2Hp+EeNs1mO6hB09lZ4kR8I4b96nL67Xm1
	19Sd1NLAA+HwnYgILIHAuuTCXmqPM8wLBJv6hhAXpRB8u1WIkjMlNjQYG9uuAla4od1F9lWe7Q9
	4BG80RU6r4E7zI7wMTeTc50HED+FjzHPB6aLwd+NfHFOInsdMLL48BGoN0s4xuiyPCKijDzo7bw
	SBYvngM7FquzXPIaJPxQT1XxJeokNbSwNARW9CAQbH8ET2FNqoAoJB3gNmS5CIGkprLMyHphSpJ
	/Ltmzvq9KKDNtC1snaA5nvKRGtUjC5l7dlkDJsZ/M3IocVgzimy
X-Received: by 2002:a05:600c:1f91:b0:492:4e09:9fc1 with SMTP id 5b1f17b1804b1-4998797d111mr413171765e9.15.1787034688334;
        Mon, 17 Aug 2026 23:31:28 -0700 (PDT)
Message-ID: <e3e692f6-c9f6-4ed9-9212-fa61521f22e6@suse.com>
Date: Tue, 18 Aug 2026 08:31:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] x86/emul: Rename the x86_seg_* system segments
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260814185841.1757421-3-andrew.cooper3@citrix.com>
 <20260817121129.1787344-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260817121129.1787344-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787034688-FEC7777B-BEE320B9/0/0
X-purgate-type: clean
X-purgate-size: 1313

On 17.08.2026 14:11, Andrew Cooper wrote:
> @@ -131,18 +131,21 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
>  #define SEG(s, r) ({                                                        \
>      s = (struct segment_register)                                           \
>          { 0, { (r)->s ## _ar }, (r)->s ## _limit, (r)->s ## _base };        \
> -    /* Set accessed / busy bit for present segments. */                     \
> +    /* Set accessed bit for present segments. */                            \
>      if ( (s).p )                                                            \
> -        (s).type |= (x86_seg_ ## s != x86_seg_tr ? 1 : 2);                  \

>From this, ...

> +        (s).type |= 2;                                                      \

... this wants to be 1, while ...

>      check_segment(&(s), x86_seg_ ## s); })
>  
>          rc = SEG(cs, regs);
>          rc |= SEG(ds, regs);
>          rc |= SEG(ss, regs);
>          rc |= SEG(es, regs);
> -        rc |= SEG(tr, regs);
>  #undef SEG
>  
> +        tr = (struct segment_register){
> +            0, { regs->tr_ar | 1 /* Busy */ }, regs->tr_limit, regs->tr_base };

... this wants to be 2. Then:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:32:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:32:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393447.1632252 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDNE-0000BU-Vg; Tue, 18 Aug 2026 06:32:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393447.1632252; Tue, 18 Aug 2026 06:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDNE-0000BN-Sl; Tue, 18 Aug 2026 06:32:36 +0000
Received: by outflank-mailman (input) for mailman id 1393447;
 Tue, 18 Aug 2026 06:32:35 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwDND-0000BH-S7
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:32:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDND-001Wv1-8c
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:32:35 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83fc77-2eae-0a2a0a5409dd-0a2a450cb4f0-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:32:35 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a83fc82-f479-0a2a450c0019-d1558035aca8-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:32:35 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-495590dde14so52164075e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:32:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999cfcee58sm91103835e9.0.2026.08.17.23.32.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 23:32:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787034754; x=1787639554; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=rCzGeGrBfNdLbR53WnF25TEaZVj3ZU6HK7gPFLSGJuk=;
        b=cMQXHHTq4lNMCDYVdgyjVsCFVNedDsbgczw5fyc4FN7zdjX46oifq5FiZ+Bepk4pZh
         VpFvWACdb3NVo2rKDge0LWzSgB+dj1NKOv8YWrxeJUBzc10F/q31tjTjKqQiW76Sjcb3
         +Pi+cmalt2F9fEGZv6NmzJv2vtyJ+47aJ3sUEKy9q/FxbeHoOVAx8SRUlvVGMaOEdsPV
         +QSBgeMx76sj2zNRtfd9lEdGYAUIJZf8VAzozD6r4yHcgutjwDVHtOoDWJLjq72zXoR8
         8HrhLFqJjIAyYH2FrKT/EsWmtCvMtudQl9k2/39EJYGVMaUlyDegZAEhVLGQVAHs3hDo
         PxTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787034754; x=1787639554;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=rCzGeGrBfNdLbR53WnF25TEaZVj3ZU6HK7gPFLSGJuk=;
        b=NhOBmiCG9aZjLi9ryd6jxZYbU+ObdR4gsONxXspT43NlZzDnfDM3qroOh2JBuJSMHJ
         oQ2enTzgnzd8SqaHgsq+GJqgiLucoWBl2UcPnX59TlvwL1GKJCjd+YxUHCCWiMWPjnn+
         VMjvt7XBqH0Nm3YPFLSsicvbfAOOwMceju704xLoFv2sDqWga4OcsvIx2BvbPpFLNPs7
         ppqFN/JcXZ6x4loQqM6+o1JH1K2ehGzCP/uHzG2F2hLArmgV+qFnd2ke+sXHDhIjfFPB
         Aydaf4OsR/rQp8HDt2M5uVVtCkoeBz6eTgFhG5Uclz6/cnNh4HKmDzZXMFbD02yrLxfw
         rQ1w==
X-Forwarded-Encrypted: i=1; AHgh+RoTsiweZd62c9c1CTq/pmZBj8R5XC8OffxuzhfkrCwZe7JMc8bhSXpgGXpBbHZCJcQ+6zGZ6OO0148=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxdrQyNyWr/1a9TakLyVcrI+2l508R7H+nHf5QQmhH+pEtBI3gm
	UXT53iDkvNe45//5nEvu1JnC0BJGC6zEKf0Ij0XE2Le2jQ5+N3Vyot7tu8jmg22Tbw==
X-Gm-Gg: AR+sD13DyX5FDHsmpCtzWh9/zTXyRDnsoqWTrc/eVcnJ2AlMZg3wYacTgXa7iHwYKi9
	/2XvKrJYV+12T6rrBywMaiXTEJIJ3MaBRKM9x61a/AMFwrrc6rdJSth8Go22X/28B0iFyJRelEW
	fNzsvLnPDboPBO1cn5aSBh+T1YfR8NblBDqLG2MLU1R/LZ6F2D10Zdxb1UXGd4+Lg7nNMfoNRtg
	PhLzzM2c0ZTALsQQDmsjTlzqgeY/9dTQLOnjBt6sHfyPNydkqKwaelUye0zo44WZh2IOhazXmaP
	MSab8nAUgbmLBH+mSQUwSlsxWf23LVogMfd8cqQP1hxjYNsvdwftT+v6lhDNEPTsP4OO3oXNxl4
	DuCOWgEf04nhr7dBSSvTCnLZGq8Abspnj8TcE+aA1zN/63xVlrd/LqGgq+ezrSrsWc+rj6fUU+/
	72ZSP/uF7XG97r1UWEY6xJ2UqowG59/Yq34NhwnmRurjGT4728ICwDurcS9U3PKeHfI2dKgbzi+
	bEb3/dGy/lhKP40sz1Wnn2h/KX1Oo5+evIbcsZ9ZaWAqH0T11yo
X-Received: by 2002:a05:600c:1d20:b0:493:e365:7630 with SMTP id 5b1f17b1804b1-4999fb98421mr91025205e9.14.1787034754551;
        Mon, 17 Aug 2026 23:32:34 -0700 (PDT)
Message-ID: <f322c95e-3eb1-4533-81f9-ab7fc3a18111@suse.com>
Date: Tue, 18 Aug 2026 08:32:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2.5/5] x86/nmi: Remove logic for pre-64bit Pentium 4 CPUs
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260805124525.105457-3-andrew.cooper3@citrix.com>
 <20260817162432.1833803-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260817162432.1833803-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787034755-03AD4A5B-B117B028/0/0
X-purgate-type: clean
X-purgate-size: 295

On 17.08.2026 18:24, Andrew Cooper wrote:
> Model 3 was the first 64bit-capable P4.  Xen won't be booting on anything
> older, so remove the condition.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:33:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:33:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393453.1632261 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDOE-0000gR-6p; Tue, 18 Aug 2026 06:33:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393453.1632261; Tue, 18 Aug 2026 06:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDOE-0000gK-45; Tue, 18 Aug 2026 06:33:38 +0000
Received: by outflank-mailman (input) for mailman id 1393453;
 Tue, 18 Aug 2026 06:33:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwDOC-0000gE-Qj
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:33:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDOC-00CAgO-7Q
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:33:36 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a83fc9a-e002-0a2a0a5209dd-0a2a4508bf58-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:33:36 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a83fcc0-f659-0a2a45080019-d1558031d4f9-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:33:36 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49954b88fffso47286615e9.0
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:33:36 -0700 (PDT)
Received: from notebook.. ([88.230.46.229]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996188217sm490215315e9.13.2026.08.17.23.33.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 23:33:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787034816; x=1787639616; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=jrY9WI5HPCaERTSxBCfhoLhMGiowgpjbqH2F9KzZUnY=;
        b=cOxon+Mp0868XIAJXpNL6oRyEGqoKUoaOx7vlgd4rxb2wIXhHrp/z6FmXujYsfulwY
         SXGVIRWcTQrF6srwU3feM7q2PVHpffmSV1RDAFGYioqpBhl0Umk+k1e7xEQ+0tvbuMNi
         30mBcPklrAbFSwGJ8SzJPpdsOQ2mcQDXPBxsV29WiHy3IXQ4fgVGWuZVNJPX8PVFcKwl
         CK/9E48PTQSju/V7WtwhwYCF77RFmLd3jTDshDjiNK9PkbjiBNYWWgWjjLKbhwOz+LU2
         DYKO7X3FLD02ghNrWa+5QTNEsNoI/4Qcbk+diOc8HchyHk+19MTpBts4zWW4Q51BbM2M
         CiAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787034816; x=1787639616;
        h=content-transfer-encoding:mime-version: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=jrY9WI5HPCaERTSxBCfhoLhMGiowgpjbqH2F9KzZUnY=;
        b=FxFCi4ejweIj+PDCFrki+wQaRELgFbypf51eW1232kflrnhJYkZ/NAOy9xAcTq9uXb
         BihCP3xcRT0RPn3McAlNKZ4ZU7hC71Y6e4IoXRB8ZaKnrvBwBr5c9o+49D0pYlpeqG8t
         pz/sbaKpX5buk4nY3IWnrZKccyinVIRzGxT1etc2HTo5OxbQRj+wcVIcJgapczz/sRho
         KyoxP9CR7tqQFd0qL0cXcwImN3Bw4y3OhkjxRJ7TJ0NGminfmYIanDpYuTAi9uN54Ah2
         K2vhqTTzSBQHwqyVt1ByU7wKzsUzxYk9lYi7Jw9yG4j3Dqunjybe+dZW52FL9yP7FOwG
         FA4g==
X-Gm-Message-State: AOJu0YypOIjqJ79CPDFKQ4PnPF8gxJqwODvtMG+3Ni3MA7GWs19JJCG0
	lNbKjCWpRGvGIgUT0ruD3rpTdpQVOlLuxwMc3p9phF8vUGc7ZZNdn56xZ3Rctw==
X-Gm-Gg: AR+sD136GPDeoeuSNMQzV7YZxk+BN5zcRumXh39l/cI+mPr20Xv+Fx1C6Kv5gKOkvFL
	9mduUUV667VBB3FjoUXLpfq7C5+ycESne9FIOYuy2+ay7d2U77B0U0ircNnZImPpzC1wh1yYsIK
	cGAC4xuDVSpiq3l9/lfMZI0+0wLS2QJEkxzvvnPNiWtAnREStyEKfT70wwf9WF0eNvNc67hVgK7
	43looo4IIFO0Y+zvgUe08dQrteWng6Ce1sg54Q2TrOJj25MCQOcy498BouAfcxNC+Dzcyu1MXek
	QoYS2htJC/QABG/CyrS2vfvu8DOO5SFYCwVXv1zj+zG7Q1qGB5sx6Wabj/StodqDlwcWP9HQzUW
	KPovGsZlz+PmaSyfZXLfq8EiUSFhd1VKICWhZS/vF8MUmCJ/ToirAZQuf1Jud7+an6yYgkddU2I
	RM3rLKypmwZmgBk/ngGS2cqNbqV9jrV694A9GacHtSBi+LTyMvmYhmFaKoWb9+tA==
X-Received: by 2002:a05:600c:8b86:b0:499:a4d1:d7d9 with SMTP id 5b1f17b1804b1-499a4d1d80dmr27162405e9.9.1787034815510;
        Mon, 17 Aug 2026 23:33:35 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 0/2] xen/sched: fix crashes when vcpu creation fails
Date: Tue, 18 Aug 2026 09:32:57 +0300
Message-Id: <20260818063259.18733-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787034816-D735D87B-9894919A/0/0
X-purgate-type: clean
X-purgate-size: 266

Furkan Caliskan (2):
  xen/sched: core: skip missing vcpu slots in sched_move_domain()
  xen/sched: core: kill unarmed timers on sched_init_vcpu() failure

 xen/common/sched/core.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:33:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:33:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393454.1632270 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDON-0000vf-E7; Tue, 18 Aug 2026 06:33:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393454.1632270; Tue, 18 Aug 2026 06:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDON-0000vY-AI; Tue, 18 Aug 2026 06:33:47 +0000
Received: by outflank-mailman (input) for mailman id 1393454;
 Tue, 18 Aug 2026 06:33:46 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwDOM-0000v7-Pg
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:33:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDOM-0053YC-6i
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:33:46 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a83fcca-bab6-0a2a0a5309dd-0a2a450c9ec2-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:33:46 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a83fcca-f479-0a2a450c0019-d1558035e8be-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:33:46 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4954f5e8020so22039905e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:33:46 -0700 (PDT)
Received: from notebook.. ([88.230.46.229]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996188217sm490215315e9.13.2026.08.17.23.33.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 23:33:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787034826; x=1787639626; 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=Kd6Uf/jaILnHhDnAFQz92ldpUytfMBZNj1lRHYK8kiA=;
        b=PZ71Li1x7JJH9i9peXHTk2FT8wZ6QzaF5aEp/XNz4rocXIlHfhn+KM3WjUZ6Tc7rY4
         9pj1CSOYvLjTD3YIN3tdFdN0NJRnBYzKeoMTdSlTh8+Y5F4sQPEz2mC4swV9sTMM4Mg/
         aaQNIafP3C7jYfK5TJ2ACbeqXhRLG9iCLeX/OjciUH62eZ6mpJ1JAhN+A5q4rYnzpgza
         9QFZW1d4qJBAkWdrJYVFu80WmmSnCd1P3XRyCRYMZ3vImj84mV4TDbedX/GrAJhV9Rnb
         gRD4NFwLQtrEfqKlOESOQ/t7feaxswP1ag/iiOt5kUe0tIkkRrpPqJxb47h+mtZI69aY
         08IQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787034826; x=1787639626;
        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=Kd6Uf/jaILnHhDnAFQz92ldpUytfMBZNj1lRHYK8kiA=;
        b=m4uPYQhLT4m0OT8k87hiBYsikegjOHlox8fMBAvVcmjNAAC2LggkV+kaZZdoN0uzyG
         uEtxoolJMi/UbkZQlZb8mrBJb5776HJzE6maztsdL3XmXJ4q3ZlBxC35V56tF7FsNSTg
         3nqzrBvlT/Peayr+Bttr43GbH1HmTtgROlKP796/tyKxYCbIoWeNC+Gj1+pSU1Rk1EOB
         J653tq0FvgfUlQg9qeo+dAdapshGIhYVe0bMPmnUusw4LWDYw4Ec/rJEU4mWYDIBP/si
         DU3zbF7kzjBUyBQez+rXFwRIyQNQ1NL2LQPZvtExJi18qoOsGk9l73eX7dB3nOsu3U5F
         sF+g==
X-Gm-Message-State: AOJu0YwgtnOJjFpDhpM1MIHuBP5gP6Rlg7ubVlgXLEBHKng81i2WQoiP
	O9BdG7k3ItWYxAW4tRCdaE3Dd12RA9jD+qpOhSFAOb8eQxcVB5+VNoVJaBCw+g==
X-Gm-Gg: AR+sD12htkfojvIScPAJ1gGo5Kcd8hqCkKyoGk68Hz2ASFNDFH9AGBnpq5Mfe34BkFo
	Xg6Iv/5ZBPZGTvucha1dLxY7aoazIJ6Wk14Ru6XAWaR2yd1QI087WG0Y0xPDus3XtAxnOupZ2Lh
	Dzaf09yUalJz1vrTeUhs04QwCQAOcf+Z1t55gRrhhzTVHIQPpr6nWgqsKrGjdBAiBjZEYG6oQZH
	IwI1v+d4YdIUByYXritVsyN5DhQT56spgZolN1qaaZwvW8QiB5XshuSHopjtLXqUMSXtNWAstVu
	5l8lihhUYWOL9gGwfxOTKzfKrwZ4ZvE4jBrHJgyvyF5+bGxLxVg1PSVvieN/6h2mjJHA2baE+0g
	6hwN7ndR1/8ByEM0nTvSXhVRoTtaaGQUAbnA6E1/v5i89bXpVsiZtjNMeUUNe7ursN8gBoY1OFz
	VD5SOlh2eBLswbs73uoqjts0+q8foygvUwFL/c9AihtrKtrhXcdcygSfy6GtmB
X-Received: by 2002:a05:600c:6287:b0:495:5fdf:2075 with SMTP id 5b1f17b1804b1-499878ccf00mr444504555e9.0.1787034825529;
        Mon, 17 Aug 2026 23:33:45 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in sched_move_domain()
Date: Tue, 18 Aug 2026 09:32:58 +0300
Message-Id: <20260818063259.18733-2-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260818063259.18733-1-frn1furkan10@gmail.com>
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787034826-012C8A5B-680D25A9/0/0
X-purgate-type: clean
X-purgate-size: 2307

sched_move_domain() derives the number of units to rebuild from
d->max_vcpus, which is fixed at domain creation and never rolled
back if vcpu_create() fails partway through building a domain. So
d->vcpu[i] can be NULL for some i even though max_vcpus still
counts it - this happens if sched_alloc_udata() returns NULL.

The per-unit loop doesn't check for this: it sets
unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
unit straight to the destination scheduler's alloc_udata(),
which assumes vcpu_list is always valid and crashes Xen when
it is not.

Reproduced by building a domain in a non-default cpupool where
vcpu creation fails partway through, then destroying it.
domain_kill() moves the domain back to the default cpupool via
sched_move_domain() before actually destroying it, crashing
inside the destination scheduler's alloc_udata() (seen in
Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).

Before building a unit in sched_move_domain(), check that all of
its vcpu slots are populated, and skip it if any are missing. The
rest of the function walks the vcpus that actually exist, via
for_each_vcpu() rather than n_units, so skipping a unit here
does not leave anything else out of sync.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/core.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d3a0a97e1d..d542c76543 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
 
     for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
     {
+        /*
+         * Skip this unit if any of its vcpus is missing. Bounded by
+         * max_vcpus.
+         */
+        bool vcpu_failed = false;
+
+        for ( unsigned int i = 0;
+              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
+        {
+            if ( !d->vcpu[unit_idx * gran + i] )
+            {
+                vcpu_failed = true;
+                break;
+            }
+        }
+
+        if ( vcpu_failed )
+            continue;
+
         unit = sched_alloc_unit_mem();
         if ( unit )
         {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:33:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:33:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393455.1632280 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDOS-0001Cr-M8; Tue, 18 Aug 2026 06:33:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393455.1632280; Tue, 18 Aug 2026 06:33:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDOS-0001Ci-I6; Tue, 18 Aug 2026 06:33:52 +0000
Received: by outflank-mailman (input) for mailman id 1393455;
 Tue, 18 Aug 2026 06:33:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwDOR-0001Bf-Pp
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:33:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDOR-005gEc-2r
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:33:51 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a83fcc9-2eae-0a2a0a5409dd-0a2a450bebb6-32
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:33:51 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a83fcce-b7e8-0a2a450b0019-d155dd32b908-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:33:51 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47f84023916so4024716f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:33:51 -0700 (PDT)
Received: from notebook.. ([88.230.46.229]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996188217sm490215315e9.13.2026.08.17.23.33.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 17 Aug 2026 23:33:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787034830; x=1787639630; 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=WoJZAAWBUAZrL1iWvSjl3oV3lSy2PEyJsi9Rwklp8Qc=;
        b=oVjjYwB0MJ4FSRTqIf5CIWzsm5ldYx3FiM6MHXThOaxGR/dQN+H9yUZrXZnHnd+qQI
         ce4AfrwGbb/LVDqVrwkk9A4VGnsRb+QH2zL4b4nKPr3ubpMbPP9hMNEpoWNS2IG1MsE8
         1l7mTzUExR/Vzp7JdJiXV1bHKDxunjiIaBzUejk/zGzOLQvBH8cFcrUjNBCosCBlHIw8
         DFiatUN05tbb4dFNLjDFz/mXxENAKY+C3DsWQDWRx1YmVTyeH6uqCf3X2Op0j2kKVVBR
         A/yHQHPw+jONK4tqvIZgwqqOpDXUCr6OOK8EuZJGkJasRJ73T7o/v21pptvaPw3dHlwa
         mbbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787034830; x=1787639630;
        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=WoJZAAWBUAZrL1iWvSjl3oV3lSy2PEyJsi9Rwklp8Qc=;
        b=I/sVInWJ1dXJNxwYe7Mjg9RpSdpu/MijPcBQDzWVS+wnowF3KwPp+5MqFDfMK4zL1v
         MriIyUGO/o5Z6uFo/5nPhwEoJuvf1seOq4u0hSv8XxtKlgqhOfEKEvCCKkM+oN/iZnbw
         u7j+pUcJpZ2vbj1NJjF+R3uy8Gh9vl/gedYBkHMf3ay6yeRyBpcn3IOKJCPDbQqn6eqy
         GixV/7r/iugFTh9HjZVdsAMj6Fa382pf0pM8Hni8rAZ5Rz4amp/Qtk8LOtG+tn5qUCrp
         EcS91TPXh/CyanVJ6y6tnliswt0aF62vegtYVcZDFQpVdSd0IXOcbJaOjSi+/TwEd4G7
         zv6w==
X-Gm-Message-State: AOJu0YyQ/ygkZJzBHODv3MfvH3DKm5ZAvCN59HBO8Sz3DZV0x1x1RcQN
	CILibewmFxF2V1u2v5wgl0STINhIHqdd4Pt1b8sCdc2CokwbWwhh+K0G2xKWvw==
X-Gm-Gg: AR+sD11cdzCkLbSwzALlDOz0sM0Zlql8m0bEa6lVbgcoZX4NxEV230wpstX8VkrPbI3
	XLV7cyrceL4aDUV4mpvoSY19Qqt6Uo1jzklFD7vSE53H7XxAjz8Kif4KMQJRyihE60xHTM2hN6l
	SRcxSeiHXn1n3/p4QXCYOCT1XlkLXekN+QNGfnNvfzdukgGLVi0Wpp4YSZR9kRNScokLre6ev8F
	3kEae126BGTe/YvYa8B+qblKMMBGFACM9schdt6NStZZarh1yIuTOvKSBe3Wlha/4LAcvSJHcXQ
	esKqEm8TdUoWJoZkRrheDkmxaXpBJsnrs3hAuifmRLcr2w6TCTDPlzeXby59HO1CFcytyn4wg1b
	08QTL7SrL5fSASUS2EUghF0rmSPDbNhHgOcCFy/O4VbHkW7Eg2yli+YImVPNubnZQihSoJYJcPn
	SvW6pTm3JIubgCPCYij/n3uWwOpwjkBLUs7bzvqpjSYZpASQ6h5vfIURnMvX7E
X-Received: by 2002:a05:600c:4745:b0:499:9eb7:4558 with SMTP id 5b1f17b1804b1-4999fb6d4e4mr87879565e9.10.1787034830534;
        Mon, 17 Aug 2026 23:33:50 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 2/2] xen/sched: core: kill unarmed timers on sched_init_vcpu() failure
Date: Tue, 18 Aug 2026 09:32:59 +0300
Message-Id: <20260818063259.18733-3-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260818063259.18733-1-frn1furkan10@gmail.com>
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787034831-1B4D39EA-C63C98B3/0/0
X-purgate-type: clean
X-purgate-size: 1865

sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
singleshot_timer and poll_timer before it can fail -- these
become live, linked into their target pCPU's per-cpu timer list
regardless of what happens next. If the sched_alloc_udata() call
further down then fails, the function frees the sched_unit via
sched_free_unit() and returns 1, but never unlinks these three
timers.

The caller, vcpu_create(), does worse: on sched_init_vcpu()
returning nonzero it jumps to fail_wq, skipping fail_sched and
thus sched_destroy_vcpu() -- the only function on this path that
calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
and the three timers embedded in it, while they are still linked
into that shared list.

This silently corrupts that list. It only shows up later, when
something else touches a neighboring timer: sched_move_domain()
crashed with "Assertion 'entry->prev->next == entry' failed" on a
completely unrelated, valid vcpus's timer.

Kill all three timers in sched_init_vcpu()'s own failure branch,
so it doesn't depend on the caller reaching sched_destroy_vcpu()
to undo what it set up itself.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d542c76543..f3ae9998ef 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
     unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
     if ( unit->priv == NULL )
     {
+        kill_timer(&v->periodic_timer);
+        kill_timer(&v->singleshot_timer);
+        kill_timer(&v->poll_timer);
         sched_free_unit(unit, v);
         rcu_read_unlock(&sched_res_rculock);
         return 1;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 06:49:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 06:49:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393476.1632287 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDd0-0003nm-SO; Tue, 18 Aug 2026 06:48:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393476.1632287; Tue, 18 Aug 2026 06:48:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDd0-0003nf-PH; Tue, 18 Aug 2026 06:48:54 +0000
Received: by outflank-mailman (input) for mailman id 1393476;
 Tue, 18 Aug 2026 06:48:54 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwDcz-0003nZ-W8
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 06:48:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDcy-007wxv-Qk
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:52 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84004b-2eae-0a2a0a5409dd-0a2a450cac0e-42
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:48:52 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a840054-f479-0a2a450c0019-d155dd2be171-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:48:52 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so3700666f8f.3
 for <xen-devel@lists.xenproject.org>; Mon, 17 Aug 2026 23:48:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783d1sm9741189f8f.25.2026.08.17.23.48.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Aug 2026 23:48:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787035732; x=1787640532; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=xx1Wdt2gxZFYTf9eirquKL7iCA2KvE+DVau7VDFh+X4=;
        b=UX/u5bf/fn4eTEwBOeT6V092U8s8THaki6U18lM8zhURKzbqGwMWGFeqXNjKtd1C+/
         yHGMHaHrTQv1roWsAlYrzcp/RYBKm+tDb8/UXynxK0Ya0MTwXa/Spy6tp8jcf9+c1SRI
         VrnUMHAyh3Ri3y1KBS+GNlG6/S/HJE3MQqswtX4WSKzXtQvfyE2tJXlGTyVKCwguFjNF
         SZhQfaJg68+kV5Ri0jqeakbWCVtE/KlFt5IOBnkHtkw2lyht3SNL49GzmdJM7XAVl5KU
         eWwNQZJpSzaBsxbqv1ug46QuJ/dJ5hp1HaKUxnTIvMNmuBSjVTrEKvp/EpALbYYpop+Z
         PXpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787035732; x=1787640532;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=xx1Wdt2gxZFYTf9eirquKL7iCA2KvE+DVau7VDFh+X4=;
        b=k1UERO+uX6e+FavO8R0b9XWQ0MZg5a2OXLIN5qT/86u56wO+TmMuB6JQbbRz8fDm2o
         EmdIyS/ZoX4RZSXgpFfaz2TEQ2t7NI1CAzgAQGofeSKeziFbaYboTcpk2g6iwKJ0yaaR
         x7QUUmZwXRP/4TZi3vlyR9MvFpPtdu2QfEbGrLwhKduikxjDemiY0zhMJ/68iDFzcjwi
         sXRXD3WdSRmYM7rxwglNTWew1I6E/ZFanOVDrfo3GHggz8L3QkpjVcOyRF+c05SuhAfN
         dReXVB/k260968fG3gkZ++Qwg6kEXTti58C0mjWINrIX6qT6hbkZxeFrkOWz3alYqRJW
         WL1Q==
X-Forwarded-Encrypted: i=1; AHgh+RpWExInshsTS784ws7itVtdEDoodkjK2DvlRM0jpon62RptIX9L4dniRM7fN2e4bHRjcOlDgsbhyGw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZalNhevz98nrnjS5UZiHS+hjDkeslpJamcmVAQlRLh3oCReic
	kHfiFGyNoztKkhklIctcbyX6nDZG7guB6bIodgrrZCsX0BarixLeJD5addItMpRaiw==
X-Gm-Gg: AR+sD10Pgq3f7M7me62kGqtpbILo0oos2PIErTi65hP1T5gOPi0/wh09gwfbz4a2qJ2
	pwgwx9MW5SMEQwoTc64kSUsK4vYbQ2lzdHv8CcEGyu6Yo0f48mIf+5RmJn2TNVfGQ+QslopfBCJ
	4E1bSpy1ubfAmrs5zhG518TnRgR4Yl9LMfD0eGaAeOGkknfbM9DbF4aQh+1p2SRCXwz6B8iUCat
	yn/8M2ozzzAvDuH/MLS+/3shLGmZzgkxaD6KpoKfVlljfwjixGC14OdmGZZg4dtJlUxbSj2L+TR
	wdEl0i4gI54VKl7ysyQhow/tkakc/JNEMIeeY4Sih6CYCY/v2GaKB11t+41F1ARH0/q0OcxI9Cc
	J9no9llxZxHIYmQGb1ZVpglt9SZuCHPbD5WpXoFDHYgIGLbsfVJmGhRQBH2OQjDohyBqpAQ9T9G
	rpi2aqF2ZM5VqTXwOCddysou5E1hli8liSYhECmyCvOZ733+qVZI18UzYIiCt7A0jwEX+vrD7FM
	ykcpPQYbHInQcaBGLSLUY5Cs4eadLxzS2NnqgsRI18sPaIhKjSX
X-Received: by 2002:a05:6000:46c8:b0:482:552f:ef68 with SMTP id ffacd0b85a97d-482552fef9bmr31887304f8f.19.1787035732210;
        Mon, 17 Aug 2026 23:48:52 -0700 (PDT)
Message-ID: <d0b7d31d-f824-46ec-a085-84c01fd4f1b1@suse.com>
Date: Tue, 18 Aug 2026 08:48:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] xen/sched: fix crashes when vcpu creation fails
To: Furkan Caliskan <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260818063259.18733-1-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787035732-5113AA5B-72496303/0/0
X-purgate-type: clean
X-purgate-size: 388

On 18.08.2026 08:32, Furkan Caliskan wrote:
> Furkan Caliskan (2):
>   xen/sched: core: skip missing vcpu slots in sched_move_domain()
>   xen/sched: core: kill unarmed timers on sched_init_vcpu() failure
> 
>  xen/common/sched/core.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)

Just one formal remark: Both patches look to be in want of Fixes: tags.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:11:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:11:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393487.1632297 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDyc-0008An-LZ; Tue, 18 Aug 2026 07:11:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393487.1632297; Tue, 18 Aug 2026 07:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwDyc-0008Ag-Ip; Tue, 18 Aug 2026 07:11:14 +0000
Received: by outflank-mailman (input) for mailman id 1393487;
 Tue, 18 Aug 2026 07:11:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwDya-0008Aa-Cd
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:11:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwDyZ-00E9gW-Kw
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:11:11 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a84058f-2eae-0a2a0a5409dd-0a2a4507ca50-2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:11:11 +0200
Received: from [209.85.218.46] (helo=mail-ej1-f46.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a84058f-b4ea-0a2a45070019-d155da2eb9c0-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:11:11 +0200
Received: by mail-ej1-f46.google.com with SMTP id
 a640c23a62f3a-c1f758014b8so432455566b.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:11:11 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2185bc9697sm114423866b.61.2026.08.18.00.11.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:11:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787037071; x=1787641871; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=lJBBmG4p9SbIc89wJomJR4a4+EyqUaza4PNsuDUiDk8=;
        b=f5rW/EZVmwSn/5IZSvY76AP7dwqIj6wHM3yqMb9RTvJ6S3aoZrWWZYJWiP7E7xG4i+
         PAe2TY6pkmtVhfLLBOBIxBdUojMhl6mDxfWqQFFU7jQVR+Q7iSlrNkiqa/J/RRCQyzSJ
         U+OLzZJgBaa0JDbiWJS+mkZBGi7VM41LmpS1pDOI4eRi4KcO7gsPGJgIfkQhwtHnaUeR
         Nq9VekHw/9ZYDDw4hAB3emkhx+3WriyvIqYH0gUzdcvwml2vjzUPFCwGKvaoxCkGtt5X
         XCxBbKr38E8vbca/LAYz6bSjxf6JqLrc/j20Btp0zmc3xBRMiZHRyKEF+35IaoLXBZuk
         crDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787037071; x=1787641871;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=lJBBmG4p9SbIc89wJomJR4a4+EyqUaza4PNsuDUiDk8=;
        b=Zum3v6aqTnGfKLZdYGXllha9HfVCw9pHGHjqNpM78oOGWQQJJIHrHK4lz9iWrhDbht
         bxxEHuXjFDMvZMsNqRPYLFb/dElNCxWScLY9wRSr3cYTU0FUKaJW5sxDDpEOLbr/Fz9r
         c4EFNj3JxE73TdHGpxG+kpZs2zbYJuRd8h/I/9sY2oMyIjiQg9bsmfyW2FZrXgx5+zey
         I4m4AxnY8T6ujUoXKq+wWMUrQ6MOVcQC6zYlxNU09wSyetXF/CIjNpx4r02I3Fyi6mpP
         ZjqfpCcvfqsW/REr2kY2lIUPhCxn1VoEr4L9RZt+vbOsouElNQycUnDI8bT/xRdxx7D5
         RQnQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr7LMmLgVqltqEdpEHy+VHhc4rCP2Dvo5bV0YtgJnF/iwyvTBL1yFRi3Z9zFy9ndxB7PY75RhJYonk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywj8K76QgUnuWJ3IW32yMJ5i1QpYsomjY80iZVMYHu/y80oPGSm
	9zrSoFT++TgM6XXDyTtk9P9eK32PrCeBPmkPwHhMrQrGqnRM273a6fkHNWLQJFdoKoCH5ZSdfMC
	pWb01SHA=
X-Gm-Gg: AR+sD1041jIFlyy7AGDmprXOo4/sOQn+b1iDNiKYBUJtTsSvxq97r7UKBfvhH7WFTle
	E0v5a6Tdi32Dn8qTI7PelRXCw2keUhNclKgI6sCOgNgnKv3nbaFyKH+eFhNoXUm3n59Q4D0rBC2
	bXu25jAXl9XKWmsluS83Z4C0JGOG4rNC0S3xskN0QRDKI5KJ37TYVTjkcj6BxnMddvFgdvnSsiB
	90fiMvTEEnqX5yrSvwNemCixGESLEWmfyEwUmyMB1khZKKVJcAP4imSSP2GVNTABNv8781aDt4B
	BWvHJ/TRAAqFiwyY9rBoz4Hvkybt8D2h2X+y8Cz5FmuKZAFypXBouQTb3V2YDH2SzVPJSrsRTuS
	V0idboV+4fqwJPx3wZ28wvWP7Buljm0YWjrpNxfdLemLex1RsS9plHaotiCeatCNwAYzZRuA2/p
	pMPAp3KcZ271SM5B/W13o2r8jA/4Ru+rm6h8XP5SNvNPaXkoFoNVBASK+XwiI5PR9ie3n/NRxfx
	eqBpCoD838Rqnr0+BpoKbMFQA5IntAJoX+qg+L/0d02RaHA4i4U0PEUpLXrplovB15jvZkNY6Rb
	4S9vjpwnTIKOLQ==
X-Received: by 2002:a17:907:3d11:b0:c20:9447:bd5e with SMTP id a640c23a62f3a-c21884b519dmr276162866b.9.1787037070802;
        Tue, 18 Aug 2026 00:11:10 -0700 (PDT)
Message-ID: <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
Date: Tue, 18 Aug 2026 09:11:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260818063259.18733-2-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------gooG7Y2TfRwRFUlti7DQtiGN"
X-purgate-ID: tlsNG-ef75cf/1787037071-35EC6AE4-1F475732/0/0
X-purgate-type: clean
X-purgate-size: 11474

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------gooG7Y2TfRwRFUlti7DQtiGN
Content-Type: multipart/mixed; boundary="------------7hedWnIs9IyQlpaeDdjENRpr";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
Message-ID: <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
In-Reply-To: <20260818063259.18733-2-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------7hedWnIs9IyQlpaeDdjENRpr
Content-Type: multipart/mixed; boundary="------------q5lpfLmyCi7F2MqenCajxyNi"

--------------q5lpfLmyCi7F2MqenCajxyNi
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTguMDguMjYgMDg6MzIsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gc2NoZWRfbW92
ZV9kb21haW4oKSBkZXJpdmVzIHRoZSBudW1iZXIgb2YgdW5pdHMgdG8gcmVidWlsZCBmcm9t
DQo+IGQtPm1heF92Y3B1cywgd2hpY2ggaXMgZml4ZWQgYXQgZG9tYWluIGNyZWF0aW9uIGFu
ZCBuZXZlciByb2xsZWQNCj4gYmFjayBpZiB2Y3B1X2NyZWF0ZSgpIGZhaWxzIHBhcnR3YXkg
dGhyb3VnaCBidWlsZGluZyBhIGRvbWFpbi4gU28NCj4gZC0+dmNwdVtpXSBjYW4gYmUgTlVM
TCBmb3Igc29tZSBpIGV2ZW4gdGhvdWdoIG1heF92Y3B1cyBzdGlsbA0KPiBjb3VudHMgaXQg
LSB0aGlzIGhhcHBlbnMgaWYgc2NoZWRfYWxsb2NfdWRhdGEoKSByZXR1cm5zIE5VTEwuDQo+
IA0KPiBUaGUgcGVyLXVuaXQgbG9vcCBkb2Vzbid0IGNoZWNrIGZvciB0aGlzOiBpdCBzZXRz
DQo+IHVuaXQtPnZjcHVfbGlzdCA9IGQtPnZjcHVbdW5pdF9pZF0gKE5VTEwpIGFuZCBoYW5k
cyB0aGF0IGJyb2tlbg0KPiB1bml0IHN0cmFpZ2h0IHRvIHRoZSBkZXN0aW5hdGlvbiBzY2hl
ZHVsZXIncyBhbGxvY191ZGF0YSgpLA0KPiB3aGljaCBhc3N1bWVzIHZjcHVfbGlzdCBpcyBh
bHdheXMgdmFsaWQgYW5kIGNyYXNoZXMgWGVuIHdoZW4NCj4gaXQgaXMgbm90Lg0KPiANCj4g
UmVwcm9kdWNlZCBieSBidWlsZGluZyBhIGRvbWFpbiBpbiBhIG5vbi1kZWZhdWx0IGNwdXBv
b2wgd2hlcmUNCj4gdmNwdSBjcmVhdGlvbiBmYWlscyBwYXJ0d2F5IHRocm91Z2gsIHRoZW4g
ZGVzdHJveWluZyBpdC4NCj4gZG9tYWluX2tpbGwoKSBtb3ZlcyB0aGUgZG9tYWluIGJhY2sg
dG8gdGhlIGRlZmF1bHQgY3B1cG9vbCB2aWENCj4gc2NoZWRfbW92ZV9kb21haW4oKSBiZWZv
cmUgYWN0dWFsbHkgZGVzdHJveWluZyBpdCwgY3Jhc2hpbmcNCj4gaW5zaWRlIHRoZSBkZXN0
aW5hdGlvbiBzY2hlZHVsZXIncyBhbGxvY191ZGF0YSgpIChzZWVuIGluDQo+IENyZWRpdDIn
cyBjc2NoZWQyX2FsbG9jX3VkYXRhKCkgLT4gaXNfaWRsZV91bml0KCkgLT4gTlVMTCBkZXJl
ZikuDQo+IA0KPiBCZWZvcmUgYnVpbGRpbmcgYSB1bml0IGluIHNjaGVkX21vdmVfZG9tYWlu
KCksIGNoZWNrIHRoYXQgYWxsIG9mDQo+IGl0cyB2Y3B1IHNsb3RzIGFyZSBwb3B1bGF0ZWQs
IGFuZCBza2lwIGl0IGlmIGFueSBhcmUgbWlzc2luZy4gVGhlDQo+IHJlc3Qgb2YgdGhlIGZ1
bmN0aW9uIHdhbGtzIHRoZSB2Y3B1cyB0aGF0IGFjdHVhbGx5IGV4aXN0LCB2aWENCj4gZm9y
X2VhY2hfdmNwdSgpIHJhdGhlciB0aGFuIG5fdW5pdHMsIHNvIHNraXBwaW5nIGEgdW5pdCBo
ZXJlDQo+IGRvZXMgbm90IGxlYXZlIGFueXRoaW5nIGVsc2Ugb3V0IG9mIHN5bmMuDQo+IA0K
PiBTaWduZWQtb2ZmLWJ5OiBGdXJrYW4gQ2FsaXNrYW4gPGZybjFmdXJrYW4xMEBnbWFpbC5j
b20+DQo+IC0tLQ0KPiAgIHhlbi9jb21tb24vc2NoZWQvY29yZS5jIHwgMTkgKysrKysrKysr
KysrKysrKysrKw0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspDQo+IA0K
PiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMgYi94ZW4vY29tbW9uL3Nj
aGVkL2NvcmUuYw0KPiBpbmRleCBkM2EwYTk3ZTFkLi5kNTQyYzc2NTQzIDEwMDY0NA0KPiAt
LS0gYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYw0KPiArKysgYi94ZW4vY29tbW9uL3NjaGVk
L2NvcmUuYw0KPiBAQCAtNzQ1LDYgKzc0NSwyNSBAQCBpbnQgc2NoZWRfbW92ZV9kb21haW4o
c3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGNwdXBvb2wgKmMpDQo+ICAgDQo+ICAgICAgIGZv
ciAoIHVuaXRfaWR4ID0gMDsgdW5pdF9pZHggPCBuX3VuaXRzOyB1bml0X2lkeCsrICkNCj4g
ICAgICAgew0KPiArICAgICAgICAvKg0KPiArICAgICAgICAgKiBTa2lwIHRoaXMgdW5pdCBp
ZiBhbnkgb2YgaXRzIHZjcHVzIGlzIG1pc3NpbmcuIEJvdW5kZWQgYnkNCj4gKyAgICAgICAg
ICogbWF4X3ZjcHVzLg0KPiArICAgICAgICAgKi8NCj4gKyAgICAgICAgYm9vbCB2Y3B1X2Zh
aWxlZCA9IGZhbHNlOw0KPiArDQo+ICsgICAgICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0g
MDsNCj4gKyAgICAgICAgICAgICAgaSA8IGdyYW4gJiYgdW5pdF9pZHggKiBncmFuICsgaSA8
IGQtPm1heF92Y3B1czsgaSsrICkNCj4gKyAgICAgICAgew0KPiArICAgICAgICAgICAgaWYg
KCAhZC0+dmNwdVt1bml0X2lkeCAqIGdyYW4gKyBpXSApDQo+ICsgICAgICAgICAgICB7DQo+
ICsgICAgICAgICAgICAgICAgdmNwdV9mYWlsZWQgPSB0cnVlOw0KPiArICAgICAgICAgICAg
ICAgIGJyZWFrOw0KPiArICAgICAgICAgICAgfQ0KPiArICAgICAgICB9DQo+ICsNCj4gKyAg
ICAgICAgaWYgKCB2Y3B1X2ZhaWxlZCApDQo+ICsgICAgICAgICAgICBjb250aW51ZTsNCg0K
SSBkb24ndCB0aGluayB0aGlzIGlzIGNvcnJlY3QuDQoNCklmIHRoZXJlIGFyZSBzb21lIHZj
cHVzIGluIHRoZSB1bml0IHlvdSB3aWxsIGxvb3NlIHRoZW0gKGkuZS4gbWFrZSB0aGVtIG5v
DQpsb25nZXIgYmUgYWJsZSB0byBiZSBzY2hlZHVsZWQpLCByaWdodD8NCg0KRm9yIGEgZHlp
bmcgZG9tYWluIHRoaXMgbWlnaHQgYmUgb2theSwgYnV0IG5vdCBmb3Igb25lIHN0aWxsIGFj
dGl2ZS4gU28gSSB0aGluaw0KeW91IHNob3VsZCBhdCBsZWFzdCB2ZXJpZnkgdGhlIGRvbWFp
biBpcyBkeWluZywgb3RoZXJ3aXNlIHNjaGVkX21vdmVfZG9tYWluKCkNCnNob3VsZCBqdXN0
IGZhaWwuDQoNCkFuIGFsdGVybmF0aXZlIG1pZ2h0IGJlIHRvIGZpeCB0aGUgTlVMTCBkZXJl
ZmVyZW5jaW5nIHdoZXJlIG5lZWRlZCwgYnV0IHRoaXMNCmNvdWxkIGJlY29tZSB0ZWRpb3Vz
Lg0KDQoNCkp1ZXJnZW4NCg==
--------------q5lpfLmyCi7F2MqenCajxyNi
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------q5lpfLmyCi7F2MqenCajxyNi--

--------------7hedWnIs9IyQlpaeDdjENRpr--

--------------gooG7Y2TfRwRFUlti7DQtiGN
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqEBY0FAwAAAAAACgkQsN6d1ii/Ey+R
NAf/bNDLqq7iLu3A8eVMZ7XZJM9PZY89Q5Wxrb+MdBOQQZdpzQb6yLI5SyrMFyid2qaZzgDe/nx2
2TGG80waFKJ0+UWCeyME31Xwvzkh/QiF4jK3GBIEo7wWv4O4q+s/qvgcDxnJZL+Q55ugSNeZMvJ9
YEZVvTW+RiRmiEOrEwGoGkJ5291N/4EImjnWUjneg8ZXHic9WAghr2VHJyCZ3l6lvRttwbv9t+9I
5uXkyQYmSZvbap/dO9d18VhbChBQtjKmbPC23Feq9CYcgNTw3E/kguKyuvqWf5xjj9CPsR46KEGs
JBZOGSmFDnCVSLGS/AJuIlR2dOIekERcVUwxeX/YqA==
=Qzbl
-----END PGP SIGNATURE-----

--------------gooG7Y2TfRwRFUlti7DQtiGN--


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:18:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:18:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393494.1632307 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE59-0000QL-BQ; Tue, 18 Aug 2026 07:17:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393494.1632307; Tue, 18 Aug 2026 07:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE59-0000QE-7H; Tue, 18 Aug 2026 07:17:59 +0000
Received: by outflank-mailman (input) for mailman id 1393494;
 Tue, 18 Aug 2026 07:17:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwE58-0000Q8-NX
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:17:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE57-00EAxZ-II
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:17:57 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84071d-bab6-0a2a0a5309dd-0a2a4509eb02-24
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:17:57 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a840725-be1a-0a2a45090019-d155802fac41-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:17:57 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-495590dde14so52655725e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:17:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7840esm8853223f8f.29.2026.08.18.00.17.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:17:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787037477; x=1787642277; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=L7FAbteNVTVo+lqbCQIlVu+Buu38SbMZ2XQYRGm7L2E=;
        b=WGv0vFvIbV0zADH6y3I87cubRFOFJ41HaeQKOKVvenx3UXwpaAuLjpAf288EwaIrOi
         zP2ZJWQ9+vcIbR39MmvhX1RlvG/+RN8wLgvX1T1OW2qfyguE+Du9NHjtzHOI6yb5Ft4c
         587Ev5Hz7fb1BPUN4kfIPx641NM2dYsnsu6w0wC344oMZbBT8oD4YmD7mATXL5QSlrHt
         avRLLhGKSYGkeTBCfYXCTkmkb1HQvmkJUEWYb95fBZuTxknxzb8prsvi427PILo584lg
         Qfhjj4tU8CV2lrb12AMffXnm2b1+citBj5hmM9vIjSyB6YmBExtfaI7yxmZjQnXgscUX
         QaGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787037477; x=1787642277;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=L7FAbteNVTVo+lqbCQIlVu+Buu38SbMZ2XQYRGm7L2E=;
        b=hpXmfqkqC4v+P1uLBdImCztM30NLDfP5CXuQALM+a7NZK7BfETQZ70Aj/kzUPSzMF+
         NRcCBO7tTC1rymDWvjLpDFCJUy5x7btIaSCyBC8fk7y9T0zZYKgdeeOxUBd7CCnMkT2J
         VEBvAxISENk3+rhcsEn/aTnBfOgOfSPpACkTiYsPOzglJUt/QCD3TdgBkOfHOh+WKIAC
         En5KiaZelps+72LCpAkrkwHLoln1R+je9Hq/sw/PvpGOZlhXXjoyNqYxQ83gaRg6IqH0
         yvIKjKM7bZiYHVzyDZCAkdeIfEx4smHYNAgLFafc6O5rvmfSgSj2JMR8WimD4TSZwJ5F
         OOjA==
X-Forwarded-Encrypted: i=1; AHgh+RrNu5vIA5PlDCkDWHKaTwvYO6hri3hFYQxNrvlwS0cDRhc9W8AxyrqACnr45GQIXX4lSMQJ4ao0jPs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzN5F9dK3FGA9LS0Z+vqIvhF6zzC4Q1KAsgh5WmgwDb2bPF4UgL
	ZwyDJay6jbpTyjjaVasPKBjErsYBo3xrcQKYhrDnhpQHNcaUsSSQQYEzv/z3OBHRDQ==
X-Gm-Gg: AR+sD138e8t0uaTaUAuCiIcwP8cdbDHUvFQ4bdfcUtKdDsoET8tY1DXv7V/TbCMyJI2
	pyuU7nLN6d+qPiWYnWSAa+b940AA4pCluG+RVkewsL44915VtHdhROA7PkKBP5Oan/upHs4eLO0
	5pdzA4eSi19HrzyJdqSs9ACnJq/HE79jdC+DyowUVtLXei8U52XK3NQhoEYIGhg7h3Iw0GnSp/a
	JiUGLKWg9QzoEl0Qba5UqJqjDtwqj4fXIhWqU/S6e2RUqlGOzKDNLiEut/TX6p0lasHSQCmYDbL
	nTGC+ie2c9N32Sg3h5ywU/wiBoh3sJ4COA56oeSSh0CQ0bF5f4KawsC4+HLrPO2koHPDrgnvGE4
	uTBXDkIryF+yTfN+J524VQbXCA9ULMOQZ4T9qCcEss6wAN1x68YKFPfu9U7+cULRWloWLJmBOHL
	t5pgnf4TGh9xJUS1VbzCasrkTSCCJzw9NJr+3UFRqbXwr/SgbfNW2+pbrCy5pbUNRS18o/Yc+PW
	yPOQ5w3iFQKEiLGv8cpqyjG13n393tK5aV6NbHKWKpjMHhHa2Gx
X-Received: by 2002:a05:600c:3b8e:b0:499:a660:f926 with SMTP id 5b1f17b1804b1-499a660facemr1547315e9.11.1787037476748;
        Tue, 18 Aug 2026 00:17:56 -0700 (PDT)
Message-ID: <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
Date: Tue, 18 Aug 2026 09:17:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787037477-BE8D9034-61AA8779/0/0
X-purgate-type: clean
X-purgate-size: 4725

On 17.08.2026 18:04, Chuck Zmudzinski wrote:
> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>> -- snip --
>>>>>>>>> +    /*
>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>> +     *
>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>> +     */
>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>
>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>
>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>
>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>> by its DM.
>>>>>
>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>
>>>> Can you explain to me how the region becomes accessible to the guest?
>>>> That would then (hopefully) help me understand why the DM would not have
>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>> guest are also assigned to its DM.
>>>
>>> Currently, in the device model (Qemu) we have:
>>>
>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>             DPCI_ADD_MAPPING);
>>>
>>> That statement is in the igd_write_opregion(...) function in the
>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>
>>> If I understand our current implementation correctly, this statement
>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>> in hvmloader code).
>>
>> No, it introduces mappings of those pages into the guest's P2M.
>>
>>> I don't think this statement makes the host OpRegion
>>> accessible to the device model, though, so I think, if I understand your
>>> comment in an earlier about my patch resulting in what you called a "layering
>>> violation" correctly, that our current implementation is also guilty of this
>>> same kind of "layering violation."
>>
>> That code, if it can be successfully executed, indeed doesn't grant any
>> permissions (to the DM or the guest). Instead it proves that the DM has the
>> needed permissions to access the pages itself.
> 
> So, are you saying it should be possible, without any patches to either Xen or
> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
> 
> I think I could implement what you proposed in an earlier message and do
> all (or most) of this in the DM instead of here in hvmloader:
> 
>> The more correct thing to do might be for the DM to
>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>> (How in turn the DM would learn of the contents of the opregion is a
>> separate question then.)
> 
> Actually, when I was developing this patch, I tried first to do it that
> way, but the problem was, I could not find a way to get a pointer to the
> host OpRegion in Qemu.
> 
> So, how can I get a pointer to the host OpRegion in Qemu?

You don't ask me this question, do you? All I can say is that surely qemu
has an existing way to map (host) physical memory; see e.g. how
xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
device. "Bogusly" there because that's another layering violation. Plus
(independently) there and here there's the issue of how to accomplish
things when not running in Dom0, or when running de-privileged in Dom0.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:18:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:18:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393501.1632316 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE5f-0000xV-Mm; Tue, 18 Aug 2026 07:18:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393501.1632316; Tue, 18 Aug 2026 07:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE5f-0000xO-Ib; Tue, 18 Aug 2026 07:18:31 +0000
Received: by outflank-mailman (input) for mailman id 1393501;
 Tue, 18 Aug 2026 07:18:30 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwE5e-0000uP-83
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:18:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE5d-0083Au-1r
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:18:29 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a84073a-bab6-0a2a0a5309dd-0a2a45028cbe-32
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:18:28 +0200
Received: from [40.93.195.12]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840743-6ca4-0a2a45020019-285dc30c18cc-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:18:28 +0200
Received: from CH0PR03CA0265.namprd03.prod.outlook.com (2603:10b6:610:e5::30)
 by CH3PR12MB9344.namprd12.prod.outlook.com (2603:10b6:610:1c8::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 07:18:21 +0000
Received: from CH3PEPF0000000A.namprd04.prod.outlook.com
 (2603:10b6:610:e5:cafe::2d) by CH0PR03CA0265.outlook.office365.com
 (2603:10b6:610:e5::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 07:18:21 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH3PEPF0000000A.mail.protection.outlook.com (10.167.244.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 07:18:21 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:18:21 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 02:18:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YuYiYgyr19k1jojvGRrx8t3xDEZKsyXf0iV1p4pc0FZQwzr8V29Ys5Vnacsd9B+FqPND7FYuxfaMK5DNNvvv797Ts6urLnw9jHoviIkHry1i0X4nniZWCt8KUTuwK9GEc4bQdD+v/6PRwm7oOw5wNI9hxMJ8CeWTrqc5ZL/lZYg616ZX0P5IhqL+hqaQR5Fuo1X+jBWZidUEvHJbMrhWRwlZyGv6fZdSyr13qei2/Hq/NVp76+jGClhYU8zGSBk+5lKWgewHzdyHRuBityqiniqARWhk/SNnSHikRzQWOmofQeZZ5mLfs2J1Fh/TqXYEiW6D7MEgi42BoWVFqTh75g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2VKtktAghtvAyfShnMl7Gov2iTCHFu/RnL+YdTnPlnU=;
 b=qqOLqQMDTLt0doS0M4EWoBwcFNxywSeXnjTcTCeKOFRHf0m7arGAIBaQTt1ISawXjZI9/FfeJHZxHoDiW7UCQoW1tbTqgthtBFCKh0usrzQiRA7QuOZC/SUvpvDZUNnTdUbQ17zPCPZ1JuhVTeuruhKJycWUpDGHH9AgjOtjZ76afNg9m3spVRz7I47PoKwUh7WliKbfR3A50HiCtqOu6ErThESSpsqw27jYei5FgZ79FiArGgWQLhHjtJleTH45H5/1fmn+kyBqxrjrjChNuYb0FZtnRJuIm6kiy8p3xhf2Bl2eJGm6swXskFe9gJLa72X+scT8DL5Wn5YmX6HZYA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2VKtktAghtvAyfShnMl7Gov2iTCHFu/RnL+YdTnPlnU=;
 b=wjh11NAL5zIlJZMYnGAUVrH2PIgAAV5UgR8OZaJTMzCNzt/YcPVSSvkhe0WOS65t1fKXUNiYYl6KnbPmxItGPkubT9ZFFVGn5kzkcrXQgxdftQ82cIrNquMk2FJXHo7tvUPgxWD4SDKgm3JHUOkHLDSkBqx2Q1XOzrtBFddOM1w=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <e820d885-123e-49f8-b6e7-f0cd2e7fcd99@amd.com>
Date: Tue, 18 Aug 2026 09:18:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen/char: add classic i.MX UART driver
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
 <20260818025224.4165503-2-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-2-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000A:EE_|CH3PR12MB9344:EE_
X-MS-Office365-Filtering-Correlation-Id: daa165a2-460e-4734-ec64-08defcf8e2b2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700016|82310400026|376014|23010399003|22082099003|18002099003|10067099003|11063799006|56012099006|4143699003|6133799003;
X-Microsoft-Antispam-Message-Info:
	FBuzX7xduSqKF5CJANfuRm9AxYdkCHngcpu33DTXLm1s9Id3MSKeP6EA31LNLepHlfT/gjeYsIfexffOvOPwTHLor0ajcPxzoOFDx4/s+pCjRykzruqPXl2URqqb87M43BBLPORP7FnUdWrc2Uk3rsMWvVApqwQ/4ruxJfqh4PS4qmaKHfm4pARWrMgMXZeFc6SSeZugIIu16swCsMagQ8mWJjY2YNap0iFQfRD4pYmT0+eMR8UaItOC0ECuZYxJaFLrpipb2xS1J9blTFhllMs1w5xgZQCPKqIIC1ZhW5YJ2q0VKe2wy/tyLQAW5gIRoW4PZt6VgTtvbRnOKHhHCqSFo0cDYEPY1IdNvH0qJzh6ThuVwLLVBpR82aWT+FhophRtcnr7CR+nMl3bPNxFQi0Uwg4YVpytOFLf/zbylA7ecXSdFPQtVnCxj9ZY/Y+/e/lrUWIIm71vJlN/Nlodl+crqfBoomujkQPMAqztXQ0OF5XlM8pIcWdJkjT4CUAvAiARNghHoYjlIEabZ4pYKkpZl6D8F0UYGJL6JOPHoBtAfme3ms1WqS+RdpJt6f3m8fh6CtLZfmEbmUnNOjFpWDG9/WWBASeVsiUhM78MJlZNlUI8M9QycZ0BmzfMMp2PqJk84CZRRt1txZXvqFGZFZOaQLkiY9DqXTU2d98mzPLCqUTxvucvFYxUD4gef8npITyV754AFzmnfOCoAFs1dQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(82310400026)(376014)(23010399003)(22082099003)(18002099003)(10067099003)(11063799006)(56012099006)(4143699003)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	2Et1/Qs7+6m1FHjJNk9QPUrXKrXWpdNE9yYl+ziBOyxcH8RNQFPiEJ/Xk5eheeiDL4zcaWViF8o9YEk3j/Q9J+8sIXdb9T/6krXkzh2Y8AfAgdiZRVuXHKShkU3EELpe6XISr28cDO8c2FqiPnc+o7JqzkTeKinytkgLYX1BTIDWKVrzgoIJIi8hDriP+dsuHSHIj6Bxzu6xZ++d57AEMXlltLLu74TTZYnu2aw9GBoapVyO3pJKjRa7gnQnZ+kqcnmn7hBl5xYqV+LynUoC56uMpZo3KcRjALJSBX5gc0rkHrJ+SImqZE9osa89LS6aYGnrgTDDqtOKErDFuwbZ90S3CHRG8Tyf3u++gZKGRSUdv83o4XkehQQPsQbCKBP92du9mEy1pAe6NeyKmOnQWEjnN825s1hcFOFOyWiXYOaGGLgFRFrrp3hji2NyajkQ
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 07:18:21.8380
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: daa165a2-460e-4734-ec64-08defcf8e2b2
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9344
X-purgate-ID: tlsNG-720697/1787037508-309C32AC-986DA9E5/0/0
X-purgate-type: clean
X-purgate-size: 7568



On 18-Aug-26 04:52, Wig Cheng wrote:
> Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
> compatible), used as the console UART on the i.MX8M family.  Baudrate
> and pin configuration are inherited from the bootloader; the driver
> only enables the transmitter/receiver and wires up the RX/TX
> interrupts, mirroring the existing imx-lpuart driver.
> 
> The i.MX8M family's UART IP differs from the LPUART used on
> i.MX8QM/8QXP, so a separate driver is needed.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/include/asm/imx-uart.h |  57 +++++++
>  xen/drivers/char/Kconfig            |   8 +
>  xen/drivers/char/Makefile           |   1 +
>  xen/drivers/char/imx-uart.c         | 226 ++++++++++++++++++++++++++++
You should add an entry to the MAINTAINERS file for imx-uart.c so that it falls
down under ARM maintainership. Your last patch makes you a reviewer but we still
need to be maintainers of it. See how it was done for IMX8QM.

>  4 files changed, 292 insertions(+)
>  create mode 100644 xen/arch/arm/include/asm/imx-uart.h
>  create mode 100644 xen/drivers/char/imx-uart.c
> 
> diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
> new file mode 100644
> index 0000000000..a3892020e6
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/imx-uart.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Register definitions for the classic i.MX UART IP
> + * ("fsl,imx6q-uart" compatible), used as the console UART on the
> + * i.MX8M family.
> + *
> + * Register layout taken from Linux drivers/tty/serial/imx.c.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#ifndef ASM_IMX_UART_H
> +#define ASM_IMX_UART_H
> +
> +#include <xen/const.h>
> +
> +#define URXD0           0x00   /* Receiver Register */
> +#define URTX0           0x40   /* Transmitter Register */
> +#define UCR1            0x80   /* Control Register 1 */
> +#define UCR2            0x84   /* Control Register 2 */
> +#define USR1            0x94   /* Status Register 1 */
> +#define USR2            0x98   /* Status Register 2 */
> +#define UTS             0xb4   /* Test Register */
> +
> +#define URXD_RX_DATA    0xff
> +
> +#define UCR1_UARTEN     BIT(0, U)   /* UART enable */
> +#define UCR1_ATDMAEN    BIT(2, U)   /* Aging DMA timer enable */
> +#define UCR1_TXDMAEN    BIT(3, U)   /* Transmitter ready DMA enable */
> +#define UCR1_TXMPTYEN   BIT(6, U)   /* Transmitter empty interrupt enable */
> +#define UCR1_RXDMAEN    BIT(8, U)   /* Receiver ready DMA enable */
> +#define UCR1_RRDYEN     BIT(9, U)   /* Receiver ready interrupt enable */
> +#define UCR1_TRDYEN     BIT(13, U)  /* Transmitter ready interrupt enable */
> +
> +#define UCR2_SRST       BIT(0, U)   /* 0 = issue software reset */
> +#define UCR2_RXEN       BIT(1, U)   /* Receiver enable */
> +#define UCR2_TXEN       BIT(2, U)   /* Transmitter enable */
> +
> +#define USR1_TRDY       BIT(13, U)  /* Transmitter ready */
> +
> +#define USR2_RDR        BIT(0, U)   /* Receive data ready */
> +#define USR2_ORE        BIT(1, U)   /* Overrun error */
> +
> +#define UTS_TXFULL      BIT(4, U)   /* TX FIFO full */
> +#define UTS_RXEMPTY     BIT(5, U)   /* RX FIFO empty */
> +#define UTS_TXEMPTY     BIT(6, U)   /* TX FIFO empty */
> +
> +#endif /* ASM_IMX_UART_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index 8e49a52c73..f237c0220d 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -30,6 +30,14 @@ config HAS_IMX_LPUART
>  	help
>  	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
>  
> +config HAS_IMX_UART
> +	bool "i.MX UART driver"
> +	default y
> +	depends on ARM_64
> +	help
> +	  This selects the classic i.MX UART. If you have an i.MX8M family
> +	  based board, say Y.
> +
>  config HAS_MVEBU
>  	bool "Marvell MVEBU UART driver"
>  	default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 8cbbffdca8..039f566926 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
>  obj-$(CONFIG_XHCI) += xhci-dbc.o
>  obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
> +obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
>  obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
>  obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
> new file mode 100644
> index 0000000000..fd34b0cd11
> --- /dev/null
> +++ b/xen/drivers/char/imx-uart.c
> @@ -0,0 +1,226 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), used as the
> + * console UART on the i.MX8M family (e.g. i.MX8MP).
> + *
> + * Baudrate and pin configuration are inherited from the bootloader.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/irq.h>
> +#include <xen/mm.h>
> +#include <xen/serial.h>
> +#include <asm/device.h>
> +#include <asm/imx-uart.h>
> +#include <asm/io.h>
> +
> +#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
> +#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
> +
> +static struct imx_uart {
> +    uint32_t irq;
> +    char __iomem *regs;
> +    struct irqaction irqaction;
> +    struct vuart_info vuart;
> +} imx8m_com;
> +
> +static void imx_uart_interrupt(int irq, void *data)
> +{
> +    struct serial_port *port = data;
> +    struct imx_uart *uart = port->uart;
> +
> +    if ( imx_uart_read(uart, USR2) & USR2_RDR )
> +        serial_rx_interrupt(port);
> +
> +    if ( imx_uart_read(uart, USR1) & USR1_TRDY )
Looking at Linux's imx.c you should clear TRDY if TRDEN is not enabled to
prevent RX interrupt entering serial_tx_interrupt as TRDY is a raw status register.

> +        serial_tx_interrupt(port);
> +}
> +
> +static void __init imx_uart_init_preirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1, ucr2;
> +
> +    /*
> +     * Reuse the bootloader settings; only enable the UART and both
> +     * directions.  The console uses UCR1 interrupts (RRDYEN/TRDYEN)
> +     * exclusively, so just clear UCR1's interrupt and DMA enables.
> +     */
> +    ucr1 = imx_uart_read(uart, UCR1);
> +    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_TXMPTYEN | UCR1_RXDMAEN |
> +              UCR1_TXDMAEN | UCR1_ATDMAEN);
> +    ucr1 |= UCR1_UARTEN;
> +    imx_uart_write(uart, UCR1, ucr1);
> +
> +    ucr2 = imx_uart_read(uart, UCR2);
> +    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
> +    imx_uart_write(uart, UCR2, ucr2);
> +}
> +
> +static void __init imx_uart_init_postirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1;
> +
> +    uart->irqaction.handler = imx_uart_interrupt;
> +    uart->irqaction.name = "imx_uart";
> +    uart->irqaction.dev_id = port;
> +
> +    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
> +    {
> +        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %d\n", uart->irq);
uart->irq is unsigned, so s/%d/%u.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:18:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:18:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393503.1632324 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE5j-0001C7-SA; Tue, 18 Aug 2026 07:18:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393503.1632324; Tue, 18 Aug 2026 07:18:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE5j-0001Bx-Pd; Tue, 18 Aug 2026 07:18:35 +0000
Received: by outflank-mailman (input) for mailman id 1393503;
 Tue, 18 Aug 2026 07:18:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwE5i-0001BQ-Q7
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:18:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE5i-0083Au-6u
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:18:34 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840743-bab6-0a2a0a5309dd-0a2a450bbc36-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:18:33 +0200
Received: from [52.101.193.63]
 (helo=CH1PR05CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840748-b7e8-0a2a450b0019-3465c13fb579-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:18:33 +0200
Received: from CH0PR03CA0003.namprd03.prod.outlook.com (2603:10b6:610:b0::8)
 by SAVPR12MB999143.namprd12.prod.outlook.com (2603:10b6:806:4e5::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 07:18:28 +0000
Received: from CH3PEPF0000000C.namprd04.prod.outlook.com
 (2603:10b6:610:b0:cafe::16) by CH0PR03CA0003.outlook.office365.com
 (2603:10b6:610:b0::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Tue,
 18 Aug 2026 07:18:28 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 07:18:27 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:18:27 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 02:18:26 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=s2NDtwdDLcVVwGlFnimHClKCa5AZwxEVuq3o6EvsKV773sriqiQsRGaqV0jlTgsEEMlKnTHPSC/UiGHx3dUCpO1rdlNnkTgTi3oSyTLs+mTXG1EIvIi67dkAfQDYm6goi6NclxUm6CEXq7DZN0ebRtnpNNgmKWXyzxWCk4ULBPmlIHtWBabSi/2x9jsB7CRY82zXSwyBEC8Ug5VlfYo8kcNc2IbcuEi7vIxGgCWGOsTwGOlpGBzVRkmTbEO+SoTPZFca2vAlEcWmrZyaa3yxo25pHhQ8yRK9Fy+Y05w+XKGBrFsvFpO2cSpr/fSVP2dfwkXnkf0XypWoOsnOO04v8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Nfr/XdqaQfwcneuaTPPE2HBtDkQgRyv4jhc+Rw/0Va4=;
 b=elDCXLK18L2vaKUoGxyV+qxZR+fDALo1iKo3GtcwxBcYGsa70CqodUtY7f8MSwZmDfwZVf34eSJMEhFxTJ+3Lxv4464zzQLcHzd/mJIm/x/tw6eMPsYWs8ygHKpX/h82hzfRaPxH5IHWvDaoqM7mVZH3fTvokAUerjI+wMRaziLDMk6bdHUe7JlKoyVaajYpz+EYMhPDcjsO3T9WxGi/1Z8BDBwgkCGiFVh25jEGAILg4WU02u/Kjlbq2yDlXWKW5wZpNlVDMvEWjEMHOS5bvt+AI327hHqUbIiE/5jM9y1q2lSAXNcVCyZXh/8gZdZeOVcJeACKvXQ5TbOG7g9UoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Nfr/XdqaQfwcneuaTPPE2HBtDkQgRyv4jhc+Rw/0Va4=;
 b=lie7NOfuNTs4lkD9Bj7fdLWTxdZd/eWZMQilJNFmXM+UumhXdMIUQR6yHu573R+1PGNubmHz20s35zbtFA4e3vO0QxLDzHzZCSYnOBFNqncYs9zZAh8Zu+8Bpdd3NtImuVcO4qORGKIkT8UszghBKzpqxjAqudZVKxfFXmMz0bY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <d80dbc73-d69f-4f68-a508-7a7c5ea30c12@amd.com>
Date: Tue, 18 Aug 2026 09:18:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/4] xen/arm64: add early printk for the classic i.MX
 UART
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
 <20260818025224.4165503-3-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-3-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|SAVPR12MB999143:EE_
X-MS-Office365-Filtering-Correlation-Id: c8f6dcb5-0b60-4244-0c39-08defcf8e65d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700016|23010399003|376014|82310400026|18002099003|22082099003|10067099003|56012099006|11063799006|4143699003;
X-Microsoft-Antispam-Message-Info:
	zkKANjQmV+XGkhuEMtrw+iMl16pG76u0+IvRvmjBdYiC/XMh70C2lI4g+em6beSVf8wNWUVldBzObddpKxrrKUnthiMlgvsGSudHIN0kS62F2HK73DB0FpY8GloS1IPpbjFJoEGYRSY6+h11gyio8yMQM0TA2O1aDfU75hT3Nd3v5jtLg+etC0/LAmD87oWH5zfRfO2/kZfmSoZ7rFItFO8RUQ7zVoqq1qNctEIjPkNbRB3/DoEZf3Ap1xmLviClC1beWeEp3jNLJT631kZqsR4Uq75V1ZeFGs2NvPdvpSJsBPuF/IvMbmR4SUZA16mxwyrjCx0202d5JjuYF6fDK6XVNmFERH2LqW9uBFO/sWc93Z8Qg8HdN0OX2K2D4TpuYGuZfMy2szr8c4raqftJhEMOP6nvg/2MRubJBeyQntUO9jQjAR5wj6wS21gLSu0S4M9WBgg/TxF1lUG3vcC8k5zqVwSMLfHn1WbcvfAHfjbcmHYOuFRburN38DkzGDgLpWHVOUKIcVzTl8E3AhEd8wisJ2Dzwjl21FWtiL4kbDaAHpoFm4pqUZtfMyKMbLTPX+XyHEpoa4R2AAAtIgmyAc3pCISdY0iN7aiv09UM3Fr1/fJBvtvcUdPFAFxZNHIyr55VuhUU7nTS4P7PiFuojT1ckbmeMC37WpkZnECO3aOKfEc1IDPMQk8I3S0IcHL6ufYqmQrAxXOOguP5ldbO1Q==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(23010399003)(376014)(82310400026)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006)(4143699003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	7CLv6Y3NFMs8DWorPlllsKw3fEazSdPvYjPo0XJKmDcqqtfPxN9rlFGUERoLUDv2yVpVq6ATA+g3jJaM5RIITwJag6vbvjsKAd8oahIPXNz2Y6bXYkNtR6t2tXiEUfpena9ADJxtufwxRbUq5ojSynNlAMnf7djFedIQwnOpre+SZC+JRH+a81nCEj52ega2vx8z19b/UYI395nNZFhhXg6PNumtsUa78P5b5OK5JJerICyo4QxOaBcdaL8KfWoB3/Pa7bRLRICzrkWIi3OdP/V0zKLV0pQtr7e2j0n5COpOHh7OvYoF3Vzbl5j9kHDSHo20VYSvrAR6vDsUJoxhwGfMxMLtcNmhYB73pDjBlIwXOkoIohAhEgzQoWcwIXF2uMSRc916KBrec7866NXSVewNtWvyrk7veu6Law3It3oK4JMF2q1hw5zaQcE8/QAW
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 07:18:27.9780
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c8f6dcb5-0b60-4244-0c39-08defcf8e65d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAVPR12MB999143
X-purgate-ID: tlsNG-42698a/1787037513-190CD9EA-2019530F/0/0
X-purgate-type: clean
X-purgate-size: 339



On 18-Aug-26 04:52, Wig Cheng wrote:
> Add an early printk implementation for the classic i.MX UART IP,
> selectable via EARLY_UART_CHOICE_IMX_UART.  The UART is expected to be
> fully initialized by the bootloader.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:18:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:18:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393505.1632333 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE5r-0001VN-3O; Tue, 18 Aug 2026 07:18:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393505.1632333; Tue, 18 Aug 2026 07:18:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE5q-0001VD-WE; Tue, 18 Aug 2026 07:18:43 +0000
Received: by outflank-mailman (input) for mailman id 1393505;
 Tue, 18 Aug 2026 07:18:41 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwE5p-0001Sh-JU
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:18:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE5p-001SIS-0E
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:18:41 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840741-8faa-0a2a0a5109dd-0a2a450cb95a-26
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:18:40 +0200
Received: from [40.93.195.24]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a84074f-f479-0a2a450c0019-285dc318355c-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:18:40 +0200
Received: from CH0PR03CA0015.namprd03.prod.outlook.com (2603:10b6:610:b0::20)
 by BN3PR12MB9596.namprd12.prod.outlook.com (2603:10b6:408:2cb::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 07:18:34 +0000
Received: from CH3PEPF0000000C.namprd04.prod.outlook.com
 (2603:10b6:610:b0:cafe::74) by CH0PR03CA0015.outlook.office365.com
 (2603:10b6:610:b0::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Tue,
 18 Aug 2026 07:18:34 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 07:18:34 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:18:34 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 02:18:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ofIcB+1E9aOz0UkvhfRrMgX94pUES2qyRLM7cZIj0OKrs2SEXaE0h8TIluWvPXBMgbxierhOifUtzp6WBuKEeqbvT/bmYzLIqMEPsfeyvQ0q6SgxQeW49OkBJ77wxyYEwwQ3JiNKLnE3eUXLLPR6ujebr58ePRCCyWn7VPyKe/4ikWWhI4CxR4F8UIk2eYgWK+coZc+AVcxpEuWkrlFhyNk1HS6DjjYcwXTi75C5BBMMI0EQFFj5QI+hAx968L8huD/ysES1Ohn7aIFOicaanbCY6HzQ5PKfXCcrqg8iDeQtADc0kqWQiddfTq3RXj37pLdNqQK88vYZuqgjSeX44g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QpcGkFvRyFdHnDIV8aQW+2Sdjn7ZdrKvUXdmQa2bF6I=;
 b=NphPv/QhjDkE/m203rKK21pInp1Xz4gpBU01l858gKZLtQgpgEAL2y0eskCrVZOxnRTr6EHGsLwSvGUeULsV5rQJLJj2jVL0U2+W4hZXOz3DrJBrjoBjp6vsGdhm8uDcJkf/ad3otWX3c48pc1Z4jKRPc+VjNwR1003DqDVOa2IDpBgE7HSGyLOYeWJX2GHtyxcn+MuQplVZ46PWjP08goFVFbodh06ROFv270DYVd35dpL0wMpgr39FsJS1cNYNhSi6/kXk64YQ0WVnLRz17ZQIBoNxa4t/qmM74QH2tNWGeF/QeK7N8+Tg3lehFHOnXSKjOohtMqAQ9WIp2mI3aQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QpcGkFvRyFdHnDIV8aQW+2Sdjn7ZdrKvUXdmQa2bF6I=;
 b=B6QstF5D7PoQFxjAudqg6+luDm2ait6t9drGILlW+1bbtAvBR6pmIfctMNlfMPIa98KEdSQQA+YXNfGnwqNXvUsYvF8LA55mq+8Xj2E9zKskQf7QN110ongduRDCi/At+n2kVOmfFQg5jA7ibMWeFNwnSILsHWV8qw3kVK9l1vY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <09d25fc1-4482-497e-a91a-24c444a9218b@amd.com>
Date: Tue, 18 Aug 2026 09:18:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] xen/arm: add i.MX8M platform support
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
 <20260818025224.4165503-4-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-4-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|BN3PR12MB9596:EE_
X-MS-Office365-Filtering-Correlation-Id: 71b6b8a6-8ac5-4e41-c145-08defcf8ea3f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|1800799024|23010399003|376014|82310400026|6133799003|10067099003|11063799006|4143699003|18002099003|22082099003|56012099006;
X-Microsoft-Antispam-Message-Info:
	+caQWHt9jjZAUskXRfefnodGMvSrO4lKCngr5vGF51FJfLD06Xg7+gTtLS8lT4Zq1Crw0ZEfpbeeJYbv3JG+sf/lfb424Y2QC2HBy1xMm/bCWRTd2ubl89Xi3IIRsPvqO/qCqx2ohWcCyWCzjIZ6DTob4OCj4C5JVfRcV0Y1Ie8oQWk1yp7rEz5kD2oQ3Eb8IyfWnOk7dyD9C6/ZAbYxQBYLjL1CcPuIsi1Xq9a7lhoRY1GMsinwtVIoHgp6jfWssO1pJiHUUDKL5wkIJ42sQJGBqPx1BeGencAzBOVJZb1G3JaYRMeCzLtjFEcV+L4cSEod0Ry4plkvGt8wVrwMa5EWB3jLHUsce0NSEksjHpGw170pmgSiQQ3mBmPBVhOAFSTlXrL+LfUduoLB/lIfiUSguwQVm7oE2JlCg/Mt9uVOIUe1G8CkKECXGTA1y0jsy6PdVHjdTu1Z3g9ePkxjzpjxAJ0KSN1PJvAQNone5ulXgzWsJRdnHFcp6NxWzfQ15KWb8DtyTXRpQqbmtXP8Smffc91sbb1sPrUv5QO/9rWOkF7B4ckor1NJ8dw6B5x2gDqgqolj5+PkbL+izRFYJqvE33hS9otEABrcx6x4Cqs2RDKoTsq/+WjyI11HhkjOn83DN2mUAibZRWtMCpnGk1eX7CowOzlZVJAy6omp5dmz6sT9XD4wGR7NigHmt/UultTq46kSENVBrNoEbrqSHg==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(23010399003)(376014)(82310400026)(6133799003)(10067099003)(11063799006)(4143699003)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	NvGciwGAZ5z4/Kcy8gWrd/yf2lG3hLMW2skcJZj6Kav+HKwSeR9bR2MkPkbq/3gAIs082VRV5cS6Wx1FL08ucvrdx+Lx1f6mxbyXir4GJ/qF6HLc8sXVTgz87nEWEU2zs6C0/pVSxA2JNPZvYTKbVY/QCRpVD7nILqWigt47JY9AzoGUqz95p5eI8ybyg/oBlWFwDqqTD0YyZD2enXnVnhkD6kaevc1CTp0zLAAKK+cIG3pXVN8VRnH/izldZBinnoJ0X59X/TLJgYjJ1psePgFLAB56K969/xnFzwQuZLdhI7b6jU2yphaZgPSMIObcohT8YREdnbHvRYQT+k4ZRmkMgh2+l05nUH/meyXjQv/KPsJYOT2uvz9a2UuIIPmK+1BsQGizUn1FwacScUJ6kprzrktvaiRzhJSIiU+Cb+0ZZKgTF3rcULGFnsw8mQTQ
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 07:18:34.5025
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 71b6b8a6-8ac5-4e41-c145-08defcf8ea3f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR12MB9596
X-purgate-ID: tlsNG-d25034/1787037520-032D8A5B-3E427AAC/0/0
X-purgate-type: clean
X-purgate-size: 7479



On 18-Aug-26 04:52, Wig Cheng wrote:
> Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).
> 
> When Linux is used as dom0 a number of drivers make SiP SMC calls into
> TF-A to manage hardware: GPC power domains, DDR frequency scaling, SRC
> (M-core remoteproc), SoC info and NoC QoS.  There is no public
> specification for these calls; the function IDs and their subfunctions
> are taken from the vendor kernel call sites.
> 
> Forward only the specific subfunctions the hardware domain issues,
> following the whitelist model of the i.MX8QM platform.  Where a service
> has a fixed set of subfunctions (GPC, SRC, NoC) they are filtered; DDR
> DVFS is left at service level because its reg1 is a frequency setpoint
> rather than a fixed subfunction id, and the SoC info call is a read-only
> query.  CPU frequency scaling is denied because the hardware domain
> cannot make an informed decision, and any unknown function ID is
> rejected.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/platforms/Makefile |   1 +
>  xen/arch/arm/platforms/imx8m.c  | 152 ++++++++++++++++++++++++++++++++
>  2 files changed, 153 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/imx8m.c
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index bec6e55d1f..cdf936c50d 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
>  obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>  obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>  obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
> +obj-$(CONFIG_ALL64_PLAT) += imx8m.o
>  obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
> diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
> new file mode 100644
> index 0000000000..fcf01298d8
> --- /dev/null
> +++ b/xen/arch/arm/platforms/imx8m.c
> @@ -0,0 +1,152 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * i.MX 8M family setup
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/sched.h>
> +#include <asm/platform.h>
> +#include <asm/smccc.h>
You should also include asm/regs.h for `get/set_user_regs()`

> +
> +static const char * const imx8m_dt_compat[] __initconst =
> +{
> +    "fsl,imx8mp",
> +    "fsl,imx8mq",
> +    "fsl,imx8mm",
> +    "fsl,imx8mn",
> +    NULL
> +};
> +
> +#define IMX_SIP_FID(fid) \
> +    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +                       ARM_SMCCC_CONV_64, \
> +                       ARM_SMCCC_OWNER_SIP, \
> +                       (fid))
> +
> +/*
> + * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
> + * public specification for these; the IDs and their subfunctions are
> + * extracted from the vendor kernel call sites (see drivers/soc/imx,
> + * drivers/devfreq, drivers/remoteproc).
> + */
> +#define IMX_SIP_F_GPC       0x0   /* GPC power-domain control */
> +#define IMX_SIP_F_CPUFREQ   0x1
Why no description?

> +#define IMX_SIP_F_DDR_DVFS  0x4   /* DRAM frequency scaling */
> +#define IMX_SIP_F_SRC       0x5   /* SRC: M-core remoteproc start/stop */
> +#define IMX_SIP_F_SOC_INFO  0x6   /* read-only SoC info query */
> +#define IMX_SIP_F_NOC       0x8   /* NoC QoS priority setup */
> +
> +#define IMX_SIP_GPC_SF_PM_DOMAIN    0x03
> +
> +#define IMX_SIP_SRC_SF_M4_START     0x00
This seems to be unused. Why?

> +#define IMX_SIP_SRC_SF_M4_STOP      0x02
> +
> +#define IMX_SIP_NOC_SF_LCDIF        0x00
This seems to be unused. Why?

> +#define IMX_SIP_NOC_SF_PRIORITY     0x01
> +
> +static bool imx8m_smc(struct cpu_user_regs *regs)
> +{
> +    uint32_t function_id = get_user_reg(regs, 0);
> +    uint32_t subfunction_id = get_user_reg(regs, 1);
> +    struct arm_smccc_res res;
> +
> +    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
> +    {
> +        printk_once(XENLOG_WARNING
> +                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
> +
> +        return false;
> +    }
> +
> +    /* Only the hardware domain may use the SiP calls */
> +    if ( !is_hardware_domain(current->domain) )
> +    {
> +        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
> +        return false;
> +    }
> +
> +    /*
> +     * Forward only the subfunctions the dom0 kernel actually issues.  All
> +     * of these manage hardware that belongs to the hardware domain (power
> +     * domains, DRAM controller, M-core, NoC) or are read-only queries.
> +     */
> +    switch ( function_id )
> +    {
> +    case IMX_SIP_FID(IMX_SIP_F_GPC):
> +        if ( subfunction_id != IMX_SIP_GPC_SF_PM_DOMAIN )
> +            goto deny_subfunction;
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_SRC):
Please list the cases in an order (GPC, CPUFREQ ...)

> +        if ( subfunction_id > IMX_SIP_SRC_SF_M4_STOP )
> +            goto deny_subfunction;
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_NOC):
> +        if ( subfunction_id > IMX_SIP_NOC_SF_PRIORITY )
> +            goto deny_subfunction;
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
IMO the stated reason for CPUFREQ applies here as well and we should rather deny
this call. What makes it safe in your opinion to allow this call?

> +        /*
> +         * For DDR DVFS reg1 is a frequency setpoint index (or the
> +         * GET_FREQ_COUNT / GET_FREQ_INFO query), not a fixed subfunction
> +         * id, so it is not filtered here.
> +         */
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_SOC_INFO):
> +        break;
> +
> +    /*
> +     * CPU frequency scaling: the hardware domain does not see the whole
> +     * system and cannot make an informed decision, so deny it (matches
> +     * the i.MX8QM platform).
> +     */
> +    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
> +        return false;
> +
> +    default:
> +        gprintk(XENLOG_WARNING, "imx8m: smc: Unknown function id %x\n",
> +                function_id);
> +        return false;
> +    }
> +
> +    arm_smccc_1_1_smc(function_id,
> +                      subfunction_id,
> +                      get_user_reg(regs, 2),
> +                      get_user_reg(regs, 3),
> +                      get_user_reg(regs, 4),
> +                      get_user_reg(regs, 5),
> +                      get_user_reg(regs, 6),
> +                      get_user_reg(regs, 7),
> +                      &res);
> +
> +    set_user_reg(regs, 0, res.a0);
> +    set_user_reg(regs, 1, res.a1);
> +    set_user_reg(regs, 2, res.a2);
> +    set_user_reg(regs, 3, res.a3);
> +
> +    return true;
> +
> + deny_subfunction:
> +    gprintk(XENLOG_WARNING,
> +            "imx8m: smc: function %x: denied subfunction %x\n",
> +            function_id, subfunction_id);
IMO just return false directly on deny, no need for goto and printk, given that
Xen will also print Unhandled SMC/HVC from `vsmccc_handle_call()`.

> +    return false;
> +}
> +
> +PLATFORM_START(imx8m, "i.MX 8M")
> +    .compatible = imx8m_dt_compat,
> +    .smc = imx8m_smc,
> +PLATFORM_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:19:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:19:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393523.1632342 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE6g-0002Px-HT; Tue, 18 Aug 2026 07:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393523.1632342; Tue, 18 Aug 2026 07:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE6g-0002Pq-Ea; Tue, 18 Aug 2026 07:19:34 +0000
Received: by outflank-mailman (input) for mailman id 1393523;
 Tue, 18 Aug 2026 07:19:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwE6f-0002Pc-ML
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:19:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE6f-00EBKC-33
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:19:33 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840772-8faa-0a2a0a5109dd-0a2a45059c0a-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:19:32 +0200
Received: from [52.101.57.65]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840783-4cb1-0a2a45050019-346539412227-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:19:32 +0200
Received: from CH0PR03CA0241.namprd03.prod.outlook.com (2603:10b6:610:e5::6)
 by CYYPR12MB8702.namprd12.prod.outlook.com (2603:10b6:930:c8::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 07:19:26 +0000
Received: from CH3PEPF0000000A.namprd04.prod.outlook.com
 (2603:10b6:610:e5:cafe::86) by CH0PR03CA0241.outlook.office365.com
 (2603:10b6:610:e5::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 07:19:26 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH3PEPF0000000A.mail.protection.outlook.com (10.167.244.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 07:19:26 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:19:25 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 02:19:24 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TutpTAnYnGAsnHKdI49DyZio7gHiov0RJMxqY8U4guIGQynuoMW5TDJGcxFXqpFP5qj2O3bOfbCQOgM2+SLJ1/YOwFWY3rnGsY1ATWsVbEq/ciR4AjTQorIVCek7Dj1EeAQ3NJxt//AXfxbi9NmKQUwH7l+hN8LgkEpiL5puU4eQTz1TEHQgQpfWjk5TgG8WI/PAcX15z+g50eWzI0ZneU4IS1Yb9ANP2e1NrKlzq+ZBgrp87M/BIs4GC3I5+UwoU8rMdo8BP0qjlAhg8s5I85hkgTz7n3f14/FHZHtTz4yrRLA206sejW5kZGl7MhmuEDf0lSp7bKNJGCjj5AXelw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9P0gGPgWpneLVxUs1PK1OcKo3ZL9EA+X6hbK2ABu/ow=;
 b=WKAgA8qJCC2aIPEMHQtIcBoqto2ZNfXSxQz5uc8NzX53+BEmNCpYrFp0r62wb8iCefv7b/68cZjQnSHzrJTa9bNGF+59Avti0IrrnacHX1XbJYI+gI42NEdjMMwpBkG3jUK7n7WDDhixGCIRVR30DlLM5Foq6q2OtBWqA5R/OT8uHYFC8MzGwxjdaTOUMTwVdgSK4luFTmCWf+eSU4Or1ED2DM3FW9KLenA4J39fsIpxiS4BPLTiGrgIH/mDKcEJAr2Ejyp4qp2R85pIsg7HZzG8dZFD9iFAAbbqZqB/SeZHdA/eVgsTapIrJHs8v9ATHFUCOF+sJQLS2/Igs5b3gw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9P0gGPgWpneLVxUs1PK1OcKo3ZL9EA+X6hbK2ABu/ow=;
 b=GCACG8GQFZBfGJ9f0wRoi9h+5GlC7pyfpAKuoc0lPgEs9XXtZBCgBLqOWdarB45+yoegQ9eAewMgKGXI4KAyHXsL69cWtyxWIu8xAIIrUp5sUWpHdpICSUbkI83OpJRO0Jv8DFC3KYEf9PsAHU3M867D1J0zyGaGW8lh9dJvPC8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <6351248a-e923-4e76-adb1-596224417f7e@amd.com>
Date: Tue, 18 Aug 2026 09:19:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/4] MAINTAINERS: add myself as reviewer of i.MX8M
 related patches
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
 <20260818025224.4165503-5-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-5-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000A:EE_|CYYPR12MB8702:EE_
X-MS-Office365-Filtering-Correlation-Id: 2406e876-0da5-4c89-de44-08defcf90909
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|23010399003|36860700016|1800799024|56012099006|10067099003|4143699003|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	J0c7njDboY9GW+Pq3PVyc4IUEjHo7C5Sw0FtGaNzIKdNeZouHIYuCjVb8QkJjrgFz5UbWY1GhQtY6DY4LMlA2vP1P3Jltp6s4OWp49mEw1F0l+cDq0sbUeLsgEXW9a5iqzH7FfvQvx8v+dmFOeFOPNhY6qEILaffLfi2kpZja+jZ9rdIQIy3QYguwgAGLxXkWl33nhLtuz3jwkDRwNnv77AKGYOyL0zA4oTZHemDSvl+o3DAxf1noJbL/Ts1THeN1sQLfO9stVUV5u4ezL9pgix7KaslwjlhYpbY6oRQ9oWNz/vIWFwEy1EbzsMz4i08KbCUOFIhWHRVHwvZZvlkH8vMIzvzycEbolVRUhJlhO7Fy9TkJHHjbvTXWTqoR8M+p4i0HqDV9eJrG8+HYJ8U0iIFGTOuiCzaIG2NBbkWhqj1mauteJybO9Cy/Y2KRr6X+qjSn1VoUwqw2JNN8cy2yW0x/kePovi7QrX1DLE6Xc4koZYR41onHwbdrqKFYveVIk8EkSlXpJqrrPX4TaFKwe+k4JCnal1ZK/9MppmYHOeJbRP07tRtRSRgaUqIJJxZG+81/tSLVOqfQAuMMty2zvQVc5YoSAY8eg86oEw0MlQ8q8Z+EhY3QP+tuBpycymIxp0ovZ/wtvFM0r1gW0zWVpQJvHoTOIkOecWsu4M5g3PCvbcMTeZb1sY73IwdekJvdR3omcdsGzt2ZtMPYOh1Ug==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(23010399003)(36860700016)(1800799024)(56012099006)(10067099003)(4143699003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	BnMappz3JoMfRPfd0H3WZNb5+GbBEBLT+qWSz4sQSsFTOEeBWO/UYvHsqRMGkrgRqGZ3PiiP9zrs0Cn0oqXikPP1BNHCH1gcM1o+Q6LMizyLjVUNi59/m0Bv4SwHEFiUqbMZsIni3pUzO9K923lOhh9YFvdsAMnKfne0n6/IKqQBNjuxsnMgR3yc2Le/mI4KXsEWjxjcurL/PuQXcsx75/yi2AqO0wNel8gW19H/P0tm63k5gl+bdrN6f9ywfC+ewvF7wzUKAOvDmvnuOL69Fox5PvOlYZZzb0Qcw7Y7ool5mPXRMNhTDWIG8HEdclzdgy1VrkS+rhj2BItc99MT9s6LTxrA5Jqb4bCYuXC3kKV4NSxDnjepfrw3W5VLqO/d5l1s2pYg7h4DoIijFNblQShpndjKA3CbhSqzVSYux7MUPPfpoGGUVNJGY1bVhBJ5
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 07:19:26.1575
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2406e876-0da5-4c89-de44-08defcf90909
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8702
X-purgate-ID: tlsNG-c201ff/1787037572-24D1E2A1-D6589C2B/0/0
X-purgate-type: clean
X-purgate-size: 258



On 18-Aug-26 04:52, Wig Cheng wrote:
> I wrote the i.MX8M platform and UART support and can help review
> patches touching these areas.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:21:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:21:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393532.1632352 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE8L-0003y2-Rx; Tue, 18 Aug 2026 07:21:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393532.1632352; Tue, 18 Aug 2026 07:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE8L-0003xv-OQ; Tue, 18 Aug 2026 07:21:17 +0000
Received: by outflank-mailman (input) for mailman id 1393532;
 Tue, 18 Aug 2026 07:21:16 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwE8K-0003xn-MH
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:21:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE8K-005p6h-2n
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:21:16 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8407e8-2eae-0a2a0a5409dd-0a2a450c81e2-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:21:15 +0200
Received: from [52.101.56.2]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8407ea-f479-0a2a450c0019-34653802f479-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:21:15 +0200
Received: from BYAPR21CA0003.namprd21.prod.outlook.com (2603:10b6:a03:114::13)
 by SJ0PR12MB7474.namprd12.prod.outlook.com (2603:10b6:a03:48d::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 07:21:10 +0000
Received: from SJ5PEPF00000205.namprd05.prod.outlook.com
 (2603:10b6:a03:114:cafe::34) by BYAPR21CA0003.outlook.office365.com
 (2603:10b6:a03:114::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.0 via Frontend Transport; Tue, 18
 Aug 2026 07:21:10 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ5PEPF00000205.mail.protection.outlook.com (10.167.244.38) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 07:21:10 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:13:33 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 02:13:32 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Kw96ApVzONTO671Id+xEGKBifjG7Tc7P+Jf+m57NUe68vXILIFmZCzomaN1eGCDkorm5UwhEO3170JZofSl8cU1efob4/hD9ybGyF3s65XNeejP1qCtc9ci3tnwVyXWUevgXlTdHP97TpDTwUZ1xutyyP/hhib+QnJBPhBrn4GA1+aZP7PNjSoWZUX7Q/VlhbdUE/snuo5zWzcls/DAbDDjDRB9UPwwDZl3NlAHspbzlT5FWdtRReUiTO/8hh7sRp7jbbPkf+7Y2LyDROA1468WiuyVarqShkyHI7SBYEZxFaQvuDtSu7E7KNLKK/IIyyWmCTAx7PCALFu3hqT7FuA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2VKtktAghtvAyfShnMl7Gov2iTCHFu/RnL+YdTnPlnU=;
 b=Mg/ivKU+nqV7Gg7A86W1Q7TcaWTu9EpFlJFvyECB26UwLBvJKGTuejzhLHCoSRgS31JW6eeZFStrUJOk6U+tRMi1DEvPAOseVPeNB0WyxB6++mMBHPpu3YRf/9nuIVnGbII26LAeKZffkrsfCvyaFEE4F9jj9W4Y/6NuwZbzHUWCMaKaF4AS9spzmVnI/0EoKPs8C+YttmrhjM85VdFkMsu9lo0Px1IAWRIHJSxXpEOHL5+QTBhTLQ4xZ8fdafZYEmX2d6EX2w7gGNBPZUkRY+ogDjNBjn3XZn7An+Arafi9Xxou4bPJGocz/60Vm4ckNGmpZ1f/iTV0xywq+MbUKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2VKtktAghtvAyfShnMl7Gov2iTCHFu/RnL+YdTnPlnU=;
 b=ZjGMpiO3L39QWBjbj/zAOCtfs1SH6WQ2as2WzbnrWSlkV9/0uuL+mlHzu1otypBrqRk4FHMLs5ntNXhmueROq9wLf1dVHfkdG8Gg/9dulb80AaHsfAlLVIm9/+WHnJGavhRZzsGiLKu+OqSeFmZHVVvpKBIsdVLdXgeshn3GMRA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <f8f4389b-975a-46e9-bb07-3d347b4d30e3@amd.com>
Date: Tue, 18 Aug 2026 09:13:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen/char: add classic i.MX UART driver
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
 <20260818025224.4165503-2-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-2-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF00000205:EE_|SJ0PR12MB7474:EE_
X-MS-Office365-Filtering-Correlation-Id: 5acf8983-8bda-4161-c6c3-08defcf94717
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|23010399003|376014|82310400026|1800799024|10067099003|56012099006|6133799003|18002099003|22082099003|4143699003|11063799006;
X-Microsoft-Antispam-Message-Info:
	9C2g9/r3PdMY0K0jF6AeDXwXAa8/wbWMWYsLVohFznr+9Mk0eaW/Sjz5+Yav/B8d74OI4wN9G/hVA5fHRKnzutJwXVHONJNzCv3y7fTgNVxKhoympWExFp5DyRSXwAToGKzkraKvtIFundOB31nSR4uAfM77hDh8EZKGYZTBe1nJlnYGRRvISD/RVvCTJj17Y6mPbL9DAQEePU2CcC69PGZ05GVe/MVqKCteDOX/mXAQVZ2cvSXG84CzJMwgBpPL5GMe5eakmz6a/Yubr8rfhmZDd9dKoR1KFUi2+4KU8yqRPCEGDo9LxKKWVOZcdVs+rtCmq8l/+m7VfJ8DGmAcfPka9F1YeMBmnqOVp9lmmdmSZMwEQ59DuksNXeORcALUh9VjKBL/VOtzkmy3zlk9b5MbFJsEpL5AsJ4aKZSVlD96yRLFaqXdC7gD+M6y2LOxh0oSX+OOtaqUhkGl+ngBXWki3zzzSLFAlfZrSqtTgJI0eCXMIgyD4A9iAA51hLYavqb2hX/KDr1qsLjVY59fGNA4R/dKI0K9pnlvqKLXx8piqDwfKBVcf6VgqLYtuEZbUCcijq0NByLn5b+aGhHqflBJXD6vWKyVgi8bo2kW0awHkMtkSJkbu2MtWwJcSceYvjKNnZECyEPFPZj2npwTu34muhzJLrPu6AN2IgE8+7z8S5lmhrPBwXFQb5n5uFLidF29yObaRlzz2S0p8I9PxA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(376014)(82310400026)(1800799024)(10067099003)(56012099006)(6133799003)(18002099003)(22082099003)(4143699003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	buPFfLZsT8NvQh/QnoTaFjdcRuA/RgzPeYQxE3NMDBkxL7e8XPccF7YCjv9BU7sbwqU4AxNRdZdhAwbryzbGjpjozXYLJk5l96dSHcr5T0MA/x5X6dCfzUK84iiXAmjRHkveNm0ucTud9lXcNUmJ6nRvaQErzqWkoNQIOx/bmW8CfDvG2OxB2G0gWzOVLLpYWyvORcrxN5etlkH7opwbtPolBoRLqwwOo/h0M1SJhdJ/DQ0sG0tgg30ufLR3Qdkgq3B/dKN4lDVpzrD45crvSvbG6E8OPGEblB0nQG4FdInwZupUKgf/wdIsfnNVZkdVqPHP4/gJSOcyaInjqmE+sYSFKSs5vyznmXtFkxIPVXFO6hmVvIeCXWI9RSywObF0WoSHPLufcKOwztAvXepC0Pdoy/n0+br9zLsrB9wselPl+Drqs70xGx0D7c/a37G+
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 07:21:10.1122
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5acf8983-8bda-4161-c6c3-08defcf94717
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF00000205.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7474
X-purgate-ID: tlsNG-d25034/1787037675-772D8A5B-AC374120/0/0
X-purgate-type: clean
X-purgate-size: 7568



On 18-Aug-26 04:52, Wig Cheng wrote:
> Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
> compatible), used as the console UART on the i.MX8M family.  Baudrate
> and pin configuration are inherited from the bootloader; the driver
> only enables the transmitter/receiver and wires up the RX/TX
> interrupts, mirroring the existing imx-lpuart driver.
> 
> The i.MX8M family's UART IP differs from the LPUART used on
> i.MX8QM/8QXP, so a separate driver is needed.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/include/asm/imx-uart.h |  57 +++++++
>  xen/drivers/char/Kconfig            |   8 +
>  xen/drivers/char/Makefile           |   1 +
>  xen/drivers/char/imx-uart.c         | 226 ++++++++++++++++++++++++++++
You should add an entry to the MAINTAINERS file for imx-uart.c so that it falls
down under ARM maintainership. Your last patch makes you a reviewer but we still
need to be maintainers of it. See how it was done for IMX8QM.

>  4 files changed, 292 insertions(+)
>  create mode 100644 xen/arch/arm/include/asm/imx-uart.h
>  create mode 100644 xen/drivers/char/imx-uart.c
> 
> diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
> new file mode 100644
> index 0000000000..a3892020e6
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/imx-uart.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Register definitions for the classic i.MX UART IP
> + * ("fsl,imx6q-uart" compatible), used as the console UART on the
> + * i.MX8M family.
> + *
> + * Register layout taken from Linux drivers/tty/serial/imx.c.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#ifndef ASM_IMX_UART_H
> +#define ASM_IMX_UART_H
> +
> +#include <xen/const.h>
> +
> +#define URXD0           0x00   /* Receiver Register */
> +#define URTX0           0x40   /* Transmitter Register */
> +#define UCR1            0x80   /* Control Register 1 */
> +#define UCR2            0x84   /* Control Register 2 */
> +#define USR1            0x94   /* Status Register 1 */
> +#define USR2            0x98   /* Status Register 2 */
> +#define UTS             0xb4   /* Test Register */
> +
> +#define URXD_RX_DATA    0xff
> +
> +#define UCR1_UARTEN     BIT(0, U)   /* UART enable */
> +#define UCR1_ATDMAEN    BIT(2, U)   /* Aging DMA timer enable */
> +#define UCR1_TXDMAEN    BIT(3, U)   /* Transmitter ready DMA enable */
> +#define UCR1_TXMPTYEN   BIT(6, U)   /* Transmitter empty interrupt enable */
> +#define UCR1_RXDMAEN    BIT(8, U)   /* Receiver ready DMA enable */
> +#define UCR1_RRDYEN     BIT(9, U)   /* Receiver ready interrupt enable */
> +#define UCR1_TRDYEN     BIT(13, U)  /* Transmitter ready interrupt enable */
> +
> +#define UCR2_SRST       BIT(0, U)   /* 0 = issue software reset */
> +#define UCR2_RXEN       BIT(1, U)   /* Receiver enable */
> +#define UCR2_TXEN       BIT(2, U)   /* Transmitter enable */
> +
> +#define USR1_TRDY       BIT(13, U)  /* Transmitter ready */
> +
> +#define USR2_RDR        BIT(0, U)   /* Receive data ready */
> +#define USR2_ORE        BIT(1, U)   /* Overrun error */
> +
> +#define UTS_TXFULL      BIT(4, U)   /* TX FIFO full */
> +#define UTS_RXEMPTY     BIT(5, U)   /* RX FIFO empty */
> +#define UTS_TXEMPTY     BIT(6, U)   /* TX FIFO empty */
> +
> +#endif /* ASM_IMX_UART_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index 8e49a52c73..f237c0220d 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -30,6 +30,14 @@ config HAS_IMX_LPUART
>  	help
>  	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
>  
> +config HAS_IMX_UART
> +	bool "i.MX UART driver"
> +	default y
> +	depends on ARM_64
> +	help
> +	  This selects the classic i.MX UART. If you have an i.MX8M family
> +	  based board, say Y.
> +
>  config HAS_MVEBU
>  	bool "Marvell MVEBU UART driver"
>  	default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 8cbbffdca8..039f566926 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
>  obj-$(CONFIG_XHCI) += xhci-dbc.o
>  obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
> +obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
>  obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
>  obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
> new file mode 100644
> index 0000000000..fd34b0cd11
> --- /dev/null
> +++ b/xen/drivers/char/imx-uart.c
> @@ -0,0 +1,226 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), used as the
> + * console UART on the i.MX8M family (e.g. i.MX8MP).
> + *
> + * Baudrate and pin configuration are inherited from the bootloader.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/irq.h>
> +#include <xen/mm.h>
> +#include <xen/serial.h>
> +#include <asm/device.h>
> +#include <asm/imx-uart.h>
> +#include <asm/io.h>
> +
> +#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
> +#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
> +
> +static struct imx_uart {
> +    uint32_t irq;
> +    char __iomem *regs;
> +    struct irqaction irqaction;
> +    struct vuart_info vuart;
> +} imx8m_com;
> +
> +static void imx_uart_interrupt(int irq, void *data)
> +{
> +    struct serial_port *port = data;
> +    struct imx_uart *uart = port->uart;
> +
> +    if ( imx_uart_read(uart, USR2) & USR2_RDR )
> +        serial_rx_interrupt(port);
> +
> +    if ( imx_uart_read(uart, USR1) & USR1_TRDY )
Looking at Linux's imx.c you should clear TRDY if TRDEN is not enabled to
prevent RX interrupt entering serial_tx_interrupt as TRDY is a raw status register.

> +        serial_tx_interrupt(port);
> +}
> +
> +static void __init imx_uart_init_preirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1, ucr2;
> +
> +    /*
> +     * Reuse the bootloader settings; only enable the UART and both
> +     * directions.  The console uses UCR1 interrupts (RRDYEN/TRDYEN)
> +     * exclusively, so just clear UCR1's interrupt and DMA enables.
> +     */
> +    ucr1 = imx_uart_read(uart, UCR1);
> +    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_TXMPTYEN | UCR1_RXDMAEN |
> +              UCR1_TXDMAEN | UCR1_ATDMAEN);
> +    ucr1 |= UCR1_UARTEN;
> +    imx_uart_write(uart, UCR1, ucr1);
> +
> +    ucr2 = imx_uart_read(uart, UCR2);
> +    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
> +    imx_uart_write(uart, UCR2, ucr2);
> +}
> +
> +static void __init imx_uart_init_postirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1;
> +
> +    uart->irqaction.handler = imx_uart_interrupt;
> +    uart->irqaction.name = "imx_uart";
> +    uart->irqaction.dev_id = port;
> +
> +    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
> +    {
> +        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %d\n", uart->irq);
uart->irq is unsigned, so s/%d/%u.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:22:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:22:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393539.1632360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE9o-0004So-4Z; Tue, 18 Aug 2026 07:22:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393539.1632360; Tue, 18 Aug 2026 07:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwE9o-0004Sh-1l; Tue, 18 Aug 2026 07:22:48 +0000
Received: by outflank-mailman (input) for mailman id 1393539;
 Tue, 18 Aug 2026 07:22:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwE9n-0004Sb-AT
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:22:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwE9m-00EC46-NY
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:22:46 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840838-bab6-0a2a0a5309dd-0a2a45078428-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:22:46 +0200
Received: from [40.93.195.26]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a840844-b4ea-0a2a45070019-285dc31a88ac-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:22:46 +0200
Received: from SJ0PR05CA0067.namprd05.prod.outlook.com (2603:10b6:a03:332::12)
 by LV0PR12MB999068.namprd12.prod.outlook.com (2603:10b6:408:32d::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 07:22:39 +0000
Received: from SJ5PEPF00000204.namprd05.prod.outlook.com
 (2603:10b6:a03:332:cafe::2b) by SJ0PR05CA0067.outlook.office365.com
 (2603:10b6:a03:332::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 07:22:39 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 SJ5PEPF00000204.mail.protection.outlook.com (10.167.244.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 07:22:39 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:22:34 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 02:06:39 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 02:06:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F8VAH8b78BACGFFuGUl3yTzNZYpNGJc0se3Dw5/rMM/Y34LbGQNE8oTpX0AtRXLrA46xdGGvYRlWYWppsFq3UB1zLAZKHBbzm2M7U8MY8kahk062wdMIQPiYuZzCeiQ9fWPRZgfG+fq7A25fLEpi1s4qnOemrOmO4miMvCvH8TqfWXGDh38IawJOQGJ97dbLYDBEWYfto1MWNK46jYA/aPXGYSxKLOvTbtBBFq56m+DJZGgneuUzaq1OTM+JW4FyE5Xs/YsojCk64quLHmKzOZA/HbOhW6HHVpXO8ksnyRyWQr/udt1r/Kfrx+Ndnw7kHpleGXVsMSGdRQi297Yctg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2VKtktAghtvAyfShnMl7Gov2iTCHFu/RnL+YdTnPlnU=;
 b=r+vPhsp75d0EgAc2k1liItec8V8BRrVx23rZSxKclPVAfH2ZMxKQnc4ies2V9ACjDYT9xN1Wl2nU68dawLBgcaXbxFOPJe7z9evqNCcvNmj+gIRSGWjCh/Viwoq6X11BrUq7hBBaLYs2wVwJMV1TDyHEWBsB2LjCMIRawIp6v0Zse+SCf/oT2Lf6CgF6YRlwOBsG89TrCpBOdy0ZLgUGv+yx3M+daPIgVVFUB5VT7RDDCIxdHtzytz2lIW/4MnmT2KtQlRzISRylEiw8BSaD3xuRfRxiDo9DOFmY3YhR9mOkVw6abSML9pFCoorYEJOxW7taTFblcN9r9PF7nNhwPw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2VKtktAghtvAyfShnMl7Gov2iTCHFu/RnL+YdTnPlnU=;
 b=f6kKi52jlJGQ9EsIJ2Dm4AmwieGvkMg+cTfwpeW7bdwFbXjLQnmubB7fjSnR42igE4m66G0ke/Z4qNLgRf6RPBMhkalm2fqZlMV6MKTgQRQZ/HYVA6FVJdGQSjp0ZYWlLZC93lr5Na/r2ueu/mA/Q/bJHtOmK8EXbN/vQVZ7/78=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <9acefe1c-5325-4de3-9dbc-d8c4adf4182c@amd.com>
Date: Tue, 18 Aug 2026 09:06:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] xen/char: add classic i.MX UART driver
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818025224.4165503-1-onlywig@gmail.com>
 <20260818025224.4165503-2-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818025224.4165503-2-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF00000204:EE_|LV0PR12MB999068:EE_
X-MS-Office365-Filtering-Correlation-Id: f3d7d243-f8f0-47eb-a926-08defcf97c2f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|23010399003|376014|1800799024|36860700016|6133799003|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	Px64mKvGFRhrl4JmiOJ11LcNWDToFm91xjOOEYG24GujsrnuuZb6NoKGYgQMj7bShuZBU3TYWmNkvD7047xXWCojzh4HP9gOiaOKGf2Uxo6+FopIpYKJdfXdw8BoaU9Ge4okASVy95twRb2XzUNhlW8fjNEQEX6w196QRE0JhC6Oh2mNdsJfjHlNolz6yNmre6HbmVLUFRVnhSno9u2X7+BJ5yfJeTSfDcvY3VcH2sGEMkrjH8CtHmNGD5EwaVT7r0uvsTKIHTEnYc5bUKV8l6eeJLi6XjFYp9igKoMEBp1gU43JWy0DjZJkDWLrTwzQkU1nUYH97befxwPe81KR8GNbbjsLj2aZryIlHw/lMH3Osk2AG8DHrRVPRwKnOIhBRCbC1u5SVmpgTVBaoni4JVB9YwqRWCZIZE3TuKGLrtPDRXyCgc5ky7dWErZZ7pmxuHouaZV16U98cV2+Ov0wKna7FIShjyRbonoahrwl9jQ4k5UL2nHr2UanD7kaJ3ox1C7Cb5cSNV6vxYYLOIV5epwXt49tmVb6PEgDX26ZN9XHK7jdgifJ0PZsdf/1yh3NlV+E6JjY5IT0Br0BnDiRB3mjg0Y/WNGN003tn5FTfRRLjrC0/Yxzg9AOpPuWmFHakD8EnU5i+cKt0AyeiHBDSZeF+uYkDBdmhRiJtIArIDyrFndIzcf/TmXh6yXjK6EVAfG3efGrqTmhH8rND9BREQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(23010399003)(376014)(1800799024)(36860700016)(6133799003)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	ti4q8gxE/8TjlyvILGY+Sz+4BpYhgdOe2tTP2z3O5zSzM1rqTDxA4dh35Yff5p5wjqg5RWxnFgo3LqSsOS+VZWjEOdsD4RNPg/4QtatEoOgXv/rKYIfMNtj79p1RUG9LxcVWF33l4zr7lgGNbp/nbMVnKNFhiuvk4c1jej0F7smI9A9g/ejomyeFBtShTJYcRf6K3SnsU67Q6M3KUI4UknvU7qiFb1UNf6JPROPrHhAPeE8tO/jH6F9ukju2djnMPaGFh+0gwK4hGr9MXgufhCos9DdM9IUwJGVD8ZmWcW6ftPvRml48LKPI/cwNod9DLrMrd94XRWTHQxoRAazciyo/G8sHZcWNfvziD7hblAzqWW6HDjqfyfsuZDlUM8MgOYAdKw4KvxizejrYHayxF2dmHbKrgEwFUokd3klwGCCsHNY+hsfi+8gOMdkDWzCL
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 07:22:39.2398
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f3d7d243-f8f0-47eb-a926-08defcf97c2f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF00000204.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV0PR12MB999068
X-purgate-ID: tlsNG-ef75cf/1787037766-360C5AE4-D2FBA5FF/0/0
X-purgate-type: clean
X-purgate-size: 7568



On 18-Aug-26 04:52, Wig Cheng wrote:
> Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
> compatible), used as the console UART on the i.MX8M family.  Baudrate
> and pin configuration are inherited from the bootloader; the driver
> only enables the transmitter/receiver and wires up the RX/TX
> interrupts, mirroring the existing imx-lpuart driver.
> 
> The i.MX8M family's UART IP differs from the LPUART used on
> i.MX8QM/8QXP, so a separate driver is needed.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
>  xen/arch/arm/include/asm/imx-uart.h |  57 +++++++
>  xen/drivers/char/Kconfig            |   8 +
>  xen/drivers/char/Makefile           |   1 +
>  xen/drivers/char/imx-uart.c         | 226 ++++++++++++++++++++++++++++
You should add an entry to the MAINTAINERS file for imx-uart.c so that it falls
down under ARM maintainership. Your last patch makes you a reviewer but we still
need to be maintainers of it. See how it was done for IMX8QM.

>  4 files changed, 292 insertions(+)
>  create mode 100644 xen/arch/arm/include/asm/imx-uart.h
>  create mode 100644 xen/drivers/char/imx-uart.c
> 
> diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
> new file mode 100644
> index 0000000000..a3892020e6
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/imx-uart.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Register definitions for the classic i.MX UART IP
> + * ("fsl,imx6q-uart" compatible), used as the console UART on the
> + * i.MX8M family.
> + *
> + * Register layout taken from Linux drivers/tty/serial/imx.c.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#ifndef ASM_IMX_UART_H
> +#define ASM_IMX_UART_H
> +
> +#include <xen/const.h>
> +
> +#define URXD0           0x00   /* Receiver Register */
> +#define URTX0           0x40   /* Transmitter Register */
> +#define UCR1            0x80   /* Control Register 1 */
> +#define UCR2            0x84   /* Control Register 2 */
> +#define USR1            0x94   /* Status Register 1 */
> +#define USR2            0x98   /* Status Register 2 */
> +#define UTS             0xb4   /* Test Register */
> +
> +#define URXD_RX_DATA    0xff
> +
> +#define UCR1_UARTEN     BIT(0, U)   /* UART enable */
> +#define UCR1_ATDMAEN    BIT(2, U)   /* Aging DMA timer enable */
> +#define UCR1_TXDMAEN    BIT(3, U)   /* Transmitter ready DMA enable */
> +#define UCR1_TXMPTYEN   BIT(6, U)   /* Transmitter empty interrupt enable */
> +#define UCR1_RXDMAEN    BIT(8, U)   /* Receiver ready DMA enable */
> +#define UCR1_RRDYEN     BIT(9, U)   /* Receiver ready interrupt enable */
> +#define UCR1_TRDYEN     BIT(13, U)  /* Transmitter ready interrupt enable */
> +
> +#define UCR2_SRST       BIT(0, U)   /* 0 = issue software reset */
> +#define UCR2_RXEN       BIT(1, U)   /* Receiver enable */
> +#define UCR2_TXEN       BIT(2, U)   /* Transmitter enable */
> +
> +#define USR1_TRDY       BIT(13, U)  /* Transmitter ready */
> +
> +#define USR2_RDR        BIT(0, U)   /* Receive data ready */
> +#define USR2_ORE        BIT(1, U)   /* Overrun error */
> +
> +#define UTS_TXFULL      BIT(4, U)   /* TX FIFO full */
> +#define UTS_RXEMPTY     BIT(5, U)   /* RX FIFO empty */
> +#define UTS_TXEMPTY     BIT(6, U)   /* TX FIFO empty */
> +
> +#endif /* ASM_IMX_UART_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index 8e49a52c73..f237c0220d 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -30,6 +30,14 @@ config HAS_IMX_LPUART
>  	help
>  	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
>  
> +config HAS_IMX_UART
> +	bool "i.MX UART driver"
> +	default y
> +	depends on ARM_64
> +	help
> +	  This selects the classic i.MX UART. If you have an i.MX8M family
> +	  based board, say Y.
> +
>  config HAS_MVEBU
>  	bool "Marvell MVEBU UART driver"
>  	default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 8cbbffdca8..039f566926 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
>  obj-$(CONFIG_XHCI) += xhci-dbc.o
>  obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
> +obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
>  obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
>  obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
> new file mode 100644
> index 0000000000..fd34b0cd11
> --- /dev/null
> +++ b/xen/drivers/char/imx-uart.c
> @@ -0,0 +1,226 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), used as the
> + * console UART on the i.MX8M family (e.g. i.MX8MP).
> + *
> + * Baudrate and pin configuration are inherited from the bootloader.
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/irq.h>
> +#include <xen/mm.h>
> +#include <xen/serial.h>
> +#include <asm/device.h>
> +#include <asm/imx-uart.h>
> +#include <asm/io.h>
> +
> +#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
> +#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
> +
> +static struct imx_uart {
> +    uint32_t irq;
> +    char __iomem *regs;
> +    struct irqaction irqaction;
> +    struct vuart_info vuart;
> +} imx8m_com;
> +
> +static void imx_uart_interrupt(int irq, void *data)
> +{
> +    struct serial_port *port = data;
> +    struct imx_uart *uart = port->uart;
> +
> +    if ( imx_uart_read(uart, USR2) & USR2_RDR )
> +        serial_rx_interrupt(port);
> +
> +    if ( imx_uart_read(uart, USR1) & USR1_TRDY )
Looking at Linux's imx.c you should clear TRDY if TRDEN is not enabled to
prevent RX interrupt entering serial_tx_interrupt as TRDY is a raw status register.

> +        serial_tx_interrupt(port);
> +}
> +
> +static void __init imx_uart_init_preirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1, ucr2;
> +
> +    /*
> +     * Reuse the bootloader settings; only enable the UART and both
> +     * directions.  The console uses UCR1 interrupts (RRDYEN/TRDYEN)
> +     * exclusively, so just clear UCR1's interrupt and DMA enables.
> +     */
> +    ucr1 = imx_uart_read(uart, UCR1);
> +    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_TXMPTYEN | UCR1_RXDMAEN |
> +              UCR1_TXDMAEN | UCR1_ATDMAEN);
> +    ucr1 |= UCR1_UARTEN;
> +    imx_uart_write(uart, UCR1, ucr1);
> +
> +    ucr2 = imx_uart_read(uart, UCR2);
> +    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
> +    imx_uart_write(uart, UCR2, ucr2);
> +}
> +
> +static void __init imx_uart_init_postirq(struct serial_port *port)
> +{
> +    struct imx_uart *uart = port->uart;
> +    uint32_t ucr1;
> +
> +    uart->irqaction.handler = imx_uart_interrupt;
> +    uart->irqaction.name = "imx_uart";
> +    uart->irqaction.dev_id = port;
> +
> +    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
> +    {
> +        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %d\n", uart->irq);
uart->irq is unsigned, so s/%d/%u.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:24:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:24:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393549.1632368 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEB0-0004zi-HO; Tue, 18 Aug 2026 07:24:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393549.1632368; Tue, 18 Aug 2026 07:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEB0-0004zb-ED; Tue, 18 Aug 2026 07:24:02 +0000
Received: by outflank-mailman (input) for mailman id 1393549;
 Tue, 18 Aug 2026 07:24:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwEAz-0004zV-Cn
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:24:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEAy-001ht8-Pf
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:24:00 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a84088b-2eae-0a2a0a5409dd-0a2a450688fc-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:24:00 +0200
Received: from [209.85.208.53] (helo=mail-ed1-f53.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a840890-195a-0a2a45060019-d155d035e11d-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:24:00 +0200
Received: by mail-ed1-f53.google.com with SMTP id
 4fb4d7f45d1cf-6a157f90752so6246682a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:24:00 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a3d85319b1sm1607716a12.13.2026.08.18.00.23.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:23:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787037840; x=1787642640; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=v6Ect+BVV2rp46H08828Mnkf1AjJmDKjQgbbV67/FTI=;
        b=Ut9LaYxfh03YDcbtaJTiSubF1Todv+n6fgsh3J/5o1lcq1PBDBqd89w0gP5EA077z5
         Dm9iPwvE28B8JtD4QZFlmcQnPqQEWidCDBhb39QsOGlB3zvEvSFhJuhoV/pj6MB6zKop
         CsdKThK3lgxKGr8f2WizQ1IcWUEytOqU/hWgAkknyDVdmpFSs29thNpTlpet8Sh+5CZV
         m94Uf8ke0KrTiRYmALmuvUQ12KPJ3pQqD7FkLMxTjA4McUGE2yuS5qINvFwxj6RWLbCs
         MPuwZxPGpGxQo1SwaU5DOjvv9yw5Itfj3Le18g+HiRjmpOTlB/G97Sl+SPzVcNn//5t1
         0ocQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787037840; x=1787642640;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=v6Ect+BVV2rp46H08828Mnkf1AjJmDKjQgbbV67/FTI=;
        b=IbBhNubSAI3Rgn603NnJ+ByOnH0isbqGdu9rKSBNhR9pi2iCyEbCqqFhBVJrsau24P
         xsJLbZKS/m22E+wbm9cYzqcJnFFgI+Z+6aFQsqvjc7MQvSeG6uI3OiNeFH9adEVbiDq9
         MUJgacqU95wiHE8N9fmsAVcUY9PgxnzblIGSKr90r+cZu7gQ/hzA0JDIzNAXvDJi8d6F
         1SV0mHd6tetDYJ3BEFyZ5KP5DnxX3b13PcycyDOOfrZuagB4jGz+aFCsNNYZlr8etABJ
         95z2y75dSkhurn1y3iuYrqN8obrALcGfHYrQZSBGFz9sHf9Y6ehp6/k4o7qEI0dsW/F1
         LQBA==
X-Forwarded-Encrypted: i=1; AHgh+RobPa06e+hC0ahyGhGCaF2t/1ZS4fEmgeNYgZ9pC/QCvYlKQGBxLG+FlsMf4215TS+AFQlXlSu4wO8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxNdVX3fyJOns9uu+3GddEZ8fqkBEJhCwMHqImXxSXUz5wFAtvI
	BtC2t5BTShyVS5/Db3pZowHlilOhw+r3HjbAlLUxUyqwkkvXgiQmDo7Ur4cjUnoZ8Wo=
X-Gm-Gg: AR+sD10pFCe5g5LjuR+z3sy5niGDonhEjANvPTYIYt6LYfu37UxEiRHpy7PKhLOC8wg
	+k15hnHMCpO4f1iHzUkmOW0kxJlIrVf9LryI5019hY5jcuuQPDcDR/VmTgTNzTSr6PvbGzeNGsU
	cc5QDQBcJaz0eB0sbxhirFZHf3G0ufRl7VZyaQmoYaAyZhduyYXvvkl5eIzBEGpX0QJx2MzxpjH
	n45nliJpq7aWCUj8fMLgtB4W33Xnp8ZYuXElbolaoR6O4w4zWSQisBjHJ6p6fMW9s+Ho24Pe15d
	uVh3QqVzvV2qvTj8DosG514SKVFFs6DCJl5srPBBTqpN9ZjiO14TtDwrRXr9aut1nwSwE3mUNiK
	QEQwRcDTyNh+T/vob8L33GuX2ky9Zl9TMzTQJXOsJblhUEnrJg92FnzTpNrFNV/5PJwMBPK7i6w
	18tg3lFssVFkTTiLgBA0cZ7SFVIfGomjeCD8HZeX0WkSLW0dUsrhFkwWs5khAMUDWUxRPYUSRvw
	liMpHNLYVrILJwT0CV3xned2b1jTqzwtzl2Z2MjcT5OGbE4DQDoAFoYrWck34+pHIUJkacv3MYq
	2tlR3KpYvQKgog==
X-Received: by 2002:a05:6402:20d1:10b0:6a3:8525:b9da with SMTP id 4fb4d7f45d1cf-6a3d1f2c5d1mr4361648a12.4.1787037840095;
        Tue, 18 Aug 2026 00:24:00 -0700 (PDT)
Message-ID: <d4fc3ae9-e048-4e66-bd18-d4a7a2024dd6@suse.com>
Date: Tue, 18 Aug 2026 09:23:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-3-frn1furkan10@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260818063259.18733-3-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------in5zL4sb5tT0i26bidN0O2OD"
X-purgate-ID: tlsNG-16d1c6/1787037840-F4A0477B-E750C1C6/0/0
X-purgate-type: clean
X-purgate-size: 9528

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------in5zL4sb5tT0i26bidN0O2OD
Content-Type: multipart/mixed; boundary="------------hy22a6UXLvCxK10ANgSLlwHt";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
Message-ID: <d4fc3ae9-e048-4e66-bd18-d4a7a2024dd6@suse.com>
Subject: Re: [PATCH 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-3-frn1furkan10@gmail.com>
In-Reply-To: <20260818063259.18733-3-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------hy22a6UXLvCxK10ANgSLlwHt
Content-Type: multipart/mixed; boundary="------------2oZQmAeItHC3huexOgzquQki"

--------------2oZQmAeItHC3huexOgzquQki
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTguMDguMjYgMDg6MzIsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gc2NoZWRfaW5p
dF92Y3B1KCkgY2FsbHMgaW5pdF90aW1lcigpIGZvciBhIHZjcHUncyBwZXJpb2RpY190aW1l
ciwNCj4gc2luZ2xlc2hvdF90aW1lciBhbmQgcG9sbF90aW1lciBiZWZvcmUgaXQgY2FuIGZh
aWwgLS0gdGhlc2UNCj4gYmVjb21lIGxpdmUsIGxpbmtlZCBpbnRvIHRoZWlyIHRhcmdldCBw
Q1BVJ3MgcGVyLWNwdSB0aW1lciBsaXN0DQo+IHJlZ2FyZGxlc3Mgb2Ygd2hhdCBoYXBwZW5z
IG5leHQuIElmIHRoZSBzY2hlZF9hbGxvY191ZGF0YSgpIGNhbGwNCj4gZnVydGhlciBkb3du
IHRoZW4gZmFpbHMsIHRoZSBmdW5jdGlvbiBmcmVlcyB0aGUgc2NoZWRfdW5pdCB2aWENCj4g
c2NoZWRfZnJlZV91bml0KCkgYW5kIHJldHVybnMgMSwgYnV0IG5ldmVyIHVubGlua3MgdGhl
c2UgdGhyZWUNCj4gdGltZXJzLg0KPiANCj4gVGhlIGNhbGxlciwgdmNwdV9jcmVhdGUoKSwg
ZG9lcyB3b3JzZTogb24gc2NoZWRfaW5pdF92Y3B1KCkNCj4gcmV0dXJuaW5nIG5vbnplcm8g
aXQganVtcHMgdG8gZmFpbF93cSwgc2tpcHBpbmcgZmFpbF9zY2hlZCBhbmQNCj4gdGh1cyBz
Y2hlZF9kZXN0cm95X3ZjcHUoKSAtLSB0aGUgb25seSBmdW5jdGlvbiBvbiB0aGlzIHBhdGgg
dGhhdA0KPiBjYWxscyBraWxsX3RpbWVyKCkgb24gdGhlbS4gdmNwdV9kZXN0cm95KCkgdGhl
biBmcmVlcyB0aGUgdmNwdSwNCj4gYW5kIHRoZSB0aHJlZSB0aW1lcnMgZW1iZWRkZWQgaW4g
aXQsIHdoaWxlIHRoZXkgYXJlIHN0aWxsIGxpbmtlZA0KPiBpbnRvIHRoYXQgc2hhcmVkIGxp
c3QuDQo+IA0KPiBUaGlzIHNpbGVudGx5IGNvcnJ1cHRzIHRoYXQgbGlzdC4gSXQgb25seSBz
aG93cyB1cCBsYXRlciwgd2hlbg0KPiBzb21ldGhpbmcgZWxzZSB0b3VjaGVzIGEgbmVpZ2hi
b3JpbmcgdGltZXI6IHNjaGVkX21vdmVfZG9tYWluKCkNCj4gY3Jhc2hlZCB3aXRoICJBc3Nl
cnRpb24gJ2VudHJ5LT5wcmV2LT5uZXh0ID09IGVudHJ5JyBmYWlsZWQiIG9uIGENCj4gY29t
cGxldGVseSB1bnJlbGF0ZWQsIHZhbGlkIHZjcHVzJ3MgdGltZXIuDQo+IA0KPiBLaWxsIGFs
bCB0aHJlZSB0aW1lcnMgaW4gc2NoZWRfaW5pdF92Y3B1KCkncyBvd24gZmFpbHVyZSBicmFu
Y2gsDQo+IHNvIGl0IGRvZXNuJ3QgZGVwZW5kIG9uIHRoZSBjYWxsZXIgcmVhY2hpbmcgc2No
ZWRfZGVzdHJveV92Y3B1KCkNCj4gdG8gdW5kbyB3aGF0IGl0IHNldCB1cCBpdHNlbGYuDQo+
IA0KPiBTaWduZWQtb2ZmLWJ5OiBGdXJrYW4gQ2FsaXNrYW4gPGZybjFmdXJrYW4xMEBnbWFp
bC5jb20+DQoNCkFwYXJ0IGZyb20gdGhlIG1pc3NpbmcgRml4ZXM6IHRhZzoNCg0KUmV2aWV3
ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=

--------------2oZQmAeItHC3huexOgzquQki
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------2oZQmAeItHC3huexOgzquQki--

--------------hy22a6UXLvCxK10ANgSLlwHt--

--------------in5zL4sb5tT0i26bidN0O2OD
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqECI8FAwAAAAAACgkQsN6d1ii/Ey9q
Rwf+L2k3awXc3UT0xayKlNJypmTwgpurZd+e/oogZbePtjmYOLhhd3Lc1tvsWGNUiV+tuft0OFFg
7RSZ/0mT7hG1dZ9GCSAHnWoKVh73ePdEzuwYenY7D8lyu4mwk8UndihQPOEksGVAbfiq7AqdLATW
9oHEkjn5xIE7SllJQVCYUrqg4gZ8yqUJL5TBeg5+cLYqZC80eBM61OAWB8Fw9SiLGoRX9BgYbuh8
tRhvJy0wEpf66CfC27GW/TYG/yeJfQYs5j2nuQdwhS7f0LRkXkE8joklty2ZIKs+u+oAZbEkUa7y
BF2e4qTjM0O33uRU1hjzH/gbV1lMu1OhHPrqMMQK4w==
=e9ze
-----END PGP SIGNATURE-----

--------------in5zL4sb5tT0i26bidN0O2OD--


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:31:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:31:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393560.1632378 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEI8-0006uG-A7; Tue, 18 Aug 2026 07:31:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393560.1632378; Tue, 18 Aug 2026 07:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEI8-0006u9-7K; Tue, 18 Aug 2026 07:31:24 +0000
Received: by outflank-mailman (input) for mailman id 1393560;
 Tue, 18 Aug 2026 07:31:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwEI6-0006u3-H3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:31:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEI5-005rAp-BQ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:31:21 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a840a3f-bab6-0a2a0a5309dd-0a2a4504a1aa-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:31:21 +0200
Received: from [209.85.208.45] (helo=mail-ed1-f45.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a840a49-b57f-0a2a45040019-d155d02dc5a5-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:31:21 +0200
Received: by mail-ed1-f45.google.com with SMTP id
 4fb4d7f45d1cf-6a0a4a17f91so6450177a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:31:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b81748sm9925960f8f.37.2026.08.18.00.31.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:31:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787038280; x=1787643080; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=pXpZsmJ61FrDBmxfTHEIMZ42vT/kI2HLZ6xI/PR5zvo=;
        b=PT4oltyiE3eSBHOWQDkK7jRIG+cj7z1sJT8hWrogQWLXsNAKKgH+gajE4fGcOYJXxH
         0i7ZIjRis6UnEIJX7dog4kwAHSZDCq2rZv8TJ60hu1aE2/adfaM510DZYVR6GzQwKX1d
         2mq/XWTF2NAK9KNmj3hldCUBQyeaDsyvW4KjK70YFfSooZ6EXvtsEWDNDLFNRA9Ezcr2
         V/7x6+JewlTnSXyq53t+D5QabvyhoXHgfFXaZWkkxN4+peMVERflxeUxz25C5Ie/ZE98
         T4tlWTEB7hAoftG4seUHiRa7RQQWW7mMd30CaGXlv/P6wdX92otzOcuSU7dXQIVNo7aJ
         VcuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787038280; x=1787643080;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=pXpZsmJ61FrDBmxfTHEIMZ42vT/kI2HLZ6xI/PR5zvo=;
        b=rxWbJbVOE22thnqiHDJqsrsqOXRdhjqadr2qrBhdEOkslEqUvvjoNBiGTvp4at7S79
         /KQ6PagKts7n6JQgUyb4eE/155igD/FKEe+uRjSNz1MpLUyvEZGEcDRZGnstw559eTtx
         ixqM5KX52K0tQ74G5BlsyXmhmcwUD7uBNvtFPxs68AuluOK6+9w6Xvxf6owqr4M3CWoo
         75aL9MdDfNEmfl6Pcey9XWyl7Goh9Ix79dMHLrTuvc7ZK7sEUa0J4tGWfi8ImtwzcdAb
         N4ZN9q3TKMHqe8/Z0m6vIA7iuTuYtEJGJIbMCDa43x/tuj82epMvE5Sz3Iw0O5nfQPRW
         QrZw==
X-Forwarded-Encrypted: i=1; AHgh+RrmwV/KkRiYortFXy4RnBBbUk39sbpBpqsDLS2BYrENj8Sgf4SqyznC9V0Yu3d5AwphltPWDvTDaBE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz8gMXKFumfs8RDqyTTeowcZC4rqohjDD8yHB9x6ikqvDqJPfiX
	sUhIdoob+BHvRIHqx0zWI4NFCb3hnXod1xIJ7LTD7EdNAY6Q4cFR7I+mCbqhdVLIHlbvsL7/f8H
	JvkuwDg==
X-Gm-Gg: AR+sD103po1FnK19YUE4PbA5XofxhecXDOUyyaBHsnFnihrfBDxyRThU2OR7KiXCIwL
	1i4F6mkNWuHx5DZvsmbwxB8lKCaAzuyfaIgw5BVEeU13fBpRB1e3jGnAOXmyB12rEgxeIIfZWCp
	vyyLyURs1y1zuLcJlFmO+6NDATZpyU1Vcp4770rcOQwEJUqLWNH5CphOzLVKHUcDsXsdEQ6MdiD
	tzVj8TP7qfcdF8WDJrB43ezdZleYVcp2B9Z2rWAqfOYmdJ20JhQSfRdioEdguUmtoJYZZL297VG
	qaLGaw8vqZXRR+vhqfU78oUW/9JIPsBab9SXO4fijhwfyrx1eON8UgbU08OzqWwAFD9szdcamhg
	KmWxfHuZAJDC7Y2b76oRGHJZ5XdDu64btGrl0zmrDGHQHZ+S8r58YtInIDloDU7owKFCv7GtyVe
	5ErjuYn6b9kwykgOUc6kwk9gFB+MjZi/HNWEm/o04YhaMQJzooWmde0IuF6TLQtCZ+L1rZbRmby
	WHuleDMpU9JwSqq2OzYPahXKaVBUXZUUpxCYpUs0VDkjSmkO10w
X-Received: by 2002:a17:907:fd18:b0:c16:4df6:176b with SMTP id a640c23a62f3a-c212a126a7emr1357477666b.20.1787038279183;
        Tue, 18 Aug 2026 00:31:19 -0700 (PDT)
Message-ID: <253d3fc1-fb38-4e22-b5e0-6e2c9f27afed@suse.com>
Date: Tue, 18 Aug 2026 09:31:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 6/5] x86/nmi: Support watchdogs on Intel Fam18/19 CPUs
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260805124525.105457-6-andrew.cooper3@citrix.com>
 <20260817172348.1839547-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260817172348.1839547-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787038281-52ECEB50-9F18C1D8/0/0
X-purgate-type: clean
X-purgate-size: 1971

On 17.08.2026 19:23, Andrew Cooper wrote:
> It is the Pentium 4 (Fam15) which is the odd-one-out.  The counter indicies
> used in the P6 went on to be declared architectural, and Fam18/19 continue
> using the architectural indices.

Do you really mean P6? The code in hunk context uses both
P6_EVENT_CPU_CLOCKS_NOT_HALTED, CORE_EVENT_CPU_CLOCKS_NOT_HALTED, and
I'm pretty sure that if anything became architectural, it would be what
Core uses.

> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger@xenproject.org>
> CC: Teddy Astie <teddy.astie@vates.tech>
> 
> This wants backporting to 4.21.  So does "Check MSR_MISC_ENABLE for all Intel
> platforms" on which it texturally depends.

Sure; that other one first has to go in though.

For both - why do you say specifically 4.21? Stuff to support newer
families may be reasonably natural to go onto the most recent major
release. If it was to also go further back, I then wouldn't quite see
why to stop at 4.21. Surely the MSR_MISC_ENABLE one I intend to put onto
everything back to 4.20.

> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -329,17 +329,12 @@ void setup_apic_nmi_watchdog(void)
>              break;
>          }
>  
> -        switch ( boot_cpu_data.family )
> -        {
> -        case 6:
> +        if ( boot_cpu_data.family == 15 )
> +            setup_p4_watchdog(misc);
> +        else
>              setup_p6_watchdog((boot_cpu_data.model < 14)

This model check surely applies to family 6 only? Hence why we may be
better off sticking to the use of switch().

Jan

>                                ? P6_EVENT_CPU_CLOCKS_NOT_HALTED
>                                : CORE_EVENT_CPU_CLOCKS_NOT_HALTED);
> -            break;
> -        case 15:
> -            setup_p4_watchdog(misc);
> -            break;
> -        }
>          break;
>      }
>  



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:47:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:47:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393570.1632387 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEXP-0000KQ-Lb; Tue, 18 Aug 2026 07:47:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393570.1632387; Tue, 18 Aug 2026 07:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEXP-0000KJ-Hq; Tue, 18 Aug 2026 07:47:11 +0000
Received: by outflank-mailman (input) for mailman id 1393570;
 Tue, 18 Aug 2026 07:47:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <stojkovicdusan555@gmail.com>) id 1wwEXO-0000KD-1V
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:47:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEXN-00COfS-9O
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:47:09 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <stojkovicdusan555@gmail.com>)
 id 6a840de6-2eae-0a2a0a5409dd-0a2a450be51e-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:47:09 +0200
Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <stojkovicdusan555@gmail.com>)
 id 6a840dfd-b7e8-0a2a450b0019-d155da30ec0b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:47:09 +0200
Received: by mail-ej1-f48.google.com with SMTP id
 a640c23a62f3a-c2022323c37so538155766b.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:47:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787039229; cv=none;
        d=google.com; s=arc-20260327;
        b=Y274OzEm2hJ7N1nLiJ3v5/fewnf4Cuc0ePtTLhsFXs/nA3KMsTNhb+UrAw0d8Cj7Nv
         IKR98+0BYuSkjpqrgrZ4Th/ZF1zoKbigO/Pko3RgxIGWqS6zx6KZ2jc3E7D4VW4W53LZ
         hleg0FnBApVqKzprO5r6ipZB8F9yKjOa04SllSYrAjx0LOxBdVw8F1OQ9QUNYF3k+Hjj
         4F0/PedZXdA3fiMuRem+HdBiqYc86JpU3E5QcEtSIR8ODHIcRCyY1wnQRvtWXt6ElhLL
         XPB3WjNTB7+yGrMb91jDuiFoUq0b4j1f/cwUl8NXOTPamRy1WTJ1grEaKa0UYGdRbCAN
         LLlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=8zpGVmQCF4Ej1R71DGStEiTG8p9UGbCUyASXHvOD9PY=;
        fh=X71NQUKnNgYptC1inX+R4i9FMImhMA36OFztJnavrjY=;
        b=PXdRMKr5wESb0DjKlx3IaEhBB1IZWmJrB32mxE3eMIxPC2LELA9jv/JyCxdMk3raIp
         763bl1nHRa4v5jjf5yKuECzb9wSondw2HyVmRW3hK+otvYP6Hr4Uhf9tlECGYS9LFctV
         YjfJKuXetnq+o6eTnfaXgaokGRdUKRRqiHIqMRFTr1lA0vRQT1+CaNhBSfzG6dj2p5DK
         lPUT0YK2+sIwzFHR3uWwIlEAOXx8sr3UIdKdNZFdkTiELal9rB5w889WkycFHLK8VM/q
         fredsnLmAz9BESYHomJcAc0luXkbLdklBvMrgPNXWB9ldlg2MSxDORsUSy4hIqxVqD9f
         TPbg==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787039229; x=1787644029; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=8zpGVmQCF4Ej1R71DGStEiTG8p9UGbCUyASXHvOD9PY=;
        b=iUFWHHZpGsDdgnH/pf0Q3yMkIz9zx+aJON1AbzuD0i95l190UqVtT8ztvLpJ0e0cal
         bpJF/LiCqotrhk3I4si8Y//98Y+H6hJzefZZMtv8q+eYKyQbA25mzf2O9fR1y/FooPpn
         2MOx8iHMaYgDhdFJpFHfHQSV2BxWMHBtVAdIWM7WVgIkHvYGQ36QClOUp8HFhsul+yIo
         6jhFFFlNf6qwPmGdgfm0F0u2xlMYRCwtW6JYG8SKnjtX+4wm/fzpi/1qp+/09Y46FbhR
         oOwBzCuZ/of0PZnt9LF+QcNbX0rxlvCzrzu7e91XxasI5P4AkHRMspMpkL7eyifLwEJS
         0ULg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787039229; x=1787644029;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=8zpGVmQCF4Ej1R71DGStEiTG8p9UGbCUyASXHvOD9PY=;
        b=V6FPF7CHeImrrh5ClP3M5pb+BuMWebVS6TKvZEFpT7M7lqFDAfD8HPh3KCJ1WBNM9X
         FEL4SmrA7fyIoS9IWd9x5X/FmQuVAh1fficgMf2Dmvshp+EAstTOPwrqZX3Yra7q/t7+
         vcjFQBg4Z1MVK2MeYWyk2p9a03hDng/HRmyVfKhQC256lT8MY9w+qtR9C2JRVs9lNNDn
         VNt64sTSrBDADVgzFl7BOMz+RU3CPcj2ikfQSN4rHaOL93IMRyaVCdC3wrB7MDFyD4fS
         uuGqeiMEMVCQ/rrYUpEeuXRKoqafdOx6wr5dNJjXvy4dIRNmdztJjGpDdN3/OyIpP1Bg
         e+8A==
X-Forwarded-Encrypted: i=1; AHgh+RpoVpb9IxysVBeH3+ni/Axk/ko0kj2kOcGkX/+xiNvKEQaj/eM84IFmbmPpIov3Spe8tA1U6TK2puo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGGICwhPrDh4h4rooCjfagMJzk4CeyTVDRqqhJw6F/qWXFmb7n
	ARpOco0ilTDr6ff2SRUW+jx3yuHNR3wxmY8GYY79lmfFqC0VEA30vnKcq+7nWBpo3Qa2LrXiXNw
	w3wo1lfIlNeVLHwCYeJcUPS+MuxTLUDk=
X-Gm-Gg: AR+sD136JzUrYvI5FsuRtlsKnIJW2yxbNhLZve6ucgGQmFy4YGYC+ohymKY2UbjklYs
	mrg2SYE6GwugZLgrfXBqC64xEDyqaJca6ooDJEfFiun8smco7/E3m8zlecoMIxzB8XQ4tYreE9i
	gJTqyevrBykO8uANicGn3Dfj/k0Lc48qO4Onf8Mav+NICRq/66YCX4JUrFYGpY9wdrEqy02U5me
	BnxjCdDOWiZtN7w5jfWooS1WL1nimyr7L1X2Zr66GxeFxpS7R92n5SztUNsiPZxRWIis/hmxdJY
	Y5BBUGglPOCBp5sgaSjeTbZyQIaKUXbfuNv33NfyyZWhQA==
X-Received: by 2002:a17:907:3e0a:b0:c19:473b:dc8f with SMTP id
 a640c23a62f3a-c2129a9a64bmr1559305066b.3.1787039228250; Tue, 18 Aug 2026
 00:47:08 -0700 (PDT)
MIME-Version: 1.0
References: <20260702-vhost-xen-foreign-mapping-v3-0-2b8ef913382b@rt-rk.com>
In-Reply-To: <20260702-vhost-xen-foreign-mapping-v3-0-2b8ef913382b@rt-rk.com>
From: Dusan Stojkovic <stojkovicdusan555@gmail.com>
Date: Tue, 18 Aug 2026 09:46:55 +0200
X-Gm-Features: AcwNN1W7gU_jJa_iP4WQA_eZBPE7Cr-gPNRXOQzqoF4jm3hepZhRV2OF6Roqhp0
Message-ID: <CALPHYNQOLY1FBRE_=rKHSXRELBpinezpLWUb2cwuKY+ev64j2A@mail.gmail.com>
Subject: Re: [PATCH RFC v3 0/2] vhost-user: support Xen foreign memory mappings
To: qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD <anthony@xenproject.org>, 
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>, xen-devel@lists.xenproject.org, 
	Viresh Kumar <viresh.kumar@linaro.org>, Dusan Stojkovic <Dusan.Stojkovic@rt-rk.com>, 
	Nikola Jelic <Nikola.Jelic@rt-rk.com>
Content-Type: multipart/alternative; boundary="000000000000664b2706594d7e05"
X-purgate-ID: tlsNG-42698a/1787039229-1AEDE9EA-44D70C0B/0/0
X-purgate-type: clean
X-purgate-size: 18889

--000000000000664b2706594d7e05
Content-Type: text/plain; charset="UTF-8"

Ping for feedback.

On Thu, Jul 2, 2026, 11:47 AM Dusan Stojkovic <stojkovicdusan555@gmail.com>
wrote:

> This series lets QEMU, when running as a Xen device model, drive
> vhost-user backends that map guest memory through the Xen foreign
> mapping interface, implementing the front-end side of
> VHOST_USER_PROTOCOL_F_XEN_MMAP. The protocol extension itself is
> already documented in docs/interop/vhost-user.rst (feature bit 17,
> extended memory region description) and implemented by rust-vmm's
> vhost / vm-memory crates and the vhost-device backends built on them.
>
> The problem this solves: under Xen the guest's RAM is not allocated by
> QEMU and is not backed by a file descriptor. memory_region_get_fd()
> returns -1, so vhost_section() filters out every RAM section, the vhost
> memory listener registers no regions, and starting any vhost-user
> device fails with "Failed initializing vhost-user memory map". With
> F_XEN_MMAP the backend maps guest memory itself.
>
> The protocol requires one file descriptor per region in SET_MEM_TABLE.
> Guest RAM under Xen has no backing fd, so the front-end opens
> /dev/xen/privcmd per region purely to satisfy that requirement; the
> backend derives the mapping from guest_phys_addr + domid and never
> reads the fd. Each fd is closed once the message has been sent.
>
> This patchset was rebased onto the new vhost_phys_vring_addr
> infrastructure
> and extends vhost_user_gpa_addresses() so that negotiated
> F_XEN_MMAP (bit 17), not F_GPA_ADDRESSES (bit 21, which the backend
> doesn't
> advertise), drives GPA addressing for both rings and userspace_addr.
>
> The two patches:
>   1/2  accept the Xen RAM section in vhost_section()
>   2/2  negotiate F_XEN_MMAP and build SET_MEM_TABLE from the extended
>        region layout.
> Testing:
> Tested on Xen/ARM64 with a DomU using virtio-mmio transports created
> by the xenpvh machine, running vhost-device-sound (rust-vmm, built
> with the "xen" feature) as the backend in dom0. The device negotiates,
> receives the memory table and ring addresses, and the guest's
> virtio-snd driver probes and operates.
>
> Non-Xen / x86 KVM: vhost-user-snd backed by
> vhost-device-sound (null backend) on a q35/KVM guest. The device
> negotiates, the guest virtio-snd driver probes and runs the control and
> PCM paths, and the SET_MEM_TABLE and vring-address traffic is identical
> to a build without this series confirming the
> non-Xen path is unchanged.
>
> The control message exchange between the frontend and backend was
> tracked using sockdump as was described in:
> Making VirtIO sing - implementing virtio-sound in rust-vmm project
> |-> at FOSDEM 2024
>
> Setup:
> The main part of the xl config this enables:
> virtio = [
>  'backend=0,type=virtio,device,transport=mmio,grant_usage=false'
> ]
>
> device_model_args = [
>  ...
>  '-chardev', 'socket,id=snd_chardev,path=/tmp/snd.sock',
>  '-device',
> 'vhost-user-snd,chardev=snd_chardev,id=snd,iommu_platform=true',
>  ...
> ]
>
> Xen 4.22-unstable was used with:
>  -enable-IOREQ_SERVER
>  -enable-EXPERT
>
> An extra patch was added to xen-tools.
> Namely, xen tools will request a pv device drive type for ARM64 but
> qemu expects pvh. This is a known issue:
> github.com/Xilinx/xen/commit/5f669949c9ffdb1947cb47038956b5fb8eeb072a
>
> Qemu master was used configured with the following flags:
>     --target-list=aarch64-softmmu \
>     --cross-prefix=aarch64-linux-gnu- \
>     --enable-xen \
>     --enable-vhost-user \
>     --extra-cflags="-I$XEN-TOOLS/usr/local/include" \
>     --extra-ldflags="-L$XEN-TOOLS/usr/local/lib -Wl,
>         -rpath-link,$XEN-TOOLS/usr/local/lib" \
>
> Likewise for x86:
>     --target-list=aarch64-softmmu \
>     --enable-slirp \
>     --enable-xen \
>     --enable-vhost-user \
>     --enable-virtfs \
>
> Linux version 6.11.7 was used with extra configuration flags:
> * For enabling Xen Dom0/DomU support
> * For enabling virtio (mmio, snd, etc.)
> * For enabling sockdump features (BPF, IKHEADERS, KPROBE, etc.)
> * Extra debug flags (DEBUG_FS, etc.)
>
> vhost-device commit-id:
>     c3bb658ef4fe20a2f264dbbbbc6fa19f1c08c0c5
>
>     Was used built with:
>     --features alsa-backend,xen
>
> Importantly in vhost-device-scmi/src/vhu_scmi.rs:
>
> // QUEUE_SIZE must be apparently at least 1024 for MMIO.
> // There is probably a maximum size per descriptor defined in the kernel.
> const QUEUE_SIZE: usize = 1024;
>
> A similar change was made to make mmio work in vhost-user-sound device,
> bumping QUEUE_SIZE to 1024.
>
> Without this frontend and backend will fail to negotiate queue size.
>
> Scope and known limitations:
> * Foreign mappings only. Grant mappings are not supported: vhost's
>   section tracking derives a host pointer for each region, which is
>   invalid for the grant pseudo-region, and per-access grant mapping
>   needs a different region description (GRANT | no-advance-map). Patch
>   1 rejects the xen.grants region explicitly. Setting grant_usage=true
>   does not change the qemu<->backend vhost-user exchange.
>
> * VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS is suppressed under Xen:
>   the ADD/REM_MEM_REG path has not been converted to the extended
>   region format, and Xen guests currently expose a single RAM region,
>   so SET_MEM_TABLE is sufficient. Multiple RAM regions are not yet
>   exercised. Postcopy is refused.
>
> * Spec vs reference implementation: docs/interop/vhost-user.rst
>   describes the "can not be mapped in advance" xen-mmap flag as Bit 8
>   (value 0x100), whereas rust-vmm's vm-memory uses 0x8 (bit 3,
>   MmapXenFlags::NO_ADVANCE_MAP). This series uses neither, but the
>   discrepancy probably wants resolving in the spec. Viresh, which is
>   intended -- bit position 8 or value 0x8?
>
> * userspace_addr is carried unchanged in the region descriptor; under
>   Xen it does not correspond to a mapping and backends do not
>   interpret it. An alternative would be to define it (e.g. mirror
>   guest_phys_addr).
>
> Open questions:
> - userspace_addr semantics under Xen: leave it unchanged, or define it?
> - Multi-region support: convert ADD/REM_MEM_REG to the extended layout
>   rather than suppressing CONFIGURE_MEM_SLOTS?
> - Grant-mapping support: worth pursuing, and what region-description
>   shape do backends expect?
> - Updating vhost-device-sound to reflect the mmio support.
>
> References:
> - vhost-user spec, F_XEN_MMAP / extended memory region / xen mmap flags:
>   docs/interop/vhost-user.rst
> - rust-vmm vm-memory MmapXenFlags (FOREIGN=0x1, GRANT=0x2,
>   NO_ADVANCE_MAP=0x8): src/mmap/xen.rs
> - Making VirtIO sing - implementing virtio-sound in rust-vmm project
> |-> at FOSDEM 2024
>
> Signed-off-by: Dusan Stojkovic <Dusan.Stojkovic@rt-rk.com>
> Signed-off-by: Nikola Jelic <Nikola.Jelic@rt-rk.com>
> ---
> Changes in v3:
> - Rebased onto current master
> - Fixed semantic error in vhost_section comment
> - Link to v2:
> https://lore.kernel.org/qemu-devel/20260629-vhost-xen-foreign-mapping-v2-0-19e4685e7575@rt-rk.com
>
> Changes in v2:
> - Rebased onto current master
> - Cover letter: removed a rust-vmm hunk which made the git am
>   on Patchview fail. The reference is now mentioned in a sentance.
> - Link to v1:
>
> https://lore.kernel.org/qemu-devel/20260618-vhost-xen-foreign-mapping-v1-0-7f60a6241971@rt-rk.com
>
> ---
> Dusan Stojkovic (2):
>       vhost: accept Xen guest RAM sections for vhost-user
>       vhost-user: implement VHOST_USER_PROTOCOL_F_XEN_MMAP
>
>  hw/virtio/trace-events         |   2 +
>  hw/virtio/vhost-user.c         | 120
> +++++++++++++++++++++++++++++++++++++++--
>  hw/virtio/vhost.c              |  18 +++++++
>  hw/xen/xen_stubs.c             |   5 ++
>  include/hw/virtio/vhost-user.h |   2 +-
>  5 files changed, 143 insertions(+), 4 deletions(-)
> ---
> base-commit: 30e8a06b64aa58a3990ba39cb5d09531e7d265e0
> change-id: 20260618-vhost-xen-foreign-mapping-d023c85bb706
>
> Best regards,
> --
> Dusan Stojkovic <Dusan.Stojkovic@rt-rk.com>
>
>

--000000000000664b2706594d7e05
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Ping for feedback.</div><br><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 2, 20=
26, 11:47 AM Dusan Stojkovic &lt;<a href=3D"mailto:stojkovicdusan555@gmail.=
com">stojkovicdusan555@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">This series lets QEMU, when running as a Xen device model, dr=
ive<br>
vhost-user backends that map guest memory through the Xen foreign<br>
mapping interface, implementing the front-end side of<br>
VHOST_USER_PROTOCOL_F_XEN_MMAP. The protocol extension itself is<br>
already documented in docs/interop/vhost-user.rst (feature bit 17,<br>
extended memory region description) and implemented by rust-vmm&#39;s<br>
vhost / vm-memory crates and the vhost-device backends built on them.<br>
<br>
The problem this solves: under Xen the guest&#39;s RAM is not allocated by<=
br>
QEMU and is not backed by a file descriptor. memory_region_get_fd()<br>
returns -1, so vhost_section() filters out every RAM section, the vhost<br>
memory listener registers no regions, and starting any vhost-user<br>
device fails with &quot;Failed initializing vhost-user memory map&quot;. Wi=
th<br>
F_XEN_MMAP the backend maps guest memory itself.<br>
<br>
The protocol requires one file descriptor per region in SET_MEM_TABLE.<br>
Guest RAM under Xen has no backing fd, so the front-end opens<br>
/dev/xen/privcmd per region purely to satisfy that requirement; the<br>
backend derives the mapping from guest_phys_addr + domid and never<br>
reads the fd. Each fd is closed once the message has been sent.<br>
<br>
This patchset was rebased onto the new vhost_phys_vring_addr infrastructure=
 <br>
and extends vhost_user_gpa_addresses() so that negotiated<br>
F_XEN_MMAP (bit 17), not F_GPA_ADDRESSES (bit 21, which the backend doesn&#=
39;t <br>
advertise), drives GPA addressing for both rings and userspace_addr.<br>
<br>
The two patches:<br>
=C2=A0 1/2=C2=A0 accept the Xen RAM section in vhost_section()<br>
=C2=A0 2/2=C2=A0 negotiate F_XEN_MMAP and build SET_MEM_TABLE from the exte=
nded<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0region layout. <br>
Testing:<br>
Tested on Xen/ARM64 with a DomU using virtio-mmio transports created<br>
by the xenpvh machine, running vhost-device-sound (rust-vmm, built<br>
with the &quot;xen&quot; feature) as the backend in dom0. The device negoti=
ates,<br>
receives the memory table and ring addresses, and the guest&#39;s<br>
virtio-snd driver probes and operates.<br>
<br>
Non-Xen / x86 KVM: vhost-user-snd backed by<br>
vhost-device-sound (null backend) on a q35/KVM guest. The device<br>
negotiates, the guest virtio-snd driver probes and runs the control and<br>
PCM paths, and the SET_MEM_TABLE and vring-address traffic is identical<br>
to a build without this series confirming the<br>
non-Xen path is unchanged.<br>
<br>
The control message exchange between the frontend and backend was<br>
tracked using sockdump as was described in:<br>
Making VirtIO sing - implementing virtio-sound in rust-vmm project<br>
|-&gt; at FOSDEM 2024<br>
<br>
Setup:<br>
The main part of the xl config this enables:<br>
virtio =3D [<br>
=C2=A0&#39;backend=3D0,type=3Dvirtio,device,transport=3Dmmio,grant_usage=3D=
false&#39;<br>
]<br>
<br>
device_model_args =3D [<br>
=C2=A0...<br>
=C2=A0&#39;-chardev&#39;, &#39;socket,id=3Dsnd_chardev,path=3D/tmp/snd.sock=
&#39;,<br>
=C2=A0&#39;-device&#39;, &#39;vhost-user-snd,chardev=3Dsnd_chardev,id=3Dsnd=
,iommu_platform=3Dtrue&#39;,<br>
=C2=A0...<br>
]<br>
<br>
Xen 4.22-unstable was used with:<br>
=C2=A0-enable-IOREQ_SERVER <br>
=C2=A0-enable-EXPERT<br>
<br>
An extra patch was added to xen-tools.<br>
Namely, xen tools will request a pv device drive type for ARM64 but <br>
qemu expects pvh. This is a known issue:<br>
<a href=3D"http://github.com/Xilinx/xen/commit/5f669949c9ffdb1947cb47038956=
b5fb8eeb072a" rel=3D"noreferrer noreferrer" target=3D"_blank">github.com/Xi=
linx/xen/commit/5f669949c9ffdb1947cb47038956b5fb8eeb072a</a><br>
<br>
Qemu master was used configured with the following flags:<br>
=C2=A0 =C2=A0 --target-list=3Daarch64-softmmu \<br>
=C2=A0 =C2=A0 --cross-prefix=3Daarch64-linux-gnu- \<br>
=C2=A0 =C2=A0 --enable-xen \<br>
=C2=A0 =C2=A0 --enable-vhost-user \<br>
=C2=A0 =C2=A0 --extra-cflags=3D&quot;-I$XEN-TOOLS/usr/local/include&quot; \=
<br>
=C2=A0 =C2=A0 --extra-ldflags=3D&quot;-L$XEN-TOOLS/usr/local/lib -Wl,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -rpath-link,$XEN-TOOLS/usr/local/lib&quot; \<br=
>
<br>
Likewise for x86:<br>
=C2=A0 =C2=A0 --target-list=3Daarch64-softmmu \<br>
=C2=A0 =C2=A0 --enable-slirp \<br>
=C2=A0 =C2=A0 --enable-xen \<br>
=C2=A0 =C2=A0 --enable-vhost-user \<br>
=C2=A0 =C2=A0 --enable-virtfs \<br>
<br>
Linux version 6.11.7 was used with extra configuration flags:<br>
* For enabling Xen Dom0/DomU support<br>
* For enabling virtio (mmio, snd, etc.)<br>
* For enabling sockdump features (BPF, IKHEADERS, KPROBE, etc.)<br>
* Extra debug flags (DEBUG_FS, etc.)<br>
<br>
vhost-device commit-id:<br>
=C2=A0 =C2=A0 c3bb658ef4fe20a2f264dbbbbc6fa19f1c08c0c5<br>
<br>
=C2=A0 =C2=A0 Was used built with:<br>
=C2=A0 =C2=A0 --features alsa-backend,xen<br>
<br>
Importantly in vhost-device-scmi/src/vhu_scmi.rs:<br>
<br>
// QUEUE_SIZE must be apparently at least 1024 for MMIO.<br>
// There is probably a maximum size per descriptor defined in the kernel.<b=
r>
const QUEUE_SIZE: usize =3D 1024;<br>
<br>
A similar change was made to make mmio work in vhost-user-sound device,<br>
bumping QUEUE_SIZE to 1024.<br>
<br>
Without this frontend and backend will fail to negotiate queue size.<br>
<br>
Scope and known limitations:<br>
* Foreign mappings only. Grant mappings are not supported: vhost&#39;s<br>
=C2=A0 section tracking derives a host pointer for each region, which is<br=
>
=C2=A0 invalid for the grant pseudo-region, and per-access grant mapping<br=
>
=C2=A0 needs a different region description (GRANT | no-advance-map). Patch=
<br>
=C2=A0 1 rejects the xen.grants region explicitly. Setting grant_usage=3Dtr=
ue<br>
=C2=A0 does not change the qemu&lt;-&gt;backend vhost-user exchange.<br>
<br>
* VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS is suppressed under Xen:<br>
=C2=A0 the ADD/REM_MEM_REG path has not been converted to the extended<br>
=C2=A0 region format, and Xen guests currently expose a single RAM region,<=
br>
=C2=A0 so SET_MEM_TABLE is sufficient. Multiple RAM regions are not yet<br>
=C2=A0 exercised. Postcopy is refused.<br>
<br>
* Spec vs reference implementation: docs/interop/vhost-user.rst<br>
=C2=A0 describes the &quot;can not be mapped in advance&quot; xen-mmap flag=
 as Bit 8<br>
=C2=A0 (value 0x100), whereas rust-vmm&#39;s vm-memory uses 0x8 (bit 3,<br>
=C2=A0 MmapXenFlags::NO_ADVANCE_MAP). This series uses neither, but the<br>
=C2=A0 discrepancy probably wants resolving in the spec. Viresh, which is<b=
r>
=C2=A0 intended -- bit position 8 or value 0x8?<br>
<br>
* userspace_addr is carried unchanged in the region descriptor; under<br>
=C2=A0 Xen it does not correspond to a mapping and backends do not<br>
=C2=A0 interpret it. An alternative would be to define it (e.g. mirror<br>
=C2=A0 guest_phys_addr).<br>
<br>
Open questions:<br>
- userspace_addr semantics under Xen: leave it unchanged, or define it?<br>
- Multi-region support: convert ADD/REM_MEM_REG to the extended layout<br>
=C2=A0 rather than suppressing CONFIGURE_MEM_SLOTS?<br>
- Grant-mapping support: worth pursuing, and what region-description<br>
=C2=A0 shape do backends expect?<br>
- Updating vhost-device-sound to reflect the mmio support.<br>
<br>
References:<br>
- vhost-user spec, F_XEN_MMAP / extended memory region / xen mmap flags:<br=
>
=C2=A0 docs/interop/vhost-user.rst<br>
- rust-vmm vm-memory MmapXenFlags (FOREIGN=3D0x1, GRANT=3D0x2,<br>
=C2=A0 NO_ADVANCE_MAP=3D0x8): src/mmap/xen.rs<br>
- Making VirtIO sing - implementing virtio-sound in rust-vmm project<br>
|-&gt; at FOSDEM 2024<br>
<br>
Signed-off-by: Dusan Stojkovic &lt;<a href=3D"mailto:Dusan.Stojkovic@rt-rk.=
com" target=3D"_blank" rel=3D"noreferrer">Dusan.Stojkovic@rt-rk.com</a>&gt;=
<br>
Signed-off-by: Nikola Jelic &lt;<a href=3D"mailto:Nikola.Jelic@rt-rk.com" t=
arget=3D"_blank" rel=3D"noreferrer">Nikola.Jelic@rt-rk.com</a>&gt;<br>
---<br>
Changes in v3:<br>
- Rebased onto current master<br>
- Fixed semantic error in vhost_section comment<br>
- Link to v2: <a href=3D"https://lore.kernel.org/qemu-devel/20260629-vhost-=
xen-foreign-mapping-v2-0-19e4685e7575@rt-rk.com" rel=3D"noreferrer noreferr=
er" target=3D"_blank">https://lore.kernel.org/qemu-devel/20260629-vhost-xen=
-foreign-mapping-v2-0-19e4685e7575@rt-rk.com</a><br>
<br>
Changes in v2:<br>
- Rebased onto current master<br>
- Cover letter: removed a rust-vmm hunk which made the git am<br>
=C2=A0 on Patchview fail. The reference is now mentioned in a sentance.<br>
- Link to v1:<br>
=C2=A0 <a href=3D"https://lore.kernel.org/qemu-devel/20260618-vhost-xen-for=
eign-mapping-v1-0-7f60a6241971@rt-rk.com" rel=3D"noreferrer noreferrer" tar=
get=3D"_blank">https://lore.kernel.org/qemu-devel/20260618-vhost-xen-foreig=
n-mapping-v1-0-7f60a6241971@rt-rk.com</a><br>
<br>
---<br>
Dusan Stojkovic (2):<br>
=C2=A0 =C2=A0 =C2=A0 vhost: accept Xen guest RAM sections for vhost-user<br=
>
=C2=A0 =C2=A0 =C2=A0 vhost-user: implement VHOST_USER_PROTOCOL_F_XEN_MMAP<b=
r>
<br>
=C2=A0hw/virtio/trace-events=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=
=A02 +<br>
=C2=A0hw/virtio/vhost-user.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 120 +++++++=
++++++++++++++++++++++++++++++++--<br>
=C2=A0hw/virtio/vhost.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 18 +++++++<br>
=C2=A0hw/xen/xen_stubs.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
=C2=A0 =C2=A05 ++<br>
=C2=A0include/hw/virtio/vhost-user.h |=C2=A0 =C2=A02 +-<br>
=C2=A05 files changed, 143 insertions(+), 4 deletions(-)<br>
---<br>
base-commit: 30e8a06b64aa58a3990ba39cb5d09531e7d265e0<br>
change-id: 20260618-vhost-xen-foreign-mapping-d023c85bb706<br>
<br>
Best regards,<br>
-- <br>
Dusan Stojkovic &lt;<a href=3D"mailto:Dusan.Stojkovic@rt-rk.com" target=3D"=
_blank" rel=3D"noreferrer">Dusan.Stojkovic@rt-rk.com</a>&gt;<br>
<br>
</blockquote></div>

--000000000000664b2706594d7e05--


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:48:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:48:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393577.1632397 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEYE-0000yB-2J; Tue, 18 Aug 2026 07:48:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393577.1632397; Tue, 18 Aug 2026 07:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEYD-0000y4-Uw; Tue, 18 Aug 2026 07:48:01 +0000
Received: by outflank-mailman (input) for mailman id 1393577;
 Tue, 18 Aug 2026 07:48:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwEYC-0000xk-Js
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:48:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEYC-00EHbw-0h
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:48:00 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a840e18-e002-0a2a0a5209dd-0a2a45059300-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:47:59 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a840e2f-4cb1-0a2a45050019-d1558036b5ff-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:47:59 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-49557167508so43530815e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:47:59 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b81715sm9961205f8f.35.2026.08.18.00.47.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:47:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787039279; x=1787644079; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=X73KZPwR54w6SuQCuwA1xe8PBoemaZ6s6A+rL8ZkOhI=;
        b=Mp1z/dmnTu+KZrGS6AL3d85tIw5l4xuckvmPsuTJVS+0ObVLJd+sb9/3A8Ah2yBDo1
         s1tr2wtSBD0WNOOFW3QYNNCTPeLeYIno1jQvKK+3ywi+pXNYePZwnQZnqDEXGMfI1PL0
         0erDZnv8lltR8aplFrMak11Emf9sDO3F1q6Rxj51o5g1nqdc4Ke3RzjBwbVPvG7qDKm7
         Et0HZyA/rD5WF2qQ/ATTtD/TN4EOMowd+L6RAdNvsdIIjD2TItWsN2fm61yv0JX1bbW2
         7Vo/1zUc1OqqJV0KzQfoyOpVffLVQr3NsjK+8IY+GsqhfwNdwOkgu9Hdcg4DXAspW3BF
         7r2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787039279; x=1787644079;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=X73KZPwR54w6SuQCuwA1xe8PBoemaZ6s6A+rL8ZkOhI=;
        b=OcOTmxCcMM8ooAcFrMEfMn7fI7Fy+kNyn0jayeHs0hJPc35Qf3n8qLRLftvoL8+bck
         p/tJOva1El+n+S1sqdW/MlGAwOxjHBGSrsXn49hSECilVziuu2y577jB4BIUuD5DrzoC
         XCFA1qrLbMhWZ4v12xAGKg/VAcrST29DR0pdc7xy6yFdpIxIhHydBrMv8Iw5xSUDR/j/
         l/ZjhUuJgl2lA4pUdtANzUD50x5dpPplxt1fVv7F26/ngXMjGO1Aab9r3QxERTSWjglC
         +ZB6OLGsOZuT+pDcBQ6beChzj2hLEiVLk0RyV7DuLAIcXzEQXBihu3fCojtmW2PwBkQR
         VOAg==
X-Forwarded-Encrypted: i=1; AHgh+RpCUY5bAXeV+gnY8sk5fILZmwk9g2aQOLUibe3OWTKpyGUAg3E9guKFkb6Y//g5+JGKL3Y5GSPmyXU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyF63skaGomXwG4R3DFMCKVmX1nCAyLk1AlA5CMi9ZbtOK15MCz
	myhzOvLtSriEVr+P1U9gu/BiFKZ1ZqWXeldt1s8ZXfH2ri5Oee5ZWUTf
X-Gm-Gg: AR+sD12Up3ClvL3uHpe0HpZ9eE1rH9gqdH2QFyzIFH+TYD5QGRpPcgo+VTAnpdK1hxg
	q8BGzfRLSe1qF78GVUW4VvO44ffddAgrT9vC2Pq4r+hUxve9rzf2VF2BDu5iMZ/hHLmHd7fQObi
	GHUcklfKhtTCqIbjzXi8eJrLvF64NjpAj+vGL1MxXrKIkAtp8vtNAborm57KYdsS0NFrALn1zII
	H6g1PeFKiCL9vqM0JBvRs7lhK14FNj2JggX5YbpFMeO5qIHZaKtOFPDsA1+qMuVmwhKyNXK+93r
	zNkHY3I5kckID3kQMKLlpuTEDGWMApJOZ6X+M/iizZYbyQPyBed4ij3W7Rz5SdcGF0xGysWFS2g
	mn3Vn29jfZRPWkjGP/ceCRer0CLhYnR9nudvpRs9TOjqytZUnTG9GSg+/Wy3D47E5lbRXrVmPxm
	xMp/BoSMPmWTrkvo5frsMDn3Eu+hBae21WmCsoqczDs0sXn3Dl1WJdyP//LXSwTEkcR2OVkjzJy
	+bJ+mOdUJG7hTHJWnnISurJGJckRaP4Qji+56Y/Y4As
X-Received: by 2002:a05:600c:358a:b0:496:c06b:9fb4 with SMTP id 5b1f17b1804b1-4999fb940c5mr104040705e9.14.1787039278885;
        Tue, 18 Aug 2026 00:47:58 -0700 (PDT)
Message-ID: <41c9717f-6083-4669-8e60-20a023c3ae8f@gmail.com>
Date: Tue, 18 Aug 2026 09:47:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 15/17] xen/riscv: implement trap redirection to a guest
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <8b14a7926e42c7e3308dc7f730334fed56210d81.1784560663.git.oleksii.kurochko@gmail.com>
 <f3ca2cf9-49b9-4515-b634-6de4ae9614ce@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <f3ca2cf9-49b9-4515-b634-6de4ae9614ce@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787039279-24B1D2A1-C778888E/10/73395122804
X-purgate-type: spam
X-purgate-size: 6422



On 8/12/26 6:03 PM, Jan Beulich wrote:
> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>> Some traps taken by Xen on behalf of a guest can't or shouldn't be
>> handled by the hypervisor and must be forwarded to the guest's own
>> S-mode exception handler instead: e.g. when riscv_vcpu_unpriv_read()
>> faults while accessing guest memory, or when emulation hits a condition
>> only the guest kernel can resolve.
> 
> Is the plan to use riscv_vcpu_unpriv_read() also for reading hypercall
> buffers?

Yes, it could also be used to read hypercall buffers, but I don't think 
it's the best option, as hypercall buffers could be larger than 8 bytes 
(which is the size supported by the `hlv` instruction on the RV64 
platform). For that case, I think it would be better to map the Xen page 
corresponding to the GVA of the hypercall buffer and then use the usual 
memcpy(). So, basically, use copy_guest() on RISC-V for that purpose.


> In that case trap redirection shouldn't come into play.

It isn't mandatory to perform a redirection in the case of 
riscv_vcpu_unpriv_read(), so if trap redirection shouldn't happen for 
hypercall buffers, then the caller of riscv_vcpu_unpriv_read() needs to 
handle that properly by checking utrap.cause. Something like:

```
     *insn = riscv_vcpu_unpriv_read(true, regs->sepc, &utrap);
     if ( utrap.scause )
     {
         ...
         utrap.sepc = regs->sepc;
         utrap.stval = utrap.sepc;

         riscv_vcpu_trap_redirect(&utrap);

         return true;
     }
```

So, if this cannot happen in the case of a hypercall buffer, then we 
need to return -EFAULT in the if ( utrap.scause ) case.

I don't think I understand why redirection shouldn't come into play. Do 
you mean that the hypercall buffer will always be available, and that it 
is impossible for the hlv instruction to fail, so there is no point in 
handling redirection at all in this case?

> 
>> Introduce riscv_vcpu_trap_redirect() 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.
>>
>> 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.
> 
> For this last bullet point - how is a reviewer supposed to validate the
> assertions added when no caller of the new function exists?

My bad (again). The caller appears in "[PATCH v1 16/17] xen/riscv: add 
guest load emulation for trapped MMIO accesses" (as you already know) so 
I have to re-order patches and put this patch after PATCH v1 16/17.

> 
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> ---
>>   xen/arch/riscv/guestcopy.c                | 54 +++++++++++++++++++++++
>>   xen/arch/riscv/include/asm/guest_access.h |  2 +
>>   2 files changed, 56 insertions(+)
> 
> I don't understand this placement - trap redirection has nothing
> (directly) to do with accessing guest memory.

Agree, at some point. I put trap redirection there as the idea was to 
catch trap from hlv{x} instructions and redirect some of them to guest 
so I put it to guestcopy.h.

I will put inside traps.{c,h} instead.

> 
>> --- a/xen/arch/riscv/guestcopy.c
>> +++ b/xen/arch/riscv/guestcopy.c
>> @@ -205,3 +205,57 @@ unsigned long riscv_vcpu_unpriv_read(bool read_insn,
>>   
>>       return val;
>>   }
>> +
>> +/* Redirect trap to Guest. */
>> +void riscv_vcpu_trap_redirect(const struct trap_info *trap)
>> +{
>> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>> +    unsigned long vsstatus = 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 &= ~SSTATUS_SPP;
>> +    if ( regs->sstatus & SSTATUS_SPP )
>> +        vsstatus |= SSTATUS_SPP;
>> +
>> +    /* Change Guest SSTATUS.SPIE bit */
>> +    vsstatus &= ~SSTATUS_SPIE;
>> +    if ( vsstatus & SSTATUS_SIE )
>> +        vsstatus |= SSTATUS_SPIE;
>> +
>> +    /* Clear Guest SSTATUS.SIE bit */
>> +    vsstatus &= ~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[1:0] is the vector MODE, 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 = csr_read(CSR_VSTVEC) & ~0x3UL;
> 
> Can there be a proper constant please for this mask?

Sure, I will introduce one.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:53:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:53:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393587.1632405 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEdF-0002Yv-Jl; Tue, 18 Aug 2026 07:53:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393587.1632405; Tue, 18 Aug 2026 07:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEdF-0002Yo-G0; Tue, 18 Aug 2026 07:53:13 +0000
Received: by outflank-mailman (input) for mailman id 1393587;
 Tue, 18 Aug 2026 07:53:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwEdE-0002Yi-2a
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:53:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEdD-001YPy-Ba
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:53:11 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a840f61-e002-0a2a0a5209dd-0a2a450b9e8e-18
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:53:11 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a840f66-b7e8-0a2a450b0019-d155dd31bd50-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:53:11 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-4798bea72f9so2750211f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:53:11 -0700 (PDT)
Received: from [192.168.1.109] ([88.230.46.229])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783d1sm10117598f8f.25.2026.08.18.00.53.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:53:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787039590; x=1787644390; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Xr4ZfnWKD0xKIkpYtFflfHg4lC9aGjmdM+QlqFxml/c=;
        b=Jsd+3OithwuQMTCdZyrwFsphm0O3o2JU38M3oNF5d1gjj/TawbwGuW3EzUhTw2oY/x
         VcAWC5OxIBgr1SSqH9oeoDk6Y81TvKyPw1bkiv4ogTJMZaUMj3tnfaZooXGdhdRKWoik
         WCoYGB+z6pXSn4sinypXMrhrC/5+Jlgsi7LVqxDDo5T/Gwj+XtZ6a33SPqyjuXnBSTPb
         Os0IWhZpL817X9J0d0pF/nyeK9xYSH0Rsr28Z7+anwYeNbkxJtQPKvBLGtLlvxuBRnof
         wf91kBJp8vb6ssvDnY4/U2GEYl0zELQ/uoKKwkv7RX0R7MfdYjA1LiF6RwUwPWy31bW6
         sixw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787039590; x=1787644390;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Xr4ZfnWKD0xKIkpYtFflfHg4lC9aGjmdM+QlqFxml/c=;
        b=Qikn02Q81ctk/iNZBruMFotmpFdQTFx6KRv/EmgN0BRpq9Lt81oaxleq7T8jzf6L2u
         pao8ZaaZGplQrdYQcoDPiXSxvR99dMzUCk19TPxZLZOGk2X+zKr6LinRJh/Tk59C24Zn
         4P7p7aFva8dS0p7xN5gZZXltHkmLc/EDLa8/F312tD9+ixZWNHnBI7xGJo3UYu///B1l
         SPx+TEJln/97p7wmY1jK7OgGQf7QisrKuUZ9kYiiUldkT5wgi6pssa4SaXZcu4ZXSHkc
         T1FLi/Wl8cjrWZZbMOcBPpsKJJFHOKKMOCUFPv2rF4zayVo/C0mQm8xLhzNHzKcCkU6L
         uo0Q==
X-Forwarded-Encrypted: i=1; AHgh+RrMrSO5EcTb55+L3kLLxMa5kzyKq+CLGE8n8uSziHLRHIxdx8WzPcKvAhe943cO8lR+aZbRRwPRAcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwO6PFLaq78YHbuA91VPx+Y2EmI14IMToZMmkH/c0h8h8KS37uT
	6Qz08kZcLQ0tkyc4MddEHhuh1bcmFTeaKTToJeZTk6PiJt7RsEqDaP24
X-Gm-Gg: AR+sD10whmOAkcy+0hlGxDfuXzyJVJigvbei+X64iwUr+/3gOfy4cN3uAKyNshIQX69
	PAEL9hcpLrUN+B9mPOhAN5TX4aHbjRybr9pFmVpXIAgnaCRjJlsvOU1nSQNGgAau6BXM3kDXuVq
	2/08NhBQT/hrRMyaTlPH/4YVb4O2WFKwGAdW57yu+WtE/FzUEsii3JHoUKZQ31FuPUd8e4wdcQS
	1CJzNRFEcKBitPsvXu5b6+MiPMnRwz1JToZZLSjPsxfyV5ZM0o/FkmFI0LZycsh9gugQbrB0qrK
	kUWGB9T8knMGBmxlBIF7500CtwxcICU/69KaMZU2bP8JSE6u0sExj7gemm8AYCnmY0hbQXJd7fn
	koluGLqxHR2q3VvROm0M37vliInCBLYwWs2Yq260bncF4Z2YcNysJcBPe3wN1jUPw27+cHtLps5
	ESxw/JK3rMfC3YueIQjJVe+He0si5czYbdk6BEwnb0/85Mh+EmGZHtikbcl0Cam8zO/Rs=
X-Received: by 2002:a5d:500b:0:b0:47f:e797:41c8 with SMTP id ffacd0b85a97d-482a905d127mr7938655f8f.4.1787039590321;
        Tue, 18 Aug 2026 00:53:10 -0700 (PDT)
Message-ID: <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
Date: Tue, 18 Aug 2026 10:53:06 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787039591-A84CB9EA-21286693/0/0
X-purgate-type: clean
X-purgate-size: 3710


On 8/18/26 10:11, Jürgen Groß wrote:
> On 18.08.26 08:32, Furkan Caliskan wrote:
>> sched_move_domain() derives the number of units to rebuild from
>> d->max_vcpus, which is fixed at domain creation and never rolled
>> back if vcpu_create() fails partway through building a domain. So
>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>> counts it - this happens if sched_alloc_udata() returns NULL.
>>
>> The per-unit loop doesn't check for this: it sets
>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>> unit straight to the destination scheduler's alloc_udata(),
>> which assumes vcpu_list is always valid and crashes Xen when
>> it is not.
>>
>> Reproduced by building a domain in a non-default cpupool where
>> vcpu creation fails partway through, then destroying it.
>> domain_kill() moves the domain back to the default cpupool via
>> sched_move_domain() before actually destroying it, crashing
>> inside the destination scheduler's alloc_udata() (seen in
>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>
>> Before building a unit in sched_move_domain(), check that all of
>> its vcpu slots are populated, and skip it if any are missing. The
>> rest of the function walks the vcpus that actually exist, via
>> for_each_vcpu() rather than n_units, so skipping a unit here
>> does not leave anything else out of sync.
>>
>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>> ---
>>   xen/common/sched/core.c | 19 +++++++++++++++++++
>>   1 file changed, 19 insertions(+)
>>
>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>> index d3a0a97e1d..d542c76543 100644
>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>>         for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>       {
>> +        /*
>> +         * Skip this unit if any of its vcpus is missing. Bounded by
>> +         * max_vcpus.
>> +         */
>> +        bool vcpu_failed = false;
>> +
>> +        for ( unsigned int i = 0;
>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>> +        {
>> +            if ( !d->vcpu[unit_idx * gran + i] )
>> +            {
>> +                vcpu_failed = true;
>> +                break;
>> +            }
>> +        }
>> +
>> +        if ( vcpu_failed )
>> +            continue;
> 
> I don't think this is correct.
> 
> If there are some vcpus in the unit you will loose them (i.e. make them no
> longer be able to be scheduled), right?
> 
> For a dying domain this might be okay, but not for one still active. So I think
> you should at least verify the domain is dying, otherwise sched_move_domain()
> should just fail.
> 
> An alternative might be to fix the NULL dereferencing where needed, but this
> could become tedious.
> 
> 
> Juergen

Right. My initial attempt only checked 'd->vcpu[unit_idx*gran]'
for the head vCPU. The crash happens when unit->vcpu_list is set
to d->vcpu[unit_idx*gran] (which is NULL) and passed to 'alloc_udata()',
causing a NULL dereference. 

I expanded the loop over 'gran' to handle core-scheduling cases where a 
subsequent vCPU fails mid-unit, but as you pointed out, that drops the 
whole unit for active domain.

I'll update the patch to check d->is_dying to skip incomplete units 
only for dying domains, and have sched_move_domain() fail if an active 
domain has missing vCPUs

Furkan



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:56:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:56:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393594.1632415 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEg7-000356-W1; Tue, 18 Aug 2026 07:56:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393594.1632415; Tue, 18 Aug 2026 07:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEg7-00034z-Rf; Tue, 18 Aug 2026 07:56:11 +0000
Received: by outflank-mailman (input) for mailman id 1393594;
 Tue, 18 Aug 2026 07:56:11 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwEg6-00034t-UL
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:56:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEg6-001oVA-Aq
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:56:10 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841002-bab6-0a2a0a5309dd-0a2a45078cbc-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:56:05 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841014-b4ea-0a2a45070019-d155dd29e83f-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:56:05 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47f6609c657so2067045f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:56:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b77fa3sm9639633f8f.26.2026.08.18.00.56.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:56:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787039764; x=1787644564; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=zXEcZZ29k+TvYgFCA8ciZUZEguthu2ZUBj81fxlkawM=;
        b=Y3VBxJXf3gN0wAz7XUeiPBaWvkBu1K97eWZm4u/3CBY5/Wt+1npLVQ3bX8q3kt6lj1
         iLo46s56w2NrPFMmE5d/sMci+k3TgwADwW7A/ERI/0TXCngT1I9nFX2pnW6mTzI0kuBm
         /ToRdP9/bsfFwx3dFNMZUt1Aq+nRfYZLstt1KEII0PDLAujXajOYbRqnuvGiMD6teuBo
         iIAPRGvn9OOd9jKp4iRU5eX5Yw6tMkg6xxYA4byIilxnnHfpRaWuS52Yx0ubknvGYC00
         ++oe1gaCzNjWbPgKCZHdATH5BfjSq69ea+wMcHyO8hbo9v941timHmd7yTdEzAd04JCx
         ZAnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787039764; x=1787644564;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=zXEcZZ29k+TvYgFCA8ciZUZEguthu2ZUBj81fxlkawM=;
        b=SmSZbhCd+mq0JUMGfL8xJm2/NvX7/r3qmgE1VRqUo6xIe3oxt8T6IGqjuFTE30jOMg
         UWYnPZW5hlHHwl7c9p75/KKN3DC0xxrqBWp3puXwcetlJj8NxEOSEE5ZhEkiodJq+lXz
         KZNfGmwdTNqddJ6Q4x5KU7Km6IaEyvyJUWkNpJfry1hdQs5FoGxD7Fbq+yEMuVw30iBw
         HzaQtV+fualRJ0b8qsFXiAk9m6q0Pr5Xa94mtBQhnLnLvGOdUE6orWVil9MPjBIIQyN+
         DnDkfJrgk1ho1XGdVYJ68TPG/arFo3rdpRwnjI6frAdAMoxG/Mothvu6RdgjtZn93qbQ
         5Iow==
X-Forwarded-Encrypted: i=1; AHgh+RrOKBu6K1ax5ZeuWS1r5oqFpU6Z02woYbCIkBCU+nO5YPQNYkNYEhbR60qRQtR/3Uwu6PTknkMCYMA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydBfL1MIAyfzvy8aWYUDhZJIHJG7+2BU7sIoZeACnDzQGESoLT
	nWbG26jmC13p2LyAZk7XN6DEm9cmaQD7CXAh5AITw32Qaigw0xSujvtlzuQ1SEH69A==
X-Gm-Gg: AR+sD10wrEPw1O3AHn1coNZwazEcnWGr1kY1dQcAsx5bMdKY5unBJrb/QG5DCa2v79D
	QhdP//3EipresN77sGizoTsoP0XQtyx7xV3QNoecAkEEGfY4xbTz5t87kJyhfb9ZYkjPyPEHmAP
	YooodAOe8p9QQJ1cZcU2lBszN5r3Kit1WXeV0Vyq8V1uPX7Q7Uu7BdOiab58+0Zinlj28/v48lq
	7OA6wD270oIYXItn2fpYivcC0LrOJCmbs2H7Op56dvOqiJNY933HSniWOYGAtJ2cxGUsYFNXi6g
	5D11yvQ6uWA2SawbsFqjIChH+w/rkfDHpvGiZWlCURwQtxJwU0/o6qROSf8BS0v6fNcrwS509YR
	NDZFXCWb9wvDVx7bpzTtcQXVPDU/xCNaRhB/Uac5nHyRxmY96AUwQWdB9/52SVvXuVzWQQkOKPY
	VbyyEZBTic1xOIO/oPQR8XCs7nOVbedCkBgtzWgLH542OGNpHjDDcxADY1MXr8h15srz/k9/AO4
	LE69CJiV2olYiJ9veGzxeT9HIgQQuQojktiGSQMPtIbqllRsPDX
X-Received: by 2002:a05:6000:410a:b0:47f:8b2c:3d98 with SMTP id ffacd0b85a97d-48160723cd4mr47724056f8f.4.1787039764518;
        Tue, 18 Aug 2026 00:56:04 -0700 (PDT)
Message-ID: <b8b794ec-c86a-4a82-9d3a-b3ffcaa802f3@suse.com>
Date: Tue, 18 Aug 2026 09:56:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787039765-352CCAE4-189113E2/0/0
X-purgate-type: clean
X-purgate-size: 4888

On 17.08.2026 13:33, Oleksii Kurochko wrote:
> On 8/12/26 4:37 PM, Jan Beulich wrote:
>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>>>       regs->sepc = ex_fixup(ex);
>>>   }
>>>   
>>> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
>>> +                                         unsigned int offset)
>>> +{
>>> +    /*
>>> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
>>> +     * laid out at the start of struct cpu_user_regs in architectural
>>> +     * order.
>>> +     */
>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
>>> +                 sizeof(unsigned long));
>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
>>> +                 31 * sizeof(unsigned long));
>>> +
>>> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
>>> +        return 0;
>>
>> And an offset not divisible by sizeof(unsigned long) is okay?
> 
> No, it isn't okay. I will apply your comment ...
> 
>>
>> Returning 0 as error indicator also feels fragile.
> 
> With what I suggested below returning could be just dropped.
> 
>>
>>> +    return *(unsigned long *)((unsigned long)regs + offset);
>>> +}
>>> +
>>> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
>>> +                                 struct cpu_user_regs *regs)
>>> +{
>>> +    struct trap_info *trap_info =
>>> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));
>>
>> Related to the earlier comment: Simply pass just ex->data here, leaving the
>> multiplication to regs_get_gpr()?
> 
> ... It would be better to move the multiplication inside regs_get_gpr().
> 
> Your comment made me think about whether the multiplication is needed at 
> all (regardless of where it is done). In other words, ex->data contains 
> the register number, so we could just write:
> 
> static unsigned long regs_get_gpr(const struct cpu_user_regs *regs,
>                                    unsigned int num)
> {
>      /*
>       * The GPR number -> offset arithmetic below relies on x0..x31 being
>       * laid out at the start of struct cpu_user_regs in architectural 
> order.
>       */
>      BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) != sizeof(unsigned 
> long));
>      BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) != 31 * 
> sizeof(unsigned long));
> 
>      ASSERT(num && (num < 32));
> 
>      return ((const unsigned long *)regs)[num];
> }
> 
> Probably, we want to consider this function out of context (for now 
> context is that we use it to recieve a pointer to trap_info which can't 
> be obviously stored in x0 as it should be always hardwired zero). In 
> that case, there is no need to check that num is 0.
> 
> So, it probably makes sense to just have:
>    ASSERT(num < 32);
> 
> ASSERT() is fine here as I don't think that compiler will use incorrect 
> number during register allocation.

I agree.

However, the x0 aspect is still odd. Why again is it that struct cpu_user_regs
has a field for it, when the register value is always 0? (And tangentially,
what's the pregs field there, and what is stack_cpu_regs?)

>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/gpr-num.h
>>> @@ -0,0 +1,33 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef RISCV_GPR_NUM_H
>>> +#define RISCV_GPR_NUM_H
>>> +
>>> +/* GPR ABI names, in register-number order (x0 .. x31). */
>>> +#define GPR_ABI_NAMES                   \
>>> +    zero, ra, sp, gp, tp, t0, t1, t2,   \
>>> +    s0, s1, a0, a1, a2, a3, a4, a5,     \
>>> +    a6, a7, s2, s3, s4, s5, s6, s7,     \
>>> +    s8, s9, s10, s11, t3, t4, t5, t6

Having looked at struct cpu_user_regs for the response above: How is this
macro intended to be kept in sync with struct cpu_user_regs? Yes, the ABI
isn't going to change, but (a) still and (b) if later another ABI was
introduced, names here and fields there could still easily diverge.

>>> +#ifdef __ASSEMBLER__
>>> +
>>> +    .equ    .L_gpr_num, 0
>>> +    .irp    name, GPR_ABI_NAMES
>>> +    .equ    .L_gpr_num_\name, .L_gpr_num
>>> +    .equ    .L_gpr_num, .L_gpr_num + 1
>>> +    .endr
>>
>> So this is emitted no matter whether a .S file actually uses any of the constants.
>> Perhaps okayish, but somewhat wasteful.
> 
> I can move #include <asm/gpr-num.h> inside "#else /* __ASSEMBLER__ */" 
> in asm/extable.h and it will be enough for now. Or just drop declaration 
> of .L_gpr_num for assembler code until it will be needed by it.

How would either of these address the remark I made? Not every .S file
including asm/extable.h will need these constants. Imo this new file wants
strictly only including by files which actually need .L_gpr_num_*.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 07:58:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 07:58:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393604.1632424 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEiI-0003rz-Cv; Tue, 18 Aug 2026 07:58:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393604.1632424; Tue, 18 Aug 2026 07:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEiI-0003rs-9G; Tue, 18 Aug 2026 07:58:26 +0000
Received: by outflank-mailman (input) for mailman id 1393604;
 Tue, 18 Aug 2026 07:58:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwEiG-0003rm-Gg
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 07:58:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEiE-00EJb1-OX
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:58:22 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84109e-bab6-0a2a0a5309dd-0a2a4509e082-2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:58:22 +0200
Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84109e-be1a-0a2a45090019-d155dd30b05b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:58:22 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-472326ca506so3020633f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 00:58:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783c6sm10571925f8f.31.2026.08.18.00.58.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 00:58:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787039902; x=1787644702; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qEAPiSMgkMnRLHoTW3o1ymMnjgIDMjAExbQhjcPQ0ZM=;
        b=LvkoNKuQl2csWdShj69tqMKdnqR92MbI9xDGWf6PQjk6MSvb+5a4ldEjXcfGZKZj1e
         U6mUJ/LbgC7BTinOWRw9vSLzdoFQmOjLXRo+XhK9Vx2q/tznBpOUaD7SPBMqrSUn6mzg
         0KE7O47YR63ilYAqTc6mIFZN9V52M8QccFxEhjWz37g8rhGUDJrWH+Q73IApKdWEzAmH
         Yw9vnYWjJx2DDTYgsZfZVUwA6T1RNHStURqBnNscxhAwT+2JHsPbjrOwvh6ntNXMSWrP
         mDjABgM5tjmM28UxkUF0991fRjgjkCMJUwDlFfkGsA6Gv48XhF/6pabS+96CkmgtSJph
         9zgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787039902; x=1787644702;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=qEAPiSMgkMnRLHoTW3o1ymMnjgIDMjAExbQhjcPQ0ZM=;
        b=GKbqE4B6gq+vDExnFWdD3/9N3PvYB0uer2QLidwm84LhjozXkXH2rx/oCGZqmIVuGb
         6HV1CBPGAydqiQxrO15TI7u2AV4J2ApTSAvVkyDpZ4s7rXmymxFfVykCfVTB9PxezvKC
         HokAK/JLYf7bGIO67+8KAk2iL9SVlIWKZnK84bl4tDRtRlGu1lADFtjFLTtJiPIFktWI
         dgLkdi4/OjkgLWDBDbmkQMUoDcPdNK8Sd69J77NyZl3hZAJ8B52mmzFp1RowEErpDQkl
         8DjibUqN67Es/ItgBelOs1x6ynb0lYlYQNUsUlwTTddsCjBR/LkKdHR6Rqs1fH/HIBjx
         gv5g==
X-Forwarded-Encrypted: i=1; AHgh+RrSkXAx3cloiNTFIsv74PGUaFOovnLYqbP4ALYtt169IM+DX+gc2S4c/LGXlK2EZqV1J+dC+N13Zfw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyocl8YYuWSya5LWdPWk89RohvsZfLBmHqxmU0mBm3WeW14R/Mw
	zcD5bl4WvbjmBYBzslTBrPr3VpFoaBtqoUDfC5NPnFRvruu3Dy3SniJbmvJ2iihukA==
X-Gm-Gg: AR+sD10jqAwKiW47SIxlgyBLSORdJbPlCoQwBNNI7dKaO4slPl0rDQnym3fNGlmjqiW
	8fggB65yByWYxRY3+l/EBTO/eqxBHXy4ly2USyR77Z4hdlzCeY8WPLEYqFtfVAzJur+v+MxGFVZ
	O0Qa1FHFwYQpFfRnJDNVHgutmbyLvZQfS6f3vmNWalzUe7JDDL02/lWW9vgV4lfcyj8GRYrqjGZ
	rO2PZkn3LX2LpQnaD7ApOs0b9mh4noOH0s4OyWKFw53t1rdCiimjuzo4FhVzPEEXxZyrMQjLJ2M
	n4KodrbUlRRGHoWXY8oSvxGlGprnuBc4niau93UMwIZTCTw74Z5I1AzQESMSGkKSXYp51juNGG9
	GSd/v+nHjnrhBnjsMZQepPjXHoqQe/ejN9v1P8sfpxXiJPQfGhAr85iOqQ2E58SbcLHDrmK0dfz
	1dtxpLO0E58ePa97AE/hmenNMW2x/EbBVDl0zj6nZScUoxY2OxWK48FYhazS3z+Oki6aeGGqAaD
	KOgEOfjYUFrLwud6XzztUpdDow4ENjYc2/WddS6S8DGyPfEQfJG
X-Received: by 2002:a05:6000:288d:b0:47f:9de0:c27f with SMTP id ffacd0b85a97d-482a8fe9b80mr10234019f8f.1.1787039902023;
        Tue, 18 Aug 2026 00:58:22 -0700 (PDT)
Message-ID: <eeedd10c-0c14-438e-a48f-05383ba49ec8@suse.com>
Date: Tue, 18 Aug 2026 09:58:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
 <87339fc0-fbf7-44eb-8b08-cc95ac7d1cb6@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <87339fc0-fbf7-44eb-8b08-cc95ac7d1cb6@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787039902-3A8D9034-B4CE8CD4/0/0
X-purgate-type: clean
X-purgate-size: 719

On 17.08.2026 13:39, Oleksii Kurochko wrote:
> On 8/17/26 1:33 PM, Oleksii Kurochko wrote:
>>>
>>>> +    BUG_ON(!trap_info);
>>>> +
>>>> +    trap_info->sepc = csr_read(CSR_SEPC);
>>>> +    trap_info->scause = csr_read(CSR_SCAUSE);
>>>> +    trap_info->stval = csr_read(CSR_STVAL);
>>>
>>> Do you really need to re-read all three registers here? Didn't you 
>>> read at least
>>> scause already, in order to make it here in the first place?
>>
>> Agree, ->scause and ->sepc are already read.
> 
> scause should be re-reaad as we don't save it inside cpu_user_regs 
> structure.

It could be propagated as a function argument. Question really is how
expensive these CSR reads are.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:06:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:06:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393622.1632432 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEqE-00063J-Jx; Tue, 18 Aug 2026 08:06:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393622.1632432; Tue, 18 Aug 2026 08:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwEqE-00063C-HH; Tue, 18 Aug 2026 08:06:38 +0000
Received: by outflank-mailman (input) for mailman id 1393622;
 Tue, 18 Aug 2026 08:06:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwEqC-000636-OE
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:06:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwEqB-005Nw4-CM
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:06:35 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a841288-2eae-0a2a0a5409dd-0a2a45058dcc-24
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:06:35 +0200
Received: from [52.101.65.121]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a84128a-4cb1-0a2a45050019-346541799ecd-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:06:35 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS2PR03MB9718.eurprd03.prod.outlook.com (2603:10a6:20b:60e::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.11; Tue, 18 Aug
 2026 08:06:31 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 08:06:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I6pnMfeYzqnzCwh6gW0tsfRXYO4z8VAcNZilznoP2f0WuD8IPz8ArmajvJyFrRAAvw8gWtXb/BJb0nT/s8ZFn1afWSYRT/pXgv5ItF7oxLUagDnzGkB2rafIGU0IWEcclJ48XmO5ye9XIM6kFd8Dper8Gck3Va25PEp1H9LFCJ8U5+RD0D+wz+Ik/KYvpzqJIWQlhpuRn1kxWOiDcMfPhDOn6dXvQNexYOFRYAJrL1Q2j0oeR1DBhcjTnEN61pt8eXjDq5+JNuUG2ElmdyQNq7hKjZL4vrRHhnG0QbI5ofBeoi6iSNlc1F73ZSAG2m49m0DixGswvEXhIp9+OYbwUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hoz66d29gEfg8FYdfnppGP8J19Tvl/1HF1J4mYAvfgM=;
 b=A71ICOhdI2jw0tpatMjxdzIK5jajER18NIO3rLIGBBEMPsLwRJgIpviogJ1P9XtkqNKBNmb6JnFJ7sIoG0QkvAseZcDF8SB3jf3C2jBvjuK92XKQAb7SgUoIbYvPbHvS/hCM/IcPdqO+fedLq7p9k7bpbcIhuZjp4kBEbZ3meIEzwesD+6i0u8XRwCWmJjrq1Ps+/JVprTvQUfmYA+Fev7wazgNo3fjPXYMUgZSLKRFJd5Sn1xRFXvh8O6P9PnQQWZjqjDE6JUz/O1LKrPsTzo5wgz2mA4uqaaMbQ2lN7G2QhAP7DOACJeON7b+YTTon78dfRmsKUVjHcufEdkesiw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hoz66d29gEfg8FYdfnppGP8J19Tvl/1HF1J4mYAvfgM=;
 b=Vyg7YtVBlc+nXofpX/MBMb7sw8w6crCpSRYx8I2J87PG/R1J+AuoY0GVwjQ/DLkhLdYMqlr9Oh5XJZC95390cPJIGhSBYcmbjosRUY5P2p5s8Qq7o3d+pgAdNeuyJooU63EDY49yOGQ9i5CQB2Jd82tx7YqGh0TMiTnPdvhrBJdelCEfNy8LWHJ6gnAKFIGkAgqIDJkU974qLvN2MV2ZfquLl1KFmyScybW+69kQrQ7Sj3GiK3xFjevQJK1oTtIGUVNjHdK7QJK2w2Mpic7vU0pvzdB38vmUmJ1bhquPVqfjQJF8TQJ1UEOyl5zKaow61BTFaCsgBLhFbKeD4PxWqw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Date: Tue, 18 Aug 2026 11:06:27 +0300
From: Mykola Kvach <mykola_kvach@epam.com>
To: "Orzel, Michal" <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2] xen/arm: derive GIC CPU interface ID fields from the
 vGIC
Message-ID: <iutqzuknxgblhw4j77yuoapsmvcsy2gwhbolslyfvkvsm6uc4b@b67uc7ri6pdd>
Mail-Followup-To: "Orzel, Michal" <michal.orzel@amd.com>, 
	xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>, 
	Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <f46f9e6ebb12d8402fa72b1641796f33e24c539f.1786395761.git.mykola_kvach@epam.com>
 <103a2e50-0391-4bad-b9e7-d00c36c76a54@amd.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <103a2e50-0391-4bad-b9e7-d00c36c76a54@amd.com>
X-ClientProxiedBy: WA2P291CA0016.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::12) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS2PR03MB9718:EE_
X-MS-Office365-Filtering-Correlation-Id: 31f90dc4-264b-4beb-92fc-08defcff9cff
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|6133799003|4133799003|56012099006|5023799004|4143699003|22082099003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	PRCfCr0/xCV31gh/qK3LD7c1xUxiB9FdhDAjweoA4bqeoQEmun7O9obLecL7ZGJmJ8If8CHKLKHwz8olLOHjLcTMrdQM20wGYiHjKxBYucGKy6sJu8zeeGH2tKzP6CBTLmfW0Lfl1GegjgbG4gJ+h2olJnMmNUUPppezIdHc+H2jjPfWHCHEj7kGmZdHVNJdJPQ71zuEslO1kcVJuE589nu24WQ3WyCQdwZGEulXgy4bM4mIf03iJS+MsSZMUkCmCc4aGmJ0CvLPXx7k9RZJIhSuzMrYaUN53X5djkbQUSFjewoaC41wbVjxJzeVvrqKm4Fo8b4Ars6k0mcQKfsckX0kAClDEZAgKbzdhkYYGJPLfr+yPywXX5IrUP2a1tp+tHlfJbtOHh0BNkYtqEgMJZniDOV8T4WBeNSxb13bUGawDgdy74cnatxGg0DJCjIfN+cToQ8Fhq5crSFz+KKNon/8p3vmqk56th4Uujp5A6akbEzlhehwq/uzvNqXXQbRbQha0GRdFGvWDx7GttNvrQ67p3cC9oxAg2Hu8alFoelJk7wh7IaS+K6GtIyTZI0D+keWL0S1tR6aXJ3XGEeQvsfOds8e3+8FEgXtp9F1a8A06ucy9kztOVoJBedum3fq
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(10067099003)(6133799003)(4133799003)(56012099006)(5023799004)(4143699003)(22082099003)(11063799006)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a05zWVF4UEczVXdXMFUwakYzQ3NSV3VhLzMwMDRFT1pHaHpVVDNZNlZoYk1U?=
 =?utf-8?B?Nld1K1pYVGphY2NrK0FhT3dLRjF5ZmJUK3ZpcGprUHlIaGpkZDNhYVM2WWUx?=
 =?utf-8?B?b1FaczhCd1lGUXhKWDNGZG9xKzFiREdCbnZVL0s5ODhIemlGOWZxMVlUc2Vh?=
 =?utf-8?B?NGVFZ2NvUU91KzFMcGtxQ2lzeDgyVmdxaDVUMFZiY0p5UGtUSjZRQVZIVnVD?=
 =?utf-8?B?THRqOWlncEhzNHJ4YVZxeWZlV2tKK2QrWXhkSEpZSjByVUx6dmU3SUR4aUY2?=
 =?utf-8?B?bXNKa1JKcTZCOEM2Um9wNlBYaFRiWFdsMFRIV3JLOUE1Rzd5SERlRUpXSEU1?=
 =?utf-8?B?R0ZFZzFCaXBYUmhUKzhMdUpZU0dqVkdUQXptaWRPSFpDVkV6VHJ6UklQS2JO?=
 =?utf-8?B?c2o3dHI1K3E2a0o5c0hycmcxYzJUbW5NVmpZTERlME00ZHdtd09CZDNtb1N0?=
 =?utf-8?B?QXRmNFd0dTE4TDBUSTl1TDBYUmhkWmdxbmRjU2RSZzZWSDdTYlFubGR4OUdU?=
 =?utf-8?B?STR0Rm9OeGtOY0RtbkxGTWtOQmQxUkZYbTBmS0ZqdkpSdFVhTWJ0TzFGbXhB?=
 =?utf-8?B?aWUxQU5TRHBtcVMyWUdlL2pnaDdiNE5XN3AyblhnMWtvcVdhK1grWVpaUDFQ?=
 =?utf-8?B?elFtSE80dnFHc1U4alVqaUQ1MFpGZkFySmFTUW0xQnlTY0E2RUlKMzFNWGw2?=
 =?utf-8?B?QUpUc3pLZE1NcEtzMUhFUVZCYlZ4dE1rajdEZ3pPbm8wUFAyZWlIOUtsM0hT?=
 =?utf-8?B?bFptdkxzRS9rQVJhNzJERHQ1eVBUY3p2RWJjclBpaFBqWGFWY2FtNSt6NTBZ?=
 =?utf-8?B?YiszbGZoMDVFSVp6UHBiM2h0VCtmZGQwS3VOZDRvR3pJMkJJSFRidkYxOXRI?=
 =?utf-8?B?NzRuekJ1WEEyTFlYZTNENFB4ZS9hdGVpRGxZWG5lemd3ckgvT1QzZ2xJUWZC?=
 =?utf-8?B?dDN0MXdmQ3ZxNEZhQmtjSlREUzlLSDRmSXdER3FFeVlETk82NldtQ280V0w2?=
 =?utf-8?B?bS9UemorL2dtT3BsUktmYVJXa2pmMW0wOXJUdWdGRk5NVTVYUGR4MW5NNHAw?=
 =?utf-8?B?K1ZEbmNuRDJqVkR2a2NrUGM3Sk4wTlVLS0ZISW80QXUyOUd1K2xVL0F3bVlr?=
 =?utf-8?B?Vk42eWQ3c1BOZVhVaTZQTTY1WHo0Z0d5R05sOGlrQStkUkVjV2trOVd1OFZr?=
 =?utf-8?B?RU9MbXpmcmFXbnByYjNXaHI3SHF3b1lITThTdmxqcDJDdGZJVXU1WUpMditj?=
 =?utf-8?B?OHlJU2FKMHR2TEQ2L0wxVk1xM1NsNG40R2wyaUkvSFovNWhiQzBVdXpLMnpa?=
 =?utf-8?B?ME5VS09VYXMycnJWbnNHb0hDaHJtS3Z4cHJRTkpVV0lsQTJqSTBQeDZ2MnI5?=
 =?utf-8?B?NWxmZ01wc1hHMithMjNSSklBcFVqMllUV1ZGdmM3NHZYZHlzRXNRNWR1ZTBM?=
 =?utf-8?B?N2xOUnlSdk44alhXdWFNekUzVXJIUWtkc3gyTXNYYWRLeTFnaVpTR2w0SFd5?=
 =?utf-8?B?OUFJS25hQld0K1RReDRQZFRaYnk4akMzT0N5UTcvcm1mczlGR3lBdGtGQ1Bw?=
 =?utf-8?B?WVhQTUgvVGhNNVUyMWNWWGIyeUdBOHAwcE9KYWQyVGVsZlFIdG02Rkxla09K?=
 =?utf-8?B?TXU0R0JDbUZ4NGowbWg0QlVIY2JVeWRGTjUvWEVkWDBLWFZBN0ZzbG1XNUdG?=
 =?utf-8?B?WjhLZU12SFZnY3pCWGd5ZjF4dGJ6dkM4SXBmeGlvT2xTaTFLc3dKVGdncWx2?=
 =?utf-8?B?Rml1cTNWR1hBYmMwK3F3TXBxWEVxR2IrRGI5S1RqTHh2K0hVcE10ZFNBRnVi?=
 =?utf-8?B?WUMxcDNjUW5mWnVuZHpyejJnU1FUMGp0dUNUNk8zengvUjlGd09LRDNhbC9W?=
 =?utf-8?B?dFBMWmpKK1c1NnphZTlva1VZalVWZytUektvL09EakFLcWg5N0FXRHMyVzhr?=
 =?utf-8?B?czNINDBtbmVPSkNuc0VaTm0xTUhxUkJ4MXZXMFZyNTNwMzBmSEhzbENPVTRx?=
 =?utf-8?B?UnBKSWF3WE4zSFVrMGZxR0hPOGNocVBjTWQwUzBqRS9sMkpNSzg4dFBPN2xR?=
 =?utf-8?B?aTFFUnREOEc5bUhHeUxkWFR6R0xxNEpxOXk0QlJJYWQ3WFNQa0ZiWDQ0L2VE?=
 =?utf-8?B?OE5xVW5mZEU2UmtBaEhFT3RMUlpaNG1vU0FzdjUxWE42anVUQS92MWxBVEty?=
 =?utf-8?B?bU1BLzl1WHNyakVCdmhLUjZPcUl3TFIzNnk0bUpOZUdObXB2RUNIeVNLd21y?=
 =?utf-8?B?R2FFMlluQ1FLQlAxdytrT3pBNTg0TU9aQk1oUytsQnYyMlROc1ptUFc2T3dm?=
 =?utf-8?B?Z1pJK0JXZWwyRU10VFJjTmhjc1NGYlF4cndKNFQxM0xPUXFZR1hUZz09?=
Content-Transfer-Encoding: 7bit
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 31f90dc4-264b-4beb-92fc-08defcff9cff
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 08:06:31.5882
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: itYwUaXk7tr7FW7YFir83Y8wwuAI/xWH+Qzr4b851PNvuJyS332mI7tVEKVAd7RNdN65jIT1APypuKHBcLrGkA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9718
X-purgate-ID: tlsNG-c201ff/1787040395-71AAF2A1-EF556941/0/0
X-purgate-type: clean
X-purgate-size: 6217

Hi Michal,

Thank you for the review.

On Tue, Aug 11, 2026 at 09:51:38AM +0200, Orzel, Michal wrote:
> 
> 
> On 10-Aug-26 23:12, Mykola Kvach wrote:
> > Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo,
> > which is initialized from the sanitized host CPU feature state. This
> > does not necessarily match the virtual interrupt controller configured
> > for a domain.
> > 
> > A vGICv2 domain can therefore observe a nonzero GIC field when the host
> > supports the GIC system register interface, even though Xen disables that
> > interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can
> > observe encoding 0b0011, although Xen exposes only its vGICv3 model.
> > 
> > Derive the fields from the domain's vGIC version instead. Expose 0b0000
> > for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the
> > ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through
> > CP15 in AArch32 state. Leave the alias unchanged when AArch32 is
> > unavailable.
> > 
> > Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
> > Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers")
> > Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> > ---
> > Changes in v2:
> > - Share the GIC ID field helpers between the AArch64 and AArch32 paths.
> > - Parenthesize the individual ASSERT conditions.
> > - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable.
> > - Target master instead of the 4.22 release.
> > 
> > v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/
> > ---
> >  xen/arch/arm/arm64/vsysreg.c    | 18 +++++++++++++++++-
> >  xen/arch/arm/include/asm/vreg.h | 20 ++++++++++++++++++++
> >  xen/arch/arm/vcpreg.c           | 15 ++++++++++++++-
> >  3 files changed, 51 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> > index d14258290f..a02ad951f9 100644
> > --- a/xen/arch/arm/arm64/vsysreg.c
> > +++ b/xen/arch/arm/arm64/vsysreg.c
> > @@ -21,6 +21,7 @@
> >  #include <asm/arm64/cpufeature.h>
> >  #include <asm/arm64/sve.h>
> >  #include <asm/current.h>
> > +#include <asm/gic.h>
> Stale include? Nothing references gic.h here anymore.

Ack.

> 
> >  #include <asm/regs.h>
> >  #include <asm/traps.h>
> >  #include <asm/vreg.h>
> > @@ -304,7 +305,18 @@ void do_sysreg(struct cpu_user_regs *regs,
> >       * to identify the processor features
> >       */
> >      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
> > -    GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
> > +    case HSR_SYSREG_ID_PFR1_EL1:
> > +    {
> > +        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
> > +
> > +        if ( cpu_feature64_has_el0_32(&domain_cpuinfo) )
> > +            guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> > +                                                   ID_PFR1_GIC_SHIFT,
> > +                                                   v->domain);
> > +
> > +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> > +                                  guest_reg_value);
> > +    }
> >      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
> >      GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
> >      GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
> > @@ -343,6 +355,10 @@ void do_sysreg(struct cpu_user_regs *regs,
> >              guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask;
> >          }
> >  
> > +        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> > +                                               ID_AA64PFR0_GIC_SHIFT,
> > +                                               v->domain);
> > +
> >          return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> >                                    guest_reg_value);
> >      }
> > diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
> > index 387ce76e7e..24735aaea1 100644
> > --- a/xen/arch/arm/include/asm/vreg.h
> > +++ b/xen/arch/arm/include/asm/vreg.h
> > @@ -9,6 +9,26 @@ typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> >  typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r,
> >                                     bool read);
> >  
> > +#define ID_REG_GIC_WIDTH 4
> > +
> > +static inline unsigned int vgic_id_gic_field(const struct domain *d)
> > +{
> > +    ASSERT((d->arch.vgic.version == GIC_V2) ||
> > +           (d->arch.vgic.version == GIC_V3));
> > +
> > +    return d->arch.vgic.version == GIC_V3;
> > +}
> > +
> > +static inline register_t id_reg_set_gic_field(register_t val,
> > +                                               unsigned int shift,
> > +                                               const struct domain *d)
> These two are incorrectly indented (off by one to the right).

Ack.

> 
> > +{
> > +    register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift);
> > +
> > +    return (val & ~mask) |
> > +           ((register_t)vgic_id_gic_field(d) << shift);
> Incorrect indentation: continuation line should be indented +1

Ack.

> 
> > +}
> vreg.h does not include any header, so please add appropriate headers for
> objects you are adding.

Ack.

> 
> > +
> >  static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr,
> >                                       vreg_reg_fn_t fn)
> >  {
> > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> > index e7c484f2c1..d6f9326b71 100644
> > --- a/xen/arch/arm/vcpreg.c
> > +++ b/xen/arch/arm/vcpreg.c
> > @@ -12,6 +12,7 @@
> >  #include <asm/cpufeature.h>
> >  #include <asm/cpregs.h>
> >  #include <asm/current.h>
> > +#include <asm/gic.h>
> >  #include <asm/regs.h>
> >  #include <asm/traps.h>
> >  #include <asm/vreg.h>
> > @@ -173,6 +174,8 @@ TVM_REG32(CONTEXTIDR, CONTEXTIDR_EL1)
> >                                    domain_cpuinfo.field.bits[offset]);\
> >      }
> >  
> > +#define ID_PFR1_GIC_SHIFT 28
> Move this to cpregs.h and remove one from arm64/sysregs.h to avoid duplicate
> entries.

Ack.

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:17:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:17:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393632.1632440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwF0S-00086w-H7; Tue, 18 Aug 2026 08:17:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393632.1632440; Tue, 18 Aug 2026 08:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwF0S-00086p-EG; Tue, 18 Aug 2026 08:17:12 +0000
Received: by outflank-mailman (input) for mailman id 1393632;
 Tue, 18 Aug 2026 08:17:11 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwF0R-00086j-B3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:17:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwF0Q-0060oH-HA
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:17:10 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8414ff-8faa-0a2a0a5109dd-0a2a4502cbae-18
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:17:06 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841502-6ca4-0a2a45020019-d1558032c9ea-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:17:06 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so28938165e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:17:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996188217sm507279205e9.13.2026.08.18.01.17.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:17:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787041026; x=1787645826; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=IhipMhwqMcTACvWaNn73WmCch4Fpx+tbx53KKzTxD9Q=;
        b=dYVfV/8gLppSPMJjPlUTgBHa1fVXfPVqHs3O9TVoYMaYdzqmeZv5NY+/2e00GQkpUR
         eFNk8k5VMXT/0TA0lR1hWLT8FcwEtVs4quj/il+F4jOj+bjUjp3dmzvQAbqTyLlHuRJk
         fgZMbuo9NNUI+O6bljg3NPONrSeF9w0DRVkfAV8ei2nH72ShxqLclMG1gaUHlM6J+uCF
         cfY8tMZi95m3V3jGr4JRbi8Mq3PUj2zvckMJfqBsj55uB2YJgiM4FN6UI7Vr46+Pq0NV
         h1AkWm2lHgefPbFPlBKquBfEyQpTguorvHJZEMPGPToxL+I2qEdlva0s/O/UWz0gZ62e
         u6ZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787041026; x=1787645826;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=IhipMhwqMcTACvWaNn73WmCch4Fpx+tbx53KKzTxD9Q=;
        b=tZ6gAZzJN6b4hUkaF1qMtK7HqD40spv6L4W9IVTQYmZHw89FQAgKPayhh6RQtGjM60
         yesmReroBO5tFjn7OXSTAo6CCx2fqJYGCIB3yxTgv9tHCEg47LccBgGTzbzXdNyJLkeq
         nP7c8w+K3QrBi+qltlKC5dnuYQhsw1/gKU8TaXkUTaRTPdJSTQISx3eY76uZNZZjlBO1
         /aZCxtvc/cgHhju0/lO+6chuPJiWg2XnE5lhLo4XdqRPq1t9jRi6Vbn8/qCmEs7lEATG
         eoLMchD+F70889uRdQGiHJEN2eJXWvmCd/xfYkpku6x9pGbrGyTyTY7qAQjNK2jo1ZmR
         54Ng==
X-Forwarded-Encrypted: i=1; AHgh+RqxSGPvft+Kxl64766ECtoEKos+iTDrLL63x+e1bD/5Bdv/8cSUWFwPEBiIVc+iiKK3TRPbSs9PUPY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw90pPd2uGVHLYNYbn/oTxtygXuVIB8r8zdepJeBJMDjI6Egg6h
	4zGh+vt9HaWQGPFGFdwiyhWodO4rWcP29IStnZNvH7fk7xMqa9AEuGPNby9jfbuTRw==
X-Gm-Gg: AR+sD123EblcHWbu7j0tNG8vFIPedLdCLeR5pZ/fT0L6SgghbculHcHe2UtNlPsgQml
	ByWXGnRLjVM+pNaunS2SugfRWvE2iGDWrXiHTEwvn+5WKgtGcy09YSnsbFjymg4O8OsomOw5x+j
	dYzwPFGPzGzVrNIsc7yuHz96CXNbK3QuB5x8yy857PalsdKB0AOSMdKAGporms8R2SVzvbk5+OT
	g7LcmMGKEAygh5GDy0u38trckJA2wk5/H535nUeMUZ4jD2znA2ygtF7OPQ6kxBHCFgKPVERWo7u
	vB3fIYD6q9U5ay5rma4WLTHzaKz8yxZOu2FUBwxqlSfFBmj5G3QtHY9moMAkDu98UwQALLPcJpg
	4z8iZ8aQv6XDVnC4u+MckuMA8uOLhvNrYckfmYn67Y1Xk84ztw/OVjOaSPyiXHdwglVcdQQnO0H
	v2FkPRl41OQkRDTTcId/Dub9QTcYj6a38XixDgxxNcQK9bXetBiPfSTwkBbvLNYohI/mznTbleo
	NLfIkBoblLA/eoFz62XYXSePzsIr0yyKw3n6Dr0A2Vur4awbyr8
X-Received: by 2002:a05:600c:3485:b0:499:8758:8cb4 with SMTP id 5b1f17b1804b1-49987935eecmr505817515e9.5.1787041025563;
        Tue, 18 Aug 2026 01:17:05 -0700 (PDT)
Message-ID: <2ca3f802-bf93-4714-8a9b-e33ab0c89300@suse.com>
Date: Tue, 18 Aug 2026 10:17:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
 <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
 <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787041026-67ABD2AC-34359257/0/0
X-purgate-type: clean
X-purgate-size: 5115

On 17.08.2026 17:36, Oleksii Kurochko wrote:
> On 8/12/26 5:30 PM, Jan Beulich wrote:
>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>> Introduce riscv_vcpu_unpriv_read() to allow Xen to safely read guest memory
>>> using HLV/HLVX instructions while reliably capturing trap context.
>>
>> Both for the title and the function name: How does "unprivileged" matter here?
> 
> Unprivileged because HLV/HLVX reads guest memory as if it were accessed 
> from a less-privileged (guest) context, rather than by the hypervisor in 
> HS mode.
> 
> I think I am okay generally to drop "unpriv..." from the function name.
> 
>> The same functions would be use for reading Dom0's memory, wouldn't they?
> 
> Yes, I don't see any issue to let this function to read DomO's memory 
> too. But Dom0 could be counted as "unprivileged" too as it is executed 
> in VS-mode which is less-privileged then HS-mode.

Well, you need to properly distinguish the different cases of "unprivileged"
when writing titles / descriptions. The way you put it in your reply above
("less-privileged (guest)") is sufficiently unambiguous, but what you have
in the title ("unprivileged guest") clearly is a synonym for "DomU".

In the end, as you confirm, "guest" alone is all that's needed here to know
what is being talked about. (That said: We often distinguish "guest" and
"domain", with the former meaning DomU but the latter meaning all domains,
including Dom0 and service domains. Yet for the purpose here I think "guest"
is good to use, not matter that all kinds of domains are meant.)

>>> +    if ( read_insn )
>>> +    {
>>> +        asm volatile ( "\n"
>>> +            "1:\n"
>>> +            "   hlvx.hu %[val], (%[addr])\n"
>>> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])
>>> +            "   andi %[tmp], %[val], 3\n"
>>> +            "   addi %[tmp], %[tmp], -3\n"
>>> +            "   bne %[tmp], zero, 3f\n"
>>> +            "   addi %[addr], %[addr], 2\n"
>>> +            "\n"
>>> +            "2:\n"
>>> +            "   hlvx.hu %[tmp], (%[addr])\n"
>>> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
>>> +            "   sll %[tmp], %[tmp], 16\n"
>>> +            "   add %[val], %[val], %[tmp]\n"
>>> +            "3:\n"
>>> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
>>> +        : [ti] "r" (trap) : "memory" );
>>
>> You want to tell the compiler that *trap is written. Instead I don't see
>> why a memory clobber would be needed: You access a different address space,
>> i.e. nothing the compiler can make any assumptions about.
> 
> memory clobber tells the compiler that the assembly code performs memory 
> reads or writes to items other than those listed in the input and output 
> operands and so I don't tell here that *trap will be changed.
> 
> Why this understanding is wrong?

You can (ab)use "memory" for that purpose, but why would you when you can
properly express the operand? All that achieves is the compiler possibly
having to emit less efficient code.

> Alternative, I think, could be:
>          : [val] "+r" (val), "+m" (*trap)
>          : [addr] "r" (guest_addr), [ti] "r" (trap) );
> And then memory clobber could be dropped.
> 
> 
> 
>>
>> You also need to take precautions for not returning an uninitialized "val".
>> I think the variable wants initializing (perhaps to ~0) and "+r" wants
>> using as constraint. (Afaik & isn't necessary to use together with +.)
> 
> I agree with '+' if we will initialize val with some value.
> 
> Regarding, '&' my understanding is that I have to use it always when

When what exactly? If an operand is both input and output, how could the
compiler re-use the (generally) register for any further purpose? '&'
indicates to the compiler that it may not use the register used for an
output to hold some input's value, as that value may be lost by the time
the input is actually consumed.

>>> +        /*
>>> +         * Although HLVX instructions' explicit memory accesses require execute
>>> +         * permissions, they still raise the same exceptions as other load
>>> +         * instructions, rather than raising fetch exceptions instead.
>>> +         */
>>> +        if ( trap->scause == CAUSE_LOAD_PAGE_FAULT )
>>> +            trap->scause = CAUSE_FETCH_PAGE_FAULT;
>>> +    }
>>> +    else
>>> +    {
>>> +        asm volatile ( "\n"
>>> +            "1:\n"
>>> +#ifdef CONFIG_RISCV_64
>>> +            "hlv.d %[val], (%[addr])\n"
>>> +#else
>>> +            "hlv.w %[val], (%[addr])\n"
>>> +#endif
>>
>> Once again please use enough care that RV128 would at least obviously fail to
>> build, rather than building something which then doesn't work.
> 
> Sure, I will do the following:
> 
> #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

And that, as before, without indenting #, please.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:17:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:17:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393639.1632449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwF13-0000GZ-TE; Tue, 18 Aug 2026 08:17:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393639.1632449; Tue, 18 Aug 2026 08:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwF13-0000GR-QI; Tue, 18 Aug 2026 08:17:49 +0000
Received: by outflank-mailman (input) for mailman id 1393639;
 Tue, 18 Aug 2026 08:17:49 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwF13-0000GJ-I5
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:17:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwF12-001tUU-V9
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:17:48 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a841525-bab6-0a2a0a5309dd-0a2a450bbf98-26
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:17:48 +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 <oleksii.kurochko@gmail.com>)
 id 6a84152c-b7e8-0a2a450b0019-d155802fe541-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:17:48 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4957eefd361so33143865e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:17:48 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a31572sm10324689f8f.5.2026.08.18.01.17.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:17:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787041068; x=1787645868; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=d8T0Y6BfA3DZkgPSKVxlgvLHJXkmbTof8jMJmn/Ja58=;
        b=BuDEnAzwXqKE1/BFsKYDxkg7L97gTUf89XOynV594GJGsGgMYCcrMe1ClSv9xn+om9
         RyTlgg0xajzl24A+GSvN5f+wTyPAaMzsPylVmld+4gyWXQtbGziiKByn/mmVh8c/H18/
         huMqwL584yZUMhsgvr88rEXoz8cZaQpD1tw7FtcCBPR31ioasVPcV/4LJ2ALgBHHk7Uh
         WfAwjWngfMJk3BD2NKo2aghPqaE2bxG49n3/iagF0BmOvcIOtLYSCWaZM/GmzihMekFv
         xxL4ZUUp2kzniJBk8q61h4PnRhZhzIlq4Fb6aFlXGXHZa/gH7Ygfy/qgYGFAyoufknM7
         oPJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787041068; x=1787645868;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=d8T0Y6BfA3DZkgPSKVxlgvLHJXkmbTof8jMJmn/Ja58=;
        b=rxbqYjgCcBcxzv/jFVASXH65fHFqIbSR5fxASIfbYpTazpDaozX6NVw7NrrfHzDw0S
         MfzqvKNwl+M6ku1xo4j1sCaNjRuKVvdy7C+FIwRrqHDiHOuyVw+PNuC/J8JU0AhPj7AT
         DasX95th7xkyfKbjAg6eF+rJd/BwbozzBaHx1rFnfxgDW21XKdqDXTZQBkE/M3YJjANm
         /YBckiE58oiKhrMbsbw6OpBSt0IxCHT14oqGgtolXhGCtbbts7cnRR1qS2hVsWM2ptuG
         X9baYgvpJTLfbJLjUphRjtG7hRy1IFCt0TLuKY0lRoxSQLvIWw9rw+KozwHHabodL3Xy
         4zHg==
X-Forwarded-Encrypted: i=1; AHgh+Romjjqwi21Vdb7BAHPPmzG0qsPhMPTPJDgKtc4jJYZPoDgIyGytfa3z0NuGUAXwuGSJlBQjS1NeKNQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzvLQM7tKMV5DO0iV250xgEugiAoxa0Q/NOLsomQBAI/oC/spJW
	Z8fwZie2/MjS2x9cRwuo0DpZibo4LfgjHJkBCQJgaXk83vM7U7Ih669E
X-Gm-Gg: AR+sD11T5kzW+mXEsqgP6Bdp26WELb2lhXzgCGHIbNdpMwRtduWUDexGiV6agXav3km
	FGDOMxqEAFhDjX19s2DWec31s52T3besu+9IXJM1SZNJTpuYTPzGlWFHCWY1Xeb59vByRpCc2zz
	2q8RX1IfPC2JgoKu3AkGcKSpvkKd/srtBWzQ5sa/1meEX7RzKOaW8IFll8sABwyt5S5UIxAarzl
	iHckycMuQxcDo7NArSQMVOVFxd8vLn7irYiaVcCkcSRV+I9ZiFpPEWeXkL0wob612ZLu/Ug6BcN
	so3wskOhXr/nvL5sUxqec/xDe1RY7/1pEE2IxXQsx4kSbPn1onKf9fsKjx5u6ig9DW3fdhucFR5
	CkFRt9x3l+ejkofhzaGXUJlytdDo5TqsQSsU7FejLR0pzB4YCeRrf4ddLixcqGwaWupTOfyZNQh
	E6HECmK+MCCp9tBZe0gCzEvGgiv+JvAF0fkagHdDo7ePaFvoeQKY/HURZOiDaD0F0xPDBRr6Y7s
	hnzWS1/xVXX+RwVfy/956R9GRaoz0rSNYmb8r+tLxA=
X-Received: by 2002:a05:600c:4fcb:b0:499:5a50:b022 with SMTP id 5b1f17b1804b1-49987928d0cmr524314855e9.3.1787041068221;
        Tue, 18 Aug 2026 01:17:48 -0700 (PDT)
Message-ID: <12b04ab7-6d0c-4d01-8c73-16cd46f1b311@gmail.com>
Date: Tue, 18 Aug 2026 10:17:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
 <87339fc0-fbf7-44eb-8b08-cc95ac7d1cb6@gmail.com>
 <eeedd10c-0c14-438e-a48f-05383ba49ec8@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <eeedd10c-0c14-438e-a48f-05383ba49ec8@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787041068-1A8D99EA-4957A184/10/73395122804
X-purgate-type: spam
X-purgate-size: 1051



On 8/18/26 9:58 AM, Jan Beulich wrote:
> On 17.08.2026 13:39, Oleksii Kurochko wrote:
>> On 8/17/26 1:33 PM, Oleksii Kurochko wrote:
>>>>
>>>>> +    BUG_ON(!trap_info);
>>>>> +
>>>>> +    trap_info->sepc = csr_read(CSR_SEPC);
>>>>> +    trap_info->scause = csr_read(CSR_SCAUSE);
>>>>> +    trap_info->stval = csr_read(CSR_STVAL);
>>>>
>>>> Do you really need to re-read all three registers here? Didn't you
>>>> read at least
>>>> scause already, in order to make it here in the first place?
>>>
>>> Agree, ->scause and ->sepc are already read.
>>
>> scause should be re-reaad as we don't save it inside cpu_user_regs
>> structure.
> 
> It could be propagated as a function argument. Question really is how
> expensive these CSR reads are.

Considering that each RISC-V hart normally observes its own CSR 
accesses, including its implicit CSR accesses, as performed in program 
order what affects out of order execution maybe it will be really better 
to propagate scause as a function argument.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:28:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:28:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393649.1632460 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFBj-0002BL-UY; Tue, 18 Aug 2026 08:28:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393649.1632460; Tue, 18 Aug 2026 08:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFBj-0002BA-Pr; Tue, 18 Aug 2026 08:28:51 +0000
Received: by outflank-mailman (input) for mailman id 1393649;
 Tue, 18 Aug 2026 08:28:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@swg.vates.tech>)
 id 1wwFBi-0002B4-He
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:28:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFBg-001fvd-VW
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:28:48 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@swg.vates.tech>)
 id 6a8417b4-bab6-0a2a0a5309dd-0a2a450bd304-18
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:28:48 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@swg.vates.tech>)
 id 6a8417c0-b7e8-0a2a450b0019-b9ff1c12a333-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:28:48 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a013fcb15a000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 18 Aug 2026 08:28:42 +0000
Received: from [192.168.1.17] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr
 [90.112.87.96]) (Authenticated sender: baptiste.le-duc@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id C4AAD8387F;
 Tue, 18 Aug 2026 10:28:41 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=r5WVRdBGOceVMVwcG+Gv/vWAgeYC7BhFIH6R93zEkfM=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=HFmysp/JQhNelCAATMuwkWbhfy8k+Vwsq9JqYc73JwNImXEETsgP7SySfKzsMmIbVo9O0ADbC
 tcTaTb1OCryV1byaqIXphNIubHdvc867lcKvwzlaRv6rkBhXFZe5geznwYBHVOZCuJNOtaYRUie
 57UxyQ8ojuGhbQuV9RQ4to1yEVEhVJrXyY4g5EmCteHEjteVdi3lUR09g8oW2ZJsBPLvPUrnrDG
 +fMtLqT3SPfgk0W3l7RCyaavtVUCYsX3rzpQDq864NaugJoZfRbL/Jk/XN2Pk18PegJg+4AkeEp
 A+XiIA2mEP8Xe0xl7vkO0MHcU22VB3qgtJTV3Orr/8cA==
X-Zone-Loop: e5130db2204b6b2ca21217d42104af8bd1f5379c1045
x-campaign-type: default
x-transaction-id: f1d3bf31-b3f2-4192-9d86-8b18d64f8198
x-swg-uid: 01-80a118a5-825e-401e-b65f-a4100b62be9a
X-Mailer: Sweego
Message-ID:
 <1787041722.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@vates.tech>
x-swg-bid: 1787041722.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 10/17] xen/riscv: introduce
 vintc_state_{save,restore}()
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <cae4c5ef-cc4a-47a0-90fa-2f84c00ba4a6@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
 <1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@vates.tech>
 <cae4c5ef-cc4a-47a0-90fa-2f84c00ba4a6@gmail.com>
Date: Tue, 18 Aug 2026 10:28:28 +0200
X-Developer-Signature: v=1; a=openssh-sha256; t=1787041721; l=1739;
 i=baptiste.le-duc@vates.tech; h=from:subject:message-id;
 bh=JbcJf4dkvQ7ngMpfVYGeElsA2ynqU2bI968PDCcJzdM=;
 b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgQKqDblDzOFimZyyhA+RsKnxim2EiA
 60KatQBsuueKYUAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA
 QPbTq3r5z8P5yLkOq5ksX2PeJvmZEmlYQBcJgSDFPIz7gPAyMXC9sy3ml+eeLm1WpJa+aGQjOAp
 CzSojT2E1DwY=
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=openssh;
 fpr=SHA256:YieMhmvNcCYpeUbL6HuedGp4rwSlu4mQ+D7EJoVHM+k
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787041722146
X-purgate-ID: tlsNG-42698a/1787041728-AB6D29EA-28DBCBCA/0/0
X-purgate-type: clean
X-purgate-size: 1743

On 2026-08-17 10:31 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/13/26 11:42 AM, Baptiste Le Duc wrote:
> >>   #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
> >> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
> >> index 372c8d3a20..879d513374 100644
> >> --- a/xen/arch/riscv/intc.c
> >> +++ b/xen/arch/riscv/intc.c
> >> @@ -163,3 +163,17 @@ bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
> >>   
> >>       return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
> >>   }
> >> +
> >> +void vintc_state_save(struct vcpu *vcpu)
> >> +{
> >> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
> > Is there a situation where ops could be NULL? If yes, add a check.
> 
> It is unlikely that there is nothing to do during a context switch for 
> vINTC, so vINTC should provide an implementation for saving and 
> restoring its context. This also ensures that a NULL pointer dereference 
> will lead to a trap, allowing us to catch cases where a 
> context-switch/restore handler is missing.
> 
> Even if it turns out that vINTC does not need to perform any actions 
> during a context switch, it is perfectly fine to provide an empty 
> implementation. However, as mentioned above, this is unlikely. 
> Therefore, having a NULL pointer dereference here is intentional: it 
> helps catch cases where someone adds a new interrupt controller driver 
> but forgets to implement the corresponding context switch functionality.

Thanks for these explanations. However, wouldn't it be better to have a
dedicated BUG_ON in case of NULL dereference to indicate clean call
trace to people who missed to implement context-switch functionality?

> 
> ~ Oleksii
> 
> 




From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:29:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:29:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393653.1632468 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFCJ-0002ZO-4h; Tue, 18 Aug 2026 08:29:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393653.1632468; Tue, 18 Aug 2026 08:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFCJ-0002ZH-11; Tue, 18 Aug 2026 08:29:27 +0000
Received: by outflank-mailman (input) for mailman id 1393653;
 Tue, 18 Aug 2026 08:29:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwFCH-0002YI-Bv
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:29:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFCG-0063jF-OV
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:29:24 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8417d6-8faa-0a2a0a5109dd-0a2a45079842-38
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:29:20 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8417e0-b4ea-0a2a45070019-d1558029b06e-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:29:20 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4954d29264cso21678455e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:29:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996100082sm301181995e9.2.2026.08.18.01.29.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:29:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787041760; x=1787646560; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=VcANKyrGAhQFs8JEyLNEdPsIOZJssOQGyQ8mwhhhccM=;
        b=WXIqE22KnuHE5rbB1B5rgnsynt6tqSXWpYiPix7XxF3bPOA80ILn9QlD1jsLUzehWu
         TjBVIhxoqDF8HJyoCxlDSKn9ej6wK7tqOfPdx+IQtlfac6GsctcmZ5BB5Q6rD9srmxP3
         CGsnNvbVhzm4w8Erze1/l023lTeI4HtHOrgLRWL6F4jx38wbc/s8r4rB5zomjthrn4Kt
         7qDu5ZOIHvGr/vjiTeMbao42/zxkBismrkp94KdEDMby1m1g1oPOobNAsdWYlgphfTOC
         SeOX3txY3Hw9WXW986wrsBhJCpNXseTjMBUzjgS6K0iXpUjoiGaf3MDRvWNEy7Ne8Fwz
         6Yqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787041760; x=1787646560;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=VcANKyrGAhQFs8JEyLNEdPsIOZJssOQGyQ8mwhhhccM=;
        b=py5kIFDA97cgBoXE9QGXi+TTGuX9yjHMgdZ/KsqSLNb6elF/ggJvD0eYFdZl+8sgDw
         lK6nvvIw2+GazIj8anQZmKF0MlRWX1B5A7ICfmkV2J7Q8dnf1AbNj2hU0smvHIsgSSlD
         3IrIEDRlG55TtK2cneazKORYEGTgUgMGJ4Wrfv4HXDCuP3tNML73SFWAf2fMSoJpGngK
         Url8OLETHWMCKEYSndXXAp4BQpOHftcxlX8mK4WbPRKMrbs96swRYckCW8+moQ/gM4ZR
         EDY6QWFPXUkno2k7o1FPyuZ06LPiEYh4hE7BABg8GqCJT08GEh2RwpWZq2c36fTQzIZi
         cevQ==
X-Forwarded-Encrypted: i=1; AHgh+RpFCpsQuRU5YMwb+V2bZ6UxBiFNmAXeIfVMir6i12V3Sd7YR9nT3q0DnU1p+4L6zmn6v8aSqdXQzrs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzbqf63OgOFFdtkzZ4IcIoUb4HwsLKmbPUSnqOHahj4XQDMx1CT
	FXbPtRrF9UPdfWmfnWIYz0deYmkPedUpjh1TEjNpyJRODJxmbtH+os1xZrubmOIkug==
X-Gm-Gg: AR+sD10Ad/IlP91VUiHpOeMHz5zbuZxCGz3pirit9AGenKNo1ranempDCnxCmhc5xCG
	5hVIVkd8CpdVqe/zbNTdx5vC3cxSfhMELHCGtuaMRRAynB5zk+/0H1AbnG6oTSJayRLuRU6Xs5V
	UKM9NYjPMuNppDsyfj7gaIJXCHTeU85Y8vg8fLg4xaokP6xZXJMsv8yprymO1Z+vmaPwzBQHcFQ
	PB+ll2yGt7+UiSH5V9BoPWZ+PYsa9dKClcsmnnr7jSNtdgTelrtQFuUqIkJrcJMrH/DEEVtabg2
	w6mudeTI2tNxYJ9kJKbFjcA4MZwyJDAywtz8tNA42B7qfCKty1PCalTHDyP+a9mHmIOrjf0xTdp
	bV6Ned41Me3YLlGHoop880fsGyNHv6+JFycdOYDxfextMvF3WN4w8YSEJkAkv9uMWZ58pLlKax/
	mYcMklBJ2hswg7xGTeyGJejMDDzQrsWC9qvNDy7nj3oLezzTpw8LdJaVMd1FChn3wZQQY+ojd1+
	VQUOg1QJQoJt6CEBs8hPJ4Mvrqh05W8azVA7sgJjLsoH10mKmdNe68R93viaTs=
X-Received: by 2002:a05:600c:c490:b0:495:4859:8f9b with SMTP id 5b1f17b1804b1-4999fb76fc2mr88466925e9.9.1787041760170;
        Tue, 18 Aug 2026 01:29:20 -0700 (PDT)
Message-ID: <f6e12465-dcd0-4f04-bdd4-8e1943e1ade7@suse.com>
Date: Tue, 18 Aug 2026 10:29:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
 <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
 <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787041760-350CDAE4-01FB4293/0/0
X-purgate-type: clean
X-purgate-size: 3572

On 17.08.2026 18:10, Oleksii Kurochko wrote:
> On 8/12/26 5:48 PM, Jan Beulich wrote:
>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/traps.c
>>> +++ b/xen/arch/riscv/traps.c
>>> @@ -191,6 +191,67 @@ static void timer_interrupt(void)
>>>       raise_softirq(TIMER_SOFTIRQ);
>>>   }
>>>   
>>> +static always_inline unsigned long get_faulting_gpa(void)
>>
>> May I suggest to use always_inline only when inlining is _functionally_
>> required?
> 
> Sure. But it ins't clear to me why it isn't a case here? Is it connected 
> to that function is static and too simple so a compiler will do by itself?

Counter question: What is it that would functionally break if the function
ended up not being inlined? (This is the question you generally need to
answer to justify use of always_inline. Of course there's the additional
case of performance being affected, but I don't view that as applicable
here; I'm open to be proven wrong, though.)

>>> +{
>>> +    /*
>>> +     * According to RISC-V spec:
>>> +     *  18.2.8. Hypervisor Trap Value Register (htval)
>>> +     *   ...
>>> +     *   A guest physical address written to htval is shifted right by 2 bits
>>> +     *   to accommodate addresses wider than the current XLEN.
>>> +     *   ...
>>> +     *   If the least-significant two bits of a faulting guest physical address
>>> +     *   are needed, these bits are ordinarily the same as the
>>> +     *   least-significant two bits of the faulting virtual address in stval.
>>> +     *   For faults due to implicit memory accesses for VS-stage address
>>> +     *   translation, the least-significant two bits are instead zeros. These
>>> +     *   cases can be distinguished using the value provided in register htinst.
>>> +     */
>>> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>
>> Well, okay, but instead of not losing the bottom two bits you're now losing
>> the top two ones.
> 
> Oh, right, I will add a cast ((uint64_t)csr_read(CSR_HTVAL) << 2) | ...
> 
> It will cover all the cases RV32 which has 34-bit guest address and it 
> will be enough for RV64 where GPA is 59bit (the highest possible for Sv59).

Only if the function return type then also changes.

>> Also the spec reads as if htval only _may_ hold the original address of the
>> faulting access. What if htval ends up 0?
> 
> good point. then we have to emulate fault instruction and get an address 
> from an instruction. I think that for now it will be enough just to 
> support platforms which always write GPA to HTVAL.
> 
> If I understand correctly if htval is supported by platform then htval 
> will be always filled for guest page fault. To verify if HTVAL is 
> supported we could do:
> 
> 'Unless it has reason to assume otherwise (such as a platform standard), 
> software that writes a value to htval should read back from htval to 
> confirm the stored value.'

How does this matter here? It's one thing for htval to be capable of
holding (all?) non-zero values, and another that it would always be
written. If the platform doesn't indicate the behavior, I fear you have
to assume that you may (perhaps even randomly) observe 0.

> And is it true because:
> ```
> A value of zero in mtval signifies either that the feature is not 
> supported, or an illegal zero instruction was fetched.
> ```
> (yes, it is about mtval but I asssume that htval has the same behaviour').

Right, but what you quote is specific to illegal instruction exceptions.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:31:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393663.1632477 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFEK-00048X-Eq; Tue, 18 Aug 2026 08:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393663.1632477; Tue, 18 Aug 2026 08:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFEK-00048Q-BV; Tue, 18 Aug 2026 08:31:32 +0000
Received: by outflank-mailman (input) for mailman id 1393663;
 Tue, 18 Aug 2026 08:31:30 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwFEI-00048K-Mn
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:31:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFEH-00CYTu-Fy
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:31:29 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84185c-bab6-0a2a0a5309dd-0a2a4502bca2-22
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:31:29 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841861-6ca4-0a2a45020019-d1558032b4c4-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:31:29 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-4998590d392so45385325e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:31:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49987b2a176sm334873155e9.4.2026.08.18.01.31.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:31:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787041889; x=1787646689; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=lypWdWKsZ7gIDc20Ywb8XyrvrgmPbThj1oc6KcVY1Zc=;
        b=KTbw/RLTNZj3SXHOz3si/4nJcbfB4IXApBX0zZ0ensddiaD/EctahqrL4YQ3YUk0GE
         Fbl2/GGxZ+yPqI8pBhba8YDAMpYIQP+Kob9CG9C6pdWonFSPAsXPp+svdZT+wf0Q7WqJ
         OhNW6fTfZqW5J9i8e9dvwPZ835oNpgJ3tP46nGp7jfl5junpF9EAuIctN6BDg/f6JPhg
         Q8WBlgtI079OdfjiqMsN4FkTsEPtb1FB2K31aFPaXniF5uRBWphyvg8QQ58CHuHHkP5q
         bjNFu6CEjRCL11wyySA4+647v16eaSlSlLSZD4jgZQYRKH5AwIsU0PI1zm8qtHauIeDp
         P9ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787041889; x=1787646689;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=lypWdWKsZ7gIDc20Ywb8XyrvrgmPbThj1oc6KcVY1Zc=;
        b=EWpDL4be5SeW/5nD/rHFZekvpYF38IlsA/x95FIsaDh3bZCXykeabCod7c7q/9mSe8
         8vi1UmsaqyHT3kvyOOjFHt96iRM7hISt6Rx2aXykU1JNSG22StykQWQaE/sjce/nQG2O
         NEsUPApCV6e7oVmovwGp9tWcb4E7CITEETr0x0DUbqOwxUBi4DJdT3C075W/wM+jH85L
         lAV/883ko5IFCaD2kh+1GNyn0OfrSG6ycPhptyVahgQFNoX5eP4UfnUKE+JR4AW5iD6Y
         DHmZVFDHighjRJZFjNwoOOdPmE+V3ZcUEDsvgEIuk026ynG0aqTlwCJ3Hg/E1HpX+WaZ
         Pvww==
X-Gm-Message-State: AOJu0Yw2xEHGra8TvaDB3QBR/fRA1ApOS0NvaLOOeQE7KZAk7a1Xiaei
	KWzF3V2wTts22fMyJQE0bhZuzyl9YwUu44AmbzAiMr6NXJp9b7SzsbgkNY6oHnXNbQ==
X-Gm-Gg: AR+sD12VgBMZU46ip164PpABgC0ZMhlOzUJQivzhbmDTucBGlPkRUyBjdmMd4lZIKJ2
	Ty4Ahfjl7nqgugN8ED+QP8usi7OZO6rZvFR6nq+p8BKzbfq97p8gKMJuQC4noGVu62TcJ/rFAIC
	l1lGkHHIwPpeMk8Fd02e5Sbk2wmzA9J6Y4YqFnLg/5nuxeuzIX1CjQcpidFZoxh/hBHYFjT9zIE
	2u/iCKz8jBMeKQF0ENbOemVZ+gaxvmgSDZsIAn24wE+yDprqj0LEDnTCAQFk9yVr4CEFKEqs6XY
	8NgTanrVGFcUnWOi2R/WqV8Md3BcUp3959FMfU5AMd5mZNtUD4YMngU0/NMXD3URx74CirpvP7U
	HPOao/zQknc+T/C++iprw4OuFTrsQC/SHSZ/9y0u7Sms0RgB+Fup0PlFM/eGn8SP1ewXKUPmRaL
	XgVo6FLwSbl++MaH00HoEPpqhZfOwptqznRVGpSvYz4G7BNo31caN15kXkUJCL8D4elwF1HHhav
	EUQLN5tlmU5zm2yFk+9HBWhZaRxVedsQeYwtlA7FAsx0gehz4Fr
X-Received: by 2002:a05:600c:8a1b:10b0:499:a685:c10 with SMTP id 5b1f17b1804b1-499a68512ccmr8915605e9.4.1787041888896;
        Tue, 18 Aug 2026 01:31:28 -0700 (PDT)
Message-ID: <ed89d5c2-43b6-45d2-a426-0affe3bfd1bd@suse.com>
Date: Tue, 18 Aug 2026 10:31:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 10/17] xen/riscv: introduce
 vintc_state_{save,restore}()
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
 <1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@vates.tech>
 <cae4c5ef-cc4a-47a0-90fa-2f84c00ba4a6@gmail.com>
 <1787041722.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1787041722.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787041889-668B42AC-E70C8A2A/0/0
X-purgate-type: clean
X-purgate-size: 1877

On 18.08.2026 10:28, Baptiste Le Duc wrote:
> On 2026-08-17 10:31 +0200, Oleksii Kurochko wrote:
>>
>>
>> On 8/13/26 11:42 AM, Baptiste Le Duc wrote:
>>>>   #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
>>>> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
>>>> index 372c8d3a20..879d513374 100644
>>>> --- a/xen/arch/riscv/intc.c
>>>> +++ b/xen/arch/riscv/intc.c
>>>> @@ -163,3 +163,17 @@ bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
>>>>   
>>>>       return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
>>>>   }
>>>> +
>>>> +void vintc_state_save(struct vcpu *vcpu)
>>>> +{
>>>> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
>>> Is there a situation where ops could be NULL? If yes, add a check.
>>
>> It is unlikely that there is nothing to do during a context switch for 
>> vINTC, so vINTC should provide an implementation for saving and 
>> restoring its context. This also ensures that a NULL pointer dereference 
>> will lead to a trap, allowing us to catch cases where a 
>> context-switch/restore handler is missing.
>>
>> Even if it turns out that vINTC does not need to perform any actions 
>> during a context switch, it is perfectly fine to provide an empty 
>> implementation. However, as mentioned above, this is unlikely. 
>> Therefore, having a NULL pointer dereference here is intentional: it 
>> helps catch cases where someone adds a new interrupt controller driver 
>> but forgets to implement the corresponding context switch functionality.
> 
> Thanks for these explanations. However, wouldn't it be better to have a
> dedicated BUG_ON in case of NULL dereference to indicate clean call
> trace to people who missed to implement context-switch functionality?

How would BUG_ON() provide any better (or worse) call trace, compared to
a NULL deref?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:35:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:35:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393672.1632485 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFIP-0004j3-1H; Tue, 18 Aug 2026 08:35:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393672.1632485; Tue, 18 Aug 2026 08:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFIO-0004iw-Uh; Tue, 18 Aug 2026 08:35:44 +0000
Received: by outflank-mailman (input) for mailman id 1393672;
 Tue, 18 Aug 2026 08:35:43 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwFIN-0004iq-0N
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:35:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFIM-008HXl-9A
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:35:42 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84192f-bab6-0a2a0a5309dd-0a2a4503cdb8-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:35:42 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84195e-fae8-0a2a45030019-d155802ca4a2-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:35:42 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so8056695e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:35:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4998777a4bdsm246461745e9.0.2026.08.18.01.35.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:35:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787042141; x=1787646941; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=g5Sd4O06hDffRwPc1COMU+YEsbVDiujwTLscAEleQBE=;
        b=KWPBHij4ugu5oHxzFsj8zuM4b9bwNV19d5MZr3fblLsoLWrZDOvlDzCdnwuWRc7aF+
         FsNMCrNT4mhKPD1vc/23cR8R5TqcfD7EltqpUGGhIaZhOqCp8aNky2UqVVrIP0Pa769T
         uOYnqbuTO6d21H2Unu8YO7coEV7U7UiJemZ3JQcpcm6RKVBIbFfAb/XklM3vYH46X3TP
         HeZd/5TgX4rZsho2dQeMzMGR0lWbSEWr9JjdSJKQjzUSqszJxRj2frZeMPYK3XinBuO1
         7FTRg6kHwcP2IRhNvQntTKNHOLsVL9Nwutwqe6UJtfQN/pOKd5MUx+8xh9D2++QjHZ4v
         12hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787042141; x=1787646941;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=g5Sd4O06hDffRwPc1COMU+YEsbVDiujwTLscAEleQBE=;
        b=OjivArEDiLuZ1PJgn7MJnJ2Cz57+FtkD2NuORWtgskf5yzlcdrF0TWe/tBl1f750K5
         /IFOIGC7veqPVzFlmhhrUjWHNspUquESoXXyFnktSXutzjionGKWQsHx6ooCvwVHins/
         ObVnfi4BdqI9rV8ZY/uleiTwH9wzul+DqTdb4XSzjzSIxSciV9sYlU7TDnkGQZkgq1lH
         ntU1jnc6IUvwmhUuO9S9fw2/E2XdEpcyKvdnPl67jHt64UG4x4LHk83eQ8xgJQjnknYf
         MfwNMmlo9YnUDI4dINnaK18eADbHiA0SKGyFndM18nLigA0lsUBLEzokvsXiErqzytHA
         WXRQ==
X-Forwarded-Encrypted: i=1; AHgh+RreGBD1+XVYXD0KfyKoOk6sgpEN9vW+BGfSgzINgusV8zexKf7BDb7Gv8aKXa9OIXUBRhRWm0DX+vM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpVw4CIY02tv3VGEF+iEZ1fbeGbGRUKQpc7EzR/z0o2c+FyscW
	PPAdLhnTK9wTDFi9XQduLAwhQmQMpSpgOjSQfnowuIMkU97lcqnbiBZmd3nzkncbeg==
X-Gm-Gg: AR+sD11WYod3+hWCZr/ntyUNtYgq+fzxc8VV2DcQsi040oJg1GvOZxDhjZn5TEhJad+
	YX5myKI9kbDc/1V8fGqHttdVTqgpuHCmdBzqjlyEJK37bSkL9DvhSDwxL6R0P8U1V9u/VX/DN+8
	P8jOnJvchCP7+/fcXEacI3eh9ekVtlYdQIWu+I/wnivym5N90eiRNxgpB4xEe7AcjebNl25+CI7
	untNEfNjw3AkJzPYirxzo8b1GgP9BJ05Bz3xWayM8BQvBCoj/j/NXwHW4cq3wna+l1c0wXJpy8m
	8OIcDitVx5r2fGNFJRZnLgupd+qfmr8ZKYdMgHJACs6ItMS2q2zJOfBeBFQWZV2td2LvOKWuEae
	UcxOaBwUCygSberkT3X7A4abzRV2jrUOkglQ3aAgIfqnfB5U6LFzJ6G6vityKdz4lMqHlShcITS
	eWkRe1z2lUm9iyKjYwnr83KV+p803/mBFheZ8Kv9cd3Ks70WJq14P4taTI/pppp4+XbOGPdLqNQ
	KFK5oVq/HR8FFXqqRLTTPowu7fmUbftz91YBfjiBd5lFhvmZ1dz
X-Received: by 2002:a05:600c:34c7:b0:499:8afd:4a9f with SMTP id 5b1f17b1804b1-499a05ac869mr95670705e9.0.1787042141514;
        Tue, 18 Aug 2026 01:35:41 -0700 (PDT)
Message-ID: <331a3b8e-7846-42c7-b1f4-8e4951b8e84b@suse.com>
Date: Tue, 18 Aug 2026 10:35:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 15/17] xen/riscv: implement trap redirection to a guest
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <8b14a7926e42c7e3308dc7f730334fed56210d81.1784560663.git.oleksii.kurochko@gmail.com>
 <f3ca2cf9-49b9-4515-b634-6de4ae9614ce@suse.com>
 <41c9717f-6083-4669-8e60-20a023c3ae8f@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <41c9717f-6083-4669-8e60-20a023c3ae8f@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787042142-6D6D64E9-FB56CC0A/0/0
X-purgate-type: clean
X-purgate-size: 2200

On 18.08.2026 09:47, Oleksii Kurochko wrote:
> On 8/12/26 6:03 PM, Jan Beulich wrote:
>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>> Some traps taken by Xen on behalf of a guest can't or shouldn't be
>>> handled by the hypervisor and must be forwarded to the guest's own
>>> S-mode exception handler instead: e.g. when riscv_vcpu_unpriv_read()
>>> faults while accessing guest memory, or when emulation hits a condition
>>> only the guest kernel can resolve.
>>
>> Is the plan to use riscv_vcpu_unpriv_read() also for reading hypercall
>> buffers?
> 
> Yes, it could also be used to read hypercall buffers, but I don't think 
> it's the best option, as hypercall buffers could be larger than 8 bytes 
> (which is the size supported by the `hlv` instruction on the RV64 
> platform). For that case, I think it would be better to map the Xen page 
> corresponding to the GVA of the hypercall buffer and then use the usual 
> memcpy(). So, basically, use copy_guest() on RISC-V for that purpose.
> 
> 
>> In that case trap redirection shouldn't come into play.
> 
> It isn't mandatory to perform a redirection in the case of 
> riscv_vcpu_unpriv_read(), so if trap redirection shouldn't happen for 
> hypercall buffers, then the caller of riscv_vcpu_unpriv_read() needs to 
> handle that properly by checking utrap.cause. Something like:
> 
> ```
>      *insn = riscv_vcpu_unpriv_read(true, regs->sepc, &utrap);
>      if ( utrap.scause )
>      {
>          ...
>          utrap.sepc = regs->sepc;
>          utrap.stval = utrap.sepc;
> 
>          riscv_vcpu_trap_redirect(&utrap);
> 
>          return true;
>      }
> ```
> 
> So, if this cannot happen in the case of a hypercall buffer, then we 
> need to return -EFAULT in the if ( utrap.scause ) case.
> 
> I don't think I understand why redirection shouldn't come into play. Do 
> you mean that the hypercall buffer will always be available, and that it 
> is impossible for the hlv instruction to fail, so there is no point in 
> handling redirection at all in this case?

Failure to access a hypercall buffer should result in a -EFAULT return
value, not in any kind of exception.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:41:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:41:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393681.1632495 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFNU-0006Rk-If; Tue, 18 Aug 2026 08:41:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393681.1632495; Tue, 18 Aug 2026 08:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFNU-0006Rd-Fk; Tue, 18 Aug 2026 08:41:00 +0000
Received: by outflank-mailman (input) for mailman id 1393681;
 Tue, 18 Aug 2026 08:40:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01407da88000c4f3@swg.vates.tech>)
 id 1wwFNT-0006RX-If
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:40:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFNS-00CaPP-Nn
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:40:58 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01407da88000c4f3@swg.vates.tech>)
 id 6a841a89-bab6-0a2a0a5309dd-0a2a450ad468-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:40:58 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01407da88000c4f3@swg.vates.tech>)
 id 6a841a9a-f2d2-0a2a450a0019-b9ff1c22a45d-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:40:58 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01407da88000c4f3.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 18 Aug 2026 08:40:54 +0000
Received: from [192.168.1.17] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr
 [90.112.87.96]) (Authenticated sender: baptiste.le-duc@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 42EAB81F53;
 Tue, 18 Aug 2026 10:40:53 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=IklsQRnx0B+xkzztfnfSIBMnYqjrEZbU+kj5jgBOCZA=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=rtB9qb+9qsRQiyWw2VRScl9woxFQOS2+vDnFGLKkEMxpkZMIKbNSZKeqp2bhODYlrxVG3tbuf
 2S1d64mG6ZD0lgn+2aXU5Z1C5yr2l1jGho4ciwG9JGmg7v+OSoHNKrl9uWGl+uAUmUolnJNSVO6
 CmAzS9Gr6uk5zr0m9+Cc0VtyCwRiPCp6d/C2hnknmlP7TmAEtAVUknFEx3RQceb72Snox0hbUwn
 DpZbkK9hlEwECZBH6DlwMy7vKEYZg1OElYBiOgqBhJPhUmJ9X4odjw/ks5bUdbglGLtVYXFOLMs
 Dk33/4NoWyciUU/zZJNLh5NHIta5X+hynSNj7XM/sWSQ==
X-Zone-Loop: fb35c9fbc1ee52b780434731d60d661f81d30f3e7336
x-campaign-type: default
x-transaction-id: b6fa80cf-763e-4c0f-9f77-b176cc932277
x-swg-uid: 01-690785de-fb32-41f6-8156-d14ab0a2a92e
X-Mailer: Sweego
Message-ID:
 <1787042454.8631fc262581453bbf619ec5b2062170.1a01407da88000c4f3@vates.tech>
x-swg-bid: 1787042454.8631fc262581453bbf619ec5b2062170.1a01407da88000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1 10/17] xen/riscv: introduce
 vintc_state_{save,restore}()
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Jan Beulich <jbeulich@suse.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <ed89d5c2-43b6-45d2-a426-0affe3bfd1bd@suse.com>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <e71f53f1165619fabb9f79f34cc931cd4296af67.1784560663.git.oleksii.kurochko@gmail.com>
 <1786614174.8631fc262581453bbf619ec5b2062170.19ffa80d28a000c4f3@vates.tech>
 <cae4c5ef-cc4a-47a0-90fa-2f84c00ba4a6@gmail.com>
 <1787041722.8631fc262581453bbf619ec5b2062170.1a013fcb15a000c4f3@vates.tech>
 <ed89d5c2-43b6-45d2-a426-0affe3bfd1bd@suse.com>
Date: Tue, 18 Aug 2026 10:40:42 +0200
X-Developer-Signature: v=1; a=openssh-sha256; t=1787042453; l=2240;
 i=baptiste.le-duc@vates.tech; h=from:subject:message-id;
 bh=xaepcaGPOu2kKQjFcxUSW1pbIjRxONjJTMxVE6Deo7Q=;
 b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgQKqDblDzOFimZyyhA+RsKnxim2EiA
 60KatQBsuueKYUAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA
 QCkouXyAKC8AFzWoblFyekFe7dBiF60hb41u6SRrVC5ztQfkOPEBCrKlfUAbQt8GUyirAuY9z9m
 SkjezJR2yigA=
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=openssh;
 fpr=SHA256:YieMhmvNcCYpeUbL6HuedGp4rwSlu4mQ+D7EJoVHM+k
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787042453603
X-purgate-ID: tlsNG-4011c0/1787042458-597C2CFC-9DD9A8BE/0/0
X-purgate-type: clean
X-purgate-size: 2244

On 2026-08-18 10:31 +0200, Jan Beulich wrote:
> On 18.08.2026 10:28, Baptiste Le Duc wrote:
> > On 2026-08-17 10:31 +0200, Oleksii Kurochko wrote:
> >>
> >>
> >> On 8/13/26 11:42 AM, Baptiste Le Duc wrote:
> >>>>   #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
> >>>> diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
> >>>> index 372c8d3a20..879d513374 100644
> >>>> --- a/xen/arch/riscv/intc.c
> >>>> +++ b/xen/arch/riscv/intc.c
> >>>> @@ -163,3 +163,17 @@ bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
> >>>>   
> >>>>       return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
> >>>>   }
> >>>> +
> >>>> +void vintc_state_save(struct vcpu *vcpu)
> >>>> +{
> >>>> +    const struct vintc_ops *ops = vcpu->domain->arch.vintc->ops;
> >>> Is there a situation where ops could be NULL? If yes, add a check.
> >>
> >> It is unlikely that there is nothing to do during a context switch for 
> >> vINTC, so vINTC should provide an implementation for saving and 
> >> restoring its context. This also ensures that a NULL pointer dereference 
> >> will lead to a trap, allowing us to catch cases where a 
> >> context-switch/restore handler is missing.
> >>
> >> Even if it turns out that vINTC does not need to perform any actions 
> >> during a context switch, it is perfectly fine to provide an empty 
> >> implementation. However, as mentioned above, this is unlikely. 
> >> Therefore, having a NULL pointer dereference here is intentional: it 
> >> helps catch cases where someone adds a new interrupt controller driver 
> >> but forgets to implement the corresponding context switch functionality.
> > 
> > Thanks for these explanations. However, wouldn't it be better to have a
> > dedicated BUG_ON in case of NULL dereference to indicate clean call
> > trace to people who missed to implement context-switch functionality?
> 
> How would BUG_ON() provide any better (or worse) call trace, compared to
> a NULL deref?

I wanted the file:line and function printed directly, but sepc in the
trap's register dump resolves to the same place, and BUG_ON() ends up in
the same handler anyway. Fair enough, dropping it.

Thanks,
Baptiste

> 
> Jan
> 
> 
> 




From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:41:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:41:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393686.1632505 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFOC-0006sg-SA; Tue, 18 Aug 2026 08:41:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393686.1632505; Tue, 18 Aug 2026 08:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFOC-0006sZ-NX; Tue, 18 Aug 2026 08:41:44 +0000
Received: by outflank-mailman (input) for mailman id 1393686;
 Tue, 18 Aug 2026 08:41:43 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwFOB-0006sP-Ry
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:41:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFOA-00ET6n-Qo
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:41:42 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841ac6-e002-0a2a0a5209dd-0a2a4504a300-2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:41:42 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841ab5-b57f-0a2a45040019-d155802bd0f3-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:41:25 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-495757ccbc1so39494645e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:41:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996100184sm273236125e9.1.2026.08.18.01.41.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:41:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787042485; x=1787647285; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=VYJI/TpKxX/BjSnlDjBDEhH+0fQCeiA84iddIrpDSj0=;
        b=J0XrM7+nyCi4gO0Ba8uyA4HB9TUmeYS5zMU9R2i/ai59yZ9Csgic1+t7vXGIDVIqh9
         wi4MQg/FYzs5mAalBdV5sdSssbjLAsbHRZtH7D4Bi5ydMHXqsWZnVXTMgyi8otumZ2It
         R59wdFV5I59ZL1Ye6emvn9VDk2Y3gwHeiBTwg81eX+VjV7e8iaiBZnejiXNJMokT9RKh
         3+g8r10C143h4JBeoxtVYDN55q+BWrPYF/BhsiUfjwaO/44JJir+Ayo8mH8dNiPbW+la
         gTmQzjA1MEMoWhTgtcCCaaumz6lDpiKu5lgw11zyk2r322GMlBjrQu0PZxtsFkM6zlve
         cupg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787042485; x=1787647285;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=VYJI/TpKxX/BjSnlDjBDEhH+0fQCeiA84iddIrpDSj0=;
        b=P7UMDjrAzYjV1MKgSLwtySPj7SU1RbGEhhfxBMdbVBfTo2ntALfKfds7LRcLzFAhCi
         Eml2fOwUHW5pFiZpol3vjeiYxHFD0O9NYLj6bQVxbIjDHfpXc4C5GcCzFGmlYyQFgUgN
         XRk33SIVDrHvFT+UpbfYr5iU42S9Go5ZMX5JqtzzG7znvP7bgxzjs1YlbSVv3kSiUJ7H
         fkT5XQ09Jm6crKqGo3F9bKG7P/uaaAOrlWpWNsl/p8aGym7DadA4GWcpeG9RCvkcYIrY
         /VqCi9pnITec9IcO17Mk3Z/lvYODqX8lrWvhtHnmZYUljz3dHjojznCsPWZA3hL+idXU
         oQHA==
X-Gm-Message-State: AOJu0YzUAHY4VN9egs4Y4CQtZa24WW0ANPZ+NeGZZdUjmeLXW5UFFhf1
	fsWOcKy4nSNiNuhP0XWCS8+Jhw4OadNe0dKMj5XOuLHLGfNLRvfToCSoL+YHJ1ox2w==
X-Gm-Gg: AR+sD102om9SL7XKdB5Ax7L9cLvMRkJyp7Kj5pRWcJ5PU1K9tQs90dk0R3+LPPCvARJ
	w84iLCmXjyMekSs24n7tymU2Vi60jDD9UHsojOlLpqHpQDrnoxIQcia4oE8GIsRoBGyot4ZmrBG
	qOjd1dTmq3dMWjjHj3xej7TAaOHaIbjXan8VSXSBiLufuX+53v3Rk8urfOMEx0B9OcKHDjQvSa3
	S8fbsfvmm+F4IHLu6Hb73Faq8ptaYi6KjOVxOp4PBI6WrDdcOMXnESTYXO/i9ECiCWAGDwtBPjt
	7+jEu4VWGqzZImxXs6tTgeoeqiQ3TTjShe0EFgS1ynsLhjQHgEDYYarsABotQPZ3TKAegStC3Pm
	ZxxH/CqNBh1EKVdO5FcITpzseo8dmPtuXEN7JwX8sWzDNRWIRVd6HwZjOUkPsG3Me0IimKjp9lk
	qkUTy2m8mHThaEgqt/VJpsXSHcTKyu4F7yJktGDb8z6b6/3643KzogGd1OZy+JQ1YOxMGQKmXhE
	NwqMgtZJn2YNJR1GFWl//LFnRVy6WdZDFCBOl8i7QtF1FqW2/ldGXyFY6UHpzo=
X-Received: by 2002:a05:600c:638e:b0:499:900c:9c68 with SMTP id 5b1f17b1804b1-49994db0768mr319876375e9.6.1787042485359;
        Tue, 18 Aug 2026 01:41:25 -0700 (PDT)
Message-ID: <69356789-a65d-4580-a240-be088004599d@suse.com>
Date: Tue, 18 Aug 2026 10:41:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/2] xen/console: add build-time rate-limiting controls
To: dmukhin@ford.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
 julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
 sstabellini@kernel.org
Cc: xen-devel@lists.xenproject.org
References: <20260811233824.1874525-1-dmukhin@ford.com>
 <20260811233824.1874525-3-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260811233824.1874525-3-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787042485-C14D3B50-F514F4F5/0/0
X-purgate-type: clean
X-purgate-size: 1526

On 12.08.2026 01:38, dmukhin@ford.com wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -672,4 +672,34 @@ config PM_STATS
>  	  Enable collection of performance management statistics to aid in
>  	  analyzing and tuning power/performance characteristics of the system
>  
> +menu "Console rate-limiting"
> +	visible if EXPERT
> +
> +config PRINTK_RATELIMIT_MS
> +	int "printk rate-limiting time window (milliseconds)"
> +	default 5000
> +	help
> +	  Specifies the time window, in milliseconds, for rate-limited printk
> +	  messages. No more than `CONFIG_PRINTK_RATELIMIT_BURST` messages will be
> +	  printed within this window.
> +
> +	  Setting this value to 0 disables rate-limiting entirely.
> +
> +	  Configurations using a value other than the default of 5000 are not
> +	  security supported.

Do we need to be as strict? Specifying a larger value wouldn't increase
the risk of log flooding.

> +config PRINTK_RATELIMIT_BURST
> +	int "printk rate-limited message burst size"
> +	default 10
> +	help
> +	  Defines the maximum number of rate-limited printk messages that may
> +	  be printed within each `CONFIG_PRINTK_RATELIMIT_MS` time window.
> +
> +	  Setting this value to 0 disables rate-limiting entirely.
> +
> +	  Configurations using a value other than the default of 10 are not
> +	  security supported.

Same here - lowering the number (to a non-zero value) wouldn't increase
the risk of log flooding.

(Question to everyone, not just Denis.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393701.1632547 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUr-0008Dk-KC; Tue, 18 Aug 2026 08:48:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393701.1632547; Tue, 18 Aug 2026 08:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUr-0008AV-4M; Tue, 18 Aug 2026 08:48:37 +0000
Received: by outflank-mailman (input) for mailman id 1393701;
 Tue, 18 Aug 2026 08:48:35 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUp-0007fC-6l
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUo-008KNP-JS
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:34 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:34 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-9
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:34 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:30 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LbB4Bki1UDSxb2w5ZS6JHWXeqLqZ6ougu7f7IpvjnaNot7Oce4anrNT4j/V8SFhcVbQsWoa7hal3RuOVFyusRuJHErlbGO9J1MIoyZYTnf4HrOsZz4nrqOMLwoAzQ0+0x8n3IV5ZbhbildfpQzkzrEhxk8lIU/Rs+xh2iu37Y8pTI+WLA06whA34ex0NwLsJBqLNuYdj38HmDhakECYR8bcCjp+p9nIbI6tGpdFRHJWzXZB0sE2sW0ojSy5B+NrPRZvIVJDM3utoTe1ieGnBK9FS4XU6nFMVYJWF1vGdEmoTUV+LHlX+j+Zoy31I4GO2P0h677R2uQV7tQAIOdffWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=u9FElmracPDBtWbdVP3t7NJG1uYSKXKX5uvMeAKBI64=;
 b=BYireIyh39SkC8+k81cuxMI38w2FIvahHSmh628OXjpV2Rc1/ANnzNF9Ak2EIsDcpVDqTiCiYQbqA0LufyJbMRjFmTnR8a+QY8X+SeWVikLIgeHBtdFrkTxSWTEszXeOHwI51ymiy/QG1N4EmbJ1Lrqkl7PDyzGBY1PDoXLH126dgSt9gRM/dHucWVfE2TBAE6rcy155w6NWsWf16qP/qzScSm7sp+ZqVbHPhklSeBwOzvJcSrSh24e/FXV0HT2Zf/WcdrxRYC3qV39zfu8wlFGSOY6T8zSweLsS2dPzV/zPmaGAcGyNrv0Yzwbokwdp1JFgFNSZSV/Nq5h1vWrYcA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=u9FElmracPDBtWbdVP3t7NJG1uYSKXKX5uvMeAKBI64=;
 b=j/6jBMwqPA9ZEqUHy0S+w5F/tbYlouSFvndcTYT7Xrs7MwUTP0WykRctjyYOamZ0iRYeeDAasfFp/rdsSc522ophXykth86aqTAzst4V945IR675RFQaAVvle9M0bV7wQgWstg32HC39m4/IPrl2+8AwYPpCKk7f1PCY2I3GRxcz/nOdku7QJBvuqGjI6E6OkfpUZb/XJ5GCuLpMg1RkjGmv26vIpkeor9mJMR4QmXUldiy2F4iHW9udXi6WCtFBA6vAmpAnx6TXairE6/TQecdyYlTbsJ84lYauSQJErgZxS7Ynp+8tpZMtbuxwc6007tcu2Ex9LQssgqeQUOe0TA==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, Jan
 Beulich <jbeulich@suse.com>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger@xenproject.org>, Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>, Connor Davis
	<connojdavis@gmail.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>, Teddy
 Astie <teddy.astie@vates.tech>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
Subject: [PATCH v9 4/6] arm/sysctl: Implement cpu hotplug ops
Thread-Topic: [PATCH v9 4/6] arm/sysctl: Implement cpu hotplug ops
Thread-Index: AQHdLu5YSYy+G2Q5nkKDlWjuRtlO5A==
Date: Tue, 18 Aug 2026 08:48:30 +0000
Message-ID:
 <43447ba62f39a46ceeafca58a4212fb8c07497e1.1787042017.git.mykyta_poturai@epam.com>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: f61ce5f9-a161-4e47-104e-08defd057a9d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|7416014|23010399003|366016|10067099003|56012099006|11063799006|10063799003|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 G/j6kTgSqTo9kIWHW5zrl4oCIEIxfneTVrr7+EkPEbpxVi1PnTBPyRbSFPF0YLzFhn72tNjZEMOGeOZTTkyNCKhWquHctZiK8lOkDSWvSiyFdvrHwrgJRmHkRfEyJI8Dbiq53TK506J9G3vhkObJs+aZ/sHxNSZ1dzb+UHlBFVcyDH5uci0kE7cCfjAwcs4U0MYqS1hzr+QkBl+cXHZIogLWQv9W4TLTRQo3lrDTSDAt4uo7uDKh/qctbcmXUHmDSui8V7a/lxKGIHNwuM7xBFSmDigeIOQuPXbETVbQOKuaOANmi0jUzbCqkULPtDEyTDO7iZsYWXMQl8tWGAwNZCRQFK4XGgFtP0qvsFKrbJpsysqrFPuFvY5zmtCTn8ryv5zpxLu691LaPNa86oEFRLhH5dIHbI9cyGpj1tf6X6jEpYXGLzlVY3QxFgOp2fpWmQSmY55YfqC/OyeONbm9J0AZP8lc0J2pnNfIAaTCjw+hLkhpgMPqR2dXXbNyWpG6isGEejA1FX6OV1TyioWRpSB9EVDdZjSLg9vay93IbVqgxDocwHs2p8KAARlNKP6XaHjP19GCmpFmebHVMN4Ced4PTULruORYhb39OLEZeZjO4XsKHo8fLObyHShBQ8ynCr+JwckmNabBBeAObRT+rYwoRTI68l5cmDemUKFRBd3Psddbz9OL/mIujjP5ZTcuzN2Dxg6vi7fIVKzWqtEClUbo0sUthX1+HemBB+1lxO0=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(10063799003)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?6NLgsTteJXV8hhDhISxTkaOtNYp5ZztXB135TA6M9bCeiu9TOueygPRdpp?=
 =?iso-8859-1?Q?ufoKgtqubRT+FRwtCh68n04U4J4fkHgWSJ5jsLZ4pFkBDyu1Ry6ZYflZIM?=
 =?iso-8859-1?Q?CCS6CkrA+O45qheX2w0M4AYWUXF3cFQ5ioFwJP7ZVAE0jqF7Cz+FtxU1Fl?=
 =?iso-8859-1?Q?XlBqHgoFPiN+9GAvDTd+YxDQ8HBK9Mt3+4ztS81TLk77NqnWIElBgXRKbD?=
 =?iso-8859-1?Q?Zznj4E9kP1+ZNy9ytQhZAh1jXxVtI/GNzB1i93BmG76GiIUTzbf/OCxYZp?=
 =?iso-8859-1?Q?q0q3p8J8RYBtX1H7g+qnLzQDM5ver0u6tQWKuu8Tu+1iGbOpKUiNnPxGy7?=
 =?iso-8859-1?Q?ChzneK6K5pND1/jjWY5uWU/R+c204iFCQ0D5sTuEefsQWfpneH9ieQT+5X?=
 =?iso-8859-1?Q?J80Ugmb+AHmQugChhGntmEdh1Q5M7Hh5XBnyuoLlevLaVayIRpHP4b525O?=
 =?iso-8859-1?Q?F7vT0C0xokwjlTdCetCjbir6Vhz3nFsDHN37QNmIk29M4oZFDCjDAJa/2L?=
 =?iso-8859-1?Q?9gBpoV+WBb2/yO05FnLpXvc5gNWWYv87W0kxvEpRzLeF2WutubuMc43uuB?=
 =?iso-8859-1?Q?GHmspcv0p1xFdbfuwOWPiPzFWJjPdWkYlG0qWRWA0x4sl8lZ49Eh71FYb4?=
 =?iso-8859-1?Q?GzvzjFZLYFWr65I/A/dTJh+QPp1U6cUSbIxenigvIK0T6gzzrH8KIy06RR?=
 =?iso-8859-1?Q?XU880KK1K/o+dr4btjFy0jTk04vJY4Y9nFEreAhmMF8ItFKrA8BsTWcjQ/?=
 =?iso-8859-1?Q?0+tpc1oKqBUc5Oi/6EeN3TD8xgtRTFn+vKdM821x8SCgnCYzZK+EhqLJA3?=
 =?iso-8859-1?Q?601m43rhlk6NXkl85/zZgnRNdx1LoZLJaPi0mmj/HXa9L8OTxxiSy3mSUp?=
 =?iso-8859-1?Q?pte5ecUf68zJgBr79+4GgJGAhw8KSd315DocSmKVDZwD7eYt7vBQobOXD0?=
 =?iso-8859-1?Q?0n6014X7ut3GrcW7nxVYdc/4a4HdLasQYvi3/2p9NIEw+Dqs2TJDgWncT+?=
 =?iso-8859-1?Q?WWThheoMGC4OM3R0XBxYEGdWJ/ATO+k3NWNMJby4saKBTaPYOhTFi1fa1S?=
 =?iso-8859-1?Q?Ragq6UgLEW/yKyNDF/505bSusCiixKg0/aDmP3uRVTjh/YSMsuPRfVkv0T?=
 =?iso-8859-1?Q?K0pOc8x0D7uJQcr2wQxT6WaOs0UK/iQS3sluqCuzYt3A9kVWg+qMNfSWVV?=
 =?iso-8859-1?Q?5xH0pievC74ussa7aUVPDyIwJIT0zZ2yPbLJSsnnJ761cg/agldff1xPYD?=
 =?iso-8859-1?Q?qmXtwKR4MyuXs9Rf9jC+ObMiKQvlUspCqT40nbGYpJevQpo78B5vY8o5+v?=
 =?iso-8859-1?Q?rxiG6SI55fvbQ10irKLb0NUnlRtiDBfqJJBB4yJW+vma/FkgM579hgVyP5?=
 =?iso-8859-1?Q?wiHR9QLawhk0GHNMMyUOF0PC4wH8bPs5CHSnhy2ql/1d9by+R72EvjDMUU?=
 =?iso-8859-1?Q?aQObYHdkPiW0H+4DWjKVs3VTqdOGIVLrM/NLH6Sbv7n7oNL6e//KJuajuM?=
 =?iso-8859-1?Q?DI3XoGeLRIbdEOEVcmMMsAJngGkus2Qv0qGd5Y/gybehTQv2fKXEJgBhLY?=
 =?iso-8859-1?Q?t6qd457N+oIIw3AFF7GtE+VHrEuSNhde8a/8T8MPmJ0FMWi+CSjiDRcjCb?=
 =?iso-8859-1?Q?TPkQUGj2NHsWVkUSEp27pPcmZwnPF54wF4h71mWMSfINAAq1YIURLivlUT?=
 =?iso-8859-1?Q?sFbY2u5/W8W6zBgD47W14G7pY8tE+sCqT5DGe/tE663OjY9zt2UODsk5po?=
 =?iso-8859-1?Q?bdMQ42rBS/EelNxf06OQZd6CDk2T3bXlCBSi+QwRgGgvsp6H3hl3LoBMu0?=
 =?iso-8859-1?Q?naTeFC8MV0m9pRa6RbCMPFS37RlOnVQ=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f61ce5f9-a161-4e47-104e-08defd057a9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:30.5777
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: c1DzjAG7mKkaFXnmVCZEKGt6s1Je30JQgYxVG0qjBlIRiIBJfOi9EA6eP2BSgNNyJKjdg+LT9+zrRXALGtVFRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042914-F20A82AC-B17930F2/0/0
X-purgate-type: clean
X-purgate-size: 10340

SMT-disable enforcement check is moved into a separate
architecture-specific function.

For now this operations only support Arm64. For proper Arm32 support,
there needs to be a mechanism to free per-cpu page tables, allocated in
init_domheap_mappings. Also, hotplug is not supported if ITS enabled,
and partially supported FFA, or TEE is enabled, as they use non-static
IRQ actions.

Remove ifdef guards for x86 in flask, as cpu hotplug is now
supported on more architectures.

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
v8->v9:
* simplify dependencies of config CPU_ONLINE_OFFLINE again

v7->v8:
* simplify dependencies of config CPU_ONLINE_OFFLINE

v6->v7:
* use IS_ENABLED istead of ifdef in more places
* remove unneded variables
* more explicit fallthrough in do_sysctl

v5->v6:
* fix style issues
* rename arch_smt_cpu_disable -> arch_cpu_can_stay_online and invert the
logic
* use IS_ENABLED istead of ifdef
* remove explicit list af arch-specific SYSCTL_CPU_HOTPLUG_* options
from the common handler
* fix flask issue

v4->v5:
* move handling to common code
* rename config to CPU_HOTPUG
* merge with "smp: Move cpu_up/down helpers to common code"

v3->v4:
* don't reimplement cpu_up/down helpers
* add Kconfig option
* fixup formatting

v2->v3:
* no changes

v1->v2:
* remove SMT ops
* remove cpu =3D=3D 0 checks
* add XSM hooks
* only implement for 64bit Arm
---
 xen/arch/arm/smp.c             |  9 +++++++++
 xen/arch/ppc/stubs.c           |  5 +++++
 xen/arch/riscv/stubs.c         |  5 +++++
 xen/arch/x86/include/asm/smp.h |  3 ---
 xen/arch/x86/smp.c             | 34 +++------------------------------
 xen/arch/x86/sysctl.c          | 11 ++++-------
 xen/common/Kconfig             |  4 ++--
 xen/common/smp.c               | 35 ++++++++++++++++++++++++++++++++++
 xen/common/sysctl.c            | 34 +++++++++++++++++++++++++++++++++
 xen/include/xen/smp.h          |  4 ++++
 xen/xsm/flask/hooks.c          |  2 +-
 11 files changed, 102 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index b372472188..0ea64d2ee1 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -44,6 +44,15 @@ void smp_send_call_function_mask(const cpumask_t *mask)
     }
 }
=20
+/*
+ * We currently don't support SMT on ARM so we don't need any special logi=
c for
+ * CPU disabling
+ */
+inline bool arch_cpu_can_stay_online(unsigned int cpu)
+{
+    return true;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c
index a333f06119..2cd116c2f2 100644
--- a/xen/arch/ppc/stubs.c
+++ b/xen/arch/ppc/stubs.c
@@ -101,6 +101,11 @@ void smp_send_call_function_mask(const cpumask_t *mask=
)
     BUG_ON("unimplemented");
 }
=20
+bool arch_cpu_can_stay_online(unsigned int cpu)
+{
+    BUG_ON("unimplemented");
+}
+
 /* irq.c */
=20
 void irq_ack_none(struct irq_desc *desc)
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index 3a7953593d..a8b2f54f3d 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -65,6 +65,11 @@ void smp_send_call_function_mask(const cpumask_t *mask)
     BUG_ON("unimplemented");
 }
=20
+bool arch_cpu_can_stay_online(unsigned int cpu)
+{
+    BUG_ON("unimplemented");
+}
+
 /* irq.c */
=20
 void irq_ack_none(struct irq_desc *desc)
diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/smp.=
h
index 3f16e62696..cb3e0fed19 100644
--- a/xen/arch/x86/include/asm/smp.h
+++ b/xen/arch/x86/include/asm/smp.h
@@ -50,9 +50,6 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t =
pxm);
=20
 void __stop_this_cpu(void);
=20
-long cf_check cpu_up_helper(void *data);
-long cf_check cpu_down_helper(void *data);
-
 long cf_check core_parking_helper(void *data);
 bool core_parking_remove(unsigned int cpu);
 uint32_t get_cur_idle_nums(void);
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 9046c826f8..caf4411705 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -419,37 +419,9 @@ void cf_check call_function_interrupt(void)
 }
=20
 #ifdef CONFIG_CPU_ONLINE_OFFLINE
-long cf_check cpu_up_helper(void *data)
+bool arch_cpu_can_stay_online(unsigned int cpu)
 {
-    unsigned int cpu =3D (unsigned long)data;
-    int ret =3D cpu_up(cpu);
-
-    /* Have one more go on EBUSY. */
-    if ( ret =3D=3D -EBUSY )
-        ret =3D cpu_up(cpu);
-
-    if ( !ret && !opt_smt &&
-         cpu_data[cpu].compute_unit_id =3D=3D INVALID_CUID &&
-         cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) > 1 )
-    {
-        ret =3D cpu_down_helper(data);
-        if ( ret )
-            printk("Could not re-offline CPU%u (%d)\n", cpu, ret);
-        else
-            ret =3D -EPERM;
-    }
-
-    return ret;
-}
-
-long cf_check cpu_down_helper(void *data)
-{
-    int cpu =3D (unsigned long)data;
-    int ret =3D cpu_down(cpu);
-
-    /* Have one more go on EBUSY. */
-    if ( ret =3D=3D -EBUSY )
-        ret =3D cpu_down(cpu);
-    return ret;
+    return opt_smt || cpu_data[cpu].compute_unit_id !=3D INVALID_CUID ||
+           cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) <=3D 1;
 }
 #endif
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 10d485e633..a4254beabb 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -121,13 +121,13 @@ long arch_do_sysctl(
=20
     case XEN_SYSCTL_cpu_hotplug:
     {
-        unsigned int cpu =3D sysctl->u.cpu_hotplug.cpu;
         unsigned int op  =3D sysctl->u.cpu_hotplug.op;
         long (*fn)(void *data);
         void *hcpu;
=20
         if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
         {
+            ASSERT_UNREACHABLE();
             ret =3D -EOPNOTSUPP;
             break;
         }
@@ -135,13 +135,10 @@ long arch_do_sysctl(
         switch ( op )
         {
         case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
-            fn =3D cpu_up_helper;
-            hcpu =3D _p(cpu);
-            break;
-
         case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
-            fn =3D cpu_down_helper;
-            hcpu =3D _p(cpu);
+            /* Handled by common code */
+            ASSERT_UNREACHABLE();
+            ret =3D -EOPNOTSUPP;
             break;
=20
         case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE:
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f029addbfd..4b74392984 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -645,8 +645,8 @@ config SYSTEM_SUSPEND
=20
 config CPU_ONLINE_OFFLINE
 	bool "CPU online/offline support" if EXPERT
-	depends on X86
-	default y
+	depends on !ARM || !HAS_ITS
+	default X86
 	help
 	  Enable support for bringing CPUs online and offline at runtime. On
 	  X86 this is required for disabling SMT.
diff --git a/xen/common/smp.c b/xen/common/smp.c
index a011f541f1..16f4ed2d4e 100644
--- a/xen/common/smp.c
+++ b/xen/common/smp.c
@@ -16,6 +16,7 @@
  * GNU General Public License for more details.
  */
=20
+#include <xen/cpu.h>
 #include <asm/hardirq.h>
 #include <asm/processor.h>
 #include <xen/spinlock.h>
@@ -104,6 +105,40 @@ void smp_call_function_interrupt(void)
     irq_exit();
 }
=20
+#ifdef CONFIG_CPU_ONLINE_OFFLINE
+long cf_check cpu_up_helper(void *data)
+{
+    unsigned int cpu =3D (unsigned long)data;
+    int ret =3D cpu_up(cpu);
+
+    /* Have one more go on EBUSY. */
+    if ( ret =3D=3D -EBUSY )
+        ret =3D cpu_up(cpu);
+
+    if ( !ret && !arch_cpu_can_stay_online(cpu) )
+    {
+        ret =3D cpu_down_helper(data);
+        if ( ret )
+            printk("Could not re-offline CPU%u (%d)\n", cpu, ret);
+        else
+            ret =3D -EPERM;
+    }
+
+    return ret;
+}
+
+long cf_check cpu_down_helper(void *data)
+{
+    unsigned int cpu =3D (unsigned long)data;
+    int ret =3D cpu_down(cpu);
+
+    /* Have one more go on EBUSY. */
+    if ( ret =3D=3D -EBUSY )
+        ret =3D cpu_down(cpu);
+    return ret;
+}
+#endif /* CONFIG_CPU_ONLINE_OFFLINE */
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 8fb5ff0af3..42ad7accd0 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -475,6 +475,40 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_=
sysctl)
             copyback =3D 1;
         break;
=20
+    case XEN_SYSCTL_cpu_hotplug:
+    {
+        unsigned int hp_op =3D op->u.cpu_hotplug.op;
+        long (*fn)(void *data);
+        void *hcpu =3D _p(op->u.cpu_hotplug.cpu);
+
+        ret =3D -EOPNOTSUPP;
+        if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
+            break;
+
+        switch ( hp_op )
+        {
+        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
+            fn =3D cpu_up_helper;
+            break;
+
+        case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
+            fn =3D cpu_down_helper;
+            break;
+
+        default:
+            fn =3D NULL;
+            break;
+        }
+
+        if ( fn )
+        {
+            ret =3D continue_hypercall_on_cpu(0, fn, hcpu);
+            break;
+        }
+    }
+
+        /* Use the arch handler for cases not handled here */
+        fallthrough;
     default:
         ret =3D arch_do_sysctl(op, u_sysctl);
         copyback =3D 0;
diff --git a/xen/include/xen/smp.h b/xen/include/xen/smp.h
index 2ca9ff1bfc..04530738c9 100644
--- a/xen/include/xen/smp.h
+++ b/xen/include/xen/smp.h
@@ -76,4 +76,8 @@ extern void *stack_base[NR_CPUS];
 void initialize_cpu_data(unsigned int cpu);
 int setup_cpu_root_pgt(unsigned int cpu);
=20
+bool arch_cpu_can_stay_online(unsigned int cpu);
+long cf_check cpu_up_helper(void *data);
+long cf_check cpu_down_helper(void *data);
+
 #endif /* __XEN_SMP_H__ */
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 11a77f0e28..863b66ec58 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -957,7 +957,7 @@ static int cf_check flask_sysctl(const struct xen_sysct=
l *op)
     case XEN_SYSCTL_getdomaininfolist:
         return flask_getdomaininfo(dom_xen);
=20
-#ifdef CONFIG_X86
+#ifdef CONFIG_CPU_ONLINE_OFFLINE
     case XEN_SYSCTL_cpu_hotplug:
         switch ( op->u.cpu_hotplug.op )
         {
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393698.1632523 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUq-0007nC-11; Tue, 18 Aug 2026 08:48:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393698.1632523; Tue, 18 Aug 2026 08:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUp-0007mb-TR; Tue, 18 Aug 2026 08:48:35 +0000
Received: by outflank-mailman (input) for mailman id 1393698;
 Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUo-0007eo-08
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUn-008KNP-D3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:33 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:33 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:33 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:29 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EokPi8gvXEpmR1NZdzLo3h8Tj1Oozwt3FD3VmJFZltcqdyywscUVHoN7UZnGGjn6RQG6IPjc4SH69UI/8F/ypYgbNVfEhpwHypfrSgJjVP3HjxxbenEXTerUfMsiDinUNAvzlOGfc1EsKr8lDnIl+Yo2knBTLYpwuKnKevWNZWJ/TWFWu4QKzPdWX9cP15Mmct29j1D/ST7HYrun+xgE1U4glp6GJ5y7ysKvw3va8ceG9RIMxGDs+nyJcJDwuEDNv8i9XOHEhktm0Ve0odVmZYgUZEgiQ6d2/PdW7/ffAXTOJdkHgJQp+Fwpdwd/ZE4wnhS1imiGALAOEMQ7xvq/4g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=isjpLrgeDc/7t9NzHLhmfoXOeBmp97fvsmTC4cCrND8=;
 b=keTaaUy4uZwdIO8+3Q61c0a/yud41MW0knPxzegKdHp8CZYeefI7Kcai/w2I0lyxyhRvkdI9WZQ5AbaP6ESRwQzPTZeJFWhN5SGqusKy64xGhf/8kHfQWhQWf6vE1gwS78iRWziAiv5yKh1UZ4qTpbNckrZwY/OtCJII/UH3mGV6D2cvtslH8Nf0mB5puUQZURzIqa9YsO+z8Hq5RjYckKv7Ycz5rLdnHqKGcGK3ID4ZJD4Kr1bY+241WJycX3IMoFxMSr+9WaSC371ewgUnZ9IuzC96rSAK8Ct2S0GOr+7cSmaIXsWngQcrpfbk7GySG1oqBxdKlI34yzRh/8ZoCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=isjpLrgeDc/7t9NzHLhmfoXOeBmp97fvsmTC4cCrND8=;
 b=LCwnMbYDODiRop9+01QMlVVjSM2HcxkziiQdGlVJ22INCSoKb9xX53PegNqguXu6nwboq+uJ46VTXeaR9SSm0CnyzdFG/hPUMStLjy/qmJ8W/INvzms2sAY5v8vt27Fc13dMBH1bRKjGAaDQYWU/IcPtAnJWozfo3xIX1BnAV4iURdrw228Po1bB7IPTnQ9vJuMeKrRZDCVPq42PVUrZQBfQ9lrz3XNH6LracQs+TXd/XumeRHvqpUeGlqSSULwGXE3K2kBWnctqcTnQUUfdKiE95cDx8gZNeoDWIt3Yvsq6UZBtZSwfjrD9Es3FTzXlkhQ5mEV8AVXAmn+Z76GrDw==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, Jan Beulich <jbeulich@suse.com>, Andrew
 Cooper <andrew.cooper3@citrix.com>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD
	<anthony.perard@vates.tech>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, Oleksii
 Kurochko <oleksii.kurochko@gmail.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
Subject: [PATCH v9 0/6] Implement CPU hotplug on Arm
Thread-Topic: [PATCH v9 0/6] Implement CPU hotplug on Arm
Thread-Index: AQHdLu5XTX2wVWAf/0WnWqy3wZ0dQA==
Date: Tue, 18 Aug 2026 08:48:28 +0000
Message-ID: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: bc66cc7c-eada-494d-e49c-08defd0579a8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|7416014|23010399003|366016|10067099003|56012099006|6133799003|11063799006|18002099003|38070700021;
x-microsoft-antispam-message-info:
 t99q6yPgpznvuNdzvbMX7ogkpQoJAejuYNsTHKblEeIr3Sjp8rH7xRBfXlvr5ih0tN9dotyECK1sp5irVbQvJXgGrdzr2kvJw/Pw1Dyfi7LtLwOeIuveYb5wrSNgQfaOvc/o7NNX8C1WD1oiMLYf5J547KCbzIP8hxNmhO32CosLAj9HGY/cwAeKdOPejJ6flQbI1I9vy9lCXvuyIefYAPpmcVVWYDOBWDJLOoK9S5ZHmbKASeCrbGU5EQc0aPV4qk8urxZRpfJ0JQOe0qJzTR9Tv+bWSEtKsh5AlLNSWBtJJCkG6MF6uwJYNIaIKIjD7chYhavRYNTeiT8w1Dy5S7G8hlx+BcVFe0rGpkxoGIvk2vu1sQIsfKcux4RlA9ZpeCEgk7QsYb2n9Fszl83qgy0oUYqy1z0JMOzWVgb+neWbhXtcPlR4LiiEAZU79+rPpkJBuk8FpRSywGvM0JclW4mw7DRktl3OgOuGqvCPJ/mZTVmobBFcbgrjn9tnkFp9y5h+ZdQh8Q4yhxaRddSakgl/ETGxJTXTyqV15LAkMK05pn7kfg/YnswVfWwK3wSvkT06s8mgx18K4mwGxeZKEz+RDFwkAIPdnduhtLXmbJmdgyN9SOsfwikoL2D3Wvr3ZLrGFhMs3LxQ4npJYRY9r4B3gmn8fFyopYxio/vug6adPg2z8cAGHzW5DJEuL4jHVO1Jksid/FJTuali+VK0MJQNo39IUEFJetfgIuTsKkY=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(23010399003)(366016)(10067099003)(56012099006)(6133799003)(11063799006)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?cXOLpD3STbjA/B5vp1Z/m3OOUreEujvanqvsYZrm9C8MF2bKNDY/Gq9hgX?=
 =?iso-8859-1?Q?/4Jny3V8zcpYulImC4T4q8BHzft0R9tWAiHrXBSxspXsF0qJpKoHG1DwsG?=
 =?iso-8859-1?Q?/bEe4r+ftViPVXFo/bu50CYOozMqM7OwnA5g+IPYKf3D4BAOQG/sl4RE29?=
 =?iso-8859-1?Q?tx6qWzPCKzNin1T+t4HdYhSZ6RHyZJqhsz4Gv5B6N7MJwde8jxBfuOofHP?=
 =?iso-8859-1?Q?HmdPP2XD3a5TAH7FA+gjCjeVahpcrrzLOlfQLTzrIfNlj+78pa7bwM8I+U?=
 =?iso-8859-1?Q?DTBJg7d51J6lHoyRrxveIx2Wiu0RWE1VJdf+szYx2jLm7bGoN0AgKkVZTL?=
 =?iso-8859-1?Q?okVGQip+9YrYzwNZTnzhXajbRCtcwtfAJH3P2tDDK4xeV8zN6YZMOc6zO2?=
 =?iso-8859-1?Q?+dsdYvE9ldKa7npG1Q2AlsKWkvGZ+G3IpkIucgRdWZcETreaC+Z1kx0sjn?=
 =?iso-8859-1?Q?8mwnjSEgQgBbQV+P++FPZaaLEKSYWEvoFwP9/NEKGRdI/BheLaStM96mbL?=
 =?iso-8859-1?Q?47p5vVaPImGOf0GGPaU3qjDvdXMgzLHBISfqttg4gpExriJxLTTPjJ1YJX?=
 =?iso-8859-1?Q?xhXC2BDyjiNPSOwcr//H2cb2zfdqR+urLLUPVD/zQpDl/wLxFuCwIHpHQ7?=
 =?iso-8859-1?Q?SAL0peCT5YnJLSs8l85Rvhaad6us+Ho5Jk9Kg89v7GSQtg/pBloIhPpyFj?=
 =?iso-8859-1?Q?FE3ZXhlLatVVsvoSVc+PtkOfyvo/DmSBfxJMF7QAPvz/XxcFtwJVRbFZh/?=
 =?iso-8859-1?Q?3g9AGHWEifk2wIwU4ddl9oyl7VaIym/gcAdRs8CZlMTwSIs2apyvGuT5Kh?=
 =?iso-8859-1?Q?znEqM8hd/paugtuAkbjz3nzlbhONVnQKI8WIwMzeGyNNT4js/Ge0IEr593?=
 =?iso-8859-1?Q?3dR//c9SoARoJMjvoYvq5051iGmn0bJqipEcR0sAQjWOXtHW8G005peS5g?=
 =?iso-8859-1?Q?wAyLC2FtDA88pPLGOfjeFAzpJ0sHKrJN2MBatzJjlai5RPIYUE4NShsLMl?=
 =?iso-8859-1?Q?JjXwgAytOKPro1XrcEZAXM3RsiOJNfS9IfoJHLKOQYQe4Ktx3PgKPqQxlC?=
 =?iso-8859-1?Q?Jtt/ooGfltTlAo6sByx0gjK1vkIQui11r4SZPaZYdJFng9qBk4n5iPhrBy?=
 =?iso-8859-1?Q?XBJ8YTAwVKB72upyRrsvV4vc5Ev/szXPUCS6qCvsMfI9Wm/nM0b+ZJ3+9E?=
 =?iso-8859-1?Q?Sgg7EfhVwn7bNIiD8d81Z6cx/5BtTlAHjIx1EZR2i2JFOHgjFyl9WyuTBf?=
 =?iso-8859-1?Q?6oyJORosHCgoBIXddwyzwP6fuqbrDjmQ77vk0h9ExwUDViSayJaOo9we2i?=
 =?iso-8859-1?Q?a0eXf/KAl3v5NcOV/zlSYXA6JhUp4iXN7clquseuuexkeJ2LBec3+FCrF6?=
 =?iso-8859-1?Q?VUcscrSKUjIwRxn9nRC7rYKZh1VVnz6YBg1ouAeec5yhxenspU5yzXnfyG?=
 =?iso-8859-1?Q?xDwdZB1zSFeHp48ogm3BxHeSwmMAzybLORMRnE6eU7oK6ssNVgiZKgSdUZ?=
 =?iso-8859-1?Q?yBDa9g6g6NHfgKM9KSFF2s/fkFEVaPo1X7SST2a7R56K4zYBV3PxwNttLH?=
 =?iso-8859-1?Q?4LuVmgkaopC7zvSfQDUFqjEVMrcDVxH/Snop4LKyJyVXE1vDZRgD6EgTO7?=
 =?iso-8859-1?Q?5gFSfpuiNAyKJmcjgd0HhNgRmRepFbwKVMpkI7xF02EyTe641mm1IfKNZR?=
 =?iso-8859-1?Q?sfOFE2+QZE/dyQsjFSp6q6heBvky3nhow/EJj7OJO5m+iQWshkNXOysJ5o?=
 =?iso-8859-1?Q?fSqG0g4we9FyF1eY8LxFE3PsnfgvIw0Cf6bvBOk4oSi80ZpZjkYFsFlMke?=
 =?iso-8859-1?Q?5mNjKzeUSG68fYT64/0iknSpOhuzFqM=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bc66cc7c-eada-494d-e49c-08defd0579a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:29.0659
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OxW5S4wQ7r1ID2SgNaCeCDWiwF6gZm2BhDtgtN2EXda5NSlY7s8Wg7pqnqvtEfvFVaTQjXQxx96vB58cKmzPNw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042913-662A92AC-5B29AA9B/0/0
X-purgate-type: clean
X-purgate-size: 2429

This series implements support for CPU hotplug/unplug on Arm. To achieve
this, several things need to be done:

1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented on Arm64.
2. Enabled building of xen-hptool.
3. Migration of irqs from dying CPUs implemented.

Tested on QEMU and R-Car Gen5 HW.

v8->v9:
* rebase
* see individual patches

v7->v8:
* see individual patches

v6->v7:
* new patch "Kconfig: Make cpu hotplug configurable

v5->v6:
* see individual patches

v4->v5:
* drop merged patches
* combine "smp: Move cpu_up/down helpers to common code" with=20
  "arm/sysctl: Implement cpu hotplug ops"
* see individual patches

v3->v4:
* add irq migration patches
* see individual patches

v2->v3:
* add docs

v1->v2:
* see individual patches

Mykyta Poturai (6):
  arm/irq: Keep track of irq affinities
  arm/irq: Migrate IRQs during CPU up/down operations
  Kconfig: Make cpu hotplug configurable
  arm/sysctl: Implement cpu hotplug ops
  tools: Allow building xen-hptool without CONFIG_MIGRATE
  docs: Document CPU hotplug

 docs/misc/cpu-hotplug.txt         |  98 ++++++++++
 tools/misc/Makefile               |   9 +-
 tools/misc/xen-hptool-x86.c       | 278 ++++++++++++++++++++++++++++
 tools/misc/xen-hptool.c           | 293 ++----------------------------
 tools/misc/xen-hptool.h           |  15 ++
 xen/arch/arm/gic-vgic.c           |   2 +
 xen/arch/arm/include/asm/irq.h    |   6 +
 xen/arch/arm/irq.c                |  69 ++++++-
 xen/arch/arm/smp.c                |   9 +
 xen/arch/arm/smpboot.c            |   7 +
 xen/arch/arm/vgic.c               |  14 +-
 xen/arch/arm/vgic/vgic-mmio-v2.c  |  11 +-
 xen/arch/arm/vgic/vgic.c          |  21 ++-
 xen/arch/ppc/stubs.c              |   5 +
 xen/arch/riscv/stubs.c            |   5 +
 xen/arch/x86/include/asm/smp.h    |   3 -
 xen/arch/x86/platform_hypercall.c |  12 ++
 xen/arch/x86/smp.c                |  35 +---
 xen/arch/x86/sysctl.c             |  23 ++-
 xen/common/Kconfig                |   8 +
 xen/common/smp.c                  |  35 ++++
 xen/common/sysctl.c               |  34 ++++
 xen/include/xen/smp.h             |   4 +
 xen/xsm/flask/hooks.c             |   2 +-
 24 files changed, 658 insertions(+), 340 deletions(-)
 create mode 100644 docs/misc/cpu-hotplug.txt
 create mode 100644 tools/misc/xen-hptool-x86.c
 create mode 100644 tools/misc/xen-hptool.h

--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393700.1632540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUr-00088Y-2B; Tue, 18 Aug 2026 08:48:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393700.1632540; Tue, 18 Aug 2026 08:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUq-00086p-Ot; Tue, 18 Aug 2026 08:48:36 +0000
Received: by outflank-mailman (input) for mailman id 1393700;
 Tue, 18 Aug 2026 08:48:35 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUo-0007fA-R8
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUo-008KNP-7l
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:34 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-26
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:34 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-8
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:34 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:31 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uLvNoI0KfGoYRIKf3RcwhpIiCsYq9/7CV7seDvjeLXhNT3ugvRIzqOv7TyAkAkgg+zCACE1b6XVG0ZkEsQ6F3/PPmsK4qBkVlBzCj5hA0gYUyaqHQDIIR1Q2s+blBbvdSmG3WZ/jJfBvR+a2o7OhgHcBa5J9GNhc+8JZ6oUw6X80BhZHRzFqx+IBbdKbA2/ec5DosvnJJcsiDRQdU6lq7ZvjN+kIWfq+uBs2cKCpQZM1S6o1z9I05Wb4qUgfMB6aRP/xGB1xN5+mffpu0RC8PHFCo3srPkocOC2g6IUtQs7CoOK/fKc+04A2O71TWnLenyXiat8jLJoJEfA3e6nXmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LLub64GgmKZmKLFHh2VXjwdM16NT1jk+aUcCFVSJs58=;
 b=A7lSTPYmvkzAx8wo7HJ9cxfJk5HZH9t0PYGA2C6d2ZlPMdov9SvtUrp/emEiFSLRSw2uMG76jQwe1CxXvK8bLijcG8Q+yhxvWnU6M5NLk48noRvRa+pKwZ6YvqzhvXdIcK8ltUTcmrumX0BEmiuHq2aPIn3Z7e8RfJKKWYJH6u7b6qu4RiUkX53e1PJaHV4jLrw7/ImZSMtuxmYDFUo60LOy2oIGvH8zn8twUy4KofHtUoyPnZxZTy178wQbzQS5WrT67DExUMB1kdC4AqUHvPHMOY8oFZwRCBoNTkZKIlZsD8m/bbXFi7lRWcbvN3El5Td9PPVqF3GwUE0+sDp68A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LLub64GgmKZmKLFHh2VXjwdM16NT1jk+aUcCFVSJs58=;
 b=r5bXTmIBAP/BF3wyVW/RZVgTfq5M5v79OFWn5dD/mELGXuJ1a7+GbohhlvjkBqV+HP5GDwwtGKTKVex5UEIbK+XDkZzc4sM06g617eOTzoTEUVY05SOvB4uW4VdMVGJZkofX+HzdNVIbQ4DqLzF73HEZZWafgHPycYx+Rb2fh63y7aMP+AhPpJ3kLopWURER3+9Lf9JZaVjF+4fUlTmxWgjAxCsoRQDjMAEvwGNMoA4iqheoMDLOOlcaTogx6WQKBORz55wKrg2K9vAvMst8NgQpDCwqpo5stHsON8AWamnDhfUq+ya8Bx6AdiUMQ4nlvI54brycohS6MlurDsaPOQ==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Anthony PERARD
	<anthony.perard@vates.tech>
Subject: [PATCH v9 5/6] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Topic: [PATCH v9 5/6] tools: Allow building xen-hptool without
 CONFIG_MIGRATE
Thread-Index: AQHdLu5YHRJt4YkHAUu41q6KPLRZ9g==
Date: Tue, 18 Aug 2026 08:48:31 +0000
Message-ID:
 <c1f410ccb1469f1c46d2df94cd76546bf3db00b9.1787042017.git.mykyta_poturai@epam.com>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: f5aab0b0-03e4-42f5-4652-08defd057adc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|6133799003|11063799006|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 zHNK1Z+9GI9IiPsW2OmuiOy+bCj48BlpG1iT3TvM8PzIL2UP7MrzXBPU7NBUsGhhthhMm4xqlIh+iG3ushF6OErk5lHy02Um0SVIdGdCKt0rpsIzJ3jukCHTSORLVbZCP4nBc/wakPSPfoeC+xtB4cLaAJqWIyQieSn2woVZ0aJtUwCTw3g1t/doi7kOVt6ef2hLWZGyEGqhZXil3v4rZ+ibJ0diKswQTtbDr+dhRAUO6XiaxyyndP/L88C6HZxhHNHktCyEZV0s3dOKD0FpII4Kg6EXO9N/9PHz+7YNvKdU6euQnru2gDP35wM12z2UsRWGYOUfQzeU0LltWRGq/Rh2NmkwT79SsbkSdOrXihYG/MJhDMK/MdgRj5imsUlcsWFJ+OVb3z7aeWDOyeeqTVz4rteIpIalNf1fMI0knaFXxRYB3lgWnBZ9+UhhXYOG4dphZZ+xqY/7kOPArOe84+r81gRX4q1IZmArdp0RBBT7LFG75Jz2BJmF7wKpvNgSPS+Kss1xicfoVH6Fcdm165y1//udnSHNbRpsXCuwCXOS38mT2oVkCMIucK5e/xyx1XWLLINGlgr5pd9/6ricnhSx+xuZbLhaO1vS0w9fTgo/E1OR3yK6+V/BRvjuabC6TpfSOEQHK8D/VUtP9whXm7EdTBR2+HwHF45PmGxm+EXixf/cbPTNf5J6zaNSRDRkhBNDAsg9R6+4gIu79iLQvZ9KH5oUSlh/6k+R75+eVos=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(6133799003)(11063799006)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?UhmRKVlEkGdcH/8WueyQ25sFOttLizLRdsv0NDqvwjifIK7p9Oi9W1trz8?=
 =?iso-8859-1?Q?s2CtP6vVqD0bKcec1b8H5iE4SsSV5tmiZkPrhsTTobKKKavCG05JHCpOdu?=
 =?iso-8859-1?Q?S3Mf5//25vA3IAEH6r5aONA9PENdcavoG+6PwBT8jE7Vmsa7O+/JDU+ycX?=
 =?iso-8859-1?Q?tkJtLATFdyi2RFgNXgArm5+8C4kv70Tgo0U5whqNB4yNdMq+9H9B4BDf7U?=
 =?iso-8859-1?Q?VpquvxLUfMgI3QtVtKjSIosQTUgeMGjo0N1N8013GiL2LkY+3s2KCfKzmH?=
 =?iso-8859-1?Q?SJ+PxZVQtznOsdGq44wZV2cF7uJEyr2mysZPXQyHRYbwN7lL3TJMeDpUma?=
 =?iso-8859-1?Q?EWK0OBDzQzQNt2Tb5ke+PInQcJT3e6y4BNUlIHjsp+m46zQPmavAaGlUYH?=
 =?iso-8859-1?Q?vmnPi1p6vsZyhssvTewnBMqlH54nthSpQAV2P/hPxS7tEQ8OcxFKXOCJsY?=
 =?iso-8859-1?Q?ybuKxCB3SFwahupTB8GfPNaJJx1El7LnmObxv+Ck9I9yeFR+Gpe9qOkSiN?=
 =?iso-8859-1?Q?HlfzptWJb/eZhDIFPzLrmOY93UgtOwdq9UswnuXJ0LXkcw7CSMUXGB6mVf?=
 =?iso-8859-1?Q?cutqwYOBbw+0KqIpXSTuk0MeSlnNHOvqtO227rm8Eh7Qafg9dkGN+KIk7C?=
 =?iso-8859-1?Q?dUVZVWJis1haO/TZC2xZqmdpE4G/9Dy/WtYNZThytHwkj3z+a5sWuUtpHk?=
 =?iso-8859-1?Q?Kwm6DrOwgB2IgTtyaPssBIp0VbKDaAZlPB7CCPfesmRzOjuTlj3Yw0h2fi?=
 =?iso-8859-1?Q?GcV6TEqb+v7MDo11vps49EKGhPItVTP/m1YYvP95ZRdYKBHLUdv5yClUan?=
 =?iso-8859-1?Q?K20FfzuGQ7CxDj9h076nAEdvo/8082g9Z2Y6w5tH5aSniMeYabeegd79Vt?=
 =?iso-8859-1?Q?Y0N8i7Zg95pPHEFuyP0T7cGTECzZO/hmNuXNFyQYlLkDsLWY6kX43ncx7/?=
 =?iso-8859-1?Q?8OHC6DwrCRM1Y6cRqCv+/H0UsjK/MPVLiyU77kgOWD/SuhEIhmdmGlupwm?=
 =?iso-8859-1?Q?yczsBHcNVkU+UPl15GwG/ZXL1AIXGQy/0fHaRcTcuiSYOZEHrRw/rW2+HZ?=
 =?iso-8859-1?Q?Dc4TB3VcKQLe/PMo/cxXNXa/5T8ep4mgKA6j5VpNL6SoNrHfhtF9F5xs/Y?=
 =?iso-8859-1?Q?XICWHeD6sBsLXJ5oZ2SfrvPYfo7oI36HNoa5hDht0Hkve3KW+IHB4UcuNU?=
 =?iso-8859-1?Q?zlebNfQ3MNG2BS6E/BqcqoT8x4BPf5vf1ArkQrjpZQLLXBmmCosq/DJILg?=
 =?iso-8859-1?Q?rcYG2HTCUBeBm3VUTb0mdQCK8bXOjrYXHDljfkr/XhFRLJ0auCzCq7tPlM?=
 =?iso-8859-1?Q?Oj17X+t5cgMpnXi1HuKtcI4WJCOMinajj9povtMWtxe0po309cR+8X5eMT?=
 =?iso-8859-1?Q?/HQCoBwnX0wcx622NxFlebOQZFxHXM2+Ujv2W6vw+/Ql7EEZQt6vuhvVPU?=
 =?iso-8859-1?Q?EA+BmaCvVuu8+Rpc3mFK3+pRwJOc3Zwth2R2WCPARE7SRwkaXUwpvSCfE6?=
 =?iso-8859-1?Q?eXUX8dL26XrT1xpI2dJlvaUoyml4gCiYyohJcDFqXPXSoMSql1xjVgs0Vg?=
 =?iso-8859-1?Q?Au+xV08ZnXsm/MhufSVcF8bZ623n8rtrdSWVTuicHuGIi/hjAZVU8G5/tW?=
 =?iso-8859-1?Q?V2n7b7CZBtSubEQOEYaT+C+SGdPqdyUCQNGFrHUx2FMijoGb11uJYSpx3+?=
 =?iso-8859-1?Q?QHWuqPg8i+49V0+KUUx5pODLOvSt16TqNHK3QNpGrpJnjffFOXy1X198cn?=
 =?iso-8859-1?Q?lfppgwRvTrmGIJk/zhWmzwo1op9EEvDuruX/+pjTNjdZQjYOclLfRMIwcw?=
 =?iso-8859-1?Q?wXmRY4JLy2ddDozfZQhT9US14wV/0Q8=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f5aab0b0-03e4-42f5-4652-08defd057adc
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:31.0596
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XKoFFHis06NgzcaAKcqYT98BwTcQs3Z8k7Ssbz+4S4Pm2MqE7P15OsUqQ9Ju3SjB/r4DCXIlA1X6EFbS95kUwA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042914-668B42AC-6FF6DE56/0/0
X-purgate-type: clean
X-purgate-size: 24478

With CPU hotplug sysctls implemented on Arm it becomes useful to have a
tool for calling them.

According to the commit history it seems that putting hptool under
config MIGRATE was a measure to fix IA64 build. As IA64 is no longer
supported it can now be brought back. So build it unconditionally.

Operations specific to x86 architecture are moved into a separate file
and only built on x86.

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
v8->v9:
* use CONFIG_X86 instead of CONFIG_MIGRATE
* fix style issues
* add SPDX headers

v7->v8:
* move x86 specific function into a separate file

v6->v7:
* no changes

v5->v6:
* don't change order in Makefile

v4->v5:
* make hptool always build

v3->v4:
* no changes

v2->v3:
* no changes

v1->v2:
* switch to configure from legacy config
---
 tools/misc/Makefile         |   9 +-
 tools/misc/xen-hptool-x86.c | 278 ++++++++++++++++++++++++++++++++++
 tools/misc/xen-hptool.c     | 293 ++----------------------------------
 tools/misc/xen-hptool.h     |  15 ++
 4 files changed, 314 insertions(+), 281 deletions(-)
 create mode 100644 tools/misc/xen-hptool-x86.c
 create mode 100644 tools/misc/xen-hptool.h

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 6ee783f43e..064ab7c4bd 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -16,7 +16,7 @@ INSTALL_BIN                    +=3D xencov_split
 INSTALL_BIN +=3D $(INSTALL_BIN-y)
=20
 # Everything to be installed in regular sbin/
-INSTALL_SBIN-$(CONFIG_MIGRATE) +=3D xen-hptool
+INSTALL_SBIN                   +=3D xen-hptool
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-hvmctx
 INSTALL_SBIN-$(CONFIG_X86)     +=3D xen-lowmemd
@@ -104,8 +104,11 @@ xenhypfs: xenhypfs.o
 xenlockprof: xenlockprof.o
 	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
=20
-xen-hptool: xen-hptool.o
-	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(L=
DLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
+hptool-objs-y :=3D xen-hptool.o
+hptool-objs-$(CONFIG_X86) +=3D xen-hptool-x86.o
+
+xen-hptool: $(hptool-objs-y)
+	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(L=
DLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
=20
 xenhypfs.o: CFLAGS +=3D $(CFLAGS_libxenhypfs)
=20
diff --git a/tools/misc/xen-hptool-x86.c b/tools/misc/xen-hptool-x86.c
new file mode 100644
index 0000000000..95a7e05990
--- /dev/null
+++ b/tools/misc/xen-hptool-x86.c
@@ -0,0 +1,278 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <xenevtchn.h>
+#include <xenctrl.h>
+#include <xenguest.h>
+#include <xenstore.h>
+#include "xen-hptool.h"
+
+int hp_mem_online_func(int argc, char *argv[], xc_interface *xch)
+{
+    uint32_t status;
+    int ret;
+    unsigned long mfn;
+
+    if (argc !=3D 1)
+    {
+        show_help();
+        return -1;
+    }
+
+    sscanf(argv[0], "%lx", &mfn);
+    printf("Prepare to online MEMORY mfn %lx\n", mfn);
+
+    ret =3D xc_mark_page_online(xch, mfn, mfn, &status);
+
+    if (ret < 0)
+        fprintf(stderr, "Onlining page mfn %lx failed, error %x\n", mfn, e=
rrno);
+    else if (status & (PG_ONLINE_FAILED |PG_ONLINE_BROKEN)) {
+        fprintf(stderr, "Onlining page mfn %lx is broken, "
+                        "Memory online failed\n", mfn);
+        ret =3D -1;
+    }
+    else if (status & PG_ONLINE_ONLINED)
+        printf("Memory mfn %lx onlined successfully\n", mfn);
+    else
+        printf("Memory is already onlined!\n");
+
+    return ret;
+}
+
+int hp_mem_query_func(int argc, char *argv[], xc_interface *xch)
+{
+    uint32_t status;
+    int ret;
+    unsigned long mfn;
+
+    if (argc !=3D 1)
+    {
+        show_help();
+        return -1;
+    }
+
+    sscanf(argv[0], "%lx", &mfn);
+    printf("Querying MEMORY mfn %lx status\n", mfn);
+    ret =3D xc_query_page_offline_status(xch, mfn, mfn, &status);
+
+    if (ret < 0)
+        fprintf(stderr, "Querying page mfn %lx failed, error %x\n", mfn, e=
rrno);
+    else
+    {
+        printf("Memory Status %x: [", status);
+        if ( status & PG_OFFLINE_STATUS_OFFLINE_PENDING)
+            printf(" PAGE_OFFLINE_PENDING ");
+        if ( status & PG_OFFLINE_STATUS_BROKEN )
+            printf(" PAGE_BROKEND  ");
+        if ( status & PG_OFFLINE_STATUS_OFFLINED )
+            printf(" PAGE_OFFLINED ");
+        else
+            printf(" PAGE_ONLINED ");
+        printf("]\n");
+    }
+
+    return ret;
+}
+
+static int suspend_guest(xc_interface *xch, xenevtchn_handle *xce, int dom=
id,
+                         int *evtchn, int *lockfd)
+{
+    int port, rc, suspend_evtchn =3D -1;
+
+    *lockfd =3D -1;
+
+    if (!evtchn)
+        return -1;
+
+    port =3D xs_suspend_evtchn_port(domid);
+    if (port < 0)
+    {
+        fprintf(stderr, "DOM%d: No suspend port, try live migration\n", do=
mid);
+        goto failed;
+    }
+    suspend_evtchn =3D xc_suspend_evtchn_init_exclusive(xch, xce, domid,
+                                                      port, lockfd);
+    if (suspend_evtchn < 0)
+    {
+        fprintf(stderr, "Suspend evtchn initialization failed\n");
+        goto failed;
+    }
+    *evtchn =3D suspend_evtchn;
+
+    rc =3D xenevtchn_notify(xce, suspend_evtchn);
+    if (rc < 0)
+    {
+        fprintf(stderr, "Failed to notify suspend channel: errno %d\n", rc=
);
+        goto failed;
+    }
+    if (xc_await_suspend(xch, xce, suspend_evtchn) < 0)
+    {
+        fprintf(stderr, "Suspend Failed\n");
+        goto failed;
+    }
+    return 0;
+
+failed:
+    if (suspend_evtchn !=3D -1)
+        xc_suspend_evtchn_release(xch, xce, domid,
+                                  suspend_evtchn, lockfd);
+
+    return -1;
+}
+
+int hp_mem_offline_func(int argc, char *argv[], xc_interface *xch)
+{
+    uint32_t status, domid;
+    int ret;
+    unsigned long mfn;
+
+    if (argc !=3D 1)
+    {
+        show_help();
+        return -1;
+    }
+
+    sscanf(argv[0], "%lx", &mfn);
+    printf("Prepare to offline MEMORY mfn %lx\n", mfn);
+    ret =3D xc_mark_page_offline(xch, mfn, mfn, &status);
+    if (ret < 0) {
+        fprintf(stderr, "Offlining page mfn %lx failed, error %x\n", mfn, =
errno);
+        if (status & (PG_OFFLINE_XENPAGE | PG_OFFLINE_FAILED))
+            fprintf(stderr, "XEN_PAGE is not permitted be offlined\n");
+        else if (status & (PG_OFFLINE_FAILED | PG_OFFLINE_NOT_CONV_RAM))
+            fprintf(stderr, "RESERVED RAM is not permitted to be offlined\=
n");
+    }
+    else
+    {
+        switch(status & PG_OFFLINE_STATUS_MASK)
+        {
+            case PG_OFFLINE_OFFLINED:
+            {
+                printf("Memory mfn %lx offlined successfully, current stat=
e is"
+                       " [PG_OFFLINE_OFFLINED]\n", mfn);
+                if (status & PG_OFFLINE_BROKEN)
+                    printf("And this offlined PAGE is already marked broke=
n"
+                        " before!\n");
+                break;
+            }
+            case PG_OFFLINE_FAILED:
+            {
+                fprintf(stderr, "Memory mfn %lx offline failed\n", mfn);
+                if ( status & PG_OFFLINE_ANONYMOUS)
+                    fprintf(stderr, "the memory is an anonymous page!\n");
+                ret =3D -1;
+                break;
+            }
+            case PG_OFFLINE_PENDING:
+            {
+                if (status & PG_OFFLINE_XENPAGE) {
+                    ret =3D -1;
+                    fprintf(stderr, "Memory mfn %lx offlined succssefully,=
"
+                            "this page is xen page, current state is"
+                            " [PG_OFFLINE_PENDING, PG_OFFLINE_XENPAGE]\n",=
 mfn);
+                }
+                else if (status & PG_OFFLINE_OWNED)
+                {
+                    int result, suspend_evtchn =3D -1, suspend_lockfd =3D =
-1;
+                    xenevtchn_handle *xce;
+                    xce =3D xenevtchn_open(NULL, 0);
+
+                    if (xce =3D=3D NULL)
+                    {
+                        fprintf(stderr, "When exchange page, fail"
+                                " to open evtchn\n");
+                        return -1;
+                    }
+
+                    domid =3D status >> PG_OFFLINE_OWNER_SHIFT;
+                    if (suspend_guest(xch, xce, domid,
+                                      &suspend_evtchn, &suspend_lockfd))
+                    {
+                        fprintf(stderr, "Failed to suspend guest %d for"
+                                " mfn %lx\n", domid, mfn);
+                        xenevtchn_close(xce);
+                        return -1;
+                    }
+
+                    result =3D xc_exchange_page(xch, domid, mfn);
+
+                    /* Exchange page successfully */
+                    if (result =3D=3D 0)
+                        printf("Memory mfn %lx offlined successfully, this=
 "
+                                "page is DOM%d page and being swapped "
+                                "successfully, current state is "
+                                "[PG_OFFLINE_OFFLINED, PG_OFFLINE_OWNED]\n=
",
+                                mfn, domid);
+                    else {
+                        ret =3D -1;
+                        fprintf(stderr, "Memory mfn %lx offlined successfu=
lly"
+                                " , this page is DOM%d page yet failed to =
be "
+                                "exchanged. current state is "
+                                "[PG_OFFLINE_PENDING, PG_OFFLINE_OWNED]\n"=
,
+                                mfn, domid);
+                    }
+                    xc_domain_resume(xch, domid, 1);
+                    xc_suspend_evtchn_release(xch, xce, domid,
+                                              suspend_evtchn, &suspend_loc=
kfd);
+                    xenevtchn_close(xce);
+                }
+                break;
+            }
+        }//end of switch
+    }//end of if
+
+    return ret;
+}
+
+int main_smt_enable(int argc, char *argv[], xc_interface *xch)
+{
+    int ret;
+
+    if ( argc )
+    {
+        show_help();
+        return -1;
+    }
+
+    for ( ;; )
+    {
+        ret =3D xc_smt_enable(xch);
+        if ( (ret >=3D 0) || (errno !=3D EBUSY) )
+            break;
+    }
+
+    if ( ret < 0 )
+        fprintf(stderr, "Unable to enable SMT: errno %d, %s\n",
+                errno, strerror(errno));
+    else
+        printf("Enabled SMT\n");
+
+    return ret;
+}
+
+int main_smt_disable(int argc, char *argv[], xc_interface *xch)
+{
+    int ret;
+
+    if ( argc )
+    {
+        show_help();
+        return -1;
+    }
+
+    for ( ;; )
+    {
+        ret =3D xc_smt_disable(xch);
+        if ( (ret >=3D 0) || (errno !=3D EBUSY) )
+            break;
+    }
+
+    if ( ret < 0 )
+        fprintf(stderr, "Unable to disable SMT: errno %d, %s\n",
+                errno, strerror(errno));
+    else
+        printf("Disabled SMT\n");
+
+    return ret;
+}
diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c
index 590810b6eb..7b886e2304 100644
--- a/tools/misc/xen-hptool.c
+++ b/tools/misc/xen-hptool.c
@@ -6,8 +6,8 @@
 #include <xenguest.h>
 #include <xenstore.h>
 #include <xen-tools/common-macros.h>
+#include "xen-hptool.h"
=20
-static xc_interface *xch;
=20
 void show_help(void)
 {
@@ -18,239 +18,25 @@ void show_help(void)
             "  help                     display this help\n"
             "  cpu-online    <cpuid>    online CPU <cpuid>\n"
             "  cpu-offline   <cpuid>    offline CPU <cpuid>\n"
+#if defined(__i386__) || defined(__x86_64__)
             "  mem-online    <mfn>      online MEMORY <mfn>\n"
             "  mem-offline   <mfn>      offline MEMORY <mfn>\n"
             "  mem-status    <mfn>      query Memory status<mfn>\n"
             "  smt-enable               onlines all SMT threads\n"
             "  smt-disable              offlines all SMT threads\n"
+#endif
            );
 }
=20
 /* wrapper function */
-static int help_func(int argc, char *argv[])
+static int help_func(int argc, char *argv[], xc_interface *xch)
 {
     show_help();
     return 0;
 }
=20
-static int hp_mem_online_func(int argc, char *argv[])
-{
-    uint32_t status;
-    int ret;
-    unsigned long mfn;
-
-    if (argc !=3D 1)
-    {
-        show_help();
-        return -1;
-    }
-
-    sscanf(argv[0], "%lx", &mfn);
-    printf("Prepare to online MEMORY mfn %lx\n", mfn);
-
-    ret =3D xc_mark_page_online(xch, mfn, mfn, &status);
-
-    if (ret < 0)
-        fprintf(stderr, "Onlining page mfn %lx failed, error %x\n", mfn, e=
rrno);
-    else if (status & (PG_ONLINE_FAILED |PG_ONLINE_BROKEN)) {
-        fprintf(stderr, "Onlining page mfn %lx is broken, "
-                        "Memory online failed\n", mfn);
-        ret =3D -1;
-    }
-    else if (status & PG_ONLINE_ONLINED)
-        printf("Memory mfn %lx onlined successfully\n", mfn);
-    else
-        printf("Memory is already onlined!\n");
-
-    return ret;
-}
-
-static int hp_mem_query_func(int argc, char *argv[])
-{
-    uint32_t status;
-    int ret;
-    unsigned long mfn;
-
-    if (argc !=3D 1)
-    {
-        show_help();
-        return -1;
-    }
-
-    sscanf(argv[0], "%lx", &mfn);
-    printf("Querying MEMORY mfn %lx status\n", mfn);
-    ret =3D xc_query_page_offline_status(xch, mfn, mfn, &status);
-
-    if (ret < 0)
-        fprintf(stderr, "Querying page mfn %lx failed, error %x\n", mfn, e=
rrno);
-    else
-    {
-        printf("Memory Status %x: [", status);
-        if ( status & PG_OFFLINE_STATUS_OFFLINE_PENDING)
-            printf(" PAGE_OFFLINE_PENDING ");
-        if ( status & PG_OFFLINE_STATUS_BROKEN )
-            printf(" PAGE_BROKEND  ");
-        if ( status & PG_OFFLINE_STATUS_OFFLINED )
-            printf(" PAGE_OFFLINED ");
-        else
-            printf(" PAGE_ONLINED ");
-        printf("]\n");
-    }
-
-    return ret;
-}
-
-static int suspend_guest(xc_interface *xch, xenevtchn_handle *xce, int dom=
id,
-                         int *evtchn, int *lockfd)
-{
-    int port, rc, suspend_evtchn =3D -1;
-
-    *lockfd =3D -1;
-
-    if (!evtchn)
-        return -1;
-
-    port =3D xs_suspend_evtchn_port(domid);
-    if (port < 0)
-    {
-        fprintf(stderr, "DOM%d: No suspend port, try live migration\n", do=
mid);
-        goto failed;
-    }
-    suspend_evtchn =3D xc_suspend_evtchn_init_exclusive(xch, xce, domid,
-                                                      port, lockfd);
-    if (suspend_evtchn < 0)
-    {
-        fprintf(stderr, "Suspend evtchn initialization failed\n");
-        goto failed;
-    }
-    *evtchn =3D suspend_evtchn;
-
-    rc =3D xenevtchn_notify(xce, suspend_evtchn);
-    if (rc < 0)
-    {
-        fprintf(stderr, "Failed to notify suspend channel: errno %d\n", rc=
);
-        goto failed;
-    }
-    if (xc_await_suspend(xch, xce, suspend_evtchn) < 0)
-    {
-        fprintf(stderr, "Suspend Failed\n");
-        goto failed;
-    }
-    return 0;
-
-failed:
-    if (suspend_evtchn !=3D -1)
-        xc_suspend_evtchn_release(xch, xce, domid,
-                                  suspend_evtchn, lockfd);
-
-    return -1;
-}
-
-static int hp_mem_offline_func(int argc, char *argv[])
-{
-    uint32_t status, domid;
-    int ret;
-    unsigned long mfn;
-
-    if (argc !=3D 1)
-    {
-        show_help();
-        return -1;
-    }
-
-    sscanf(argv[0], "%lx", &mfn);
-    printf("Prepare to offline MEMORY mfn %lx\n", mfn);
-    ret =3D xc_mark_page_offline(xch, mfn, mfn, &status);
-    if (ret < 0) {
-        fprintf(stderr, "Offlining page mfn %lx failed, error %x\n", mfn, =
errno);
-        if (status & (PG_OFFLINE_XENPAGE | PG_OFFLINE_FAILED))
-            fprintf(stderr, "XEN_PAGE is not permitted be offlined\n");
-        else if (status & (PG_OFFLINE_FAILED | PG_OFFLINE_NOT_CONV_RAM))
-            fprintf(stderr, "RESERVED RAM is not permitted to be offlined\=
n");
-    }
-    else
-    {
-        switch(status & PG_OFFLINE_STATUS_MASK)
-        {
-            case PG_OFFLINE_OFFLINED:
-            {
-                printf("Memory mfn %lx offlined successfully, current stat=
e is"
-                       " [PG_OFFLINE_OFFLINED]\n", mfn);
-                if (status & PG_OFFLINE_BROKEN)
-                    printf("And this offlined PAGE is already marked broke=
n"
-                        " before!\n");
-                break;
-            }
-            case PG_OFFLINE_FAILED:
-            {
-                fprintf(stderr, "Memory mfn %lx offline failed\n", mfn);
-                if ( status & PG_OFFLINE_ANONYMOUS)
-                    fprintf(stderr, "the memory is an anonymous page!\n");
-                ret =3D -1;
-                break;
-            }
-            case PG_OFFLINE_PENDING:
-            {
-                if (status & PG_OFFLINE_XENPAGE) {
-                    ret =3D -1;
-                    fprintf(stderr, "Memory mfn %lx offlined succssefully,=
"
-                            "this page is xen page, current state is"
-                            " [PG_OFFLINE_PENDING, PG_OFFLINE_XENPAGE]\n",=
 mfn);
-                }
-                else if (status & PG_OFFLINE_OWNED)
-                {
-                    int result, suspend_evtchn =3D -1, suspend_lockfd =3D =
-1;
-                    xenevtchn_handle *xce;
-                    xce =3D xenevtchn_open(NULL, 0);
-
-                    if (xce =3D=3D NULL)
-                    {
-                        fprintf(stderr, "When exchange page, fail"
-                                " to open evtchn\n");
-                        return -1;
-                    }
-
-                    domid =3D status >> PG_OFFLINE_OWNER_SHIFT;
-                    if (suspend_guest(xch, xce, domid,
-                                      &suspend_evtchn, &suspend_lockfd))
-                    {
-                        fprintf(stderr, "Failed to suspend guest %d for"
-                                " mfn %lx\n", domid, mfn);
-                        xenevtchn_close(xce);
-                        return -1;
-                    }
-
-                    result =3D xc_exchange_page(xch, domid, mfn);
-
-                    /* Exchange page successfully */
-                    if (result =3D=3D 0)
-                        printf("Memory mfn %lx offlined successfully, this=
 "
-                                "page is DOM%d page and being swapped "
-                                "successfully, current state is "
-                                "[PG_OFFLINE_OFFLINED, PG_OFFLINE_OWNED]\n=
",
-                                mfn, domid);
-                    else {
-                        ret =3D -1;
-                        fprintf(stderr, "Memory mfn %lx offlined successfu=
lly"
-                                " , this page is DOM%d page yet failed to =
be "
-                                "exchanged. current state is "
-                                "[PG_OFFLINE_PENDING, PG_OFFLINE_OWNED]\n"=
,
-                                mfn, domid);
-                    }
-                    xc_domain_resume(xch, domid, 1);
-                    xc_suspend_evtchn_release(xch, xce, domid,
-                                              suspend_evtchn, &suspend_loc=
kfd);
-                    xenevtchn_close(xce);
-                }
-                break;
-            }
-        }//end of switch
-    }//end of if
-
-    return ret;
-}
-
-static int exec_cpu_hp_fn(int (*hp_fn)(xc_interface *, int), int cpu)
+static int exec_cpu_hp_fn(int (*hp_fn)(xc_interface *, int), int cpu,
+                          xc_interface *xch)
 {
     int ret;
=20
@@ -265,7 +51,7 @@ static int exec_cpu_hp_fn(int (*hp_fn)(xc_interface *, i=
nt), int cpu)
     return ret;
 }
=20
-static int hp_cpu_online_func(int argc, char *argv[])
+static int hp_cpu_online_func(int argc, char *argv[], xc_interface *xch)
 {
     int cpu, ret;
=20
@@ -277,7 +63,7 @@ static int hp_cpu_online_func(int argc, char *argv[])
=20
     cpu =3D atoi(argv[0]);
     printf("Prepare to online CPU %d\n", cpu);
-    ret =3D exec_cpu_hp_fn(xc_cpu_online, cpu);
+    ret =3D exec_cpu_hp_fn(xc_cpu_online, cpu, xch);
     if (ret < 0)
         fprintf(stderr, "CPU %d online failed (error %d: %s)\n",
                 cpu, errno, strerror(errno));
@@ -287,7 +73,7 @@ static int hp_cpu_online_func(int argc, char *argv[])
     return ret;
=20
 }
-static int hp_cpu_offline_func(int argc, char *argv[])
+static int hp_cpu_offline_func(int argc, char *argv[], xc_interface *xch)
 {
     int cpu, ret;
=20
@@ -298,7 +84,7 @@ static int hp_cpu_offline_func(int argc, char *argv[])
     }
     cpu =3D atoi(argv[0]);
     printf("Prepare to offline CPU %d\n", cpu);
-    ret =3D exec_cpu_hp_fn(xc_cpu_offline, cpu);
+    ret =3D exec_cpu_hp_fn(xc_cpu_offline, cpu, xch);
     if (ret < 0)
         fprintf(stderr, "CPU %d offline failed (error %d: %s)\n",
                 cpu, errno, strerror(errno));
@@ -308,76 +94,27 @@ static int hp_cpu_offline_func(int argc, char *argv[])
     return ret;
 }
=20
-static int main_smt_enable(int argc, char *argv[])
-{
-    int ret;
-
-    if ( argc )
-    {
-        show_help();
-        return -1;
-    }
-
-    for ( ;; )
-    {
-        ret =3D xc_smt_enable(xch);
-        if ( (ret >=3D 0) || (errno !=3D EBUSY) )
-            break;
-    }
-
-    if ( ret < 0 )
-        fprintf(stderr, "Unable to enable SMT: errno %d, %s\n",
-                errno, strerror(errno));
-    else
-        printf("Enabled SMT\n");
-
-    return ret;
-}
-
-static int main_smt_disable(int argc, char *argv[])
-{
-    int ret;
-
-    if ( argc )
-    {
-        show_help();
-        return -1;
-    }
-
-    for ( ;; )
-    {
-        ret =3D xc_smt_disable(xch);
-        if ( (ret >=3D 0) || (errno !=3D EBUSY) )
-            break;
-    }
-
-    if ( ret < 0 )
-        fprintf(stderr, "Unable to disable SMT: errno %d, %s\n",
-                errno, strerror(errno));
-    else
-        printf("Disabled SMT\n");
-
-    return ret;
-}
-
 struct {
     const char *name;
-    int (*function)(int argc, char *argv[]);
+    int (*function)(int argc, char *argv[], xc_interface *xch);
 } main_options[] =3D {
     { "help", help_func },
     { "cpu-online", hp_cpu_online_func },
     { "cpu-offline", hp_cpu_offline_func },
+#if defined(__i386__) || defined(__x86_64__)
     { "mem-status", hp_mem_query_func},
     { "mem-online", hp_mem_online_func},
     { "mem-offline", hp_mem_offline_func},
     { "smt-enable", main_smt_enable },
     { "smt-disable", main_smt_disable },
+#endif
 };
=20
=20
 int main(int argc, char *argv[])
 {
     int i, ret;
+    xc_interface *xch;
=20
     if (argc < 2)
     {
@@ -402,7 +139,7 @@ int main(int argc, char *argv[])
         return 1;
     }
=20
-    ret =3D main_options[i].function(argc -2, argv + 2);
+    ret =3D main_options[i].function(argc -2, argv + 2, xch);
=20
     xc_interface_close(xch);
=20
diff --git a/tools/misc/xen-hptool.h b/tools/misc/xen-hptool.h
new file mode 100644
index 0000000000..34f492c34b
--- /dev/null
+++ b/tools/misc/xen-hptool.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __XEN_HPTOOL_H__
+#define __XEN_HPTOOL_H__
+
+#if defined(__i386__) || defined(__x86_64__)
+int hp_mem_online_func(int argc, char *argv[], xc_interface *xch);
+int hp_mem_query_func(int argc, char *argv[], xc_interface *xch);
+int hp_mem_offline_func(int argc, char *argv[], xc_interface *xch);
+int main_smt_enable(int argc, char *argv[], xc_interface *xch);
+int main_smt_disable(int argc, char *argv[], xc_interface *xch);
+#endif
+
+void show_help(void);
+
+#endif /* __XEN_HPTOOL_H__ */
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393697.1632517 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUp-0007i5-Oa; Tue, 18 Aug 2026 08:48:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393697.1632517; Tue, 18 Aug 2026 08:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUp-0007gl-Kh; Tue, 18 Aug 2026 08:48:35 +0000
Received: by outflank-mailman (input) for mailman id 1393697;
 Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUn-0007en-VF
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUm-008KNP-VM
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:32 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-16
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:32 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-5
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:32 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:30 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kfy3x0iVGg0Mzf2XoI4PQmYPEQYy7ELnmjKVMJU3Hxz2RHuiNfPT6GWyDukfQiQKB9S3VKtMMrtE8iTdm0oTA3bwsHA1o1tHl2YNcSHU8Kd/AGeJv6ZZ8ev3MrUqA5mYYFMtNKgyl3spWxmRflolZ/WyE8G1H+AfR1++skkR4HTlnSCzYme0yTDAD4drmNAvJU44v+YfcQBK2KnrgRvWfh9VqoNJK7AR2LqR6HFI5A9yffaA2fGrX7ItO7+yVGzl7TUIayfuhuzsov6Z9buVCvwTFuWaV+JOMC9k0yZ3h6ZI5Wd3CgNB+duEt6CbOc8W/wVX46wSK0OLL/Udwe8YJw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=q7EAGySORphYMfpI2/c0B+nTzcv6FJOsXy1zCeip318=;
 b=t0qVdjDjCWKPLsMKDxTTr2VKWYIG63eIEh4tuiqJp9RoRf5akDa5jOf07runds1HTbChhiWD8NBa4SyHOq33Z5uahF9sbyBvzQJhCBF32pHS4W9Pqd06uWr06qI6/MEq23QuX6dM5lg9HBmkhSKb6Ba11sX1/XyF4DcK4CNMCEh231QCM7R7sjVlY+qNqw+gfm6Jm0LH0qmDtJIHqRcsbeDLH8PzZXNGVnM5mP8kxruokMwHgfKhgHNQF/gJ8fBMS2kKLvhq930ROgVcitMrnM71nrBoZOwHHZSfMqjSjGbeAWkAGtRX9R6C3Td0hPScEWEaZgPJt42OAKjeBywYQA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=q7EAGySORphYMfpI2/c0B+nTzcv6FJOsXy1zCeip318=;
 b=kt5Kb5QB+vtU1qh806pqrh3J3UoctSGotk9+6m1JWDtJgXy6cCPJ42mQLvAEah0vTnn0VmXv84QkSnkn30B3Rcdj8MaP+hnRnkvKjbyrbO+DYRbLNmElC9B3ZCnvKztolsNTOPAMEjCuE7oMwl6VMXTIMG3yVNaQmn0fLozjaGvb8KfGYrBrtmyZZfTubRN0EyhBT/gFso4qTQKUorsn5nwZPO6NPmPi5Qpp36v8J92JAJlyoTphL5MLuMBUoynkxTlgntmQ5lM8ui8KyBM5yZKSWDU2JwPjgnRZAEysal2BPaigTUSgZ1SZZwaOgdS2OeT7LSEugu4xCg+/OxNoDg==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v9 2/6] arm/irq: Migrate IRQs during CPU up/down operations
Thread-Topic: [PATCH v9 2/6] arm/irq: Migrate IRQs during CPU up/down
 operations
Thread-Index: AQHdLu5XyuKK+Q2mBU6sZp5cWKKcAA==
Date: Tue, 18 Aug 2026 08:48:29 +0000
Message-ID:
 <55f4839f427df6675a621bb61bfbdac4fb089382.1787042017.git.mykyta_poturai@epam.com>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: 6490d7db-cdc0-4897-e99c-08defd057a37
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|11063799006|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 i/77Vl7u/RHdPFMQMvoQLnqgNMHWt/SlBkJ6PZabLm7CgGCei/fFeUF7irU7YNb1gdzg2dBJz4NCT73LU5ZKrrvJSCAqpqIO3TphZloVJUdkkunWXkwZdA7so2ctoKa2hfLdEXaTFyT8WeCYZrCOzPBOtX4WoCZhAKwtZX3zV1cS2aHJyeLBmH7ZEQZSiKQaOSr38g1rPxHtYjIk3crD7utpcPiB1ux89VJqeLNLCzBQcoMFC0Hek0vvOeADA+hqVTRtzTvl1Eqevz1f+8urPkaHkEa35zEnwubup8AkL8dKoxX0+sUsEzDXgrV/SaSmc6iKYKJOyju5zr9QIFOwhihrxxvULrs9y0asZXJDLL/5tm6aJBD+/F88JODUWMcMfDK/C4hmCozwPFZVJwa8M1OXneN7ZPv3hdldMAYodSi+Hg99XFh+Vo2u4xbLxVlmiJIK4+ztij0prnU2pSIFQZLFNLIU88AFpcNsQLUIRGtZIdnODLcLhI55R7d6J0QaXVb03r0Q9ZTP/awrRwQx18SXuFkyQ89HcmSfMK17mbtCkSTuECgiQmmd6XEONIlPF3s9sxYdPftTo05R4HM7V5OugBcNZ/aSgxcldNhPDe897tfHFsx1NCY2Si81Q6fvf3qOTqXL8GD2lbzcWQcQRZZAysGXMSSFCGKYVx2EIBHRwNoqAzOhQIuuvnmNhi5SC1VensMXb76nm36JQkR3GfScoPmc0FNAx5rtzl1VPAg=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?MeOVwGW1J1ruDsEQAoTw40d/ELX0hROc7ZFSNoOZlJwD/rv9r8LVSrH5c0?=
 =?iso-8859-1?Q?DVGssNuS18UqivqtS62Bin5Zow0LbZ8UFHOZVSE+pq5DbCyiSrj4Va6VpT?=
 =?iso-8859-1?Q?qAqj31mdPqveP/GuXkgRuhLKg35ppmwfJREuLsCarwugbgFiexWCFduFq1?=
 =?iso-8859-1?Q?RrmJRKjjZm/pzA5BsVikfs+ZrmHlDm33TkTfzMP0o0ky+bc9axqqCHYCIk?=
 =?iso-8859-1?Q?ejE7uSSmkz8J2CcsbabrPdINNglt7p76eA9UtfrKeJY3NwG9dfta76QF/z?=
 =?iso-8859-1?Q?gLUDfx7NukQcbrUTJgIwRDjZAWODlSncNZentv0BHT9eE9nXowZrqdP0/L?=
 =?iso-8859-1?Q?PTPrMslMCeFXYFj1Wyisk751HchiKwuF7hvzocC1OfwsTKRV3iW2pb2A7E?=
 =?iso-8859-1?Q?NkH9Kdr1l/UdXfBm6YyXXMSVwr+EX6fYx7Z+IyoHYFsN+HKCjbF8f2dJiy?=
 =?iso-8859-1?Q?tcHSPE9t3n8ajkgJ+xwhbb+6skLwfSEYnWYdcqXIiFIOraCsEdXWFN52zc?=
 =?iso-8859-1?Q?m9YOgk2jT9KsNBFax+ZBef4xNoMYsSKxoV5YxsagjnXtEc0G+5lp2suDbe?=
 =?iso-8859-1?Q?Fpr44wErLVBJVEJfmJYBOswj2SCoDTkC6XeuJSR/LKH6Ntye3aQMY6HbjJ?=
 =?iso-8859-1?Q?HUuecHp0pD0OIvlQbGE6uyTRcNGU9RK/5uvxSE+mn/PTXLnO6uQaX4Yufj?=
 =?iso-8859-1?Q?YFKF7c53bHqsKwYbgiFGzrJEvAaXuCyEleFpjc79P4mjhWFZCD73UxsFFv?=
 =?iso-8859-1?Q?EA7DuIzjEDgDFYjxCeBXb08AJPORANIZIM0DFt40axcXnRZ6gfwsHJ7Kw5?=
 =?iso-8859-1?Q?xBVxqs8N4nU2DEeEuGNEGw5rhMoaBpOTBH90g2cU1ckNlamTHvMiaB1kZC?=
 =?iso-8859-1?Q?zHlrACvQRvKMd4jyDGxm6LDrrinyVZJIELXo6HKqzovliNp6NUpB8ipbfq?=
 =?iso-8859-1?Q?XkujjmEmOESKfDuwqs2900o7iw75uono2rPS7oG3WnRtYKl/Bkkkk86Emn?=
 =?iso-8859-1?Q?bJ5IAi12KLWer5OwLnnD9DDSY7HctW/LFmQ6xdwS9woG4qANl7lSuER4tg?=
 =?iso-8859-1?Q?QFw/WlU6eVcDrETyxcuu6tjmIZpyT0w9pKelCTJI1uqrFxiMkVPOpaODjd?=
 =?iso-8859-1?Q?CH0w9PceScw36hMDVjEGXI3d800bRwBU3NR9UHsb0boTyzznkHLWllOj3N?=
 =?iso-8859-1?Q?BrXddNQdxX16+JWV2kgTHVd40zfNUGbSZAtzfPLmHE0ywn5O/ICuMuCmxV?=
 =?iso-8859-1?Q?+gaDW+14F0uWG/xldloEmTqv5wwSbphVEXLB31vs9EIfaIrNu9ldCh9FH6?=
 =?iso-8859-1?Q?peLutZMuRmwg7YfA+rbX2KRe3K4bf7fHLu2bGzdGJkCjqEKLHvr5SIwgPS?=
 =?iso-8859-1?Q?jOUuFWGf5oxkGDG6oKeOp2TwoNq15VQvJB3k26eW9MQM8QQWWSUTO4Wv1B?=
 =?iso-8859-1?Q?icaKtfkqwzQuIngynRDvJ5ARJaV/RUBpMWzGt8ethVkZmPOuWthMLdnBZ4?=
 =?iso-8859-1?Q?q1xc/wBC150hR4ptuouktSoHIMXVPqtx1HxrOy4BltlV3eDGv8R46B+tB2?=
 =?iso-8859-1?Q?1TgqJg9/lhpGPjxrsrrd68lIIqw2MB52jAEmJHpWgWA16SmjoH1NwJpX66?=
 =?iso-8859-1?Q?1U+ZVmRXYgwIOdQoeN0I7z5pJXD+RpVDioRHMJJl7MEEM+UQGX1WzqfCdw?=
 =?iso-8859-1?Q?D11XXl5fp1QaIwbUNV+aVjZna1bFzd/ct5/1u2JWVqKb9j5id70Do5YrBr?=
 =?iso-8859-1?Q?T5p6srOlFK5P79azEAXp6qYmHxxwdWHXT66jhZnACav7JkJU0dlCTF121Y?=
 =?iso-8859-1?Q?KNOXYaXFb9RHlwuforQqnB7On7eUE8I=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6490d7db-cdc0-4897-e99c-08defd057a37
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:29.8078
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NErzJOpi23dX9I43DrZOsJ60HmAmK/6DSIIYWT41/RPjxkG1bT4YQIYoqarj9XD4xVVp2ZZgz7C34EsNkj6JAw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042912-30BC02AC-34657BF6/0/0
X-purgate-type: clean
X-purgate-size: 4957

Move IRQs from dying CPU to the online ones when a CPU is getting
offlined. When onlining, rebalance all IRQs in a round-robin fashion.
Guest-bound IRQs are already handled by scheduler in the process of
moving vCPUs to active pCPUs, so we only need to handle IRQs used by Xen
itself.

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
v8->v9:
* replace CONFIG_CPU_HOTPLUG with CONFIG_CPU_ONLINE_OFFLINE

v7->v8:
* check only existings ESPIs

v6->v7:
* replace ifdef with IS_ENABLED

v5->v6:
* don't do any balancing on boot
* only do balancing when cpu hotplug is enabled

v4->v5:
* handle CPU onlining as well
* more comments
* fix crash when ESPI is disabled
* don't assume CPU 0 is a boot CPU
* use insigned int for irq number
* remove assumption that all irqs a bound to CPU 0 by default from the
  commit message

v3->v4:
* patch introduced
---
 xen/arch/arm/include/asm/irq.h |  6 ++++
 xen/arch/arm/irq.c             | 60 ++++++++++++++++++++++++++++++++++
 xen/arch/arm/smpboot.c         |  7 ++++
 3 files changed, 73 insertions(+)

diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.=
h
index 09788dbfeb..d043360135 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -126,6 +126,12 @@ bool irq_type_set_by_domain(const struct domain *d);
 void irq_end_none(struct irq_desc *irq);
 #define irq_end_none irq_end_none
=20
+#ifdef CONFIG_CPU_ONLINE_OFFLINE
+void rebalance_irqs(unsigned int from, bool up);
+#else
+static inline void rebalance_irqs(unsigned int from, bool up) {}
+#endif
+
 #endif /* _ASM_HW_IRQ_H */
 /*
  * Local variables:
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 7204bc2b68..6445183f5c 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -158,6 +158,61 @@ static int init_local_irq_data(unsigned int cpu)
     return 0;
 }
=20
+#ifdef CONFIG_CPU_ONLINE_OFFLINE
+static int cpu_next;
+
+static void balance_irq(int irq, unsigned int from, bool up)
+{
+    struct irq_desc *desc =3D irq_to_desc(irq);
+    unsigned long flags;
+
+    ASSERT(!cpumask_empty(&cpu_online_map));
+
+    spin_lock_irqsave(&desc->lock, flags);
+    if ( likely(!desc->action) )
+        goto out;
+
+    if ( likely(test_bit(_IRQ_GUEST, &desc->status) ||
+                test_bit(_IRQ_MOVE_PENDING, &desc->status)) )
+        goto out;
+
+    /*
+     * Setting affinity to a mask of multiple CPUs causes the GIC drivers =
to
+     * select one CPU from that mask. If the dying CPU was included in the=
 IRQ's
+     * affinity mask, we cannot determine exactly which CPU the interrupt =
is
+     * currently routed to, as GIC drivers lack a concrete get_affinity AP=
I. So
+     * to be safe we must reroute it to a new, definitely online, CPU. In =
the
+     * case of CPU going down, we move only the interrupt that could resid=
e on
+     * it. Otherwise, we rearrange all interrupts in a round-robin fashion=
.
+     */
+    if ( !up && !cpumask_test_cpu(from, desc->affinity) )
+        goto out;
+
+    cpu_next =3D cpumask_cycle(cpu_next, &cpu_online_map);
+    irq_set_affinity(desc, cpumask_of(cpu_next));
+
+out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+}
+
+void rebalance_irqs(unsigned int from, bool up)
+{
+    int irq;
+
+    if ( cpumask_empty(&cpu_online_map) )
+        return;
+
+    for ( irq =3D NR_LOCAL_IRQS; irq < NR_IRQS; irq++ )
+        balance_irq(irq, from, up);
+
+#ifdef CONFIG_GICV3_ESPI
+    for ( irq =3D ESPI_BASE_INTID; irq < ESPI_BASE_INTID + gic_number_espi=
s();
+          irq++ )
+        balance_irq(irq, from, up);
+#endif
+}
+#endif /* CONFIG_CPU_ONLINE_OFFLINE */
+
 static int cpu_callback(struct notifier_block *nfb, unsigned long action,
                         void *hcpu)
 {
@@ -172,6 +227,11 @@ static int cpu_callback(struct notifier_block *nfb, un=
signed long action,
             printk(XENLOG_ERR "Unable to allocate local IRQ for CPU%u\n",
                    cpu);
         break;
+    case CPU_ONLINE:
+        if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) &&
+             system_state >=3D SYS_STATE_active )
+            rebalance_irqs(cpu, true);
+        break;
     }
=20
     return notifier_from_errno(rc);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1806c47a08..239d4a7a25 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -433,6 +433,13 @@ void __cpu_disable(void)
=20
     smp_mb();
=20
+    /*
+     * Now that the interrupts are cleared and the CPU marked as offline,
+     * move interrupts out of it
+     */
+    if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
+        rebalance_irqs(cpu, false);
+
     /* Return to caller; eventually the IPI mechanism will unwind and the=
=20
      * scheduler will drop to the idle loop, which will call stop_cpu(). *=
/
 }
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393696.1632513 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUp-0007fP-GW; Tue, 18 Aug 2026 08:48:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393696.1632513; Tue, 18 Aug 2026 08:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUp-0007fI-Cc; Tue, 18 Aug 2026 08:48:35 +0000
Received: by outflank-mailman (input) for mailman id 1393696;
 Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUn-0007em-OC
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUm-008KNP-J7
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:32 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-14
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:32 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:32 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:29 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mmNnfxlASyYfuFq2Jjy/pHdGvrRZFQiBZnLXGTUBPpEq1oyrwh5qQa840qCcGvrIUfCRtUBFyJnw1sKdjvqKudR22plGlp11Tk7eZuYZIeqrJWzBIMDOSMok8+hwPbhGE9dnCyKqnkWSAUWpe6t7iTzokSj1nV0S6Ww7odwW+J6TMJgmuG7ilVDZcFMcbTWr6fxYVU09zEWSxsHHQeTSs0YX8Jgas/HGYZq3KBRWY172oJGiOtDYtdwnAMeFaeRS/B8rKV5nvyEdWYTRKnEcYWcN4yBaGF4YfJW5YEsYMSlp+G++10SZVYC9sfFgnfwe9UetQuj7UjH6C5px4uyMAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hlCHG3dFyvpQr7rVjU5xIUeB5UufTD6urFGufhnw+fw=;
 b=GHZZXYsCXi8sk9pKt1i1GYb3tYLkFBDwF6rS8JCumUbYszoJb8H9/5Qe0vlBHMViaepdxRlGFuGYURXwvQf67raI+eUgVXaUJopZ1QUrOLNf1vx57dhRbBClqW4CZY/Z00fWHF3k+uSuAXtifwrweVTsFCPBrCCZWqE7mENpp/F7mybSlat3wXf62pX1oxd2MrTm5kb3r21jyyKJuU5SBKMWKClJ15CmZQ+f98XryO6+86fs4hcnxK8+efdld/skedU6i9IKC65S+0lthO8thJDYU9H9m43bS+/mgabiY6eYvVMF32MihtlIBsJX+eSwB9PNqxVginH95gPkz0RU/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hlCHG3dFyvpQr7rVjU5xIUeB5UufTD6urFGufhnw+fw=;
 b=Fw7o+tqIS9lw/1RL1vz7DfmbkRGIuX5oIAjfHNFhmbGZbIHc5ekPwTSKAgK3r4JJ+QGySN3rVAgfp86FeptFK2Jjnkam6AeMNo6ka3mN3QnviiEJe3tFnefs1H8Kz+yTpdz2bJTe9FQHwhUqrcjEFge/9PdYxOGnfas4zzm9da02Xr4IjY99yuqN9DCvPdLbjG0b8lPdqw08ZdwSs98WqWiBo8+UhIKiNw97cETT8+dPUQ8E7/a/7lV7TWG9vaTX37Jb2s8NchVN5CLh+ZnKXJ07OVhSxjDeF46Xb4tDbzvCFnKbl84/bFo1QovqbXRaU7AXBCMqf6dKiabs52aFTg==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v9 1/6] arm/irq: Keep track of irq affinities
Thread-Topic: [PATCH v9 1/6] arm/irq: Keep track of irq affinities
Thread-Index: AQHdLu5XGAg8SJKpeEauVTuKn5PLYA==
Date: Tue, 18 Aug 2026 08:48:29 +0000
Message-ID:
 <46f51acfd3afed96499e1ad6388d7c6005375911.1787042017.git.mykyta_poturai@epam.com>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: 046705ea-af75-45a7-7d69-08defd0579ff
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|11063799006|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 zuB6n8qbvSSambOgJmn3YmGiv60AUfXm9xEAeOCKt1WRllSD69vbFp4CtjUy7eWY9Ku39OXcl6pQGI9cUPQ8iAeVTqHKjVhsJxkyPCqyEtezYyr6ykGB5Qrmsy55/0k9jLADJypKqE49N8n87ujvmaYsQOm7+xoCEUpRusrndtHRwjqZVduMltP5lBp4JGb9xt7gYtHLpeYWRf0KkG1j6hzrowK+MXX9LZs3XiLblUTAJG7sxwd+NVefkxoC7PAdm9Rnnlo35/TDXJFFcXExfvpDUXjvD+7dzEWJkFigmlzwj+KsKHIsks7Mg4ehov3KJaJnxdBms6hgh53VzvBBkZwF3uOEnmZX04+5iTdlM3R9n5REaqZk6+hiv1rq95fm0k7y6Hq3IRyWAAeWkEh8cWwyVm4s258kxx3ScGG4n8MiXMfdvyYV63bSUiBZJlLk6PAYtSQ1oqWXapfyD1wIO8RfjqM/vo+xOC2+zrxrWCbIK+DhNKbE8OEf+SxacwB8ewY7JDLYgNCxtcAh8Q7WuPd8qi4WtLuHO1xnL+9jG0mpZ8gsuJh35HK2x21ObceiiUjWE5CulnRb2nwqJogHXkJj5r9zSDKkCh7ep3KMfO8jXKe4w6iwbpcTxmAXnHzn6CdYrjyHiFQ2QpFji5EESlTpwGkvaLYQ8jEA9UwDVUWjneR8fhEIdU21srO6Bt/IJ7OzrNHWqQZmerpf8aRBV+vA4wZna8bClm/y5pt+A7Y=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?R4WmY+zsjKzBHCtR4Zn7bAOWDtQMDtxZpUTZw5yYFGI86oMMRBINzC5eKg?=
 =?iso-8859-1?Q?3RS/1Lbm/EosOiaxUhsUQoml3RcqRWRQK4cTnZz4UbmAvbgg/YW096hU2i?=
 =?iso-8859-1?Q?p6Tf8PWpIc28VVABFxmoW15mu7R1SDcQfuTKXtfGSaWvAJaPOw2JUidc+S?=
 =?iso-8859-1?Q?aVNLC1usFhLwBqRdTnhYc4sAh8HP1qYQ/L7fkrWYszaR9Hx9ohLAUp0G9k?=
 =?iso-8859-1?Q?43GQJ05ojIAcfCMBGewFwcXYlNUCHXsvmQayxxV3YYReN1SXeQ4qlrrpLO?=
 =?iso-8859-1?Q?LiYb1NeJc3rQQRZjoJd6tRXTS2p7eS952E2MjfR9c30LSdpFXRX2dY1g9E?=
 =?iso-8859-1?Q?V1HGOfD7upNOzsjanWoI4Sbe9O6RdvSXAuTsnizehLpJ3HHdzUC0lFlPQF?=
 =?iso-8859-1?Q?t4CUFJe3dvYADXoMXTvIQyM1YQPrPDvwg/CfHfRHvBUTQ5ykLwkEs0XX4y?=
 =?iso-8859-1?Q?ZCfG4gRzsqawyfPbIRyG/sTEuX4B/MYqHiRqbBbFQ+dQSh73ddRJCWHV5+?=
 =?iso-8859-1?Q?MhsPUmaIDXbzcIEKrTylcMXhSa16cJGMyyFnnno/ige9xWIyN6MllUV7JY?=
 =?iso-8859-1?Q?DJ7O7DVuEWh/kd923TY0qZjs63QYBawtG+CeFlb3uQV/L0fG1/sIV16sd6?=
 =?iso-8859-1?Q?KR/g6N37qHZa2vASqSdyefeJkheaLTF2D7VWXNv+5/Cw9l4mLW9tQ5iJQH?=
 =?iso-8859-1?Q?nbUCZqsPCzExg63sjXASAd8bG3NPOsYOk7i5BFks/e+s2m7B1t6ud7A42F?=
 =?iso-8859-1?Q?N2t64oBy25tUmpJNFB9Vdjx00PsHrUzEMTgpFC7xiGIzp0bYzcQ6L8Pmcu?=
 =?iso-8859-1?Q?gcsE3R5COJcUOqmPYxdHScua1h6j+9vQbXxZv15MBuYxcUptegFw/JVzdg?=
 =?iso-8859-1?Q?baFagX2D4y1Vhup5y1/3tPW/FQq5iPaorb2H84Zbi1t8FPQ88AOBawegKS?=
 =?iso-8859-1?Q?IK2Me5YDvBkGLzPjxJoPtmQuKW9k68pujBMxiJwKTfxatWpuzEs5O918G0?=
 =?iso-8859-1?Q?OQYKJe1+gHe0tUCin29ssRMJ2M8GGpSqSJDa3ujaarr5/G+JsXRfKRcDZb?=
 =?iso-8859-1?Q?kUooODg/DIyoUaPjeLkfrO1z+mATt9y8grWUp41Jy9EwC904ZKMJZkzcHo?=
 =?iso-8859-1?Q?FzvVmjqa6R2FETUea5Ziejo757VHKFXncNT6hs7olX+nrZ/lt9zYZFPdQ8?=
 =?iso-8859-1?Q?PvadkS/ORgYgyi0tBLgJS6ilZxac81kHSafqFlnyqebh75aXRIL262CqYC?=
 =?iso-8859-1?Q?5DJCBUGGOgsKV9GW366xiarwv7EyiAZXbZv7ZJIf7uMHWuFXuWglLr5jio?=
 =?iso-8859-1?Q?+NrvCIq8DKjnT3m0uZ+wChuDzXk5lusi5+1zzHU7h2N/eyPXMov6jWsMy0?=
 =?iso-8859-1?Q?0Xd/UrKmENRpCQbu2dFtbxpZXSCg40rbV3BYK7kzzDnJ008SWyQKZ1qO40?=
 =?iso-8859-1?Q?luGhzq8VzUN4rtGGl3KzGrVIzSJXYov/rG/HCRrLDh7NVE09O2BjT+9Aln?=
 =?iso-8859-1?Q?xNvtJe0fMrsyzIxA105RiyAS9+GXcbcF6KLdfF/iDNAxkrHL3w17biJwd1?=
 =?iso-8859-1?Q?CKWTaWuHCjMAkHIvf3qn5pDZOVfAXSua496I0sN2NKPu4au/gIg6wZruPJ?=
 =?iso-8859-1?Q?GJEuHYO+tdy+7Db5N/tTkDwZyHIZpifPUwjOa2yd5D7DNVRphQ722+95/G?=
 =?iso-8859-1?Q?UeKw9cuZzUnmPknG65yXvxv00lsAsayrNW2vOUMyjl61k3Nlmv+gJ6MTSG?=
 =?iso-8859-1?Q?fVZaFutvBXThI0Sqh4r+axtIXb5OY2efcuFOgIbOrMz1lKmr2afNXdLnFN?=
 =?iso-8859-1?Q?H0fngIng3uj/IoxoVjqlGUDeCyJnIMY=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 046705ea-af75-45a7-7d69-08defd0579ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:29.4938
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OIgKR14UjhzweAIabq2UcL5CUZXGRqhCiz1h3JWfIg/AFFH9Kff8ZgBSYXk/O3vBpBWJgiT545ic8bxCf3DSwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042912-66AB52AC-BB66A04E/0/0
X-purgate-type: clean
X-purgate-size: 7541

Currently on Arm the desc->affinity mask of an irq is never updated,
which makes it hard to know the actual affinity of an interrupt. Fix
this by updating the field in irq_set_affinity. Changing desc->affinity
requires desc->lock to be held, so add an assertion to ensure that
callers of irq_set_affinity are doing so correctly.

With desc->lock now being required for irq_set_affinity, add locking
around calls to it where it was missing.

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>

---
v8->v9:
* no changes
v7->v8:
* no changes
v6->v7:
* update commit message
* fix possible locking on null desc
* collect RBs

v5->v6:
* add missing locking around irq_set_affinity calls

v4->v5:
* add locking

v3->v4:
* patch introduced
---
 xen/arch/arm/gic-vgic.c          |  2 ++
 xen/arch/arm/irq.c               |  9 +++++++--
 xen/arch/arm/vgic.c              | 14 ++++++++++++--
 xen/arch/arm/vgic/vgic-mmio-v2.c | 11 +++++------
 xen/arch/arm/vgic/vgic.c         | 21 +++++++++++++--------
 5 files changed, 39 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index fae80e6cd2..28ad4903b4 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -232,7 +232,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
             if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
             {
                 struct vcpu *v_target =3D vgic_get_target_vcpu(v, irq);
+                spin_lock(&p->desc->lock);
                 irq_set_affinity(p->desc, cpumask_of(v_target->processor))=
;
+                spin_unlock(&p->desc->lock);
                 clear_bit(GIC_IRQ_GUEST_MIGRATING, &p->status);
             }
         }
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 73e58a5108..7204bc2b68 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -216,10 +216,15 @@ static inline struct domain *irq_get_domain(struct ir=
q_desc *desc)
     return irq_get_guest_info(desc)->d;
 }
=20
+/* Must be called with desc->lock held */
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
 {
-    if ( desc !=3D NULL )
-        desc->handler->set_affinity(desc, mask);
+    if ( desc =3D=3D NULL )
+        return;
+
+    ASSERT(spin_is_locked(&desc->lock));
+    cpumask_copy(desc->affinity, mask);
+    desc->handler->set_affinity(desc, mask);
 }
=20
 int request_irq(unsigned int irq, unsigned int irqflags,
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e5aca17dcb..7a87bc2c7b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -450,7 +450,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *ne=
w, unsigned int irq)
=20
     if ( list_empty(&p->inflight) )
     {
+        spin_lock(&p->desc->lock);
         irq_set_affinity(p->desc, cpumask_of(new->processor));
+        spin_unlock(&p->desc->lock);
         spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
         return true;
     }
@@ -458,7 +460,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *ne=
w, unsigned int irq)
     if ( !list_empty(&p->lr_queue) )
     {
         vgic_remove_irq_from_queues(old, p);
+        spin_lock(&p->desc->lock);
         irq_set_affinity(p->desc, cpumask_of(new->processor));
+        spin_unlock(&p->desc->lock);
         spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
         vgic_inject_irq(new->domain, new, irq, true);
         return true;
@@ -478,6 +482,7 @@ void arch_move_irqs(struct vcpu *v)
     struct domain *d =3D v->domain;
     struct pending_irq *p;
     struct vcpu *v_target;
+    unsigned long flags;
     int i;
=20
     /*
@@ -499,7 +504,13 @@ void arch_move_irqs(struct vcpu *v)
         p =3D irq_to_pending(v_target, virq);
=20
         if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->s=
tatus) )
+        {
+            if ( !p->desc )
+                continue;
+            spin_lock_irqsave(&p->desc->lock, flags);
             irq_set_affinity(p->desc, cpu_mask);
+            spin_unlock_irqrestore(&p->desc->lock, flags);
+        }
     }
 }
=20
@@ -579,8 +590,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsig=
ned int n)
         spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
         if ( p->desc !=3D NULL )
         {
-            irq_set_affinity(p->desc, cpumask_of(v_target->processor));
             spin_lock_irqsave(&p->desc->lock, flags);
+            irq_set_affinity(p->desc, cpumask_of(v_target->processor));
             /*
              * The irq cannot be a PPI, we only support delivery of SPIs
              * to guests.
@@ -949,4 +960,3 @@ void vgic_check_inflight_irqs_pending(struct vcpu *v, u=
nsigned int rank, uint32_
  * indent-tabs-mode: nil
  * End:
  */
-
diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio=
-v2.c
index b7c2d7ce99..fc04741ca1 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -159,24 +159,23 @@ static void vgic_mmio_write_target(struct vcpu *vcpu,
     for ( i =3D 0; i < len; i++ )
     {
         struct vgic_irq *irq =3D vgic_get_irq(vcpu->domain, NULL, intid + =
i);
+        struct irq_desc *desc =3D irq_to_desc(irq->hwintid);
=20
-        spin_lock_irqsave(&irq->irq_lock, flags);
+        spin_lock_irqsave(&desc->lock, flags);
+        spin_lock(&irq->irq_lock);
=20
         irq->targets =3D (val >> (i * 8)) & cpu_mask;
         if ( irq->targets )
         {
             irq->target_vcpu =3D vcpu->domain->vcpu[ffs(irq->targets) - 1]=
;
             if ( irq->hw )
-            {
-                struct irq_desc *desc =3D irq_to_desc(irq->hwintid);
-
                 irq_set_affinity(desc, cpumask_of(irq->target_vcpu->proces=
sor));
-            }
         }
         else
             irq->target_vcpu =3D NULL;
=20
-        spin_unlock_irqrestore(&irq->irq_lock, flags);
+        spin_unlock(&irq->irq_lock);
+        spin_unlock_irqrestore(&desc->lock, flags);
         vgic_put_irq(vcpu->domain, irq);
     }
 }
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index b2c0e1873a..1c44236c4f 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -812,22 +812,27 @@ void arch_move_irqs(struct vcpu *v)
     {
         struct vgic_irq *irq =3D vgic_get_irq(d, NULL, i + VGIC_NR_PRIVATE=
_IRQS);
         unsigned long flags;
+        irq_desc_t *desc;
=20
         if ( !irq )
             continue;
=20
-        spin_lock_irqsave(&irq->irq_lock, flags);
-
-        /* Only hardware mapped vIRQs that are targeting this vCPU. */
-        if ( irq->hw && irq->target_vcpu =3D=3D v)
+        if ( !irq->hw )
         {
-            irq_desc_t *desc =3D irq_to_desc(irq->hwintid);
+            vgic_put_irq(d, irq);
+            continue;
+        }
=20
+        desc =3D irq_to_desc(irq->hwintid);
+        spin_lock_irqsave(&desc->lock, flags);
+        spin_lock(&irq->irq_lock);
+
+        /* Only hardware mapped vIRQs that are targeting this vCPU. */
+        if ( irq->target_vcpu =3D=3D v )
             irq_set_affinity(desc, cpumask_of(v->processor));
-        }
=20
-        spin_unlock_irqrestore(&irq->irq_lock, flags);
-        vgic_put_irq(d, irq);
+        spin_unlock(&irq->irq_lock);
+        spin_unlock_irqrestore(&desc->lock, flags);
     }
 }
=20
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393699.1632529 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUq-0007t8-A6; Tue, 18 Aug 2026 08:48:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393699.1632529; Tue, 18 Aug 2026 08:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUq-0007rX-4S; Tue, 18 Aug 2026 08:48:36 +0000
Received: by outflank-mailman (input) for mailman id 1393699;
 Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUo-0007f3-EU
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUn-008KNP-RH
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:33 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-22
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:33 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-7
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:33 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:30 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:30 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XA7euOYsHUVqwmqOXJ4CECa1OsyPTZN8QlhRI4iFAs1dDAwZcLbwqhpVJZZKvhVoBuS55URw6rEECrWJl/P9whRxQAPe9w0eTf1mX3ldDhA9dkaCLOQDm6RN/TlB1g9CjKZMWUbEU5NGw0S4zZvnoU4ghINB0r70YV28PGQndvwG1dERUt+h4pikxYeLw/COXDhg/r5yLw+w76t9Cn3Gck71CG6EubWnrHIBXkY/7KLzGU9PI6nDItME3JZh7HRPZ+JBzzUXuyxqrKOe7PJCZo4yBiK94watAsj2rqapJX1IRoKZnJH9qacsDOALzRBlH4A9VLBaOxTnOFyYzfyuhw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UCYQupUGrePIwOZoFAb9n8q7lPaplrW6wSkuZ8P8hMk=;
 b=NuNkRuDN/jjsshObkBB8PeV0tFboncsAStK0/UmMntO0r6IeLlKD62RkLzv701RHhPoN2w4LUfuNowtCt6RuJtXKid3E4wGUWn0dRr+5rrLNzP7tI7n0vYhlaXsUguhbul3Kz+kpwVsBgEcoeNa0sVRJ33PcFx7T60dH1MjoQr6zxhAXRbpB0j1RGY2vWiT0n22iBMY7pPd/9NWINbuKcv9f/x4PzufYSAqlnWn77rdWIObQw56aI/xYeq32SUg5cvYj3fRM4r7GFlJ0XPMDAK5SHVSsWNTCiPkjXcXS29EdVkehXlTU4oASI5ElZ9pCUa5x3+4jbTpzkQzCC72Klg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=UCYQupUGrePIwOZoFAb9n8q7lPaplrW6wSkuZ8P8hMk=;
 b=h+RABc+jFhGt6wY8u0z25aQ+NRQi2Fr3OjEaiW/b1a0f99WeHo1utkbUK0tCDy9Pw6ypwCR0GTiDODbH//EnuWwLvpEguET8YFvaq10cxQ543VTtrxMXIdZzz3j92E6Kb2tLoyJ4SX8seX/kgbt3F4AYnE8xbgtiAydQDUP3j40z5xEiXt2bZ9VfZX+sY2lI8M04Dwx5vHMPAfWTZrZn3qAHW0Ny8E6TVYTtlI6m7KxeMh18Md0/MIkt6rZYrEwXvzx5PjexPfHWVIlsArTHAsjTWrWtXA7JJO9j5bVRatIp0ssPgnFzUFXnSEW4pavAi00xU75avdpEAN6XokRyDw==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD
	<anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>, Julien
 Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v9 3/6] Kconfig: Make cpu hotplug configurable
Thread-Topic: [PATCH v9 3/6] Kconfig: Make cpu hotplug configurable
Thread-Index: AQHdLu5Xf1tMU9esMkGqVTTU0TAa7Q==
Date: Tue, 18 Aug 2026 08:48:30 +0000
Message-ID:
 <81919da6e316cd22e06f34ccd8826695adde3293.1787042017.git.mykyta_poturai@epam.com>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: b8870e4e-62e7-46ad-7552-08defd057a6a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|11063799006|10063799003|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 Po0GifBh7cgp5az8JAVK52TOF6unxWcuStOsIXG0KHnPA6FrSlCuB91pYzqucmQr7X6Bbj6+DYxwxcbK69lhMjdU/TEQpiJ8toasQP16Zd2+7mWquvS7Vk9nvJFBlLnmRlBirVcoOcYBNEZedoo08Xm61ffeN1hQzmhz2WDvtYw+FEEO1DM2K5es41gvd3O0GlOjlkrzMwtxX2IxSnBW8rBmKbUJfTT4u5gx52XE34BAmwuIyDJF8AjKcxD+9eLTTIxuIXu083lhx1MOv0irL7G4f/0II8btsq12RZ1oTJWB5/B9aNv1Zt8+4SUf/L8uTnOEKfHaw3o9WgpU6nNdLRJkI/eppEX000PDRxZfSO4gMOZPolPxQFTLqrEHwxAk029xGnlVeMVPXxI/Y495dfKPcI0ryZMWRL45zxt30L8JT5CtfTfrOR9M+TVoB6qKTiHy8//+t91cIb0zvzkjKBr+4yYKZQvrLAMSj9bCy9dk/9Iwt0sp+Ef92Jhdz0iFu0F5P3JfuyXOGd36qOntRzWN3T183nILdUHSqX3yByct2T0iJeaydRBtjOEVhxFCb0EkWx3iGfyt9pAHS6fKEEejwGw/x6eaLQn/YDeiGZjlivV6TkiWSKJfn9jQimjY3EuEQ4yUqZn9PWzkcBQjtY/RSA4tbE8h28MpIT20bA93apt0+drMD2nk1UzkcjuBcJgZwxcMox0utFwHblwUPL4nS0hngG044tczF7UhAOo=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(10063799003)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?1VxlDq+IjzQtAWBqqG4EAI4h7cFCNSqWrMKnQWKy+N7PHesyT0e+L4YcEO?=
 =?iso-8859-1?Q?XTH983gq7yFooDOA7Nah5EX+rb4iTmQPoZIl42IwdCBeinFqugDxuV2KML?=
 =?iso-8859-1?Q?9alTWk38FrKIqqyw8cDC7jA0opcrpwDLvwoUXymCfnxf67tHCEV6cRCQ/w?=
 =?iso-8859-1?Q?feiBNPEv3ku+yvPWyAZckRsaMTj9lNYCAFaV/gWptoDNr9cCqKBDYZKcDS?=
 =?iso-8859-1?Q?0ZgCkdlrn9TgCItUFjBk9KFXn9OVbFRsTTbu1HM7oaX/0ROn/Fd425w59/?=
 =?iso-8859-1?Q?v/QjJadW2puRlWM/dAOYPzM7VzFFuIFIdbDUVDBaY4I/d5tccYVeLoccAa?=
 =?iso-8859-1?Q?wylY3HD0vudzKvRtOiOmablO2BM4PViQacddYKD2DmzZMBJC2n8XWRk7wg?=
 =?iso-8859-1?Q?jcNY6L+tnB5JAtqehjloRWx38f2QJ/VxxUVGKhAprVySXM0ihbD+CBfPU9?=
 =?iso-8859-1?Q?XKbxD8m06F+WV5tpb7g0rT2e0zCyQMdNIjHgar6KOTOIawjW7uvbDryEN9?=
 =?iso-8859-1?Q?GspadPRvcQg4sVBa2c2zNWNVPBrX5zUvYNL/oYIM6HlzN9IzLf0gLBhZSj?=
 =?iso-8859-1?Q?dBr5vnizTi+GbRo7mFXTF1hfg3HOwllyidbu/FJWfzxgBdpmg0q2LaPvua?=
 =?iso-8859-1?Q?RRY5/361EHjrVUqz50YihGBuolqDWfxJGgwsSZwC1XStcpbk4hzAUhT+PI?=
 =?iso-8859-1?Q?uWmCVMqrls/53D9NhERed770wAOjIpOOPJb9ddbiark0q5AY3RzQUzp5tU?=
 =?iso-8859-1?Q?yEySHFSdYg/H0q1GoHPuATPnAq57SsnbsiZnsm0W1uFiaFuw3tCGyawas3?=
 =?iso-8859-1?Q?Sgww1+qlzo8JPxtfWBrbdb0HRUh62JzD8ZXZFvQE6qzjdupi0z2w+g6wsS?=
 =?iso-8859-1?Q?Oy2QLYwUhrtbglqf+qSyVUtjlHrJq0Y4llvcnxZUQfebDSd/+pwDOZecSh?=
 =?iso-8859-1?Q?ET8t8H0EnpfjkQjsph7ahzLDTF2uFQG4bbXzJpM1+xH6rDHERVkeih3+yA?=
 =?iso-8859-1?Q?hxJmbT1A7B1LZe1t2VFvgEyuZBK0dJUwTd0uFybN52Pr45aEi4fMhsJTZU?=
 =?iso-8859-1?Q?iIWmsbCwxSL3uUOxxhWbu+7QaydqRxG+4oEv5AZib4EIY0MZEbt0p9u6l2?=
 =?iso-8859-1?Q?9WbV8PYeJwLdjKeBerAZlHrpVtVjhOLtaKOkNzq3YXAFzh6mRfIuTV0/df?=
 =?iso-8859-1?Q?KSf+NMoCNIN2z6+6tATD2hwRg0Dmu+pVRvUyqFT2KsQ2/d0TNzQNVcHWet?=
 =?iso-8859-1?Q?Jss9AmWDqr+WF7H5s6QNYUiZJjEiLjAZKhgPRW7JuMyOMeYFSLyevI3MbO?=
 =?iso-8859-1?Q?twTboAog/UjyZeEN3qqIawew+aoeMM3+nNM1oYG5i8DqUUXHF/gy6nkWAj?=
 =?iso-8859-1?Q?CebF9Zk3RT5zoXWzjBBz0K4gXaMVhNEv1RlZWkFvQKrStVoYun6Z5JFHdU?=
 =?iso-8859-1?Q?bfbwrOtYjJtjRiodW5sYHn9vrFSz0LPdjJ3qXkbwWmZBiGKBEXlvj1yCjo?=
 =?iso-8859-1?Q?Yq6jlLhrnC1tLxf9jIZvMgbZX8gO2hv7LSZgnse+tb3X9hKOSCrhYvsqIn?=
 =?iso-8859-1?Q?jNay687mOyJaHVHl9kUAfX4gOSope3OOcCFoGebC/PSNtZuHYFaTKnOsjx?=
 =?iso-8859-1?Q?tB/mTrnOFO3rw410Dz4CcOrGYAhndHgAXDZsnWG/woaGQAucQkiEbdwwIa?=
 =?iso-8859-1?Q?G4i1j40QXLNvOevfp16Do41ITwO1VWBt/cc7piusXr3VmPEQL+TO7IAsQs?=
 =?iso-8859-1?Q?2VPsWbiOpFyTlvODMcNfozeUo2vxX96Dq46R10zaBM4kDlFZNo8bsIN+mQ?=
 =?iso-8859-1?Q?pSqtvSf7u2WRc6KlsdG7fFczmU+yYsU=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8870e4e-62e7-46ad-7552-08defd057a6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:30.1569
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8v+Z4m5n6tEJuuc74GyCj1PF/lsHcFu5S1I+lyB0C18Ce8ZikNlGflzQmesJEG7b+qGsvY1G+YG5dUaFrJRabA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042913-30FCE2AC-2EB71826/0/0
X-purgate-type: clean
X-purgate-size: 3660

For the purposes of certification, we want as little code as possible to
be unconditionally compiled in. Make CPU hotplug and SMT operations
configurable to ease the process. This will also help with introducing
CPU hotplug on Arm, where it needs to be configurable.

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
v8->v9:
* add "if EXPERT"
* add AB

v7->v8:
* fix style
* s/CPU_HOTPLUG/CPU_ONLINE_OFFLINE/

v6->v7:
* new patch
---
 xen/arch/x86/platform_hypercall.c | 12 ++++++++++++
 xen/arch/x86/smp.c                |  3 +++
 xen/arch/x86/sysctl.c             | 12 ++++++++++++
 xen/common/Kconfig                |  8 ++++++++
 4 files changed, 35 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hype=
rcall.c
index 6dee4922f3..361a4cd37a 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -735,6 +735,12 @@ ret_t do_platform_op(
     {
         int cpu =3D op->u.cpu_ol.cpuid;
=20
+        if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
+        {
+            ret =3D -EOPNOTSUPP;
+            break;
+        }
+
         if ( cpu >=3D nr_cpu_ids || !cpu_present(cpu) ||
              clocksource_is_tsc() )
         {
@@ -757,6 +763,12 @@ ret_t do_platform_op(
     {
         int cpu =3D op->u.cpu_ol.cpuid;
=20
+        if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
+        {
+            ret =3D -EOPNOTSUPP;
+            break;
+        }
+
         if ( cpu =3D=3D 0 )
         {
             ret =3D -EOPNOTSUPP;
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 7936294f5f..9046c826f8 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -418,6 +418,7 @@ void cf_check call_function_interrupt(void)
     smp_call_function_interrupt();
 }
=20
+#ifdef CONFIG_CPU_ONLINE_OFFLINE
 long cf_check cpu_up_helper(void *data)
 {
     unsigned int cpu =3D (unsigned long)data;
@@ -445,8 +446,10 @@ long cf_check cpu_down_helper(void *data)
 {
     int cpu =3D (unsigned long)data;
     int ret =3D cpu_down(cpu);
+
     /* Have one more go on EBUSY. */
     if ( ret =3D=3D -EBUSY )
         ret =3D cpu_down(cpu);
     return ret;
 }
+#endif
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 6bd4e191a7..10d485e633 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -53,6 +53,12 @@ static long cf_check smt_up_down_helper(void *data)
     unsigned int cpu, sibling_mask =3D boot_cpu_data.x86_num_siblings - 1;
     int ret =3D 0;
=20
+    if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
+    {
+        ASSERT_UNREACHABLE();
+        return -EOPNOTSUPP;
+    }
+
     opt_smt =3D up;
=20
     for_each_present_cpu ( cpu )
@@ -120,6 +126,12 @@ long arch_do_sysctl(
         long (*fn)(void *data);
         void *hcpu;
=20
+        if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
+        {
+            ret =3D -EOPNOTSUPP;
+            break;
+        }
+
         switch ( op )
         {
         case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index da80fdba84..f029addbfd 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -643,6 +643,14 @@ config SYSTEM_SUSPEND
=20
 	  If unsure, say N.
=20
+config CPU_ONLINE_OFFLINE
+	bool "CPU online/offline support" if EXPERT
+	depends on X86
+	default y
+	help
+	  Enable support for bringing CPUs online and offline at runtime. On
+	  X86 this is required for disabling SMT.
+
 menu "Supported hypercall interfaces"
 	visible if EXPERT
=20
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:48:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:48:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393702.1632554 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUr-0008LM-UD; Tue, 18 Aug 2026 08:48:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393702.1632554; Tue, 18 Aug 2026 08:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFUr-0008I0-Ij; Tue, 18 Aug 2026 08:48:37 +0000
Received: by outflank-mailman (input) for mailman id 1393702;
 Tue, 18 Aug 2026 08:48:35 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wwFUp-0007fc-NA
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:48:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFUp-008KNP-3T
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:48:35 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5b-2eae-0a2a0a5409dd-0a2a4502b71e-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:35 +0200
Received: from [52.101.65.110]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a841c5f-6ca4-0a2a45020019-3465416e3afa-10
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:48:34 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by GVUPR03MB11425.eurprd03.prod.outlook.com
 (2603:10a6:150:362::9) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 08:48:31 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:48:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XTkMQo97HukRcTjjrOdCPFZAOTEcKLCdic5vYcGQKu91E+T0Qk239U5V8xAUxv7fIVD6Fo3zGFYBWwxLXfIZGw/ScR/RFh+tmIHijEn4dCttTZcUimG8wh5uS6dPsGLG0XyqOFUj5LadN3UGA1CcDcDjm9wUWlAOiIbUW1BggTOX1OuVCSiD4eENIlpAlBRlzo9bHhNO+IYc+HkAas7ljEp2arLamFw+7Ygk4xZK7acPMIRUWAsC82FiTNhMeIlJaTlRP9qUS2dLBxH/0PdFrYmehFUZGFbjutwEFyKOVzjKKZYJH5E+5CBG6yDJbcrIiqGiJ4qmXCeDvZelCToFrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=k7+zNs5V3iR8FEEzs42eWXELhKzBBEEuVxpRSiUeRFY=;
 b=anZ6wV0bEIGfd4IZ5l1q5vojvSbApI/gp06fVrTsDrif4KNbsjp61GRGnRc0cpilZhfap+m3i98j2RtcOJrgBPN/jzVuthJlQEeD6Fa5uSto1P3jRF1wOxVAgFUtZ4yPXr5CiSsB/bVD3jmgkZV3yRh403BOgbElTwyeTk7d17TfghakBKMdjGcOTRP7QoqASCsuIf277OvVDKPkwUFT9Zn9WGqYgri7UrH0ECVeJoSdDUo2zvh6OG6FTww9pJoftIFNT6rZHhHUBT2ed9V3F5Rwdh6g3JCEsyGIf875pVOVGbyjM0kprBfIcfJD3gtv3cBTKHqAykvZdwi3qYf4Tg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k7+zNs5V3iR8FEEzs42eWXELhKzBBEEuVxpRSiUeRFY=;
 b=W4tTvG1YWsrxDEwpGu8TEG/9YMQfKpabcvlJLV+SlDa22u+/NvTMfEBvMVVdXEBAU7jataHMlo6teGVNTtsvCFRbKario74J1aUqiUFpv6UdnSnZ41z8EAngOwCjNswAqeo0h6Kz9GPRNuWVwPyQbrPQsLtgGEhrq5H5dP1jGAkt9Wd1twOcXN77eAIAggCHUs75vYIt/AwVZMtqhVeXqbCSkClbK/y/t15R0XeU0/PsRTNHZgEgqiur1U3GjNJY0Lqy0LEfmpdsuGcibNnzKfhFUVCqtsTcCpxHjTSsmLeTR+9r39+6EppngH2wT1/mmJBoPx5yI2W5Z0RIdms57A==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, Julien
 Grall <julien@xen.org>, =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	<roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v9 6/6] docs: Document CPU hotplug
Thread-Topic: [PATCH v9 6/6] docs: Document CPU hotplug
Thread-Index: AQHdLu5YUFC+BXJe80SorzYjSmg7Eg==
Date: Tue, 18 Aug 2026 08:48:31 +0000
Message-ID:
 <70484b3362f3b816bf4ed5f70c374c198a8a6eea.1787042017.git.mykyta_poturai@epam.com>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
In-Reply-To: <cover.1787042017.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|GVUPR03MB11425:EE_
x-ms-office365-filtering-correlation-id: 8133ac73-a04d-475a-a03c-08defd057b2d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|6133799003|11063799006|22082099003|18002099003|38070700021;
x-microsoft-antispam-message-info:
 KjbZAH/XJGRhbvE2b+wzOnWzCRJUCCj8b3hdnGrfp9iPE8u0bslYAWsS2yQZAfNbO7s87bP0B1wR3plVBxTffTSEU/wWWympZAeLMKRq0hwIbkFln3M/CFx/wvgnUgwUBDXp2qexHIo4lhO6aeDsE1/3tWw9aeazAUALAXTUsefnhDU7gtokXeuPWBWcl8i4Kp+trNiFgUNvPKQpKhQgEiOrLVgzSgiatM7iJLJ06/xBbNrAowNCqgd5DdzYV/oJCthS5ZWA/3eJgtIBVngR/KY47A9ayZ8z7yXpVpvYeJfWjfrmH4qDE030b3XTmOx8bpsByeZKQIIz+Y8P2CCsw8JYWW2g286o/Q77UmUTMMGHQQ0YWZgddDMTt3rSaPEoY/FVQXV+jPkWT6aDnKOuH/PJxqbJC/hm06WaJD40KbzjsYUCMdUkuYX+kv2QSDaBBsUAiUKEv1720Nm+2/sAJpZqgracP0qkb9tBJPcuBLodLp8cNZdwmwOagU2bC+okDcKOGAwgIO/+qthmBPu1UoESSUafS/7kJWcG0YSJ8LtLNV1XchmArd3gi2an/wY6kieBkl2vKcXuYKY8V1SkLJonZgCjoS0Wo87l6JwpCU9Din2tIgai15j3HC4Wrvi/H1EQ53kPeJrLke3UmZVD8O9okfra+iP8VeJskNJSO/ZNEBL9s4MIgQr4MMIsBq/gT4CKJLFfGUdgPw2GnkdkRFgCnyw6JvaVZV4/6ajdKuI=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(6133799003)(11063799006)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?2ojB5AR8Ck8eXZFBdYgtzZcSvfFQwhP7HrAIWzcZpNMZfCOjTXV0HKAmYp?=
 =?iso-8859-1?Q?PWg20PJzYzp44zH5IthV2jB2DDJ8mSH3QZH0VEeNVtwQ1X78AQbyjV3JaA?=
 =?iso-8859-1?Q?U4woDs2+HCfcT6a/vOaJX8WQIkee4bV2/JEBDZ/o65PzD/rzllsKSMWNBJ?=
 =?iso-8859-1?Q?pp6//ilsWm9XU9eAYE6WuJQ6fJYC7dzJuojJ4lBjgIiuN10iVy9DOoPASo?=
 =?iso-8859-1?Q?FmhRJRiSjUvjKqMMnxVYp2ODSnFn5Z+RiRyDpo0WH26MO34KyuefvwXgzD?=
 =?iso-8859-1?Q?abzG4zZYkBnTE27/17TGWKTp9kkV0wwZJE0sz8tQgGDh/zjsViiPzCgIlM?=
 =?iso-8859-1?Q?iIk4dPnpsUaQwwJ0Xai86fvdO4hs/UZDqLCxpwHmMkLcFiLYYqwzIWzjeX?=
 =?iso-8859-1?Q?y40qodwAXR3qCmmP1sdtOdMNIhsOZtc6w/Ge8HNPPMcqWfY7RNbxL88ML1?=
 =?iso-8859-1?Q?5njX4ozlCFwcMgljC5rl/+7+0MG+23eCMYc1gEyu/KcojFAPc79ffdcci1?=
 =?iso-8859-1?Q?q56e0E/rj8fWgITUIHsQsMpFdZuP8ndW6rp7jl9HL9jG5gYacf0lLGXzCC?=
 =?iso-8859-1?Q?RJ2dgorp3genXpNQltkMAykn8+ZdGj8zpe2MtWEtg6M1qkBf82VCj6ioi4?=
 =?iso-8859-1?Q?DSCT880TbCyal+FH/hYwPGktAsbW8ar+9hb1gCcBkwZymBGlemNA+wtqLz?=
 =?iso-8859-1?Q?BMBp5YrZZV9Q1HWxlnSNebi2VgOBUxzstYiHjvl9Dl5ndD94qRrr/qSKWc?=
 =?iso-8859-1?Q?IV6M3IvphmeIWTlqHw4egeetbtYy2xjfZjbfHyACqW/QQZkZ3QhaC4BUrU?=
 =?iso-8859-1?Q?iK/31PilvQy/xfmn30wsRnb3ZcDP4AjbsEiegMI6kPYuOF/Ylyl5sT+mGU?=
 =?iso-8859-1?Q?ur0+f/Eu3tOpwO6j49nL0lbhRz3HQ9jx2cr5m0z60AEqS2Xjyp4J+Y4g8e?=
 =?iso-8859-1?Q?VjeGooE7hozUqjiNkgPc2rDZTgl3gOQ6YHHeN+nfjPT5uul9dMeRU7dCXL?=
 =?iso-8859-1?Q?PTADF4JkTXYCLThvZ/VOmT2m1/utHR01M+zj2Mqo1puK4pGXR8J0kBqIPQ?=
 =?iso-8859-1?Q?PpUQryTKqposD8BEAx6QKOF9WldtZjXa5j9l05akFvJNNDhldrN+dsdRra?=
 =?iso-8859-1?Q?qss3YqS5GuHqZ1GUyNw8hH6c8qzB7LApCgb1fBje+rY6P8eqbN9T8UOHOV?=
 =?iso-8859-1?Q?1m5y7D36pNM7qMuqr+T7l7xxwMLYhgJBwfFXje+gMOkPaUlTktgHubON4y?=
 =?iso-8859-1?Q?MrBNXAomnvGT03weC7Kq1OyM1cHgN1fKRUAPHInyrreVRctQxgPC4n9rHa?=
 =?iso-8859-1?Q?Fw9czuYKPUq/jQ42Gv1qZjXXuUCnXaFf+SSVwqbpSvaCWbGe2EarCs26Se?=
 =?iso-8859-1?Q?Cc//wtBTRGqzRG2qrCe/WtGkcdHUYZKhkL6MdE4phdhbR4ZruvJsG1ZyaT?=
 =?iso-8859-1?Q?OXnvsJLCTBP/XyaBySDy1o93xyD/QY2ZO05urnWKWkKG2sCVsGvK1cvEiI?=
 =?iso-8859-1?Q?D+A0qlYVeC77P/pTfnz26UBBTVMIRWmQR/gYpTt4xYQz5ux6w0WoqSQHot?=
 =?iso-8859-1?Q?rLBU+OL7bv0rvlIBKL/+9bMUWhPc5BzA/yykUmdDLRT6piFKR7GZnLDLco?=
 =?iso-8859-1?Q?LbZXF6a1STSJQHKlnfkvYci6f2p2yDj2o+SBAxey0pegHA5tQp0eoZeRCW?=
 =?iso-8859-1?Q?xqXyZ8fqbS+VPbo7fzJS/XfX4SRptJAZ1yiWW05njegBdrrP6bEH1vG+f+?=
 =?iso-8859-1?Q?lLyAGw9hSZpBgo7VS1thDuAsPBqPLbxBjWID3ET6BTHmqLM0BUSEVq4bDq?=
 =?iso-8859-1?Q?sLw4A9XmwBKj7ArB+B/I1K4mWbRmKMI=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8133ac73-a04d-475a-a03c-08defd057b2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:48:31.5978
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hc7tdIsq4js1AKsZm7JjgQV0H93WsuumKyf/MjUwtTMW31iBFdJ4DJY24MHIuHUBQeOqtbX9yZbmIvnVrA+qeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11425
X-purgate-ID: tlsNG-720697/1787042915-F12A12AC-A8ED2642/0/0
X-purgate-type: clean
X-purgate-size: 4120

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---
v8->v9:
* fix typos

v7->v8:
* remove support status update
* update config option name

v6->v7:
* add testing and limitations

v5->v6:
* no changes

v4->v5:
* s/supported/implemented/
* update SUPPORT.md

v3->v4:
* update configuration section

v2->v3:
* patch introduced
---
 docs/misc/cpu-hotplug.txt | 98 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 98 insertions(+)
 create mode 100644 docs/misc/cpu-hotplug.txt

diff --git a/docs/misc/cpu-hotplug.txt b/docs/misc/cpu-hotplug.txt
new file mode 100644
index 0000000000..4f6068db30
--- /dev/null
+++ b/docs/misc/cpu-hotplug.txt
@@ -0,0 +1,98 @@
+CPU Hotplug
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+
+CPU hotplug is a feature that allows pCPU cores to be added to or removed =
from a
+running system without requiring a reboot. It is implemented on x86 and Ar=
m64
+architectures.
+
+Implementation Details
+----------------------
+
+CPU hotplug is implemented through the `XEN_SYSCTL_CPU_HOTPLUG_*` sysctl c=
alls.
+The specific calls are:
+
+- `XEN_SYSCTL_CPU_HOTPLUG_ONLINE`: Brings a pCPU online
+- `XEN_SYSCTL_CPU_HOTPLUG_OFFLINE`: Takes a pCPU offline
+- `XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE`: Enables SMT threads (x86 only)
+- `XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE`: Disables SMT threads (x86 only)
+
+All cores can be disabled, assuming hardware support, except for the boot =
core.
+Sysctl calls are routed to the boot core before doing any actual up/down
+operations on other cores.
+
+If there are Xen-bound interrupts pinned to the pCPU being offlined, they =
will
+be automatically migrated to other online pCPUs. Interrupts used by guest
+domains are handled by the scheduler when it reschedules the vCPUs to a ne=
w,
+online, pCPU. When a pCPU is being onlined, some Xen-bound interrupts will=
 get
+redistributed to the newly onlined pCPU to prevent imbalance.
+
+If pCPU being offlined has some vCPUs pinned to it, they will be automatic=
ally
+unpinned and migrated to other online pCPUs.
+
+Limitations
+-----------
+
+On Arm64 cpu hotplug is currently not compatible with ITS, due to an issue=
 with
+the redistributor assignment.
+
+On Arm64 there can be problems with FFA if secure FW supports the notifica=
tion
+ABI, and with TEE, as both use non-static IRQ actions.
+
+Configuration
+-------------
+
+The presence of the feature is controlled by CONFIG_CPU_ONLINE_OFFLINE opt=
ion.
+It is enabled by default on x86 architecture. On Arm64, the option is disa=
bled
+by default and marked as EXPERT. xen-hptool userspace tool is built
+unconditionally.
+
+Usage
+-----
+
+Disable core:
+
+$ xen-hptool cpu-offline 2
+Prepare to offline CPU 2
+(XEN) Removing cpu 2 from runqueue 0
+CPU 2 offlined successfully
+
+Enable core:
+
+$ xen-hptool cpu-online 2
+Prepare to online CPU 2
+(XEN) Bringing up CPU2
+(XEN) GICv3: CPU2: Found redistributor in region 0 @00000a004005c000
+(XEN) CPU2: Guest atomics will try 1 times before pausing the domain
+(XEN) CPU 2 booted.
+(XEN) Adding cpu 2 to runqueue 0
+CPU 2 onlined successfully
+
+Disabling a core with pinned vCPUs:
+
+$ xl vcpu-pin 0 3 3 3
+$ xl vcpu-pin 0 2 3 3
+$ xl vcpu-pin 0 1 3 3
+$ xl vcpu-pin 0 0 3 3
+$ xen-hptool cpu-offline 3
+Prepare to offline CPU 3
+(XEN) Breaking affinity for d0v0
+(XEN) Breaking affinity for d0v1
+(XEN) Breaking affinity for d0v2
+(XEN) Breaking affinity for d0v3
+(XEN) Removing cpu 3 from runqueue 0
+CPU 3 offlined successfully
+
+Testing
+-------
+
+The CPU hotplug feature has been tested on both x86 and Arm64 QEMU setups =
and on
+R-Car Gen5 (Arm64) hardware.
+
+The tests included:
+- Offlining and onlining cores with no pinned vCPUs
+- Offlining cores with pinned vCPUs
+- Offlining cores with Xen-bound interrupts
+- Offlining all cores except the boot core
+- Offlining the boot core (expected to fail)
+- Enabling and disabling SMT threads (x86 only)
+- Offlining cores to which guests with passthrough devices are pinned
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:49:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:49:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393746.1632576 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFVq-0002ca-Fd; Tue, 18 Aug 2026 08:49:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393746.1632576; Tue, 18 Aug 2026 08:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFVq-0002cR-Ch; Tue, 18 Aug 2026 08:49:38 +0000
Received: by outflank-mailman (input) for mailman id 1393746;
 Tue, 18 Aug 2026 08:49:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwFVo-0002bn-LT
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:49:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFVo-005Wni-23
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:49:36 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841c98-2eae-0a2a0a5409dd-0a2a450799f8-24
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:49:36 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a841c9f-b4ea-0a2a45070019-d155802cccc0-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:49:35 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-4955aa106b1so39203125e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 01:49:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b51asm10324466f8f.11.2026.08.18.01.49.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 01:49:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787042975; x=1787647775; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=OX8HwlWMKmzVF2iaRGwJTTGCJjMKbDAbMdfQl49dMqw=;
        b=L/p9gfWBPb9DLL1fDCT+Rfl6/GN1sUSEEfGWupiCeiIFbn68dtMxTpHX11c0+rv/iZ
         nJnmWJOCl8q630dQc4ex4beQWyVAgjQSOmIat3MCZUb4q/XIfJf/T+8PkiSFInCkOwgN
         3ZJQZXVvJVG86h7KY8ue3z1xCdszcTqGgn4cej5MjYYWPWjNi1exroCXzdXamWqUFR7T
         cC5T5SZbeTtdwxOp8hSesGeBnG+vGVRC7eTChPIMaTn91p763BozmPSB2oq5cwgIuN55
         VE1lFqYhdfAcww8JOEpk/+Oniax+W8/TNDqxxwirvgcvbJ/ATElZPieNxVXnNKZZZaSt
         yURQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787042975; x=1787647775;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=OX8HwlWMKmzVF2iaRGwJTTGCJjMKbDAbMdfQl49dMqw=;
        b=AIlT6BkOqiH++Zsu9VL4YPc2mddAtxoMk2/+Sz6EOu9QwmZezasJMXeXU0zd7e18bV
         QVyWvGodjnJKyIuHgwxAPEaQXyxx/eUd2MWZ9TkrOj9ea6A+0lXQ7IyHBn2TTBOkcqUW
         uBa2NUY3tvDKWYLB08pyGmczpMwF6tEvexMIAcxxOxuUpI5a+IejCkTErT3W5yikft+9
         E/HAElRwK9Hk+WXr6BKoG5XF6VWmWAEJLxunmNNKv1agMy6qw6HKYli1boxbhydHC6IB
         Si9uS1Qy5da7tWydvtVnC2FRGuL9HcdprHyOiICZW+6w35uGuZG6PLq5C2itTa8+vEXQ
         pZwQ==
X-Forwarded-Encrypted: i=1; AHgh+RpAkUagtwZYrumoN1at5PJ60kTtTsHqdvJDLbGk6SQnht+YZ/aHF7QNdXF0gUv51H10DbKhbpZ6Yzk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHAgQr53mR0Kh+HSP0oTsoi2rbHRhNF75Xl7yaLwhzHDJBuzXf
	oAQoZwxmN7XxNGcoki/1seA0AvS5zN+Os9KeearRdYnph98b9kgOiddHr5/ZwUB/kQ==
X-Gm-Gg: AR+sD12QQSgtVXgMijK0pem+auiSbQpWK9myT6tz3Lk2vN1fRcNatrpsOCTwpXmmO4U
	Qj/VQW3llc1zaw6KRr/3nbQyZAQdCGQwggall0t+sa5r9YrUdq9zV9DJNF/2wdhJM8KdDOBZhkX
	BR91nKVdRXUcOLdlNeQoLi55YEt2loKwXvubpULsgOBSzXdov5yoLwP+nTW0oo4Zgz98ttH1X9b
	dqC6ZHjHoqk9l9IbnXZN/kI2EB6yAWyf7ElK6D2YgvJlYFteRxh7oPmIDeYktXyKIl5IjdH2NGh
	8hgwaiF3i12plXElgQNrTQQYY4onJlOygW8rWK9oiMJfnKZqHBfy3tekbInYEXFVhqyW5nRZ01V
	p4Kf/h3A9M4Y55bYdPuZnN4A2n/zyR6bOXD2LgQYeUGS2jXk5UJwCrz7WKWeuPev2r5PDtlBCNU
	TjIZ12DeZCvFAicIf8CNmpNRcYXu5KSJ+2NXoFGgGI+ZB3G/4Xt17F8MNZlrmzH48vg63qCcX/k
	olkTzfFgEzmZ6F3BPoiRCwDrl9fj91RK3DBMyYQDT9itUeRSE30RD2y+EppAlM=
X-Received: by 2002:a05:600c:638e:b0:499:900c:9c68 with SMTP id 5b1f17b1804b1-49994db0768mr320849595e9.6.1787042975447;
        Tue, 18 Aug 2026 01:49:35 -0700 (PDT)
Message-ID: <c2cc1049-3b92-4a72-bbf9-c49b2c6ff280@suse.com>
Date: Tue, 18 Aug 2026 10:49:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 0/2] add keyhandler to show Xen command line
To: dmukhin@ford.com
Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org,
 michal.orzel@amd.com, roger@xenproject.org, sstabellini@kernel.org,
 xen-devel@lists.xenproject.org
References: <20260814010206.1321724-1-dmukhin@ford.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260814010206.1321724-1-dmukhin@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787042975-A5EC6AE4-318628B0/0/0
X-purgate-type: clean
X-purgate-size: 609

On 14.08.2026 03:02, dmukhin@ford.com wrote:
> Mini-series to add new keyhander '?' for showing system information,
> including command line and version info.
> 
> v5: https://lore.kernel.org/xen-devel/20260813035139.915536-2-dmukhin@ford.com/
> CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2758940285
> 
> Denis Mukhin (2):
>   xen/common: add keyhandler to show Xen command line
>   xen/common: move version printout under '?' keyhandler

I would have wished them to be the other way around (as was requested), but well:
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 08:50:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 08:50:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393759.1632586 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFWv-0004E5-Od; Tue, 18 Aug 2026 08:50:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393759.1632586; Tue, 18 Aug 2026 08:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFWv-0004Dy-L6; Tue, 18 Aug 2026 08:50:45 +0000
Received: by outflank-mailman (input) for mailman id 1393759;
 Tue, 18 Aug 2026 08:50:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wwFWt-0004DZ-Rc
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 08:50:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFWt-00EUqE-3B
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:50:43 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a841cd6-8faa-0a2a0a5109dd-0a2a450c95c0-16
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:50:42 +0200
Received: from [52.101.125.95]
 (helo=TYVP286CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a841cdf-f479-0a2a450c0019-34657d5f78b8-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 10:50:41 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by OS9P286MB6268.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:40c::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.16; Tue, 18 Aug
 2026 08:50:37 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0315.016; Tue, 18 Aug 2026
 08:50:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=sg7SzwAbZZCghqs3xmmWczjcTetVG3GT4HJNO2g2N0IcmuowXRQvihRBW1CT496uw60J4DPy7JLHaUKDP9SWWCaoeY0VFZzxv8Jl0FDrC5dwliO/fALy2taMgOf6PB/wqZC3AhrP5rOQyGkZKGkuDkt1aZHYrVFQLwB2zkw5L6t7GUiWo+/JkatFtaEHnRn3dpNVkctYtZTVSJ1A+jHdnwLmCPhBsyaZt/ziPbmNUALxoOlKvW5I40x2cOsqc0BfTNRuF7lOrSGK0Csqc43vWe5rp/h/bMqjP8K8ffHWjT2Z1F+M5zyUTwaA8/h8XkuC8tpkRiiIohqsytRHMm1/9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VbvT8x9zoq0rkWeJWBifYWg2YRUo1eaIi1gYrNArckQ=;
 b=E8KSPIwr4tufivnfkR0K0Wot2BKdcqpuIlB+qQzd8lDcAukl0LHnwTlIVCGE52iQzyZtxINi13pAe/QZFKNxYgng1HrszPxzWF1EQO3T5bZn1xTbISt05r0OIRFc7qjlelI6GrK+z7ChqANpNqdx7eqx/KYmWkrf1tGm8SR/qr6wYuNYH6ZsrsQYvNDPf9ktW0q8Vn6rp3k1eAi2UDbtEBeIeNGpqnL9dtm9P64eWp5crsk0GWttmxEjGiYuh5VZjs0VSKFbEe9KytwXOBWVEWWAjxh1aM5dIdupdz+2ldzNFeByY+tlxLCNGaLLV8jUPtgIjCUwgVc58Ff68fks4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=VbvT8x9zoq0rkWeJWBifYWg2YRUo1eaIi1gYrNArckQ=;
 b=tO3gnQHVpq6XFg14/s4FtjmU1FFpJL2r3GjgnIhLDVBzOSihvrj2VbpqWBlacUEkzooo+KY3R6tDMM0IT4L7k7vQ3u2+pe83mLzRKog8PFoTuUPSkqRlicN6leafFnGX6QFekJCQHkNs1rZeq5Y/Xjsfd3CIPSq1l18jB774FJw=
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: "Orzel, Michal" <michal.orzel@amd.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
Subject: RE: [PATCH v2] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
Thread-Topic: [PATCH v2] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
Thread-Index: AQHdKtQB8xBHNNKUi0aqLwvXe0fRLbah1oEAgAGbhOA=
Date: Tue, 18 Aug 2026 08:50:36 +0000
Message-ID:
 <OS9P286MB722234CE96BB22DD89AC65B082A62@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
References: <20260813032938.3946-1-taka@valinux.co.jp>
 <37b2d119-7ff9-4862-9bcd-acb0b7ff4c9d@amd.com>
In-Reply-To: <37b2d119-7ff9-4862-9bcd-acb0b7ff4c9d@amd.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OS9P286MB7222:EE_|OS9P286MB6268:EE_
x-ms-office365-filtering-correlation-id: 116cf1e9-8a1d-42b3-1e65-08defd05c5d2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|6133799003|38070700021|22082099003|18002099003|10067099003|4143699003|56012099006;
x-microsoft-antispam-message-info:
 iRJ32zHvGfM5UEUb7hvfw8UXY/spM9Rk+4HNCujcADBICWdaFYoYyOeh6ztlWXNSrI18+p8l2wHNu0fVqjG+eJcU1OxIhF73U/A4+dYaaCZMTuRvNC69Gw8YLJ0rQAcB4i4TLtXVoCUAJU7DeqBEnHJ/ATzZk72YTY9H/V+jwSCMOZ7bWnXLrJT25nTflbD5MhusDAt7GLe8XLP5JubQUCIGI5z2uMNftL98Sos0NqE47/NH5wagAcYV4O0AgzswjMhpX1niNa6PIHGulBonBtSojTNUYLFHx5YFYQ2JUki3YV7Zku/FS2+3UMfzgt0hZs4o8UQYrtVsZtNOo6LbQYyuwbfZ9Uw69wBrN9Et8ZbYQOaX+ggzBaDDupbb/0NS/I/GnGsrB6R8NSrfzRAwqYQI9zI0UqlFoJ9SMpQaIpnOnVLqTf/gmKCn+OfW+Idutc7vgD7UIpHvg/YIz1+xyXahuCl7l6fnJQO5H4uYHELemRLw3K0onWdhIm/KonaRCk1ZY8LqweZEk4QVE9gbK7zthW/CGFf+1E5VvAL8N5wFO9Jgwzfw8y8fGTr3jWEAjqXfCLlOKFCfTKJNHIHcDkZX5t3XIjAxuI8KvFQXpBEUD8s/FoL7v1a9lIg10CH9V/D+LzPl4kmMAxT08AyvImkeqbSmVKkRsiUYZFaZAUjmhCl3cfzUKug2v0jslRJ6yO8qnkt3Eg4r7lz8oJxRuskZaRkkJkQIgWQWBXTOsog=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(6133799003)(38070700021)(22082099003)(18002099003)(10067099003)(4143699003)(56012099006);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?T1dPU21QMHlWOGhmZEdFM2hSN0Y3VnN1ZHFhVjM5NmRpVmo2TWVvK1kzcnU5?=
 =?utf-8?B?RjVNQnlKSGpwbWRYRmpTcUZLS0NacE1GR0YzMkVVcnErSlJTZEJuTVZMT29K?=
 =?utf-8?B?NHV4Y3lrWXdQbzVHeEhNMkZqUHhCTGhQUUhpU2RRSmE0Q2pkZ3l4cSs3WnFk?=
 =?utf-8?B?aUY3MnZrZDlOVkM0bC9MVHJlK2UwTnpkTVNQdHl5REZPWXA3ZEM0M2RoL3ls?=
 =?utf-8?B?QXlraktHalBHdTJDOWJSOTVnczJ5anFubkV4YmwrVURHUkp3dy91S3hUdTQ5?=
 =?utf-8?B?U3pjazZTNlh1bTI5VzAzVDQ4Yk9jZkhkTEsrY0FEOVdPUHBjdDhwQ3cvM3M1?=
 =?utf-8?B?QkRibEJlTVdNSnR6ZkNZUHArK3prMXhlNVJBeENrOEZPSEtFbWtBZVh6VVZG?=
 =?utf-8?B?UUNCd0Rra2VwSVVVdzVURmw0TEcrRVU1dElwZ3IzWEdVSnhLVDgvYmtaK2tj?=
 =?utf-8?B?VEV6cnQwSDI3ZmR2Ukp0RHlKQzVXamV3Q2FISWNhV25uTndOMTh4clkxYzcx?=
 =?utf-8?B?RkN3eWZtdHZJcGt2SHh0ZTJjdlNBbUUxeFMrNmlZTzQ2NUlJTDNuWTVTUFVk?=
 =?utf-8?B?SE9kWWFDa3R5TUVLeno1NUk5a1ZqQjRxRHlGMW5YREZXekFPT1NFamo3TDBX?=
 =?utf-8?B?K2ZSRmJLSmtiZFJpZzhrdHdMUDhmM1RtcGZEYUlpc2tFMmhvSmUxdHNncWZz?=
 =?utf-8?B?WGpSM01OdERQUVVpN0dTd2h4K056NGhETWVOT09UcUM3anE5aXBkZDVpRTVM?=
 =?utf-8?B?NjhockZXaE01aFF1WEJSZEpmZUgvSVBIVjdnWER6bmd3YnhCUTJOVzVpbCt0?=
 =?utf-8?B?TlB6eklPVFNwWWtpVlJiK1ZGK3NlWDVZOU9GMnNaTzZPdG1pZmRFR21XajEx?=
 =?utf-8?B?Mkp6WGMwNWNGVVJvdW44V1JRQU5sQnhVWThQOWNZQTZCQzREY3RVYzBaOENy?=
 =?utf-8?B?aGsyNm02T3JpOFZqZHNldUVQWkR5TWVPZHFFU1FEMUZzZ2VaOHZOTUhjZTBT?=
 =?utf-8?B?TDNtWnpIL3lSK0ZIbWJqYXZVNEZkVThtWitPbE9VV1ltSXVxazVCRFVrNWxY?=
 =?utf-8?B?UE9mNDh4ZWVmTVdTMGNTd2UvUnNSMHZ6OFduYm9BaE9TcVhLN0dwQ2VWYkFO?=
 =?utf-8?B?S3ZSNG5OMlJ3REFBS21GSkFmR0VuNldRRVhvRlArT3k4Q0kvWVlTU2tQbHNP?=
 =?utf-8?B?Z2F6ZUp3Tk5jZHNVK0pTL2lHY2UxcVcwdDc2TXJvWnMxRzhia0JFTHpwK2Vy?=
 =?utf-8?B?bUU5Y1hMeDZqSHl4STdnYkVmRHR1aFlmNjVXM1Z2NFU4U2tEVmkwK1NLZUp6?=
 =?utf-8?B?cDB6a29kRDlLS1EwekZZWVREUzY3NGI0c1hXcU9lMmF3SW1leUIwSWgwNGxW?=
 =?utf-8?B?NTVuQ29jazd1UnMxZ3BlcWRsSldWVEhVdzFKVmlIQThWbjNjOE9adDA4L0Zl?=
 =?utf-8?B?MTdJcnRBWFlJL3JJem52SFBQUFRQekYxYmVyWWQ2emVDWkRTZVlHSVF5Ni9o?=
 =?utf-8?B?WkJSMjJpdFh4TFJNb0VYRGRxL1F3Wk1qRUY2SytiWm5vZTVJTjlQR05kNVN5?=
 =?utf-8?B?c0YwaGFuMGZvQi81bFM4WE1LSDdYeE14Uzl4UGxOWVZ5cWNVVHZFZ2VsY0Zk?=
 =?utf-8?B?L1h5ZGNwcVUydU5Vb3k4YnNWNDVnZTBkOHpkYVVtQW51eWMrZU0xQ3lZNCtv?=
 =?utf-8?B?Y2RLYkpuZTNjeS93RVhCZmlQSVBxRS9tWUtkeHlZaEgwR2N4MEMvYnJxT3dk?=
 =?utf-8?B?TTFrc3FQQVZZTisyeExtK0VFQ1BDWVZTTW1oS0hrd3E1WXBpZlh3ZmM4R0E2?=
 =?utf-8?B?YVpwYXVabWpLeitlUFpsZy9ON1U2WDdlMGExVU4wRkJrNzJHKzdjTysyNlRF?=
 =?utf-8?B?OGNRNkJZaStOcEh6REhlQ3RNVS9BMU5wVCt1bHptcFFaTFBIRlJnWWhUcXR4?=
 =?utf-8?B?OXBZQzVFR2NHZkYzOTROWVJaVTVabkM2NE03U0RVMnRBQ0h2dVhvakpWU0FG?=
 =?utf-8?B?alIrcGw0WHFaWlVJTkpxWmxhUlhCa1RLNmNtNFJJUkYrcW5QcVZrODB3SFgz?=
 =?utf-8?B?V3R3MHAzenNNQ2JGVm44aHh0Zy8rK3JIS2Rkcm9IdFMzSWllTEp0Y0VlRkJu?=
 =?utf-8?B?Z3dETjl4MHUwUlpGb04zQ1l1NVJsNHVHalJHT0JaNDlUUjZEekxMRFM0M1l0?=
 =?utf-8?B?Vkd5aVVsbUlKTkZ0TmhpOTZ6Z1BVamVhV2ZkMzlDR29UcytFTXRwRERjdk1n?=
 =?utf-8?B?NXNUbnJjSnU2UVphdVlBd2wzZUN6VGJRNWQ2dDByODBKZTBOZmIyaVdrTjB1?=
 =?utf-8?Q?DSbxVSCyzmDvU4aYM0?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 116cf1e9-8a1d-42b3-1e65-08defd05c5d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2026 08:50:36.8700
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6pthHj8s9IGnh16eXcD1iORHoTO7k8gdyGwl/3stwi5mumjjC/3si64VnV9vT1pQVKB4+dnsrZIec/7uLUiHAg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB6268
X-purgate-ID: tlsNG-d25034/1787043042-00CCBA5B-0EFB83F9/0/0
X-purgate-type: clean
X-purgate-size: 7566

SGVsbG8sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KDQo+ID4gT24gQVJNdjguNC1BIGFu
ZCBuZXdlciBwbGF0Zm9ybXMsIGJvb3RpbmcgRG9tMCBMaW51eCB3aXRoIEFDUEkgZW5hYmxlZA0K
PiA+IGNhdXNlcyB0aGUgZG9tYWluIHRvIHByb2JlIGFkdmFuY2VkIFBNVSBmZWF0dXJlIGJhc2Vk
IG9uIHN5c3RlbSBJRA0KPiA+IHJlZ2lzdGVyIElEX0FBNjRERlIwX0VMMS5EdXJpbmcgdGhpcyBw
cm9iZSwgTGludXggYWNjZXNzZXMgUE1NSVJfRUwxLA0KPiA+IHdoaWNoIGNhdXNlcyB1bmhhbmRs
ZWQgcmVnaXN0ZXIgdHJhcHMgYW5kIGNyYXNoZXMgdGhlIGRvbWFpbi4NCj4gPg0KPiA+IFRvIGFk
ZHJlc3MgdGhpcyBpc3N1ZSwgSSBpbXBsZW1lbnQgdGhlIGZvbGxvd2luZzoNCj4gUGxlYXNlIHVz
ZSB0aGUgaW1wZXJhdGl2ZSBtb29kDQoNCk9rYXkuDQoNCj4gPiAtIEhpZGUgUE1VIHJlZ2lzdGVy
cyBmcm9tIGEgZ3Vlc3QgZG9tYWluIHdoZW4gaXRzIHZQTVUgZmVhdHVyZSBpcw0KPiA+ICAgZGlz
YWJsZWQuDQo+ID4gLSBQcm9hY3RpdmVseSBtYWtlIFNQRSwgVFJCRSwgQlJCRSwgYW5kIFRyYWNl
IEV4dGVuc2lvbnMgaW5hY2Nlc3NpYmxlDQo+ID4gICB0byBndWVzdCBkb21haW5zLCBhcyB0aGV5
IGNvdWxkIHBvdGVudGlhbGx5IGNhdXNlIHNpbWlsYXIgaXNzdWVzLg0KPiA+IC0gQWRkIGVtdWxh
dGlvbiBmb3IgUE1NSVJfRUwxIHJlZ2lzdGVyIGFjY2Vzc2VzIHBlcmZvcm1lZCBieSBhIGd1ZXN0
DQo+ID4gICBkb21haW4gd2hlbiB2UE1VIGlzIGVuYWJsZWQuIEhvd2V2ZXIsIHNpbWlsYXIgdG8g
cmVhZHMgZnJvbSBvdGhlcg0KPiBXaGVuIHZQTVUgaXMgZW5hYmxlZCwgdGhlcmUgaXMgbm8gdHJh
cC9lbXVsYXRpb24NCg0KVW5kZXJzdG9vZC4NCg0KPiA+ICAgUE1VIHJlZ2lzdGVycywgdGhlIHJl
YWQgdmFsdWUgcmV0dXJucyB6ZXJvIChub3RlIHRoYXQgdGhpcyBpcyBhDQo+ID4gICB0ZW1wb3Jh
cnkgaW1wbGVtZW50YXRpb24pLg0KPiA+IC0gRW11bGF0aW9uIGZvciBQTVNTIChQTVUgU25hcHNo
b3QpIHJlZ2lzdGVyIGFjY2Vzc2VzIGlzIG5vdCB5ZXQNCj4gPiAgIGltcGxlbWVudGVkLCBiZWNh
dXNlIFBNU1Mgc3VwcG9ydCBpcyBub3QgYXZhaWxhYmxlIGluDQo+ID4gICBxZW11LXN5c3RlbS1h
YXJjaDY0IGFuZCBjb3VsZCBub3QgYmUgdmVyaWZpZWQuDQo+ID4NCj4gPiBGaXhlczogMDdiOWFj
ZWExMTZlICJ4ZW4vYXJtOiBBZGQgaGFuZGxlciBmb3IgSUQgcmVnaXN0ZXJzIG9uIGFybTY0Ig0K
PiA+IEZpeGVzOiAzNjY5YTFjYjk1OTggInhlbi9hcm06IGNyZWF0ZSBhIGNwdWluZm8gc3RydWN0
dXJlIGZvciBndWVzdCINCj4gRml4ZXMgY29tbWl0IHRpdGxlIG5lZWRzIHRvIGJlIGluIGJyYWNr
ZXRzICgpDQoNCk9rYXkuDQoNCj4gPiAtLS0gYS94ZW4vYXJjaC9hcm0vYXJtNjQvdnN5c3JlZy5j
DQo+ID4gKysrIGIveGVuL2FyY2gvYXJtL2FybTY0L3ZzeXNyZWcuYw0KPiA+IEBAIC0yMjksNiAr
MjI5LDcgQEAgdm9pZCBkb19zeXNyZWcoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MsDQo+ID4g
ICAgICAgKi8NCj4gPiAgICAgIGNhc2UgSFNSX1NZU1JFR19QTUlOVEVOU0VUX0VMMToNCj4gPiAg
ICAgIGNhc2UgSFNSX1NZU1JFR19QTUlOVEVOQ0xSX0VMMToNCj4gPiArICAgIGNhc2UgSFNSX1NZ
U1JFR19QTU1JUl9FTDE6DQo+IFdoYXQgYWJvdXQgQUFyY2gzMiBQTU1JUj8NCg0KT2theSwgSSB3
aWxsIGFkZCBhIHRyYXAgaGFuZGxlciBlbnRyeSBmb3IgQUFyY2gzMiBQTU1JUiByZWdpc3RlciBh
Y2Nlc3Nlcy4NCg0KPiA+IEBAIC0zMDYsNyArMzA3LDYgQEAgdm9pZCBkb19zeXNyZWcoc3RydWN0
IGNwdV91c2VyX3JlZ3MgKnJlZ3MsDQo+ID4gICAgICBHRU5FUkFURV9USUQzX0lORk8oSURfUEZS
MF9FTDEsIHBmcjMyLCAwKQ0KPiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX1BGUjFfRUwx
LCBwZnIzMiwgMSkNCj4gPiAgICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9QRlIyX0VMMSwgcGZy
MzIsIDIpDQo+ID4gLSAgICBHRU5FUkFURV9USUQzX0lORk8oSURfREZSMF9FTDEsIGRiZzMyLCAw
KQ0KPiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX0RGUjFfRUwxLCBkYmczMiwgMSkNCj4g
PiAgICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9BRlIwX0VMMSwgYXV4MzIsIDApDQo+ID4gICAg
ICBHRU5FUkFURV9USUQzX0lORk8oSURfTU1GUjBfRUwxLCBtbTMyLCAwKQ0KPiA+IEBAIC0zMjYs
NiArMzI2LDE4IEBAIHZvaWQgZG9fc3lzcmVnKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLA0K
PiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKE1WRlIxX0VMMSwgbXZmciwgMSkNCj4gPiAgICAg
IEdFTkVSQVRFX1RJRDNfSU5GTyhNVkZSMl9FTDEsIG12ZnIsIDIpDQo+ID4NCj4gPiArICAgIGNh
c2UgSFNSX1NZU1JFR19JRF9ERlIwX0VMMToNCj4gWW91IG9ubHkgY292ZXIgQUFyY2g2NC4gV2hh
dCBhYm91dCBBQXJjaDMyIERGUjA/DQoNCk9rYXksIEkgd2lsbCBhbHNvIGFkZCBhIHRyYXAgaGFu
ZGxlciBlbnRyeSBmb3IgaXQuDQogDQo+ID4gKyAgICB7DQo+ID4gKyAgICAgICAgc3RydWN0IGRv
bWFpbiAqZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4gVXNlIHYtPmRvbWFpbiBpbnN0ZWFkIGxpa2Ug
dGhlIHN1cnJvdW5kaW5nIGNvZGUNCg0KT2theS4NCiANCj4gPiArICAgICAgICB1bmlvbiBjcHVp
bmZvX2RiZzMyIGluZm9fZGJnMzIgPSBkb21haW5fY3B1aW5mby5kYmczMjsNCj4gPiArDQo+ID4g
KyAgICAgICAgaWYgKCAhKGQtPm9wdGlvbnMgJiBYRU5fRE9NQ1RMX0NERl92cG11KSApDQo+ID4g
KyAgICAgICAgICAgIGluZm9fZGJnMzIucGVyZm1vbiA9IDA7DQo+ID4gKw0KPiA+ICsgICAgICAg
IHJldHVybiBoYW5kbGVfcm9fcmVhZF92YWwocmVncywgcmVnaWR4LCBoc3Iuc3lzcmVnLnJlYWQs
IGhzciwgMSwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm9fZGJn
MzIuYml0c1swXSk7DQo+ID4gKyAgICB9DQo+ID4gKw0KPiA+ICAgICAgY2FzZSBIU1JfU1lTUkVH
X0lEX0FBNjRQRlIwX0VMMToNCj4gPiAgICAgIHsNCj4gPiAgICAgICAgICByZWdpc3Rlcl90IGd1
ZXN0X3JlZ192YWx1ZSA9IGRvbWFpbl9jcHVpbmZvLnBmcjY0LmJpdHNbMF07DQo+ID4gQEAgLTM0
OCw3ICszNjAsNiBAQCB2b2lkIGRvX3N5c3JlZyhzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywN
Cj4gPiAgICAgIH0NCj4gPg0KPiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX0FBNjRQRlIx
X0VMMSwgcGZyNjQsIDEpDQo+ID4gLSAgICBHRU5FUkFURV9USUQzX0lORk8oSURfQUE2NERGUjBf
RUwxLCBkYmc2NCwgMCkNCj4gPiAgICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9BQTY0REZSMV9F
TDEsIGRiZzY0LCAxKQ0KPiBXaGF0IGFib3V0IERGUjEgZmllbGRzIGxpa2UgUE1JQ05UUj8gVGhl
eSBzdWZmZXIgZnJvbSB0aGUgc2FtZSBwcm9ibGVtLg0KDQpPa2F5LCBJIHdpbGwgZml4IGl0Lg0K
IA0KPiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX0FBNjRJU0FSMF9FTDEsIGlzYTY0LCAw
KQ0KPiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX0FBNjRJU0FSMV9FTDEsIGlzYTY0LCAx
KQ0KPiA+IEBAIC0zNTgsNiArMzY5LDIyIEBAIHZvaWQgZG9fc3lzcmVnKHN0cnVjdCBjcHVfdXNl
cl9yZWdzICpyZWdzLA0KPiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX0FBNjRBRlIwX0VM
MSwgYXV4NjQsIDApDQo+ID4gICAgICBHRU5FUkFURV9USUQzX0lORk8oSURfQUE2NEFGUjFfRUwx
LCBhdXg2NCwgMSkNCj4gPg0KPiA+ICsgICAgY2FzZSBIU1JfU1lTUkVHX0lEX0FBNjRERlIwX0VM
MToNCj4gUGxlYXNlIGFkaGVyZSB0byB0aGUgb3JkZXIgaW4gd2hpY2ggdGhlIGNhc2VzIHdlcmUg
b3JpZ2luYWxseSBwbGFjZWQNCg0KT2theS4NCg0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIHN0
cnVjdCBkb21haW4gKmQgPSBjdXJyZW50LT5kb21haW47DQo+ID4gKyAgICAgICAgdW5pb24gY3B1
aW5mb19kYmc2NCBpbmZvX2RiZzY0ID0gZG9tYWluX2NwdWluZm8uZGJnNjQ7DQo+ID4gKw0KPiA+
ICsgICAgICAgIGlmICggIShkLT5vcHRpb25zICYgWEVOX0RPTUNUTF9DREZfdnBtdSkgKQ0KPiBU
byBhdm9pZCBkdXBsaWNhdGlvbiwgcGxlYXNlIGludHJvZHVjZSBpc192cG11X2RvbWFpbg0KDQpP
a2F5LCBJIHdpbGwuDQoNCj4gPiArICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgIGluZm9fZGJn
NjQucG11X3ZlciA9IDA7DQo+ID4gKyAgICAgICAgICAgIGluZm9fZGJnNjQubXRwbXUgPSAwOw0K
PiA+ICsgICAgICAgICAgICBpbmZvX2RiZzY0LnBtc3MgPSAwOw0KPiA+ICsgICAgICAgIH0NCj4g
PiArDQo+ID4gKyAgICAgICAgcmV0dXJuIGhhbmRsZV9yb19yZWFkX3ZhbChyZWdzLCByZWdpZHgs
IGhzci5zeXNyZWcucmVhZCwgaHNyLCAxLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaW5mb19kYmc2NC5iaXRzWzBdKTsNCj4gPiArICAgIH0NCj4gPiArDQoNCj4gPiBA
QCAtMjE2LDE2ICsyMTYsMTggQEAgc3RydWN0IGNwdWluZm9fYXJtIHsNCj4gPiAgICAgICAgICAg
ICAgdW5zaWduZWQgbG9uZyB0cmFjZV92ZXI6NDsNCj4gPiAgICAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBwbXVfdmVyOjQ7DQo+ID4gICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgYnJwczo0Ow0K
PiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVzMDo0Ow0KPiA+ICsgICAgICAgICAg
ICB1bnNpZ25lZCBsb25nIHBtc3M6NDsNCj4gPiAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyB3
cnBzOjQ7DQo+ID4gLSAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgX19yZXMxOjQ7DQo+ID4gKyAg
ICAgICAgICAgIHVuc2lnbmVkIGxvbmcgc2ViZXA6NDsNCj4gV2hlcmUgZGlkIHlvdSB0YWtlIHRo
aXMgZmllbGQgZnJvbT8gSSBjYW4ndCBzZWUgaXQgaW4gdGhlIGxhdGVzdCBBcm0gQVJNOg0KPiBo
dHRwczovL3N1cHBvcnQuYXJtLmNvbS9kb2N1bWVudGF0aW9uL2RkaTA0ODcvbWMvLVBhcnQtRC1U
aGUtQUFyY2g2NA0KPiAtU3lzdGVtLUxldmVsLUFyY2hpdGVjdHVyZS8tQ2hhcHRlci1EMjQtQUFy
Y2g2NC1TeXN0ZW0tUmVnaXN0ZXItRGVzY3JpDQo+IHB0aW9ucy8tRDI0LTItR2VuZXJhbC1zeXN0
ZW0tY29udHJvbC1yZWdpc3RlcnMvLUQyNC0yLTc5LUlELUFBNjRERlIwLQ0KPiBFTDEtLUFBcmNo
NjQtRGVidWctRmVhdHVyZS1SZWdpc3Rlci0wP2xhbmc9ZW4NCg0KSW4gYSBzbGlnaHRseSBvbGRl
ciBBcmNoaXRlY3R1cmUgUmVmZXJlbmNlIE1hbnVhbCwgdGhlcmUgd2FzIGEgU0VCRVAgZmllbGQN
CmluIElEX0FBNjRERlIwX0VMMS4gSGFzIGl0IGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBzcGVjPw0K
aHR0cHM6Ly9zdXBwb3J0LmFybS5jb20vZG9jdW1lbnRhdGlvbi8xMTExODAvMjAyNS0wOV9BU0wx
L0FBcmNoNjQtUmVnaXN0ZXJzL0lELUFBNjRERlIwLUVMMS0tQUFyY2g2NC1EZWJ1Zy1GZWF0dXJl
LVJlZ2lzdGVyLTA/bGFuZz1lbg0KDQpUaGFuayB5b3UsDQpIaXJva2F6dSBUYWthaGFzaGkuDQo=


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:07:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:07:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393776.1632594 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFnF-0006hW-30; Tue, 18 Aug 2026 09:07:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393776.1632594; Tue, 18 Aug 2026 09:07:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFnE-0006hP-VZ; Tue, 18 Aug 2026 09:07:36 +0000
Received: by outflank-mailman (input) for mailman id 1393776;
 Tue, 18 Aug 2026 09:07:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwFnD-0006hJ-LE
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:07:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFnD-006C4g-1s
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:07:35 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8420c4-e002-0a2a0a5209dd-0a2a450192c2-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:07:34 +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 <jbeulich@suse.com>)
 id 6a8420d6-5984-0a2a45010019-d155802ff125-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:07:34 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so51219435e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 02:07:34 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49993d1b78asm161207275e9.3.2026.08.18.02.07.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 02:07:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787044054; x=1787648854; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=m5NMqaKEMHNMyIIFFQBJe81IxITT7YiCf9WRfA9vfQU=;
        b=QlX72C2xJMjnSTiVfNhJxPNlm9v+SZeNl4gAWjG22cWsQtIOc3NZW2oqLLQmu2030s
         J2TUfnEDigcgNUG4M4935yRFA+afk7L4crDC9CO9xwXBW4UBvPrWyYGJLHPvLRP7qULw
         e3IYQBJl9NHC2MgQPVIG9vS7Qp4murs212ccMe+1KZDrtxsWLcg8dLpk6oWk7BCB8+RZ
         KiXmidlPpql0ulWFWYNazYKB0MRUiqe1lBeMfXmfPqK3BYlYSSHtysKyud4KYbLzOQm4
         2WkqEE2asuK52TW9+py81RrBtCo97Lt5iuYx5PTTMSvSsj/X64pWlEGpScfHCkgOe6KO
         vgOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787044054; x=1787648854;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=m5NMqaKEMHNMyIIFFQBJe81IxITT7YiCf9WRfA9vfQU=;
        b=eTLCit3cxIpocGSQkgH4fTFCR4OY6a8jT7VR6GTE5BYVoNEUvMli6aebtczUIjzTIg
         7uY+E1Z7YWtU9WuIE+gMulzj1hI3cgNpDnTAOG88eViQPsjb07z/lI5F9i+bDC1L7ILJ
         K6GUtJ+MrQeY0o3gjUwNeNRamJMAforUVORsRsTtgm6tPUFXx9HiotLXakTs0d/l+s7w
         +Jr5Uaz3SI5WfDqGXNIeO7jDKMMOT9S4/Pt1CDZWilqZ/qT4rcerAXjfLjC75v0Lh9Ph
         FcGcyzzZWvIK97msYOO22sMX3xbi9svFUsrlt/zEL+dXGXG1JHZSHEnBrPZc7viliorU
         q70w==
X-Forwarded-Encrypted: i=1; AHgh+Rod/EbuiyZCYXX7Wxy5trUy5AmrVYC+Al2My+m1oPFqpTmYK6QT/Ik2Jqr/5+4Pxlsjy9WzWEpqmP4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhFQVhdpx9LKyVBPzh7jjxxWhoJQfFNzTexOkomicGGxPKXyhi
	EqCR/UwS5R1h1DRhGgXaf5Q+gr7baUoFjb25I0+SYA9ta6OkbbMFnxfH32QGwijjNA==
X-Gm-Gg: AR+sD13chaZx0/2x+uaKS/jGXywPsA+m6Bv3fxV7XwzyfX52tyrwl+OhGJ78ePghilA
	uau0NOyFQSeixDuSeeylRe+xf8iFuQy3Z68+e8faQ/b5c0m3W8Qx4tC+BFlJrWwI/tmYgT3Nkry
	qVIbxSORr4jyzjANVDKjvlOeDhD2mwiHdBLJOA7qUEqSGuU9NfzwFeT5hnYRgvdJzD2/I6I7GGf
	kgNNGdf70Qd+AxkTg1oGQBX2TY0rtGYdAYoxc2+95ad+3Lj6QNOi8Yb9KZCZfBHu76MHbc3odKD
	U1jzQ8ExDMpth3MI+DStQ/+sr1/kNOVfkh0w9k9VPJJ73OesLvXXpdIOUc+OG9u8QDy4Ly62LRd
	gYVFK6u51COF9HbzwZqpRGCLali/gxL5GDq/Z2LhjGjBdOQEGXhODL9l20hQgqPGTZR9MmdzH2i
	32lTTixFqQ9xuXz3vogKY+s3xWeS6Ux21m1LEAAWtSfELDCk3K+J1fVVBkU9t8fROF6IrU9ozNL
	2zQFeDCxLGkPB84y7FT5CzQy/1wSRGiWhLGY7sOWHW59aXHFeUwLCtpdHhBQysqnWBCIhktGZA=
X-Received: by 2002:a05:600c:c16d:b0:499:8ff5:8ecc with SMTP id 5b1f17b1804b1-4998ff590a6mr428321925e9.15.1787044054444;
        Tue, 18 Aug 2026 02:07:34 -0700 (PDT)
Message-ID: <4784dadc-9485-4a0c-8c93-928e27d21146@suse.com>
Date: Tue, 18 Aug 2026 11:07:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 4/6] arm/sysctl: Implement cpu hotplug ops
To: Mykyta Poturai <Mykyta_Poturai@epam.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Teddy Astie <teddy.astie@vates.tech>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cover.1787042017.git.mykyta_poturai@epam.com>
 <43447ba62f39a46ceeafca58a4212fb8c07497e1.1787042017.git.mykyta_poturai@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <43447ba62f39a46ceeafca58a4212fb8c07497e1.1787042017.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787044054-BCB45757-0B62A2A8/0/0
X-purgate-type: clean
X-purgate-size: 2964

On 18.08.2026 10:48, Mykyta Poturai wrote:
> SMT-disable enforcement check is moved into a separate
> architecture-specific function.
> 
> For now this operations only support Arm64. For proper Arm32 support,
> there needs to be a mechanism to free per-cpu page tables, allocated in
> init_domheap_mappings. Also, hotplug is not supported if ITS enabled,
> and partially supported FFA, or TEE is enabled, as they use non-static
> IRQ actions.
> 
> Remove ifdef guards for x86 in flask, as cpu hotplug is now
> supported on more architectures.
> 
> Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
> ---
> v8->v9:
> * simplify dependencies of config CPU_ONLINE_OFFLINE again

You must also have re-based over XSA-499. As non-trivial re-basing can go
wrong, I think at least in those cases it wants noting in the revlog.
(Personally I try to remember to always add the remark, even if the re-base
was the trivial resolution of e.g. fuzz.)

> @@ -104,6 +105,40 @@ void smp_call_function_interrupt(void)
>      irq_exit();
>  }
>  
> +#ifdef CONFIG_CPU_ONLINE_OFFLINE
> +long cf_check cpu_up_helper(void *data)
> +{
> +    unsigned int cpu = (unsigned long)data;
> +    int ret = cpu_up(cpu);
> +
> +    /* Have one more go on EBUSY. */
> +    if ( ret == -EBUSY )
> +        ret = cpu_up(cpu);
> +
> +    if ( !ret && !arch_cpu_can_stay_online(cpu) )

I'm sorry, I should have noticed this already before: This isn't "can", at least
on x86. It is a requirement in certain situations that CPUs be kept kind-of-
online. Since arch_cpu_must_stay_online() feels clumsy as a name, and since that
might also conflict with another arch perhaps really meaning "can", not "must",
maybe arch_cpu_keep_online()?

> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -475,6 +475,40 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
>              copyback = 1;
>          break;
>  
> +    case XEN_SYSCTL_cpu_hotplug:
> +    {
> +        unsigned int hp_op = op->u.cpu_hotplug.op;

This variable is used ...

> +        long (*fn)(void *data);
> +        void *hcpu = _p(op->u.cpu_hotplug.cpu);
> +
> +        ret = -EOPNOTSUPP;
> +        if ( !IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) )
> +            break;
> +
> +        switch ( hp_op )

... solely here. Is such a variable really warranted?

> +        {
> +        case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
> +            fn = cpu_up_helper;
> +            break;
> +
> +        case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
> +            fn = cpu_down_helper;
> +            break;
> +
> +        default:
> +            fn = NULL;
> +            break;
> +        }
> +
> +        if ( fn )
> +        {
> +            ret = continue_hypercall_on_cpu(0, fn, hcpu);

Same (maybe to slightly lesser degree) for "hcpu", used solely here.

For both variables, the situation is/was different in the original code.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:14:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:14:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393786.1632602 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFtX-0000dB-QO; Tue, 18 Aug 2026 09:14:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393786.1632602; Tue, 18 Aug 2026 09:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFtX-0000d4-NR; Tue, 18 Aug 2026 09:14:07 +0000
Received: by outflank-mailman (input) for mailman id 1393786;
 Tue, 18 Aug 2026 09:14:06 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwFtW-0000cy-CG
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:14:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFtV-00GLLd-Hl
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:14:05 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a84224f-2eae-0a2a0a5409dd-0a2a4503ab3e-46
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:14:05 +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 <oleksii.kurochko@gmail.com>)
 id 6a84225d-fae8-0a2a45030019-d155802add57-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:14:05 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49802c418b5so47178335e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 02:14:05 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783basm10776066f8f.30.2026.08.18.02.14.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 02:14:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787044445; x=1787649245; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=SNxttgFqZ62Mks/7jNp/0G7ERYuZ5YR2vKGntiN4L3g=;
        b=EerxsRaYOTIJhnR7kAqclycIqQmetxDNdIlr4BgDs5yJPS0a2fhE1Qusd7kNlgCaB7
         EcP0FAv8xSm9h0nKoUQ9xbERC3BQ04TZwrfn88F5OsjI3eB0p/FThKIvGckDBl7li86N
         lIMCvsnogMu7v1EXykscnrvHv5XHJ6vOxOkp13qamc+H//czuui8daMCbk2RhPrWvEfY
         Gm5k/4wbzzKMTSXxugOf0raTgbJnplADNkaytGVsNfNCAs1QnCTmgCpaG0L/BQ76x7re
         ED8aBGLJGXg7+LE0FxIiqTto+64WOZJxMchEgX2juQygx8328laXe7IBzWrmVoSFpOj9
         6Paw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787044445; x=1787649245;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=SNxttgFqZ62Mks/7jNp/0G7ERYuZ5YR2vKGntiN4L3g=;
        b=i210aSbwcuXFNmUxGfDgyJkB57HwZJSQZAOfMLTLL8c9w9WjTmfTshT5UmGdMhDzsi
         IVzTGtDXc9/1eCokPoWNQVBlxrrCWhgWGX/9epYJ+sUuqpp/NCnmBGPmIw6/6kKWg0/5
         /vutws+LyAend4RH+yDA7wuFa3YxdxawYsCaYn822nS/njbGvr5a4iJkbR6HTL+7VZ5i
         5goWH7rTS2WBmds2msP8dbHFJwNWwrDCSajmwfZmqyDegg+flXO0tWW25bn7e+Y2F/yZ
         LAqZxPoMjaOg9y6H7YvvBYPkvE0k03VLgWf/mj++nWNO1D4SzpiTL/mei1+aOE3Qn8Kc
         hqsA==
X-Forwarded-Encrypted: i=1; AHgh+RqDEN96K1u9AsyBUPn7Ib4G+2NK+3mUoKHSxXg8bET7Fi5+RowUmFc5UmMF+/o8quFw40Sbvhvo7JE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhOziQzatE/kg4XDE6kxVCzwPXmSP8ewtSQ8Vo7xzxySKmh2uN
	rKDSsnNrUthscf7TURei3xtWHY4PkuInDB3Z8dDkjWseNjFxYzUm9zU2
X-Gm-Gg: AR+sD12SzLg6gJlL5Vx10VWLXybkm5oHH3EXE6Pe5y4xrf4TtBqIZq7pEcx5u80xJ5h
	jBOeGgEdFHpTtutQBEoEP38IBFVgHupOAefQRAipVQcrvNb2yzLTUEsmn7fbkTUs0fQp3uEIBSk
	tD2f7T5dUQ+pBb/mbFMSu3V+QnxybcNG7/7ji8mkJP20atv2VYm1NCSh2UKboKkaizv7DdLf7mu
	E0LlIMKkrnkSFG+vWqgYfelLTkbi7CTwkLJOnEk0HDzql3WZ2ltORAs3++zyZXFsh/jtWZwXhqM
	5YGxT4YrUJ76iS6yC/AvvGxA0uM0+HmX7JSrYwQlxmsh7fgS0W16FJs3tA6F1dJn5kn36WzCdYR
	9sFOIdK7utdAtgIghlYasBP+5DY3WeElrpNw9slXtUlfwDl+kajkPlwhHzkwwlhXJ8jULUxyGwr
	fU0fb/HbCFFe+wWCMspAZvm8j+59Fj3VbHm3BUOh3BrsIA2ThgfBamN245Yl+NglkLFZf0fH5NT
	IuWh+WXNL1oh0jjOPy+nOnPLIOfZReqmi9DM26YTq0eR5CeCpBVWw==
X-Received: by 2002:a05:600c:8b6b:b0:499:8f9f:e9ee with SMTP id 5b1f17b1804b1-4998f9febbdmr426485635e9.7.1787044444570;
        Tue, 18 Aug 2026 02:14:04 -0700 (PDT)
Message-ID: <4a707c58-2225-477f-936e-9f99ae616c44@gmail.com>
Date: Tue, 18 Aug 2026 11:14:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
 <b8b794ec-c86a-4a82-9d3a-b3ffcaa802f3@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <b8b794ec-c86a-4a82-9d3a-b3ffcaa802f3@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787044445-6C2E04E9-364AC3A5/10/73395122804
X-purgate-type: spam
X-purgate-size: 7423



On 8/18/26 9:56 AM, Jan Beulich wrote:
> On 17.08.2026 13:33, Oleksii Kurochko wrote:
>> On 8/12/26 4:37 PM, Jan Beulich wrote:
>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>>>>        regs->sepc = ex_fixup(ex);
>>>>    }
>>>>    
>>>> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
>>>> +                                         unsigned int offset)
>>>> +{
>>>> +    /*
>>>> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>> +     * laid out at the start of struct cpu_user_regs in architectural
>>>> +     * order.
>>>> +     */
>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
>>>> +                 sizeof(unsigned long));
>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
>>>> +                 31 * sizeof(unsigned long));
>>>> +
>>>> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
>>>> +        return 0;
>>>
>>> And an offset not divisible by sizeof(unsigned long) is okay?
>>
>> No, it isn't okay. I will apply your comment ...
>>
>>>
>>> Returning 0 as error indicator also feels fragile.
>>
>> With what I suggested below returning could be just dropped.
>>
>>>
>>>> +    return *(unsigned long *)((unsigned long)regs + offset);
>>>> +}
>>>> +
>>>> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
>>>> +                                 struct cpu_user_regs *regs)
>>>> +{
>>>> +    struct trap_info *trap_info =
>>>> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));
>>>
>>> Related to the earlier comment: Simply pass just ex->data here, leaving the
>>> multiplication to regs_get_gpr()?
>>
>> ... It would be better to move the multiplication inside regs_get_gpr().
>>
>> Your comment made me think about whether the multiplication is needed at
>> all (regardless of where it is done). In other words, ex->data contains
>> the register number, so we could just write:
>>
>> static unsigned long regs_get_gpr(const struct cpu_user_regs *regs,
>>                                     unsigned int num)
>> {
>>       /*
>>        * The GPR number -> offset arithmetic below relies on x0..x31 being
>>        * laid out at the start of struct cpu_user_regs in architectural
>> order.
>>        */
>>       BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) != sizeof(unsigned
>> long));
>>       BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) != 31 *
>> sizeof(unsigned long));
>>
>>       ASSERT(num && (num < 32));
>>
>>       return ((const unsigned long *)regs)[num];
>> }
>>
>> Probably, we want to consider this function out of context (for now
>> context is that we use it to recieve a pointer to trap_info which can't
>> be obviously stored in x0 as it should be always hardwired zero). In
>> that case, there is no need to check that num is 0.
>>
>> So, it probably makes sense to just have:
>>     ASSERT(num < 32);
>>
>> ASSERT() is fine here as I don't think that compiler will use incorrect
>> number during register allocation.
> 
> I agree.
> 
> However, the x0 aspect is still odd. Why again is it that struct cpu_user_regs
> has a field for it, when the register value is always 0? 

zero field isn't there to hold a value, it's there so the first 32 slots 
form an x0..x31 array indexed by GPR number. It is useful for SET_RD() 
implementation, for example.

> (And tangentially,
> what's the pregs field there, and what is stack_cpu_regs?)

It is rudiment, I don't use it anymore.

I will drop it in separate patch.

> 
>>>> --- /dev/null
>>>> +++ b/xen/arch/riscv/include/asm/gpr-num.h
>>>> @@ -0,0 +1,33 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>> +#ifndef RISCV_GPR_NUM_H
>>>> +#define RISCV_GPR_NUM_H
>>>> +
>>>> +/* GPR ABI names, in register-number order (x0 .. x31). */
>>>> +#define GPR_ABI_NAMES                   \
>>>> +    zero, ra, sp, gp, tp, t0, t1, t2,   \
>>>> +    s0, s1, a0, a1, a2, a3, a4, a5,     \
>>>> +    a6, a7, s2, s3, s4, s5, s6, s7,     \
>>>> +    s8, s9, s10, s11, t3, t4, t5, t6
> 
> Having looked at struct cpu_user_regs for the response above: How is this
> macro intended to be kept in sync with struct cpu_user_regs? Yes, the ABI
> isn't going to change, but (a) still and (b) if later another ABI was
> introduced, names here and fields there could still easily diverge.

Yes, this macro should be in sync with struct cpu_user_regs too.

Then it is needed to turn GPR_ABI_NAMES into a numbered X-macro list and 
generate everything from it:


/* asm/gpr-num.h */
/*
  * GPRs in register-number order (x0 .. x31), by ABI name.  Single 
source of
  * truth: generates the .L_gpr_num_* assembler symbols, and is 
cross-checked
  * against struct cpu_user_regs at build time (see regs_get_gpr()).
  */
#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)

#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

and then also:


/* extable.c, replacing the two existing BUILD_BUG_ONs */
#define CHECK_GPR_OFFSET(num, name)                     \
     BUILD_BUG_ON(offsetof(struct cpu_user_regs, name)   \
                  != (num) * sizeof(unsigned long));

static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
                                          unsigned int offset)
{
     /* GPR number N must be field N of struct cpu_user_regs. */
     GPR_LIST(CHECK_GPR_OFFSET)
     ...
}

> 
>>>> +#ifdef __ASSEMBLER__
>>>> +
>>>> +    .equ    .L_gpr_num, 0
>>>> +    .irp    name, GPR_ABI_NAMES
>>>> +    .equ    .L_gpr_num_\name, .L_gpr_num
>>>> +    .equ    .L_gpr_num, .L_gpr_num + 1
>>>> +    .endr
>>>
>>> So this is emitted no matter whether a .S file actually uses any of the constants.
>>> Perhaps okayish, but somewhat wasteful.
>>
>> I can move #include <asm/gpr-num.h> inside "#else /* __ASSEMBLER__ */"
>> in asm/extable.h and it will be enough for now. Or just drop declaration
>> of .L_gpr_num for assembler code until it will be needed by it.
> 
> How would either of these address the remark I made? Not every .S file
> including asm/extable.h will need these constants. Imo this new file wants
> strictly only including by files which actually need .L_gpr_num_*.

Oh, now I got your idea. There is no need to icnlude asm/gpr-num.h 
inside <asm/extable.h>. It seems to me then it will be better to follow 
the way which was intrdouced originally just have asm/gpr-num.h included 
at the top of asm/extable.h, this is not a big price for .S file which 
including asm/extrable.h and doesn't really need asm/gpr-num.h.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:18:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:18:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393793.1632612 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFxi-0001WJ-9I; Tue, 18 Aug 2026 09:18:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393793.1632612; Tue, 18 Aug 2026 09:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFxi-0001VW-6j; Tue, 18 Aug 2026 09:18:26 +0000
Received: by outflank-mailman (input) for mailman id 1393793;
 Tue, 18 Aug 2026 09:18:24 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwFxg-0001Uq-J6
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:18:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFxf-00B445-JD
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:18:23 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a842350-8faa-0a2a0a5109dd-0a2a450cdbea-36
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:18:22 +0200
Received: from [52.101.43.27]
 (helo=SJ2PR03CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a84235d-f479-0a2a450c0019-34652b1b1f1c-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:18:22 +0200
Received: from CH0PR03CA0199.namprd03.prod.outlook.com (2603:10b6:610:e4::24)
 by SJ0PR12MB7066.namprd12.prod.outlook.com (2603:10b6:a03:4ae::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 09:18:16 +0000
Received: from CH1PEPF0000AD74.namprd04.prod.outlook.com
 (2603:10b6:610:e4:cafe::66) by CH0PR03CA0199.outlook.office365.com
 (2603:10b6:610:e4::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 09:18:16 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 CH1PEPF0000AD74.mail.protection.outlook.com (10.167.244.52) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 09:18:16 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 04:18:15 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 04:18:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UllfezdwrDQlvbG+nayyye0gZVZhEhvQuJy1eX2lLDr60IaIGDOhpC6dJCprnrVaEjkwGC6gqzQkvQixe/u99Prq35t3hXb1vKIDTzCLVKRtZK3FXgo9e0+YL5OLTgeW4DpbubvCVUAo1Pr0mIpeBbaSe8oN9NN5WbqOtDwfjs4mT9HwpE+IG0VgyXxgXifY8spp5NxgA9kW7iMk2/2uWHS3WobEHPiNs29dD0V7loCC88KHrT9V5sR05jcjyqVq5wuF5kcFIRv2FoSJLqXO+SkSfGX55PW3RfdhIC482C+/np7dr0foQdH+0Lqlg4RfQh/yR0VqEtNrUFeN5EPRlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UZqpulfjTWkOhIsoGZ4e0pAvqoxKQjA10qGlLQTjhQg=;
 b=f9+qOkl0K7Y0tspR8rRcX0hSz+BU+50b9oIFm3ls09GHN+Cl3iPJ1EQirRSk0mI0421GGlINWhUY6X64A5NQ7Vy9m7MKxrx+ueLe/1hTZo14dNR8CdK0nbaoDnTi212W5FfqncruAY5Wtx/CodjyrGN590UVZkLmT/vwr5B6YIqE9R+lotH3CWbGXT0Qsa5MDOjJZVR+1sLGkOfMpzilgjGnowkbM7wXktzmjN6Hdzo1m5RPAr01fOTfc39VPeIOwLra/EIGnb4UlGS7Tam7fs1qi1jS6ARxBRJJsS/ttDKQyiXGgR1haDUqaHPwpz2jqLYUYT/TZzciQoi/zH4LIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=valinux.co.jp smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=UZqpulfjTWkOhIsoGZ4e0pAvqoxKQjA10qGlLQTjhQg=;
 b=uKpy0LJX3vb4cpAincOvPRmKDsEsBxJ0vs0BcXGsP8fmzDzMWIDsWmdTlYkmrMbPXw29YEITrQLL6IsVQ/0kuoYGgvEx8T7946V6H/fTRGbdUOOYBl43/WVP8FhaujFM2sUzu2h4EDwbqPlBEv8p5WOUlCy0P0tOFYab/5xuxzU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <5f9c4266-e808-4478-a339-53b16a53b32a@amd.com>
Date: Tue, 18 Aug 2026 11:18:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
To: Hirokazu Takahashi <taka@valinux.co.jp>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260813032938.3946-1-taka@valinux.co.jp>
 <37b2d119-7ff9-4862-9bcd-acb0b7ff4c9d@amd.com>
 <OS9P286MB722234CE96BB22DD89AC65B082A62@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <OS9P286MB722234CE96BB22DD89AC65B082A62@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD74:EE_|SJ0PR12MB7066:EE_
X-MS-Office365-Filtering-Correlation-Id: c34ee783-4851-435c-e6b8-08defd09a2ee
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|23010399003|18002099003|22082099003|56012099006|13003099007|6133799003|11063799006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	3DMzfPgNtBGaaLE7tqKr0TK88GTX0VTSi/Al0eaCERjIUSC5l84+dB1gf9vwLeR2pFnSutCP34nIIauVYvyIxP6wxCEDKGQwVjx0i5NVVuxS37j0dsoih15pPHVwMEwcOX1pJy1yXkXA8Rwl27Hu4mL9LPqgkN+H7lJ2jlcHGIenkyI8/liXi76/c9+KFSKr56rtuRwiQ4H+h7o3WNz+i0z7Z25V5qrYoZ56EMnGB2LOcdKdAeTUY0mZPWY9DBtlm1JRke1NyWyTNraJ8pljmeza1jPJWIajm1o1aQc9DulsrjId/jdpkjUL9PtgKdveeqJhLDRqWXxHmykhwae1EjYw3DobeYfEPjNsD8dl/uMVsadf7e1qBIYE3toqfsv2C9EzNtbMQrrU3HMEhPSRGB1QT2hqgQDpVfQypvkJogjoIYT6PZGiX00HxX/8AOZSrpZvcFLW2v0JPknKGQq2/PcZt6ysQYtG3bskDafqR1or+ourViBEsUvoq6OkvLNh5hi81EtpW35LSK5hGiIFQkhNHzQ2eu+SatwME/NLqyFB3Z94f/EVBbS2wIFvUYrij5scSgld/+M5Qfi+VoC9yAyTUFZJLD6/xbFJzyLwzg7VkUdT6gZAdIDYEgieZNgbgRVEI2v6NGq2l3uS97VIwC5fGVE4XDriwAoLAiOPaFEhEJQhVpG47FWWBGHo18lyrUMJh245Z3zrnutNw/QaEA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700016)(23010399003)(18002099003)(22082099003)(56012099006)(13003099007)(6133799003)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	M4y+vJDk8PhKX+WhiX2ZzlEAPBvi4/2PsjnQ14xJoJp3LeiHdn0rDb6xmHUrQbkYJqvhi8fBwnFB2oVK93x9kNKhun/etTWhbFXwcS++uokLGQyA7E+bRnR2EJZD0U4E8BYmuV4BJh3whFbS8xgIts3hOoVvTanM1PhfBmzbAWff5diWlfuVoJNq4j1qHbcQta9tP9dBQAH7sXtWFHoUUzIv5L2cTunnVarijhOdkblP77wLpZfDPVGOEOKyLjNqSAtXgsfQgjdNNHwHMTartVQNv48PePXBvBNDh2jfXqfRwtbh8dxyl6BsQtxjnlvL9v+eJc0TOhk2fVtVHYvKP7Hy+spWntfl3LGeych2QZdjSZtpam0IkVeJvr4ch4fRYdhCkl/Zx2FEvwN2giP117JCiM6IWSSUZVHHWbVTVlduQx/zYrItjg1mM3GeyeRo
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 09:18:16.2745
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c34ee783-4851-435c-e6b8-08defd09a2ee
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD74.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7066
X-purgate-ID: tlsNG-d25034/1787044702-00CCBA5B-F4689333/0/0
X-purgate-type: clean
X-purgate-size: 5696



On 18-Aug-26 10:50, Hirokazu Takahashi wrote:
> Hello,
> 
> Thanks for the comments.
> 
>>> On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
>>> causes the domain to probe advanced PMU feature based on system ID
>>> register ID_AA64DFR0_EL1.During this probe, Linux accesses PMMIR_EL1,
>>> which causes unhandled register traps and crashes the domain.
>>>
>>> To address this issue, I implement the following:
>> Please use the imperative mood
> 
> Okay.
> 
>>> - Hide PMU registers from a guest domain when its vPMU feature is
>>>   disabled.
>>> - Proactively make SPE, TRBE, BRBE, and Trace Extensions inaccessible
>>>   to guest domains, as they could potentially cause similar issues.
>>> - Add emulation for PMMIR_EL1 register accesses performed by a guest
>>>   domain when vPMU is enabled. However, similar to reads from other
>> When vPMU is enabled, there is no trap/emulation
> 
> Understood.
> 
>>>   PMU registers, the read value returns zero (note that this is a
>>>   temporary implementation).
>>> - Emulation for PMSS (PMU Snapshot) register accesses is not yet
>>>   implemented, because PMSS support is not available in
>>>   qemu-system-aarch64 and could not be verified.
>>>
>>> Fixes: 07b9acea116e "xen/arm: Add handler for ID registers on arm64"
>>> Fixes: 3669a1cb9598 "xen/arm: create a cpuinfo structure for guest"
>> Fixes commit title needs to be in brackets ()
> 
> Okay.
> 
>>> --- a/xen/arch/arm/arm64/vsysreg.c
>>> +++ b/xen/arch/arm/arm64/vsysreg.c
>>> @@ -229,6 +229,7 @@ void do_sysreg(struct cpu_user_regs *regs,
>>>       */
>>>      case HSR_SYSREG_PMINTENSET_EL1:
>>>      case HSR_SYSREG_PMINTENCLR_EL1:
>>> +    case HSR_SYSREG_PMMIR_EL1:
>> What about AArch32 PMMIR?
> 
> Okay, I will add a trap handler entry for AArch32 PMMIR register accesses.
> 
>>> @@ -306,7 +307,6 @@ void do_sysreg(struct cpu_user_regs *regs,
>>>      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
>>>      GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
>>>      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
>>> -    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
>>>      GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
>>>      GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
>>>      GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
>>> @@ -326,6 +326,18 @@ void do_sysreg(struct cpu_user_regs *regs,
>>>      GENERATE_TID3_INFO(MVFR1_EL1, mvfr, 1)
>>>      GENERATE_TID3_INFO(MVFR2_EL1, mvfr, 2)
>>>
>>> +    case HSR_SYSREG_ID_DFR0_EL1:
>> You only cover AArch64. What about AArch32 DFR0?
> 
> Okay, I will also add a trap handler entry for it.
>  
>>> +    {
>>> +        struct domain *d = current->domain;
>> Use v->domain instead like the surrounding code
> 
> Okay.
>  
>>> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
>>> +
>>> +        if ( !(d->options & XEN_DOMCTL_CDF_vpmu) )
>>> +            info_dbg32.perfmon = 0;
>>> +
>>> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
>>> +                                  info_dbg32.bits[0]);
>>> +    }
>>> +
>>>      case HSR_SYSREG_ID_AA64PFR0_EL1:
>>>      {
>>>          register_t guest_reg_value = domain_cpuinfo.pfr64.bits[0];
>>> @@ -348,7 +360,6 @@ void do_sysreg(struct cpu_user_regs *regs,
>>>      }
>>>
>>>      GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
>>> -    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
>>>      GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
>> What about DFR1 fields like PMICNTR? They suffer from the same problem.
> 
> Okay, I will fix it.
>  
>>>      GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
>>>      GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
>>> @@ -358,6 +369,22 @@ void do_sysreg(struct cpu_user_regs *regs,
>>>      GENERATE_TID3_INFO(ID_AA64AFR0_EL1, aux64, 0)
>>>      GENERATE_TID3_INFO(ID_AA64AFR1_EL1, aux64, 1)
>>>
>>> +    case HSR_SYSREG_ID_AA64DFR0_EL1:
>> Please adhere to the order in which the cases were originally placed
> 
> Okay.
> 
>>> +    {
>>> +        struct domain *d = current->domain;
>>> +        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
>>> +
>>> +        if ( !(d->options & XEN_DOMCTL_CDF_vpmu) )
>> To avoid duplication, please introduce is_vpmu_domain
> 
> Okay, I will.
> 
>>> +        {
>>> +            info_dbg64.pmu_ver = 0;
>>> +            info_dbg64.mtpmu = 0;
>>> +            info_dbg64.pmss = 0;
>>> +        }
>>> +
>>> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
>>> +                                  info_dbg64.bits[0]);
>>> +    }
>>> +
> 
>>> @@ -216,16 +216,18 @@ struct cpuinfo_arm {
>>>              unsigned long trace_ver:4;
>>>              unsigned long pmu_ver:4;
>>>              unsigned long brps:4;
>>> -            unsigned long __res0:4;
>>> +            unsigned long pmss:4;
>>>              unsigned long wrps:4;
>>> -            unsigned long __res1:4;
>>> +            unsigned long sebep:4;
>> Where did you take this field from? I can't see it in the latest Arm ARM:
>> https://support.arm.com/documentation/ddi0487/mc/-Part-D-The-AArch64
>> -System-Level-Architecture/-Chapter-D24-AArch64-System-Register-Descri
>> ptions/-D24-2-General-system-control-registers/-D24-2-79-ID-AA64DFR0-
>> EL1--AArch64-Debug-Feature-Register-0?lang=en
> 
> In a slightly older Architecture Reference Manual, there was a SEBEP field
> in ID_AA64DFR0_EL1. Has it been removed from the spec?
I can see it's been added since Armv9.3. I'd recommend leaving it as RES given
that you do not use it anyway in this patch. We usually do the update looking at
the latest Armv8-A spec.

~Michal




From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:20:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:20:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393800.1632622 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFzG-0002KA-La; Tue, 18 Aug 2026 09:20:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393800.1632622; Tue, 18 Aug 2026 09:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwFzG-0002JZ-H7; Tue, 18 Aug 2026 09:20:02 +0000
Received: by outflank-mailman (input) for mailman id 1393800;
 Tue, 18 Aug 2026 09:20:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwFzF-00022A-8f
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:20:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwFzE-0026XI-LM
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:20:00 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8423b8-8faa-0a2a0a5109dd-0a2a450cb062-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:20:00 +0200
Received: from [52.101.83.105]
 (helo=GVXPR05CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8423c0-f479-0a2a450c0019-3465536943d3-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:20:00 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by BESPR03MB11771.eurprd03.prod.outlook.com (2603:10a6:b10:fe::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 09:19:58 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 09:19:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=A5/IiBp9a+diqt1ip1NlPb8nrvFkySO3DGRYeHKkBPEDzJiBUHaAPe9Ii5nd3fKHJvUMuUQ+xxZ7XeyyXy96m8O+rnTltsRBhpQ2He/32jFMSIytHbqoOjit61y5nl2Ulpzvyia8xDItQIP7p0GRSVOJCdnw/zA0WFmYZUXq243WVye3FA2O4Wvzjx1luhbp+aNAyavbdRd2Quq4hHsEQTsW+J00VIjtdAPl1+s+4WI6PD1P25C6l+Yo1js8FgqvMdptNvZRkUrT9JnK3FMlsZqCrL54TS/M1XiGlnkKxdS3s5vPO9o0V1KDOITunbCYWW+zaUX1O3X4YsVAsYONRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OZJW6+PpwTOAkHi4zyqBOVwy7B7owB2mnA+s6Q0GOYk=;
 b=uML0fT2jX2GZbHKozaGUtH/GpvgTVQcPkJjARyDf7kC1zBXF6Ih1OUDR6F7/Ld2X6oZDM0ql1Ur4JPei0M2XIr1nj00nXzISFL3NxDjdILL/opOqDvK13u/jVIk8iMeYaVcwqCLM0vmtwNC/U981z7ZCq4Q601+TbHuEulaz/q/9vZ4Jc2498z5vpT3OC97ljys4HaDqfu6ZrWJPnjzqLrhka4S2R+PJoOLKpNmAdirfyeRMKzJQUNk8/lcL05bL5zWbtmKIG2mc/o+zROP+nHehKfoQCq1pP7sIQavhOmvq0gMCHTIG2I3UWY3PMd4PSm+YDAqydT9eVkSyQ07jsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OZJW6+PpwTOAkHi4zyqBOVwy7B7owB2mnA+s6Q0GOYk=;
 b=XFWT598exDOX1BfgbFMDeUJ+eo578wTEEBEmLfdr3c6VIj7k+vKwXHrjXEAbOs/AutDxbT0yu6pwPlzeZ0fuXuUcr/ZHS52J6xXJzJ/3yO6liLRLRCyBnVJUv7A93UICHRYQXH0q1cIJjlty7wUzszUofZtL7fn4lrc3O7MMIKrsqT4KrBvaYQREEd/lr8AqwwbGlM7wB5/v4rgGe2ElNsvwULUDoj9JJtIZx6Wp0eypC3lomWfHmlyyAn0qe75R/15hFBeQhFke3VThRyyvijjCbe1Tk4SLUk7BiUg+PKMReoaYc2Qc7por1Bq56rMPjS35y9QjP33USYMCNb22GA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v3] xen/arm: derive GIC CPU interface ID fields from the vGIC
Date: Tue, 18 Aug 2026 12:19:49 +0300
Message-ID: <e8841a943eb7f6a64348b7316032084fb848bc2b.1787040666.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA2P291CA0037.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1f::17) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|BESPR03MB11771:EE_
X-MS-Office365-Filtering-Correlation-Id: 95d9c60e-7758-4582-3f0b-08defd09dfbd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|56012099006|6133799003|11063799006|10067099003|5023799004;
X-Microsoft-Antispam-Message-Info:
	hBNE/7XyHxeH4Qxx4lF6KZjxCjIixopRDIG9hgiwYlhnpZTO4EBQpBg8KX8B0lBx8h0mXf8kGhpgkU96WGVYt8bmI3wAm3R8peATobnRao/odzVzkDCra85sqnU4runFhoA9eGHryjqYi5kala/sHY4Z4RdNPv0EmAN9JfjqWoMagsnih/0rWKEgBYHSAR/ZeqSKvr9n+prbrgN7LHIsAL2SAE3V4Cy1bLNwtHXWuu485xUybRQBuJGEarkCfC1kjA1hIEpUgwUM0B8FywAxhzrs6isqUIyb5jRyKmts8+f0WE3+BW5/C1X9f/eZj8HyZto8XEQxXoU/W3w0yuSmlJqyOCc0Ixa8PcB54nxWWud5T5vmhbpaMPVGx7cmJIzzcI1I3kcZYXTrPUI+SpqbLsN+ngh/8AnAea276Sk54xEYAoroxE04tNLgG5AGxZfN6HG94PIECRlwrk48q4JCuy8rA2l3fm4StwHeyqYY8OmEW5V3QQPRlvXXpic8L0hajmQlDhu2POv/g/52Frb4EjnBZnUpCIZ0Ye1ZhqhSHwFusB/RS4rNo1BEJx5zrXNvdfGtBAb6KPhpwi2FhcOu7K7cSjEpP+6xKd5WWiNfAK8=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(56012099006)(6133799003)(11063799006)(10067099003)(5023799004);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ZUlzGMIpvPRO/9P53z4BFfOKBTVHrfHr2TX1nRXmuta6TFTFxMmd/5wc6390?=
 =?us-ascii?Q?dNH7N5fmX+1LC3WLWJeMpBPZbEFoPO+bCl3qieqvQwDaIDedGtHWW4HZjA4t?=
 =?us-ascii?Q?7sT44MwC7qUq3Naq31frez9VuQncJDnp8wWpp4emoe5Z+fD1V842uz+okua6?=
 =?us-ascii?Q?KPFqkU5ySixUTcgBwccVB2Bgvk7X9yP6UrdyrSYJQORm9nzJ2yK0uhdHDxK0?=
 =?us-ascii?Q?pK7vSiAovYHaZIaYUpfwMHsdKHQeF0c923d3v2U6Z4XJwMRGFi8NwZtdu6/X?=
 =?us-ascii?Q?m+5kfWEWn8jIzwZlgHRqwLu/w/HfO30Mt+CgSKJHrvSRD8+lVZBQXc5AVaMp?=
 =?us-ascii?Q?MdAMAnrETajNoOMmK8hJo8S8STqcMkXoh9sOMfFbXV3Kep4NN14XlcXl5lKt?=
 =?us-ascii?Q?nH9FR32vjHZG13NarnqO5Tf+BNWvLKcqpCyzN9RoCz0ArTFmHnE5TC/LtwON?=
 =?us-ascii?Q?fpVI5cyevj2o5ihVoZCzTJSZrxEVIn4sCcBgDOI6+8aUOJJ/7Rwp6YSugWkX?=
 =?us-ascii?Q?QpbWQdJVAy6nEPJtg5HON8dYORR+zKMwQ7737jlFhbPpgjDWpSXCi6XOJsA7?=
 =?us-ascii?Q?XTLmVsS9r7yE5tGYmkOqoBKVN8wQtMzKopqXqTtQya6DMXURD6yOD7raG7Io?=
 =?us-ascii?Q?wA3FTuNwcH05b1+9RMlsU1LMeE2+9KHudiwPYmNBNn1UyRBbFmtLo5gvUh1M?=
 =?us-ascii?Q?LmCwXpyJGLjBahBanj/x0tCIhjxf9i39u4MLq5FHUoS+0vQDbeYXAWirJdwJ?=
 =?us-ascii?Q?IQQiOPQi/86cbeOUjoBgs5Tg84Mxc//gPwg1NwTloeS554UT7UZd6EOLY01y?=
 =?us-ascii?Q?t1BD79Y+sxtdBbDJv6DCPZ0/63iidOdHxC2t1q5spDc1C6ADPuAlJ+spgFNa?=
 =?us-ascii?Q?Q+ryF9nlnbtVj6Nz1eO2n30kUtut3nsQHpbyctdvzZxdMTojeO4+frhuKe3D?=
 =?us-ascii?Q?irzd5IRmQH7ZspeacBRHrvJfgBP5iGac09k0uI4f9uXH+t0axisx5SA2jrRy?=
 =?us-ascii?Q?gDnB6mGGYUTSztbFj11oZnTzck1gMVmdRDHqb4Wrz9sdPJtTpCS3IuYFMA4X?=
 =?us-ascii?Q?QRFpk38iap8Uy7NaWHOH32TJ0cwHkCaeIjJkSyXEW3XvMs/76zZDkZVvPhl+?=
 =?us-ascii?Q?XuSyzJp3TU2ojr401um3ECmDcijTcQuW6YnaFtLbtYLHN4zxqmvggEaY53Bq?=
 =?us-ascii?Q?tu8OD3S/EuFy0lqGHeLfLOGe3QhmsHyF0NIXgQUN1a7bcGeVYTvaH8iNZkOd?=
 =?us-ascii?Q?Q40G/VyaAQsmW5aEI93KS0kVDgbzhnoN40yF7souDkjZ9aNldHuodFOEA1c/?=
 =?us-ascii?Q?Al6znAHf/sexVqJFZxJnErifUQ1OzvLCdotibFqoAOkaaJVrZlWaozosGEkp?=
 =?us-ascii?Q?U0d/v5pF4LOTP9Tg3YcmHw6xy/WfzNE0QLjrAqMipjaIRAaf8MnEPvGANNAf?=
 =?us-ascii?Q?UcN0JGPaA7vW7zYBaH1XCfBqlXHdOelg/0Vhe9UdsDOMSEQtx+fpyqXe6Oac?=
 =?us-ascii?Q?PAo+1XRSTitcuzRBGQAIbv+6PqxnyUd3StNIeIkLaqPoTQOn8ncdHeMjx9hv?=
 =?us-ascii?Q?1wuVQMyKpowoYdDIB9vU1lJuUrakmLoUV7Eo09fg/OcHABaFuV9SHk6NbBvV?=
 =?us-ascii?Q?GvLxGR85FPQIpD+JomNNbS8F+3dILyRv793ZjjYtLZvr6h+H4Yu6K26VV0bo?=
 =?us-ascii?Q?3Ns8VEVe6CkDR4ZKBnaglOw2dNVmi2r/vDk+fIOCg/AmALtH7OXmR652uQNL?=
 =?us-ascii?Q?m1E7coju+w=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95d9c60e-7758-4582-3f0b-08defd09dfbd
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 09:19:58.6046
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: HvcMRhwdZVelW8Ok2nbAk78/YpbWHOYGPE4L+aRxDNZOtSStegEImFBGy9O+1AdD3UwnXPWpersczwH3wxmBKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB11771
X-purgate-ID: tlsNG-d25034/1787044800-024DFA5B-5254EC1A/0/0
X-purgate-type: clean
X-purgate-size: 7709

Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo,
which is initialized from the sanitized host CPU feature state. This
does not necessarily match the virtual interrupt controller configured
for a domain.

A vGICv2 domain can therefore observe a nonzero GIC field when the host
supports the GIC system register interface, even though Xen disables that
interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can
observe encoding 0b0011, although Xen exposes only its vGICv3 model.

Derive the fields from the domain's vGIC version instead. Expose 0b0000
for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the
ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through
CP15 in AArch32 state. Leave the alias unchanged when AArch32 is
unavailable.

Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v3:
- Add direct dependencies for the shared ID register helpers.
- Move ID_PFR1_GIC_SHIFT to the common CP15 register header.
- Apply cosmetic fixes from review.

Changes in v2:
- Share the GIC ID field helpers between the AArch64 and AArch32 paths.
- Parenthesize the individual ASSERT conditions.
- Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable.
- Target master instead of the 4.22 release.

v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/
---
 xen/arch/arm/arm64/cpufeature.c          |  1 +
 xen/arch/arm/arm64/vsysreg.c             | 18 +++++++++++++++-
 xen/arch/arm/include/asm/arm64/sysregs.h |  1 -
 xen/arch/arm/include/asm/cpregs.h        |  1 +
 xen/arch/arm/include/asm/vreg.h          | 26 ++++++++++++++++++++++++
 xen/arch/arm/vcpreg.c                    | 12 ++++++++++-
 6 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
index 6fb8974ade..8bae8915e8 100644
--- a/xen/arch/arm/arm64/cpufeature.c
+++ b/xen/arch/arm/arm64/cpufeature.c
@@ -72,6 +72,7 @@
 #include <xen/bug.h>
 #include <xen/types.h>
 #include <xen/kernel.h>
+#include <asm/cpregs.h>
 #include <asm/sysregs.h>
 #include <asm/cpufeature.h>
 #include <asm/arm64/cpufeature.h>
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index d9e3619dfb..4fb50b6972 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -20,6 +20,7 @@
 
 #include <asm/arm64/cpufeature.h>
 #include <asm/arm64/sve.h>
+#include <asm/cpregs.h>
 #include <asm/current.h>
 #include <asm/regs.h>
 #include <asm/traps.h>
@@ -298,7 +299,18 @@ void do_sysreg(struct cpu_user_regs *regs,
      * to identify the processor features
      */
     GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
-    GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
+    case HSR_SYSREG_ID_PFR1_EL1:
+    {
+        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
+
+        if ( cpu_feature64_has_el0_32(&domain_cpuinfo) )
+            guest_reg_value = id_reg_set_gic_field(guest_reg_value,
+                                                   ID_PFR1_GIC_SHIFT,
+                                                   v->domain);
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  guest_reg_value);
+    }
     GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
     GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
     GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
@@ -337,6 +349,10 @@ void do_sysreg(struct cpu_user_regs *regs,
             guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask;
         }
 
+        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
+                                               ID_AA64PFR0_GIC_SHIFT,
+                                               v->domain);
+
         return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
                                   guest_reg_value);
     }
diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
index f3c11d871e..c0a6827b08 100644
--- a/xen/arch/arm/include/asm/arm64/sysregs.h
+++ b/xen/arch/arm/include/asm/arm64/sysregs.h
@@ -438,7 +438,6 @@
 #define MVFR1_FPDNAN_SHIFT           4
 #define MVFR1_FPFTZ_SHIFT            0
 
-#define ID_PFR1_GIC_SHIFT            28
 #define ID_PFR1_VIRT_FRAC_SHIFT      24
 #define ID_PFR1_SEC_FRAC_SHIFT       20
 #define ID_PFR1_GENTIMER_SHIFT       16
diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
index a7503a190f..79203324fa 100644
--- a/xen/arch/arm/include/asm/cpregs.h
+++ b/xen/arch/arm/include/asm/cpregs.h
@@ -114,6 +114,7 @@
 #define MPIDR           p15,0,c0,c0,5   /* Multiprocessor Affinity Register */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define ID_PFR1_GIC_SHIFT 28
 #define ID_PFR2         p15,0,c0,c3,4   /* Processor Feature Register 2 */
 #define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */
 #define ID_DFR1         p15,0,c0,c3,5   /* Debug Feature Register 1 */
diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
index 387ce76e7e..bb6c904f2e 100644
--- a/xen/arch/arm/include/asm/vreg.h
+++ b/xen/arch/arm/include/asm/vreg.h
@@ -4,11 +4,37 @@
 #ifndef __ASM_ARM_VREG__
 #define __ASM_ARM_VREG__
 
+#include <xen/bitops.h>
+#include <xen/bug.h>
+#include <xen/sched.h>
+
+#include <asm/gic.h>
+
 typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
                                    bool read);
 typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r,
                                    bool read);
 
+#define ID_REG_GIC_WIDTH 4
+
+static inline unsigned int vgic_id_gic_field(const struct domain *d)
+{
+    ASSERT((d->arch.vgic.version == GIC_V2) ||
+           (d->arch.vgic.version == GIC_V3));
+
+    return d->arch.vgic.version == GIC_V3;
+}
+
+static inline register_t id_reg_set_gic_field(register_t val,
+                                              unsigned int shift,
+                                              const struct domain *d)
+{
+    register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift);
+
+    return (val & ~mask) |
+            ((register_t)vgic_id_gic_field(d) << shift);
+}
+
 static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr,
                                      vreg_reg_fn_t fn)
 {
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index 3205c7df46..31ef6df838 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -318,7 +318,17 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
      * to identify the processor features
      */
     GENERATE_TID3_INFO(ID_PFR0, pfr32, 0)
-    GENERATE_TID3_INFO(ID_PFR1, pfr32, 1)
+    case HSR_CPREG32(ID_PFR1):
+    {
+        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
+
+        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
+                                               ID_PFR1_GIC_SHIFT,
+                                               v->domain);
+
+        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1,
+                                  guest_reg_value);
+    }
     GENERATE_TID3_INFO(ID_PFR2, pfr32, 2)
     GENERATE_TID3_INFO(ID_DFR0, dbg32, 0)
     GENERATE_TID3_INFO(ID_DFR1, dbg32, 1)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:23:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:23:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393810.1632631 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwG2O-0003Zp-7t; Tue, 18 Aug 2026 09:23:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393810.1632631; Tue, 18 Aug 2026 09:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwG2O-0003Zh-47; Tue, 18 Aug 2026 09:23:16 +0000
Received: by outflank-mailman (input) for mailman id 1393810;
 Tue, 18 Aug 2026 09:23:14 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwG2M-0003Zb-Oj
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:23:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwG2L-00Ci9J-36
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:23:13 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a842480-2eae-0a2a0a5409dd-0a2a4504ce44-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:23:12 +0200
Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a842480-b57f-0a2a45040019-d155dd30c582-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:23:12 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so2881779f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 02:23:12 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b81715sm10625068f8f.35.2026.08.18.02.23.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 02:23:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787044992; x=1787649792; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=v0JjEXAniUWY5CBuYEhmSYBUVuaMTMa/XL2l8ATqYpU=;
        b=IA6p75qoEdAPznIzpBG6U0Wxf1HPd9TuwE+6ReiQzv3A4IDud29pHzokQ/E9bucz+f
         ccrPSX8nX+GiSqDdZIxwpsWCGOlD5zTAcHqlmnwA0CqKavsE5fGycbDp3Tb4CN35HGZ8
         m3QcmSPJNqkwAxBBFtQxy2vG8aRMi3COEpsVkvhDQhj4X80y91TaDVkoedcyZr7rdjUI
         wUhplAfy8/Nrkt7JP8AxvwW6fQPt4o3zTN3Bz1MhyjBn1dv54MUSLNisizZ9T0z+pYOt
         UtLt1Tm2kndzpcuRXdIZqKAceX08O+CJBo1f+7k2+BFPFj9Jmd2LaS++KPaY80+AElmV
         6fUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787044992; x=1787649792;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=v0JjEXAniUWY5CBuYEhmSYBUVuaMTMa/XL2l8ATqYpU=;
        b=XMf7cWtiTVrOK48oLwyX1wSZ88bUUGhxOqu/SqV3KlmyQScoNlUtgTPPknkrIpx1ws
         yRO2NJME8yk0L/WaE9fd6WQ8ZjqyrzjgqKuLvMtFK2+x32RSkEr1TRGScgNThXb1FkIP
         Bn/OJk2HAa8ko3oqY/kpaRdY2IEeX9jv1KTjmIfYG+HX+OEdQUuxjBUcXRjD8LNBpyTL
         lM5Xq0/ROsZolJZIqBcZvpQHs2iIjsJHFUeKOUxmg2Aj7Ekhb95MV3MCuAkAQe7Y0zLg
         ZGHTYLsGtsKTL+35t3PgAVe4L6sJz22PO143do1f3GL0Bo5gl+BfxRf8ErWxcSPKe+jM
         lMcg==
X-Forwarded-Encrypted: i=1; AHgh+Rpiqsi3wfDwlKVPFldo1j9nsdwCtZ8VL/J7P9xB7Yg3QUPxiiQhKaUCLpzMuzRNe8Fx1JtkxRXLII4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxAHsP6UJrsUU+0ud2q5cMOBKk8f7PoI856U5Ckv9gAQzX4W0Qj
	ZNcr76mI7242zrvAnqCU6VFAEO1ZJFaJlYO5MHoUIEyswdvL9WbXMyBu9Zhc1YxUSA==
X-Gm-Gg: AR+sD12P2KdlV+Yn6VoMy3EXKZt4lFkYxF3kb0LG+s0dcesSfknv2F25ghUzzilyphH
	Idkcfv+2T9lwb7B9MmGaVDMjVICfCqbEaz5sC0/gWkaxeL2KWQmNAh0T3k01r8+tzIWJ2dpu5Y5
	Kjd5G3KU16NobzKVTC94mWG8AcfF0xNHTSNqT8HKlyoTqQ7vs53CT2mcUFLPqIOogt3BGekdcHJ
	9aY7CvHw9hOgivmlc4SzRXvYZOS5nhnovp0gxOtk0kGsF7D06GFtjKbmXr9YmH8jpKyJ1rhg4MY
	C/42K7t6E5WK5IFesKVknRzgRKXFXpa7nhZ1wej8SFVc/T9o7nvwnsXVRfpAp17Cq+BNz1R2VNZ
	Qdtk3JeAYgQ0hYjA4dkO4/fW2mt375GdLb5e+lw/DKJinIKwe8lKoCGpnZnGwR42mEEsv9mcRRG
	B/1cu8GVPlHA2LbZRWV/Y7tO/J/qUqygKW/ZtQfLTJ/rDjMP3Jixipk2yuZ+S6g20mSGlLtlBAl
	HaWhQi1gnZOos1tVTBH7oAcGHemTbXLMEToN8GwFkveWgxHOtyfKTEWMasbR7c=
X-Received: by 2002:adf:e002:0:10b0:482:a610:7a27 with SMTP id ffacd0b85a97d-482a6107a55mr12434569f8f.20.1787044992325;
        Tue, 18 Aug 2026 02:23:12 -0700 (PDT)
Message-ID: <e6f35ea6-77e2-481a-b695-421087e60edf@suse.com>
Date: Tue, 18 Aug 2026 11:23:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86/nSVM: Validate the L1 IOPM physical address range
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com,
 teddy.astie@vates.tech, xen-devel@lists.xenproject.org
References: <8302fc9800d6d5ffe8341ccf1a5f8cc0ee19540c.1786984508.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <8302fc9800d6d5ffe8341ccf1a5f8cc0ee19540c.1786984508.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787044992-C06DAB50-276A1BFE/0/0
X-purgate-type: clean
X-purgate-size: 1668

On 17.08.2026 18:59, Abdelkareem Abdelsaamad wrote:
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -282,7 +282,7 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
>      return 0;
>  }
>  
> -static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
> +static int nsvm_vmrun_permissionmap(struct vcpu *v)
>  {
>      struct svm_vcpu *arch_svm = &v->arch.hvm.svm;
>      struct nestedsvm *svm = &vcpu_nestedsvm(v);
> @@ -294,6 +294,17 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>      enum hvm_translation_result ret;
>      unsigned long *ns_viomap;
>      bool ioport_80 = true, ioport_ed = true;
> +    /* IOPM is structured as a linear array of 64K+3 bits. */
> +    const unsigned long nr_iopm_additional_pages = PFN_DOWN((0x10000 + 8) / 8 - 1);

Hm, the expression I did suggest was indeed off by one, yet yours doesn't fit
the comment very well. What's wrong with PFN_DOWN((0x10000 + 3) / 8) or
PFN_DOWN((0xffff + 4) / 8)?

> +    gfn_t ns_iopm_end =
> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), nr_iopm_additional_pages);

I'm also inclined to suggest to drop the local variable, as it's used just
here. The overall result would be

    /* IOPM is structured as a linear array of 64K+3 bits. */
    gfn_t ns_iopm_end = gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa),
                                PFN_DOWN((0x10000 + 3) / 8));

which imo is a little easier to follow. Preferably with those adjustments
(happy to carry out while committing, but please confirm):
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:26:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:26:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393819.1632640 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwG5R-00045r-KE; Tue, 18 Aug 2026 09:26:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393819.1632640; Tue, 18 Aug 2026 09:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwG5R-00045k-Gh; Tue, 18 Aug 2026 09:26:25 +0000
Received: by outflank-mailman (input) for mailman id 1393819;
 Tue, 18 Aug 2026 09:26:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwG5Q-00045e-UT
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:26:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwG5Q-0028EO-B2
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:26:24 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a842530-e002-0a2a0a5209dd-0a2a45018608-28
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:26:24 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a842540-5984-0a2a45010019-d1558035c40d-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:26:24 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4954df200ddso31225805e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 02:26:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d10be27sm143981755e9.14.2026.08.18.02.26.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 02:26:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787045184; x=1787649984; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=jEgNroY0JsJnddGsmWEYJrQYgdk5+i9LPOWctWmuOH8=;
        b=NmQ3RrxzQUo6fDDgeVyHuLZc1U241Hl10WGPTCRRnrvk3hg6jVdg34UAr1/fLz5+dF
         s8G4h6T0BjiJyD6cbiRogp43s/ZnNKgK1x1x5kUr5NNkhK7qJM1sq00fq4/MTqQrt87F
         K0m7ghGpPEan3b1Zh0LYOb4L/AcsShEFlYhPhoPYeD3KG4FUusLQzPffN6++MP0JknS9
         b9lZjAY1m+e8JEg0K1c796El2K4F8QZ5STECeik6AsybYKfOWkUbSZjj+HWAbf/MIyHj
         V5KlEV4zCZibJsTlgMDGVVmQV2ipSDSBw8KXCj5BKCwxOUnDgL8bT59nuSoUDX7PROLb
         I/Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787045184; x=1787649984;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=jEgNroY0JsJnddGsmWEYJrQYgdk5+i9LPOWctWmuOH8=;
        b=XH+q+vIbZYRBXuWrAajv/IbAyFhQCxfTIbiPhQZYvy0xeZTE6zFqad0mxds3+syNtQ
         G5APX2y+lSdrOlpeY8eKTreoAwBVnEcLSbfAINtU8j4IRIj0P6/Hb6DIl4ersruaJcWn
         my6CBW3uwpfCkBV0cckSN5T+Oa3Ym7Dpvi0JyneucZrVoIhLtGr7ijLJ/BDD1M8IuTnd
         O1bu+d36spHYYZN22uF09SDn622VeRG5ogQgbyymtTOop97Q443nHTsZZiE1/nNi2vUo
         rpFvl8JGAlsv8/tVbkSJjE98nR8BYFfS6SbP/cJ6UxmaIoxylS9Odk6eXlDt2zd8rOnF
         4sAg==
X-Forwarded-Encrypted: i=1; AHgh+RoPg2e5tWTdej1/t4GmLt37AfXLsA9ls0IKRaYrM4ibvoA40xjGLy1FzHPTr1wJ2IFLWBvKCscumc8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwpSx47V+BSYDoU/iXzKQw9XJAd9a9ego7ahcS9yzSLXifl9HcJ
	RVzIgpoLTDrraFu9Tavoiazw8WG5he4Fi0+6V6HeA4sGzrXjIF/so6waaY/IzxvN8w==
X-Gm-Gg: AR+sD12rohgyowCqDuNFoIv/M7CpJbpPlrk6dQGootpQQUkjje3xaFbPttwcuzPtAO7
	PgHombY3wEK4EEAGaz8+xDoQ1n+Nx0gvYPqtm6RGrYGGHgw/WFDvpqcFsrJCdtKbt2lGJ6HZk11
	TWjTNhxtg46mJUaPlMWTKh81Xr3Opg9pfoqTU6HJWPfFfMEFsPIgkLkDE5zx3O+mpCWNXpxlUET
	tI7joYZKyMANZw5BwJc2ZB4zB+QHpmEPmg1Dx6v+zBxxWgr+8drC6lWDAqNwqz7Nlw8e9OBtwfd
	Woe6ksXERIV1ppD1m2NHZB1VhJTbR1rT+LrMZ1wf6C8YeGaAsQxQQL14fiNhCx++13J1gUr7Zha
	PK0+y84f+wlcNlkckRBLMMZhkVQ2WdAK8XNykkn7J+htN2o4WVULeK319PL1CkzYT8VtM+XvXbH
	jX3Uu2e5j6s2LjmSjVxgGDgJix3pKJLQOC3VC81nrq8TSGOk25lfGv3PbOE3+P8jiejdOGXgXMM
	AhJEZHvkOAJvyTulYVnOnRQfob6jPKM8HVSHX3vb+mKO7e6igEN
X-Received: by 2002:a05:600c:3049:b0:499:781e:25fc with SMTP id 5b1f17b1804b1-4998792e359mr333704495e9.3.1787045183695;
        Tue, 18 Aug 2026 02:26:23 -0700 (PDT)
Message-ID: <eabb8190-51a9-4c25-b377-c25cd23af044@suse.com>
Date: Tue, 18 Aug 2026 11:26:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
 <b8b794ec-c86a-4a82-9d3a-b3ffcaa802f3@suse.com>
 <4a707c58-2225-477f-936e-9f99ae616c44@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <4a707c58-2225-477f-936e-9f99ae616c44@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787045184-1E07B757-EEF9512C/0/0
X-purgate-type: clean
X-purgate-size: 3780

On 18.08.2026 11:14, Oleksii Kurochko wrote:
> On 8/18/26 9:56 AM, Jan Beulich wrote:
>> On 17.08.2026 13:33, Oleksii Kurochko wrote:
>>> On 8/12/26 4:37 PM, Jan Beulich wrote:
>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>>>>>        regs->sepc = ex_fixup(ex);
>>>>>    }
>>>>>    
>>>>> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
>>>>> +                                         unsigned int offset)
>>>>> +{
>>>>> +    /*
>>>>> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>>> +     * laid out at the start of struct cpu_user_regs in architectural
>>>>> +     * order.
>>>>> +     */
>>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
>>>>> +                 sizeof(unsigned long));
>>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
>>>>> +                 31 * sizeof(unsigned long));
>>>>> +
>>>>> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
>>>>> +        return 0;
>>>>
>>>> And an offset not divisible by sizeof(unsigned long) is okay?
>>>
>>> No, it isn't okay. I will apply your comment ...
>>>
>>>>
>>>> Returning 0 as error indicator also feels fragile.
>>>
>>> With what I suggested below returning could be just dropped.
>>>
>>>>
>>>>> +    return *(unsigned long *)((unsigned long)regs + offset);
>>>>> +}
>>>>> +
>>>>> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
>>>>> +                                 struct cpu_user_regs *regs)
>>>>> +{
>>>>> +    struct trap_info *trap_info =
>>>>> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));
>>>>
>>>> Related to the earlier comment: Simply pass just ex->data here, leaving the
>>>> multiplication to regs_get_gpr()?
>>>
>>> ... It would be better to move the multiplication inside regs_get_gpr().
>>>
>>> Your comment made me think about whether the multiplication is needed at
>>> all (regardless of where it is done). In other words, ex->data contains
>>> the register number, so we could just write:
>>>
>>> static unsigned long regs_get_gpr(const struct cpu_user_regs *regs,
>>>                                     unsigned int num)
>>> {
>>>       /*
>>>        * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>        * laid out at the start of struct cpu_user_regs in architectural
>>> order.
>>>        */
>>>       BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) != sizeof(unsigned
>>> long));
>>>       BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) != 31 *
>>> sizeof(unsigned long));
>>>
>>>       ASSERT(num && (num < 32));
>>>
>>>       return ((const unsigned long *)regs)[num];
>>> }
>>>
>>> Probably, we want to consider this function out of context (for now
>>> context is that we use it to recieve a pointer to trap_info which can't
>>> be obviously stored in x0 as it should be always hardwired zero). In
>>> that case, there is no need to check that num is 0.
>>>
>>> So, it probably makes sense to just have:
>>>     ASSERT(num < 32);
>>>
>>> ASSERT() is fine here as I don't think that compiler will use incorrect
>>> number during register allocation.
>>
>> I agree.
>>
>> However, the x0 aspect is still odd. Why again is it that struct cpu_user_regs
>> has a field for it, when the register value is always 0? 
> 
> zero field isn't there to hold a value, it's there so the first 32 slots 
> form an x0..x31 array indexed by GPR number. It is useful for SET_RD() 
> implementation, for example.

But SET_RD() will need to avoid touching .zero anyway. Why waste the space,
when something useful can be put there?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:40:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:40:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393830.1632649 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGJ8-0007jF-Oc; Tue, 18 Aug 2026 09:40:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393830.1632649; Tue, 18 Aug 2026 09:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGJ8-0007j6-KU; Tue, 18 Aug 2026 09:40:34 +0000
Received: by outflank-mailman (input) for mailman id 1393830;
 Tue, 18 Aug 2026 09:40:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwGJ7-0007j0-JP
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:40:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGJ7-006Hcu-0A
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:40:33 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a842880-e002-0a2a0a5209dd-0a2a4509eb28-36
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:40:32 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a842890-be1a-0a2a45090019-d155802adce2-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:40:32 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49978908b35so33438255e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 02:40:32 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996109652sm294496935e9.4.2026.08.18.02.40.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 02:40:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787046032; x=1787650832; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=kSyrNZbnHBXHQgc5+cdGaQ7lQ041+r8gtibycrCKihM=;
        b=TcaVqBHf1dgkoCUFUPlZhYu0HtMcrghgVR20fCxEJEwi4asOe+TiH7yGB03ucv+jWa
         QTNbJ6O0FkobcKC1/v6+FwhRLzIDx9Pg1mAphvlP3lMz8vl2xHHbPTwi08F76o+3hrjM
         WKdtjfjOO6QIeHFShbuPff78cwixriV5piGwwF1ErkYJV1Q04BZ89xo6e8ee9QZRyJxk
         ypPKbVQLGTvY49mSNvc0r3pDdUFtD7H1ZLrbnxxgNyS/Ehpl21yyw+DEYEae9ShDOuuV
         tbLk66LEXPJpPuulQY/asHOe8/66xfG+wiZ1Qbrh6nTzEBkDfjf0WfiXK04D4ZU68QNc
         j/Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787046032; x=1787650832;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=kSyrNZbnHBXHQgc5+cdGaQ7lQ041+r8gtibycrCKihM=;
        b=gmvwGHn00JukkpL44uPnbNmNKI6Tg3k+xcSDU+heZvGu9YGlm+upaZbvrzNoJXXqsn
         JPqpxhsxnKIkK0qMVWW6GhZf7z2yChp0gs3mZCEFVyjNlExUN90CeounSyaQM4jRSGyQ
         vlk79ABWNY6x/KxXvCOHGe1ewTWTWX5OGVU5aQPR+k/GHBRvOgcaXGCOCDOum41YlYOW
         w7hgkUsdpXp5bxDY8zhOfXI0XqYSWmbN6cU5mYoKahv2yzfALxkVXhol+JSuBV5ZJGQA
         NiL1BMfuOfaFvgBVvNTu/uATbAyCfDiorKUmonVsbSc+3LbkPeEDK4XUwYS4G/eso7yf
         vj2A==
X-Forwarded-Encrypted: i=1; AHgh+Rr48si9Pr8LkJl0LEclCSK2eogaLgx4bK6gt6XGW3LlhmnQSl7Qs64EQQxTeHrV87FomzUC5lNWs5o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw0mvLbRU/zPi1HbE4mVgGBch3m0cQoDa0XUaxHy5JUYu2mDPrE
	cOIhqlirjrR6nXFyQBw+9gzYVD661QRHyWgEOmhMqTruYWa8hDA9Y8c6
X-Gm-Gg: AR+sD137Ug0LFtKBeMTwg7pYbxNyuPszU/HERC2wzoZ/6fW88r+fYovbjUPd5qjLAvx
	eLFASuOT1FrPW3/z8qfChavmTvkwBNLn8uMgIYJTb+leXiAT1eWZdo6VDSaOWKcyCO4/GTa80mu
	F5D2MSzF/DFVuI7qyjDn8lS72uFoM4V8MmZPhpLvtIbXdkP6rM5JgWXL4hEfQkJd/ifxiX1vJGn
	sRBKvi0iUk5mW2J6dLRGC4R/vMlC8pJ150K57sWi9iPkWfbfQR3wldI21n0q2wpwYYxi57bTQIa
	iT79zZq97TbnHH2S/zoDecbfHRuTBemlwJnzS1UX4OWNCgmKe3g/CNs0SLwOlQ03jOC8ZZjZGFF
	o4OuxERBhBKJgY7VVGplcHrXga+poWVOdl0nqfxNgfQrSe7p72YBywG0dr9ffEphYcuZkfbrFXF
	UhM0ng7XRUVAj/1vIBHw7Z3FQdZFV7NU/ByqfLa4LeLcpM8hBk6Wb1OFd2M8DB9AHnDU12dt0oG
	u9bc5ImVoXLM4iD2tTtjeGq1xq5gfoJ41yMc7LCRW4=
X-Received: by 2002:a7b:cbd3:0:b0:493:cefc:d113 with SMTP id 5b1f17b1804b1-4998794c02emr330877545e9.5.1787046032260;
        Tue, 18 Aug 2026 02:40:32 -0700 (PDT)
Message-ID: <5005ead1-b7e2-4edc-8359-c2a9a89e5b4d@gmail.com>
Date: Tue, 18 Aug 2026 11:40:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
 <b8b794ec-c86a-4a82-9d3a-b3ffcaa802f3@suse.com>
 <4a707c58-2225-477f-936e-9f99ae616c44@gmail.com>
 <eabb8190-51a9-4c25-b377-c25cd23af044@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <eabb8190-51a9-4c25-b377-c25cd23af044@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787046032-3AEDE034-1372C4F9/10/73395122804
X-purgate-type: spam
X-purgate-size: 4625



On 8/18/26 11:26 AM, Jan Beulich wrote:
> On 18.08.2026 11:14, Oleksii Kurochko wrote:
>> On 8/18/26 9:56 AM, Jan Beulich wrote:
>>> On 17.08.2026 13:33, Oleksii Kurochko wrote:
>>>> On 8/12/26 4:37 PM, Jan Beulich wrote:
>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>>>>>>         regs->sepc = ex_fixup(ex);
>>>>>>     }
>>>>>>     
>>>>>> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
>>>>>> +                                         unsigned int offset)
>>>>>> +{
>>>>>> +    /*
>>>>>> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>>>> +     * laid out at the start of struct cpu_user_regs in architectural
>>>>>> +     * order.
>>>>>> +     */
>>>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
>>>>>> +                 sizeof(unsigned long));
>>>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
>>>>>> +                 31 * sizeof(unsigned long));
>>>>>> +
>>>>>> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
>>>>>> +        return 0;
>>>>>
>>>>> And an offset not divisible by sizeof(unsigned long) is okay?
>>>>
>>>> No, it isn't okay. I will apply your comment ...
>>>>
>>>>>
>>>>> Returning 0 as error indicator also feels fragile.
>>>>
>>>> With what I suggested below returning could be just dropped.
>>>>
>>>>>
>>>>>> +    return *(unsigned long *)((unsigned long)regs + offset);
>>>>>> +}
>>>>>> +
>>>>>> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
>>>>>> +                                 struct cpu_user_regs *regs)
>>>>>> +{
>>>>>> +    struct trap_info *trap_info =
>>>>>> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));
>>>>>
>>>>> Related to the earlier comment: Simply pass just ex->data here, leaving the
>>>>> multiplication to regs_get_gpr()?
>>>>
>>>> ... It would be better to move the multiplication inside regs_get_gpr().
>>>>
>>>> Your comment made me think about whether the multiplication is needed at
>>>> all (regardless of where it is done). In other words, ex->data contains
>>>> the register number, so we could just write:
>>>>
>>>> static unsigned long regs_get_gpr(const struct cpu_user_regs *regs,
>>>>                                      unsigned int num)
>>>> {
>>>>        /*
>>>>         * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>>         * laid out at the start of struct cpu_user_regs in architectural
>>>> order.
>>>>         */
>>>>        BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) != sizeof(unsigned
>>>> long));
>>>>        BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) != 31 *
>>>> sizeof(unsigned long));
>>>>
>>>>        ASSERT(num && (num < 32));
>>>>
>>>>        return ((const unsigned long *)regs)[num];
>>>> }
>>>>
>>>> Probably, we want to consider this function out of context (for now
>>>> context is that we use it to recieve a pointer to trap_info which can't
>>>> be obviously stored in x0 as it should be always hardwired zero). In
>>>> that case, there is no need to check that num is 0.
>>>>
>>>> So, it probably makes sense to just have:
>>>>      ASSERT(num < 32);
>>>>
>>>> ASSERT() is fine here as I don't think that compiler will use incorrect
>>>> number during register allocation.
>>>
>>> I agree.
>>>
>>> However, the x0 aspect is still odd. Why again is it that struct cpu_user_regs
>>> has a field for it, when the register value is always 0?
>>
>> zero field isn't there to hold a value, it's there so the first 32 slots
>> form an x0..x31 array indexed by GPR number. It is useful for SET_RD()
>> implementation, for example.
> 
> But SET_RD() will need to avoid touching .zero anyway. Why waste the space,
> when something useful can be put there?

For SET_RD() agree, it doesn't make sense. Bad example. But it could be 
somehow a "protection" to not clobber something useful if SET_RD 
arguments won't handled correctly.

SET_RD() is only half of it. The read accessors matter more: sd x0, 
0(a0) to an MMIO address is the normal way a guest writes 0 to a device 
register, and emulate_store() fetches the operand with GET_RS2(), which 
is a plain index by register number. If something useful lived at offset 
0, that store would hand the device that value instead of zero. So 
whatever we put there would have to survive being read as a source 
operand and being clobbered by SET_RD(), which means nothing can go there.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:42:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:42:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393841.1632657 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGKk-0008GC-4l; Tue, 18 Aug 2026 09:42:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393841.1632657; Tue, 18 Aug 2026 09:42:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGKk-0008G5-1c; Tue, 18 Aug 2026 09:42:14 +0000
Received: by outflank-mailman (input) for mailman id 1393841;
 Tue, 18 Aug 2026 09:42:13 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <davydov-max@yandex-team.ru>) id 1wwGKi-0008Fx-CZ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:42:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGKh-001vlL-PP
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:42:11 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <davydov-max@yandex-team.ru>)
 id 6a8428ee-2eae-0a2a0a5409dd-0a2a45018a5a-12
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:42:11 +0200
Received: from [178.154.239.200] (helo=forwardcorp1d.mail.yandex.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <davydov-max@yandex-team.ru>)
 id 6a8428f2-5984-0a2a45010019-b29aefc8955c-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:42:11 +0200
Received: from mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net
 (mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net
 [IPv6:2a02:6b8:c0c:118b:0:640:b49:0])
 by forwardcorp1d.mail.yandex.net (postfix) with ESMTPS id 6D52F80AD6;
 Tue, 18 Aug 2026 12:42:10 +0300 (MSK)
Received: from [IPV6:2a02:6bf:8080:636::1:14] (unknown
 [2a02:6bf:8080:636::1:14])
 by mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net (smtpcorp) with ESMTPSA
 id 6gRfrm0eGeA0-HnMFl5RT; Tue, 18 Aug 2026 12:42:09 +0300
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID"
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru;
	s=default; t=1787046129;
	bh=o/IysMWmyL9LUdYg5QZLrssRFGKPRJkTzu4baxWXaZg=;
	h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID;
	b=KBJ1mDiEsA2ZbXz6LAiDf7sMjQBUnZHmD6q7NN4aApX9W9cwYLnw+/PkEj1rU5g0O
	 wmOVMdLrswWWfOlsuS6Zbc0aNo6B+EP7xCK/0dM6B7zp71WV22pr6Xi2ufD9MxpSZR
	 GhjGRNk9STz4esdKjMLB6QrbrNeJuE1j1slK1PkU=
Authentication-Results: mail-nwsmtp-smtp-corp-main-80.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru
Message-ID: <52aed8f2-02e1-4ef5-a6bb-7010e0dda488@yandex-team.ru>
Date: Tue, 18 Aug 2026 12:42:06 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 21/51] x86/kvm: Obtain TSC frequency from PV CPUID if
 present
To: Jim Mattson <jmattson@google.com>
Cc: Sean Christopherson <seanjc@google.com>, Kiryl Shutsemau
 <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>,
 Paolo Bonzini <pbonzini@redhat.com>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Jan Kiszka <jan.kiszka@siemens.com>,
 Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski
 <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
 Juergen Gross <jgross@suse.com>, Daniel Lezcano <daniel.lezcano@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, John Stultz <jstultz@google.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, Stephen Boyd
 <sboyd@kernel.org>, Miroslav Lichvar <mlichvar@redhat.com>, x86@kernel.org,
 linux-coco@lists.linux.dev, kvm@vger.kernel.org,
 linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev,
 linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
 Michael Kelley <mhklinux@outlook.com>, Tom Lendacky
 <thomas.lendacky@amd.com>, Nikunj A Dadhania <nikunj@amd.com>,
 David Woodhouse <dwmw@amazon.co.uk>, David Woodhouse <dwmw2@infradead.org>,
 Thomas Gleixner <tglx@linutronix.de>
References: <20260806233609.212337-1-seanjc@google.com>
 <20260806233609.212337-22-seanjc@google.com>
 <ef3b56bf-8df0-4a40-82c7-bd2d65eec71e@yandex-team.ru>
 <aoMVy4VB1sq4T-ys@google.com>
 <0d1f0afe-74f0-4adb-a7cf-2d4efd001de3@yandex-team.ru>
 <CALMp9eQRW22S6zSrhkxc+8PgSuOJJOB-jh_W1iyr7c0j5SBLow@mail.gmail.com>
Content-Language: en-US
From: Maksim Davydov <davydov-max@yandex-team.ru>
In-Reply-To: <CALMp9eQRW22S6zSrhkxc+8PgSuOJJOB-jh_W1iyr7c0j5SBLow@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787046131-C475B757-0EE3ED6C/0/0
X-purgate-type: clean
X-purgate-size: 3809



On 8/18/26 01:25, Jim Mattson wrote:
> On Mon, Aug 17, 2026 at 3:20 PM Maksim Davydov
> <davydov-max@yandex-team.ru> wrote:
>>
>>
>>
>> On 8/17/26 17:08, Sean Christopherson wrote:
>>> On Mon, Aug 17, 2026, Maksim Davydov wrote:
>>>> On 8/7/26 02:35, Sean Christopherson wrote:
>>>>> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
>>>>> index 29ca37e9a3bc..f55d0305d1f3 100644
>>>>> --- a/arch/x86/kernel/kvmclock.c
>>>>> +++ b/arch/x86/kernel/kvmclock.c
>>>>> @@ -342,8 +342,10 @@ void __init kvmclock_init(void)
>>>>>     flags = pvclock_read_flags(&hv_clock_boot[0].pvti);
>>>>>     kvm_sched_clock_init(flags & PVCLOCK_TSC_STABLE_BIT);
>>>>>
>>>>> -   x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
>>>>> -   x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
>>>>> +   if (!x86_init.hyper.get_tsc_khz)
>>>>> +           x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz;
>>>>> +   if (!x86_init.hyper.get_cpu_khz)
>>>>> +           x86_init.hyper.get_cpu_khz = kvmclock_get_tsc_khz;
>>>>>     x86_platform.get_wallclock = kvm_get_wallclock;
>>>>>     x86_platform.set_wallclock = kvm_set_wallclock;
>>>>>  #ifdef CONFIG_X86_LOCAL_APIC
>>>>
>>>>
>>>> I cannot test this right now as I lack two servers with different CPU
>>>> base frequencies, but it seems that this patch might break something in
>>>> guests:
>>>> After migrating a VM (QEMU + KVM) from a host with one base frequency to
>>>> another host with a different base frequency, the value in CPUID leaf
>>>> 0x40000010 EAX changes and becomes the same as the destination host base
>>>> frequency instead of remaining the source base frequency.
>>>
>>> That's a bug in whatever is orchestrating the migration, and/or QEMU if QEMU is
>>> handing the upper layers a loaded footgun.
>>>
>>>> The main reason for this behaviour is that setting the TSC frequency via
>>>> ioctl(KVM_SET_TSC_KHZ) doesn't change the value in CPUID leaf 0x40000010
>>>> EAX and these two entities are still not connected.
>>>
>>> And they never will be.  It's userspace's responsibility to fill the correct
>>> values for 0x40000010.
>>>
>>> But AFAICT, QEMU does the right thing.  env->tsc_khz is used for both the CPUID
>>> leaf and for KVM_SET_TSC_KHZ.
>>>
>>> kvm_arch_init_vcpu():
>>>
>>>         c = &cpuid_data.entries[cpuid_i++];
>>>         c->function = KVM_CPUID_SIGNATURE | 0x10;
>>>         c->eax = env->tsc_khz;
>>>         c->ebx = env->apic_bus_freq / 1000; /* Hz to KHz */
>>>         c->ecx = c->edx = 0;
>>>
>>> kvm_arch_set_tsc_khz():
>>>
>>>     r = set_ioctl ?
>>>         kvm_vcpu_ioctl(cs, KVM_SET_TSC_KHZ, env->tsc_khz) :
>>>         -ENOTSUP;
>>>
>>
>> Agreed.
>> However, kvm_arch_set_tsc_khz() is also used at the end of migration
>> (qemu_loadvm_state -> cpu_synchronize_post_init).
>> So, the new value of env->tsc_khz from the source host can be loaded
>> during migration via KVM_SET_TSC_KHZ. However, the frequency in CPUID
>> leaf 0x40000010 remains the same as on the destination host (the TSC
>> frequency can differ from the source host's frequency). Thus, it's
>> possible to have unsynchronized CPUID leaf 0x40000010 when using default
>> QEMU parameters.
> 
> I don't use qemu, but isn't the qemu solution for this general
> situation to mark leaf 40000010H as 'unmigratable'?

I don't think this leaf should be unmigratable by default. I think the
same logic as for `invtsc` can be implemented:
If the TSC frequency is explicitly specified via `-cpu`, CPUID leaf
0x40000010 is migratable because `env->tsc_khz` during
`kvm_arch_init_vcpu()` on the destination host will be the same as on
the source host. But if the TSC frequency isn't specified, CPUID leaf
0x40000010 has to be omitted from `KVM_SET_CPUID2`.



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:47:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:47:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393852.1632667 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGPR-0000Og-LJ; Tue, 18 Aug 2026 09:47:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393852.1632667; Tue, 18 Aug 2026 09:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGPR-0000OZ-He; Tue, 18 Aug 2026 09:47:05 +0000
Received: by outflank-mailman (input) for mailman id 1393852;
 Tue, 18 Aug 2026 09:47:04 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwGPQ-0000OT-3c
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:47:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGPP-005ivD-GX
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:47:03 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a842a15-bab6-0a2a0a5309dd-0a2a45048d0c-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:47:03 +0200
Received: from [40.107.130.91]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a842a17-b57f-0a2a45040019-286b825bb462-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:47:03 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AMBPR03MB11696.eurprd03.prod.outlook.com (2603:10a6:20b:761::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 09:47:01 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 09:47:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=b2LTZ+NYxCiyyUTQB6dBzArHlizulz2kB4GG3NvE4GqWHbkFre4YM6QHyZ0ukLLX7AyWH+tabNXGBy1CdPXWGWxL6XEdD7cLpSw0zeHr181K7s6m3si8Uj8KaxQqLL7fuDuIcun0FRnY4LUSrzRn84cgaYC/inGMq0KNgV7NorpHKl8vTypxS3p5gfqIRI69SdReOVwX0SBlFiC3+6PVweCSDL2obExP8UlmM3IWhMCpY3V9dl+IHzxI1gkVzYDW/vfayzB+5e0Ik1jXWpiFVmS2lARrq5eUigdCjSSlP9pcogFFGHniRmJ6E5aUnpb2EnQ0MtVE3GBxpwam3MtGlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kz1gqIWWsKdIgKvBwJLn8N3sahAW1xLtDaWTiYno8Kg=;
 b=NicTafW3zGpktRtU18o4Uekz8n8eM9h2uBdz/cC0Q9YtFI8e4Kd5T43+iwm2vM3IhF1sc9SCfroV3r9lGOBlkD8NSecma1wroxfU8aR92uUT916DkCGZYg+mQ8c8PnlOy7+Sx13bgpzbk9oUQewf8eWyrobN3+Mqq+ggdGLYP3Zzx0dNJUaa+WwMqwxISLsxP8FLnag8dTjV/mIrklYa9fO+3aVC40kD9GBVVJmKNRQT5KbfVzTds4otOiLp70IIr0n1DBZU/WMM4h9AbiorlMfUL03TY7lVgq9F7sHlneer/bSz1cS+VokPP/HfgFh1SbUDyj+7DKaSBqQ8iEAKMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kz1gqIWWsKdIgKvBwJLn8N3sahAW1xLtDaWTiYno8Kg=;
 b=g3gjK90/aij5CRF09zNZD7oOHnzw51Rkn79+Y9XMwqF2BcCUIg+qN64IsQqz2AC1HYu6QZd3exLYDucvNiKspqYx+UF5ztlYa9cI+aCLzLmwe0OhWU1l0IdcQTC0aIn40IJmRG2ZbQ59nVec552YViMQuKaeuq3BZNpz1mL1LlVQtRWzlX04Yx4aUcCZC6UXFzyTtKddzVBYfzdMwfVHkUiW7CzB4eshsNhaDknk1xpmc8fzI28gxQ8hrTeO/9EfOQOhTqfKpH+y7168DvUw74yHgBc1yDrfxVFfbwYJ+KtDIXLqwlYaPyVj+5CP04yk/4ondSqfb3gukgTmoXsaJw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Date: Tue, 18 Aug 2026 12:46:57 +0300
From: Mykola Kvach <mykola_kvach@epam.com>
To: "Orzel, Michal" <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2 1/3] xen/arm: validate IRQs before descriptor lookup
Message-ID: <ug4fcrlmwbanszl2iiri5pwnpaae3o6gwinyiy2vvvjex6x522@spvoir2ps3ti>
Mail-Followup-To: "Orzel, Michal" <michal.orzel@amd.com>, 
	xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>, 
	Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <cover.1786385827.git.mykola_kvach@epam.com>
 <271952244ae71ade885b3619fe161ed4f47777fa.1786385827.git.mykola_kvach@epam.com>
 <272a8622-47c2-4cbb-a98c-8242561cbdb8@amd.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <272a8622-47c2-4cbb-a98c-8242561cbdb8@amd.com>
X-ClientProxiedBy: WA1PEPF00005B9A.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::638) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMBPR03MB11696:EE_
X-MS-Office365-Filtering-Correlation-Id: 4ccbbef7-ea33-4df5-bbd0-08defd0da719
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|18002099003|22082099003|56012099006|6133799003|5023799004|11063799006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	MQ7Roe3Mzt2iA63cG8dUpQ7I6Y5NzXJTuSumnNVUcYYP1cfxRfb3q8wH13SqZvIZ5OmbzO9cV7GOBt4D3rbGY3LO0VJP2EjfPYkwZhqQ2NVjlitcxvg4sPk09tS9g3tX9YkVpoqi6ZSkSGa4y7a4HwzyWHwJ8Sz4TXZ87SNchdb40TTRZD83fXObwePl/Q76XvFQAIH8j81+mT/YS2z5AsHtJ/H+N6QIsUtaGbDz71rCQd0NuxCfgA6H+TA2Q2n/S0woVL8XVJuuh5c6rQEyaSrwWvdWgxx4Br5/7yWlcDUZ1qNXfQJe4GGLeWniAx8fBDlZpuoN3QWVWIjhxyMNfflZnUzo31lUSoTnoZViTxXttT8c5zfZQzjrYzk9F4qQPI59nOrCCzSdy098VOI5fSoOFq2HwxwKAT7fj08Ucc2axwUSFecXPY9OEmGElx9cF3pdjmHeU7wdcnfgOzV3tbD7VAV1KaKULDp48lfnSi+YYkZdG/UoHZn7ztP+pCbFUh+oqpt6eoTOE22WxHLkov7ozgQWxhFyQm2nX2T083X24A81eiXC3EdUBfH/cNxMmR7HHb0VbyDRZ7yViKh4xztW9FitTWs48jdpTeftlzzk5ayU5ScgUynqCK2dWJ5xjDasu45VEJCorlilt6ciBfjucaHcD/qdTQueDljDbPI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(18002099003)(22082099003)(56012099006)(6133799003)(5023799004)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UDRvVkM4T0NMYTVnVjJIU0V2U3hmTDFLbnNvandGKzBidEFBZ05yakF1b3gv?=
 =?utf-8?B?KzIwamI4L0k2TmZVRjJDa3N5b3oyWHpjb1YyWGJXeDVWYndmd1ZDQ2xhQmJT?=
 =?utf-8?B?MWZkc0Q1UHh3QkgzZUkycEhBR3NYNGZLNEJ3ODlWMGQxb1dTcXd3N3Yvd2dB?=
 =?utf-8?B?WXBBU005RDRabG9OTFlaZ2wzUTlYSUM3YWh6L2M0b044czBObjRsSTRwelJu?=
 =?utf-8?B?eXZHMnNDaGdwTTBtUTU3TEozdHB2Uyt6aHhtaE5reDFyQWtxQWt3ZkVibUJN?=
 =?utf-8?B?YVlabzV5Vjk0bCt4V0g4c2JqMHVvUThBUVUwcHZEQS8rOGFsWDNWaFlmQzFE?=
 =?utf-8?B?M1F0Nkt3aVFsMnhtdkI3dkVTeC92ZmY4VWI1Uy9UbnV5NlV0bmthdFd3U2Va?=
 =?utf-8?B?Mm1zdVZlNnNWRlpvOVlsMW4vVFAwYTM1TnhiYm9yVWFBQmRGdjdKS3hTU1RU?=
 =?utf-8?B?b05URms0KzFvN3hpOFgxdXJsTm1TUlJwUDY4ZXhUSDF3aWs3TjFiVENBclVm?=
 =?utf-8?B?bjE0eTNSQ2s2emVCMVNNVjNWWndsTlpTVVE0bk0xUHhrZ2pVME5aKzZRNkVy?=
 =?utf-8?B?Z2Vkd3ZzV3FEN004KzJuYjN2MXk3RVZ6NVJGY3poZFNpUTIvNTY2WDNiN0I2?=
 =?utf-8?B?SnBicG1LOVRzVDlWcmNZSGF0a1pVRjhOand6KzRUbUpZU2Y3eEF0Y2FlZERM?=
 =?utf-8?B?aTIrRlZrY0xXUEw2S1hvMS9ESHR5Z2tZeXUxbjkrSjJOL0lhQnVhOVgySnhm?=
 =?utf-8?B?UUlxdllRZGZIRmIrbHdldERZdjkzVzFsTm9sajRhMXIzOXVwRVJBTWllTGtF?=
 =?utf-8?B?L0lueXZTZFJ2N1NLT1N3Z04rNXJqVDlSd2svY3BNV0Z2STVVSlljVkl4Z3Aw?=
 =?utf-8?B?RkhVak5SZlBuQitBSmVZQ1dLNVNHL3F6aDdoQTU4MnZGc3RzZGJqVVlGSGFQ?=
 =?utf-8?B?ZHF2ZUJyc2ViOUR3c1NxQXFpam9DL0p5MlpJL2Z6MUxGN3ZyZVl1KzVNM3hM?=
 =?utf-8?B?ZWJKbWx6VEVoUmpGYks1ejJCRzZwdEd6eEtDNWdsVHZKVW11M0phRHF0M0lu?=
 =?utf-8?B?d29tazMybG9ldVNYditOb2ZINlZ3NUxGZEkyQVdENXU2NFZCYTNDY0xublh2?=
 =?utf-8?B?d2RMSEJHSmd4UEcrNHNJMDFORVJrTFNyZW41MklERG5TLzArbFlWQ2liWWY0?=
 =?utf-8?B?K042WmdDZjZrdGhTMFBCUnlvSXhBZjl5ZVVOTHh4YXAvdHVPZTc0bU9scUlS?=
 =?utf-8?B?YWJIT2V0SUQvbFpzOVlyWHNXNWlWL2F4aURMd2RhUXdhNTBhdmVvUlFjMzYr?=
 =?utf-8?B?VG9PR2R6R094K3ppNDdqWG9NVHM2QTVSeStqRjlodDFEMi9Wb0UzRHlCbFpT?=
 =?utf-8?B?LzdrUEUxOXhhaC9reFNSSng2RlIzWmZBek1zZjJWNjAzMTNTZDJxYzJQbWFZ?=
 =?utf-8?B?ckVBQmF4T2dEYlJJL2prY01hYUtQRWlZOEtXWnB1alU0aFBVV2pEM2dDWG5j?=
 =?utf-8?B?MGtOM3l3MGozak4xVDd4T3MzMnpYUjMwVE5ZMHdEQ0ZSZWhJdzR6djFMWXQr?=
 =?utf-8?B?VjBrTWh2OXlLUnhPenUrcldvMEpIaE9IaktuSGtRNmZDZXI0eTd5QnBsMmo0?=
 =?utf-8?B?dFlCamZtRlRIeUVyOHpJd081YkVkWlI5VnZUQUhCN21sNGVqSThIaUNPV0Nz?=
 =?utf-8?B?VndxOWhJbnZTUFJmVXJ2TUZjWFlLL1RiNlRzaGFpZTdnTll3R2gxUlNxR0N4?=
 =?utf-8?B?MmtwSkNlcGJSREdqTXlFVlA4Z3hYdjIvNjcvS2lXL3AxWGpySDkwcGN3aHFS?=
 =?utf-8?B?SDJFRndaV3R1SmVQdjJrUG9Zd096TmFhZGxOekdkaHZGUWlOTUdHNjYyN2Q5?=
 =?utf-8?B?cXRQL3pSOUVWMVdVYXB4TjdkNko1c3FRTHdOd3EwUXRTcUxUcHFSbzFrTTht?=
 =?utf-8?B?ODV6OExUNzkxbTArWFNKQnFHSk8rbjU1YWlGLytxZDM5TEk2VW1NSmhieDhs?=
 =?utf-8?B?a08yT3JZdkR2NTU1eFBYKzJGSEc0VGl0MHdrMTIyMzB1VkNuUU1RVHhKV1B5?=
 =?utf-8?B?V2hLMnVvN1U5dGgxdHFVcDd0UmovQ0hIWkNkQWY4NDkyRG1DK2NQWStZR3FN?=
 =?utf-8?B?K011MC9IQkxnSi9pRnlSYVJZcEkxaGNBSUxDM2E4eXNNdVozQ2I5ZS9FWE5J?=
 =?utf-8?B?UFJWWENiUUpKTVlIVksvaFFzSDFsclpiLzlrSXNjM3pnSXdQSFJ6UHRTWUla?=
 =?utf-8?B?dlpPUUhvcHQ4bzNrR1RUQTZzcjNhdmJCNWpxeFJFTVlRVmpwRVJMMU0xTzFj?=
 =?utf-8?B?alJLaU5QemduWExXZ2dnbkxpdnIxWTJ6VVlVMlc5blNhMHJTbDhIQT09?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ccbbef7-ea33-4df5-bbd0-08defd0da719
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 09:47:01.5715
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pLM5UWn5A5/4tW/34Is7WC7vQCz2oQmZ/C33vew3Cpoe6d39d9DopNqbtLSb2BMCbXXVYKrr9MMjnjmtccG4Lw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR03MB11696
X-purgate-ID: tlsNG-ebf023/1787046423-C3AC0B50-9B7E7D29/0/0
X-purgate-type: clean
X-purgate-size: 4785

Hi Michal,

Thank you for the review.

On Tue, Aug 11, 2026 at 10:51:47AM +0200, Orzel, Michal wrote:
> 
> 
> On 10-Aug-26 20:38, Mykola Kvach wrote:
> > GICv3 eSPI support makes nr_irqs span the architectural INTID namespace
> > through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[]
> > and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs.
> > INTIDs 1024 through 4095 have no backing descriptors.
> > 
> > Validation based only on nr_irqs accepts an INTID in this gap.
> > __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or
> > update unrelated Xen memory.
> > 
> > Reject INTIDs that the GIC reports as unimplemented in setup_irq() before
> > looking up a descriptor. irq_set_spi_type() can run before the implemented
> > GIC line counts are available, so validate descriptor-backed ranges there
> > before looking up a descriptor.
> > 
> > Call is_espi() unconditionally in __irq_to_desc() and provide an
> > espi_to_desc() stub when eSPI support is disabled. This preserves the
> > is_espi() debug check for eSPI-range INTIDs when support is disabled.
> > 
> > Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range")
> > Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> > ---
> > Changes in v2:
> > - Validate descriptor-backed ranges in irq_set_spi_type().
> > - Validate implemented GIC lines in setup_irq().
> > - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled.
> > ---
> >  xen/arch/arm/irq.c | 29 ++++++++++++++++++++++++-----
> >  1 file changed, 24 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> > index 73e58a5108..0f5d3496bf 100644
> > --- a/xen/arch/arm/irq.c
> > +++ b/xen/arch/arm/irq.c
> > @@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ?
> >                                          (ESPI_MAX_INTID + 1) :
> >                                          NR_IRQS;
> >  
> > +static bool irq_has_desc(unsigned int irq)
> > +{
> > +    return irq < NR_IRQS ||
> > +           (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq));
> This IS_ENABLED reads redundant because is_espi() contains #ifdef
> CONFIG_GICV3_ESPI inside. AFAICT you added it here to prevent the !ESPI build
> from reaching ASSERT inside is_espi() when the irq is in ESPI range. I don't
> like the ASSERT inside is_espi(). I think it does not make much sense in a
> helper that should really just tell us whether the IRQ is in ESPI range or not.
> It should be up to the caller to decide what to do based on whether ESPI is
> compiled in or not. I think this cleanup would be best to be done first. If you
> don't want to do that, at least document this in the commit msg because others
> may be tempted to drop this IS_ENABLED.

Ack. I’ll add a preparatory cleanup patch making is_espi() a pure
range predicate and keep the configuration handling at the call sites.

> 
> > +}
> > +
> >  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
> >  static DEFINE_SPINLOCK(local_irqs_type_lock);
> >  
> > @@ -77,6 +83,12 @@ static int __init init_espi_data(void)
> >  }
> >  #else
> >  
> > +static struct irq_desc *espi_to_desc(unsigned int irq)
> > +{
> > +    ASSERT_UNREACHABLE();
> > +    return NULL;
> > +}
> > +
> >  static int __init init_espi_data(void)
> >  {
> >      return 0;
> > @@ -90,10 +102,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
> >      if ( irq < NR_LOCAL_IRQS )
> >          return &this_cpu(local_irq_desc)[irq];
> >  
> > -#ifdef CONFIG_GICV3_ESPI
> >      if ( is_espi(irq) )
> >          return espi_to_desc(irq);
> > -#endif
> >  
> >      return &irq_desc[irq-NR_LOCAL_IRQS];
> Nothing here covers 1024..4095. I think we should add at least:
> ASSERT(irq < NR_IRQS) like we discussed some time ago.

Ack, I’ll restore the assertion before indexing irq_desc[].

> 
> >  }
> > @@ -416,6 +426,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
> >      struct irq_desc *desc;
> >      bool disabled;
> >  
> > +    if ( !gic_is_valid_line(irq) )
> > +        return -EINVAL;
> > +
> >      desc = irq_to_desc(irq);
> >  
> >      spin_lock_irqsave(&desc->lock, flags);
> > @@ -647,13 +660,19 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new)
> >  int irq_set_spi_type(unsigned int spi, unsigned int type)
> >  {
> >      unsigned long flags;
> > -    struct irq_desc *desc = irq_to_desc(spi);
> > +    struct irq_desc *desc;
> >      int ret = -EBUSY;
> >  
> > -    /* This function should not be used for other than SPIs */
> This is an important line that you should keep.

Ack.

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:49:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:49:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393861.1632674 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGSA-0001JW-0a; Tue, 18 Aug 2026 09:49:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393861.1632674; Tue, 18 Aug 2026 09:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGS9-0001JP-U4; Tue, 18 Aug 2026 09:49:53 +0000
Received: by outflank-mailman (input) for mailman id 1393861;
 Tue, 18 Aug 2026 09:49:52 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwGS8-0001JJ-38
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:49:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGS6-006Jsg-RV
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:49:50 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a842ab7-bab6-0a2a0a5309dd-0a2a4505e55c-18
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:49:50 +0200
Received: from [40.107.130.129]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a842abe-4cb1-0a2a45050019-286b8281889a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:49:50 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AMBPR03MB11696.eurprd03.prod.outlook.com (2603:10a6:20b:761::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 09:49:49 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 09:49:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XHvy+/JEWku+UxkdzqY7knZjTtXLQrRNqbBdj1qe+bQQnRvD+B4lnxpSuTbg4usM8J9P1pYjqS/gpaphm667gGgEjnCnrKkWsQzijg9zWNXod/PJnx0HS35bPm/gTleV+0oSxD+Opa0fkj5zNATsSfWhwACkA4zK8kcXNTqdvfq/VbJRPPE6akcxxzkwX6LL5IsSxx/STCymZZpwGlBq87cnci7pOTrr+Fnj/VwWPwFzfOh8VHnF4Q7hh+s9nZSqVZnui/1GJpyVtnn4gnTNKeaqHRWAqqFQZL/dwS+6Ix1XDA+oSnql4aK5zS/acYiyATetbvBYJGNJ9evxGCC1vQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2qR6YoKQ0aQCP3DAgWuPuHk0fup3mTEUzB8mdM04Qew=;
 b=JEmLJQcS8CsnlmpuyaTgSn3vbJmUnxG/M5EHd+82jYjzOKJ62KMnvK+afZouYRMUqZiqn4nH76Zk4u0EwAXmF7OIewxXpXpnotEyW+G6eo0vQf7RlPd629MSdbSoXE/AcDSmCEa6srJDj5Gbxi5UEZ27tHpkgTw+jwV2Xx1Ap5j+pgmkUSF/jb7pK4wlxuvMKgTIRHmidRl/A4JCtGPJsc8I1t1ggHfjXK5P92ShQe/tNp5x11IRZzdNTnZOvdjX6yvVy1iXAi/d+TwLOdI+DDvhOzP9m9l36AeFhpPfJYGWq1h3YjU+kHcxQjJy3ymNbAlTPQbhGZy6BVIxn90UBA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2qR6YoKQ0aQCP3DAgWuPuHk0fup3mTEUzB8mdM04Qew=;
 b=dKAE6bVzsuV6ZG3MwjrW/aWrDtVcKfKYn5vNnwhByO8rmUpvnGpVE7MLF0GNIHZJpaaGRX36KFPRFKLwpTYbzwp+5nIkEIZCEjCLWROyfb3GlcBF9MW2fHdcnjvmEmBnbOt6Al1ifnM4WSg2oRAAVOjMXDZWjjWa2mAXDOzUunzp65RtLibfrzjr6/sGrzD4y8W8NN+QG1MdNlhYnjMI6jkIxKZk5CzVEom1aytSWdoNm88/jsSVugV09koXokUL3skzzGbAbRd538x7kcQ3jsumqMQ/g+/m9iHKSSgSpzLzNSJcwM8a24FNdbyUaGB70VqhZ6gwzIihwbD8ALm63g==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Date: Tue, 18 Aug 2026 12:49:45 +0300
From: Mykola Kvach <mykola_kvach@epam.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Anthony PERARD <anthony.perard@vates.tech>, 
	Jan Beulich <jbeulich@suse.com>, Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>, 
	Jens Wiklander <jenswi@kernel.org>
Subject: Re: [PATCH v2 3/3] xen/arm: handle irq_set_type() failures
Message-ID: <zttrpp5cd76mqlghcgrlvjbjnnw7g54cxowyaonwsdpvrbjcew@5ipae2upbvoh>
Mail-Followup-To: Andrew Cooper <andrew.cooper3@citrix.com>, 
	xen-devel@lists.xenproject.org, Stefano Stabellini <sstabellini@kernel.org>, 
	Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	Michal Orzel <michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, 
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>, Jens Wiklander <jenswi@kernel.org>
References: <cover.1786385827.git.mykola_kvach@epam.com>
 <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
 <7b2d0e8f-5c6c-4002-a123-d96c90030e54@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7b2d0e8f-5c6c-4002-a123-d96c90030e54@citrix.com>
X-ClientProxiedBy: WA0P291CA0007.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::11) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMBPR03MB11696:EE_
X-MS-Office365-Filtering-Correlation-Id: 80d894a8-5305-4202-6c8b-08defd0e0b46
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|23010399003|1800799024|366016|18002099003|22082099003|56012099006|6133799003|11063799006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	nb/kj7XwlZXr5CnIzp9Nln90DWmV6EADIN2Q7w8rBLJUsil15GQQ3sz2hZ4I+OpsWAUQ2wT3qerohgkdyUmE+jddt1MmRngmUtvdlZxevmu92UdEhGMhLb9ATbGJj36NNcdLAYuzGLxWF8yI9aQ8cuEMx8yRYr/BaOeT7NHo7162VW2QLfrbxANNWpL1g66wUBOVk1c9H6Y0kweLAhgWD6uy3JJyoBOmRET+zDR4c+rz/1awBx0WNYc3Ddgfwz2AOiJ7SwQ8dy8QBQ05AGZThbJSL6JblbDl4IE9giTCTM0ANLXZcmR4XUzX5LsIXgiX/mok86hgdZex5XisrHRXnrFAbF37HIme+Ag6CEKl8CQLwI2Qt0uDaDkcCcuCL9kISXyl73ISt23sdSI7XdWhYfnFrdsIrhMeI+uv3znwq8hdfc+5iAC7k5lW3AOxfcNJ66+cUDWVW1QFPjAVwPzZWlQ99f2dZNg57mbU6MQ07hApLiHxFQtpyYFkhQePEuKUNK6acBewBnhO/HCGR6lPPMoc8dbOfgkbXoa1MrUyKLf6puR52X3g2uAMmMNkncB76JKTgy2AB/WyNG/II3i4b6U8le3TGJhW32V6YtC4o9LIYcR0M/oINMextrf4IFW4+HfYCB+eR66paDrgXOYeZ6HMKhjom+E1uAPWlDFNRDU=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(1800799024)(366016)(18002099003)(22082099003)(56012099006)(6133799003)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SGRYekRGSkhjY2kzYzB5ZmtpNEorSTRqT2g3L3JxWGlPRTV3a0R5Q2JQcjIz?=
 =?utf-8?B?aWJNeTU3eVpkQVhsSkNTelQrajlWVy95dGNMTzlHM3lHT2Q1SFhLcWJHLzds?=
 =?utf-8?B?WHFzWUVjYkYvYktvZzJPQnhRVVA1bWlDc2I2aXd2Z3pLUXllN1lOUzNFTHQy?=
 =?utf-8?B?MW84dWtodUdGNGFxVHRoTVVkL296OHNWcFlFL0lxQVhrWVhLWElhQWxaZW03?=
 =?utf-8?B?RnJ1WnBjcGJhOVBieGJoazNQd3hNQklKQTZyUVRqOTR5MUN1alRBVjF3OXFU?=
 =?utf-8?B?bktSZ0dhb2QyNFYxdkc3aDVRNGx2dG9mSFVlV0RnSUw4OUNiME9pSkNSRk10?=
 =?utf-8?B?Qld2NXQ5MTJZeDlrQVk1d0kvbGN4aFRPSlpWWjZmUzNkOG9ZQ21XbDh0eS9E?=
 =?utf-8?B?SW9IQVkrcjFuR2lZZlN6UDNXTWlsVjZsbkFPaXplQUtIbHQxeXJCZWptT3Uw?=
 =?utf-8?B?aVcxN0xCL1BZT216aUcrQXJVbzBBRnR2OGtjQnlKNWtCUCtvQlRaTGVBTU52?=
 =?utf-8?B?UFBRUVV5TFR1QURRaGtWaVRmV0lqR0syOVI3YURJMjBaMUFwYUVGMVRlRzlx?=
 =?utf-8?B?VUI3eGc1U0ozbzBqRHQwbkJmV2l0ZkExbnV3Y2EzUkdnbyt5VlBJSXlVYlFn?=
 =?utf-8?B?eEtoaFNuS1hGS3VxT2o0Z2VRZFVwUkoyRmQ3aWtVNFgrUW10R1I2YlA5Rlk0?=
 =?utf-8?B?QThBNHJCK1JKeVNsZDhGajZQT0FuQU5MSmx1R3hLRWZnLzVkbXJjbUM4TXAy?=
 =?utf-8?B?WFpQNWEzUEpWbmFuSHlBcXFrWkVxNkNUNlUwRzY3UEdHRGp5QWVWTWhOVUhs?=
 =?utf-8?B?bTR6RzRmY09ENWR6TUo4UDBQTjlvMC9nWFMzZXdxRXE2bWVPN1V5cHJyUGZw?=
 =?utf-8?B?WGZQMFJnNzNqYWRUeW5SeGpYWTE0L1RaOVhHZGFCcFlnM0R4V3NxbnowZWs1?=
 =?utf-8?B?YURaR01JT0FHTWhJc1pPNVV3eXg4ZStYakNybG5RKzBkVERIWEg5bnVDQVda?=
 =?utf-8?B?T2QrekozRktrRUQxNUNYRVNVc1dXSHdxRGlQSG8wQm1ZNWppY21iWEhZRk8v?=
 =?utf-8?B?bnNtMk1RbTRIVjZ6VEVsaFNmYVptSUVHNnB5Ri9ZcldVODBmbVlFMzR1cTNG?=
 =?utf-8?B?VFZoNDdtWDV5cHJMT1pXbWt2ajYrQ25RaUNoOHZ2V044WWlMV0l6azJEVVhk?=
 =?utf-8?B?cFRxenl5TFhLcTQ0T3k5cnp0U0ZZRmJtWUhCUkxHS3FNUmQwcmlaejZoWVNH?=
 =?utf-8?B?c1p3RHV0TTBSNit6OGtFOGRJVUQvTnJxcFp6d2ZVZlhiUC84NG9iV0NubEZu?=
 =?utf-8?B?QWVWSTB4QUt6aXcxUUdpZTlCRmliVFQyb2o2dTFpK3pZc2NOek5mbm54TGsr?=
 =?utf-8?B?cFYxa3BzYTFlb0dIWHpIQmVZQnZQWTd2LzRSTVlYdlVQNW9BdkMvejg2ZDI5?=
 =?utf-8?B?Znc0dGZpR0dYdjhlODhqZTc5YXJDbGgreWZnZndyOVhOZ0Ewb0VpdzlUL0dO?=
 =?utf-8?B?SVVHY0kvYjArZUxGNGJxVVJiVWpwWU84MVpDOWtVQVdSUjRRV2ovQ1dISzNZ?=
 =?utf-8?B?Mk0zTUx1U1FVaUEzd2kybUUrMXd1bHg5V3ZWWEliV05FZTNKdXc2R3RjZ3ZW?=
 =?utf-8?B?RTIzR3kvV2dFbHg4Rjc2UWpjV1dldE00b290cVlFK0IvWmFGczNHc2pqNG12?=
 =?utf-8?B?eW5KbmM2cWl4N0JicTQwSjAyODZIV3didUpReUp1V1h5Q2NpczZjVUNiTzZ2?=
 =?utf-8?B?QnQxclAzR2hveCtSL1VHZC9IZEkxQkhYc005NEt6ai9pQ1pXbHFpWkd2Qmt1?=
 =?utf-8?B?VmM3M0orVUxtaFdjTXhBVHJRcEdoYXlvZ3drbGlDcVNOeGp5bkMyRVN3SFJo?=
 =?utf-8?B?TWVvY2RDL3FiY3RNRjJKUVdrblE0YVFYSzFtTGRjc3pEZDVsc3dhcERSNmRh?=
 =?utf-8?B?OC9PWTlSOUVIU2Z0aUxWZURkWHVQaTRldXZ0UC9XNlBQcVkzOWpLamVYZXdB?=
 =?utf-8?B?OTBraWZOdEcxd0d4MmN6MFFvQTJMelVLclBEMkNWN1pwVXBsbEFNaFhyOUE5?=
 =?utf-8?B?Mi9WSnIvY2RCTVNJYUVMY09LcXZ2MUdwZ09GVElBNWl1TUEzN2FOK1RBUlZ0?=
 =?utf-8?B?WVdmOEsyQTlOYkZ2dElSUTFPNnIyTW5ZVWpHYkpsakRUcHkvdnpxSVVMVUVa?=
 =?utf-8?B?OWN0VVZVT21QQ3o1TkViL0NPczV2WGl5UEhwaFNvd2VlRHh0VUFja0tQUUI4?=
 =?utf-8?B?Nk1ZdVVQNmlEekJOYUxmRk1OU05PNUE3eFA3b0FJZ1N0Wm1Xc3FldnA4VFJt?=
 =?utf-8?B?TzQ4cUFzbzJDbzdqYXRxWXdlKzlXUDdlL3UrVnBwUjJ5Z0d0N0VMdz09?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 80d894a8-5305-4202-6c8b-08defd0e0b46
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 09:49:49.5064
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RshWmSYehw8QHq80l72CpZ00UUMrEOo2vIXgjVDeqRCziQDKlwsE3i+5fDsmkZMyLp2nySH155C5T6Yvur4lkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR03MB11696
X-purgate-ID: tlsNG-c201ff/1787046590-714AC2A1-B33A7B97/0/0
X-purgate-type: clean
X-purgate-size: 2783

Hi Andrew,

Thank you for the review.

On Tue, Aug 11, 2026 at 02:01:17PM +0100, Andrew Cooper wrote:
> On 10/08/2026 7:38 pm, Mykola Kvach wrote:
> > Several Arm firmware initialization paths discard irq_set_type()'s return
> > value, violating MISRA C Rule 17.7. If trigger configuration fails,
> > initialization continues with an IRQ that was not configured as requested.
> >
> > Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store
> > timer INTIDs only after successful trigger configuration, make GTDT
> > parsing failure fatal, and stop UART or notification setup when trigger
> > configuration fails.
> >
> > Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> > ---
> > Changes in v2:
> > - new patch.
> > ---
> >  xen/arch/arm/gic-v2.c        |  8 ++++++--
> >  xen/arch/arm/gic-v3.c        |  8 ++++++--
> >  xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++-
> >  xen/arch/arm/time.c          | 18 ++++++++++++++----
> >  xen/drivers/char/ns16550.c   |  5 ++++-
> >  xen/drivers/char/pl011.c     |  4 +++-
> >  6 files changed, 43 insertions(+), 11 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > index 43a379fdda..b8dcbb0bb4 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -1157,6 +1157,7 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> >                          const unsigned long end)
> >  {
> >      static int cpu_base_assigned = 0;
> > +    int rc;
> >      struct acpi_madt_generic_interrupt *processor =
> >                 container_of(header, struct acpi_madt_generic_interrupt, header);
> >  
> > @@ -1173,9 +1174,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> >          gicv2_info.maintenance_irq = processor->vgic_interrupt;
> >  
> >          if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
> > -            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
> > +            rc = irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
> >          else
> > -            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
> > +            rc = irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
> 
> I know it was pre-existing, but this is an overly verbose way of writing:
> 
> rc = irq_set_type(gicv2_info.maintenance_irq,
>           (processor->flags & ACPI_MADT_VGIC_IRQ_MODE)
>           ? IRQ_TYPE_EDGE_BOTH
>           : IRQ_TYPE_LEVEL_MASK);
> 
> I expect the optimiser can transform behind the scenes, but it's better
> to make the C simpler for humans too.

Agreed. I'll use a single irq_set_type() call with a conditional
trigger type in both the GICv2 and GICv3 MADT paths.

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 09:51:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 09:51:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393869.1632685 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGU1-0002ov-F6; Tue, 18 Aug 2026 09:51:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393869.1632685; Tue, 18 Aug 2026 09:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGU1-0002oo-BZ; Tue, 18 Aug 2026 09:51:49 +0000
Received: by outflank-mailman (input) for mailman id 1393869;
 Tue, 18 Aug 2026 09:51:48 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwGU0-0002oi-Jp
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 09:51:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGTz-00BBLg-Mo
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:51:47 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a842b30-8faa-0a2a0a5109dd-0a2a4503d28e-14
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:51:47 +0200
Received: from [52.101.72.114]
 (helo=AM0PR02CU008.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a842b33-fae8-0a2a45030019-346548723e9b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 11:51:47 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB7319.eurprd03.prod.outlook.com (2603:10a6:20b:2b7::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.14; Tue, 18 Aug
 2026 09:51:45 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 09:51:45 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HlLXGFQ++o/9yJzw3TuHi8WH5sxDFHixrFU8d6Aa269kzerCBILNv4kTp9xpvxEKTwYWqAGxqz7ucrXfYXkR7ZPnDFIR89Y5SNuSKjV/UJ7upOYAKGA5uRllXvE+EOixUiM7a81dzYDBsuGrxQ8eWf8GDUUL2m2c1Dk08XaW1AjBFH4QwqgHB5hvRPZ+RmqhuDmT4nRd40leEZ2G8bxvCZ7xbiqnWaUuJ4CYldNtKz/c7wMSUUYCCnQ81aoQlMody8QE0nWmX5BDSKCa0JxgGrYRzCXK/fq+rgz7G3/ByCMaHCJI0/lOTp12aZI1b3H7zwcfx8fW+eeDszyRSspMuw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=++vue6zmpgd1AiBfELRsqf8M3Vb4q01LCid6m88uRVM=;
 b=Dgw4xYI+GZXDgOn81NccNbxIrkvb+RUav9lj0BV4fqeGMVc20Jvq9XSwfLXonAu5ojZQCfGnHRn3R/vKrTzRbZ5TnQhSQsDNAlrHYZIb7ahb34dcGoUxuym1MjnvMRjVn8QTKxUA1ak51IVQHVND8jgVpLYApnmQAVmNvXVVZlKzlWZl4FgKRCKIh1GCaRSV6SP0mAnkGyWulkEDZAhFz/xaWLoJ5refGgXLOkEiDPGRAhhm4ds/qoDL+G2bdrh9qSZmNIvP5xV71mbDVGTWsKGmRmJVXW1zCAvxm09wnhl1+uVnSuxoBHB35NQCTeEAQYYBIJhozF11wXE03CNbcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=++vue6zmpgd1AiBfELRsqf8M3Vb4q01LCid6m88uRVM=;
 b=i1s48JBWbH3B23gChhL0AYCNWdJjlcmStoiSwJttZd8ZW8DT9+hv4iJWSohfG+yvGO6wRsDevmLky3H/f7A9a+SIN/dpoiLzLg1hJu4PMKUptrW1tRFprzdRtBupfkspNHjuoG6U4NQG/QPpyghHpOHjW6UzdpHaV3OjYl/tPsLRjKGDiOX/7BzL16JnIdwGQTOsz9D0IrVt5kjPn2kvFFhLoxfomhGzrfXzzBzqQB9Rvoz5m9gFl/qnh2JqmdtUkYrBKEHjo83vszW7jKXu3Sk6siJ2EofiLqi0IHHXa0Bv3WE958cIvjk26hqYnjBlIDKZCsxDJopspMupJpukhw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Date: Tue, 18 Aug 2026 12:51:41 +0300
From: Mykola Kvach <mykola_kvach@epam.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, 
	Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, 
	Michal Orzel <michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, 
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>, Jens Wiklander <jenswi@kernel.org>, 
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/3] xen/arm: handle irq_set_type() failures
Message-ID: <w5cozmwr5bh2iugoslfjwxhhqlijbfcmrh2rgiu7acspysitl6@umdjbcatzf2o>
Mail-Followup-To: Jan Beulich <jbeulich@suse.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, 
	Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, 
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Anthony PERARD <anthony.perard@vates.tech>, Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>, 
	Jens Wiklander <jenswi@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1786385827.git.mykola_kvach@epam.com>
 <d4087afce93cd4bb1779507393ac74c5dd5baea3.1786385827.git.mykola_kvach@epam.com>
 <68b346b5-e4fe-455c-9f7f-f4c9d2b3ed73@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <68b346b5-e4fe-455c-9f7f-f4c9d2b3ed73@suse.com>
X-ClientProxiedBy: WA0P291CA0006.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::18) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB7319:EE_
X-MS-Office365-Filtering-Correlation-Id: 0644861c-9fc1-40bf-47fc-08defd0e508e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|4143699003|18002099003|11063799006|56012099006|22082099003|10067099003|6133799003;
X-Microsoft-Antispam-Message-Info:
	LXpNpPd6yPqxwwA43l4LxrHGolBCGk25akxYJxaE3agiI/9w+LtkQHrR851FWo6xkSecMq3JBRAvJe9zZggvlA1ouybGYzCS8OE1SZh7BdMRMCXXSHcsBOtI/7/wGs2xebmnWqbye5tPUW03vCILbEVGbCtgun2qoRaooBKmkMwcxjSUR9lYlW5uCTUF0pv7lxPlZI+HOHyx5DEKmmHiEZKUULd+s1ihDfJEDW7pPotZg5Zy1Rffd4SMtdfEpCIvrHpNB1/j1DTWHzhSvbOlA8TskOn5CDAHVksOLNmnWMpVWDWCVngEJaim/4S6j8f0K2HWlDWN/KekklU8e2Ad6FqxjiqxxJFpQzvYbkdi1wBJXm+7eDAm5Z3o11GHeyr10sFhy/ir8jWKXio5NHNRU8DLhBYlRN4MHedwnOtbEhPIkN5ypU40kaZ4xmj+x6wtb2K47f++z03rw14NcSmre13FUuFZQ/53VXY3hXgxe/QkYNQtn108Gu0PMRGe9bq1kjs0IW/rEOxgSJNwwvm5Rui/KUtxFNv9BXgtnjl9iJWmoXkzAU4lLNKZN8WwxQCHhcXJceofugLV5us8MQFPObOI8uBoHRL5CugEvmH9GRfUD3WklzQ79vwyZ3pT5vMZD9Y3k6NI/4AGkbMm57HO5KfQr75IgBoTNGDpXKa+sA4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(4143699003)(18002099003)(11063799006)(56012099006)(22082099003)(10067099003)(6133799003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dDlrdWxTOXV2UXVmNUZNNnZERWMrNWo0Sk1HNzZDeFBSV2R3WGk1VEZYQVlU?=
 =?utf-8?B?bUNnUENVY1FzWFdaMjROczRNai9NZ1I1UUptK2Q1MGsyeVpUaTVkUWhuZ2l6?=
 =?utf-8?B?KzJzdzIyeG80V2N3M0J4dlllYkJTWWtXdk1veFhpK3U5TnA2OGZINVA2eFBu?=
 =?utf-8?B?YzBsTDF3TDBQTUFDVkc5TGVqT3kzZXdGYzJ0dnJnZllESS81UVM3VVJZTnNK?=
 =?utf-8?B?MGVrNjBHRGlCVEc5QlUreFJFdkh3dWcxYTY5NHlpZWpnY3pPbk1ZUGRCRDkr?=
 =?utf-8?B?L0c0TzBCU1hLRE9Ic3U1NnY3MFlmYVNacXFTVHlYclV1b0ZWTFp6Vy93bXBw?=
 =?utf-8?B?TEpmdmJSRzJXYm9xSE8yckhmUlpGTkNMZHRxZHRBdVY2Um9hNlQydm5rZFdU?=
 =?utf-8?B?Q2Q0ZWJGY2hJZVRvVEd2eDJ3YUs1OWNXdFdlbEdNNXMyb2J1SW4vMW1KZnZX?=
 =?utf-8?B?d0s2NTRDVUxxdjl6eElyVnYxWWhNaVRGQVBrc3lPYVQ5VmQzK3ZOMi9FblE1?=
 =?utf-8?B?ZU5TcDh0djFURVdxSUVwQUJLK3hhT0ZIbVh4dk1ZcUsrb2grbno4SjJIckdX?=
 =?utf-8?B?RWVLbGlKTWFpMFJLTU1lckNRS1JKbFMwK3VDYlg1YllyQjJMaGVEblk3aU5o?=
 =?utf-8?B?VXA3eUU3THk5ODJEcnc3aXpONFp1amNSNVUwenc0SGRjKzlsVys2eGZ6eXFN?=
 =?utf-8?B?OXpyOFlRTGJObWtCWkxXem1SWUZROE94Q2E5NVU1bm5SRldnZHJWYzlydFpX?=
 =?utf-8?B?NmN6K1ppRzBFR1JaRzhjemhIT0VSV1VrMU5xNnlQWW5QUFE3Q2g4Smp1MDds?=
 =?utf-8?B?Y3pmaHdvVlRFaXhVYVd4b0toQ3BlaTFFL0JvaE1Da3o3THdwdkc0Zk9WT0J3?=
 =?utf-8?B?VkdsK3FrcU9VL0Nsa1BLYkY0b3k2NzJFY1RpeCs0TVNnNWlvNmtYek5yTEgx?=
 =?utf-8?B?bGM3Vm1aL0lCZ3RCMjEvN0ZweHd6N1AwUDZaL1NVWGRSTmlHQ29PeFlDOXhE?=
 =?utf-8?B?S2RxYnZwRWJhMzR6ZnhkVlExWkJONVIycjJRY1JWRlFuQWg5d0pmR2JRcHdn?=
 =?utf-8?B?c2xoUEhkb1doUlNtWFFFcnlrWVZmQzc3NW9oenpoc1M3MzQ3UXVLcGF2OUY1?=
 =?utf-8?B?S1lQaXZRSTFiTjBBeWpkdUdUOUpLamliZ1A0Q0x3OGZFMkJRd01XYUpXMm11?=
 =?utf-8?B?aUNZQWRRSnlZcGhNZ1Z2a2JFTHZLbHMxUTVYZnpockd5Q1RscUF3dm90cDVQ?=
 =?utf-8?B?RWVQSFJIT21HZWlCU3ljdTdqdUxaSi9OSmM4cXllaXRQNUpmcUNISDkwbzV2?=
 =?utf-8?B?TkRwZlI3Zmt3UEFxZVRuY2pjSEM4bmFtbm9ZSFNkRk9HVHFNK1dYWkhsR1ZR?=
 =?utf-8?B?Y3F1ZGdBeUs5QTh0QXNkc1BXVFk5MzlaK2dleHFhN0NCTWRPb1lJYjlYN3dj?=
 =?utf-8?B?ZFFGeFBsRlpRUmx5TlAvN2YxZk5ZelhFckFVRy9TYVdjVTA2ZW15RVRzRXoz?=
 =?utf-8?B?V1l4TFp6WHRINEtFT3h1Q1FNZS95akhpMG1uWXBXbWw0QzJOZmtGYUdZNXg1?=
 =?utf-8?B?WTFPaUl2UnppaEZDYTFSVlR3T3hzbHRkWXJLQkFQTkNRZC9Mdm5FUjBIM3lL?=
 =?utf-8?B?ZWd4SzM1Q3ZGOUZSVytHalRvQTVPdWI5MEU3UlNhd2hSNkR2Lyt3Q2ZIZlR5?=
 =?utf-8?B?NTFWWnJMbG5wSHBEWTgyejY3c3d6OGxVM1p4ZCtQRVMvQXNPdUFaTVRTSk8w?=
 =?utf-8?B?cUNXRlNwNjJadjBqekpWYnNwTWpIUm9PbWFVb2RyOTlNTmpHRkw1VmJvWmhq?=
 =?utf-8?B?OFJSaEJNRUdTY2VWK0ZpVGszSTJrcUh1R3djeERtYXJLejVyaWpmc2YzOGxH?=
 =?utf-8?B?QTRKcDk3akdvYUlMOEVVc2NkcTlRb1VHNlROeW4zdk5aK0xoaG5TcW85YkM3?=
 =?utf-8?B?ODd0YjZKak5vVjB1cnE0VlJONFdXOXZLTGF2UkFXelBUaU9BZkdGYmphSXFz?=
 =?utf-8?B?MmdjSkUyeGxFYk1DR2tDNTlaME9tZGNOWDE2eVZXaUFvVGVFNzlTcnkydTZT?=
 =?utf-8?B?MlFNa3hVdnBNMm5NUHJqZDBvbVhyVWJrVXVCeHVkeWN6WmdRKzA5UkZ4Smpa?=
 =?utf-8?B?cWZDTEhzOUZrTGtURHdmWm5qR0U4WTA4ZERqdGRmZi83TWVybnI1Nm03RWdk?=
 =?utf-8?B?MkJKeGpZQ2NtT0lWbk5CKzdETUVtYjZINEpMOHlFSWtCdnZMc2VlQXlseEJR?=
 =?utf-8?B?V0tOeW5YSzdrd1hXRmlGUFk1Mzl0TXErbVduV212aUlCbnB6VmNJL01zR0FS?=
 =?utf-8?B?Y29FTU0xV3MrVFJ3dDJFYituUXhNOFJtbk1kT2xqYi84YlZudnhHdz09?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0644861c-9fc1-40bf-47fc-08defd0e508e
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 09:51:45.7962
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9IZMTMtEOjYuQHcUYTBvY8f3AOgwPP28oJbi09rzfqjOD8+GXT0VI6qCmlcgKYWwOyc2alJelZYms0iBe9tQRA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7319
X-purgate-ID: tlsNG-33051d/1787046707-6F2C84E9-676EE359/0/0
X-purgate-type: clean
X-purgate-size: 1299

Hi Jan,

Thank you for the review.

On Wed, Aug 12, 2026 at 09:39:55AM +0200, Jan Beulich wrote:
> On 10.08.2026 20:38, Mykola Kvach wrote:
> > --- a/xen/drivers/char/ns16550.c
> > +++ b/xen/drivers/char/ns16550.c
> > @@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data)
> >      struct acpi_table_header *table;
> >      struct acpi_table_spcr *spcr;
> >      acpi_status status;
> > +    int rc;
> >      /*
> >       * Same as the DT part.
> >       * Only support one UART on ARM which happen to be ns16550_com[0].
> > @@ -1976,7 +1977,9 @@ static int __init ns16550_acpi_uart_init(const void *data)
> >      uart->reg_width = spcr->serial_port.access_width;
> >  
> >      /* The trigger/polarity information is not available in spcr. */
> > -    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> > +    rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> > +    if ( rc )
> > +        return rc;
> 
> Is erroring out still appropriate when part of ns16550_com[] was already
> modified? I.e. doesn't the call need to move up then?

Good point. Returning there can leave ns16550_com[0] partially
initialized. I'll move irq_set_type() before ns16550_init_common()
and before modifying the UART state.

Best regards,
Mykola


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:04:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:04:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393882.1632692 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGgL-00053Q-Fd; Tue, 18 Aug 2026 10:04:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393882.1632692; Tue, 18 Aug 2026 10:04:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGgL-00053J-D1; Tue, 18 Aug 2026 10:04:33 +0000
Received: by outflank-mailman (input) for mailman id 1393882;
 Tue, 18 Aug 2026 10:04:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwGgK-00053D-1s
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:04:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGgI-001zok-T6
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:04:30 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a842e24-8faa-0a2a0a5109dd-0a2a45049ede-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:04:30 +0200
Received: from [52.101.201.59]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a842e2c-b57f-0a2a45040019-3465c93b5850-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:04:30 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA5PR03MB989127.namprd03.prod.outlook.com (2603:10b6:806:4d6::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 10:04:27 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Tue, 18 Aug 2026
 10:04:26 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lRi5UG1lvM6GpnrHhvDG+8raSxfpWobc7j4g3opnU16RiEDNZxFtfqXSfIM6ffq55ewHRC9Jg2FzLiP3P8bAi+gdWPM5jcmsKNDBNoLDD0FPlCBxcItd7dtPcd/wi3lIBN+MkuSPlO8Lqqw33ygfVEkj2QtattZCQRsSewp4QRXJHntcjUufPGEV32G2IAHo+ZclffjEoMvxj2MjhyXkXz4zNRu2p6TGT/cGOROOFfjtVSoBH70czUev04ZDpbmEBUotYuLtlXSQKnHtLrgIXDwWw3/6kf4517aq9Y0bXStv+H4CRzmDSmnPZmxFLjpiXqQ88m5dDwgi60gqGsqiVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xqWtnm7A+Rwq/Adql3s205bgwPiU4RVpkU8vfIv+3eE=;
 b=GlLF9xkePx46Ajffx9h4xOpLfenHFtJJEDC5oqztw3puhI00CZ66gwUiPWXXKMoccxui/OxGOkDZflsgbKVnW0H1fVbbHNhnKk2pZzqU6vocuwGpjvgI33Ug9CibcJzo6gXWKl4RXHPVBgR/PRKkQ9KC87W7qNkMrLMlyPK7XkzRhKUOoyeDolT2QYxlbvVMZjhdoVbB28bPVmP39V/HAClWY6L5TJAy0Sed2EezrWVFahLrq0KqxWrI9rN/qY2pdw+AOKIrAP0QYxnKVcFF9F0l+FKesZp2n45Yuy8wD4knWKQwnFTFg4RAkJR5PHmulPa05R8SXLEJyhSBJb5mzw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xqWtnm7A+Rwq/Adql3s205bgwPiU4RVpkU8vfIv+3eE=;
 b=abjGVb9yR5FsiKSBAUjSwOQ96vYQU8an2KPBrdEOPwo0MRdMzzNadCVttJQIKf19o/LsuWeCJyYmodUv0h6HluD2CX9v1IbP+6f/MZMlGwPnZnP9UY856Q10aeeaTnCqAh3pHaZ2vU18AB9GMQvi3JBaI/JyMiuQhq3zlltDnR0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
Date: Tue, 18 Aug 2026 11:04:23 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, jbeulich@suse.com,
 dfaggioli@suse.com, gwd@xenproject.org
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0009.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2ad::12) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA5PR03MB989127:EE_
X-MS-Office365-Filtering-Correlation-Id: 79323816-6006-46fc-cf11-08defd10162e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|10067099003|56012099006|6133799003|22082099003|18002099003|4143699003|11063799006;
X-Microsoft-Antispam-Message-Info:
	ywoLujoIxZgykwXCYEpVkvsozdBrR9Q6X1mUMbLyOxEmfA+SCDDpB7+4eSm4Lrzi/Tgg8LkXnap6Dptnrl0/FxWNP9KXgeoYWjtHTw97KLLdqVsbplI1djXrWX3GE2RPVohgnZ58bt+wDnNlIgxQKk+Py+o54IMxAZsDktaMP4ypgmg/lY7cslqm3vSQW5bC1xVcYyJAz+tFO0u+UFWR2EUkZHCNpTydt8CAG2QGDHdzNHwzAoUuwzMipSIAbzWoaK7eTa/wLwcFpgthZcKWwsqTrYcQl6fD4vR6WTVba+0h1baHIoSyyuD9yUudxRRK4kNYUWISo30V3DmwcNm0H84i5j7krBij1IaFLumgp1Ds2UO27tS11hdi4QP8sL1RGm0gqquuca/XzXrifKFbreHIrMV+deCJbIsfsS7wGknovPEM0a69hCSz4O6rfMnPSMqLMn3U/+wZ2nDiWl/9fzhWhlxQbKuOPM2m0e9tk5Gd+7qhp/UKHmJAdLHUvqZI9vulY7tuIsbk5Oh2JxtGxaUt4WN9IAAIk1RoeljMBAi3Fqn0YQ0kooQLP8J3oC5TB7ViM9UucsocjakZ2Fnipmsrb7XwjQgQ2WlqIV1GDQHRv/ECo2YTLA2Er3bGg1SIiUrTgjA5mHHzYBpFy7R4F1gPVGPANxpy54ZljeTS7ms=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(10067099003)(56012099006)(6133799003)(22082099003)(18002099003)(4143699003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dnAyK1JFQ1JFcUtYckZEZ1FRU0lFZTZSYmNyV0NObGczOXptb0dpN2VHM0pu?=
 =?utf-8?B?RUZYLzM4Yk9GejJNbEQwZnJqbHJxZTVuT3pjb2hOUFBkdEpNL2NjNTdScFVB?=
 =?utf-8?B?SzJrT3ZFUDAzTFVBNW43RUJYbkZJa0JULys5blBDeDZkaVdQZ0hLUEpVeFVW?=
 =?utf-8?B?di95UStFNTFySW0yRmxVY0tOUFRyUGVnUVE3cXNXQ2lYV0lUU3JGeFU4WlZz?=
 =?utf-8?B?QzF4czF5eFpUaHRQdnU5ckYyeXB6MFZoanNSbHpLR0ZxNXhZRGlCSDBHYVFN?=
 =?utf-8?B?b21wZ2Ztbk0rNmR6cThuR25JTGkwTEU3Z0RIZWZSbTZaMFVGWDZ3TXNucFFN?=
 =?utf-8?B?d284WURpMWhGSUpPc0VITzBJVmp3QVcwY0QyMUFYZ2J0ZUozVGZIc0s2K01r?=
 =?utf-8?B?WEJqd2xJOGF2UjVlMUV2eGtrRWRNYmxjY2YzR3MwdGNuZkZENVNhdERJNEt3?=
 =?utf-8?B?NUFZaUVtWjlFTWxEMUhEVy82Y3N5T0lRNFFxVUw2T2VqL2lWc2dWeU5JYzV3?=
 =?utf-8?B?THFVcklzTG1PUzdudUZnemo2QW1vTUpVdHkvOVVMSkI3MXFDL0swdDlFTkMv?=
 =?utf-8?B?Z01UZzhoQU5qcnNEcHo1UVROME9uVlFUT0I4TjFreWM2djJSeWNTbk9ZeGZH?=
 =?utf-8?B?cmM0dVhwQllkbmdMRXVTZnQ2TlNRSjlyM1ZHdm5uNTNmTVdjaUh2VjE3YUxk?=
 =?utf-8?B?REJtYTMxSG15V2lUM2wxU1BRaGdYbzhXdmllYUw5MTFIbGlWd3E3UzM4YUVY?=
 =?utf-8?B?Uno1WjRjVUJmai9SODhCVXI4aTBpWURTRHZJUXgxQlg0NENsVmIxU2MxalRS?=
 =?utf-8?B?cFVBMFlLMEpVT2trRjlSTHVBbXhzZDlNUlpTMkRYeDVudHE4eWI2TURyRTNy?=
 =?utf-8?B?NFk2SW1RZUpLTlo1bm52TWNCS281VE53czIwb3Fhc3h3eHpKUWRDcXc5UnYy?=
 =?utf-8?B?QW5JbVZNeDhsMzhFMzZjbDNoRTE4QnpNWU4zeU15bGNLYk9XRUZaTk96RDA0?=
 =?utf-8?B?WGQ2cW9lVWhjVlZhVDlvcklSV3c0ZVVBMVh2bm50b1l2ejY0MjNLck9mSkVn?=
 =?utf-8?B?S1g5RVdBT2xrdzBtNGM1QTRKUWlOdWhZeWIzemtFb1AwVkNhTGRSRXZvcWVa?=
 =?utf-8?B?eERENy9Gc3hsYzQ3YmV3NjViZ0NHem1hS2tqUVBDWUoyQXExRS95a0FXQ29j?=
 =?utf-8?B?U3h4TFVVSnRKSHU5YzZ0ME9vUnJCSTd1dDNlWHRHamo0LzVOUmJXUXV3TkxP?=
 =?utf-8?B?T3pSZGVqdXo5OFhjZFVxMWpKOTNUZGpnYndZazU2azZrLy84NjFlWm44VGVh?=
 =?utf-8?B?M05OTWxLYk5Vcy9nejZ5RWhHNW9zZ0RsWkZGRG05MDJ6NjF3cXVsSFpDbjdQ?=
 =?utf-8?B?T3ZXNGlxakRoK1dBOWlVbU9Qc2NVNVVxMFRRMnZZbnQ4Sk56L2ozQlA2M0VU?=
 =?utf-8?B?Yy9BdkdGNDlNRWVuOGw5OEJtQTVMTW1ValBnRmhYeTBpbTY0b0hRUW1kRW44?=
 =?utf-8?B?Mzg2Q3NNdkZqc3h1bi9NWUVZVGpRVEIzQ2g4elVpQU1pczVROUo3UWVRU1NZ?=
 =?utf-8?B?d0E4aURXVWQyaEZyT2FOZHphSjB5L2hEeU9DUHVOc05xa3RuUXhvYU5ZcG1U?=
 =?utf-8?B?UkZkUlhRUWdiaURHQVl6YXFjRncyUU5vS0RxNmFVaDh0TUE3bU5RTVVaRVgz?=
 =?utf-8?B?TU1qOW1xejZUTU53TDhZM3BPOWVQL0UrdTFYZldRNzJMbTBUWXR0Ky93a21B?=
 =?utf-8?B?bDlNODdCclJXbU12Vm5RMUljajBadHhQS3gwTmJpTVNBNmNQRE5wcVJLU2dz?=
 =?utf-8?B?eU1kd2JLNmQ2ZFJwVGdiY1pDTklPdmZycm1YSkNBTXlzY1F4dFNKc3Qzekw4?=
 =?utf-8?B?Uy81cW1SeEcveDltVXlqNE9JWmtyWi9RSXZNOWgvRUt3V01UczN2RWVCRU9J?=
 =?utf-8?B?emlQdnlNTHJrTFdONjA2aEJhTmVLbEk4RXlzN2JLMWVReStQU3NZUWtLRjll?=
 =?utf-8?B?TUxINkRrYkdYb1FZQ1Yva1hUdjJzM0tMVjNEUVVUS09oVDhzSTF0SStMUFQz?=
 =?utf-8?B?aEpkMjVWNGw3T0xKeGhlQVBWNUp2QlZZbEw2WmNQc1FXS3ZZaE56WUFQMFdY?=
 =?utf-8?B?VmdPT1E2VDc2U2xhNDVpM0lyTFlhWnc2WXlIRC9wR3hQZWdaREVtQUN3MjFu?=
 =?utf-8?B?R09GMUxQa1FvNzMvditXVVhIbUNTMGlrdjhua3dhZWRNNkgzMHdkZjR6TG9r?=
 =?utf-8?B?K1FoQXg4UVoveGxqVndzM1B6RXJUTm9qSWZuMURiK2YxVVpOck12eUVjUkFt?=
 =?utf-8?B?dmRoeFBXWUZZczdYZXJ6UVBja2hkd2Ftem9vS3hjeVdSN1ZMSTBXQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79323816-6006-46fc-cf11-08defd10162e
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 10:04:26.8464
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: frtIyXmsLQ9UsIFY84Nq7mQi2cZJP+ETaOYPmxHvM82M0d4rO99p7ShT5avOciNT0f9w9Q3yI1/zyTIbMAXJgWyqVU370EUxX5Ifb3Ryflo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PR03MB989127
X-purgate-ID: tlsNG-ebf023/1787047470-583C0B50-A731A666/0/0
X-purgate-type: clean
X-purgate-size: 4296

On 18/08/2026 8:53 am, Furkan Çalışkan wrote:
> On 8/18/26 10:11, Jürgen Groß wrote:
>> On 18.08.26 08:32, Furkan Caliskan wrote:
>>> sched_move_domain() derives the number of units to rebuild from
>>> d->max_vcpus, which is fixed at domain creation and never rolled
>>> back if vcpu_create() fails partway through building a domain. So
>>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>>> counts it - this happens if sched_alloc_udata() returns NULL.
>>>
>>> The per-unit loop doesn't check for this: it sets
>>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>>> unit straight to the destination scheduler's alloc_udata(),
>>> which assumes vcpu_list is always valid and crashes Xen when
>>> it is not.
>>>
>>> Reproduced by building a domain in a non-default cpupool where
>>> vcpu creation fails partway through, then destroying it.
>>> domain_kill() moves the domain back to the default cpupool via
>>> sched_move_domain() before actually destroying it, crashing
>>> inside the destination scheduler's alloc_udata() (seen in
>>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>>
>>> Before building a unit in sched_move_domain(), check that all of
>>> its vcpu slots are populated, and skip it if any are missing. The
>>> rest of the function walks the vcpus that actually exist, via
>>> for_each_vcpu() rather than n_units, so skipping a unit here
>>> does not leave anything else out of sync.
>>>
>>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>>> ---
>>>   xen/common/sched/core.c | 19 +++++++++++++++++++
>>>   1 file changed, 19 insertions(+)
>>>
>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>>> index d3a0a97e1d..d542c76543 100644
>>> --- a/xen/common/sched/core.c
>>> +++ b/xen/common/sched/core.c
>>> @@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>>>         for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>>       {
>>> +        /*
>>> +         * Skip this unit if any of its vcpus is missing. Bounded by
>>> +         * max_vcpus.
>>> +         */
>>> +        bool vcpu_failed = false;
>>> +
>>> +        for ( unsigned int i = 0;
>>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>>> +        {
>>> +            if ( !d->vcpu[unit_idx * gran + i] )
>>> +            {
>>> +                vcpu_failed = true;
>>> +                break;
>>> +            }
>>> +        }
>>> +
>>> +        if ( vcpu_failed )
>>> +            continue;
>> I don't think this is correct.
>>
>> If there are some vcpus in the unit you will loose them (i.e. make them no
>> longer be able to be scheduled), right?
>>
>> For a dying domain this might be okay, but not for one still active. So I think
>> you should at least verify the domain is dying, otherwise sched_move_domain()
>> should just fail.
>>
>> An alternative might be to fix the NULL dereferencing where needed, but this
>> could become tedious.
>>
>>
>> Juergen
> Right. My initial attempt only checked 'd->vcpu[unit_idx*gran]'
> for the head vCPU. The crash happens when unit->vcpu_list is set
> to d->vcpu[unit_idx*gran] (which is NULL) and passed to 'alloc_udata()',
> causing a NULL dereference. 
>
> I expanded the loop over 'gran' to handle core-scheduling cases where a 
> subsequent vCPU fails mid-unit, but as you pointed out, that drops the 
> whole unit for active domain.
>
> I'll update the patch to check d->is_dying to skip incomplete units 
> only for dying domains, and have sched_move_domain() fail if an active 
> domain has missing vCPUs

I'm afraid that wont fix everything.

Your scenario is rare, but sadly we have no interlock to kill the domain
if a setmaxvcpus hypercall finishes mid-way through.  Furthermore, for
dom0 at least, we actively do want to run in this configuration if we
end up in it, because that at least helps recovery of the system.

At all points in a domain's lifecycle, d->vcpu[0..max_vcpus] may be
NULL, and we may even want to schedule in this scenario.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:14:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:14:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393891.1632702 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGpH-00078a-BY; Tue, 18 Aug 2026 10:13:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393891.1632702; Tue, 18 Aug 2026 10:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGpH-00078T-8A; Tue, 18 Aug 2026 10:13:47 +0000
Received: by outflank-mailman (input) for mailman id 1393891;
 Tue, 18 Aug 2026 10:13:45 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwGpF-00078N-Le
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:13:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGpE-005o81-F0
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:13:44 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a84304c-bab6-0a2a0a5309dd-0a2a4503c996-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:13:44 +0200
Received: from [209.85.218.53] (helo=mail-ej1-f53.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a843058-fae8-0a2a45030019-d155da35b850-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:13:44 +0200
Received: by mail-ej1-f53.google.com with SMTP id
 a640c23a62f3a-c20e70a0962so583944366b.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 03:13:44 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a3d8596435sm1518244a12.20.2026.08.18.03.13.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 03:13:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787048024; x=1787652824; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=t8r6c7UhsU8GKVZQ8YLSiHdWTlDTRxcwRsc+LFXj+kU=;
        b=Rwew15p5kacUwJsx3uZMmIsAoJvJ36APr9nurMO+QwIOJnnJfKhhLoCg7ad6XScpHs
         sCmk2miVQtvKkhlYgHRbN0x5IF19x/SKZP6bzexBTcxbkORqBGj/2LOiFMBb0F1gfAmQ
         qWgXEPA8pIUk+O/Xf2h7Minr2A8CuUERQ15yhmY7+L0Qk7/JiS9MvFRJgxtHIXUHo+fd
         Nfyv6q40Q7FoTTcewWASvTeE+Uy3i/Sx298QOkLd/uGjkwUQDiWf1QkCm+aL6ldho0go
         8sMYUroJwmn3qDBkjxYzrpBbfDRPIif8sfxyEVwOhRLb27rEpx3ej43k48ackO1Mb1QL
         gaHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787048024; x=1787652824;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=t8r6c7UhsU8GKVZQ8YLSiHdWTlDTRxcwRsc+LFXj+kU=;
        b=n3yQoifrpEkzO48iQ0cGniolUc5W1Sjy8bAV4FrqppSRi0LvXARlPsLR/6INi2UJHo
         aGs7VLQtikTyW8U46d6A+b87VRhyZuDA40W4KMgVHvVDir8Y0CAIXryTEbhJHDn4WmRY
         1GDD1KLolZELYVx/8WgCaHvGDphhlj6QLM6kRnQ/K2Etyh4sOY47m+ctQb9kjY41qkzH
         DIWqVPD4k9KUhPCqXzHIpxPYWy+Rkxoc8PW3JekwtJjKC0mgOtqboxBzlV8nwhYSeDZ1
         En4KcuiqhteQenAZtxo9dEQfHcgiz1AfPiiak5avTTegWkcNAbcIsMgsVJpD5FDOCojC
         vxtQ==
X-Forwarded-Encrypted: i=1; AHgh+Rru+nA+8B+mZi++OIy7ljPXPlC6QRFHts7xaVZydTDtS8fCsX7Ai5NvdSUyMi3etKmO2AetMdOAhnY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLpYhbJoOCq2sUcxlSFyN7/1U0k3Qk7pCWsHawGJfE5in+dBx8
	SZ8rycmFj1QuWAS3a3rObvVvRmWKnccqbs/w5g3i59ExBsglX6Qt9En1rARzhbKb2o4=
X-Gm-Gg: AR+sD11+qeYscQMH68ThCAKrabsncT0LA6w8xJnAGK12GeKGL2RSJwJw8mfrB8KfJlf
	ubOxIzgXFTCr57yBnPQPDzzRAWrZehqflH7+W8SHLjP7pF0Hrd6WJ+hiT0xh9jsPxwnUpEFdrjd
	ofcV0FfMhE1K37iuMCfKYLuQO8Y916NLnsVXCELu94qs+dvztyUKgt3PybYvFQr0nvbFpRRhY1U
	1n3ldN0F/hoBPeGBOrxCoz+Ken9C/kcLsqxUxMtrdAfKenCCW8lzsbk1FYsDqDXrwhe5ng+hYGq
	69FPo2afoYRF9KXkgCzecycvZ3nzZtkBen6MEDruyuIKi/fDHjikgU/4tg8NaOgkgeHIRpx8I5t
	weNNWhYFqWF6DsIeSNDrC1G/eGv8b9wImn3HUUvJt29EkV8x+81gsOj5xcLRtr30FW4Be07QsAo
	XgBHOe+iFTTm3i24rXp0Tnfg3oo4Z6c2eDdIkPAc/SCPBjudB8kYM78Cm2XZYhh7KzffdHN1cHd
	t30VmHeRy5DVkS/1gJ/WtFUEXK5/QauOtAM+xaNn+vrvxvm3c1JvuKSKOse77Ec00ggMGJ3erTc
	S1k2HG4ahUyXkQ==
X-Received: by 2002:a17:907:6b05:b0:c20:74db:50c7 with SMTP id a640c23a62f3a-c21885150damr446451666b.13.1787048023539;
        Tue, 18 Aug 2026 03:13:43 -0700 (PDT)
Message-ID: <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
Date: Tue, 18 Aug 2026 12:13:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Og4p1i93BPivoCxW76jncXBj"
X-purgate-ID: tlsNG-33051d/1787048024-6F0C94E9-A741D20D/0/0
X-purgate-type: clean
X-purgate-size: 13970

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Og4p1i93BPivoCxW76jncXBj
Content-Type: multipart/mixed; boundary="------------Jl1Ur1M09zZ0jOUw6VMaiPnv";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org
Message-ID: <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
In-Reply-To: <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------Jl1Ur1M09zZ0jOUw6VMaiPnv
Content-Type: multipart/mixed; boundary="------------c0FZ40kblfKT6yQODYUd7hlP"

--------------c0FZ40kblfKT6yQODYUd7hlP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTguMDguMjYgMTI6MDQsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IE9uIDE4LzA4LzIw
MjYgODo1MyBhbSwgRnVya2FuIMOHYWzEscWfa2FuIHdyb3RlOg0KPj4gT24gOC8xOC8yNiAx
MDoxMSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+PiBPbiAxOC4wOC4yNiAwODozMiwgRnVy
a2FuIENhbGlza2FuIHdyb3RlOg0KPj4+PiBzY2hlZF9tb3ZlX2RvbWFpbigpIGRlcml2ZXMg
dGhlIG51bWJlciBvZiB1bml0cyB0byByZWJ1aWxkIGZyb20NCj4+Pj4gZC0+bWF4X3ZjcHVz
LCB3aGljaCBpcyBmaXhlZCBhdCBkb21haW4gY3JlYXRpb24gYW5kIG5ldmVyIHJvbGxlZA0K
Pj4+PiBiYWNrIGlmIHZjcHVfY3JlYXRlKCkgZmFpbHMgcGFydHdheSB0aHJvdWdoIGJ1aWxk
aW5nIGEgZG9tYWluLiBTbw0KPj4+PiBkLT52Y3B1W2ldIGNhbiBiZSBOVUxMIGZvciBzb21l
IGkgZXZlbiB0aG91Z2ggbWF4X3ZjcHVzIHN0aWxsDQo+Pj4+IGNvdW50cyBpdCAtIHRoaXMg
aGFwcGVucyBpZiBzY2hlZF9hbGxvY191ZGF0YSgpIHJldHVybnMgTlVMTC4NCj4+Pj4NCj4+
Pj4gVGhlIHBlci11bml0IGxvb3AgZG9lc24ndCBjaGVjayBmb3IgdGhpczogaXQgc2V0cw0K
Pj4+PiB1bml0LT52Y3B1X2xpc3QgPSBkLT52Y3B1W3VuaXRfaWRdIChOVUxMKSBhbmQgaGFu
ZHMgdGhhdCBicm9rZW4NCj4+Pj4gdW5pdCBzdHJhaWdodCB0byB0aGUgZGVzdGluYXRpb24g
c2NoZWR1bGVyJ3MgYWxsb2NfdWRhdGEoKSwNCj4+Pj4gd2hpY2ggYXNzdW1lcyB2Y3B1X2xp
c3QgaXMgYWx3YXlzIHZhbGlkIGFuZCBjcmFzaGVzIFhlbiB3aGVuDQo+Pj4+IGl0IGlzIG5v
dC4NCj4+Pj4NCj4+Pj4gUmVwcm9kdWNlZCBieSBidWlsZGluZyBhIGRvbWFpbiBpbiBhIG5v
bi1kZWZhdWx0IGNwdXBvb2wgd2hlcmUNCj4+Pj4gdmNwdSBjcmVhdGlvbiBmYWlscyBwYXJ0
d2F5IHRocm91Z2gsIHRoZW4gZGVzdHJveWluZyBpdC4NCj4+Pj4gZG9tYWluX2tpbGwoKSBt
b3ZlcyB0aGUgZG9tYWluIGJhY2sgdG8gdGhlIGRlZmF1bHQgY3B1cG9vbCB2aWENCj4+Pj4g
c2NoZWRfbW92ZV9kb21haW4oKSBiZWZvcmUgYWN0dWFsbHkgZGVzdHJveWluZyBpdCwgY3Jh
c2hpbmcNCj4+Pj4gaW5zaWRlIHRoZSBkZXN0aW5hdGlvbiBzY2hlZHVsZXIncyBhbGxvY191
ZGF0YSgpIChzZWVuIGluDQo+Pj4+IENyZWRpdDIncyBjc2NoZWQyX2FsbG9jX3VkYXRhKCkg
LT4gaXNfaWRsZV91bml0KCkgLT4gTlVMTCBkZXJlZikuDQo+Pj4+DQo+Pj4+IEJlZm9yZSBi
dWlsZGluZyBhIHVuaXQgaW4gc2NoZWRfbW92ZV9kb21haW4oKSwgY2hlY2sgdGhhdCBhbGwg
b2YNCj4+Pj4gaXRzIHZjcHUgc2xvdHMgYXJlIHBvcHVsYXRlZCwgYW5kIHNraXAgaXQgaWYg
YW55IGFyZSBtaXNzaW5nLiBUaGUNCj4+Pj4gcmVzdCBvZiB0aGUgZnVuY3Rpb24gd2Fsa3Mg
dGhlIHZjcHVzIHRoYXQgYWN0dWFsbHkgZXhpc3QsIHZpYQ0KPj4+PiBmb3JfZWFjaF92Y3B1
KCkgcmF0aGVyIHRoYW4gbl91bml0cywgc28gc2tpcHBpbmcgYSB1bml0IGhlcmUNCj4+Pj4g
ZG9lcyBub3QgbGVhdmUgYW55dGhpbmcgZWxzZSBvdXQgb2Ygc3luYy4NCj4+Pj4NCj4+Pj4g
U2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29t
Pg0KPj4+PiAtLS0NCj4+Pj4gIMKgIHhlbi9jb21tb24vc2NoZWQvY29yZS5jIHwgMTkgKysr
KysrKysrKysrKysrKysrKw0KPj4+PiAgwqAgMSBmaWxlIGNoYW5nZWQsIDE5IGluc2VydGlv
bnMoKykNCj4+Pj4NCj4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWQvY29yZS5j
IGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4+Pj4gaW5kZXggZDNhMGE5N2UxZC4uZDU0
MmM3NjU0MyAxMDA2NDQNCj4+Pj4gLS0tIGEveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4+
Pj4gKysrIGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4+Pj4gQEAgLTc0NSw2ICs3NDUs
MjUgQEAgaW50IHNjaGVkX21vdmVfZG9tYWluKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBj
cHVwb29sICpjKQ0KPj4+PiAgwqAgwqDCoMKgwqDCoCBmb3IgKCB1bml0X2lkeCA9IDA7IHVu
aXRfaWR4IDwgbl91bml0czsgdW5pdF9pZHgrKyApDQo+Pj4+ICDCoMKgwqDCoMKgIHsNCj4+
Pj4gK8KgwqDCoMKgwqDCoMKgIC8qDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgICogU2tpcCB0
aGlzIHVuaXQgaWYgYW55IG9mIGl0cyB2Y3B1cyBpcyBtaXNzaW5nLiBCb3VuZGVkIGJ5DQo+
Pj4+ICvCoMKgwqDCoMKgwqDCoMKgICogbWF4X3ZjcHVzLg0KPj4+PiArwqDCoMKgwqDCoMKg
wqDCoCAqLw0KPj4+PiArwqDCoMKgwqDCoMKgwqAgYm9vbCB2Y3B1X2ZhaWxlZCA9IGZhbHNl
Ow0KPj4+PiArDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoCBmb3IgKCB1bnNpZ25lZCBpbnQgaSA9
IDA7DQo+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpIDwgZ3JhbiAmJiB1bml0
X2lkeCAqIGdyYW4gKyBpIDwgZC0+bWF4X3ZjcHVzOyBpKysgKQ0KPj4+PiArwqDCoMKgwqDC
oMKgwqAgew0KPj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoICFkLT52Y3B1W3Vu
aXRfaWR4ICogZ3JhbiArIGldICkNCj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgew0K
Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZjcHVfZmFpbGVkID0gdHJ1
ZTsNCj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+Pj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfQ0KPj4+PiArwqDCoMKgwqDCoMKgwqAgfQ0KPj4+
PiArDQo+Pj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIHZjcHVfZmFpbGVkICkNCj4+Pj4gK8Kg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgY29udGludWU7DQo+Pj4gSSBkb24ndCB0aGluayB0aGlz
IGlzIGNvcnJlY3QuDQo+Pj4NCj4+PiBJZiB0aGVyZSBhcmUgc29tZSB2Y3B1cyBpbiB0aGUg
dW5pdCB5b3Ugd2lsbCBsb29zZSB0aGVtIChpLmUuIG1ha2UgdGhlbSBubw0KPj4+IGxvbmdl
ciBiZSBhYmxlIHRvIGJlIHNjaGVkdWxlZCksIHJpZ2h0Pw0KPj4+DQo+Pj4gRm9yIGEgZHlp
bmcgZG9tYWluIHRoaXMgbWlnaHQgYmUgb2theSwgYnV0IG5vdCBmb3Igb25lIHN0aWxsIGFj
dGl2ZS4gU28gSSB0aGluaw0KPj4+IHlvdSBzaG91bGQgYXQgbGVhc3QgdmVyaWZ5IHRoZSBk
b21haW4gaXMgZHlpbmcsIG90aGVyd2lzZSBzY2hlZF9tb3ZlX2RvbWFpbigpDQo+Pj4gc2hv
dWxkIGp1c3QgZmFpbC4NCj4+Pg0KPj4+IEFuIGFsdGVybmF0aXZlIG1pZ2h0IGJlIHRvIGZp
eCB0aGUgTlVMTCBkZXJlZmVyZW5jaW5nIHdoZXJlIG5lZWRlZCwgYnV0IHRoaXMNCj4+PiBj
b3VsZCBiZWNvbWUgdGVkaW91cy4NCj4+Pg0KPj4+DQo+Pj4gSnVlcmdlbg0KPj4gUmlnaHQu
IE15IGluaXRpYWwgYXR0ZW1wdCBvbmx5IGNoZWNrZWQgJ2QtPnZjcHVbdW5pdF9pZHgqZ3Jh
bl0nDQo+PiBmb3IgdGhlIGhlYWQgdkNQVS4gVGhlIGNyYXNoIGhhcHBlbnMgd2hlbiB1bml0
LT52Y3B1X2xpc3QgaXMgc2V0DQo+PiB0byBkLT52Y3B1W3VuaXRfaWR4KmdyYW5dICh3aGlj
aCBpcyBOVUxMKSBhbmQgcGFzc2VkIHRvICdhbGxvY191ZGF0YSgpJywNCj4+IGNhdXNpbmcg
YSBOVUxMIGRlcmVmZXJlbmNlLg0KPj4NCj4+IEkgZXhwYW5kZWQgdGhlIGxvb3Agb3ZlciAn
Z3JhbicgdG8gaGFuZGxlIGNvcmUtc2NoZWR1bGluZyBjYXNlcyB3aGVyZSBhDQo+PiBzdWJz
ZXF1ZW50IHZDUFUgZmFpbHMgbWlkLXVuaXQsIGJ1dCBhcyB5b3UgcG9pbnRlZCBvdXQsIHRo
YXQgZHJvcHMgdGhlDQo+PiB3aG9sZSB1bml0IGZvciBhY3RpdmUgZG9tYWluLg0KPj4NCj4+
IEknbGwgdXBkYXRlIHRoZSBwYXRjaCB0byBjaGVjayBkLT5pc19keWluZyB0byBza2lwIGlu
Y29tcGxldGUgdW5pdHMNCj4+IG9ubHkgZm9yIGR5aW5nIGRvbWFpbnMsIGFuZCBoYXZlIHNj
aGVkX21vdmVfZG9tYWluKCkgZmFpbCBpZiBhbiBhY3RpdmUNCj4+IGRvbWFpbiBoYXMgbWlz
c2luZyB2Q1BVcw0KPiANCj4gSSdtIGFmcmFpZCB0aGF0IHdvbnQgZml4IGV2ZXJ5dGhpbmcu
DQoNCldoeSBub3Q/DQoNCj4gWW91ciBzY2VuYXJpbyBpcyByYXJlLCBidXQgc2FkbHkgd2Ug
aGF2ZSBubyBpbnRlcmxvY2sgdG8ga2lsbCB0aGUgZG9tYWluDQo+IGlmIGEgc2V0bWF4dmNw
dXMgaHlwZXJjYWxsIGZpbmlzaGVzIG1pZC13YXkgdGhyb3VnaC7CoCBGdXJ0aGVybW9yZSwg
Zm9yDQo+IGRvbTAgYXQgbGVhc3QsIHdlIGFjdGl2ZWx5IGRvIHdhbnQgdG8gcnVuIGluIHRo
aXMgY29uZmlndXJhdGlvbiBpZiB3ZQ0KPiBlbmQgdXAgaW4gaXQsIGJlY2F1c2UgdGhhdCBh
dCBsZWFzdCBoZWxwcyByZWNvdmVyeSBvZiB0aGUgc3lzdGVtLg0KDQpJdCBpcyBvbmx5IGFi
b3V0IG1vdmluZyBhIGRvbWFpbiB0byBhbm90aGVyIGNwdXBvb2wuIERvbTAgY2FuJ3QgYmUg
bW92ZWQNCmFueXdheSwgYW5kIG5vdCBiZWluZyBhYmxlIHRvIG1vdmUgYSBjcmlwcGxlZCBk
b21haW4gaXMgYmV0dGVyIHRoYW4gYSBjcmFzaC4NCg0KU28gd2hhdCBpcyB0aGUgcHJvYmxl
bSB0aGVuPw0KDQoNCkp1ZXJnZW4NCg==
--------------c0FZ40kblfKT6yQODYUd7hlP
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------c0FZ40kblfKT6yQODYUd7hlP--

--------------Jl1Ur1M09zZ0jOUw6VMaiPnv--

--------------Og4p1i93BPivoCxW76jncXBj
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqEMFYFAwAAAAAACgkQsN6d1ii/Ey8r
bQf/Z5E+0/cJmkeOmPt7jKseymoUz50PBpI11Ip/ZdG7adkZ3fe/738Mrr/Ik353zxKTsqD8F+cf
Nl+CSQEF7efkWIL9cjUGdaQds5Ck3BuAdHoYja8oomK8jLqo+/mMbFmYkUFnaHUbYmphjT3zaBr+
R1VTZr7AJ747gBA1lQa+hfa5vjxMRGhX7v3Z3C2rm32FXyq3uUq9n+f8cCktAwi2WUR3NRhV9djX
OULQiS8rz8i2RNOiU+eaN1VEFvYnxFMhKap+VpzeoqGITTXsiRf8/e8MnKfnoa38JekiN5REETLI
X5deagQQ+e3J46FFJjyvqCjivSxXdBAZwqRqrn3r1Q==
=NEn8
-----END PGP SIGNATURE-----

--------------Og4p1i93BPivoCxW76jncXBj--


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:18:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:18:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393901.1632712 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGtj-0007zT-0H; Tue, 18 Aug 2026 10:18:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393901.1632712; Tue, 18 Aug 2026 10:18:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwGti-0007zM-Sc; Tue, 18 Aug 2026 10:18:22 +0000
Received: by outflank-mailman (input) for mailman id 1393901;
 Tue, 18 Aug 2026 10:18:21 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwGth-0007zG-1w
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:18:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwGtg-002HTj-Ez
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:18:20 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a843168-bab6-0a2a0a5309dd-0a2a4506b4aa-14
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:18:20 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84316c-195a-0a2a45060019-d155dd2eb98e-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:18:20 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47f84023916so4225826f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 03:18:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a31543sm11741005f8f.4.2026.08.18.03.18.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 03:18:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787048300; x=1787653100; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=2Jv2vcgIzhDSmZQdCY7vbZsbKDES6306ZvajYTMAiBU=;
        b=C+rPJVZ62Ldqeejk6YtTzTFGwXu87mIWZ+k5syTTh1Mrb5JMwS7rBhOz4GhX7VrFOI
         zyjLMdlB0ELtcRgMF+AvDFKT6Brcm0vMlQyNQt/eMKluJ+8pTgPQh7ENkQ/LEH1VTDCl
         G1sgSvJ9JOp0Ad7j7g2hDUeg0DuLjfXIGVHt81fan8R/HB004nhGeuZ9rkJBSs1WXQMU
         dDXtJTWbIcXXsH8vtf+7cn5MC+arskv46csbcqT89Jrr/GqiMx58y1+uURXPntUpCl5l
         4nD+atkOh/DWxAy0WLpJdP6BukfRD+aX06lE2DQjvPatFeUOUH42QiStewR4Kt3caku4
         q46Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787048300; x=1787653100;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=2Jv2vcgIzhDSmZQdCY7vbZsbKDES6306ZvajYTMAiBU=;
        b=USBaD7KJomYrriCxfxcOu/29AgXfQtxdZGbyjaMqozO5ro0RvGo0Hdl2Fdh5l8z7om
         jho5aCxb6r+ZZE1rI7rEuptODFJct0a6ingklkvsYzOzS0q7RrUAu9pVdhJn8wUBvXvS
         B6RhcKWY4C+K4xnyW0OYfgVpfnmc3stxXzhWS84NfXvfHlyzMucwPUDHuIkkroQaq68Y
         uDjlXo0DFfblhoPc33olo9Pa/6pnxb0rqByZ4qPX+WRSQWC0o0tNC38mUnKYZbbANuSk
         5SoXr0vU0o+SthgCoL3NdA8b8JgmVZBSenjOZe4pNf7ZTQ9mDYtRmJbsLULLbZmbxZsz
         xo8Q==
X-Forwarded-Encrypted: i=1; AHgh+RojrnL+AnWgUJkeOs2ZOX20UbrOC8i4IC5gPgSYUa6rUgbtz3a3ROsV/8ZQ2n7tooFQdXpEtonX5Ds=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJSzm7/G4oCIAENjK0VU9EqEhv2JdOmR20CQpsNSdndXFECO9C
	L9XrptC6BXHQMG9Lm146Dv9svOKVVz2iUEWyPVyv30WE1Xd6OlzcFB1uwq612jilpg==
X-Gm-Gg: AR+sD11ptJrAb5ptc7I6VeFpLA90mxI4QAFWm8WT/kiy66/j192yaWS1xxvohY0bqaI
	8kvvutWC8lx4k3sZSM1WZDGGiS5zgyTKruXuc23s8BJy7ISC8thcI2uFr9zScUZ4nQDdqeSfU6Y
	RH15zsCFxcwS0QEd3ytyqDkBJIXHAsdAGtCKS3sNt1qW98zy6PVuul4+TIlthCdjQAGaf44pdeZ
	DUsv691wkZe6OHvB0lzPupas/asdFI7f7u/XmronTTD9BGpJrMR4NpFxvmD0JlKJoHEtyO8C2yw
	4f7DNr162IoRO51FZCGsyDPPBAeQ2012Q2fqZfPXiJMmQ5jc2MM4edMwU1obh2o5F4bFJgIkcLX
	/vaTsqlb+6DHP3M+W/a++DSBSPSwVdmjRmpAajFauWLJ+SejSeiUvhgqjipcKXIMop2iRr8QEwX
	G4+t+VO3hk6ms0PCo9y+5VQQwaAsBlweW96WThnaoEmft2+YlsF1qI0MlbaLTQSl4E43gU4qPVi
	tGHYZxqGeX9s1Sx4Ydv9H86pQq6z8up6cDiWQ5ozcsZrRA5mQOU
X-Received: by 2002:a5d:5482:0:b0:482:a36c:a5e1 with SMTP id ffacd0b85a97d-482a905b0a1mr9828744f8f.1.1787048299675;
        Tue, 18 Aug 2026 03:18:19 -0700 (PDT)
Message-ID: <0fe5fa72-e10c-41c1-8f4c-749cf241bf29@suse.com>
Date: Tue, 18 Aug 2026 12:18:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 16/20] xen/riscv: implement IRQ routing for device
 passthrough
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <cbbaea00bd461284f6440dbd11653a64f7434b94.1785836421.git.oleksii.kurochko@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <cbbaea00bd461284f6440dbd11653a64f7434b94.1785836421.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787048300-F627077B-A4E8ECE6/10/73395122804
X-purgate-type: spam
X-purgate-size: 17395

On 04.08.2026 17:48, Oleksii Kurochko wrote:
> dom0less device passthrough requires granting guest domains access to
> device interrupts. Introduce map_device_irqs_to_domain() to enumerate
> a DT node's interrupt properties, skipping those not owned by
> the primary interrupt controller (as at the moment I haven't seen usages
> of it), and map_irq_to_domain() to grant domain access and configure
> Xen's interrupt descriptor accordingly. Sharing IRQ between domains is
> rejected.
> 
> Both map_irq_to_domain() and map_device_irqs_to_domain() are marked
> __overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to
> __init, so the functions are init-only and need no XSM check; with
> CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime
> entry point is dt_overlay_domctl(), which performs the XSM checks at the
> domctl layer.  RISC-V does not wire up DT overlay yet, so today these are
> strictly __init; if/when overlay support is added, the domctl-level XSM
> gating must be added together with it, as on Arm.
> 
> route_irq_to_guest() and release_irq() manage irq_desc ownership for
> guest-assigned interrupts. Each assignment carries a small irq_guest
> structure as irqaction::dev_id, recording the owning domain and virtual
> IRQ number which is 1:1 mapped to physical IRQ number. A per-domain
> vIRQ allocation bitmap (used_irqs in struct vintc), managed by
> vintc_reserve_virq(), prevents the same vIRQ being claimed twice.
> 
> Host and guest interrupts may differ in some operations (EOI timing in
> particular, possibly others): a host IRQ is completed once Xen's handler
> runs, whereas a passthrough IRQ must defer the physical completion until
> the guest issues its own EOI, otherwise a still-asserted level line would
> immediately retrigger and storm. This affects only the .end callback;
> the rest of hw_interrupt_type is shared, hence the separate host and
> guest hw_interrupt_type instances.
> 
> With APLIC+IMSIC, guest interrupts are delivered directly by hardware
> through the IMSIC, bypassing do_IRQ(). The _IRQ_GUEST branch in
> do_IRQ() is therefore left as BUG() until a platform without direct
> IMSIC delivery is encountered.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> ---
> Changes in v7:
>  - Build device.c as device.init.o: everything it provides is
>    __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB
>    stays Arm-only.  Unlike Arm, which picks device.o/device.init.o based
>    on that config, RISC-V cannot enable it, so the choice is
>    unconditional for now.
>  - Don't have release_irq() free the guest IRQ info anymore: set
>    free_on_release = false and free 'info' explicitly in
>    release_guest_irq(), i.e. reinstate the xvfree() dropped in v5. The
>    action stays embedded in struct irq_guest, so a single allocation
>    still covers both, but it no longer has to be the structure's first
>    member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer
>    that merely happened to coincide with the allocation base are gone.
>    The ->dev_id concern from v5 doesn't apply: release_irq() clears
>    desc->action under desc->lock and waits for in-flight handling before
>    returning, so nothing can observe ->dev_id once 'info' is freed.
>  - Move 'action' to the end of struct irq_guest and reword its comment
>    accordingly.
>  - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that
>    the embedded action is fully initialized (action.handler was left
>    uninitialized before).
>  - route_irq_to_guest(): free 'info' via the common free_info label when
>    intc_route_irq_to_guest() fails, now that release_irq() no longer
>    frees it.
>  - Drop a stray blank line ahead of release_irq().
> ---
> Changes in v6:
>  - size nr_virqs as guest_aplic_num_sources + 1 to reserve APLIC's 1-indexed
>    source 0, so the highest source/irq could be reserved.
> ---
> Changes in v5:
>  - add early -EINVAL return in route_irq_to_guest() if domain is dying
>  - use __clear_bit() instead of clear_bit() in release_guest_irq()
>    since desc->lock is already held
>  - remove irq_get_domain() wrapper; inline irq_get_guest_info(desc)->d
>     at its single call site
>  - reword IRQ_GUEST comment in do_IRQ() for clarity
>  - move XVFREE(used_irqs) before the switch so it is freed prior to
>    variant-specific vintc teardown
>  - fix missing space in dt_dprintk() format string split across lines
>  - Drop 'inline' for irq_get_guest_info() and leave it only static.
>  - Drop xfree(info) from release_guest_irq() to avoid a potential
>    dangling-pointer issue with the ->dev_id field. Now that
>    'struct irqaction action;' is embedded into 'struct irq_guest',
>    'info' will be freed as part of release_irq() at the end.
> ---
> Changes in v4:
>  - Update the commit message.
>  - Mark map_irq_to_domain() and map_device_irqs_to_domain() as
>    __overlay_init (mirroring Arm) and include <xen/dt-overlay.h>.
>  - Fix grammar in the controller-skip comment ("IRQ" -> "IRQs").
>  - Drop the redundant 'base' local in guest_imsic_make_reg_property();
>    use GUEST_IMSIC_S_BASE directly.
>  - Rename vintc::irq_nums -> nr_virqs and update all users.
>  - Guard domain_vintc_deinit() against a NULL d->arch.vintc.
>  - Use smp_rmb() instead of smp_mb() in release_irq()'s wait loop and
>    document how it pairs with the spin_unlock() in do_IRQ().
>  - In release_guest_irq(), reject live unrouting from a non-dying domain
>    (-EBUSY) and clear _IRQ_GUEST under desc->lock so a concurrent
>    release for the same IRQ bails out instead of double-freeing 'info'.
>  - Tidy spurious whitespace in release_irq()'s spin_lock/unlock calls.
> ---
> Changes in v3:
>  - Drop extraneous "to" from "Unable to permit to %pd" message.
>  - Move res/irq/rirq to loop scope; use nirq as declaration initializer.
>  - Hoist irq_ranges check before the loop (it is loop-invariant).
>  - Remove spurious forward declarations (struct dt_device_node, struct
>    rangeset) from intc.h; remove all three from setup.h.
>  - Use __set_bit() instead of set_bit() in intc_route_irq_to_guest()
>    since desc->lock is always held on every write path for desc->status.
>  - Use XVFREE() instead of xvfree() in domain_vintc_deinit().
>  - Rename allocated_irqs -> used_irqs in struct vintc.
>  - Fix dangling desc->action in release_irq()'s !IRQ_HAS_MULTIPLE_ACTION
>    path by nulling *action_ptr after saving the action pointer.
>  - Use true (not 1) for free_on_release in route_irq_to_guest().
>  - Use %pd for domain printing in route_irq_to_guest() error paths.
>  - Introduce release_guest_irq() to pair with route_irq_to_guest() and
>    plug the irq_guest info leak; call it from domain_vintc_deinit()
>    for each vIRQ recorded in used_irqs.
> ---
> Changes in v2:
>  - Rework IRQ mapping in more common (similar approach to Arm).
> ---
> 
> Updates
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> Changes in v7:
>  - Build device.c as device.init.o: everything it provides is
>    __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB
>    stays Arm-only.  Unlike Arm, which picks device.o/device.init.o based
>    on that config, RISC-V cannot enable it, so the choice is
>    unconditional for now.
>  - Don't have release_irq() free the guest IRQ info anymore: set
>    free_on_release = false and free 'info' explicitly in
>    release_guest_irq(), i.e. reinstate the xvfree() dropped in v5.  The
>    action stays embedded in struct irq_guest, so a single allocation
>    still covers both, but it no longer has to be the structure's first
>    member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer
>    that merely happened to coincide with the allocation base are gone.
>    The ->dev_id concern from v5 doesn't apply: release_irq() clears
>    desc->action under desc->lock and waits for in-flight handling before
>    returning, so nothing can observe ->dev_id once 'info' is freed.
>  - Move 'action' to the end of struct irq_guest and reword its comment
>    accordingly.
>  - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that
>    the embedded action is fully initialized (action.handler was left
>    uninitialized before).
>  - route_irq_to_guest(): free 'info' via the common free_info label when
>    intc_route_irq_to_guest() fails, now that release_irq() no longer
>    frees it.
>  - Drop a stray blank line ahead of release_irq().
> ---
> ---

Why does this appear a 2nd time? All of the above is already long / verbose
enough.

> @@ -101,12 +119,31 @@ int domain_vintc_init(struct domain *d)
>          break;
>      }
>  
> +    if ( !ret )
> +    {
> +        d->arch.vintc->used_irqs =
> +            xvzalloc_array(unsigned long,
> +                           BITS_TO_LONGS(d->arch.vintc->nr_virqs));
> +        if ( !d->arch.vintc->used_irqs )
> +            ret = -ENOMEM;
> +    }
> +
>      return ret;
>  }

Patch 13 doesn't arrange for domain_vintc_deinit() to be called when
domain_vintc_init() fails. Ideally that would change, or else you'd
now need to call the function in the error case from here. In either
case ...

>  void domain_vintc_deinit(struct domain *d)
>  {
>      const enum intc_variant variant = intc_hw_ops->info->hw_variant;
> +    unsigned int virq;
> +
> +    if ( !d->arch.vintc )
> +        return;
> +
> +    for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ )
> +        if ( test_bit(virq, d->arch.vintc->used_irqs) )
> +            release_guest_irq(d, virq);
> +
> +    XVFREE(d->arch.vintc->used_irqs);

... this function will then need to become resilient against being
called with partially initialized state.

> @@ -118,3 +155,11 @@ void domain_vintc_deinit(struct domain *d)
>          break;
>      }
>  }
> +
> +bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
> +{
> +    if ( virq >= d->arch.vintc->nr_virqs )
> +        return false;
> +
> +    return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
> +}

Is the present caller of this going to remain the only one? If so,
__overlay_init would want using here as well. If not - will future
callers appear on paths which are exposed to guests? If in turn so,
speculation safety may need adding here.

> @@ -227,3 +250,206 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
>      spin_unlock(&desc->lock);
>      irq_exit();
>  }
> +
> +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc)
> +{
> +    ASSERT(spin_is_locked(&desc->lock));
> +    ASSERT(test_bit(_IRQ_GUEST, &desc->status));
> +    ASSERT(desc->action != NULL);

Btw, no need for the " != NULL" part.

> +    return desc->action->dev_id;
> +}
> +
> +void release_irq(unsigned int irq, const void *dev_id)
> +{
> +    struct irq_desc *desc;
> +    unsigned long flags;
> +    struct irqaction *action, **action_ptr;
> +
> +    desc = irq_to_desc(irq);

Can't this (once again) be the initializer of the variable?

> +    spin_lock_irqsave(&desc->lock, flags);
> +
> +    action_ptr = &desc->action;

Same for this one, which also doesn't require the lock to be held.

> +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
> +    for ( ;; )
> +    {
> +        action = *action_ptr;
> +        if ( !action )
> +        {
> +            printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", irq);
> +            spin_unlock_irqrestore(&desc->lock, flags);
> +            return;
> +        }
> +
> +        if ( action->dev_id == dev_id )
> +            break;
> +
> +        action_ptr = &action->next;
> +    }
> +
> +    /* Found it - remove it from the action list */
> +    *action_ptr = action->next;
> +#else
> +    action = *action_ptr;
> +    *action_ptr = NULL;
> +#endif
> +
> +    /* If this was the last action, shut down the IRQ */
> +    if ( !desc->action )
> +    {
> +        desc->handler->shutdown(desc);
> +        __clear_bit(_IRQ_GUEST, &desc->status);
> +    }
> +
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +
> +    /*
> +     * Wait to make sure it's not being used on another CPU.
> +     *
> +     * The read barrier pairs with the spin_unlock() in do_IRQ(): once we
> +     * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the
> +     * writes do_IRQ() made to desc (e.g. desc->action) before releasing the
> +     * lock, so it is safe to free the action below.
> +     */
> +    do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) );
> +
> +    if ( action->free_on_release )
> +        xvfree(action);
> +}
> +
> +int release_guest_irq(struct domain *d, unsigned int virq)
> +{
> +    struct irq_desc *desc = irq_to_desc(virq);
> +    struct irq_guest *info;
> +    unsigned long flags;
> +    int ret = -EINVAL;
> +
> +    spin_lock_irqsave(&desc->lock, flags);
> +
> +    if ( !test_bit(_IRQ_GUEST, &desc->status) )
> +        goto unlock_err;
> +
> +    info = irq_get_guest_info(desc);
> +    if ( d != info->d )
> +        goto unlock_err;
> +
> +    /*
> +     * Live IRQ unrouting from a running domain is not supported: the tear-down
> +     * drops desc->lock across release_irq()/xvfree() and relies on no
> +     * concurrent route_irq_to_guest() being issued for this domain. Only permit
> +     * it for a dying domain, where assignment is frozen and no new routes can
> +     * appear.
> +     */
> +    if ( !d->is_dying )
> +    {
> +        ret = -EBUSY;
> +        goto unlock_err;
> +    }
> +
> +    /*
> +     * Clear _IRQ_GUEST while still holding the lock so that a concurrent
> +     * release_guest_irq() for the same IRQ observes it and bails out, rather
> +     * than capturing the same 'info' and double-freeing it below.
> +     */
> +    __clear_bit(_IRQ_GUEST, &desc->status);
> +
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +
> +    release_irq(desc->irq, info);
> +    xvfree(info);

While in the v7 revlog you claim there is no issue here, imo there (still) is.
You obtain "info" with the lock held, then drop the lock, for release_irq() to
re-acquire. If a similar pattern was used elsewhere (info obtained under lock,
lock dropped, then using info), the pointer would go stale the moment you free
it here. Imo for this to be safe _and_ not setting a bad precendent, you need
a variant of release_irq() which is passed desc with the lock already held.
release_irq() itself (if to be called from anywhere else) would then be a thin
wrapper around it.

> +/* Route an IRQ to a specific guest */
> +int route_irq_to_guest(struct domain *d, unsigned int virq,
> +                       unsigned int irq, const char *devname)
> +{
> +    struct irq_guest *info;
> +    struct irq_desc *desc;
> +    unsigned long flags;
> +    int retval = 0;
> +
> +    if ( d->is_dying )
> +        return -EINVAL;
> +
> +    desc = irq_to_desc(irq);

Imo this either wants to be the initializer of the variable, or (perhaps
better here) it wants to move immediately ahead of ...

> +    info = xvzalloc(struct irq_guest);
> +    if ( !info )
> +        return -ENOMEM;
> +
> +    info->d = d;
> +    info->virq = virq;
> +
> +    info->action.dev_id = info;
> +    info->action.name = devname;
> +    /* The action is part of 'info', thus it is freed together with it. */
> +    info->action.free_on_release = false;
> +
> +    spin_lock_irqsave(&desc->lock, flags);

... this.

> +    /*
> +     * If the IRQ is already used by someone
> +     *  - If it's the same domain -> Xen doesn't need to update the IRQ desc.
> +     *  For safety check if we are not trying to assign the IRQ to a
> +     *  different vIRQ.
> +     *  - Otherwise -> For now, don't allow the IRQ to be shared between
> +     *  Xen and domains.
> +     */
> +    if ( desc->action != NULL )
> +    {
> +        if ( test_bit(_IRQ_GUEST, &desc->status) )
> +        {
> +            struct domain *ad = irq_get_guest_info(desc)->d;
> +
> +            if ( d != ad )
> +            {
> +                printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n",
> +                       irq, ad);
> +                retval = -EBUSY;
> +            }
> +            else if ( irq_get_guest_info(desc)->virq != virq )
> +            {
> +                printk(XENLOG_G_ERR
> +                       "%pd: IRQ %u is already assigned to vIRQ %u\n",
> +                       d, irq, irq_get_guest_info(desc)->virq);
> +                retval = -EBUSY;
> +            }
> +        }
> +        else
> +        {
> +            printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
> +            retval = -EBUSY;
> +        }
> +        goto out;
> +    }
> +
> +    retval = _setup_irq(desc, 0, &info->action);
> +    if ( retval )
> +        goto out;
> +
> +    retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY);
> +
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +
> +    if ( retval )
> +    {
> +        release_irq(desc->irq, info);

Like above, I think you want to avoid transiently dropping the lock here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:27:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:27:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393915.1632721 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwH2N-00018I-Qg; Tue, 18 Aug 2026 10:27:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393915.1632721; Tue, 18 Aug 2026 10:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwH2N-00018B-MS; Tue, 18 Aug 2026 10:27:19 +0000
Received: by outflank-mailman (input) for mailman id 1393915;
 Tue, 18 Aug 2026 10:27:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwH2N-000185-0I
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:27:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwH2L-00EnYk-Vx
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:27:18 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a843370-bab6-0a2a0a5309dd-0a2a4508c646-46
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:27:17 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a843385-f659-0a2a45080019-d1558036f1c4-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:27:17 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so52098035e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 03:27:17 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482aa084a64sm5690380f8f.17.2026.08.18.03.27.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 03:27:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787048837; x=1787653637; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=T126TCGs+nAGgigu/iaRPhT8aiEINrKVZhmxMW+LbXY=;
        b=BoEMpok5qaicrMQ3S36JPD2rDrY3a8V3DdTWh2NPLRSgPrj7kxwFVpLjP8mQa53dKO
         wFyy0tYr9oAEbSYm0NZ1l2KlRo3w3Vl5JJeqrnmI5v2UB3mqfKk+vPgvonyM/cX0gr6m
         ncWlLaOPnR6TLh3SaS4twq3bunrJYHRbRTq0uCMsTmk87rgw8YVCZgwk2lR5XNxrhBpR
         SAy6JKJDd5/IQZaqH9P4mLs28n6q7BmJLstG8Hj5a5M1gO4vSSZudK3VaSPwaQzfjvWV
         iLeS+PfROVqsnxeEeHnQsu7+TE9ASr2sWcBKErsmIESMwS37LKafzg4Lhcnwp25W8UJ5
         YWPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787048837; x=1787653637;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=T126TCGs+nAGgigu/iaRPhT8aiEINrKVZhmxMW+LbXY=;
        b=MdmVr8K2GfTRRwclPewETNAX0m3DSe0y1vnnMwX5lTLlsjuq7Rb1Vw5YtMfcLN9FqX
         nXSVY/I54j7hyI0dh8BYWoBWfVBYOD6raN8TIBr44Xd37bUsKD/b5MhKa6Np+ADdhqQn
         2F7TQe97VG3MQGu6s5slGtzIFEgZl4M9YyOATjE7rAmekG3hcI+0LkvownVr0CVlLrz7
         5AhFDUlv9TI8rI64vGSZhs3g05J6tC/VH/t7+WA3YgUSYIgOlpxJ83JL7Lxl5kkihiMZ
         nwox/ZWH9wxDA/E44lJ+F8RWKnx/iMbDrbNGnyo7gt/WQbMe+q/Z9kAMhT11mtyMZeRA
         g55w==
X-Forwarded-Encrypted: i=1; AHgh+RqNkUL748DsRqGd9n6KZWOMpjjaIfLe1lQ3crfWKDLfDetJgOvfxmJiJLlX4YC7proWvAszPsO+v1I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRe+8QzzNpS8FUrpUru7o9CiluI5jOkXRca8vU3QP/OP+LPNzV
	+RGT47mhZRSc35KvFOiHwilcEm7oZMl3L39UWImiUwQs77W7OpTzmbZV
X-Gm-Gg: AR+sD13JYhQrf0SF6G7Le5HdD24qgNFgclPIm3BUZX2zjKpeCBPJq14NrJMU7tnE+WW
	UZZ4tUYmftZ60isfcT2Mc3cRjhWpvHto/ExmJx2cybqH40hpoVZoFYxapC+lmcMkkrnHgKCo7uW
	gZtV5R++exQFOzMizS4KYyc4qhaxXzJ8I4D2VLMgh8dZ33/445CrUCzsC4Z3vOV4WwIjZzPqWqI
	KAIXXg82p8pQv8Kg55kMypjPUwGlgUlsxu9KwzHo6RoXI4q2Y6/LP3hC7cuDa2ieFgNgL7nxU3X
	Rcx/lRi4GF+/2E79PKOO0ttdn6AFPhezkXilDlcrYxvMWE8SkHQnGxB6R3mTQNOMktoLn+tO0R2
	G8EKg8Qjn+K1rlcv+IdM9g82m8kslcl/8lqApwnJ3sBPt07t3SWUQO5Ryi4bfn5TSUIQC3sc0Hs
	7PRy2i24qH125We+nc2rSqJYcnLRLbEB8uP7JxJ1eKxayp7nB0Tkxt8sDAJnrAL4qsafRcr+U/r
	hV9fi67k+FnxQLT1+EBiiqxgUVLFT0VLnYz5J7xvYU=
X-Received: by 2002:a05:600c:3b8e:b0:499:a0f3:9d5c with SMTP id 5b1f17b1804b1-499a0f3a47bmr92169705e9.3.1787048837302;
        Tue, 18 Aug 2026 03:27:17 -0700 (PDT)
Message-ID: <d94bd15a-bf99-4df5-9dac-1fe0fcb77cfc@gmail.com>
Date: Tue, 18 Aug 2026 12:27:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
 <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
 <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
 <2ca3f802-bf93-4714-8a9b-e33ab0c89300@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <2ca3f802-bf93-4714-8a9b-e33ab0c89300@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787048837-CEB4187B-442F742F/10/73395122804
X-purgate-type: spam
X-purgate-size: 5579



On 8/18/26 10:17 AM, Jan Beulich wrote:
> On 17.08.2026 17:36, Oleksii Kurochko wrote:
>> On 8/12/26 5:30 PM, Jan Beulich wrote:
>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>> Introduce riscv_vcpu_unpriv_read() to allow Xen to safely read guest memory
>>>> using HLV/HLVX instructions while reliably capturing trap context.
>>>
>>> Both for the title and the function name: How does "unprivileged" matter here?
>>
>> Unprivileged because HLV/HLVX reads guest memory as if it were accessed
>> from a less-privileged (guest) context, rather than by the hypervisor in
>> HS mode.
>>
>> I think I am okay generally to drop "unpriv..." from the function name.
>>
>>> The same functions would be use for reading Dom0's memory, wouldn't they?
>>
>> Yes, I don't see any issue to let this function to read DomO's memory
>> too. But Dom0 could be counted as "unprivileged" too as it is executed
>> in VS-mode which is less-privileged then HS-mode.
> 
> Well, you need to properly distinguish the different cases of "unprivileged"
> when writing titles / descriptions. The way you put it in your reply above
> ("less-privileged (guest)") is sufficiently unambiguous, but what you have
> in the title ("unprivileged guest") clearly is a synonym for "DomU".
> 
> In the end, as you confirm, "guest" alone is all that's needed here to know
> what is being talked about. (That said: We often distinguish "guest" and
> "domain", with the former meaning DomU but the latter meaning all domains,
> including Dom0 and service domains. Yet for the purpose here I think "guest"
> is good to use, not matter that all kinds of domains are meant.)

I will use then guest.

> 
>>>> +    if ( read_insn )
>>>> +    {
>>>> +        asm volatile ( "\n"
>>>> +            "1:\n"
>>>> +            "   hlvx.hu %[val], (%[addr])\n"
>>>> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])
>>>> +            "   andi %[tmp], %[val], 3\n"
>>>> +            "   addi %[tmp], %[tmp], -3\n"
>>>> +            "   bne %[tmp], zero, 3f\n"
>>>> +            "   addi %[addr], %[addr], 2\n"
>>>> +            "\n"
>>>> +            "2:\n"
>>>> +            "   hlvx.hu %[tmp], (%[addr])\n"
>>>> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
>>>> +            "   sll %[tmp], %[tmp], 16\n"
>>>> +            "   add %[val], %[val], %[tmp]\n"
>>>> +            "3:\n"
>>>> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
>>>> +        : [ti] "r" (trap) : "memory" );
>>>
>>> You want to tell the compiler that *trap is written. Instead I don't see
>>> why a memory clobber would be needed: You access a different address space,
>>> i.e. nothing the compiler can make any assumptions about.
>>
>> memory clobber tells the compiler that the assembly code performs memory
>> reads or writes to items other than those listed in the input and output
>> operands and so I don't tell here that *trap will be changed.
>>
>> Why this understanding is wrong?
> 
> You can (ab)use "memory" for that purpose, but why would you when you can
> properly express the operand? All that achieves is the compiler possibly
> having to emit less efficient code.

Then I will use the option mentioned ...

> 
>> Alternative, I think, could be:
>>           : [val] "+r" (val), "+m" (*trap)
>>           : [addr] "r" (guest_addr), [ti] "r" (trap) );
>> And then memory clobber could be dropped.

... here.

Probably I have to return '[addr] "r" (guest_addr)' to output and use 
+&r constraint.

>>
>>
>>
>>>
>>> You also need to take precautions for not returning an uninitialized "val".
>>> I think the variable wants initializing (perhaps to ~0) and "+r" wants
>>> using as constraint. (Afaik & isn't necessary to use together with +.)
>>
>> I agree with '+' if we will initialize val with some value.
>>
>> Regarding, '&' my understanding is that I have to use it always when
> 
> When what exactly? If an operand is both input and output, how could the
> compiler re-use the (generally) register for any further purpose? '&'
> indicates to the compiler that it may not use the register used for an
> output to hold some input's value, as that value may be lost by the time
> the input is actually consumed.

But what is written in the gcc doc:

& - Means (in a particular alternative) that this operand is an 
earlyclobber operand, which is written before the instruction is 
finished using the input operands.

What sounds like if an operand (val) in our case is written before the 
instruction which using the input operands (and after the write 
instuction which writes val there are instructions which are using input 
operands) it is needed to have &.

t1:  hlvx.hu %[val], (%[addr])   W:val R:addr + can trap -> read register ti

t2:  andi    %[tmp], %[val], 3   W:tmp   R:val
t3:  addi    %[tmp], %[tmp], -3
t4:  bnez    %[tmp], 3f
t5:  addi    %[addr], %[addr], 2 W:addr  R:addr
t6:  hlvx.hu %[tmp], (%[addr])   W:tmp   R:addr + can trap -> read 
register ti

t7:  slli    %[tmp], %[tmp], 16
t8:  or      %[val], %[val], %[tmp] W:val

So val is written on t1 before t6 where addr and ti still alive.

The similar is for [addr] "+&r" (guest_addr):

addr is written on t5 and input ti is alive till t6. So if allocator 
will allocate the same register for addr and ti then addi %[addr], 
%[addr], 2 will break a pointer and handler will get something wrong.

Am I missing something?

If I am still wrong then in both cases should be just "+r"?

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:30:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:30:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393924.1632730 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwH5j-0002zz-BD; Tue, 18 Aug 2026 10:30:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393924.1632730; Tue, 18 Aug 2026 10:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwH5j-0002zs-7V; Tue, 18 Aug 2026 10:30:47 +0000
Received: by outflank-mailman (input) for mailman id 1393924;
 Tue, 18 Aug 2026 10:30:46 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwH5i-0002zm-7D
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:30:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwH5h-00Ctdv-K5
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:30:45 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84344b-bab6-0a2a0a5309dd-0a2a450887e2-36
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:30:45 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a843455-f659-0a2a45080019-d155dd2ae149-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:30:45 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so3875522f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 03:30:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a6c449dbsm10260610f8f.8.2026.08.18.03.30.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 03:30:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787049045; x=1787653845; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=jJfs0zmMOm8zObf9eEZAFlFoq7G6tNcIx2OxBTDpWRk=;
        b=eu/2KuOuIkzINUEQV7b0Sf72thg7JLFLRmy5AuSBH189lDo6ewvcTqOU9vOBCt3J5V
         3yZL1EmcgsSrL3JH8Kp/E7fp+iWAcqBXE3qxzg+yD/NpoQcDOPKWIuESOEu2qjULt7ni
         HB7QJJhVpUkeAXvAzP7u2TM1COzRv9WGZvx3VpiFBk8w3WGo1utSz4cJFXsX6hAPojnp
         0PRw2ucf2F8GWs+fu609IEISy0K+P888xTgon0w4Wa8KliaPO3yV6cw563SwcOct3rFa
         242EASe/P/v1H2IxwdlWEzX30bMuCH8Ef156GajnEbw+Rg/d/8VqCdJjPomffoJTFX+N
         qdmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787049045; x=1787653845;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=jJfs0zmMOm8zObf9eEZAFlFoq7G6tNcIx2OxBTDpWRk=;
        b=g4p1ejrfbym1BwcGDjmmzME7MONdTm4lOU2+PB/iiqwI50twmyx1qTsUitAKawzSVq
         I+ea1HfKiUbpILuESS9JgFkaEj0oQz9dbmPGw7W/dL8OX7BDPGZCpC0wkrOt8XMmWBiV
         S208oVEcoYtnr7EPsMbWMeDcH+SgtOLIcriEADlpvGQw5xvg/wjdG7+6uhOinpa0YvPU
         uhKns7If7O0Ah6WjLYSWHQWLpHMcjSeo2axlABy5nikx56FJjIfwKXgVP6spwMxAWF1C
         oMTf5gG5aXUEdywlICHonhNmgB3xwiMAD5ZxPQ+RxcAm7fRLvRt23bPlnwhByvFQbq+8
         b2hA==
X-Forwarded-Encrypted: i=1; AHgh+RrGJCOrIGjUaGa/AHtbsBZXpSlMdFyzPyitT+p23XZrSa3AspmQJAWaj3+ligSH1JANgMpAqSOpjuc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyq1N8En4qS+Ge/HYQM+VsANbwb4oUgfC7qoVS82qirmJ80CSXU
	Y+hpaNotj7edDosRbkt7MvfHG/vqzGh9iW31xreILf6UN/nBtb/4yvXtERiRERNdFA==
X-Gm-Gg: AR+sD12sGfKI4CblGjHwT2fXYpLR2FEYUrVi10UQUhOa8DtdkZMfUhbJnZfBcGrkIhn
	ghNi5jrOI3IGtEy/eeoSaWFLBw/qhUaRAf8BD0UKbjIUNN3CIpIgPDy50uMI5VD1hfF0qByNoXy
	oebt7T6slii7lyjIXJHthNPigXfWaqfHpTiPDywVVMOQrsy2X+xrDzsGZN2n2WBXKE2Ov6pk9ew
	kBG9R5owalZ4c6nZNFMEvjU2hhlwWnMaVy/ejkB3MewgsToYKtOzItWiKA/QesHVyh46Fz0Q8a3
	N5FVPzWtMrCh4nkkEobDTZO+Av0gikq63gFn3feAYRnluNnygNK6LNaW7yPeI1uq0NV80qK3BTr
	182HNJILfDEsxHLzulN7Wo8aSxrPTcq2hCf0l6NOOlXDLG/aM5nsCXlLv1BIYrKkvneipKIDU0w
	BOjGfJPy6fsuuQqkZpYHBiLT5k8/hNfBxWw2K12la2qm4AuFiiiyqU0x4C7EQVTFCVRM9vIVvXb
	czJiNEextZeVcxH73sv7GYvKZAY2Xpw1UxzTjpcHxfXD3T28eJE
X-Received: by 2002:a05:6000:3109:b0:47f:e748:3ae3 with SMTP id ffacd0b85a97d-4816070bf1fmr48632766f8f.3.1787049044931;
        Tue, 18 Aug 2026 03:30:44 -0700 (PDT)
Message-ID: <b3cfe45c-9d44-48b9-98d2-8682aa062184@suse.com>
Date: Tue, 18 Aug 2026 12:30:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 12/17] xen/riscv: extend exception tables with type and
 data fields
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <1eb9050ff6632f91682151471440990bd718ed90.1784560663.git.oleksii.kurochko@gmail.com>
 <be932384-6661-4c92-9137-8f6a9cd54057@suse.com>
 <3c9ef195-a8d4-489c-8daf-5635d3b53063@gmail.com>
 <b8b794ec-c86a-4a82-9d3a-b3ffcaa802f3@suse.com>
 <4a707c58-2225-477f-936e-9f99ae616c44@gmail.com>
 <eabb8190-51a9-4c25-b377-c25cd23af044@suse.com>
 <5005ead1-b7e2-4edc-8359-c2a9a89e5b4d@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <5005ead1-b7e2-4edc-8359-c2a9a89e5b4d@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787049045-CED4087B-7CBF197B/0/0
X-purgate-type: clean
X-purgate-size: 5115

On 18.08.2026 11:40, Oleksii Kurochko wrote:
> On 8/18/26 11:26 AM, Jan Beulich wrote:
>> On 18.08.2026 11:14, Oleksii Kurochko wrote:
>>> On 8/18/26 9:56 AM, Jan Beulich wrote:
>>>> On 17.08.2026 13:33, Oleksii Kurochko wrote:
>>>>> On 8/12/26 4:37 PM, Jan Beulich wrote:
>>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>>> @@ -60,6 +68,40 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
>>>>>>>         regs->sepc = ex_fixup(ex);
>>>>>>>     }
>>>>>>>     
>>>>>>> +static inline unsigned long regs_get_gpr(struct cpu_user_regs *regs,
>>>>>>> +                                         unsigned int offset)
>>>>>>> +{
>>>>>>> +    /*
>>>>>>> +     * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>>>>> +     * laid out at the start of struct cpu_user_regs in architectural
>>>>>>> +     * order.
>>>>>>> +     */
>>>>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) !=
>>>>>>> +                 sizeof(unsigned long));
>>>>>>> +    BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) !=
>>>>>>> +                 31 * sizeof(unsigned long));
>>>>>>> +
>>>>>>> +    if ( unlikely(!offset || (offset > MAX_REG_OFFSET)) )
>>>>>>> +        return 0;
>>>>>>
>>>>>> And an offset not divisible by sizeof(unsigned long) is okay?
>>>>>
>>>>> No, it isn't okay. I will apply your comment ...
>>>>>
>>>>>>
>>>>>> Returning 0 as error indicator also feels fragile.
>>>>>
>>>>> With what I suggested below returning could be just dropped.
>>>>>
>>>>>>
>>>>>>> +    return *(unsigned long *)((unsigned long)regs + offset);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void ex_handler_trap_info(const struct exception_table_entry *ex,
>>>>>>> +                                 struct cpu_user_regs *regs)
>>>>>>> +{
>>>>>>> +    struct trap_info *trap_info =
>>>>>>> +        (struct trap_info *)regs_get_gpr(regs, ex->data * sizeof(unsigned long));
>>>>>>
>>>>>> Related to the earlier comment: Simply pass just ex->data here, leaving the
>>>>>> multiplication to regs_get_gpr()?
>>>>>
>>>>> ... It would be better to move the multiplication inside regs_get_gpr().
>>>>>
>>>>> Your comment made me think about whether the multiplication is needed at
>>>>> all (regardless of where it is done). In other words, ex->data contains
>>>>> the register number, so we could just write:
>>>>>
>>>>> static unsigned long regs_get_gpr(const struct cpu_user_regs *regs,
>>>>>                                      unsigned int num)
>>>>> {
>>>>>        /*
>>>>>         * The GPR number -> offset arithmetic below relies on x0..x31 being
>>>>>         * laid out at the start of struct cpu_user_regs in architectural
>>>>> order.
>>>>>         */
>>>>>        BUILD_BUG_ON(offsetof(struct cpu_user_regs, ra) != sizeof(unsigned
>>>>> long));
>>>>>        BUILD_BUG_ON(offsetof(struct cpu_user_regs, t6) != 31 *
>>>>> sizeof(unsigned long));
>>>>>
>>>>>        ASSERT(num && (num < 32));
>>>>>
>>>>>        return ((const unsigned long *)regs)[num];
>>>>> }
>>>>>
>>>>> Probably, we want to consider this function out of context (for now
>>>>> context is that we use it to recieve a pointer to trap_info which can't
>>>>> be obviously stored in x0 as it should be always hardwired zero). In
>>>>> that case, there is no need to check that num is 0.
>>>>>
>>>>> So, it probably makes sense to just have:
>>>>>      ASSERT(num < 32);
>>>>>
>>>>> ASSERT() is fine here as I don't think that compiler will use incorrect
>>>>> number during register allocation.
>>>>
>>>> I agree.
>>>>
>>>> However, the x0 aspect is still odd. Why again is it that struct cpu_user_regs
>>>> has a field for it, when the register value is always 0?
>>>
>>> zero field isn't there to hold a value, it's there so the first 32 slots
>>> form an x0..x31 array indexed by GPR number. It is useful for SET_RD()
>>> implementation, for example.
>>
>> But SET_RD() will need to avoid touching .zero anyway. Why waste the space,
>> when something useful can be put there?
> 
> For SET_RD() agree, it doesn't make sense. Bad example. But it could be 
> somehow a "protection" to not clobber something useful if SET_RD 
> arguments won't handled correctly.
> 
> SET_RD() is only half of it. The read accessors matter more: sd x0, 
> 0(a0) to an MMIO address is the normal way a guest writes 0 to a device 
> register, and emulate_store() fetches the operand with GET_RS2(), which 
> is a plain index by register number.

Oh, wow, how fragile. Without a bright comment in struct cpu_user_regs, one
should be permitted to move fields around or insert new ones at arbitrary
positions. That comment would then also help clarify why "zero" is there as
a field.

> If something useful lived at offset 
> 0, that store would hand the device that value instead of zero. So 
> whatever we put there would have to survive being read as a source 
> operand and being clobbered by SET_RD(), which means nothing can go there.

But you can't use it as (reliable zero) source when you allow SET_RD() to
clobber it.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:35:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:35:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393933.1632737 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHAC-0003Wf-QR; Tue, 18 Aug 2026 10:35:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393933.1632737; Tue, 18 Aug 2026 10:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHAC-0003WY-NX; Tue, 18 Aug 2026 10:35:24 +0000
Received: by outflank-mailman (input) for mailman id 1393933;
 Tue, 18 Aug 2026 10:35:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwHAB-0003WS-CL
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:35:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwHAA-00BK4B-6I
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:35:22 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a843554-e002-0a2a0a5209dd-0a2a4502a726-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:35:22 +0200
Received: from [52.101.61.0]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a843568-6ca4-0a2a45020019-34653d000998-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:35:21 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PH7PR03MB7413.namprd03.prod.outlook.com (2603:10b6:510:2e8::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 10:35:17 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Tue, 18 Aug 2026
 10:35:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mJD9W62zqW029P5LaJ9kR2gzvxyUg7J9z/ingio94S2WpZ72VNToStfG9Jjh5WJQwqdqcTZPrIK+cEuBilh8Y9uIQ+V/i/Vxcf/JCHZYNXqkbKewFQgwz/NHxnLCa47tigqkjbT0mD5kbNGQ5xxhkC6GbyxsLQb20HvobFzh/vbIuOlg86+BlMIfwjkUH1GhpgPNGqnYZnGNevOLravgFsbVu2o+8HThOXpd3+joco9RNIqJB8RW/Akkz80RBPSLswbSFJOj1qbsVbeP/gY5JaAs8Koy2I1b40M9kh+b6U93qQMbs2PlV2hkdBLnqG0pfJ3ckVo9ymI6BsVXuJhdfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=a72T3B3V1OW7tNrgOO/ktM4/K+rzTKrQksiFPMT06IQ=;
 b=a49W2RA9hOEloL2DQ2dRSfsnqK507g57XRK4Bu79/PSlOq84ODp0h+YjRECdgsuiN0bRE56fgeif+DChV+lX0aCFvPoNwiM3Yjz9g7Kdg9OLA+xJkcn/pU1ueSsXj1dx/af60pmJKhJJ00QbDB7oAkwOL9zGLw0P32sDxP9fVoazoN8RVsxUGuWf96dTLyic3ZbK9gbYNRKZnHl+UHhIXrYmrSmQVwExoqYnFxALvMMU4DSP3LNTiY7mU5hQxJqgizqfqokMzXKkiWwIRW6HMqnksqeOdYQuiqJzo6TR3B0I1lFaFMm2qoyxTJQ1xk4ZLnJeEI/sLLLtqFKPSUb9/w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=a72T3B3V1OW7tNrgOO/ktM4/K+rzTKrQksiFPMT06IQ=;
 b=l3vNFiocqGxgqURRi5PtC6nWYxGaO3tBD0uafVj6f9zn5lnj08HspEJUeiLoT1jdayaPeOa0zc9AK/lOeMS4Z5byRWOSTnEIfoxBj3c3h0slozG0SyazJluh4nVKHwT2aLK2WL3kRlABmJuByooVY7tC6ujDr/eWpdV2z4Q4xSk=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
Date: Tue, 18 Aug 2026 11:35:13 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, jbeulich@suse.com,
 dfaggioli@suse.com, gwd@xenproject.org
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
 <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0149.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2c7::13) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH7PR03MB7413:EE_
X-MS-Office365-Filtering-Correlation-Id: 3f29c74e-9e50-4b2e-2c72-08defd146542
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|22082099003|18002099003|56012099006|10067099003|11063799006|4143699003;
X-Microsoft-Antispam-Message-Info:
	CKYWS6WYHeuzBzp9EMWMWYmCrgz5/Y3CMdAMkpbqvdIA/5jvfk4s+NF9KwP+/SkB6MOd3DugCMy/v766NKMh039dMdd/+zsPwD17/xYLRiCtt7HtJtNgrW+cCqYhGcLU+MMWDwbiT1lDzJd1GLRpwlD/3ax1KhLTaSlyYP0uiMgqd4iubRwlh/GTomkV9Sk1L5KR/cenJ4QtkmGbbhB21TFeFPK5i6pvrgFUanSxV97hSUD9qMi1Zo4h22UaDOtVtfujJZYwRW+mMHYe9yIQkGieQVrUFHs91TmviCnNLiSRm9qrqlXPfBvkK5HF19zVn57z/+NreF6dcPWltBJMpKWiBq/TH4eMadp3tBpg6YVRHO6sC+H+jlSTy23TwstoLd1d7WDy/cj3WCVvyUJcxMv+e2jGNzwPAHhQrP3rL67F3BjH2WLqG9vyVd/qKglk1FOyZZskvcogG/KU2FjdQYdFnVbbLHYIvjajdxGey5bUPQH7BDaP2jH0ui3KnuHAyVZN5oTwyw5XghCHxcMbLEalnyV8p/OepipjAdtOy5J1N2AyRkPf61H/kki37HZyWoDLRWiANr8ivIxH1MC2PFBrbdA8peAO0KmCbzR+HqKkpAdQ4XmZGTCwdrceXM66wczUgwEW1bmfK/rjuwPAe+ikBh2AQmURv0siHGkQPJU=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(22082099003)(18002099003)(56012099006)(10067099003)(11063799006)(4143699003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Nmh1RzNIaUhobE9HYm15K2l3OTVkUGFLenJEZVlubmZZRklUVGVmWExneFIw?=
 =?utf-8?B?eCs3MCtZZC90Q083c0ZhMVoyV1RvNDZVRm9oQ1NSSkd1dFJJSzdJZGsxNFhT?=
 =?utf-8?B?UWVTQlloMG9ubnRmV29ENmh2cFhrazkrOGMrVGJNVVRKckxlUzJ6R2VJYjFL?=
 =?utf-8?B?NDlSeThRWHFqc0xKUFdzbENVWWVqMTA4dXorVHdEVGlCRWJrVUtQRE5iZ3Jw?=
 =?utf-8?B?THRQSWpyM2tmNU1CTE1rQkluUW52aE5oSGdSTzRMaVVKaG92ODV3NHZvTEZE?=
 =?utf-8?B?a0xFcEs3LzB3WEZnWjR2YWowMVJLVWQrZXRuNEl1ZVUza0xYYTFjbFFZaWN6?=
 =?utf-8?B?NU5BQndSYmtOZm9mRXNQdkFFc0FuS210R3liaUZwOW9nQk40WFdJSnBUR0Rw?=
 =?utf-8?B?R2dmTW1wdFMwSHZFZWRudnVhT3dRdEl1YkxGcDhjN2xOeDdXcjNkaDBzdEpR?=
 =?utf-8?B?bGVWQU9IUU5QWWFDVi90MUEyVW9TZTZUQkJYV29wTXllbEI3b1dDUkN0YXRx?=
 =?utf-8?B?TzRmamhSV01WM1ZqZFkrT0lpMTh2cFhDNkwzTXM3MGF3YmJXTElHVmIrU280?=
 =?utf-8?B?L21zTFZrajVlK1A0dWlXdHcxLy9hdkN6Wi9oYXorK1g5WTE4TnRsV203ZXl0?=
 =?utf-8?B?aGp6ZHZZOXp5dkppdjVmT2xtLzJJU1RvNGdzRUczbUxZZWhHdzBySmxiZVJp?=
 =?utf-8?B?QlRsWFdMZlBqT0t6L3I5R1FnazdsSTdkZVJXcUZlSXdTazA2WCs1cFNINVA2?=
 =?utf-8?B?RXhRS24vMlB3QUM5M1JXcnlQZTQxODFzM3BxTTBGcG1vdFhCTUpCL2d6aVB5?=
 =?utf-8?B?Y1V3cWZQa281QlhnU2lsNFRhTXhhbktaR1kzbDNoRTNkL0gxWmpFSG9reDBH?=
 =?utf-8?B?LzNZb05aT3dpVVlGcVROUzJ1amFhU29VV3lkOGdkSmRPaEpUOXlxdWo4Uisy?=
 =?utf-8?B?YVYra2VuVTkvc1RjczlqcmtIcXNXallRMU53dlh4cXpvNk4vOHFGU1Y5Tlp3?=
 =?utf-8?B?NElxTEVIV0V5cXdXMk5Sc3htQXJHbGJVV3B5YlpmWS92VzkzZjFSaTFHZkhJ?=
 =?utf-8?B?Y1FpQzJ4U25CdVZJUlEwSlZxdjJ2aDMwSEZmQXJQSXE1NElhS2kvcEhDa0NF?=
 =?utf-8?B?L2FndHJLVUhEcHhqZm1WOFA2MTlqVmZsVkJ1WnpxVHd5TGtlT0EycGtHVmww?=
 =?utf-8?B?eDFVYzZyeUp6QlhCdDlsdS9SR0xKbVNjMEwxQk5hRTg2TjIxaEJsdDBCbUY2?=
 =?utf-8?B?bEFaOFROUG1FQ05DMytOcWNqS0xKdDNWWXN4L0lvTkhOU0RKZDhKRlFuZ2dm?=
 =?utf-8?B?bG1jSGZHRWNKOGVEd2dHM3p4dzBxNmN6RC8reURnZGFsMlU3ZkVxU2VMdkRR?=
 =?utf-8?B?ZkN5ZG13a1A5Qkp1QVFrNEtvWThHV3ZxSUZLNkEwUWJNUkNxb1dvUktjNnZy?=
 =?utf-8?B?VkU4Y3FiU1dRQkRxLysyY1k1RDF5UWxBM284UkdFWFBWUE9wS2s2ZWl3dXVr?=
 =?utf-8?B?UUdJakcyUUVoN2doZTNWMjVUMWd6YmMrRjJmT0NDR1lMdHk3MTZjQnhUWEdW?=
 =?utf-8?B?K0gzY0RQU0lDRmpJQSsrMkc3Q2NodjlIcGVML2F3WFErbWFVNThqNXlINFBZ?=
 =?utf-8?B?c25TTHdxTnZsU25nM0dCNVFqN0gzRjlHd1RpRDU1ZnJ6REYzU04vT24xMlZo?=
 =?utf-8?B?eHBrRHZPRHFZTVJ5T3BmT2E3cHJXYlBLY1UvcTJYQkw4cTBCZWxQUXI2aG1a?=
 =?utf-8?B?TUYvc0VzbmFBM1RZS0pDeUtQVFlFQ2JSSWpnT0Z6a0RjVTdCVy9kUzZpcTJT?=
 =?utf-8?B?WFJMZmM3WWd3RGdmWkNTeGI3NU1rcUsvZWZDMlc4ZVZuMEQ2cEJuOHRrZkZW?=
 =?utf-8?B?bjVQaW5rZlBhakVsQ0s5R0dSeWZ2MWtqNW5lZFZEeUpCVlN1SWtmNHZLRmJY?=
 =?utf-8?B?NkZSRmZtN1ZyYVlSWXRuRUxSeFBGYkFHWGs5ZTFkSXlOV050SkRsTUZRcXgv?=
 =?utf-8?B?WEJ4L0VoWFNML0w0NWNObjFGQlkvL0J4TWplMTJsRHJ4S3c2aTBabGNQUlNR?=
 =?utf-8?B?ZEZ6VDNIOHpvNWZVdmNyVGFwZXR2R0NpOGdkZXlCVzFiR1lFRU5iY2hGajRG?=
 =?utf-8?B?L3ptbkU4b3pWTkJWbjc1aUVxbTQ2OVF4TzNDR04xeUlRMFZzTVJ0MlJLSlh0?=
 =?utf-8?B?b0prUkZmRDBTWjEwQTd2dHEyMVA4dlBwOXczejl3anFuS0Q3QlNKczNVTEpz?=
 =?utf-8?B?bGhXanh4N1BYQVJ2N011em53K1NDL2ZLT2RIS0NHclBEdVR1dDlTZEVRUUlW?=
 =?utf-8?B?Y3B3MnBvYXptQ2ljNjBnQ1hZekNQZUJIZjAxeDlSTzJiVlkvVUFOdz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f29c74e-9e50-4b2e-2c72-08defd146542
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 10:35:17.3981
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3FMTUPdeD45ZYYmHd1FwhPz9APBaU24TvPqO2/X+f98H8EaBe+le8kBml4ulpI/DtkNy/lWRU75vJ7ijp7PUseIysUAcYH44Y8SalhhJJS4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB7413
X-purgate-ID: tlsNG-720697/1787049322-66CB22AC-5B89919C/0/0
X-purgate-type: clean
X-purgate-size: 4251

On 18/08/2026 11:13 am, Jürgen Groß wrote:
> On 18.08.26 12:04, Andrew Cooper wrote:
>> On 18/08/2026 8:53 am, Furkan Çalışkan wrote:
>>> On 8/18/26 10:11, Jürgen Groß wrote:
>>>> On 18.08.26 08:32, Furkan Caliskan wrote:
>>>>> sched_move_domain() derives the number of units to rebuild from
>>>>> d->max_vcpus, which is fixed at domain creation and never rolled
>>>>> back if vcpu_create() fails partway through building a domain. So
>>>>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>>>>> counts it - this happens if sched_alloc_udata() returns NULL.
>>>>>
>>>>> The per-unit loop doesn't check for this: it sets
>>>>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>>>>> unit straight to the destination scheduler's alloc_udata(),
>>>>> which assumes vcpu_list is always valid and crashes Xen when
>>>>> it is not.
>>>>>
>>>>> Reproduced by building a domain in a non-default cpupool where
>>>>> vcpu creation fails partway through, then destroying it.
>>>>> domain_kill() moves the domain back to the default cpupool via
>>>>> sched_move_domain() before actually destroying it, crashing
>>>>> inside the destination scheduler's alloc_udata() (seen in
>>>>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>>>>
>>>>> Before building a unit in sched_move_domain(), check that all of
>>>>> its vcpu slots are populated, and skip it if any are missing. The
>>>>> rest of the function walks the vcpus that actually exist, via
>>>>> for_each_vcpu() rather than n_units, so skipping a unit here
>>>>> does not leave anything else out of sync.
>>>>>
>>>>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>>>>> ---
>>>>>    xen/common/sched/core.c | 19 +++++++++++++++++++
>>>>>    1 file changed, 19 insertions(+)
>>>>>
>>>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>>>>> index d3a0a97e1d..d542c76543 100644
>>>>> --- a/xen/common/sched/core.c
>>>>> +++ b/xen/common/sched/core.c
>>>>> @@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d,
>>>>> struct cpupool *c)
>>>>>          for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>>>>        {
>>>>> +        /*
>>>>> +         * Skip this unit if any of its vcpus is missing. Bounded by
>>>>> +         * max_vcpus.
>>>>> +         */
>>>>> +        bool vcpu_failed = false;
>>>>> +
>>>>> +        for ( unsigned int i = 0;
>>>>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>>>>> +        {
>>>>> +            if ( !d->vcpu[unit_idx * gran + i] )
>>>>> +            {
>>>>> +                vcpu_failed = true;
>>>>> +                break;
>>>>> +            }
>>>>> +        }
>>>>> +
>>>>> +        if ( vcpu_failed )
>>>>> +            continue;
>>>> I don't think this is correct.
>>>>
>>>> If there are some vcpus in the unit you will loose them (i.e. make
>>>> them no
>>>> longer be able to be scheduled), right?
>>>>
>>>> For a dying domain this might be okay, but not for one still
>>>> active. So I think
>>>> you should at least verify the domain is dying, otherwise
>>>> sched_move_domain()
>>>> should just fail.
>>>>
>>>> An alternative might be to fix the NULL dereferencing where needed,
>>>> but this
>>>> could become tedious.
>>>>
>>>>
>>>> Juergen
>>> Right. My initial attempt only checked 'd->vcpu[unit_idx*gran]'
>>> for the head vCPU. The crash happens when unit->vcpu_list is set
>>> to d->vcpu[unit_idx*gran] (which is NULL) and passed to
>>> 'alloc_udata()',
>>> causing a NULL dereference.
>>>
>>> I expanded the loop over 'gran' to handle core-scheduling cases where a
>>> subsequent vCPU fails mid-unit, but as you pointed out, that drops the
>>> whole unit for active domain.
>>>
>>> I'll update the patch to check d->is_dying to skip incomplete units
>>> only for dying domains, and have sched_move_domain() fail if an active
>>> domain has missing vCPUs
>>
>> I'm afraid that wont fix everything.
>
> Why not?

domU's in this situation do not have is_dying set.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:44:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:44:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393945.1632748 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHIY-0005UY-OR; Tue, 18 Aug 2026 10:44:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393945.1632748; Tue, 18 Aug 2026 10:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHIY-0005UQ-IO; Tue, 18 Aug 2026 10:44:02 +0000
Received: by outflank-mailman (input) for mailman id 1393945;
 Tue, 18 Aug 2026 10:44:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwHIW-0005UK-Tw
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:44:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwHIW-00BLoZ-AW
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:44:00 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a843761-2eae-0a2a0a5409dd-0a2a4506c166-28
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:44:00 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84376c-195a-0a2a45060019-d1558034e853-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:43:57 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4954f5e8020so23503745e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 03:43:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996109652sm299552755e9.4.2026.08.18.03.43.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 03:43:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787049836; x=1787654636; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ZA67QQ3LFQeABYIel3pFcNF5s6j7atqy/CSoHYn97Kk=;
        b=XVF8GzC5Nj4YtZGduNSKX4s9LOBxZkcqSOLz/1nYQZfLvJhEGdJ9mm5T/i25zcXEex
         JG9df4u3zSR1XVPkpafEKEr/MCl886iom+ULm8xYxR3MTzQxinYSN383fkZLjWqS47Wf
         Gj6ic4MOEN5tdMW2tOB836VFhjmFOPBe+4GSQ5evdfCnBGSYdBZofnNydcyFBsXxzrbj
         qGu0szCa7TelXAAhjFW311phKYwUoMP2+ER4BjW+HVml7/C3Km+WmkCpFpK7YOS2Dgsf
         Z8826uXBO/PnRqb6ox6+zjaqhJM0m96stph1FJ2R6ROMP4bWTopUpzgemDSmPEe8FOw9
         L1PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787049836; x=1787654636;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ZA67QQ3LFQeABYIel3pFcNF5s6j7atqy/CSoHYn97Kk=;
        b=FDrYUUthRyF770Rjpa14sz2r3XPbF+YmfTjN+E88Q23HxAC5Wx5YFUiC+DCiNYT6Za
         gkNhv94V0CiFDoaMrFYVCW4rOcB0xISxbI/P0igZgmPnFruJ7tRLmu3V+8xjxgk2l0IS
         YXIuJgSWsHK7pX//+nFP9uLrhBY2gwV1VXIRj+s2I7jHPxhDq5zmvZ846D141l3qjF2P
         wE9PULiYjsTLFCpLQ5hi0p4GsnlUYyxDkmxohwR0uVhz9+fUgFjieV+iwTfA/U5ykaET
         9RfsMNlBugDa7nznHuqMKmvwrf44BZBJoNH7B0k4kr9/ir0RmwJT2gCdh4zzTWLFboeG
         4Qzg==
X-Forwarded-Encrypted: i=1; AHgh+RoxTYdBahBXbIlaMx2gwUJb1xbRSau1nH8QpzQ7RgbYcbdE5kz0DJ0yBfLyDIPwwQxScp+5hKb1lSw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyT600qiMnRrfd8hMiT2AZG0K6OlQpsNZxTZOlVCY4Beay/3xHc
	qB9stfqSdpaVzihs/JWQ9HbWFP/9BUWcuC8jVMxgKdT2lO7Q6KXQ8sv+jp/wR44dJA==
X-Gm-Gg: AR+sD12V4BHjrDCrrTV7r6cu7uA6+pLOOfYUaC4bNQ9N3166ky7burobzhOP3lDwhBH
	FOccYgianV81r+duf6m9WeAoj76+rWylunH/5uHUbgg/MGVv/pJXNYh5UTAvZoNcDpWKNX5VRiC
	Ec1fO+niSooS6UFntq/TonQP3f2zgDD93pdoQ9Xqm8ZTsGWmBcj3nodSRK8858WbZk/Vf7p7miV
	0jnXVVNdBN1P1qg1WdBPTqe8+lcrAfK/2nBgN0zVFAqk9lZcwPrAemnqZklmfJORy9XPfcywatA
	+DhQkV7x8PzNXDIQl/dBki84Wq3yoTrPKRiYHHB4GaPvZh1Rd19qppHBoI3z67ZzTWg07cmK49v
	BS9kJpB3pbAhkuw+1dTSoWnjbHLOxb3PG28imN6mGbrw+PDnucYjnRKtIVSWqg+qWR4fzsv2s/h
	EQTAFXeCVZ1HtXTdyWU7G+Zbg6hPzkkRITm8N7fE9iv1a0Zu5i9vwVMbocRYBDvq+AAiHdwqhM6
	NCPgSNOkHuJkgP3RAxvAr4bj1DbmCWcGvv1sGRE0gapzGZ0Ma2j
X-Received: by 2002:a05:600c:1988:b0:496:c93d:e2f with SMTP id 5b1f17b1804b1-4998798dc17mr480155675e9.15.1787049836615;
        Tue, 18 Aug 2026 03:43:56 -0700 (PDT)
Message-ID: <5ee55d9c-d0f8-41cc-8d4e-3ba6c08d7506@suse.com>
Date: Tue, 18 Aug 2026 12:43:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
 <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
 <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
 <2ca3f802-bf93-4714-8a9b-e33ab0c89300@suse.com>
 <d94bd15a-bf99-4df5-9dac-1fe0fcb77cfc@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <d94bd15a-bf99-4df5-9dac-1fe0fcb77cfc@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787049837-1ECC577B-98B4DCC5/0/0
X-purgate-type: clean
X-purgate-size: 4858

On 18.08.2026 12:27, Oleksii Kurochko wrote:
> On 8/18/26 10:17 AM, Jan Beulich wrote:
>> On 17.08.2026 17:36, Oleksii Kurochko wrote:
>>> On 8/12/26 5:30 PM, Jan Beulich wrote:
>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>> +    if ( read_insn )
>>>>> +    {
>>>>> +        asm volatile ( "\n"
>>>>> +            "1:\n"
>>>>> +            "   hlvx.hu %[val], (%[addr])\n"
>>>>> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])
>>>>> +            "   andi %[tmp], %[val], 3\n"
>>>>> +            "   addi %[tmp], %[tmp], -3\n"
>>>>> +            "   bne %[tmp], zero, 3f\n"
>>>>> +            "   addi %[addr], %[addr], 2\n"
>>>>> +            "\n"
>>>>> +            "2:\n"
>>>>> +            "   hlvx.hu %[tmp], (%[addr])\n"
>>>>> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
>>>>> +            "   sll %[tmp], %[tmp], 16\n"
>>>>> +            "   add %[val], %[val], %[tmp]\n"
>>>>> +            "3:\n"
>>>>> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
>>>>> +        : [ti] "r" (trap) : "memory" );
>>>>
>>>> You want to tell the compiler that *trap is written. Instead I don't see
>>>> why a memory clobber would be needed: You access a different address space,
>>>> i.e. nothing the compiler can make any assumptions about.
>>>
>>> memory clobber tells the compiler that the assembly code performs memory
>>> reads or writes to items other than those listed in the input and output
>>> operands and so I don't tell here that *trap will be changed.
>>>
>>> Why this understanding is wrong?
>>
>> You can (ab)use "memory" for that purpose, but why would you when you can
>> properly express the operand? All that achieves is the compiler possibly
>> having to emit less efficient code.
> 
> Then I will use the option mentioned ...
> 
>>
>>> Alternative, I think, could be:
>>>           : [val] "+r" (val), "+m" (*trap)
>>>           : [addr] "r" (guest_addr), [ti] "r" (trap) );
>>> And then memory clobber could be dropped.
> 
> ... here.
> 
> Probably I have to return '[addr] "r" (guest_addr)' to output and use 
> +&r constraint.
> 
>>>> You also need to take precautions for not returning an uninitialized "val".
>>>> I think the variable wants initializing (perhaps to ~0) and "+r" wants
>>>> using as constraint. (Afaik & isn't necessary to use together with +.)
>>>
>>> I agree with '+' if we will initialize val with some value.
>>>
>>> Regarding, '&' my understanding is that I have to use it always when
>>
>> When what exactly? If an operand is both input and output, how could the
>> compiler re-use the (generally) register for any further purpose? '&'
>> indicates to the compiler that it may not use the register used for an
>> output to hold some input's value, as that value may be lost by the time
>> the input is actually consumed.
> 
> But what is written in the gcc doc:
> 
> & - Means (in a particular alternative) that this operand is an 
> earlyclobber operand, which is written before the instruction is 
> finished using the input operands.
> 
> What sounds like if an operand (val) in our case is written before the 
> instruction which using the input operands (and after the write 
> instuction which writes val there are instructions which are using input 
> operands) it is needed to have &.

And that's indeed relevant, just not here. My crucial earlier question was:
"If an operand is both input and output, how could the compiler re-use the
(generally) register for any further purpose?" There is a case where the
answer to this is not "it can't". In your case all inputs are distinct; in
e.g. (using x86 assembly, sorry):

int test(int i, int j) {
	asm("nop %0; nop %1" : "+r" (i) : "r" (i));
	asm("cmc; nop %0; nop %1" : "+&r" (j) : "r" (j));

	return i + j;
}

using "+&r" indeed makes a difference.

> t1:  hlvx.hu %[val], (%[addr])   W:val R:addr + can trap -> read register ti
> 
> t2:  andi    %[tmp], %[val], 3   W:tmp   R:val
> t3:  addi    %[tmp], %[tmp], -3
> t4:  bnez    %[tmp], 3f
> t5:  addi    %[addr], %[addr], 2 W:addr  R:addr
> t6:  hlvx.hu %[tmp], (%[addr])   W:tmp   R:addr + can trap -> read 
> register ti
> 
> t7:  slli    %[tmp], %[tmp], 16
> t8:  or      %[val], %[val], %[tmp] W:val
> 
> So val is written on t1 before t6 where addr and ti still alive.
> 
> The similar is for [addr] "+&r" (guest_addr):
> 
> addr is written on t5 and input ti is alive till t6. So if allocator 
> will allocate the same register for addr and ti then addi %[addr], 
> %[addr], 2 will break a pointer and handler will get something wrong.
> 
> Am I missing something?
> 
> If I am still wrong then in both cases should be just "+r"?

As per above, if you want to play absolutely by the rules, use "+&r",
even if that's unnecessary here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:47:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:47:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393954.1632755 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHME-00065q-3p; Tue, 18 Aug 2026 10:47:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393954.1632755; Tue, 18 Aug 2026 10:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHME-00065j-12; Tue, 18 Aug 2026 10:47:50 +0000
Received: by outflank-mailman (input) for mailman id 1393954;
 Tue, 18 Aug 2026 10:47:48 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwHMC-00064H-1t
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:47:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwHMA-00BMMf-Rm
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:47:46 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a843837-2eae-0a2a0a5409dd-0a2a45049f6e-44
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:47:46 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a843852-b57f-0a2a45040019-c387df83e2cc-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:47:46 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 76E0D3E4A;
 Tue, 18 Aug 2026 10:47:34 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 4681722BA;
 Tue, 18 Aug 2026 10:47:34 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 1KegD0Y4hGpDJwAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 18 Aug 2026 10:47:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787050058; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Zm1OIKnWNLDe+fPcFREt3GIochIMEEweQR0cKalomks=;
	b=rs6Q7d/XGVGFNNSRm2rfHvRl0lJOXiRzaxOsxdT5wF6oN1TaChRmjtbhuH7MtxkAR+7Hkf
	nrhu/yHq/exnet0U2IXXDIA0O6xys5AS23rMdESQtqxAtaNhxQiEoBeskvxjUQ7Rq1U7Xg
	Agtc5T25D1qJkdqE+uugFc02BOoaM2k=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787050054; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=Zm1OIKnWNLDe+fPcFREt3GIochIMEEweQR0cKalomks=;
	b=RrYCv1rOWkpb514kmvRYOc4lXD/qDQvWe1/PDbEFqvyFM5bzBWqX6altIZWFnuvmWOdy4K
	sX1r4n5gFs8ZAoa63cY7MOcd0ylnjQEF1M6x/PcArRYSQeThSPwZCo9XDSX4l8QdKyr7vY
	RrGdLHnV21Kr5VAGyyygtE/qtd5Rk18=
Message-ID: <27889c5e-ff00-4209-9b7e-674cd145442e@suse.com>
Date: Tue, 18 Aug 2026 12:47:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
 <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
 <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------HIn7oqEkWLG6yHL03DqUoyxz"
X-Spam-Score: -6.19
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-6.19 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.989];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.999];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	RCVD_TLS_ALL(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_SOME(0.00)[];
	FREEMAIL_TO(0.00)[citrix.com,gmail.com,lists.xenproject.org];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCPT_COUNT_FIVE(0.00)[6];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	HAS_ATTACHMENT(0.00)[]
X-purgate-ID: tlsNG-ebf023/1787050066-538C1B50-6E878E36/0/0
X-purgate-type: clean
X-purgate-size: 14501

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------HIn7oqEkWLG6yHL03DqUoyxz
Content-Type: multipart/mixed; boundary="------------X7grn7hpczWpj6TPR95lMoie";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org
Message-ID: <27889c5e-ff00-4209-9b7e-674cd145442e@suse.com>
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
 <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
 <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
In-Reply-To: <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------X7grn7hpczWpj6TPR95lMoie
Content-Type: multipart/mixed; boundary="------------Hr6LP4AM9ISu7BxeozvC4NC3"

--------------Hr6LP4AM9ISu7BxeozvC4NC3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTguMDguMjYgMTI6MzUsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IE9uIDE4LzA4LzIw
MjYgMTE6MTMgYW0sIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+PiBPbiAxOC4wOC4yNiAxMjow
NCwgQW5kcmV3IENvb3BlciB3cm90ZToNCj4+PiBPbiAxOC8wOC8yMDI2IDg6NTMgYW0sIEZ1
cmthbiDDh2FsxLHFn2thbiB3cm90ZToNCj4+Pj4gT24gOC8xOC8yNiAxMDoxMSwgSsO8cmdl
biBHcm/DnyB3cm90ZToNCj4+Pj4+IE9uIDE4LjA4LjI2IDA4OjMyLCBGdXJrYW4gQ2FsaXNr
YW4gd3JvdGU6DQo+Pj4+Pj4gc2NoZWRfbW92ZV9kb21haW4oKSBkZXJpdmVzIHRoZSBudW1i
ZXIgb2YgdW5pdHMgdG8gcmVidWlsZCBmcm9tDQo+Pj4+Pj4gZC0+bWF4X3ZjcHVzLCB3aGlj
aCBpcyBmaXhlZCBhdCBkb21haW4gY3JlYXRpb24gYW5kIG5ldmVyIHJvbGxlZA0KPj4+Pj4+
IGJhY2sgaWYgdmNwdV9jcmVhdGUoKSBmYWlscyBwYXJ0d2F5IHRocm91Z2ggYnVpbGRpbmcg
YSBkb21haW4uIFNvDQo+Pj4+Pj4gZC0+dmNwdVtpXSBjYW4gYmUgTlVMTCBmb3Igc29tZSBp
IGV2ZW4gdGhvdWdoIG1heF92Y3B1cyBzdGlsbA0KPj4+Pj4+IGNvdW50cyBpdCAtIHRoaXMg
aGFwcGVucyBpZiBzY2hlZF9hbGxvY191ZGF0YSgpIHJldHVybnMgTlVMTC4NCj4+Pj4+Pg0K
Pj4+Pj4+IFRoZSBwZXItdW5pdCBsb29wIGRvZXNuJ3QgY2hlY2sgZm9yIHRoaXM6IGl0IHNl
dHMNCj4+Pj4+PiB1bml0LT52Y3B1X2xpc3QgPSBkLT52Y3B1W3VuaXRfaWRdIChOVUxMKSBh
bmQgaGFuZHMgdGhhdCBicm9rZW4NCj4+Pj4+PiB1bml0IHN0cmFpZ2h0IHRvIHRoZSBkZXN0
aW5hdGlvbiBzY2hlZHVsZXIncyBhbGxvY191ZGF0YSgpLA0KPj4+Pj4+IHdoaWNoIGFzc3Vt
ZXMgdmNwdV9saXN0IGlzIGFsd2F5cyB2YWxpZCBhbmQgY3Jhc2hlcyBYZW4gd2hlbg0KPj4+
Pj4+IGl0IGlzIG5vdC4NCj4+Pj4+Pg0KPj4+Pj4+IFJlcHJvZHVjZWQgYnkgYnVpbGRpbmcg
YSBkb21haW4gaW4gYSBub24tZGVmYXVsdCBjcHVwb29sIHdoZXJlDQo+Pj4+Pj4gdmNwdSBj
cmVhdGlvbiBmYWlscyBwYXJ0d2F5IHRocm91Z2gsIHRoZW4gZGVzdHJveWluZyBpdC4NCj4+
Pj4+PiBkb21haW5fa2lsbCgpIG1vdmVzIHRoZSBkb21haW4gYmFjayB0byB0aGUgZGVmYXVs
dCBjcHVwb29sIHZpYQ0KPj4+Pj4+IHNjaGVkX21vdmVfZG9tYWluKCkgYmVmb3JlIGFjdHVh
bGx5IGRlc3Ryb3lpbmcgaXQsIGNyYXNoaW5nDQo+Pj4+Pj4gaW5zaWRlIHRoZSBkZXN0aW5h
dGlvbiBzY2hlZHVsZXIncyBhbGxvY191ZGF0YSgpIChzZWVuIGluDQo+Pj4+Pj4gQ3JlZGl0
MidzIGNzY2hlZDJfYWxsb2NfdWRhdGEoKSAtPiBpc19pZGxlX3VuaXQoKSAtPiBOVUxMIGRl
cmVmKS4NCj4+Pj4+Pg0KPj4+Pj4+IEJlZm9yZSBidWlsZGluZyBhIHVuaXQgaW4gc2NoZWRf
bW92ZV9kb21haW4oKSwgY2hlY2sgdGhhdCBhbGwgb2YNCj4+Pj4+PiBpdHMgdmNwdSBzbG90
cyBhcmUgcG9wdWxhdGVkLCBhbmQgc2tpcCBpdCBpZiBhbnkgYXJlIG1pc3NpbmcuIFRoZQ0K
Pj4+Pj4+IHJlc3Qgb2YgdGhlIGZ1bmN0aW9uIHdhbGtzIHRoZSB2Y3B1cyB0aGF0IGFjdHVh
bGx5IGV4aXN0LCB2aWENCj4+Pj4+PiBmb3JfZWFjaF92Y3B1KCkgcmF0aGVyIHRoYW4gbl91
bml0cywgc28gc2tpcHBpbmcgYSB1bml0IGhlcmUNCj4+Pj4+PiBkb2VzIG5vdCBsZWF2ZSBh
bnl0aGluZyBlbHNlIG91dCBvZiBzeW5jLg0KPj4+Pj4+DQo+Pj4+Pj4gU2lnbmVkLW9mZi1i
eTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPj4+Pj4+IC0t
LQ0KPj4+Pj4+ICDCoMKgIHhlbi9jb21tb24vc2NoZWQvY29yZS5jIHwgMTkgKysrKysrKysr
KysrKysrKysrKw0KPj4+Pj4+ICDCoMKgIDEgZmlsZSBjaGFuZ2VkLCAxOSBpbnNlcnRpb25z
KCspDQo+Pj4+Pj4NCj4+Pj4+PiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZC9jb3Jl
LmMgYi94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYw0KPj4+Pj4+IGluZGV4IGQzYTBhOTdlMWQu
LmQ1NDJjNzY1NDMgMTAwNjQ0DQo+Pj4+Pj4gLS0tIGEveGVuL2NvbW1vbi9zY2hlZC9jb3Jl
LmMNCj4+Pj4+PiArKysgYi94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYw0KPj4+Pj4+IEBAIC03
NDUsNiArNzQ1LDI1IEBAIGludCBzY2hlZF9tb3ZlX2RvbWFpbihzdHJ1Y3QgZG9tYWluICpk
LA0KPj4+Pj4+IHN0cnVjdCBjcHVwb29sICpjKQ0KPj4+Pj4+ICDCoMKgIMKgwqDCoMKgwqAg
Zm9yICggdW5pdF9pZHggPSAwOyB1bml0X2lkeCA8IG5fdW5pdHM7IHVuaXRfaWR4KysgKQ0K
Pj4+Pj4+ICDCoMKgwqDCoMKgwqAgew0KPj4+Pj4+ICvCoMKgwqDCoMKgwqDCoCAvKg0KPj4+
Pj4+ICvCoMKgwqDCoMKgwqDCoMKgICogU2tpcCB0aGlzIHVuaXQgaWYgYW55IG9mIGl0cyB2
Y3B1cyBpcyBtaXNzaW5nLiBCb3VuZGVkIGJ5DQo+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqAg
KiBtYXhfdmNwdXMuDQo+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqAgKi8NCj4+Pj4+PiArwqDC
oMKgwqDCoMKgwqAgYm9vbCB2Y3B1X2ZhaWxlZCA9IGZhbHNlOw0KPj4+Pj4+ICsNCj4+Pj4+
PiArwqDCoMKgwqDCoMKgwqAgZm9yICggdW5zaWduZWQgaW50IGkgPSAwOw0KPj4+Pj4+ICvC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpIDwgZ3JhbiAmJiB1bml0X2lkeCAqIGdyYW4g
KyBpIDwgZC0+bWF4X3ZjcHVzOyBpKysgKQ0KPj4+Pj4+ICvCoMKgwqDCoMKgwqDCoCB7DQo+
Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCAhZC0+dmNwdVt1bml0X2lkeCAq
IGdyYW4gKyBpXSApDQo+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgew0KPj4+Pj4+
ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdmNwdV9mYWlsZWQgPSB0cnVlOw0K
Pj4+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYnJlYWs7DQo+Pj4+Pj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfQ0KPj4+Pj4+ICvCoMKgwqDCoMKgwqDCoCB9DQo+
Pj4+Pj4gKw0KPj4+Pj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAoIHZjcHVfZmFpbGVkICkNCj4+
Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjb250aW51ZTsNCj4+Pj4+IEkgZG9uJ3Qg
dGhpbmsgdGhpcyBpcyBjb3JyZWN0Lg0KPj4+Pj4NCj4+Pj4+IElmIHRoZXJlIGFyZSBzb21l
IHZjcHVzIGluIHRoZSB1bml0IHlvdSB3aWxsIGxvb3NlIHRoZW0gKGkuZS4gbWFrZQ0KPj4+
Pj4gdGhlbSBubw0KPj4+Pj4gbG9uZ2VyIGJlIGFibGUgdG8gYmUgc2NoZWR1bGVkKSwgcmln
aHQ/DQo+Pj4+Pg0KPj4+Pj4gRm9yIGEgZHlpbmcgZG9tYWluIHRoaXMgbWlnaHQgYmUgb2th
eSwgYnV0IG5vdCBmb3Igb25lIHN0aWxsDQo+Pj4+PiBhY3RpdmUuIFNvIEkgdGhpbmsNCj4+
Pj4+IHlvdSBzaG91bGQgYXQgbGVhc3QgdmVyaWZ5IHRoZSBkb21haW4gaXMgZHlpbmcsIG90
aGVyd2lzZQ0KPj4+Pj4gc2NoZWRfbW92ZV9kb21haW4oKQ0KPj4+Pj4gc2hvdWxkIGp1c3Qg
ZmFpbC4NCj4+Pj4+DQo+Pj4+PiBBbiBhbHRlcm5hdGl2ZSBtaWdodCBiZSB0byBmaXggdGhl
IE5VTEwgZGVyZWZlcmVuY2luZyB3aGVyZSBuZWVkZWQsDQo+Pj4+PiBidXQgdGhpcw0KPj4+
Pj4gY291bGQgYmVjb21lIHRlZGlvdXMuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEp1ZXJnZW4N
Cj4+Pj4gUmlnaHQuIE15IGluaXRpYWwgYXR0ZW1wdCBvbmx5IGNoZWNrZWQgJ2QtPnZjcHVb
dW5pdF9pZHgqZ3Jhbl0nDQo+Pj4+IGZvciB0aGUgaGVhZCB2Q1BVLiBUaGUgY3Jhc2ggaGFw
cGVucyB3aGVuIHVuaXQtPnZjcHVfbGlzdCBpcyBzZXQNCj4+Pj4gdG8gZC0+dmNwdVt1bml0
X2lkeCpncmFuXSAod2hpY2ggaXMgTlVMTCkgYW5kIHBhc3NlZCB0bw0KPj4+PiAnYWxsb2Nf
dWRhdGEoKScsDQo+Pj4+IGNhdXNpbmcgYSBOVUxMIGRlcmVmZXJlbmNlLg0KPj4+Pg0KPj4+
PiBJIGV4cGFuZGVkIHRoZSBsb29wIG92ZXIgJ2dyYW4nIHRvIGhhbmRsZSBjb3JlLXNjaGVk
dWxpbmcgY2FzZXMgd2hlcmUgYQ0KPj4+PiBzdWJzZXF1ZW50IHZDUFUgZmFpbHMgbWlkLXVu
aXQsIGJ1dCBhcyB5b3UgcG9pbnRlZCBvdXQsIHRoYXQgZHJvcHMgdGhlDQo+Pj4+IHdob2xl
IHVuaXQgZm9yIGFjdGl2ZSBkb21haW4uDQo+Pj4+DQo+Pj4+IEknbGwgdXBkYXRlIHRoZSBw
YXRjaCB0byBjaGVjayBkLT5pc19keWluZyB0byBza2lwIGluY29tcGxldGUgdW5pdHMNCj4+
Pj4gb25seSBmb3IgZHlpbmcgZG9tYWlucywgYW5kIGhhdmUgc2NoZWRfbW92ZV9kb21haW4o
KSBmYWlsIGlmIGFuIGFjdGl2ZQ0KPj4+PiBkb21haW4gaGFzIG1pc3NpbmcgdkNQVXMNCj4+
Pg0KPj4+IEknbSBhZnJhaWQgdGhhdCB3b250IGZpeCBldmVyeXRoaW5nLg0KPj4NCj4+IFdo
eSBub3Q/DQo+IA0KPiBkb21VJ3MgaW4gdGhpcyBzaXR1YXRpb24gZG8gbm90IGhhdmUgaXNf
ZHlpbmcgc2V0Lg0KDQpQbGVhc2UgY2xhcmlmeSB3aGF0IHlvdSBtZWFuIHdpdGggInRoaXMg
c2l0dWF0aW9uIi4NCg0Kc2NoZWRfbW92ZV9kb21haW4oKSBpcyBiZWluZyBjYWxsZWQgZWl0
aGVyIGR1ZSB0byBhbiBhZG1pbiBhY3Rpb24NCigieGwgY3B1cG9vbC1taWdyYXRlIiksIG9y
IGR1cmluZyBkb21haW5fa2lsbCgpIGluIG9yZGVyIHRvIG1vdmUgdGhlDQpkb21haW4gdG8g
Y3B1cG9vbDAgZm9yIGF2b2lkaW5nIGEgem9tYmllIGRvbWFpbiBibG9ja2luZyBjcHVwb29s
DQpyZW1vdmFsLg0KDQpUaGUgZmlyc3QgY2FzZSBpcyBhbGxvd2VkIHRvIGZhaWwsIHdoaWNo
IHRoZSBzdWdnZXN0ZWQgZml4IHdvdWxkIGRvLA0Kd2hpbGUgdGhlIHNlY29uZCBjYXNlIGlz
IGhhcHBlbmluZyBvbmx5IGFmdGVyIERPTURZSU5HX2R5aW5nIGhhcyBiZWVuDQpzZXQgZm9y
IHRoZSBkb21haW4uDQoNCg0KSnVlcmdlbg0K
--------------Hr6LP4AM9ISu7BxeozvC4NC3
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------Hr6LP4AM9ISu7BxeozvC4NC3--

--------------X7grn7hpczWpj6TPR95lMoie--

--------------HIn7oqEkWLG6yHL03DqUoyxz
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqEOEUFAwAAAAAACgkQsN6d1ii/Ey/5
2QgAir7+RRdj7Ppt76PZ+PY/ynyBAS2m+1QjvErVZlp6atv8ZcyUy6irqmaf16M/YDLxM7/t+QFc
lDIiqZKDoH1CWOgp7QDg8ZsP45Zj/4MyRaScucfCGzLH9bOqX+UPzPe31f8LmFCXKOyHE16m7kGt
WfNnJAwMsEvmr6GPAPJrpdN223F7wL7T1XHL9iGG5Df56YXxh4L7wQk1XmlFRAOWdBJZIsZzwoFr
6cs9wTSs1Zivt+upHUxACS5YFCREcdUP5S0Y+UmivObcwD/B18nZwNULBOxTfXHs5CZ8NcJcSRZu
SqlrmWuvo7Dn5B9Gq/bKyEEy66UfvpA58k6HPpt5GA==
=poQi
-----END PGP SIGNATURE-----

--------------HIn7oqEkWLG6yHL03DqUoyxz--


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 10:54:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 10:54:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393964.1632766 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHS9-0007sA-S8; Tue, 18 Aug 2026 10:53:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393964.1632766; Tue, 18 Aug 2026 10:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHS9-0007s3-OD; Tue, 18 Aug 2026 10:53:57 +0000
Received: by outflank-mailman (input) for mailman id 1393964;
 Tue, 18 Aug 2026 10:53:57 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwHS9-0007rx-8I
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 10:53:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwHS8-00BNXs-Gi
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:53:56 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8439c2-e002-0a2a0a5209dd-0a2a4508c304-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:53:56 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8439c4-f659-0a2a45080019-d155802fb89b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 12:53:56 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so55488425e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 03:53:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499877d5548sm271817045e9.1.2026.08.18.03.53.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 03:53:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787050436; x=1787655236; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=p0dZ8OLjSVhKzdaD3CgraNN7o0yOzCiOTjMA4RIB0yk=;
        b=Czkavsu4WsYxQP3GrZMmg53rVVUsE0sPAIZbdd1/8XeJl2xmHNurl2ReeGhnPZUK9p
         lGMggzWdn6tMc9xdzG/UFXGmIIlHCKmLw1aB1OqbcIimiPW4pdIaZVlxfrPFUHU/YnIm
         +evJWQsYb1cmL2ueytBN8N9KVZh8Ww1wU1dlvfkvGKqXQB5eokqcvLpUGIspCJ4tluev
         cdPoFJC4+77jtewiX0ADyN5ujzkoQPFE3jYMRU5QP1iNC/jD0Y0yxFL99ZA/F3zM/Ygn
         FwgsG21JJLVcvVPSCoryvR81LOwS7F2RPJzLwkjjD4eZMg/qQ0dpU204HsMIdkmzxtvc
         7hAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787050436; x=1787655236;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=p0dZ8OLjSVhKzdaD3CgraNN7o0yOzCiOTjMA4RIB0yk=;
        b=d4rMWfBVyJ5m5Fri6jX1uaDqIAGwgqUsYQrcgDkQCMG35gVGOq633e1E+QWHk1RLXd
         y0PdpCgwT4g40+hz7ZMmQ0EQRxvOU24Yc29HJ61r0g6sW0R8ckaXceiWXJF8CofyFWYg
         QQTS41c34iX4jcDJR0DPF4+D5XPYmFqWL9MJ5ECu+YjcagUCWbOHQDvuL2fDtTkVE58m
         CDdoSbxPX0rX4Aw0p2f8V9vC8uHqbmL9YfmhRHvVFH/HcKBke8hmOCVWgWdK0pPj9rX9
         ye1uk0ITxSqJgKg3kmZOS6heZTvWEr+PsEaFGO3iWMr2DkgCtkNiU112WEgbtSUoebro
         iNaQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr7v+XBzshr8tz1wj9sU1geJoFI2kuEkzx6zINcPdDr/0GXTFf8JcNlBhEZdwuv+bNffhGvpGQIoVM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfdX/Q6stFFlqrP/Wz42cKXbDkiDwbVV1IB8TV0x0ixJ0yzdD2
	lpCgBFOfMuSJWsueoQgP8Dkw+KUm2HTmg3Z3Vuf5UQNzqtlh5tC/Hq77h0159UzW+g==
X-Gm-Gg: AR+sD11ZcX2+kCJEqlP6KjOr4xLf5ieMIeu6haHVanItCjO0dbWidy5rZYKHbNkT+4K
	1ztCd7xa4/YNHNDHyIHNHyhOmOVhK9Z/Di1nkK3JftcAiabshiIQL+GXiHHBbGUjyMjI7SBdXwK
	4/Dr2rVk75tzk2mbKHvi1agL5pDnvBOJPUWcoNEQ3/zlacwpDf21F1Qrdi+LgUiewqTOE+lVnVc
	fKRiiLE5oVpzx6Qs24RQquNRop8W1u7/B7xkqi++k5I+hFVZRKEUdOoLGBdWY/vz7N2opUl5n0C
	z97vIsgr6NAet3WYldbhbyYaHcD78GMPLIlzfRVQd6MJkSRA+YD0YHg9gebXBVfmg6qjsYXKPfi
	D1m/K0GBzmOukeF9xQHNZc3L1zQUSPRzadU0FEp+BEcF4cxynDLC7sV3IhoNqfdNVOKBX1frmny
	ClI2pjEyeRgaidIGwcq5mqn4BiybaWcLxb/Hzy4YUjM0fuUF1nVk8DRxZSGl72eLcwaBYK9E0pU
	i3KEtaoYZWuaVPW735k4cxFAyyAudTpUQhXeou13p9kMW+gdqP8
X-Received: by 2002:a05:600c:528d:b0:499:48be:3189 with SMTP id 5b1f17b1804b1-4999fa84b7dmr141772645e9.0.1787050435812;
        Tue, 18 Aug 2026 03:53:55 -0700 (PDT)
Message-ID: <48825846-fd82-423c-9133-9221a629aa10@suse.com>
Date: Tue, 18 Aug 2026 12:53:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: dfaggioli@suse.com, gwd@xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?=
 <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
 <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
 <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787050436-D5B4987B-499EA0F6/0/0
X-purgate-type: clean
X-purgate-size: 4658

On 18.08.2026 12:35, Andrew Cooper wrote:
> On 18/08/2026 11:13 am, Jürgen Groß wrote:
>> On 18.08.26 12:04, Andrew Cooper wrote:
>>> On 18/08/2026 8:53 am, Furkan Çalışkan wrote:
>>>> On 8/18/26 10:11, Jürgen Groß wrote:
>>>>> On 18.08.26 08:32, Furkan Caliskan wrote:
>>>>>> sched_move_domain() derives the number of units to rebuild from
>>>>>> d->max_vcpus, which is fixed at domain creation and never rolled
>>>>>> back if vcpu_create() fails partway through building a domain. So
>>>>>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>>>>>> counts it - this happens if sched_alloc_udata() returns NULL.
>>>>>>
>>>>>> The per-unit loop doesn't check for this: it sets
>>>>>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>>>>>> unit straight to the destination scheduler's alloc_udata(),
>>>>>> which assumes vcpu_list is always valid and crashes Xen when
>>>>>> it is not.
>>>>>>
>>>>>> Reproduced by building a domain in a non-default cpupool where
>>>>>> vcpu creation fails partway through, then destroying it.
>>>>>> domain_kill() moves the domain back to the default cpupool via
>>>>>> sched_move_domain() before actually destroying it, crashing
>>>>>> inside the destination scheduler's alloc_udata() (seen in
>>>>>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>>>>>
>>>>>> Before building a unit in sched_move_domain(), check that all of
>>>>>> its vcpu slots are populated, and skip it if any are missing. The
>>>>>> rest of the function walks the vcpus that actually exist, via
>>>>>> for_each_vcpu() rather than n_units, so skipping a unit here
>>>>>> does not leave anything else out of sync.
>>>>>>
>>>>>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>>>>>> ---
>>>>>>    xen/common/sched/core.c | 19 +++++++++++++++++++
>>>>>>    1 file changed, 19 insertions(+)
>>>>>>
>>>>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>>>>>> index d3a0a97e1d..d542c76543 100644
>>>>>> --- a/xen/common/sched/core.c
>>>>>> +++ b/xen/common/sched/core.c
>>>>>> @@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d,
>>>>>> struct cpupool *c)
>>>>>>          for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>>>>>        {
>>>>>> +        /*
>>>>>> +         * Skip this unit if any of its vcpus is missing. Bounded by
>>>>>> +         * max_vcpus.
>>>>>> +         */
>>>>>> +        bool vcpu_failed = false;
>>>>>> +
>>>>>> +        for ( unsigned int i = 0;
>>>>>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>>>>>> +        {
>>>>>> +            if ( !d->vcpu[unit_idx * gran + i] )
>>>>>> +            {
>>>>>> +                vcpu_failed = true;
>>>>>> +                break;
>>>>>> +            }
>>>>>> +        }
>>>>>> +
>>>>>> +        if ( vcpu_failed )
>>>>>> +            continue;
>>>>> I don't think this is correct.
>>>>>
>>>>> If there are some vcpus in the unit you will loose them (i.e. make
>>>>> them no
>>>>> longer be able to be scheduled), right?
>>>>>
>>>>> For a dying domain this might be okay, but not for one still
>>>>> active. So I think
>>>>> you should at least verify the domain is dying, otherwise
>>>>> sched_move_domain()
>>>>> should just fail.
>>>>>
>>>>> An alternative might be to fix the NULL dereferencing where needed,
>>>>> but this
>>>>> could become tedious.
>>>>>
>>>>>
>>>>> Juergen
>>>> Right. My initial attempt only checked 'd->vcpu[unit_idx*gran]'
>>>> for the head vCPU. The crash happens when unit->vcpu_list is set
>>>> to d->vcpu[unit_idx*gran] (which is NULL) and passed to
>>>> 'alloc_udata()',
>>>> causing a NULL dereference.
>>>>
>>>> I expanded the loop over 'gran' to handle core-scheduling cases where a
>>>> subsequent vCPU fails mid-unit, but as you pointed out, that drops the
>>>> whole unit for active domain.
>>>>
>>>> I'll update the patch to check d->is_dying to skip incomplete units
>>>> only for dying domains, and have sched_move_domain() fail if an active
>>>> domain has missing vCPUs
>>>
>>> I'm afraid that wont fix everything.
>>
>> Why not?
> 
> domU's in this situation do not have is_dying set.

Yet isn't the (separate) bug then that we allow a DomU to be launched when
XEN_DOMCTL_max_vcpus didn't finish setting up all vCPU-s? Or is that what
you were alluding to? Since you did say "..., and we may even want to
schedule in this scenario" - perhaps not.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:24:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:24:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393981.1632787 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHvK-0004CI-6t; Tue, 18 Aug 2026 11:24:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393981.1632787; Tue, 18 Aug 2026 11:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHvK-0004CB-2O; Tue, 18 Aug 2026 11:24:06 +0000
Received: by outflank-mailman (input) for mailman id 1393981;
 Tue, 18 Aug 2026 11:24:04 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wwHvI-0004C5-Gn
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:24:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwHvH-00BSBZ-BF
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:24:03 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8440c7-2eae-0a2a0a5409dd-0a2a450be122-36
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:24:03 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8440d1-b7e8-0a2a450b0019-aa0a857c684b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:24:02 +0200
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-494-FnY6rZmLPsOFiEotG4IUNg-1; Tue,
 18 Aug 2026 07:23:55 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id CF20B1955E70; Tue, 18 Aug 2026 11:23:46 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 41DF81800346; Tue, 18 Aug 2026 11:22:47 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787052241;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=h64XN1WLxAYWIvGPaSy4g9mn7J0U93E0Dk0P5R8MRfI=;
	b=INb6GzL+lsmdI8cSqdr6fp+czoDhgfN3e4P9gomdNgin9boStEq01iITh8S6ySdgov8r5S
	/Hs1O8I2fvxPHkpeCFHmA1oBMtKZdSOtlFQRHuWsDnLok+fRfdabZR11rrJt/xEiF7x1fu
	LqYx0BQHuGrsQtTIndAN6Nk0JB+3hLA=
X-MC-Unique: FnY6rZmLPsOFiEotG4IUNg-1
X-Mimecast-MFC-AGG-ID: FnY6rZmLPsOFiEotG4IUNg_1787052229
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Tue, 18 Aug 2026 15:11:12 +0400
Subject: [PATCH v3 45/74] qom: convert scalar properties to QAPI-aware
 registration
MIME-Version: 1.0
Message-Id: <20260818-qom-qapi-v3-45-24b8bbbe3d86@redhat.com>
References: <20260818-qom-qapi-v3-0-24b8bbbe3d86@redhat.com>
In-Reply-To: <20260818-qom-qapi-v3-0-24b8bbbe3d86@redhat.com>
To: qemu-devel@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 Michael Roth <michael.roth@amd.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 Alexander Graf <graf@amazon.com>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 "Gonglei (Arei)" <arei.gonglei@huawei.com>, 
 zhenwei pi <zhenwei.pi@linux.dev>, David Hildenbrand <david@kernel.org>, 
 Igor Mammedov <imammedo@redhat.com>, Alberto Garcia <berto@igalia.com>, 
 Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Ani Sinha <anisinha@redhat.com>, 
 Peter Maydell <peter.maydell@linaro.org>, Luc Michel <luc@lmichel.fr>, 
 Zhao Liu <zhao1.liu@intel.com>, Jonathan Cameron <jic23@kernel.org>, 
 =?utf-8?q?C=C3=A9dric_Le_Goater?= <clg@kaod.org>, 
 Steven Lee <steven_lee@aspeedtech.com>, Troy Lee <leetroy@gmail.com>, 
 Jamin Lin <jamin_lin@aspeedtech.com>, Kane Chen <kane_chen@aspeedtech.com>, 
 Andrew Jeffery <andrew@codeconstruct.com.au>, Joel Stanley <joel@jms.id.au>, 
 Samuel Tardieu <sam@rfc1149.net>, Marcelo Tosatti <mtosatti@redhat.com>, 
 John Snow <jsnow@redhat.com>, "Denis V. Lunev" <den@openvz.org>, 
 Song Gao <17746591750@163.com>, Bibo Mao <maobibo@loongson.cn>, 
 Xianglai Li <lixianglai@loongson.cn>, Jiaxun Yang <jiaxun.yang@flygoat.com>, 
 FangSheng Huang <FangSheng.Huang@amd.com>, Tyrone Ting <kfting@nuvoton.com>, 
 Hao Wu <wuhaotsh@google.com>, Jason Wang <jasowangio@gmail.com>, 
 Keith Busch <kbusch@kernel.org>, Klaus Jensen <its@irrelevant.dk>, 
 Jesper Devantier <foss@defmacro.it>, Nicholas Piggin <npiggin@gmail.com>, 
 Aditya Gupta <adityag@linux.ibm.com>, Glenn Miles <milesg@linux.ibm.com>, 
 Harsh Prateek Bora <harshpb@linux.ibm.com>, Conor Dooley <conor@kernel.org>, 
 Sebastian Huber <sebastian.huber@embedded-brains.de>, 
 Palmer Dabbelt <palmer@dabbelt.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Weiwei Li <liwei1518@gmail.com>, 
 Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, 
 Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
 Chao Liu <chao.liu@processmission.com>, Halil Pasic <pasic@linux.ibm.com>, 
 Christian Borntraeger <borntraeger@linux.ibm.com>, 
 Jason Herne <jjherne@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, 
 Matthew Rosato <mjrosato@linux.ibm.com>, 
 Ilya Leoshkevich <iii@linux.ibm.com>, Cornelia Huck <cohuck@redhat.com>, 
 Titus Rwantare <titusr@google.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 Zhang Chen <zhangckid@gmail.com>, Li Zhijian <lizhijian@fujitsu.com>, 
 Peter Xu <peterx@redhat.com>, Chinmay Rath <rathc@linux.ibm.com>, 
 Hendrik Brueckner <brueckner@linux.ibm.com>, kvm@vger.kernel.org, 
 qemu-block@nongnu.org, qemu-arm@nongnu.org, linux-cxl@vger.kernel.org, 
 qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=108245;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=I3ngOK474uG6L8GlTGihBDhFs2IbouaKgNqts0SQpbQ=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqhD27wd29pCZcsiZN03D0ycgqgojx2bU9GopVv
 C90fLkj/FCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaoQ9uwAKCRDa6OEJdZac
 5S0wD/4tOtd+QWL4mGBf2P80sHbQkFktxXaQZRJKRpTkzh7Fpp9zfrEraWOIn9DSqcYvW5VM7dj
 bWIXfKGHMAn1ILiAMeo3OaQAYbvBYuM1e+/fQ0AGwbq2wtyXwS+FOsHsd7+JInX321/3wrNlbUZ
 tZsoX74l+HP6MpHTe/GgHi2hDTtghOI9prYfQD514FyAq+TGCZx7NH9Jiam58DA9Y9D0klPFX1J
 1TJqXIlpaNbpNXBGg8dU0N9E+1YindXkWO9qSMrJerQkHmeU4Y8C+kDj4GWV84FpjckGNEyCkzk
 b8WK1tMB4lIfEdMrUD8wyxySUZ32VazRBK6VKwjlwNTA5Ntv3zeW0mDHNAgSVNoAMBX7yxfOnI9
 B0yNNAhW1WbPFFJZwy0nl/6WDwITj4q8qxaJ8bSfXNZOggnPilvsPEx88R4nh0rQzE1Vtdf/KVr
 qHTSkaDYrZA6q2vC045maGcwLTjDjh8WLlBgnrkRyDnLJqmHjgNwpmlwd7RrEk0v6BP9Ci9H7zo
 F7H4EilJ8Z1A+2RobTvqFPe8S2EO2/4RcL+8SZaVtXJQyhigGwoBOBspynSXwuNcwBhP6tXTsxu
 RBDau6l90HwMSPIVRaUE7NTSe3B9C3+mwtOGpM7K0hWIX+tgcNO1hEbYtPP22qeA7mWxzHi12QH
 LhVJJ0MKBj+Zbtg==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 7_DFWfMvPBRYpm_t9Lle6qvE2ZLd87NAHc8fH2LSUcA_1787052229
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787052242-AAEDEA4A-18C1C3AF/0/0
X-purgate-type: clean
X-purgate-size: 108247

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 accel/kvm/kvm-all.c                 |  5 ++-
 accel/nitro/nitro-accel.c           |  3 +-
 accel/tcg/tcg-all.c                 |  3 +-
 backends/cryptodev.c                |  7 ++--
 backends/hostmem-file.c             |  4 +-
 backends/hostmem-memfd.c            |  3 +-
 backends/hostmem.c                  |  6 +--
 block/throttle-groups.c             |  5 ++-
 crypto/secret_keyring.c             |  9 +++--
 event-loop-base.c                   |  7 ++--
 hw/acpi/ich9.c                      |  3 +-
 hw/acpi/pci.c                       |  7 ++--
 hw/arm/virt.c                       |  4 +-
 hw/core/clock.c                     |  3 +-
 hw/core/machine.c                   |  2 +-
 hw/cpu/core.c                       | 10 +++--
 hw/cxl/cxl-host.c                   |  2 +-
 hw/gpio/aspeed_gpio.c               |  5 ++-
 hw/gpio/aspeed_sgpio.c              |  3 +-
 hw/gpio/stm32l4x5_gpio.c            |  5 ++-
 hw/i386/pc.c                        |  6 +--
 hw/i386/sgx-epc.c                   |  3 +-
 hw/i386/x86.c                       |  6 +--
 hw/ide/ide-dev.c                    |  3 +-
 hw/intc/apic_common.c               |  3 +-
 hw/loongarch/virt.c                 |  2 +-
 hw/mem/nvdimm.c                     |  7 ++--
 hw/mem/pc-dimm.c                    |  3 +-
 hw/misc/aspeed_lpc.c                | 73 +++++++++++++++++++++++++------------
 hw/misc/aspeed_sdmc.c               |  3 +-
 hw/misc/npcm7xx_mft.c               |  3 +-
 hw/net/ne2000-isa.c                 |  3 +-
 hw/nvme/ctrl.c                      |  3 +-
 hw/pci-bridge/pci_expander_bridge.c |  3 +-
 hw/pci-host/i440fx.c                | 29 +++++++++------
 hw/pci-host/pnv_phb3.c              |  5 ++-
 hw/pci-host/pnv_phb4.c              |  5 ++-
 hw/pci-host/q35.c                   |  9 +++--
 hw/ppc/spapr_drc.c                  |  3 +-
 hw/riscv/microchip_pfsoc.c          |  3 +-
 hw/s390x/sclpcpi.c                  |  8 ++--
 hw/s390x/virtio-ccw-mem.c           |  3 +-
 hw/sensor/adc128d818.c              | 16 +++++---
 hw/sensor/adm1266.c                 |  3 +-
 hw/sensor/adm1272.c                 |  9 +++--
 hw/sensor/emc141x.c                 |  9 +++--
 hw/sensor/isl_pmbus_vr.c            | 19 +++++-----
 hw/sensor/lsm303dlhc_mag.c          |  9 +++--
 hw/sensor/max34451.c                |  5 ++-
 hw/sensor/tmp105.c                  |  3 +-
 hw/sensor/tmp421.c                  |  9 +++--
 hw/usb/dev-storage-classic.c        |  3 +-
 hw/virtio/virtio-balloon.c          |  3 +-
 hw/virtio/virtio-mem-pci.c          |  3 +-
 hw/virtio/virtio-mem.c              | 18 +++++----
 hw/xen/xen-pvh-common.c             |  9 +++--
 iothread.c                          |  9 +++--
 net/colo-compare.c                  |  7 ++--
 net/dump.c                          |  6 ++-
 net/filter-buffer.c                 |  3 +-
 qom/object.c                        | 42 ++++++++++-----------
 system/bootdevice.c                 |  3 +-
 system/memory.c                     |  5 ++-
 target/arm/cpu64.c                  | 11 +++---
 target/arm/kvm.c                    |  3 +-
 target/arm/tcg/cpu64.c              |  5 ++-
 target/i386/cpu.c                   | 12 +++---
 target/i386/kvm/kvm.c               |  8 ++--
 target/i386/sev.c                   |  2 +-
 target/ppc/compat.c                 |  3 +-
 target/riscv/cpu.c                  | 15 ++++----
 target/riscv/kvm/kvm-cpu.c          |  7 ++--
 target/riscv/tcg/tcg-cpu.c          | 13 ++++---
 target/s390x/cpu_models.c           |  5 ++-
 tests/unit/test-qdev-global-props.c | 11 ++++--
 ui/console.c                        |  3 +-
 util/thread-context.c               |  7 ++--
 77 files changed, 341 insertions(+), 239 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index e2cfbcf44046..ff9db3ca8b3d 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -24,6 +24,7 @@
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "hw/pci/msi.h"
 #include "hw/pci/msix.h"
 #include "hw/s390x/adapter.h"
@@ -4278,13 +4279,13 @@ static void kvm_accel_class_init(ObjectClass *oc, const void *data)
         .description = "Configure KVM in-kernel irqchip",
     ));
 
-    object_class_property_add(oc, "kvm-shadow-mem", "int",
+    object_class_property_add_qapi(oc, "kvm-shadow-mem", &int_type_info,
         kvm_get_kvm_shadow_mem, kvm_set_kvm_shadow_mem,
         NULL, NULL);
     object_class_property_set_description(oc, "kvm-shadow-mem",
         "KVM shadow MMU size");
 
-    object_class_property_add(oc, "dirty-ring-size", "uint32",
+    object_class_property_add_qapi(oc, "dirty-ring-size", &uint32_type_info,
         kvm_get_dirty_ring_size, kvm_set_dirty_ring_size,
         NULL, NULL);
     object_class_property_set_description(oc, "dirty-ring-size",
diff --git a/accel/nitro/nitro-accel.c b/accel/nitro/nitro-accel.c
index a1e97a9162e9..05841c1277dc 100644
--- a/accel/nitro/nitro-accel.c
+++ b/accel/nitro/nitro-accel.c
@@ -29,6 +29,7 @@
 #include "qemu/osdep.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "qemu/rcu.h"
@@ -238,7 +239,7 @@ static void nitro_accel_class_init(ObjectClass *oc, const void *data)
     object_class_property_set_description(oc, "debug-mode",
         "Start enclave in debug mode (enables console output)");
 
-    object_class_property_add(oc, "enclave-cid", "uint64",
+    object_class_property_add_qapi(oc, "enclave-cid", &uint64_type_info,
                               nitro_get_enclave_cid,
                               nitro_set_enclave_cid,
                               NULL, NULL);
diff --git a/accel/tcg/tcg-all.c b/accel/tcg/tcg-all.c
index 767e8805552f..277cf0e2d012 100644
--- a/accel/tcg/tcg-all.c
+++ b/accel/tcg/tcg-all.c
@@ -29,6 +29,7 @@
 #include "exec/icount.h"
 #include "tcg/startup.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qemu/error-report.h"
 #include "qemu/accel.h"
 #include "qemu/atomic.h"
@@ -270,7 +271,7 @@ static void tcg_accel_class_init(ObjectClass *oc, const void *data)
                                   tcg_get_thread,
                                   tcg_set_thread);
 
-    object_class_property_add(oc, "tb-size", "uint32",
+    object_class_property_add_qapi(oc, "tb-size", &uint32_type_info,
         tcg_get_tb_size, tcg_set_tb_size,
         NULL, NULL);
     object_class_property_set_description(oc, "tb-size",
diff --git a/backends/cryptodev.c b/backends/cryptodev.c
index e8f2b18f2017..a69adb70440c 100644
--- a/backends/cryptodev.c
+++ b/backends/cryptodev.c
@@ -25,6 +25,7 @@
 #include "system/cryptodev.h"
 #include "system/stats.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-commands-cryptodev.h"
 #include "qapi/qapi-types-stats.h"
 #include "qapi/visitor.h"
@@ -622,15 +623,15 @@ cryptodev_backend_class_init(ObjectClass *oc, const void *data)
     ucc->prepare_delete = cryptodev_backend_prepare_delete;
 
     QTAILQ_INIT(&crypto_clients);
-    object_class_property_add(oc, "queues", "uint32",
+    object_class_property_add_qapi(oc, "queues", &uint32_type_info,
                               cryptodev_backend_get_queues,
                               cryptodev_backend_set_queues,
                               NULL, NULL);
-    object_class_property_add(oc, "throttle-bps", "uint64",
+    object_class_property_add_qapi(oc, "throttle-bps", &uint64_type_info,
                               cryptodev_backend_get_bps,
                               cryptodev_backend_set_bps,
                               NULL, NULL);
-    object_class_property_add(oc, "throttle-ops", "uint64",
+    object_class_property_add_qapi(oc, "throttle-ops", &uint64_type_info,
                               cryptodev_backend_get_ops,
                               cryptodev_backend_set_ops,
                               NULL, NULL);
diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index 39a46d353839..5d339ca426cb 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -275,11 +275,11 @@ file_backend_class_init(ObjectClass *oc, const void *data)
         file_memory_backend_get_discard_data, file_memory_backend_set_discard_data);
     object_class_property_add_str(oc, "mem-path",
         get_mem_path, set_mem_path);
-    object_class_property_add(oc, "align", "size",
+    object_class_property_add_qapi(oc, "align", &size_type_info,
         file_memory_backend_get_align,
         file_memory_backend_set_align,
         NULL, NULL);
-    object_class_property_add(oc, "offset", "int",
+    object_class_property_add_qapi(oc, "offset", &int_type_info,
         file_memory_backend_get_offset,
         file_memory_backend_set_offset,
         NULL, NULL);
diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
index 77f7eab40fe0..8fa77b3429eb 100644
--- a/backends/hostmem-memfd.c
+++ b/backends/hostmem-memfd.c
@@ -16,6 +16,7 @@
 #include "qemu/memfd.h"
 #include "qemu/module.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qom/object.h"
 #include "migration/cpr.h"
 
@@ -145,7 +146,7 @@ memfd_backend_class_init(ObjectClass *oc, const void *data)
                                        memfd_backend_set_hugetlb);
         object_class_property_set_description(oc, "hugetlb",
                                               "Use huge pages");
-        object_class_property_add(oc, "hugetlbsize", "size",
+        object_class_property_add_qapi(oc, "hugetlbsize", &size_type_info,
                                   memfd_backend_get_hugetlbsize,
                                   memfd_backend_set_hugetlbsize,
                                   NULL, NULL);
diff --git a/backends/hostmem.c b/backends/hostmem.c
index e7f9b436a459..d05ab53ab662 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -529,7 +529,7 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data)
         host_memory_backend_set_prealloc);
     object_class_property_set_description(oc, "prealloc",
         "Preallocate memory");
-    object_class_property_add(oc, "prealloc-threads", "int",
+    object_class_property_add_qapi(oc, "prealloc-threads", &int_type_info,
         host_memory_backend_get_prealloc_threads,
         host_memory_backend_set_prealloc_threads,
         NULL, NULL);
@@ -540,13 +540,13 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data)
         object_property_allow_set_link, OBJ_PROP_LINK_STRONG);
     object_class_property_set_description(oc, "prealloc-context",
         "Context to use for creating CPU threads for preallocation");
-    object_class_property_add(oc, "size", "size",
+    object_class_property_add_qapi(oc, "size", &size_type_info,
         host_memory_backend_get_size,
         host_memory_backend_set_size,
         NULL, NULL);
     object_class_property_set_description(oc, "size",
         "Size of the memory region (ex: 500M)");
-    object_class_property_add(oc, "host-nodes", "[uint16]",
+    object_class_property_add_qapi(oc, "host-nodes", &uint16List_type_info,
         host_memory_backend_get_host_nodes,
         host_memory_backend_set_host_nodes,
         NULL, NULL);
diff --git a/block/throttle-groups.c b/block/throttle-groups.c
index 6312157802da..851617237f80 100644
--- a/block/throttle-groups.c
+++ b/block/throttle-groups.c
@@ -31,6 +31,7 @@
 #include "qemu/thread.h"
 #include "system/qtest.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-type-infos-block-core.h"
 #include "qapi/qapi-visit-block-core.h"
 #include "qom/object.h"
@@ -983,9 +984,9 @@ static void throttle_group_obj_class_init(ObjectClass *klass,
 
     /* individual properties */
     for (i = 0; i < sizeof(properties) / sizeof(ThrottleParamInfo); i++) {
-        object_class_property_add(klass,
+        object_class_property_add_qapi(klass,
                                   properties[i].name,
-                                  "int64",
+                                  &int64_type_info,
                                   throttle_group_get,
                                   throttle_group_set,
                                   NULL, &properties[i]);
diff --git a/crypto/secret_keyring.c b/crypto/secret_keyring.c
index 78d7f09b3b97..de813e79d8d6 100644
--- a/crypto/secret_keyring.c
+++ b/crypto/secret_keyring.c
@@ -21,6 +21,7 @@
 #include "qemu/osdep.h"
 #include <asm/unistd.h>
 #include <linux/keyctl.h>
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/error.h"
 #include "qom/object_interfaces.h"
 #include "trace.h"
@@ -108,10 +109,10 @@ qcrypto_secret_keyring_class_init(ObjectClass *oc, const void *data)
     QCryptoSecretCommonClass *sic = QCRYPTO_SECRET_COMMON_CLASS(oc);
     sic->load_data = qcrypto_secret_keyring_load_data;
 
-    object_class_property_add(oc, "serial", "int32_t",
-                                  qcrypto_secret_prop_get_key,
-                                  qcrypto_secret_prop_set_key,
-                                  NULL, NULL);
+    object_class_property_add_qapi(oc, "serial", &int32_type_info,
+                                   qcrypto_secret_prop_get_key,
+                                   qcrypto_secret_prop_set_key,
+                                   NULL, NULL);
 }
 
 
diff --git a/event-loop-base.c b/event-loop-base.c
index 23f554d92ce8..c16c5366f680 100644
--- a/event-loop-base.c
+++ b/event-loop-base.c
@@ -14,6 +14,7 @@
 #include "qemu/osdep.h"
 #include "qom/object_interfaces.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "block/thread-pool.h"
 #include "system/event-loop-base.h"
 
@@ -104,15 +105,15 @@ static void event_loop_base_class_init(ObjectClass *klass,
     ucc->complete = event_loop_base_complete;
     ucc->prepare_delete = event_loop_base_prepare_delete;
 
-    object_class_property_add(klass, "aio-max-batch", "int64",
+    object_class_property_add_qapi(klass, "aio-max-batch", &int64_type_info,
                               event_loop_base_get_param,
                               event_loop_base_set_param,
                               NULL, &aio_max_batch_info);
-    object_class_property_add(klass, "thread-pool-min", "int64",
+    object_class_property_add_qapi(klass, "thread-pool-min", &int64_type_info,
                               event_loop_base_get_param,
                               event_loop_base_set_param,
                               NULL, &thread_pool_min_info);
-    object_class_property_add(klass, "thread-pool-max", "int64",
+    object_class_property_add_qapi(klass, "thread-pool-max", &int64_type_info,
                               event_loop_base_get_param,
                               event_loop_base_set_param,
                               NULL, &thread_pool_max_info);
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 5e8f8a7eafa3..3bf895672d50 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -26,6 +26,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/pci/pci.h"
 #include "migration/vmstate.h"
@@ -409,7 +410,7 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs *pm)
                              (Object **)&pm->acpi_pci_hotplug.root,
                              object_property_allow_set_link,
                              OBJ_PROP_LINK_STRONG);
-    object_property_add(obj, ACPI_PM_PROP_GPE0_BLK, "uint32",
+    object_property_add_qapi(obj, ACPI_PM_PROP_GPE0_BLK, &uint32_type_info,
                         ich9_pm_get_gpe0_blk,
                         NULL, NULL, pm);
     object_property_add_uint32_ptr(obj, ACPI_PM_PROP_GPE0_BLK_LEN,
diff --git a/hw/acpi/pci.c b/hw/acpi/pci.c
index c82924be8620..71d01307e141 100644
--- a/hw/acpi/pci.c
+++ b/hw/acpi/pci.c
@@ -27,6 +27,7 @@
 #include "qemu/error-report.h"
 #include "qom/object_interfaces.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "hw/core/boards.h"
 #include "hw/acpi/aml-build.h"
 #include "hw/acpi/pci.h"
@@ -139,7 +140,7 @@ static void acpi_generic_initiator_class_init(ObjectClass *oc, const void *data)
         acpi_generic_initiator_set_pci_device);
     object_class_property_set_description(oc, "pci-dev",
         "PCI device to associate with the node");
-    object_class_property_add(oc, "node", "uint32", NULL,
+    object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL,
         acpi_generic_initiator_set_node, NULL, NULL);
     object_class_property_set_description(oc, "node",
         "NUMA node associated with the PCI device");
@@ -253,8 +254,8 @@ static void acpi_generic_port_class_init(ObjectClass *oc, const void *data)
         acpi_generic_port_set_pci_bus);
     object_class_property_set_description(oc, "pci-bus",
        "PCI Bus of the host bridge associated with this GP affinity structure");
-    object_class_property_add(oc, "node", "uint32", NULL,
-        acpi_generic_port_set_node, NULL, NULL);
+    object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL,
+       acpi_generic_port_set_node, NULL, NULL);
     object_class_property_set_description(oc, "node",
        "The NUMA node like ID to index HMAT/SLIT NUMA properties involving GP");
 }
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index f283703fb002..8ec51f3b1a00 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -4258,7 +4258,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
                                           "Set on/off to enable/disable high "
                                           "memory region for PCI MMIO");
 
-    object_class_property_add(oc, "highmem-mmio-size", "size",
+    object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info,
                                    virt_get_highmem_mmio_size,
                                    virt_set_highmem_mmio_size,
                                    NULL, NULL);
@@ -4266,7 +4266,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data)
                                           "Set the high memory region size "
                                           "for PCI MMIO");
 
-    object_class_property_add(oc, "virtio-mmio-transports", "uint8",
+    object_class_property_add_qapi(oc, "virtio-mmio-transports", &uint8_type_info,
                                    virt_get_virtio_transports,
                                    virt_set_virtio_transports,
                                    NULL, NULL);
diff --git a/hw/core/clock.c b/hw/core/clock.c
index 3fc98a0c65d5..f55cb17af77e 100644
--- a/hw/core/clock.c
+++ b/hw/core/clock.c
@@ -13,6 +13,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "system/qtest.h"
 #include "hw/core/clock.h"
@@ -185,7 +186,7 @@ static void clock_initfn(Object *obj)
     QLIST_INIT(&clk->children);
 
     if (qtest_enabled()) {
-        object_property_add(obj, "qtest-clock-period", "uint64",
+        object_property_add_qapi(obj, "qtest-clock-period", &uint64_type_info,
                             clock_period_prop_get, NULL, NULL, NULL);
     }
 }
diff --git a/hw/core/machine.c b/hw/core/machine.c
index cd9636dde6e6..85a9d428473f 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -1133,7 +1133,7 @@ static void machine_class_init(ObjectClass *oc, const void *data)
     object_class_property_set_description(oc, "smp-cache",
         "Cache properties list for SMP machine");
 
-    object_class_property_add(oc, "phandle-start", "int",
+    object_class_property_add_qapi(oc, "phandle-start", &int_type_info,
         machine_get_phandle_start, machine_set_phandle_start,
         NULL, NULL);
     object_class_property_set_description(oc, "phandle-start",
diff --git a/hw/cpu/core.c b/hw/cpu/core.c
index 26e488f3d8e3..d7c89f47ab04 100644
--- a/hw/cpu/core.c
+++ b/hw/cpu/core.c
@@ -12,6 +12,7 @@
 #include "hw/core/boards.h"
 #include "hw/cpu/core.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 
 static void core_prop_get_core_id(Object *obj, Visitor *v, const char *name,
@@ -82,10 +83,11 @@ static void cpu_core_class_init(ObjectClass *oc, const void *data)
     DeviceClass *dc = DEVICE_CLASS(oc);
 
     set_bit(DEVICE_CATEGORY_CPU, dc->categories);
-    object_class_property_add(oc, "core-id", "int", core_prop_get_core_id,
-                              core_prop_set_core_id, NULL, NULL);
-    object_class_property_add(oc, "nr-threads", "int", core_prop_get_nr_threads,
-                              core_prop_set_nr_threads, NULL, NULL);
+    object_class_property_add_qapi(oc, "core-id", &int_type_info, core_prop_get_core_id,
+                                   core_prop_set_core_id, NULL, NULL);
+    object_class_property_add_qapi(oc, "nr-threads", &int_type_info,
+                                   core_prop_get_nr_threads, core_prop_set_nr_threads,
+                                   NULL, NULL);
 }
 
 static const TypeInfo cpu_core_type_info = {
diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c
index 7592c4ac6c7b..4133398fec48 100644
--- a/hw/cxl/cxl-host.c
+++ b/hw/cxl/cxl-host.c
@@ -565,7 +565,7 @@ static void machine_set_cfmw(Object *obj, Visitor *v, const char *name,
 
 void cxl_machine_init(Object *obj, CXLState *state)
 {
-    object_property_add(obj, "cxl", "bool", machine_get_cxl,
+    object_property_add_qapi(obj, "cxl", &bool_type_info, machine_get_cxl,
                         machine_set_cxl, NULL, state);
     object_property_set_description(obj, "cxl",
                                     "Set on/off to enable/disable "
diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index 1cf6f5df5505..0c90bcd723da 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -12,6 +12,7 @@
 #include "hw/gpio/aspeed_gpio.h"
 #include "hw/misc/aspeed_scu.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/core/irq.h"
 #include "migration/vmstate.h"
@@ -1481,7 +1482,7 @@ static void aspeed_gpio_init(Object *obj)
             int pin_idx = j % GPIOS_PER_GROUP;
             const char *group = &props->group_label[group_idx][0];
             char *name = g_strdup_printf("gpio%s%d", group, pin_idx);
-            object_property_add(obj, name, "bool", aspeed_gpio_get_pin,
+            object_property_add_qapi(obj, name, &bool_type_info, aspeed_gpio_get_pin,
                                 aspeed_gpio_set_pin, NULL, NULL);
             g_free(name);
         }
@@ -1489,7 +1490,7 @@ static void aspeed_gpio_init(Object *obj)
 
     for (int i = 0; i < agc->nr_gpio_sets; i++) {
         g_autofree char *name = g_strdup_printf("gpio-set[%d]", i);
-        object_property_add(obj, name, "uint32", aspeed_gpio_get_set,
+        object_property_add_qapi(obj, name, &uint32_type_info, aspeed_gpio_get_set,
         aspeed_gpio_set_set, NULL, NULL);
     }
 }
diff --git a/hw/gpio/aspeed_sgpio.c b/hw/gpio/aspeed_sgpio.c
index 7d2f73699520..67b0c10d79fa 100644
--- a/hw/gpio/aspeed_sgpio.c
+++ b/hw/gpio/aspeed_sgpio.c
@@ -11,6 +11,7 @@
 #include "qemu/log.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/core/irq.h"
 #include "hw/core/qdev-properties.h"
@@ -300,7 +301,7 @@ static void aspeed_sgpio_init(Object *obj)
 {
     for (int i = 0; i < ASPEED_SGPIO_MAX_PIN_PAIR * 2; i++) {
         g_autofree char *name = g_strdup_printf("sgpio%03d", i);
-        object_property_add(obj, name, "bool", aspeed_sgpio_get_pin,
+        object_property_add_qapi(obj, name, &bool_type_info, aspeed_sgpio_get_pin,
                             aspeed_sgpio_set_pin, NULL, NULL);
     }
 }
diff --git a/hw/gpio/stm32l4x5_gpio.c b/hw/gpio/stm32l4x5_gpio.c
index 92fa397fbafe..d349d41e41a1 100644
--- a/hw/gpio/stm32l4x5_gpio.c
+++ b/hw/gpio/stm32l4x5_gpio.c
@@ -25,6 +25,7 @@
 #include "hw/core/qdev-properties.h"
 #include "qapi/visitor.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "migration/vmstate.h"
 #include "trace.h"
 
@@ -409,10 +410,10 @@ static void stm32l4x5_gpio_init(Object *obj)
 
     s->clk = qdev_init_clock_in(DEVICE(s), "clk", NULL, s, 0);
 
-    object_property_add(obj, "disconnected-pins", "uint16",
+    object_property_add_qapi(obj, "disconnected-pins", &uint16_type_info,
                         disconnected_pins_get, disconnected_pins_set,
                         NULL, &s->disconnected_pins);
-    object_property_add(obj, "clock-freq-hz", "uint32",
+    object_property_add_qapi(obj, "clock-freq-hz", &uint32_type_info,
                         clock_freq_get, NULL, NULL, NULL);
 }
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 18b5dc169ab7..24c4c589ed04 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1720,7 +1720,7 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data)
     mc->default_ram_id = "pc.ram";
     pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_AUTO;
 
-    object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
+    object_class_property_add_qapi(oc, PC_MACHINE_MAX_RAM_BELOW_4G, &size_type_info,
         pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g,
         NULL, NULL);
     object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G,
@@ -1758,13 +1758,13 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data)
         pc_machine_get_default_bus_bypass_iommu,
         pc_machine_set_default_bus_bypass_iommu);
 
-    object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size",
+    object_class_property_add_qapi(oc, PC_MACHINE_MAX_FW_SIZE, &size_type_info,
         pc_machine_get_max_fw_size, pc_machine_set_max_fw_size,
         NULL, NULL);
     object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE,
         "Maximum combined firmware size");
 
-    object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str",
+    object_class_property_add_qapi(oc, PC_MACHINE_SMBIOS_EP, &str_type_info,
         pc_machine_get_smbios_ep, pc_machine_set_smbios_ep,
         NULL, NULL);
     object_class_property_set_description(oc, PC_MACHINE_SMBIOS_EP,
diff --git a/hw/i386/sgx-epc.c b/hw/i386/sgx-epc.c
index d3fe10028c51..d9b9ab3f7a96 100644
--- a/hw/i386/sgx-epc.c
+++ b/hw/i386/sgx-epc.c
@@ -15,6 +15,7 @@
 #include "hw/mem/memory-device.h"
 #include "hw/core/qdev-properties.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "target/i386/cpu.h"
 #include "system/address-spaces.h"
@@ -43,7 +44,7 @@ static void sgx_epc_get_size(Object *obj, Visitor *v, const char *name,
 
 static void sgx_epc_init(Object *obj)
 {
-    object_property_add(obj, SGX_EPC_SIZE_PROP, "uint64", sgx_epc_get_size,
+    object_property_add_qapi(obj, SGX_EPC_SIZE_PROP, &uint64_type_info, sgx_epc_get_size,
                         NULL, NULL, NULL);
 }
 
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 63f297a10532..d0c782ec8544 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -420,9 +420,9 @@ static void x86_machine_class_init(ObjectClass *oc, const void *data)
                                           "in ACPI table header."
                                           "The string may be up to 8 bytes in size");
 
-    object_class_property_add(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "uint64_t",
-                                x86_machine_get_bus_lock_ratelimit,
-                                x86_machine_set_bus_lock_ratelimit, NULL, NULL);
+    object_class_property_add_qapi(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, &uint64_type_info,
+                                   x86_machine_get_bus_lock_ratelimit,
+                                   x86_machine_set_bus_lock_ratelimit, NULL, NULL);
     object_class_property_set_description(oc, X86_MACHINE_BUS_LOCK_RATELIMIT,
             "Set the ratelimit for the bus locks acquired in VMs");
 
diff --git a/hw/ide/ide-dev.c b/hw/ide/ide-dev.c
index 5d478588c614..e2dd2439991f 100644
--- a/hw/ide/ide-dev.c
+++ b/hw/ide/ide-dev.c
@@ -19,6 +19,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-types-block.h"
 #include "qemu/error-report.h"
 #include "qemu/module.h"
@@ -174,7 +175,7 @@ out:
 
 static void ide_dev_instance_init(Object *obj)
 {
-    object_property_add(obj, "bootindex", "int32",
+    object_property_add_qapi(obj, "bootindex", &int32_type_info,
                         ide_dev_get_bootindex,
                         ide_dev_set_bootindex, NULL, NULL);
     object_property_set_int(obj, "bootindex", -1, NULL);
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index 0f0f37d45734..dc0517ceea90 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -22,6 +22,7 @@
 #include "qemu/error-report.h"
 #include "qemu/module.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/i386/apic.h"
 #include "hw/i386/apic_internal.h"
@@ -442,7 +443,7 @@ static void apic_common_initfn(Object *obj)
     APICCommonState *s = APIC_COMMON(obj);
 
     s->id = s->initial_apic_id = -1;
-    object_property_add(obj, "id", "uint32",
+    object_property_add_qapi(obj, "id", &uint32_type_info,
                         apic_common_get_id,
                         apic_common_set_id, NULL, NULL);
 }
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 750ce2dbe5fc..209a0feddd80 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -1520,7 +1520,7 @@ static void virt_class_init(ObjectClass *oc, const void *data)
     object_class_property_set_description(oc, "highmem-mmio",
                                           "Set on/off to enable/disable high "
                                           "memory region for PCI MMIO");
-    object_class_property_add(oc, "highmem-mmio-size", "size",
+    object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info,
                                    virt_get_highmem_mmio_size,
                                    virt_set_highmem_mmio_size,
                                    NULL, NULL);
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index cf8a4d8c5f2a..123ddc938546 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -26,6 +26,7 @@
 #include "qemu/module.h"
 #include "qemu/pmem.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/mem/nvdimm.h"
 #include "hw/core/qdev-properties.h"
@@ -99,9 +100,9 @@ static void nvdimm_set_uuid(Object *obj, Visitor *v, const char *name,
 
 static void nvdimm_init(Object *obj)
 {
-    object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "size",
-                        nvdimm_get_label_size, nvdimm_set_label_size, NULL,
-                        NULL);
+    object_property_add_qapi(obj, NVDIMM_LABEL_SIZE_PROP, &size_type_info,
+                             nvdimm_get_label_size, nvdimm_set_label_size, NULL,
+                             NULL);
 
     object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_uuid,
                         nvdimm_set_uuid, NULL, NULL);
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 68862926ee2d..ee586ecc0c7d 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -26,6 +26,7 @@
 #include "hw/mem/nvdimm.h"
 #include "hw/mem/memory-device.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "system/hostmem.h"
@@ -176,7 +177,7 @@ static void pc_dimm_get_size(Object *obj, Visitor *v, const char *name,
 
 static void pc_dimm_init(Object *obj)
 {
-    object_property_add(obj, PC_DIMM_SIZE_PROP, "uint64", pc_dimm_get_size,
+    object_property_add_qapi(obj, PC_DIMM_SIZE_PROP, &uint64_type_info, pc_dimm_get_size,
                         NULL, NULL, NULL);
 }
 
diff --git a/hw/misc/aspeed_lpc.c b/hw/misc/aspeed_lpc.c
index 7f7e4f1a0985..e2d9b7572f27 100644
--- a/hw/misc/aspeed_lpc.c
+++ b/hw/misc/aspeed_lpc.c
@@ -12,6 +12,7 @@
 #include "qemu/error-report.h"
 #include "hw/misc/aspeed_lpc.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/core/irq.h"
 #include "hw/core/qdev-properties.h"
@@ -417,30 +418,54 @@ static void aspeed_lpc_realize(DeviceState *dev, Error **errp)
 
 static void aspeed_lpc_init(Object *obj)
 {
-    object_property_add(obj, "idr1", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "odr1", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "str1", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "idr2", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "odr2", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "str2", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "idr3", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "odr3", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "str3", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "idr4", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "odr4", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
-    object_property_add(obj, "str4", "uint32", aspeed_kcs_get_register_property,
-                        aspeed_kcs_set_register_property, NULL, NULL);
+    object_property_add_qapi(obj, "idr1", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "odr1", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "str1", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "idr2", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "odr2", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "str2", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "idr3", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "odr3", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "str3", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "idr4", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "odr4", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "str4", &uint32_type_info,
+                             aspeed_kcs_get_register_property,
+                             aspeed_kcs_set_register_property,
+                             NULL, NULL);
 }
 
 static const VMStateDescription vmstate_aspeed_lpc = {
diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c
index f8fbaebee6ab..d096cc88f5c5 100644
--- a/hw/misc/aspeed_sdmc.c
+++ b/hw/misc/aspeed_sdmc.c
@@ -15,6 +15,7 @@
 #include "hw/core/qdev-properties.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "trace.h"
 #include "qemu/units.h"
 #include "qemu/cutils.h"
@@ -259,7 +260,7 @@ static void aspeed_sdmc_set_ram_size(Object *obj, Visitor *v, const char *name,
 
 static void aspeed_sdmc_initfn(Object *obj)
 {
-    object_property_add(obj, "ram-size", "int",
+    object_property_add_qapi(obj, "ram-size", &int_type_info,
                         aspeed_sdmc_get_ram_size, aspeed_sdmc_set_ram_size,
                         NULL, NULL);
 }
diff --git a/hw/misc/npcm7xx_mft.c b/hw/misc/npcm7xx_mft.c
index 742166c4e828..99e9e49788c0 100644
--- a/hw/misc/npcm7xx_mft.c
+++ b/hw/misc/npcm7xx_mft.c
@@ -23,6 +23,7 @@
 #include "hw/core/registerfields.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/bitops.h"
 #include "qemu/error-report.h"
@@ -491,7 +492,7 @@ static void npcm7xx_mft_init(Object *obj)
     s->clock_2 = qdev_init_clock_out(dev, "clock2");
 
     for (int i = 0; i < NPCM7XX_PWM_PER_MODULE; ++i) {
-        object_property_add(obj, "max_rpm[*]", "uint32",
+        object_property_add_qapi(obj, "max_rpm[*]", &uint32_type_info,
                             npcm7xx_mft_get_max_rpm,
                             npcm7xx_mft_set_max_rpm,
                             NULL, &s->max_rpm[i]);
diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c
index 673c785abc94..63e0d40ee726 100644
--- a/hw/net/ne2000-isa.c
+++ b/hw/net/ne2000-isa.c
@@ -29,6 +29,7 @@
 #include "ne2000.h"
 #include "system/system.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "qom/object.h"
@@ -131,7 +132,7 @@ out:
 
 static void isa_ne2000_instance_init(Object *obj)
 {
-    object_property_add(obj, "bootindex", "int32",
+    object_property_add_qapi(obj, "bootindex", &int32_type_info,
                         isa_ne2000_get_bootindex,
                         isa_ne2000_set_bootindex, NULL, NULL);
     object_property_set_int(obj, "bootindex", -1, NULL);
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index 4893cf7e7418..e4549aa9e534 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -203,6 +203,7 @@
 #include "qemu/units.h"
 #include "qemu/range.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "system/system.h"
 #include "system/block-backend.h"
@@ -10578,7 +10579,7 @@ static void nvme_instance_init(Object *obj)
                                   "bootindex", "/namespace@1,0",
                                   DEVICE(obj));
 
-    object_property_add(obj, "smart_critical_warning", "uint8",
+    object_property_add_qapi(obj, "smart_critical_warning", &uint8_type_info,
                         nvme_get_smart_warning,
                         nvme_set_smart_warning, NULL, NULL);
 }
diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c
index 40ffbc4e0821..9bb7d3c9debe 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -12,6 +12,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_host.h"
@@ -103,7 +104,7 @@ static void pxb_bus_class_init(ObjectClass *class, const void *data)
     pbc->bus_num = pxb_bus_num;
     pbc->numa_node = pxb_bus_numa_node;
 
-    object_class_property_add(class, "acpi_uid", "uint32",
+    object_class_property_add_qapi(class, "acpi_uid", &uint32_type_info,
                               prop_pxb_uid_get, NULL, NULL, NULL);
     object_class_property_set_description(class, "acpi_uid",
         "ACPI Unique ID used to distinguish this PCI Host Bridge / ACPI00016");
diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index c1982f7962a6..feafa6a72fe4 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -32,6 +32,7 @@
 #include "hw/core/qdev-properties.h"
 #include "hw/core/sysbus.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "migration/vmstate.h"
 #include "qapi/visitor.h"
 #include "qemu/error-report.h"
@@ -387,21 +388,25 @@ static void i440fx_pcihost_class_init(ObjectClass *klass, const void *data)
     /* Reason: needs to be wired up by pc_init1 */
     dc->user_creatable = false;
 
-    object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
-                              i440fx_pcihost_get_pci_hole_start,
-                              NULL, NULL, NULL);
+    object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_START,
+                                   &uint32_type_info,
+                                   i440fx_pcihost_get_pci_hole_start,
+                                   NULL, NULL, NULL);
 
-    object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_END, "uint32",
-                              i440fx_pcihost_get_pci_hole_end,
-                              NULL, NULL, NULL);
+    object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_END,
+                                   &uint32_type_info,
+                                   i440fx_pcihost_get_pci_hole_end,
+                                   NULL, NULL, NULL);
 
-    object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_START, "uint64",
-                              i440fx_pcihost_get_pci_hole64_start,
-                              NULL, NULL, NULL);
+    object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_START,
+                                   &uint64_type_info,
+                                   i440fx_pcihost_get_pci_hole64_start,
+                                   NULL, NULL, NULL);
 
-    object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_END, "uint64",
-                              i440fx_pcihost_get_pci_hole64_end,
-                              NULL, NULL, NULL);
+    object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_END,
+                                   &uint64_type_info,
+                                   i440fx_pcihost_get_pci_hole64_end,
+                                   NULL, NULL, NULL);
 }
 
 static const TypeInfo i440fx_pcihost_info = {
diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 0471b009ec2f..0ea5e695a688 100644
--- a/hw/pci-host/pnv_phb3.c
+++ b/hw/pci-host/pnv_phb3.c
@@ -11,6 +11,7 @@
 #include "qemu/bswap.h"
 #include "qapi/visitor.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "hw/pci-host/pnv_phb3_regs.h"
 #include "hw/pci-host/pnv_phb.h"
 #include "hw/pci-host/pnv_phb3.h"
@@ -1164,12 +1165,12 @@ static void pnv_phb3_root_bus_class_init(ObjectClass *klass, const void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
-    object_class_property_add(klass, "phb-id", "size",
+    object_class_property_add_qapi(klass, "phb-id", &size_type_info,
                               pnv_phb3_root_bus_get_prop,
                               pnv_phb3_root_bus_set_prop,
                               NULL, NULL);
 
-    object_class_property_add(klass, "chip-id", "size",
+    object_class_property_add_qapi(klass, "chip-id", &size_type_info,
                               pnv_phb3_root_bus_get_prop,
                               pnv_phb3_root_bus_set_prop,
                               NULL, NULL);
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 510edebc40de..6ca16158575d 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -11,6 +11,7 @@
 #include "qemu/bswap.h"
 #include "qapi/visitor.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "target/ppc/cpu.h"
 #include "hw/pci-host/pnv_phb4_regs.h"
 #include "hw/pci-host/pnv_phb4.h"
@@ -1761,12 +1762,12 @@ static void pnv_phb4_root_bus_class_init(ObjectClass *klass, const void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
-    object_class_property_add(klass, "phb-id", "size",
+    object_class_property_add_qapi(klass, "phb-id", &size_type_info,
                               pnv_phb4_root_bus_get_prop,
                               pnv_phb4_root_bus_set_prop,
                               NULL, NULL);
 
-    object_class_property_add(klass, "chip-id", "size",
+    object_class_property_add_qapi(klass, "chip-id", &size_type_info,
                               pnv_phb4_root_bus_get_prop,
                               pnv_phb4_root_bus_set_prop,
                               NULL, NULL);
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index f4556ad03a04..6eba30e06811 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -35,6 +35,7 @@
 #include "hw/core/qdev-properties.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 
@@ -226,19 +227,19 @@ static void q35_host_initfn(Object *obj)
     qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE,
                          Q35_PCI_HOST_HOLE64_SIZE_DEFAULT);
 
-    object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
+    object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_START, &uint32_type_info,
                         q35_host_get_pci_hole_start,
                         NULL, NULL, NULL);
 
-    object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32",
+    object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_END, &uint32_type_info,
                         q35_host_get_pci_hole_end,
                         NULL, NULL, NULL);
 
-    object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64",
+    object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_START, &uint64_type_info,
                         q35_host_get_pci_hole64_start,
                         NULL, NULL, NULL);
 
-    object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64",
+    object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_END, &uint64_type_info,
                         q35_host_get_pci_hole64_end,
                         NULL, NULL, NULL);
 
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 5c2150b71c86..64f9ca29b02e 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -12,6 +12,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qobject/qnull.h"
 #include "qemu/cutils.h"
 #include "hw/ppc/spapr_drc.h"
@@ -584,7 +585,7 @@ static void spapr_dr_connector_instance_init(Object *obj)
     SpaprDrcClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
 
     object_property_add_uint32_ptr(obj, "id", &drc->id, OBJ_PROP_FLAG_READ);
-    object_property_add(obj, "index", "uint32", prop_get_index,
+    object_property_add_qapi(obj, "index", &uint32_type_info, prop_get_index,
                         NULL, NULL, NULL);
     object_property_add(obj, "fdt", "struct", prop_get_fdt,
                         NULL, NULL, NULL);
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 4017129c8304..19788590cddc 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -39,6 +39,7 @@
 #include "qemu/units.h"
 #include "qemu/cutils.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/core/boards.h"
 #include "hw/core/loader.h"
@@ -742,7 +743,7 @@ static void microchip_icicle_kit_machine_class_init(ObjectClass *oc,
      */
     mc->default_ram_size = 1537 * MiB;
 
-    object_class_property_add(oc, "clint-timebase-frequency", "uint32_t",
+    object_class_property_add_qapi(oc, "clint-timebase-frequency", &uint32_type_info,
                               microchip_icicle_kit_get_clint_timebase_freq,
                               microchip_icicle_kit_set_clint_timebase_freq,
                               NULL, NULL);
diff --git a/hw/s390x/sclpcpi.c b/hw/s390x/sclpcpi.c
index ec4bdf23509b..97d37ae4b932 100644
--- a/hw/s390x/sclpcpi.c
+++ b/hw/s390x/sclpcpi.c
@@ -53,6 +53,7 @@
 #include "qemu/timer.h"
 #include "hw/s390x/event-facility.h"
 #include "hw/s390x/ebcdic.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-visit-machine.h"
 #include "qapi/qapi-events-machine-s390x.h"
 #include "migration/vmstate.h"
@@ -195,12 +196,13 @@ static void cpi_class_init(ObjectClass *klass, const void *data)
             "name of the cluster which the VM belongs to, if any"
             " e.g. \"PLEX    \"");
 
-    object_class_property_add(klass, "system_level", "uint64", get_system_level,
-                              NULL, NULL, NULL);
+    object_class_property_add_qapi(klass, "system_level",
+                                   &uint64_type_info, get_system_level,
+                                   NULL, NULL, NULL);
     object_class_property_set_description(klass, "system_level",
             "distribution and kernel version in Linux e.g. 74872343805430528");
 
-    object_class_property_add(klass, "timestamp", "uint64", get_timestamp,
+    object_class_property_add_qapi(klass, "timestamp", &uint64_type_info, get_timestamp,
                               NULL, NULL, NULL);
     object_class_property_set_description(klass, "timestamp",
             "latest update of CPI data in nanoseconds since the UNIX EPOCH");
diff --git a/hw/s390x/virtio-ccw-mem.c b/hw/s390x/virtio-ccw-mem.c
index dea30aacfb32..046dfd544cf3 100644
--- a/hw/s390x/virtio-ccw-mem.c
+++ b/hw/s390x/virtio-ccw-mem.c
@@ -13,6 +13,7 @@
 #include "qemu/osdep.h"
 #include "hw/core/qdev-properties.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qemu/module.h"
 #include "virtio-ccw-mem.h"
 #include "hw/mem/memory-device.h"
@@ -205,7 +206,7 @@ static void virtio_ccw_mem_instance_init(Object *obj)
                               OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP);
     object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev),
                               VIRTIO_MEM_SIZE_PROP);
-    object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size",
+    object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info,
                         virtio_ccw_mem_get_requested_size,
                         virtio_ccw_mem_set_requested_size, NULL, NULL);
 }
diff --git a/hw/sensor/adc128d818.c b/hw/sensor/adc128d818.c
index c65508cba144..b0f93e28d19f 100644
--- a/hw/sensor/adc128d818.c
+++ b/hw/sensor/adc128d818.c
@@ -8,6 +8,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/log.h"
+#include "qapi-builtin-type-infos.h"
 #include "qapi/error.h"
 #include "qapi/visitor.h"
 #include "qom/object.h"
@@ -642,15 +643,18 @@ static void adc128d818_initfn(Object *obj)
     for (unsigned ch = 0u; ch < ADC128D818_NUM_CHANNELS; ch++) {
         char *name = g_strdup_printf("ain%u", ch);
 
-        object_property_add(obj, name, "int", adc128d818_get_ain,
-                            adc128d818_set_ain, NULL, NULL);
+        object_property_add_qapi(obj, name, &int_type_info,
+                                 adc128d818_get_ain,
+                                 adc128d818_set_ain, NULL, NULL);
         g_free(name);
     }
 
-    object_property_add(obj, "temperature", "int", adc128d818_get_temperature,
-                        adc128d818_set_temperature, NULL, NULL);
-    object_property_add(obj, "ext-vref-mv", "int", adc128d818_get_ext_vref,
-                        adc128d818_set_ext_vref, NULL, NULL);
+    object_property_add_qapi(obj, "temperature", &int_type_info,
+                             adc128d818_get_temperature,
+                             adc128d818_set_temperature, NULL, NULL);
+    object_property_add_qapi(obj, "ext-vref-mv", &int_type_info,
+                             adc128d818_get_ext_vref,
+                             adc128d818_set_ext_vref, NULL, NULL);
 }
 
 static void adc128d818_realize(DeviceState *dev, Error **errp)
diff --git a/hw/sensor/adm1266.c b/hw/sensor/adm1266.c
index 37d1cffd57a9..62f563af7a7a 100644
--- a/hw/sensor/adm1266.c
+++ b/hw/sensor/adm1266.c
@@ -14,6 +14,7 @@
 #include "hw/core/irq.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
@@ -217,7 +218,7 @@ static void adm1266_init(Object *obj)
     for (int i = 0; i < ADM1266_NUM_PAGES; i++) {
         pmbus_page_config(pmdev, i, flags);
 
-        object_property_add(obj, "vout[*]", "uint16",
+        object_property_add_qapi(obj, "vout[*]", &uint16_type_info,
                             adm1266_get,
                             adm1266_set, NULL, &pmdev->pages[i].read_vout);
     }
diff --git a/hw/sensor/adm1272.c b/hw/sensor/adm1272.c
index 0aa2a8655683..e1c1bf1c54de 100644
--- a/hw/sensor/adm1272.c
+++ b/hw/sensor/adm1272.c
@@ -12,6 +12,7 @@
 #include "hw/core/irq.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
@@ -493,19 +494,19 @@ static void adm1272_init(Object *obj)
 
     pmbus_page_config(pmdev, 0, flags);
 
-    object_property_add(obj, "vin", "uint16",
+    object_property_add_qapi(obj, "vin", &uint16_type_info,
                         adm1272_get,
                         adm1272_set, NULL, &pmdev->pages[0].read_vin);
 
-    object_property_add(obj, "vout", "uint16",
+    object_property_add_qapi(obj, "vout", &uint16_type_info,
                         adm1272_get,
                         adm1272_set, NULL, &pmdev->pages[0].read_vout);
 
-    object_property_add(obj, "iout", "uint16",
+    object_property_add_qapi(obj, "iout", &uint16_type_info,
                         adm1272_get,
                         adm1272_set, NULL, &pmdev->pages[0].read_iout);
 
-    object_property_add(obj, "pin", "uint16",
+    object_property_add_qapi(obj, "pin", &uint16_type_info,
                         adm1272_get,
                         adm1272_set, NULL, &pmdev->pages[0].read_pin);
 
diff --git a/hw/sensor/emc141x.c b/hw/sensor/emc141x.c
index a51fc44395ab..5efe94643ca0 100644
--- a/hw/sensor/emc141x.c
+++ b/hw/sensor/emc141x.c
@@ -22,6 +22,7 @@
 #include "hw/i2c/i2c.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "qom/object.h"
@@ -251,16 +252,16 @@ static void emc141x_reset(DeviceState *dev)
 
 static void emc141x_initfn(Object *obj)
 {
-    object_property_add(obj, "temperature0", "int",
+    object_property_add_qapi(obj, "temperature0", &int_type_info,
                         emc141x_get_temperature,
                         emc141x_set_temperature, NULL, NULL);
-    object_property_add(obj, "temperature1", "int",
+    object_property_add_qapi(obj, "temperature1", &int_type_info,
                         emc141x_get_temperature,
                         emc141x_set_temperature, NULL, NULL);
-    object_property_add(obj, "temperature2", "int",
+    object_property_add_qapi(obj, "temperature2", &int_type_info,
                         emc141x_get_temperature,
                         emc141x_set_temperature, NULL, NULL);
-    object_property_add(obj, "temperature3", "int",
+    object_property_add_qapi(obj, "temperature3", &int_type_info,
                         emc141x_get_temperature,
                         emc141x_set_temperature, NULL, NULL);
 }
diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c
index 0fad04def773..8923e9e87510 100644
--- a/hw/sensor/isl_pmbus_vr.c
+++ b/hw/sensor/isl_pmbus_vr.c
@@ -9,6 +9,7 @@
 #include "qemu/osdep.h"
 #include "hw/sensor/isl_pmbus_vr.h"
 #include "hw/core/qdev-properties.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
@@ -136,63 +137,63 @@ static void isl_pmbus_vr_add_props(Object *obj, uint64_t *flags, uint8_t pages)
     PMBusDevice *pmdev = PMBUS_DEVICE(obj);
     for (int i = 0; i < pages; i++) {
         if (flags[i] & PB_HAS_VIN) {
-            object_property_add(obj, "vin[*]", "uint16",
+            object_property_add_qapi(obj, "vin[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_vin);
         }
 
         if (flags[i] & PB_HAS_VOUT) {
-            object_property_add(obj, "vout[*]", "uint16",
+            object_property_add_qapi(obj, "vout[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_vout);
         }
 
         if (flags[i] & PB_HAS_IIN) {
-            object_property_add(obj, "iin[*]", "uint16",
+            object_property_add_qapi(obj, "iin[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_iin);
         }
 
         if (flags[i] & PB_HAS_IOUT) {
-            object_property_add(obj, "iout[*]", "uint16",
+            object_property_add_qapi(obj, "iout[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_iout);
         }
 
         if (flags[i] & PB_HAS_PIN) {
-            object_property_add(obj, "pin[*]", "uint16",
+            object_property_add_qapi(obj, "pin[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_pin);
         }
 
         if (flags[i] & PB_HAS_POUT) {
-            object_property_add(obj, "pout[*]", "uint16",
+            object_property_add_qapi(obj, "pout[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_pout);
         }
 
         if (flags[i] & PB_HAS_TEMPERATURE) {
-            object_property_add(obj, "temp1[*]", "uint16",
+            object_property_add_qapi(obj, "temp1[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_temperature_1);
         }
 
         if (flags[i] & PB_HAS_TEMP2) {
-            object_property_add(obj, "temp2[*]", "uint16",
+            object_property_add_qapi(obj, "temp2[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_temperature_2);
         }
 
         if (flags[i] & PB_HAS_TEMP3) {
-            object_property_add(obj, "temp3[*]", "uint16",
+            object_property_add_qapi(obj, "temp3[*]", &uint16_type_info,
                                 isl_pmbus_vr_get,
                                 isl_pmbus_vr_set,
                                 NULL, &pmdev->pages[i].read_temperature_3);
diff --git a/hw/sensor/lsm303dlhc_mag.c b/hw/sensor/lsm303dlhc_mag.c
index cd5773ae64e8..c8085739ca47 100644
--- a/hw/sensor/lsm303dlhc_mag.c
+++ b/hw/sensor/lsm303dlhc_mag.c
@@ -25,6 +25,7 @@
 #include "hw/i2c/i2c.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "qemu/log.h"
@@ -509,19 +510,19 @@ static void lsm303dlhc_mag_reset(DeviceState *dev)
  */
 static void lsm303dlhc_mag_initfn(Object *obj)
 {
-    object_property_add(obj, "mag-x", "int",
+    object_property_add_qapi(obj, "mag-x", &int_type_info,
                 lsm303dlhc_mag_get_x,
                 lsm303dlhc_mag_set_x, NULL, NULL);
 
-    object_property_add(obj, "mag-y", "int",
+    object_property_add_qapi(obj, "mag-y", &int_type_info,
                 lsm303dlhc_mag_get_y,
                 lsm303dlhc_mag_set_y, NULL, NULL);
 
-    object_property_add(obj, "mag-z", "int",
+    object_property_add_qapi(obj, "mag-z", &int_type_info,
                 lsm303dlhc_mag_get_z,
                 lsm303dlhc_mag_set_z, NULL, NULL);
 
-    object_property_add(obj, "temperature", "int",
+    object_property_add_qapi(obj, "temperature", &int_type_info,
                 lsm303dlhc_mag_get_temperature,
                 lsm303dlhc_mag_set_temperature, NULL, NULL);
 }
diff --git a/hw/sensor/max34451.c b/hw/sensor/max34451.c
index 4d64434f3af4..3c8fa3d4a861 100644
--- a/hw/sensor/max34451.c
+++ b/hw/sensor/max34451.c
@@ -11,6 +11,7 @@
 #include "hw/core/irq.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/log.h"
 #include "qemu/module.h"
@@ -727,7 +728,7 @@ static void max34451_init(Object *obj)
 
     /* get and set the voltage in millivolts, max is 32767 mV */
     for (int i = 0; i < MAX34451_NUM_PWR_DEVICES; i++) {
-        object_property_add(obj, "vout[*]", "uint16",
+        object_property_add_qapi(obj, "vout[*]", &uint16_type_info,
                             max34451_get,
                             max34451_set, NULL, &pmdev->pages[i].read_vout);
     }
@@ -737,7 +738,7 @@ static void max34451_init(Object *obj)
      * centidegrees Celsius i.e.: 2500 -> 25.00 C, max is 327.67 C
      */
     for (int i = 0; i < MAX34451_NUM_TEMP_DEVICES; i++) {
-        object_property_add(obj, "temperature[*]", "uint16",
+        object_property_add_qapi(obj, "temperature[*]", &uint16_type_info,
                             max34451_get,
                             max34451_set,
                             NULL,
diff --git a/hw/sensor/tmp105.c b/hw/sensor/tmp105.c
index c5089d74f4bf..ce4ff4856afb 100644
--- a/hw/sensor/tmp105.c
+++ b/hw/sensor/tmp105.c
@@ -24,6 +24,7 @@
 #include "migration/vmstate.h"
 #include "hw/sensor/tmp105.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "hw/core/registerfields.h"
@@ -308,7 +309,7 @@ static void tmp105_realize(DeviceState *dev, Error **errp)
 
 static void tmp105_initfn(Object *obj)
 {
-    object_property_add(obj, "temperature", "int",
+    object_property_add_qapi(obj, "temperature", &int_type_info,
                         tmp105_get_temperature,
                         tmp105_set_temperature, NULL, NULL);
 }
diff --git a/hw/sensor/tmp421.c b/hw/sensor/tmp421.c
index 127edd0ba568..60844e76b21f 100644
--- a/hw/sensor/tmp421.c
+++ b/hw/sensor/tmp421.c
@@ -28,6 +28,7 @@
 #include "hw/i2c/i2c.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
 #include "qom/object.h"
@@ -350,16 +351,16 @@ static void tmp421_class_init(ObjectClass *klass, const void *data)
     dc->vmsd = &vmstate_tmp421;
     sc->dev = (DeviceInfo *) data;
 
-    object_class_property_add(klass, "temperature0", "int",
+    object_class_property_add_qapi(klass, "temperature0", &int_type_info,
                               tmp421_get_temperature,
                               tmp421_set_temperature, NULL, NULL);
-    object_class_property_add(klass, "temperature1", "int",
+    object_class_property_add_qapi(klass, "temperature1", &int_type_info,
                               tmp421_get_temperature,
                               tmp421_set_temperature, NULL, NULL);
-    object_class_property_add(klass, "temperature2", "int",
+    object_class_property_add_qapi(klass, "temperature2", &int_type_info,
                               tmp421_get_temperature,
                               tmp421_set_temperature, NULL, NULL);
-    object_class_property_add(klass, "temperature3", "int",
+    object_class_property_add_qapi(klass, "temperature3", &int_type_info,
                               tmp421_get_temperature,
                               tmp421_set_temperature, NULL, NULL);
 }
diff --git a/hw/usb/dev-storage-classic.c b/hw/usb/dev-storage-classic.c
index 977151c4a087..06584092bcae 100644
--- a/hw/usb/dev-storage-classic.c
+++ b/hw/usb/dev-storage-classic.c
@@ -9,6 +9,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/usb/usb.h"
 #include "hw/usb/desc.h"
@@ -122,7 +123,7 @@ out:
 
 static void usb_msd_instance_init(Object *obj)
 {
-    object_property_add(obj, "bootindex", "int32",
+    object_property_add_qapi(obj, "bootindex", &int32_type_info,
                         usb_msd_get_bootindex,
                         usb_msd_set_bootindex, NULL, NULL);
     object_property_set_int(obj, "bootindex", -1, NULL);
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 4c5f486ba238..9e43948128f7 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -27,6 +27,7 @@
 #include "hw/virtio/virtio-balloon.h"
 #include "system/address-spaces.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-events-machine.h"
 #include "qapi/visitor.h"
 #include "trace.h"
@@ -1022,7 +1023,7 @@ static void virtio_balloon_instance_init(Object *obj)
     object_property_add(obj, "guest-stats", "guest statistics",
                         balloon_stats_get_all, NULL, NULL, NULL);
 
-    object_property_add(obj, "guest-stats-polling-interval", "int",
+    object_property_add_qapi(obj, "guest-stats-polling-interval", &int_type_info,
                         balloon_stats_get_poll_interval,
                         balloon_stats_set_poll_interval,
                         NULL, NULL);
diff --git a/hw/virtio/virtio-mem-pci.c b/hw/virtio/virtio-mem-pci.c
index f592eb1a7849..80e9bfedd9f5 100644
--- a/hw/virtio/virtio-mem-pci.c
+++ b/hw/virtio/virtio-mem-pci.c
@@ -14,6 +14,7 @@
 #include "virtio-mem-pci.h"
 #include "hw/mem/memory-device.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-events-machine.h"
 #include "qapi/qapi-events-misc.h"
 
@@ -211,7 +212,7 @@ static void virtio_mem_pci_instance_init(Object *obj)
                               OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP);
     object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev),
                               VIRTIO_MEM_SIZE_PROP);
-    object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size",
+    object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info,
                         virtio_mem_pci_get_requested_size,
                         virtio_mem_pci_set_requested_size, NULL, NULL);
 }
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index 7130ed852d9c..42dc028e3bdc 100644
--- a/hw/virtio/virtio-mem.c
+++ b/hw/virtio/virtio-mem.c
@@ -26,6 +26,7 @@
 #include "hw/virtio/virtio-bus.h"
 #include "hw/virtio/virtio-mem.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "migration/misc.h"
 #include "hw/core/boards.h"
@@ -1533,14 +1534,15 @@ static void virtio_mem_instance_init(Object *obj)
 
     notifier_list_init(&vmem->size_change_notifiers);
 
-    object_property_add(obj, VIRTIO_MEM_SIZE_PROP, "size", virtio_mem_get_size,
-                        NULL, NULL, NULL);
-    object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size",
-                        virtio_mem_get_requested_size,
-                        virtio_mem_set_requested_size, NULL, NULL);
-    object_property_add(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, "size",
-                        virtio_mem_get_block_size, virtio_mem_set_block_size,
-                        NULL, NULL);
+    object_property_add_qapi(obj, VIRTIO_MEM_SIZE_PROP, &size_type_info,
+                             virtio_mem_get_size,
+                             NULL, NULL, NULL);
+    object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info,
+                             virtio_mem_get_requested_size,
+                             virtio_mem_set_requested_size, NULL, NULL);
+    object_property_add_qapi(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, &size_type_info,
+                             virtio_mem_get_block_size, virtio_mem_set_block_size,
+                             NULL, NULL);
 }
 
 static void virtio_mem_instance_finalize(Object *obj)
diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c
index cca37202ffb2..7b4fd933a8fb 100644
--- a/hw/xen/xen-pvh-common.c
+++ b/hw/xen/xen-pvh-common.c
@@ -9,6 +9,7 @@
 #include "qemu/osdep.h"
 #include "qemu/error-report.h"
 #include "qemu/units.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "hw/core/boards.h"
 #include "hw/core/irq.h"
@@ -413,7 +414,7 @@ void xen_pvh_class_setup_common_props(XenPVHMachineClass *xpc)
 
 #define OC_MEMMAP_PROP_BASE(c, prop_name, name)                           \
 do {                                                                      \
-    object_class_property_add(c, prop_name "-base", "uint64_t",           \
+    object_class_property_add_qapi(c, prop_name "-base", &uint64_type_info,\
                               xen_pvh_get_ ## name ## _base,              \
                               xen_pvh_set_ ## name ## _base, NULL, NULL); \
     object_class_property_set_description(oc, prop_name "-base",          \
@@ -422,7 +423,7 @@ do {                                                                      \
 
 #define OC_MEMMAP_PROP_SIZE(c, prop_name, name)                           \
 do {                                                                      \
-    object_class_property_add(c, prop_name "-size", "uint64_t",           \
+    object_class_property_add_qapi(c, prop_name "-size", &size_type_info, \
                               xen_pvh_get_ ## name ## _size,              \
                               xen_pvh_set_ ## name ## _size, NULL, NULL); \
     object_class_property_set_description(oc, prop_name "-size",          \
@@ -458,7 +459,7 @@ do {                                                                      \
         OC_MEMMAP_PROP(oc, "pci-mmio", pci_mmio);
         OC_MEMMAP_PROP(oc, "pci-mmio-high", pci_mmio_high);
 
-        object_class_property_add(oc, "pci-intx-irq-base", "uint32_t",
+        object_class_property_add_qapi(oc, "pci-intx-irq-base", &uint32_type_info,
                                   xen_pvh_get_pci_intx_irq_base,
                                   xen_pvh_set_pci_intx_irq_base,
                                   NULL, NULL);
@@ -468,7 +469,7 @@ do {                                                                      \
 
 #ifdef CONFIG_TPM
     if (xpc->has_tpm) {
-        object_class_property_add(oc, "tpm-base-addr", "uint64_t",
+        object_class_property_add_qapi(oc, "tpm-base-addr", &uint64_type_info,
                                   xen_pvh_get_tpm_base,
                                   xen_pvh_set_tpm_base,
                                   NULL, NULL);
diff --git a/iothread.c b/iothread.c
index 76eea6df3861..7285135d40a8 100644
--- a/iothread.c
+++ b/iothread.c
@@ -20,6 +20,7 @@
 #include "system/event-loop-base.h"
 #include "system/iothread.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-commands-misc.h"
 #include "qemu/error-report.h"
 #include "qemu/rcu.h"
@@ -315,19 +316,19 @@ static void iothread_class_init(ObjectClass *klass, const void *class_data)
     bc->init = iothread_init;
     bc->update_params = iothread_set_aio_context_params;
 
-    object_class_property_add(klass, "poll-max-ns", "int64",
+    object_class_property_add_qapi(klass, "poll-max-ns", &int64_type_info,
                               iothread_get_poll_param,
                               iothread_set_poll_param,
                               NULL, &poll_max_ns_info);
-    object_class_property_add(klass, "poll-grow", "int64",
+    object_class_property_add_qapi(klass, "poll-grow", &int64_type_info,
                               iothread_get_poll_param,
                               iothread_set_poll_param,
                               NULL, &poll_grow_info);
-    object_class_property_add(klass, "poll-shrink", "int64",
+    object_class_property_add_qapi(klass, "poll-shrink", &int64_type_info,
                               iothread_get_poll_param,
                               iothread_set_poll_param,
                               NULL, &poll_shrink_info);
-    object_class_property_add(klass, "poll-weight", "int64",
+    object_class_property_add_qapi(klass, "poll-weight", &int64_type_info,
                               iothread_get_poll_param,
                               iothread_set_poll_param,
                               NULL, &poll_weight_info);
diff --git a/net/colo-compare.c b/net/colo-compare.c
index a6910de869ff..4b237a59d120 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -16,6 +16,7 @@
 #include "qemu/error-report.h"
 #include "trace.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "net/net.h"
 #include "net/eth.h"
 #include "qom/object_interfaces.h"
@@ -1373,15 +1374,15 @@ static void colo_compare_init(Object *obj)
     object_property_add_str(obj, "notify_dev",
                             compare_get_notify_dev, compare_set_notify_dev);
 
-    object_property_add(obj, "compare_timeout", "uint64",
+    object_property_add_qapi(obj, "compare_timeout", &uint64_type_info,
                         compare_get_timeout,
                         compare_set_timeout, NULL, NULL);
 
-    object_property_add(obj, "expired_scan_cycle", "uint32",
+    object_property_add_qapi(obj, "expired_scan_cycle", &uint32_type_info,
                         compare_get_expired_scan_cycle,
                         compare_set_expired_scan_cycle, NULL, NULL);
 
-    object_property_add(obj, "max_queue_size", "uint32",
+    object_property_add_qapi(obj, "max_queue_size", &uint32_type_info,
                         get_max_queue_size,
                         set_max_queue_size, NULL, NULL);
 
diff --git a/net/dump.c b/net/dump.c
index 0c39f09892c2..3d7bb36182ec 100644
--- a/net/dump.c
+++ b/net/dump.c
@@ -25,6 +25,7 @@
 #include "qemu/osdep.h"
 #include "clients.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qemu/error-report.h"
 #include "qemu/iov.h"
 #include "qemu/module.h"
@@ -238,8 +239,9 @@ static void filter_dump_class_init(ObjectClass *oc, const void *data)
 {
     NetFilterClass *nfc = NETFILTER_CLASS(oc);
 
-    object_class_property_add(oc, "maxlen", "uint32", filter_dump_get_maxlen,
-                              filter_dump_set_maxlen, NULL, NULL);
+    object_class_property_add_qapi(oc, "maxlen", &uint32_type_info,
+                                   filter_dump_get_maxlen,
+                                   filter_dump_set_maxlen, NULL, NULL);
     object_class_property_add_str(oc, "file", file_dump_get_filename,
                                   file_dump_set_filename);
 
diff --git a/net/filter-buffer.c b/net/filter-buffer.c
index 427da24097f2..9d7a9f5cb2c7 100644
--- a/net/filter-buffer.c
+++ b/net/filter-buffer.c
@@ -10,6 +10,7 @@
 #include "net/filter.h"
 #include "net/queue.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qemu/timer.h"
 #include "qemu/iov.h"
 #include "qapi/qapi-builtin-visit.h"
@@ -182,7 +183,7 @@ static void filter_buffer_class_init(ObjectClass *oc, const void *data)
 {
     NetFilterClass *nfc = NETFILTER_CLASS(oc);
 
-    object_class_property_add(oc, "interval", "uint32",
+    object_class_property_add_qapi(oc, "interval", &uint32_type_info,
                               filter_buffer_get_interval,
                               filter_buffer_set_interval, NULL, NULL);
 
diff --git a/qom/object.c b/qom/object.c
index 89a5ea04ab2e..65e640d1b7d1 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -22,9 +22,9 @@
 #include "qapi/string-output-visitor.h"
 #include "qapi/qobject-input-visitor.h"
 #include "qapi/forward-visitor.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-builtin-visit.h"
 #include "qobject/qdict.h"
-#include "qobject/qjson.h"
 #include "qemu/id.h"
 #include "qapi/qmp/qerror.h"
 #include "trace.h"
@@ -2425,7 +2425,7 @@ object_property_add_str(Object *obj, const char *name,
     prop->get = get;
     prop->set = set;
 
-    return object_property_add(obj, name, "string",
+    return object_property_add_qapi(obj, name, &str_type_info,
                                get ? property_get_str : NULL,
                                set ? property_set_str : NULL,
                                property_release_data,
@@ -2443,7 +2443,7 @@ object_class_property_add_str(ObjectClass *klass, const char *name,
     prop->get = get;
     prop->set = set;
 
-    return object_class_property_add(klass, name, "string",
+    return object_class_property_add_qapi(klass, name, &str_type_info,
                                      get ? property_get_str : NULL,
                                      set ? property_set_str : NULL,
                                      NULL,
@@ -2495,7 +2495,7 @@ object_property_add_bool(Object *obj, const char *name,
     prop->get = get;
     prop->set = set;
 
-    return object_property_add(obj, name, "bool",
+    return object_property_add_qapi(obj, name, &bool_type_info,
                                get ? property_get_bool : NULL,
                                set ? property_set_bool : NULL,
                                property_release_data,
@@ -2512,7 +2512,7 @@ object_class_property_add_bool(ObjectClass *klass, const char *name,
     prop->get = get;
     prop->set = set;
 
-    return object_class_property_add(klass, name, "bool",
+    return object_class_property_add_qapi(klass, name, &bool_type_info,
                                      get ? property_get_bool : NULL,
                                      set ? property_set_bool : NULL,
                                      NULL,
@@ -2761,8 +2761,8 @@ object_property_add_uint8_ptr(Object *obj, const char *name,
         setter = property_set_uint8_ptr;
     }
 
-    return object_property_add(obj, name, "uint8",
-                               getter, setter, NULL, (void *)v);
+    return object_property_add_qapi(obj, name, &uint8_type_info,
+                                    getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2782,8 +2782,8 @@ object_class_static_property_add_uint8_ptr(ObjectClass *klass,
         setter = property_set_uint8_ptr;
     }
 
-    return object_class_property_add(klass, name, "uint8",
-                                     getter, setter, NULL, (void *)v);
+    return object_class_property_add_qapi(klass, name, &uint8_type_info,
+                                          getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2802,8 +2802,8 @@ object_property_add_uint16_ptr(Object *obj, const char *name,
         setter = property_set_uint16_ptr;
     }
 
-    return object_property_add(obj, name, "uint16",
-                               getter, setter, NULL, (void *)v);
+    return object_property_add_qapi(obj, name, &uint16_type_info,
+                                    getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2823,8 +2823,8 @@ object_class_static_property_add_uint16_ptr(ObjectClass *klass,
         setter = property_set_uint16_ptr;
     }
 
-    return object_class_property_add(klass, name, "uint16",
-                                     getter, setter, NULL, (void *)v);
+    return object_class_property_add_qapi(klass, name, &uint16_type_info,
+                                          getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2843,8 +2843,8 @@ object_property_add_uint32_ptr(Object *obj, const char *name,
         setter = property_set_uint32_ptr;
     }
 
-    return object_property_add(obj, name, "uint32",
-                               getter, setter, NULL, (void *)v);
+    return object_property_add_qapi(obj, name, &uint32_type_info,
+                                    getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2864,8 +2864,8 @@ object_class_static_property_add_uint32_ptr(ObjectClass *klass,
         setter = property_set_uint32_ptr;
     }
 
-    return object_class_property_add(klass, name, "uint32",
-                                     getter, setter, NULL, (void *)v);
+    return object_class_property_add_qapi(klass, name, &uint32_type_info,
+                                          getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2884,8 +2884,8 @@ object_property_add_uint64_ptr(Object *obj, const char *name,
         setter = property_set_uint64_ptr;
     }
 
-    return object_property_add(obj, name, "uint64",
-                               getter, setter, NULL, (void *)v);
+    return object_property_add_qapi(obj, name, &uint64_type_info,
+                                    getter, setter, NULL, (void *)v);
 }
 
 ObjectProperty *
@@ -2905,8 +2905,8 @@ object_class_static_property_add_uint64_ptr(ObjectClass *klass,
         setter = property_set_uint64_ptr;
     }
 
-    return object_class_property_add(klass, name, "uint64",
-                                     getter, setter, NULL, (void *)v);
+    return object_class_property_add_qapi(klass, name, &uint64_type_info,
+                                          getter, setter, NULL, (void *)v);
 }
 
 typedef struct {
diff --git a/system/bootdevice.c b/system/bootdevice.c
index 9538b08983f5..7789e464186a 100644
--- a/system/bootdevice.c
+++ b/system/bootdevice.c
@@ -24,6 +24,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "system/system.h"
 #include "qapi/visitor.h"
 #include "qemu/error-report.h"
@@ -336,7 +337,7 @@ void device_add_bootindex_property(Object *obj, int32_t *bootindex,
     prop->suffix = suffix;
     prop->dev = dev;
 
-    object_property_add(obj, name, "int32",
+    object_property_add_qapi(obj, name, &int32_type_info,
                         device_get_bootindex,
                         device_set_bootindex,
                         property_release_bootindex,
diff --git a/system/memory.c b/system/memory.c
index 164c18757f8f..46a0dbaf6859 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -16,6 +16,7 @@
 #include "qemu/osdep.h"
 #include "qemu/log.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "system/memory.h"
 #include "qapi/visitor.h"
 #include "qemu/bitops.h"
@@ -1318,11 +1319,11 @@ static void memory_region_initfn(Object *obj)
 
     object_property_add_uint64_ptr(OBJECT(mr), "addr",
                                    &mr->addr, OBJ_PROP_FLAG_READ);
-    object_property_add(OBJECT(mr), "priority", "int32",
+    object_property_add_qapi(OBJECT(mr), "priority", &int32_type_info,
                         memory_region_get_priority,
                         NULL, /* memory_region_set_priority */
                         NULL, NULL);
-    object_property_add(OBJECT(mr), "size", "uint64",
+    object_property_add_qapi(OBJECT(mr), "size", &uint64_type_info,
                         memory_region_get_size,
                         NULL, /* memory_region_set_size, */
                         NULL, NULL);
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 28167355773b..62c0fa5a9e51 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -20,6 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "cpu.h"
 #include "cpregs.h"
 #include "qemu/module.h"
@@ -320,7 +321,7 @@ static void prop_bool_set_false(Object *obj, Visitor *v, const char *name,
 
 static void prop_add_stub_bool(Object *obj, const char *name)
 {
-    object_property_add(obj, name, "bool", prop_bool_get_false,
+    object_property_add_qapi(obj, name, &bool_type_info, prop_bool_get_false,
                         prop_bool_set_false, NULL, NULL);
 }
 
@@ -510,13 +511,13 @@ void aarch64_add_sve_properties(Object *obj)
     for (vq = 1; vq <= ARM_MAX_VQ; ++vq) {
         char name[8];
         snprintf(name, sizeof(name), "sve%d", vq * 128);
-        object_property_add(obj, name, "bool", cpu_arm_get_vq,
+        object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq,
                             cpu_arm_set_vq, NULL, &cpu->sve_vq);
     }
 
 #ifdef CONFIG_USER_ONLY
     /* Mirror linux /proc/sys/abi/sve_default_vector_length. */
-    object_property_add(obj, "sve-default-vector-length", "int32",
+    object_property_add_qapi(obj, "sve-default-vector-length", &int32_type_info,
                         cpu_arm_get_default_vec_len,
                         cpu_arm_set_default_vec_len, NULL,
                         &cpu->sve_default_vq);
@@ -535,13 +536,13 @@ void aarch64_add_sme_properties(Object *obj)
     for (vq = 1; vq <= ARM_MAX_VQ; vq <<= 1) {
         char name[8];
         snprintf(name, sizeof(name), "sme%d", vq * 128);
-        object_property_add(obj, name, "bool", cpu_arm_get_vq,
+        object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq,
                             cpu_arm_set_vq, NULL, &cpu->sme_vq);
     }
 
 #ifdef CONFIG_USER_ONLY
     /* Mirror linux /proc/sys/abi/sme_default_vector_length. */
-    object_property_add(obj, "sme-default-vector-length", "int32",
+    object_property_add_qapi(obj, "sme-default-vector-length", &int32_type_info,
                         cpu_arm_get_default_vec_len,
                         cpu_arm_set_default_vec_len, NULL,
                         &cpu->sme_default_vq);
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index d40a6a985914..96531e8c28a8 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -20,6 +20,7 @@
 #include "qemu/main-loop.h"
 #include "qom/object.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "system/system.h"
 #include "system/runstate.h"
 #include "system/ramblock.h"
@@ -1776,7 +1777,7 @@ static void kvm_arch_set_eager_split_size(Object *obj, Visitor *v,
 
 void kvm_arch_accel_class_init(ObjectClass *oc)
 {
-    object_class_property_add(oc, "eager-split-size", "size",
+    object_class_property_add_qapi(oc, "eager-split-size", &size_type_info,
                               kvm_arch_get_eager_split_size,
                               kvm_arch_set_eager_split_size, NULL, NULL);
 
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 24f34947eca8..c47aaa9df65f 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -20,6 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "cpu.h"
 #include "qemu/module.h"
 #include "qapi/visitor.h"
@@ -1438,10 +1439,10 @@ void aarch64_max_tcg_initfn(Object *obj)
     aarch64_add_pauth_properties(obj);
     aarch64_add_sve_properties(obj);
     aarch64_add_sme_properties(obj);
-    object_property_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_max_vq,
+    object_property_add_qapi(obj, "sve-max-vq", &uint32_type_info, cpu_max_get_sve_max_vq,
                         cpu_max_set_sve_max_vq, NULL, NULL);
     object_property_add_bool(obj, "x-rme", cpu_arm_get_rme, cpu_arm_set_rme);
-    object_property_add(obj, "x-l0gptsz", "uint32", cpu_max_get_l0gptsz,
+    object_property_add_qapi(obj, "x-l0gptsz", &uint32_type_info, cpu_max_get_l0gptsz,
                         cpu_max_set_l0gptsz, NULL, NULL);
     qdev_property_add_static(DEVICE(obj), &arm_cpu_lpa2_property);
 }
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 567cbf04ca75..472c33736f36 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -10431,7 +10431,7 @@ static void x86_cpu_register_bit_prop(X86CPUClass *xcc,
         fp = g_new0(BitProperty, 1);
         fp->w = w;
         fp->mask = mask;
-        object_class_property_add(oc, prop_name, "bool",
+        object_class_property_add_qapi(oc, prop_name, &bool_type_info,
                                   x86_cpu_get_bit_prop,
                                   x86_cpu_set_bit_prop,
                                   NULL, fp);
@@ -10947,13 +10947,13 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data)
 
     dc->user_creatable = true;
 
-    object_class_property_add(oc, "family", "uint64",
+    object_class_property_add_qapi(oc, "family", &uint64_type_info,
                               x86_cpuid_version_get_family,
                               x86_cpuid_version_set_family, NULL, NULL);
-    object_class_property_add(oc, "model", "uint64",
+    object_class_property_add_qapi(oc, "model", &uint64_type_info,
                               x86_cpuid_version_get_model,
                               x86_cpuid_version_set_model, NULL, NULL);
-    object_class_property_add(oc, "stepping", "uint64",
+    object_class_property_add_qapi(oc, "stepping", &uint64_type_info,
                               x86_cpuid_version_get_stepping,
                               x86_cpuid_version_set_stepping, NULL, NULL);
     object_class_property_add_str(oc, "vendor",
@@ -10962,7 +10962,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data)
     object_class_property_add_str(oc, "model-id",
                                   x86_cpuid_get_model_id,
                                   x86_cpuid_set_model_id);
-    object_class_property_add(oc, "tsc-frequency", "int",
+    object_class_property_add_qapi(oc, "tsc-frequency", &int_type_info,
                               x86_cpuid_get_tsc_freq,
                               x86_cpuid_set_tsc_freq, NULL, NULL);
     /*
@@ -10975,7 +10975,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data)
                               x86_cpu_get_unavailable_features,
                               NULL, NULL, NULL);
 
-    object_class_property_add(oc, "avx10-version",  "uint8",
+    object_class_property_add_qapi(oc, "avx10-version",  &uint8_type_info,
                               x86_cpuid_get_avx10_version,
                               x86_cpuid_set_avx10_version,
                               NULL, NULL);
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 601b78df5363..6824af33bd32 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -7099,7 +7099,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc)
         .set = kvm_arch_set_notify_vmexit,
     ));
 
-    object_class_property_add(oc, "notify-window", "uint32",
+    object_class_property_add_qapi(oc, "notify-window", &uint32_type_info,
                               kvm_arch_get_notify_window,
                               kvm_arch_set_notify_window,
                               NULL, NULL);
@@ -7107,7 +7107,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc)
                                           "Clock cycles without an event window "
                                           "after which a notification VM exit occurs");
 
-    object_class_property_add(oc, "xen-version", "uint32",
+    object_class_property_add_qapi(oc, "xen-version", &uint32_type_info,
                               kvm_arch_get_xen_version,
                               kvm_arch_set_xen_version,
                               NULL, NULL);
@@ -7116,14 +7116,14 @@ void kvm_arch_accel_class_init(ObjectClass *oc)
                                           "(in XENVER_version form "
                                           "e.g. 0x4000a for 4.10)");
 
-    object_class_property_add(oc, "xen-gnttab-max-frames", "uint16",
+    object_class_property_add_qapi(oc, "xen-gnttab-max-frames", &uint16_type_info,
                               kvm_arch_get_xen_gnttab_max_frames,
                               kvm_arch_set_xen_gnttab_max_frames,
                               NULL, NULL);
     object_class_property_set_description(oc, "xen-gnttab-max-frames",
                                           "Maximum number of grant table frames");
 
-    object_class_property_add(oc, "xen-evtchn-max-pirq", "uint16",
+    object_class_property_add_qapi(oc, "xen-evtchn-max-pirq", &uint16_type_info,
                               kvm_arch_get_xen_evtchn_max_pirq,
                               kvm_arch_set_xen_evtchn_max_pirq,
                               NULL, NULL);
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 335a504af4db..01bd9eceaedc 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -3175,7 +3175,7 @@ sev_snp_guest_class_init(ObjectClass *oc, const void *data)
     x86_klass->adjust_cpuid_features = sev_snp_adjust_cpuid_features;
     x86_klass->kvm_type = sev_snp_kvm_type;
 
-    object_class_property_add(oc, "policy", "uint64",
+    object_class_property_add_qapi(oc, "policy", &uint64_type_info,
                               sev_snp_guest_get_policy,
                               sev_snp_guest_set_policy, NULL, NULL);
     object_class_property_add_str(oc, "guest-visible-workarounds",
diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index 55de3bd5d5de..4d81225de37f 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -23,6 +23,7 @@
 #include "kvm_ppc.h"
 #include "system/cpus.h"
 #include "qemu/error-report.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/error.h"
 #include "qapi/visitor.h"
 #include "cpu-models.h"
@@ -335,7 +336,7 @@ void ppc_compat_add_property(Object *obj, const char *name,
     gchar *names, *desc;
     int i;
 
-    object_property_add(obj, name, "string",
+    object_property_add_qapi(obj, name, &str_type_info,
                         ppc_compat_prop_get, ppc_compat_prop_set, NULL,
                         compat_pvr);
 
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 23b5023dd37e..6116d6da7685 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -27,6 +27,7 @@
 #include "target/riscv/tcg/csr.h"
 #include "internals.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/error-report.h"
 #include "qemu/timer.h"
@@ -1306,20 +1307,20 @@ void riscv_add_satp_mode_properties(Object *obj)
 {
     RISCVCPU *cpu = RISCV_CPU(obj);
 
-    object_property_add(obj, "svbare", "bool", cpu_riscv_get_satp,
-                        cpu_riscv_set_satp, NULL, &cpu->satp_modes);
+    object_property_add_qapi(obj, "svbare", &bool_type_info, cpu_riscv_get_satp,
+                             cpu_riscv_set_satp, NULL, &cpu->satp_modes);
 
     if (cpu->env.misa_mxl == MXL_RV32) {
-        object_property_add(obj, "sv32", "bool", cpu_riscv_get_satp,
+        object_property_add_qapi(obj, "sv32", &bool_type_info, cpu_riscv_get_satp,
                             cpu_riscv_set_satp, NULL, &cpu->satp_modes);
     } else {
-        object_property_add(obj, "sv39", "bool", cpu_riscv_get_satp,
+        object_property_add_qapi(obj, "sv39", &bool_type_info, cpu_riscv_get_satp,
                             cpu_riscv_set_satp, NULL, &cpu->satp_modes);
-        object_property_add(obj, "sv48", "bool", cpu_riscv_get_satp,
+        object_property_add_qapi(obj, "sv48", &bool_type_info, cpu_riscv_get_satp,
                             cpu_riscv_set_satp, NULL, &cpu->satp_modes);
-        object_property_add(obj, "sv57", "bool", cpu_riscv_get_satp,
+        object_property_add_qapi(obj, "sv57", &bool_type_info, cpu_riscv_get_satp,
                             cpu_riscv_set_satp, NULL, &cpu->satp_modes);
-        object_property_add(obj, "sv64", "bool", cpu_riscv_get_satp,
+        object_property_add_qapi(obj, "sv64", &bool_type_info, cpu_riscv_get_satp,
                             cpu_riscv_set_satp, NULL, &cpu->satp_modes);
     }
 }
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 97069bf597a7..90660643da59 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -24,6 +24,7 @@
 
 #include "qemu/timer.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "qapi/visitor.h"
@@ -532,7 +533,7 @@ static void riscv_cpu_add_kvm_unavail_prop(Object *obj, const char *prop_name)
      * unknown to KVM and error out if the user attempts
      * to enable any of them.
      */
-    object_property_add(obj, prop_name, "bool",
+    object_property_add_qapi(obj, prop_name, &bool_type_info,
                         cpu_get_cfg_unavailable,
                         cpu_set_cfg_unavailable,
                         NULL, (void *)prop_name);
@@ -552,7 +553,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj)
         misa_cfg->name = riscv_get_misa_ext_name(bit);
         misa_cfg->description = riscv_get_misa_ext_description(bit);
 
-        object_property_add(cpu_obj, misa_cfg->name, "bool",
+        object_property_add_qapi(cpu_obj, misa_cfg->name, &bool_type_info,
                             kvm_cpu_get_misa_ext_cfg,
                             kvm_cpu_set_misa_ext_cfg,
                             NULL, misa_cfg);
@@ -568,7 +569,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj)
     for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) {
         KVMCPUConfig *multi_cfg = &kvm_multi_ext_cfgs[i];
 
-        object_property_add(cpu_obj, multi_cfg->name, "bool",
+        object_property_add_qapi(cpu_obj, multi_cfg->name, &bool_type_info,
                             kvm_cpu_get_multi_ext_cfg,
                             kvm_cpu_set_multi_ext_cfg,
                             NULL, multi_cfg);
diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 9e3cc87f8a31..92e03a386832 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -26,6 +26,7 @@
 #include "pmu.h"
 #include "time_helper.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qemu/accel.h"
 #include "qemu/error-report.h"
@@ -1438,7 +1439,7 @@ static void riscv_cpu_add_misa_properties(Object *cpu_obj)
             continue;
         }
 
-        object_property_add(cpu_obj, name, "bool",
+        object_property_add_qapi(cpu_obj, name, &bool_type_info,
                             cpu_get_misa_ext_cfg,
                             cpu_set_misa_ext_cfg,
                             NULL, (void *)misa_cfg);
@@ -1492,7 +1493,7 @@ static void riscv_cpu_add_profiles(Object *cpu_obj)
     for (int i = 0; riscv_profiles[i] != NULL; i++) {
         RISCVCPUProfile *profile = riscv_profiles[i];
 
-        object_property_add(cpu_obj, profile->name, "bool",
+        object_property_add_qapi(cpu_obj, profile->name, &bool_type_info,
                             cpu_get_profile, cpu_set_profile,
                             NULL, (void *)profile);
 
@@ -1568,10 +1569,10 @@ static void riscv_cpu_add_user_properties(Object *obj)
 
     for (edata = isa_edata_arr; edata && edata->name; edata++) {
         if (edata->prop_name) {
-            object_property_add(obj, edata->prop_name, "bool",
-                                cpu_get_multi_ext_cfg,
-                                cpu_set_multi_ext_cfg,
-                                NULL, (void *)&edata->ext_enable_offset);
+            object_property_add_qapi(obj, edata->prop_name, &bool_type_info,
+                                     cpu_get_multi_ext_cfg,
+                                     cpu_set_multi_ext_cfg,
+                                     NULL, (void *)&edata->ext_enable_offset);
         }
     }
 
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index f292af7ad01c..f12634234352 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -17,6 +17,7 @@
 #include "system/kvm.h"
 #include "system/tcg.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qemu/error-report.h"
 #include "qapi/visitor.h"
 #include "qemu/module.h"
@@ -908,13 +909,13 @@ void s390_cpu_model_class_register_props(ObjectClass *oc)
 
     for (feat = 0; feat < S390_FEAT_MAX; feat++) {
         const S390FeatDef *def = s390_feat_def(feat);
-        object_class_property_add(oc, def->name, "bool", get_feature,
+        object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature,
                                   set_feature, NULL, (void *) feat);
         object_class_property_set_description(oc, def->name, def->desc);
     }
     for (group = 0; group < S390_FEAT_GROUP_MAX; group++) {
         const S390FeatGroupDef *def = s390_feat_group_def(group);
-        object_class_property_add(oc, def->name, "bool", get_feature_group,
+        object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature_group,
                                   set_feature_group, NULL, (void *) group);
         object_class_property_set_description(oc, def->name, def->desc);
     }
diff --git a/tests/unit/test-qdev-global-props.c b/tests/unit/test-qdev-global-props.c
index 8ea362cbb902..204436fb7276 100644
--- a/tests/unit/test-qdev-global-props.c
+++ b/tests/unit/test-qdev-global-props.c
@@ -27,6 +27,7 @@
 #include "hw/core/qdev-properties.h"
 #include "qom/object.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 
 
@@ -171,10 +172,12 @@ static void prop2_accessor(Object *obj, Visitor *v, const char *name,
 
 static void dynamic_instance_init(Object *obj)
 {
-    object_property_add(obj, "prop1", "uint32", prop1_accessor, prop1_accessor,
-                        NULL, NULL);
-    object_property_add(obj, "prop2", "uint32", prop2_accessor, prop2_accessor,
-                        NULL, NULL);
+    object_property_add_qapi(obj, "prop1", &uint32_type_info,
+                             prop1_accessor, prop1_accessor,
+                             NULL, NULL);
+    object_property_add_qapi(obj, "prop2", &uint32_type_info,
+                             prop2_accessor, prop2_accessor,
+                             NULL, NULL);
 }
 
 static void dynamic_class_init(ObjectClass *oc, const void *data)
diff --git a/ui/console.c b/ui/console.c
index a8a2a247d8f4..b4345b06d012 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -28,6 +28,7 @@
 #include "ui/vgafont.h"
 #include "hw/core/qdev.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-commands-ui.h"
 #include "qapi/visitor.h"
 #include "qemu/coroutine.h"
@@ -535,7 +536,7 @@ qemu_graphic_console_class_init(ObjectClass *oc, const void *data)
                                    offsetof(QemuGraphicConsole, device),
                                    object_property_allow_set_link,
                                    OBJ_PROP_LINK_STRONG);
-    object_class_property_add(oc, "head", "uint32",
+    object_class_property_add_qapi(oc, "head", &uint32_type_info,
                               qemu_graphic_console_prop_get_head,
                               NULL, NULL, NULL);
 
diff --git a/util/thread-context.c b/util/thread-context.c
index 88d8f0a55a4e..7fa6840dd401 100644
--- a/util/thread-context.c
+++ b/util/thread-context.c
@@ -13,6 +13,7 @@
 #include "qemu/osdep.h"
 #include "qemu/thread-context.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/qapi-builtin-visit.h"
 #include "qapi/visitor.h"
 #include "qemu/config-file.h"
@@ -278,13 +279,13 @@ static void thread_context_class_init(ObjectClass *oc, const void *data)
     UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
 
     ucc->complete = thread_context_instance_complete;
-    object_class_property_add(oc, "thread-id", "uint64",
+    object_class_property_add_qapi(oc, "thread-id", &uint64_type_info,
                               thread_context_get_thread_id, NULL, NULL,
                               NULL);
-    object_class_property_add(oc, "cpu-affinity", "[uint16]",
+    object_class_property_add_qapi(oc, "cpu-affinity", &uint16List_type_info,
                               thread_context_get_cpu_affinity,
                               thread_context_set_cpu_affinity, NULL, NULL);
-    object_class_property_add(oc, "node-affinity", "[uint16]", NULL,
+    object_class_property_add_qapi(oc, "node-affinity", &uint16List_type_info, NULL,
                               thread_context_set_node_affinity, NULL, NULL);
 }
 

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:25:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:25:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393990.1632794 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHx0-0004kn-KO; Tue, 18 Aug 2026 11:25:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393990.1632794; Tue, 18 Aug 2026 11:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwHx0-0004kg-Hc; Tue, 18 Aug 2026 11:25:50 +0000
Received: by outflank-mailman (input) for mailman id 1393990;
 Tue, 18 Aug 2026 11:25:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwHwy-0004kX-VK
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:25:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwHwy-00Gj8b-Bs
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:25:48 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a844136-2eae-0a2a0a5409dd-0a2a4501ab6e-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:25:48 +0200
Received: from [52.101.201.64]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a84413a-5984-0a2a45010019-3465c9401a88-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:25:47 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BLAPR03MB5572.namprd03.prod.outlook.com (2603:10b6:208:292::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 11:25:44 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Tue, 18 Aug 2026
 11:25:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mu9i2Hfb3ioo6UGjjycxdB2qaxjT/HR6L7V2+jywOzBqmiM6Cg774o9OEud1ewYi9G4m2X719uAzbyKcPnXBxACJ8wH6+hex6MnwETJVQlk0rnG2zqgEqupBCeL3Qd/3g/9PtQpSLKqtCBkw4CodBrmvN/ErBZ6rSbwW1DzkFK9r6ETNvT0/95pMhgZW0PubdpXWjX1/OI8lGN7TlRf7tZcj+8NY9vL7XQI/cReFYp1Ef6spDIDiB8R53Ud9sdAz0Zo4dbtbWmK32JubiCoueR9DHpGaKcNVCRNRcJcjAxQ8xahgaTwP/jQCN9lQIJadnID39eyn3NmdUNi5PrBNuQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=I2PDRsXl3qSiajdMqTa8WBM2OuMW0US74uehJ7v6P/8=;
 b=RayS9DEecC3LW7J13QywCGg4NN6LdA49x3/tQoVZrSFjHH8NQUzwKW2XhxaWYtZtP3MzhpR5GYIjj9H+JaR+0o+/sSd7wZEAKj29aHHU60r+SBZpyyDJ+yh6UtifNdX+SJ3pNB+KglcuzIBENj5Gxo22A6kf4VFWDMRFX8Q6eQUf9+TajVz+QbNtvm8uaaHK81mBbL615fWXQikIdavLdZgMJP5TaRvc7oZs7h8gg6B2K/lq/nun/4brnjEbhDDkN/CLIkVobBeDrsobQm865rmprI8EkFCBKxEPsdvxaQHCJsq2epG0vBn4/m8vk98VtTjhfh0QHWiY01dWLZaGAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=I2PDRsXl3qSiajdMqTa8WBM2OuMW0US74uehJ7v6P/8=;
 b=JzzlOmjs3r4HoYsBJreJfjsYR+l1L8XjcsbQOg54rm/gjmGhUgn9Cj3YLdjirVKc9oUWd0bgV+yD+dP5L4ltmCHraiTr/lERkRG6C+E3GbuHoc0+SwRUOS27YQqbixiK1FSmTBs5AGYrEdiqyaOSc1JOEZdxRNrhLwPJeA46EEo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <4291b18a-c33e-4068-82b5-1cfdad211cbc@citrix.com>
Date: Tue, 18 Aug 2026 12:25:41 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 2/3] x86/emul: Rename the x86_seg_* system segments
To: Jan Beulich <jbeulich@suse.com>
References: <20260814185841.1757421-3-andrew.cooper3@citrix.com>
 <20260817121129.1787344-1-andrew.cooper3@citrix.com>
 <e3e692f6-c9f6-4ed9-9212-fa61521f22e6@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <e3e692f6-c9f6-4ed9-9212-fa61521f22e6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0065.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:153::16) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BLAPR03MB5572:EE_
X-MS-Office365-Filtering-Correlation-Id: 88510243-842b-400a-414a-08defd1b718a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	h5rJynVhREZsQmyHmbQNK8mfEjCEcu3nO/zhuC4/D7zsbMtj6zAQGjoaE0huLLk2XD0wIsB8AwuYLbgSgCOe/0WheLB3Ldr1N2QeMHm5uqcVPkOgGxT3m4whiHHzwvoCOPfhJ5kfcunC0Vxw2gHHaa6FKSpqvoZI/F6S8yFgRc5+sKU7Lbfli3eHkvl/3OKONHIHa94gJkJ4Fjy+L3rVDZwhVSdDfBNnlCR0yq0OZq8hr17dMA5fRoB2ebJpBAE0kuy5KJQ09f32+zyA840NHnwf4Bdilnwi7w4pJvXhtuIXHWQ07XDeqYj9q7X8NFZ1CgiJf+zjyPB2Hl8pCarXsyKSSd7NB/BjVaAfmdc60TD8fi2RvuG6SGrIH/N/q2PAFHOgvRdHgSjGhWZ+xUplSAKTi0otLZ3QBHQ+NtBO6p7qLY6CdqeIFCzkqQMpBLm2YiFiZb5jlWRZHDxNpueWHxguNOl1anvtzddlHgr6yr6+wUNgnP+Bl33PglbmCf2FCF+Z2324eFZ7mf4+UBFT/skbD6VGgXhs0AHF+fH2Wz2/EUFOA/3S5Q58GhIHmBLywiNX0+IucH4bnuyVY4a4nwB6tuVk5X9HI6TDggwfThyAu01cMrsBd/+DNkgSYjrVoIHDxC3tdZwh3NZjcVd5f8Fio/5X/p8/z5ryWEWwyss=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NTFnYVRua0d4RE1KaEtCNVdxakg4emdvUnU1WXlTQW5GcDdqbGErSUdreTlO?=
 =?utf-8?B?MWkzY0FyZkNtZzhyOXdTRHR6OXAvWXhibDVrK1FnUEwwT1h3eFh5RkppbEk1?=
 =?utf-8?B?STlGcWRBaDdLT2Ivc2dQTGN4ZGlUZnBlajg5M25CdjBoeFkvNXphc0ZQTURT?=
 =?utf-8?B?Y0xlTUpZbVNTaC9Sc29IdTI5T21ScEp4MG9QU1hQUk0zVlRkdWpIYWtKZUpq?=
 =?utf-8?B?Z0dJV0lhRDBWVmJWZ0hZdTNMU3M3Umh6dlBacFBSTW9yNi90aVZmUnJoTmJ3?=
 =?utf-8?B?WjMxcWt5WkZuWDFtY2R0RWNNeWJTSG8xSXVpMkc5dTVMeXdwUGs0UzZUUTRC?=
 =?utf-8?B?VG80eU5weVRBSHgwU0JaK3d4djdUL3NyL1pxaEhOVjJWZSt0VmpJaVZjOWM2?=
 =?utf-8?B?d09mY2pMYmowZ3dKRjBNZDdLQ2doVTlkSno0cHAxeFRiSXVrZTUzSlJYNHk2?=
 =?utf-8?B?SHMwS1RFcTNIL1QwM1d0Ty96akdhYTl5eldIbjI0OVp3OE5ZbmJmU2xCM2Vx?=
 =?utf-8?B?K1VGUGtmOTVONmNvbDlpUHk0RUhaSXZ1Rm5od05TSGtlTm55cWhVS0FGUWV2?=
 =?utf-8?B?OUYrWFJWRVg1d0pQM1RtSERabUtNTGRRUmZXY1djWjVuUnJybW5IR1BsS2tN?=
 =?utf-8?B?c1NOcmMzTHREVGFuSTQycm1OenlmT205ZnFlYUlTY2srb205M0x3aWpkamFt?=
 =?utf-8?B?eXllVXlmVjU3d2xJQTJQWS9IQ1kvSHFueCtrWGgvN2djejJuM3NyQ0w4blo4?=
 =?utf-8?B?dzd5WnFqL0xHanZJWTloRTJwUGFrM3BmTStjNzM3WXhIaGhzbXd4MDR6cG04?=
 =?utf-8?B?Q1FMV0FIT2hhU2RzRFRFV1NOcSswK2xsM2d6MTZFVk04alk0UkZlU3hqcU1j?=
 =?utf-8?B?Mk50VTBINXBIQVZ0N3pNY281cDhBbnY0RDB0M0xUSVlPRWNmUFdROWVNVmly?=
 =?utf-8?B?WWxWbkkrbXMvN1RTdHBCd3hlSlRSRXZza2xpSXBFTVExUGtZbml3L0V3WVRV?=
 =?utf-8?B?QTlraC96YVYxem5kUko0TlpHM1QySjR6NXNOelZta3B6bndqUS9MZ3dIS3Rk?=
 =?utf-8?B?bmdlRnZSdktkUlp6ZS8wVVJHeUJrdzF3ZzVVbG9BVHR3TTFRTnBPeWdVV1Ur?=
 =?utf-8?B?TURpZUhXUllOYU44ZndjTWp1SUw4Tm1lbTU1TVhmR1o4cnptdnBaS3FIOGdm?=
 =?utf-8?B?SzkzSUhveTFGSkNKeGRScjlLZm1jcll4WkdydVJqekluOHVzM3dONzljQ0Vq?=
 =?utf-8?B?YUg1WnI2WFQrRWlpRWV3SVFjTW8wVHZ3bTVoejdkZ1I2MDU0dFBCR3ZQTFlI?=
 =?utf-8?B?TEsrS1FId25rZ2tzOUswQm9POEdreWRjMGVVMkVPbThrOUtUWmNnMTBRQkFM?=
 =?utf-8?B?T3dNdHVQWDdyb0J5dUFyWDFYSmRXczR4RXJ6dFA5N290cGFCMVVkeU05YjhR?=
 =?utf-8?B?RVdzYlV5c3JZRW5ldE5qT2tvRmJoU3BxRDZSTkFyTU9IbnUxM2lsTC9YUUxE?=
 =?utf-8?B?ZGp1YldxS1JrcFdhWjZ1WmV0Y2txTUUzbW14NDk0YWFVcWVvenRSMkxSdzMy?=
 =?utf-8?B?YmR3UnFHTEt0RndzRlVkT0Z4ZThKOE9RKzVKUCtLQXg3VnhZTHVxUU5yK254?=
 =?utf-8?B?WGp1cGp6ZWZVb2tXcjVKN2xoU041LzlRSFdCYUJYaFFDUlh0WUxFaHhXcEZi?=
 =?utf-8?B?Q0hzcVhyY1hHZzhWdWt3MVJOa3EwbTQwbWkxSTFFWkE5TVJ4RjNuaVFyY0sr?=
 =?utf-8?B?RGVTRHJ5aU9VNkJZckZPNE92cFZGckpIQytBanBTTGJlM0Jwc3pUanA2UVdW?=
 =?utf-8?B?Qk9vOG8wd3VCaTNDbFpwRzJkZ1l0blRiOThJVFB6eEZRZ3g5OVRXUUFlYVdU?=
 =?utf-8?B?dTVNV0Rjd1NhWWVoOE1VbVlIaDVRdjdOUU5qWkFpUW1QYkcrOHFVbWxRakRZ?=
 =?utf-8?B?TktJWXJndUg0b0tYSnEwckdtdTk0TG12Ym9EQnRxZ0FOa1JkSmw0c2I5YU1K?=
 =?utf-8?B?SnJqMyt4QS84SUhwaENCdXZIWnI4UUJnc25zWWpGZVh4S0E5SXBFZ3BBeGpI?=
 =?utf-8?B?d0c2YUMyYWQrelNydTFUbEN2Um1oRWlPZkZJbTMrbG90TURTb3pFQlNIYVFV?=
 =?utf-8?B?dUJOaGNMZk44TWdEakpyZmtRSGxwcVdBY0VHQ2NYNmllQTI2NnhEelFjK1l1?=
 =?utf-8?B?TmZLdGFlM3RBRGRLZlBaTFUxMzFFMjU3K2l1UlhOZ3RVVXNqQU9obXRzSXhX?=
 =?utf-8?B?SzRmM0d1ZlRZa2JoUjIxTnRCbW5UWXFxUEE5c0NkY3ZRNGpIaU1HMjVER01K?=
 =?utf-8?B?SzVyNTU5cEtCeHVwbGQ4eGFicEoyRjJjdmZjK0FTQU9NN2xFYUZTZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 88510243-842b-400a-414a-08defd1b718a
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 11:25:44.4697
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: y9JbFRA3jD9RKz9HMxmsMAiM76sv+QE/xvh4CYzFHjVc8HisWIDcX0TwN61kh2YOXuJH2tCZMgOq/0NKjczvZ3Ve+lZsyBmn8SZI3YHSe+E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5572
X-purgate-ID: tlsNG-d62444/1787052348-BC558757-949087AF/0/0
X-purgate-type: clean
X-purgate-size: 1495

On 18/08/2026 7:31 am, Jan Beulich wrote:
> On 17.08.2026 14:11, Andrew Cooper wrote:
>> @@ -131,18 +131,21 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
>>  #define SEG(s, r) ({                                                        \
>>      s = (struct segment_register)                                           \
>>          { 0, { (r)->s ## _ar }, (r)->s ## _limit, (r)->s ## _base };        \
>> -    /* Set accessed / busy bit for present segments. */                     \
>> +    /* Set accessed bit for present segments. */                            \
>>      if ( (s).p )                                                            \
>> -        (s).type |= (x86_seg_ ## s != x86_seg_tr ? 1 : 2);                  \
> From this, ...
>
>> +        (s).type |= 2;                                                      \
> ... this wants to be 1, while ...
>
>>      check_segment(&(s), x86_seg_ ## s); })
>>  
>>          rc = SEG(cs, regs);
>>          rc |= SEG(ds, regs);
>>          rc |= SEG(ss, regs);
>>          rc |= SEG(es, regs);
>> -        rc |= SEG(tr, regs);
>>  #undef SEG
>>  
>> +        tr = (struct segment_register){
>> +            0, { regs->tr_ar | 1 /* Busy */ }, regs->tr_limit, regs->tr_base };
> ... this wants to be 2.

Yes, I did spot that just after sending.  I thought I emailed out, but
clearly didn't.

>  Then:
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thanks.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:33:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:33:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394000.1632813 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4G-0006iN-IS; Tue, 18 Aug 2026 11:33:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394000.1632813; Tue, 18 Aug 2026 11:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4G-0006iG-FX; Tue, 18 Aug 2026 11:33:20 +0000
Received: by outflank-mailman (input) for mailman id 1394000;
 Tue, 18 Aug 2026 11:33:19 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwI4F-0006VX-18
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:33:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwI4E-00BTlp-Dq
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:33:18 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442f4-2eae-0a2a0a5409dd-0a2a4503e17c-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:18 +0200
Received: from [40.107.130.130]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442fd-fae8-0a2a45030019-286b8282bd98-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:18 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by PAVPR03MB9598.eurprd03.prod.outlook.com (2603:10a6:102:301::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 11:33:14 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 11:33:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kflSWwRqRsPQ9DCXjWQOsFEkpzMeLfkHZsTQyRPjeeLqgGHL44GtnyF9Y/lw17SPy1ImNadgvtVcvsirPYIbLbBVY/83AVVImFQvu845CvRZkuYB0kAAMHe2KVnz3s79Igy8Kve0oHqvjVKK5fjWaFHm5sXLILVThvnf1Kb9ax+5UgDcNIlpOMFAMx/HswMlA/VrdNSwI/SEGVZyH6sAeqvpqui42gUmEuiS2oKqqKHDyZosd0ABBP0dn+sTmJD3AUu02i6JhCQCf7Rg9M1jf5656zR9kdIL1qk818BLY9O7gLe01CW5Avr3p0M10uS0SzX0MCtldQq08IyaFcCOOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=N70P7aW11jK3CbWzYj+uAhsxTa1DoTppUHe0Uo144Mg=;
 b=ZmtUw2E8OsSMeg9ZHV1T6S8JigpY9JM1DSmck7H/cFvq0FHFKIXt5+e+1po8qhtMv+pTdkMLlfpLKucJ80pDYB4xREAfVfH0ntU36y4hfEP5N3E9FykGTAx1EflnYbei8h4sszqmF1GdXxR1SqQj+CAsc4y4W2f6EsNpnQdXI5GPLb06pnnxmcwR81Mo8AkAQDLvdir2yZZPeEyB+t6CNrnfzdM3PT3tLKG/J0zDcYYwFm/hHY4PSFhLKiRFquNl1R8Jhelbz1TSGnMzvMkqB6GCzz7tNyJkEfgc+7TKJUD+vNBULz0HTh7bKJ2sYC42b8DjfTKZxwFYNBNzMo8gZw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=N70P7aW11jK3CbWzYj+uAhsxTa1DoTppUHe0Uo144Mg=;
 b=hYdZ9HNyuo9ff6eQowz46v8JS+sTyyOsHOhnrW5fLA69suZ21sDJqibb28k3cBol2flnP7kSpHXY8kJm6PygCN1MM3DgEhgb9d9PaBhCONh0NUcdRYM0T4AHXbr2Qu7Md+OjH8SNfqTJV6sIVQo5O/atlxjnC/4JFcrgyqq3ZgPZCd6X/4sFe3SQ+Mjv87ME/fMtxAi8dSRUJx9sZzqIAzM+G2a7hOAhX4OvXH8BTwDK8S1dWUedzBZBn+Zm3hRfndvI9M2Z5QztS+gFvEakv7+QhMwDJgP8/kSkt+mS5CHQPD9v9QxxrnSaWwK8iMooRzaKRnnV+MZqh0uVT2/MeA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v3 1/4] xen/arm: make is_espi() a pure range predicate
Date: Tue, 18 Aug 2026 14:32:59 +0300
Message-ID: <8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787050437.git.mykola_kvach@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA1PEPF00005B92.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::63a) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PAVPR03MB9598:EE_
X-MS-Office365-Filtering-Correlation-Id: 8910cc88-e67a-4d0f-cf64-08defd1c7db9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|56012099006|6133799003|11063799006|5023799004|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	PZ8PAuzk9Q5Vf5FiseYvsusMLdT1VAUlJIjRjFenPOc/GgPLqrGzTeI2GCFUT5J1PVeQDH06HPCglXRS5iUvkac3i2wl7EdHoO1RuKd43XEjXWkvKPwNeFbWQIBgDyq8kWzRD6uvYsUUeoUVPw90wiXSipNBsNzwWly52Z9K3AdXGiZGtb91rdhxXMzmgq7v6uB1jEY9J3J9v46SpcOel+Hnl10zEWQT/1iC6XGTvvSnedaIafXt0NzhCpNF8DYSMBF4JE9BacNSuRbXatuTBvFbVC1MDkjRH4G/99g0jEkOFb39B1wGQQZ1ywUEdFM7UBEqXRGCha7iCSKLev0RXDN94nNkeZUMWzDEXsV2gE3LvlKpcrob5bCQBh2y/tiC4wCnI6yuoqnpFp0YB53G/WcwOANrSnlkN5OBT+M7j7KkczbYyYVh2GrGPiulvZRuG8PryPtYlcwWvFcVMI8LgeMXA/AEkcBC4YnuOAUoEloXHF4xCADY6zC1ejreosJL/F9/VDXc+ERRXg6DAoh4Ow1oXq4mPJBC/eGeCF8DcIctJgPWwZLiadNMMLVl9/WAu+pIFT2LdAakDhXu3uKiG6c3tp9tVaxW39Os7db8HYOsqx/qCJ/e7llLXMxcQMdJMrZiI8dEb95D93qapbqOURqTRGZEdhVoY+Wk6B3HRMg=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(10067099003)(56012099006)(6133799003)(11063799006)(5023799004)(18002099003)(22082099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?esAz5BYUxkkMJC+r+p3700VyeF7WFIqOeda8FUq3m8qqJHX8LqPLKbCH55cx?=
 =?us-ascii?Q?BPV0jN8yP8osaiPUaWfsMvA+mTqT6okuqB4mNWFoBZqIZkxKrNwv4ehiZzsG?=
 =?us-ascii?Q?xntjlDCkVT6cGrJEDJXJVOh9eTjn7wQQy7gA+3cZOXU0xjo2o0Afi4zvEsZu?=
 =?us-ascii?Q?haJyGhGRQETs1SmiQ7DTnOVD/T9MjOQLUwuyn2mte1OEKPIPjXmxOlGaCzI3?=
 =?us-ascii?Q?eWppbcSWw81DkI9iqBIQE/tDCtrhWcqxBZy4xmyPNvWS98uLx/BVTHi4EKSq?=
 =?us-ascii?Q?oDNQOFbamVyR0MKG00YA6vghSGdfMVaNZ91ci2NxuyWg01Z2iX/mSDL8lgzr?=
 =?us-ascii?Q?ZGLHJY0DLBULrs5pyt2cGcF4EJ8Xk5fMrarED9D7SBZNdEXim4LlAuVjkO7S?=
 =?us-ascii?Q?d1zJqWWDJ3QjN/eFNGq5jsUh27MlACX96h1yHGbsZ0fJFbOInkJFf0DEebqM?=
 =?us-ascii?Q?GzlUyrnEUsgoO1AB4gT9590zKQPvQRAHtuFCqdx2+Ws73+Cwk1XqaIGXgpeR?=
 =?us-ascii?Q?YVRCfa6VP6yr2hOAnn9NgQBKsoUWeUBN4iTHGAemjhzU7Cmv/mZcvqH/kHSy?=
 =?us-ascii?Q?s0C9FJFy0ku5WQpuHJp+I9mzUN3kVJEBEcUSf+hOpfMtNujTlslBS0OA+OHQ?=
 =?us-ascii?Q?GP4LHvQ5/OcwfwIADb3Cw9pTV+z5YQvR/kKXgcWu7DQPxbHm7veAUHfV+5H7?=
 =?us-ascii?Q?uve7ByStOuOjTPbS+bewl+s8QvSRIgywB+MdYxIwdwaWCZiwoG3rnx3mXT5U?=
 =?us-ascii?Q?56Gq2loC9hQpg4GQHoCjkvFOjEyVZyn6eY6O+iAgJ1KGNtWnkappuNH2fIq2?=
 =?us-ascii?Q?lqPUrmUAFhEZLvrmZlQ3y2OsOpkcYUIa+IEemuLjH8M/AuDmt6VEsMhcBNo0?=
 =?us-ascii?Q?6ZQTGOEAYD9K+KG1/W37Q3Xw7JqKEHNfeQwpXEf+4lIRyCvNjdpdCLP85Gr5?=
 =?us-ascii?Q?gMFPN7ZDaLbjfgYPv0Kxswb7XSEaFhMvSSD4yYeTq1JLjeBR2Q2O3onu8olE?=
 =?us-ascii?Q?KqSpOq/FXFNKJ9hgHQTgewEtgkRI2mj8RmPkbJn1kMPyi0t5ATTp1y8pPVJD?=
 =?us-ascii?Q?xweWeQ+CqR37TAws0GGcHlIlSA3yKi6WbSgnKarFzTykkt8A5WJiFeHjlHgR?=
 =?us-ascii?Q?cH939nWcnlH2qiYH/qJdqKoXvXUiqh7OdU8Ue720eglCYgHgAdAv9nKHwLFt?=
 =?us-ascii?Q?BHqzDtEQICtW5ynsiNGMFI2AYcF2aC8HFRXdzL8nJJ5BBkrxADNUCR93yvqo?=
 =?us-ascii?Q?uSqGK7WF4ubd+ocnqpP/fF8N4WRWc8u2mfxPh0ylwE4Qz1GqSwI009RC8cnr?=
 =?us-ascii?Q?hyd3dWfGFqb58SihBbTSnr26rQRB7veYxujG6JwvDbKyK17Q3hrLsIeh9TSP?=
 =?us-ascii?Q?1u2tsFUr6ngb0oGDKRiacEuGaU6qTSs4X19GOS265YEawvbz+rNfU+yvp55d?=
 =?us-ascii?Q?FPFb5Fo9jwvqNVd78nrrNfFJQgOocFVESuQvrsZVhWV6G83XxXfv+aM+32oi?=
 =?us-ascii?Q?Okhlk/UJAkAkbzxKyinCQxs/n2xJyDFldm7rjFsq5CSDWcNyRMGkWzkn7JiZ?=
 =?us-ascii?Q?+7VAUSZJ6V6Y4RLS4AlJ+lzQ1kNldSUvBPfvk27FHR16mFG75e2od2O7PqtP?=
 =?us-ascii?Q?LmIZ/997XB/CPzg1y1xUzsz6kDYCMYHGYRd17rBJzDoPWHSufC7lRut9mpPE?=
 =?us-ascii?Q?RFW4PxeXhW37sUZrILcvMHwS9y8La+BGYgzGeU/8jv4A3VTiZSOPU2mN1mXg?=
 =?us-ascii?Q?EvuS7EJkOw=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8910cc88-e67a-4d0f-cf64-08defd1c7db9
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 11:33:14.4821
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Y3KILa40u7z8D8qOLSTWfnIsQZomPPyjXGrom6Pq5V7uFcc/EwHLrBJ45wAndM0CEs1KSceiyBqttqTt8GgR8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9598
X-purgate-ID: tlsNG-33051d/1787052798-768FA4E9-1643847A/0/0
X-purgate-type: clean
X-purgate-size: 3024

is_espi() currently changes its result according to CONFIG_GICV3_ESPI
and asserts when an eSPI INTID is passed to a build without eSPI
support. This makes a range predicate carry configuration policy and
causes callers to depend on its hidden side effects.

Make is_espi() report only whether an INTID is in the architectural
eSPI range. Gate eSPI handling explicitly at call sites and preserve
the debug checks on paths where an eSPI is invalid without compiled-in
support.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v3:
- New preparatory cleanup requested during review.
---
 xen/arch/arm/gic.c             |  5 ++++-
 xen/arch/arm/include/asm/irq.h | 11 -----------
 xen/arch/arm/vgic.c            |  4 ++--
 3 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 078049e741..075e1d2c50 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -348,7 +348,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
         /* Reading IRQ will ACK it */
         irq = gic_hw_ops->read_irq();
 
-        if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) )
+        ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq));
+
+        if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) ||
+             (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)) )
         {
             isb();
             do_IRQ(regs, irq, is_fiq);
diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
index 09788dbfeb..c29f3d04a3 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq)
 
 static inline bool is_espi(unsigned int irq)
 {
-#ifdef CONFIG_GICV3_ESPI
     return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID;
-#else
-    /*
-     * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is
-     * disabled. Returning false allows the compiler to optimize the code
-     * when the config is disabled, while the assert ensures that out-of-range
-     * array resources are not accessed.
-     */
-    ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID));
-    return false;
-#endif
 }
 
 static inline unsigned int espi_intid_to_idx(unsigned int intid)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e5aca17dcb..e14123a30a 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -718,8 +718,9 @@ struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq)
     unsigned int idx;
 
     ASSERT(irq >= NR_LOCAL_IRQS);
+    ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq));
 
-    if ( is_espi(irq) )
+    if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq) )
     {
         unsigned int nr_spis = d->arch.vgic.nr_spis;
 
@@ -949,4 +950,3 @@ void vgic_check_inflight_irqs_pending(struct vcpu *v, unsigned int rank, uint32_
  * indent-tabs-mode: nil
  * End:
  */
-
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:33:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:33:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1393999.1632804 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4F-0006Vq-CA; Tue, 18 Aug 2026 11:33:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1393999.1632804; Tue, 18 Aug 2026 11:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4F-0006Vi-96; Tue, 18 Aug 2026 11:33:19 +0000
Received: by outflank-mailman (input) for mailman id 1393999;
 Tue, 18 Aug 2026 11:33:18 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwI4E-0006VW-P1
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:33:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwI4E-00BTlp-5j
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:33:18 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442f4-2eae-0a2a0a5409dd-0a2a4503e17c-28
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:18 +0200
Received: from [40.107.130.130]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442fd-fae8-0a2a45030019-286b8282bd98-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:17 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by PAVPR03MB9598.eurprd03.prod.outlook.com (2603:10a6:102:301::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 11:33:12 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 11:33:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TWaTj36pJ4WdZZW1g/zPgznk+Ex/RrdlyfmDg8HKdtu4JYRyOyWZnrf7nxRhVsKNoav3YaG2J43DZctUMGJLsFhi0yCq5bhYTT4Mi0zrRT7SBZisUjXBiCCPO5G7GOpTwyKxGohOLr3C3hvSWwUNFtp7K80bhOxIi84HjDUUuEbayObecVLxZaex59WrJQeEMY4AtH/jTT2h2MAZvPcjNjRGg1aadlVgMJBlkMTW69thjD02RuOS/xC74xXomJuv4ozm4KHTf2sJvJcijI4UDU+SOW503TrA2MqLhg4PfFJXJC8ZH35UfdTEss1NeYwua1Om7O682CSehFzzYZXoMg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hbPdzC7WpK/2tg/s9h3Y3KTdD8QT9vS/xIsoEwcoJ4c=;
 b=TzqmxZNmrr0bYIN70vxeiaGvzzXEBcetL9FrdFSf50zFXioptKetCUpUYW71zoBIMFynJ3uD9YNfzFZgbUxMq8GbGQi6rT3IDeaI1bsFf5alowPCWmLhDOogPcSre6Ul/b9PtTYJQMgrpQ73rYwb6qN7tOVTli7qj7kFPgew20+0ADFEmyEJQiES5RGy92SKb7NHgdbxX4Fn0PDa0t/266N2IMLFSPe00SF5MGsHw8ZG4Vwbg/Pm7lTu4xqOQKPkRGC4zwYIRJ+pYw6ElpAis+wMn4bn12G/edT0peLtd+YlCt89nZZnDMr2OEPmnGcbBPNGf05j5kKR994ciH7+yQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hbPdzC7WpK/2tg/s9h3Y3KTdD8QT9vS/xIsoEwcoJ4c=;
 b=lx+7VhOwO2dZPvODrJqmT1Qp37qWEvFA/m0uyk4CStB4eYh6+qQ2oHyKN9voZFwohz3gcRFc/+WBpV3R/gzG0iw/Y17BPabG59gI9F7cMTksKRbHQH/cfKHjKy/ExYcT6RsTgn+vAIYFWbYBvRlwj+H3XCTF8oz6/3NydUEBv7KpWY2gxZAx1JLP/UyO0vDgGqnbqXxV3nQzORvgqGYqsPO7sPALRQFyXmfaeGm3HUvL0+rEVxH8Y7P80U/ftkQhnmgWD9EM8Gl7dgCSWarngy9KLB6Z5qSBiHg3VgRO5y6zifLi+uGIAfzvkApxlKeJjlscvadB5jZKjxIxErDIKQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jens Wiklander <jenswi@kernel.org>
Subject: [PATCH v3 0/4] xen/arm: Fix eSPI IRQ handling
Date: Tue, 18 Aug 2026 14:32:58 +0300
Message-ID: <cover.1787050437.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA1PEPF00005B92.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::63a) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PAVPR03MB9598:EE_
X-MS-Office365-Filtering-Correlation-Id: 5a28dd87-6f4f-4b26-67d3-08defd1c7c54
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|10067099003|56012099006|6133799003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	5sDXSX7sHK+pO5kIDCyVQ7xm9XUcJ/QxTFewR0SyWmbxJKkPYbSz6XNlqbJIBNCten15OhIzDWAlOJJeoCtnh1t1kBvbDMX5Lh/tWFmLBUq3tvRIu3wAO62pmbyoKEavIp+MlCQXWap5SswSXYT9vx1tAsko/tiVM93UGuk6LWFhr4S8s1W8nY62gHk2XeI+HXHRMaV+9RAJ8NRZWAf5z9VM31YRQJTjJNQGpeCy1BGcobucoNXKKDEh+BI1Ye4PvANMmAEIzFStLSlapaVRqFePuSBAuer/rWdlodm9RCk77GOoUFtsyaBvM11B8YY1w6Y8MCzmf/3n5B8hcWoHLOdMrnneZIf2odQrobKdFcc+CC3+v7hreXzYnVP7SOoFMLU20QIh4tzR2a8A0keYaEZnLSP6095r8LipxUeS+5Z+E/7kkAtYFOn8VZ+YgwYZam2Re+LZPJWqmT+EeMIx1U5NQAHpYlQSKNMyza2gnwG6d3NLaoEBaHy4EihgK4ad8ENsddS7Az6xBo92LOzVhCnSyP8DYLFKnjAC1LrzpisqMaynAGO2P1W1hQa+r0MkDd8l48MZ0qy2hNnT8ZqpaJrw7cubNiu6o8xmpf+aEORnO6wsgmWsDpbnBsXK16t5
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(7416014)(376014)(10067099003)(56012099006)(6133799003)(11063799006)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?JwbJgBo36aBhgkExis4RjaGY/Dm1es6jCJug2DiCuHP3isNxN4Mk7T8VaCOr?=
 =?us-ascii?Q?xwGsGqa328YXs7ow4IK95etmh8IwFlXGR3JObpk+LloF27CeZ+Fj2b21Lnoa?=
 =?us-ascii?Q?UPNxsQEbJwQbP7hzjkIe+56LR6sVBhF1pR7wYJrQkp7Nth5AMEYGldL8M8qD?=
 =?us-ascii?Q?PSd4S3Tx+nyor8U6vekJ63oClxlm8WQqKtiXS1PgnTuL7IatBE7ZpT+ORYri?=
 =?us-ascii?Q?5lEtz3GynFZO6dvJZ9YU5EYBNkr+GU4yglI4bSdf0XHENWs3Jn+++3judC1q?=
 =?us-ascii?Q?gm98swlm9JFjOGG0+UsQDTuxVXcpr4djggZXwrzCXL2NFIvwEdzO3mI8AS9D?=
 =?us-ascii?Q?MWpMfj/8E7bp0GgWOFrcaqIHxpb+Eves34BAACJh6QvJWgXMiUIrQH95jD4Z?=
 =?us-ascii?Q?VUZWFJVVRX3s6i5QeQCxPD9389KSAMwuB+Zyfc3vRAh/AV6Jd2nPjnh+KUac?=
 =?us-ascii?Q?FCczBXGJFtUpkYgJn90ujjyiDQxIRlMKJY1P/tXRimlFHj/CD5wLSAEV3NJ3?=
 =?us-ascii?Q?sAEOcr/0JxSpQltdYQxkTrgFUnChrMJLeI3oa6RM5ThN4t8cES+HWpVvu0e1?=
 =?us-ascii?Q?MJtmIeF/kd9MOUQHaEuXeVDb6fSCpaaaEBigbkDnv+a1MXPJG9ERzztp/+Xl?=
 =?us-ascii?Q?NrMxiWgE4Chm+Co6l5HHXHrCoUlhrhIGot6iDSRqhR67be9pB5rQM79rfDvj?=
 =?us-ascii?Q?o6orlzsmNCZlDFhj5wtJ6MuDOJwYWNlNjM7c9j3b5FP7/uCoQZLPOd0vONfU?=
 =?us-ascii?Q?Y8Sn6AgOC4mbpu6vdfIhGBTV95GP2U6vkWHG26CYWq8qp9l96Xn4CvjTsqqn?=
 =?us-ascii?Q?x1hqSeRjJ/1+LXsww+rlbLhbirC99p/NKHAmr0ksQOuN+p7OsCytOdQZEBn/?=
 =?us-ascii?Q?KsxfC6egGA4vEtYEMJQsTVVC5wwB+RfFtShTXwL1AMi8Df9v18ax83GDg8He?=
 =?us-ascii?Q?2TJ8Cm2yaAARdxds0ZV6EEIPw0VrsL107tnDB23QxLWiglL8MFTOW9O0IOZP?=
 =?us-ascii?Q?NDtu960DkH1W12fp4JmCK7ctDqcpIjE4DuSWK/OYl1+kj/jOABqX7JsDqif9?=
 =?us-ascii?Q?MAstWmog2XKb9Nw7SevkghbNrUQehTqv2GbJeYMe1MkyEaPHsEa2kAyC/nYd?=
 =?us-ascii?Q?EfUu1ZffnwEaTX8wv3PTmPVaPbmdPaNoNXwjzbZpsKKmAKXX9+myToG97il8?=
 =?us-ascii?Q?/l1dcw29AwDG7E8jBOZ6jOpWkhj4cbboNVmu8LaPytymFSTJ5FGHawCPk2tQ?=
 =?us-ascii?Q?qXEqr9uMmuotrP8FK6KuRMNvJM8wWjrkWHhiNG/F6FbaJJjfBitCzEIKj8ra?=
 =?us-ascii?Q?lL14dXJg7TAihCbhQ3OteY0gz84DqfK12OrzvLYV959oD64eyug8Zww3cE6r?=
 =?us-ascii?Q?0M4YBhMmrpnufpxUJ9A3jgVfYkdF28duKTDjaNR1W/GAMNB/CzwcSMtg7047?=
 =?us-ascii?Q?1vOr++9nCMEcNJoUY6Nwj2X7NOljWEbdRm2h2e/0aYQyTHBGG+FtkRnACagL?=
 =?us-ascii?Q?fQeW8iio6na3Jblj2LoEdFU4DoQyQRWeEJT2n4s9McaCFzBYyP9Yn2BkOVvR?=
 =?us-ascii?Q?jFzbtXvw4RfR9vd4IEb+nCW7r+lvi13h3pRK7E/UQuKieDmnLNucRh826ROI?=
 =?us-ascii?Q?PNJC3Doy1DHTnNELa9hfLc6AIzjYSnG6DEO5+ddLboDWLGLmtcf8BzrNFCIi?=
 =?us-ascii?Q?yXZd25JPhOGbDx3PXITbNoM2b6NdDwtPlUX51Fr8EdjA1Z4KK0sXtZC4phoh?=
 =?us-ascii?Q?JABrVSg9uQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a28dd87-6f4f-4b26-67d3-08defd1c7c54
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 11:33:12.1780
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uYm2Fq7Ug/wXv8RHPbI4E6CMeaRd+lugECTO8BT7CVBM8mAQpy97yGItrMjMC0euekD/SIpnSbrI6p0P2AqGRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9598
X-purgate-ID: tlsNG-33051d/1787052798-74E874E9-32FE4DE7/0/0
X-purgate-type: clean
X-purgate-size: 3112

This series fixes sparse eSPI INTID handling and checks errors returned by
irq_set_type().

Patch 1 makes is_espi() a configuration-neutral architectural range
predicate. Configuration policy and debug checks for unsupported eSPIs are
now explicit at call sites.

Xen has IRQ descriptors for INTIDs below NR_IRQS and for eSPIs starting at
4096. It has no descriptors for INTIDs 1024 through 4095. Patch 2 checks
INTIDs in setup_irq() and irq_set_spi_type() before these functions look up
a descriptor. irq_set_spi_type() checks descriptor ranges because the GIC
line counts are not known yet. setup_irq() uses the line counts once they
are available.

Patch 3 fixes the vGIC allocation bitmap. Reserving an eSPI used a compact
bitmap index, but freeing it used the raw virtual INTID. This could write
past the bitmap and leave the eSPI reserved.

Patch 4, introduced in v2, checks errors from irq_set_type() in the GTDT,
MADT, SPCR, and FF-A paths. GTDT and MADT could keep a rejected timer or
maintenance INTID and later use it in a direct descriptor lookup. This
patch also fixes MISRA C Rule 17.7 violations.

Tested with:
- Arm64 debug builds with CONFIG_ACPI=y and CONFIG_FFA=y, both with and
  without CONFIG_GICV3_ESPI
- FVP Device Tree boot with 64 eSPIs; Linux dom0 started
- QEMU virt UEFI/ACPI boot to a dom0 initramfs shell; this covered the GTDT,
  GICv3 MADT, and PL011 SPCR paths

Changes in v3:
- Add a preparatory patch making is_espi() a pure range predicate and move
  configuration policy and debug checks to callers.
- Add the requested assertion before regular descriptor lookup.
- Avoid partial MADT and UART state updates after irq_set_type() failures.
- Apply cosmetic cleanups from review.

Changes in v2:
- Check descriptor ranges in irq_set_spi_type() and implemented GIC lines
  in setup_irq().
- Keep the is_espi() debug check when CONFIG_GICV3_ESPI is disabled.
- Remove a redundant CONFIG_GICV3_ESPI guard from the vGIC code.
- Add patch 3 to check irq_set_type() errors in the GTDT, MADT, SPCR, and
  FF-A paths.
- Target master instead of the 4.22 release.

v2: https://patchew.org/Xen/cover.1786385827.git.mykola._5Fkvach@epam.com/
v1: https://patchew.org/Xen/cover.1783671887.git.mykola._5Fkvach@epam.com/

Mykola Kvach (4):
  xen/arm: make is_espi() a pure range predicate
  xen/arm: validate IRQs before descriptor lookup
  xen/arm: vgic: free eSPIs using the bitmap index
  xen/arm: handle irq_set_type() failures

 xen/arch/arm/gic-v2.c          | 15 +++++++++------
 xen/arch/arm/gic-v3.c          | 15 +++++++++------
 xen/arch/arm/gic.c             |  5 ++++-
 xen/arch/arm/include/asm/irq.h | 11 -----------
 xen/arch/arm/irq.c             | 26 ++++++++++++++++++++++----
 xen/arch/arm/tee/ffa_notif.c   | 11 ++++++++++-
 xen/arch/arm/time.c            | 18 ++++++++++++++----
 xen/arch/arm/vgic.c            | 31 ++++++++++++++++++-------------
 xen/drivers/char/ns16550.c     |  8 ++++++--
 xen/drivers/char/pl011.c       |  4 +++-
 10 files changed, 95 insertions(+), 49 deletions(-)

-- 
2.43.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:33:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:33:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394001.1632819 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4G-0006l4-SE; Tue, 18 Aug 2026 11:33:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394001.1632819; Tue, 18 Aug 2026 11:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4G-0006kw-Ld; Tue, 18 Aug 2026 11:33:20 +0000
Received: by outflank-mailman (input) for mailman id 1394001;
 Tue, 18 Aug 2026 11:33:19 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwI4F-0006Vd-B4
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:33:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwI4E-00BTlp-Np
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:33:18 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442f4-2eae-0a2a0a5409dd-0a2a4503e17c-32
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:18 +0200
Received: from [40.107.130.130]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442fd-fae8-0a2a45030019-286b8282bd98-5
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:18 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by PAVPR03MB9598.eurprd03.prod.outlook.com (2603:10a6:102:301::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 11:33:16 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 11:33:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PmuUxKl4mAHx2fh1kbIG7whTmNtoBJgzrNLFSRevSfu6mA3s2GhXHkB6xH4axyquLq06R69hzyV8cdQas+HKFoOFzL++Hnb0wskQnwL9oJ5kD2rJ8yCLdCTsXZckFpH1Cx1sgBimYqeNmcNR5AGnV54N+opXRKTyyJKUXMhpvojiLGKNxf4sSVnFlgnTDuI8CmMCiPn/f0M3AVDK4gui2t5X7S/WHqAfd7DS6er3ybZZ8eAVnEP8hCUZXKxU43s0mcuIRNo5JJx6it/BImVmPoGFiXjvpgPgJepwopCvpV0P+t50fJaBXPHd4/4Rf/a1WWpT0acmRTSB8X+/mbyL+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=F3h0aDabB4S3N+q+n0dwzdXfsKs/jsW96yHUTuqm6Mk=;
 b=e7SxnYfW/bsU5HvTqX98o8MeNhq7dMwAitR48kpZ2s9cuJHaSqsZgC1XpRC3qvttU1IE+H7KuSe9Nl1o+AK0NSIfnb5BvZxBR2ZYDRsbwbJij8Dz1tn5DT+ngpDT5n8ps3mbHOgAB8Ydvypm4A1Z2VYviaKWgbIicC9DzHkr4VdZnkocivPEriQEidEXRboCRj6FGyUSGY3YuhSajUSU4G+428wXRD3gRISDBNQO73TMVtcEhsGAi6FxASngd/ATVI+20xoEXL5AqHimxscJsacEKKCAYa4LEJRjdHbJRJvG2qsjH99dh6Gvf+V4E7g+C6f5v6TdhdS8bcaiGo8Ejw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=F3h0aDabB4S3N+q+n0dwzdXfsKs/jsW96yHUTuqm6Mk=;
 b=vHpOKMJA8g2t81NJnmVrnt6jNZNFGX0hOQjTSTWVKqit8ERE7bhp5rrX0TN3LgXGFzKLpR+CGjpS6DYQQ+tAPfnazESOS4lJwNH4IMNAXSPJljjAfUBetnzuDffdYDzCm2T++d/EDsZvG+8XmsGUltbHyL2VX4wSAunssMVn5+Qgk7smSkGbfYu3K+/p4iUJOrzdLWqWuyYFaVn4KKRTNLDBjcHeWeRUALXU7zrTDowCBnKK7awzDflj+6M3FuN65Wrv6pcU35oPfnf/lQHjgkOnywYFJpQ702vK0pRDldFe86rHSL0WKLMYxaeh0OZuhGB+DiIiQiq3nb+/H3kdbQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v3 2/4] xen/arm: validate IRQs before descriptor lookup
Date: Tue, 18 Aug 2026 14:33:00 +0300
Message-ID: <355ff5a0aab671894a527ccb7b5999db6b168de3.1787050437.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787050437.git.mykola_kvach@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA1PEPF00005B92.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::63a) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PAVPR03MB9598:EE_
X-MS-Office365-Filtering-Correlation-Id: 0485857c-6228-4148-890d-08defd1c7ead
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|56012099006|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	Ux1Aeh6oeDy3SUHp1wziUsVtVbyFjXlAZ61JOX4V69qECUiPyaMBaZuv0EDhW90dZsFFyF9HarI30Z2bn79zma48/z+AbEfqrit7mO5mGNYEvEKicAUlpfJg3ws+gnKNJ9pCfRKBOPLrvfVoo0rI1ET+zNQPw2zIJsoCOYuS3BrNSVrBwOqqBYPQQQjzTHbIQ4Q6IXaYWXTGCD6UD6RaWw/+2K8ZuL3Kh9oL28QC/4vjbtMA1RXvIDgPlpd53yn8ArS6Vps0JhuGfZz2pWnkSZYDU8zA78ub5XW0eVi6cQXviEgsXO8M/lY7NxgSJpIqtOa7rh0FuB4nuU20DJ3qGyEDBbYw+dVCLuAH+YJnuCwGsHYLaZfUSxkSMRFUVnVi3p7WV3014jbyDQ415Kb+B5WzQzNPR9paH5xN+kyLAN+YPRSLnUADzZuv6QO9nxSIzgZYhkhixCH228Xo6zn7wM01j/U/BJMD4AK/XfPgaDQN1Ck/xi1N95ZgvUm/+9tEgYzbQ3+NKCaYoozpY/vxCcY6m2IU/xFX+gvjZ84o5+qwCPJfyJl9/6sEleZQbDiBMvjW5Ctf8xe/jWFQ0J5O79OJQVC69Fz8lWW62w+S3oitRMX3c4GJPKA7ndtwhHK+UW+RZxlsE69wyNPQvGdiecxVfXIVwEFAhZTeKvAuqKo=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?pnr95fPRlfcRG7xmT5WHoMYgtsDkwnk0MzoKRWibp+oYrJ8qI4qQEB3mj+ka?=
 =?us-ascii?Q?EWS4KZFf4aivM1WiL8YwOIMZVj7Xe43ic7xb8vmEnmhv+VeQ5ctjacR7m2Jl?=
 =?us-ascii?Q?icEqv+UjHi5c0p89Rg9G8n/6l9vCMNRicOBWopSBVZxlpDBPVYeTm/BPmaXZ?=
 =?us-ascii?Q?6NbOIiv7k6f+s3qWPFUIvOegAhHJvvwpA7fCtlVp8nCAhOywHR65uv+DbwC3?=
 =?us-ascii?Q?x/XKF0OUJvI4JM9J/tu0lWcM6DsdlasiMDcebldxzpKsiTdGn5dwrB+9eKSw?=
 =?us-ascii?Q?ZLTC7NkWifWKSGuqN9T6ZWRsL5eljIIlxIgIhJJRUw7aO3lfov2ILIfxN6bi?=
 =?us-ascii?Q?uvljWEfcCT5rYx46W1+gcJL+z1gHCJ3ZeM0kKSmY9DJO8Z1LN6KeVSi2ueqa?=
 =?us-ascii?Q?wHhckIRpTEAw6A+vMUCZPr/iTUWnQZ05wF271hDWH74G3JginHRH9mVz63VD?=
 =?us-ascii?Q?Su/o1C/LhrCIX0YOyYYkkfDp8srUYG4pX+228sqRWpM5JqadenlTWUaRygoU?=
 =?us-ascii?Q?IQzqkmEyMSyMgsNED2otLQr4ZzFhpgvNrDpyrPA7uJgc3JRRYOV1bj4CVISg?=
 =?us-ascii?Q?txab/ZUJPm8QwYKEty8gJ2BNkoF9/cruJvE/AgwclXzf+dq5hjqUGt9J/UcO?=
 =?us-ascii?Q?8/Ld/Ed7WTzwNlAkzYgjq9hHFZPH38hRuC1ujd/qMwArRHNagpXdx0enhvp3?=
 =?us-ascii?Q?aJOjX+dsMHNb6igDIlMXBGSL3IRe77qsWg4fnmWOHzGS3D/emVqpYVPYToNc?=
 =?us-ascii?Q?JBF7dmdT7xl0hLz3UPNbkVb/AOGilJQPR7q/z4zq5orssrTDSF8RWub/s9pN?=
 =?us-ascii?Q?ndoBPfemozUfPSxJgcmhOyZ6Mkntkp+v+TGc2UYt8tKNjCtJhOouQNLdRQJ+?=
 =?us-ascii?Q?A+b7W9gWf5hD/9ePl2qAyzRJbfXDoz45QFVO9GSRnFXHd/qHUWFMJfiN+PAi?=
 =?us-ascii?Q?sEHLzgupFXKp9WeZtLvJnsfRNe5Ych04ZC//hO6FG0iCaTcj+w/D1ONeaDO3?=
 =?us-ascii?Q?6m525WaGO6BrPZViEMxzzFP+gum/sjOCDJXRJvu4+mh7c0d8cyVZR3M/6mxU?=
 =?us-ascii?Q?Gm8eaXbFE3i6E78MXfScq7MDpXI6CzPK17WD7Ie9jGEiuFbBPyFHT/uVaNEG?=
 =?us-ascii?Q?w4jOhmRGeO+PDVDU7ajmQeytBqocTg16U5SbJvJvUXH9tDdzKFHEbQ7HqjrJ?=
 =?us-ascii?Q?kjKGO00XHpQ3RoSVojgFlK9NqCALwBbxFr7Dn5D8Ocii/78uezT7mrvdpoZY?=
 =?us-ascii?Q?F9N4EGKINvXxQctvTNg5+NLxKfJzHhZ0f4lvOA7h2G+A+z5GDx9JsuKZJrrD?=
 =?us-ascii?Q?DlWSibgSYh42pBdjbj8r2b5y3QdiMubXjIogytYZ3IeS+EFYDyClUAWSxEcV?=
 =?us-ascii?Q?MOqYJ2eBFuvd3zpaJlaLMmKyQb3F0t9SfIdEysRZLbVfSpLmnI2B2FkDkc4y?=
 =?us-ascii?Q?GbHun/dTqAABEUsQuU+K9ww6xEgU0p5/aYeqmqMIE2g003cuUMSDF0kWbE9+?=
 =?us-ascii?Q?GRkEIVoJXv6Be73dwP9shY22b0QT3NRzJ/AARzmUxjgui2mrc8Jl8mcbKlPj?=
 =?us-ascii?Q?zs+4BwhGCpGpxFCYfK8nmZ+YYvtyRvupO7YBsxabBjexIVov2nm2tbvb5Vrl?=
 =?us-ascii?Q?ITWmt2RxipsI0cGyRvReq1dwfIWqOqQkxccOQDi2tKLva6Hybb6/rqbh9iK9?=
 =?us-ascii?Q?Z+XRK5ie9TA5yRrfhYS+F/eFILyXscZR0rP4aEUIl7pPLlikOGAupUPiGqVk?=
 =?us-ascii?Q?6cXvzvohIQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0485857c-6228-4148-890d-08defd1c7ead
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 11:33:16.1089
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: evTp44mnkgcd3k46kp8Fd7634sLwB7jq3AgWIHcMUycuq2keEurFnKkQM1WXxVVcS+JhwWtTj7Clqfhsro+6FA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9598
X-purgate-ID: tlsNG-33051d/1787052798-772F54E9-C83F8BB5/0/0
X-purgate-type: clean
X-purgate-size: 3551

GICv3 eSPI support makes nr_irqs span the architectural INTID namespace
through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[]
and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs.
INTIDs 1024 through 4095 have no backing descriptors.

Validation based only on nr_irqs accepts an INTID in this gap.
__irq_to_desc() then indexes beyond irq_desc[], and callers may lock or
update unrelated Xen memory.

Reject INTIDs that the GIC reports as unimplemented in setup_irq() before
looking up a descriptor. irq_set_spi_type() can run before the implemented
GIC line counts are available, so validate descriptor-backed ranges there
before looking up a descriptor.

Assert the regular descriptor bound in __irq_to_desc() so direct callers
cannot silently index the sparse gap in debug builds.

Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v3:
- Add the requested bound assertion and retain the SPI-only comment.

Changes in v2:
- Validate descriptor-backed ranges in irq_set_spi_type().
- Validate implemented GIC lines in setup_irq().
- Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled.
---
 xen/arch/arm/irq.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 73e58a5108..bf14180f97 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ?
                                         (ESPI_MAX_INTID + 1) :
                                         NR_IRQS;
 
+static bool irq_has_desc(unsigned int irq)
+{
+    return irq < NR_IRQS ||
+           (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq));
+}
+
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
 
@@ -76,7 +82,6 @@ static int __init init_espi_data(void)
     return 0;
 }
 #else
-
 static int __init init_espi_data(void)
 {
     return 0;
@@ -95,6 +100,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
         return espi_to_desc(irq);
 #endif
 
+    ASSERT(irq < NR_IRQS);
+
     return &irq_desc[irq-NR_LOCAL_IRQS];
 }
 
@@ -416,6 +423,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new)
     struct irq_desc *desc;
     bool disabled;
 
+    if ( !gic_is_valid_line(irq) )
+        return -EINVAL;
+
     desc = irq_to_desc(irq);
 
     spin_lock_irqsave(&desc->lock, flags);
@@ -647,13 +657,21 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new)
 int irq_set_spi_type(unsigned int spi, unsigned int type)
 {
     unsigned long flags;
-    struct irq_desc *desc = irq_to_desc(spi);
+    struct irq_desc *desc;
     int ret = -EBUSY;
 
-    /* This function should not be used for other than SPIs */
-    if ( spi < NR_LOCAL_IRQS )
+    /*
+     * This function should not be used for other than SPIs.
+     *
+     * The implemented GIC line counts are not available when early
+     * callers configure IRQ types. Check descriptor storage here; setup_irq()
+     * validates the implemented line before the interrupt is used.
+     */
+    if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) )
         return -EINVAL;
 
+    desc = irq_to_desc(spi);
+
     spin_lock_irqsave(&desc->lock, flags);
 
     if ( !irq_validate_new_type(desc->arch.type, type) )
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394002.1632831 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4J-0007A5-77; Tue, 18 Aug 2026 11:33:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394002.1632831; Tue, 18 Aug 2026 11:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4J-00079s-4L; Tue, 18 Aug 2026 11:33:23 +0000
Received: by outflank-mailman (input) for mailman id 1394002;
 Tue, 18 Aug 2026 11:33:21 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwI4H-0006me-1C
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:33:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwI4G-0061ee-C5
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:33:20 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442f4-bab6-0a2a0a5309dd-0a2a4505b038-40
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:20 +0200
Received: from [52.101.72.140]
 (helo=AM0PR02CU008.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442ff-4cb1-0a2a45050019-3465488c380a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:19 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by PAVPR03MB9598.eurprd03.prod.outlook.com (2603:10a6:102:301::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 11:33:17 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 11:33:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tbclOfyK5EuhcYz/OaT4WR/LYKGNuslTGb8fQ4fYFBIlmd3Nt24odPZabanRmnigCYJI79rQdH8fBRZ1XXLZCWHx/n9wMrDdMTnw2TGODKyV4r5CR8dkTpnrkirWdwNnHIsiqds4GdI/RJX+KJvqQJFMlTtwQqcjWBmezZ+wTlgLCo8QYsHFGT7OLK0sRbnnLcvHaqAOtBbEJCTWYtuYd6gmj6LULvs4gCtJvfqwF3avRXvs8y0XCRXq0I2zLdHdWCOpHl/tzMGe7Hk3KSCFEcQjo4dkTWfdXQR0JKrAQYf1Fbhqz8Yul9Vf5kXS+8QTi+SosfIdgbElc9dsMhNitA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2xUZUPUEChfEb02JjA/GupRaagI2/1BMV5nqyehtpb4=;
 b=SgP16vqrgoHEGYIEZlkT1usXOJxK1rU5sIpuZFG5IxZdD5TS7193eO5rafc1eghnQ9Xg1ON0dOcGb/khp8AVyJzybi+xUxFFERxvZFrg5DAUpKjGrOYM9TUfFF++UHm15M/KIqmcpwTeRJg5G8788rfoce82eVze/HDS2lzGyiy5u+/j2sv4qkgnB6jZPO5nVBmAkofbIATx5XKPCp2SWKfIr/xGcd/UwZDkCeF3P2pDPn/Rp2IivYScHJd5PmnAa/MWj22eW+rVoPRTY/X4LpcMD1DTG24ubEPX+lgQfhpQZjCP9Z0DccZ1LH+9FyFKjPJTmZXtk9eYLr/o1MT0Ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2xUZUPUEChfEb02JjA/GupRaagI2/1BMV5nqyehtpb4=;
 b=CVQ2jr6T1RGvXXBwY9yl8sy4R7Zyi6TWIOFg4MbsKOXVeJXb7ZovKhxuXmWs28RSFd4gPTlteBLfOFXvGqkO2l3sgeTfkUKMRRtHMeV1t0XA0UuDTvn6836VBhwRMFZvfQK/u01E35wiUt4klTF2ATJdUw//rEPp9aH37DWd8qpGGZidH/R7y86Nexqo9NFWWnPrurdEMNuw9oVLoLR1FVIRoWlLoaOQ+X8KIB520nX+G5hhzPc3aA0El6FCPn5TAGS8fB0Eea/zirKV6xMMt9XtKIvUT70eQaLVtopqhQvmxXySSr92zML2++HGmCG4tFepPyBrbe1QxQjsS4XEhg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v3 3/4] xen/arm: vgic: free eSPIs using the bitmap index
Date: Tue, 18 Aug 2026 14:33:01 +0300
Message-ID: <d359777c9fe4c4e1a53b93dea14e36adc4f39e00.1787050437.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787050437.git.mykola_kvach@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA1PEPF00005B92.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::63a) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PAVPR03MB9598:EE_
X-MS-Office365-Filtering-Correlation-Id: 24d8c10c-5afa-45c9-9ef3-08defd1c7f95
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|56012099006|6133799003|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	1guIF8JLqgK5bnhLQaCJ+bpmn/R9UB9Eqj6ZvhMWevg2ARY2BCWk7UPIWQb33HcFMfJsgQT1vVDuzbeFjF8FhuqwUHkA8+uFCElE/WOFL42ftFaXiHzYaRGIdBetdtE8c057hd6lAHdJGRdN7d+KJTDc/SiNl3fXDuRdInvopjxX/TdI+7ZSlCWjqWTCDvrrMG+kefRDDzVfjxmMlevRS2dyKe8ZWnyzCmENVi13AgW7j3mdp4eMN38JizktSKv88FeCM/XyS5oC1XBmIYgBAfl8JW1hLMnAYQjR8XCZ4al4oMCBncF7EqScfeKNrLrjhfG6kdzWy03iTf6WEwR4uVAaidZ/JeW1/BjBdpR42Rw3Ek1FIyg6x3mtMWJo1MKU/vVBb1VRlb/fU+2zuD8AVh+pEHbv7rDXrPkAgYvqCswqJ8YLFQHBfE9OqkUC9pr9r0pj4iDhUVdtakwYfIjEtHpto/pJJ7JwdgzzeHt9xUybnObGgunFQNU1zfuH2Dk35UVCeFKOX4h8sl3EVmlMRcUiHGgAE6xYVg1yrPx8gJJmnM4FBB87xLgV25FTQrxty+MrXfH/Or2NVa28qlWmc4vFq3KljFEGuTG8NfCr0DIbjr9kU1rGy0XWLxIJjOgOP2Q0grk2iIPbRuqH28SbSRP0tD8HE0pka/o6O1QQjO4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(10067099003)(56012099006)(6133799003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?+QUkgr5pSuwR/HNuZMqg5zSnc7P3bRmoR6LE1VJMPKz07KkdIsZyIFytEYjM?=
 =?us-ascii?Q?luDWQj3JH/5qEjmPGu4602K5JzpEnqS2349tdfqEgmL7g1JMnIGtyc25cesA?=
 =?us-ascii?Q?Tw4hVJsp+Au01uP7h/Fm68b3xZNBtocHbqeZSSgC6MOzd1xGmNEnwvKDUcOL?=
 =?us-ascii?Q?7Nb+nE/5itOCQf+cxYyRcz9LHbgcD1/e9CBBsHFNmiYW9OjEW9olQ8hLDSSF?=
 =?us-ascii?Q?yWXPXhOPOsT5pOYbt6mM7MvcL527CR3ZRiPlDHGxcuhFz/vqdvO0J+A644X4?=
 =?us-ascii?Q?HQ83hQIyvODB5D/RI0l1Rbs1uXBZIQh7UvFhFnJSP9UkOz2znayqsW20JMz9?=
 =?us-ascii?Q?1nf4TgwhIFBvsJYJUQqsooGq4hcQ0kc21ek3Bx/U85JLEpQD3zhydW4L1Hyh?=
 =?us-ascii?Q?tj69PmPqH048tzS5BZ29MMzSX361A/q/G3JAKyjEXVLK5QxTNM/2iW3x73hn?=
 =?us-ascii?Q?daOm+wlGIZ1OyrtQlQPK2G1ED3L0b79RkE7nxeZvuJ+0Ln5zCd82ZZGcAHJC?=
 =?us-ascii?Q?xUGpKDKBenNdFK7tVbx/tUYI1LoC/4dBDH0Fc4Cqk+gXIJ50Io17iNPSKky2?=
 =?us-ascii?Q?4pSgnQlsTImxX6zUtkPFSDKZC9COv0q0Ra67N7Wu9le0HpaVuSiyYfaKJjOY?=
 =?us-ascii?Q?pqU2SOZd+9WKaoDzSi6ATrSX1AXEUUHp159BD1WYPNYxomqBgIkKXvKQtzYM?=
 =?us-ascii?Q?aX63oaQ9AH3UicJQmgFyuchWN+I7mWcH/ZOmaMdoBvNODcoazRP6i68T9kZQ?=
 =?us-ascii?Q?O3q8fBTR5L/6BtDJ/dmttKI/QRWUaxmwsfD/17fTgjMxotwmH9pL0UyWUKCb?=
 =?us-ascii?Q?LjAX0Z75l3goS0bIJPRg1L6KXXsgMaD0wijL+gP74ay5kPyqEznorhwg6fm7?=
 =?us-ascii?Q?SD+q9grR6w2NCozn5K/rrEN+lx8PO/mHgR6jzBeneoXcnRihursuYcmVKrjT?=
 =?us-ascii?Q?kc2XSyDHgXS4iYwlnmTUYkfB4Sb+HZrd226JuZ6NK/CmV+FwoIKDCAb+SGNh?=
 =?us-ascii?Q?W3cgEhLgg5HfeOvP2XouPmsYP/ZNVSQpfmFsKDcxEaLdhle/Y3xuCOl0NYsu?=
 =?us-ascii?Q?5lEzRLFVMF1QrxjEu4OArWo8dF4ihYzbLK3jqe2p0IVF2bDmTf2l+KaGa2nK?=
 =?us-ascii?Q?NEPYDfXJB6KyusOfkpxPlsh/rsTqQCDber6KpiwRvGmGI5Z4LROLBn9l84B9?=
 =?us-ascii?Q?ss9ykXb+CwqUYVpEJF35dL/luetTp5eWGUjFCr/1xrY3lGDex9i+bKuoHtTT?=
 =?us-ascii?Q?ZTijhdUbaiDJIVtEMeLw0R+eCUpmo1pvNdYXtdnkoGovQopIg/QVbIHpFx/K?=
 =?us-ascii?Q?3zw1vDMjt7B/bxJE6OYNab48MJee+Lx0KNPboXsSEZOEg8daa7JmGabk8oJv?=
 =?us-ascii?Q?fc4+olTeqjP5emcLCGL1NUTG1/2yP6xNAvjmVr44kG9JVDRYmx+pBQH8/+et?=
 =?us-ascii?Q?Z2fj2xsIf7htUuSu1B45NGypq1Qu315mA7tXlhxfr9iKCWTTFyOMBoLignHY?=
 =?us-ascii?Q?zM1Jjjn4cVwjhaJpMUNTZQoRbkPehJ14X/NZt+ZEK6g/JIPi6vpdwbVzgHYl?=
 =?us-ascii?Q?p5WXZzOu3y2Ci1QqLAytYxMmJP7deU+6KLnFLLpBTs44rhwHkjZyu7kRN4vh?=
 =?us-ascii?Q?Cf6cif8fHlPrX5OWEBW5o+B4Dsn8QanmKMQEkFX/OXoXqwFHWPEuuif/a5C4?=
 =?us-ascii?Q?VfKxAf808Ft/X9gCQqPfirpd0o0QzQFltHONUvfFCei5CygUwY2oHDYneWXq?=
 =?us-ascii?Q?jkqZV3ycpg=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 24d8c10c-5afa-45c9-9ef3-08defd1c7f95
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 11:33:17.6083
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: zrXAvHs5QcHtM28hbHunu+h+Zjz1Ea6kkbIiDIOfJ/fqkAReipDzgS0WWykn+b538Ho2Rb6d0SDDcteMEB/xeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9598
X-purgate-ID: tlsNG-c201ff/1787052799-F76BD2A1-539AE163/0/0
X-purgate-type: clean
X-purgate-size: 2800

The allocated_irqs bitmap in the existing vGIC implementation stores eSPI
allocation bits immediately after the regular vIRQ bits.
vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index,
but vgic_free_virq() used the raw INTID.

Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit.
This writes beyond allocated_irqs and leaves the intended eSPI bit set.
Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind,
and during vPL011 teardown.

Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving
and freeing vIRQs. Validate a vIRQ before clearing its allocation bit.

Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v3:
- Adapt virq_to_idx() to the configuration-neutral is_espi() helper.

Changes in v2:
- Call is_espi() without a configuration guard.
---
 xen/arch/arm/vgic.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e14123a30a..e541348a5c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -33,6 +33,16 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx)
     return idx;
 }
 
+static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq)
+{
+    ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq));
+
+    if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) )
+        return espi_intid_to_idx(virq) + vgic_num_irqs(d);
+
+    return virq;
+}
+
 bool vgic_is_valid_line(struct domain *d, unsigned int virq)
 {
 #ifdef CONFIG_GICV3_ESPI
@@ -849,19 +859,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
 
 bool vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
-    unsigned int idx = virq;
-
     if ( !vgic_is_valid_line(d, virq) )
         return false;
 
-    if ( is_espi(virq) )
-    {
-        unsigned int num_regular_irqs = vgic_num_irqs(d);
-
-        idx = espi_intid_to_idx(virq) + num_regular_irqs;
-    }
-
-    return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs);
+    return !test_and_set_bit(virq_to_idx(d, virq),
+                             d->arch.vgic.allocated_irqs);
 }
 
 int vgic_allocate_virq(struct domain *d, bool spi)
@@ -898,7 +900,10 @@ int vgic_allocate_virq(struct domain *d, bool spi)
 
 void vgic_free_virq(struct domain *d, unsigned int virq)
 {
-    clear_bit(virq, d->arch.vgic.allocated_irqs);
+    if ( !vgic_is_valid_line(d, virq) )
+        return;
+
+    clear_bit(virq_to_idx(d, virq), d->arch.vgic.allocated_irqs);
 }
 
 unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:33:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:33:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394003.1632840 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4K-0007OM-EP; Tue, 18 Aug 2026 11:33:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394003.1632840; Tue, 18 Aug 2026 11:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwI4K-0007OB-BW; Tue, 18 Aug 2026 11:33:24 +0000
Received: by outflank-mailman (input) for mailman id 1394003;
 Tue, 18 Aug 2026 11:33:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wwI4I-00078R-8x
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:33:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwI4H-006e0V-Lc
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:33:21 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a8442e3-e002-0a2a0a5209dd-0a2a45048bae-48
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:21 +0200
Received: from [52.101.72.117]
 (helo=AM0PR02CU008.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a844301-b57f-0a2a45040019-34654875529a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:33:21 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by PAVPR03MB9598.eurprd03.prod.outlook.com (2603:10a6:102:301::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 11:33:19 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0315.012; Tue, 18 Aug 2026
 11:33:19 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gIxIyrQaZPkg/pZz+bOTtsJxhhik1Wfs6H8R2Yr52JVjobIsWFQz3jhRuv/aeJM7N8XIdJjmIWEhS2o1QUQYoqxlF7WZyzFmYtk6GQcsgl7w6C//K3F3EEMSWzFPeq0/ZY/2SFsQDs2B7rdL2bxCcVtFiW884VAGnyo02V7c0Vu05XxxMXck2+oxkxMuXmCFA2UGujrK/MdAcF3NsIhti1pPAwBTtNwSexfKASBcakLISTK+7RtS9XeWYT2SXeJzKsXIK+FO+CY/eEfABcJbN1NAFTitQB/gr1hYv4/zqXnzpR8cP2HZE+9G/YQ/Mx3AOI9YnyQkJNamUIJqmSCNKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7HDe1xkWtdxGmtk4I8gFdOwYDocPhKfwfAK1ssSxjYs=;
 b=l0mG1Izx9VSvs7qkukMGnyAerQeTkW7JUrr1enJuGcI+CpUDESaCX1Qns0G/P+MlcwHtkCmhSBfGRb0dN9ViP/EVbei/ND7PS1cCnCSYHZP7LbI1xjRvgphiHhBWPz4Q3UjUDDwKCLAYANgZ8v1AMAs/JNtWVRPVpZYA2xaHw0Z2MAcm+FlzuqnWtUmzmvJrrDVoqfb6MWazNhVzOFFYYQkjPpW3jXkccn9pNW13b2AqQjpUrJLpot1fWQBdSXjyU7ewS/UYWy5E+z3enYuUKnsYS/3tMIWtnQvqLpT8H2Cr3tZI2zFZZy87DCVUJugeOOUEHQnZTUnynZm6MnInmA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7HDe1xkWtdxGmtk4I8gFdOwYDocPhKfwfAK1ssSxjYs=;
 b=rffEqluXHrkD8BkWH/gn6XQw3mwFk2cI1V8Nouu83YL+tbeqJL9Hdx8ouiatv0hpelD/Y9FhCQPTCvGT3QV6ub7Sc2iw1S3dnmYnCEPhQtkBP+Sm8MKglyOtZYSJTZAtV1UQccT2YlDU/eojcxnO/poZFllkwsgPYjSLzkdUCNcATJfNH9cWmTlzOwloB7wtlqJY6nugZopGsS95xZLmsMhdII1GlLP3pRtls7YUTQ/pEbcfStUPSc+uRDLNQoYBNGyahHTG1zVK1VRc79JP3WzF6CVF1PHq2FhwDSnnBpG0dcFNhyS4HV5be+wDCNtzRt6oUSIPzml6RYSHswJMeg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jens Wiklander <jenswi@kernel.org>
Subject: [PATCH v3 4/4] xen/arm: handle irq_set_type() failures
Date: Tue, 18 Aug 2026 14:33:02 +0300
Message-ID: <a960bc4917d4673cd1920cada2cfdb7eb7475f23.1787050437.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787050437.git.mykola_kvach@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA1PEPF00005B92.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d8::63a) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PAVPR03MB9598:EE_
X-MS-Office365-Filtering-Correlation-Id: 04e34735-1d56-47f5-1049-08defd1c80a3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|7416014|376014|10067099003|56012099006|6133799003|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	1ly0t2Wp8MzggSIWNxSQGDA0WLshz1OdxXdSgSVrON0Ma0SNeK0cybjLwEkYOQ3As+NimmrtS4SV7dGMLwjn0guWum2N5pOIjJxnTDnflmLJoSrkhWxKF1kykCf3kfBSja3Nn9+xSH39ubQIbvlN5bP6fJfgwKIGAYVjjLINW32oEjD5O9j7+/b3B43Uc2WpWadRrw1Clo7iEL9b+aR6St4Acn2n6vt8nZanDJ9FoSToUvZHcYGrihzdS2G0GwLF+7BZAUI7BA7kNoRObMCQNvBlyn5xlwirnQ+4geMdzItgieDFe4KrYVe6/r5aOdBS26HOU5qVy6oVC03HHcM5w/2Ba/ojL+h4cfu2h3ucVQjEV9ZmzJju/wzNsviVUzZ3qqA1UDSJdHJNQriIKEeHjZOqbBbZuUgbv4CjvqYPJjiJSfu0TijwYygQpULE+WmVmHgpdW8kUueNj5tOtVOpig+F6rIF/9Fhfm67Zm1uMTShQSTJfRV9GM4yDfdUTxSNoIS1zuKE1ehI8x+32HMx57lqCWzhQV+hpDr7tKeOTHjgnAyfIxBIurULDc0PMTCGwxCUNbahqCSftEQ9Mupq/xP6zdApdnVyTu0Qoa6hQi6HCV+uU30mTkT5iceZqtzE01CLgWtXeY8bkNzbsClgvnNWxDsltZESrY1S20saclI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(7416014)(376014)(10067099003)(56012099006)(6133799003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Ni5Kc5HWi0tZN2w3+KA0w8ocghgF0iegYt5hszSvRsPoj7N6N+4bsOCqsEiZ?=
 =?us-ascii?Q?J4AusptUgCRg30ucuA4hjz4ObPeAbAMHIAOq5nfbkvommZRN41+PQ+F5baTs?=
 =?us-ascii?Q?HAMynBvAeQF7+SgQpT+Cq4xpRbhTBbxUkGZi9n1+Dq2hF8clMm6GBqu1Nd3B?=
 =?us-ascii?Q?XQQMHgv9/1m7kTFyhyBQIitwkoOwx4UjjBCx9oNFMDFxrN0Ld6EdwqKCZ1UF?=
 =?us-ascii?Q?Tduzec5NYpRY/Q0yZzYgVq9G3W0RmtgMa1QB+FHVVtw34AsXhGxc1hj9zEsx?=
 =?us-ascii?Q?Apt9sygDtkAvCOnpACZTjnS1jmEG+sWpXw/h+GxyfNIUlt359fHAnMMzWt9G?=
 =?us-ascii?Q?MQwvjTl3yNplLfeaSnC8fSFd4h4VV0PFwy2Od9CtgFuUqwOm8jsMKvZsTnOK?=
 =?us-ascii?Q?ublVLXzSL3moNSdWf2cH0RFr+R23WgkTbjvgePdbJzTkVxrg489+CkRfmOvv?=
 =?us-ascii?Q?AXKmwOm1kETSkM+9wj6+Y0+vBd/bApSVaFrWAem30G1tOHle2uHsBi18+a34?=
 =?us-ascii?Q?Ewba8y6rNdU9v1gVIFNgggQkFNXR8UgNYla3axwDOSmFdftavVib9tF1iq0C?=
 =?us-ascii?Q?4j5MODf/MgT+/UEmOWpJJI5gWZKRhryX9IT6X3beSPC65c9JaIQfzEi2Np42?=
 =?us-ascii?Q?s3rICSFVvOIlnVQ5L0PORcM4dYyZA8887xnV0/Foqse6ZGx4OF1NF8PGqd8C?=
 =?us-ascii?Q?zdWPdvcIQ1SuEB537ezTiD+1wSXhP6ix7ZzjWgzxeKp3cdnHxf1Dsm52bXuJ?=
 =?us-ascii?Q?QsUumsvW7OZcpgqGD6OVDAN3sg7VMnVo0p4QxM7z0UYUVj7qfPn+f4pY8Tdr?=
 =?us-ascii?Q?FpPOER+jPeF7GTnxD2K6Fa0tSPfZrMSbe8PE6HGEu19Kt6xL61gUpRWuNpna?=
 =?us-ascii?Q?xuJ4eJ/DbDSxoMqEUXEWlnXgzr5KdboN4TaJnnV8vVKNyoJJ8b/vtI/rQHrr?=
 =?us-ascii?Q?2xIEAy9Y5RA0MsOrZpaLIPl1XeKv+jIWoWAeJc773nNxDWYSNbhdJYqmCAmI?=
 =?us-ascii?Q?XoDEe3yTxRBGXC1/pL57kxQClEwQ1q2nfeaPZOLeMnxLBDrG+cqEeRFXmxp/?=
 =?us-ascii?Q?+H/Sh7XaOyEy9XJfuRpmGEnrEXCBOWAti0KymKXO3cIucBquU5ilJt0PEY4L?=
 =?us-ascii?Q?4E+677OqbecvmD2tjOTWDxmk4VzwgNhVyzeUj/0GyKpZrztMazrest52lL/X?=
 =?us-ascii?Q?TMnzoivf6qQ4Fl8k3VP/GYkq1wOSjDIRzMHGCiPs20+TIGjDxinxlTlhIue7?=
 =?us-ascii?Q?o+vmyPTAgaIKmBXFjm/xv2UsyRKZQApmtKt64EviRzhLaZbcx9Gw5h84hR/M?=
 =?us-ascii?Q?VAM2ges1fTbXzDOzFZJcUi55k/Sd0uEBHYYKRdY1FSL5t2DOGftHgiRNNHPn?=
 =?us-ascii?Q?uR7G/c4N36Vf/8hLy2aPARCPhLQrWx41dK5E5OCZj2g1gJZva53AU4ipS1ml?=
 =?us-ascii?Q?EihaTZObYUglSS0UQrj61GXfsTCWaQWbdDS6CtRkrBjtVVxjp/KcXbZd7/ue?=
 =?us-ascii?Q?pP7gtBJUHRDcy0kNcL4rCns/0PROwdaxOT1ck4oYZPv5NbyUcuUbf+Iondwc?=
 =?us-ascii?Q?0lxC3/FmpK+CsO2XCj8/I858W2c4tUgUyf4EsVhGH2uQ8Kg7mClSbBhIdIQE?=
 =?us-ascii?Q?4y674+RRkHV8ZzQY7rTezuEtq6NwNWsPoc05tyb2ySixw1KheaePWF5qbeP8?=
 =?us-ascii?Q?uWhBiUPXj7NtNo+aQp/pPSw32IXBje5J955eAPUac+G8Zf+ZCDlYWIgrsHs7?=
 =?us-ascii?Q?kpiNf2NArA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 04e34735-1d56-47f5-1049-08defd1c80a3
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 11:33:19.3671
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 05I/PAgTfSHYaUFLsSs2nZEH0SOvgMUSx6T2pJsTiKpvRbrwlEXDIp6AX+jI6jmB5ZO+Nt7fBeV7/KQFMrEntw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9598
X-purgate-ID: tlsNG-ebf023/1787052801-532CCB50-344BEABA/0/0
X-purgate-type: clean
X-purgate-size: 8017

Several Arm firmware initialization paths discard irq_set_type()'s return
value, violating MISRA C Rule 17.7. If trigger configuration fails,
initialization continues with an IRQ that was not configured as requested.

GTDT and MADT retain rejected timer and maintenance INTIDs.
check_timer_irq_cfg() and release_irq() later perform unconditional
descriptor lookups on those values. Xen has no backing descriptors for
INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds
access.

Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer
INTIDs only after successful trigger configuration, make GTDT parsing
failure fatal, and stop UART or notification setup when trigger
configuration fails.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v3:
- Avoid partial state updates and simplify maintenance IRQ setup.

Changes in v2:
- New patch.
---
 xen/arch/arm/gic-v2.c        | 15 +++++++++------
 xen/arch/arm/gic-v3.c        | 15 +++++++++------
 xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++-
 xen/arch/arm/time.c          | 18 ++++++++++++++----
 xen/drivers/char/ns16550.c   |  8 ++++++--
 xen/drivers/char/pl011.c     |  4 +++-
 6 files changed, 51 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 43a379fdda..a24d387e7d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1166,17 +1166,20 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
     /* Read from APIC table and fill up the GIC variables */
     if ( cpu_base_assigned == 0 )
     {
+        int rc;
+
+        rc = irq_set_type(processor->vgic_interrupt,
+                          processor->flags & ACPI_MADT_VGIC_IRQ_MODE ?
+                          IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK);
+
+        if ( rc )
+            return rc;
+
         cbase = processor->base_address;
         csize = SZ_8K;
         hbase = processor->gich_base_address;
         vbase = processor->gicv_base_address;
         gicv2_info.maintenance_irq = processor->vgic_interrupt;
-
-        if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
-            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
-        else
-            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
-
         cpu_base_assigned = 1;
     }
     else
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index acdac22953..b32a9b5009 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1743,15 +1743,18 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
     /* Read from APIC table and fill up the GIC variables */
     if ( !cpu_base_assigned )
     {
+        int rc;
+
+        rc = irq_set_type(processor->vgic_interrupt,
+                          processor->flags & ACPI_MADT_VGIC_IRQ_MODE ?
+                          IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK);
+
+        if ( rc )
+            return rc;
+
         cbase = processor->base_address;
         vbase = processor->gicv_base_address;
         gicv3_info.maintenance_irq = processor->vgic_interrupt;
-
-        if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
-            irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
-        else
-            irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
-
         cpu_base_assigned = 1;
     }
     else
diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
index 186e726412..d08d0a3366 100644
--- a/xen/arch/arm/tee/ffa_notif.c
+++ b/xen/arch/arm/tee/ffa_notif.c
@@ -407,7 +407,16 @@ void ffa_notif_init(void)
         irq = resp.a2;
         notif_sri_irq = irq;
         if ( irq >= NR_GIC_SGI )
-            irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
+        {
+            ret = irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
+            if ( ret )
+            {
+                printk(XENLOG_ERR
+                       "ffa: irq_set_type irq %u failed: error %d\n",
+                       irq, ret);
+                return;
+            }
+        }
         ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
         if ( ret )
         {
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 6955b2788f..39b5eabe7c 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -60,20 +60,27 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header)
 {
     u32 irq_type;
     struct acpi_table_gtdt *gtdt;
+    int rc;
 
     gtdt = container_of(header, struct acpi_table_gtdt, header);
 
     /* Initialize all the generic timer IRQ variable from GTDT table */
     irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el1_flags);
-    irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
+    rc = irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
+    if ( rc )
+        return rc;
     timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
 
     irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags);
-    irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
+    rc = irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
+    if ( rc )
+        return rc;
     timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
 
     irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el2_flags);
-    irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
+    rc = irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
+    if ( rc )
+        return rc;
     timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
 
     return 0;
@@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header)
 
 static void __init preinit_acpi_xen_time(void)
 {
-    acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+    int rc = acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+
+    if ( rc )
+        panic("Timer: Failed to configure interrupts from GTDT: %d\n", rc);
 }
 #else
 static void __init preinit_acpi_xen_time(void) { }
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 120ac09d23..eb608ab8b4 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data)
     struct acpi_table_header *table;
     struct acpi_table_spcr *spcr;
     acpi_status status;
+    int rc;
     /*
      * Same as the DT part.
      * Only support one UART on ARM which happen to be ns16550_com[0].
@@ -1959,6 +1960,11 @@ static int __init ns16550_acpi_uart_init(const void *data)
         return -EINVAL;
     }
 
+    /* The trigger/polarity information is not available in spcr. */
+    rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    if ( rc )
+        return rc;
+
     ns16550_init_common(uart);
 
     /*
@@ -1975,8 +1981,6 @@ static int __init ns16550_acpi_uart_init(const void *data)
     uart->reg_shift = spcr->serial_port.bit_offset;
     uart->reg_width = spcr->serial_port.access_width;
 
-    /* The trigger/polarity information is not available in spcr. */
-    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
     uart->irq = spcr->interrupt;
 
     uart->vuart.base_addr = uart->io_base;
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index a336241033..97c53c11e0 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -363,7 +363,9 @@ static int __init pl011_acpi_uart_init(const void *data)
             spcr->interface_type == ACPI_DBG2_SBSA_32);
 
     /* trigger/polarity information is not available in spcr */
-    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    res = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
+    if ( res )
+        return res;
 
     /* TODO - mmio32 proper handling (for now set to true) */
     res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:44:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:44:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394043.1632849 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIEj-0001wc-Jo; Tue, 18 Aug 2026 11:44:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394043.1632849; Tue, 18 Aug 2026 11:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIEj-0001wU-GM; Tue, 18 Aug 2026 11:44:09 +0000
Received: by outflank-mailman (input) for mailman id 1394043;
 Tue, 18 Aug 2026 11:44:08 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwIEi-0001wO-0z
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:44:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIEh-002WhO-AJ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:44:07 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844585-2eae-0a2a0a5409dd-0a2a450cc15e-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:44:07 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844586-f479-0a2a450c0019-d155dd33e148-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:44:07 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so3943001f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 04:44:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996100073sm288638625e9.3.2026.08.18.04.44.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 04:44:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787053446; x=1787658246; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=H7XzeYR+7zhcH+bahORub+d00BZMv3iO0s/OTh8B8NA=;
        b=I88b2ZNAmm19uRrxD1tbLHMYzeyTIvIF2r+vv7E+Ms7BoHzGQVxg6pd74/JOzb32A/
         f2DtOl5bjFjljCqg5lDGkxW5AOYcwX9/n4SSIoQhUAY9FfhFwVC4G1bgFFYriTbAF2p0
         xViljL085cd/CbY83uHehUJJ44R9El9rNB2Ej6cGZ1YfiPxx+szMurAGnSt5iayAaazx
         rXvo0+YFYjUSyI2318skWlS4uB/Bz4I67h3j4WEGNlMoUhiY1bxAOYwrlOub0FTezsdK
         Ggb1Ruk7sc4avxRoMST2n6MxRQ5qsXCi7suWVgngFaLveTjKqUnCL3Et3u6aVCSVQDAh
         57oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787053446; x=1787658246;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=H7XzeYR+7zhcH+bahORub+d00BZMv3iO0s/OTh8B8NA=;
        b=a8IxrOXp0OMzxCYIIkdUMrKh6eYlJJ2usQsXsuMwIoak/KsvFu+OmrrnRlPs63O7aT
         +V43r/Z1knuGabYXzJgiaJf0gYFwfGNS7TJRksbF2f06VuZR4PD3KHQXDlnra3xtSDO6
         YpVz43XGtvvri91ByQ6BUhx7VRrTu0E+ie8s2+dnIdCoZVpWf7tsNwE37nsGQc3ojiSx
         HQ0fl+JhFJYwbEdyerXMxUh7OC+uBzstXVu0vupGEzHn/EOHp9BftKza8ZXfugzwjvn3
         pcHHiw9cT3yQUipuFliS07Bw4tWg3aAWbonJwHaTMJ+Y32HruzLWgWq5BFs9k/Ll6RKt
         Tamg==
X-Forwarded-Encrypted: i=1; AHgh+Rrfvqv0DHgzNv7d/wWQUqtCF93uQKkCuYLz1om64FKTAO8r5IcPrIe0tjRFeVdNphVCfv0Lfb3xjDg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxkENaqcSNMaNx7QKUxtD59Re/QR5u8pwJqRUVRpryrBI5gx3Vw
	Y96ZB/31zeAdfBS4MOceQvh2yiMMtX05dF4YBxFLc5e0TLfVINNI41/HEpijzZQhJw==
X-Gm-Gg: AR+sD1049zxlmQhl3JWno9MUTHP+6YPB4JdcHtSieaSIOO6CEPqaTKxyU8xqlhsHXPk
	9hw/PYDNN+7Pb3k6zGXk/N4aAHD8jYPG1ftrDME8xWgJDN4wtM4Ty6mPDZyrXiZl+G83YNQskbW
	Iwa1dZ9zvykWJ6bAFJHpSw1drLMj02f7knW8ldf5ukY1RU/T0RipI1lJ4K4woEP3zOvNlJ9+bO5
	Qg3isjvLVOA5xzHxkDJCadlIteqKx1lXh5Jc3mW4oDLFeflfxtwYPzwfLrpXv3SgzvXRCskfr0A
	QLopjUyXZURAYd/yeUiK50eXitdJ7HkHnRXXTAId7AhNchBizyf6fQ2IovRRhyqTueP083YvYCy
	G8yVkag4zSZoCNg1RbzdOh/CwGvZ0iXZRTUrytdh1SxwSBs1h9Hi4n2u+LafL1GuO2AzP2VPqS3
	zUOQV1BOYypKhAifNTOwFNNIxlq3TQwtMvByex1RYdg/qRESVYXdsesLBlDTW1jAAecRtEbnzdy
	SC6pRpaLhS9EjhkWk3UtqLQl/nKxiXPGA6DjNTNOON7IvopPDFy
X-Received: by 2002:a7b:cbd3:0:b0:493:cefc:d113 with SMTP id 5b1f17b1804b1-4998794c02emr341063815e9.5.1787053446606;
        Tue, 18 Aug 2026 04:44:06 -0700 (PDT)
Message-ID: <403cc4a0-9b26-413d-bab8-03034e349c39@suse.com>
Date: Tue, 18 Aug 2026 13:44:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/23] x86/mtrr: get rid of a static variable on
 pause/restore
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Cc: Teddy Astie <teddy.astie@vates.tech>, trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787053447-01EC2A5B-7F994608/0/0
X-purgate-type: clean
X-purgate-size: 1467

On 02.08.2026 15:09, Sergii Dmytruk wrote:
> In addition to keeping the state in one place instead of on stack and in
> a static variable, this enables exposing this functionality to other
> units in the future.
> 
> Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
> ---
> 
> Notes:
>     v4: was called "x86/mtrr: expose functions for pausing caching"
>     v4: no longer makes anything public, just updates implementation
>     v4: the state structure is now an output parameter instead of a return value

I don't mind it to stay as you have it now, but recently we discussed this
aspect in another context, and I've changed my position: When the struct
can be returned in registers, it's okay to return by value.

> @@ -439,7 +440,7 @@ static DEFINE_SPINLOCK(set_atomicity_lock);
>   * has been called.
>   */
>  
> -static bool prepare_set(void)
> +static void mtrr_pause_caching(struct mtrr_pausing_state *state)
>  {
>  	unsigned long cr4;

Considering the conditional ...

> @@ -461,7 +462,9 @@ static bool prepare_set(void)
>  	alternative("wbinvd", "", X86_FEATURE_XEN_SELFSNOOP);

... cache flush that's done (and the comment just out of context also
correctly saying "no-fill cache mode"), we're not really pausing caching
in all cases. I'm therefore worried of the new names of the two involved
functions. Andrew, Roger - thoughts? (My inclination would be to suggest
mtrr_{pause,resume}_cache_fill().)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 11:52:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 11:52:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394052.1632858 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIMt-0003qX-Bd; Tue, 18 Aug 2026 11:52:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394052.1632858; Tue, 18 Aug 2026 11:52:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIMt-0003qQ-8p; Tue, 18 Aug 2026 11:52:35 +0000
Received: by outflank-mailman (input) for mailman id 1394052;
 Tue, 18 Aug 2026 11:52:34 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwIMs-0003qK-A9
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 11:52:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIMr-00F1mZ-ND
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:52:33 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a844780-e002-0a2a0a5209dd-0a2a450ccd04-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:52:33 +0200
Received: from [98.137.69.82] (helo=sonic314-19.consmr.mail.gq1.yahoo.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a84477f-f479-0a2a450c0019-62894552af1c-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 13:52:32 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Aug 2026 11:52:31 +0000
Received: by hermes--production-bf1-54b5569bdc-mnb2s (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 84544e02033dbaed8688a630b01bbe20; 
 Tue, 18 Aug 2026 11:52:26 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787053951; bh=sNtOfKbb03VpboV/eXDRYXRmjekDpDgcWLU0H+gqS/c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=RGSSK8u6ivWLA8pbBSWRRm4kWyKoMhbwcgfd3bNsLdP2qtJ7oaBdzY9KXzcitP7s5ycE6jMFWWvppVN/LeAS3Eu/hG52ZFg9w4YJwpnC5zbEqCsdVW9R1VnkLrV3g1ioAJEFxdGWmL7hXSHv4ywcKxtJBqo314fPwdk2IsV5idDbJlxLlJn+y3aI4owTIPMdk4b4+alsAez1Qitc7GnjhSSxF7OV7zeb+oThYnp8TQtnnWsiPc3MI5+q3iTElqGCjbhu1m6YKkJ3zQhHLri8+gBhNwH0T/r/zXQbDImyK8Y/FCbMaHEAfyTF1/vnXI3EXWtW+X6EsMeWC9lp+6IsRw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787053951; bh=162KKrb6tNGVUFigS9uRpqS0iWM52o0F4QFQST5mPll=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=hKBlSFZ05MvCbQwwYC1k2tVo9vY6Fl2d94MikygqEJDWe3VM46YkQFizaGYWS9o3nD3cs4ImgN71mITEq8sXIoWP9VSB57wWCNaA6wqJvufkXJK5Rh6/MXwJS8YiPrV2uT/UsktDAJSqD9I6k/cZUyeH/zrih7aTOMz+Q4haJwROet7Fc/GuaCZ6Dq0bE9BgEu1uEfFpnvVvQ+lBG0RbboZpcbni5EhkLumAOqL7/28FRce/Tv1J3kbeM2ju1iR7br1YaZ3b5M4iWg1IgB4R5NGWGSFfgS+ISUBdgz9NkecpDGOe4xWgXSDmFbkZtdTw9CsS8FY+QwVQEdexb4s37A==
X-YMail-OSG: KiTq6FoVM1mVn3bZbrVWaG6dgjAKCC8Yv8a.qMQ1cyqACIXRq.c.2ho1crvBLTj
 BiPWed9iDAG3V18fxQo1wdT9cMDTqeMnpjZJ25F8BA3kuOZ7nZ.k9lqg6Bqvf36gQe7d6RyAD7h3
 k3yLUkhIJ0oaV1kqDmMMNpsp.IbHbm36GaLIhjQSeW_ZBX2A8s.v8snXt0GBs6RKOwK6r5z_6S5h
 tHsjLhcLXyeU6NBfxOQHUBm8YAVYBkAkNzcyKkJkk8qqnX9WU.CzsxkRqMfkec.48zNdLMYa5c7S
 XZiq10Uc4urT4dN2dznlQ23ctUvkz4ep_QWACIqLDuTFphmqrK5Qu9sNLdAvxq8qCCin_.yyht_U
 bf.yaCSENz.CHEDNDIJHwKE9qynUb8t5JsjEEO4FIV7jFwlCL7lJYI4q0cjnqnewEpOBHky3G6pZ
 UfS_IYnf632KwTLuSlRgCOTQ5iV6MacVUJMnHg5XUwWR33hHzbAeXWXZgJmGDFdSC3ySdUH9mIYI
 ONmmO5anRZ5_SWr5X0A9p_2QuNzDtRyDjlWLRe.ySGft.RzhhKqYvHIyLGl6hhrbwJ7aTN9UN61J
 XvGx32hq4HsrCR2nB7dS9UNhEIooesY7kuzjVwWXYRcad9KaUHuOhYhDBXJ_nQrk2DS1KKrqBv89
 gWkAsQpdLRafCLsa1WZLlkx.slX6y_USQp316X9s2.bYO5vNo89c7mbMc6z2auhXWIWR1LJOeb1g
 LAz1oWtEYzxsiJgDP_QEeKOugk3tGE_mdOD__.r7ZNqIGldCNr.tdFd_KDbugCKc.1gOcP5nFeat
 ZwkOinyILo5kizBrUIzEv6rz4Y1DoZK1yBEzQz3RmGtEi1LgnaaLSoUDkUIIWS8fO9oIzNMii4YK
 Frn3yVLOzfqYb1YP4I5tK04KzLlEn8F7HnXB458w1B3qfHqiI8mQ9CznYw06UxuGzOaUDSSL1dOM
 oGWihV1NM3SH7xdsUQ4hZK2XSA2evEBuQD7BRJ_qtCLjMXVOCi8gis5D_TO6wbPYdpqQF_wO9Ybr
 qTkjjoIBe9mRXeIOpFUEND5gb9cQ_TKzNRhRR4cXmyMpGoYkawdpxr72UpeNpWjwO3Xmr1njw5_3
 xSHGCzOXrojDvznJsdJhgHXUuijdJD0Ifm96JNzB4NUTBRG4VoVUHM5BfFtOP8htOV5R4PvTeDJW
 _PwKcDqZHyhMw.f0vlRe4eB2GHZf88E64g2WCVyuTwLHTgp3_fCi5Vvke6oJHL8BubpHJj6XQRM3
 PNe10xc3R252eEfMsOExj8I1xFeH53mg4kec6rHEknEcdsk.GIJk2HBZsinwX.HvYQ1CHw5pPHqO
 JNmB9hXGmJnSYZiuzawHVXe0HJmIUh1KpLbE8EpaC.._NIk1s7Yo_rgynGJjk1b.xpT594IJ9AJs
 0Zkzk0s00_6I5OwvfmkL2N7W3shjxT9wIzVKB.XL4UD17tJROW9.ESd1deONS2snKSs8.c951otA
 5h._PODebtDXHVDVQjCF3q6g8ZyfGo8.GlC_ACOEA73Zp6b2zAclceaQj5nF37XE8dhuLTWpbrTS
 BcekgYsSr1sLHERH1w.kvg3T989tSeobHqaZjwEVgADDkmpNcMUyIWGOERPTmMqyhKyE0Mkn1lj6
 O4eIOfi6H4_ZrH2a6dyM4rHYktmxSBYUFMDlmm_2WMrXfzucrRYXhCViyB7PtwcI81pLlaBZwswP
 7EvQOfzaeYJxCuMarwN.Bs.x7kyL.NclgcaAWIFVMtk9dpulvh6ywrwyiOKGqN_sCed05t3l_Nsx
 PTlqR10MWBBewAOuc5a2I.zKjDTtY.4BYWgukEoGGaayOijkLqGxSCPXscWR5Lt0HKv18G5ElZlw
 oeQZwLJOVcSIeKQzE2yNOyAFEOoODJjs6T9zOYRphyOGgK.6qBdqz0raVaRoPrxkeIUD9dhF55Cd
 UwCuKDOE3evToa9EWMYE0s7l0t_8MZl3JEzSaytgmSRaSl1A5HkTrw0V9RMiC_vTHNYFh5i3OWtc
 vTiCzi3sYXAMNx3JYqikyP0.RxOQVpb5cCdk3Oh.IHvK9NZu3ykHIyxgGnLcAp2lc89x_t.PZ_lm
 9LJ.vAkhFOTEEmNnHTEqNA9KVmMPEaWgFIy0_z5XaeKTZWsMU2HR1V_dSdWA66G.d8sNsJH7Rxr8
 eWsn4YH3mbTFxV2HsNhaGUCS8FtHkdlHV_5SHHSnHEC7G2plXeH2xfC.rIobb2F1QyKFeSnkxyoX
 DMsjJLQiEIFDkeorggb2SlSarQM.cpt9gvjov4cO1
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 817225af-2dcb-4dd3-be27-e75fbd3ebedb
Message-ID: <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
Date: Tue, 18 Aug 2026 07:52:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 6053
X-purgate-ID: tlsNG-d25034/1787053953-020C1A5B-DA22BF94/0/0
X-purgate-type: clean
X-purgate-size: 6177

On 8/18/2026 3:17 AM, Jan Beulich wrote:
> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>> -- snip --
>>>>>>>>>> +    /*
>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>> +     *
>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>> +     */
>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>
>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>
>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>
>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>> by its DM.
>>>>>>
>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>
>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>> guest are also assigned to its DM.
>>>>
>>>> Currently, in the device model (Qemu) we have:
>>>>
>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>             DPCI_ADD_MAPPING);
>>>>
>>>> That statement is in the igd_write_opregion(...) function in the
>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>
>>>> If I understand our current implementation correctly, this statement
>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>> in hvmloader code).
>>>
>>> No, it introduces mappings of those pages into the guest's P2M.
>>>
>>>> I don't think this statement makes the host OpRegion
>>>> accessible to the device model, though, so I think, if I understand your
>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>> violation" correctly, that our current implementation is also guilty of this
>>>> same kind of "layering violation."
>>>
>>> That code, if it can be successfully executed, indeed doesn't grant any
>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>> needed permissions to access the pages itself.
>> 
>> So, are you saying it should be possible, without any patches to either Xen or
>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>> 
>> I think I could implement what you proposed in an earlier message and do
>> all (or most) of this in the DM instead of here in hvmloader:
>> 
>>> The more correct thing to do might be for the DM to
>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>> (How in turn the DM would learn of the contents of the opregion is a
>>> separate question then.)
>> 
>> Actually, when I was developing this patch, I tried first to do it that
>> way, but the problem was, I could not find a way to get a pointer to the
>> host OpRegion in Qemu.
>> 
>> So, how can I get a pointer to the host OpRegion in Qemu?
> 
> You don't ask me this question, do you?

Are you offended I asked this question? If so, I am sorry. You make me
afraid to ask it again so I will not do so unless you permit to do so
again.

All I can say is that surely qemu
> has an existing way to map (host) physical memory; see e.g. how
> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
> device. "Bogusly" there because that's another layering violation. Plus
> (independently) there and here there's the issue of how to accomplish
> things when not running in Dom0, or when running de-privileged in Dom0.

Well, that only proves Qemu *might* be able to access the MSI-X table of
a device, that is, if the calls to open /dev/mem and mmap it succeed.
Why is the MSI-X table all of the sudden relevant? Even if Qemu
can access the MSI-X table of some device, that does not prove that
Qemu can access the host OpRegion of an Intel IGD. So I think my point
still stands: I still don't see proof that it is possible for Qemu
to get a pointer to the host OpRegion without any patches to the current
implementations of Xen and the Linux kernel.

Perhaps I should accept your indications that it must be possible to get a
pointer to the host OpRegion. I will admit maybe it is possible and I have
not yet found out how to do it, but I have hardware I can experiment
with, and for me, that is the final authority. Proof for me only comes
from my own tests and experiments that I conduct on my hardware. Until I
see how I can get a pointer to the OpRegion in Qemu on my hardware and
actually realize that goal, I remain skeptical that it is possible to do
so solely by patching Qemu and not patching either Xen or the Linux kernel.

Chuck 

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:09:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:09:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394070.1632879 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIcf-0006WR-RF; Tue, 18 Aug 2026 12:08:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394070.1632879; Tue, 18 Aug 2026 12:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIcf-0006WK-On; Tue, 18 Aug 2026 12:08:53 +0000
Received: by outflank-mailman (input) for mailman id 1394070;
 Tue, 18 Aug 2026 12:08:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwIcd-0006WE-Pg
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:08:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIcd-00BayI-6R
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:08:51 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844b51-2eae-0a2a0a5409dd-0a2a4501a0f2-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:08:51 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844b52-5984-0a2a45010019-d1558033d0e4-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:08:51 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-495757ccbc1so41578735e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 05:08:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996100184sm291726575e9.1.2026.08.18.05.08.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 05:08:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787054930; x=1787659730; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=3yPtWQjt4aEfZty2NFG/9vt0uKtE4t9EaGlidQL9Cw8=;
        b=OEqLg1nHqwHfu+XxUWnpP2fYTaJHFnMCBgXIX1AwXMS/xYyyuBuDJqFFKioeh0u4q+
         Z4ZBfR51VeoiovVla5hv9x8qJDI7cUnHkt8BBUBeuWmGEnGyRhUzEpqyH7r2/ryiJ7sU
         OWrb990WaA9u6DhB+3TOEeZp6uk2A91gDZ1jKLdpbsQQPnYG5Q76TAgI/OEgWrv48Wbz
         9KFZPJ9hs57m5wTb2VAX72BgoeRcsGvtBgNiWFvfeh31xnKGgh7j9ZLAsKK6KElDUyvh
         VgIW+/hxNFxJid6mgf+A/nM6hhKYQKHycTA0OYeoWdXCA2+A/zl7G/dTh5NfvpXaMheD
         EALw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787054930; x=1787659730;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=3yPtWQjt4aEfZty2NFG/9vt0uKtE4t9EaGlidQL9Cw8=;
        b=PC2zmB1IfA/+7nDJpx9U+0EBClwcbI+PEgiTjIv8Blb3kt7HdFKnieuao7QwS3ccy0
         divBx1qW2bVtzRUMRGgylBecf5IREjZvMSqbZte83cKNej1JVwxL+8nDlmi+AS1MvbNS
         ZnjRKYwRnUm/ixw5tMSYfaSE3nL5qJAc3RRjzJV32gQX+LDE7HRzlUUwWbB8fNMEbhbw
         vUmkMsBnfUrbdRkIYMaR5IB1viQis8Kt0mGLYQPGgYcWDvZ4qr2mtOH8YCdlDto17Jfz
         owSTrl7RCRleTte+k1wY5gKTxHWQpa972UpGo9l+QPybdzBh02siDgxs7bpGNfpdyyzX
         Chfg==
X-Forwarded-Encrypted: i=1; AHgh+Rq+bhxfeKPPSVCYNcrGqG8rf2uSNmjo0fzc8Bs6dceWyRExyN0oGFfcWg53hRoCuF6hODWtkHZG7QE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYy/viR/sAgNgbXZ80BRcZaJddbLh/ZKfLl1eyhUxJvEQw4Pr+
	I21ZmIO/NsGEYKzcd1LtaOcCFKql/3ZTAD9zQlaKI8cTlireTQtNLGedc638GqlcdQ==
X-Gm-Gg: AR+sD11fCJFAS9gjs2dpwZfs68+Q/Wx9jYVAwd/kL9w/OX3yo1OcQp/WmJbioavgFYC
	C1lG+RclTZbnAABGVa0FCXvWKkATbO8gQPwe5YhbYAbnMwEe1Bs9IpQISfUomjqav04+j/Honv+
	dhS7/4q12h9mUnNTBf7uZnL+aeFa5cwP/Mj+l7arRLzFXacREozltQ5qJ61+qMPC5djPQ5gWJpk
	oklWCcxW0pED2oSKL4gnuNie5T3YgW3qpifMInyZwxAQ4lAbTmubqugVaeoPF/z7391bqZQSwoa
	dd4NIV9aCo9Ox6RQM3twEOYOgGWil+tDos8YKWK1RSBQp4AWqFvno91TfPtO7EeF6BBCjtjlCGe
	ayqBA1LxLum2BSFcyRZLqS03vDvK79QDU/CwszIfAK0m7Zu4bJVEtLoVc9nIHckxQRkgkrx7zdP
	Vv7U+DgQ+fqpMiL/FebVFkvH/pQ3xoF3wV1n+Sc2L/7V9/sERscuqajWxJh/XZSlKq5lKJUlGMb
	jXi8y52PNyGEasc7P0NoV6ynPPg15VHBEiQIugeLzHNljXDQ2v6
X-Received: by 2002:a05:600c:3398:b0:499:52dd:c1f0 with SMTP id 5b1f17b1804b1-499879298c4mr341784855e9.1.1787054930476;
        Tue, 18 Aug 2026 05:08:50 -0700 (PDT)
Message-ID: <7489d730-6e91-4d6f-a355-4eaa62698c4c@suse.com>
Date: Tue, 18 Aug 2026 14:08:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787054931-C4F47757-2E336DE1/0/0
X-purgate-type: clean
X-purgate-size: 4068

On 02.08.2026 15:09, Sergii Dmytruk wrote:
> From: Michał Żygowski <michal.zygowski@3mdeb.com>
> 
> Report TXT capabilities so that dom0 can query the Intel TXT or AMD
> SKINIT support information using xl dmesg.

Hmm. I first meant to ask: In how far is this extra logging useful,
especially as long as we don't use the features just yet? And only then
I noticed that I must have paid too little attention here already in v3.
Querying through "xl dmesg" is entirely unreliable. Sooner or later the
boot messages will scroll off of the ring buffer. Making this a
query-able interface also would mean we can't alter any of the messages,
should the want/need arise.

For AMD the situation is easy: It's part of the featureset / CPU policy
exposed via sysctl. The same is true for SMX on Intel, but the further
GETSEC output requires some other means to communicate. I wonder whether
making this part of the CPU policy would make sense, or whether to
introduce a Dom0-only hypervisor-CPUID bit for it, or whether yet
something else would be best here. Likely Andrew will have had thoughts
on this long before ...

Irrespective of the above also a few comments on the patch itself.

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -617,6 +617,21 @@ void amd_process_freq(const struct cpuinfo_x86 *c,
>  		*low_mhz = amd_parse_freq(c->family, lo);
>  }
>  
> +void amd_log_skinit(const struct cpuinfo_x86 *c)
> +{
> +    /*
> +     * Run only on BSP and not during resume to report the capability only once.
> +     */
> +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
> +        return;

If this is BSP-on-boot only, the function really wants to be __init. For that,
...

> +    printk("CPU: SKINIT capability ");
> +    if ( !test_bit(X86_FEATURE_SKINIT, &boot_cpu_data.x86_capability) )
> +        printk("not supported\n");
> +    else
> +        printk("supported\n");
> +}
> +
>  void cf_check early_init_amd(struct cpuinfo_x86 *c)
>  {
>  	if (c == &boot_cpu_data)

... use this condition ...

> @@ -1325,6 +1340,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
>  		setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
>  
>  	amd_log_freq(c);
> +	amd_log_skinit(c);

... at the call site (and of course also the other one). Same for the Intel
code, obviously.

> @@ -620,6 +625,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
>      }
>  }
>  
> +/*
> + * Print out the SMX and TXT capabilties, so that dom0 can determine if the
> + * system is DRTM-capable.
> + */
> +static void intel_log_smx_txt(void)
> +{
> +    unsigned long cr4_val, getsec_caps;
> +
> +    /*
> +     * Run only on BSP and not during resume to report the capability only once.
> +     */
> +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
> +        return;
> +
> +    printk("CPU: SMX capability ");
> +    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
> +    {
> +        printk("not supported\n");
> +        return;
> +    }
> +    printk("supported\n");
> +
> +    /* Can't run GETSEC without VMX and SMX */
> +    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
> +        return;
> +
> +    cr4_val = read_cr4();
> +    if ( !(cr4_val & X86_CR4_SMXE) )
> +        write_cr4(cr4_val | X86_CR4_SMXE);
> +
> +    asm volatile ("getsec\n"
> +        : "=a" (getsec_caps)
> +        : "a" (GETSEC_CAPABILITIES), "b" (0) :);

Nit (style): Bad indentation, missing blanks, unnecessary \n, and stray colon.
Overall:

    asm volatile ( "getsec"
                   : "=a" (getsec_caps)
                   : "a" (GETSEC_CAPABILITIES), "b" (0) );

I further question the need for volatile here. (Like for we have for CPUID, we
anyway may want to gain a getsec() wrapper for GETSEC.)

> +    if ( !(cr4_val & X86_CR4_SMXE) )
> +        write_cr4(cr4_val & ~X86_CR4_SMXE);

The clearing of SMXE here is pointless, as the if() already guarantees the bit
to be clear.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:12:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:12:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394077.1632887 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIgL-00083N-9q; Tue, 18 Aug 2026 12:12:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394077.1632887; Tue, 18 Aug 2026 12:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIgL-00083G-6n; Tue, 18 Aug 2026 12:12:41 +0000
Received: by outflank-mailman (input) for mailman id 1394077;
 Tue, 18 Aug 2026 12:12:39 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwIgJ-00083A-7l
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:12:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIgI-00Bbi0-DU
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:12:38 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a844c36-2eae-0a2a0a5409dd-0a2a450a84e2-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:12:38 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a844c36-f2d2-0a2a450a0019-d155dd34bcf2-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:12:38 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47f96c5b722so2843963f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 05:12:38 -0700 (PDT)
Received: from [192.168.1.109] ([88.230.46.229])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a3b51asm11719333f8f.11.2026.08.18.05.12.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 05:12:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787055158; x=1787659958; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Kw25hz9HWZA9hmiGJ4QWM8eskztAy8yjaPcWrKaRRhY=;
        b=Tt/W2l7Mjlazb35Vyxl2yMRzb/HY8YnsDADUbZuitRr11oPHG8o48LvZEfk/ycTBen
         v3+PD4M7N8YqjuapVV3n008eK7U83EtFbvqshdDhV/YSD1N4UosIGgUmNh8jG2kOBDNA
         3RLIBV5CAmQd06JKlDirymNabPFOvdxjjiUvwcL+qwaaXQqo0q0IR6Q7Jhmy0K5lU5ZX
         6xU2YDIbbNHyKr7eHYJkVf05AfLbHzyk/DTY1FhVbmsnoaVnCibS8/pMbWXk2yNRUP65
         2Flsi3nLW5IkWwJLaD6NzdOsEu9/sz1FlqAVHk5I7dWSPoiZOCdXH6haLcA/KK4ZXYHJ
         Tf5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787055158; x=1787659958;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Kw25hz9HWZA9hmiGJ4QWM8eskztAy8yjaPcWrKaRRhY=;
        b=NiRiY3ECKtqvu/PE0let+RJ7S4kIC4f1BxipmdhJGIFtbyrF+GMILVAHzwwpKDvatY
         QJoV6J2XOhAMDhfa3kCsGsfAF2FrC9DN0vOu8CXTYJ3K5PLPjbzUO5hS6PRvlO5Gy4K6
         9YFUS6lKQBoog+pGFERB17qFqDwR4F+C+d8IfnKgnMP9zRitJY7sYXeMaTc9E/w2lVZS
         CWnvtBqT0AhoHzfQ2ABytbnSMMdTCYu/bx/tpXRlD5bX7t6biSq2qgkwjZ5KWXsC2Rz2
         B+IV28nJypy/A/rf6a6coxLr3gX79X5iIYpQK8iiaQ/t3YycrhRaLVuMdvgEn4YR8rbI
         kt6Q==
X-Forwarded-Encrypted: i=1; AHgh+RranJClCQKvz4ZSkrOdjflkFGdBuAmfaLfmiLEwOnVhHL8m9NNWaFCmYle0J3xWKACu83/dV49zdBI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+X1WXGI9uUfJWuVz1Mx5sjNNVbQ/zeCXXqwV5MaQS7WxeZDE+
	fkHJyvRFyGb5RQZcYq5kP74sMtDmdU4AdzINHwX+p8ReoHhHqDi4n4MI
X-Gm-Gg: AR+sD12UBCft2HZm8dJBgdedN2Ie7uxk4wlNccf5DwlbzWE4N/j+o14WO+Ln77sLDhp
	VL9iY079cY7dzu19Ey6NgSI6kcxuLxy5Ydws6qdVPIaFyAyPfkClv45ucbqRpUJxmJWrS+DsREX
	PgzMNPV/tD7LqbhALDu11KP6k3Gt5ql+3UhPLFw3SoRCVPpNpAdvkdSyyZBM73WnobGL+Dr6+yn
	L+3qRH24ii/BzFVQOxkksf1uxJIkUhFttM+awsoyrjMfdkAR3/6cf7LOuaYC0vq5X+9ItI3w5f/
	ojGDOv6VcBGruhCk2eVPbA6UWPjJLlKSpGHC++zz5yXLTjfjD5a8pa+XBXGYQJkjVgUvN6rnX/Q
	J2CQFOSmxbq1JNfi1WKe/fFZQGra0KzsqEaKG951F2DEVHexUM2pkhgy/GOc7XSjCci32Ic2SE3
	7IOMo+B8ll4knGuHffJ0dnJzSe9Glpf/mDGOZW9qGUxDCg/a7aS+Qd9hWBiGqtY4MUbVOt
X-Received: by 2002:a5d:500b:0:b0:47f:e797:41c8 with SMTP id ffacd0b85a97d-482a905d127mr10618151f8f.4.1787055157666;
        Tue, 18 Aug 2026 05:12:37 -0700 (PDT)
Message-ID: <9cf716f2-cde6-484f-b371-1d4cc95e9479@gmail.com>
Date: Tue, 18 Aug 2026 15:12:29 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: dfaggioli@suse.com, gwd@xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, xen-devel@lists.xenproject.org
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
 <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
 <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
 <48825846-fd82-423c-9133-9221a629aa10@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <48825846-fd82-423c-9133-9221a629aa10@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787055158-52CDBCFC-8D7E12C6/0/0
X-purgate-type: clean
X-purgate-size: 5057



On 8/18/26 13:53, Jan Beulich wrote:
> On 18.08.2026 12:35, Andrew Cooper wrote:
>> On 18/08/2026 11:13 am, Jürgen Groß wrote:
>>> On 18.08.26 12:04, Andrew Cooper wrote:
>>>> On 18/08/2026 8:53 am, Furkan Çalışkan wrote:
>>>>> On 8/18/26 10:11, Jürgen Groß wrote:
>>>>>> On 18.08.26 08:32, Furkan Caliskan wrote:
>>>>>>> sched_move_domain() derives the number of units to rebuild from
>>>>>>> d->max_vcpus, which is fixed at domain creation and never rolled
>>>>>>> back if vcpu_create() fails partway through building a domain. So
>>>>>>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>>>>>>> counts it - this happens if sched_alloc_udata() returns NULL.
>>>>>>>
>>>>>>> The per-unit loop doesn't check for this: it sets
>>>>>>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>>>>>>> unit straight to the destination scheduler's alloc_udata(),
>>>>>>> which assumes vcpu_list is always valid and crashes Xen when
>>>>>>> it is not.
>>>>>>>
>>>>>>> Reproduced by building a domain in a non-default cpupool where
>>>>>>> vcpu creation fails partway through, then destroying it.
>>>>>>> domain_kill() moves the domain back to the default cpupool via
>>>>>>> sched_move_domain() before actually destroying it, crashing
>>>>>>> inside the destination scheduler's alloc_udata() (seen in
>>>>>>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>>>>>>
>>>>>>> Before building a unit in sched_move_domain(), check that all of
>>>>>>> its vcpu slots are populated, and skip it if any are missing. The
>>>>>>> rest of the function walks the vcpus that actually exist, via
>>>>>>> for_each_vcpu() rather than n_units, so skipping a unit here
>>>>>>> does not leave anything else out of sync.
>>>>>>>
>>>>>>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>>>>>>> ---
>>>>>>>    xen/common/sched/core.c | 19 +++++++++++++++++++
>>>>>>>    1 file changed, 19 insertions(+)
>>>>>>>
>>>>>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>>>>>>> index d3a0a97e1d..d542c76543 100644
>>>>>>> --- a/xen/common/sched/core.c
>>>>>>> +++ b/xen/common/sched/core.c
>>>>>>> @@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d,
>>>>>>> struct cpupool *c)
>>>>>>>          for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>>>>>>        {
>>>>>>> +        /*
>>>>>>> +         * Skip this unit if any of its vcpus is missing. Bounded by
>>>>>>> +         * max_vcpus.
>>>>>>> +         */
>>>>>>> +        bool vcpu_failed = false;
>>>>>>> +
>>>>>>> +        for ( unsigned int i = 0;
>>>>>>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>>>>>>> +        {
>>>>>>> +            if ( !d->vcpu[unit_idx * gran + i] )
>>>>>>> +            {
>>>>>>> +                vcpu_failed = true;
>>>>>>> +                break;
>>>>>>> +            }
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        if ( vcpu_failed )
>>>>>>> +            continue;
>>>>>> I don't think this is correct.
>>>>>>
>>>>>> If there are some vcpus in the unit you will loose them (i.e. make
>>>>>> them no
>>>>>> longer be able to be scheduled), right?
>>>>>>
>>>>>> For a dying domain this might be okay, but not for one still
>>>>>> active. So I think
>>>>>> you should at least verify the domain is dying, otherwise
>>>>>> sched_move_domain()
>>>>>> should just fail.
>>>>>>
>>>>>> An alternative might be to fix the NULL dereferencing where needed,
>>>>>> but this
>>>>>> could become tedious.
>>>>>>
>>>>>>
>>>>>> Juergen
>>>>> Right. My initial attempt only checked 'd->vcpu[unit_idx*gran]'
>>>>> for the head vCPU. The crash happens when unit->vcpu_list is set
>>>>> to d->vcpu[unit_idx*gran] (which is NULL) and passed to
>>>>> 'alloc_udata()',
>>>>> causing a NULL dereference.
>>>>>
>>>>> I expanded the loop over 'gran' to handle core-scheduling cases where a
>>>>> subsequent vCPU fails mid-unit, but as you pointed out, that drops the
>>>>> whole unit for active domain.
>>>>>
>>>>> I'll update the patch to check d->is_dying to skip incomplete units
>>>>> only for dying domains, and have sched_move_domain() fail if an active
>>>>> domain has missing vCPUs
>>>>
>>>> I'm afraid that wont fix everything.
>>>
>>> Why not?
>>
>> domU's in this situation do not have is_dying set.
> 
> Yet isn't the (separate) bug then that we allow a DomU to be launched when
> XEN_DOMCTL_max_vcpus didn't finish setting up all vCPU-s? Or is that what
> you were alluding to? Since you did say "..., and we may even want to
> schedule in this scenario" - perhaps not.
> 
> Jan

When vcpu_create() returns NULL, XEN_DOMCTL_max_vcpus returns an
error. Once the toolstack sees that, it immediately issues the 
kill hypercall. AFAIK, a domain in that state will simply be killed
and never actually launched.

Furkan



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:16:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:16:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394085.1632898 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIkL-00008t-Op; Tue, 18 Aug 2026 12:16:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394085.1632898; Tue, 18 Aug 2026 12:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIkL-00008l-LT; Tue, 18 Aug 2026 12:16:49 +0000
Received: by outflank-mailman (input) for mailman id 1394085;
 Tue, 18 Aug 2026 12:16:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <bertrand.marquis@arm.com>) id 1wwIkK-00008f-SG
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:16:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIkK-008xSv-8v
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:16:48 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <bertrand.marquis@arm.com>)
 id 6a844d29-8faa-0a2a0a5109dd-0a2a4506a67e-12
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:16:48 +0200
Received: from [217.140.110.172] (helo=foss.arm.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1)
 (envelope-from <bertrand.marquis@arm.com>)
 id 6a844d2e-195a-0a2a45060019-d98c6eaccede-1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:16:47 +0200
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A70C514BF;
 Tue, 18 Aug 2026 05:16:42 -0700 (PDT)
Received: from C3HXLD123V.arm.com (unknown [10.57.6.159])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A67D3F85F;
 Tue, 18 Aug 2026 05:16:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1787055406; bh=pV+iOjma9Ty2hBZaZWqNqKptTdOktDr+yOcJUa2WTjk=;
	h=From:To:Cc:Subject:Date:From;
	b=AKL0oE3a5XUtdijQTviDTNxbjHIM4tI1g4+vppwpm8n943XdOjepR5U27zFiOACW/
	 D0IU72ilceOd0IAvN3q+pUQ9bYp+tdxjLuNn+VJ9TOdlCzWBDIjzmxFtcNKId1hDMs
	 eHgxvRM+uBk2Qz3Nws2nGiqSaJLF31+kcYLAz2AY=
From: Bertrand Marquis <bertrand.marquis@arm.com>
To: xen-devel@lists.xenproject.org
Cc: Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
	Jens Wiklander <jenswi@kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>
Subject: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Date: Tue, 18 Aug 2026 14:16:32 +0200
Message-ID: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787055407-1FECC77B-09D466CA/0/0
X-purgate-type: clean
X-purgate-size: 2068

Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
possible vulnerability.

ffa_handle_msg_send2() copies the message header from the guest-writable
TX buffer before validating and using its fields. A plain structure copy
does not prevent the compiler from re-deriving later field accesses from
the live TX mapping.

For VM-to-VM messages, msg_offset and msg_size are validated against the
source and destination buffers, then used to copy the payload. If a
sibling vCPU changes the header and the compiler reloads either field,
the checked and used values can differ. This can cause an out-of-bounds
read from the sender's TX buffer or an out-of-bounds write into the
receiver's RX buffer.

The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
default. The audit ranks the likelihood of such a reload as low, but the
C semantics do not guarantee that later accesses use the stack copy.

Add a compiler barrier immediately after copying the header so that
validation and use consume the same snapshot.

Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
 xen/arch/arm/tee/ffa_msg.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
index 1eadc62870f2..39f561c8237f 100644
--- a/xen/arch/arm/tee/ffa_msg.c
+++ b/xen/arch/arm/tee/ffa_msg.c
@@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
 
     /* create a copy of the message header */
     memcpy(&src_msg, tx_buf, sizeof(src_msg));
+    /*
+     * Make sure that "tx_buf" which is shared with the guest isn't accessed
+     * again after this point.
+     */
+    barrier();
 
     src_id = src_msg.send_recv_id >> 16;
     dst_id = src_msg.send_recv_id & GENMASK(15,0);
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:18:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:18:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394092.1632907 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIlu-0000qA-21; Tue, 18 Aug 2026 12:18:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394092.1632907; Tue, 18 Aug 2026 12:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIlt-0000q3-UJ; Tue, 18 Aug 2026 12:18:25 +0000
Received: by outflank-mailman (input) for mailman id 1394092;
 Tue, 18 Aug 2026 12:18:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwIls-0000px-Sf
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:18:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIlr-00F6cK-Uc
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:18:23 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844d7a-2eae-0a2a0a5409dd-0a2a450388ce-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:18:23 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844d8f-fae8-0a2a45030019-d155dd29b98d-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:18:23 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47f84023916so4330637f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 05:18:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783c6sm12282438f8f.31.2026.08.18.05.18.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 05:18:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787055503; x=1787660303; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=oI/+2/4qb6DsLorRhnoBURW6T2nMbZwNewNOhb3O8qk=;
        b=K+bqkzpZRhbnC8fDeB7f+WAomNvSBET7ADJecEIcFiigApwo1L1m145IqW+nDdV837
         SDCJgRphql+Zib6Kkzmi2bQ0UMQgezoMaqUJ4DsBIvSogE8FZSs3FlNANKY/HoALM42U
         DqXjKvGUTIN07PhTSy3jwxqbuFPD6o9+aKgd1QUUBLJwjEBp8/dNd6eC/od9aBXjMRKB
         KbG4dhQEBiVUHrIRDNM1bhDcqPiJR5yZXupB23g6VWRRCcAE5oMk/gZR3UhT2QtFp6Q4
         XZJUQMZAyHqffwUPkcpleFLm8rdX/Ug60hWSV1EZyiZlFlZi/r0gt1ipkZnqQjaf+Ur3
         9SlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787055503; x=1787660303;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=oI/+2/4qb6DsLorRhnoBURW6T2nMbZwNewNOhb3O8qk=;
        b=Vs8KQ0GZ3YV3q7ZzldnORFni4grOqSFPvbRf83hrvodzP9bSRikgWRaZA2P8obaNS0
         5SqFFDEz9rE6a8z7ceA5Ky9QnQSpyauT/GvPoVZOfQywOIFxbixTmUqr4ycR7MnUyl4k
         plmvSbK2oedyWjST+TW+LJ7+otS/IG6Ba7Uuu3UVFkpL1ZJQqy2Z9Ek+zkTyVuRBhVOj
         GN1/v35ShQlkRvO3fydEyIjZvG8dgAQRxnt4CU8r3pm/8vzTktTgbPQ8wpKBeLj/M1m4
         u+maANjLi0Xt7C/8cY3qW2teOpQuGS2GM7Kts5w4EMEDB4Pl3foqEJU7Fc9wFtrin/fo
         Pu0g==
X-Forwarded-Encrypted: i=1; AHgh+Ro6UIONwkbUO/E50gPQIct/OCwCrj90otgiFGoEuibIk8/Zeh2uVi6HOZK2wvk/JQcWfcfSZrDYF5Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzfN0QNEvyttHI+xfvbO9ovgyxBbO6tQJ7rYz0ixK69lJ5/YMVx
	i9L1OWi/nlfH63TW5W3KzUy1K+OU3XkD987rxNwbhIvUaKC5XqG51X5swGpSOE3Cdg==
X-Gm-Gg: AR+sD134ryPsTKhAjfA6Bnv3S2BjT+Z1s3xKD8Cqc3YbGSbZA0t4Hdvz4iw4ab1Te/t
	2XF6OaCk3a8RqkcLzbQIftscvpUif1i3MW3ehgeEpeSThBaMxK4/VL6COratVvnZyQiiEselnru
	oPxaWvsrp0iwt3ODozClAE33k8UCYiAZkw9EaeokNsHobW2exIU+G+yTFCXwd2xHjh9TVDP1zPO
	fIwjswZ5JqRfeToQVs3pspaTK+ULVw0Tol1rwX6GweB43LgHrxp9NbMIdITY6Z9iDs6YOuRzieT
	4zck4fOBzjXSareSx93+TaPsvf0v9sj3mSFG6ZgYR1yJL+Cc5ikFAh8RDLwoojXH+NPn7j1qTuK
	RUzvlcXKPAJbWMwbm9XFZq7VL9kW0sKg166LLOyj6ixZzhwJYhl7KHlVXIECn4vbsEYpSPq9eZ7
	FZvqhfYgfjt4qYlkWH5w2oYiXhvGbb02MpEkmvRbEYX7N6qLH5o7zOPa6E9cA+5pkZaQXxvsaMQ
	bfdhyVYXuSLIsWDihnMmgJffDlEpzICVgQ3Hm2NJhX2MTyHwRoVzv7zkdNIaJg=
X-Received: by 2002:adf:ee06:0:b0:47f:9760:4d2e with SMTP id ffacd0b85a97d-482a90f493cmr11769620f8f.24.1787055503210;
        Tue, 18 Aug 2026 05:18:23 -0700 (PDT)
Message-ID: <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
Date: Tue, 18 Aug 2026 14:18:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787055503-6FEC24E9-8B19F3E0/0/0
X-purgate-type: clean
X-purgate-size: 6581

On 18.08.2026 13:52, Chuck Zmudzinski wrote:
> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>> -- snip --
>>>>>>>>>>> +    /*
>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>> +     *
>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>> +     */
>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>
>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>
>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>
>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>> by its DM.
>>>>>>>
>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>
>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>> guest are also assigned to its DM.
>>>>>
>>>>> Currently, in the device model (Qemu) we have:
>>>>>
>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>             DPCI_ADD_MAPPING);
>>>>>
>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>
>>>>> If I understand our current implementation correctly, this statement
>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>> in hvmloader code).
>>>>
>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>
>>>>> I don't think this statement makes the host OpRegion
>>>>> accessible to the device model, though, so I think, if I understand your
>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>> same kind of "layering violation."
>>>>
>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>> needed permissions to access the pages itself.
>>>
>>> So, are you saying it should be possible, without any patches to either Xen or
>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>
>>> I think I could implement what you proposed in an earlier message and do
>>> all (or most) of this in the DM instead of here in hvmloader:
>>>
>>>> The more correct thing to do might be for the DM to
>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>> separate question then.)
>>>
>>> Actually, when I was developing this patch, I tried first to do it that
>>> way, but the problem was, I could not find a way to get a pointer to the
>>> host OpRegion in Qemu.
>>>
>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>
>> You don't ask me this question, do you?
> 
> Are you offended I asked this question? If so, I am sorry. You make me
> afraid to ask it again so I will not do so unless you permit to do so
> again.

"Offended" is the wrong word; "very puzzled" may better get it. I'm not a
qemu person, and I never have been. I can't really help much there.

> All I can say is that surely qemu
>> has an existing way to map (host) physical memory; see e.g. how
>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>> device. "Bogusly" there because that's another layering violation. Plus
>> (independently) there and here there's the issue of how to accomplish
>> things when not running in Dom0, or when running de-privileged in Dom0.
> 
> Well, that only proves Qemu *might* be able to access the MSI-X table of
> a device, that is, if the calls to open /dev/mem and mmap it succeed.
> Why is the MSI-X table all of the sudden relevant? Even if Qemu
> can access the MSI-X table of some device, that does not prove that
> Qemu can access the host OpRegion of an Intel IGD. So I think my point
> still stands: I still don't see proof that it is possible for Qemu
> to get a pointer to the host OpRegion without any patches to the current
> implementations of Xen and the Linux kernel.

The MSI-X table (and it being accessible to qemu) is the best analogy I
could come up with, as that's one tiny area of qemu that I know at least
a little.

>From a Xen perspective, this analogy should be sufficient: All you need
from Xen is for it to permit to establish mappings of the underlying page.
As I've pointed out when commenting on a code fragment you presented, the
DM (domain) looks to have permission. Everything else is a matter of
establishing such a mapping. There the MSI-X table code may also guide
you. (Sadly it may also misguide you, since (a) I don't know whether it's
appropriate to do things this way in qemu, and since (b) it is, as said,
imo a layering violation.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:20:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:20:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394101.1632915 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwInP-0001PC-Et; Tue, 18 Aug 2026 12:19:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394101.1632915; Tue, 18 Aug 2026 12:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwInP-0001P5-BI; Tue, 18 Aug 2026 12:19:59 +0000
Received: by outflank-mailman (input) for mailman id 1394101;
 Tue, 18 Aug 2026 12:19:58 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwInN-0001Ox-Ul
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:19:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwInM-006As8-N3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:19:56 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844dea-2eae-0a2a0a5409dd-0a2a4509e932-14
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:19:56 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a844dec-be1a-0a2a45090019-d155dd2cf0df-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:19:56 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f59f25ec4so1947135f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 05:19:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a6c449dbsm11037872f8f.8.2026.08.18.05.19.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 05:19:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787055596; x=1787660396; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=647W8yleiNXsvO+eqQLwTgxj/0ySZYHUKiwnSDmJC74=;
        b=ZHM09KS+VzEcHaizkgxlsb4MuqEZiuhrptewxrpi7zA3v5nzYPbvzhPMhV+eF0l3sI
         OwWuTZGtNRJ3dXgZXePPPqisbHNscQouBLPyBX17/InRBR5VLJoPN+O/WjTDATaPzv6m
         MDjc7gox/ZOFBpLrJXF+1H+H/o6hMUjXUsWk2/bJ8XtZh5yxZhI3lYv6F9ufN4KAtrQA
         qIUw11obg8IHOmzdLjz4PTjT6W9RHV5VwpShV9HgDD1cSL6u09uvgWOsoDLvsje3hIvv
         rQI+xBOaB9EN+rEV4VcqQ2n4ueAkFE02y1CJuHwHp3Cysoh8ZIE7gfDnj2eKFJj0rmhf
         HqUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787055596; x=1787660396;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=647W8yleiNXsvO+eqQLwTgxj/0ySZYHUKiwnSDmJC74=;
        b=PPrcg+pvDlML53MKto2LqSjaOqRupgiEiEzksLDDJUmfhEwAL1b0zo7pjn+qS7EJ2s
         yUb1DPvLsZtijRfHPFCOf5niM4u6j8WIpc42DGTcYhBVvIAQJRnyNbF2LL+JC7mTN+id
         /K7NjN/kgVW3WrANfr+HYFHTFjMxZEbF/Yli6eHHTdxcrEIflhZJ57NctJ3/OHeFaUk1
         oSbHQ9huQh/0tdkUJAhTVTpZb0m62/cRQFw/uqUPdMRW2FFUVxfgkp2nLLjzPB4t30VQ
         ne08Q9mW6aOKm+2CLCSgRg+zF8n782tN5dNEqc2WwZmLZ5K4MSdCK7SkexMDExVSo7Gp
         p4UA==
X-Forwarded-Encrypted: i=1; AHgh+RrF9/8d94RctHMDnAe0RLz9xtlEmd4WwYcVLrMJ6PqDjHiRw3UcTmtkmqkvlfpq/OlQ6vsFv7eHqFk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6kWsUb8QUwMDcfFv1M4Q214xgZA+SQSAGqbdv3ZKc6xQLIkLS
	OxhgoebTtT3DAhuQlg9lqtUcsU+CNV5jBZAs8SDayzgyJ66hWXhi5UmS+wh5u390QTYNV7UYWZL
	ARDbNhA==
X-Gm-Gg: AR+sD12KlhwzDueQ5+r6H2DHc65N91kyManvD7VaafdIiC+A7pnUEp4mKt1l0T7Hp3O
	lMcIjFvPYyqHvNsqkXHnjbZV+D0GEirAlKWSImYi/0xfHOT8DEL7qHVfK+yabAkyak4z2F/57nX
	EXITNi+h85T/kNUpyhG0AS8kLYp9k7HmOczrnz63xYJ8w8wTox+YNg5Bt2OP8VzyOTM3iAksy73
	1beZCrirFQ3KO7O2e4XBCH+upL+s38HqA7Fj6d9dutYfBEF56oDIhpjjCpoi8Ls3A+KlKTdC2KX
	7Vg9Wz5Bq01NpMqZ2lX45/vuvYKFsjJilxb02PtYmsvz0VV9VhnkEf5N64Zf+k6y/qYKF18unmo
	mSWpx/XxP7NASbmvUZyz/ah67SDFKpN6IX0t1+zfLeaKazdVG2uqd4HYLD/TtITYFSLwVo+3c00
	UYDwWn/YCdXnl6vooRv1pSEcGzuWpDHpDiAJn2P17dsdnZtepZbfQteAvsAoYPuvW+Nfv05mTC4
	hqTiOByeJvVfm0T/obyeVdsQ2d+nA7K2SFoPM5AOjJDQdtLitff
X-Received: by 2002:a5d:5e90:0:b0:47f:8183:e9b8 with SMTP id ffacd0b85a97d-481607656b7mr52199325f8f.22.1787055596032;
        Tue, 18 Aug 2026 05:19:56 -0700 (PDT)
Message-ID: <7faa6208-1b72-49bf-b4b0-c509a6572ceb@suse.com>
Date: Tue, 18 Aug 2026 14:19:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
Cc: dfaggioli@suse.com, gwd@xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?=
 <jgross@suse.com>, xen-devel@lists.xenproject.org,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <20260818063259.18733-1-frn1furkan10@gmail.com>
 <20260818063259.18733-2-frn1furkan10@gmail.com>
 <030c7756-c959-465d-9d14-9bb3523e8c31@suse.com>
 <1d50520d-68bf-4765-8a13-c7c047580f2e@gmail.com>
 <887cce18-5a67-4177-bdaf-7ef9bc192bea@citrix.com>
 <1b281dff-d43c-4ab6-9429-e30765a93be3@suse.com>
 <cf0fe335-a45b-4721-b5cd-ac1fd293553a@citrix.com>
 <48825846-fd82-423c-9133-9221a629aa10@suse.com>
 <9cf716f2-cde6-484f-b371-1d4cc95e9479@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9cf716f2-cde6-484f-b371-1d4cc95e9479@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787055596-BCCCF034-6A834623/0/0
X-purgate-type: clean
X-purgate-size: 5262

On 18.08.2026 14:12, Furkan Çalışkan wrote:
> 
> 
> On 8/18/26 13:53, Jan Beulich wrote:
>> On 18.08.2026 12:35, Andrew Cooper wrote:
>>> On 18/08/2026 11:13 am, Jürgen Groß wrote:
>>>> On 18.08.26 12:04, Andrew Cooper wrote:
>>>>> On 18/08/2026 8:53 am, Furkan Çalışkan wrote:
>>>>>> On 8/18/26 10:11, Jürgen Groß wrote:
>>>>>>> On 18.08.26 08:32, Furkan Caliskan wrote:
>>>>>>>> sched_move_domain() derives the number of units to rebuild from
>>>>>>>> d->max_vcpus, which is fixed at domain creation and never rolled
>>>>>>>> back if vcpu_create() fails partway through building a domain. So
>>>>>>>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>>>>>>>> counts it - this happens if sched_alloc_udata() returns NULL.
>>>>>>>>
>>>>>>>> The per-unit loop doesn't check for this: it sets
>>>>>>>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>>>>>>>> unit straight to the destination scheduler's alloc_udata(),
>>>>>>>> which assumes vcpu_list is always valid and crashes Xen when
>>>>>>>> it is not.
>>>>>>>>
>>>>>>>> Reproduced by building a domain in a non-default cpupool where
>>>>>>>> vcpu creation fails partway through, then destroying it.
>>>>>>>> domain_kill() moves the domain back to the default cpupool via
>>>>>>>> sched_move_domain() before actually destroying it, crashing
>>>>>>>> inside the destination scheduler's alloc_udata() (seen in
>>>>>>>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>>>>>>>
>>>>>>>> Before building a unit in sched_move_domain(), check that all of
>>>>>>>> its vcpu slots are populated, and skip it if any are missing. The
>>>>>>>> rest of the function walks the vcpus that actually exist, via
>>>>>>>> for_each_vcpu() rather than n_units, so skipping a unit here
>>>>>>>> does not leave anything else out of sync.
>>>>>>>>
>>>>>>>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>>>>>>>> ---
>>>>>>>>    xen/common/sched/core.c | 19 +++++++++++++++++++
>>>>>>>>    1 file changed, 19 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>>>>>>>> index d3a0a97e1d..d542c76543 100644
>>>>>>>> --- a/xen/common/sched/core.c
>>>>>>>> +++ b/xen/common/sched/core.c
>>>>>>>> @@ -745,6 +745,25 @@ int sched_move_domain(struct domain *d,
>>>>>>>> struct cpupool *c)
>>>>>>>>          for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>>>>>>>        {
>>>>>>>> +        /*
>>>>>>>> +         * Skip this unit if any of its vcpus is missing. Bounded by
>>>>>>>> +         * max_vcpus.
>>>>>>>> +         */
>>>>>>>> +        bool vcpu_failed = false;
>>>>>>>> +
>>>>>>>> +        for ( unsigned int i = 0;
>>>>>>>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>>>>>>>> +        {
>>>>>>>> +            if ( !d->vcpu[unit_idx * gran + i] )
>>>>>>>> +            {
>>>>>>>> +                vcpu_failed = true;
>>>>>>>> +                break;
>>>>>>>> +            }
>>>>>>>> +        }
>>>>>>>> +
>>>>>>>> +        if ( vcpu_failed )
>>>>>>>> +            continue;
>>>>>>> I don't think this is correct.
>>>>>>>
>>>>>>> If there are some vcpus in the unit you will loose them (i.e. make
>>>>>>> them no
>>>>>>> longer be able to be scheduled), right?
>>>>>>>
>>>>>>> For a dying domain this might be okay, but not for one still
>>>>>>> active. So I think
>>>>>>> you should at least verify the domain is dying, otherwise
>>>>>>> sched_move_domain()
>>>>>>> should just fail.
>>>>>>>
>>>>>>> An alternative might be to fix the NULL dereferencing where needed,
>>>>>>> but this
>>>>>>> could become tedious.
>>>>>>>
>>>>>>>
>>>>>>> Juergen
>>>>>> Right. My initial attempt only checked 'd->vcpu[unit_idx*gran]'
>>>>>> for the head vCPU. The crash happens when unit->vcpu_list is set
>>>>>> to d->vcpu[unit_idx*gran] (which is NULL) and passed to
>>>>>> 'alloc_udata()',
>>>>>> causing a NULL dereference.
>>>>>>
>>>>>> I expanded the loop over 'gran' to handle core-scheduling cases where a
>>>>>> subsequent vCPU fails mid-unit, but as you pointed out, that drops the
>>>>>> whole unit for active domain.
>>>>>>
>>>>>> I'll update the patch to check d->is_dying to skip incomplete units
>>>>>> only for dying domains, and have sched_move_domain() fail if an active
>>>>>> domain has missing vCPUs
>>>>>
>>>>> I'm afraid that wont fix everything.
>>>>
>>>> Why not?
>>>
>>> domU's in this situation do not have is_dying set.
>>
>> Yet isn't the (separate) bug then that we allow a DomU to be launched when
>> XEN_DOMCTL_max_vcpus didn't finish setting up all vCPU-s? Or is that what
>> you were alluding to? Since you did say "..., and we may even want to
>> schedule in this scenario" - perhaps not.
> 
> When vcpu_create() returns NULL, XEN_DOMCTL_max_vcpus returns an
> error. Once the toolstack sees that, it immediately issues the 
> kill hypercall.

That's what the one toolstack you look at does. At the hypervisor level, what
a toolstack may do after a failure is entirely unknown.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:30:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:30:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394109.1632925 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIxC-00049b-Cc; Tue, 18 Aug 2026 12:30:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394109.1632925; Tue, 18 Aug 2026 12:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwIxC-00049S-78; Tue, 18 Aug 2026 12:30:06 +0000
Received: by outflank-mailman (input) for mailman id 1394109;
 Tue, 18 Aug 2026 12:30:05 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwIxA-0003or-RK
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:30:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwIx9-002fJJ-Sa
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:30:03 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a845042-bab6-0a2a0a5309dd-0a2a450ad80c-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:30:03 +0200
Received: from [98.137.65.146] (helo=sonic309-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a845049-f2d2-0a2a450a0019-62894192876d-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:30:03 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Aug 2026 12:30:01 +0000
Received: by hermes--production-ne1-6dbcb84f44-9jslv (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID e5dc29c1a1be5ea329f6254e372ba29b; 
 Tue, 18 Aug 2026 12:29:58 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787056201; bh=jz0lsF7UaR5cFtfwz1uDrwFu8gHUr1wVACs9npDuP/I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=uL2qU2pLXjrDAW5zX4VClWEZ0aiLaXI/yO/XM4bHVUvsRJDmtfH5xQtYQPMN1ehzyMjQ5+wMDYe+KA9vww5fL9Ano0H5iDroljAe5pSpdxX+a/pDdx0Ti8lbsCyGyoueJ59hk5+W+ePqwuIsZbuYh67HPQy1YTSALsz08h3K1Gxb94VTbEen49f691UIjWKaZVdUSwscCsJd0dz20+aIG+9g1Cqy2R1hHxl73n0cOAGG462RgyOFMw89xH3jNBx9idtZgcoo3nixKPX2t4/oQSYDifID1RNPBalOyMZDBoNinbWPMez3nHGGFRuMR0CrS7wgSy/dQmOFqyROTXSoQg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787056201; bh=DdppHNbovwvCrHmNHrOUpcghqG/ObVCcXyDuVFT/Mb0=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=GwOcGaT8YLWUmlvX0c6iR7IsCTDfnyL59TWHqpEiuZamceYZU4zCOYzH5MGBcb7oqbQxy9znU5KlshcwJQWpSB0U0O5R5AXzgzaaHVMopxzUzwRiHHr117KTYhPeFHjRGcdlmx8Hb/YYR11JJf1dtZZ40b0K5mHeYs24Bql2Z02CrxWh/lXBPzfd/GPCvaxCmeDwEisabSsgms9wtNHiSvbFMR0Lw4oBkFiDKJ/adrutDYuTqu9ZMquKtgqX+QME5O+T8ROx2MyQTlmGyR7BfBha/8/4kIlL/9onyibAdJoWzbVJk9yhvH/SoNapjJJqN0OMAvbT7IP0d+BwRgnv6g==
X-YMail-OSG: _RgedzsVM1lCNngddMq0FFkG2OfsZ9VNbhI.CmnFjYpNxp47JVb9_CZs9bNI3mw
 27LwFJWq77gMSgfTqDeURmQv.tTupW88MwtG2QVMeEayxoBl7oe3ZJ8Sk6N.jfCmLRQFOuVs.4n6
 idJeV9ByJiiEaVU8QXhuW.V.rd6DFJ4JM8ysVSVAoh.xSymCJ5sqh7ODlOb5yWi6IzAZEkhG2Djx
 MWdyMe9QNggu6zKmITmk9ezCB057wyyZBIME96r_nA1rX5jwcw_nqhLooPWHysV2k.cocJJz4qVf
 gXDdvbo.4kP4VjNJxBWC.DFaXhb9jdsf7xKhgcDoPozUfDC.pg.yWtKROyLOEQkqYD3Th8jmeNMM
 vqTuWRKWfRYBNhHvwUXMTUD.Ps2UgSZiIWrPtrgnmoHpfWUHJEFmWEKGrSQV5Y1TBeIEfzp6ylvi
 sPAl6dSNcvjI2WiC2f0ZtJQQhUKfmTrkzTEhJJWTnBO2HT7b9yCRt6A1D9OqTUYRIEkhxcPLSCDq
 viZPcQWeoZI3WxN.c_PS7ExCQsleEDJzVvlzvZSOmsG6cQ_qByCcLRUu8l7d5cPq21OUBzzr2Lyh
 V23bquTnBvWuGquWw9oqIBEJp1wsrFzAsk_JfJaDBAPrPoMBCi.W37isi9xQUai5JZZHlAGfSGeZ
 mczWFgp5ioFvDoG79Fq3lrMvQNl1dfk_O8EBzrpjh2hE6SXhy.NjElHq6GL86vbjP5XshcmpwGGq
 6DT1dCabxtYuTyYGVslPMXqOg69KTF7XaK8afp0OYtMZK6y03us.32PsCTZwFcMnDCTVxAyg8FEg
 mxxOAZYVp1JqzePFISiDpoWtMTRwynl04YIMV2.1UQYjuhzMsl2U9q6oHXx6Q.ohYpVPk1vfRC1f
 6aQYV4cM1rE3NleN.9LN3p5ZzkKKE3ogRxh6xklvvVFR.uBdHYdPQxYMguyMnmqPjTveuW7MFTCb
 WCpycdw35m_PhN1L876m60ALNGVktD8bhwFAwEe3dxw0zFJDixvRyFkGPrnf_eNGo2AbKRxOBTsq
 hT.2C3jTKVkJBiPoUdfUWfhJLrP0JFWnIIVNKmSwBv5Xy_eiWcFBG8mDPR7d5CjtlRpZAUMts7h5
 PFnWf83IqoAQl9i9Zb093NsOzWbycsdsqQusdnM4ny8r6a.HqzAJrJ6wLD9YXIbSSSS3vyn9pI41
 n.Ep.G7Cv1U1S4fBLR8cVodyTmwy2zh0Ih1Cvng.KGs1bXrilwg.c2tg_JdK15cYBXOlO4y1P0Fl
 bOyI8VFXWHM0ziKnShysmRZBQ8Jr28X4vOUZmRw1091Yzs0VU3CrOxObbOWNDjLPKD3XHuckNqo.
 _9fGJK.GI1rI7XEsL2Mkvz7bFQ82kj8E8bq8VFdelxDB5OczLkDTbL_gI09NhO2u3bBJExGV7ogo
 qkRGrMeKSbRYxcEh73h25iRvMqD8tKB.XzYsaPU97zG_U8R91xF5OOdGKnYdF7nf2qUXMpGfEtOl
 cIuZeXvQd1hvZT0IvpkKULakrgS3z939dhlvvN4nGXK7PMajY8pZH7BU7EudVQbF07cwQTe5iY0y
 EPZooGHDFejw8kBFgb_e.gI8O_avQT46l1dHlDy2GWuyT3WH8RzPK3n.sxnRjbAVao1EwFbPdd.I
 mQsqAdon8.Hn7QqXobT4lqLVcd0cchRMJAwqxFMz7ctWeLXBElKYo2lCilejE7V8.Ys8ZrEghPmz
 GpKApktwuAkNYZVDjuYhx6tsa3jed48DFfE3siACv.TzU7JAPM0xhFbJTWokEgLJyACaP8QviFyZ
 QAE.f8.tMAiWo3EZX10IQiy2G95dKZnA2nvuJycW74jdt4aEG.mb4EuQ_FToJObQcPRuooT.JWNG
 hwo5Eglarp9s6_MLIdFK9uG1r9Bvdk.j_cdOMg2C1Czv3J8ZhpgzwWlm6WNHH1LtuQ2OKiAzEN1O
 16CJBgroC84WXR5USkvEcTEydb6xr1uZNIPvH2EvGBxX4qMw7e5xonVOUqVkVQAIdmI6Ah1TeoqF
 S6d3Po1TjZuKiYX0s9MfLlVwEMAGY9wkB14RJf1hMvzgSLwA3yyK22OGEM3YTgAWdBXWiinu5aNv
 8VNYZnap0U5prYHd6v.ww3SPeu8W5lgYjCUnNTSrlKqMqhPFcT_YIcgBsXTVTASEX_O9TLVJiMnf
 QE7O4C1gGvgjP9pAWugQHb.6iSsWj52uyV2QXX7BF__WzdaxqCrKxD98buMRnd096kXEO3sqwplx
 oFHayQxcPsQ9fuyOKN40Hk9xPIH3rp4MWM5X.ABHSZTuS
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: c47e0327-5137-42a7-963d-da8cd16b4b6f
Message-ID: <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
Date: Tue, 18 Aug 2026 08:29:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 6779
X-purgate-ID: tlsNG-4011c0/1787056203-4ABD8CFC-80B861D4/0/0
X-purgate-type: clean
X-purgate-size: 6915

On 8/18/2026 8:18 AM, Jan Beulich wrote:
> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>> -- snip --
>>>>>>>>>>>> +    /*
>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>> +     *
>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>> +     */
>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>
>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>
>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>>
>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>>> by its DM.
>>>>>>>>
>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>
>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>>> guest are also assigned to its DM.
>>>>>>
>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>
>>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>>             DPCI_ADD_MAPPING);
>>>>>>
>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>
>>>>>> If I understand our current implementation correctly, this statement
>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>>> in hvmloader code).
>>>>>
>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>
>>>>>> I don't think this statement makes the host OpRegion
>>>>>> accessible to the device model, though, so I think, if I understand your
>>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>>> same kind of "layering violation."
>>>>>
>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>>> needed permissions to access the pages itself.
>>>>
>>>> So, are you saying it should be possible, without any patches to either Xen or
>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>
>>>> I think I could implement what you proposed in an earlier message and do
>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>
>>>>> The more correct thing to do might be for the DM to
>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>> separate question then.)
>>>>
>>>> Actually, when I was developing this patch, I tried first to do it that
>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>> host OpRegion in Qemu.
>>>>
>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>
>>> You don't ask me this question, do you?
>> 
>> Are you offended I asked this question? If so, I am sorry. You make me
>> afraid to ask it again so I will not do so unless you permit to do so
>> again.
> 
> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
> qemu person, and I never have been. I can't really help much there.
> 
>> All I can say is that surely qemu
>>> has an existing way to map (host) physical memory; see e.g. how
>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>> device. "Bogusly" there because that's another layering violation. Plus
>>> (independently) there and here there's the issue of how to accomplish
>>> things when not running in Dom0, or when running de-privileged in Dom0.
>> 
>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>> can access the MSI-X table of some device, that does not prove that
>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>> still stands: I still don't see proof that it is possible for Qemu
>> to get a pointer to the host OpRegion without any patches to the current
>> implementations of Xen and the Linux kernel.
> 
> The MSI-X table (and it being accessible to qemu) is the best analogy I
> could come up with, as that's one tiny area of qemu that I know at least
> a little.
> 
> From a Xen perspective, this analogy should be sufficient: All you need
> from Xen is for it to permit to establish mappings of the underlying page.
> As I've pointed out when commenting on a code fragment you presented, the
> DM (domain) looks to have permission. Everything else is a matter of
> establishing such a mapping. There the MSI-X table code may also guide
> you. (Sadly it may also misguide you, since (a) I don't know whether it's
> appropriate to do things this way in qemu, and since (b) it is, as said,
> imo a layering violation.)

I agree that accessing the host /dev/mem directly is cringy. I would not
really want to do it that way for the host OpRegion.

Chuck

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:37:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:37:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394117.1632932 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJ4I-0004oE-1N; Tue, 18 Aug 2026 12:37:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394117.1632932; Tue, 18 Aug 2026 12:37:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJ4H-0004o7-Uj; Tue, 18 Aug 2026 12:37:25 +0000
Received: by outflank-mailman (input) for mailman id 1394117;
 Tue, 18 Aug 2026 12:36:55 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jjherne@linux.ibm.com>) id 1wwJ3n-0004nR-Oq
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:36:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJ3n-002gny-1Z
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:36:55 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jjherne@linux.ibm.com>)
 id 6a8451e4-8faa-0a2a0a5109dd-0a2a450aa5e6-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:36:55 +0200
Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jjherne@linux.ibm.com>)
 id 6a8451e5-f2d2-0a2a450a0019-94a39c01ea74-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:36:54 +0200
Received: from pps.filterd (m0353729.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67IAVWUM2355685; Tue, 18 Aug 2026 12:31:31 GMT
Received: from ppma21.wdc07v.mail.ibm.com
 (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g2fsqr3va-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 18 Aug 2026 12:31:30 +0000 (GMT)
Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1])
 by ppma21.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67ICQKHI005403;
 Tue, 18 Aug 2026 12:31:29 GMT
Received: from smtprelay05.dal12v.mail.ibm.com ([172.16.1.7])
 by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4g33ek35sp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 18 Aug 2026 12:31:29 +0000 (GMT)
Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com
 [10.39.53.229])
 by smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 67ICVRIC20578988
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 18 Aug 2026 12:31:27 GMT
Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 6B03A5805D;
 Tue, 18 Aug 2026 12:31:27 +0000 (GMT)
Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 974735805B;
 Tue, 18 Aug 2026 12:31:21 +0000 (GMT)
Received: from [9.61.88.99] (unknown [9.61.88.99])
 by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTP;
 Tue, 18 Aug 2026 12:31:21 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=pp1; bh=UL9IFO
	BfaU/clKhXme8sOAazBEUtsscNml+GIhZ/mjc=; b=oMT8bJEReh0EmAFaP7G9HP
	e/pj+gHlxR7TUff7uWpiXYx3U+zLTQr2uKoCAAwLfYUP5qXZpXFZXv8X+VOm3MSv
	IjbE7NjT2UWR52QmJbviFARKyiB+G76mRaH9Kv6JlYOTVYZUKOArW4VolOjz//2P
	H8D6Xb6Gw7OBcF1N/579Dw0t+u1lkl0DMDr9KzEbnhQIb+UM0zQlgbGDScoRNQ6c
	c5KsKxoyv4OCZ+tEOmdgW1ynYWz67IUK7ogWIQ/S2j/IuC+zpj0amqTkLTKq03T7
	LbZchkE1MoH1hl788YRP4ZywydVPfEjpFVhDOIhTSqRB3VneJIT4R7XAunnUqJAg
	==
Message-ID: <77e4a58e-269f-4c90-8a1d-bbf89a889c35@linux.ibm.com>
Date: Mon, 17 Aug 2026 14:09:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 37/49] monitor: tighten monitor_printf*()
To: =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>,
        qemu-devel@nongnu.org
Cc: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
        Markus Armbruster <armbru@redhat.com>,
        Gerd Hoffmann <kraxel@redhat.com>,
        "Gonglei (Arei)" <arei.gonglei@huawei.com>,
        zhenwei pi
 <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>,
        Hanna Reitz <hreitz@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
        =?UTF-8?Q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>,
        Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
        Ani Sinha <anisinha@redhat.com>, Laurent Vivier <lvivier@redhat.com>,
        Amit Shah <amit@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>,
        Brian Cain <brian.cain@oss.qualcomm.com>,
        David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>,
        Richard Henderson <richard.henderson@linaro.org>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
        Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>,
        Halil Pasic <pasic@linux.ibm.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Cornelia Huck <cohuck@redhat.com>, Eric Farman <farman@linux.ibm.com>,
        Matthew Rosato <mjrosato@linux.ibm.com>,
        Ilya Leoshkevich
 <iii@linux.ibm.com>,
        David Hildenbrand <david@kernel.org>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Anthony PERARD <anthony@xenproject.org>,
        "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
        "Dr. David Alan Gilbert" <dave@treblig.org>,
        Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>,
        Fabiano Rosas <farosas@suse.de>,
        Samuel Thibault <samuel.thibault@ens-lyon.org>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>,
        Chinmay Rath <rathc@linux.ibm.com>, Glenn Miles <milesg@linux.ibm.com>,
        Harsh Prateek Bora <harshpb@linux.ibm.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        Weiwei Li
 <liwei1518@gmail.com>,
        Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
        Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
        Chao Liu <chao.liu@processmission.com>,
        Yoshinori Sato <yoshinori.sato@nifty.com>,
        Artyom Tarasenko <atar4qemu@gmail.com>,
        Max Filippov <jcmvbkbc@gmail.com>,
        Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org,
        kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
 <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com>
Content-Language: en-US
From: "Jason J. Herne" <jjherne@linux.ibm.com>
In-Reply-To: <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-TM-AS-GCONF: 00
X-Proofpoint-Reinject: loops=2 maxloops=12
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE4MDA5MiBTYWx0ZWRfXxeP10mi5nXk+
 42JuJ8FBRrSfAYCu/Q4o7d7+QjXR0y0YhLBXkgd3jS+DNmCgivbuDm/ZDSs3n8sSKCYwwSS9DVv
 NgWoNA0BwgCQpVOd0YlV1AgDl+Yi6+o2mDjLiNhVnCu3Iau7D1S8g+hCEDt2R0SHK58wtGi1/5s
 RsoSkQaqsfxgejgt67fHbonxC2nqio0fdE54/b3h309WKFkCPv8jczyyFYUmhEuBrox4FrFb7wC
 PggyxsIl4jVNptZqWdfEykgaHsd7pCNOyBiZc63Zi4tyERkBaOFbTYD+VvrDqVjy3rsEtC+ZxFV
 syR9AFCpfomtfiYbRemhA1VR8Zb4KVxISW6kyI+L2CNsRt3eFSzkaEXWyNO+sowDrmMC7kBgTR2
 5tD9HUyfomfLDqaSHLjYIq6swzt3Ep8j+EJa7WICWbXLEoglP6kNvklJYaBlu+zXSSDds8nl6md
 PTudAuUQifZz7GHw46A==
X-Proofpoint-ORIG-GUID: G5eJ90vsRCcNC-bXB9XjB1i4CkNoQiux
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE4MDA5MiBTYWx0ZWRfX/l7XvQu5FXvY
 757EDCutzJiMhhtpUOg8veUoUv7xm8vDn4iZni2l2SWZhtMOzb10+wUB8ZZ4Fm+mPM+dyZPA8iu
 wv2noNska5/BZi3NZrq0a2WXPePTskc=
X-Authority-Analysis: v=2.4 cv=DJe/JSNb c=1 sm=1 tr=0 ts=6a8450a3 cx=c_pps
 a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=20KFwNOVAAAA:8
 a=VnNF1IyMAAAA:8 a=mY-fmJR8b8s-Z9VvxFgA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10
X-Proofpoint-GUID: WJt7z1CXoN-0E-GSYEQWlRq5_XUQN17s
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-18_01,2026-08-12_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 priorityscore=1501 impostorscore=0 spamscore=0 clxscore=1011 bulkscore=0
 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 lowpriorityscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608180092
X-purgate-ID: tlsNG-4011c0/1787056615-59DDFCFC-04EBC6B5/0/0
X-purgate-type: clean
X-purgate-size: 864



On 8/16/26 3:13 PM, Marc-André Lureau wrote:
> Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> the first parameter from Monitor * to MonitorHMP * to enforce type
> safety. The implementation is also simplified: monitor_hmp_vprintf now
> directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> dispatch via moncls->vprintf.
> 
> The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> cast, they are fixed in the following commits.
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> ...
>   hw/pci/pci-stub.c                       |   3 +-
>   hw/s390x/s390-skeys.c                   |   9 +-
>   hw/s390x/s390-stattrib.c                |  20 +--
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 12:40:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 12:40:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394128.1632942 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJ7d-0006bK-Jc; Tue, 18 Aug 2026 12:40:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394128.1632942; Tue, 18 Aug 2026 12:40:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJ7d-0006bD-Go; Tue, 18 Aug 2026 12:40:53 +0000
Received: by outflank-mailman (input) for mailman id 1394128;
 Tue, 18 Aug 2026 12:40:52 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwJ7c-0006b7-Lu
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 12:40:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJ7b-0091Nc-TZ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:40:51 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8452c1-e002-0a2a0a5209dd-0a2a4507e0fe-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:40:51 +0200
Received: from [40.93.196.63]
 (helo=SA9PR02CU001.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8452d2-b4ea-0a2a45070019-285dc43f991b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:40:51 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DSVPR03MB327264.namprd03.prod.outlook.com (2603:10b6:8:37c::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 12:40:48 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Tue, 18 Aug 2026
 12:40:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=boSSxvf8iN0RMRR9sI2ePDev6KEZBDrAHs4R+JHTboOCmSFS719AMj4s/L9uWOTQ4QLuj6NVJ6VMwc7gJCJLbhQ5LbuD/nNdqRixQTXLXeHyQdlJORllr9p1ZZv2CS4sz4xlFgYHIq+Tzpz0TZRGH0chxUSTA9gUpTOgx2XccXjb4dvaCKvpEAX2UxDMVJM3dRoiRoCIqlTIg9Q5gSc/rSIIxOSjBKIQB4JSyveIOVPzXgaliEyUm3YuIA6HByMNzBs3UBFex3zjDJbzLHGl+po4CHaBXuaz8QHkNcfQua33p4pZVHs0qmps+kPqnycWaGWXdTnryDNdcnio9qL9Rw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Se8YLnfgXv2gKpjSg3NRrAj06ixFg9Xs0ND2aASdIWM=;
 b=f0W3EOkMtHzjmbnDQ1h74Ooh3gsEKLqJqaHVYcXSO0mchWOgOkZqND6iQhSMM+rrO1elUTeX77pCq2Ef7Obbj8cQuvb5fwIkQmtY6TKpQo508Dfo7HPh23FnFtHmdmZV8LT0xE3zSYk6qRJsc0wluYF34akoSViN5VITyxQy8lTZ0sNdricwERuoBufZsa8MZzVog/Bkv77xQ60JmYbzFBHHpoXD9CX/iZ9si1i8F7elRuTcNcSiGMihdm9vsFLQHN67Nq4NFToI0Hc/Fhrxn5zhR8+Dwn0/iF/c+9u1WF5URcB6Edg+aNodu4rLXcu8SrNaJNq5oC+GyvFfq1OgPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Se8YLnfgXv2gKpjSg3NRrAj06ixFg9Xs0ND2aASdIWM=;
 b=VxAI/G/KUi6JV/oGM6kmASjB8Kd3dQ35lcZIsx29u2EXAGkVpiLONcCTxFfuliZA0LzYQ+pAqfIwI08U6Z2EhMZcKQgugqCX3D90BTYzg2tLTFCNSfNrU5XS9qtNF0wpHe8PLryk8xuwvewLdOr1/bLVD5nmv9NwpEI+P8nlg4M=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <d739485a-72cc-4518-afa9-8d2692a225ae@citrix.com>
Date: Tue, 18 Aug 2026 13:40:44 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Jens Wiklander <jenswi@kernel.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
To: Bertrand Marquis <bertrand.marquis@arm.com>,
 xen-devel@lists.xenproject.org
References: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0314.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:197::13) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DSVPR03MB327264:EE_
X-MS-Office365-Filtering-Correlation-Id: df2ed854-2ac1-44a0-fe3d-08defd25ee02
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|56012099006|10067099003|22082099003|18002099003|11063799006;
X-Microsoft-Antispam-Message-Info:
	607nC/FyyIv65khyPwvoTg981PNygNbaMnd6zaA3HMBLzzHVezgoGYErj+Xibz6dm5YMA5yzib4PQyWNDiKeeDjkO3AuMqjBqLkkMOmPRoTyH/0GTSok/ZyLuE0F5YoZFZU6YaWpUB8uB3xR3R+qP621a+DuPKRtWRQ3wdJa7eOaEcARtMM3y4rtjblgOfKR2MQW0+H1CN7QB/L2wTpP8dTNetcSo+OJKgiImlZ/6W6HBIurwF5jnsQW2LsZh+H1lLle0bvoq0B8NoNlgbUcX01WiaY96CcQDwfGOfBOd9Glx5hQUl/2rRYlRQFuKY7+1fPyr3Bh4F6Kja893GwpQ5N6LqJIpwnua2Y9fia9KbKCs3JJ+nw5681h2E7GoZRHS7yZqTGEojGkQzEM9Nl3LS5JDoe5KTCwFJmx5KZgXjBGD2zKowiAhqsq1NcRiP2AIqqF59h8eY7IPTB2FPq+0GCrNGpj45+A66bx9XgU/Miy+pw6qF2dBiTNWyBMH2Z3dbTWf1LqPOBzsjWrYpiGU2o9oKCd0MPBo8TywKsFc3YXmrbzah9fkQh+ucJL7/Hcd7fOcCzrXA/RJ/qN7cVk+hOtXYwgqGAjyVzDY04lQdUR7JHYYbXazpm33I8jC60tx0/bugPoJqxE1GoRLOBjW7x+VzsnO/Qe7tBDnL8YOWI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(56012099006)(10067099003)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?U3FUMG5GYnB4dk9MSkc5c1VzSEpzUXJiOEFjdjd2Sk1id0N1MXFQaXlBbW1t?=
 =?utf-8?B?b3VidUIyZ3dSZ1R4TUdxenAxZUZSSlNvaFFDaWd1dzlXcnBPS1l4ZDBOUWlL?=
 =?utf-8?B?Q1dlckVXTnRVUW1pbEtNaTJlNHhZTlphN291aXVKbE5wNzFYdGFaK01JOFlp?=
 =?utf-8?B?b2Z0S3gvN0N6M0VEYjkzWUhTNWZYQmwvR01McUNiaUhzTUhrT0NiZ2ppQlhI?=
 =?utf-8?B?YkNWNm1lZkhkTEx4cnZHRU1XUWVJdUFlSWNIS0ZUb1pvbm50NEExUFZ3SDVx?=
 =?utf-8?B?cVQ0RmxEbHFiUVRBWTM4V3hjVU5VRmpoc0xxeG5jNlZOS2xpUUF4Zkg4UG5k?=
 =?utf-8?B?ZVhUc0hJWG9oVHo1NEtKekZGRE90ZXZkeUh0dmhLZWpGbnJSbWtRNngvM2FC?=
 =?utf-8?B?N1ZPR3FmMFdYbSszK1JnamMwMHlPTXFubFJFT1FUbmRJcEhUSm53ZUtqZzd2?=
 =?utf-8?B?RUZzZHZveHRYR3NQM1EwdnVWUXpjU296NXplcHhMREFVUExQUlQ0WThLeDNr?=
 =?utf-8?B?YUFxRTBmNUVJNytHYkhkYlJ4TlNnNUJnVmp3VEQrV0ZKYmRaMEpSTXhnaDZL?=
 =?utf-8?B?dWZGRGQ1eHQ3OWFkaG5OcEcwOXRjNXdtK2NTblFvTmlId3ArWmgzVThrOXRr?=
 =?utf-8?B?UksreFIyRFoyT2pNbDJwVU00MWF3OXZEbWxSbVFhZE9XTVhhUHljTlZ6MUxa?=
 =?utf-8?B?ZlA4cFgzOG9Ycm1HTGk4VXhBM1pGd2s3RkxWb0tTbDdMeFZ3UHh0c2pQdnNt?=
 =?utf-8?B?MkU4Y1BwK2FvZzZ3cnZJWHpJNU95R1VLRHNLTVd0SUZ3MDdvVXBEbXdtcDFm?=
 =?utf-8?B?cktIMXpYMnNpNmhaOWUwcmxXbXduZ3pkL0dobmlPdlc2c3pBS0JxR2tmekFw?=
 =?utf-8?B?SlRSbmdFdDAyWVl6VFdRaGpRNi9yRlRPbjVTdlN4bUREaHRjSm5BOXJUWFp6?=
 =?utf-8?B?R3N4Uzh3UmJycytPejY3dHVMOFFwYXR2aUdYVUpmL2hsWEJlYnpzUnZNQmJK?=
 =?utf-8?B?eE5kMCt5VnFEbGdmNzhJcjh5TWJ6TDdrYnBTcTVYVC9EK2ZLOWR2Uklablhx?=
 =?utf-8?B?NUwrM2hIaWR4YjFPcGNWMXJOcmtEVW82UjFaTG1mSGE4RFJPU09qOVFqUjE5?=
 =?utf-8?B?OFRaYWYwWC9Ec01rd1F2NVdMMmMvM0JCdGZMdWY5SW1iTytxMXhuaHNEL3Vx?=
 =?utf-8?B?OGg3MFdxSElNdDAzazJ5QlVkdVBPMjNMQnBjTmhwd2NRWG9OMU1JQ0c1bks3?=
 =?utf-8?B?bHNsdk8vSHYvQUhDdWhhZ1NMY2p5YjFqOWdiVHRoLzF2bUpuMlNldVpCLzZB?=
 =?utf-8?B?bThZZUxDYjFKOTJEeUVnOWZjYjBtdk9MSEtabk1WT2RKZXFvTU55R293cFJE?=
 =?utf-8?B?ZlBpSXRWSEdOL0g2VE9KUm1QRW9SUlVWWndSSlJTNE02czNoVTMxYXNkZ3R6?=
 =?utf-8?B?ejdmQ3lpdW9BWVdFTUR0WXBnY1UxOTFJOVNWZkczTmhIZ0NyQStFQ3dkOFJT?=
 =?utf-8?B?SktTVHhLUEdDYzl2MEY4Z1NpcEVFcmU3QTE3RElRdVFZbVFDakNZcnhwSzlw?=
 =?utf-8?B?MlpUcnlONnlYVXR3WmJ5MFdHZW9Xa1Q4a1ZrL0hOR3JuYjhxNm5abmg0M0xS?=
 =?utf-8?B?Uk1lejB4bkswb2twMjFZcmFXTW9YL1NiVFRlMU8vcDJCWXpTdENldXVOcWZ4?=
 =?utf-8?B?ZGVnRmhkbWRuaGVmWTI3YUlCQXhNMTRxRjBuR0RneUlEaTA1NWIyQzAvVzZj?=
 =?utf-8?B?SDVVeFZ0NmhnaE5CdWF6RW8vYnJDeU85VzU1NWZnTEN3NjlERE11R2RlV0pU?=
 =?utf-8?B?QUtHRkRJUGZpQXBtellUa0RublFiMEZLYWhIRnVFeW9Vb0U0MllNQkxiS1pE?=
 =?utf-8?B?T1RxcnJBNldyNkh1VXpSNUpYdS93VkVwaUFDM0kvNkcwT1QzZ0trWVVRU29n?=
 =?utf-8?B?V3IwcCtjREErYmlaRkNtWjJLbHhLYUw5YXNuQnBQTCthUE9GODZoM2FQRFlN?=
 =?utf-8?B?bm81L0hCWFpRN3M4eG8rTWt4TkVBQzlIeGkzZUtnM1o0SzdveENKQ1EzZnEz?=
 =?utf-8?B?TTgvS2U5STdveUZrdXg1by9yc28vbHAzZ1dXTi9JR1BERG5kZG0rb1k0a1dW?=
 =?utf-8?B?YzFnQnN6OUY1cEptUDVsOGJsNHJ5UE9haVQ4Ylg5dW0zNUcraDgvZVdLbkZu?=
 =?utf-8?B?L1NlN1oxN3QxMzB3UlNCOHJ1ekFMOFVkUUtBU3ZMeG8zWS9wVEJOd1RxbW5p?=
 =?utf-8?B?SkllRWlQT0s2VnM4MTlzVzlWVjVFcUNJMUQ1ZDlZSFQ0cTh3YldablZ1Qkpi?=
 =?utf-8?B?bXh0S0ttUUR5MjdodVliWUFlSnphcmFpTGwxRERuYy8vZmhIY3JTQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: df2ed854-2ac1-44a0-fe3d-08defd25ee02
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 12:40:48.2792
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0iHw9vPJkPbyRQIvOBwv1QQqOYuLz1pQaI0d5nhD90+qUbYOb+ZFhtdDucojtbsH0LqcUJrEROpchqSNphZQy0JAFdQTnjvHaRj8iequsto=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR03MB327264
X-purgate-ID: tlsNG-ef75cf/1787056851-A6AD8AE4-8C3EAAD4/0/0
X-purgate-type: clean
X-purgate-size: 2577

On 18/08/2026 1:16 pm, Bertrand Marquis wrote:
> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
> possible vulnerability.
>
> ffa_handle_msg_send2() copies the message header from the guest-writable
> TX buffer before validating and using its fields. A plain structure copy
> does not prevent the compiler from re-deriving later field accesses from
> the live TX mapping.
>
> For VM-to-VM messages, msg_offset and msg_size are validated against the
> source and destination buffers, then used to copy the payload. If a
> sibling vCPU changes the header and the compiler reloads either field,
> the checked and used values can differ. This can cause an out-of-bounds
> read from the sender's TX buffer or an out-of-bounds write into the
> receiver's RX buffer.
>
> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
> default. The audit ranks the likelihood of such a reload as low, but the
> C semantics do not guarantee that later accesses use the stack copy.
>
> Add a compiler barrier immediately after copying the header so that
> validation and use consume the same snapshot.
>
> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
>  xen/arch/arm/tee/ffa_msg.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
> index 1eadc62870f2..39f561c8237f 100644
> --- a/xen/arch/arm/tee/ffa_msg.c
> +++ b/xen/arch/arm/tee/ffa_msg.c
> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
>  
>      /* create a copy of the message header */
>      memcpy(&src_msg, tx_buf, sizeof(src_msg));
> +    /*
> +     * Make sure that "tx_buf" which is shared with the guest isn't accessed
> +     * again after this point.
> +     */
> +    barrier();
>  
>      src_id = src_msg.send_recv_id >> 16;
>      dst_id = src_msg.send_recv_id & GENMASK(15,0);

This does look to be adequate to fix the potential issue, but you should
drop the ACCESS_ONCE(src_ctx->guest_vers) a little lower down.

With a safe copy on the stack, there's no need to further inhibit
optimisations around it.  In fact, it's unclear why e040b94d0fff added
the ACCESS_ONCE() in the first place, seeing as it was already an
on-stack object at the time.

~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:06:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:06:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394149.1632982 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJWX-0001vJ-Qx; Tue, 18 Aug 2026 13:06:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394149.1632982; Tue, 18 Aug 2026 13:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJWX-0001vC-Ni; Tue, 18 Aug 2026 13:06:37 +0000
Received: by outflank-mailman (input) for mailman id 1394149;
 Tue, 18 Aug 2026 13:06:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwJWW-0001v6-Ij
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:06:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJWV-00976M-Er
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:06:35 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8458d4-2eae-0a2a0a5409dd-0a2a4506e102-28
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:06:35 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8458db-195a-0a2a45060019-d155dd35b82b-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:06:35 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47362928f65so4426704f8f.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 06:06:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b77fa3sm11467116f8f.26.2026.08.18.06.06.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 06:06:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787058395; x=1787663195; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=oDjT4BBN1EzoUHulOiaogMyGrmiXXGVI4o1SGJB33yQ=;
        b=U/Bni5iYLhhViOyJ/WZ6xF+4MSof1Qp9um3Z3oSVpSVvQep5JrWPkkJL4VT3eCnuRJ
         yIDTdwYMhrMHD2BPFtAknv9HRzdw0BTKDMDzE5ld+PhnFPvjkntK3lV4XAoK70BtxVqb
         6b9llU4DnjdKYSXY/6mmAbFcDpYDGkBXWJF/1nj0LGG6UwQ+F5f9GjUsCzICHQzmaZPo
         7d38ufR3LHIprIZNFRUQczNTwfCwo+x9PSv+xcDZLGeZfWEWS8WxKAJucmsFJDr9xVPk
         I7U/BWttt89ZNiAuXPobrgcyJge4cpzDZl9/6iSAFHHVIFqRCMAnlIX1hF4kYcdB6kIW
         g6rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787058395; x=1787663195;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=oDjT4BBN1EzoUHulOiaogMyGrmiXXGVI4o1SGJB33yQ=;
        b=tDNcjo0ljl7xPpgSB6WEAvde6q8cUZtYBcesD1UgKsm9jFDtMpv8ymTWeM52qxrkLA
         ncf8inj+1defqzqUDHqJbZzdRAnoTeRPYmGD8NO7U7y8vGciEBdYzwZSiy+38J2EoNQ2
         4NvRxfdKUo/eBkUG49EXt/pYgvWxV+n6+VYvGq2wov/1+CuMn8EHoK0HmmoKx91NWRrt
         cvzPMflAvyl4SBPpTrwihCNnqgj3Bn4rk5Q0r04wwr8lvcUZW5bBaxlnKPoq2tfrP2dw
         LIoCK0mzNU88DLb2IZCvtZskwiDjvfeQ1qgcyJvhHg83p70SvOSWq7lhGsp5SzA/LXAg
         mikw==
X-Forwarded-Encrypted: i=1; AHgh+Roz0S/g9iexft5pbS4y+pe+qzENKY+HH4fQ5yeNYEy3iwdP+uqXI2e0Wa+Oh7+t9UK0FTAT8Za2z7A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZFCe46+tc72u4dcATBwbfjy8uC6L+v2aNfn//JEUYMweOFjUq
	7jJhqYpPwNFEetpgiFkdFrbtR2bO7WuX5BgkMxLQX8AIKhHOmesyMBro8hKMTBC0hg==
X-Gm-Gg: AR+sD104yCfufzYPz3pj+esoUzSzCCntpkDIRkc6nkLF7WzwdmIkK3laaNboBfm5MwF
	ZbI8iWMLgiR5SgyDRnAxJRXTFQFCSZpeQzjbXLAxr5uuXsee5xMbQNbdiaVDIWIkR1tze7Vlh5d
	vMYBuEU6u32k7fADiXvU7Pqv8GWntfaVdQV9cZgJ+xjGj0+8T7TaBgfjFM0cPFJp+ixLjHT/qUr
	4qxJCvR1Yc+0ouinLAn+kyE1pc0DBcP3gQ2dgGUjJ9ofFDrLIgrTLotjaoR1gv9eyHkDzUhA0TU
	upmFitv90usmjICtF09eZQkOST3el5UGvpnbQa4IzYxPHyFCT779uE6aUl+XAzIpNVu7sb9NmDq
	WY9BU8rDE8hXMGaAUejxVz35rHMOE+eaxgCnqwh0CXMANk6Bn7rH8mtVDd4eAHSRswpLyidWxrS
	KdNBAflESJXZgw56yys58ejvwtJxSe0qJMPS8McMIEnxUbZ9G6XZ/c9+Xyh7BxMosl4Vw8kV4cx
	/TkyN5q+sPAyMEn7792ifBCWNnd+IxOGMx8Ts0RDtxc7qMRKP99
X-Received: by 2002:a05:6000:288f:b0:481:5edd:1b6c with SMTP id ffacd0b85a97d-482a9071f76mr13882448f8f.7.1787058394667;
        Tue, 18 Aug 2026 06:06:34 -0700 (PDT)
Message-ID: <35a08d22-1e95-4e02-a7e9-7f392ef11722@suse.com>
Date: Tue, 18 Aug 2026 15:06:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/3] ioreq: switch ioreq page allocation to vmap
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260420093820.825969-1-julian.vetter@vates.tech>
 <20260420093820.825969-2-julian.vetter@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260420093820.825969-2-julian.vetter@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787058395-FD00977B-BF8C582F/0/0
X-purgate-type: clean
X-purgate-size: 4645

On 20.04.2026 11:38, Julian Vetter wrote:
> Switch the Xen-side ioreq page mapping from prepare_ring_for_helper() /
> map_domain_page_global() to explicit vmap(), to ensure vmap_to_page()
> can recover the struct page_info * uniformly during teardown.

What's after the comma isn't really the main reason for this patch, is it?
Describing this aspect ...

> This is a prerequisite for multi-page ioreq support: the non-buf ioreq
> region will need to span multiple pages for domains with more vCPUs than
> fit in a single page, and vmap() is the natural interface for contiguous
> multi-page Xen VA mappings.
> 
> In non-debug builds map_domain_page_global() uses the directmap for low
> MFNs rather than vmap(), so this change has a small overhead in the
> common case. Debug builds already used vmap() indirectly.
> 
> With both paths using vmap(), vmap_to_page() can recover the struct
> page_info * uniformly, so drop the 'page' field from struct ioreq_page
> and update all callers accordingly.

... here (at the bottom) is fully sufficient.

> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v6:
> - Updated commit message to clearly specify why these changes are made
> - Added comment to say that this is {prepare,destroy}_ring_for_helper()
>   just using vmap_to_page() + v{map,unmap}()
> - Kept proper ordering in ioreq_server_free_mfn(), first clearing the va
>   pointer before unmapping

Yet then you didn't extend the same consideration ...

> @@ -128,8 +129,13 @@ static void hvm_unmap_ioreq_gfn(struct ioreq_server *s, bool buf)
>      if ( gfn_eq(iorp->gfn, INVALID_GFN) )
>          return;
>  
> -    destroy_ring_for_helper(&iorp->va, iorp->page);
> -    iorp->page = NULL;
> +    /* Equivalent to destroy_ring_for_helper(), using vmap_to_page(). */
> +    if ( iorp->va )
> +    {
> +        put_page_and_type(vmap_to_page(iorp->va));
> +        vunmap(iorp->va);
> +        iorp->va = NULL;
> +    }

... to here. (Really we should perhaps introduce VUNMAP(), much like we
have XFREE(), XVFREE(), etc.)

Further the ordering doesn't match destroy_ring_for_helper(), which unmaps
first and only then drops the page refs.

> @@ -162,12 +171,40 @@ static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf)
>      if ( gfn_eq(iorp->gfn, INVALID_GFN) )
>          return -ENOMEM;
>  
> -    rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page,
> -                                 &iorp->va);
> -
> +    /*
> +     * Equivalent to prepare_ring_for_helper() using vmap(). Using vmap()
> +     * rather than map_domain_page_global() ensures vmap_to_page() can
> +     * recover the struct page_info * uniformly at teardown, which is
> +     * needed to support multi-page ioreq mappings (see nr_ioreq_pages()).
> +     */

"is needed" is too strong, I think - surely there would be a way to handle
that without vmap_to_page(), by tracking all struct page_info * separately.

> @@ -309,15 +310,16 @@ static int ioreq_server_alloc_mfn(struct ioreq_server *s, bool buf)
>  static void ioreq_server_free_mfn(struct ioreq_server *s, bool buf)
>  {
>      struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> -    struct page_info *page = iorp->page;
> +    struct page_info *page;
> +    void *va;
>  
> -    if ( !page )
> +    if ( !iorp->va )
>          return;
>  
> -    iorp->page = NULL;
> -
> -    unmap_domain_page_global(iorp->va);
> +    va = iorp->va;

Please can this be the initializer of the variable, for the if() above to
then use that local var?

> @@ -333,7 +335,8 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
>  
>      FOR_EACH_IOREQ_SERVER(d, id, s)
>      {
> -        if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
> +        if ( (s->ioreq.va && vmap_to_page(s->ioreq.va) == page) ||
> +             (s->bufioreq.va && vmap_to_page(s->bufioreq.va) == page) )
>          {
>              found = true;
>              break;

You mention in the description that some extra overhead is introduced. The
(generally) two page walks done here are particularly concerning. Since we
have a valid struct page_info * available here, I wonder if we shouldn't
aid this lookup by recording the VA in one of struct page_info's fields.
Afaics vmap() doesn't use any of the fields, so it should be relatively
easy to determine a field to use for this purpose. The more involved part
would then be to make sure the field (in other struct page_info instances)
is also properly different from any VA vmap() may return.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:07:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:07:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394156.1632991 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJXc-0002Sa-3K; Tue, 18 Aug 2026 13:07:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394156.1632991; Tue, 18 Aug 2026 13:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJXb-0002ST-WD; Tue, 18 Aug 2026 13:07:44 +0000
Received: by outflank-mailman (input) for mailman id 1394156;
 Tue, 18 Aug 2026 13:07:42 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wwJXa-0002SL-1m
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:07:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJXZ-00H1ud-El
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:07:41 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a845913-bab6-0a2a0a5309dd-0a2a450298c4-16
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:07:41 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a84591d-6ca4-0a2a45020019-d155dd2df147-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:07:41 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f7872abb6so2604507f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 06:07:41 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482aa084a64sm6663200f8f.17.2026.08.18.06.07.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 06:07:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1787058461; x=1787663261; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=XWB74GLQjah/HiO+IV8IQxonLXtBV9EkrjdxoXyQbgc=;
        b=TUur1ftU7U8ffrZnky49+/gwBHcO6U9EuZEkVYjtx3Izd1Nho7OYs9dZrR12R6tMtO
         jkEJo3/Q3X6t6+eFGf4vdQu+GZgD4ouXiu2vQOOanTFqkssrdfM7RVThmbeLfcfPpMYx
         +gSTNdHkLdRFpusiTrZ9NQhhc7AprJ3lek9Fc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787058461; x=1787663261;
        h=content-transfer-encoding:content-type:mime-version: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=XWB74GLQjah/HiO+IV8IQxonLXtBV9EkrjdxoXyQbgc=;
        b=Ci2jhOvqjxQZKJdUD5afUkuZvtXvws0zJhT66fJ6v4s3cYUJcH4ZrdsgueW7FxN2Ee
         6nyDzrmNHGfVw4rR3c/JLrFZU9V39FXeAehnHfFpf4hgRJQpbl60g+RumWrcUGMYHRVV
         7SjNVgEa9FMjZG8w5hqvMtaC5FG7WRFUyUq/txP3OAYTyQUC9jD2rB7oFKzWNk6W/2Oh
         KldrQdASeKgnb5aGnuwdsM0z4yuQFwYsFolXOhQUqkRlNLCilR1RewvEY2z+QrSYlF3Y
         2h2CXJ2i+368pcHH1e69kyIPRVNPKfQflkr7n0BwtexEFvShiXnAdWm8jsRzsZJZulVa
         vJTw==
X-Gm-Message-State: AOJu0YwmagaYNv/veKAdyVWHLPJ6K/ZYpSHjVMLEtaC2PTxoZooIQIEc
	uIblXW189qzQeZdjltnpe39JeIl3pBMIOQw6AuJwosbiDX/FKjwGcxixwjH373vd7BynC5BxODm
	MG3kOIIg=
X-Gm-Gg: AR+sD11ffmiXIwuRYY5fj6gC03WtGSLP/50JiBzQscKyTnf2/4B77QQxqlr/buDJrha
	xCo/RSblusFnWbEJ9n+l5XOplMGr53bSNTjSsvCX0el6vLPWBWE6fheY016/T3HpUEgUlgEGgoB
	RyQX+ZVTIg1Ev3avdmlQ3efxKSoN4txNTHnGxEQ3xIu31v3t0yDgtskExDXQbYOHzO6Mfx1Dc09
	Z5QTzzimBnM8CG7bw0HX+qpHjlSZTGJE9EuD7LCwrDxGr80Wrp0+c/00Zj9jS9Uh05BiTHertLO
	zSk5oNiSzqLqvVVlS7DMlSf4G2JvEl/ggok0Xh0T+cjVjvViSNi9Sm18GQLAPC84bADamAFmRKp
	ibUb77dowZWmSXfLKPn5JP3dFC07OARkUhyj1idrdlVx9jf+sCCZZ8yywdHfYVtp1kTR3jP2EGz
	tK7bt/wxyJ6BP6wJzyjITkizG1YsV3sFnToS6EYZFRB8jLd2JUfEVZqKWunA+a0teKwT104jtoB
	eM4Mf6ObKnSun4x/dAuGBZAEaeuwM/5xZ/I/+0=
X-Received: by 2002:a05:6000:29cc:b0:47f:773f:2d68 with SMTP id ffacd0b85a97d-48160738c19mr41645267f8f.16.1787058460644;
        Tue, 18 Aug 2026 06:07:40 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated panic()
Date: Tue, 18 Aug 2026 14:07:38 +0100
Message-Id: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787058461-67ABD2AC-8B0246B9/0/0
X-purgate-type: clean
X-purgate-size: 2541

Panicing in the case of a timeout turns out to be about the worst possible
action Xen can take.  It leaves all other APs waiting on the condition
variable, some in NMI context.  As a result, they fail to be shot down and
dump state for kexec crash analysis.

Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
excess of the of the arbitrary 1s Xen allows.  This time is spent in the WRMSR
to load the blob, and there's nothing the system can do but to sit and wait.
Despite the delay, the system as a whole does survive.

Microcode loading occures through admin operation only, so get rid of the
timeout completely.  It does nothing but make a bad sitaution worse.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/cpu/microcode/core.c | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 9b8d1e09cb98..12edd52fee87 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -52,12 +52,6 @@
  */
 #define MICROCODE_CALLIN_TIMEOUT_US 30000
 
-/*
- * Timeout for each thread to complete update is set to 1s. It is a
- * conservative choice considering all possible interference.
- */
-#define MICROCODE_UPDATE_TIMEOUT_US 1000000
-
 static bool __initdata __maybe_unused ucode_mod_forced;
 static unsigned int nr_cores;
 
@@ -422,17 +416,7 @@ static int control_thread_fn(const struct microcode_patch *patch,
     /* Wait for primary threads finishing update */
     while ( (done = atomic_read(&cpu_out)) != nr_cores )
     {
-        /*
-         * During each timeout interval, at least a CPU is expected to
-         * finish its update. Otherwise, something goes wrong.
-         *
-         * Note that RDTSC (in wait_for_condition()) is safe for threads to
-         * execute while waiting for completion of loading an update.
-         */
-        if ( wait_for_condition(wait_cpu_callout, (done + 1),
-                                MICROCODE_UPDATE_TIMEOUT_US) )
-            panic("Timeout when finished updating microcode (finished %u/%u)\n",
-                  done, nr_cores);
+        cpu_relax();
 
         /* Print warning message once if long time is spent here */
         if ( tick && rdtsc_ordered() - tick >= cpu_khz * 1000 )
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:12:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:12:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394167.1633000 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJbm-000498-O9; Tue, 18 Aug 2026 13:12:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394167.1633000; Tue, 18 Aug 2026 13:12:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJbm-000490-KV; Tue, 18 Aug 2026 13:12:02 +0000
Received: by outflank-mailman (input) for mailman id 1394167;
 Tue, 18 Aug 2026 13:12:02 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwJbm-00048u-2R
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:12:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJbl-002nBZ-FX
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:12:01 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a845a18-8faa-0a2a0a5109dd-0a2a4503e70c-10
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:12:01 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a845a21-fae8-0a2a45030019-d1558030bd03-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:12:01 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49556f97a9dso32690385e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 06:12:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b783c6sm12635954f8f.31.2026.08.18.06.11.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 06:12:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787058721; x=1787663521; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=UhCCliZcXnxsXYHFMkzEGMsk4inzeOQruIWoWIFumDY=;
        b=ZRzG49y8Ns2GrHJLHdGyrJmcY7Zu7rmvn3P1kx7z2u3kG4QzzNL8xo1XbP31+Vyf/u
         0YA+KFL/ZkTnnECAMeHmRhmwcJxznvf7RjzAtk8y3QL8gsa1cowSrXYxKd1qyjOWPx2R
         wQYCTF0Rd+Q8eJrwk5TkhBBeSPgFGsx67psFBedDsicLix7CsAUfGv8CCb5OKSDW5fwc
         tZEdIusFgz/SIHI0fiiAkQH1AtB5+/B9TkUsoVB5rCZRv5Frf0MMSRCDxK1PJsvIzHvr
         UtRukbk9C2+HkXAo72qHJfi29zp0o9TyFnJGmkvPTZKfUYZDyTtoh2FAit17jo/cdM8Q
         pXjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787058721; x=1787663521;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=UhCCliZcXnxsXYHFMkzEGMsk4inzeOQruIWoWIFumDY=;
        b=DNcIKmdPuD2rynW7/23XvhSqyTwKPxUH1tsNKK5muIeba43lQdu4KduFkbv+YcKoE5
         JEsL2cbCFefBdoyZyPGex6jjlPCOh1223LruTPU2NNAIuVsr1pv1fONJKE7W+gl9CWwC
         lY3iJANBCBhysZeoLUbrx7YrhnboFDfFnf/MubM3+UjU+h9W3t61wxjVqvq3yD+uVFCi
         fyyHAU20GX8geOSTLX4JvxhkeEY6zuwhXZAAsVQYxP5vE4ua1EgpqbWopkU02cdhT+Td
         QeQE56Myj3a+v2qvOnw8I3dTU4m6XQCP48Hybr9qbUERRpJ8U/lkqreB5ptWb18Zb8QL
         w4aQ==
X-Forwarded-Encrypted: i=1; AHgh+RpntNj5z0rfvNWhBS4vwEUxJY8PPTSn6IWBTgbjinwRj+27edeSS61qRhGjXIBKUsHVH7rs3txvx/8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw24w5w1sW9RiXCj9c0wr5xXVy1pi93H6EDiqrogsDiBsq2ixN+
	WxuT9dF5ZMTb1eR7eS6/hoNcAj2Iav4RTrSY2EN7pnLPrPRKl01+apNpbC4LqoPm4zML80RgPYv
	GVBvemA==
X-Gm-Gg: AR+sD13ZrtWw+Jf/gKHtU9l8U9HkveSv2ZSQKHLmDcU0c+sE14PC/HZno/KvXhwK3xK
	hs2eSR+hy3wdVC6NAA07L46duMi9deePlMzFQq8ofvWMCQGnCoxKo79kpDcBt+/3Q1Sr2tvpPNL
	WdAElvF5ETfjPZpyZcWQChtcoVLbWiNthScXxC1kvfWge7WE+zDJ0pXWXcxZHhhowPUkNbtiDqA
	HDyTTnnWecpoUlMBjOJ+w1rcE7wSPFjLqR49dszs/fdqWvwfUl9O5+10rkQjhnQD5+0AgwGCs/j
	3xDmg17gVD5AdfCOn/56o1DI+3cJ/eZ4eEdJwC5gsNUIOM2UC01Y41auum5rdWIl0G3oTeHbR9K
	p2qRoYj9mhZtSNc4mIwxrfJBP98cdVPkzXc0YibZGRl2N8hiuLqk1xaPC4FYW+qt1eMdfpEL2ZE
	lbQKDOsUNEoObRFFbqejKue1MZ5s3OxaIH5+BsGkcKjmkE/lvcjPIf/z3WuWg9pVvrHV2pvBqR3
	jJEGNwgkfNe3SGceRpYofT9bvjhu62/T7UMYMNjQ3ul223DuqVS
X-Received: by 2002:a05:600c:540e:b0:495:6a50:3fb8 with SMTP id 5b1f17b1804b1-4999fae4f89mr155216325e9.1.1787058720677;
        Tue, 18 Aug 2026 06:12:00 -0700 (PDT)
Message-ID: <53491489-ba60-4176-80c3-45b7e790e8e4@suse.com>
Date: Tue, 18 Aug 2026 15:11:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 2/3] ioreq: Indent ioreq_server_alloc_mfn() body one
 level deeper
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260420093820.825969-1-julian.vetter@vates.tech>
 <20260420093820.825969-3-julian.vetter@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260420093820.825969-3-julian.vetter@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787058721-778C54E9-28AD151A/0/0
X-purgate-type: clean
X-purgate-size: 1613

On 20.04.2026 11:38, Julian Vetter wrote:
> --- a/xen/common/ioreq.c
> +++ b/xen/common/ioreq.c
> @@ -277,22 +277,24 @@ static int ioreq_server_alloc_mfn(struct ioreq_server *s, bool buf)
>          return 0;
>      }
>  
> -    page = alloc_domheap_page(s->target, MEMF_no_refcount);
> +    {
> +        page = alloc_domheap_page(s->target, MEMF_no_refcount);
>  
> -    if ( !page )
> -        return -ENOMEM;
> +        if ( !page )
> +            return -ENOMEM;
>  
> -    if ( !get_page_and_type(page, s->target, PGT_writable_page) )
> -    {
> -        /*
> -         * The domain can't possibly know about this page yet, so failure
> -         * here is a clear indication of something fishy going on.
> -         */
> -        domain_crash(s->emulator);
> -        return -ENODATA;
> -    }
> +        if ( !get_page_and_type(page, s->target, PGT_writable_page) )
> +        {
> +            /*
> +             * The domain can't possibly know about this page yet, so failure
> +             * here is a clear indication of something fishy going on.
> +             */
> +            domain_crash(s->emulator);
> +            return -ENODATA;
> +        }
>  
> -    mfn = page_to_mfn(page);
> +        mfn = page_to_mfn(page);
> +    }
>      iorp->va = vmap(&mfn, 1);
>      if ( !iorp->va )
>          goto fail;

Please would you then also add another blank line after the new closing curly
brace? (Based on the corresponding ioreq_server_free_mfn() change having been
dropped, I'd like to wait with ack-ing until the 3rd patch is in final shape.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:29:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:29:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394175.1633009 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJsx-00069S-4J; Tue, 18 Aug 2026 13:29:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394175.1633009; Tue, 18 Aug 2026 13:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJsx-00069L-1E; Tue, 18 Aug 2026 13:29:47 +0000
Received: by outflank-mailman (input) for mailman id 1394175;
 Tue, 18 Aug 2026 13:29:46 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Bertrand.Marquis@arm.com>) id 1wwJsw-00069F-1s
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:29:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJsu-009BaM-OX
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:29:44 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a845e3a-bab6-0a2a0a5309dd-0a2a45069ab2-18
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:29:44 +0200
Received: from [52.101.72.8]
 (helo=AM0PR02CU008.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a845e47-195a-0a2a45060019-3465480879a1-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:29:44 +0200
Received: from AM0PR10CA0008.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::18)
 by PAVPR08MB9331.eurprd08.prod.outlook.com (2603:10a6:102:303::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 13:29:30 +0000
Received: from AM2PEPF0001C716.eurprd05.prod.outlook.com
 (2603:10a6:208:17c:cafe::a5) by AM0PR10CA0008.outlook.office365.com
 (2603:10a6:208:17c::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 13:29:30 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM2PEPF0001C716.mail.protection.outlook.com (10.167.16.186) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Tue, 18 Aug 2026 13:29:30 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13)
 by PAWPR08MB10946.eurprd08.prod.outlook.com (2603:10a6:102:46d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Tue, 18 Aug
 2026 13:28:56 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0339.007; Tue, 18 Aug 2026
 13:28:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=OjYYVHB8OBpR5dlVXVQFy7QOSvVZ7ZhRLMXmAWJ1WbYoEAjRFRmzKrBdHV3HYMSbu+z1EE5JAehFUYwIRRrpyODN5LQt37XuFqvKWeINeweSs+3kT87mAt31VDJX6OwivL27CT1gQ32UCuCRnguK3Utu6wM9fOyl8O6czz4sPPFHneloJ6X025oyvsPV2jATmFjXNb7EBPsxzAYLrHLeo9HpN5kgzoWrKlwUg5pbdV6IqX5l4+TYc6/Yzbvr4t75+u3Su1Xon5tsc+hnUQY5y6CGCJyr3f7gDAS2UDrTLRcttkIBj/7yXpgDPk895zrDNSQMuOSBaGQF7vhqAsybrw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vs3t465oTgOJ/gmIgHwch4LThzCGUM61rplAOjWbpkI=;
 b=ZINnH2K6N2eDitB6czqg/6kGGZ+Dv96v8IRg7KYOTxtlQzx2NDlqBCi61RDeWv6WcRhjOD465HLGhp60cot2BucF5nHyWZJmW2hysCpnmshFzVTtTWR6lbxSf5Rsy43pjBFUSoKfUKiWZ56NzS4sFdT0f8yubz3VqZiIMJGbTfe2k4uVdzSuVGBhFpmk8TH3RFHSWE54rzngTcQ6get0ePWDjCo7oUr6LbxsQ6ICaBCuf807I1vhe1yr+21q1Zr3ASxAwGLKtC58Xb+TPWhVL5MRx5sfNWUGDZFzwKyiR+hZolhkZk9AinGopWpHhKlKQxvF1ZR8Jjbi+Upf7UIWog==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vs3t465oTgOJ/gmIgHwch4LThzCGUM61rplAOjWbpkI=;
 b=FxeAeNjF5+QwQgdjD2VD/qU0UUi12kmY7gKd5xwxsitwGuQqIhvm213St6HQIdWCeZ982zh87Dv+R39SowVIcYx9t4HsYcz4k0YQnJfFel9zhQLnCaojHHwDR8b/LayVOkkjVZLXR+lO/TzCKPBiBxbGzioE/dU6gfYpYbfiqSY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eeViMAdKINJPIeHAZD/vXuTjqFcas8JGILz87WGERhDmdqg6nbGgwj/u6BQ86ZnbjKDFseUhPlhQQWjTMaFdfp4ShbQVaMZmcZjlaCJx+rNpqQa12uYf3fRfn1hl37Lvg8RsXyOHENlUqnmhQTR1cAWaPifxan8zyfA+UCH/O647J4ms6OromY/oQEjZFYHzJ1ITbVUrh5p188W8iMU1A0fQJ5el7HxZwWdOEs2sshMqeGAWPg5OyCmMOZtMxdSxeobvVQvtNB48qJHKgw9E6adNmL/f4/PkvGmQetIlJoDxG9iqYznrbA7ivzvhHuMCSCYyM465aRqUWvA2SykmQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vs3t465oTgOJ/gmIgHwch4LThzCGUM61rplAOjWbpkI=;
 b=pBPqRsXoHpX+ZkWVrx6unGGQczctAYkiM7jbPCJ1Prwp9+0/EtESsBt7lIIrJ5ABZghmR6eiUM/r9yAq5B6eX3ZSRL8zFxQf2r2wgJRYpAj2qJPU+PhmFYtmnF43DRJr1JIsw7Fk3nTCRvScPBGGzmlt5aCSORHKmcv9gYtudtVg1/0pbR2l6dm7QmhBnKk5sBmE2k6AjKK2QiJ3hjONZ2hvBxq7NPGKV4IVddg1EZlpGTbjibTY8NZZOyNcntGFhgbQWbcgm2c40tBijFDB4cj7ZtHXeE+QHo4zGLexTMVdqoktSui3rGuZc7mhTxl/wnSzfAon3QAjK8qqTyYbnA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vs3t465oTgOJ/gmIgHwch4LThzCGUM61rplAOjWbpkI=;
 b=FxeAeNjF5+QwQgdjD2VD/qU0UUi12kmY7gKd5xwxsitwGuQqIhvm213St6HQIdWCeZ982zh87Dv+R39SowVIcYx9t4HsYcz4k0YQnJfFel9zhQLnCaojHHwDR8b/LayVOkkjVZLXR+lO/TzCKPBiBxbGzioE/dU6gfYpYbfiqSY=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Jens Wiklander
	<jenswi@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Topic: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Index: AQHdLwt9ezGusG27iE6LBf89mJZswbajv3sAgAANaoA=
Date: Tue, 18 Aug 2026 13:28:55 +0000
Message-ID: <7F03E2BE-44A0-41E9-850C-8480CA0C8F0D@arm.com>
References:
 <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <d739485a-72cc-4518-afa9-8d2692a225ae@citrix.com>
In-Reply-To: <d739485a-72cc-4518-afa9-8d2692a225ae@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3864.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PR3PR08MB5593:EE_|PAWPR08MB10946:EE_|AM2PEPF0001C716:EE_|PAVPR08MB9331:EE_
X-MS-Office365-Filtering-Correlation-Id: d2c55618-033e-4496-d50c-08defd2cbbf7
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|38070700021|10067099003|4143699003|11063799006|56012099006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info-Original:
 JMeLCeNJoiZH1Q0WUZ57p02tL/+tDvCd1VcL/z87qcX/OfR141BfCCu6abULGcBzA+BtSdGI3dsHHmIEvVhLif02hI+HIN5Aovf8Fq8vjy8lq46j552c2TorT+c9Md3jZwZbZwrYEqSPWFSb6QRoZORBDf4+/Q+JfThULc7UXJFv67uK6kBSQBg0+MH0kujHT6v9ppScHGPV62AceIFq5qqd3yAQarxJ9aUcrsjmzqrBVXG/IoLISAV5ppVO3xwQeSXTZaum49BBIXozpKDelVhjMrCj2Q7T1cJ3AqatkPO55AMmxzfHomd2mmzr6lCgcts8RM/JKEGdEIBrFYTpYfG3xEnxyenNjksNQPTrEOqdlVAWgFIHEKGQfsB6Rz6alSxYSsWex6rj91eJgGDMi5FhwW75CD6ZQrLBw7fR3BCIx/5Vs9NdEdCyboW12kzqSxVUxFqWJr8sNAq9+9DmpRwWgmwX7GWeTX0d7IZTmtDNiT8FnQkJaMctUHSkm2F2FsKVfO/avKPYPsipoauubU27WRIACQm9CovYSrxmLBKH9zxMYkOgz4PsdsDzSG5dE7jAfcZB0Hscq7dC2Zc00ZYjn2Oq/sMzROW9tgzh+VCJdrS/GDsN2i54VHOG8khP3MMvQcuZlmubR1KjOIXz1rHs+FpQvW3bSDesvrmDVn4wo8u1uMtp1xi964Z12G/W9jetxiLDFFp+Wa01C2NIwzPs5x33ZWAt8LmWfPxq61Q=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(38070700021)(10067099003)(4143699003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21552626E6253245B95B7B2D0DA10A9C@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Exchange-RoutingPolicyChecked:
 o5zc88oRZQNectCg2jznTnOn3veyJTT2PnQeGejvhRwIpOp20xDDtbzCbqX0UUVMa1Xhf6nerEg6Pl9Sgl6MOReK9bcCGKifiDY3YiNfDp34QsvSo4wJ/WCzPvoh18VTb31ITU94QGXvMhY9FBnPpk+cGfv4RP1aez9Ndcw4WkxpXH758bJMNVcpsh0lekLeMm5hvIjZfF7Y4ni7BjpFDEChRGB2wuhB/sondVHReLKrPNomQ+ZUrxwNkEwMDUrEIFRlL7FaEmsUEUT747a2oCMns2ICEdS1MLIAPYkXGerGacAzlcADl1tmOYgfR9SOaOV1qRwr6IjLBk4quYM1ig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10946
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM2PEPF0001C716.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	acf944ce-c3c9-4b3d-8978-08defd2ca749
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700016|35042699022|1800799024|23010399003|14060799003|22082099003|18002099003|11063799006|56012099006|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	jsA8c0KtAZdOw07RgJSJ3WMx+Th1Yfg/cm9T335+xQN1TB3nTnTORNe53Vf10W0eDJkM7qNStelxj2JzDJfb+iPvBmDZtA5dLJy34zaDk+mnfo+q9Af41Hw5tadZGaDsHrUfZPntPOFa5cTMVXQJfk9E12fcSRSm8YuovHqNX6P/kvRHOumfFa6PIeCJRSfcSrtLQDOFhsc27ywbzLayCJ8VQAKCYp7Wu6L+7Uvi90G1BILHVoDQbEFvr3JvOv8bSRt0oJ4sxQJ7obeLAY2R78VPRchn4//PghLFnnHAQPQgLoEbX66tiMldFuD34HbhO8kHBwom302RL68TwVbq0R72VfUg04j5De8EpO7fffxtd1/u/w/sA7UTzjUB+OiFUFsZtO0G5LpOxRTkYM0rZa0EOZMSSnJZAVAV58H83x0UVq/FlN8/MtPcbgQNqBaFVbpsZEDhBGbFkOCXDl4sKJ1MMcdXPZjQUVHeQhV87Ck9XvXqQtVkWoiDaH2YYw5+LuXXklw0hQKgICVrOkhgWnTF7bttCJEthZtYtbKekEoiKvziJ1bl68K/LhQ1jrNIDYhM6kmeXksscYZGHv/lBlg3sea6z2pRH6MrHOjkTa3zM7jCrdAStqGtl94KljXfHTIriGdCFvgrpPpK5FrKbqq9K+9PlxxUKY3WFJrotq2fudCPRGKrbJctzWCKdQ0/WzrX5b6npnnjOkFtzwf3Nw==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700016)(35042699022)(1800799024)(23010399003)(14060799003)(22082099003)(18002099003)(11063799006)(56012099006)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	9iHGGkLIVmAlRk3JVq3dGypE7bXoQpv7G5emIzh7wShh0eWp/h7O7+x012VGZXhKyT+A2Hv1UGMtkGMzt7QrYOeBcd0tDAdn70VxdrmQodLNb6ZFTw9nNEYCEbsKQZ/sBW+TMFMp3HIoiXgWjJKROmvoiILIRJg5J/STEQXqTlpc8bhkXataWFYFQn3QD+Qhi/A5qhjRToLK1NBk8SburSYfl5+8ymLMwALyGKT7rM1MdCHob9CnNO2PpiwVqAAHft0imO9Kgtxs3nwQxPVOE74Uz7Q9095DCeYPpwmthD+Yk2vM7WPVdmM3eT50WbUxfT4knHiX3L0Hh5n1MUJsEm53cmQWnSSd7rytjfRWRVI6hQQOi7ZD3ZfXHNXcT9C71DB52YA6KqdViLheJIl2kOxfGdttLnuqTmNbbjz2HoKR9X97oPPaprDtYVrCYLLd
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 13:29:30.6206
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d2c55618-033e-4496-d50c-08defd2cbbf7
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM2PEPF0001C716.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9331
X-purgate-ID: tlsNG-16d1c6/1787059784-FE67277B-8B2B9373/0/0
X-purgate-type: clean
X-purgate-size: 2993

Hi Andrew,

> On 18 Aug 2026, at 14:40, Andrew Cooper <andrew.cooper3@citrix.com> wrote=
:
>=20
> On 18/08/2026 1:16 pm, Bertrand Marquis wrote:
>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>> possible vulnerability.
>>=20
>> ffa_handle_msg_send2() copies the message header from the guest-writable
>> TX buffer before validating and using its fields. A plain structure copy
>> does not prevent the compiler from re-deriving later field accesses from
>> the live TX mapping.
>>=20
>> For VM-to-VM messages, msg_offset and msg_size are validated against the
>> source and destination buffers, then used to copy the payload. If a
>> sibling vCPU changes the header and the compiler reloads either field,
>> the checked and used values can differ. This can cause an out-of-bounds
>> read from the sender's TX buffer or an out-of-bounds write into the
>> receiver's RX buffer.
>>=20
>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
>> default. The audit ranks the likelihood of such a reload as low, but the
>> C semantics do not guarantee that later accesses use the stack copy.
>>=20
>> Add a compiler barrier immediately after copying the header so that
>> validation and use consume the same snapshot.
>>=20
>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/obse=
rver-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx=
-buffers-ffa_shmc-ffa_msgc
>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>=20
>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>> index 1eadc62870f2..39f561c8237f 100644
>> --- a/xen/arch/arm/tee/ffa_msg.c
>> +++ b/xen/arch/arm/tee/ffa_msg.c
>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *=
regs)
>>=20
>>     /* create a copy of the message header */
>>     memcpy(&src_msg, tx_buf, sizeof(src_msg));
>> +    /*
>> +     * Make sure that "tx_buf" which is shared with the guest isn't acc=
essed
>> +     * again after this point.
>> +     */
>> +    barrier();
>>=20
>>     src_id =3D src_msg.send_recv_id >> 16;
>>     dst_id =3D src_msg.send_recv_id & GENMASK(15,0);
>=20
> This does look to be adequate to fix the potential issue, but you should
> drop the ACCESS_ONCE(src_ctx->guest_vers) a little lower down.
>=20
> With a safe copy on the stack, there's no need to further inhibit
> optimisations around it.  In fact, it's unclear why e040b94d0fff added
> the ACCESS_ONCE() in the first place, seeing as it was already an
> on-stack object at the time.

the ACCESS_ONCE is protecting the access to guest_vers which is not on the =
stack
but a value on an internal context accessed by all VMs.

You probably mixed src_MSG with src_CTX ?

Cheers
Bertrand

>=20
> ~Andrew




From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:35:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394183.1633019 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJyc-0007lG-Px; Tue, 18 Aug 2026 13:35:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394183.1633019; Tue, 18 Aug 2026 13:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwJyc-0007l9-Lc; Tue, 18 Aug 2026 13:35:38 +0000
Received: by outflank-mailman (input) for mailman id 1394183;
 Tue, 18 Aug 2026 13:35:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wwJyb-0007l3-Hx
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:35:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwJya-00Bppu-Uh
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:35:36 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a845fa8-e002-0a2a0a5209dd-0a2a45058bcc-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:35:36 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a845fa7-4cb1-0a2a45050019-aa0a817cdb97-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:35:36 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-655-0LsnsvebM_iuqnqKt0D47w-1; Tue,
 18 Aug 2026 09:35:21 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 2A1FC18011C5; Tue, 18 Aug 2026 13:35:14 +0000 (UTC)
Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.116])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id D3927180034F; Tue, 18 Aug 2026 13:35:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787060135;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=NcMcfYcJnP5pSepZPUlbKT/IGaqv3YNUpR9si4mBH+Q=;
	b=UsgJ3vcDg/jEc6Kj6D4UGh+sCDOXeYpgxSAkwBmWKQ41ToaP8lJgQ9Xhd1vo46Jk+sCc0t
	hZ7kLwxdH2NlhQgVerTB6lQ1hXJXUnHGw7aQqTjYOHh1YsHtva/Z2S7y2ricPgCZDHlXan
	ZolPkL8MhmOaKx2IocDUemZgQvh/yYQ=
X-MC-Unique: 0LsnsvebM_iuqnqKt0D47w-1
X-Mimecast-MFC-AGG-ID: 0LsnsvebM_iuqnqKt0D47w_1787060115
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Tue, 18 Aug 2026 17:29:29 +0400
Subject: [PATCH v3 63/74] hw: convert device-local PropertyInfo definitions
 to use qapi_type
MIME-Version: 1.0
Message-Id: <20260818-qom-qapi-v3-63-24b8bbbe3d86@redhat.com>
References: <20260818-qom-qapi-v3-0-24b8bbbe3d86@redhat.com>
In-Reply-To: <20260818-qom-qapi-v3-0-24b8bbbe3d86@redhat.com>
To: qemu-devel@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 Michael Roth <michael.roth@amd.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
 Phil Dennis-Jordan <phil@philjordan.eu>, 
 Alistair Francis <alistair@alistair23.me>, 
 Peter Maydell <peter.maydell@linaro.org>, Keith Busch <kbusch@kernel.org>, 
 Klaus Jensen <its@irrelevant.dk>, Jesper Devantier <foss@defmacro.it>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Halil Pasic <pasic@linux.ibm.com>, 
 Christian Borntraeger <borntraeger@linux.ibm.com>, 
 Eric Farman <farman@linux.ibm.com>, Farhan Ali <alifm@linux.ibm.com>, 
 Matthew Rosato <mjrosato@linux.ibm.com>, Cornelia Huck <cohuck@redhat.com>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Ilya Leoshkevich <iii@linux.ibm.com>, David Hildenbrand <david@kernel.org>, 
 Alex Williamson <alex@shazbot.org>, 
 =?utf-8?q?C=C3=A9dric_Le_Goater?= <clg@redhat.com>, 
 xen-devel@lists.xenproject.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, 
 qemu-s390x@nongnu.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=8761;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=M1ZK58SCDRwPvhT0ecKJ8jMYH52yLNqHGDUugt8emrA=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqhF9z4CkZw2HKM6dzp+UwaFJyFhTU2u5rvrSYf
 BXDoaKYjlqJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaoRfcwAKCRDa6OEJdZac
 5TOdD/0Q9eYTxC1cXJssQBTteyZwUW7EKCWsS/xXRovKEx+Kktno7QRX7UT2fLJQQIvHlkwM+LH
 lTxEFpG1pm45KOEQgHwxUP2e7clXlV5ri74lCFTIsYgXuM0wWqJ9FUXZNpM03icIJeVql1Bev9w
 VcgWpRv8aeBjn0jRvYSyA1qY+nRfUd8KT9SR/9elfGTCFA2LWnu1iFDi2pm42I6+PGmdUrDIn9L
 eBxdg5XNFKSYJ6iuNNFyc+wn4CAgXD6t4SF1c7YbZPUMEahGoXHtNN7Dyh55F1kmPAPJXlU60Ly
 QNs7ECUtW+o7mOC+7c07FYFgZGwAtXzgZRP1qrYFaBq3rkNvWTDHz4YIE6HN8n3WzLm0HjJJaLJ
 /xG/hOfgKpwiEYKhsyZnaWRAugrzFMy3HuAjXNzenokQYpPZbEbbEkcX7ThHth5w/+BBs/53IF1
 oMoicdK6lxhlpRpcARnNOH2vgZhUcgQj914/RpTsKKBceYwvG3/w5JRf3nBRlDrsXahjo9BenyA
 Q+theYaAaOmLZ9BBDU9bKh6U5pOZOaWGiQiDEIO+hc0dQXibHwJmO/NvuUDtDO2VwR8GWGaym9B
 2tiD5+1HFd7vv5FAdTQR3sdBm0q2neoHk9GwmWJARYpW9nEOxJUx180AQ9xYvW0vr+PRvMknpHD
 0URkHEcRSEyYjmQ==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: whWz0eEuS4WCv6OXIQ8Vz9HeXyeCINJahOT99l2Qw-M_1787060115
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787060136-F48A62A1-FCE76BB9/0/0
X-purgate-type: clean
X-purgate-size: 8763

Mechanical conversion of PropertyInfo definitions in device-specific
files, replacing .type string with .qapi_type pointer to the
corresponding QAPITypeInfo. Except "display_mode" for apple-gfx, which
is a string of a specific format.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/block/xen-block.c       | 3 ++-
 hw/display/apple-gfx.m     | 3 ++-
 hw/misc/xlnx-versal-trng.c | 3 ++-
 hw/nvme/nguid.c            | 3 ++-
 hw/nvram/xlnx-bbram.c      | 3 ++-
 hw/nvram/xlnx-efuse.c      | 3 ++-
 hw/pci/pci.c               | 3 ++-
 hw/s390x/ccw-device.c      | 3 ++-
 hw/s390x/css.c             | 5 +++--
 hw/s390x/s390-pci-bus.c    | 3 ++-
 hw/vfio/pci-quirks.c       | 3 ++-
 11 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 474c12fe4ac8..d9721c565c5f 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -29,6 +29,7 @@
 #include "dataplane/xen-block.h"
 #include "hw/xen/interface/io/xs_wire.h"
 #include "trace.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 #define XVDA_MAJOR 202
 #define XVDQ_MAJOR (1 << 20)
@@ -663,7 +664,7 @@ invalid:
  * https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html
  */
 static const PropertyInfo xen_block_prop_vdev = {
-    .type  = "str",
+    .qapi_type = &str_type_info,
     .description = "Virtual Disk specifier (d*p*/xvd*/hd*/sd*)",
     .get = xen_block_get_vdev,
     .set = xen_block_set_vdev,
diff --git a/hw/display/apple-gfx.m b/hw/display/apple-gfx.m
index be0061b9db25..77c420b30006 100644
--- a/hw/display/apple-gfx.m
+++ b/hw/display/apple-gfx.m
@@ -15,6 +15,7 @@
 #include "qemu/lockable.h"
 #include "qemu/cutils.h"
 #include "qemu/log.h"
+#include "qapi/qapi-builtin-type-infos.h"
 #include "qapi/visitor.h"
 #include "qapi/error.h"
 #include "qemu/aio-wait.h"
@@ -871,7 +872,7 @@ static void apple_gfx_set_display_mode(Object *obj, Visitor *v,
 }
 
 const PropertyInfo qdev_prop_apple_gfx_display_mode = {
-    .type  = "display_mode",
+    .qapi_type = &str_type_info,
     .description =
         "Display mode in pixels and Hertz, as <width>x<height>@<refresh-rate> "
         "Example: 3840x2160@60",
diff --git a/hw/misc/xlnx-versal-trng.c b/hw/misc/xlnx-versal-trng.c
index 0584ee089e3c..97bd3c3f8475 100644
--- a/hw/misc/xlnx-versal-trng.c
+++ b/hw/misc/xlnx-versal-trng.c
@@ -36,6 +36,7 @@
 #include "qapi/visitor.h"
 #include "migration/vmstate.h"
 #include "hw/core/qdev-properties.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 #ifndef XLNX_VERSAL_TRNG_ERR_DEBUG
 #define XLNX_VERSAL_TRNG_ERR_DEBUG 0
@@ -662,7 +663,7 @@ static void trng_prop_fault_event_get(Object *obj, Visitor *v,
 }
 
 static const PropertyInfo trng_prop_fault_events = {
-    .type = "uint32",
+    .qapi_type = &uint32_type_info,
     .description = "Set to trigger TRNG fault events",
     .set = trng_prop_fault_event_set,
     .get = trng_prop_fault_event_get,
diff --git a/hw/nvme/nguid.c b/hw/nvme/nguid.c
index 4cd6fad6ac9b..6eaf90fca88e 100644
--- a/hw/nvme/nguid.c
+++ b/hw/nvme/nguid.c
@@ -18,6 +18,7 @@
 #include "qapi/visitor.h"
 #include "qemu/ctype.h"
 #include "nvme.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 #define NGUID_SEPARATOR '-'
 
@@ -179,7 +180,7 @@ static void set_nguid(Object *obj, Visitor *v, const char *name, void *opaque,
 }
 
 const PropertyInfo qdev_prop_nguid = {
-    .type  = "str",
+    .qapi_type = &str_type_info,
     .description =
         "NGUID or \"" NGUID_VALUE_AUTO "\" for random value",
     .get   = get_nguid,
diff --git a/hw/nvram/xlnx-bbram.c b/hw/nvram/xlnx-bbram.c
index e336874bdef4..eb032ab8b9c8 100644
--- a/hw/nvram/xlnx-bbram.c
+++ b/hw/nvram/xlnx-bbram.c
@@ -34,6 +34,7 @@
 #include "hw/core/qdev-properties.h"
 #include "hw/core/qdev-properties-system.h"
 #include "hw/nvram/xlnx-efuse.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 #ifndef XLNX_BBRAM_ERR_DEBUG
 #define XLNX_BBRAM_ERR_DEBUG 0
@@ -486,7 +487,7 @@ static void bbram_prop_release_drive(Object *obj, const char *name,
 }
 
 static const PropertyInfo bbram_prop_drive = {
-    .type  = "str",
+    .qapi_type = &str_type_info,
     .description = "Node name or ID of a block device to use as BBRAM backend",
     .realized_set_allowed = true,
     .get = bbram_prop_get_drive,
diff --git a/hw/nvram/xlnx-efuse.c b/hw/nvram/xlnx-efuse.c
index 03c9fbc0d076..b1c9ee4980a0 100644
--- a/hw/nvram/xlnx-efuse.c
+++ b/hw/nvram/xlnx-efuse.c
@@ -34,6 +34,7 @@
 #include "system/blockdev.h"
 #include "hw/core/qdev-properties.h"
 #include "hw/core/qdev-properties-system.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 #define TBIT0_OFFSET     28
 #define TBIT1_OFFSET     29
@@ -251,7 +252,7 @@ static void efuse_prop_release_drive(Object *obj, const char *name,
 }
 
 static const PropertyInfo efuse_prop_drive = {
-    .type  = "str",
+    .qapi_type = &str_type_info,
     .description = "Node name or ID of a block device to use as eFUSE backend",
     .realized_set_allowed = true,
     .get = efuse_prop_get_drive,
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index be6145a90a9f..7cfe6032b915 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -52,6 +52,7 @@
 #include "qapi/error.h"
 #include "qemu/cutils.h"
 #include "pci-internal.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 #include "hw/xen/xen.h"
 #include "hw/i386/kvm/xen_evtchn.h"
@@ -79,7 +80,7 @@ static void prop_pci_busnr_get(Object *obj, Visitor *v, const char *name,
 }
 
 static const PropertyInfo prop_pci_busnr = {
-    .type = "uint8",
+    .qapi_type = &uint8_type_info,
     .get = prop_pci_busnr_get,
 };
 
diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c
index 25c427327957..fd21a4346522 100644
--- a/hw/s390x/ccw-device.c
+++ b/hw/s390x/ccw-device.c
@@ -17,6 +17,7 @@
 #include "qapi/visitor.h"
 #include "qemu/ctype.h"
 #include "qapi/error.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 static void ccw_device_refill_ids(CcwDevice *dev)
 {
@@ -74,7 +75,7 @@ static void ccw_device_set_loadparm(Object *obj, Visitor *v,
 }
 
 const PropertyInfo ccw_loadparm = {
-    .type  = "str",
+    .qapi_type = &str_type_info,
     .description = "Up to 8 chars in set of [A-Za-z0-9. ] to select"
             " a guest kernel",
     .get = ccw_device_get_loadparm,
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 3a67b6705319..152687da7820 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -24,6 +24,7 @@
 #include "hw/s390x/s390-virtio-ccw.h"
 #include "hw/s390x/s390-ccw.h"
 #include "exec/cpu-common.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 typedef struct CrwContainer {
     CRW crw;
@@ -2519,7 +2520,7 @@ out:
 }
 
 const PropertyInfo css_devid_propinfo = {
-    .type = "str",
+    .qapi_type = &str_type_info,
     .description = "Identifier of an I/O device in the channel "
                    "subsystem, example: fe.1.23ab",
     .get = get_css_devid,
@@ -2527,7 +2528,7 @@ const PropertyInfo css_devid_propinfo = {
 };
 
 const PropertyInfo css_devid_ro_propinfo = {
-    .type = "str",
+    .qapi_type = &str_type_info,
     .description = "Read-only identifier of an I/O device in the channel "
                    "subsystem, example: fe.1.23ab",
     .get = get_css_devid,
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index eff980fdfe92..f77632810b76 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -33,6 +33,7 @@
 #include "system/runstate.h"
 
 #include "trace.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 S390pciState *s390_get_phb(void)
 {
@@ -1541,7 +1542,7 @@ static void s390_pci_set_fid(Object *obj, Visitor *v, const char *name,
 }
 
 static const PropertyInfo s390_pci_fid_propinfo = {
-    .type = "uint32",
+    .qapi_type = &uint32_type_info,
     .description = "zpci_fid",
     .get = s390_pci_get_fid,
     .set = s390_pci_set_fid,
diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index c5b4f9091d49..4a3fd374a211 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -26,6 +26,7 @@
 #include "pci.h"
 #include "pci-quirks.h"
 #include "trace.h"
+#include "qapi/qapi-builtin-type-infos.h"
 
 /*
  * List of device ids/vendor ids for which to disable
@@ -1436,7 +1437,7 @@ static void set_nv_gpudirect_clique_id(Object *obj, Visitor *v,
 }
 
 const PropertyInfo qdev_prop_nv_gpudirect_clique = {
-    .type = "uint8",
+    .qapi_type = &uint8_type_info,
     .description = "NVIDIA GPUDirect Clique ID (0 - 15)",
     .get = get_nv_gpudirect_clique_id,
     .set = set_nv_gpudirect_clique_id,

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:38:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:38:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394192.1633027 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwK1D-0008S6-7D; Tue, 18 Aug 2026 13:38:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394192.1633027; Tue, 18 Aug 2026 13:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwK1D-0008Rx-40; Tue, 18 Aug 2026 13:38:19 +0000
Received: by outflank-mailman (input) for mailman id 1394192;
 Tue, 18 Aug 2026 13:38:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwK1B-0008Rr-L3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:38:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwK1B-002cb0-1d
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:38:17 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a846040-8faa-0a2a0a5109dd-0a2a45048e0e-36
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:38:17 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a846048-b57f-0a2a45040019-d1558036b431-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:38:16 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4998590d392so48394415e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 06:38:16 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a7c568sm12198942f8f.18.2026.08.18.06.38.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 06:38:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787060296; x=1787665096; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=zhlxW4qiePznAo5gSWosjOTmBT5D8uBehTWpiIJV8lY=;
        b=QmMM9ri0vxatAeFkgKC7fIJw/7DdFWAQLIphrjY9YeAdXG6jFlGxXMgi0bVdgxwL9S
         wWYPuX2TMNP/WzbbzI3p3c5fXVsS/tX6P2om4Eg3Ept7SzcSsBFM4jO0t6comdJcCQbm
         vP/YdgTHIKhfAkuJD8Ncx8TZFQqUtngO7fdSG8YKv1taBCVIb1mANIWWIyvxe55EOV1k
         5DRiKUQMeG7VdW1xwUjss0Uz0yjlfWUE1QFFyz4dB+rrNuWxXvWc/Wv2fh24lcaKOTix
         Uw3yya7F6QPVilm+uAPK6CIhp8tKprw6Hcj1XhAYF4134h/xozK2UgMqibrAlw1+M4vh
         nG4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787060296; x=1787665096;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=zhlxW4qiePznAo5gSWosjOTmBT5D8uBehTWpiIJV8lY=;
        b=pZiXYjRrmlnCpjzCBEuygTLPGIvXfoHGAz+Fz05qCMHI/7DYHAGuaOCtZoOYW3Qmpw
         bwztZlCMORM9ygcN7tg5QA4kWPXIIEa4nA3Xhh6ek2VdKvtxNUw/RjVzmAP6FN4aSuVN
         8bzDBkYiLyb/mDMAkRYTHU7owckLAGcGtm3JCI5T6GRVz8l7ZpBb1JBTplRVutE9lhRt
         ih+3z2K3Dm4aALeuFRASlQAB3o+HeeBumBBuDdn1Pl+JWjKb0bSfk9BJYcQhy+lW+2DG
         ZjJHMB1NZt2LzHsJxfVlTnF6XquxrJmQ+U4mqQzMX1ranmHN8N8XzZhJ5YSU+QJ96fBM
         tPPA==
X-Forwarded-Encrypted: i=1; AHgh+RqiFnFMFQ+kwywVPZlb1gpckFZj3TqsV2KMpLgHfH+OrF4YA3ya2TMkEybPN9M0W6qlHnoG8CTNUPg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxpyXemqRmCUS46aVpk4MAotOhwmDvTPvqiFOR0oP+icqAN9K97
	FQJ6QicghSRqa/QN9gnwlPjv2JSOvWE/2wTTedzR/H6z5utUosRn4kVL
X-Gm-Gg: AR+sD12/8GJSmpsgpVUyjBR5lKbeuHXYFeMT3NxXVgSLp+1+L8KYFL+f5YJOQH5jGPz
	KCk0HmD6l3D/UoGLlXL+ndZgdPeKDO8SngznfIk1UNRuZTeadm/gePAi4YjtS06FTHgOSROf+1f
	hDJTGjFpA8mxD09gyv/ZPfPCIUYJLM60g5iBlmzOVi/nze9ji/J5B5WfUJz0u1+VqWuZZZLU+Sj
	W94Qdu5UZhp8VwZl+XSFhNshe7VeTP84s7oVSImLymvWvn73V0/9U79/yifNxXIottyckXIaOXx
	MtA9vB0iMeRdiEijbfy80I3BcnFXDlVYqZIWXODAQ/PM89hptDAYCfsyn8QxbLfcwdwQkhUsdCU
	GoCFwB3Lzp12lK6hXxdWKCtzMW9e1TMCHyXRftxAY6oqAxIw+9CKGN1QsjII8paUhXPY4SOlCnX
	l3YA0ybO6WKXOSkP5JyzOfPDuFea1ZpNPdrmi3fitzv2OgmtJFIdTLG6pN85YUNZszPoKPDYxJ8
	9IDshuTh70JV8HnWEBI3qwPpZVzlrEUpR0jvnFfOWA=
X-Received: by 2002:a05:600c:848e:b0:499:8156:cd3f with SMTP id 5b1f17b1804b1-4999fb3f78bmr153120185e9.8.1787060296169;
        Tue, 18 Aug 2026 06:38:16 -0700 (PDT)
Message-ID: <6959b0e1-3059-4d3b-baa1-28dc0d761f9e@gmail.com>
Date: Tue, 18 Aug 2026 15:38:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
 <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
 <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
 <2ca3f802-bf93-4714-8a9b-e33ab0c89300@suse.com>
 <d94bd15a-bf99-4df5-9dac-1fe0fcb77cfc@gmail.com>
 <5ee55d9c-d0f8-41cc-8d4e-3ba6c08d7506@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <5ee55d9c-d0f8-41cc-8d4e-3ba6c08d7506@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787060296-528C9B50-16DCEEF0/10/73395122804
X-purgate-type: spam
X-purgate-size: 5639



On 8/18/26 12:43 PM, Jan Beulich wrote:
> On 18.08.2026 12:27, Oleksii Kurochko wrote:
>> On 8/18/26 10:17 AM, Jan Beulich wrote:
>>> On 17.08.2026 17:36, Oleksii Kurochko wrote:
>>>> On 8/12/26 5:30 PM, Jan Beulich wrote:
>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>> +    if ( read_insn )
>>>>>> +    {
>>>>>> +        asm volatile ( "\n"
>>>>>> +            "1:\n"
>>>>>> +            "   hlvx.hu %[val], (%[addr])\n"
>>>>>> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])
>>>>>> +            "   andi %[tmp], %[val], 3\n"
>>>>>> +            "   addi %[tmp], %[tmp], -3\n"
>>>>>> +            "   bne %[tmp], zero, 3f\n"
>>>>>> +            "   addi %[addr], %[addr], 2\n"
>>>>>> +            "\n"
>>>>>> +            "2:\n"
>>>>>> +            "   hlvx.hu %[tmp], (%[addr])\n"
>>>>>> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
>>>>>> +            "   sll %[tmp], %[tmp], 16\n"
>>>>>> +            "   add %[val], %[val], %[tmp]\n"
>>>>>> +            "3:\n"
>>>>>> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
>>>>>> +        : [ti] "r" (trap) : "memory" );
>>>>>
>>>>> You want to tell the compiler that *trap is written. Instead I don't see
>>>>> why a memory clobber would be needed: You access a different address space,
>>>>> i.e. nothing the compiler can make any assumptions about.
>>>>
>>>> memory clobber tells the compiler that the assembly code performs memory
>>>> reads or writes to items other than those listed in the input and output
>>>> operands and so I don't tell here that *trap will be changed.
>>>>
>>>> Why this understanding is wrong?
>>>
>>> You can (ab)use "memory" for that purpose, but why would you when you can
>>> properly express the operand? All that achieves is the compiler possibly
>>> having to emit less efficient code.
>>
>> Then I will use the option mentioned ...
>>
>>>
>>>> Alternative, I think, could be:
>>>>            : [val] "+r" (val), "+m" (*trap)
>>>>            : [addr] "r" (guest_addr), [ti] "r" (trap) );
>>>> And then memory clobber could be dropped.
>>
>> ... here.
>>
>> Probably I have to return '[addr] "r" (guest_addr)' to output and use
>> +&r constraint.
>>
>>>>> You also need to take precautions for not returning an uninitialized "val".
>>>>> I think the variable wants initializing (perhaps to ~0) and "+r" wants
>>>>> using as constraint. (Afaik & isn't necessary to use together with +.)
>>>>
>>>> I agree with '+' if we will initialize val with some value.
>>>>
>>>> Regarding, '&' my understanding is that I have to use it always when
>>>
>>> When what exactly? If an operand is both input and output, how could the
>>> compiler re-use the (generally) register for any further purpose? '&'
>>> indicates to the compiler that it may not use the register used for an
>>> output to hold some input's value, as that value may be lost by the time
>>> the input is actually consumed.
>>
>> But what is written in the gcc doc:
>>
>> & - Means (in a particular alternative) that this operand is an
>> earlyclobber operand, which is written before the instruction is
>> finished using the input operands.
>>
>> What sounds like if an operand (val) in our case is written before the
>> instruction which using the input operands (and after the write
>> instuction which writes val there are instructions which are using input
>> operands) it is needed to have &.
> 
> And that's indeed relevant, just not here. My crucial earlier question was:
> "If an operand is both input and output, how could the compiler re-use the
> (generally) register for any further purpose?" There is a case where the
> answer to this is not "it can't". In your case all inputs are distinct; in
> e.g. (using x86 assembly, sorry):
> 
> int test(int i, int j) {
> 	asm("nop %0; nop %1" : "+r" (i) : "r" (i));
> 	asm("cmc; nop %0; nop %1" : "+&r" (j) : "r" (j));
> 
> 	return i + j;
> }
> 
> using "+&r" indeed makes a difference.

I think it is clear when operands are equal. but what about the case 
when they are different in  first  case:
...
   asm("nop %0; nop %1" : "+r" (i) : "r" (j));
...

What guarantees that i and j will be in different registers?

We have the similar situation in RISC-V code of riscv_vcpu_unpriv_read():

         : [val] "+r" (val), [tmp] "=&r" (tmp), [addr] "+r" (guest_addr),
           "+m" (*trap)
         : [ti] "r" (trap) );

With having & for val and guest_addr & guarantees that the same 
registers won't be re-used for ti (and so ti won't be corrupted) but 
without it?

~ Oleksii

> 
>> t1:  hlvx.hu %[val], (%[addr])   W:val R:addr + can trap -> read register ti
>>
>> t2:  andi    %[tmp], %[val], 3   W:tmp   R:val
>> t3:  addi    %[tmp], %[tmp], -3
>> t4:  bnez    %[tmp], 3f
>> t5:  addi    %[addr], %[addr], 2 W:addr  R:addr
>> t6:  hlvx.hu %[tmp], (%[addr])   W:tmp   R:addr + can trap -> read
>> register ti
>>
>> t7:  slli    %[tmp], %[tmp], 16
>> t8:  or      %[val], %[val], %[tmp] W:val
>>
>> So val is written on t1 before t6 where addr and ti still alive.
>>
>> The similar is for [addr] "+&r" (guest_addr):
>>
>> addr is written on t5 and input ti is alive till t6. So if allocator
>> will allocate the same register for addr and ti then addi %[addr],
>> %[addr], 2 will break a pointer and handler will get something wrong.
>>
>> Am I missing something?
>>
>> If I am still wrong then in both cases should be just "+r"?
> 
> As per above, if you want to play absolutely by the rules, use "+&r",
> even if that's unnecessary here.
> 
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 13:57:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 13:57:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394209.1633036 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKK2-0002yr-My; Tue, 18 Aug 2026 13:57:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394209.1633036; Tue, 18 Aug 2026 13:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKK2-0002yk-KB; Tue, 18 Aug 2026 13:57:46 +0000
Received: by outflank-mailman (input) for mailman id 1394209;
 Tue, 18 Aug 2026 13:57:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwKK1-0002xA-0a
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 13:57:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwKK0-0075pT-DY
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:57:44 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8464bc-e002-0a2a0a5209dd-0a2a45019a34-46
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:57:40 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8464d4-5984-0a2a45010019-d155802da4cf-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 15:57:40 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so12346315e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 06:57:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d10b7f6sm131626285e9.12.2026.08.18.06.57.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 06:57:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787061460; x=1787666260; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cN/JhVLMabK6UpBzze+2jfLaJR/nelh/I66BaRpCVK0=;
        b=ZFstpW0UCFNyW+DKoigJVpIycYVWMuTi1D5pKnimzcyAL5nwWji39bSx+gVGD+EdsZ
         cP1fljsIGbVTkIyheJTjdQMv5KwSL6h90ouQWjqdRUY4f9pv/1cOuRAzzGgkZps1SPmi
         t4CSqLSaPzeaFBdZn8qXOtucO3jzWjJxc8gKuHMt49TklFa6z9HdacnSmW0zbaNkZ4UO
         8NHZb/11aKjTFXHpYdq9oaMDp3HhsgjZBycBL62+Z+cpWXmeQLo7V2hd86cH9r/1RRwd
         hpSnrbfdX6mS2AVJQzIscZEz3lgqAKqS68XgiQCjV55qe5zd3LeD/pDeQ++1v06WvmJV
         pnIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787061460; x=1787666260;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=cN/JhVLMabK6UpBzze+2jfLaJR/nelh/I66BaRpCVK0=;
        b=hfHD3rigbr4R7KSJFMZFZbYfxMnuWhGzOgr4VoAfz6aWkxsP6kniKIa29wEKmXh3vI
         Gqx+zJB4o//YuJCRGcnlDnyK5lkWG9OcEsMacIhYRPyh16sM6BrJ/0YksXvcEGvHeS82
         /KZm3e0rc3FsNyNNORenKC9SAUQ49pHMilnUX2pCJChwQOBjLCY0JdnV/wQ/SSDoQ9Cp
         CFyfnJjjEM4xK4gxtFQJiKFiLGrI8wMV99F1ZAzFiD0let/gkKLuvtDsuygdah830uaO
         guVc3SboRNT1w6oBipCkyqkdgUinHtISO/+lfV16kFQlZqHYy91is5mM7zrP4x8nwrMB
         ANbg==
X-Forwarded-Encrypted: i=1; AHgh+RqnvTr6NapJasmAIjkwQU3qIVl1bX1Zlsf9rRKvldC4Ypq15qV9ZoPO/RNvdbHQeqJjJ3owIwENo6A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy1hHOpQZc+KSvmDGmkiKvOOyR7V7v2l75thldrzxaocBDMHINv
	ilm2WIbvnOp8NmlZWntLEghUiquINLKyOXJ8zGS3dZTvDbWinzMzisZpicySTNOphw==
X-Gm-Gg: AR+sD11OPLj63PAEQjLPevnHG/BDOCZutXK/8kW+dd9LIEiuCztqHVIiTdt9GRMmPp5
	OlwcznhWvg4uQHHfKN1z2ydzTY7DR9KNRYski9U5rwrh6XL2VEy6hM1Xlqm4HglwfwhaP6no03w
	hnDH7GUI76nIgSrLcPqfKFBEFBjQBMxAWuNw17NS1HBYkjRglHPMY6HbnGKSgVpOQLemzXC/WdX
	ViXjKzrpqRfPjwNt2LjZLxxkO9ynktvkiygL1HxM/6OzNT3HZJd/iOVJrUkYDk/7Fw01EU+81M7
	gufexg9BGnB/J30yfhOUcvQDtjtbjXB2322AhOuGSowKlV5sj6EtjLGui/SXvbHbVauehsHYmGE
	TEye4geQ+gTkmypZ3+ARNNAvIhNx/74rTAu/mD2z4ET8W2cGnjgbKWgBjZormFyw74rGUh9ci6J
	Jl+LyUHY6kc3lOSIeQiZN18cG5cMG+2s4rFiIhw1G3MyXAlxuzYkP2gFk2E3FE3Lk99qIQDbV0x
	T0CyYOvbIkWPrnRp4cKzuDzox9tkeJQ5qenS7Y5UvY9HMiooVvO
X-Received: by 2002:a05:600c:35d1:b0:499:a0a5:e13f with SMTP id 5b1f17b1804b1-499a2040313mr94987795e9.2.1787061459685;
        Tue, 18 Aug 2026 06:57:39 -0700 (PDT)
Message-ID: <f72b77f0-155e-4c13-bc36-5376daeb5959@suse.com>
Date: Tue, 18 Aug 2026 15:57:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 3/3] x86/ioreq: Extend ioreq server to support multiple
 ioreq pages
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260420093820.825969-1-julian.vetter@vates.tech>
 <20260420093820.825969-4-julian.vetter@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260420093820.825969-4-julian.vetter@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787061460-BF66C757-A544A0F4/0/0
X-purgate-type: clean
X-purgate-size: 7887

On 20.04.2026 11:38, Julian Vetter wrote:
> As the number of vCPUs grows, a single ioreq page of 128 slots may not
> be sufficient. Add support for allocating and mapping multiple ioreq
> pages so that the ioreq region can scale with d->max_vcpus.
> 
> Introduce nr_ioreq_pages() to compute the number of pages required for
> a given domain, and IOREQ_NR_PAGES_MAX as a compile-time upper bound
> (based on HVM_MAX_VCPUS).
> 
> ioreq_server_alloc_mfn() is updated to allocate nr_ioreq_pages() pages
> and map them contiguously via vmap().
> 
> is_ioreq_server_page() iterates over all ioreq pages when checking
> page ownership. ioreq_server_get_frame() allows callers to retrieve any
> ioreq page by index via the XENMEM_acquire_resource interface.
> 
> On x86, the legacy GFN mapping path (hvm_map_ioreq_gfn) is limited to
> a single ioreq page; device models requiring more ioreq slots must use
> the resource mapping interface (XENMEM_acquire_resource).
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v6:
> - Adapted the comment to not mention the guest, but the device model
> - Replaced the dynamic allocation for the mfns array by a static array
> - Fixed error handling in ioreq_server_alloc_mfn, using an extra
>   nr_alloc variable to track the already allocated pages
> - Dropped unnecessary void casts
> ---
>  xen/arch/x86/hvm/ioreq.c |  8 ++++
>  xen/common/ioreq.c       | 93 ++++++++++++++++++++++++++++------------
>  xen/include/xen/ioreq.h  | 12 ++++++
>  3 files changed, 86 insertions(+), 27 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 3cabec141c..ee679bdf5a 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -166,6 +166,14 @@ static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf)
>      if ( d->is_dying )
>          return -EINVAL;
>  
> +    /*
> +     * The legacy GFN path supports only a single ioreq page. Device models
> +     * requiring more ioreq slots must use the resource mapping interface
> +     * (XENMEM_acquire_resource).
> +     */
> +    if ( !buf && nr_ioreq_pages(d) > 1 )
> +        return -EOPNOTSUPP;
> +
>      iorp->gfn = hvm_alloc_ioreq_gfn(s);
>  
>      if ( gfn_eq(iorp->gfn, INVALID_GFN) )
> diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c
> index bae9b99c99..3a08e77597 100644
> --- a/xen/common/ioreq.c
> +++ b/xen/common/ioreq.c
> @@ -261,8 +261,11 @@ bool vcpu_ioreq_handle_completion(struct vcpu *v)
>  static int ioreq_server_alloc_mfn(struct ioreq_server *s, bool buf)
>  {
>      struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> -    struct page_info *page;
> -    mfn_t mfn;
> +    unsigned int i, nr_alloc = 0, nr_pages = buf ? 1 : nr_ioreq_pages(s->target);
> +    mfn_t mfns[IOREQ_NR_PAGES_MAX] = {};

This is okay to have with the present HVM_MAX_VCPUS, but we need to put in
place something to bound stack usage here. Once the upper bound on the
number of vCPU-s has grown enough, some other mechanism will need to be put
in place, preferably still without runtime allocation. (And no, this isn't
a static array, i.e. the revlog entry isn't quite correct.)

For the moment I'd suggest BUILD_BUG_ON(ARRAY_SIZE(mfns) > 32), with a
clarifying comment.

> +    int rc;
> +
> +    ASSERT(nr_pages <= IOREQ_NR_PAGES_MAX);

Why would this be relevant to check (only) here? Imo this either wants
dropping, or moving into nr_ioreq_pages().

> @@ -277,11 +280,16 @@ static int ioreq_server_alloc_mfn(struct ioreq_server *s, bool buf)
>          return 0;
>      }
>  
> +    for ( i = 0; i < nr_pages; i++ )
>      {
> -        page = alloc_domheap_page(s->target, MEMF_no_refcount);
> +        struct page_info *page = alloc_domheap_page(s->target,
> +                                                    MEMF_no_refcount);

This movement of the decl would better also be part of patch 2.

> @@ -290,41 +298,59 @@ static int ioreq_server_alloc_mfn(struct ioreq_server *s, bool buf)
>               * here is a clear indication of something fishy going on.
>               */
>              domain_crash(s->emulator);
> -            return -ENODATA;
> +            rc = -ENODATA;
> +            goto fail;
>          }
>  
> -        mfn = page_to_mfn(page);
> +        mfns[nr_alloc++] = page_to_mfn(page);
>      }
> -    iorp->va = vmap(&mfn, 1);
> +
> +    iorp->va = vmap(mfns, nr_pages);
>      if ( !iorp->va )
> +    {
> +        rc = -ENOMEM;
>          goto fail;
> +    }
>  
> -    clear_page(iorp->va);
> +    memset(iorp->va, 0, nr_pages * PAGE_SIZE);

clear_page() is a bit more efficient, so I wonder whether - especially for
small nr_pages - we aren't needlessly losing performance here. Question is
whether there's a reasonable to establish boundary at which memset()
(largely) catches up.

> @@ -337,12 +363,25 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
>  
>      FOR_EACH_IOREQ_SERVER(d, id, s)
>      {
> -        if ( (s->ioreq.va && vmap_to_page(s->ioreq.va) == page) ||
> -             (s->bufioreq.va && vmap_to_page(s->bufioreq.va) == page) )
> +        unsigned int i;
> +
> +        if ( s->bufioreq.va && vmap_to_page(s->bufioreq.va) == page )
>          {
>              found = true;
>              break;
>          }
> +
> +        for ( i = 0; i < nr_ioreq_pages(d) && s->ioreq.va; i++ )

s->ioreq.va is loop invariant, without the compiler being in the position
to know. The condition therefore wants moving out, preferably as

        if ( !s->ioreq.va )
            continue;

to avoid indentation growing too much.

> +        {
> +            if ( vmap_to_page(s->ioreq.va + i * PAGE_SIZE) == page )
> +            {
> +                found = true;
> +                break;
> +            }
> +        }

It may help readability here if for()'s curly braces were dropped.

> +        if ( found )
> +            break;
>      }
>  
>      rspin_unlock(&d->ioreq_server.lock);
> @@ -816,26 +855,26 @@ int ioreq_server_get_frame(struct domain *d, ioservid_t id,
>      if ( rc )
>          goto out;
>  
> -    switch ( idx )
> +    if ( idx == XENMEM_resource_ioreq_server_frame_bufioreq )
>      {
> -    case XENMEM_resource_ioreq_server_frame_bufioreq:
>          rc = -ENOENT;
>          if ( !HANDLE_BUFIOREQ(s) )
>              goto out;
>  
>          *mfn = vmap_to_mfn(s->bufioreq.va);
>          rc = 0;
> -        break;
> +    }
> +    else if ( idx >= XENMEM_resource_ioreq_server_frame_ioreq(0) &&
> +              idx < XENMEM_resource_ioreq_server_frame_ioreq(nr_ioreq_pages(d)) )
> +    {
> +        unsigned int page_idx = idx - XENMEM_resource_ioreq_server_frame_ioreq(0);
>  
> -    case XENMEM_resource_ioreq_server_frame_ioreq(0):
> -        *mfn = vmap_to_mfn(s->ioreq.va);
> +        ASSERT(page_idx < nr_ioreq_pages(d));

Isn't this redundant with the range check on idx?

> --- a/xen/include/xen/ioreq.h
> +++ b/xen/include/xen/ioreq.h
> @@ -35,6 +35,18 @@ struct ioreq_vcpu {
>      bool             pending;
>  };
>  
> +/*
> + * Maximum number of ioreq pages, based on the maximum number
> + * of vCPUs and the number of ioreq slots per page.
> + */
> +#define IOREQ_NR_PAGES_MAX \
> +    DIV_ROUND_UP(HVM_MAX_VCPUS, PAGE_SIZE / sizeof(ioreq_t))
> +
> +static inline unsigned int nr_ioreq_pages(const struct domain *d)
> +{
> +    return DIV_ROUND_UP(d->max_vcpus, PAGE_SIZE / sizeof(ioreq_t));
> +}

To reduce redundancy, how about

static inline unsigned int nr_ioreq_pages(const struct domain *d)
{
    return DIV_ROUND_UP(d ? d->max_vcpus : HVM_MAX_VCPUS,
                        PAGE_SIZE / sizeof(ioreq_t));
}

#define IOREQ_NR_PAGES_MAX nr_ioreq_pages(NULL)

?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 14:08:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 14:08:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394216.1633045 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKU4-00051x-Ie; Tue, 18 Aug 2026 14:08:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394216.1633045; Tue, 18 Aug 2026 14:08:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKU4-00051q-FH; Tue, 18 Aug 2026 14:08:08 +0000
Received: by outflank-mailman (input) for mailman id 1394216;
 Tue, 18 Aug 2026 14:08:08 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwKU3-00051k-Ue
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:08:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwKU3-009Ia6-3E
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:08:07 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a846740-2eae-0a2a0a5409dd-0a2a4508aa6c-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:08:06 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a846746-f659-0a2a45080019-d155802fd571-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:08:06 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so45570565e9.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:08:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49987b2a176sm354293485e9.4.2026.08.18.07.08.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 07:08:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787062086; x=1787666886; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=EEVtHaDdO9l8Kuslq6ElT4hhldlh7ZpnF3AWC38WmGg=;
        b=adSjjZQL2t/8CPRrkh0+puvNGZffkqUsRizqDNRXrWsEZ55Y9tGVBmLw79hCuwRIc0
         4NJXKwfbBNwF9C3jTx2HZNGs6Gajz1v/gFMeuHnlOtafeUNc9hrLO5o9XyHG477d+H9J
         Qt+WpVesWeYx2WGVcHFMPOuq9bbkw68rX2GNpYHiq8psJocaHmdZexI1bFl8iYSvzl8B
         VCXm5SvE+pdxxxtMY9BszWG61ZJLZq5x/EeSDWxk+w+EbSci62wha6+Z+6vNPFtr1mwY
         tVXLcWsKykrD2ROCSUk5GDweAQwRntDeXqmmjxsuqB0j8xMnN8Pnyya6rinUJa5hZdmo
         Bf7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787062086; x=1787666886;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=EEVtHaDdO9l8Kuslq6ElT4hhldlh7ZpnF3AWC38WmGg=;
        b=QHs448mUo17pMrdHMVi8SvY0yUbPtJkNDhowLGJbATPsCMFoCxIG/aanTw4NdD7rXF
         yDhRlb2tyyPErXh0tirwc1uP80PdBjQCVXUaBo51pLi4Sq0EpljgcT8lbRux7OqqK8yH
         n+L7W6Q9Ca3gARQO3lDlhBHNwYzPoObHNFwA4CxN8Rb/ryBphSv9goExe5cGjQy1swTr
         mXuxmxgUSWh8rw3HGgK7n6I2Wh3z/YScBZLwR9texh5JTdY45YGcucPXPJA/p0rv8LqY
         JhQTbP5l55Ub4oIByh+1CdEEnLV75xpRp5F/B/5lH6I4Tguok0FKRAW6MlWys2nU/3TK
         eNWQ==
X-Forwarded-Encrypted: i=1; AHgh+RoXUc/n8eKsbU586Ys62JHSpqyexEqMhM+Epdq61N9L9YJbdg8u8qjJS6elxI/aPWLVccU2dovcQQY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwqH48RZc9phZXV+RiRIXwG8w7luQH6e8RLT86mPFFoE0qdIQmt
	XnzHpfxdicO2hgHwy1b1eu70e/Wfte1Hkv1rBiZQXFH0o/SxCusA8/56UiHZJAzNrQ==
X-Gm-Gg: AR+sD10eaz8tjS1SC0eJJ4YkHG4abD3nFu/ZzF07HZ2CkvG7RCCI8uNw+UREdU/QBIP
	bjvcdKDG8/gCyUb7Z+Jqd1AUqFmnab62goSsqvtQapfFM/lRBKJ35sf6l7Hs1lZ/wvHWQbINoeV
	fEQT74MeXsnL2YniMw4Woxm5aLPMl1ngqs6QbM2LA5r/fLRiG8tOFgvNd9a9zGnigC/xiICaVhx
	kYoaZNL0PD1MBWqBe8SpuDWt7jfSI7sOiKW/D5tXOmHdXjCdc9vbeZJ8uYpC+oiLAlaWIW28wMY
	aDuLyQ2gY9n8jjo6LbuxAU0Be+1JZLdeO7pa4RzMuL0ZDyVDxf4wrvJyNRbvzgH3eLpOT9o7C2h
	/k/tcnPdYUQPRDHdQljqnxrT8cCnONvjfbtIlIX2CLdxwvvk/lVf4uvxRxjQq9QlEADkmOl5+/g
	oBu0CpvNEy8x1zLc0NF4jVGUF763GxP6k3PP0V5ADhXaTZ0USYcFtk7tZ+a13uGQMkVWtYuxp8p
	xiIsxzwXUXYPB8VkPT1aAgllDlMc4JvK107LvzFy7Fcym6tUeth
X-Received: by 2002:a05:600c:1d0e:b0:495:7888:281c with SMTP id 5b1f17b1804b1-499878cd5bcmr485265185e9.0.1787062086458;
        Tue, 18 Aug 2026 07:08:06 -0700 (PDT)
Message-ID: <23816f6d-57eb-4567-b6da-93269e6a1c23@suse.com>
Date: Tue, 18 Aug 2026 16:08:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 0/3] Support multiple ioreq pages
To: Julian Vetter <julian.vetter@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260420093820.825969-1-julian.vetter@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260420093820.825969-1-julian.vetter@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787062086-D534D87B-7C5CBEC2/0/0
X-purgate-type: clean
X-purgate-size: 1459

On 20.04.2026 11:38, Julian Vetter wrote:
> Julian Vetter (3):
>   ioreq: switch ioreq page allocation to vmap
>   ioreq: Indent ioreq_server_alloc_mfn() body one level deeper
>   x86/ioreq: Extend ioreq server to support multiple ioreq pages
> 
>  xen/arch/x86/hvm/ioreq.c |  63 ++++++++++++++++---
>  xen/common/ioreq.c       | 127 ++++++++++++++++++++++++++-------------
>  xen/include/xen/ioreq.h  |  13 +++-
>  3 files changed, 151 insertions(+), 52 deletions(-)

For (future) reference, in case it wasn't said earlier:

To be able to test this, at least the last patch here will want to wait
until the apic_id == vcpu_id * 2 issue was addressed. Andrew said he'd pick
up Alejandro's work there, thus - once finished - permitting up to 255
vCPU-s (i.e. requiring 2 IOREQ pages).

Once (really: before) we grow the number of vCPU-s for HVM, we need to
revisit the amount of VA space set aside for vmap(). For many years we've
been adding new uses of vmap() without making sure its reserved range is
still adequately sized.

Since multi-page functionality added here will also need qemu changes, and
since we did determine (elsewhere) that ioreq_t needs to grow as well, it
remains to be decided whether the two changes wouldn't better be done
together, to keep the qemu backwards compatibility logic somewhat limited
in size / complexity. Anthony (in particular) - thoughts?

There may be more aspects which I forget.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 14:16:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 14:16:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394225.1633054 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKbu-0006f7-CR; Tue, 18 Aug 2026 14:16:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394225.1633054; Tue, 18 Aug 2026 14:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKbu-0006f0-9e; Tue, 18 Aug 2026 14:16:14 +0000
Received: by outflank-mailman (input) for mailman id 1394225;
 Tue, 18 Aug 2026 14:16:13 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwKbt-0006eu-He
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:16:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwKbs-00Da6f-7B
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:16:12 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a84691a-bab6-0a2a0a5309dd-0a2a4503d1c0-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:16:08 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a846928-fae8-0a2a45030019-d1558034e43a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:16:08 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso37714655e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:16:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a31572sm12796383f8f.5.2026.08.18.07.16.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 07:16:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787062568; x=1787667368; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wBF9nUt5CrcYIqX2i8K8X50NNea0WojETI06s9K0YQ0=;
        b=F5jE1fhM8wrGi6i+uwg+1lx3lW3iXQNTll4GwByNG7eZvUEAnKgVwp8MyrLhc7QzvI
         QxfiLAzgt+C1suQacz9HfDDAaRx0mpr2aHz2lhcffgzJJdEKHM0BgKwVWgrO5XWkvzGF
         MIZ79qFQyCcEVHiB0zo5mUWrUEPnLWSf55B0SHMaIIZynVVgLJyD38Hi+Nb1Eb0Divg3
         ByeZr6cMAuTJZAWRROfh0rnAvCVppFdF32ii/bm9OOR+4U+V+KbF1DuT4VvfQcQoppOH
         zuThglmxabdXYHlQhKaZUSI5n/IL1ZQ1dZ9pruL4F6I9MBFkjYt/FNU6TWVRD5mvc0Uh
         hsLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787062568; x=1787667368;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=wBF9nUt5CrcYIqX2i8K8X50NNea0WojETI06s9K0YQ0=;
        b=DNSio/DUy+D1yz130M7FGcpi733bPoIdzUzINNiaVAal4EHtscALB3bzu4EhzIAY0G
         6K0u0UJtcPZwHP+I+W9JLNRRSJyKYwOYCvDnRBX+94Ye0LfXebF5icHP3SXuF3Df5DkG
         MyHDZM05sEZwQzBd8TUgnovl4qQN6fMxyfV7zZNiLwj+blLZ7UVvaPs4PHLbXVuXSg3O
         uoFn4bmcRiQ7piPI093ItX08h3cooPDUvF4awn2vAVA47gOASUUVWpb/7hZgiimyTrv5
         iHkN0RWQJI/sicUN2TH+2hrRwOR8eX2GvZ6Zu8CtAR8mHGIi1bki7+EvBENUUa6nlzwC
         /Nzw==
X-Forwarded-Encrypted: i=1; AHgh+Rq30f6TVdlA152RMR57rc0gfWPgzIAA34TlKlkTQ5xXV4Xy7/Xktufe/5qc4R+cHdGOJM+tHK6wPq4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsC1A1lsaD2AGrb0knp9JbNxiRA6P4JPL0ICIUHHK5WxczXjiB
	DHCYm0oxgXNtO56qmVrcLtTeMpqYGOFZgYN+VkrvASTsejLpcf6fc6tLTqVB30Mr0A==
X-Gm-Gg: AR+sD10T30CZRYolZywhXr4YFBrMSfRvuwEhiknDUVk3Dm1v3qGtkeqzXnfLGpWzTDQ
	GYJL9vhAIGoc3fG1coQjYu8cUWfPr0q+/tmAqVFOeskx8A7F5P9uC3wj7G1wQw0wRo3lPhx2WQY
	SuYhwoVPJn+6tTsCT0KJK8KghIOq2XUUaxlAHsumAXzJ3ghDWpFeXyuelRgZRT/BxW6a/Nemcqm
	8n1XJWc4csYtmx+h69zjRoVxtTgQOD/3DPtO7RtlrWPaRmQm6SRHNpuWjCUB2KelzS08ekDPYYD
	kzb1lSagvSpwN5Un4uWe2arkxg6appEBLzkTgIu1XyT/aLSNaUvQVuLz0wYTNx/pIqQKjtumfOd
	uJyeKW6MP02qafgaGhaixjhDId6kLQRvNDJ1bE2g2zOjMtFN0J8/hKfG/jLTQ8YHWog3xK6t4LL
	tYZbV0wRX0ygFwaxonip7rNBxyiXVFWkq3h6TblWaOfB9fuvhnLQFeqscJ2Vk3Y4YjQkLlfHWIm
	fG7znh7lF+fIYogsqWUP5RGGNsCtCvUXpud1UZge72LgFhGy45K
X-Received: by 2002:a05:600c:8509:b0:496:c9cd:e7ab with SMTP id 5b1f17b1804b1-499879337acmr611677535e9.5.1787062567283;
        Tue, 18 Aug 2026 07:16:07 -0700 (PDT)
Message-ID: <35b8afb4-dec6-4110-892f-c2202c9066b8@suse.com>
Date: Tue, 18 Aug 2026 16:16:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/17] xen/riscv: add unprivileged guest memory read
 helper
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <79cfa875e9dfc14bbcad948c20f4008b03d11f72.1784560663.git.oleksii.kurochko@gmail.com>
 <71a226b9-dc03-4a69-beb2-5c4c03b8d09b@suse.com>
 <3c0d33bd-ebab-48df-9ddf-a508e5bed5fe@gmail.com>
 <2ca3f802-bf93-4714-8a9b-e33ab0c89300@suse.com>
 <d94bd15a-bf99-4df5-9dac-1fe0fcb77cfc@gmail.com>
 <5ee55d9c-d0f8-41cc-8d4e-3ba6c08d7506@suse.com>
 <6959b0e1-3059-4d3b-baa1-28dc0d761f9e@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <6959b0e1-3059-4d3b-baa1-28dc0d761f9e@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787062568-6D4D74E9-EB8E14E3/0/0
X-purgate-type: clean
X-purgate-size: 5223

On 18.08.2026 15:38, Oleksii Kurochko wrote:
> 
> 
> On 8/18/26 12:43 PM, Jan Beulich wrote:
>> On 18.08.2026 12:27, Oleksii Kurochko wrote:
>>> On 8/18/26 10:17 AM, Jan Beulich wrote:
>>>> On 17.08.2026 17:36, Oleksii Kurochko wrote:
>>>>> On 8/12/26 5:30 PM, Jan Beulich wrote:
>>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>>> +    if ( read_insn )
>>>>>>> +    {
>>>>>>> +        asm volatile ( "\n"
>>>>>>> +            "1:\n"
>>>>>>> +            "   hlvx.hu %[val], (%[addr])\n"
>>>>>>> +            ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti])
>>>>>>> +            "   andi %[tmp], %[val], 3\n"
>>>>>>> +            "   addi %[tmp], %[tmp], -3\n"
>>>>>>> +            "   bne %[tmp], zero, 3f\n"
>>>>>>> +            "   addi %[addr], %[addr], 2\n"
>>>>>>> +            "\n"
>>>>>>> +            "2:\n"
>>>>>>> +            "   hlvx.hu %[tmp], (%[addr])\n"
>>>>>>> +            ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti])
>>>>>>> +            "   sll %[tmp], %[tmp], 16\n"
>>>>>>> +            "   add %[val], %[val], %[tmp]\n"
>>>>>>> +            "3:\n"
>>>>>>> +        : [val] "=&r" (val), [tmp] "=&r" (tmp), [addr] "+&r" (guest_addr)
>>>>>>> +        : [ti] "r" (trap) : "memory" );
>>>>>>
>>>>>> You want to tell the compiler that *trap is written. Instead I don't see
>>>>>> why a memory clobber would be needed: You access a different address space,
>>>>>> i.e. nothing the compiler can make any assumptions about.
>>>>>
>>>>> memory clobber tells the compiler that the assembly code performs memory
>>>>> reads or writes to items other than those listed in the input and output
>>>>> operands and so I don't tell here that *trap will be changed.
>>>>>
>>>>> Why this understanding is wrong?
>>>>
>>>> You can (ab)use "memory" for that purpose, but why would you when you can
>>>> properly express the operand? All that achieves is the compiler possibly
>>>> having to emit less efficient code.
>>>
>>> Then I will use the option mentioned ...
>>>
>>>>
>>>>> Alternative, I think, could be:
>>>>>            : [val] "+r" (val), "+m" (*trap)
>>>>>            : [addr] "r" (guest_addr), [ti] "r" (trap) );
>>>>> And then memory clobber could be dropped.
>>>
>>> ... here.
>>>
>>> Probably I have to return '[addr] "r" (guest_addr)' to output and use
>>> +&r constraint.
>>>
>>>>>> You also need to take precautions for not returning an uninitialized "val".
>>>>>> I think the variable wants initializing (perhaps to ~0) and "+r" wants
>>>>>> using as constraint. (Afaik & isn't necessary to use together with +.)
>>>>>
>>>>> I agree with '+' if we will initialize val with some value.
>>>>>
>>>>> Regarding, '&' my understanding is that I have to use it always when
>>>>
>>>> When what exactly? If an operand is both input and output, how could the
>>>> compiler re-use the (generally) register for any further purpose? '&'
>>>> indicates to the compiler that it may not use the register used for an
>>>> output to hold some input's value, as that value may be lost by the time
>>>> the input is actually consumed.
>>>
>>> But what is written in the gcc doc:
>>>
>>> & - Means (in a particular alternative) that this operand is an
>>> earlyclobber operand, which is written before the instruction is
>>> finished using the input operands.
>>>
>>> What sounds like if an operand (val) in our case is written before the
>>> instruction which using the input operands (and after the write
>>> instuction which writes val there are instructions which are using input
>>> operands) it is needed to have &.
>>
>> And that's indeed relevant, just not here. My crucial earlier question was:
>> "If an operand is both input and output, how could the compiler re-use the
>> (generally) register for any further purpose?" There is a case where the
>> answer to this is not "it can't". In your case all inputs are distinct; in
>> e.g. (using x86 assembly, sorry):
>>
>> int test(int i, int j) {
>> 	asm("nop %0; nop %1" : "+r" (i) : "r" (i));
>> 	asm("cmc; nop %0; nop %1" : "+&r" (j) : "r" (j));
>>
>> 	return i + j;
>> }
>>
>> using "+&r" indeed makes a difference.
> 
> I think it is clear when operands are equal. but what about the case 
> when they are different in  first  case:
> ...
>    asm("nop %0; nop %1" : "+r" (i) : "r" (j));
> ...
> 
> What guarantees that i and j will be in different registers?

They can both be in the same register only if the compiler sees respective
call sites, and can determine that the same value is passed for i and j.
This ...

> We have the similar situation in RISC-V code of riscv_vcpu_unpriv_read():
> 
>          : [val] "+r" (val), [tmp] "=&r" (tmp), [addr] "+r" (guest_addr),
>            "+m" (*trap)
>          : [ti] "r" (trap) );
> 
> With having & for val and guest_addr & guarantees that the same 
> registers won't be re-used for ti (and so ti won't be corrupted) but 
> without it?

... pretty clearly is impossible in your case: val and guest_addr can't
possibly have the same origin as trap.

Yet to repeat what I said before, and to not needlessly continue this
discussion, just go and use "+&r", despite that being unnecessary here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 14:31:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 14:31:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394233.1633063 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKr2-00017F-J8; Tue, 18 Aug 2026 14:31:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394233.1633063; Tue, 18 Aug 2026 14:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKr2-000178-GM; Tue, 18 Aug 2026 14:31:52 +0000
Received: by outflank-mailman (input) for mailman id 1394233;
 Tue, 18 Aug 2026 14:31:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwKr1-000172-GI
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:31:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwKr0-00FXA9-5R
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:31:50 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a846cd3-2eae-0a2a0a5409dd-0a2a4502ae38-6
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:31:50 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a846cd5-6ca4-0a2a45020019-d155dd2aa893-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:31:50 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47db714766aso705136f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:31:49 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5a7c55bsm12043664f8f.20.2026.08.18.07.31.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 07:31:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787063509; x=1787668309; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=CfCofe3KyBoJCN3PFQ3H3q6o9j9MJAxwTJdM1Z5zqAY=;
        b=RUNLFEdQD0PVo+RAL4Ty7IKpnZbx+xdWXEct7/iR3dWNxDO27PxyQ30sGpLFMWGKnD
         S+nLQHNKZcsjMl00gKYqSw9+OFQAJPak8jZLAIs2SZvACkEL9H9tMpaybzmrHLXzOjNj
         ClPVqtZLi22B+ID3x0dpQ5O8oIeVFxQf/OA92rmgNaAYnGPsYa0J5iTd3Q7Av3loxybW
         ngTFrkY1xBVDscdLbzhugy3px4+EqsVs7akTgAvwWmZ6GVOcXDc7OIFgWXvbaHII+Hxl
         efdI0ziCRSffNkim/qVrFqf0gzlYGQzhghjDayGOOr99120kD+SsFWLEfPIpI0AtkaCh
         JS6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787063509; x=1787668309;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=CfCofe3KyBoJCN3PFQ3H3q6o9j9MJAxwTJdM1Z5zqAY=;
        b=tEISC+cUhmB3QFMmWsd4xHvxq6WUBdVvm1QzPiSd6CYPznfj2rJGgkLjMS/SArY6RW
         8p4TM8kbnr8ZU3ljacfqlatkJ00wjx8qhErOsnSx/ZW/C6zTohm3sM0DEu+IzaIn1Ph6
         VUIJPbNDWtifXvZxcoIluYN6PBupiM/wCmyGWP8iWnKr4qcu3ZuMoTpqBreSgBmklcdf
         z/JuMFskZWYXr0F7a/oxjjqjRDl8b8L0B24bYxd2b9n1so6DCRCjE2mDJqYJwjyU+f47
         7kI6D0hVFDy/HyR2tsM7sT/WPP5gVX8D7xeWc56FZaflMfnaED4qatbjOsfR+oLoCwwh
         AS5w==
X-Forwarded-Encrypted: i=1; AHgh+RoV2Pw0QRGLSJ/NN/rQ0aT7vOsav5lE20IopBatbNudIFBY6iQdIeXprZSaizwoRIXPNYwxL8UJOSk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzSqRjfqjUklvfO6iIHpWONKUhV+LWhLc7ijWvP9zp9IpLi2bmP
	V0kUrh7hdQzyqj8Jug/VxIGpB9zecNrSk0VAPW+WCk9E9SiXqyNN+SVCsFeTvqbIiA==
X-Gm-Gg: AR+sD10oZ+KJT95P3UZdqhbyjznmukvpQ+/LzltF+Cpro2lNlRxFg+1VQQVk6sAck+I
	Mlq+NG6NNZte6YlknCCmYlI7RwjiJ6cD815tUClu0yxa5rRGpriBZKHRI60fI4FJ22iBBV00PFG
	Ny9UbN/n+T6hgObCmRt3A5Ff3m6Ugz1UzMBc675M5S7I7prI5KInI8xkI2sb++RCVQg1GWtDaNN
	dP06rbIN8bQUuCztW9NWraWSmOX3s2v///eCLl2z5Wj/fi+ic6wcFcRrFTN+4wonRrZnw5W/oTM
	jFHxTkY58/2hicgFDFfhKR/Jd+0NqYLt8y2QzJ22K7bhbbQIOKEmBOgLu+EP10W8c5y9teyOQml
	GllqmQ/3MJwVJYun+0uVZ2YAJyYzhcbNA+42TWn4c2T3PH4+pBEaXsksMcnbCka45oIUiPovRhB
	hZGM8OYV63U3jQeC7s1uowIMa04J36QdPIwf+egghMZIdc+mmrKafV+M2kOHnnCnvywL9s3Rw4b
	It1/KCRrLFjdRAAVWn5O524ITMJGYTDVZO2LOzxxj065D3sRBVJ
X-Received: by 2002:a05:6000:2881:b0:47f:7fe0:a287 with SMTP id ffacd0b85a97d-482aaa5fe04mr10184190f8f.2.1787063509508;
        Tue, 18 Aug 2026 07:31:49 -0700 (PDT)
Message-ID: <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
Date: Tue, 18 Aug 2026 16:31:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated
 panic()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787063510-F34BE2AC-BDC93B56/0/0
X-purgate-type: clean
X-purgate-size: 1557

On 18.08.2026 15:07, Andrew Cooper wrote:
> Panicing in the case of a timeout turns out to be about the worst possible
> action Xen can take.  It leaves all other APs waiting on the condition
> variable, some in NMI context.  As a result, they fail to be shot down and
> dump state for kexec crash analysis.

At the same time there likely isn't much to be learned from a kexec dump, as
the source of the issue is in the CPU, not in Xen.

Further, this code runs with the watchdog disabled. If there's truly no
progress anymore, how would one know from the outside whether the system is
dead altogether vs the control CPU still kicking around?

> Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
> excess of the of the arbitrary 1s Xen allows.  This time is spent in the WRMSR
> to load the blob, and there's nothing the system can do but to sit and wait.
> Despite the delay, the system as a whole does survive.

For this I wonder whether the log message issues after 1 sec is adequate. If
we know things can take this long, wouldn't we better issue the log message
no earlier than, say, 5s * nr_sockets?

> Microcode loading occures through admin operation only, so get rid of the
> timeout completely.  It does nothing but make a bad sitaution worse.

Worse when taking one perspective, yes, yet a silent hang also is worse than
a panic() telling you what was wrong.

This is a tough one, with - likely - no really good options. And establishing
what's "least bad" may also be difficult.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 14:41:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 14:41:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394240.1633071 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKzs-0002oJ-DC; Tue, 18 Aug 2026 14:41:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394240.1633071; Tue, 18 Aug 2026 14:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwKzs-0002oC-Ad; Tue, 18 Aug 2026 14:41:00 +0000
Received: by outflank-mailman (input) for mailman id 1394240;
 Tue, 18 Aug 2026 14:40:58 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwKzq-0002o6-JY
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:40:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwKzp-00C0P2-JW
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:40:57 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a846ee8-8faa-0a2a0a5109dd-0a2a4502a830-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:40:57 +0200
Received: from [40.93.198.19]
 (helo=CY7PR03CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a846ef7-6ca4-0a2a45020019-285dc6133339-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:40:57 +0200
Received: from BN1PR13CA0020.namprd13.prod.outlook.com (2603:10b6:408:e2::25)
 by DM6PR12MB4330.namprd12.prod.outlook.com (2603:10b6:5:21d::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 14:40:52 +0000
Received: from BN1PEPF0000468E.namprd05.prod.outlook.com
 (2603:10b6:408:e2:cafe::9b) by BN1PR13CA0020.outlook.office365.com
 (2603:10b6:408:e2::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 14:40:52 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN1PEPF0000468E.mail.protection.outlook.com (10.167.243.139) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 14:40:52 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 09:40:52 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 09:40:51 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I0AjZs0LNxrB1lC5lhIEO6r46r8jSYPYOfb08bFJOHrUx1+gchthtVvVYSnermaDDvgvQ/v+n1aGAyGuMR0pHRQ4fRiYk8ABDlPu+TESpggkIIz4mEeQ9JBPbFmd8/q6UTmAu1sukwq4c8YXyb3qkfdzghaDN228k3tzW/5wOaEp40J0qMq/rD9S3uC3HEIe5glHZC6b9K73B+yJvrwo5lfR+rmB7xXpddn1jLx/GY/Vl99QS7qLPwPGgCfv6m6fNtrRjF0KZTOAqfi2U/DmU0f7XKeej/ywWWmFLJxXhe69s1/nJqwrp0LPn4GoK31tiFxhtvZZy/J4+b+ykoLyPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qBoiOGtufWp+jsiy8lRgE3KmXZlt92Xy9zli4/jVRT4=;
 b=cCUXQfMvfOplxAUGbjbes9ByM1VVodrcvXTDehHy64HOdiFLqD+A/4u23AXyhfHQWrOMoreJ1ALlk8RcDTUZgUy5zaPxp1eNv1O6plCUnICEYW4Abi9QLJrszawXFDvF5GRT/2aM532fWSk9EhBQXbSNPLzl0WnqFs0PvMnD4bg4Y2JUp9sVARiEQ3hhqbKsXHSE4fA2Y8gQOD9BmuTDrjd/Szfwy4m8rjp68NXke7JR8ULDyzsllJ7VSAB7C83Z+WXNHUbmNHl/uEyBEmarg8Em2Pmpn5+pKbjWcOhAYItd0+lcjefJnna14cjPNAMnKjB4bFYbOs+1OSsO/pYweA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=qBoiOGtufWp+jsiy8lRgE3KmXZlt92Xy9zli4/jVRT4=;
 b=2tdjREW0sduhMnTKM07Ex/Hu4MDVfPeJCwVJ8Gz50T9ITIJwg8tCJpywABFujT4QKBLN3X2Cy6hFCpRH+rLzvDDvxBvRDgDqOs0AuJS/2o1gtBNV2ucryxsnDCWxN9PheeHi2qPszSYUftQIKr3j0RQAkGxE321uyGhoxPS5JT4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <ec0800b0-cb65-4b75-b13b-69a90cec75ca@amd.com>
Date: Tue, 18 Aug 2026 16:40:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm: derive GIC CPU interface ID fields from the
 vGIC
To: Mykola Kvach <mykola_kvach@epam.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>
References: <e8841a943eb7f6a64348b7316032084fb848bc2b.1787040666.git.mykola_kvach@epam.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <e8841a943eb7f6a64348b7316032084fb848bc2b.1787040666.git.mykola_kvach@epam.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0000468E:EE_|DM6PR12MB4330:EE_
X-MS-Office365-Filtering-Correlation-Id: 5c314a54-cb64-40d1-775b-08defd36b42b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|82310400026|1800799024|23010399003|376014|5023799004|11063799006|10067099003|56012099006|6133799003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	CO0CXD+WdCDo768J2Rcm8Zvz0TgUezvvdMeHY6+gR5AdK6iA51UfzVIHgILFoqHqmX15PMmgWyCSj8A33xYvT3JbhR25om8crQhkUiMueYnLUtD+XgMKhhC16xY9/nnqdW83jTHGg7K2Uju3Rbl2Fr4BXLrV/HoYPNtOLNuv6XGu1ziLH4dmAqwt6Txi8gHwm2sBijHSOx4Lig9lfD0o8GP11Eccd8klv8XI6opZns0VEdM0KBUoUeNX5OrlHYqLmNH95vkGLiSUwta6BqlWsI3vK2QdjqwKHym7kFsaPvSD90FifdmBFoeyV+aW27qaS6Wa7jsDO3m22hrxS19HMb7Xrz05XTPHbUxMtlsjVmvb69DIBlGsKNIcLJJGCjX/lDG2qDO+RMh1J6pK9kjGdhnSg9R+1TS5pUCVp6yMRyNj6pE1TplEKdogT1yq8aVeupXek6azmwd/G00Kuk7sBzqhokctzhDdL3ijpcVJhvrSVBoVlfHz3zBFtf4pXLCWvjK51nHQpk4aZKnasGo88U+MnXI85J81LDbrKvL2G3JMpzHOYcad+GzFnY9Rd8+wUVMfM4rUrKPnyhTvTuK7D1MyKQER9kEaeClD2UT8sYaLEK1Wb5+d0A4YgsNKNzwnvLVq1QT2JYcVpgUwJQ66Ew==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(82310400026)(1800799024)(23010399003)(376014)(5023799004)(11063799006)(10067099003)(56012099006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	HbGON6NkIlmc9m46ZBFbENqvFuZCZ+uTSaxBwPr2enA0O00qh4C24ZhblBExd50wnrg0BA4FlqU3mMHIri5/SMn3p1GH6x7xmliN0z0qLt7Drg3QyUN2c4x0SWV/h5BHrB6d+gfKH29a9F2dSGoL5uigihPwUtySJoULS11zC3+V/9tTSx8u6x0+g0b4GYLGJyCYwWTzXl/cO/2tR721571wuj0Dthz3+lC4/AnM9j84JJ+Hs6+PNXVD7bB4UHrOp0Lc/HHr/7DQRNlMpDaKMy0KUkiwvVRkOfidXPVzMPh3IMYbHkMsGNtevrOF/MI1zOdOfbYiGcT+oWCKOPrPJbFKryOgsh1fqTUmyW9HYhae/jZk/6Kkff5FstrraFFhmxu3p9ssaHwiVEx9/M02qiIzcwSsisP80ZpN3llPEbVToMxDNYugQj56qsuywNM+
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 14:40:52.5577
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c314a54-cb64-40d1-775b-08defd36b42b
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0000468E.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4330
X-purgate-ID: tlsNG-720697/1787064057-30FCE2AC-DD9EEE3E/0/0
X-purgate-type: clean
X-purgate-size: 6885



On 18-Aug-26 11:19, Mykola Kvach wrote:
> Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo,
> which is initialized from the sanitized host CPU feature state. This
> does not necessarily match the virtual interrupt controller configured
> for a domain.
> 
> A vGICv2 domain can therefore observe a nonzero GIC field when the host
> supports the GIC system register interface, even though Xen disables that
> interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can
> observe encoding 0b0011, although Xen exposes only its vGICv3 model.
> 
> Derive the fields from the domain's vGIC version instead. Expose 0b0000
> for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the
> ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through
> CP15 in AArch32 state. Leave the alias unchanged when AArch32 is
> unavailable.
> 
> Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
> Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v3:
> - Add direct dependencies for the shared ID register helpers.
> - Move ID_PFR1_GIC_SHIFT to the common CP15 register header.
> - Apply cosmetic fixes from review.
> 
> Changes in v2:
> - Share the GIC ID field helpers between the AArch64 and AArch32 paths.
> - Parenthesize the individual ASSERT conditions.
> - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable.
> - Target master instead of the 4.22 release.
> 
> v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/
> ---
>  xen/arch/arm/arm64/cpufeature.c          |  1 +
>  xen/arch/arm/arm64/vsysreg.c             | 18 +++++++++++++++-
>  xen/arch/arm/include/asm/arm64/sysregs.h |  1 -
>  xen/arch/arm/include/asm/cpregs.h        |  1 +
>  xen/arch/arm/include/asm/vreg.h          | 26 ++++++++++++++++++++++++
>  xen/arch/arm/vcpreg.c                    | 12 ++++++++++-
>  6 files changed, 56 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
> index 6fb8974ade..8bae8915e8 100644
> --- a/xen/arch/arm/arm64/cpufeature.c
> +++ b/xen/arch/arm/arm64/cpufeature.c
> @@ -72,6 +72,7 @@
>  #include <xen/bug.h>
>  #include <xen/types.h>
>  #include <xen/kernel.h>
> +#include <asm/cpregs.h>
>  #include <asm/sysregs.h>
>  #include <asm/cpufeature.h>
>  #include <asm/arm64/cpufeature.h>
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index d9e3619dfb..4fb50b6972 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -20,6 +20,7 @@
>  
>  #include <asm/arm64/cpufeature.h>
>  #include <asm/arm64/sve.h>
> +#include <asm/cpregs.h>
>  #include <asm/current.h>
>  #include <asm/regs.h>
>  #include <asm/traps.h>
> @@ -298,7 +299,18 @@ void do_sysreg(struct cpu_user_regs *regs,
>       * to identify the processor features
>       */
>      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
> -    GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
> +    case HSR_SYSREG_ID_PFR1_EL1:
> +    {
> +        register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1];
> +
> +        if ( cpu_feature64_has_el0_32(&domain_cpuinfo) )
This check deserves a comment.
> +            guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> +                                                   ID_PFR1_GIC_SHIFT,
> +                                                   v->domain);
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  guest_reg_value);
> +    }
>      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
>      GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
>      GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
> @@ -337,6 +349,10 @@ void do_sysreg(struct cpu_user_regs *regs,
>              guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask;
>          }
>  
> +        guest_reg_value = id_reg_set_gic_field(guest_reg_value,
> +                                               ID_AA64PFR0_GIC_SHIFT,
> +                                               v->domain);
> +
>          return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
>                                    guest_reg_value);
>      }
> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
> index f3c11d871e..c0a6827b08 100644
> --- a/xen/arch/arm/include/asm/arm64/sysregs.h
> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h
> @@ -438,7 +438,6 @@
>  #define MVFR1_FPDNAN_SHIFT           4
>  #define MVFR1_FPFTZ_SHIFT            0
>  
> -#define ID_PFR1_GIC_SHIFT            28
>  #define ID_PFR1_VIRT_FRAC_SHIFT      24
>  #define ID_PFR1_SEC_FRAC_SHIFT       20
>  #define ID_PFR1_GENTIMER_SHIFT       16
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index a7503a190f..79203324fa 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -114,6 +114,7 @@
>  #define MPIDR           p15,0,c0,c0,5   /* Multiprocessor Affinity Register */
>  #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
>  #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
> +#define ID_PFR1_GIC_SHIFT 28
It does not look nice to split CP15 encoding list with this macro. Furthermore,
it looks a bit odd to move just GIC and not the other fields. Also, how about
moving the block to asm/sysregs.h? You would not need to include cpregs.h then.

>  #define ID_PFR2         p15,0,c0,c3,4   /* Processor Feature Register 2 */
>  #define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */
>  #define ID_DFR1         p15,0,c0,c3,5   /* Debug Feature Register 1 */
> diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h
> index 387ce76e7e..bb6c904f2e 100644
> --- a/xen/arch/arm/include/asm/vreg.h
> +++ b/xen/arch/arm/include/asm/vreg.h
> @@ -4,11 +4,37 @@
>  #ifndef __ASM_ARM_VREG__
>  #define __ASM_ARM_VREG__
>  
> +#include <xen/bitops.h>
> +#include <xen/bug.h>
> +#include <xen/sched.h>
> +
> +#include <asm/gic.h>
> +
>  typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
>                                     bool read);
>  typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r,
>                                     bool read);
>  
> +#define ID_REG_GIC_WIDTH 4
> +
> +static inline unsigned int vgic_id_gic_field(const struct domain *d)
> +{
> +    ASSERT((d->arch.vgic.version == GIC_V2) ||
> +           (d->arch.vgic.version == GIC_V3));
> +
> +    return d->arch.vgic.version == GIC_V3;
Wouldn't this be a violation of MISRA C R10.3?

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 14:46:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 14:46:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394248.1633080 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwL4m-0003Py-3E; Tue, 18 Aug 2026 14:46:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394248.1633080; Tue, 18 Aug 2026 14:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwL4m-0003Pr-0b; Tue, 18 Aug 2026 14:46:04 +0000
Received: by outflank-mailman (input) for mailman id 1394248;
 Tue, 18 Aug 2026 14:46:02 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwL4j-0003Pl-SD
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:46:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwL4j-00C16e-4m
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:46:01 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a847028-e002-0a2a0a5209dd-0a2a4503c284-0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:46:00 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a847028-fae8-0a2a45030019-d155dd33c531-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:46:00 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so3121079f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 07:46:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7834dsm12517790f8f.28.2026.08.18.07.45.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 07:45:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787064360; x=1787669160; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=gjbvGHWsfYFg6XEBRxXMeyukweaBaztj01wqpgRPlk4=;
        b=KXBIaVoM9AByNohDgYsJbymmggKOnw2KQiLwtkSo9ZBLTqx0LwBLbA60dOJ1vyjXd2
         8Mh9DnICbhtcqxdeZ51FySvCgJ0cEB6Kw49MDI/AM/fQclBl0ZlwJdPqHswKYtNdTAz3
         i0GLmv5ZZ1oIJJFCw6Q/ikfelvoE51Vi3dGI5jo61DvyvtiP5vkcMY/un6NMc4r+TTCH
         +grkd7iqHg/MxE7Szt9EKme+6B/wgkzT9Z67jlk/74qk2Rx6xU/COkCMbQZUJngrypyB
         96Cg0+jgt+sMWILYlj5RcywwcMo+m5i7x3ErtcAQaaNRxAxW+e2vSHrXnk5OeibAdzns
         kT9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787064360; x=1787669160;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=gjbvGHWsfYFg6XEBRxXMeyukweaBaztj01wqpgRPlk4=;
        b=mgEbGjf95lCKaQ/FOIGsk4brnBL2BYhEJZlHExlp4nMVUkpait+2liWQ2Chvh5i09o
         s+n/kobTR/c8usEm9BH7EB0DKD6WvZ72NDCxpxpUmew/lrKnlxPeVa94j0vfnxqk7UV4
         xWGCwhlN4ODcONn9aLOp2msQ/fHXK+cz8u3RWY95IRWfAQWJsvIG9RGlRIY8wU/tGg/H
         38SFwEKeBk9ihWIA0p8p7USusnNMPb6gmfpUCQVsdR8j7GZb9CkOCrygK0jJzymsnu0Y
         aH1lVAqGN3G7mC42krELn8qs9PHH7cFA/iPg6H2mEmhExYvYfst12ZbNAWnbI3WgHTas
         LQQw==
X-Forwarded-Encrypted: i=1; AHgh+RrCxMk9hzr9N7FSrtCizTmbavi9hz6OrQ9Pe7w/QvQSP+bu7+XcN9EshD1swP+MWn7u9ymMtk4vxRI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzybno1U6dxRH64wQMJcmFXVzuqCpiplQDgNVC7s6aW1t9/3n0G
	J2NWh4Og5I49EX06gRpWEopBCd3/KsTWBBF/W/olgSIEy6oUdVhl7ct5Hd/viVWOyw==
X-Gm-Gg: AR+sD13UBKVwBNVJKOjv+UEw2+sRjoe4EOmiwl55qQ+JzgSsogmcVn5/OQvlw+eI0bp
	Cap7kqjAv1aNQqXPIp75j53Q11tdPJ0SJS7V0/nsugOZ0CVwwoh08uBSTfAkNM5GtnVIWtbPjPm
	20roFc8FVTtVZlL0oFAQeHgbPkSNnVRupV2k5kOtvD51Wc1pgVQtIw+rqs8FQ2UbSl1oKy6Bhdy
	II4epAyPf6qjoNOjOU8TlGPjqabKg8lutZWUU9teJi/UpORPIha104jI/oF+yETeChKT9Km5+zr
	7gNHCmyfo1VbEdbWlvwJFxFTdiQl2i2P1Y27bniN8AhG4/qXVaFETmYOZ7gNdI2thj80t1TKsVy
	ZFx+F/EvxmHst0VibSCIbd4dezOTgTXqAO44Rao3ZdO0i+zak6AEmWEn7M5D/ekhxZP6R9j9Nyj
	mbvbr7e6mrEPS/zzCBaBSURoviZvS+m7Lch/+0W5+Zd5RQlem5hplHmGwwHYmW5eCIrYi4ImaBq
	eAlk5BBsz65CMmX9UqV1EXjbdn5vuDlzMPAFA==
X-Received: by 2002:a05:6000:230d:b0:47f:8ce7:8684 with SMTP id ffacd0b85a97d-481607100bdmr59106215f8f.6.1787064360018;
        Tue, 18 Aug 2026 07:46:00 -0700 (PDT)
Message-ID: <d1498f93-1b6e-4113-9473-efe9bbc53b93@suse.com>
Date: Tue, 18 Aug 2026 16:45:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/9] x86/passthrough: Extract pt_irq_dpci_setup() from
 pt_irq_create_bind()
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298079.8631fc262581453bbf619ec5b2062170.19dcf387f6f000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298079.8631fc262581453bbf619ec5b2062170.19dcf387f6f000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787064360-77EC24E9-B407A8CC/0/0
X-purgate-type: clean
X-purgate-size: 2251

On 27.04.2026 15:54, Julian Vetter wrote:
> @@ -238,10 +242,11 @@ int pt_irq_create_bind(
>              unsigned int i;
>  
>              /*
> -             * NB: the hardware domain doesn't use a hvm_irq_dpci struct because
> -             * it's only allowed to identity map GSIs, and so the data contained in
> -             * that struct (used to map guest GSIs into machine GSIs and perform
> -             * interrupt routing) is completely useless to it.
> +             * NB: the hardware domain doesn't use a hvm_irq_dpci struct
> +             * because it's only allowed to identity map GSIs, and so the
> +             * data contained in that struct (used to map guest GSIs into
> +             * machine GSIs and perform interrupt routing) is completely
> +             * useless to it.
>               */
>              hvm_irq_dpci = xzalloc(struct hvm_irq_dpci);
>              if ( hvm_irq_dpci == NULL )

This wants to be part of the patch increasing indentation.

> @@ -269,15 +274,36 @@ int pt_irq_create_bind(
>           * We MUST check for this condition as the softirq could be scheduled
>           * and hasn't run yet. Note that this code replaced tasklet_kill which
>           * would have spun forever and would do the same thing (wait to flush out
> -         * outstanding hvm_dirq_assist calls.
> +         * outstanding hvm_dirq_assist calls).
>           */

This would also better be part of the earlier patch. And this block needs re-
flowing there as well.

>          if ( pt_pirq_softirq_active(pirq_dpci) )
>          {
>              write_unlock(&d->event_lock);
>              cpu_relax();
> -            goto restart;
> +            continue;
>          }
> -    }
> +
> +        *hvm_irq_dpci_out = hvm_irq_dpci;
> +        *pirq_dpci_out = pirq_dpci;
> +        *info_out = info;
> +        return 0;
> +    } while ( true );

do { } while ( false ) (as Teddy suggests) wouldn't be much better. Why not
simply for ( ; ; ), as we have it in quite a few places elsewhere? Yet then
I'm not overly happy to see this secondary change (to complicated code) be
folded into a change of entirely different purpose. Please consider
(further) splitting.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 14:46:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 14:46:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394254.1633090 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwL5Y-0003qU-DO; Tue, 18 Aug 2026 14:46:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394254.1633090; Tue, 18 Aug 2026 14:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwL5Y-0003qN-9R; Tue, 18 Aug 2026 14:46:52 +0000
Received: by outflank-mailman (input) for mailman id 1394254;
 Tue, 18 Aug 2026 14:46:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwL5X-0003q8-BK
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 14:46:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwL5W-0034dU-OJ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:46:50 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a847048-bab6-0a2a0a5309dd-0a2a45089ee6-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:46:50 +0200
Received: from [52.101.62.61]
 (helo=DM5PR21CU001.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a847059-f659-0a2a45080019-34653e3dda21-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:46:50 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by IA5PR03MB989630.namprd03.prod.outlook.com (2603:10b6:208:609::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 14:46:47 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Tue, 18 Aug 2026
 14:46:47 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uD9Xt7RlGqU8GFU79Fm3Hrg8JE5RbTbd4qGdOLP2ahG17gidM/nxJVjBcbGKjXyo/cXHSBS/riWE+BMYYQgs+hCVE77dmeLbJCOmhLdXxZ8RF9EYZDUKLB/xbR5YuXoXL2yEFexD6AlScM28SvXFghf7/cwM4FRetVPBVEBOngOmCwLfe4DMfve82oJyJZTuq5Au7yd7OyTanH4Z9AMahzaVP9KyEVLN7jqxW/oCH6hgOLocxDkOd9CdEFyvn87gKEz0Sj6Ez/e7AmIE4fxsnAZF5lIeRqsN9lSXTModNc4IedZdCb1q4Y3o4ERrm/NX50l1WPZuWSxsbFL19BhVcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EUudSj6anH+iJ8NvmFFxyu2/+1c5djuuya9xz5CiJN8=;
 b=iJjpoTOHWlv6MXMBMimN9ZH0PILVMdei4gAxK0ESwrDBaDOiHj9tZDgpzbjSRkwMffalRfWfiWHzZxfJjL8O65wr3XjbOpvvwj9sBs1M5vwssgKxoozSnVJQsGv2VJAZ/ht5QBCdUW4xCn5rxmYLOiMdZXmt4HczXs7duc8Y6WjuxNea4JXw81sPbwouP8cqc5ieqsvU/S64ALz9NrG0teZWAOZoGXfgFhYM+clXM7cVY3xlPIWsbxBWT6bXsY30pphxjOF8SXO9xL8KB1QfKA9cPPTtlYAs8WTjttGzj+aikwZIKX0OwI1hWHqYDuwmB123Io7fzcC3eaMsN/G30Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=EUudSj6anH+iJ8NvmFFxyu2/+1c5djuuya9xz5CiJN8=;
 b=BDlEP3WOwUM7kD0dPxZ4wdpNOClB+B0U87NitgiscXVpWCFzTUhq8z+4ZqHK8mYwIpHKMnObYA2RbZuqPPOeXrk7gkVDr9Iaw+tpJQfXmbIBVggiQFwQHxnfm1j94n6qB2QH9kzV5mjOy9m+X24HLJ7qZgpp1qv7RvvKvy3I0tU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <07151e7f-3179-4432-b7fe-e70890f1ba4f@citrix.com>
Date: Tue, 18 Aug 2026 15:46:41 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Jens Wiklander <jenswi@kernel.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
References: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <d739485a-72cc-4518-afa9-8d2692a225ae@citrix.com>
 <7F03E2BE-44A0-41E9-850C-8480CA0C8F0D@arm.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <7F03E2BE-44A0-41E9-850C-8480CA0C8F0D@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0677.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:351::20) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|IA5PR03MB989630:EE_
X-MS-Office365-Filtering-Correlation-Id: d4bb7a56-a21c-4cc3-d620-08defd378751
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	iUp/UtTXJWkPASoapwdMFRrZw85rM37nzgWsGJv+YXMGe2MiUhhmRMuJ/pONIuvT90IF6TeT4D/2coWZP9cuHYLooEodm9BmnuG7gGr4sdm1jcr6aVyCNlMVv2X/gG4ULOw9OWaZ9K4dXUuE7jQzw/ldJSPrvW9HbELcME8z45v07oWRitQvvTyW565WJV/p0PwHRte1+V29x+D5WnR/J0QiC7AI+XEVKM82b7jk9wbCaUKboNnlzf+uwrmbawj1WjUlJrauaTdG5tXrwbHvSLxwKFeqpBPoYs1jBP2Gb/u49oSTYVDauaaXmTtiDynSbAnzvQnolb4kPMZeOHR2y0WiDXxQWGuNUsCI403pbl3azebXZYfFs3FaCEb1iKUQvOVNKqFY2ZjtPiTdq6eAxP/5auw25LHWa1QKztg8Qi/p7kuFy0sREYuqcbLRy6arwz3Xpbk9LKkWrgAC+ok+AXVpAwaDmn7SU4IY1uS4yHNciykJ5gI31DiWqjkBVUEFgqK8VgNPqDXKh+cK8xxt3m1FVkZu+bYQppUKcaQIQGzRPZ8HT1zVvmME1cFzQscN0twU5L2x35q8Blk8pA/Josg3mZX7Vav6LOR13JuDdEj1fzKliqErSMQXCZ407gBZuumQwdW1OaaKQzP+ZmuglwM91rMFq9aSuXizDjIu7ug=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SjNzL1hlU3RudERlZTFsVkpIK1NFRUg2TEQvR05tT2U1VnBoRW9NNDZ2Snlt?=
 =?utf-8?B?V0p3TURReEhPNjJrVjhRZVVjS0M4ajBnZjBHTStNeS8weGwxTDl1a0FBYWwr?=
 =?utf-8?B?WTA0Sk1HOXJ0d0ZEN3Y4TzNXZTFpWWRzNThQd0dMa0MwUHBnYm5ISDlLWDYz?=
 =?utf-8?B?YWVzYnBhZGdBQVpvUzZUbFFpSEZ1d0l2bi9NM1ZQUUg3cHBhcTBJVnlYTC9v?=
 =?utf-8?B?SlVkRXFRM1ZON1Jnem42V0ZKWVc1by96L0hTZVRIYm80OU9RSnFBeHpMeDU2?=
 =?utf-8?B?N0JMTlpaSW8vSVRkUmswSmRIcFcxTnI2c1pBdUZTOGZINVQrYk1wSkUrYzdL?=
 =?utf-8?B?eE5TdWZsbStKOHV2b0JrRC9PU1BEM1F1OGFUVGt1bXpkWTZGSWNRZ2xGYS9V?=
 =?utf-8?B?OU5ST1l6N1kwalJ1c0FQMFlxN1I2R0JjMGNzclpSc25xNE5HOWRWWk5DYm5w?=
 =?utf-8?B?OUUxelRpSFNzYXd4WW5ZTlhNcXlSZjVIRWp1Z1krR29vL3BkNzhtWVlHSXZn?=
 =?utf-8?B?cVNBMGwvRDJiNVp4ZytOb1A3QWFGblBLbExGRUhjREtxZ25QSnlsZDBrQklO?=
 =?utf-8?B?T0pGc3ZYaWZKcFNzVDlkemx1QTZFUHJ1ZEc2OWY5MjdIdnFHaHdPdTQxVEYv?=
 =?utf-8?B?ZVp0UXVMUkIySnBBd1dWaCtlVDIvVkpNcFFBemRXVXZBM2NOV3p5cS9SQzdV?=
 =?utf-8?B?VW9IdXExNkxVT0x2eGNSMDlnOTZXZURKNlhsMEIzaFRQNFhuUjBMbEhjM1NE?=
 =?utf-8?B?L0xsU01jaEliaHFETUNnWmdRaFR4OHZQTVo2anc0U3FBUFR4R0JCOGY1RUM3?=
 =?utf-8?B?RTB6dWZuWXhadlBQZllmc2pQVXpjUEdwdkE3Uk1vNVJvbjRhV0tyWDNpUzEz?=
 =?utf-8?B?ZW9tWU1xZVQ2UmpCV0JVSnRqd0JXMHFPemZqNVBZaUV2eThSNEpteGN2Snpi?=
 =?utf-8?B?dTZNbnVDVGpEb0IvUDVrbXRMZjI0VlRzbE9XeXBQRjI0MFJkbVMrcjZRQXdz?=
 =?utf-8?B?V3Nab0hGL0xsbE5sUXhTeVh5R2ROdVE3UGJUbU5rOHdCUzlpQWZWaTRBdzl3?=
 =?utf-8?B?dG9DTi9kMFFValZGU2NsVTNtcWZ2UUNDaTFOK01nYjBqUzFhdFBxY0NtZlha?=
 =?utf-8?B?Q0lLTS80dzFWZXEyVUN4aDNCbk15YXF4QXBZUmJ2WENjRGwvU0g3WmdjbU84?=
 =?utf-8?B?UW9jNlRLTEdXYzIwVTQxdUVlclpUNXBMMTVYU2VpalFJSzB2UGtxQmc4SEt3?=
 =?utf-8?B?S0srSVJ1T29sNUpEV05ISGJZUE0rTzZsbW1DNTRXV3BpVXZTNlBFMncrampM?=
 =?utf-8?B?VlJXaC9lNHJPV1VqemdmYU9vWVVoSFVFWW1TWjBwQVc4L2ZPNVZicUJCZjY0?=
 =?utf-8?B?c0NDRmpRWkVDU05xRXB5Zi9pRWJ0enlsT0tMOFhaYmtRUHJPYWNyWDVqbEdh?=
 =?utf-8?B?VEhqRVZWc2d6V2NZK0E2U2c4dHJOMHNDVW5GWlV6VW43TTluMng1eWNObjY3?=
 =?utf-8?B?alJpaUNzd0t4dWZmK3JEVGorOWxldDVkWTRlTE1vRWgyY0twa0ViVFpxMFNa?=
 =?utf-8?B?THhCRmU2NGJJYUVZWmlVM0YzSzBKR1ZzQk4zU01YY1BXZjRoZlZKYXk2UEdV?=
 =?utf-8?B?bGhnYkJuU090ZWZ4RFhWZDE2Z2tNbGNoamprYlVkZWlnS2VSbzlhU1M1NVZu?=
 =?utf-8?B?SEZTVXBvclNaYzFRUGtmalYrcFdpWnBuaHN5ajdZT3FvYkJQOUNnNVRnYjJz?=
 =?utf-8?B?TzVqbTBDY3R5ZXRQMHZDWk0zdXdEeTFzOFNZak5jVDIwa084K3RkZnU4U29Q?=
 =?utf-8?B?Y3NmRUFabTFVeGd3RmJGWGkrOFA1VzFzWno5SXBNOGpvdWhNRzVpd3pRY1Fk?=
 =?utf-8?B?NC8reVUzSXFTYlFpNGtKLy9GRVJEUFYrZUh2bGZHckxpQzMyUGJYSytQRWpC?=
 =?utf-8?B?dWxJZnBmdEJKUmovd1JxdGp5UnMwS2UxNWNEQ1ozbXQxazR1QW5YcUxGYXZF?=
 =?utf-8?B?Yk9NNjE5ZHhUSkIrR1Njd1RiRkl2aWxraUUrelYwT3liRHRwUW5QWXQvUm1m?=
 =?utf-8?B?YkY0OW1iRFpoSjkyTW5GdDlkd1ZlRGgwTkkyQ3FLcExJOGE3ckVqaVF1S2xK?=
 =?utf-8?B?RXlEazJoczZPMjdnazhtOXdHZnNzbVB0VCtSSWxyMHJLU1UwaW1mNVV2bUo0?=
 =?utf-8?B?VDlpL25NaVUwR2huNXBubmpHYzU2VE8zWC9pVXg4RnlxdS8zUkhhd2RPSmxI?=
 =?utf-8?B?c3QyLy9sSStlS0hyejV0QmtLNkdCQ0FJamZLaSswM3BoN2d4UEdlOXVxSHdl?=
 =?utf-8?B?bURTMDU1ZzJIaXJBc3BwN1BnaXRXeXhHZ0krcU85RGhDbjhQc3pTZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d4bb7a56-a21c-4cc3-d620-08defd378751
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 14:46:47.0081
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9wBA25HXjbVVtOlmro0hs5gbYbH/M9FQ2qE/YbgxE2cIxCLxwG1N47GGvLRyivF5DPRw5y18LVzPGR2Rgl4W9q/FnErQGMvYOGokptrH/Sk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA5PR03MB989630
X-purgate-ID: tlsNG-c1860d/1787064410-D715E87B-8EA4ADF3/0/0
X-purgate-type: clean
X-purgate-size: 3078

On 18/08/2026 2:28 pm, Bertrand Marquis wrote:
> Hi Andrew,
>
>> On 18 Aug 2026, at 14:40, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>
>> On 18/08/2026 1:16 pm, Bertrand Marquis wrote:
>>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>>> possible vulnerability.
>>>
>>> ffa_handle_msg_send2() copies the message header from the guest-writable
>>> TX buffer before validating and using its fields. A plain structure copy
>>> does not prevent the compiler from re-deriving later field accesses from
>>> the live TX mapping.
>>>
>>> For VM-to-VM messages, msg_offset and msg_size are validated against the
>>> source and destination buffers, then used to copy the payload. If a
>>> sibling vCPU changes the header and the compiler reloads either field,
>>> the checked and used values can differ. This can cause an out-of-bounds
>>> read from the sender's TX buffer or an out-of-bounds write into the
>>> receiver's RX buffer.
>>>
>>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
>>> default. The audit ranks the likelihood of such a reload as low, but the
>>> C semantics do not guarantee that later accesses use the stack copy.
>>>
>>> Add a compiler barrier immediately after copying the header so that
>>> validation and use consume the same snapshot.
>>>
>>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
>>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>> ---
>>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>>> index 1eadc62870f2..39f561c8237f 100644
>>> --- a/xen/arch/arm/tee/ffa_msg.c
>>> +++ b/xen/arch/arm/tee/ffa_msg.c
>>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
>>>
>>>     /* create a copy of the message header */
>>>     memcpy(&src_msg, tx_buf, sizeof(src_msg));
>>> +    /*
>>> +     * Make sure that "tx_buf" which is shared with the guest isn't accessed
>>> +     * again after this point.
>>> +     */
>>> +    barrier();
>>>
>>>     src_id = src_msg.send_recv_id >> 16;
>>>     dst_id = src_msg.send_recv_id & GENMASK(15,0);
>> This does look to be adequate to fix the potential issue, but you should
>> drop the ACCESS_ONCE(src_ctx->guest_vers) a little lower down.
>>
>> With a safe copy on the stack, there's no need to further inhibit
>> optimisations around it.  In fact, it's unclear why e040b94d0fff added
>> the ACCESS_ONCE() in the first place, seeing as it was already an
>> on-stack object at the time.
> the ACCESS_ONCE is protecting the access to guest_vers which is not on the stack
> but a value on an internal context accessed by all VMs.
>
> You probably mixed src_MSG with src_CTX ?

Oh, maybe.  Those really ought to have more distinct names.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:10:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:10:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394267.1633099 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLSZ-0008Jw-69; Tue, 18 Aug 2026 15:10:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394267.1633099; Tue, 18 Aug 2026 15:10:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLSZ-0008Jp-3E; Tue, 18 Aug 2026 15:10:39 +0000
Received: by outflank-mailman (input) for mailman id 1394267;
 Tue, 18 Aug 2026 15:10:38 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwLSY-0008Jj-D3
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:10:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLSW-0039Az-IH
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:10:36 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8475d8-8faa-0a2a0a5109dd-0a2a45059f86-30
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:10:36 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8475ec-4cb1-0a2a45050019-d155802dc943-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:10:36 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so32187055e9.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:10:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49996100184sm305073375e9.1.2026.08.18.08.10.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 08:10:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787065836; x=1787670636; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=kG7Zaffwl0mxSN4K5nDR/1mjY7t5FTHW4GrkGQ7+s74=;
        b=KzQ6SXdycJE0W+Eox4NFTl7aAtmnyorqsO5lNN86CPTjrfuBY/Vpbsy/hp64hEczbZ
         owLsXTiIrVaZLi51bqoA2/FnnXUv42A7tdW3T0999AZZ2MDoAkOhaH4s0IoxRlXwAwIC
         rfUZVMVolenOFZz6the14ilpHnksCI/Wg7MxlDHSWNqlQzerrcYDvKyKVpZnV6aJ80/Z
         cOAOQPKcGd/UEjtiGE/ZT77b39483F96tPgA78g5RXj/VCtdrDSqqSLQkMzw/2Gn8gOr
         gPhTupZXRnSUHzU+W5xEZBA7DgMzWJ/wDNB8Yt472XJ6B6uDKBLVu2b3wFE82NLkkHPc
         TWuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787065836; x=1787670636;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=kG7Zaffwl0mxSN4K5nDR/1mjY7t5FTHW4GrkGQ7+s74=;
        b=AS6oTqHJ5bfzHdVX4JLgn+W/75R6LgtfXEjslpE5CF7jw3N26od17ND9cRR0ASs92o
         1cHzJ9mYVtddTzVdCZEkm0Se4yh+2HSBKAM9GFLqqIBqLd53zEu897jJr/7f9IptFIew
         x7kwnAg5tvGAnC3B+nMjKG2QWpmH5sv/EN2Sr4RGi60C8+GGHfWAB3t9Gbcee2QvFjMh
         a41VPkuPIXBYzHBpouruvn8elgAqgJWk0oPgOrXQHVQiZwpDfUEJmVi4WPIoCc7z2jzk
         jYV3rfRhIYLwmCLFu6wMg4QToXVBjcysFppAHKvgFcKcSiIZEWRA6yXAk4ixKAflUcF7
         ls6w==
X-Forwarded-Encrypted: i=1; AHgh+RqiPtBZriFpzJ95A0jNB0sDkHS9j+e6nit+jo/vtj4nLWfiP8GTQUvApLZ8Ov5ZaVzr38pycyEtUEs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBbmQqlQHT9pQCwTQSriZUjAqnSnjhtHJtVvdeQ6/Vm7Ku2PVP
	bwdsBNuueb1qIcdx/v+J+jsZzJtPMpx4GzeUIyo6pZPscNMGKxaIuXZ0r2xoywzw2A==
X-Gm-Gg: AR+sD13ayxU0wpCQ1XID4UURentQBeVlzyn7f0LKIOVBqQTBF/w+YNgwlJXSXes3ITN
	haDxQIzl9XBIRTxRyJ54j4WJujQ9yXjL8Skzcglux/lHYGUCICRReb15T5dMvoTRPMJymXxbvIf
	ffo3DTLMVDmOM6UqfW+BQcqxVIRO0Q5dmKOlW7lePua80C3MPlhnAjiHDSEd76/uaeMYa560TEB
	wxOPFfFRD/4dMS1ztEM+0da9Amucq/NTa+F8PBgnpnx5TnmUgRot0SPYVRPuuIjPcu0UoSYC6eP
	A5bBuwLUXmbn6UeKC+lPUW5/5BFG+uoY9B4roIWhGdICqMkYAOsK8qim0XiNzcaHG3EatXEjJOw
	MkWASztKBEPslxzmYG9lDNxfFbzyPN2+aavNlfMMYK9PCkPz3IRyDr4mBtU51jxLmNIczhA/0tu
	dpfD4L6g5bYpXIWDSdokyDaEIyULyLyDskgjTapNhtkLJ0dwPkPFfcaxb9WG+cuuQ5vGIAyQDDn
	KbpVGRUiCjCIzNK70raAFgBLGTc2mQbs2r0QiQWFz/XyPZbZbgk
X-Received: by 2002:a05:600c:2114:b0:499:5210:c537 with SMTP id 5b1f17b1804b1-4998792e462mr385780165e9.1.1787065835734;
        Tue, 18 Aug 2026 08:10:35 -0700 (PDT)
Message-ID: <47f3e8ea-ecb2-46b5-841d-a0234e0d536f@suse.com>
Date: Tue, 18 Aug 2026 17:10:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 4/9] x86/passthrough: Extract PT_IRQ_TYPE_MSI body into
 pt_irq_bind_msi()
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298079.8631fc262581453bbf619ec5b2062170.19dcf3880b0000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298079.8631fc262581453bbf619ec5b2062170.19dcf3880b0000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787065836-F5AAF2A1-9A3C87F0/0/0
X-purgate-type: clean
X-purgate-size: 12956

On 27.04.2026 15:54, Julian Vetter wrote:
> --- a/xen/drivers/passthrough/x86/hvm.c
> +++ b/xen/drivers/passthrough/x86/hvm.c
> @@ -290,161 +290,186 @@ static int pt_irq_dpci_setup(struct domain *d, unsigned int pirq,
>      } while ( true );
>  }
>  
> -int pt_irq_create_bind(
> -    struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind)
> +static int pt_irq_bind_msi(struct domain *d, uint32_t machine_irq,
> +                            uint8_t gvec, uint32_t gflags, uint64_t gtable,

Please see ./CODING_STYLE for the use of fixed-width types. With relaxed
interpretation of them, at least machine_irq and gflags should be simply
unsigned int. (gvec and gtable I think are tolerable as you have them.)

> +                            bool unmasked)

Nit (for both wrapped lines): Indentation.

>  {
>      struct hvm_irq_dpci *hvm_irq_dpci;
>      struct hvm_pirq_dpci *pirq_dpci;
>      struct pirq *info;
> -    int rc, pirq = pt_irq_bind->machine_irq;
> +    uint8_t dest, delivery_mode;
> +    bool dest_mode;
> +    int dest_vcpu_id, rc;
> +    const struct vcpu *vcpu;
>  
> -    if ( pirq < 0 || pirq >= d->nr_pirqs )
> +    if ( machine_irq >= (unsigned int)d->nr_pirqs )
>          return -EINVAL;

Rather than merely asking on the cast: What use is this check, when the
caller has done it already?

> -    rc = pt_irq_dpci_setup(d, pirq, &hvm_irq_dpci, &pirq_dpci, &info);
> +    rc = pt_irq_dpci_setup(d, machine_irq, &hvm_irq_dpci, &pirq_dpci, &info);
>      if ( rc )
>          return rc;
>  
> -    switch ( pt_irq_bind->irq_type )
> +    if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
>      {
> -    case PT_IRQ_TYPE_MSI:
> -    {
> -        uint8_t dest, delivery_mode;
> -        bool dest_mode;
> -        int dest_vcpu_id;
> -        const struct vcpu *vcpu;
> -        uint32_t gflags = pt_irq_bind->u.msi.gflags &
> -                          ~XEN_DOMCTL_VMSI_X86_UNMASKED;
> -
> -        if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
> +        pirq_dpci->flags = HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_MSI |
> +                           HVM_IRQ_DPCI_GUEST_MSI;
> +        pirq_dpci->gmsi.gvec = gvec;
> +        pirq_dpci->gmsi.gflags = gflags;
> +        /*
> +         * 'pt_irq_bind_msi' can be called after 'pt_irq_destroy_bind'.
> +         * The 'pirq_cleanup_check' which would free the structure is only
> +         * called if the event channel for the PIRQ is active. However
> +         * OS-es that use event channels usually bind PIRQs to eventds
> +         * and unbind them before calling 'pt_irq_destroy_bind' - with the
> +         * result that we re-use the 'dpci' structure. This can be
> +         * reproduced with unloading and loading the driver for a device.
> +         *
> +         * As such on every 'pt_irq_bind_msi' call we MUST set it.
> +         */
> +        pirq_dpci->dom = d;
> +        /* bind after hvm_irq_dpci is setup to avoid race with irq handler */

Much like you add the missing blank at the end, please also correct the start
of this comment (to use a capital 'B').

> +        rc = pirq_guest_bind(d->vcpu[0], info, 0);
> +        if ( rc == 0 && gtable )
>          {
> -            pirq_dpci->flags = HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_MSI |
> -                               HVM_IRQ_DPCI_GUEST_MSI;
> -            pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
> -            pirq_dpci->gmsi.gflags = gflags;
> -            /*
> -             * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_bind'.
> -             * The 'pirq_cleanup_check' which would free the structure is only
> -             * called if the event channel for the PIRQ is active. However
> -             * OS-es that use event channels usually bind PIRQs to eventds
> -             * and unbind them before calling 'pt_irq_destroy_bind' - with the
> -             * result that we re-use the 'dpci' structure. This can be
> -             * reproduced with unloading and loading the driver for a device.
> -             *
> -             * As such on every 'pt_irq_create_bind' call we MUST set it.
> -             */
> -            pirq_dpci->dom = d;
> -            /* bind after hvm_irq_dpci is setup to avoid race with irq handler*/
> -            rc = pirq_guest_bind(d->vcpu[0], info, 0);
> -            if ( rc == 0 && pt_irq_bind->u.msi.gtable )
> -            {
> -                rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable);
> -                if ( unlikely(rc) )
> -                {
> -                    pirq_guest_unbind(d, info);
> -                    /*
> -                     * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
> -                     * an interrupt can be scheduled. No more of them are going
> -                     * to be scheduled but we must deal with the one that may be
> -                     * in the queue.
> -                     */
> -                    pt_pirq_softirq_reset(pirq_dpci);
> -                }
> -            }
> +            rc = msixtbl_pt_register(d, info, gtable);
>              if ( unlikely(rc) )
>              {
> -                pirq_dpci->gmsi.gflags = 0;
> -                pirq_dpci->gmsi.gvec = 0;
> -                pirq_dpci->dom = NULL;
> -                pirq_dpci->flags = 0;
> -                if ( !info->evtchn )
> -                    pirq_cleanup_check(info, d);
> -                write_unlock(&d->event_lock);
> -                return rc;
> +                pirq_guest_unbind(d, info);
> +                /*
> +                 * Between 'pirq_guest_bind' and before 'pirq_guest_unbind'
> +                 * an interrupt can be scheduled. No more of them are going
> +                 * to be scheduled but we must deal with the one that may be
> +                 * in the queue.
> +                 */
> +                pt_pirq_softirq_reset(pirq_dpci);
>              }
>          }
> -        else
> +        if ( unlikely(rc) )
>          {
> -            uint32_t mask = HVM_IRQ_DPCI_MACH_MSI | HVM_IRQ_DPCI_GUEST_MSI;
> -
> -            if ( (pirq_dpci->flags & mask) != mask )
> -            {
> -                write_unlock(&d->event_lock);
> -                return -EBUSY;
> -            }
> -
> -            /* If pirq is already mapped as vmsi, update guest data/addr. */
> -            if ( pirq_dpci->gmsi.gvec != pt_irq_bind->u.msi.gvec ||
> -                 pirq_dpci->gmsi.gflags != gflags )
> -            {
> -                /* Directly clear pending EOIs before enabling new MSI info. */
> -                pirq_guest_eoi(info);
> -
> -                pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
> -                pirq_dpci->gmsi.gflags = gflags;
> -            }
> +            pirq_dpci->gmsi.gflags = 0;
> +            pirq_dpci->gmsi.gvec = 0;
> +            pirq_dpci->dom = NULL;
> +            pirq_dpci->flags = 0;
> +            if ( !info->evtchn )
> +                pirq_cleanup_check(info, d);
> +            write_unlock(&d->event_lock);
> +            return rc;
>          }
> -        /* Calculate dest_vcpu_id for MSI-type pirq migration. */
> -        dest = MASK_EXTR(pirq_dpci->gmsi.gflags,
> -                         XEN_DOMCTL_VMSI_X86_DEST_ID_MASK);
> -        dest_mode = pirq_dpci->gmsi.gflags & XEN_DOMCTL_VMSI_X86_DM_MASK;
> -        delivery_mode = MASK_EXTR(pirq_dpci->gmsi.gflags,
> -                                  XEN_DOMCTL_VMSI_X86_DELIV_MASK);
> -
> -        dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
> -        pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
> -        write_unlock(&d->event_lock);
> +    }
> +    else
> +    {
> +        uint32_t mask = HVM_IRQ_DPCI_MACH_MSI | HVM_IRQ_DPCI_GUEST_MSI;
>  
> -        pirq_dpci->gmsi.posted = false;
> -        vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;
> -        if ( iommu_intpost )
> +        if ( (pirq_dpci->flags & mask) != mask )
>          {
> -            if ( delivery_mode == dest_LowestPrio )
> -                vcpu = vector_hashing_dest(d, dest, dest_mode,
> -                                           pirq_dpci->gmsi.gvec);
> -            if ( vcpu )
> -                pirq_dpci->gmsi.posted = true;
> +            write_unlock(&d->event_lock);
> +            return -EBUSY;
>          }
> -        if ( vcpu && is_iommu_enabled(d) )
> -            hvm_migrate_pirq(pirq_dpci, vcpu);
>  
> -        /* Use interrupt posting if it is supported. */
> -        if ( iommu_intpost )
> +        /* If pirq is already mapped as vmsi, update guest data/addr. */
> +        if ( pirq_dpci->gmsi.gvec != gvec || pirq_dpci->gmsi.gflags != gflags )
>          {
> -            rc = hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi.gvec);
> +            /* Directly clear pending EOIs before enabling new MSI info. */
> +            pirq_guest_eoi(info);
>  
> -            if ( rc )
> -            {
> -                pt_irq_destroy_bind(d, pt_irq_bind);
> -                return rc;
> -            }
> +            pirq_dpci->gmsi.gvec = gvec;
> +            pirq_dpci->gmsi.gflags = gflags;
>          }
> +    }
> +    /* Calculate dest_vcpu_id for MSI-type pirq migration. */
> +    dest = MASK_EXTR(pirq_dpci->gmsi.gflags, XEN_DOMCTL_VMSI_X86_DEST_ID_MASK);
> +    dest_mode = pirq_dpci->gmsi.gflags & XEN_DOMCTL_VMSI_X86_DM_MASK;
> +    delivery_mode = MASK_EXTR(pirq_dpci->gmsi.gflags,
> +                               XEN_DOMCTL_VMSI_X86_DELIV_MASK);
> +
> +    dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
> +    pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
> +    write_unlock(&d->event_lock);
>  
> -        if ( pt_irq_bind->u.msi.gflags & XEN_DOMCTL_VMSI_X86_UNMASKED )
> +    pirq_dpci->gmsi.posted = false;
> +    vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;
> +    if ( iommu_intpost )
> +    {
> +        if ( delivery_mode == dest_LowestPrio )
> +            vcpu = vector_hashing_dest(d, dest, dest_mode,
> +                                       pirq_dpci->gmsi.gvec);
> +        if ( vcpu )
> +            pirq_dpci->gmsi.posted = true;
> +    }
> +    if ( vcpu && is_iommu_enabled(d) )
> +        hvm_migrate_pirq(pirq_dpci, vcpu);
> +
> +    /* Use interrupt posting if it is supported. */
> +    if ( iommu_intpost )
> +    {
> +        struct xen_domctl_bind_pt_irq bind = {
> +            .machine_irq = machine_irq,
> +            .irq_type = PT_IRQ_TYPE_MSI,
> +        };
> +
> +        rc = hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi.gvec);
> +        if ( rc )
>          {
> -            unsigned long flags;
> -            struct irq_desc *desc = pirq_spin_lock_irq_desc(info, &flags);
> +            pt_irq_destroy_bind(d, &bind);
> +            return rc;
> +        }
> +    }
>  
> -            if ( !desc )
> -            {
> -                pt_irq_destroy_bind(d, pt_irq_bind);
> -                return -EINVAL;
> -            }
> +    if ( unmasked )
> +    {
> +        struct xen_domctl_bind_pt_irq bind = {
> +            .machine_irq = machine_irq,
> +            .irq_type = PT_IRQ_TYPE_MSI,
> +        };
> +        unsigned long flags;
> +        struct irq_desc *desc = pirq_spin_lock_irq_desc(info, &flags);
>  
> -            guest_mask_msi_irq(desc, false);
> -            spin_unlock_irqrestore(&desc->lock, flags);
> +        if ( !desc )
> +        {
> +            pt_irq_destroy_bind(d, &bind);
> +            return -EINVAL;
>          }
>  
> -        break;
> +        guest_mask_msi_irq(desc, false);
> +        spin_unlock_irqrestore(&desc->lock, flags);
>      }
>  
> +    return 0;
> +}

For all of the above, going in two steps would again help review quite a
bit: First introduce the new function, but leave excess indentation alone.
Then have a purely mechanical patch removing one indentation level (and
the associated leftover figure braces).

> +int pt_irq_create_bind(
> +    struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind)
> +{
> +    int rc, pirq = pt_irq_bind->machine_irq;

rc, afaict, is now only used in the more narrow scope below.

> +    if ( pirq < 0 || pirq >= d->nr_pirqs )
> +        return -EINVAL;
> +
> +    switch ( pt_irq_bind->irq_type )
> +    {
> +    case PT_IRQ_TYPE_MSI:
> +        return pt_irq_bind_msi(d, pirq,
> +                               pt_irq_bind->u.msi.gvec,
> +                               pt_irq_bind->u.msi.gflags &
> +                                   ~XEN_DOMCTL_VMSI_X86_UNMASKED,
> +                               pt_irq_bind->u.msi.gtable,
> +                               !!(pt_irq_bind->u.msi.gflags &
> +                                  XEN_DOMCTL_VMSI_X86_UNMASKED));

No need for !!.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:11:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:11:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394269.1633108 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLSv-0000Cj-IN; Tue, 18 Aug 2026 15:11:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394269.1633108; Tue, 18 Aug 2026 15:11:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLSv-0000Cc-Eb; Tue, 18 Aug 2026 15:11:01 +0000
Received: by outflank-mailman (input) for mailman id 1394269;
 Tue, 18 Aug 2026 15:10:59 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwLSt-0000Ac-I9
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:10:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLSs-00Fcyx-Fx
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:10:58 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8475ed-2eae-0a2a0a5409dd-0a2a450ac3c4-44
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:10:58 +0200
Received: from [52.101.201.40]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8475fd-f2d2-0a2a450a0019-3465c9280b7f-4
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:10:55 +0200
Received: from BN9PR03CA0382.namprd03.prod.outlook.com (2603:10b6:408:f7::27)
 by CH3PR12MB8401.namprd12.prod.outlook.com (2603:10b6:610:130::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Tue, 18 Aug
 2026 15:10:49 +0000
Received: from BN1PEPF00004681.namprd03.prod.outlook.com
 (2603:10b6:408:f7:cafe::7b) by BN9PR03CA0382.outlook.office365.com
 (2603:10b6:408:f7::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Tue,
 18 Aug 2026 15:10:49 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN1PEPF00004681.mail.protection.outlook.com (10.167.243.87) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Tue, 18 Aug 2026 15:10:49 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 18 Aug
 2026 10:10:48 -0500
Received: from [10.71.196.80] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Tue, 18 Aug 2026 10:10:46 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pX/E7YfH9pfwNT6Vx0Ve+WZqiqlf3ryA/A8vHIh95mvDGGwJ9dRz+PRB42ZBfjL9rC16IjEXRc20oJ244hdwphjPZEhPbYVyEZUxd4qnNlvzspDoXasC1MUnD0zTNII3lg+6WLDh64xApucJY8RojQYhKVQqKFOQHafq1PZTt2qFGbpriEXMRQuiono5BBsFP9XZVUzHvhaL7VVTpQ8tmjcXd5qsGJBx2BOw+UOzxv00j9WHFVOsQpH3to9I0qeJXNrW4VTRk4y53ywadakqTassyi7OR3PsQdYgtCPLix/QdhE8Iy/AeEU0ni32E6d7O+EBA7mM++ra3S+ZUkA2Tg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=YBknbZWDj/0htpZZ+qXSXeosH6Y9ULnrkqGxMw4M1Nk=;
 b=b7OL86NN/O/iK6JxfDFY13ck7B/4zC/38XsDCw8g8bfPPnyJ3d1wAHU0nMv/g5svyk9wxH/TFACNZRNwQBb4MtcHu8IhhYbgtXeCLX/a1FTpAGJhn6S3U28JI3dF8hH5tKN+eCOLsyCkWn+s0+6BCJ38wFMaXGi1OKe797xDV3G8DSwKVIXf37ZRXA/kZkcL4o6q8uLqn44wo0xIP9p+pzo0er/mH9TcEwXFRMGWWCo/KhmI8AtlAa1Lsb+e5d9Ab1yp4B2WAOy6yZLlHJtV89WwDgbyW4k9zKuFRpwfb2nPw9WEuTCPjbY627YTrnpj8Vha1T8D3ypvVUSLn2aWPg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=YBknbZWDj/0htpZZ+qXSXeosH6Y9ULnrkqGxMw4M1Nk=;
 b=yimgmC2r6SkhWVV6ISXCK+WQaE+GU1korqMrInekTDH7HxZvfXS0lM5sJh7ZclX9+KvHBSN3obI3od5m7PIxvVhmn1soWQrTWyI+Jh64Dvxgbs/9hUPRRY6jaZrYYF3zjCSZVATH7sEEclBxG6n54Z69yfCk9giWtkhxi+i63dA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <7ef46d06-7674-40bf-816c-71f6935394fb@amd.com>
Date: Tue, 18 Aug 2026 17:10:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/3] time: add "NOW() good" indicator
To: Jan Beulich <jbeulich@suse.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD
	<anthony.perard@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>, Teddy Astie <teddy.astie@vates.tech>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Volodymyr Babchuk
	<volodymyr_babchuk@epam.com>, Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <f5040939-b166-4050-9a27-117b772547d4@suse.com>
 <b7513795-9e4b-4358-9d46-6c7036d64b81@suse.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <b7513795-9e4b-4358-9d46-6c7036d64b81@suse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004681:EE_|CH3PR12MB8401:EE_
X-MS-Office365-Filtering-Correlation-Id: bb0ff625-63fd-4900-f442-08defd3ae31d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|1800799024|376014|82310400026|7416014|23010399003|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	qBeDGkHxIATQy22qfK8B8Wq0USnh7PZOpGNpYO2PhZ6UI4EAzz9ZLGhb5VNpIUqrlIeR328RP00fM935Gjas9ps5ZOko59P92nExkjCU5cWYBpaGga0/k8cyN4RAJjV/riXF+lOa/43JvSo3wNArooAryV/JWiPM8q98X9vSRTw1zLCIZCMaVHG9kffygK2ZN05M9hkh7hyx3pSEhzdn0TxRxgpAjxxWlGEyIV5RgCUSYpZ5mtBILZ5oZ0JpvNq21lFKyDeKoHqBdf0s1ixK9xTJKdId+d1f3ar1sSX3hP+kDLeiLuly9Y/c33iCZnDGlicLCSHichOlUtiRvjJmQ4JgHMGKknRMJMa9oyuSDg6j++8w9EwoTlHECiUd3nr7/9nZ6EJbIKSlMnBRGMNc1ZcnltJKO7Tz0psdhSrk/UEk7rCQC9oi6VZcwYbDIvcac//88+u7UIOkkOgFzG6ub5tEN6UqQin/m1c1q8xJWcoRUdqK6xHZkcaoYZ9BeaBxqHh9Al4pPdPI+n5XxuqL1PWUOeUHYyFqF+tIraEWxjQhYQpq2a6iYVKlW3eE0LsWG3p4kr3x61UTe4fGGqtHHteQZ55EAdyFjbniBm/IP9XP5e202iowmK/a1872c9g/NW6xRd+c4Whcpg1jtZrp8ZOLW/4wOzEg+LzOxdADvcL/GiCv+K4LEbxHdTTTZqmuywBEiwVwhgIPjQx3PYe9IQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(376014)(82310400026)(7416014)(23010399003)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	pKDtnnffxLHO5nDFbb8Xcee0PaNUXf8diLRVbNMAJVjbd4lPfn9iiut/eWfrxfTjwdMQ7G4sPOypzuHCys8Ua2jCGLLuEsDYUaky893XEhf/sAF3N4t6JmlpOPTmRENKRp5XQtP5/74hQ+kXO4BAVHs0gn1JmKkIcapGHyq8wuzEA+yYiU71dbG91qXMzjCPO/TKx7WcV5SOZSvIfjoZcY+upO/v6T4KWovUAETrYQKq1xSci/Qt2u1l2KBbPPDzKsJFWbt8JD5zXN/CLgwunWKCjRKuWnGdNngOdECqy/z621zTyMzkvl+zTXmD1tE5sQ4SrMqzI9tCcDZ7116XOsr3yHflgTJV9txZkq2M5mT6ZXa8SBk3lmGO0FsNdTuSICnW8G1WEQIxflo8fPhRiFUdhiA070PPGDNjo61tEFKG9/6qlX7r5a37RWJB1VBm
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 15:10:49.3032
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bb0ff625-63fd-4900-f442-08defd3ae31d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004681.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8401
X-purgate-ID: tlsNG-4011c0/1787065855-520C1CFC-597ADFBD/0/0
X-purgate-type: clean
X-purgate-size: 853



On 30-Jun-26 16:06, Jan Beulich wrote:
> printk_start_of_line() checks for a value of 0 right now. In order to be
> able to have NOW() return at least monotonically increasing values, that
> needs replacing by an explicit indicator.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

> ---
> Arm and RISC-V may want to consider whether their initial get_cycles()
> can't be moved yet earlier, such that the indicator also can be set
> yet earlier.
On Arm, get_cycles() just reads a system register and it could be moved earlier.
That said, is there any rule as to what should actually be considered a start of
time (i.e. the boot_count value)? At the moment, this denotes the moment where
the time driver is set up in preinit_xen_time() after validating the frequency.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:16:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:16:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394283.1633117 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLXf-00010h-2L; Tue, 18 Aug 2026 15:15:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394283.1633117; Tue, 18 Aug 2026 15:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLXe-00010a-Vp; Tue, 18 Aug 2026 15:15:54 +0000
Received: by outflank-mailman (input) for mailman id 1394283;
 Tue, 18 Aug 2026 15:15:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwLXd-00010U-BB
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:15:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLXc-00DkoA-KO
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:15:52 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a847728-e002-0a2a0a5209dd-0a2a4506abb6-2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:15:52 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a847728-195a-0a2a45060019-d155dd2fe195-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:15:52 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47de0093c42so4169308f8f.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:15:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482a5b7834dsm12710927f8f.28.2026.08.18.08.15.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 08:15:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787066152; x=1787670952; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=AZMOSjPuvvS5I2CGyKk4ioLNHh1L8JHs+oyJLDw0keM=;
        b=GS9uz/QMI+/jvMCT7B3QAx+FG/lFhiDDzG6lR0A9vKpHycJBfx0ApNqP/VoXQJHBZr
         O7Y7tiBXHumNpJSRQv9q4DoGX/wI26eVHTyvBZj6wauPmSm3JMbcvwM4Tvbr4sCtnxnj
         2rX4U2mKVEY+GDfZjyTzmRV4pY2BF8GFp0CV6/wgz0Tpr5j0nQjgNLGXWnN7NmDAasoX
         LjPh7BtYz4HkMadGuWBNq4ovVJTujmYiejiJqv7iHDSD2UprWlDc/n583aa/TzxhE8ey
         CLJCWtbm/XBlszMh3SLmvxuD2PeWhV4YHyJKplU8n87gfChtFmIbfM84j+QkpA9mR4Dy
         GzWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787066152; x=1787670952;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=AZMOSjPuvvS5I2CGyKk4ioLNHh1L8JHs+oyJLDw0keM=;
        b=m2bcjCIGmC/rUNgjUsrVVe2cWleDTiFR2gqgNosVcwwtAYX7J5dtQujdkvACpJ2FpL
         R91Kb9Bx0X6Z6jcqDKnwJlM2kXd94VXqac1jvqDyIzj4KWqR11pmZV5HCNX2X/G6NZiL
         vmlsryVZtIUT1tSYD2Stq92ONImvlfpkqgBJHEAIaB6Tfv4/6dLS1dgR2V4v2KXPm1/v
         DJR1YpO46QZGiAMOU2bPe7wp5xDXvD35httcKEvlsQBSazLv/iFmugnwqxausBeFJvTo
         UWW05vPOt2SjmHquAecSakIP4ln82oBpnUdQQSCRvnetwdJ0EsO1UPjFwrRYpv5ajHAI
         KeLw==
X-Forwarded-Encrypted: i=1; AHgh+RqXugAC1NJKHournM+iBpW0X5aMFGPuH3VkkXJqKf1SbyMkf6amWhEsaUEVR8Yrx046dqlPFK3h2Mc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzX5gAl4dhC06OadjCpv4juPSqwR+FfIlz7zaVLD3T4YaDw6wBx
	KblS+JJNxSOlTyErroFFlyzlc480HgDsJ145l5NW/R5NN7v5r0ISzm9PAqTmFr/B/w==
X-Gm-Gg: AR+sD10NpuHAZ/BQ3aVl3smSiXiR2wUOWOgIfXQeLasqr4LrYwOZdbxsxo2HxI9Ce5N
	it1QQjSO0s+IhBjn4vt6ipEjqkoQ/GoDiELfxnO+EzS4ulOYqz4NYj54zsn+eWWEYwr1lCW2VXA
	jw3HIr2+zkiAp2DrsKmgsFwIxF3w/3WPLqwXvE9it9SeEBAVP87YaE3RHu3DY7b9zizVk8hCyoK
	og9QELnO9dq0U0T6aDxdnlM8mUTzzdGJ0UuRYRrmYuHUiKHM4Nf7abW8QEU8q3RQp4ayx0n0P6H
	MosZjWi7qbsTWoawxqGpiSC2rXNLeK9MPqKUkhy3493kjhPe9yLDYXONdvuYnIrpKdts0FgwJW1
	cVIzbcqRHKkZA1D5N0/7vkeSe2DmzMAF5ZvevOgduAAPilPWSD2qVlhqddNzGZQAQ25u/dfZnu6
	Pv9QZJTfVksWJaGaAqHWtVL5cOy/+k7DvXX3ZXHJWvHnJ3fQkHKfmep+vkqJFiG6R6ygoN7k5el
	Kt7oZ9ON0EPVf+a+pMayX9nlFEAUajretA4pPgv07IoGSfvck+X
X-Received: by 2002:a05:6000:2089:b0:481:573d:9d29 with SMTP id ffacd0b85a97d-481607574fbmr54157382f8f.14.1787066152042;
        Tue, 18 Aug 2026 08:15:52 -0700 (PDT)
Message-ID: <0a257dd8-86ee-4be2-9d7a-cfd90250a522@suse.com>
Date: Tue, 18 Aug 2026 17:15:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/3] time: add "NOW() good" indicator
To: "Orzel, Michal" <michal.orzel@amd.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <f5040939-b166-4050-9a27-117b772547d4@suse.com>
 <b7513795-9e4b-4358-9d46-6c7036d64b81@suse.com>
 <7ef46d06-7674-40bf-816c-71f6935394fb@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7ef46d06-7674-40bf-816c-71f6935394fb@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787066152-F7ECC77B-AA46F12A/0/0
X-purgate-type: clean
X-purgate-size: 878

On 18.08.2026 17:10, Orzel, Michal wrote:
> On 30-Jun-26 16:06, Jan Beulich wrote:
>> printk_start_of_line() checks for a value of 0 right now. In order to be
>> able to have NOW() return at least monotonically increasing values, that
>> needs replacing by an explicit indicator.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>

Thanks.

>> ---
>> Arm and RISC-V may want to consider whether their initial get_cycles()
>> can't be moved yet earlier, such that the indicator also can be set
>> yet earlier.
> On Arm, get_cycles() just reads a system register and it could be moved earlier.
> That said, is there any rule as to what should actually be considered a start of
> time (i.e. the boot_count value)?

Whatever NOW() uses as the "bias", I think. That looks to be boot_count on
Arm, yes.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:40:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:40:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394295.1633126 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLuv-0003xp-TV; Tue, 18 Aug 2026 15:39:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394295.1633126; Tue, 18 Aug 2026 15:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLuv-0003xi-Ph; Tue, 18 Aug 2026 15:39:57 +0000
Received: by outflank-mailman (input) for mailman id 1394295;
 Tue, 18 Aug 2026 15:39:57 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwLuv-0003xc-CX
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:39:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLuu-00HSrn-5e
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:39:56 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847cc0-e002-0a2a0a5209dd-0a2a4509d81a-18
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:39:56 +0200
Received: from [209.85.214.182] (helo=mail-pl1-f182.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847cca-be1a-0a2a45090019-d155d6b6cd7a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:39:55 +0200
Received: by mail-pl1-f182.google.com with SMTP id
 d9443c01a7336-2d58efc7356so29588125ad.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:39:55 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d2de41dsm6247737a91.5.2026.08.18.08.39.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 08:39:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787067594; x=1787672394; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=llSGcMbfo3K/AzLAPUD4hx170m1T96Ika40zCHvxGzw=;
        b=LUKXlw+B2PmKLjEmxuxFAY06appfoyqc+iY9lmHzhSLPVLhoMbZOrcy8xeJiTGGECE
         x2p8V8CLnAKgBV8D5SXuTkmyGsr7a78S6XOmvpO1uqXa2XNefyCmPGcYUYP4R8lpLr2R
         NQ/HUYP4pW+DczZJpREdQTXUYnTXxBb13aXfTw1/ppMYjW8gMTkOMvWXw9OatVEInWfb
         9EDxZXfDUuxxJlOrO7yhV1aVcxVSeF8IzQwYhcQFYHyGWBT1m7j49LeAbAUaDc7Z89y4
         BIrrQLlQqoTXjDx//alxhQTCo2NoYGhMImf7bnGmVi1weJEyyR1wzvxLAfYV4rCZ8D61
         jIrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787067594; x=1787672394;
        h=content-transfer-encoding:mime-version: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=llSGcMbfo3K/AzLAPUD4hx170m1T96Ika40zCHvxGzw=;
        b=WpClA4YwesruFTy/WYi0GQDUXuRBI5bbzWq4GUVVVCdpfVRWSLL29ER5LjOCn+Qsoj
         TriZGK6c2sWQoU/zg2y9joQfrrkowmEBFWLNmVNskTn2ptYDaLpKGQ0YfBpFmle+Bb2H
         XkCCyjaT0BG9WNCYV9GE6Dwx8kNpLz2U2gsrbSLA2xovkKjjAlu0ZtzhiP8vL+eQHexR
         NHzO0oDP0G9850yilm5SJgquRH2/HwZfVYB72u6BFlBmmGMU8f65IQWlAFukWELqxciX
         29b0fC5ucCJrr2+aEHn70tb5H1sv1EguwVd6Xy/zL2pZD08JSWzNX2ElpqrUiN8SUmzC
         4SkQ==
X-Gm-Message-State: AOJu0YwBmrsFyw4v4nP/5Hz9GiCSgYjNjsQjPjcd9TolVJp4GmyZXsjd
	nGgimm5LiywPzs6se57q7ERKEEsGSbF1tEHrMzkzUFcp09EplZ4CzKWZKuKxt671
X-Gm-Gg: AR+sD13sLuqAi7gn5rc321Hf8yFMccOMW29waCNA0lRXP77xP9pNlviTNHEHd0gnPOO
	iyjY+6yJ5kzxsldXgY8x2vGkSkwlhHHQmMSUFlT0YZOPBKOKxsBBKtARVUJpufzNkTODs8AX1J5
	D4JhyajwgBhSMRjXvvEW90qugc+IIST3s1Wt4ubD2RM1qp2RxUDnw80WHPZKZjA8Nq2oCBrb1tD
	UJszEx9qwLn/3o5eCdmHCFtBuTh3FDJaSEeNoVcp+q8yDNvDzE+yQctW/kyFJJiGCvHWi+tq5/c
	v86ruL4+Y1rsomnfCOjsuEufjp/dRuxjdHvCJhGY8qHn/chLEKRB1j7+/iOjy+mpLDNzpz/H4df
	1jpdQFAI1luJRL0uURT29VBxf196YSG3/M6FnMnANZSQ4uYc5YhLtrJOek3+6k3YbJwQ/MT2lQS
	5V7YFfE4kURDXs1lavS2tbhO0Fg3gITbefNq30HDu9qkQM3Ai76QXYnbT+kKLASrtkG/dqN7WQq
	ER/ndbXGyRFYCpyilHTiIqTR20Rrylm8meIXOQB2ZY=
X-Received: by 2002:a17:90b:17d2:b0:381:9028:5945 with SMTP id 98e67ed59e1d1-3933e60c1damr34155541a91.14.1787067593849;
        Tue, 18 Aug 2026 08:39:53 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v3 0/4] xen/arm: add i.MX8M platform and UART support
Date: Tue, 18 Aug 2026 23:39:42 +0800
Message-ID: <20260818153946.1635464-1-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787067596-FDC6D034-2C5F9CEF/0/0
X-purgate-type: clean
X-purgate-size: 3303

Following Michal Orzel's review of v2, this series adds Xen support for
the NXP i.MX8M family (i.MX8MP / MQ / MM / MN).  It provides the console
UART driver, its early printk, the platform glue (SiP SMC whitelist for
the calls the dom0 kernel issues to TF-A), and a MAINTAINERS entry.

Tested on i.MX8MP (4x Cortex-A53, GICv3) with the vendor kernel 6.18:
dom0 boots to login on the hypervisor console, and a domU starts with a
PV disk and virtio devices running a full Wayland distro.

Notes for reviewers:

- Unlike i.MX8MQ, the i.MX8MP device tree uses the GIC as the root
  interrupt controller (interrupt-parent = <&gic>), so no device-tree
  workaround is needed and power domains keep working.

- The i.MX8M family has no SMMU, so device passthrough relies on the
  1:1 direct-mapped hardware domain.

- The SiP SMC whitelist forwards only the specific subfunctions the
  dom0 kernel issues, extracted from the vendor kernel call sites.
  Following the v2 review, CPU and DRAM frequency scaling are now both
  denied: the hardware domain cannot make an informed decision about
  resources it shares with the other domains.  dom0's i.MX8M DDRC
  devfreq driver issues the DDR DVFS call at boot; with it denied that
  driver just skips DRAM frequency scaling (the DRAM stays at the
  frequency set by firmware) and dom0 boots normally.

Changes since v2:

Patch 1 (UART driver):
- Add imx-uart.c to the Arm MAINTAINERS section so it falls under Arm
  maintainership.
- Gate serial_tx_interrupt() on TRDYEN; USR1_TRDY is a raw status bit,
  set independently of whether the TX interrupt is enabled.
- Print the IRQ number with %u.

Patch 2 (early printk):
- No code changes; picked up Michal's Reviewed-by.

Patch 3 (platform):
- Include <asm/regs.h> for get/set_user_reg().
- Add a description for the CPUFREQ function id.
- Drop the unused SRC M4_START and NoC LCDIF subfunction macros.
- Order the switch cases by function id.
- Deny DDR DVFS as well as CPU frequency scaling (same reasoning),
  rather than forwarding it.
- Return false directly on a denied subfunction instead of goto plus a
  redundant printk.

Patch 4 (MAINTAINERS):
- No changes; picked up Michal's Reviewed-by.

v2: https://lore.kernel.org/xen-devel/20260818025224.4165503-1-onlywig@gmail.com/

Wig Cheng (4):
  xen/char: add classic i.MX UART driver
  xen/arm64: add early printk for the classic i.MX UART
  xen/arm: add i.MX8M platform support
  MAINTAINERS: add myself as reviewer of i.MX8M related patches

 MAINTAINERS                           |   8 +
 xen/arch/arm/Kconfig.debug            |  12 ++
 xen/arch/arm/arm64/debug-imx-uart.inc |  37 ++++
 xen/arch/arm/include/asm/imx-uart.h   |  57 +++++++
 xen/arch/arm/platforms/Makefile       |   1 +
 xen/arch/arm/platforms/imx8m.c        | 139 +++++++++++++++
 xen/drivers/char/Kconfig              |   8 +
 xen/drivers/char/Makefile             |   1 +
 xen/drivers/char/imx-uart.c           | 233 ++++++++++++++++++++++++++
 9 files changed, 496 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/arch/arm/platforms/imx8m.c
 create mode 100644 xen/drivers/char/imx-uart.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:40:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:40:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394296.1633135 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvK-0005Da-3r; Tue, 18 Aug 2026 15:40:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394296.1633135; Tue, 18 Aug 2026 15:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvK-0005DR-19; Tue, 18 Aug 2026 15:40:22 +0000
Received: by outflank-mailman (input) for mailman id 1394296;
 Tue, 18 Aug 2026 15:40:21 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwLvI-0005D3-Tu
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:40:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLvI-00HT20-Ag
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:40:20 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847cd3-e002-0a2a0a5209dd-0a2a450596e8-24
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:20 +0200
Received: from [209.85.216.52] (helo=mail-pj1-f52.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847ce2-4cb1-0a2a45050019-d155d834c925-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:19 +0200
Received: by mail-pj1-f52.google.com with SMTP id
 98e67ed59e1d1-383cb94f742so91579a91.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:40:19 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d2de41dsm6247737a91.5.2026.08.18.08.40.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 08:40:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787067618; x=1787672418; 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=qIBzYOD0MBsGKdeHT2126j/ybS3L8h3qOs9csVaO/Z0=;
        b=Qbl1HeTYz5doLhXBg2Fjwj38ys/m6aHNM9YRwluNaD4MCOWo6PyLPXC791A+gR2WQ7
         YoxXckjp0Aa5+8Y0iA5HpDLxKiU6we/Iuc8GWZg8xcSFy4tn/1G32kv9CfKx8HWNC+pa
         ePTX1TRn3u6pJTSLdDXL4MPef2oo0CIkxo/4Sy/ugaXnWzds/FOk6EXkqEX4Wc9rKnNu
         xdfWz7+VMoAT+/6sInNHe+80yGRSGYMslF5FewSuHINbWZlmfwzFN4i5zfDBrjp01qXX
         DOX5Hi7YtU1XXN6xOJGw+wCsi5FVC6gnrJXklb9akH9SZ6cutEX2pdFS406gVjYDTttQ
         sKPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787067618; x=1787672418;
        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=qIBzYOD0MBsGKdeHT2126j/ybS3L8h3qOs9csVaO/Z0=;
        b=E8+0BM/GxdSXq4B2BV2K/IPrYR7JvKI0bDWBWdX+W8lvTRCgmWN8fpSCQpOzrol7sI
         izQRDeZJz9yoiISExNgM3YuB6GgnhsIHNPkQxKP+N7PviZLK/tpFk3rMaMm6h3UDngcw
         s8ZZSS5qZlpTb8ONPiwpSOkLfY5LwCwaOLikxkqGmKnbL85UFo39tGLODCKgpPZPF2T1
         bZLpfLuLv/aiyRX4x4iwkN7v8+QhKUdrshbXGRl0C/bzvmJ0zB5lcmY6iySA+Sjrc/SF
         8v1XzB3UEEKMqp/mW0KozbSXtIMCAA7jR4gMtO79XK7OkCgBERYdKic4/6RFTMRKU8GQ
         7wEw==
X-Gm-Message-State: AOJu0YxHAMtX9wNy6WRScsVj5PcXCKJQiJ2c0ods0LU2YMaTZiVFyfuD
	Guot0YrtLSFoDMTVF8cLV4Rz0Lg2OLJsn43+uTeDFjWMFaz62P5ptBbqaP5d6qRb
X-Gm-Gg: AR+sD12r0bGirbkkLv6avB2GhZHhhVjKgVNvYNcxJ91f+kPq9Umr3vDmMxJOMcAeLvc
	FuQbeSNMaa4iy7lplb1gkkqTdM+9y1j+n06pJzo2tyiN2PO9hqym/FkJQ83vLZsNzI+bkP2i3eE
	HyxASwZk9AHWRKlPucycwdLvXr+iMwLoUkNWf3awmZ+qbVJc9dkWeGNxE2JbeivEWESya8TmCKf
	W+bxPnmWNvba8sEAmbi9q0JRrYu3YXbu19vHz+D5erdibpqKBZ4kpp9AB/3Prjc/ECdiOQCDQKJ
	n3uQ1aJiSCPaJEQ6+zKQwW+d4y6utW9CD6BjY9v/3O2UPi7lziIFWNOu1ZFd+HFn9rCUwczXKLQ
	oTDjKORcime61Tbtw7HAQGCdAuHXT2q2vG6Yfnahh6CJjFOaVAMXO8V4zxosC/HQWrOLQ9kF85s
	27OmWvAeY3wYwaoArFCNrIADY49ETFeiLah3CAMv3mtAzf2ivtI/k4JG57PpLDemTMMP1O7cUZf
	U1U98R9E3DZtKn97/R/pyCg6WNxbXsR
X-Received: by 2002:a17:90a:6089:b0:395:4de4:92c7 with SMTP id 98e67ed59e1d1-3954de49a5fmr10840161a91.3.1787067617869;
        Tue, 18 Aug 2026 08:40:17 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v3 1/4] xen/char: add classic i.MX UART driver
Date: Tue, 18 Aug 2026 23:39:43 +0800
Message-ID: <20260818153946.1635464-2-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818153946.1635464-1-onlywig@gmail.com>
References: <20260818153946.1635464-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787067620-F7ABF2A1-F9429C21/0/0
X-purgate-type: clean
X-purgate-size: 11658

Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
compatible), used as the console UART on the i.MX8M family.  Baudrate
and pin configuration are inherited from the bootloader; the driver
only enables the transmitter/receiver and wires up the RX/TX
interrupts, mirroring the existing imx-lpuart driver.

The i.MX8M family's UART IP differs from the LPUART used on
i.MX8QM/8QXP, so a separate driver is needed.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
Changes in v3:
- Add imx-uart.c to the Arm MAINTAINERS section so it falls under Arm
  maintainership.
- Gate serial_tx_interrupt() on TRDYEN: USR1_TRDY is a raw status bit,
  set independently of whether the TX interrupt is enabled.
- Print the IRQ number with %u (it is unsigned).

 MAINTAINERS                         |   1 +
 xen/arch/arm/include/asm/imx-uart.h |  57 +++++++
 xen/drivers/char/Kconfig            |   8 +
 xen/drivers/char/Makefile           |   1 +
 xen/drivers/char/imx-uart.c         | 233 ++++++++++++++++++++++++++++
 5 files changed, 300 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/drivers/char/imx-uart.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ed0ffa608f..4dd97ffcad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,6 +269,7 @@ F:	xen/arch/arm/
 F:	xen/drivers/char/cadence-uart.c
 F:	xen/drivers/char/exynos4210-uart.c
 F:	xen/drivers/char/imx-lpuart.c
+F:	xen/drivers/char/imx-uart.c
 F:	xen/drivers/char/meson-uart.c
 F:	xen/drivers/char/mvebu-uart.c
 F:	xen/drivers/char/omap-uart.c
diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
new file mode 100644
index 0000000000..a3892020e6
--- /dev/null
+++ b/xen/arch/arm/include/asm/imx-uart.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Register definitions for the classic i.MX UART IP
+ * ("fsl,imx6q-uart" compatible), used as the console UART on the
+ * i.MX8M family.
+ *
+ * Register layout taken from Linux drivers/tty/serial/imx.c.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#ifndef ASM_IMX_UART_H
+#define ASM_IMX_UART_H
+
+#include <xen/const.h>
+
+#define URXD0           0x00   /* Receiver Register */
+#define URTX0           0x40   /* Transmitter Register */
+#define UCR1            0x80   /* Control Register 1 */
+#define UCR2            0x84   /* Control Register 2 */
+#define USR1            0x94   /* Status Register 1 */
+#define USR2            0x98   /* Status Register 2 */
+#define UTS             0xb4   /* Test Register */
+
+#define URXD_RX_DATA    0xff
+
+#define UCR1_UARTEN     BIT(0, U)   /* UART enable */
+#define UCR1_ATDMAEN    BIT(2, U)   /* Aging DMA timer enable */
+#define UCR1_TXDMAEN    BIT(3, U)   /* Transmitter ready DMA enable */
+#define UCR1_TXMPTYEN   BIT(6, U)   /* Transmitter empty interrupt enable */
+#define UCR1_RXDMAEN    BIT(8, U)   /* Receiver ready DMA enable */
+#define UCR1_RRDYEN     BIT(9, U)   /* Receiver ready interrupt enable */
+#define UCR1_TRDYEN     BIT(13, U)  /* Transmitter ready interrupt enable */
+
+#define UCR2_SRST       BIT(0, U)   /* 0 = issue software reset */
+#define UCR2_RXEN       BIT(1, U)   /* Receiver enable */
+#define UCR2_TXEN       BIT(2, U)   /* Transmitter enable */
+
+#define USR1_TRDY       BIT(13, U)  /* Transmitter ready */
+
+#define USR2_RDR        BIT(0, U)   /* Receive data ready */
+#define USR2_ORE        BIT(1, U)   /* Overrun error */
+
+#define UTS_TXFULL      BIT(4, U)   /* TX FIFO full */
+#define UTS_RXEMPTY     BIT(5, U)   /* RX FIFO empty */
+#define UTS_TXEMPTY     BIT(6, U)   /* TX FIFO empty */
+
+#endif /* ASM_IMX_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 8e49a52c73..f237c0220d 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -30,6 +30,14 @@ config HAS_IMX_LPUART
 	help
 	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
 
+config HAS_IMX_UART
+	bool "i.MX UART driver"
+	default y
+	depends on ARM_64
+	help
+	  This selects the classic i.MX UART. If you have an i.MX8M family
+	  based board, say Y.
+
 config HAS_MVEBU
 	bool "Marvell MVEBU UART driver"
 	default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 8cbbffdca8..039f566926 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
 obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_XHCI) += xhci-dbc.o
 obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
+obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
 obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
 obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
 obj-y += serial.o
diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
new file mode 100644
index 0000000000..2dc531a84e
--- /dev/null
+++ b/xen/drivers/char/imx-uart.c
@@ -0,0 +1,233 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), used as the
+ * console UART on the i.MX8M family (e.g. i.MX8MP).
+ *
+ * Baudrate and pin configuration are inherited from the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/serial.h>
+#include <asm/device.h>
+#include <asm/imx-uart.h>
+#include <asm/io.h>
+
+#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
+#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
+
+static struct imx_uart {
+    uint32_t irq;
+    char __iomem *regs;
+    struct irqaction irqaction;
+    struct vuart_info vuart;
+} imx8m_com;
+
+static void imx_uart_interrupt(int irq, void *data)
+{
+    struct serial_port *port = data;
+    struct imx_uart *uart = port->uart;
+
+    if ( imx_uart_read(uart, USR2) & USR2_RDR )
+        serial_rx_interrupt(port);
+
+    /*
+     * USR1_TRDY is a raw status bit, set whenever the transmitter has
+     * room regardless of whether the TX interrupt is enabled.  Only treat
+     * it as a TX interrupt when TRDYEN is set, otherwise an RX-only
+     * interrupt would spuriously enter serial_tx_interrupt().
+     */
+    if ( (imx_uart_read(uart, USR1) & USR1_TRDY) &&
+         (imx_uart_read(uart, UCR1) & UCR1_TRDYEN) )
+        serial_tx_interrupt(port);
+}
+
+static void __init imx_uart_init_preirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1, ucr2;
+
+    /*
+     * Reuse the bootloader settings; only enable the UART and both
+     * directions.  The console uses UCR1 interrupts (RRDYEN/TRDYEN)
+     * exclusively, so just clear UCR1's interrupt and DMA enables.
+     */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_TXMPTYEN | UCR1_RXDMAEN |
+              UCR1_TXDMAEN | UCR1_ATDMAEN);
+    ucr1 |= UCR1_UARTEN;
+    imx_uart_write(uart, UCR1, ucr1);
+
+    ucr2 = imx_uart_read(uart, UCR2);
+    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
+    imx_uart_write(uart, UCR2, ucr2);
+}
+
+static void __init imx_uart_init_postirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    uart->irqaction.handler = imx_uart_interrupt;
+    uart->irqaction.name = "imx_uart";
+    uart->irqaction.dev_id = port;
+
+    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
+    {
+        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %u\n", uart->irq);
+        return;
+    }
+
+    /* Enable the receiver ready interrupt */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 |= UCR1_RRDYEN;
+    imx_uart_write(uart, UCR1, ucr1);
+}
+
+static int imx_uart_tx_ready(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return !(imx_uart_read(uart, UTS) & UTS_TXFULL);
+}
+
+static void imx_uart_putc(struct serial_port *port, char c)
+{
+    struct imx_uart *uart = port->uart;
+
+    while ( imx_uart_read(uart, UTS) & UTS_TXFULL )
+        cpu_relax();
+
+    imx_uart_write(uart, URTX0, c);
+}
+
+static int imx_uart_getc(struct serial_port *port, char *pc)
+{
+    struct imx_uart *uart = port->uart;
+
+    if ( !(imx_uart_read(uart, USR2) & USR2_RDR) )
+        return 0;
+
+    *pc = imx_uart_read(uart, URXD0) & URXD_RX_DATA;
+
+    if ( imx_uart_read(uart, USR2) & USR2_ORE )
+        imx_uart_write(uart, USR2, USR2_ORE);
+
+    return 1;
+}
+
+static int __init imx_uart_irq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return ((uart->irq > 0) ? uart->irq : -1);
+}
+
+static const struct vuart_info *imx_uart_vuart_info(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return &uart->vuart;
+}
+
+static void imx_uart_start_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 | UCR1_TRDYEN);
+}
+
+static void imx_uart_stop_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 & ~UCR1_TRDYEN);
+}
+
+static struct uart_driver __read_mostly imx_uart_driver = {
+    .init_preirq = imx_uart_init_preirq,
+    .init_postirq = imx_uart_init_postirq,
+    .tx_ready = imx_uart_tx_ready,
+    .putc = imx_uart_putc,
+    .getc = imx_uart_getc,
+    .irq = imx_uart_irq,
+    .start_tx = imx_uart_start_tx,
+    .stop_tx = imx_uart_stop_tx,
+    .vuart_info = imx_uart_vuart_info,
+};
+
+static int __init imx_uart_init(struct dt_device_node *dev, const void *data)
+{
+    const char *config = data;
+    struct imx_uart *uart;
+    int res;
+    paddr_t addr, size;
+
+    if ( strcmp(config, "") )
+        printk("WARNING: UART configuration is not supported\n");
+
+    uart = &imx8m_com;
+
+    res = dt_device_get_paddr(dev, 0, &addr, &size);
+    if ( res )
+    {
+        printk("imx-uart: Unable to retrieve the base address of the UART\n");
+        return res;
+    }
+
+    res = platform_get_irq(dev, 0);
+    if ( res < 0 )
+    {
+        printk("imx-uart: Unable to retrieve the IRQ\n");
+        return -EINVAL;
+    }
+    uart->irq = res;
+
+    uart->regs = ioremap_nocache(addr, size);
+    if ( !uart->regs )
+    {
+        printk("imx-uart: Unable to map the UART memory\n");
+        return -ENOMEM;
+    }
+
+    uart->vuart.base_addr = addr;
+    uart->vuart.size = size;
+    uart->vuart.data_off = URTX0;
+    uart->vuart.status_off = UTS;
+    uart->vuart.status = UTS_TXEMPTY | UTS_RXEMPTY;
+
+    /* Register with generic serial driver */
+    serial_register_uart(SERHND_DTUART, &imx_uart_driver, uart);
+
+    dt_device_set_used_by(dev, DOMID_XEN);
+
+    return 0;
+}
+
+static const struct dt_device_match imx_uart_dt_compat[] __initconst =
+{
+    DT_MATCH_COMPATIBLE("fsl,imx6q-uart"),
+    { /* sentinel */ },
+};
+
+DT_DEVICE_START(imx_uart, "i.MX UART", DEVICE_SERIAL)
+    .dt_match = imx_uart_dt_compat,
+    .init = imx_uart_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:40:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394297.1633143 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvN-0005SR-EE; Tue, 18 Aug 2026 15:40:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394297.1633143; Tue, 18 Aug 2026 15:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvN-0005SF-BV; Tue, 18 Aug 2026 15:40:25 +0000
Received: by outflank-mailman (input) for mailman id 1394297;
 Tue, 18 Aug 2026 15:40:24 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwLvM-0005RU-LU
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:40:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLvL-00DoOS-QQ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:40:23 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847cd6-bab6-0a2a0a5309dd-0a2a450981d6-44
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:23 +0200
Received: from [209.85.214.179] (helo=mail-pl1-f179.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847ce6-be1a-0a2a45090019-d155d6b3b4a1-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:23 +0200
Received: by mail-pl1-f179.google.com with SMTP id
 d9443c01a7336-2d530328efbso44051555ad.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:40:23 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d2de41dsm6247737a91.5.2026.08.18.08.40.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 08:40:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787067622; x=1787672422; 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=n0On8hRhK0t4yabFkZiREtUdWVWf6eqi7kbFEajsEts=;
        b=Lwo69YnFA8djpTfkPSBkmSG/J4ab30v8QP/nkTaM2UapmsGnk+zNJVrupHGlSzmp3H
         WMtkJFtV7ihF9X/AWMueCSIskBQwHUfi68SKIGbxSMCgH5gJewayrBWu5ss0UUi/Gaxw
         bBARM/tCqT4zofGXpBNgbUaFRhTOU0qi75nan5QN8AVdhW93Ql5/+CcJWDyJEW2OzAHU
         bUyjz86bivoJAQfl4uv72EGLOn1x2PPimEWSMG1hU2X1saaTRByCn8VvR/MMX5cp2tap
         gSRsJ734wA1eGL92fhxL1ZI6ZwMoSZRjC8U3NCY87R6ubkNH2kuZDskAlkNyBjSxyWfs
         h8RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787067622; x=1787672422;
        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=n0On8hRhK0t4yabFkZiREtUdWVWf6eqi7kbFEajsEts=;
        b=LNn2gbITZjoj0BM+djPo07pB/9s6Mu6JCDYWUHmI5kVopEVkSUEitOaPnrh77e4jMz
         Wf9/Tr1I+/jMAglMukl3m8nw5gBCT5QD4/rGgUoockQQmfpY9f266R8H0SBnJm8XPoae
         Qo4UQQbak6599U5UfuFeeW82F1rS9K9Cva3OTQ2QG16rRSKbAof1cWzMRbHjHjt+KzsQ
         bfCXFeF9P+lChIpUL2SV7oT2hfOOS9j0QTjlHIb6A6J+smOIwieC/bJIyMixdpOaKXTF
         BPuVAUWI4U1bMNqs2xOU3secr55hd4PTFo9T1CNDtqwHAyzBWC+P7oxVEpQDgaJOeo6Z
         GqHA==
X-Gm-Message-State: AOJu0YzWwxFInCf6x5Lllof6O/9JfIbqYgm1CMhQq89rBZVIDeJZfbI8
	bp8ghC6GnOyfTtGMpWKP4eWH/Vcw0IYOdLLQNxmqAafbyupE+uGoyYzpd71QaPo2
X-Gm-Gg: AR+sD11YlAboy4OCKTh6XN7Ax7ZMugfZtPKJs14V7gQV3mBH4HamJ4oNQhEeClnGQ/B
	tdtdP7shuNlrPQbbbNJROB8sMrLgPncfb00Vn6301eubR2OHcGs3wlfJN4xh3nlWBJQdNIN4ng8
	2vvWiAsmKjDWh0WLY2RiDYEhHNejfTgC21n/GnWGZwIUwqGgx2eb6+LAE8l7mOhf1DeVuosUtC1
	fCYOfaMd5i/F+FYORTZETeqADow4DmswE/RmPHDGH8BqKmxrzIpPPVQBvYpS/xJIJp0PJVQV7io
	QGTxGbgoXolNEjz59GwlVanlRgwLaznjCgz/ves9jRl+vvCk/IKyT4+ppUaR0yKGMY9eDx1yocm
	hlzeYFmRH8+l14f2+oD1tTWBO5Qa33UYIEKMDP4HB3lOgHqJB5RgAqkWfdlzXTJqy9rzTpnU537
	YuYI0y6BYED7W+64iGhZRzRrZmVByMYWRtRKiOktGiSQfvbASsFhvbDpuph4pq9O0xdorOTxu0c
	che29I2UUf0veqt+opeAoe7e9+Zey04iLF1cr11opw=
X-Received: by 2002:a17:90b:314a:b0:37f:fdc8:71b4 with SMTP id 98e67ed59e1d1-3955a3dadefmr11324468a91.2.1787067621660;
        Tue, 18 Aug 2026 08:40:21 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v3 2/4] xen/arm64: add early printk for the classic i.MX UART
Date: Tue, 18 Aug 2026 23:39:44 +0800
Message-ID: <20260818153946.1635464-3-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818153946.1635464-1-onlywig@gmail.com>
References: <20260818153946.1635464-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787067623-BFED6034-904A1B9B/0/0
X-purgate-type: clean
X-purgate-size: 3128

Add an early printk implementation for the classic i.MX UART IP,
selectable via EARLY_UART_CHOICE_IMX_UART.  The UART is expected to be
fully initialized by the bootloader.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v3:
- No code changes; picked up Michal's Reviewed-by.

 xen/arch/arm/Kconfig.debug            | 12 +++++++++
 xen/arch/arm/arm64/debug-imx-uart.inc | 37 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc

diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 5a03b220ac..63a34b813a 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -44,6 +44,14 @@ choice
 		  Say Y here if you wish the early printk to direct their
 		  output to a i.MX LPUART.
 
+	config EARLY_UART_CHOICE_IMX_UART
+		select EARLY_UART_IMX_UART
+		depends on ARM_64
+		bool "Early printk via i.MX UART"
+		help
+		  Say Y here if you wish the early printk to direct their
+		  output to the classic i.MX UART (i.MX8M family).
+
 	config EARLY_UART_CHOICE_LINFLEX
 		select EARLY_UART_LINFLEX
 		depends on ARM_64
@@ -97,6 +105,9 @@ config EARLY_UART_EXYNOS4210
 config EARLY_UART_IMX_LPUART
 	select EARLY_PRINTK
 	bool
+config EARLY_UART_IMX_UART
+	select EARLY_PRINTK
+	bool
 config EARLY_UART_LINFLEX
 	select EARLY_PRINTK
 	bool
@@ -185,6 +196,7 @@ config EARLY_PRINTK_INC
 	default "debug-cadence.inc" if EARLY_UART_CADENCE
 	default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
 	default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
+	default "debug-imx-uart.inc" if EARLY_UART_IMX_UART
 	default "debug-linflex.inc" if EARLY_UART_LINFLEX
 	default "debug-meson.inc" if EARLY_UART_MESON
 	default "debug-mvebu.inc" if EARLY_UART_MVEBU
diff --git a/xen/arch/arm/arm64/debug-imx-uart.inc b/xen/arch/arm/arm64/debug-imx-uart.inc
new file mode 100644
index 0000000000..19b1679020
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-imx-uart.inc
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Early printk for the classic i.MX UART IP (i.MX8M family).
+ * The UART is expected to be fully initialized by the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <asm/imx-uart.h>
+
+/*
+ * Wait for the UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb, c
+1:
+        ldr   w\c, [\xb, #UTS]        /* <- Test register */
+        tst   w\c, #UTS_TXFULL        /* Check TX FIFO full bit */
+        b.ne  1b                      /* Wait until there is room */
+.endm
+
+/*
+ * UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb, wt
+        str   \wt, [\xb, #URTX0]      /* -> Transmitter register */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:40:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:40:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394300.1633154 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvR-0005lJ-Ne; Tue, 18 Aug 2026 15:40:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394300.1633154; Tue, 18 Aug 2026 15:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvR-0005l7-Id; Tue, 18 Aug 2026 15:40:29 +0000
Received: by outflank-mailman (input) for mailman id 1394300;
 Tue, 18 Aug 2026 15:40:28 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwLvQ-0005jp-Gs
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:40:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLvP-006hOt-Ti
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:40:27 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847ce4-8faa-0a2a0a5109dd-0a2a4504d266-20
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:27 +0200
Received: from [209.85.216.44] (helo=mail-pj1-f44.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847cea-b57f-0a2a45040019-d155d82cd18f-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:27 +0200
Received: by mail-pj1-f44.google.com with SMTP id
 98e67ed59e1d1-384930ca5e2so83335a91.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:40:27 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d2de41dsm6247737a91.5.2026.08.18.08.40.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 08:40:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787067626; x=1787672426; 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=M9gYmqB9sm85nt1WIzPntBQ829u0LTMSjCyLS2s6yWc=;
        b=dR2SSz3uPUK3epUlw4KJb0txon1RPqOlQUxOV94V0pu+SPsMRYYZsWHeB2RcYIeOJl
         OarhFesP8EIvV0D2uK5nABveVpEO5wbzicaraEMwXP54O4DfqNFqzk6JqfIcgFPMdB1Q
         w9pG2HLJ6f9eR9wrJmxjIbpB+UbAvuXnZGbUZkDldL3KaKsngd4MU6I1Mnfe+E/KIxQv
         N8/g4dyq/266eM8UTsIsqQTCrImsTvTQsahSd5gTBQ/yeCwRgLpvXzLUpv4lPir7gJ0n
         gneUQsDjJZE7QUPnB+qJZITQS5LslBpVybeE7SzT71GwT645OlAfqhpzVgqqoMMHH0J2
         R0gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787067626; x=1787672426;
        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=M9gYmqB9sm85nt1WIzPntBQ829u0LTMSjCyLS2s6yWc=;
        b=I0Ri7HXebCxlAkQaJ6XxdUU5aiv+y2leuy9s+XAV9H9fQRLK3+Cp3N/DpyRlVMzgEw
         6YowfrqlditWrGDFIyRkeO0GUb6q00JJtf4mYdHeUvjIUhgOiQin4+L2aNu2M3t+7RaV
         RIyRQbuMuci4tnjAijr3Te8kT89LY4DDzfk+i9LbsvTBrjpT+9i0OISBgPN2LgbWynIS
         4OHFfncXrTwrTNTNy7mXFeGIddwVBw7iAZbN8Vce3jQfczzwk2xz73Q+bvxZhUFeLXgY
         bxCqjDBMLr0AtpLtN+pWd2mGCL0jYhpvDYlx2yA8cisyCY5B8K0c3dlQOtO6m6qZzB3j
         Frig==
X-Gm-Message-State: AOJu0YxgreaHsqxw4TN7MmyvFMzi/mvCK0GAXxV45ocWo/C5vlfTM7LS
	Bwf3GK1tJBlB6kPvGK7a+jFoiffYT+jntzJW4Kbn9inZc3yAEMMxl4rPYaomdZdc
X-Gm-Gg: AR+sD13E61YbFfM8rkpASrknx9yxniQHeWwvgR1Q0oBubOAqEccQSl8tX43liCaX707
	tS1VxExfb6Y4OhYK1nBl7vzM1EyEYHZSi4rtQNL81u0Lp14Li2LdSWpq+8x/AQr7NNZjbc6iEE1
	9U9W3BMxvEGkxhhGKl/MHvmJL2Ke3yNagCRLYYT0WqHofHyt753OITq2RyVqDanUcLuoyjthXkn
	uGZM7M7/Xr5Z55VcrqYsnhGF6mNX5fsBfW4pjZG3tKZt1dA0gNh7+XBICQpAOkYNlb+9isbVtw6
	v8l9iC+8v3cCWktSlJOD4q1w/IT21NCNDaeVJ+w6tLXVo2MCkttHlGkVKus3q0XBWZE6O/056dF
	ByTTz7xB1iWNCCTyQfeIm06akfBp7KZ1JXk73uuik0vwYnCr326yCwlQHZfNKz1p4ucNpyDBQBI
	pD8ImkzDEWMV7pJ8dpUF0ZMXPF5KvIEtsC5WitYNDHWAaY4SNAD873LfvTU36GaBaaVsVpKv6VF
	8ICoIwNpaibm0mD+8lD/gHGMsvrvXk4jxkmdkN1JsU=
X-Received: by 2002:a17:90b:5707:b0:38f:5801:dc0e with SMTP id 98e67ed59e1d1-3933e61bee2mr39142719a91.15.1787067625672;
        Tue, 18 Aug 2026 08:40:25 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v3 3/4] xen/arm: add i.MX8M platform support
Date: Tue, 18 Aug 2026 23:39:45 +0800
Message-ID: <20260818153946.1635464-4-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818153946.1635464-1-onlywig@gmail.com>
References: <20260818153946.1635464-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787067627-510DDB50-329D83F9/0/0
X-purgate-type: clean
X-purgate-size: 6665

Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).

When Linux is used as dom0 a number of drivers make SiP SMC calls into
TF-A to manage hardware: GPC power domains, SRC (M-core remoteproc),
SoC info and NoC QoS.  There is no public specification for these
calls; the function IDs and their subfunctions are taken from the
vendor kernel call sites.

Forward only the specific subfunctions the hardware domain issues,
following the whitelist model of the i.MX8QM platform.  Where a service
has a fixed set of subfunctions (GPC, SRC, NoC) they are filtered, and
the SoC info call is a read-only query.  CPU and DRAM frequency scaling
are denied because the hardware domain cannot make an informed decision
about resources shared with the other domains, and any unknown function
ID is rejected.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
---
Changes in v3:
- Include <asm/regs.h> for get/set_user_reg().
- Add a description for the CPUFREQ function id.
- Drop the unused SRC M4_START and NoC LCDIF subfunction macros.
- Order the switch cases by function id.
- Deny DDR DVFS as well, for the same reason CPU frequency scaling is
  denied: the hardware domain cannot make an informed decision about
  DRAM shared with the other domains.  Previously it was forwarded.
- Return false directly on a denied subfunction instead of goto plus a
  redundant printk (vsmccc_handle_call() already logs the rejection).

 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/imx8m.c  | 139 ++++++++++++++++++++++++++++++++
 2 files changed, 140 insertions(+)
 create mode 100644 xen/arch/arm/platforms/imx8m.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index bec6e55d1f..cdf936c50d 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
 obj-$(CONFIG_ALL64_PLAT) += thunderx.o
 obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
 obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8m.o
 obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
new file mode 100644
index 0000000000..0aceed9d43
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8m.c
@@ -0,0 +1,139 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * i.MX 8M family setup
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/sched.h>
+#include <asm/platform.h>
+#include <asm/regs.h>
+#include <asm/smccc.h>
+
+static const char * const imx8m_dt_compat[] __initconst =
+{
+    "fsl,imx8mp",
+    "fsl,imx8mq",
+    "fsl,imx8mm",
+    "fsl,imx8mn",
+    NULL
+};
+
+#define IMX_SIP_FID(fid) \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+                       ARM_SMCCC_CONV_64, \
+                       ARM_SMCCC_OWNER_SIP, \
+                       (fid))
+
+/*
+ * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
+ * public specification for these; the IDs and their subfunctions are
+ * extracted from the vendor kernel call sites (see drivers/soc/imx,
+ * drivers/devfreq, drivers/remoteproc).
+ */
+#define IMX_SIP_F_GPC       0x0   /* GPC power-domain control */
+#define IMX_SIP_F_CPUFREQ   0x1   /* CPU frequency scaling */
+#define IMX_SIP_F_DDR_DVFS  0x4   /* DRAM frequency scaling */
+#define IMX_SIP_F_SRC       0x5   /* SRC: M-core remoteproc start/stop */
+#define IMX_SIP_F_SOC_INFO  0x6   /* read-only SoC info query */
+#define IMX_SIP_F_NOC       0x8   /* NoC QoS priority setup */
+
+#define IMX_SIP_GPC_SF_PM_DOMAIN    0x03
+
+#define IMX_SIP_SRC_SF_M4_STOP      0x02
+
+#define IMX_SIP_NOC_SF_PRIORITY     0x01
+
+static bool imx8m_smc(struct cpu_user_regs *regs)
+{
+    uint32_t function_id = get_user_reg(regs, 0);
+    uint32_t subfunction_id = get_user_reg(regs, 1);
+    struct arm_smccc_res res;
+
+    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+    {
+        printk_once(XENLOG_WARNING
+                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
+
+        return false;
+    }
+
+    /* Only the hardware domain may use the SiP calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
+        return false;
+    }
+
+    /*
+     * Forward only the subfunctions the dom0 kernel actually issues.  All
+     * of these manage hardware that belongs to the hardware domain (power
+     * domains, M-core, NoC) or are read-only queries.
+     */
+    switch ( function_id )
+    {
+    case IMX_SIP_FID(IMX_SIP_F_GPC):
+        if ( subfunction_id != IMX_SIP_GPC_SF_PM_DOMAIN )
+            return false;
+        break;
+
+    /*
+     * CPU and DRAM frequency scaling: the hardware domain does not see the
+     * whole system and cannot make an informed decision about resources
+     * shared with the other domains, so deny both (CPU frequency scaling
+     * is denied on the i.MX8QM platform for the same reason).
+     */
+    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
+    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
+        return false;
+
+    case IMX_SIP_FID(IMX_SIP_F_SRC):
+        if ( subfunction_id > IMX_SIP_SRC_SF_M4_STOP )
+            return false;
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_SOC_INFO):
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_NOC):
+        if ( subfunction_id > IMX_SIP_NOC_SF_PRIORITY )
+            return false;
+        break;
+
+    default:
+        gprintk(XENLOG_WARNING, "imx8m: smc: Unknown function id %x\n",
+                function_id);
+        return false;
+    }
+
+    arm_smccc_1_1_smc(function_id,
+                      subfunction_id,
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+}
+
+PLATFORM_START(imx8m, "i.MX 8M")
+    .compatible = imx8m_dt_compat,
+    .smc = imx8m_smc,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 15:40:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 15:40:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394302.1633163 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvW-00068E-UU; Tue, 18 Aug 2026 15:40:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394302.1633163; Tue, 18 Aug 2026 15:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwLvW-000684-PZ; Tue, 18 Aug 2026 15:40:34 +0000
Received: by outflank-mailman (input) for mailman id 1394302;
 Tue, 18 Aug 2026 15:40:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwLvV-00063D-1C
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 15:40:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwLvU-00DoR5-DT
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:40:32 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847ce0-2eae-0a2a0a5409dd-0a2a4507d21e-32
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:32 +0200
Received: from [209.85.216.43] (helo=mail-pj1-f43.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a847cee-b4ea-0a2a45070019-d155d82be94f-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 17:40:32 +0200
Received: by mail-pj1-f43.google.com with SMTP id
 98e67ed59e1d1-383b4a3755fso63725a91.3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 08:40:31 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3954d2de41dsm6247737a91.5.2026.08.18.08.40.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 08:40:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787067630; x=1787672430; 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=5GnPo4KAZWnrGy/rpIMN59vgyD7cezvUOyXwJsPUekw=;
        b=TXRObutIKkDq+zX4W/Ur8hm45LMqy5RLh7/gpWiwRdiGelEuYMETc9Ku4dttf3WUqj
         +1U86ezQcjFtr6RDUA4eUTK/mpe62ZkewXSc0jb8NLy26pSeIzVf6N7vqFhZcE2UoNqf
         dsmREfpe/P4Q3ap2DptagKSBAZhvKmZ/HSVWViGlZ7ZtuwPJplq1b0cNMjZhnzAa3reA
         sejHJHbyVe7mbgqPuzzaBnkkPha3BcD7bQ+yaK0E0CmWGdngBdwm6HxCJMASUTyKNIU4
         GnoTXge/nVK/UMeuHCcXCHvkRz+1di0V0Lgm9m3gh9JxY+C1GYcJf9jjfj/up2VyIPvi
         aViA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787067630; x=1787672430;
        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=5GnPo4KAZWnrGy/rpIMN59vgyD7cezvUOyXwJsPUekw=;
        b=FTj8yy7ORDVXw/xwYgdscP6TVCT4vEDiDy57mk4lmVnQ0GA26Wwi+2vynqt7z/1grI
         c3eYz7ZwQbxNtG9Z4K7MvwSnqA7kMF234RlWWGB/jj1aZ3ipi6BKcbbwwBYfqIHblAEc
         gKOJKj+sdhWFS3O4ihfoY2un/jD3i3nzgExJ+kb2bCyvBVNQ630wla88Uf/Nm3zaRRaz
         BpQ6dKERhk9hI+PFTgpmb4vxCAzeVNNl+CDl7ubv0jcm8ujHh4+SUc4Lh6bSGnuR9FG8
         oAXsCVzXp1EdS/hXSOO9DdlvP7v217be+5W8emVSy28qXuw+/tH+i5lNrlx/jseJISCj
         ySMA==
X-Gm-Message-State: AOJu0YxKHFSYSt3hnuAybrW4ioCmrACCSWneG7X6e6O5yvCzr/JWY3Ul
	axIXGucwTHYJAbWFYWlcPjbENSbzF6VuFeVMs8MAfadI7y5fpjqPhj/1wbW+BcaW
X-Gm-Gg: AR+sD11/c9cZuBqiKtmaUCUQzxgLfJbO3us7D3D1RKfzJg392KHJv6PmG+1m5VziYmF
	hOqD2UTCZfXCpZfUroYrgJSX0q8SzbjA9lNA6CFk7pFAEI9IL/gtPjncDjQ3DWCQEmkAjWRcYJn
	P0zymbWkz8Ct0wuZD/2VeQn3lkxP75APNbzYLp30obzuMzWK4ckjVV0JEtMo6TNiPtEkYOlvgXQ
	W+yiGsINFIeuAScffbAhfkgcnFTtu+qbPbNfJK5e5MQh9/R8Oe1SQ8CchazTw58kNGle67YQGKK
	NWbcowFBIr7OHPZHSbxl4GjBQ9HiAtu3TU0mOgyPO1jJHdx9tJDdcpw7+WJWBd270aU4KXK/Q4K
	DtaoYrVJTgTfy+kk5HEiGMYzckdYD38Cg+kJa5DukMZ97wzy7wik48iOaKcaassLfbs2Txy1P/3
	EL+phHaLzXnPmPior23B65a9sk61unDiPhs3tzHhLte42IE51rswPUhMFcNCh4VkaMe8NWZEkhE
	XsbtkzBZEbfhpL+0hJ3OwqrMcDV4x+b
X-Received: by 2002:a17:90a:ec83:b0:381:e74f:8a6a with SMTP id 98e67ed59e1d1-3933b8c1041mr39437789a91.16.1787067629975;
        Tue, 18 Aug 2026 08:40:29 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>,
	Wig Cheng <onlywig@gmail.com>
Subject: [PATCH v3 4/4] MAINTAINERS: add myself as reviewer of i.MX8M related patches
Date: Tue, 18 Aug 2026 23:39:46 +0800
Message-ID: <20260818153946.1635464-5-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260818153946.1635464-1-onlywig@gmail.com>
References: <20260818153946.1635464-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787067632-34CCFAE4-583081B3/0/0
X-purgate-type: clean
X-purgate-size: 867

I wrote the i.MX8M platform and UART support and can help review
patches touching these areas.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v3:
- No changes; picked up Michal's Reviewed-by.

 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4dd97ffcad..c60afc93a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -365,6 +365,13 @@ F:	tools/misc/xenhypfs.c
 F:	xen/common/hypfs.c
 F:	xen/include/xen/hypfs.h
 
+IMX8M SUPPORT
+R:	Wig Cheng <onlywig@gmail.com>
+F:	xen/arch/arm/arm64/debug-imx-uart.inc
+F:	xen/arch/arm/include/asm/imx-uart.h
+F:	xen/arch/arm/platforms/imx8m.c
+F:	xen/drivers/char/imx-uart.c
+
 IMX8QM/QXP SUPPORT
 R:	John Ernberg <john.ernberg@actia.se>
 F:	xen/arch/arm/platforms/imx8qm.c
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 18 16:04:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 16:04:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394342.1633171 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwMIv-0002ao-O5; Tue, 18 Aug 2026 16:04:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394342.1633171; Tue, 18 Aug 2026 16:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwMIv-0002ah-LO; Tue, 18 Aug 2026 16:04:45 +0000
Received: by outflank-mailman (input) for mailman id 1394342;
 Tue, 18 Aug 2026 16:04:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwMIu-0002ab-MG
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:04:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwMIu-00FkPm-2w
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 18:04:44 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a848287-8faa-0a2a0a5109dd-0a2a450a9638-46
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 18:04:44 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a84829b-f2d2-0a2a450a0019-d155dd32acef-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 18:04:43 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47f703a9e5dso2251976f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:04:43 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d0fb85csm188392425e9.11.2026.08.18.09.04.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 09:04:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787069083; x=1787673883; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=R7E3RhGjcMrQEACWget1/Qhjbhr69AQstIrEKp2WYwM=;
        b=L1YkYX0wjVFThOMWbEJ1g0Rl1Zsuxn8TPql9pCR1r/sM8gI9ZXccB2MdvSYYhNjLCS
         A04bxSA+i/l+JsXFEg+jQn1fz2jZi8jCrF/MA2k9M8UEPp/imYgWqeGlGuqG8LNyOmhd
         z5F4d3yR8H8csUWO3pIku4I2zteGLyIuzGYgqEhcijMtEMDlNl7EJLFH48xpURaAMP7I
         VwY739/vW0I56oneaa4OOPS0BCol8SLNndEaKBY9/VdPuF7O1cA8g9esLFwcpS9GvD3l
         mJLmRmJKCWbv9Qe+XWOq7gwO7dR99VZDnqzA6qLh9dfGuc8G98FOs0WHRDLHyfMPVa8l
         vqWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787069083; x=1787673883;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=R7E3RhGjcMrQEACWget1/Qhjbhr69AQstIrEKp2WYwM=;
        b=Oty4D7PtWv+qa/3fH/K5OnrYbPRYznFsJ394f9ChW0BGXklFOxsAl1qhX+Cl3PCNAO
         hbpnFqtF3+11xYfiwj+Tk1ZmdlCH/crlpAtcaRIi4lg+VVNdElFg9Z+LGiXfNqqzGYOp
         LWUBWKl7JSDF3ygohbOV5EbDwMpKgmkCMUyOaFvzFYAeveXpbU0MBzbgNhTz91MXbCRS
         d/tP2oyLkTpdfU3Cey+BgRe3+yJAHZihoW75QwO6Vgu7lbOSey9LhQFnxXGn4BrohpDe
         uASYzEn6srFVa1lcowcj3GGzAjFj05gAER1VqA0CL4BUeF/43lvtqjnZ4VMrXBWw3KLB
         Sf/Q==
X-Forwarded-Encrypted: i=1; AHgh+Rr90q9yDRo5v2MvD6Shz911r/S3gbhlkGWzZhSIc5UteND5vfD3oJ5qKUmNhXeyq0vBE195nBU8pR0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyxc4QDdap7dxWXXaY1H3xppUSJ8++lvncY/Ge2NpKcbvVAufOr
	O9yjSusgQFEhEMGtLr+BfzBodg4G7oIPnc7/nQvtOWkqKG6kaoC1P0YX
X-Gm-Gg: AR+sD13ovL2pcc8UW03D+x1BRKmbGAbxc7NlWOYb9ob+e5TYuAAvvH4IDclDz0vtboP
	4OveKDBoDDNsoSDiL707tXKw7gNs7lKlwffH5fa/Ea+xQPL81eWXrVLG/t6VYWDS7iPkBcKTgEO
	Wz/xDaTVvd9rP8l4IIj0BvDA3NZ2O+DoYFsKrIvL7GU7ylTpvSBvRC7q3pT2zjdB333Uc+jt0gV
	7VIIl2ZY7E438zm8LfVn8GR/u3VD1B+WzA1rQWKRbKVoRRRhMnoQ0kN+RzgpNYxGVE9ZFxzCl0e
	dZrempi7AZ+W0Wjvs1dFh7CpkqWWtJ7yhX9SRaXJQHyZUL78wgTZoFnEudKxtbv3ACoM7criXcZ
	AmOpt5EYr8Bj9tHyC7bMXd3Ig8WfdruIb4HLuNRCxcyKks9D0HH1Trrz5vMngc6sr+pWUBTEWYi
	R3LX/dPeNdWe/bC/MWpMzjtG9FHcGtF1PdycLDhHYBnZ/Je7VA3v2YhgL9euf0VzF7eWUJSrDqw
	9LBAsISa0pyGnuW3YuXTQas7y/B52rr1X+gPpeWP5U=
X-Received: by 2002:a05:600d:16:b0:499:a5c8:c6f3 with SMTP id 5b1f17b1804b1-499a5c8c74fmr84239055e9.3.1787069083162;
        Tue, 18 Aug 2026 09:04:43 -0700 (PDT)
Message-ID: <fa2924e9-139c-4cdc-9dd4-4b3a26a21fa2@gmail.com>
Date: Tue, 18 Aug 2026 18:04:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
 <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
 <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
 <f6e12465-dcd0-4f04-bdd4-8e1943e1ade7@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <f6e12465-dcd0-4f04-bdd4-8e1943e1ade7@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787069084-504CFCFC-7FD3143D/10/73395122804
X-purgate-type: spam
X-purgate-size: 5466



On 8/18/26 10:29 AM, Jan Beulich wrote:
> On 17.08.2026 18:10, Oleksii Kurochko wrote:
>> On 8/12/26 5:48 PM, Jan Beulich wrote:
>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/traps.c
>>>> +++ b/xen/arch/riscv/traps.c
>>>> @@ -191,6 +191,67 @@ static void timer_interrupt(void)
>>>>        raise_softirq(TIMER_SOFTIRQ);
>>>>    }
>>>>    
>>>> +static always_inline unsigned long get_faulting_gpa(void)
>>>
>>> May I suggest to use always_inline only when inlining is _functionally_
>>> required?
>>
>> Sure. But it ins't clear to me why it isn't a case here? Is it connected
>> to that function is static and too simple so a compiler will do by itself?
> 
> Counter question: What is it that would functionally break if the function
> ended up not being inlined? (This is the question you generally need to
> answer to justify use of always_inline. Of course there's the additional
> case of performance being affected, but I don't view that as applicable
> here; I'm open to be proven wrong, though.)

Now it is clear how to identrify if function should be always_inline.

I put it only for the purpose to be sure that this function won't be 
called with prologue/epilogue but I agree that compiler will do that by 
itself.

> 
>>>> +{
>>>> +    /*
>>>> +     * According to RISC-V spec:
>>>> +     *  18.2.8. Hypervisor Trap Value Register (htval)
>>>> +     *   ...
>>>> +     *   A guest physical address written to htval is shifted right by 2 bits
>>>> +     *   to accommodate addresses wider than the current XLEN.
>>>> +     *   ...
>>>> +     *   If the least-significant two bits of a faulting guest physical address
>>>> +     *   are needed, these bits are ordinarily the same as the
>>>> +     *   least-significant two bits of the faulting virtual address in stval.
>>>> +     *   For faults due to implicit memory accesses for VS-stage address
>>>> +     *   translation, the least-significant two bits are instead zeros. These
>>>> +     *   cases can be distinguished using the value provided in register htinst.
>>>> +     */
>>>> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>>
>>> Well, okay, but instead of not losing the bottom two bits you're now losing
>>> the top two ones.
>>
>> Oh, right, I will add a cast ((uint64_t)csr_read(CSR_HTVAL) << 2) | ...
>>
>> It will cover all the cases RV32 which has 34-bit guest address and it
>> will be enough for RV64 where GPA is 59bit (the highest possible for Sv59).
> 
> Only if the function return type then also changes.
> 
>>> Also the spec reads as if htval only _may_ hold the original address of the
>>> faulting access. What if htval ends up 0?
>>
>> good point. then we have to emulate fault instruction and get an address
>> from an instruction. I think that for now it will be enough just to
>> support platforms which always write GPA to HTVAL.
>>
>> If I understand correctly if htval is supported by platform then htval
>> will be always filled for guest page fault. To verify if HTVAL is
>> supported we could do:
>>
>> 'Unless it has reason to assume otherwise (such as a platform standard),
>> software that writes a value to htval should read back from htval to
>> confirm the stored value.'
> 
> How does this matter here? It's one thing for htval to be capable of
> holding (all?) non-zero values, and another that it would always be
> written. If the platform doesn't indicate the behavior, I fear you have
> to assume that you may (perhaps even randomly) observe 0.

So to be very sure we could check for two extensions: Sstval and Shtval.
They will guarantee that under any circumstances it will be filled.

Also, as an option we could check that htinst value isn't zero as 
according to the spec:

For guest-page faults, the trap instruction register is written with a 
special pseudoinstruction value if:
(a) the fault is caused by an implicit memory access for VS-stage 
address translation, and (b) a nonzero
value (the faulting guest physical address) is written to mtval2 or htval.

So if htinst != 0 then htval is filled with GPA and a nonzero guest 
physical address written to mtval2/htval shall correspond to the exact 
virtual address written to mtval/stval.

But if htinst is 0 then we have to do VS-stage software pagewalk to get 
GPA and also we will need to decode instruction to get GVA.

I am thinking if it will be okay for now to cover the case htinst != 0 
and have BUG_ON(!htinst) to not miss that the possible future case when 
VS-stage s/w page walks and parsing of GVA from an instruction are 
needed. I think it is fine as all real boards on which I was able to 
test Xen has htval and stval properly filled and of course QEMU code 
guarantees that htval and stval will be properly filled in the case of QEMU.
Also, KVM is based also only htval and stval and I assume that they 
tested it on real hardware too so it seems like it is okay to go with 
solution that for now we are using htval + stval to get faulty address.

> 
>> And is it true because:
>> ```
>> A value of zero in mtval signifies either that the feature is not
>> supported, or an illegal zero instruction was fetched.
>> ```
>> (yes, it is about mtval but I asssume that htval has the same behaviour').
> 
> Right, but what you quote is specific to illegal instruction exceptions.

Oh, right.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 16:05:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 16:05:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394349.1633180 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwMJc-00035D-3Q; Tue, 18 Aug 2026 16:05:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394349.1633180; Tue, 18 Aug 2026 16:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwMJc-000356-0G; Tue, 18 Aug 2026 16:05:28 +0000
Received: by outflank-mailman (input) for mailman id 1394349;
 Tue, 18 Aug 2026 16:05:26 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwMJa-00034w-HO
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 16:05:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwMJZ-00HWf2-Ua
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 18:05:25 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8482be-2eae-0a2a0a5409dd-0a2a4508803e-14
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 18:05:25 +0200
Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8482c5-f659-0a2a45080019-d155802fb8f3-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 18:05:25 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so1105e9.2
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 09:05:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4999d078523sm143035125e9.6.2026.08.18.09.05.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 09:05:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787069125; x=1787673925; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=InfOa6qUmClzKj3WxgBIReQM4wfkrqswb3Yp/gAlkqY=;
        b=PWSalbjmxeSzlRR/aYcgJh1OhuZeOntMMtbNO9EhEhpuHBm8/Fc8Y1K16kZa9y1zh5
         5ENdhrEzxeWuG7pyWTdEaqJjSFaqxvNV/3Hnor70Dcu2PcpImtE5E8DZN/bPkWIJxJFw
         /GhSa8RtCG0P3TwgB43JBugIwNwWf+qDr7rDrxWAH+R/IzlZGwq6Fyv9cLWOfdJw7GwR
         mzXfXFdDhM2E6XoiFli0fFhgPtqEtgRMvnyTNsCWqNcJp9H2aVImBZizTL9AdXniw/mx
         XRBj45iCxBF6ikWwN7/oVA8vk+6DMjB/m3jmPzBcwR5j0Hq1fNrkWAyLwSP78UHc4xoy
         jIQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787069125; x=1787673925;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=InfOa6qUmClzKj3WxgBIReQM4wfkrqswb3Yp/gAlkqY=;
        b=LFWH9+15VGXtap/V3w9FUWSBV/bzQpr1SGv17P4FAYPOzR9S0jVWP4PRTZ31MciDah
         VxKqmgoMi53Sp9wQ1GpxSgTMmuYdtubHQeoSZRE6S+krxcY/IOFfxDeDBQYXDOxeVlzr
         f3CLz9ALkrQKy1F1+48Dq3/UVRlVklnMql3Vbi/K/jMHj7IpWuWGUFT4M5wmJGRp77RW
         WY2WFrVbEGNMWfBEVGlhCPQZ2IAzWUDQhWp3nc81+JhB2sAKPF9qWwTxaG3/IeGbdMCw
         v81pFucmbh20c/k6VqYshgFcKqu2r5oXWNZ8uQ6PD7f2fSv+/PPJirluQC4+F2v9i8JY
         aCHg==
X-Forwarded-Encrypted: i=1; AHgh+RraD/GGA18Fg1v3nLQ1vrFLg3nv4FIRYUFb3p3ZNOwKFVt2ttqOQfsM22wxHzlvjOWNUYe4PATgZow=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyeKMjRvq9sGSlN47vhYdE9JzBAGYisWdjK7j/eprpolxK/i1vA
	uaL/+OP8Dh/yC5BTQFGiJuamWFhT4LDnbYIeoG96KPO97DTzffvM7b8k0t46ZICHVA==
X-Gm-Gg: AR+sD12KbSiRK/mbLgijE1xK5xbHArrThcBV0bOTIzEO+cT0XvZ9GIdPk+E013ChEiQ
	0IjLmiy7Dx8zxtJ+cl/wy0YXVKWcvSjvudbJsV1RwfXNMtP5hqN6FnODaLkbZzMoSsG0s3GaR0h
	jvnBJxNSdIMopRYs1iOn1MdW3h2g+6qWpBfi3yZ9y4eRvbDRFR6pEzPCRDpcT7kKgaj0dPydabc
	TBOHl3jXBzyR+0IxgZ/YxeUCJhtwcHuea60FhcneSN9D03BmEPatVLvA/T1HkCL7Rx7m5mKwmZA
	4ZsqD7rre5osb2FhDL5vSROWjEMJz213g9/Rxp6MiqrTFDRMyKtqMaEVtZLNaJYwJyYMXYDHkIF
	Hu9+FPRM4KhN2XvCYzENNiRMVtg/z5m9l5HDJMGp6WFUaEPv9rv3bUzmfo+Y1aZ/ZRgXA1qPDUj
	pAMNA4svEBhrXh5205bkw0lQt2qgW7HvZjsnmUFMeLhHsYKs1w4rxiDI0FWMm64k2f1G7/SYhBr
	msRVHPGRwdfLoew4U32v9wXRxm0VxNRMF5xmMrAdLmDHOhHM2Va
X-Received: by 2002:a05:600c:848e:b0:499:8156:cd3f with SMTP id 5b1f17b1804b1-4999fb3f78bmr175917645e9.8.1787069124968;
        Tue, 18 Aug 2026 09:05:24 -0700 (PDT)
Message-ID: <35f997cb-e143-41bd-9360-fafff3c9bfc7@suse.com>
Date: Tue, 18 Aug 2026 18:05:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/9] x86/passthrough: Introduce pt_irq_bind_msi() as
 canonical MSI bind path
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298080.8631fc262581453bbf619ec5b2062170.19dcf3882f5000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298080.8631fc262581453bbf619ec5b2062170.19dcf3882f5000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787069125-D674387B-8B044975/0/0
X-purgate-type: clean
X-purgate-size: 10305

On 27.04.2026 15:54, Julian Vetter wrote:
> Change pt_irq_bind_msi() to accept raw MSI address and data values instead
> of pre-decoded gvec/gflags. Add msi_addr_to_gflags() to decode the
> destination ID and delivery attributes, including the Extended Destination
> ID bits from address[11:5] per Intel convention.
> 
> Update pt_irq_create_bind() to call pt_irq_bind_msi() via the existing
> gvec/gflags interface so domctl-based callers continue to work.
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v4:
> - As suggested by Roger replace the v3 approach (v3 patches 2+4) of
>   extending the gflags ABI with XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK and
>   XEN_DOMCTL_VMSI_X86_FULL_DEST() so callers could pass extended bits
>   through XEN_DOMCTL_bind_pt_irq. pt_irq_bind_msi() now accepts raw MSI
>   address + data and decodes the destination internally via
>   msi_addr_to_gflags()
> - Replace the gmsi.gvec + gmsi.gflags fields in struct hvm_pirq_dpci
>   with gmsi.addr + gmsi.data
> - Replace msi_gflags() (v3 vmsi.c helper that packed the extended
>   destination bits into gflags) with msi_addr_to_gflags() which decodes
>   the raw MSI address directly
> - pt_irq_create_bind() now rejects PT_IRQ_TYPE_MSI with -EOPNOTSUPP and
>   all callers are redirected through the DM op path in patch 7

This does not look to match what the patch here does. Peeking ahead, patch
7 doesn't look to convert to -EOPNOTSUPP either.

> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -43,6 +43,7 @@
>  #include <asm/current.h>
>  #include <asm/event.h>
>  #include <asm/io_apic.h>
> +#include <asm/msi.h>
>  
>  static void vmsi_inj_irq(
>      struct vlapic *target,
> @@ -107,12 +108,12 @@ int vmsi_deliver(
>  
>  void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci *pirq_dpci)
>  {
> -    uint32_t flags = pirq_dpci->gmsi.gflags;
> -    int vector = pirq_dpci->gmsi.gvec;
> -    uint8_t dest = (uint8_t)flags;
> -    bool dest_mode = flags & XEN_DOMCTL_VMSI_X86_DM_MASK;
> -    uint8_t delivery_mode = MASK_EXTR(flags, XEN_DOMCTL_VMSI_X86_DELIV_MASK);
> -    bool trig_mode = flags & XEN_DOMCTL_VMSI_X86_TRIG_MASK;
> +    uint32_t dest = MSI_ADDR_DEST(pirq_dpci->gmsi.addr);
> +    bool dest_mode = pirq_dpci->gmsi.addr & MSI_ADDR_DESTMODE_MASK;
> +    uint8_t delivery_mode = MASK_EXTR(pirq_dpci->gmsi.data,
> +                                      MSI_DATA_DELIVERY_MODE_MASK);
> +    bool trig_mode = pirq_dpci->gmsi.data & MSI_DATA_TRIGGER_MASK;
> +    int vector = pirq_dpci->gmsi.data & MSI_DATA_VECTOR_MASK;

Please consider types used, as indicated elsewhere before. I don't see how
"vector" could go negative, and I don't see how delivery_mode can sensibly
be uint8_t. Just to name the two most obvious issues; others may be on the
edge.

> @@ -850,17 +830,17 @@ static int vpci_msi_update(const struct pci_dev *pdev, uint32_t data,
>      {
>          uint8_t vector = MASK_EXTR(data, MSI_DATA_VECTOR_MASK);
>          uint8_t vector_mask = 0xff >> (8 - fls(vectors) + 1);
> -        struct xen_domctl_bind_pt_irq bind = {
> -            .machine_irq = pirq + i,
> -            .irq_type = PT_IRQ_TYPE_MSI,
> -            .u.msi.gvec = (vector & ~vector_mask) |
> -                          ((vector + i) & vector_mask),
> -            .u.msi.gflags = msi_gflags(data, address, (mask >> i) & 1),
> -        };
> -        int rc = pt_irq_create_bind(pdev->domain, &bind);
> +        uint8_t gvec = (vector & ~vector_mask) | ((vector + i) & vector_mask);
> +        uint32_t msi_data = (data & ~MSI_DATA_VECTOR_MASK) | gvec;

Please be consistent throughout with the use of MASK_INSR(): Here you're
open-coding MSI_DATA_VECTOR_SHIFT / MSI_DATA_VECTOR_MASK (of which only
the latter should really exist).

> +        int rc = pt_irq_bind_msi(pdev->domain, pirq + i,
> +                                 address, msi_data, 0, !((mask >> i) & 1));

The literal 0 here could do with a /* gtable */ comment.

>          if ( rc )
>          {
> +            struct xen_domctl_bind_pt_irq bind = {
> +                .irq_type = PT_IRQ_TYPE_MSI,
> +                .machine_irq = pirq + i,
> +            };
>              gdprintk(XENLOG_ERR, "%pp: failed to bind PIRQ %u: %d\n",

Blank line please between declaration(s) and statement(s).

> --- a/xen/arch/x86/include/asm/hvm/irq.h
> +++ b/xen/arch/x86/include/asm/hvm/irq.h
> @@ -120,8 +120,8 @@ struct dev_intx_gsi_link {
>  #define HVM_IRQ_DPCI_TRANSLATE       (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT)
>  
>  struct hvm_gmsi_info {
> -    uint32_t gvec;
> -    uint32_t gflags;
> +    uint64_t addr;    /* raw MSI address (0xfeexxxxx, includes ext dest ID) */

Is "includes" true? You need to cope with existing code passing rubbish there
(and I think we have said so before). E.g. in vpci_msi_update().

> --- a/xen/arch/x86/include/asm/msi.h
> +++ b/xen/arch/x86/include/asm/msi.h
> @@ -51,8 +51,22 @@
>  #define MSI_ADDR_REDIRECTION_MASK   (1 << MSI_ADDR_REDIRECTION_SHIFT)
>  
>  #define MSI_ADDR_DEST_ID_SHIFT		12
> -#define	 MSI_ADDR_DEST_ID_MASK		0x00ff000
> -#define  MSI_ADDR_DEST_ID(dest)		(((dest) << MSI_ADDR_DEST_ID_SHIFT) & MSI_ADDR_DEST_ID_MASK)
> +#define MSI_ADDR_DEST_ID_UPPER_BITS	8

The name doesn't make clear whether the constant describes a number of
bits, or a bit position, or yet something else. From the use below it
looks to instead describe the number of the _lower_ bits, or
(equivalently) the number of bits to shift left the raw value of the
(seven) upper bits. (In the end I think this value would want deriving
anyway, to make crystal clear where it is coming from.)

> +#define MSI_ADDR_DEST_ID_MASK		0x00ff000
> +#define MSI_ADDR_DEST_ID(dest)		(((dest) << MSI_ADDR_DEST_ID_SHIFT) & MSI_ADDR_DEST_ID_MASK)

I understand there's cleanup potential here, but please leave this alone
when you don't need to touch the lines anyway, and when the patch is
already pretty involved. Plus you don't even finish tidying - the too
long like is left there.

> +/*
> + * Intel convention: in physical destination mode bits 11:5 of the MSI
> + * address carry APIC ID bits [14:8] (the "Extended Destination ID"),
> + * extending the addressable range from 8 to 15 bits.
> + */
> +#define MSI_ADDR_EXT_DEST_ID_MASK	0x0000fe0

What reference is "Intel convention" based upon?

> --- a/xen/drivers/passthrough/x86/hvm.c
> +++ b/xen/drivers/passthrough/x86/hvm.c
> @@ -21,6 +21,7 @@
>  #include <xen/event.h>
>  #include <xen/iommu.h>
>  #include <xen/cpu.h>
> +#include <xen/ioreq.h>
>  #include <xen/irq.h>
>  #include <asm/hvm/irq.h>
>  #include <asm/io_apic.h>

Why is this? (And didn't I see patch 7 remove it again, when I peeked there?)

> @@ -367,20 +369,22 @@ static int pt_irq_bind_msi(struct domain *d, uint32_t machine_irq,
>          }
>  
>          /* If pirq is already mapped as vmsi, update guest data/addr. */
> -        if ( pirq_dpci->gmsi.gvec != gvec || pirq_dpci->gmsi.gflags != gflags )
> +        if ( pirq_dpci->gmsi.addr != msi_addr ||
> +             pirq_dpci->gmsi.data != msi_data )

You suddenly compare much more here. To prove correctness of this imo requires
a sentence or two in the description.

>          {
>              /* Directly clear pending EOIs before enabling new MSI info. */
>              pirq_guest_eoi(info);
>  
> -            pirq_dpci->gmsi.gvec = gvec;
> -            pirq_dpci->gmsi.gflags = gflags;
> +            pirq_dpci->gmsi.addr = msi_addr;
> +            pirq_dpci->gmsi.data = msi_data;
>          }
>      }
> +
>      /* Calculate dest_vcpu_id for MSI-type pirq migration. */

Such a blank line would best be inserted when the function is being split out
(or as per the eralier suggesting, maybe when its body is re-indented).

> @@ -448,13 +451,29 @@ int pt_irq_create_bind(
>      switch ( pt_irq_bind->irq_type )
>      {
>      case PT_IRQ_TYPE_MSI:
> -        return pt_irq_bind_msi(d, pirq,
> -                               pt_irq_bind->u.msi.gvec,
> -                               pt_irq_bind->u.msi.gflags &
> -                                   ~XEN_DOMCTL_VMSI_X86_UNMASKED,
> +    {
> +        uint32_t gflags = pt_irq_bind->u.msi.gflags;
> +        uint64_t msi_addr;
> +        uint32_t msi_data;
> +
> +        msi_addr = MSI_ADDR_HEADER |
> +                   MASK_INSR(MASK_EXTR(gflags, XEN_DOMCTL_VMSI_X86_DEST_ID_MASK),
> +                             MSI_ADDR_DEST_ID_MASK) |
> +                   (gflags & XEN_DOMCTL_VMSI_X86_RH_MASK ?
> +                    MSI_ADDR_REDIRECTION_LOWPRI : MSI_ADDR_REDIRECTION_CPU) |
> +                   (gflags & XEN_DOMCTL_VMSI_X86_DM_MASK ?
> +                    MSI_ADDR_DESTMODE_LOGIC : MSI_ADDR_DESTMODE_PHYS);

We prefer to treat the ?: operator a little special, to help readbility:

                   (gflags & XEN_DOMCTL_VMSI_X86_RH_MASK
                    ? MSI_ADDR_REDIRECTION_LOWPRI
                    : MSI_ADDR_REDIRECTION_CPU) |
                   (gflags & XEN_DOMCTL_VMSI_X86_DM_MASK ?
                    ? MSI_ADDR_DESTMODE_LOGIC
                    : MSI_ADDR_DESTMODE_PHYS);

> @@ -617,7 +636,6 @@ int pt_irq_create_bind(
>      }
>  
>      default:
> -        write_unlock(&d->event_lock);
>          return -EOPNOTSUPP;
>      }

Seeing no other locking change here - how is this hunk to be explained?

> @@ -858,11 +876,10 @@ static int cf_check _hvm_dpci_msi_eoi(
>      int vector = (long)arg;
>  
>      if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) &&
> -         (pirq_dpci->gmsi.gvec == vector) )
> +         ((pirq_dpci->gmsi.data & MSI_DATA_VECTOR_MASK) == vector) )

MASK_EXTR()

>      {
> -        unsigned int dest = MASK_EXTR(pirq_dpci->gmsi.gflags,
> -                                      XEN_DOMCTL_VMSI_X86_DEST_ID_MASK);
> -        bool dest_mode = pirq_dpci->gmsi.gflags & XEN_DOMCTL_VMSI_X86_DM_MASK;
> +        unsigned int dest = MSI_ADDR_DEST(pirq_dpci->gmsi.addr);
> +        bool dest_mode = pirq_dpci->gmsi.addr & XEN_DOMCTL_VMSI_X86_DM_MASK;

If this is now the raw address, how come XEN_DOMCTL_VMSI_X86_DM_MASK can
be used on it?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 17:15:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 17:15:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394371.1633190 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwNPK-00046v-WD; Tue, 18 Aug 2026 17:15:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394371.1633190; Tue, 18 Aug 2026 17:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwNPK-00046o-Rz; Tue, 18 Aug 2026 17:15:26 +0000
Received: by outflank-mailman (input) for mailman id 1394371;
 Tue, 18 Aug 2026 17:15:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwNPJ-00046i-Pz
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:15:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwNPI-0005Y0-Rh
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 19:15:24 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a849312-2eae-0a2a0a5409dd-0a2a4507b9fa-34
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 19:15:24 +0200
Received: from [98.137.64.83] (helo=sonic305-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a84932a-b4ea-0a2a45070019-62894053a821-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 19:15:23 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Aug 2026 17:15:21 +0000
Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 98c40eed43962414fb5e048669f343c4; 
 Tue, 18 Aug 2026 17:15:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787073321; bh=ww0do9RIpWZpsVbpNSFOhezYk+OgminhDdsrY20XsMg=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=GaNh19QUvPFaQzjGq8mnc2VsGg11xf0nVMfhLsjLDYKmOc0h3V91ozijb2eC4o0yn1C8qkGfWw3R86GNTC0AkabW8RUdvBrpSaR5926j0//2ZsMeSTiWoV7KHSX4mdxk7wcD1DQUevi4RngGwzhzj65gjd39zarlbpY7XRP/mn/rhrH1aeQxQE3ZYiXr1dH1i7I3V1OvA+mcaH8XUE0oODYvU6YGa8w1h4mkuPUg9HfkRYSLG77MLR7HsxoT/lFOO5hUV0zCaPmh60YlpiC34BE/0XYMekcN4V+oxnDatdlSb6Fe7fUn46ZPyLZOIU/7ATgzjVe0fwS2gdTv8FbJvg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787073321; bh=v+4Qi5BEw41TP/0I2vqdj5LVgeJipweToZ70c0VID5v=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=H8FrYQlVToUpnFbShzXFwcfffrsuVhtxeJPz4YGDLDxO37eQ2/Od3KHbnHp+QebBdDO/VSyrKBpcGuLJJsT28GD2pKrL6GIYmyagIrmOqlEtVWPCjCkh/VEmexn1FwsVCSJXI2A964Atzk+Z6CtXf/Yd0F6g6lusaDcl+VFMXzN5cnmLRXdFegAP/Drc/tPcv6eSeZ0tc/vjJ9Uudn0px2xLmhAVaz3rRD17kUGsD1LwC87Z6rYeIoV+19hnQk04OATOdaAxTOJVmVciMMx84yMJjan098aCwDb85NGiwacp3ipbd+TjeFYDz2s21cEyxs/Pv1SU5jM/Og7VeK7Sfg==
X-YMail-OSG: E6ofAT0VM1n9r71xfRntP8iTNGo8uLmyyFcsFXM3pVg29_OofBq.fDJ1ed6s_lG
 CMLyu2VGGiaPkvmlycrT8I2unAV5dSg2v2gqoBBAuQmeAUkAeZBvrT7fuJiv6u7o.ITpdBFFOGMJ
 BFrwrh6L8M9ggcVmez7q_f0kU6KXdtLD3yjYPaOqyTVFrzEDlAvYax9fxdIcBygJz00P57yDk5ff
 RdAyiRcxXIuIq3BAXnPwxOKTliuLGsNazlZV2ZyRAAb5PVB5eScGMXfmfSkoKH_mEVZ0B9qXwpBo
 JDcMplMaRmmpym3jQo8SJdodeZKubLDYxDws00vKQIBkao0Sw8Jjw2a67H7gVd2z09m48ZkC5Ssa
 4bHW9FoxL.tM4Eg8qfZ1oIL3t03vblVDjbMlir1wWJ0WOpsAtQp3Yb6ndOC3733h4wF4yhEMrykw
 frIQs7zYpXHwrOYhcVKAC4nDawrOiXkmvCiBYbQf5CvJnuKoo9Rm0ntkmoWKc2GPRrTApKMTFGmB
 KiSVku2ItFIggtgPsk7PazlFiA5.DRAUGrRnqvsbivRY4s2DVaqLUuRH1eleGt4RCGYEpbvosX7z
 V4ttapJHEgFOUpgvOpzrC_cPKUnuPHlnm3y3SnnWw3thp45NpA9jwXW.2IgXKQ1wTVLQyc0NAaSM
 28GZtu6S0sLgPfGuYLLb2XKw8W01yba6BEjr0PjF04n3UdCSxLytjkuURtyC.QhyFS8jecZKAdkg
 P3aGynupAAtqlmooZ0SLE_9TiMkJqYPhCprxL_r7ygxXE1rLIxgOT0ktkGi5WVUbvHrdv9PW_PUS
 ZrySvs9KH2wwlOdAFEqsP6CyipgS6JshkpjWbE9xS1Y.B2qPgihvFdDGD_1Wz6Fku2BTgev06N0w
 .uPyoOv5MXAA3h0ZQhLNnTz5o._BCSTTUh3OBt9AMTyBd037roaQEnIh5D6WadlNHkREFa.6sAi6
 a3UG6rfd0.kjA1tIIgegNGNZWdQogobFVzSNM9H4Qpok2bXdI.J.yiwT1f0SLxL0mABhedn0KxPS
 Alt0Dl34KoXAuvZlCodGFo9uQ3r_0XWxbKOxSAkGaQ3NZWQkjHtTjDnjeybYs8w2CZEtTbgnvLky
 7MM0Ridv22E9zHQYgTVHzOHQ4UHa7e1fZb48i2xLiw4D2XJ10KR9WNyeoBbSZGmY1QQ_yZ6PcUmp
 8w4.qboEupKschHuEyPwJzYqLrfgW1hnomHzWRzQ5aw8yCqhOE1j7nPaGSFGuDuWrHf6RaYGLt3K
 zhMF554qAB_UssU_7NAYBZ2y0aRemhFdTgaiPrQNmHWoE_8F2EscFhWmghiMSUXw0FzyWm2YeOQJ
 RU3shSA63BXJk4oin0fPq1UmlXcQPgVsDyekqrqa8PxZijZFEeH9UN5fjR3js8j35783LWg6Mht6
 AReQFRIyJDyEIqEQpPZyjjI.hrV8wAkNL8F8mcboiM9qB1exOTKwANVMZwF8n2w_7dS5x3xrOagw
 iXKwDFHjJWleZfUnz0aI1.SjWuo06PZWiMGIxjcA8r05lMMwW8fPobbY84VF1sNLg6vzhBZAUAAt
 O22QSOw3GipDrZN.wsqPxdI2YFOlS8B1Zqx5Hb9B6.320hGRtWvaT4wLDflAIEXrk6kRIFymMNYD
 gEidBndyjIqLFSPncyuwhTd82S04JF1L48M0q.SKGQdwe9ERIlUCi1LHqpxWyPRUYeDrb2NvLaXM
 xVg.BBGlHGcMyPuEIQEK7R0BfSrwtt_Lid3287KqYy9MEEzNQPcncUVB.qwNbtl7CFD1031LVgq5
 60pwaFYEm8jOpvRiU5IJjaDoed1WGMtKRMBeGObvXrRZy0u_8ygMgHtGmlMGV5sknK5MkMiPUkLE
 Ma82oJ_H2APgSNCLMqhF.h8jbS64YuYCRo53ILHhAeFSB0v9WisIBaZCig3EDdPn1rUw_8nG5121
 X2orfiUYj5frjATJoJl1E1vYl4VFrqwRPLLQwiqwgoGUZoLNmp_pJ4Qb4anc8x8eUEdbsiqU8vVh
 Wu0Mce8CiqBCxgOOKeSnnmGRl0fqmlkoeUEYFS5_1EPtoL8so2Y1EvTmOWBEUjqmwN4xxJ.xg5Q.
 4QLD71532U6lLj4n46CDzKXCd7mpw5fZmPNJEJKhgYyDV9EKdz9N.Tr09rDXxFmC0SdiLHvWjoov
 pZXdWBtdggJCzZmIC6s3MpHTp82wa2cx5gJKYFim_cJ4EXM8RaDgRD81jEqfQ2XqNJdo76usFuvf
 qTzdOqzp8PLJjNpeRgfURzVcQTx_SNffSnBfyDL3GOtpEQgY-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: bfde24b5-fcdf-40ac-8182-a0be452d90a5
Message-ID: <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
Date: Tue, 18 Aug 2026 13:15:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
Content-Language: en-US
In-Reply-To: <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 8588
X-purgate-ID: tlsNG-ef75cf/1787073324-362C4AE4-CF58CDBC/0/0
X-purgate-type: clean
X-purgate-size: 8751

On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>>> -- snip --
>>>>>>>>>>>>> +    /*
>>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>>> +     *
>>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>>> +     */
>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>>
>>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>>
>>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>>>
>>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>>>> by its DM.
>>>>>>>>>
>>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>>
>>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>>>> guest are also assigned to its DM.
>>>>>>>
>>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>>
>>>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>>>             DPCI_ADD_MAPPING);
>>>>>>>
>>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>>
>>>>>>> If I understand our current implementation correctly, this statement
>>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>>>> in hvmloader code).
>>>>>>
>>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>>
>>>>>>> I don't think this statement makes the host OpRegion
>>>>>>> accessible to the device model, though, so I think, if I understand your
>>>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>>>> same kind of "layering violation."
>>>>>>
>>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>>>> needed permissions to access the pages itself.
>>>>>
>>>>> So, are you saying it should be possible, without any patches to either Xen or
>>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>>
>>>>> I think I could implement what you proposed in an earlier message and do
>>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>>
>>>>>> The more correct thing to do might be for the DM to
>>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>>> separate question then.)
>>>>>
>>>>> Actually, when I was developing this patch, I tried first to do it that
>>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>>> host OpRegion in Qemu.
>>>>>
>>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>>
>>>> You don't ask me this question, do you?
>>> 
>>> Are you offended I asked this question? If so, I am sorry. You make me
>>> afraid to ask it again so I will not do so unless you permit to do so
>>> again.
>> 
>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>> qemu person, and I never have been. I can't really help much there.
>> 
>>> All I can say is that surely qemu
>>>> has an existing way to map (host) physical memory; see e.g. how
>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>> (independently) there and here there's the issue of how to accomplish
>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>> 
>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>> can access the MSI-X table of some device, that does not prove that
>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>> still stands: I still don't see proof that it is possible for Qemu
>>> to get a pointer to the host OpRegion without any patches to the current
>>> implementations of Xen and the Linux kernel.
>> 
>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>> could come up with, as that's one tiny area of qemu that I know at least
>> a little.
>> 
>> From a Xen perspective, this analogy should be sufficient: All you need
>> from Xen is for it to permit to establish mappings of the underlying page.
>> As I've pointed out when commenting on a code fragment you presented, the
>> DM (domain) looks to have permission. Everything else is a matter of
>> establishing such a mapping. There the MSI-X table code may also guide
>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>> appropriate to do things this way in qemu, and since (b) it is, as said,
>> imo a layering violation.)
> 
> I agree that accessing the host /dev/mem directly is cringy. I would not
> really want to do it that way for the host OpRegion.

I looked at the current mainline Linux kernel code about access to memory using
/dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
ordinary system RAM but allows access to what the kernel developers call
non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
in the Linux source code:

>  * On x86, access has to be given to the first megabyte of RAM because that
>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>  * and similar apps. Since they map the entire memory range, the whole range
>  * must be allowed (for mapping), but any areas that would otherwise be
>  * disallowed are flagged as being "zero filled" instead of rejected.
>  * Access has to be given to non-kernel-ram areas as well, these contain the
>  * PCI mmio resources as well as potential bios/acpi data regions.

So I think things like the MSI-X table and the OpRegion would qualify for
/dev/men access even with CONFIG_STRICT_DEVMEM set, so after seeing this
I expect I could get a pointer to the OpRegion running in Qemu using
/dev/mem and mmap, as long as it is running in dom0 with root privileges.
But as I said earlier, I agree that /dev/mem and mmap does not feel like
the right way to do it.

So I would like to come back to something else you said in an earlier message:

> (How in turn the DM would learn of the contents of the opregion is a separate
>  question then.)

Let me phrase the question like this: How could the DM gain access to the contents
of the OpRegion, and for that matter, also the contents of the MSI-X table, without
also committing a layering violation?

Chuck


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 19:15:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 19:15:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394404.1633198 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwPHg-0002LT-6T; Tue, 18 Aug 2026 19:15:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394404.1633198; Tue, 18 Aug 2026 19:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwPHg-0002LM-3a; Tue, 18 Aug 2026 19:15:40 +0000
Received: by outflank-mailman (input) for mailman id 1394404;
 Tue, 18 Aug 2026 19:15:38 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <pr-tracker-bot@kernel.org>) id 1wwPHe-0002LF-1W
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 19:15:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwPHc-00G6o9-Gz
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 21:15:36 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <pr-tracker-bot@kernel.org>)
 id 6a84af46-bab6-0a2a0a5309dd-0a2a45038cbc-24
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 21:15:36 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <pr-tracker-bot@kernel.org>)
 id 6a84af57-fae8-0a2a45030019-ac6904fe8996-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 21:15:36 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 9E86360A5D;
 Tue, 18 Aug 2026 19:15:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 554EF1F01563;
 Tue, 18 Aug 2026 19:15:34 +0000 (UTC)
Received: from [10.30.226.235] (localhost [IPv6:::1])
 by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id
 198D83927051; Tue, 18 Aug 2026 19:14:47 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:In-Reply-To:References:Date:To:Cc"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1787080534;
	bh=WQ/hUD8aUQayFuFPezMfBtkN2LU+sg4JGiFoFwMC0j0=;
	h=Subject:From:In-Reply-To:References:Date:To:Cc;
	b=gVyAhbaYoAj6RUAY7f97oNyGgiX+ZGVY0y9YGUbpC/BO8oBrt/olVbHwpZgws9r1l
	 yigkEd5IBU0H4cV7nQYEbnY4Fc8fhbckqSM4mcJPdxpP6JryRO+8MwHNXet0lqguwn
	 Vpj98ZNIg8Tts6afReILs+oowhhGCJmsVkk17xvDgW1isz259E2PTJijcvLk3nD4FB
	 a9ENfnc7GW3u2d6o2CJsFv+ayGFUSLOFoD+WRvdUxLpHs+A4AOJvKb/WGXcHybeIp7
	 zzA5WZBCBs9+VYFor5PIFZFpLRbxMInqzapvLrk9x2Ap/d2ocVHYlsvxyuP5LHKYpT
	 UUWd5hNNL8BQg==
Subject: Re: [GIT PULL] xen: branch for v7.3-rc1
From: pr-tracker-bot@kernel.org
In-Reply-To: <20260814112112.4042845-1-jgross@suse.com>
References: <20260814112112.4042845-1-jgross@suse.com>
X-PR-Tracked-List-Id: <linux-kernel.vger.kernel.org>
X-PR-Tracked-Message-Id: <20260814112112.4042845-1-jgross@suse.com>
X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.3-rc1-tag
X-PR-Tracked-Commit-Id: d330fb86a7170f845123ae82d95df440fad9b707
X-PR-Merge-Tree: torvalds/linux.git
X-PR-Merge-Refname: refs/heads/master
X-PR-Merge-Commit-Id: 2df813c9a6b6704b75aec7538d2225292e6b6fe6
Message-Id: <178708048575.2235733.17985325151202501364.pr-tracker-bot@kernel.org>
Date: Tue, 18 Aug 2026 19:14:45 +0000
To: Juergen Gross <jgross@suse.com>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org
X-purgate-ID: tlsNG-33051d/1787080536-6CEDA4E9-B00B0950/0/0
X-purgate-type: clean
X-purgate-size: 362

The pull request you sent on Fri, 14 Aug 2026 13:21:11 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.3-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2df813c9a6b6704b75aec7538d2225292e6b6fe6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 20:07:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 20:07:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394423.1633207 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwQ69-0000VI-Lh; Tue, 18 Aug 2026 20:07:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394423.1633207; Tue, 18 Aug 2026 20:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwQ69-0000VB-Ix; Tue, 18 Aug 2026 20:07:49 +0000
Received: by outflank-mailman (input) for mailman id 1394423;
 Tue, 18 Aug 2026 20:07:48 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dmukhin@ford.com>) id 1wwQ67-0000Uj-6c
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 20:07:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwQ65-00Cd9i-RZ
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 22:07:45 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a84bb5f-bab6-0a2a0a5309dd-0a2a45099ef8-32
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 22:07:45 +0200
Received: from [148.163.146.23] (helo=mx0a-00498f03.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dmukhin@ford.com>)
 id 6a84bb90-be1a-0a2a45090019-94a392179122-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 22:07:45 +0200
Received: from pps.filterd (m0367123.ppops.net [127.0.0.1])
 by mx0a-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67IJUQhH1656418
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 20:07:43 GMT
Received: from ch1pr05cu001.outbound.protection.outlook.com
 (mail-northcentralusazon11010039.outbound.protection.outlook.com
 [52.101.193.39])
 by mx0a-00498f03.pphosted.com (PPS) with ESMTPS id 4g4udej4a5-1
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 20:07:43 +0000 (GMT)
Received: from BL1PR13CA0145.namprd13.prod.outlook.com (2603:10b6:208:2bb::30)
 by IA6PR16MB6910.namprd16.prod.outlook.com (2603:10b6:208:5e3::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.12; Tue, 18 Aug
 2026 20:07:40 +0000
Received: from BN5PEPF00046989.namprd02.prod.outlook.com
 (2603:10b6:208:2bb:cafe::40) by BL1PR13CA0145.outlook.office365.com
 (2603:10b6:208:2bb::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Tue, 18
 Aug 2026 20:07:40 +0000
Received: from mx0a-00498f04.pphosted.com (205.220.161.53) by
 BN5PEPF00046989.mail.protection.outlook.com (10.167.245.38) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Tue, 18 Aug 2026 20:07:39 +0000
Received: from pps.filterd (m0426317.ppops.net [127.0.0.1])
 by mx0a-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67IJY0pv2229532
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:07:39 -0400
Received: from smtp-us.ser.proofpoint.com (pmta-use.ser.proofpoint.com
 [44.208.76.22])
 by mx0a-00498f04.pphosted.com (PPS) with ESMTPS id 4g376rbqg4-4
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 16:07:38 -0400 (EDT)
Received: from localhost ([19.12.92.221]) by cmsmtp with ESMTPSA
 id wQ5xwSO4ay2VKwQ5xwkZFA; Tue, 18 Aug 2026 20:07:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppford; bh=WzM5qxYmd9iyICPmUpiIzQBL8ox
	hd/QudnmGtoNLiig=; b=kevm/YU9n/8sQNLdC4FCYSw8HmZml0pg1dHjISvht16
	AuQvFmdgtRV/O5TD7iR9DcEnsq06bN/Hr7v8X0BjSwKedB0HbB3NFjbvOMkemvh+
	KTOKN7YII3ZJTZOvnlmc80072PyBcmLlRs/DkRYYxLOe2Q208B0WmS9o6pxC1HSG
	nnpIpjowIvdk3K7k+KXPGD2samaaHR4j2r/Fw/gkEPwnTdV5AEZwyjhZ5P4SaiWa
	NawoSRMdudfV8ldqKqQNZu9xtq8TfIzGlkiMWt4qVjJvvGjJo6lkYOAQINPUwtCc
	kyX4ZIOErac5SIzTPD30o9qRcSeH3Df6U1afyOb5g9Q==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=U2ziYU2Bl1vKtf2KjGaotU1Wl7Ab2Lz3/XGKSC3vLO7AMeYLsf7ZpEESLVS2FJ044zq1XUntN642g/oN9yaGam20eqBSbZbiTCRHVEGtO1ikYVRBEx/JrVrl0mPje9797wuQ7HRnfIirFbhTvUenOzhzBr2Ux7uX+oKU48wHceRg01LBS4cupuejvEWUsvsEita/Kn5dlX2I18jyp8C+LFaOXpwnQluFjHE0+xrIg/584KN2EVoPDMZNT5CDK5Fzp0vf7MaqDkXtg83MoohNL9DQ0Nuh2FSatsvW4CmOuiwshEFTCpyj+nk+5P2SRmzzAK/we3TmCTyYc2cX8HFFzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WzM5qxYmd9iyICPmUpiIzQBL8oxhd/QudnmGtoNLiig=;
 b=CWAHJXGnYemxt0iYLNXIiq57PXA3+z3znVFzIUdYp5fRTClPf3pURClCkw1eYyHEONRYUUkjfy9F1I5u7AvtvZOP2BdnkgGi1511i2Ccjzh1Pkq3AgsG0/LNhGMrItuN0lxvDjwlSkXpeFLZQHT7U18Yeht9b/HnRJTka0of46rtduXfCRoIMYXYt2vMZxe8PAHzFKqFvPEjHCDKiFdsez4gvMKunRTaMtWWxEwCoIlpcAoJfLRoiVTa7/DZW79u8NcB10IyR2Y0j1bmruDYSeFPZOMdb9QbDVaAGyow3DfZSffda2daPzWMntnBg39j0wyiXEqY79aoPyAFXyh+/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 205.220.161.53) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none
 header.from=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com; dkim=pass (signature was verified)
 header.d=ford.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WzM5qxYmd9iyICPmUpiIzQBL8oxhd/QudnmGtoNLiig=;
 b=Vj7RetxRZI1Bcam+brUjIoJmQ4rITdvQfRqOEe9UBtoQZvMli6f0GJMNusHTvdHZH2i2Jt0vxHb2NUAXoapVuXuYQA+n7mGywZ932Wt5Yt/vRWjN4u5igE/UZnqHX9hMnekNwbuviJ5y1OL1BjKNA1xb5qq5wyHboqAvXe5njVY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 205.220.161.53)
 smtp.mailfrom=ford.com; dkim=pass (signature was verified)
 header.d=saarlouis.ford.com;dkim=pass (signature was verified)
 header.d=ford.com;dmarc=pass action=none header.from=ford.com;
Received-SPF: Pass (protection.outlook.com: domain of ford.com designates
 205.220.161.53 as permitted sender) receiver=protection.outlook.com;
 client-ip=205.220.161.53; helo=mx0a-00498f04.pphosted.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	saarlouis.ford.com; h=cc:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=ppserprodsaar;
	 bh=WzM5qxYmd9iyICPmUpiIzQBL8oxhd/QudnmGtoNLiig=; b=G6NCSW4lU3MF
	pRUFbISTwwdKAOD+nf4ntNpfoUcy/Ab0dLtcMRZAQD/vzn73vvE7HQ5B5xBIjgmr
	5FIO847EV98z17Qx9tlDXGkgvRexOd7PNU/dpD6nYXOrAoMhw5RduhBYisjERFwM
	4J2MaxJJoaJbYnJc/rG+ocYXlK88y+Qg215zprE9UWvyRBeAKhbkJkZ7g5iDduqw
	wxd+i1Ma4QfwMSHBeJYABnJBEv0VfIF3OLT046NuL76OOAFa4pQOsZA7IIkvIX2z
	IDtcWG+2kf0iKwaFkp+i3x6Lhok+htHJEAuKhJHIn6iZGVKVeYsjT2y7qAO3TKgG
	QrlyyPlYXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=ppfserpocford; bh=WzM5qxYmd9iyICPmUpiI
	zQBL8oxhd/QudnmGtoNLiig=; b=cNN/lzpPdUhPn7zVXpYqDBNxYscIGB4lw2Kx
	wZkDjzkD3sY6rMPkvTG2WVokj5p+Ejw0k4BXpHauw8lcz6nT01xf8xnbxZkJdn7f
	BsT7mGMzPP53uJUlNbaIjj0dpkIiAT8oYO9VovZfL/tIkIYz2L/VZZjGFnGe+/j0
	ea3azJZWhg+Sus5qHq/D4oJCskfxls+CuDh/EK7oYTY1PfSVNYvD2kCPYrNHrDZQ
	R6Hui3TrcPmNbWn8+fmqX3hOcWOdyAxyHK2ch2vAhJCxpYw16EIcLTkeVm4hQAuO
	Np4t+J45HiDEH969LCNTZ3x9mZCq+67t5RbOL1yFyQprYl4ueA==
X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7
X-Cloudmark-MID: wQ5xwSO4ay2VKwQ5xwkZFA
X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe
From: dmukhin@ford.com
Date: Tue, 18 Aug 2026 13:07:36 -0700
To: Jan Beulich <jbeulich@suse.com>
Cc: dmukhin@ford.com, andrew.cooper3@citrix.com, anthony.perard@vates.tech,
        julien@xen.org, michal.orzel@amd.com, roger@xenproject.org,
        sstabellini@kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v6 0/2] add keyhandler to show Xen command line
Message-ID: <aoS7iF7OQ2VEAluz@kraken>
References: <20260814010206.1321724-1-dmukhin@ford.com>
 <c2cc1049-3b92-4a72-bbf9-c49b2c6ff280@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c2cc1049-3b92-4a72-bbf9-c49b2c6ff280@suse.com>
PSER-M365-App: SER-APP
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-18_04,2026-08-18_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 bulkscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 phishscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608180147
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN5PEPF00046989:EE_|IA6PR16MB6910:EE_
X-MS-Office365-Filtering-Correlation-Id: 028ed0e3-6669-411c-f62f-08defd645b3a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|1800799024|82310400026|23010399003|376014|13003099007|56012099006|10067099003|11063799006|18002099003|4143699003|22082099003;
X-Microsoft-Antispam-Message-Info:
	HEhJcSOReOxU/vEykP/9ODAPnd1IkEXbZI46RpeVxxPBFptmTtEDPm2F0nGEIYHqPbIa5De7Ybfa+DrCPnnGMvJC7yOdD3Nr1zatazjqK0B9qHp5OXaTSOZ+u2lsIbAASLLuuPd+MbF7yX3kJi1A8Vj92XAnIfou+RaBdujzZdRcekYhMV3xXIpFVQIkpJPKtB35bHVVE6C71s2qPMzEwo1HO82iSnO/ACWmypqUmhLtcRpqjDTpQs3OIP65OUtwaBP4r+Slx+rVgro/1ufPgxA3IBq0zbLoK6CAl5ocFu2Cg46wAd67Es9lnwSD2KdJJ/AZSuhz7xvLA6pL5IW/XQtdW+IJC/fBKRnUp52Dsj4COVazMmgCHe6RaDT+PbfBvxjdx0Pvo85hGxiiXIN+xFZyUNC0hqBLFXEhHznKTYmYDGjre4FhdiX70fYbWCADG/lx6/n4RIQcflbWMGyluzShmCIJglx9oIogMItZqRZehu+cLNd66YKXYtd92kb0dVabkhjb8Z2DVHoMwAhxF7YQl6kALsqpNpq2X2Utcw8gv/SQQJ92+wNT7tlrR31xBupdM9IgRAX4Q9Atdxez4U02ticzTR+h+JkYg/TtW7utShRnhjNgD6LgAjnTPDFJI5TN4jwqc3fkD0D7sT5gU3tUw2m2lBWyrw6eRwWoWwLGGh7mnfcj8x0bULMLzQVMu51eM4rNxKZnxGTQ1Tz12A==
X-Forefront-Antispam-Report:
	CIP:205.220.161.53;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0a-00498f04.pphosted.com;PTR:mx0a-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(82310400026)(23010399003)(376014)(13003099007)(56012099006)(10067099003)(11063799006)(18002099003)(4143699003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	n2cAXZnvG8oKBVGu0piN5kT8mFWSz4TRrhJeZvG6OHkg5teeE+dwFkK9gZEPZBv/aFA71bAq+HlhpK9tu7pP9KHM0uCO0kmFA4OIH6c43SjPBPxuH1m5yWcrsTJ0nLYGU35Y7V8UwO3oZnqyopdh8+d2mVY+Pt4DLC8U3gwyNkrx7YF5ihPZOy9MW7Gje5vYFbQE10jncToPL5NkvoePy4RKcjlUEnCK2OctVZ2MpxeeBeeuZMW0BzhJ4hyyG1Ti9BNNdJh5nJygbsXTRb560FxIfx/Z8ReIMkWRNK6YmMFCiA+7/l7qeQYCs8hkikoAO2H7X/Onb3aPU5Fh0EwntvtnBTn7VWtV7y2ynlAU5jbLvaBg7+xwtt3GncUWqWgpT1SOGdWeush4wAVyU4+yFjR/edVd00B/Sc5qYevyfLU0+UPTtoTBPNCGKJUdKQnl
X-Exchange-RoutingPolicyChecked:
	JGG1uCuHBjVm3r1dbL1TRtQ7KxGWuL4jXzV4V58k40WcDd1kswnhZdPkKG+ayAvckPEclBRQ1fzKqUQkFH+ISPEcvlvRwc4F16uq20vsb8OOBjc724Q6UZLXmC9axSSAbkmirEYl8T/gV2d17ENJlvOGb7hBWMBHxxpLQ0GWlXEXQp4Vd9VXfuZHUFlqmM/Jl+2heIsJznPvDcCR6cjjNWoHrvwdqiLC2aUEi2Kv6YqbQVBEGp/i3uARNSErtuk7963nYc+oQQ6VHEYsDHE2/L0a683reuGw6wMcWqs6t+e0fpovQ58LJ2waPsRbs7V3qr48aHGGI/iz38j2Nih6uA==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	uKf4PswFrUcTlNlAp0vau6BJ/brvt2OR2V5iE0yhRlq2aj854wifHqvYkCMidKXYC43QANkZWYIzW01j9kTewWh+L9SwqI2p3vWdXd+sWcajjz5hVsrByEqLVqDlTvY9xOw9Zsup0AK8USloObGZGRE4tryCR8TJgAyOZPUG8UZDCK5w5pDQ2fpUUAb5VMb0xSB657wMN9dM5ANZz94C+ox754b5MlxSlr8cq/4pKlIVfXsF97ToHNq9QGBPlYHB0E6JlfVLwpzuP/5dTuge1a7/DamXxwYKkNRWsBMQ2e09PEJExrUFKf6KuibBsjm2fB6i7SM0scv9xXbWFbIAt9H6HWhPFkZP4baFr15k0G3nK1FbdNe5IWBEYmWq0qrMwnH4sBXHSMFEGFnFXaN90GP70wmLSGGOJhYEvls5umqykwlzpcszfNfDqd8Uzj6aqHySkadExjQsaPqGv0HyvJu++71cgR98qm83cVGCQKs0LWgLwgGaki4d8aMUoX3l2Nojcjd7N4IsiZueA6M7OLs4PoGXw86s1PMfKQFpm9nw+f1wnl8aB7IimfGav1U9+keMYSaCATFMqQC+uYg+RqCuHkMrBbbxT5sWok0CjfxWLsP6/KBtxZnOczFzFW1LKAXLP7lQMdx9xnXh1uj1Jw==
X-OriginatorOrg: ford.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2026 20:07:39.9243
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 028ed0e3-6669-411c-f62f-08defd645b3a
X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[205.220.161.53];Helo=[mx0a-00498f04.pphosted.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN5PEPF00046989.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA6PR16MB6910
X-Authority-Analysis: v=2.4 cv=VsETxe2n c=1 sm=1 tr=0 ts=6a84bb8f cx=c_pps
 a=Bwi9XBBeLLDh9/ECaGV8vA==:117 a=lOEMawUel/sSvQipkIvNbg==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=kj9zAlcOel0A:10 a=Sv0fKeRqtYgA:10
 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=N9_n2FxmZfwfyRXvS9-E:22
 a=VwQbUJbxAAAA:8 a=cbNQJ9GKAAAA:8 a=p0WdMEafAAAA:8 a=iox4zFpeAAAA:8
 a=cQZ98t5XXQgEeC-qFB4A:9 a=CjuIK1q_8ugA:10 a=ZXulRonScM0A:10
 a=3whSkbs7g9Me0DR5EJEX:22 a=WzC6qhA0u3u7Ye7llzcV:22
X-Proofpoint-ORIG-GUID: zBUfd1HXRecJUv2-Z1X61XkQu1pJYLhf
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE4MDE0NyBTYWx0ZWRfX1I98SVwN3ev/
 tbMnqlhj3D4yIY1oibI56LFhLQOLZOikyJBMolJNLucrJ9021nqE0ThNerrNiiUyWOEITApi1hM
 A5ekcYp4nk8PaOn/V9t814omOg5anjdi4FRxcvCUdO2Tvg9mlMuhol9T1UFqxOcazLAI0TvJKkN
 8a5VM6iok5xZPbhc4xDxLyZTKv7t7L5e29uwtBGATP6XDr1D+zpfqRJrUdOpNTZp4livvnxEeAI
 aOxpC9Q1Mq8FkI76EEYLGryPz0PqIMQXiGsrzJ6/p1ymvuz+PvlV0QGKiu5cu49bC0EmVudyR9J
 eNqCgyxrdWnXCVsWnezjOlROqLGtasaFQrWZrvnbJHUr4uC9IC2qesGcdd25VJYJ/2JQaLL22kz
 QvOhV27YrdPTt6WzrZhCTsNfUyOjq4tXiyRaSohfCH/U71H2oEEMmw85D+o1eV5Dt7rE4RJaW/2
 /KfLuV9nTRBGzWzPOrw==
X-Proofpoint-GUID: zBUfd1HXRecJUv2-Z1X61XkQu1pJYLhf
X-Proofpoint-Spam-Info: AW1haW4tMjYwODE4MDE0NyBTYWx0ZWRfX11meS7G0gRjW
 bEKF+nbWsQo1sF2l++I7oBYSVSv4jCmqN95lIaoPDyYFarCCXV7CGnxP2oHWPPcyOhR7ojuouyM
 HRTRE0Y0Ynqr0W1CNaiR1wXg29bWp5YivA5SLvud/w3cjRTFaxnV
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-18_04,2026-08-18_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 impostorscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015
 priorityscore=1501 spamscore=0 bulkscore=0 phishscore=0 malwarescore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608180147
X-purgate-ID: tlsNG-bad1c0/1787083665-3A4DB034-07E69C09/0/0
X-purgate-type: clean
X-purgate-size: 704

On Tue, Aug 18, 2026 at 10:49:33AM +0200, Jan Beulich wrote:
> On 14.08.2026 03:02, dmukhin@ford.com wrote:
> > Mini-series to add new keyhander '?' for showing system information,
> > including command line and version info.
> > 
> > v5: https://lore.kernel.org/xen-devel/20260813035139.915536-2-dmukhin@ford.com/
> > CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2758940285
> > 
> > Denis Mukhin (2):
> >   xen/common: add keyhandler to show Xen command line
> >   xen/common: move version printout under '?' keyhandler
> 
> I would have wished them to be the other way around (as was requested), but well:
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Thank you.


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 21:40:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 21:40:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394442.1633215 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwRXc-0004H1-UI; Tue, 18 Aug 2026 21:40:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394442.1633215; Tue, 18 Aug 2026 21:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwRXc-0004Gu-Rg; Tue, 18 Aug 2026 21:40:16 +0000
Received: by outflank-mailman (input) for mailman id 1394442;
 Tue, 18 Aug 2026 21:40:15 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bUIi=GL=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wwRXb-0004Go-PG
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 21:40:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwRXa-00CmFp-Bb
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 23:40:14 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=bUIi=GL=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a84d10a-8faa-0a2a0a5109dd-0a2a4506bc92-28
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:40:14 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=bUIi=GL=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a84d13d-195a-0a2a45060019-8c4da68aae9a-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:40:14 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id 8D620A1B8D;
 Tue, 18 Aug 2026 23:40:13 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zVpbww5Fr_Lg; Tue, 18 Aug 2026 23:40:13 +0200 (CEST)
Received: from end (154.106.204.77.rev.sfr.net [77.204.106.154])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 53C16A1AB6;
 Tue, 18 Aug 2026 23:40:13 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wwRXY-0000000EOsT-2RNV; Tue, 18 Aug 2026 23:40:12 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1787089213; bh=HQMWrRs5H+9ct9exSbTeLZP+vaq/xaCZ84D6cWM6/7w=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=CgkcT6xcRS3bRnmei4C4L8RUb6kwB2dOcLVhHanG4huRrOHc4RwSQYPuOP0ctvHNa
	 ADVjWIYlQ+Vx08/+NrplLMH0HNN0rEqVToavyZWJxQIpq5uxu+qWNsmM9KUatmF63b
	 4YdPllNGI9p7HVIYpZfn2+QoNeBqs0M/g2D3XKiY1nXzqwcGD8qA2zMSUM43eXm369
	 JvILzIdGVYlQbQkdJy498oERMFkstxkZJhPhSPF93PuqDhTFsrr8k/RPYrmpKfexmc
	 6/yc5TtN0uAeuvv23w5aDxm/DykfHuiRRMH1KZ3YK0AtSOnh0N2KUj8OwoXX0H+73V
	 vwlun3JCDYCWQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1787089213; bh=HQMWrRs5H+9ct9exSbTeLZP+vaq/xaCZ84D6cWM6/7w=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=CgkcT6xcRS3bRnmei4C4L8RUb6kwB2dOcLVhHanG4huRrOHc4RwSQYPuOP0ctvHNa
	 ADVjWIYlQ+Vx08/+NrplLMH0HNN0rEqVToavyZWJxQIpq5uxu+qWNsmM9KUatmF63b
	 4YdPllNGI9p7HVIYpZfn2+QoNeBqs0M/g2D3XKiY1nXzqwcGD8qA2zMSUM43eXm369
	 JvILzIdGVYlQbQkdJy498oERMFkstxkZJhPhSPF93PuqDhTFsrr8k/RPYrmpKfexmc
	 6/yc5TtN0uAeuvv23w5aDxm/DykfHuiRRMH1KZ3YK0AtSOnh0N2KUj8OwoXX0H+73V
	 vwlun3JCDYCWQ==
Date: Tue, 18 Aug 2026 23:40:12 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
Message-ID: <aoTRPKeD6__D7Qra@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Jan Beulich <jbeulich@suse.com>, Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	xen-devel@lists.xenproject.org
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com>
 <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
 <aoM4ufGg8QO51XB9@end>
 <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-16d1c6/1787089214-FDA0C77B-7AAADA4E/0/0
X-purgate-type: clean
X-purgate-size: 1540

Jan Beulich, le mar. 18 août 2026 08:03:51 +0200, a ecrit:
> On 17.08.2026 18:37, Samuel Thibault wrote:
> > Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
> >> On 17.08.26 09:48, Samuel Thibault wrote:
> >>> Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
> >>>> There is no user of libpci left in stubdoms.
> >>>>
> >>>> Remove libpci from the stubdom build system.
> >>>
> >>> Wouldn't it be useful to keep this for anybody who would want to drive a
> >>> PCI card from a stubdomain?
> >>>
> >>> I mean, in the zlib case, it's really a mere question of build & link,
> >>> so we don't need to ship it, people can do it themselves easily like for
> >>> any other library.
> >>>
> >>> But here there is actual porting work, that we'd better not lose but
> >>> keep shipping.
> >>
> >> This is all still available via git.
> > 
> > No, it is not really.
> 
> Question is - does this matter in the first place? If someone wanted to
> drive e.g. a USB device, would we include USB code?

Why not? I mean, better centralize the maintenance of such code instead
of possibly several people having to maintain their own USB layer each.

> I'm with Jürgen that we should have in the upstream tree only what is
> also used in-tree.

But then there's probably quite a few things that could be dropped
from mini-os because the mini-os and xen trees don't use them, e.g.
the fbfront. But is that really a service to make to people using this
infrastructure, or planning to?

Samuel


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 21:42:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 21:42:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394448.1633224 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwRZv-0004ka-9V; Tue, 18 Aug 2026 21:42:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394448.1633224; Tue, 18 Aug 2026 21:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwRZv-0004kT-6Y; Tue, 18 Aug 2026 21:42:39 +0000
Received: by outflank-mailman (input) for mailman id 1394448;
 Tue, 18 Aug 2026 21:42:38 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=bUIi=GL=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wwRZt-0004kN-Vs
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 21:42:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwRZs-00EUQs-R4
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 23:42:36 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=bUIi=GL=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a84d1b9-8faa-0a2a0a5109dd-0a2a45038056-22
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:42:36 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=bUIi=GL=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a84d1cc-fae8-0a2a45030019-8c4da68ae8c6-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:42:36 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id 128B1A200A;
 Tue, 18 Aug 2026 23:42:36 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id dyoXCDi8SP28; Tue, 18 Aug 2026 23:42:35 +0200 (CEST)
Received: from end (154.106.204.77.rev.sfr.net [77.204.106.154])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id D3D35A1BDD;
 Tue, 18 Aug 2026 23:42:35 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wwRZr-0000000EP4U-0c6w; Tue, 18 Aug 2026 23:42:35 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1787089356; bh=u0wtUDEHncuW6Fp1nGWZCWv2wCiM+0+Jb/QHUqajQ0U=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=RhDDzPMhBapBj9DChIF6WfWgYTrqDXqaXROCuv7CIz2/aqjh4aq/rJ5mSSPOn9NxI
	 6WkIu+NlxIYqW1zX7U9v/FfP1NsYoSaMkw7qEYrLof2KPbNxWvPPMmezVKxdfgsTRM
	 n2vivBGih3K0nE/NnxYCM9lQLT7A0fhWsI0oNrhoBmfL7KZjQhnia7guAc00cEZ7Jv
	 1+MkYkxPwPznFaLsPyNRa/dHeZOlImf01k+OkS/qOhoySC4r/j+plhS3OkoZDoub4Z
	 bLZA9b7rFlZsx6ANTjyf6zl7BLaNy1/JsKZQXb2gL1Uo9Pt8M8b/miPDfYZLZoMicT
	 UhDLKlOD9VQ4Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1787089355; bh=u0wtUDEHncuW6Fp1nGWZCWv2wCiM+0+Jb/QHUqajQ0U=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=BW89mVgO6/5z3w4dHv9QMWzk5es0v2YHwWXjQ21DYp+cEUnKlJd560NOokuOEeYj2
	 CkyTQQPdjSOHiMr2K/R/Y/IRsNkGozOx7ZRdmv4gwH4uKdDC6DglM7CbArNnxk5eWj
	 jIwz+MxQOG4wPpUKiTaDBeth+1ZDWR4rsnF7PrPk6BBDgE3TCv1knNA+rfeZmdi5Zr
	 0qvDdf/DvGLR752E25Hncjv6gOZBiSlkQCB0ksXv0yDszxNGVQqFYuQFukYaCrxpbv
	 CI+Fg9ydzQxKy+wD5Fj6NcIBwU6wvNMDdAtq5G/UNx2xQd1sZXsMPZQQNplKTEgFyn
	 Zk9ugf8tdbCAQ==
Date: Tue, 18 Aug 2026 23:42:35 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
Message-ID: <aoTRyxN4gzsEwJa5@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
	xen-devel@lists.xenproject.org,
	Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com>
 <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
 <aoM4ufGg8QO51XB9@end>
 <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-33051d/1787089356-6CADC4E9-77A26F84/0/0
X-purgate-type: clean
X-purgate-size: 1652

Jürgen Groß, le mar. 18 août 2026 07:43:34 +0200, a ecrit:
> On 17.08.26 18:37, Samuel Thibault wrote:
> > Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
> > > On 17.08.26 09:48, Samuel Thibault wrote:
> > > > Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
> > > > > There is no user of libpci left in stubdoms.
> > > > > 
> > > > > Remove libpci from the stubdom build system.
> > > > 
> > > > Wouldn't it be useful to keep this for anybody who would want to drive a
> > > > PCI card from a stubdomain?
> > > > 
> > > > I mean, in the zlib case, it's really a mere question of build & link,
> > > > so we don't need to ship it, people can do it themselves easily like for
> > > > any other library.
> > > > 
> > > > But here there is actual porting work, that we'd better not lose but
> > > > keep shipping.
> > > 
> > > This is all still available via git.
> > 
> > No, it is not really.
> > 
> > I keep reading this argument, but people will not know that something
> > exists in the git history, and will just assume that it does not exist
> > and has to be written.
> 
> What about adding a comment to the stubdom Makefile in a separate patch, like:
> 
> # pciutils support has been removed with commit <commit-id>, revert that patch
> # in case it is needed again.
> 
> I think this would be preferable over unused and probably bit-rotten code in
> the repository.

I don't see why it would be bit-rotten, since the pciutils version in
used is fixed, it's a library that has a quite stable API, and the pci
xen interface is supposed to keep backward compatibility.

Samuel


From xen-devel-bounces@lists.xenproject.org Tue Aug 18 21:47:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Aug 2026 21:47:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394460.1633234 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwRen-0005Sv-U5; Tue, 18 Aug 2026 21:47:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394460.1633234; Tue, 18 Aug 2026 21:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwRen-0005Sn-R3; Tue, 18 Aug 2026 21:47:41 +0000
Received: by outflank-mailman (input) for mailman id 1394460;
 Tue, 18 Aug 2026 21:47:40 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <arthurborsboom@gmail.com>) id 1wwRem-0005RY-5y
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 21:47:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwRel-003bl7-FG
 for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 23:47:39 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <arthurborsboom@gmail.com>)
 id 6a84d28d-e002-0a2a0a5209dd-0a2a450290c4-46
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:47:39 +0200
Received: from [209.85.167.178] (helo=mail-oi1-f178.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <arthurborsboom@gmail.com>)
 id 6a84d2fa-6ca4-0a2a45020019-d155a7b2a8db-3
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:47:39 +0200
Received: by mail-oi1-f178.google.com with SMTP id
 5614622812f47-49ff971e903so896924b6e.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 14:47:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:To:Subject:Message-ID:Date:From:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787089657; cv=none;
        d=google.com; s=arc-20260327;
        b=MsZkQcklDtmheRjZ6sozKBp4vJmP9VTsfmaUr2yn2Y15ryb4lPlgr8ozOzYBK7PI/u
         S2o+xEmm4b/jSUfHJliTMwRUyEyQXFpOlw3k/pWWA6dvJO72pQ02jTI6NZyd+Cmy2Dyp
         lA6EQM09bzG7adGRkXn46w1zIjxX73EUR9RwY49bJcYWlysJMT4s2Svb28xcAsLCWj/K
         +WCnCsc5qhnM85FzXHBwPDH/aA1p15suZDdYFzAe+f7cFxKXwnneOQmbfBT0278aBhGp
         4T4IRiU9KZssDwhsCTbwuh3jQg1rLUc2gpG7NRS0H7/87q9ogTiWnOxE4NQ0tSEtVGCW
         rtng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=to:subject:message-id:date:from:mime-version:dkim-signature;
        bh=0X4eDJAyojIwKxxqMFxjK9Kx58HBryRY5coJ4HF4cvU=;
        fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=;
        b=id4YwvFJQ2QMxtBnOwiAI9dPeo1/kL4rZfq9ITvQf+g+UsBKv3Ku304yaYEykUxyBc
         BB/t3kaAD5z+VatqpVcjqhZLytl8ut/xNk+Pz1qwgGduGg8RgTCkcfUqN4iB5qNjr08n
         MOcy+IwOSQKBX9IjWvdos+3AnxwfjSZKCTykZy94hx04hW3T+r4or94U8Mtn9qyXoHrq
         kis1NcWFgu29ZOEJLNzlYBGb+6bVOopxPidDTnEznanH5c6kkh6eujAQioXI4KjlZ96h
         wGv+Fay8AuqzJBnyROhyq3Q/dJnJxQqC7ehOCDkZznwmizwF2t2jz8hKTS4lTS6Kr+hj
         UO4g==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787089657; x=1787694457; darn=lists.xenproject.org;
        h=content-type:to:subject:message-id:date:from:mime-version:from:to
         :cc:subject:date:message-id:reply-to:content-type;
        bh=0X4eDJAyojIwKxxqMFxjK9Kx58HBryRY5coJ4HF4cvU=;
        b=Tj+T/xa9RHd5DBgebsSQY5S1SzahHrdWpQS31uLdnIP+LSoDTpjvPgorUswcVmDeMH
         ml9crzIt+kJcv/TQNG/b7z6MMhwzVBzTEIXquKcMbpYaQ9gXefaH1JtE6CLbHM3LNddP
         Ndy+d5g2apxb1OTjl9jEICibcng77VQ/CYR6PIOcf45FFzfBjnA0LzmujR8KXSQ33uT+
         2j/MKi2smtZxEzKfrviozJbs3aaD5pcqyC+xCHSt8Gvsmg7jrZQywkaqqRBsrIqlVc0l
         Odt3BIqERCUJy9DQwK8c2mPwXOfVqXL5JZI2NXf+zesLSmsY2Gc8ttKmtTn9/HTf2RU1
         9mew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787089657; x=1787694457;
        h=content-type:to:subject:message-id:date:from:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0X4eDJAyojIwKxxqMFxjK9Kx58HBryRY5coJ4HF4cvU=;
        b=jmh06196zm0V0RpWURwlt5AO9+7VvXrmGv9pmq8TdrksTFKuxeHSW/vWYsMuygRXzu
         LKPoeeL35+Tm7hiqtreeJcqOkIFW7GwKg7ks89LHDq8/VBJ2j8v5Zeoa+VZCcxKnm1lD
         1ImUSduOagmVcJ68s8BEgpzavBKVl7fGkMqwSYrZlUgckO9AIDVpcmfJPWBF5sVFYP7d
         gyc48r36R8suwnEKBXHpoQYE9fKYNnNWgxW7g6MTbeYsbx+BNLljJ1HvrpO+u6xND9Dh
         ceLwGjh35zG5tmr1incxrP4ZXx2we+eaNTvnNoKnIB+tTenOQI4BvYTmRxslsPstrNmi
         o2Ww==
X-Gm-Message-State: AOJu0YybUY0godc3E4pZZ1lwcoA0WurksbGSHACyDCXKiG/q+piKZEB1
	65G4mMDq6RXxdvg2mVW6LOigggTfg1crrmIQ02i/i90MdxAxF0eW3ZAJ/OFdwOFTXUO0CCI6xFA
	7RsDliHjVg2TMowV/K0eVjoj3oQf5AMDzcJpUbwkN+Q==
X-Gm-Gg: AR+sD10TZw5aEPCq2rLJRTnD/vVYgny64Vnc+y8JppvPitcOcGEbx8gfC7MxXT0lZG3
	BLQqhziUaAihIsdbxhlz7mil7rsWmTMG1cDIo9uQP9sKDRXnvQF+DRPNdqwSyQA32lh37L+/r6L
	bttg28Z2DNvZ9aEx8Bq/V/jcRvWyVN+216gqLgO3AOK4chnY0FRkAh6gkjCWSVFx+EAU7PaiRfj
	AaJaapVV05z2BqnRBunYBXiuFab6vHxkYyCs7QWtAhwV1Bp4dA1+TtJjRvilGUuC0P60uzJ17wf
	69hVmBWf22yb1t/EZ8F8qxc+sAuIzJeBTGU5GKrA6v+62gSOtPsVkZZE61kJllHLdqgzFmAt05B
	gxY+rPdthMlcVsr2RU6FJMLZJZW8X357RN2y9x7ZP2YUXypaS/XdY4FE59EfHpRrIh+spTn9IyJ
	u2cvrtof1cH6Q=
X-Received: by 2002:a05:6808:6a96:b0:495:f697:92d9 with SMTP id
 5614622812f47-4b2ba69b458mr353897b6e.7.1787089657187; Tue, 18 Aug 2026
 14:47:37 -0700 (PDT)
MIME-Version: 1.0
From: Arthur Borsboom <arthurborsboom@gmail.com>
Date: Tue, 18 Aug 2026 23:47:21 +0200
X-Gm-Features: AcwNN1W25mPAMXOatQ1ufel3zTPBjo3cD8NZLrVp_pez46BbBOcsp5vpNmi59m4
Message-ID: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
Subject: [BUG] Linux kernel crash in amd_smn_init during PVH Dom0 boot on AMD EPYC
To: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-720697/1787089659-315CD2AC-E12F8AA1/0/0
X-purgate-type: clean
X-purgate-size: 24239

Hi,

I am encountering an early Linux kernel crash when booting a PVH
Dom0 on an AMD EPYC system (Family 19h Model 97). PV boot on the
same system works fine. The crash occurs during amd_smn_init due
to a divide-by-zero exception.

There is a potentially related bug report discussing a Linux patch
addressing AMD SMN initialization under Xen PVH:

https://patchew.org/linux/20260623211904.3674-1-jason.andryuk@amd.com/

It seems there was an ongoing discussion between Linux devs who
seem to have the need to align with Xen devs for a proper/future-proof fix.
I am submitting this report to share raw hardware trace data and
help move this forward.

--- System Details ---
CPU: AMD EPYC 4344P 8-Core Processor (Family 25 / 0x19, Model 97
/ 0x61, Stepping 2)
Motherboard: MSI MSIS366/S3661 (BIOS ES366AOC.10P 05/29/2025)
Xen Version: 4.20.0 (Command line: dom0_mem=8192M,max:8192M dom0=pvh
loglvl=all guest_loglvl=all sync_console noreboot console=com1,vga)
Linux Kernel: 7.1.5-arch1-2

--- Kernel Crash Log ---

 __  __            _  _    ____   ___   ___                    _
 \ \/ /___ _ __   | || |  |___ \ / _ \ / _ \     __ _ _ __ ___| |__
  \  // _ \ '_ \  | || |_   __) | | | | | | |__ / _` | '__/ __| '_ \
  /  \  __/ | | | |__   _| / __/| |_| | |_| |__| (_| | | | (__| | | |
 /_/\_\___|_| |_|    |_|(_)_____|\___(_)___/    \__,_|_|  \___|_| |_|

(XEN) Xen version 4.20.0-arch (arthur@aramgroup.com) (gcc (GCC) 16.1.1
20260725) debug=n Sun Jul 26 22:43:05 UTC 2026
(XEN) Latest ChangeSet: Tue Mar 4 16:17:52 2025 +0000 git:3ad5d648cd-dirty
(XEN) build-id: 4dcf7c0d0f3d960d48942e07d1681a98
(XEN) Console output is synchronous.
(XEN) CPU Vendor: AMD, Family 25 (0x19), Model 97 (0x61), Stepping 2
(raw 00a60f12)
(XEN) BSP microcode revision: 0x0a60120c
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=8192M,max:8192M dom0=pvh loglvl=all
guest_loglvl=all sync_console noreboot console=com1,vga
(XEN) Xen image load base address: 0x7e000000
(XEN) Video information:
(XEN)  VGA is graphics mode 1024x768, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Enabling Supervisor Shadow Stacks
(XEN) EFI RAM map:
(XEN)  [0000000000000000, 000000000009ffff] (usable)
(XEN)  [00000000000a0000, 00000000000fffff] (reserved)
(XEN)  [0000000000100000, 0000000009afefff] (usable)
(XEN)  [0000000009aff000, 0000000009ffffff] (reserved)
(XEN)  [000000000a000000, 000000000a1fffff] (usable)
(XEN)  [000000000a200000, 000000000a211fff] (ACPI NVS)
(XEN)  [000000000a212000, 000000000affffff] (usable)
(XEN)  [000000000b000000, 000000000b020fff] (reserved)
(XEN)  [000000000b021000, 000000008857efff] (usable)
(XEN)  [000000008857f000, 000000008e57efff] (reserved)
(XEN)  [000000008e57f000, 000000008e67efff] (ACPI data)
(XEN)  [000000008e67f000, 000000009067efff] (ACPI NVS)
(XEN)  [000000009067f000, 00000000987fefff] (reserved)
(XEN)  [00000000987ff000, 0000000099ff7fff] (usable)
(XEN)  [0000000099ff8000, 0000000099ffafff] (reserved)
(XEN)  [0000000099ffb000, 0000000099ffcfff] (usable)
(XEN)  [0000000099ffd000, 0000000099ffdfff] (reserved)
(XEN)  [0000000099ffe000, 0000000099ffffff] (usable)
(XEN)  [000000009a000000, 000000009bffffff] (reserved)
(XEN)  [000000009d7f3000, 000000009fffffff] (reserved)
(XEN)  [00000000e0000000, 00000000efffffff] (reserved)
(XEN)  [00000000f7000000, 00000000ffffffff] (reserved)
(XEN)  [0000000100000000, 000000105defffff] (usable)
(XEN)  [000000105ef40000, 00000010801fffff] (reserved)
(XEN)  [000000fd00000000, 000000ffffffffff] (reserved)
(XEN) ACPI: RSDP 90665014, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT 90664728, 00EC (r1 ALASKA   A M I   1072009 AMI   1000013)
(XEN) ACPI: FACP 8E672000, 0114 (r6 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: DSDT 8E5F5000, 733C1 (r171 ALASKA   A M I   1072009 INTL 20230628)
(XEN) ACPI: FACS 90662000, 0040
(XEN) ACPI: SSDT 8E676000, 816C (r2    AMD Splinter        2 MSFT  5000000)
(XEN) ACPI: SPMI 8E675000, 0041 (r5 ALASKA   A M I         0 AMI.        0)
(XEN) ACPI: SPMI 8E674000, 0041 (r5 ALASKA   A M I         0 AMI.        0)
(XEN) ACPI: SSDT 8E673000, 0221 (r2 ALASKA  CPUSSDT  1072009 AMI   1072009)
(XEN) ACPI: FIDT 8E66C000, 009C (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: MCFG 8E66B000, 003C (r1 ALASKA    A M I  1072009 MSFT    10013)
(XEN) ACPI: HPET 8E66A000, 0038 (r1 ALASKA    A M I  1072009 AMI         5)
(XEN) ACPI: UEFI 9001F000, 0048 (r1 ALASKA   A M I   1072009 AMI   1000013)
(XEN) ACPI: FPDT 8E669000, 0044 (r1 ALASKA   A M I   1072009 AMI   1000013)
(XEN) ACPI: SSDT 8E66D000, 4DEE (r2    AMD  AMD CPU        1 AMD         1)
(XEN) ACPI: TPM2 8E5F4000, 004C (r4 ALASKA   A M I         1 AMI         0)
(XEN) ACPI: SSDT 8E5F3000, 06D4 (r2    AMD  CPMWLRC        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5F2000, 0788 (r2    AMD CPMDFIG5        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5E8000, 9A9E (r2    AMD   CPMCMN        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5E5000, 27C6 (r2    AMD AOD             1 INTL 20230628)
(XEN) ACPI: WSMT 8E5E4000, 0028 (r1 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: APIC 8E5E3000, 015E (r6 ALASKA   A M I   1072009 AMI     10013)
(XEN) ACPI: IVRS 8E5E2000, 00C8 (r2  AMD   AmdTable        1 AMD         1)
(XEN) ACPI: SSDT 8E5E1000, 0500 (r2    AMD MEMTOOL0        2 INTL 20230628)
(XEN) ACPI: SSDT 8E5E0000, 09D0 (r2    AMD CPMMSOSC        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5DF000, 047C (r2    AMD   AMDWOV        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5DE000, 008D (r2    AMD CPMMSLPI        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5DC000, 1046 (r2    AMD CPMACPV4        1 INTL 20230628)
(XEN) ACPI: SSDT 8E5DB000, 044D (r2    AMD AmdTable        1 INTL 20230628)
(XEN) System RAM: 65142MB (66706336kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000105df00000
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0x00000000f5000000, mapped to
0xffff82c000203000, using 3072k, total 3072k
(XEN) vesafb: mode is 1024x768x32, linelength=4096, font 8x14
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
(XEN) SMBIOS 3.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT -
90662000/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[9066200c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x20] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 32, version 33, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x21] address[0xfec01000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 33, version 33, address 0xfec01000, GSI 24-55
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) ACPI: HPET id: 0x10228201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 16 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 56 GSI, 3272 MSI/MSI-X
(XEN) CPU0: 3000 ... 3800 MHz
(XEN) xstate: size: 0x988 and states: 0x2e7
(XEN) CPU0: AMD Fam19h machine check reporting enabled
(XEN) Speculative mitigation facilities:
(XEN)   Hardware hints: STIBP_ALWAYS IBRS_FAST IBRS_SAME_MODE BTC_NO IBPB_RET
(XEN)   Hardware features: IBPB IBRS STIBP SSBD PSFD L1D_FLUSH
(XEN)   Compiled-in support: INDIRECT_THUNK SHADOW_PAGING HARDEN_ARRAY
HARDEN_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK
(XEN)   Xen settings: BTI-Thunk: JMP, SPEC_CTRL: IBRS+ STIBP+ SSBD-
PSFD-, Other: BRANCH_HARDEN
(XEN)   Support for HVM VMs: MSR_SPEC_CTRL MSR_VIRT_SPEC_CTRL RSB IBPB-entry
(XEN)   Support for PV VMs: IBPB-entry
(XEN)   XPTI (64-bit PV only): Dom0 disabled, DomU disabled (without PCID)
(XEN)   PV L1TF shadowing: Dom0 disabled, DomU disabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Platform timer is 14.318MHz HPET
(XEN) Detected 3792.858 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-000000009cfff type=7 attr=000000000000000f
(XEN)  000000009d000-000000009efff type=2 attr=000000000000000f
(XEN)  000000009f000-000000009ffff type=4 attr=000000000000000f
(XEN)  0000000100000-0000009afefff type=7 attr=000000000000000f
(XEN)  0000009aff000-0000009ffffff type=0 attr=000000000000000f
(XEN)  000000a000000-000000a1fffff type=7 attr=000000000000000f
(XEN)  000000a200000-000000a211fff type=10 attr=000000000000000f
(XEN)  000000a212000-000000a291fff type=4 attr=000000000000000f
(XEN)  000000a292000-000000affffff type=7 attr=000000000000000f
(XEN)  000000b000000-000000b020fff type=0 attr=000000000000000f
(XEN)  000000b021000-000007d184fff type=7 attr=000000000000000f
(XEN)  000007d185000-000007dffffff type=2 attr=000000000000000f
(XEN)  000007e000000-000007fdfffff type=1 attr=000000000000000f
(XEN)  000007fe00000-0000080662fff type=7 attr=000000000000000f
(XEN)  0000080663000-00000816affff type=2 attr=000000000000000f
(XEN)  00000816b0000-00000816b0fff type=4 attr=000000000000000f
(XEN)  00000816b1000-00000816befff type=7 attr=000000000000000f
(XEN)  00000816bf000-00000816bffff type=4 attr=000000000000000f
(XEN)  00000816c0000-00000816e8fff type=7 attr=000000000000000f
(XEN)  00000816e9000-00000816ecfff type=4 attr=000000000000000f
(XEN)  00000816ed000-00000816f5fff type=7 attr=000000000000000f
(XEN)  00000816f6000-00000816f6fff type=4 attr=000000000000000f
(XEN)  00000816f7000-00000816f8fff type=7 attr=000000000000000f
(XEN)  00000816f9000-00000816fafff type=4 attr=000000000000000f
(XEN)  00000816fb000-0000081700fff type=7 attr=000000000000000f
(XEN)  0000081701000-0000081701fff type=4 attr=000000000000000f
(XEN)  0000081702000-0000081703fff type=7 attr=000000000000000f
(XEN)  0000081704000-0000081705fff type=4 attr=000000000000000f
(XEN)  0000081706000-0000081723fff type=7 attr=000000000000000f
(XEN)  0000081724000-0000081724fff type=4 attr=000000000000000f
(XEN)  0000081725000-0000081739fff type=7 attr=000000000000000f
(XEN)  000008173a000-000008173afff type=4 attr=000000000000000f
(XEN)  000008173b000-0000081829fff type=7 attr=000000000000000f
(XEN)  000008182a000-0000081874fff type=2 attr=000000000000000f
(XEN)  0000081875000-0000081875fff type=4 attr=000000000000000f
(XEN)  0000081876000-00000818b6fff type=7 attr=000000000000000f
(XEN)  00000818b7000-00000818cafff type=4 attr=000000000000000f
(XEN)  00000818cb000-00000818f3fff type=7 attr=000000000000000f
(XEN)  00000818f4000-00000818fafff type=4 attr=000000000000000f
(XEN)  00000818fb000-00000818fbfff type=7 attr=000000000000000f
(XEN)  00000818fc000-00000818fcfff type=4 attr=000000000000000f
(XEN)  00000818fd000-0000081901fff type=7 attr=000000000000000f
(XEN)  0000081902000-0000081903fff type=4 attr=000000000000000f
(XEN)  0000081904000-0000081905fff type=7 attr=000000000000000f
(XEN)  0000081906000-0000081907fff type=4 attr=000000000000000f
(XEN)  0000081908000-0000081908fff type=7 attr=000000000000000f
(XEN)  0000081909000-0000081917fff type=4 attr=000000000000000f
(XEN)  0000081918000-0000081918fff type=7 attr=000000000000000f
(XEN)  0000081919000-000008191efff type=4 attr=000000000000000f
(XEN)  000008191f000-000008191ffff type=7 attr=000000000000000f
(XEN)  0000081920000-0000081921fff type=4 attr=000000000000000f
(XEN)  0000081922000-0000081922fff type=7 attr=000000000000000f
(XEN)  0000081923000-0000081b8dfff type=4 attr=000000000000000f
(XEN)  0000081b8e000-0000081b8efff type=2 attr=000000000000000f
(XEN)  0000081b8f000-0000082e0dfff type=4 attr=000000000000000f
(XEN)  0000082e0e000-0000082e0efff type=7 attr=000000000000000f
(XEN)  0000082e0f000-000008657efff type=4 attr=000000000000000f
(XEN)  000008657f000-0000087751fff type=7 attr=000000000000000f
(XEN)  0000087752000-000008857efff type=3 attr=000000000000000f
(XEN)  000008857f000-000008e57efff type=0 attr=000000000000000f
(XEN)  000008e57f000-000008e67efff type=9 attr=000000000000000f
(XEN)  000008e67f000-000009067efff type=10 attr=000000000000000f
(XEN)  000009067f000-000009867efff type=6 attr=800000000000000f
(XEN)  000009867f000-00000987fefff type=5 attr=800000000000000f
(XEN)  00000987ff000-0000098dfffff type=4 attr=000000000000000f
(XEN)  0000098e00000-0000098ee5fff type=7 attr=000000000000000f
(XEN)  0000098ee6000-0000098fe5fff type=4 attr=000000000000000f
(XEN)  0000098fe6000-000009900dfff type=3 attr=000000000000000f
(XEN)  000009900e000-0000099043fff type=4 attr=000000000000000f
(XEN)  0000099044000-0000099078fff type=3 attr=000000000000000f
(XEN)  0000099079000-0000099091fff type=4 attr=000000000000000f
(XEN)  0000099092000-00000990aafff type=3 attr=000000000000000f
(XEN)  00000990ab000-0000099e7afff type=4 attr=000000000000000f
(XEN)  0000099e7b000-0000099e7efff type=3 attr=000000000000000f
(XEN)  0000099e7f000-0000099e92fff type=4 attr=000000000000000f
(XEN)  0000099e93000-0000099e94fff type=3 attr=000000000000000f
(XEN)  0000099e95000-0000099ea5fff type=4 attr=000000000000000f
(XEN)  0000099ea6000-0000099ec6fff type=3 attr=000000000000000f
(XEN)  0000099ec7000-0000099ec8fff type=4 attr=000000000000000f
(XEN)  0000099ec9000-0000099ec9fff type=7 attr=000000000000000f
(XEN)  0000099eca000-0000099edbfff type=4 attr=000000000000000f
(XEN)  0000099edc000-0000099edcfff type=7 attr=000000000000000f
(XEN)  0000099edd000-0000099eddfff type=3 attr=000000000000000f
(XEN)  0000099ede000-0000099feffff type=4 attr=000000000000000f
(XEN)  0000099ff0000-0000099ff7fff type=3 attr=000000000000000f
(XEN)  0000099ff8000-0000099ffafff type=6 attr=800000000000000f
(XEN)  0000099ffb000-0000099ffcfff type=4 attr=000000000000000f
(XEN)  0000099ffd000-0000099ffdfff type=6 attr=800000000000000f
(XEN)  0000099ffe000-0000099ffffff type=4 attr=000000000000000f
(XEN)  0000100000000-00001012fffff type=7 attr=000000000000000f
(XEN)  0000101300000-0000101324fff type=1 attr=000000000000000f
(XEN)  0000101325000-000105defffff type=7 attr=000000000000000f
(XEN)  00000000a0000-00000000fffff type=0 attr=000000000000000f
(XEN)  000009a000000-000009bffffff type=0 attr=000000000000000f
(XEN)  000009d7f3000-000009fffffff type=0 attr=000000000000000f
(XEN)  00000e0000000-00000efffffff type=11 attr=800000000000100d
(XEN)  00000f7000000-00000fedfffff type=11 attr=800000000000100d
(XEN)  00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN)  00000fee01000-00000ffffffff type=11 attr=800000000000100d
(XEN)  000105ef40000-000105fffffff type=0 attr=000000000000000f
(XEN)  0001060000000-00010801fffff type=11 attr=800000000000100d
(XEN)  000fd00000000-000ffffffffff type=0 attr=0000000000000001
(XEN) alt table ffff82d040693398 -> ffff82d0406a455c
(XEN) AMD-Vi: IOMMU Extended Features:
(XEN) - Peripheral Page Service Request
(XEN) - NX bit
(XEN) - Guest APIC Physical Processor Interrupt
(XEN) - Invalidate All Command
(XEN) - Guest APIC
(XEN) - Performance Counters
(XEN) - Host Address Translation Size: 0x2
(XEN) - Guest Address Translation Size: 0
(XEN) - Guest CR3 Root Table Level: 0x1
(XEN) - Maximum PASID: 0xf
(XEN) - SMI Filter Register: 0x1
(XEN) - SMI Filter Register Count: 0x1
(XEN) - Guest Virtual APIC Modes: 0x1
(XEN) - Dual PPR Log: 0x2
(XEN) - Dual Event Log: 0x2
(XEN) - Secure ATS
(XEN) - User / Supervisor Page Protection
(XEN) - Device Table Segmentation: 0x3
(XEN) - PPR Log Overflow Early Warning
(XEN) - PPR Automatic Response
(XEN) - Memory Access Routing and Control: 0x1
(XEN) - Block StopMark Message
(XEN) - Performance Optimization
(XEN) - MSI Capability MMIO Access
(XEN) - Guest I/O Protection
(XEN) - Enhanced PPR Handling
(XEN) - Invalidate IOTLB Type
(XEN) - VM Table Size: 0x2
(XEN) - Guest Access Bit Update Disable
(XEN) AMD-Vi: Disabled HAP memory map sharing with IOMMU
(XEN) AMD-Vi: IOMMU 0 Enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) nr_sockets: 1
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) Enabling APIC mode.  Using 2 I/O APICs
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Wallclock source: CMOS RTC
(XEN) Allocated console ring of 128 KiB.
(XEN) mwait-idle: does not run on family 25 model 97
(XEN) HVM: ASIDs enabled.
(XEN) SVM: Supported advanced features:
(XEN)  - Nested Page Tables (NPT)
(XEN)  - Last Branch Record (LBR) Virtualisation
(XEN)  - Next-RIP Saved on #VMEXIT
(XEN)  - VMCB Clean Bits
(XEN)  - TLB flush by ASID
(XEN)  - DecodeAssists
(XEN)  - Virtual VMLOAD/VMSAVE
(XEN)  - Virtual GIF
(XEN)  - Pause-Intercept Filter
(XEN)  - Pause-Intercept Filter Threshold
(XEN)  - TSC Rate MSR
(XEN)  - NPT Supervisor Shadow Stack
(XEN)  - MSR_SPEC_CTRL virtualisation
(XEN) HVM: SVM enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) alt table ffff82d040693398 -> ffff82d0406a455c
(XEN) Brought up 16 CPUs
(XEN) Scheduling granularity: cpu, 1 CPU per sched-resource
(XEN) Initializing Credit2 scheduler
(XEN)  load_precision_shift: 18
(XEN)  load_window_shift: 30
(XEN)  underload_balance_tolerance: 0
(XEN)  overload_balance_tolerance: -3
(XEN)  runqueues arrangement: socket
(XEN)  cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN)  First cpu on runqueue, activating
(XEN) Adding cpu 1 to runqueue 0
(XEN) Adding cpu 2 to runqueue 0
(XEN) Adding cpu 3 to runqueue 0
(XEN) Adding cpu 4 to runqueue 0
(XEN) Adding cpu 5 to runqueue 0
(XEN) Adding cpu 6 to runqueue 0
(XEN) Adding cpu 7 to runqueue 0
(XEN) Adding cpu 8 to runqueue 0
(XEN) Adding cpu 9 to runqueue 0
(XEN) Adding cpu 10 to runqueue 0
(XEN) Adding cpu 11 to runqueue 0
(XEN) Adding cpu 12 to runqueue 0
(XEN) Adding cpu 13 to runqueue 0
(XEN) Adding cpu 14 to runqueue 0
(XEN) Adding cpu 15 to runqueue 0
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) NX (Execute Disable) protection active
(XEN) d0 has maximum 3328 PIRQs
(XEN) *** Building a PVH Dom0 ***
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) ***************************************************
(XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) This option is intended to aid debugging of Xen by ensuring
(XEN) that all output is synchronously delivered on the serial line.
(XEN) However it can introduce SIGNIFICANT latencies and affect
(XEN) timekeeping. It is NOT recommended for production use!
(XEN) ***************************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 2048kB init memory
(XEN) d0v0: upcall vector f3
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:00.2
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:01.1
(XEN) PCI add device 0000:00:01.3
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:02.1
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:04.0
(XEN) PCI add device 0000:00:08.0
(XEN) PCI add device 0000:00:08.1
(XEN) PCI add device 0000:00:08.3
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:18.0
(XEN) PCI add device 0000:00:18.1
(XEN) PCI add device 0000:00:18.2
(XEN) PCI add device 0000:00:18.3
(XEN) PCI add device 0000:00:18.4
(XEN) PCI add device 0000:00:18.5
(XEN) PCI add device 0000:00:18.6
(XEN) PCI add device 0000:00:18.7
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:02:00.0
(XEN) PCI add device 0000:03:00.0
(XEN) PCI add device 0000:04:02.0
(XEN) PCI add device 0000:04:03.0
(XEN) PCI add device 0000:04:08.0
(XEN) PCI add device 0000:04:0c.0
(XEN) PCI add device 0000:04:0d.0
(XEN) PCI add device 0000:05:00.0
(XEN) PCI add device 0000:06:00.0
(XEN) PCI add device 0000:07:00.0
(XEN) PCI add device 0000:08:00.0
(XEN) PCI add device 0000:08:00.1
(XEN) PCI add device 0000:0a:00.0
(XEN) PCI add device 0000:0b:00.0
(XEN) PCI add device 0000:0c:00.0
(XEN) PCI add device 0000:0c:00.2
(XEN) PCI add device 0000:0c:00.3
(XEN) PCI add device 0000:0c:00.4
(XEN) PCI add device 0000:0d:00.0
[    0.817348] Oops: divide error: 0000 [#1] SMP NOPTI
[    0.817348] fbcon: Taking over console
[    0.823766] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted
7.1.5-arch1-2 #1 PREEMPT(full)
33708094282b4038de0f4f0d201b68f6a0b5d9bf
[    0.839766] Hardware name: MSI MSIS366/S3661, BIOS ES366AOC.10P 05/29/2025
[    0.847766] RIP: 0010:amd_smn_init+0x1ed/0x280
[    0.852766] Code: d2 45 31 f6 45 31 ed 66 41 f7 f4 89 c5 48 89 df
e8 c8 c7 1b fd 48 89 c3 48 85 c0 0f 84 48 ff ff ff 44 89 e8 31 d2 45
8d 7d 01 <66> f7 f5 66 85 d2 75 42 66 90 eb 2c 41 0f b7 ce 48 8d b3 d0
00 00
[    0.870766] RSP: 0018:ffffc9000004bdc8 EFLAGS: 00010246
[    0.878766] RAX: 0000000000000000 RBX: ffff888102661000 RCX: 0000000000000007
[    0.887766] RDX: 0000000000000000 RSI: ffff888102661000 RDI: 0000000000000000
[    0.895766] RBP: 0000000000000000 R08: 0000000000000282 R09: ffff888100f57680
[    0.903766] R10: ffffea0004044580 R11: ffff888100042700 R12: 0000000000000002
[    0.911766] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
[    0.919766] FS:  0000000000000000(0000) GS:ffff8882b2010000(0000)
knlGS:0000000000000000
[    0.927766] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.935766] CR2: 0000000000000000 CR3: 0000000003822000 CR4: 0000000000750ef0
[    0.943766] PKRU: 55555554
[    0.943766] Call Trace:
[    0.948766]  <TASK>
[    0.951766]  ? __pfx_amd_smn_init+0x10/0x10
[    0.956766]  do_one_initcall+0x8e/0x3f0
[    0.959766]  kernel_init_freeable+0x24a/0x2d0
[    0.965766]  ? __pfx_kernel_init+0x10/0x10
[    0.967766]  kernel_init+0x1a/0x140
[    0.973766]  ret_from_fork+0x2a7/0x330
[    0.974766]  ? __pfx_kernel_init+0x10/0x10
[    0.982766]  ret_from_fork_asm+0x1a/0x30
[    0.988766]  </TASK>
[    0.989766] Modules linked in:
[    0.994772] ---[ end trace 0000000000000000 ]---
[    0.999769] RIP: 0010:amd_smn_init+0x1ed/0x280
[    1.004770] Code: d2 45 31 f6 45 31 ed 66 41 f7 f4 89 c5 48 89 df
e8 c8 c7 1b fd 48 89 c3 48 85 c0 0f 84 48 ff ff ff 44 89 e8 31 d2 45
8d 7d 01 <66> f7 f5 66 85 d2 75 42 66 90 eb 2c 41 0f b7 ce 48 8d b3 d0
00 00
[    1.004771] RSP: 0018:ffffc9000004bdc8 EFLAGS: 00010246
[    1.004773] RAX: 0000000000000000 RBX: ffff888102661000 RCX: 0000000000000007
[    1.004774] RDX: 0000000000000000 RSI: ffff888102661000 RDI: 0000000000000000
[    1.004775] RBP: 0000000000000000 R08: 0000000000000282 R09: ffff888100f57680
[    1.004776] R10: ffffea0004044580 R11: ffff888100042700 R12: 0000000000000002
[    1.004777] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
[    1.004778] FS:  0000000000000000(0000) GS:ffff8882b2090000(0000)
knlGS:0000000000000000
[    1.004779] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.004780] CR2: 0000000000000000 CR3: 0000000003822000 CR4: 0000000000750ef0
[    1.004782] PKRU: 55555554
[    1.004784] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
(XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting.

Please let me know if any additional info would be helpful.

Thanks,
Arthur Borsboom


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 05:16:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 05:16:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394519.1633244 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwYek-0001DN-T9; Wed, 19 Aug 2026 05:16:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394519.1633244; Wed, 19 Aug 2026 05:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwYek-0001DD-Mk; Wed, 19 Aug 2026 05:16:06 +0000
Received: by outflank-mailman (input) for mailman id 1394519;
 Wed, 19 Aug 2026 05:16:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwYej-0001D2-Eo
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 05:16:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwYei-004J9Q-6J
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:16:04 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a853c0c-8faa-0a2a0a5109dd-0a2a4503d8d8-18
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:16:04 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a853c13-fae8-0a2a45030019-d155dd33b571-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:16:04 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47f904e80eeso487232f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 22:16:04 -0700 (PDT)
Received: from notebook.. ([78.173.117.23]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14b80a5sm2827700f8f.24.2026.08.18.22.16.02
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 22:16:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787116563; x=1787721363; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=dlPnMake1WeKgYBILi+3s7wjU1+1VkocmbnS5yGfgZA=;
        b=XKM1ib60WCUDXhtApBkkTTbIzUKXrqhd5ZOz36+oCjlO6Dncoi44vu/yOT0OEdl6eC
         URvFzl0ELMwn2IOgxLxjsrNskGGnUHy0woaPePUiq4Zt7zRV5gb6jfj9dMjpyNkbSZ4X
         38mAflweF8t5OvBT7RVJy3Cy4sW2Ge6e1tJH28C13OJNtASrKMnkcsgPCzp7ZasNwko/
         BGVzERp9Jlh+w3swye6XbHduZcTPFAhJ7EIO5fOVbCt7ZdZcdulWHgexxBZ6U2iTdsR8
         S3E5b52kgoGSuLewOkRITce7fVr3onXYyhDfDm3VnXtX0o1FAy48Z9sgiGGF6MNotGfA
         D01w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787116563; x=1787721363;
        h=content-transfer-encoding:mime-version: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=dlPnMake1WeKgYBILi+3s7wjU1+1VkocmbnS5yGfgZA=;
        b=fgo5QGKxzRygKUBDXLWwAWTtclRyZLF5BBWVdcXedDV3UujtoBNQSg7cFn496cgDGi
         ZCQiTS50PfmXx3OuTm5bdRTzpwOROlxcu9zOTZk2zygzTcSe5Za8vGK39ST6cB4AfZDS
         pFqXvDZensuaYfTfhZ4pUVQo+aMjatYg7armms9ouS+GSh4HVV2tR+yEFqpXJT2cm/Jb
         eErnG2Rufl2IW9JmKhAwBTR3cstFCvKFqqPr5BuqpTmZxl8dlKuT6eBCPGKPnNC2mSPn
         Fsu9TWp3bcuwdW/KLYuWHFNLy8KSOCeZsY+wWGAKM3kxc6x/BZecyW3rqb8q6M863U6I
         J9Ng==
X-Gm-Message-State: AOJu0YzdoVVm3Xfe3wPnpDDIhQbqxjf/T+GOElIV+F6y+Q9zPMNIYt8g
	+7x337KsymT39+JtoKig3QEJy394pv4moaivlKwUCw47Ag3gulFI6A1r/vqZdg==
X-Gm-Gg: AR+sD13qRN+s2fuREjqsZwv7NPZH/3gun2Iau+qcp6t2zEHq2NjluE5JC9ro9eb9AFp
	F1Uv02hwVJkJrY8s5gAMN2tk7LfTZd0ScK3P3MEwOjkE19eSu3lAPWxSCeIOJidDOVRharTCsnR
	eDfKVA2LqaJFxIVUxdag50XfSpfBCzggHNUO7c8mP07N/u7lZqcX7ViH7MFk+TbD2Pa28PH9Dvc
	3DMm0yXQSxtUjRGkD/QLEfFRi82hOn72CUMOFknwf4ytTgPStxjLF8EbPYCcMKus+jeBrTsW4PO
	2Ccp4wHGXztk/qVzp1EOrSVqLD7XkHa7TB15ThDjWQhyhsS7dHm68fMawAht27Ri7+8fWDyx3wb
	FQTBKNrLW850HjBZkvkCD1iQRHlhx3N+Z5l2fSr+L4CgJxbtVP/gUs8jGD+TvpPcoAlG6Pcff8t
	ul96P7CJbIBLbCp+NQof+l8HVJeK8iQdUeRZ1GKNtMimRKnwUKxi/Xll4tM0sV
X-Received: by 2002:a05:6000:715:b0:481:57f7:6015 with SMTP id ffacd0b85a97d-482b1e96130mr2875074f8f.6.1787116563513;
        Tue, 18 Aug 2026 22:16:03 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v2 0/2] xen/sched: fix crashes when vcpu creation fails
Date: Wed, 19 Aug 2026 08:15:30 +0300
Message-Id: <20260819051532.9197-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787116564-764FC4E9-C80521B3/0/0
X-purgate-type: clean
X-purgate-size: 279

Furkan Caliskan (2):
  xen/sched: core: skip missing vcpu slots in sched_move_domain()
  xen/sched: core: kill unarmed timers on sched_init_vcpu() failure

 xen/common/sched/core.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 05:16:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 05:16:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394520.1633252 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwYet-0001RP-4U; Wed, 19 Aug 2026 05:16:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394520.1633252; Wed, 19 Aug 2026 05:16:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwYet-0001RH-14; Wed, 19 Aug 2026 05:16:15 +0000
Received: by outflank-mailman (input) for mailman id 1394520;
 Wed, 19 Aug 2026 05:16:13 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwYer-0001Qq-NI
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 05:16:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwYer-00H41C-4A
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:16:13 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a853c0f-bab6-0a2a0a5309dd-0a2a450ca3d0-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:16:13 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a853c1c-f479-0a2a450c0019-d155dd2cec05-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:16:12 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-476a130c138so606489f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 22:16:12 -0700 (PDT)
Received: from notebook.. ([78.173.117.23]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14b80a5sm2827700f8f.24.2026.08.18.22.16.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 22:16:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787116572; x=1787721372; 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=piSppthAjFb2KSi6feItTL2z0Ec385nKO3fFaIX3res=;
        b=DX098R+KTA1cBN5RFfFLCbOUZoM+nV1+01sjfgqtP4rKXmVLigBqY0U5E8zxd4TP1g
         lwMmVY/FGXhcqrjzR2F9ytZ5Q6zT7xGmJIpS27kXdmBJ6X4X2AizqlSdYbkYyhrBY427
         ZVC6Jc4l/dHTKt+MgZsxemEz9uIps05InNrVvTWtECtvq/civjYliJrJzAYrhAvCQVC8
         Dd+8A3eTBuKRMmLR4Shgnhk157X1RsHrhp3yCvcPWMzstJdITt9GnYiFYcYBT8a/bdjj
         BLPvJzPuoIqGUHjDhi4g0I4Z+/5oz47kK72foFaZCOKvtonLHNlHkpRs8qUXDbGvsoG4
         gVAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787116572; x=1787721372;
        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=piSppthAjFb2KSi6feItTL2z0Ec385nKO3fFaIX3res=;
        b=DbQA9m9mCLckTRiomBKcZzWwaV8QNO6kRcJ3LTGWW+xNNBjYTyv3Wc4U64Ll3xOt2k
         G5XIDAimiMeId8DEdoGLUuMaWHEUrcSFD1sRFtS1IlCLn3pm8ePSlUOAQWhztcZhtAzP
         RrDh45bASme/ZX9KLC9CdVpHPy5TCj9HRxwXbaPl25+VBkUKflaCxVjrfGpy0ZmUppJ4
         atkBo6l1lXIr9vHcjM6yp3PyWxNnrdjnZ0IRP9LpxG0kZBiZGluzkV/nh6p8Jm73/KUb
         nKSqFZnuDSkhHa0qlYfxOQQ0Knnih/ikK4rEAhovsGCzdw6nCKe42h0FBfa/a0NpPMia
         AUng==
X-Gm-Message-State: AOJu0YwN+9WZgkPfqfqEYlrc45NXqdOMYYP/PRAV9ytUaOVGu4hlKKtJ
	X6C6YRrybMXlNzMUdAodhXO9GjZTSCF681rMr0l4ba7ftv53PGIswZIMXsml8Q==
X-Gm-Gg: AR+sD13YDzbttV8aEff0g0tuIBb+WPI5qk3ZNinC8rkUhUVxR1zRdPF+3CoZ8Cj+U2p
	vrwziPhu04e6g22ZQO8iWqRyU/kkMnlVLoceXzdEDCGqNGQ3v3unNGclIj5/Pk+KRMCJogZUMnQ
	8Yjp0nMNnKyN/35zHHfmrtViox8rD3AIwP3wS7k+he7rwMAb0McGBNlTrmRi8vcTTTuRCMc2G0C
	6IDLZ8htWXB2i6g7AuKfRLv7Lxu9VGlNZPGIMAMUsNaaX2rgIrKcRJUCloqv/t4if0Y7SkZL/ot
	k6uy4QxJSQU7d0acSGxPWy2/YsAXVjW6iCK0EyrspjQLZu2+8JGMFnDkbZ3tV2ddo74VZtoRI4c
	TZJhSsNu6uacK4sLZr6PwA3hveHANnJMFL0U+yrcz+0YYpKocUp/82UWjIfRbNj0qE4KMor/Xut
	BrTyb1kHyLgVm6fvgX0rml+91uUNcLEd9yN0hfKyg/f/6RS/hYlfdPJv2bsl+o
X-Received: by 2002:a05:6000:60c:b0:47f:71a6:970e with SMTP id ffacd0b85a97d-482b1e84686mr2710317f8f.2.1787116572430;
        Tue, 18 Aug 2026 22:16:12 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in sched_move_domain()
Date: Wed, 19 Aug 2026 08:15:31 +0300
Message-Id: <20260819051532.9197-2-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260819051532.9197-1-frn1furkan10@gmail.com>
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787116572-02CDBA5B-B8771B32/0/0
X-purgate-type: clean
X-purgate-size: 3009

sched_move_domain() derives the number of units to rebuild from
d->max_vcpus, which is fixed at domain creation and never rolled
back if vcpu_create() fails partway through building a domain. So
d->vcpu[i] can be NULL for some i even though max_vcpus still
counts it - this happens if sched_alloc_udata() returns NULL.

The per-unit loop doesn't check for this: it sets
unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
unit straight to the destination scheduler's alloc_udata(),
which assumes vcpu_list is always valid and crashes Xen when
it is not.

Reproduced by building a domain in a non-default cpupool where
vcpu creation fails partway through, then destroying it.
domain_kill() moves the domain back to the default cpupool via
sched_move_domain() before actually destroying it, crashing
inside the destination scheduler's alloc_udata() (seen in
Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).

Before building a unit in sched_move_domain(), check whether all
vpcu slots belonging to that unit are populated. If any of its
vpcus is missing:
 - For a dying domain, skip the unit allocation.
 - For an active domain, abort the move and return -EINVAL to
   prevent running with dropped vCPUs.

Fixes: 70fadc41635b ("xen/cpupool: support moving domain between cpupools with different granularity")
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
v2:
 - Fail with -EINVAL if vcpu slots are missing in an active domain.
 - Added Fixes: tag.
---
 xen/common/sched/core.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d3a0a97e1d..a9daa42339 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -745,6 +745,38 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
 
     for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
     {
+        /*
+         * A vcpu slot can be missing if creation failed partway
+         * through. A dying domain is being torn down regardless, so
+         * skip the unit -- but a domain that isn't dying still needs
+         * every vcpu it has schedulable, so fail instead of silently
+         * dropping some of them.
+         */
+        bool vcpu_failed = false;
+
+        for ( unsigned int i = 0;
+              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
+        {
+            if ( !d->vcpu[unit_idx * gran + i] )
+            {
+                vcpu_failed = true;
+                break;
+            }
+        }
+
+        if ( vcpu_failed )
+        {
+            if ( !d->is_dying )
+            {
+                sched_move_domain_cleanup(c->sched, new_units, domdata);
+                rcu_read_unlock(&sched_res_rculock);
+
+                return -EINVAL;
+            }
+
+            continue;
+        }
+
         unit = sched_alloc_unit_mem();
         if ( unit )
         {
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 05:16:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 05:16:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394532.1633262 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwYfP-000241-CM; Wed, 19 Aug 2026 05:16:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394532.1633262; Wed, 19 Aug 2026 05:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwYfP-00023u-8t; Wed, 19 Aug 2026 05:16:47 +0000
Received: by outflank-mailman (input) for mailman id 1394532;
 Wed, 19 Aug 2026 05:16:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwYfN-00021z-Kg
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 05:16:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwYfN-008kHn-1n
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:16:45 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a853bff-e002-0a2a0a5209dd-0a2a45079188-32
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:16:45 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a853c3c-b4ea-0a2a45070019-d155dd2cdc0a-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:16:45 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f92e3c14bso454593f8f.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 22:16:44 -0700 (PDT)
Received: from notebook.. ([78.173.117.23]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14b80a5sm2827700f8f.24.2026.08.18.22.16.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 18 Aug 2026 22:16:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787116604; x=1787721404; 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=tvsq1Oa/wr/4Q3UAsjMQRqR3JBXbuIwTjFhPnZ06ijg=;
        b=Yy8E6bYQ66ihRmuo8dBoIvVYXlnbzu1vjWZ4tUQ5f9n44zbazWzuw/f6iHY4REgv9j
         MsyCObsXJisl0alXJ0eqWCAHAp56s/7Ga7SXuO1HOeWeehn9S5VL3e7bnof/9KkqjznK
         kM00QTHVyw9oMRJUoQ5qReVF9/KUXkGSjUkjRoaGdLtE7FTYUtiIuDOHTqcV0YYG29cY
         20FPhz9IOndF+q9aGXf2iGBiBsBse5rZQrs3VmpSpV++XwxkW3kt9a5yuXStDG22lRcA
         cQd0K1EDdNmdPziBSG6uHzf4tvv1PRRY6kkbjS37KT0ttn/A3Zu7oGgJrb/cdm0A5Xbk
         c8yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787116604; x=1787721404;
        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=tvsq1Oa/wr/4Q3UAsjMQRqR3JBXbuIwTjFhPnZ06ijg=;
        b=X6PyhaYLlDGJiOBWpSVXB9CWwBFbRz7VxofGFOu4xvzmv0mvxqEowbTG49oJsLSttJ
         HUGNLGDXNkBe05tpmopU4P19squ/y63dmi9WGCrWIF6mDdquxjIVhOQt8AR3RcCssZOQ
         cqrgsGuBzFI8woewL8UlAi2QXpdfG57o0lkZqabw4pO5N+awKF5/bo88CWezD53RxJ81
         2ogtRaYfSalt78pAkF3pSvEv2wkOLQ+rTnZ3uZ+ROUs82WeFEcadhlbzUeGy5qaSdzgh
         IFShWOVbRuOzoDPHUwjgwk/wvZ5YE1Fp/D6uxFc8gHOMFsMgNlK2gGc9ICcU2ziLwn9a
         uk1g==
X-Gm-Message-State: AOJu0YzPa/VUMShDg5XyptPRYjLzkbHN/5kdo/4TdN4pdWE08wq2SlRm
	dWBmL3V5h6JqIcOOHfJ2FrlSNn8mw7D2bTy9SuStf1kqkCG8H030FOKBU9kMtA==
X-Gm-Gg: AR+sD12udQj3kqiun457qXDN5pgp+axwGSDHGTKmLBjfydXP1rx3O7+DdPMvcuxfSJA
	GeRZhd3wAn2QezuKG40uueaEHwjAjoPtwnd9htyaQm7ILfDoS5fzwR2n8Y3IN2fWL5jN2d0EKLj
	mb9HvOjziF6vAgRKWaCZwBA9hCSBUyH4dQcZx+8IVhypeG2Q427HtLs2PmZGXcMwFz3rVuTNfEg
	MuwaQp/v6AE+g43WMnOf+xFhWLWvxnQHZgG0KSb/ru0aa02T0UF2AMHmVc19cNH4KSqziGg1BuX
	nwyX1K71OXM6j2OmOcIQ7GH9T09G1bXX1Bprifvw91a2ThgYs7gR5LTwmaB3FhuUmBiXbH4NJCL
	DyBfZ/ETtEDQuLDowyFFRdLzlpC9VWU/AqUeauC7HZXNSYg50mxhH5uU6nbzgUn2i2jhqzpCAIf
	L1omeWyLR9QXd+hRQMEfQ5xYmqXCcEHOc0kVHnZLuL3vzqSPLBWultwlUR9P9F
X-Received: by 2002:a05:6000:4387:b0:482:aa2a:52f5 with SMTP id ffacd0b85a97d-482b20033dbmr2478043f8f.24.1787116604492;
        Tue, 18 Aug 2026 22:16:44 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on sched_init_vcpu() failure
Date: Wed, 19 Aug 2026 08:15:32 +0300
Message-Id: <20260819051532.9197-3-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260819051532.9197-1-frn1furkan10@gmail.com>
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787116605-A68D9AE4-6DC839EA/0/0
X-purgate-type: clean
X-purgate-size: 2040

sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
singleshot_timer and poll_timer before it can fail -- these
become live, linked into their target pCPU's per-cpu timer list
regardless of what happens next. If the sched_alloc_udata() call
further down then fails, the function frees the sched_unit via
sched_free_unit() and returns 1, but never unlinks these three
timers.

The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
returning nonzero it jumps to fail_wq, skipping fail_sched and
thus sched_destroy_vcpu() -- the only function on this path that
calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
and the three timers embedded in it, while they are still linked
into that shared list.

This silently corrupts that list. It only shows up later, when
something else touches a neighboring timer: sched_move_domain()
crashed with "Assertion 'entry->prev->next == entry' failed" on a
completely unrelated, valid vcpu's timer.

Kill all three timers in sched_init_vcpu()'s own failure branch,
so it doesn't depend on the caller reaching sched_destroy_vcpu()
to undo what it set up itself.

Fixes: 1ad5dad74cde ("[XEN] Re-jig VCPU initialisation -- VMX init requires generic VCPU")
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
v2:
 - Added Fixes: tag.
---
 xen/common/sched/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index a9daa42339..5777096592 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
     unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
     if ( unit->priv == NULL )
     {
+        kill_timer(&v->periodic_timer);
+        kill_timer(&v->singleshot_timer);
+        kill_timer(&v->poll_timer);
         sched_free_unit(unit, v);
         rcu_read_unlock(&sched_res_rculock);
         return 1;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 06:36:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 06:36:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394629.1633306 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwZuN-0004UX-5L; Wed, 19 Aug 2026 06:36:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394629.1633306; Wed, 19 Aug 2026 06:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwZuN-0004UQ-2R; Wed, 19 Aug 2026 06:36:19 +0000
Received: by outflank-mailman (input) for mailman id 1394629;
 Wed, 19 Aug 2026 06:36:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwZuL-0004UK-J6
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 06:36:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwZuK-004Wsb-5J
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:36:16 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a854eca-2eae-0a2a0a5409dd-0a2a4505a6b6-46
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:36:16 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a854edf-4cb1-0a2a45050019-d1558034e4c4-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:36:15 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso4699215e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:36:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0fda98sm56248705e9.1.2026.08.18.23.36.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 23:36:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787121375; x=1787726175; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=NaC35gYbS2pr7tA6g+3JbYO7R+Xiuc2IAZlQ8nbOeqk=;
        b=KEtmB90xiLPRnECStVvj1pgsgut5rUpdlo+2BxYt7Rc6la/A4bfLLkfJfpvYnFGkg2
         11Oy87SXTJ5iuzwOD9yVWYbxhDdtQKBSqx+deFGoIP90PPomhfL4IyyM9tt5fBMFmaHD
         7ZTJQhbVeJbH1AsJOM41kozDxrAEEbb0jqF2ofSt1lDCaLXKSW+7o1lV/FJ8WsrqX7wy
         zqPV4/WKmFaj/lERLMOub6JWbO+0rTZUzHDeiZvMCTSvisjfxMqwbPhfIFdu3n0I5wc8
         SQYY07KsBMbIb8y90Llk6LtDS6bjBnVGtemNiuUD6JQZQ9FXydA1D6IoKzEcUOUy+KHs
         hEcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787121375; x=1787726175;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=NaC35gYbS2pr7tA6g+3JbYO7R+Xiuc2IAZlQ8nbOeqk=;
        b=RnqTUWDP+VOnMltTHgn3e0rjODQ/InwVcNcUvyRuXrqRR9zEh6+LxyJNAVuYIJ+b4T
         AMu2X5wuV8vTfzE3uF+voxUj7KutllH4wiKYZAvuMgUSKnKpRaOjM2G+RFnRHYujduuT
         1isSeDwlomCOOanz6RPTIsm4E1gBGuI+F9Io6rDKzQADKpWmefvrklZn6e2fTnRb6A9a
         A7oMGUcxaE048ZEv1nlI1qSrZF3FnpUWhh9vapxtgzBFlOCsqsWMtXOlzz6W9qnCJX0B
         mxwuaB+pwAsXlTun3q8a6SfqFb15eeWDyezM008YfiGc9u6LdMLs0x4U1ixe03bO5y7p
         9MVQ==
X-Forwarded-Encrypted: i=1; AHgh+RpFaPnyU6BE62+K3EDfiSOk68ZOSZy6eUvf3/63X78daI6O1W+/ul/NoB1rFsk8XRY5zMyM+ntxxZ8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4jZcGfVT99bN7x2ijuhfHYx5gAtcrr0oHZ8/VMek+6ZMNt1VK
	clk56l+g3u04d89cdJpHYs9lMYWMbUuIsQlQ+37WbpF/rGTlXj/yPzlUpJsN5vzPAQ==
X-Gm-Gg: AR+sD13zwvTMG8Vj57mnh3pxQ+WM4s1UCkpTcJ6hgo5cnLQsxyHBB5JVO1ChwlcbSp5
	znYc4PbVWUuOJoYMqJPlK+Gn9Nz+o078t3OmXYFXrkAmVLaw5lQBFX2vrnFGh2YPHFeT3AAK+ko
	MoLSUPaGnuOFIsXQ3DkxEx/bdIUmn3BY5783p1ub+XYFl881UY9R4NIR/pJJ651OF84PnTWbq26
	TLLBhTgX7MwU3kGD4R1i2SF5cgc420Bka5tDfcbKIV2UqyBT1t95wrkCLaNKwazaFhS14lzjpeL
	aLTk6WnZAo4HhTPV/MvrhUswkhsTbDEaLvrDWE3bNVnWbSaaBzXm/Rqdz8vUCIxsIq35+3a0bfb
	TafTcnFgjl+Rabdlj/Vi0O80pr6NXWiPf7w8RIIJXwImJiuiUSXTIZj1avIlJsepKvsPEZ4LBOX
	gfQNMl518UxwUQIt/dyKXEjTnSxw2odSrSq5RH/yhroA+5UkIGSonKQD1srGugkHmpwplsP7rxV
	KbcjnjQA5y03I6OC028NAeXZX5rBXKRm9ZpQm65+cEbraB6ShFi
X-Received: by 2002:a05:600c:a05:b0:495:3da3:beb with SMTP id 5b1f17b1804b1-499aa1b6a02mr33406285e9.10.1787121375452;
        Tue, 18 Aug 2026 23:36:15 -0700 (PDT)
Message-ID: <41b21e6f-0049-45f8-afae-8116f09fbf22@suse.com>
Date: Wed, 19 Aug 2026 08:36:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
 <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com> <aoTRPKeD6__D7Qra@end>
Content-Language: en-US
Cc: Juergen Gross <jgross@suse.com>,
 Anthony PERARD <anthony.perard@vates.tech>, xen-devel@lists.xenproject.org
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <aoTRPKeD6__D7Qra@end>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787121376-251182A1-88EEBE1A/0/0
X-purgate-type: clean
X-purgate-size: 1888

On 18.08.2026 23:40, Samuel Thibault wrote:
> Jan Beulich, le mar. 18 août 2026 08:03:51 +0200, a ecrit:
>> On 17.08.2026 18:37, Samuel Thibault wrote:
>>> Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
>>>> On 17.08.26 09:48, Samuel Thibault wrote:
>>>>> Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
>>>>>> There is no user of libpci left in stubdoms.
>>>>>>
>>>>>> Remove libpci from the stubdom build system.
>>>>>
>>>>> Wouldn't it be useful to keep this for anybody who would want to drive a
>>>>> PCI card from a stubdomain?
>>>>>
>>>>> I mean, in the zlib case, it's really a mere question of build & link,
>>>>> so we don't need to ship it, people can do it themselves easily like for
>>>>> any other library.
>>>>>
>>>>> But here there is actual porting work, that we'd better not lose but
>>>>> keep shipping.
>>>>
>>>> This is all still available via git.
>>>
>>> No, it is not really.
>>
>> Question is - does this matter in the first place? If someone wanted to
>> drive e.g. a USB device, would we include USB code?
> 
> Why not? I mean, better centralize the maintenance of such code instead
> of possibly several people having to maintain their own USB layer each.

Well, but where would you stop then? We can't provide for everything. And
apart from "everything", "nothing" is the only other clear boundary to
possibly use.

>> I'm with Jürgen that we should have in the upstream tree only what is
>> also used in-tree.
> 
> But then there's probably quite a few things that could be dropped
> from mini-os because the mini-os and xen trees don't use them, e.g.
> the fbfront. But is that really a service to make to people using this
> infrastructure, or planning to?

fbfront is local code of ours, not something we pull in. IOW I don't think
that's valid to use for comparison here.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 06:39:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 06:39:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394641.1633314 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwZxh-00054e-Ho; Wed, 19 Aug 2026 06:39:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394641.1633314; Wed, 19 Aug 2026 06:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwZxh-00054X-Eh; Wed, 19 Aug 2026 06:39:45 +0000
Received: by outflank-mailman (input) for mailman id 1394641;
 Wed, 19 Aug 2026 06:39:44 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Bertrand.Marquis@arm.com>) id 1wwZxf-00054R-LV
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 06:39:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwZxf-008IAx-2B
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:39:43 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a854f99-e002-0a2a0a5209dd-0a2a4508c4bc-24
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:39:42 +0200
Received: from [52.101.83.24]
 (helo=GVXPR05CU001.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a854fad-f659-0a2a45080019-3465531807b6-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:39:41 +0200
Received: from DU2P251CA0016.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:230::18)
 by AS8PR08MB7337.eurprd08.prod.outlook.com (2603:10a6:20b:444::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 06:39:36 +0000
Received: from DU6PEPF00009525.eurprd02.prod.outlook.com
 (2603:10a6:10:230:cafe::65) by DU2P251CA0016.outlook.office365.com
 (2603:10a6:10:230::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Wed, 19
 Aug 2026 06:39:36 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 DU6PEPF00009525.mail.protection.outlook.com (10.167.8.6) with Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3 via
 Frontend Transport; Wed, 19 Aug 2026 06:39:35 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13)
 by AS8PR08MB6599.eurprd08.prod.outlook.com (2603:10a6:20b:332::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 06:39:03 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 06:39:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=JVB+MhqXPF5c3iWwBFv2TER6uvLSHinvHUtyBFdYswfC4mx7HSyF7GYxXI1+KQ5eB7MdPNUtSCkftFgWBOS57WSUdbbsiM4kNu/mwRLL3mn/OmsYk7hjs5Nh4A3gv9JQs+oekByjSiyzDM43z4BAoiMGst88iL7/ZerwfaaCVAl5adkAW0jgYUVYK71gEMou3jDA7tKDjO/txrL5Oh2Xl+yv2zmMvHig8VFqOI0Z4fjKvB3H7oOwb6Fyh09GV8XafNl3j04dz8cDw8aFmTvshvqy3YGvGpd3+3xXCK0PY/FJnQ0OB4VRXS2nJBkSMh366ddc4H57sebabc2xy5ZQIQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZacAcQDsE5OOl2iLFSsAvmPjBCOQWiDF5j/s9C5nOYA=;
 b=fzY43MG+SRdx005ZdPrnUqTMeJCuM1QFldpVU6w3XSjs85qipdhcM04Ecyp0fN1MkkkRUnHWRI4iAeYJ8lyf/93wZTiaOUo0nV3V1Didv1u5aFtyaBBuWaKR+5m3T/J3SS+1QUPUroIKUsIQdtZWv3DAU1F8iGYHF64Ga0lfUyWiClCxqwqHPqB63ycBBzSE+fxMETBcrVHxKNMAitVxKYwUixq47PjE15LyaltfCQZLuq0vL9VYeRcoKytrzC7Ldvq89rybqPqWlXoqKR8ZUd/kezBsYjj9eIzoWb2A6VqLuETHHGe3FPB0fgMQxt9Ay4UEJdpnW3th/H6/NVQMGA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZacAcQDsE5OOl2iLFSsAvmPjBCOQWiDF5j/s9C5nOYA=;
 b=Ri8Aog0Md/7Fb4SXEiXklY4+Yme4XldRlTa+2zzFv6ndrHITpBm/1/3sRk7onOKCxn/BZqsWx+gefcSBtzGHcRrp/D8TO2ToqMDqLEFvdNCuFSDQ6KPjWtHdq/ZUSGYUKTZ0aLZGJc7BcyCJybvrzmYNGs8aRLUnUf2FlY3LbMc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cvP/PXRNniBKhf033xnWToOsjHXAdoMAiraWMLGOAo/oFFf2TiH2SlY/x342bSnWy7vt434xc3tDfem564ca9rtz20/JvtrSE93KvAi8DMIzkGjn0qkOOiiELFMp7M3vS5NmDZR5zeUeCrQ8/SydAAIioRwpR/CCpYGewdfgr/Z8qVFtOK/xqIKnbjgf/JigOpgQ2H4obFWSluFIALHRJEhKDywqYNsKeThsdFLoUK/6D9dUXlHubdEypSHI+AVpKX6J9Knnef1DniSPa0QXkCgo68/ScwrZ2EhRG4maTzf7W7V0wYKkWvoK6lFUgKx6xJjrbHBFqZJViqGgufUaEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZacAcQDsE5OOl2iLFSsAvmPjBCOQWiDF5j/s9C5nOYA=;
 b=k9CeA1KNHjwojVujJ1HPzTtcDb32S0B1UqLBMLwZOwPtxF2u/oMe3goLvbCsyPNAyn9mgToiNbZOUIo8J1jG8B6OZDQuJrYJMY9lDBEi8ksxLYAo3PMZcF+rEggJkVofoZPkLLEu4akHoZNHlQ1jKgLw0i3HxfQNxIt9rTARA4gRV1LuEhCx5JxPS39u5MZhyY3jmk7i/4YgBn+6QD+m+2qCwDmnuJUMt7Nc4L7VtjGJzBE/yozDniUFm0Lg2OjJbQeOqFh3SQHxedjmtSHz1CxQwtqowAcxB/QRJk7YaIO36R8ftIZ8Pi6/iT1lj2J5skXxbCLXM2RpXteKbX2/gA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZacAcQDsE5OOl2iLFSsAvmPjBCOQWiDF5j/s9C5nOYA=;
 b=Ri8Aog0Md/7Fb4SXEiXklY4+Yme4XldRlTa+2zzFv6ndrHITpBm/1/3sRk7onOKCxn/BZqsWx+gefcSBtzGHcRrp/D8TO2ToqMDqLEFvdNCuFSDQ6KPjWtHdq/ZUSGYUKTZ0aLZGJc7BcyCJybvrzmYNGs8aRLUnUf2FlY3LbMc=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Jens Wiklander
	<jenswi@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Topic: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Index: AQHdLwt9ezGusG27iE6LBf89mJZswbajv3sAgAANaoCAABXGgIABCguA
Date: Wed, 19 Aug 2026 06:39:03 +0000
Message-ID: <57EE3124-D60E-485B-ACDE-4F9431BA7F3E@arm.com>
References:
 <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <d739485a-72cc-4518-afa9-8d2692a225ae@citrix.com>
 <7F03E2BE-44A0-41E9-850C-8480CA0C8F0D@arm.com>
 <07151e7f-3179-4432-b7fe-e70890f1ba4f@citrix.com>
In-Reply-To: <07151e7f-3179-4432-b7fe-e70890f1ba4f@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3864.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PR3PR08MB5593:EE_|AS8PR08MB6599:EE_|DU6PEPF00009525:EE_|AS8PR08MB7337:EE_
X-MS-Office365-Filtering-Correlation-Id: f554c3d7-fa0c-410f-3dde-08defdbca2a9
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|56012099006|4143699003|10067099003|11063799006|18002099003|22082099003|38070700021;
X-Microsoft-Antispam-Message-Info-Original:
 xgbdQYEaldSHoKcJu009GOliaL+VhTRPRQQhjlvagk3YTvFa3NoMsCz3jm7opgdu2YkG3w0SLyWCSuPAp75jhPOqVIxTnXFBklDnttgfsrb7E+Ec89Pe+u/4Mn4hCYiv85TMlPZy1egu8h0QX0bTjspHf7xogUPAOESVGl1V21qAWkVeITSNtu0hPMx5FtXC1fjEOI7H1/oTa7nuoToSfRtF9iKPLdzWZU1d1UgYXW96rt6cQq6ebprpi9KtzA83vpyNmEMuWE28cm6Ymks/oT91RUHXeS9vJ5mxBEzjj6783D68vqsp2HVPFbF2iLDWuhGZ8bLxARpwxCrwZu5r07bui7P8dr6yM7MZyvnXl7dY5fvWloR3P89aTmKKEFfaG+mUnifq6vJpU/toiaRr7jO+cPVBG5DAEJ2yxuRnOXSwiM8KLvzx9imlsqOgye9GYmAYDIdUaaGd/TZfNmXcY0VSjJHkFAQdlnMV8XRQSWoZr2+ttFCZFzqf81bkC4qUbPxxgTDYNpNfKX12IFauMN1WWGBf9oggspf6HhNiBQ/nnLq5wo7/RX3doVHGsZmzmbgOB9vu0NLmz/UHKpRv541HS5Y06Y+FELjc5PUFvj3SpUsT1BmOqhBElkhKe0FWFukgw1HGIjv36QRYF7O6phTfOnsoGEKCpBAd7uT2ixtSnE51z/Wpdkx+6qXwysEd4pticIcXfKM95cMJgNkZRIQoqMTHL4SMlH5rYmlet0E=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(56012099006)(4143699003)(10067099003)(11063799006)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B48B6C0AACDEDA4A8391139B42FEFC11@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Exchange-RoutingPolicyChecked:
 eaNeOJ6Q88z9Eb9D3fPynkOEsMZS6pdz1oSQOrydI5g1RL21E6KkKmy9io7DPdj2FINk6z5k3ZPMkrtC4uULHAA1fjiiBbVUp55en2heepJQblfoePFk1cTvvZMnAppMftJ6iS5iLO49ZhClP/qc1K5+PzWWQ+prX2Iv4nnWZAH7FVOBeG0118qgb4cf6fLAdocKy7pJ9wRA5gkKRrLZdqNbYW5TfbGHU0hbtKQADWQB5T1mqeKBsyn+M09zPVVliVKKObFq35Dl8U/Zh/a1bR1DGo/d7awE4qIopo+DKCv7YRqQqkThTQ9Jeod5VS3/FySc+Lo4l3hBzMNT9vwxRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6599
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF00009525.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	b3c018b4-98e7-447b-a512-08defdbc8fa5
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|1800799024|14060799003|82310400026|35042699022|376014|36860700016|4143699003|56012099006|10067099003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	8S9GJI2I2sGYqW9NYoJ4oKSvZkkf1uXAZIP8gDQhFzUMVA+ao8UkhSzuSvZxXTcETHy/fdKYiGrpFmYd/N98GNADrp6+LO9p+b/UqFZRurchUf6DtQkzk1IaLhUBvIEZkVTyEdXl7Yax+OT+RjPRkOD9NPE/yg6/g9eoKAXORp5tZW7WcFLlNqItBHKFyqlDzDb/dLc3HWZYrxXKJpN9SvFibwWPBps3wFNBLzDVGaLfANeTAJ8Jn1753ibJvn/gX2FFWJQY/M+crjxfLBbwgEm5L1ZMu+BV/iYOjZBFaEbF120vgSo3SiCGKNJG1wKG1xpckKanu8Ro8EOLbEb4+/IVH/5OOj7EYKRrhV2pbF5weTCq/YVjTNJfXqBCj1MfF8t1VRmXLMxRLsVqycXHuKRSgKBkp4DKXlogLheh1oBFKACnLD7p7k3ZKpysuNjgefnVe8uH75eedw4T+oiHCaD/556fnRZbijdKn87vgeVMBKASXmtBM210KSRpcEU+9+suFLgcWo2nVEqKC63eHnNGRgIqGH4XwE2KEybOxoxlLci8fnajm0/VsxyzXPaNY7QffDok6iGXfVds9dSDsbR5SBLcmvscCF1PVQnbSU3NCsYQ9qzibsOs4fG6DQd368CyCBK8cPmqigBa6JxrppgQ04uJBx6lMKUD8eam+n1kFcuBFJRT4QOsShIot2RfVfwPa9vVZ31H5KJoEVD1MA==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(14060799003)(82310400026)(35042699022)(376014)(36860700016)(4143699003)(56012099006)(10067099003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	f+uaSCbYCMDQQZ2HNV7Zq1BFGQXDu/Lcrq1I0/j5iMaWzYws203llt6vSndEuT9PzsYzr1MhCAnzq8vru5CNFAc8YaKXXFI5y5gRsAipKy+GDgsotEocgiyuXj3OeTbNfpeOr8K82AGwLZOqkqzbmwtvDGR4rqBG7RWhNeGEf4Mxk+9PXILzHpfBIdxj7Iy4VXZmtbPcwl5hWxuI5UrSL9Wm5NCbDxyJ4Z5P9AQqYAdJ9CAeeyIbkV2AHBX54/nrN1xPOGvPCKhv36phKS6shPt9sgrxReM7zk/5IcdzrKrDB9epLlXYUBKZUA1MXEchMNUraXhUcxk7ZT+Ph9JR90lHtnBopofrNV/ZxaCcb8uXYn02ow4yYcVM1uOHm2B1fL7ryO9N2zyGkPjxR5QnFNqpmV9EraEA99wrqSQF+Rxdq6jFbMfYqVjkZArQaU4p
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 06:39:35.6886
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f554c3d7-fa0c-410f-3dde-08defdbca2a9
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF00009525.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7337
X-purgate-ID: tlsNG-c1860d/1787121582-D654487B-052157AC/0/0
X-purgate-type: clean
X-purgate-size: 3535

Hi Andrew,

> On 18 Aug 2026, at 16:46, Andrew Cooper <andrew.cooper3@citrix.com> wrote=
:
>=20
> On 18/08/2026 2:28 pm, Bertrand Marquis wrote:
>> Hi Andrew,
>>=20
>>> On 18 Aug 2026, at 14:40, Andrew Cooper <andrew.cooper3@citrix.com> wro=
te:
>>>=20
>>> On 18/08/2026 1:16 pm, Bertrand Marquis wrote:
>>>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>>>> possible vulnerability.
>>>>=20
>>>> ffa_handle_msg_send2() copies the message header from the guest-writab=
le
>>>> TX buffer before validating and using its fields. A plain structure co=
py
>>>> does not prevent the compiler from re-deriving later field accesses fr=
om
>>>> the live TX mapping.
>>>>=20
>>>> For VM-to-VM messages, msg_offset and msg_size are validated against t=
he
>>>> source and destination buffers, then used to copy the payload. If a
>>>> sibling vCPU changes the header and the compiler reloads either field,
>>>> the checked and used values can differ. This can cause an out-of-bound=
s
>>>> read from the sender's TX buffer or an out-of-bounds write into the
>>>> receiver's RX buffer.
>>>>=20
>>>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled b=
y
>>>> default. The audit ranks the likelihood of such a reload as low, but t=
he
>>>> C semantics do not guarantee that later accesses use the stack copy.
>>>>=20
>>>> Add a compiler barrier immediately after copying the header so that
>>>> validation and use consume the same snapshot.
>>>>=20
>>>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/ob=
server-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-tx=
rx-buffers-ffa_shmc-ffa_msgc
>>>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>> ---
>>>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>=20
>>>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>>>> index 1eadc62870f2..39f561c8237f 100644
>>>> --- a/xen/arch/arm/tee/ffa_msg.c
>>>> +++ b/xen/arch/arm/tee/ffa_msg.c
>>>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs=
 *regs)
>>>>=20
>>>>    /* create a copy of the message header */
>>>>    memcpy(&src_msg, tx_buf, sizeof(src_msg));
>>>> +    /*
>>>> +     * Make sure that "tx_buf" which is shared with the guest isn't a=
ccessed
>>>> +     * again after this point.
>>>> +     */
>>>> +    barrier();
>>>>=20
>>>>    src_id =3D src_msg.send_recv_id >> 16;
>>>>    dst_id =3D src_msg.send_recv_id & GENMASK(15,0);
>>> This does look to be adequate to fix the potential issue, but you shoul=
d
>>> drop the ACCESS_ONCE(src_ctx->guest_vers) a little lower down.
>>>=20
>>> With a safe copy on the stack, there's no need to further inhibit
>>> optimisations around it.  In fact, it's unclear why e040b94d0fff added
>>> the ACCESS_ONCE() in the first place, seeing as it was already an
>>> on-stack object at the time.
>> the ACCESS_ONCE is protecting the access to guest_vers which is not on t=
he stack
>> but a value on an internal context accessed by all VMs.
>>=20
>> You probably mixed src_MSG with src_CTX ?
> Oh, maybe.  Those really ought to have more distinct names.

No worries.=20
Would you consider renaming them a requirement for this patch?=20
If not, I would prefer to keep this fix focused on adding the barrier and a=
void unrelated churn.

Cheers
Bertrand

>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 06:40:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 06:40:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394649.1633323 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwZyb-0006YV-Te; Wed, 19 Aug 2026 06:40:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394649.1633323; Wed, 19 Aug 2026 06:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwZyb-0006YO-R9; Wed, 19 Aug 2026 06:40:41 +0000
Received: by outflank-mailman (input) for mailman id 1394649;
 Wed, 19 Aug 2026 06:40:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwZya-0006YC-0D
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 06:40:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwZyZ-008ITr-DI
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:40:39 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a854fd5-e002-0a2a0a5209dd-0a2a4507d166-40
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:40:39 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a854fe6-b4ea-0a2a45070019-d155dd2ebd45-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:40:39 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-4798bea72f9so316842f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:40:38 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14d0360sm2994641f8f.33.2026.08.18.23.40.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 23:40:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787121638; x=1787726438; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Bk6nB7NQ9tmfzBrQcoOGA1Uhrr6jhusHNKM5pz/OGpc=;
        b=NOFJVtEbvzSZCVVwiyBUrJ2MYKmFwOnpnwPQsSNdaNrtQyICKXR31KCFkCqpBii4OJ
         8drTzSEFsfJ6Ijdl941c3ay2GD/bYAviGlD7BHbbjNS5ppW/P7NMK5RuQb+cLAblwfRA
         qtEMoGlN3kcSvCfYVW6XTxEe4ynSURZTQ9SOJWuADRq9yRn/39r8Pm+/5euGXra86wra
         gSARd1nA8q1HvkJvnfRfn03XTLri7Wca1k2ytBmd2PR4p7ye1Pom187hjHJIRG27dKYf
         UkB2sT3H4gdD+lIRbzgDqFBwwcUGoBEN01tg3vxGX99aENWkN4MQCB/d/gIbnmxjfbL2
         If7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787121638; x=1787726438;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Bk6nB7NQ9tmfzBrQcoOGA1Uhrr6jhusHNKM5pz/OGpc=;
        b=CplGSt1tnycfCDGm9QJ/FYP36FFq4qccIDZM8dZ7/7nNugI/f8JufgyejJe/O/1ISa
         wJ8HobST1TTzxIr+lGTtVwGZiyDVjSu98Mk449lSWAH+hf7/BEB9UlgaqfYTcHFQuDU9
         jDyGXSBKPgePa7gqKTyOdMPOwquzKEqE4WFYfzKHcwZq2dLlAhWKbKMfZB4FaNJ9vbI7
         2cMIs5Y1GR3RyFzqqb3Pp86S1O2h/esi7g6eCLapwuLw0Xo5f0zVdOh4uaL/kTrlkHnD
         +piOVceuL/I7/vxH8bY7gDvGF4pig1eRAEYPvROz4N9jKms1Q22pp983VPKcLVNXPojA
         sOvA==
X-Forwarded-Encrypted: i=1; AHgh+RqoxMYxi3ThWg6zYLCNZQozNi4zNhID/CyFoDfiDIfmnmaJiag9TSwbfupNh05cmx3EYgxzEEeA9y0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyILE4tNoWunG7/tL8wpiZ5Gb+UGJg6UkROPPlTchqAZpMi358r
	uiuQ0SKG/Gvfxqijv7hYDOYtnpMidOfgf5AcTWPTkaPpAFY8VETabF0x2cOcdrRu5A==
X-Gm-Gg: AR+sD10MuihLZVJHm/ZEJkJSIdU04ihJeXcSDBsigB1xhI3ptN7Q49ACkL/1kmbe4DU
	aY8zAA2H2Tiq8M15iNWwrXYntHc8nRhZ8czKTQbIrUO+/jxesu9kBG6ookJfkOXExjNWF7fSVT9
	HJrLYVevyt+ebBtRfW1/sQKaj90QoS9Wx5PPnHrJ2CpujQUVYTzPIjWrStKCV7ijw/nR6H7vd8B
	3TBN6OC17SgZNQaZYUyOhWB9Z1f3jFk30d7DivVno9NFNEAlqOvGK+10fLHfN5gHQOJCszrYdqS
	3X6CzrcCp1zqsuAwfFtcZOPgst6DZ7p+tPPXSl9yB99RU8SyO0uCG6fS0dyFKK7Nb+lEWe7BVk3
	BbpXDeARsY3i1APkAF9ueOaUm5Djihtn5gEMXee+sGh8C9lFRx/pSR9gGqq1ouU3LWVONkXemnx
	rJx4he91DRbJQFYiGT+xB/DC8EfsxU5GvqZQevYDkhPAk7uaf+s0LROd7v2TW78v3Z80RvCknmT
	BQHhev69xvnF/ABiDAkS73Hv1CnzGe2tkET3CuNHt08jtJBpOQCH7fb5mILY3Kz
X-Received: by 2002:a05:6000:1a85:b0:47f:77dc:b066 with SMTP id ffacd0b85a97d-482b1e84864mr3107006f8f.5.1787121638562;
        Tue, 18 Aug 2026 23:40:38 -0700 (PDT)
Message-ID: <dbe4d409-37b9-45b9-ae5e-5bedb5df0bb4@suse.com>
Date: Wed, 19 Aug 2026 08:40:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
 <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com> <aoTRyxN4gzsEwJa5@end>
Content-Language: en-US
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <aoTRyxN4gzsEwJa5@end>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787121639-342F4AE4-4239CA7D/0/0
X-purgate-type: clean
X-purgate-size: 1794

On 18.08.2026 23:42, Samuel Thibault wrote:
> Jürgen Groß, le mar. 18 août 2026 07:43:34 +0200, a ecrit:
>> On 17.08.26 18:37, Samuel Thibault wrote:
>>> Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
>>>> On 17.08.26 09:48, Samuel Thibault wrote:
>>>>> Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
>>>>>> There is no user of libpci left in stubdoms.
>>>>>>
>>>>>> Remove libpci from the stubdom build system.
>>>>>
>>>>> Wouldn't it be useful to keep this for anybody who would want to drive a
>>>>> PCI card from a stubdomain?
>>>>>
>>>>> I mean, in the zlib case, it's really a mere question of build & link,
>>>>> so we don't need to ship it, people can do it themselves easily like for
>>>>> any other library.
>>>>>
>>>>> But here there is actual porting work, that we'd better not lose but
>>>>> keep shipping.
>>>>
>>>> This is all still available via git.
>>>
>>> No, it is not really.
>>>
>>> I keep reading this argument, but people will not know that something
>>> exists in the git history, and will just assume that it does not exist
>>> and has to be written.
>>
>> What about adding a comment to the stubdom Makefile in a separate patch, like:
>>
>> # pciutils support has been removed with commit <commit-id>, revert that patch
>> # in case it is needed again.
>>
>> I think this would be preferable over unused and probably bit-rotten code in
>> the repository.
> 
> I don't see why it would be bit-rotten, since the pciutils version in
> used is fixed,

Which is one of the problems with it. Why are we forcing people to use a long
outdated version?

Jan

> it's a library that has a quite stable API, and the pci
> xen interface is supposed to keep backward compatibility.
> 
> Samuel
> 



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 06:50:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 06:50:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394660.1633332 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwa7p-0008IN-P6; Wed, 19 Aug 2026 06:50:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394660.1633332; Wed, 19 Aug 2026 06:50:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwa7p-0008IG-MD; Wed, 19 Aug 2026 06:50:13 +0000
Received: by outflank-mailman (input) for mailman id 1394660;
 Wed, 19 Aug 2026 06:50:12 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwa7o-0008I9-7m
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 06:50:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwa7n-00B86t-KP
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:50:11 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855220-8faa-0a2a0a5109dd-0a2a4507b018-6
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:50:11 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855223-b4ea-0a2a45070019-d155dd31a51e-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:50:11 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47de008b020so311586f8f.1
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:50:11 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14cf0a3sm3377273f8f.32.2026.08.18.23.50.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 23:50:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787122211; x=1787727011; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=T4mMFQvjBgLBZcg/KWm7UdPSfrt3rVlWFkWrDYAKa04=;
        b=BHw38H9xkfTihg6Pq5J8TW/m4sc0vk2Nk54PacrVLOB4qFsCOoQUE56jT/0bV6aVTf
         LieAaYRPbxKk41Sxh28upxq3Ini1HJV/uE6xNlh+qofid0+sUKAXWGxfF59C9seav4m1
         tFKvrpaa6XxIOZR7b48kxznC9mK91EUKEHzhonhwaI1RmGaf/js/KNrAA/0KZdmQ4un4
         pQTE9dFdR+uCILgMVKPBZmfrr3+jQOxn0i4sZr7KcI4YpJbRd0GlXsMBiM0GDcVNba7m
         NTL4+RQkuD7g/zUB2e/Qu0wlvf8TUEKPdEdqBFZv06zdiMmmNXMWwZ7ACuAQ98q/pTOL
         Eykg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787122211; x=1787727011;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :cc:content-language:references:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=T4mMFQvjBgLBZcg/KWm7UdPSfrt3rVlWFkWrDYAKa04=;
        b=ApzpT4+JlcTl9Z50OazrvCaG9kzGZlXBF7GurnCUgUPyKNoOZaoP7RMKHyR5R3m3dM
         9lGZxTIlwPw7GggJBNPH3el5AZoKHqAPOZ3cghJp0OEN2GFV7pPjIuCMGyYx6BNT6Qks
         YpS8CiR6qxjZ0n2yHPDVtP7QOSseNZ+GvXRzHzL1ftGo5tTun4NJiyTUyLlp5LM+zZ11
         C58zq9RGmZjzRvMLGvR+MEQomZI+XTn3wPYQ4XBJIjXQlkZp/A2Wo6bgkAwAKXVnHvlK
         kKzX6hPKslIBgaff/dmhemunYBAGa6fghGfva3ow9M/3XNpha5+VPFOHzurHVr+HNQJz
         terw==
X-Gm-Message-State: AOJu0YxikSGYGFnu8JPPRiXOV3TBcj49gW5HkOxx1sU2wLbbCs0wrNd6
	s4eS9laaNjCcdCgUgZQaZVYBK72Hf8VeBcfSmgyLxv8Tr/DXi3e9qLUJEjVbAsZ8uyMH3UKvbMs
	PzbnvVw==
X-Gm-Gg: AR+sD120UokVYegadHPZQKIB2pqd2zzelXkZzw+CXISdNyRlunrZML/0xkK8mr9LzOJ
	8YLlcvlBsuMtgOQ9J9torRJ+DllxwksLb7w26H+bb3hFGvzUYdLrZrtImtjUpdTWnb6wDJZbicY
	LeMtflftwMSQm+cbsNzJxigcP1i4t3TXK6smmX78peT4YN0/STai+NWbyOmAexS3UUqvLYXYYTx
	tnOyaRHsnQ+w8iRI3RlTMFMHJh9M7g0gdMK55DcFkPEpk3hLc+hNCfJ4bZQS4L7q++PyN+pc3s7
	nYtC61FnMkt+I6udGvb+F7Et2VSFgwSLoqoPXZoUFhX119m6iHu1hYTb76M6wjCKQZK3zrsiqcd
	0T67MzmcI/xpVSLoaXyUs5nJkGQmanxtRvkp0RvBr9fm+0dZKilMJUxC4Ck5RyC1Ox6DoO0zSRs
	YNLVcbjG1fZINTy0uLOxl1RIMsIlgiFT4hemtLSy2/NhT2b9vhQlBMLYCphxoET+NIHMWjGdk5o
	I+Dy15D23p0tAx9kmTTFiehjWd0mVO/YkCanflFAxGq0V09Ix/V
X-Received: by 2002:a5d:6f19:0:b0:46b:70db:2113 with SMTP id ffacd0b85a97d-482b0ede030mr4438320f8f.0.1787122210954;
        Tue, 18 Aug 2026 23:50:10 -0700 (PDT)
Message-ID: <4a1b5392-93b9-4b9e-bf65-3fb280f385fa@suse.com>
Date: Wed, 19 Aug 2026 08:50:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [BUG] Linux kernel crash in amd_smn_init during PVH Dom0 boot on
 AMD EPYC
To: Arthur Borsboom <arthurborsboom@gmail.com>
References: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
Content-Language: en-US
Cc: xen-devel@lists.xenproject.org
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787122211-A76D2AE4-2A90C0CA/0/0
X-purgate-type: clean
X-purgate-size: 4685

On 18.08.2026 23:47, Arthur Borsboom wrote:
> Hi,
> 
> I am encountering an early Linux kernel crash when booting a PVH
> Dom0 on an AMD EPYC system (Family 19h Model 97). PV boot on the
> same system works fine. The crash occurs during amd_smn_init due
> to a divide-by-zero exception.
> 
> There is a potentially related bug report discussing a Linux patch
> addressing AMD SMN initialization under Xen PVH:
> 
> https://patchew.org/linux/20260623211904.3674-1-jason.andryuk@amd.com/
> 
> It seems there was an ongoing discussion between Linux devs who
> seem to have the need to align with Xen devs for a proper/future-proof fix.
> I am submitting this report to share raw hardware trace data and
> help move this forward.
> 
> --- System Details ---
> CPU: AMD EPYC 4344P 8-Core Processor (Family 25 / 0x19, Model 97
> / 0x61, Stepping 2)
> Motherboard: MSI MSIS366/S3661 (BIOS ES366AOC.10P 05/29/2025)
> Xen Version: 4.20.0 (Command line: dom0_mem=8192M,max:8192M dom0=pvh
> loglvl=all guest_loglvl=all sync_console noreboot console=com1,vga)
> Linux Kernel: 7.1.5-arch1-2
> 
> --- Kernel Crash Log ---
> [...]
> [    0.817348] Oops: divide error: 0000 [#1] SMP NOPTI
> [    0.817348] fbcon: Taking over console
> [    0.823766] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> 7.1.5-arch1-2 #1 PREEMPT(full)
> 33708094282b4038de0f4f0d201b68f6a0b5d9bf
> [    0.839766] Hardware name: MSI MSIS366/S3661, BIOS ES366AOC.10P 05/29/2025
> [    0.847766] RIP: 0010:amd_smn_init+0x1ed/0x280
> [    0.852766] Code: d2 45 31 f6 45 31 ed 66 41 f7 f4 89 c5 48 89 df
> e8 c8 c7 1b fd 48 89 c3 48 85 c0 0f 84 48 ff ff ff 44 89 e8 31 d2 45
> 8d 7d 01 <66> f7 f5 66 85 d2 75 42 66 90 eb 2c 41 0f b7 ce 48 8d b3 d0
> 00 00
> [    0.870766] RSP: 0018:ffffc9000004bdc8 EFLAGS: 00010246
> [    0.878766] RAX: 0000000000000000 RBX: ffff888102661000 RCX: 0000000000000007
> [    0.887766] RDX: 0000000000000000 RSI: ffff888102661000 RDI: 0000000000000000
> [    0.895766] RBP: 0000000000000000 R08: 0000000000000282 R09: ffff888100f57680
> [    0.903766] R10: ffffea0004044580 R11: ffff888100042700 R12: 0000000000000002
> [    0.911766] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
> [    0.919766] FS:  0000000000000000(0000) GS:ffff8882b2010000(0000)
> knlGS:0000000000000000
> [    0.927766] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.935766] CR2: 0000000000000000 CR3: 0000000003822000 CR4: 0000000000750ef0
> [    0.943766] PKRU: 55555554
> [    0.943766] Call Trace:
> [    0.948766]  <TASK>
> [    0.951766]  ? __pfx_amd_smn_init+0x10/0x10
> [    0.956766]  do_one_initcall+0x8e/0x3f0
> [    0.959766]  kernel_init_freeable+0x24a/0x2d0
> [    0.965766]  ? __pfx_kernel_init+0x10/0x10
> [    0.967766]  kernel_init+0x1a/0x140
> [    0.973766]  ret_from_fork+0x2a7/0x330
> [    0.974766]  ? __pfx_kernel_init+0x10/0x10
> [    0.982766]  ret_from_fork_asm+0x1a/0x30
> [    0.988766]  </TASK>
> [    0.989766] Modules linked in:
> [    0.994772] ---[ end trace 0000000000000000 ]---
> [    0.999769] RIP: 0010:amd_smn_init+0x1ed/0x280
> [    1.004770] Code: d2 45 31 f6 45 31 ed 66 41 f7 f4 89 c5 48 89 df
> e8 c8 c7 1b fd 48 89 c3 48 85 c0 0f 84 48 ff ff ff 44 89 e8 31 d2 45
> 8d 7d 01 <66> f7 f5 66 85 d2 75 42 66 90 eb 2c 41 0f b7 ce 48 8d b3 d0
> 00 00
> [    1.004771] RSP: 0018:ffffc9000004bdc8 EFLAGS: 00010246
> [    1.004773] RAX: 0000000000000000 RBX: ffff888102661000 RCX: 0000000000000007
> [    1.004774] RDX: 0000000000000000 RSI: ffff888102661000 RDI: 0000000000000000
> [    1.004775] RBP: 0000000000000000 R08: 0000000000000282 R09: ffff888100f57680
> [    1.004776] R10: ffffea0004044580 R11: ffff888100042700 R12: 0000000000000002
> [    1.004777] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
> [    1.004778] FS:  0000000000000000(0000) GS:ffff8882b2090000(0000)
> knlGS:0000000000000000
> [    1.004779] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    1.004780] CR2: 0000000000000000 CR3: 0000000003822000 CR4: 0000000000750ef0
> [    1.004782] PKRU: 55555554
> [    1.004784] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> (XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting.
> 
> Please let me know if any additional info would be helpful.

Well, a pretty natural question: What amount of research have you done yourself?
You really should have found [1], or maybe its v1 counterpart, or the earlier
report(s) of what I think is this same issue.

Jan

[1] https://patchew.org/linux/20260814214255.83127-1-jason.andryuk@amd.com/20260814214255.83127-2-jason.andryuk@amd.com/



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 06:54:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 06:54:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394669.1633341 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaBX-0000Ms-7O; Wed, 19 Aug 2026 06:54:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394669.1633341; Wed, 19 Aug 2026 06:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaBX-0000Ml-4d; Wed, 19 Aug 2026 06:54:03 +0000
Received: by outflank-mailman (input) for mailman id 1394669;
 Wed, 19 Aug 2026 06:54:02 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwaBW-0000Mf-GL
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 06:54:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaBV-004a9R-PO
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:54:01 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855302-8faa-0a2a0a5109dd-0a2a4502b01e-38
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:54:01 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855309-6ca4-0a2a45020019-d1558034ac85-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:54:01 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-495590dde14so7546285e9.0
 for <xen-devel@lists.xenproject.org>; Tue, 18 Aug 2026 23:54:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9aa1594sm36481965e9.0.2026.08.18.23.54.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 18 Aug 2026 23:54:00 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787122441; x=1787727241; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=zD/sufHHBwoOFPIz80Xo992p9nEMYnvvpwRvLt4nMDQ=;
        b=baVDzJKXkSC6NvDtdukU/eomTemfQAB7B2tcrGCx65+FpFnV31qRrFFwirFDP7WMFX
         21Xj15ijqcZxFaN5P2MrJoZJklOgZzwhEsjPwnFiRe95qZ9Y+SZSyu1wt1W0u5LHSiAj
         vcCbuFUOZT5TRZ0AX/zd1N+9Kzrt38ajoEA5OwEx4kppY5HOwuLMuSm/Q3LMc4oC5POo
         NQzeJ21g7ildZnzlfjYz4tvb/WpUdiPd2cM5HHJxRg1sQj9lfX8Kx6ZzvSeVUW+Wdb1q
         ZFOknRLr3rqCVPWX+5XS9gDMar+rP5wIdAIcKzYFHhNc6334WnvHC2mu+WobsB9Z4ZTB
         ozQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787122441; x=1787727241;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=zD/sufHHBwoOFPIz80Xo992p9nEMYnvvpwRvLt4nMDQ=;
        b=BlR/Vmg+ywPWeGhofhySZJwGdZp7CZb7a0cOOoQDN1c0uxV6RafpwGa6SblZ1N/UBB
         kwp1nifBsf0wzLerR0rFBwq6MuywAl63nEvEDVKfK7duIGkO0TSZQuRgC0iEhlWjtYDS
         EfYnRZdkx3jYLGwFs9+i+0xog1pEymXqQdp+dOsF661AQ0udLNXMalVVw5h94MHUIJMh
         B0wA9/1Sm14TovPw/DTGZxPtDRe0y5N/ISi87dTWeDLPqbCii6LHlHtFTd5CWV5w1cX+
         6U1Sc5t2dX3Ni/H9gtvaq86z2iOVseXohziHWOlauiNbOSz7LhxG4UDvggaLeknf2VkI
         lAYg==
X-Forwarded-Encrypted: i=1; AHgh+RoVKnwc/Vw6E1aTyrSqAMMdBK9lpWpfNiGC1xFnCFa/UGCXie4MzqdWQu71W3pPZwk9GQBbLwqlc6Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRRbeHfonOU1H/3/0Rd9bJ+p6TZ7PO3pvhYGkZjA0h1SFkFwlQ
	uA7Ds4MChW3yxenZjoG1ZOoZacYEIkErn2VW+IJTlAzykSB7J+dkAk39NRXf8lAodg==
X-Gm-Gg: AR+sD11VInob9VPuUHLjwCaHfLtS7Mwt245mJ+YavZ4U19NhcncXtjTnL69kepAFyG6
	F02PHKK4KBs96LGxByg3iY1HSOM7YKzJ0Ty4U8tu6uEIh38fYoEpnvdkX00UHXMZOrNjXAz1BtN
	ilORNH+NT52uJX/ZEZ80cOfM26545awoKnJIwkamBDm53o16XaHWoz+ZQXqUcdopqFgX2NBp1gP
	Fg6Wg5hvXvpE/kaweCevw3uD95gzF+n8Z71+yOgLTzoE8135ZRQGfG+PP1hmzx3dPW1pmfIp9wA
	uB1zw816C0ul36LRaw+hSviohsawmEMd9Q5/NALYGUtsjRCSi8N3zb3f5/7mSo/QRMOn2y176wJ
	SsU/Ud0adTuco1UtFAotojdZAtAXYdv1vixY+fkLFW5Dt9Kk41R5V/L28lJz9outtl4jWsZ/x68
	GzJzBlde650LsliCSjs8Fb0ghunPms75Vi/m9bbKAhqDT/doGMzkTFodv3Y/NwSXwv44Hk4sGrU
	Nk+p+T+9wl0jVU7HDYN6MnNqOCV+SpkPU5ZRxjqoJSCa5ZtABwA
X-Received: by 2002:a05:600c:8b27:b0:499:7024:9d4a with SMTP id 5b1f17b1804b1-499aa16a958mr45894635e9.8.1787122441214;
        Tue, 18 Aug 2026 23:54:01 -0700 (PDT)
Message-ID: <fb107bee-6b6b-4e81-bf2d-846d8b6411b0@suse.com>
Date: Wed, 19 Aug 2026 08:53:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Furkan Caliskan <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-2-frn1furkan10@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260819051532.9197-2-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787122441-F3CBA2AC-F08B2CD9/0/0
X-purgate-type: clean
X-purgate-size: 923

On 19.08.2026 07:15, Furkan Caliskan wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -745,6 +745,38 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>  
>      for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>      {
> +        /*
> +         * A vcpu slot can be missing if creation failed partway
> +         * through. A dying domain is being torn down regardless, so
> +         * skip the unit -- but a domain that isn't dying still needs
> +         * every vcpu it has schedulable, so fail instead of silently
> +         * dropping some of them.
> +         */
> +        bool vcpu_failed = false;
> +
> +        for ( unsigned int i = 0;
> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
> +        {
> +            if ( !d->vcpu[unit_idx * gran + i] )

Is there a particular reason domain_vcpu() cannot be used here?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:05:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:05:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394681.1633351 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaML-0002Q0-60; Wed, 19 Aug 2026 07:05:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394681.1633351; Wed, 19 Aug 2026 07:05:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaML-0002Pt-3L; Wed, 19 Aug 2026 07:05:13 +0000
Received: by outflank-mailman (input) for mailman id 1394681;
 Wed, 19 Aug 2026 07:05:11 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwaMJ-0002Pn-Cp
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:05:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaMI-008No9-6z
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:05:10 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a85559e-e002-0a2a0a5209dd-0a2a4503ca66-40
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:05:10 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a8555a5-fae8-0a2a45030019-d1558033c1a0-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:05:10 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-499a4d1d7f1so5128555e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:05:09 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499ab2a8b34sm40655715e9.8.2026.08.19.00.05.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:05:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787123109; x=1787727909; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=px2VSvtn3ucDS4hl04iQiAarE+9qcLC8U547OQfO20w=;
        b=eTXz5jp6viWam7BQQKhjvKcIxFGdlFpdzq8ii4vqSEDXzDC9rcE4KolvyJ7CYHsCRE
         FJy9qvkj3+WyQuUykgv/GuNXH0zLqYN5yuuVXaLZT0YdaJybHixX2pdwo1eHvR77S5MO
         usJVz70dTLHA7NWHBJNgVKk5VSx9ovMNKXNlIyAadQ+c77l9F79T3LsU7EiUEpu/UjUj
         Ro+O0FhR26C1o7SWd9Qc4bFgSOprth/MzEM5xd/S0gfHXg0BSi4T/scB+q4dZlqaWQid
         VDmByXuNT27XPLPbKEUZzW6Je2l2TOaA0Sm2N3d/jw0CEDUV1wFLCrwCn9+H6SRZX3zr
         i55Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787123109; x=1787727909;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=px2VSvtn3ucDS4hl04iQiAarE+9qcLC8U547OQfO20w=;
        b=HDNQm8vzndQDG5+xORj3tsJgkB3+QEocAa9rS78kbeVsE/rQbCSYzcsu8sipkhxroB
         RzL+SME4RVzskmwhqc/1gHmFzkC6wwptKbT0+0SECSwKVrSd8s1AbxtfRQLuk6cbYXdm
         Ib4s0WErjzjDv5gWolRSVBsBwfmxIW9Ts0sUTFSAlopj1CAMVJz0eP076HMm0m+H5s8W
         L+Ydx4dGuZ9JVO751LRaq62Rlaap+G25CKnwKyH4W4iV5utZMdEl1p9iVCvLAGyMhFxO
         9WChTtbZ3bw8LI1su2/FLSX/9LDwzP+vOmZzNK4jWJRAxSeC+rELmWAEaM5GyNzha3bV
         ZOXw==
X-Forwarded-Encrypted: i=1; AHgh+RqdlB6EJRp2kU9U7eUSAxT3zGiTbdIZToeb9nq54p9/UXCt+WhaauItL2kKhY3GPUV2wfonDRXDjGo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzJ7BfQOjoF7JTXigZBA7Cq41dJsxGG5cGmDgRKzQ6PpylaimcZ
	KAISIOtpGEhB2UmI30l/qE6ng1SMmX1z4fi/XthUgPLLPIIhEvrkVZIdAcp3IpYXenc=
X-Gm-Gg: AR+sD12AhjvE5xI9py+wOWDfuXCYDMQmFbKCguXxHU/HGLlqyMF6Uo57uMRa/SwXUUZ
	J6fpzz5Lzy/n6uLjLqrQLK8BeK9Yj8tk6U+fA68TU3csTsLwayJRwO12eOfnTUeCjlQzDSniVLK
	KnrofKb7rnFRJALBgh+ew967np2yLIc32/WBY7zMnXX7ZfVSH5XDrR6rSPiKTaNrsjP15BaWZgw
	gRNqhUhrrLZfV+3XkkP3bC1DLYglwtpfn1Y1WJBGIgWW4/ZkwVJoff0A7BBISgRS7XoaCDntPG1
	qMLA29nmCP9TvQhobBTv2/rKS/h8i2LxkH4Glb88e2wskKgYTFj7gvQnnR6We3euL17AImDK4h8
	dL5pVFdGYfe0Uv+l10J3KLSrltkWLLwasgBVN7mRHGElS/G0sU6+RzFZ+matY6vAWhmMKW//mSv
	6DQoDvsH+m1Xoyeer/t+UanZ+M+Sqq9SgYEAPeWB/nKmQ88JzgjpdQdYbBdIYqOqXXmFzr6vfMH
	j5dfx8lIDAs0Hfv10W85N9iRWZ4RYXUb9w+/djWcMkt+KJOdB4ozLBTNIn/gT17bSxKfbg9fwPW
	HvhWmeUeM1zVAng/LiHvqihO8A==
X-Received: by 2002:a05:600c:64c8:b0:493:e451:a9e1 with SMTP id 5b1f17b1804b1-499aa18014emr43786535e9.2.1787123109324;
        Wed, 19 Aug 2026 00:05:09 -0700 (PDT)
Message-ID: <cae0c369-1f88-40e2-9990-97dc5147bb71@suse.com>
Date: Wed, 19 Aug 2026 09:05:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@vates.tech>,
 xen-devel@lists.xenproject.org
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
 <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com> <aoTRPKeD6__D7Qra@end>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <aoTRPKeD6__D7Qra@end>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------go8iON0vGr8tfxpQXeAcR7Oj"
X-purgate-ID: tlsNG-33051d/1787123110-6FCC34E9-C7568101/0/0
X-purgate-type: clean
X-purgate-size: 9558

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------go8iON0vGr8tfxpQXeAcR7Oj
Content-Type: multipart/mixed; boundary="------------9DSG636NSZ0eru91HRmCxZq4";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 Jan Beulich <jbeulich@suse.com>, Anthony PERARD <anthony.perard@vates.tech>,
 xen-devel@lists.xenproject.org
Message-ID: <cae0c369-1f88-40e2-9990-97dc5147bb71@suse.com>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
 <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com> <aoTRPKeD6__D7Qra@end>
In-Reply-To: <aoTRPKeD6__D7Qra@end>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------9DSG636NSZ0eru91HRmCxZq4
Content-Type: multipart/mixed; boundary="------------rKjuY9pp0bfNP0qTOcVhAs0X"

--------------rKjuY9pp0bfNP0qTOcVhAs0X
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTguMDguMjYgMjM6NDAsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4gSmFuIEJldWxp
Y2gsIGxlIG1hci4gMTggYW/Du3QgMjAyNiAwODowMzo1MSArMDIwMCwgYSBlY3JpdDoNCj4+
IE9uIDE3LjA4LjIwMjYgMTg6MzcsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4+PiBKdWVy
Z2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIwMjYgMTA6MjQ6MDIgKzAyMDAsIGEgZWNy
aXQ6DQo+Pj4+IE9uIDE3LjA4LjI2IDA5OjQ4LCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6DQo+
Pj4+PiBKdWVyZ2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIwMjYgMDk6MTg6NDEgKzAy
MDAsIGEgZWNyaXQ6DQo+Pj4+Pj4gVGhlcmUgaXMgbm8gdXNlciBvZiBsaWJwY2kgbGVmdCBp
biBzdHViZG9tcy4NCj4+Pj4+Pg0KPj4+Pj4+IFJlbW92ZSBsaWJwY2kgZnJvbSB0aGUgc3R1
YmRvbSBidWlsZCBzeXN0ZW0uDQo+Pj4+Pg0KPj4+Pj4gV291bGRuJ3QgaXQgYmUgdXNlZnVs
IHRvIGtlZXAgdGhpcyBmb3IgYW55Ym9keSB3aG8gd291bGQgd2FudCB0byBkcml2ZSBhDQo+
Pj4+PiBQQ0kgY2FyZCBmcm9tIGEgc3R1YmRvbWFpbj8NCj4+Pj4+DQo+Pj4+PiBJIG1lYW4s
IGluIHRoZSB6bGliIGNhc2UsIGl0J3MgcmVhbGx5IGEgbWVyZSBxdWVzdGlvbiBvZiBidWls
ZCAmIGxpbmssDQo+Pj4+PiBzbyB3ZSBkb24ndCBuZWVkIHRvIHNoaXAgaXQsIHBlb3BsZSBj
YW4gZG8gaXQgdGhlbXNlbHZlcyBlYXNpbHkgbGlrZSBmb3INCj4+Pj4+IGFueSBvdGhlciBs
aWJyYXJ5Lg0KPj4+Pj4NCj4+Pj4+IEJ1dCBoZXJlIHRoZXJlIGlzIGFjdHVhbCBwb3J0aW5n
IHdvcmssIHRoYXQgd2UnZCBiZXR0ZXIgbm90IGxvc2UgYnV0DQo+Pj4+PiBrZWVwIHNoaXBw
aW5nLg0KPj4+Pg0KPj4+PiBUaGlzIGlzIGFsbCBzdGlsbCBhdmFpbGFibGUgdmlhIGdpdC4N
Cj4+Pg0KPj4+IE5vLCBpdCBpcyBub3QgcmVhbGx5Lg0KPj4NCj4+IFF1ZXN0aW9uIGlzIC0g
ZG9lcyB0aGlzIG1hdHRlciBpbiB0aGUgZmlyc3QgcGxhY2U/IElmIHNvbWVvbmUgd2FudGVk
IHRvDQo+PiBkcml2ZSBlLmcuIGEgVVNCIGRldmljZSwgd291bGQgd2UgaW5jbHVkZSBVU0Ig
Y29kZT8NCj4gDQo+IFdoeSBub3Q/IEkgbWVhbiwgYmV0dGVyIGNlbnRyYWxpemUgdGhlIG1h
aW50ZW5hbmNlIG9mIHN1Y2ggY29kZSBpbnN0ZWFkDQo+IG9mIHBvc3NpYmx5IHNldmVyYWwg
cGVvcGxlIGhhdmluZyB0byBtYWludGFpbiB0aGVpciBvd24gVVNCIGxheWVyIGVhY2guDQoN
ClRoZXJlIGlzIFVOSUtSQUZUIChiYXNlZCBvbiBhIGZvcmsgb2YgTWluaS1PUyksIHdoaWNo
IGlzIHByb2JhYmx5IG11Y2ggYmV0dGVyDQpzdWl0ZWQgZm9yIHN1Y2ggZW5kZWF2b3JzLg0K
DQoNCkp1ZXJnZW4NCg==
--------------rKjuY9pp0bfNP0qTOcVhAs0X
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------rKjuY9pp0bfNP0qTOcVhAs0X--

--------------9DSG636NSZ0eru91HRmCxZq4--

--------------go8iON0vGr8tfxpQXeAcR7Oj
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqFVaQFAwAAAAAACgkQsN6d1ii/Ey+T
5wgAgeNnOmjblKPkILe0gEhi43gMsF8MgfiOAlFpLXF2oDqByLr6FNUBgsJPPIiAbKdWeY4ylnrv
KKleq0nL5MoL+bohJB5y1HimCctYfl4WI/pvNNcYBIDUG1s5AHoCGVMvdEGbIEyahg6K92eoXHe2
V8sECYH+qmqTxyNTpH/BwYRlpdk5LE33QPWGai+R/Bq9QWgY02fQghWYamQF5JqsYKOHfFLE1Xrs
j8orgzr2vfaSO7MsctfFTRF15P5s2XqdXIEYI3m/W0Jao4gfETZgPhf3rsf90Rg/6XqqTiZkVHpl
KzVcO7ow9/yy/5hdk0Txx5akGBSgQrhbumRhMo3iAQ==
=iqWS
-----END PGP SIGNATURE-----

--------------go8iON0vGr8tfxpQXeAcR7Oj--


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:08:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:08:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394690.1633360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaPI-0003H0-Mg; Wed, 19 Aug 2026 07:08:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394690.1633360; Wed, 19 Aug 2026 07:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaPI-0003Gt-Jc; Wed, 19 Aug 2026 07:08:16 +0000
Received: by outflank-mailman (input) for mailman id 1394690;
 Wed, 19 Aug 2026 07:08:14 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwaPG-0003Gn-Lw
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:08:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaPF-001Za4-Uy
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:08:14 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a855652-bab6-0a2a0a5309dd-0a2a4507ec34-10
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:08:13 +0200
Received: from [52.101.61.46]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a85565b-b4ea-0a2a45070019-34653d2ea953-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:08:13 +0200
Received: from BY3PR03CA0005.namprd03.prod.outlook.com (2603:10b6:a03:39a::10)
 by MN0PR12MB5764.namprd12.prod.outlook.com (2603:10b6:208:377::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 19 Aug
 2026 07:08:07 +0000
Received: from BY1PEPF000264B6.namprd02.prod.outlook.com
 (2603:10b6:a03:39a:cafe::60) by BY3PR03CA0005.outlook.office365.com
 (2603:10b6:a03:39a::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Wed, 19
 Aug 2026 07:08:06 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BY1PEPF000264B6.mail.protection.outlook.com (10.167.242.123) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Wed, 19 Aug 2026 07:08:06 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 19 Aug
 2026 02:08:06 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 19 Aug
 2026 02:08:05 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Wed, 19 Aug 2026 02:08:04 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=elOR1Uj83B26GzLVMdtUWGWN/ugPVEI5UWKlmF+YUBMyjh3OapYxIKFk/lqNYqyznAZZaCdUJSAAORC/HjL1fdTwugSCnnrbUM9o/msyQbtXznPLTu7ZT3hT0Gp57wPOb3ldOnJ2OMS/ZLsd2Flq1fas5Eyokm1PvhR1OkkjPVWX+2bu9RTcfJkLpg76HUtvMVaxMNcQJafDdjoEzVys8eagX5rxOpRO5Q9Zit91PXPeN353N0AhgNpx4JPDTKeoMETn1RUVbCPmOZ5QlkBUA/gDaUrY3c/x0spolymRFPtJhriVYWBE/NDWtT781I3upMaTl9s0Ou4B1wiCmMfPXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yjHP+Ld4TbMYfxiyJZ88jQOO3OOQviB4Z7wac3Ji9tA=;
 b=aQElrLR8O1Mu5VQLbVdwEIGQPp/JEw9TIGAakJSzXFcioWcygJXJnFxIgDLrWSPSMR3BsFawn9Nu9ptVKCZWLduqgNNMOqjjd3ydOZzQrabVRtSahICJd5WY7JiIaXVUB3ttvkAkPwrUdlOtjakMcidLH7XBiZs53UYKK+v0EYcdwmxjHEG6IU2U9cZq3yA+ceLRwcKCU6MX7a/14OFRhENkcCvtz+udOngr8C9fIl4ouqVEM41HzitHShmXeXSrTbxb2sKAyL+puDyEHzxneoS1V9ajDi5IFl528dhPJzcudMJhuuxaSvii8JSnn6UMBFjkKvVcFrk6oO9KqFB+nA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=yjHP+Ld4TbMYfxiyJZ88jQOO3OOQviB4Z7wac3Ji9tA=;
 b=Xg2DJ442SgeR3nlcu/1HLFbKrrrfO84+YnysT7ezPYZ/sF6SRgH7Y1qgUEUdk7TDNo56eTNKOSQlobxVQnQDTE5oRNOftzXgtnoRIko4pZmxlqQqr7glnq/zh2dlgrypVTVr3N09bTeKukznaALmmFkqTMpzl10iwLDfSuuO4lM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <e14eac36-cdba-4882-adb8-2849f3305de0@amd.com>
Date: Wed, 19 Aug 2026 09:08:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/4] xen/char: add classic i.MX UART driver
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818153946.1635464-1-onlywig@gmail.com>
 <20260818153946.1635464-2-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818153946.1635464-2-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BY1PEPF000264B6:EE_|MN0PR12MB5764:EE_
X-MS-Office365-Filtering-Correlation-Id: 76a83cef-297c-4000-9263-08defdc09e75
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|23010399003|36860700016|82310400026|6133799003|11063799006|18002099003|22082099003|10067099003|56012099006|4143699003;
X-Microsoft-Antispam-Message-Info:
	Xq8Pzk0sBCxXHEiPyxHVN+6z6RBxbkGLb2fDC67dQ89O+kfFdeBVar4yjozt4/+PYEhjRxGSMPcg0z42suUL7VdLzm48JRlixjQtcAT3HZ7sBzSvjXJmn9cek1AfVIQXjun9F7TBpJOVCXD5t+zP6Zu6/3oIqOiR8oNxb483RrsK8y/vS4mvIEuDDweiH3Wll2lQQMEtnuhRXNFsGusmyvzcw90NZ9YxYe0OAwVN2bJ4wTrGjdyr7FB8YHG1jF/PGjDJaVQ+vvWNLqtmCWTl1wipObXEd5jQ/LsRKT76mJnpqDe1Xv8642zx81q5WIAjwaR/0IRMGPv79CJkPkOnji5mmDRyCiHyIaO4CD78IRxLtoBpVZJs7UlMKlAmSwXWXivlALejQJHnkZ/FeTwyYBGBuzXKtJaYvFqFlI4Gi/SWkjiYXQlOHBRe2GYEQSt9j03/+15RKTt3ApceGDcNCGbS7NoUofxfuNA0/5z3IwBErhcLK62vgU8aUDjOByaYB1Mpw3YL0GVhG669KUdW0rVJpabo7p5/TjTWWrQKIWZSiYUJ9WlDgsrT+MOnh277ihmwjWhOWihGcZLisVxLHJoK1DYkMtAFU2N/jzA9zio3c7zJ7tBh7I6XOf9vxeq+RFbpHA2zV2TEPvDNfDhkip41G2L0BGfRDJElW781j1nzvSY0tUdlVcxBvmjFPEzD0lE8iVM7LWVg9tVAi6UMJQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(36860700016)(82310400026)(6133799003)(11063799006)(18002099003)(22082099003)(10067099003)(56012099006)(4143699003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	vKIbCbDnhjBy6BKRBpTaGSuNsOyi/iTQX1F+MVpAeZmvmTYkoTpLHGqNKxcAr92LsPaR4azYQEOEd8fbHFxsF/m6BrL0q5H2wyJN9nJqeGJYvHV1hnHTv+kUqEu4yJqbK45QjjhvnFrX4bSt1PLKjNfLnbJr1wCab2T4LEoLvmQJ6yXIX4gLtQan+f8HcRu8U+hIkfXhje0pHsuIsqLcYJaF8Ri8AMeOZ1RBdmNylTCuDR/1IH2gyU3Axbp/6rawGtvuuwGMoMfj2mWmJPYyCKN0RgkoPQpmzZ7LdDx74K1SVPKvkvWCehMvTeiyjt9Jy6O6HjOxwhlZy4R5u/jD0DTJkYtO5FtdKBA+GGCPqL6lV8qz1YqFxXVUI8bqijefcQPnSHhjxWSpyLHiq2nayn8NMPzYEvG24KuwOyPrsiDg+/CFsS0TtoX3voBBo+sV
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 07:08:06.6468
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 76a83cef-297c-4000-9263-08defdc09e75
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BY1PEPF000264B6.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5764
X-purgate-ID: tlsNG-ef75cf/1787123293-36EDEAE4-D6334771/0/0
X-purgate-type: clean
X-purgate-size: 609



On 18-Aug-26 17:39, Wig Cheng wrote:
> Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
> compatible), used as the console UART on the i.MX8M family.  Baudrate
> and pin configuration are inherited from the bootloader; the driver
> only enables the transmitter/receiver and wires up the RX/TX
> interrupts, mirroring the existing imx-lpuart driver.
> 
> The i.MX8M family's UART IP differs from the LPUART used on
> i.MX8QM/8QXP, so a separate driver is needed.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:10:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:10:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394698.1633368 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaR5-0004mm-Vt; Wed, 19 Aug 2026 07:10:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394698.1633368; Wed, 19 Aug 2026 07:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaR5-0004mf-TQ; Wed, 19 Aug 2026 07:10:07 +0000
Received: by outflank-mailman (input) for mailman id 1394698;
 Wed, 19 Aug 2026 07:10:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <arthurborsboom@gmail.com>) id 1wwaR3-0004Vv-Is
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:10:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaR2-00947D-Vl
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:10:04 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <arthurborsboom@gmail.com>)
 id 6a8556c3-8faa-0a2a0a5109dd-0a2a4502daba-48
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:10:04 +0200
Received: from [209.85.161.52] (helo=mail-oo1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <arthurborsboom@gmail.com>)
 id 6a8556cb-6ca4-0a2a45020019-d155a134ec12-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:10:04 +0200
Received: by mail-oo1-f52.google.com with SMTP id
 006d021491bc7-6aa9606ddadso612700eaf.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:10:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787123403; cv=none;
        d=google.com; s=arc-20260327;
        b=BJeRTzjW+DqvOqq4O35VR38hVsl0RYbQ+U+dwW4eX6w1CeNpTDrsQX0XQCO9nGm/Ti
         oMoanFFW//pEu9jz3j3YTpP7xRo3Kc0tBF2FwUrBxGK7ETXOuWCYZK5hRfbql5xc6zQ7
         AU+b9h4P9CgzjAEKQKf05im1HEPsBz2Oeux0wcU9CZ+1DCwHLtmmfqJy6s9z200p7YZ7
         vFL7tP8MplWu1jzzKpM5u54h11C6A0BNIhXm/ltTzHqs5+7PSvc+w6Pk+JjJu9ng3IF5
         1clqOx2UOvLx6W5R8mpku8KAXTQ59p87aDWgBbAh/B8Yw0Buc9U2gENA/MnNQEQcvu+w
         w1AQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=H0UQa7SJVLlMpEKFF4UaRWDyvNxTtVVlXym54BMWUlA=;
        fh=7sFv6QZAJlpg3YTCZX0B+j1POgKz6Tmh3lBntxDYpAE=;
        b=HYM97RI3Cx8fHzHQjP0ERB2LkEMLiuQapE2CDC46X6CtwVlnCrzXy2W5ApvPfIYuF5
         Hyxr6f8O4c2raTQzawJiFrGpMNBex1NQnW6v5vuSEOIQYAZD5+WaU0lJwr3O29PBEYoP
         SwP6j/XIv+1+uXk8hxnuKMLdTIPY2/N49HBRyV7wFpBrC6Z5vR8PrP+kaehg09d1itON
         t46tQVE/E9nksDzEXiC1KsKT7+llkQdFdr/ft3ELfTi6DZj+ZdbsMpUGA0vFGPqHjs3b
         UFe12rAYzE3zGTy8+rsk/gPY0BELbkwfY4WC52V4z7/HQUYy30OL63lSoFnxcAz6mOUN
         YVOA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787123403; x=1787728203; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=H0UQa7SJVLlMpEKFF4UaRWDyvNxTtVVlXym54BMWUlA=;
        b=dRCaU1CSLNahCvanGcO+dU3eO4Ad7L0L8CZNyJ28+H7a/tHpf52nV9M96A0fu/OnV6
         VXwdEn2R4JwGKtuppQwO5l8JR2JyAr7qyFehZDy5yJ6WkR6b+1NTmPL0jX1lfH+NOY8q
         f0ZhAeEfP2X1eLpXBpn42sCBRbM23YZsM3XufgWnGz4heuXDjjwxfyfA2l/m56ygoAhY
         LLInrgp8bmFCZYetAmPOOQIe/fCYeBUojrJu7KYoFQlwARpvc8Uqmivn16vy04niAi2f
         vDYfbWo9UsB097tk21VCdU+FIOFuMdsmfBROyhwRth/XJ6lAdMtC7QyYzdc70Xh1Ut1O
         bdqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787123403; x=1787728203;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=H0UQa7SJVLlMpEKFF4UaRWDyvNxTtVVlXym54BMWUlA=;
        b=BUkQFz+AJH2zo04vu+Gyl+sPWgq4L6RrM1K6rnnaPi7VhgrI+r5abLMLl31CW+dEGh
         +FstVEPU8Lh/KKas+efOetvDvw6cPil4DWkP782kf8uVpV1grCTQ2v5zp+Bo4qM9vHog
         CAUpJIsh6EHRSi4yZGOcgDACTDK2lyKRY20W1oN3mGJEGH1mT3qH5qLrWQYPJSIlWk3/
         /s8p/ADKpckoKHnSCCHU0m54krI61GnIC70sn9ndFnJgWCGq8VYG2RpkDBUfejU2BiMc
         BIHeM2m7l7x83Q+tWUdSL9trFp+eAHbr6iialF91FDSd579FAGi2MP2xrl1euYZG36fK
         ry9Q==
X-Gm-Message-State: AOJu0YxlfXOmc4U5IeO8zAkEIRj/aAZstten2CpGF7SIB9lb46jVLR0I
	+C0yLGuNpwpLRohu4mOcRCNu1N7C4j8Ku8h87BXw6iiJMwImI30/9JlMa3I8d0bZTZPwAxpSe+C
	6qcu686goIlYoCZRy/vSLc8bT3ehYqa2M7CXPfTiZCWJm
X-Gm-Gg: AR+sD10WCDU60ACYUoXC2iJsdTs3ak8smJRTyoBYPZ3Uj675XfoY+pSov/0GTF+UygA
	mzSvdUEJyyl2Q5IXs9D9mK/CzBtXUjO/HlKxR7d8NrvgPHWEovrSaY0XxlOQOUhgN6Vw8rYCnlx
	MVhXDiFvurA5c/M1FaERkzuxgVkxJ4kLIoFvQRa5Vi4+AzH009yuClebMp/1pzKI6FOAQHAPJGM
	9EE6aDvahJ5+ppIJUm8oIS/nzjtuIW9YtH6t87yH38OQmvDQ0u/U568Tp+YtDDAO0dQoV3fupi9
	TxFEz7bD8LL2pGfuUw1umWQN6hGIOZQlD8d+DGGmyzJrBT7mxPZyyW7rJFSp+9UBwLnj0XcD2rN
	XfdixLqw+4FqVmCqItYxPJdMF2vNtpEmhxe7s5nccyQLTBjSRg4ow+fwJMecRszZ7c9fsmhG82O
	bXcfNWuIgDdg==
X-Received: by 2002:a4a:e90d:0:b0:6ae:ab01:91a8 with SMTP id
 006d021491bc7-6b13c6e1872mr2346910eaf.34.1787123402963; Wed, 19 Aug 2026
 00:10:02 -0700 (PDT)
MIME-Version: 1.0
References: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
 <4a1b5392-93b9-4b9e-bf65-3fb280f385fa@suse.com>
In-Reply-To: <4a1b5392-93b9-4b9e-bf65-3fb280f385fa@suse.com>
From: Arthur Borsboom <arthurborsboom@gmail.com>
Date: Wed, 19 Aug 2026 09:09:46 +0200
X-Gm-Features: AcwNN1U8eFtzbjZUw9Hn3LSM1B1eaw_TN6bVF5EKgDWoLyjIqApTklAIsxl3FOc
Message-ID: <CALUcmU=QNXA8gs8JYy01tLVOH-y8mjZM-GxKzOCoA_3e2QFVwQ@mail.gmail.com>
Subject: Re: [BUG] Linux kernel crash in amd_smn_init during PVH Dom0 boot on
 AMD EPYC
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-720697/1787123404-F16AF2AC-1ED39421/0/0
X-purgate-type: clean
X-purgate-size: 5602

> Well, a pretty natural question: What amount of research have you done yourself?

Lovely response. You really know how to motivate people and welcome
them into a community.

It has taken me about 1,5 day of work to find out why the screen
remained black, to determine where the problem was, how to retrieve
potential info by a serial-over-LAN console, subscribe to the mailing
list, and create this bug report to help.

But don't worry, I won't do any debugging anymore for the Xen project,
you have made sure of that. No need to respond. I will unsubscribe
myself from the mailing list after this mail.

Thanks for the warm welcome.
Enjoy your day

On Wed, 19 Aug 2026 at 08:50, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 18.08.2026 23:47, Arthur Borsboom wrote:
> > Hi,
> >
> > I am encountering an early Linux kernel crash when booting a PVH
> > Dom0 on an AMD EPYC system (Family 19h Model 97). PV boot on the
> > same system works fine. The crash occurs during amd_smn_init due
> > to a divide-by-zero exception.
> >
> > There is a potentially related bug report discussing a Linux patch
> > addressing AMD SMN initialization under Xen PVH:
> >
> > https://patchew.org/linux/20260623211904.3674-1-jason.andryuk@amd.com/
> >
> > It seems there was an ongoing discussion between Linux devs who
> > seem to have the need to align with Xen devs for a proper/future-proof fix.
> > I am submitting this report to share raw hardware trace data and
> > help move this forward.
> >
> > --- System Details ---
> > CPU: AMD EPYC 4344P 8-Core Processor (Family 25 / 0x19, Model 97
> > / 0x61, Stepping 2)
> > Motherboard: MSI MSIS366/S3661 (BIOS ES366AOC.10P 05/29/2025)
> > Xen Version: 4.20.0 (Command line: dom0_mem=8192M,max:8192M dom0=pvh
> > loglvl=all guest_loglvl=all sync_console noreboot console=com1,vga)
> > Linux Kernel: 7.1.5-arch1-2
> >
> > --- Kernel Crash Log ---
> > [...]
> > [    0.817348] Oops: divide error: 0000 [#1] SMP NOPTI
> > [    0.817348] fbcon: Taking over console
> > [    0.823766] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted
> > 7.1.5-arch1-2 #1 PREEMPT(full)
> > 33708094282b4038de0f4f0d201b68f6a0b5d9bf
> > [    0.839766] Hardware name: MSI MSIS366/S3661, BIOS ES366AOC.10P 05/29/2025
> > [    0.847766] RIP: 0010:amd_smn_init+0x1ed/0x280
> > [    0.852766] Code: d2 45 31 f6 45 31 ed 66 41 f7 f4 89 c5 48 89 df
> > e8 c8 c7 1b fd 48 89 c3 48 85 c0 0f 84 48 ff ff ff 44 89 e8 31 d2 45
> > 8d 7d 01 <66> f7 f5 66 85 d2 75 42 66 90 eb 2c 41 0f b7 ce 48 8d b3 d0
> > 00 00
> > [    0.870766] RSP: 0018:ffffc9000004bdc8 EFLAGS: 00010246
> > [    0.878766] RAX: 0000000000000000 RBX: ffff888102661000 RCX: 0000000000000007
> > [    0.887766] RDX: 0000000000000000 RSI: ffff888102661000 RDI: 0000000000000000
> > [    0.895766] RBP: 0000000000000000 R08: 0000000000000282 R09: ffff888100f57680
> > [    0.903766] R10: ffffea0004044580 R11: ffff888100042700 R12: 0000000000000002
> > [    0.911766] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
> > [    0.919766] FS:  0000000000000000(0000) GS:ffff8882b2010000(0000)
> > knlGS:0000000000000000
> > [    0.927766] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    0.935766] CR2: 0000000000000000 CR3: 0000000003822000 CR4: 0000000000750ef0
> > [    0.943766] PKRU: 55555554
> > [    0.943766] Call Trace:
> > [    0.948766]  <TASK>
> > [    0.951766]  ? __pfx_amd_smn_init+0x10/0x10
> > [    0.956766]  do_one_initcall+0x8e/0x3f0
> > [    0.959766]  kernel_init_freeable+0x24a/0x2d0
> > [    0.965766]  ? __pfx_kernel_init+0x10/0x10
> > [    0.967766]  kernel_init+0x1a/0x140
> > [    0.973766]  ret_from_fork+0x2a7/0x330
> > [    0.974766]  ? __pfx_kernel_init+0x10/0x10
> > [    0.982766]  ret_from_fork_asm+0x1a/0x30
> > [    0.988766]  </TASK>
> > [    0.989766] Modules linked in:
> > [    0.994772] ---[ end trace 0000000000000000 ]---
> > [    0.999769] RIP: 0010:amd_smn_init+0x1ed/0x280
> > [    1.004770] Code: d2 45 31 f6 45 31 ed 66 41 f7 f4 89 c5 48 89 df
> > e8 c8 c7 1b fd 48 89 c3 48 85 c0 0f 84 48 ff ff ff 44 89 e8 31 d2 45
> > 8d 7d 01 <66> f7 f5 66 85 d2 75 42 66 90 eb 2c 41 0f b7 ce 48 8d b3 d0
> > 00 00
> > [    1.004771] RSP: 0018:ffffc9000004bdc8 EFLAGS: 00010246
> > [    1.004773] RAX: 0000000000000000 RBX: ffff888102661000 RCX: 0000000000000007
> > [    1.004774] RDX: 0000000000000000 RSI: ffff888102661000 RDI: 0000000000000000
> > [    1.004775] RBP: 0000000000000000 R08: 0000000000000282 R09: ffff888100f57680
> > [    1.004776] R10: ffffea0004044580 R11: ffff888100042700 R12: 0000000000000002
> > [    1.004777] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
> > [    1.004778] FS:  0000000000000000(0000) GS:ffff8882b2090000(0000)
> > knlGS:0000000000000000
> > [    1.004779] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    1.004780] CR2: 0000000000000000 CR3: 0000000003822000 CR4: 0000000000750ef0
> > [    1.004782] PKRU: 55555554
> > [    1.004784] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x0000000b
> > (XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting.
> >
> > Please let me know if any additional info would be helpful.
>
> Well, a pretty natural question: What amount of research have you done yourself?
> You really should have found [1], or maybe its v1 counterpart, or the earlier
> report(s) of what I think is this same issue.
>
> Jan
>
> [1] https://patchew.org/linux/20260814214255.83127-1-jason.andryuk@amd.com/20260814214255.83127-2-jason.andryuk@amd.com/
>


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:12:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:12:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394709.1633377 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaSy-0005Hu-Ay; Wed, 19 Aug 2026 07:12:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394709.1633377; Wed, 19 Aug 2026 07:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaSy-0005Hn-8P; Wed, 19 Aug 2026 07:12:04 +0000
Received: by outflank-mailman (input) for mailman id 1394709;
 Wed, 19 Aug 2026 07:12:02 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwaSw-0005Hf-Qw
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:12:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaSw-001aGL-7W
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:12:02 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a85572c-bab6-0a2a0a5309dd-0a2a4503aeec-30
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:12:02 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a855741-fae8-0a2a45030019-d1558031dcbc-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:12:02 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49978908b35so4620295e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:12:02 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aaef1665sm35726875e9.5.2026.08.19.00.12.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:12:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787123521; x=1787728321; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=DEHv+CzXB3/Fiyf4F4VjBjL5OCrtiPJUOpuAMs0AdoE=;
        b=f8cUW3pChEPCgbWBTQ83j9FPKnF/F93RAi0v/a2jANlB8B0kWsGxKfWnt8g4ZLzGOA
         03wEQTXXjxeJ1mDPX20ECUzMiWvTFJU7CUHddpFE54TDzVdh73kW9e+UF2rFjLlp3OAa
         fjRPH9OuauOwZlUUSvXU7IeWdZ9vrkK2vhjq1ohxpwH82my4HEYTv3r7oaI+zq/WNDO7
         XLRekIBTbWRwbXFW8px+zweJZy12fDRcyU3HVbk85DTdj4mK9qr6F6Rmyj7nAhz6W82L
         d68oP9n1I8Rcf9ciz4N0x9fAfdrfnyRCTAshfGzgEtIzouFKEkwqr4Q1QGlr/P+2UEH8
         RiQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787123521; x=1787728321;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=DEHv+CzXB3/Fiyf4F4VjBjL5OCrtiPJUOpuAMs0AdoE=;
        b=UmF0SE5en16LwoqdnIzUVHeE+E7HhMfXGTVfdd4yQVqzInkuNCg4ergLO1xAZADTCF
         rYdBa3HqmU6/LJ5a6P5b+MNGXVXN9Jp23lwUrxFLZLeLDVFyWO5tLEysPADfvkDs7RoQ
         6GF7QRAIDv/glmuBF9DGK/kk3/u/1gjXANo2FfErP83VkI3LAuwxmC1vFqh5X3+pzdQv
         wdD40Ahlw5N4j8JbRyKyPXlsgx7QYmHlQZ+DMJSDO0fXEgZljE280i0wgTmG/dl2BfPn
         9wONzdJd6CiRNyJFFzW8/RXSecCLZmIQzdbKcFy3wQ0gybU6MwaiI0CkHqQBFUZQSldp
         YY1w==
X-Forwarded-Encrypted: i=1; AHgh+RqOET8iM9Q8ftwIuRDpzfsZbZtR3jCjibTphKZE3ag/wzwVrh7OZY9rBFv2JJrFekhdfKtK43Kq+r4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzBJ1hIxJ1lgs9xc2NvJBysjd96XCskiraKVUtZQu1Qls4+zSC0
	9bxda0bBCA1OkDa0Bj5g327Y2erYjmo/hbrjjzzw+6pOrJgE69mE/bqumg8PUGtUPmqWaeYQTfb
	oQGLguVM=
X-Gm-Gg: AR+sD12KT8nk+Id0PRuGYI5aeAE76pqmngkt8c0TxxlSdB6YPfOmQL9BAMzt8Nnl8TJ
	KYwWA0JT4wubcmke5XlqPSRXnwoYoJRKHewa+i05hQ5ZpUWyhwBVoOHAhZ2u5fcwx1qGDCfUY1z
	1h6TiqJgy2gKiQW5m43o/jLPBQC8RieF0xX0iA/qHaizgdbxWaolo7YUOcj5SNiHsOmD8EH++PO
	MtoVrckTcCFvsUkJuwUPT506edhhMKAymIARueYQ/ulctVc8J3LuEFqD9DyGKzitGdNjVfo3FZz
	NNGHdVEnfH/89/qD+x7YkFSLl28znQ8vPoO3erYoQXfE5QVgEqgENUjeneWHaYcAd+d+Mw4MTqR
	iG21QqJDOT2DxGfPXA+ekwFnmSXCs21zA/lM9hwvPqT4iPJhHZEJhlgeheXI9o2wfqKyI2BllsT
	9AXjvYU+ZcgczV2vHhRpfdbJrxZHutvcaPYRtwXff9CLNTVgCNP0X0UARDOea8epN+1tS6siYhJ
	CncbxdOxcFBczriurX71DCOpY5douoLDcCU8yed/S7LWI2nT4icUkiyRk/tLzPwhUpKEwLdugdX
	jTmKIxdBa58ftA==
X-Received: by 2002:a05:600c:8b70:b0:495:4e89:3f30 with SMTP id 5b1f17b1804b1-499aa1ea322mr41505155e9.15.1787123521493;
        Wed, 19 Aug 2026 00:12:01 -0700 (PDT)
Message-ID: <ab78351b-6b03-407c-9bcd-74b1566fd853@suse.com>
Date: Wed, 19 Aug 2026 09:12:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
 <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com> <aoTRyxN4gzsEwJa5@end>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <aoTRyxN4gzsEwJa5@end>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------6u4Zdt0q1c61OmVqarKYgq0b"
X-purgate-ID: tlsNG-33051d/1787123522-6DCD34E9-D4F821D7/0/0
X-purgate-type: clean
X-purgate-size: 8593

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------6u4Zdt0q1c61OmVqarKYgq0b
Content-Type: multipart/mixed; boundary="------------2Hkm9I00nWh2bfGBkdpYqawm";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
 xen-devel@lists.xenproject.org, Anthony PERARD <anthony.perard@vates.tech>
Message-ID: <ab78351b-6b03-407c-9bcd-74b1566fd853@suse.com>
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com> <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com> <aoM4ufGg8QO51XB9@end>
 <4a9b5ae9-b37b-4a6c-8ee0-7e7571c99fb5@suse.com> <aoTRyxN4gzsEwJa5@end>
In-Reply-To: <aoTRyxN4gzsEwJa5@end>

--------------2Hkm9I00nWh2bfGBkdpYqawm
Content-Type: multipart/mixed; boundary="------------CjbwuI0AhnZvKZgA9rzYxhBL"

--------------CjbwuI0AhnZvKZgA9rzYxhBL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTguMDguMjYgMjM6NDIsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4gSsO8cmdlbiBH
cm/DnywgbGUgbWFyLiAxOCBhb8O7dCAyMDI2IDA3OjQzOjM0ICswMjAwLCBhIGVjcml0Og0K
Pj4gT24gMTcuMDguMjYgMTg6MzcsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4+PiBKdWVy
Z2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIwMjYgMTA6MjQ6MDIgKzAyMDAsIGEgZWNy
aXQ6DQo+Pj4+IE9uIDE3LjA4LjI2IDA5OjQ4LCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6DQo+
Pj4+PiBKdWVyZ2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIwMjYgMDk6MTg6NDEgKzAy
MDAsIGEgZWNyaXQ6DQo+Pj4+Pj4gVGhlcmUgaXMgbm8gdXNlciBvZiBsaWJwY2kgbGVmdCBp
biBzdHViZG9tcy4NCj4+Pj4+Pg0KPj4+Pj4+IFJlbW92ZSBsaWJwY2kgZnJvbSB0aGUgc3R1
YmRvbSBidWlsZCBzeXN0ZW0uDQo+Pj4+Pg0KPj4+Pj4gV291bGRuJ3QgaXQgYmUgdXNlZnVs
IHRvIGtlZXAgdGhpcyBmb3IgYW55Ym9keSB3aG8gd291bGQgd2FudCB0byBkcml2ZSBhDQo+
Pj4+PiBQQ0kgY2FyZCBmcm9tIGEgc3R1YmRvbWFpbj8NCj4+Pj4+DQo+Pj4+PiBJIG1lYW4s
IGluIHRoZSB6bGliIGNhc2UsIGl0J3MgcmVhbGx5IGEgbWVyZSBxdWVzdGlvbiBvZiBidWls
ZCAmIGxpbmssDQo+Pj4+PiBzbyB3ZSBkb24ndCBuZWVkIHRvIHNoaXAgaXQsIHBlb3BsZSBj
YW4gZG8gaXQgdGhlbXNlbHZlcyBlYXNpbHkgbGlrZSBmb3INCj4+Pj4+IGFueSBvdGhlciBs
aWJyYXJ5Lg0KPj4+Pj4NCj4+Pj4+IEJ1dCBoZXJlIHRoZXJlIGlzIGFjdHVhbCBwb3J0aW5n
IHdvcmssIHRoYXQgd2UnZCBiZXR0ZXIgbm90IGxvc2UgYnV0DQo+Pj4+PiBrZWVwIHNoaXBw
aW5nLg0KPj4+Pg0KPj4+PiBUaGlzIGlzIGFsbCBzdGlsbCBhdmFpbGFibGUgdmlhIGdpdC4N
Cj4+Pg0KPj4+IE5vLCBpdCBpcyBub3QgcmVhbGx5Lg0KPj4+DQo+Pj4gSSBrZWVwIHJlYWRp
bmcgdGhpcyBhcmd1bWVudCwgYnV0IHBlb3BsZSB3aWxsIG5vdCBrbm93IHRoYXQgc29tZXRo
aW5nDQo+Pj4gZXhpc3RzIGluIHRoZSBnaXQgaGlzdG9yeSwgYW5kIHdpbGwganVzdCBhc3N1
bWUgdGhhdCBpdCBkb2VzIG5vdCBleGlzdA0KPj4+IGFuZCBoYXMgdG8gYmUgd3JpdHRlbi4N
Cj4+DQo+PiBXaGF0IGFib3V0IGFkZGluZyBhIGNvbW1lbnQgdG8gdGhlIHN0dWJkb20gTWFr
ZWZpbGUgaW4gYSBzZXBhcmF0ZSBwYXRjaCwgbGlrZToNCj4+DQo+PiAjIHBjaXV0aWxzIHN1
cHBvcnQgaGFzIGJlZW4gcmVtb3ZlZCB3aXRoIGNvbW1pdCA8Y29tbWl0LWlkPiwgcmV2ZXJ0
IHRoYXQgcGF0Y2gNCj4+ICMgaW4gY2FzZSBpdCBpcyBuZWVkZWQgYWdhaW4uDQo+Pg0KPj4g
SSB0aGluayB0aGlzIHdvdWxkIGJlIHByZWZlcmFibGUgb3ZlciB1bnVzZWQgYW5kIHByb2Jh
Ymx5IGJpdC1yb3R0ZW4gY29kZSBpbg0KPj4gdGhlIHJlcG9zaXRvcnkuDQo+IA0KPiBJIGRv
bid0IHNlZSB3aHkgaXQgd291bGQgYmUgYml0LXJvdHRlbiwgc2luY2UgdGhlIHBjaXV0aWxz
IHZlcnNpb24gaW4NCj4gdXNlZCBpcyBmaXhlZCwgaXQncyBhIGxpYnJhcnkgdGhhdCBoYXMg
YSBxdWl0ZSBzdGFibGUgQVBJLCBhbmQgdGhlIHBjaQ0KPiB4ZW4gaW50ZXJmYWNlIGlzIHN1
cHBvc2VkIHRvIGtlZXAgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCg0KVGhlbiBJJ2QgcmF0
aGVyIGFkZCBpdCB0byBNaW5pLU9TIChwcm9iYWJseSBiZWhpbmQgYW5vdGhlciBDT05GSUcg
b3B0aW9uKSB0aGFuDQpoYXZpbmcgaXQgaW4gdGhlIFhlbiB0cmVlLg0KDQpUaGlzIHdheSBp
dCBjb3VsZCBiZSB0ZXN0LWJ1aWx0IG11Y2ggZWFzaWVyIHdpdGggTWluaS1PUywgdGh1cyBh
dm9pZGluZyBhbnkNCmJyZWFrYWdlIGluIGNhc2UgZS5nLiBhIHBjaWZyb250IGludGVyZmFj
ZSBpcyBjaGFuZ2VkLg0KDQoNCkp1ZXJnZW4NCg==
--------------CjbwuI0AhnZvKZgA9rzYxhBL
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------CjbwuI0AhnZvKZgA9rzYxhBL--

--------------2Hkm9I00nWh2bfGBkdpYqawm--

--------------6u4Zdt0q1c61OmVqarKYgq0b
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqFV0AFAwAAAAAACgkQsN6d1ii/Ey8H
OQf7BlkHTXqrxdOdphZJFu+dVI34Y9OBwMw6BUdUtOmO2cSZtlej59nt6z/O+R+alAAz6dhaH1Dg
8zuYsdgtFSZubjIv6FVh/UYvvyhyMPajTFdCNUQkmfbdOR6YnLGVjCkIpabU2zcCo3aKJXo/7k/H
gjC1oCSD9DpoYzUjWgQkjs05gyr/Y0u62CthRFrh5JK8JkqNSxCOeNP2Pm6QvteNEvrv8zTdeBKi
jjyM514PSltoWGS05xxdAMBVDUuLV07EM0JL49rrg2ccUpzzJkeHU3pHSFCjD7350ALzznqFOOZD
pkhJ1xPl31K2RKWpcMp37sFYmL8mxcC3y75uD/vpRA==
=w521
-----END PGP SIGNATURE-----

--------------6u4Zdt0q1c61OmVqarKYgq0b--


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:13:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:13:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394721.1633387 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaUj-0005pa-Tg; Wed, 19 Aug 2026 07:13:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394721.1633387; Wed, 19 Aug 2026 07:13:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwaUj-0005pT-QL; Wed, 19 Aug 2026 07:13:53 +0000
Received: by outflank-mailman (input) for mailman id 1394721;
 Wed, 19 Aug 2026 07:13:52 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwaUi-0005pM-LP
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:13:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaUh-001apn-R8
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:13:51 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8557aa-2eae-0a2a0a5409dd-0a2a450ab568-8
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:13:47 +0200
Received: from [40.93.201.16]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8557a9-f2d2-0a2a450a0019-285dc9102ce9-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:13:47 +0200
Received: from BY3PR10CA0001.namprd10.prod.outlook.com (2603:10b6:a03:255::6)
 by CH1PPF6B6BCC42C.namprd12.prod.outlook.com
 (2603:10b6:61f:fc00::612) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 07:13:42 +0000
Received: from SJ1PEPF00002312.namprd03.prod.outlook.com
 (2603:10b6:a03:255:cafe::28) by BY3PR10CA0001.outlook.office365.com
 (2603:10b6:a03:255::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Wed, 19
 Aug 2026 07:13:42 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ1PEPF00002312.mail.protection.outlook.com (10.167.242.166) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Wed, 19 Aug 2026 07:13:42 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 19 Aug
 2026 02:13:41 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Wed, 19 Aug 2026 02:13:40 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tVFI1l8qxajGAeGL4IhIl6kQUrN0UIfTEsrV95dunJGvvXWeWNrN9n9qOCSOfqYC4Da/5mTSiF0vea820LL2HjWWGnPVvHG4kcm1coJYPkFTQwCfblaxzcRrHtptnWPSTdEDZPHZJGHfpczByfoPVxZkaTNH1IeU8xmRpRFeR7wGL/dJ8FQnBk0pDehRWSSDNTrM7B6MUQXKX7ydGKre5caY+Bzv2HKOuQZs75/MnZQrCCNsdhUe9GX7cTvpw9BUccYfj0BPKz+Zn3eYaGk1qmc5WjmfL3rhJv2zhilaNomqKTzpRbxNSQwzfO28GCOcCC3BxPKdFp6qnXKuX91R1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0G+z6egPFygd4uGSiCW0yHP4QZ4BC6yuLAT+y3M+77Y=;
 b=qeKXnL86O/WHHRNyYYDr2+ChiVSJh8QedUMZund8/qvL/2l8+D6rk41a453hMBQ/xhJ97TCQedY3s1EebIrHx/zoKhE2vMIG1FFRmNZy3dOhGAlItgo8hHORUD6z1AMt+R1kEsmTGWhhD40ZK9WiTPBbWi8K7OV1brNqY1gzsZwxsRU4w2MP5Jq0zvtIqQNmdFzltv9NnKL7DMeqhBsnLBf8jt06X9RzAMlwyKsYMXwdz4F9tsrE7yAnKT9f4R5ChyHjagW46gmTEfw0dSA3Hhlmfa6QzT3xw7Yezz2eulrX9bSAS5Z99PYAT5YK/pPqFyYc4Pipt3WxGQ6q2XOqng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0G+z6egPFygd4uGSiCW0yHP4QZ4BC6yuLAT+y3M+77Y=;
 b=yAc9Voz+7Dra62HjmoAOxblfXvDPl/xeljqQ6NGbvFJDBRXoTnMJyUdvCDBhmIWhjRxD48/Be8qZrO9vOT7BgtHy5L07y0JUZIz3NrtWVTKSCVSZxSUbUlPOcFv5Vxuwg9Fi+FviuBQiUQM4MFW1O0PXEl1gbDMV5doMjgOSdWo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <a36894b1-2104-4df4-a82a-6d1b7d1cd21a@amd.com>
Date: Wed, 19 Aug 2026 09:13:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/4] xen/arm: add i.MX8M platform support
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260818153946.1635464-1-onlywig@gmail.com>
 <20260818153946.1635464-4-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260818153946.1635464-4-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002312:EE_|CH1PPF6B6BCC42C:EE_
X-MS-Office365-Filtering-Correlation-Id: 953ea6af-76de-4ade-0349-08defdc16690
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700016|1800799024|82310400026|23010399003|56012099006|4143699003|11063799006|10067099003|6133799003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	gGOZJDHt62jK7JpUQhKq3ioY/nDto5c8nC9vGNE1L6VUfkmLEAVIp3zVJV2Op4dLaobQz1RUmElVJwnDxbzLf22WXLD7/jRMNtPID9eYqNLTedvVPY2bWpr2x6B14vZ5OUZ69dwJO7eUGNRSkTjQzaeXhAWOGtNyEWOVeTnuhiz+jWFJte3oIcAXwOej9jJ6y5Trvf9II5Ij2tTG2+I079aThWPFdm+hj8wtaVHHd9iT0bvoMBMvI5DjSqdZKcK/4P1qs+Om619JVZtjC0iAeuhQh/4AWIA96dnMkyrbSSi9RXr0otooa9noQefEhMnxtYySALzgcK3qTiYXmtXFO/d9AlvnNj7xbELVm08mahnEY+Hlz5+Ehi/zswK4RAzgsk6aAQyQTsm8UYUT4gJ95+dkWnNMTZifCG9us+G6cSFJltsCWMVIgFJAXgSWvI5iQ/PBpNB5/HP0fGUrQd/rEAKbbrEpq5RMp0su3M5H2u2DLEWorGWQsYdjen/vtv0uWRdG4M0lleMOi6RdAXaQlo7e+T3m65V7AX3B0CHiph6KzfCp8tMh6ORTCccoCpMuJQPwvSKTRpP0dVXC/zs/uyZUMg/ZBUVsxL53mk5ypPGJFgd4qe/oyEaIxHsUPnIzWnID8VgZLlm92QbMbkSAALkWvVJbnEUIk7TKUHbFgEh2gEOP9OR/U/HEw9+M+nvpt3612UFRkQv9WbLf/5eb4A==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(82310400026)(23010399003)(56012099006)(4143699003)(11063799006)(10067099003)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	qzHHNT4M3KG19+3baKGZKwinN5wrIZ2+rDIJOJoChsmNgvRFCxLSR1tDJQfkaXJ3Yyg2yVExVtFdtGD0bFXzaPNBpihTJ1OsMOCxG3I0dz5phUrVSUnYIB7DGzjFK/cZkmTqr7W1uj6Ks+kCL59epVWorMO7pq8/Twu1cq/1Ugfjw9OYCib10VdM2VldBA8NC1IfEgEBb5XwPt1tJRx2iSlYLz3a9/moJWHRfGMkchLTD9b98r2pdDTK9Xq5quvYybHzI9zpcz1E9tjR8cGEga8jncSNe8ffdoP9RVVHcVBXrw5GsDLVC+QEU2kmN6KAWUhhR8Uze0vsttl2smGJ9QS722MKreg5uo4atasid6/ZG6JhC3s6LHL/NzqxWSvMCG0ArcyRRvEwQafrOYDA7VmeyFWctvIcH8wPCOArTzXdTWtcp/J0IaqW0/Uv+zn0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 07:13:42.3033
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 953ea6af-76de-4ade-0349-08defdc16690
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002312.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PPF6B6BCC42C
X-purgate-ID: tlsNG-4011c0/1787123627-599C1CFC-9743402E/0/0
X-purgate-type: clean
X-purgate-size: 6466



On 18-Aug-26 17:39, Wig Cheng wrote:
> Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).
> 
> When Linux is used as dom0 a number of drivers make SiP SMC calls into
> TF-A to manage hardware: GPC power domains, SRC (M-core remoteproc),
> SoC info and NoC QoS.  There is no public specification for these
> calls; the function IDs and their subfunctions are taken from the
> vendor kernel call sites.
> 
> Forward only the specific subfunctions the hardware domain issues,
> following the whitelist model of the i.MX8QM platform.  Where a service
> has a fixed set of subfunctions (GPC, SRC, NoC) they are filtered, and
> the SoC info call is a read-only query.  CPU and DRAM frequency scaling
> are denied because the hardware domain cannot make an informed decision
> about resources shared with the other domains, and any unknown function
> ID is rejected.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> ---
> Changes in v3:
> - Include <asm/regs.h> for get/set_user_reg().
> - Add a description for the CPUFREQ function id.
> - Drop the unused SRC M4_START and NoC LCDIF subfunction macros.
> - Order the switch cases by function id.
> - Deny DDR DVFS as well, for the same reason CPU frequency scaling is
>   denied: the hardware domain cannot make an informed decision about
>   DRAM shared with the other domains.  Previously it was forwarded.
> - Return false directly on a denied subfunction instead of goto plus a
>   redundant printk (vsmccc_handle_call() already logs the rejection).
> 
>  xen/arch/arm/platforms/Makefile |   1 +
>  xen/arch/arm/platforms/imx8m.c  | 139 ++++++++++++++++++++++++++++++++
>  2 files changed, 140 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/imx8m.c
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index bec6e55d1f..cdf936c50d 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
>  obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>  obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>  obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
> +obj-$(CONFIG_ALL64_PLAT) += imx8m.o
>  obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
> diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
> new file mode 100644
> index 0000000000..0aceed9d43
> --- /dev/null
> +++ b/xen/arch/arm/platforms/imx8m.c
> @@ -0,0 +1,139 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * i.MX 8M family setup
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/sched.h>
> +#include <asm/platform.h>
> +#include <asm/regs.h>
> +#include <asm/smccc.h>
> +
> +static const char * const imx8m_dt_compat[] __initconst =
> +{
> +    "fsl,imx8mp",
> +    "fsl,imx8mq",
> +    "fsl,imx8mm",
> +    "fsl,imx8mn",
> +    NULL
> +};
> +
> +#define IMX_SIP_FID(fid) \
> +    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +                       ARM_SMCCC_CONV_64, \
> +                       ARM_SMCCC_OWNER_SIP, \
> +                       (fid))
> +
> +/*
> + * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
> + * public specification for these; the IDs and their subfunctions are
> + * extracted from the vendor kernel call sites (see drivers/soc/imx,
> + * drivers/devfreq, drivers/remoteproc).
> + */
> +#define IMX_SIP_F_GPC       0x0   /* GPC power-domain control */
> +#define IMX_SIP_F_CPUFREQ   0x1   /* CPU frequency scaling */
> +#define IMX_SIP_F_DDR_DVFS  0x4   /* DRAM frequency scaling */
> +#define IMX_SIP_F_SRC       0x5   /* SRC: M-core remoteproc start/stop */
> +#define IMX_SIP_F_SOC_INFO  0x6   /* read-only SoC info query */
> +#define IMX_SIP_F_NOC       0x8   /* NoC QoS priority setup */
> +
> +#define IMX_SIP_GPC_SF_PM_DOMAIN    0x03
> +
> +#define IMX_SIP_SRC_SF_M4_STOP      0x02
> +
> +#define IMX_SIP_NOC_SF_PRIORITY     0x01
> +
> +static bool imx8m_smc(struct cpu_user_regs *regs)
> +{
> +    uint32_t function_id = get_user_reg(regs, 0);
> +    uint32_t subfunction_id = get_user_reg(regs, 1);
> +    struct arm_smccc_res res;
> +
> +    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
> +    {
> +        printk_once(XENLOG_WARNING
> +                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
> +
> +        return false;
> +    }
> +
> +    /* Only the hardware domain may use the SiP calls */
> +    if ( !is_hardware_domain(current->domain) )
> +    {
> +        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
> +        return false;
> +    }
> +
> +    /*
> +     * Forward only the subfunctions the dom0 kernel actually issues.  All
> +     * of these manage hardware that belongs to the hardware domain (power
> +     * domains, M-core, NoC) or are read-only queries.
> +     */
> +    switch ( function_id )
> +    {
> +    case IMX_SIP_FID(IMX_SIP_F_GPC):
> +        if ( subfunction_id != IMX_SIP_GPC_SF_PM_DOMAIN )
> +            return false;
> +        break;
> +
> +    /*
> +     * CPU and DRAM frequency scaling: the hardware domain does not see the
> +     * whole system and cannot make an informed decision about resources
> +     * shared with the other domains, so deny both (CPU frequency scaling
> +     * is denied on the i.MX8QM platform for the same reason).
> +     */
> +    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
> +    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
> +        return false;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_SRC):
> +        if ( subfunction_id > IMX_SIP_SRC_SF_M4_STOP )
This is a range check rather than a white list. I think it's very important to
be able to see what exact subfunctions are allowed i.e. switch ( subfunction_id )

> +            return false;
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_SOC_INFO):
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_NOC):
> +        if ( subfunction_id > IMX_SIP_NOC_SF_PRIORITY )
Same here.

> +            return false;
> +        break;
> +
> +    default:
> +        gprintk(XENLOG_WARNING, "imx8m: smc: Unknown function id %x\n",
> +                function_id);
Worth printing also subfunction_id.

With the remarks addressed:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:22:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:22:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394731.1633395 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwadL-0007kf-Oa; Wed, 19 Aug 2026 07:22:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394731.1633395; Wed, 19 Aug 2026 07: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wwadL-0007kY-L2; Wed, 19 Aug 2026 07:22:47 +0000
Received: by outflank-mailman (input) for mailman id 1394731;
 Wed, 19 Aug 2026 07:22:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwadJ-0007kS-Ld
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:22:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwadJ-0096X5-28
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:22:45 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8559ba-2eae-0a2a0a5409dd-0a2a4506a83c-16
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:22:44 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8559c4-195a-0a2a45060019-d155802ad4cc-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:22:44 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49954b88fffso6590875e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:22:44 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14514d5sm3950500f8f.10.2026.08.19.00.22.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:22:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787124164; x=1787728964; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=2NZoBcFqMNoc7iCqfHSRU1JgiQhuz7rRtU331DbrzT0=;
        b=VEQcWSGX4GeK5QkZE/WEn6ze3wqWEVsq0ahedcipUmx3UAk049P7bMHKlhq8P5g+V7
         WcneJJ6b+yfbCa0JbwMhBIf1FrX08cHpGG6Lbakk8MK/qqSNJkGARpIqMETwkgvQDMCf
         r6MDSzGn0F4iTl51n7tMyxIUpD8dlMzs4Ozb3X+lKRVbSmoYr4vOPgisDjuULsslDGWe
         y7pyfU/md0UHk7MdFZmL0WfKsckOhuQ0mFYDV7QyRKW1hfvuydVepf9ppp6cZaYbtoJC
         GbCssrtCWuLNYXzVt+V5iHz2rh6JhJYzafSRantSRR6vOrHY2E9zxSzpKyHppz9dsAT6
         GwJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787124164; x=1787728964;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=2NZoBcFqMNoc7iCqfHSRU1JgiQhuz7rRtU331DbrzT0=;
        b=DwkeKMSCj7Y1u9VC3k/+eI5TUBDCneWfBS5b3yJXUyp6XL1z9EBLk7LQthmrTYcq81
         Q+k8E0cTuixRHn/NZCISgynj/tACAyvszMclAG0w9qqCvXAmWRVDgGkUByVxEPTnRrUk
         J518rjZLpV5YKj8CaU4Sye5IUTt0kN+8B6klMxnH/7iwum49AcHb0s4KnDZ/wfaLNOQC
         tXgklL65algJd0SC7ZMtucavP4Ua3rC9wsla76ry89uf7/7H66xluFdjUcKA8nI4tDHm
         xwKUbFAdt9LfCbyf0GuESaNscZehXgyTq2AgRjEhwRqzlatWksrqaSxoNNY/oQmthnZ6
         XcuQ==
X-Forwarded-Encrypted: i=1; AHgh+Rq8QzTBkKQGGZQPpAfkXyqxykjG41/3Xk6PTj9WRjp2qJinHr6iP+o1CfFfSOHgwxW7qyFjfMbgx3U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwsqY4/4/6BixT4fUHqfA3M3y1f5o2xlcoBcrC3NmpMnun/IKTF
	C9n4bHe7juD5TOPGlNaa91dU1szB9GQ5yrob0EMOEJmLp/+i6xEQsu5t+/VDv47YSw==
X-Gm-Gg: AR+sD13OU+mqESWdsMSci4L+zXYsB3WvhE0wAEHjVWUkdk/sG2KCVrQuiAE10zH8neb
	oGK+gwwlgwSg6HslCt4ckyB1EFgzvtGLMKtRvNzYC6reNB5u9vE8AlP+cdzqUEvsyoYhujpijbE
	tNPdN6VQUvMBb8n74qc0tErw6uOZ5ZZaErAZmVGiPwhc/Z6rCgQOmOFpXUurI/VHIBqICKWxQjl
	LU96pv/GSCvXvTn4S4S0AWVhxc89dbf38d0CIPFmxMitkQcKRm67VHyg3iPYb9Yick7edEKQshl
	kruZK1WsJhz1SwYn0Y62eK0FtsWh7hcvtQ9GhV3yOxshxeTSFXKV25H48HSfvZW9Z4ybnxXxIoU
	3jX5UMuFPWUfZhAGpOqdyWg6dE4ct/wyWS1QyUQdrXFGNJmcrzu1OJ5eoFTfMBD1XDLeJZ4ohLV
	M2pXlqBT6cINZl76SP/kRv7b1C1OL8iNkNU5dmSNplrIJzHDmeE56UWv7kaYAcZA3HHzqe9HIeI
	C8QyLf/l5x3EfviPS0FEa24G02JhxTRpkSsE1cCkgW5Jaui0p9ZGP0EnG2wSeM=
X-Received: by 2002:a05:600c:37c6:b0:499:87f3:a2a3 with SMTP id 5b1f17b1804b1-499aa1c7bafmr45212215e9.15.1787124164412;
        Wed, 19 Aug 2026 00:22:44 -0700 (PDT)
Message-ID: <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
Date: Wed, 19 Aug 2026 09:22:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Furkan Caliskan <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260819051532.9197-3-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787124164-FDE0E77B-F564CE00/0/0
X-purgate-type: clean
X-purgate-size: 2596

On 19.08.2026 07:15, Furkan Caliskan wrote:
> sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
> singleshot_timer and poll_timer before it can fail -- these
> become live, linked into their target pCPU's per-cpu timer list
> regardless of what happens next. If the sched_alloc_udata() call
> further down then fails, the function frees the sched_unit via
> sched_free_unit() and returns 1, but never unlinks these three
> timers.
> 
> The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
> returning nonzero it jumps to fail_wq, skipping fail_sched and
> thus sched_destroy_vcpu() -- the only function on this path that
> calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
> and the three timers embedded in it, while they are still linked
> into that shared list.
> 
> This silently corrupts that list. It only shows up later, when
> something else touches a neighboring timer: sched_move_domain()
> crashed with "Assertion 'entry->prev->next == entry' failed" on a
> completely unrelated, valid vcpu's timer.
> 
> Kill all three timers in sched_init_vcpu()'s own failure branch,
> so it doesn't depend on the caller reaching sched_destroy_vcpu()
> to undo what it set up itself.
> 
> Fixes: 1ad5dad74cde ("[XEN] Re-jig VCPU initialisation -- VMX init requires generic VCPU")

How did you arrive at this commit? It doesn't even touch sched_init_vcpu().
All it does is move kill_timer() invocations around. I think it's
d884b1077817, as that's where the "return SCHED_OP(init_vcpu, v)" was
introduced (i.e. where kill_timer() would have been necessary to call in
the error case). (I can't exclude the issue was pre-existing already at
that time, but that would require more analysis than I think is worth to
invest.)

> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
>      unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
>      if ( unit->priv == NULL )
>      {
> +        kill_timer(&v->periodic_timer);
> +        kill_timer(&v->singleshot_timer);
> +        kill_timer(&v->poll_timer);
>          sched_free_unit(unit, v);
>          rcu_read_unlock(&sched_res_rculock);
>          return 1;

This almost, but not quite open-codes sched_destroy_vcpu(). Would be nice
if the cleanup logic was shared. The sched_free_unit() call there could be
leveraged here as well; what would need skipping are the sched_free_udata()
and sched_remove_unit(). And of course the RCU-locking would need sorting.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:28:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:28:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394743.1633404 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwajH-0008UF-8n; Wed, 19 Aug 2026 07:28:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394743.1633404; Wed, 19 Aug 2026 07:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwajH-0008U8-5n; Wed, 19 Aug 2026 07:28:55 +0000
Received: by outflank-mailman (input) for mailman id 1394743;
 Wed, 19 Aug 2026 07:28:53 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwajF-0008U2-A4
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:28:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwajE-00BEzc-GD
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:28:52 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a855b1e-e002-0a2a0a5209dd-0a2a4502c45a-46
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:28:52 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a855b34-6ca4-0a2a45020019-d1558033b42e-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:28:52 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4998590d392so6227685e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:28:52 -0700 (PDT)
Received: from [192.168.1.109] ([78.173.117.23])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0fd7a9sm53825755e9.2.2026.08.19.00.28.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:28:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787124532; x=1787729332; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=f+BHz/ZvcnQKOTBNafzlJ+C4BLhA+M7gH9JYI18ux3U=;
        b=lCWAahBF0ks/2p9EAIYoDM3o8teKcyD82XwU4YveSQ4LN5nzgw5l7/hND0xHUF9m7E
         +J6ozuEVQaNisF3x9jmxaO8Vtg3/oaTi/Fdw05UHDL2UGQatvw+4ZXaqr5zsNlM7qwP9
         Xk6CRvefbDmSQsi1AFqbB6dVvJE9KsNzajYOcYXkHoawICiau41uPbWeII73FsU3oxSC
         hQjS9Q3NzXqnHhOTHdZhxd+Te3kkdfjBVIebNTwZPg+KQA7+mAu1KJC46RpryX1A89dg
         1WtCvZEGRZ0erI/XpcUTTL0lLs6gTicV4RA3ZEh82oOZ9eMYSXOnnb3+8rBio0RRG95C
         aZQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787124532; x=1787729332;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=f+BHz/ZvcnQKOTBNafzlJ+C4BLhA+M7gH9JYI18ux3U=;
        b=PaB7z9h0ANDsXnjIrV0XBE0StdzEMOJ0XVz+MOP3s2H6oC3ZQuS/UWBhvYaP5vwCdb
         gFWWg2Ht3dh0yth/kcbFkOFzTWjCy8zvhuvoXilVd5h0xKW9idVYa5eYyXw0Vzchm+nS
         VTNajUR6dIO88fQmWWihkfsbEW5KuxY9v7tThUEqrrJtd6PDQt/gU+xehg5y5G8L9/b7
         w0OH9yA9Y/nxo6DJ+HHHyq8/G+A8zVuKuIukBAae7Pk+aw2dOlZD3+a1zucNKqOsNr86
         sKmLgmsNx/Rt9ot9NoCuK4Z6IM9bywwgPsvnKw6PIZbRoISlpROwYV6ymgJxuu6ir8CY
         D/sg==
X-Forwarded-Encrypted: i=1; AHgh+RoP+tuh7HuYj5Evdqo0MSpz7op6sWnvQ03zq7cYHYe6+M9CYcnWCN5Dbs0MKC/SGT0GKpSe8/76d0U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgTlG2KXHv03LpDBjFh/yI/wqc6tqZLS8NIxeHNDW6Fj/wCo5j
	UodMKxiC1E4NoSv3jg8+w23E67LyiaB7EaCd76ZBGHbVk3FweIaxlS4F
X-Gm-Gg: AR+sD12u6+mw4cQ75jBX2pYuTMR38qMwYhV7P9oFf4memb2eE4IlsG8rL/ORfnpgQ74
	UD29J21ux5vi51ut4umO/aFr73HUyR3PlAwhG8mfFFa3kUfHFUG3RVUBDFyxUnSiSSa4MnqkeMS
	AOZGJB+l0PSsMZhQzCsxwpPvH4LeVmbt9XuSq3ag0Go/Z6hS+b3gnx8FLMibxL5n1uBQnadkeQG
	J0R/hUpXbR7Vu4/sTNh3KcHSK2Mrx0gGXwUCPq/lSaImnrcjpS1zrpNjbameOaMPA8V+0D9jVVy
	ClGbf7lYTPtDjIfqThNBIR5ju8PShuCC4XlXhkmQXKCgV9Y7jp+oIVGD3y598jf+/afpguyngPM
	Q5hD+OnN93657QdovWN3HYDaF4BBGS7+gOTOM4bBXoOzwztR0/vt6970uhcXpQuq3m+bTJLfN+c
	sPuKIChRK3N8x42Ohivx0PHHC/vrHLJtgIhtDiNObKlVZmQm5BpbWMKGtWzKB4RMhROPM=
X-Received: by 2002:a05:600c:8b32:b0:496:c06b:9fb4 with SMTP id 5b1f17b1804b1-499aa200efcmr44193365e9.14.1787124531545;
        Wed, 19 Aug 2026 00:28:51 -0700 (PDT)
Message-ID: <0200ea9a-c1e3-46fc-bb7a-d50c39b38b92@gmail.com>
Date: Wed, 19 Aug 2026 10:28:36 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Jan Beulich <jbeulich@suse.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-2-frn1furkan10@gmail.com>
 <fb107bee-6b6b-4e81-bf2d-846d8b6411b0@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <fb107bee-6b6b-4e81-bf2d-846d8b6411b0@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787124532-662A92AC-85241F94/0/0
X-purgate-type: clean
X-purgate-size: 1362



On 8/19/26 09:53, Jan Beulich wrote:
> On 19.08.2026 07:15, Furkan Caliskan wrote:
>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -745,6 +745,38 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>>  
>>      for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>      {
>> +        /*
>> +         * A vcpu slot can be missing if creation failed partway
>> +         * through. A dying domain is being torn down regardless, so
>> +         * skip the unit -- but a domain that isn't dying still needs
>> +         * every vcpu it has schedulable, so fail instead of silently
>> +         * dropping some of them.
>> +         */
>> +        bool vcpu_failed = false;
>> +
>> +        for ( unsigned int i = 0;
>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>> +        {
>> +            if ( !d->vcpu[unit_idx * gran + i] )
> 
> Is there a particular reason domain_vcpu() cannot be used here?
> 
> Jan

We still need to guard against d->max_vcpus so that out-of-bounds
indices in a partially filled unit don't get treated as missing 
vCPUs by domain_vcpu() returning NULL. 

However, domain_vcpu(unit_idx * gran + i) can be used here instead of
d->vcpu[unit_idx * gran + i]. I simply used d->vcpu[] because the rest
of the function uses it that way.

Furkan



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:30:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:30:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394754.1633414 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwakj-0001aX-Kl; Wed, 19 Aug 2026 07:30:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394754.1633414; Wed, 19 Aug 2026 07:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwakj-0001aQ-Hs; Wed, 19 Aug 2026 07:30:25 +0000
Received: by outflank-mailman (input) for mailman id 1394754;
 Wed, 19 Aug 2026 07:30:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwakj-0001aG-2k
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:30:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwaki-004zNz-FC
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:30:24 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855b87-2eae-0a2a0a5409dd-0a2a450ca74a-24
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:30:24 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855b90-f479-0a2a450c0019-d1558030e9cd-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:30:24 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-499840a2575so4967765e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:30:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa111113sm32778895e9.4.2026.08.19.00.30.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:30:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787124624; x=1787729424; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=vDXwFjdZGRE6UEogEeXgLT8E+AZZ+Pj3Tcn5HrNbF/A=;
        b=CSmV9Ax32cGGj9nzYSUkUGBFiZzs7mn6NmIm/CeqTAH5pU2/rZjT+L/QCTPzdBkvVG
         GI1iotIsCi97w2O9H/nxI+itOctpy25G8s9BHPiGnVg7bPdNXI7kjJZnEnsoeG5g1tfd
         bO28Yot+AGcXuhSib0qx5/aetI6hJRq5zTncNUW6DN/5UGcOaubuxkuTgtyYKni2hE53
         bhZcZwTzZWfhvOvLisBV8OzVgDCEgtEJCLZm4m5VE/kBU6CjEn7EZN+Kn0lAl51Cvbq5
         HbYZ2lqdJEAmviMr22KxqVtrJiqwl3ojZuyFUzP69UYDy5vMXPOvfKO6ioEiLZXWCgUj
         Bx5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787124624; x=1787729424;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=vDXwFjdZGRE6UEogEeXgLT8E+AZZ+Pj3Tcn5HrNbF/A=;
        b=nVu7XvidDqEHvpUdp6MPFLM4nILIOjkvKW38AFGnWSUmHzZWkjpigBfVty0RDuI7A8
         wmO4NFplvdnbfV80KQ9jIoJyrMp0gbDN9hSSsRPWt4KfemiGofpuCXLrD6m9FHA9UhGL
         tpAezwIV7tcb5ZYFijXZDYU7pY/y/QJWCaxtxjunsR++sLWKnZR3QAF3iPM4MsjPsiSE
         llqJ/hwN/JkdxLxUVl3WytAfHwgA7DE5PBNqKCHPv2JD3SlM4K1lRGcv2mUzuXRFH6u8
         CuGtg/s+1DwNm6Kn+YXhvvlMqpqd+xDikK/gCZyvbSvNQ/NYvjEqYJIPRi7ueoPD9MnC
         vl0A==
X-Forwarded-Encrypted: i=1; AHgh+RpQXrlz/HiWNm6iDIb1Q+bbmccIWjzxFEGEWsaVkW67CbaoYSXHTIbnxDEWg4/ZN2AbCsRgJFT1y3s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxwXm6eoA73rz7vUSa5kGLR/N/EDyOhuu+WstuwLhyWbmzgg2EU
	aP0D/GSoErMuF5CJF/5aF3VNiTAFCOh1hU+R5hR83otMWE0nspsP9ekZtyCho/Yapg==
X-Gm-Gg: AR+sD11tZF2NeTuL8OkL9fuA7uMicV+QaFVu6Tyy2nRxvesmibFRn0NEx3/Q1+A2ZrJ
	WR0ZKE6BczYPVuWqB4AYz7Xs+Q1hFcvwZRTExD59/yNvVITvOW9/yq51oZfmCcQUVxwkl0VpHgY
	7pI831LIDxiSi/P/W1dCD/9ZhOaEtfP4tHPtMOCM51YuLsw5ofYxPLEhwQJ3kDWqTEYmNhbhaBL
	zFLoJ47/1i+jMXkSXXRQacyFA99IfQ5FfHhtX9fndpIqxN8im0t7tbF7RaE38PQTdYu9bekvAyZ
	xylvJ05FuQDRgdz8lIR5hg+XAd5+AO43aj3HCCRbZlUXtVQFJ1pnw8HKsZ1b9b1lxeNJJS1AgFE
	PKAOUvRgThVb1JJz6KBzAdA14WrIlCPP2omV0Fhnu6ezsteS984K4YM4RekOMaw040KGBbYCjSb
	ouYNoGU0Y0RsQ7gXOG3v1NfNSIppJ1dzi/hCxTzvrH1qf3NAPoTyeViKQB6MnESzA1aTsL7/ymI
	krsnbsnKgdHWZxjTf1kYGpeYOIkro8/bR0cd+fPE+FiCqJFumx0
X-Received: by 2002:a05:600c:6308:b0:499:80d0:8b73 with SMTP id 5b1f17b1804b1-499aa171fd8mr42828625e9.4.1787124623716;
        Wed, 19 Aug 2026 00:30:23 -0700 (PDT)
Message-ID: <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
Date: Wed, 19 Aug 2026 09:30:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787124624-012C8A5B-DC185E10/0/0
X-purgate-type: clean
X-purgate-size: 9210

On 18.08.2026 19:15, Chuck Zmudzinski wrote:
> On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
>> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>>>> -- snip --
>>>>>>>>>>>>>> +    /*
>>>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>>>> +     *
>>>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>>>> +     */
>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>>>
>>>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>>>>
>>>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>>>>> by its DM.
>>>>>>>>>>
>>>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>>>
>>>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>>>>> guest are also assigned to its DM.
>>>>>>>>
>>>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>>>
>>>>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>>>>             DPCI_ADD_MAPPING);
>>>>>>>>
>>>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>>>
>>>>>>>> If I understand our current implementation correctly, this statement
>>>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>>>>> in hvmloader code).
>>>>>>>
>>>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>>>
>>>>>>>> I don't think this statement makes the host OpRegion
>>>>>>>> accessible to the device model, though, so I think, if I understand your
>>>>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>>>>> same kind of "layering violation."
>>>>>>>
>>>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>>>>> needed permissions to access the pages itself.
>>>>>>
>>>>>> So, are you saying it should be possible, without any patches to either Xen or
>>>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>>>
>>>>>> I think I could implement what you proposed in an earlier message and do
>>>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>>>
>>>>>>> The more correct thing to do might be for the DM to
>>>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>>>> separate question then.)
>>>>>>
>>>>>> Actually, when I was developing this patch, I tried first to do it that
>>>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>>>> host OpRegion in Qemu.
>>>>>>
>>>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>>>
>>>>> You don't ask me this question, do you?
>>>>
>>>> Are you offended I asked this question? If so, I am sorry. You make me
>>>> afraid to ask it again so I will not do so unless you permit to do so
>>>> again.
>>>
>>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>>> qemu person, and I never have been. I can't really help much there.
>>>
>>>> All I can say is that surely qemu
>>>>> has an existing way to map (host) physical memory; see e.g. how
>>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>>> (independently) there and here there's the issue of how to accomplish
>>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>>>
>>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>>> can access the MSI-X table of some device, that does not prove that
>>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>>> still stands: I still don't see proof that it is possible for Qemu
>>>> to get a pointer to the host OpRegion without any patches to the current
>>>> implementations of Xen and the Linux kernel.
>>>
>>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>>> could come up with, as that's one tiny area of qemu that I know at least
>>> a little.
>>>
>>> From a Xen perspective, this analogy should be sufficient: All you need
>>> from Xen is for it to permit to establish mappings of the underlying page.
>>> As I've pointed out when commenting on a code fragment you presented, the
>>> DM (domain) looks to have permission. Everything else is a matter of
>>> establishing such a mapping. There the MSI-X table code may also guide
>>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>>> appropriate to do things this way in qemu, and since (b) it is, as said,
>>> imo a layering violation.)
>>
>> I agree that accessing the host /dev/mem directly is cringy. I would not
>> really want to do it that way for the host OpRegion.
> 
> I looked at the current mainline Linux kernel code about access to memory using
> /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
> ordinary system RAM but allows access to what the kernel developers call
> non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
> in the Linux source code:
> 
>>  * On x86, access has to be given to the first megabyte of RAM because that
>>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>>  * and similar apps. Since they map the entire memory range, the whole range
>>  * must be allowed (for mapping), but any areas that would otherwise be
>>  * disallowed are flagged as being "zero filled" instead of rejected.
>>  * Access has to be given to non-kernel-ram areas as well, these contain the
>>  * PCI mmio resources as well as potential bios/acpi data regions.
> 
> So I think things like the MSI-X table and the OpRegion would qualify for
> /dev/men access even with CONFIG_STRICT_DEVMEM set, so after seeing this
> I expect I could get a pointer to the OpRegion running in Qemu using
> /dev/mem and mmap, as long as it is running in dom0 with root privileges.
> But as I said earlier, I agree that /dev/mem and mmap does not feel like
> the right way to do it.
> 
> So I would like to come back to something else you said in an earlier message:
> 
>> (How in turn the DM would learn of the contents of the opregion is a separate
>>  question then.)
> 
> Let me phrase the question like this: How could the DM gain access to the contents
> of the OpRegion, and for that matter, also the contents of the MSI-X table, without
> also committing a layering violation?

As said previously, I'm not a qemu person at all. Yet it's entirely a qemu
question you raise. From Xen's perspective, as also said previously, the
one prereq is there - the DM domain is permitted to access the page(s) in
question.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:35:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:35:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394763.1633422 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwapc-00028e-59; Wed, 19 Aug 2026 07:35:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394763.1633422; Wed, 19 Aug 2026 07:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwapc-00028X-2P; Wed, 19 Aug 2026 07:35:28 +0000
Received: by outflank-mailman (input) for mailman id 1394763;
 Wed, 19 Aug 2026 07:35:26 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwapa-00028R-O7
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:35:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwapa-001fLk-2h
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:35:26 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855cb8-8faa-0a2a0a5109dd-0a2a4504e232-14
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:35:26 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a855cbd-b57f-0a2a45040019-d155802ee4c7-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:35:25 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso5175675e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:35:25 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa17567asm39592365e9.10.2026.08.19.00.35.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:35:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787124925; x=1787729725; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=eX42ao3aPC8bijCBxzXtFBmm3vcAf1PsreEEOvh2qQg=;
        b=Z1wVP1yuFHndzOhCl9332Ee0wsKAwssCZ4kT7qkQAKpZz0xOC6cVhFBqMnCiNbXDN5
         hJymbMCRTSMVRFArzi+46ssveGIwHphJmOwWa7kOHTOPQHEf1c2XH7BhOGW2sr6LLxRz
         tWVAS/8Ctaqhyd9a4Hbio9CRyb2xrXLzaFN7bT14QUx2XMuUgShA8oOKuJd2cs3RSoU8
         8HD9V9/QlpAi3yQHWDkb8TOjlojBWG2WtGzWKNE9CsQz8RF8ga2kuI+7wuTY1RPZdERm
         89HkrZnbP3oFXUrCcEZ/baqZt65pXDbFlWzjGlxTDlEn8ZmwKPn+GoqUDbyYi/+ig8lN
         1qsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787124925; x=1787729725;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=eX42ao3aPC8bijCBxzXtFBmm3vcAf1PsreEEOvh2qQg=;
        b=KFLYre7hVnSuO080BwXhcpXDJc6D8aw5SmmrxgZRrEvGAW71EEbigqkLEZp1cF1fBj
         QGpgnaqEV5H6QDHabZlpxi3AODqQa049r9t0z7Xo8i+acfCcCFExLTHn+qKZ2ZPeWqRL
         NauKpF1G235MdgJadL6JB5mU6jehmca2LfEBaDK34TuRnsu9cqxsixOCrH9AvXePweUT
         L9tFGUISB8hLFZHGYlrbQeo1+W5BteNJV8YyhqA2hVHHrxj97CKUW8yONHI0Fm2UQWYr
         UR7ZX+lWh6bY9/SPLFGiu3E1FTS0V2cDVJahXZbq9PGzIvWZrkKtA7TWIFuYmqCXViQj
         sdnA==
X-Forwarded-Encrypted: i=1; AHgh+Ro+yxTfVqIIbUkgXYX0HorJxXCIwA3uBQbA26l5umpeUIeO1W5JI0zW5LvqTs0k9obzadbve5wLqTc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz75HwUMxHjsDQz0ZoARqR7OHH2K6Q5TxQ3ZsuUCLwSLdQ9wbql
	QKxsYBY2uLoIUyiabN/IGIsn5loYlwpOfg8kAGnWVRp/b5cCQVwHc4uG7kv27plGRQ==
X-Gm-Gg: AR+sD11gSjLUxVoOGaaetvLiJFqv07ngA/YAdclhsIyYvtpOSy7FT0EfkV8m2CeE3fk
	8zbdLuJqH/OUGEcDJPQmO4zwHaMeUdP8EeckFA6TCrB9YWrGLwL6ZMtcZAKO962rCnDH7xF9zbU
	nTmNLe0F0gjK47b32oycteiAxtRmwg663S0FEoQQzswhFJpgDGzyTdwslqlUPM8pBr9iu4ULrLN
	aL2ZKqmjX2P1dJFaAtMfX69CDMqC6VgVdIQLLZoLZQB7kb8rxVC8hC0L+nXFj18ka7TrrxBH2DD
	Xry1SBhT5bx3zbUUuiFkAjHlyRrVht1Psj0QR9kfC+SiAJpRw9IUCAZPxGsfQqzZ1XklFMl/2yr
	4Ky+oiCTIplFzIcoASuYGXFPKeN324k2Nk+dRjI0MdqPcdJ0svGhccwcIUQdipMIw2t1bkGZjmR
	k4vD/h7jHntyQCRQlb+mrMZTt+x5bWRaXxGyM4AKam7K3g5v0SX6Y+7ERe/mbQYZRlEtByZIWGz
	KencyDUYOD4NCYxjckalEQpsRWdxa/t7EC8LjYft86iKshiNUwv
X-Received: by 2002:a05:600c:6308:b0:499:80d0:8b73 with SMTP id 5b1f17b1804b1-499aa171fd8mr43427235e9.4.1787124925511;
        Wed, 19 Aug 2026 00:35:25 -0700 (PDT)
Message-ID: <997d00e8-912d-4835-952c-d2912b3f1aaf@suse.com>
Date: Wed, 19 Aug 2026 09:35:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-2-frn1furkan10@gmail.com>
 <fb107bee-6b6b-4e81-bf2d-846d8b6411b0@suse.com>
 <0200ea9a-c1e3-46fc-bb7a-d50c39b38b92@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <0200ea9a-c1e3-46fc-bb7a-d50c39b38b92@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787124926-C10DDB50-0B463FE0/0/0
X-purgate-type: clean
X-purgate-size: 1678

On 19.08.2026 09:28, Furkan Çalışkan wrote:
> 
> 
> On 8/19/26 09:53, Jan Beulich wrote:
>> On 19.08.2026 07:15, Furkan Caliskan wrote:
>>> --- a/xen/common/sched/core.c
>>> +++ b/xen/common/sched/core.c
>>> @@ -745,6 +745,38 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
>>>  
>>>      for ( unit_idx = 0; unit_idx < n_units; unit_idx++ )
>>>      {
>>> +        /*
>>> +         * A vcpu slot can be missing if creation failed partway
>>> +         * through. A dying domain is being torn down regardless, so
>>> +         * skip the unit -- but a domain that isn't dying still needs
>>> +         * every vcpu it has schedulable, so fail instead of silently
>>> +         * dropping some of them.
>>> +         */
>>> +        bool vcpu_failed = false;
>>> +
>>> +        for ( unsigned int i = 0;
>>> +              i < gran && unit_idx * gran + i < d->max_vcpus; i++ )
>>> +        {
>>> +            if ( !d->vcpu[unit_idx * gran + i] )
>>
>> Is there a particular reason domain_vcpu() cannot be used here?
> 
> We still need to guard against d->max_vcpus so that out-of-bounds
> indices in a partially filled unit don't get treated as missing 
> vCPUs by domain_vcpu() returning NULL. 

Ah, right - the bounds check cannot really be folded here. Then ...

> However, domain_vcpu(unit_idx * gran + i) can be used here instead of
> d->vcpu[unit_idx * gran + i]. I simply used d->vcpu[] because the rest
> of the function uses it that way.

... best wait for Jürgen to comment. Outside of the scheduler we're
trying to replace open-coding of domain_vcpu(), but inside the
scheduler things may be different.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:48:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:48:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394780.1633432 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwb1r-00040V-3J; Wed, 19 Aug 2026 07:48:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394780.1633432; Wed, 19 Aug 2026 07:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwb1q-00040O-Vv; Wed, 19 Aug 2026 07:48:06 +0000
Received: by outflank-mailman (input) for mailman id 1394780;
 Wed, 19 Aug 2026 07:48:06 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwb1p-00040I-Vk
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:48:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwb1p-00HV6h-CF
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:48:05 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a855fb2-bab6-0a2a0a5309dd-0a2a4502a734-12
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:48:05 +0200
Received: from [40.93.201.29]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a855fb3-6ca4-0a2a45020019-285dc91d9029-4
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:48:04 +0200
Received: from BL1PR13CA0167.namprd13.prod.outlook.com (2603:10b6:208:2bd::22)
 by DM6PR12MB4449.namprd12.prod.outlook.com (2603:10b6:5:2a5::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 19 Aug
 2026 07:47:59 +0000
Received: from BL02EPF00021F6F.namprd02.prod.outlook.com
 (2603:10b6:208:2bd:cafe::61) by BL1PR13CA0167.outlook.office365.com
 (2603:10b6:208:2bd::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Wed, 19
 Aug 2026 07:47:59 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 BL02EPF00021F6F.mail.protection.outlook.com (10.167.249.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Wed, 19 Aug 2026 07:47:59 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 19 Aug
 2026 02:47:59 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Wed, 19 Aug 2026 02:47:58 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iQ9nGPITrwLyhvDia8TIEVe1RQBuOaKZvaBT48EmUDCRTBpqtCS2f+cWArLoUhbaqnRSS85yT0UpKJmT7gAtDTD6k2DBsoFdh25D5OKat/waERi8G4UzTAMEWpV0mvy05oFEolcGtT1UkfQwq+k+Df8x8tUNJUAlG8dozOAffONBmZr+UsnK3VXx1SMpOxEOjK+sKoeG4EPfL/1PkxymxjBNmCD5AmV/pWiclaKX1G16XlAAyCJ726GrsA8NHZpe5CyJ2iOOuYH1kPfqBMcFHN1QFfFaZb6FTpjZR+7WLkWdebqpRtedIL+AxqufRz0DxZ3PfMu1UsIkxAT2He+cHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Jr/R1bH16Z1lchxKYimZiKXPqs5gtPksoeyzxN1bjNo=;
 b=ckMAyeM/Z7Ht+Z+XKuP020zNRiuk7Ek61El68CTyZ5Msw+pXuJv4J+C9AnerOGDDbH6ElDTaRBNnFmGSa3G1d9V+Bhj0T5M8weENojWhNxXpP5AX56ZJTMz4yBd3JsPbGegLlqRnGnakyDfjWp4Ni6ieuIErQ0YvEyx8DDwrj7+0u19AaTqWahpuYWpXR7BcVbjxNffaXUs7xX0JghFnbf8KZUl04yzPu74x0BWkMiE2IhowB4xJULrsquJjkxpfivGLbRVhtCWhKy3SPTk4AQCnvNLKQESeXfULyOpGY0XrEjnCWaKFMdRg7SSvxtuxP+v8gITmFe+lL7JRPuWffg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Jr/R1bH16Z1lchxKYimZiKXPqs5gtPksoeyzxN1bjNo=;
 b=Yj/C2jZgqKOuXI9usFTfpo3GnUGY5odfMERhm+2QKmMDQSgwOzYhomuWJnZhL5nMfWOrLmIWmDSqp0TkqHR50JqznYxxqeoJZnZqu9ieJOZpPNQmgWxi7Rvb2fh+qG6rmI2n3SsRreWY3VZMUAjOQgSMRI83IHZCqhU2uGy3lu4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <bb5a2a10-39ae-429f-a414-631b89d0bc89@amd.com>
Date: Wed, 19 Aug 2026 09:47:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
To: Bertrand Marquis <bertrand.marquis@arm.com>,
	<xen-devel@lists.xenproject.org>
CC: Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Jens Wiklander
	<jenswi@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>
References: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF00021F6F:EE_|DM6PR12MB4449:EE_
X-MS-Office365-Filtering-Correlation-Id: 47a19d2e-71ec-4f0a-7889-08defdc630ca
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|23010399003|36860700016|376014|18002099003|22082099003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	tN6QHwM8e2q8jba0YrU0XfxNBXx6yk+m9rQut29DsHwtAi0ji6UwwgALHpO0KXlNivdFNRhm7ryCb6cQpo2zn1Bj6Ym459xD1CALyzM33e4WdzGXe/hbuPqk/y1UbhnG9CJX/GnoajQ+i+MgXHAuP+vRqur8G6gaZvRZbXJkY9hPDRqd+42TQhF26/wFRpHOb+Eo7VwGYee6dG1fYAMNh8WhoH/mssR/JEGZGT6b8xiXZl5UYuA/+uWVvYwoEsuSxZIGzt3DWwSQIjpJPQhXUNM7o4SxblssnqWCjVDOk89K1N3r+xfGmi0GJ1MMmRrzHdF504p/LJD2KlM1WZq3KTCXxZWf0BIvyuRkzpclvA4kCQ04hwSZVm3BgcGFX7E4LpG2idXD3GJMTzt1jkd0hVdMtCbZEKQhHUkht06v1SijEMggjR/zUx6zBitgAudONqfneNNnrmLhe0yhBJzsr2kqPT33sDuIPP0yTTwu7GQES7zAvijOgDpp2cQPA3NNSwlksn358q0Mq/QQ8OHTV7miEtjzqq4vUiZuOoRX7IFUo/DOxYrZ6VdY5Q6wJX1KPKEpKm7JRu2851jbTnkFCG82bMtJdG2IPyKB5icEEmSVQAxS1/5ofLTRpA1VVHct6Ol6B/sV9LEFcYSuciV2/Yv++FpreHzBiXjDtOITg4imLE6SarUFAEyfETatyFFT/hpcC6Hv+bLdP8MM2a3L0w==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(23010399003)(36860700016)(376014)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Eq/z1jH6ugaP97fFpDEMb2ocgnWnQX6nn5OvmUg6j7FS4sIYoMgJnUW3g8X+iPAF2CHok8AhKXSfw7QyqJLYjPfnaJsp1g43kdr/VG98+clfw/3/MLLb3oH/BBnQssyKpyv/fH7GzoG/sPKpz7nFYbQJtbBmxVFpM6kI+hqeRVthvSQdu2XzJxK6RNRYAWMoTFp/h0bls9yBEfc9t2cfgTnf8nG6u4niiLKZi2w9+p8Xj4yjHACnHMxuKhuJJBigX+0zdyCZZvb67pnKtUPw6tFihstlRiz6Bon11uh75curz++xyjTjCAlxexRchmVSPwwZlVQ2FM0tl9Doc8vTFA2i7PuecMmo+FBa0rGC1AMsMXNtDxSq9bPk+hWREsbOjRxjAy/I2SSlouAxKEfGoi+Bt/Wk5qFOpZz9Oc6FyBJtI2LMSl/iAB3FwP0j59ur
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 07:47:59.6687
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 47a19d2e-71ec-4f0a-7889-08defdc630ca
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF00021F6F.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4449
X-purgate-ID: tlsNG-720697/1787125685-319CB2AC-8B26068D/0/0
X-purgate-type: clean
X-purgate-size: 2285



On 18-Aug-26 14:16, Bertrand Marquis wrote:
> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
> possible vulnerability.
> 
> ffa_handle_msg_send2() copies the message header from the guest-writable
> TX buffer before validating and using its fields. A plain structure copy
> does not prevent the compiler from re-deriving later field accesses from
> the live TX mapping.
> 
> For VM-to-VM messages, msg_offset and msg_size are validated against the
> source and destination buffers, then used to copy the payload. If a
> sibling vCPU changes the header and the compiler reloads either field,
> the checked and used values can differ. This can cause an out-of-bounds
> read from the sender's TX buffer or an out-of-bounds write into the
> receiver's RX buffer.
> 
> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
> default. The audit ranks the likelihood of such a reload as low, but the
> C semantics do not guarantee that later accesses use the stack copy.
> 
> Add a compiler barrier immediately after copying the header so that
> validation and use consume the same snapshot.
> 
> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
>  xen/arch/arm/tee/ffa_msg.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
> index 1eadc62870f2..39f561c8237f 100644
> --- a/xen/arch/arm/tee/ffa_msg.c
> +++ b/xen/arch/arm/tee/ffa_msg.c
> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
>  
>      /* create a copy of the message header */
>      memcpy(&src_msg, tx_buf, sizeof(src_msg));
> +    /*
> +     * Make sure that "tx_buf" which is shared with the guest isn't accessed
> +     * again after this point.
This is a bit misleading because it *is* accessed in ffa_msg_send2_vm. The
comment should say what you wrote as the last paragraph in the commit msg.

With that:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:52:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:52:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394792.1633441 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwb62-0005ZZ-Lc; Wed, 19 Aug 2026 07:52:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394792.1633441; Wed, 19 Aug 2026 07:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwb62-0005ZS-Hg; Wed, 19 Aug 2026 07:52:26 +0000
Received: by outflank-mailman (input) for mailman id 1394792;
 Wed, 19 Aug 2026 07:52:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwb61-0005ZM-Lc
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:52:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwb60-00BJki-Gd
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:52:24 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8560b1-e002-0a2a0a5209dd-0a2a4502cefc-28
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:52:24 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8560b8-6ca4-0a2a45020019-d1558034b141-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:52:24 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-499ae1c6471so477865e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:52:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0d6a84sm38904575e9.10.2026.08.19.00.52.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:52:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787125944; x=1787730744; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=6Nl+LoQuvaTo57INmOcUA55t6MJUqdmCvn37eHHwtcM=;
        b=KXdXz+knFq2Q68LDkkF0qKrCZaAwXZGHc3rdRcdTY1PTlIMqXFXJdrr1sIaDvMAojX
         kXBZozG8W0uVHlONmzNdxqzsL4Qn+lNdPSozj0xRxZirukjq3Kt4ExuKl/BOSJWNZpqy
         mucd5M9nS0A5tLcz//iy/Q3MuL3l6i/uPafrZ6l4Y9Qw1WJKO1Lth9iX+H/iHYJCri1Z
         KPCmXDojtRL4JUFmlV0XzY6QoezywcgWpDBvNwaXeu6vLd0fppGz9mknQ8aTpca61nFQ
         fiw84i0yoHHtV+fsvfiYMPIJF2AM9rBixehiLSQkIQgx/aTZYyuXj0bgQJB79S+HQ+rf
         jCoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787125944; x=1787730744;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=6Nl+LoQuvaTo57INmOcUA55t6MJUqdmCvn37eHHwtcM=;
        b=hbutDkgoTCxisF3ES2auID0wHEtJAajpqnCuu4xo0hOKc2W3uZT1zeHB3au0FMuYyE
         UTvg3HyT0o8G/jvRjHVKDjPH0LhXKGAqcv1gn+5ZgY+TRZKlyt+cQCHTD5oili1BCYaF
         kY3gIjVvEL80zXGS35vV81o3oKyl2/KA0WArRzOPtrkadTU/bJd0hng1jmJz7erhaNL3
         r4rQhZH1q1Mvo8X6YTTv7RKprb5ojGD1rdbd9jmKoV5rIXU7sjJkATtVy1iGNaiffeVa
         Exg7Thnz/vFaKPVK9IEGvcaHQdvwu3VkCjMzxaqBgggjby8EWq7yfOypuy5UnOoxiU91
         2XQw==
X-Gm-Message-State: AOJu0YwtEW0VDipVpujKBaEJE2ban55MS9Le8EC5X/pdRD/S2FYqqXtK
	ywWEXWfF1niUxDD+nT571s0KtH1pq52sFsPprvwIwYB3ZvS6lnBQ9q/Ly5mTh4dUZg==
X-Gm-Gg: AR+sD13IUO47XSnDmpRd8tZw5xB7/fxQMx8JFM1T3Ws77jFwn6fpLKyk+qiSXi0H1ik
	FgayeHiCqaEHEs+DRnzULQxXykbtYVPios9ZdVzmR2o1ETPH/8DwEQh5fgCrWVuwHMF2Q/XqDKG
	+5MaUhG58qpCLcVyprTKUVVCf9fsTtKsMXJHddLUg7kzEeUlJj8TiEGVmlBNJyPC3m46lqsnItO
	5UF125XvX08ZfwZm/Sl99x6B9hVsAh9b9amHX9n8YSoh4sex5vTm8KsN1va9/t1nPEdaLJKi4B/
	imUMRDVtCv300Y+tOSbXalrQvgU0fdK3gMF/TufJ81CRnhkWpg35etihFaUyFyzj1c1G2mk9/3M
	eRooI3Lsyuia9mPE70iRd5w7zIwTvae3DuLAcpDpSFnQaEjJ0UmXkjws3Ky4bdSLPj33Tj+E7gm
	WZTMs8OKu2NUaFRofL5xXOTG5Nz3vIVPHMVGaZGFXYkkxWIew38W2Kh0pu4xwcoN0n1rbABBaEt
	Cx0R6pfhyasP+J2ncMMOXi9EFJ+gi+Hsc8nJkgj33Jgw8xIeqHG
X-Received: by 2002:a05:600c:3f12:b0:499:8174:9f39 with SMTP id 5b1f17b1804b1-499aa0dd282mr47257335e9.0.1787125943751;
        Wed, 19 Aug 2026 00:52:23 -0700 (PDT)
Message-ID: <83abdfca-70f3-479d-b7ed-929567c4254d@suse.com>
Date: Wed, 19 Aug 2026 09:52:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [BUG] Linux kernel crash in amd_smn_init during PVH Dom0 boot on
 AMD EPYC
To: Arthur Borsboom <arthurborsboom@gmail.com>
Cc: xen-devel@lists.xenproject.org
References: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
 <4a1b5392-93b9-4b9e-bf65-3fb280f385fa@suse.com>
 <CALUcmU=QNXA8gs8JYy01tLVOH-y8mjZM-GxKzOCoA_3e2QFVwQ@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CALUcmU=QNXA8gs8JYy01tLVOH-y8mjZM-GxKzOCoA_3e2QFVwQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787125944-66AB52AC-939F12B0/0/0
X-purgate-type: clean
X-purgate-size: 2158

On 19.08.2026 09:09, Arthur Borsboom wrote:
>> Well, a pretty natural question: What amount of research have you done yourself?
> 
> Lovely response. You really know how to motivate people and welcome
> them into a community.
> 
> It has taken me about 1,5 day of work to find out why the screen
> remained black, to determine where the problem was, how to retrieve
> potential info by a serial-over-LAN console, subscribe to the mailing
> list, and create this bug report to help.
> 
> But don't worry, I won't do any debugging anymore for the Xen project,
> you have made sure of that. No need to respond.

Well, no, I can't really skip responding here. Yes, there was a risk that
you may take my reply as "not welcoming". Yet please can you try to see
both sides of the medal? From your initial report, which effectively
wasn't much more than the dumping of a log with the traces of a crash,
how could anyone have concluded how little or much work it was for you to
get there. As much as you have felt offended by my reply, I consider such
reports as an abuse as well: This is xen-devel@, not xen-users@, and I
think it is only fair for us to expect that reporters check whether their
problem was reported before, and whether therefore a fix already exists.

In fact, looking back - you did identify the earlier report. I clearly
scrolled down too quickly, and I'm sorry for that. The question then is,
though: What did you expect from re-reporting the issue to xen-devel@?
A patch for the issue is in flight, yet that patch to be taken is
nothing any of the Xen developers really have much control over: It's
not Xen interfacing code in Linux which is affected. So I continue to
have the feeling that this wasn't helpful at all, and my putting time
into finding the (apparently) most recent variant of the pending fix was
not valued / pointless, as I ended up offending you be a non-technical
aspect of my reply.

As a result I wonder: Would it have left you with better feelings if
your mail was left entirely unresponded to (as would end up reasonably
likely, according to my observations over many years)?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 07:54:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 07:54:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394801.1633449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwb7X-00063C-U0; Wed, 19 Aug 2026 07:53:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394801.1633449; Wed, 19 Aug 2026 07:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwb7X-000635-RL; Wed, 19 Aug 2026 07:53:59 +0000
Received: by outflank-mailman (input) for mailman id 1394801;
 Wed, 19 Aug 2026 07:53:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwb7V-00062z-Te
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 07:53:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwb7V-00HWPc-AU
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:53:57 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8560ff-2eae-0a2a0a5409dd-0a2a450a8420-38
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:53:57 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a856115-f2d2-0a2a450a0019-d155dd34ddab-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:53:57 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-482938466a7so550969f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 00:53:57 -0700 (PDT)
Received: from [192.168.1.109] ([78.173.117.23])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e784b3sm35843335e9.3.2026.08.19.00.53.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 00:53:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787126037; x=1787730837; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=4CJXLd/U91yXXqh2bashFWZ0DcoUxn4q8GKZFtPXLq0=;
        b=hPU8Gz0HPmKme4wkQ1wpwe02cKGnXTnnhU0dc5GHMVFhXXdY5RC79v0dQkj21Gow7Q
         Kl8w6d56zowfk0nhUC27m3fqJwJc0MT2gn4uKo4E4YKmKgyAH315YZPddn02LY2mUYc/
         set5NFnHJVAmXYwvicxnQzkoly1PN8smSLZIDRD/mhJqIPs9EpqUEjLzcle8dyxRKmkY
         yOkEXkg2zjuonOTLhurUt5+T768IU2KAFczP4/T+YhX0lcN6Clx2hyR1oLD+RnNyQjnk
         e+SwthoLbbVqzfBdeskn4Jc3FIOuvey57WJ4bKbTC81YeVPmbLf9arjjTDoHGEElsok1
         ZL8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787126037; x=1787730837;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=4CJXLd/U91yXXqh2bashFWZ0DcoUxn4q8GKZFtPXLq0=;
        b=Uq7UFQMPBbvjmEGVAL0zeyTZor8pyqoWPTVVFvJeocJ5MBtu4OzyJC2a7A99USwS93
         BdiNvqOTwr9CJ01UB8Q9wojUEnVI618t48q8CraRQP73tcpvpH3znsBSf89kt5oX7LMH
         XdgIBYEEDaQPTglSpxtQeyFbeenl218yt3qzsu3/W/ttY0Md9ktJXam6kQiYYEb58Au0
         ouGWCKch2fJNypCq04LHSTFLLj2HW6Yf+rZ6NaVsDoWJuwP2I45cRD+VwN6KCADbI/ny
         ifAiTRpTDZsql3aj6hvMHndszpNARPcOSfTyMDtpIYH4Xebl/74r+DaPCeZ2wMUveXtF
         ybYA==
X-Forwarded-Encrypted: i=1; AHgh+RpwW5fHEAtnY/0tnmrc+T4+V2IynCHPWQtd/1ko0qPtsZM66oJ9mCQ69FgHCoUrcM7GJJiQ8qkzIVk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy57HbyxXHfGgjObuhU7CgqYSXeTbSId0A+QA5HzHWUkAPU93BO
	k57+oZ4MK/jYhDCafiRDd03JEMtgscKR80gw7oXw3j+gNHjrsjTAqrGD
X-Gm-Gg: AR+sD12vMLhSgMp15d90yWyTVrEBk2sjETnOD4ENSUKhVlbpBncQr/mEBzM72FymuCb
	VqZ3SL6HzhJWeOHKgpr9NIXeUXLatjAdX7LL7Qwumbk3+PGGjzlG9pUGqDCxBTj8OI4+n5bG7Ks
	fHDwmLJJndNW5zSqyM07ujdcgQMKzCJEBE20LXhC/sj4S7I8p/F33+inhQPMfLVcMYgqHSyhR2T
	nrqPqh+ovgP+47Hc11cxe7h8GI2E8asM3JFqUJS8kEk7qAGAP6Wgzrcqlr0R4SO4JjrviHCaZEA
	3TkQXc4B93wSlxfJeV6dS+llFYfTSZyKs5/WDDEZJSJerkC65nsITMfYnxGajifcu/hXebLpBzc
	hxJqgwiP4ypH2VLTiq0JcTfWJp9gIhUgtByClvAXs+qRJQg6PzGc/WABu9n2kpM3l5WHsa3dl7i
	2nkCYhS7MHUBA16qShoqAvAoas1QYKERIMThmW+hGRninFrsSkbwgUSWSt79qg4OpYXm0=
X-Received: by 2002:a05:600c:c170:b0:499:86ce:465e with SMTP id 5b1f17b1804b1-499aa15d8dcmr49130935e9.4.1787126036561;
        Wed, 19 Aug 2026 00:53:56 -0700 (PDT)
Message-ID: <50005702-c719-4ba9-92f7-4d5a0dc3e0b8@gmail.com>
Date: Wed, 19 Aug 2026 10:53:49 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Jan Beulich <jbeulich@suse.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787126037-51AC4CFC-2A265EF1/0/0
X-purgate-type: clean
X-purgate-size: 3604



On 8/19/26 10:22, Jan Beulich wrote:
> On 19.08.2026 07:15, Furkan Caliskan wrote:
>> sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
>> singleshot_timer and poll_timer before it can fail -- these
>> become live, linked into their target pCPU's per-cpu timer list
>> regardless of what happens next. If the sched_alloc_udata() call
>> further down then fails, the function frees the sched_unit via
>> sched_free_unit() and returns 1, but never unlinks these three
>> timers.
>>
>> The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
>> returning nonzero it jumps to fail_wq, skipping fail_sched and
>> thus sched_destroy_vcpu() -- the only function on this path that
>> calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
>> and the three timers embedded in it, while they are still linked
>> into that shared list.
>>
>> This silently corrupts that list. It only shows up later, when
>> something else touches a neighboring timer: sched_move_domain()
>> crashed with "Assertion 'entry->prev->next == entry' failed" on a
>> completely unrelated, valid vcpu's timer.
>>
>> Kill all three timers in sched_init_vcpu()'s own failure branch,
>> so it doesn't depend on the caller reaching sched_destroy_vcpu()
>> to undo what it set up itself.
>>
>> Fixes: 1ad5dad74cde ("[XEN] Re-jig VCPU initialisation -- VMX init requires generic VCPU")
> 
> How did you arrive at this commit? It doesn't even touch sched_init_vcpu().
> All it does is move kill_timer() invocations around. I think it's
> d884b1077817, as that's where the "return SCHED_OP(init_vcpu, v)" was
> introduced (i.e. where kill_timer() would have been necessary to call in
> the error case). (I can't exclude the issue was pre-existing already at
> that time, but that would require more analysis than I think is worth to
> invest.)

Commit 1ad5dad74cde moved kill_timer() calls into sched_destroy_vcpu() 
function, which is not called if sched_init_vcpu() fails. 
Before that commit, kill_timer() calls were in sched_destroy_domain(), 
which is called if sched_init_vcpu() returns non-zero to its caller, 
alloc_vcpu(). 

        for ( i = 0; i < max; i++ )
        {
            if ( d->vcpu[i] != NULL )
                continue;

            cpu = (i == 0) ?
                default_vcpu0_location() :
                (d->vcpu[i-1]->processor + 1) % num_online_cpus();

            if ( alloc_vcpu(d, i, cpu) == NULL )
                goto maxvcpu_out;
        }

        ret = 0;

    maxvcpu_out:
        domain_unpause(d);
        put_domain(d);
    }
    break;

put_domain() calls domain_destroy(), which then calls free_domain(), 
which ultimately calls sched_destroy_domain().

> 
>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
>>      unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
>>      if ( unit->priv == NULL )
>>      {
>> +        kill_timer(&v->periodic_timer);
>> +        kill_timer(&v->singleshot_timer);
>> +        kill_timer(&v->poll_timer);
>>          sched_free_unit(unit, v);
>>          rcu_read_unlock(&sched_res_rculock);
>>          return 1;
> 
> This almost, but not quite open-codes sched_destroy_vcpu(). Would be nice
> if the cleanup logic was shared. The sched_free_unit() call there could be
> leveraged here as well; what would need skipping are the sched_free_udata()
> and sched_remove_unit(). And of course the RCU-locking would need sorting.
> 
> Jan

Furkan



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 08:02:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 08:02:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394827.1633459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbFs-0008UF-5P; Wed, 19 Aug 2026 08:02:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394827.1633459; Wed, 19 Aug 2026 08:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbFs-0008U8-2Y; Wed, 19 Aug 2026 08:02:36 +0000
Received: by outflank-mailman (input) for mailman id 1394827;
 Wed, 19 Aug 2026 08:02:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Bertrand.Marquis@arm.com>) id 1wwbFq-0008U2-Hn
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:02:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbFp-008bHd-Ua
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:02:33 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a85630c-2eae-0a2a0a5409dd-0a2a4501db20-34
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:02:30 +0200
Received: from [52.101.65.13]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a856316-5984-0a2a45010019-3465410df103-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:02:30 +0200
Received: from AM8P189CA0015.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:218::20)
 by PAWPR08MB11414.eurprd08.prod.outlook.com (2603:10a6:102:512::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Wed, 19 Aug
 2026 08:02:28 +0000
Received: from AM3PEPF0000A78F.eurprd04.prod.outlook.com
 (2603:10a6:20b:218:cafe::4f) by AM8P189CA0015.outlook.office365.com
 (2603:10a6:20b:218::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Wed, 19
 Aug 2026 08:02:27 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM3PEPF0000A78F.mail.protection.outlook.com (10.167.16.118) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Wed, 19 Aug 2026 08:02:26 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13)
 by GVXPR08MB10429.eurprd08.prod.outlook.com (2603:10a6:150:151::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 08:01:48 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 08:01:48 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=r/LOhEzb+IhYoXaZKJWvMJXaottc9NvrB2mq8gpnoZnTegzKK3ClzoCnJ61g+YWfgVHepli193p7aLmREQYRFm9R48XT6ususuvmhWFZfu7jVVMs/9WQc83WP2R9xF6asj68vhw3F4tmM5lB4iRzEHDwOG2WuDaJFVK8+iiPuYq8iWX/Xw6VR8pw5lwF0WVpBDIn8XosGzvDDsdOYJpgCtENZ42H74PF/f42k/EjVmEv0Wredb48oIKBWI4R2wKS7W4r1c93EHQJ3XNSBeEZGW9jM+80mGSN/+onLWRskp8IvL+a0tEe9j2dQJvGhq7WDB3BzRsR4uux7orDkhjiiw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rr6gOfc2p/SnwVCX8TubUZatbnbQUnYhhWS+pBnid70=;
 b=dxV0vlVE4293FUNt8OjwKMW/QjC+XTqBf9gC8AaCZZ76o6nNRE9cJve6MNGUhQrFKMtIx7BqCnNKMaU80gq1lVGXCCoILghrtEYr0MmqC1mAn76YX87f7RkDT2tbJj9jv0dM43PKTi3KnHzeh2cADonU7Jx29BkRJWzDeJ+hH8m+ptMIS4k+VgLiBTxaD0LVVjaCNQjjz1JFwvS7bThYJKPe/3OlihTYLegrJj5B45lmlPZUE5wc2bxzkitnAwXW5KZzHKlK/S+sV50o3S6amjenHaVR3ZkqehJ3CmFbJbymG/7NLpkjaC2Ft2DeykJbRndZ9PW06QCOKSMiNQIbvA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rr6gOfc2p/SnwVCX8TubUZatbnbQUnYhhWS+pBnid70=;
 b=Y2iee92l5e4UyBeFDe8INMflonMZww5gSN2jsjZB+qRySv2zal2Uxu8+vdWpGFj4M/r3p1m0jFBf/fcPqqiLj8W8xx0NtUhBmZX8snLqMYBcN+p8gtheBNk8XiA+H0WWWVVtHN8m4kHTFsR/q63dibOq0694mthkUeSrzJDLApY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=A0K9MhumRtmknmDpDIVzyJuMyQT8Z3ZxCpZaFSGtwAzohXgpcftWx/saD1HdY6Z0R3Kg3WwSGcdIjpciica8KNtMttSXqDqbzhWSmLsWlPMVtdOBlmTakBjv0Ngjp5JfcOJPG1XYmoqKr9jnoUHPesk8B8/A2wkDMpI4sTwner+rFOdHbOzv6vT4pc/BuV18hXVMl7G/xNJYDlDQcxOIkJPb3Q0DCqSY5NamHGqJyMF2JISDAFs7ju4Sbgt+hmrHW1ojR7ajlKzIPZ/Hd1rLTB8WcpofxDAh1cy8JKy/MV4sj8LuNMegr6Jb57qZWFNGwU2UupKz76+g5Bf7K+DT3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rr6gOfc2p/SnwVCX8TubUZatbnbQUnYhhWS+pBnid70=;
 b=kLaedVi7CYnL34TltVsk5gDqUPa2CgFLfSmOjYOR87vuuCmhgiy1kP3cFdqKJA894Xg4Wdt36WGfS0zrvYBLz/WqA+hTXEzWZJ1CHR0muMnIW/clm6V8ubCyxxHfXX6APbdrmjJ6gaoTbjfulmGkVcpe0X1kpSMrDS3VtKVj4JKAkH19IkJNhpnPFfUI50ENw1lNPYcQlf59Av2xdPIMhv2+ZX4pIZBaicgrokbPQpr6O1Hx8YjaIquMfDd1bI6MO0Wv64A+BMG0fkAbFz+S529o2ylPyBEHbVCjuLwahTryD2WElhgE2BIVYNHj2iDNsGL+IUYUObK4xe82bvbz8w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rr6gOfc2p/SnwVCX8TubUZatbnbQUnYhhWS+pBnid70=;
 b=Y2iee92l5e4UyBeFDe8INMflonMZww5gSN2jsjZB+qRySv2zal2Uxu8+vdWpGFj4M/r3p1m0jFBf/fcPqqiLj8W8xx0NtUhBmZX8snLqMYBcN+p8gtheBNk8XiA+H0WWWVVtHN8m4kHTFsR/q63dibOq0694mthkUeSrzJDLApY=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: "Orzel, Michal" <Michal.Orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Jens Wiklander
	<jenswi@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Topic: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Index: AQHdLwt9ezGusG27iE6LBf89mJZswbak//uAgAAD2IA=
Date: Wed, 19 Aug 2026 08:01:48 +0000
Message-ID: <59299B15-47CD-46AA-890F-E8991F41C01B@arm.com>
References:
 <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <bb5a2a10-39ae-429f-a414-631b89d0bc89@amd.com>
In-Reply-To: <bb5a2a10-39ae-429f-a414-631b89d0bc89@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3864.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PR3PR08MB5593:EE_|GVXPR08MB10429:EE_|AM3PEPF0000A78F:EE_|PAWPR08MB11414:EE_
X-MS-Office365-Filtering-Correlation-Id: 6a7d471d-a21f-466c-634c-08defdc835bf
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|10067099003|56012099006|18002099003|22082099003|11063799006|4143699003|38070700021;
X-Microsoft-Antispam-Message-Info-Original:
 GRlcB9k7GamiwhX2WXLC8ifsrDcoJ9KExePWAj/ZJalTOAqCvuZw1l5+fTkfheJa2FzxrOVnZXFwDJWcscZMqS/AER4RGXunXZXIOZbHWphL+7vHl4HzvqNdhEPoY0hUSxJDbY1Q6rR/Gr+qJeArKQqQT4RtyMrVn/laM9j1zWNXdONTv+hGWFVciajWYeWjAuYNDlWopqP+WRUR58XErmRMdB1KrWQ6R9AUDAVeRnZSvKRuE69EadZnfZnqP3DbSTQK0WWus7oNDWN+6HNza1X+gkYnWpIgz32Y/7+jayYvvag+atCmXRi2g775FtWuTPtlt3KaE63F1a0Hkx2tR7tTT/cpQLLi3EJby8zJFmF7CkijvRrGxqN17u8X5y0L+pbjPuPK1QOqdsgFXptQRvo0g/zCgFN6z6sR1cnm+ifP131qHSxGYeuRDzkr354dfZrhbU0OJg5qifANGhDtRfkQuUo3KDgHI29UgFGmLWfptguhan4wdqcecyOgDbsQt4nxR7rhYIBnIEAi1ASGD76bk2m48zlF7cTCHi6g371+ttck/yL929868vFX3sjVbueZyn0JVlWMx9WmmmYDeOnZiinxy4QZCyHOC3t4RwWPwngoxHHqU2F0ZR9id2JP6Nm5lyRUQ9UyqPkDggR/6m+M7auQjlkG15+ZRIuB2KPLeE6KYf2tKco1jNjmmE7QbpfQNKy0TEo6eMsGDNf9s/YXH/+lcFLuIP2XxlQzUSQ=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(10067099003)(56012099006)(18002099003)(22082099003)(11063799006)(4143699003)(38070700021);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <679FCBF2931219469C9DA9C18938CFC8@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Exchange-RoutingPolicyChecked:
 AjMYy3YHU4i/bVLHFFl+R2J695xxb4HELfW19ckfKyD/Iv2RhS3rjYQkqz8gIrmMp7NEXGsvH6zbdT5QeafhmxaqBx1INVBiFIvCeiGuQeIotV0Lo68a53z+LiLb+JwJeubanNWKxdRE9/Thf7B6/+tGffg8rarF4DXeVnh+woVR8LM/A/Wspay06R4DgmlxnJ53pPpotQKI8LS0DX3FCEQVRyu9GU8wZEKQSH1iZQ9SiCwva+skCspb1j2vu2h0anpNJW2BdenOvS9pyX71pFTxQFaGX5QeIQgiPkXHN1YidKMbvWOudhMhgMzSHN6yWdNFDw61gI3qW9xnx85/ug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB10429
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF0000A78F.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	51e8a0f0-fc4a-42b5-ee82-08defdc81ea3
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|36860700016|35042699022|23010399003|1800799024|376014|82310400026|56012099006|10067099003|11063799006|4143699003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	Vfb2qd8n0xwIkbDypPJ2iY8BN6lJ5SEVRwWe8I9PxN7OVSathhx5g5c7KkJ02PzqQcntEAD1BIKBsIuhwZz7HyFTt4RSBBFL4Jgk2RrM6pCuNPQ1T2tVMm1HDtJ86ZQFkYczTc5MBE3rSTTjluMta1+C00pr3E5/vyYv2aZgGsarB64RibWqDzxCqivRxeIsfwlSDymW04rWKJSuCJdIZgmiOOaqkv6PEDtJnV/5REkNl1Sq/UcDDKud6/h+DtYm2iY2e7bjwmk7ZWpfo/LeaRo3SMke5KF+X7Iztme9/IO/QfltIab/oJvP4dBsCV+AlcXk6/IqBZ8TCDm4LnvfE9ZbIeuR5BSdrr7mDIFHdgjiLJrsPvRu+GbJfJBR0bfl2nOxpyfNxNJhoiBtQT9CLZAWLq1mP+wrZ36+rao0tlkHbjjdT1YuAgUekNfq+opTWGnye9m4VrQ5trz7Vrgbckr2Fc7SoLAoaLsBs9pjVzTH3C2HJOLCrbZKSuuhAg0Ac1sEj+DDh5+9A6VVvmd7Y0UyNLJLLHkEPyRn63m+u7aOs6mYvylmG/pMz9lZwb+K50u9eKEIPF4GJLpifz/GZVjQOpuO5WPAq3krjdr75Avf8kvZCBCbUNnHyoZ8Kt7vSN1d1OrGIoFZQ3PhxSNCF9vL2TdOROtYfe01zeHsFKbKZ2Nil+qlKwyh1FxdjUX24Un4wNKdRkF0cQN4uhcpww==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(36860700016)(35042699022)(23010399003)(1800799024)(376014)(82310400026)(56012099006)(10067099003)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	QyORKWNpmUkzHUPMn4NUGYZw1DAU5QnAe9Ne2db/M9Y7x3Rtr7z/kqh7496xJrjpP6/QjCPe5vOhJueFu4QqcnhoYmxfrd0scSsdv62Yf1FuwUyXIMScnecLRERn7lHRnpMC9eRmKk99EPC2tphOKQkEm02LuJeS9vD/a4j8yS6uOsjUQkkcHNfYtgmO72Du5u7YofgU81zpld6UP8hBHwYFkHqj5xyFkPf7ecq1pEiVelA1BBU05fUdEdYaRplxHyOgprUbqW0/1ZHMdJ18exYSlOo8t0Hd1NKc8v4XvhPQ/OL/e4d7rQaB5aB0gR6QNZx0ALWG3EhDq8RNz2/gEKXMHgdkgOjHHOx0fqb/ZstMag+juKazN7Ih9tnzFSsa2K/oif+PuMLOpN9ox9X8xYNAJeUWM4y0txJ02yWnRPNB+yHES6OkaXBGHKu8zz7A
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 08:02:26.9306
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a7d471d-a21f-466c-634c-08defdc835bf
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM3PEPF0000A78F.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11414
X-purgate-ID: tlsNG-d62444/1787126550-BD67C757-ACAC41BA/0/0
X-purgate-type: clean
X-purgate-size: 2711

Hi Michal,

> On 19 Aug 2026, at 09:47, Orzel, Michal <Michal.Orzel@amd.com> wrote:
>=20
>=20
>=20
> On 18-Aug-26 14:16, Bertrand Marquis wrote:
>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>> possible vulnerability.
>>=20
>> ffa_handle_msg_send2() copies the message header from the guest-writable
>> TX buffer before validating and using its fields. A plain structure copy
>> does not prevent the compiler from re-deriving later field accesses from
>> the live TX mapping.
>>=20
>> For VM-to-VM messages, msg_offset and msg_size are validated against the
>> source and destination buffers, then used to copy the payload. If a
>> sibling vCPU changes the header and the compiler reloads either field,
>> the checked and used values can differ. This can cause an out-of-bounds
>> read from the sender's TX buffer or an out-of-bounds write into the
>> receiver's RX buffer.
>>=20
>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
>> default. The audit ranks the likelihood of such a reload as low, but the
>> C semantics do not guarantee that later accesses use the stack copy.
>>=20
>> Add a compiler barrier immediately after copying the header so that
>> validation and use consume the same snapshot.
>>=20
>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/obse=
rver-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx=
-buffers-ffa_shmc-ffa_msgc
>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>> ---
>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>=20
>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>> index 1eadc62870f2..39f561c8237f 100644
>> --- a/xen/arch/arm/tee/ffa_msg.c
>> +++ b/xen/arch/arm/tee/ffa_msg.c
>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *=
regs)
>>=20
>>     /* create a copy of the message header */
>>     memcpy(&src_msg, tx_buf, sizeof(src_msg));
>> +    /*
>> +     * Make sure that "tx_buf" which is shared with the guest isn't acc=
essed
>> +     * again after this point.
> This is a bit misleading because it *is* accessed in ffa_msg_send2_vm. Th=
e
> comment should say what you wrote as the last paragraph in the commit msg=
.

Yes, this should be something around:
Ensure validation and use of the message header use the same snapshot.

Do you agree ?

>=20
> With that:
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
>=20

Thanks.

Could that be fixed on commit or do you want me to send a v2 ?

Cheers
Bertrand

> ~Michal
>=20



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 08:11:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 08:11:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394840.1633469 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbOA-0002H1-45; Wed, 19 Aug 2026 08:11:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394840.1633469; Wed, 19 Aug 2026 08:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbO9-0002Gu-VE; Wed, 19 Aug 2026 08:11:09 +0000
Received: by outflank-mailman (input) for mailman id 1394840;
 Wed, 19 Aug 2026 08:11:08 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwbO8-0002Go-I3
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:11:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbO7-00Fhfi-V8
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:11:07 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a85651b-2eae-0a2a0a5409dd-0a2a450c8930-2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:11:07 +0200
Received: from [52.101.61.14]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a85650a-f479-0a2a450c0019-34653d0e4699-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:10:52 +0200
Received: from CH2PR08CA0029.namprd08.prod.outlook.com (2603:10b6:610:5a::39)
 by LV8PR12MB9690.namprd12.prod.outlook.com (2603:10b6:408:296::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 08:09:25 +0000
Received: from CH1PEPF0000AD80.namprd04.prod.outlook.com
 (2603:10b6:610:5a:cafe::68) by CH2PR08CA0029.outlook.office365.com
 (2603:10b6:610:5a::39) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Wed,
 19 Aug 2026 08:09:25 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CH1PEPF0000AD80.mail.protection.outlook.com (10.167.244.90) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Wed, 19 Aug 2026 08:09:24 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 19 Aug
 2026 03:09:24 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Wed, 19 Aug 2026 03:09:23 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=a0W0FQN3znL9XDgjauVQBtrY7/wfswEeprm2/u/psJUIDVf7O3VDQY80PtL7gMTtFSwwGirMvAgQoD+Wq/NicjRn2glRSPThgmnIaZGLlYwt5kIajNrGrpyYg6fGhDcYvf3dMF+ukqI01Pub3uhFHirLTL9ddcK3tZpUprhtgMegdFPLgOouJvO7hsBeEQmWDdLA2XPOxzDWGwZeTxX89TuxbVjwF9KsYVS9R8b6itQFX0RqdzfvR5ZIP6MZ3tnyMVdgD1y/mB3wtfP8+OHOPRI8BxSh8cS7bSg4VHw9z74/sVeWdFSD4XFUxCpDTpYKekbSUwrQEax+8o7s9DsGCg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ElBOtEt8QuWxXRD7KgiNEGsI3yTM46XD66HgmSF/09s=;
 b=HEIxouBnvG/RlC/GpvXWW44XpDVVZk/BegKrecKxSGjxhDw1vLe1piq2CmFovY4e+sZkYMDqYdrA5mbHXgEkLbgVQWivG4quVvcr37coVy86eTfEiDwtNBsZFMtxw6ol23qrWYAMA3Gup0b4uJQhDMQ7jMq+8BJqeYOFQttFlaAldPsc9PjXMt7Y+h7XQmxA/YVrslMBlg4CZRntGdh7FBIxo6hjTSn91tm8tXT2kuC7AK0Tqv21O9jPOafhQBHcD9z58lv8A9yXwCzHEiof1pwc6A/9J4w6tLkeOVCQFt2E8DFfpm6wvK2EVe2tREZ6+fxqxfcs29ruz+6nK/0BAQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ElBOtEt8QuWxXRD7KgiNEGsI3yTM46XD66HgmSF/09s=;
 b=YFKRUtho8/5FzdZuMIUltPQH6ZV47urXkCPWobgYJAAY52AwGs+hvGE4MKcLsBSJsd2JG2L8lLlr1lNWJ398T+MzutaLA9o+wUPqM9EScdyw1UzZN9IG/yXMRrZkmvo9c70t6AHjU4ThMLnn8mauN39OVH1glufxNiObLrYLddM=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <3db3822e-5f40-462f-9f44-aab17806b656@amd.com>
Date: Wed, 19 Aug 2026 10:09:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Jens Wiklander
	<jenswi@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>
References: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <bb5a2a10-39ae-429f-a414-631b89d0bc89@amd.com>
 <59299B15-47CD-46AA-890F-E8991F41C01B@arm.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <59299B15-47CD-46AA-890F-E8991F41C01B@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD80:EE_|LV8PR12MB9690:EE_
X-MS-Office365-Filtering-Correlation-Id: 401c78eb-7cf5-4ca9-3ad4-08defdc92edc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|23010399003|376014|36860700016|1800799024|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	mkGCefHF8ugKh0DzX3/9rT0eM9/HHzHHqTBzHqy5O6gBLgwcnna9g4ovDpM1oZNHysd1H65u+PTtVFQb8bpqOUDE9Ls9/RNt0GW9N9KkfHiQSu/tAHh2DVGkX9yXPNnRdhS+WqR6Yc/FnURy4Vmh2e24Kd440mDS2DYKlK+39EHiqGZhs/vzsAup9a/gBl2btChNiuXzkjLFwvBWm0gEQsMQPJTAev8Io6Vo5GZ/MYVD/86bJZfnAlJUy6DpOw07W3RJU7KImNaJaGozbz8K9T8xwmhsDLMkKVlzLt6vZ6U/sU1KAWfEFupT4Sz0WbaCS94pDIAq12m7ehthd5jIMNuqPmc9F78HRC93zrHxypXwSb/rVL0g9rni/5112OQU6gJCHDnqi6+H0DKhnS3/WVrIUGHUr2k8enu8T6jTdyYsX/YUYe/k5M8HEnQroTBpHY/j+Qzzf7ksBy1ZeIHt3ZNbH5ddntw8/JQzH/NcZw+b+mDT377VDAsBzgIDzBePjhQOAAT6M8CRlCyLwbFZ9qvW9q3vt5T6ILyCdNynjGTa7ayLaFdNIj1gD5flY4VggffGgXbzceqQ72GjWPQ9qaSbsa+5Ve+BiZZ5mLesgyBzFzF86PKRMkksKZHv4/xUz7Lamod4Ogi7rzzwSNb0e3fxlCZt91pE4qLTggmCGKHpPwt6wZTiBEInk+Y9guhXXFlaxzpM7lEVraAdUUK/6A==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(23010399003)(376014)(36860700016)(1800799024)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	UhZzvc8kdWDHcMLkRYPr3zPpcIkEXklei22LShKPLx1PIwVtBM5euT3skwM219fx6M8bdaEDEvvgtUSoFwNNT8okLWt6PFWiynhg8CDNWrYLtcj3WEVLp0J91M9goN+Vv/U2QoRV5UtBJWSjttr4pbs7j7j7woR1zBhWz56rV70/yNTylIyXXrFA1WOYqqOfSGcJwR8FJmnvRBgzwusisBhJU4KhvNOg2zYUNFi3NZyd3ZLF0ca3+Zhb2UFHNojBSAm0ZKmG68rKxESdBt3EvgjWXumR6mtBLYlYORW7OxR8HTe82uWJD39jGQTk+9IvfbwyoPDMqw2lUDDN/eFi97Aebg3PauFyioeDGwx17Gs7h7A28r/rJe7pgpoMX/1TyYrxZvNx0rXBr9RZ3uf8CqbZI/BkezzpBKGLcIVmR86KooWc0SP7wsc7claI8j5F
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 08:09:24.9261
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 401c78eb-7cf5-4ca9-3ad4-08defdc92edc
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD80.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9690
X-purgate-ID: tlsNG-d25034/1787127052-014C7A5B-F3FBD798/0/0
X-purgate-type: clean
X-purgate-size: 2614



On 19-Aug-26 10:01, Bertrand Marquis wrote:
> Hi Michal,
> 
>> On 19 Aug 2026, at 09:47, Orzel, Michal <Michal.Orzel@amd.com> wrote:
>>
>>
>>
>> On 18-Aug-26 14:16, Bertrand Marquis wrote:
>>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>>> possible vulnerability.
>>>
>>> ffa_handle_msg_send2() copies the message header from the guest-writable
>>> TX buffer before validating and using its fields. A plain structure copy
>>> does not prevent the compiler from re-deriving later field accesses from
>>> the live TX mapping.
>>>
>>> For VM-to-VM messages, msg_offset and msg_size are validated against the
>>> source and destination buffers, then used to copy the payload. If a
>>> sibling vCPU changes the header and the compiler reloads either field,
>>> the checked and used values can differ. This can cause an out-of-bounds
>>> read from the sender's TX buffer or an out-of-bounds write into the
>>> receiver's RX buffer.
>>>
>>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
>>> default. The audit ranks the likelihood of such a reload as low, but the
>>> C semantics do not guarantee that later accesses use the stack copy.
>>>
>>> Add a compiler barrier immediately after copying the header so that
>>> validation and use consume the same snapshot.
>>>
>>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
>>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>> ---
>>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>>> index 1eadc62870f2..39f561c8237f 100644
>>> --- a/xen/arch/arm/tee/ffa_msg.c
>>> +++ b/xen/arch/arm/tee/ffa_msg.c
>>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
>>>
>>>     /* create a copy of the message header */
>>>     memcpy(&src_msg, tx_buf, sizeof(src_msg));
>>> +    /*
>>> +     * Make sure that "tx_buf" which is shared with the guest isn't accessed
>>> +     * again after this point.
>> This is a bit misleading because it *is* accessed in ffa_msg_send2_vm. The
>> comment should say what you wrote as the last paragraph in the commit msg.
> 
> Yes, this should be something around:
> Ensure validation and use of the message header use the same snapshot.
> 
> Do you agree ?
Yes. I'll fix on commit.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 08:12:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 08:12:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394848.1633478 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbPG-0002mc-CK; Wed, 19 Aug 2026 08:12:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394848.1633478; Wed, 19 Aug 2026 08:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbPG-0002mV-7T; Wed, 19 Aug 2026 08:12:18 +0000
Received: by outflank-mailman (input) for mailman id 1394848;
 Wed, 19 Aug 2026 08:12:16 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <hongyan.xia@transsion.com>) id 1wwbPE-0002mC-6Z
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:12:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbPD-001nON-Jc
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:12:15 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <hongyan.xia@transsion.com>)
 id 6a856558-e002-0a2a0a5209dd-0a2a4506a3f8-20
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:12:15 +0200
Received: from [52.101.127.95]
 (helo=TYDPR03CU002.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <hongyan.xia@transsion.com>)
 id 6a85655c-195a-0a2a45060019-34657f5ff07b-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:12:15 +0200
Received: from KL1PR0401MB6196.apcprd04.prod.outlook.com
 (2603:1096:820:c7::13) by SEZPR04MB6432.apcprd04.prod.outlook.com
 (2603:1096:101:a8::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 08:12:09 +0000
Received: from KL1PR0401MB6196.apcprd04.prod.outlook.com
 ([fe80::f2ee:1e28:9022:99f3]) by KL1PR0401MB6196.apcprd04.prod.outlook.com
 ([fe80::f2ee:1e28:9022:99f3%3]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 08:12:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=transsion.com header.i="@transsion.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HfS+ewTrYSphbObGuzP/RgPvbx7O9b41zYlm6vkq/vPGksWVGJrnz+gVj1Qr2dyWXn4R70qEAY3gzQGHXAEWFO8IhDNO4uoOb5AOQxEGn857AjSz+0zlvmG/ZYUfMZiiDa6KIqOLbDZm9iB5S2sFfuP0a2uCx7L9ZzCx/NggjDA7/f2LhWBDIAaOEKk32ntKR+7rJqSWy0qEclTnVKemqQZqwGdlSuIIkTDnjgx2IvQuVGcNTffpr56J0sLHGPUNj7JnQkMcRY7TgYzLyNyqibxaXAMWOdqsgE1Rq0MCRWJIF6DHOf7vYNPkO94zGy/9Fn3Qae6mdnnKIPWTiBQeLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=d84hCATNqnUCsUt/1WDjP8LtD1u8eNmXIKR7OiNQFo0=;
 b=BQDNrsbZqqJHSxYmmZv+K31QGGbQIOrz4WPrN3gxVhssdFluwtqCBd347CsL6beQCqTXXc7V08JbGZYrcm469Qk3c4086Yvwv7YdaFwkI7y5alaMPaMqwxRIlXDd+CmE0VH9yQn0vplV+RBzgMdbBfg22eDPG0SnPK3834pYMb9QQsWs787cIByGttOhhRNxm3ob5GTF9URWEbDEKQrt3k7N9z5gCqpxLkaRIDoyjWr8CqPWPse6IuhC7ovzPjhh3nQe1v0w9PjLoCY/XQvpSL4DevNUQjTKk1bewdDz743ipSh44ZtvAbbFMScBSHjCiuKZD51pb7xo7kPWsUiSgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=transsion.com; dmarc=pass action=none
 header.from=transsion.com; dkim=pass header.d=transsion.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transsion.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=d84hCATNqnUCsUt/1WDjP8LtD1u8eNmXIKR7OiNQFo0=;
 b=trS+M/3+1UuFoHFDnAG5KK1O3hlYMw8+9RjteJDPP/QvYvDOH4JfgTBepxUxzt8/EJzzg3QCsYTkzF3wzBmukSuwLhHDDMIjghwD+KrVh3wpr0qcJOEN8z+0jSpuynJWuVk1I/xCwqp1Obe2Pej9Ob/EnyIr4ORvGC+b1qCG/Go=
From: Hongyan Xia <hongyan.xia@transsion.com>
To: Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>, Broadcom internal kernel
 review list <bcm-kernel-feedback-list@broadcom.com>, Catalin Marinas
	<catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Huacai Chen
	<chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Madhavan Srinivasan
	<maddy@linux.ibm.com>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin
	<npiggin@gmail.com>, "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>, Paul
 Walmsley <pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Thomas Gleixner
	<tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov
	<bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "x86@kernel.org"
	<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, Paolo Bonzini
	<pbonzini@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Stefano
 Stabellini <sstabellini@kernel.org>, Oleksandr Tyshchenko
	<oleksandr_tyshchenko@epam.com>, Peter Zijlstra <peterz@infradead.org>, Juri
 Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>, Steven Rostedt
	<rostedt@goodmis.org>, Ben Segall <bsegall@google.com>, Mel Gorman
	<mgorman@suse.de>, Valentin Schneider <vschneid@redhat.com>, K Prateek Nayak
	<kprateek.nayak@amd.com>
CC: Jiazi Li <jiazi.li@transsion.com>, "virtualization@lists.linux.dev"
	<virtualization@lists.linux.dev>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "loongarch@lists.linux.dev"
	<loongarch@lists.linux.dev>, "linuxppc-dev@lists.ozlabs.org"
	<linuxppc-dev@lists.ozlabs.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "kvm@vger.kernel.org"
	<kvm@vger.kernel.org>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
Subject: [PATCH RESEND] sched: Convert paravirt_steal to new static key APIs
Thread-Topic: [PATCH RESEND] sched: Convert paravirt_steal to new static key
 APIs
Thread-Index: AQHdL7JurDcnsknKnUOaLMvw1Db+YA==
Date: Wed, 19 Aug 2026 08:12:09 +0000
Message-ID: <20260819081207.12150-1-hongyan.xia@transsion.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=transsion.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: KL1PR0401MB6196:EE_|SEZPR04MB6432:EE_
x-ms-office365-filtering-correlation-id: befa3bdb-2ae8-4060-d27d-08defdc990d6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|1800799024|23010399003|366016|921020|38070700021|6133799003|10067099003|56012099006|11063799006|18002099003;
x-microsoft-antispam-message-info:
 d8clx7CxpRAa7wDJWB7i0klecT0DiSo22kLcX70H82L7a4gg0NdJrkEtcqUOdNIwosLMHYe0XUNDBVs/NhktiHHwHtj2QkCeGcdpxFPmMls2XC9RBCwVVgm2ajs5N8t3HtkgZnqReAMJZyywnq5d0jTTwIpfpYfFgXawESMmAmNkzzsr1SLWruQ7f4Hk2+gqcd5wZgkTLPFyoTVtNCCeE8rKsrwkPQ31BzI78TZkhXdSB+Qv2V6DOz0VdMRgHa17lQgcC5jTj9HL5zCBF5b+12FstdHYISJnh6p7CPkpw0PGXa7NiXmP1lhk0Cl2/zUOUc/ZeqGsSdNNPinZUEnqGgBuDL/GTGURucPA1mkxl77PohNaXuFesP70S6swapKFVd2aT+VoEQYdsXzIn5yxpnQ3LsSWO7Fc+xKO8LPExZdQnyJ9jem0WSG83F+B83Ie70hWFEGgyqRY6S5LiLULNsU0/NgrnvnHMgYJxhCC26g8jo3Ffv2CpChLMP9NIUSb8FGN4UoTH7QbmzSE6GcDTXLUTUv0qYJu+CzmFq23IlmJzl2eYM4AtOdXj7ysaQh//Mp0+fAhaX5/P+B/UnDJMc/DsuUHCniw6UZr9PnCGl91OYWZ4VOnmhBFmx7mOMf9a6nXAGId+79AyywjQM0dRQPZ9qPDNMbk1vCFkup7X8dmcCn2LhK0EQgWh3hT8/YLc/DSTF3IvXgZTxQ6QS9Hi7dRtqbmxG/nWOWxynlfK9nqP7LJ7uQl5q4OJkn8mwKz
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:KL1PR0401MB6196.apcprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(23010399003)(366016)(921020)(38070700021)(6133799003)(10067099003)(56012099006)(11063799006)(18002099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Odxo+I8eXOuMeqm5vDHyLaZpOpKBP20/pEIg1Hlaiw95uP2SsGAv55wdQt?=
 =?iso-8859-1?Q?jlKFqPTVy5IDwLR2OYSi3i5HDYkolIrBk4IzV5padxa9xV7CmWgGu8URpP?=
 =?iso-8859-1?Q?t7052kutoeHqgA1aYkEDgSOr9KxClnZXitRKRR+QkprYVc4gIlrH1/ZNCk?=
 =?iso-8859-1?Q?PWgIhgJZrH6hxr3IP8KtAp6xqGQZa2kHkGp5YaobRA4BZAWweUmEYkfnps?=
 =?iso-8859-1?Q?e4G4RKGWuk0EpcOpebrPROUoK61gfIgZmnXEAOZn/Be+jA6ZFJlcmuB7YW?=
 =?iso-8859-1?Q?IHhAOyIlG9lDaGCEsjAzhbJo2okmJMaT/au92Emk9cZXd0TBntWM4nr9e/?=
 =?iso-8859-1?Q?sf9cY8FKxM5zzW473dLU5nEpYwVBsGo+tJ3JCZGdTuguYKFoVKx9oEU2A5?=
 =?iso-8859-1?Q?0QtCucd1NT3fgyKSuv9fu2+Pdx4mSjVdy31OGxiFA6UpL10WTM7j+dDp/b?=
 =?iso-8859-1?Q?9/ZXNREcScYt64xbi1xEjpuN47e7D82SiKnJtjhmFsfs3uRiUwvPBKbJF3?=
 =?iso-8859-1?Q?mrJv9+d3QcVv00QavF1CCPigmkmCgf9IYH11vuj5dUPCsrTXIND7+OlRhz?=
 =?iso-8859-1?Q?FfaS8JFp8x61NPINL+nUGHSwgFbufz8Jo3X8hDCHT1zaGAJYyrB0ExyNYi?=
 =?iso-8859-1?Q?XieQwJUVwVfiLk3lRnJ1qY/wJSxGAudDvy7SiUKbBbsqQQMZ4UKJDd9JSa?=
 =?iso-8859-1?Q?jRRcdwK+jcmnwrAIHSOrQilwj3BY3dshkpd8ZyAHNGG/7XFu70smJyiUQ0?=
 =?iso-8859-1?Q?wl6VgF0XPmtSI3PsxD4AyhWrZLjZ9y3Dx78c3sYI+/rdc2ReD6y8CZuDob?=
 =?iso-8859-1?Q?rIbA/ZNPmanTxBfjiYnXwGYg+4a1oUf7KizvVHz1EYrLcYX7qwBHVScYjT?=
 =?iso-8859-1?Q?xm71PHk7txJvONIV9gS4+3o7pVmN+E1XfBCpGgGtLoyYUF7nWMJyLQW3FA?=
 =?iso-8859-1?Q?79/iiIGV6/cy+J8cIvFL36LJxWN+7ohTFj1ZXLSxWuVi63fxGEDbR5Sx+O?=
 =?iso-8859-1?Q?CgRp8osfe3EIn9Rfp6OCs8lfIeoYykDcj/eJI6/F2Hks661vxFFxsHm9Jc?=
 =?iso-8859-1?Q?+F96FhqTOz2Mr7E9QRx/L2mSacCCzXmyhYRccypaYwrphTw6Ao12OGHnpG?=
 =?iso-8859-1?Q?k9leOs5rCL3+vknwnr25r1wmEhuTzZeWuAbZVhfIiAuoWc9VMOczjvLA5d?=
 =?iso-8859-1?Q?o9fL1xPyoS9YqdvmcYrLAhDF2EWkWXdzKt7MqeDDw5YsHHrlIigociDETA?=
 =?iso-8859-1?Q?VcxU2hKOvjHHzW+1qO5v0xXqOHdJZC8gZDmYK1s+YaZOSbPZiQDCCmemPT?=
 =?iso-8859-1?Q?YyPVgnGfnO4waCsIpSjtaJWAl5CIaI5T0rthGoLSQafPEU+Ett9d0YB9DL?=
 =?iso-8859-1?Q?IoNQtJUR1p5vHLr88Dno+vgnpvP/cMgVCiqBhveIsmVDPuolcMCI688H5I?=
 =?iso-8859-1?Q?anOB5/CIDLviX1uBhb3NKAAB9iCxjzSKFfggywHvZmJnhMBTX3UBtC4CDd?=
 =?iso-8859-1?Q?Da+6ipEMVhyemyHz3BMqdVt8CqGITjqM7APWVk3aaoDrQuYGn6l1p51MDS?=
 =?iso-8859-1?Q?Ydm1JUPePZn/y30L0hxz4JkoNuJtWGtUXqXlGWo/d/bc9qiK0dWPuVK9zW?=
 =?iso-8859-1?Q?vF1L9KW0r3hVibwZFfszwHNF/4GQ0HTZYWJK4quj6tiVgT7dih2DIuMtv2?=
 =?iso-8859-1?Q?G1gJSCEEQ3v+h99lggXlOS7nuTwplaUm2nWw7DExOEO9wGfl+WuCBitgRP?=
 =?iso-8859-1?Q?KIfUQxSNSigKdin9PzRYWMxH+/hM+j0Zr9ypkUpWbKuzrhoGTlDaf0uwAr?=
 =?iso-8859-1?Q?JYyUZT+kVg=3D=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: transsion.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: KL1PR0401MB6196.apcprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: befa3bdb-2ae8-4060-d27d-08defdc990d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2026 08:12:09.3185
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2e8503a6-2d01-4333-8e36-6ab7c8cd7ae2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hahIfAI68GG4NH7OftBS1CZP1PWA2JXjn6x51ud59dJAgdzNyPwXHPNEGP9iVwarDN/dWZFuGQaIOxQqZF0lS26mGmSBp4GhxB4Us/HB+tE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR04MB6432
X-purgate-ID: tlsNG-16d1c6/1787127135-1EEC477B-7169E82E/0/0
X-purgate-type: clean
X-purgate-size: 8308

From: Hongyan Xia <hongyan.xia@transsion.com>=0A=
=0A=
paravirt_steal_rq_enabled and paravirt_steal_enabled use raw static_key=0A=
APIs which are now deprecated. Use the new API instead.=0A=
=0A=
No functional change.=0A=
=0A=
Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>=0A=
Acked-by: Juergen Gross <jgross@suse.com>=0A=
---=0A=
Changed in RESEND:=0A=
- Separate the original series into individual patches. They aren't easy=0A=
  to review as a series.=0A=
=0A=
 arch/arm64/kernel/paravirt.c           | 4 ++--=0A=
 arch/loongarch/kernel/paravirt.c       | 4 ++--=0A=
 arch/powerpc/platforms/pseries/setup.c | 4 ++--=0A=
 arch/riscv/kernel/paravirt.c           | 4 ++--=0A=
 arch/x86/kernel/cpu/vmware.c           | 4 ++--=0A=
 arch/x86/kernel/kvm.c                  | 4 ++--=0A=
 drivers/xen/time.c                     | 4 ++--=0A=
 include/linux/sched/cputime.h          | 6 +++---=0A=
 kernel/sched/core.c                    | 4 ++--=0A=
 kernel/sched/cputime.c                 | 4 ++--=0A=
 10 files changed, 21 insertions(+), 21 deletions(-)=0A=
=0A=
diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c=0A=
index 572efb96b23f..30bf61d031eb 100644=0A=
--- a/arch/arm64/kernel/paravirt.c=0A=
+++ b/arch/arm64/kernel/paravirt.c=0A=
@@ -157,9 +157,9 @@ int __init pv_time_init(void)=0A=
 =0A=
 	static_call_update(pv_steal_clock, para_steal_clock);=0A=
 =0A=
-	static_key_slow_inc(&paravirt_steal_enabled);=0A=
+	static_branch_inc(&paravirt_steal_enabled);=0A=
 	if (steal_acc)=0A=
-		static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+		static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 =0A=
 	pr_info("using stolen time PV\n");=0A=
 =0A=
diff --git a/arch/loongarch/kernel/paravirt.c b/arch/loongarch/kernel/parav=
irt.c=0A=
index 10821cce554c..e8965a3f8082 100644=0A=
--- a/arch/loongarch/kernel/paravirt.c=0A=
+++ b/arch/loongarch/kernel/paravirt.c=0A=
@@ -308,10 +308,10 @@ int __init pv_time_init(void)=0A=
 =0A=
 	static_call_update(pv_steal_clock, paravt_steal_clock);=0A=
 =0A=
-	static_key_slow_inc(&paravirt_steal_enabled);=0A=
+	static_branch_inc(&paravirt_steal_enabled);=0A=
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING=0A=
 	if (steal_acc)=0A=
-		static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+		static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 #endif=0A=
 =0A=
 	if (static_key_enabled(&virt_preempt_key))=0A=
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platform=
s/pseries/setup.c=0A=
index 1223dc961242..8dcbc4bb7025 100644=0A=
--- a/arch/powerpc/platforms/pseries/setup.c=0A=
+++ b/arch/powerpc/platforms/pseries/setup.c=0A=
@@ -852,9 +852,9 @@ static void __init pSeries_setup_arch(void)=0A=
 			static_branch_enable(&shared_processor);=0A=
 			pv_spinlocks_init();=0A=
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING=0A=
-			static_key_slow_inc(&paravirt_steal_enabled);=0A=
+			static_branch_inc(&paravirt_steal_enabled);=0A=
 			if (steal_acc)=0A=
-				static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+				static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 #endif=0A=
 		}=0A=
 =0A=
diff --git a/arch/riscv/kernel/paravirt.c b/arch/riscv/kernel/paravirt.c=0A=
index 5f56be79cd06..9c13a6f1ea2a 100644=0A=
--- a/arch/riscv/kernel/paravirt.c=0A=
+++ b/arch/riscv/kernel/paravirt.c=0A=
@@ -116,9 +116,9 @@ int __init pv_time_init(void)=0A=
 =0A=
 	static_call_update(pv_steal_clock, pv_time_steal_clock);=0A=
 =0A=
-	static_key_slow_inc(&paravirt_steal_enabled);=0A=
+	static_branch_inc(&paravirt_steal_enabled);=0A=
 	if (steal_acc)=0A=
-		static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+		static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 =0A=
 	pr_info("Computing paravirt steal-time\n");=0A=
 =0A=
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c=0A=
index 34b73573b108..f7ab9e7902cf 100644=0A=
--- a/arch/x86/kernel/cpu/vmware.c=0A=
+++ b/arch/x86/kernel/cpu/vmware.c=0A=
@@ -328,9 +328,9 @@ static int vmware_cpu_down_prepare(unsigned int cpu)=0A=
 static __init int activate_jump_labels(void)=0A=
 {=0A=
 	if (has_steal_clock) {=0A=
-		static_key_slow_inc(&paravirt_steal_enabled);=0A=
+		static_branch_inc(&paravirt_steal_enabled);=0A=
 		if (steal_acc)=0A=
-			static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+			static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 	}=0A=
 =0A=
 	return 0;=0A=
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c=0A=
index dcef84da304b..d3dcd64f22c2 100644=0A=
--- a/arch/x86/kernel/kvm.c=0A=
+++ b/arch/x86/kernel/kvm.c=0A=
@@ -1052,9 +1052,9 @@ const __initconst struct hypervisor_x86 x86_hyper_kvm=
 =3D {=0A=
 static __init int activate_jump_labels(void)=0A=
 {=0A=
 	if (has_steal_clock) {=0A=
-		static_key_slow_inc(&paravirt_steal_enabled);=0A=
+		static_branch_inc(&paravirt_steal_enabled);=0A=
 		if (steal_acc)=0A=
-			static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+			static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 	}=0A=
 =0A=
 	return 0;=0A=
diff --git a/drivers/xen/time.c b/drivers/xen/time.c=0A=
index a2be0a4d45b0..a02d48a2aa68 100644=0A=
--- a/drivers/xen/time.c=0A=
+++ b/drivers/xen/time.c=0A=
@@ -169,7 +169,7 @@ void __init xen_time_setup_guest(void)=0A=
 =0A=
 	static_call_update(pv_steal_clock, xen_steal_clock);=0A=
 =0A=
-	static_key_slow_inc(&paravirt_steal_enabled);=0A=
+	static_branch_inc(&paravirt_steal_enabled);=0A=
 	if (xen_runstate_remote)=0A=
-		static_key_slow_inc(&paravirt_steal_rq_enabled);=0A=
+		static_branch_inc(&paravirt_steal_rq_enabled);=0A=
 }=0A=
diff --git a/include/linux/sched/cputime.h b/include/linux/sched/cputime.h=
=0A=
index e90efaf6d26e..694126411dfe 100644=0A=
--- a/include/linux/sched/cputime.h=0A=
+++ b/include/linux/sched/cputime.h=0A=
@@ -182,9 +182,9 @@ extern unsigned long long=0A=
 task_sched_runtime(struct task_struct *task);=0A=
 =0A=
 #ifdef CONFIG_PARAVIRT=0A=
-struct static_key;=0A=
-extern struct static_key paravirt_steal_enabled;=0A=
-extern struct static_key paravirt_steal_rq_enabled;=0A=
+#include <linux/jump_label.h>=0A=
+DECLARE_STATIC_KEY_FALSE(paravirt_steal_enabled);=0A=
+DECLARE_STATIC_KEY_FALSE(paravirt_steal_rq_enabled);=0A=
 =0A=
 #ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN=0A=
 u64 dummy_steal_clock(int cpu);=0A=
diff --git a/kernel/sched/core.c b/kernel/sched/core.c=0A=
index 5c07d53e43b5..84d090581a08 100644=0A=
--- a/kernel/sched/core.c=0A=
+++ b/kernel/sched/core.c=0A=
@@ -795,7 +795,7 @@ struct rq *_task_rq_lock(struct task_struct *p, struct =
rq_flags *rf)=0A=
 =0A=
 /* Use CONFIG_PARAVIRT as this will avoid more #ifdef in arch code. */=0A=
 #ifdef CONFIG_PARAVIRT=0A=
-struct static_key paravirt_steal_rq_enabled;=0A=
+DEFINE_STATIC_KEY_FALSE(paravirt_steal_rq_enabled);=0A=
 #endif=0A=
 =0A=
 static void update_rq_clock_task(struct rq *rq, s64 delta)=0A=
@@ -834,7 +834,7 @@ static void update_rq_clock_task(struct rq *rq, s64 del=
ta)=0A=
 	}=0A=
 #endif=0A=
 #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING=0A=
-	if (static_key_false((&paravirt_steal_rq_enabled))) {=0A=
+	if (static_branch_unlikely(&paravirt_steal_rq_enabled)) {=0A=
 		u64 prev_steal;=0A=
 =0A=
 		steal =3D prev_steal =3D paravirt_steal_clock(cpu_of(rq));=0A=
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c=0A=
index 06bddaa738e5..f16970ca81d0 100644=0A=
--- a/kernel/sched/cputime.c=0A=
+++ b/kernel/sched/cputime.c=0A=
@@ -255,7 +255,7 @@ void __account_forceidle_time(struct task_struct *p, u6=
4 delta)=0A=
  * occasion account more time than the calling functions think elapsed.=0A=
  */=0A=
 #ifdef CONFIG_PARAVIRT=0A=
-struct static_key paravirt_steal_enabled;=0A=
+DEFINE_STATIC_KEY_FALSE(paravirt_steal_enabled);=0A=
 =0A=
 #ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN=0A=
 static u64 native_steal_clock(int cpu)=0A=
@@ -270,7 +270,7 @@ DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);=
=0A=
 static __always_inline u64 steal_account_process_time(u64 maxtime)=0A=
 {=0A=
 #ifdef CONFIG_PARAVIRT=0A=
-	if (static_key_false(&paravirt_steal_enabled)) {=0A=
+	if (static_branch_unlikely(&paravirt_steal_enabled)) {=0A=
 		u64 steal;=0A=
 =0A=
 		steal =3D paravirt_steal_clock(smp_processor_id());=0A=
-- =0A=
2.47.3=0A=
=0A=


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 08:19:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 08:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394863.1633487 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbVq-0003cD-40; Wed, 19 Aug 2026 08:19:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394863.1633487; Wed, 19 Aug 2026 08:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbVq-0003c6-0F; Wed, 19 Aug 2026 08:19:06 +0000
Received: by outflank-mailman (input) for mailman id 1394863;
 Wed, 19 Aug 2026 08:19:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Bertrand.Marquis@arm.com>) id 1wwbVo-0003c0-SY
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:19:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbVo-004qMk-5b
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:19:04 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a8566ed-8faa-0a2a0a5109dd-0a2a4503b45a-40
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:19:03 +0200
Received: from [52.101.65.31]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Bertrand.Marquis@arm.com>)
 id 6a8566f6-fae8-0a2a45030019-3465411fe646-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:19:03 +0200
Received: from AS8PR04CA0196.eurprd04.prod.outlook.com (2603:10a6:20b:2f3::21)
 by VI0PR08MB10559.eurprd08.prod.outlook.com (2603:10a6:800:20f::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 08:18:59 +0000
Received: from AM4PEPF00027A62.eurprd04.prod.outlook.com
 (2603:10a6:20b:2f3:cafe::73) by AS8PR04CA0196.outlook.office365.com
 (2603:10a6:20b:2f3::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.315.17 via Frontend Transport; Wed,
 19 Aug 2026 08:18:58 +0000
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
 AM4PEPF00027A62.mail.protection.outlook.com (10.167.16.71) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.3
 via Frontend Transport; Wed, 19 Aug 2026 08:18:58 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13)
 by AS8PR08MB5941.eurprd08.prod.outlook.com (2603:10a6:20b:296::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 08:18:24 +0000
Received: from PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com
 ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 08:18:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=CV20b8b2eQhmU9fXtT0zL900SZcbXazbeUUlQ9XHG4V6i3j92Y0xOnZ6D4e1QG0eRnrn5ttSAVXyViBrcwaSsLfJOFv+tYKWEemRhKNmasFKctUh03vmaWWl/PkBmIx7wJ89V/dXNc5X8EstC993/ZklwNjbq80OtFy+kMRdrIqP0N+IfCNxe7D2xAk8aaKu3D1bOHqeItiXrn0GWAQSVA28NDM2gfxmIu9jXqF1nZWO/Y7QWRG4fEIUb1uMYaynrjFsUTpULBP6FT2o1HYXiVxHlENCfenxrs4CgOM5wS9NoEXbdPb9IOis+n2mu5siNqcgkO5wFn6octhVZiQ1CA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nmfV9jZkRiW5RX0g53UAkRH+0KpBfEnmsl36tJuhhGM=;
 b=xmQ4CJbPGCauo2mn20dVOXgb419tENqwLBq70vvHLTkqzHep4fdxJLEO5e8qJmVyr95b96DU8gjGs/G6AoZDrDRpxrgWPbBYbmLw4Ph4+yKG87ENIBFqA+2P+up/k0Qp0dT8UmIPSLeIQjhGh29wFroOwFBM3kUmRqlhEpG2wEnDXYMGRmDTSMKOu+6zjRW6yJv5XJUnIfKbuIMXT7mQYrCKLCGeo3+GPlfHW6QHM2BUb+oVeqch50bCn58yimC30ggxA/jfFlw8kfn8lF+PhJ/ZZSk92HRiM3oZJDsGy2j98GTdgLXA/J7iFqZYPCEm8c8NRB9M9O85UyQWu9Bvlg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 4.158.2.129) smtp.rcpttodomain=amd.com smtp.mailfrom=arm.com; dmarc=pass
 (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
 (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
 dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nmfV9jZkRiW5RX0g53UAkRH+0KpBfEnmsl36tJuhhGM=;
 b=WbPpit4EGanfgUUbMhAXxQQWpsWl77Q0NBFaF6JfJvLW6pQtI7Oc16cPxFdBBet+jXHI46RgVKSj40USDAZ5vp80BDUVg1fqfYN+9VrA+a/pDYvfjQo8fjyvVycFZKwaTRDMPF8ZyendcA8nfAS7Hm1mu1iG1FTGIoyCUaOKHXc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
 smtp.mailfrom=arm.com; dkim=pass (signature was verified)
 header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 4.158.2.129 as permitted sender) receiver=protection.outlook.com;
 client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HZZWq4W8pVTrWF7NUzLSsqq5fgAd8atd1xGeXKcwms02oQLcPRuEl/dlrurKn0Ox8jY8nOg1cLT10RztqZ2EW5oPE4RmrLG2HfL0k7aeCRJXA8aabv9EdJIGVyjBDRYERqwcWAq3NaZ7fahkMRHORrSCzoGCsSIMUt9oxvCQg9Q2FpgXyYcOAHnCs0zOaSOteUmK2kb1UTSzTTUwRjS5q6jqWbAqTKF+RRIU7RYSQ0FpZaVyuC/hPPH/3xPe8OEN170/amhP/Zms6Bvr2nPyjs+1srL3oVaa7/4Tvvr+qdX/2Axe/UnioaeMaIC4mpRTMaFcKf1Uj9MSgHLzBQIlKg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nmfV9jZkRiW5RX0g53UAkRH+0KpBfEnmsl36tJuhhGM=;
 b=lOCu/GqeiuLLQxlK6vaVdR8JQ6PPjWhTG7YaHSYcsbTywosg/LI73v2QutIhwQQ7rt+iOj/9kEUDuPGIeXpIYMypdwjNn9FlRYPEWRGOYL4aenPRp8SoC4T7nyXugcXi4zZuU58atU4Vj1prWl0oRWI17gtfK/24kDHZJYaJpkz4nRh1LjG0SjjeDXDLl2SPpGYXUTeAcVLDYju5HQrYAtgAmjHgkHlFMOkoZF1s5xIO+RFfA+AWPO00tj/ODX6I6cM4y55CvgY31QH4zM2DiFdUg3bOMaMAsX9soGIi6D0W0jlY0pn/51fhXS6eguQuw/OW/TvcpD3CzIhpAaywCw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nmfV9jZkRiW5RX0g53UAkRH+0KpBfEnmsl36tJuhhGM=;
 b=WbPpit4EGanfgUUbMhAXxQQWpsWl77Q0NBFaF6JfJvLW6pQtI7Oc16cPxFdBBet+jXHI46RgVKSj40USDAZ5vp80BDUVg1fqfYN+9VrA+a/pDYvfjQo8fjyvVycFZKwaTRDMPF8ZyendcA8nfAS7Hm1mu1iG1FTGIoyCUaOKHXc=
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: "Orzel, Michal" <michal.orzel@amd.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>, Jens Wiklander
	<jenswi@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, Julien
 Grall <julien@xen.org>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Topic: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
Thread-Index: AQHdLwt9ezGusG27iE6LBf89mJZswbak//uAgAAD2ICAAAIrAIAAAnoA
Date: Wed, 19 Aug 2026 08:18:24 +0000
Message-ID: <93FE9979-8787-4473-A356-34FD3C1AEACD@arm.com>
References:
 <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <bb5a2a10-39ae-429f-a414-631b89d0bc89@amd.com>
 <59299B15-47CD-46AA-890F-E8991F41C01B@arm.com>
 <3db3822e-5f40-462f-9f44-aab17806b656@amd.com>
In-Reply-To: <3db3822e-5f40-462f-9f44-aab17806b656@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3864.600.51.1.1)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	PR3PR08MB5593:EE_|AS8PR08MB5941:EE_|AM4PEPF00027A62:EE_|VI0PR08MB10559:EE_
X-MS-Office365-Filtering-Correlation-Id: 50d114cb-f07f-4f77-998a-08defdca84a5
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|22082099003|18002099003|38070700021|56012099006|10067099003|4143699003|11063799006;
X-Microsoft-Antispam-Message-Info-Original:
 1vV7+KJsynwQ/PdQZ9F24pcGutEF4J+t2DZH0emQhlntSwXtlbtGNNAjKoV6vpsRj43dKxj7st+xfrjws8nhx6CcDxQ4u+1GeNm7nFt5kslQshzHDBPNg0b66s9fvvIiu/aym/6wTrDiAuFesobJoyVLaXvSxc+N/XzdUR6nPB46OAawwyZCuCPOhHL6bWDh/6BIVwgqceYb4jpJ6gSMkKx07zcigxYukcDc/CaLDjRThwPH31LcwFu00UzZziA3ocKOjodg7AcVjLS4A6DSv//ZoHPhzGs9OIsSaVHhMsXkej7Ew0QZNzzI8ZeM80MogYLxABy+F6t4H7MeJrmnmPvB641fgrlRH9OjnnOy3IICZ46Lmdd2K6+lLk9U4eTlXSTqZ7sJw5Kg6imuzDE8nAqzmPTTku8ra6gq3Xd6doq0PEDPq5x6OanYKbu5OUf9Uh93P9R/t7mEORFMCK6e9b78eoQdMGQGNoxnBwY7nixa6fVSAGXTPjn6+VQT+W9DghqOZcVcQz6cLHBZfMDpAA3cRUwCobd4aNRs+GR1Om7SCNaGxo7Mle6MdqIMxv82wyKzfieskslJ68gm/9qb7z8cYvSdTYzc4F1pU42TNUT8wJ0EZ2Fi30xHG9v2O4XEuqJQVkqFnpKP5nrvQOB78gMT5gRuPTduhKkP/VCQr0XmLVBUwSp7rxqq0UdEil+VINXrkubuDFoHPzF/xhxv4+hEBqdMVX6OMdGdFkP88+w=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(22082099003)(18002099003)(38070700021)(56012099006)(10067099003)(4143699003)(11063799006);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B7D3DBABC316114CBDE51B643FB6B502@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Exchange-RoutingPolicyChecked:
 KZmChN8N1RVTw3DkpzUSCkBG2j+MPbrjHBiADB7qMFOFcaDxPHahUa3xgjNvfB81tiEOc7TxDBICaYsk3VedAA1zOdNGXMLDzWu9PKc+nDNsUqcXPzb4/2jE8qC2FZ+OOAlwXG4mtzNH39muH31C91VCh9FethniJqScNh8lOPXnvCkiwAnIqUcZjrAG7z14iYIC0ieSSTRMEeApXAS+mURJzVZqscsdk/rqEdR8LBcZ/Mrq3u7G+Jroqk0G7k+QM45CbhErKXJna6uimmHiO/8hoY+EvNtcEH0xLpwJmvidRCUQveuAYYMD2YhfJxdc93NpKOuxniKN0wTrj32Odg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB5941
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM4PEPF00027A62.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	04e4377c-2c26-45b7-02fc-08defdca7071
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|376014|1800799024|82310400026|14060799003|23010399003|35042699022|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	QEWpCC7eidPODXHb+Zb8s3XrCIcUcm3B0wz0baWz1qMlDJ0b0rfovGUOBDkGOLDrGZ6K6opLgowzQzN9BfeUON1Wo02ixShSJefK87K7nKk6XL8ZBprF0YGoS/u6Ri742RDXl1Yxl4jdTNgoXjr0Gkzm2gEbi5sYcAd6CYaTwMlb5OdsYzuZTRBAQng4XGtDx6lmOFoSeyrfNERc1rruOryhMJQeyxvg1YSELF4Qp4LpIgHTuFmCAfm721CB/45CtEot/YZG4pZLXGqv03PNwi6+oC2dNQdsS6MGN/ikJ+KZZJdEoUXRWxtB1g2oLZxc+qQymrIZ9fjI8zGE1cQ7/z/lNlYeGd08fvGNd6ofXPKxBe/3oCdJmBO9be9LILtzBCKqelVzoBbX5I1FsAUYEeZIIhn1Y7wb7XUAutJvxqND/GzEawqcC+ky6sux3PieJ31lKwzrkSuBeJ+LHH4c7KLdDigE1PSdhd+RUvRC5qAF9A1JSXoiM0IDW1bBhsX96Mckt/5d3lkK4G3L/DFpx7CWulIJmtQfmPRVgCr+eUOvMY/e3ZCplqSY5FwSc5QBPPIy3iTP7SxvF7ESeaeDfnKsx4JdACkJYYi95xbBullkYa3mfA/a6OZTKlO2TulgEqhnJuLmx1OFctGgQHj68SX68p/7glWTR2/MR5fsGtOoaKyvpQ1ZNWiBlT+5AdVs1myLtq1Fc867tM44OsJkUg==
X-Forefront-Antispam-Report:
	CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(376014)(1800799024)(82310400026)(14060799003)(23010399003)(35042699022)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	sxvW4I0i1v+yn8nXkZjqByaDSQK1KzvZQWNq6/rqfPkv+JEpfBdbCH9MgconS6z5HGzr6chKOexa7BbmQSNLT1AdnTL+V6Lz0s5/3qKkDzuknIrplqZ6TVq9d9gVzxvL/R/1Dkacpp/W2A50g3d/M4LWr2OY3R4r23b9o6zW47OpNF2AzbnA+RRrZeHMFOhA30EIfyd875oB5NaHFpPCF+jRkU7qzrcUax5tDeSZT/J+0XiijLjHL4m1mLvH1BU6wofe5HrESs4D+wlPwq2MiiJKNGOgOe0bQHcQBqWGWQv0qFS3+1dm779cFjbh6T5FK/y/cbaozfU9csbyIo8+E2cSmryHbGsyV7Bcwp1uJIZleGG6GY0S2F5wYqDJ2T4hRhl5iquu7YMnknt+Pwuh12hw6LO1Q9axeN4GuU9ypYaaE+1mX6KWzz2H1paFlJ7X
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 08:18:58.2924
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 50d114cb-f07f-4f77-998a-08defdca84a5
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM4PEPF00027A62.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10559
X-purgate-ID: tlsNG-33051d/1787127543-6C8DD4E9-8D3CE50F/0/0
X-purgate-type: clean
X-purgate-size: 2872



> On 19 Aug 2026, at 10:09, Orzel, Michal <michal.orzel@amd.com> wrote:
>=20
>=20
>=20
> On 19-Aug-26 10:01, Bertrand Marquis wrote:
>> Hi Michal,
>>=20
>>> On 19 Aug 2026, at 09:47, Orzel, Michal <Michal.Orzel@amd.com> wrote:
>>>=20
>>>=20
>>>=20
>>> On 18-Aug-26 14:16, Bertrand Marquis wrote:
>>>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>>>> possible vulnerability.
>>>>=20
>>>> ffa_handle_msg_send2() copies the message header from the guest-writab=
le
>>>> TX buffer before validating and using its fields. A plain structure co=
py
>>>> does not prevent the compiler from re-deriving later field accesses fr=
om
>>>> the live TX mapping.
>>>>=20
>>>> For VM-to-VM messages, msg_offset and msg_size are validated against t=
he
>>>> source and destination buffers, then used to copy the payload. If a
>>>> sibling vCPU changes the header and the compiler reloads either field,
>>>> the checked and used values can differ. This can cause an out-of-bound=
s
>>>> read from the sender's TX buffer or an out-of-bounds write into the
>>>> receiver's RX buffer.
>>>>=20
>>>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled b=
y
>>>> default. The audit ranks the likelihood of such a reload as low, but t=
he
>>>> C semantics do not guarantee that later accesses use the stack copy.
>>>>=20
>>>> Add a compiler barrier immediately after copying the header so that
>>>> validation and use consume the same snapshot.
>>>>=20
>>>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/ob=
server-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-tx=
rx-buffers-ffa_shmc-ffa_msgc
>>>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>> ---
>>>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>=20
>>>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>>>> index 1eadc62870f2..39f561c8237f 100644
>>>> --- a/xen/arch/arm/tee/ffa_msg.c
>>>> +++ b/xen/arch/arm/tee/ffa_msg.c
>>>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs=
 *regs)
>>>>=20
>>>>    /* create a copy of the message header */
>>>>    memcpy(&src_msg, tx_buf, sizeof(src_msg));
>>>> +    /*
>>>> +     * Make sure that "tx_buf" which is shared with the guest isn't a=
ccessed
>>>> +     * again after this point.
>>> This is a bit misleading because it *is* accessed in ffa_msg_send2_vm. =
The
>>> comment should say what you wrote as the last paragraph in the commit m=
sg.
>>=20
>> Yes, this should be something around:
>> Ensure validation and use of the message header use the same snapshot.
>>=20
>> Do you agree ?
> Yes. I'll fix on commit.

Thanks :-)

Bertrand

>=20
> ~Michal




From xen-devel-bounces@lists.xenproject.org Wed Aug 19 08:33:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 08:33:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394885.1633495 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbjM-0006Ko-6w; Wed, 19 Aug 2026 08:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394885.1633495; Wed, 19 Aug 2026 08:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwbjM-0006Kh-47; Wed, 19 Aug 2026 08:33:04 +0000
Received: by outflank-mailman (input) for mailman id 1394885;
 Wed, 19 Aug 2026 08:33:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwbjL-0006Kb-7J
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:33:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbjI-005Cdn-TD
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:33:00 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a856a29-8faa-0a2a0a5109dd-0a2a4509bb1e-32
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:33:00 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a856a3c-be1a-0a2a45090019-d1558034b582-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:33:00 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49557167508so7703535e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 01:33:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa11f832sm42564735e9.7.2026.08.19.01.32.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 01:32:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787128380; x=1787733180; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=DCJTQX+7EPYMYBKv6GGunUbsM7O1XB1lvOqnyK2ApEM=;
        b=B1/jU/4GKeSFRFiYJw+RPAcou90DeE0jaQFc31ZerKK8pQTHlUkaTHVMnZcxeotz3G
         Kz+PNPh/R2zLb7+kszP29CihAjAkFHPcTn1COoTthaROYalJfIp6LdszYF0xcidAXujl
         SrDuW+hHisk6iNXNd9upl8EAF0CILdzXxbyoZ0IbOxh+tq7/nZLks//PhV0eQ9HwE4vZ
         S8W1zN2mUy17wWetwPXC8NVYOyBbFbYeumobUgyXj0rjfE/ZQ3busGM58qQKz3m8FzI4
         EqDETQN23nGf2/7iWp0fh7EaZa3Fbo4QJsHFcYQ/+eKwPMA1kSXTRtrM73MJnumG2rxo
         qB+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787128380; x=1787733180;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=DCJTQX+7EPYMYBKv6GGunUbsM7O1XB1lvOqnyK2ApEM=;
        b=U91lB4qfqhsa+doAbfkreE+pld8DIWAdzbzk3eWk3+73LilKXztePlD/KB7ZpBQwTy
         7ZjjJ52OBwAwcmMP0pNXTADAJKqyJ4YhM7bwwZcUDW26XNhegRVZGyALm/u85ZzTCalx
         gfxc3u0sJQH4XQqqldCro7dk1lAZxFrw0zIpPWefeA+NbiuUtO9NV/BzIPLt5Qi370vJ
         EK9nOSWC+nWZ3gKK+RAeNirT5esh81O2yy4yuVQJZPh+aZYR8fJxf+ZJkBnfL++GSdCU
         cgmppwQF/wOI34BHt9y2JkR3pRMIXnWANfBAAdy+qSzi7ekMhka/p02xZvutdvNvDjnv
         njmA==
X-Forwarded-Encrypted: i=1; AHgh+RrPyVp0M4xv91Udyg6TOdS0gZblYKf55OdRuoRfKiFi0Mjq+W38UZ2LreKkao3ZP8Xr4mes9oPRlRM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwG1g8Xt08eIwFV8rXCGBhC71ILgW0wkhU6YqxX83A3v/n19Jmo
	25vJH7QDwzaKf492wOmroI+CtApF2PHBz2ucpmGpruvYh/AZw//H0jn3dUD4EYoZ/A==
X-Gm-Gg: AR+sD13uOf0DeU6NKRSS7P0vqeMiHiV3ldSYdzPXKsRcmINnVzHA+YenQr6AtOIYBhN
	Hq7PplTr0N3L9SuAHzUoTY46kqMCwD3DaDjXgM3e0KHfB7cYOvagh+ZQGxExZcsPXLf3t7u9D2e
	kW9rvQ4vU252TQGgGgiZezjUvlC5iB+njErhXEi6LFPf82l5jnIHZx5so6MmN2sF2BCKm/33B9k
	+a0gYc3zGVK+OPeOcg4MwW4S5qh201V3DFYh/GsCLyBpe45dPnrkW4gMYRDftKgfbmvliPNltGd
	rDVAmE20KP4/SCN72A4JLB+16hNn1AngzY+l5k2aS9LZk0jWAqtMLN7CC9Pgi9PDYusnk3AhuvP
	Sre+d7xIK/KhxYaKne5BHYxyuTZvB9xNZllgePlOtrvhTGkJHu/58evb5ay2yboP+KAQlABnpX+
	QMW6MXyz/RwHxV+9oh4jMuQAf8eaq69fe+4xVg5ZO0EKiHEDOjbx3nKlhwLxAWHYNLiIEHag8Hz
	AjUZsIlBwo/p7+/wCRL3FGFgvft527pHoUomKj+MHNU+auGozcm
X-Received: by 2002:a05:600c:3485:b0:499:a685:c10 with SMTP id 5b1f17b1804b1-499aa19a3b8mr55615185e9.4.1787128380251;
        Wed, 19 Aug 2026 01:33:00 -0700 (PDT)
Message-ID: <8de158e4-c9d6-47cf-887a-de8c061c5bcf@suse.com>
Date: Wed, 19 Aug 2026 10:32:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
 <50005702-c719-4ba9-92f7-4d5a0dc3e0b8@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <50005702-c719-4ba9-92f7-4d5a0dc3e0b8@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787128380-BDCC7034-96C3B0DF/0/0
X-purgate-type: clean
X-purgate-size: 3222

On 19.08.2026 09:53, Furkan Çalışkan wrote:
> 
> 
> On 8/19/26 10:22, Jan Beulich wrote:
>> On 19.08.2026 07:15, Furkan Caliskan wrote:
>>> sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
>>> singleshot_timer and poll_timer before it can fail -- these
>>> become live, linked into their target pCPU's per-cpu timer list
>>> regardless of what happens next. If the sched_alloc_udata() call
>>> further down then fails, the function frees the sched_unit via
>>> sched_free_unit() and returns 1, but never unlinks these three
>>> timers.
>>>
>>> The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
>>> returning nonzero it jumps to fail_wq, skipping fail_sched and
>>> thus sched_destroy_vcpu() -- the only function on this path that
>>> calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
>>> and the three timers embedded in it, while they are still linked
>>> into that shared list.
>>>
>>> This silently corrupts that list. It only shows up later, when
>>> something else touches a neighboring timer: sched_move_domain()
>>> crashed with "Assertion 'entry->prev->next == entry' failed" on a
>>> completely unrelated, valid vcpu's timer.
>>>
>>> Kill all three timers in sched_init_vcpu()'s own failure branch,
>>> so it doesn't depend on the caller reaching sched_destroy_vcpu()
>>> to undo what it set up itself.
>>>
>>> Fixes: 1ad5dad74cde ("[XEN] Re-jig VCPU initialisation -- VMX init requires generic VCPU")
>>
>> How did you arrive at this commit? It doesn't even touch sched_init_vcpu().
>> All it does is move kill_timer() invocations around. I think it's
>> d884b1077817, as that's where the "return SCHED_OP(init_vcpu, v)" was
>> introduced (i.e. where kill_timer() would have been necessary to call in
>> the error case). (I can't exclude the issue was pre-existing already at
>> that time, but that would require more analysis than I think is worth to
>> invest.)
> 
> Commit 1ad5dad74cde moved kill_timer() calls into sched_destroy_vcpu() 
> function, which is not called if sched_init_vcpu() fails. 
> Before that commit, kill_timer() calls were in sched_destroy_domain(), 
> which is called if sched_init_vcpu() returns non-zero to its caller, 
> alloc_vcpu(). 
> 
>         for ( i = 0; i < max; i++ )
>         {
>             if ( d->vcpu[i] != NULL )
>                 continue;
> 
>             cpu = (i == 0) ?
>                 default_vcpu0_location() :
>                 (d->vcpu[i-1]->processor + 1) % num_online_cpus();
> 
>             if ( alloc_vcpu(d, i, cpu) == NULL )
>                 goto maxvcpu_out;
>         }
> 
>         ret = 0;
> 
>     maxvcpu_out:
>         domain_unpause(d);
>         put_domain(d);
>     }
>     break;
> 
> put_domain() calls domain_destroy(), which then calls free_domain(), 
> which ultimately calls sched_destroy_domain().

Well, yes, except that - how would that have helped for a vCPU which
failed to be properly constructed? The function loops over all vCPU-s
in the domain, but that wouldn't include the vCPU in question.
alloc_vcpu() would (of course) insert the vCPU into the list only when
sched_init_vcpu() succeeds.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 08:51:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 08:51:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394917.1633532 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwc0p-00012u-2u; Wed, 19 Aug 2026 08:51:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394917.1633532; Wed, 19 Aug 2026 08:51:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwc0o-00012l-Vu; Wed, 19 Aug 2026 08:51:06 +0000
Received: by outflank-mailman (input) for mailman id 1394917;
 Wed, 19 Aug 2026 08:51:05 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwc0n-00012f-34
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:51:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwc0m-005FeO-Bu
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:51:04 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a856e77-8faa-0a2a0a5109dd-0a2a450cda14-2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:51:04 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a856e78-f479-0a2a450c0019-d155dd2fd402-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:51:04 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47f93b2fe4cso414486f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 01:51:04 -0700 (PDT)
Received: from [192.168.1.109] ([78.173.117.23])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa1755b2sm44905995e9.11.2026.08.19.01.51.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 01:51:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787129464; x=1787734264; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=46WDO2bhjbLW3XWaFiT9A3+j0YLlfUJtI+oF/pbYPyw=;
        b=CoT3jLpv+jcPGG6mGS+SWOgh0ugDKjMITTTBirw5jL8vS6No/S/xLeFL8Ji2VgfCHu
         BEimNec45omz6OU1oqDVbtUtFH7hO9OwOVLbvKqGRYoJf0ztY7JH7DiKA9JM1TcNHsv7
         lso/QkZVHe7Q0b906ivR5CnKC/wsF6avwpukreZ2QBZZXTHzIfXXjc0GHmsqr4/wwcFJ
         RC5UL16zW9ieNU0gcB+pEXafYkgahKB0eOLFFYqvwPy7Or/pSEWPXPoGEZ+0wo4I05vL
         xDF/kivoJ7Le0Vm36YAfavf3889RFwqiOMLT0jFC2Y3oUKkHzRxaQHpTYDeQ4ZkJe/xT
         d7dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787129464; x=1787734264;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=46WDO2bhjbLW3XWaFiT9A3+j0YLlfUJtI+oF/pbYPyw=;
        b=ddQlWxu3shzjLr+bLmKPt9G0jkNknCrR2ZLE0spYzqFh6G9mQ9nAVILZeOPJC4E1sd
         k/RR+FrElis1GoTJmr1Pmyq6yGh0r5jIczx3bF8oZNG7aRkQMOBha1c56Bi3QM/RcODo
         7Fxtb5/+xdTDFCgjoP6gkOOqOOxInOnmdGvms1Y65kbhXSc09bjEEIX6fitBaaf3szjb
         fP40umd1NDVw2UMFrfSRqp1lkTYQC9eXHTR1be4nqCyLYzKgDj91Nr1Z56jPEhl//zjb
         T/48ff6p4YZK9zjFTTQnPVTXEjSYzGPaWEYRCC7M84KLebmpPTZbh45NZQJpmP6xRQqw
         obNw==
X-Forwarded-Encrypted: i=1; AHgh+Rq8urqpTyxzrU7vUwXoPsOzr6e65bKUv7Mw7LYFBlZ0DWT9evoGSN2XOnN28Gx7T4dmkD8H9dEFDro=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHkNZdSfDMl43TPd3ABnPP4tU1kskillAaUu19Ig5nnKQucGBs
	rIEeZYUIG9jepw+/nyj67IU00Cu0155JXhLZD4qoP09xKZNJYfenxtdx
X-Gm-Gg: AR+sD13Uw0YAp3xDzDJRAgPSHHAW55jlq5jJ2zN3aPKhbgIOWRmpcJzkk2yfSZbms2W
	TJqabccHk/AykPnBsmp089gezxoPeFJtRRTQLzWqCRFCNiG+7Bufn9WtWouX/SelDe19bbR0zP6
	Ahvy9uTCn3Wahxc51yLE/Frj8zQc9/dE4V8ehM0h1hfym+lHont80AL77MJBKpgFasCnfXZUNGC
	cEbO1HdCs7Tu9+h+JQh8XRD4BDzK6iSrBqzvqbVPSaAOBbCO0Rwf4DRbnv463grI5VPd1Yu6/yw
	tIZGCYf7lxnMyw2C1+c0Vng/EVA6R6Xs+eVOHt6UoPs80etFUAulDpU8PMCcyCscm3FdLulec7o
	OyL9Goydd+7OsO25fPTyDKrc4HK4T+Ae01ihbi7oJ7uwto025aOGHgE0xwJ1tBGtlaItn6rW7t+
	7wtalYWfIYEhEYXJ9rGKsVSfp3V/3cnLfOY06px9a3RiJiQ0VvI/dSxt9Q9i7XWt3zXovM8/sG
X-Received: by 2002:a05:600c:6211:b0:499:a760:722f with SMTP id 5b1f17b1804b1-499aa1ba0b7mr53472815e9.13.1787129463726;
        Wed, 19 Aug 2026 01:51:03 -0700 (PDT)
Message-ID: <c221f28d-2710-4fe5-9261-081678d973c0@gmail.com>
Date: Wed, 19 Aug 2026 11:50:57 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Jan Beulich <jbeulich@suse.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
 <50005702-c719-4ba9-92f7-4d5a0dc3e0b8@gmail.com>
 <8de158e4-c9d6-47cf-887a-de8c061c5bcf@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <8de158e4-c9d6-47cf-887a-de8c061c5bcf@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787129464-03CD3A5B-F8B348C0/0/0
X-purgate-type: clean
X-purgate-size: 3525



On 8/19/26 11:32, Jan Beulich wrote:
> On 19.08.2026 09:53, Furkan Çalışkan wrote:
>>
>>
>> On 8/19/26 10:22, Jan Beulich wrote:
>>> On 19.08.2026 07:15, Furkan Caliskan wrote:
>>>> sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
>>>> singleshot_timer and poll_timer before it can fail -- these
>>>> become live, linked into their target pCPU's per-cpu timer list
>>>> regardless of what happens next. If the sched_alloc_udata() call
>>>> further down then fails, the function frees the sched_unit via
>>>> sched_free_unit() and returns 1, but never unlinks these three
>>>> timers.
>>>>
>>>> The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
>>>> returning nonzero it jumps to fail_wq, skipping fail_sched and
>>>> thus sched_destroy_vcpu() -- the only function on this path that
>>>> calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
>>>> and the three timers embedded in it, while they are still linked
>>>> into that shared list.
>>>>
>>>> This silently corrupts that list. It only shows up later, when
>>>> something else touches a neighboring timer: sched_move_domain()
>>>> crashed with "Assertion 'entry->prev->next == entry' failed" on a
>>>> completely unrelated, valid vcpu's timer.
>>>>
>>>> Kill all three timers in sched_init_vcpu()'s own failure branch,
>>>> so it doesn't depend on the caller reaching sched_destroy_vcpu()
>>>> to undo what it set up itself.
>>>>
>>>> Fixes: 1ad5dad74cde ("[XEN] Re-jig VCPU initialisation -- VMX init requires generic VCPU")
>>>
>>> How did you arrive at this commit? It doesn't even touch sched_init_vcpu().
>>> All it does is move kill_timer() invocations around. I think it's
>>> d884b1077817, as that's where the "return SCHED_OP(init_vcpu, v)" was
>>> introduced (i.e. where kill_timer() would have been necessary to call in
>>> the error case). (I can't exclude the issue was pre-existing already at
>>> that time, but that would require more analysis than I think is worth to
>>> invest.)
>>
>> Commit 1ad5dad74cde moved kill_timer() calls into sched_destroy_vcpu() 
>> function, which is not called if sched_init_vcpu() fails. 
>> Before that commit, kill_timer() calls were in sched_destroy_domain(), 
>> which is called if sched_init_vcpu() returns non-zero to its caller, 
>> alloc_vcpu(). 
>>
>>         for ( i = 0; i < max; i++ )
>>         {
>>             if ( d->vcpu[i] != NULL )
>>                 continue;
>>
>>             cpu = (i == 0) ?
>>                 default_vcpu0_location() :
>>                 (d->vcpu[i-1]->processor + 1) % num_online_cpus();
>>
>>             if ( alloc_vcpu(d, i, cpu) == NULL )
>>                 goto maxvcpu_out;
>>         }
>>
>>         ret = 0;
>>
>>     maxvcpu_out:
>>         domain_unpause(d);
>>         put_domain(d);
>>     }
>>     break;
>>
>> put_domain() calls domain_destroy(), which then calls free_domain(), 
>> which ultimately calls sched_destroy_domain().
> 
> Well, yes, except that - how would that have helped for a vCPU which
> failed to be properly constructed? The function loops over all vCPU-s
> in the domain, but that wouldn't include the vCPU in question.
> alloc_vcpu() would (of course) insert the vCPU into the list only when
> sched_init_vcpu() succeeds.
> 
> Jan

Ah, I missed that compeletely - you're right.
sched_destroy_domain() wouldn't have reached the failed vCPU anyway.

In that case, d884b1077817 makes total sense here.

Furkan



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 09:00:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 09:00:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394931.1633540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwc9N-0001l6-VU; Wed, 19 Aug 2026 08:59:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394931.1633540; Wed, 19 Aug 2026 08:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwc9N-0001kz-SW; Wed, 19 Aug 2026 08:59:57 +0000
Received: by outflank-mailman (input) for mailman id 1394931;
 Wed, 19 Aug 2026 08:59:56 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwc9M-0001ka-AZ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:59:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwc9L-005HdV-NZ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:59:55 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a85706e-2eae-0a2a0a5409dd-0a2a4509d87c-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:59:55 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a85708b-be1a-0a2a45090019-d155802be0e1-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:59:55 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-4956242332dso7182595e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 01:59:55 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9aa7e8dsm28321935e9.0.2026.08.19.01.59.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 01:59:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787129995; x=1787734795; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=5mnOP/uz5PJBUYJ7+Pmzbd2rmvd9WdUt1+NtWRw3KbI=;
        b=n37Wyd01qQoufqs3yEiwLdy+yA66rnXYf+1qH1C7p15QtGswU2wzjPrPVjVlicS2yi
         aZuU0GPxW36cW/E4DtGYVS1N73O9dR0tIU9EI3WE0TFMLZYyaHVQGpdRsbrMxR5x487F
         KVyOHhS65k+Gk9zSJEfc8wT7QHE4+LKKjD5H5E2giRN3/wNT7QyAXf0gXQTBlzsqRH6q
         fwV3tq5+aER7Zu8216Sxkb/18cBrpnHCkU94Wb60CoXNXTnwsEawQTMFoLKQfeTmUVjK
         X7LD4Ap08yFAu2vAtnZJsWmq78w39iQ0EBeoocFwo9kQGu1rncytRns8IE9nkYlKukNQ
         VQuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787129995; x=1787734795;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=5mnOP/uz5PJBUYJ7+Pmzbd2rmvd9WdUt1+NtWRw3KbI=;
        b=JCjHD8wHUWB8FqCZOUH5Ox+at3UYPQ2R72wv6/bVery7KYxs+rsZ6H/QLrZbWjQhMO
         bep+QzLzVbD2eXxOAjzHuOQryLduUnUetVxcLYNhrrsOG6pPcVcJM93hU1+GbBFRSpvX
         MBb2YGo5FeOhY/poQ9y0/icVC0Nu2TvPnkGp2VpP+B3Bhyb3YHG+7B6EPFZl+1tfJB4n
         t2LRfL/95zS78eDYjeIfUrhlfc60XXTZUvayicAKGSNmg7XfPQHkdORC5PQy/K27pQfD
         +GFBNiqlfDee+G2khCk09NJOdv+3tFxr2o+rbkcO3WhSG2JvB+x+AJHoHTAC3GZc3tNB
         bfNw==
X-Forwarded-Encrypted: i=1; AHgh+Rq0WeyEO7epkxcuSH+vmTdlDN5fwlpknZnyiJa5Guc9hhW8tDGlI4uxbNXUOwA7akNmhpElCY/1F9g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyJztAZORgUDHzgefr7YfqpJM2bSkhA/SockWSvyMdqzp0tR/2/
	1KslcpP7xVbSPEa2+zms8PwDQG8iY7X/JxtvhCGKy43HH8nsYo/Bv2gI
X-Gm-Gg: AR+sD121WOJCem1nh2zhFDFB8HKAC3CuhZhFtaoDnUtiCT94iNfOtg229A8hjFROhF8
	2HGSkxat+gSKCNfobpXgRrcgSqRnFDPuX/ndtfg1lGxOufT0M3veTu8EO8vZ/B/3fg8sff8vVE5
	xssTiO05KqMxsXlUQqrgpyqKKv1UpXKurpq83KgdzruXzoCo9Ghpat3ENEQJMBdKFnP2TqOGgzD
	Q3OKRLXwajVI+8d69ivXezLbA0Mi5LtBKXfK5JPFnGUr1fIh0SWqetdvsPvTYaQ1rtxeUihHMpb
	RBsviryimjuQR4CM+WlVXCC1wZzhRP1tyUIBDQmTzoZPHZDNfgsp4RNtajFV67LMz6VGHHn/CYU
	KZJYbY1VMdG8buJVY3Wbw0Yy98ZCuXa/DUMuyWiVLP8yQLtCJCfpeHvDu8GmplTPwRxeiZCdHr6
	6HLCKmBBJGiO0llTft1+0E1Qkbr8ZCLVh92k+TeXZDSb6AI0/bEVyIq9x0lpCO9gHYYIuKHBEp4
	gH3nxIVv1pmbuI8+GR94vsVBOaTmwXWv2NamZZdcto=
X-Received: by 2002:a05:600c:4e94:b0:499:78b3:7b36 with SMTP id 5b1f17b1804b1-499aa1b549cmr51115725e9.11.1787129994885;
        Wed, 19 Aug 2026 01:59:54 -0700 (PDT)
Message-ID: <38fd0ba7-562f-49e2-8453-be14f79f1c3c@gmail.com>
Date: Wed, 19 Aug 2026 10:59:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
 <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
 <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
 <f6e12465-dcd0-4f04-bdd4-8e1943e1ade7@suse.com>
 <fa2924e9-139c-4cdc-9dd4-4b3a26a21fa2@gmail.com>
Content-Language: en-US
In-Reply-To: <fa2924e9-139c-4cdc-9dd4-4b3a26a21fa2@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787129995-BFED6034-51068E59/10/73395122804
X-purgate-type: spam
X-purgate-size: 6397



On 8/18/26 6:04 PM, Oleksii Kurochko wrote:
> 
> 
> On 8/18/26 10:29 AM, Jan Beulich wrote:
>> On 17.08.2026 18:10, Oleksii Kurochko wrote:
>>> On 8/12/26 5:48 PM, Jan Beulich wrote:
>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/traps.c
>>>>> +++ b/xen/arch/riscv/traps.c
>>>>> @@ -191,6 +191,67 @@ static void timer_interrupt(void)
>>>>>        raise_softirq(TIMER_SOFTIRQ);
>>>>>    }
>>>>> +static always_inline unsigned long get_faulting_gpa(void)
>>>>
>>>> May I suggest to use always_inline only when inlining is _functionally_
>>>> required?
>>>
>>> Sure. But it ins't clear to me why it isn't a case here? Is it connected
>>> to that function is static and too simple so a compiler will do by 
>>> itself?
>>
>> Counter question: What is it that would functionally break if the 
>> function
>> ended up not being inlined? (This is the question you generally need to
>> answer to justify use of always_inline. Of course there's the additional
>> case of performance being affected, but I don't view that as applicable
>> here; I'm open to be proven wrong, though.)
> 
> Now it is clear how to identrify if function should be always_inline.
> 
> I put it only for the purpose to be sure that this function won't be 
> called with prologue/epilogue but I agree that compiler will do that by 
> itself.
> 
>>
>>>>> +{
>>>>> +    /*
>>>>> +     * According to RISC-V spec:
>>>>> +     *  18.2.8. Hypervisor Trap Value Register (htval)
>>>>> +     *   ...
>>>>> +     *   A guest physical address written to htval is shifted 
>>>>> right by 2 bits
>>>>> +     *   to accommodate addresses wider than the current XLEN.
>>>>> +     *   ...
>>>>> +     *   If the least-significant two bits of a faulting guest 
>>>>> physical address
>>>>> +     *   are needed, these bits are ordinarily the same as the
>>>>> +     *   least-significant two bits of the faulting virtual 
>>>>> address in stval.
>>>>> +     *   For faults due to implicit memory accesses for VS-stage 
>>>>> address
>>>>> +     *   translation, the least-significant two bits are instead 
>>>>> zeros. These
>>>>> +     *   cases can be distinguished using the value provided in 
>>>>> register htinst.
>>>>> +     */
>>>>> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>>>
>>>> Well, okay, but instead of not losing the bottom two bits you're now 
>>>> losing
>>>> the top two ones.
>>>
>>> Oh, right, I will add a cast ((uint64_t)csr_read(CSR_HTVAL) << 2) | ...
>>>
>>> It will cover all the cases RV32 which has 34-bit guest address and it
>>> will be enough for RV64 where GPA is 59bit (the highest possible for 
>>> Sv59).
>>
>> Only if the function return type then also changes.
>>
>>>> Also the spec reads as if htval only _may_ hold the original address 
>>>> of the
>>>> faulting access. What if htval ends up 0?
>>>
>>> good point. then we have to emulate fault instruction and get an address
>>> from an instruction. I think that for now it will be enough just to
>>> support platforms which always write GPA to HTVAL.
>>>
>>> If I understand correctly if htval is supported by platform then htval
>>> will be always filled for guest page fault. To verify if HTVAL is
>>> supported we could do:
>>>
>>> 'Unless it has reason to assume otherwise (such as a platform standard),
>>> software that writes a value to htval should read back from htval to
>>> confirm the stored value.'
>>
>> How does this matter here? It's one thing for htval to be capable of
>> holding (all?) non-zero values, and another that it would always be
>> written. If the platform doesn't indicate the behavior, I fear you have
>> to assume that you may (perhaps even randomly) observe 0.
> 
> So to be very sure we could check for two extensions: Sstval and Shtval.
> They will guarantee that under any circumstances it will be filled.
> 
> Also, as an option we could check that htinst value isn't zero as 
> according to the spec:
> 
> For guest-page faults, the trap instruction register is written with a 
> special pseudoinstruction value if:
> (a) the fault is caused by an implicit memory access for VS-stage 
> address translation, and (b) a nonzero
> value (the faulting guest physical address) is written to mtval2 or htval.
> 
> So if htinst != 0 then htval is filled with GPA and a nonzero guest 
> physical address written to mtval2/htval shall correspond to the exact 
> virtual address written to mtval/stval.

I've re-read SPEC again and it looks like htinst != 0 doesn't guarantee 
that htval and stval will contain necessary for me here faulty 
instruction. What I wrote above guarantee that if a fault during 
VS-stage translation failed then it htval will contatain GPA of PTE with 
which was an issue.

So I have to blindly believe that HTVAL and STVAL will always contain 
necessary for me data as KVM and other hypervisor does or introduce here 
software guest page table walker if Sstvala and Shtvala aren't provided 
by platform.

~ Oleksii

> 
> But if htinst is 0 then we have to do VS-stage software pagewalk to get 
> GPA and also we will need to decode instruction to get GVA.
> 
> I am thinking if it will be okay for now to cover the case htinst != 0 
> and have BUG_ON(!htinst) to not miss that the possible future case when 
> VS-stage s/w page walks and parsing of GVA from an instruction are 
> needed. I think it is fine as all real boards on which I was able to 
> test Xen has htval and stval properly filled and of course QEMU code 
> guarantees that htval and stval will be properly filled in the case of 
> QEMU.
> Also, KVM is based also only htval and stval and I assume that they 
> tested it on real hardware too so it seems like it is okay to go with 
> solution that for now we are using htval + stval to get faulty address.
> 
>>
>>> And is it true because:
>>> ```
>>> A value of zero in mtval signifies either that the feature is not
>>> supported, or an illegal zero instruction was fetched.
>>> ```
>>> (yes, it is about mtval but I asssume that htval has the same 
>>> behaviour').
>>
>> Right, but what you quote is specific to illegal instruction exceptions.
> 
> Oh, right.
> 
> ~ Oleksii



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 09:29:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 09:29:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394960.1633551 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwcc6-00063i-6S; Wed, 19 Aug 2026 09:29:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394960.1633551; Wed, 19 Aug 2026 09:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwcc6-00063b-1v; Wed, 19 Aug 2026 09:29:38 +0000
Received: by outflank-mailman (input) for mailman id 1394960;
 Wed, 19 Aug 2026 09:29:37 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wwcc5-00063V-Ls
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:29:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwcc4-0023kS-VP
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:29:36 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a857776-8faa-0a2a0a5109dd-0a2a450abf16-26
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:29:36 +0200
Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a85777d-f2d2-0a2a450a0019-a0658309992a-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:29:34 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id DDFEA833DCF6;
 Wed, 19 Aug 2026 05:27:37 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech
Subject: Re: Re: [PATCH v4] x86/nSVM: Validate the L1 IOPM physical address range
Date: Wed, 19 Aug 2026 10:25:38 +0100
Message-ID: <20260819092538.2765153-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <e6f35ea6-77e2-481a-b695-421087e60edf@suse.com>
References: <e6f35ea6-77e2-481a-b695-421087e60edf@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787131774-4BAD4CFC-156D7123/0/0
X-purgate-type: clean
X-purgate-size: 2169

On 18.08.2026 11:23, Jan Beulich wrote:
>On 17.08.2026 18:59, Abdelkareem Abdelsaamad wrote:
>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
>> @@ -282,7 +282,7 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs)
>>      return 0;
>>  }
>>  
>> -static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>> +static int nsvm_vmrun_permissionmap(struct vcpu *v)
>>  {
>>      struct svm_vcpu *arch_svm = &v->arch.hvm.svm;
>>      struct nestedsvm *svm = &vcpu_nestedsvm(v);
>> @@ -294,6 +294,17 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v, bool viopm)
>>      enum hvm_translation_result ret;
>>      unsigned long *ns_viomap;
>>      bool ioport_80 = true, ioport_ed = true;
>> +    /* IOPM is structured as a linear array of 64K+3 bits. */
>> +    const unsigned long nr_iopm_additional_pages = PFN_DOWN((0x10000 + 8) / 8 - 1);
>
>Hm, the expression I did suggest was indeed off by one, yet yours doesn't fit
>the comment very well. What's wrong with PFN_DOWN((0x10000 + 3) / 8) or
>PFN_DOWN((0xffff + 4) / 8)?
In the expression I wrote, I was trying to maintain maximum fidelity to the
exact byte count and fetch the last byte index, even though PFN_DOWN ultimately
maps both 8192 and 8193 to 2 pages to have more fidelity to the original
calculation. It probaly looks a bit over-engineered but I wanted to keep as
much fidelity to the actual expression.
> +    gfn_t ns_iopm_end =
> +        gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), nr_iopm_additional_pages);
>
>I'm also inclined to suggest to drop the local variable, as it's used just
>here. The overall result would be
>
>    /* IOPM is structured as a linear array of 64K+3 bits. */
>    gfn_t ns_iopm_end = gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa),
>                                PFN_DOWN((0x10000 + 3) / 8));
>
>which imo is a little easier to follow. Preferably with those adjustments
>(happy to carry out while committing, but please confirm):
Sounds good to me! Please go ahead and drop it while committing. Thank you.
>Reviewed-by: Jan Beulich <jbeulich@suse.com>
>
>Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 09:52:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 09:52:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395006.1633558 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwcyC-0001Nb-SP; Wed, 19 Aug 2026 09:52:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395006.1633558; Wed, 19 Aug 2026 09:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwcyC-0001NU-Pl; Wed, 19 Aug 2026 09:52:28 +0000
Received: by outflank-mailman (input) for mailman id 1395006;
 Wed, 19 Aug 2026 09:52:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwcyB-0001NO-Gc
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:52:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwcyA-005902-TD
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:52:26 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a857cd7-2eae-0a2a0a5409dd-0a2a450cc9e6-10
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:52:26 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a857cda-f479-0a2a450c0019-d155dd2db834-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:52:26 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47362928f65so734224f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 02:52:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14c338dsm3901352f8f.25.2026.08.19.02.52.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 02:52:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787133146; x=1787737946; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=BTSnvSUpkyd3JhkthQ4Vco9aYiTArRzCCgBbmokvk/4=;
        b=UmuLXpJi3VoM5+OOEJUfvkQCRDOaEvUC3SN6mbPXOkrrrVcadxpRseLaDVOu0CgMNo
         udnjD86E/qtVXj8sGVvEHUoOcz5AfWVSbuQoOfCKUWqckCOOKgICvRJ8o1PXpvQ/HD6c
         8PbY1C1LMWl2A3Jb3If3IZbpuRIt4YJzDuyzGdtPRU8YjgorIyCdUxEeRwMEK7DuSP2C
         MN8Urc56YcObzFC59vB/BeiCNvmk1FmBP71xuQv1pmlkLFd36ByIz/q/GiQkw1wGkvsk
         lmDOXNKpET7Czx6hWj7tnCoUAbVbNM2P684F+7gCP9wiLF6PbdvgXMHx+Bg26xtt6TYl
         2zZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787133146; x=1787737946;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=BTSnvSUpkyd3JhkthQ4Vco9aYiTArRzCCgBbmokvk/4=;
        b=ULGpmevyCSbS5SNBArhoRoa2c6k9eP7hkvI3z0/aoqgbK2GX+yK/Kqr7VL4z9rRxrE
         ZCh2ddpp65pOdVZmv1xqQ5cIuls3JW04E/NexGUxg6kge8Tmy+nphLatrq3FQjOke8E+
         1LkMqiqsbVdxkwQksTo1eIptYIXtnvkpF60EejlgXKOIAZBoGwD0nQLw/DcR2qN67ENd
         kMdUCUk2W/E9+v7jj8v5+NeBojoPbTr6Tz5DROgiTPay+k9lkwxN9N7xaknnrKgdkerm
         RCB3gYvWq2prJ3+5kQn4KeADMD17BmOKJJB9OAzEKyP8IDTgjQOLs1mPU2wzd4+QQDMv
         qVDQ==
X-Forwarded-Encrypted: i=1; AHgh+RoNzfJmvSfVTB4Bb6xxkWnTAfT75DpZLLDCWVDhmmfib15fmW1CVnLUQDhB3j8Xz/TUmuHiuE8BOec=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywhkc0KpuC1VTiowuKxrClRpjJoBU31+LXCDeL8j1PSattRTRR6
	kTBOcXUiseP/IH3o2zHz/2uHW4tG9uK5Jsp4wpy4XYL/uu+RYml3bcPFQR3OXYty4Q==
X-Gm-Gg: AR+sD10rdO/IjhpAiDmZ+nK8rBMS5wN2c+enGzkzQBEo9/o5NyEOdRVqYk1y7oT23jN
	dXryI0yZ3M75ZTymYAHqA6wk1bxwtb9K35S94kA0olyStWKBAVu99C3k/RhdrTYtvs+GYah+3RR
	Ka76qJSydOVMrsCLk2hXYsbB56V3WKJC50OTY/VziH+cr7MypndVjbDZPg21qimUAqmczz253+F
	2eGv5k+HaTzBZV81K58Fp7pHcwK2iOzUbQi8FtcqckvgFVhAp6pUpNzpyFRq/r6f5FmKaAsEJVU
	2yvsbyMC/Sh7AvQC7WqW4iRg9Y2pyU3I3nmoF7w/DNeuc/d3+c114JhvHHkXb7TGUVvZIhLl58L
	T2Jrx/Koi7z9YtOfyJZVI0z5I/sg0bjAv+GsuW0hFcdqK5RJn+UtmPyO1qli65sO2A/m5EiUrSi
	11aOafo3MZjqCpb2se0Pard7RzluB74QhNDwd8OHimJXY+tqD8zcsTzOq1+X+h2q77GJBky07ml
	HPlwlTJYJmksr2IPOzG0Az/J/OgHvtT+ZBkbz+6dC/pEgPO590Y
X-Received: by 2002:a05:6000:2507:b0:47e:81aa:3832 with SMTP id ffacd0b85a97d-482b1fe7f68mr5261938f8f.16.1787133146151;
        Wed, 19 Aug 2026 02:52:26 -0700 (PDT)
Message-ID: <0d0d45b2-8682-4ae3-9f64-bdcb4add09b1@suse.com>
Date: Wed, 19 Aug 2026 11:52:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
 <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
 <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
 <f6e12465-dcd0-4f04-bdd4-8e1943e1ade7@suse.com>
 <fa2924e9-139c-4cdc-9dd4-4b3a26a21fa2@gmail.com>
 <38fd0ba7-562f-49e2-8453-be14f79f1c3c@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <38fd0ba7-562f-49e2-8453-be14f79f1c3c@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787133146-76CDBA5B-2E5AD7FB/0/0
X-purgate-type: clean
X-purgate-size: 4335

On 19.08.2026 10:59, Oleksii Kurochko wrote:
> On 8/18/26 6:04 PM, Oleksii Kurochko wrote:
>> On 8/18/26 10:29 AM, Jan Beulich wrote:
>>> On 17.08.2026 18:10, Oleksii Kurochko wrote:
>>>> On 8/12/26 5:48 PM, Jan Beulich wrote:
>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>> +{
>>>>>> +    /*
>>>>>> +     * According to RISC-V spec:
>>>>>> +     *  18.2.8. Hypervisor Trap Value Register (htval)
>>>>>> +     *   ...
>>>>>> +     *   A guest physical address written to htval is shifted 
>>>>>> right by 2 bits
>>>>>> +     *   to accommodate addresses wider than the current XLEN.
>>>>>> +     *   ...
>>>>>> +     *   If the least-significant two bits of a faulting guest 
>>>>>> physical address
>>>>>> +     *   are needed, these bits are ordinarily the same as the
>>>>>> +     *   least-significant two bits of the faulting virtual 
>>>>>> address in stval.
>>>>>> +     *   For faults due to implicit memory accesses for VS-stage 
>>>>>> address
>>>>>> +     *   translation, the least-significant two bits are instead 
>>>>>> zeros. These
>>>>>> +     *   cases can be distinguished using the value provided in 
>>>>>> register htinst.
>>>>>> +     */
>>>>>> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>>>>
>>>>> Well, okay, but instead of not losing the bottom two bits you're now 
>>>>> losing
>>>>> the top two ones.
>>>>
>>>> Oh, right, I will add a cast ((uint64_t)csr_read(CSR_HTVAL) << 2) | ...
>>>>
>>>> It will cover all the cases RV32 which has 34-bit guest address and it
>>>> will be enough for RV64 where GPA is 59bit (the highest possible for 
>>>> Sv59).
>>>
>>> Only if the function return type then also changes.
>>>
>>>>> Also the spec reads as if htval only _may_ hold the original address 
>>>>> of the
>>>>> faulting access. What if htval ends up 0?
>>>>
>>>> good point. then we have to emulate fault instruction and get an address
>>>> from an instruction. I think that for now it will be enough just to
>>>> support platforms which always write GPA to HTVAL.
>>>>
>>>> If I understand correctly if htval is supported by platform then htval
>>>> will be always filled for guest page fault. To verify if HTVAL is
>>>> supported we could do:
>>>>
>>>> 'Unless it has reason to assume otherwise (such as a platform standard),
>>>> software that writes a value to htval should read back from htval to
>>>> confirm the stored value.'
>>>
>>> How does this matter here? It's one thing for htval to be capable of
>>> holding (all?) non-zero values, and another that it would always be
>>> written. If the platform doesn't indicate the behavior, I fear you have
>>> to assume that you may (perhaps even randomly) observe 0.
>>
>> So to be very sure we could check for two extensions: Sstval and Shtval.
>> They will guarantee that under any circumstances it will be filled.
>>
>> Also, as an option we could check that htinst value isn't zero as 
>> according to the spec:
>>
>> For guest-page faults, the trap instruction register is written with a 
>> special pseudoinstruction value if:
>> (a) the fault is caused by an implicit memory access for VS-stage 
>> address translation, and (b) a nonzero
>> value (the faulting guest physical address) is written to mtval2 or htval.
>>
>> So if htinst != 0 then htval is filled with GPA and a nonzero guest 
>> physical address written to mtval2/htval shall correspond to the exact 
>> virtual address written to mtval/stval.
> 
> I've re-read SPEC again and it looks like htinst != 0 doesn't guarantee 
> that htval and stval will contain necessary for me here faulty 
> instruction. What I wrote above guarantee that if a fault during 
> VS-stage translation failed then it htval will contatain GPA of PTE with 
> which was an issue.
> 
> So I have to blindly believe that HTVAL and STVAL will always contain 
> necessary for me data as KVM and other hypervisor does or introduce here 
> software guest page table walker if Sstvala and Shtvala aren't provided 
> by platform.

Why "blindly believe"? Checking for the necessary extension(s) should be
an option. Adding fallback code for when an extension isn't available can
come later, can't it?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 09:58:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 09:58:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395025.1633568 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwd3y-000200-Fy; Wed, 19 Aug 2026 09:58:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395025.1633568; Wed, 19 Aug 2026 09:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwd3y-0001zt-CV; Wed, 19 Aug 2026 09:58:26 +0000
Received: by outflank-mailman (input) for mailman id 1395025;
 Wed, 19 Aug 2026 09:58:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwd3w-0001zn-Oo
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 09:58:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwd3w-00EKAH-5P
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:58:24 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a857e28-bab6-0a2a0a5309dd-0a2a450aa33e-44
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:58:24 +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 <oleksii.kurochko@gmail.com>)
 id 6a857e3f-f2d2-0a2a450a0019-d155802bd528-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:58:24 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so7293155e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 02:58:24 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14c45d1sm4022125f8f.30.2026.08.19.02.58.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 02:58:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787133503; x=1787738303; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=WwE3QN3aeSi+hrmkACfe8EjgEbp/hhVhsQ8C2TOXVNk=;
        b=FJSSBK7N3fgIjkiO9j/9C/qY2Cw6h793sCLkv/ZEfFfKT8OFXiky09TSF34Z1Yyg71
         vknC5A8q1VQPNRFYhuszFqdfud4sLcqb8+5JjAldhJLEtqmZQ0yj8/zwF/wQr2v3it/u
         9Ozm87boFNcfQ/bV16T9tHcd8D+eMKJC2g8QReZGpP8/zO71LMmXptt69KNYpYhmflc0
         3n8iD47mVDjawUCuAh+8lBsl5O0tGUnqHS/Nq707ESBOQHsA8MiovuFKcfiP8a5WoTWE
         CcA0PaarSPmVc6XzvIHcwTpTh/X1KVTzEwjWLerNOaiE8a5IhdT7Y2PLY2NluqdbKjwd
         VaWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787133503; x=1787738303;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=WwE3QN3aeSi+hrmkACfe8EjgEbp/hhVhsQ8C2TOXVNk=;
        b=p9ETjk7d+JmhBgQ9D5HzgYtrbHZScRZ45S2sjjlQnqeQu40GWNRPdRAi7Mrtav6ssH
         2plADj9VnQab0cAF45R1ga7UjfH08+3t8whCA6KGZ2IFcpAvkIJMEIVQaFevpsq0+r9M
         fjqQXFoqRjU5Dk5B5ogqhM422ihAgcppbyYWoiO+Ld/5anEC4b8G3LuX8TDhd5c005lu
         l5Q9rkri0rSr5ZNwEojfhbi8vkKSw5Tf8cXFN69z1TTHyV/Q0WlkOALkvG1yitAUn1OO
         dhVOxh5Xry0xl7InmI8KVneSQQFVNFtipZSvgWgGHruk3tnB6JcBvjWq01PHYQnwhI1Y
         gzUg==
X-Forwarded-Encrypted: i=1; AHgh+RqOE1CvkN8mj97PGdgpdEATQKRohcYWt2Qw3ZCyDni2HOEt+hBUu3rWNbSnndR9OaXkYSSGQDxpJ9A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6GaQxw+sODtzhOcS8vb9TVMyoVrWYjWGHSBiE/p3D9kVVcTBo
	4xKQjP+a4nHCBe8wn+CdyjPSM4wsRzM0lDSHJOGLlyHX0tohbKWgzLOI
X-Gm-Gg: AR+sD10FhpSQckOb8F+n2oeO86ORcu8I1q5VaDPhPL6AkGg74+h7IioARCC7u0abN8j
	GDsemqohxgctIbgllcA7SPmnVddfFJ+HIUvB+IlnoPcGgIiqounjTXKgzNSHuwPMW8cL36UAsVZ
	sMo+p0yfzWgoj/1QaBS4DNlAd37XO/WhglfNUiOB1z1rFf1ecQQ4X+6mLeqwk27pivoEkMc+HfN
	M9uu5rWPNkcEFpncEPj8ku1V4NxdYD18lIwCGZi1n7otzPyD30RchKJXU4EI9jJ0N9Hg4gndW5H
	iYmSR7Wewe3ULzsW/AnndseHZXgBK436MrMelprYjwVDGhLRIsIu06+nAUZeXzequyOezIyYUWJ
	bYb5FAUdX/cN60nt//SUQz+3xVzv1sPc4y+wWXjqddtGD1N4QNjVPNCipo8cwoJazCa8e5q4DGa
	vdx0AyGGMTy3QmuB43TjaAC9fUamOnGTFfi8LcvPpBYQigRLSb+To7cwFyJNioRLHY2r40o7yPO
	yJaS0xb64OjUW1zN4EFmPKq1nTxPg8Mk7Ex7T7S9jw=
X-Received: by 2002:a05:600c:524f:b0:499:795a:c5fc with SMTP id 5b1f17b1804b1-499aa17baafmr53213415e9.7.1787133503360;
        Wed, 19 Aug 2026 02:58:23 -0700 (PDT)
Message-ID: <e800e7f3-bd42-4e79-9d5f-9f46f3a2437b@gmail.com>
Date: Wed, 19 Aug 2026 11:58:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 14/17] xen/riscv: add guest page fault handling stub
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <7ef8919f12c269d180a2b56a83218cc54e0e357c.1784560663.git.oleksii.kurochko@gmail.com>
 <ab3eb1be-ec62-42ae-8966-e2801752ce4f@suse.com>
 <61b9f565-7193-4192-9f57-1b4bd258fc11@gmail.com>
 <f6e12465-dcd0-4f04-bdd4-8e1943e1ade7@suse.com>
 <fa2924e9-139c-4cdc-9dd4-4b3a26a21fa2@gmail.com>
 <38fd0ba7-562f-49e2-8453-be14f79f1c3c@gmail.com>
 <0d0d45b2-8682-4ae3-9f64-bdcb4add09b1@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <0d0d45b2-8682-4ae3-9f64-bdcb4add09b1@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787133504-526DECFC-F47D1AEC/10/73395122804
X-purgate-type: spam
X-purgate-size: 4512



On 8/19/26 11:52 AM, Jan Beulich wrote:
> On 19.08.2026 10:59, Oleksii Kurochko wrote:
>> On 8/18/26 6:04 PM, Oleksii Kurochko wrote:
>>> On 8/18/26 10:29 AM, Jan Beulich wrote:
>>>> On 17.08.2026 18:10, Oleksii Kurochko wrote:
>>>>> On 8/12/26 5:48 PM, Jan Beulich wrote:
>>>>>> On 20.07.2026 18:02, Oleksii Kurochko wrote:
>>>>>>> +{
>>>>>>> +    /*
>>>>>>> +     * According to RISC-V spec:
>>>>>>> +     *  18.2.8. Hypervisor Trap Value Register (htval)
>>>>>>> +     *   ...
>>>>>>> +     *   A guest physical address written to htval is shifted
>>>>>>> right by 2 bits
>>>>>>> +     *   to accommodate addresses wider than the current XLEN.
>>>>>>> +     *   ...
>>>>>>> +     *   If the least-significant two bits of a faulting guest
>>>>>>> physical address
>>>>>>> +     *   are needed, these bits are ordinarily the same as the
>>>>>>> +     *   least-significant two bits of the faulting virtual
>>>>>>> address in stval.
>>>>>>> +     *   For faults due to implicit memory accesses for VS-stage
>>>>>>> address
>>>>>>> +     *   translation, the least-significant two bits are instead
>>>>>>> zeros. These
>>>>>>> +     *   cases can be distinguished using the value provided in
>>>>>>> register htinst.
>>>>>>> +     */
>>>>>>> +    return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>>>>>
>>>>>> Well, okay, but instead of not losing the bottom two bits you're now
>>>>>> losing
>>>>>> the top two ones.
>>>>>
>>>>> Oh, right, I will add a cast ((uint64_t)csr_read(CSR_HTVAL) << 2) | ...
>>>>>
>>>>> It will cover all the cases RV32 which has 34-bit guest address and it
>>>>> will be enough for RV64 where GPA is 59bit (the highest possible for
>>>>> Sv59).
>>>>
>>>> Only if the function return type then also changes.
>>>>
>>>>>> Also the spec reads as if htval only _may_ hold the original address
>>>>>> of the
>>>>>> faulting access. What if htval ends up 0?
>>>>>
>>>>> good point. then we have to emulate fault instruction and get an address
>>>>> from an instruction. I think that for now it will be enough just to
>>>>> support platforms which always write GPA to HTVAL.
>>>>>
>>>>> If I understand correctly if htval is supported by platform then htval
>>>>> will be always filled for guest page fault. To verify if HTVAL is
>>>>> supported we could do:
>>>>>
>>>>> 'Unless it has reason to assume otherwise (such as a platform standard),
>>>>> software that writes a value to htval should read back from htval to
>>>>> confirm the stored value.'
>>>>
>>>> How does this matter here? It's one thing for htval to be capable of
>>>> holding (all?) non-zero values, and another that it would always be
>>>> written. If the platform doesn't indicate the behavior, I fear you have
>>>> to assume that you may (perhaps even randomly) observe 0.
>>>
>>> So to be very sure we could check for two extensions: Sstval and Shtval.
>>> They will guarantee that under any circumstances it will be filled.
>>>
>>> Also, as an option we could check that htinst value isn't zero as
>>> according to the spec:
>>>
>>> For guest-page faults, the trap instruction register is written with a
>>> special pseudoinstruction value if:
>>> (a) the fault is caused by an implicit memory access for VS-stage
>>> address translation, and (b) a nonzero
>>> value (the faulting guest physical address) is written to mtval2 or htval.
>>>
>>> So if htinst != 0 then htval is filled with GPA and a nonzero guest
>>> physical address written to mtval2/htval shall correspond to the exact
>>> virtual address written to mtval/stval.
>>
>> I've re-read SPEC again and it looks like htinst != 0 doesn't guarantee
>> that htval and stval will contain necessary for me here faulty
>> instruction. What I wrote above guarantee that if a fault during
>> VS-stage translation failed then it htval will contatain GPA of PTE with
>> which was an issue.
>>
>> So I have to blindly believe that HTVAL and STVAL will always contain
>> necessary for me data as KVM and other hypervisor does or introduce here
>> software guest page table walker if Sstvala and Shtvala aren't provided
>> by platform.
> 
> Why "blindly believe"? Checking for the necessary extension(s) should be
> an option. Adding fallback code for when an extension isn't available can
> come later, can't it?

It can be an option. It is what I planned to do.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:04:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:04:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395039.1633577 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwd9L-0003ee-59; Wed, 19 Aug 2026 10:03:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395039.1633577; Wed, 19 Aug 2026 10:03:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwd9L-0003eX-1a; Wed, 19 Aug 2026 10:03:59 +0000
Received: by outflank-mailman (input) for mailman id 1395039;
 Wed, 19 Aug 2026 10:03:58 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wwd9K-0003e8-5g
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:03:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwd9J-005StN-IV
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:03:57 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a857f88-e002-0a2a0a5209dd-0a2a4503c18a-14
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:03:57 +0200
Received: from [209.85.128.175] (helo=mail-yw1-f175.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a857f8c-fae8-0a2a45030019-d15580afd537-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:03:57 +0200
Received: by mail-yw1-f175.google.com with SMTP id
 00721157ae682-836cb2fa1bcso13068767b3.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 03:03:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787133836; cv=none;
        d=google.com; s=arc-20260327;
        b=abNGgkbtv8xeHMeOjsEc6CVolrj3vz/k6gIvmhdYj1PqcjP/Vns5fRTpppkyuqgWu8
         dbiKWkXxk0HGpM/50z70RRvf4VDBaZLhm90NYaZpfAWTxIg6EqdxY9TKyajUPlTz3u2J
         lSyzNJrk7NaSuDKoDT70Xe1lwuM/kZ+qN92URX6YwrJvkFod7LOdQa3SnHhZ2sEYLtw9
         rUXwPyDXUyfBixjr9cM9Qt1YS+d1PDrzuh6IwuzSaM4snZe9A6d0fsTs4TO7d1F3mK2g
         0JkbpB2ea9wuPCzsq8SMhtdUp0HjOFo7Wqg5/KGnTxGczlPtDquUOVtyPTceIyNP1cs8
         xv5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=mDNLO0xc31qLwjng0ficJHE9ArvswGdZXzGZB5MG/YE=;
        fh=gKNe9p6CUigmZ3hfEbBZPSHY3Mosr9iEmW1Mh4pK8Uo=;
        b=iygMP8N9lL1QdCDELGpZkv50PsJ0je6oQa+CiVfIVGKayxArKNyi9DrF78DQYB7p1z
         7t934CErtSHBq6GuC+JVXvJZ4cH4KyBDctzxgIy8vYxthY8Ui+cBmQQPIEOmKgyrF1+C
         /zrwSyJ5YFN2lqG0xNtOB8eUGZYT8dlLVsbL7FpVN33OyBCIc+kxmyeD/NpXoXujfkN6
         2JEQpiJT3mxgDk+h9MpOwo31bjicUkXDq/Dg8ipEAn8dKs38D7K2XVXLU/7/zBnRS2Dm
         UGY+iAE1uvtrM3Mmgl6vzSSO1jf9BS4k2eR7WxHiYJr2Hf/ljJSRNIEge/E8+GQEyc9U
         rixQ==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787133836; x=1787738636; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=mDNLO0xc31qLwjng0ficJHE9ArvswGdZXzGZB5MG/YE=;
        b=A5uO6vmR63ScJyc0mnImuZpYuWC2cUltF1CL5J0UU4vfAXut1jACNjdbDYbgaHdh87
         t5CNWyna9f01XnbAm34KO6vV9RIZ48zIkXsExAwM6SZxB1tf7SVqt/37DFEseZj8S/eV
         iXHMxydoPuhoSu8AmJw9BPcTmdsxgk0V4PrH8Xpf3vCRp8hgz9M9f1SBCWLYXvnlJgMg
         5L87UPCJUe2y67pjt7CEvsh/V0eLZyNCVRLBgTJy+IIZmbAgHHmwEKYL6XBvZDYj9Kfu
         9Z0tYctx6mAok3X5+avuw1aXSuI1wlvfmJBtxdUfejoTb2hC5g0J5m5s2R9ESESP+Fve
         x1KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787133836; x=1787738636;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=mDNLO0xc31qLwjng0ficJHE9ArvswGdZXzGZB5MG/YE=;
        b=FXIc25M9FhC6eli4T31jmWHWg/MoqNlFFk/oo5AkTw0qyZECcQ/bdeGX2FKMk1GGJg
         NOLAy1WdSd2DVClExBmsOAR7TsypLxjvQLeO8CfdHlTI41PoT3Bve6waqni1wKsL5b8R
         CSrvVyrB8BKrl3pOaFljYh4zC7OHDwJ+z+VGnIiCt4c3Fq0YUxQmYQruHP35iNU04Oko
         lz7Xmsbg4q8ilXgaKgYTjU3x5Qvg6j4T2Gik9RUBvbLQ0yidRMfXHknLHfy5XrmkVfeu
         yEw0QLQ53UbjlQGIV5Twik8Hiauf2F20pjV/jk4mhKQbb0z64SDOEqplwvokAuTLP9HT
         ONPg==
X-Gm-Message-State: AFuF++nbWAAu83e2SrR4svAuw2iG4OEuexRsDbu64mpCfcLrg0x/zyw8
	/1jo5NuGRConl6u3F9RaBwmXQi3QNEAcSfgsUN2ebgMZM5WSW8vAf79RXjYNpDfXqDoC0Zlz/bL
	i/8J37MhCI8MH7yb19hOvUGfST1ser2K13a2s
X-Gm-Gg: AR+sD13agG5uUDWn2gIG0le2C8MpbCahRV7Y5UDf5bgKOiU8d0CTpQ6jxhLX/t+tcKb
	gHOVpTtRqIpK1RKIoWmBUieYiObtE3eT4AG5GGEobvlotSnEDp29nzZUYJ6q2Xzf2NlfC2W/+Ey
	FPbmtUJ1Emdn0L+kd6lQLUntzOb0ahOWop+q0jQhXs//Wx6jfYaefRsgzNtI4JhR+QjgnXJSZr0
	zCoC0VwzgmKbHMDHXyWYv3VmOo79wuZlNfxEYRAwXqfZBp6CXi6BZa/1L5QWQ7esVG82t1fCt7E
	VX4SDvnK3f7Ci6nZllg/1rdv4+V2AiKWQzily2Nvb+2fFF4pxVmmxabqcHeBDslkJtFEeyQYrAC
	cAg==
X-Received: by 2002:a05:690c:e0d4:10b0:81f:650d:1377 with SMTP id
 00721157ae682-844e53b3419mr11046027b3.35.1787133835843; Wed, 19 Aug 2026
 03:03:55 -0700 (PDT)
MIME-Version: 1.0
References: <20260715062206.328049-1-frediano.ziglio@citrix.com> <CAHt6W4cG_-=8MBJ+7dWQrLuC2Lf-fLOHDUyGwWDGQn6=9bO1Lw@mail.gmail.com>
In-Reply-To: <CAHt6W4cG_-=8MBJ+7dWQrLuC2Lf-fLOHDUyGwWDGQn6=9bO1Lw@mail.gmail.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Wed, 19 Aug 2026 11:03:44 +0100
X-Gm-Features: AcwNN1UEiPDCoqggR9ARSXM1iRAUXqd80NSnO7hdkEQpwi5fua9wjNtOi_oAt8g
Message-ID: <CAHt6W4fFYs8fMUFer2oRL67voM_NbwtFbD=fJxFiQ5g0cujsMA@mail.gmail.com>
Subject: Re: [PATCH v8 0/4] Various patches to improve Secure Boot support
To: xen-devel@lists.xenproject.org
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich <jbeulich@suse.com>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-33051d/1787133837-7468B4E9-87005187/0/0
X-purgate-type: clean
X-purgate-size: 1930

On Sat, 8 Aug 2026 at 07:41, Frediano Ziglio <freddy77@gmail.com> wrote:
>
> On Wed, 15 Jul 2026 at 07:22, Frediano Ziglio <freddy77@gmail.com> wrote:
> >
> > These patches improve support for Secure boot.
> > UEFI CA memory mitigation requires memory pages to be not executable an=
d
> > writable at the same time. So changing permissions and splitting some s=
ection
> > is required.
> > Remove multiboot pieces from EFI executable.
> >
> > Changes since v1:
> > - improved some comments;
> > - merged 2 pacthes removing multiboot support in x86 PE;
> > - removed a patch dealing with SBAT;
> > - other minor changes (see single patches).
> >
> > Changes since v2:
> > - improved some comments.
> >
> > Changes since v3:
> > - Added Acked-by;
> > - Improve commit message.
> >
> > Changes since v4:
> > - Messages updates;
> > - Clean some dependencies cause by code removal;
> > - Add small commit to remove a possibly unused string.
> >
> > Changes since v5:
> > - removed merged commit;
> > - remove more code/data from xen.efi output.
> >
> > Changes since v6:
> > - fix commit message.
> >
> > Changes since v7:
> > - added Acked-by, all commit are now acked.
> >
> > Frediano Ziglio (2):
> >   Align relevant sections to 4KB
> >   x86: Split .init section to satisfy UEFI CA memory mitigation
> >
> > Roger Pau Monn=C3=A9 (2):
> >   x86/efi: discard multiboot and PVH support for PE binary
> >   x86/efi: avoid a relocation in efi_arch_post_exit_boot()
> >
> >  docs/hypervisor-guide/x86/how-xen-boots.rst |  6 -----
> >  xen/arch/x86/boot/head.S                    |  8 +++----
> >  xen/arch/x86/efi/efi-boot.h                 |  7 ++++--
> >  xen/arch/x86/xen.lds.S                      | 25 ++++++++++++---------
> >  xen/tools/combine_two_binaries.py           |  2 +-
> >  5 files changed, 25 insertions(+), 23 deletions(-)
> >
>
> Ping
>

Ping

Frediano


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:07:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:07:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394902.1633590 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdD3-0004Wm-QG; Wed, 19 Aug 2026 10:07:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394902.1633590; Wed, 19 Aug 2026 10:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdD3-0004Wd-MT; Wed, 19 Aug 2026 10:07:49 +0000
Received: by outflank-mailman (input) for mailman id 1394902;
 Wed, 19 Aug 2026 08:42:24 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <suruurism@gmail.com>) id 1wwbsO-00081p-O9
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:42:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbsO-00Fnyp-4s
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:42:24 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <suruurism@gmail.com>)
 id 6a856c5e-2eae-0a2a0a5409dd-0a2a4506ab3a-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:42:24 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <suruurism@gmail.com>)
 id 6a856c6f-195a-0a2a45060019-d155802ce90c-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:42:24 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-499840a2575so5548295e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 01:42:24 -0700 (PDT)
Received: from SurHub.localdomain ([196.188.112.82])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499ab2a8b34sm48429415e9.8.2026.08.19.01.42.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 01:42:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787128943; x=1787733743; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=hjjUvOmK0OPOz9lxQcUSjqU8S6ZDd+xG7uAE7UP0M10=;
        b=mHG1JQhzF9UM1cMLXZAnT9is3yu9XWXonzmqfOrTFemR8Pk/dc0MP5B8/FOkzRo2nr
         bt8q1/deq5VDZLJQql5qN3FrMpXmcbEqJ3rW3A8Eme0oTb/76AANWWWPK2n3WqzKODFw
         mu9RoScu2IocB5PtPRDXgdn33YSXRRsM24PkD93DkKrQyiIcc1SS8bMrD0ajjTvgqSsh
         rDg+SqWZgKOONnk9zwa1cdc21ZbgZDbgU0CxKxEDP+Ba+2iyxqCabXEz2oGmTEchRUiI
         Lfqz5ktvIJcl/HajGM7V6QwyBYkYPfNahpMRlQnv6HAlDnW4sOIhMFUtK5vgVvY+SNH5
         p5CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787128943; x=1787733743;
        h=content-transfer-encoding:mime-version: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=hjjUvOmK0OPOz9lxQcUSjqU8S6ZDd+xG7uAE7UP0M10=;
        b=itD+KKRd9CTRSQDFd3m4mVZwbZJ0mlPeJXdjSVXj4GjZQs7G2fGWPly3YoPKyxETNX
         UhWr/ja2tZMAtrxt7R7SWJdpX9Up4s7/U9jjnBTMzndVuTSxJmDL1mslkPuFOzJgTLD5
         2jNHYYcnzfHwTKkOkhSU8AuwCkdeKFv73YgRDNT2WrMoFBGAgnOcgOadzz1Ei3BYbhn1
         ogLaeiGvSKLhJBgIyYYJFl7v3zmcJHdDYlD6V2SlTcUmz4EpRfvAKCw3GfYxjV+hDsO2
         mDYIKHZ/kOiVGjU8C/3raM5+8iSutbeqQZhUDD9VojYLhEs695bUgrK27Y7EFQ37nCDK
         MSlw==
X-Gm-Message-State: AOJu0YxZ4UcVazL1iBY9aKHwV4TEQZAms2OyG32vNdy/c0PZ2NO9B+ff
	Zx8p2cRd9EYLk217LZRJYV0GnKIOrsQ8gu3GW8nchFfGt/xE6swq9HLLazmsJQ==
X-Gm-Gg: AR+sD136Z34kJ5e7V9EiDh49iDL1axlTwBh50VebBUNnUVuP6hPP8ZMAVO4513owKC/
	E7wnIDF4crE0fmShU5RoEP16Gh0dRTrUscHMMeYN4C+ULtWPquobXtf2pK2xrVRq4aWKArYi6gs
	DliC5mhbk+Uk9W7YHm+kthOFLytKRxvdFgXpt+oEik2SYyG7nDyOgbvozXEkxStDXswGJpi3dEO
	0QZvJa6zOOaJdMXeTP8ArImru3Dtl4MZ0iUwYXQmWXpfUNgvRSgvSxLwj7Jk1VtNLhlKhH6shQg
	PA/FWyYNhFTa4IXNG/CMlByA6eYHuH/l7GYR53u9hVmaiqTESvRcBT/X+xS11F44MHT4kPuxdO5
	4XEBcmkVeSITJpvkFwXOeo1EqwwbWqVklMtdIDIh4kRM2XZ+Y1xpuXWGKkIvo5AcSAUJPcjPG70
	MGvrwgVd24AJQzINGB8a51kAsdfNcD37U1nx7IZbOYFJvvMWpV5JHkMctr7t8mXesTEPd7
X-Received: by 2002:a05:600c:a05:b0:495:3da3:beb with SMTP id 5b1f17b1804b1-499aa1b6a02mr45293395e9.10.1787128943217;
        Wed, 19 Aug 2026 01:42:23 -0700 (PDT)
From: Abdifatah Suruur <suruurism@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org,
	jgross@suse.com
Subject: [PATCH] xen/gntdev: prevent private mappings from becoming writable
Date: Wed, 19 Aug 2026 11:42:17 +0300
Message-ID: <20260819084217.1577-1-suruurism@gmail.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787128944-F5C0F77B-29DE9FC2/0/0
X-purgate-type: clean
X-purgate-size: 1440

gntdev_mmap() rejects writable private (non-shared) mappings of foreign
grant pages, because a private writable mapping takes the COW path on
pages that have no proper struct-page backing.  However, VM_MAYWRITE is
left set, so userspace can map the grant read-only and then upgrade the
mapping to writable with mprotect(), hitting the same COW path the
check was written to prevent.

Clear VM_MAYWRITE for private mappings, as i915 does for its read-only
objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor
(CVE-2024-53071) and ptp: vmclock (commit
a5edadbae57e2298a56cf7a4e774a027905a331f).

Fixes: ab31523c2fcac ("xen/gntdev: allow usermode to map granted pages")
Cc: stable@vger.kernel.org
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>

---
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1dcc4675580ed..b71f5bae25b63 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1066,6 +1066,13 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 	if ((vma->vm_flags & VM_WRITE) && !(vma->vm_flags & VM_SHARED))
 		return -EINVAL;
 
+	/*
+	 * Private mappings of foreign grant pages must never become
+	 * writable: they would take the COW path on granted pages.
+	 */
+	if (!(vma->vm_flags & VM_SHARED))
+		vm_flags_clear(vma, VM_MAYWRITE);
+
 	pr_debug("map %d+%d at %lx (pgoff %lx)\n",
 		 index, count, vma->vm_start, vma->vm_pgoff);
 


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:07:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:07:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1394898.1633587 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdD3-0004UA-Jp; Wed, 19 Aug 2026 10:07:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1394898.1633587; Wed, 19 Aug 2026 10:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdD3-0004U3-GY; Wed, 19 Aug 2026 10:07:49 +0000
Received: by outflank-mailman (input) for mailman id 1394898;
 Wed, 19 Aug 2026 08:40:01 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <suruurism@gmail.com>) id 1wwbq5-00070R-AP
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 08:40:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwbq4-00FnNH-Jh
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:40:00 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <suruurism@gmail.com>)
 id 6a856be0-e002-0a2a0a5209dd-0a2a4508be42-0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:40:00 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <suruurism@gmail.com>)
 id 6a856be0-f659-0a2a45080019-d1558031acea-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 10:40:00 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-495590dde14so8914505e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 01:40:00 -0700 (PDT)
Received: from SurHub.localdomain ([196.188.112.82])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9dff4c1sm33032205e9.3.2026.08.19.01.39.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 01:39:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787128800; x=1787733600; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=hjjUvOmK0OPOz9lxQcUSjqU8S6ZDd+xG7uAE7UP0M10=;
        b=cJV1rfCSuhfyvSngFcjXYKuWHxoVDEMNU7FBNvtWH81DrY4+p52xQA4Yb3v+LGQJGq
         0ogd5ENlVX8MfIWLbIgzE+zUTMwT+Gi5+/YAqCSdzv5MXNJXXl5VXGcI/pSCK3r0HOsi
         zBJxEkhpvJtA9Hn0y/UskjIt5K1yYL9OnzqXE2gk43qSnzwyPmaqvZhV090avrSHHNM5
         U1on8R49ZLpcyS0kVT2tbs65/6UvyICed9I4f+xwQk2g4gXD+b2ciS8B5Sw9tkfBgmR8
         77LJSEwej7inxz9b3s7zgETCKKXSvO6pEswCyZ99Djy8xm/lp1YKfjnbCqyFkqYc4Cc0
         RQLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787128800; x=1787733600;
        h=content-transfer-encoding:mime-version: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=hjjUvOmK0OPOz9lxQcUSjqU8S6ZDd+xG7uAE7UP0M10=;
        b=CGe2gRxspzTwTIF6ZLvqEKnua137RTDHK3JMRIUl3e+KRLUOHqmYMdswutbmmJi4kp
         PSOm8MkX4cxOtVWvnqZNfDqD7dt8W2hMjVH7Iwe2qy+z4l+llMmZwwNV8pMlfPmBaALf
         mgpT1/ZBZnsriLUMIdHCIf9vvmlypZLSB54VUGrhwHCgxc3Mf7/BzhEq9p3cP8DT9NBV
         ZZcapIgTAVharq7gayWza4qIfd4TSF/l1iu31beJaUniD/bPXRYaPMDi7aZneCzj8B/T
         4dbUW6Lxaf6uh9EhwrH5awKNhs/dXQluGSpa1eO1KjtZCICi0BWvixuF6imuquoiSJq0
         FLGA==
X-Gm-Message-State: AOJu0YzhpWYBbard7FYbUqvw35fIF9780cHhaMlvZENY/NZrU6j6+52N
	QXOd+hs+l2IjJlsWra+IfeDpcJmJZ3DGXdIC9yAmCwqWxVqSx8pGJl39rcqqF1Js
X-Gm-Gg: AR+sD11s6fB3aC9wVY4TyNX5kY+5qclFqef0bDuKF96aCddcCsQbCC9cnC1++2ui/0p
	YnkhSwaOHCkNZe0sD/LGiKUxvh3lU3zgWMrbSQTs60ItY2khWMOIW6lidhui6BGPr3P7rKWNWQ2
	SaQCxriaoh4D42YrpkyU1aDcozIPrIltFrH1njGnMdp/84LUY4bdvcawebNS0zMsRIAMwvldFWi
	LM2QCkNgqKZ4lNO7SJDAZuzQllOhwBpwWYNeFmYd+BnC5oEgRT34jGnHSKwsLILB++d5+bCpHUt
	biPuUXd4ZIXLv+e1uUggGnWrP5glgb4rzdvjSaP8ELdCGEtXiduKPNeob7lwv46rB7rL3x+7PHr
	JHD3hJZHgvK1fNGCtAeOKjIUYF8eQuJYHKheqqnlgxTPHXxE00gJ7NOdm1G8QMM48iCeOt6MroK
	PPWfNvVsuKvWLlEM86bXzDbd5nBic2bJ6D8eXZxfFimrt48klYJeHx9PI8lQzTiL79g5vd
X-Received: by 2002:a05:600c:a012:b0:499:593b:a15b with SMTP id 5b1f17b1804b1-499aa1431a5mr56444255e9.1.1787128799811;
        Wed, 19 Aug 2026 01:39:59 -0700 (PDT)
From: Abdifatah Suruur <suruurism@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org,
	jgross@suse.com
Subject: [PATCH] xen/gntdev: prevent private mappings from becoming writable
Date: Wed, 19 Aug 2026 11:39:56 +0300
Message-ID: <20260819083956.1442-1-suruurism@gmail.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787128800-CF55C87B-F0C3CF76/0/0
X-purgate-type: clean
X-purgate-size: 1440

gntdev_mmap() rejects writable private (non-shared) mappings of foreign
grant pages, because a private writable mapping takes the COW path on
pages that have no proper struct-page backing.  However, VM_MAYWRITE is
left set, so userspace can map the grant read-only and then upgrade the
mapping to writable with mprotect(), hitting the same COW path the
check was written to prevent.

Clear VM_MAYWRITE for private mappings, as i915 does for its read-only
objects and as fixed in drm/vc4 (CVE-2026-68445) and drm/panthor
(CVE-2024-53071) and ptp: vmclock (commit
a5edadbae57e2298a56cf7a4e774a027905a331f).

Fixes: ab31523c2fcac ("xen/gntdev: allow usermode to map granted pages")
Cc: stable@vger.kernel.org
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>

---
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1dcc4675580ed..b71f5bae25b63 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1066,6 +1066,13 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma)
 	if ((vma->vm_flags & VM_WRITE) && !(vma->vm_flags & VM_SHARED))
 		return -EINVAL;
 
+	/*
+	 * Private mappings of foreign grant pages must never become
+	 * writable: they would take the COW path on granted pages.
+	 */
+	if (!(vma->vm_flags & VM_SHARED))
+		vm_flags_clear(vma, VM_MAYWRITE);
+
 	pr_debug("map %d+%d at %lx (pgoff %lx)\n",
 		 index, count, vma->vm_start, vma->vm_pgoff);
 


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:12:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:12:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395073.1633604 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdHW-0006qW-9N; Wed, 19 Aug 2026 10:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395073.1633604; Wed, 19 Aug 2026 10:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdHW-0006qP-6g; Wed, 19 Aug 2026 10:12:26 +0000
Received: by outflank-mailman (input) for mailman id 1395073;
 Wed, 19 Aug 2026 10:12:25 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwdHV-0006qI-Cs
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:12:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwdHU-0090ZM-OH
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:12:24 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a858184-8faa-0a2a0a5109dd-0a2a450bb5ea-6
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:12:24 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a858188-b7e8-0a2a450b0019-d1558031bdf9-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:12:24 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49556f97a9dso5535385e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 03:12:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa17567asm48380635e9.10.2026.08.19.03.12.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 03:12:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787134344; x=1787739144; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wKWqU+1jI6a1UnAym+QHfLDxwV0xh/bkzkwdE77jal4=;
        b=XciyvTGQQ/q+zW9O+QlAngGdONj7AS8kdQRSyXQykxWjP/F60UYYZ0ASHXgIgRDeyg
         IutQRgP13uAAvzgvOzxLhd8FWnMsT6PEDg4kumDQL9g039Czsa9Hn/aGV3Jkj4pB1lrK
         2aCbl4BXzATlXOLUUx8lVjjl19SICsplKWDMA2wpGWnXoD0mQ6Pq6QAwNGQHWPWqfJZt
         P6LYkwF27BOKR6So0RHPC+VfvHsJMiF4appFQFN3C5fwgGRlOfn+ypdznL6pN0CT/gQP
         pB/ZZp6+Uw1xte7cDAXoG5fL3wjI1zcgxv10kdoDK2RD++m93Trww/87NbI9uZRP4ao9
         qeyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787134344; x=1787739144;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=wKWqU+1jI6a1UnAym+QHfLDxwV0xh/bkzkwdE77jal4=;
        b=MVYjaEyxTRvyVg49BEuZrogTD8+91Xp1wLteHVMdcZv6m8DKp/ABZjAAcDhEkPWL1n
         BJI0qgZDooIyzLTj4hGDHlo6RADnNNgnfDcAI+EE9iGKvyDYm6qq1SqpoBGVT2bUF/8K
         4ZDperYRcMj/LOSyqLI4gq6FB7kV+JWP9Mhgq1npTRzbdk9SvQRRR2aj6Z8+4GfaltyS
         xXGuE1uvl7JGNlhQcCWFaKW/b/sH5B017GKH4XFHwk0fPxNQQ3lKyXnIsvXZksl7UanB
         F6fJ6J3J4CQLS1mg9wXWsV8p0f1EPBOOJniLzM5nyq2ayflGsX5zdMumuAq6A+cpfEPS
         2zbg==
X-Forwarded-Encrypted: i=1; AHgh+RpmZXDYBDKhjYgVpvi06dMP0a5qn3L87KPJrjZzY/t8BvPIWyRQFeg8OMUhWJoh/AZfAfss1uBDEII=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8GtwyQprF6ajLxXnvRw9MyGBOiZo5Z352be/QQuO77xiahABj
	4Vz8sVsCAkgJzwyRG8+dYM+9mj8bQeYCNJ41euIMrH23oAv38fWOA9lXvGQMxnvfoQ==
X-Gm-Gg: AR+sD11DQcocX0f4cTzRSVNe6tSC/17p2AIDn7CUOJPUEeCqf+Y5B3rYbD/E+AiI80z
	BrpLTpk6xOImPBSBOy0GH1toKvqtMGa0rg8WxWF183BiRpj+ESxhqdDmBlSS77Ln9DfRMUss2DK
	FJ+oXAfLF7wLIJmnT/8SsllXj1/ENyLZxP2DtnMC3dREXITC1Y++tCHcDWZvLQN3ud4v1XQFINu
	LYJDEBmE1lm42VTj2hrueB+wGLbTP+sOjPTuNZKdYOlwNxXz26bDd6WXUkwOFkbN8NKVyBxkwmN
	H0HbaKIRvEI6i/dC0ACcVbvWhWCKBk8xERCru694o3Id1g5fjgTnG3jWIC36pn2mL7MVdID4M4s
	5qujWW51ZIoiFf6f1CAQ35wqnM2spQZNGtAabVIbzUvUIBlWwHCIitAWkjL4qBABBFPrFe61zRD
	EvOOpse1AZlXrzM//DaqCkPc1/iAa+n5TT2b5vVPYRSv9Fn+i8LQZtmL2dXuN4TJjy4WvRU3UBy
	BJjYLkTU0wIQSqxiAUt0b3rCCb3PRQ6Z+7f1us20mB2WE29btHG
X-Received: by 2002:a05:600c:8b81:b0:499:8ff5:8ec4 with SMTP id 5b1f17b1804b1-499aa1802a9mr70231845e9.3.1787134344041;
        Wed, 19 Aug 2026 03:12:24 -0700 (PDT)
Message-ID: <559e68bb-1689-456b-89a5-0a39d3bb3afd@suse.com>
Date: Wed, 19 Aug 2026 12:12:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 0/4] Various patches to improve Secure Boot support
To: Frediano Ziglio <freddy77@gmail.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
 <marmarek@invisiblethingslab.com>, xen-devel@lists.xenproject.org
References: <20260715062206.328049-1-frediano.ziglio@citrix.com>
 <CAHt6W4cG_-=8MBJ+7dWQrLuC2Lf-fLOHDUyGwWDGQn6=9bO1Lw@mail.gmail.com>
 <CAHt6W4fFYs8fMUFer2oRL67voM_NbwtFbD=fJxFiQ5g0cujsMA@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAHt6W4fFYs8fMUFer2oRL67voM_NbwtFbD=fJxFiQ5g0cujsMA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787134344-A9EC69EA-653DF019/0/0
X-purgate-type: clean
X-purgate-size: 2136

On 19.08.2026 12:03, Frediano Ziglio wrote:
> On Sat, 8 Aug 2026 at 07:41, Frediano Ziglio <freddy77@gmail.com> wrote:
>>
>> On Wed, 15 Jul 2026 at 07:22, Frediano Ziglio <freddy77@gmail.com> wrote:
>>>
>>> These patches improve support for Secure boot.
>>> UEFI CA memory mitigation requires memory pages to be not executable and
>>> writable at the same time. So changing permissions and splitting some section
>>> is required.
>>> Remove multiboot pieces from EFI executable.
>>>
>>> Changes since v1:
>>> - improved some comments;
>>> - merged 2 pacthes removing multiboot support in x86 PE;
>>> - removed a patch dealing with SBAT;
>>> - other minor changes (see single patches).
>>>
>>> Changes since v2:
>>> - improved some comments.
>>>
>>> Changes since v3:
>>> - Added Acked-by;
>>> - Improve commit message.
>>>
>>> Changes since v4:
>>> - Messages updates;
>>> - Clean some dependencies cause by code removal;
>>> - Add small commit to remove a possibly unused string.
>>>
>>> Changes since v5:
>>> - removed merged commit;
>>> - remove more code/data from xen.efi output.
>>>
>>> Changes since v6:
>>> - fix commit message.
>>>
>>> Changes since v7:
>>> - added Acked-by, all commit are now acked.
>>>
>>> Frediano Ziglio (2):
>>>   Align relevant sections to 4KB
>>>   x86: Split .init section to satisfy UEFI CA memory mitigation
>>>
>>> Roger Pau Monné (2):
>>>   x86/efi: discard multiboot and PVH support for PE binary
>>>   x86/efi: avoid a relocation in efi_arch_post_exit_boot()
>>>
>>>  docs/hypervisor-guide/x86/how-xen-boots.rst |  6 -----
>>>  xen/arch/x86/boot/head.S                    |  8 +++----
>>>  xen/arch/x86/efi/efi-boot.h                 |  7 ++++--
>>>  xen/arch/x86/xen.lds.S                      | 25 ++++++++++++---------
>>>  xen/tools/combine_two_binaries.py           |  2 +-
>>>  5 files changed, 25 insertions(+), 23 deletions(-)
>>
>> Ping
> 
> Ping

Andrew had indicated to me (apparently not to you?) that he'd like to
massage the descriptions some while committing. Hence why I refrained
from putting any of this in.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:21:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:21:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395089.1633613 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdQc-0000IX-4H; Wed, 19 Aug 2026 10:21:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395089.1633613; Wed, 19 Aug 2026 10:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdQc-0000IQ-11; Wed, 19 Aug 2026 10:21:50 +0000
Received: by outflank-mailman (input) for mailman id 1395089;
 Wed, 19 Aug 2026 10:21:48 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwdQa-0000II-8o
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:21:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwdQZ-005FBj-IM
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:21:47 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8583a5-e002-0a2a0a5209dd-0a2a4506d530-40
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:21:47 +0200
Received: from [52.101.201.7]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8583b9-195a-0a2a45060019-3465c9071ed0-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:21:47 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA2PR03MB5932.namprd03.prod.outlook.com (2603:10b6:806:112::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 10:21:41 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 10:21:41 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=b18fZ6NvL13GfiV++LuEFXAHeYsfQFrnW7hgoehhBWcab+vKCNWsIK6hWREz5UYcCMOX/mZ896Irb+/O8AZlFF6d34u+jNYmhUngz5iWjn0Lx6jKlYvPQre/0806vDBo8Uhn/HBTpTrt+GZMmTv7zyhbswwiYc0xtnlueb9mt2dV1Ts7/Lzy8utT5pq9tln4G1ph1VU/YYa+ijWl8BwgVM3jeZcHo1ZA7lifuYGCfytW+5bN6dNKjuEmlFyzgdS0gEW8jwwIBoaXNuzLc+EsDrW9AxSkLoRezDCHc41zM8Zvk/ynO2Pnzm/n/l0blsJXx5yREXR2gJPJUeuglp0+/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WAt/SvYtKyriI70B6z8ahBIYQKuGuOFtO9aN5yUVtUg=;
 b=itDni58PPp5Nv8IQOHEOBe0C62bEMFycjfQaeUt4bfMeu3P4ZigZ4ZktZqmcsoSxHzFg0PMeQHcGcW++cFsdv8DE/v+fQe+8JS8oLEaRWKNFMzdHROdkedW5DbXlZ0yU+L5yfvtGlq7F/9ILuyGSGKzpVYK4nAZShwKUgh9jaMnN8Tmd7I88mZwe2yqhatypT41kGh3BX2a6S7J+ExOjK10ZsjX/tk+v5YmFSV2sMJqnMNYSU3yc4TRx5pG934Vm05QtwvLNce3oQV52P3PNNcCDgg3gOEYY+lk2toYXYh5+atiE8upMc1gYl5B03zD34hLSEJTmwBjRcaDtF6gfDg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WAt/SvYtKyriI70B6z8ahBIYQKuGuOFtO9aN5yUVtUg=;
 b=KaY/ThMcdXVwriURQX1FhapPMVIoV2JhQ+blX0Sx8UZQdTu+z6ZWhereFGSnhM7lDrqncWQ4WEYOXyA+NYAMUGLIpp+rCQzmJpIbm1myT68qGy2c4HCNMYZSoiaAWXu3e/2RHyWyM9eLeCQMDjwVVhVxERldSykf/7MuTYNpkT8=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <ee86d60f-2dec-4944-89eb-f31e47930774@citrix.com>
Date: Wed, 19 Aug 2026 11:21:37 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Jens Wiklander <jenswi@kernel.org>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH] xen/arm: ffa: Harden SEND2 against invented loads
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
References: <1b483ce633bfa7d304cb78458ce029370691f00c.1787055320.git.bertrand.marquis@arm.com>
 <d739485a-72cc-4518-afa9-8d2692a225ae@citrix.com>
 <7F03E2BE-44A0-41E9-850C-8480CA0C8F0D@arm.com>
 <07151e7f-3179-4432-b7fe-e70890f1ba4f@citrix.com>
 <57EE3124-D60E-485B-ACDE-4F9431BA7F3E@arm.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <57EE3124-D60E-485B-ACDE-4F9431BA7F3E@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO0P123CA0012.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:354::20) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA2PR03MB5932:EE_
X-MS-Office365-Filtering-Correlation-Id: 82c6bcf4-0865-419e-3b10-08defddba933
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|10067099003|56012099006|4143699003|22082099003|18002099003|11063799006;
X-Microsoft-Antispam-Message-Info:
	2BzYQm3+Hun69Sr7XYloNq4ch60Fd9FND2KE5DlqrshSMFQT0ob1i+H7OvF5fd1G/b3xBVVWH7hFb6MdVWljiIJJdoth2QJCi/hxKQsFkBI0sTrkojs6y6uud79FPGS2tph9oJPfI642zhxUsOVNSkiUWBctnyjlcD+89Trt8uVzbdiOPcuGYYo7SIHcQFc24ZmTB0tDH1N5Ggiba24RdPdba6Jc4bVH6uLOdJ5G9brHcaugl1QWQwJd8NgScJJRJRQ0TGBp5zeowjbAQ9OS/ZSPOUwjd8tqkGZ/OFZRHI6LaUA8IOl8im8zfMf8p/c65ShStU4cFrlhgpdoo0FGTwbQol45mv+XAbDDiFwpE4bPxhDBDUzVo9nfZfp+OaVN1Q8i8JRJWKlVkPh3buA0Onxnz294QqNg4BjvMu1jZ4B+GqtmYZIZJmhV0+xYuGFskWTOimdolXdOjFg+/lpo8NlBaY1Q7PSixKxbqbuXa+YIGJtfJDSXhpQHwFJas9LoYmzeu/GSzTFhuJBniNJiDMBv/7dB6LES2tsV12Xft6bFNtg0RdIjc2YN4jz8HH2lQLABz6Ech3fY2rXraRf1/+pyP/kSGCOn6ORzlqQFurbQVZQMvnaQbL/rz9JI/G4QuKfYdzmSr4Lm+kPPUTNqZtRf57TotLvtfSH+D6i6hM0=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(10067099003)(56012099006)(4143699003)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?UEhYOEhaTmQvTTFPRjMyZXZYMDI5a0tGTEhjK1hHSDk3YmszNnJRNVpkd0xI?=
 =?utf-8?B?Y2U1czdLSlppM2R2Rzc1TGkvLzZRYk5yWEdmQWQ4UTVRUWFlTXFZbENkbHBs?=
 =?utf-8?B?NEFvNldsYmVyMUR0dUw2cEpDS0pkS1JDNjVQbWYvN1E4YU0zdHdyckNUTkVx?=
 =?utf-8?B?WFpPaHlBdDlxc3JOcGJXbzVTQTdVMkFvU2FjMmVBWWRINVJ1NzJydzVER3FM?=
 =?utf-8?B?V0VFUVVtN2Vac0REYVJVT3REcmJ6VHZHVTJhQXZIUFJkZUpNVVNITzJhMlFh?=
 =?utf-8?B?dWVmWWFBZzNudkkzb091VkdaNVEwTGExREFGdmpONGRUQ1AwVXh0aXBlNyt3?=
 =?utf-8?B?Qy9xOGN4a0RvVmYrVVBCNDdMcC9mbUNVdnlPd3lCRDUzQk9FTHBhdm9TTzZQ?=
 =?utf-8?B?ZTBXRnpVeHhGanJIWk9ROEhPSVZweGdlWnI3MnlWeGhzS1laeHFoOTNqVjU0?=
 =?utf-8?B?UUgvYkVXdFNkNXFkSW1GbTh0VkZ3Yjh5MVNSalF1MnRoSk1qMi81b2hGMTNG?=
 =?utf-8?B?a1lLeUcxeUNSMkNzR0xwTCswUWt6RmgwWDBhV29YczAxY1hPT2JBRkJ1VXc5?=
 =?utf-8?B?em1OVzJHV0pyN0gyaWdLVFd0MEQ2NWYzcUQ5cFU1ZkxIT0VtSmxyYmJ5WmI0?=
 =?utf-8?B?MS9oQTVnV3R6Z0hSNDAzektiRWw5amQvK1JER2pOWTJUZU1HRnlJUHpXZ2xN?=
 =?utf-8?B?Q0p5R1RlY0RkK1VmVmZuZk5qVmFxOEtMcTRmNVdEcUgwSTBBc2kwYmFEU29V?=
 =?utf-8?B?Mkpqbk1ORW9BODNqa1JqcWZHSzIwMVNCQks1aGlXdzkrTTVIS1ExY2NqbVIr?=
 =?utf-8?B?eFVEbnZmbjM3VlZjTFhONUcwZHBIUThqYloxN20yTFRJazg3TDlqdHlGK0N4?=
 =?utf-8?B?M2d4RGpyeUF5R3NiQjB5UWZuS2pxMnhMQWtjTkxUaXdtRVdyelRHZE91c0RH?=
 =?utf-8?B?dHpWU2xCd2YrcUFqK2loOXpQb2pMdmxIaW5NVnNIZ01CekFPZkdHRE1idGRT?=
 =?utf-8?B?amZnTzVKUnFBTDZyWTlKbG1WTnNLVVl3MDJFbnFuaHVRYzIvb3ZtTUVhUTVG?=
 =?utf-8?B?d2lYUDdNUGs0K0RHbXg5Wk5wVXRqSnNIV1VwM3VrL3oxOEMrVVFTZ085c1p2?=
 =?utf-8?B?WUhQSGZQc1UrV0IwZ0QyT09hOXdGQ1B0amQwb0diRWhXc2lNOXoyVWtXcjVn?=
 =?utf-8?B?UWtNSmVyME9TNW1mZ3p5UEdMNjd6by9jc2RwclVZcUEvYm9zYkZlcCtwODBN?=
 =?utf-8?B?bHRpV2Q2WEFDWVhpS28xVk1QYkNIQmVVSnFJL1huWUcwSDlWSngxeU1jRnZZ?=
 =?utf-8?B?SEk2bFBxNExoakxKWFhYd1V0amxUSlVadjIzV0puTVlMOFlYZW5ydzNRRFJv?=
 =?utf-8?B?N0ZBdmxSaXg1V0NhWm1RY3lRM2MrREtDM2xOVkZ3VW5DclYwMXdPTldzU3pM?=
 =?utf-8?B?clM3SlRaZnBQTTdiTE1KTHM0ODM3NkZpSDJWRjAxOHV1SjAzaE9GbVExU2RD?=
 =?utf-8?B?Z1RQbEZxMFBFMUNTeWZBUGlBd0srZlJ0NTYvUTFLREZGNlBTenF2bFE0bkh3?=
 =?utf-8?B?elNGci9NVUZZV0tzVXBHR2hOeTR4NCtuWWxsbXdBSy9zejFHM2JCeFJkTTB6?=
 =?utf-8?B?UE5kT2VxSmlYYTV6c3FmYmhOWWw1cmVTY1N2MWlpVUNjYXZwejFLVGtwbTdO?=
 =?utf-8?B?MmoyclFjSFZ1M1dPdHo2NmYwNlIxYU0za2NoTXhWM3lxazBVWUF1akVLWlBZ?=
 =?utf-8?B?a1I1TmFoS01QeW5wV2lGQ2hTZXN4N3JPbnRHZEFDSTdVK3gwTlVQeUdxTXB6?=
 =?utf-8?B?Zkw0WWJ4dmttTlZBNDZXbVNBMmE5YjNtLzF6SlU2d1FRb1pJR1ozU3g3ZGdT?=
 =?utf-8?B?Qzc5OGgvb2hIVytyN0tBMEE2eWRKblNIbkhhcFg0cFlVN2dNUzV3OXVUNU00?=
 =?utf-8?B?WUVrOEg1NmxNeTNnZ2lmVG93UzF5QTVZWnF4UDI1NTBEblVpeVoxa0plcnlj?=
 =?utf-8?B?Rm1Da3BjeGg4dmlXQ3BaYXhHVHZoYnpMcVF3dUpKNDUvWGZJNzJFenU1cEpU?=
 =?utf-8?B?Zm5FSDJCd2ZUTE0xN01VZTIzSFFWUUhhamFablBhWWlMK1NBc3dqcjJ5TTVs?=
 =?utf-8?B?WEM3cHE4MGlxQmtFMFNxbWtrZFFPR09oS2NlWWlFSlZpc0hKa0c4VDNSOS9y?=
 =?utf-8?B?bEE3NWVTWVlFdGkrNlFyK1pnVDM5Z2VNa2JPSVB2SHdaVHpJYWhSamp2dndX?=
 =?utf-8?B?dXhmalZ1N2NBZEJNTDNacGN2RHE3QnNTRmhoZEdkMWVoaVRMY2kvekE4SnBi?=
 =?utf-8?B?Q3lWQjZrTXZjTDBvSTNTSmV2QlNvS1dBZitNdi9DVnlQNmZ6d21XUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 82c6bcf4-0865-419e-3b10-08defddba933
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 10:21:41.3128
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dTPrnmEQa73oNzoj9BreeT9WL3quuo9QhQj6rx6uQaZLPcAzvIxukwgh0Z267IStFrufCBetel5R4O6f+WhD/EZUD/cXNhPMEaevBdsmHLQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5932
X-purgate-ID: tlsNG-16d1c6/1787134907-F70C777B-508A3F64/0/0
X-purgate-type: clean
X-purgate-size: 3609

On 19/08/2026 7:39 am, Bertrand Marquis wrote:
> Hi Andrew,
>
>> On 18 Aug 2026, at 16:46, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>
>> On 18/08/2026 2:28 pm, Bertrand Marquis wrote:
>>> Hi Andrew,
>>>
>>>> On 18 Aug 2026, at 14:40, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>>
>>>> On 18/08/2026 1:16 pm, Bertrand Marquis wrote:
>>>>> Research into compiler-invented loads has flagged FFA_MSG_SEND2 as a
>>>>> possible vulnerability.
>>>>>
>>>>> ffa_handle_msg_send2() copies the message header from the guest-writable
>>>>> TX buffer before validating and using its fields. A plain structure copy
>>>>> does not prevent the compiler from re-deriving later field accesses from
>>>>> the live TX mapping.
>>>>>
>>>>> For VM-to-VM messages, msg_offset and msg_size are validated against the
>>>>> source and destination buffers, then used to copy the payload. If a
>>>>> sibling vCPU changes the header and the compiler reloads either field,
>>>>> the checked and used values can differ. This can cause an out-of-bounds
>>>>> read from the sender's TX buffer or an out-of-bounds write into the
>>>>> receiver's RX buffer.
>>>>>
>>>>> The cross-VM path is gated by CONFIG_FFA_VM_TO_VM, which is disabled by
>>>>> default. The audit ranks the likelihood of such a reload as low, but the
>>>>> C semantics do not guarantee that later accesses use the stack copy.
>>>>>
>>>>> Add a compiler barrier immediately after copying the header so that
>>>>> validation and use consume the same snapshot.
>>>>>
>>>>> Link: https://github.com/xoreaxeaxeax/schrodingers-toctou/blob/main/observer-effect/audits/audit-xen-tee-mediator-RELEASE-4.21.1.md#tm-2--ff-a-txrx-buffers-ffa_shmc-ffa_msgc
>>>>> Fixes: 98af565b1e61 ("xen/arm: ffa: Add indirect message between VM")
>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
>>>>> ---
>>>>> xen/arch/arm/tee/ffa_msg.c | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c
>>>>> index 1eadc62870f2..39f561c8237f 100644
>>>>> --- a/xen/arch/arm/tee/ffa_msg.c
>>>>> +++ b/xen/arch/arm/tee/ffa_msg.c
>>>>> @@ -257,6 +257,11 @@ int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs)
>>>>>
>>>>>    /* create a copy of the message header */
>>>>>    memcpy(&src_msg, tx_buf, sizeof(src_msg));
>>>>> +    /*
>>>>> +     * Make sure that "tx_buf" which is shared with the guest isn't accessed
>>>>> +     * again after this point.
>>>>> +     */
>>>>> +    barrier();
>>>>>
>>>>>    src_id = src_msg.send_recv_id >> 16;
>>>>>    dst_id = src_msg.send_recv_id & GENMASK(15,0);
>>>> This does look to be adequate to fix the potential issue, but you should
>>>> drop the ACCESS_ONCE(src_ctx->guest_vers) a little lower down.
>>>>
>>>> With a safe copy on the stack, there's no need to further inhibit
>>>> optimisations around it.  In fact, it's unclear why e040b94d0fff added
>>>> the ACCESS_ONCE() in the first place, seeing as it was already an
>>>> on-stack object at the time.
>>> the ACCESS_ONCE is protecting the access to guest_vers which is not on the stack
>>> but a value on an internal context accessed by all VMs.
>>>
>>> You probably mixed src_MSG with src_CTX ?
>> Oh, maybe.  Those really ought to have more distinct names.
> No worries. 
> Would you consider renaming them a requirement for this patch? 
> If not, I would prefer to keep this fix focused on adding the barrier and avoid unrelated churn.

This would be later cleanup.  It definitely shouldn't be part of this fix.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:23:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:23:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395097.1633622 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdSI-0000m2-Dc; Wed, 19 Aug 2026 10:23:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395097.1633622; Wed, 19 Aug 2026 10:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdSI-0000lv-Ax; Wed, 19 Aug 2026 10:23:34 +0000
Received: by outflank-mailman (input) for mailman id 1395097;
 Wed, 19 Aug 2026 10:23:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwdSG-0000ll-N9
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:23:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwdSF-005FYj-Ln
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:23:31 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a85841e-e002-0a2a0a5209dd-0a2a4506e584-10
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:23:31 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a858423-195a-0a2a45060019-c387df82a234-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:23:31 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id E53A884A96;
 Wed, 19 Aug 2026 10:23:21 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E8F612F81;
 Wed, 19 Aug 2026 10:23:17 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id 0iJsNxWEhWr6EQAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 19 Aug 2026 10:23:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787135006; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=rUrkP0fQrqvOQ9OLE4fnFFCdOZvcGWwepbiIvdEtgQk=;
	b=VVgQbBAdIb9QbmJJKirftoUF+aLqDdBw7M79uJ5wJ3yiffCWjywiB/nzGsxnitVzRQ2V0y
	OjWvwOivcXo4wZ0oErSvG3k+sg2aA4VD3s+STj5Y0WinIsHcjW9SCkuzl8cGw76jQIat7f
	qaV+BFDcHMkxl/Bz9an1oUftBzWhnFs=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="uSkjk/rJ"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787135001; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=rUrkP0fQrqvOQ9OLE4fnFFCdOZvcGWwepbiIvdEtgQk=;
	b=uSkjk/rJ2Uh0ynDagC0v4V8HunG0SNGBzghncML4JpCo4kJ+tcGw16EamiLRhPftSnSgHD
	abINT6UpVtoBnUoPcMJ7HQp7PZwXJZ1WyNjAEZ/L49zaXywWVYk67G9J1R12XT+0kgBSLI
	vpl1rlDAj/5ujSIpWywIj9Omy2bdecA=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	virtualization@lists.linux.dev,
	linux-ide@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org,
	linux-crypto@vger.kernel.org,
	linux-gpio@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	kvm@vger.kernel.org,
	linux-edac@vger.kernel.org,
	linux-pci@vger.kernel.org,
	linux-pm@vger.kernel.org,
	linux-coco@lists.linux.dev,
	linux-acpi@vger.kernel.org,
	linux-hwmon@vger.kernel.org,
	linux-mtd@lists.infradead.org,
	platform-driver-x86@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	Niklas Cassel <cassel@kernel.org>,
	David Airlie <airlied@redhat.com>,
	Helge Deller <deller@gmx.de>,
	linux-geode@lists.infradead.org,
	Olivia Mackall <olivia@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Linus Walleij <linusw@kernel.org>,
	Bartosz Golaszewski <brgl@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Pu Wen <puwen@hygon.cn>,
	Tony Luck <tony.luck@intel.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Dave Martin <Dave.Martin@arm.com>,
	James Morse <james.morse@arm.com>,
	Babu Moger <babu.moger@amd.com>,
	Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Pavel Machek <pavel@kernel.org>,
	Kiryl Shutsemau <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Len Brown <lenb@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Huang Rui <ray.huang@amd.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Perry Yuan <perry.yuan@amd.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Ashok Raj <ashok.raj.linux@gmail.com>,
	Hans de Goede <hansg@kernel.org>,
	=?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
	Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
	David E Box <david.e.box@intel.com>,
	Daniel Lezcano <daniel.lezcano@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
Date: Wed, 19 Aug 2026 12:23:01 +0200
Message-ID: <20260819102314.1499258-1-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.51
X-Spam-Level: 
X-Rspamd-Action: no action
X-Rspamd-Queue-Id: E53A884A96
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[suse.com,kernel.org,redhat.com,alien8.de,linux.intel.com,zytor.com,broadcom.com,gmx.de,lists.infradead.org,selenic.com,gondor.apana.org.au,arndb.de,linuxfoundation.org,infradead.org,arm.com,google.com,intel.com,linaro.org,microsoft.com,hygon.cn,amd.com,zhaoxin.com,oracle.com,roeck-us.net,gmail.com,bootlin.com,nod.at,ti.com,lists.xenproject.org];
	ARC_NA(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_TLS_ALL(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLfz41jyixnitwwfnh5yqd7x44)];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCPT_COUNT_GT_50(0.00)[95];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-purgate-ID: tlsNG-16d1c6/1787135011-F74C977B-27F42CEF/0/0
X-purgate-type: clean
X-purgate-size: 9977

For accessing the MSR registers on the local CPU, there are 2 types of
interfaces: the "modern" 64-bit ones (rdmsrq() etc.) and the 32-bit
ones (rdmsr() etc.) which are using the upper and lower 32-bit halves
of the 64-bit wide MSR register values.

The 32-bit interfaces are not optimal for 3 reasons:

- They are based on primitives using 64-bit sized values anyway.

- Modern x86 CPUs have added support for MSR access instructions using
  an immediate value instead of a register for addressing the MSR,
  while the value is in a 64-bit register.

- rdmsr() is a macro storing the upper and lower 32-bit halves in
  variables specified as macro parameters. This is obscuring variable
  assignment through a macro. Additionally rdmsrq() is mimicking this
  pattern by being a macro, too, with the target variable specified as
  a parameter as well.

For those reasons drop the 32-bit interfaces for accessing the x86 MSR
registers completely and only use the 64-bit variants.

This allows to switch all "high-level" MSR access macros to inline
functions in the end.

This series will be used as the base for further reorganisation of the
MSR access functions, especially for completely inlining the MSR
access instructions even with paravirtualization being active.

Based on kernel 7.3 as of 2026-08-19.

Changes in V2:
- dropped already applied patches
- added patch 1
- rebased

Juergen Gross (13):
  x86/cpu: Fix coding style violation
  x86/msr: Remove wrmsr_safe()
  x86/msr: Remove rdmsr_safe()
  drivers/ata: Stop using 32-bit MSR interfaces
  agp/nvidia: Stop using 32-bit MSR interfaces
  fbdev/geode: Stop using 32-bit MSR interfaces
  hw_random/via-rng: Stop using 32-bit MSR interfaces
  drivers/gpio: Stop using 32-bit MSR interfaces
  drivers/misc: Stop using 32-bit MSR interfaces
  x86/msr: Remove wrmsr()
  x86/msr: Remove rdmsr()
  treewide: convert rdmsrq() from a macro to an inline function
  x86/msr: Simplify some rdmsrq() use cases

 arch/x86/coco/sev/core.c                      |  2 +-
 arch/x86/events/amd/brs.c                     |  4 +-
 arch/x86/events/amd/core.c                    |  8 +--
 arch/x86/events/amd/ibs.c                     | 18 +++----
 arch/x86/events/amd/lbr.c                     | 16 ++----
 arch/x86/events/amd/power.c                   |  8 +--
 arch/x86/events/amd/uncore.c                  |  4 +-
 arch/x86/events/core.c                        | 20 ++++----
 arch/x86/events/intel/core.c                  | 15 ++----
 arch/x86/events/intel/cstate.c                |  5 +-
 arch/x86/events/intel/ds.c                    |  2 +-
 arch/x86/events/intel/knc.c                   | 10 ++--
 arch/x86/events/intel/lbr.c                   | 25 +++-------
 arch/x86/events/intel/p4.c                    |  6 +--
 arch/x86/events/intel/p6.c                    |  4 +-
 arch/x86/events/intel/pt.c                    | 12 ++---
 arch/x86/events/intel/uncore.c                |  6 +--
 arch/x86/events/intel/uncore_nhmex.c          |  4 +-
 arch/x86/events/intel/uncore_snb.c            |  2 +-
 arch/x86/events/intel/uncore_snbep.c          |  6 +--
 arch/x86/events/msr.c                         |  2 +-
 arch/x86/events/perf_event.h                  |  6 +--
 arch/x86/events/rapl.c                        |  6 +--
 arch/x86/events/zhaoxin/core.c                | 10 ++--
 arch/x86/hyperv/hv_apic.c                     |  9 ++--
 arch/x86/hyperv/hv_init.c                     | 26 +++++-----
 arch/x86/hyperv/hv_spinlock.c                 |  2 +-
 arch/x86/include/asm/apic.h                   |  7 +--
 arch/x86/include/asm/debugreg.h               |  6 +--
 arch/x86/include/asm/fsgsbase.h               |  2 +-
 arch/x86/include/asm/kvm_host.h               |  5 +-
 arch/x86/include/asm/msr.h                    | 39 ++-------------
 arch/x86/include/asm/paravirt.h               | 26 +---------
 arch/x86/kernel/apic/apic.c                   | 14 +++---
 arch/x86/kernel/apic/apic_numachip.c          |  6 +--
 arch/x86/kernel/cet.c                         |  2 +-
 arch/x86/kernel/cpu/amd.c                     | 14 +++---
 arch/x86/kernel/cpu/aperfmperf.c              |  8 +--
 arch/x86/kernel/cpu/bugs.c                    | 12 ++---
 arch/x86/kernel/cpu/bus_lock.c                |  8 +--
 arch/x86/kernel/cpu/centaur.c                 |  8 +--
 arch/x86/kernel/cpu/common.c                  | 12 ++---
 arch/x86/kernel/cpu/feat_ctl.c                |  4 +-
 arch/x86/kernel/cpu/hygon.c                   |  4 +-
 arch/x86/kernel/cpu/intel.c                   |  6 +--
 arch/x86/kernel/cpu/intel_epb.c               |  4 +-
 arch/x86/kernel/cpu/mce/amd.c                 |  4 +-
 arch/x86/kernel/cpu/mce/core.c                |  8 +--
 arch/x86/kernel/cpu/mce/inject.c              |  2 +-
 arch/x86/kernel/cpu/mce/intel.c               | 18 +++----
 arch/x86/kernel/cpu/mce/p5.c                  |  8 +--
 arch/x86/kernel/cpu/mce/winchip.c             |  2 +-
 arch/x86/kernel/cpu/microcode/intel.c         |  2 +-
 arch/x86/kernel/cpu/mshyperv.c                |  6 +--
 arch/x86/kernel/cpu/mtrr/amd.c                |  4 +-
 arch/x86/kernel/cpu/mtrr/cleanup.c            |  4 +-
 arch/x86/kernel/cpu/mtrr/generic.c            | 32 ++++++------
 arch/x86/kernel/cpu/mtrr/mtrr.c               |  2 +-
 arch/x86/kernel/cpu/resctrl/core.c            |  2 +-
 arch/x86/kernel/cpu/resctrl/monitor.c         |  4 +-
 arch/x86/kernel/cpu/resctrl/pseudo_lock.c     |  4 +-
 arch/x86/kernel/cpu/resctrl/rdtgroup.c        |  2 +-
 arch/x86/kernel/cpu/topology.c                |  2 +-
 arch/x86/kernel/cpu/topology_amd.c            |  4 +-
 arch/x86/kernel/cpu/transmeta.c               |  8 +--
 arch/x86/kernel/cpu/tsx.c                     | 10 ++--
 arch/x86/kernel/cpu/umwait.c                  |  2 +-
 arch/x86/kernel/cpu/zhaoxin.c                 |  4 +-
 arch/x86/kernel/fpu/core.c                    |  2 +-
 arch/x86/kernel/hpet.c                        |  2 +-
 arch/x86/kernel/kvm.c                         |  2 +-
 arch/x86/kernel/mmconf-fam10h_64.c            |  6 +--
 arch/x86/kernel/process.c                     |  4 +-
 arch/x86/kernel/process_64.c                  | 14 +++---
 arch/x86/kernel/shstk.c                       |  8 +--
 arch/x86/kernel/traps.c                       |  4 +-
 arch/x86/kernel/tsc.c                         |  2 +-
 arch/x86/kernel/tsc_msr.c                     |  6 +--
 arch/x86/kernel/tsc_sync.c                    |  6 +--
 arch/x86/kvm/svm/pmu.c                        |  4 +-
 arch/x86/kvm/svm/svm.c                        |  4 +-
 arch/x86/kvm/vmx/nested.c                     |  4 +-
 arch/x86/kvm/vmx/pmu_intel.c                  |  8 +--
 arch/x86/kvm/vmx/sgx.c                        |  6 +--
 arch/x86/kvm/vmx/vmx.c                        | 36 ++++++-------
 arch/x86/kvm/x86.c                            |  8 +--
 arch/x86/lib/insn-eval.c                      |  6 +--
 arch/x86/lib/msr-smp.c                        |  2 +-
 arch/x86/mm/pat/memtype.c                     |  2 +-
 arch/x86/pci/amd_bus.c                        |  8 +--
 arch/x86/platform/olpc/olpc-xo1-rtc.c         |  6 +--
 arch/x86/platform/olpc/olpc-xo1-sci.c         |  2 +-
 arch/x86/power/cpu.c                          | 10 ++--
 arch/x86/realmode/init.c                      |  2 +-
 arch/x86/virt/hw.c                            |  8 +--
 arch/x86/virt/svm/sev.c                       | 18 +++----
 arch/x86/virt/vmx/tdx/tdx.c                   |  2 +-
 arch/x86/xen/suspend.c                        |  2 +-
 drivers/acpi/processor_perflib.c              |  2 +-
 drivers/ata/pata_cs5535.c                     | 20 ++++----
 drivers/ata/pata_cs5536.c                     | 17 +++----
 drivers/char/agp/nvidia-agp.c                 | 32 ++++++------
 drivers/char/hw_random/via-rng.c              | 29 +++++------
 drivers/cpufreq/acpi-cpufreq.c                |  8 +--
 drivers/cpufreq/amd-pstate.c                  |  4 +-
 drivers/cpufreq/e_powersaver.c                | 20 ++++----
 drivers/cpufreq/intel_pstate.c                | 30 +++++------
 drivers/cpufreq/longhaul.c                    | 12 ++---
 drivers/cpufreq/longrun.c                     | 16 +++---
 drivers/cpufreq/powernow-k7.c                 | 10 ++--
 drivers/cpufreq/powernow-k8.c                 |  8 +--
 drivers/cpufreq/speedstep-centrino.c          |  4 +-
 drivers/cpufreq/speedstep-lib.c               | 14 +++---
 drivers/edac/amd64_edac.c                     |  6 +--
 drivers/gpio/gpio-cs5535.c                    | 10 ++--
 drivers/hv/mshv_vtl_main.c                    |  2 +-
 drivers/hwmon/hwmon-vid.c                     |  4 +-
 drivers/idle/intel_idle.c                     | 26 +++++-----
 drivers/misc/cs5535-mfgpt.c                   | 33 ++++++------
 drivers/mtd/nand/raw/cs553x_nand.c            |  6 +--
 drivers/platform/x86/intel/ifs/load.c         | 10 ++--
 drivers/platform/x86/intel/ifs/runtest.c      |  8 +--
 drivers/platform/x86/intel/pmc/cnp.c          |  2 +-
 .../intel/speed_select_if/isst_if_mbox_msr.c  |  6 +--
 .../intel/speed_select_if/isst_tpmi_core.c    |  2 +-
 drivers/platform/x86/intel_ips.c              | 20 ++++----
 drivers/powercap/intel_rapl_msr.c             |  2 +-
 drivers/thermal/intel/intel_hfi.c             |  8 +--
 drivers/thermal/intel/therm_throt.c           | 22 ++++----
 drivers/thermal/intel/x86_pkg_temp_thermal.c  |  6 +--
 drivers/video/fbdev/geode/display_gx.c        |  8 +--
 drivers/video/fbdev/geode/gxfb_core.c         |  2 +-
 drivers/video/fbdev/geode/lxfb_ops.c          | 50 +++++++++----------
 drivers/video/fbdev/geode/suspend_gx.c        | 24 +++++----
 drivers/video/fbdev/geode/video_gx.c          |  8 +--
 include/linux/cs5535.h                        | 10 ++--
 136 files changed, 571 insertions(+), 683 deletions(-)

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:24:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395107.1633631 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdTL-0001KM-PY; Wed, 19 Aug 2026 10:24:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395107.1633631; Wed, 19 Aug 2026 10:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdTL-0001KF-Lr; Wed, 19 Aug 2026 10:24:39 +0000
Received: by outflank-mailman (input) for mailman id 1395107;
 Wed, 19 Aug 2026 10:24:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwdTJ-0001K0-7I
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:24:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwdTI-0092kx-KC
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:24:36 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a858464-8faa-0a2a0a5109dd-0a2a45098466-2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:24:36 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a858464-be1a-0a2a45090019-c387df829ca6-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:24:36 +0200
Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id AA4C784A91;
 Wed, 19 Aug 2026 10:24:27 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BD5C12F81;
 Wed, 19 Aug 2026 10:24:25 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id LmYmLVmEhWoGEwAAD6G6ig
 (envelope-from <jgross@suse.com>); Wed, 19 Aug 2026 10:24:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787135072; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=djWREWd79pfT0XaqMjUu2+dY6D2o54Oqcv3fLfZnWC4=;
	b=YB1FY5wNh99mEzz9IDvVNRjVgK3qkOmr/OggIchv9Kb0afJcmI2aqV4CzakAi5ZJer2Iqk
	AAgsx+a/ivyet/kX2XQwJ2jIbYWkLFoJEj5ldnMzXrB9YG51rhoOaQw2jqK4zDCP4vPD8k
	wHFhvZrzyts6WsUxabY83o25GuAHUXI=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787135067; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=djWREWd79pfT0XaqMjUu2+dY6D2o54Oqcv3fLfZnWC4=;
	b=jYwlB1FSeINheCaLqnBuiwL1t1IfxcZz4F05eIgbRvb5Bqhyz+yxYp7YpNAFY5UOQvDfet
	tB67cXntJTg+72e3uxAHWhSQBDOpT7FYXaVqjNxTNTLx3kUHbBx8/uoxhip/UFoqMS5pQU
	XWFq1uZEtt0be5PtjjX4aa1SU1uC1b0=
From: Juergen Gross <jgross@suse.com>
To: linux-kernel@vger.kernel.org,
	x86@kernel.org,
	linux-perf-users@vger.kernel.org,
	linux-hyperv@vger.kernel.org,
	kvm@vger.kernel.org,
	virtualization@lists.linux.dev,
	linux-edac@vger.kernel.org,
	linux-pci@vger.kernel.org,
	linux-pm@vger.kernel.org,
	linux-coco@lists.linux.dev,
	linux-acpi@vger.kernel.org,
	linux-ide@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	linux-crypto@vger.kernel.org,
	linux-gpio@vger.kernel.org,
	linux-hwmon@vger.kernel.org,
	linux-mtd@lists.infradead.org,
	platform-driver-x86@vger.kernel.org,
	linux-fbdev@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	Alexey Makhalov <alexey.makhalov@broadcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Pu Wen <puwen@hygon.cn>,
	Tony Luck <tony.luck@intel.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Dave Martin <Dave.Martin@arm.com>,
	James Morse <james.morse@arm.com>,
	Babu Moger <babu.moger@amd.com>,
	Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Pavel Machek <pavel@kernel.org>,
	Kiryl Shutsemau <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Len Brown <lenb@kernel.org>,
	Damien Le Moal <dlemoal@kernel.org>,
	Niklas Cassel <cassel@kernel.org>,
	David Airlie <airlied@redhat.com>,
	Olivia Mackall <olivia@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Huang Rui <ray.huang@amd.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Perry Yuan <perry.yuan@amd.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	Linus Walleij <linusw@kernel.org>,
	Bartosz Golaszewski <brgl@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Ashok Raj <ashok.raj.linux@gmail.com>,
	Hans de Goede <hansg@kernel.org>,
	=?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
	Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
	David E Box <david.e.box@intel.com>,
	Daniel Lezcano <daniel.lezcano@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>,
	Helge Deller <deller@gmx.de>,
	xen-devel@lists.xenproject.org,
	linux-geode@lists.infradead.org
Subject: [PATCH v2 12/13] treewide: convert rdmsrq() from a macro to an inline function
Date: Wed, 19 Aug 2026 12:23:13 +0200
Message-ID: <20260819102314.1499258-13-jgross@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260819102314.1499258-1-jgross@suse.com>
References: <20260819102314.1499258-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -5.30
X-Spam-Level: 
X-Spam-Flag: NO
X-Spamd-Result: default: False [-5.30 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_GT_50(0.00)[95];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_CC(0.00)[suse.com,kernel.org,redhat.com,alien8.de,linux.intel.com,zytor.com,infradead.org,arm.com,google.com,intel.com,linaro.org,microsoft.com,broadcom.com,hygon.cn,amd.com,zhaoxin.com,oracle.com,selenic.com,gondor.apana.org.au,roeck-us.net,gmail.com,arndb.de,linuxfoundation.org,bootlin.com,nod.at,ti.com,gmx.de,lists.xenproject.org,lists.infradead.org];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	TAGGED_RCPT(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLrf5uwk9di5w18wgdjy9q5m8s)];
	RCVD_TLS_ALL(0.00)[]
X-purgate-ID: tlsNG-bad1c0/1787135076-3AAD8394-BE7B9359/0/0
X-purgate-type: clean
X-purgate-size: 167134

Today rdmsrq() is a macro using its second parameter as the target for
storing the read MSR value.

Convert rdmsrq() to an inline function returning the MSR value.

The users have been converted using the following semantic patch:

  // Options: --include-headers

  virtual patch
  virtual report

  @@
  expression msr, val;
  @@
  (
  - rdmsrq(msr,val)
  + val = rdmsrq(msr)
  )

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/coco/sev/core.c                      |  2 +-
 arch/x86/events/amd/brs.c                     |  4 +--
 arch/x86/events/amd/core.c                    |  4 +--
 arch/x86/events/amd/ibs.c                     | 18 +++++-----
 arch/x86/events/amd/lbr.c                     |  8 ++---
 arch/x86/events/amd/power.c                   |  8 ++---
 arch/x86/events/amd/uncore.c                  |  4 +--
 arch/x86/events/core.c                        | 20 +++++------
 arch/x86/events/intel/core.c                  | 11 +++---
 arch/x86/events/intel/cstate.c                |  2 +-
 arch/x86/events/intel/ds.c                    |  2 +-
 arch/x86/events/intel/knc.c                   |  6 ++--
 arch/x86/events/intel/lbr.c                   | 14 ++++----
 arch/x86/events/intel/p4.c                    |  6 ++--
 arch/x86/events/intel/p6.c                    |  4 +--
 arch/x86/events/intel/pt.c                    | 12 +++----
 arch/x86/events/intel/uncore.c                |  2 +-
 arch/x86/events/intel/uncore_nhmex.c          |  4 +--
 arch/x86/events/intel/uncore_snb.c            |  2 +-
 arch/x86/events/intel/uncore_snbep.c          |  6 ++--
 arch/x86/events/msr.c                         |  2 +-
 arch/x86/events/perf_event.h                  |  6 ++--
 arch/x86/events/rapl.c                        |  4 +--
 arch/x86/events/zhaoxin/core.c                |  6 ++--
 arch/x86/hyperv/hv_apic.c                     |  6 ++--
 arch/x86/hyperv/hv_init.c                     | 26 +++++++-------
 arch/x86/hyperv/hv_spinlock.c                 |  2 +-
 arch/x86/include/asm/apic.h                   |  4 +--
 arch/x86/include/asm/debugreg.h               |  2 +-
 arch/x86/include/asm/fsgsbase.h               |  2 +-
 arch/x86/include/asm/kvm_host.h               |  2 +-
 arch/x86/include/asm/msr.h                    | 15 ++++----
 arch/x86/include/asm/paravirt.h               |  8 ++---
 arch/x86/kernel/apic/apic.c                   | 14 ++++----
 arch/x86/kernel/apic/apic_numachip.c          |  6 ++--
 arch/x86/kernel/cet.c                         |  2 +-
 arch/x86/kernel/cpu/amd.c                     | 14 ++++----
 arch/x86/kernel/cpu/aperfmperf.c              |  8 ++---
 arch/x86/kernel/cpu/bugs.c                    | 12 +++----
 arch/x86/kernel/cpu/bus_lock.c                |  8 ++---
 arch/x86/kernel/cpu/centaur.c                 |  8 ++---
 arch/x86/kernel/cpu/common.c                  | 12 +++----
 arch/x86/kernel/cpu/feat_ctl.c                |  4 +--
 arch/x86/kernel/cpu/hygon.c                   |  4 +--
 arch/x86/kernel/cpu/intel.c                   |  6 ++--
 arch/x86/kernel/cpu/intel_epb.c               |  4 +--
 arch/x86/kernel/cpu/mce/amd.c                 |  4 +--
 arch/x86/kernel/cpu/mce/core.c                |  8 ++---
 arch/x86/kernel/cpu/mce/inject.c              |  2 +-
 arch/x86/kernel/cpu/mce/intel.c               | 18 +++++-----
 arch/x86/kernel/cpu/mce/p5.c                  |  8 ++---
 arch/x86/kernel/cpu/mce/winchip.c             |  2 +-
 arch/x86/kernel/cpu/microcode/intel.c         |  2 +-
 arch/x86/kernel/cpu/mshyperv.c                |  6 ++--
 arch/x86/kernel/cpu/mtrr/amd.c                |  4 +--
 arch/x86/kernel/cpu/mtrr/cleanup.c            |  4 +--
 arch/x86/kernel/cpu/mtrr/generic.c            | 32 ++++++++---------
 arch/x86/kernel/cpu/mtrr/mtrr.c               |  2 +-
 arch/x86/kernel/cpu/resctrl/core.c            |  2 +-
 arch/x86/kernel/cpu/resctrl/monitor.c         |  4 +--
 arch/x86/kernel/cpu/resctrl/pseudo_lock.c     |  4 +--
 arch/x86/kernel/cpu/resctrl/rdtgroup.c        |  2 +-
 arch/x86/kernel/cpu/topology.c                |  2 +-
 arch/x86/kernel/cpu/topology_amd.c            |  4 +--
 arch/x86/kernel/cpu/transmeta.c               |  2 +-
 arch/x86/kernel/cpu/tsx.c                     | 10 +++---
 arch/x86/kernel/cpu/umwait.c                  |  2 +-
 arch/x86/kernel/cpu/zhaoxin.c                 |  4 +--
 arch/x86/kernel/fpu/core.c                    |  2 +-
 arch/x86/kernel/hpet.c                        |  2 +-
 arch/x86/kernel/kvm.c                         |  2 +-
 arch/x86/kernel/mmconf-fam10h_64.c            |  6 ++--
 arch/x86/kernel/process.c                     |  4 +--
 arch/x86/kernel/process_64.c                  | 14 ++++----
 arch/x86/kernel/shstk.c                       |  8 ++---
 arch/x86/kernel/traps.c                       |  4 +--
 arch/x86/kernel/tsc.c                         |  2 +-
 arch/x86/kernel/tsc_msr.c                     |  6 ++--
 arch/x86/kernel/tsc_sync.c                    |  6 ++--
 arch/x86/kvm/svm/pmu.c                        |  4 +--
 arch/x86/kvm/svm/svm.c                        |  4 +--
 arch/x86/kvm/vmx/nested.c                     |  4 +--
 arch/x86/kvm/vmx/pmu_intel.c                  |  8 ++---
 arch/x86/kvm/vmx/sgx.c                        |  6 ++--
 arch/x86/kvm/vmx/vmx.c                        | 36 +++++++++----------
 arch/x86/kvm/x86.c                            |  8 ++---
 arch/x86/lib/insn-eval.c                      |  6 ++--
 arch/x86/lib/msr-smp.c                        |  2 +-
 arch/x86/mm/pat/memtype.c                     |  2 +-
 arch/x86/pci/amd_bus.c                        |  8 ++---
 arch/x86/platform/olpc/olpc-xo1-rtc.c         |  6 ++--
 arch/x86/platform/olpc/olpc-xo1-sci.c         |  2 +-
 arch/x86/power/cpu.c                          | 10 +++---
 arch/x86/realmode/init.c                      |  2 +-
 arch/x86/virt/hw.c                            |  8 ++---
 arch/x86/virt/svm/sev.c                       | 18 +++++-----
 arch/x86/virt/vmx/tdx/tdx.c                   |  2 +-
 arch/x86/xen/suspend.c                        |  2 +-
 drivers/acpi/processor_perflib.c              |  2 +-
 drivers/ata/pata_cs5535.c                     |  4 +--
 drivers/ata/pata_cs5536.c                     |  2 +-
 drivers/char/agp/nvidia-agp.c                 |  6 ++--
 drivers/char/hw_random/via-rng.c              |  4 +--
 drivers/cpufreq/acpi-cpufreq.c                |  8 ++---
 drivers/cpufreq/amd-pstate.c                  |  4 +--
 drivers/cpufreq/e_powersaver.c                | 20 +++++------
 drivers/cpufreq/intel_pstate.c                | 30 ++++++++--------
 drivers/cpufreq/longhaul.c                    | 12 +++----
 drivers/cpufreq/longrun.c                     | 16 ++++-----
 drivers/cpufreq/powernow-k7.c                 | 10 +++---
 drivers/cpufreq/powernow-k8.c                 |  8 ++---
 drivers/cpufreq/speedstep-centrino.c          |  4 +--
 drivers/cpufreq/speedstep-lib.c               | 14 ++++----
 drivers/edac/amd64_edac.c                     |  6 ++--
 drivers/gpio/gpio-cs5535.c                    |  2 +-
 drivers/hv/mshv_vtl_main.c                    |  2 +-
 drivers/hwmon/hwmon-vid.c                     |  4 +--
 drivers/idle/intel_idle.c                     | 26 +++++++-------
 drivers/misc/cs5535-mfgpt.c                   |  6 ++--
 drivers/mtd/nand/raw/cs553x_nand.c            |  6 ++--
 drivers/platform/x86/intel/ifs/load.c         | 10 +++---
 drivers/platform/x86/intel/ifs/runtest.c      |  8 ++---
 drivers/platform/x86/intel/pmc/cnp.c          |  2 +-
 .../intel/speed_select_if/isst_if_mbox_msr.c  |  6 ++--
 .../intel/speed_select_if/isst_tpmi_core.c    |  2 +-
 drivers/platform/x86/intel_ips.c              | 20 +++++------
 drivers/powercap/intel_rapl_msr.c             |  2 +-
 drivers/thermal/intel/intel_hfi.c             |  8 ++---
 drivers/thermal/intel/therm_throt.c           | 22 ++++++------
 drivers/thermal/intel/x86_pkg_temp_thermal.c  |  6 ++--
 drivers/video/fbdev/geode/display_gx.c        |  2 +-
 drivers/video/fbdev/geode/gxfb_core.c         |  2 +-
 drivers/video/fbdev/geode/lxfb_ops.c          | 18 +++++-----
 drivers/video/fbdev/geode/suspend_gx.c        |  8 ++---
 drivers/video/fbdev/geode/video_gx.c          |  8 ++---
 include/linux/cs5535.h                        |  2 +-
 136 files changed, 484 insertions(+), 486 deletions(-)

diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index cc292d7c6fd1..2a1875642cd4 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -2026,7 +2026,7 @@ void __init snp_secure_tsc_init(void)
 	secrets = (__force struct snp_secrets_page *)mem;
 
 	setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
-	rdmsrq(MSR_AMD64_GUEST_TSC_FREQ, tsc_freq_mhz);
+	tsc_freq_mhz = rdmsrq(MSR_AMD64_GUEST_TSC_FREQ);
 
 	/* Extract the GUEST TSC MHZ from BIT[17:0], rest is reserved space */
 	tsc_freq_mhz &= GENMASK_ULL(17, 0);
diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c
index dc564688f3d7..4df3a2a736e0 100644
--- a/arch/x86/events/amd/brs.c
+++ b/arch/x86/events/amd/brs.c
@@ -325,7 +325,7 @@ void amd_brs_drain(void)
 		u32 brs_idx = tos - i;
 		u64 from, to;
 
-		rdmsrq(brs_to(brs_idx), to);
+		to = rdmsrq(brs_to(brs_idx));
 
 		/* Entry does not belong to us (as marked by kernel) */
 		if (to == BRS_POISON)
@@ -338,7 +338,7 @@ void amd_brs_drain(void)
 		 */
 		to = (u64)(((s64)to << shift) >> shift);
 
-		rdmsrq(brs_from(brs_idx), from);
+		from = rdmsrq(brs_from(brs_idx));
 
 		if (!amd_brs_match_plm(event, from, to))
 			continue;
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index 49b6b8fce566..80ed49dba255 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -663,7 +663,7 @@ static inline u64 amd_pmu_get_global_status(void)
 	u64 status;
 
 	/* PerfCntrGlobalStatus is read-only */
-	rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, status);
+	status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS);
 
 	return status;
 }
@@ -683,7 +683,7 @@ static bool amd_pmu_test_overflow_topbit(int idx)
 {
 	u64 counter;
 
-	rdmsrq(x86_pmu_event_addr(idx), counter);
+	counter = rdmsrq(x86_pmu_event_addr(idx));
 
 	return !(counter & BIT_ULL(x86_pmu.cntval_bits - 1));
 }
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 3531f9c23b8c..17eab32164df 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -505,7 +505,7 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct perf_event *event,
 	 * prev count manually on overflow.
 	 */
 	while (!perf_event_try_update(event, count, 64)) {
-		rdmsrq(event->hw.config_base, *config);
+		*config = rdmsrq(event->hw.config_base);
 		count = perf_ibs->get_count(*config);
 	}
 }
@@ -610,7 +610,7 @@ static void perf_ibs_stop(struct perf_event *event, int flags)
 	if (!stopping && (hwc->state & PERF_HES_UPTODATE))
 		return;
 
-	rdmsrq(hwc->config_base, config);
+	config = rdmsrq(hwc->config_base);
 
 	if (stopping) {
 		/*
@@ -1437,7 +1437,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs)
 	hwc = &event->hw;
 	msr = hwc->config_base;
 	buf = ibs_data.regs;
-	rdmsrq(msr, *buf);
+	*buf = rdmsrq(msr);
 	if (!(*buf++ & perf_ibs->valid_mask))
 		goto fail;
 
@@ -1455,7 +1455,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs)
 	offset_max = perf_ibs_get_offset_max(perf_ibs, event, check_rip);
 
 	do {
-		rdmsrq(msr + offset, *buf++);
+		*buf++ = rdmsrq(msr + offset);
 		size++;
 		offset = find_next_bit(perf_ibs->offset_mask,
 				       perf_ibs->offset_max,
@@ -1497,17 +1497,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs)
 	if (event->attr.sample_type & PERF_SAMPLE_RAW) {
 		if (perf_ibs == &perf_ibs_op) {
 			if (ibs_caps & IBS_CAPS_BRNTRGT) {
-				rdmsrq(MSR_AMD64_IBSBRTARGET, *buf++);
+				*buf++ = rdmsrq(MSR_AMD64_IBSBRTARGET);
 				br_target_idx = size;
 				size++;
 			}
 			if (ibs_caps & IBS_CAPS_OPDATA4) {
-				rdmsrq(MSR_AMD64_IBSOPDATA4, *buf++);
+				*buf++ = rdmsrq(MSR_AMD64_IBSOPDATA4);
 				size++;
 			}
 		}
 		if (perf_ibs == &perf_ibs_fetch && (ibs_caps & IBS_CAPS_FETCHCTLEXTD)) {
-			rdmsrq(MSR_AMD64_ICIBSEXTDCTL, *buf++);
+			*buf++ = rdmsrq(MSR_AMD64_ICIBSEXTDCTL);
 			size++;
 		}
 	}
@@ -1768,7 +1768,7 @@ static inline int ibs_eilvt_valid(void)
 
 	preempt_disable();
 
-	rdmsrq(MSR_AMD64_IBSCTL, val);
+	val = rdmsrq(MSR_AMD64_IBSCTL);
 	offset = val & IBSCTL_LVT_OFFSET_MASK;
 
 	if (!(val & IBSCTL_LVT_OFFSET_VALID)) {
@@ -1883,7 +1883,7 @@ static inline int get_ibs_lvt_offset(void)
 {
 	u64 val;
 
-	rdmsrq(MSR_AMD64_IBSCTL, val);
+	val = rdmsrq(MSR_AMD64_IBSCTL);
 	if (!(val & IBSCTL_LVT_OFFSET_VALID))
 		return -EINVAL;
 
diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
index 9d9c961989d5..29628af6a023 100644
--- a/arch/x86/events/amd/lbr.c
+++ b/arch/x86/events/amd/lbr.c
@@ -76,7 +76,7 @@ static __always_inline u64 amd_pmu_lbr_get_from(unsigned int idx)
 {
 	u64 val;
 
-	rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2, val);
+	val = rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2);
 
 	return val;
 }
@@ -85,7 +85,7 @@ static __always_inline u64 amd_pmu_lbr_get_to(unsigned int idx)
 {
 	u64 val;
 
-	rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1, val);
+	val = rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1);
 
 	return val;
 }
@@ -404,11 +404,11 @@ void amd_pmu_lbr_enable_all(void)
 	}
 
 	if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
-		rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
+		dbg_ctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
 	}
 
-	rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg);
+	dbg_extn_cfg = rdmsrq(MSR_AMD_DBG_EXTN_CFG);
 	wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg | DBG_EXTN_CFG_LBRV2EN);
 }
 
diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c
index 744dffa42dee..553a6d0c8a14 100644
--- a/arch/x86/events/amd/power.c
+++ b/arch/x86/events/amd/power.c
@@ -52,8 +52,8 @@ static void event_update(struct perf_event *event)
 
 	prev_pwr_acc = hwc->pwr_acc;
 	prev_ptsc = hwc->ptsc;
-	rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, new_pwr_acc);
-	rdmsrq(MSR_F15H_PTSC, new_ptsc);
+	new_pwr_acc = rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR);
+	new_ptsc = rdmsrq(MSR_F15H_PTSC);
 
 	/*
 	 * Calculate the CU power consumption over a time period, the unit of
@@ -79,8 +79,8 @@ static void __pmu_event_start(struct perf_event *event)
 
 	event->hw.state = 0;
 
-	rdmsrq(MSR_F15H_PTSC, event->hw.ptsc);
-	rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, event->hw.pwr_acc);
+	event->hw.ptsc = rdmsrq(MSR_F15H_PTSC);
+	event->hw.pwr_acc = rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR);
 }
 
 static void pmu_event_start(struct perf_event *event, int mode)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 222dfab9225f..9d81b24cd963 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -151,7 +151,7 @@ static void amd_uncore_read(struct perf_event *event)
 	 * read counts directly from the corresponding PERF_CTR.
 	 */
 	if (hwc->event_base_rdpmc < 0)
-		rdmsrq(hwc->event_base, new);
+		new = rdmsrq(hwc->event_base);
 	else
 		new = rdpmc(hwc->event_base_rdpmc);
 
@@ -998,7 +998,7 @@ static void amd_uncore_umc_read(struct perf_event *event)
 	 * UMC counters do not have RDPMC assignments. Read counts directly
 	 * from the corresponding PERF_CTR.
 	 */
-	rdmsrq(hwc->event_base, new);
+	new = rdmsrq(hwc->event_base);
 
 	/*
 	 * Unlike the other uncore counters, UMC counters saturate and set the
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 8b3ea0adb965..34bd80bb2c9e 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -711,7 +711,7 @@ void x86_pmu_disable_all(void)
 
 		if (!test_bit(idx, cpuc->active_mask))
 			continue;
-		rdmsrq(x86_pmu_config_addr(idx), val);
+		val = rdmsrq(x86_pmu_config_addr(idx));
 		if (!(val & ARCH_PERFMON_EVENTSEL_ENABLE))
 			continue;
 		val &= ~ARCH_PERFMON_EVENTSEL_ENABLE;
@@ -1592,10 +1592,10 @@ void perf_event_print_debug(void)
 		return;
 
 	if (x86_pmu.version >= 2) {
-		rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL, ctrl);
-		rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status);
-		rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, overflow);
-		rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL, fixed);
+		ctrl = rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL);
+		status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS);
+		overflow = rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL);
+		fixed = rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL);
 
 		pr_info("\n");
 		pr_info("CPU#%d: ctrl:       %016llx\n", cpu, ctrl);
@@ -1603,19 +1603,19 @@ void perf_event_print_debug(void)
 		pr_info("CPU#%d: overflow:   %016llx\n", cpu, overflow);
 		pr_info("CPU#%d: fixed:      %016llx\n", cpu, fixed);
 		if (pebs_constraints) {
-			rdmsrq(MSR_IA32_PEBS_ENABLE, pebs);
+			pebs = rdmsrq(MSR_IA32_PEBS_ENABLE);
 			pr_info("CPU#%d: pebs:       %016llx\n", cpu, pebs);
 		}
 		if (x86_pmu.lbr_nr) {
-			rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
+			debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 			pr_info("CPU#%d: debugctl:   %016llx\n", cpu, debugctl);
 		}
 	}
 	pr_info("CPU#%d: active:     %016llx\n", cpu, *(u64 *)cpuc->active_mask);
 
 	for_each_set_bit(idx, cntr_mask, X86_PMC_IDX_MAX) {
-		rdmsrq(x86_pmu_config_addr(idx), pmc_ctrl);
-		rdmsrq(x86_pmu_event_addr(idx), pmc_count);
+		pmc_ctrl = rdmsrq(x86_pmu_config_addr(idx));
+		pmc_count = rdmsrq(x86_pmu_event_addr(idx));
 
 		prev_left = per_cpu(pmc_prev_left[idx], cpu);
 
@@ -1627,7 +1627,7 @@ void perf_event_print_debug(void)
 			cpu, idx, prev_left);
 	}
 	for_each_set_bit(idx, fixed_cntr_mask, X86_PMC_IDX_MAX) {
-		rdmsrq(x86_pmu_fixed_ctr_addr(idx), pmc_count);
+		pmc_count = rdmsrq(x86_pmu_fixed_ctr_addr(idx));
 
 		pr_info("CPU#%d: fixed-PMC%d count: %016llx\n",
 			cpu, idx, pmc_count);
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 27cda71c96ce..47a2abe73221 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2965,7 +2965,7 @@ static inline u64 intel_pmu_get_status(void)
 {
 	u64 status;
 
-	rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status);
+	status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS);
 
 	return status;
 }
@@ -3494,7 +3494,7 @@ static void intel_pmu_enable_event_ext(struct perf_event *event)
 		else
 			new.thresh = ARCH_PEBS_THRESH_SINGLE;
 
-		rdmsrq(MSR_IA32_PEBS_INDEX, old.whole);
+		old.whole = rdmsrq(MSR_IA32_PEBS_INDEX);
 		if (new.thresh != old.thresh || !old.en) {
 			if (old.thresh == ARCH_PEBS_THRESH_MULTI && old.wr > 0) {
 				/*
@@ -6255,8 +6255,7 @@ static void intel_update_pmu_caps(struct pmu *pmu)
 		update_pmu_cap_from_perfmonext(pmu);
 
 	if (is_hybrid() && this_cpu_has(X86_FEATURE_PDCM)) {
-		rdmsrq(MSR_IA32_PERF_CAPABILITIES,
-		       hybrid(pmu, intel_cap).capabilities);
+		hybrid(pmu, intel_cap).capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES);
 
 		/*
 		 * Restore perf_metrics on platforms with broken
@@ -6412,7 +6411,7 @@ static void intel_pmu_cpu_starting(int cpu)
 	if (!is_hybrid() && x86_pmu.intel_cap.perf_metrics) {
 		union perf_capabilities perf_cap;
 
-		rdmsrq(MSR_IA32_PERF_CAPABILITIES, perf_cap.capabilities);
+		perf_cap.capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES);
 		if (!perf_cap.perf_metrics) {
 			x86_pmu.intel_cap.perf_metrics = 0;
 			x86_pmu.intel_ctrl &= ~GLOBAL_CTRL_EN_PERF_METRICS;
@@ -7959,7 +7958,7 @@ __init int intel_pmu_init(void)
 	if (boot_cpu_has(X86_FEATURE_PDCM)) {
 		u64 capabilities;
 
-		rdmsrq(MSR_IA32_PERF_CAPABILITIES, capabilities);
+		capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES);
 		x86_pmu.intel_cap.capabilities = capabilities;
 	}
 
diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index f3d5ee07f8f2..69eb6cf51d3b 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -324,7 +324,7 @@ static inline u64 cstate_pmu_read_counter(struct perf_event *event)
 {
 	u64 val;
 
-	rdmsrq(event->hw.event_base, val);
+	val = rdmsrq(event->hw.event_base);
 	return val;
 }
 
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index e86e4ba91e1b..d332ae04e3cd 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -3231,7 +3231,7 @@ static void intel_pmu_drain_arch_pebs(struct pt_regs *iregs,
 	void *base, *at, *top;
 	u64 mask;
 
-	rdmsrq(MSR_IA32_PEBS_INDEX, index.whole);
+	index.whole = rdmsrq(MSR_IA32_PEBS_INDEX);
 
 	if (unlikely(!index.wr)) {
 		intel_pmu_pebs_event_update_no_drain(cpuc, X86_PMC_IDX_MAX);
diff --git a/arch/x86/events/intel/knc.c b/arch/x86/events/intel/knc.c
index e887adc108ac..c4f81215f758 100644
--- a/arch/x86/events/intel/knc.c
+++ b/arch/x86/events/intel/knc.c
@@ -160,7 +160,7 @@ static void knc_pmu_disable_all(void)
 {
 	u64 val;
 
-	rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val);
+	val = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL);
 	val &= ~(KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1);
 	wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val);
 }
@@ -169,7 +169,7 @@ static void knc_pmu_enable_all(int added)
 {
 	u64 val;
 
-	rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val);
+	val = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL);
 	val |= (KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1);
 	wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val);
 }
@@ -201,7 +201,7 @@ static inline u64 knc_pmu_get_status(void)
 {
 	u64 status;
 
-	rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS, status);
+	status = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS);
 
 	return status;
 }
diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index cbe5c762008d..fc05ec3b9a99 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -141,7 +141,7 @@ static void __intel_pmu_lbr_enable(bool pmi)
 	if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && !pmi && cpuc->lbr_sel)
 		wrmsrq(MSR_LBR_SELECT, lbr_select);
 
-	rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
+	debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 	orig_debugctl = debugctl;
 
 	if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR))
@@ -211,7 +211,7 @@ static inline u64 intel_pmu_lbr_tos(void)
 {
 	u64 tos;
 
-	rdmsrq(x86_pmu.lbr_tos, tos);
+	tos = rdmsrq(x86_pmu.lbr_tos);
 	return tos;
 }
 
@@ -304,7 +304,7 @@ static __always_inline u64 rdlbr_from(unsigned int idx, struct lbr_entry *lbr)
 	if (lbr)
 		return lbr->from;
 
-	rdmsrq(x86_pmu.lbr_from + idx, val);
+	val = rdmsrq(x86_pmu.lbr_from + idx);
 
 	return lbr_from_signext_quirk_rd(val);
 }
@@ -316,7 +316,7 @@ static __always_inline u64 rdlbr_to(unsigned int idx, struct lbr_entry *lbr)
 	if (lbr)
 		return lbr->to;
 
-	rdmsrq(x86_pmu.lbr_to + idx, val);
+	val = rdmsrq(x86_pmu.lbr_to + idx);
 
 	return val;
 }
@@ -328,7 +328,7 @@ static __always_inline u64 rdlbr_info(unsigned int idx, struct lbr_entry *lbr)
 	if (lbr)
 		return lbr->info;
 
-	rdmsrq(x86_pmu.lbr_info + idx, val);
+	val = rdmsrq(x86_pmu.lbr_info + idx);
 
 	return val;
 }
@@ -477,7 +477,7 @@ void intel_pmu_lbr_save(void *ctx)
 	task_ctx->tos = tos;
 
 	if (cpuc->lbr_select)
-		rdmsrq(MSR_LBR_SELECT, task_ctx->lbr_sel);
+		task_ctx->lbr_sel = rdmsrq(MSR_LBR_SELECT);
 }
 
 static void intel_pmu_arch_lbr_save(void *ctx)
@@ -754,7 +754,7 @@ void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc)
 			u64     lbr;
 		} msr_lastbranch;
 
-		rdmsrq(x86_pmu.lbr_from + lbr_idx, msr_lastbranch.lbr);
+		msr_lastbranch.lbr = rdmsrq(x86_pmu.lbr_from + lbr_idx);
 
 		perf_clear_branch_entry_bitfields(br);
 
diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c
index 5368dc31787c..e675e85682f1 100644
--- a/arch/x86/events/intel/p4.c
+++ b/arch/x86/events/intel/p4.c
@@ -860,7 +860,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc)
 	u64 v;
 
 	/* an official way for overflow indication */
-	rdmsrq(hwc->config_base, v);
+	v = rdmsrq(hwc->config_base);
 	if (v & P4_CCCR_OVF) {
 		wrmsrq(hwc->config_base, v & ~P4_CCCR_OVF);
 		return 1;
@@ -873,7 +873,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc)
 	 * the counter has reached zero value and continued counting before
 	 * real NMI signal was received:
 	 */
-	rdmsrq(hwc->event_base, v);
+	v = rdmsrq(hwc->event_base);
 	if (!(v & ARCH_P4_UNFLAGGED_BIT))
 		return 1;
 
@@ -1373,7 +1373,7 @@ __init int p4_pmu_init(void)
 	/* If we get stripped -- indexing fails */
 	BUILD_BUG_ON(ARCH_P4_MAX_CCCR > INTEL_PMC_MAX_GENERIC);
 
-	rdmsrq(MSR_IA32_MISC_ENABLE, misc);
+	misc = rdmsrq(MSR_IA32_MISC_ENABLE);
 	if (!(misc & MSR_IA32_MISC_ENABLE_EMON)) {
 		pr_cont("unsupported Netburst CPU model %d ",
 			boot_cpu_data.x86_model);
diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c
index fb991e0ac614..4268b576b5d8 100644
--- a/arch/x86/events/intel/p6.c
+++ b/arch/x86/events/intel/p6.c
@@ -143,7 +143,7 @@ static void p6_pmu_disable_all(void)
 	u64 val;
 
 	/* p6 only has one enable register */
-	rdmsrq(MSR_P6_EVNTSEL0, val);
+	val = rdmsrq(MSR_P6_EVNTSEL0);
 	val &= ~ARCH_PERFMON_EVENTSEL_ENABLE;
 	wrmsrq(MSR_P6_EVNTSEL0, val);
 }
@@ -153,7 +153,7 @@ static void p6_pmu_enable_all(int added)
 	unsigned long val;
 
 	/* p6 only has one enable register */
-	rdmsrq(MSR_P6_EVNTSEL0, val);
+	val = rdmsrq(MSR_P6_EVNTSEL0);
 	val |= ARCH_PERFMON_EVENTSEL_ENABLE;
 	wrmsrq(MSR_P6_EVNTSEL0, val);
 }
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 5754cd405562..d595d69b49a1 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -196,7 +196,7 @@ static int __init pt_pmu_hw_init(void)
 	int ret;
 	long i;
 
-	rdmsrq(MSR_PLATFORM_INFO, reg);
+	reg = rdmsrq(MSR_PLATFORM_INFO);
 	pt_pmu.max_nonturbo_ratio = (reg & 0xff00) >> 8;
 
 	/*
@@ -232,7 +232,7 @@ static int __init pt_pmu_hw_init(void)
 		 * "IA32_VMX_MISC[bit 14]" being 1 means PT can trace
 		 * post-VMXON.
 		 */
-		rdmsrq(MSR_IA32_VMX_MISC, reg);
+		reg = rdmsrq(MSR_IA32_VMX_MISC);
 		if (reg & BIT(14))
 			pt_pmu.vmx = true;
 	}
@@ -935,7 +935,7 @@ static void pt_handle_status(struct pt *pt)
 	int advance = 0;
 	u64 status;
 
-	rdmsrq(MSR_IA32_RTIT_STATUS, status);
+	status = rdmsrq(MSR_IA32_RTIT_STATUS);
 
 	if (status & RTIT_STATUS_ERROR) {
 		pr_err_ratelimited("ToPA ERROR encountered, trying to recover\n");
@@ -994,12 +994,12 @@ static void pt_read_offset(struct pt_buffer *buf)
 	struct topa_page *tp;
 
 	if (!buf->single) {
-		rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, pt->output_base);
+		pt->output_base = rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE);
 		tp = phys_to_virt(pt->output_base);
 		buf->cur = &tp->topa;
 	}
 
-	rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, pt->output_mask);
+	pt->output_mask = rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK);
 	/* offset within current output region */
 	buf->output_off = pt->output_mask >> 32;
 	/* index of current output region within this table */
@@ -1623,7 +1623,7 @@ static void pt_event_start(struct perf_event *event, int mode)
 			 * PMI might have just cleared these, so resume_allowed
 			 * must be checked again also.
 			 */
-			rdmsrq(MSR_IA32_RTIT_STATUS, status);
+			status = rdmsrq(MSR_IA32_RTIT_STATUS);
 			if (!(status & (RTIT_STATUS_TRIGGEREN |
 					RTIT_STATUS_ERROR |
 					RTIT_STATUS_STOPPED)) &&
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 9f8a80c9dcb6..cd85a5d28e42 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -171,7 +171,7 @@ u64 uncore_msr_read_counter(struct intel_uncore_box *box, struct perf_event *eve
 {
 	u64 count;
 
-	rdmsrq(event->hw.event_base, count);
+	count = rdmsrq(event->hw.event_base);
 
 	return count;
 }
diff --git a/arch/x86/events/intel/uncore_nhmex.c b/arch/x86/events/intel/uncore_nhmex.c
index 7a6855281102..81e838e6f729 100644
--- a/arch/x86/events/intel/uncore_nhmex.c
+++ b/arch/x86/events/intel/uncore_nhmex.c
@@ -216,7 +216,7 @@ static void nhmex_uncore_msr_disable_box(struct intel_uncore_box *box)
 	u64 config;
 
 	if (msr) {
-		rdmsrq(msr, config);
+		config = rdmsrq(msr);
 		config &= ~((1ULL << uncore_num_counters(box)) - 1);
 		/* WBox has a fixed counter */
 		if (uncore_msr_fixed_ctl(box))
@@ -231,7 +231,7 @@ static void nhmex_uncore_msr_enable_box(struct intel_uncore_box *box)
 	u64 config;
 
 	if (msr) {
-		rdmsrq(msr, config);
+		config = rdmsrq(msr);
 		config |= (1ULL << uncore_num_counters(box)) - 1;
 		/* WBox has a fixed counter */
 		if (uncore_msr_fixed_ctl(box))
diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c
index 055131c508ff..da864724ff20 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -533,7 +533,7 @@ static int icl_get_cbox_num(void)
 {
 	u64 num_boxes;
 
-	rdmsrq(ICL_UNC_CBO_CONFIG, num_boxes);
+	num_boxes = rdmsrq(ICL_UNC_CBO_CONFIG);
 
 	return num_boxes & ICL_UNC_NUM_CBO_MASK;
 }
diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c
index a97cd029db36..490725c8fee1 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -642,7 +642,7 @@ static void snbep_uncore_msr_disable_box(struct intel_uncore_box *box)
 
 	msr = uncore_msr_box_ctl(box);
 	if (msr) {
-		rdmsrq(msr, config);
+		config = rdmsrq(msr);
 		config |= SNBEP_PMON_BOX_CTL_FRZ;
 		wrmsrq(msr, config);
 	}
@@ -655,7 +655,7 @@ static void snbep_uncore_msr_enable_box(struct intel_uncore_box *box)
 
 	msr = uncore_msr_box_ctl(box);
 	if (msr) {
-		rdmsrq(msr, config);
+		config = rdmsrq(msr);
 		config &= ~SNBEP_PMON_BOX_CTL_FRZ;
 		wrmsrq(msr, config);
 	}
@@ -6370,7 +6370,7 @@ void spr_uncore_cpu_init(void)
 		 * of UNCORE_SPR_CHA) is incorrect on some SPR variants because of a
 		 * firmware bug. Using the value from SPR_MSR_UNC_CBO_CONFIG to replace it.
 		 */
-		rdmsrq(SPR_MSR_UNC_CBO_CONFIG, num_cbo);
+		num_cbo = rdmsrq(SPR_MSR_UNC_CBO_CONFIG);
 		/*
 		 * The MSR doesn't work on the EMR XCC, but the firmware bug doesn't impact
 		 * the EMR XCC. Don't let the value from the MSR replace the existing value.
diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c
index 76d6418c5055..0e59781549ca 100644
--- a/arch/x86/events/msr.c
+++ b/arch/x86/events/msr.c
@@ -158,7 +158,7 @@ static inline u64 msr_read_counter(struct perf_event *event)
 	u64 now;
 
 	if (event->hw.event_base)
-		rdmsrq(event->hw.event_base, now);
+		now = rdmsrq(event->hw.event_base);
 	else
 		now = rdtsc_ordered();
 
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index 71ed5b2acea2..4abdb9475e8f 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -1475,11 +1475,11 @@ static __always_inline void __amd_pmu_lbr_disable(void)
 {
 	u64 dbg_ctl, dbg_extn_cfg;
 
-	rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg);
+	dbg_extn_cfg = rdmsrq(MSR_AMD_DBG_EXTN_CFG);
 	wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg & ~DBG_EXTN_CFG_LBRV2EN);
 
 	if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
-		rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
+		dbg_ctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl & ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
 	}
 }
@@ -1633,7 +1633,7 @@ static __always_inline void __intel_pmu_lbr_disable(void)
 {
 	u64 debugctl;
 
-	rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
+	debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 	debugctl &= ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
 	wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
 }
diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index 8ed03c32f560..180cc18282ca 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -193,7 +193,7 @@ static inline unsigned int get_rapl_pmu_idx(int cpu, int scope)
 static inline u64 rapl_read_counter(struct perf_event *event)
 {
 	u64 raw;
-	rdmsrq(event->hw.event_base, raw);
+	raw = rdmsrq(event->hw.event_base);
 	return raw;
 }
 
@@ -222,7 +222,7 @@ static u64 rapl_event_update(struct perf_event *event)
 
 	prev_raw_count = local64_read(&hwc->prev_count);
 	do {
-		rdmsrq(event->hw.event_base, new_raw_count);
+		new_raw_count = rdmsrq(event->hw.event_base);
 	} while (!local64_try_cmpxchg(&hwc->prev_count,
 				      &prev_raw_count, new_raw_count));
 
diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/core.c
index e506f677db57..1980e5995e27 100644
--- a/arch/x86/events/zhaoxin/core.c
+++ b/arch/x86/events/zhaoxin/core.c
@@ -268,7 +268,7 @@ static inline u64 zhaoxin_pmu_get_status(void)
 {
 	u64 status;
 
-	rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status);
+	status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS);
 
 	return status;
 }
@@ -295,7 +295,7 @@ static void zhaoxin_pmu_disable_fixed(struct hw_perf_event *hwc)
 
 	mask = 0xfULL << (idx * 4);
 
-	rdmsrq(hwc->config_base, ctrl_val);
+	ctrl_val = rdmsrq(hwc->config_base);
 	ctrl_val &= ~mask;
 	wrmsrq(hwc->config_base, ctrl_val);
 }
@@ -331,7 +331,7 @@ static void zhaoxin_pmu_enable_fixed(struct hw_perf_event *hwc)
 	bits <<= (idx * 4);
 	mask = 0xfULL << (idx * 4);
 
-	rdmsrq(hwc->config_base, ctrl_val);
+	ctrl_val = rdmsrq(hwc->config_base);
 	ctrl_val &= ~mask;
 	ctrl_val |= bits;
 	wrmsrq(hwc->config_base, ctrl_val);
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 95f1782d1e17..4e30f9a11bc4 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -38,7 +38,7 @@ static u64 hv_apic_icr_read(void)
 {
 	u64 reg_val;
 
-	rdmsrq(HV_X64_MSR_ICR, reg_val);
+	reg_val = rdmsrq(HV_X64_MSR_ICR);
 	return reg_val;
 }
 
@@ -64,10 +64,10 @@ static u32 hv_apic_read(u32 reg)
 
 	switch (reg) {
 	case APIC_EOI:
-		rdmsrq(HV_X64_MSR_EOI, reg_val.q);
+		reg_val.q = rdmsrq(HV_X64_MSR_EOI);
 		return reg_val.l;
 	case APIC_TASKPRI:
-		rdmsrq(HV_X64_MSR_TPR, reg_val.q);
+		reg_val.q = rdmsrq(HV_X64_MSR_TPR);
 		return reg_val.l;
 
 	default:
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 55a8b6de2865..bc8f91114868 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -101,7 +101,7 @@ static int hyperv_init_ghcb(void)
 	 * returned by MSR_AMD64_SEV_ES_GHCB is above shared
 	 * memory boundary and map it here.
 	 */
-	rdmsrq(MSR_AMD64_SEV_ES_GHCB, ghcb_gpa);
+	ghcb_gpa = rdmsrq(MSR_AMD64_SEV_ES_GHCB);
 
 	/* Mask out vTOM bit and map as decrypted */
 	ghcb_gpa &= ~ms_hyperv.shared_gpa_boundary;
@@ -134,7 +134,7 @@ static int hv_cpu_init(unsigned int cpu)
 		 * For root partition we get the hypervisor provided VP assist
 		 * page, instead of allocating a new page.
 		 */
-		rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
+		msr.as_uint64 = rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE);
 		*hvp = memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT,
 				PAGE_SIZE, MEMREMAP_WB);
 	} else {
@@ -183,7 +183,7 @@ static void hv_reenlightenment_notify(struct work_struct *dummy)
 {
 	struct hv_tsc_emulation_status emu_status;
 
-	rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status);
+	*(u64 *)&emu_status = rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS);
 
 	/* Don't issue the callback if TSC accesses are not emulated */
 	if (hv_reenlightenment_cb && emu_status.inprogress)
@@ -196,11 +196,11 @@ void hyperv_stop_tsc_emulation(void)
 	u64 freq;
 	struct hv_tsc_emulation_status emu_status;
 
-	rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status);
+	*(u64 *)&emu_status = rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS);
 	emu_status.inprogress = 0;
 	wrmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status);
 
-	rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq);
+	freq = rdmsrq(HV_X64_MSR_TSC_FREQUENCY);
 	tsc_khz = div64_u64(freq, 1000);
 }
 EXPORT_SYMBOL_GPL(hyperv_stop_tsc_emulation);
@@ -260,7 +260,7 @@ void clear_hv_tscchange_cb(void)
 	if (!hv_reenlightenment_available())
 		return;
 
-	rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl);
+	*(u64 *)&re_ctrl = rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL);
 	re_ctrl.enabled = 0;
 	wrmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl);
 
@@ -297,7 +297,7 @@ static int hv_cpu_die(unsigned int cpu)
 			 */
 			memunmap(hv_vp_assist_page[cpu]);
 			hv_vp_assist_page[cpu] = NULL;
-			rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
+			msr.as_uint64 = rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE);
 			msr.enable = 0;
 		}
 		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
@@ -306,7 +306,7 @@ static int hv_cpu_die(unsigned int cpu)
 	if (hv_reenlightenment_cb == NULL)
 		return 0;
 
-	rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
+	*((u64 *)&re_ctrl) = rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL);
 	if (re_ctrl.target_vp == hv_vp_index[cpu]) {
 		/*
 		 * Reassign reenlightenment notifications to some other online
@@ -377,7 +377,7 @@ static int hv_suspend(void *data)
 	hv_set_hypercall_pg(NULL);
 
 	/* Disable the hypercall page in the hypervisor */
-	rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+	hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL);
 	hypercall_msr.enable = 0;
 	wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 
@@ -394,7 +394,7 @@ static void hv_resume(void *data)
 	WARN_ON(ret);
 
 	/* Re-enable the hypercall page */
-	rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+	hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL);
 	hypercall_msr.enable = 1;
 	hypercall_msr.guest_physical_address =
 		vmalloc_to_pfn(hv_hypercall_pg_saved);
@@ -529,7 +529,7 @@ void __init hyperv_init(void)
 	if (hv_hypercall_pg == NULL)
 		goto clean_guest_os_id;
 
-	rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+	hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL);
 	hypercall_msr.enable = 1;
 
 	if (hv_root_partition()) {
@@ -671,7 +671,7 @@ void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die)
 		return;
 	panic_reported = true;
 
-	rdmsrq(HV_X64_MSR_GUEST_OS_ID, guest_id);
+	guest_id = rdmsrq(HV_X64_MSR_GUEST_OS_ID);
 
 	wrmsrq(HV_X64_MSR_CRASH_P0, err);
 	wrmsrq(HV_X64_MSR_CRASH_P1, guest_id);
@@ -705,7 +705,7 @@ bool hv_is_hyperv_initialized(void)
 	 * that the hypercall page is setup
 	 */
 	hypercall_msr.as_uint64 = 0;
-	rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+	hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL);
 
 	return hypercall_msr.enable;
 }
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 6b4bdea18218..7ef2d794e2e8 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -50,7 +50,7 @@ static void hv_qlock_wait(u8 *byte, u8 val)
 	if (READ_ONCE(*byte) == val) {
 		unsigned long msr_val;
 
-		rdmsrq(HV_X64_MSR_GUEST_IDLE, msr_val);
+		msr_val = rdmsrq(HV_X64_MSR_GUEST_IDLE);
 
 		(void)msr_val;
 	}
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 9cd493d467d4..e028140fac49 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -220,7 +220,7 @@ static inline u32 native_apic_msr_read(u32 reg)
 	if (reg == APIC_DFR)
 		return -1;
 
-	rdmsrq(APIC_BASE_MSR + (reg >> 4), msr);
+	msr = rdmsrq(APIC_BASE_MSR + (reg >> 4));
 	return (u32)msr;
 }
 
@@ -233,7 +233,7 @@ static inline u64 native_x2apic_icr_read(void)
 {
 	unsigned long val;
 
-	rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4), val);
+	val = rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4));
 	return val;
 }
 
diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h
index 854d82b88ff4..60a3df32a4d3 100644
--- a/arch/x86/include/asm/debugreg.h
+++ b/arch/x86/include/asm/debugreg.h
@@ -180,7 +180,7 @@ static inline unsigned long get_debugctlmsr(void)
 	if (boot_cpu_data.x86 < 6)
 		return 0;
 #endif
-	rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctlmsr);
+	debugctlmsr = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 
 	return debugctlmsr;
 }
diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h
index 70ff4ef457b1..9de49d732e9e 100644
--- a/arch/x86/include/asm/fsgsbase.h
+++ b/arch/x86/include/asm/fsgsbase.h
@@ -60,7 +60,7 @@ static inline unsigned long x86_fsbase_read_cpu(void)
 	if (boot_cpu_has(X86_FEATURE_FSGSBASE))
 		fsbase = rdfsbase();
 	else
-		rdmsrq(MSR_FS_BASE, fsbase);
+		fsbase = rdmsrq(MSR_FS_BASE);
 
 	return fsbase;
 }
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 6db5b5f79df9..2097602a00a0 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -2417,7 +2417,7 @@ static inline unsigned long read_msr(unsigned long msr)
 {
 	u64 value;
 
-	rdmsrq(msr, value);
+	value = rdmsrq(msr);
 	return value;
 }
 #endif
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 6d7bab33af71..95761803c2e6 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -173,14 +173,13 @@ static inline u64 native_read_pmc(int counter)
 #include <asm/paravirt.h>
 #else
 #include <linux/errno.h>
-/*
- * Access to machine-specific registers (available on 586 and better only)
- * Note: the rd* operations modify the parameters directly (without using
- * pointer indirection), this allows gcc to optimize better
- */
 
-#define rdmsrq(msr, val)			\
-	((val) = native_read_msr((msr)))
+/* Access to machine-specific registers (available on 586 and better only) */
+
+static __always_inline u64 rdmsrq(u32 msr)
+{
+	return native_read_msr(msr);
+}
 
 static inline void wrmsrq(u32 msr, u64 val)
 {
@@ -237,7 +236,7 @@ int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8]);
 #else  /*  CONFIG_SMP  */
 static inline int rdmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 *q)
 {
-	rdmsrq(msr_no, *q);
+	*q = rdmsrq(msr_no);
 	return 0;
 }
 static inline int wrmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 q)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 93754aa60d5e..19442bc3af37 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -150,10 +150,10 @@ static inline int paravirt_write_msr_safe(u32 msr, u64 val)
 	return PVOP_CALL2(int, pv_ops, cpu.write_msr_safe, msr, val);
 }
 
-#define rdmsrq(msr, val)			\
-do {						\
-	val = paravirt_read_msr(msr);		\
-} while (0)
+static __always_inline u64 rdmsrq(u32 msr)
+{
+	return paravirt_read_msr(msr);
+}
 
 static inline void wrmsrq(u32 msr, u64 val)
 {
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 90025451ace2..7a6c77e6a44e 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1193,7 +1193,7 @@ void disable_local_APIC(void)
 	if (enabled_via_apicbase) {
 		struct msr val;
 
-		rdmsrq(MSR_IA32_APICBASE, val.q);
+		val.q = rdmsrq(MSR_IA32_APICBASE);
 		val.l &= ~MSR_IA32_APICBASE_ENABLE;
 		wrmsrq(MSR_IA32_APICBASE, val.q);
 	}
@@ -1710,7 +1710,7 @@ static bool x2apic_hw_locked(void)
 
 	x86_arch_cap_msr = x86_read_arch_cap_msr();
 	if (x86_arch_cap_msr & ARCH_CAP_XAPIC_DISABLE) {
-		rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS, msr);
+		msr = rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS);
 		return (msr & LEGACY_XAPIC_DISABLED);
 	}
 	return false;
@@ -1723,7 +1723,7 @@ static void __x2apic_disable(void)
 	if (!boot_cpu_has(X86_FEATURE_APIC))
 		return;
 
-	rdmsrq(MSR_IA32_APICBASE, msr);
+	msr = rdmsrq(MSR_IA32_APICBASE);
 	if (!(msr & X2APIC_ENABLE))
 		return;
 	/* Disable xapic and x2apic first and then reenable xapic mode */
@@ -1736,7 +1736,7 @@ static void __x2apic_enable(void)
 {
 	u64 msr;
 
-	rdmsrq(MSR_IA32_APICBASE, msr);
+	msr = rdmsrq(MSR_IA32_APICBASE);
 	if (msr & X2APIC_ENABLE)
 		return;
 	wrmsrq(MSR_IA32_APICBASE, msr | X2APIC_ENABLE);
@@ -1976,7 +1976,7 @@ static bool __init apic_verify(unsigned long addr)
 
 	/* The BIOS may have set up the APIC at some other address */
 	if (boot_cpu_data.x86 >= 6) {
-		rdmsrq(MSR_IA32_APICBASE, val.q);
+		val.q = rdmsrq(MSR_IA32_APICBASE);
 		if (val.l & MSR_IA32_APICBASE_ENABLE)
 			addr = val.l & MSR_IA32_APICBASE_BASE;
 	}
@@ -1999,7 +1999,7 @@ bool __init apic_force_enable(unsigned long addr)
 	 * and AMD K7 (Model > 1) or later.
 	 */
 	if (boot_cpu_data.x86 >= 6) {
-		rdmsrq(MSR_IA32_APICBASE, val.q);
+		val.q = rdmsrq(MSR_IA32_APICBASE);
 		if (!(val.l & MSR_IA32_APICBASE_ENABLE)) {
 			pr_info("Local APIC disabled by BIOS -- reenabling.\n");
 			val.l &= ~MSR_IA32_APICBASE_BASE;
@@ -2476,7 +2476,7 @@ static void lapic_resume(void *data)
 		 * SMP! We'll need to do this as part of the CPU restore!
 		 */
 		if (boot_cpu_data.x86 >= 6) {
-			rdmsrq(MSR_IA32_APICBASE, val.q);
+			val.q = rdmsrq(MSR_IA32_APICBASE);
 			val.l &= ~MSR_IA32_APICBASE_BASE;
 			val.l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
 			wrmsrq(MSR_IA32_APICBASE, val.q);
diff --git a/arch/x86/kernel/apic/apic_numachip.c b/arch/x86/kernel/apic/apic_numachip.c
index a60c8960bbfd..3af93e3f2179 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -32,7 +32,7 @@ static u32 numachip1_get_apic_id(u32 x)
 	unsigned int id = (x >> 24) & 0xff;
 
 	if (cpu_feature_enabled(X86_FEATURE_NODEID_MSR)) {
-		rdmsrq(MSR_FAM10H_NODE_ID, value);
+		value = rdmsrq(MSR_FAM10H_NODE_ID);
 		id |= (value << 2) & 0xff00;
 	}
 
@@ -43,7 +43,7 @@ static u32 numachip2_get_apic_id(u32 x)
 {
 	u64 mcfg;
 
-	rdmsrq(MSR_FAM10H_MMIO_CONF_BASE, mcfg);
+	mcfg = rdmsrq(MSR_FAM10H_MMIO_CONF_BASE);
 	return ((mcfg >> (28 - 8)) & 0xfff00) | (x >> 24);
 }
 
@@ -151,7 +151,7 @@ static void fixup_cpu_id(struct cpuinfo_x86 *c, int node)
 
 	/* Account for nodes per socket in multi-core-module processors */
 	if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) {
-		rdmsrq(MSR_FAM10H_NODE_ID, val);
+		val = rdmsrq(MSR_FAM10H_NODE_ID);
 		nodes = ((val >> 3) & 7) + 1;
 	}
 
diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c
index 99444409c026..3efceee443b7 100644
--- a/arch/x86/kernel/cet.c
+++ b/arch/x86/kernel/cet.c
@@ -56,7 +56,7 @@ static void do_user_cp_fault(struct pt_regs *regs, unsigned long error_code)
 	 * will be whatever is live in userspace. So read the SSP before enabling
 	 * interrupts so locking the fpregs to do it later is not required.
 	 */
-	rdmsrq(MSR_IA32_PL3_SSP, ssp);
+	ssp = rdmsrq(MSR_IA32_PL3_SSP);
 
 	cond_local_irq_enable(regs);
 
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 54e14ed276b5..4bd43e899c64 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -160,7 +160,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)
 		if (mbytes > 508)
 			mbytes = 508;
 
-		rdmsrq(MSR_K6_WHCR, val.q);
+		val.q = rdmsrq(MSR_K6_WHCR);
 		if ((val.l & 0x0000FFFF) == 0) {
 			unsigned long flags;
 			val.l = (1 << 0) | ((mbytes / 4) << 1);
@@ -181,7 +181,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c)
 		if (mbytes > 4092)
 			mbytes = 4092;
 
-		rdmsrq(MSR_K6_WHCR, val.q);
+		val.q = rdmsrq(MSR_K6_WHCR);
 		if ((val.l & 0xFFFF0000) == 0) {
 			unsigned long flags;
 			val.l = ((mbytes >> 2) << 22) | (1 << 16);
@@ -228,7 +228,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c)
 	 * As per AMD technical note 27212 0.2
 	 */
 	if ((c->x86_model == 8 && c->x86_stepping >= 1) || (c->x86_model > 8)) {
-		rdmsrq(MSR_K7_CLK_CTL, val.q);
+		val.q = rdmsrq(MSR_K7_CLK_CTL);
 		if ((val.l & 0xfff00000) != 0x20000000) {
 			pr_info("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n",
 				val.l, ((val.l & 0x000fffff) | 0x20000000));
@@ -429,7 +429,7 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
 		    (c->x86 == 0x10 && c->x86_model >= 0x2)) {
 			u64 val;
 
-			rdmsrq(MSR_K7_HWCR, val);
+			val = rdmsrq(MSR_K7_HWCR);
 			if (!(val & BIT(24)))
 				pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n");
 		}
@@ -583,7 +583,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
 	 */
 	if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) {
 		/* Check if memory encryption is enabled */
-		rdmsrq(MSR_AMD64_SYSCFG, msr);
+		msr = rdmsrq(MSR_AMD64_SYSCFG);
 		if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT))
 			goto clear_all;
 
@@ -600,7 +600,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
 		if (!sme_me_mask)
 			setup_clear_cpu_cap(X86_FEATURE_SME);
 
-		rdmsrq(MSR_K7_HWCR, msr);
+		msr = rdmsrq(MSR_K7_HWCR);
 		if (!(msr & MSR_K7_HWCR_SMMLOCK))
 			goto clear_sev;
 
@@ -1111,7 +1111,7 @@ static void init_amd(struct cpuinfo_x86 *c)
 	init_amd_cacheinfo(c);
 
 	if (cpu_has(c, X86_FEATURE_SVM)) {
-		rdmsrq(MSR_VM_CR, vm_cr);
+		vm_cr = rdmsrq(MSR_VM_CR);
 		if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) {
 			pr_notice_once("SVM disabled (by BIOS) in MSR_VM_CR\n");
 			clear_cpu_cap(c, X86_FEATURE_SVM);
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index 7ffc78d5ebf2..492dc9a11d6b 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -41,8 +41,8 @@ static void init_counter_refs(void *data)
 {
 	u64 aperf, mperf;
 
-	rdmsrq(MSR_IA32_APERF, aperf);
-	rdmsrq(MSR_IA32_MPERF, mperf);
+	aperf = rdmsrq(MSR_IA32_APERF);
+	mperf = rdmsrq(MSR_IA32_MPERF);
 
 	this_cpu_write(cpu_samples.aperf, aperf);
 	this_cpu_write(cpu_samples.mperf, mperf);
@@ -479,8 +479,8 @@ void arch_scale_freq_tick(void)
 	if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF))
 		return;
 
-	rdmsrq(MSR_IA32_APERF, aperf);
-	rdmsrq(MSR_IA32_MPERF, mperf);
+	aperf = rdmsrq(MSR_IA32_APERF);
+	mperf = rdmsrq(MSR_IA32_MPERF);
 	acnt = aperf - s->aperf;
 	mcnt = mperf - s->mperf;
 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 56eac5611c31..aeb4770ba73c 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -761,7 +761,7 @@ void update_srbds_msr(void)
 	if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL))
 		return;
 
-	rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+	mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL);
 
 	switch (srbds_mitigation) {
 	case SRBDS_MITIGATION_OFF:
@@ -897,7 +897,7 @@ void update_gds_msr(void)
 
 	switch (gds_mitigation) {
 	case GDS_MITIGATION_OFF:
-		rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+		mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL);
 		mcu_ctrl |= GDS_MITG_DIS;
 		break;
 	case GDS_MITIGATION_FULL_LOCKED:
@@ -907,7 +907,7 @@ void update_gds_msr(void)
 		 * CPUs.
 		 */
 	case GDS_MITIGATION_FULL:
-		rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+		mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL);
 		mcu_ctrl &= ~GDS_MITG_DIS;
 		break;
 	case GDS_MITIGATION_FORCE:
@@ -924,7 +924,7 @@ void update_gds_msr(void)
 	 * GDS_MITG_DIS will be ignored if this processor is locked but the boot
 	 * processor was not.
 	 */
-	rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl_after);
+	mcu_ctrl_after = rdmsrq(MSR_IA32_MCU_OPT_CTRL);
 	WARN_ON_ONCE(mcu_ctrl != mcu_ctrl_after);
 }
 
@@ -959,7 +959,7 @@ static void __init gds_select_mitigation(void)
 	if (gds_mitigation == GDS_MITIGATION_FORCE)
 		gds_mitigation = GDS_MITIGATION_FULL;
 
-	rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+	mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL);
 	if (mcu_ctrl & GDS_MITG_LOCKED) {
 		if (gds_mitigation == GDS_MITIGATION_OFF)
 			pr_warn("Mitigation locked. Disable failed.\n");
@@ -3274,7 +3274,7 @@ void __init cpu_select_mitigations(void)
 	 * init code as it is not enumerated and depends on the family.
 	 */
 	if (cpu_feature_enabled(X86_FEATURE_MSR_SPEC_CTRL)) {
-		rdmsrq(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+		x86_spec_ctrl_base = rdmsrq(MSR_IA32_SPEC_CTRL);
 
 		/*
 		 * Previously running kernel (kexec), may have some controls
diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c
index bba28607a59a..c9074c368146 100644
--- a/arch/x86/kernel/cpu/bus_lock.c
+++ b/arch/x86/kernel/cpu/bus_lock.c
@@ -105,7 +105,7 @@ static bool split_lock_verify_msr(bool on)
 		ctrl &= ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT;
 	if (wrmsrq_safe(MSR_TEST_CTRL, ctrl))
 		return false;
-	rdmsrq(MSR_TEST_CTRL, tmp);
+	tmp = rdmsrq(MSR_TEST_CTRL);
 	return ctrl == tmp;
 }
 
@@ -145,7 +145,7 @@ static void __init __split_lock_setup(void)
 		return;
 	}
 
-	rdmsrq(MSR_TEST_CTRL, msr_test_ctrl_cache);
+	msr_test_ctrl_cache = rdmsrq(MSR_TEST_CTRL);
 
 	if (!split_lock_verify_msr(true)) {
 		pr_info("MSR access failed: Disabled\n");
@@ -305,7 +305,7 @@ void bus_lock_init(void)
 	if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
 		return;
 
-	rdmsrq(MSR_IA32_DEBUGCTLMSR, val);
+	val = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 
 	if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) &&
 	    (sld_state == sld_warn || sld_state == sld_fatal)) ||
@@ -383,7 +383,7 @@ static void __init split_lock_setup(struct cpuinfo_x86 *c)
 	 * MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT is.  All CPUs that set
 	 * it have split lock detection.
 	 */
-	rdmsrq(MSR_IA32_CORE_CAPS, ia32_core_caps);
+	ia32_core_caps = rdmsrq(MSR_IA32_CORE_CAPS);
 	if (ia32_core_caps & MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT)
 		goto supported;
 
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 513fa1f640f9..6cd89b5ac9de 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -30,7 +30,7 @@ static void init_c3(struct cpuinfo_x86 *c)
 
 		/* enable ACE unit, if present and disabled */
 		if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) {
-			rdmsrq(MSR_VIA_FCR, msr);
+			msr = rdmsrq(MSR_VIA_FCR);
 			/* enable ACE unit */
 			wrmsrq(MSR_VIA_FCR, msr | ACE_FCR);
 			pr_info("CPU: Enabled ACE h/w crypto\n");
@@ -38,7 +38,7 @@ static void init_c3(struct cpuinfo_x86 *c)
 
 		/* enable RNG unit, if present and disabled */
 		if ((tmp & (RNG_PRESENT | RNG_ENABLED)) == RNG_PRESENT) {
-			rdmsrq(MSR_VIA_RNG, msr);
+			msr = rdmsrq(MSR_VIA_RNG);
 			/* enable RNG unit */
 			wrmsrq(MSR_VIA_RNG, msr | RNG_ENABLE);
 			pr_info("CPU: Enabled h/w RNG\n");
@@ -52,7 +52,7 @@ static void init_c3(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_32
 	/* Cyrix III family needs CX8 & PGE explicitly enabled. */
 	if (c->x86_model >= 6 && c->x86_model <= 13) {
-		rdmsrq(MSR_VIA_FCR, msr);
+		msr = rdmsrq(MSR_VIA_FCR);
 		wrmsrq(MSR_VIA_FCR, msr | (1 << 1 | 1 << 7));
 		set_cpu_cap(c, X86_FEATURE_CX8);
 	}
@@ -169,7 +169,7 @@ static void init_centaur(struct cpuinfo_x86 *c)
 			name = "??";
 		}
 
-		rdmsrq(MSR_IDT_FCR1, val.q);
+		val.q = rdmsrq(MSR_IDT_FCR1);
 		newlo = (val.l | fcr_set) & (~fcr_clr);
 
 		if (newlo != val.l) {
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c7352827f491..b2d9f8b14909 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -346,7 +346,7 @@ static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
 
 	/* Disable processor serial number: */
 
-	rdmsrq(MSR_IA32_BBL_CR_CTL, val.q);
+	val.q = rdmsrq(MSR_IA32_BBL_CR_CTL);
 	val.l |= 0x200000;
 	wrmsrq(MSR_IA32_BBL_CR_CTL, val.q);
 
@@ -610,7 +610,7 @@ __noendbr u64 ibt_save(bool disable)
 	u64 msr = 0;
 
 	if (cpu_feature_enabled(X86_FEATURE_IBT)) {
-		rdmsrq(MSR_IA32_S_CET, msr);
+		msr = rdmsrq(MSR_IA32_S_CET);
 		if (disable)
 			wrmsrq(MSR_IA32_S_CET, msr & ~CET_ENDBR_EN);
 	}
@@ -623,7 +623,7 @@ __noendbr void ibt_restore(u64 save)
 	u64 msr;
 
 	if (cpu_feature_enabled(X86_FEATURE_IBT)) {
-		rdmsrq(MSR_IA32_S_CET, msr);
+		msr = rdmsrq(MSR_IA32_S_CET);
 		msr &= ~CET_ENDBR_EN;
 		msr |= (save & CET_ENDBR_EN);
 		wrmsrq(MSR_IA32_S_CET, msr);
@@ -1357,7 +1357,7 @@ u64 x86_read_arch_cap_msr(void)
 	u64 x86_arch_cap_msr = 0;
 
 	if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
-		rdmsrq(MSR_IA32_ARCH_CAPABILITIES, x86_arch_cap_msr);
+		x86_arch_cap_msr = rdmsrq(MSR_IA32_ARCH_CAPABILITIES);
 
 	return x86_arch_cap_msr;
 }
@@ -1923,10 +1923,10 @@ static bool detect_null_seg_behavior(void)
 	 */
 
 	unsigned long old_base, tmp;
-	rdmsrq(MSR_FS_BASE, old_base);
+	old_base = rdmsrq(MSR_FS_BASE);
 	wrmsrq(MSR_FS_BASE, 1);
 	loadsegment(fs, 0);
-	rdmsrq(MSR_FS_BASE, tmp);
+	tmp = rdmsrq(MSR_FS_BASE);
 	wrmsrq(MSR_FS_BASE, old_base);
 	return tmp == 0;
 }
diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
index 10a92927a515..7228fc2bb43e 100644
--- a/arch/x86/kernel/cpu/feat_ctl.c
+++ b/arch/x86/kernel/cpu/feat_ctl.c
@@ -40,7 +40,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c)
 	 * as they exist on any CPU that supports VMX, i.e. we want the WARN if
 	 * the RDMSR faults.
 	 */
-	rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS, val.q);
+	val.q = rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS);
 	supported = val.h;
 	c->vmx_capability[PRIMARY_CTLS] = supported;
 
@@ -53,7 +53,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c)
 	c->vmx_capability[TERTIARY_CTLS_LOW] = val.l;
 	c->vmx_capability[TERTIARY_CTLS_HIGH] = val.h;
 
-	rdmsrq(MSR_IA32_VMX_PINBASED_CTLS, val.q);
+	val.q = rdmsrq(MSR_IA32_VMX_PINBASED_CTLS);
 	supported = val.h;
 	rdmsrq_safe(MSR_IA32_VMX_VMFUNC, &val.q);
 	funcs = val.h;
diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c
index ec51c2b9a257..44b462799cf6 100644
--- a/arch/x86/kernel/cpu/hygon.c
+++ b/arch/x86/kernel/cpu/hygon.c
@@ -99,7 +99,7 @@ static void bsp_init_hygon(struct cpuinfo_x86 *c)
 	if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) {
 		u64 val;
 
-		rdmsrq(MSR_K7_HWCR, val);
+		val = rdmsrq(MSR_K7_HWCR);
 		if (!(val & BIT(24)))
 			pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n");
 	}
@@ -194,7 +194,7 @@ static void init_hygon(struct cpuinfo_x86 *c)
 	init_hygon_cacheinfo(c);
 
 	if (cpu_has(c, X86_FEATURE_SVM)) {
-		rdmsrq(MSR_VM_CR, vm_cr);
+		vm_cr = rdmsrq(MSR_VM_CR);
 		if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) {
 			pr_notice_once("SVM disabled (by BIOS) in MSR_VM_CR\n");
 			clear_cpu_cap(c, X86_FEATURE_SVM);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 4297ceb2cb24..2aabe9affa0c 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -159,7 +159,7 @@ static void detect_tme_early(struct cpuinfo_x86 *c)
 	u64 tme_activate;
 	int keyid_bits;
 
-	rdmsrq(MSR_IA32_TME_ACTIVATE, tme_activate);
+	tme_activate = rdmsrq(MSR_IA32_TME_ACTIVATE);
 
 	if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activate)) {
 		pr_info_once("x86/tme: not enabled by BIOS\n");
@@ -335,7 +335,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 	 * string flag and enhanced fast string capabilities accordingly.
 	 */
 	if (c->x86_vfm >= INTEL_PENTIUM_M_DOTHAN) {
-		rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
+		misc_enable = rdmsrq(MSR_IA32_MISC_ENABLE);
 		if (misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING) {
 			/* X86_FEATURE_ERMS is set based on CPUID */
 			set_cpu_cap(c, X86_FEATURE_REP_GOOD);
@@ -579,7 +579,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 	if (boot_cpu_has(X86_FEATURE_DS)) {
 		u64 l;
 
-		rdmsrq(MSR_IA32_MISC_ENABLE, l);
+		l = rdmsrq(MSR_IA32_MISC_ENABLE);
 		if (!(l & MSR_IA32_MISC_ENABLE_BTS_UNAVAIL))
 			set_cpu_cap(c, X86_FEATURE_BTS);
 		if (!(l & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL))
diff --git a/arch/x86/kernel/cpu/intel_epb.c b/arch/x86/kernel/cpu/intel_epb.c
index 2c56f8730f59..a02d562253d9 100644
--- a/arch/x86/kernel/cpu/intel_epb.c
+++ b/arch/x86/kernel/cpu/intel_epb.c
@@ -79,7 +79,7 @@ static int intel_epb_save(void *data)
 {
 	u64 epb;
 
-	rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb);
+	epb = rdmsrq(MSR_IA32_ENERGY_PERF_BIAS);
 	/*
 	 * Ensure that saved_epb will always be nonzero after this write even if
 	 * the EPB value read from the MSR is 0.
@@ -94,7 +94,7 @@ static void intel_epb_restore(void *data)
 	u64 val = this_cpu_read(saved_epb);
 	u64 epb;
 
-	rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb);
+	epb = rdmsrq(MSR_IA32_ENERGY_PERF_BIAS);
 	if (val) {
 		val &= EPB_MASK;
 	} else {
diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index f916fb4c5d13..febdd4fe9b3b 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -438,7 +438,7 @@ static void threshold_restart_block(void *_tr)
 	if (!this_cpu_read(threshold_banks) && !tr->set_lvt_off)
 		return;
 
-	rdmsrq(tr->b->address, val.q);
+	val.q = rdmsrq(tr->b->address);
 
 	/*
 	 * Reset error count and overflow bit.
@@ -658,7 +658,7 @@ static void disable_err_thresholding(struct cpuinfo_x86 *c, unsigned int bank)
 		return;
 	}
 
-	rdmsrq(MSR_K7_HWCR, hwcr);
+	hwcr = rdmsrq(MSR_K7_HWCR);
 
 	/* McStatusWrEn has to be set */
 	need_toggle = !(hwcr & BIT(18));
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index ab469605fc89..df56ca06275b 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1845,7 +1845,7 @@ static void __mcheck_cpu_cap_init(void)
 	u64 cap;
 	u8 b;
 
-	rdmsrq(MSR_IA32_MCG_CAP, cap);
+	cap = rdmsrq(MSR_IA32_MCG_CAP);
 
 	b = cap & MCG_BANKCNT_MASK;
 
@@ -1864,7 +1864,7 @@ static void __mcheck_cpu_init_generic(void)
 {
 	u64 cap;
 
-	rdmsrq(MSR_IA32_MCG_CAP, cap);
+	cap = rdmsrq(MSR_IA32_MCG_CAP);
 	if (cap & MCG_CTL_P)
 		wrmsrq(MSR_IA32_MCG_CTL, ~0ULL);
 }
@@ -1896,7 +1896,7 @@ static void __mcheck_cpu_init_prepare_banks(void)
 		wrmsrq(mca_msr_reg(i, MCA_CTL), b->ctl);
 		wrmsrq(mca_msr_reg(i, MCA_STATUS), 0);
 
-		rdmsrq(mca_msr_reg(i, MCA_CTL), msrval);
+		msrval = rdmsrq(mca_msr_reg(i, MCA_CTL));
 		b->init = !!msrval;
 	}
 }
@@ -2214,7 +2214,7 @@ void mca_bsp_init(struct cpuinfo_x86 *c)
 	if (mce_flags.smca)
 		smca_bsp_init();
 
-	rdmsrq(MSR_IA32_MCG_CAP, cap);
+	cap = rdmsrq(MSR_IA32_MCG_CAP);
 
 	/* Use accurate RIP reporting if available. */
 	if ((cap & MCG_EXT_P) && MCG_EXT_CNT(cap) >= 9)
diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c
index 6f8a49d8baeb..aa933864f32e 100644
--- a/arch/x86/kernel/cpu/mce/inject.c
+++ b/arch/x86/kernel/cpu/mce/inject.c
@@ -743,7 +743,7 @@ static void check_hw_inj_possible(void)
 		u64 status = MCI_STATUS_VAL, ipid;
 
 		/* Check whether bank is populated */
-		rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank), ipid);
+		ipid = rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank));
 		if (!ipid)
 			continue;
 
diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c
index 4655223ba560..2edb05d5e2d7 100644
--- a/arch/x86/kernel/cpu/mce/intel.c
+++ b/arch/x86/kernel/cpu/mce/intel.c
@@ -94,7 +94,7 @@ static bool cmci_supported(int *banks)
 	if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
 		return false;
 
-	rdmsrq(MSR_IA32_MCG_CAP, cap);
+	cap = rdmsrq(MSR_IA32_MCG_CAP);
 	*banks = min_t(unsigned, MAX_NR_BANKS, cap & MCG_BANKCNT_MASK);
 	return !!(cap & MCG_CMCI_P);
 }
@@ -106,7 +106,7 @@ static bool lmce_supported(void)
 	if (mca_cfg.lmce_disabled)
 		return false;
 
-	rdmsrq(MSR_IA32_MCG_CAP, tmp);
+	tmp = rdmsrq(MSR_IA32_MCG_CAP);
 
 	/*
 	 * LMCE depends on recovery support in the processor. Hence both
@@ -123,7 +123,7 @@ static bool lmce_supported(void)
 	 * WARN if the MSR isn't locked as init_ia32_feat_ctl() unconditionally
 	 * locks the MSR in the event that it wasn't already locked by BIOS.
 	 */
-	rdmsrq(MSR_IA32_FEAT_CTL, tmp);
+	tmp = rdmsrq(MSR_IA32_FEAT_CTL);
 	if (WARN_ON_ONCE(!(tmp & FEAT_CTL_LOCKED)))
 		return false;
 
@@ -141,7 +141,7 @@ static void cmci_set_threshold(int bank, int thresh)
 	u64 val;
 
 	raw_spin_lock_irqsave(&cmci_discover_lock, flags);
-	rdmsrq(MSR_IA32_MCx_CTL2(bank), val);
+	val = rdmsrq(MSR_IA32_MCx_CTL2(bank));
 	val &= ~MCI_CTL2_CMCI_THRESHOLD_MASK;
 	wrmsrq(MSR_IA32_MCx_CTL2(bank), val | thresh);
 	raw_spin_unlock_irqrestore(&cmci_discover_lock, flags);
@@ -184,7 +184,7 @@ static bool cmci_skip_bank(int bank, u64 *val)
 	if (test_bit(bank, mce_banks_ce_disabled))
 		return true;
 
-	rdmsrq(MSR_IA32_MCx_CTL2(bank), *val);
+	*val = rdmsrq(MSR_IA32_MCx_CTL2(bank));
 
 	/* Already owned by someone else? */
 	if (*val & MCI_CTL2_CMCI_EN) {
@@ -233,7 +233,7 @@ static void cmci_claim_bank(int bank, u64 val, int bios_zero_thresh, int *bios_w
 
 	val |= MCI_CTL2_CMCI_EN;
 	wrmsrq(MSR_IA32_MCx_CTL2(bank), val);
-	rdmsrq(MSR_IA32_MCx_CTL2(bank), val);
+	val = rdmsrq(MSR_IA32_MCx_CTL2(bank));
 
 	/* If the enable bit did not stick, this bank should be polled. */
 	if (!(val & MCI_CTL2_CMCI_EN)) {
@@ -324,7 +324,7 @@ static void __cmci_disable_bank(int bank)
 
 	if (!test_bit(bank, this_cpu_ptr(mce_banks_owned)))
 		return;
-	rdmsrq(MSR_IA32_MCx_CTL2(bank), val);
+	val = rdmsrq(MSR_IA32_MCx_CTL2(bank));
 	val &= ~MCI_CTL2_CMCI_EN;
 	wrmsrq(MSR_IA32_MCx_CTL2(bank), val);
 	__clear_bit(bank, this_cpu_ptr(mce_banks_owned));
@@ -430,7 +430,7 @@ void intel_init_lmce(void)
 	if (!lmce_supported())
 		return;
 
-	rdmsrq(MSR_IA32_MCG_EXT_CTL, val);
+	val = rdmsrq(MSR_IA32_MCG_EXT_CTL);
 
 	if (!(val & MCG_EXT_CTL_LMCE_EN))
 		wrmsrq(MSR_IA32_MCG_EXT_CTL, val | MCG_EXT_CTL_LMCE_EN);
@@ -443,7 +443,7 @@ void intel_clear_lmce(void)
 	if (!lmce_supported())
 		return;
 
-	rdmsrq(MSR_IA32_MCG_EXT_CTL, val);
+	val = rdmsrq(MSR_IA32_MCG_EXT_CTL);
 	val &= ~MCG_EXT_CTL_LMCE_EN;
 	wrmsrq(MSR_IA32_MCG_EXT_CTL, val);
 }
diff --git a/arch/x86/kernel/cpu/mce/p5.c b/arch/x86/kernel/cpu/mce/p5.c
index 3c2b6cc918b1..b441c720f9b7 100644
--- a/arch/x86/kernel/cpu/mce/p5.c
+++ b/arch/x86/kernel/cpu/mce/p5.c
@@ -26,8 +26,8 @@ noinstr void pentium_machine_check(struct pt_regs *regs)
 	u64 addr, type;
 
 	instrumentation_begin();
-	rdmsrq(MSR_IA32_P5_MC_ADDR, addr);
-	rdmsrq(MSR_IA32_P5_MC_TYPE, type);
+	addr = rdmsrq(MSR_IA32_P5_MC_ADDR);
+	type = rdmsrq(MSR_IA32_P5_MC_TYPE);
 
 	pr_emerg("CPU#%d: Machine Check Exception:  0x%8X (type 0x%8X).\n",
 		 smp_processor_id(), (u32)addr, (u32)type);
@@ -55,8 +55,8 @@ void intel_p5_mcheck_init(struct cpuinfo_x86 *c)
 		return;
 
 	/* Read registers before enabling: */
-	rdmsrq(MSR_IA32_P5_MC_ADDR, q);
-	rdmsrq(MSR_IA32_P5_MC_TYPE, q);
+	q = rdmsrq(MSR_IA32_P5_MC_ADDR);
+	q = rdmsrq(MSR_IA32_P5_MC_TYPE);
 	pr_info("Intel old style machine check architecture supported.\n");
 
 	/* Enable MCE: */
diff --git a/arch/x86/kernel/cpu/mce/winchip.c b/arch/x86/kernel/cpu/mce/winchip.c
index 7040243533d9..7b967f2abd8f 100644
--- a/arch/x86/kernel/cpu/mce/winchip.c
+++ b/arch/x86/kernel/cpu/mce/winchip.c
@@ -30,7 +30,7 @@ void winchip_mcheck_init(struct cpuinfo_x86 *c)
 {
 	struct msr val;
 
-	rdmsrq(MSR_IDT_FCR1, val.q);
+	val.q = rdmsrq(MSR_IDT_FCR1);
 	val.l |= (1<<2);	/* Enable EIERRINT (int 18 MCE) */
 	val.l &= ~(1<<4);	/* Enable MCE */
 	wrmsrq(MSR_IDT_FCR1, val.q);
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 1142183c950c..4d199abd8fd8 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -991,7 +991,7 @@ static __init bool staging_available(void)
 	if (!(val & ARCH_CAP_MCU_ENUM))
 		return false;
 
-	rdmsrq(MSR_IA32_MCU_ENUMERATION, val);
+	val = rdmsrq(MSR_IA32_MCU_ENUMERATION);
 	return !!(val & MCU_STAGING);
 }
 
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 185d4f677ec0..65ad235ef5c6 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -74,7 +74,7 @@ u64 hv_get_non_nested_msr(unsigned int reg)
 	if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present)
 		hv_ivm_msr_read(reg, &value);
 	else
-		rdmsrq(reg, value);
+		value = rdmsrq(reg);
 	return value;
 }
 EXPORT_SYMBOL_GPL(hv_get_non_nested_msr);
@@ -399,7 +399,7 @@ static unsigned long hv_get_tsc_khz(void)
 {
 	unsigned long freq;
 
-	rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq);
+	freq = rdmsrq(HV_X64_MSR_TSC_FREQUENCY);
 
 	return freq / 1000;
 }
@@ -645,7 +645,7 @@ static void __init ms_hyperv_init_platform(void)
 		 */
 		u64	hv_lapic_frequency;
 
-		rdmsrq(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
+		hv_lapic_frequency = rdmsrq(HV_X64_MSR_APIC_FREQUENCY);
 		hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
 		lapic_timer_period = hv_lapic_frequency;
 		pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/amd.c
index a73715d6f05c..652e4d64ff4a 100644
--- a/arch/x86/kernel/cpu/mtrr/amd.c
+++ b/arch/x86/kernel/cpu/mtrr/amd.c
@@ -13,7 +13,7 @@ amd_get_mtrr(unsigned int reg, unsigned long *base,
 	unsigned long val;
 	struct msr msr;
 
-	rdmsrq(MSR_K6_UWCCR, msr.q);
+	msr.q = rdmsrq(MSR_K6_UWCCR);
 	/* Upper dword is region 1, lower is region 0 */
 	if (reg == 1)
 		val = msr.h;
@@ -68,7 +68,7 @@ amd_set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type
 	/*
 	 * Low is MTRR0, High MTRR 1
 	 */
-	rdmsrq(MSR_K6_UWCCR, msr.q);
+	msr.q = rdmsrq(MSR_K6_UWCCR);
 	regs[0] = msr.l;
 	regs[1] = msr.h;
 
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index cd1a6dec4064..2b72c784db9e 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -670,7 +670,7 @@ int __init mtrr_cleanup(void)
 	if (!cpu_feature_enabled(X86_FEATURE_MTRR) || enable_mtrr_cleanup < 1)
 		return 0;
 
-	rdmsrq(MSR_MTRRdefType, def);
+	def = rdmsrq(MSR_MTRRdefType);
 	def &= 0xff;
 	if (def != MTRR_TYPE_UNCACHABLE)
 		return 0;
@@ -870,7 +870,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 	if (!cpu_feature_enabled(X86_FEATURE_MTRR) || disable_mtrr_trim)
 		return 0;
 
-	rdmsrq(MSR_MTRRdefType, def);
+	def = rdmsrq(MSR_MTRRdefType);
 	def &= MTRR_DEF_TYPE_TYPE;
 	if (def != MTRR_TYPE_UNCACHABLE)
 		return 0;
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index 67cf69f24b00..4d8034a7fdc8 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -112,7 +112,7 @@ static inline void k8_check_syscfg_dram_mod_en(void)
 	if (cc_platform_has(CC_ATTR_HOST_SEV_SNP))
 		return;
 
-	rdmsrq(MSR_AMD64_SYSCFG, val.q);
+	val.q = rdmsrq(MSR_AMD64_SYSCFG);
 	if (val.l & K8_MTRRFIXRANGE_DRAM_MODIFY) {
 		pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]"
 		       " not cleared by BIOS, clearing this bit\n",
@@ -559,10 +559,10 @@ get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr)
 {
 	struct msr val;
 
-	rdmsrq(MTRRphysBase_MSR(index), val.q);
+	val.q = rdmsrq(MTRRphysBase_MSR(index));
 	vr->base_lo = val.l;
 	vr->base_hi = val.h;
-	rdmsrq(MTRRphysMask_MSR(index), val.q);
+	val.q = rdmsrq(MTRRphysMask_MSR(index));
 	vr->mask_lo = val.l;
 	vr->mask_hi = val.h;
 }
@@ -588,12 +588,12 @@ static void get_fixed_ranges(mtrr_type *frs)
 
 	k8_check_syscfg_dram_mod_en();
 
-	rdmsrq(MSR_MTRRfix64K_00000, p[0]);
+	p[0] = rdmsrq(MSR_MTRRfix64K_00000);
 
 	for (i = 0; i < 2; i++)
-		rdmsrq(MSR_MTRRfix16K_80000 + i, p[1 + i]);
+		p[1 + i] = rdmsrq(MSR_MTRRfix16K_80000 + i);
 	for (i = 0; i < 8; i++)
-		rdmsrq(MSR_MTRRfix4K_C0000 + i, p[3 + i]);
+		p[3 + i] = rdmsrq(MSR_MTRRfix4K_C0000 + i);
 }
 
 void mtrr_save_fixed_ranges(void *info)
@@ -700,7 +700,7 @@ bool __init get_mtrr_state(void)
 
 	vrs = mtrr_state.var_ranges;
 
-	rdmsrq(MSR_MTRRcap, q);
+	q = rdmsrq(MSR_MTRRcap);
 	mtrr_state.have_fixed = q & MTRR_CAP_FIX;
 
 	for (i = 0; i < num_var_ranges; i++)
@@ -708,13 +708,13 @@ bool __init get_mtrr_state(void)
 	if (mtrr_state.have_fixed)
 		get_fixed_ranges(mtrr_state.fixed_ranges);
 
-	rdmsrq(MSR_MTRRdefType, q);
+	q = rdmsrq(MSR_MTRRdefType);
 	mtrr_state.def_type = q & MTRR_DEF_TYPE_TYPE;
 	mtrr_state.enabled = (q & MTRR_DEF_TYPE_ENABLE) >> MTRR_STATE_SHIFT;
 
 	if (amd_special_default_mtrr()) {
 		/* TOP_MEM2 */
-		rdmsrq(MSR_K8_TOP_MEM2, mtrr_tom2);
+		mtrr_tom2 = rdmsrq(MSR_K8_TOP_MEM2);
 		mtrr_tom2 &= 0xffffff800000ULL;
 	}
 
@@ -770,7 +770,7 @@ static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords)
 {
 	struct msr val;
 
-	rdmsrq(msr, val.q);
+	val.q = rdmsrq(msr);
 
 	if (val.l != msrwords[0] || val.h != msrwords[1]) {
 		mtrr_wrmsr(msr, msrwords[0], msrwords[1]);
@@ -818,7 +818,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base,
 	 */
 	get_cpu();
 
-	rdmsrq(MTRRphysMask_MSR(reg), mask);
+	mask = rdmsrq(MTRRphysMask_MSR(reg));
 
 	if (!(mask & MTRR_PHYSMASK_V)) {
 		/*  Invalid (i.e. free) range */
@@ -828,7 +828,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base,
 		goto out_put_cpu;
 	}
 
-	rdmsrq(MTRRphysBase_MSR(reg), base_msr);
+	base_msr = rdmsrq(MTRRphysBase_MSR(reg));
 
 	/* Work out the shifted address mask: */
 	tmp = mask & PAGE_MASK;
@@ -889,7 +889,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 	bool changed = false;
 	struct msr val;
 
-	rdmsrq(MTRRphysBase_MSR(index), val.q);
+	val.q = rdmsrq(MTRRphysBase_MSR(index));
 	if ((vr->base_lo & ~MTRR_PHYSBASE_RSVD) != (val.l & ~MTRR_PHYSBASE_RSVD)
 	    || (vr->base_hi & ~phys_hi_rsvd) != (val.h & ~phys_hi_rsvd)) {
 
@@ -897,7 +897,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
 		changed = true;
 	}
 
-	rdmsrq(MTRRphysMask_MSR(index), val.q);
+	val.q = rdmsrq(MTRRphysMask_MSR(index));
 
 	if ((vr->mask_lo & ~MTRR_PHYSMASK_RSVD) != (val.l & ~MTRR_PHYSMASK_RSVD)
 	    || (vr->mask_hi & ~phys_hi_rsvd) != (val.h & ~phys_hi_rsvd)) {
@@ -952,7 +952,7 @@ void mtrr_disable(void)
 	struct msr val;
 
 	/* Save MTRR state */
-	rdmsrq(MSR_MTRRdefType, val.q);
+	val.q = rdmsrq(MSR_MTRRdefType);
 	deftype_lo = val.l;
 	deftype_hi = val.h;
 
@@ -1065,7 +1065,7 @@ static int generic_have_wrcomb(void)
 {
 	u64 config;
 
-	rdmsrq(MSR_MTRRcap, config);
+	config = rdmsrq(MSR_MTRRcap);
 	return config & MTRR_CAP_WC;
 }
 
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index 468c53b20acf..9b7abd58b677 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -571,7 +571,7 @@ void __init mtrr_bp_init(void)
 	if (mtrr_enabled()) {
 		/* Get the number of variable MTRR ranges. */
 		if (mtrr_if == &generic_mtrr_ops)
-			rdmsrq(MSR_MTRRcap, config);
+			config = rdmsrq(MSR_MTRRcap);
 		else
 			config = mtrr_if->var_regs;
 		num_var_ranges = config & MTRR_CAP_VCNT;
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 55214d6fdc49..dd0e20179fce 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -165,7 +165,7 @@ static inline void cache_alloc_hsw_probe(void)
 	if (wrmsrq_safe(MSR_IA32_L3_CBM_BASE, max_cbm))
 		return;
 
-	rdmsrq(MSR_IA32_L3_CBM_BASE, l3_cbm_0);
+	l3_cbm_0 = rdmsrq(MSR_IA32_L3_CBM_BASE);
 
 	/* If all the bits were set in MSR, return success */
 	if (l3_cbm_0 != max_cbm)
diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
index 3838e0a13d36..530c425d7ee4 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -147,7 +147,7 @@ static int __rmid_read_phys(u32 prmid, enum resctrl_event_id eventid, u64 *val)
 	 * are error bits.
 	 */
 	wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q);
-	rdmsrq(MSR_IA32_QM_CTR, msr_val.q);
+	msr_val.q = rdmsrq(MSR_IA32_QM_CTR);
 
 	if (msr_val.q & RMID_VAL_ERROR)
 		return -EIO;
@@ -310,7 +310,7 @@ static int __cntr_id_read(u32 cntr_id, u64 *val)
 	 * is set if the counter data is unavailable.
 	 */
 	wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q);
-	rdmsrq(MSR_IA32_QM_CTR, msr_val.q);
+	msr_val.q = rdmsrq(MSR_IA32_QM_CTR);
 
 	if (msr_val.q & RMID_VAL_ERROR)
 		return -EIO;
diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
index d7caab0409b6..0408ac7f66fd 100644
--- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
+++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
@@ -250,7 +250,7 @@ int resctrl_arch_measure_cycles_lat_fn(void *_plr)
 	/*
 	 * Disable hardware prefetchers.
 	 */
-	rdmsrq(MSR_MISC_FEATURE_CONTROL, saved);
+	saved = rdmsrq(MSR_MISC_FEATURE_CONTROL);
 	wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits);
 	mem_r = READ_ONCE(plr->kmem);
 	/*
@@ -346,7 +346,7 @@ static int measure_residency_fn(struct perf_event_attr *miss_attr,
 	/*
 	 * Disable hardware prefetchers.
 	 */
-	rdmsrq(MSR_MISC_FEATURE_CONTROL, saved);
+	saved = rdmsrq(MSR_MISC_FEATURE_CONTROL);
 	wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits);
 
 	/* Initialize rest of local variables */
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 5ffa39fa86fa..37f0b1f7fe4f 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -96,7 +96,7 @@ void resctrl_arch_mon_event_config_read(void *_config_info)
 		pr_warn_once("Invalid event id %d\n", config_info->evtid);
 		return;
 	}
-	rdmsrq(MSR_IA32_EVT_CFG_BASE + index, msrval);
+	msrval = rdmsrq(MSR_IA32_EVT_CFG_BASE + index);
 
 	/* Report only the valid event configuration bits */
 	config_info->mon_config = msrval & MAX_EVT_CONFIG_BITS;
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c
index 4913b64ec592..68337da5aa09 100644
--- a/arch/x86/kernel/cpu/topology.c
+++ b/arch/x86/kernel/cpu/topology.c
@@ -151,7 +151,7 @@ static __init bool check_for_real_bsp(u32 apic_id)
 	 * kernel must rely on the firmware enumeration order.
 	 */
 	if (has_apic_base) {
-		rdmsrq(MSR_IA32_APICBASE, msr);
+		msr = rdmsrq(MSR_IA32_APICBASE);
 		is_bsp = !!(msr & MSR_IA32_APICBASE_BSP);
 	}
 
diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c
index c5a6944df86a..5192f13f3686 100644
--- a/arch/x86/kernel/cpu/topology_amd.c
+++ b/arch/x86/kernel/cpu/topology_amd.c
@@ -140,7 +140,7 @@ static void parse_fam10h_node_id(struct topo_scan *tscan)
 	if (!boot_cpu_has(X86_FEATURE_NODEID_MSR))
 		return;
 
-	rdmsrq(MSR_FAM10H_NODE_ID, nid.msr);
+	nid.msr = rdmsrq(MSR_FAM10H_NODE_ID);
 	store_node(tscan, nid.nodes_per_pkg + 1, nid.node_id);
 	tscan->c->topo.llc_id = nid.node_id;
 }
@@ -168,7 +168,7 @@ static void topoext_fixup(struct topo_scan *tscan)
 			MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT_BIT) <= 0)
 		return;
 
-	rdmsrq(MSR_AMD64_CPUID_EXT_FEAT, msrval);
+	msrval = rdmsrq(MSR_AMD64_CPUID_EXT_FEAT);
 	if (msrval & MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT) {
 		set_cpu_cap(c, X86_FEATURE_TOPOEXT);
 		pr_info_once(FW_INFO "CPU: Re-enabling disabled Topology Extensions Support.\n");
diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transmeta.c
index 35d498f24e34..f8632becda18 100644
--- a/arch/x86/kernel/cpu/transmeta.c
+++ b/arch/x86/kernel/cpu/transmeta.c
@@ -87,7 +87,7 @@ static void init_transmeta(struct cpuinfo_x86 *c)
 	}
 
 	/* Unhide possibly hidden capability flags */
-	rdmsrq(0x80860004, msr);
+	msr = rdmsrq(0x80860004);
 	wrmsrq(0x80860004, msr | ~0U);
 	cpuid_refresh_leaf(c, 0x1);
 	c->x86_capability[CPUID_1_EDX] = cpuid_edx(0x00000001);
diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c
index 209b5a22d880..b500845d2049 100644
--- a/arch/x86/kernel/cpu/tsx.c
+++ b/arch/x86/kernel/cpu/tsx.c
@@ -35,7 +35,7 @@ static void tsx_disable(void)
 {
 	u64 tsx;
 
-	rdmsrq(MSR_IA32_TSX_CTRL, tsx);
+	tsx = rdmsrq(MSR_IA32_TSX_CTRL);
 
 	/* Force all transactions to immediately abort */
 	tsx |= TSX_CTRL_RTM_DISABLE;
@@ -55,7 +55,7 @@ static void tsx_enable(void)
 {
 	u64 tsx;
 
-	rdmsrq(MSR_IA32_TSX_CTRL, tsx);
+	tsx = rdmsrq(MSR_IA32_TSX_CTRL);
 
 	/* Enable the RTM feature in the cpu */
 	tsx &= ~TSX_CTRL_RTM_DISABLE;
@@ -126,11 +126,11 @@ static void tsx_clear_cpuid(void)
 	 */
 	if (boot_cpu_has(X86_FEATURE_RTM_ALWAYS_ABORT) &&
 	    boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)) {
-		rdmsrq(MSR_TSX_FORCE_ABORT, msr);
+		msr = rdmsrq(MSR_TSX_FORCE_ABORT);
 		msr |= MSR_TFA_TSX_CPUID_CLEAR;
 		wrmsrq(MSR_TSX_FORCE_ABORT, msr);
 	} else if (cpu_feature_enabled(X86_FEATURE_MSR_TSX_CTRL)) {
-		rdmsrq(MSR_IA32_TSX_CTRL, msr);
+		msr = rdmsrq(MSR_IA32_TSX_CTRL);
 		msr |= TSX_CTRL_CPUID_CLEAR;
 		wrmsrq(MSR_IA32_TSX_CTRL, msr);
 	}
@@ -157,7 +157,7 @@ static void tsx_dev_mode_disable(void)
 	    !cpu_feature_enabled(X86_FEATURE_SRBDS_CTRL))
 		return;
 
-	rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_opt_ctrl);
+	mcu_opt_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL);
 
 	if (mcu_opt_ctrl & RTM_ALLOW) {
 		mcu_opt_ctrl &= ~RTM_ALLOW;
diff --git a/arch/x86/kernel/cpu/umwait.c b/arch/x86/kernel/cpu/umwait.c
index e4a31c536642..8c3cf0f95e9a 100644
--- a/arch/x86/kernel/cpu/umwait.c
+++ b/arch/x86/kernel/cpu/umwait.c
@@ -218,7 +218,7 @@ static int __init umwait_init(void)
 	 * changed. This is the only place where orig_umwait_control_cached
 	 * is modified.
 	 */
-	rdmsrq(MSR_IA32_UMWAIT_CONTROL, orig_umwait_control_cached);
+	orig_umwait_control_cached = rdmsrq(MSR_IA32_UMWAIT_CONTROL);
 
 	ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "umwait:online",
 				umwait_cpu_online, umwait_cpu_offline);
diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
index fe504fd43c77..f89aec38a349 100644
--- a/arch/x86/kernel/cpu/zhaoxin.c
+++ b/arch/x86/kernel/cpu/zhaoxin.c
@@ -29,7 +29,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c)
 
 		/* Enable ACE unit, if present and disabled */
 		if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) {
-			rdmsrq(MSR_ZHAOXIN_FCR57, msr);
+			msr = rdmsrq(MSR_ZHAOXIN_FCR57);
 			/* Enable ACE unit */
 			wrmsrq(MSR_ZHAOXIN_FCR57, msr | ACE_FCR);
 			pr_info("CPU: Enabled ACE h/w crypto\n");
@@ -37,7 +37,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c)
 
 		/* Enable RNG unit, if present and disabled */
 		if ((tmp & (RNG_PRESENT | RNG_ENABLED)) == RNG_PRESENT) {
-			rdmsrq(MSR_ZHAOXIN_FCR57, msr);
+			msr = rdmsrq(MSR_ZHAOXIN_FCR57);
 			/* Enable RNG unit */
 			wrmsrq(MSR_ZHAOXIN_FCR57, msr | RNG_ENABLE);
 			pr_info("CPU: Enabled h/w RNG\n");
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index d1aeecd57f5e..7d2cff9633cf 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -364,7 +364,7 @@ void fpu_sync_guest_vmexit_xfd_state(void)
 
 	lockdep_assert_irqs_disabled();
 	if (fpu_state_size_dynamic()) {
-		rdmsrq(MSR_IA32_XFD, fpstate->xfd);
+		fpstate->xfd = rdmsrq(MSR_IA32_XFD);
 		__this_cpu_write(xfd_state, fpstate->xfd);
 	}
 }
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 8dc7b710e125..8a27b9ae9fc7 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -971,7 +971,7 @@ static bool __init hpet_is_pc10_damaged(void)
 		return false;
 
 	/* Check whether PC10 is enabled in PKG C-state limit */
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, pcfg);
+	pcfg = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 	if ((pcfg & 0xF) < 8)
 		return false;
 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 6b0a5861ccb8..8710e3fab693 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -740,7 +740,7 @@ static int kvm_suspend(void *data)
 
 #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
 	if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL))
-		rdmsrq(MSR_KVM_POLL_CONTROL, val);
+		val = rdmsrq(MSR_KVM_POLL_CONTROL);
 	has_guest_poll = !(val & 1);
 #endif
 	return 0;
diff --git a/arch/x86/kernel/mmconf-fam10h_64.c b/arch/x86/kernel/mmconf-fam10h_64.c
index ef6104e7cc72..348ac8fce3ad 100644
--- a/arch/x86/kernel/mmconf-fam10h_64.c
+++ b/arch/x86/kernel/mmconf-fam10h_64.c
@@ -97,7 +97,7 @@ static void get_fam10h_pci_mmconf_base(void)
 
 	/* SYS_CFG */
 	address = MSR_AMD64_SYSCFG;
-	rdmsrq(address, val);
+	val = rdmsrq(address);
 
 	/* TOP_MEM2 is not enabled? */
 	if (!(val & (1<<21))) {
@@ -105,7 +105,7 @@ static void get_fam10h_pci_mmconf_base(void)
 	} else {
 		/* TOP_MEM2 */
 		address = MSR_K8_TOP_MEM2;
-		rdmsrq(address, val);
+		val = rdmsrq(address);
 		tom2 = max(val & 0xffffff800000ULL, 1ULL << 32);
 	}
 
@@ -177,7 +177,7 @@ void fam10h_check_enable_mmcfg(void)
 		return;
 
 	address = MSR_FAM10H_MMIO_CONF_BASE;
-	rdmsrq(address, val);
+	val = rdmsrq(address);
 
 	/* try to make sure that AP's setting is identical to BSP setting */
 	if (val & FAM10H_MMIO_CONF_ENABLE) {
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 346c438ac880..85e6b076ef17 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -730,7 +730,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p)
 	    arch_has_block_step()) {
 		unsigned long debugctl, msk;
 
-		rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
+		debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 		debugctl &= ~DEBUGCTLMSR_BTF;
 		msk = tifn & _TIF_BLOCKSTEP;
 		debugctl |= (msk >> TIF_BLOCKSTEP) << DEBUGCTLMSR_BTF_SHIFT;
@@ -980,7 +980,7 @@ void __init arch_post_acpi_subsys_init(void)
 	 * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set in
 	 * MSR_K8_INT_PENDING_MSG.
 	 */
-	rdmsrq(MSR_K8_INT_PENDING_MSG, val);
+	val = rdmsrq(MSR_K8_INT_PENDING_MSG);
 	if (!(val & K8_INTP_C1E_ACTIVE_MASK))
 		return;
 
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 2bce7b3f97ed..28dbe7e629fc 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -97,8 +97,8 @@ void __show_regs(struct pt_regs *regs, enum show_regs_mode mode,
 		return;
 
 	if (mode == SHOW_REGS_USER) {
-		rdmsrq(MSR_FS_BASE, fs);
-		rdmsrq(MSR_KERNEL_GS_BASE, shadowgs);
+		fs = rdmsrq(MSR_FS_BASE);
+		shadowgs = rdmsrq(MSR_KERNEL_GS_BASE);
 		printk("%sFS:  %016lx GS:  %016lx\n",
 		       log_lvl, fs, shadowgs);
 		return;
@@ -109,9 +109,9 @@ void __show_regs(struct pt_regs *regs, enum show_regs_mode mode,
 	savesegment(fs, fsindex);
 	savesegment(gs, gsindex);
 
-	rdmsrq(MSR_FS_BASE, fs);
-	rdmsrq(MSR_GS_BASE, gs);
-	rdmsrq(MSR_KERNEL_GS_BASE, shadowgs);
+	fs = rdmsrq(MSR_FS_BASE);
+	gs = rdmsrq(MSR_GS_BASE);
+	shadowgs = rdmsrq(MSR_KERNEL_GS_BASE);
 
 	cr0 = read_cr0();
 	cr2 = read_cr2();
@@ -197,7 +197,7 @@ static noinstr unsigned long __rdgsbase_inactive(void)
 		native_swapgs();
 	} else {
 		instrumentation_begin();
-		rdmsrq(MSR_KERNEL_GS_BASE, gsbase);
+		gsbase = rdmsrq(MSR_KERNEL_GS_BASE);
 		instrumentation_end();
 	}
 
@@ -463,7 +463,7 @@ unsigned long x86_gsbase_read_cpu_inactive(void)
 		gsbase = __rdgsbase_inactive();
 		local_irq_restore(flags);
 	} else {
-		rdmsrq(MSR_KERNEL_GS_BASE, gsbase);
+		gsbase = rdmsrq(MSR_KERNEL_GS_BASE);
 	}
 
 	return gsbase;
diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
index 0ca64900192f..f3d1f385c626 100644
--- a/arch/x86/kernel/shstk.c
+++ b/arch/x86/kernel/shstk.c
@@ -231,7 +231,7 @@ static unsigned long get_user_shstk_addr(void)
 
 	fpregs_lock_and_load();
 
-	rdmsrq(MSR_IA32_PL3_SSP, ssp);
+	ssp = rdmsrq(MSR_IA32_PL3_SSP);
 
 	fpregs_unlock();
 
@@ -248,7 +248,7 @@ int shstk_pop(u64 *val)
 
 	fpregs_lock_and_load();
 
-	rdmsrq(MSR_IA32_PL3_SSP, ssp);
+	ssp = rdmsrq(MSR_IA32_PL3_SSP);
 	if (val && get_user(*val, (__user u64 *)ssp))
 		ret = -EFAULT;
 	else
@@ -268,7 +268,7 @@ int shstk_push(u64 val)
 
 	fpregs_lock_and_load();
 
-	rdmsrq(MSR_IA32_PL3_SSP, ssp);
+	ssp = rdmsrq(MSR_IA32_PL3_SSP);
 	ssp -= SS_FRAME_SIZE;
 	ret = write_user_shstk_64((__user void *)ssp, val);
 	if (!ret)
@@ -497,7 +497,7 @@ static int wrss_control(bool enable)
 		return 0;
 
 	fpregs_lock_and_load();
-	rdmsrq(MSR_IA32_U_CET, msrval);
+	msrval = rdmsrq(MSR_IA32_U_CET);
 
 	if (enable) {
 		features_set(ARCH_SHSTK_WRSS);
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 30aa8369957e..9cd11dc7bb17 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -1250,7 +1250,7 @@ static noinstr void exc_debug_kernel(struct pt_regs *regs, unsigned long dr6)
 		 */
 		unsigned long debugctl;
 
-		rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
+		debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR);
 		debugctl |= DEBUGCTLMSR_BTF;
 		wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
 	}
@@ -1509,7 +1509,7 @@ static bool handle_xfd_event(struct pt_regs *regs)
 	if (!IS_ENABLED(CONFIG_X86_64) || !cpu_feature_enabled(X86_FEATURE_XFD))
 		return false;
 
-	rdmsrq(MSR_IA32_XFD_ERR, xfd_err);
+	xfd_err = rdmsrq(MSR_IA32_XFD_ERR);
 	if (!xfd_err)
 		return false;
 
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 723347e2cf7f..39baee2307c3 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1088,7 +1088,7 @@ static void __init detect_art(void)
 	if (art_base_clk.denominator < ART_MIN_DENOMINATOR)
 		return;
 
-	rdmsrq(MSR_IA32_TSC_ADJUST, art_base_clk.offset);
+	art_base_clk.offset = rdmsrq(MSR_IA32_TSC_ADJUST);
 
 	/* Make this sticky over multiple CPU init calls */
 	setup_force_cpu_cap(X86_FEATURE_ART);
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index d74743c8d2a4..6a1d22e8b846 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -179,15 +179,15 @@ unsigned long cpu_khz_from_msr(void)
 
 	freq_desc = (struct freq_desc *)id->driver_data;
 	if (freq_desc->use_msr_plat) {
-		rdmsrq(MSR_PLATFORM_INFO, val.q);
+		val.q = rdmsrq(MSR_PLATFORM_INFO);
 		ratio = (val.l >> 8) & 0xff;
 	} else {
-		rdmsrq(MSR_IA32_PERF_STATUS, val.q);
+		val.q = rdmsrq(MSR_IA32_PERF_STATUS);
 		ratio = (val.h >> 8) & 0x1f;
 	}
 
 	/* Get FSB FREQ ID */
-	rdmsrq(MSR_FSB_FREQ, val.q);
+	val.q = rdmsrq(MSR_FSB_FREQ);
 	index = val.l & freq_desc->mask;
 	md = &freq_desc->muldiv[index];
 
diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c
index ec3aa340d351..a21ea3c85f6f 100644
--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -66,7 +66,7 @@ void tsc_verify_tsc_adjust(bool resume)
 
 	adj->nextcheck = jiffies + HZ;
 
-	rdmsrq(MSR_IA32_TSC_ADJUST, curval);
+	curval = rdmsrq(MSR_IA32_TSC_ADJUST);
 	if (adj->adjusted == curval)
 		return;
 
@@ -166,7 +166,7 @@ bool __init tsc_store_and_check_tsc_adjust(bool bootcpu)
 	if (check_tsc_unstable())
 		return false;
 
-	rdmsrq(MSR_IA32_TSC_ADJUST, bootval);
+	bootval = rdmsrq(MSR_IA32_TSC_ADJUST);
 	cur->bootval = bootval;
 	cur->nextcheck = jiffies + HZ;
 	tsc_sanitize_first_cpu(cur, bootval, smp_processor_id(), bootcpu);
@@ -188,7 +188,7 @@ bool tsc_store_and_check_tsc_adjust(bool bootcpu)
 	if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
 		return false;
 
-	rdmsrq(MSR_IA32_TSC_ADJUST, bootval);
+	bootval = rdmsrq(MSR_IA32_TSC_ADJUST);
 	cur->bootval = bootval;
 	cur->nextcheck = jiffies + HZ;
 	cur->warned = false;
diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c
index c18286545a7a..5ebee82dba84 100644
--- a/arch/x86/kvm/svm/pmu.c
+++ b/arch/x86/kvm/svm/pmu.c
@@ -249,7 +249,7 @@ static void amd_mediated_pmu_load(struct kvm_vcpu *vcpu)
 	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
 	u64 global_status;
 
-	rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, global_status);
+	global_status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS);
 	/* Clear host global_status MSR if non-zero. */
 	if (global_status)
 		wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS_CLR, global_status);
@@ -263,7 +263,7 @@ static void amd_mediated_pmu_put(struct kvm_vcpu *vcpu)
 	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
 
 	wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, 0);
-	rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, pmu->global_status);
+	pmu->global_status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS);
 
 	/* Clear global status bits if non-zero */
 	if (pmu->global_status)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 69a0d6a1cfc7..6410bd3eb2cd 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4636,7 +4636,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
 	kvm_clear_available_registers(vcpu, SVM_REGS_LAZY_LOAD_SET);
 
 	if (!msr_write_intercepted(svm, MSR_AMD64_PERF_CNTR_GLOBAL_CTL))
-		rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, vcpu_to_pmu(vcpu)->global_ctrl);
+		vcpu_to_pmu(vcpu)->global_ctrl = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL);
 
 	trace_kvm_exit(vcpu, KVM_ISA_SVM);
 
@@ -5499,7 +5499,7 @@ static __init void svm_adjust_mmio_mask(void)
 		return;
 
 	/* If memory encryption is not enabled, use existing mask */
-	rdmsrq(MSR_AMD64_SYSCFG, msr);
+	msr = rdmsrq(MSR_AMD64_SYSCFG);
 	if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT))
 		return;
 
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index ddf6df7bee93..d8f4e7706d39 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -7348,8 +7348,8 @@ static void nested_vmx_setup_cr_fixed(struct nested_vmx_msrs *msrs)
 	msrs->cr4_fixed0 = VMXON_CR4_ALWAYSON;
 
 	/* These MSRs specify bits which the guest must keep fixed off. */
-	rdmsrq(MSR_IA32_VMX_CR0_FIXED1, msrs->cr0_fixed1);
-	rdmsrq(MSR_IA32_VMX_CR4_FIXED1, msrs->cr4_fixed1);
+	msrs->cr0_fixed1 = rdmsrq(MSR_IA32_VMX_CR0_FIXED1);
+	msrs->cr4_fixed1 = rdmsrq(MSR_IA32_VMX_CR4_FIXED1);
 
 	if (vmx_umip_emulated())
 		msrs->cr4_fixed1 |= X86_CR4_UMIP;
diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 1944939c4139..5eb5636704bc 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -320,7 +320,7 @@ static bool intel_pmu_handle_lbr_msrs_access(struct kvm_vcpu *vcpu,
 		int err = 0;
 
 		if (read)
-			rdmsrq(index, msr_info->data);
+			msr_info->data = rdmsrq(index);
 		else
 			err = wrmsrq_safe(index, msr_info->data);
 		__set_bit(INTEL_PMC_IDX_FIXED_VLBR, vcpu_to_pmu(vcpu)->pmc_in_use);
@@ -772,7 +772,7 @@ static bool intel_pmu_is_mediated_pmu_supported(struct x86_pmu_capability *host_
 	u64 host_perf_cap = 0;
 
 	if (boot_cpu_has(X86_FEATURE_PDCM))
-		rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap);
+		host_perf_cap = rdmsrq(MSR_IA32_PERF_CAPABILITIES);
 
 	/*
 	 * Require v4+ for MSR_CORE_PERF_GLOBAL_STATUS_SET, and full-width
@@ -802,7 +802,7 @@ static void intel_mediated_pmu_load(struct kvm_vcpu *vcpu)
 	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
 	u64 global_status, toggle;
 
-	rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, global_status);
+	global_status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS);
 	toggle = pmu->global_status ^ global_status;
 	if (global_status & toggle)
 		wrmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, global_status & toggle);
@@ -817,7 +817,7 @@ static void intel_mediated_pmu_put(struct kvm_vcpu *vcpu)
 	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
 
 	/* MSR_CORE_PERF_GLOBAL_CTRL is already saved at VM-exit. */
-	rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, pmu->global_status);
+	pmu->global_status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS);
 
 	/* Clear hardware MSR_CORE_PERF_GLOBAL_STATUS MSR, if non-zero. */
 	if (pmu->global_status)
diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
index 771c75a58343..765cac151023 100644
--- a/arch/x86/kvm/vmx/sgx.c
+++ b/arch/x86/kvm/vmx/sgx.c
@@ -420,9 +420,9 @@ void setup_default_sgx_lepubkeyhash(void)
 		sgx_pubkey_hash[3] = 0xd4f8c05909f9bb3bULL;
 	} else {
 		/* MSR_IA32_SGXLEPUBKEYHASH0 is read above */
-		rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1, sgx_pubkey_hash[1]);
-		rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2, sgx_pubkey_hash[2]);
-		rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3, sgx_pubkey_hash[3]);
+		sgx_pubkey_hash[1] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1);
+		sgx_pubkey_hash[2] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2);
+		sgx_pubkey_hash[3] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3);
 	}
 }
 
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 2c1947e987f8..bea3c3da264b 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1245,13 +1245,13 @@ static inline void pt_save_msr(struct pt_ctx *ctx, u32 addr_range)
 {
 	u32 i;
 
-	rdmsrq(MSR_IA32_RTIT_STATUS, ctx->status);
-	rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base);
-	rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask);
-	rdmsrq(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match);
+	ctx->status = rdmsrq(MSR_IA32_RTIT_STATUS);
+	ctx->output_base = rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE);
+	ctx->output_mask = rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK);
+	ctx->cr3_match = rdmsrq(MSR_IA32_RTIT_CR3_MATCH);
 	for (i = 0; i < addr_range; i++) {
-		rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2, ctx->addr_a[i]);
-		rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2, ctx->addr_b[i]);
+		ctx->addr_a[i] = rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2);
+		ctx->addr_b[i] = rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2);
 	}
 }
 
@@ -1264,7 +1264,7 @@ static void pt_guest_enter(struct vcpu_vmx *vmx)
 	 * GUEST_IA32_RTIT_CTL is already set in the VMCS.
 	 * Save host state before VM entry.
 	 */
-	rdmsrq(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
+	vmx->pt_desc.host.ctl = rdmsrq(MSR_IA32_RTIT_CTL);
 	if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) {
 		wrmsrq(MSR_IA32_RTIT_CTL, 0);
 		pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.num_address_ranges);
@@ -1402,7 +1402,7 @@ static void vmx_prepare_switch_to_host(struct vcpu_vmx *vmx)
 	++vmx->vcpu.stat.host_state_reload;
 
 #ifdef CONFIG_X86_64
-	rdmsrq(MSR_KERNEL_GS_BASE, vmx->msr_guest_kernel_gs_base);
+	vmx->msr_guest_kernel_gs_base = rdmsrq(MSR_KERNEL_GS_BASE);
 #endif
 	if (host_state->ldt_sel || (host_state->gs_sel & 7)) {
 		kvm_load_ldt(host_state->ldt_sel);
@@ -2678,7 +2678,7 @@ static int adjust_vmx_controls(u32 ctl_min, u32 ctl_opt, u32 msr, u32 *result)
 	struct msr vmx_msr;
 	u32 ctl = ctl_min | ctl_opt;
 
-	rdmsrq(msr, vmx_msr.q);
+	vmx_msr.q = rdmsrq(msr);
 
 	ctl &= vmx_msr.h;  /* bit == 0 in high word ==> must be zero */
 	ctl |= vmx_msr.l;  /* bit == 1 in low word  ==> must be one  */
@@ -2695,7 +2695,7 @@ static u64 adjust_vmx_controls64(u64 ctl_opt, u32 msr)
 {
 	u64 allowed;
 
-	rdmsrq(msr, allowed);
+	allowed = rdmsrq(msr);
 
 	return  ctl_opt & allowed;
 }
@@ -2881,7 +2881,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
 		break;
 	}
 
-	rdmsrq(MSR_IA32_VMX_BASIC, basic_msr);
+	basic_msr = rdmsrq(MSR_IA32_VMX_BASIC);
 
 	/* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */
 	if (vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE)
@@ -2901,7 +2901,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf,
 	if (vmx_basic_vmcs_mem_type(basic_msr) != X86_MEMTYPE_WB)
 		return -EIO;
 
-	rdmsrq(MSR_IA32_VMX_MISC, misc_msr);
+	misc_msr = rdmsrq(MSR_IA32_VMX_MISC);
 
 	vmcs_conf->basic = basic_msr;
 	vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control;
@@ -4477,7 +4477,7 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx)
 
 	vmcs_writel(HOST_RIP, (unsigned long)vmx_vmexit); /* 22.2.5 */
 
-	rdmsrq(MSR_IA32_SYSENTER_CS, val.q);
+	val.q = rdmsrq(MSR_IA32_SYSENTER_CS);
 	vmcs_write32(HOST_IA32_SYSENTER_CS, val.l);
 
 	/*
@@ -4489,11 +4489,11 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx)
 	if (!IS_ENABLED(CONFIG_IA32_EMULATION) && !IS_ENABLED(CONFIG_X86_32))
 		vmcs_writel(HOST_IA32_SYSENTER_ESP, 0);
 
-	rdmsrq(MSR_IA32_SYSENTER_EIP, tmpl);
+	tmpl = rdmsrq(MSR_IA32_SYSENTER_EIP);
 	vmcs_writel(HOST_IA32_SYSENTER_EIP, tmpl);   /* 22.2.3 */
 
 	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PAT) {
-		rdmsrq(MSR_IA32_CR_PAT, val.q);
+		val.q = rdmsrq(MSR_IA32_CR_PAT);
 		vmcs_write64(HOST_IA32_PAT, val.q);
 	}
 
@@ -7151,7 +7151,7 @@ static void handle_nm_fault_irqoff(struct kvm_vcpu *vcpu)
 	 * the #NM exception.
 	 */
 	if (is_xfd_nm_fault(vcpu))
-		rdmsrq(MSR_IA32_XFD_ERR, vcpu->arch.guest_fpu.xfd_err);
+		vcpu->arch.guest_fpu.xfd_err = rdmsrq(MSR_IA32_XFD_ERR);
 }
 
 static void handle_exception_irqoff(struct kvm_vcpu *vcpu, u32 intr_info)
@@ -8042,7 +8042,7 @@ static __init u64 vmx_get_perf_capabilities(void)
 		return 0;
 
 	if (boot_cpu_has(X86_FEATURE_PDCM))
-		rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap);
+		host_perf_cap = rdmsrq(MSR_IA32_PERF_CAPABILITIES);
 
 	if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) &&
 	    !enable_mediated_pmu) {
@@ -8599,7 +8599,7 @@ __init int vmx_hardware_setup(void)
 	vmx_setup_user_return_msrs();
 
 	if (boot_cpu_has(X86_FEATURE_MPX)) {
-		rdmsrq(MSR_IA32_BNDCFGS, host_bndcfgs);
+		host_bndcfgs = rdmsrq(MSR_IA32_BNDCFGS);
 		WARN_ONCE(host_bndcfgs, "BNDCFGS in host will be lost");
 	}
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 69469bbdc84a..44d870b51d85 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3859,7 +3859,7 @@ static __always_inline void kvm_access_xstate_msr(struct kvm_vcpu *vcpu,
 
 	kvm_fpu_get();
 	if (access == MSR_TYPE_R)
-		rdmsrq(msr_info->index, msr_info->data);
+		msr_info->data = rdmsrq(msr_info->index);
 	else
 		wrmsrq(msr_info->index, msr_info->data);
 	kvm_fpu_put();
@@ -10098,7 +10098,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
 	}
 
 	if (boot_cpu_has(X86_FEATURE_SHSTK) || boot_cpu_has(X86_FEATURE_IBT)) {
-		rdmsrq(MSR_IA32_S_CET, kvm_host.s_cet);
+		kvm_host.s_cet = rdmsrq(MSR_IA32_S_CET);
 		/*
 		 * Linux doesn't yet support supervisor shadow stacks (SSS), so
 		 * KVM doesn't save/restore the associated MSRs, i.e. KVM may
@@ -10130,7 +10130,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
 	}
 
 	if (boot_cpu_has(X86_FEATURE_XSAVES)) {
-		rdmsrq(MSR_IA32_XSS, kvm_host.xss);
+		kvm_host.xss = rdmsrq(MSR_IA32_XSS);
 		kvm_caps.supported_xss = kvm_host.xss & KVM_SUPPORTED_XSS;
 	}
 
@@ -10142,7 +10142,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
 	kvm_init_pmu_capability(ops->pmu_ops);
 
 	if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
-		rdmsrq(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabilities);
+		kvm_host.arch_capabilities = rdmsrq(MSR_IA32_ARCH_CAPABILITIES);
 
 	WARN_ON_ONCE(kvm_nr_uret_msrs);
 
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
index e03eeec55cfe..b9db2012a75e 100644
--- a/arch/x86/lib/insn-eval.c
+++ b/arch/x86/lib/insn-eval.c
@@ -709,16 +709,16 @@ unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx)
 		unsigned long base;
 
 		if (seg_reg_idx == INAT_SEG_REG_FS) {
-			rdmsrq(MSR_FS_BASE, base);
+			base = rdmsrq(MSR_FS_BASE);
 		} else if (seg_reg_idx == INAT_SEG_REG_GS) {
 			/*
 			 * swapgs was called at the kernel entry point. Thus,
 			 * MSR_KERNEL_GS_BASE will have the user-space GS base.
 			 */
 			if (user_mode(regs))
-				rdmsrq(MSR_KERNEL_GS_BASE, base);
+				base = rdmsrq(MSR_KERNEL_GS_BASE);
 			else
-				rdmsrq(MSR_GS_BASE, base);
+				base = rdmsrq(MSR_GS_BASE);
 		} else {
 			base = 0;
 		}
diff --git a/arch/x86/lib/msr-smp.c b/arch/x86/lib/msr-smp.c
index 7b6cfc2c0970..ddff68050322 100644
--- a/arch/x86/lib/msr-smp.c
+++ b/arch/x86/lib/msr-smp.c
@@ -15,7 +15,7 @@ static void __rdmsr_on_cpu(void *info)
 	else
 		reg = &rv->reg;
 
-	rdmsrq(rv->msr_no, reg->q);
+	reg->q = rdmsrq(rv->msr_no);
 }
 
 static void __wrmsr_on_cpu(void *info)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index cf94fb561310..114853c212ed 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -257,7 +257,7 @@ void __init pat_bp_init(void)
 	if (!cpu_feature_enabled(X86_FEATURE_PAT))
 		pat_disable("PAT not supported by the CPU.");
 	else
-		rdmsrq(MSR_IA32_CR_PAT, pat_msr_val);
+		pat_msr_val = rdmsrq(MSR_IA32_CR_PAT);
 
 	if (!pat_msr_val) {
 		pat_disable("PAT support disabled by the firmware.");
diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
index 99b1727136c1..342371081f60 100644
--- a/arch/x86/pci/amd_bus.c
+++ b/arch/x86/pci/amd_bus.c
@@ -202,7 +202,7 @@ static int __init early_root_info_init(void)
 
 	/* need to take out [0, TOM) for RAM*/
 	address = MSR_K8_TOP_MEM1;
-	rdmsrq(address, val);
+	val = rdmsrq(address);
 	end = (val & 0xffffff800000ULL);
 	printk(KERN_INFO "TOM: %016llx aka %lldM\n", end, end>>20);
 	if (end < (1ULL<<32))
@@ -293,12 +293,12 @@ static int __init early_root_info_init(void)
 	/* need to take out [4G, TOM2) for RAM*/
 	/* SYS_CFG */
 	address = MSR_AMD64_SYSCFG;
-	rdmsrq(address, val);
+	val = rdmsrq(address);
 	/* TOP_MEM2 is enabled? */
 	if (val & (1<<21)) {
 		/* TOP_MEM2 */
 		address = MSR_K8_TOP_MEM2;
-		rdmsrq(address, val);
+		val = rdmsrq(address);
 		end = (val & 0xffffff800000ULL);
 		printk(KERN_INFO "TOM2: %016llx aka %lldM\n", end, end>>20);
 		subtract_range(range, RANGE_NUM, 1ULL<<32, end);
@@ -341,7 +341,7 @@ static int amd_bus_cpu_online(unsigned int cpu)
 {
 	u64 reg;
 
-	rdmsrq(MSR_AMD64_NB_CFG, reg);
+	reg = rdmsrq(MSR_AMD64_NB_CFG);
 	if (!(reg & ENABLE_CF8_EXT_CFG)) {
 		reg |= ENABLE_CF8_EXT_CFG;
 		wrmsrq(MSR_AMD64_NB_CFG, reg);
diff --git a/arch/x86/platform/olpc/olpc-xo1-rtc.c b/arch/x86/platform/olpc/olpc-xo1-rtc.c
index ee77d57bcab7..95dfd90b1f05 100644
--- a/arch/x86/platform/olpc/olpc-xo1-rtc.c
+++ b/arch/x86/platform/olpc/olpc-xo1-rtc.c
@@ -64,9 +64,9 @@ static int __init xo1_rtc_init(void)
 	of_node_put(node);
 
 	pr_info("olpc-xo1-rtc: Initializing OLPC XO-1 RTC\n");
-	rdmsrq(MSR_RTC_DOMA_OFFSET, rtc_info.rtc_day_alarm);
-	rdmsrq(MSR_RTC_MONA_OFFSET, rtc_info.rtc_mon_alarm);
-	rdmsrq(MSR_RTC_CEN_OFFSET, rtc_info.rtc_century);
+	rtc_info.rtc_day_alarm = rdmsrq(MSR_RTC_DOMA_OFFSET);
+	rtc_info.rtc_mon_alarm = rdmsrq(MSR_RTC_MONA_OFFSET);
+	rtc_info.rtc_century = rdmsrq(MSR_RTC_CEN_OFFSET);
 
 	r = platform_device_register(&xo1_rtc_device);
 	if (r)
diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c b/arch/x86/platform/olpc/olpc-xo1-sci.c
index 97eb4738d602..b2e12d780e58 100644
--- a/arch/x86/platform/olpc/olpc-xo1-sci.c
+++ b/arch/x86/platform/olpc/olpc-xo1-sci.c
@@ -316,7 +316,7 @@ static int setup_sci_interrupt(struct platform_device *pdev)
 	u32 sts;
 	int r;
 
-	rdmsrq(0x51400020, msr);
+	msr = rdmsrq(0x51400020);
 	sci_irq = (msr >> 20) & 15;
 
 	if (sci_irq) {
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 702f30eaf9c4..f44ebe2fe099 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -45,7 +45,7 @@ static void msr_save_context(struct saved_context *ctxt)
 
 	while (msr < end) {
 		if (msr->valid)
-			rdmsrq(msr->info.msr_no, msr->info.reg.q);
+			msr->info.reg.q = rdmsrq(msr->info.msr_no);
 		msr++;
 	}
 }
@@ -111,12 +111,12 @@ static void __save_processor_state(struct saved_context *ctxt)
 	savesegment(ds, ctxt->ds);
 	savesegment(es, ctxt->es);
 
-	rdmsrq(MSR_FS_BASE, ctxt->fs_base);
-	rdmsrq(MSR_GS_BASE, ctxt->kernelmode_gs_base);
-	rdmsrq(MSR_KERNEL_GS_BASE, ctxt->usermode_gs_base);
+	ctxt->fs_base = rdmsrq(MSR_FS_BASE);
+	ctxt->kernelmode_gs_base = rdmsrq(MSR_GS_BASE);
+	ctxt->usermode_gs_base = rdmsrq(MSR_KERNEL_GS_BASE);
 	mtrr_save_fixed_ranges(NULL);
 
-	rdmsrq(MSR_EFER, ctxt->efer);
+	ctxt->efer = rdmsrq(MSR_EFER);
 #endif
 
 	/*
diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index 694d80a5c68e..469f2aa8e105 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -147,7 +147,7 @@ static void __init setup_real_mode(void)
 	 * Some AMD processors will #GP(0) if EFER.LMA is set in WRMSR
 	 * so we need to mask it out.
 	 */
-	rdmsrq(MSR_EFER, efer);
+	efer = rdmsrq(MSR_EFER);
 	trampoline_header->efer = efer & ~EFER_LMA;
 
 	trampoline_header->start = (u64) secondary_startup_64;
diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c
index 7e9091c640be..a2e4b99d7276 100644
--- a/arch/x86/virt/hw.c
+++ b/arch/x86/virt/hw.c
@@ -178,7 +178,7 @@ static __init int __x86_vmx_init(void)
 	if (!cpu_feature_enabled(X86_FEATURE_VMX))
 		return -EOPNOTSUPP;
 
-	rdmsrq(MSR_IA32_VMX_BASIC, basic_msr);
+	basic_msr = rdmsrq(MSR_IA32_VMX_BASIC);
 
 	/* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */
 	if (WARN_ON_ONCE(vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE))
@@ -230,7 +230,7 @@ static int x86_svm_enable_virtualization_cpu(void)
 {
 	u64 efer;
 
-	rdmsrq(MSR_EFER, efer);
+	efer = rdmsrq(MSR_EFER);
 	if (efer & EFER_SVME)
 		return -EBUSY;
 
@@ -253,7 +253,7 @@ static int x86_svm_disable_virtualization_cpu(void)
 	r = 0;
 
 fault:
-	rdmsrq(MSR_EFER, efer);
+	efer = rdmsrq(MSR_EFER);
 	wrmsrq(MSR_EFER, efer & ~EFER_SVME);
 	return r;
 }
@@ -264,7 +264,7 @@ static void x86_svm_emergency_disable_virtualization_cpu(void)
 
 	virt_rebooting = true;
 
-	rdmsrq(MSR_EFER, efer);
+	efer = rdmsrq(MSR_EFER);
 	if (!(efer & EFER_SVME))
 		return;
 
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index cff285d8ad8e..4a1e75d66e6c 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -150,7 +150,7 @@ static void snp_enable(void *arg)
 	if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
 		return;
 
-	rdmsrq(MSR_AMD64_SYSCFG, val);
+	val = rdmsrq(MSR_AMD64_SYSCFG);
 
 	val |= MSR_AMD64_SYSCFG_SNP_EN;
 	val |= MSR_AMD64_SYSCFG_SNP_VMPL_EN;
@@ -254,7 +254,7 @@ static void clear_rmp(void)
 		return;
 
 	/* Clearing the RMP while SNP is enabled will cause an exception */
-	rdmsrq(MSR_AMD64_SYSCFG, val);
+	val = rdmsrq(MSR_AMD64_SYSCFG);
 	if (WARN_ON_ONCE(val & MSR_AMD64_SYSCFG_SNP_EN))
 		return;
 
@@ -520,7 +520,7 @@ int snp_prepare(void)
 	 * Check if SEV-SNP is already enabled, this can happen in case of
 	 * kexec boot.
 	 */
-	rdmsrq(MSR_AMD64_SYSCFG, val);
+	val = rdmsrq(MSR_AMD64_SYSCFG);
 	if (val & MSR_AMD64_SYSCFG_SNP_EN)
 		return 0;
 
@@ -561,7 +561,7 @@ void snp_shutdown(void)
 {
 	u64 syscfg;
 
-	rdmsrq(MSR_AMD64_SYSCFG, syscfg);
+	syscfg = rdmsrq(MSR_AMD64_SYSCFG);
 	if (syscfg & MSR_AMD64_SYSCFG_SNP_EN)
 		return;
 
@@ -608,8 +608,8 @@ static bool probe_contiguous_rmptable_info(void)
 {
 	u64 rmp_sz, rmp_base, rmp_end;
 
-	rdmsrq(MSR_AMD64_RMP_BASE, rmp_base);
-	rdmsrq(MSR_AMD64_RMP_END, rmp_end);
+	rmp_base = rdmsrq(MSR_AMD64_RMP_BASE);
+	rmp_end = rdmsrq(MSR_AMD64_RMP_END);
 
 	if (!(rmp_base & RMP_ADDR_MASK) || !(rmp_end & RMP_ADDR_MASK)) {
 		pr_err("Memory for the RMP table has not been reserved by BIOS\n");
@@ -642,13 +642,13 @@ static bool probe_segmented_rmptable_info(void)
 	unsigned int eax, ebx, segment_shift, segment_shift_min, segment_shift_max;
 	u64 rmp_base, rmp_end;
 
-	rdmsrq(MSR_AMD64_RMP_BASE, rmp_base);
+	rmp_base = rdmsrq(MSR_AMD64_RMP_BASE);
 	if (!(rmp_base & RMP_ADDR_MASK)) {
 		pr_err("Memory for the RMP table has not been reserved by BIOS\n");
 		return false;
 	}
 
-	rdmsrq(MSR_AMD64_RMP_END, rmp_end);
+	rmp_end = rdmsrq(MSR_AMD64_RMP_END);
 	WARN_ONCE(rmp_end & RMP_ADDR_MASK,
 		  "Segmented RMP enabled but RMP_END MSR is non-zero\n");
 
@@ -684,7 +684,7 @@ static bool probe_segmented_rmptable_info(void)
 bool snp_probe_rmptable_info(void)
 {
 	if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP))
-		rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
+		rmp_cfg = rdmsrq(MSR_AMD64_RMP_CFG);
 
 	if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED)
 		return probe_segmented_rmptable_info();
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 1b9ff749dd8e..9839f5b8dcc3 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -1523,7 +1523,7 @@ static void __init check_tdx_erratum(void)
 	 * Some TDX-capable CPUs have an erratum where the current VMCS is
 	 * cleared after calling into P-SEAMLDR.
 	 */
-	rdmsrq(MSR_IA32_VMX_BASIC, basic_msr);
+	basic_msr = rdmsrq(MSR_IA32_VMX_BASIC);
 	if (!(basic_msr & VMX_BASIC_NO_SEAMRET_INVD_VMCS))
 		setup_force_cpu_bug(X86_BUG_SEAMRET_INVD_VMCS);
 }
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index ba2f17e64321..b0e1152aa80e 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -56,7 +56,7 @@ static void xen_vcpu_notify_suspend(void *data)
 	tick_suspend_local();
 
 	if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
-		rdmsrq(MSR_IA32_SPEC_CTRL, tmp);
+		tmp = rdmsrq(MSR_IA32_SPEC_CTRL);
 		this_cpu_write(spec_ctrl, tmp);
 		wrmsrq(MSR_IA32_SPEC_CTRL, 0);
 	}
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 9e25d6124efd..535a0f9dd2cf 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -296,7 +296,7 @@ static void amd_fixup_frequency(struct acpi_processor_px *px, int i)
 
 	if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10) ||
 	    boot_cpu_data.x86 == 0x11) {
-		rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index, val.q);
+		val.q = rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index);
 		/*
 		 * MSR C001_0064+:
 		 * Bit 63: PstateEn. Read-write. If set, the P-state is valid.
diff --git a/drivers/ata/pata_cs5535.c b/drivers/ata/pata_cs5535.c
index e16c7f4c7c27..63a2b05ed22a 100644
--- a/drivers/ata/pata_cs5535.c
+++ b/drivers/ata/pata_cs5535.c
@@ -110,7 +110,7 @@ static void cs5535_set_piomode(struct ata_port *ap, struct ata_device *adev)
 		(u32)pio_cmd_timings[cmdmode] << 16 | pio_timings[mode]);
 
 	/* Set the PIO "format 1" bit in the DMA timing register */
-	rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg);
+	reg = rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno);
 	wrmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg | 0x80000000UL);
 }
 
@@ -132,7 +132,7 @@ static void cs5535_set_dmamode(struct ata_port *ap, struct ata_device *adev)
 	u32 reg;
 	int mode = adev->dma_mode;
 
-	rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg);
+	reg = rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno);
 	reg &= 0x80000000UL;
 	if (mode >= XFER_UDMA_0)
 		reg |= udma_timings[mode - XFER_UDMA_0];
diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c
index 61d232a82b5e..eca97dce1e85 100644
--- a/drivers/ata/pata_cs5536.c
+++ b/drivers/ata/pata_cs5536.c
@@ -84,7 +84,7 @@ static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
 {
 #ifdef MAYBE_USE_MSR
 	if (unlikely(use_msr)) {
-		rdmsrq(MSR_IDE_CFG + reg, *val);
+		*val = rdmsrq(MSR_IDE_CFG + reg);
 		return 0;
 	}
 #endif
diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c
index 3e760bc00afa..f646f1854981 100644
--- a/drivers/char/agp/nvidia-agp.c
+++ b/drivers/char/agp/nvidia-agp.c
@@ -72,8 +72,8 @@ static int nvidia_init_iorr(u32 base, u32 size)
 	/* If not found, determine the uppermost available iorr */
 	free_iorr_addr = AMD_K7_NUM_IORR;
 	for (iorr_addr = 0; iorr_addr < AMD_K7_NUM_IORR; iorr_addr++) {
-		rdmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q);
-		rdmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q);
+		base_msr.q = rdmsrq(IORR_BASE0 + 2 * iorr_addr);
+		mask_msr.q = rdmsrq(IORR_MASK0 + 2 * iorr_addr);
 
 		if ((base_msr.l & 0xfffff000) == (base & 0xfffff000))
 			break;
@@ -94,7 +94,7 @@ static int nvidia_init_iorr(u32 base, u32 size)
     wrmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q);
     wrmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q);
 
-    rdmsrq(SYSCFG, sys_msr.q);
+    sys_msr.q = rdmsrq(SYSCFG);
     sys_msr.l |= 0x00100000;
     wrmsrq(SYSCFG, sys_msr.q);
 
diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index b718e78d3c1c..a0a3488a6947 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -151,7 +151,7 @@ static int via_rng_init(struct hwrng *rng)
 	 * does not say to write them as zero, so I make a guess that
 	 * we restore the values we find in the register.
 	 */
-	rdmsrq(MSR_VIA_RNG, val.q);
+	val.q = rdmsrq(MSR_VIA_RNG);
 
 	old_lo = val.l;
 	val.l &= ~(0x7f << VIA_STRFILT_CNT_SHIFT);
@@ -175,7 +175,7 @@ static int via_rng_init(struct hwrng *rng)
 
 	/* perhaps-unnecessary sanity check; remove after testing if
 	   unneeded */
-	rdmsrq(MSR_VIA_RNG, val.q);
+	val.q = rdmsrq(MSR_VIA_RNG);
 	if ((val.l & VIA_RNG_ENABLE) == 0) {
 		pr_err(PFX "cannot enable VIA C3 RNG, aborting\n");
 		return -ENODEV;
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 10ea6035f4ad..e1ee80ecd0bb 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -110,7 +110,7 @@ static int boost_set_msr(bool enable)
 		return -EINVAL;
 	}
 
-	rdmsrq(msr_addr, val);
+	val = rdmsrq(msr_addr);
 
 	if (enable)
 		val &= ~msr_mask;
@@ -248,7 +248,7 @@ static u32 cpu_freq_read_intel(struct acpi_pct_register *not_used)
 {
 	u64 val;
 
-	rdmsrq(MSR_IA32_PERF_CTL, val);
+	val = rdmsrq(MSR_IA32_PERF_CTL);
 	return (u32)val;
 }
 
@@ -256,7 +256,7 @@ static void cpu_freq_write_intel(struct acpi_pct_register *not_used, u32 val)
 {
 	u64 msrval;
 
-	rdmsrq(MSR_IA32_PERF_CTL, msrval);
+	msrval = rdmsrq(MSR_IA32_PERF_CTL);
 	msrval = (msrval & ~(u64)INTEL_MSR_RANGE) | (val & INTEL_MSR_RANGE);
 	wrmsrq(MSR_IA32_PERF_CTL, msrval);
 }
@@ -265,7 +265,7 @@ static u32 cpu_freq_read_amd(struct acpi_pct_register *not_used)
 {
 	u64 val;
 
-	rdmsrq(MSR_AMD_PERF_CTL, val);
+	val = rdmsrq(MSR_AMD_PERF_CTL);
 	return (u32)val;
 }
 
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index d4ff8b228f86..34ba2bde0f1f 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -596,8 +596,8 @@ static inline bool amd_pstate_sample(struct amd_cpudata *cpudata)
 	unsigned long flags;
 
 	local_irq_save(flags);
-	rdmsrq(MSR_IA32_APERF, aperf);
-	rdmsrq(MSR_IA32_MPERF, mperf);
+	aperf = rdmsrq(MSR_IA32_APERF);
+	mperf = rdmsrq(MSR_IA32_MPERF);
 	tsc = rdtsc();
 
 	if (cpudata->prev.mperf == mperf || cpudata->prev.tsc == tsc) {
diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersaver.c
index 54689ebadeb2..cc05494ac316 100644
--- a/drivers/cpufreq/e_powersaver.c
+++ b/drivers/cpufreq/e_powersaver.c
@@ -99,7 +99,7 @@ static unsigned int eps_get(unsigned int cpu)
 		return 0;
 
 	/* Return current frequency */
-	rdmsrq(MSR_IA32_PERF_STATUS, val);
+	val = rdmsrq(MSR_IA32_PERF_STATUS);
 	return centaur->fsb * ((val >> 8) & 0xff);
 }
 
@@ -111,11 +111,11 @@ static int eps_set_state(struct eps_cpu_data *centaur,
 	int i;
 
 	/* Wait while CPU is busy */
-	rdmsrq(MSR_IA32_PERF_STATUS, val);
+	val = rdmsrq(MSR_IA32_PERF_STATUS);
 	i = 0;
 	while (val & ((1 << 16) | (1 << 17))) {
 		udelay(16);
-		rdmsrq(MSR_IA32_PERF_STATUS, val);
+		val = rdmsrq(MSR_IA32_PERF_STATUS);
 		i++;
 		if (unlikely(i > 64)) {
 			return -ENODEV;
@@ -127,7 +127,7 @@ static int eps_set_state(struct eps_cpu_data *centaur,
 	i = 0;
 	do {
 		udelay(16);
-		rdmsrq(MSR_IA32_PERF_STATUS, val);
+		val = rdmsrq(MSR_IA32_PERF_STATUS);
 		i++;
 		if (unlikely(i > 64)) {
 			return -ENODEV;
@@ -139,7 +139,7 @@ static int eps_set_state(struct eps_cpu_data *centaur,
 	u8 current_multiplier, current_voltage;
 
 	/* Print voltage and multiplier */
-	rdmsrq(MSR_IA32_PERF_STATUS, val);
+	val = rdmsrq(MSR_IA32_PERF_STATUS);
 	current_voltage = val & 0xff;
 	pr_info("Current voltage = %dmV\n", current_voltage * 16 + 700);
 	current_multiplier = (val >> 8) & 0xff;
@@ -194,12 +194,12 @@ static int eps_cpu_init(struct cpufreq_policy *policy)
 
 	switch (c->x86_model) {
 	case 10:
-		rdmsrq(0x1153, val);
+		val = rdmsrq(0x1153);
 		brand = (((val >> 2) ^ val) >> 18) & 3;
 		pr_cont("Model A ");
 		break;
 	case 13:
-		rdmsrq(0x1154, val);
+		val = rdmsrq(0x1154);
 		brand = (((val >> 4) ^ (val >> 2))) & 0x000000ff;
 		pr_cont("Model D ");
 		break;
@@ -223,12 +223,12 @@ static int eps_cpu_init(struct cpufreq_policy *policy)
 		return -ENODEV;
 	}
 	/* Enable Enhanced PowerSaver */
-	rdmsrq(MSR_IA32_MISC_ENABLE, val);
+	val = rdmsrq(MSR_IA32_MISC_ENABLE);
 	if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
 		val |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP;
 		wrmsrq(MSR_IA32_MISC_ENABLE, val);
 		/* Can be locked at 0 */
-		rdmsrq(MSR_IA32_MISC_ENABLE, val);
+		val = rdmsrq(MSR_IA32_MISC_ENABLE);
 		if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
 			pr_info("Can't enable Enhanced PowerSaver\n");
 			return -ENODEV;
@@ -236,7 +236,7 @@ static int eps_cpu_init(struct cpufreq_policy *policy)
 	}
 
 	/* Print voltage and multiplier */
-	rdmsrq(MSR_IA32_PERF_STATUS, val);
+	val = rdmsrq(MSR_IA32_PERF_STATUS);
 	current_voltage = val & 0xff;
 	pr_info("Current voltage = %dmV\n", current_voltage * 16 + 700);
 	current_multiplier = (val >> 8) & 0xff;
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 7ce5981cbae5..2ea55a1f6cc2 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -600,7 +600,7 @@ static bool turbo_is_disabled(void)
 {
 	u64 misc_en;
 
-	rdmsrq(MSR_IA32_MISC_ENABLE, misc_en);
+	misc_en = rdmsrq(MSR_IA32_MISC_ENABLE);
 
 	return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
 }
@@ -1391,7 +1391,7 @@ static void set_power_ctl_ee_state(bool input)
 
 	guard(mutex)(&intel_pstate_driver_lock);
 
-	rdmsrq(MSR_IA32_POWER_CTL, power_ctl);
+	power_ctl = rdmsrq(MSR_IA32_POWER_CTL);
 	if (input) {
 		power_ctl &= ~BIT(MSR_IA32_POWER_CTL_BIT_EE);
 		power_ctl_ee_state = POWER_CTL_EE_ENABLE;
@@ -1768,7 +1768,7 @@ static ssize_t show_energy_efficiency(struct kobject *kobj, struct kobj_attribut
 	u64 power_ctl;
 	int enable;
 
-	rdmsrq(MSR_IA32_POWER_CTL, power_ctl);
+	power_ctl = rdmsrq(MSR_IA32_POWER_CTL);
 	enable = !!(power_ctl & BIT(MSR_IA32_POWER_CTL_BIT_EE));
 	return sprintf(buf, "%d\n", !enable);
 }
@@ -2062,7 +2062,7 @@ static int atom_get_min_pstate(int not_used)
 {
 	u64 value;
 
-	rdmsrq(MSR_ATOM_CORE_RATIOS, value);
+	value = rdmsrq(MSR_ATOM_CORE_RATIOS);
 	return (value >> 8) & 0x7F;
 }
 
@@ -2070,7 +2070,7 @@ static int atom_get_max_pstate(int not_used)
 {
 	u64 value;
 
-	rdmsrq(MSR_ATOM_CORE_RATIOS, value);
+	value = rdmsrq(MSR_ATOM_CORE_RATIOS);
 	return (value >> 16) & 0x7F;
 }
 
@@ -2078,7 +2078,7 @@ static int atom_get_turbo_pstate(int not_used)
 {
 	u64 value;
 
-	rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS, value);
+	value = rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS);
 	return value & 0x7F;
 }
 
@@ -2109,7 +2109,7 @@ static int silvermont_get_scaling(void)
 	static int silvermont_freq_table[] = {
 		83300, 100000, 133300, 116700, 80000};
 
-	rdmsrq(MSR_FSB_FREQ, value);
+	value = rdmsrq(MSR_FSB_FREQ);
 	i = value & 0x7;
 	WARN_ON(i > 4);
 
@@ -2125,7 +2125,7 @@ static int airmont_get_scaling(void)
 		83300, 100000, 133300, 116700, 80000,
 		93300, 90000, 88900, 87500};
 
-	rdmsrq(MSR_FSB_FREQ, value);
+	value = rdmsrq(MSR_FSB_FREQ);
 	i = value & 0xF;
 	WARN_ON(i > 8);
 
@@ -2136,7 +2136,7 @@ static void atom_get_vid(struct cpudata *cpudata)
 {
 	u64 value;
 
-	rdmsrq(MSR_ATOM_CORE_VIDS, value);
+	value = rdmsrq(MSR_ATOM_CORE_VIDS);
 	cpudata->vid.min = int_tofp((value >> 8) & 0x7f);
 	cpudata->vid.max = int_tofp((value >> 16) & 0x7f);
 	cpudata->vid.ratio = div_fp(
@@ -2144,7 +2144,7 @@ static void atom_get_vid(struct cpudata *cpudata)
 		int_tofp(cpudata->pstate.max_pstate -
 			cpudata->pstate.min_pstate));
 
-	rdmsrq(MSR_ATOM_CORE_TURBO_VIDS, value);
+	value = rdmsrq(MSR_ATOM_CORE_TURBO_VIDS);
 	cpudata->vid.turbo = value & 0x7f;
 }
 
@@ -2456,8 +2456,8 @@ static inline bool intel_pstate_sample(struct cpudata *cpu, u64 time)
 	u64 tsc;
 
 	local_irq_save(flags);
-	rdmsrq(MSR_IA32_APERF, aperf);
-	rdmsrq(MSR_IA32_MPERF, mperf);
+	aperf = rdmsrq(MSR_IA32_APERF);
+	mperf = rdmsrq(MSR_IA32_MPERF);
 	tsc = rdtsc();
 	if (cpu->prev_mperf == mperf || cpu->prev_tsc == tsc) {
 		local_irq_restore(flags);
@@ -3646,7 +3646,7 @@ static bool __init intel_pstate_platform_pwr_mgmt_exists(void)
 
 	id = x86_match_cpu(intel_pstate_cpu_oob_ids);
 	if (id) {
-		rdmsrq(MSR_MISC_PWR_MGMT, misc_pwr);
+		misc_pwr = rdmsrq(MSR_MISC_PWR_MGMT);
 		if (misc_pwr & BITMASK_OOB) {
 			pr_debug("Bit 8 or 18 in the MISC_PWR_MGMT MSR set\n");
 			pr_debug("P states are controlled in Out of Band mode by the firmware/hardware\n");
@@ -3702,7 +3702,7 @@ static bool intel_pstate_hwp_is_enabled(void)
 {
 	u64 value;
 
-	rdmsrq(MSR_PM_ENABLE, value);
+	value = rdmsrq(MSR_PM_ENABLE);
 	return !!(value & 0x1);
 }
 
@@ -3767,7 +3767,7 @@ static bool hwp_check_dec(void)
 {
 	u64 power_ctl;
 
-	rdmsrq(MSR_IA32_POWER_CTL, power_ctl);
+	power_ctl = rdmsrq(MSR_IA32_POWER_CTL);
 	return !!(power_ctl & BIT(POWER_CTL_DEC_ENABLE));
 }
 
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index 4c2599264333..9bc0acc0ea69 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -121,7 +121,7 @@ static int longhaul_get_cpu_mult(void)
 	unsigned long invalue = 0;
 	u64 val;
 
-	rdmsrq(MSR_IA32_EBL_CR_POWERON, val);
+	val = rdmsrq(MSR_IA32_EBL_CR_POWERON);
 	invalue = (val & (1<<22|1<<23|1<<24|1<<25))>>22;
 	if (longhaul_version == TYPE_LONGHAUL_V2 ||
 	    longhaul_version == TYPE_POWERSAVER) {
@@ -137,7 +137,7 @@ static void do_longhaul1(unsigned int mults_index)
 {
 	union msr_bcr2 bcr2;
 
-	rdmsrq(MSR_VIA_BCR2, bcr2.val);
+	bcr2.val = rdmsrq(MSR_VIA_BCR2);
 	/* Enable software clock multiplier */
 	bcr2.bits.ESOFTBF = 1;
 	bcr2.bits.CLOCKMUL = mults_index & 0xff;
@@ -152,7 +152,7 @@ static void do_longhaul1(unsigned int mults_index)
 
 	/* Disable software clock multiplier */
 	local_irq_disable();
-	rdmsrq(MSR_VIA_BCR2, bcr2.val);
+	bcr2.val = rdmsrq(MSR_VIA_BCR2);
 	bcr2.bits.ESOFTBF = 0;
 	wrmsrq(MSR_VIA_BCR2, bcr2.val);
 }
@@ -165,7 +165,7 @@ static void do_powersaver(int cx_address, unsigned int mults_index,
 	union msr_longhaul longhaul;
 	u32 t;
 
-	rdmsrq(MSR_VIA_LONGHAUL, longhaul.val);
+	longhaul.val = rdmsrq(MSR_VIA_LONGHAUL);
 	/* Setup new frequency */
 	if (!revid_errata)
 		longhaul.bits.RevisionKey = longhaul.bits.RevisionID;
@@ -534,7 +534,7 @@ static void longhaul_setup_voltagescaling(void)
 	unsigned int j, speed, pos, kHz_step, numvscales;
 	int min_vid_speed;
 
-	rdmsrq(MSR_VIA_LONGHAUL, longhaul.val);
+	longhaul.val = rdmsrq(MSR_VIA_LONGHAUL);
 	if (!(longhaul.bits.RevisionID & 1)) {
 		pr_info("Voltage scaling not supported by CPU\n");
 		return;
@@ -836,7 +836,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)
 	}
 	/* Check Longhaul ver. 2 */
 	if (longhaul_version == TYPE_LONGHAUL_V2) {
-		rdmsrq(MSR_VIA_LONGHAUL, val);
+		val = rdmsrq(MSR_VIA_LONGHAUL);
 		if (val == 0)
 			/* Looks like MSR isn't present */
 			longhaul_version = TYPE_LONGHAUL_V1;
diff --git a/drivers/cpufreq/longrun.c b/drivers/cpufreq/longrun.c
index 82a7bb69c401..4b7e624ae1e5 100644
--- a/drivers/cpufreq/longrun.c
+++ b/drivers/cpufreq/longrun.c
@@ -37,14 +37,14 @@ static void longrun_get_policy(struct cpufreq_policy *policy)
 {
 	struct msr msr;
 
-	rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q);
+	msr.q = rdmsrq(MSR_TMTA_LONGRUN_FLAGS);
 	pr_debug("longrun flags are %x - %x\n", msr.l, msr.h);
 	if (msr.l & 0x01)
 		policy->policy = CPUFREQ_POLICY_PERFORMANCE;
 	else
 		policy->policy = CPUFREQ_POLICY_POWERSAVE;
 
-	rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q);
+	msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL);
 	pr_debug("longrun ctrl is %x - %x\n", msr.l, msr.h);
 	msr.l &= 0x0000007F;
 	msr.h &= 0x0000007F;
@@ -93,7 +93,7 @@ static int longrun_set_policy(struct cpufreq_policy *policy)
 		pctg_lo = pctg_hi;
 
 	/* performance or economy mode */
-	rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q);
+	msr.q = rdmsrq(MSR_TMTA_LONGRUN_FLAGS);
 	msr.l &= 0xFFFFFFFE;
 	switch (policy->policy) {
 	case CPUFREQ_POLICY_PERFORMANCE:
@@ -105,7 +105,7 @@ static int longrun_set_policy(struct cpufreq_policy *policy)
 	wrmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q);
 
 	/* lower and upper boundary */
-	rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q);
+	msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL);
 	msr.l &= 0xFFFFFF80;
 	msr.h &= 0xFFFFFF80;
 	msr.l |= pctg_lo;
@@ -177,16 +177,16 @@ static int longrun_determine_freqs(unsigned int *low_freq,
 		 * For maximum frequency, read out level zero.
 		 */
 		/* minimum */
-		rdmsrq(MSR_TMTA_LRTI_READOUT, msr.q);
+		msr.q = rdmsrq(MSR_TMTA_LRTI_READOUT);
 		msr.l = msr.h;
 		wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q);
-		rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q);
+		msr.q = rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ);
 		*low_freq = msr.l * 1000; /* to kHz */
 
 		/* maximum */
 		msr.l = 0;
 		wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q);
-		rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q);
+		msr.q = rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ);
 		*high_freq = msr.l * 1000; /* to kHz */
 
 		pr_debug("longrun table interface told %u - %u kHz\n",
@@ -203,7 +203,7 @@ static int longrun_determine_freqs(unsigned int *low_freq,
 	pr_debug("high frequency is %u kHz\n", *high_freq);
 
 	/* get current borders */
-	rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q);
+	msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL);
 	save.l = msr.l & 0x0000007F;
 	save.h = msr.h & 0x0000007F;
 
diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c
index 6a930d7e6a5c..1df2a8f365a3 100644
--- a/drivers/cpufreq/powernow-k7.c
+++ b/drivers/cpufreq/powernow-k7.c
@@ -220,7 +220,7 @@ static void change_FID(int fid)
 {
 	union msr_fidvidctl fidvidctl;
 
-	rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val);
+	fidvidctl.val = rdmsrq(MSR_K7_FID_VID_CTL);
 	if (fidvidctl.bits.FID != fid) {
 		fidvidctl.bits.SGTC = latency;
 		fidvidctl.bits.FID = fid;
@@ -235,7 +235,7 @@ static void change_VID(int vid)
 {
 	union msr_fidvidctl fidvidctl;
 
-	rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val);
+	fidvidctl.val = rdmsrq(MSR_K7_FID_VID_CTL);
 	if (fidvidctl.bits.VID != vid) {
 		fidvidctl.bits.SGTC = latency;
 		fidvidctl.bits.VID = vid;
@@ -261,7 +261,7 @@ static int powernow_target(struct cpufreq_policy *policy, unsigned int index)
 	fid = powernow_table[index].driver_data & 0xFF;
 	vid = (powernow_table[index].driver_data & 0xFF00) >> 8;
 
-	rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val);
+	fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS);
 	cfid = fidvidstatus.bits.CFID;
 	freqs.old = fsb * fid_codes[cfid] / 10;
 
@@ -558,7 +558,7 @@ static unsigned int powernow_get(unsigned int cpu)
 
 	if (cpu)
 		return 0;
-	rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val);
+	fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS);
 	cfid = fidvidstatus.bits.CFID;
 
 	return fsb * fid_codes[cfid] / 10;
@@ -599,7 +599,7 @@ static int powernow_cpu_init(struct cpufreq_policy *policy)
 	if (policy->cpu != 0)
 		return -ENODEV;
 
-	rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val);
+	fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS);
 
 	recalibrate_cpu_khz();
 
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index c9bcc6f0ab7b..6097dc3e5a89 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -89,7 +89,7 @@ static int pending_bit_stuck(void)
 {
 	u64 msr;
 
-	rdmsrq(MSR_FIDVID_STATUS, msr);
+	msr = rdmsrq(MSR_FIDVID_STATUS);
 	return msr & MSR_S_LO_CHANGE_PENDING ? 1 : 0;
 }
 
@@ -107,7 +107,7 @@ static int query_current_values_with_pending_wait(struct powernow_k8_data *data)
 			pr_debug("detected change pending stuck\n");
 			return 1;
 		}
-		rdmsrq(MSR_FIDVID_STATUS, msr.q);
+		msr.q = rdmsrq(MSR_FIDVID_STATUS);
 	} while (msr.l & MSR_S_LO_CHANGE_PENDING);
 
 	data->currvid = msr.h & MSR_S_HI_CURRENT_VID;
@@ -134,7 +134,7 @@ static void fidvid_msr_init(void)
 	struct msr msr;
 	u8 fid, vid;
 
-	rdmsrq(MSR_FIDVID_STATUS, msr.q);
+	msr.q = rdmsrq(MSR_FIDVID_STATUS);
 	vid = msr.h & MSR_S_HI_CURRENT_VID;
 	fid = msr.l & MSR_S_LO_CURRENT_FID;
 	msr.l = fid | (vid << MSR_C_LO_VID_SHIFT);
@@ -293,7 +293,7 @@ static int core_voltage_pre_transition(struct powernow_k8_data *data,
 	if ((savefid < LO_FID_TABLE_TOP) && (reqfid < LO_FID_TABLE_TOP))
 		rvomult = 2;
 	rvosteps *= rvomult;
-	rdmsrq(MSR_FIDVID_STATUS, msr.q);
+	msr.q = rdmsrq(MSR_FIDVID_STATUS);
 	maxvid = 0x1f & (msr.h >> 16);
 	pr_debug("ph1 maxvid=0x%x\n", maxvid);
 	if (reqvid < maxvid) /* lower numbers are higher voltages */
diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c
index de50fb367c6b..2e90b658bfc2 100644
--- a/drivers/cpufreq/speedstep-centrino.c
+++ b/drivers/cpufreq/speedstep-centrino.c
@@ -378,7 +378,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy)
 
 	/* Check to see if Enhanced SpeedStep is enabled, and try to
 	   enable it if not. */
-	rdmsrq(MSR_IA32_MISC_ENABLE, q);
+	q = rdmsrq(MSR_IA32_MISC_ENABLE);
 
 	if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
 		q |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP;
@@ -386,7 +386,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy)
 		wrmsrq(MSR_IA32_MISC_ENABLE, q);
 
 		/* check to see if it stuck */
-		rdmsrq(MSR_IA32_MISC_ENABLE, q);
+		q = rdmsrq(MSR_IA32_MISC_ENABLE);
 		if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
 			pr_info("couldn't enable Enhanced SpeedStep\n");
 			return -ENODEV;
diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/cpufreq/speedstep-lib.c
index 2afc3f177a29..188d459c7e2a 100644
--- a/drivers/cpufreq/speedstep-lib.c
+++ b/drivers/cpufreq/speedstep-lib.c
@@ -74,7 +74,7 @@ static unsigned int pentium3_get_frequency(enum speedstep_processor processor)
 	int i = 0, j = 0;
 
 	/* read MSR 0x2a - we only need the low 32 bits */
-	rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q);
+	msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON);
 	pr_debug("P3 - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h);
 	msr_tmp = msr_lo = msr.l;
 
@@ -112,7 +112,7 @@ static unsigned int pentiumM_get_frequency(void)
 	struct msr msr;
 	u32 msr_tmp;
 
-	rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q);
+	msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON);
 	pr_debug("PM - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h);
 
 	/* see table B-2 of 24547212.pdf */
@@ -136,7 +136,7 @@ static unsigned int pentium_core_get_frequency(void)
 	u32 msr_tmp;
 	int ret;
 
-	rdmsrq(MSR_FSB_FREQ, msr.q);
+	msr.q = rdmsrq(MSR_FSB_FREQ);
 	/* see table B-2 of 25366920.pdf */
 	switch (msr.l & 0x07) {
 	case 5:
@@ -161,7 +161,7 @@ static unsigned int pentium_core_get_frequency(void)
 		pr_err("PCORE - MSR_FSB_FREQ undefined value\n");
 	}
 
-	rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q);
+	msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON);
 	pr_debug("PCORE - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n",
 			msr.l, msr.h);
 
@@ -191,7 +191,7 @@ static unsigned int pentium4_get_frequency(void)
 	if (c->x86_model < 2)
 		return cpu_khz;
 
-	rdmsrq(0x2c, msr.q);
+	msr.q = rdmsrq(0x2c);
 
 	pr_debug("P4 - MSR_EBC_FREQUENCY_ID: 0x%x 0x%x\n", msr.l, msr.h);
 
@@ -348,7 +348,7 @@ enum speedstep_processor speedstep_detect_processor(void)
 
 		/* all mobile PIII Coppermines have FSB 100 MHz
 		 * ==> sort out a few desktop PIIIs. */
-		rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q);
+		msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON);
 		pr_debug("Coppermine: MSR_IA32_EBL_CR_POWERON is 0x%x, 0x%x\n",
 				msr.l, msr.h);
 		msr.l &= 0x00c0000;
@@ -361,7 +361,7 @@ enum speedstep_processor speedstep_detect_processor(void)
 		 * it has SpeedStep technology if either
 		 * bit 56 or 57 is set
 		 */
-		rdmsrq(MSR_IA32_PLATFORM_ID, msr.q);
+		msr.q = rdmsrq(MSR_IA32_PLATFORM_ID);
 		pr_debug("Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\n",
 				msr.l, msr.h);
 		if ((msr.h & (1<<18)) &&
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index c6aa69dbd9fb..ef2fc2be954a 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2956,13 +2956,13 @@ static void dct_read_mc_regs(struct amd64_pvt *pvt)
 	 * Retrieve TOP_MEM and TOP_MEM2; no masking off of reserved bits since
 	 * those are Read-As-Zero.
 	 */
-	rdmsrq(MSR_K8_TOP_MEM1, pvt->top_mem);
+	pvt->top_mem = rdmsrq(MSR_K8_TOP_MEM1);
 	edac_dbg(0, "  TOP_MEM:  0x%016llx\n", pvt->top_mem);
 
 	/* Check first whether TOP_MEM2 is enabled: */
-	rdmsrq(MSR_AMD64_SYSCFG, msr_val);
+	msr_val = rdmsrq(MSR_AMD64_SYSCFG);
 	if (msr_val & BIT(21)) {
-		rdmsrq(MSR_K8_TOP_MEM2, pvt->top_mem2);
+		pvt->top_mem2 = rdmsrq(MSR_K8_TOP_MEM2);
 		edac_dbg(0, "  TOP_MEM2: 0x%016llx\n", pvt->top_mem2);
 	} else {
 		edac_dbg(0, "  TOP_MEM2 disabled\n");
diff --git a/drivers/gpio/gpio-cs5535.c b/drivers/gpio/gpio-cs5535.c
index a97ec7561889..e9cc577e94b7 100644
--- a/drivers/gpio/gpio-cs5535.c
+++ b/drivers/gpio/gpio-cs5535.c
@@ -148,7 +148,7 @@ int cs5535_gpio_set_irq(unsigned group, unsigned irq)
 	if (group > 7 || irq > 15)
 		return -EINVAL;
 
-	rdmsrq(MSR_PIC_ZSEL_HIGH, val.q);
+	val.q = rdmsrq(MSR_PIC_ZSEL_HIGH);
 
 	val.l &= ~(0xF << (group * 4));
 	val.l |= (irq & 0xF) << (group * 4);
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 6e3c11c68171..f678eda1641c 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -599,7 +599,7 @@ static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set)
 			if (set)
 				wrmsrq(reg_table[i].msr_addr, *reg64);
 			else
-				rdmsrq(reg_table[i].msr_addr, *reg64);
+				*reg64 = rdmsrq(reg_table[i].msr_addr);
 		}
 		return 0;
 	}
diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c
index dee42c163d92..cfb3a2975de4 100644
--- a/drivers/hwmon/hwmon-vid.c
+++ b/drivers/hwmon/hwmon-vid.c
@@ -243,10 +243,10 @@ static u8 get_via_model_d_vrm(void)
 		"C7-M", "C7", "Eden", "C7-D"
 	};
 
-	rdmsrq(0x198, msr);
+	msr = rdmsrq(0x198);
 	vid = (msr >> 32) & 0xff;
 
-	rdmsrq(0x1154, msr);
+	msr = rdmsrq(0x1154);
 	brand = ((msr >> 4) ^ (msr >> 2)) & 0x03;
 
 	if (vid > 0x3f) {
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 651408df9c24..82faaf771b2d 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -2125,35 +2125,35 @@ static void __init bxt_idle_state_table_update(void)
 	unsigned long long msr;
 	unsigned int usec;
 
-	rdmsrq(MSR_PKGC6_IRTL, msr);
+	msr = rdmsrq(MSR_PKGC6_IRTL);
 	usec = irtl_2_usec(msr);
 	if (usec) {
 		bxt_cstates[2].exit_latency = usec;
 		bxt_cstates[2].target_residency = usec;
 	}
 
-	rdmsrq(MSR_PKGC7_IRTL, msr);
+	msr = rdmsrq(MSR_PKGC7_IRTL);
 	usec = irtl_2_usec(msr);
 	if (usec) {
 		bxt_cstates[3].exit_latency = usec;
 		bxt_cstates[3].target_residency = usec;
 	}
 
-	rdmsrq(MSR_PKGC8_IRTL, msr);
+	msr = rdmsrq(MSR_PKGC8_IRTL);
 	usec = irtl_2_usec(msr);
 	if (usec) {
 		bxt_cstates[4].exit_latency = usec;
 		bxt_cstates[4].target_residency = usec;
 	}
 
-	rdmsrq(MSR_PKGC9_IRTL, msr);
+	msr = rdmsrq(MSR_PKGC9_IRTL);
 	usec = irtl_2_usec(msr);
 	if (usec) {
 		bxt_cstates[5].exit_latency = usec;
 		bxt_cstates[5].target_residency = usec;
 	}
 
-	rdmsrq(MSR_PKGC10_IRTL, msr);
+	msr = rdmsrq(MSR_PKGC10_IRTL);
 	usec = irtl_2_usec(msr);
 	if (usec) {
 		bxt_cstates[6].exit_latency = usec;
@@ -2181,7 +2181,7 @@ static void __init sklh_idle_state_table_update(void)
 	if ((mwait_substates & (0xF << 28)) == 0)
 		return;
 
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr);
+	msr = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 
 	/* PC10 is not enabled in PKG C-state limit */
 	if ((msr & 0xF) != 8)
@@ -2193,7 +2193,7 @@ static void __init sklh_idle_state_table_update(void)
 	/* if SGX is present */
 	if (ebx & (1 << 2)) {
 
-		rdmsrq(MSR_IA32_FEAT_CTL, msr);
+		msr = rdmsrq(MSR_IA32_FEAT_CTL);
 
 		/* if SGX is enabled */
 		if (msr & (1 << 18))
@@ -2213,7 +2213,7 @@ static bool __init skx_is_pc6_disabled(void)
 {
 	u64 msr;
 
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr);
+	msr = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 
 	/*
 	 * 000b: C0/C1 (no package C-state support)
@@ -2467,7 +2467,7 @@ static void auto_demotion_disable(void)
 {
 	unsigned long long msr_bits;
 
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits);
+	msr_bits = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 	msr_bits &= ~auto_demotion_disable_flags;
 	wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits);
 }
@@ -2476,7 +2476,7 @@ static void c1e_promotion_enable(void)
 {
 	unsigned long long msr_bits;
 
-	rdmsrq(MSR_IA32_POWER_CTL, msr_bits);
+	msr_bits = rdmsrq(MSR_IA32_POWER_CTL);
 	msr_bits |= 0x2;
 	wrmsrq(MSR_IA32_POWER_CTL, msr_bits);
 }
@@ -2485,7 +2485,7 @@ static void c1e_promotion_disable(void)
 {
 	unsigned long long msr_bits;
 
-	rdmsrq(MSR_IA32_POWER_CTL, msr_bits);
+	msr_bits = rdmsrq(MSR_IA32_POWER_CTL);
 	msr_bits &= ~0x2;
 	wrmsrq(MSR_IA32_POWER_CTL, msr_bits);
 }
@@ -2554,7 +2554,7 @@ static void intel_c1_demotion_toggle(void *enable)
 {
 	unsigned long long msr_val;
 
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val);
+	msr_val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 	/*
 	 * Enable/disable C1 undemotion along with C1 demotion, as this is the
 	 * most sensible configuration in general.
@@ -2594,7 +2594,7 @@ static ssize_t intel_c1_demotion_show(struct device *dev,
 	 * Read the MSR value for a CPU and assume it is the same for all CPUs. Any other
 	 * configuration would be a BIOS bug.
 	 */
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val);
+	msr_val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 	return sysfs_emit(buf, "%d\n", !!(msr_val & NHM_C1_AUTO_DEMOTE));
 }
 static DEVICE_ATTR_RW(intel_c1_demotion);
diff --git a/drivers/misc/cs5535-mfgpt.c b/drivers/misc/cs5535-mfgpt.c
index 9abfc44f70f4..9006b59858ff 100644
--- a/drivers/misc/cs5535-mfgpt.c
+++ b/drivers/misc/cs5535-mfgpt.c
@@ -83,7 +83,7 @@ int cs5535_mfgpt_toggle_event(struct cs5535_mfgpt_timer *timer, int cmp,
 		return -EIO;
 	}
 
-	rdmsrq(msr, val.q);
+	val.q = rdmsrq(msr);
 
 	if (enable)
 		val.l |= mask;
@@ -114,7 +114,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *timer, int cmp, int *irq,
 	 * IRQ of the 1st. This can only happen if forcing an IRQ, calling this
 	 * with *irq==0 is safe. Currently there _are_ no 2 drivers.
 	 */
-	rdmsrq(MSR_PIC_ZSEL_LOW, zsel.q);
+	zsel.q = rdmsrq(MSR_PIC_ZSEL_LOW);
 	shift = ((cmp == MFGPT_CMP1 ? 0 : 4) + timer->nr % 4) * 4;
 	if (((zsel.l >> shift) & 0xF) == 2)
 		return -EIO;
@@ -128,7 +128,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *timer, int cmp, int *irq,
 	/* Can't use IRQ if it's 0 (=disabled), 2, or routed to LPC */
 	if (*irq < 1 || *irq == 2 || *irq > 15)
 		return -EIO;
-	rdmsrq(MSR_PIC_IRQM_LPC, lpc.q);
+	lpc.q = rdmsrq(MSR_PIC_IRQM_LPC);
 	if (lpc.l & (1 << *irq))
 		return -EIO;
 
diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs553x_nand.c
index 0b872b1e3b04..2ed13666b48f 100644
--- a/drivers/mtd/nand/raw/cs553x_nand.c
+++ b/drivers/mtd/nand/raw/cs553x_nand.c
@@ -351,20 +351,20 @@ static int __init cs553x_init(void)
 		return -ENXIO;
 
 	/* If it doesn't have the CS553[56], abort */
-	rdmsrq(MSR_DIVIL_GLD_CAP, val);
+	val = rdmsrq(MSR_DIVIL_GLD_CAP);
 	val &= ~0xFFULL;
 	if (val != CAP_CS5535 && val != CAP_CS5536)
 		return -ENXIO;
 
 	/* If it doesn't have the NAND controller enabled, abort */
-	rdmsrq(MSR_DIVIL_BALL_OPTS, val);
+	val = rdmsrq(MSR_DIVIL_BALL_OPTS);
 	if (val & PIN_OPT_IDE) {
 		pr_info("CS553x NAND controller: Flash I/O not enabled in MSR_DIVIL_BALL_OPTS.\n");
 		return -ENXIO;
 	}
 
 	for (i = 0; i < NR_CS553X_CONTROLLERS; i++) {
-		rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i, val);
+		val = rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i);
 
 		if ((val & (FLSH_LBAR_EN|FLSH_NOR_NAND)) == (FLSH_LBAR_EN|FLSH_NOR_NAND))
 			err = cs553x_init_one(i, !!(val & FLSH_MEM_IO), val & 0xFFFFFFFF);
diff --git a/drivers/platform/x86/intel/ifs/load.c b/drivers/platform/x86/intel/ifs/load.c
index 50f1fdf7dfed..6320a0e45d38 100644
--- a/drivers/platform/x86/intel/ifs/load.c
+++ b/drivers/platform/x86/intel/ifs/load.c
@@ -129,7 +129,7 @@ static void copy_hashes_authenticate_chunks(struct work_struct *work)
 	msrs = ifs_get_test_msrs(dev);
 	/* run scan hash copy */
 	wrmsrq(msrs->copy_hashes, ifs_hash_ptr);
-	rdmsrq(msrs->copy_hashes_status, hashes_status.data);
+	hashes_status.data = rdmsrq(msrs->copy_hashes_status);
 
 	/* enumerate the scan image information */
 	num_chunks = hashes_status.num_chunks;
@@ -151,7 +151,7 @@ static void copy_hashes_authenticate_chunks(struct work_struct *work)
 		linear_addr |= i;
 
 		wrmsrq(msrs->copy_chunks, linear_addr);
-		rdmsrq(msrs->copy_chunks_status, chunk_status.data);
+		chunk_status.data = rdmsrq(msrs->copy_chunks_status);
 
 		ifsd->valid_chunks = chunk_status.valid_chunks;
 		err_code = chunk_status.error_code;
@@ -197,7 +197,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev)
 
 	if (need_copy_scan_hashes(ifsd)) {
 		wrmsrq(msrs->copy_hashes, ifs_hash_ptr);
-		rdmsrq(msrs->copy_hashes_status, hashes_status.data);
+		hashes_status.data = rdmsrq(msrs->copy_hashes_status);
 
 		/* enumerate the scan image information */
 		chunk_size = hashes_status.chunk_size * SZ_1K;
@@ -218,7 +218,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev)
 
 	if (ifsd->generation >= IFS_GEN_STRIDE_AWARE) {
 		wrmsrq(msrs->test_ctrl, INVALIDATE_STRIDE);
-		rdmsrq(msrs->copy_chunks_status, chunk_status.data);
+		chunk_status.data = rdmsrq(msrs->copy_chunks_status);
 		if (chunk_status.valid_chunks != 0) {
 			dev_err(dev, "Couldn't invalidate installed stride - %d\n",
 				chunk_status.valid_chunks);
@@ -241,7 +241,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev)
 			local_irq_disable();
 			wrmsrq(msrs->copy_chunks, (u64)chunk_table);
 			local_irq_enable();
-			rdmsrq(msrs->copy_chunks_status, chunk_status.data);
+			chunk_status.data = rdmsrq(msrs->copy_chunks_status);
 			err_code = chunk_status.error_code;
 		} while (err_code == AUTH_INTERRUPTED_ERROR && --retry_count);
 
diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/x86/intel/ifs/runtest.c
index dfc119d7354d..46e1ea944ce7 100644
--- a/drivers/platform/x86/intel/ifs/runtest.c
+++ b/drivers/platform/x86/intel/ifs/runtest.c
@@ -211,7 +211,7 @@ static int doscan(void *data)
 	 * are processed in a single pass) before it retires.
 	 */
 	wrmsrq(MSR_ACTIVATE_SCAN, params->activate->data);
-	rdmsrq(MSR_SCAN_STATUS, status.data);
+	status.data = rdmsrq(MSR_SCAN_STATUS);
 
 	trace_ifs_status(ifsd->cur_batch, start, stop, status.data);
 
@@ -324,7 +324,7 @@ static int do_array_test(void *data)
 	if (cpu == first) {
 		wrmsrq(MSR_ARRAY_BIST, command->data);
 		/* Pass back the result of the test */
-		rdmsrq(MSR_ARRAY_BIST, command->data);
+		command->data = rdmsrq(MSR_ARRAY_BIST);
 	}
 
 	return 0;
@@ -376,7 +376,7 @@ static int do_array_test_gen1(void *status)
 
 	if (cpu == first) {
 		wrmsrq(MSR_ARRAY_TRIGGER, ARRAY_GEN1_TEST_ALL_ARRAYS);
-		rdmsrq(MSR_ARRAY_STATUS, *((u64 *)status));
+		*((u64 *)status) = rdmsrq(MSR_ARRAY_STATUS);
 	}
 
 	return 0;
@@ -528,7 +528,7 @@ static int dosbaf(void *data)
 	 * during the "execution" of the WRMSR.
 	 */
 	wrmsrq(MSR_ACTIVATE_SBAF, run_params->activate->data);
-	rdmsrq(MSR_SBAF_STATUS, status.data);
+	status.data = rdmsrq(MSR_SBAF_STATUS);
 	trace_ifs_sbaf(ifsd->cur_batch, *run_params->activate, status);
 
 	/* Pass back the result of the test */
diff --git a/drivers/platform/x86/intel/pmc/cnp.c b/drivers/platform/x86/intel/pmc/cnp.c
index efea4e1ba52b..44979e680361 100644
--- a/drivers/platform/x86/intel/pmc/cnp.c
+++ b/drivers/platform/x86/intel/pmc/cnp.c
@@ -228,7 +228,7 @@ static void disable_c1_auto_demote(void *unused)
 	int cpunum = smp_processor_id();
 	u64 val;
 
-	rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, val);
+	val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL);
 	per_cpu(pkg_cst_config, cpunum) = val;
 	val &= ~NHM_C1_AUTO_DEMOTE;
 	wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, val);
diff --git a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
index 22745b217c6f..909c9e25112d 100644
--- a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
+++ b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
@@ -40,7 +40,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter,
 	/* Poll for rb bit == 0 */
 	retries = OS_MAILBOX_RETRY_COUNT;
 	do {
-		rdmsrq(MSR_OS_MAILBOX_INTERFACE, data);
+		data = rdmsrq(MSR_OS_MAILBOX_INTERFACE);
 		if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) {
 			ret = -EBUSY;
 			continue;
@@ -65,7 +65,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter,
 	/* Poll for rb bit == 0 */
 	retries = OS_MAILBOX_RETRY_COUNT;
 	do {
-		rdmsrq(MSR_OS_MAILBOX_INTERFACE, data);
+		data = rdmsrq(MSR_OS_MAILBOX_INTERFACE);
 		if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) {
 			ret = -EBUSY;
 			continue;
@@ -75,7 +75,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter,
 			return -ENXIO;
 
 		if (response_data) {
-			rdmsrq(MSR_OS_MAILBOX_DATA, data);
+			data = rdmsrq(MSR_OS_MAILBOX_DATA);
 			*response_data = data;
 		}
 		ret = 0;
diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
index 5ded0e25b6c7..2b86e9969aef 100644
--- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
+++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
@@ -561,7 +561,7 @@ static bool disable_dynamic_sst_features(void)
 	if (!cpu_feature_enabled(X86_FEATURE_HWP))
 		return true;
 
-	rdmsrq(MSR_PM_ENABLE, value);
+	value = rdmsrq(MSR_PM_ENABLE);
 	return !(value & 0x1);
 }
 
diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c
index b1b2d9caba7b..79c07f23ba0b 100644
--- a/drivers/platform/x86/intel_ips.c
+++ b/drivers/platform/x86/intel_ips.c
@@ -370,7 +370,7 @@ static void ips_cpu_raise(struct ips_driver *ips)
 	if (!ips->cpu_turbo_enabled)
 		return;
 
-	rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override);
+	turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT);
 
 	cur_tdp_limit = turbo_override & TURBO_TDP_MASK;
 	new_tdp_limit = cur_tdp_limit + 8; /* 1W increase */
@@ -405,7 +405,7 @@ static void ips_cpu_lower(struct ips_driver *ips)
 	u64 turbo_override;
 	u16 cur_limit, new_limit;
 
-	rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override);
+	turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT);
 
 	cur_limit = turbo_override & TURBO_TDP_MASK;
 	new_limit = cur_limit - 8; /* 1W decrease */
@@ -437,7 +437,7 @@ static void do_enable_cpu_turbo(void *data)
 {
 	u64 perf_ctl;
 
-	rdmsrq(IA32_PERF_CTL, perf_ctl);
+	perf_ctl = rdmsrq(IA32_PERF_CTL);
 	if (perf_ctl & IA32_PERF_TURBO_DIS) {
 		perf_ctl &= ~IA32_PERF_TURBO_DIS;
 		wrmsrq(IA32_PERF_CTL, perf_ctl);
@@ -475,7 +475,7 @@ static void do_disable_cpu_turbo(void *data)
 {
 	u64 perf_ctl;
 
-	rdmsrq(IA32_PERF_CTL, perf_ctl);
+	perf_ctl = rdmsrq(IA32_PERF_CTL);
 	if (!(perf_ctl & IA32_PERF_TURBO_DIS)) {
 		perf_ctl |= IA32_PERF_TURBO_DIS;
 		wrmsrq(IA32_PERF_CTL, perf_ctl);
@@ -1215,7 +1215,7 @@ static int cpu_clamp_show(struct seq_file *m, void *data)
 	u64 turbo_override;
 	int tdp, tdc;
 
-	rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override);
+	turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT);
 
 	tdp = (int)(turbo_override & TURBO_TDP_MASK);
 	tdc = (int)((turbo_override & TURBO_TDC_MASK) >> TURBO_TDC_SHIFT);
@@ -1290,7 +1290,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct ips_driver *ips)
 		return NULL;
 	}
 
-	rdmsrq(IA32_MISC_ENABLE, misc_en);
+	misc_en = rdmsrq(IA32_MISC_ENABLE);
 	/*
 	 * If the turbo enable bit isn't set, we shouldn't try to enable/disable
 	 * turbo manually or we'll get an illegal MSR access, even though
@@ -1312,7 +1312,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct ips_driver *ips)
 		return NULL;
 	}
 
-	rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_power);
+	turbo_power = rdmsrq(TURBO_POWER_CURRENT_LIMIT);
 	tdp = turbo_power & TURBO_TDP_MASK;
 
 	/* Sanity check TDP against CPU */
@@ -1496,7 +1496,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	 * Check PLATFORM_INFO MSR to make sure this chip is
 	 * turbo capable.
 	 */
-	rdmsrq(PLATFORM_INFO, platform_info);
+	platform_info = rdmsrq(PLATFORM_INFO);
 	if (!(platform_info & PLATFORM_TDP)) {
 		dev_err(&dev->dev, "platform indicates TDP override unavailable, aborting\n");
 		return -ENODEV;
@@ -1529,7 +1529,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	ips->mgta_val = thm_readw(THM_MGTA);
 
 	/* Save turbo limits & ratios */
-	rdmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit);
+	ips->orig_turbo_limit = rdmsrq(TURBO_POWER_CURRENT_LIMIT);
 
 	ips_disable_cpu_turbo(ips);
 	ips->cpu_turbo_enabled = false;
@@ -1596,7 +1596,7 @@ static void ips_remove(struct pci_dev *dev)
 	if (ips->gpu_turbo_disable)
 		symbol_put(i915_gpu_turbo_disable);
 
-	rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override);
+	turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT);
 	turbo_override &= ~(TURBO_TDC_OVR_EN | TURBO_TDP_OVR_EN);
 	wrmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override);
 	wrmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit);
diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c
index a34543e66446..5d840de67c2b 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -176,7 +176,7 @@ static int rapl_msr_read_raw(int cpu, struct reg_action *ra, bool pmu_ctx)
 	 * from any CPU in the package.
 	 */
 	if (pmu_ctx) {
-		rdmsrq(ra->reg.msr, ra->value);
+		ra->value = rdmsrq(ra->reg.msr);
 		goto out;
 	}
 
diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/intel_hfi.c
index 3273b8fe3d4d..6b2801aaa745 100644
--- a/drivers/thermal/intel/intel_hfi.c
+++ b/drivers/thermal/intel/intel_hfi.c
@@ -285,7 +285,7 @@ void intel_hfi_process_event(__u64 pkg_therm_status_msr_val)
 	if (!raw_spin_trylock(&hfi_instance->event_lock))
 		return;
 
-	rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr);
+	msr = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS);
 	hfi = msr & PACKAGE_THERM_STATUS_HFI_UPDATED;
 	if (!hfi) {
 		raw_spin_unlock(&hfi_instance->event_lock);
@@ -357,7 +357,7 @@ static void hfi_enable(void)
 {
 	u64 msr_val;
 
-	rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val);
+	msr_val = rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG);
 	msr_val |= HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT;
 	wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val);
 }
@@ -378,7 +378,7 @@ static void hfi_disable(void)
 	u64 msr_val;
 	int i;
 
-	rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val);
+	msr_val = rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG);
 	msr_val &= ~HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT;
 	wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val);
 
@@ -389,7 +389,7 @@ static void hfi_disable(void)
 	 * memory.
 	 */
 	for (i = 0; i < 2000; i++) {
-		rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val);
+		msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS);
 		if (msr_val & PACKAGE_THERM_STATUS_HFI_UPDATED)
 			break;
 
diff --git a/drivers/thermal/intel/therm_throt.c b/drivers/thermal/intel/therm_throt.c
index 4d4e81601d17..3ead57f45510 100644
--- a/drivers/thermal/intel/therm_throt.c
+++ b/drivers/thermal/intel/therm_throt.c
@@ -297,7 +297,7 @@ static void get_therm_status(int level, bool *proc_hot, u8 *temp)
 	else
 		msr = MSR_IA32_PACKAGE_THERM_STATUS;
 
-	rdmsrq(msr, msr_val);
+	msr_val = rdmsrq(msr);
 	if (msr_val & THERM_STATUS_PROCHOT_LOG)
 		*proc_hot = true;
 	else
@@ -543,7 +543,7 @@ static int check_directed_thermal_pkg_intr_ack(void)
 	 * Wait 15ms to be safe.
 	 */
 	do {
-		rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val);
+		msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS);
 		udelay(1);
 	} while (!(msr_val & PACKAGE_THERM_STATUS_DPTI_ACK) && --count);
 
@@ -561,7 +561,7 @@ static void config_directed_thermal_pkg_intr(void *info)
 	bool enable = *((bool *)info);
 	u64 msr_val;
 
-	rdmsrq(MSR_IA32_THERM_INTERRUPT, msr_val);
+	msr_val = rdmsrq(MSR_IA32_THERM_INTERRUPT);
 
 	if (enable)
 		msr_val |= THERM_INT_DPTI_ENABLE;
@@ -931,7 +931,7 @@ void intel_thermal_interrupt(void)
 	if (cpu_feature_enabled(X86_FEATURE_HWP))
 		notify_hwp_interrupt();
 
-	rdmsrq(MSR_IA32_THERM_STATUS, msr_val);
+	msr_val = rdmsrq(MSR_IA32_THERM_STATUS);
 
 	/* Check for violation of core thermal thresholds*/
 	notify_thresholds(msr_val);
@@ -946,7 +946,7 @@ void intel_thermal_interrupt(void)
 					CORE_LEVEL);
 
 	if (this_cpu_has(X86_FEATURE_PTS)) {
-		rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val);
+		msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS);
 		/* check violations of package thermal thresholds */
 		notify_package_thresholds(msr_val);
 		therm_throt_process(msr_val & PACKAGE_THERM_STATUS_PROCHOT,
@@ -1004,7 +1004,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 	 * be some SMM goo which handles it, so we can't even put a handler
 	 * since it might be delivered via SMI already:
 	 */
-	rdmsrq(MSR_IA32_MISC_ENABLE, val.q);
+	val.q = rdmsrq(MSR_IA32_MISC_ENABLE);
 
 	val.h = lvtthmr_init;
 	/*
@@ -1030,7 +1030,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 	/* early Pentium M models use different method for enabling TM2 */
 	if (cpu_has(c, X86_FEATURE_TM2)) {
 		if (c->x86 == 6 && (c->x86_model == 9 || c->x86_model == 13)) {
-			rdmsrq(MSR_THERM2_CTL, val.q);
+			val.q = rdmsrq(MSR_THERM2_CTL);
 			if (val.l & MSR_THERM2_CTL_TM_SELECT)
 				tm2 = 1;
 		} else if (val.l & MSR_IA32_MISC_ENABLE_TM2)
@@ -1044,7 +1044,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 	thermal_intr_init_core_clear_mask();
 	thermal_intr_init_pkg_clear_mask();
 
-	rdmsrq(MSR_IA32_THERM_INTERRUPT, val.q);
+	val.q = rdmsrq(MSR_IA32_THERM_INTERRUPT);
 	if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) {
 		val.l |= THERM_INT_LOW_ENABLE | THERM_INT_HIGH_ENABLE;
 		val.l &= ~THERM_INT_PLN_ENABLE;
@@ -1056,7 +1056,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 	wrmsrq(MSR_IA32_THERM_INTERRUPT, val.q);
 
 	if (cpu_has(c, X86_FEATURE_PTS)) {
-		rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q);
+		val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT);
 		if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) {
 			val.l |= PACKAGE_THERM_INT_LOW_ENABLE |
 				 PACKAGE_THERM_INT_HIGH_ENABLE;
@@ -1071,13 +1071,13 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 		wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q);
 
 		if (cpu_has(c, X86_FEATURE_HFI)) {
-			rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q);
+			val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT);
 			wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT,
 			       val.q | PACKAGE_THERM_INT_HFI_ENABLE);
 		}
 	}
 
-	rdmsrq(MSR_IA32_MISC_ENABLE, val.q);
+	val.q = rdmsrq(MSR_IA32_MISC_ENABLE);
 	wrmsrq(MSR_IA32_MISC_ENABLE, val.q | MSR_IA32_MISC_ENABLE_TM1);
 
 	pr_info_once("CPU0: Thermal monitoring enabled (%s)\n",
diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c b/drivers/thermal/intel/x86_pkg_temp_thermal.c
index 43fd5bdf1d8d..11ca647802dc 100644
--- a/drivers/thermal/intel/x86_pkg_temp_thermal.c
+++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c
@@ -187,7 +187,7 @@ static inline void enable_pkg_thres_interrupt(void)
 	u8 thres_0, thres_1;
 	struct msr val;
 
-	rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q);
+	val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT);
 	/* only enable/disable if it had valid threshold value */
 	thres_0 = (val.l & THERM_MASK_THRESHOLD0) >> THERM_SHIFT_THRESHOLD0;
 	thres_1 = (val.l & THERM_MASK_THRESHOLD1) >> THERM_SHIFT_THRESHOLD1;
@@ -203,7 +203,7 @@ static inline void disable_pkg_thres_interrupt(void)
 {
 	struct msr val;
 
-	rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q);
+	val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT);
 
 	val.l &= ~(THERM_INT_THRESHOLD0_ENABLE | THERM_INT_THRESHOLD1_ENABLE);
 	wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q);
@@ -356,7 +356,7 @@ static int pkg_temp_thermal_device_add(unsigned int cpu)
 		goto out_unregister_tz;
 
 	/* Store MSR value for package thermal interrupt, to restore at exit */
-	rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, zonedev->msr_pkg_therm);
+	zonedev->msr_pkg_therm = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT);
 
 	cpumask_set_cpu(cpu, &zonedev->cpumask);
 	raw_spin_lock_irq(&pkg_temp_lock);
diff --git a/drivers/video/fbdev/geode/display_gx.c b/drivers/video/fbdev/geode/display_gx.c
index b93aa21a1d2b..511cb7bf98e9 100644
--- a/drivers/video/fbdev/geode/display_gx.c
+++ b/drivers/video/fbdev/geode/display_gx.c
@@ -26,7 +26,7 @@ unsigned int gx_frame_buffer_size(void)
 		struct msr msr;
 
 		/* The number of pages is (PMAX - PMIN)+1 */
-		rdmsrq(MSR_GLIU_P2D_RO0, msr.q);
+		msr.q = rdmsrq(MSR_GLIU_P2D_RO0);
 
 		/* PMAX */
 		val = ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >> 20);
diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c
index 8d69be7c9d31..e0a3447f2b1b 100644
--- a/drivers/video/fbdev/geode/gxfb_core.c
+++ b/drivers/video/fbdev/geode/gxfb_core.c
@@ -378,7 +378,7 @@ static int gxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 
 	/* Figure out if this is a TFT or CRT part */
 
-	rdmsrq(MSR_GX_GLD_MSR_CONFIG, val);
+	val = rdmsrq(MSR_GX_GLD_MSR_CONFIG);
 
 	if ((val & MSR_GX_GLD_MSR_CONFIG_FP) == MSR_GX_GLD_MSR_CONFIG_FP)
 		par->enable_crt = 0;
diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/geode/lxfb_ops.c
index f5f1134cae9a..980a782214a2 100644
--- a/drivers/video/fbdev/geode/lxfb_ops.c
+++ b/drivers/video/fbdev/geode/lxfb_ops.c
@@ -127,7 +127,7 @@ static void lx_set_dotpll(u32 pllval)
 	struct msr dotpll;
 	int i;
 
-	rdmsrq(MSR_GLCP_DOTPLL, dotpll.q);
+	dotpll.q = rdmsrq(MSR_GLCP_DOTPLL);
 
 	if ((dotpll.l & MSR_GLCP_DOTPLL_LOCK) && (dotpll.h == pllval))
 		return;
@@ -145,7 +145,7 @@ static void lx_set_dotpll(u32 pllval)
 	/* Now, loop for the lock bit */
 
 	for (i = 0; i < 1000; i++) {
-		rdmsrq(MSR_GLCP_DOTPLL, dotpll.q);
+		dotpll.q = rdmsrq(MSR_GLCP_DOTPLL);
 		if (dotpll.l & MSR_GLCP_DOTPLL_LOCK)
 			break;
 	}
@@ -316,7 +316,7 @@ unsigned int lx_framebuffer_size(void)
 		struct msr msr;
 
 		/* The number of pages is (PMAX - PMIN)+1 */
-		rdmsrq(MSR_GLIU_P2D_RO0, msr.q);
+		msr.q = rdmsrq(MSR_GLIU_P2D_RO0);
 
 		/* PMAX */
 		val = ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >> 20);
@@ -359,7 +359,7 @@ void lx_set_mode(struct fb_info *info)
 
 	/* Set output mode */
 
-	rdmsrq(MSR_LX_GLD_MSR_CONFIG, msrval);
+	msrval = rdmsrq(MSR_LX_GLD_MSR_CONFIG);
 	msrval &= ~MSR_LX_GLD_MSR_CONFIG_FMT;
 
 	if (par->output & OUTPUT_PANEL) {
@@ -420,7 +420,7 @@ void lx_set_mode(struct fb_info *info)
 
 	/* Set default watermark values */
 
-	rdmsrq(MSR_LX_SPARE_MSR, msrval);
+	msrval = rdmsrq(MSR_LX_SPARE_MSR);
 
 	msrval &= ~(MSR_LX_SPARE_MSR_DIS_CFIFO_HGO
 			| MSR_LX_SPARE_MSR_VFIFO_ARB_SEL
@@ -592,10 +592,10 @@ static void lx_save_regs(struct lxfb_par *par)
 	} while ((i & GP_BLT_STATUS_PB) || !(i & GP_BLT_STATUS_CE));
 
 	/* save MSRs */
-	rdmsrq(MSR_LX_MSR_PADSEL, par->msr.padsel);
-	rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll);
-	rdmsrq(MSR_LX_GLD_MSR_CONFIG, par->msr.dfglcfg);
-	rdmsrq(MSR_LX_SPARE_MSR, par->msr.dcspare);
+	par->msr.padsel = rdmsrq(MSR_LX_MSR_PADSEL);
+	par->msr.dotpll = rdmsrq(MSR_GLCP_DOTPLL);
+	par->msr.dfglcfg = rdmsrq(MSR_LX_GLD_MSR_CONFIG);
+	par->msr.dcspare = rdmsrq(MSR_LX_SPARE_MSR);
 
 	write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK);
 
diff --git a/drivers/video/fbdev/geode/suspend_gx.c b/drivers/video/fbdev/geode/suspend_gx.c
index 6c0a526ee8a2..2fa20acba62e 100644
--- a/drivers/video/fbdev/geode/suspend_gx.c
+++ b/drivers/video/fbdev/geode/suspend_gx.c
@@ -21,8 +21,8 @@ static void gx_save_regs(struct gxfb_par *par)
 	} while (i & (GP_BLT_STATUS_BLT_PENDING | GP_BLT_STATUS_BLT_BUSY));
 
 	/* save MSRs */
-	rdmsrq(MSR_GX_MSR_PADSEL, par->msr.padsel);
-	rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll);
+	par->msr.padsel = rdmsrq(MSR_GX_MSR_PADSEL);
+	par->msr.dotpll = rdmsrq(MSR_GLCP_DOTPLL);
 
 	write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK);
 
@@ -43,7 +43,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi)
 	struct msr dotpll;
 	int i;
 
-	rdmsrq(MSR_GLCP_DOTPLL, dotpll.q);
+	dotpll.q = rdmsrq(MSR_GLCP_DOTPLL);
 	dotpll.l |= MSR_GLCP_DOTPLL_DOTRESET;
 	dotpll.l &= ~MSR_GLCP_DOTPLL_BYPASS;
 	dotpll.h = dotpll_hi;
@@ -51,7 +51,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi)
 
 	/* wait for the PLL to lock */
 	for (i = 0; i < 200; i++) {
-		rdmsrq(MSR_GLCP_DOTPLL, dotpll.q);
+		dotpll.q = rdmsrq(MSR_GLCP_DOTPLL);
 		if (dotpll.l & MSR_GLCP_DOTPLL_LOCK)
 			break;
 		udelay(1);
diff --git a/drivers/video/fbdev/geode/video_gx.c b/drivers/video/fbdev/geode/video_gx.c
index 5717c3356949..b2cfadaf3ff8 100644
--- a/drivers/video/fbdev/geode/video_gx.c
+++ b/drivers/video/fbdev/geode/video_gx.c
@@ -142,8 +142,8 @@ void gx_set_dclk_frequency(struct fb_info *info)
 		}
 	}
 
-	rdmsrq(MSR_GLCP_SYS_RSTPLL, sys_rstpll);
-	rdmsrq(MSR_GLCP_DOTPLL, dotpll);
+	sys_rstpll = rdmsrq(MSR_GLCP_SYS_RSTPLL);
+	dotpll = rdmsrq(MSR_GLCP_DOTPLL);
 
 	/* Program new M, N and P. */
 	dotpll &= 0x00000000ffffffffull;
@@ -167,7 +167,7 @@ void gx_set_dclk_frequency(struct fb_info *info)
 
 	/* Wait for LOCK bit. */
 	do {
-		rdmsrq(MSR_GLCP_DOTPLL, dotpll);
+		dotpll = rdmsrq(MSR_GLCP_DOTPLL);
 	} while (timeout-- && !(dotpll & MSR_GLCP_DOTPLL_LOCK));
 }
 
@@ -180,7 +180,7 @@ gx_configure_tft(struct fb_info *info)
 
 	/* Set up the DF pad select MSR */
 
-	rdmsrq(MSR_GX_MSR_PADSEL, val);
+	val = rdmsrq(MSR_GX_MSR_PADSEL);
 	val &= ~MSR_GX_MSR_PADSEL_MASK;
 	val |= MSR_GX_MSR_PADSEL_TFT;
 	wrmsrq(MSR_GX_MSR_PADSEL, val);
diff --git a/include/linux/cs5535.h b/include/linux/cs5535.h
index 5ec2aca537bb..fef236cab7d8 100644
--- a/include/linux/cs5535.h
+++ b/include/linux/cs5535.h
@@ -51,7 +51,7 @@ static inline int cs5535_pic_unreqz_select_high(unsigned int group,
 {
 	struct msr val;
 
-	rdmsrq(MSR_PIC_ZSEL_HIGH, val.q);
+	val.q = rdmsrq(MSR_PIC_ZSEL_HIGH);
 	val.l &= ~(0xF << (group * 4));
 	val.l |= (irq & 0xF) << (group * 4);
 	wrmsrq(MSR_PIC_ZSEL_HIGH, val.q);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:39:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:39:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395139.1633641 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdhk-0003XZ-3I; Wed, 19 Aug 2026 10:39:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395139.1633641; Wed, 19 Aug 2026 10:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdhj-0003XS-VH; Wed, 19 Aug 2026 10:39:31 +0000
Received: by outflank-mailman (input) for mailman id 1395139;
 Wed, 19 Aug 2026 10:39:30 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wwdhi-0003XM-4z
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:39:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwdhh-009luq-EW
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:39:29 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8587df-8faa-0a2a0a5109dd-0a2a450a8ba0-8
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:39:29 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8587e1-f2d2-0a2a450a0019-d155802eccf5-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:39:29 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4955aa106b1so8864795e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 03:39:29 -0700 (PDT)
Received: from [192.168.1.109] ([78.173.117.23])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0dd620sm47520725e9.13.2026.08.19.03.39.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 03:39:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787135969; x=1787740769; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=1AsA94VpHp480uzR+EFVVpqM0pDpJec2bgTbAJQQLnk=;
        b=VMojKCULcRb9k0u4x0fAMpmEBOqBGnE+hJiTffbrUYV+80YYsme4kotTC3GGkbx+05
         U8lPHvtYP6yLREcKovcNJo+VZzPAFXiqJRmLBnwojZLEhHOvlvEiHMMiqEAi9iEyr9ew
         5e/2SjcWJFY/ofZ7om3FgQFjzgoLBiRg8n9ZRT1MiVdfvlCoJgeMud7kwcmHiOncixcu
         AOy0fKkZAmP/ICRDbL6mKZStVSFPR77/xmqstaT3VBLx0fzqHArKeP5nSUWGWQeCwAi0
         mQKFrEDCAsNDpmmoMrfuoOel4aDZROgjgjU4NLpog/p4GF0VMlQ3tDi2qB8XBy+YwI40
         E9PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787135969; x=1787740769;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=1AsA94VpHp480uzR+EFVVpqM0pDpJec2bgTbAJQQLnk=;
        b=R9tbzCBKeC5iaanWm0fMkJ7GDF1AcCLIv+JQhU4PoHpWFLMLYK4XtZHdyFhU99YUJY
         qxh5Pm2E5pojm4Hm7JhDfH5kkKaHnJyn6gD7FMukOvigBBJgHT6rjF6+sKsIOBAacZEB
         JK/hz7w/t1yoVReG6+n/lUACMM+63Z2kAiYbvPgNkxu2M/G23yA14x9IXLrZhp6f9XKh
         raG3/54SdE5Y0bYFQtYo0aHtVGy67LyIrJpY05rmECIVqMULbkqTIz0+VQ246cQR6cqw
         WI+iAzsO0Nd6vBPF4j1d/z0xtq7Kmd0DiWD2qsMS41n57sSiGQnzye3JiO5os6deZ6yH
         Rqfg==
X-Forwarded-Encrypted: i=1; AHgh+RpWox8lJAgBd3YwovQ/jB/e+hyDazhu7g7a1TtLPTWSwMIw4QxLmLKFelJ4FgNo+MxJFSPVwBz3YWk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxTJRp7YnigLI7NxT8MpY3yxrNzzoWrPkMpAYdrwxwRtDH2hr4S
	cco4FqMSxIu6bCqZj16VxlRYQmqC3jzZAyRq05ae5GViFLzuYcYx7Z+U
X-Gm-Gg: AR+sD11XNGdP3qrFGTsgJL3iWxYAzzbFvh/QVrPw/CJgqtMUvY+577ursZ78HfOLcUg
	j7wmY7bBaFMu+zbX7XGJwVsWfVZ0n/o2yR2mUIRF0lqb9BIkGc5qQSRxrBcqUtRGPovSJUsxfGr
	AYOMZFG81nw47d0DahodQLoYkiZ5ksF45pG/ZQBjLIYfIH06FQ3WDq0in3i+nRH/PdtKvjuNsie
	GfGdNXnlP7jcK72eWhn/ovd7mouUkRnDilQQsOcsHypjkd9sHJ1UoDIH61/HE7tyiRbMKf4Gftf
	e1OCzcFuYZDS3a3C9T+vui5Bvh3cM0BlpqK7NvzfJwrDqvODzzOHiHJAZUyeK7CMcke1CBJYCop
	83suxsI3LlA0L/JyLtEu6Lret7TGe88tfRoIpmW1iwqaikg/Fi3gpSQbpmyFGqFpLLRrZX5sW4L
	I7va6DZMIJukvNP1q631lFJeBgW2Cb0ZzqIMLUChLVMy8YMAUudNzPLHsg5dsF8PRAw08=
X-Received: by 2002:a05:600c:8b27:b0:493:c47f:3c55 with SMTP id 5b1f17b1804b1-499aa199601mr74656405e9.5.1787135968713;
        Wed, 19 Aug 2026 03:39:28 -0700 (PDT)
Message-ID: <e0f91d0e-0b08-4d69-bf94-243bd26f67df@gmail.com>
Date: Wed, 19 Aug 2026 13:39:23 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Jan Beulich <jbeulich@suse.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787135969-508CDCFC-F3FF276F/0/0
X-purgate-type: clean
X-purgate-size: 3732



On 8/19/26 10:22, Jan Beulich wrote:
> On 19.08.2026 07:15, Furkan Caliskan wrote:
>> sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
>> singleshot_timer and poll_timer before it can fail -- these
>> become live, linked into their target pCPU's per-cpu timer list
>> regardless of what happens next. If the sched_alloc_udata() call
>> further down then fails, the function frees the sched_unit via
>> sched_free_unit() and returns 1, but never unlinks these three
>> timers.
>>
>> The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
>> returning nonzero it jumps to fail_wq, skipping fail_sched and
>> thus sched_destroy_vcpu() -- the only function on this path that
>> calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
>> and the three timers embedded in it, while they are still linked
>> into that shared list.
>>
>> This silently corrupts that list. It only shows up later, when
>> something else touches a neighboring timer: sched_move_domain()
>> crashed with "Assertion 'entry->prev->next == entry' failed" on a
>> completely unrelated, valid vcpu's timer.
>>
>> Kill all three timers in sched_init_vcpu()'s own failure branch,
>> so it doesn't depend on the caller reaching sched_destroy_vcpu()
>> to undo what it set up itself.
>>
>> Fixes: 1ad5dad74cde ("[XEN] Re-jig VCPU initialisation -- VMX init requires generic VCPU")
> 
> How did you arrive at this commit? It doesn't even touch sched_init_vcpu().
> All it does is move kill_timer() invocations around. I think it's
> d884b1077817, as that's where the "return SCHED_OP(init_vcpu, v)" was
> introduced (i.e. where kill_timer() would have been necessary to call in
> the error case). (I can't exclude the issue was pre-existing already at
> that time, but that would require more analysis than I think is worth to
> invest.)
> 
>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
>>      unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
>>      if ( unit->priv == NULL )
>>      {
>> +        kill_timer(&v->periodic_timer);
>> +        kill_timer(&v->singleshot_timer);
>> +        kill_timer(&v->poll_timer);
>>          sched_free_unit(unit, v);
>>          rcu_read_unlock(&sched_res_rculock);
>>          return 1;
> 
> This almost, but not quite open-codes sched_destroy_vcpu(). Would be nice
> if the cleanup logic was shared. The sched_free_unit() call there could be
> leveraged here as well; what would need skipping are the sched_free_udata()
> and sched_remove_unit(). And of course the RCU-locking would need sorting.
> 
> Jan

Would something like below be okay?

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d3a0a97e1d..36704a5836 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -589,8 +589,8 @@ int sched_init_vcpu(struct vcpu *v)
     unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
     if ( unit->priv == NULL )
     {
-        sched_free_unit(unit, v);
         rcu_read_unlock(&sched_res_rculock);
+        sched_destroy_vcpu(v);
         return 1;
     }
 
@@ -869,8 +869,11 @@ void sched_destroy_vcpu(struct vcpu *v)
     {
         rcu_read_lock(&sched_res_rculock);
 
-        sched_remove_unit(vcpu_scheduler(v), unit);
-        sched_free_udata(vcpu_scheduler(v), unit->priv);
+        if ( unit->priv )
+        {
+            sched_remove_unit(vcpu_scheduler(v), unit);
+            sched_free_udata(vcpu_scheduler(v), unit->priv);
+        }
         sched_free_unit(unit, v);
 
         rcu_read_unlock(&sched_res_rculock);


Furkan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 10:44:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 10:44:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395150.1633648 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdm6-00051w-I3; Wed, 19 Aug 2026 10:44:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395150.1633648; Wed, 19 Aug 2026 10:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwdm6-00051p-F7; Wed, 19 Aug 2026 10:44:02 +0000
Received: by outflank-mailman (input) for mailman id 1395150;
 Wed, 19 Aug 2026 10:44:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwdm5-00051j-1w
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 10:44:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwdm4-009n3j-EC
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:44:00 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8588d8-8faa-0a2a0a5109dd-0a2a450be52c-30
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:44:00 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8588f0-b7e8-0a2a450b0019-d155dd2bb84d-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 12:44:00 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47362928f65so781991f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 03:44:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14d059bsm4462722f8f.36.2026.08.19.03.43.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 03:43:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787136240; x=1787741040; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=kfpqXzda9pGcVGMV68pff/PmOJj4RBlw1c2TOpv5JoE=;
        b=LlKQjQWObQyqBSxz0gZg/PbRxjO8BdXfOBc/D7yOm/foGaHF2tkdyVoJsdbwwo95Fm
         265CLRTKaY2Qvv6RMcZlLjfzvZt7E65sEiOKKBjeNEwrB8b2vl5+DZuIwzRA/2otX/a8
         lPedJTgF2iewJpYQw8Yr+EQyBZoTvoNNIcp48joUeJFm21b1KYt0DHUoMhBxQWW6jmQS
         JLo9UxlMqIufsL9KNfOXH22F2ktPF9F6+wCmb2ra/cXsxa2TcIv5lmmVNkQaI89hkANu
         ohC9Yn21+BYYdE89uNRF+UBlJfBgj/dQMZgq1w7oHkL5hOW1CIU2ofTDyynZqWQBlFiL
         tzlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787136240; x=1787741040;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=kfpqXzda9pGcVGMV68pff/PmOJj4RBlw1c2TOpv5JoE=;
        b=rlIKFqa6gCFa907flm7cRKmxYfZMKjMoG0y/EYWNXpN4Qo1HeeMsheWRlPm6YH2gnC
         zTxxrVe734C/vhrtAhYJVQOL/SmJvSVauiMYcSQGHpiJfc8R8k0oMQ+Hh+k1pQdRPy9T
         U9+9NtSBQiRWxTHLH3a8ShPX7GHoUv80edqU/CSgaDgjOfCqXrG9pUFXf0C14wKvdtxC
         xCoah3Dojw5CTE28tLf53HSDSHXGJ+IrO/gwoVcFdcywnmp7hoEF+34CYDxjKLT6gHh7
         MVf8Q9ewu4nh5Xoqt9kmncTUGYKsKRdO8gWo3F09iT/b2nGaUmFrEEwlX1Fu168an3Tb
         kRnQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr4a5I7Jaz9H1QiU71x3S91xrgjGQmBZlMCWcmVQEUEzBTdCWb/SIir2QroumZUN83Y/g80aZi8rPI=@lists.xenproject.org
X-Gm-Message-State: AFuF++lGbzmObnwFuXCNh1rxW/Qa2O9+wBNee8cy0/V3oc2ZACkqHZVI
	/gc+uTPFp81XJTtVKBfd4ARVTETqmBUws8oKKsGstz0bvVNFCWYu4XprI+iQmYK+Xg==
X-Gm-Gg: AR+sD12SVCyBBvaMofMTKgNu4mG1Ys2yCrf5hIphN5EeztxszrPGFtxz1/Girq47KuR
	ngEUx1KZXh/YJ7m0JiOKR2bWgqK3Vgyu2TTZmRZrPTPUQdKeh+TA2EmvYHAX30PG4N+Nq/J0YQT
	OKlLZ4feKBdVIc83Vobs8HTKqj2s2jfeY8biqFHpZ9HCXJTE1upy3P8iSu25U7dMHR9/IGglgz9
	qI/ROZkDNAw2i6cGs28x2AKfoLCB/Wg/7p4W3h4qGV9pdfMJqjgAQ1yIda8I2aYIf7V9S/0Ftuv
	JTPSMHUkNz3mQFwRL3Z+2OBAsvIN8lk3zmDA6RE8ti84dLqWw8Ky6fAes5gdZf+iZiPOLwuAu4Y
	xQzoQuE9Xivwye7hrxrrfJWpO29d1zJMi36v/r9mwITj6N5tIdPijarTals68UWs9QI5AGLt8rI
	AodVH6W2OW7RoFL7FzeAUSTIZCpFB2n3xoWn+tkS/3iGPMdBL11g/UPHSTUmPWhCFs0A+OND5i+
	6Fq5XMQuayI0WIlbe9c7Om33NCI82n1FaItV1CLXtQS74W8stnC
X-Received: by 2002:a05:6000:41de:b0:482:a36c:a5e1 with SMTP id ffacd0b85a97d-482b1e875b8mr6574255f8f.1.1787136239836;
        Wed, 19 Aug 2026 03:43:59 -0700 (PDT)
Message-ID: <f687da3b-a9f7-4df3-a113-3cdd0b817e3d@suse.com>
Date: Wed, 19 Aug 2026 12:43:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
 <e0f91d0e-0b08-4d69-bf94-243bd26f67df@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <e0f91d0e-0b08-4d69-bf94-243bd26f67df@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787136240-ABAD09EA-6F06C7CF/0/0
X-purgate-type: clean
X-purgate-size: 2204

On 19.08.2026 12:39, Furkan Çalışkan wrote:
> On 8/19/26 10:22, Jan Beulich wrote:
>> On 19.08.2026 07:15, Furkan Caliskan wrote:
>>> --- a/xen/common/sched/core.c
>>> +++ b/xen/common/sched/core.c
>>> @@ -589,6 +589,9 @@ int sched_init_vcpu(struct vcpu *v)
>>>      unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
>>>      if ( unit->priv == NULL )
>>>      {
>>> +        kill_timer(&v->periodic_timer);
>>> +        kill_timer(&v->singleshot_timer);
>>> +        kill_timer(&v->poll_timer);
>>>          sched_free_unit(unit, v);
>>>          rcu_read_unlock(&sched_res_rculock);
>>>          return 1;
>>
>> This almost, but not quite open-codes sched_destroy_vcpu(). Would be nice
>> if the cleanup logic was shared. The sched_free_unit() call there could be
>> leveraged here as well; what would need skipping are the sched_free_udata()
>> and sched_remove_unit(). And of course the RCU-locking would need sorting.
> 
> Would something like below be okay?

Maybe, but you need to ask the maintainers of this code, which I'm not a part
of. What I in particular can't easily judge is whether ...

> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -589,8 +589,8 @@ int sched_init_vcpu(struct vcpu *v)
>      unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
>      if ( unit->priv == NULL )
>      {
> -        sched_free_unit(unit, v);
>          rcu_read_unlock(&sched_res_rculock);
> +        sched_destroy_vcpu(v);
>          return 1;
>      }

... this intermediate dropping of the lock is entirely okay (it looks to be
at the first glance).

Jan

> @@ -869,8 +869,11 @@ void sched_destroy_vcpu(struct vcpu *v)
>      {
>          rcu_read_lock(&sched_res_rculock);
>  
> -        sched_remove_unit(vcpu_scheduler(v), unit);
> -        sched_free_udata(vcpu_scheduler(v), unit->priv);
> +        if ( unit->priv )
> +        {
> +            sched_remove_unit(vcpu_scheduler(v), unit);
> +            sched_free_udata(vcpu_scheduler(v), unit->priv);
> +        }
>          sched_free_unit(unit, v);
>  
>          rcu_read_unlock(&sched_res_rculock);
> 
> 
> Furkan



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 11:00:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 11:00:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395169.1633671 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwe2A-0008FG-03; Wed, 19 Aug 2026 11:00:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395169.1633671; Wed, 19 Aug 2026 11:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwe29-0008F8-SS; Wed, 19 Aug 2026 11:00:37 +0000
Received: by outflank-mailman (input) for mailman id 1395169;
 Wed, 19 Aug 2026 11:00:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwe28-0008F2-IP
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:00:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwe27-00BrHg-VA
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:00:35 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a858cd3-8faa-0a2a0a5109dd-0a2a45059fb0-2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:00:35 +0200
Received: from [209.85.167.48] (helo=mail-lf1-f48.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a858cd0-4cb1-0a2a45050019-d155a730d90b-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:00:32 +0200
Received: by mail-lf1-f48.google.com with SMTP id
 2adb3069b0e04-5b021916bd3so1305524e87.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 04:00:32 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5b4788f737fsm433190e87.79.2026.08.19.04.00.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 04:00:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787137232; x=1787742032; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=eD5D5e29mk32kIOISPWSXEb3EOHjbKF0TWimAd1P+qg=;
        b=OLMPMORrT92g+ZrQIpBGfWeXP9mogYIWbirt+mNVqE7RF5C8JAyDoPDKc6yaLgFobr
         +9eSRx26ePzeJG4RPKTHfiFY+ameEYPQg/roo4Ez1qUTjBx3lOMWImPlTgY3znhPxYfX
         GVba4hgiff7n8IN+6xW4ZklTZqkLhw3te1nyoxN6sEYHBTRyEbB2aZ62W3sRk/DuQO7E
         W3ELeASviPvbUOm8sF1BlFDcmUnQ+p0v9dgKWPRYj01X6DC6GXj5JIaNpCg6io1CNsgq
         bijd7BEBZ0s4xIoWV0uY7YtX3o4M/iRszQ9ZnZyv03CP6ngLQZedGHSnHqpAk3w41rGI
         TXTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787137232; x=1787742032;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=eD5D5e29mk32kIOISPWSXEb3EOHjbKF0TWimAd1P+qg=;
        b=mlg2WYbSpcLybTCOBN6TV8zp+6CapaLO6LU4dDTxmswRhZTMOWuM0URYvMOhRn4WLz
         CUgmPOZo4U92xDZa990YAuHu9htlRdo/oj//4W7q9zEQ06UzRxoDUN8dmiUp8aAyMebN
         o1CHeRmeNwMAa7kS1o1frqRUI1ipONAOkJgCT208cx4gQ9y7yCImn9zipUNFXgPvuXvX
         JXEfDksj8/0XdLXGrNSNCqxZRiq5+7E7i6UlbSs+6JBs69hutYlcSq2tR4x1XRBam8C7
         VaDDbCm8MPTlNI510JbfIWJGbLYTt1QoESkXbiiQREbtHBmvqP+lLmDMs66yz+1ZG9Ch
         ZVRw==
X-Forwarded-Encrypted: i=1; AHgh+Rry1fcxkiEFj1cuRaiWY2CEBhk/KYxyIhuZyZXXCcGq4THW0FMF3lescV4KnSFXpmfjT+0VTSMA+0c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwuZWK11/3ogQnc/11MBiXofIVaNxSwf8SszB3migX/gJAEGTgr
	OcvZn35JCjLbzPiqJ07UMCgGWP1OLg+Vd6pI23QTOsilvQzyo6lZ1P45
X-Gm-Gg: AR+sD118vwecJuAgEFJMNdbSBFSyDfHrOSc4Z0RTG9yaBH8kJXO2l4I8PIO0Vj2bo7H
	Fz9riXIJv+khR92et0F+RtEGyov76tpms0vaxm43jjMMJFG8HHANXqxUH+pnjn/gHa4I3QGPYOC
	i3pEBtZ70GZkKheVFdFyxEj8YSn+7rOD2CNLP43oDnui4Kxv6hns7z6JTQm+8tlG3XViqwlAoEU
	fe6MJEveWqowvJbaal0JH3owpq70j0tQ+HYvUHMMKCCUhMmE9EZpyJw7kV8lfGaMT+5SP5wDTsN
	HcaSyy6cPvEGQI3rZ7k0Xx2NYC+QbpEDChZejuRnUJBv7QamHNEeHFbKkQhyZaBDJIcBxHdx7ki
	Sbws1zo3Ohw+JGHti/m2f/6EZy9apuhZZrwq4sHDEItbCR+lUshEmrh8gtERLlBR1SQMN/S4Xb7
	9qe5yMlfy2t8CsCfoxD9AjD/atKvQB1U4wr7CrgiwXU9buP0bexuNF2qcxttIJKIOXjDW2xhlbl
	2J6ZbN6llUASDbmuf7sObYNP/5s1YoWBt2hbGdj4Nd0okyozvWpaQ==
X-Received: by 2002:a05:6512:31cf:b0:5b1:5379:8b6d with SMTP id 2adb3069b0e04-5b478bcdf1fmr1165821e87.23.1787137231921;
        Wed, 19 Aug 2026 04:00:31 -0700 (PDT)
Message-ID: <abe3e920-7cbc-4714-9fb1-0553c2f539e0@gmail.com>
Date: Wed, 19 Aug 2026 13:00:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
 <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
 <20a4599a-f14e-4c7f-a765-52c1ab667516@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <20a4599a-f14e-4c7f-a765-52c1ab667516@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787137232-738BE2A1-A04F713A/10/73395122804
X-purgate-type: spam
X-purgate-size: 2219



On 8/13/26 9:28 AM, Jan Beulich wrote:
> On 13.08.2026 09:15, Jan Beulich wrote:
>> On 29.07.2026 15:40, Oleksii Kurochko wrote:
>>>   static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>>>   {
>>> -    return -EOPNOTSUPP;
>>> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>> +    mmio_info_t info = { .is_write = false };
>>> +    unsigned long insn;
>>> +    unsigned int shift = 0, len, insn_len;
>>> +    bool is_unsigned = false;
>>> +    int rc;
>>> +
>>> +    if ( decode_trapped_insn(htinst, &insn, &insn_len) )
>>> +        return 0;
>>> +
>>> +    /* Decode length of MMIO and whether it is a sign- or zero-extending load */
>>> +    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
>>> +        len = 1;
>>> +    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
>>> +    {
>>> +        len = 1;
>>> +        is_unsigned = true;
>>> +    }
>>> +    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
>>> +        len = 2;
>>> +    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
>>> +    {
>>> +        len = 2;
>>> +        is_unsigned = true;
>>> +    }
>>> +    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
>>> +        len = 4;
>>
>> Already up to here this demonstrates a weakness of the INSN_MASK_*
>> set of #define-s (which I similarly observe in binutils, and I expect it
>> all has the same questionable origin). All INSN_MASK_L* and INSN_MASK_FL*
>> (also INSN_MASK_S* and INSN_MASK_FS*) are identical, allowing for a nice
>> switch() to be used here in principle. That said, with access width
>> nicely encoded in FUNCT3, it's not even clear whether a switch() would
>> end up being needed / efficient.
>>
>> Otoh none of these masks cover the pseudoinsns that htinst may supply.
>>
>> Further, what about A-extension insns? Some (if not all) of them can
>> plausibly be used on MMIO, I think.
> 
> Because of the further additions that are going to be needed, may I also
> suggest to consider putting emulation code in its own file (emulate.c
> perhaps), rather than directly in traps.c?

Good point. It really makes sense to move emulation now to emulate.c.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 11:14:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 11:14:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395182.1633679 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweF3-0001kx-38; Wed, 19 Aug 2026 11:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395182.1633679; Wed, 19 Aug 2026 11:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweF2-0001kq-Vy; Wed, 19 Aug 2026 11:13:56 +0000
Received: by outflank-mailman (input) for mailman id 1395182;
 Wed, 19 Aug 2026 11:13:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wweF2-0001kk-0U
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:13:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wweF0-009sBo-T9
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:13:54 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a858fdb-2eae-0a2a0a5409dd-0a2a450be3bc-46
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:13:54 +0200
Received: from [40.107.201.2]
 (helo=CH4PR04CU002.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a858ff1-b7e8-0a2a450b0019-286bc9027aaf-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:13:54 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SJ2PR03MB7450.namprd03.prod.outlook.com (2603:10b6:a03:561::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 11:13:50 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 11:13:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HtIRjOuGnXbLgSCEss8tw/Ze4vzMRoAJWUMp9n360G3/S6LlK2J4/7ufEEvzBpJm0lfA+A7YYZPt/S8plA4VKYivwpT1SaDi/4DaoWv6j+yHkTi4xmAZMJS11oRuyXewFeEq95lgWCH9bqP6T4m7GXIN3nIav8cWfN6fZ5UPG5rcr7gX+AIv2GVI6E+LpuAiYynCetHtXv3/sLjrQJIk3KCKjlQlw7d9CcpfuW/ne4HTuhvNBUHdN55ogSFLO0AcEmgS/NwGtZQ1jj1IuzBpUGdHdJ56ikSTPEarRmI263Ukdi6Dm39DJIMYZfVHBrhR8tMLaRkvnZn2DJ9IAPVGSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7Z08gkcl2/hGSaktKo543z0fApnu6jnlkBaA+udc4/Q=;
 b=fDF9hbGy8lPl1uzggqir0M8dJwrwEz/wLWvQLI0NRx/1kDG7W4FV3SC54iRsR4KCrBd7YYpGXwdmRyfsgDDNtRuyL2s6dYZc7QsVG+ojkwFD5jdYpfpLQWkSScsAci/wbqZ+KNOtsUcBV7f31B1M2UYLJfhTeMCpbfRILjsO1EVSSCN+g8dFwuCVoITEJ2SXUIMWVOY0d+1Nrv7USOtHRcGX8psCJMFzQ89ggpL4TywTJO0QFZJMiHvfVCuJof1M8rSX2Hl/qRca0frIjIfn/yAyCQFZIzmJ4Diinj5TJNutuisDfD2UdHmT5lx0XNjG5JXItv3Ut7NI+JUph8g08A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7Z08gkcl2/hGSaktKo543z0fApnu6jnlkBaA+udc4/Q=;
 b=cuo2sD1ILBj4eVwt++wqMhd3m9ONblJb+qIQ/DMjB96QCXnyQ7Tro2hgWgfb9eP0uDh2fI3t8ZVWpXjFQfCxv4fKLlHArIRUBJhIRBPC2humZFnjz33W8+1u4yastDWKytawClUhs+d0PTWdE4ISyCZOMRhdVThqOU1ujs0SXSw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <65789d8b-d18f-4f1c-8ffc-e1247daa4031@citrix.com>
Date: Wed, 19 Aug 2026 12:13:47 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated
 panic()
To: Jan Beulich <jbeulich@suse.com>
References: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
 <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO3P265CA0002.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:bb::7) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ2PR03MB7450:EE_
X-MS-Office365-Filtering-Correlation-Id: 61ef183d-0ce3-4d11-cc49-08defde2f259
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|18002099003|22082099003|56012099006|6133799003|11063799006|5023799004|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	I1/+n3dGYJPL1Y2BrmVhr2okdiWmZypBd+vXiEVVbfviHfZF1lbxWqxzj9AkjevS2qsqaKkhWD9rLgzf4Zl4yJtQ2k7Rz3PfRrvTkymzZ5bl0xXBkg5RTeucvd3hXHQL/OO5WCkop7UkhQTvybi+a2dWUsG8BW7KRufvQM9o8R8AaRPk8WpZtzEQ2448K6BCAOqasJfozIfiI7d+OnV0BzhOhwHzm/1sYMu41u+aRDrPMBx2upej8OKGrhDlUk/d/oZim5L9uZ47dU4kzpThm1SjH9+RvwZVNVhtx7bIPt+L4qX0w0eDKMv+5beTHC08xJVBEaPsjxtBXn6W7G2agsf4GupqKRvLCil4b95X3JLbEx05ezKKpii5G2W9bXA3CFOWPS2/fYX1ufKbjyubrB7QQleiUk9955i69XeceB6HbuZpSSOXSopGNrKD1uME2L9EbJ1mJaxZp+JIhOF3Dzn8WyjTKfGXewrYuFzG/rbZWjTPvx/5MH6nu0eOh9dCz5THoUhgNlyHbTy1W+ShuLTzKYEx7vvSpz6bkMVfFdP3u/XTbllZuS9/rn8w3hr84+sZ/9Q8aL6NRW7p2TTlDPiZef7HFK4EB4ajS/0eTX9DS6nimJw1DpFoy+8yju+iDcmgRx25s1uVNcsgtAtaI1anwN+635WJ+sfpql7QQ4A=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(18002099003)(22082099003)(56012099006)(6133799003)(11063799006)(5023799004)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?YnFtNXUxZ2ZSYXk3VXhiOWhxcDJjWmxOMlZkem1PZ3lqaDR6ajZjdDVrZWdM?=
 =?utf-8?B?NlkvWnlvSzA1UWVnYnQySWsyUzhOKzNjWlRKMXZWS3BoUHB0blVNU3UyeHdy?=
 =?utf-8?B?ZHdkUlR3aENRYkozNlZYeHZaTEcvLyszNDE1QmdPeFlNS3J1aVZTaVNiVFJa?=
 =?utf-8?B?Yi9FSmU5WTdDYXhyTjIveWtwZW40OUFVcjRpQnhxa0Y5TEs4azE2b3RnMHhB?=
 =?utf-8?B?VUcyV3BJM2o3am5lNDdjUjN4WmRseTR0TnhHQUVqRGFtT2c4NUpuV1Y1dGZo?=
 =?utf-8?B?dXFzSngyVVZwSTBFVytKTXJnTmE3WmtEZTFsTGM4dm45UVRTeVRxZlhSUTdL?=
 =?utf-8?B?RzJMYndvbmIreGJOd1pNRExCeTROTnNacGk4c2F0bExOM0RhMVlXVEdrVnhq?=
 =?utf-8?B?NVV5b2V4NENVQ2htL2ZVOVVPaVZmOVlIdUtMdEY0U1lLODAvVEVXbVJ4SWZI?=
 =?utf-8?B?alpPRGN0RHU4QmlHN0dJc2ttb1NmbHZvUjhzRldhUUNuODZMT201bjNDSkR6?=
 =?utf-8?B?N0lWSmdrUWhGa3FqQU96TmJOM016L1ljSU5nL21HVVhHTlc3VjRLZjdpU3dH?=
 =?utf-8?B?YXdTMiszVm9CZFhPOXUrWGRGOFlQS05aZEl6akdWSGxLWEtkdkZ2b1lUUEh4?=
 =?utf-8?B?Zkt6RXQ2K2s4M2ZScHh6QnpmaGZOck1MRG8veXphdzJYRCtNWHpjQWI5SkVV?=
 =?utf-8?B?c0gvWmZKQTlmQ05Ra1I4QzhuUXpLRjMxZ1lGNGkybkFZUGVGODlhdE1lL3pn?=
 =?utf-8?B?Q0VLNkhkTUpyTHJDYThtZXJmUmtuTCsvVms4bVYwaXMwK0pLTnlQSEVxUTJj?=
 =?utf-8?B?YXRpQndRakdNTWwwaEpubHIvSjN2cEVSUzVUekxNSTlLeC9Lek5udCtVOEtq?=
 =?utf-8?B?eHB0TThKUDVwbkRjdmcxNVNXYjkzQ29QWlRMSG0xdzU0bGl1d2ZPNDNkZUR6?=
 =?utf-8?B?VzVSQ3ZTb2k4S1BFM2pWNUd6WTNHVHUrTlpsMkowcEtERXlqM2l2N3U2RTlo?=
 =?utf-8?B?TG11ak51NE9MNG1hZFZ0TEZpSDRRY29vSFlMZnA0MUNETDFwUGtURERrUHZm?=
 =?utf-8?B?QXphcG0wWUQwcTdFQ3pHcmxLZjJiN0xneDIrbkVZdFBOUEJPeklVaVRqcUgz?=
 =?utf-8?B?MXVJQlFKSWVwRCttbW1JbG5iUkpza3FsaUtzQXQ4ditxUGpxa09rTGJScTQ0?=
 =?utf-8?B?STVTYWVSVmFhd3MrdzVGVExZazV1QlVObUV4c2d3cWtZNXVPZHhwSDc3VkRt?=
 =?utf-8?B?VUg5QW5ZaXhyeCs5NG85bGJTbDlXaEh4cGY4QnRvSEtna05YTzVhemY1Q2JL?=
 =?utf-8?B?NFVhdEVBSjB6M09FUEVtSlAwcWdXSDBIWjM4UkJLYm5tQ0QrOGNiS3hSSWll?=
 =?utf-8?B?N1V0YTd4bktJME9QWWVhOWRjdGZhQlJ2dUZxNnlXMGtGSW1BWXRqS25TcGx5?=
 =?utf-8?B?UTVabGhjS3YvdGpYRWwvYzhHejZWMXBBdURxQkd3K3dJQXo3ZlE5RTVucUNo?=
 =?utf-8?B?M2lDRXBpOFhRL1hpWjdHNkU2dG9aTkNPSWQvdnozcDJYUkpZbys3RmhOK1JT?=
 =?utf-8?B?RnUySTZyalQ2Ui85YnRHS1pUZ09qb0F1SEM0OUdBTDVRZVNpN2tVQkFiSHM4?=
 =?utf-8?B?RlRLM0FNZUdRYzlueUp4TkdDT05DMzZUM1EzeFRkNXh2Z2VHc2drOUtHYlZw?=
 =?utf-8?B?dTR4a2hmS3NCc0xCRm0zWER3cnZaSHBYdGtYdVBzWjhQc1RlSWVobUlMSkF3?=
 =?utf-8?B?WGdDZTJUUDYySElvK0xCcElBQk1kbWo1S3R0UHZnOEV2MU9id1BXdjlKZnNt?=
 =?utf-8?B?aU9lTDYrQXZxMStsaFVqcVlsSkJSMVgrRDhPaG5UNEV1SW5tMEY2SmlrMU0v?=
 =?utf-8?B?WngrTUllU2NXSDdXK3lKZkZwcjE0UGh5c2xtSEljZm1PVG5Td0VYK2FrZHQ1?=
 =?utf-8?B?RnIvTDBWZ2lLS0dRTHowbDRFVXN1ektjV2RXUzl2VEN2d1krQitiMEYrT1Vk?=
 =?utf-8?B?VWtUditCTTc3bVdHcnhEK0xDR3cvSkFBbURYaXdGWVcwTG1nTzhaVjBnZzBV?=
 =?utf-8?B?RENqNjM1NXBsS0RLdW9jZlNPOWR2bjN3aTJFSHBKOUdxNjVIZ2NhUU52M2c3?=
 =?utf-8?B?L2hpS2VKZGp1a0pYdEIzbGxuM0tSbktBSkV4amhwYzBMNlQ5cG1lUGZhV1l1?=
 =?utf-8?B?UXJ5bDhFY0RzbnZnZ01UKzFwQVpoUlpRdkpLRSt0REIxN1VXU2dzblliZkZK?=
 =?utf-8?B?YUNvMThOTXhkdUhyakFTRXdyNG5pVEdiaTNaOXhtOHdrcTQ4NUpsSHROT2x0?=
 =?utf-8?B?d1NqYTRDMFZFZDEzYTIrUGdnWHpJV3VFN3JidEcyMUtwclpieDdnQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61ef183d-0ce3-4d11-cc49-08defde2f259
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 11:13:50.5316
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WtAUvZVHXMKSwwAXPymZn6aniX8ZgkQetKGg8CSzOdxuDqocNf5CZ63JfcU9URbKI1Ih0UZv4I02ypKYfxJ0dPRYsdYpdqVucO2iSmd4nkg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7450
X-purgate-ID: tlsNG-42698a/1787138034-AA6DA9EA-4F76668C/0/0
X-purgate-type: clean
X-purgate-size: 2922

On 18/08/2026 3:31 pm, Jan Beulich wrote:
> On 18.08.2026 15:07, Andrew Cooper wrote:
>> Panicing in the case of a timeout turns out to be about the worst possible
>> action Xen can take.  It leaves all other APs waiting on the condition
>> variable, some in NMI context.  As a result, they fail to be shot down and
>> dump state for kexec crash analysis.
> At the same time there likely isn't much to be learned from a kexec dump, as
> the source of the issue is in the CPU, not in Xen.

The single most valuable print message I've ever added to Xen is the one
which reports which CPUs didn't respond to NMIs.  Up until now, it has
always highlighted hardware issues.

Despite my wish to remove this panic specifically, there is still
information to be gained from kexec in a similar scenario.

> Further, this code runs with the watchdog disabled. If there's truly no
> progress anymore, how would one know from the outside whether the system is
> dead altogether vs the control CPU still kicking around?

The scenario you describe can only occur if the BSP accepts the
microcode successfully, and one of the APs locks up properly.

If the BSP locks up, we never get as far as deciding to panic(), and the
system hangs already.

If we have a bad microcode, it is far more likely for the BSP to hang
than for the BSP to work one of the APs hang.

>> Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
>> excess of the of the arbitrary 1s Xen allows.  This time is spent in the WRMSR
>> to load the blob, and there's nothing the system can do but to sit and wait.
>> Despite the delay, the system as a whole does survive.
> For this I wonder whether the log message issues after 1 sec is adequate. If
> we know things can take this long, wouldn't we better issue the log message
> no earlier than, say, 5s * nr_sockets?
>

I have some work there not submitted yet, which would periodically print
a message.  That at least gives you slight signs of life.

But nothing involving nr_sockets.  It's far more often wrong than it is
right, and that's not how our algorithm scales.

GNR has gone from milliseconds to 4.5s.  Putting the limit at 5s is just
going to need another change in a year or two.

>> Microcode loading occures through admin operation only, so get rid of the
>> timeout completely.  It does nothing but make a bad sitaution worse.
> Worse when taking one perspective, yes, yet a silent hang also is worse than
> a panic() telling you what was wrong.
>
> This is a tough one, with - likely - no really good options. And establishing
> what's "least bad" may also be difficult.

As indicated, there's only one narrow and unlikely case where the
panic() is a true positive.

The likely true-hang case don't reach the panic(), and that only leaves
"timeout too short" which has proved to be the case on GNR.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 11:44:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 11:44:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395222.1633704 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweii-00062T-L4; Wed, 19 Aug 2026 11:44:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395222.1633704; Wed, 19 Aug 2026 11:44:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweii-00062M-IP; Wed, 19 Aug 2026 11:44:36 +0000
Received: by outflank-mailman (input) for mailman id 1395222;
 Wed, 19 Aug 2026 11:44:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wweih-00062G-T2
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:44:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wweih-00GLJk-9p
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:44:35 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85970f-8faa-0a2a0a5109dd-0a2a450b9318-42
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:44:35 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859723-b7e8-0a2a450b0019-d155dd2de550-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:44:35 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-4815bce4652so568479f8f.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 04:44:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0dd5fcsm62584705e9.14.2026.08.19.04.44.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 04:44:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Content-Language:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787139875; x=1787744675; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to:content-type;
        bh=vm6DXDcPqsw9MwhiDhO8QXyISmCCCmZBdpzKByqLy8A=;
        b=MWZQtEV0PvkwM9iSVUGwUtxAb/CFi2G4SwrHjX1B4th89g8jhewSGjYNEfyK1BzElZ
         Ln1AtJpSP7q1ss325R1S1V3rL4J3VCrfysafLdjcDeLjQLvGBrxiDocBb1YncSWtg/mM
         Ari63btv9X0BarJCoD5hQk/mK6pv/IPgseCklvHGeOi8B6x4axmnuTNnTLjkP6S80OAP
         ndtW2iCmXnZA97ayMWeDOB+BaVlhnuTw+qeA1Ts3tmfl5ARDl9ikWmSRXmkLQlJ4sBTv
         +aZb4pRUBy6eWav+hh5YxYM/gh/8slxOofAu4kDdA6Y4XLdLFEfAozr6EFQr1TIkMNoF
         JC/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787139875; x=1787744675;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=vm6DXDcPqsw9MwhiDhO8QXyISmCCCmZBdpzKByqLy8A=;
        b=RQ6oYhgceXtCVUywCnnDI0iLfKi40jmz8n1bMd3o5N27iWJk3jxpSyn2m036fCkT83
         EGf2dVE0cIzGtqtywR1+aD4gLChOO5m6cT9dYwENcZvb5sCJTIdvUpZTidjCMVv5NjAY
         zXgZcL9SKbPaIDExIjbHlw3c3aW8cNMH6GIsrlZ+2UUQYRykFOnlFRONRLPLbaliFMww
         AvXAbnpq2cnq+NIk2pLTZfKjWR45BVwFFQHYFxvHetBVz/OPZf9XIvUNSdNa5I+0wiHG
         50FTkUWfVziNbiTHMi5z1e9nrJ2f+Tir+bFFRNzpY5XEhdCFkWwu0gFaMiowwPy6mUR7
         r9qQ==
X-Gm-Message-State: AOJu0YxZKjlpjTwbLOl0eEYl2h3YGvsGDZYKGk4rB1+5TAobqeP85Guv
	w495Sk2/mnffkrC+10PDKmBObnnvbE5/g30yjvBTUnU6AlPlhYgsKk6MHmuj/P/TiCkFiMwYP39
	WYzIOpg==
X-Gm-Gg: AR+sD13xm6UOYlyRlnl2r3IWNquLRa1SscNSSPdAKEk4P21B3v1E31gfykEg3cPTW8Q
	aVz5C4W5wDHxoKThr7K81no+XrFD1VpFNPgRxW8uihKXACy31ixM5hcVE3Xq/QBK47s+jw4tOc6
	eOe8XOvvhpBhyPKkLs1sFZiMl71Cp3cguTyXxR4iX46ljkde5u4IAioIufGe9rl+WL4iJ2ZWty3
	ccrcQNpdkv4oGcIlSOFXMe4LYW9ZmAKck2OE9HSBqRFBNu8k6dYzSkHRGM07rMmdELAzHuYCYcY
	RO1h3GDWS/9qCooN/VqxuNYo0Dx6Lrumkebpbxo7n7/jDNkxMQjqtfLgKugFsPLqUlAjKo5wkmf
	mDh68wTCt/nfaMky4g020MCLyj3D2xKGELWloQRMFVUAMKsa1tAjo66NblZzJFA66H/I0cQiTIn
	zfrrdJyLgasQwzvp/0XwG/0OcHktsL/hAae0VizNQV4fQiNFEcalslilqOCUmbokk9cL2/ghN6a
	ljRzh7ORev2c9h13ZG52IM4mSZ72fffqSMxsd7nm77dSrZJp9eC4vDaJt/Qq7NXeBLvZoubUVY=
X-Received: by 2002:a05:600c:a00f:b0:499:9069:c2c9 with SMTP id 5b1f17b1804b1-499aa1b6c8dmr77659275e9.11.1787139874719;
        Wed, 19 Aug 2026 04:44:34 -0700 (PDT)
Message-ID: <ec25e838-6bf6-496c-abbe-0fd71e2fb0d9@suse.com>
Date: Wed, 19 Aug 2026 13:44:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v5 0/2] x86/time: avoid early uses of NOW() to return zero
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787139875-1ACDF9EA-EBDD1847/0/0
X-purgate-type: clean
X-purgate-size: 103

1: CPU: re-arrange tail of early_cpu_init()
2: time: avoid early uses of NOW() to return zero

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 11:45:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 11:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395229.1633712 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweje-0006Tf-TB; Wed, 19 Aug 2026 11:45:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395229.1633712; Wed, 19 Aug 2026 11:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweje-0006TY-Qc; Wed, 19 Aug 2026 11:45:34 +0000
Received: by outflank-mailman (input) for mailman id 1395229;
 Wed, 19 Aug 2026 11:45:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwejd-0006TS-MZ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:45:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwejc-00Ec6G-SQ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:45:32 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85974a-bab6-0a2a0a5309dd-0a2a4508d7fc-38
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:45:32 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85975c-f659-0a2a45080019-d155dd2dac21-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:45:32 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f703a9e5dso383641f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 04:45:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b1441753sm5796968f8f.5.2026.08.19.04.45.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 04:45:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787139932; x=1787744732; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=JT+63WG7AsG4THCMk4W0hetRuXYQfuHtvo0ezhlRu24=;
        b=OMIdv778QTHooAUND2yaz7kc6GaWhgswLfE0VxjyGzDzI7kjRTZF4mD6VSudZap6UO
         CaG54t5Bj50QpnuI6HVOgERBShHIByGKHDvG1lEcru2sh7R+Nodblj697n7WtkaEimUw
         etvZlcttZ55bNfn3fNjHmBMFEsdxZXkzQPH/sXs0h3wm2KvqOHBPc+wqJQMP1gim90CT
         8TTKfAwGkzs3tzpspKKGerytDgkvNbJ4QuyGB+ajKbpoKxbUjO4kDcxqHDieA+Nd3zXU
         PrBQ1g9JJcO8XG812zc2UtB2o9ptACrz1VWDOUJF5oveTbqd0ZfG1GglYC41D8AIyyQe
         ezsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787139932; x=1787744732;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=JT+63WG7AsG4THCMk4W0hetRuXYQfuHtvo0ezhlRu24=;
        b=JPb/W3+jWlRiXEpGoU5WZ6G0n2P0fJsE6DlPJZtu9oZM4UQl2rdThPrz8Y2CVH4iws
         Tq1QAql4TuTyazW5ApcYNwjp8CkBvI34Y4hIHrErigxDezGp4sVQVIdl8ndiKeNWUbpC
         WHl1owciPD70cDCd7I2diuF65q1Ch/UlotGaq3Kwo1AiytUYVuM43HKHXMAN89viyIrI
         rGxV4xWDVsC1X+OeOnJTFfyUKzkGgaaTm9qCuBuxuou1wJ0MkrHHAgop0Jug6swoOKes
         4pShwat1InR35TctJFde7ENByw6IJs0hAl/uBxDnsTpbb4ZRhHJ28dNVTq8mGrau7kW1
         gdww==
X-Gm-Message-State: AFuF++mdTAC07om5/H8iyf4Y+3UoZhNQWjRR1qsBsrT2JplfcQMbM1ZR
	bQBmMq2yFa72Ujee2TZWZdAmvCzz4yDuuz8kMfVO+OKHciNO//HEjVlYrla69tFvloiUP0osyZL
	2Obbk8Q==
X-Gm-Gg: AR+sD111XPJKMWdKyuaOIph+FK6XdQmHYu5KcUnijZm08AM/YnoZzQM91fFPhK/e1IB
	WMay/E8ytvBBZbhGppVwfYpLZ23MOgalSPjb9SbcCQN20rErpDUw5DYWNXQ06M7wLb3J4esSula
	PcDbb2G0sygvR2ynUtiSv25xhSh093nyMBkamzxnvy3+fJzrTPkzTjAz6jmTeoC8uC075POqOvF
	xHUqv4SBzV9hg69dyZ+ZO7mMFTp/Wy3EkcHmKQefaj3wpxQMdj2s+mOPzdZhuy6qFHZQ4LSs7WL
	4Eu2U6QtF/dcddlA1DgUNxlG9iB56d2HjwXTbxTfsPeGtzllOaqgyuQnJ7Y2zk1sfY4VxB86lPq
	MUhBawRnh8A03lstUHfoKE6Ba26TIhKIRgzlviW4tN+/jIFjfAj3F3iIA+3Gu5jvQCDpMxoLjIK
	F/xhHFa9+Z1z17vvore7wmjpsXGqH0ZFnROvEKcF5i55NNpLk9UzaiO+wAQX2mr0pQm8g86LsJf
	5WiwR/OD1NhfxCgOSKXaCQjQ41iPbFJWK1OKTUYQgbQfnt27OJD
X-Received: by 2002:a05:6000:2582:b0:47f:9022:8531 with SMTP id ffacd0b85a97d-482b1ffd7ebmr2141182f8f.22.1787139932128;
        Wed, 19 Aug 2026 04:45:32 -0700 (PDT)
Message-ID: <347cd6bc-e10e-4696-a1d2-1aaa84811370@suse.com>
Date: Wed, 19 Aug 2026 13:45:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 1/2] x86/CPU: re-arrange tail of early_cpu_init()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
References: <ec25e838-6bf6-496c-abbe-0fd71e2fb0d9@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ec25e838-6bf6-496c-abbe-0fd71e2fb0d9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787139932-D554C87B-7C7C47AA/0/0
X-purgate-type: clean
X-purgate-size: 1141

Some early setup doesn't need re-doing after ucode load. Move the call to
initialize_cpu_data() slightly up and add a conditional return point.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The parameter being named "verbose" may be a little irritating for this
use, yet renaming would incur extra churn.

Clearly an alternative would be to split the function. I can't, however,
seem to be able to think of a good name for the part that would be invoked
post-ucode-loading. Maybe early_cpu_reinit(), except that calling that
from early_cpu_init() then still feel somewhat odd.
---
v5: New.

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -432,10 +432,18 @@ void __init early_cpu_init(bool verbose)
 		paddr_bits -= (ebx >> 6) & 0x3f;
 	}
 
+	initialize_cpu_data(0);
+
+	if (!verbose)
+		return;
+
+	/*
+	 * Work which doesn't need repeating after microcode load goes below
+	 * here.
+	 */
+
 	if (!(c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)))
 		park_offline_cpus = opt_mce;
-
-	initialize_cpu_data(0);
 }
 
 void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic)



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 11:46:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 11:46:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395235.1633722 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwek4-0006sq-40; Wed, 19 Aug 2026 11:46:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395235.1633722; Wed, 19 Aug 2026 11:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwek4-0006sj-1F; Wed, 19 Aug 2026 11:46:00 +0000
Received: by outflank-mailman (input) for mailman id 1395235;
 Wed, 19 Aug 2026 11:45:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwek2-0006oh-J7
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:45:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwek1-009yRN-Vq
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:45:57 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859767-8faa-0a2a0a5109dd-0a2a45089208-24
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:45:57 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859775-f659-0a2a45080019-d1558030b414-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:45:57 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-4998590d392so8628595e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 04:45:57 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14c33b3sm4839260f8f.27.2026.08.19.04.45.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 04:45:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787139957; x=1787744757; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=D6LUuo5zHGa6LkJrIlKdcQpNkQpydOsK91r6s2OSYDA=;
        b=XImVF8rAkJMrXqQFY6SS011LItDlYlps2+B5ZOb7ru0eHaoyNdDf9/JZTsTzxnpVME
         OqH8pCOA6L/W+Nri4NlwukLDhnb9+DVI7oAH9o/yWdaga3dYTofDSK+2K9BGPbJ6MFWB
         hQQIMRO1lk0Ja246BY4gIBtIkDtsaVCnbZrZlXOZDQuBM7LWMtd8Hlqje83mvXg1Io26
         esXKhHUaLdGtJ+USrsp+632Aj1kLPrfYxV+WOqX8s1bZmGJ46lkQDHhH3PYDOVDbe2bx
         XCeEcpeiP2o2M8T0DWRhbvlDrKszbhXxXh9Il8HaEB/CzKp2qrsCQem5DeOP6qf5aFr1
         FR2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787139957; x=1787744757;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=D6LUuo5zHGa6LkJrIlKdcQpNkQpydOsK91r6s2OSYDA=;
        b=iXNH3cw0cIU9qBVk6wLcjyZTywrGbFhVi5G3FjN305MCktTTl0sHTXmusml2bt58Wc
         5OhYJND7BBGvoQWKUhQulnJ2lS3FJZBrmY7F911IGn86CI30/D7ZU7qWfuhkZS4ANTEx
         mA3AneoP2tJkBzssXd3oDCvVZh8zg4ysxkVRXyRK1XGGIuj+b5lKp6ue0UJbU+pbgBl/
         wdZPVcF1VfVq68wvipHvnNXaja+E/aCU4goNx5YLli9a632KrZ8aj4TfQKMjqsb+y5tJ
         Hit6QxqQON8QnX7/tx8RcEyyC6X0lBwulwMz7MlqoZAFqv92VgSGVJHCDSjBsKn+iTyN
         kOeQ==
X-Gm-Message-State: AOJu0YzUasfXbJKZU8490FLIQc1fIHI0fi3K3czWFJ9EJkRxT7msxytl
	Cz++9DEAYVD+jbmr0uCQpFjCgiNTkbB1vJ2FOf+7sBDuJYyaYDi/3CGCBIO7K+n0smOGtAgK9Ol
	Hprk5oA==
X-Gm-Gg: AR+sD10+R7TMcVznXu1Wfoozb7gpIdFHUbjoaUrAmCN836IbvBN8upErn8NqgAn3vbv
	+HXdV9jAW0w4zd1vlqQT6wRre199YiQF6osfyi1xJCNoGHbDiOb10m9q6kv8hvJmAGHwLMjJ3aO
	VljsAGSEJnfVmdLqk2Cb3rel/8m4hB3uxGkhIUJI3lX/LndHfomJkxm2ywcxXCyAcD21T4P8IlD
	xR/uTS+M2xl69JZ5TeLnZW2sWxpgy+NyUt/7GZkUNTOEYBUd6kzIWVGNkjMcC9HRsL+VzJAOYSK
	IQfFJeM/hT86G9bObTrDDU9m+nnOQPgP0u4X+JPUceeAbIeQDw4DaenByeL6b8ejjziUDfYrb9D
	qJBe+3jzHpvQip+BZDIO1ymlM1a73CGm1VCLMb98+oUvUrlN78s2ViMJtxT5FTnWox2C+aoo/Xl
	uARrfQdYjvaGuxzXRcfldzdw2SA1e9ClJchwbDfNsAmhrpx+S+9Xei3rH9vO11QX8wXJJuDYkmA
	+iDNmHMTBDE7jrygnuvvMG1OliVFHSNCKLmMN+Z2qHc2e/Xb+cE
X-Received: by 2002:a05:600c:37c6:b0:499:9eb7:4558 with SMTP id 5b1f17b1804b1-499aa1e43b7mr77400005e9.10.1787139957333;
        Wed, 19 Aug 2026 04:45:57 -0700 (PDT)
Message-ID: <cb8d9a90-64ce-4e86-a188-36a32fe02970@suse.com>
Date: Wed, 19 Aug 2026 13:45:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v5 2/2] x86/time: avoid early uses of NOW() to return zero
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
References: <ec25e838-6bf6-496c-abbe-0fd71e2fb0d9@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ec25e838-6bf6-496c-abbe-0fd71e2fb0d9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787139957-D614687B-ED93BEB1/0/0
X-purgate-type: clean
X-purgate-size: 6163

Waiting loops like the one in flush_command_buffer() will degenerate to
infinite ones when used early enough for NOW() to still return constant
zero. Make sure the returned value at least monotonically increases. When
available, use nominal frequency values as initial approximation.

Do this only in get_s_time(), as producing a sane value in
get_s_time_fixed() for non-zero inputs won't be reasonably possible.
Put an assertion there.

Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: While generally the mentioned waiting loops will take longer to time
     out, on a very fast CPU tight loops may time out too early.

With "x86/time: set AP's TSC scale estimate earlier" the counter update
may not need to be atomic anymore, as then only the BSP can reasonably hit
that path.

I don't think Fixes: tags should be put here. If we did, we'd have to
enumerate all introductions of early uses of NOW() (or get_s_time()), with
the exception of those dealing with getting back 0 (which I expect is only
printk_start_of_line()). Will want backporting nevertheless (unless deemed
too risky).
---
v5: Move addition to early_cpu_init() down. Adjust commentary there.
v3: Use "high" / "max" freq if "nominal" isn't available. Set NOW_good.
v2: Add assertion to get_s_time_fixed(). Use nominal frequencies for very
    early setting, if available.

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -19,6 +19,7 @@
 #include <asm/random.h>
 #include <asm/setup.h>
 #include <asm/shstk.h>
+#include <asm/time.h>
 #include <asm/xstate.h>
 
 #include <public/sysctl.h>
@@ -444,6 +445,39 @@ void __init early_cpu_init(bool verbose)
 
 	if (!(c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)))
 		park_offline_cpus = opt_mce;
+
+	/*
+	 * If nominal freq isn't available, use highest, thus causing NOW()
+	 * output to move more slowly.  See preset_tsc_scale().
+	 */
+	if (c->cpuid_level >= 0x15) {
+		cpuid(0x15, &eax, &ebx, &ecx, &edx);
+
+		if (ecx && ebx && eax)
+			preset_tsc_scale(DIV_ROUND_UP(ecx * 1UL * ebx, eax));
+		else if (c->cpuid_level >= 0x16) {
+			/* Assume CPU base freq ≈ TSC freq. */
+			cpuid(0x16, &eax, &ebx, &ecx, &edx);
+			if (eax)
+				preset_tsc_scale(eax * 1000000UL);
+			else if (ebx)
+				preset_tsc_scale(ebx * 1000000UL);
+		}
+	} else if (c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) {
+		unsigned int nom_mhz = 0, hi_mhz = 0;
+
+		amd_process_freq(c, NULL, &nom_mhz, &hi_mhz);
+		if (nom_mhz)
+			preset_tsc_scale(nom_mhz * 1000000UL);
+		else if (hi_mhz)
+			preset_tsc_scale(hi_mhz * 1000000UL);
+	} else if (c->vendor & X86_VENDOR_INTEL) {
+		unsigned int hi_mhz = 0;
+
+		intel_process_freq(c, NULL, &hi_mhz);
+		if (hi_mhz)
+			preset_tsc_scale(hi_mhz * 1000000UL);
+	}
 }
 
 void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic)
--- a/xen/arch/x86/include/asm/time.h
+++ b/xen/arch/x86/include/asm/time.h
@@ -23,6 +23,7 @@ mktime (unsigned int year, unsigned int
 int time_suspend(void);
 int time_resume(void);
 
+void preset_tsc_scale(unsigned long freq);
 void init_percpu_time(void);
 void time_latch_stamps(void);
 
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -476,8 +476,8 @@ static int num_cpu_cores(struct cpuinfo_
 		return 1;
 }
 
-static void intel_process_freq(const struct cpuinfo_x86 *c,
-                               unsigned int *min_mhz, unsigned int *max_mhz)
+void intel_process_freq(const struct cpuinfo_x86 *c,
+                        unsigned int *min_mhz, unsigned int *max_mhz)
 {
     uint64_t msrval;
     uint8_t max_ratio, min_ratio;
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -417,6 +417,9 @@ static inline uint8_t get_cpu_family(uin
     return fam;
 }
 
+void intel_process_freq(const struct cpuinfo_x86 *c,
+                        unsigned int *min_mhz, unsigned int *max_mhz);
+
 #ifdef CONFIG_INTEL
 extern int8_t opt_tsx;
 extern bool rtm_disabled;
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1664,6 +1664,9 @@ s_time_t get_s_time_fixed(uint64_t at_ts
     const struct cpu_time *t = &this_cpu(cpu_time);
     uint64_t tsc, delta;
 
+    /* scale_delta() degenerates when the scale wasn't set yet. */
+    ASSERT(t->tsc_scale.mul_frac);
+
     if ( at_tsc )
         tsc = at_tsc;
     else
@@ -1679,6 +1682,20 @@ s_time_t get_s_time_fixed(uint64_t at_ts
 
 s_time_t get_s_time(void)
 {
+    /*
+     * Before the TSC scale is set, avoid returning constant 0 (or whatever
+     * this_cpu(cpu_time).stamp.local_stime is set to).  While the returned
+     * value is in no way representing time, it at least increases
+     * monotonically, thus avoiding e.g. waiting loops to degenerate to
+     * entirely infinite ones.
+     */
+    if ( unlikely(!this_cpu(cpu_time).tsc_scale.mul_frac) )
+    {
+        static s_time_t counter;
+
+        return arch_fetch_and_add(&counter, 1);
+    }
+
     return get_s_time_fixed(0);
 }
 
@@ -2632,6 +2649,22 @@ int __init init_xen_time(void)
     return 0;
 }
 
+/* BSP-only function to pre-set an approximate TSC scale. */
+void __init preset_tsc_scale(unsigned long freq)
+{
+    struct cpu_time *t = &this_cpu(cpu_time);
+
+    /*
+     * The incoming frequency is only approximate (nominal).  Increase it by
+     * 1% to make NOW() output rather a little too slow than too fast, thus
+     * avoiding a possible backwards jump once the final scale is set.
+     */
+    freq += DIV_ROUND_UP(freq, 100);
+
+    set_time_scale(&t->tsc_scale, freq);
+    t->stamp.local_tsc = boot_tsc_stamp;
+    NOW_good = true;
+}
 
 /* Early init function. */
 void __init early_time_init(void)
@@ -2649,6 +2682,9 @@ void __init early_time_init(void)
                    "TSC ADJUST set to %lx on boot CPU - clearing\n", tmp);
             wrmsrl(MSR_IA32_TSC_ADJUST, 0);
             boot_tsc_stamp -= tmp;
+
+            if ( t->stamp.local_tsc )
+                t->stamp.local_tsc -= tmp;
         }
     }
 



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 11:57:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 11:57:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395254.1633730 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweuc-0000GN-32; Wed, 19 Aug 2026 11:56:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395254.1633730; Wed, 19 Aug 2026 11:56:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wweub-0000GG-W4; Wed, 19 Aug 2026 11:56:53 +0000
Received: by outflank-mailman (input) for mailman id 1395254;
 Wed, 19 Aug 2026 11:56:52 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wweua-0000GA-L5
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 11:56:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wweuZ-005lv0-Kl
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:56:51 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859a01-8faa-0a2a0a5109dd-0a2a4506ac36-14
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:56:51 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859a03-195a-0a2a45060019-d1558031a563-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 13:56:51 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-495437bb891so7178095e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 04:56:51 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e00bddsm46885735e9.3.2026.08.19.04.56.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 04:56:50 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787140611; x=1787745411; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=b2yy6x6x0Ym69OtS8ZIaQs5CFIZaL3dzU++UsgVAeBE=;
        b=bWimoQEJBKOY36sN244gpKAQKVX/lS3Vjfb7xCQG1F9zfDNvoFKRg2XsokSnyup6hQ
         ERty8Py0oIGadU/FRIAPmU9Ft21B1qC4AJaPb4cl4bSqiOxa+D2tNTomKQgT8y6mwxkL
         Oi87ps443TaAaKypyXrsy6AFAxkCfgpRSDNdbdNOLkv+o+zDP9cvVplRZg583enR+CEw
         o+rERSuyFMD2e2cRRkt/ByVLGxSVUwoyHJCODL/21IKgHlgy8f3snaUdMQRutMo35/yI
         R2wT8MAVaQxBMzh9ETxCFBkyuxZkok0STVYjNB3iNiH9PfBGA6JjJom+XcuDdMhymyek
         2R7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787140611; x=1787745411;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=b2yy6x6x0Ym69OtS8ZIaQs5CFIZaL3dzU++UsgVAeBE=;
        b=l8DxFaj67mMUrUzkbk/hhJHS9KmradunlvALaZhuB5uxglw17N4hyLyEYoKEHE1rxC
         puijeQmM3DuNDuk4mKIV5+N/wRPCSUyxkE+Ikdy2saDbNYuQOz5LLPEMi5UU6Rwxq/bM
         26tfufN+tBUCWnaZskU5IrqCtLP/ViYeWVy8rgUjeRaOlC7Y1FRiwDhMv3tN4GRiHhDx
         oozIQfLalyosqpIYEEnKGjaoj18aispcjYPeBCxNNWiJKv/TDO1JWxTgqfZ2RFggeYrt
         QbaDXIMhpUOSR0jbrhhyJcLGM7QfybMtJKQj0G0w6b9R0UuTBFabki44Tx28AD65/ftC
         bocg==
X-Forwarded-Encrypted: i=1; AHgh+RqFT2Rsp4eu6xAry72CQl+F+feI4WckHk8w+5eWisxnO+aULCex+I5MQ8Iu5X+/zL2blXsh77yKUr4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzjYcL8CgpVOO4PfcGdBokyL0x4xWP5NmpuuuOsd0FI29sU3e91
	sL6sljyKxaX3ap9LxgSpehs7lxbKKF1zZKgbUxi53rCW0BumbKliEkVDeuav5MAWgA==
X-Gm-Gg: AR+sD11W6ipALNhYna9yGJxk0AIMT3smDxzoP0F8WG0Yj2c/Utm00jbMIefWGFX9BDP
	FYwmqTMa9ofWyR+qozdB0vLnirQs0XbCvrrLLsLbS5fxVY5A7y7uQ0Z9ieB/QJ6NRbrchoV8Ouq
	1YZhhrM7I62PBYOlb4qh5i9GSEKaOioqERAf4BgCky3XzJWL0YOHLgylEVsR/DqG7ed+XLB1B2u
	c9rpGSDIHYhhNc3861uAi1qIowwzFo44rBRCbFXdzPzhQM0cePeeYu4ZsKjMhYJvp8C9qo1zDb+
	pcuK0NhbI6TpKbqJLbxICiNj/xPI7OwWcTeuXgQSy0d7ONUrjaJQRR1Rljs6lTGiJXt02iXKgLe
	e3lGmvLsJOft1fr3CdAcjoWcwiIwuObRwg4KRcQngogM9/E4LKzBUx8X39JaAM53WYxwzsHls/i
	CpIDEhWNKg8lTdlgpZEt3uP9acU5jC+uaulMepRJ8GuTlzsJprsZ/pFS7aMvkKFEVM6BbkjzwEJ
	pXq4MsBHk2Pdk64T2r6abV47a3Cy0aEQo4/TTcPRbN/0EJklD2tUaOlfyFgAzM=
X-Received: by 2002:a05:600c:19c7:b0:499:a5cb:b7c0 with SMTP id 5b1f17b1804b1-499aa0e7cfcmr53081745e9.3.1787140610877;
        Wed, 19 Aug 2026 04:56:50 -0700 (PDT)
Message-ID: <ffe6c2b0-ec82-40e6-9bf5-fd49a3ef3a43@suse.com>
Date: Wed, 19 Aug 2026 13:56:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated
 panic()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
 <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
 <65789d8b-d18f-4f1c-8ffc-e1247daa4031@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <65789d8b-d18f-4f1c-8ffc-e1247daa4031@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787140611-F440377B-DA05CDEC/0/0
X-purgate-type: clean
X-purgate-size: 2912

On 19.08.2026 13:13, Andrew Cooper wrote:
> On 18/08/2026 3:31 pm, Jan Beulich wrote:
>> On 18.08.2026 15:07, Andrew Cooper wrote:
>>> Panicing in the case of a timeout turns out to be about the worst possible
>>> action Xen can take.  It leaves all other APs waiting on the condition
>>> variable, some in NMI context.  As a result, they fail to be shot down and
>>> dump state for kexec crash analysis.
>> At the same time there likely isn't much to be learned from a kexec dump, as
>> the source of the issue is in the CPU, not in Xen.
> 
> The single most valuable print message I've ever added to Xen is the one
> which reports which CPUs didn't respond to NMIs.  Up until now, it has
> always highlighted hardware issues.
> 
> Despite my wish to remove this panic specifically, there is still
> information to be gained from kexec in a similar scenario.

That is you think of a system without console, where those log messages would
only be possible to fish out of the dump. Fair enough.

>> Further, this code runs with the watchdog disabled. If there's truly no
>> progress anymore, how would one know from the outside whether the system is
>> dead altogether vs the control CPU still kicking around?
> 
> The scenario you describe can only occur if the BSP accepts the
> microcode successfully, and one of the APs locks up properly.
> 
> If the BSP locks up, we never get as far as deciding to panic(), and the
> system hangs already.
> 
> If we have a bad microcode, it is far more likely for the BSP to hang
> than for the BSP to work one of the APs hang.

Hmm, probably. (I'm always having in mind the one old system I have where only
the primary cores on each socket get ucode updated by firmware, with secondary
cores needing us to deal with them.) Still somewhat hesitantly:
Acked-by: Jan Beulich <jbeulich@suse.com>

>>> Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
>>> excess of the of the arbitrary 1s Xen allows.  This time is spent in the WRMSR
>>> to load the blob, and there's nothing the system can do but to sit and wait.
>>> Despite the delay, the system as a whole does survive.
>> For this I wonder whether the log message issues after 1 sec is adequate. If
>> we know things can take this long, wouldn't we better issue the log message
>> no earlier than, say, 5s * nr_sockets?
> 
> I have some work there not submitted yet, which would periodically print
> a message.  That at least gives you slight signs of life.
> 
> But nothing involving nr_sockets.  It's far more often wrong than it is
> right, and that's not how our algorithm scales.
> 
> GNR has gone from milliseconds to 4.5s.  Putting the limit at 5s is just
> going to need another change in a year or two.

That's one possibility, yes. The other is that they realize that they have to
bring processing time back down.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 12:10:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 12:10:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395272.1633741 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwf83-0003XR-B1; Wed, 19 Aug 2026 12:10:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395272.1633741; Wed, 19 Aug 2026 12:10:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwf83-0003XJ-7C; Wed, 19 Aug 2026 12:10:47 +0000
Received: by outflank-mailman (input) for mailman id 1395272;
 Wed, 19 Aug 2026 12:10:46 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwf81-0003XD-RM
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:10:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwf80-00GQTO-O3
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:10:44 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a859d35-bab6-0a2a0a5309dd-0a2a4508d180-24
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:10:44 +0200
Received: from [98.137.68.205] (helo=sonic304-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a859d42-f659-0a2a45080019-628944cd8337-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:10:43 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 12:10:42 +0000
Received: by hermes--production-bf1-54b5569bdc-bl9f6 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID fc9d868b60d516231b4456f7cd23fd55; 
 Wed, 19 Aug 2026 12:10:36 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787141442; bh=fQPOdOsF7VLzOoXGlPvMjMuPS4+j5ip1AlTMsRA9OX8=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=c2T1CmTnZwk0QPjYhKDqmt2CxYxh4A4LGTsw2zOGgkcZPuasFq3l3AOmbVZZK2FVeaiNmKTaJ07eayK+SQ3nA4V6J+EMCo10Aaco0PMbj9fcugfWl63XjJPA6R1h2J/nWMSh6hdkHW7HPaxNqeJvrmCM4/3SCmtLvdV4Q2YLxprQuUip86aMEhD0RJRun7awdCIuxOm099RmDhStHql+Y6bQUhQ2EzAP61HYr5b5GeBqyTxwei0W/zerxFDlkOlDcVKBtR5nNNfvbjH+qfJ55DVwTE976Bgivrd6tpiVFWkF7qdUcpEU94BsuzRADtoaAOCToYXCElrmXY6o3GsMRw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787141442; bh=/XDTVlVGNJfBHN5HwLVyLYJ5ur/xhq9Iv0e9z/T4vMk=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=uUHDY/w9aSG0+UBCR2ASot1d2Vp69yrA3WS0pfvzhq8aj3ZCE14dC46FbbsgzqSP/IrxFfZWJgf0E3uX+y0QFFf3kEMu80VXI6z2w60pAIjfTgVrrkIwnaVOMzQQGuLJ6MUjZEdXteEb734F9JQIXOR9u/uDaMD4ogGw41xDjWOLLKFSbvwnLYkhM5+RToiOAa7ZbYES/AcF8tr+UcBtaqq7bT7hMcqaaC9GmUBS26fRT7HHiKtTRspquWhYicV5aofC8p5pwrvwPfwr7nbP8+erA58ZnsoSy8/Lj6Uas3UYbzO5xp/aB/WwX/HZOAd1g5F1ngjCgX6Q10R/3VrH/w==
X-YMail-OSG: jdaRoe4VM1lFa1atrVrdAGXP8_khn7C2lNiVoRmqTjcZRAlT1yPjrnQmK734jJy
 3bXi0Wr2OHI6k6eCOKm897TuXgtW3hR_HR4h6YL8jYj_arE5qrKx.fcFKfWz9GyqntKuwaGwYqtX
 73tsurDZVYaL4MHMW3xplnPVMCTi.Vf85g0dSs_i9_STaWxJnmMQAxVyE63HA0naR0hzv9BPRw9W
 6Zo_vpW5nBXSw4tFT3XPP5m5YnUtE9TM.jCkv7x5jrLZtCXdktRXWwta5kRceM.AotNTF8JA_ETB
 NtLHVgDtF8ADugYERCOCOP8INnSrvdvUEDqQgz7LAt95CGCvXU5m0TCH6tfrXTauTmMutt6q2YFb
 v91VhxYu4TU.Lii3gh5685OMVK08W6.8GAma9GvGJ83f4ZNy9KyMX3NTQceq5ixwpyqh1bz5Nru_
 S.dvyE5JC9RJrrDs9fck7WR6GqNcrFRxbs1VFPmzV72Hq1LMR.I0dB6IShL_7g3v5nDzrvNcbbfs
 R8rWukEGavlyH90UFOUi5FrA8CSgKWtrEUDcH7zQvgDql0G13FWPxOLi7qmiYiFoFlSKC5c9agXx
 sYxKmeySg6pv1e2a6YxdSXJBsNhiu8ZI3766pn6eAoXb1xOtZGzmqnXL.GxLe9hI41Mhr3Nrn6sq
 4ndVsnHMkrcbmPYqsVyoqBVzYebK1R8qfwRXhCDuINpffKPF0xjsSRrAK3Emy.VWM9PqdcSBCJdx
 AmPpmgEO0f_fNzCmEPNN_mTTgInad0AfuhaU6kQzJVedAAAmYngBBMvdp8gjXFsp6dlnKXLmYn_b
 WFgOk6USmNGhZsY5j4a9.1bQ.rSlijQ6BP2lgQWL0br4wnPO.UyGrKQ5WL0jFKU.wLkQ05P4exlR
 jD.5S2wHaK4aJ74tJuzlbYeZiezJDHvyb0ACv3aheZ75dh3JTaH.pcHk_YcM63s.oXFAjiusWDx8
 bcbl7.N7QQzTuiy9snDke2KJOt1yR.WpAhVjxd9iEkpX7qC1eT6AuXL1Tpc3tOtDc6A5UTtXN9Ra
 V8oBJ7q1ZGIJsPzvmVWg9BH9F_ntcEaEMfl2OibN8D1oCGfi_jDKaSWwd3DAYaXYO1eycTbpBsLH
 1WEOJzjUmZEWwYAwWakIpEhbQpuYnvYBxUhVMFsXxbnmHtPxAcdsZeggnS3TlG9s_QySt6DCIVKV
 uw8UCP3IhuQKGaLcW5G5GSx1AkBPO9qRmBvf1uQLtaysmiV6RptkNzdiKNYTIeV7rSW7n2jX_n3h
 gJ9qUgidQZHxHBJj0l3BE1YkFM2pmnN_xoPxg2CAsNEHFfLeD67uTclD0rgTNaafQNjXen0D0xx.
 dTMybE7ZBp2sOS6M9BXB_iyA9ATvd.e0gwkwSAhP_MESlv_lKg6UuzQnhV6g_rP6Gp17SpZXXQxy
 _gUtOJUf5CuR9uSUG6JQYxXEbDVC0uY4RKT6eO6O4mv6ww7YHPpdp1BmbmwzA5Z_pgG4SHa_lTHp
 NayMaLMD0SsS1ie4SkSIobvbZZVgVwhAHkEowy7T_g34.OdS9Lry2QJlCwmdsjQPKLmGD2H5L5eA
 HpV3WCugYx4d34aXcHEBCzoFeSctLQlaQ_rHGkgMTnTAHsV9T_5l78QiDtpM.3zyC9PjLi9ACgde
 pBuLveKSiagzwteppdGl9eo5bgyOUTgUwZ_vGhlboFgOHfNGa7LIdcNNQS6zeTKpRILIcAy.H9wF
 r4BAP8dHyPxC9R6SUFy.mJDs29rvQzaiOVYeot_DN8Zng2LRemidtm5QSvSZASWKfArBfsNBBBKe
 7Dfy5ivmFIGRGzRvr5KDuLI0CCZkI_DaJKXVGcEnNiIKRzzoxJ13cdoTtpbT_m8F5D44a0SkR.3E
 JLwccXixIuwA4YeRwDy4_yW28.5Tvttmf11HUNd6rBr7svvtA2hDBaXpXnUIC6DAZ2J6y.7KvTGr
 hCYaDHI2BcFgMor7WmBHXyupwACmqMjmfJ5lK8iEn1LTOMswnG95R7P_iehcYCWloTsn55Os7BKC
 vrRj0N0eS3EW6PoTPizjk2_bbReqd6czsJx_0v98azF327LX0w9nRd.UQoLoJ5M0bmKiVq1qZ1tt
 zB4O5Os_7rL_jYvgsxo2Z8LLyeG0S7v2uyU7kjcoCfoWjYcsEJRxfS7MZ.mCzD3xuC1_9aHT5RMc
 NG5SCpLNXG_Nl8EVaBPyIBPM58Xcj.YvQ08xE14b4s6GHdDd2TP9TmCIXD4pix4_11XE.0c59t7a
 XJAwBUPw0zDcAkPUyZfknBdaiM7_pz93G6aEPKA22.6fV
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 3fbe1c6f-0ebe-4df9-9310-2351d8ac13c6
Message-ID: <e750110e-13f8-427d-b93e-08c49ab3550e@aol.com>
Date: Wed, 19 Aug 2026 08:10:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
Content-Language: en-US
In-Reply-To: <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 11139
X-purgate-ID: tlsNG-c1860d/1787141444-D614687B-8A206327/0/0
X-purgate-type: clean
X-purgate-size: 11349

On 8/18/2026 1:15 PM, Chuck Zmudzinski wrote:
> On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
>> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>>>> -- snip --
>>>>>>>>>>>>>> +    /*
>>>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>>>> +     *
>>>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>>>> +     */
>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>>>
>>>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>>>>
>>>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>>>>> by its DM.
>>>>>>>>>>
>>>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>>>
>>>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>>>>> guest are also assigned to its DM.
>>>>>>>>
>>>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>>>
>>>>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>>>>             DPCI_ADD_MAPPING);
>>>>>>>>
>>>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>>>
>>>>>>>> If I understand our current implementation correctly, this statement
>>>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>>>>> in hvmloader code).
>>>>>>>
>>>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>>>
>>>>>>>> I don't think this statement makes the host OpRegion
>>>>>>>> accessible to the device model, though, so I think, if I understand your
>>>>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>>>>> same kind of "layering violation."
>>>>>>>
>>>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>>>>> needed permissions to access the pages itself.
>>>>>>
>>>>>> So, are you saying it should be possible, without any patches to either Xen or
>>>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>>>
>>>>>> I think I could implement what you proposed in an earlier message and do
>>>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>>>
>>>>>>> The more correct thing to do might be for the DM to
>>>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>>>> separate question then.)
>>>>>>
>>>>>> Actually, when I was developing this patch, I tried first to do it that
>>>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>>>> host OpRegion in Qemu.
>>>>>>
>>>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>>>
>>>>> You don't ask me this question, do you?
>>>> 
>>>> Are you offended I asked this question? If so, I am sorry. You make me
>>>> afraid to ask it again so I will not do so unless you permit to do so
>>>> again.
>>> 
>>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>>> qemu person, and I never have been. I can't really help much there.
>>> 
>>>> All I can say is that surely qemu
>>>>> has an existing way to map (host) physical memory; see e.g. how
>>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>>> (independently) there and here there's the issue of how to accomplish
>>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>>> 
>>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>>> can access the MSI-X table of some device, that does not prove that
>>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>>> still stands: I still don't see proof that it is possible for Qemu
>>>> to get a pointer to the host OpRegion without any patches to the current
>>>> implementations of Xen and the Linux kernel.
>>> 
>>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>>> could come up with, as that's one tiny area of qemu that I know at least
>>> a little.
>>> 
>>> From a Xen perspective, this analogy should be sufficient: All you need
>>> from Xen is for it to permit to establish mappings of the underlying page.
>>> As I've pointed out when commenting on a code fragment you presented, the
>>> DM (domain) looks to have permission. Everything else is a matter of
>>> establishing such a mapping. There the MSI-X table code may also guide
>>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>>> appropriate to do things this way in qemu, and since (b) it is, as said,
>>> imo a layering violation.)
>> 
>> I agree that accessing the host /dev/mem directly is cringy. I would not
>> really want to do it that way for the host OpRegion.
> 
> I looked at the current mainline Linux kernel code about access to memory using
> /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
> ordinary system RAM but allows access to what the kernel developers call
> non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
> in the Linux source code:
> 
>>  * On x86, access has to be given to the first megabyte of RAM because that
>>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>>  * and similar apps. Since they map the entire memory range, the whole range
>>  * must be allowed (for mapping), but any areas that would otherwise be
>>  * disallowed are flagged as being "zero filled" instead of rejected.
>>  * Access has to be given to non-kernel-ram areas as well, these contain the
>>  * PCI mmio resources as well as potential bios/acpi data regions.
> 
> So I think things like the MSI-X table and the OpRegion would qualify for
> /dev/mem access even with CONFIG_STRICT_DEVMEM set, so after seeing this
> I expect I could get a pointer to the OpRegion running in Qemu using
> /dev/mem and mmap, as long as it is running in dom0 with root privileges.
> But as I said earlier, I agree that /dev/mem and mmap does not feel like
> the right way to do it.

Moreover, I tried accessing the OpRegion using /dev/mem and mmap using a
little C program, dumpmem, [1] I found but it does not work in either dom0
or in the guest when IGD is passed through to the guest: mmap returns
MAP_FAILED and reports the EPERM error: Operation not permitted. So it looks
like Qemu cannot access the OpRegion using mmap and /dev/mem with current
Linux kernels. So I am still skeptical that with current Linux kernel
implementation and its hardening mechanisms such as CONFIG_STRICT_DEVMEM, it
is not possible for Qemu to directly access the OpRegion without also adding a
patch to either Linux or Xen to provide access of OpRegion contents to Qemu. 

But the good news is I did find a way to dump the OpRegion to a file from
either dom0 or the guest when passed through, but in dom0 it works only before
xl makes the device assignable for passthrough and bound to xen-pciback, so that
is not so helpful since we need Qemu to access it when the IGD is assigned to
its guest and bound to the xen-pciback kernel driver.

Here is how I accessed the OpRegion from dom0 userland before xl assigns it
for Xen PCI passthrough:

Linux debugfs mentioned in the man page for IGT GPU tools [2] exposes the OpRegion:

https://manpages.debian.org/trixie/intel-gpu-tools/intel_vbt_decode.1.en.html

Here is how to dump the OpRegion contents to a file in the home directory:

user@dom0:~$ sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_opregion > ~/i915_opregion
user@dom0:~$ ls -l ~/i915_opregion
-rw-r--r--. 1 chuckz chuckz 8192 Aug 18 22:41 /home/chuckz/i915_opregion
user@dom0:~$

There it is, the 8k OpRegion dumped to a file.

This also works for the VBT:

user@dom0:~$ sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_vbt > ~/i915_vbt
user@dom0:~$ ls -l ~/i915_vbt
-rw-r--r--. 1 chuckz chuckz 8704 Aug 18 22:48 /home/chuckz/i915_vbt
user@dom0:~$

So now, with a copy of both the OpRegion and VBT, I can write and test
patches to hvmloader and Qemu using your approach of exposing a copy
and never mapping the host OpRegion to the guest and in that way avoid the
layering violation. The TODO is to find a way for Qemu to get a copy of
the OpRegion on the fly instead of only after the administrator places
a copy of it in the dom0 filesystem where Qemu can access it.

I think one way to make the OpRegion directly accessible to Qemu instead
of being accessible only after dumping it to a file and placing the dumped
file where Qemu can access it would be to provide a xen-intelgpuback kernel
driver whose job would be to make the OpRegion and VBT accessible to Qemu
when the device is assigned to a Xen HVM guest.

Chuck

[1] https://github.com/tchebb/memdump
[2] https://drm.pages.freedesktop.org/igt-gpu-tools/


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 12:15:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 12:15:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395289.1633750 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfC9-00045B-P0; Wed, 19 Aug 2026 12:15:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395289.1633750; Wed, 19 Aug 2026 12:15:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfC9-000454-Li; Wed, 19 Aug 2026 12:15:01 +0000
Received: by outflank-mailman (input) for mailman id 1395289;
 Wed, 19 Aug 2026 12:15:00 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwfC8-00044y-AV
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:15:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwfC7-00C2zo-NJ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:14:59 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859e35-bab6-0a2a0a5309dd-0a2a4508b77a-48
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:14:59 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859e42-f659-0a2a45080019-d155dd32ccf3-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:14:58 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-47f633e6058so769004f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 05:14:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14b7d3asm5068052f8f.23.2026.08.19.05.14.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 05:14:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787141698; x=1787746498; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=E2AvHH1BOJZVivwdNU06aE+xjBAckx3IC3gaKA2oUfg=;
        b=TyHbcLJ92mlU5J78QQWxK1j3Lm5bKdVi6q/xZw4DBQRPpeeXPR02YHyEtL1x2vHAUQ
         rM2Fq+1nmnpLFQg+w+pyHgNnxJZV0Ncs9X1zY09fcFuyf0hPgwAlLP9TOZd2oJsZF45r
         nFT/hbf6+diRmhGKqmL+yKt05UwYUz8y2f+2oZfiRkffnG/8pn/xsocvKTBaRzBRQxld
         mDXWKbuKJZwJVOleLBWFHn4U1vBpSz5yghKJ1zvPiBLTBznqXkrPMBiKxAPTmefDGNJU
         hVJb7pokDws+UWB4m7mxDpGvAmEv52EG7UYXoPY4/1PtuDfDGyNYLoAgtNVAij+ZTjug
         UV1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787141698; x=1787746498;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=E2AvHH1BOJZVivwdNU06aE+xjBAckx3IC3gaKA2oUfg=;
        b=tWc+2KbARsetfPj8xGkjavx15BkrH687v2yCLSBpaDpwZwUP6ns9RW6kxh/EKmifni
         zo3fXRSmc6fespD0dJujHrknHwa1VWzXsPGRWo6PJWDGkPbDtC0X1vXaaEvGn2X+bJYL
         V9FGYvFFRCvyu1MqGzZr29wBswlHc/2uF7vE1YvzhnVRbEBjMopR2Abvq1rKCdR4s//a
         bKt3caAg71PWTB7tAStkBZPl56fay1z1NiBpnsKh9StFvXsXhdM7q/ZwIXeYHs4k63zP
         DZDMgAIfP2SJWZy2Bi8zRqYnopG9VPkEx1sg0QlXT3VXprdSfT0oqTE5SHJhsyGES8Bf
         9TWA==
X-Forwarded-Encrypted: i=1; AHgh+RozS0ayhRRQgman8h4DCT6eA49zw4cYTMZ4KAz4OAKgx+ycPdf8VWXazo39ZDD+2pFIr62wjoLYLYE=@lists.xenproject.org
X-Gm-Message-State: AFuF++kRGXnW5Ix8UmS5wSEXuZ6MCq482Itqh41GlBOn4YztVpShDbGX
	iRTH+3rrCAZ9trXkwBjTIquh2rt8nbdOSmOQeIiilsJsGcvLFLRg4J/hv2opF0cbckNRN7sCcAj
	rXTvCIA==
X-Gm-Gg: AR+sD10uIZZcraFe8yred6Os+awiELDEeGDMVSlkUE+rzYHeGyws0rwX9EbtnjsRN+X
	yZGDUFz1tUAeKH0hgKktcyKbAfQyfNjhHHN4Hge7M2QCFUnVJCK34gORTHopcjeVuqEO55xqW7H
	3PKVMnG6Zf0A7qlQDbEw/MaFoHs6M4w4dfeltNrlm6Gk+B+zF9nAAF00wP13Wt8w3Rw0zwAew0M
	tyIPAezNANZYWvZW0k7WJO8zqFLuBwGBcBxocaWRtF6GqTD+ZvqeIH1Mcu3VAr58i94hHS49Aoh
	uBPlMt1FgExp7uoqdtMN0JxiL3cfdXKAl1lVvnByzhO260XNETMoQx8mCIm4AOW6XQHaHzDaLf5
	y2mXT80v2T1k+1I93sQ/rPYzYTofYugGhzHmYjgQ9k4brSad/ThpcMYUwga0cntKb+b8e48zLBU
	IHBkxdRSEUJW6T7LPHMdPh8WuESMXxPsHZuF47nVUNxL+NZV0za1WQj9X0Otfb8xfHW446H6lB/
	dPgA62kfVO259wi0EJr+AHUQcmNiD5Q+q3LYppzCqTam69fSUhv
X-Received: by 2002:a05:6000:4012:b0:47f:4fa9:ae42 with SMTP id ffacd0b85a97d-482b1fd3990mr6302569f8f.11.1787141698120;
        Wed, 19 Aug 2026 05:14:58 -0700 (PDT)
Message-ID: <a9123568-9727-407c-9cca-edbb0000b618@suse.com>
Date: Wed, 19 Aug 2026 14:14:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 6/9] x86/hvm: Support extended destination IDs in
 virtual MSI and IO-APIC
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298081.8631fc262581453bbf619ec5b2062170.19dcf388512000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298081.8631fc262581453bbf619ec5b2062170.19dcf388512000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787141698-D775B87B-9885AFC8/0/0
X-purgate-type: clean
X-purgate-size: 2575

On 27.04.2026 15:54, Julian Vetter wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -374,7 +374,14 @@ int hvm_set_pci_link_route(struct domain *d, u8 link, u8 isa_irq)
>  int hvm_inject_msi(struct domain *d, uint64_t addr, uint32_t data)
>  {
>      uint32_t tmp = (uint32_t) addr;
> -    uint8_t  dest = (tmp & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
> +    /*
> +     * Standard MSI destination address bits 19:12 carry the 8-bit APIC ID.
> +     * When XEN_HVM_CPUID_EXT_DEST_ID is enabled, bits 11:5 carry APIC ID bits
> +     * [14:8], extending the addressable range to 15 bits. Guests that do not
> +     * use extended IDs leave these bits at zero, so the combined extraction is
> +     * safe regardless.
> +     */

How do you know what guests do?

I also don't think such a comment needs to be put at every ...

> +    uint32_t dest = MSI_ADDR_DEST(tmp);

... use site of MSI_ADDR_DEST().

> --- a/xen/arch/x86/include/asm/hvm/vioapic.h
> +++ b/xen/arch/x86/include/asm/hvm/vioapic.h
> @@ -32,6 +32,18 @@
>  #define VIOAPIC_EDGE_TRIG  0
>  #define VIOAPIC_LEVEL_TRIG 1
>  
> +/*
> + * Extract the destination ID from a 64-bit IO-APIC RTE, including the
> + * extended bits (55:49) used when XEN_HVM_CPUID_EXT_DEST_ID is advertised.
> + */
> +#define IO_APIC_REDIR_DEST_MASK         (0xffULL << 56)
> +#define IO_APIC_REDIR_EXT_DEST_MASK     (0x7fULL << 49)
> +
> +#define VIOAPIC_RTE_DEST(rte) \
> +    (MASK_EXTR((rte), IO_APIC_REDIR_DEST_MASK) | \
> +     (MASK_EXTR((rte), IO_APIC_REDIR_EXT_DEST_MASK) << \
> +      MSI_ADDR_DEST_ID_UPPER_BITS))

Following Teddy's comment this may go away altogether, but if not: Please
avoid unnecessary parentheses (around "rte" here). They only hamper
readability.

Further, with ...

> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -359,7 +359,9 @@ union vioapic_redir_entry
>          uint8_t trig_mode:1;
>          uint8_t mask:1;
>          uint8_t reserve:7;
> -        uint8_t reserved[4];
> +        uint8_t reserved[3];
> +        uint8_t reserved2:1;
> +        uint8_t ext_dest_id:7;
>          uint8_t dest_id;
>      } fields;
>  };

... this change, and with ioapic_check() as added by patch 1 not needing
a change here, it is clear that non-zero bits in ext_dest_id could possibly
be seen irrespective of the guest being aware of the new feature. You may
not interpret them as extended ID. (And I'm pretty sure I or someone else
did say so before.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 12:16:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 12:16:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395295.1633757 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfDL-0004Wo-0j; Wed, 19 Aug 2026 12:16:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395295.1633757; Wed, 19 Aug 2026 12:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfDK-0004Wh-UP; Wed, 19 Aug 2026 12:16:14 +0000
Received: by outflank-mailman (input) for mailman id 1395295;
 Wed, 19 Aug 2026 12:16:14 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwfDK-0004Wb-6M
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:16:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwfDJ-005ptP-JJ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:16:13 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a859e8b-2eae-0a2a0a5409dd-0a2a4509b69e-4
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:16:12 +0200
Received: from [98.137.64.83] (helo=sonic305-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a859e8b-be1a-0a2a45090019-62894053873e-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:16:12 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 12:16:10 +0000
Received: by hermes--production-bf1-54b5569bdc-6nq7v (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 55ce23ae771b45d3ef4426380501e0bb; 
 Wed, 19 Aug 2026 12:16:06 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787141770; bh=LRyWQBiH5+CH5bDb5wmPMyRE3/M8Fa6qNVzqk+Wy6xk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=bSK2F/gCyntS8YvgAPgSQ0G55XkwzVeZJHLYHpIJrRyCWkvtY6lQhCHg44BIis/u7PpaOJ2/p+XoEwDWeVMZZOMX2Bo8x9q1zzyGS1YkctCCPgHwCLX7/OhqgHYlHXy60mL0MstYgJ9Po3lTAs8bcHSg/p1TDDgbsTHHMmn03MjrVHW/v3MiMK+9hTYSI9lUNuvpUJNSx4XM4eWJS3DVRwY1gR3IypuLH9IQAKx6TI3qKoF8Z+GCegj8awx8gGDU1pJQjlrIWomk8yzJgZiDQEGWl3K5emlXGTyQJxiSxj/jfZYAFvZXN1csNumVjpZofKcDdNcW8wARfxFVASp+wA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787141770; bh=wENHuOElFAE3RfXqFK8YOFRH1kgimdjxd5lC14xwnuR=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=eeNTZwrgz2EODgQmAay2DT/hwSIOXv60Duy37GQX+N/mGxgXsTDCdqkCrY5J7HnwBdjJ4mWaUB4rtDE8+i9lGpsLVLldeZ/I91i4pEe91Twi9c9fZObbfqjud2OVuAWYoPhpO7fGH/stQBArgZECu3oAcpv/w3kbckXDDURxKPt5f6TsfqcO0+sAFV8RuPLAo2Wbe7a3BhFtj/VK77y3sdG728qpjpMB2c4r2Nj6fKqqO1aiwFvHxwhs/qA0vMhT1zBC0ud0YJS1TM8b+fMUu6vFA6fkNr+oTs9mf9qh2YymwMMk33zk8k8iQiKIUFwj3AhqbaGUTEPhBvrYUtLt7A==
X-YMail-OSG: Q0BbGKYVM1kMHnHcQmlEGcWvJLp5lljiSLcbyeYvX15UOUspCsIw2ygpf6FglnN
 JQlip1UDynu.VoEsVQMmrQp3Ru5ZJHezw43BmcSGFgIGly50F.L2xskfDgLG2j0uDt3fx1QNCa._
 7_uZ5wNsHL0e7_bYTwWSW1dYxhb4Q_nGPFCXkRFIhw6u5o77EIF_i7yfUseiM7XapADGmm_U2sMi
 jWLy7oHXqWAGT7cMuhSyrAIVu3irs0EQ8RGiLQQP9Ap_hU41ZJ0uwHQv4MnTexLRSLfPrwhyKJCP
 aFMsLyaTKUbYvfrCrJ1b3CK0ykkFEkjbizjPPYBUqkhxEd1a4k_Z95g8Rf3ZTkOq1F8NtEl7PCe2
 flRnpBqCFpHfzq9gjrzGB_lKjH23sA5JANQJRei.Pj2UjN2drQnJ7m9oWzznNxBHhq6Nnknvj9Sq
 68V1w3Qm0OBBcFcj2NIif9lICkyXX1QwvSNgby6i1HcfR4NAgdc3bw7YvhpMDmFiBnJzY9o9JOxM
 pspBzkZ.SQROq1hE2bk8I._0Cv_9EdFrtcvesoQK8fxicH8F12Gdl36n4gxPTv_lZHbVp2SsWP9d
 Be0Rcre9oB10fl6Stvv5GDLj1msd4axR_hv5JufRE0Mde4pTnaNZ.JygSeWRb90AL7XGP0poFlU4
 a0ngha9A0UpxYs9ETDgY.SP27YfkHrbS3LI002DSXOxG7D0Dmzuapsy87KExyZC0XpJJYWES3Wbp
 03JyI7b.r5tzy9QovOFxIWhO5YcREsfcUajuneoa3ohslTAUoM7tRuX1xnB6u0KvPX08OZn29AKh
 wkcPAOqFT2GTaLdfX4OinFPI9Cn8P9gkawQtlSOPkGHNSR_0FHRdngrVZCUMUsOdldJ1S7pgQS_T
 8HbWXGGLzTl77jcSidqGWQ0tASkGsCqg3kaxVQkOAOIiQtCfGTi_c8Vbfk9ZICX6DfBarh81ek1l
 Vez.Pbn4Qv5qiZAPPMhs5CxdwKBcdI44cOIimnjpGwEYnzlHcfWPOx_K85Tdpy6LKFAsNS1XOTX3
 Zn4AtGSUpcLjxnqHnv7ozXo1jxV247XsAPtkW_URVjMfOqSdsFxKFDEzf12cC9kITGAaVXVibfWi
 hpn6Rz4lPzYdQUlgV8CFet0DALAvALUYt7UmDaYxufjhgdPiQySsoEhc7wh32jU3WjAjWFm1Lyk3
 xNMktLOsL1p_tQX0MNJeRrWSSekA9IMb63HX1W8yxWCzIi8cJreWkXE2kcj17kgbUk2ykFoApwXQ
 X4ZIHr6h6E8J4jqlbN9bbXcoLKEDPZyeaCvD10yIrsUZrbaADgTBKYZFREcpCxvlmhyukKnak1gc
 neUKMRjx5vyf_7BDWEy8NQa2tSmFXwTyLKZ9XmiLrr0M482YWLtttaXX3nryHDvd_KGPhyWP4ZBJ
 nylHuQ5ErzMosx4qKCW0vf2eKAhX9KnEaAcqIdsh.GRJPrwCPovfg7_tusxFrqYvguR0oDfmWrii
 mGGvCFpXVbuLHJW06ZPP.D5n0Vt0fm8IvFsnDAHOVWRdGxqpw24WPBRsnzt6eGv.Ii1SVncw6Q5X
 n49TVhSbaYp4itOUJnS7KBx_ttHrqKtNRT_xZM06AWJPcM6tp_N5hZ3F8d7PWT7m3y0krmUJbSns
 j_kLLyYmNgtADwJM71j__OwtRtr.XP9Zk4vHB01exPwVVhX1ZGqqkITie2a5ktUumXTp9CkzUSvP
 _h_JsUnhll1AG_UtqlpD9_KSTivKx9SjN8tawyoJN6.tZLql1G_.TjMN2FtFYmw9zo_wsfGRR3io
 33yehkgUP5AsXBoIgMz3CM0fWT.fnaklhPKXPt7O1S1msOqk4Qn5m3Tv2BpOcfnVg0ZbcuPyXiW5
 eCqY3eCcKaltO.spKNYysbNvxgPd.k16JuEUBkLUMPeoBpvl62YIivU5VFIOfbvsbMNJwA45xz8G
 _BtOfjUrBr8bSxRjli.itFa_hp91J6katRMglfUDeg2PZIcSQ922a1p6fDao5e0QlcYm8S8BSryN
 HDG51NrdH04TOHFt6PA8cBMFtrTR7zsna9bmR0LLR6IAMQWVVYj3lizdq9UGpjvjcxkXTaztoPMI
 gmnw4QLnJ3HEsj_poBAXzXf6IMstD7c.oI2E8BxbbWmF806OVIiqp9a25UAPJxHiQo1POw.jxs4p
 zWTtFFynAJGIBWmNVNvuzUdlP76vlvcHFqUxiVLHAOozqhXS9WfjgYNltN3x4GIrehFcPZUkkJPI
 cj3ot8OeBkus1QX09IYVQprFEElhBFg5wtvLxbVUgj0_mK_8-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 17daee9b-8285-43c5-91c6-181b53f8b45c
Message-ID: <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
Date: Wed, 19 Aug 2026 08:16:06 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 9574
X-purgate-ID: tlsNG-bad1c0/1787141772-BE2C4034-283C9EC5/0/0
X-purgate-type: clean
X-purgate-size: 9753

On 8/19/2026 3:30 AM, Jan Beulich wrote:
> On 18.08.2026 19:15, Chuck Zmudzinski wrote:
>> On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
>>> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>>>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>>>>> -- snip --
>>>>>>>>>>>>>>> +    /*
>>>>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>>>>> +     *
>>>>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>>>>> +     */
>>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>>>>>> by its DM.
>>>>>>>>>>>
>>>>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>>>>
>>>>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>>>>>> guest are also assigned to its DM.
>>>>>>>>>
>>>>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>>>>
>>>>>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>>>>>             DPCI_ADD_MAPPING);
>>>>>>>>>
>>>>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>>>>
>>>>>>>>> If I understand our current implementation correctly, this statement
>>>>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>>>>>> in hvmloader code).
>>>>>>>>
>>>>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>>>>
>>>>>>>>> I don't think this statement makes the host OpRegion
>>>>>>>>> accessible to the device model, though, so I think, if I understand your
>>>>>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>>>>>> same kind of "layering violation."
>>>>>>>>
>>>>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>>>>>> needed permissions to access the pages itself.
>>>>>>>
>>>>>>> So, are you saying it should be possible, without any patches to either Xen or
>>>>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>>>>
>>>>>>> I think I could implement what you proposed in an earlier message and do
>>>>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>>>>
>>>>>>>> The more correct thing to do might be for the DM to
>>>>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>>>>> separate question then.)
>>>>>>>
>>>>>>> Actually, when I was developing this patch, I tried first to do it that
>>>>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>>>>> host OpRegion in Qemu.
>>>>>>>
>>>>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>>>>
>>>>>> You don't ask me this question, do you?
>>>>>
>>>>> Are you offended I asked this question? If so, I am sorry. You make me
>>>>> afraid to ask it again so I will not do so unless you permit to do so
>>>>> again.
>>>>
>>>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>>>> qemu person, and I never have been. I can't really help much there.
>>>>
>>>>> All I can say is that surely qemu
>>>>>> has an existing way to map (host) physical memory; see e.g. how
>>>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>>>> (independently) there and here there's the issue of how to accomplish
>>>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>>>>
>>>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>>>> can access the MSI-X table of some device, that does not prove that
>>>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>>>> still stands: I still don't see proof that it is possible for Qemu
>>>>> to get a pointer to the host OpRegion without any patches to the current
>>>>> implementations of Xen and the Linux kernel.
>>>>
>>>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>>>> could come up with, as that's one tiny area of qemu that I know at least
>>>> a little.
>>>>
>>>> From a Xen perspective, this analogy should be sufficient: All you need
>>>> from Xen is for it to permit to establish mappings of the underlying page.
>>>> As I've pointed out when commenting on a code fragment you presented, the
>>>> DM (domain) looks to have permission. Everything else is a matter of
>>>> establishing such a mapping. There the MSI-X table code may also guide
>>>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>>>> appropriate to do things this way in qemu, and since (b) it is, as said,
>>>> imo a layering violation.)
>>>
>>> I agree that accessing the host /dev/mem directly is cringy. I would not
>>> really want to do it that way for the host OpRegion.
>> 
>> I looked at the current mainline Linux kernel code about access to memory using
>> /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
>> ordinary system RAM but allows access to what the kernel developers call
>> non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
>> in the Linux source code:
>> 
>>>  * On x86, access has to be given to the first megabyte of RAM because that
>>>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>>>  * and similar apps. Since they map the entire memory range, the whole range
>>>  * must be allowed (for mapping), but any areas that would otherwise be
>>>  * disallowed are flagged as being "zero filled" instead of rejected.
>>>  * Access has to be given to non-kernel-ram areas as well, these contain the
>>>  * PCI mmio resources as well as potential bios/acpi data regions.
>> 
>> So I think things like the MSI-X table and the OpRegion would qualify for
>> /dev/men access even with CONFIG_STRICT_DEVMEM set, so after seeing this
>> I expect I could get a pointer to the OpRegion running in Qemu using
>> /dev/mem and mmap, as long as it is running in dom0 with root privileges.
>> But as I said earlier, I agree that /dev/mem and mmap does not feel like
>> the right way to do it.
>> 
>> So I would like to come back to something else you said in an earlier message:
>> 
>>> (How in turn the DM would learn of the contents of the opregion is a separate
>>>  question then.)
>> 
>> Let me phrase the question like this: How could the DM gain access to the contents
>> of the OpRegion, and for that matter, also the contents of the MSI-X table, without
>> also committing a layering violation?
> 
> As said previously, I'm not a qemu person at all. Yet it's entirely a qemu
> question you raise. From Xen's perspective, as also said previously, the
> one prereq is there - the DM domain is permitted to access the page(s) in
> question.

Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
a copy of the OpRegion and read its contents so most of this can be done in the
DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
about avoiding the layering violation than anything else.

Chuck

> 
> Jan



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 12:21:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 12:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395315.1633767 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfIn-0006JC-M3; Wed, 19 Aug 2026 12:21:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395315.1633767; Wed, 19 Aug 2026 12: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfIn-0006J5-JY; Wed, 19 Aug 2026 12:21:53 +0000
Received: by outflank-mailman (input) for mailman id 1395315;
 Wed, 19 Aug 2026 12:21:53 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwfIm-0006Iy-TA
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:21:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwfIm-005r8u-9t
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:21:52 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859fbc-2eae-0a2a0a5409dd-0a2a450bad14-48
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:21:52 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a859fe0-b7e8-0a2a450b0019-d155dd35e0da-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:21:52 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47f3b39f2a1so779442f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 05:21:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b144173csm5656496f8f.6.2026.08.19.05.21.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 05:21:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787142112; x=1787746912; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7ymdwcq3ZzdgRlLof7/7lfEkobjba6OLnUYf9Fg42gA=;
        b=G5giJRQXID4z6kOkVh0P2h0e/P+mMT8og7jNjzWtuY2cwvENaWVvwMzL1Ps2b2DXn9
         XNU9CeKuzXG/BNW69/CGcJtRcorcRDVCzx0iCAhNkU1SHTKXVGXJi7+fRN39qteTC9ZY
         hDOiPPCoLces7+01gc7PUzVuO6nL9FVYt1Ieqxu+m8BUoCv/muzhkgQHOrn9880q4862
         kpoRuDoRbafa+jVSkAqkbTALZgrpKC68dZY5Po1Mvep5xQLASFopyaiqH4KpuBmDVS0k
         UH93o+jlmcaCX9G3N39Cee8DJR7EE5rnSICvlhg1v/fBMJi8HJfpiqCkav9iOnBxT3wX
         Xc+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787142112; x=1787746912;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=7ymdwcq3ZzdgRlLof7/7lfEkobjba6OLnUYf9Fg42gA=;
        b=qp/u6u2tW6u+4/gFm0ORHsfDbpp0lJKSwpzEagDqxAUFab5Tr0EuHJpzGaHgbeZwGR
         D7GJesgszmLsDKC2h7VehKDAkrdPjdaDx26X7KbIowXBGnKAt4iNulqV08Ih3RYHjpfN
         Lq28qubHewxVMSXDwQalkahQsJxa8NA7iQ1vsrxSETP2s3le3CPGqqvsLPQaxbySjIWl
         93p2stwjCfDi2zNGteLic8fU2aepNl6Qa44zvXFDC0fzWWu1XwfqBLp+GmZN3XnI8LD+
         mvs203kCq98MmgOHYGk25h6acUhj5wiowwP0QRkKYXlspv9ntdrDtyuOqNRkQWq0VWkF
         gTyg==
X-Forwarded-Encrypted: i=1; AHgh+Ro8UwYfLwQH0Tg4vVVvoNEbiO4dCjiZS93+JZ/+VVBCU6Y9G/3F9zT9VLJOV5iofKy3kWs38hGScRA=@lists.xenproject.org
X-Gm-Message-State: AFuF++mpo/ePwFSIY1gsVI2dY9t5fvpC1OEhByD/zPQHWiQH9x46OLXG
	2ELsMo4xfjXLN4dqPDiMCWbS5+ooPO3XKJec73MW75PX2nYLSybg/+f4YczVq1Rfpg==
X-Gm-Gg: AR+sD1354jBRvEnxrQj9DxDjGx/9jTZj2Pt6S0feLjpvXvLF+Bug5CKq/V6GS/fGmJl
	498eH7vBjpD+vvW1Nc3fedOSmJCZrQZVozYCE10UaPHe2w4ySE3vETVB6o1uLHgGRGY4MNMkMIG
	k3HWjDkxVS+ee3xj1i33TWN1io1GMaKG6R1dTKLEjUijR27HU/Me+1IFYH0bnmk6WrD01s3YK2H
	Kwb13egiKdW4DhNwI2rYmc5WKqCb+F+6C6UdEalwg8FG+pt+RcA6ZnCbR5xwf4Fm290mQ9Jj5hj
	D6vK3hOPGTJIufkNQPvynp/njWiKVfEQBjohSjFUN8CAHmsyi5MMTa6WTlvIBkZQK7IpmPvD9EH
	DjiEFpK7Qxb64Kd/grJUIW6SuRtCm+cM9OvEKiS+XUnqJV9D0uAst0cHpOsVBhS/cF2Ior0gbrJ
	sPkSFS7UlAp80OqofYjHEY4aTiRYL5bYkXpDKC13msUTtzhfowpIcnCFMYOi6b9nZUptUmcv+OB
	GRmpi0Pzs656dt7fzxDXB6jMID9JdvsF5XGj4qqI5r8pbsWf1vr
X-Received: by 2002:a05:6000:2f84:b0:47f:c648:e265 with SMTP id ffacd0b85a97d-482b1feb260mr6928494f8f.17.1787142111697;
        Wed, 19 Aug 2026 05:21:51 -0700 (PDT)
Message-ID: <d4ef5689-4197-499e-97e4-642a6b3bc6b9@suse.com>
Date: Wed, 19 Aug 2026 14:21:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 7/9] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM
 ops
To: Teddy Astie <teddy.astie@vates.tech>,
 Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298081.8631fc262581453bbf619ec5b2062170.19dcf388597000f373@vates.tech>
 <1777392179.8631fc262581453bbf619ec5b2062170.19dd4d45724000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777392179.8631fc262581453bbf619ec5b2062170.19dd4d45724000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787142112-18CCF9EA-9C4EC526/0/0
X-purgate-type: clean
X-purgate-size: 3049

On 28.04.2026 18:02, Teddy Astie wrote:
> Le 27/04/2026 à 15:57, Julian Vetter a écrit :
>> Add two DM ops for MSI passthrough IRQs. These new DM ops take the raw
>> MSI address and data fields rather than pre-decoded gflags values. Xen
>> decodes the destination ID via msi_addr_to_gflags(), including any
>> extended destination bits in address[11:5]. This means the device model
>> does not need to understand the extended destination ID encoding, and
>> simply forwards the MSI address it observes from the guest.
>>
>> With these DM ops in place, redirect xc_domain_update_msi_irq() and
>> xc_domain_unbind_msi_irq() in libxenctrl to use
>> xendevicemodel_bind_pt_msi_irq() / xendevicemodel_unbind_pt_msi_irq()
>> via xch->dmod. The gflags/gvec arguments are translated to the raw MSI
>> address and data words at the libxc level using the standard x86 MSI
>> address format.
>>
>> Reject the PT_IRQ_TYPE_MSI sub-case in XEN_DOMCTL_bind_pt_irq and
>> XEN_DOMCTL_unbind_pt_irq: all callers now go through the DM op path, so
>> the domctl sub-case is fully obsolete.
> 
> We probably want to reflect that on XEN_DOMCTL_{un}bind_pt_irq interface 
> in domctl.h (e.g through a note saying that PT_IRQ_TYPE_MSI type is now 
> deprecated and unsupported).

Which may further want mentioning in ./CHANGELOG.md.

>> --- a/tools/libs/devicemodel/core.c
>> +++ b/tools/libs/devicemodel/core.c
>> @@ -645,6 +645,44 @@ int xendevicemodel_nr_vcpus(
>>       return 0;
>>   }
>>   
>> +int xendevicemodel_bind_pt_msi_irq(
>> +    xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq,
>> +    uint64_t msi_addr, uint32_t msi_data, uint64_t gtable, int unmasked)
>> +{
>> +    struct xen_dm_op op;
>> +    struct xen_dm_op_bind_pt_msi_irq *data;
>> +
>> +    memset(&op, 0, sizeof(op));
>> +
>> +    op.op = XEN_DMOP_bind_pt_msi_irq;
>> +    data = &op.u.bind_pt_msi_irq;
>> +
>> +    data->machine_irq = machine_irq;
>> +    data->data = msi_data;
>> +    data->addr = msi_addr;
>> +    data->gtable = gtable;
>> +    if ( unmasked )
>> +        data->flags |= XEN_DMOP_MSI_FLAG_UNMASKED;
>> +
>> +    return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
>> +}
>> +
>> +int xendevicemodel_unbind_pt_msi_irq(
>> +    xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq)
>> +{
>> +    struct xen_dm_op op;
>> +    struct xen_dm_op_unbind_pt_msi_irq *data;
>> +
>> +    memset(&op, 0, sizeof(op));
>> +
>> +    op.op = XEN_DMOP_unbind_pt_msi_irq;
>> +    data = &op.u.unbind_pt_msi_irq;
>> +
>> +    data->machine_irq = machine_irq;
>> +
>> +    return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
>> +}
>> +
> 
> I think we want to mark 
> xc_domain_update_msi_irq/xc_domain_unbind_msi_irq as deprecated since we 
> implemented a newer (better) version of it in xendevicemodel; and the 
> old one is now a wrapper.

Why mark it deprecated? It can be removed right away when there are no callers
left. libxc doesn't offer a stable API.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 12:37:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 12:37:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395335.1633775 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfXV-0008B9-Tv; Wed, 19 Aug 2026 12:37:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395335.1633775; Wed, 19 Aug 2026 12:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwfXV-0008B2-R5; Wed, 19 Aug 2026 12:37:05 +0000
Received: by outflank-mailman (input) for mailman id 1395335;
 Wed, 19 Aug 2026 12:37:04 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwfXU-0008Aw-Gv
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 12:37:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwfXT-005u0z-Mf
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:37:03 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85a356-2eae-0a2a0a5409dd-0a2a450bcb3c-44
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:37:03 +0200
Received: from [98.137.64.147] (helo=sonic301-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85a36d-b7e8-0a2a450b0019-628940939de3-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 14:37:02 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 12:37:00 +0000
Received: by hermes--production-ne1-6dbcb84f44-dmnws (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 50442b8dd76f8214298a192fce311db5; 
 Wed, 19 Aug 2026 12:36:58 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787143020; bh=aQMJaWrBE/UDIgSTKcnwI0kKyEcWtqyD5o/eXF4SQZY=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=S/KUGWlwLxiuTsJv9Xawxm1uFPyHtstQYTAuhiZ7kINHfcZ0/idfIcBoNKP31gJKiV1f40lyNaclhr68gIAMVwXusqcapQhtAbSuToP2yyNzxmlYYESHHbalyGt+oJ7oauFRINDrZhLRxiJFDh93bjyo3T1k+Wy9Fn+hQXbjzLlYY0oRDEc4Z9aHNFW7pKbMWLy0u9cGP67gV6UHBShiBXe+fiqjdkgEXZLpQx9OOzDjrbdRMCFqWnQoskVBrwt7VI/vXqmbphJ1h0uazL7/27GBrAA+hMqxyHUzzQjdGI+ne+KmuXIl4R45veMOo9USRU6AgRy67/zZp2fUITz4Zg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787143020; bh=3rUIrosknPXJgf2KIJ7zgMrdZ5x2aqxv9+baVEKKqH1=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=g2YCPbHX6vzEG5t05jOyO6OEWs2UUfJ4dqHUAmPU+W9m8W34dvEPXJmMKrgqlhAGQamcpw8+zmMaqw8+/W7MMEkDph0Uc/QYxv7tSJumCQO5zdqOmcrR5V+slrT8dBD9hordzvYpbs914xm+8hUdKhEwQSKlRhGGWC0M8nqHJaiwV0KZ1LuOP7VsqWhVJ4dODE01pu0d4TbtV/sNsh9M8/Hs5dzsuZm/99kvzmOMSrxmOZdby1V4lOZX6Ljeu5yz+Q9VBdvcigAz2eaUDNXlyE/cPatmB+SfCyo3T0i040XU7wscgdKryIUFHgZrNe58DjAjP0lQgk/R5cg1Sfw4WQ==
X-YMail-OSG: xPWzEPwVM1mtGePVdgn3cg1Z.kjN7ZFGIXPv1byaQ9chaO2V2rRZdSybUH9R_MA
 yEIakh8jX6Yz0.ylc12zIhoY0YIAFStonCSCCv3yup7t7_jp_64ocrWcpVIZrWiyWpKAKc5BwBJg
 G5OyE_sEW9MinqB9rXdGeupgZMpSK5t_Nru.0Yig2K4KV8sig9jRi66zswPNzt7RgEtDM8DZftA_
 cBNmgz3DwsmSoa6OXfdYSFbo3cSWexY1HfeUICIodDSwcfum9xvj0CExcUUjU93rkuWqY0UxtP1m
 NPLN66imAdNb9WabKnXnZLVjJr.tuHTzbIe9SFtdGaRfp3SoE7uOFawmmpydTpsfftGpBKNUlWrS
 qV6ywFoi4J49ByMyD6fqfuusE2oeQk6CQkAH3Gzr1j6ZOVck2qePyfOwzW9IbaswGjB5E85qFDVS
 KYYB3pr4ME8.CWEsP5xHU7ZS0dyLtk.CS71OxmE3NMjQYE4FETrj47i0IlKkweZvaJzLKJL7beUM
 HBbco.8xKBIJvJHYTXCY2uO5X9Mp31kPUR7k6ELS1tCgwc.uR2dj6O8gAwdlQ6atpJpPuhkSIyFt
 z_IKTpVOk4vwnEZVm2B4doIq9f.pvTRn_1z_geo6Z3hDBKmoAT9ppu_KjyEwOw6vq.X_MM0n8pWM
 EvnoShVLS55iwxhog18VMNH9BuhdTxqIs3hSHVghNRn1d1X8zHABY2fzoz5R6HmF57eXoliWOw5Y
 EmakxoPJdheEM6BLWpX_UK1IbS9ifJGJ_.JNZYs2rN7w8sk3mxJBZIc1_tf3_dURUCz_xmSe3iEx
 LKv9fzCfAQQqBOu8i2kEZ_akzBrtn_Cj7mO7xaOtaEu3eGN6LK5l7NSRuyw7IFA6a_u2DTxb97PY
 EtfFGu9nh7wa7hddpRyXboTFvmlSdufPM0oftBhOZbsBkUhXbfsCpu1etX.YaLzF1mm9dFfu7HpV
 GUyWfzySQcS3quJV_UhpFipcf_HMeJfzFjFVLIl.DifRX.qo_GySJgsRlfuatnqGdd5o8lz2vVls
 0CSQ0x_DuZFeVLBqTprltBq4Ys.x3H7IE5C826RkIYbR74ZcdBWCtUrzuFn4yv4SzHJZCdd970yt
 92riYm3XRyw10L8qFXMaK3sdCeGatrQjNlW7V_DvIHOdbaeys9j7EG8RyxlEZUhHz3w2WQn_EvcT
 ihvPZ0Hheh0Ts.SypD6zRr.mtRobu3kSlCsYKG3O.6hrReCx8SfsUDI1wFhCNwUc.SadOgk5pMCA
 bpD3cKprFNy9xpdbuzNKDnn6ShYFQit_aW00D2Qs1PS4GdgF1NMrxXHCxbRoRSjdzvqE8faBnkfq
 ZiUFt9Rq03W2EiEgvTKjUQJnNHMkNpm3rSMbYSgmtLDgHoCjoJXEiw3CPymxbj3CfjH7Gaq4_FoW
 b_6QPgBrZkC76jSdrDZ6cpG1tSJfhWjlLs75IteWnUTTL9HyfSIyU4zmmKq0kmUsq3NwMu4APJc3
 nkF6hm6CxTAfwyQ3LTrVs4fr2noJfdKYBhQj_sWr9kfKTwvo33ZBeYxtym86pBJR33GqfDWfBRDB
 2SSXH9YQkNMsBwcDpTSs6CJ3AuS4gH48mtdphsWrgzXoKESZGNtuYCmFOIsc.o1k00V2hNhZ8XL7
 6szzk3.HknOA4dmOBvGwQDDQb9eFXpo.emJ_hwId44pUTjanShlk3jM8GBfUEySRpG9nm_iJA2pm
 L5XnxufqHBSbqPjG1Wl1AAhMl8PozDoWI2oH_..uBOlJMBfEBGtPExpA548YSr3BY0MjRwJm8fFL
 AK4BEogjOZn0H8C1BxHpzmLPbKSP03.jj1QswqIfLPC4dwWi_lKpGwaYMMyLVD1ztABcoNGmPH1N
 caH7jpRlliK_qGPM19SA6AI_z.jyYUDs948htYAM3A1II2Wld.agTD1zD05qWgju4S2HzCi53reU
 ItzdHfUkmuK_9CdY1V0r98hF5sGC4GKsIfbvGfy52twrkgJzhQJNenOcOI2aMHpzeFzFqSroilsP
 q5wUyxufcEQDQOz2ouEAE_APkSPtrlgAibyiLyZqeYVWn7OsDfsojGztHH95BZuhvoy7aJ6ee9DJ
 CEY3Crv_w2gPXbGcWVdkm03dnU7N6ojjkGvWricDREpaaanr4OlNZ9o8SfGl.ZoJqBaqXlhfdysL
 wwB2nHFuKcJD4JVgFthwknX3ToA9UovoF08q_aUV3T5ZCzKTub2.0kiCwMa6I_9WgtCwyN1.eMuY
 elMl4fi_dBma9Vzolqgc5VCKrMjdn8r1mSyCs.QtKlWRcWshjmQ--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 61385cdc-0033-4694-b92a-75ff42d11af2
Message-ID: <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
Date: Wed, 19 Aug 2026 08:36:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
Content-Language: en-US
In-Reply-To: <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 10231
X-purgate-ID: tlsNG-42698a/1787143023-18ECE9EA-74B393D8/0/0
X-purgate-type: clean
X-purgate-size: 10415

On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
> On 8/19/2026 3:30 AM, Jan Beulich wrote:
>> On 18.08.2026 19:15, Chuck Zmudzinski wrote:
>>> On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
>>>> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>>>>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>>>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>>>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>>>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>>>>>> -- snip --
>>>>>>>>>>>>>>>> +    /*
>>>>>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>>>>>> +     *
>>>>>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>>>>>> +     */
>>>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible
>>>>>>>>>>>>> by its DM.
>>>>>>>>>>>>
>>>>>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>>>>>
>>>>>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>>>>>> That would then (hopefully) help me understand why the DM would not have
>>>>>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>>>>>>>>>>> guest are also assigned to its DM.
>>>>>>>>>>
>>>>>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>>>>>
>>>>>>>>>>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>>>>>>>>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>>>>>>>>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>>>>>>>>             XEN_PCI_INTEL_OPREGION_PAGES,
>>>>>>>>>>             DPCI_ADD_MAPPING);
>>>>>>>>>>
>>>>>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>>>>>
>>>>>>>>>> If I understand our current implementation correctly, this statement
>>>>>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
>>>>>>>>>> in hvmloader code).
>>>>>>>>>
>>>>>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>>>>>
>>>>>>>>>> I don't think this statement makes the host OpRegion
>>>>>>>>>> accessible to the device model, though, so I think, if I understand your
>>>>>>>>>> comment in an earlier about my patch resulting in what you called a "layering
>>>>>>>>>> violation" correctly, that our current implementation is also guilty of this
>>>>>>>>>> same kind of "layering violation."
>>>>>>>>>
>>>>>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the
>>>>>>>>> needed permissions to access the pages itself.
>>>>>>>>
>>>>>>>> So, are you saying it should be possible, without any patches to either Xen or
>>>>>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>>>>>
>>>>>>>> I think I could implement what you proposed in an earlier message and do
>>>>>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>>>>>
>>>>>>>>> The more correct thing to do might be for the DM to
>>>>>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>>>>>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>>>>>> separate question then.)
>>>>>>>>
>>>>>>>> Actually, when I was developing this patch, I tried first to do it that
>>>>>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>>>>>> host OpRegion in Qemu.
>>>>>>>>
>>>>>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>>>>>
>>>>>>> You don't ask me this question, do you?
>>>>>>
>>>>>> Are you offended I asked this question? If so, I am sorry. You make me
>>>>>> afraid to ask it again so I will not do so unless you permit to do so
>>>>>> again.
>>>>>
>>>>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>>>>> qemu person, and I never have been. I can't really help much there.
>>>>>
>>>>>> All I can say is that surely qemu
>>>>>>> has an existing way to map (host) physical memory; see e.g. how
>>>>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>>>>> (independently) there and here there's the issue of how to accomplish
>>>>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>>>>>
>>>>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>>>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>>>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>>>>> can access the MSI-X table of some device, that does not prove that
>>>>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>>>>> still stands: I still don't see proof that it is possible for Qemu
>>>>>> to get a pointer to the host OpRegion without any patches to the current
>>>>>> implementations of Xen and the Linux kernel.
>>>>>
>>>>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>>>>> could come up with, as that's one tiny area of qemu that I know at least
>>>>> a little.
>>>>>
>>>>> From a Xen perspective, this analogy should be sufficient: All you need
>>>>> from Xen is for it to permit to establish mappings of the underlying page.
>>>>> As I've pointed out when commenting on a code fragment you presented, the
>>>>> DM (domain) looks to have permission. Everything else is a matter of
>>>>> establishing such a mapping. There the MSI-X table code may also guide
>>>>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>>>>> appropriate to do things this way in qemu, and since (b) it is, as said,
>>>>> imo a layering violation.)
>>>>
>>>> I agree that accessing the host /dev/mem directly is cringy. I would not
>>>> really want to do it that way for the host OpRegion.
>>> 
>>> I looked at the current mainline Linux kernel code about access to memory using
>>> /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
>>> ordinary system RAM but allows access to what the kernel developers call
>>> non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
>>> in the Linux source code:
>>> 
>>>>  * On x86, access has to be given to the first megabyte of RAM because that
>>>>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>>>>  * and similar apps. Since they map the entire memory range, the whole range
>>>>  * must be allowed (for mapping), but any areas that would otherwise be
>>>>  * disallowed are flagged as being "zero filled" instead of rejected.
>>>>  * Access has to be given to non-kernel-ram areas as well, these contain the
>>>>  * PCI mmio resources as well as potential bios/acpi data regions.
>>> 
>>> So I think things like the MSI-X table and the OpRegion would qualify for
>>> /dev/men access even with CONFIG_STRICT_DEVMEM set, so after seeing this
>>> I expect I could get a pointer to the OpRegion running in Qemu using
>>> /dev/mem and mmap, as long as it is running in dom0 with root privileges.
>>> But as I said earlier, I agree that /dev/mem and mmap does not feel like
>>> the right way to do it.
>>> 
>>> So I would like to come back to something else you said in an earlier message:
>>> 
>>>> (How in turn the DM would learn of the contents of the opregion is a separate
>>>>  question then.)
>>> 
>>> Let me phrase the question like this: How could the DM gain access to the contents
>>> of the OpRegion, and for that matter, also the contents of the MSI-X table, without
>>> also committing a layering violation?
>> 
>> As said previously, I'm not a qemu person at all. Yet it's entirely a qemu
>> question you raise. From Xen's perspective, as also said previously, the
>> one prereq is there - the DM domain is permitted to access the page(s) in
>> question.
> 
> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
> a copy of the OpRegion and read its contents so most of this can be done in the
> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
> about avoiding the layering violation than anything else.

However, there is one advantage, from the viewpoint of the Xen virtualization platform
as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.

If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
solution for extended VBT support for Intel IGD devices that would be compatible with
all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
in hvmloader?

Chuck


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 13:37:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 13:37:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395392.1633785 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwgTc-0007bY-00; Wed, 19 Aug 2026 13:37:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395392.1633785; Wed, 19 Aug 2026 13:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwgTb-0007bR-TZ; Wed, 19 Aug 2026 13:37:07 +0000
Received: by outflank-mailman (input) for mailman id 1395392;
 Wed, 19 Aug 2026 13:37:06 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwgTa-0007bJ-Bo
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:37:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwgTZ-00Ghxl-KZ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:37:05 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85b17e-8faa-0a2a0a5109dd-0a2a4505aba8-14
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 15:37:05 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85b181-4cb1-0a2a45050019-d155dd2cbcb8-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 15:37:05 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-47f96c5b722so590110f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 06:37:05 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b1441b0fsm5620257f8f.4.2026.08.19.06.37.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 06:37:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787146625; x=1787751425; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=hTcSuDVkFf5dwBrguIb3nNGNVEVOqcTPkUcXw9M5yn4=;
        b=bSV3eg2Rz3S++0GCVFOyfsGWn7ngMcqgepcy2QiEZkcwFOvvXJIaz1nVyBYzQGlowD
         /B2X3abM5jmRxBLK17wKzf3TN/njBW+C28osSPbbeTFBPTrPtK1SljDCLNSIdOSCdQg/
         bGi0aCZl5wFNU50M3eooDqV3QqRY463BlVpA3WiQwQKk9tay84v/2HbSmOYKm7in57hu
         9Jz/xMKtAbRMa2Vm3ENSRdMZse1vHcv/8gVsIsyfrgBaVhpaeqK68ruG3z/bM+OXgj+M
         odDRg/vVKg48s/thd+75KN1SyaK/veuwWcIts8gIGYSDzhm7CtEuSgesZ1P5EH96OvWd
         +7lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787146625; x=1787751425;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=hTcSuDVkFf5dwBrguIb3nNGNVEVOqcTPkUcXw9M5yn4=;
        b=fjiUmYPriUYzsHbbDOdqffaSzvPAN7PLAm9oJU4fyGS73ghlCaVIQu6ltp7uN/hNa/
         5lUptNso2AgV1daWw1nvGTiROj38QmqDOpxGyWiTwgXa88QHzMz8i9rhQj/+fnKNGFwG
         t0qxqI6IrgkxJ+XV7cOJC/lz9y+Dt0SWCw6pAe9XkwlRvdFmHmFQO3z8G23ibuXizjHI
         O6V+BB5V/f8yyoywPxt6gZi/WiOt7iosbFkcEx7ELu0AGqJvJeOaheS7nZX9VR5w4l50
         D58xPVQcF3kP+7p09UrvmjU7hetkDtpk1TOKpaaA6KokVbD3YDsF3mhRaCqA/7KfhaAq
         7dug==
X-Forwarded-Encrypted: i=1; AHgh+RoWR+zLS/UnA/mM6hDTgVhg1fG/7Ipz795jfqarJQaYXheC9ytvoIPOVNY2JXOSzdezvfg/B7vWmEc=@lists.xenproject.org
X-Gm-Message-State: AFuF++mmicp24LPJ70aIf/MM7VAyl8g7q1SxzrT+XRO3R5D5RJjasElY
	G8STjN2/YnwZnlDqPYC2i95CL8cKXd7czBpfdov/EHkZmNdfP+W+7vCEq/hbGyKoOg==
X-Gm-Gg: AR+sD10rjEOC+ue0y4Fevwf0biwu9S/m9cu8ufjwXYsDzlSVwebJIzZmaOjidwIHNJk
	P41kG2S15qmmWcia68c0H6vxWM/Qu5VHXM5DJTuLknrSBgtUG9hL8Y728387TUKbtA4qWdrXRwW
	r3TbSi0/STzkgHSxb3UmW4Fs/UYItqoc4Lw6XDxlL4QrjTJbFJgjDHaOBjxz9GIfJXGWllWbsKt
	X8i/Jn7xowXqz/aZ1851q6a5h84p0rUNYKYNZ/TQMEqOysD0dUyponLii3g6LXY3bUUcBSYFgVS
	1hCY3uQNr8wq0Fg2wny6hldDoO7g/Vi9MLLK0h7Dao/jV3AUnGi1xA2p+ANthRyd0yKIA1804rx
	e4il3nPWv0ofASZMVzSct8LK6fI4wC5wO8hFMbWMYuG8JkeWHB+mXDX/0m6Z/EZ6o8vSFXdb4bb
	FmQF+nt0V8dSHS1LT4JkxWtRXTxwcKmYgNBFyY70WP36zgYg+xUORxHa0dMW9mwuA3d4pqMEYz3
	bhxp6Zowew/ELTzAPKbYXFXHSvroJ7l97XRV9gOwwpPtKvTA6sE
X-Received: by 2002:a05:6000:4b10:b0:47f:97f6:d39a with SMTP id ffacd0b85a97d-482b1fece9emr9108588f8f.17.1787146624835;
        Wed, 19 Aug 2026 06:37:04 -0700 (PDT)
Message-ID: <b4f7fac9-c9fa-4a84-977e-373fc4df5297@suse.com>
Date: Wed, 19 Aug 2026 15:37:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 7/9] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM
 ops
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org,
 Daniel Smith <dpsmith@apertussolutions.com>
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298081.8631fc262581453bbf619ec5b2062170.19dcf388597000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298081.8631fc262581453bbf619ec5b2062170.19dcf388597000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787146625-F64B42A1-62F7206E/0/0
X-purgate-type: clean
X-purgate-size: 7777

On 27.04.2026 15:54, Julian Vetter wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -574,6 +574,14 @@ long arch_do_domctl(
>          if ( !is_hvm_domain(d) )
>              break;
>  
> +        /*
> +         * PT_IRQ_TYPE_MSI is obsoleted by XEN_DMOP_bind_pt_msi_irq, which
> +         * passes raw MSI address/data so Xen can decode extended destination
> +         * ID bits. Device models must use the DM op path instead.
> +         */
> +        if ( bind->irq_type == PT_IRQ_TYPE_MSI )
> +            break;

Oh, here is where you have put the reject logic. With the other call to
pt_irq_create_bind() having been removed by patch 5, respective logic in
that function (as last modified also by patch 5) is now unreachable,
violating Misra rule 2.1.

Then again you cannot do this anyway, as it breaks older DMs. You want to
reject this only when XEN_DMOP_enable_ext_dest_id (subject to rename) was
called earlier. And you want to reject XEN_DMOP_enable_ext_dest_id when
XEN_DOMCTL_bind_pt_irq with PT_IRQ_TYPE_MSI was called earlier on. We
want to make sure that we get to see uses of only one kind of interface
(unless both interfaces can be made interoperate cleanly).

> @@ -607,6 +611,68 @@ int dm_op(const struct dmop_args *op_args)
>          break;
>      }
>  
> +    case XEN_DMOP_bind_pt_msi_irq:
> +    {
> +        const struct xen_dm_op_bind_pt_msi_irq *data =
> +            &op.u.bind_pt_msi_irq;
> +        int irq;
> +
> +        rc = -EINVAL;
> +        if ( data->pad || (data->flags & ~XEN_DMOP_MSI_FLAG_UNMASKED) )
> +            break;
> +
> +        irq = domain_pirq_to_irq(d, data->machine_irq);
> +
> +        rc = -EPERM;
> +        if ( irq <= 0 || !irq_access_permitted(current->domain, irq) )
> +            break;
> +
> +        rc = -ESRCH;
> +        if ( is_iommu_enabled(d) )
> +        {
> +            read_lock(&d->pci_lock);
> +            rc = pt_irq_bind_msi(d, data->machine_irq, data->addr, data->data,
> +                                 data->gtable,
> +                                 !!(data->flags & XEN_DMOP_MSI_FLAG_UNMASKED));

As before, no need for !!.

> +            read_unlock(&d->pci_lock);
> +        }
> +        if ( rc < 0 )
> +            printk(XENLOG_G_ERR
> +                   "XEN_DMOP_bind_pt_msi_irq: pt_irq_bind_msi failed (%ld) for %pd\n",

Imo this is too verbose. If anything needs logging here at all (which I
question), "%pd: pt_irq_bind_msi() failed: %ld\n" would likely do, without
becoming ambiguous. (Same below then, obviously.)

> +                   rc, d);
> +        break;
> +    }

Where did, btw, the XSM check go that the original code has? Daniel - I
don't think such can simply be dropped, despite there being xsm_dm_op()
on the path here?

> +    case XEN_DMOP_unbind_pt_msi_irq:
> +    {
> +        const struct xen_dm_op_unbind_pt_msi_irq *data =
> +            &op.u.unbind_pt_msi_irq;
> +        struct xen_domctl_bind_pt_irq bind = {
> +            .machine_irq = data->machine_irq,
> +            .irq_type = PT_IRQ_TYPE_MSI,
> +        };
> +        int irq;
> +
> +        irq = domain_pirq_to_irq(d, bind.machine_irq);
> +
> +        rc = -EPERM;
> +        if ( irq <= 0 || !irq_access_permitted(current->domain, irq) )
> +            break;

As we're making a new interface, we need to consider getting rid of bogus
aspects of the old one. Along the lines of what 6df6f24251db ("domctl:
restrict permission check for XEN_DOMCTL_memory_mapping's remove form")
says, and as then also mirrored by 6e42fa383c70 ("x86/domctl: don't imply
I/O port permissions from I/O port mapping"), a permission check on unmap
(here: unbind) for current->domain may be excessive: Even if permission
was already removed, the DM should still be able to unbind the guest's
IRQ.

> +        rc = -ESRCH;
> +        if ( is_iommu_enabled(d) )
> +        {
> +            read_lock(&d->pci_lock);
> +            rc = pt_irq_destroy_bind(d, &bind);
> +            read_unlock(&d->pci_lock);

Here and above - please pay attention to impending locking changes at the
original site, as per (much) earlier discussion. (As said there, I don't
think a lock needs taking here - or above - at all.)

> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -444,6 +444,41 @@ struct xen_dm_op_nr_vcpus {
>  };
>  typedef struct xen_dm_op_nr_vcpus xen_dm_op_nr_vcpus_t;
>  
> +#define XEN_DMOP_bind_pt_msi_irq   21
> +#define XEN_DMOP_unbind_pt_msi_irq 22
> +
> +struct xen_dm_op_bind_pt_msi_irq {
> +    /* IN - physical IRQ (pirq) */
> +    uint32_t machine_irq;

Please can comment and field identifier match up with one another? We don't
want to carry over such an inconsistency from the old interface.

> +    /* IN - MSI data word (bits [7:0] are the guest vector) */

The part in parentheses is x86-centric, which we'd better avoid in the public
headers.

> +    uint32_t data;
> +    /* IN - flags */
> +    uint32_t flags;
> +#define XEN_DMOP_MSI_FLAG_UNMASKED (1u << 0)

s/FLAG/BIND/ perhaps?

> +    uint32_t pad;
> +    /* IN - MSI address (includes extended destination ID in bits [11:5]) */

Please again omit the x86-centric part.

> +    uint64_aligned_t addr;
> +    /* IN - MSI-X table base GFN, 0 for plain MSI */
> +    uint64_aligned_t gtable;

This is a GADDR, not a GFN, isn't it?

With this, the earlier field being named just "addr" also ends up potentially
ambiguous. Perhaps msg_addr (and then also msg_data)?

More generally: Why does the DM need to be bothered about IRQ numbers in the
first place? To identify a particular MSI, what you need are device coordinates
and an index. Once passed in like this, the need for passing in "gtable" for
MSI-X should then also disappear. That said, re-working accordingly may incur
significant effort. That needs weighing against the downsides of introducing
another partly screwed interface.

> +};
> +
> +typedef struct xen_dm_op_bind_pt_msi_irq xen_dm_op_bind_pt_msi_irq_t;

Please omit the intermediate blank line, just like ...

> +struct xen_dm_op_unbind_pt_msi_irq {
> +    /* IN - physical IRQ (pirq) */
> +    uint32_t machine_irq;
> +};
> +typedef struct xen_dm_op_unbind_pt_msi_irq xen_dm_op_unbind_pt_msi_irq_t;

... you do here. That said - are these typedefs needed anywhere in the
first place?

> +/*
> + * XEN_DMOP_enable_ext_dest_id: Signal to Xen that this device model will use
> + * XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings, passing raw MSI
> + * address/data fields. Once called, Xen will advertise
> + * XEN_HVM_CPUID_EXT_DEST_ID to the guest. Must be called before the guest
> + * starts.
> + */
> +#define XEN_DMOP_enable_ext_dest_id 23

I don't understand this. With XEN_DOMCTL_bind_pt_irq's PT_IRQ_TYPE_MSI case
cut off, DMs have no alternative besides using XEN_DMOP_bind_pt_msi_irq. If
that cut-off was viable, I think this comment would want re-wording almost
from scratch. As the cut-off needs dropping / constraining, some less severe
edit may do. The requirement to call this before the guest starts isn't
enough imo: It also needs to be called ahead of any binding, as the behavior
of the binding logic will need to be dependent upon whether this call was
issued.

The identifier XEN_DMOP_enable_ext_dest_id isn't suitable, though, as this
is about the choice of interface the DM is going to use. The newer interface
offering extended-ID support is merely a wanted side effect.

And then it's pretty odd that you add this #define here, but there's no
handling of the new sub-op. Was this perhaps meant to go in the next patch?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 13:51:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 13:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395405.1633795 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwghR-0001tZ-9J; Wed, 19 Aug 2026 13:51:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395405.1633795; Wed, 19 Aug 2026 13:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwghR-0001tR-4z; Wed, 19 Aug 2026 13:51:25 +0000
Received: by outflank-mailman (input) for mailman id 1395405;
 Wed, 19 Aug 2026 13:51:23 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwghP-0001tJ-7E
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 13:51:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwghO-009hKl-8O
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:51:22 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85b4cf-bab6-0a2a0a5309dd-0a2a450ba9dc-38
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 15:51:22 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85b4d9-b7e8-0a2a450b0019-d155802dbc02-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 15:51:22 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so10101485e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 06:51:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9aa1594sm57495895e9.0.2026.08.19.06.51.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 06:51:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787147481; x=1787752281; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=aJUEMSryna+3PimjSfXAj6OIY7VHsqco4QHCn+u97Cc=;
        b=eijLxkXz9jQzeYHwIJ+L4NWe1GSZ8fuhwH1LvB5bs8R+ZD/cPCwHpieDftvShwrtGq
         BfzohYpyX4Cd8TmBxwe3/nozgvgcP9kE4X9E4V9LUlTMICSQfs9TD3Eai/APFvyVuRhh
         AtfGOH1qmCYNPlFGMdwuRbtdTEasK8CP3x9DhRqBIEa9jouJsoNAPD1rZDtLmusoT2xy
         juWgPvAOllAW6KUMCyol1AiLMLSTU3j5AlJQX52plzIJMVTxzo96RB5DP/Y6OT6eHEEV
         sS1gqxmuTJsaI8u676xWX7mUKgow1/EMlVolVpKEsBbim1LasArFYUJVmX+Pmccve1z5
         ae7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787147481; x=1787752281;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=aJUEMSryna+3PimjSfXAj6OIY7VHsqco4QHCn+u97Cc=;
        b=K3R6m0UOjU9qAIklAbe0tUEoePILG/8ITjeHOkhoedavswyxiggKblFHLZz1o1a+A/
         3WE63JELhyoEUAHkUqzWQjXAExjrc1DQ2KDs2FVnVSpDsPaWJ8v/eMkC1mvbI6e9xlCS
         pyY2F3I61x0KzUcF+TShhQumZj7S+9tebe1sdBob3Osfzsrm+g95qx6fkz0+m45vWEQL
         2ERDwt4Hovjgkuf/1Kaq1UIxdZ/6sUeDepbGT4lHRDDAVNDSaXizi+Y2XQc5kjtySwzb
         74RorBPVDVzb3ypmJ7EOZ0/GntHj6YYnsUY4bu/tybbnhL610A52F6A34dgsv/lFRWw3
         zjIw==
X-Forwarded-Encrypted: i=1; AHgh+RoSGeefnvBweH0e+Yb24gkYqYzlkN7vCkq2oDIOewyykt99Omeq1i963C3bnRNnOLds1p0VJusu6rA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yybgi56VKdX3nlPNUDWcggyIUrLnKJ1aw4F3dtCRbnp53dXzx29
	+8NwArviceg+Ny5+YuadM1TSrKlLkYxVAwsYJ6tvPaDY/CP8BEwwozoZnPJScRS61w==
X-Gm-Gg: AR+sD13CDSUBWlLovzco/W4tHHJGM+vhMXp2i7o4poC4ERbhqqr6y3bkjD7JOr7E7wb
	4h9MB7lt6tyrLPxO0pxz7ej93u1Qc6a/GbaU2D/rvL0Z5XlWfjNl6joZ2VKKBY9ocM2jelxfaQ5
	8XCrseeGVcs8uhcCvc3zZHylzhGTqTNUXsdkqv8a/joWmP6GfHkPjFK3g39NokGmsrex6oIo2fV
	eLvMqIBA8tYfIGigR7loD357/vBa8Lb0vx/z/tuXmV85pSyaUnUAj4jp/TY9lyZb3RBk5R+0t4a
	1SpoVWE12zmWxnuV+C7ft4ft68xYtdAxFhAaYjoDjGvy+W8G/c6l1Ba1DVd2BF0snebELsOba8Q
	7a2+LoZ18YLRDAMxIm2Tp5U+IkZ5pV8IAlAFx4hFjuBKLG+bKlKoLhEhyp5KpLgEHeMzMUGjNKm
	uGjC+9UnbkJ3Q8VVf/4PvchlzMtI1yiuU3hJhqasuae60xWqFuOjw8Is79jvv5KKhSXRrMHsfxO
	RFfGzCXXZUhvPmxXgfonItQtCgdsfJnnS8FqdlroaA5Y8Y4DB18
X-Received: by 2002:a05:600c:3593:b0:499:841c:2016 with SMTP id 5b1f17b1804b1-499aa0ff5a0mr106238875e9.0.1787147481535;
        Wed, 19 Aug 2026 06:51:21 -0700 (PDT)
Message-ID: <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
Date: Wed, 19 Aug 2026 15:51:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787147482-ABED69EA-2B8D308A/0/0
X-purgate-type: clean
X-purgate-size: 1867

On 19.08.2026 14:36, Chuck Zmudzinski wrote:
> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>> a copy of the OpRegion and read its contents so most of this can be done in the
>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>> about avoiding the layering violation than anything else.
> 
> However, there is one advantage, from the viewpoint of the Xen virtualization platform
> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
> 
> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
> solution for extended VBT support for Intel IGD devices that would be compatible with
> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
> in hvmloader?

As indicated before: If the OpRegion holds data that is needed to drive the
device, and if the OpRegion is exposed writable to guests, then guest can
screw up that data such that subsequent guests won't work anymore. Hence
exposing to guests (which includes hvmloader) needs to be stopped, or at
least be limited to r/o. That, in fact, includes exposing to any privilege-
restricted DM as well.

Exposing r/o may be entirely okay (i.e. may not be a layering violation),
depending how exactly an OpRegion surfaces for a device (on the host). Aiui
it's not addressed by any of the BARs, yet it looks like it needs similar
treatment. Earlier on we also talked about the region not necessarily being
page-aligned. That poses, even with r/o exposure, the question of other
data on the same (leading / trailing) pages. This may imply that the
copying needs to be done strictly in Dom0, for both DM and guest to only
ever act on copies (which may then as well be r/w).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 14:04:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 14:04:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395425.1633802 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwguL-0003hp-At; Wed, 19 Aug 2026 14:04:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395425.1633802; Wed, 19 Aug 2026 14:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwguL-0003hi-83; Wed, 19 Aug 2026 14:04:45 +0000
Received: by outflank-mailman (input) for mailman id 1395425;
 Wed, 19 Aug 2026 14:04:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwguJ-0003hX-Or
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:04:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwguF-005tR8-U1
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 16:04:39 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a85b7ee-e002-0a2a0a5209dd-0a2a4505d388-30
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:04:39 +0200
Received: from [52.101.48.65]
 (helo=MW6PR02CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a85b7f5-4cb1-0a2a45050019-346530417a1e-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:04:39 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA2PR03MB5771.namprd03.prod.outlook.com (2603:10b6:806:11e::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 14:04:36 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 14:04:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=opi9Zkk60Zeu7Z04qxn/Xpm7ZlAzgJdgA7lY9BCJjctmIyIWwB/xrYjM+5DUetZwtgbR69aTWTelrfSBZ4ZYTqmA/F9araC0SzjWVHBS7t3Zqx3H42mWm8jRhofkoYbt9Lx0Z+h9B6OY4HIbzBSsYh08nmLaDR3oZ2s2rgBtPCet6jMHdjKajxgJMHELbs7XBbLjuXn+G600SAwZNjmTp+AZ5ptduXRAMRImg7aXqJ3oQpZnoE+D8k+vezRXfTMEl5mrHB5lg+n0HrwWW8OAGS05FGEL4GLMeEO4W9Vm+nLNIYW9lCf0xdvdoGy5tThfbp0lf44FUuXn+sFc9ON+IA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CrVmE5+FnLQ6dD2nN978imW6NMMpjS99mVRfpfPXzwU=;
 b=E+0+h1mTXdpY8HS/eaBKfL29jMjiCFbILQljCnZs2ujMrIW8BOJWxy9gSBTkgjeXz8f4nNan+AwRRd9OA7UjeGttto6zpFYgbast8FW/XyWiyVpBKw2vHnwxGspVtr/P9fjVi9cY+yAKGtKS7EYh9bUjCce47Ex2wtgutlH6ff1m35axt4efR6yfkPrb/UiOgAJwlSPwYthsjt1k0Mi8IhWTDRqjIQkLSxjA6XmyAkACYYMrdRuPicxOR2SZNxtMpd8QLY55OgS6kGAN7EHw6NnzzZ4qV3w4oC9jgc+ZqglTWH9Ye4Z0eUZgQZrsjd4rAj6hf+vZ+r9OtDPlD9G0kg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CrVmE5+FnLQ6dD2nN978imW6NMMpjS99mVRfpfPXzwU=;
 b=Dsot+i30nl1jlxHkTpnSJv9clt0LpzkHNMWM9/kIODI8LIgUK1bQsVOVjRahrtWwlDYm2BQYkQf7rcCSUg20J0+PiCCe7pmUi6zSnYDkc5a1wGxXIJvVWcFRQ2CzQKa8EcqFE2ixSil7tSSBEbJuriFxNiomfeLLq7brhiUBoHU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <1200071f-122a-4dc0-aa08-7a7e2f1a6587@citrix.com>
Date: Wed, 19 Aug 2026 15:04:32 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated
 panic()
To: Jan Beulich <jbeulich@suse.com>
References: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
 <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
 <65789d8b-d18f-4f1c-8ffc-e1247daa4031@citrix.com>
 <ffe6c2b0-ec82-40e6-9bf5-fd49a3ef3a43@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <ffe6c2b0-ec82-40e6-9bf5-fd49a3ef3a43@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0249.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:1a7::20) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA2PR03MB5771:EE_
X-MS-Office365-Filtering-Correlation-Id: dee61821-0ab2-4ef7-7319-08defdfacd60
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|10067099003|56012099006|6133799003|4143699003|22082099003|18002099003|11063799006|5023799004;
X-Microsoft-Antispam-Message-Info:
	IBU3JPj2SRF6hjf5N9CyxKF7c78K3LyGWsMimwtDOMrSRkQT57BRSDmAPm6NioL/C+/tWTSzi4rOhIFKShyYfYhq2Xztl+1bWxmIP8I+whuSgc3+OfB+w8Q9JpneXukRz0kWK2ghWNq2YriYI6uHQC0BAz4oEERFZCDAFrjF/ppQebliDlnvtDf9x+CCZ9ndmaUpkBNFIKiEvrg5s2zyGNv1hx2NMKoH7nZ9CuQ2hLWT8nlxVRv2Gb4hdM2u9KjrPLCEbs6FvSEGH4SPdHebxyWuwv8kSfwSdT5PG+vfob9WZZMDc2p5wTBhpIRuxuTCj4KCut3f2Bl2oRXLn3fSpbkgKOJK9p09WzHd7WL7mKk2ZkY8KK3dOSKzs6lnLe0G15YCtOM8YTdvuzcft4q5BWyVO6gOUP4SIFj3S2Th1TIY/aBWZOHltyjUa3GGlDhyUf9wURlaYxcgbvdafRk/DDYPrm7kXPq5VrE1h8/Dx3ioYhI9KQWA4iTCr0dM2jI3Qck1wZgq9g6530KhGURVk+AU9WLmfxV+qC/D7KIZ4uI5rYG54PrGX/04t/auwytWmCP9G5K9w6WMjnlNIwP+ThWv/5MUNwPM24JfDnCNqT3DujK5baK80GGj+hI6fyAPKmgpFjWmY267qel9wjUlVv2w37nA884JzUfmqWagXFI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(10067099003)(56012099006)(6133799003)(4143699003)(22082099003)(18002099003)(11063799006)(5023799004);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QUhpVXNySUt0TEZyVkc0L09jazM0VndHclBTU3J1WU02SHV0RmpjQ2dyZXNw?=
 =?utf-8?B?VCtMN2loR2hXd0oxeUZLYzhFYW01NWJRaHhZV3QwZCtEZm01VjJjQzMremps?=
 =?utf-8?B?NW9QbGF0dUY4VkpGQkNrdkNkeXgwdVhiM0dXTndGenh2dk4zR0FVZkVYWURW?=
 =?utf-8?B?NHFMRzRzcmxUMUlyalVtb0kxOGoySmpmNjdYci9QM2cwTzJGcFl4L21pOTRp?=
 =?utf-8?B?ZmJFU2hKNUFtY09icmRIcnJXdE9ITFNJa0JVZHhBaWVrSHZZRU5OYldjbkpY?=
 =?utf-8?B?Y1phKy9KWFRQTFI0bFZPcGdBOThFR01kZkpzWElqTDdYbWJybXFqTFlkMkJa?=
 =?utf-8?B?SFZVdG8vQXRlY005cDlWbFZFUTl4NjBCTGFLM291b3o0UkhLSldzSy9hU0pI?=
 =?utf-8?B?Ukp5M1Q4QWZyNkk1RStlRnd0YW1hNG9ZVGZURlErMnRZZkdsUTZock9IL3lD?=
 =?utf-8?B?cjRDc0gvTzcweEtja3hYL1o2TnRpeG1YQXRSRDhWSmFPZVIxRXg3MDNsMXpH?=
 =?utf-8?B?eXZJWHpUcU03UFJhUkQ4am1sZ0JkazlzcFNyTTg4dngrVzhKUUVkU2xQT0xw?=
 =?utf-8?B?TTJoZ3dvWnZvTEZYS3pvay9ScCttK1NBWDlFanROWkpaaW5HeklGaFh3WERm?=
 =?utf-8?B?MHFGU2FxMHBlYTdhcDY0bFVla2tSbXorUUR6M1BsTUZGNFBVcXgxaGpTWitn?=
 =?utf-8?B?Ymt5dXVvUk8xRFZuQ3M3b0hML0Njb3FmbGZKalRTSUJMM0o4SC9oSlRmdGli?=
 =?utf-8?B?T21yaE9kY1VpVG9PZU5GT0hvazAraHVXL2V1YjhlMHVJbjNtM0lmRHplWm5T?=
 =?utf-8?B?ajBvemcxYXFNY3F2a0JEWi9PbXZwdmg0RDJtV1NsdnhoTVRsQWRObmNXaFF0?=
 =?utf-8?B?RWZycDF6RGFScVV6a3c4dTRaekxMdXppRkpqeThPUlpIM1Q5cHJPTnhtYmcx?=
 =?utf-8?B?bVV0OVNxSjBjei9pR1NxeXJBQU9qRUg4TlMwaFpUb2RUUzBQczVRUkJmWFls?=
 =?utf-8?B?aHU3eEFjYzBFS0RlTzR3L0NmeWcrbXNqbC85elAzWmRZYmpIMCtpUnlXd0lL?=
 =?utf-8?B?bHV1Y3JEUG1PK0ZCM3RrYzkvQ0hqZnYzYzFqRFBaclZaK2hhMDJJWE53ZGxi?=
 =?utf-8?B?aloxbHlzS3gxZkZsWTZyQmV4WXozQTY1ZEF3SnhHL0VFNUlsb0lUaVFyMDI1?=
 =?utf-8?B?V1RjM0xWNWZkRWlJQjZ5OGpGUmJvbzBvbDBsSGxBMnBZTmY2Tm1DRHhjdEt2?=
 =?utf-8?B?Sk5SdnUwTktuYWhWbFVjb01lQ3FVc3Z1NnhjUkg0dGJ4UC84VEJVRTVjRjBn?=
 =?utf-8?B?aGtGd0VxQnQwN2FVNEZOMjY5NXI4QXlobVI0MmM3aVozMDE0QmRTaWJsb2Vu?=
 =?utf-8?B?N2RGRVhoMmFYTWdrZnp1aG94WlFBZkROQStaUCtXU1ZZMmtJMVBCaThiNU9I?=
 =?utf-8?B?RGZSckpSYWptTVo0NlBjMkZoeDNuQzJ6Qkd2VUpJNGYrQlo4SUFlbGdKOFBE?=
 =?utf-8?B?c21UWndHODdvVFV5R0tDb2Iya0tha3dQUkw2bkNRVVVLSVNiTGgrSEVpU1pu?=
 =?utf-8?B?a2pQU3ZLTll0eDdDUjBhWUJXUHFzUktSRGtXUVpvMmJkaC9hdWVOVWZTRW0z?=
 =?utf-8?B?V201d2N6ajNNQ0x4Y2k2emovQkphdktjeGQyWW1ad3loelFWTkg4M285RHM2?=
 =?utf-8?B?NlhXTk9lTXpOeFJSMWdsdFl1V29GbzlWZkdWRzc2aHRnL0hHK3FpYWJGaTlB?=
 =?utf-8?B?d2VrOVIxa2kzSzdoS3ZqTU4yMWdpNnZDYlVaaFJkViszTWdPZmx2L21sNmtP?=
 =?utf-8?B?RDU5eDFtb3MxVTF3N1lUOTU0b2dvVXpDL3FlYnowN0EvdERlUXdjTThubVZQ?=
 =?utf-8?B?ZW5TSTkvSDFCaEx1K3R4L21zd2JtazFETDE0eFlKRVY4bHN2UzY4WFJIVU93?=
 =?utf-8?B?SFJJR0xIM1k4Y2p0VWhiOHJVUHZ6V2t4OGV2b1AxWkRwaGdzaWx2T2w3ODRZ?=
 =?utf-8?B?Q1I0RnhjN0JqbXh3QmRvc09HbzZiQXNGUkFENk5vL2lGU2g2Y0lTLzFZQitp?=
 =?utf-8?B?ZEVNU1VkbE4yajdCOXhoOGdHVXpXSG1aVzNleGowb3ppZzA3WDVuK0FScGxn?=
 =?utf-8?B?dk55a2kydUc4aHRKUHBnRHJMU1dvRWtOMnI3L05vai9MYWowK2U5SVJWUXVk?=
 =?utf-8?B?N1pza1pEWmVpdEdhT3krNGozN0VmdDR3b3NrbGZHMUQvWTB5b3FHN3RpUFd4?=
 =?utf-8?B?NDgveGRqdFlrdktwM0l5WGRzSkhWNmJyQS81aHA5SHFGclhNbGNaY3ZEd1BO?=
 =?utf-8?B?ajBSczNQdnNweFAwdWp1MkJtRlFOSktTUStRSHJXdE9nTE0vbVZCOWpFRWVY?=
 =?utf-8?Q?8ABarrny95SpMaTw=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dee61821-0ab2-4ef7-7319-08defdfacd60
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 14:04:36.3207
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: thn7VcrzH5KdwJwF/TsbxXzCqreEkctfdBcwyLqJ7yfmuOXtFGlin2Evsf7Krm4rNQ6uCoo/cjdbK6/XgldZRgFRxXlCuIo7Se9f16cZsjg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5771
X-purgate-ID: tlsNG-c201ff/1787148279-728B62A1-084CA0E4/0/0
X-purgate-type: clean
X-purgate-size: 4172

On 19/08/2026 12:56 pm, Jan Beulich wrote:
> On 19.08.2026 13:13, Andrew Cooper wrote:
>> On 18/08/2026 3:31 pm, Jan Beulich wrote:
>>> On 18.08.2026 15:07, Andrew Cooper wrote:
>>>> Panicing in the case of a timeout turns out to be about the worst possible
>>>> action Xen can take.  It leaves all other APs waiting on the condition
>>>> variable, some in NMI context.  As a result, they fail to be shot down and
>>>> dump state for kexec crash analysis.
>>> At the same time there likely isn't much to be learned from a kexec dump, as
>>> the source of the issue is in the CPU, not in Xen.
>> The single most valuable print message I've ever added to Xen is the one
>> which reports which CPUs didn't respond to NMIs.  Up until now, it has
>> always highlighted hardware issues.
>>
>> Despite my wish to remove this panic specifically, there is still
>> information to be gained from kexec in a similar scenario.
> That is you think of a system without console, where those log messages would
> only be possible to fish out of the dump. Fair enough.

Yes.  This covers approximately all of XenServer deployments.

>
>>> Further, this code runs with the watchdog disabled. If there's truly no
>>> progress anymore, how would one know from the outside whether the system is
>>> dead altogether vs the control CPU still kicking around?
>> The scenario you describe can only occur if the BSP accepts the
>> microcode successfully, and one of the APs locks up properly.
>>
>> If the BSP locks up, we never get as far as deciding to panic(), and the
>> system hangs already.
>>
>> If we have a bad microcode, it is far more likely for the BSP to hang
>> than for the BSP to work one of the APs hang.
> Hmm, probably. (I'm always having in mind the one old system I have where only
> the primary cores on each socket get ucode updated by firmware, with secondary
> cores needing us to deal with them.) Still somewhat hesitantly:
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

>
>>>> Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
>>>> excess of the of the arbitrary 1s Xen allows.  This time is spent in the WRMSR
>>>> to load the blob, and there's nothing the system can do but to sit and wait.
>>>> Despite the delay, the system as a whole does survive.
>>> For this I wonder whether the log message issues after 1 sec is adequate. If
>>> we know things can take this long, wouldn't we better issue the log message
>>> no earlier than, say, 5s * nr_sockets?
>> I have some work there not submitted yet, which would periodically print
>> a message.  That at least gives you slight signs of life.
>>
>> But nothing involving nr_sockets.  It's far more often wrong than it is
>> right, and that's not how our algorithm scales.
>>
>> GNR has gone from milliseconds to 4.5s.  Putting the limit at 5s is just
>> going to need another change in a year or two.
> That's one possibility, yes. The other is that they realize that they have to
> bring processing time back down.

I'm still trying to get details out of Intel, but I strongly suspect the
massive jump here is because of the introduction of the Ucode Staging
Buffer.

Even the architectural description is:

IA32_MCU_ENUMERATION (0x7b), bit 4: MCU_STAGING
"When set to 1, indicates that the microcode update staging capability
is supported by the processor. When supported, the use of the MCU
staging capability is recommended to reduce the latency of the
IA32_BIOS_UPDT_TRIG operation."

which all-but-says "high latency now expected".

When the staging buffer is primed properly, it gets back down to a
reasonable time, but I have no idea when we're going to be able to
support that, and in the meantime running xen-ucode needs to not crash.

One other idea I had:

If we rearrange the loop to have a periodic "taken $X seconds" (shows
liveness), and maybe at 40s decide to panic (by passing through the out:
label first so we release the APs, so they can crash more cleanly), then
that might be acceptable.

By 40s, the system isn't surviving even if the cores do all come back.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 14:29:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 14:29:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395444.1633812 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhIf-00073c-73; Wed, 19 Aug 2026 14:29:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395444.1633812; Wed, 19 Aug 2026 14:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhIf-00073V-3Q; Wed, 19 Aug 2026 14:29:53 +0000
Received: by outflank-mailman (input) for mailman id 1395444;
 Wed, 19 Aug 2026 14:29:52 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dg@treblig.org>) id 1wwhId-00073P-FY
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:29:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhIc-00F4LY-0N; Wed, 19 Aug 2026 16:29:50 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dg@treblig.org>)
 id 6a85bddd-2eae-0a2a0a5409dd-0a2a4507c3ee-0
 for <multiple-recipients>; Wed, 19 Aug 2026 16:29:49 +0200
Received: from [46.235.229.95] (helo=mx.treblig.org)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dg@treblig.org>)
 id 6a85bddc-b4ea-0a2a45070019-2eebe55f86ca-3
 for <multiple-recipients>; Wed, 19 Aug 2026 16:29:49 +0200
Received: from dg by mx.treblig.org with local (Exim 4.98.2)
 (envelope-from <dg@treblig.org>) id 1wwhIS-00000003ACe-15ee;
 Wed, 19 Aug 2026 14:29:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=bytemarkmx header.d=treblig.org header.i="@treblig.org" header.h="Content-Type:MIME-Version:Message-ID:Subject:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org
	; s=bytemarkmx; h=Content-Type:MIME-Version:Message-ID:Subject:From:Date:From
	:Subject; bh=jwGFj3dk7bRsmCsMxl/8zlgj8+Yd7iw52L+ctAQptL0=; b=la0Zcbo6bws+LX7c
	tyMBMAqD9oSk+niuKRwvcAUkz9bkmPFmfKSDPZfE21NmZwguFSjJS4xmj0IoRseCvobFtTCp7kOSU
	A9pe/rfpmK3CU8OOuZjBoRG7sVT0cydXiX5d0CNUq3gsiCrCugFqYHpg833BHcK5WA4kKn7aIbMn9
	SRWhyG6EAqeO4ML4TmSQTCwguoP1HhktToX2fuPfUIW2OocmEtxTeAXlZ7JXY4eNZ2RsvSEpkI0eF
	OK4kjNy6ld3tjiOzNduGgqeoqsWrP1YTTpqlNSYydajUaLQl5TVROl6Lno5oPU3RnlfcHTEtSHnWd
	8vUzl4dKnwrFbovJAw==;
Date: Wed, 19 Aug 2026 14:29:40 +0000
From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org,
	Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <philmd@mailo.com>,
	Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= <berrange@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alex =?iso-8859-1?Q?Benn=E9e?= <alex.bennee@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
	Ani Sinha <anisinha@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Brian Cain <brian.cain@oss.qualcomm.com>,
	David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Eric Farman <farman@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	David Hildenbrand <david@kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Hyman Huang <infra.ai.cloud@bitdeer.com>,
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>,
	Chinmay Rath <rathc@linux.ibm.com>,
	Glenn Miles <milesg@linux.ibm.com>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Weiwei Li <liwei1518@gmail.com>,
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
	Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
	Chao Liu <chao.liu@processmission.com>,
	Yoshinori Sato <yoshinori.sato@nifty.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org,
	kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
Subject: Re: [PATCH v3 37/49] monitor: tighten monitor_printf*()
Message-ID: <aoW91OUi2w68yBTR@gallifrey>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
 <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com>
X-Chocolate: 70 percent or better cocoa solids preferably
X-Operating-System: Linux/6.12.101+deb13-amd64 (x86_64)
X-Uptime: 14:28:01 up 12 days, 18:05,  3 users,  load average: 0.05, 0.05,
 0.00
User-Agent: Mutt/2.2.13 (2024-03-09)
X-purgate-ID: tlsNG-ef75cf/1787149789-35EC6944-FC3AC186/0/0
X-purgate-type: clean
X-purgate-size: 281561

* Marc-Andr� Lureau (marcandre.lureau@redhat.com) wrote:
> Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> the first parameter from Monitor * to MonitorHMP * to enforce type
> safety. The implementation is also simplified: monitor_hmp_vprintf now
> directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> dispatch via moncls->vprintf.
> 
> The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> cast, they are fixed in the following commits.
> 
> Signed-off-by: Marc-Andr� Lureau <marcandre.lureau@redhat.com>

Hmm, this patch is HUGE.
What are the chances of anyone being able to apply this without it conflicting
in a bunch of places?
Wouldn't it be better to split it into adding the monitor_hmp_ named versions,
then splitting the uses into one patch by area and then
trickling them in?

Dave

> ---
>  audio/audio-hmp-cmds.c                  |   6 +-
>  backends/cryptodev-hmp-cmds.c           |   9 +-
>  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
>  chardev/char-hmp-cmds.c                 |  12 +-
>  disas/disas-mon.c                       |  10 +-
>  docs/devel/style.rst                    |   2 +-
>  docs/devel/writing-monitor-commands.rst |   8 +-
>  dump/dump-hmp-cmds.c                    |   5 +-
>  hw/char/virtio-serial-bus.c             |  10 +-
>  hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
>  hw/core/sysbus.c                        |   5 +-
>  hw/hexagon/hexagon_tlb.c                |  44 ++---
>  hw/i386/kvm/xen-stubs.c                 |   6 +-
>  hw/i386/kvm/xen_evtchn.c                |  21 +--
>  hw/i386/sgx-hmp-stub.c                  |   3 +-
>  hw/i386/sgx.c                           |  29 ++-
>  hw/misc/auxbus.c                        |   9 +-
>  hw/misc/mos6522-stub.c                  |   3 +-
>  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++-------
>  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
>  hw/pci/pci-stub.c                       |   3 +-
>  hw/s390x/s390-skeys.c                   |   9 +-
>  hw/s390x/s390-stattrib.c                |  20 +--
>  hw/uefi/ovmf-log.c                      |   5 +-
>  hw/usb/bus.c                            |  11 +-
>  hw/usb/host-libusb.c                    |  21 ++-
>  hw/virtio/virtio-hmp-cmds.c             | 297 +++++++++++++++----------------
>  hw/xen/xen-bus.c                        |   5 +-
>  include/disas/disas.h                   |   4 +-
>  include/monitor/hmp.h                   |  12 +-
>  migration/dirtyrate.c                   |  46 +++--
>  migration/migration-hmp-cmds.c          | 305 ++++++++++++++++----------------
>  monitor/hmp-cmds.c                      | 141 +++++++--------
>  monitor/hmp.c                           | 143 +++++++--------
>  monitor/monitor-internal.h              |   6 -
>  monitor/monitor.c                       |  33 ++--
>  net/net-hmp-cmds.c                      |  31 ++--
>  net/slirp.c                             |  31 ++--
>  qom/qom-hmp-cmds.c                      |  27 ++-
>  replay/replay-debugging.c               |   5 +-
>  stats/stats-hmp-cmds.c                  |  57 +++---
>  stubs/hmp-cmd-info_sev.c                |   3 +-
>  stubs/monitor-core.c                    |   2 +-
>  system/dirtylimit-hmp-cmds.c            |  10 +-
>  system/qdev-monitor.c                   |  19 +-
>  system/runstate-hmp-cmds.c              |  16 +-
>  system/tpm-hmp-cmds.c                   |  29 ++-
>  target/i386/cpu-apic.c                  |   3 +-
>  target/i386/monitor.c                   | 152 ++++++++--------
>  target/i386/sev.c                       |  35 ++--
>  target/m68k/monitor.c                   |   3 +-
>  target/ppc/monitor.c                    |   3 +-
>  target/riscv/monitor.c                  |  55 +++---
>  target/sh4/monitor.c                    |  29 ++-
>  target/sparc/monitor.c                  |   3 +-
>  target/xtensa/monitor.c                 |   3 +-
>  tests/unit/test-util-sockets.c          |   2 +-
>  tools/qemu-vnc/clipboard.c              |   4 +-
>  tools/qemu-vnc/stubs.c                  |   2 +-
>  trace/trace-hmp-cmds.c                  |  12 +-
>  ui/ui-hmp-cmds.c                        | 115 ++++++------
>  util/error-report.c                     |   2 +-
>  util/qemu-print.c                       |   4 +-
>  63 files changed, 1214 insertions(+), 1329 deletions(-)
> 
> diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
> index 4d326ec99fdf..94182fe1d71f 100644
> --- a/audio/audio-hmp-cmds.c
> +++ b/audio/audio-hmp-cmds.c
> @@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
>  
>  void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int i;
>      CaptureState *s;
>  
>      warn_report_once("'info capture' is deprecated since v10.2, to be removed");
>  
>      for (s = capture_head.lh_first, i = 0; s; s = s->entries.le_next, ++i) {
> -        monitor_printf(mon, "[%d]: ", i);
> +        monitor_hmp_printf(hmp, "[%d]: ", i);
>          s->ops.info (s->opaque);
>      }
>  }
> @@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *path = qdict_get_str(qdict, "path");
>      int freq = qdict_get_try_int(qdict, "freq", 44100);
>      int bits = qdict_get_try_int(qdict, "bits", 16);
> @@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
>      s = g_malloc0 (sizeof (*s));
>  
>      if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
> -        monitor_printf(mon, "Failed to add wave capture\n");
> +        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
>          g_free (s);
>          return;
>      }
> diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
> index fb62428d795a..aafa4b970d24 100644
> --- a/backends/cryptodev-hmp-cmds.c
> +++ b/backends/cryptodev-hmp-cmds.c
> @@ -19,7 +19,6 @@
>  
>  void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      QCryptodevInfoList *il;
>      QCryptodevBackendServiceTypeList *sl;
>      QCryptodevBackendClientList *cl;
> @@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
>                  services = tmp_services;
>              }
>          }
> -        monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
> +        monitor_hmp_printf(hmp, "%s: service=[%s]\n", info->id, services);
>  
>          for (cl = info->client; cl; cl = cl->next) {
>              QCryptodevBackendClient *client = cl->value;
> -            monitor_printf(mon, "    queue %" PRIu32 ": type=%s\n",
> -                           client->queue,
> -                           QCryptodevBackendType_str(client->type));
> +            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=%s\n",
> +                               client->queue,
> +                               QCryptodevBackendType_str(client->type));
>          }
>      }
>  
> diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-cmds.c
> index a2666e2f1b9b..7bae4d425c6d 100644
> --- a/block/monitor/block-hmp-cmds.c
> +++ b/block/monitor/block-hmp-cmds.c
> @@ -89,7 +89,6 @@ out:
>  
>  void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      DriveInfo *dinfo;
>      QemuOpts *opts;
> @@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
>  
>      switch (dinfo->type) {
>      case IF_NONE:
> -        monitor_printf(mon, "OK\n");
> +        monitor_hmp_printf(hmp, "OK\n");
>          break;
>      default:
>          error_setg(&err, "Can't hot-add drive to type %d", dinfo->type);
> @@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdict)
>      hmp_handle_error(hmp, err);
>  }
>  
> -static void print_block_info(Monitor *mon, BlockInfo *info,
> +static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
>                               BlockDeviceInfo *inserted, bool verbose)
>  {
> +    Monitor *mon = MONITOR(hmp);
>      ImageInfo *image_info;
>  
>      assert(!info || !info->inserted || info->inserted == inserted);
> @@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
>      if (info && *info->device) {
>          monitor_puts(mon, info->device);
>          if (inserted && inserted->node_name) {
> -            monitor_printf(mon, " (%s)", inserted->node_name);
> +            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
>          }
>      } else {
>          assert(info || inserted);
> @@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
>      }
>  
>      if (inserted) {
> -        monitor_printf(mon, ": %s (%s%s%s%s)\n",
> -                       inserted->file,
> -                       inserted->drv,
> -                       inserted->ro ? ", read-only" : "",
> -                       inserted->encrypted ? ", encrypted" : "",
> -                       inserted->active ? "" : ", inactive");
> +        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
> +                           inserted->file,
> +                           inserted->drv,
> +                           inserted->ro ? ", read-only" : "",
> +                           inserted->encrypted ? ", encrypted" : "",
> +                           inserted->active ? "" : ", inactive");
>      } else {
> -        monitor_printf(mon, ": [not inserted]\n");
> +        monitor_hmp_printf(hmp, ": [not inserted]\n");
>      }
>  
>      if (info) {
>          if (info->qdev) {
> -            monitor_printf(mon, "    Attached to:      %s\n", info->qdev);
> +            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info->qdev);
>          }
>          if (info->has_io_status && info->io_status != BLOCK_DEVICE_IO_STATUS_OK) {
> -            monitor_printf(mon, "    I/O status:       %s\n",
> -                           BlockDeviceIoStatus_str(info->io_status));
> +            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
> +                               BlockDeviceIoStatus_str(info->io_status));
>          }
>  
>          if (info->removable) {
> -            monitor_printf(mon, "    Removable device: %slocked, tray %s\n",
> -                           info->locked ? "" : "not ",
> -                           info->tray_open ? "open" : "closed");
> +            monitor_hmp_printf(hmp, "    Removable device: %slocked, tray %s\n",
> +                               info->locked ? "" : "not ",
> +                               info->tray_open ? "open" : "closed");
>          }
>      }
>  
> @@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
>          return;
>      }
>  
> -    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
> -                   inserted->cache->writeback ? "writeback" : "writethrough",
> -                   inserted->cache->direct ? ", direct" : "",
> -                   inserted->cache->no_flush ? ", ignore flushes" : "");
> +    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
> +                       inserted->cache->writeback ? "writeback" : "writethrough",
> +                       inserted->cache->direct ? ", direct" : "",
> +                       inserted->cache->no_flush ? ", ignore flushes" : "");
>  
>      if (inserted->backing_file) {
> -        monitor_printf(mon,
> -                       "    Backing file:     %s "
> -                       "(chain depth: %" PRId64 ")\n",
> -                       inserted->backing_file,
> -                       inserted->backing_file_depth);
> +        monitor_hmp_printf(hmp,
> +                           "    Backing file:     %s "
> +                           "(chain depth: %" PRId64 ")\n",
> +                           inserted->backing_file,
> +                           inserted->backing_file_depth);
>      }
>  
>      if (inserted->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF) {
> -        monitor_printf(mon, "    Detect zeroes:    %s\n",
> +        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
>                  BlockdevDetectZeroesOptions_str(inserted->detect_zeroes));
>      }
>  
>      if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
>          inserted->iops || inserted->iops_rd || inserted->iops_wr)
>      {
> -        monitor_printf(mon, "    I/O throttling:   bps=%" PRId64
> +        monitor_hmp_printf(hmp, "    I/O throttling:   bps=%" PRId64
>                          " bps_rd=%" PRId64  " bps_wr=%" PRId64
>                          " bps_max=%" PRId64
>                          " bps_rd_max=%" PRId64
> @@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
>      }
>  
>      if (verbose) {
> -        monitor_printf(mon, "\nImages:\n");
> +        monitor_hmp_printf(hmp, "\nImages:\n");
>          image_info = inserted->image;
>          while (1) {
>              bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, false);
> @@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
>  
>  void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      BlockInfoList *block_list, *info;
>      BlockDeviceInfoList *blockdev_list, *blockdev;
>      const char *device = qdict_get_try_str(qdict, "device");
> @@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
>          }
>  
>          if (info != block_list) {
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>  
> -        print_block_info(mon, info->value, info->value->inserted,
> +        print_block_info(hmp, info->value, info->value->inserted,
>                           verbose);
>          printed = true;
>      }
> @@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
>          }
>  
>          if (blockdev != blockdev_list) {
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>  
> -        print_block_info(mon, NULL, blockdev->value, verbose);
> +        print_block_info(hmp, NULL, blockdev->value, verbose);
>      }
>      qapi_free_BlockDeviceInfoList(blockdev_list);
>  }
>  
>  void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      BlockStatsList *stats_list, *stats;
>  
>      stats_list = qmp_query_blockstats(false, false, NULL);
> @@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
>              continue;
>          }
>  
> -        monitor_printf(mon, "%s%s: idle_time_ns=%" PRId64 "\n",
> -                       stats != stats_list ? "\n" : "",
> -                       stats->value->device,
> -                       stats->value->stats->idle_time_ns);
> -        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
> -                       "operations", "total_time_ns", "merged");
> -        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
> -                       " %10" PRId64 "\n",
> -                       stats->value->stats->rd_bytes,
> -                       stats->value->stats->rd_operations,
> -                       stats->value->stats->rd_total_time_ns,
> -                       stats->value->stats->rd_merged);
> -        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
> -                       " %10" PRId64 "\n",
> -                       stats->value->stats->wr_bytes,
> -                       stats->value->stats->wr_operations,
> -                       stats->value->stats->wr_total_time_ns,
> -                       stats->value->stats->wr_merged);
> -        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
> -                       "",
> -                       stats->value->stats->flush_operations,
> -                       stats->value->stats->flush_total_time_ns);
> +        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=%" PRId64 "\n",
> +                           stats != stats_list ? "\n" : "",
> +                           stats->value->device,
> +                           stats->value->stats->idle_time_ns);
> +        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes",
> +                           "operations", "total_time_ns", "merged");
> +        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
> +                           " %10" PRId64 "\n",
> +                           stats->value->stats->rd_bytes,
> +                           stats->value->stats->rd_operations,
> +                           stats->value->stats->rd_total_time_ns,
> +                           stats->value->stats->rd_merged);
> +        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
> +                           " %10" PRId64 "\n",
> +                           stats->value->stats->wr_bytes,
> +                           stats->value->stats->wr_operations,
> +                           stats->value->stats->wr_total_time_ns,
> +                           stats->value->stats->wr_merged);
> +        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
> +                           "",
> +                           stats->value->stats->flush_operations,
> +                           stats->value->stats->flush_total_time_ns);
>      }
>  
>      qapi_free_BlockStatsList(stats_list);
> @@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      BlockJobInfoList *list;
>  
>      list = qmp_query_block_jobs(&error_abort);
>  
>      if (!list) {
> -        monitor_printf(mon, "No active jobs\n");
> +        monitor_hmp_printf(hmp, "No active jobs\n");
>          return;
>      }
>  
>      while (list) {
>          if (list->value->type == JOB_TYPE_STREAM) {
> -            monitor_printf(mon, "Streaming device %s: Completed %" PRId64
> -                           " of %" PRId64 " bytes, speed limit %" PRId64
> -                           " bytes/s\n",
> -                           list->value->device,
> -                           list->value->offset,
> -                           list->value->len,
> -                           list->value->speed);
> +            monitor_hmp_printf(hmp, "Streaming device %s: Completed %" PRId64
> +                               " of %" PRId64 " bytes, speed limit %" PRId64
> +                               " bytes/s\n",
> +                               list->value->device,
> +                               list->value->offset,
> +                               list->value->len,
> +                               list->value->speed);
>          } else {
> -            monitor_printf(mon, "Type %s, device %s: Completed %" PRId64
> -                           " of %" PRId64 " bytes, speed limit %" PRId64
> -                           " bytes/s\n",
> -                           JobType_str(list->value->type),
> -                           list->value->device,
> -                           list->value->offset,
> -                           list->value->len,
> -                           list->value->speed);
> +            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" PRId64
> +                               " of %" PRId64 " bytes, speed limit %" PRId64
> +                               " bytes/s\n",
> +                               JobType_str(list->value->type),
> +                               list->value->device,
> +                               list->value->offset,
> +                               list->value->len,
> +                               list->value->speed);
>          }
>          list = list->next;
>      }
> @@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      BlockDriverState *bs, *bs1;
>      BdrvNextIterator it1;
>      QEMUSnapshotInfo *sn_tab, *sn;
> @@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
>      nb_sns = bdrv_snapshot_list(bs, &sn_tab);
>  
>      if (nb_sns < 0) {
> -        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
> +        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_sns);
>          return;
>      }
>  
> @@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
>      }
>  
>      if (no_snapshot) {
> -        monitor_printf(mon, "There is no snapshot available.\n");
> +        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
>          return;
>      }
>  
> @@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
>              }
>          }
>      }
> -    monitor_printf(mon, "List of snapshots present on all disks:\n");
> +    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n");
>  
>      if (total > 0) {
>          bdrv_snapshot_dump(NULL);
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>          for (i = 0; i < total; i++) {
>              sn = &sn_tab[global_snapshots[i]];
>              /*
> @@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
>               */
>              pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
>              bdrv_snapshot_dump(sn);
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>      } else {
> -        monitor_printf(mon, "None\n");
> +        monitor_hmp_printf(hmp, "None\n");
>      }
>  
>      QTAILQ_FOREACH(image_entry, &image_list, next) {
>          if (QTAILQ_EMPTY(&image_entry->snapshots)) {
>              continue;
>          }
> -        monitor_printf(mon,
> -                       "\nList of partial (non-loadable) snapshots on '%s':\n",
> -                       image_entry->imagename);
> +        monitor_hmp_printf(hmp,
> +                           "\nList of partial (non-loadable) snapshots on '%s':\n",
> +                           image_entry->imagename);
>          bdrv_snapshot_dump(NULL);
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>          QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) {
>              bdrv_snapshot_dump(&snapshot_entry->sn);
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>      }
>  
> @@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
>      g_free(global_snapshots);
>  }
>  
> -void hmp_change_medium(Monitor *mon, const char *device, const char *target,
> +void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
>                         const char *arg, const char *read_only, bool force,
>                         Error **errp)
>  {
> diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
> index 71017fd2d19e..fb0560054b7b 100644
> --- a/chardev/char-hmp-cmds.c
> +++ b/chardev/char-hmp-cmds.c
> @@ -26,12 +26,11 @@
>  
>  void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      ChardevInfoList *char_info, *info;
>  
>      char_info = qmp_query_chardev(NULL);
>      for (info = char_info; info; info = info->next) {
> -        monitor_printf(mon, "%s: filename=%s\n", info->value->label,
> +        monitor_hmp_printf(hmp, "%s: filename=%s\n", info->value->label,
>                                                   info->value->filename);
>      }
>  
> @@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      uint32_t size = qdict_get_int(qdict, "size");
>      const char *chardev = qdict_get_str(qdict, "device");
>      char *data;
> @@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
>          unsigned char ch = data[i];
>  
>          if (ch == '\\') {
> -            monitor_printf(mon, "\\\\");
> +            monitor_hmp_printf(hmp, "\\\\");
>          } else if ((ch < 0x20 && ch != '\n' && ch != '\t') || ch == 0x7F) {
> -            monitor_printf(mon, "\\u%04X", ch);
> +            monitor_hmp_printf(hmp, "\\u%04X", ch);
>          } else {
> -            monitor_printf(mon, "%c", ch);
> +            monitor_hmp_printf(hmp, "%c", ch);
>          }
>  
>      }
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>      g_free(data);
>  }
>  
> diff --git a/disas/disas-mon.c b/disas/disas-mon.c
> index bc9dec3a7761..32e4220181a8 100644
> --- a/disas/disas-mon.c
> +++ b/disas/disas-mon.c
> @@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
>  }
>  
>  /* Disassembler for the monitor.  */
> -void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> +void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
>                     int nb_insn, bool is_physical)
>  {
>      int count, i;
> @@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
>      s.info.buffer_vma = pc;
>  
>      if (s.info.cap_arch >= 0 && cap_disas_monitor(&s.info, pc, nb_insn)) {
> -        monitor_puts(mon, ds->str);
> +        monitor_puts(MONITOR(hmp), ds->str);
>          return;
>      }
>  
>      if (!s.info.print_insn) {
> -        monitor_printf(mon, "0x%08" PRIx64
> -                       ": Asm output not supported on this arch\n", pc);
> +        monitor_hmp_printf(hmp, "0x%08" PRIx64
> +                           ": Asm output not supported on this arch\n", pc);
>          return;
>      }
>  
> @@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
>          pc += count;
>      }
>  
> -    monitor_puts(mon, ds->str);
> +    monitor_puts(MONITOR(hmp), ds->str);
>  }
> diff --git a/docs/devel/style.rst b/docs/devel/style.rst
> index 6c5f94cc5098..6876d3a59ec7 100644
> --- a/docs/devel/style.rst
> +++ b/docs/devel/style.rst
> @@ -754,7 +754,7 @@ Error handling and reporting
>  Reporting errors to the human user
>  ----------------------------------
>  
> -Do not use printf(), fprintf() or monitor_printf().  Instead, use
> +Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
>  error_report() or error_vreport() from error-report.h.  This ensures the
>  error is reported in the right place (current monitor or stderr), and in
>  a uniform format.
> diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
> index 7ae7efe32759..baf94cbdefab 100644
> --- a/docs/devel/writing-monitor-commands.rst
> +++ b/docs/devel/writing-monitor-commands.rst
> @@ -479,7 +479,7 @@ The HMP command
>  
>  Here's the HMP counterpart of the query-option-roms command::
>  
> - void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
> + void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
>   {
>       Error *err = NULL;
>       OptionRomInfoList *info_list, *tail;
> @@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-roms command::
>  
>       for (tail = info_list; tail; tail = tail->next) {
>           info = tail->value;
> -         monitor_printf(mon, "%s", info->filename);
> +         monitor_hmp_printf(mon, "%s", info->filename);
>           if (info->has_bootindex) {
> -             monitor_printf(mon, " %" PRId64, info->bootindex);
> +             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
>           }
> -         monitor_printf(mon, "\n");
> +         monitor_hmp_printf(mon, "\n");
>       }
>  
>       qapi_free_OptionRomInfoList(info_list);
> diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
> index 104ab5d2a53a..c7045c2d7314 100644
> --- a/dump/dump-hmp-cmds.c
> +++ b/dump/dump-hmp-cmds.c
> @@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      DumpQueryResult *result = qmp_query_dump(NULL);
>  
>      assert(result && result->status < DUMP_STATUS__MAX);
> -    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status));
> +    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->status));
>  
>      if (result->status == DUMP_STATUS_ACTIVE) {
>          float percent = 0;
>          assert(result->total != 0);
>          percent = 100.0 * result->completed / result->total;
> -        monitor_printf(mon, "Finished: %.2f %%\n", percent);
> +        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
>      }
>  
>      qapi_free_DumpQueryResult(result);
> diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
> index 02604740f86a..33fdc0846ac3 100644
> --- a/hw/char/virtio-serial-bus.c
> +++ b/hw/char/virtio-serial-bus.c
> @@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
>  {
>      VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
>  
> -    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
> -                   indent, "", port->id,
> -                   port->guest_connected ? "on" : "off",
> -                   port->host_connected ? "on" : "off",
> -                   port->throttled ? "on" : "off");
> +    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
> +                       indent, "", port->id,
> +                       port->guest_connected ? "on" : "off",
> +                       port->host_connected ? "on" : "off",
> +                       port->throttled ? "on" : "off");
>  }
>  
>  /* This function is only used if a port id is not provided by the user */
> diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
> index 702c798ccc56..10a633af0780 100644
> --- a/hw/core/machine-hmp-cmds.c
> +++ b/hw/core/machine-hmp-cmds.c
> @@ -27,7 +27,6 @@
>  
>  void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CpuInfoFastList *cpu_list, *cpu;
>  
>      cpu_list = qmp_query_cpus_fast(NULL);
> @@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
>              active = '*';
>          }
>  
> -        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
> -                       cpu->value->cpu_index);
> -        monitor_printf(mon, " thread_id=%" PRId64 " model=%s\n",
> -                       cpu->value->thread_id, cpu_model);
> +        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
> +                           cpu->value->cpu_index);
> +        monitor_hmp_printf(hmp, " thread_id=%" PRId64 " model=%s\n",
> +                           cpu->value->thread_id, cpu_model);
>      }
>  
>      qapi_free_CpuInfoFastList(cpu_list);
> @@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      HotpluggableCPUList *l = qmp_query_hotpluggable_cpus(&err);
>      HotpluggableCPUList *saved = l;
> @@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "Hotpluggable CPUs:\n");
> +    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
>      while (l) {
> -        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
> -        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
> -                       l->value->vcpus_count);
> +        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
> +        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
> +                           l->value->vcpus_count);
>          if (l->value->qom_path) {
> -            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_path);
> +            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->qom_path);
>          }
>  
>          c = l->value->props;
> -        monitor_printf(mon, "  CPUInstance Properties:\n");
> +        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
>          if (c->has_node_id) {
> -            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
> +            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
>          }
>          if (c->has_drawer_id) {
> -            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
> +            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
>          }
>          if (c->has_book_id) {
> -            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
> +            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
>          }
>          if (c->has_socket_id) {
> -            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
> +            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
>          }
>          if (c->has_die_id) {
> -            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
> +            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
>          }
>          if (c->has_cluster_id) {
> -            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
> -                           c->cluster_id);
> +            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n",
> +                               c->cluster_id);
>          }
>          if (c->has_module_id) {
> -            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
> -                           c->module_id);
> +            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n",
> +                               c->module_id);
>          }
>          if (c->has_core_id) {
> -            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
> +            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
>          }
>          if (c->has_thread_id) {
> -            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
> +            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
>          }
>  
>          l = l->next;
> @@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      MemdevList *memdev_list = qmp_query_memdev(&err);
>      MemdevList *m = memdev_list;
> @@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
>      while (m) {
>          v = string_output_visitor_new(false, &str);
>          visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_abort);
> -        monitor_printf(mon, "memory backend: %s\n", m->value->id);
> -        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
> -        monitor_printf(mon, "  merge: %s\n",
> -                       m->value->merge ? "true" : "false");
> -        monitor_printf(mon, "  dump: %s\n",
> -                       m->value->dump ? "true" : "false");
> -        monitor_printf(mon, "  prealloc: %s\n",
> -                       m->value->prealloc ? "true" : "false");
> -        monitor_printf(mon, "  share: %s\n",
> -                       m->value->share ? "true" : "false");
> +        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
> +        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->size);
> +        monitor_hmp_printf(hmp, "  merge: %s\n",
> +                           m->value->merge ? "true" : "false");
> +        monitor_hmp_printf(hmp, "  dump: %s\n",
> +                           m->value->dump ? "true" : "false");
> +        monitor_hmp_printf(hmp, "  prealloc: %s\n",
> +                           m->value->prealloc ? "true" : "false");
> +        monitor_hmp_printf(hmp, "  share: %s\n",
> +                           m->value->share ? "true" : "false");
>          if (m->value->has_reserve) {
> -            monitor_printf(mon, "  reserve: %s\n",
> -                           m->value->reserve ? "true" : "false");
> +            monitor_hmp_printf(hmp, "  reserve: %s\n",
> +                               m->value->reserve ? "true" : "false");
>          }
> -        monitor_printf(mon, "  policy: %s\n",
> -                       HostMemPolicy_str(m->value->policy));
> +        monitor_hmp_printf(hmp, "  policy: %s\n",
> +                           HostMemPolicy_str(m->value->policy));
>          visit_complete(v, &str);
> -        monitor_printf(mon, "  host nodes: %s\n", str);
> +        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
>  
>          g_free(str);
>          visit_free(v);
>          m = m->next;
>      }
>  
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>  
>      qapi_free_MemdevList(memdev_list);
>      hmp_handle_error(hmp, err);
> @@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      KvmInfo *info;
>  
>      info = qmp_query_kvm(NULL);
> -    monitor_printf(mon, "kvm support: ");
> +    monitor_hmp_printf(hmp, "kvm support: ");
>      if (info->present) {
> -        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disabled");
> +        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "disabled");
>      } else {
> -        monitor_printf(mon, "not compiled\n");
> +        monitor_hmp_printf(hmp, "not compiled\n");
>      }
>  
>      qapi_free_KvmInfo(info);
> @@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      AcceleratorInfo *info;
>      AcceleratorList *accel;
>  
> @@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
>      for (accel = info->present; accel; accel = accel->next) {
>          char trail = accel->next ? ' ' : '\n';
>          if (info->enabled == accel->value) {
> -            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value), trail);
> +            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->value), trail);
>          } else {
> -            monitor_printf(mon, "%s%c", Accelerator_str(accel->value), trail);
> +            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->value), trail);
>          }
>      }
>  
> @@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      UuidInfo *info;
>  
>      info = qmp_query_uuid(NULL);
> -    monitor_printf(mon, "%s\n", info->UUID);
> +    monitor_hmp_printf(hmp, "%s\n", info->UUID);
>      qapi_free_UuidInfo(info);
>  }
>  
>  void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      BalloonInfo *info;
>      Error *err = NULL;
>  
> @@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
> +    monitor_hmp_printf(hmp, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
>  
>      qapi_free_BalloonInfo(info);
>  }
> @@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      uint32_t size = qdict_get_int(qdict, "size");
>      const char *filename = qdict_get_str(qdict, "filename");
>      uint64_t addr = qdict_get_int(qdict, "val");
> @@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
>      int cpu_index = monitor_hmp_get_cpu_index(hmp);
>  
>      if (cpu_index < 0) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>  
> @@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      MemoryDeviceInfoList *info_list = qmp_query_memory_devices(&err);
>      MemoryDeviceInfoList *info;
> @@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
>              case MEMORY_DEVICE_INFO_KIND_NVDIMM:
>                  di = value->type == MEMORY_DEVICE_INFO_KIND_DIMM ?
>                       value->u.dimm.data : value->u.nvdimm.data;
> -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> -                               MemoryDeviceInfoKind_str(value->type),
> -                               di->id ? di->id : "");
> -                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->addr);
> -                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot);
> -                monitor_printf(mon, "  node: %" PRId64 "\n", di->node);
> -                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size);
> -                monitor_printf(mon, "  memdev: %s\n", di->memdev);
> -                monitor_printf(mon, "  hotplugged: %s\n",
> -                               di->hotplugged ? "true" : "false");
> -                monitor_printf(mon, "  hotpluggable: %s\n",
> -                               di->hotpluggable ? "true" : "false");
> +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> +                                   MemoryDeviceInfoKind_str(value->type),
> +                                   di->id ? di->id : "");
> +                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di->addr);
> +                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->slot);
> +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->node);
> +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->size);
> +                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
> +                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
> +                                   di->hotplugged ? "true" : "false");
> +                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
> +                                   di->hotpluggable ? "true" : "false");
>                  break;
>              case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
>                  vpi = value->u.virtio_pmem.data;
> -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> -                               MemoryDeviceInfoKind_str(value->type),
> -                               vpi->id ? vpi->id : "");
> -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
> -                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size);
> -                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
> +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> +                                   MemoryDeviceInfoKind_str(value->type),
> +                                   vpi->id ? vpi->id : "");
> +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
> +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->size);
> +                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev);
>                  break;
>              case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
>                  vmi = value->u.virtio_mem.data;
> -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> -                               MemoryDeviceInfoKind_str(value->type),
> -                               vmi->id ? vmi->id : "");
> -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
> -                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node);
> -                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
> -                               vmi->requested_size);
> -                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size);
> -                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->max_size);
> -                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
> -                               vmi->block_size);
> -                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
> +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> +                                   MemoryDeviceInfoKind_str(value->type),
> +                                   vmi->id ? vmi->id : "");
> +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
> +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->node);
> +                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "\n",
> +                                   vmi->requested_size);
> +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->size);
> +                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", vmi->max_size);
> +                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
> +                                   vmi->block_size);
> +                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev);
>                  break;
>              case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
>                  se = value->u.sgx_epc.data;
> -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> -                               MemoryDeviceInfoKind_str(value->type),
> -                               se->id ? se->id : "");
> -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
> -                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size);
> -                monitor_printf(mon, "  node: %" PRId64 "\n", se->node);
> -                monitor_printf(mon, "  memdev: %s\n", se->memdev);
> +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> +                                   MemoryDeviceInfoKind_str(value->type),
> +                                   se->id ? se->id : "");
> +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
> +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->size);
> +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->node);
> +                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
>                  break;
>              case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
>                  hi = value->u.hv_balloon.data;
> -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> -                               MemoryDeviceInfoKind_str(value->type),
> -                               hi->id ? hi->id : "");
> +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> +                                   MemoryDeviceInfoKind_str(value->type),
> +                                   hi->id ? hi->id : "");
>                  if (hi->has_memaddr) {
> -                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
> -                                   hi->memaddr);
> +                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n",
> +                                       hi->memaddr);
>                  }
> -                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->max_size);
> +                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", hi->max_size);
>                  if (hi->memdev) {
> -                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
> +                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memdev);
>                  }
>                  break;
>              case MEMORY_DEVICE_INFO_KIND_SP_MEM:
>                  spmi = value->u.sp_mem.data;
> -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> -                               MemoryDeviceInfoKind_str(value->type),
> -                               spmi->id ? spmi->id : "");
> -                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->addr);
> -                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->node);
> -                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->size);
> -                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
> +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> +                                   MemoryDeviceInfoKind_str(value->type),
> +                                   spmi->id ? spmi->id : "");
> +                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spmi->addr);
> +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi->node);
> +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi->size);
> +                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev);
>                  break;
>              default:
>                  g_assert_not_reached();
> @@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      GuidInfo *info = qmp_query_vm_generation_id(&err);
>      if (info) {
> -        monitor_printf(mon, "%s\n", info->guid);
> +        monitor_hmp_printf(hmp, "%s\n", info->guid);
>      }
>      hmp_handle_error(hmp, err);
>      qapi_free_GuidInfo(info);
> @@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      MemoryInfo *info = qmp_query_memory_size_summary(&err);
>      if (info) {
> -        monitor_printf(mon, "base memory: %" PRIu64 "\n",
> -                       info->base_memory);
> +        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
> +                           info->base_memory);
>  
>          if (info->has_plugged_memory) {
> -            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
> -                           info->plugged_memory);
> +            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
> +                               info->plugged_memory);
>          }
>  
>          qapi_free_MemoryInfo(info);
> diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> index 13df7cbafe10..82130ba04698 100644
> --- a/hw/core/sysbus.c
> +++ b/hw/core/sysbus.c
> @@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
>  static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  {
>      SysBusDevice *s = SYS_BUS_DEVICE(dev);
> +    MonitorHMP *hmp = MONITOR_HMP(mon);
>      hwaddr size;
>      int i;
>  
>      for (i = 0; i < s->num_mmio; i++) {
>          size = memory_region_size(s->mmio[i].memory);
> -        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> -                       indent, "", s->mmio[i].addr, size);
> +        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> +                           indent, "", s->mmio[i].addr, size);
>      }
>  }
>  
> diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
> index 2d878cee736d..576929ff224b 100644
> --- a/hw/hexagon/hexagon_tlb.c
> +++ b/hw/hexagon/hexagon_tlb.c
> @@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t entry)
>  
>  bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
>  {
> +    MonitorHMP *hmp = MONITOR_HMP(mon);
> +
>      if (GET_PTE_V(entry)) {
>          uint64_t PA = hex_tlb_phys_addr(entry);
>          uint64_t VA = hex_tlb_virt_addr(entry);
> -        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
> -        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
> -                       " A1:%" PRId64 " A0:%" PRId64,
> -                       GET_PTE_V(entry),
> -                       GET_PTE_G(entry),
> -                       GET_PTE_ATR1(entry),
> -                       GET_PTE_ATR0(entry));
> -        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
> -                       GET_PTE_ASID(entry), VA);
> -        monitor_printf(mon,
> -                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
> -                       " U:%" PRId64 " C:%" PRId64,
> -                       GET_PTE_X(entry),
> -                       GET_PTE_W(entry),
> -                       GET_PTE_R(entry),
> -                       GET_PTE_U(entry),
> -                       GET_PTE_C(entry));
> -        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
> -                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
> -                       hex_tlb_page_size_bytes(entry));
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
> +        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
> +                           " A1:%" PRId64 " A0:%" PRId64,
> +                           GET_PTE_V(entry),
> +                           GET_PTE_G(entry),
> +                           GET_PTE_ATR1(entry),
> +                           GET_PTE_ATR0(entry));
> +        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
> +                           GET_PTE_ASID(entry), VA);
> +        monitor_hmp_printf(hmp,
> +                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
> +                           " U:%" PRId64 " C:%" PRId64,
> +                           GET_PTE_X(entry),
> +                           GET_PTE_W(entry),
> +                           GET_PTE_R(entry),
> +                           GET_PTE_U(entry),
> +                           GET_PTE_C(entry));
> +        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
> +                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
> +                           hex_tlb_page_size_bytes(entry));
> +        monitor_hmp_printf(hmp, "\n");
>          return true;
>      }
>  
> diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
> index ab1eb14f99e0..5ed71583281a 100644
> --- a/hw/i386/kvm/xen-stubs.c
> +++ b/hw/i386/kvm/xen-stubs.c
> @@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
>  
>  void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
> +    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
>  }
>  
>  void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
> +    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
>  }
> diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
> index 00dff6ee8760..b2135020f27f 100644
> --- a/hw/i386/kvm/xen_evtchn.c
> +++ b/hw/i386/kvm/xen_evtchn.c
> @@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **errp)
>  
>  void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      EvtchnInfoList *iter, *info_list;
>      Error *err = NULL;
>  
> @@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
>      for (iter = info_list; iter; iter = iter->next) {
>          EvtchnInfo *info = iter->value;
>  
> -        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info->vcpu,
> -                       EvtchnPortType_str(info->type));
> +        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, info->vcpu,
> +                           EvtchnPortType_str(info->type));
>          if (info->type != EVTCHN_PORT_TYPE_IPI) {
> -            monitor_printf(mon,  "(");
> +            monitor_hmp_printf(hmp,  "(");
>              if (info->remote_domain) {
> -                monitor_printf(mon, "%s:", info->remote_domain);
> +                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
>              }
> -            monitor_printf(mon, "%d)", info->target);
> +            monitor_hmp_printf(hmp, "%d)", info->target);
>          }
>          if (info->pending) {
> -            monitor_printf(mon, " PENDING");
> +            monitor_hmp_printf(hmp, " PENDING");
>          }
>          if (info->masked) {
> -            monitor_printf(mon, " MASKED");
> +            monitor_hmp_printf(hmp, " MASKED");
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>      }
>  
>      qapi_free_EvtchnInfoList(info_list);
> @@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int port = qdict_get_int(qdict, "port");
>      Error *err = NULL;
>  
> @@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
>      if (err) {
>          hmp_handle_error(hmp, err);
>      } else {
> -        monitor_printf(mon, "Delivered port %d\n", port);
> +        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
>      }
>  }
> -
> diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
> index a4848ae1d1a7..b7afb26886a8 100644
> --- a/hw/i386/sgx-hmp-stub.c
> +++ b/hw/i386/sgx-hmp-stub.c
> @@ -12,6 +12,5 @@
>  
>  void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    monitor_printf(mon, "SGX is not available in this QEMU\n");
> +    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
>  }
> diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
> index 77b41d234c9f..634e33e819ce 100644
> --- a/hw/i386/sgx.c
> +++ b/hw/i386/sgx.c
> @@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
>  
>  void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      SgxEpcSectionList *section_list, *section;
>      g_autoptr(SgxInfo) info = qmp_query_sgx(&err);
> @@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
>          error_report_err(err);
>          return;
>      }
> -    monitor_printf(mon, "SGX support: %s\n",
> -                   info->sgx ? "enabled" : "disabled");
> -    monitor_printf(mon, "SGX1 support: %s\n",
> -                   info->sgx1 ? "enabled" : "disabled");
> -    monitor_printf(mon, "SGX2 support: %s\n",
> -                   info->sgx2 ? "enabled" : "disabled");
> -    monitor_printf(mon, "FLC support: %s\n",
> -                   info->flc ? "enabled" : "disabled");
> +    monitor_hmp_printf(hmp, "SGX support: %s\n",
> +                       info->sgx ? "enabled" : "disabled");
> +    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
> +                       info->sgx1 ? "enabled" : "disabled");
> +    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
> +                       info->sgx2 ? "enabled" : "disabled");
> +    monitor_hmp_printf(hmp, "FLC support: %s\n",
> +                       info->flc ? "enabled" : "disabled");
>  
>      section_list = info->sections;
>      for (section = section_list; section; section = section->next) {
> -        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
> -                       section->value->node);
> -        monitor_printf(mon, "size=%" PRIu64 "\n",
> -                       section->value->size);
> +        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
> +                           section->value->node);
> +        monitor_hmp_printf(hmp, "size=%" PRIu64 "\n",
> +                           section->value->size);
>          size += section->value->size;
>      }
> -    monitor_printf(mon, "total size=%" PRIu64 "\n",
> -                   size);
> +    monitor_hmp_printf(hmp, "total size=%" PRIu64 "\n",
> +                       size);
>  }
>  
>  bool check_sgx_support(void)
> diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
> index ac2525b90fec..ffa76f83016b 100644
> --- a/hw/misc/auxbus.c
> +++ b/hw/misc/auxbus.c
> @@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  
>      s = AUX_SLAVE(dev);
>  
> -    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> -                   indent, "",
> -                   object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
> -                   memory_region_size(s->mmio));
> +    monitor_hmp_printf(MONITOR_HMP(mon),
> +                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> +                       indent, "",
> +                       object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
> +                       memory_region_size(s->mmio));
>  }
>  
>  void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
> diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
> index 6a7d76292f00..154cd32ed88b 100644
> --- a/hw/misc/mos6522-stub.c
> +++ b/hw/misc/mos6522-stub.c
> @@ -12,6 +12,5 @@
>  
>  void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n");
> +    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU\n");
>  }
> diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp-cmds.c
> index 6405ce26dd65..5099d59cc620 100644
> --- a/hw/net/rocker/rocker-hmp-cmds.c
> +++ b/hw/net/rocker/rocker-hmp-cmds.c
> @@ -22,7 +22,6 @@
>  
>  void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *name = qdict_get_str(qdict, "name");
>      RockerSwitch *rocker;
>      Error *err = NULL;
> @@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "name: %s\n", rocker->name);
> -    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
> -    monitor_printf(mon, "ports: %d\n", rocker->ports);
> +    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
> +    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
> +    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
>  
>      qapi_free_RockerSwitch(rocker);
>  }
>  
>  void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      RockerPortList *list, *port;
>      const char *name = qdict_get_str(qdict, "name");
>      Error *err = NULL;
> @@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "            ena/    speed/ auto\n");
> -    monitor_printf(mon, "      port  link    duplex neg?\n");
> +    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
> +    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
>  
>      for (port = list; port; port = port->next) {
> -        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
> -                       port->value->name,
> -                       port->value->enabled ? port->value->link_up ?
> -                       "up" : "down" : "!ena",
> -                       port->value->speed == 10000 ? "10G" : "??",
> -                       port->value->duplex ? "FD" : "HD",
> -                       port->value->autoneg ? "Yes" : "No");
> +        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
> +                           port->value->name,
> +                           port->value->enabled ? port->value->link_up ?
> +                           "up" : "down" : "!ena",
> +                           port->value->speed == 10000 ? "10G" : "??",
> +                           port->value->duplex ? "FD" : "HD",
> +                           port->value->autoneg ? "Yes" : "No");
>      }
>  
>      qapi_free_RockerPortList(list);
> @@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      RockerOfDpaFlowList *list, *info;
>      const char *name = qdict_get_str(qdict, "name");
>      uint32_t tbl_id = qdict_get_try_int(qdict, "tbl_id", -1);
> @@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
> +    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
>  
>      for (info = list; info; info = info->next) {
>          RockerOfDpaFlow *flow = info->value;
> @@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
>          RockerOfDpaFlowAction *action = flow->action;
>  
>          if (flow->hits) {
> -            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
> -                           key->priority, key->tbl_id, flow->hits);
> +            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
> +                               key->priority, key->tbl_id, flow->hits);
>          } else {
> -            monitor_printf(mon, "%-4d %-3d     ",
> -                           key->priority, key->tbl_id);
> +            monitor_hmp_printf(hmp, "%-4d %-3d     ",
> +                               key->priority, key->tbl_id);
>          }
>  
>          if (key->has_in_pport) {
> -            monitor_printf(mon, " pport %d", key->in_pport);
> +            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
>              if (mask->has_in_pport) {
> -                monitor_printf(mon, "(0x%x)", mask->in_pport);
> +                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
>              }
>          }
>  
>          if (key->has_vlan_id) {
> -            monitor_printf(mon, " vlan %d",
> -                           key->vlan_id & VLAN_VID_MASK);
> +            monitor_hmp_printf(hmp, " vlan %d",
> +                               key->vlan_id & VLAN_VID_MASK);
>              if (mask->has_vlan_id) {
> -                monitor_printf(mon, "(0x%x)", mask->vlan_id);
> +                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
>              }
>          }
>  
>          if (key->has_tunnel_id) {
> -            monitor_printf(mon, " tunnel %d", key->tunnel_id);
> +            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
>              if (mask->has_tunnel_id) {
> -                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
> +                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
>              }
>          }
>  
>          if (key->has_eth_type) {
>              switch (key->eth_type) {
>              case 0x0806:
> -                monitor_printf(mon, " ARP");
> +                monitor_hmp_printf(hmp, " ARP");
>                  break;
>              case 0x0800:
> -                monitor_printf(mon, " IP");
> +                monitor_hmp_printf(hmp, " IP");
>                  break;
>              case 0x86dd:
> -                monitor_printf(mon, " IPv6");
> +                monitor_hmp_printf(hmp, " IPv6");
>                  break;
>              case 0x8809:
> -                monitor_printf(mon, " LACP");
> +                monitor_hmp_printf(hmp, " LACP");
>                  break;
>              case 0x88cc:
> -                monitor_printf(mon, " LLDP");
> +                monitor_hmp_printf(hmp, " LLDP");
>                  break;
>              default:
> -                monitor_printf(mon, " eth type 0x%04x", key->eth_type);
> +                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_type);
>                  break;
>              }
>          }
> @@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
>              if ((strcmp(key->eth_src, "01:00:00:00:00:00") == 0) &&
>                  mask->eth_src &&
>                  (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
> -                monitor_printf(mon, " src <any mcast/bcast>");
> +                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
>              } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") == 0) &&
>                  mask->eth_src &&
>                  (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
> -                monitor_printf(mon, " src <any ucast>");
> +                monitor_hmp_printf(hmp, " src <any ucast>");
>              } else {
> -                monitor_printf(mon, " src %s", key->eth_src);
> +                monitor_hmp_printf(hmp, " src %s", key->eth_src);
>                  if (mask->eth_src) {
> -                    monitor_printf(mon, "(%s)", mask->eth_src);
> +                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
>                  }
>              }
>          }
> @@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
>              if ((strcmp(key->eth_dst, "01:00:00:00:00:00") == 0) &&
>                  mask->eth_dst &&
>                  (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
> -                monitor_printf(mon, " dst <any mcast/bcast>");
> +                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
>              } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") == 0) &&
>                  mask->eth_dst &&
>                  (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
> -                monitor_printf(mon, " dst <any ucast>");
> +                monitor_hmp_printf(hmp, " dst <any ucast>");
>              } else {
> -                monitor_printf(mon, " dst %s", key->eth_dst);
> +                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
>                  if (mask->eth_dst) {
> -                    monitor_printf(mon, "(%s)", mask->eth_dst);
> +                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
>                  }
>              }
>          }
>  
>          if (key->has_ip_proto) {
> -            monitor_printf(mon, " proto %d", key->ip_proto);
> +            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
>              if (mask->has_ip_proto) {
> -                monitor_printf(mon, "(0x%x)", mask->ip_proto);
> +                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
>              }
>          }
>  
>          if (key->has_ip_tos) {
> -            monitor_printf(mon, " TOS %d", key->ip_tos);
> +            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
>              if (mask->has_ip_tos) {
> -                monitor_printf(mon, "(0x%x)", mask->ip_tos);
> +                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
>              }
>          }
>  
>          if (key->ip_dst) {
> -            monitor_printf(mon, " dst %s", key->ip_dst);
> +            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
>          }
>  
>          if (action->has_goto_tbl || action->has_group_id ||
>              action->has_new_vlan_id) {
> -            monitor_printf(mon, " -->");
> +            monitor_hmp_printf(hmp, " -->");
>          }
>  
>          if (action->has_new_vlan_id) {
> -            monitor_printf(mon, " apply new vlan %d",
> -                           ntohs(action->new_vlan_id));
> +            monitor_hmp_printf(hmp, " apply new vlan %d",
> +                               ntohs(action->new_vlan_id));
>          }
>  
>          if (action->has_group_id) {
> -            monitor_printf(mon, " write group 0x%08x", action->group_id);
> +            monitor_hmp_printf(hmp, " write group 0x%08x", action->group_id);
>          }
>  
>          if (action->has_goto_tbl) {
> -            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
> +            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
>          }
>  
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>      }
>  
>      qapi_free_RockerOfDpaFlowList(list);
> @@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      RockerOfDpaGroupList *list, *g;
>      const char *name = qdict_get_str(qdict, "name");
>      uint8_t type = qdict_get_try_int(qdict, "type", 9);
> @@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "id (decode) --> buckets\n");
> +    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
>  
>      for (g = list; g; g = g->next) {
>          RockerOfDpaGroup *group = g->value;
>          bool set = false;
>  
> -        monitor_printf(mon, "0x%08x", group->id);
> +        monitor_hmp_printf(hmp, "0x%08x", group->id);
>  
> -        monitor_printf(mon, " (type %s", group->type == 0 ? "L2 interface" :
> +        monitor_hmp_printf(hmp, " (type %s", group->type == 0 ? "L2 interface" :
>                                           group->type == 1 ? "L2 rewrite" :
>                                           group->type == 2 ? "L3 unicast" :
>                                           group->type == 3 ? "L2 multicast" :
> @@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
>                                           "unknown");
>  
>          if (group->has_vlan_id) {
> -            monitor_printf(mon, " vlan %d", group->vlan_id);
> +            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
>          }
>  
>          if (group->has_pport) {
> -            monitor_printf(mon, " pport %d", group->pport);
> +            monitor_hmp_printf(hmp, " pport %d", group->pport);
>          }
>  
>          if (group->has_index) {
> -            monitor_printf(mon, " index %d", group->index);
> +            monitor_hmp_printf(hmp, " index %d", group->index);
>          }
>  
> -        monitor_printf(mon, ") -->");
> +        monitor_hmp_printf(hmp, ") -->");
>  
>          if (group->has_set_vlan_id && group->set_vlan_id) {
>              set = true;
> -            monitor_printf(mon, " set vlan %d",
> -                           group->set_vlan_id & VLAN_VID_MASK);
> +            monitor_hmp_printf(hmp, " set vlan %d",
> +                               group->set_vlan_id & VLAN_VID_MASK);
>          }
>  
>          if (group->set_eth_src) {
>              if (!set) {
>                  set = true;
> -                monitor_printf(mon, " set");
> +                monitor_hmp_printf(hmp, " set");
>              }
> -            monitor_printf(mon, " src %s", group->set_eth_src);
> +            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
>          }
>  
>          if (group->set_eth_dst) {
>              if (!set) {
> -                monitor_printf(mon, " set");
> +                monitor_hmp_printf(hmp, " set");
>              }
> -            monitor_printf(mon, " dst %s", group->set_eth_dst);
> +            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
>          }
>  
>          if (group->has_ttl_check && group->ttl_check) {
> -            monitor_printf(mon, " check TTL");
> +            monitor_hmp_printf(hmp, " check TTL");
>          }
>  
>          if (group->has_group_id && group->group_id) {
> -            monitor_printf(mon, " group id 0x%08x", group->group_id);
> +            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_id);
>          }
>  
>          if (group->has_pop_vlan && group->pop_vlan) {
> -            monitor_printf(mon, " pop vlan");
> +            monitor_hmp_printf(hmp, " pop vlan");
>          }
>  
>          if (group->has_out_pport) {
> -            monitor_printf(mon, " out pport %d", group->out_pport);
> +            monitor_hmp_printf(hmp, " out pport %d", group->out_pport);
>          }
>  
>          if (group->has_group_ids) {
>              struct uint32List *id;
>  
> -            monitor_printf(mon, " groups [");
> +            monitor_hmp_printf(hmp, " groups [");
>              for (id = group->group_ids; id; id = id->next) {
> -                monitor_printf(mon, "0x%08x", id->value);
> +                monitor_hmp_printf(hmp, "0x%08x", id->value);
>                  if (id->next) {
> -                    monitor_printf(mon, ",");
> +                    monitor_hmp_printf(hmp, ",");
>                  }
>              }
> -            monitor_printf(mon, "]");
> +            monitor_hmp_printf(hmp, "]");
>          }
>  
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>      }
>  
>      qapi_free_RockerOfDpaGroupList(list);
> diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
> index 51d95d76620e..500f821246a9 100644
> --- a/hw/pci/pci-hmp-cmds.c
> +++ b/hw/pci/pci-hmp-cmds.c
> @@ -24,54 +24,55 @@
>  #include "qapi/qapi-commands-pci.h"
>  #include "qemu/cutils.h"
>  
> -static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
> +static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *dev)
>  {
> +    Monitor *mon = MONITOR(hmp);
>      PciMemoryRegionList *region;
>  
> -    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
> -    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n",
> -                   dev->slot, dev->function);
> -    monitor_printf(mon, "    ");
> +    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
> +    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 ":\n",
> +                       dev->slot, dev->function);
> +    monitor_hmp_printf(hmp, "    ");
>  
>      if (dev->class_info->desc) {
>          monitor_puts(mon, dev->class_info->desc);
>      } else {
> -        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_class);
> +        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q_class);
>      }
>  
> -    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
> -                   dev->id->vendor, dev->id->device);
> +    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
> +                       dev->id->vendor, dev->id->device);
>      if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
> -        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
> -                       dev->id->subsystem_vendor, dev->id->subsystem);
> +        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
> +                           dev->id->subsystem_vendor, dev->id->subsystem);
>      }
>  
>      if (dev->has_irq) {
> -        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
> -                       dev->irq, (char)('A' + dev->irq_pin - 1));
> +        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
> +                           dev->irq, (char)('A' + dev->irq_pin - 1));
>      }
>  
>      if (dev->pci_bridge) {
> -        monitor_printf(mon, "      BUS %" PRId64 ".\n",
> -                       dev->pci_bridge->bus->number);
> -        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
> -                       dev->pci_bridge->bus->secondary);
> -        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
> -                       dev->pci_bridge->bus->subordinate);
> +        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
> +                           dev->pci_bridge->bus->number);
> +        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
> +                           dev->pci_bridge->bus->secondary);
> +        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n",
> +                           dev->pci_bridge->bus->subordinate);
>  
> -        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
> -                       dev->pci_bridge->bus->io_range->base,
> -                       dev->pci_bridge->bus->io_range->limit);
> +        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
> +                           dev->pci_bridge->bus->io_range->base,
> +                           dev->pci_bridge->bus->io_range->limit);
>  
> -        monitor_printf(mon,
> -                       "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
> -                       dev->pci_bridge->bus->memory_range->base,
> -                       dev->pci_bridge->bus->memory_range->limit);
> +        monitor_hmp_printf(hmp,
> +                           "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
> +                           dev->pci_bridge->bus->memory_range->base,
> +                           dev->pci_bridge->bus->memory_range->limit);
>  
> -        monitor_printf(mon, "      prefetchable memory range "
> -                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
> -                       dev->pci_bridge->bus->prefetchable_range->base,
> -                       dev->pci_bridge->bus->prefetchable_range->limit);
> +        monitor_hmp_printf(hmp, "      prefetchable memory range "
> +                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
> +                           dev->pci_bridge->bus->prefetchable_range->base,
> +                           dev->pci_bridge->bus->prefetchable_range->limit);
>      }
>  
>      for (region = dev->regions; region; region = region->next) {
> @@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
>          addr = region->value->address;
>          size = region->value->size;
>  
> -        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->bar);
> +        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->value->bar);
>  
>          if (!strcmp(region->value->type, "io")) {
>              if (addr != PCI_BAR_UNMAPPED) {
> -                monitor_printf(mon, "I/O at 0x%04" PRIx64
> +                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
>                                      " [0x%04" PRIx64 "]\n",
>                                 addr, addr + size - 1);
>              } else {
> -                monitor_printf(mon, "I/O (not mapped)\n");
> +                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
>              }
>          } else {
>              if (addr != PCI_BAR_UNMAPPED) {
> -                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
> +                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRIx64
>                                     " [0x%08" PRIx64 "]\n",
>                                 region->value->mem_type_64 ? 64 : 32,
>                                 region->value->prefetch ? " prefetchable" : "",
>                                 addr, addr + size - 1);
>              } else {
> -                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
> -                               region->value->mem_type_64 ? 64 : 32,
> -                               region->value->prefetch ? " prefetchable" : "");
> +                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\n",
> +                                   region->value->mem_type_64 ? 64 : 32,
> +                                   region->value->prefetch ? " prefetchable" : "");
>              }
>          }
>      }
>  
> -    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
> +    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
>  
>      if (dev->pci_bridge) {
>          if (dev->pci_bridge->has_devices) {
>              PciDeviceInfoList *cdev;
>              for (cdev = dev->pci_bridge->devices; cdev; cdev = cdev->next) {
> -                hmp_info_pci_device(mon, cdev->value);
> +                hmp_info_pci_device(hmp, cdev->value);
>              }
>          }
>      }
> @@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
>  
>  void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      PciInfoList *info_list, *info;
>  
>      info_list = qmp_query_pci(&error_abort);
> @@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
>          PciDeviceInfoList *dev;
>  
>          for (dev = info->value->devices; dev; dev = dev->next) {
> -            hmp_info_pci_device(mon, dev->value);
> +            hmp_info_pci_device(hmp, dev->value);
>          }
>      }
>  
> @@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
>  
>  void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>  {
> +    MonitorHMP *hmp = MONITOR_HMP(mon);
>      PCIDevice *d = (PCIDevice *)dev;
>      int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
>      const pci_class_desc *desc = get_class_desc(class);
> @@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
>          snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
>      }
>  
> -    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
> -                   "pci id %04x:%04x (sub %04x:%04x)\n",
> -                   indent, "", ctxt, pci_dev_bus_num(d),
> -                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
> -                   pci_get_word(d->config + PCI_VENDOR_ID),
> -                   pci_get_word(d->config + PCI_DEVICE_ID),
> -                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
> -                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
> +    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
> +                       "pci id %04x:%04x (sub %04x:%04x)\n",
> +                       indent, "", ctxt, pci_dev_bus_num(d),
> +                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
> +                       pci_get_word(d->config + PCI_VENDOR_ID),
> +                       pci_get_word(d->config + PCI_DEVICE_ID),
> +                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
> +                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
>      for (i = 0; i < PCI_NUM_REGIONS; i++) {
>          r = &d->io_regions[i];
>          if (!r->size) {
>              continue;
>          }
> -        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
> -                       " [0x%"FMT_PCIBUS"]\n",
> -                       indent, "",
> -                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
> -                       r->addr, r->addr + r->size - 1);
> +        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
> +                           " [0x%"FMT_PCIBUS"]\n",
> +                           indent, "",
> +                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
> +                           r->addr, r->addr + r->size - 1);
>      }
>  }
>  
>  void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      const char *id = qdict_get_str(qdict, "id");
>      const char *error_name;
> @@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
>      }
>  
>  
> -    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
> -                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
> -                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> +    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
> +                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
> +                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
>  
>  out:
>      hmp_handle_error(hmp, err);
> diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
> index a80e34175462..7e2797300ba0 100644
> --- a/hw/pci/pci-stub.c
> +++ b/hw/pci/pci-stub.c
> @@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    monitor_printf(mon, "PCI devices not supported\n");
> +    monitor_hmp_printf(hmp, "PCI devices not supported\n");
>  }
>  
>  /* kvm-all wants this */
> diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
> index d8afaf730639..b5e56a16cce1 100644
> --- a/hw/s390x/s390-skeys.c
> +++ b/hw/s390x/s390-skeys.c
> @@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
>  
>  void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      S390SKeysState *ss = s390_get_skeys_device();
>      S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
>      uint64_t addr = qdict_get_int(qdict, "addr");
> @@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
>  
>      /* Quick check to see if guest is using storage keys*/
>      if (!skeyclass->skeys_are_enabled(ss)) {
> -        monitor_printf(mon, "Error: This guest is not using storage keys\n");
> +        monitor_hmp_printf(hmp, "Error: This guest is not using storage keys\n");
>          return;
>      }
>  
>      if (!address_space_access_valid(&address_space_memory,
>                                      addr & TARGET_PAGE_MASK, TARGET_PAGE_SIZE,
>                                      false, MEMTXATTRS_UNSPECIFIED)) {
> -        monitor_printf(mon, "Error: The given address is not valid\n");
> +        monitor_hmp_printf(hmp, "Error: The given address is not valid\n");
>          return;
>      }
>  
>      r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
>      if (r < 0) {
> -        monitor_printf(mon, "Error: %s\n", strerror(-r));
> +        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
>          return;
>      }
>  
> -    monitor_printf(mon, "  key: 0x%X\n", key);
> +    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
>  }
>  
>  void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
> diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
> index b4a405455901..644298f7f0b2 100644
> --- a/hw/s390x/s390-stattrib.c
> +++ b/hw/s390x/s390-stattrib.c
> @@ -61,7 +61,6 @@ void s390_stattrib_init(void)
>  
>  void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      S390StAttribState *sas = s390_get_stattrib_device();
>      S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
>      uint64_t what = qdict_get_int(qdict, "mode");
> @@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
>  
>      r = sac->set_migrationmode(sas, what, &local_err);
>      if (r < 0) {
> -        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
> +        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_err));
>          error_free(local_err);
>      }
>  }
>  
>  void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      S390StAttribState *sas = s390_get_stattrib_device();
>      S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
>      uint64_t addr = qdict_get_int(qdict, "addr");
> @@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
>  
>      vals = g_try_malloc(buflen);
>      if (!vals) {
> -        monitor_printf(mon, "Error: %s\n", strerror(errno));
> +        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
>          return;
>      }
>  
>      len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
>      if (len < 0) {
> -        monitor_printf(mon, "Error: %s", strerror(-len));
> +        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
>          goto out;
>      }
>  
> -    monitor_printf(mon, "  CMMA attributes, "
> -                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
> -                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
> +    monitor_hmp_printf(hmp, "  CMMA attributes, "
> +                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
> +                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
>      for (cx = 0; cx < len; cx++) {
>          if (cx % 8 == 7) {
> -            monitor_printf(mon, "%02x\n", vals[cx]);
> +            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
>          } else {
> -            monitor_printf(mon, "%02x", vals[cx]);
> +            monitor_hmp_printf(hmp, "%02x", vals[cx]);
>          }
>      }
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>  
>  out:
>      g_free(vals);
> diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
> index 0d59a74ad60e..0249eea2cfe9 100644
> --- a/hw/uefi/ovmf-log.c
> +++ b/hw/uefi/ovmf-log.c
> @@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_size, uint64_t max_size,
>  
>  void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      g_autofree gchar *log_esc = NULL;
>      g_autofree guchar *log_out = NULL;
>      Error *err = NULL;
> @@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
>  
>      if (log->version) {
>          g_autofree gchar *esc = g_strescape(log->version, NULL);
> -        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
> +        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
>      }
>  
>      log_out = g_base64_decode(log->log, &log_len);
>      log_esc = g_strescape((gchar *)log_out, "\r\n");
> -    monitor_printf(mon, "%s\n", log_esc);
> +    monitor_hmp_printf(hmp, "%s\n", log_esc);
>  }
> diff --git a/hw/usb/bus.c b/hw/usb/bus.c
> index 9b9b2e7c2f8f..fe3dbfa2227c 100644
> --- a/hw/usb/bus.c
> +++ b/hw/usb/bus.c
> @@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
>  
>  static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
>  {
> +    MonitorHMP *hmp = MONITOR_HMP(mon);
>      USBDevice *dev = USB_DEVICE(qdev);
>      USBBus *bus = usb_bus_from_device(dev);
>  
> -    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
> -                   indent, "", bus->busnr, dev->addr,
> -                   dev->port ? dev->port->path : "-",
> -                   usb_speed(dev->speed), dev->product_desc,
> -                   dev->attached ? ", attached" : "");
> +    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
> +                       indent, "", bus->busnr, dev->addr,
> +                       dev->port ? dev->port->path : "-",
> +                       usb_speed(dev->speed), dev->product_desc,
> +                       dev->attached ? ", attached" : "");
>  }
>  
>  static char *usb_get_dev_path(DeviceState *qdev)
> diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> index c02343d3a655..9b9f26a1078e 100644
> --- a/hw/usb/host-libusb.c
> +++ b/hw/usb/host-libusb.c
> @@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
>  
>  void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      libusb_device **devs = NULL;
>      struct libusb_device_descriptor ddesc;
>      char port[16];
> @@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
>              continue;
>          }
>          usb_host_get_port(devs[i], port, sizeof(port));
> -        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
> -                       libusb_get_bus_number(devs[i]),
> -                       libusb_get_device_address(devs[i]),
> -                       port,
> -                       speed_name[libusb_get_device_speed(devs[i])]);
> -        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
> -        monitor_printf(mon, " USB device %04x:%04x",
> -                       ddesc.idVendor, ddesc.idProduct);
> +        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
> +                           libusb_get_bus_number(devs[i]),
> +                           libusb_get_device_address(devs[i]),
> +                           port,
> +                           speed_name[libusb_get_device_speed(devs[i])]);
> +        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass);
> +        monitor_hmp_printf(hmp, " USB device %04x:%04x",
> +                           ddesc.idVendor, ddesc.idProduct);
>          if (ddesc.iProduct) {
>              libusb_device_handle *handle;
>              if (libusb_open(devs[i], &handle) == 0) {
> @@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
>                                                     ddesc.iProduct,
>                                                     name, sizeof(name));
>                  libusb_close(handle);
> -                monitor_printf(mon, ", %s", name);
> +                monitor_hmp_printf(hmp, ", %s", name);
>              }
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>      }
>      libusb_free_device_list(devs, 1);
>  }
> diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
> index fb36c8b9274c..e5da6f00699d 100644
> --- a/hw/virtio/virtio-hmp-cmds.c
> +++ b/hw/virtio/virtio-hmp-cmds.c
> @@ -12,77 +12,76 @@
>  #include "qobject/qdict.h"
>  
>  
> -static void hmp_virtio_dump_protocols(Monitor *mon,
> +static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
>                                        VhostDeviceProtocols *pcol)
>  {
>      strList *pcol_list = pcol->protocols;
>      while (pcol_list) {
> -        monitor_printf(mon, "\t%s", pcol_list->value);
> +        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
>          pcol_list = pcol_list->next;
>          if (pcol_list != NULL) {
> -            monitor_printf(mon, ",\n");
> +            monitor_hmp_printf(hmp, ",\n");
>          }
>      }
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>      if (pcol->has_unknown_protocols) {
> -        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
> -                       pcol->unknown_protocols);
> +        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n",
> +                           pcol->unknown_protocols);
>      }
>  }
>  
> -static void hmp_virtio_dump_status(Monitor *mon,
> +static void hmp_virtio_dump_status(MonitorHMP *hmp,
>                                     VirtioDeviceStatus *status)
>  {
>      strList *status_list = status->statuses;
>      while (status_list) {
> -        monitor_printf(mon, "\t%s", status_list->value);
> +        monitor_hmp_printf(hmp, "\t%s", status_list->value);
>          status_list = status_list->next;
>          if (status_list != NULL) {
> -            monitor_printf(mon, ",\n");
> +            monitor_hmp_printf(hmp, ",\n");
>          }
>      }
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>      if (status->has_unknown_statuses) {
> -        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
> -                       status->unknown_statuses);
> +        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n",
> +                           status->unknown_statuses);
>      }
>  }
>  
> -static void hmp_virtio_dump_features(Monitor *mon,
> +static void hmp_virtio_dump_features(MonitorHMP *hmp,
>                                       VirtioDeviceFeatures *features)
>  {
>      strList *transport_list = features->transports;
>      while (transport_list) {
> -        monitor_printf(mon, "\t%s", transport_list->value);
> +        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
>          transport_list = transport_list->next;
>          if (transport_list != NULL) {
> -            monitor_printf(mon, ",\n");
> +            monitor_hmp_printf(hmp, ",\n");
>          }
>      }
>  
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>      strList *list = features->dev_features;
>      if (list) {
>          while (list) {
> -            monitor_printf(mon, "\t%s", list->value);
> +            monitor_hmp_printf(hmp, "\t%s", list->value);
>              list = list->next;
>              if (list != NULL) {
> -                monitor_printf(mon, ",\n");
> +                monitor_hmp_printf(hmp, ",\n");
>              }
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>      }
>  
>      if (features->has_unknown_dev_features) {
> -        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
> -                       features->unknown_dev_features2,
> -                       features->unknown_dev_features);
> +        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
> +                           features->unknown_dev_features2,
> +                           features->unknown_dev_features);
>      }
>  }
>  
>  void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      VirtioInfoList *list = qmp_x_query_virtio(&err);
>      VirtioInfoList *node;
> @@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
>      }
>  
>      if (list == NULL) {
> -        monitor_printf(mon, "No VirtIO devices\n");
> +        monitor_hmp_printf(hmp, "No VirtIO devices\n");
>          return;
>      }
>  
>      node = list;
>      while (node) {
> -        monitor_printf(mon, "%s [%s]\n", node->value->path,
> -                       node->value->name);
> +        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
> +                           node->value->name);
>          node = node->next;
>      }
>      qapi_free_VirtioInfoList(list);
> @@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      const char *path = qdict_get_try_str(qdict, "path");
>      VirtioStatus *s = qmp_x_query_virtio_status(path, &err);
> @@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "%s:\n", path);
> -    monitor_printf(mon, "  device_name:             %s %s\n",
> -                   s->name, s->vhost_dev ? "(vhost)" : "");
> -    monitor_printf(mon, "  device_id:               %d\n", s->device_id);
> -    monitor_printf(mon, "  vhost_started:           %s\n",
> -                   s->vhost_started ? "true" : "false");
> -    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name);
> -    monitor_printf(mon, "  broken:                  %s\n",
> -                   s->broken ? "true" : "false");
> -    monitor_printf(mon, "  disabled:                %s\n",
> -                   s->disabled ? "true" : "false");
> -    monitor_printf(mon, "  disable_legacy_check:    %s\n",
> -                   s->disable_legacy_check ? "true" : "false");
> -    monitor_printf(mon, "  started:                 %s\n",
> -                   s->started ? "true" : "false");
> -    monitor_printf(mon, "  use_started:             %s\n",
> -                   s->use_started ? "true" : "false");
> -    monitor_printf(mon, "  start_on_kick:           %s\n",
> -                   s->start_on_kick ? "true" : "false");
> -    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
> -                   s->use_guest_notifier_mask ? "true" : "false");
> -    monitor_printf(mon, "  vm_running:              %s\n",
> -                   s->vm_running ? "true" : "false");
> -    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
> -    monitor_printf(mon, "  queue_sel:               %d\n",
> -                   s->queue_sel);
> -    monitor_printf(mon, "  isr:                     %d\n", s->isr);
> -    monitor_printf(mon, "  endianness:              %s\n",
> -                   s->device_endian);
> -    monitor_printf(mon, "  status:\n");
> -    hmp_virtio_dump_status(mon, s->status);
> -    monitor_printf(mon, "  Guest features:\n");
> -    hmp_virtio_dump_features(mon, s->guest_features);
> -    monitor_printf(mon, "  Host features:\n");
> -    hmp_virtio_dump_features(mon, s->host_features);
> -    monitor_printf(mon, "  Backend features:\n");
> -    hmp_virtio_dump_features(mon, s->backend_features);
> +    monitor_hmp_printf(hmp, "%s:\n", path);
> +    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
> +                       s->name, s->vhost_dev ? "(vhost)" : "");
> +    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->device_id);
> +    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
> +                       s->vhost_started ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_name);
> +    monitor_hmp_printf(hmp, "  broken:                  %s\n",
> +                       s->broken ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  disabled:                %s\n",
> +                       s->disabled ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
> +                       s->disable_legacy_check ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  started:                 %s\n",
> +                       s->started ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  use_started:             %s\n",
> +                       s->use_started ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
> +                       s->start_on_kick ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
> +                       s->use_guest_notifier_mask ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
> +                       s->vm_running ? "true" : "false");
> +    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
> +    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
> +                       s->queue_sel);
> +    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr);
> +    monitor_hmp_printf(hmp, "  endianness:              %s\n",
> +                       s->device_endian);
> +    monitor_hmp_printf(hmp, "  status:\n");
> +    hmp_virtio_dump_status(hmp, s->status);
> +    monitor_hmp_printf(hmp, "  Guest features:\n");
> +    hmp_virtio_dump_features(hmp, s->guest_features);
> +    monitor_hmp_printf(hmp, "  Host features:\n");
> +    hmp_virtio_dump_features(hmp, s->host_features);
> +    monitor_hmp_printf(hmp, "  Backend features:\n");
> +    hmp_virtio_dump_features(hmp, s->backend_features);
>  
>      if (s->vhost_dev) {
> -        monitor_printf(mon, "  VHost:\n");
> -        monitor_printf(mon, "    nvqs:           %d\n",
> -                       s->vhost_dev->nvqs);
> -        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
> -                       s->vhost_dev->vq_index);
> -        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
> -                       s->vhost_dev->max_queues);
> -        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
> -                       s->vhost_dev->n_mem_sections);
> -        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
> -                       s->vhost_dev->n_tmp_sections);
> -        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
> -                       s->vhost_dev->backend_cap);
> -        monitor_printf(mon, "    log_enabled:    %s\n",
> -                       s->vhost_dev->log_enabled ? "true" : "false");
> -        monitor_printf(mon, "    log_size:       %"PRId64"\n",
> -                       s->vhost_dev->log_size);
> -        monitor_printf(mon, "    Features:\n");
> -        hmp_virtio_dump_features(mon, s->vhost_dev->features);
> -        monitor_printf(mon, "    Acked features:\n");
> -        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
> -        monitor_printf(mon, "    Protocol features:\n");
> -        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features);
> +        monitor_hmp_printf(hmp, "  VHost:\n");
> +        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
> +                           s->vhost_dev->nvqs);
> +        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
> +                           s->vhost_dev->vq_index);
> +        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
> +                           s->vhost_dev->max_queues);
> +        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
> +                           s->vhost_dev->n_mem_sections);
> +        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
> +                           s->vhost_dev->n_tmp_sections);
> +        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
> +                           s->vhost_dev->backend_cap);
> +        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
> +                           s->vhost_dev->log_enabled ? "true" : "false");
> +        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
> +                           s->vhost_dev->log_size);
> +        monitor_hmp_printf(hmp, "    Features:\n");
> +        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
> +        monitor_hmp_printf(hmp, "    Acked features:\n");
> +        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
> +        monitor_hmp_printf(hmp, "    Protocol features:\n");
> +        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features);
>      }
>  
>      qapi_free_VirtioStatus(s);
> @@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      const char *path = qdict_get_try_str(qdict, "path");
>      int queue = qdict_get_int(qdict, "queue");
> @@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "%s:\n", path);
> -    monitor_printf(mon, "  device_name:          %s (vhost)\n",
> -                   s->name);
> -    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick);
> -    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call);
> -    monitor_printf(mon, "  VRing:\n");
> -    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
> -    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
> -                   s->desc_phys);
> -    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
> -    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
> -                   s->avail_phys);
> -    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size);
> -    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
> -                   s->used_phys);
> -    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
> +    monitor_hmp_printf(hmp, "%s:\n", path);
> +    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
> +                       s->name);
> +    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->kick);
> +    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->call);
> +    monitor_hmp_printf(hmp, "  VRing:\n");
> +    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
> +    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
> +                       s->desc_phys);
> +    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_size);
> +    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
> +                       s->avail_phys);
> +    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_size);
> +    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
> +                       s->used_phys);
> +    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_size);
>  
>      qapi_free_VirtVhostQueueStatus(s);
>  }
>  
>  void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      const char *path = qdict_get_try_str(qdict, "path");
>      int queue = qdict_get_int(qdict, "queue");
> @@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "%s:\n", path);
> -    monitor_printf(mon, "  device_name:          %s\n", s->name);
> -    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index);
> -    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
> -    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
> -    monitor_printf(mon, "  signalled_used:       %d\n",
> -                   s->signalled_used);
> -    monitor_printf(mon, "  signalled_used_valid: %s\n",
> -                   s->signalled_used_valid ? "true" : "false");
> +    monitor_hmp_printf(hmp, "%s:\n", path);
> +    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
> +    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_index);
> +    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
> +    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_idx);
> +    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
> +                       s->signalled_used);
> +    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
> +                       s->signalled_used_valid ? "true" : "false");
>      if (s->has_last_avail_idx) {
> -        monitor_printf(mon, "  last_avail_idx:       %d\n",
> -                       s->last_avail_idx);
> +        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
> +                           s->last_avail_idx);
>      }
>      if (s->has_shadow_avail_idx) {
> -        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
> -                       s->shadow_avail_idx);
> +        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
> +                           s->shadow_avail_idx);
>      }
> -    monitor_printf(mon, "  VRing:\n");
> -    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num);
> -    monitor_printf(mon, "    num_default:  %"PRId32"\n",
> -                   s->vring_num_default);
> -    monitor_printf(mon, "    align:        %"PRId32"\n",
> -                   s->vring_align);
> -    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
> -                   s->vring_desc);
> -    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
> -                   s->vring_avail);
> -    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
> -                   s->vring_used);
> +    monitor_hmp_printf(hmp, "  VRing:\n");
> +    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_num);
> +    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
> +                       s->vring_num_default);
> +    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
> +                       s->vring_align);
> +    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
> +                       s->vring_desc);
> +    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
> +                       s->vring_avail);
> +    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
> +                       s->vring_used);
>  
>      qapi_free_VirtQueueStatus(s);
>  }
>  
>  void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      const char *path = qdict_get_try_str(qdict, "path");
>      int queue = qdict_get_int(qdict, "queue");
> @@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "%s:\n", path);
> -    monitor_printf(mon, "  device_name: %s\n", e->name);
> -    monitor_printf(mon, "  index:   %d\n", e->index);
> -    monitor_printf(mon, "  desc:\n");
> -    monitor_printf(mon, "    descs:\n");
> +    monitor_hmp_printf(hmp, "%s:\n", path);
> +    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
> +    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
> +    monitor_hmp_printf(hmp, "  desc:\n");
> +    monitor_hmp_printf(hmp, "    descs:\n");
>  
>      list = e->descs;
>      while (list) {
> -        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
> -                       list->value->addr, list->value->len);
> +        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
> +                           list->value->addr, list->value->len);
>          if (list->value->flags) {
>              strList *flag = list->value->flags;
> -            monitor_printf(mon, " (");
> +            monitor_hmp_printf(hmp, " (");
>              while (flag) {
> -                monitor_printf(mon, "%s", flag->value);
> +                monitor_hmp_printf(hmp, "%s", flag->value);
>                  flag = flag->next;
>                  if (flag) {
> -                    monitor_printf(mon, ", ");
> +                    monitor_hmp_printf(hmp, ", ");
>                  }
>              }
> -            monitor_printf(mon, ")");
> +            monitor_hmp_printf(hmp, ")");
>          }
>          list = list->next;
>          if (list) {
> -            monitor_printf(mon, ",\n");
> +            monitor_hmp_printf(hmp, ",\n");
>          }
>      }
> -    monitor_printf(mon, "\n");
> -    monitor_printf(mon, "  avail:\n");
> -    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
> -    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
> -    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
> -    monitor_printf(mon, "  used:\n");
> -    monitor_printf(mon, "    flags: %d\n", e->used->flags);
> -    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
> +    monitor_hmp_printf(hmp, "\n");
> +    monitor_hmp_printf(hmp, "  avail:\n");
> +    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
> +    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
> +    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
> +    monitor_hmp_printf(hmp, "  used:\n");
> +    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
> +    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
>  
>      qapi_free_VirtioQueueElement(e);
>  }
> diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> index a563f6066bb4..4075b5b001ae 100644
> --- a/hw/xen/xen-bus.c
> +++ b/hw/xen/xen-bus.c
> @@ -103,10 +103,11 @@ abort:
>  
>  static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
>  {
> +    MonitorHMP *hmp = MONITOR_HMP(mon);
>      XenDevice *xendev = XEN_DEVICE(dev);
>  
> -    monitor_printf(mon, "%*sname = '%s' frontend_id = %u\n",
> -                   indent, "", xendev->name, xendev->frontend_id);
> +    monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
> +                       indent, "", xendev->name, xendev->frontend_id);
>  }
>  
>  static char *xen_bus_get_dev_path(DeviceState *dev)
> diff --git a/include/disas/disas.h b/include/disas/disas.h
> index c702b1effc1c..47daa9b4d2df 100644
> --- a/include/disas/disas.h
> +++ b/include/disas/disas.h
> @@ -1,13 +1,15 @@
>  #ifndef QEMU_DISAS_H
>  #define QEMU_DISAS_H
>  
> +#include "monitor/hmp.h"
> +
>  /* Disassemble this for me please... (debugging). */
>  #ifdef CONFIG_TCG
>  void disas(FILE *out, const void *code, size_t size);
>  void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db);
>  #endif
>  
> -void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> +void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
>                     int nb_insn, bool is_physical);
>  
>  #ifdef CONFIG_PLUGIN
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 3fd17048b319..f10bf83df86d 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *chardev_id,
>  
>  MonitorHMP *monitor_cur_hmp(void);
>  
> -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
>      G_GNUC_PRINTF(2, 0);
> -int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
> -void monitor_printc(Monitor *mon, int ch);
> +int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
> +void monitor_hmp_printc(MonitorHMP *mon, int ch);
>  
>  void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
>  int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> @@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
>  int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
>  
>  bool hmp_handle_error(MonitorHMP *hmp, Error *err);
> -void hmp_help_cmd(Monitor *mon, const char *name);
> +void hmp_help_cmd(MonitorHMP *hmp, const char *name);
>  strList *hmp_split_at_comma(const char *str);
>  
>  void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
> @@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDict *qdict);
>  void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
>  void hmp_change(MonitorHMP *hmp, const QDict *qdict);
>  #ifdef CONFIG_VNC
> -void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
> +void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
>                      const char *arg, const char *read_only, bool force,
>                      Error **errp);
>  #endif
> -void hmp_change_medium(Monitor *mon, const char *device, const char *target,
> +void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
>                         const char *arg, const char *read_only, bool force,
>                         Error **errp);
>  void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
> diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> index 3c0931796ce2..bdbb2aaa99db 100644
> --- a/migration/dirtyrate.c
> +++ b/migration/dirtyrate.c
> @@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool has_calc_time_unit,
>  
>  void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      DirtyRateInfo *info = query_dirty_rate_info(TIME_UNIT_SECOND);
>  
> -    monitor_printf(mon, "Status: %s\n",
> -                   DirtyRateStatus_str(info->status));
> -    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
> -                   info->start_time);
> +    monitor_hmp_printf(hmp, "Status: %s\n",
> +                       DirtyRateStatus_str(info->status));
> +    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
> +                       info->start_time);
>      if (info->mode == DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
> -        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
> -                       info->sample_pages);
> +        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
> +                           info->sample_pages);
>      }
> -    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
> -                   info->calc_time);
> -    monitor_printf(mon, "Mode: %s\n",
> -                   DirtyRateMeasureMode_str(info->mode));
> -    monitor_printf(mon, "Dirty rate: ");
> +    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
> +                       info->calc_time);
> +    monitor_hmp_printf(hmp, "Mode: %s\n",
> +                       DirtyRateMeasureMode_str(info->mode));
> +    monitor_hmp_printf(hmp, "Dirty rate: ");
>      if (info->has_dirty_rate) {
> -        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
> +        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate);
>          if (info->has_vcpu_dirty_rate) {
>              DirtyRateVcpuList *rate, *head = info->vcpu_dirty_rate;
>              for (rate = head; rate != NULL; rate = rate->next) {
> -                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
> -                               " (MB/s)\n", rate->value->id,
> -                               rate->value->dirty_rate);
> +                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
> +                                   " (MB/s)\n", rate->value->id,
> +                                   rate->value->dirty_rate);
>              }
>          }
>      } else {
> -        monitor_printf(mon, "(not ready)\n");
> +        monitor_hmp_printf(hmp, "(not ready)\n");
>      }
>  
>      qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
> @@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int64_t sec = qdict_get_try_int(qdict, "second", 0);
>      int64_t sample_pages = qdict_get_try_int(qdict, "sample_pages_per_GB", -1);
>      bool has_sample_pages = (sample_pages != -1);
> @@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
>      Error *err = NULL;
>  
>      if (!sec) {
> -        monitor_printf(mon, "Incorrect period length specified!\n");
> +        monitor_hmp_printf(hmp, "Incorrect period length specified!\n");
>          return;
>      }
>  
>      if (dirty_ring && dirty_bitmap) {
> -        monitor_printf(mon, "Either dirty ring or dirty bitmap "
> -                       "can be specified!\n");
> +        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
> +                           "can be specified!\n");
>          return;
>      }
>  
> @@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "Starting dirty rate measurement with period %"PRIi64
> -                   " seconds\n", sec);
> -    monitor_printf(mon, "[Please use 'info dirty_rate' to check results]\n");
> +    monitor_hmp_printf(hmp, "Starting dirty rate measurement with period %"PRIi64
> +                       " seconds\n", sec);
> +    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check results]\n");
>  }
> diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
> index 73a974259478..6fe189471899 100644
> --- a/migration/migration-hmp-cmds.c
> +++ b/migration/migration-hmp-cmds.c
> @@ -36,23 +36,23 @@
>  #include "options.h"
>  #include "migration.h"
>  
> -static void migration_global_dump(Monitor *mon)
> +static void migration_global_dump(MonitorHMP *hmp)
>  {
>      MigrationState *ms = migrate_get_current();
>  
> -    monitor_printf(mon, "Globals:\n");
> -    monitor_printf(mon, "  store-global-state: %s\n",
> -                   ms->store_global_state ? "on" : "off");
> -    monitor_printf(mon, "  only-migratable: %s\n",
> -                   only_migratable ? "on" : "off");
> -    monitor_printf(mon, "  send-configuration: %s\n",
> -                   ms->send_configuration ? "on" : "off");
> -    monitor_printf(mon, "  send-section-footer: %s\n",
> -                   ms->send_section_footer ? "on" : "off");
> -    monitor_printf(mon, "  send-switchover-start: %s\n",
> -                   ms->send_switchover_start ? "on" : "off");
> -    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
> -                   ms->clear_bitmap_shift);
> +    monitor_hmp_printf(hmp, "Globals:\n");
> +    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
> +                       ms->store_global_state ? "on" : "off");
> +    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
> +                       only_migratable ? "on" : "off");
> +    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
> +                       ms->send_configuration ? "on" : "off");
> +    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
> +                       ms->send_section_footer ? "on" : "off");
> +    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
> +                       ms->send_switchover_start ? "on" : "off");
> +    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
> +                       ms->clear_bitmap_shift);
>  }
>  
>  static const gchar *format_time_str(uint64_t us)
> @@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
>      return g_strdup_printf("%"PRIu64" %s", us, units[index]);
>  }
>  
> -static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> +static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *info)
>  {
>      if (info->has_postcopy_blocktime) {
> -        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
> -                       info->postcopy_blocktime);
> +        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\n",
> +                           info->postcopy_blocktime);
>      }
>  
>      if (info->has_postcopy_vcpu_blocktime) {
> @@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
>          const char *sep = "";
>          int count = 0;
>  
> -        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
> +        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
>  
>          while (item) {
> -            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
> +            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
>              item = item->next;
>              /* Each line 10 vcpu results, newline if there's more */
>              sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
>          }
> -        monitor_printf(mon, "]\n");
> +        monitor_hmp_printf(hmp, "]\n");
>      }
>  
>      if (info->has_postcopy_latency) {
> -        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
> -                       info->postcopy_latency);
> +        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n",
> +                           info->postcopy_latency);
>      }
>  
>      if (info->has_postcopy_non_vcpu_latency) {
> -        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
> -                       info->postcopy_non_vcpu_latency);
> +        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
> +                           info->postcopy_non_vcpu_latency);
>      }
>  
>      if (info->has_postcopy_vcpu_latency) {
> @@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
>          const char *sep = "";
>          int count = 0;
>  
> -        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
> +        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
>  
>          while (item) {
> -            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
> +            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
>              item = item->next;
>              /* Each line 10 vcpu results, newline if there's more */
>              sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
>          }
> -        monitor_printf(mon, "]\n");
> +        monitor_hmp_printf(hmp, "]\n");
>      }
>  
>      if (info->has_postcopy_latency_dist) {
>          uint64List *item = info->postcopy_latency_dist;
>          int count = 0;
>  
> -        monitor_printf(mon, "Postcopy Latency Distribution:\n");
> +        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
>  
>          while (item) {
>              g_autofree const gchar *from = format_time_str(1UL << count);
>              g_autofree const gchar *to = format_time_str(1UL << (count + 1));
>  
> -            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
> -                           from, to, item->value);
> +            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
> +                               from, to, item->value);
>              item = item->next;
>              count++;
>          }
> @@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
>  
>  void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      bool show_all = qdict_get_try_bool(qdict, "all", false);
>      MigrationInfo *info;
>  
> @@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
>  
>      if (info->blocked_reasons) {
>          strList *reasons = info->blocked_reasons;
> -        monitor_printf(mon, "Outgoing migration blocked:\n");
> +        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
>          while (reasons) {
> -            monitor_printf(mon, "  %s\n", reasons->value);
> +            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
>              reasons = reasons->next;
>          }
>      }
>  
>      if (info->has_status) {
> -        monitor_printf(mon, "Status: \t\t%s",
> -                       MigrationStatus_str(info->status));
> +        monitor_hmp_printf(hmp, "Status: \t\t%s",
> +                           MigrationStatus_str(info->status));
>          if ((info->status == MIGRATION_STATUS_FAILED ||
>               info->status == MIGRATION_STATUS_POSTCOPY_PAUSED) &&
>              info->error_desc) {
> -            monitor_printf(mon, " (%s)\n", info->error_desc);
> +            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
>          } else {
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>  
>          if (info->total_time) {
> -            monitor_printf(mon, "Time (ms): \t\ttotal=%" PRIu64,
> -                           info->total_time);
> +            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=%" PRIu64,
> +                               info->total_time);
>              if (info->has_setup_time) {
> -                monitor_printf(mon, ", setup=%" PRIu64,
> -                               info->setup_time);
> +                monitor_hmp_printf(hmp, ", setup=%" PRIu64,
> +                                   info->setup_time);
>              }
>              if (info->has_expected_downtime) {
> -                monitor_printf(mon, ", exp_down=%" PRIu64,
> -                               info->expected_downtime);
> +                monitor_hmp_printf(hmp, ", exp_down=%" PRIu64,
> +                                   info->expected_downtime);
>              }
>              if (info->has_downtime) {
> -                monitor_printf(mon, ", down=%" PRIu64,
> -                               info->downtime);
> +                monitor_hmp_printf(hmp, ", down=%" PRIu64,
> +                                   info->downtime);
>              }
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>      }
>  
>      if (info->has_remaining) {
>          g_autofree char *remaining = size_to_str(info->remaining);
> -        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
> +        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
>      }
>  
>      if (info->has_socket_address) {
>          SocketAddressList *addr;
>  
> -        monitor_printf(mon, "Sockets: [\n");
> +        monitor_hmp_printf(hmp, "Sockets: [\n");
>  
>          for (addr = info->socket_address; addr; addr = addr->next) {
>              char *s = socket_uri(addr->value);
> -            monitor_printf(mon, "\t%s\n", s);
> +            monitor_hmp_printf(hmp, "\t%s\n", s);
>              g_free(s);
>          }
> -        monitor_printf(mon, "]\n");
> +        monitor_hmp_printf(hmp, "]\n");
>      }
>  
>      if (info->ram) {
> @@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
>          g_autofree char *str_multifd = size_to_str(info->ram->multifd_bytes);
>          g_autofree char *str_postcopy = size_to_str(info->ram->postcopy_bytes);
>  
> -        monitor_printf(mon, "RAM info:\n");
> -        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
> -                       info->ram->mbps);
> -        monitor_printf(mon, "  Sizes: \t\tpagesize=%s, total=%s\n",
> -                       str_psize, str_total);
> -        monitor_printf(mon, "  Transfers: \t\ttransferred=%s, remain=%s\n",
> -                       str_transferred, str_remaining);
> -        monitor_printf(mon, "    Channels: \t\tprecopy=%s, "
> -                       "multifd=%s, postcopy=%s",
> -                       str_precopy, str_multifd, str_postcopy);
> +        monitor_hmp_printf(hmp, "RAM info:\n");
> +        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
> +                           info->ram->mbps);
> +        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=%s, total=%s\n",
> +                           str_psize, str_total);
> +        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=%s, remain=%s\n",
> +                           str_transferred, str_remaining);
> +        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=%s, "
> +                           "multifd=%s, postcopy=%s",
> +                           str_precopy, str_multifd, str_postcopy);
>  
>          if (info->vfio) {
>              g_autofree char *str_vfio = size_to_str(info->vfio->transferred);
>  
> -            monitor_printf(mon, ", vfio=%s", str_vfio);
> +            monitor_hmp_printf(hmp, ", vfio=%s", str_vfio);
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>  
> -        monitor_printf(mon, "    Page Types: \tnormal=%" PRIu64
> -                       ", zero=%" PRIu64 "\n",
> -                       info->ram->normal, info->ram->duplicate);
> -        monitor_printf(mon, "  Page Rates (pps): \ttransfer=%" PRIu64,
> -                       info->ram->pages_per_second);
> +        monitor_hmp_printf(hmp, "    Page Types: \tnormal=%" PRIu64
> +                           ", zero=%" PRIu64 "\n",
> +                           info->ram->normal, info->ram->duplicate);
> +        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=%" PRIu64,
> +                           info->ram->pages_per_second);
>          if (info->ram->dirty_pages_rate) {
> -            monitor_printf(mon, ", dirty=%" PRIu64,
> -                           info->ram->dirty_pages_rate);
> +            monitor_hmp_printf(hmp, ", dirty=%" PRIu64,
> +                               info->ram->dirty_pages_rate);
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>  
> -        monitor_printf(mon, "  Others: \t\tdirty_syncs=%" PRIu64,
> -                       info->ram->dirty_sync_count);
> +        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=%" PRIu64,
> +                           info->ram->dirty_sync_count);
>          if (info->ram->postcopy_requests) {
> -            monitor_printf(mon, ", postcopy_req=%" PRIu64,
> -                           info->ram->postcopy_requests);
> +            monitor_hmp_printf(hmp, ", postcopy_req=%" PRIu64,
> +                               info->ram->postcopy_requests);
>          }
>          if (info->ram->downtime_bytes) {
> -            monitor_printf(mon, ", downtime_bytes=%" PRIu64,
> -                           info->ram->downtime_bytes);
> +            monitor_hmp_printf(hmp, ", downtime_bytes=%" PRIu64,
> +                               info->ram->downtime_bytes);
>          }
>          if (info->ram->dirty_sync_missed_zero_copy) {
> -            monitor_printf(mon, ", zerocopy_fallbacks=%" PRIu64,
> -                           info->ram->dirty_sync_missed_zero_copy);
> +            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=%" PRIu64,
> +                               info->ram->dirty_sync_missed_zero_copy);
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>      }
>  
>      if (!show_all) {
>          goto out;
>      }
>  
> -    migration_global_dump(mon);
> +    migration_global_dump(hmp);
>  
>      if (info->xbzrle_cache) {
> -        monitor_printf(mon, "XBZRLE: size=%" PRIu64
> -                       ", transferred=%" PRIu64
> -                       ", pages=%" PRIu64
> -                       ", miss=%" PRIu64 "\n"
> -                       "  miss_rate=%0.2f"
> -                       ", encode_rate=%0.2f"
> -                       ", overflow=%" PRIu64 "\n",
> -                       info->xbzrle_cache->cache_size,
> -                       info->xbzrle_cache->bytes,
> -                       info->xbzrle_cache->pages,
> -                       info->xbzrle_cache->cache_miss,
> -                       info->xbzrle_cache->cache_miss_rate,
> -                       info->xbzrle_cache->encoding_rate,
> -                       info->xbzrle_cache->overflow);
> +        monitor_hmp_printf(hmp, "XBZRLE: size=%" PRIu64
> +                           ", transferred=%" PRIu64
> +                           ", pages=%" PRIu64
> +                           ", miss=%" PRIu64 "\n"
> +                           "  miss_rate=%0.2f"
> +                           ", encode_rate=%0.2f"
> +                           ", overflow=%" PRIu64 "\n",
> +                           info->xbzrle_cache->cache_size,
> +                           info->xbzrle_cache->bytes,
> +                           info->xbzrle_cache->pages,
> +                           info->xbzrle_cache->cache_miss,
> +                           info->xbzrle_cache->cache_miss_rate,
> +                           info->xbzrle_cache->encoding_rate,
> +                           info->xbzrle_cache->overflow);
>      }
>  
>      if (info->has_cpu_throttle_percentage) {
> -        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
> -                       info->cpu_throttle_percentage);
> +        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
> +                           info->cpu_throttle_percentage);
>      }
>  
>      if (info->has_dirty_limit_throttle_time_per_round) {
> -        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n",
> -                       info->dirty_limit_throttle_time_per_round);
> +        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 "\n",
> +                           info->dirty_limit_throttle_time_per_round);
>      }
>  
>      if (info->has_dirty_limit_ring_full_time) {
> -        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
> -                       info->dirty_limit_ring_full_time);
> +        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
> +                           info->dirty_limit_ring_full_time);
>      }
>  
> -    migration_dump_blocktime(mon, info);
> +    migration_dump_blocktime(hmp, info);
>  out:
>      qapi_free_MigrationInfo(info);
>  }
>  
>  void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      MigrationCapabilityStatusList *caps, *cap;
>  
>      caps = qmp_query_migrate_capabilities(NULL);
>  
>      if (caps) {
>          for (cap = caps; cap; cap = cap->next) {
> -            monitor_printf(mon, "%s: %s\n",
> -                           MigrationCapability_str(cap->value->capability),
> -                           cap->value->state ? "on" : "off");
> +            monitor_hmp_printf(hmp, "%s: %s\n",
> +                               MigrationCapability_str(cap->value->capability),
> +                               cap->value->state ? "on" : "off");
>          }
>      }
>  
>      qapi_free_MigrationCapabilityStatusList(caps);
>  }
>  
> -static void monitor_print_cpr_exec_command(Monitor *mon, strList *args)
> +static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *args)
>  {
> -    monitor_printf(mon, "%s:",
> +    monitor_hmp_printf(hmp, "%s:",
>          MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
>  
>      while (args) {
> -        monitor_printf(mon, " %s", args->value);
> +        monitor_hmp_printf(hmp, " %s", args->value);
>          args = args->next;
>      }
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>  }
>  
>  void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      MigrationParameters *params;
>      MigrationState *s = migrate_get_current();
>  
>      params = qmp_query_migrate_parameters(NULL);
>  
>      if (params) {
> -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIAL),
>              params->announce_initial);
> -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
>              params->announce_max);
> -        monitor_printf(mon, "%s: %" PRIu64 "\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS),
>              params->announce_rounds);
> -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
>              params->announce_step);
>          assert(params->has_throttle_trigger_threshold);
> -        monitor_printf(mon, "%s: %u\n",
> +        monitor_hmp_printf(hmp, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD),
>              params->throttle_trigger_threshold);
>          assert(params->has_cpu_throttle_initial);
> -        monitor_printf(mon, "%s: %u\n",
> +        monitor_hmp_printf(hmp, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
>              params->cpu_throttle_initial);
>          assert(params->has_cpu_throttle_increment);
> -        monitor_printf(mon, "%s: %u\n",
> +        monitor_hmp_printf(hmp, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
>              params->cpu_throttle_increment);
>          assert(params->has_cpu_throttle_tailslow);
> -        monitor_printf(mon, "%s: %s\n",
> +        monitor_hmp_printf(hmp, "%s: %s\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW),
>              params->cpu_throttle_tailslow ? "on" : "off");
>          assert(params->has_max_cpu_throttle);
> -        monitor_printf(mon, "%s: %u\n",
> +        monitor_hmp_printf(hmp, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTLE),
>              params->max_cpu_throttle);
>          assert(params->tls_creds);
> -        monitor_printf(mon, "%s: '%s'\n",
> +        monitor_hmp_printf(hmp, "%s: '%s'\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
>                         params->tls_creds->u.s);
>          assert(params->tls_hostname);
> -        monitor_printf(mon, "%s: '%s'\n",
> +        monitor_hmp_printf(hmp, "%s: '%s'\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
>                         params->tls_hostname->u.s);
>          assert(params->tls_authz);
> -        monitor_printf(mon, "%s: '%s'\n",
> +        monitor_hmp_printf(hmp, "%s: '%s'\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
>                         params->tls_authz->u.s);
>          assert(params->has_max_bandwidth);
> -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
>              params->max_bandwidth);
>          assert(params->has_avail_switchover_bandwidth);
> -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVER_BANDWIDTH),
>              params->avail_switchover_bandwidth);
>          assert(params->has_max_postcopy_bandwidth);
> -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH),
>              params->max_postcopy_bandwidth);
>          assert(params->has_downtime_limit);
> -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
>              params->downtime_limit);
>          assert(params->has_x_checkpoint_delay);
> -        monitor_printf(mon, "%s: %u ms\n",
> +        monitor_hmp_printf(hmp, "%s: %u ms\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
>              params->x_checkpoint_delay);
> -        monitor_printf(mon, "%s: %u\n",
> +        monitor_hmp_printf(hmp, "%s: %u\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
>              params->multifd_channels);
> -        monitor_printf(mon, "%s: %s\n",
> +        monitor_hmp_printf(hmp, "%s: %s\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRESSION),
>              MultiFDCompression_str(params->multifd_compression));
>          assert(params->has_zero_page_detection);
> -        monitor_printf(mon, "%s: %s\n",
> +        monitor_hmp_printf(hmp, "%s: %s\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETECTION),
>              qapi_enum_lookup(&ZeroPageDetection_lookup,
>                  params->zero_page_detection));
> -        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
>              params->xbzrle_cache_size);
>  
>          if (s->has_block_bitmap_mapping) {
>              const BitmapMigrationNodeAliasList *bmnal;
>  
> -            monitor_printf(mon, "%s:\n",
> -                           MigrationParameter_str(
> -                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
> +            monitor_hmp_printf(hmp, "%s:\n",
> +                               MigrationParameter_str(
> +                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
>  
>              for (bmnal = params->block_bitmap_mapping;
>                   bmnal;
> @@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
>                  const BitmapMigrationNodeAlias *bmna = bmnal->value;
>                  const BitmapMigrationBitmapAliasList *bmbal;
>  
> -                monitor_printf(mon, "  '%s' -> '%s'\n",
> -                               bmna->node_name, bmna->alias);
> +                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
> +                                   bmna->node_name, bmna->alias);
>  
>                  for (bmbal = bmna->bitmaps; bmbal; bmbal = bmbal->next) {
>                      const BitmapMigrationBitmapAlias *bmba = bmbal->value;
>  
> -                    monitor_printf(mon, "    '%s' -> '%s'\n",
> -                                   bmba->name, bmba->alias);
> +                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
> +                                       bmba->name, bmba->alias);
>                  }
>              }
>          }
>  
> -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
>          MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD),
>          params->x_vcpu_dirty_limit_period);
>  
> -        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
> +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT),
>              params->vcpu_dirty_limit);
>  
>          assert(params->has_mode);
> -        monitor_printf(mon, "%s: %s\n",
> +        monitor_hmp_printf(hmp, "%s: %s\n",
>              MigrationParameter_str(MIGRATION_PARAMETER_MODE),
>              qapi_enum_lookup(&MigMode_lookup, params->mode));
>  
>          if (params->has_direct_io) {
> -            monitor_printf(mon, "%s: %s\n",
> -                           MigrationParameter_str(
> -                               MIGRATION_PARAMETER_DIRECT_IO),
> -                           params->direct_io ? "on" : "off");
> +            monitor_hmp_printf(hmp, "%s: %s\n",
> +                               MigrationParameter_str(
> +                                   MIGRATION_PARAMETER_DIRECT_IO),
> +                               params->direct_io ? "on" : "off");
>          }
>  
>          if (params->has_x_rdma_chunk_size) {
> -            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
> -                           MigrationParameter_str(
> -                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
> -                           params->x_rdma_chunk_size);
> +            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
> +                               MigrationParameter_str(
> +                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
> +                               params->x_rdma_chunk_size);
>          }
>  
>          assert(params->has_cpr_exec_command);
> -        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
> +        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
>      }
>  
>      qapi_free_MigrationParameters(params);
> @@ -857,12 +854,12 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
>      if (uri_cpr) {
>          if (migrate_mode() != MIG_MODE_CPR_TRANSFER) {
>              error_setg(&err, "-c can only be used in cpr-transfer mode");
> -            hmp_handle_error(mon, err);
> +            hmp_handle_error(hmp, err);
>              return;
>          }
>  
>          if (!migrate_uri_parse(uri_cpr, &channel_cpr, &err)) {
> -            hmp_handle_error(mon, err);
> +            hmp_handle_error(hmp, err);
>              return;
>          }
>  
> @@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
>          HMPMigrationStatus *status;
>  
>          if (!hmp->use_readline) {
> -            monitor_printf(mon, "terminal does not allow synchronous "
> -                           "migration, continuing detached\n");
> +            monitor_hmp_printf(hmp, "terminal does not allow synchronous "
> +                               "migration, continuing detached\n");
>              return;
>          }
>          monitor_suspend(mon);
> diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> index 89cc19c2431d..1834e3c1f697 100644
> --- a/monitor/hmp-cmds.c
> +++ b/monitor/hmp-cmds.c
> @@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
>  
>  void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      NameInfo *info;
>  
>      info = qmp_query_name(NULL);
>      if (info->name) {
> -        monitor_printf(mon, "%s\n", info->name);
> +        monitor_hmp_printf(hmp, "%s\n", info->name);
>      }
>      qapi_free_NameInfo(info);
>  }
>  
>  void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      VersionInfo *info;
>  
>      info = qmp_query_version(NULL);
>  
> -    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> -                   info->qemu->major, info->qemu->minor, info->qemu->micro,
> -                   info->package);
> +    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> +                       info->qemu->major, info->qemu->minor, info->qemu->micro,
> +                       info->package);
>  
>      qapi_free_VersionInfo(info);
>  }
> @@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *op = qdict_get_try_str(qdict, "op");
>  
>      if (op == NULL) {
>          bool on = qsp_is_enabled();
>  
> -        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off");
> +        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "off");
>          return;
>      }
>      if (!strcmp(op, "on")) {
> @@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int64_t cpu_index;
>  
>      /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands that
>              use it are converted to the QAPI */
>      cpu_index = qdict_get_int(qdict, "index");
>      if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
> -        monitor_printf(mon, "invalid CPU index\n");
> +        monitor_hmp_printf(hmp, "invalid CPU index\n");
>      }
>  }
>  
> @@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_change(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *device = qdict_get_str(qdict, "device");
>      const char *target = qdict_get_str(qdict, "target");
>      const char *arg = qdict_get_try_str(qdict, "arg");
> @@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdict)
>  
>  #ifdef CONFIG_VNC
>      if (strcmp(device, "vnc") == 0) {
> -        hmp_change_vnc(mon, device, target, arg, read_only, force, &err);
> +        hmp_change_vnc(hmp, device, target, arg, read_only, force, &err);
>      } else
>  #endif
>      {
> -        hmp_change_medium(mon, device, target, arg, read_only, force, &err);
> +        hmp_change_medium(hmp, device, target, arg, read_only, force, &err);
>      }
>  
>      hmp_handle_error(hmp, err);
> @@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
>      IOThreadInfoList *info;
>      IOThreadInfo *value;
>  
>      for (info = info_list; info; info = info->next) {
>          value = info->value;
> -        monitor_printf(mon, "%s:\n", value->id);
> -        monitor_printf(mon, "  thread_id=%" PRId64 "\n", value->thread_id);
> -        monitor_printf(mon, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
> -        monitor_printf(mon, "  poll-grow=%" PRId64 "\n", value->poll_grow);
> -        monitor_printf(mon, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
> -        monitor_printf(mon, "  poll-weight=%" PRId64 "\n", value->poll_weight);
> -        monitor_printf(mon, "  aio-max-batch=%" PRId64 "\n",
> -                       value->aio_max_batch);
> +        monitor_hmp_printf(hmp, "%s:\n", value->id);
> +        monitor_hmp_printf(hmp, "  thread_id=%" PRId64 "\n", value->thread_id);
> +        monitor_hmp_printf(hmp, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
> +        monitor_hmp_printf(hmp, "  poll-grow=%" PRId64 "\n", value->poll_grow);
> +        monitor_hmp_printf(hmp, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
> +        monitor_hmp_printf(hmp, "  poll-weight=%" PRId64 "\n", value->poll_weight);
> +        monitor_hmp_printf(hmp, "  aio-max-batch=%" PRId64 "\n",
> +                           value->aio_max_batch);
>      }
>  
>      qapi_free_IOThreadInfoList(info_list);
> @@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_help(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
> +    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
>  }
>  
>  void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      /*
>       * Send an ANSI escape sequence:
>       * "\x1b[H" - move cursor to top-left
>       * "\x1b[2J" - clear visible screen
>       * "\x1b[3J" - clear scrollback
>       */
> -    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
> +    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
>  }
>  
>  void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    hmp_help_cmd(mon, "info");
> +    hmp_help_cmd(hmp, "info");
>  }
>  
>  void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
> @@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int i;
>      const char *str;
>  
> @@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
>          if (!str) {
>              break;
>          }
> -        monitor_printf(mon, "%d: '%s'\n", i, str);
> +        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
>          i++;
>      }
>  }
> @@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_log(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int mask;
>      const char *items = qdict_get_str(qdict, "items");
>      Error *err = NULL;
> @@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
>      } else {
>          mask = qemu_str_to_log_mask(items);
>          if (!mask) {
> -            hmp_help_cmd(mon, "log");
> +            hmp_help_cmd(hmp, "log");
>              return;
>          }
>      }
> @@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      const char *device = qdict_get_try_str(qdict, "device");
>  
> @@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
>      if (!gdbserver_start(device, &err)) {
>          error_report_err(err);
>      } else if (strcmp(device, "none") == 0) {
> -        monitor_printf(mon, "Disabled gdbserver\n");
> +        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
>      } else {
> -        monitor_printf(mon, "Waiting for gdb connection on device '%s'\n",
> -                       device);
> +        monitor_hmp_printf(hmp, "Waiting for gdb connection on device '%s'\n",
> +                           device);
>      }
>  }
>  
>  void hmp_print(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int format = qdict_get_int(qdict, "format");
>      hwaddr val = qdict_get_int(qdict, "val");
>  
>      switch(format) {
>      case 'o':
> -        monitor_printf(mon, "%#" HWADDR_PRIo, val);
> +        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
>          break;
>      case 'x':
> -        monitor_printf(mon, "%#" HWADDR_PRIx, val);
> +        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
>          break;
>      case 'u':
> -        monitor_printf(mon, "%" HWADDR_PRIu, val);
> +        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
>          break;
>      default:
>      case 'd':
> -        monitor_printf(mon, "%" HWADDR_PRId, val);
> +        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
>          break;
>      case 'c':
> -        monitor_printc(mon, val);
> +        monitor_hmp_printc(hmp, val);
>          break;
>      }
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>  }
>  
>  void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      uint32_t addr;
>      uint16_t sum;
>      uint32_t start = qdict_get_int(qdict, "start");
> @@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
>          sum = (sum >> 1) | (sum << 15);
>          sum += val;
>      }
> -    monitor_printf(mon, "%05d\n", sum);
> +    monitor_hmp_printf(hmp, "%05d\n", sum);
>  }
>  
>  void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int size = qdict_get_int(qdict, "size");
>      int addr = qdict_get_int(qdict, "addr");
>      int has_index = qdict_haskey(qdict, "index");
> @@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
>          suffix = 'l';
>          break;
>      }
> -    monitor_printf(mon, "port%c[0x%04x] = 0x%0*x\n",
> -                   suffix, addr, size * 2, val);
> +    monitor_hmp_printf(hmp, "port%c[0x%04x] = 0x%0*x\n",
> +                       suffix, addr, size * 2, val);
>  }
>  
>  void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
> @@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *local_err = NULL;
>      const char *bootdevice = qdict_get_str(qdict, "bootdevice");
>  
> @@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
>      if (local_err) {
>          error_report_err(local_err);
>      } else {
> -        monitor_printf(mon, "boot device list now set to %s\n", bootdevice);
> +        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bootdevice);
>      }
>  }
>  
> @@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
> +    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
>  }
>  #endif
>  
> @@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
>  
>  void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
>      int vcpu = qdict_get_try_int(qdict, "vcpu", -1);
>      CPUState *cs;
>  
>      if (all_cpus) {
>          CPU_FOREACH(cs) {
> -            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
> +            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
>              cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
>          }
>      } else {
> @@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
>  
>          if (!cs) {
>              if (vcpu >= 0) {
> -                monitor_printf(mon, "CPU#%d not available\n", vcpu);
> +                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu);
>              } else {
> -                monitor_printf(mon, "No CPU available\n");
> +                monitor_hmp_printf(hmp, "No CPU available\n");
>              }
>              return;
>          }
>  
> -        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
> +        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
>          cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
>      }
>  }
> @@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
>  static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
>                          uint64_t addr, bool is_physical)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int l, line_size, i, max_digits, len;
>      uint8_t buf[16];
>      uint64_t v;
> @@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
>      const bool big_endian = target_big_endian();
>  
>      if (!cs && (format == 'i' || !is_physical)) {
> -        monitor_printf(mon, "Can not dump without CPU\n");
> +        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
>          return;
>      }
>  
>      if (format == 'i') {
> -        monitor_disas(mon, cs, addr, count, is_physical);
> +        monitor_disas(hmp, cs, addr, count, is_physical);
>          return;
>      }
>  
> @@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
>      }
>  
>      while (len > 0) {
> -        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
> +        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
>          l = len;
>          if (l > line_size) {
>              l = line_size;
> @@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
>              MemTxResult r = address_space_read(as, addr,
>                                                 MEMTXATTRS_UNSPECIFIED, buf, l);
>              if (r != MEMTX_OK) {
> -                monitor_printf(mon, " Cannot access memory\n");
> +                monitor_hmp_printf(hmp, " Cannot access memory\n");
>                  break;
>              }
>          } else {
>              if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
> -                monitor_printf(mon, " Cannot access memory\n");
> +                monitor_hmp_printf(hmp, " Cannot access memory\n");
>                  break;
>              }
>          }
> @@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
>                  v = (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
>                  break;
>              }
> -            monitor_printf(mon, " ");
> +            monitor_hmp_printf(hmp, " ");
>              switch (format) {
>              case 'o':
> -                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
> +                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
>                  break;
>              case 'x':
> -                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
> +                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v);
>                  break;
>              case 'u':
> -                monitor_printf(mon, "%*" PRIu64, max_digits, v);
> +                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
>                  break;
>              case 'd':
> -                monitor_printf(mon, "%*" PRId64, max_digits, v);
> +                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
>                  break;
>              case 'c':
> -                monitor_printc(mon, v);
> +                monitor_hmp_printc(hmp, v);
>                  break;
>              }
>              i += wsize;
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>          addr += l;
>          len -= l;
>      }
> @@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      hwaddr addr = qdict_get_int(qdict, "addr");
>      Error *local_err = NULL;
>      MemoryRegion *mr = NULL;
> @@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
> -                   " (%s) is %p\n",
> -                   addr, mr->name, ptr);
> +    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
> +                       " (%s) is %p\n",
> +                       addr, mr->name, ptr);
>  
>      memory_region_unref(mr);
>  }
>  
>  void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      vaddr addr = qdict_get_int(qdict, "addr");
>      CPUState *cs = monitor_hmp_get_cpu(hmp);
>      TranslateForDebugResult tres;
>  
>      if (!cs) {
> -        monitor_printf(mon, "No cpu\n");
> +        monitor_hmp_printf(hmp, "No cpu\n");
>          return;
>      }
>  
>      if (!cpu_translate_for_debug(cs, addr, &tres)) {
> -        monitor_printf(mon, "Unmapped\n");
> +        monitor_hmp_printf(hmp, "Unmapped\n");
>      } else {
> -        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
> +        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
>      }
>  }
>  
> @@ -806,7 +786,6 @@ out:
>  
>  void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      hwaddr addr = qdict_get_int(qdict, "addr");
>      Error *local_err = NULL;
>      MemoryRegion *mr = NULL;
> @@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
>      if (local_err) {
>          error_report_err(local_err);
>      } else {
> -        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRIx
> -                       " (%s) is 0x%" PRIx64 "\n",
> -                       addr, mr->name, (uint64_t) physaddr);
> +        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR_PRIx
> +                           " (%s) is 0x%" PRIx64 "\n",
> +                           addr, mr->name, (uint64_t) physaddr);
>      }
>  
>      memory_region_unref(mr);
> diff --git a/monitor/hmp.c b/monitor/hmp.c
> index 2484a2310dff..e5f8b9c576e0 100644
> --- a/monitor/hmp.c
> +++ b/monitor/hmp.c
> @@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, bool val, Error **errp)
>      hmp->use_readline = val;
>  }
>  
> -int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
> -    G_GNUC_PRINTF(2, 0);
>  static void monitor_hmp_accept_input(Monitor *mon);
>  static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
>  static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp);
> @@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, const void *data)
>                                     monitor_hmp_get_readline,
>                                     monitor_hmp_set_readline);
>  
> -    moncls->vprintf = monitor_hmp_vprintf;
>      moncls->accept_input = monitor_hmp_accept_input;
>  
>      ucc->complete = monitor_hmp_complete;
> @@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
>      hmp->use_readline = true;
>  }
>  
> -int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
> -{
> -    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
> -    return monitor_puts(mon, buf);
> -}
> -
>  static void monitor_hmp_accept_input(Monitor *mon)
>  {
>      qemu_mutex_lock(&mon->mon_lock);
> @@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
>          /* prompt is printed on return from the command handler */
>          return 0;
>      } else {
> -        monitor_printf(&hmp->parent_obj,
> -                       "terminal does not support password prompting\n");
> +        monitor_hmp_printf(hmp, "terminal does not support password prompting\n");
>          return -ENOTTY;
>      }
>  }
> @@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
>      return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
>  }
>  
> -static void help_cmd_dump_one(Monitor *mon,
> +static void help_cmd_dump_one(MonitorHMP *mon,
>                                const HMPCommand *cmd,
>                                char **prefix_args,
>                                int prefix_args_nb)
> @@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
>      }
>  
>      for (i = 0; i < prefix_args_nb; i++) {
> -        monitor_printf(mon, "%s ", prefix_args[i]);
> +        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
>      }
> -    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
> +    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
>  }
>  
>  /* @args[@arg_index] is the valid command need to find in @cmds */
> -static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
> +static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
>                            char **args, int nb_args, int arg_index)
>  {
>      const HMPCommand *cmd;
> @@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
>      }
>  
>      /* Command not found */
> -    monitor_printf(mon, "unknown command: '");
> +    monitor_hmp_printf(mon, "unknown command: '");
>      for (i = 0; i <= arg_index; i++) {
> -        monitor_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
> +        monitor_hmp_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
>      }
>  }
>  
> -void hmp_help_cmd(Monitor *mon, const char *name)
> +void hmp_help_cmd(MonitorHMP *mon, const char *name)
>  {
>      char *args[MAX_ARGS];
>      int nb_args = 0;
> @@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
>          /* special case for log, directly dump and return */
>          if (!strcmp(name, "log")) {
>              const QEMULogItem *item;
> -            monitor_printf(mon, "Log items (comma separated):\n");
> -            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs");
> +            monitor_hmp_printf(mon, "Log items (comma separated):\n");
> +            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all logs");
>              for (item = qemu_log_items; item->mask != 0; item++) {
> -                monitor_printf(mon, "%-15s %s\n", item->name, item->help);
> +                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item->help);
>              }
>  #ifdef CONFIG_TRACE_LOG
> -            monitor_printf(mon, "trace:PATTERN   enable trace events\n");
> -            monitor_printf(mon, "\nUse \"log trace:help\" to get a list of "
> -                           "trace events.\n\n");
> +            monitor_hmp_printf(mon, "trace:PATTERN   enable trace events\n");
> +            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a list of "
> +                               "trace events.\n\n");
>  #endif
>              return;
>          }
> @@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
>  static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char *name);
>  
>  static G_NORETURN G_GNUC_PRINTF(2, 3)
> -void expr_error(Monitor *mon, const char *fmt, ...)
> +void expr_error(MonitorHMP *mon, const char *fmt, ...)
>  {
>      va_list ap;
>      va_start(ap, fmt);
> -    monitor_vprintf(mon, fmt, ap);
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_vprintf(mon, fmt, ap);
> +    monitor_hmp_printf(mon, "\n");
>      va_end(ap);
>      siglongjmp(expr_env, 1);
>  }
> @@ -475,9 +465,9 @@ static void next(void)
>      }
>  }
>  
> -static int64_t expr_sum(Monitor *mon);
> +static int64_t expr_sum(MonitorHMP *mon);
>  
> -static int64_t expr_unary(Monitor *mon)
> +static int64_t expr_unary(MonitorHMP *mon)
>  {
>      int64_t n;
>      char *p;
> @@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
>                  pch++;
>              }
>              *q = 0;
> -            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
> -                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
> +            if (!gdb_get_register(mon, &reg, buf)
> +                && get_monitor_def(mon, &reg, buf) < 0) {
>                  expr_error(mon, "unknown register");
>              }
>              n = reg;
> @@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
>      return n;
>  }
>  
> -static int64_t expr_prod(Monitor *mon)
> +static int64_t expr_prod(MonitorHMP *mon)
>  {
>      int64_t val, val2;
>      int op;
> @@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
>      return val;
>  }
>  
> -static int64_t expr_logic(Monitor *mon)
> +static int64_t expr_logic(MonitorHMP *mon)
>  {
>      int64_t val, val2;
>      int op;
> @@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
>      return val;
>  }
>  
> -static int64_t expr_sum(Monitor *mon)
> +static int64_t expr_sum(MonitorHMP *mon)
>  {
>      int64_t val, val2;
>      int op;
> @@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
>      return val;
>  }
>  
> -static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
> +static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
>  {
>      pch = *pp;
>      if (sigsetjmp(expr_env, 0)) {
> @@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
>      return 0;
>  }
>  
> -static int get_double(Monitor *mon, double *pval, const char **pp)
> +static int get_double(MonitorHMP *mon, double *pval, const char **pp)
>  {
>      const char *p = *pp;
>      char *tailp;
> @@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval, const char **pp)
>  
>      d = strtod(p, &tailp);
>      if (tailp == p) {
> -        monitor_printf(mon, "Number expected\n");
> +        monitor_hmp_printf(mon, "Number expected\n");
>          return -1;
>      }
>      if (d != d || d - d != 0) {
>          /* NaN or infinity */
> -        monitor_printf(mon, "Bad number\n");
> +        monitor_hmp_printf(mon, "Bad number\n");
>          return -1;
>      }
>      *pval = d;
> @@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
>                                                 const char **cmdp,
>                                                 HMPCommand *table)
>  {
> -    Monitor *mon = &hmp->parent_obj;
>      const char *p;
>      const HMPCommand *cmd;
>      char cmdname[256];
> @@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
>  
>      cmd = search_dispatch_table(table, cmdname);
>      if (!cmd) {
> -        monitor_printf(mon, "unknown command: '%.*s'\n",
> -                       (int)(p - cmdp_start), cmdp_start);
> +        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
> +                           (int)(p - cmdp_start), cmdp_start);
>          return NULL;
>      }
>      if (!cmd_available(cmd)) {
> -        monitor_printf(mon, "Command '%.*s' not available "
> -                            "until machine initialization has completed.\n",
> -                       (int)(p - cmdp_start), cmdp_start);
> +        monitor_hmp_printf(hmp, "Command '%.*s' not available "
> +                           "until machine initialization has completed.\n",
> +                           (int)(p - cmdp_start), cmdp_start);
>          return NULL;
>      }
>  
> @@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
>   * Else, insert command arguments into a QDict, and return it.
>   * Note: On success, caller has to free the QDict structure.
>   */
> -static QDict *monitor_parse_arguments(Monitor *mon,
> +static QDict *monitor_parse_arguments(MonitorHMP *mon,
>                                        const char **endp,
>                                        const HMPCommand *cmd)
>  {
> @@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                  if (ret < 0) {
>                      switch (c) {
>                      case 'F':
> -                        monitor_printf(mon, "%s: filename expected\n",
> -                                       cmd->name);
> +                        monitor_hmp_printf(mon, "%s: filename expected\n",
> +                                           cmd->name);
>                          break;
>                      case 'B':
> -                        monitor_printf(mon, "%s: block device name expected\n",
> -                                       cmd->name);
> +                        monitor_hmp_printf(mon, "%s: block device name expected\n",
> +                                           cmd->name);
>                          break;
>                      default:
> -                        monitor_printf(mon, "%s: string expected\n", cmd->name);
> +                        monitor_hmp_printf(mon, "%s: string expected\n", cmd->name);
>                          break;
>                      }
>                      goto fail;
> @@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                      }
>                  next:
>                      if (*p != '\0' && !qemu_isspace(*p)) {
> -                        monitor_printf(mon, "invalid char in format: '%c'\n",
> -                                       *p);
> +                        monitor_hmp_printf(mon, "invalid char in format: '%c'\n",
> +                                           *p);
>                          goto fail;
>                      }
>                      if (format < 0) {
> @@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                  }
>                  /* Check if 'i' is greater than 32-bit */
>                  if ((c == 'i') && ((val >> 32) & 0xffffffff)) {
> -                    monitor_printf(mon, "\'%s\' has failed: ", cmd->name);
> -                    monitor_printf(mon, "integer is for 32-bit values\n");
> +                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd->name);
> +                    monitor_hmp_printf(mon, "integer is for 32-bit values\n");
>                      goto fail;
>                  } else if (c == 'M') {
>                      if (val < 0) {
> -                        monitor_printf(mon, "enter a positive value\n");
> +                        monitor_hmp_printf(mon, "enter a positive value\n");
>                          goto fail;
>                      }
>                      val *= MiB;
> @@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                  }
>                  ret = qemu_strtosz_MiB(p, &end, &val);
>                  if (ret < 0 || val > INT64_MAX) {
> -                    monitor_printf(mon, "invalid size\n");
> +                    monitor_hmp_printf(mon, "invalid size\n");
>                      goto fail;
>                  }
>                  qdict_put_int(qdict, key, val);
> @@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                      }
>                  }
>                  if (*p && !qemu_isspace(*p)) {
> -                    monitor_printf(mon, "Unknown unit suffix\n");
> +                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
>                      goto fail;
>                  }
>                  qdict_put(qdict, key, qnum_from_double(val));
> @@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                  } else if (p - beg == 3 && !memcmp(beg, "off", p - beg)) {
>                      val = false;
>                  } else {
> -                    monitor_printf(mon, "Expected 'on' or 'off'\n");
> +                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n");
>                      goto fail;
>                  }
>                  qdict_put_bool(qdict, key, val);
> @@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                      p++;
>                      if (c != *p) {
>                          if (!is_valid_option(p, typestr)) {
> -                            monitor_printf(mon, "%s: unsupported option -%c\n",
> -                                           cmd->name, *p);
> +                            monitor_hmp_printf(mon, "%s: unsupported option -%c\n",
> +                                               cmd->name, *p);
>                              goto fail;
>                          } else {
>                              skip_key = 1;
> @@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                          }
>                          ret = get_str(buf, sizeof(buf), &p);
>                          if (ret < 0) {
> -                            monitor_printf(mon, "%s: value expected for -%c\n",
> -                                           cmd->name, *tmp);
> +                            monitor_hmp_printf(mon, "%s: value expected for -%c\n",
> +                                               cmd->name, *tmp);
>                              goto fail;
>                          }
>                          qdict_put_str(qdict, key, buf);
> @@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>                  }
>                  len = strlen(p);
>                  if (len <= 0) {
> -                    monitor_printf(mon, "%s: string expected\n",
> -                                   cmd->name);
> +                    monitor_hmp_printf(mon, "%s: string expected\n",
> +                                       cmd->name);
>                      goto fail;
>                  }
>                  qdict_put_str(qdict, key, p);
> @@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>              break;
>          default:
>          bad_type:
> -            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
> +            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
>              goto fail;
>          }
>          g_free(key);
> @@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
>          p++;
>      }
>      if (*p != '\0') {
> -        monitor_printf(mon, "%s: extraneous characters at the end of line\n",
> -                       cmd->name);
> +        monitor_hmp_printf(mon, "%s: extraneous characters at the end of line\n",
> +                           cmd->name);
>          goto fail;
>      }
>  
> @@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const char *cmdline)
>  
>      if (!cmd->cmd && !cmd->cmd_info_hrt) {
>          /* FIXME: is it useful to try autoload modules here ??? */
> -        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not available.\n",
> -                       (int)(cmdline - cmd_start), cmd_start);
> +        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n",
> +                           (int)(cmdline - cmd_start), cmd_start);
>          return;
>      }
>  
> -    qdict = monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd);
> +    qdict = monitor_parse_arguments(hmp, &cmdline, cmd);
>      if (!qdict) {
>          while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
>              cmdline--;
>          }
> -        monitor_printf(&hmp->parent_obj,
> -                       "Try \"help %.*s\" for more information\n",
> -                       (int)(cmdline - cmd_start), cmd_start);
> +        monitor_hmp_printf(hmp,
> +                           "Try \"help %.*s\" for more information\n",
> +                           (int)(cmdline - cmd_start), cmd_start);
>          return;
>      }
>  
> @@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint8_t *buf, int size)
>          }
>      } else {
>          if (size == 0 || buf[size - 1] != 0) {
> -            monitor_printf(&hmp->parent_obj, "corrupted command\n");
> +            monitor_hmp_printf(hmp, "corrupted command\n");
>          } else {
>              handle_hmp_command(hmp, (char *)buf);
>          }
> @@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEvent event)
>          break;
>  
>      case CHR_EVENT_OPENED:
> -        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
> -                       "information\n", QEMU_VERSION);
> +        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for more "
> +                           "information\n", QEMU_VERSION);
>          qemu_mutex_lock(&mon->mon_lock);
>          hmp->reset_seen = 1;
>          if (!mon->mux_out && hmp->use_readline) {
> @@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_printf(void *opaque,
>      MonitorHMP *hmp = opaque;
>      va_list ap;
>      va_start(ap, fmt);
> -    monitor_vprintf(&hmp->parent_obj, fmt, ap);
> +    monitor_hmp_vprintf(hmp, fmt, ap);
>      va_end(ap);
>  }
>  
> diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
> index afdda1386080..c198c12eaa00 100644
> --- a/monitor/monitor-internal.h
> +++ b/monitor/monitor-internal.h
> @@ -108,12 +108,6 @@ typedef struct HMPCommand {
>  struct MonitorClass {
>      ObjectClass parent_class;
>  
> -    /*
> -     * If non-NULL, the monitor is able to print messages
> -     * for attention of the client user
> -     */
> -    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
> -        G_GNUC_PRINTF(2, 0);
>      /*
>       * If non-NULL, the monitor is able to send event
>       * notifications back to the client
> diff --git a/monitor/monitor.c b/monitor/monitor.c
> index 8528af6f79b8..da76e6e4ac19 100644
> --- a/monitor/monitor.c
> +++ b/monitor/monitor.c
> @@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
>      return monitor_puts_locked(mon, str);
>  }
>  
> -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
>  {
> -    MonitorClass *moncls;
> +    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
>  
>      if (!mon) {
>          return -1;
>      }
>  
> -    moncls = MONITOR_GET_CLASS(mon);
> -    if (!moncls->vprintf) {
> -        return -1;
> -    }
> -
> -    return moncls->vprintf(mon, fmt, ap);
> +    return monitor_puts(MONITOR(mon), buf);
>  }
>  
> -int monitor_printf(Monitor *mon, const char *fmt, ...)
> +int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
>  {
>      int ret;
>  
>      va_list ap;
>      va_start(ap, fmt);
> -    ret = monitor_vprintf(mon, fmt, ap);
> +    ret = monitor_hmp_vprintf(mon, fmt, ap);
>      va_end(ap);
>      return ret;
>  }
>  
> -void monitor_printc(Monitor *mon, int c)
> +void monitor_hmp_printc(MonitorHMP *mon, int c)
>  {
> -    monitor_printf(mon, "'");
> +    monitor_hmp_printf(mon, "'");
>      switch(c) {
>      case '\'':
> -        monitor_printf(mon, "\\'");
> +        monitor_hmp_printf(mon, "\\'");
>          break;
>      case '\\':
> -        monitor_printf(mon, "\\\\");
> +        monitor_hmp_printf(mon, "\\\\");
>          break;
>      case '\n':
> -        monitor_printf(mon, "\\n");
> +        monitor_hmp_printf(mon, "\\n");
>          break;
>      case '\r':
> -        monitor_printf(mon, "\\r");
> +        monitor_hmp_printf(mon, "\\r");
>          break;
>      default:
>          if (c >= 32 && c <= 126) {
> -            monitor_printf(mon, "%c", c);
> +            monitor_hmp_printf(mon, "%c", c);
>          } else {
> -            monitor_printf(mon, "\\x%02x", c);
> +            monitor_hmp_printf(mon, "\\x%02x", c);
>          }
>          break;
>      }
> -    monitor_printf(mon, "'");
> +    monitor_hmp_printf(mon, "'");
>  }
>  
>  static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
> diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
> index 5b1c678f5d89..0d718d78aef9 100644
> --- a/net/net-hmp-cmds.c
> +++ b/net/net-hmp-cmds.c
> @@ -28,26 +28,25 @@
>  #include "qemu/help_option.h"
>  #include "qemu/option.h"
>  
> -static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
> +static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *ci)
>  {
>      NetFilterInfoList *f;
>  
> -    monitor_printf(mon, "%s: index=%" PRIu32 ",type=%s,%s\n",
> -                   ci->name, ci->queue_index,
> -                   NetClientDriver_str(ci->type), ci->info_str);
> +    monitor_hmp_printf(hmp, "%s: index=%" PRIu32 ",type=%s,%s\n",
> +                       ci->name, ci->queue_index,
> +                       NetClientDriver_str(ci->type), ci->info_str);
>      if (ci->filters) {
> -        monitor_printf(mon, "filters:\n");
> +        monitor_hmp_printf(hmp, "filters:\n");
>          for (f = ci->filters; f; f = f->next) {
> -            monitor_printf(mon, "  - %s: type=%s%s%s\n",
> -                           f->value->name, f->value->type,
> -                           f->value->info[0] ? "," : "", f->value->info);
> +            monitor_hmp_printf(hmp, "  - %s: type=%s%s%s\n",
> +                               f->value->name, f->value->type,
> +                               f->value->info[0] ? "," : "", f->value->info);
>          }
>      }
>  }
>  
>  void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      Error *err = NULL;
>      g_autoptr(NetworkInfo) info = qmp_x_query_network(&err);
>      NetHubInfoList *h;
> @@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
>      for (h = info->hubs; h; h = h->next) {
>          NetHubPortInfoList *p;
>  
> -        monitor_printf(mon, "hub %d\n", (int)h->value->id);
> +        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
>          for (p = h->value->ports; p; p = p->next) {
>              if (p->value->peer) {
> -                monitor_printf(mon, " \\ %s: ", p->value->name);
> -                hmp_print_client_info(mon, p->value->peer);
> +                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
> +                hmp_print_client_info(hmp, p->value->peer);
>              } else {
> -                monitor_printf(mon, " \\ %s\n", p->value->name);
> +                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
>              }
>          }
>      }
> @@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
>          NetworkClientInfo *ci = entry->value;
>  
>          if (!ci->peer || ci->type == NET_CLIENT_DRIVER_NIC) {
> -            hmp_print_client_info(mon, ci);
> +            hmp_print_client_info(hmp, ci);
>          } /* else it's a netdev connected to a NIC, printed with the NIC */
>          if (ci->peer && ci->type == NET_CLIENT_DRIVER_NIC) {
> -            monitor_printf(mon, " \\ ");
> -            hmp_print_client_info(mon, ci->peer);
> +            monitor_hmp_printf(hmp, " \\ ");
> +            hmp_print_client_info(hmp, ci->peer);
>          }
>      }
>  }
> diff --git a/net/slirp.c b/net/slirp.c
> index d5c190b48b76..6fbefa9ed1d7 100644
> --- a/net/slirp.c
> +++ b/net/slirp.c
> @@ -711,22 +711,22 @@ error:
>      return -1;
>  }
>  
> -static SlirpState *slirp_lookup(Monitor *mon, const char *id)
> +static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
>  {
>      if (id) {
>          NetClientState *nc = qemu_find_netdev(id);
>          if (!nc) {
> -            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
> +            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", id);
>              return NULL;
>          }
>          if (strcmp(nc->model, "user")) {
> -            monitor_printf(mon, "invalid device specified\n");
> +            monitor_hmp_printf(hmp, "invalid device specified\n");
>              return NULL;
>          }
>          return DO_UPCAST(SlirpState, nc, nc);
>      } else {
>          if (QTAILQ_EMPTY(&slirp_stacks)) {
> -            monitor_printf(mon, "user mode network stack not in use\n");
> +            monitor_hmp_printf(hmp, "user mode network stack not in use\n");
>              return NULL;
>          }
>          return QTAILQ_FIRST(&slirp_stacks);
> @@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const char *id)
>  
>  void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      /* TODO: support removing unix fwd */
>      struct sockaddr_in host_addr = {
>          .sin_family = AF_INET,
> @@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
>      const char *arg2 = qdict_get_try_str(qdict, "arg2");
>  
>      if (arg2) {
> -        s = slirp_lookup(mon, arg1);
> +        s = slirp_lookup(hmp, arg1);
>          src_str = arg2;
>      } else {
> -        s = slirp_lookup(mon, NULL);
> +        s = slirp_lookup(hmp, NULL);
>          src_str = arg1;
>      }
>      if (!s) {
> @@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
>      err = slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr, host_port);
>  #endif
>  
> -    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
> -                   err ? "not found" : "removed");
> +    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_str,
> +                       err ? "not found" : "removed");
>      return;
>  
>   fail_syntax:
> -    monitor_printf(mon, "invalid format\n");
> +    monitor_hmp_printf(hmp, "invalid format\n");
>  }
>  
>  static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
> @@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
>  
>  void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *redir_str;
>      SlirpState *s;
>      const char *arg1 = qdict_get_str(qdict, "arg1");
>      const char *arg2 = qdict_get_try_str(qdict, "arg2");
>  
>      if (arg2) {
> -        s = slirp_lookup(mon, arg1);
> +        s = slirp_lookup(hmp, arg1);
>          redir_str = arg2;
>      } else {
> -        s = slirp_lookup(mon, NULL);
> +        s = slirp_lookup(hmp, NULL);
>          redir_str = arg1;
>      }
>      if (s) {
> @@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **errp)
>  
>  void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      g_autoptr(UsernetInfoList) list = NULL;
>      UsernetInfoList *entry;
>  
>      list = qmp_x_query_usernet(&error_abort);
>      for (entry = list; entry; entry = entry->next) {
>          UsernetInfo *ui = entry->value;
> -        monitor_printf(mon, "Hub %d (%s):\n%s",
> -                       ui->has_hub_id ? (int)ui->hub_id : -1,
> -                       ui->hub_name, ui->info);
> +        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
> +                           ui->has_hub_id ? (int)ui->hub_id : -1,
> +                           ui->hub_name, ui->info);
>      }
>  }
>  
> diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
> index 2e2eb33371e2..bbf5980332a4 100644
> --- a/qom/qom-hmp-cmds.c
> +++ b/qom/qom-hmp-cmds.c
> @@ -20,13 +20,12 @@
>  
>  void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *path = qdict_get_try_str(qdict, "path");
>      ObjectPropertyInfoList *list;
>      Error *err = NULL;
>  
>      if (path == NULL) {
> -        monitor_printf(mon, "/\n");
> +        monitor_hmp_printf(hmp, "/\n");
>          return;
>      }
>  
> @@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
>          while (list != NULL) {
>              ObjectPropertyInfo *value = list->value;
>  
> -            monitor_printf(mon, "%s (%s)\n",
> -                           value->name, value->type);
> +            monitor_hmp_printf(hmp, "%s (%s)\n",
> +                               value->name, value->type);
>              list = list->next;
>          }
>          qapi_free_ObjectPropertyInfoList(start);
> @@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *path = qdict_get_str(qdict, "path");
>      const char *property = qdict_get_str(qdict, "property");
>      Error *err = NULL;
> @@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
>  
>      if (err == NULL) {
>          GString *str = qobject_to_json_pretty(obj, true);
> -        monitor_printf(mon, "%s\n", str->str);
> +        monitor_hmp_printf(hmp, "%s\n", str->str);
>          g_string_free(str, true);
>      }
>  
> @@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
>      int indent;
>  } QOMCompositionState;
>  
> -static void print_qom_composition(Monitor *mon, Object *obj, int indent);
> +static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent);
>  
>  static int qom_composition_compare(const void *a, const void *b)
>  {
> @@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj, void *opaque)
>      return 0;
>  }
>  
> -static void print_qom_composition(Monitor *mon, Object *obj, int indent)
> +static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent)
>  {
>      GArray *children = g_array_new(false, false, sizeof(Object *));
>      const char *name;
> @@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
>      } else {
>          name = object_get_canonical_path_component(obj);
>      }
> -    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
> -                   object_get_typename(obj));
> +    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
> +                       object_get_typename(obj));
>  
>      object_child_foreach(obj, insert_qom_composition_child, children);
>      g_array_sort(children, qom_composition_compare);
>  
>      for (i = 0; i < children->len; i++) {
> -        print_qom_composition(mon, g_array_index(children, Object *, i),
> +        print_qom_composition(hmp, g_array_index(children, Object *, i),
>                                indent + 2);
>      }
>      g_array_free(children, TRUE);
> @@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
>  
>  void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *path = qdict_get_try_str(dict, "path");
>      Object *obj;
>      bool ambiguous = false;
> @@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
>      if (path) {
>          obj = object_resolve_path(path, &ambiguous);
>          if (!obj) {
> -            monitor_printf(mon, "Path '%s' could not be resolved.\n", path);
> +            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\n", path);
>              return;
>          }
>          if (ambiguous) {
> -            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", path);
> +            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\n", path);
>              return;
>          }
>      } else {
>          obj = qdev_get_machine();
>      }
> -    print_qom_composition(mon, obj, 0);
> +    print_qom_composition(hmp, obj, 0);
>  }
>  
>  void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
> diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
> index ef69d23ff507..965565715ef2 100644
> --- a/replay/replay-debugging.c
> +++ b/replay/replay-debugging.c
> @@ -33,11 +33,10 @@ bool replay_running_debug(void)
>  
>  void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      if (replay_mode == REPLAY_MODE_NONE) {
> -        monitor_printf(mon, "Record/replay is not active\n");
> +        monitor_hmp_printf(hmp, "Record/replay is not active\n");
>      } else {
> -        monitor_printf(mon,
> +        monitor_hmp_printf(hmp,
>              "%s execution '%s': instruction count = %"PRId64"\n",
>              replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
>              replay_get_filename(), replay_get_current_icount());
> diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
> index cd1f1deb58bc..3d556c745d61 100644
> --- a/stats/stats-hmp-cmds.c
> +++ b/stats/stats-hmp-cmds.c
> @@ -14,11 +14,11 @@
>  #include "qobject/qdict.h"
>  #include "qapi/error.h"
>  
> -static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
> +static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue *value)
>  {
>      const char *unit = NULL;
> -    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(value->type),
> -                   value->has_unit || value->exponent ? ", " : "");
> +    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str(value->type),
> +                       value->has_unit || value->exponent ? ", " : "");
>  
>      if (value->has_unit) {
>          if (value->unit == STATS_UNIT_SECONDS) {
> @@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
>      if (unit && value->base == 10 &&
>          value->exponent >= -18 && value->exponent <= 18 &&
>          value->exponent % 3 == 0) {
> -        monitor_puts(mon, si_prefix(value->exponent));
> +        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
>      } else if (unit && value->base == 2 &&
>                 value->exponent >= 0 && value->exponent <= 60 &&
>                 value->exponent % 10 == 0) {
>  
> -        monitor_puts(mon, iec_binary_prefix(value->exponent));
> +        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent));
>      } else if (value->exponent) {
>          /* Use exponential notation and write the unit's English name */
> -        monitor_printf(mon, "* %d^%d%s",
> -                       value->base, value->exponent,
> -                       value->has_unit ? " " : "");
> +        monitor_hmp_printf(hmp, "* %d^%d%s",
> +                           value->base, value->exponent,
> +                           value->has_unit ? " " : "");
>          unit = NULL;
>      }
>  
>      if (value->has_unit) {
> -        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
> +        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->unit));
>      }
>  
>      /* Print bucket size for linear histograms */
>      if (value->type == STATS_TYPE_LINEAR_HISTOGRAM && value->has_bucket_size) {
> -        monitor_printf(mon, ", bucket size=%d", value->bucket_size);
> +        monitor_hmp_printf(hmp, ", bucket size=%d", value->bucket_size);
>      }
> -    monitor_printf(mon, ")");
> +    monitor_hmp_printf(hmp, ")");
>  }
>  
>  static StatsSchemaValueList *find_schema_value_list(
> @@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
>      return NULL;
>  }
>  
> -static void print_stats_results(Monitor *mon, StatsTarget target,
> +static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
>                                  bool show_provider,
>                                  StatsResult *result,
>                                  StatsSchemaList *schema)
> @@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
>      StatsList *stats_list;
>  
>      if (!schema_value_list) {
> -        monitor_printf(mon, "failed to find schema list for %s\n",
> -                       StatsProvider_str(result->provider));
> +        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
> +                           StatsProvider_str(result->provider));
>          return;
>      }
>  
>      if (show_provider) {
> -        monitor_printf(mon, "provider: %s\n",
> -                       StatsProvider_str(result->provider));
> +        monitor_hmp_printf(hmp, "provider: %s\n",
> +                           StatsProvider_str(result->provider));
>      }
>  
>      for (stats_list = result->stats; stats_list;
> @@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
>          /* Find schema entry */
>          while (!g_str_equal(stats->name, schema_value->name)) {
>              if (!schema_value_list->next) {
> -                monitor_printf(mon, "failed to find schema entry for %s\n",
> -                               stats->name);
> +                monitor_hmp_printf(hmp, "failed to find schema entry for %s\n",
> +                                   stats->name);
>                  return;
>              }
>              schema_value_list = schema_value_list->next;
>              schema_value = schema_value_list->value;
>          }
>  
> -        print_stats_schema_value(mon, schema_value);
> +        print_stats_schema_value(hmp, schema_value);
>  
>          if (stats_value->type == QTYPE_QNUM) {
> -            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scalar);
> +            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.scalar);
>          } else if (stats_value->type == QTYPE_QBOOL) {
> -            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "yes" : "no");
> +            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ? "yes" : "no");
>          } else if (stats_value->type == QTYPE_QLIST) {
>              uint64List *list;
>              int i;
>  
> -            monitor_printf(mon, ": ");
> +            monitor_hmp_printf(hmp, ": ");
>              for (list = stats_value->u.list, i = 1;
>                   list;
>                   list = list->next, i++) {
> -                monitor_printf(mon, "[%d]=%" PRId64 " ", i, list->value);
> +                monitor_hmp_printf(hmp, "[%d]=%" PRId64 " ", i, list->value);
>              }
> -            monitor_printf(mon, "\n");
> +            monitor_hmp_printf(hmp, "\n");
>          }
>      }
>  }
> @@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target, const char *names,
>  
>  void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *target_str = qdict_get_str(qdict, "target");
>      const char *provider_str = qdict_get_try_str(qdict, "provider");
>      const char *names = qdict_get_try_str(qdict, "names");
> @@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
>  
>      target = qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &err);
>      if (err) {
> -        monitor_printf(mon, "invalid stats target %s\n", target_str);
> +        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_str);
>          goto exit_no_print;
>      }
>      if (provider_str) {
>          provider = qapi_enum_parse(&StatsProvider_lookup, provider_str, -1, &err);
>          if (err) {
> -            monitor_printf(mon, "invalid stats provider %s\n", provider_str);
> +            monitor_hmp_printf(hmp, "invalid stats provider %s\n", provider_str);
>              goto exit_no_print;
>          }
>      }
> @@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
>          goto exit;
>      }
>      for (entry = stats; entry; entry = entry->next) {
> -        print_stats_results(mon, target, provider_str == NULL, entry->value, schema);
> +        print_stats_results(hmp, target, provider_str == NULL, entry->value, schema);
>      }
>  
>  exit:
>      if (err) {
> -        monitor_printf(mon, "%s\n", error_get_pretty(err));
> +        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
>      }
>  exit_no_print:
>      error_free(err);
> diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
> index 6f2b87d1ad10..c9c1d10c165c 100644
> --- a/stubs/hmp-cmd-info_sev.c
> +++ b/stubs/hmp-cmd-info_sev.c
> @@ -12,6 +12,5 @@
>  
>  void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
> -    monitor_printf(mon, "SEV is not available in this QEMU\n");
> +    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
>  }
> diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
> index b0c7002bd406..094b80721003 100644
> --- a/stubs/monitor-core.c
> +++ b/stubs/monitor-core.c
> @@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
>  {
>  }
>  
> -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
>  {
>      /*
>       * Pretend 'g_test_message' is our monitor console to
> diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.c
> index 75194add7931..fb9338e9aef6 100644
> --- a/system/dirtylimit-hmp-cmds.c
> +++ b/system/dirtylimit-hmp-cmds.c
> @@ -17,7 +17,6 @@
>  
>  void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      int64_t cpu_index = qdict_get_try_int(qdict, "cpu_index", -1);
>      Error *err = NULL;
>  
> @@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>  
> -    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query "
> -                   "dirty limit for virtual CPU]\n");
> +    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to query "
> +                       "dirty limit for virtual CPU]\n");
>  }
>  
>  void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> @@ -50,13 +49,12 @@ out:
>  
>  void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      DirtyLimitInfoList *info;
>      g_autoptr(DirtyLimitInfoList) head = NULL;
>      Error *err = NULL;
>  
>      if (!dirtylimit_in_service()) {
> -        monitor_printf(mon, "Dirty page limit not enabled!\n");
> +        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
>          return;
>      }
>  
> @@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
>      }
>  
>      for (info = head; info != NULL; info = info->next) {
> -        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
> +        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
>                              " current rate %"PRIi64 " (MB/s)\n",
>                              info->value->cpu_index,
>                              info->value->limit_rate,
> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> index 5c2de2f53cc9..3860ada2a237 100644
> --- a/system/qdev-monitor.c
> +++ b/system/qdev-monitor.c
> @@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
>      return ret;
>  }
>  
> -#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ## __VA_ARGS__)
> +#define qdev_printf(fmt, ...) \
> +    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
>  
> -static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
> +static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
>                               int indent)
>  {
>      for (int i = 0, n = dc->props_count_; i < n; ++i) {
> @@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int ind
>      }
>  }
>  
> -static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
> +static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
>  {
> +    Monitor *mon = MONITOR(hmp);
>      ObjectClass *class;
>      NamedGPIOList *ngl;
>      NamedClockList *ncl;
> @@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
>      }
>      class = object_get_class(OBJECT(dev));
>      do {
> -        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
> +        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
>          class = object_class_get_parent(class);
>      } while (class != object_class_by_name(TYPE_DEVICE));
>      bus_print_dev(dev->parent_bus, mon, dev, indent);
>  }
>  
> -static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
> +static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)
>  {
>      BusChild *kid;
>  
> @@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
>          qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
>                      dev->id ? dev->id : "");
>          if (details) {
> -            qdev_print(mon, dev, indent + 2);
> +            qdev_print(hmp, dev, indent + 2);
>          }
>          QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
> -            qbus_print(mon, child_bus, indent + 2, details);
> +            qbus_print(hmp, child_bus, indent + 2, details);
>          }
>      }
>  }
> @@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
>  
>  void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      bool details = !qdict_get_try_bool(qdict, "brief", false);
>  
>      if (sysbus_get_default()) {
> -        qbus_print(mon, sysbus_get_default(), 0, details);
> +        qbus_print(hmp, sysbus_get_default(), 0, details);
>      }
>  }
>  
> diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
> index 051ee45ee74c..ad70b53f8abf 100644
> --- a/system/runstate-hmp-cmds.c
> +++ b/system/runstate-hmp-cmds.c
> @@ -25,33 +25,31 @@
>  
>  void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      StatusInfo *info;
>  
>      info = qmp_query_status(NULL);
>  
> -    monitor_printf(mon, "VM status: %s",
> -                   info->running ? "running" : "paused");
> +    monitor_hmp_printf(hmp, "VM status: %s",
> +                       info->running ? "running" : "paused");
>  
>      if (!info->running && info->status != RUN_STATE_PAUSED) {
> -        monitor_printf(mon, " (%s)", RunState_str(info->status));
> +        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
>      }
>  
> -    monitor_printf(mon, "\n");
> +    monitor_hmp_printf(hmp, "\n");
>  
>      qapi_free_StatusInfo(info);
>  }
>  
>  void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *option = qdict_get_try_str(qdict, "option");
>      AccelState *accel = current_accel();
>      bool newval;
>  
>      if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
> -        monitor_printf(mon,
> -                       "This accelerator does not support setting one-insn-per-tb\n");
> +        monitor_hmp_printf(hmp,
> +                           "This accelerator does not support setting one-insn-per-tb\n");
>          return;
>      }
>  
> @@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
>      } else if (!strcmp(option, "off")) {
>          newval = false;
>      } else {
> -        monitor_printf(mon, "unexpected option %s\n", option);
> +        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
>          return;
>      }
>      /* If the property exists then setting it can never fail */
> diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
> index 094c3f16cf50..35406e24d2c3 100644
> --- a/system/tpm-hmp-cmds.c
> +++ b/system/tpm-hmp-cmds.c
> @@ -13,7 +13,6 @@
>  
>  void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>  #ifdef CONFIG_TPM
>      TPMInfoList *info_list, *info;
>      Error *err = NULL;
> @@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
>  
>      info_list = qmp_query_tpm(&err);
>      if (err) {
> -        monitor_printf(mon, "TPM device not supported\n");
> +        monitor_hmp_printf(hmp, "TPM device not supported\n");
>          error_free(err);
>          return;
>      }
>  
>      if (info_list) {
> -        monitor_printf(mon, "TPM device:\n");
> +        monitor_hmp_printf(hmp, "TPM device:\n");
>      }
>  
>      for (info = info_list; info; info = info->next) {
>          TPMInfo *ti = info->value;
> -        monitor_printf(mon, " tpm%d: model=%s\n",
> -                       c, TpmModel_str(ti->model));
> +        monitor_hmp_printf(hmp, " tpm%d: model=%s\n",
> +                           c, TpmModel_str(ti->model));
>  
> -        monitor_printf(mon, "  \\ %s: type=%s",
> -                       ti->id, TpmType_str(ti->options->type));
> +        monitor_hmp_printf(hmp, "  \\ %s: type=%s",
> +                           ti->id, TpmType_str(ti->options->type));
>  
>          switch (ti->options->type) {
>          case TPM_TYPE_PASSTHROUGH:
>              tpo = ti->options->u.passthrough.data;
> -            monitor_printf(mon, "%s%s%s%s",
> -                           tpo->path ? ",path=" : "",
> -                           tpo->path ?: "",
> -                           tpo->cancel_path ? ",cancel-path=" : "",
> -                           tpo->cancel_path ?: "");
> +            monitor_hmp_printf(hmp, "%s%s%s%s",
> +                               tpo->path ? ",path=" : "",
> +                               tpo->path ?: "",
> +                               tpo->cancel_path ? ",cancel-path=" : "",
> +                               tpo->cancel_path ?: "");
>              break;
>          case TPM_TYPE_EMULATOR:
>              teo = ti->options->u.emulator.data;
> -            monitor_printf(mon, ",chardev=%s", teo->chardev);
> +            monitor_hmp_printf(hmp, ",chardev=%s", teo->chardev);
>              break;
>          case TPM_TYPE__MAX:
>              break;
>          }
> -        monitor_printf(mon, "\n");
> +        monitor_hmp_printf(hmp, "\n");
>          c++;
>      }
>      qapi_free_TPMInfoList(info_list);
>  #else
> -    monitor_printf(mon, "TPM device not supported\n");
> +    monitor_hmp_printf(hmp, "TPM device not supported\n");
>  #endif /* CONFIG_TPM */
>  }
> diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
> index 3ae20f004b64..5d69ece15034 100644
> --- a/target/i386/cpu-apic.c
> +++ b/target/i386/cpu-apic.c
> @@ -82,7 +82,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
>  
>  void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUState *cs;
>  
>      if (qdict_haskey(qdict, "apic-id")) {
> @@ -98,7 +97,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
>  
>  
>      if (!cs) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>      x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
> diff --git a/target/i386/monitor.c b/target/i386/monitor.c
> index 72bcab131f77..46762540ba65 100644
> --- a/target/i386/monitor.c
> +++ b/target/i386/monitor.c
> @@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
>      return addr;
>  }
>  
> -static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
> +static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
>                        hwaddr pte, hwaddr mask)
>  {
>      addr = addr_canonical(env, addr);
>  
> -    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
> -                   " %c%c%c%c%c%c%c%c%c\n",
> -                   addr,
> -                   pte & mask,
> -                   pte & PG_NX_MASK ? 'X' : '-',
> -                   pte & PG_GLOBAL_MASK ? 'G' : '-',
> -                   pte & PG_PSE_MASK ? 'P' : '-',
> -                   pte & PG_DIRTY_MASK ? 'D' : '-',
> -                   pte & PG_ACCESSED_MASK ? 'A' : '-',
> -                   pte & PG_PCD_MASK ? 'C' : '-',
> -                   pte & PG_PWT_MASK ? 'T' : '-',
> -                   pte & PG_USER_MASK ? 'U' : '-',
> -                   pte & PG_RW_MASK ? 'W' : '-');
> +    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
> +                       " %c%c%c%c%c%c%c%c%c\n",
> +                       addr,
> +                       pte & mask,
> +                       pte & PG_NX_MASK ? 'X' : '-',
> +                       pte & PG_GLOBAL_MASK ? 'G' : '-',
> +                       pte & PG_PSE_MASK ? 'P' : '-',
> +                       pte & PG_DIRTY_MASK ? 'D' : '-',
> +                       pte & PG_ACCESSED_MASK ? 'A' : '-',
> +                       pte & PG_PCD_MASK ? 'C' : '-',
> +                       pte & PG_PWT_MASK ? 'T' : '-',
> +                       pte & PG_USER_MASK ? 'U' : '-',
> +                       pte & PG_RW_MASK ? 'W' : '-');
>  }
>  
> -static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      unsigned int l1, l2;
> @@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>          if (pde & PG_PRESENT_MASK) {
>              if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
>                  /* 4M pages */
> -                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
> +                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1));
>              } else {
>                  for(l2 = 0; l2 < 1024; l2++) {
>                      pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
>                                                 attrs, NULL);
>                      if (pte & PG_PRESENT_MASK) {
> -                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
> +                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
>                                    pte & ~PG_PSE_MASK,
>                                    ~0xfff);
>                      }
> @@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>      }
>  }
>  
> -static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      unsigned int l1, l2, l3;
> @@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                  if (pde & PG_PRESENT_MASK) {
>                      if (pde & PG_PSE_MASK) {
>                          /* 2M pages with PAE, CR4.PSE is ignored */
> -                        print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
> +                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), pde,
>                                    ~((hwaddr)(1 << 20) - 1));
>                      } else {
>                          pt_addr = pde & 0x3fffffffff000ULL;
> @@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                              pte = address_space_ldq_le(as, pt_addr + l3 * 8,
>                                                         attrs, NULL);
>                              if (pte & PG_PRESENT_MASK) {
> -                                print_pte(mon, env, (l1 << 30) + (l2 << 21)
> +                                print_pte(hmp, env, (l1 << 30) + (l2 << 21)
>                                            + (l3 << 12),
>                                            pte & ~PG_PSE_MASK,
>                                            ~(hwaddr)0xfff);
> @@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>  }
>  
>  #ifdef TARGET_X86_64
> -static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
> +static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as,
>          uint64_t l0, uint64_t pml4_addr)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> @@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
>  
>              if (pdpe & PG_PSE_MASK) {
>                  /* 1G pages, CR4.PSE is ignored */
> -                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
> +                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
>                          pdpe, 0x3ffffc0000000ULL);
>                  continue;
>              }
> @@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
>  
>                  if (pde & PG_PSE_MASK) {
>                      /* 2M pages, CR4.PSE is ignored */
> -                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
> +                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
>                              (l3 << 21), pde, 0x3ffffffe00000ULL);
>                      continue;
>                  }
> @@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
>                      pte = address_space_ldq_le(as, pt_addr + l4 * 8,
>                                                 attrs, NULL);
>                      if (pte & PG_PRESENT_MASK) {
> -                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
> +                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
>                                  (l2 << 30) + (l3 << 21) + (l4 << 12),
>                                  pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
>                      }
> @@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
>      }
>  }
>  
> -static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      uint64_t l0;
> @@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>      for (l0 = 0; l0 < 512; l0++) {
>          pml5e = address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, NULL);
>          if (pml5e & PG_PRESENT_MASK) {
> -            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL);
> +            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL);
>          }
>      }
>  }
> @@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>  
>  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env;
>      AddressSpace *as;
>  
>      env = monitor_hmp_get_cpu_env(hmp);
>      if (!env) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>  
>      if (!(env->cr[0] & CR0_PG_MASK)) {
> -        monitor_printf(mon, "PG disabled\n");
> +        monitor_hmp_printf(hmp, "PG disabled\n");
>          return;
>      }
>      as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
> @@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  #ifdef TARGET_X86_64
>          if (env->hflags & HF_LMA_MASK) {
>              if (env->cr[4] & CR4_LA57_MASK) {
> -                tlb_info_la57(mon, env, as);
> +                tlb_info_la57(hmp, env, as);
>              } else {
> -                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
> +                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
>              }
>          } else
>  #endif
>          {
> -            tlb_info_pae32(mon, env, as);
> +            tlb_info_pae32(hmp, env, as);
>          }
>      } else {
> -        tlb_info_32(mon, env, as);
> +        tlb_info_32(hmp, env, as);
>      }
>  }
>  
> -static void mem_print(Monitor *mon, CPUArchState *env,
> +static void mem_print(MonitorHMP *hmp, CPUArchState *env,
>                        hwaddr *pstart, int *plast_prot,
>                        hwaddr end, int prot)
>  {
> @@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState *env,
>      prot1 = *plast_prot;
>      if (prot != prot1) {
>          if (*pstart != -1) {
> -            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
> -                           HWADDR_FMT_plx " %c%c%c\n",
> -                           addr_canonical(env, *pstart),
> -                           addr_canonical(env, end),
> -                           addr_canonical(env, end - *pstart),
> -                           prot1 & PG_USER_MASK ? 'u' : '-',
> -                           'r',
> -                           prot1 & PG_RW_MASK ? 'w' : '-');
> +            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
> +                               HWADDR_FMT_plx " %c%c%c\n",
> +                               addr_canonical(env, *pstart),
> +                               addr_canonical(env, end),
> +                               addr_canonical(env, end - *pstart),
> +                               prot1 & PG_USER_MASK ? 'u' : '-',
> +                               'r',
> +                               prot1 & PG_RW_MASK ? 'w' : '-');
>          }
>          if (prot != 0)
>              *pstart = end;
> @@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *env,
>      }
>  }
>  
> -static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      unsigned int l1, l2;
> @@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>          if (pde & PG_PRESENT_MASK) {
>              if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
>                  prot = pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
> -                mem_print(mon, env, &start, &last_prot, end, prot);
> +                mem_print(hmp, env, &start, &last_prot, end, prot);
>              } else {
>                  for(l2 = 0; l2 < 1024; l2++) {
>                      pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
> @@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                      } else {
>                          prot = 0;
>                      }
> -                    mem_print(mon, env, &start, &last_prot, end, prot);
> +                    mem_print(hmp, env, &start, &last_prot, end, prot);
>                  }
>              }
>          } else {
>              prot = 0;
> -            mem_print(mon, env, &start, &last_prot, end, prot);
> +            mem_print(hmp, env, &start, &last_prot, end, prot);
>          }
>      }
>      /* Flush last range */
> -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
>  }
>  
> -static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      unsigned int l1, l2, l3;
> @@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                      if (pde & PG_PSE_MASK) {
>                          prot = pde & (PG_USER_MASK | PG_RW_MASK |
>                                        PG_PRESENT_MASK);
> -                        mem_print(mon, env, &start, &last_prot, end, prot);
> +                        mem_print(hmp, env, &start, &last_prot, end, prot);
>                      } else {
>                          pt_addr = pde & 0x3fffffffff000ULL;
>                          for (l3 = 0; l3 < 512; l3++) {
> @@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                              } else {
>                                  prot = 0;
>                              }
> -                            mem_print(mon, env, &start, &last_prot, end, prot);
> +                            mem_print(hmp, env, &start, &last_prot, end, prot);
>                          }
>                      }
>                  } else {
>                      prot = 0;
> -                    mem_print(mon, env, &start, &last_prot, end, prot);
> +                    mem_print(hmp, env, &start, &last_prot, end, prot);
>                  }
>              }
>          } else {
>              prot = 0;
> -            mem_print(mon, env, &start, &last_prot, end, prot);
> +            mem_print(hmp, env, &start, &last_prot, end, prot);
>          }
>      }
>      /* Flush last range */
> -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
>  }
>  
>  
>  #ifdef TARGET_X86_64
> -static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      int prot, last_prot;
> @@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                          prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
>                                         PG_PRESENT_MASK);
>                          prot &= pml4e;
> -                        mem_print(mon, env, &start, &last_prot, end, prot);
> +                        mem_print(hmp, env, &start, &last_prot, end, prot);
>                      } else {
>                          pd_addr = pdpe & 0x3fffffffff000ULL;
>                          for (l3 = 0; l3 < 512; l3++) {
> @@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                                      prot = pde & (PG_USER_MASK | PG_RW_MASK |
>                                                    PG_PRESENT_MASK);
>                                      prot &= pml4e & pdpe;
> -                                    mem_print(mon, env, &start,
> +                                    mem_print(hmp, env, &start,
>                                                &last_prot, end, prot);
>                                  } else {
>                                      pt_addr = pde & 0x3fffffffff000ULL;
> @@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                                          } else {
>                                              prot = 0;
>                                          }
> -                                        mem_print(mon, env, &start,
> +                                        mem_print(hmp, env, &start,
>                                                    &last_prot, end, prot);
>                                      }
>                                  }
>                              } else {
>                                  prot = 0;
> -                                mem_print(mon, env, &start,
> +                                mem_print(hmp, env, &start,
>                                            &last_prot, end, prot);
>                              }
>                          }
>                      }
>                  } else {
>                      prot = 0;
> -                    mem_print(mon, env, &start, &last_prot, end, prot);
> +                    mem_print(hmp, env, &start, &last_prot, end, prot);
>                  }
>              }
>          } else {
>              prot = 0;
> -            mem_print(mon, env, &start, &last_prot, end, prot);
> +            mem_print(hmp, env, &start, &last_prot, end, prot);
>          }
>      }
>      /* Flush last range */
> -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
> +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
>  }
>  
> -static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> +static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
>  {
>      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
>      int prot, last_prot;
> @@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>          end = l0 << 48;
>          if (!(pml5e & PG_PRESENT_MASK)) {
>              prot = 0;
> -            mem_print(mon, env, &start, &last_prot, end, prot);
> +            mem_print(hmp, env, &start, &last_prot, end, prot);
>              continue;
>          }
>  
> @@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>              end = (l0 << 48) + (l1 << 39);
>              if (!(pml4e & PG_PRESENT_MASK)) {
>                  prot = 0;
> -                mem_print(mon, env, &start, &last_prot, end, prot);
> +                mem_print(hmp, env, &start, &last_prot, end, prot);
>                  continue;
>              }
>  
> @@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                  end = (l0 << 48) + (l1 << 39) + (l2 << 30);
>                  if (pdpe & PG_PRESENT_MASK) {
>                      prot = 0;
> -                    mem_print(mon, env, &start, &last_prot, end, prot);
> +                    mem_print(hmp, env, &start, &last_prot, end, prot);
>                      continue;
>                  }
>  
> @@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                      prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
>                              PG_PRESENT_MASK);
>                      prot &= pml5e & pml4e;
> -                    mem_print(mon, env, &start, &last_prot, end, prot);
> +                    mem_print(hmp, env, &start, &last_prot, end, prot);
>                      continue;
>                  }
>  
> @@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                      end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
>                      if (pde & PG_PRESENT_MASK) {
>                          prot = 0;
> -                        mem_print(mon, env, &start, &last_prot, end, prot);
> +                        mem_print(hmp, env, &start, &last_prot, end, prot);
>                          continue;
>                      }
>  
> @@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                          prot = pde & (PG_USER_MASK | PG_RW_MASK |
>                                  PG_PRESENT_MASK);
>                          prot &= pml5e & pml4e & pdpe;
> -                        mem_print(mon, env, &start, &last_prot, end, prot);
> +                        mem_print(hmp, env, &start, &last_prot, end, prot);
>                          continue;
>                      }
>  
> @@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
>                          } else {
>                              prot = 0;
>                          }
> -                        mem_print(mon, env, &start, &last_prot, end, prot);
> +                        mem_print(hmp, env, &start, &last_prot, end, prot);
>                      }
>                  }
>              }
>          }
>      }
>      /* Flush last range */
> -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
> +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
>  }
>  #endif /* TARGET_X86_64 */
>  
>  void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env;
>      AddressSpace *as;
>  
>      env = monitor_hmp_get_cpu_env(hmp);
>      if (!env) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>  
>      if (!(env->cr[0] & CR0_PG_MASK)) {
> -        monitor_printf(mon, "PG disabled\n");
> +        monitor_hmp_printf(hmp, "PG disabled\n");
>          return;
>      }
>      as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
> @@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
>  #ifdef TARGET_X86_64
>          if (env->hflags & HF_LMA_MASK) {
>              if (env->cr[4] & CR4_LA57_MASK) {
> -                mem_info_la57(mon, env, as);
> +                mem_info_la57(hmp, env, as);
>              } else {
> -                mem_info_la48(mon, env, as);
> +                mem_info_la48(hmp, env, as);
>              }
>          } else
>  #endif
>          {
> -            mem_info_pae32(mon, env, as);
> +            mem_info_pae32(hmp, env, as);
>          }
>      } else {
> -        mem_info_32(mon, env, as);
> +        mem_info_32(hmp, env, as);
>      }
>  }
>  
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 4473d02981ff..36a62e58be95 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -756,33 +756,32 @@ SevInfo *qmp_query_sev(Error **errp)
>  
>  void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      SevInfo *info = sev_get_info();
>  
>      if (!info || !info->enabled) {
> -        monitor_printf(mon, "SEV is not enabled\n");
> +        monitor_hmp_printf(hmp, "SEV is not enabled\n");
>          goto out;
>      }
>  
> -    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
> -    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
> -    monitor_printf(mon, "build: %d\n", info->build_id);
> -    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
> -                   info->api_minor);
> +    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->sev_type));
> +    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
> +    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
> +    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
> +                       info->api_minor);
>  
>      if (sev_snp_enabled()) {
> -        monitor_printf(mon, "debug: %s\n",
> -                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
> -                                                                       : "off");
> -        monitor_printf(mon, "SMT allowed: %s\n",
> -                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
> -                                                                       : "off");
> +        monitor_hmp_printf(hmp, "debug: %s\n",
> +                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
> +                                                                           : "off");
> +        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
> +                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
> +                                                                           : "off");
>      } else {
> -        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
> -        monitor_printf(mon, "debug: %s\n",
> -                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
> -        monitor_printf(mon, "key-sharing: %s\n",
> -                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
> +        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
> +        monitor_hmp_printf(hmp, "debug: %s\n",
> +                           info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
> +        monitor_hmp_printf(hmp, "key-sharing: %s\n",
> +                           info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
>      }
>  
>  out:
> diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
> index 5645a5d4d4f5..23c25283b27a 100644
> --- a/target/m68k/monitor.c
> +++ b/target/m68k/monitor.c
> @@ -12,11 +12,10 @@
>  
>  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
>  
>      if (!env1) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>  
> diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
> index 5769829bdd7e..6e8a075f5a41 100644
> --- a/target/ppc/monitor.c
> +++ b/target/ppc/monitor.c
> @@ -13,11 +13,10 @@
>  
>  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
>  
>      if (!env1) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>      dump_mmu(env1);
> diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
> index 4c9c0c793b36..59cc04b3d0fb 100644
> --- a/target/riscv/monitor.c
> +++ b/target/riscv/monitor.c
> @@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, target_ulong addr)
>      return addr;
>  }
>  
> -static void print_pte_header(Monitor *mon)
> +static void print_pte_header(MonitorHMP *hmp)
>  {
> -    monitor_printf(mon, PTE_HEADER_FIELDS);
> -    monitor_printf(mon, PTE_HEADER_DELIMITER);
> +    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
> +    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
>  }
>  
> -static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
> +static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr,
>                        hwaddr paddr, target_ulong size, int attr)
>  {
>      /* sanity check on vaddr */
> @@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
>          return;
>      }
>  
> -    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
> -                   " %c%c%c%c%c%c%c\n",
> -                   addr_canonical(va_bits, vaddr),
> -                   paddr, size,
> -                   attr & PTE_R ? 'r' : '-',
> -                   attr & PTE_W ? 'w' : '-',
> -                   attr & PTE_X ? 'x' : '-',
> -                   attr & PTE_U ? 'u' : '-',
> -                   attr & PTE_G ? 'g' : '-',
> -                   attr & PTE_A ? 'a' : '-',
> -                   attr & PTE_D ? 'd' : '-');
> +    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
> +                       " %c%c%c%c%c%c%c\n",
> +                       addr_canonical(va_bits, vaddr),
> +                       paddr, size,
> +                       attr & PTE_R ? 'r' : '-',
> +                       attr & PTE_W ? 'w' : '-',
> +                       attr & PTE_X ? 'x' : '-',
> +                       attr & PTE_U ? 'u' : '-',
> +                       attr & PTE_G ? 'g' : '-',
> +                       attr & PTE_A ? 'a' : '-',
> +                       attr & PTE_D ? 'd' : '-');
>  }
>  
> -static void walk_pte(Monitor *mon, AddressSpace *as,
> +static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
>                       hwaddr base, target_ulong start,
>                       int level, int ptidxbits, int ptesize, int va_bits,
>                       target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
> @@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
>                  if ((*last_attr != attr) ||
>                      (*last_paddr + *last_size != paddr) ||
>                      (last_start + *last_size != start)) {
> -                    print_pte(mon, va_bits, *vbase, *pbase,
> +                    print_pte(hmp, va_bits, *vbase, *pbase,
>                                *last_paddr + *last_size - *pbase, *last_attr);
>  
>                      *vbase = start;
> @@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
>                  *last_size = pgsize;
>              } else {
>                  /* pointer to the next level of the page table */
> -                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, ptesize,
> +                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, ptesize,
>                           va_bits, vbase, pbase, last_paddr,
>                           last_size, last_attr);
>              }
> @@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
>  
>  }
>  
> -static void mem_info_svxx(Monitor *mon, CPUArchState *env)
> +static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
>  {
>      AddressSpace *as = env_cpu(env)->as;
>      int levels, ptidxbits, ptesize, vm, va_bits;
> @@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
>      va_bits = PGSHIFT + levels * ptidxbits;
>  
>      /* print header */
> -    print_pte_header(mon);
> +    print_pte_header(hmp);
>  
>      vbase = -1;
>      pbase = -1;
> @@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
>      last_attr = 0;
>  
>      /* walk page tables, starting from address 0 */
> -    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
> +    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
>               &vbase, &pbase, &last_paddr, &last_size, &last_attr);
>  
>      /* don't forget the last one */
> -    print_pte(mon, va_bits, vbase, pbase,
> +    print_pte(hmp, va_bits, vbase, pbase,
>                last_paddr + last_size - pbase, last_attr);
>  }
>  
>  void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env;
>  
>      env = monitor_hmp_get_cpu_env(hmp);
>      if (!env) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>  
>      if (!riscv_cpu_cfg(env)->mmu) {
> -        monitor_printf(mon, "S-mode MMU unavailable\n");
> +        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
>          return;
>      }
>  
>      if (riscv_cpu_mxl(env) == MXL_RV32) {
>          if (!(env->satp & SATP32_MODE)) {
> -            monitor_printf(mon, "No translation or protection\n");
> +            monitor_hmp_printf(hmp, "No translation or protection\n");
>              return;
>          }
>      } else {
>          if (!(env->satp & SATP64_MODE)) {
> -            monitor_printf(mon, "No translation or protection\n");
> +            monitor_hmp_printf(hmp, "No translation or protection\n");
>              return;
>          }
>      }
>  
> -    mem_info_svxx(mon, env);
> +    mem_info_svxx(hmp, env);
>  }
>  
>  #ifdef CONFIG_TCG
> diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
> index 4e443152bf56..62998a9a57cb 100644
> --- a/target/sh4/monitor.c
> +++ b/target/sh4/monitor.c
> @@ -26,33 +26,32 @@
>  #include "monitor/monitor.h"
>  #include "monitor/hmp.h"
>  
> -static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
> +static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
>  {
> -    monitor_printf(mon, " tlb%i:\t"
> -                   "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
> -                   "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
> -                   "dirty=%hhu writethrough=%hhu\n",
> -                   idx,
> -                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
> -                   tlb->v, tlb->sh, tlb->c, tlb->pr,
> -                   tlb->d, tlb->wt);
> +    monitor_hmp_printf(hmp, " tlb%i:\t"
> +                       "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
> +                       "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
> +                       "dirty=%hhu writethrough=%hhu\n",
> +                       idx,
> +                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
> +                       tlb->v, tlb->sh, tlb->c, tlb->pr,
> +                       tlb->d, tlb->wt);
>  }
>  
>  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env = monitor_hmp_get_cpu_env(hmp);
>      int i;
>  
>      if (!env) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>  
> -    monitor_printf (mon, "ITLB:\n");
> +    monitor_hmp_printf(hmp, "ITLB:\n");
>      for (i = 0 ; i < ITLB_SIZE ; i++)
> -        print_tlb (mon, i, &env->itlb[i]);
> -    monitor_printf (mon, "UTLB:\n");
> +        print_tlb(hmp, i, &env->itlb[i]);
> +    monitor_hmp_printf(hmp, "UTLB:\n");
>      for (i = 0 ; i < UTLB_SIZE ; i++)
> -        print_tlb (mon, i, &env->utlb[i]);
> +        print_tlb(hmp, i, &env->utlb[i]);
>  }
> diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
> index e826e584a918..36f109cbb568 100644
> --- a/target/sparc/monitor.c
> +++ b/target/sparc/monitor.c
> @@ -29,11 +29,10 @@
>  
>  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
>  
>      if (!env1) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>      dump_mmu(env1);
> diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
> index b7b7387706f3..b9c4089b0fb1 100644
> --- a/target/xtensa/monitor.c
> +++ b/target/xtensa/monitor.c
> @@ -28,11 +28,10 @@
>  
>  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
>  
>      if (!env1) {
> -        monitor_printf(mon, "No CPU available\n");
> +        monitor_hmp_printf(hmp, "No CPU available\n");
>          return;
>      }
>      dump_mmu(env1);
> diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
> index b2a884529598..530a3fee3c13 100644
> --- a/tests/unit/test-util-sockets.c
> +++ b/tests/unit/test-util-sockets.c
> @@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
>   */
>  Monitor *monitor_cur(void) { return cur_mon; }
>  Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
> -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort(); }
> +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) { abort(); }
>  
>  #ifndef _WIN32
>  static void test_socket_fd_pass_name_good(void)
> diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
> index f62b2f294952..81a09ec5adfa 100644
> --- a/tools/qemu-vnc/clipboard.c
> +++ b/tools/qemu-vnc/clipboard.c
> @@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboardRequest *req)
>          "Cancelled clipboard request");
>  
>      g_clear_object(&req->invocation);
> -    g_clear_handle_id(&req->timeout_id, g_source_remove);;
> +    g_clear_handle_id(&req->timeout_id, g_source_remove);
>  }
>  
>  static gboolean
> @@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *info)
>          vnc_dbus_clipboard_complete_request(
>              req->invocation, info, req->type);
>          g_clear_object(&req->invocation);
> -        g_clear_handle_id(&req->timeout_id, g_source_remove);;
> +        g_clear_handle_id(&req->timeout_id, g_source_remove);
>          return;
>      }
>  
> diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
> index 26597fefaa99..0aa50a901d37 100644
> --- a/tools/qemu-vnc/stubs.c
> +++ b/tools/qemu-vnc/stubs.c
> @@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
>      return NULL;
>  }
>  
> -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
>  {
>      return -1;
>  }
> diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
> index 5a8158f4f4b6..a68f5b900d7c 100644
> --- a/trace/trace-hmp-cmds.c
> +++ b/trace/trace-hmp-cmds.c
> @@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qdict)
>  #ifdef CONFIG_TRACE_SIMPLE
>  void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *op = qdict_get_try_str(qdict, "op");
>      const char *arg = qdict_get_try_str(qdict, "arg");
>  
> @@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
>              st_set_trace_file(arg);
>          }
>      } else {
> -        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
> -        hmp_help_cmd(mon, "trace-file");
> +        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
> +        hmp_help_cmd(hmp, "trace-file");
>      }
>  }
>  #endif
>  
>  void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *name = qdict_get_try_str(qdict, "name");
>      TraceEventInfoList *events;
>      TraceEventInfoList *elem;
> @@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
>      }
>  
>      for (elem = events; elem != NULL; elem = elem->next) {
> -        monitor_printf(mon, "%s : state %u\n",
> -                       elem->value->name,
> -                       elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
> +        monitor_hmp_printf(hmp, "%s : state %u\n",
> +                           elem->value->name,
> +                           elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
>      }
>      qapi_free_TraceEventInfoList(events);
>  }
> diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
> index 186209fd0234..f611dd7ee457 100644
> --- a/ui/ui-hmp-cmds.c
> +++ b/ui/ui-hmp-cmds.c
> @@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qdict)
>  
>  void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      MouseInfoList *mice_list, *mouse;
>  
>      mice_list = qmp_query_mice(NULL);
>      if (!mice_list) {
> -        monitor_printf(mon, "No mouse devices connected\n");
> +        monitor_hmp_printf(hmp, "No mouse devices connected\n");
>          return;
>      }
>  
>      for (mouse = mice_list; mouse; mouse = mouse->next) {
> -        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
> -                       mouse->value->current ? '*' : ' ',
> -                       mouse->value->index, mouse->value->name,
> -                       mouse->value->absolute ? " (absolute)" : "");
> +        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
> +                           mouse->value->current ? '*' : ' ',
> +                           mouse->value->index, mouse->value->name,
> +                           mouse->value->absolute ? " (absolute)" : "");
>      }
>  
>      qapi_free_MouseInfoList(mice_list);
> @@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
>  
>  #ifdef CONFIG_VNC
>  /* Helper for hmp_info_vnc_clients, _servers */
> -static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
> +static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
>                                    const char *name)
>  {
> -    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
> -                   name,
> -                   info->host,
> -                   info->service,
> -                   NetworkAddressFamily_str(info->family),
> -                   info->websocket ? " (Websocket)" : "");
> +    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
> +                       name,
> +                       info->host,
> +                       info->service,
> +                       NetworkAddressFamily_str(info->family),
> +                       info->websocket ? " (Websocket)" : "");
>  }
>  
>  /* Helper displaying and auth and crypt info */
> -static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
> +static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent,
>                                     VncPrimaryAuth auth,
>                                     VncVencryptSubAuth *vencrypt)
>  {
> -    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
> -                   VncPrimaryAuth_str(auth),
> -                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
> +    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
> +                       VncPrimaryAuth_str(auth),
> +                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
>  }
>  
> -static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *client)
> +static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *client)
>  {
>      while (client) {
>          VncClientInfo *cinfo = client->value;
>  
> -        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Client");
> -        monitor_printf(mon, "    x509_dname: %s\n",
> -                       cinfo->x509_dname ?: "none");
> -        monitor_printf(mon, "    sasl_username: %s\n",
> -                       cinfo->sasl_username ?: "none");
> +        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Client");
> +        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
> +                           cinfo->x509_dname ?: "none");
> +        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
> +                           cinfo->sasl_username ?: "none");
>  
>          client = client->next;
>      }
>  }
>  
> -static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
> +static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *server)
>  {
>      while (server) {
>          VncServerInfo2 *sinfo = server->value;
> -        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "Server");
> -        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
> +        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "Server");
> +        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
>                                 sinfo->has_vencrypt ? &sinfo->vencrypt : NULL);
>          server = server->next;
>      }
> @@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
>  
>  void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      VncInfo2List *info2l, *info2l_head;
>      Error *err = NULL;
>  
> @@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
>          return;
>      }
>      if (!info2l) {
> -        monitor_printf(mon, "None\n");
> +        monitor_hmp_printf(hmp, "None\n");
>          return;
>      }
>  
>      while (info2l) {
>          VncInfo2 *info = info2l->value;
> -        monitor_printf(mon, "%s:\n", info->id);
> -        hmp_info_vnc_servers(mon, info->server);
> -        hmp_info_vnc_clients(mon, info->clients);
> +        monitor_hmp_printf(hmp, "%s:\n", info->id);
> +        hmp_info_vnc_servers(hmp, info->server);
> +        hmp_info_vnc_clients(hmp, info->clients);
>          if (!info->server) {
>              /*
>               * The server entry displays its auth, we only need to
>               * display in the case of 'reverse' connections where
>               * there's no server.
>               */
> -            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
> +            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
>                                 info->has_vencrypt ? &info->vencrypt : NULL);
>          }
>          if (info->display) {
> -            monitor_printf(mon, "  Display: %s\n", info->display);
> +            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
>          }
>          info2l = info2l->next;
>      }
> @@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
>  #ifdef CONFIG_SPICE
>  void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      SpiceChannelList *chan;
>      SpiceInfo *info;
>      const char *channel_name;
> @@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
>      info = qmp_query_spice(NULL);
>  
>      if (!info->enabled) {
> -        monitor_printf(mon, "Server: disabled\n");
> +        monitor_hmp_printf(hmp, "Server: disabled\n");
>          goto out;
>      }
>  
> -    monitor_printf(mon, "Server:\n");
> +    monitor_hmp_printf(hmp, "Server:\n");
>      if (info->has_port) {
> -        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
> -                       info->host, info->port);
> +        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
> +                           info->host, info->port);
>      }
>      if (info->has_tls_port) {
> -        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
> -                       info->host, info->tls_port);
> +        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n",
> +                           info->host, info->tls_port);
>      }
> -    monitor_printf(mon, "    migrated: %s\n",
> -                   info->migrated ? "true" : "false");
> -    monitor_printf(mon, "        auth: %s\n", info->auth);
> -    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
> -    monitor_printf(mon, "  mouse-mode: %s\n",
> -                   SpiceQueryMouseMode_str(info->mouse_mode));
> +    monitor_hmp_printf(hmp, "    migrated: %s\n",
> +                       info->migrated ? "true" : "false");
> +    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
> +    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_version);
> +    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
> +                       SpiceQueryMouseMode_str(info->mouse_mode));
>  
>      if (!info->has_channels || info->channels == NULL) {
> -        monitor_printf(mon, "Channels: none\n");
> +        monitor_hmp_printf(hmp, "Channels: none\n");
>      } else {
>          for (chan = info->channels; chan; chan = chan->next) {
> -            monitor_printf(mon, "Channel:\n");
> -            monitor_printf(mon, "     address: %s:%s%s\n",
> -                           chan->value->host, chan->value->port,
> -                           chan->value->tls ? " [tls]" : "");
> -            monitor_printf(mon, "     session: %" PRId64 "\n",
> -                           chan->value->connection_id);
> -            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "\n",
> -                           chan->value->channel_type, chan->value->channel_id);
> +            monitor_hmp_printf(hmp, "Channel:\n");
> +            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
> +                               chan->value->host, chan->value->port,
> +                               chan->value->tls ? " [tls]" : "");
> +            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
> +                               chan->value->connection_id);
> +            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId64 "\n",
> +                               chan->value->channel_type, chan->value->channel_id);
>  
>              channel_name = "unknown";
>              if (chan->value->channel_type > 0 &&
> @@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
>                  channel_name = channel_names[chan->value->channel_type];
>              }
>  
> -            monitor_printf(mon, "     channel name: %s\n", channel_name);
> +            monitor_hmp_printf(hmp, "     channel name: %s\n", channel_name);
>          }
>      }
>  
> @@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
>      monitor_hmp_read_command(opaque, 1);
>  }
>  
> -void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
> +void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
>                      const char *arg, const char *read_only, bool force,
>                      Error **errp)
>  {
> @@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
>          return;
>      }
>      if (!arg) {
> -        MonitorHMP *hmp = MONITOR_HMP(mon);
>          monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
>      } else {
>          qmp_change_vnc_password(arg, errp);
> @@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t key_length)
>  
>  void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
>  {
> -    Monitor *mon = MONITOR(hmp);
>      const char *keys = qdict_get_str(qdict, "keys");
>      KeyValue *v = NULL;
>      KeyValueList *head = NULL, **tail = &head;
> @@ -432,7 +427,7 @@ out:
>      return;
>  
>  err_out:
> -    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
> +    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, keys);
>      goto out;
>  }
>  
> diff --git a/util/error-report.c b/util/error-report.c
> index 70cbd174ffae..c20e157780fa 100644
> --- a/util/error-report.c
> +++ b/util/error-report.c
> @@ -38,7 +38,7 @@ error_vprintf_mon(const char *fmt, va_list ap)
>      MonitorHMP *hmp = monitor_cur_hmp();
>  
>      if (hmp) {
> -        return monitor_vprintf(MONITOR(hmp), fmt, ap);
> +        return monitor_hmp_vprintf(hmp, fmt, ap);
>      }
>  
>      return vfprintf(stderr, fmt, ap);
> diff --git a/util/qemu-print.c b/util/qemu-print.c
> index 0eecc05b0330..aabe670fda01 100644
> --- a/util/qemu-print.c
> +++ b/util/qemu-print.c
> @@ -23,7 +23,7 @@ int qemu_vprintf(const char *fmt, va_list ap)
>  {
>      MonitorHMP *hmp = monitor_cur_hmp();
>      if (hmp) {
> -        return monitor_vprintf(MONITOR(hmp), fmt, ap);
> +        return monitor_hmp_vprintf(hmp, fmt, ap);
>      }
>      return vprintf(fmt, ap);
>  }
> @@ -54,7 +54,7 @@ int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
>  {
>      if (!stream) {
>          MonitorHMP *hmp = monitor_cur_hmp();
> -        return hmp ? monitor_vprintf(MONITOR(hmp), fmt, ap) : -1;
> +        return hmp ? monitor_hmp_vprintf(hmp, fmt, ap) : -1;
>      }
>      return vfprintf(stream, fmt, ap);
>  }
> 
> -- 
> 2.55.0.543.g5ebe2ebe4ea8
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 14:39:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 14:39:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395456.1633821 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhRG-0000HW-7m; Wed, 19 Aug 2026 14:38:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395456.1633821; Wed, 19 Aug 2026 14:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhRG-0000HP-4b; Wed, 19 Aug 2026 14:38:46 +0000
Received: by outflank-mailman (input) for mailman id 1395456;
 Wed, 19 Aug 2026 14:38:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwhRE-0000HI-SN
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:38:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhRD-0060Sp-LC
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 16:38:43 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85bff3-2eae-0a2a0a5409dd-0a2a450bb1a2-0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:38:43 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85bff3-b7e8-0a2a450b0019-d1558033d549-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:38:43 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so9976805e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:38:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9b6ed64sm40026485e9.1.2026.08.19.07.38.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 07:38:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787150323; x=1787755123; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=NjXOyh07FZshHAd+xtDfXNOYHDG5hYOaZotRxQ8Uox0=;
        b=WfnYWpgQEHZ2qjTVqJeGCGRVvOvFVoIOnaUsdxDrwRgc50WoiGrlBnoMS+g+43qOmM
         VGwF//QatGsa/V1UV9lGs086pitiIin1VsauNWMTiN/Bf7ymtm+bVHFnRxD19OGcAQTY
         6DZsUjuKjWTAh4G+irC5zXvYuzf4U16ZY5oNNGmxW1ZbKmezCofCMyHDxDhDpShVB/hs
         ZovWKsOqhgsjIXPcHOpmWOA6WF/IUMoi6tjBf5GohjL6h1DQACESfBNeHiIjhlols1hv
         tnpQsdjLK67LGEMN1l92gZxWQ3vrhmD73Wp2WDsPDFW6VHGrL5V187IqZZzxxYuiBfjw
         hA1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787150323; x=1787755123;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=NjXOyh07FZshHAd+xtDfXNOYHDG5hYOaZotRxQ8Uox0=;
        b=gnu5Io/uAc0kJKYIkyStm1OvONna125XDZmQWyuI8YNiWznQmzTZybw0qsXh73XjNV
         k0WIvVYGhw7WdCUEJ7k1hCVakVr70H9/dWKM1eYARLTTp+pcwWvQsVI0OBQeeoqj42VH
         9kAhP6n6hnIfQIKoE0vU8pAZ83HLXCUutLGeDpxb2CpnPnF90Vv7kGMW73icK2eFJJaf
         pMZ7NAjCKgJbqo994ob8Vv//9AFckwse5m/57ZNBNHT98EHGK3iixRzy87NTZV1CvUNc
         3T5BF1A2evefWESDqEwBATHPWBckrqjwzQD3VNdnVKkNp+v9zgbW8mxvsiNmjlwPEexM
         X2Iw==
X-Forwarded-Encrypted: i=1; AHgh+RpyMKyJbCbOSXhhTNVGG7hAgpEo4g40Xb9c//FsDh0azBK6HuXHs4t4aK2RafMSOA2n+M7i5Aw2uxw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyYaomaul+PyE1QfkS6HoCzkqUWJinuxMjeYF/NA1MkTZ1URPPv
	SqINdKusfZX7BXaAFZLQrHgutgpm5SLUjdH8ehnV4sTp94ZRlxZGje+DAipRphnGIA==
X-Gm-Gg: AR+sD13VDmENcZ4Q6TmCEh79+ymJ81TjCeDGi0mQgzFdMI5JJmqDRBHEcSQGWQhPe5K
	2ICb64vxe+JZk7IBu1dV/6yuTEONhEYAqnlrSV0Vc8xOwz+l9/N6ATF6ZzpsPbXKrl0e0rGbIOG
	UI+67JlzbvmGIHyRvWkNeMTdYmgzd/UB6S5kHcNIELDsxzw5IfVR4Xj08cO0Ew7qpjnvr2+h9n/
	EGSjgqp14+1guEho9zQXB+X2it0R8b/rJn7KksLq0Qoou84ZayAENibfdQnr3xA+tM3R6HYhIjP
	PqiWfGpfKEsz7S4WowSViUgFvMB84mxb+87z5uuBXIeVUSxZKL4y95gDUxLn75phVvJ4GfLLfkd
	EkvQSPRWrd7yi/0Ul//StYQ8L6jnjJz/illlChtf/IqwlHp9bcPk8yVUAndc2ycoBiHIy64xHid
	YUayxS3wH/kawRM9Pi3xmWYarBRb8lHuYjCbKu8+4afhe6aR4K74ruWTJaLJXLJ/zECbyoFMPnS
	C77paHbQkZE7lY3kT0D/5ZtvMxK8VSY0OO0iiJzKwzU1nNrj3sP
X-Received: by 2002:a05:600c:468d:b0:499:4892:d022 with SMTP id 5b1f17b1804b1-499aa17d5a2mr91260655e9.8.1787150322726;
        Wed, 19 Aug 2026 07:38:42 -0700 (PDT)
Message-ID: <a9510f21-b7a8-4323-a64d-0f33e44cd8b0@suse.com>
Date: Wed, 19 Aug 2026 16:38:40 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 8/9] hvm/ioreq: Negotiate extended destination ID
 support per ioreq server
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298081.8631fc262581453bbf619ec5b2062170.19dcf3886cc000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298081.8631fc262581453bbf619ec5b2062170.19dcf3886cc000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787150323-AAAD89EA-02523BE6/0/0
X-purgate-type: clean
X-purgate-size: 11576

On 27.04.2026 15:54, Julian Vetter wrote:
> ---
> Changes in v4:
> - As suggested by Roger, replaced XEN_DMOP_enable_ext_dest_id (v3 patch
>   6), a separate DM op the device model had to call before starting
>   vCPUs, with a flags byte repurposed from the existing pad[3] field of
>   xen_dm_op_create_ioreq_server

IOW the presence of XEN_DMOP_enable_ext_dest_id in the earlier patch is
entirely stale?

> - New XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID flag (bit 0) lets each ioreq
>   server signal support at registration time
> - As suggested by Roger level the feature across all ioreq servers.
>   XEN_HVM_CPUID_EXT_DEST_ID is only advertised when every server
>   registered before arch_domain_creation_finished() sets the flag. A
>   single server without the flag suppresses the feature for the whole
>   domain!
> - Lock the levelled result at domain creation time and enforce it for
>   servers registered afterwards, preventing a late opt-out from breaking
>   guests that already see the feature in CPUID
> - Persist the locked flag via HVM_SAVE_TYPE(EXT_DEST_ID) so that live
>   migration preserves the guest-visible CPUID bit independently of when
>   the device model registers its ioreq servers on the destination host

So a new save record for a single bit. That doesn't look very efficient
to me.

> @@ -1106,7 +1107,16 @@ int arch_domain_soft_reset(struct domain *d)
>  void arch_domain_creation_finished(struct domain *d)
>  {
>      if ( is_hvm_domain(d) )
> +    {
> +        /*
> +         * Lock the extended destination ID state. OR preserves any value
> +         * already restored from an HVM save record (migration path). For a
> +         * fresh domain, ext_dest_id starts false and the dynamic check
> +         * supplies the levelled result across all registered ioreq servers.
> +         */
> +        d->arch.hvm.ext_dest_id |= hvm_ext_dest_id_enabled(d);

For an unaware guest, after migration it'll suddenly get the flag set
if all servers are capable. That can't be right. It looks pretty much
unavoidable for the field to become tristate (unset / false / true).

>          hvm_domain_creation_finished(d);

Blank line please between what you add and what was already there.

> @@ -325,6 +326,42 @@ void arch_ioreq_domain_init(struct domain *d)
>      register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
>  }
>  
> +int arch_ioreq_server_create_check(const struct domain *d, uint8_t flags)

Bogus use of a fixed-width type again.

> +{
> +    if ( !is_hvm_domain(d) || !d->creation_finished )
> +        return 0;

Why the HVM check? ioreq_server_dm_op(), the sole caller, will only ever
be called for HVM domains (as per the check near the top of dm_op()).

> +    if ( d->arch.hvm.ext_dest_id &&
> +         !(flags & XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID) )
> +        return -EPERM;
> +
> +    return 0;
> +}
> +
> +static int cf_check ext_dest_id_save(struct vcpu *v, hvm_domain_context_t *h)
> +{
> +    struct hvm_hw_ext_dest_id s = {
> +        .enabled = v->domain->arch.hvm.ext_dest_id,
> +    };
> +
> +    return hvm_save_entry(EXT_DEST_ID, 0, h, &s);
> +}
> +
> +static int cf_check ext_dest_id_load(struct domain *d, hvm_domain_context_t *h)
> +{
> +    struct hvm_hw_ext_dest_id s;
> +
> +    if ( hvm_load_entry(EXT_DEST_ID, h, &s) )
> +        return -EINVAL;
> +
> +    d->arch.hvm.ext_dest_id = s.enabled;

Afaict this can load arbitrary values other than 0 or 1. In fact ...

> +    return 0;
> +}
> +
> +HVM_REGISTER_SAVE_RESTORE(EXT_DEST_ID, ext_dest_id_save, NULL,
> +                          ext_dest_id_load, 1, HVMSR_PER_DOM);

... I think there's ext_dest_id_check() missing.

> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -24,6 +24,7 @@
>   *  Ported to xen by using virtual IRQ line.
>   */
>  
> +#include <xen/ioreq.h>
>  #include <xen/types.h>
>  #include <xen/mm.h>
>  #include <xen/xmalloc.h>

Is this hunk stale?

> @@ -597,6 +598,7 @@ int vioapic_get_trigger_mode(const struct domain *d, unsigned int gsi)
>  static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h)
>  {
>      const HVM_SAVE_TYPE(IOAPIC) *s;
> +    unsigned int i;

Better ...

> @@ -617,6 +619,24 @@ static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h
>      if ( s->ioregsel > VIOAPIC_REG_RTE0 + (ARRAY_SIZE(s->redirtbl) - 1) * 2 + 1 )
>          return -EINVAL;
>  
> +    /*
> +     * If any RTE uses extended destination ID bits, the EXT_DEST_ID save
> +     * record must have been loaded first (restoring d->arch.hvm.ext_dest_id).
> +     * The ioreq server re-registration by the DM happens later, so use the
> +     * domain-level locked flag rather than the per-server dynamic check.
> +     */
> +    for ( i = 0; i < ARRAY_SIZE(s->redirtbl); i++ )

...

    for ( unsigned int i = 0; i < ARRAY_SIZE(s->redirtbl); i++ )

> +    {
> +        if ( s->redirtbl[i].fields.ext_dest_id && !d->arch.hvm.ext_dest_id )
> +        {
> +            printk(XENLOG_G_ERR "HVM restore: %pd IO-APIC RTE %u has "
> +                                "extended destination ID bits set but "
> +                                "EXT_DEST_ID is not enabled\n",
> +                                d, i);

No, this is the wrong way round. As long as we permit guests to put
non-zero in these bits, we can't demand the bits to be zero here. You
need to avoid interpreting them as extended-ID when the feature isn't
enabled for a guest.

> --- a/xen/common/ioreq.c
> +++ b/xen/common/ioreq.c
> @@ -641,7 +641,7 @@ static void ioreq_server_deinit(struct ioreq_server *s)
>  }
>  
>  static int ioreq_server_create(struct domain *d, int bufioreq_handling,
> -                               ioservid_t *id)
> +                               uint8_t flags, ioservid_t *id)

Inappropriate use of a fixed-width type again.

> @@ -1350,11 +1352,16 @@ int ioreq_server_dm_op(struct xen_dm_op *op, struct domain *d, bool *const_op)
>          *const_op = false;
>  
>          rc = -EINVAL;
> -        if ( data->pad[0] || data->pad[1] || data->pad[2] )
> +        if ( data->flags & ~XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID ||

Parentheses please around bitwise logic being operands to boolean logic.

> +             data->pad[0] || data->pad[1] )
> +            break;
> +
> +        rc = arch_ioreq_server_create_check(d, data->flags);

It's a little odd to have an arch hook here, yet at the same time an
x86-specific check a few lines up (XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID
really is meaningless on non-x86, and should hence either be constrained
to x86 [with the bit position reusable for something else on other
architectures], or be properly rejected on non-x86).

> @@ -455,6 +456,18 @@ int pt_irq_create_bind(
>          uint64_t msi_addr;
>          uint32_t msi_data;
>  
> +        /*
> +         * Refuse the old MSI bind path when extended destination IDs are
> +         * in use. The caller must use XEN_DMOP_bind_pt_msi_irq instead,
> +         * which passes the raw MSI address so Xen can decode the extended
> +         * bits. This old path only carries an 8-bit destination ID and
> +         * would silently misroute interrupts to vCPUs with APIC IDs > 255.

"to" looks ambiguous to me here. Maybe better "targeted at"? It's also >= 255,
I think.

> +         */
> +        if ( hvm_ext_dest_id_enabled(d) )
> +        {
> +            return -EPERM;
> +        }

No need for curly braces here. Further I think -EPERM isn't a good choice, as
that's what xsm_default_action() returns. -EOPNOTSUPP may be an option, or
some other, more "exotic" indicator.

> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -627,12 +627,27 @@ struct hvm_msr {
>  
>  #define CPU_MSR_CODE  20
>  
> +/*
> + * HVM_SAVE_TYPE(EXT_DEST_ID): domain-level extended MSI destination ID state.

Why MSI when the vIO-APIC uses it as well?

> + * Records whether the extended destination ID feature was enabled for this
> + * domain at the time guest vCPUs were started. This allows migration to
> + * preserve the setting across hosts without relying on the device model to
> + * re-register its ioreq servers before the guest's first CPUID query.
> + */

The guest's first CPUID query surely is going to happen after at least one DM
has registered a server? (For HVM, that is. No server may ever be registered
for PVH, aiui.) It's not quite clear to me why this connection to CPUID
queries is being made here. The flag is necessary at server registration time,
as ones not supporting the feature need to be rejected.

> --- a/xen/include/public/hvm/dm_op.h
> +++ b/xen/include/public/hvm/dm_op.h
> @@ -39,18 +39,28 @@ typedef uint16_t ioservid_t;
>   * XEN_DMOP_create_ioreq_server: Instantiate a new IOREQ Server for a
>   *                               secondary emulator.
>   *
> - * The <id> handed back is unique for target domain. The valur of
> + * The <id> handed back is unique for target domain. The value of
>   * <handle_bufioreq> should be one of HVM_IOREQSRV_BUFIOREQ_* defined in
> - * hvm_op.h. If the value is HVM_IOREQSRV_BUFIOREQ_OFF then  the buffered
> + * hvm_op.h. If the value is HVM_IOREQSRV_BUFIOREQ_OFF then the buffered
>   * ioreq ring will not be allocated and hence all emulation requests to
>   * this server will be synchronous.
> + *
> + * If <flags> contains XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID, the server will
> + * use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings, passing
> + * raw MSI address/data fields so Xen can decode extended destination ID
> + * bits. Once any server sets this flag, Xen will advertise
> + * XEN_HVM_CPUID_EXT_DEST_ID to the guest. Must be set before the guest
> + * vCPUs are started.

I don't understand the last sentence. Is it perhaps stale from how things
were earlier? There's nothing to "set" here.

> --- a/xen/include/xen/ioreq.h
> +++ b/xen/include/xen/ioreq.h
> @@ -54,9 +54,35 @@ struct ioreq_server {
>      evtchn_port_t          bufioreq_evtchn;
>      struct rangeset        *range[NR_IO_RANGE_TYPES];
>      bool                   enabled;
> +    bool                   ext_dest_id;
>      uint8_t                bufioreq_handling;
>  };
>  
> +/*
> + * Return true if every registered ioreq server has opted in to extended
> + * destination IDs (XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID) and at least one
> + * server exists.

Why is one server existing relevant?

> A single server without the flag is enough to suppress
> + * XEN_HVM_CPUID_EXT_DEST_ID, preventing misrouted interrupts.
> + */
> +static inline bool hvm_ext_dest_id_enabled(const struct domain *d)
> +{
> +    unsigned int i;
> +    bool found = false;
> +
> +    for ( i = 0; i < MAX_NR_IOREQ_SERVERS; i++ )

Please use ARRAY_SIZE() in such cases.

> +    {
> +        const struct ioreq_server *s = d->ioreq_server.server[i];
> +
> +        if ( !s )
> +            continue;
> +        if ( !s->ext_dest_id )

As there's no locking here, and as the comment ahead of the function also
doesn't mention any locking requirements: What guarantees s to still be
valid to deref here? Furthermore, what guarantees the result of this
function to not be stale by the time the caller looks at it? (Some of
this may be easier if this wasn't an inline function in a globally
visible header.)

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 14:40:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 14:40:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395464.1633830 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhSn-0001lo-HL; Wed, 19 Aug 2026 14:40:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395464.1633830; Wed, 19 Aug 2026 14:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhSn-0001lh-ED; Wed, 19 Aug 2026 14:40:21 +0000
Received: by outflank-mailman (input) for mailman id 1395464;
 Wed, 19 Aug 2026 14:40:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dave.hansen@intel.com>) id 1wwhSl-0001lb-VM
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:40:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhSk-00GtnC-Rk
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 16:40:19 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dave.hansen@intel.com>)
 id 6a85c043-e002-0a2a0a5209dd-0a2a450bc9e8-38
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:40:17 +0200
Received: from [192.198.163.18] (helo=mgamail.intel.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dave.hansen@intel.com>)
 id 6a85c04f-b7e8-0a2a450b0019-c0c6a3127db1-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:40:16 +0200
Received: from fmviesa006.fm.intel.com ([10.60.135.146])
 by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 19 Aug 2026 07:40:14 -0700
Received: from bradocaj-mobl.ger.corp.intel.com (HELO [10.125.111.233])
 ([10.125.111.233])
 by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 19 Aug 2026 07:40:10 -0700
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1787150417; x=1818686417;
  h=message-id:date:mime-version:subject:to:cc:references:
   from:in-reply-to:content-transfer-encoding;
  bh=vymarJZh4YqC2L7NKmpGaLSs+LwWBnjm4Ga1t8pq/Yg=;
  b=Wu27R9UBBX0S8wdkbVXiqLYW8cI6533GUPz7DNSoOv44tx2dvpMd4ktv
   3kTcUXnUaNMIaSnZGjaTopVR4TEW31hUPEPu6MyPxh9JmIaFoF2zQJAQE
   RaPzYGXMekHZ2HHoEj0zIa2IIaaCWav/U2Xw5TI+o6+3G/dcGM2nRss52
   BQAnNRB31Dx7/V2Rzb8/XnrsUkr3sg3RbbP3smsWdTYEXrO5+zmv5ZPZW
   oqeiKfpBmnvZ9ZN3dy42eVV6dszqNyeXBTEK/2XvS8RkebYqWY52+gyK4
   PLX3vYZmk9ruUzX/+2dLQn3Qx5ajH8gFDWM+KsiwzzfHohbG8aVgDQhoY
   w==;
X-CSE-ConnectionGUID: bcX7b9cGTtKvAVI1NMbeBg==
X-CSE-MsgGUID: l0HSxzTqS/CPCFUMquogxQ==
X-IronPort-AV: E=McAfee;i="6800,10657,11880"; a="86787554"
X-IronPort-AV: E=Sophos;i="6.25,231,1779174000"; 
   d="scan'208";a="86787554"
X-CSE-ConnectionGUID: DLD05uXOSQS3eQ3eQ3POPA==
X-CSE-MsgGUID: nBdVyMTXSn+BXYA1OEkKQA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.25,231,1779174000"; 
   d="scan'208";a="261366363"
Message-ID: <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
Date: Wed, 19 Aug 2026 07:40:09 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
To: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org,
 dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
 linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org,
 linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org,
 kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org,
 linux-pm@vger.kernel.org, linux-coco@lists.linux.dev,
 linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org,
 linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Damien Le Moal
 <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>,
 David Airlie <airlied@redhat.com>, Helge Deller <deller@gmx.de>,
 linux-geode@lists.infradead.org, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Linus Walleij <linusw@kernel.org>,
 Bartosz Golaszewski <brgl@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Peter Zijlstra <peterz@infradead.org>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu Wen <puwen@hygon.cn>,
 Tony Luck <tony.luck@intel.com>, Reinette Chatre
 <reinette.chatre@intel.com>, Dave Martin <Dave.Martin@arm.com>,
 James Morse <james.morse@arm.com>, Babu Moger <babu.moger@amd.com>,
 Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki"
 <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>,
 Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe
 <rick.p.edgecombe@intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Len Brown <lenb@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>,
 Huang Rui <ray.huang@amd.com>, Mario Limonciello
 <mario.limonciello@amd.com>, Perry Yuan <perry.yuan@amd.com>,
 K Prateek Nayak <kprateek.nayak@amd.com>,
 Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>, Guenter Roeck <linux@roeck-us.net>,
 Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
 Artem Bityutskiy <dedekind1@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
 Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@intel.com>,
 Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
 Lukasz Luba <lukasz.luba@arm.com>, xen-devel@lists.xenproject.org
References: <20260819102314.1499258-1-jgross@suse.com>
From: Dave Hansen <dave.hansen@intel.com>
Content-Language: en-US
Autocrypt: addr=dave.hansen@intel.com; keydata=
 xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC
 oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY
 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb
 ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz
 VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W
 iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn
 c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1
 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb
 ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL
 QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp
 c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs
 LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1
 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t
 MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF
 IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB
 aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2
 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY
 E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z
 F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR
 CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2
 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY
 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd
 GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr
 MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H
 Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B
 lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR
 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG
 qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH
 BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj
 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/
 vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci
 FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw
 l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn
 yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm
 +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l
 asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep
 WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8
 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju
 KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ
 MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH
 hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF
 vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y
In-Reply-To: <20260819102314.1499258-1-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787150417-1A4DB9EA-9D260346/0/0
X-purgate-type: clean
X-purgate-size: 727

Hey Juergen,

These look great. Thanks for doing it!

The only wonky thing is how we're going to actually merge it. We
obviously can't do patches 10-11 until all the "stop using" patches have
been applied.

I obviously 100% realize that it's during the merge window, but any acks
that the maintainers of 5-9 provide in the next few weeks would be super
helpful. Or, if any of those maintainers want to cherry pick their
subsystem's stuff out of this series and apply it, that would be great too.

But, the last time we did some MSR function munging, the tip tree
carried most of the patches. I would expect we'll have a repeat of that
here too. I'll pencil in the idea of just merging the lot around -rc1 time.


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 14:49:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 14:49:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395488.1633839 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhbG-0002XQ-Am; Wed, 19 Aug 2026 14:49:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395488.1633839; Wed, 19 Aug 2026 14:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhbG-0002XJ-7Y; Wed, 19 Aug 2026 14:49:06 +0000
Received: by outflank-mailman (input) for mailman id 1395488;
 Wed, 19 Aug 2026 14:49:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mlureau@redhat.com>) id 1wwhbE-0002XD-4L
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:49:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhbD-0061zO-0D
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 16:49:03 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mlureau@redhat.com>)
 id 6a85c23e-2eae-0a2a0a5409dd-0a2a4508dd7a-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:49:02 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mlureau@redhat.com>)
 id 6a85c1e4-f659-0a2a45080019-aa0a857ca5cd-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:47:02 +0200
Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com
 [209.85.217.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-678-XAyIYA4-Mwqo69TINZiYkg-1; Wed, 19 Aug 2026 10:46:53 -0400
Received: by mail-vs1-f70.google.com with SMTP id
 ada2fe7eead31-744e806f474so117735137.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:46:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787150820;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=565NvIcKFEkNBWn6JWVtxzNYyXZ2AzW1Nr3KJRE/BT0=;
	b=JN345ON6553CVGfS2cMw5ValqEbPaL6fKSnnX07QHXycmQg6VjrnMTi8nqPTWqtQDPzTDM
	EdmUFW7nKgHRRcFEJ085QfzvDzBnDZZrTe/rxB3LuF/UQ7JxxFtUk0qHoXkcqZF1IlV4bE
	VHpujQsTN3W373tiREwPWTEAdG9tDWE=
X-MC-Unique: XAyIYA4-Mwqo69TINZiYkg-1
X-Mimecast-MFC-AGG-ID: XAyIYA4-Mwqo69TINZiYkg_1787150812
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787150812; x=1787755612;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=565NvIcKFEkNBWn6JWVtxzNYyXZ2AzW1Nr3KJRE/BT0=;
        b=EwgIEsoHMVfmASd4t0DPvLLFmK6Uj3dMLlsl1cqHY5QAhaGJDWO3D9pcjG+quwrMXs
         SgWZ7tXhSSh8uFtMuOyETKVscKmQcmEnQXX7MOstQnslsqtIZoeGRjJ5jTDleO2yySd9
         BTS6hYkMw8+/8G4TOKQYdgO4T671ce7RjZbrM4YH2USaBDLLxca5N4FKk3+0en0/OHU7
         FMT/mSZVqRDV3JNflUa8ribBye/ITgef8I0a6BGhcAZNuChlrajzCfjr8tvSmQ70OdYo
         ubnDB9kvI5j2jT07K88WVhBpHzQN8bApKLAJzrANN5ECLiO/daCGokSDCEOyGv2+vGsB
         zasw==
X-Forwarded-Encrypted: i=1; AHgh+RoT+T76iprnzNp52qbU4Fa7IGz6DEiWGYlPmBDwN+COXKVPVw8dA1xdGX5aTBeXNh482LKvTHpDiBI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxsgbL+GkDcrah65ack9gO5UDMKj6TxMLMtBbW2MixI2w2YQ+Qi
	rqEPTFz4AyK/sqDnlCXx3WGbNwvZf+tm4W++JfbvP00bt1QOPB05DBZLxvLn5NFPwVQk39yNFi9
	/Vz+A69UgPlnR71tHQbpgjurmqsHH60E5apUwZLRqed2iMwHjP4/LDm8VuOe+zk+mtOAjeRpuXV
	FG1sSJQ32HcJU87FyeM6pF3smrfE6UmJmvGwFJBxCVvdw=
X-Gm-Gg: AR+sD11UF2Oy0I7/9KNgQO0i3HqHSgxR0KtZtpq4KTiBUgQ+d5aBXrxyBSjrmXKVr7I
	OlA7Tjz/9zHjonVfPKyI9jMNjBqmYEKVk5fszfkl0ogqi7wwrE8v1LEHJJuqQyCr+gq6j4Gjcnr
	safOHJZUBLVIxg/RrQ4sNefXr8ntoji53jHMMfSpGI2xeiw5GwJJhCB5iLYx/fGKfJc5fXQiKUk
	x+ErZXOWNGk/w3xvhZwTEMCIZLSyxLir0Hv1Wj0kqOW5His3CUREdEt7xHPTpUMLdXCFFrz7Wy2
	ww==
X-Received: by 2002:a05:6102:358c:b0:777:4e99:6f84 with SMTP id ada2fe7eead31-777f86830acmr1608230137.1.1787150809496;
        Wed, 19 Aug 2026 07:46:49 -0700 (PDT)
X-Received: by 2002:a05:6102:358c:b0:777:4e99:6f84 with SMTP id
 ada2fe7eead31-777f86830acmr1608061137.1.1787150805804; Wed, 19 Aug 2026
 07:46:45 -0700 (PDT)
MIME-Version: 1.0
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
 <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com> <aoW91OUi2w68yBTR@gallifrey>
In-Reply-To: <aoW91OUi2w68yBTR@gallifrey>
From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= <marcandre.lureau@redhat.com>
Date: Wed, 19 Aug 2026 18:46:31 +0400
X-Gm-Features: AcwNN1WD3xgWIpwQ8xqICbs_UgG2HYmGRBU7fTc10c3sww3zP_Kt4TixnxChlvM
Message-ID: <CAMxuvaz4RA8mSKYZJz9TqVgkRkt0APtdYCO1LOw+qrA3Jj494A@mail.gmail.com>
Subject: Re: [PATCH v3 37/49] monitor: tighten monitor_printf*()
To: "Dr. David Alan Gilbert" <dave@treblig.org>
Cc: qemu-devel@nongnu.org, =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= <philmd@mailo.com>, 
	=?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
	Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, 
	"Gonglei (Arei)" <arei.gonglei@huawei.com>, zhenwei pi <zhenwei.pi@linux.dev>, 
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>, 
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, Ani Sinha <anisinha@redhat.com>, 
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
	"Michael S. Tsirkin" <mst@redhat.com>, Brian Cain <brian.cain@oss.qualcomm.com>, 
	David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>, 
	Richard Henderson <richard.henderson@linaro.org>, Marcelo Tosatti <mtosatti@redhat.com>, 
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, Jiri Pirko <jiri@resnulli.us>, 
	Jason Wang <jasowangio@gmail.com>, Halil Pasic <pasic@linux.ibm.com>, 
	Christian Borntraeger <borntraeger@linux.ibm.com>, Jason Herne <jjherne@linux.ibm.com>, 
	Cornelia Huck <cohuck@redhat.com>, Eric Farman <farman@linux.ibm.com>, 
	Matthew Rosato <mjrosato@linux.ibm.com>, Ilya Leoshkevich <iii@linux.ibm.com>, 
	David Hildenbrand <david@kernel.org>, Stefano Stabellini <sstabellini@kernel.org>, 
	Anthony PERARD <anthony@xenproject.org>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
	Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>, 
	Fabiano Rosas <farosas@suse.de>, Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Stefan Berger <stefanb@linux.vnet.ibm.com>, Zhao Liu <zhao1.liu@intel.com>, 
	Nicholas Piggin <npiggin@gmail.com>, Chinmay Rath <rathc@linux.ibm.com>, 
	Glenn Miles <milesg@linux.ibm.com>, Harsh Prateek Bora <harshpb@linux.ibm.com>, 
	Palmer Dabbelt <palmer@dabbelt.com>, Alistair Francis <alistair.francis@wdc.com>, 
	Weiwei Li <liwei1518@gmail.com>, 
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
	Chao Liu <chao.liu@processmission.com>, Yoshinori Sato <yoshinori.sato@nifty.com>, 
	Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, kvm@vger.kernel.org, 
	qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, 
	qemu-riscv@nongnu.org
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: M0xmtvsHQK-hiADnhE8_MQP4uT93OEd2W0QGip6-xgE_1787150812
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-c1860d/1787150822-CE345BDB-9EF88530/13/0
X-purgate-type: bulk
X-purgate-size: 297500

Hi

On Wed, Aug 19, 2026 at 6:30=E2=80=AFPM Dr. David Alan Gilbert <dave@trebli=
g.org> wrote:
>
> * Marc-Andr=C3=A9 Lureau (marcandre.lureau@redhat.com) wrote:
> > Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> > monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> > the first parameter from Monitor * to MonitorHMP * to enforce type
> > safety. The implementation is also simplified: monitor_hmp_vprintf now
> > directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> > dispatch via moncls->vprintf.
> >
> > The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> > cast, they are fixed in the following commits.
> >
> > Signed-off-by: Marc-Andr=C3=A9 Lureau <marcandre.lureau@redhat.com>
>
> Hmm, this patch is HUGE.
> What are the chances of anyone being able to apply this without it confli=
cting
> in a bunch of places?
> Wouldn't it be better to split it into adding the monitor_hmp_ named vers=
ions,
> then splitting the uses into one patch by area and then
> trickling them in?

It's possible, but I can take care of the eventual conflicts as well,
it's not moving so fast.

thanks

>
> Dave
>
> > ---
> >  audio/audio-hmp-cmds.c                  |   6 +-
> >  backends/cryptodev-hmp-cmds.c           |   9 +-
> >  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
> >  chardev/char-hmp-cmds.c                 |  12 +-
> >  disas/disas-mon.c                       |  10 +-
> >  docs/devel/style.rst                    |   2 +-
> >  docs/devel/writing-monitor-commands.rst |   8 +-
> >  dump/dump-hmp-cmds.c                    |   5 +-
> >  hw/char/virtio-serial-bus.c             |  10 +-
> >  hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
> >  hw/core/sysbus.c                        |   5 +-
> >  hw/hexagon/hexagon_tlb.c                |  44 ++---
> >  hw/i386/kvm/xen-stubs.c                 |   6 +-
> >  hw/i386/kvm/xen_evtchn.c                |  21 +--
> >  hw/i386/sgx-hmp-stub.c                  |   3 +-
> >  hw/i386/sgx.c                           |  29 ++-
> >  hw/misc/auxbus.c                        |   9 +-
> >  hw/misc/mos6522-stub.c                  |   3 +-
> >  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++-------
> >  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
> >  hw/pci/pci-stub.c                       |   3 +-
> >  hw/s390x/s390-skeys.c                   |   9 +-
> >  hw/s390x/s390-stattrib.c                |  20 +--
> >  hw/uefi/ovmf-log.c                      |   5 +-
> >  hw/usb/bus.c                            |  11 +-
> >  hw/usb/host-libusb.c                    |  21 ++-
> >  hw/virtio/virtio-hmp-cmds.c             | 297 +++++++++++++++---------=
-------
> >  hw/xen/xen-bus.c                        |   5 +-
> >  include/disas/disas.h                   |   4 +-
> >  include/monitor/hmp.h                   |  12 +-
> >  migration/dirtyrate.c                   |  46 +++--
> >  migration/migration-hmp-cmds.c          | 305 ++++++++++++++++--------=
--------
> >  monitor/hmp-cmds.c                      | 141 +++++++--------
> >  monitor/hmp.c                           | 143 +++++++--------
> >  monitor/monitor-internal.h              |   6 -
> >  monitor/monitor.c                       |  33 ++--
> >  net/net-hmp-cmds.c                      |  31 ++--
> >  net/slirp.c                             |  31 ++--
> >  qom/qom-hmp-cmds.c                      |  27 ++-
> >  replay/replay-debugging.c               |   5 +-
> >  stats/stats-hmp-cmds.c                  |  57 +++---
> >  stubs/hmp-cmd-info_sev.c                |   3 +-
> >  stubs/monitor-core.c                    |   2 +-
> >  system/dirtylimit-hmp-cmds.c            |  10 +-
> >  system/qdev-monitor.c                   |  19 +-
> >  system/runstate-hmp-cmds.c              |  16 +-
> >  system/tpm-hmp-cmds.c                   |  29 ++-
> >  target/i386/cpu-apic.c                  |   3 +-
> >  target/i386/monitor.c                   | 152 ++++++++--------
> >  target/i386/sev.c                       |  35 ++--
> >  target/m68k/monitor.c                   |   3 +-
> >  target/ppc/monitor.c                    |   3 +-
> >  target/riscv/monitor.c                  |  55 +++---
> >  target/sh4/monitor.c                    |  29 ++-
> >  target/sparc/monitor.c                  |   3 +-
> >  target/xtensa/monitor.c                 |   3 +-
> >  tests/unit/test-util-sockets.c          |   2 +-
> >  tools/qemu-vnc/clipboard.c              |   4 +-
> >  tools/qemu-vnc/stubs.c                  |   2 +-
> >  trace/trace-hmp-cmds.c                  |  12 +-
> >  ui/ui-hmp-cmds.c                        | 115 ++++++------
> >  util/error-report.c                     |   2 +-
> >  util/qemu-print.c                       |   4 +-
> >  63 files changed, 1214 insertions(+), 1329 deletions(-)
> >
> > diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
> > index 4d326ec99fdf..94182fe1d71f 100644
> > --- a/audio/audio-hmp-cmds.c
> > +++ b/audio/audio-hmp-cmds.c
> > @@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState)=
 capture_head;
> >
> >  void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int i;
> >      CaptureState *s;
> >
> >      warn_report_once("'info capture' is deprecated since v10.2, to be =
removed");
> >
> >      for (s =3D capture_head.lh_first, i =3D 0; s; s =3D s->entries.le_=
next, ++i) {
> > -        monitor_printf(mon, "[%d]: ", i);
> > +        monitor_hmp_printf(hmp, "[%d]: ", i);
> >          s->ops.info (s->opaque);
> >      }
> >  }
> > @@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qd=
ict)
> >
> >  void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *path =3D qdict_get_str(qdict, "path");
> >      int freq =3D qdict_get_try_int(qdict, "freq", 44100);
> >      int bits =3D qdict_get_try_int(qdict, "bits", 16);
> > @@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdi=
ct)
> >      s =3D g_malloc0 (sizeof (*s));
> >
> >      if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
> > -        monitor_printf(mon, "Failed to add wave capture\n");
> > +        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
> >          g_free (s);
> >          return;
> >      }
> > diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmd=
s.c
> > index fb62428d795a..aafa4b970d24 100644
> > --- a/backends/cryptodev-hmp-cmds.c
> > +++ b/backends/cryptodev-hmp-cmds.c
> > @@ -19,7 +19,6 @@
> >
> >  void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      QCryptodevInfoList *il;
> >      QCryptodevBackendServiceTypeList *sl;
> >      QCryptodevBackendClientList *cl;
> > @@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDic=
t *qdict)
> >                  services =3D tmp_services;
> >              }
> >          }
> > -        monitor_printf(mon, "%s: service=3D[%s]\n", info->id, services=
);
> > +        monitor_hmp_printf(hmp, "%s: service=3D[%s]\n", info->id, serv=
ices);
> >
> >          for (cl =3D info->client; cl; cl =3D cl->next) {
> >              QCryptodevBackendClient *client =3D cl->value;
> > -            monitor_printf(mon, "    queue %" PRIu32 ": type=3D%s\n",
> > -                           client->queue,
> > -                           QCryptodevBackendType_str(client->type));
> > +            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=3D%s\=
n",
> > +                               client->queue,
> > +                               QCryptodevBackendType_str(client->type)=
);
> >          }
> >      }
> >
> > diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-c=
mds.c
> > index a2666e2f1b9b..7bae4d425c6d 100644
> > --- a/block/monitor/block-hmp-cmds.c
> > +++ b/block/monitor/block-hmp-cmds.c
> > @@ -89,7 +89,6 @@ out:
> >
> >  void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      DriveInfo *dinfo;
> >      QemuOpts *opts;
> > @@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qd=
ict)
> >
> >      switch (dinfo->type) {
> >      case IF_NONE:
> > -        monitor_printf(mon, "OK\n");
> > +        monitor_hmp_printf(hmp, "OK\n");
> >          break;
> >      default:
> >          error_setg(&err, "Can't hot-add drive to type %d", dinfo->type=
);
> > @@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdi=
ct)
> >      hmp_handle_error(hmp, err);
> >  }
> >
> > -static void print_block_info(Monitor *mon, BlockInfo *info,
> > +static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
> >                               BlockDeviceInfo *inserted, bool verbose)
> >  {
> > +    Monitor *mon =3D MONITOR(hmp);
> >      ImageInfo *image_info;
> >
> >      assert(!info || !info->inserted || info->inserted =3D=3D inserted)=
;
> > @@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInf=
o *info,
> >      if (info && *info->device) {
> >          monitor_puts(mon, info->device);
> >          if (inserted && inserted->node_name) {
> > -            monitor_printf(mon, " (%s)", inserted->node_name);
> > +            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
> >          }
> >      } else {
> >          assert(info || inserted);
> > @@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockI=
nfo *info,
> >      }
> >
> >      if (inserted) {
> > -        monitor_printf(mon, ": %s (%s%s%s%s)\n",
> > -                       inserted->file,
> > -                       inserted->drv,
> > -                       inserted->ro ? ", read-only" : "",
> > -                       inserted->encrypted ? ", encrypted" : "",
> > -                       inserted->active ? "" : ", inactive");
> > +        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
> > +                           inserted->file,
> > +                           inserted->drv,
> > +                           inserted->ro ? ", read-only" : "",
> > +                           inserted->encrypted ? ", encrypted" : "",
> > +                           inserted->active ? "" : ", inactive");
> >      } else {
> > -        monitor_printf(mon, ": [not inserted]\n");
> > +        monitor_hmp_printf(hmp, ": [not inserted]\n");
> >      }
> >
> >      if (info) {
> >          if (info->qdev) {
> > -            monitor_printf(mon, "    Attached to:      %s\n", info->qd=
ev);
> > +            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info=
->qdev);
> >          }
> >          if (info->has_io_status && info->io_status !=3D BLOCK_DEVICE_I=
O_STATUS_OK) {
> > -            monitor_printf(mon, "    I/O status:       %s\n",
> > -                           BlockDeviceIoStatus_str(info->io_status));
> > +            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
> > +                               BlockDeviceIoStatus_str(info->io_status=
));
> >          }
> >
> >          if (info->removable) {
> > -            monitor_printf(mon, "    Removable device: %slocked, tray =
%s\n",
> > -                           info->locked ? "" : "not ",
> > -                           info->tray_open ? "open" : "closed");
> > +            monitor_hmp_printf(hmp, "    Removable device: %slocked, t=
ray %s\n",
> > +                               info->locked ? "" : "not ",
> > +                               info->tray_open ? "open" : "closed");
> >          }
> >      }
> >
> > @@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockI=
nfo *info,
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
> > -                   inserted->cache->writeback ? "writeback" : "writeth=
rough",
> > -                   inserted->cache->direct ? ", direct" : "",
> > -                   inserted->cache->no_flush ? ", ignore flushes" : ""=
);
> > +    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
> > +                       inserted->cache->writeback ? "writeback" : "wri=
tethrough",
> > +                       inserted->cache->direct ? ", direct" : "",
> > +                       inserted->cache->no_flush ? ", ignore flushes" =
: "");
> >
> >      if (inserted->backing_file) {
> > -        monitor_printf(mon,
> > -                       "    Backing file:     %s "
> > -                       "(chain depth: %" PRId64 ")\n",
> > -                       inserted->backing_file,
> > -                       inserted->backing_file_depth);
> > +        monitor_hmp_printf(hmp,
> > +                           "    Backing file:     %s "
> > +                           "(chain depth: %" PRId64 ")\n",
> > +                           inserted->backing_file,
> > +                           inserted->backing_file_depth);
> >      }
> >
> >      if (inserted->detect_zeroes !=3D BLOCKDEV_DETECT_ZEROES_OPTIONS_OF=
F) {
> > -        monitor_printf(mon, "    Detect zeroes:    %s\n",
> > +        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
> >                  BlockdevDetectZeroesOptions_str(inserted->detect_zeroe=
s));
> >      }
> >
> >      if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
> >          inserted->iops || inserted->iops_rd || inserted->iops_wr)
> >      {
> > -        monitor_printf(mon, "    I/O throttling:   bps=3D%" PRId64
> > +        monitor_hmp_printf(hmp, "    I/O throttling:   bps=3D%" PRId64
> >                          " bps_rd=3D%" PRId64  " bps_wr=3D%" PRId64
> >                          " bps_max=3D%" PRId64
> >                          " bps_rd_max=3D%" PRId64
> > @@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInf=
o *info,
> >      }
> >
> >      if (verbose) {
> > -        monitor_printf(mon, "\nImages:\n");
> > +        monitor_hmp_printf(hmp, "\nImages:\n");
> >          image_info =3D inserted->image;
> >          while (1) {
> >              bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, fa=
lse);
> > @@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInf=
o *info,
> >
> >  void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      BlockInfoList *block_list, *info;
> >      BlockDeviceInfoList *blockdev_list, *blockdev;
> >      const char *device =3D qdict_get_try_str(qdict, "device");
> > @@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict =
*qdict)
> >          }
> >
> >          if (info !=3D block_list) {
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >
> > -        print_block_info(mon, info->value, info->value->inserted,
> > +        print_block_info(hmp, info->value, info->value->inserted,
> >                           verbose);
> >          printed =3D true;
> >      }
> > @@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict =
*qdict)
> >          }
> >
> >          if (blockdev !=3D blockdev_list) {
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >
> > -        print_block_info(mon, NULL, blockdev->value, verbose);
> > +        print_block_info(hmp, NULL, blockdev->value, verbose);
> >      }
> >      qapi_free_BlockDeviceInfoList(blockdev_list);
> >  }
> >
> >  void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      BlockStatsList *stats_list, *stats;
> >
> >      stats_list =3D qmp_query_blockstats(false, false, NULL);
> > @@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const Q=
Dict *qdict)
> >              continue;
> >          }
> >
> > -        monitor_printf(mon, "%s%s: idle_time_ns=3D%" PRId64 "\n",
> > -                       stats !=3D stats_list ? "\n" : "",
> > -                       stats->value->device,
> > -                       stats->value->stats->idle_time_ns);
> > -        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
> > -                       "operations", "total_time_ns", "merged");
> > -        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" P=
RId64
> > -                       " %10" PRId64 "\n",
> > -                       stats->value->stats->rd_bytes,
> > -                       stats->value->stats->rd_operations,
> > -                       stats->value->stats->rd_total_time_ns,
> > -                       stats->value->stats->rd_merged);
> > -        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" P=
RId64
> > -                       " %10" PRId64 "\n",
> > -                       stats->value->stats->wr_bytes,
> > -                       stats->value->stats->wr_operations,
> > -                       stats->value->stats->wr_total_time_ns,
> > -                       stats->value->stats->wr_merged);
> > -        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n=
",
> > -                       "",
> > -                       stats->value->stats->flush_operations,
> > -                       stats->value->stats->flush_total_time_ns);
> > +        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=3D%" PRId64 "\n",
> > +                           stats !=3D stats_list ? "\n" : "",
> > +                           stats->value->device,
> > +                           stats->value->stats->idle_time_ns);
> > +        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes=
",
> > +                           "operations", "total_time_ns", "merged");
> > +        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %2=
4" PRId64
> > +                           " %10" PRId64 "\n",
> > +                           stats->value->stats->rd_bytes,
> > +                           stats->value->stats->rd_operations,
> > +                           stats->value->stats->rd_total_time_ns,
> > +                           stats->value->stats->rd_merged);
> > +        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %2=
4" PRId64
> > +                           " %10" PRId64 "\n",
> > +                           stats->value->stats->wr_bytes,
> > +                           stats->value->stats->wr_operations,
> > +                           stats->value->stats->wr_total_time_ns,
> > +                           stats->value->stats->wr_merged);
> > +        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64=
 "\n",
> > +                           "",
> > +                           stats->value->stats->flush_operations,
> > +                           stats->value->stats->flush_total_time_ns);
> >      }
> >
> >      qapi_free_BlockStatsList(stats_list);
> > @@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const Q=
Dict *qdict)
> >
> >  void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      BlockJobInfoList *list;
> >
> >      list =3D qmp_query_block_jobs(&error_abort);
> >
> >      if (!list) {
> > -        monitor_printf(mon, "No active jobs\n");
> > +        monitor_hmp_printf(hmp, "No active jobs\n");
> >          return;
> >      }
> >
> >      while (list) {
> >          if (list->value->type =3D=3D JOB_TYPE_STREAM) {
> > -            monitor_printf(mon, "Streaming device %s: Completed %" PRI=
d64
> > -                           " of %" PRId64 " bytes, speed limit %" PRId=
64
> > -                           " bytes/s\n",
> > -                           list->value->device,
> > -                           list->value->offset,
> > -                           list->value->len,
> > -                           list->value->speed);
> > +            monitor_hmp_printf(hmp, "Streaming device %s: Completed %"=
 PRId64
> > +                               " of %" PRId64 " bytes, speed limit %" =
PRId64
> > +                               " bytes/s\n",
> > +                               list->value->device,
> > +                               list->value->offset,
> > +                               list->value->len,
> > +                               list->value->speed);
> >          } else {
> > -            monitor_printf(mon, "Type %s, device %s: Completed %" PRId=
64
> > -                           " of %" PRId64 " bytes, speed limit %" PRId=
64
> > -                           " bytes/s\n",
> > -                           JobType_str(list->value->type),
> > -                           list->value->device,
> > -                           list->value->offset,
> > -                           list->value->len,
> > -                           list->value->speed);
> > +            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" =
PRId64
> > +                               " of %" PRId64 " bytes, speed limit %" =
PRId64
> > +                               " bytes/s\n",
> > +                               JobType_str(list->value->type),
> > +                               list->value->device,
> > +                               list->value->offset,
> > +                               list->value->len,
> > +                               list->value->speed);
> >          }
> >          list =3D list->next;
> >      }
> > @@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDi=
ct *qdict)
> >
> >  void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      BlockDriverState *bs, *bs1;
> >      BdrvNextIterator it1;
> >      QEMUSnapshotInfo *sn_tab, *sn;
> > @@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDic=
t *qdict)
> >      nb_sns =3D bdrv_snapshot_list(bs, &sn_tab);
> >
> >      if (nb_sns < 0) {
> > -        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
> > +        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_s=
ns);
> >          return;
> >      }
> >
> > @@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDic=
t *qdict)
> >      }
> >
> >      if (no_snapshot) {
> > -        monitor_printf(mon, "There is no snapshot available.\n");
> > +        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
> >          return;
> >      }
> >
> > @@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QD=
ict *qdict)
> >              }
> >          }
> >      }
> > -    monitor_printf(mon, "List of snapshots present on all disks:\n");
> > +    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n=
");
> >
> >      if (total > 0) {
> >          bdrv_snapshot_dump(NULL);
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >          for (i =3D 0; i < total; i++) {
> >              sn =3D &sn_tab[global_snapshots[i]];
> >              /*
> > @@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QD=
ict *qdict)
> >               */
> >              pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
> >              bdrv_snapshot_dump(sn);
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >      } else {
> > -        monitor_printf(mon, "None\n");
> > +        monitor_hmp_printf(hmp, "None\n");
> >      }
> >
> >      QTAILQ_FOREACH(image_entry, &image_list, next) {
> >          if (QTAILQ_EMPTY(&image_entry->snapshots)) {
> >              continue;
> >          }
> > -        monitor_printf(mon,
> > -                       "\nList of partial (non-loadable) snapshots on =
'%s':\n",
> > -                       image_entry->imagename);
> > +        monitor_hmp_printf(hmp,
> > +                           "\nList of partial (non-loadable) snapshots=
 on '%s':\n",
> > +                           image_entry->imagename);
> >          bdrv_snapshot_dump(NULL);
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >          QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) =
{
> >              bdrv_snapshot_dump(&snapshot_entry->sn);
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >      }
> >
> > @@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDic=
t *qdict)
> >      g_free(global_snapshots);
> >  }
> >
> > -void hmp_change_medium(Monitor *mon, const char *device, const char *t=
arget,
> > +void hmp_change_medium(MonitorHMP *hmp, const char *device, const char=
 *target,
> >                         const char *arg, const char *read_only, bool fo=
rce,
> >                         Error **errp)
> >  {
> > diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
> > index 71017fd2d19e..fb0560054b7b 100644
> > --- a/chardev/char-hmp-cmds.c
> > +++ b/chardev/char-hmp-cmds.c
> > @@ -26,12 +26,11 @@
> >
> >  void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      ChardevInfoList *char_info, *info;
> >
> >      char_info =3D qmp_query_chardev(NULL);
> >      for (info =3D char_info; info; info =3D info->next) {
> > -        monitor_printf(mon, "%s: filename=3D%s\n", info->value->label,
> > +        monitor_hmp_printf(hmp, "%s: filename=3D%s\n", info->value->la=
bel,
> >                                                   info->value->filename=
);
> >      }
> >
> > @@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *=
qdict)
> >
> >  void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      uint32_t size =3D qdict_get_int(qdict, "size");
> >      const char *chardev =3D qdict_get_str(qdict, "device");
> >      char *data;
> > @@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict =
*qdict)
> >          unsigned char ch =3D data[i];
> >
> >          if (ch =3D=3D '\\') {
> > -            monitor_printf(mon, "\\\\");
> > +            monitor_hmp_printf(hmp, "\\\\");
> >          } else if ((ch < 0x20 && ch !=3D '\n' && ch !=3D '\t') || ch =
=3D=3D 0x7F) {
> > -            monitor_printf(mon, "\\u%04X", ch);
> > +            monitor_hmp_printf(hmp, "\\u%04X", ch);
> >          } else {
> > -            monitor_printf(mon, "%c", ch);
> > +            monitor_hmp_printf(hmp, "%c", ch);
> >          }
> >
> >      }
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >      g_free(data);
> >  }
> >
> > diff --git a/disas/disas-mon.c b/disas/disas-mon.c
> > index bc9dec3a7761..32e4220181a8 100644
> > --- a/disas/disas-mon.c
> > +++ b/disas/disas-mon.c
> > @@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myadd=
r, int length,
> >  }
> >
> >  /* Disassembler for the monitor.  */
> > -void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> > +void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
> >                     int nb_insn, bool is_physical)
> >  {
> >      int count, i;
> > @@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uin=
t64_t pc,
> >      s.info.buffer_vma =3D pc;
> >
> >      if (s.info.cap_arch >=3D 0 && cap_disas_monitor(&s.info, pc, nb_in=
sn)) {
> > -        monitor_puts(mon, ds->str);
> > +        monitor_puts(MONITOR(hmp), ds->str);
> >          return;
> >      }
> >
> >      if (!s.info.print_insn) {
> > -        monitor_printf(mon, "0x%08" PRIx64
> > -                       ": Asm output not supported on this arch\n", pc=
);
> > +        monitor_hmp_printf(hmp, "0x%08" PRIx64
> > +                           ": Asm output not supported on this arch\n"=
, pc);
> >          return;
> >      }
> >
> > @@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint6=
4_t pc,
> >          pc +=3D count;
> >      }
> >
> > -    monitor_puts(mon, ds->str);
> > +    monitor_puts(MONITOR(hmp), ds->str);
> >  }
> > diff --git a/docs/devel/style.rst b/docs/devel/style.rst
> > index 6c5f94cc5098..6876d3a59ec7 100644
> > --- a/docs/devel/style.rst
> > +++ b/docs/devel/style.rst
> > @@ -754,7 +754,7 @@ Error handling and reporting
> >  Reporting errors to the human user
> >  ----------------------------------
> >
> > -Do not use printf(), fprintf() or monitor_printf().  Instead, use
> > +Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
> >  error_report() or error_vreport() from error-report.h.  This ensures t=
he
> >  error is reported in the right place (current monitor or stderr), and =
in
> >  a uniform format.
> > diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writi=
ng-monitor-commands.rst
> > index 7ae7efe32759..baf94cbdefab 100644
> > --- a/docs/devel/writing-monitor-commands.rst
> > +++ b/docs/devel/writing-monitor-commands.rst
> > @@ -479,7 +479,7 @@ The HMP command
> >
> >  Here's the HMP counterpart of the query-option-roms command::
> >
> > - void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
> > + void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
> >   {
> >       Error *err =3D NULL;
> >       OptionRomInfoList *info_list, *tail;
> > @@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-ro=
ms command::
> >
> >       for (tail =3D info_list; tail; tail =3D tail->next) {
> >           info =3D tail->value;
> > -         monitor_printf(mon, "%s", info->filename);
> > +         monitor_hmp_printf(mon, "%s", info->filename);
> >           if (info->has_bootindex) {
> > -             monitor_printf(mon, " %" PRId64, info->bootindex);
> > +             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
> >           }
> > -         monitor_printf(mon, "\n");
> > +         monitor_hmp_printf(mon, "\n");
> >       }
> >
> >       qapi_free_OptionRomInfoList(info_list);
> > diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
> > index 104ab5d2a53a..c7045c2d7314 100644
> > --- a/dump/dump-hmp-cmds.c
> > +++ b/dump/dump-hmp-cmds.c
> > @@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const Q=
Dict *qdict)
> >
> >  void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      DumpQueryResult *result =3D qmp_query_dump(NULL);
> >
> >      assert(result && result->status < DUMP_STATUS__MAX);
> > -    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status)=
);
> > +    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->sta=
tus));
> >
> >      if (result->status =3D=3D DUMP_STATUS_ACTIVE) {
> >          float percent =3D 0;
> >          assert(result->total !=3D 0);
> >          percent =3D 100.0 * result->completed / result->total;
> > -        monitor_printf(mon, "Finished: %.2f %%\n", percent);
> > +        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
> >      }
> >
> >      qapi_free_DumpQueryResult(result);
> > diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
> > index 02604740f86a..33fdc0846ac3 100644
> > --- a/hw/char/virtio-serial-bus.c
> > +++ b/hw/char/virtio-serial-bus.c
> > @@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, D=
eviceState *qdev, int indent)
> >  {
> >      VirtIOSerialPort *port =3D VIRTIO_SERIAL_PORT(qdev);
> >
> > -    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n"=
,
> > -                   indent, "", port->id,
> > -                   port->guest_connected ? "on" : "off",
> > -                   port->host_connected ? "on" : "off",
> > -                   port->throttled ? "on" : "off");
> > +    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %=
s, throttle %s\n",
> > +                       indent, "", port->id,
> > +                       port->guest_connected ? "on" : "off",
> > +                       port->host_connected ? "on" : "off",
> > +                       port->throttled ? "on" : "off");
> >  }
> >
> >  /* This function is only used if a port id is not provided by the user=
 */
> > diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
> > index 702c798ccc56..10a633af0780 100644
> > --- a/hw/core/machine-hmp-cmds.c
> > +++ b/hw/core/machine-hmp-cmds.c
> > @@ -27,7 +27,6 @@
> >
> >  void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CpuInfoFastList *cpu_list, *cpu;
> >
> >      cpu_list =3D qmp_query_cpus_fast(NULL);
> > @@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qd=
ict)
> >              active =3D '*';
> >          }
> >
> > -        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
> > -                       cpu->value->cpu_index);
> > -        monitor_printf(mon, " thread_id=3D%" PRId64 " model=3D%s\n",
> > -                       cpu->value->thread_id, cpu_model);
> > +        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
> > +                           cpu->value->cpu_index);
> > +        monitor_hmp_printf(hmp, " thread_id=3D%" PRId64 " model=3D%s\n=
",
> > +                           cpu->value->thread_id, cpu_model);
> >      }
> >
> >      qapi_free_CpuInfoFastList(cpu_list);
> > @@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdic=
t)
> >
> >  void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      HotpluggableCPUList *l =3D qmp_query_hotpluggable_cpus(&err);
> >      HotpluggableCPUList *saved =3D l;
> > @@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const Q=
Dict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "Hotpluggable CPUs:\n");
> > +    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
> >      while (l) {
> > -        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
> > -        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
> > -                       l->value->vcpus_count);
> > +        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
> > +        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
> > +                           l->value->vcpus_count);
> >          if (l->value->qom_path) {
> > -            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_=
path);
> > +            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->=
qom_path);
> >          }
> >
> >          c =3D l->value->props;
> > -        monitor_printf(mon, "  CPUInstance Properties:\n");
> > +        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
> >          if (c->has_node_id) {
> > -            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->n=
ode_id);
> > +            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", =
c->node_id);
> >          }
> >          if (c->has_drawer_id) {
> > -            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c-=
>drawer_id);
> > +            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n"=
, c->drawer_id);
> >          }
> >          if (c->has_book_id) {
> > -            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->b=
ook_id);
> > +            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", =
c->book_id);
> >          }
> >          if (c->has_socket_id) {
> > -            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c-=
>socket_id);
> > +            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n"=
, c->socket_id);
> >          }
> >          if (c->has_die_id) {
> > -            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->di=
e_id);
> > +            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c=
->die_id);
> >          }
> >          if (c->has_cluster_id) {
> > -            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
> > -                           c->cluster_id);
> > +            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n=
",
> > +                               c->cluster_id);
> >          }
> >          if (c->has_module_id) {
> > -            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
> > -                           c->module_id);
> > +            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n"=
,
> > +                               c->module_id);
> >          }
> >          if (c->has_core_id) {
> > -            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->c=
ore_id);
> > +            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", =
c->core_id);
> >          }
> >          if (c->has_thread_id) {
> > -            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c-=
>thread_id);
> > +            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n"=
, c->thread_id);
> >          }
> >
> >          l =3D l->next;
> > @@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const Q=
Dict *qdict)
> >
> >  void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      MemdevList *memdev_list =3D qmp_query_memdev(&err);
> >      MemdevList *m =3D memdev_list;
> > @@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict=
 *qdict)
> >      while (m) {
> >          v =3D string_output_visitor_new(false, &str);
> >          visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_a=
bort);
> > -        monitor_printf(mon, "memory backend: %s\n", m->value->id);
> > -        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
> > -        monitor_printf(mon, "  merge: %s\n",
> > -                       m->value->merge ? "true" : "false");
> > -        monitor_printf(mon, "  dump: %s\n",
> > -                       m->value->dump ? "true" : "false");
> > -        monitor_printf(mon, "  prealloc: %s\n",
> > -                       m->value->prealloc ? "true" : "false");
> > -        monitor_printf(mon, "  share: %s\n",
> > -                       m->value->share ? "true" : "false");
> > +        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
> > +        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->si=
ze);
> > +        monitor_hmp_printf(hmp, "  merge: %s\n",
> > +                           m->value->merge ? "true" : "false");
> > +        monitor_hmp_printf(hmp, "  dump: %s\n",
> > +                           m->value->dump ? "true" : "false");
> > +        monitor_hmp_printf(hmp, "  prealloc: %s\n",
> > +                           m->value->prealloc ? "true" : "false");
> > +        monitor_hmp_printf(hmp, "  share: %s\n",
> > +                           m->value->share ? "true" : "false");
> >          if (m->value->has_reserve) {
> > -            monitor_printf(mon, "  reserve: %s\n",
> > -                           m->value->reserve ? "true" : "false");
> > +            monitor_hmp_printf(hmp, "  reserve: %s\n",
> > +                               m->value->reserve ? "true" : "false");
> >          }
> > -        monitor_printf(mon, "  policy: %s\n",
> > -                       HostMemPolicy_str(m->value->policy));
> > +        monitor_hmp_printf(hmp, "  policy: %s\n",
> > +                           HostMemPolicy_str(m->value->policy));
> >          visit_complete(v, &str);
> > -        monitor_printf(mon, "  host nodes: %s\n", str);
> > +        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
> >
> >          g_free(str);
> >          visit_free(v);
> >          m =3D m->next;
> >      }
> >
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >
> >      qapi_free_MemdevList(memdev_list);
> >      hmp_handle_error(hmp, err);
> > @@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict=
 *qdict)
> >
> >  void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      KvmInfo *info;
> >
> >      info =3D qmp_query_kvm(NULL);
> > -    monitor_printf(mon, "kvm support: ");
> > +    monitor_hmp_printf(hmp, "kvm support: ");
> >      if (info->present) {
> > -        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disab=
led");
> > +        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "d=
isabled");
> >      } else {
> > -        monitor_printf(mon, "not compiled\n");
> > +        monitor_hmp_printf(hmp, "not compiled\n");
> >      }
> >
> >      qapi_free_KvmInfo(info);
> > @@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdi=
ct)
> >
> >  void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      AcceleratorInfo *info;
> >      AcceleratorList *accel;
> >
> > @@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const Q=
Dict *qdict)
> >      for (accel =3D info->present; accel; accel =3D accel->next) {
> >          char trail =3D accel->next ? ' ' : '\n';
> >          if (info->enabled =3D=3D accel->value) {
> > -            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value=
), trail);
> > +            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->v=
alue), trail);
> >          } else {
> > -            monitor_printf(mon, "%s%c", Accelerator_str(accel->value),=
 trail);
> > +            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->val=
ue), trail);
> >          }
> >      }
> >
> > @@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const=
 QDict *qdict)
> >
> >  void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      UuidInfo *info;
> >
> >      info =3D qmp_query_uuid(NULL);
> > -    monitor_printf(mon, "%s\n", info->UUID);
> > +    monitor_hmp_printf(hmp, "%s\n", info->UUID);
> >      qapi_free_UuidInfo(info);
> >  }
> >
> >  void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      BalloonInfo *info;
> >      Error *err =3D NULL;
> >
> > @@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict =
*qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "balloon: actual=3D%" PRId64 "\n", info->actua=
l >> 20);
> > +    monitor_hmp_printf(hmp, "balloon: actual=3D%" PRId64 "\n", info->a=
ctual >> 20);
> >
> >      qapi_free_BalloonInfo(info);
> >  }
> > @@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QD=
ict *qdict)
> >
> >  void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      uint32_t size =3D qdict_get_int(qdict, "size");
> >      const char *filename =3D qdict_get_str(qdict, "filename");
> >      uint64_t addr =3D qdict_get_int(qdict, "val");
> > @@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdic=
t)
> >      int cpu_index =3D monitor_hmp_get_cpu_index(hmp);
> >
> >      if (cpu_index < 0) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >
> > @@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdic=
t)
> >
> >  void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      MemoryDeviceInfoList *info_list =3D qmp_query_memory_devices(&err)=
;
> >      MemoryDeviceInfoList *info;
> > @@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, con=
st QDict *qdict)
> >              case MEMORY_DEVICE_INFO_KIND_NVDIMM:
> >                  di =3D value->type =3D=3D MEMORY_DEVICE_INFO_KIND_DIMM=
 ?
> >                       value->u.dimm.data : value->u.nvdimm.data;
> > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > -                               MemoryDeviceInfoKind_str(value->type),
> > -                               di->id ? di->id : "");
> > -                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->add=
r);
> > -                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot)=
;
> > -                monitor_printf(mon, "  node: %" PRId64 "\n", di->node)=
;
> > -                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size)=
;
> > -                monitor_printf(mon, "  memdev: %s\n", di->memdev);
> > -                monitor_printf(mon, "  hotplugged: %s\n",
> > -                               di->hotplugged ? "true" : "false");
> > -                monitor_printf(mon, "  hotpluggable: %s\n",
> > -                               di->hotpluggable ? "true" : "false");
> > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n"=
,
> > +                                   MemoryDeviceInfoKind_str(value->typ=
e),
> > +                                   di->id ? di->id : "");
> > +                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di-=
>addr);
> > +                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->s=
lot);
> > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->n=
ode);
> > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->s=
ize);
> > +                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
> > +                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
> > +                                   di->hotplugged ? "true" : "false");
> > +                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
> > +                                   di->hotpluggable ? "true" : "false"=
);
> >                  break;
> >              case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
> >                  vpi =3D value->u.virtio_pmem.data;
> > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > -                               MemoryDeviceInfoKind_str(value->type),
> > -                               vpi->id ? vpi->id : "");
> > -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi-=
>memaddr);
> > -                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size=
);
> > -                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
> > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n"=
,
> > +                                   MemoryDeviceInfoKind_str(value->typ=
e),
> > +                                   vpi->id ? vpi->id : "");
> > +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", =
vpi->memaddr);
> > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->=
size);
> > +                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev)=
;
> >                  break;
> >              case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
> >                  vmi =3D value->u.virtio_mem.data;
> > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > -                               MemoryDeviceInfoKind_str(value->type),
> > -                               vmi->id ? vmi->id : "");
> > -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi-=
>memaddr);
> > -                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node=
);
> > -                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
> > -                               vmi->requested_size);
> > -                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size=
);
> > -                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->=
max_size);
> > -                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
> > -                               vmi->block_size);
> > -                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
> > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n"=
,
> > +                                   MemoryDeviceInfoKind_str(value->typ=
e),
> > +                                   vmi->id ? vmi->id : "");
> > +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", =
vmi->memaddr);
> > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->=
node);
> > +                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "=
\n",
> > +                                   vmi->requested_size);
> > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->=
size);
> > +                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", v=
mi->max_size);
> > +                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
> > +                                   vmi->block_size);
> > +                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev)=
;
> >                  break;
> >              case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
> >                  se =3D value->u.sgx_epc.data;
> > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > -                               MemoryDeviceInfoKind_str(value->type),
> > -                               se->id ? se->id : "");
> > -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->=
memaddr);
> > -                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size)=
;
> > -                monitor_printf(mon, "  node: %" PRId64 "\n", se->node)=
;
> > -                monitor_printf(mon, "  memdev: %s\n", se->memdev);
> > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n"=
,
> > +                                   MemoryDeviceInfoKind_str(value->typ=
e),
> > +                                   se->id ? se->id : "");
> > +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", =
se->memaddr);
> > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->s=
ize);
> > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->n=
ode);
> > +                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
> >                  break;
> >              case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
> >                  hi =3D value->u.hv_balloon.data;
> > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > -                               MemoryDeviceInfoKind_str(value->type),
> > -                               hi->id ? hi->id : "");
> > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n"=
,
> > +                                   MemoryDeviceInfoKind_str(value->typ=
e),
> > +                                   hi->id ? hi->id : "");
> >                  if (hi->has_memaddr) {
> > -                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
> > -                                   hi->memaddr);
> > +                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\=
n",
> > +                                       hi->memaddr);
> >                  }
> > -                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->m=
ax_size);
> > +                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", h=
i->max_size);
> >                  if (hi->memdev) {
> > -                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
> > +                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memd=
ev);
> >                  }
> >                  break;
> >              case MEMORY_DEVICE_INFO_KIND_SP_MEM:
> >                  spmi =3D value->u.sp_mem.data;
> > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > -                               MemoryDeviceInfoKind_str(value->type),
> > -                               spmi->id ? spmi->id : "");
> > -                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->a=
ddr);
> > -                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->nod=
e);
> > -                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->siz=
e);
> > -                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
> > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n"=
,
> > +                                   MemoryDeviceInfoKind_str(value->typ=
e),
> > +                                   spmi->id ? spmi->id : "");
> > +                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spm=
i->addr);
> > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi-=
>node);
> > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi-=
>size);
> > +                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev=
);
> >                  break;
> >              default:
> >                  g_assert_not_reached();
> > @@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, con=
st QDict *qdict)
> >
> >  void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      GuidInfo *info =3D qmp_query_vm_generation_id(&err);
> >      if (info) {
> > -        monitor_printf(mon, "%s\n", info->guid);
> > +        monitor_hmp_printf(hmp, "%s\n", info->guid);
> >      }
> >      hmp_handle_error(hmp, err);
> >      qapi_free_GuidInfo(info);
> > @@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, c=
onst QDict *qdict)
> >
> >  void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      MemoryInfo *info =3D qmp_query_memory_size_summary(&err);
> >      if (info) {
> > -        monitor_printf(mon, "base memory: %" PRIu64 "\n",
> > -                       info->base_memory);
> > +        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
> > +                           info->base_memory);
> >
> >          if (info->has_plugged_memory) {
> > -            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
> > -                           info->plugged_memory);
> > +            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
> > +                               info->plugged_memory);
> >          }
> >
> >          qapi_free_MemoryInfo(info);
> > diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> > index 13df7cbafe10..82130ba04698 100644
> > --- a/hw/core/sysbus.c
> > +++ b/hw/core/sysbus.c
> > @@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, =
Error **errp)
> >  static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int inden=
t)
> >  {
> >      SysBusDevice *s =3D SYS_BUS_DEVICE(dev);
> > +    MonitorHMP *hmp =3D MONITOR_HMP(mon);
> >      hwaddr size;
> >      int i;
> >
> >      for (i =3D 0; i < s->num_mmio; i++) {
> >          size =3D memory_region_size(s->mmio[i].memory);
> > -        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_p=
lx "\n",
> > -                       indent, "", s->mmio[i].addr, size);
> > +        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_F=
MT_plx "\n",
> > +                           indent, "", s->mmio[i].addr, size);
> >      }
> >  }
> >
> > diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
> > index 2d878cee736d..576929ff224b 100644
> > --- a/hw/hexagon/hexagon_tlb.c
> > +++ b/hw/hexagon/hexagon_tlb.c
> > @@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t=
 entry)
> >
> >  bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
> >  {
> > +    MonitorHMP *hmp =3D MONITOR_HMP(mon);
> > +
> >      if (GET_PTE_V(entry)) {
> >          uint64_t PA =3D hex_tlb_phys_addr(entry);
> >          uint64_t VA =3D hex_tlb_virt_addr(entry);
> > -        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
> > -        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
> > -                       " A1:%" PRId64 " A0:%" PRId64,
> > -                       GET_PTE_V(entry),
> > -                       GET_PTE_G(entry),
> > -                       GET_PTE_ATR1(entry),
> > -                       GET_PTE_ATR0(entry));
> > -        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
> > -                       GET_PTE_ASID(entry), VA);
> > -        monitor_printf(mon,
> > -                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
> > -                       " U:%" PRId64 " C:%" PRId64,
> > -                       GET_PTE_X(entry),
> > -                       GET_PTE_W(entry),
> > -                       GET_PTE_R(entry),
> > -                       GET_PTE_U(entry),
> > -                       GET_PTE_C(entry));
> > -        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")=
",
> > -                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
> > -                       hex_tlb_page_size_bytes(entry));
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
> > +        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
> > +                           " A1:%" PRId64 " A0:%" PRId64,
> > +                           GET_PTE_V(entry),
> > +                           GET_PTE_G(entry),
> > +                           GET_PTE_ATR1(entry),
> > +                           GET_PTE_ATR0(entry));
> > +        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx6=
4,
> > +                           GET_PTE_ASID(entry), VA);
> > +        monitor_hmp_printf(hmp,
> > +                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
> > +                           " U:%" PRId64 " C:%" PRId64,
> > +                           GET_PTE_X(entry),
> > +                           GET_PTE_W(entry),
> > +                           GET_PTE_R(entry),
> > +                           GET_PTE_U(entry),
> > +                           GET_PTE_C(entry));
> > +        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx6=
4 ")",
> > +                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
> > +                           hex_tlb_page_size_bytes(entry));
> > +        monitor_hmp_printf(hmp, "\n");
> >          return true;
> >      }
> >
> > diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
> > index ab1eb14f99e0..5ed71583281a 100644
> > --- a/hw/i386/kvm/xen-stubs.c
> > +++ b/hw/i386/kvm/xen-stubs.c
> > @@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
> >
> >  void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    monitor_printf(mon, "XEN emulation is not available in this QEMU\n=
");
> > +    monitor_hmp_printf(hmp, "XEN emulation is not available in this QE=
MU\n");
> >  }
> >
> >  void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    monitor_printf(mon, "XEN emulation is not available in this QEMU\n=
");
> > +    monitor_hmp_printf(hmp, "XEN emulation is not available in this QE=
MU\n");
> >  }
> > diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
> > index 00dff6ee8760..b2135020f27f 100644
> > --- a/hw/i386/kvm/xen_evtchn.c
> > +++ b/hw/i386/kvm/xen_evtchn.c
> > @@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **=
errp)
> >
> >  void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      EvtchnInfoList *iter, *info_list;
> >      Error *err =3D NULL;
> >
> > @@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const =
QDict *qdict)
> >      for (iter =3D info_list; iter; iter =3D iter->next) {
> >          EvtchnInfo *info =3D iter->value;
> >
> > -        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info-=
>vcpu,
> > -                       EvtchnPortType_str(info->type));
> > +        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, i=
nfo->vcpu,
> > +                           EvtchnPortType_str(info->type));
> >          if (info->type !=3D EVTCHN_PORT_TYPE_IPI) {
> > -            monitor_printf(mon,  "(");
> > +            monitor_hmp_printf(hmp,  "(");
> >              if (info->remote_domain) {
> > -                monitor_printf(mon, "%s:", info->remote_domain);
> > +                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
> >              }
> > -            monitor_printf(mon, "%d)", info->target);
> > +            monitor_hmp_printf(hmp, "%d)", info->target);
> >          }
> >          if (info->pending) {
> > -            monitor_printf(mon, " PENDING");
> > +            monitor_hmp_printf(hmp, " PENDING");
> >          }
> >          if (info->masked) {
> > -            monitor_printf(mon, " MASKED");
> > +            monitor_hmp_printf(hmp, " MASKED");
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >      }
> >
> >      qapi_free_EvtchnInfoList(info_list);
> > @@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QD=
ict *qdict)
> >
> >  void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int port =3D qdict_get_int(qdict, "port");
> >      Error *err =3D NULL;
> >
> > @@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const =
QDict *qdict)
> >      if (err) {
> >          hmp_handle_error(hmp, err);
> >      } else {
> > -        monitor_printf(mon, "Delivered port %d\n", port);
> > +        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
> >      }
> >  }
> > -
> > diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
> > index a4848ae1d1a7..b7afb26886a8 100644
> > --- a/hw/i386/sgx-hmp-stub.c
> > +++ b/hw/i386/sgx-hmp-stub.c
> > @@ -12,6 +12,5 @@
> >
> >  void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    monitor_printf(mon, "SGX is not available in this QEMU\n");
> > +    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
> >  }
> > diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
> > index 77b41d234c9f..634e33e819ce 100644
> > --- a/hw/i386/sgx.c
> > +++ b/hw/i386/sgx.c
> > @@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
> >
> >  void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      SgxEpcSectionList *section_list, *section;
> >      g_autoptr(SgxInfo) info =3D qmp_query_sgx(&err);
> > @@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *q=
dict)
> >          error_report_err(err);
> >          return;
> >      }
> > -    monitor_printf(mon, "SGX support: %s\n",
> > -                   info->sgx ? "enabled" : "disabled");
> > -    monitor_printf(mon, "SGX1 support: %s\n",
> > -                   info->sgx1 ? "enabled" : "disabled");
> > -    monitor_printf(mon, "SGX2 support: %s\n",
> > -                   info->sgx2 ? "enabled" : "disabled");
> > -    monitor_printf(mon, "FLC support: %s\n",
> > -                   info->flc ? "enabled" : "disabled");
> > +    monitor_hmp_printf(hmp, "SGX support: %s\n",
> > +                       info->sgx ? "enabled" : "disabled");
> > +    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
> > +                       info->sgx1 ? "enabled" : "disabled");
> > +    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
> > +                       info->sgx2 ? "enabled" : "disabled");
> > +    monitor_hmp_printf(hmp, "FLC support: %s\n",
> > +                       info->flc ? "enabled" : "disabled");
> >
> >      section_list =3D info->sections;
> >      for (section =3D section_list; section; section =3D section->next)=
 {
> > -        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
> > -                       section->value->node);
> > -        monitor_printf(mon, "size=3D%" PRIu64 "\n",
> > -                       section->value->size);
> > +        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
> > +                           section->value->node);
> > +        monitor_hmp_printf(hmp, "size=3D%" PRIu64 "\n",
> > +                           section->value->size);
> >          size +=3D section->value->size;
> >      }
> > -    monitor_printf(mon, "total size=3D%" PRIu64 "\n",
> > -                   size);
> > +    monitor_hmp_printf(hmp, "total size=3D%" PRIu64 "\n",
> > +                       size);
> >  }
> >
> >  bool check_sgx_support(void)
> > diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
> > index ac2525b90fec..ffa76f83016b 100644
> > --- a/hw/misc/auxbus.c
> > +++ b/hw/misc/auxbus.c
> > @@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, Dev=
iceState *dev, int indent)
> >
> >      s =3D AUX_SLAVE(dev);
> >
> > -    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx=
 "\n",
> > -                   indent, "",
> > -                   object_property_get_uint(OBJECT(s->mmio), "addr", N=
ULL),
> > -                   memory_region_size(s->mmio));
> > +    monitor_hmp_printf(MONITOR_HMP(mon),
> > +                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx =
"\n",
> > +                       indent, "",
> > +                       object_property_get_uint(OBJECT(s->mmio), "addr=
", NULL),
> > +                       memory_region_size(s->mmio));
> >  }
> >
> >  void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
> > diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
> > index 6a7d76292f00..154cd32ed88b 100644
> > --- a/hw/misc/mos6522-stub.c
> > +++ b/hw/misc/mos6522-stub.c
> > @@ -12,6 +12,5 @@
> >
> >  void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n")=
;
> > +    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU=
\n");
> >  }
> > diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp=
-cmds.c
> > index 6405ce26dd65..5099d59cc620 100644
> > --- a/hw/net/rocker/rocker-hmp-cmds.c
> > +++ b/hw/net/rocker/rocker-hmp-cmds.c
> > @@ -22,7 +22,6 @@
> >
> >  void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *name =3D qdict_get_str(qdict, "name");
> >      RockerSwitch *rocker;
> >      Error *err =3D NULL;
> > @@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict=
)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "name: %s\n", rocker->name);
> > -    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
> > -    monitor_printf(mon, "ports: %d\n", rocker->ports);
> > +    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
> > +    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
> > +    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
> >
> >      qapi_free_RockerSwitch(rocker);
> >  }
> >
> >  void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      RockerPortList *list, *port;
> >      const char *name =3D qdict_get_str(qdict, "name");
> >      Error *err =3D NULL;
> > @@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict =
*qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "            ena/    speed/ auto\n");
> > -    monitor_printf(mon, "      port  link    duplex neg?\n");
> > +    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
> > +    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
> >
> >      for (port =3D list; port; port =3D port->next) {
> > -        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
> > -                       port->value->name,
> > -                       port->value->enabled ? port->value->link_up ?
> > -                       "up" : "down" : "!ena",
> > -                       port->value->speed =3D=3D 10000 ? "10G" : "??",
> > -                       port->value->duplex ? "FD" : "HD",
> > -                       port->value->autoneg ? "Yes" : "No");
> > +        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
> > +                           port->value->name,
> > +                           port->value->enabled ? port->value->link_up=
 ?
> > +                           "up" : "down" : "!ena",
> > +                           port->value->speed =3D=3D 10000 ? "10G" : "=
??",
> > +                           port->value->duplex ? "FD" : "HD",
> > +                           port->value->autoneg ? "Yes" : "No");
> >      }
> >
> >      qapi_free_RockerPortList(list);
> > @@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *q=
dict)
> >
> >  void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      RockerOfDpaFlowList *list, *info;
> >      const char *name =3D qdict_get_str(qdict, "name");
> >      uint32_t tbl_id =3D qdict_get_try_int(qdict, "tbl_id", -1);
> > @@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const Q=
Dict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
> > +    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
> >
> >      for (info =3D list; info; info =3D info->next) {
> >          RockerOfDpaFlow *flow =3D info->value;
> > @@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const=
 QDict *qdict)
> >          RockerOfDpaFlowAction *action =3D flow->action;
> >
> >          if (flow->hits) {
> > -            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
> > -                           key->priority, key->tbl_id, flow->hits);
> > +            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
> > +                               key->priority, key->tbl_id, flow->hits)=
;
> >          } else {
> > -            monitor_printf(mon, "%-4d %-3d     ",
> > -                           key->priority, key->tbl_id);
> > +            monitor_hmp_printf(hmp, "%-4d %-3d     ",
> > +                               key->priority, key->tbl_id);
> >          }
> >
> >          if (key->has_in_pport) {
> > -            monitor_printf(mon, " pport %d", key->in_pport);
> > +            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
> >              if (mask->has_in_pport) {
> > -                monitor_printf(mon, "(0x%x)", mask->in_pport);
> > +                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
> >              }
> >          }
> >
> >          if (key->has_vlan_id) {
> > -            monitor_printf(mon, " vlan %d",
> > -                           key->vlan_id & VLAN_VID_MASK);
> > +            monitor_hmp_printf(hmp, " vlan %d",
> > +                               key->vlan_id & VLAN_VID_MASK);
> >              if (mask->has_vlan_id) {
> > -                monitor_printf(mon, "(0x%x)", mask->vlan_id);
> > +                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
> >              }
> >          }
> >
> >          if (key->has_tunnel_id) {
> > -            monitor_printf(mon, " tunnel %d", key->tunnel_id);
> > +            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
> >              if (mask->has_tunnel_id) {
> > -                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
> > +                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
> >              }
> >          }
> >
> >          if (key->has_eth_type) {
> >              switch (key->eth_type) {
> >              case 0x0806:
> > -                monitor_printf(mon, " ARP");
> > +                monitor_hmp_printf(hmp, " ARP");
> >                  break;
> >              case 0x0800:
> > -                monitor_printf(mon, " IP");
> > +                monitor_hmp_printf(hmp, " IP");
> >                  break;
> >              case 0x86dd:
> > -                monitor_printf(mon, " IPv6");
> > +                monitor_hmp_printf(hmp, " IPv6");
> >                  break;
> >              case 0x8809:
> > -                monitor_printf(mon, " LACP");
> > +                monitor_hmp_printf(hmp, " LACP");
> >                  break;
> >              case 0x88cc:
> > -                monitor_printf(mon, " LLDP");
> > +                monitor_hmp_printf(hmp, " LLDP");
> >                  break;
> >              default:
> > -                monitor_printf(mon, " eth type 0x%04x", key->eth_type)=
;
> > +                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_t=
ype);
> >                  break;
> >              }
> >          }
> > @@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, con=
st QDict *qdict)
> >              if ((strcmp(key->eth_src, "01:00:00:00:00:00") =3D=3D 0) &=
&
> >                  mask->eth_src &&
> >                  (strcmp(mask->eth_src, "01:00:00:00:00:00") =3D=3D 0))=
 {
> > -                monitor_printf(mon, " src <any mcast/bcast>");
> > +                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
> >              } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") =3D=
=3D 0) &&
> >                  mask->eth_src &&
> >                  (strcmp(mask->eth_src, "01:00:00:00:00:00") =3D=3D 0))=
 {
> > -                monitor_printf(mon, " src <any ucast>");
> > +                monitor_hmp_printf(hmp, " src <any ucast>");
> >              } else {
> > -                monitor_printf(mon, " src %s", key->eth_src);
> > +                monitor_hmp_printf(hmp, " src %s", key->eth_src);
> >                  if (mask->eth_src) {
> > -                    monitor_printf(mon, "(%s)", mask->eth_src);
> > +                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
> >                  }
> >              }
> >          }
> > @@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, con=
st QDict *qdict)
> >              if ((strcmp(key->eth_dst, "01:00:00:00:00:00") =3D=3D 0) &=
&
> >                  mask->eth_dst &&
> >                  (strcmp(mask->eth_dst, "01:00:00:00:00:00") =3D=3D 0))=
 {
> > -                monitor_printf(mon, " dst <any mcast/bcast>");
> > +                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
> >              } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") =3D=
=3D 0) &&
> >                  mask->eth_dst &&
> >                  (strcmp(mask->eth_dst, "01:00:00:00:00:00") =3D=3D 0))=
 {
> > -                monitor_printf(mon, " dst <any ucast>");
> > +                monitor_hmp_printf(hmp, " dst <any ucast>");
> >              } else {
> > -                monitor_printf(mon, " dst %s", key->eth_dst);
> > +                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
> >                  if (mask->eth_dst) {
> > -                    monitor_printf(mon, "(%s)", mask->eth_dst);
> > +                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
> >                  }
> >              }
> >          }
> >
> >          if (key->has_ip_proto) {
> > -            monitor_printf(mon, " proto %d", key->ip_proto);
> > +            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
> >              if (mask->has_ip_proto) {
> > -                monitor_printf(mon, "(0x%x)", mask->ip_proto);
> > +                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
> >              }
> >          }
> >
> >          if (key->has_ip_tos) {
> > -            monitor_printf(mon, " TOS %d", key->ip_tos);
> > +            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
> >              if (mask->has_ip_tos) {
> > -                monitor_printf(mon, "(0x%x)", mask->ip_tos);
> > +                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
> >              }
> >          }
> >
> >          if (key->ip_dst) {
> > -            monitor_printf(mon, " dst %s", key->ip_dst);
> > +            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
> >          }
> >
> >          if (action->has_goto_tbl || action->has_group_id ||
> >              action->has_new_vlan_id) {
> > -            monitor_printf(mon, " -->");
> > +            monitor_hmp_printf(hmp, " -->");
> >          }
> >
> >          if (action->has_new_vlan_id) {
> > -            monitor_printf(mon, " apply new vlan %d",
> > -                           ntohs(action->new_vlan_id));
> > +            monitor_hmp_printf(hmp, " apply new vlan %d",
> > +                               ntohs(action->new_vlan_id));
> >          }
> >
> >          if (action->has_group_id) {
> > -            monitor_printf(mon, " write group 0x%08x", action->group_i=
d);
> > +            monitor_hmp_printf(hmp, " write group 0x%08x", action->gro=
up_id);
> >          }
> >
> >          if (action->has_goto_tbl) {
> > -            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
> > +            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
> >          }
> >
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >      }
> >
> >      qapi_free_RockerOfDpaFlowList(list);
> > @@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const=
 QDict *qdict)
> >
> >  void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      RockerOfDpaGroupList *list, *g;
> >      const char *name =3D qdict_get_str(qdict, "name");
> >      uint8_t type =3D qdict_get_try_int(qdict, "type", 9);
> > @@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, co=
nst QDict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "id (decode) --> buckets\n");
> > +    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
> >
> >      for (g =3D list; g; g =3D g->next) {
> >          RockerOfDpaGroup *group =3D g->value;
> >          bool set =3D false;
> >
> > -        monitor_printf(mon, "0x%08x", group->id);
> > +        monitor_hmp_printf(hmp, "0x%08x", group->id);
> >
> > -        monitor_printf(mon, " (type %s", group->type =3D=3D 0 ? "L2 in=
terface" :
> > +        monitor_hmp_printf(hmp, " (type %s", group->type =3D=3D 0 ? "L=
2 interface" :
> >                                           group->type =3D=3D 1 ? "L2 re=
write" :
> >                                           group->type =3D=3D 2 ? "L3 un=
icast" :
> >                                           group->type =3D=3D 3 ? "L2 mu=
lticast" :
> > @@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, co=
nst QDict *qdict)
> >                                           "unknown");
> >
> >          if (group->has_vlan_id) {
> > -            monitor_printf(mon, " vlan %d", group->vlan_id);
> > +            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
> >          }
> >
> >          if (group->has_pport) {
> > -            monitor_printf(mon, " pport %d", group->pport);
> > +            monitor_hmp_printf(hmp, " pport %d", group->pport);
> >          }
> >
> >          if (group->has_index) {
> > -            monitor_printf(mon, " index %d", group->index);
> > +            monitor_hmp_printf(hmp, " index %d", group->index);
> >          }
> >
> > -        monitor_printf(mon, ") -->");
> > +        monitor_hmp_printf(hmp, ") -->");
> >
> >          if (group->has_set_vlan_id && group->set_vlan_id) {
> >              set =3D true;
> > -            monitor_printf(mon, " set vlan %d",
> > -                           group->set_vlan_id & VLAN_VID_MASK);
> > +            monitor_hmp_printf(hmp, " set vlan %d",
> > +                               group->set_vlan_id & VLAN_VID_MASK);
> >          }
> >
> >          if (group->set_eth_src) {
> >              if (!set) {
> >                  set =3D true;
> > -                monitor_printf(mon, " set");
> > +                monitor_hmp_printf(hmp, " set");
> >              }
> > -            monitor_printf(mon, " src %s", group->set_eth_src);
> > +            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
> >          }
> >
> >          if (group->set_eth_dst) {
> >              if (!set) {
> > -                monitor_printf(mon, " set");
> > +                monitor_hmp_printf(hmp, " set");
> >              }
> > -            monitor_printf(mon, " dst %s", group->set_eth_dst);
> > +            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
> >          }
> >
> >          if (group->has_ttl_check && group->ttl_check) {
> > -            monitor_printf(mon, " check TTL");
> > +            monitor_hmp_printf(hmp, " check TTL");
> >          }
> >
> >          if (group->has_group_id && group->group_id) {
> > -            monitor_printf(mon, " group id 0x%08x", group->group_id);
> > +            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_i=
d);
> >          }
> >
> >          if (group->has_pop_vlan && group->pop_vlan) {
> > -            monitor_printf(mon, " pop vlan");
> > +            monitor_hmp_printf(hmp, " pop vlan");
> >          }
> >
> >          if (group->has_out_pport) {
> > -            monitor_printf(mon, " out pport %d", group->out_pport);
> > +            monitor_hmp_printf(hmp, " out pport %d", group->out_pport)=
;
> >          }
> >
> >          if (group->has_group_ids) {
> >              struct uint32List *id;
> >
> > -            monitor_printf(mon, " groups [");
> > +            monitor_hmp_printf(hmp, " groups [");
> >              for (id =3D group->group_ids; id; id =3D id->next) {
> > -                monitor_printf(mon, "0x%08x", id->value);
> > +                monitor_hmp_printf(hmp, "0x%08x", id->value);
> >                  if (id->next) {
> > -                    monitor_printf(mon, ",");
> > +                    monitor_hmp_printf(hmp, ",");
> >                  }
> >              }
> > -            monitor_printf(mon, "]");
> > +            monitor_hmp_printf(hmp, "]");
> >          }
> >
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >      }
> >
> >      qapi_free_RockerOfDpaGroupList(list);
> > diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
> > index 51d95d76620e..500f821246a9 100644
> > --- a/hw/pci/pci-hmp-cmds.c
> > +++ b/hw/pci/pci-hmp-cmds.c
> > @@ -24,54 +24,55 @@
> >  #include "qapi/qapi-commands-pci.h"
> >  #include "qemu/cutils.h"
> >
> > -static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev=
)
> > +static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *=
dev)
> >  {
> > +    Monitor *mon =3D MONITOR(hmp);
> >      PciMemoryRegionList *region;
> >
> > -    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
> > -    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n"=
,
> > -                   dev->slot, dev->function);
> > -    monitor_printf(mon, "    ");
> > +    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
> > +    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 "=
:\n",
> > +                       dev->slot, dev->function);
> > +    monitor_hmp_printf(hmp, "    ");
> >
> >      if (dev->class_info->desc) {
> >          monitor_puts(mon, dev->class_info->desc);
> >      } else {
> > -        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_cla=
ss);
> > +        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q=
_class);
> >      }
> >
> > -    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
> > -                   dev->id->vendor, dev->id->device);
> > +    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\=
n",
> > +                       dev->id->vendor, dev->id->device);
> >      if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
> > -        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PR=
Ix64 "\n",
> > -                       dev->id->subsystem_vendor, dev->id->subsystem);
> > +        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04=
" PRIx64 "\n",
> > +                           dev->id->subsystem_vendor, dev->id->subsyst=
em);
> >      }
> >
> >      if (dev->has_irq) {
> > -        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
> > -                       dev->irq, (char)('A' + dev->irq_pin - 1));
> > +        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
> > +                           dev->irq, (char)('A' + dev->irq_pin - 1));
> >      }
> >
> >      if (dev->pci_bridge) {
> > -        monitor_printf(mon, "      BUS %" PRId64 ".\n",
> > -                       dev->pci_bridge->bus->number);
> > -        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
> > -                       dev->pci_bridge->bus->secondary);
> > -        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
> > -                       dev->pci_bridge->bus->subordinate);
> > +        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
> > +                           dev->pci_bridge->bus->number);
> > +        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
> > +                           dev->pci_bridge->bus->secondary);
> > +        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n"=
,
> > +                           dev->pci_bridge->bus->subordinate);
> >
> > -        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx=
64"]\n",
> > -                       dev->pci_bridge->bus->io_range->base,
> > -                       dev->pci_bridge->bus->io_range->limit);
> > +        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"=
PRIx64"]\n",
> > +                           dev->pci_bridge->bus->io_range->base,
> > +                           dev->pci_bridge->bus->io_range->limit);
> >
> > -        monitor_printf(mon,
> > -                       "      memory range [0x%08"PRIx64", 0x%08"PRIx6=
4"]\n",
> > -                       dev->pci_bridge->bus->memory_range->base,
> > -                       dev->pci_bridge->bus->memory_range->limit);
> > +        monitor_hmp_printf(hmp,
> > +                           "      memory range [0x%08"PRIx64", 0x%08"P=
RIx64"]\n",
> > +                           dev->pci_bridge->bus->memory_range->base,
> > +                           dev->pci_bridge->bus->memory_range->limit);
> >
> > -        monitor_printf(mon, "      prefetchable memory range "
> > -                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
> > -                       dev->pci_bridge->bus->prefetchable_range->base,
> > -                       dev->pci_bridge->bus->prefetchable_range->limit=
);
> > +        monitor_hmp_printf(hmp, "      prefetchable memory range "
> > +                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
> > +                           dev->pci_bridge->bus->prefetchable_range->b=
ase,
> > +                           dev->pci_bridge->bus->prefetchable_range->l=
imit);
> >      }
> >
> >      for (region =3D dev->regions; region; region =3D region->next) {
> > @@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const=
 PciDeviceInfo *dev)
> >          addr =3D region->value->address;
> >          size =3D region->value->size;
> >
> > -        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->b=
ar);
> > +        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->valu=
e->bar);
> >
> >          if (!strcmp(region->value->type, "io")) {
> >              if (addr !=3D PCI_BAR_UNMAPPED) {
> > -                monitor_printf(mon, "I/O at 0x%04" PRIx64
> > +                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
> >                                      " [0x%04" PRIx64 "]\n",
> >                                 addr, addr + size - 1);
> >              } else {
> > -                monitor_printf(mon, "I/O (not mapped)\n");
> > +                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
> >              }
> >          } else {
> >              if (addr !=3D PCI_BAR_UNMAPPED) {
> > -                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
> > +                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRI=
x64
> >                                     " [0x%08" PRIx64 "]\n",
> >                                 region->value->mem_type_64 ? 64 : 32,
> >                                 region->value->prefetch ? " prefetchabl=
e" : "",
> >                                 addr, addr + size - 1);
> >              } else {
> > -                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
> > -                               region->value->mem_type_64 ? 64 : 32,
> > -                               region->value->prefetch ? " prefetchabl=
e" : "");
> > +                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\=
n",
> > +                                   region->value->mem_type_64 ? 64 : 3=
2,
> > +                                   region->value->prefetch ? " prefetc=
hable" : "");
> >              }
> >          }
> >      }
> >
> > -    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
> > +    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
> >
> >      if (dev->pci_bridge) {
> >          if (dev->pci_bridge->has_devices) {
> >              PciDeviceInfoList *cdev;
> >              for (cdev =3D dev->pci_bridge->devices; cdev; cdev =3D cde=
v->next) {
> > -                hmp_info_pci_device(mon, cdev->value);
> > +                hmp_info_pci_device(hmp, cdev->value);
> >              }
> >          }
> >      }
> > @@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const=
 PciDeviceInfo *dev)
> >
> >  void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      PciInfoList *info_list, *info;
> >
> >      info_list =3D qmp_query_pci(&error_abort);
> > @@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdi=
ct)
> >          PciDeviceInfoList *dev;
> >
> >          for (dev =3D info->value->devices; dev; dev =3D dev->next) {
> > -            hmp_info_pci_device(mon, dev->value);
> > +            hmp_info_pci_device(hmp, dev->value);
> >          }
> >      }
> >
> > @@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdi=
ct)
> >
> >  void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> >  {
> > +    MonitorHMP *hmp =3D MONITOR_HMP(mon);
> >      PCIDevice *d =3D (PCIDevice *)dev;
> >      int class =3D pci_get_word(d->config + PCI_CLASS_DEVICE);
> >      const pci_class_desc *desc =3D get_class_desc(class);
> > @@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *=
dev, int indent)
> >          snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
> >      }
> >
> > -    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
> > -                   "pci id %04x:%04x (sub %04x:%04x)\n",
> > -                   indent, "", ctxt, pci_dev_bus_num(d),
> > -                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
> > -                   pci_get_word(d->config + PCI_VENDOR_ID),
> > -                   pci_get_word(d->config + PCI_DEVICE_ID),
> > -                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
> > -                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
> > +    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
> > +                       "pci id %04x:%04x (sub %04x:%04x)\n",
> > +                       indent, "", ctxt, pci_dev_bus_num(d),
> > +                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
> > +                       pci_get_word(d->config + PCI_VENDOR_ID),
> > +                       pci_get_word(d->config + PCI_DEVICE_ID),
> > +                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_I=
D),
> > +                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
> >      for (i =3D 0; i < PCI_NUM_REGIONS; i++) {
> >          r =3D &d->io_regions[i];
> >          if (!r->size) {
> >              continue;
> >          }
> > -        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
> > -                       " [0x%"FMT_PCIBUS"]\n",
> > -                       indent, "",
> > -                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" =
: "mem",
> > -                       r->addr, r->addr + r->size - 1);
> > +        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
> > +                           " [0x%"FMT_PCIBUS"]\n",
> > +                           indent, "",
> > +                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i=
/o" : "mem",
> > +                           r->addr, r->addr + r->size - 1);
> >      }
> >  }
> >
> >  void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      const char *id =3D qdict_get_str(qdict, "id");
> >      const char *error_name;
> > @@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, con=
st QDict *qdict)
> >      }
> >
> >
> > -    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\=
n",
> > -                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
> > -                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> > +    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x=
.%x\n",
> > +                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev=
),
> > +                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> >
> >  out:
> >      hmp_handle_error(hmp, err);
> > diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
> > index a80e34175462..7e2797300ba0 100644
> > --- a/hw/pci/pci-stub.c
> > +++ b/hw/pci/pci-stub.c
> > @@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict=
)
> >
> >  void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    monitor_printf(mon, "PCI devices not supported\n");
> > +    monitor_hmp_printf(hmp, "PCI devices not supported\n");
> >  }
> >
> >  /* kvm-all wants this */
> > diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
> > index d8afaf730639..b5e56a16cce1 100644
> > --- a/hw/s390x/s390-skeys.c
> > +++ b/hw/s390x/s390-skeys.c
> > @@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint=
64_t startgfn,
> >
> >  void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      S390SKeysState *ss =3D s390_get_skeys_device();
> >      S390SKeysClass *skeyclass =3D S390_SKEYS_GET_CLASS(ss);
> >      uint64_t addr =3D qdict_get_int(qdict, "addr");
> > @@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict =
*qdict)
> >
> >      /* Quick check to see if guest is using storage keys*/
> >      if (!skeyclass->skeys_are_enabled(ss)) {
> > -        monitor_printf(mon, "Error: This guest is not using storage ke=
ys\n");
> > +        monitor_hmp_printf(hmp, "Error: This guest is not using storag=
e keys\n");
> >          return;
> >      }
> >
> >      if (!address_space_access_valid(&address_space_memory,
> >                                      addr & TARGET_PAGE_MASK, TARGET_PA=
GE_SIZE,
> >                                      false, MEMTXATTRS_UNSPECIFIED)) {
> > -        monitor_printf(mon, "Error: The given address is not valid\n")=
;
> > +        monitor_hmp_printf(hmp, "Error: The given address is not valid=
\n");
> >          return;
> >      }
> >
> >      r =3D skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
> >      if (r < 0) {
> > -        monitor_printf(mon, "Error: %s\n", strerror(-r));
> > +        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "  key: 0x%X\n", key);
> > +    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
> >  }
> >
> >  void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
> > diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
> > index b4a405455901..644298f7f0b2 100644
> > --- a/hw/s390x/s390-stattrib.c
> > +++ b/hw/s390x/s390-stattrib.c
> > @@ -61,7 +61,6 @@ void s390_stattrib_init(void)
> >
> >  void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      S390StAttribState *sas =3D s390_get_stattrib_device();
> >      S390StAttribClass *sac =3D S390_STATTRIB_GET_CLASS(sas);
> >      uint64_t what =3D qdict_get_int(qdict, "mode");
> > @@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict=
 *qdict)
> >
> >      r =3D sac->set_migrationmode(sas, what, &local_err);
> >      if (r < 0) {
> > -        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
> > +        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_er=
r));
> >          error_free(local_err);
> >      }
> >  }
> >
> >  void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      S390StAttribState *sas =3D s390_get_stattrib_device();
> >      S390StAttribClass *sac =3D S390_STATTRIB_GET_CLASS(sas);
> >      uint64_t addr =3D qdict_get_int(qdict, "addr");
> > @@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qd=
ict)
> >
> >      vals =3D g_try_malloc(buflen);
> >      if (!vals) {
> > -        monitor_printf(mon, "Error: %s\n", strerror(errno));
> > +        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
> >          return;
> >      }
> >
> >      len =3D sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, val=
s);
> >      if (len < 0) {
> > -        monitor_printf(mon, "Error: %s", strerror(-len));
> > +        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
> >          goto out;
> >      }
> >
> > -    monitor_printf(mon, "  CMMA attributes, "
> > -                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
> > -                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_M=
ASK);
> > +    monitor_hmp_printf(hmp, "  CMMA attributes, "
> > +                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
> > +                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PA=
GE_MASK);
> >      for (cx =3D 0; cx < len; cx++) {
> >          if (cx % 8 =3D=3D 7) {
> > -            monitor_printf(mon, "%02x\n", vals[cx]);
> > +            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
> >          } else {
> > -            monitor_printf(mon, "%02x", vals[cx]);
> > +            monitor_hmp_printf(hmp, "%02x", vals[cx]);
> >          }
> >      }
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >
> >  out:
> >      g_free(vals);
> > diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
> > index 0d59a74ad60e..0249eea2cfe9 100644
> > --- a/hw/uefi/ovmf-log.c
> > +++ b/hw/uefi/ovmf-log.c
> > @@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_s=
ize, uint64_t max_size,
> >
> >  void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      g_autofree gchar *log_esc =3D NULL;
> >      g_autofree guchar *log_out =3D NULL;
> >      Error *err =3D NULL;
> > @@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const=
 QDict *qdict)
> >
> >      if (log->version) {
> >          g_autofree gchar *esc =3D g_strescape(log->version, NULL);
> > -        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
> > +        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
> >      }
> >
> >      log_out =3D g_base64_decode(log->log, &log_len);
> >      log_esc =3D g_strescape((gchar *)log_out, "\r\n");
> > -    monitor_printf(mon, "%s\n", log_esc);
> > +    monitor_hmp_printf(hmp, "%s\n", log_esc);
> >  }
> > diff --git a/hw/usb/bus.c b/hw/usb/bus.c
> > index 9b9b2e7c2f8f..fe3dbfa2227c 100644
> > --- a/hw/usb/bus.c
> > +++ b/hw/usb/bus.c
> > @@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
> >
> >  static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int ind=
ent)
> >  {
> > +    MonitorHMP *hmp =3D MONITOR_HMP(mon);
> >      USBDevice *dev =3D USB_DEVICE(qdev);
> >      USBBus *bus =3D usb_bus_from_device(dev);
> >
> > -    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n=
",
> > -                   indent, "", bus->busnr, dev->addr,
> > -                   dev->port ? dev->port->path : "-",
> > -                   usb_speed(dev->speed), dev->product_desc,
> > -                   dev->attached ? ", attached" : "");
> > +    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s=
%s\n",
> > +                       indent, "", bus->busnr, dev->addr,
> > +                       dev->port ? dev->port->path : "-",
> > +                       usb_speed(dev->speed), dev->product_desc,
> > +                       dev->attached ? ", attached" : "");
> >  }
> >
> >  static char *usb_get_dev_path(DeviceState *qdev)
> > diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> > index c02343d3a655..9b9f26a1078e 100644
> > --- a/hw/usb/host-libusb.c
> > +++ b/hw/usb/host-libusb.c
> > @@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
> >
> >  void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      libusb_device **devs =3D NULL;
> >      struct libusb_device_descriptor ddesc;
> >      char port[16];
> > @@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QD=
ict *qdict)
> >              continue;
> >          }
> >          usb_host_get_port(devs[i], port, sizeof(port));
> > -        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s=
\n",
> > -                       libusb_get_bus_number(devs[i]),
> > -                       libusb_get_device_address(devs[i]),
> > -                       port,
> > -                       speed_name[libusb_get_device_speed(devs[i])]);
> > -        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
> > -        monitor_printf(mon, " USB device %04x:%04x",
> > -                       ddesc.idVendor, ddesc.idProduct);
> > +        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s =
Mb/s\n",
> > +                           libusb_get_bus_number(devs[i]),
> > +                           libusb_get_device_address(devs[i]),
> > +                           port,
> > +                           speed_name[libusb_get_device_speed(devs[i])=
]);
> > +        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass)=
;
> > +        monitor_hmp_printf(hmp, " USB device %04x:%04x",
> > +                           ddesc.idVendor, ddesc.idProduct);
> >          if (ddesc.iProduct) {
> >              libusb_device_handle *handle;
> >              if (libusb_open(devs[i], &handle) =3D=3D 0) {
> > @@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QD=
ict *qdict)
> >                                                     ddesc.iProduct,
> >                                                     name, sizeof(name))=
;
> >                  libusb_close(handle);
> > -                monitor_printf(mon, ", %s", name);
> > +                monitor_hmp_printf(hmp, ", %s", name);
> >              }
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >      }
> >      libusb_free_device_list(devs, 1);
> >  }
> > diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
> > index fb36c8b9274c..e5da6f00699d 100644
> > --- a/hw/virtio/virtio-hmp-cmds.c
> > +++ b/hw/virtio/virtio-hmp-cmds.c
> > @@ -12,77 +12,76 @@
> >  #include "qobject/qdict.h"
> >
> >
> > -static void hmp_virtio_dump_protocols(Monitor *mon,
> > +static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
> >                                        VhostDeviceProtocols *pcol)
> >  {
> >      strList *pcol_list =3D pcol->protocols;
> >      while (pcol_list) {
> > -        monitor_printf(mon, "\t%s", pcol_list->value);
> > +        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
> >          pcol_list =3D pcol_list->next;
> >          if (pcol_list !=3D NULL) {
> > -            monitor_printf(mon, ",\n");
> > +            monitor_hmp_printf(hmp, ",\n");
> >          }
> >      }
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >      if (pcol->has_unknown_protocols) {
> > -        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
> > -                       pcol->unknown_protocols);
> > +        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n=
",
> > +                           pcol->unknown_protocols);
> >      }
> >  }
> >
> > -static void hmp_virtio_dump_status(Monitor *mon,
> > +static void hmp_virtio_dump_status(MonitorHMP *hmp,
> >                                     VirtioDeviceStatus *status)
> >  {
> >      strList *status_list =3D status->statuses;
> >      while (status_list) {
> > -        monitor_printf(mon, "\t%s", status_list->value);
> > +        monitor_hmp_printf(hmp, "\t%s", status_list->value);
> >          status_list =3D status_list->next;
> >          if (status_list !=3D NULL) {
> > -            monitor_printf(mon, ",\n");
> > +            monitor_hmp_printf(hmp, ",\n");
> >          }
> >      }
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >      if (status->has_unknown_statuses) {
> > -        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
> > -                       status->unknown_statuses);
> > +        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n"=
,
> > +                           status->unknown_statuses);
> >      }
> >  }
> >
> > -static void hmp_virtio_dump_features(Monitor *mon,
> > +static void hmp_virtio_dump_features(MonitorHMP *hmp,
> >                                       VirtioDeviceFeatures *features)
> >  {
> >      strList *transport_list =3D features->transports;
> >      while (transport_list) {
> > -        monitor_printf(mon, "\t%s", transport_list->value);
> > +        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
> >          transport_list =3D transport_list->next;
> >          if (transport_list !=3D NULL) {
> > -            monitor_printf(mon, ",\n");
> > +            monitor_hmp_printf(hmp, ",\n");
> >          }
> >      }
> >
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >      strList *list =3D features->dev_features;
> >      if (list) {
> >          while (list) {
> > -            monitor_printf(mon, "\t%s", list->value);
> > +            monitor_hmp_printf(hmp, "\t%s", list->value);
> >              list =3D list->next;
> >              if (list !=3D NULL) {
> > -                monitor_printf(mon, ",\n");
> > +                monitor_hmp_printf(hmp, ",\n");
> >              }
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >      }
> >
> >      if (features->has_unknown_dev_features) {
> > -        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRI=
x64")\n",
> > -                       features->unknown_dev_features2,
> > -                       features->unknown_dev_features);
> > +        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016=
"PRIx64")\n",
> > +                           features->unknown_dev_features2,
> > +                           features->unknown_dev_features);
> >      }
> >  }
> >
> >  void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      VirtioInfoList *list =3D qmp_x_query_virtio(&err);
> >      VirtioInfoList *node;
> > @@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict =
*qdict)
> >      }
> >
> >      if (list =3D=3D NULL) {
> > -        monitor_printf(mon, "No VirtIO devices\n");
> > +        monitor_hmp_printf(hmp, "No VirtIO devices\n");
> >          return;
> >      }
> >
> >      node =3D list;
> >      while (node) {
> > -        monitor_printf(mon, "%s [%s]\n", node->value->path,
> > -                       node->value->name);
> > +        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
> > +                           node->value->name);
> >          node =3D node->next;
> >      }
> >      qapi_free_VirtioInfoList(list);
> > @@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict =
*qdict)
> >
> >  void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      const char *path =3D qdict_get_try_str(qdict, "path");
> >      VirtioStatus *s =3D qmp_x_query_virtio_status(path, &err);
> > @@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDi=
ct *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "%s:\n", path);
> > -    monitor_printf(mon, "  device_name:             %s %s\n",
> > -                   s->name, s->vhost_dev ? "(vhost)" : "");
> > -    monitor_printf(mon, "  device_id:               %d\n", s->device_i=
d);
> > -    monitor_printf(mon, "  vhost_started:           %s\n",
> > -                   s->vhost_started ? "true" : "false");
> > -    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name=
);
> > -    monitor_printf(mon, "  broken:                  %s\n",
> > -                   s->broken ? "true" : "false");
> > -    monitor_printf(mon, "  disabled:                %s\n",
> > -                   s->disabled ? "true" : "false");
> > -    monitor_printf(mon, "  disable_legacy_check:    %s\n",
> > -                   s->disable_legacy_check ? "true" : "false");
> > -    monitor_printf(mon, "  started:                 %s\n",
> > -                   s->started ? "true" : "false");
> > -    monitor_printf(mon, "  use_started:             %s\n",
> > -                   s->use_started ? "true" : "false");
> > -    monitor_printf(mon, "  start_on_kick:           %s\n",
> > -                   s->start_on_kick ? "true" : "false");
> > -    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
> > -                   s->use_guest_notifier_mask ? "true" : "false");
> > -    monitor_printf(mon, "  vm_running:              %s\n",
> > -                   s->vm_running ? "true" : "false");
> > -    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->n=
um_vqs);
> > -    monitor_printf(mon, "  queue_sel:               %d\n",
> > -                   s->queue_sel);
> > -    monitor_printf(mon, "  isr:                     %d\n", s->isr);
> > -    monitor_printf(mon, "  endianness:              %s\n",
> > -                   s->device_endian);
> > -    monitor_printf(mon, "  status:\n");
> > -    hmp_virtio_dump_status(mon, s->status);
> > -    monitor_printf(mon, "  Guest features:\n");
> > -    hmp_virtio_dump_features(mon, s->guest_features);
> > -    monitor_printf(mon, "  Host features:\n");
> > -    hmp_virtio_dump_features(mon, s->host_features);
> > -    monitor_printf(mon, "  Backend features:\n");
> > -    hmp_virtio_dump_features(mon, s->backend_features);
> > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > +    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
> > +                       s->name, s->vhost_dev ? "(vhost)" : "");
> > +    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->devi=
ce_id);
> > +    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
> > +                       s->vhost_started ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_=
name);
> > +    monitor_hmp_printf(hmp, "  broken:                  %s\n",
> > +                       s->broken ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  disabled:                %s\n",
> > +                       s->disabled ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
> > +                       s->disable_legacy_check ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  started:                 %s\n",
> > +                       s->started ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  use_started:             %s\n",
> > +                       s->use_started ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
> > +                       s->start_on_kick ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
> > +                       s->use_guest_notifier_mask ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
> > +                       s->vm_running ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", =
s->num_vqs);
> > +    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
> > +                       s->queue_sel);
> > +    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr)=
;
> > +    monitor_hmp_printf(hmp, "  endianness:              %s\n",
> > +                       s->device_endian);
> > +    monitor_hmp_printf(hmp, "  status:\n");
> > +    hmp_virtio_dump_status(hmp, s->status);
> > +    monitor_hmp_printf(hmp, "  Guest features:\n");
> > +    hmp_virtio_dump_features(hmp, s->guest_features);
> > +    monitor_hmp_printf(hmp, "  Host features:\n");
> > +    hmp_virtio_dump_features(hmp, s->host_features);
> > +    monitor_hmp_printf(hmp, "  Backend features:\n");
> > +    hmp_virtio_dump_features(hmp, s->backend_features);
> >
> >      if (s->vhost_dev) {
> > -        monitor_printf(mon, "  VHost:\n");
> > -        monitor_printf(mon, "    nvqs:           %d\n",
> > -                       s->vhost_dev->nvqs);
> > -        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
> > -                       s->vhost_dev->vq_index);
> > -        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
> > -                       s->vhost_dev->max_queues);
> > -        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
> > -                       s->vhost_dev->n_mem_sections);
> > -        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
> > -                       s->vhost_dev->n_tmp_sections);
> > -        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
> > -                       s->vhost_dev->backend_cap);
> > -        monitor_printf(mon, "    log_enabled:    %s\n",
> > -                       s->vhost_dev->log_enabled ? "true" : "false");
> > -        monitor_printf(mon, "    log_size:       %"PRId64"\n",
> > -                       s->vhost_dev->log_size);
> > -        monitor_printf(mon, "    Features:\n");
> > -        hmp_virtio_dump_features(mon, s->vhost_dev->features);
> > -        monitor_printf(mon, "    Acked features:\n");
> > -        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
> > -        monitor_printf(mon, "    Protocol features:\n");
> > -        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features=
);
> > +        monitor_hmp_printf(hmp, "  VHost:\n");
> > +        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
> > +                           s->vhost_dev->nvqs);
> > +        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
> > +                           s->vhost_dev->vq_index);
> > +        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
> > +                           s->vhost_dev->max_queues);
> > +        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
> > +                           s->vhost_dev->n_mem_sections);
> > +        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
> > +                           s->vhost_dev->n_tmp_sections);
> > +        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
> > +                           s->vhost_dev->backend_cap);
> > +        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
> > +                           s->vhost_dev->log_enabled ? "true" : "false=
");
> > +        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
> > +                           s->vhost_dev->log_size);
> > +        monitor_hmp_printf(hmp, "    Features:\n");
> > +        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
> > +        monitor_hmp_printf(hmp, "    Acked features:\n");
> > +        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
> > +        monitor_hmp_printf(hmp, "    Protocol features:\n");
> > +        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features=
);
> >      }
> >
> >      qapi_free_VirtioStatus(s);
> > @@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict=
 *qdict)
> >
> >  void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      const char *path =3D qdict_get_try_str(qdict, "path");
> >      int queue =3D qdict_get_int(qdict, "queue");
> > @@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, cons=
t QDict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "%s:\n", path);
> > -    monitor_printf(mon, "  device_name:          %s (vhost)\n",
> > -                   s->name);
> > -    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick=
);
> > -    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call=
);
> > -    monitor_printf(mon, "  VRing:\n");
> > -    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
> > -    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
> > -                   s->desc_phys);
> > -    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
> > -    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
> > -                   s->avail_phys);
> > -    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size)=
;
> > -    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
> > -                   s->used_phys);
> > -    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
> > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > +    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
> > +                       s->name);
> > +    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->=
kick);
> > +    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->=
call);
> > +    monitor_hmp_printf(hmp, "  VRing:\n");
> > +    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
> > +    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
> > +                       s->desc_phys);
> > +    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_si=
ze);
> > +    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
> > +                       s->avail_phys);
> > +    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_s=
ize);
> > +    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
> > +                       s->used_phys);
> > +    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_si=
ze);
> >
> >      qapi_free_VirtVhostQueueStatus(s);
> >  }
> >
> >  void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      const char *path =3D qdict_get_try_str(qdict, "path");
> >      int queue =3D qdict_get_int(qdict, "queue");
> > @@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, con=
st QDict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "%s:\n", path);
> > -    monitor_printf(mon, "  device_name:          %s\n", s->name);
> > -    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index=
);
> > -    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
> > -    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
> > -    monitor_printf(mon, "  signalled_used:       %d\n",
> > -                   s->signalled_used);
> > -    monitor_printf(mon, "  signalled_used_valid: %s\n",
> > -                   s->signalled_used_valid ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > +    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
> > +    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_i=
ndex);
> > +    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
> > +    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_id=
x);
> > +    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
> > +                       s->signalled_used);
> > +    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
> > +                       s->signalled_used_valid ? "true" : "false");
> >      if (s->has_last_avail_idx) {
> > -        monitor_printf(mon, "  last_avail_idx:       %d\n",
> > -                       s->last_avail_idx);
> > +        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
> > +                           s->last_avail_idx);
> >      }
> >      if (s->has_shadow_avail_idx) {
> > -        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
> > -                       s->shadow_avail_idx);
> > +        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
> > +                           s->shadow_avail_idx);
> >      }
> > -    monitor_printf(mon, "  VRing:\n");
> > -    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num)=
;
> > -    monitor_printf(mon, "    num_default:  %"PRId32"\n",
> > -                   s->vring_num_default);
> > -    monitor_printf(mon, "    align:        %"PRId32"\n",
> > -                   s->vring_align);
> > -    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
> > -                   s->vring_desc);
> > -    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
> > -                   s->vring_avail);
> > -    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
> > -                   s->vring_used);
> > +    monitor_hmp_printf(hmp, "  VRing:\n");
> > +    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_=
num);
> > +    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
> > +                       s->vring_num_default);
> > +    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
> > +                       s->vring_align);
> > +    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
> > +                       s->vring_desc);
> > +    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
> > +                       s->vring_avail);
> > +    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
> > +                       s->vring_used);
> >
> >      qapi_free_VirtQueueStatus(s);
> >  }
> >
> >  void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      const char *path =3D qdict_get_try_str(qdict, "path");
> >      int queue =3D qdict_get_int(qdict, "queue");
> > @@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, co=
nst QDict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "%s:\n", path);
> > -    monitor_printf(mon, "  device_name: %s\n", e->name);
> > -    monitor_printf(mon, "  index:   %d\n", e->index);
> > -    monitor_printf(mon, "  desc:\n");
> > -    monitor_printf(mon, "    descs:\n");
> > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > +    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
> > +    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
> > +    monitor_hmp_printf(hmp, "  desc:\n");
> > +    monitor_hmp_printf(hmp, "    descs:\n");
> >
> >      list =3D e->descs;
> >      while (list) {
> > -        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
> > -                       list->value->addr, list->value->len);
> > +        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
> > +                           list->value->addr, list->value->len);
> >          if (list->value->flags) {
> >              strList *flag =3D list->value->flags;
> > -            monitor_printf(mon, " (");
> > +            monitor_hmp_printf(hmp, " (");
> >              while (flag) {
> > -                monitor_printf(mon, "%s", flag->value);
> > +                monitor_hmp_printf(hmp, "%s", flag->value);
> >                  flag =3D flag->next;
> >                  if (flag) {
> > -                    monitor_printf(mon, ", ");
> > +                    monitor_hmp_printf(hmp, ", ");
> >                  }
> >              }
> > -            monitor_printf(mon, ")");
> > +            monitor_hmp_printf(hmp, ")");
> >          }
> >          list =3D list->next;
> >          if (list) {
> > -            monitor_printf(mon, ",\n");
> > +            monitor_hmp_printf(hmp, ",\n");
> >          }
> >      }
> > -    monitor_printf(mon, "\n");
> > -    monitor_printf(mon, "  avail:\n");
> > -    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
> > -    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
> > -    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
> > -    monitor_printf(mon, "  used:\n");
> > -    monitor_printf(mon, "    flags: %d\n", e->used->flags);
> > -    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
> > +    monitor_hmp_printf(hmp, "\n");
> > +    monitor_hmp_printf(hmp, "  avail:\n");
> > +    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
> > +    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
> > +    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
> > +    monitor_hmp_printf(hmp, "  used:\n");
> > +    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
> > +    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
> >
> >      qapi_free_VirtioQueueElement(e);
> >  }
> > diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> > index a563f6066bb4..4075b5b001ae 100644
> > --- a/hw/xen/xen-bus.c
> > +++ b/hw/xen/xen-bus.c
> > @@ -103,10 +103,11 @@ abort:
> >
> >  static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int inde=
nt)
> >  {
> > +    MonitorHMP *hmp =3D MONITOR_HMP(mon);
> >      XenDevice *xendev =3D XEN_DEVICE(dev);
> >
> > -    monitor_printf(mon, "%*sname =3D '%s' frontend_id =3D %u\n",
> > -                   indent, "", xendev->name, xendev->frontend_id);
> > +    monitor_hmp_printf(hmp, "%*sname =3D '%s' frontend_id =3D %u\n",
> > +                       indent, "", xendev->name, xendev->frontend_id);
> >  }
> >
> >  static char *xen_bus_get_dev_path(DeviceState *dev)
> > diff --git a/include/disas/disas.h b/include/disas/disas.h
> > index c702b1effc1c..47daa9b4d2df 100644
> > --- a/include/disas/disas.h
> > +++ b/include/disas/disas.h
> > @@ -1,13 +1,15 @@
> >  #ifndef QEMU_DISAS_H
> >  #define QEMU_DISAS_H
> >
> > +#include "monitor/hmp.h"
> > +
> >  /* Disassemble this for me please... (debugging). */
> >  #ifdef CONFIG_TCG
> >  void disas(FILE *out, const void *code, size_t size);
> >  void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db=
);
> >  #endif
> >
> > -void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> > +void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
> >                     int nb_insn, bool is_physical);
> >
> >  #ifdef CONFIG_PLUGIN
> > diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> > index 3fd17048b319..f10bf83df86d 100644
> > --- a/include/monitor/hmp.h
> > +++ b/include/monitor/hmp.h
> > @@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *ch=
ardev_id,
> >
> >  MonitorHMP *monitor_cur_hmp(void);
> >
> > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> >      G_GNUC_PRINTF(2, 0);
> > -int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2=
, 3);
> > -void monitor_printc(Monitor *mon, int ch);
> > +int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_P=
RINTF(2, 3);
> > +void monitor_hmp_printc(MonitorHMP *mon, int ch);
> >
> >  void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
> >  int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_=
func,
> > @@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
> >  int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
> >
> >  bool hmp_handle_error(MonitorHMP *hmp, Error *err);
> > -void hmp_help_cmd(Monitor *mon, const char *name);
> > +void hmp_help_cmd(MonitorHMP *hmp, const char *name);
> >  strList *hmp_split_at_comma(const char *str);
> >
> >  void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
> > @@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDic=
t *qdict);
> >  void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
> >  void hmp_change(MonitorHMP *hmp, const QDict *qdict);
> >  #ifdef CONFIG_VNC
> > -void hmp_change_vnc(Monitor *mon, const char *device, const char *targ=
et,
> > +void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *t=
arget,
> >                      const char *arg, const char *read_only, bool force=
,
> >                      Error **errp);
> >  #endif
> > -void hmp_change_medium(Monitor *mon, const char *device, const char *t=
arget,
> > +void hmp_change_medium(MonitorHMP *hmp, const char *device, const char=
 *target,
> >                         const char *arg, const char *read_only, bool fo=
rce,
> >                         Error **errp);
> >  void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
> > diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> > index 3c0931796ce2..bdbb2aaa99db 100644
> > --- a/migration/dirtyrate.c
> > +++ b/migration/dirtyrate.c
> > @@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool h=
as_calc_time_unit,
> >
> >  void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      DirtyRateInfo *info =3D query_dirty_rate_info(TIME_UNIT_SECOND);
> >
> > -    monitor_printf(mon, "Status: %s\n",
> > -                   DirtyRateStatus_str(info->status));
> > -    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
> > -                   info->start_time);
> > +    monitor_hmp_printf(hmp, "Status: %s\n",
> > +                       DirtyRateStatus_str(info->status));
> > +    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
> > +                       info->start_time);
> >      if (info->mode =3D=3D DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
> > -        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
> > -                       info->sample_pages);
> > +        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
> > +                           info->sample_pages);
> >      }
> > -    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
> > -                   info->calc_time);
> > -    monitor_printf(mon, "Mode: %s\n",
> > -                   DirtyRateMeasureMode_str(info->mode));
> > -    monitor_printf(mon, "Dirty rate: ");
> > +    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
> > +                       info->calc_time);
> > +    monitor_hmp_printf(hmp, "Mode: %s\n",
> > +                       DirtyRateMeasureMode_str(info->mode));
> > +    monitor_hmp_printf(hmp, "Dirty rate: ");
> >      if (info->has_dirty_rate) {
> > -        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
> > +        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate=
);
> >          if (info->has_vcpu_dirty_rate) {
> >              DirtyRateVcpuList *rate, *head =3D info->vcpu_dirty_rate;
> >              for (rate =3D head; rate !=3D NULL; rate =3D rate->next) {
> > -                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PR=
Ii64
> > -                               " (MB/s)\n", rate->value->id,
> > -                               rate->value->dirty_rate);
> > +                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: =
%"PRIi64
> > +                                   " (MB/s)\n", rate->value->id,
> > +                                   rate->value->dirty_rate);
> >              }
> >          }
> >      } else {
> > -        monitor_printf(mon, "(not ready)\n");
> > +        monitor_hmp_printf(hmp, "(not ready)\n");
> >      }
> >
> >      qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
> > @@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDi=
ct *qdict)
> >
> >  void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int64_t sec =3D qdict_get_try_int(qdict, "second", 0);
> >      int64_t sample_pages =3D qdict_get_try_int(qdict, "sample_pages_pe=
r_GB", -1);
> >      bool has_sample_pages =3D (sample_pages !=3D -1);
> > @@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const Q=
Dict *qdict)
> >      Error *err =3D NULL;
> >
> >      if (!sec) {
> > -        monitor_printf(mon, "Incorrect period length specified!\n");
> > +        monitor_hmp_printf(hmp, "Incorrect period length specified!\n"=
);
> >          return;
> >      }
> >
> >      if (dirty_ring && dirty_bitmap) {
> > -        monitor_printf(mon, "Either dirty ring or dirty bitmap "
> > -                       "can be specified!\n");
> > +        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
> > +                           "can be specified!\n");
> >          return;
> >      }
> >
> > @@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDi=
ct *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "Starting dirty rate measurement with period %=
"PRIi64
> > -                   " seconds\n", sec);
> > -    monitor_printf(mon, "[Please use 'info dirty_rate' to check result=
s]\n");
> > +    monitor_hmp_printf(hmp, "Starting dirty rate measurement with peri=
od %"PRIi64
> > +                       " seconds\n", sec);
> > +    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check re=
sults]\n");
> >  }
> > diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-c=
mds.c
> > index 73a974259478..6fe189471899 100644
> > --- a/migration/migration-hmp-cmds.c
> > +++ b/migration/migration-hmp-cmds.c
> > @@ -36,23 +36,23 @@
> >  #include "options.h"
> >  #include "migration.h"
> >
> > -static void migration_global_dump(Monitor *mon)
> > +static void migration_global_dump(MonitorHMP *hmp)
> >  {
> >      MigrationState *ms =3D migrate_get_current();
> >
> > -    monitor_printf(mon, "Globals:\n");
> > -    monitor_printf(mon, "  store-global-state: %s\n",
> > -                   ms->store_global_state ? "on" : "off");
> > -    monitor_printf(mon, "  only-migratable: %s\n",
> > -                   only_migratable ? "on" : "off");
> > -    monitor_printf(mon, "  send-configuration: %s\n",
> > -                   ms->send_configuration ? "on" : "off");
> > -    monitor_printf(mon, "  send-section-footer: %s\n",
> > -                   ms->send_section_footer ? "on" : "off");
> > -    monitor_printf(mon, "  send-switchover-start: %s\n",
> > -                   ms->send_switchover_start ? "on" : "off");
> > -    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
> > -                   ms->clear_bitmap_shift);
> > +    monitor_hmp_printf(hmp, "Globals:\n");
> > +    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
> > +                       ms->store_global_state ? "on" : "off");
> > +    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
> > +                       only_migratable ? "on" : "off");
> > +    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
> > +                       ms->send_configuration ? "on" : "off");
> > +    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
> > +                       ms->send_section_footer ? "on" : "off");
> > +    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
> > +                       ms->send_switchover_start ? "on" : "off");
> > +    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
> > +                       ms->clear_bitmap_shift);
> >  }
> >
> >  static const gchar *format_time_str(uint64_t us)
> > @@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
> >      return g_strdup_printf("%"PRIu64" %s", us, units[index]);
> >  }
> >
> > -static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info=
)
> > +static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *i=
nfo)
> >  {
> >      if (info->has_postcopy_blocktime) {
> > -        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
> > -                       info->postcopy_blocktime);
> > +        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\=
n",
> > +                           info->postcopy_blocktime);
> >      }
> >
> >      if (info->has_postcopy_vcpu_blocktime) {
> > @@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, =
MigrationInfo *info)
> >          const char *sep =3D "";
> >          int count =3D 0;
> >
> > -        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
> > +        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
> >
> >          while (item) {
> > -            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
> > +            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
> >              item =3D item->next;
> >              /* Each line 10 vcpu results, newline if there's more */
> >              sep =3D ((++count % 10 =3D=3D 0) && item) ? ",\n  " : ", "=
;
> >          }
> > -        monitor_printf(mon, "]\n");
> > +        monitor_hmp_printf(hmp, "]\n");
> >      }
> >
> >      if (info->has_postcopy_latency) {
> > -        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
> > -                       info->postcopy_latency);
> > +        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n"=
,
> > +                           info->postcopy_latency);
> >      }
> >
> >      if (info->has_postcopy_non_vcpu_latency) {
> > -        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64=
 "\n",
> > -                       info->postcopy_non_vcpu_latency);
> > +        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PR=
Iu64 "\n",
> > +                           info->postcopy_non_vcpu_latency);
> >      }
> >
> >      if (info->has_postcopy_vcpu_latency) {
> > @@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon=
, MigrationInfo *info)
> >          const char *sep =3D "";
> >          int count =3D 0;
> >
> > -        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
> > +        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
> >
> >          while (item) {
> > -            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
> > +            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
> >              item =3D item->next;
> >              /* Each line 10 vcpu results, newline if there's more */
> >              sep =3D ((++count % 10 =3D=3D 0) && item) ? ",\n  " : ", "=
;
> >          }
> > -        monitor_printf(mon, "]\n");
> > +        monitor_hmp_printf(hmp, "]\n");
> >      }
> >
> >      if (info->has_postcopy_latency_dist) {
> >          uint64List *item =3D info->postcopy_latency_dist;
> >          int count =3D 0;
> >
> > -        monitor_printf(mon, "Postcopy Latency Distribution:\n");
> > +        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
> >
> >          while (item) {
> >              g_autofree const gchar *from =3D format_time_str(1UL << co=
unt);
> >              g_autofree const gchar *to =3D format_time_str(1UL << (cou=
nt + 1));
> >
> > -            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
> > -                           from, to, item->value);
> > +            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
> > +                               from, to, item->value);
> >              item =3D item->next;
> >              count++;
> >          }
> > @@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, =
MigrationInfo *info)
> >
> >  void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      bool show_all =3D qdict_get_try_bool(qdict, "all", false);
> >      MigrationInfo *info;
> >
> > @@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDic=
t *qdict)
> >
> >      if (info->blocked_reasons) {
> >          strList *reasons =3D info->blocked_reasons;
> > -        monitor_printf(mon, "Outgoing migration blocked:\n");
> > +        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
> >          while (reasons) {
> > -            monitor_printf(mon, "  %s\n", reasons->value);
> > +            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
> >              reasons =3D reasons->next;
> >          }
> >      }
> >
> >      if (info->has_status) {
> > -        monitor_printf(mon, "Status: \t\t%s",
> > -                       MigrationStatus_str(info->status));
> > +        monitor_hmp_printf(hmp, "Status: \t\t%s",
> > +                           MigrationStatus_str(info->status));
> >          if ((info->status =3D=3D MIGRATION_STATUS_FAILED ||
> >               info->status =3D=3D MIGRATION_STATUS_POSTCOPY_PAUSED) &&
> >              info->error_desc) {
> > -            monitor_printf(mon, " (%s)\n", info->error_desc);
> > +            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
> >          } else {
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >
> >          if (info->total_time) {
> > -            monitor_printf(mon, "Time (ms): \t\ttotal=3D%" PRIu64,
> > -                           info->total_time);
> > +            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=3D%" PRIu64,
> > +                               info->total_time);
> >              if (info->has_setup_time) {
> > -                monitor_printf(mon, ", setup=3D%" PRIu64,
> > -                               info->setup_time);
> > +                monitor_hmp_printf(hmp, ", setup=3D%" PRIu64,
> > +                                   info->setup_time);
> >              }
> >              if (info->has_expected_downtime) {
> > -                monitor_printf(mon, ", exp_down=3D%" PRIu64,
> > -                               info->expected_downtime);
> > +                monitor_hmp_printf(hmp, ", exp_down=3D%" PRIu64,
> > +                                   info->expected_downtime);
> >              }
> >              if (info->has_downtime) {
> > -                monitor_printf(mon, ", down=3D%" PRIu64,
> > -                               info->downtime);
> > +                monitor_hmp_printf(hmp, ", down=3D%" PRIu64,
> > +                                   info->downtime);
> >              }
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >      }
> >
> >      if (info->has_remaining) {
> >          g_autofree char *remaining =3D size_to_str(info->remaining);
> > -        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
> > +        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
> >      }
> >
> >      if (info->has_socket_address) {
> >          SocketAddressList *addr;
> >
> > -        monitor_printf(mon, "Sockets: [\n");
> > +        monitor_hmp_printf(hmp, "Sockets: [\n");
> >
> >          for (addr =3D info->socket_address; addr; addr =3D addr->next)=
 {
> >              char *s =3D socket_uri(addr->value);
> > -            monitor_printf(mon, "\t%s\n", s);
> > +            monitor_hmp_printf(hmp, "\t%s\n", s);
> >              g_free(s);
> >          }
> > -        monitor_printf(mon, "]\n");
> > +        monitor_hmp_printf(hmp, "]\n");
> >      }
> >
> >      if (info->ram) {
> > @@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QD=
ict *qdict)
> >          g_autofree char *str_multifd =3D size_to_str(info->ram->multif=
d_bytes);
> >          g_autofree char *str_postcopy =3D size_to_str(info->ram->postc=
opy_bytes);
> >
> > -        monitor_printf(mon, "RAM info:\n");
> > -        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
> > -                       info->ram->mbps);
> > -        monitor_printf(mon, "  Sizes: \t\tpagesize=3D%s, total=3D%s\n"=
,
> > -                       str_psize, str_total);
> > -        monitor_printf(mon, "  Transfers: \t\ttransferred=3D%s, remain=
=3D%s\n",
> > -                       str_transferred, str_remaining);
> > -        monitor_printf(mon, "    Channels: \t\tprecopy=3D%s, "
> > -                       "multifd=3D%s, postcopy=3D%s",
> > -                       str_precopy, str_multifd, str_postcopy);
> > +        monitor_hmp_printf(hmp, "RAM info:\n");
> > +        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
> > +                           info->ram->mbps);
> > +        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=3D%s, total=3D%=
s\n",
> > +                           str_psize, str_total);
> > +        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=3D%s, re=
main=3D%s\n",
> > +                           str_transferred, str_remaining);
> > +        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=3D%s, "
> > +                           "multifd=3D%s, postcopy=3D%s",
> > +                           str_precopy, str_multifd, str_postcopy);
> >
> >          if (info->vfio) {
> >              g_autofree char *str_vfio =3D size_to_str(info->vfio->tran=
sferred);
> >
> > -            monitor_printf(mon, ", vfio=3D%s", str_vfio);
> > +            monitor_hmp_printf(hmp, ", vfio=3D%s", str_vfio);
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >
> > -        monitor_printf(mon, "    Page Types: \tnormal=3D%" PRIu64
> > -                       ", zero=3D%" PRIu64 "\n",
> > -                       info->ram->normal, info->ram->duplicate);
> > -        monitor_printf(mon, "  Page Rates (pps): \ttransfer=3D%" PRIu6=
4,
> > -                       info->ram->pages_per_second);
> > +        monitor_hmp_printf(hmp, "    Page Types: \tnormal=3D%" PRIu64
> > +                           ", zero=3D%" PRIu64 "\n",
> > +                           info->ram->normal, info->ram->duplicate);
> > +        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=3D%" P=
RIu64,
> > +                           info->ram->pages_per_second);
> >          if (info->ram->dirty_pages_rate) {
> > -            monitor_printf(mon, ", dirty=3D%" PRIu64,
> > -                           info->ram->dirty_pages_rate);
> > +            monitor_hmp_printf(hmp, ", dirty=3D%" PRIu64,
> > +                               info->ram->dirty_pages_rate);
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >
> > -        monitor_printf(mon, "  Others: \t\tdirty_syncs=3D%" PRIu64,
> > -                       info->ram->dirty_sync_count);
> > +        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=3D%" PRIu64=
,
> > +                           info->ram->dirty_sync_count);
> >          if (info->ram->postcopy_requests) {
> > -            monitor_printf(mon, ", postcopy_req=3D%" PRIu64,
> > -                           info->ram->postcopy_requests);
> > +            monitor_hmp_printf(hmp, ", postcopy_req=3D%" PRIu64,
> > +                               info->ram->postcopy_requests);
> >          }
> >          if (info->ram->downtime_bytes) {
> > -            monitor_printf(mon, ", downtime_bytes=3D%" PRIu64,
> > -                           info->ram->downtime_bytes);
> > +            monitor_hmp_printf(hmp, ", downtime_bytes=3D%" PRIu64,
> > +                               info->ram->downtime_bytes);
> >          }
> >          if (info->ram->dirty_sync_missed_zero_copy) {
> > -            monitor_printf(mon, ", zerocopy_fallbacks=3D%" PRIu64,
> > -                           info->ram->dirty_sync_missed_zero_copy);
> > +            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=3D%" PRIu64,
> > +                               info->ram->dirty_sync_missed_zero_copy)=
;
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >      }
> >
> >      if (!show_all) {
> >          goto out;
> >      }
> >
> > -    migration_global_dump(mon);
> > +    migration_global_dump(hmp);
> >
> >      if (info->xbzrle_cache) {
> > -        monitor_printf(mon, "XBZRLE: size=3D%" PRIu64
> > -                       ", transferred=3D%" PRIu64
> > -                       ", pages=3D%" PRIu64
> > -                       ", miss=3D%" PRIu64 "\n"
> > -                       "  miss_rate=3D%0.2f"
> > -                       ", encode_rate=3D%0.2f"
> > -                       ", overflow=3D%" PRIu64 "\n",
> > -                       info->xbzrle_cache->cache_size,
> > -                       info->xbzrle_cache->bytes,
> > -                       info->xbzrle_cache->pages,
> > -                       info->xbzrle_cache->cache_miss,
> > -                       info->xbzrle_cache->cache_miss_rate,
> > -                       info->xbzrle_cache->encoding_rate,
> > -                       info->xbzrle_cache->overflow);
> > +        monitor_hmp_printf(hmp, "XBZRLE: size=3D%" PRIu64
> > +                           ", transferred=3D%" PRIu64
> > +                           ", pages=3D%" PRIu64
> > +                           ", miss=3D%" PRIu64 "\n"
> > +                           "  miss_rate=3D%0.2f"
> > +                           ", encode_rate=3D%0.2f"
> > +                           ", overflow=3D%" PRIu64 "\n",
> > +                           info->xbzrle_cache->cache_size,
> > +                           info->xbzrle_cache->bytes,
> > +                           info->xbzrle_cache->pages,
> > +                           info->xbzrle_cache->cache_miss,
> > +                           info->xbzrle_cache->cache_miss_rate,
> > +                           info->xbzrle_cache->encoding_rate,
> > +                           info->xbzrle_cache->overflow);
> >      }
> >
> >      if (info->has_cpu_throttle_percentage) {
> > -        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
> > -                       info->cpu_throttle_percentage);
> > +        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
> > +                           info->cpu_throttle_percentage);
> >      }
> >
> >      if (info->has_dirty_limit_throttle_time_per_round) {
> > -        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n"=
,
> > -                       info->dirty_limit_throttle_time_per_round);
> > +        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 =
"\n",
> > +                           info->dirty_limit_throttle_time_per_round);
> >      }
> >
> >      if (info->has_dirty_limit_ring_full_time) {
> > -        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n=
",
> > -                       info->dirty_limit_ring_full_time);
> > +        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64=
 "\n",
> > +                           info->dirty_limit_ring_full_time);
> >      }
> >
> > -    migration_dump_blocktime(mon, info);
> > +    migration_dump_blocktime(hmp, info);
> >  out:
> >      qapi_free_MigrationInfo(info);
> >  }
> >
> >  void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict=
)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      MigrationCapabilityStatusList *caps, *cap;
> >
> >      caps =3D qmp_query_migrate_capabilities(NULL);
> >
> >      if (caps) {
> >          for (cap =3D caps; cap; cap =3D cap->next) {
> > -            monitor_printf(mon, "%s: %s\n",
> > -                           MigrationCapability_str(cap->value->capabil=
ity),
> > -                           cap->value->state ? "on" : "off");
> > +            monitor_hmp_printf(hmp, "%s: %s\n",
> > +                               MigrationCapability_str(cap->value->cap=
ability),
> > +                               cap->value->state ? "on" : "off");
> >          }
> >      }
> >
> >      qapi_free_MigrationCapabilityStatusList(caps);
> >  }
> >
> > -static void monitor_print_cpr_exec_command(Monitor *mon, strList *args=
)
> > +static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *a=
rgs)
> >  {
> > -    monitor_printf(mon, "%s:",
> > +    monitor_hmp_printf(hmp, "%s:",
> >          MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
> >
> >      while (args) {
> > -        monitor_printf(mon, " %s", args->value);
> > +        monitor_hmp_printf(hmp, " %s", args->value);
> >          args =3D args->next;
> >      }
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >  }
> >
> >  void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      MigrationParameters *params;
> >      MigrationState *s =3D migrate_get_current();
> >
> >      params =3D qmp_query_migrate_parameters(NULL);
> >
> >      if (params) {
> > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIA=
L),
> >              params->announce_initial);
> > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
> >              params->announce_max);
> > -        monitor_printf(mon, "%s: %" PRIu64 "\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS=
),
> >              params->announce_rounds);
> > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
> >              params->announce_step);
> >          assert(params->has_throttle_trigger_threshold);
> > -        monitor_printf(mon, "%s: %u\n",
> > +        monitor_hmp_printf(hmp, "%s: %u\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGE=
R_THRESHOLD),
> >              params->throttle_trigger_threshold);
> >          assert(params->has_cpu_throttle_initial);
> > -        monitor_printf(mon, "%s: %u\n",
> > +        monitor_hmp_printf(hmp, "%s: %u\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_IN=
ITIAL),
> >              params->cpu_throttle_initial);
> >          assert(params->has_cpu_throttle_increment);
> > -        monitor_printf(mon, "%s: %u\n",
> > +        monitor_hmp_printf(hmp, "%s: %u\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_IN=
CREMENT),
> >              params->cpu_throttle_increment);
> >          assert(params->has_cpu_throttle_tailslow);
> > -        monitor_printf(mon, "%s: %s\n",
> > +        monitor_hmp_printf(hmp, "%s: %s\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TA=
ILSLOW),
> >              params->cpu_throttle_tailslow ? "on" : "off");
> >          assert(params->has_max_cpu_throttle);
> > -        monitor_printf(mon, "%s: %u\n",
> > +        monitor_hmp_printf(hmp, "%s: %u\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTL=
E),
> >              params->max_cpu_throttle);
> >          assert(params->tls_creds);
> > -        monitor_printf(mon, "%s: '%s'\n",
> > +        monitor_hmp_printf(hmp, "%s: '%s'\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
> >                         params->tls_creds->u.s);
> >          assert(params->tls_hostname);
> > -        monitor_printf(mon, "%s: '%s'\n",
> > +        monitor_hmp_printf(hmp, "%s: '%s'\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
> >                         params->tls_hostname->u.s);
> >          assert(params->tls_authz);
> > -        monitor_printf(mon, "%s: '%s'\n",
> > +        monitor_hmp_printf(hmp, "%s: '%s'\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
> >                         params->tls_authz->u.s);
> >          assert(params->has_max_bandwidth);
> > -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
> >              params->max_bandwidth);
> >          assert(params->has_avail_switchover_bandwidth);
> > -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVE=
R_BANDWIDTH),
> >              params->avail_switchover_bandwidth);
> >          assert(params->has_max_postcopy_bandwidth);
> > -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BA=
NDWIDTH),
> >              params->max_postcopy_bandwidth);
> >          assert(params->has_downtime_limit);
> > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT)=
,
> >              params->downtime_limit);
> >          assert(params->has_x_checkpoint_delay);
> > -        monitor_printf(mon, "%s: %u ms\n",
> > +        monitor_hmp_printf(hmp, "%s: %u ms\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DE=
LAY),
> >              params->x_checkpoint_delay);
> > -        monitor_printf(mon, "%s: %u\n",
> > +        monitor_hmp_printf(hmp, "%s: %u\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNEL=
S),
> >              params->multifd_channels);
> > -        monitor_printf(mon, "%s: %s\n",
> > +        monitor_hmp_printf(hmp, "%s: %s\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRES=
SION),
> >              MultiFDCompression_str(params->multifd_compression));
> >          assert(params->has_zero_page_detection);
> > -        monitor_printf(mon, "%s: %s\n",
> > +        monitor_hmp_printf(hmp, "%s: %s\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETEC=
TION),
> >              qapi_enum_lookup(&ZeroPageDetection_lookup,
> >                  params->zero_page_detection));
> > -        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SI=
ZE),
> >              params->xbzrle_cache_size);
> >
> >          if (s->has_block_bitmap_mapping) {
> >              const BitmapMigrationNodeAliasList *bmnal;
> >
> > -            monitor_printf(mon, "%s:\n",
> > -                           MigrationParameter_str(
> > -                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPIN=
G));
> > +            monitor_hmp_printf(hmp, "%s:\n",
> > +                               MigrationParameter_str(
> > +                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MA=
PPING));
> >
> >              for (bmnal =3D params->block_bitmap_mapping;
> >                   bmnal;
> > @@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp,=
 const QDict *qdict)
> >                  const BitmapMigrationNodeAlias *bmna =3D bmnal->value;
> >                  const BitmapMigrationBitmapAliasList *bmbal;
> >
> > -                monitor_printf(mon, "  '%s' -> '%s'\n",
> > -                               bmna->node_name, bmna->alias);
> > +                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
> > +                                   bmna->node_name, bmna->alias);
> >
> >                  for (bmbal =3D bmna->bitmaps; bmbal; bmbal =3D bmbal->=
next) {
> >                      const BitmapMigrationBitmapAlias *bmba =3D bmbal->=
value;
> >
> > -                    monitor_printf(mon, "    '%s' -> '%s'\n",
> > -                                   bmba->name, bmba->alias);
> > +                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
> > +                                       bmba->name, bmba->alias);
> >                  }
> >              }
> >          }
> >
> > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> >          MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_=
PERIOD),
> >          params->x_vcpu_dirty_limit_period);
> >
> > -        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
> > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMI=
T),
> >              params->vcpu_dirty_limit);
> >
> >          assert(params->has_mode);
> > -        monitor_printf(mon, "%s: %s\n",
> > +        monitor_hmp_printf(hmp, "%s: %s\n",
> >              MigrationParameter_str(MIGRATION_PARAMETER_MODE),
> >              qapi_enum_lookup(&MigMode_lookup, params->mode));
> >
> >          if (params->has_direct_io) {
> > -            monitor_printf(mon, "%s: %s\n",
> > -                           MigrationParameter_str(
> > -                               MIGRATION_PARAMETER_DIRECT_IO),
> > -                           params->direct_io ? "on" : "off");
> > +            monitor_hmp_printf(hmp, "%s: %s\n",
> > +                               MigrationParameter_str(
> > +                                   MIGRATION_PARAMETER_DIRECT_IO),
> > +                               params->direct_io ? "on" : "off");
> >          }
> >
> >          if (params->has_x_rdma_chunk_size) {
> > -            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
> > -                           MigrationParameter_str(
> > -                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
> > -                           params->x_rdma_chunk_size);
> > +            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
> > +                               MigrationParameter_str(
> > +                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SI=
ZE),
> > +                               params->x_rdma_chunk_size);
> >          }
> >
> >          assert(params->has_cpr_exec_command);
> > -        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
> > +        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
> >      }
> >
> >      qapi_free_MigrationParameters(params);
> > @@ -857,12 +854,12 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qd=
ict)
> >      if (uri_cpr) {
> >          if (migrate_mode() !=3D MIG_MODE_CPR_TRANSFER) {
> >              error_setg(&err, "-c can only be used in cpr-transfer mode=
");
> > -            hmp_handle_error(mon, err);
> > +            hmp_handle_error(hmp, err);
> >              return;
> >          }
> >
> >          if (!migrate_uri_parse(uri_cpr, &channel_cpr, &err)) {
> > -            hmp_handle_error(mon, err);
> > +            hmp_handle_error(hmp, err);
> >              return;
> >          }
> >
> > @@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdic=
t)
> >          HMPMigrationStatus *status;
> >
> >          if (!hmp->use_readline) {
> > -            monitor_printf(mon, "terminal does not allow synchronous "
> > -                           "migration, continuing detached\n");
> > +            monitor_hmp_printf(hmp, "terminal does not allow synchrono=
us "
> > +                               "migration, continuing detached\n");
> >              return;
> >          }
> >          monitor_suspend(mon);
> > diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> > index 89cc19c2431d..1834e3c1f697 100644
> > --- a/monitor/hmp-cmds.c
> > +++ b/monitor/hmp-cmds.c
> > @@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
> >
> >  void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      NameInfo *info;
> >
> >      info =3D qmp_query_name(NULL);
> >      if (info->name) {
> > -        monitor_printf(mon, "%s\n", info->name);
> > +        monitor_hmp_printf(hmp, "%s\n", info->name);
> >      }
> >      qapi_free_NameInfo(info);
> >  }
> >
> >  void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      VersionInfo *info;
> >
> >      info =3D qmp_query_version(NULL);
> >
> > -    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> > -                   info->qemu->major, info->qemu->minor, info->qemu->m=
icro,
> > -                   info->package);
> > +    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> > +                       info->qemu->major, info->qemu->minor, info->qem=
u->micro,
> > +                       info->package);
> >
> >      qapi_free_VersionInfo(info);
> >  }
> > @@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict=
)
> >
> >  void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *op =3D qdict_get_try_str(qdict, "op");
> >
> >      if (op =3D=3D NULL) {
> >          bool on =3D qsp_is_enabled();
> >
> > -        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off")=
;
> > +        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "o=
ff");
> >          return;
> >      }
> >      if (!strcmp(op, "on")) {
> > @@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QD=
ict *qdict)
> >
> >  void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int64_t cpu_index;
> >
> >      /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands=
 that
> >              use it are converted to the QAPI */
> >      cpu_index =3D qdict_get_int(qdict, "index");
> >      if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
> > -        monitor_printf(mon, "invalid CPU index\n");
> > +        monitor_hmp_printf(hmp, "invalid CPU index\n");
> >      }
> >  }
> >
> > @@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
> >
> >  void hmp_change(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *device =3D qdict_get_str(qdict, "device");
> >      const char *target =3D qdict_get_str(qdict, "target");
> >      const char *arg =3D qdict_get_try_str(qdict, "arg");
> > @@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdi=
ct)
> >
> >  #ifdef CONFIG_VNC
> >      if (strcmp(device, "vnc") =3D=3D 0) {
> > -        hmp_change_vnc(mon, device, target, arg, read_only, force, &er=
r);
> > +        hmp_change_vnc(hmp, device, target, arg, read_only, force, &er=
r);
> >      } else
> >  #endif
> >      {
> > -        hmp_change_medium(mon, device, target, arg, read_only, force, =
&err);
> > +        hmp_change_medium(hmp, device, target, arg, read_only, force, =
&err);
> >      }
> >
> >      hmp_handle_error(hmp, err);
> > @@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qd=
ict)
> >
> >  void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      IOThreadInfoList *info_list =3D qmp_query_iothreads(NULL);
> >      IOThreadInfoList *info;
> >      IOThreadInfo *value;
> >
> >      for (info =3D info_list; info; info =3D info->next) {
> >          value =3D info->value;
> > -        monitor_printf(mon, "%s:\n", value->id);
> > -        monitor_printf(mon, "  thread_id=3D%" PRId64 "\n", value->thre=
ad_id);
> > -        monitor_printf(mon, "  poll-max-ns=3D%" PRId64 "\n", value->po=
ll_max_ns);
> > -        monitor_printf(mon, "  poll-grow=3D%" PRId64 "\n", value->poll=
_grow);
> > -        monitor_printf(mon, "  poll-shrink=3D%" PRId64 "\n", value->po=
ll_shrink);
> > -        monitor_printf(mon, "  poll-weight=3D%" PRId64 "\n", value->po=
ll_weight);
> > -        monitor_printf(mon, "  aio-max-batch=3D%" PRId64 "\n",
> > -                       value->aio_max_batch);
> > +        monitor_hmp_printf(hmp, "%s:\n", value->id);
> > +        monitor_hmp_printf(hmp, "  thread_id=3D%" PRId64 "\n", value->=
thread_id);
> > +        monitor_hmp_printf(hmp, "  poll-max-ns=3D%" PRId64 "\n", value=
->poll_max_ns);
> > +        monitor_hmp_printf(hmp, "  poll-grow=3D%" PRId64 "\n", value->=
poll_grow);
> > +        monitor_hmp_printf(hmp, "  poll-shrink=3D%" PRId64 "\n", value=
->poll_shrink);
> > +        monitor_hmp_printf(hmp, "  poll-weight=3D%" PRId64 "\n", value=
->poll_weight);
> > +        monitor_hmp_printf(hmp, "  aio-max-batch=3D%" PRId64 "\n",
> > +                           value->aio_max_batch);
> >      }
> >
> >      qapi_free_IOThreadInfoList(info_list);
> > @@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QD=
ict *qdict)
> >
> >  void hmp_help(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
> > +    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
> >  }
> >
> >  void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      /*
> >       * Send an ANSI escape sequence:
> >       * "\x1b[H" - move cursor to top-left
> >       * "\x1b[2J" - clear visible screen
> >       * "\x1b[3J" - clear scrollback
> >       */
> > -    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
> > +    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
> >  }
> >
> >  void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    hmp_help_cmd(mon, "info");
> > +    hmp_help_cmd(hmp, "info");
> >  }
> >
> >  void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
> > @@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const Q=
Dict *qdict)
> >
> >  void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int i;
> >      const char *str;
> >
> > @@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict =
*qdict)
> >          if (!str) {
> >              break;
> >          }
> > -        monitor_printf(mon, "%d: '%s'\n", i, str);
> > +        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
> >          i++;
> >      }
> >  }
> > @@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdic=
t)
> >
> >  void hmp_log(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int mask;
> >      const char *items =3D qdict_get_str(qdict, "items");
> >      Error *err =3D NULL;
> > @@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
> >      } else {
> >          mask =3D qemu_str_to_log_mask(items);
> >          if (!mask) {
> > -            hmp_help_cmd(mon, "log");
> > +            hmp_help_cmd(hmp, "log");
> >              return;
> >          }
> >      }
> > @@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
> >
> >  void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      const char *device =3D qdict_get_try_str(qdict, "device");
> >
> > @@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *=
qdict)
> >      if (!gdbserver_start(device, &err)) {
> >          error_report_err(err);
> >      } else if (strcmp(device, "none") =3D=3D 0) {
> > -        monitor_printf(mon, "Disabled gdbserver\n");
> > +        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
> >      } else {
> > -        monitor_printf(mon, "Waiting for gdb connection on device '%s'=
\n",
> > -                       device);
> > +        monitor_hmp_printf(hmp, "Waiting for gdb connection on device =
'%s'\n",
> > +                           device);
> >      }
> >  }
> >
> >  void hmp_print(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int format =3D qdict_get_int(qdict, "format");
> >      hwaddr val =3D qdict_get_int(qdict, "val");
> >
> >      switch(format) {
> >      case 'o':
> > -        monitor_printf(mon, "%#" HWADDR_PRIo, val);
> > +        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
> >          break;
> >      case 'x':
> > -        monitor_printf(mon, "%#" HWADDR_PRIx, val);
> > +        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
> >          break;
> >      case 'u':
> > -        monitor_printf(mon, "%" HWADDR_PRIu, val);
> > +        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
> >          break;
> >      default:
> >      case 'd':
> > -        monitor_printf(mon, "%" HWADDR_PRId, val);
> > +        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
> >          break;
> >      case 'c':
> > -        monitor_printc(mon, val);
> > +        monitor_hmp_printc(hmp, val);
> >          break;
> >      }
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >  }
> >
> >  void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      uint32_t addr;
> >      uint16_t sum;
> >      uint32_t start =3D qdict_get_int(qdict, "start");
> > @@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
> >          sum =3D (sum >> 1) | (sum << 15);
> >          sum +=3D val;
> >      }
> > -    monitor_printf(mon, "%05d\n", sum);
> > +    monitor_hmp_printf(hmp, "%05d\n", sum);
> >  }
> >
> >  void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int size =3D qdict_get_int(qdict, "size");
> >      int addr =3D qdict_get_int(qdict, "addr");
> >      int has_index =3D qdict_haskey(qdict, "index");
> > @@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *=
qdict)
> >          suffix =3D 'l';
> >          break;
> >      }
> > -    monitor_printf(mon, "port%c[0x%04x] =3D 0x%0*x\n",
> > -                   suffix, addr, size * 2, val);
> > +    monitor_hmp_printf(hmp, "port%c[0x%04x] =3D 0x%0*x\n",
> > +                       suffix, addr, size * 2, val);
> >  }
> >
> >  void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
> > @@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict =
*qdict)
> >
> >  void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *local_err =3D NULL;
> >      const char *bootdevice =3D qdict_get_str(qdict, "bootdevice");
> >
> > @@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdi=
ct)
> >      if (local_err) {
> >          error_report_err(local_err);
> >      } else {
> > -        monitor_printf(mon, "boot device list now set to %s\n", bootde=
vice);
> > +        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bo=
otdevice);
> >      }
> >  }
> >
> > @@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdic=
t)
> >          return;
> >      }
> >
> > -    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
> > +    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
> >  }
> >  #endif
> >
> > @@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
> >
> >  void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      bool all_cpus =3D qdict_get_try_bool(qdict, "cpustate_all", false)=
;
> >      int vcpu =3D qdict_get_try_int(qdict, "vcpu", -1);
> >      CPUState *cs;
> >
> >      if (all_cpus) {
> >          CPU_FOREACH(cs) {
> > -            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
> > +            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
> >              cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
> >          }
> >      } else {
> > @@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QD=
ict *qdict)
> >
> >          if (!cs) {
> >              if (vcpu >=3D 0) {
> > -                monitor_printf(mon, "CPU#%d not available\n", vcpu);
> > +                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu=
);
> >              } else {
> > -                monitor_printf(mon, "No CPU available\n");
> > +                monitor_hmp_printf(hmp, "No CPU available\n");
> >              }
> >              return;
> >          }
> >
> > -        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
> > +        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
> >          cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
> >      }
> >  }
> > @@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDic=
t *qdict)
> >  static void memory_dump(MonitorHMP *hmp, int count, int format, int ws=
ize,
> >                          uint64_t addr, bool is_physical)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int l, line_size, i, max_digits, len;
> >      uint8_t buf[16];
> >      uint64_t v;
> > @@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int coun=
t, int format, int wsize,
> >      const bool big_endian =3D target_big_endian();
> >
> >      if (!cs && (format =3D=3D 'i' || !is_physical)) {
> > -        monitor_printf(mon, "Can not dump without CPU\n");
> > +        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
> >          return;
> >      }
> >
> >      if (format =3D=3D 'i') {
> > -        monitor_disas(mon, cs, addr, count, is_physical);
> > +        monitor_disas(hmp, cs, addr, count, is_physical);
> >          return;
> >      }
> >
> > @@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count,=
 int format, int wsize,
> >      }
> >
> >      while (len > 0) {
> > -        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
> > +        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
> >          l =3D len;
> >          if (l > line_size) {
> >              l =3D line_size;
> > @@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int coun=
t, int format, int wsize,
> >              MemTxResult r =3D address_space_read(as, addr,
> >                                                 MEMTXATTRS_UNSPECIFIED,=
 buf, l);
> >              if (r !=3D MEMTX_OK) {
> > -                monitor_printf(mon, " Cannot access memory\n");
> > +                monitor_hmp_printf(hmp, " Cannot access memory\n");
> >                  break;
> >              }
> >          } else {
> >              if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
> > -                monitor_printf(mon, " Cannot access memory\n");
> > +                monitor_hmp_printf(hmp, " Cannot access memory\n");
> >                  break;
> >              }
> >          }
> > @@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int coun=
t, int format, int wsize,
> >                  v =3D (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
> >                  break;
> >              }
> > -            monitor_printf(mon, " ");
> > +            monitor_hmp_printf(hmp, " ");
> >              switch (format) {
> >              case 'o':
> > -                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
> > +                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
> >                  break;
> >              case 'x':
> > -                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
> > +                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v)=
;
> >                  break;
> >              case 'u':
> > -                monitor_printf(mon, "%*" PRIu64, max_digits, v);
> > +                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
> >                  break;
> >              case 'd':
> > -                monitor_printf(mon, "%*" PRId64, max_digits, v);
> > +                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
> >                  break;
> >              case 'c':
> > -                monitor_printc(mon, v);
> > +                monitor_hmp_printc(hmp, v);
> >                  break;
> >              }
> >              i +=3D wsize;
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >          addr +=3D l;
> >          len -=3D l;
> >      }
> > @@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, cons=
t QDict *qdict)
> >
> >  void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      hwaddr addr =3D qdict_get_int(qdict, "addr");
> >      Error *local_err =3D NULL;
> >      MemoryRegion *mr =3D NULL;
> > @@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qd=
ict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
> > -                   " (%s) is %p\n",
> > -                   addr, mr->name, ptr);
> > +    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
> > +                       " (%s) is %p\n",
> > +                       addr, mr->name, ptr);
> >
> >      memory_region_unref(mr);
> >  }
> >
> >  void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      vaddr addr =3D qdict_get_int(qdict, "addr");
> >      CPUState *cs =3D monitor_hmp_get_cpu(hmp);
> >      TranslateForDebugResult tres;
> >
> >      if (!cs) {
> > -        monitor_printf(mon, "No cpu\n");
> > +        monitor_hmp_printf(hmp, "No cpu\n");
> >          return;
> >      }
> >
> >      if (!cpu_translate_for_debug(cs, addr, &tres)) {
> > -        monitor_printf(mon, "Unmapped\n");
> > +        monitor_hmp_printf(hmp, "Unmapped\n");
> >      } else {
> > -        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr=
);
> > +        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.phys=
addr);
> >      }
> >  }
> >
> > @@ -806,7 +786,6 @@ out:
> >
> >  void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      hwaddr addr =3D qdict_get_int(qdict, "addr");
> >      Error *local_err =3D NULL;
> >      MemoryRegion *mr =3D NULL;
> > @@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdic=
t)
> >      if (local_err) {
> >          error_report_err(local_err);
> >      } else {
> > -        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRI=
x
> > -                       " (%s) is 0x%" PRIx64 "\n",
> > -                       addr, mr->name, (uint64_t) physaddr);
> > +        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR=
_PRIx
> > +                           " (%s) is 0x%" PRIx64 "\n",
> > +                           addr, mr->name, (uint64_t) physaddr);
> >      }
> >
> >      memory_region_unref(mr);
> > diff --git a/monitor/hmp.c b/monitor/hmp.c
> > index 2484a2310dff..e5f8b9c576e0 100644
> > --- a/monitor/hmp.c
> > +++ b/monitor/hmp.c
> > @@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, boo=
l val, Error **errp)
> >      hmp->use_readline =3D val;
> >  }
> >
> > -int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > -    G_GNUC_PRINTF(2, 0);
> >  static void monitor_hmp_accept_input(Monitor *mon);
> >  static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
> >  static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp=
);
> > @@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, =
const void *data)
> >                                     monitor_hmp_get_readline,
> >                                     monitor_hmp_set_readline);
> >
> > -    moncls->vprintf =3D monitor_hmp_vprintf;
> >      moncls->accept_input =3D monitor_hmp_accept_input;
> >
> >      ucc->complete =3D monitor_hmp_complete;
> > @@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
> >      hmp->use_readline =3D true;
> >  }
> >
> > -int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > -{
> > -    g_autofree char *buf =3D g_strdup_vprintf(fmt, ap);
> > -    return monitor_puts(mon, buf);
> > -}
> > -
> >  static void monitor_hmp_accept_input(Monitor *mon)
> >  {
> >      qemu_mutex_lock(&mon->mon_lock);
> > @@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, Read=
LineFunc *readline_func,
> >          /* prompt is printed on return from the command handler */
> >          return 0;
> >      } else {
> > -        monitor_printf(&hmp->parent_obj,
> > -                       "terminal does not support password prompting\n=
");
> > +        monitor_hmp_printf(hmp, "terminal does not support password pr=
ompting\n");
> >          return -ENOTTY;
> >      }
> >  }
> > @@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
> >      return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
> >  }
> >
> > -static void help_cmd_dump_one(Monitor *mon,
> > +static void help_cmd_dump_one(MonitorHMP *mon,
> >                                const HMPCommand *cmd,
> >                                char **prefix_args,
> >                                int prefix_args_nb)
> > @@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
> >      }
> >
> >      for (i =3D 0; i < prefix_args_nb; i++) {
> > -        monitor_printf(mon, "%s ", prefix_args[i]);
> > +        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
> >      }
> > -    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->=
help);
> > +    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, c=
md->help);
> >  }
> >
> >  /* @args[@arg_index] is the valid command need to find in @cmds */
> > -static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
> > +static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
> >                            char **args, int nb_args, int arg_index)
> >  {
> >      const HMPCommand *cmd;
> > @@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMP=
Command *cmds,
> >      }
> >
> >      /* Command not found */
> > -    monitor_printf(mon, "unknown command: '");
> > +    monitor_hmp_printf(mon, "unknown command: '");
> >      for (i =3D 0; i <=3D arg_index; i++) {
> > -        monitor_printf(mon, "%s%s", args[i], i =3D=3D arg_index ? "'\n=
" : " ");
> > +        monitor_hmp_printf(mon, "%s%s", args[i], i =3D=3D arg_index ? =
"'\n" : " ");
> >      }
> >  }
> >
> > -void hmp_help_cmd(Monitor *mon, const char *name)
> > +void hmp_help_cmd(MonitorHMP *mon, const char *name)
> >  {
> >      char *args[MAX_ARGS];
> >      int nb_args =3D 0;
> > @@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
> >          /* special case for log, directly dump and return */
> >          if (!strcmp(name, "log")) {
> >              const QEMULogItem *item;
> > -            monitor_printf(mon, "Log items (comma separated):\n");
> > -            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs=
");
> > +            monitor_hmp_printf(mon, "Log items (comma separated):\n");
> > +            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all =
logs");
> >              for (item =3D qemu_log_items; item->mask !=3D 0; item++) {
> > -                monitor_printf(mon, "%-15s %s\n", item->name, item->he=
lp);
> > +                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item=
->help);
> >              }
> >  #ifdef CONFIG_TRACE_LOG
> > -            monitor_printf(mon, "trace:PATTERN   enable trace events\n=
");
> > -            monitor_printf(mon, "\nUse \"log trace:help\" to get a lis=
t of "
> > -                           "trace events.\n\n");
> > +            monitor_hmp_printf(mon, "trace:PATTERN   enable trace even=
ts\n");
> > +            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a=
 list of "
> > +                               "trace events.\n\n");
> >  #endif
> >              return;
> >          }
> > @@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
> >  static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char =
*name);
> >
> >  static G_NORETURN G_GNUC_PRINTF(2, 3)
> > -void expr_error(Monitor *mon, const char *fmt, ...)
> > +void expr_error(MonitorHMP *mon, const char *fmt, ...)
> >  {
> >      va_list ap;
> >      va_start(ap, fmt);
> > -    monitor_vprintf(mon, fmt, ap);
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_vprintf(mon, fmt, ap);
> > +    monitor_hmp_printf(mon, "\n");
> >      va_end(ap);
> >      siglongjmp(expr_env, 1);
> >  }
> > @@ -475,9 +465,9 @@ static void next(void)
> >      }
> >  }
> >
> > -static int64_t expr_sum(Monitor *mon);
> > +static int64_t expr_sum(MonitorHMP *mon);
> >
> > -static int64_t expr_unary(Monitor *mon)
> > +static int64_t expr_unary(MonitorHMP *mon)
> >  {
> >      int64_t n;
> >      char *p;
> > @@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
> >                  pch++;
> >              }
> >              *q =3D 0;
> > -            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
> > -                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
> > +            if (!gdb_get_register(mon, &reg, buf)
> > +                && get_monitor_def(mon, &reg, buf) < 0) {
> >                  expr_error(mon, "unknown register");
> >              }
> >              n =3D reg;
> > @@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
> >      return n;
> >  }
> >
> > -static int64_t expr_prod(Monitor *mon)
> > +static int64_t expr_prod(MonitorHMP *mon)
> >  {
> >      int64_t val, val2;
> >      int op;
> > @@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
> >      return val;
> >  }
> >
> > -static int64_t expr_logic(Monitor *mon)
> > +static int64_t expr_logic(MonitorHMP *mon)
> >  {
> >      int64_t val, val2;
> >      int op;
> > @@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
> >      return val;
> >  }
> >
> > -static int64_t expr_sum(Monitor *mon)
> > +static int64_t expr_sum(MonitorHMP *mon)
> >  {
> >      int64_t val, val2;
> >      int op;
> > @@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
> >      return val;
> >  }
> >
> > -static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
> > +static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
> >  {
> >      pch =3D *pp;
> >      if (sigsetjmp(expr_env, 0)) {
> > @@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, co=
nst char **pp)
> >      return 0;
> >  }
> >
> > -static int get_double(Monitor *mon, double *pval, const char **pp)
> > +static int get_double(MonitorHMP *mon, double *pval, const char **pp)
> >  {
> >      const char *p =3D *pp;
> >      char *tailp;
> > @@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval,=
 const char **pp)
> >
> >      d =3D strtod(p, &tailp);
> >      if (tailp =3D=3D p) {
> > -        monitor_printf(mon, "Number expected\n");
> > +        monitor_hmp_printf(mon, "Number expected\n");
> >          return -1;
> >      }
> >      if (d !=3D d || d - d !=3D 0) {
> >          /* NaN or infinity */
> > -        monitor_printf(mon, "Bad number\n");
> > +        monitor_hmp_printf(mon, "Bad number\n");
> >          return -1;
> >      }
> >      *pval =3D d;
> > @@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(Moni=
torHMP *hmp,
> >                                                 const char **cmdp,
> >                                                 HMPCommand *table)
> >  {
> > -    Monitor *mon =3D &hmp->parent_obj;
> >      const char *p;
> >      const HMPCommand *cmd;
> >      char cmdname[256];
> > @@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(Mo=
nitorHMP *hmp,
> >
> >      cmd =3D search_dispatch_table(table, cmdname);
> >      if (!cmd) {
> > -        monitor_printf(mon, "unknown command: '%.*s'\n",
> > -                       (int)(p - cmdp_start), cmdp_start);
> > +        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
> > +                           (int)(p - cmdp_start), cmdp_start);
> >          return NULL;
> >      }
> >      if (!cmd_available(cmd)) {
> > -        monitor_printf(mon, "Command '%.*s' not available "
> > -                            "until machine initialization has complete=
d.\n",
> > -                       (int)(p - cmdp_start), cmdp_start);
> > +        monitor_hmp_printf(hmp, "Command '%.*s' not available "
> > +                           "until machine initialization has completed=
.\n",
> > +                           (int)(p - cmdp_start), cmdp_start);
> >          return NULL;
> >      }
> >
> > @@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(Moni=
torHMP *hmp,
> >   * Else, insert command arguments into a QDict, and return it.
> >   * Note: On success, caller has to free the QDict structure.
> >   */
> > -static QDict *monitor_parse_arguments(Monitor *mon,
> > +static QDict *monitor_parse_arguments(MonitorHMP *mon,
> >                                        const char **endp,
> >                                        const HMPCommand *cmd)
> >  {
> > @@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                  if (ret < 0) {
> >                      switch (c) {
> >                      case 'F':
> > -                        monitor_printf(mon, "%s: filename expected\n",
> > -                                       cmd->name);
> > +                        monitor_hmp_printf(mon, "%s: filename expected=
\n",
> > +                                           cmd->name);
> >                          break;
> >                      case 'B':
> > -                        monitor_printf(mon, "%s: block device name exp=
ected\n",
> > -                                       cmd->name);
> > +                        monitor_hmp_printf(mon, "%s: block device name=
 expected\n",
> > +                                           cmd->name);
> >                          break;
> >                      default:
> > -                        monitor_printf(mon, "%s: string expected\n", c=
md->name);
> > +                        monitor_hmp_printf(mon, "%s: string expected\n=
", cmd->name);
> >                          break;
> >                      }
> >                      goto fail;
> > @@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> >                      }
> >                  next:
> >                      if (*p !=3D '\0' && !qemu_isspace(*p)) {
> > -                        monitor_printf(mon, "invalid char in format: '=
%c'\n",
> > -                                       *p);
> > +                        monitor_hmp_printf(mon, "invalid char in forma=
t: '%c'\n",
> > +                                           *p);
> >                          goto fail;
> >                      }
> >                      if (format < 0) {
> > @@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *=
mon,
> >                  }
> >                  /* Check if 'i' is greater than 32-bit */
> >                  if ((c =3D=3D 'i') && ((val >> 32) & 0xffffffff)) {
> > -                    monitor_printf(mon, "\'%s\' has failed: ", cmd->na=
me);
> > -                    monitor_printf(mon, "integer is for 32-bit values\=
n");
> > +                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd=
->name);
> > +                    monitor_hmp_printf(mon, "integer is for 32-bit val=
ues\n");
> >                      goto fail;
> >                  } else if (c =3D=3D 'M') {
> >                      if (val < 0) {
> > -                        monitor_printf(mon, "enter a positive value\n"=
);
> > +                        monitor_hmp_printf(mon, "enter a positive valu=
e\n");
> >                          goto fail;
> >                      }
> >                      val *=3D MiB;
> > @@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                  }
> >                  ret =3D qemu_strtosz_MiB(p, &end, &val);
> >                  if (ret < 0 || val > INT64_MAX) {
> > -                    monitor_printf(mon, "invalid size\n");
> > +                    monitor_hmp_printf(mon, "invalid size\n");
> >                      goto fail;
> >                  }
> >                  qdict_put_int(qdict, key, val);
> > @@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                      }
> >                  }
> >                  if (*p && !qemu_isspace(*p)) {
> > -                    monitor_printf(mon, "Unknown unit suffix\n");
> > +                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
> >                      goto fail;
> >                  }
> >                  qdict_put(qdict, key, qnum_from_double(val));
> > @@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                  } else if (p - beg =3D=3D 3 && !memcmp(beg, "off", p -=
 beg)) {
> >                      val =3D false;
> >                  } else {
> > -                    monitor_printf(mon, "Expected 'on' or 'off'\n");
> > +                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n"=
);
> >                      goto fail;
> >                  }
> >                  qdict_put_bool(qdict, key, val);
> > @@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                      p++;
> >                      if (c !=3D *p) {
> >                          if (!is_valid_option(p, typestr)) {
> > -                            monitor_printf(mon, "%s: unsupported optio=
n -%c\n",
> > -                                           cmd->name, *p);
> > +                            monitor_hmp_printf(mon, "%s: unsupported o=
ption -%c\n",
> > +                                               cmd->name, *p);
> >                              goto fail;
> >                          } else {
> >                              skip_key =3D 1;
> > @@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                          }
> >                          ret =3D get_str(buf, sizeof(buf), &p);
> >                          if (ret < 0) {
> > -                            monitor_printf(mon, "%s: value expected fo=
r -%c\n",
> > -                                           cmd->name, *tmp);
> > +                            monitor_hmp_printf(mon, "%s: value expecte=
d for -%c\n",
> > +                                               cmd->name, *tmp);
> >                              goto fail;
> >                          }
> >                          qdict_put_str(qdict, key, buf);
> > @@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >                  }
> >                  len =3D strlen(p);
> >                  if (len <=3D 0) {
> > -                    monitor_printf(mon, "%s: string expected\n",
> > -                                   cmd->name);
> > +                    monitor_hmp_printf(mon, "%s: string expected\n",
> > +                                       cmd->name);
> >                      goto fail;
> >                  }
> >                  qdict_put_str(qdict, key, p);
> > @@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >              break;
> >          default:
> >          bad_type:
> > -            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, =
c);
> > +            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->na=
me, c);
> >              goto fail;
> >          }
> >          g_free(key);
> > @@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mo=
n,
> >          p++;
> >      }
> >      if (*p !=3D '\0') {
> > -        monitor_printf(mon, "%s: extraneous characters at the end of l=
ine\n",
> > -                       cmd->name);
> > +        monitor_hmp_printf(mon, "%s: extraneous characters at the end =
of line\n",
> > +                           cmd->name);
> >          goto fail;
> >      }
> >
> > @@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const =
char *cmdline)
> >
> >      if (!cmd->cmd && !cmd->cmd_info_hrt) {
> >          /* FIXME: is it useful to try autoload modules here ??? */
> > -        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not avai=
lable.\n",
> > -                       (int)(cmdline - cmd_start), cmd_start);
> > +        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n"=
,
> > +                           (int)(cmdline - cmd_start), cmd_start);
> >          return;
> >      }
> >
> > -    qdict =3D monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd)=
;
> > +    qdict =3D monitor_parse_arguments(hmp, &cmdline, cmd);
> >      if (!qdict) {
> >          while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
> >              cmdline--;
> >          }
> > -        monitor_printf(&hmp->parent_obj,
> > -                       "Try \"help %.*s\" for more information\n",
> > -                       (int)(cmdline - cmd_start), cmd_start);
> > +        monitor_hmp_printf(hmp,
> > +                           "Try \"help %.*s\" for more information\n",
> > +                           (int)(cmdline - cmd_start), cmd_start);
> >          return;
> >      }
> >
> > @@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint=
8_t *buf, int size)
> >          }
> >      } else {
> >          if (size =3D=3D 0 || buf[size - 1] !=3D 0) {
> > -            monitor_printf(&hmp->parent_obj, "corrupted command\n");
> > +            monitor_hmp_printf(hmp, "corrupted command\n");
> >          } else {
> >              handle_hmp_command(hmp, (char *)buf);
> >          }
> > @@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEv=
ent event)
> >          break;
> >
> >      case CHR_EVENT_OPENED:
> > -        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
> > -                       "information\n", QEMU_VERSION);
> > +        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for mor=
e "
> > +                           "information\n", QEMU_VERSION);
> >          qemu_mutex_lock(&mon->mon_lock);
> >          hmp->reset_seen =3D 1;
> >          if (!mon->mux_out && hmp->use_readline) {
> > @@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_=
printf(void *opaque,
> >      MonitorHMP *hmp =3D opaque;
> >      va_list ap;
> >      va_start(ap, fmt);
> > -    monitor_vprintf(&hmp->parent_obj, fmt, ap);
> > +    monitor_hmp_vprintf(hmp, fmt, ap);
> >      va_end(ap);
> >  }
> >
> > diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
> > index afdda1386080..c198c12eaa00 100644
> > --- a/monitor/monitor-internal.h
> > +++ b/monitor/monitor-internal.h
> > @@ -108,12 +108,6 @@ typedef struct HMPCommand {
> >  struct MonitorClass {
> >      ObjectClass parent_class;
> >
> > -    /*
> > -     * If non-NULL, the monitor is able to print messages
> > -     * for attention of the client user
> > -     */
> > -    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
> > -        G_GNUC_PRINTF(2, 0);
> >      /*
> >       * If non-NULL, the monitor is able to send event
> >       * notifications back to the client
> > diff --git a/monitor/monitor.c b/monitor/monitor.c
> > index 8528af6f79b8..da76e6e4ac19 100644
> > --- a/monitor/monitor.c
> > +++ b/monitor/monitor.c
> > @@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
> >      return monitor_puts_locked(mon, str);
> >  }
> >
> > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> >  {
> > -    MonitorClass *moncls;
> > +    g_autofree char *buf =3D g_strdup_vprintf(fmt, ap);
> >
> >      if (!mon) {
> >          return -1;
> >      }
> >
> > -    moncls =3D MONITOR_GET_CLASS(mon);
> > -    if (!moncls->vprintf) {
> > -        return -1;
> > -    }
> > -
> > -    return moncls->vprintf(mon, fmt, ap);
> > +    return monitor_puts(MONITOR(mon), buf);
> >  }
> >
> > -int monitor_printf(Monitor *mon, const char *fmt, ...)
> > +int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
> >  {
> >      int ret;
> >
> >      va_list ap;
> >      va_start(ap, fmt);
> > -    ret =3D monitor_vprintf(mon, fmt, ap);
> > +    ret =3D monitor_hmp_vprintf(mon, fmt, ap);
> >      va_end(ap);
> >      return ret;
> >  }
> >
> > -void monitor_printc(Monitor *mon, int c)
> > +void monitor_hmp_printc(MonitorHMP *mon, int c)
> >  {
> > -    monitor_printf(mon, "'");
> > +    monitor_hmp_printf(mon, "'");
> >      switch(c) {
> >      case '\'':
> > -        monitor_printf(mon, "\\'");
> > +        monitor_hmp_printf(mon, "\\'");
> >          break;
> >      case '\\':
> > -        monitor_printf(mon, "\\\\");
> > +        monitor_hmp_printf(mon, "\\\\");
> >          break;
> >      case '\n':
> > -        monitor_printf(mon, "\\n");
> > +        monitor_hmp_printf(mon, "\\n");
> >          break;
> >      case '\r':
> > -        monitor_printf(mon, "\\r");
> > +        monitor_hmp_printf(mon, "\\r");
> >          break;
> >      default:
> >          if (c >=3D 32 && c <=3D 126) {
> > -            monitor_printf(mon, "%c", c);
> > +            monitor_hmp_printf(mon, "%c", c);
> >          } else {
> > -            monitor_printf(mon, "\\x%02x", c);
> > +            monitor_hmp_printf(mon, "\\x%02x", c);
> >          }
> >          break;
> >      }
> > -    monitor_printf(mon, "'");
> > +    monitor_hmp_printf(mon, "'");
> >  }
> >
> >  static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] =
=3D {
> > diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
> > index 5b1c678f5d89..0d718d78aef9 100644
> > --- a/net/net-hmp-cmds.c
> > +++ b/net/net-hmp-cmds.c
> > @@ -28,26 +28,25 @@
> >  #include "qemu/help_option.h"
> >  #include "qemu/option.h"
> >
> > -static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
> > +static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *=
ci)
> >  {
> >      NetFilterInfoList *f;
> >
> > -    monitor_printf(mon, "%s: index=3D%" PRIu32 ",type=3D%s,%s\n",
> > -                   ci->name, ci->queue_index,
> > -                   NetClientDriver_str(ci->type), ci->info_str);
> > +    monitor_hmp_printf(hmp, "%s: index=3D%" PRIu32 ",type=3D%s,%s\n",
> > +                       ci->name, ci->queue_index,
> > +                       NetClientDriver_str(ci->type), ci->info_str);
> >      if (ci->filters) {
> > -        monitor_printf(mon, "filters:\n");
> > +        monitor_hmp_printf(hmp, "filters:\n");
> >          for (f =3D ci->filters; f; f =3D f->next) {
> > -            monitor_printf(mon, "  - %s: type=3D%s%s%s\n",
> > -                           f->value->name, f->value->type,
> > -                           f->value->info[0] ? "," : "", f->value->inf=
o);
> > +            monitor_hmp_printf(hmp, "  - %s: type=3D%s%s%s\n",
> > +                               f->value->name, f->value->type,
> > +                               f->value->info[0] ? "," : "", f->value-=
>info);
> >          }
> >      }
> >  }
> >
> >  void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      Error *err =3D NULL;
> >      g_autoptr(NetworkInfo) info =3D qmp_x_query_network(&err);
> >      NetHubInfoList *h;
> > @@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict =
*qdict)
> >      for (h =3D info->hubs; h; h =3D h->next) {
> >          NetHubPortInfoList *p;
> >
> > -        monitor_printf(mon, "hub %d\n", (int)h->value->id);
> > +        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
> >          for (p =3D h->value->ports; p; p =3D p->next) {
> >              if (p->value->peer) {
> > -                monitor_printf(mon, " \\ %s: ", p->value->name);
> > -                hmp_print_client_info(mon, p->value->peer);
> > +                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
> > +                hmp_print_client_info(hmp, p->value->peer);
> >              } else {
> > -                monitor_printf(mon, " \\ %s\n", p->value->name);
> > +                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
> >              }
> >          }
> >      }
> > @@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict =
*qdict)
> >          NetworkClientInfo *ci =3D entry->value;
> >
> >          if (!ci->peer || ci->type =3D=3D NET_CLIENT_DRIVER_NIC) {
> > -            hmp_print_client_info(mon, ci);
> > +            hmp_print_client_info(hmp, ci);
> >          } /* else it's a netdev connected to a NIC, printed with the N=
IC */
> >          if (ci->peer && ci->type =3D=3D NET_CLIENT_DRIVER_NIC) {
> > -            monitor_printf(mon, " \\ ");
> > -            hmp_print_client_info(mon, ci->peer);
> > +            monitor_hmp_printf(hmp, " \\ ");
> > +            hmp_print_client_info(hmp, ci->peer);
> >          }
> >      }
> >  }
> > diff --git a/net/slirp.c b/net/slirp.c
> > index d5c190b48b76..6fbefa9ed1d7 100644
> > --- a/net/slirp.c
> > +++ b/net/slirp.c
> > @@ -711,22 +711,22 @@ error:
> >      return -1;
> >  }
> >
> > -static SlirpState *slirp_lookup(Monitor *mon, const char *id)
> > +static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
> >  {
> >      if (id) {
> >          NetClientState *nc =3D qemu_find_netdev(id);
> >          if (!nc) {
> > -            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
> > +            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", i=
d);
> >              return NULL;
> >          }
> >          if (strcmp(nc->model, "user")) {
> > -            monitor_printf(mon, "invalid device specified\n");
> > +            monitor_hmp_printf(hmp, "invalid device specified\n");
> >              return NULL;
> >          }
> >          return DO_UPCAST(SlirpState, nc, nc);
> >      } else {
> >          if (QTAILQ_EMPTY(&slirp_stacks)) {
> > -            monitor_printf(mon, "user mode network stack not in use\n"=
);
> > +            monitor_hmp_printf(hmp, "user mode network stack not in us=
e\n");
> >              return NULL;
> >          }
> >          return QTAILQ_FIRST(&slirp_stacks);
> > @@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const=
 char *id)
> >
> >  void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      /* TODO: support removing unix fwd */
> >      struct sockaddr_in host_addr =3D {
> >          .sin_family =3D AF_INET,
> > @@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QD=
ict *qdict)
> >      const char *arg2 =3D qdict_get_try_str(qdict, "arg2");
> >
> >      if (arg2) {
> > -        s =3D slirp_lookup(mon, arg1);
> > +        s =3D slirp_lookup(hmp, arg1);
> >          src_str =3D arg2;
> >      } else {
> > -        s =3D slirp_lookup(mon, NULL);
> > +        s =3D slirp_lookup(hmp, NULL);
> >          src_str =3D arg1;
> >      }
> >      if (!s) {
> > @@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QD=
ict *qdict)
> >      err =3D slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr,=
 host_port);
> >  #endif
> >
> > -    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
> > -                   err ? "not found" : "removed");
> > +    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_st=
r,
> > +                       err ? "not found" : "removed");
> >      return;
> >
> >   fail_syntax:
> > -    monitor_printf(mon, "invalid format\n");
> > +    monitor_hmp_printf(hmp, "invalid format\n");
> >  }
> >
> >  static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error *=
*errp)
> > @@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const cha=
r *redir_str, Error **errp)
> >
> >  void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *redir_str;
> >      SlirpState *s;
> >      const char *arg1 =3D qdict_get_str(qdict, "arg1");
> >      const char *arg2 =3D qdict_get_try_str(qdict, "arg2");
> >
> >      if (arg2) {
> > -        s =3D slirp_lookup(mon, arg1);
> > +        s =3D slirp_lookup(hmp, arg1);
> >          redir_str =3D arg2;
> >      } else {
> > -        s =3D slirp_lookup(mon, NULL);
> > +        s =3D slirp_lookup(hmp, NULL);
> >          redir_str =3D arg1;
> >      }
> >      if (s) {
> > @@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **er=
rp)
> >
> >  void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      g_autoptr(UsernetInfoList) list =3D NULL;
> >      UsernetInfoList *entry;
> >
> >      list =3D qmp_x_query_usernet(&error_abort);
> >      for (entry =3D list; entry; entry =3D entry->next) {
> >          UsernetInfo *ui =3D entry->value;
> > -        monitor_printf(mon, "Hub %d (%s):\n%s",
> > -                       ui->has_hub_id ? (int)ui->hub_id : -1,
> > -                       ui->hub_name, ui->info);
> > +        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
> > +                           ui->has_hub_id ? (int)ui->hub_id : -1,
> > +                           ui->hub_name, ui->info);
> >      }
> >  }
> >
> > diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
> > index 2e2eb33371e2..bbf5980332a4 100644
> > --- a/qom/qom-hmp-cmds.c
> > +++ b/qom/qom-hmp-cmds.c
> > @@ -20,13 +20,12 @@
> >
> >  void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *path =3D qdict_get_try_str(qdict, "path");
> >      ObjectPropertyInfoList *list;
> >      Error *err =3D NULL;
> >
> >      if (path =3D=3D NULL) {
> > -        monitor_printf(mon, "/\n");
> > +        monitor_hmp_printf(hmp, "/\n");
> >          return;
> >      }
> >
> > @@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict=
)
> >          while (list !=3D NULL) {
> >              ObjectPropertyInfo *value =3D list->value;
> >
> > -            monitor_printf(mon, "%s (%s)\n",
> > -                           value->name, value->type);
> > +            monitor_hmp_printf(hmp, "%s (%s)\n",
> > +                               value->name, value->type);
> >              list =3D list->next;
> >          }
> >          qapi_free_ObjectPropertyInfoList(start);
> > @@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
> >
> >  void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *path =3D qdict_get_str(qdict, "path");
> >      const char *property =3D qdict_get_str(qdict, "property");
> >      Error *err =3D NULL;
> > @@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
> >
> >      if (err =3D=3D NULL) {
> >          GString *str =3D qobject_to_json_pretty(obj, true);
> > -        monitor_printf(mon, "%s\n", str->str);
> > +        monitor_hmp_printf(hmp, "%s\n", str->str);
> >          g_string_free(str, true);
> >      }
> >
> > @@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
> >      int indent;
> >  } QOMCompositionState;
> >
> > -static void print_qom_composition(Monitor *mon, Object *obj, int inden=
t);
> > +static void print_qom_composition(MonitorHMP *hmp, Object *obj, int in=
dent);
> >
> >  static int qom_composition_compare(const void *a, const void *b)
> >  {
> > @@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj=
, void *opaque)
> >      return 0;
> >  }
> >
> > -static void print_qom_composition(Monitor *mon, Object *obj, int inden=
t)
> > +static void print_qom_composition(MonitorHMP *hmp, Object *obj, int in=
dent)
> >  {
> >      GArray *children =3D g_array_new(false, false, sizeof(Object *));
> >      const char *name;
> > @@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, O=
bject *obj, int indent)
> >      } else {
> >          name =3D object_get_canonical_path_component(obj);
> >      }
> > -    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
> > -                   object_get_typename(obj));
> > +    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
> > +                       object_get_typename(obj));
> >
> >      object_child_foreach(obj, insert_qom_composition_child, children);
> >      g_array_sort(children, qom_composition_compare);
> >
> >      for (i =3D 0; i < children->len; i++) {
> > -        print_qom_composition(mon, g_array_index(children, Object *, i=
),
> > +        print_qom_composition(hmp, g_array_index(children, Object *, i=
),
> >                                indent + 2);
> >      }
> >      g_array_free(children, TRUE);
> > @@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Obj=
ect *obj, int indent)
> >
> >  void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *path =3D qdict_get_try_str(dict, "path");
> >      Object *obj;
> >      bool ambiguous =3D false;
> > @@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDi=
ct *dict)
> >      if (path) {
> >          obj =3D object_resolve_path(path, &ambiguous);
> >          if (!obj) {
> > -            monitor_printf(mon, "Path '%s' could not be resolved.\n", =
path);
> > +            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\=
n", path);
> >              return;
> >          }
> >          if (ambiguous) {
> > -            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", =
path);
> > +            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\=
n", path);
> >              return;
> >          }
> >      } else {
> >          obj =3D qdev_get_machine();
> >      }
> > -    print_qom_composition(mon, obj, 0);
> > +    print_qom_composition(hmp, obj, 0);
> >  }
> >
> >  void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
> > diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
> > index ef69d23ff507..965565715ef2 100644
> > --- a/replay/replay-debugging.c
> > +++ b/replay/replay-debugging.c
> > @@ -33,11 +33,10 @@ bool replay_running_debug(void)
> >
> >  void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      if (replay_mode =3D=3D REPLAY_MODE_NONE) {
> > -        monitor_printf(mon, "Record/replay is not active\n");
> > +        monitor_hmp_printf(hmp, "Record/replay is not active\n");
> >      } else {
> > -        monitor_printf(mon,
> > +        monitor_hmp_printf(hmp,
> >              "%s execution '%s': instruction count =3D %"PRId64"\n",
> >              replay_mode =3D=3D REPLAY_MODE_RECORD ? "Recording" : "Rep=
laying",
> >              replay_get_filename(), replay_get_current_icount());
> > diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
> > index cd1f1deb58bc..3d556c745d61 100644
> > --- a/stats/stats-hmp-cmds.c
> > +++ b/stats/stats-hmp-cmds.c
> > @@ -14,11 +14,11 @@
> >  #include "qobject/qdict.h"
> >  #include "qapi/error.h"
> >
> > -static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *v=
alue)
> > +static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue=
 *value)
> >  {
> >      const char *unit =3D NULL;
> > -    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(val=
ue->type),
> > -                   value->has_unit || value->exponent ? ", " : "");
> > +    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str=
(value->type),
> > +                       value->has_unit || value->exponent ? ", " : "")=
;
> >
> >      if (value->has_unit) {
> >          if (value->unit =3D=3D STATS_UNIT_SECONDS) {
> > @@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, =
StatsSchemaValue *value)
> >      if (unit && value->base =3D=3D 10 &&
> >          value->exponent >=3D -18 && value->exponent <=3D 18 &&
> >          value->exponent % 3 =3D=3D 0) {
> > -        monitor_puts(mon, si_prefix(value->exponent));
> > +        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
> >      } else if (unit && value->base =3D=3D 2 &&
> >                 value->exponent >=3D 0 && value->exponent <=3D 60 &&
> >                 value->exponent % 10 =3D=3D 0) {
> >
> > -        monitor_puts(mon, iec_binary_prefix(value->exponent));
> > +        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent))=
;
> >      } else if (value->exponent) {
> >          /* Use exponential notation and write the unit's English name =
*/
> > -        monitor_printf(mon, "* %d^%d%s",
> > -                       value->base, value->exponent,
> > -                       value->has_unit ? " " : "");
> > +        monitor_hmp_printf(hmp, "* %d^%d%s",
> > +                           value->base, value->exponent,
> > +                           value->has_unit ? " " : "");
> >          unit =3D NULL;
> >      }
> >
> >      if (value->has_unit) {
> > -        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
> > +        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->=
unit));
> >      }
> >
> >      /* Print bucket size for linear histograms */
> >      if (value->type =3D=3D STATS_TYPE_LINEAR_HISTOGRAM && value->has_b=
ucket_size) {
> > -        monitor_printf(mon, ", bucket size=3D%d", value->bucket_size);
> > +        monitor_hmp_printf(hmp, ", bucket size=3D%d", value->bucket_si=
ze);
> >      }
> > -    monitor_printf(mon, ")");
> > +    monitor_hmp_printf(hmp, ")");
> >  }
> >
> >  static StatsSchemaValueList *find_schema_value_list(
> > @@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
> >      return NULL;
> >  }
> >
> > -static void print_stats_results(Monitor *mon, StatsTarget target,
> > +static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
> >                                  bool show_provider,
> >                                  StatsResult *result,
> >                                  StatsSchemaList *schema)
> > @@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, Stats=
Target target,
> >      StatsList *stats_list;
> >
> >      if (!schema_value_list) {
> > -        monitor_printf(mon, "failed to find schema list for %s\n",
> > -                       StatsProvider_str(result->provider));
> > +        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
> > +                           StatsProvider_str(result->provider));
> >          return;
> >      }
> >
> >      if (show_provider) {
> > -        monitor_printf(mon, "provider: %s\n",
> > -                       StatsProvider_str(result->provider));
> > +        monitor_hmp_printf(hmp, "provider: %s\n",
> > +                           StatsProvider_str(result->provider));
> >      }
> >
> >      for (stats_list =3D result->stats; stats_list;
> > @@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, Sta=
tsTarget target,
> >          /* Find schema entry */
> >          while (!g_str_equal(stats->name, schema_value->name)) {
> >              if (!schema_value_list->next) {
> > -                monitor_printf(mon, "failed to find schema entry for %=
s\n",
> > -                               stats->name);
> > +                monitor_hmp_printf(hmp, "failed to find schema entry f=
or %s\n",
> > +                                   stats->name);
> >                  return;
> >              }
> >              schema_value_list =3D schema_value_list->next;
> >              schema_value =3D schema_value_list->value;
> >          }
> >
> > -        print_stats_schema_value(mon, schema_value);
> > +        print_stats_schema_value(hmp, schema_value);
> >
> >          if (stats_value->type =3D=3D QTYPE_QNUM) {
> > -            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scal=
ar);
> > +            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.=
scalar);
> >          } else if (stats_value->type =3D=3D QTYPE_QBOOL) {
> > -            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "ye=
s" : "no");
> > +            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ?=
 "yes" : "no");
> >          } else if (stats_value->type =3D=3D QTYPE_QLIST) {
> >              uint64List *list;
> >              int i;
> >
> > -            monitor_printf(mon, ": ");
> > +            monitor_hmp_printf(hmp, ": ");
> >              for (list =3D stats_value->u.list, i =3D 1;
> >                   list;
> >                   list =3D list->next, i++) {
> > -                monitor_printf(mon, "[%d]=3D%" PRId64 " ", i, list->va=
lue);
> > +                monitor_hmp_printf(hmp, "[%d]=3D%" PRId64 " ", i, list=
->value);
> >              }
> > -            monitor_printf(mon, "\n");
> > +            monitor_hmp_printf(hmp, "\n");
> >          }
> >      }
> >  }
> > @@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target=
, const char *names,
> >
> >  void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *target_str =3D qdict_get_str(qdict, "target");
> >      const char *provider_str =3D qdict_get_try_str(qdict, "provider");
> >      const char *names =3D qdict_get_try_str(qdict, "names");
> > @@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict =
*qdict)
> >
> >      target =3D qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &e=
rr);
> >      if (err) {
> > -        monitor_printf(mon, "invalid stats target %s\n", target_str);
> > +        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_st=
r);
> >          goto exit_no_print;
> >      }
> >      if (provider_str) {
> >          provider =3D qapi_enum_parse(&StatsProvider_lookup, provider_s=
tr, -1, &err);
> >          if (err) {
> > -            monitor_printf(mon, "invalid stats provider %s\n", provide=
r_str);
> > +            monitor_hmp_printf(hmp, "invalid stats provider %s\n", pro=
vider_str);
> >              goto exit_no_print;
> >          }
> >      }
> > @@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict =
*qdict)
> >          goto exit;
> >      }
> >      for (entry =3D stats; entry; entry =3D entry->next) {
> > -        print_stats_results(mon, target, provider_str =3D=3D NULL, ent=
ry->value, schema);
> > +        print_stats_results(hmp, target, provider_str =3D=3D NULL, ent=
ry->value, schema);
> >      }
> >
> >  exit:
> >      if (err) {
> > -        monitor_printf(mon, "%s\n", error_get_pretty(err));
> > +        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
> >      }
> >  exit_no_print:
> >      error_free(err);
> > diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
> > index 6f2b87d1ad10..c9c1d10c165c 100644
> > --- a/stubs/hmp-cmd-info_sev.c
> > +++ b/stubs/hmp-cmd-info_sev.c
> > @@ -12,6 +12,5 @@
> >
> >  void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> > -    monitor_printf(mon, "SEV is not available in this QEMU\n");
> > +    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
> >  }
> > diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
> > index b0c7002bd406..094b80721003 100644
> > --- a/stubs/monitor-core.c
> > +++ b/stubs/monitor-core.c
> > @@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
> >  {
> >  }
> >
> > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> >  {
> >      /*
> >       * Pretend 'g_test_message' is our monitor console to
> > diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.=
c
> > index 75194add7931..fb9338e9aef6 100644
> > --- a/system/dirtylimit-hmp-cmds.c
> > +++ b/system/dirtylimit-hmp-cmds.c
> > @@ -17,7 +17,6 @@
> >
> >  void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      int64_t cpu_index =3D qdict_get_try_int(qdict, "cpu_index", -1);
> >      Error *err =3D NULL;
> >
> > @@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, con=
st QDict *qdict)
> >          return;
> >      }
> >
> > -    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query =
"
> > -                   "dirty limit for virtual CPU]\n");
> > +    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to qu=
ery "
> > +                       "dirty limit for virtual CPU]\n");
> >  }
> >
> >  void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> > @@ -50,13 +49,12 @@ out:
> >
> >  void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      DirtyLimitInfoList *info;
> >      g_autoptr(DirtyLimitInfoList) head =3D NULL;
> >      Error *err =3D NULL;
> >
> >      if (!dirtylimit_in_service()) {
> > -        monitor_printf(mon, "Dirty page limit not enabled!\n");
> > +        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
> >          return;
> >      }
> >
> > @@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const=
 QDict *qdict)
> >      }
> >
> >      for (info =3D head; info !=3D NULL; info =3D info->next) {
> > -        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (M=
B/s),"
> > +        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 =
" (MB/s),"
> >                              " current rate %"PRIi64 " (MB/s)\n",
> >                              info->value->cpu_index,
> >                              info->value->limit_rate,
> > diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> > index 5c2de2f53cc9..3860ada2a237 100644
> > --- a/system/qdev-monitor.c
> > +++ b/system/qdev-monitor.c
> > @@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error=
 **errp)
> >      return ret;
> >  }
> >
> > -#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "=
", ## __VA_ARGS__)
> > +#define qdev_printf(fmt, ...) \
> > +    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
> >
> > -static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceCla=
ss *dc,
> > +static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, Device=
Class *dc,
> >                               int indent)
> >  {
> >      for (int i =3D 0, n =3D dc->props_count_; i < n; ++i) {
> > @@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *m=
on, DeviceState *dev, int ind
> >      }
> >  }
> >
> > -static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
> > +static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
> >  {
> > +    Monitor *mon =3D MONITOR(hmp);
> >      ObjectClass *class;
> >      NamedGPIOList *ngl;
> >      NamedClockList *ncl;
> > @@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState =
*dev, int indent)
> >      }
> >      class =3D object_get_class(OBJECT(dev));
> >      do {
> > -        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
> > +        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
> >          class =3D object_class_get_parent(class);
> >      } while (class !=3D object_class_by_name(TYPE_DEVICE));
> >      bus_print_dev(dev->parent_bus, mon, dev, indent);
> >  }
> >
> > -static void qbus_print(Monitor *mon, BusState *bus, int indent, bool d=
etails)
> > +static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, boo=
l details)
> >  {
> >      BusChild *kid;
> >
> > @@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bu=
s, int indent, bool details)
> >          qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT=
(dev)),
> >                      dev->id ? dev->id : "");
> >          if (details) {
> > -            qdev_print(mon, dev, indent + 2);
> > +            qdev_print(hmp, dev, indent + 2);
> >          }
> >          QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
> > -            qbus_print(mon, child_bus, indent + 2, details);
> > +            qbus_print(hmp, child_bus, indent + 2, details);
> >          }
> >      }
> >  }
> > @@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bu=
s, int indent, bool details)
> >
> >  void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      bool details =3D !qdict_get_try_bool(qdict, "brief", false);
> >
> >      if (sysbus_get_default()) {
> > -        qbus_print(mon, sysbus_get_default(), 0, details);
> > +        qbus_print(hmp, sysbus_get_default(), 0, details);
> >      }
> >  }
> >
> > diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
> > index 051ee45ee74c..ad70b53f8abf 100644
> > --- a/system/runstate-hmp-cmds.c
> > +++ b/system/runstate-hmp-cmds.c
> > @@ -25,33 +25,31 @@
> >
> >  void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      StatusInfo *info;
> >
> >      info =3D qmp_query_status(NULL);
> >
> > -    monitor_printf(mon, "VM status: %s",
> > -                   info->running ? "running" : "paused");
> > +    monitor_hmp_printf(hmp, "VM status: %s",
> > +                       info->running ? "running" : "paused");
> >
> >      if (!info->running && info->status !=3D RUN_STATE_PAUSED) {
> > -        monitor_printf(mon, " (%s)", RunState_str(info->status));
> > +        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
> >      }
> >
> > -    monitor_printf(mon, "\n");
> > +    monitor_hmp_printf(hmp, "\n");
> >
> >      qapi_free_StatusInfo(info);
> >  }
> >
> >  void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *option =3D qdict_get_try_str(qdict, "option");
> >      AccelState *accel =3D current_accel();
> >      bool newval;
> >
> >      if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
> > -        monitor_printf(mon,
> > -                       "This accelerator does not support setting one-=
insn-per-tb\n");
> > +        monitor_hmp_printf(hmp,
> > +                           "This accelerator does not support setting =
one-insn-per-tb\n");
> >          return;
> >      }
> >
> > @@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict=
 *qdict)
> >      } else if (!strcmp(option, "off")) {
> >          newval =3D false;
> >      } else {
> > -        monitor_printf(mon, "unexpected option %s\n", option);
> > +        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
> >          return;
> >      }
> >      /* If the property exists then setting it can never fail */
> > diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
> > index 094c3f16cf50..35406e24d2c3 100644
> > --- a/system/tpm-hmp-cmds.c
> > +++ b/system/tpm-hmp-cmds.c
> > @@ -13,7 +13,6 @@
> >
> >  void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >  #ifdef CONFIG_TPM
> >      TPMInfoList *info_list, *info;
> >      Error *err =3D NULL;
> > @@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdi=
ct)
> >
> >      info_list =3D qmp_query_tpm(&err);
> >      if (err) {
> > -        monitor_printf(mon, "TPM device not supported\n");
> > +        monitor_hmp_printf(hmp, "TPM device not supported\n");
> >          error_free(err);
> >          return;
> >      }
> >
> >      if (info_list) {
> > -        monitor_printf(mon, "TPM device:\n");
> > +        monitor_hmp_printf(hmp, "TPM device:\n");
> >      }
> >
> >      for (info =3D info_list; info; info =3D info->next) {
> >          TPMInfo *ti =3D info->value;
> > -        monitor_printf(mon, " tpm%d: model=3D%s\n",
> > -                       c, TpmModel_str(ti->model));
> > +        monitor_hmp_printf(hmp, " tpm%d: model=3D%s\n",
> > +                           c, TpmModel_str(ti->model));
> >
> > -        monitor_printf(mon, "  \\ %s: type=3D%s",
> > -                       ti->id, TpmType_str(ti->options->type));
> > +        monitor_hmp_printf(hmp, "  \\ %s: type=3D%s",
> > +                           ti->id, TpmType_str(ti->options->type));
> >
> >          switch (ti->options->type) {
> >          case TPM_TYPE_PASSTHROUGH:
> >              tpo =3D ti->options->u.passthrough.data;
> > -            monitor_printf(mon, "%s%s%s%s",
> > -                           tpo->path ? ",path=3D" : "",
> > -                           tpo->path ?: "",
> > -                           tpo->cancel_path ? ",cancel-path=3D" : "",
> > -                           tpo->cancel_path ?: "");
> > +            monitor_hmp_printf(hmp, "%s%s%s%s",
> > +                               tpo->path ? ",path=3D" : "",
> > +                               tpo->path ?: "",
> > +                               tpo->cancel_path ? ",cancel-path=3D" : =
"",
> > +                               tpo->cancel_path ?: "");
> >              break;
> >          case TPM_TYPE_EMULATOR:
> >              teo =3D ti->options->u.emulator.data;
> > -            monitor_printf(mon, ",chardev=3D%s", teo->chardev);
> > +            monitor_hmp_printf(hmp, ",chardev=3D%s", teo->chardev);
> >              break;
> >          case TPM_TYPE__MAX:
> >              break;
> >          }
> > -        monitor_printf(mon, "\n");
> > +        monitor_hmp_printf(hmp, "\n");
> >          c++;
> >      }
> >      qapi_free_TPMInfoList(info_list);
> >  #else
> > -    monitor_printf(mon, "TPM device not supported\n");
> > +    monitor_hmp_printf(hmp, "TPM device not supported\n");
> >  #endif /* CONFIG_TPM */
> >  }
> > diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
> > index 3ae20f004b64..5d69ece15034 100644
> > --- a/target/i386/cpu-apic.c
> > +++ b/target/i386/cpu-apic.c
> > @@ -82,7 +82,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
> >
> >  void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUState *cs;
> >
> >      if (qdict_haskey(qdict, "apic-id")) {
> > @@ -98,7 +97,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict=
 *qdict)
> >
> >
> >      if (!cs) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >      x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
> > diff --git a/target/i386/monitor.c b/target/i386/monitor.c
> > index 72bcab131f77..46762540ba65 100644
> > --- a/target/i386/monitor.c
> > +++ b/target/i386/monitor.c
> > @@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwa=
ddr addr)
> >      return addr;
> >  }
> >
> > -static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
> > +static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
> >                        hwaddr pte, hwaddr mask)
> >  {
> >      addr =3D addr_canonical(env, addr);
> >
> > -    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
> > -                   " %c%c%c%c%c%c%c%c%c\n",
> > -                   addr,
> > -                   pte & mask,
> > -                   pte & PG_NX_MASK ? 'X' : '-',
> > -                   pte & PG_GLOBAL_MASK ? 'G' : '-',
> > -                   pte & PG_PSE_MASK ? 'P' : '-',
> > -                   pte & PG_DIRTY_MASK ? 'D' : '-',
> > -                   pte & PG_ACCESSED_MASK ? 'A' : '-',
> > -                   pte & PG_PCD_MASK ? 'C' : '-',
> > -                   pte & PG_PWT_MASK ? 'T' : '-',
> > -                   pte & PG_USER_MASK ? 'U' : '-',
> > -                   pte & PG_RW_MASK ? 'W' : '-');
> > +    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
> > +                       " %c%c%c%c%c%c%c%c%c\n",
> > +                       addr,
> > +                       pte & mask,
> > +                       pte & PG_NX_MASK ? 'X' : '-',
> > +                       pte & PG_GLOBAL_MASK ? 'G' : '-',
> > +                       pte & PG_PSE_MASK ? 'P' : '-',
> > +                       pte & PG_DIRTY_MASK ? 'D' : '-',
> > +                       pte & PG_ACCESSED_MASK ? 'A' : '-',
> > +                       pte & PG_PCD_MASK ? 'C' : '-',
> > +                       pte & PG_PWT_MASK ? 'T' : '-',
> > +                       pte & PG_USER_MASK ? 'U' : '-',
> > +                       pte & PG_RW_MASK ? 'W' : '-');
> >  }
> >
> > -static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace =
*as)
> > +static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpa=
ce *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      unsigned int l1, l2;
> > @@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState =
*env, AddressSpace *as)
> >          if (pde & PG_PRESENT_MASK) {
> >              if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
> >                  /* 4M pages */
> > -                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1))=
;
> > +                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1))=
;
> >              } else {
> >                  for(l2 =3D 0; l2 < 1024; l2++) {
> >                      pte =3D address_space_ldl_le(as, (pde & ~0xfff) + =
l2 * 4,
> >                                                 attrs, NULL);
> >                      if (pte & PG_PRESENT_MASK) {
> > -                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
> > +                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
> >                                    pte & ~PG_PSE_MASK,
> >                                    ~0xfff);
> >                      }
> > @@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *e=
nv, AddressSpace *as)
> >      }
> >  }
> >
> > -static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpa=
ce *as)
> > +static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, Address=
Space *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      unsigned int l1, l2, l3;
> > @@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchSta=
te *env, AddressSpace *as)
> >                  if (pde & PG_PRESENT_MASK) {
> >                      if (pde & PG_PSE_MASK) {
> >                          /* 2M pages with PAE, CR4.PSE is ignored */
> > -                        print_pte(mon, env, (l1 << 30) + (l2 << 21), p=
de,
> > +                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), p=
de,
> >                                    ~((hwaddr)(1 << 20) - 1));
> >                      } else {
> >                          pt_addr =3D pde & 0x3fffffffff000ULL;
> > @@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchSta=
te *env, AddressSpace *as)
> >                              pte =3D address_space_ldq_le(as, pt_addr +=
 l3 * 8,
> >                                                         attrs, NULL);
> >                              if (pte & PG_PRESENT_MASK) {
> > -                                print_pte(mon, env, (l1 << 30) + (l2 <=
< 21)
> > +                                print_pte(hmp, env, (l1 << 30) + (l2 <=
< 21)
> >                                            + (l3 << 12),
> >                                            pte & ~PG_PSE_MASK,
> >                                            ~(hwaddr)0xfff);
> > @@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchSta=
te *env, AddressSpace *as)
> >  }
> >
> >  #ifdef TARGET_X86_64
> > -static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpac=
e *as,
> > +static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressS=
pace *as,
> >          uint64_t l0, uint64_t pml4_addr)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> > @@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as,
> >
> >              if (pdpe & PG_PSE_MASK) {
> >                  /* 1G pages, CR4.PSE is ignored */
> > -                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 3=
0),
> > +                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 3=
0),
> >                          pdpe, 0x3ffffc0000000ULL);
> >                  continue;
> >              }
> > @@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as,
> >
> >                  if (pde & PG_PSE_MASK) {
> >                      /* 2M pages, CR4.PSE is ignored */
> > -                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 =
<< 30) +
> > +                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 =
<< 30) +
> >                              (l3 << 21), pde, 0x3ffffffe00000ULL);
> >                      continue;
> >                  }
> > @@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as,
> >                      pte =3D address_space_ldq_le(as, pt_addr + l4 * 8,
> >                                                 attrs, NULL);
> >                      if (pte & PG_PRESENT_MASK) {
> > -                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
> > +                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
> >                                  (l2 << 30) + (l3 << 21) + (l4 << 12),
> >                                  pte & ~PG_PSE_MASK, 0x3fffffffff000ULL=
);
> >                      }
> > @@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as,
> >      }
> >  }
> >
> > -static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpac=
e *as)
> > +static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressS=
pace *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      uint64_t l0;
> > @@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >      for (l0 =3D 0; l0 < 512; l0++) {
> >          pml5e =3D address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, =
NULL);
> >          if (pml5e & PG_PRESENT_MASK) {
> > -            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL=
);
> > +            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL=
);
> >          }
> >      }
> >  }
> > @@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchSt=
ate *env, AddressSpace *as)
> >
> >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env;
> >      AddressSpace *as;
> >
> >      env =3D monitor_hmp_get_cpu_env(hmp);
> >      if (!env) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >
> >      if (!(env->cr[0] & CR0_PG_MASK)) {
> > -        monitor_printf(mon, "PG disabled\n");
> > +        monitor_hmp_printf(hmp, "PG disabled\n");
> >          return;
> >      }
> >      as =3D cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
> > @@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *q=
dict)
> >  #ifdef TARGET_X86_64
> >          if (env->hflags & HF_LMA_MASK) {
> >              if (env->cr[4] & CR4_LA57_MASK) {
> > -                tlb_info_la57(mon, env, as);
> > +                tlb_info_la57(hmp, env, as);
> >              } else {
> > -                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffff=
ff000ULL);
> > +                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffff=
ff000ULL);
> >              }
> >          } else
> >  #endif
> >          {
> > -            tlb_info_pae32(mon, env, as);
> > +            tlb_info_pae32(hmp, env, as);
> >          }
> >      } else {
> > -        tlb_info_32(mon, env, as);
> > +        tlb_info_32(hmp, env, as);
> >      }
> >  }
> >
> > -static void mem_print(Monitor *mon, CPUArchState *env,
> > +static void mem_print(MonitorHMP *hmp, CPUArchState *env,
> >                        hwaddr *pstart, int *plast_prot,
> >                        hwaddr end, int prot)
> >  {
> > @@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState =
*env,
> >      prot1 =3D *plast_prot;
> >      if (prot !=3D prot1) {
> >          if (*pstart !=3D -1) {
> > -            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
> > -                           HWADDR_FMT_plx " %c%c%c\n",
> > -                           addr_canonical(env, *pstart),
> > -                           addr_canonical(env, end),
> > -                           addr_canonical(env, end - *pstart),
> > -                           prot1 & PG_USER_MASK ? 'u' : '-',
> > -                           'r',
> > -                           prot1 & PG_RW_MASK ? 'w' : '-');
> > +            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx =
" "
> > +                               HWADDR_FMT_plx " %c%c%c\n",
> > +                               addr_canonical(env, *pstart),
> > +                               addr_canonical(env, end),
> > +                               addr_canonical(env, end - *pstart),
> > +                               prot1 & PG_USER_MASK ? 'u' : '-',
> > +                               'r',
> > +                               prot1 & PG_RW_MASK ? 'w' : '-');
> >          }
> >          if (prot !=3D 0)
> >              *pstart =3D end;
> > @@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *e=
nv,
> >      }
> >  }
> >
> > -static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace =
*as)
> > +static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpa=
ce *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      unsigned int l1, l2;
> > @@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState =
*env, AddressSpace *as)
> >          if (pde & PG_PRESENT_MASK) {
> >              if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
> >                  prot =3D pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT=
_MASK);
> > -                mem_print(mon, env, &start, &last_prot, end, prot);
> > +                mem_print(hmp, env, &start, &last_prot, end, prot);
> >              } else {
> >                  for(l2 =3D 0; l2 < 1024; l2++) {
> >                      pte =3D address_space_ldl_le(as, (pde & ~0xfff) + =
l2 * 4,
> > @@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                      } else {
> >                          prot =3D 0;
> >                      }
> > -                    mem_print(mon, env, &start, &last_prot, end, prot)=
;
> > +                    mem_print(hmp, env, &start, &last_prot, end, prot)=
;
> >                  }
> >              }
> >          } else {
> >              prot =3D 0;
> > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> >          }
> >      }
> >      /* Flush last range */
> > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> >  }
> >
> > -static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpa=
ce *as)
> > +static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, Address=
Space *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      unsigned int l1, l2, l3;
> > @@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchSta=
te *env, AddressSpace *as)
> >                      if (pde & PG_PSE_MASK) {
> >                          prot =3D pde & (PG_USER_MASK | PG_RW_MASK |
> >                                        PG_PRESENT_MASK);
> > -                        mem_print(mon, env, &start, &last_prot, end, p=
rot);
> > +                        mem_print(hmp, env, &start, &last_prot, end, p=
rot);
> >                      } else {
> >                          pt_addr =3D pde & 0x3fffffffff000ULL;
> >                          for (l3 =3D 0; l3 < 512; l3++) {
> > @@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchS=
tate *env, AddressSpace *as)
> >                              } else {
> >                                  prot =3D 0;
> >                              }
> > -                            mem_print(mon, env, &start, &last_prot, en=
d, prot);
> > +                            mem_print(hmp, env, &start, &last_prot, en=
d, prot);
> >                          }
> >                      }
> >                  } else {
> >                      prot =3D 0;
> > -                    mem_print(mon, env, &start, &last_prot, end, prot)=
;
> > +                    mem_print(hmp, env, &start, &last_prot, end, prot)=
;
> >                  }
> >              }
> >          } else {
> >              prot =3D 0;
> > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> >          }
> >      }
> >      /* Flush last range */
> > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> >  }
> >
> >
> >  #ifdef TARGET_X86_64
> > -static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpac=
e *as)
> > +static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressS=
pace *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      int prot, last_prot;
> > @@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                          prot =3D pdpe & (PG_USER_MASK | PG_RW_MASK |
> >                                         PG_PRESENT_MASK);
> >                          prot &=3D pml4e;
> > -                        mem_print(mon, env, &start, &last_prot, end, p=
rot);
> > +                        mem_print(hmp, env, &start, &last_prot, end, p=
rot);
> >                      } else {
> >                          pd_addr =3D pdpe & 0x3fffffffff000ULL;
> >                          for (l3 =3D 0; l3 < 512; l3++) {
> > @@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                                      prot =3D pde & (PG_USER_MASK | PG_=
RW_MASK |
> >                                                    PG_PRESENT_MASK);
> >                                      prot &=3D pml4e & pdpe;
> > -                                    mem_print(mon, env, &start,
> > +                                    mem_print(hmp, env, &start,
> >                                                &last_prot, end, prot);
> >                                  } else {
> >                                      pt_addr =3D pde & 0x3fffffffff000U=
LL;
> > @@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchSt=
ate *env, AddressSpace *as)
> >                                          } else {
> >                                              prot =3D 0;
> >                                          }
> > -                                        mem_print(mon, env, &start,
> > +                                        mem_print(hmp, env, &start,
> >                                                    &last_prot, end, pro=
t);
> >                                      }
> >                                  }
> >                              } else {
> >                                  prot =3D 0;
> > -                                mem_print(mon, env, &start,
> > +                                mem_print(hmp, env, &start,
> >                                            &last_prot, end, prot);
> >                              }
> >                          }
> >                      }
> >                  } else {
> >                      prot =3D 0;
> > -                    mem_print(mon, env, &start, &last_prot, end, prot)=
;
> > +                    mem_print(hmp, env, &start, &last_prot, end, prot)=
;
> >                  }
> >              }
> >          } else {
> >              prot =3D 0;
> > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> >          }
> >      }
> >      /* Flush last range */
> > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
> > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
> >  }
> >
> > -static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpac=
e *as)
> > +static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressS=
pace *as)
> >  {
> >      const MemTxAttrs attrs =3D MEMTXATTRS_UNSPECIFIED;
> >      int prot, last_prot;
> > @@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >          end =3D l0 << 48;
> >          if (!(pml5e & PG_PRESENT_MASK)) {
> >              prot =3D 0;
> > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> >              continue;
> >          }
> >
> > @@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >              end =3D (l0 << 48) + (l1 << 39);
> >              if (!(pml4e & PG_PRESENT_MASK)) {
> >                  prot =3D 0;
> > -                mem_print(mon, env, &start, &last_prot, end, prot);
> > +                mem_print(hmp, env, &start, &last_prot, end, prot);
> >                  continue;
> >              }
> >
> > @@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                  end =3D (l0 << 48) + (l1 << 39) + (l2 << 30);
> >                  if (pdpe & PG_PRESENT_MASK) {
> >                      prot =3D 0;
> > -                    mem_print(mon, env, &start, &last_prot, end, prot)=
;
> > +                    mem_print(hmp, env, &start, &last_prot, end, prot)=
;
> >                      continue;
> >                  }
> >
> > @@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                      prot =3D pdpe & (PG_USER_MASK | PG_RW_MASK |
> >                              PG_PRESENT_MASK);
> >                      prot &=3D pml5e & pml4e;
> > -                    mem_print(mon, env, &start, &last_prot, end, prot)=
;
> > +                    mem_print(hmp, env, &start, &last_prot, end, prot)=
;
> >                      continue;
> >                  }
> >
> > @@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                      end =3D (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3=
 << 21);
> >                      if (pde & PG_PRESENT_MASK) {
> >                          prot =3D 0;
> > -                        mem_print(mon, env, &start, &last_prot, end, p=
rot);
> > +                        mem_print(hmp, env, &start, &last_prot, end, p=
rot);
> >                          continue;
> >                      }
> >
> > @@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchStat=
e *env, AddressSpace *as)
> >                          prot =3D pde & (PG_USER_MASK | PG_RW_MASK |
> >                                  PG_PRESENT_MASK);
> >                          prot &=3D pml5e & pml4e & pdpe;
> > -                        mem_print(mon, env, &start, &last_prot, end, p=
rot);
> > +                        mem_print(hmp, env, &start, &last_prot, end, p=
rot);
> >                          continue;
> >                      }
> >
> > @@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchSt=
ate *env, AddressSpace *as)
> >                          } else {
> >                              prot =3D 0;
> >                          }
> > -                        mem_print(mon, env, &start, &last_prot, end, p=
rot);
> > +                        mem_print(hmp, env, &start, &last_prot, end, p=
rot);
> >                      }
> >                  }
> >              }
> >          }
> >      }
> >      /* Flush last range */
> > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
> > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
> >  }
> >  #endif /* TARGET_X86_64 */
> >
> >  void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env;
> >      AddressSpace *as;
> >
> >      env =3D monitor_hmp_get_cpu_env(hmp);
> >      if (!env) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >
> >      if (!(env->cr[0] & CR0_PG_MASK)) {
> > -        monitor_printf(mon, "PG disabled\n");
> > +        monitor_hmp_printf(hmp, "PG disabled\n");
> >          return;
> >      }
> >      as =3D cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
> > @@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *q=
dict)
> >  #ifdef TARGET_X86_64
> >          if (env->hflags & HF_LMA_MASK) {
> >              if (env->cr[4] & CR4_LA57_MASK) {
> > -                mem_info_la57(mon, env, as);
> > +                mem_info_la57(hmp, env, as);
> >              } else {
> > -                mem_info_la48(mon, env, as);
> > +                mem_info_la48(hmp, env, as);
> >              }
> >          } else
> >  #endif
> >          {
> > -            mem_info_pae32(mon, env, as);
> > +            mem_info_pae32(hmp, env, as);
> >          }
> >      } else {
> > -        mem_info_32(mon, env, as);
> > +        mem_info_32(hmp, env, as);
> >      }
> >  }
> >
> > diff --git a/target/i386/sev.c b/target/i386/sev.c
> > index 4473d02981ff..36a62e58be95 100644
> > --- a/target/i386/sev.c
> > +++ b/target/i386/sev.c
> > @@ -756,33 +756,32 @@ SevInfo *qmp_query_sev(Error **errp)
> >
> >  void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      SevInfo *info =3D sev_get_info();
> >
> >      if (!info || !info->enabled) {
> > -        monitor_printf(mon, "SEV is not enabled\n");
> > +        monitor_hmp_printf(hmp, "SEV is not enabled\n");
> >          goto out;
> >      }
> >
> > -    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_t=
ype));
> > -    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
> > -    monitor_printf(mon, "build: %d\n", info->build_id);
> > -    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
> > -                   info->api_minor);
> > +    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->s=
ev_type));
> > +    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
> > +    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
> > +    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
> > +                       info->api_minor);
> >
> >      if (sev_snp_enabled()) {
> > -        monitor_printf(mon, "debug: %s\n",
> > -                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG=
 ? "on"
> > -                                                                      =
 : "off");
> > -        monitor_printf(mon, "SMT allowed: %s\n",
> > -                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT=
 ? "on"
> > -                                                                      =
 : "off");
> > +        monitor_hmp_printf(hmp, "debug: %s\n",
> > +                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY=
_DBG ? "on"
> > +                                                                      =
     : "off");
> > +        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
> > +                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY=
_SMT ? "on"
> > +                                                                      =
     : "off");
> >      } else {
> > -        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
> > -        monitor_printf(mon, "debug: %s\n",
> > -                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" :=
 "on");
> > -        monitor_printf(mon, "key-sharing: %s\n",
> > -                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : =
"on");
> > +        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
> > +        monitor_hmp_printf(hmp, "debug: %s\n",
> > +                           info->u.sev.policy & SEV_POLICY_NODBG ? "of=
f" : "on");
> > +        monitor_hmp_printf(hmp, "key-sharing: %s\n",
> > +                           info->u.sev.policy & SEV_POLICY_NOKS ? "off=
" : "on");
> >      }
> >
> >  out:
> > diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
> > index 5645a5d4d4f5..23c25283b27a 100644
> > --- a/target/m68k/monitor.c
> > +++ b/target/m68k/monitor.c
> > @@ -12,11 +12,10 @@
> >
> >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env1 =3D monitor_hmp_get_cpu_env(hmp);
> >
> >      if (!env1) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >
> > diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
> > index 5769829bdd7e..6e8a075f5a41 100644
> > --- a/target/ppc/monitor.c
> > +++ b/target/ppc/monitor.c
> > @@ -13,11 +13,10 @@
> >
> >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env1 =3D monitor_hmp_get_cpu_env(hmp);
> >
> >      if (!env1) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >      dump_mmu(env1);
> > diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
> > index 4c9c0c793b36..59cc04b3d0fb 100644
> > --- a/target/riscv/monitor.c
> > +++ b/target/riscv/monitor.c
> > @@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, tar=
get_ulong addr)
> >      return addr;
> >  }
> >
> > -static void print_pte_header(Monitor *mon)
> > +static void print_pte_header(MonitorHMP *hmp)
> >  {
> > -    monitor_printf(mon, PTE_HEADER_FIELDS);
> > -    monitor_printf(mon, PTE_HEADER_DELIMITER);
> > +    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
> > +    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
> >  }
> >
> > -static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
> > +static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr=
,
> >                        hwaddr paddr, target_ulong size, int attr)
> >  {
> >      /* sanity check on vaddr */
> > @@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, ta=
rget_ulong vaddr,
> >          return;
> >      }
> >
> > -    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FM=
T_lx
> > -                   " %c%c%c%c%c%c%c\n",
> > -                   addr_canonical(va_bits, vaddr),
> > -                   paddr, size,
> > -                   attr & PTE_R ? 'r' : '-',
> > -                   attr & PTE_W ? 'w' : '-',
> > -                   attr & PTE_X ? 'x' : '-',
> > -                   attr & PTE_U ? 'u' : '-',
> > -                   attr & PTE_G ? 'g' : '-',
> > -                   attr & PTE_A ? 'a' : '-',
> > -                   attr & PTE_D ? 'd' : '-');
> > +    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGE=
T_FMT_lx
> > +                       " %c%c%c%c%c%c%c\n",
> > +                       addr_canonical(va_bits, vaddr),
> > +                       paddr, size,
> > +                       attr & PTE_R ? 'r' : '-',
> > +                       attr & PTE_W ? 'w' : '-',
> > +                       attr & PTE_X ? 'x' : '-',
> > +                       attr & PTE_U ? 'u' : '-',
> > +                       attr & PTE_G ? 'g' : '-',
> > +                       attr & PTE_A ? 'a' : '-',
> > +                       attr & PTE_D ? 'd' : '-');
> >  }
> >
> > -static void walk_pte(Monitor *mon, AddressSpace *as,
> > +static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
> >                       hwaddr base, target_ulong start,
> >                       int level, int ptidxbits, int ptesize, int va_bit=
s,
> >                       target_ulong *vbase, hwaddr *pbase, hwaddr *last_=
paddr,
> > @@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as=
,
> >                  if ((*last_attr !=3D attr) ||
> >                      (*last_paddr + *last_size !=3D paddr) ||
> >                      (last_start + *last_size !=3D start)) {
> > -                    print_pte(mon, va_bits, *vbase, *pbase,
> > +                    print_pte(hmp, va_bits, *vbase, *pbase,
> >                                *last_paddr + *last_size - *pbase, *last=
_attr);
> >
> >                      *vbase =3D start;
> > @@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as=
,
> >                  *last_size =3D pgsize;
> >              } else {
> >                  /* pointer to the next level of the page table */
> > -                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, =
ptesize,
> > +                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, =
ptesize,
> >                           va_bits, vbase, pbase, last_paddr,
> >                           last_size, last_attr);
> >              }
> > @@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as=
,
> >
> >  }
> >
> > -static void mem_info_svxx(Monitor *mon, CPUArchState *env)
> > +static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
> >  {
> >      AddressSpace *as =3D env_cpu(env)->as;
> >      int levels, ptidxbits, ptesize, vm, va_bits;
> > @@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchStat=
e *env)
> >      va_bits =3D PGSHIFT + levels * ptidxbits;
> >
> >      /* print header */
> > -    print_pte_header(mon);
> > +    print_pte_header(hmp);
> >
> >      vbase =3D -1;
> >      pbase =3D -1;
> > @@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchSt=
ate *env)
> >      last_attr =3D 0;
> >
> >      /* walk page tables, starting from address 0 */
> > -    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits=
,
> > +    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits=
,
> >               &vbase, &pbase, &last_paddr, &last_size, &last_attr);
> >
> >      /* don't forget the last one */
> > -    print_pte(mon, va_bits, vbase, pbase,
> > +    print_pte(hmp, va_bits, vbase, pbase,
> >                last_paddr + last_size - pbase, last_attr);
> >  }
> >
> >  void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env;
> >
> >      env =3D monitor_hmp_get_cpu_env(hmp);
> >      if (!env) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >
> >      if (!riscv_cpu_cfg(env)->mmu) {
> > -        monitor_printf(mon, "S-mode MMU unavailable\n");
> > +        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
> >          return;
> >      }
> >
> >      if (riscv_cpu_mxl(env) =3D=3D MXL_RV32) {
> >          if (!(env->satp & SATP32_MODE)) {
> > -            monitor_printf(mon, "No translation or protection\n");
> > +            monitor_hmp_printf(hmp, "No translation or protection\n");
> >              return;
> >          }
> >      } else {
> >          if (!(env->satp & SATP64_MODE)) {
> > -            monitor_printf(mon, "No translation or protection\n");
> > +            monitor_hmp_printf(hmp, "No translation or protection\n");
> >              return;
> >          }
> >      }
> >
> > -    mem_info_svxx(mon, env);
> > +    mem_info_svxx(hmp, env);
> >  }
> >
> >  #ifdef CONFIG_TCG
> > diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
> > index 4e443152bf56..62998a9a57cb 100644
> > --- a/target/sh4/monitor.c
> > +++ b/target/sh4/monitor.c
> > @@ -26,33 +26,32 @@
> >  #include "monitor/monitor.h"
> >  #include "monitor/hmp.h"
> >
> > -static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
> > +static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
> >  {
> > -    monitor_printf(mon, " tlb%i:\t"
> > -                   "asid=3D%hhu vpn=3D%x\tppn=3D%x\tsz=3D%hhu size=3D%=
u\t"
> > -                   "v=3D%hhu shared=3D%hhu cached=3D%hhu prot=3D%hhu "
> > -                   "dirty=3D%hhu writethrough=3D%hhu\n",
> > -                   idx,
> > -                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
> > -                   tlb->v, tlb->sh, tlb->c, tlb->pr,
> > -                   tlb->d, tlb->wt);
> > +    monitor_hmp_printf(hmp, " tlb%i:\t"
> > +                       "asid=3D%hhu vpn=3D%x\tppn=3D%x\tsz=3D%hhu size=
=3D%u\t"
> > +                       "v=3D%hhu shared=3D%hhu cached=3D%hhu prot=3D%h=
hu "
> > +                       "dirty=3D%hhu writethrough=3D%hhu\n",
> > +                       idx,
> > +                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->si=
ze,
> > +                       tlb->v, tlb->sh, tlb->c, tlb->pr,
> > +                       tlb->d, tlb->wt);
> >  }
> >
> >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env =3D monitor_hmp_get_cpu_env(hmp);
> >      int i;
> >
> >      if (!env) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >
> > -    monitor_printf (mon, "ITLB:\n");
> > +    monitor_hmp_printf(hmp, "ITLB:\n");
> >      for (i =3D 0 ; i < ITLB_SIZE ; i++)
> > -        print_tlb (mon, i, &env->itlb[i]);
> > -    monitor_printf (mon, "UTLB:\n");
> > +        print_tlb(hmp, i, &env->itlb[i]);
> > +    monitor_hmp_printf(hmp, "UTLB:\n");
> >      for (i =3D 0 ; i < UTLB_SIZE ; i++)
> > -        print_tlb (mon, i, &env->utlb[i]);
> > +        print_tlb(hmp, i, &env->utlb[i]);
> >  }
> > diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
> > index e826e584a918..36f109cbb568 100644
> > --- a/target/sparc/monitor.c
> > +++ b/target/sparc/monitor.c
> > @@ -29,11 +29,10 @@
> >
> >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env1 =3D monitor_hmp_get_cpu_env(hmp);
> >
> >      if (!env1) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >      dump_mmu(env1);
> > diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
> > index b7b7387706f3..b9c4089b0fb1 100644
> > --- a/target/xtensa/monitor.c
> > +++ b/target/xtensa/monitor.c
> > @@ -28,11 +28,10 @@
> >
> >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      CPUArchState *env1 =3D monitor_hmp_get_cpu_env(hmp);
> >
> >      if (!env1) {
> > -        monitor_printf(mon, "No CPU available\n");
> > +        monitor_hmp_printf(hmp, "No CPU available\n");
> >          return;
> >      }
> >      dump_mmu(env1);
> > diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sock=
ets.c
> > index b2a884529598..530a3fee3c13 100644
> > --- a/tests/unit/test-util-sockets.c
> > +++ b/tests/unit/test-util-sockets.c
> > @@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, =
Error **errp)
> >   */
> >  Monitor *monitor_cur(void) { return cur_mon; }
> >  Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
> > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort=
(); }
> > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) =
{ abort(); }
> >
> >  #ifndef _WIN32
> >  static void test_socket_fd_pass_name_good(void)
> > diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
> > index f62b2f294952..81a09ec5adfa 100644
> > --- a/tools/qemu-vnc/clipboard.c
> > +++ b/tools/qemu-vnc/clipboard.c
> > @@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboard=
Request *req)
> >          "Cancelled clipboard request");
> >
> >      g_clear_object(&req->invocation);
> > -    g_clear_handle_id(&req->timeout_id, g_source_remove);;
> > +    g_clear_handle_id(&req->timeout_id, g_source_remove);
> >  }
> >
> >  static gboolean
> > @@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *i=
nfo)
> >          vnc_dbus_clipboard_complete_request(
> >              req->invocation, info, req->type);
> >          g_clear_object(&req->invocation);
> > -        g_clear_handle_id(&req->timeout_id, g_source_remove);;
> > +        g_clear_handle_id(&req->timeout_id, g_source_remove);
> >          return;
> >      }
> >
> > diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
> > index 26597fefaa99..0aa50a901d37 100644
> > --- a/tools/qemu-vnc/stubs.c
> > +++ b/tools/qemu-vnc/stubs.c
> > @@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
> >      return NULL;
> >  }
> >
> > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> >  {
> >      return -1;
> >  }
> > diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
> > index 5a8158f4f4b6..a68f5b900d7c 100644
> > --- a/trace/trace-hmp-cmds.c
> > +++ b/trace/trace-hmp-cmds.c
> > @@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qd=
ict)
> >  #ifdef CONFIG_TRACE_SIMPLE
> >  void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *op =3D qdict_get_try_str(qdict, "op");
> >      const char *arg =3D qdict_get_try_str(qdict, "arg");
> >
> > @@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *q=
dict)
> >              st_set_trace_file(arg);
> >          }
> >      } else {
> > -        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
> > -        hmp_help_cmd(mon, "trace-file");
> > +        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
> > +        hmp_help_cmd(hmp, "trace-file");
> >      }
> >  }
> >  #endif
> >
> >  void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *name =3D qdict_get_try_str(qdict, "name");
> >      TraceEventInfoList *events;
> >      TraceEventInfoList *elem;
> > @@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDi=
ct *qdict)
> >      }
> >
> >      for (elem =3D events; elem !=3D NULL; elem =3D elem->next) {
> > -        monitor_printf(mon, "%s : state %u\n",
> > -                       elem->value->name,
> > -                       elem->value->state =3D=3D TRACE_EVENT_STATE_ENA=
BLED ? 1 : 0);
> > +        monitor_hmp_printf(hmp, "%s : state %u\n",
> > +                           elem->value->name,
> > +                           elem->value->state =3D=3D TRACE_EVENT_STATE=
_ENABLED ? 1 : 0);
> >      }
> >      qapi_free_TraceEventInfoList(events);
> >  }
> > diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
> > index 186209fd0234..f611dd7ee457 100644
> > --- a/ui/ui-hmp-cmds.c
> > +++ b/ui/ui-hmp-cmds.c
> > @@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qd=
ict)
> >
> >  void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      MouseInfoList *mice_list, *mouse;
> >
> >      mice_list =3D qmp_query_mice(NULL);
> >      if (!mice_list) {
> > -        monitor_printf(mon, "No mouse devices connected\n");
> > +        monitor_hmp_printf(hmp, "No mouse devices connected\n");
> >          return;
> >      }
> >
> >      for (mouse =3D mice_list; mouse; mouse =3D mouse->next) {
> > -        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
> > -                       mouse->value->current ? '*' : ' ',
> > -                       mouse->value->index, mouse->value->name,
> > -                       mouse->value->absolute ? " (absolute)" : "");
> > +        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
> > +                           mouse->value->current ? '*' : ' ',
> > +                           mouse->value->index, mouse->value->name,
> > +                           mouse->value->absolute ? " (absolute)" : ""=
);
> >      }
> >
> >      qapi_free_MouseInfoList(mice_list);
> > @@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *=
qdict)
> >
> >  #ifdef CONFIG_VNC
> >  /* Helper for hmp_info_vnc_clients, _servers */
> > -static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
> > +static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
> >                                    const char *name)
> >  {
> > -    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
> > -                   name,
> > -                   info->host,
> > -                   info->service,
> > -                   NetworkAddressFamily_str(info->family),
> > -                   info->websocket ? " (Websocket)" : "");
> > +    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
> > +                       name,
> > +                       info->host,
> > +                       info->service,
> > +                       NetworkAddressFamily_str(info->family),
> > +                       info->websocket ? " (Websocket)" : "");
> >  }
> >
> >  /* Helper displaying and auth and crypt info */
> > -static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
> > +static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent=
,
> >                                     VncPrimaryAuth auth,
> >                                     VncVencryptSubAuth *vencrypt)
> >  {
> > -    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
> > -                   VncPrimaryAuth_str(auth),
> > -                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "non=
e");
> > +    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
> > +                       VncPrimaryAuth_str(auth),
> > +                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : =
"none");
> >  }
> >
> > -static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *clie=
nt)
> > +static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *c=
lient)
> >  {
> >      while (client) {
> >          VncClientInfo *cinfo =3D client->value;
> >
> > -        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Cl=
ient");
> > -        monitor_printf(mon, "    x509_dname: %s\n",
> > -                       cinfo->x509_dname ?: "none");
> > -        monitor_printf(mon, "    sasl_username: %s\n",
> > -                       cinfo->sasl_username ?: "none");
> > +        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Cl=
ient");
> > +        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
> > +                           cinfo->x509_dname ?: "none");
> > +        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
> > +                           cinfo->sasl_username ?: "none");
> >
> >          client =3D client->next;
> >      }
> >  }
> >
> > -static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *ser=
ver)
> > +static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *=
server)
> >  {
> >      while (server) {
> >          VncServerInfo2 *sinfo =3D server->value;
> > -        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "S=
erver");
> > -        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
> > +        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "S=
erver");
> > +        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
> >                                 sinfo->has_vencrypt ? &sinfo->vencrypt =
: NULL);
> >          server =3D server->next;
> >      }
> > @@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncS=
erverInfo2List *server)
> >
> >  void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      VncInfo2List *info2l, *info2l_head;
> >      Error *err =3D NULL;
> >
> > @@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *q=
dict)
> >          return;
> >      }
> >      if (!info2l) {
> > -        monitor_printf(mon, "None\n");
> > +        monitor_hmp_printf(hmp, "None\n");
> >          return;
> >      }
> >
> >      while (info2l) {
> >          VncInfo2 *info =3D info2l->value;
> > -        monitor_printf(mon, "%s:\n", info->id);
> > -        hmp_info_vnc_servers(mon, info->server);
> > -        hmp_info_vnc_clients(mon, info->clients);
> > +        monitor_hmp_printf(hmp, "%s:\n", info->id);
> > +        hmp_info_vnc_servers(hmp, info->server);
> > +        hmp_info_vnc_clients(hmp, info->clients);
> >          if (!info->server) {
> >              /*
> >               * The server entry displays its auth, we only need to
> >               * display in the case of 'reverse' connections where
> >               * there's no server.
> >               */
> > -            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
> > +            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
> >                                 info->has_vencrypt ? &info->vencrypt : =
NULL);
> >          }
> >          if (info->display) {
> > -            monitor_printf(mon, "  Display: %s\n", info->display);
> > +            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
> >          }
> >          info2l =3D info2l->next;
> >      }
> > @@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdi=
ct)
> >  #ifdef CONFIG_SPICE
> >  void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      SpiceChannelList *chan;
> >      SpiceInfo *info;
> >      const char *channel_name;
> > @@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict =
*qdict)
> >      info =3D qmp_query_spice(NULL);
> >
> >      if (!info->enabled) {
> > -        monitor_printf(mon, "Server: disabled\n");
> > +        monitor_hmp_printf(hmp, "Server: disabled\n");
> >          goto out;
> >      }
> >
> > -    monitor_printf(mon, "Server:\n");
> > +    monitor_hmp_printf(hmp, "Server:\n");
> >      if (info->has_port) {
> > -        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
> > -                       info->host, info->port);
> > +        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
> > +                           info->host, info->port);
> >      }
> >      if (info->has_tls_port) {
> > -        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
> > -                       info->host, info->tls_port);
> > +        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n"=
,
> > +                           info->host, info->tls_port);
> >      }
> > -    monitor_printf(mon, "    migrated: %s\n",
> > -                   info->migrated ? "true" : "false");
> > -    monitor_printf(mon, "        auth: %s\n", info->auth);
> > -    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
> > -    monitor_printf(mon, "  mouse-mode: %s\n",
> > -                   SpiceQueryMouseMode_str(info->mouse_mode));
> > +    monitor_hmp_printf(hmp, "    migrated: %s\n",
> > +                       info->migrated ? "true" : "false");
> > +    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
> > +    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_versi=
on);
> > +    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
> > +                       SpiceQueryMouseMode_str(info->mouse_mode));
> >
> >      if (!info->has_channels || info->channels =3D=3D NULL) {
> > -        monitor_printf(mon, "Channels: none\n");
> > +        monitor_hmp_printf(hmp, "Channels: none\n");
> >      } else {
> >          for (chan =3D info->channels; chan; chan =3D chan->next) {
> > -            monitor_printf(mon, "Channel:\n");
> > -            monitor_printf(mon, "     address: %s:%s%s\n",
> > -                           chan->value->host, chan->value->port,
> > -                           chan->value->tls ? " [tls]" : "");
> > -            monitor_printf(mon, "     session: %" PRId64 "\n",
> > -                           chan->value->connection_id);
> > -            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "=
\n",
> > -                           chan->value->channel_type, chan->value->cha=
nnel_id);
> > +            monitor_hmp_printf(hmp, "Channel:\n");
> > +            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
> > +                               chan->value->host, chan->value->port,
> > +                               chan->value->tls ? " [tls]" : "");
> > +            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
> > +                               chan->value->connection_id);
> > +            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId=
64 "\n",
> > +                               chan->value->channel_type, chan->value-=
>channel_id);
> >
> >              channel_name =3D "unknown";
> >              if (chan->value->channel_type > 0 &&
> > @@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *q=
dict)
> >                  channel_name =3D channel_names[chan->value->channel_ty=
pe];
> >              }
> >
> > -            monitor_printf(mon, "     channel name: %s\n", channel_nam=
e);
> > +            monitor_hmp_printf(hmp, "     channel name: %s\n", channel=
_name);
> >          }
> >      }
> >
> > @@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const=
 char *password,
> >      monitor_hmp_read_command(opaque, 1);
> >  }
> >
> > -void hmp_change_vnc(Monitor *mon, const char *device, const char *targ=
et,
> > +void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *t=
arget,
> >                      const char *arg, const char *read_only, bool force=
,
> >                      Error **errp)
> >  {
> > @@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *devic=
e, const char *target,
> >          return;
> >      }
> >      if (!arg) {
> > -        MonitorHMP *hmp =3D MONITOR_HMP(mon);
> >          monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
> >      } else {
> >          qmp_change_vnc_password(arg, errp);
> > @@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t k=
ey_length)
> >
> >  void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
> >  {
> > -    Monitor *mon =3D MONITOR(hmp);
> >      const char *keys =3D qdict_get_str(qdict, "keys");
> >      KeyValue *v =3D NULL;
> >      KeyValueList *head =3D NULL, **tail =3D &head;
> > @@ -432,7 +427,7 @@ out:
> >      return;
> >
> >  err_out:
> > -    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys=
);
> > +    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, =
keys);
> >      goto out;
> >  }
> >
> > diff --git a/util/error-report.c b/util/error-report.c
> > index 70cbd174ffae..c20e157780fa 100644
> > --- a/util/error-report.c
> > +++ b/util/error-report.c
> > @@ -38,7 +38,7 @@ error_vprintf_mon(const char *fmt, va_list ap)
> >      MonitorHMP *hmp =3D monitor_cur_hmp();
> >
> >      if (hmp) {
> > -        return monitor_vprintf(MONITOR(hmp), fmt, ap);
> > +        return monitor_hmp_vprintf(hmp, fmt, ap);
> >      }
> >
> >      return vfprintf(stderr, fmt, ap);
> > diff --git a/util/qemu-print.c b/util/qemu-print.c
> > index 0eecc05b0330..aabe670fda01 100644
> > --- a/util/qemu-print.c
> > +++ b/util/qemu-print.c
> > @@ -23,7 +23,7 @@ int qemu_vprintf(const char *fmt, va_list ap)
> >  {
> >      MonitorHMP *hmp =3D monitor_cur_hmp();
> >      if (hmp) {
> > -        return monitor_vprintf(MONITOR(hmp), fmt, ap);
> > +        return monitor_hmp_vprintf(hmp, fmt, ap);
> >      }
> >      return vprintf(fmt, ap);
> >  }
> > @@ -54,7 +54,7 @@ int qemu_vfprintf(FILE *stream, const char *fmt, va_l=
ist ap)
> >  {
> >      if (!stream) {
> >          MonitorHMP *hmp =3D monitor_cur_hmp();
> > -        return hmp ? monitor_vprintf(MONITOR(hmp), fmt, ap) : -1;
> > +        return hmp ? monitor_hmp_vprintf(hmp, fmt, ap) : -1;
> >      }
> >      return vfprintf(stream, fmt, ap);
> >  }
> >
> > --
> > 2.55.0.543.g5ebe2ebe4ea8
> >
> --
>  -----Open up your eyes, open up your mind, open up your code -------
> / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> \        dave @ treblig.org |                               | In Hex /
>  \ _________________________|_____ http://www.treblig.org   |_______/
>



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 14:53:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 14:53:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395503.1633848 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhfl-00046h-2Y; Wed, 19 Aug 2026 14:53:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395503.1633848; Wed, 19 Aug 2026 14:53:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhfk-00046a-Vw; Wed, 19 Aug 2026 14:53:44 +0000
Received: by outflank-mailman (input) for mailman id 1395503;
 Wed, 19 Aug 2026 14:53:44 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwhfj-00046U-Vk
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 14:53:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhfj-00GvnN-3W
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 16:53:43 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85c363-2eae-0a2a0a5409dd-0a2a450cc6d2-28
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:53:43 +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 <jbeulich@suse.com>)
 id 6a85c376-f479-0a2a450c0019-d1558036a448-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 16:53:42 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4994c49f588so11651875e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 07:53:42 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0d6721sm85565645e9.11.2026.08.19.07.53.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 07:53:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787151222; x=1787756022; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=SbA6JXXyVmCBXLEtXdb1uu35/iM8yCB3kbwPdKt9X2M=;
        b=TTL/X4bjxmjCgivBS3YacY5vlMMmQxik2JZowcwDxqQVXpVJNPFowBMeS3KkfFdgC2
         B7T3i1dSN3mLI1UrEEXqUlN0Rhzr9EVE0XsWdOLUkGWoShoYJ85mfaOzmjl2d+Giuz8y
         z8cBoXp/K5qFp3zZt//0ciAB60RKo1/HlKyd/cBIYjADsaeDzHXRrF8h15UDQ7rT3QDq
         HFLzG6bNeA6NL0FlrWVLOVySPElvm09S0D141rMOuC4HYnLosuonuNna3oTpdBTbW6ao
         WNZQrL4L8cEmPGe4A1tGC6slGPb9DozoTFN3MmW5XENFfuRbCrg9DkQEWOscZiMcDbms
         RZyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787151222; x=1787756022;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=SbA6JXXyVmCBXLEtXdb1uu35/iM8yCB3kbwPdKt9X2M=;
        b=NWTdOBYimBL1Il4dYfI4/Y52Zy1+LnfN+9Bd157Quf+efYg+Tv4wZXiHtYwyUjFqi5
         Fj8GPldgFXduIwz5rbzQskvkgzs2xfsFFxVdVxqeEWCU0ifKog78aeWK8NzqHcPDdSoX
         if8znROWqThoYvkGWBp9Z7uTtzL2ep+sj17yQLY37slcasw/z0XPer24FIKwGV3LBpJ/
         5NnXG+2lULiQdsy2OMgAyZkxvmHpG6isd0XGqT9bonp9HZF8r5GSzIx9ae1bIqlpVegM
         Rl/UvGqU6c1VKOnleA7xMMcxJVYPvreIu4NT51CBvHcOCxZttdfKmDFQPSpe8RYkkAeD
         ZMHw==
X-Forwarded-Encrypted: i=1; AHgh+RpBMkNB4eN3RcJvBhN8HZpy/6qX+u/bRdNt89ZAyNqJfZGXFjKNSUvNnrmfct8RnDi2DMzDNwT3UPI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywu1fCbVWEJkqQAG52kYXhfqA5A0TCw7x6cFYBU0GzDQ9dvmOqf
	LeyLwYc84z4lJIPyByOPaAscx+p2ybEz+tEnNhKEvUFU/ezLEA6iO6xaWELIQ8UUgQ==
X-Gm-Gg: AR+sD11byHoMUr30oY0KG2Pu+hdKRVPHeVsYanBZ5Kp+OifXDRnT7ioXoOmrnYQwLpx
	jfwyM8jtt4m7s2K9pf0C2yIYcht0mLH1ehQwKTF26vshZixSosFpoez1y5jX4H1nRrHmrN2X6EH
	Bq4swnwMyPZz3lxH2Nb4tezzgYNex06KSJrqggNItKMhWVECZsWUtWqz7N7GYHKGl+k1/2jOir5
	3NjtbHCAt+iKUvH2SZoduNlGW/R3hNFqWwEEBmet5xh0jWjdvWFYxg4LXAhSyztEdFlnleuWDIa
	uy5R5G1glcbiBn5Z043aKL3LIRWa5iWHZjUuzeDY7ahgFAKNGN5qyGoKbOYwm50BqEgkKWxlZR4
	NkNVmjdrd4nZUkr59YRCFtGRHFn/yC+/8Hj/DXpGMHLilkS2oGnN9vBmJ6x4XvYa55d0SwBbgZN
	GucRGf8+ZRpT6H/ref77gbRft20SGaAaIFL9dR7xPcoZddIL6U6k0cgjoL/dAThr1r6CWuvIR8q
	0MSHY8WPGkYmtodei0e0kky6SdDiN2/OpUnvFfKMa9HpwjMQJzJ
X-Received: by 2002:a05:600c:3f10:b0:493:f783:c46a with SMTP id 5b1f17b1804b1-499aa0f306fmr99397055e9.6.1787151222437;
        Wed, 19 Aug 2026 07:53:42 -0700 (PDT)
Message-ID: <90d8da75-3d95-4cb2-944c-24e11b0e215a@suse.com>
Date: Wed, 19 Aug 2026 16:53:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated
 panic()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
 <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
 <65789d8b-d18f-4f1c-8ffc-e1247daa4031@citrix.com>
 <ffe6c2b0-ec82-40e6-9bf5-fd49a3ef3a43@suse.com>
 <1200071f-122a-4dc0-aa08-7a7e2f1a6587@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1200071f-122a-4dc0-aa08-7a7e2f1a6587@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787151222-772D8A5B-935D17E2/0/0
X-purgate-type: clean
X-purgate-size: 885

On 19.08.2026 16:04, Andrew Cooper wrote:
> One other idea I had:
> 
> If we rearrange the loop to have a periodic "taken $X seconds" (shows
> liveness), and maybe at 40s decide to panic (by passing through the out:
> label first so we release the APs, so they can crash more cleanly), then
> that might be acceptable.
> 
> By 40s, the system isn't surviving even if the cores do all come back.

Maybe, yet I'm curious: How did you land at 40s as the "magic" boundary?
For a runtime load, even the 4.5s that you say GNR takes may already be
too much for the system (Dom0 and/or DomU-s) to properly survive as a
whole, depending on their requirements and/or configuration. Even our
time calibration rendezvous wants to occur once a second (albeit it may
not really need to run that often, plus iirc you have been saying that
we should get rid of it altogether).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:01:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:01:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395516.1633857 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhmx-0005pd-OC; Wed, 19 Aug 2026 15:01:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395516.1633857; Wed, 19 Aug 2026 15:01:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhmx-0005pW-LC; Wed, 19 Aug 2026 15:01:11 +0000
Received: by outflank-mailman (input) for mailman id 1395516;
 Wed, 19 Aug 2026 15:01:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwhmw-0005pQ-3I
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:01:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhmu-0063Sq-Vb
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:01:08 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85c525-2eae-0a2a0a5409dd-0a2a4504d86c-48
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:01:08 +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 <jbeulich@suse.com>)
 id 6a85c534-b57f-0a2a45040019-d155802db5d3-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:01:08 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49557167508so12016055e9.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:01:08 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0dd620sm61797305e9.13.2026.08.19.08.01.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 08:01:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787151668; x=1787756468; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=dsyhCyqOxMGByEJU+chQPW8k4quQqctXy3hKMIyZqhk=;
        b=cf/OZaDVQzorhQE569hrT46OMyaWKC4X9wcFXz4cNzOoTK3a4A13vTogMiavVjKy1M
         XMwc476+Bv5CRElLdOFRfM0L/g1Gyo96PLAll89rVhdZ1ioNeuWijHXI83A3Hyzr/caU
         2bkXn9GCaLd7+ySI0i0iE6V+qvERxC094h1FlT+lUNUPh80WzuspS2RejGAQpF5Cszmw
         Act5j3TMlw537cS3sWEOCNmiNK36Kb2xP7U7yXhUjdqMr0Ex1hU7YsSpj8e8xt+Dr8ax
         uyJuXfr3YimKS1y7qN+mef86L6h2xovo9axh35IbIiFgngshVmYu2LR+VQv1N+9M7d7b
         xcjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787151668; x=1787756468;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=dsyhCyqOxMGByEJU+chQPW8k4quQqctXy3hKMIyZqhk=;
        b=nMO1+Uw8eVUJvbftSdPgzgPlwcEwlGUxy8CM3mTVA7QlmxXFT4eJOB5RQKO+QNR93D
         LHBnwvzc04AfbMfi/z2cO5S+HOGdf5QFiOa4fJk4zU6tALb8IEHGGgE/t3Sh2qnE++ob
         gNvb37dgg5eAorzwnojqHsV/arw2zcWM2tRX84H1bKcFtzKI/AnV2wGo1Iw4dxb8IKNr
         lzyE4A1/sUAjYRvUuqY6Fnu3k3KybLmv0XAvKH/1NvjI8CmPLg3CidL28hWgjCNW72jP
         y4OFk7mbvZlEo+/oOaMyX3omRhIfa0KpcJldkeN+WB1iYxKib1l+Sr1KWZ6Bn90Kyic4
         VT3g==
X-Forwarded-Encrypted: i=1; AHgh+Rpz7Cxm/RyZn58lLh369HUUiMsInqfT3grhrhhwEFshLBoYmwRoitxgUxMQq0wt+9pW/1YYnhp6djI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxXWV4QlcNafhwuwvC+pPaSs6pyJpgz5B/wC9rIccjVhAFS5WDm
	k3+KQ1p5D3DxOvQAsrDSGn4TIZ+rPZcLfKrk8rWvpe9efwSjeCDGrrlCVzFYIfefxg==
X-Gm-Gg: AR+sD13RSg0I5rSsMDSt5Ls52EdMtrlBate6BuFGmnEDtu/LFT7xzxAVy/Mey0HAeO+
	yu6YM47lhubrmYThuQR1pifHII7v/eRdBFh2yUD6BoNHhb57rqjnDmW0tcenByz06xpKKubOISG
	UJQXfg0vfytPIDvvjz6KKpf3mF5sG0zRSZT+4pwDYhBHhiWTzABv95EVIhKuU9r/d1Q1uh3jge4
	6XWLAHfufU20UiA1H46bs5zjIbyThVp31AG7LgbZvPJbPKSl2axiLStClX2C5fwobE/XWm9usSS
	YGPPZgAJ9taAJpFFiT8N0L30XJoWkZJNQaA3IVEn3Bsa3cp4kSU1ReqTSdpuG3EEEdT6NOR5tP8
	/WwG+epR7kPfesgDp6hsDxvAPjkqPpp2SDaWTH5SE+8+ELaEYBlquDy8AA6WOs1wXh4fM2ZXFNS
	f4E2ewXRiR63YpjQ0S07zOyNwS3xoxAbad9WpQtV48JNaj/3d9dGzA/8a8ynysk+H7HLFRqqY+j
	xZyccIFXuBHJiXGQbp84Si04gdc+EMyrzf3jPrQ7OtL46lEiiF8
X-Received: by 2002:a05:600c:37c6:b0:499:9eb7:4558 with SMTP id 5b1f17b1804b1-499aa1e43b7mr105051065e9.10.1787151668076;
        Wed, 19 Aug 2026 08:01:08 -0700 (PDT)
Message-ID: <c1db28e7-2914-48cf-ace2-111e2dec6fbd@suse.com>
Date: Wed, 19 Aug 2026 17:01:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 9/9] x86/cpuid: Advertise XEN_HVM_CPUID_EXT_DEST_ID
 when device model opts in
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298082.8631fc262581453bbf619ec5b2062170.19dcf3888b2000f373@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1777298082.8631fc262581453bbf619ec5b2062170.19dcf3888b2000f373@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787151668-534C3B50-8E84EC00/0/0
X-purgate-type: clean
X-purgate-size: 1480

On 27.04.2026 15:54, Julian Vetter wrote:
> Set the XEN_HVM_CPUID_EXT_DEST_ID bit in the HVM hypervisor CPUID leaf
> based on the domain-level ext_dest_id flag, which is locked at domain
> creation time by taking the AND across all registered ioreq servers that
> set XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID. This guarantees that the bit is
> only advertised when every active device model will use
> XEN_DMOP_bind_pt_msi_irq for passthrough MSIs, so Xen can decode the
> extended destination bits from the raw MSI address internally.
> 
> After creation_finished the locked d->arch.hvm.ext_dest_id is used
> directly, providing a stable and migration-safe value independent of
> whether ioreq servers have been re-registered yet. Before
> creation_finished the dynamic per-server check is used so toolstack
> queries during domain setup reflect the current state.

What toolstack queries to you have in mind here? Did you check ...

> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -1,3 +1,4 @@
> +#include <xen/ioreq.h>
>  #include <xen/sched.h>
>  #include <xen/types.h>
>  #include <xen/version.h>
> @@ -148,6 +149,18 @@ static void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,

... call sites of this function? It's solely guest_cpuid(), and all
callers of the latter act on current. I.e. if there was a need for a
toolstack to find out (transient) state, it would need to be through
a different interface anyway.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:08:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:08:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395541.1633866 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhu8-0006kS-DL; Wed, 19 Aug 2026 15:08:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395541.1633866; Wed, 19 Aug 2026 15:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwhu8-0006kL-AQ; Wed, 19 Aug 2026 15:08:36 +0000
Received: by outflank-mailman (input) for mailman id 1395541;
 Wed, 19 Aug 2026 15:08:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwhu7-0006j9-6a
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:08:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwhu4-00GxnJ-1q
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:08:32 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85c6e8-2eae-0a2a0a5409dd-0a2a45039b50-14
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:08:31 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85c6ef-fae8-0a2a45030019-d155dd29b4c6-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:08:31 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-4815b8781c7so556227f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:08:31 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e00bddsm54561765e9.3.2026.08.19.08.08.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 08:08:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787152111; x=1787756911; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=CB6iquoH6KbE/idsuqAY9deu2VeImI5opQQKnqZffLw=;
        b=MAd8or4iIEPpE/HJ1QweV4149qUm5LGoMNdqsQXfjrsn8jyV80EoiUE8b30BGXMD3z
         3wVvxW2Jt/dq0QzaQd382tiS4p7iaJv7Pdfp97THlKiaWtK4nuOHo+5MIylfNaxzZyJK
         K3U59NcSadXX7fyK+I508KRO004ferv9vUhRUeFUllztfcEJwzng+3+ouZH0v+7grAtv
         +uCdaGJuk2xkTdnu/zOK0dvIX4Zt3ZZHrBw21xgA8E0GG8PzPNSNE8BFLLgX204qP/nA
         66xQRSosAEbT3H+Mq+yMiZnXYqGh3HoP3H9tlgmjdlmtXETP3fD0OA3FYywJk5w4Mxb4
         q/gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787152111; x=1787756911;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=CB6iquoH6KbE/idsuqAY9deu2VeImI5opQQKnqZffLw=;
        b=ku8ZOtl4YhWwxkbIu25E38Wc1AA+dtqLcm8YG+i0yIF0ylsLpIVESOEaLLB9lohIMe
         M0jetSNlHFNbBqmBtxheGOfTaq2JsoJRFsB7PDRCffpsXzqQNeKANbP36PsxosZNeLFE
         nQ+y2N8qSGYIy53ViFR4kGN7MskouMCbT0SgE8slFBfEGxUzL8qceWQDxF1OOjekPdDb
         vXffq67gqD7bZiVWlJ4gkfuM5/iLw4wAF/KneY6YctnV0QC4U2TjB5JnCCpO+UZgiE0H
         9GQ+RqcVdC+JYQThkDgqaIFntKjspyl5qC7aw+0l9RDPyAtnhoEPDPlySlue5YQGAaya
         GXCg==
X-Forwarded-Encrypted: i=1; AHgh+RosVg14BqxVRVmC2K6cO3soMvHucYcP6hYnJUixCLJEmmcEO3ojODQ9zQ1YzbLlgkkK9y0IN+4o2lU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZ/wRv5oBuJbjFfPjRGZzKJNO/Akve7aOcbXS6X27IfQY8odnK
	M0Q2OAKP11AWgNc1m0ngbBW6z+QGbnAr+FcgPMDRhFn/RvUfxRle9VjPG4DZGnQtrQ==
X-Gm-Gg: AR+sD13rUd+EAjZ9zUWtFZ8oaGnqZQFlmLf/IUowlBQ1bpjBGBIabuWjBZvZzJtuXD3
	OI/ubwHOu01B3UemIogcMLAFREqq6BUnZwWTx5YzxprEuaQIp8t+IeWLw43SZWLC6lCGVYKIzLM
	sL80kqcgID9tdXnmHEXAisQXcFlsfxoAMzxDpYZnLDWR0xufzm4SFQ3p2hGLEeSkXem9opm+CR6
	1ZewH7AcyNQMdVNchcKTkNr73apMFpmgIQgJI0BNMVvVxhLy6S82kG+CQdoslw5TwWZD9XLA2Rm
	q9lRlFArKoZtzun8ZUZhKUS/a++ASyvZDpQl8NMXxH0yypY6vrLQ1OY8yGrAirbnsKVVsZNg+DD
	ML2ZkVeByiyh01r3ddRv4U8u3lYZtwURn97XJsZVoEOOvuHepKV17uUimvYJk1Idv/j3w17z6U9
	BcnLsMswYV9SwvLo+1xNInkhe1mgkuz9WPL36/vh1EjYfa+Y9qie3nj1h7//WWVtJ810vg6LTab
	trg7955hwFoBKEmjGLgI6/5JxYUFi4MMfrRyzM6cFQA9dGrGaGY
X-Received: by 2002:a05:600c:4f52:b0:499:7a15:fcec with SMTP id 5b1f17b1804b1-499aa1fdfb3mr87422285e9.13.1787152111443;
        Wed, 19 Aug 2026 08:08:31 -0700 (PDT)
Message-ID: <4fed56c0-b8b1-408b-bc60-7a1afe05ffa2@suse.com>
Date: Wed, 19 Aug 2026 17:08:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v7 03/14] x86/domain: Defer domain iommu
 initialization.
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <cover.1763569135.git.teddy.astie@vates.tech>
 <c4a81e284ec202a34b8e983679dead4dc2ae248a.1763569135.git.teddy.astie@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <c4a81e284ec202a34b8e983679dead4dc2ae248a.1763569135.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787152111-77AF14E9-7E09EDBE/0/0
X-purgate-type: clean
X-purgate-size: 1139

On 20.11.2025 12:09, Teddy Astie wrote:
> For the IOMMU redesign, the iommu context pagetable is defined once during
> initialization. When reusing P2M pagetable, we want to ensure that this
> pagetable is properly initialized.
> 
> Signed-off-by Teddy Astie <teddy.astie@vates.tech>

>From what is said, I for one cannot deduce why the move is (a) necessary and
(b) correct / safe to do.

Jan

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -927,9 +927,6 @@ int arch_domain_create(struct domain *d,
>      if ( (rc = init_domain_irq_mapping(d)) != 0 )
>          goto fail;
>  
> -    if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
> -        goto fail;
> -
>      psr_domain_init(d);
>  
>      if ( is_hvm_domain(d) )
> @@ -948,6 +945,9 @@ int arch_domain_create(struct domain *d,
>      else
>          ASSERT_UNREACHABLE(); /* Not HVM and not PV? */
>  
> +    if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
> +        goto fail;
> +
>      if ( (rc = tsc_set_info(d, XEN_CPUID_TSC_MODE_DEFAULT, 0, 0, 0)) != 0 )
>      {
>          ASSERT_UNREACHABLE();



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:15:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:15:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395549.1633876 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwi0p-0008Vb-2i; Wed, 19 Aug 2026 15:15:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395549.1633876; Wed, 19 Aug 2026 15:15:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwi0o-0008VU-V8; Wed, 19 Aug 2026 15:15:30 +0000
Received: by outflank-mailman (input) for mailman id 1395549;
 Wed, 19 Aug 2026 15:15:29 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwi0n-0008VO-KW
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:15:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwi0m-00GzA2-QL
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:15:28 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85c87d-bab6-0a2a0a5309dd-0a2a4507bbe2-22
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:15:24 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85c88b-b4ea-0a2a45070019-d155802cbc73-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:15:24 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-4921eed3fa2so11039295e9.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:15:24 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9aa3204sm48049415e9.0.2026.08.19.08.15.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 08:15:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787152523; x=1787757323; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=UT03oe7zJYEP+lA/DptUnOk0xOrLpZuOPliTdRhSV60=;
        b=YBU8ILUyfLgInYNw34hmQsK4W90IJLXK+KEy7qI4D7+e8mn5FCr3YOObGD97PQS5I5
         p1rFXZm+SIkrJvPtuwvSMlnFNA/Yz8IyqT/ruM4Sjvu5kOCIgW/x3aguan7ygQr0w7ic
         pLX4zNajWNLjatWxpuhZ3Q5GNeVmDkGo0/FgJFnLxOhSPDvGe0txwwBS7gLp/0ibhohr
         V35J8bJuBKtorqbtL6q7s3RmoA8oPShSlIg/or1QDxgJZHJZ8ytWaQmOjGEihaK3UtBB
         OHfYkKnuz+bkqqTFj2zvaeJGIQMWOqmuOEdSE2c+zxceu8tZxd4wqrp/M3IfPSf70DwC
         8thw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787152523; x=1787757323;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=UT03oe7zJYEP+lA/DptUnOk0xOrLpZuOPliTdRhSV60=;
        b=jnZlPr2P88aNDofrqbfd9mA3NMy78kJ1Yi8j7sEG80wqifm7TGyJE7UEeY6CriOh3h
         G/sBq6edlp5fKo1Y9iNLEKGjjCUQOnS51tcZRkBegJPUTLmJ08i7HcchTxU7N2pb6j8P
         3Snq1YgXym+LR6FB4VBgIE3gysgP8Qoticzh1vk9tJ23ROwoNa75axglWoqZPXoBadbu
         jpuWhlCriL3zrAaNu0yvI8D+dUvtfu73OQgmMWLpCi2n3ZJvQ1mfJfVRdj/isOXL2s+q
         Mb03BRuvg6N4PR/LrBmjX7Gr1nCh9WnT5ZYLMuaZAvRKSVQki2waaOE0MkDL+tiQlLbM
         eQFw==
X-Forwarded-Encrypted: i=1; AHgh+Rp7KY6TXwmHwyD414hSvgsIA/iiehnZMrEpFgBoYi7io2WNHYWgyZts0p9CRXS+Jnxj0RCohrARsc8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGB1rvYTKqlgQ31yUgVSAnCSM3i8k2S1xMvLdt8rHB9QT5IC6y
	SaA1/Ny/M2u1T2LzIpduCaIi9lmk3y2vB/yQfx35owBh+z4aiLmInLtQlRZZP6VQlQ==
X-Gm-Gg: AR+sD12C2UJ0xK6nWEkmeZFBW5cQgyfex+IDuo7oyC1WDiC8dQPTvlkQckpOTYiqzNH
	qX4aFb5XnxnDJwZcyCei/vvUg0Mor6NosWBpm6FLMK6a/AJRiDGbjqgI5duyjh5oKw0m3sydPQ7
	Woifq/jrbDimCH6IbyfIQ9hXmf111ofdKRE7u3fK3kq4icRxlbwwy5kk432yxftSmZB6kT2dOJO
	z5Gy1+cktsrnpbZF46v/TKTU3P/Suo72R3yU/eqtOGM2qY+7WYPjO/aYcZXGKiXavDwI2nD7WwR
	ukgL/WZShDhvOA+NaZquB54W4Qv9qoyCFWLOUuYE5FUzJ3ploEdvOGNpNzA3m9MvWx+73uNz1SL
	lp0eD73HMjhTYMJMCIJEVdUod20Nib1sqWyXa+oRQdvbQbO8fkrvUx896n46dgZSaD03cDyU23m
	MPuY5NrlaVv3gOKO19rAFq3JQprGU6s+68lNpc6RvL7rCfrw9DBRnUxdZiPCxEMcHD9pmZNKpSR
	KYYPy2643H83HmwmC2BK24xVFmBdC18STk1USBWq77KixPTczhIkg==
X-Received: by 2002:a05:600c:3e0c:b0:499:4e47:eaf2 with SMTP id 5b1f17b1804b1-499aa1a3e87mr112516105e9.6.1787152523539;
        Wed, 19 Aug 2026 08:15:23 -0700 (PDT)
Message-ID: <f7d5cd81-ecf3-4075-9355-34c03cdbc644@suse.com>
Date: Wed, 19 Aug 2026 17:15:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v7 04/14] iommu: Move IOMMU domain related structures
 to (arch_)iommu_context
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Timothy Pearson <tpearson@raptorengineering.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Lukasz Hawrylko <lukasz@hawrylko.pl>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 =?UTF-8?Q?Mateusz_M=C3=B3wka?= <mateusz.mowka@intel.com>,
 Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
References: <cover.1763569135.git.teddy.astie@vates.tech>
 <af6217ef3ce355cc873fd7aca128fb12feea3e55.1763569135.git.teddy.astie@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <af6217ef3ce355cc873fd7aca128fb12feea3e55.1763569135.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787152524-374D3AE4-E5E90F1C/0/0
X-purgate-type: clean
X-purgate-size: 3005

On 20.11.2025 12:09, Teddy Astie wrote:
> Preparatory work for IOMMU redesign.
> 
> Introduce a new structure (arch_)iommu_context that will hold all
> per-IOMMU context related informations for the IOMMU drivers.
> 
> Signed-off-by Teddy Astie <teddy.astie@vates.tech>

It's hard to see what feedback you're expecting here. For an RFC, I'm not
going to point out all the style issues. One remark, perhaps:

> --- a/xen/arch/arm/include/asm/iommu.h
> --- a/xen/arch/x86/include/asm/iommu.h
> +++ b/xen/arch/x86/include/asm/iommu.h
> @@ -31,22 +31,21 @@ typedef uint64_t daddr_t;
>  #define dfn_to_daddr(dfn) __dfn_to_daddr(dfn_x(dfn))
>  #define daddr_to_dfn(daddr) _dfn(__daddr_to_dfn(daddr))
>  
> -struct arch_iommu
> -{
> -    spinlock_t mapping_lock; /* io page table lock */
> -    struct {
> -        struct page_list_head list;
> -        spinlock_t lock;
> -    } pgtables;
> +struct iommu_context;
>  
> +struct arch_iommu_context
> +{
> +    struct page_list_head pgtables;
>      struct list_head identity_maps;
>  
> +
> +    spinlock_t mapping_lock; /* io page table lock */
> +
>      union {
>          /* Intel VT-d */
>          struct {
>              uint64_t pgd_maddr; /* io page directory machine address */
> -            unsigned int agaw; /* adjusted guest address width, 0 is level 2 30-bit */
> -            unsigned long *iommu_bitmap; /* bitmap of iommu(s) that the domain uses */
> +            unsigned long *iommu_bitmap; /* bitmap of iommu(s) that the context uses */
>          } vtd;
>          /* AMD IOMMU */
>          struct {
> @@ -56,6 +55,24 @@ struct arch_iommu
>      };
>  };
>  
> +struct arch_iommu
> +{
> +    /* Queue for freeing pages */
> +    struct page_list_head free_queue;
> +
> +    union {
> +        /* Intel VT-d */
> +        struct {
> +            unsigned int agaw; /* adjusted guest address width, 0 is level 2 30-bit */
> +        } vtd;
> +        /* AMD IOMMU */
> +        struct {
> +            unsigned int paging_mode;
> +            struct guest_iommu *g_iommu;
> +        };
> +    };
> +};
> +
>  extern struct iommu_ops iommu_ops;
>  
>  # include <asm/alternative.h>
> @@ -109,10 +126,10 @@ static inline void iommu_disable_x2apic(void)
>          iommu_vcall(&iommu_ops, disable_x2apic);
>  }
>  
> -int iommu_identity_mapping(struct domain *d, p2m_access_t p2ma,
> -                           paddr_t base, paddr_t end,
> +int iommu_identity_mapping(struct domain *d, struct iommu_context *ctx,
> +                           p2m_access_t p2ma, paddr_t base, paddr_t end,
>                             unsigned int flag);
> -void iommu_identity_map_teardown(struct domain *d);
> +void iommu_identity_map_teardown(struct domain *d, struct iommu_context *ctx);

At the example of these: I think it shouldn't be necessary to pass both a
context and a domain into a function. The context likely should have a
back-pointer to the domain.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:21:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:21:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395560.1633884 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwi6W-0001y8-Pi; Wed, 19 Aug 2026 15:21:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395560.1633884; Wed, 19 Aug 2026 15:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwi6W-0001y1-Mu; Wed, 19 Aug 2026 15:21:24 +0000
Received: by outflank-mailman (input) for mailman id 1395560;
 Wed, 19 Aug 2026 15:21:24 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwi6V-0001xv-R3
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:21:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwi6V-00H0GY-7H
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:21:23 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a85c9e3-2eae-0a2a0a5409dd-0a2a4509c7d6-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:21:23 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a85c9f2-be1a-0a2a45090019-d1558033c8dc-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:21:23 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4956869750eso7395675e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:21:23 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9dffa59sm88551995e9.3.2026.08.19.08.21.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 08:21:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787152882; x=1787757682; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=MKNgMRpgXBs1k36yPifDtp69lXqrNZHJTAajRYMV7sM=;
        b=JJojtiyBcj0nTgco0uJIShuWaaMdI1ElHrm6ua39yc5hwyiBiFZ/KbGgtvhXuukRXB
         f5N5JGpW3ApPs/lkpHf1hifKG7Nu8Xx8Je2t9su8dMVi+rK2RIq33egWF/lNtnD7oOLM
         1kkTbGtDpHQoW9Vbarg87zrSedVrotftuM6kHMdKW+QHJefjYSQag2BSwJZvGm9m+zAx
         376Zuk9pUBkcNPLgzRT2Od7SNuBI38MVqYgebnhQ4Sj4AlSVgmO6y5rh/HN0IokVj8OF
         Jly/hp9RiDKaHUTrw3KbO/zyZKVBwWD2aDCrQ2Ttu8aPuQ8BW1zcU9q9SV9qKTstYRr+
         zyzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787152882; x=1787757682;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=MKNgMRpgXBs1k36yPifDtp69lXqrNZHJTAajRYMV7sM=;
        b=TzZqh5JMx1taaRd4BylP+qhKL5xFsyY5A05ogrZBkrXayx8JoBNz14d6bI9PJ64I3t
         DbvQ7aI1JZ1S9SpVvMf5xWFWwgAc+6Xm1CaxqsTAE6F4fOYXsCl82KjOHRT6OBLdHiPi
         Z3BnN+waO2tJR8Og8thNXNlapk6fYEqQBJkKDOJJLiMoa2UJuyjUxorXaNjPQgeHRTuW
         s9SteHJFI5aOke6BaJ1YynkCig24UaKSxayML09dXI3IVSwiSRxTZzyBwr8dnqFWX/Dq
         iqO9g0mtNeucVSK/9mC28of/RAK5N828MxydV6LN/hEiBiQ87htV9sqzxh3NRzr5SMvG
         o/wQ==
X-Forwarded-Encrypted: i=1; AHgh+RrnVnk/Bk0lyJv6mdn7emU4DsTMU8EPTLzBFD0cNCVK4hLOK0BkEzUomK2yAQsUQoKgO5pdkOiG5k0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzADh4NbkoKtBZbWXBWEMM4i4HclAXhmBIycgeCjfrBstn7fwAK
	0V9fWrFTNIZNVzv9hEP66emddYDCknkFeJC9wpjiKg3ZrISpPiXzenQcqMqYU4RfNpw=
X-Gm-Gg: AR+sD12Znkk8u7enY4uKuOOYf+s5ZG31LOL6R0DOrsKHybRHmyCwfu/Bf5MI6cYrqnj
	8JK4U5IRmz3uptnowDhLXGeNDTCbTwCA6i5Y8Ce0geIsYZQFzsismsI7Mqbd55YS/Kg89u3zzqZ
	QhomtDn+tV5g0JeFU72qkB9ETge/9n/gm0XH1hphrhnlhYmCk7N9mqDSmStwf7oCGMC16NeiasS
	FQgf0RAcfiqpB2moq88oO1toj70Nqm5AQEtxFYcSVGVvdD4/W826LJQot7UbfYes7pISYc76F6C
	8BugWIfZG0N/cIidtaV97TPozcVkOtoe52IzPvybwMPXUMjkY4TB7vQTAx8cgYClblmMfgKLvBs
	UHHGN63azey4/1A2HhJrbL/gaUlyH6liluRF8M0BGcbZQvlFF1zc4osZwtowOq0wholxuMN3QD8
	EH85Parestjk6d/7hl2cpg0oPb00oi0s+a/Em+HU28pDl90H8s7KqlQv96Tq5duJ3ztVymFoXLJ
	JYKGorEG1MBHEsgTkE1/oIYNYD9lKfVKppPbeB4Ztd+2DMDJ3nfVZHxC5WUnK+3H7mVHUCmcCaJ
	bLqYXcjxpLVPYQ==
X-Received: by 2002:a05:600c:5253:b0:499:79b9:e226 with SMTP id 5b1f17b1804b1-499aa109edbmr89278865e9.0.1787152881956;
        Wed, 19 Aug 2026 08:21:21 -0700 (PDT)
Message-ID: <819fea2f-7df9-484a-9565-80578cfdfa3c@suse.com>
Date: Wed, 19 Aug 2026 17:21:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org,
 dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
 linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org,
 linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org,
 kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org,
 linux-pm@vger.kernel.org, linux-coco@lists.linux.dev,
 linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org,
 linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Damien Le Moal
 <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>,
 David Airlie <airlied@redhat.com>, Helge Deller <deller@gmx.de>,
 linux-geode@lists.infradead.org, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Linus Walleij <linusw@kernel.org>,
 Bartosz Golaszewski <brgl@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Peter Zijlstra <peterz@infradead.org>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu Wen <puwen@hygon.cn>,
 Tony Luck <tony.luck@intel.com>, Reinette Chatre
 <reinette.chatre@intel.com>, Dave Martin <Dave.Martin@arm.com>,
 James Morse <james.morse@arm.com>, Babu Moger <babu.moger@amd.com>,
 Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki"
 <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>,
 Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe
 <rick.p.edgecombe@intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Len Brown <lenb@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>,
 Huang Rui <ray.huang@amd.com>, Mario Limonciello
 <mario.limonciello@amd.com>, Perry Yuan <perry.yuan@amd.com>,
 K Prateek Nayak <kprateek.nayak@amd.com>,
 Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>, Guenter Roeck <linux@roeck-us.net>,
 Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
 Artem Bityutskiy <dedekind1@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
 Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@intel.com>,
 Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
 Lukasz Luba <lukasz.luba@arm.com>, xen-devel@lists.xenproject.org
References: <20260819102314.1499258-1-jgross@suse.com>
 <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Hc4PeuQ841RPSm0B83GP3ggL"
X-purgate-ID: tlsNG-bad1c0/1787152883-BECDF034-945D9B91/0/0
X-purgate-type: clean
X-purgate-size: 10551

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Hc4PeuQ841RPSm0B83GP3ggL
Content-Type: multipart/mixed; boundary="------------TnQmW2xUHDfryHdoV1v2DtYY";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org,
 dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
 linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org,
 linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org,
 kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org,
 linux-pm@vger.kernel.org, linux-coco@lists.linux.dev,
 linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org,
 linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Damien Le Moal
 <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>,
 David Airlie <airlied@redhat.com>, Helge Deller <deller@gmx.de>,
 linux-geode@lists.infradead.org, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Linus Walleij <linusw@kernel.org>,
 Bartosz Golaszewski <brgl@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Peter Zijlstra <peterz@infradead.org>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu Wen <puwen@hygon.cn>,
 Tony Luck <tony.luck@intel.com>, Reinette Chatre
 <reinette.chatre@intel.com>, Dave Martin <Dave.Martin@arm.com>,
 James Morse <james.morse@arm.com>, Babu Moger <babu.moger@amd.com>,
 Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki"
 <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>,
 Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe
 <rick.p.edgecombe@intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Len Brown <lenb@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>,
 Huang Rui <ray.huang@amd.com>, Mario Limonciello
 <mario.limonciello@amd.com>, Perry Yuan <perry.yuan@amd.com>,
 K Prateek Nayak <kprateek.nayak@amd.com>,
 Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>, Guenter Roeck <linux@roeck-us.net>,
 Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
 Artem Bityutskiy <dedekind1@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
 Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@intel.com>,
 Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
 Lukasz Luba <lukasz.luba@arm.com>, xen-devel@lists.xenproject.org
Message-ID: <819fea2f-7df9-484a-9565-80578cfdfa3c@suse.com>
Subject: Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
References: <20260819102314.1499258-1-jgross@suse.com>
 <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
In-Reply-To: <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>

--------------TnQmW2xUHDfryHdoV1v2DtYY
Content-Type: multipart/mixed; boundary="------------TnjqcXnTcN66nC2lLK07OASL"

--------------TnjqcXnTcN66nC2lLK07OASL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTkuMDguMjYgMTY6NDAsIERhdmUgSGFuc2VuIHdyb3RlOg0KPiBIZXkgSnVlcmdlbiwN
Cj4gDQo+IFRoZXNlIGxvb2sgZ3JlYXQuIFRoYW5rcyBmb3IgZG9pbmcgaXQhDQo+IA0KPiBU
aGUgb25seSB3b25reSB0aGluZyBpcyBob3cgd2UncmUgZ29pbmcgdG8gYWN0dWFsbHkgbWVy
Z2UgaXQuIFdlDQo+IG9idmlvdXNseSBjYW4ndCBkbyBwYXRjaGVzIDEwLTExIHVudGlsIGFs
bCB0aGUgInN0b3AgdXNpbmciIHBhdGNoZXMgaGF2ZQ0KPiBiZWVuIGFwcGxpZWQuDQo+IA0K
PiBJIG9idmlvdXNseSAxMDAlIHJlYWxpemUgdGhhdCBpdCdzIGR1cmluZyB0aGUgbWVyZ2Ug
d2luZG93LCBidXQgYW55IGFja3MNCj4gdGhhdCB0aGUgbWFpbnRhaW5lcnMgb2YgNS05IHBy
b3ZpZGUgaW4gdGhlIG5leHQgZmV3IHdlZWtzIHdvdWxkIGJlIHN1cGVyDQo+IGhlbHBmdWwu
IE9yLCBpZiBhbnkgb2YgdGhvc2UgbWFpbnRhaW5lcnMgd2FudCB0byBjaGVycnkgcGljayB0
aGVpcg0KPiBzdWJzeXN0ZW0ncyBzdHVmZiBvdXQgb2YgdGhpcyBzZXJpZXMgYW5kIGFwcGx5
IGl0LCB0aGF0IHdvdWxkIGJlIGdyZWF0IHRvby4NCj4gDQo+IEJ1dCwgdGhlIGxhc3QgdGlt
ZSB3ZSBkaWQgc29tZSBNU1IgZnVuY3Rpb24gbXVuZ2luZywgdGhlIHRpcCB0cmVlDQo+IGNh
cnJpZWQgbW9zdCBvZiB0aGUgcGF0Y2hlcy4gSSB3b3VsZCBleHBlY3Qgd2UnbGwgaGF2ZSBh
IHJlcGVhdCBvZiB0aGF0DQo+IGhlcmUgdG9vLiBJJ2xsIHBlbmNpbCBpbiB0aGUgaWRlYSBv
ZiBqdXN0IG1lcmdpbmcgdGhlIGxvdCBhcm91bmQgLXJjMSB0aW1lLg0KDQpJbmdvIHJlcXVl
c3RlZCB0aGlzIHNlcmllcyB0byBiZSBjYXJyaWVkIHRocm91Z2ggdGhlIHRpcCB0cmVlLg0K
DQoNCkp1ZXJnZW4NCg0K
--------------TnjqcXnTcN66nC2lLK07OASL
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------TnjqcXnTcN66nC2lLK07OASL--

--------------TnQmW2xUHDfryHdoV1v2DtYY--

--------------Hc4PeuQ841RPSm0B83GP3ggL
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqFye4FAwAAAAAACgkQsN6d1ii/Ey+U
SAf8C8haRR6O0CCShzFFYF1D7zhf+INyEBxTFvh5fq5QSa2E0aTWRzrn9ZHLe6z7fRE5/VsjIWJW
Wv+uKkLyygytd0ZT/GRy6kcNe/ZXUfnmmjl4yX97epKZY9piuLckqPyKGDTINYQYCUJhwhRcBtU8
QgLvU3AibgE96qSyLjBZbjX5raJrBq+SoXpf3eUKQTfGhO+UgmwRr6QKVYFJISjaEsWGxfaCizwW
ahMu/cKoa67H1yUC0LHEBdKJu0MZbTgR6SuwUbyHTsCiO7oVBRblyWEIDNUdSPNm3FGHbRMoQx+f
LJyOH4+/xJ6CwkTpHibkwDMlRNYMS0IC7i1B0GMXlw==
=AZsj
-----END PGP SIGNATURE-----

--------------Hc4PeuQ841RPSm0B83GP3ggL--


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:21:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:21:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395564.1633894 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwi75-0002M5-1c; Wed, 19 Aug 2026 15:21:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395564.1633894; Wed, 19 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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wwi74-0002Ly-UQ; Wed, 19 Aug 2026 15:21:58 +0000
Received: by outflank-mailman (input) for mailman id 1395564;
 Wed, 19 Aug 2026 15:21:57 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwi73-0002Ln-G6
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:21:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwi72-0035n1-T3
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:21:56 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85ca03-e002-0a2a0a5209dd-0a2a45028e46-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:21:56 +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 <jbeulich@suse.com>)
 id 6a85ca14-6ca4-0a2a45020019-d1558036e105-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:21:56 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-49554ebb87dso12114215e9.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:21:56 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa17fc80sm72889305e9.14.2026.08.19.08.21.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 08:21:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787152916; x=1787757716; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=4knUFfMmt2eXsg6zvk2plIhzZPfzCn/JZd/OrHbzN8I=;
        b=abbBGHvCVfbXZcTT0xx0Pvyp2D9h3xWEGQde1up0LiouVyr/q4jA3MIHzo0M6VEZcV
         sTt7jE3RdvqK+v+5HoAS4NhVQjvUIWIdFnQseIoCn2JhxXlSAPwB43aTvsnh/wXu1v5d
         RIbKLPcooM02AtbRhT7eE3zT3hy4jW7uYSXaFzLmOIQyfCCP9kLWYviq46GPmeKV5HKY
         TKv1jNX2QYzdWMD59J2a5qsCz/roFf+cfl3MGzqLgCs7QnEVJDbMrUQ8ZDi5kZNak/ad
         cW+/vK3ufnT4WFHIZY3uq1LART+NG/lzZGOVF1b0j5wlUjcoFgck2uHBup54ACe21/Be
         /rqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787152916; x=1787757716;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=4knUFfMmt2eXsg6zvk2plIhzZPfzCn/JZd/OrHbzN8I=;
        b=G4o8J/ctTCzSEyBfztnxT5SloEPd5OcYHmwYdsRrN4PUV1Df7C0N+ybu3jPq6Ji64U
         ut6vbABQYp9/aJamy8PRO9sufmcFIvtlh8n86vsTulqhGZTgSeBo1RhOI9/wjkGHsDk6
         PEHalds9Ul6cAIeRMlDMUq0jECovEAifLy7afUbVk+DLNrn24/vaF6k2sP1X4r1p8Sta
         d6Gkr7th4Rct/3whiwHNjDN/+XlxRNlSWdAQPGJYp3M7+tJhZnrGjvN1Vh/+XT9jbFUE
         w5xhLSycBAw3RTf+28NCeki3z2xvURG5WBzRvmo+jZceKGX4+43dvUAVMCVrcSscvQrz
         OOSg==
X-Forwarded-Encrypted: i=1; AHgh+Rojt+FUc/VU4TAw+ioP6QEjtQjt+S3TbsrZyEfdMgQHmGnLVZnJ7a4HAPuPJPGB/QsdDS0wAXUx7N0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxia1AcJ0uY1aw6RDrmcUkUS8VPleKCupdz13gsM33Mp9jPd6iU
	dlZagtBeDWoNIjd26bdx0uUIzBzrRg/3k7ZtqvkK7MOz9SE5M9AZrJ5ALc0Ru81Bcw==
X-Gm-Gg: AR+sD11hToXxIK29GE1r1QkQ7JM5XOi2v0nWXmr5GYgCn8wlItjskCYlJhU7hz2WdPH
	BLs1Q/GRBCUWTSrIQXBs9yjPUp79Scj43CfeFl7C7BYWOkKnoVBy1++b7vsP6frv8gFrropp0QI
	jN4B8Tesbkxcy1ully2lR2NwW6R/a13z40fvLmaCxVfLDoL5PkY12wfaYH4GK+RMxK0ai+2wQu5
	jRtMXE6oE0kxV3kO19IcG1nW62DO7cGbNEYbG885msvwRIHmrLSC9SQJ8F8NQaDo/Z/QTGdfuhK
	9iEnEbBvcwr7uV8HuWruKtZ2VcSjJiX2og8vmWj/8PH1dgg/Jh/7Bbnms/J9WZhqzQ5V2I3NECC
	Mq11DzeV3DA/acmZpsvPIsyhm2LT8Hpd2Gnt98bkWYFYbyh5ERFZH9LIvcCfMu1CDjGPYxtbrEs
	YuvFF8A3/Y/JNaiIonSSoLrXruJ/OmwTCF1KMew32ZqMsOgGW+R6eIgAjSKJ3DFbgbGy7lLzLFR
	RYZVmfIx9e7/fJfnPpJrZJ/5zamoNhEPbY+cZ/E5eAB8ZKBen/E
X-Received: by 2002:a05:600c:37c6:b0:499:8f9f:e9ee with SMTP id 5b1f17b1804b1-499aa173a16mr109156325e9.7.1787152916266;
        Wed, 19 Aug 2026 08:21:56 -0700 (PDT)
Message-ID: <1e6aa092-778f-4826-8013-aa527a4858eb@suse.com>
Date: Wed, 19 Aug 2026 17:21:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v7 05/14] iommu: Simplify quarantine logic
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Jason Andryuk <jason.andryuk@amd.com>, xen-devel@lists.xenproject.org
References: <cover.1763569135.git.teddy.astie@vates.tech>
 <31b2ede1eab92048b69fe4999a35eb7d4a4617ba.1763569135.git.teddy.astie@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <31b2ede1eab92048b69fe4999a35eb7d4a4617ba.1763569135.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787152916-676BF2AC-69426B25/0/0
X-purgate-type: clean
X-purgate-size: 680

On 20.11.2025 12:09, Teddy Astie wrote:
> Current quarantine code is very hard to change and is very
> complicated, remove most bits of it and replace it with direct
> reassignement to dom_io domain instead.

Well, again far too little of a description, even when taking ...

> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> A idea would be to rework this feature using the new reworked
> IOMMU subsystem.

... this sentence into account: As I can't spot replacement of present logic
(fill_qpt() being a prime example) - how is existing behavior retained? I
can't help the impression that you simply lose functionality, which is not
an option.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:26:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:26:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395576.1633902 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiBg-000321-Ib; Wed, 19 Aug 2026 15:26:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395576.1633902; Wed, 19 Aug 2026 15:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiBg-00031u-Ed; Wed, 19 Aug 2026 15:26:44 +0000
Received: by outflank-mailman (input) for mailman id 1395576;
 Wed, 19 Aug 2026 15:26:43 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwiBf-00031o-0q
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:26:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiBe-009wG1-92
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:26:42 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85cb15-bab6-0a2a0a5309dd-0a2a4504aeb2-42
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:26:42 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a85cb31-b57f-0a2a45040019-d155dd35b866-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:26:41 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47362928f65so1062539f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:26:41 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14514d5sm6511823f8f.10.2026.08.19.08.26.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 08:26:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787153201; x=1787758001; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=NAjSeqGo8bCvuUajX1CJPX/BVd8Amvrb66bC1ViYuAY=;
        b=f4Lhrw5XdL5+o8j6F8G6wKFzhYTEHyPbEnuiK53AGYI0xLCbOY31uo5iVGxynmAa4g
         zj2bs3nX1nsOMD0GEhcjgoLjsXPZ943PMqCX3fpM1NPDHcnfv0sD0VLp6zqvEytu2O9j
         a78GJlJEILVvhoLpUJsKe7OhfViXrjInagxMcxVX42ozna53nhxbHBCs1wV6pK8Hv3sp
         Wm64ix4OvqbpqKTDLbwxnHniYWYUGxcbdwm0YyWVYk0mazKPkDePMNx9ANNXUshDm/iG
         9V9HOY4QqWMEp+EvNtnzA7l7OkA84HkiQNyxeArd2lWdSU5h/FvrwqY//Za4dTqoQbU2
         E0RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153201; x=1787758001;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=NAjSeqGo8bCvuUajX1CJPX/BVd8Amvrb66bC1ViYuAY=;
        b=bPFsqmzYeoZelUt/C/SE44qFsiHw5sgnQ4nDhY6iUVaOg5aOM5Rv12Rxu9UnUY+xFn
         YnDsD67PGMQ5+mC1csBnmAE7BCu09kVSPVCIbUp3AbOttr4BlfsOx3e3KRkYpplVc02v
         xyYQPbSNFlgWq5SfsrtmApwjEVK/V8WADovLbEXbo0+maZSTSJ/pZ7RXpVIfIgRTd7X7
         t1DmSuXphkgnhkbkFMJodei7DxSKL9Be4NyQZZvshoFrWmrZeMufOQ2zv0ffkk3Dj0xo
         jmUD36VK/0CoUZ3gI+850bB1Zpa6LgIwDNLZvQiztZ1/eiK2p20GTGNT4rl7xhBFjXCu
         WqLQ==
X-Forwarded-Encrypted: i=1; AHgh+RouqenZxE5eqV/rMTUvn8WuBxvkgWjE5Y6PtChQblIVu0e2Jp0xxUeo3dwBa4q84Z2NFfNZKL2V+qc=@lists.xenproject.org
X-Gm-Message-State: AFuF++kGR75plL4JgyT/dyO/Iij9Q22SMoxZWV11Cfmtl7PoRHGvNq55
	v38H+mmqHaa9y/7sLbD5HgnzOu5UsGfLSdUHousMBoepRRBrO0bRsaICb1rpcl/h0w==
X-Gm-Gg: AR+sD13mYvdaQJxXDcpu2WAIJliiSC4kFx5SkqlsbL/JPRQN6h7XIpR/Xmu3iGKUOSr
	uGxlYMCTKvf8ag2iazS5fucqaOvdd3EGMHfHHbXjuCFl0CtMpg72CTd1Ez1rF8Nlnub8Kpcr25b
	Q6QTCBhVMSYRvb+wCIf0yhkqT3Fjy6eVxOMgAqmkke+5VMj/JMvpOs7Bjycjpdtl0m+mCO4JMst
	HWwZcc0Yth/MNz8ehLAsnTYOTsI2RNAGBVrmafMI/FBsqmNjPzvrKpV1QCAsQtVB01mD8jIaA+7
	KFheL1QLtku8p1a2E1pAe3eWaU4OArNPDzu8+48w3b2+dd6TNSAivR6kIqPhx0b9sKj064Hnobo
	kDsvCvISTomofd8fY3skAwvNOu60HdVWwtEissHoj2iKORuEtvQiFyU6mCKyIeUV34j+FXUmtTx
	LgWHrWP5reqLW4biN8pXBdeGAOQosVEy6js4BHU7IjeLF0orFZd8VOelvGsVrDHZtwZXkDZQ+aj
	6T5qKzzD2JoJpiNRht4DN7NhhaIkx6sI0i5YuwqvJFLyjnmJWAJ
X-Received: by 2002:a5d:5e8c:0:b0:47f:9283:1fbe with SMTP id ffacd0b85a97d-482b1e22ed5mr10476645f8f.0.1787153201393;
        Wed, 19 Aug 2026 08:26:41 -0700 (PDT)
Message-ID: <8fc44fb5-9541-4039-ab01-9db9fc327fb9@suse.com>
Date: Wed, 19 Aug 2026 17:26:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v7 06/14] vtd: Remove MAP_ERROR_RECOVERY code path in
 domain_context_mapping_one
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <cover.1763569135.git.teddy.astie@vates.tech>
 <149e3a765a5a55792be7af0a4d9c0ca9fb5098c6.1763569135.git.teddy.astie@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <149e3a765a5a55792be7af0a4d9c0ca9fb5098c6.1763569135.git.teddy.astie@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787153201-520D5B50-5B79DAB5/0/0
X-purgate-type: clean
X-purgate-size: 918

On 20.11.2025 12:09, Teddy Astie wrote:
> This logic is basically never called as the only possible failures are
> - no memory to allocate the pagetable (if it isn't already allocated)
>   this is fixed in this patch serie by ensuring that the pagetable is allocated
>   when entering this function
> - EILSEQ when there is a race condtion with hardware, which should not happen under
>   normal circonstances
> 
> Remove this logic to simplify the error management of the function.

But this code was added for a reason, yet you (again) don't make clear why
the change you make is correct. Putting in place something else _later_ in
the series isn't really an option. Things need to work at every patch
boundary.

Considering that (long ago) you indicated anyway that you'd work towards
better splitting up some of the large patches here, I think I'll stop here,
waiting for a re-submission.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:28:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:28:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395586.1633911 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDP-0003qM-1R; Wed, 19 Aug 2026 15:28:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395586.1633911; Wed, 19 Aug 2026 15:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDO-0003qF-Uv; Wed, 19 Aug 2026 15:28:30 +0000
Received: by outflank-mailman (input) for mailman id 1395586;
 Wed, 19 Aug 2026 15:28:29 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwiDN-0003ow-GW
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:28:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiDM-00FCv4-TY
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:28:28 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cb81-e002-0a2a0a5209dd-0a2a45079170-38
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:28 +0200
Received: from [209.85.215.180] (helo=mail-pg1-f180.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cb9b-b4ea-0a2a45070019-d155d7b4bd9e-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:28 +0200
Received: by mail-pg1-f180.google.com with SMTP id
 41be03b00d2f7-cc1469c1b83so1231314a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:28:28 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-851d3617434sm787575b3a.29.2026.08.19.08.28.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 08:28:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787153307; x=1787758107; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=gURzRJNpCSIB7YbDliLuIS2za+vACAoh58p0svjXRV4=;
        b=iNMcwqjP3Utj54zOzdc60guVMJbGhSUMIskBOG49MZ+YdtVV+pGqpiMZjuLjyiBPxO
         xbfzhVmDbEnOctILZUzZ0fjov3HBwbvKpsO3rviLO0UE+7VM/YhDYgRFeovG/Z8xvoyu
         Kq8ZEDcxJqFgBfZ3Oavt2SQzVWX2m9FrAjzzPOcRXcsCanEr2OrM2aZzRJ8IkNsxgNkz
         HWT/NiqWGml5+uZo4vmLHadAJqRcT9k5C3+nMAcnjI5W/qkxfVHMSR6kE7Qo1NmvC8xD
         DlxdFU4bWrJcS6swQY81ZhL5xhexOMBKtd6Dddn7SdUE7CBh4G9ce16rplKMrIYWJgpF
         KDeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153307; x=1787758107;
        h=content-transfer-encoding:mime-version: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=gURzRJNpCSIB7YbDliLuIS2za+vACAoh58p0svjXRV4=;
        b=VGa5Irmyh9XneO27cIwmypMtpWpgmvDWLG3BjiD6bJwyN7V/wUGJHXGeRA0jAfMxFL
         +wTXYIkbHbhsVLozIOiLcjE2F/JLAw3Pi3DuH9nVfyCe+Q1OD2hpkIuQALsTd1jx1d3b
         ORwdbCeeE+UOiR3QZhKzMOMxSuledxQvjpdUE29kqycz0vBQ6ZSIvKkgrpWF9K54Ly7t
         tbF8/HGMHG5fl69fxLBccEaFUdFWQQWzvtr+Ve7OZNBsiztO8FbPX1G88NZsN94lEKhR
         etghwwwzNWc+uGzaUwihGosvCQtmb9izXdeHoFVeNK0O5FPelTDKrfUu7QecAnMoDdFR
         Vfgw==
X-Gm-Message-State: AOJu0Yzi/D0HbFpWV9AoBHApvrdOZQgIs0XDHylX2HWBdsu1h9VDLl0g
	aR8wmc3tCYoKFS7L2ed+Vr1XTpF+eqRkL7rP2Zlke0c4AGu02sW0dHXrzxCwbdn4
X-Gm-Gg: AR+sD11xwBvnAWbdpw/GpQdi3spgoGzb5TxAbM1I8xxdA6e/oxkayy70HsfBhB5R7jx
	ZfPVvyGi1vUClPbLUUwiA1CU7H5hgL4uF+2iJzCJtlss48jVRm3nyOnz19w7cAVBTKSYamd6eCp
	YzsF1l+XZcfrNyeQTtx+vXCUBIO6R9INYOXOUWNh8WI2/SIoBYi+4RLAcgdux4xIHiuU5kpGBhe
	v1UESxBVJ+KUynuRjLwxfTlqH7juLBIGHfrPPcm1HJXQghJUR50OzRqzQ32bSRTYS0u7OXC2O2c
	blKycQPJbqJqkBFRvjfuiIyPBl0KP6QdNoxv5pZBv4+ILXVCU2HCPlSf9AcFUC8TeLt1/75uDXU
	/AwZFzJN0K17gQ9F608ExV48eqkUgV4snw6B18+tDgjTL5020HeM5SiDMuiCWoy+K5KvmkUI++5
	tNJKu6ngPIOTp0PmfKs9Cxq2jYSm5X4rUEqdKTHyz/u2/8XbjGPxNcUMqrkkpFXv/br+oZ2NeDe
	iWqX2E1czjchI2Zweyp5Pg2kbi93wXQuJJSmmRaqZI=
X-Received: by 2002:a05:6a00:4009:b0:848:4754:28e4 with SMTP id d2e1a72fcca58-851d3a93294mr10104827b3a.15.1787153306718;
        Wed, 19 Aug 2026 08:28:26 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
Subject: [PATCH v4 0/4] xen/arm: add i.MX8M platform and UART support
Date: Wed, 19 Aug 2026 23:28:17 +0800
Message-ID: <20260819152821.3361898-1-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787153308-37AD0AE4-8276DB7D/0/0
X-purgate-type: clean
X-purgate-size: 2814

This series adds Xen support for the NXP i.MX8M family (i.MX8MP / MQ /
MM / MN).  It provides the console UART driver, its early printk, the
platform glue (SiP SMC whitelist for the calls the dom0 kernel issues
to TF-A), and a MAINTAINERS entry.

Tested on i.MX8MP (4x Cortex-A53, GICv3) with the vendor kernel 6.18:
dom0 boots to login on the hypervisor console, and a domU starts with a
PV disk and virtio devices running a full Wayland distro.

Notes for reviewers:

- Unlike i.MX8MQ, the i.MX8MP device tree uses the GIC as the root
  interrupt controller (interrupt-parent = <&gic>), so no device-tree
  workaround is needed and power domains keep working.

- The i.MX8M family has no SMMU, so device passthrough relies on the
  1:1 direct-mapped hardware domain.

- The SiP SMC whitelist forwards only the specific subfunctions the
  dom0 kernel issues, extracted from the vendor kernel call sites.  CPU
  and DRAM frequency scaling are both denied: the hardware domain
  cannot make an informed decision about resources it shares with the
  other domains.  dom0's i.MX8M DDRC devfreq driver issues the DDR DVFS
  call at boot; with it denied that driver just skips DRAM frequency
  scaling (the DRAM stays at the frequency set by firmware) and dom0
  boots normally.

Changes since v3:

- Patch 3: filter the SRC and NoC subfunctions with an explicit switch
  that lists each accepted subfunction, instead of a range check
  (Michal Orzel).  The NoC service now accepts only the QoS priority
  subfunction, and the unknown-function-id warning also prints the
  subfunction id.
- Patches 1, 2 and 4 are unchanged; all four patches now carry Michal's
  Reviewed-by.

Per-patch changelogs are in each patch.

v3: https://lore.kernel.org/xen-devel/20260818153946.1635464-1-onlywig@gmail.com/

Wig Cheng (4):
  xen/char: add classic i.MX UART driver
  xen/arm64: add early printk for the classic i.MX UART
  xen/arm: add i.MX8M platform support
  MAINTAINERS: add myself as reviewer of i.MX8M related patches

 MAINTAINERS                           |   8 +
 xen/arch/arm/Kconfig.debug            |  12 ++
 xen/arch/arm/arm64/debug-imx-uart.inc |  37 ++++
 xen/arch/arm/include/asm/imx-uart.h   |  57 +++++++
 xen/arch/arm/platforms/Makefile       |   1 +
 xen/arch/arm/platforms/imx8m.c        | 161 ++++++++++++++++++
 xen/drivers/char/Kconfig              |   8 +
 xen/drivers/char/Makefile             |   1 +
 xen/drivers/char/imx-uart.c           | 233 ++++++++++++++++++++++++++
 9 files changed, 518 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/arch/arm/platforms/imx8m.c
 create mode 100644 xen/drivers/char/imx-uart.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:28:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:28:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395587.1633920 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDS-00043x-8G; Wed, 19 Aug 2026 15:28:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395587.1633920; Wed, 19 Aug 2026 15:28:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDS-00043q-5U; Wed, 19 Aug 2026 15:28:34 +0000
Received: by outflank-mailman (input) for mailman id 1395587;
 Wed, 19 Aug 2026 15:28:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwiDR-00043E-8S
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:28:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiDQ-001HxZ-Le
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:28:32 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cb88-2eae-0a2a0a5409dd-0a2a45068b12-32
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:32 +0200
Received: from [209.85.210.179] (helo=mail-pf1-f179.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cb9f-195a-0a2a45060019-d155d2b3f151-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:32 +0200
Received: by mail-pf1-f179.google.com with SMTP id
 d2e1a72fcca58-84862b0d5f8so983290b3a.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:28:32 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-851d3617434sm787575b3a.29.2026.08.19.08.28.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 08:28:28 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787153310; x=1787758110; 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=FBaWu89tr1O3ae9E4zrFCri6nPdlnyNL6tarjmgqd28=;
        b=qtFgaYVe7P16dqvKfLHotcAmkmXK5JVg/JXQwXjWt8MQXmJHws3rpQvB7r5yMhJcza
         OZ/EudlZZcbKIiVgPwbDcmngRae22YbPPFEkZXk0CUMzKUoUslORojBA5XTNYzri6kDs
         hS7tduVEeH+OSozic+9uzVCnWnk440I30CZK/tfE1GBY6g/2tfHGEmujF8eBO6U3MJGJ
         Xr9/y0LuQ2xHMazTxHePPKbbTAirVs151jG2QKXXTjVLRwMbPJVp2F3a9UcplBLs/xX1
         yY/yG61JF/vffOg+j2J/LDi7x4TvvsYHxilrh/I+/Fy4ncI0caRsqxb9lAMF3+oSAFhr
         ETkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153310; x=1787758110;
        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=FBaWu89tr1O3ae9E4zrFCri6nPdlnyNL6tarjmgqd28=;
        b=LGBBD4SnqgcGzApohfvAOX5GX8oG06EETx+L6E7GDF0vRAdiGgvu1dp5oRBmSht4Tg
         R3gNLGGuRJ1A/FW4UUBwqeVA3ACMZpXzzArAb8NRExCntukcBraZbQ5qdBVYuihzTR/K
         Tf6ik+Wts/IOXyQ84Xvdq5wqb9hyPMZyWyOvFQCAjfUgBvXDq4Rsum20gY7iJj4ehIyU
         MKB+2g3PLLeNn99TspQbxWcQTs6FLKw68BPCvTeIhvWtiXbORtgaSEpsA1JZHhY6qf5x
         mPBz9F6lmECp/cjcK/sdKYNbdrFYJO1fshooGTKQmbfccgiYhkpe5WZelZuVfBas+3MN
         4Gpw==
X-Gm-Message-State: AOJu0YwY79SrLW1KEKSWVnMJnJbjit1quhPUuaiK4ClFzIDvTjQgEbHB
	oBBdbvtyMXFfHX1Ng9uRtlwoW+9r3Wl9ut1Xk2T7dDMXKHO7iWzbqLYe6bi208ZG
X-Gm-Gg: AR+sD13ikSKxe+/ysZtb1/T5iKMIM0Q6Toy8qxe22YrDbjw5x7ljjovRuEK09CVKKAs
	EM98cXzO1xMh7qmGUdUqvXiB8Pmklq9UdY80WrjqWucM+LUNpNkYTYH+hNjwLLK6HgBCn8X2gnc
	MNIlRO4HCjXWmSYWD9TKhN5yDBAyxYhyNA58/voo3AJQB//M3lDM7VUL6sb9o9AGmTW72imWNWv
	kjVYHPhyeDfmgG1izAGgOZVMaLU1NJykrkqpXHrj93WoDalwc5YXtjWJf4yWmX9L3JKQS4xgGm0
	VxEZiEmt4OHbI9SOSZIMhHOWAZR2glUFvM4Q6DgnArlTAfgllBMYXYelGQpagZhArqTsOwsnQL8
	YygsnCqdgFB5hkUJOH66t1StvLG1/z15NagGlMxfmZIdwgoD+jQ/DhpOgRcuP+3j0Vc9Ib8BnX7
	4JkvcMbls3MS4tJv/90WbMjzKB7MF3o4V0iV+7HDBFF/WAeGJ2nX4I7F9Qy6cwno4lManN3jG33
	NHHPSnXfeeFYUzrnwD7D23Mz3f1HAP0
X-Received: by 2002:a05:6a00:22ca:b0:84e:4d6:78fe with SMTP id d2e1a72fcca58-851d3807df1mr8953418b3a.3.1787153309563;
        Wed, 19 Aug 2026 08:28:29 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
Subject: [PATCH v4 1/4] xen/char: add classic i.MX UART driver
Date: Wed, 19 Aug 2026 23:28:18 +0800
Message-ID: <20260819152821.3361898-2-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260819152821.3361898-1-onlywig@gmail.com>
References: <20260819152821.3361898-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787153312-FEC7777B-F173E3FC/0/0
X-purgate-type: clean
X-purgate-size: 11487

Add a console driver for the classic i.MX UART IP ("fsl,imx6q-uart"
compatible), used as the console UART on the i.MX8M family.  Baudrate
and pin configuration are inherited from the bootloader; the driver
only enables the transmitter/receiver and wires up the RX/TX
interrupts, mirroring the existing imx-lpuart driver.

The i.MX8M family's UART IP differs from the LPUART used on
i.MX8QM/8QXP, so a separate driver is needed.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v4:
- No code changes; picked up Michal's Reviewed-by.

 MAINTAINERS                         |   1 +
 xen/arch/arm/include/asm/imx-uart.h |  57 +++++++
 xen/drivers/char/Kconfig            |   8 +
 xen/drivers/char/Makefile           |   1 +
 xen/drivers/char/imx-uart.c         | 233 ++++++++++++++++++++++++++++
 5 files changed, 300 insertions(+)
 create mode 100644 xen/arch/arm/include/asm/imx-uart.h
 create mode 100644 xen/drivers/char/imx-uart.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ed0ffa608f..4dd97ffcad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,6 +269,7 @@ F:	xen/arch/arm/
 F:	xen/drivers/char/cadence-uart.c
 F:	xen/drivers/char/exynos4210-uart.c
 F:	xen/drivers/char/imx-lpuart.c
+F:	xen/drivers/char/imx-uart.c
 F:	xen/drivers/char/meson-uart.c
 F:	xen/drivers/char/mvebu-uart.c
 F:	xen/drivers/char/omap-uart.c
diff --git a/xen/arch/arm/include/asm/imx-uart.h b/xen/arch/arm/include/asm/imx-uart.h
new file mode 100644
index 0000000000..a3892020e6
--- /dev/null
+++ b/xen/arch/arm/include/asm/imx-uart.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Register definitions for the classic i.MX UART IP
+ * ("fsl,imx6q-uart" compatible), used as the console UART on the
+ * i.MX8M family.
+ *
+ * Register layout taken from Linux drivers/tty/serial/imx.c.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#ifndef ASM_IMX_UART_H
+#define ASM_IMX_UART_H
+
+#include <xen/const.h>
+
+#define URXD0           0x00   /* Receiver Register */
+#define URTX0           0x40   /* Transmitter Register */
+#define UCR1            0x80   /* Control Register 1 */
+#define UCR2            0x84   /* Control Register 2 */
+#define USR1            0x94   /* Status Register 1 */
+#define USR2            0x98   /* Status Register 2 */
+#define UTS             0xb4   /* Test Register */
+
+#define URXD_RX_DATA    0xff
+
+#define UCR1_UARTEN     BIT(0, U)   /* UART enable */
+#define UCR1_ATDMAEN    BIT(2, U)   /* Aging DMA timer enable */
+#define UCR1_TXDMAEN    BIT(3, U)   /* Transmitter ready DMA enable */
+#define UCR1_TXMPTYEN   BIT(6, U)   /* Transmitter empty interrupt enable */
+#define UCR1_RXDMAEN    BIT(8, U)   /* Receiver ready DMA enable */
+#define UCR1_RRDYEN     BIT(9, U)   /* Receiver ready interrupt enable */
+#define UCR1_TRDYEN     BIT(13, U)  /* Transmitter ready interrupt enable */
+
+#define UCR2_SRST       BIT(0, U)   /* 0 = issue software reset */
+#define UCR2_RXEN       BIT(1, U)   /* Receiver enable */
+#define UCR2_TXEN       BIT(2, U)   /* Transmitter enable */
+
+#define USR1_TRDY       BIT(13, U)  /* Transmitter ready */
+
+#define USR2_RDR        BIT(0, U)   /* Receive data ready */
+#define USR2_ORE        BIT(1, U)   /* Overrun error */
+
+#define UTS_TXFULL      BIT(4, U)   /* TX FIFO full */
+#define UTS_RXEMPTY     BIT(5, U)   /* RX FIFO empty */
+#define UTS_TXEMPTY     BIT(6, U)   /* TX FIFO empty */
+
+#endif /* ASM_IMX_UART_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 8e49a52c73..f237c0220d 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -30,6 +30,14 @@ config HAS_IMX_LPUART
 	help
 	  This selects the i.MX LPUART. If you have i.MX8QM based board, say Y.
 
+config HAS_IMX_UART
+	bool "i.MX UART driver"
+	default y
+	depends on ARM_64
+	help
+	  This selects the classic i.MX UART. If you have an i.MX8M family
+	  based board, say Y.
+
 config HAS_MVEBU
 	bool "Marvell MVEBU UART driver"
 	default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 8cbbffdca8..039f566926 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_HAS_SCIF) += scif-uart.o
 obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_XHCI) += xhci-dbc.o
 obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
+obj-$(CONFIG_HAS_IMX_UART) += imx-uart.o
 obj-$(CONFIG_HAS_LINFLEX) += linflex-uart.o
 obj-$(CONFIG_GENERIC_UART_INIT) += uart-init.o
 obj-y += serial.o
diff --git a/xen/drivers/char/imx-uart.c b/xen/drivers/char/imx-uart.c
new file mode 100644
index 0000000000..2dc531a84e
--- /dev/null
+++ b/xen/drivers/char/imx-uart.c
@@ -0,0 +1,233 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Driver for the classic i.MX UART IP ("fsl,imx6q-uart"), used as the
+ * console UART on the i.MX8M family (e.g. i.MX8MP).
+ *
+ * Baudrate and pin configuration are inherited from the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/irq.h>
+#include <xen/mm.h>
+#include <xen/serial.h>
+#include <asm/device.h>
+#include <asm/imx-uart.h>
+#include <asm/io.h>
+
+#define imx_uart_read(uart, off)       readl((uart)->regs + (off))
+#define imx_uart_write(uart, off, val) writel((val), (uart)->regs + (off))
+
+static struct imx_uart {
+    uint32_t irq;
+    char __iomem *regs;
+    struct irqaction irqaction;
+    struct vuart_info vuart;
+} imx8m_com;
+
+static void imx_uart_interrupt(int irq, void *data)
+{
+    struct serial_port *port = data;
+    struct imx_uart *uart = port->uart;
+
+    if ( imx_uart_read(uart, USR2) & USR2_RDR )
+        serial_rx_interrupt(port);
+
+    /*
+     * USR1_TRDY is a raw status bit, set whenever the transmitter has
+     * room regardless of whether the TX interrupt is enabled.  Only treat
+     * it as a TX interrupt when TRDYEN is set, otherwise an RX-only
+     * interrupt would spuriously enter serial_tx_interrupt().
+     */
+    if ( (imx_uart_read(uart, USR1) & USR1_TRDY) &&
+         (imx_uart_read(uart, UCR1) & UCR1_TRDYEN) )
+        serial_tx_interrupt(port);
+}
+
+static void __init imx_uart_init_preirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1, ucr2;
+
+    /*
+     * Reuse the bootloader settings; only enable the UART and both
+     * directions.  The console uses UCR1 interrupts (RRDYEN/TRDYEN)
+     * exclusively, so just clear UCR1's interrupt and DMA enables.
+     */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 &= ~(UCR1_RRDYEN | UCR1_TRDYEN | UCR1_TXMPTYEN | UCR1_RXDMAEN |
+              UCR1_TXDMAEN | UCR1_ATDMAEN);
+    ucr1 |= UCR1_UARTEN;
+    imx_uart_write(uart, UCR1, ucr1);
+
+    ucr2 = imx_uart_read(uart, UCR2);
+    ucr2 |= UCR2_SRST | UCR2_RXEN | UCR2_TXEN;
+    imx_uart_write(uart, UCR2, ucr2);
+}
+
+static void __init imx_uart_init_postirq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    uart->irqaction.handler = imx_uart_interrupt;
+    uart->irqaction.name = "imx_uart";
+    uart->irqaction.dev_id = port;
+
+    if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
+    {
+        dprintk(XENLOG_ERR, "Failed to allocate imx_uart IRQ %u\n", uart->irq);
+        return;
+    }
+
+    /* Enable the receiver ready interrupt */
+    ucr1 = imx_uart_read(uart, UCR1);
+    ucr1 |= UCR1_RRDYEN;
+    imx_uart_write(uart, UCR1, ucr1);
+}
+
+static int imx_uart_tx_ready(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return !(imx_uart_read(uart, UTS) & UTS_TXFULL);
+}
+
+static void imx_uart_putc(struct serial_port *port, char c)
+{
+    struct imx_uart *uart = port->uart;
+
+    while ( imx_uart_read(uart, UTS) & UTS_TXFULL )
+        cpu_relax();
+
+    imx_uart_write(uart, URTX0, c);
+}
+
+static int imx_uart_getc(struct serial_port *port, char *pc)
+{
+    struct imx_uart *uart = port->uart;
+
+    if ( !(imx_uart_read(uart, USR2) & USR2_RDR) )
+        return 0;
+
+    *pc = imx_uart_read(uart, URXD0) & URXD_RX_DATA;
+
+    if ( imx_uart_read(uart, USR2) & USR2_ORE )
+        imx_uart_write(uart, USR2, USR2_ORE);
+
+    return 1;
+}
+
+static int __init imx_uart_irq(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return ((uart->irq > 0) ? uart->irq : -1);
+}
+
+static const struct vuart_info *imx_uart_vuart_info(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+
+    return &uart->vuart;
+}
+
+static void imx_uart_start_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 | UCR1_TRDYEN);
+}
+
+static void imx_uart_stop_tx(struct serial_port *port)
+{
+    struct imx_uart *uart = port->uart;
+    uint32_t ucr1;
+
+    ucr1 = imx_uart_read(uart, UCR1);
+    imx_uart_write(uart, UCR1, ucr1 & ~UCR1_TRDYEN);
+}
+
+static struct uart_driver __read_mostly imx_uart_driver = {
+    .init_preirq = imx_uart_init_preirq,
+    .init_postirq = imx_uart_init_postirq,
+    .tx_ready = imx_uart_tx_ready,
+    .putc = imx_uart_putc,
+    .getc = imx_uart_getc,
+    .irq = imx_uart_irq,
+    .start_tx = imx_uart_start_tx,
+    .stop_tx = imx_uart_stop_tx,
+    .vuart_info = imx_uart_vuart_info,
+};
+
+static int __init imx_uart_init(struct dt_device_node *dev, const void *data)
+{
+    const char *config = data;
+    struct imx_uart *uart;
+    int res;
+    paddr_t addr, size;
+
+    if ( strcmp(config, "") )
+        printk("WARNING: UART configuration is not supported\n");
+
+    uart = &imx8m_com;
+
+    res = dt_device_get_paddr(dev, 0, &addr, &size);
+    if ( res )
+    {
+        printk("imx-uart: Unable to retrieve the base address of the UART\n");
+        return res;
+    }
+
+    res = platform_get_irq(dev, 0);
+    if ( res < 0 )
+    {
+        printk("imx-uart: Unable to retrieve the IRQ\n");
+        return -EINVAL;
+    }
+    uart->irq = res;
+
+    uart->regs = ioremap_nocache(addr, size);
+    if ( !uart->regs )
+    {
+        printk("imx-uart: Unable to map the UART memory\n");
+        return -ENOMEM;
+    }
+
+    uart->vuart.base_addr = addr;
+    uart->vuart.size = size;
+    uart->vuart.data_off = URTX0;
+    uart->vuart.status_off = UTS;
+    uart->vuart.status = UTS_TXEMPTY | UTS_RXEMPTY;
+
+    /* Register with generic serial driver */
+    serial_register_uart(SERHND_DTUART, &imx_uart_driver, uart);
+
+    dt_device_set_used_by(dev, DOMID_XEN);
+
+    return 0;
+}
+
+static const struct dt_device_match imx_uart_dt_compat[] __initconst =
+{
+    DT_MATCH_COMPATIBLE("fsl,imx6q-uart"),
+    { /* sentinel */ },
+};
+
+DT_DEVICE_START(imx_uart, "i.MX UART", DEVICE_SERIAL)
+    .dt_match = imx_uart_dt_compat,
+    .init = imx_uart_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:28:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:28:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395588.1633928 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDU-0004IP-GC; Wed, 19 Aug 2026 15:28:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395588.1633928; Wed, 19 Aug 2026 15:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDU-0004II-DN; Wed, 19 Aug 2026 15:28:36 +0000
Received: by outflank-mailman (input) for mailman id 1395588;
 Wed, 19 Aug 2026 15:28:34 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwiDS-0004Bl-TG
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:28:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiDS-00FCv4-A5
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:28:34 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cba0-e002-0a2a0a5209dd-0a2a450b9086-6
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:34 +0200
Received: from [209.85.210.178] (helo=mail-pf1-f178.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cba0-b7e8-0a2a450b0019-d155d2b2e0d8-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:34 +0200
Received: by mail-pf1-f178.google.com with SMTP id
 d2e1a72fcca58-8518d5ddaabso1032210b3a.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:28:33 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-851d3617434sm787575b3a.29.2026.08.19.08.28.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 08:28:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787153312; x=1787758112; 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=NVwP6oo+AcC8zP/zY/rrq1zp653mgLYZ54VIF02BJyk=;
        b=sKnjZlG45dIk1z0ctGnffIqmHDeWelWt1S6UZi008iSE1029HRo8DPLHrUNKRza4Ds
         Zm2zzN5suumb38M7hry/9gfAQiivklRldCZQcbJCcQsphoUsiSINqDYbe44Ew7LztzD3
         zXSBqBJKiO+RxX8d84G81qBhkgjkpstblZXhYYQ7XkWCY5M8ZfR6ImrA97wi1Qvf3rfO
         7h3Vaab/QRd42CrJSSQ0MimPvz2IX9HSHuh//ROtabXhfydaLO41wjRx80m7OnRKqnxP
         Mg8o25VOuZ3cynV1AUtvCo6GGkH9eOvqypiBY3jkNr6mTdTlrByCSpKGE/Uv/4q+XUMb
         Dzxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153312; x=1787758112;
        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=NVwP6oo+AcC8zP/zY/rrq1zp653mgLYZ54VIF02BJyk=;
        b=Ab7NlRKZ3lE4GAT2u0rJPgGPvDMfbqcZDsLYEYcuy14G4KDAc443ECtPiyPYrvrgwq
         fT7HQoGBzyH4I2H1QcOFOVqk5vnDyoWERZrhjdRUqNp1fXwMjqiLITLtNzmD+5OwSHUB
         AwY12hvq5oHGEVNiheW+Wge4LxOgwMWfA5NdjisWkXrahCtaE34LzL+9n1mthnxN4ety
         hKkTWCt9l6gs88LTaWa5CksVNZJgmQ71VfiuNez5Q+QMIj5MRs84VGMpXviI/zeY2KJH
         A1w4PLoPeTdSrO/yNH162KJvR6CyrEHV0Ut7qPFBRl+/eeMvPrN1kcGbXF+3z4Mdgpee
         I40A==
X-Gm-Message-State: AOJu0Yxv2utmfJB+KAuyRKnez9vd+XK+gNVCjla0RdEG2QJgbW91LYMz
	+RWU8hSwWrp8EJUUhKh2x1PtzHpAILjha4sBtksx27iR68cHQyBG4460gzqYhGoZ
X-Gm-Gg: AR+sD11U965trUHsMFRBixXa0ykD3g7bUOpMyRUqVi0OcPXDEFclmYyB59uOf5ktku/
	ygLZcsETpwsekVN3UBYoOkywDtmIjnmyjvmPzG5nU3IL5OcOzoJVO5s0pGcYws7pwHRFWx/iZBA
	kB4Hbxl68ZUZ602Ad6I/cSmY9lCfym8y3PvxEw5Hh99T6bwbQfGafftKvA6smVbafWVxrdwhR4r
	uXXBntME/4sszrhHKM+fdhPv4iosxvRGHadT467AzPPOUspb6oJKhuYDGLpbBjxE0aFeFngQKkJ
	EpIHRxk14y9uSu8Eonvl6bC/rt5lUCagg1DQsuwDMuARepH+qBcVwGHkmyBu6S3mmimCy/sAmXb
	LOVPcnkHqnRmfdJrqfm2jNAVSbyPMrOqK2Ywr8eWrFHLtVsNLcvgKRNj1squcAbg4cKliNXzl5U
	UGEr5jJPBfMKmJUhAFttIUd7SgT+IaINsgNIDDrI0djhMh3e2MoYBNPyup8PPberbMzKZ7ihOv9
	JTb1kQsLkZbPYOGTNfTdOwhkD6JgaWd
X-Received: by 2002:a05:6a00:4f91:b0:848:5f4f:289d with SMTP id d2e1a72fcca58-851d3850391mr8923732b3a.4.1787153312230;
        Wed, 19 Aug 2026 08:28:32 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
Subject: [PATCH v4 2/4] xen/arm64: add early printk for the classic i.MX UART
Date: Wed, 19 Aug 2026 23:28:19 +0800
Message-ID: <20260819152821.3361898-3-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260819152821.3361898-1-onlywig@gmail.com>
References: <20260819152821.3361898-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787153314-A8AC89EA-D21BFA9F/0/0
X-purgate-type: clean
X-purgate-size: 3091

Add an early printk implementation for the classic i.MX UART IP,
selectable via EARLY_UART_CHOICE_IMX_UART.  The UART is expected to be
fully initialized by the bootloader.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v4:
- No changes.

 xen/arch/arm/Kconfig.debug            | 12 +++++++++
 xen/arch/arm/arm64/debug-imx-uart.inc | 37 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-imx-uart.inc

diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
index 5a03b220ac..63a34b813a 100644
--- a/xen/arch/arm/Kconfig.debug
+++ b/xen/arch/arm/Kconfig.debug
@@ -44,6 +44,14 @@ choice
 		  Say Y here if you wish the early printk to direct their
 		  output to a i.MX LPUART.
 
+	config EARLY_UART_CHOICE_IMX_UART
+		select EARLY_UART_IMX_UART
+		depends on ARM_64
+		bool "Early printk via i.MX UART"
+		help
+		  Say Y here if you wish the early printk to direct their
+		  output to the classic i.MX UART (i.MX8M family).
+
 	config EARLY_UART_CHOICE_LINFLEX
 		select EARLY_UART_LINFLEX
 		depends on ARM_64
@@ -97,6 +105,9 @@ config EARLY_UART_EXYNOS4210
 config EARLY_UART_IMX_LPUART
 	select EARLY_PRINTK
 	bool
+config EARLY_UART_IMX_UART
+	select EARLY_PRINTK
+	bool
 config EARLY_UART_LINFLEX
 	select EARLY_PRINTK
 	bool
@@ -185,6 +196,7 @@ config EARLY_PRINTK_INC
 	default "debug-cadence.inc" if EARLY_UART_CADENCE
 	default "debug-exynos4210.inc" if EARLY_UART_EXYNOS4210
 	default "debug-imx-lpuart.inc" if EARLY_UART_IMX_LPUART
+	default "debug-imx-uart.inc" if EARLY_UART_IMX_UART
 	default "debug-linflex.inc" if EARLY_UART_LINFLEX
 	default "debug-meson.inc" if EARLY_UART_MESON
 	default "debug-mvebu.inc" if EARLY_UART_MVEBU
diff --git a/xen/arch/arm/arm64/debug-imx-uart.inc b/xen/arch/arm/arm64/debug-imx-uart.inc
new file mode 100644
index 0000000000..19b1679020
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-imx-uart.inc
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Early printk for the classic i.MX UART IP (i.MX8M family).
+ * The UART is expected to be fully initialized by the bootloader.
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <asm/imx-uart.h>
+
+/*
+ * Wait for the UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb, c
+1:
+        ldr   w\c, [\xb, #UTS]        /* <- Test register */
+        tst   w\c, #UTS_TXFULL        /* Check TX FIFO full bit */
+        b.ne  1b                      /* Wait until there is room */
+.endm
+
+/*
+ * UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb, wt
+        str   \wt, [\xb, #URTX0]      /* -> Transmitter register */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:28:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:28:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395589.1633938 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDW-0004Z5-Rv; Wed, 19 Aug 2026 15:28:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395589.1633938; Wed, 19 Aug 2026 15:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDW-0004Yw-Oa; Wed, 19 Aug 2026 15:28:38 +0000
Received: by outflank-mailman (input) for mailman id 1395589;
 Wed, 19 Aug 2026 15:28:37 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwiDV-0004XO-OZ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:28:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiDV-009wZP-5C
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:28:37 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cb7e-bab6-0a2a0a5309dd-0a2a4504bacc-32
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:37 +0200
Received: from [209.85.210.169] (helo=mail-pf1-f169.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cba3-b57f-0a2a45040019-d155d2a9dd6d-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:36 +0200
Received: by mail-pf1-f169.google.com with SMTP id
 d2e1a72fcca58-84830c774a0so1191353b3a.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:28:36 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-851d3617434sm787575b3a.29.2026.08.19.08.28.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 08:28:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787153315; x=1787758115; 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=oCTJm4KprltrO2DL2H0L71Et98Ar4/DK5gqKwieMcHI=;
        b=TGkL8+PFm6hIVmuzNShpvBMa28/sfgXhRlkBZwoHyi8xqXo/O8bcaKUX1QXnBCaVBL
         DMS14Hdfa80U7qN3rD/GH5yVLGbUgLQKZgPO0wC6GRVzTVkcCW95Ru7ALxfT3V/7dmTb
         KWQyaaY8jla959gJNU317Ufv5Y6Nq8d57dA6WdS4UWglmu+OgFmrh6Tmu2/9Q74HFe76
         OSDV3dTokp/9v4Qiz19GEykCBRCkpPaD0L2fSLv+Z/ljY502lw6tBse1UOhQEeXOGG2D
         wKVpp4erZGYdhcNREpQ6rSp4lF+9nHhdZNLBwz2sb7on5OxzPGSU8Bi1gd11Qz5UZuSI
         BFYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153315; x=1787758115;
        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=oCTJm4KprltrO2DL2H0L71Et98Ar4/DK5gqKwieMcHI=;
        b=CEMyHnkOixiNCJqyP4bs/WzWevpc4zI9K5GqOij98KDBiJHttoMR1JDW+Rll28j5ap
         ffbQLnfSc+Z80cgsgvWkZBr2KtBwOuiiz5MjLef2xuIiSggxSXB6j0ASU3Bjzag1iiW6
         zY9Me2yHuzpO5YVOqJxKudWoDnTr/r9Ah0hYtiXxIU2rLWNxLWESx8s09f2IKRJtGROq
         HlqJmxy7nYOIU9D7IL2l9ZDEn6WfQAzikPgv4lMeHZ7zDhQ4exf9TUIhzlSKKSupi5Gd
         aTqTJlkoVYw5pTwny1KsJTK44OIw1AW+C4uC63DfvZRokGUANQRMvlMZhZvDP+3f1X74
         lvYQ==
X-Gm-Message-State: AOJu0Yyxr9j7rCEx5RbjlMRBQUDcxHutgfW3f9EglhlozfpbFwkaigJb
	6RSro2ObSYN3r+piX54/xlz+1YkbxieP5cQae94p9iaOUi+zmsVQTqo31/lag+nJ
X-Gm-Gg: AR+sD12Oc2SZo1LpR2IpA64WWC2PXPFFzmuADWltgmZeSrGDNlX55JQuajP9KqLlL09
	6sS61RBFDFmZcQ/K5Q5VZOEeZMIcSw0IYkGESGpOKLUzcq4LItR2oZScckyljMAE9pYDbuAlDsV
	jCyseNTQ+gp3ek3TZI2EJcuuhum4n7bL53vUskZSzAq+85PS28MOwbHoTT+6BREKLLWWwmPeQa1
	7eXEdf0nPJM03wGEGkwGvoRWiREKENZiX9eh6bPnf6x8tk7RG9sbJ0dQOC8LP47jQPKr98QKnHR
	HEvWInITn/CMShXJaEoVIE1/zhOr80Y4AK6Q3SuENByGMVmdE5ITo/dXqGkJsBHBzVkXmORvYFh
	9IdlOfx0gWZWGOFBeoTgjxlTSXxQauGFLq5lDLf+9ASECExaKurOrI+hUM7dfj3eFPDjMlMGISM
	8GkxbbE8u11BR8mEqBjLkfRz4ob/FztDWAo+Sqw7Dz3y8+ehtSi9uSckbBcVFlEqIC9Ke9gnjh4
	X669B2KroM5wcSoKGQqypYfz2DxhRod
X-Received: by 2002:a05:6a00:ba8e:b0:847:9267:2104 with SMTP id d2e1a72fcca58-851d394802emr8097891b3a.12.1787153314949;
        Wed, 19 Aug 2026 08:28:34 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
Subject: [PATCH v4 3/4] xen/arm: add i.MX8M platform support
Date: Wed, 19 Aug 2026 23:28:20 +0800
Message-ID: <20260819152821.3361898-4-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260819152821.3361898-1-onlywig@gmail.com>
References: <20260819152821.3361898-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787153317-508D9B50-366F072F/0/0
X-purgate-type: clean
X-purgate-size: 7252

Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).

When Linux is used as dom0 a number of drivers make SiP SMC calls into
TF-A to manage hardware: GPC power domains, SRC (M-core remoteproc),
SoC info and NoC QoS.  There is no public specification for these
calls; the function IDs and their subfunctions are taken from the
vendor kernel call sites.

Forward only the specific subfunctions the hardware domain issues,
following the whitelist model of the i.MX8QM platform.  Each service
with a fixed set of subfunctions (GPC, SRC, NoC) filters them with an
explicit switch on the subfunction id, and the SoC info call is a
read-only query.  CPU and DRAM frequency scaling are denied because
the hardware domain cannot make an informed decision about resources
shared with the other domains, and any unknown function ID is
rejected.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v4:
- SRC and NoC: filter the subfunction id with an explicit switch that
  lists each accepted subfunction, instead of a range check.
- NoC: accept only the QoS priority subfunction; the LCDIF subfunction
  has no caller in the vendor kernel.  Note that i.MX8MP issues no NoC
  call at boot (only i.MX8MQ does).
- Print the subfunction id as well when rejecting an unknown function
  id.
- Picked up Michal's Reviewed-by.

 xen/arch/arm/platforms/Makefile |   1 +
 xen/arch/arm/platforms/imx8m.c  | 161 ++++++++++++++++++++++++++++++++
 2 files changed, 162 insertions(+)
 create mode 100644 xen/arch/arm/platforms/imx8m.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index bec6e55d1f..cdf936c50d 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
 obj-$(CONFIG_ALL64_PLAT) += thunderx.o
 obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
 obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8m.o
 obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
 obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
new file mode 100644
index 0000000000..ad76935f5d
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8m.c
@@ -0,0 +1,161 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * i.MX 8M family setup
+ *
+ * Copyright 2026 Open-EP (E-Paper) Community
+ */
+
+#include <xen/sched.h>
+#include <asm/platform.h>
+#include <asm/regs.h>
+#include <asm/smccc.h>
+
+static const char * const imx8m_dt_compat[] __initconst =
+{
+    "fsl,imx8mp",
+    "fsl,imx8mq",
+    "fsl,imx8mm",
+    "fsl,imx8mn",
+    NULL
+};
+
+#define IMX_SIP_FID(fid) \
+    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+                       ARM_SMCCC_CONV_64, \
+                       ARM_SMCCC_OWNER_SIP, \
+                       (fid))
+
+/*
+ * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
+ * public specification for these; the IDs and their subfunctions are
+ * extracted from the vendor kernel call sites (see drivers/soc/imx,
+ * drivers/devfreq, drivers/remoteproc).
+ */
+#define IMX_SIP_F_GPC       0x0   /* GPC power-domain control */
+#define IMX_SIP_F_CPUFREQ   0x1   /* CPU frequency scaling */
+#define IMX_SIP_F_DDR_DVFS  0x4   /* DRAM frequency scaling */
+#define IMX_SIP_F_SRC       0x5   /* SRC: M-core remoteproc start/stop */
+#define IMX_SIP_F_SOC_INFO  0x6   /* read-only SoC info query */
+#define IMX_SIP_F_NOC       0x8   /* NoC QoS priority setup */
+
+#define IMX_SIP_GPC_SF_PM_DOMAIN    0x03
+
+#define IMX_SIP_SRC_SF_M4_START     0x00
+#define IMX_SIP_SRC_SF_M4_STARTED   0x01
+#define IMX_SIP_SRC_SF_M4_STOP      0x02
+
+#define IMX_SIP_NOC_SF_PRIORITY     0x01
+
+static bool imx8m_smc(struct cpu_user_regs *regs)
+{
+    uint32_t function_id = get_user_reg(regs, 0);
+    uint32_t subfunction_id = get_user_reg(regs, 1);
+    struct arm_smccc_res res;
+
+    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+    {
+        printk_once(XENLOG_WARNING
+                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
+
+        return false;
+    }
+
+    /* Only the hardware domain may use the SiP calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
+        return false;
+    }
+
+    /*
+     * Forward only the subfunctions the dom0 kernel actually issues.  All
+     * of these manage hardware that belongs to the hardware domain (power
+     * domains, M-core, NoC) or are read-only queries.
+     */
+    switch ( function_id )
+    {
+    case IMX_SIP_FID(IMX_SIP_F_GPC):
+        if ( subfunction_id != IMX_SIP_GPC_SF_PM_DOMAIN )
+            return false;
+        break;
+
+    /*
+     * CPU and DRAM frequency scaling: the hardware domain does not see the
+     * whole system and cannot make an informed decision about resources
+     * shared with the other domains, so deny both (CPU frequency scaling
+     * is denied on the i.MX8QM platform for the same reason).
+     */
+    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
+    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
+        return false;
+
+    case IMX_SIP_FID(IMX_SIP_F_SRC):
+        /* SRC: M-core remoteproc start, poll-started and stop. */
+        switch ( subfunction_id )
+        {
+        case IMX_SIP_SRC_SF_M4_START:
+        case IMX_SIP_SRC_SF_M4_STARTED:
+        case IMX_SIP_SRC_SF_M4_STOP:
+            break;
+
+        default:
+            return false;
+        }
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_SOC_INFO):
+        break;
+
+    case IMX_SIP_FID(IMX_SIP_F_NOC):
+        /*
+         * NoC QoS priority setup.  Only i.MX8MQ issues this at boot;
+         * i.MX8MP issues no NoC call, but the platform covers both.
+         */
+        switch ( subfunction_id )
+        {
+        case IMX_SIP_NOC_SF_PRIORITY:
+            break;
+
+        default:
+            return false;
+        }
+        break;
+
+    default:
+        gprintk(XENLOG_WARNING,
+                "imx8m: smc: Unknown function id %x subfunction id %x\n",
+                function_id, subfunction_id);
+        return false;
+    }
+
+    arm_smccc_1_1_smc(function_id,
+                      subfunction_id,
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+}
+
+PLATFORM_START(imx8m, "i.MX 8M")
+    .compatible = imx8m_dt_compat,
+    .smc = imx8m_smc,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:28:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:28:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395591.1633947 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDa-0004qH-36; Wed, 19 Aug 2026 15:28:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395591.1633947; Wed, 19 Aug 2026 15:28:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiDa-0004q5-03; Wed, 19 Aug 2026 15:28:42 +0000
Received: by outflank-mailman (input) for mailman id 1395591;
 Wed, 19 Aug 2026 15:28:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <onlywig@gmail.com>) id 1wwiDY-0004nj-G6
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:28:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiDX-00H1ec-T1
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:28:39 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cb8f-8faa-0a2a0a5109dd-0a2a4508bc0c-44
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:39 +0200
Received: from [209.85.210.175] (helo=mail-pf1-f175.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <onlywig@gmail.com>)
 id 6a85cba6-f659-0a2a45080019-d155d2afd55e-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:28:39 +0200
Received: by mail-pf1-f175.google.com with SMTP id
 d2e1a72fcca58-84a4d8fd6ecso1218101b3a.1
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:28:39 -0700 (PDT)
Received: from wig-Precision-3660.. (125-227-154-99.hinet-ip.hinet.net.
 [125.227.154.99]) by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-851d3617434sm787575b3a.29.2026.08.19.08.28.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 08:28:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787153318; x=1787758118; 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=qexHZlqSFqOa+wu3jRbx9Js4zQ/0pHMbVWziLO2Koe8=;
        b=fvjeIXfqWr7lemEYCDFilUOYi0yQOdInrpXfqrQiShNPfmmQ0nMmlUapUqKye7H4aJ
         hUfD2EqmNb4r3lSBYTzDI8HBoxL4HuO3ngqhPnYwwqYvTxJJRKrq5r7yVf5P+Tm3l+b0
         bFNriKoAq05PvxExmuYrx9NscTe0j3KKtGVWGYfXMozJz/BJ3kkprPeeAIzOec5XVHUL
         Dkp/LGgTxnSEglAqUUoJMv5ie94P40V9Dag8fx35u2K46CBradPHQ8PPAX6PPbnWUXl4
         t8Oe7YpPrCjEwHRkRw+gFN6RuxT1QtNMCTumu6BZfpAVKV2gOLBol+ZJ4S82qO+fiqS5
         M4Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153318; x=1787758118;
        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=qexHZlqSFqOa+wu3jRbx9Js4zQ/0pHMbVWziLO2Koe8=;
        b=AIGD12ByyomQi+ZQB6tpdaKPPHNmHdN9ruPcjW5FtwQ8BExZvFuCXyzhKHGKgxgML3
         2oVQdSM2B5ghDmTe6BQLWlWAILLP09ij54WpJ9EypAAltW6zTOTN3PZlThr3Mj7aV1mD
         KqFNxqal6BvDL2I0QeeJQHJwXjs7T3xoxLh6LgaClSRQvLDEBbONJy5zvZb+5TiTJxsx
         T1enbubVErZp3LCQKWiB9al9s1o+Atx4Ddb5OtKWM6YGxtqhwXyTBLw2TEbecpy9PA60
         SMvNQ9OBhVfQSnkmRXY3b02IoIr0ZLJi2ZtHKXL8OnkIeXm+skMCXfzW0EIJbopgh5oM
         /Iqw==
X-Gm-Message-State: AOJu0Yw//TKlln6NmyB01mNH+lZKBjhdnZ2KQDgoCgaHDU0sF62UGvwp
	lzyOJOCqZwrjGKVcWXxD7jVoQ55e5OUDAD04kwZ0eO40RdBZnyUErES3KT2hHAJM
X-Gm-Gg: AR+sD13F+DJYckygfntXMNV+cRFI/fQeHgeqrI95cCRsoaMnlDck6KCwLcTFhnSX/lG
	n5FJX98om1sZ2H7r5xrOwB+BqpV8ri9kS32BjoagV/t9A8Jw+JsGwi3FItXMNAnrUouEIGM2IHH
	s4YfrCS6A5qcwind/j7xyWlxk8VyT6dIVPB9OzlJUeFVtfT9mUlYcgU/vt3cHE+4hgle4Nbw9WG
	HqLUGzbFNKuup8A+8iSrcixlfFG5iMQ6OQq3ZKL8uI/hyq1Ug7s5K4PMVMulqDOeRZhGdpnURQz
	8mVyFfBZYkelKGa6C2GvtA3i70xYy1pqv3j5+ZitjEN6X+hux3Mn7sgz9GIAIji7n2ZyC2aABaA
	etD/rpS9bYU/kh4yq2WOKjZ1wPFaC1uU9GTSEbRO/vRIENPFjPachjSg1LIf6MbeVQ1SbJss6T3
	pBVujYd0WADp8AatjWCH0S9/ga7q0sGHZOXS3aHenWz2zvmKjOLy7ifDKbt3NjKzqx50kW7fFsa
	yAijTfxFWdKGfHqvPcNdzfC9U9UkveRkeNZYPY3ltk=
X-Received: by 2002:a05:6a00:f05:b0:845:e9e8:645c with SMTP id d2e1a72fcca58-851d3847482mr9283456b3a.6.1787153317737;
        Wed, 19 Aug 2026 08:28:37 -0700 (PDT)
From: Wig Cheng <onlywig@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Michal Orzel <michal.orzel@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
Subject: [PATCH v4 4/4] MAINTAINERS: add myself as reviewer of i.MX8M related patches
Date: Wed, 19 Aug 2026 23:28:21 +0800
Message-ID: <20260819152821.3361898-5-onlywig@gmail.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260819152821.3361898-1-onlywig@gmail.com>
References: <20260819152821.3361898-1-onlywig@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787153319-D4D7087B-AB079D30/0/0
X-purgate-type: clean
X-purgate-size: 835

I wrote the i.MX8M platform and UART support and can help review
patches touching these areas.

Signed-off-by: Wig Cheng <onlywig@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v4:
- No changes.

 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4dd97ffcad..c60afc93a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -365,6 +365,13 @@ F:	tools/misc/xenhypfs.c
 F:	xen/common/hypfs.c
 F:	xen/include/xen/hypfs.h
 
+IMX8M SUPPORT
+R:	Wig Cheng <onlywig@gmail.com>
+F:	xen/arch/arm/arm64/debug-imx-uart.inc
+F:	xen/arch/arm/include/asm/imx-uart.h
+F:	xen/arch/arm/platforms/imx8m.c
+F:	xen/drivers/char/imx-uart.c
+
 IMX8QM/QXP SUPPORT
 R:	John Ernberg <john.ernberg@actia.se>
 F:	xen/arch/arm/platforms/imx8qm.c
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:33:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:33:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395627.1633957 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiIY-0007Qf-NM; Wed, 19 Aug 2026 15:33:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395627.1633957; Wed, 19 Aug 2026 15:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiIY-0007QY-JN; Wed, 19 Aug 2026 15:33:50 +0000
Received: by outflank-mailman (input) for mailman id 1395627;
 Wed, 19 Aug 2026 15:33:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <32syFagYKCeUZLHUQJNVVNSL.JVTeLU-KLcLSSPZaZ.eLUWYVQLJa.VYN@flex--seanjc.bounces.google.com>)
 id 1wwiIX-0007QS-Rp
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:33:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiIX-0037Ib-8u
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:33:49 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <32syFagYKCeUZLHUQJNVVNSL.JVTeLU-KLcLSSPZaZ.eLUWYVQLJa.VYN@flex--seanjc.bounces.google.com>)
 id 6a85ccd9-8faa-0a2a0a5109dd-0a2a4506b77c-8
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:33:49 +0200
Received: from [209.85.210.197] (helo=mail-pf1-f197.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <32syFagYKCeUZLHUQJNVVNSL.JVTeLU-KLcLSSPZaZ.eLUWYVQLJa.VYN@flex--seanjc.bounces.google.com>)
 id 6a85ccdb-195a-0a2a45060019-d155d2c5a884-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:33:49 +0200
Received: by mail-pf1-f197.google.com with SMTP id
 d2e1a72fcca58-84c4cd31b51so15826b3a.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 08:33:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20251104; t=1787153627; x=1787758427; darn=lists.xenproject.org;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=c2FvzDQHxVaueg4hvKJpjDuB27Njlxwegg3SIxYd2Fg=;
        b=UXFZaNX5rOqMYok4fpR3qSSJw6eZWTnbNxi1TUxrOSS42cM0yCiaVyBBCIyKhOaF++
         3mipzWrRqBm6wY+7nHdoHP79oV5zf7TYrw3JGcveS9a1UVzalbuDzRSrasKMGJs6+QyE
         ljT0ceGZUJkFjsUWBq+cUqkvCz4esBDZPukH6h1JTPaY6e4eXFaIQCXZzbpoV9/d5W30
         JIwLo+5qK8WF//9h8Fhp0C4lI/5++qAT2vgOD5rpTjJz5dcCS1okPQou3mqEJ00YYAEe
         9zSAy6U8iVc6656vMtylFdVRVq2j+LqBjrWzKTvU9iB1DIZN0tlDhxU2XgRkL95ZIT1a
         zgiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787153627; x=1787758427;
        h=content-type:cc:to:from:subject:message-id:references:mime-version
         :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=c2FvzDQHxVaueg4hvKJpjDuB27Njlxwegg3SIxYd2Fg=;
        b=SR4kJX4uXIeZgbfSCtsZebyzJH9uazrTbB1M8CdMczSzZMI6jSLrCT3MiZhIQeUgYS
         LNBUUM6wbNMJYk21elaon/XNqYcb52E1ErpjkQf+E4/JiKdq2JzAyWZ7yBB0YSyZAY+Z
         u/4FtfJKvO5keWb3rALt0PlveET5rAOdSPS0V3pNArNwOsOgVdHSPf3aniKCHm3tpqoc
         7294fM7uFf7Arwfhc3UNwVj4RnSm6hHpwTLbaLNrafYL6xLYktMgtz2f0t6G0L9W509H
         eYnt/oaqG8oAbI/NzEFunMDazDiA5kQLT0YSeGduSYJCUogs7cYlI7vOoUir+Sf2dJab
         U5jw==
X-Forwarded-Encrypted: i=1; AHgh+RqTZQhBuLP4yt1aQClzKwp5lmxxXXtSUDp803Yj05gqNTqUeJoxSwquNkZejE7eF9C6OjQvFN2LIz8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBK3SrJYS4rmPpC6sdj1pFMySskLQvJHStInemgoQP+wHX2JSD
	K5TnAdgKA6WZ7L5hXSZgMDvzhvDtmwk6UUe+1fmfeRvMIcf5S+a3pFqaq1iUC8HmhwKMqIaF1Ur
	fFA6CBg==
X-Received: from pfoo3.prod.google.com ([2002:a05:6a00:1a03:b0:84f:df8f:5a90])
 (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2913:b0:84b:9a69:156d
 with SMTP id d2e1a72fcca58-851df6dc419mr109732b3a.0.1787153626373; Wed, 19
 Aug 2026 08:33:46 -0700 (PDT)
Date: Wed, 19 Aug 2026 08:33:45 -0700
In-Reply-To: <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
Mime-Version: 1.0
References: <20260819102314.1499258-1-jgross@suse.com> <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
Message-ID: <aoXM2f1YTwgVj8KL@google.com>
Subject: Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org, x86@kernel.org, 
	virtualization@lists.linux.dev, linux-ide@vger.kernel.org, 
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, 
	linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, 
	linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, 
	kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, 
	linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, 
	linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, 
	linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, 
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, 
	Ajay Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov <alexey.makhalov@broadcom.com>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, Damien Le Moal <dlemoal@kernel.org>, 
	Niklas Cassel <cassel@kernel.org>, David Airlie <airlied@redhat.com>, Helge Deller <deller@gmx.de>, 
	linux-geode@lists.infradead.org, Olivia Mackall <olivia@selenic.com>, 
	Herbert Xu <herbert@gondor.apana.org.au>, Linus Walleij <linusw@kernel.org>, 
	Bartosz Golaszewski <brgl@kernel.org>, Arnd Bergmann <arnd@arndb.de>, 
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Peter Zijlstra <peterz@infradead.org>, 
	Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim <namhyung@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>, 
	James Clark <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>, 
	Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, 
	Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>, 
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu Wen <puwen@hygon.cn>, 
	Tony Luck <tony.luck@intel.com>, Reinette Chatre <reinette.chatre@intel.com>, 
	Dave Martin <Dave.Martin@arm.com>, James Morse <james.morse@arm.com>, 
	Babu Moger <babu.moger@amd.com>, Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>, 
	Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>, 
	Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>, 
	Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, 
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Len Brown <lenb@kernel.org>, 
	Viresh Kumar <viresh.kumar@linaro.org>, Huang Rui <ray.huang@amd.com>, 
	Mario Limonciello <mario.limonciello@amd.com>, Perry Yuan <perry.yuan@amd.com>, 
	K Prateek Nayak <kprateek.nayak@amd.com>, 
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>, Yazen Ghannam <yazen.ghannam@amd.com>, 
	Guenter Roeck <linux@roeck-us.net>, Artem Bityutskiy <artem.bityutskiy@linux.intel.com>, 
	Artem Bityutskiy <dedekind1@gmail.com>, Miquel Raynal <miquel.raynal@bootlin.com>, 
	Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Ashok Raj <ashok.raj.linux@gmail.com>, 
	Hans de Goede <hansg@kernel.org>, 
	"Ilpo =?utf-8?B?SsOkcnZpbmVu?=" <ilpo.jarvinen@linux.intel.com>, 
	Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>, David E Box <david.e.box@intel.com>, 
	Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>, 
	Lukasz Luba <lukasz.luba@arm.com>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="us-ascii"
X-purgate-ID: tlsNG-16d1c6/1787153629-F687577B-967E702C/0/0
X-purgate-type: clean
X-purgate-size: 1172

On Wed, Aug 19, 2026, Dave Hansen wrote:
> Hey Juergen,
> 
> These look great. Thanks for doing it!
> 
> The only wonky thing is how we're going to actually merge it. We
> obviously can't do patches 10-11 until all the "stop using" patches have
> been applied.
> 
> I obviously 100% realize that it's during the merge window, but any acks
> that the maintainers of 5-9 provide in the next few weeks would be super
> helpful. Or, if any of those maintainers want to cherry pick their
> subsystem's stuff out of this series and apply it, that would be great too.
> 
> But, the last time we did some MSR function munging, the tip tree
> carried most of the patches. I would expect we'll have a repeat of that
> here too. I'll pencil in the idea of just merging the lot around -rc1 time.

Note, patch 12 "treewide: convert rdmsrq() from a macro to an inline function"
is going to conflict with the KVM changes for 7.3; kvm_access_xstate_msr() is
getting moved from x86.c to msrs.c.  Somewhat surprisingly, AFAICT that's the
only conflict with KVM's code movement, so it's probably not strictly required
to send a new version after the KVM pull request?


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 15:47:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 15:47:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395642.1633964 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiVl-00011x-Py; Wed, 19 Aug 2026 15:47:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395642.1633964; Wed, 19 Aug 2026 15:47:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwiVl-00011q-NM; Wed, 19 Aug 2026 15:47:29 +0000
Received: by outflank-mailman (input) for mailman id 1395642;
 Wed, 19 Aug 2026 15:47:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwiVl-00011k-5N
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 15:47:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwiVk-0069z5-IQ
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:47:28 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85d007-2eae-0a2a0a5409dd-0a2a450cdd3e-12
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:47:27 +0200
Received: from [98.137.64.205] (helo=sonic303-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85d00e-f479-0a2a450c0019-628940cdaa13-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 17:47:27 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 15:47:25 +0000
Received: by hermes--production-ne1-6dbcb84f44-7k4wv (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID b43061383b4c87a44dcdb958addcba99; 
 Wed, 19 Aug 2026 15:47:19 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787154445; bh=oieMMDfhAvwhqSEpTV4R3AjOTw3bjj4ZSJt6BKoklFA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=Ox+DNJdXYUbNkufDgz9xh0D4eFJWxkQCLxn9CD02nCm+FY0GbybNQatwuH3LYPVty9Jmi2GWfiVQzTCSUBwLydMkaALn/dJkdY61frw5fEgHFcUJYkezxG1k7A4s2ticj6K0oFVkIMA87fw/BgSiPX3rFhm/lLx9ZGh2zrXUV5L6/sbd5NMDFiAnL+PCDEw7L0OEFXJFMNIt3BuXA7eQ1bT6RwEW9gkuude3sqLBRAQYinQrKnYDxg+MqEw3ZfEJo+Ctl1yT66nZJ6Vj65bzNf0P3CcaxcYvZ77LWd+OjvWh27MZsSeVfE4OCefxdnKuaiQDsGq05o3oV7A3Rq8gcA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787154445; bh=uC5weUnpcDDd3XniiqwsBOch23gP3/nSZjOV+JMK1zI=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=NrRLYBEna+pKDQ3Kgan1kwfSF3A5Ieb+rGl8hvGY+IRJL2FGUTo2JYQ39Xicm61fwUU52ClZbtb49hpRgmBYLKt7ULAXNVUZ4tCWmrOQX/pNdiF9n44YclgXe5UFqTUqAPT944qNQduQAuimYH1lbfiVzBig9qxA1Zma1bqcywN4v6ya6U/zsVaP4d0F8j3k+SPuN6czFmbb3BJXB0fIvmr1idzVaQAT1vbFKvu6op2mvB+qlxYp3DHPSx996/ZAD47+7Ix6wMVWcvAszIxk2mmL7Jk+JV1Ruo/qElJIQaugEukT2PCgOQ1ykIqxSDv56XFbLJMh01jfigKPDpjo9g==
X-YMail-OSG: JB_skrgVM1nw1pTvkxWZx0qbHvp8TRhlfta8ZAe82lTJpG021Ijyfa6MZsEAMfH
 uikSlncdGFidtMnpbucsAQDCfubh1zPjUSxJ4gEjwcDxdUThMnrHKEsRODxXEAGjGYMWnszx977a
 4xGLBllAVD1mYoYcpO3b6EInOztKyhtDH_D3HlaOoF8Wcm_8p6ovDpDXFc.zE7RgjTgSC_0UNqoR
 ciiXdj3ytgFbwC8a9VJXTGw1Ij_HtOe3HCbEUZ3yp0FQnwLhpwwRx2XQKm0seJ5S_zjkRz9XurNC
 M6jqbvXIvalSpW611NmE1vYom_e1ZczXWzyFS_XMyKAU_D8sp8OnQ_XjyJwCCseXOLsMVBEvvVDR
 9BDiH0gOk0YzKuBou__692HSBPPA2lsrcEj69ny6hmUjxSvN_oAB4LbQgk_b4JATnwW7R4I.x4DC
 06J_WZNfX0BAr.k1ArXqJrwAjVkzhd1rAsiMXWvq3aQBHHFUYxM.1lzHEoVzeWk1M8JvLu6Q6Cdk
 5o85oi8DPZ1XXkxkXIzsG4.IQTfV79UidZyyvc9aWBQy0h.nworHFQ7JMi.wGaZgjVTTVsztjZyG
 pLgGusbu75q2B7yIJ7d07Dy7T_iLnXHesdfyD_esSFfRdhkAH6O9MpT.pHn1F4HyO2JQkx8sUC1d
 NjoF8KvU0wxOuiESGpma_QjMR1aodHkNyAUjMSdQTb5exOhAoCCFd1Q1eFTk_slgZTe47ZKa7XR.
 qijJXz9iVrJ2oxHKLX4_1T8X_jpvuBRf5_pzrI21G.3FdfDA6bPoJn.Ja_lAwQM9rBPAeC0JBf81
 BaU0nmJa2m50KxpHfmmLmfOEsaJvFSuvQLcGEXGqWhU7B8XYnhQT2eSIM3q7PCFIMknmzVoL5lww
 xiplkAzT_jXpA4I5YA_O9.ulMx1MSw68SvlizdBFHFwZ3S4ILHvyB22RiOg6f7fP8vNghByMliTj
 AmDWOQjh1uRYxa69WGvinw85G4YcG0i2zq3fGE.m9.KfgegQQAF6JXTECcdWjCH9hJ_LjNdMehK4
 oU0EXfksn6HYFz2VmKCHzqpl56xpBIjTiy2ZcYs9QCNdqZ.3wHf52ARCfXgmfGMz5EYYQIk8TMOc
 XXGgR_oYgPLqYUsF1q4ByVaYMZ8HSv1uMid7DuXSKvgWyf7dNbW4fMxilLTCzud8cRvrHSiRbsJB
 DubHdJwIz0sIDnft9ugeP7zlET3sXNZxJ0D9jjHqLVYUKqFo8iBD6WRCPeFfdAf9dHwELZkf6yan
 DcOrWgQPNTU80jhN25zIWI3kmZyQ3o22dT37tr6nVJbEuiDCpzq2YvHD0831oFcDhDfYUybeXOLb
 wlRpam94j.FE1Vr2xdmi6Pp9UXxyxuNhXoBngz_mze9nNeczUr3IBhRo633pNnrOd4TphzYKAx9I
 US4.ZXKPToamLH9bd.HcoJ.tYZ.PUHz30Dg1wsl7pCNflpX9vwQ4JrGZAq026tvZrHJxMUCzQEYC
 8xeEUkH6xwAaU_n0bv5OxWqtUrD.hIz34UKWLSlpcvvxtcja2Pg2KQcQGwv8q7kTkwupbOIcWhzV
 v3NOWpgo5scqDe0GAfkPD2AV9E7FEMVUvESgV2fqg9VbmaOaXqC3dPBHkH7vBnxG6CyUz72lDvE4
 iWnXqfrztqn5ktHAIOzb2aioYrN4XFZeLVHJpFxjA4lRjeiJRB_5tBbVkFZveAnOaegxfyf3KYJK
 cEZ5ZJIkICHLvngCZVWP68Tw4dzQNwCgwog5gzakSVPC61e_1pSqN9NYlYMRSBGW2g5LpmgT3zfy
 akcatDzXeXs1EVjLLZet7zNUoJ40M0cr3p_yq7fNZJhdP.SZtKzLtfJNDfWZu8vXB5aGqvbfGYp2
 uu8Mmr73GPSKRPbwATQjUsz851FcnTFiVaGtakEhRsfDskyRCmR7EJIEtpzOzCymtmiDQ9.eBxZu
 Bkksm8vvjkJfWFUBLVJvt3UAUWJLAoyrXOvobC1gNWcXqTdRIv08dZUFYAUAsJWx.bYOtv_96lJU
 dhJ.WfibIzyevq49aWIbob1AywjN5h7k.bdKM8fGcMFngk9LcBn85KgiZKL3UCKxCHzUUybarnqB
 FVbUC2Tnm4yy351CVHs8rpL4988Uz6NfMo7ZMA1ryBQjEzayTdysZp0focoV0gcDw9McjJh6Cev9
 xItsKmsS8ymySETRI0Z8fNShR_N8RDh8IzV_X3q6SpUuqFk6as2TTJ_z4_1OwEVBWx9Iq8qfpMn4
 xotzNZrCKVdshE90cQ8IYBG41oVC7GMcmermzFK_w3gLk.YT8
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 8687901d-e9a8-4fa7-9114-bfc7157ed932
Message-ID: <682975cc-4857-42b2-badf-b638869f3268@aol.com>
Date: Wed, 19 Aug 2026 11:47:18 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 3489
X-purgate-ID: tlsNG-d25034/1787154447-776D6A5B-E0F14938/0/0
X-purgate-type: clean
X-purgate-size: 3545

On 8/19/2026 9:51 AM, Jan Beulich wrote:
> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>> about avoiding the layering violation than anything else.
>> 
>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>> 
>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>> solution for extended VBT support for Intel IGD devices that would be compatible with
>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>> in hvmloader?
> 
> As indicated before: If the OpRegion holds data that is needed to drive the
> device, and if the OpRegion is exposed writable to guests, then guest can
> screw up that data such that subsequent guests won't work anymore. Hence
> exposing to guests (which includes hvmloader) needs to be stopped, or at
> least be limited to r/o. That, in fact, includes exposing to any privilege-
> restricted DM as well.
> 
> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
> it's not addressed by any of the BARs, yet it looks like it needs similar
> treatment. Earlier on we also talked about the region not necessarily being
> page-aligned. That poses, even with r/o exposure, the question of other
> data on the same (leading / trailing) pages. This may imply that the
> copying needs to be done strictly in Dom0, for both DM and guest to only
> ever act on copies (which may then as well be r/w).

Yes, I am thinking the DM should make a copy host OpRegion and never expose
the host OpRegion to the guest but only a copy of it.

The reason we need a patch like this is that with the introduction of the
rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
so its contents might be unsuitable in the guest address space, so in those cases
we need to patch the copy of the OpRegion that will be exposed to the guest.
If there is an extended VBT the DM will also get a copy of it, make a copy of
it, and expose it to the guest by appending it contiguous with the OpRegion.
Since in this scenario we are assuming the DM knows the contents of the OpRegion,
then it can find the host VBT and make a copy of it without needing hvmloader
to send the rvda and rvds values to it.

Then, the remaining question is which component (DM or hvmloader) will patch it
if it needs to be patched to make the guest's copy of it compatible with the guest
address space. It could be done in the DM only after hvmloader informs the DM
where in the guest it will be in the memory map unless we make the specifications
for how hvmloader determines where it will be in the guest address space public so
the DM can compute where the OpRegion will be in the guest address space. Currently,
the DM learns this from hvmloader when hvmloader writes the guest igd_opregion_phbase
value to the ASLS register of the device (in hmvlmoader code we currently name the
ASLS register for the OpRegion using the PCI_INTEL_OPREGION macro, which is defined to
be 0xfc). 

Chuck


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 16:06:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 16:06:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395662.1633974 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwio1-0004zS-B6; Wed, 19 Aug 2026 16:06:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395662.1633974; Wed, 19 Aug 2026 16:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwio1-0004zL-8E; Wed, 19 Aug 2026 16:06:21 +0000
Received: by outflank-mailman (input) for mailman id 1395662;
 Wed, 19 Aug 2026 16:06:20 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wwio0-0004zF-7P
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 16:06:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwinz-00A1fF-60
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 18:06:19 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a85d46a-bab6-0a2a0a5309dd-0a2a4503bf1a-36
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 18:06:19 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a85d47a-fae8-0a2a45030019-d155dd34a883-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 18:06:18 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47db714766aso41712f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 09:06:18 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e784b3sm61369175e9.3.2026.08.19.09.06.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 09:06:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787155578; x=1787760378; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=V3aCry1tuYFSYd1HvBy8Hn801kksHmedceglL/moChE=;
        b=lRArQjA5sv4nXXOFpMhz5qi4p9OyC1ddSDHNs5Ht1fFrnUU19KEZEUggTpc6FI+1nz
         Ktpcjj8jqkPBoIzF81R2xchyX4TePR9ri67RAt7moS9Rr/j1R0HZMaSv783uuJAiSyi5
         odXwbpeAkJKDi/M1rPtRvCFR6Y4+ofOcQ2ppnpP4yIk2Mr6PzkqKP+bxBzgyiQCd+o23
         QsZGYO2OGVyQZ5TYX54m1qyX/sPjGQ4qA3wGr5ZKE+TacBO241/t/1p++IAuHJQQ9ADC
         AOVbBbPsypcElb35Fs2Dd1EXhNINhMmzSaUkbMh9gRPqasoyq3shPZsFdX2pUZbgcdAi
         9Hvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787155578; x=1787760378;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=V3aCry1tuYFSYd1HvBy8Hn801kksHmedceglL/moChE=;
        b=H0MuoiD5I33suu1+beU9KyKLAsJ17Ff5q2LlUAptWqqnALEfdqxS3Gr6+UxZk1gRuZ
         OL8a7s4S1kBSlUHVIfFPmQTnpNJ7fovkX9BYJG1r/Ba44Eo4FTzvSZcoDbjqYkzGB0xv
         ruWyzF8qCHvlDIL7d4u0ncu366V1jBc8TtApLXdsGK9+MiyCsN7Q9yPfxkisSIhAtb79
         BiTCfS/uT4XlpydQo5+OtdyMGZrU9dDWLYJ198mBjUrt6eO558hh+RrqBfe+jrHrbxxy
         n8ue5dnEhvX4nwvlWRMqFovYPUybDmnok85h3Bcw/qBnZY68BtX0hA/74xKOv4ZDIcX7
         HI2g==
X-Forwarded-Encrypted: i=1; AHgh+RrcId/9rRS+dIX3Yy6p+2jHEaxYQKHefjwBz+TTZjhNArBiDX6fyTdNoaMxd5H5r4f8MzOp7xAj1Oo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzLJwI67mBArOkHfH+I4I5QPNz8rsgCAhEgTwqmd29BRFwzRIoM
	s2hJ19scd0+v1hvH/zoMcVqIbX5P0y8tZja9gFzBdfatgJHn09IM4T9Q
X-Gm-Gg: AR+sD128mn63MY5OHUzx+/goW6V+TQ0dP0oXtq+TdMoP5u01S1vlX2Qi9R6Y69KAjya
	MoX5QCct0bF71eqkQg9NlGiDMWPlK7cyiMlrRHvnPVyaFlN2auMJj025JCyTYs14t7uo45ErgCU
	LMXDtUZ1zoIO5hbUpONxJoig/SYiDLSBNy+zqjWNjZNozuDS0HEFIjphuAajYh+kaDoPQz25a+S
	YBVAHUc0q8G2kqfdEEydx6dOj1/cpmuaq5o+UixFIOqre5uxCvqb6+C/yVjaO7848oBZgKsuloo
	8Hr6WymBmMur5lP+CE1t2rS+dBQP/9w/Emvbl8LWSJysALFUUwsJ0gGx2Pv8wQS6HdwApUxcK0S
	n9X0fgd3CbR4uXstc7xrTyFLK7SO5J9uhHMzx89NAGPnc7Qz0D8sJW0rdXctWEOMQXEsgugbRmr
	qZt1GtOpwPXjUPbhbq9ELyfb2qoULVcakpSBs1cVBuqarIiO/6Gphy5GJH82Rcd/vNJGarhpfg2
	Ph2/eBSq5C6NkZETGEQ8+1s2rRD2D0p9UHTnU7ygqY=
X-Received: by 2002:a05:600c:1f85:b0:499:90d0:4906 with SMTP id 5b1f17b1804b1-499b06bf1a1mr3549415e9.5.1787155578048;
        Wed, 19 Aug 2026 09:06:18 -0700 (PDT)
Message-ID: <aff1f879-48c6-4047-a6c1-237a350e0f35@gmail.com>
Date: Wed, 19 Aug 2026 18:06:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
 <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
Content-Language: en-US
In-Reply-To: <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787155579-768FA4E9-506633C2/10/73395122804
X-purgate-type: spam
X-purgate-size: 22051



On 8/13/26 9:15 AM, Jan Beulich wrote:
> On 29.07.2026 15:40, Oleksii Kurochko wrote:
>> Introduce emulate_load() to decode and emulate guest load instructions
>> that fault due to MMIO accesses. This provides the basic infrastructure
>> required for MMIO emulation on RISC-V.
>>
>> The instruction decode (decode_trapped_insn() and the mask/match chain
>> for standard and compressed load encodings) is adapted from Linux's KVM
>> RISC-V implementation. The completion path differs from KVM's,
>> since Xen dispatches MMIO synchronously to an in-hypervisor handler via
>> try_handle_mmio() and has no userspace exit/return step equivalent to
>> KVM's kvm_io_bus_read() / KVM_EXIT_MMIO / kvm_riscv_vcpu_mmio_return()
>> split.
>>
>> A fault taken while re-reading the trapped instruction is handled
>> depending on the faulting translation stage:
>>   - A VS-stage fault is the guest's own fault (e.g. it modified its page
>>     tables from another vCPU) and, as in KVM, is redirected to the
>>     guest's trap vector, with the cause remapped to
>>     CAUSE_FETCH_PAGE_FAULT since HLVX reports execute-permission failures
>>     as load faults.
>>   - A G-stage fault would mean the P2M mapping of the instruction page
>>     disappeared after the instruction was fetched. KVM must handle this
>>     by resuming the guest and retrying, as Linux MM can invalidate
>>     G-stage mappings at any time. Xen does not remove P2M mappings of a
>>     running domain at the moment, so this case is asserted unreachable with
>>     BUG_ON(); it will need to be revisited once such removal is implemented.
> 
> I don't see why this cannot be implemented correctly right away. The behavior
> should be that of an access to unpopulated space on bare hardware, whatever
> that behavior is on RISC-V.

I wasn't able to find a spec what should be returned in this case but in 
QEMU source code I founded (unassigned_mem_ops → MEMTX_DECODE_ERROR → 
io_failed() → riscv_cpu_do_transaction_failed().):

void riscv_cpu_do_transaction_failed(CPUState *cs, hwaddr physaddr,
                                      vaddr addr, unsigned size,
                                      MMUAccessType access_type,
                                      int mmu_idx, MemTxAttrs attrs,
                                      MemTxResult response, uintptr_t 
retaddr)
{
     RISCVCPU *cpu = RISCV_CPU(cs);
     CPURISCVState *env = &cpu->env;

     if (access_type == MMU_DATA_STORE) {
         cs->exception_index = RISCV_EXCP_STORE_AMO_ACCESS_FAULT;
     } else if (access_type == MMU_DATA_LOAD) {
         cs->exception_index = RISCV_EXCP_LOAD_ACCESS_FAULT;
     } else {
         cs->exception_index = RISCV_EXCP_INST_ACCESS_FAULT;
     }

So RISCV_EXCP_INST_ACCESS_FAULT (in Xen it is CAUSE_FETCH_ACCESS) will 
be fine to return.

So do the following:

             if ( is_load_guest_page_fault(utrap.scause) )
                 utrap.scause = CAUSE_FETCH_ACCESS;

will be fair enough instead of: 
BUG_ON(is_load_guest_page_fault(utrap.scause)).

Probably, we want to rename CAUSE_FETCH_ACCESS to be closer to RISC-V 
spec as for value 1 in spec it is used:
    1 Instruction access fault
Interesting that all other CAUSE_* defines are aligned with the spec...

> 
>> @@ -13,6 +14,11 @@ struct trap_info {
>>       register_t stval;
>>   };
>>   
>> +static inline bool is_load_guest_page_fault(unsigned long scause)
>> +{
>> +    return (scause == CAUSE_LOAD_GUEST_PAGE_FAULT);
>> +}
> 
> Is something like this really a useful wrapper to have? It doesn't really
> shorten anything, nor does (imo) it aid readability.
> 
>> @@ -191,6 +193,11 @@ static void timer_interrupt(void)
>>       raise_softirq(TIMER_SOFTIRQ);
>>   }
>>   
>> +static always_inline void advance_pc(struct cpu_user_regs *regs, int step)
> 
> See my earlier remark regarding always_inline. Also - why plain int? Are
> there (going to be) cases where PC is moved backwards (in which case
> "advance" isn't suitable naming)?

No, it won't. At least, I don't see such use cases now. I'll use 
unsigned int instead.

> 
>> +{
>> +    regs->sepc += step;
>> +}
>> +
>>   static always_inline unsigned long get_faulting_gpa(void)
>>   {
>>       /*
>> @@ -210,9 +217,162 @@ static always_inline unsigned long get_faulting_gpa(void)
>>       return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>   }
>>   
>> +/*
>> + * Determine the trapped instruction which caused a guest MMIO trap.
>> + *
>> + * Returns true if the trap was redirected to the guest, in which case
>> + * the caller must stop emulation and return success. Otherwise *insn
>> + * and *insn_len are filled in and the caller should continue decoding.
>> + */
>> +static bool decode_trapped_insn(unsigned long htinst, unsigned long *insn,
>> +                                unsigned int *insn_len)
>> +{
>> +    if ( htinst & 0x1 )
>> +    {
>> +        /*
>> +         * Bit[0] == 1 implies trapped instruction value is
>> +         * transformed instruction or custom instruction.
>> +         */
>> +        *insn = htinst | INSN_16BIT_MASK;
>> +        *insn_len = (htinst & BIT(1, UL)) ? INSN_LEN(*insn) : 2;
> 
> In the if() you don't use BIT(), while here you do. Please be consistent.
> 
> Why the use of INSN_LEN(), when due to the earlier assignment it'll always
> yield 4 here?

ld/sd instruction which we are trapping here at the moment here could be 
2 bit and 4 bit depends on C extension so we need to pass correct 
instruction length to advance_pc() after it is emulated.

> 
> Finally, how would the caller know whether it looks at a transformed insn
> or (as fetched below) a "normal" one?

According to the spec ((part from htinst ... ):
On a synchronous exception, if a nonzero value is written, one of the 
following shall be true about the value:

• Bit 0 is 1, and replacing bit 1 with 1 makes the value into a valid 
encoding of a standard instruction.
In this case, the instruction that trapped is the same kind as indicated 
by the register value, and the register value is the transformation of 
the trapping instruction, as defined later. For example, if bits 1:0 are 
binary 11 and the register value is the encoding of a standard LW (load 
word) instruction, then the trapping instruction is LW, and the register 
value is the transformation of the trapping LW instruction.

• Bit 0 is 1, and replacing bit 1 with 1 makes the value into an 
instruction encoding that is explicitly designated for a custom 
instruction (not an unused reserved encoding). This is a custom value. 
The instruction that trapped is a non-standard instruction. The
interpretation of a custom value is not otherwise specified by this 
standard.

• The value is one of the special pseudoinstructions defined later, all 
of which have bits 1:0 equal to 00.

So setting bit 0 to 1 we will guarantee that it is normal "normal" 
instruction.

> 
>> +    }
>> +    else
>> +    {
>> +        struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
> 
> Pointer-to-const.
> 
>> +        struct trap_info utrap = { 0 };
> 
> Just {} please.
> 
>> +        /*
>> +         * Bit[0] == 0 implies trapped instruction value is
>> +         * zero or special value.
>> +         */
> 
> How come you get away without dealing with pseudoinsns? The insn pointed at
> by regs->sepc is of no interest for faults caused by implicit memory accesses
> originating from VS-stage address translation.

It is really problem but I think it should be resolved much earlier in 
handle_guest_page_fault(). I will add the following:

/*
      * A guest page fault taken on an implicit memory access performed for
      * VS-stage address translation (reading a PTE, or updating its A/D 
bits)
      * reports a pseudoinstruction in htinst rather than a transformed
      * instruction. Such a fault can't be emulated: htval holds the guest
      * physical address of a VS-stage PTE rather than of any access the 
guest
      * itself performed (and its two least significant bits are zero 
instead
      * of matching stval), while the instruction at sepc is unrelated 
to the
      * access which actually faulted.
      *
      * Report an access fault to the guest at the original virtual address,
      * which is what stval already holds and what hardware would raise 
for a
      * page table walk hitting an inaccessible address.
      */
     if ( (htinst == INSN_PSEUDO_VS_LOAD) || (htinst == 
INSN_PSEUDO_VS_STORE) )
     {
         struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
         struct trap_info utrap = {
             .scause = (htinst == INSN_PSEUDO_VS_LOAD) ? CAUSE_LOAD_ACCESS
                                                       : CAUSE_STORE_ACCESS,
             .sepc = regs->sepc,
             .stval = csr_read(CSR_STVAL),
         };

         riscv_trap_redirect(&utrap);
         return;
     }

and will update the comment:

 >> +        /*
 >> +         * Bit[0] == 0 implies trapped instruction value is
 >> +         * zero or special value. It can't be pseudoinstruction as 
it is guaranteed by check in handle_guest_page_fault().
 >> +         */

> 
>> +        *insn = riscv_vcpu_unpriv_read(true, regs->sepc, &utrap);
>> +        if ( utrap.scause )
>> +        {
>> +            /*
>> +             * A G-stage fault here would mean the P2M mapping of the page
>> +             * containing the trapped instruction disappeared after it was
>> +             * fetched.
> 
> Does it? What about, again, faults from VS-stage address translation while
> hardware was trying to fetch an insn? That is ...
> 
>> Nothing removes P2M mappings of a running domain yet,
>> +             * so this cannot happen.
> 
> ... the necessary P2M mapping may never have been there.

If VS-stage failed then CAUSE_LOAD_PAGE_FAULT will happen so BUG_ON() 
won't occur and it will be passed to guest to handle it.

BUG_ON() here catches CAUSE_LOAD_GUEST_PAGE_FAULT (G-stage translation 
failure).

Also, as I mentioned above I will change BUG_ON() too:

             /*
              * 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
              */
             if ( is_load_guest_page_fault(utrap.scause) )
                 utrap.scause = CAUSE_FETCH_ACCESS;


> 
>> +             * TODO: Revisit once P2M mappings can be removed at runtime.
>> +             */
>> +            BUG_ON(is_load_guest_page_fault(utrap.scause));
>> +
>> +            utrap.sepc = regs->sepc;
>> +            utrap.stval = utrap.sepc;
> 
> How do you know the fault was at .sepc? A 32-bit insn crossing a page boundary
> (implying the C extension is available) may well fault only on its higher half.

According to the spec, if stval is written with a nonzero value when an 
instruction access-fault or page-fault exception occurs on a system with 
variable-length instructions, then stval will contain the virtual 
address of the portion of the instruction that caused the fault, while 
sepc will point to the beginning of the instruction.

So here, we are trying to emulate what real hardware will do in this 
case. In regs->sepc, we have the start of the instruction that we didn't 
touch. sepc is filled according to the spec in this case.

Regarding utrap.stval, we know that utrap.sepc points to the correct 
part of the faulting address, as we are reading the instruction in 
16-bit chunks:

HLVX_HU(%[val], %[addr])        ; low 16 bits from sepc
andi %[tmp], %[val], 3
addi %[tmp], %[tmp], -3
bne  %[tmp], zero, 2f           ; if not (insn & 3) == 3 -> 16-bit, end
addi %[addr], %[addr], 2        ; <- addr is now sepc+2
HLVX_HU(%[tmp], %[addr])        ; high 16 bits, possibly from another page

So, if a trap happens while reading the high 16 bits (which may be 
located on another page), then utrap.sepc, if the read fails, will point 
to the high part of the instruction, which is what the spec requires.

Does that make sense?

> 
>> +            riscv_vcpu_trap_redirect(&utrap);
>> +
>> +            return true;
>> +        }
>> +
>> +        *insn_len = INSN_LEN(*insn);
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> +/*
>> + * Check alignment and dispatch a decoded MMIO access to a registered
>> + * handler. On success (0), info->data holds the read value for loads.
>> + */
>> +static int do_mmio(mmio_info_t *info, unsigned long fault_addr,
>> +                   unsigned int len)
>> +{
>> +    /* Fault address should be aligned to length of MMIO */
>> +    if ( fault_addr & (len - 1) )
>> +        return -EIO;
>> +
>> +    info->gpa = fault_addr;
>> +    info->len = len;
>> +
>> +    switch ( try_handle_mmio(info) )
>> +    {
>> +    case IO_HANDLED:
>> +        return 0;
>> +    case IO_ABORT:
>> +        return -EIO;
>> +    default:
>> +        return -EOPNOTSUPP;
>> +    }
>> +}
> 
> And there's no indication of "retry needed", e.g. when something changed
> between find_mmio_handler() and handle_{read,write}()?

I don't have any specific scenario where it is needed now so I don't 
know what to say.
And there is no race between find_mmio_handler() and 
handle_{read,write}() as find_mmio_handler() returns copy of the 
structure under read_lock():
/*
  * 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 = &d->arch.vmmio;
     struct mmio_handler key = { .addr = gpa };
     const struct mmio_handler *handler;

     read_lock(&vmmio->lock);
     handler = bsearch(&key, vmmio->handlers, vmmio->num_entries,
                       sizeof(*handler), cmp_mmio_handler);
     if ( handler )
         *out = *handler;
     read_unlock(&vmmio->lock);

     return handler != NULL;
}

At the moment, use cases are pretty strainghforward, a device from guest 
trying to read/write into MMIO and so the result logically could be or 
it is successfully handled or some issue happened and it is just 
aborted. As a real hardware will do, I think.

> 
> Also, nit: Blank lines please between non-fall-through case blocks.
> 
>>   static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>>   {
>> -    return -EOPNOTSUPP;
>> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>> +    mmio_info_t info = { .is_write = false };
>> +    unsigned long insn;
>> +    unsigned int shift = 0, len, insn_len;
>> +    bool is_unsigned = false;
>> +    int rc;
>> +
>> +    if ( decode_trapped_insn(htinst, &insn, &insn_len) )
>> +        return 0;
>> +
>> +    /* Decode length of MMIO and whether it is a sign- or zero-extending load */
>> +    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
>> +        len = 1;
>> +    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
>> +    {
>> +        len = 1;
>> +        is_unsigned = true;
>> +    }
>> +    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
>> +        len = 2;
>> +    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
>> +    {
>> +        len = 2;
>> +        is_unsigned = true;
>> +    }
>> +    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
>> +        len = 4;
> 
> Already up to here this demonstrates a weakness of the INSN_MASK_*
> set of #define-s (which I similarly observe in binutils, and I expect it
> all has the same questionable origin). All INSN_MASK_L* and INSN_MASK_FL*
> (also INSN_MASK_S* and INSN_MASK_FS*) are identical, allowing for a nice
> switch() to be used here in principle. That said, with access width
> nicely encoded in FUNCT3, it's not even clear whether a switch() would
> end up being needed / efficient.

.......

> 
> Otoh none of these masks cover the pseudoinsns that htinst may supply.

As I answered above we should handle that before this function will call 
so here we won't deal with htinst at all. Of course, if what I wrote 
above is correct. I will double check before applying that.

> 
> Further, what about A-extension insns? Some (if not all) of them can
> plausibly be used on MMIO, I think.

I’m not really sure that the A-extension is actively used for MMIO. At 
least, Linux doesn’t do that for now, which is why we don’t handle 
A-extension instructions here.

I think this is related to the fact that MMIO is usually (if not 
always?) naturally aligned, and naturally aligned loads and stores are 
guaranteed by RISC-V to execute atomically.

Anyway, since we don’t have a case for this for now, I think we could go 
with the current emulation. If this turns out not to be true in the 
future, A-extension support can be added separately.

> 
>> +#ifndef CONFIG_RISCV_32
>> +    else if ( (insn & INSN_MASK_LWU) == INSN_MATCH_LWU )
> 
> First: Better use IS_ENABLED() in favor of #if{,n}def, whenever possible.
> And then this depends not only on CONFIG_RISCV_32, but also on guest
> bitness.

Both points taken. The #ifndef will become a condition in the if-chain; 
the INSN_MATCH_/INSN_MASK_ definitions are unconditional in 
riscv_encoding.h, so that builds either way.

On guest bitness you're right, and it's worse than the 32-bit-only 
encodings being reserved in RV32: the compressed RV64 encodings collide 
with the RV32 single-precision float ones — C.LD and C.FLW are both 
0x6000 under mask 0xe003, likewise C.SD/C.FSW, C.LDSP/C.FLWSP and 
C.SDSP/C.FSWSP. A 32-bit guest doing a c.flw to an emulated MMIO region 
would be decoded as c.ld, i.e.an 8-byte access with the result written 
to an integer register.

I'll fold both into a helper returning the guest's effective XLEN
(hstatus.VSXL, or vsstatus.UXL when the trap was taken from VU-mode, and
unconditionally 32 for a RV32 build) and gate the RV64-only cases on it. 
As a side note, vcpu hstatus setup currently leaves VSXL alone and thus 
relies on the WARL behaviour of the field; I think Xen should set it 
explicitly.

/*
  * 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.
  *
  * It is needed to decode a trapped instruction: the encodings which 
exist only
  * for XLEN=64 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 == 64 only, the field not existing on RV32 in the first 
place.
  */
static unsigned int guest_xlen(const struct cpu_user_regs *regs)
{
#ifdef CONFIG_RISCV_32
     return 32;
#else
     unsigned long xl = (regs->sstatus & SSTATUS_SPP)
                        ? MASK_EXTR(regs->hstatus, HSTATUS_VSXL)
                        : MASK_EXTR(csr_read(CSR_VSSTATUS), SSTATUS64_UXL);

     /* 1 encodes XLEN=32, 2 encodes XLEN=64. */
     return (xl == HSTATUS_VSXL_32) ? 32 : 64;
#endif
}

and then use it in emulate_store/load():

     unsigned int xlen = guest_xlen(regs);
     ...
     else if ( (xlen == 64) && ((insn & INSN_MASK_LWU) == INSN_MATCH_LWU) )
     {
         len = 4;
         is_unsigned = true;
     }
     ...
     else if ( (xlen == 64) && ((insn & INSN_MASK_C_LD) == 
INSN_MATCH_C_LD) )


> 
>> +    {
>> +        len = 4;
>> +        is_unsigned = true;
>> +    }
>> +#endif
>> +    else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW )
>> +    {
>> +        len = 4;
>> +        insn = RVC_RS2S(insn) << SH_RD;
>> +    }
>> +    else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
>> +              RV_X(insn, SH_RD, 5) )
>> +        len = 4;
>> +#ifndef CONFIG_RISCV_32
>> +    else if ( (insn & INSN_MASK_LD) == INSN_MATCH_LD )
>> +        len = 8;
>> +    else if ( (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD )
>> +    {
>> +        len = 8;
>> +        insn = RVC_RS2S(insn) << SH_RD;
>> +    }
>> +    else if ( (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
>> +              RV_X(insn, SH_RD, 5) )
>> +        len = 8;
>> +#endif
>> +    else
>> +        return -EOPNOTSUPP;
> 
> Because you don't permit F/D/Q for guests (yet), FL* and FS* aren't
> covered, I expect? 

At the moment, I wrote this function with handling of MMIO instruction 
in mind, which are at the moment ld and sd.

Even if to permit F/D/Q then do we really need to trap that 
instructions? Hypervisor could allow access to FPU to guest and then it 
will be just a question of context switch to properly save and restore FPU.

> I wonder how easy it is going to be to spot the places
> needing adjustment once support is to be added. Same perhaps for Zilsd in
> RV32 guests.

There is a message in handle_guest_page_fault():

     if ( rc )
         domain_crash(current->domain,
                      "%s: unable to handle faulted guest %s addr %#lx\n",
                      __func__,
                      (cause == CAUSE_LOAD_GUEST_PAGE_FAULT) ? "load" : 
"store",
                      addr);

Probably, it isn't enough and we could print here instruction (in hex) 
before return -EOPNOTSUPP.

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 17:14:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 17:14:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395707.1633982 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwjrM-00076B-1b; Wed, 19 Aug 2026 17:13:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395707.1633982; Wed, 19 Aug 2026 17:13:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwjrL-000764-UX; Wed, 19 Aug 2026 17:13:51 +0000
Received: by outflank-mailman (input) for mailman id 1395707;
 Wed, 19 Aug 2026 17:13:50 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwjrK-00075y-F4
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:13:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwjrJ-00Cm3g-Oq
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 19:13:49 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85e426-2eae-0a2a0a5409dd-0a2a450782bc-46
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 19:13:49 +0200
Received: from [98.137.68.31] (helo=sonic308-55.consmr.mail.gq1.yahoo.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85e44b-b4ea-0a2a45070019-6289441fb108-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 19:13:49 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 17:13:47 +0000
Received: by hermes--production-bf1-54b5569bdc-t2h4f (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 742b15b49534c807090a38b8b6396e9e; 
 Wed, 19 Aug 2026 17:13:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787159627; bh=BanAkv7rgc8Cm9c0aFLe97SGo72w3NkF9rLVAthNeQQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=HsM/Au0jM8VK870ek+t9k8ep3KXLMNzFohuKoFKvsmRYQiJCqd1ffRRWrncFnhlOUf4c1RwYb2itcnEfvQHv1CWn2zDOaLSjRwGVwjMD650PUwRM/PLvU2lXkIjraM3e6eVXzA32KODVDHmNNU1cXxA9ERatgzFppxkk1xiiaYkNivp1omXHQmXNByZVOGHsPkU6B85xUZ9STMWZkhwV2uU7X+zkIyjXimAuH546EMWctkyWDXcYgn2DqiBIV/LLkn/af/yXz+y3NEaEcZWdvd1c9m3B5FKiklo/HpdygN3zN0c1y/B6O9S3rx/LcRqcf0jz7j8X6bKAfLC5+FZmWw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787159627; bh=bOQF6M36pSZCahM7VdwAAR/NtnEHpJ7B+U55I/q8XeI=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=NEM5pY58Myc/T9ZHXKD+bCoPyy+KANjAW+dTokG6rrm6rtPUEXBpYYD8km+jBfrwht5DW09Gc8enknCssXJ0klmLJt83U/47lmmqgWw3v0J6nLGMOd0mphRFzHHBpancTKnpYnl/SBrontXqSpHBYiYkcTuM42vsYPkUvd7B1f4wlGTrwlX5fMQFGLxdmBpZvtTUmOoqW24U1bwa567c2V6wvipTUosMzENxvTI/kfAA68Xv6Cj3uSNqYNRs4ZLbXQlqkDwvzSsv+pFAM3hOoacYctadeZHZcKOvO+tJb824qF7dZp4GxOrZsar/gWQMDmCEgTxUcvzMZS2ZRFcPnQ==
X-YMail-OSG: I47cM1cVM1kgh0nrQvai66kGGwf.OQnEcPY_KKa6ubPsjpmNb1m.cAe9xxsraL9
 lR.agm7gh9T5pVLcVdi.lvsQfGO89Sj0Do5FjgW18spVhO4AZkw_qV4aUjyal._JJi4NiBCO9qbl
 NmKwURDqoGtPYDqEK5JmBnVDJmzlzH73pp2OHo0Xycef9Wg8GY4.M2TiH4342VfyvUyzZBiajTON
 cPRiRYqSfEtRju3UeoKKnue3vbcV4Uf5wMHivUN18JzHP.sfew3QKbhNgUKxT8OL2y.NiUPFNLM0
 C59Y2KGmBoaPtHJHd84kAAdskmsFFjOvMfXsb3NS1D5iNaVG4MoMUgW4SjT_VxBbM6PyrRcf5N79
 FgriVgpZk60SGw.GTw63IzlLLAQQras.bLwowZDY83dIW0q5bo4DGb2qY3DroeQK8XPZ7zAidWqM
 fwzfav1pMmlbdo_TPccMRXnBiCVxolelSMd6g94VL8RR618u1ehTstEa4bTBwZ0.JheWxplDGFov
 qmMBjtP0mBEeX.w5rR9PjATdL2KPR5VfVhYc23MwET2LdhS_uCS9ckViTfINclegtLugH6mJJcrm
 GCksJD4sfekYro7WglZkfcN35G4TXPY6gpOFk1_yd2oluAay4Y3jdzfACKLjvCIwNry6GBo4W0B_
 43SK.EYE5cnP6I_Sv8u.1m3gietWkqml5GPE6u5UxhGG24swj3zZ4oOsQzJcCAKr0Ujcjne8qqaK
 AOH3NDEcsxE.7XyV33mB.dWk8HOyYJ7Kn4UtvqrcLU46h2rhN9kVQ1poHKMh.hQH4DciqrURDmY5
 AW7gpddl2ebUkqXxk05UP3AA0wPqzcFFyazNwGUY6YMnEh8nOn9..dMWI9BL0vlbik0wd276e7M1
 7ceWZfrD9Mln_36kmG7ewXcqEjRBUXmy8xz3NLmvj0mnCJ0jIllSpSrh9s.jXMQ0t.ZRogXZNIr9
 pA0hN67nFSOaBBdPOoRABGzgQO0dYSaDPZhz8QsK7wdywYD6oFRquo0a2SZ2exu_67EncDq0Qe9P
 UnFjgvPKtckTz0Yx8RPxJH6oozQ_jdbFzJ9zoChY05hSOla_.ZQgnEMrIqIi1HWWwexfQxdbIMIe
 aLcEM5fiomtJXrKYVx2Q3Fpkg0nKwjFoPg.XaJvCYZP67yt8YHMmf3heBqyrvPLwyWRi0GMbGBkr
 IWaJi9lCtjvhJ.B5WNsIPW_8znlYAfbuCicRXtAxRAXs2PTGGBrDEaM_vH1YbK0DTnFdOIm4hWSU
 P6Q7mlZ_kbTn0hYnniF39NFU02S8EOHpR670ZBDOmMH8ZhH.IU49AAz4zJIujHjkWf_UbT5ILNaN
 tuWP4I9KbdJJrL6yzUkFu.77VC0bslbi7c25zT2WyyWLNKDm_uTtEC6I02kQU.fYzGtqUFXyrjOL
 S1Spa3MY2TeKmz28Pk9YQZvSzQw8XgV_gx4gPaCxdzE0P1NPgosg_VrP4zpl3WJwGz8BZMU6.hc5
 YQs8YfLctMkUEmT0k9_v0p5G20yBNKbdz9Vq6kUh.a3YcaCmj9Xh8qzi6nYhlYfNYjYB2MIGAHwT
 .jldyJB02PtyFDT.4WJ7RyiqEevt84XK3ufUCOTGkc5CCI.iEWRjpuRhFSG6ZkZnHX8m9J5WFJGi
 GbFRFZiXl8f0wQUmR3_q3jP7TVPRNIu8AnhZRXyrF_T7r4uXnSktYNXPj7e5vKa90ZikIHzaCemW
 uB7yic_0CI0.8xLe48RJC29qxsiiANI9h6_mTObTjLYLNbJqO8l_ZIbDuEq.0bb_4WOHvMK1JhyT
 ndRDqYdlr5Bjs74WnBV50YGg92hxQHnpnA9wtEXgFZLk.SYixbOUKmdcsjMSttTnhscWU4hICMOU
 zZ2.GrxVBJvdmY9uXGfhSF4jSL9RJjvasM5PAf7Zfm2G2WilzsifsDDHTGwMrA7rfWfQfj6FUkCA
 wOHE.Ivmpy5BykTKexO_h7JcM3ypWNJAA5e5YvK.vZXwYpwQwonGGjIJR.BtMvh7S3SbOmu40oqG
 dkeMJ.0Oq5L_.UW5_uMxCB6HXyycf5XZ6kVpRbdyARZ5btFtpw4mLe32RSn63zDQJr5ainQ.lIyF
 AHKHQaAI4bbMh3lmkNvzBY7xUzcWPPcfHijHpwbs2y28SPxCqG0yK8FVsg40HfBMdA7.HYsy9ria
 p7Rtqp17YdFWQWcub5KsJfi_ycoiCh2p4iIyk3YKhU_6GVVwMYNm5MK5MQHiyHd3Qh56PuWaKNox
 PVK7znSjMBroqX79WmjeeW7bsBiVslHKN2yAhR6ZlQtix
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 7905f90b-7e4e-497a-aa21-e5becffaebf2
Message-ID: <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
Date: Wed, 19 Aug 2026 13:13:43 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 2613
X-purgate-ID: tlsNG-ef75cf/1787159629-350CDAE4-A89C5524/0/0
X-purgate-type: clean
X-purgate-size: 2659

On 8/19/2026 9:51 AM, Jan Beulich wrote:
> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>> about avoiding the layering violation than anything else.
>> 
>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>> 
>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>> solution for extended VBT support for Intel IGD devices that would be compatible with
>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>> in hvmloader?
> 
> As indicated before: If the OpRegion holds data that is needed to drive the
> device, and if the OpRegion is exposed writable to guests, then guest can
> screw up that data such that subsequent guests won't work anymore. Hence
> exposing to guests (which includes hvmloader) needs to be stopped, or at
> least be limited to r/o. That, in fact, includes exposing to any privilege-
> restricted DM as well.
> 
> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
> it's not addressed by any of the BARs, yet it looks like it needs similar
> treatment.

Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
it functions more or less like a BAR region with the devices's ASLS register
at offset 0xfc in the PCI device config space of the device acting like the
BAR for that region.

Actually, in hvmloader code, this value of 0xfc for the OpRegion ASLS register
is added to the header file where all the other registers defined by the
PCI spec live: tools/firmware/hvmloader/pci_regs.h, but in that file it is
defined by the PCI_INTEL_OPREGION macro.

So this is another cleanup of this I could do along with this patch: Remove
the define of PCI_INTEL_OPREGION from pci_regs.h (after all, it is not part
of the PCI spec anyways) and pci.c (or the new intel-opregion.c file if some
version of it survives until later versions of this patch) can get the value
for the ASLS register from a header where specs for the IGD OpRegion are
located instead, or it can just be added to config.h where the other IGD related
definitions currently are in hvmloader code.

Chuck


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 17:49:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 17:49:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395724.1633992 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwkQ1-00038D-QF; Wed, 19 Aug 2026 17:49:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395724.1633992; Wed, 19 Aug 2026 17:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwkQ1-000386-N7; Wed, 19 Aug 2026 17:49:41 +0000
Received: by outflank-mailman (input) for mailman id 1395724;
 Wed, 19 Aug 2026 17:49:41 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwkQ0-00037w-Re
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 17:49:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwkPz-006ceO-F1
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 19:49:39 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85ec93-8faa-0a2a0a5109dd-0a2a4501a678-30
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 19:49:38 +0200
Received: from [98.137.68.205] (helo=sonic304-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85ecb1-5984-0a2a45010019-628944cd9b36-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 19:49:38 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 17:49:36 +0000
Received: by hermes--production-ne1-6dbcb84f44-s2c5h (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID bcdd50cfdd69c45373e572de97e837a0; 
 Wed, 19 Aug 2026 17:49:33 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787161776; bh=aQBDs8cBxZftUk4yBhPCLxwhUgL2bs2msElB1ZoQnbo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=DRcpEVhFG+ZMoXSbrJqQuLJzIhTL4+CtgUsikg6B+Z0RKDz8tP2k1W9RtptrdSCPDbwUSRBKElGfAOt8/eLotANxfHHp4UN4u4pMHO678gVwvZMYhkEC9U43nS0+Pp67hAIPdHwgQw9AWFnxaYlrVXsYxt18h6+s1oX2KKa6E19fcqx0NJduJvaFpPVgTkQG1w+xwA2hBPvD9yAcksQTJxjGI5GJ24LxvVDy9ccRLrMwXbySqbWamizQb28lYQicm09Xw9DhYzQ/U9sv+6grsMBKkPUv1CIPNLVMdWInTaewQvqQKDQzp7Iczl/3tBeUD1S7pDFuEWl7RucFFDMiog==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787161776; bh=A2jYJ0csOKeu5XX5nbNwAL5CZFsk/5zB0L07+WMgGsG=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=XuY0OhckUAhmzqT/x96kH5qdVAMlyntmawgFEgQJoSKXgknmAf2bkpd/NpQUcZm79r2udTegFqBKMsrXXSliweyIReztfgyffpGvXeBMsAHoviQ1axrfXWyywR95dozGxQ4wODJJRryxRQl9z8WaNP5lH+aaX6Psqbn+Qy6W/dMfr/QOQZ8NxpXlYwf7Uq+QwN87h/xhM5IFtYPQxH2eBTEhWkGHfiuE+zn+DfTK932FUxq88IheYoLRw42VHR7p/sAs+tC2w/YHEJ1poSMo0wi32zdBCiFMuOCQTfcWSe7z9TCsUvIFG2eC4QsWDT8/Q+fdfmbZUl5z5BVU4NUENA==
X-YMail-OSG: vpiwb_oVM1npxKwmB_8iAt2Shxm4hpqAdUBP.6qpElbhIZtNbpsgv5C.IxkkYJG
 tmk7cTnmhZ4X8vPmwAo7FNPfjelBKrVYPmZ.7GzPvKYbO6x29AJSNlkt2ku21Jp5ENo8ZTRMC_qk
 MWaBNkV4uL9vXYAWU9tv1Zs3NicQcaVYvPAf0tLCYx5R1Ka9sNnF3GQaQV53JVtvtYnvSly5Uh4C
 3CF3VAiXsXYoPxomm0AX1O08fRmAFs4CAbQ.CDanPFWazk6XNWh5jwvEuhbj_B6YgGdU6AkO7gq2
 J1V.YGlNrHepe9Hi0QU9vDhWnZ2jbT2b_JLFP7ZBU.V3pPMxuDtLkpe5HlkX0R2MvX_xuE7U4sK2
 L.OpRw2YvZwXz9KXYE_Di3hFwwnLARC8MH0nIzTMtkF.Jc2Loku5JhcZIJzg7p0QEp.Od5Y1jqeS
 6YoGVi4x9hfnaRJvGLCYAjHckaaZfZ4Nrd.sBwn5c1qa0v1vFmYTjrZAylBK50oRCBY.qHSZAELP
 CRWPZvHM.8f.cQQL6JDDC6lQzUNiyqxYv7nWbQ73rBPK.rwOq8ZbLXavDYI8RAyZiDp3oRgSb75x
 5pyl1EXWW5Kdw3iODOAgNbCqAqNs082Nra3dSh9Zzsl3kdO4cteR2349.AQhQZUPG.iBTe9aikgi
 8IRzvqGuaezbLxqwIRh6bhcRQ6iPirebxJsz84zCIijNeq2ukf_wlwHY0tBfeEs9cmyGeGc3hLEn
 yjL5C3HBGypJYTZp_gj5Pg4zkoZHZo1Zf_F35vd6TfJ1odxwXpxhUvHHKTEaH_5bsUtkTVviJ6Yg
 KudDvMjUPE.WIy6muH8HY.LuQ_1AROQWUYcpYuCow5EacG10F7XKwIHhff2fQo58den87h7.H9te
 ySyWA90U5pFFtxjYpiJOI.VtMmWSaPdtFn9YNaTEH1BumbSRNgcvKOIf4CfZdqc7ytpSOAw3T6j8
 rTzk7rUi0TQdwxkN2r6ll3fDlklpyzrvhLuFDWW4NyPhbnSN72MFsfqxDPj4QmmCCf99rmT8hZFa
 VvBJcpaAm70nMPWtPXF.u5ulf2sntm3l6KGm5qULEht9e_UkCoRsA92AvR0Akl5O0iBxn3eMvroI
 oM7RYp.B93j6cp2Y84jLaOyiu_lOnvV9hAUJ_jVjx7.hV7jJyR6S9vO46JpywlceOv79aqJf1hYl
 ak.oMkRMYTmq8RwD52H.HshwcWDlkSDDwciq6NzsDh.nmIA3Pa5FYW6xLkbO37zU9JjU8OJ5TB49
 uA.tjgN7LdjkbyonsqE56WpqEMdZiekdSZ.hc6paMSK1cdreN2ROTcBQbJoVpkdEGBWWVkDWH036
 4KmAqiGvzHv22K1RW0iqgmSmwKJZqPMpj9AxEBw7XkDJo2eRdCbMEoawOM0J.nVboqrpAAlfJveB
 .tWaP3AKAUruk5J4xvanijsUcRGHZvqhdCM23pbcdvH93WbfZUWwSWKoznIbu8B64yNQRu_Vhvo5
 .H08ma8cRj2sTcArSDta43D0GHhOywbGGoFd0oxlebqX_8PL3x6ABR6iDAZDy2WCvrA1Zf5t_rRf
 7mUItYbbOT5K0ovhAs0J8kf22LPiYjPIDv4ePdFbJi0ME3cJN.JxetmMdkZGoHAVjRthCchyR9oQ
 UDfVFg5HegKzrVSm6sDfgjDxAQHu5rdrc.6m9ePTdy0uTtJSHfum2O9MECxSfRsnvbguHfyzqGZC
 df.q.oR9fwV5d9vr.PkAIfr6IC3iwUlTkq7vkRY.HGQOQb_tbEr1QCQ4620MR8_fl0s4hMDPcLMK
 IZbgH021s.IxuxLO52_DxY.9_c.BJznex7.mNMRgrWwVcYRCp3aApYg_nTzHdD9Omtc_ge3Rnm6h
 4A.hWN5Zg7orVniAc5HRQgA2IJJCBZtuNObLYjEB2xl1PuNRe.W6f_pC44ARVeDXbyGcL4XpxzCe
 xJxIXsx7CowwjGyJC.cC2FxGbgMXIzBE2.JKUkaxuCNVG3Q34k3SOzwXAipIwQE281bD8a8C21CC
 IOudOJYHfBjziQtlCLqRslsyyoMREUg4GM8BNOk4VoJoAsMKxRtc_IMBnaq3qtGa_WomPoUJ0XxW
 gFB_z37cf0I5lmUWBIZ_nvFj3e6fynZhbrwgtE5Md2xJVrEzNwOzqUzq18D5zBaxYFTXiPkPHqAX
 0SY0SAYrVa6ltpW1VCEFM4J3OgvyNLvnXu59g95HhWEDWVNM4rD485PNo_kC9jY5Jk645KDkfNzG
 Ql_8UT1M3vGVkCtTtf4fFdL6ABLvwmRK3ReTlxMmW8d3V
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: db1ac486-3527-4366-88c2-78fc9a2ac78d
Message-ID: <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
Date: Wed, 19 Aug 2026 13:49:31 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
Content-Language: en-US
In-Reply-To: <682975cc-4857-42b2-badf-b638869f3268@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 4072
X-purgate-ID: tlsNG-d62444/1787161778-1E867757-39187583/0/0
X-purgate-type: clean
X-purgate-size: 4137

On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>> about avoiding the layering violation than anything else.
>>> 
>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>> 
>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>> in hvmloader?
>> 
>> As indicated before: If the OpRegion holds data that is needed to drive the
>> device, and if the OpRegion is exposed writable to guests, then guest can
>> screw up that data such that subsequent guests won't work anymore. Hence
>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>> restricted DM as well.
>> 
>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>> it's not addressed by any of the BARs, yet it looks like it needs similar
>> treatment. Earlier on we also talked about the region not necessarily being
>> page-aligned. That poses, even with r/o exposure, the question of other
>> data on the same (leading / trailing) pages. This may imply that the
>> copying needs to be done strictly in Dom0, for both DM and guest to only
>> ever act on copies (which may then as well be r/w).
> 
> Yes, I am thinking the DM should make a copy host OpRegion and never expose
> the host OpRegion to the guest but only a copy of it.
> 
> The reason we need a patch like this is that with the introduction of the
> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
> so its contents might be unsuitable in the guest address space, so in those cases
> we need to patch the copy of the OpRegion that will be exposed to the guest.
> If there is an extended VBT the DM will also get a copy of it, make a copy of
> it, and expose it to the guest by appending it contiguous with the OpRegion.
> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
> then it can find the host VBT and make a copy of it without needing hvmloader
> to send the rvda and rvds values to it.
> 
> Then, the remaining question is which component (DM or hvmloader) will patch it
> if it needs to be patched to make the guest's copy of it compatible with the guest
> address space.

As I noted earlier, it think it would be advantageous for the Xen platform as whole
for the patching to be done in hvmloader. That way, support for extended VBT is
automatically added for all implementations of the DM, not just for Qemu. But the
downside is that for hvmloader to do the patching, it needs to know the host OpRegion
address, which one could argue it should not need to know. This is the only reason I
can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
avoid disclosing the host OpRegion address to the guest.

But we trust hvmloader, don't we, to not abuse this knowledge of the host's OpRegion
address? The point is, hvmloader will discard the host OpRegion address and not
disclose it to guest firmware (ovmf/seabios) nor to the bootloader or guest OS, so
I think the advantage of adding support for extended VBT to all DMs that rely on
hvmloader outweighs the risk of disclosing the host OpRegion to the guest (hvmloader,
which, for security reasons, should not disclose it to ovmf or seabios).

Chuck


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 18:02:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 18:02:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395733.1634001 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwkcS-0005pM-Sa; Wed, 19 Aug 2026 18:02:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395733.1634001; Wed, 19 Aug 2026 18:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwkcS-0005pE-PF; Wed, 19 Aug 2026 18:02:32 +0000
Received: by outflank-mailman (input) for mailman id 1395733;
 Wed, 19 Aug 2026 18:02:31 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <vsementsov@yandex-team.ru>) id 1wwkcR-0005p6-1t
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 18:02:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwkcQ-00HJ65-1B
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 20:02:30 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <vsementsov@yandex-team.ru>)
 id 6a85efa2-e002-0a2a0a5209dd-0a2a4504c5c4-40
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 20:02:29 +0200
Received: from [178.154.239.72] (helo=forwardcorp1a.mail.yandex.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <vsementsov@yandex-team.ru>)
 id 6a85efb4-b57f-0a2a45040019-b29aef48ed32-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 20:02:29 +0200
Received: from mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net
 (mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net
 [IPv6:2a02:6b8:c2d:3530:0:640:eca4:0])
 by forwardcorp1a.mail.yandex.net (postfix) with ESMTPS id 10899C08B2;
 Wed, 19 Aug 2026 21:02:28 +0300 (MSK)
Received: from i115954770.yandex-team.ru (unknown [2a02:6bf:8080:c60::1:5])
 by mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net (smtpcorp) with ESMTPSA
 id M2bUThDaVKo0-qhLICAcE; Wed, 19 Aug 2026 21:02:27 +0300
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="Cc:Message-ID:References:Date:In-Reply-To:Subject:To:From"
Precedence: bulk
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru;
	s=default; t=1787162547;
	bh=CPeeLqJxqKF0PJ+VeCy5iEY5SVA2hqQkETeHHoPveXg=;
	h=Cc:Message-ID:References:Date:In-Reply-To:Subject:To:From;
	b=X0qxl4T1N4agxXBLxlA8rsZ/MmLq7UY9J5IlIHa24kDsVWfZKc6JTYcBxqBFZGZOP
	 2qUpSTZ24Ca/LuB4MfyK4TL2UzXPm+ccIIjWG7Sdbnh5ORwxlpE744i/u1JLhVIMOL
	 51uho2cmQTw0xlbwU2PTQXiOH5jRVvv5gyc3c+Gc=
Authentication-Results: mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru
From: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
To: jasowang@redhat.com,
	mst@redhat.com
Cc: armbru@redhat.com,
	peterx@redhat.com,
	farosas@suse.de,
	raphael.s.norwitz@gmail.com,
	bchaney@akamai.com,
	vsementsov@yandex-team.ru,
	qemu-devel@nongnu.org,
	berrange@redhat.com,
	pbonzini@redhat.com,
	yc-core@yandex-team.ru,
	mark.caveayland@nutanix.com,
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
	Sergio Lopez <slp@redhat.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Bernhard Beschow <shentey@gmail.com>,
	Conor Dooley <conor@kernel.org>,
	Sebastian Huber <sebastian.huber@embedded-brains.de>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Jason Wang <jasowangio@gmail.com>,
	Eric Blake <eblake@redhat.com>,
	devel@lists.libvirt.org (open list:Incompatible changes),
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs),
	qemu-ppc@nongnu.org (open list:e500),
	qemu-riscv@nongnu.org (open list:Microchip PolarFi...)
Subject: [PATCH v21 03/16] net/tap: deprecate "no" as special value for script/downscript
Date: Wed, 19 Aug 2026 21:01:46 +0300
Message-ID: <20260819180201.1970193-4-vsementsov@yandex-team.ru>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260819180201.1970193-1-vsementsov@yandex-team.ru>
References: <20260819180201.1970193-1-vsementsov@yandex-team.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787162549-C18D1B50-2840CCE6/0/0
X-purgate-type: clean
X-purgate-size: 12499

The interface is ambiguous, as "no" is valid file name. So,
using "no" as a special value to disable script is deprecated.
Use an empty string ("script=" / "downscript=") instead.

In a future version, "no" will be treated as a plain file name, just
like any other non-empty value.

Document the deprecation in docs/about/deprecated.rst, qapi/net.json,
and qemu-options.hx. Update other docs to use empty string instead of
"no". Add a warning.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Ben Chaney <bchaney@akamai.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
---
 docs/about/deprecated.rst                  | 18 ++++++++++++++++++
 docs/system/i386/microvm.rst               |  4 ++--
 docs/system/i386/xenpvh.rst                |  2 +-
 docs/system/ppc/ppce500.rst                |  4 ++--
 docs/system/riscv/microchip-icicle-kit.rst |  2 +-
 docs/system/riscv/sifive_u.rst             |  2 +-
 net/tap.c                                  | 17 +++++++++++------
 qapi/net.json                              | 14 ++++++++++----
 qemu-options.hx                            |  8 ++++++--
 9 files changed, 52 insertions(+), 19 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0c656a968fc..c4929317e3a 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -71,6 +71,15 @@ flexible enough. The monitor objects have been converted to QOM, so
 ``-mon mode=control`` is replaced by ``-object monitor-qmp``. The
 short convenience options are not deprecated, only ``-mon``.
 
+``script=no`` and ``downscript=no`` for ``-netdev tap`` (since 11.2)
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The special value ``"no"`` for the ``script`` and ``downscript``
+parameters of ``-netdev tap`` disables script execution.  This special
+treatment of ``"no"`` is deprecated.  Use an empty string (``script=``
+or ``downscript=``) to disable script execution instead.  In a future
+version, ``"no"`` will be treated as a plain file name.
+
 QEMU Machine Protocol (QMP) commands
 ------------------------------------
 
@@ -164,6 +173,15 @@ Use ``job-finalize`` instead.
 
 Use ``query-accelerators`` instead.
 
+``"no"`` as value of ``script``/``downscript`` for tap in ``netdev_add`` (since 11.2)
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The special value ``"no"`` for the ``script`` and ``downscript``
+parameters of ``netdev_add`` with ``type=tap`` disables script
+execution.  This special treatment of ``"no"`` is deprecated.  Use an
+empty string instead.  In a future version, ``"no"`` will be treated as
+a plain file name.
+
 Human Machine Protocol (HMP) commands
 -------------------------------------
 
diff --git a/docs/system/i386/microvm.rst b/docs/system/i386/microvm.rst
index 1675e37d3e7..077ea15751e 100644
--- a/docs/system/i386/microvm.rst
+++ b/docs/system/i386/microvm.rst
@@ -79,7 +79,7 @@ legacy ``ISA serial`` device as console::
      -serial stdio \
      -drive id=test,file=test.img,format=raw,if=none \
      -device virtio-blk-device,drive=test \
-     -netdev tap,id=tap0,script=no,downscript=no \
+     -netdev tap,id=tap0,script=,downscript= \
      -device virtio-net-device,netdev=tap0
 
 While the example above works, you might be interested in reducing the
@@ -103,7 +103,7 @@ disabled::
      -device virtconsole,chardev=virtiocon0 \
      -drive id=test,file=test.img,format=raw,if=none \
      -device virtio-blk-device,drive=test \
-     -netdev tap,id=tap0,script=no,downscript=no \
+     -netdev tap,id=tap0,script=,downscript= \
      -device virtio-net-device,netdev=tap0
 
 
diff --git a/docs/system/i386/xenpvh.rst b/docs/system/i386/xenpvh.rst
index 904778e3f5c..862f38830b1 100644
--- a/docs/system/i386/xenpvh.rst
+++ b/docs/system/i386/xenpvh.rst
@@ -42,7 +42,7 @@ case you need to construct one manually:
       -vnc none                                       \
       -display none                                   \
       -device virtio-net-pci,id=nic0,netdev=net0,mac=00:16:3e:5c:81:78 \
-      -netdev type=tap,id=net0,ifname=vif3.0-emu,br=xenbr0,script=no,downscript=no \
+      -netdev type=tap,id=net0,ifname=vif3.0-emu,br=xenbr0,script=,downscript= \
       -smp 4,maxcpus=4                                \
       -nographic                                      \
       -machine xenpvh,ram-low-base=0,ram-low-size=2147483648,ram-high-base=4294967296,ram-high-size=2147483648,pci-ecam-base=824633720832,pci-ecam-size=268435456,pci-mmio-base=4026531840,pci-mmio-size=33554432,pci-mmio-high-base=824902156288,pci-mmio-high-size=68719476736 \
diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst
index c9fe0915dc5..ec5aaf14fd9 100644
--- a/docs/system/ppc/ppce500.rst
+++ b/docs/system/ppc/ppce500.rst
@@ -158,14 +158,14 @@ interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by:
   $ qemu-system-ppc64 -M ppce500 -smp 4 -m 2G \
                       -display none -serial stdio \
                       -bios u-boot \
-                      -nic tap,ifname=tap0,script=no,downscript=no,model=e1000
+                      -nic tap,ifname=tap0,script=,downscript=,model=e1000
 
 The QEMU ``ppce500`` machine can also dynamically instantiate an eTSEC device
 if “-device eTSEC” is given to QEMU:
 
 .. code-block:: bash
 
-  -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device eTSEC,netdev=net0
+  -netdev tap,ifname=tap0,script=,downscript=,id=net0 -device eTSEC,netdev=net0
 
 Root file system on flash drive
 -------------------------------
diff --git a/docs/system/riscv/microchip-icicle-kit.rst b/docs/system/riscv/microchip-icicle-kit.rst
index 9809e94b84b..7fdb96601ad 100644
--- a/docs/system/riscv/microchip-icicle-kit.rst
+++ b/docs/system/riscv/microchip-icicle-kit.rst
@@ -84,7 +84,7 @@ Then we can boot the machine by:
   $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 -m 2G \
       -sd path/to/sdcard.img \
       -nic user,model=cadence_gem \
-      -nic tap,ifname=tap,model=cadence_gem,script=no \
+      -nic tap,ifname=tap,model=cadence_gem,script= \
       -display none -serial stdio \
       -kernel path/to/u-boot/build/dir/u-boot.bin \
       -dtb path/to/u-boot/build/dir/u-boot.dtb
diff --git a/docs/system/riscv/sifive_u.rst b/docs/system/riscv/sifive_u.rst
index 8f55ae8e313..0e4dcf3e70c 100644
--- a/docs/system/riscv/sifive_u.rst
+++ b/docs/system/riscv/sifive_u.rst
@@ -199,7 +199,7 @@ To boot the VxWorks kernel in QEMU with the ``sifive_u`` machine, use:
 
   $ qemu-system-riscv64 -M sifive_u -smp 5 -m 2G \
       -display none -serial stdio \
-      -nic tap,ifname=tap0,script=no,downscript=no \
+      -nic tap,ifname=tap0,script=,downscript= \
       -kernel /path/to/vxWorks \
       -append "gem(0,0)host:vxWorks h=192.168.200.1 e=192.168.200.2:ffffff00 u=target pw=vxTarget f=0x01"
 
diff --git a/net/tap.c b/net/tap.c
index 2076f5b7802..f4051e8d4b1 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -92,7 +92,8 @@ static void launch_script(const char *setup_script, const char *ifname,
 static void tap_send(void *opaque);
 static void tap_writable(void *opaque);
 
-static bool tap_is_explicit_no_script(const char *script_arg_value)
+static bool tap_is_explicit_no_script(const char *script_arg_name,
+                                      const char *script_arg_value)
 {
     if (!script_arg_value) {
         return false;
@@ -103,16 +104,19 @@ static bool tap_is_explicit_no_script(const char *script_arg_value)
     }
 
     if (strcmp(script_arg_value, "no") == 0) {
+        warn_report("'%s=no' is deprecated; use '%s=' instead",
+                    script_arg_name, script_arg_name);
         return true;
     }
 
     return false;
 }
 
-static char *tap_parse_script(const char *script_arg_value,
+static char *tap_parse_script(const char *script_arg_name,
+                              const char *script_arg_value,
                               const char *default_path)
 {
-    if (tap_is_explicit_no_script(script_arg_value)) {
+    if (tap_is_explicit_no_script(script_arg_name, script_arg_value)) {
         return NULL;
     }
 
@@ -741,7 +745,7 @@ static bool net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer,
         qemu_set_info_str(&s->nc, "helper=%s", tap->helper);
     } else {
         qemu_set_info_str(&s->nc, "ifname=%s,script=%s,downscript=%s", ifname,
-                          script ?: "no", downscript ?: "no");
+                          script ?: "", downscript ?: "");
 
         if (downscript) {
             snprintf(s->down_script, sizeof(s->down_script), "%s", downscript);
@@ -947,9 +951,10 @@ int net_init_tap(const Netdev *netdev, const char *name,
         }
     } else {
         g_autofree char *script =
-            tap_parse_script(tap->script, DEFAULT_NETWORK_SCRIPT);
+            tap_parse_script("script", tap->script, DEFAULT_NETWORK_SCRIPT);
         g_autofree char *downscript =
-            tap_parse_script(tap->downscript, DEFAULT_NETWORK_DOWN_SCRIPT);
+            tap_parse_script("downscript", tap->downscript,
+                             DEFAULT_NETWORK_DOWN_SCRIPT);
 
         if (tap->ifname) {
             pstrcpy(ifname, sizeof ifname, tap->ifname);
diff --git a/qapi/net.json b/qapi/net.json
index 8f0915c4d86..acb8594c952 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -399,15 +399,21 @@
 # @fds: multiple file descriptors of already opened multiqueue capable
 #     tap
 #
-# @script: script to initialize the interface.  An empty string or
-#     "no" disables script execution.  Defaults to
+# @script: script to initialize the interface.  An empty string
+#     disables script execution.  Defaults to
 #     ``<sysconfdir>/qemu-ifup``, where ``<sysconfdir>`` is the
 #     system configuration directory at build time (typically /etc).
+#     Using "no" to disable script execution is deprecated (since
+#     11.2); use an empty string instead.  In a future version, "no"
+#     will be treated as a plain file name.
 #
-# @downscript: script to shut down the interface.  An empty string or
-#     "no" disables script execution.  Defaults to
+# @downscript: script to shut down the interface.  An empty string
+#     disables script execution.  Defaults to
 #     ``<sysconfdir>/qemu-ifdown``, where ``<sysconfdir>`` is the
 #     system configuration directory at build time (typically /etc).
+#     Using "no" to disable script execution is deprecated (since
+#     11.2); use an empty string instead.  In a future version, "no"
+#     will be treated as a plain file name.
 #
 # @br: bridge name (since 2.8)
 #
diff --git a/qemu-options.hx b/qemu-options.hx
index 200949655ea..1efdb8e9860 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3014,7 +3014,8 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
     "                use network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
     "                to configure it and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
     "                to deconfigure it\n"
-    "                use '[down]script=no' or '[down]script=' to disable script execution\n"
+    "                use '[down]script=' to disable script execution\n"
+    "                ('[down]script=no' is deprecated and will be treated as a file name in future)\n"
     "                use network helper 'helper' (default=" DEFAULT_BRIDGE_HELPER ") to\n"
     "                configure it\n"
     "                use 'fd=h' to connect to an already opened TAP interface\n"
@@ -3553,7 +3554,10 @@ SRST
     ``<sysconfdir>/qemu-ifup`` and the default network deconfigure script is
     ``<sysconfdir>/qemu-ifdown``, where ``<sysconfdir>`` is the system
     configuration directory at build time (typically ``/etc``).
-    Use ``[down]script=no`` or ``[down]script=`` to disable script execution.
+    Use ``[down]script=`` to disable script execution.
+    Using ``[down]script=no`` is deprecated; it disables script
+    execution now, but in a future version it will be treated as a
+    plain file name.
 
     If running QEMU as an unprivileged user, use the network helper
     to configure the TAP interface and attach it to the bridge.
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 18:08:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 18:08:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395741.1634009 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwkhy-0006fK-Dj; Wed, 19 Aug 2026 18:08:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395741.1634009; Wed, 19 Aug 2026 18:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwkhy-0006fD-Ak; Wed, 19 Aug 2026 18:08:14 +0000
Received: by outflank-mailman (input) for mailman id 1395741;
 Wed, 19 Aug 2026 18:08:13 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrewprecious388@gmail.com>) id 1wwkhx-0006f7-9f
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 18:08:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwkhw-00AHdd-It
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 20:08:12 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a85f0de-e002-0a2a0a5209dd-0a2a45048bfc-28
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 20:08:12 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a85f10c-b57f-0a2a45040019-d155dd2fb0f9-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 20:08:12 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-472326ca506so904002f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 11:08:12 -0700 (PDT)
Received: from debian.debian ([102.213.48.6]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b145d31bsm6958670f8f.16.2026.08.19.11.08.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 19 Aug 2026 11:08:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787162892; x=1787767692; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wsZf5GBHmMPiBkZ0qQQi6d95RzL9J4vmayfNExw3wK8=;
        b=dM6GcryeHaguYc8kKkxRpnGPR61MuZWYCKiJp+MtlwKKbFCt7aEbuo7UNxJ9SGq+zr
         JxgEtvxBKyCoQMpalDcGL4yTWa3P6Ke8ouDK3+xvIVm7gKzu2p16YLlN7Z9LXwgYGvAN
         YXXA6VyuRnlCe1vVtG65QAX9kKb6cpUgah+1pbE/LCG6SZwciIQjP8vImgblGduCXvu3
         Lbos6KjvXmiyQDzHNUGTeUnMheNn3nYXFPEXTLUpczN2C6KCBAPMTPzlVWBZ18LczBll
         4eN1JANF/rM0ciH8yLRUOCKWhnjPFi7PnNMdNTTseSYVfm11qiA/UFOlL/oYe2ebasl3
         z7+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787162892; x=1787767692;
        h=content-transfer-encoding:content-type:mime-version: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=wsZf5GBHmMPiBkZ0qQQi6d95RzL9J4vmayfNExw3wK8=;
        b=JsFkPokC2IA0HxyD9iWVdMmXgok+UJO643RLAQlL8nY89Z5saoYqwPKazGsom2w0LC
         hkEKZ5ESBsfrLhgFNjvsiXggytkitpNxApytws/nJKF1juzDsIsvngRfnEJVlP6lHaaI
         fF7WTWSXe1yoSDPRngIH2JXRb+P0OP+hHoyqMxpfTa/S0ky/2dnkua5AoXYn0DdyUgR7
         PidPGn1WwYzgTzlDPPtz0AWS+lxbJdNDchJ56Si8UB0Sb+aa95wjNzpr4+ZeLUdi+X7H
         KxCLTSpYgEGKl4GZulKBnRAHyYGZMN4A6tuRPYxqC4uB2HDoAa5h6ucokyGRrNT4iBLq
         unZA==
X-Gm-Message-State: AFuF++mTX2YUfRnnp5nYAI5aEp9zhNTPS6XMnkiKHrkelznMM/NrEqqR
	xbbSwwwZTQIWzXJmkJzoR3FbGKtz0BZwIFm1O0NOAZQz9WQHTfnK7IMs31vSU2COAK8=
X-Gm-Gg: AR+sD12w55joxF3lYAWbEErPKK1Vj7uhPO+po6APkoQuTyzIRTHrfHFUR5bIY4DTLKv
	PZnCDmcGHpBmA+i6CxNgjY3VgJEmYNY8nfgVH8TfTdi2kskggg+Aynrfdav9KQvgQnddjeGGbFq
	VakRl8J0foMEEjuKc1qBjjmY5is0SdytsgTZEHouBUuJcYC6tkBZss62Ca1mAaHuJSJth945KsY
	9MXfsg3mt3X01YmA1SqTg3Pmty7zG0YE/ZLK4uY7gJd/XEKHLPJB8DHehUTSeuvf9Ll6ojFgqtV
	wWgM74B/q4YIDvR2IPijau0DJkGpaoetac/lw2zW46KFyK59OOEHxm8jllEyrPSHmwgU4f2Xde4
	bsJU4nVT6AN1ptMKAbytxeqQYrmWq/eQJxYUBTEnfhRB9naPKkIBMC8eAx/CMlb730WjnsgapFL
	b2+X3rgYnMrhIx3XooD/3dxrRR+EMy4pSnctG4/BdSuvkLmJT4YZiQlStF691iPd2uHpD7dA==
X-Received: by 2002:a05:6000:41fd:b0:47f:8ac0:282 with SMTP id ffacd0b85a97d-482b1fef313mr12519204f8f.17.1787162891893;
        Wed, 19 Aug 2026 11:08:11 -0700 (PDT)
From: Andrew Mbugua <andrewprecious388@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	teddy.astie@vates.tech,
	anthony.perard@vates.tech,
	Andrew Mbugua <andrewprecious388@gmail.com>
Subject: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when XSAVE is absent
Date: Wed, 19 Aug 2026 21:07:34 +0300
Message-ID: <20260819180735.135911-1-andrewprecious388@gmail.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787162892-C3EC6B50-8A026238/0/0
X-purgate-type: clean
X-purgate-size: 2800

While running the x86_instruction_emulator fuzzer via AFL, I encountered an assertion failure in the emul_test_read_xcr() function.
The fuzzer is able to generate a CPU state where cpu_has_xsave is false. If the fuzzer then generates & feeds an instruction containing AVX,the emulator
attempts to fetch the FPU state via x86emul_get_fpu(), which then calls emul_test_read_xcr() and hits the ASSERT(cpu_has_xsave). This assertion crashes the fuzzer.

The crash:
1. $ ./afl-harness < findings_dir/master01/...
   afl-harness: ../../tests/x86_emulator/x86-emulate.c:179: emul_test_read_xcr: Assertion `cpu_has_xsave' failed.
   Aborted

2. The stacktrace:
(gdb) bt
data_p=data_p@entry=0x55555604f320 <input> "\244\264\336\346\337\001\254%\247R\216d\204*\234\377\377\224λ\3237/\365ʿX\266?\353\036\227/\0323\351dj\257\v\207\031V֖\235{\036\225|:M\330\336 \314V:&\357\306@\224\331,\301\300\372FW\262.\020\\\276\244\203\242\276\262\022!\337)F&\261\2064\200\200\377I;J\376X41\2061\206\325 \021\017F\026\267\275\340\361\357)\255\343\237n\377\374n\357#ֽ\226\365d",
size=size@entry=580) at fuzz-emul.c:934

Possible fixes:
To prevent the fuzzer from getting stuck on this state,would it be better for emul_test_read_xcr to return X86EMUL_UNHANDLEABLE (or something similar) instead of ASSERT(cpu_has_xsave) ?

I have attached the binary crash file(converted to Base64) found by AFL below:

pLTe5t8BrCWnUo5khCqc//+UzrvTNy/1yr9Ytj/rHpcvGjPpZGqvC4cZVtaWnXselXw6TdjeIMxW
OibvxkCU2SzBwPpGV7IuEFy+pIOivrISId8pRiaxhjSAgP9JO0r+WDQxhjGG1SARD0YWt73g8e8p
reOfbv/8bu8j1r2W9WQAJnNNzsTXiDzn+tIYXP5ib7u5oA9GFre94PHvKa3jn27N/G7vI9a9lvVk
f/9fO1wsISMXjMG1qMtVHNLp6uRBZb1cV0Ybc1T5SBvfAawlp1KOZIQqnP//lOi70zgv9cq/WPWk
5MOmSoAqmv+M1R9Sc8UnJgEA9fX1IvX19fXu9fX19fX19fX19fX1/+dKZ6S03ubfAawlv1j1pOTD
pkqAKpr/jDcv9cq/WLY/6x6XLxoz6WRrrguGGVbWlsD6RleQLuUQkKSDoqayEiHf1kYmsYY0gFPE
gP9JO0r+VzQxhtUgEdeIPOf60hhcBmJvu7mgD0YWt73g8e8preOfbv/8bu/c1sbQS2L9zkVE9Ohz
xScmAQD19fUi9fVfO1xJAAACAMG1qMtVHNLp6uRBZX+AAAAbc1TaSBsdNdgkffrwwtCPjXe/D62n
Z+mGpLTe5t8BrCWnUo5khCqc//+UzrvTNy/1yr9Ytj/rHpcvGjPpZGuuC4cZVtaWnXselXw6TQAP
f/9WOibvxpCU2SzBwPpGV7IuEFy+pIOivrISId8pRiaxhjSAZWVlZWVlZWVlZWVlZWVlZWJlZWVl
ZWVleGVlZWVlZQ==

Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
---
 tools/tests/x86_emulator/x86-emulate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/tests/x86_emulator/x86-emulate.c b/tools/tests/x86_emulator/x86-emulate.c
index e2fbeb52e7..4d0b4610b5 100644
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -176,7 +176,8 @@ int emul_test_read_xcr(
 {
     uint32_t lo, hi;
 
-    ASSERT(cpu_has_xsave);
+    if ( !cpu_has_xsave )
+	return X86EMUL_UNHANDLEABLE;
 
     switch ( reg )
     {
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Wed Aug 19 19:09:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 19:09:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395780.1634020 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwlf2-0005s5-P9; Wed, 19 Aug 2026 19:09:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395780.1634020; Wed, 19 Aug 2026 19:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwlf2-0005ry-Jv; Wed, 19 Aug 2026 19:09:16 +0000
Received: by outflank-mailman (input) for mailman id 1395780;
 Wed, 19 Aug 2026 19:09:14 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wwlf0-0005rs-PG
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 19:09:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwlf0-00HQ1y-20
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 21:09:14 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85ff48-e002-0a2a0a5209dd-0a2a4503caea-18
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 21:09:13 +0200
Received: from [98.137.65.83] (helo=sonic313-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a85ff58-fae8-0a2a45030019-62894153b584-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 21:09:13 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Aug 2026 19:09:11 +0000
Received: by hermes--production-bf1-54b5569bdc-qwskm (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID a90e575e3ebcc0470bae79e8d3e34cf5; 
 Wed, 19 Aug 2026 19:09:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787166551; bh=Y+hqqQPJMhkzNUsx8sqJNX2kHqtYWU34FayrXcsDCNQ=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=g+tHZepq0Eg46owsVlJgEu1pKXa6fVW1QFczW2+nS35rjljg9KVrTKpcgzYV1UmmqMXzVWQOabmM8tUU1QvVbME9N8mkPX7XiR0Ofn+BqOKDb3dufin8lGy20XNpnYwRHfo5qtXXbN86CB2pSaIXj3+vp0GZTOZUlpg0Gv357OwGfT6eG3DPtMyvhiARCoiqP+zWxRQHzc7I/QASH4IGhmUi47aDCt7ycakVRc7kzvDJBDsB1/rIPqNdpWZ3SfAuHgSdygtMNNPA16I/PvQ0K6nUzTCfpJRzzPdOT2oJ9SRdGJM8ZZhBWktnFswBqG1wn0pOCVFAxyJimHF+t6iwkw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787166551; bh=BNV/t1p3CmCpvWRkvTXmn7BJ8vHrJFw84E9OFGhTd3z=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=LZWKtE1xw25aNUTEbvUvtsrWElvRGJ7Gl6IZ8dFAbGF7+7FxCFw9+UEDMiyiRhGLUHQXZAPfjGx2BofZ9b/z3ewKIxzNMkSW6aZ497YxpBuECu4fZBTBGWKVnp6sZl6tCiEYMucbHTRyycIlnIhTfxGoj8CGZkVouN922wkxijlb2Q2HNTbEM6uvIvtSFD53MtmTY/C8XyA8hVarGiQuYJVkhMCCWQcNmZZZde38MnispDM+24QsdcnMWGA/FchDVMB+7p3skRRTLSGmN5EJaWkUtLCDViu+1OCZWTINsvmtNkX0AT5xiGa25pAaIaApkzTZ5J0AQ+uFOU1Efand6g==
X-YMail-OSG: EUiA.UkVM1nauO91Zrsn4JRKzkxz8niXGiN4Tm5IO29C03Ej6LzlDF0gU8j2JBC
 MAvBw5RuK5rGmGNmiiHG5smxostK106O69XXn8NNsU654.2fT5vGcK7oCdRapKBpsw_.v9diI6ZY
 1nNwuH9dseuHXwVlPQxloCtaqhOJ1ikN1npszz3oJIwlx7GkSNlDn8.BMopLHbdUyqmxEv4HM3fA
 Jw8qW3.E_rszsevm14mmXfwLvBY5_kNTUr4YoOJgBfS8zdeGVxvUKzMfYQQfFOSeLJYaIqY5BJIg
 kYTx5u3qe0RDK8skKBqdmT2.M2itQ2.q2SthIfvms07mfllAocQ7i5FhBx6.GZB34gSikN7W7tEx
 .Vt0L2FUSFD9TDzG7Qnt25Ge56imBgwDq6VjIJsK9PUDbVl7PQnLAP1aOyxXRS4DU16rt2wa2Y3n
 26fPMJP_lqS7af00gY3RHbHs7sNysXKSYIJL.VA9JCq.YyTmNN1aWsr1RYOSkWpiYGHlA3fqeEF0
 IqicxsMqbUy.FI5pVu0C8vn8n1.867_NACYL6O20hivtLWvv1U8.qpruqCAvA_2ygnYO_6.EYxKL
 H7Db4_3zEHux3_DhFBVJUELBn4hAQhJUivqXaTvX0lT5bJOPhvPm0zi59b7JfiJUzFzml7f37GrY
 Alt1ehgeJWmiSwU7K1ilYZyyYui1WPhCu5CmgCVXk7IVveIu0Pbp6bPlnfbFQDGkHhpRMBCrmSUV
 tyMYt0pTuMoVxOQ_.kC9aoMirZBY4EFw7z0iQZRRErbk0wpGklpMCiMkLI9uspydHbdTt21BqamO
 eN3.BVv2NZWg5EmmivLuoGR5e7q.SOhC5oUv4Yt9njI_8NKyUkIqYu3FCejwn9tbzWyv1vswiCEx
 ySqd0IKZUePhgpvvZABzzSwyBrPxEAKjBo6qRlIxomPqXC.XnocG_.R8kQgYP3iLGIEfbmYhmjeE
 D8Bf71CHZhipRmF6ABWYykaheqOm52DLyeJr.9v2jU2C40cz834mFZtLw.oRG_zV1P1.En6rc59D
 ZogvhBKzWuca4COBUIKHc77JxkkLgQWX0TqxcJJBTGQWJMT6I8yrhwRKjYQmXBAMYDc0JF_NPKzt
 ckBu5Fr.9rxBzjc37kt7ex7eTyu7ELuP3Ahwa1TNZWgL6h1RPE5iVCYczmSipqu4087ORfiUo06g
 YBg3jtLxr04kDGLoYZn7e24VZ9S3VNAS4W5F3ScdrJQijZIRIHpf49d0LhS4.t1I8Gm2BaJ4vJEZ
 slmE3w0op_h_RcD_1KBRpuk_tX9np_bJoBoHMxMVWHRy3IQpaakiDmEOYfgdODo6XWdychMh7X80
 EO4HlVqgFgySEP.92r9y6SKFLkQjPPsiEPSG48jNhr9dfyt3nb6.KOwm1CgFfLB4V7XEuVGfbtWL
 XVTMDV0IzS12JIkSWhcxfjR53u2gT8xTo3BiLF9pUWq6IT78xDO_SPOYav8RuFrlPWza_gpTbNPE
 chul_0USpDsEU0Wmnyr8ddSQvjjcFgLwt_pGFYXu8nlDOjDrSRXUrf52PWHo.THfS5qydGVxKQLO
 CuK9ar5ao81b0KD.9vsiEN8C7fHqo7QS2bjGfjaxUaB1BTNEse1def3w7H9dSPnwN44zUR2eWSsA
 U1bk0TuXrjKxpYRWxaZdRz2s_t_rybyCUUpn39YUaj3Lv6wPho4sjLWXrcjAIedces39dMD7OQQ3
 L89_Ngq7fFZ3wqUXRo8IR72QD1nVdUMGAYPaDlUGr0A6I9M4hmdrHT41kYYX9OnQWnl.pelsgn4I
 9UhTL8E308s7U.aF1AQ0FtQ_TfcOU.W3FXF4AjhF5SL57hlWp2ETyYkj_rqmTNlIHHhri2roT8P9
 HtvOGpaSQB6S22SHpy114L1qfYzrv6Ag7krN60zBjdSf8qgDMl_XKYGZNULVQaRlXy_cr75_JsSG
 gmQWUTvG__NDjaLQVYFVhd6Yi_uxssupBEYOQoUnZGf59r_PEEoFj_SZMTNQvxnzIBZozpPvpVSE
 bzheOsj1Im6ZzYmYAXaq9HuVCUpzbGvmaCjSva_86mQxkTh5bjFluPmM7VIFAp988FTqSa1CxtDC
 YjlyG5c71I.W_2NrhUfO1Bridbmp6.C5LScB4hPlLwllNAq2hmFdCarW9_OkpYOu_hznbzIQacbM
 8SA6pjCXTNu3G8Gy4Z88A5iN6qBh2uiQjfC766cu1k7rW75ssDK1LBXfH2K177Pv7iYQt.L_jVWV
 yhNxFuJTgc7Y2HLsn9Ij_99SefOeZR1p13XFRkknVbbhTow--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: ac5ef29e-e26b-4b88-9572-1a7679b59f89
Message-ID: <f0ffe015-1bc5-4091-8dbe-2b4eee9cec2d@aol.com>
Date: Wed, 19 Aug 2026 15:09:06 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
 <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
Content-Language: en-US
In-Reply-To: <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 4602
X-purgate-ID: tlsNG-33051d/1787166553-75EFF4E9-16EFEB35/0/0
X-purgate-type: clean
X-purgate-size: 4680

On 8/19/2026 1:49 PM, Chuck Zmudzinski wrote:
> On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>> about avoiding the layering violation than anything else.
>>>> 
>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>> 
>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>> in hvmloader?
>>> 
>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>> screw up that data such that subsequent guests won't work anymore. Hence
>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>> restricted DM as well.
>>> 
>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>> treatment. Earlier on we also talked about the region not necessarily being
>>> page-aligned. That poses, even with r/o exposure, the question of other
>>> data on the same (leading / trailing) pages. This may imply that the
>>> copying needs to be done strictly in Dom0, for both DM and guest to only
>>> ever act on copies (which may then as well be r/w).
>> 
>> Yes, I am thinking the DM should make a copy host OpRegion and never expose
>> the host OpRegion to the guest but only a copy of it.
>> 
>> The reason we need a patch like this is that with the introduction of the
>> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
>> so its contents might be unsuitable in the guest address space, so in those cases
>> we need to patch the copy of the OpRegion that will be exposed to the guest.
>> If there is an extended VBT the DM will also get a copy of it, make a copy of
>> it, and expose it to the guest by appending it contiguous with the OpRegion.
>> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
>> then it can find the host VBT and make a copy of it without needing hvmloader
>> to send the rvda and rvds values to it.
>> 
>> Then, the remaining question is which component (DM or hvmloader) will patch it
>> if it needs to be patched to make the guest's copy of it compatible with the guest
>> address space.
> 
> As I noted earlier, it think it would be advantageous for the Xen platform as whole
> for the patching to be done in hvmloader. That way, support for extended VBT is
> automatically added for all implementations of the DM, not just for Qemu. But the
> downside is that for hvmloader to do the patching, it needs to know the host OpRegion
> address, which one could argue it should not need to know. This is the only reason I
> can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
> avoid disclosing the host OpRegion address to the guest.

Correction: Actually, with this new scenario, we need not disclose any confidential
host addresses to hvmloader if the DM removes such information from the copy of
the OpRegion that it exposes to hvmloader. Then, all hvmloader needs to know to
ensure the OpRegion is compatible with the guest's address space is the guest
address of the OpRegion. It need not know either the host OpRegion address or the
host VBT address.

So the guidance I need from you to do v3 of the patch is simply to answer these
two questions.

1. Should I write v3 of the patch not only assuming the DM will never expose the
host OpRegion to hvmloader, but also assuming that the DM is responsible for
patching the OpRegion to ensure it is compatible with guest address space?

Or

2. Should I write v3 of the patch assuming that hvmloader is responsible for
patching the OpRegion so it is compatible with the guest address space?

Chuck


From xen-devel-bounces@lists.xenproject.org Wed Aug 19 21:06:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Aug 2026 21:06:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395809.1634029 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwnUP-0003NO-K9; Wed, 19 Aug 2026 21:06:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395809.1634029; Wed, 19 Aug 2026 21:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwnUP-0003NG-Ej; Wed, 19 Aug 2026 21:06:25 +0000
Received: by outflank-mailman (input) for mailman id 1395809;
 Wed, 19 Aug 2026 21:06:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wwnUO-0003N3-41
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 21:06:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwnUN-00BFcr-HE
 for xen-devel@lists.xenproject.org; Wed, 19 Aug 2026 23:06:23 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a861abe-bab6-0a2a0a5309dd-0a2a4503949c-46
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 23:06:23 +0200
Received: from [52.101.56.62]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a861ace-fae8-0a2a45030019-3465383eb019-3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 23:06:23 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BLAPR03MB5604.namprd03.prod.outlook.com (2603:10b6:208:29a::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Wed, 19 Aug
 2026 21:06:20 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Wed, 19 Aug 2026
 21:06:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ItSqfhxsKGc6QrBjg+H4sH2gPENlqAN7yHSAaTi/jKuWeiYuSYEVbJsuZEhdfB0Kl43CC7C/2u/gs/dAS+Zmt4WUAx6XWpNu7exS5ePhAzEOoL5ky/mBuI+HAlF2gGDWQMuhFzp13IRrrOtFq19cwk6ahR0rHyRDOvqpOTMYDoPosqTvqLMlZJItmWr45yEgjJo3hk/QRjFAbsChTv1/O6kl2JgLnRXx6eLzIVz9bhXmvyiS4uke2Fde1XTVsOkpM2GBwYn7Ih3U9uPVXtuj3kuZczDthnJYu0scpQwb6ObUO57yxOkSjmywIumIz7yos0QpOSWD/KCxtMYmsxftaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4RAy1iA+wEISg9oWUqKgTndMJKJIZBWyCoImFmxuYEA=;
 b=ylrkgaiNhxh+eQzNY1jZLdOqqsVYSqwMt+97RrE1d8CaF9ErJU9hURjJHh9uy0nraPMkxuwan+In/Kib0GXF8oDCHyJENVYSleTamGAXs3/jF8mV3k7sG9D9GCaeniW3yG/2LeJcJSN1SIxnupjkdBfV2RYSY/QOmEz9q/iRKxrKh1O3LEk+qOFM/V5+tv7HGvJ8p4Y47VXexUfU7QvsAEYA69RQug07vfRfmCMN236zzhm6Dp2NEB78U6HwLhxAxZapqfcoqFe027uwJepV2KMXaiK+Wb1pd4spnt9CsnpE7Gi2TwIBZ0aJPJuO+RWY96ckeraz0coaPm/7wxxsdg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4RAy1iA+wEISg9oWUqKgTndMJKJIZBWyCoImFmxuYEA=;
 b=sg8g3VnLbgg4JZhpS2XOq+DuJ6ru+/an9r8FCilM1enpwor2bco6wLSxf8pGeY0o64t+CZIyms+YEK3JOPGvG0CXvT5Hko68r4yx6K012mwyN267sSJ2e1vB4HNr/2h7BZu6txmJf3eYLDDP+GLPkHeSsFy7n26q7y5dM3VSuvE=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <5f6df9e5-d0bc-4c1f-8513-27eaefe73292@citrix.com>
Date: Wed, 19 Aug 2026 22:06:17 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated
 panic()
To: Jan Beulich <jbeulich@suse.com>
References: <20260818130738.1911850-1-andrew.cooper3@citrix.com>
 <5fa222d8-af04-4b1a-a457-ee5004ace484@suse.com>
 <65789d8b-d18f-4f1c-8ffc-e1247daa4031@citrix.com>
 <ffe6c2b0-ec82-40e6-9bf5-fd49a3ef3a43@suse.com>
 <1200071f-122a-4dc0-aa08-7a7e2f1a6587@citrix.com>
 <90d8da75-3d95-4cb2-944c-24e11b0e215a@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <90d8da75-3d95-4cb2-944c-24e11b0e215a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0411.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:189::20) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BLAPR03MB5604:EE_
X-MS-Office365-Filtering-Correlation-Id: 1f2772c8-a166-420c-9e66-08defe35b78a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|10067099003|4143699003|11063799006|56012099006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	TqN2CD9h9BwSwwq6APTzOlJ3Z1LWKfNo9oUiyjsCxXttuW6YUDWI35GFE4xVa4pDGF7C2nQ2IumDc9ZlynXIxqys1QQP/Kijk1TY5nhR3JPLGF1lPMwMzGolHij3tVPZGh6pw1Sla5gh5/YVSIZwniXsSk+ZPZ116bUzc561yRVtLGvlcNFeo4BPvLXwWZb28zRbrBqJxdzxkz0ABHHyh8EH48JSZJtcmEnGFSKI6eNo0zj9Of2/52JlIRlBs5nfzSFDo2O4bAQ1U3LKbPSBm1uaBk8PcJSnreu4TJMRjEEj38O05A7XEieounj3g6FfNEaRjzm+20O2fXN7MkGOL3XJ7d2DStMA3idTPpjiLdilumb4TN1BC5CnbLrmD1lpY/bJJqp4VNTt21xPkLSEXF5HyphKvAyoE0H1/wp3GPJuISI7K+XHnAjxJS5ZoFxtQiFtLV542syLCf4sYRGRxRc4Fdkxc79aTsk+9S6WFVBSl5jhkCighBwkykZEC4Cuw9NczRksAhcQ1FZNN32GIDIlNpLKfmCVTs2yBDvM9UIurcoDLLVMUdS4D7Md8m8AxThSKJMBLQH+7qd7nDFJmdkKyQQBa5/AEjr9uZWyAvC+8FyM902d7fNwOp0Sjrj5R3Z0/h3xcmgg6oYASaEtbJ0cQP+VPYrl9rtDAetD9YQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(6133799003)(10067099003)(4143699003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?V2dZWlhEdXFDcW5rdDd2Y0V0ekpkUkMrcjhMQm41Z01XTG5wMjlLbzNWTmpW?=
 =?utf-8?B?SE8yVG11UThDNjJ3K3FETDZ2dk12SWcrZThUZEp1MWNVaTB0NjQvV3BDR2Rm?=
 =?utf-8?B?OUJkaGxCME9vckxBOGxleE5QQUU5TTBva0x0aG1RZFdreUJqeFoxTEZMQkg5?=
 =?utf-8?B?ckh3Q1oxb3k1U2xNQkpTMUFKN1hCRnVpZmw2MHZrcEdvUGgxT0dRNXBMYmtH?=
 =?utf-8?B?VDJBUVlCSnM4M0ZleDFJeTZYZEJzaGFiWVZuSjJLaTBJdGhhMUNwUkJIR2tR?=
 =?utf-8?B?MGk2SjJvUmhoS0dod21aemZLcmFTS2ZtdXY5Z3cxZWppdmRiZlozcmtaY003?=
 =?utf-8?B?TnVwYUEwM2hZTEttQ0ZqTDZuVmd4eVBmbzkwdktVZU1MY0h0YlpvWFNvS1NN?=
 =?utf-8?B?WWJGbUpmdGZ6M2MvMHo3S1BUNDRETXhFNmowRUM1YmlhQmF5bUZQOUpLT3RN?=
 =?utf-8?B?R09WNUhod2hOOUcyR3dEWG12d2hJV2wrMk9QK0wrQnFoTUxkQkZ4Sjczdy9z?=
 =?utf-8?B?TWprQUtkNW1DSWxkMkRZWlk1SlRMZE1wSEdYM2xsUVpOSmpIVzNCWmhjWFN1?=
 =?utf-8?B?bkJMVlNJMHBpN2l4bmlPelhHbVk5SFl3SVAwSkkxaU9OT0xqaW5lOE9BNEsz?=
 =?utf-8?B?TkNTM2p0REd6ZXlSd3JMejJuRHNkREJVMWRRVW5sUnpOS2tEejJTUkxpWG9t?=
 =?utf-8?B?SDBmZ1RwaG5aeVFpK2lsbkUwTXZmT0NaT2d5RDJSalVzcmZUUWRKNUw1bGQ4?=
 =?utf-8?B?dm9XVG5KakNlOTJmRlZta3BoTUIxL3hQc3FtNHBHOS82N0EwQ1Q1OWc4WDRR?=
 =?utf-8?B?eUg2UWdOSGJSbDlBbTZNL3h3a0h5Z29icTZrNGlxR0pOWlJGaWthZENFV1ZL?=
 =?utf-8?B?WVlIODZrWjFvTllwZ3ZQTmdDdXpNMWlLOEFreEdKZWFiUFdqRjBIdTY3bnZG?=
 =?utf-8?B?OU1mZTcrMW1oclJObkVFVGtiY210QitVWlJ0Q2t1L09TdFg4Y2pYZ1NWVDgx?=
 =?utf-8?B?UklNTy9ja0VmT0Q2QVQ4Nkt3RE5zZGI3REhXY0Z0a3BzTk81dlpLMVFYTUUy?=
 =?utf-8?B?ZEZhYUM1Ti8vdXROeXdacjJCMWpWL0dMZVBoNjNRWE9wVTBpRFlMeGRyd05k?=
 =?utf-8?B?d3lZWjdYbVB4dDA1YWM5ZEd5WTJwZ1lJM2FZNHd3OThpL3lyRHVsU0kzdE5z?=
 =?utf-8?B?NldLM1ZGemZIRDI4YUovU0RqbHVmWTZjMzJQTE5yQzZHMU1nUVVyeWFoczRH?=
 =?utf-8?B?QTNib3RBeUtoNGhTOWtleTYxdmMra0hKTE9ubkFJV2VaeE9PSUk0WmlQYWVl?=
 =?utf-8?B?K2FxZUFibGVEZVMrbzFicW8ySFM3UU00QUVYUzBuQ3lWMFRpWjhXL0RmTFJu?=
 =?utf-8?B?c2hOcGRtRExDeGxHeXhZOC9xaGJRZ0VkNEltRTA2Y0ZqNEhSdFYwLzZZd1N0?=
 =?utf-8?B?cG9wU0w5SEVCdGpGTmRJWXNJK1dJc1dOcTJFdW9QUTNmRkE0Q3JUVWRFancy?=
 =?utf-8?B?c3ZaYzZyMTFvN1JUcVoyamtYZUphTmJXc2lqY2llT09qOXc4TFJLd2krOUNM?=
 =?utf-8?B?Z3NVR0pjT1p1STRZNzBnQUFiRmlRZk9kRjh2TDA1MDF1NzdwMTBaZ1lLR3Nj?=
 =?utf-8?B?dzdIeHZCUnNaVmxuc2tZSm8wYXMxUjdhYmpDNlloMCswZ1ZMMnJyRkE2Mm10?=
 =?utf-8?B?dnErL2p5Y2ZVWjdpUTc3anVWTVQ0c3FWalZrNXA1Vk9td09MdTd6dkl0RTU3?=
 =?utf-8?B?aHlWUWxXaWY5NkdIK2t6dWV1WWZWbjkrU3hURlczVVNKMi96WENBcVM4c01s?=
 =?utf-8?B?RlF2YWVCTWdESkdBVXpGeXQ1MHRTR1J0aitscWhZbGUvNUorenhOSUpqRytW?=
 =?utf-8?B?Rk00dkRMb3dDMk1oTVpKM2g5NGo2Zzl6aTAwckR0R1lDRXJlVUhuaEluSHpZ?=
 =?utf-8?B?YWltSnBFQ1lRdG1aemMzQWlCY2tXRkJzZG9kdHNqNU9IRE4rT3lWNFdqUVFN?=
 =?utf-8?B?cDFVZ01mOVNrWk1UcTd4aG5aclM5SDZyMzBpTG9HYU5tVDZkcXJjcHhieXl6?=
 =?utf-8?B?SER5clRxTlNHRGxGNGJNcG0xbldDY0o1RSt1aFBJKzdmSzZ1eDZmeEFKVlZx?=
 =?utf-8?B?YTdqZ2xDa25oNnhMMnBKTElNa1NCNFBsUi9nSkNJcUk3cFNoRk9JR3EvNldo?=
 =?utf-8?B?N0FHN2IrWDA3RklWN0sxYVd0anZBT1QzUys2NDJvVWtyQVVSNnBObVlHNWFz?=
 =?utf-8?B?bjAxODU0eWltcGVtVEljM2crdjA3OFZNZ09FMWdNVnpNRFR2OGc1Sk1UUHFW?=
 =?utf-8?B?RUc5OXErVE9LZjQxQ3h4WGFRcS9MWjVjN1hBL2ZXdVdmUU4vdzZEK2oxbmI4?=
 =?utf-8?Q?Ri7ZO0ay6QcjacpI=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f2772c8-a166-420c-9e66-08defe35b78a
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2026 21:06:19.9979
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: e+u07jk+lppz5yNmbNTLohhdryPNrH3uO5zxv0MXgYi+ifUZ7fLPtLp7Cv6Kh+CtpXsa7QnKI9QIGzlhryn1mfCq2GVsbdtmxFrELjnTV8k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5604
X-purgate-ID: tlsNG-33051d/1787173583-6FAC44E9-81A618E7/0/0
X-purgate-type: clean
X-purgate-size: 1762

On 19/08/2026 3:53 pm, Jan Beulich wrote:
> On 19.08.2026 16:04, Andrew Cooper wrote:
>> One other idea I had:
>>
>> If we rearrange the loop to have a periodic "taken $X seconds" (shows
>> liveness), and maybe at 40s decide to panic (by passing through the out:
>> label first so we release the APs, so they can crash more cleanly), then
>> that might be acceptable.
>>
>> By 40s, the system isn't surviving even if the cores do all come back.
> Maybe, yet I'm curious: How did you land at 40s as the "magic" boundary?

Mostly arbitrary.  Linux has as least one timeouts around the 20s mark
(panic on soft lockup).  XenServer has some clustering timeouts around 30s.

> For a runtime load, even the 4.5s that you say GNR takes may already be
> too much for the system (Dom0 and/or DomU-s) to properly survive as a
> whole, depending on their requirements and/or configuration.

Its 9s all together, given our algorithm.  And I was a bit surprised,
but even a busy system doesn't seem to suffer any permanent issues as a
consequence.

> Even our
> time calibration rendezvous wants to occur once a second (albeit it may
> not really need to run that often, plus iirc you have been saying that
> we should get rid of it altogether).

Most hardware from the past 15y doesn't need it at all, because of
Invariant TSC.  Some >=8 socket Intel servers need a one-off calibration
during AP bringup, but that suffices AIUI.

There is one advantage to the tsc rendezvous.  If a core/thread/etc
really goes offline, it guarantees to get caught.  With the watchdog, 5
seconds after that, you'll notice.  System-wide TLB flushes have this
property too, but they're irregular and never the thing caught by the
watchdog.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 00:18:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 00:18:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395869.1634038 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwqTr-0002Jt-Ol; Thu, 20 Aug 2026 00:18:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395869.1634038; Thu, 20 Aug 2026 00:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwqTr-0002Jl-Jc; Thu, 20 Aug 2026 00:18:03 +0000
Received: by outflank-mailman (input) for mailman id 1395869;
 Thu, 20 Aug 2026 00:18:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <SRS0=3AlD=GN=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 1wwqTp-0002Je-JY
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 00:18:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwqTn-007Dij-6M
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 02:17:59 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <SRS0=3AlD=GN=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a8647a1-8faa-0a2a0a5109dd-0a2a45029986-22
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 02:17:59 +0200
Received: from [140.77.166.138] (helo=sonata.ens-lyon.org)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <SRS0=3AlD=GN=ens-lyon.org=samuel.thibault@bounce.ens-lyon.org>)
 id 6a8647b6-6ca4-0a2a45020019-8c4da68abd26-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 02:17:59 +0200
Received: from localhost (localhost [127.0.0.1])
 by sonata.ens-lyon.org (Postfix) with ESMTP id 91296A1CFD;
 Thu, 20 Aug 2026 02:17:58 +0200 (CEST)
Received: from sonata.ens-lyon.org ([127.0.0.1])
 by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id prg8_IHdEkWb; Thu, 20 Aug 2026 02:17:58 +0200 (CEST)
Received: from end (168.106.204.77.rev.sfr.net [77.204.106.168])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by sonata.ens-lyon.org (Postfix) with ESMTPSA id 37E7FA1C52;
 Thu, 20 Aug 2026 02:17:58 +0200 (CEST)
Received: from samy by end with local (Exim 4.99.4)
 (envelope-from <samuel.thibault@ens-lyon.org>)
 id 1wwqTl-0000000HOpw-1biG; Thu, 20 Aug 2026 02:17:57 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1787185078; bh=+nnlEIVNbEpSVwyvbAkLaDDMpsBu/R50sIcGqo6KRmc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=A8bSObTRABOU4cVf+Qb0+W8AY+C1eusjKCfohEDlYlgxiB/NrtPfICaR305m1qjOl
	 x1xrwd7zoVG5w87VVJvNOFE/eY/RR5wx137chkJgn3g7vVud5ffGtzfaPSHd0L0rnL
	 uEj73eQzHJ5frqnSbpU9GyKWUCJl9zZ7st5Txry2znHov7d1HPg2W9CnlxOZRbTQ1g
	 HP6agE6WJXES78Gs2AxIelV6RydxpHCV5oSttfewejDDHJJLa+6MsoYhzRQbCBRXu3
	 jWBAqRmsrnOgmR9QGVL08KUGbr47ONDUD4zs3n9RFuAOlz/M4Xem3Gl0dBcf+JU2CQ
	 xtTof2zTmfPYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim;
	t=1787185078; bh=+nnlEIVNbEpSVwyvbAkLaDDMpsBu/R50sIcGqo6KRmc=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=A8bSObTRABOU4cVf+Qb0+W8AY+C1eusjKCfohEDlYlgxiB/NrtPfICaR305m1qjOl
	 x1xrwd7zoVG5w87VVJvNOFE/eY/RR5wx137chkJgn3g7vVud5ffGtzfaPSHd0L0rnL
	 uEj73eQzHJ5frqnSbpU9GyKWUCJl9zZ7st5Txry2znHov7d1HPg2W9CnlxOZRbTQ1g
	 HP6agE6WJXES78Gs2AxIelV6RydxpHCV5oSttfewejDDHJJLa+6MsoYhzRQbCBRXu3
	 jWBAqRmsrnOgmR9QGVL08KUGbr47ONDUD4zs3n9RFuAOlz/M4Xem3Gl0dBcf+JU2CQ
	 xtTof2zTmfPYg==
Date: Thu, 20 Aug 2026 02:17:57 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/4] stubdom: remove pciutils
Message-ID: <aoZHtXgJJJM3q37k@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Jan Beulich <jbeulich@suse.com>, Juergen Gross <jgross@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	xen-devel@lists.xenproject.org
References: <20260817071843.114898-1-jgross@suse.com>
 <20260817071843.114898-3-jgross@suse.com>
 <aoK8zVAP0C0ksD_0@end>
 <2e8b1f56-6447-44c9-9555-4f1b3f0a00e8@suse.com>
 <aoM4ufGg8QO51XB9@end>
 <e47cf430-dc06-4e9d-9a3b-82ed8c081a70@suse.com>
 <aoTRPKeD6__D7Qra@end>
 <41b21e6f-0049-45f8-afae-8116f09fbf22@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <41b21e6f-0049-45f8-afae-8116f09fbf22@suse.com>
Organization: I am not organized
X-purgate-ID: tlsNG-720697/1787185079-660A82AC-01BB67FA/0/0
X-purgate-type: clean
X-purgate-size: 1482

Jan Beulich, le mer. 19 août 2026 08:36:14 +0200, a ecrit:
> On 18.08.2026 23:40, Samuel Thibault wrote:
> > Jan Beulich, le mar. 18 août 2026 08:03:51 +0200, a ecrit:
> >> On 17.08.2026 18:37, Samuel Thibault wrote:
> >>> Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit:
> >>>> On 17.08.26 09:48, Samuel Thibault wrote:
> >>>>> Juergen Gross, le lun. 17 août 2026 09:18:41 +0200, a ecrit:
> >>>>>> There is no user of libpci left in stubdoms.
> >>>>>>
> >>>>>> Remove libpci from the stubdom build system.
> >>>>>
> >>>>> Wouldn't it be useful to keep this for anybody who would want to drive a
> >>>>> PCI card from a stubdomain?
> >>>>>
> >>>>> I mean, in the zlib case, it's really a mere question of build & link,
> >>>>> so we don't need to ship it, people can do it themselves easily like for
> >>>>> any other library.
> >>>>>
> >>>>> But here there is actual porting work, that we'd better not lose but
> >>>>> keep shipping.
> >>>>
> >>>> This is all still available via git.
> >>>
> >>> No, it is not really.
> >>
> >> Question is - does this matter in the first place? If someone wanted to
> >> drive e.g. a USB device, would we include USB code?
> > 
> > Why not? I mean, better centralize the maintenance of such code instead
> > of possibly several people having to maintain their own USB layer each.
> 
> Well, but where would you stop then?

Wherever Xen stops defining a virtualization interface for it.

Samuel


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 05:27:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 05:27:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395931.1634046 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwvJ6-0005u3-KI; Thu, 20 Aug 2026 05:27:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395931.1634046; Thu, 20 Aug 2026 05:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwvJ6-0005tv-F9; Thu, 20 Aug 2026 05:27:16 +0000
Received: by outflank-mailman (input) for mailman id 1395931;
 Thu, 20 Aug 2026 05:27:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wwvJ5-0005tp-17
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 05:27:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwvJ4-000nRz-AW
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 07:27:14 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a869023-e002-0a2a0a5209dd-0a2a450298d0-14
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 07:27:14 +0200
Received: from [209.85.208.50] (helo=mail-ed1-f50.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a869032-6ca4-0a2a45020019-d155d032c105-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 07:27:14 +0200
Received: by mail-ed1-f50.google.com with SMTP id
 4fb4d7f45d1cf-6a378f90555so2667827a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 19 Aug 2026 22:27:14 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c24591989ecsm24409966b.38.2026.08.19.22.27.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 19 Aug 2026 22:27:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787203634; x=1787808434; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=pD5f4qqlrVvZK5V1FYjurHHuEuqcJN2AUDmZ/4khKV0=;
        b=JGhQI8mkEkDuMktT+McgqQuBMb5aO1R63r1w+x8OD5STeVfWsPFfMaveueIujNCC6M
         YKj/YllCzRfbqUkmXkXPS74wC6SJIkgm3zlZ/fh6KSo3edXhD3Y78rlPAJvP5mngqHPY
         KRbmMMORBJSQdTuQ7odO3rSGu02zAueJ150P1nWOpB+wbFg80qQvbNreBSq1AkJlj6fz
         hg7GH/ibqwNIK+etOckzZp1BbEFAfaz7PkmjerEqQruWijlfKtgJoeyARaPoeGeGw/4J
         pHC36fx/6plIWxCWMcjF7KnU6mYjX6O7tU0UoOa1re3XQIgAweJaOGaiSx/jVPyT6FyG
         z0rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787203634; x=1787808434;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=pD5f4qqlrVvZK5V1FYjurHHuEuqcJN2AUDmZ/4khKV0=;
        b=PsVJ/rFhBqniL1DAcORGeifafQxZSoUkYgH1NJqkJJgU9bwAvDacb/iWmwSOh/s5dj
         8zhmPAiTIRBhdXAhUtePFQZVn8FjIBkH1+DTOcKTexmFyDFXZ7cUbl5zDvZiNFR5FX4b
         b2JBHkWdJq6YwMafw/HFGm2STCg0QdNOYOfNcVTWTw7o+vA4xD/qEoSQN4JxN3kNGCz9
         gKEKn5jASonkI5pEKIvjh+WtlW/OD2Q6ce5rfOcMUX3SVwhxFUgQwrkPn4XBs5tCaM6D
         odpJMfO3VRLmIRhCjhVxPpARxvblpTumOmHkpiUvhxQRvPgZbY4zzNNyO+VF5suHJqHx
         bKBw==
X-Forwarded-Encrypted: i=1; AHgh+RrKl2VT8W55LudHpi4JCCM8PEfcnRr7b5Q/fguH7WI1Xq1zG4faSBSIgSZ8tGgJMT6yGAd7/j3PLxs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwdqsQqot0XtCrU9NG/hmnkmmAeO5RxnxyKDGpWij3ab7g1WcBL
	y5lTOITMyLxqR07aK604lMLaJZ9ZaH38HmtOVYZJ4tyBWzN8/JoGxn4t3OVmHYV2R5E=
X-Gm-Gg: AR+sD11G3I1mdV/6EGbn18WFphkzzQV4+PUC9k28Au7ULX2SYmOmy5YkRSMUb6Zkznx
	9is+NfRYrMoHXSn2HAa5cuG76I18za6KrN++JheNdfNyHiyxgL9CReg2qaoNL0N9e2g6onmO5GO
	bWmKunMgk1dAm4zkMoLmf3/eQR9LH3M3VyRbFMFfM2o9JPq5cWg+RDzvwo5SU5FpMTzypZGKrxo
	ugqaxQDMcst8OMODZ6rsOVek8o3SEzm/1jwG8Nf/xgQb+IBLhJltACBgr2elc/MTVKzDCLp3x1I
	dl5RdgtylfO2a9jwdR9knEOMlAQm3Qm+hQpveU3/mK5F8+V5/aMnqMRkS9CkLLPGPkOLAPoGXlF
	1Ruvw/4cnkdaw+FQjF6CCF4tUdIddD8OW7laguOXTOUDoXn9IWG4uBl5Oig/DJElnssdL0pLDJD
	OHc1orP/q4tTOUG8KzKYAdxcYqrtpIhEvxT65SNqo1FDff+psSiUOYIZ83CtnKdQ6/rEOjMOuwV
	gi3xH/E66tbhui5gT/FSANeLFyXInsflSTarIdgppNt+teSwkpEeDaSvnPMyMNAXSZTAN5q3kwb
	INvn035MJhiA9g==
X-Received: by 2002:a17:907:3c8f:b0:c21:34a3:4df9 with SMTP id a640c23a62f3a-c23f92a86e6mr659193466b.3.1787203633620;
        Wed, 19 Aug 2026 22:27:13 -0700 (PDT)
Message-ID: <7c46f230-7eff-4420-aafc-47fdc27abd24@suse.com>
Date: Thu, 20 Aug 2026 07:27:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
To: Sean Christopherson <seanjc@google.com>,
 Dave Hansen <dave.hansen@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-ide@vger.kernel.org,
 dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
 linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org,
 linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org,
 kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org,
 linux-pm@vger.kernel.org, linux-coco@lists.linux.dev,
 linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org,
 linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Damien Le Moal
 <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>,
 David Airlie <airlied@redhat.com>, Helge Deller <deller@gmx.de>,
 linux-geode@lists.infradead.org, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Linus Walleij <linusw@kernel.org>,
 Bartosz Golaszewski <brgl@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Peter Zijlstra <peterz@infradead.org>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu Wen <puwen@hygon.cn>,
 Tony Luck <tony.luck@intel.com>, Reinette Chatre
 <reinette.chatre@intel.com>, Dave Martin <Dave.Martin@arm.com>,
 James Morse <james.morse@arm.com>, Babu Moger <babu.moger@amd.com>,
 Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki"
 <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>,
 Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe
 <rick.p.edgecombe@intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Len Brown <lenb@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>,
 Huang Rui <ray.huang@amd.com>, Mario Limonciello
 <mario.limonciello@amd.com>, Perry Yuan <perry.yuan@amd.com>,
 K Prateek Nayak <kprateek.nayak@amd.com>,
 Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>, Guenter Roeck <linux@roeck-us.net>,
 Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
 Artem Bityutskiy <dedekind1@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
 Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@intel.com>,
 Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
 Lukasz Luba <lukasz.luba@arm.com>, xen-devel@lists.xenproject.org
References: <20260819102314.1499258-1-jgross@suse.com>
 <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
 <aoXM2f1YTwgVj8KL@google.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <aoXM2f1YTwgVj8KL@google.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------OlQIV8uZOa0bnOS7005717DP"
X-purgate-ID: tlsNG-720697/1787203634-F02992AC-6E8D36ED/0/0
X-purgate-type: clean
X-purgate-size: 11354

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------OlQIV8uZOa0bnOS7005717DP
Content-Type: multipart/mixed; boundary="------------qk5J6DZ8xy0dNfYeK9IbauuV";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Sean Christopherson <seanjc@google.com>,
 Dave Hansen <dave.hansen@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
 virtualization@lists.linux.dev, linux-ide@vger.kernel.org,
 dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
 linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org,
 linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org,
 kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org,
 linux-pm@vger.kernel.org, linux-coco@lists.linux.dev,
 linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org,
 linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Damien Le Moal
 <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>,
 David Airlie <airlied@redhat.com>, Helge Deller <deller@gmx.de>,
 linux-geode@lists.infradead.org, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>, Linus Walleij <linusw@kernel.org>,
 Bartosz Golaszewski <brgl@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Peter Zijlstra <peterz@infradead.org>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Josh Poimboeuf <jpoimboe@kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu Wen <puwen@hygon.cn>,
 Tony Luck <tony.luck@intel.com>, Reinette Chatre
 <reinette.chatre@intel.com>, Dave Martin <Dave.Martin@arm.com>,
 James Morse <james.morse@arm.com>, Babu Moger <babu.moger@amd.com>,
 Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki"
 <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>,
 Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe
 <rick.p.edgecombe@intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Len Brown <lenb@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>,
 Huang Rui <ray.huang@amd.com>, Mario Limonciello
 <mario.limonciello@amd.com>, Perry Yuan <perry.yuan@amd.com>,
 K Prateek Nayak <kprateek.nayak@amd.com>,
 Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>, Guenter Roeck <linux@roeck-us.net>,
 Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
 Artem Bityutskiy <dedekind1@gmail.com>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
 Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@intel.com>,
 Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
 Lukasz Luba <lukasz.luba@arm.com>, xen-devel@lists.xenproject.org
Message-ID: <7c46f230-7eff-4420-aafc-47fdc27abd24@suse.com>
Subject: Re: [PATCH v2 00/13] x86/msr: Drop 32-bit MSR interfaces
References: <20260819102314.1499258-1-jgross@suse.com>
 <bd9e5b6e-07f2-459d-bca6-e290585060aa@intel.com>
 <aoXM2f1YTwgVj8KL@google.com>
In-Reply-To: <aoXM2f1YTwgVj8KL@google.com>

--------------qk5J6DZ8xy0dNfYeK9IbauuV
Content-Type: multipart/mixed; boundary="------------VektzkYqobfpSCR53LmeFJO1"

--------------VektzkYqobfpSCR53LmeFJO1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTkuMDguMjYgMTc6MzMsIFNlYW4gQ2hyaXN0b3BoZXJzb24gd3JvdGU6DQo+IE9uIFdl
ZCwgQXVnIDE5LCAyMDI2LCBEYXZlIEhhbnNlbiB3cm90ZToNCj4+IEhleSBKdWVyZ2VuLA0K
Pj4NCj4+IFRoZXNlIGxvb2sgZ3JlYXQuIFRoYW5rcyBmb3IgZG9pbmcgaXQhDQo+Pg0KPj4g
VGhlIG9ubHkgd29ua3kgdGhpbmcgaXMgaG93IHdlJ3JlIGdvaW5nIHRvIGFjdHVhbGx5IG1l
cmdlIGl0LiBXZQ0KPj4gb2J2aW91c2x5IGNhbid0IGRvIHBhdGNoZXMgMTAtMTEgdW50aWwg
YWxsIHRoZSAic3RvcCB1c2luZyIgcGF0Y2hlcyBoYXZlDQo+PiBiZWVuIGFwcGxpZWQuDQo+
Pg0KPj4gSSBvYnZpb3VzbHkgMTAwJSByZWFsaXplIHRoYXQgaXQncyBkdXJpbmcgdGhlIG1l
cmdlIHdpbmRvdywgYnV0IGFueSBhY2tzDQo+PiB0aGF0IHRoZSBtYWludGFpbmVycyBvZiA1
LTkgcHJvdmlkZSBpbiB0aGUgbmV4dCBmZXcgd2Vla3Mgd291bGQgYmUgc3VwZXINCj4+IGhl
bHBmdWwuIE9yLCBpZiBhbnkgb2YgdGhvc2UgbWFpbnRhaW5lcnMgd2FudCB0byBjaGVycnkg
cGljayB0aGVpcg0KPj4gc3Vic3lzdGVtJ3Mgc3R1ZmYgb3V0IG9mIHRoaXMgc2VyaWVzIGFu
ZCBhcHBseSBpdCwgdGhhdCB3b3VsZCBiZSBncmVhdCB0b28uDQo+Pg0KPj4gQnV0LCB0aGUg
bGFzdCB0aW1lIHdlIGRpZCBzb21lIE1TUiBmdW5jdGlvbiBtdW5naW5nLCB0aGUgdGlwIHRy
ZWUNCj4+IGNhcnJpZWQgbW9zdCBvZiB0aGUgcGF0Y2hlcy4gSSB3b3VsZCBleHBlY3Qgd2Un
bGwgaGF2ZSBhIHJlcGVhdCBvZiB0aGF0DQo+PiBoZXJlIHRvby4gSSdsbCBwZW5jaWwgaW4g
dGhlIGlkZWEgb2YganVzdCBtZXJnaW5nIHRoZSBsb3QgYXJvdW5kIC1yYzEgdGltZS4NCj4g
DQo+IE5vdGUsIHBhdGNoIDEyICJ0cmVld2lkZTogY29udmVydCByZG1zcnEoKSBmcm9tIGEg
bWFjcm8gdG8gYW4gaW5saW5lIGZ1bmN0aW9uIg0KPiBpcyBnb2luZyB0byBjb25mbGljdCB3
aXRoIHRoZSBLVk0gY2hhbmdlcyBmb3IgNy4zOyBrdm1fYWNjZXNzX3hzdGF0ZV9tc3IoKSBp
cw0KPiBnZXR0aW5nIG1vdmVkIGZyb20geDg2LmMgdG8gbXNycy5jLiAgU29tZXdoYXQgc3Vy
cHJpc2luZ2x5LCBBRkFJQ1QgdGhhdCdzIHRoZQ0KPiBvbmx5IGNvbmZsaWN0IHdpdGggS1ZN
J3MgY29kZSBtb3ZlbWVudCwgc28gaXQncyBwcm9iYWJseSBub3Qgc3RyaWN0bHkgcmVxdWly
ZWQNCj4gdG8gc2VuZCBhIG5ldyB2ZXJzaW9uIGFmdGVyIHRoZSBLVk0gcHVsbCByZXF1ZXN0
Pw0KDQpJJ20gZXhwZWN0aW5nIHNvbWUgbW9yZSBjb25mbGljdHMgZXNwZWNpYWxseSBmb3Ig
cGF0Y2hlcyAxMC0xMiBiZWZvcmUgdGhleSBhcmUNCm1lcmdlZC4gSSdtIG1vcmUgb3IgbGVz
cyBjb25zdGFudGx5IHJlYmFzaW5nIGxvY2FsbHkuIEluIGNhc2UgYSBjb25mbGljdCBpcw0K
ZGV0ZWN0ZWQsIEknbGwgc2VuZCBhIFYzIGFmdGVyIHJjMS4NCg0KDQpKdWVyZ2VuDQo=
--------------VektzkYqobfpSCR53LmeFJO1
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------VektzkYqobfpSCR53LmeFJO1--

--------------qk5J6DZ8xy0dNfYeK9IbauuV--

--------------OlQIV8uZOa0bnOS7005717DP
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqGkC8FAwAAAAAACgkQsN6d1ii/Ey+e
awf+Jpv8k2uyA4+Ryt6TuDaHqSnrkgatMB0F84HZ1AAuI02rgaxcS4qHeWXYnftFjGMzmdOuklMu
fD2qHqlJtns8wbus6eBshyaJf7L5QqPdODWfJ1xma7m/JkWCfsWEtF1RHh+/gqnAxZ36Pjln1VTa
cxXkk6/DqdrBc78e/ZRqY+yi90Eew9HaLArNBthsvcyWc9uXr8aGVl4naO3p/2Pj6J8FxDK7+9rm
OVsJX5tkOwDyarQUJGLfaSNizqJT0nDnb+VyBzRdCHS06Uy2ho9GXkp83OfJo7tn5MWHtggptx9W
8Q9DFLf/YdwL9qfWGVa/u5zq863UtqO9SWyFmp3aYQ==
=np+M
-----END PGP SIGNATURE-----

--------------OlQIV8uZOa0bnOS7005717DP--


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 06:06:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 06:06:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395956.1634055 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwvv2-0002co-Cz; Thu, 20 Aug 2026 06:06:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395956.1634055; Thu, 20 Aug 2026 06:06:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwvv2-0002ch-AR; Thu, 20 Aug 2026 06:06:28 +0000
Received: by outflank-mailman (input) for mailman id 1395956;
 Thu, 20 Aug 2026 06:06:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dlemoal@kernel.org>) id 1wwvv1-0002cb-VS
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 06:06:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwvv1-004edB-CM
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 08:06:27 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dlemoal@kernel.org>)
 id 6a869961-8faa-0a2a0a5109dd-0a2a4509a95a-16
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 08:06:27 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dlemoal@kernel.org>)
 id 6a869962-be1a-0a2a45090019-ac6904feceb4-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 08:06:27 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 4954360A84;
 Thu, 20 Aug 2026 06:06:25 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 106F71F000E9;
 Thu, 20 Aug 2026 06:06:11 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1787205985;
	bh=8Ul4LcNKNGu0Z584PICkjX7+P+obMk+pMAEdlAEtBLc=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To;
	b=n7FFTwj85oHM8+Z0bncLFNY9/eW5UxEc3LeFSPwVmM/J0yU3NCrZjNz2zCIEYZwLE
	 VkUDYV1ptH6tax/0F1oXiJjDiE4SC7hgcWjk/xP+EHEssecT4QfZMP4aTD2PVsDkB/
	 PHZc88roAXGNSFiQUibZJ0cNvxEnz09z/agN4p5AbkwKKXMWc8TIrdxjcPbruKZSKu
	 3OPsCjNo23WGFwZ6ajg3ye5CpkwpwGndpwB3CJOPi5MYLZRxkxBpTyt0laVyIVRSIA
	 t9R0jcmDR/EPUk7IXvEelvCevQFSUrNEUzW4iSTQEsCRum1JwmrzWQUfF/uSY/YiLe
	 LHO1ski2SQNRg==
Message-ID: <21d31639-4d16-4ee2-8ff3-18877636aa8b@kernel.org>
Date: Thu, 20 Aug 2026 15:06:10 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/13] treewide: convert rdmsrq() from a macro to an
 inline function
To: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
 x86@kernel.org, linux-perf-users@vger.kernel.org,
 linux-hyperv@vger.kernel.org, kvm@vger.kernel.org,
 virtualization@lists.linux.dev, linux-edac@vger.kernel.org,
 linux-pci@vger.kernel.org, linux-pm@vger.kernel.org,
 linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org,
 linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org,
 linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org,
 linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org,
 platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "H. Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>,
 Arnaldo Carvalho de Melo <acme@kernel.org>,
 Namhyung Kim <namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
 Adrian Hunter <adrian.hunter@intel.com>, James Clark
 <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Sean Christopherson <seanjc@google.com>, Paolo Bonzini
 <pbonzini@redhat.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
 Alexey Makhalov <alexey.makhalov@broadcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>, Josh Poimboeuf
 <jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
 Pu Wen <puwen@hygon.cn>, Tony Luck <tony.luck@intel.com>,
 Reinette Chatre <reinette.chatre@intel.com>,
 Dave Martin <Dave.Martin@arm.com>, James Morse <james.morse@arm.com>,
 Babu Moger <babu.moger@amd.com>, Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>,
 Vitaly Kuznetsov <vkuznets@redhat.com>, Andy Lutomirski <luto@kernel.org>,
 Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki"
 <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>,
 Kiryl Shutsemau <kas@kernel.org>, Rick Edgecombe
 <rick.p.edgecombe@intel.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Len Brown <lenb@kernel.org>, Niklas Cassel <cassel@kernel.org>,
 David Airlie <airlied@redhat.com>, Olivia Mackall <olivia@selenic.com>,
 Herbert Xu <herbert@gondor.apana.org.au>,
 Viresh Kumar <viresh.kumar@linaro.org>, Huang Rui <ray.huang@amd.com>,
 Mario Limonciello <mario.limonciello@amd.com>,
 Perry Yuan <perry.yuan@amd.com>, K Prateek Nayak <kprateek.nayak@amd.com>,
 Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
 Yazen Ghannam <yazen.ghannam@amd.com>, Linus Walleij <linusw@kernel.org>,
 Bartosz Golaszewski <brgl@kernel.org>, Guenter Roeck <linux@roeck-us.net>,
 Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
 Artem Bityutskiy <dedekind1@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Miquel Raynal <miquel.raynal@bootlin.com>,
 Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
 Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
 David E Box <david.e.box@intel.com>,
 Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
 Lukasz Luba <lukasz.luba@arm.com>, Helge Deller <deller@gmx.de>,
 xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org
References: <20260819102314.1499258-1-jgross@suse.com>
 <20260819102314.1499258-13-jgross@suse.com>
Content-Language: en-US
From: Damien Le Moal <dlemoal@kernel.org>
Organization: Western Digital Research
In-Reply-To: <20260819102314.1499258-13-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787205987-3AAD8034-0B00B6B7/0/0
X-purgate-type: clean
X-purgate-size: 652

On 8/19/26 19:23, Juergen Gross wrote:
> Today rdmsrq() is a macro using its second parameter as the target for
> storing the read MSR value.
> 
> Convert rdmsrq() to an inline function returning the MSR value.
> 
> The users have been converted using the following semantic patch:
> 
>   // Options: --include-headers
> 
>   virtual patch
>   virtual report
> 
>   @@
>   expression msr, val;
>   @@
>   (
>   - rdmsrq(msr,val)
>   + val = rdmsrq(msr)
>   )
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

For the ata bits,

Acked-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 07:14:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 07:14:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395977.1634065 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwwyI-0003FO-3M; Thu, 20 Aug 2026 07:13:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395977.1634065; Thu, 20 Aug 2026 07:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwwyH-0003FH-Ve; Thu, 20 Aug 2026 07:13:53 +0000
Received: by outflank-mailman (input) for mailman id 1395977;
 Thu, 20 Aug 2026 07:13:53 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wwwyG-0003FB-N5
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 07:13:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwwyG-00EEV8-3Z
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:13:52 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a86a924-e002-0a2a0a5209dd-0a2a4506a402-28
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:13:48 +0200
Received: from [52.101.57.54]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a86a92a-195a-0a2a45060019-34653936c83b-4
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:13:47 +0200
Received: from SJ0PR03CA0290.namprd03.prod.outlook.com (2603:10b6:a03:39e::25)
 by CYXPR12MB9280.namprd12.prod.outlook.com (2603:10b6:930:e4::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.9; Thu, 20 Aug
 2026 07:13:42 +0000
Received: from CO1PEPF000066E8.namprd05.prod.outlook.com
 (2603:10b6:a03:39e:cafe::1) by SJ0PR03CA0290.outlook.office365.com
 (2603:10b6:a03:39e::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.8 via Frontend Transport; Thu, 20
 Aug 2026 07:13:41 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CO1PEPF000066E8.mail.protection.outlook.com (10.167.249.6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.339.3 via Frontend Transport; Thu, 20 Aug 2026 07:13:41 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 20 Aug
 2026 02:13:41 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 20 Aug
 2026 02:13:40 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Thu, 20 Aug 2026 02:13:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w04bSLi+NvUdYWugna4SPw8PL57pyFb37+KiR7y1+fCXDWjv4ZYRgHKf1GTBF+aXC6lPcS05OJXs1cOxE0QLd4hQBJ2zkixxDGbxz5LfmQDpi3lBMk3vTsPyQ2TTTzAfz9qVd/6MEKaJmjPd7JhedLMGHMOkc+oDDSKrT1dZLRsWWT2V3xcEkYT2S0kEfyJLBdhYedf8FXBE48pHK7g1OTXfpMWaWHb8O2Ixeerm28afDe8nLfkscKCDLzbiWjBHhUCC/f6yU+aEI9e9NQOtUKn+7QQQRUORcWZ8N70wA4svKE+v5wZOAjTVZEtWQ1lFmo1RwM4biei3drTMqOSRsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=D9h8NqKPbXOk0n+m3x7gD/9twF1D1vVmvxEUaxrs3nQ=;
 b=jAzl3wmqo6d2JH0UgzDq4zCgNbowJsu3LqhwXl7WnX0K9D2l94GLTFmX54TXmf1Uyvx9NxVTEKDijo3OkKREuo0YFgCOudB7lT0Z4/9S9FJD57cxI7SkgcdJDF6IlWZl7+9AHtd1oFmRmXDabPSZiPRQK328YQHFkft3BvFOTK1Wq73Nv5+LJaBa07GV2GXiaOyaJmx2di4TH6OF/8o6ChrWENNVq5EFRX1vc/rY9AvGWToJ3bxGYZX2LywRtcDPZnUvMHew5qoc/8J1H35ND5O+x3RIlYI1YfhXJ7ChHV8tyylMvVVesq9rScTjiy+EDky6r7Re6K2rAX4fJ5Vp/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=D9h8NqKPbXOk0n+m3x7gD/9twF1D1vVmvxEUaxrs3nQ=;
 b=sQaH65UYdbb1Wken+mPZfvqmijCdpAg1s1mFE+aNs4W8C9Ky0lmNksSCVnDsnZLepZwrWwqZW6gSGSqIDPEFcBInKgPwG73zy4fVrk6m2Y/lZy5NH3LZNopYecU5JHj17z5WzYsRQ8wYGYqrYGxakpVEvyrox6jBLaLUV2yc2p0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <d9c1df07-ae4e-4fe7-bfbf-09cfbd9ceda9@amd.com>
Date: Thu, 20 Aug 2026 09:13:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/4] xen/arm: add i.MX8M platform support
To: Wig Cheng <onlywig@gmail.com>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, John Ernberg <john.ernberg@actia.se>,
	Peng Fan <peng.fan@nxp.com>
References: <20260819152821.3361898-1-onlywig@gmail.com>
 <20260819152821.3361898-4-onlywig@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260819152821.3361898-4-onlywig@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000066E8:EE_|CYXPR12MB9280:EE_
X-MS-Office365-Filtering-Correlation-Id: f870b918-544c-4756-402a-08defe8a9096
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700016|1800799024|23010399003|82310400026|56012099006|4143699003|11063799006|10067099003|18002099003|22082099003|6133799003;
X-Microsoft-Antispam-Message-Info:
	wc4wIEuINhdGh+2FOiZH6tlG+7vbRF+VRDtP71BmwdjfJVLGHbkwXJ6p2gP0DjRqEGvP5vhwsSZdE1562VLv1m0DVyU3mx3fAj/1dgFSjopxWscPiJ/XJlmI/KMXy2j1n52w44AKo6wX2Im7kpA5potiiDUtUiJc0nFgCyOiJpMoH3veTTmiTj4V5nE+afmrlGhipheFASWZsaIEnF7i3sVl8TK5CMWG6nNpSbOGAoifuA7kHwZCBbmmf6+eXuBSVlGYwfoEmNTJmHyKa4iVbKXFZv045aS7YnhPioZFJYumsuIsA6nh1U9akg0Akm1fbv8RTxGslPn21Buwr0u2pQ/pNKrsaSwkQVknQyZ/daaHZmSceFxUWE5qkyUoyjwSZyBOtzuKV1is9WEeRRTusTCdtsyWu5ZNpZcQ6xUHwPPuuafyhObETu/9B6eZ8cynkV8PKOKPNqI+c4NVrAz9R3K1ggIhsaTB5o6yYBwp9Q18QnQSpVSDR+Vx07tLU7UJw4g/0GB1SDI0Ofnkh1dE+O4NGDVbY6FiocEYGJbPSl9rgQfaEcD92Y9SPVEdWAaXXIE8+7WX/YUIG/z3+y/NV34lkVfCqt3SDrmXhgeBsX2mbuzyTnG0rIf3V3OHWG3Lw0EGx+qz5GZBAD5G49Nxmj7oGN/up737vLwt3BgCWzNfpDOED8gMEZrooZgb17XTeaFmiuiS/1FVNUrLBnWVAg==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(23010399003)(82310400026)(56012099006)(4143699003)(11063799006)(10067099003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	51odEQQCWbNXyfkWi5vAQ/E4QX8oHvjnanX2i0flbLGoXMY2+g3TnhVi+YxTIt5KyDzm9nVtyri/4I3Ob5GRY41+Dm6K6UoXB1YkKnZaOOYnp8Cu7WywDEiO21SFOMwcSeGFd9Xyvotq++SAdKisbeT2fje76y1DqqtevSyUYM5Nrh5TMG+adxVeBCbPRle0lkg7B6umjkgAGO9hWLeH4y8IwkwkkVlqtW1bR/U0oQJpp51dSC0ANKLMiOiQTaho36nUPgc4YzEL6v1oSqV+9XaIXndggd18SlmU7NBGuYU1F3Yqj1Bvn9N5jjvh7zq4CEiMC2hNfqAgzvP+ns3RwJ24I5Kct2Qf/kGMraXoAdLEG3GJuXBKc2OEO5UVe5SBP4/KwKDJhCObRPy3xeU/c7daXD0QO+UB7iOzI9Kgn/K0woMuNG6vUnhX0OUle/3l
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2026 07:13:41.6539
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f870b918-544c-4756-402a-08defe8a9096
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000066E8.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9280
X-purgate-ID: tlsNG-16d1c6/1787210028-F7ACA77B-0BBD3E8F/0/0
X-purgate-type: clean
X-purgate-size: 6775



On 19-Aug-26 17:28, Wig Cheng wrote:
> Add platform glue for the NXP i.MX8M family (i.MX8MP/MQ/MM/MN).
> 
> When Linux is used as dom0 a number of drivers make SiP SMC calls into
> TF-A to manage hardware: GPC power domains, SRC (M-core remoteproc),
> SoC info and NoC QoS.  There is no public specification for these
> calls; the function IDs and their subfunctions are taken from the
> vendor kernel call sites.
> 
> Forward only the specific subfunctions the hardware domain issues,
> following the whitelist model of the i.MX8QM platform.  Each service
> with a fixed set of subfunctions (GPC, SRC, NoC) filters them with an
> explicit switch on the subfunction id, and the SoC info call is a
> read-only query.  CPU and DRAM frequency scaling are denied because
> the hardware domain cannot make an informed decision about resources
> shared with the other domains, and any unknown function ID is
> rejected.
> 
> Signed-off-by: Wig Cheng <onlywig@gmail.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> ---
> Changes in v4:
> - SRC and NoC: filter the subfunction id with an explicit switch that
>   lists each accepted subfunction, instead of a range check.
> - NoC: accept only the QoS priority subfunction; the LCDIF subfunction
>   has no caller in the vendor kernel.  Note that i.MX8MP issues no NoC
>   call at boot (only i.MX8MQ does).
> - Print the subfunction id as well when rejecting an unknown function
>   id.
> - Picked up Michal's Reviewed-by.
> 
>  xen/arch/arm/platforms/Makefile |   1 +
>  xen/arch/arm/platforms/imx8m.c  | 161 ++++++++++++++++++++++++++++++++
>  2 files changed, 162 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/imx8m.c
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index bec6e55d1f..cdf936c50d 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_ALL_PLAT)   += sunxi.o
>  obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>  obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>  obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
> +obj-$(CONFIG_ALL64_PLAT) += imx8m.o
>  obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o
>  obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp-eemi.o
> diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
> new file mode 100644
> index 0000000000..ad76935f5d
> --- /dev/null
> +++ b/xen/arch/arm/platforms/imx8m.c
> @@ -0,0 +1,161 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * i.MX 8M family setup
> + *
> + * Copyright 2026 Open-EP (E-Paper) Community
> + */
> +
> +#include <xen/sched.h>
> +#include <asm/platform.h>
> +#include <asm/regs.h>
> +#include <asm/smccc.h>
> +
> +static const char * const imx8m_dt_compat[] __initconst =
> +{
> +    "fsl,imx8mp",
> +    "fsl,imx8mq",
> +    "fsl,imx8mm",
> +    "fsl,imx8mn",
> +    NULL
> +};
> +
> +#define IMX_SIP_FID(fid) \
> +    ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +                       ARM_SMCCC_CONV_64, \
> +                       ARM_SMCCC_OWNER_SIP, \
> +                       (fid))
> +
> +/*
> + * SiP SMC function IDs used by the i.MX8M Linux drivers.  There is no
> + * public specification for these; the IDs and their subfunctions are
> + * extracted from the vendor kernel call sites (see drivers/soc/imx,
> + * drivers/devfreq, drivers/remoteproc).
> + */
> +#define IMX_SIP_F_GPC       0x0   /* GPC power-domain control */
> +#define IMX_SIP_F_CPUFREQ   0x1   /* CPU frequency scaling */
> +#define IMX_SIP_F_DDR_DVFS  0x4   /* DRAM frequency scaling */
> +#define IMX_SIP_F_SRC       0x5   /* SRC: M-core remoteproc start/stop */
> +#define IMX_SIP_F_SOC_INFO  0x6   /* read-only SoC info query */
> +#define IMX_SIP_F_NOC       0x8   /* NoC QoS priority setup */
> +
> +#define IMX_SIP_GPC_SF_PM_DOMAIN    0x03
> +
> +#define IMX_SIP_SRC_SF_M4_START     0x00
> +#define IMX_SIP_SRC_SF_M4_STARTED   0x01
> +#define IMX_SIP_SRC_SF_M4_STOP      0x02
> +
> +#define IMX_SIP_NOC_SF_PRIORITY     0x01
> +
> +static bool imx8m_smc(struct cpu_user_regs *regs)
> +{
> +    uint32_t function_id = get_user_reg(regs, 0);
> +    uint32_t subfunction_id = get_user_reg(regs, 1);
> +    struct arm_smccc_res res;
> +
> +    if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
> +    {
> +        printk_once(XENLOG_WARNING
> +                    "imx8m: smc: no SMCCC 1.1 support. Disabling firmware calls\n");
> +
> +        return false;
> +    }
> +
> +    /* Only the hardware domain may use the SiP calls */
> +    if ( !is_hardware_domain(current->domain) )
> +    {
> +        gprintk(XENLOG_WARNING, "imx8m: smc: No access\n");
> +        return false;
> +    }
> +
> +    /*
> +     * Forward only the subfunctions the dom0 kernel actually issues.  All
> +     * of these manage hardware that belongs to the hardware domain (power
> +     * domains, M-core, NoC) or are read-only queries.
> +     */
> +    switch ( function_id )
> +    {
> +    case IMX_SIP_FID(IMX_SIP_F_GPC):
> +        if ( subfunction_id != IMX_SIP_GPC_SF_PM_DOMAIN )
> +            return false;
> +        break;
> +
> +    /*
> +     * CPU and DRAM frequency scaling: the hardware domain does not see the
> +     * whole system and cannot make an informed decision about resources
> +     * shared with the other domains, so deny both (CPU frequency scaling
> +     * is denied on the i.MX8QM platform for the same reason).
> +     */
> +    case IMX_SIP_FID(IMX_SIP_F_CPUFREQ):
> +    case IMX_SIP_FID(IMX_SIP_F_DDR_DVFS):
> +        return false;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_SRC):
> +        /* SRC: M-core remoteproc start, poll-started and stop. */
> +        switch ( subfunction_id )
> +        {
> +        case IMX_SIP_SRC_SF_M4_START:
> +        case IMX_SIP_SRC_SF_M4_STARTED:
> +        case IMX_SIP_SRC_SF_M4_STOP:
> +            break;
> +
> +        default:
> +            return false;
> +        }
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_SOC_INFO):
> +        break;
> +
> +    case IMX_SIP_FID(IMX_SIP_F_NOC):
> +        /*
> +         * NoC QoS priority setup.  Only i.MX8MQ issues this at boot;
> +         * i.MX8MP issues no NoC call, but the platform covers both.
> +         */
> +        switch ( subfunction_id )
> +        {
> +        case IMX_SIP_NOC_SF_PRIORITY:
No need for a switch for a single case. This can be simplified the same way as
you did for IMX_SIP_GPC_SF_PM_DOMAIN i.e.:
if ( subfunction_id != IMX_SIP_NOC_SF_PRIORITY )
    return false;
break;

I'll fix on commit. Thanks for the series. I'll commit it shortly.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 07:34:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 07:34:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1395996.1634073 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxI7-00066W-Li; Thu, 20 Aug 2026 07:34:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1395996.1634073; Thu, 20 Aug 2026 07:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxI7-00066P-Ie; Thu, 20 Aug 2026 07:34:23 +0000
Received: by outflank-mailman (input) for mailman id 1395996;
 Thu, 20 Aug 2026 07:34:21 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwxI5-00066J-N3
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 07:34:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwxI5-00EKfo-3G
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:34:21 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86adfc-bab6-0a2a0a5309dd-0a2a450bea4c-6
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:34:20 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86adfc-b7e8-0a2a450b0019-d155dd2bc8aa-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:34:20 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-480033bdcf4so1151235f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 00:34:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e784b3sm106612955e9.3.2026.08.20.00.34.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 00:34:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787211260; x=1787816060; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=BrRbmE6A4s++MJpiH/sxkRvu2kym42T2lS4Vq6tq99I=;
        b=LeJPUD7Wr783Ff+GKYohREXGAYQ+4dSJTBm+zHabNx4weiI2nrH/Wt0Ov0fBOAmsBS
         Kd2yoWtuARRHggxqfCYS66hKJsdzBwDFeDxqBKA9CnpmRnVIfI6SWGgoCMqkVeb7JS12
         lMW2iAc/v8AlotVVlf314Tcti1sscKsFKUFNdQ0QkZT7idXtX0tc86uUcEB90+yx2iMi
         Bp3N22SjqpbDQWwb2NZjTdq+ua+tnoDsqKFl/1s6ZRZaiA94S3VnPEJOnDVKHwFeWkzr
         KIF5zMRpFFE+BWJPFNJEtivehFNG1X62sT/fmcUZWNzMbULfLGZ2hHBrX/gtrdOUTCaj
         QBGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787211260; x=1787816060;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=BrRbmE6A4s++MJpiH/sxkRvu2kym42T2lS4Vq6tq99I=;
        b=sSrgk2mZx//gsmF+2VDD9VqACuiE9p78JDFpJWRIBccPyvHKyDZ4QDAggcfAleE6fA
         zdh6zVMVqBxAUV28b939hQ5D6hax1psQfeAp1xFD2h+ahfs/7FLpqfhGFxMLSKCBOfFZ
         sqOi0IBMnZk4CIALk9OGEpUnC7XsuOGfUtTiXMphwnu0s5+qMxgbq8uxQJMk3nuWExjo
         xAiv+p3322o7Clr11mrW3faLcgX/8zQ6xD5cfXrYfx8hYc5XfZjKXcE+u2H9DalnB4fp
         T/2JoSi7unQ4HBd8AhaBv6w6oUF+QaX2CyAHH0pEybcuQmn0e7hNxs9CXPqL7oxbSTfF
         G1gA==
X-Forwarded-Encrypted: i=1; AHgh+Rof3uIPM7esCosYAuiAwC19aUUY5veB6R4hlPUOEznAmQj89gHmIPwf3UTZxxnkGIfNknmCe6fDBxs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+TidiPhOM/2nV2Yrtna3qErKkTJ5xhfEg+7EiTz4Bu/7n45w6
	2DB1ZsWmusBqlRd4/RI9nLwpTza27vDQ03TpVUC2ZZFvRmNUXFoXS7aoALylHAxHtQ==
X-Gm-Gg: AR+sD10OvBSaMYk0xVn+dWQaC6xOu8uV0z6WzoDp+ffddjYuJxz4/1oZFwprOI38Dri
	BJ8HIEfbOjww0r+ZL57PgyyPSIUap3CyOeaE/BmyazIYvX/b6lf35BAUoWm/YNnHIywoqh5hDzr
	Rkb/EaVlcF76wjkwA5a4FZmY+EzkcwG5qC6xqR8LQOTBQB2Issf0XWAHGBVoKYFK20znGLuighj
	cuhQBYfatduLTrvAMhkSD6pXZXYR1pPRU4qN61A8pkQk8URG/DtQkG9zRCMFw7tyzQIKbJVPxYt
	l1yPHCUNDeEiNatBNDsKjfZrg9EdkVwDD6+8twxEQBpGSQ+l3Y+ZE+QacUWv6OXv3zsmt6GLB0Z
	MwNCxmE6UV5U3kQdQDEzEQPBvZMT03BXtfU7xoOo/aEAvo5AAIuaJ6VbVCDV/V1he/f+dIdo71+
	lX9F2+zvwPyn018MTuhJobkm6YvFyvvRFfKB35bAMQ7B8Ratp8RoOqUc2JL3bmeC7gxCmGyIJwL
	h1NwRHgRbHWhFr9i9lrkpyzuX6/oSGm8BvQ8T/l4jftiVobcm6/
X-Received: by 2002:a05:600c:1387:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-499aa1a47cfmr146411295e9.7.1787211259682;
        Thu, 20 Aug 2026 00:34:19 -0700 (PDT)
Message-ID: <a64d4714-2215-4bff-9dfa-2cbcc36ce3f2@suse.com>
Date: Thu, 20 Aug 2026 09:34:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
 <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
 <aff1f879-48c6-4047-a6c1-237a350e0f35@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <aff1f879-48c6-4047-a6c1-237a350e0f35@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787211260-A90CD9EA-FE193D31/0/0
X-purgate-type: clean
X-purgate-size: 14916

On 19.08.2026 18:06, Oleksii Kurochko wrote:
> On 8/13/26 9:15 AM, Jan Beulich wrote:
>> On 29.07.2026 15:40, Oleksii Kurochko wrote:
>>> @@ -210,9 +217,162 @@ static always_inline unsigned long get_faulting_gpa(void)
>>>       return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>>   }
>>>   
>>> +/*
>>> + * Determine the trapped instruction which caused a guest MMIO trap.
>>> + *
>>> + * Returns true if the trap was redirected to the guest, in which case
>>> + * the caller must stop emulation and return success. Otherwise *insn
>>> + * and *insn_len are filled in and the caller should continue decoding.
>>> + */
>>> +static bool decode_trapped_insn(unsigned long htinst, unsigned long *insn,
>>> +                                unsigned int *insn_len)
>>> +{
>>> +    if ( htinst & 0x1 )
>>> +    {
>>> +        /*
>>> +         * Bit[0] == 1 implies trapped instruction value is
>>> +         * transformed instruction or custom instruction.
>>> +         */
>>> +        *insn = htinst | INSN_16BIT_MASK;
>>> +        *insn_len = (htinst & BIT(1, UL)) ? INSN_LEN(*insn) : 2;
>>
>> In the if() you don't use BIT(), while here you do. Please be consistent.
>>
>> Why the use of INSN_LEN(), when due to the earlier assignment it'll always
>> yield 4 here?
> 
> ld/sd instruction which we are trapping here at the moment here could be 
> 2 bit and 4 bit depends on C extension so we need to pass correct 
> instruction length to advance_pc() after it is emulated.

Well, fine, but how does that matter? I pointed you at the preceding
assignment, which sets bits 0 and 1. With that INSN_LEN() is guaranteed
to return (at least) 4 (and it's not presently capable of returning
values larger than 4).

>> Finally, how would the caller know whether it looks at a transformed insn
>> or (as fetched below) a "normal" one?
> 
> According to the spec ((part from htinst ... ):
> On a synchronous exception, if a nonzero value is written, one of the 
> following shall be true about the value:
> 
> • Bit 0 is 1, and replacing bit 1 with 1 makes the value into a valid 
> encoding of a standard instruction.
> In this case, the instruction that trapped is the same kind as indicated 
> by the register value, and the register value is the transformation of 
> the trapping instruction, as defined later. For example, if bits 1:0 are 
> binary 11 and the register value is the encoding of a standard LW (load 
> word) instruction, then the trapping instruction is LW, and the register 
> value is the transformation of the trapping LW instruction.
> 
> • Bit 0 is 1, and replacing bit 1 with 1 makes the value into an 
> instruction encoding that is explicitly designated for a custom 
> instruction (not an unused reserved encoding). This is a custom value. 
> The instruction that trapped is a non-standard instruction. The
> interpretation of a custom value is not otherwise specified by this 
> standard.
> 
> • The value is one of the special pseudoinstructions defined later, all 
> of which have bits 1:0 equal to 00.
> 
> So setting bit 0 to 1 we will guarantee that it is normal "normal" 
> instruction.

Right. Yet my question was how to distinguish the cases. Or are you trying
to tell me that distinguishing isn't going to be necessary, anywhere?

>>> +    }
>>> +    else
>>> +    {
>>> +        struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>
>> Pointer-to-const.
>>
>>> +        struct trap_info utrap = { 0 };
>>
>> Just {} please.
>>
>>> +        /*
>>> +         * Bit[0] == 0 implies trapped instruction value is
>>> +         * zero or special value.
>>> +         */
>>
>> How come you get away without dealing with pseudoinsns? The insn pointed at
>> by regs->sepc is of no interest for faults caused by implicit memory accesses
>> originating from VS-stage address translation.
> 
> It is really problem but I think it should be resolved much earlier in 
> handle_guest_page_fault(). I will add the following:
> 
> /*
>       * A guest page fault taken on an implicit memory access performed for
>       * VS-stage address translation (reading a PTE, or updating its A/D 
> bits)
>       * reports a pseudoinstruction in htinst rather than a transformed
>       * instruction. Such a fault can't be emulated: htval holds the guest
>       * physical address of a VS-stage PTE rather than of any access the 
> guest
>       * itself performed (and its two least significant bits are zero 
> instead
>       * of matching stval), while the instruction at sepc is unrelated 
> to the
>       * access which actually faulted.
>       *
>       * Report an access fault to the guest at the original virtual address,
>       * which is what stval already holds and what hardware would raise 
> for a
>       * page table walk hitting an inaccessible address.
>       */
>      if ( (htinst == INSN_PSEUDO_VS_LOAD) || (htinst == 
> INSN_PSEUDO_VS_STORE) )
>      {
>          struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>          struct trap_info utrap = {
>              .scause = (htinst == INSN_PSEUDO_VS_LOAD) ? CAUSE_LOAD_ACCESS
>                                                        : CAUSE_STORE_ACCESS,
>              .sepc = regs->sepc,
>              .stval = csr_read(CSR_STVAL),
>          };
> 
>          riscv_trap_redirect(&utrap);
>          return;
>      }

That's not what would happen on bare hardware though, aiui. At least I don't
think I ever found it being spelled out anywhere what the supposed behavior
is when a page table resides in unpopulated space.

>>> +        *insn = riscv_vcpu_unpriv_read(true, regs->sepc, &utrap);
>>> +        if ( utrap.scause )
>>> +        {
>>> +            /*
>>> +             * A G-stage fault here would mean the P2M mapping of the page
>>> +             * containing the trapped instruction disappeared after it was
>>> +             * fetched.
>>
>> Does it? What about, again, faults from VS-stage address translation while
>> hardware was trying to fetch an insn? That is ...
>>
>>> Nothing removes P2M mappings of a running domain yet,
>>> +             * so this cannot happen.
>>
>> ... the necessary P2M mapping may never have been there.
> 
> If VS-stage failed then CAUSE_LOAD_PAGE_FAULT will happen so BUG_ON() 
> won't occur and it will be passed to guest to handle it.

Are you sure? So far it was my understanding that CAUSE_LOAD_PAGE_FAULT
would happen when VS-stage translation hits e.g. a non-present leaf
entry. But got an address translation failure while doing the VS-stage
page walk (i.e. failure to translate the address found in a VS-stage
PTE to a host address) would raise CAUSE_LOAD_GUEST_PAGE_FAULT.

> BUG_ON() here catches CAUSE_LOAD_GUEST_PAGE_FAULT (G-stage translation 
> failure).
> 
> Also, as I mentioned above I will change BUG_ON() too:
> 
>              /*
>               * 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
>               */

What is "bus" here (dym "bug"?), and why is the sentence unfinished?

>>> +             * TODO: Revisit once P2M mappings can be removed at runtime.
>>> +             */
>>> +            BUG_ON(is_load_guest_page_fault(utrap.scause));
>>> +
>>> +            utrap.sepc = regs->sepc;
>>> +            utrap.stval = utrap.sepc;
>>
>> How do you know the fault was at .sepc? A 32-bit insn crossing a page boundary
>> (implying the C extension is available) may well fault only on its higher half.
> 
> According to the spec, if stval is written with a nonzero value when an 
> instruction access-fault or page-fault exception occurs on a system with 
> variable-length instructions, then stval will contain the virtual 
> address of the portion of the instruction that caused the fault, while 
> sepc will point to the beginning of the instruction.
> 
> So here, we are trying to emulate what real hardware will do in this 
> case. In regs->sepc, we have the start of the instruction that we didn't 
> touch. sepc is filled according to the spec in this case.

Right, but utrap.stval is set to the same value, which is explicitly not
in line with what you say above ("will contain the virtual address of the
portion of the instruction that caused the fault").

> Regarding utrap.stval, we know that utrap.sepc points to the correct 
> part of the faulting address, as we are reading the instruction in 
> 16-bit chunks:
> 
> HLVX_HU(%[val], %[addr])        ; low 16 bits from sepc
> andi %[tmp], %[val], 3
> addi %[tmp], %[tmp], -3
> bne  %[tmp], zero, 2f           ; if not (insn & 3) == 3 -> 16-bit, end
> addi %[addr], %[addr], 2        ; <- addr is now sepc+2
> HLVX_HU(%[tmp], %[addr])        ; high 16 bits, possibly from another page
> 
> So, if a trap happens while reading the high 16 bits (which may be 
> located on another page), then utrap.sepc, if the read fails, will point 
> to the high part of the instruction, which is what the spec requires.
> 
> Does that make sense?

Not really, no. As said above - the code as written guarantees
utrap.stval == utrap.sepc, and that cannot always be correct.

>>> +/*
>>> + * Check alignment and dispatch a decoded MMIO access to a registered
>>> + * handler. On success (0), info->data holds the read value for loads.
>>> + */
>>> +static int do_mmio(mmio_info_t *info, unsigned long fault_addr,
>>> +                   unsigned int len)
>>> +{
>>> +    /* Fault address should be aligned to length of MMIO */
>>> +    if ( fault_addr & (len - 1) )
>>> +        return -EIO;
>>> +
>>> +    info->gpa = fault_addr;
>>> +    info->len = len;
>>> +
>>> +    switch ( try_handle_mmio(info) )
>>> +    {
>>> +    case IO_HANDLED:
>>> +        return 0;
>>> +    case IO_ABORT:
>>> +        return -EIO;
>>> +    default:
>>> +        return -EOPNOTSUPP;
>>> +    }
>>> +}
>>
>> And there's no indication of "retry needed", e.g. when something changed
>> between find_mmio_handler() and handle_{read,write}()?
> 
> I don't have any specific scenario where it is needed now so I don't 
> know what to say.
> And there is no race between find_mmio_handler() and 
> handle_{read,write}() as find_mmio_handler() returns copy of the 
> structure under read_lock():

Oh, right, but that's not visible here at all and requires going back to
patch 04 to realize.

>>>   static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>>>   {
>>> -    return -EOPNOTSUPP;
>>> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>> +    mmio_info_t info = { .is_write = false };
>>> +    unsigned long insn;
>>> +    unsigned int shift = 0, len, insn_len;
>>> +    bool is_unsigned = false;
>>> +    int rc;
>>> +
>>> +    if ( decode_trapped_insn(htinst, &insn, &insn_len) )
>>> +        return 0;
>>> +
>>> +    /* Decode length of MMIO and whether it is a sign- or zero-extending load */
>>> +    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
>>> +        len = 1;
>>> +    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
>>> +    {
>>> +        len = 1;
>>> +        is_unsigned = true;
>>> +    }
>>> +    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
>>> +        len = 2;
>>> +    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
>>> +    {
>>> +        len = 2;
>>> +        is_unsigned = true;
>>> +    }
>>> +    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
>>> +        len = 4;
>>
>> Already up to here this demonstrates a weakness of the INSN_MASK_*
>> set of #define-s (which I similarly observe in binutils, and I expect it
>> all has the same questionable origin). All INSN_MASK_L* and INSN_MASK_FL*
>> (also INSN_MASK_S* and INSN_MASK_FS*) are identical, allowing for a nice
>> switch() to be used here in principle. That said, with access width
>> nicely encoded in FUNCT3, it's not even clear whether a switch() would
>> end up being needed / efficient.
> 
> .......
> 
>>
>> Otoh none of these masks cover the pseudoinsns that htinst may supply.
> 
> As I answered above we should handle that before this function will call 
> so here we won't deal with htinst at all. Of course, if what I wrote 
> above is correct. I will double check before applying that.
> 
>>
>> Further, what about A-extension insns? Some (if not all) of them can
>> plausibly be used on MMIO, I think.
> 
> I’m not really sure that the A-extension is actively used for MMIO.

Does the spec preclude their use? I'm unaware of such a restriction.

> At 
> least, Linux doesn’t do that for now, which is why we don’t handle 
> A-extension instructions here.

Focusing on what present Linux needs is okay, but then remaining gaps
should (as said on various other occasions before) be clearly marked.

> I think this is related to the fact that MMIO is usually (if not 
> always?) naturally aligned, and naturally aligned loads and stores are 
> guaranteed by RISC-V to execute atomically.

How does this matter, when a bit or field in MMIO may serve the purpose
of e.g. a semaphore?

>>> +    {
>>> +        len = 4;
>>> +        is_unsigned = true;
>>> +    }
>>> +#endif
>>> +    else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW )
>>> +    {
>>> +        len = 4;
>>> +        insn = RVC_RS2S(insn) << SH_RD;
>>> +    }
>>> +    else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
>>> +              RV_X(insn, SH_RD, 5) )
>>> +        len = 4;
>>> +#ifndef CONFIG_RISCV_32
>>> +    else if ( (insn & INSN_MASK_LD) == INSN_MATCH_LD )
>>> +        len = 8;
>>> +    else if ( (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD )
>>> +    {
>>> +        len = 8;
>>> +        insn = RVC_RS2S(insn) << SH_RD;
>>> +    }
>>> +    else if ( (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
>>> +              RV_X(insn, SH_RD, 5) )
>>> +        len = 8;
>>> +#endif
>>> +    else
>>> +        return -EOPNOTSUPP;
>>
>> Because you don't permit F/D/Q for guests (yet), FL* and FS* aren't
>> covered, I expect? 
> 
> At the moment, I wrote this function with handling of MMIO instruction 
> in mind, which are at the moment ld and sd.
> 
> Even if to permit F/D/Q then do we really need to trap that 
> instructions? Hypervisor could allow access to FPU to guest and then it 
> will be just a question of context switch to properly save and restore FPU.

And how would you know FPU loads/stores aren't used against MMIO? Later
on, once V support is added, even its loads/stores might be used that way.
Think of video frame buffer accesses, for example.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 07:52:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 07:52:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396014.1634101 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxZ5-0000eu-7G; Thu, 20 Aug 2026 07:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396014.1634101; Thu, 20 Aug 2026 07:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxZ5-0000en-4i; Thu, 20 Aug 2026 07:51:55 +0000
Received: by outflank-mailman (input) for mailman id 1396014;
 Thu, 20 Aug 2026 07:51:54 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwxZ4-0000eh-IZ
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 07:51:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwxZ3-0088Xc-Uv
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:51:53 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86b20a-8faa-0a2a0a5109dd-0a2a4502a5ae-44
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:51:53 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86b219-6ca4-0a2a45020019-d1558030b063-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:51:53 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-499b02fc590so6701995e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 00:51:53 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499b20a14c6sm32137555e9.0.2026.08.20.00.51.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 00:51:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787212313; x=1787817113; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=PhBK6YnNsECh8KigWIjCiZjoLxt1fp8hP0W1MkIlNMA=;
        b=LGD49Ojb9wPgdoynv1LxMjddwRNNWqsq7dK5MkyGt9NlBYQLa7Rp/VnwjjF+P1IAfz
         Yw4Q/k1+119j6Kri8cYPy0i0DshUmxMD5ERn3IPfD1tEXsoTj338k0ytBrrqf/n3eTCs
         3H8DmXs/YVXdYWS2QU6eCp7Jg8jzrwNkBMQ4/rWoEBh1o/fbzbr/0uNVwQjnNl3C5yRt
         bAlPvo92kb78EOGk2HYIFDtZ09+YflLplu7dbPkKmcd7+H4gui9JcvQig2CjH4BDQ4lq
         FD+CJ6alnnyTA0QliJDp0utWoBBOFTB4VlYXBIdBLJvh6g7UZfn/M24XGxFwDB8jsXO8
         xC3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787212313; x=1787817113;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=PhBK6YnNsECh8KigWIjCiZjoLxt1fp8hP0W1MkIlNMA=;
        b=A5+P6Jc/+JB3np9o4DK1zORRs+wWc3/O3TrDCZcBLhoByK+U4wp3GGoDF6ADgc1xlA
         iXYLNAcc50x2vn7Z7LS9O6p4JblZ4drxalMgv80w33d2Avy6N9NJw/vTNmm/aGiKzSKT
         Kkuw8qmOGopzwYbAgrlFCpXQUX6GUrK53SmHNQmb76MW3ui4EjymeySsFzeu+r65Uqms
         OhPsVg70pGjvHraFr0zalT2bKS7AykP2nGxmWspcrd7bIGDFf3uw4IEfEdXHlFbXklqB
         q5/ioeFdcsVSi5IdV+s/xc0/xQiUDcrFIf7Sl5ZoYTLiSPeCh3Il2oyhk+8mcjdq3yXb
         VcRQ==
X-Forwarded-Encrypted: i=1; AHgh+RqqfKxGWGEuwVJEqCgx/B4icszIsOUcaFjnQ3rss69kg5wJRTTsZ3KrgVWwJX71a8Wcqr5F5yiYlco=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyiBRPKI8pNeeUB6BkNjAxaL34Z8UzoX2cNtRPFaX4G18fxZRp+
	9ndT54PGrwI9Ao0yId5PelMNGRueE7m2hSl6yFiL0yCnYS44su46OT636DQOIqovRg==
X-Gm-Gg: AR+sD10WgQjcVgU2569ZpRtQNWFnxIstmaNVrGNqRWD2y8+YJ8GrdlfVbgkMKormcji
	GNgMctHh7fyWY5UODdFjL6KWq+O+PPYkMeCFUms98JfUxFG4tozaTBYiE3MCGTYdXS2LR3dmNgN
	FMm0/DJLNOHAK6JNYe+zCv1T/8Ze6NV12sXMLfbNwdwYWLjK58yEinHSmVRN4+aoF5t2hc1H9ZF
	HHFNP9vBk1NW4jOhOvEOXGXCT5NJB9AFbqc8b3q5FQ2ibuPbiBBBOXAJN9kfQdU1BUy7LCkgBmv
	dEIx19vwuZHb9ZFixpWl7vi2NURB1M/3cc2v/1Rut6cG5JVKpSZRhrEN7Tr9Xc0NlRtUiuhR9Gj
	VWJ83zt/yIstNorPr+ejzanEQ43Zq6u2P/fgtuGCitO1bhNcrH6OKjawg5kgb7xbKAeqsaNnPXt
	dF1T0MN7IUBQur6y3Ck7OH39pkoDkKoVvGmHEeN/iqhzQQieiSM4NRx9dfOfNeZCs+AnJkrtpu+
	8rP4OXRHIfLBOTqhqx506nTQBls+0trTUSK0a39yqVqnvQHmuqw
X-Received: by 2002:a05:600c:a012:b0:499:593b:a15b with SMTP id 5b1f17b1804b1-499aa1431a5mr203011985e9.1.1787212313335;
        Thu, 20 Aug 2026 00:51:53 -0700 (PDT)
Message-ID: <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
Date: Thu, 20 Aug 2026 09:51:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <20260802050824.10554-1-brchuckz@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787212313-672B12AC-5EACF022/0/0
X-purgate-type: clean
X-purgate-size: 2208

On 19.08.2026 19:13, Chuck Zmudzinski wrote:
> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>> about avoiding the layering violation than anything else.
>>>
>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>
>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>> in hvmloader?
>>
>> As indicated before: If the OpRegion holds data that is needed to drive the
>> device, and if the OpRegion is exposed writable to guests, then guest can
>> screw up that data such that subsequent guests won't work anymore. Hence
>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>> restricted DM as well.
>>
>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>> it's not addressed by any of the BARs, yet it looks like it needs similar
>> treatment.
> 
> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
> it functions more or less like a BAR region with the devices's ASLS register
> at offset 0xfc in the PCI device config space of the device acting like the
> BAR for that region.

That is, on real hardware a write to that register moves the OpRegion? That
would need following by the DM then, i.e. the DM would need to indicate the
original position in the register, and the guest (incl hvmloader) would
then be free to relocate it.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 07:53:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 07:53:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396022.1634110 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxaS-0001Au-Jk; Thu, 20 Aug 2026 07:53:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396022.1634110; Thu, 20 Aug 2026 07:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxaS-0001An-Gz; Thu, 20 Aug 2026 07:53:20 +0000
Received: by outflank-mailman (input) for mailman id 1396022;
 Thu, 20 Aug 2026 07:53:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwxaR-0001Ah-KF
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 07:53:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwxaR-004yxH-0m
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:53:19 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86b267-8faa-0a2a0a5109dd-0a2a450b8ef8-12
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:53:19 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86b26e-b7e8-0a2a450b0019-d1558034d41d-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:53:18 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49954b88fffso19200775e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 00:53:18 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0fd7a9sm158734505e9.2.2026.08.20.00.53.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 00:53:18 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787212398; x=1787817198; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=dHzBX9KPRgMkIWd5I1Gbf+AhNbdoMSEIZNKs+X7J9rE=;
        b=c+YTCFPxDC+PZcS2iAMwzeYSLATAH1KU5Vneb3HFZv1w1n/8fz3rHhyrxSTsm4rEhF
         e8i4Cf3WbI82V7Stx437Q75mxIX8EYgvHStTUQ00kKX1R6IWz4ccry3bkEcVZWOoYJ1G
         UROPkY6nZYEOkxWf+1Q0SXZfZgI573W1mRWfHGXc94hMjHW933cptIZbKZcPEjXSwsnQ
         Aboaeht+rkVHi0i5Xhwyy5nkGPC68GL6JnTAfJ/bT+v0fqmYY9g1zIrMP0tFSSfKhi1t
         nl4EQoBEiQt58mOOXe5i/YhMj+S5BDG9cp6T8a8WyxOVLbG2nAPseqbt1MwLdUmBWdg+
         Hm4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787212398; x=1787817198;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=dHzBX9KPRgMkIWd5I1Gbf+AhNbdoMSEIZNKs+X7J9rE=;
        b=KtT3bkGly59FCSIdRFJ5XgFd68RTpM0DkSdsBuKHoIIwxL3cEMxYo6dV722gDtGM9B
         GPPTkEdQZx1WICzHej0SpPg1EWwpHFyCSKncN6Eqw36mK0XeRYPcvvcm4pLrqmJz3bdm
         y+uDXGOVuL2DuxUrw9K+PYDKVJAjj+eC0gGHRtGQzvA4sEGuqZ97meqDXtOQ1H+5PaVw
         KbmmvTZqjPcQnUVwgOgso+6kimJ/D1xuQzgGeB3hMRrWuxG6WXosOzxd/ILlU0P+TLDL
         KzS3h1mkqL4bLou0TKows+WlyGHy+BLAFa/+k5uP3i2/OlNqr31nMCkGylS9paOHA9EY
         k4VQ==
X-Forwarded-Encrypted: i=1; AHgh+RrABTg2F4QwkmDxSIzld5J2LB0BHXDl9oVt9F9B5PeG87FSEzg7ENk1pq79nmS1KThzwCPiAvj3NVs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx63hE7LPizG5N+gJ2FNSzOnstYChXWkg7+eWukIAfcelH2m1uv
	7NiqcNCp69Jl35Lb4CS+O2PTnGI3JOxhQmgB+AbgITGuDNIUsZVtTWsE/vUZ+pTK3Q==
X-Gm-Gg: AR+sD13jk2NVSa4PYeL0vWYQDemGreNMedjFY4uvnSK66NNwLNtPxM6bV7JMpttzYhv
	hH4AlQ9iG+NbrYzcEyI2BcgdmNk/zQdpViCu+1x1shGh76Tbmn92GPY9Gm2xWwMRvcppVLqqktX
	pKsph9g49JUJxBvEom5D/ct5r4M04R0a5CMtt+2htmdEKppptsQnCVlWlPhdKjUwXszCNv0NvMC
	7ob4UmDzFRyEa+0Bhwab0rMzkFiQF/7KhVP9fl0XYNWTMp8ag6VcmW7t9adLL9XDjqn5ZerahXP
	UOMaZkZiT1YgiAmmC9KQVkWkqqTorLH/k06eoRWFWrk9H1W2SlXm3hEBYgJG3vq0VRcLc1Szaxj
	WbRuVWRTm+m6x2Nf2SwPJa1j4XubgnPbXuPGbrWDfo4xEnMRzQdJaECv5DpUiPna1mdxZs/Te/r
	jVcWoGaEeWfmuHFw497Lo6Syq7PqzEyxolSBN6FH9pFezsUeUazsEhzafPv9Bmf0qVEVa4Ha2eH
	3MDgcy438zyxQZepV3o3ifaSAaLMiN7KDQY0eAImUZmwUN8ZuTG
X-Received: by 2002:a05:600c:c114:b0:499:ad2e:f7bc with SMTP id 5b1f17b1804b1-499ad2efd25mr150667025e9.10.1787212398437;
        Thu, 20 Aug 2026 00:53:18 -0700 (PDT)
Message-ID: <efd82852-484d-4b59-8d04-887533c13dea@suse.com>
Date: Thu, 20 Aug 2026 09:53:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
 <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787212398-A8ECE9EA-A1FCF03E/0/0
X-purgate-type: clean
X-purgate-size: 4316

On 19.08.2026 19:49, Chuck Zmudzinski wrote:
> On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>> about avoiding the layering violation than anything else.
>>>>
>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>
>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>> in hvmloader?
>>>
>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>> screw up that data such that subsequent guests won't work anymore. Hence
>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>> restricted DM as well.
>>>
>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>> treatment. Earlier on we also talked about the region not necessarily being
>>> page-aligned. That poses, even with r/o exposure, the question of other
>>> data on the same (leading / trailing) pages. This may imply that the
>>> copying needs to be done strictly in Dom0, for both DM and guest to only
>>> ever act on copies (which may then as well be r/w).
>>
>> Yes, I am thinking the DM should make a copy host OpRegion and never expose
>> the host OpRegion to the guest but only a copy of it.
>>
>> The reason we need a patch like this is that with the introduction of the
>> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
>> so its contents might be unsuitable in the guest address space, so in those cases
>> we need to patch the copy of the OpRegion that will be exposed to the guest.
>> If there is an extended VBT the DM will also get a copy of it, make a copy of
>> it, and expose it to the guest by appending it contiguous with the OpRegion.
>> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
>> then it can find the host VBT and make a copy of it without needing hvmloader
>> to send the rvda and rvds values to it.
>>
>> Then, the remaining question is which component (DM or hvmloader) will patch it
>> if it needs to be patched to make the guest's copy of it compatible with the guest
>> address space.
> 
> As I noted earlier, it think it would be advantageous for the Xen platform as whole
> for the patching to be done in hvmloader. That way, support for extended VBT is
> automatically added for all implementations of the DM, not just for Qemu. But the
> downside is that for hvmloader to do the patching, it needs to know the host OpRegion
> address, which one could argue it should not need to know. This is the only reason I
> can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
> avoid disclosing the host OpRegion address to the guest.
> 
> But we trust hvmloader, don't we, to not abuse this knowledge of the host's OpRegion
> address?

No, we cannot (fully) trust hvmloader.

Jan

> The point is, hvmloader will discard the host OpRegion address and not
> disclose it to guest firmware (ovmf/seabios) nor to the bootloader or guest OS, so
> I think the advantage of adding support for extended VBT to all DMs that rely on
> hvmloader outweighs the risk of disclosing the host OpRegion to the guest (hvmloader,
> which, for security reasons, should not disclose it to ovmf or seabios).
> 
> Chuck



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 07:58:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 07:58:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396031.1634119 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxfd-0001qD-6c; Thu, 20 Aug 2026 07:58:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396031.1634119; Thu, 20 Aug 2026 07:58:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwxfd-0001q6-3k; Thu, 20 Aug 2026 07:58:41 +0000
Received: by outflank-mailman (input) for mailman id 1396031;
 Thu, 20 Aug 2026 07:58:40 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwxfc-0001q0-7D
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 07:58:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwxfb-00396n-KA
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:58:39 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86b3a9-bab6-0a2a0a5309dd-0a2a45048950-18
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:58:39 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86b3af-b57f-0a2a45040019-d155802ef19c-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 09:58:39 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so21201275e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 00:58:39 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499b20bb2b4sm27973115e9.0.2026.08.20.00.58.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 00:58:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787212719; x=1787817519; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=DvxJIX5REEgAjoaQUfIh/9VLwd5fuvQExru6eU7BFJo=;
        b=RjSywlCr5xySh1ET36iXt+toyJRHTuSFcH5c25tgWB6/DcLyuXhVaFrq7rLXqWGZks
         SwwvVOcIEXa1Sn+T1wfuIgHD/KXHUe2rbR/jYsKMGeunGVQbNe6yz8MV32mwdgYBxYcC
         VFGKunHGlscOawYHQPPHYvxqRxgCW0GshDhSMn+lha7K+Fb01PnLmKUpYLvsjhhcgT6I
         Hb+z4hMtAYgO69bst2hAbFA81K778cRZ+yTQve96ZiJ6blhO85qElMR7JW+M/ofWmJYM
         CxcXR8hPBkh+gB7deM4GPIQswL0YqnuUjvYnmuNddHls3vqsK+SSN5gGVxlkWTLGr3Xr
         jXYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787212719; x=1787817519;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=DvxJIX5REEgAjoaQUfIh/9VLwd5fuvQExru6eU7BFJo=;
        b=T2EqH7cGg6sdZYsfXsc7f7HUGEyVhCJ29bw12x48T93ORrO3si3CF4aCA7M3FODZL0
         UQVBNik8Aq9JdVbv2A9Obc4vUay8Tyz7DgySRe/BDNP+WE4gyGAiXVpXky1sLhjrgqcq
         px2W/7tD+4SSIYIMMB6iI8z3TBBIGbd9Jrk6Zvxk/zWHokjYendRbwUxYTd4MBh/5Rb5
         zVTO2McNGMCIQCND9hgyvs7wwMO+NvYaaP07Fln1JwN9Kwe5eNd4VYN3rRNYZzg40RHT
         MJ6Q6zBwytCVdkz/0J6xNk/Nr54esKwlZ4WYmgJQ3uiv9HLjyOst5yUOw8xLFwRCKV7j
         ZN3Q==
X-Forwarded-Encrypted: i=1; AHgh+Rrg41FvezCVbHgjU+oZlRWBtL2fK7cmCxWpqp5sGwrymlnafb1wOG1z+Snj5Set9AHVHVginbRiryQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw7b64eTl3PbkwZa3tWxoLvRfNcDn8PnQVS09iMgpgPpQe+Udhx
	QltCSjOcRO0UNyVJ87gb7snbgRuwNYXdXDs1CJ0PkUvZjSeGfzPkvVQyk+ps9d2Veg==
X-Gm-Gg: AR+sD131jOtp/AQjmCZ7jIrjDJKY272Vm/7VyqubwyzZQS/16uc5+LJXrDrt8Nf6QZh
	YJ56v0nTujl2HzZwdg6upbJimuzGP4fTa3jHlwjOGR4KuP5WGoCv1TS2BiSL4p0KOG89BpN+txK
	bsVuFS+MDSd6On2b4xZ/GE+Z8wZEmV8k8TpKCkDYQUulTpaJBo4AlbXLGtS/269P6JNHF9GWr3I
	U/nzgpAic8jClY33h9gVQUTuNulMyaFAzE0TjQfHjSIOvOvCneI1DkHXuZFAouXX1b1O5Ki0z37
	WBiXziABRHkb8V7jwerXHzVgkkLoQPYGP5y7Eo+xRzWqkPrHu0tn2pVyXu1NfDjaJjlET+sJ6Th
	1PaDe2DQSmj/V41DOqV2y1WeZaY+PpNtZRVSuJRnYXMC3vvQLp3ouk3p2vg8uXRijPeJ9a0Xmcb
	rd8UpisnA2YsP2y4UMxDHElSTwMeLBVLOz+wphdVsIWv0XUBmjVhN1sOrAhOIOljOsX7PrqjHcI
	NsXi1kaYexARhRavksfb2q1Lun/GgYqOF+eC2YGaRhXUNFCraCw
X-Received: by 2002:a05:600c:468c:b0:499:48bb:417e with SMTP id 5b1f17b1804b1-499aa14a72dmr160304885e9.2.1787212718889;
        Thu, 20 Aug 2026 00:58:38 -0700 (PDT)
Message-ID: <b05a3553-398d-4ed0-bbf1-6e93cf385fe2@suse.com>
Date: Thu, 20 Aug 2026 09:58:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
 <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
 <f0ffe015-1bc5-4091-8dbe-2b4eee9cec2d@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <f0ffe015-1bc5-4091-8dbe-2b4eee9cec2d@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787212719-C1AD0B50-22B320E3/0/0
X-purgate-type: clean
X-purgate-size: 5133

On 19.08.2026 21:09, Chuck Zmudzinski wrote:
> On 8/19/2026 1:49 PM, Chuck Zmudzinski wrote:
>> On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>> about avoiding the layering violation than anything else.
>>>>>
>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>
>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>> in hvmloader?
>>>>
>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>> restricted DM as well.
>>>>
>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>> treatment. Earlier on we also talked about the region not necessarily being
>>>> page-aligned. That poses, even with r/o exposure, the question of other
>>>> data on the same (leading / trailing) pages. This may imply that the
>>>> copying needs to be done strictly in Dom0, for both DM and guest to only
>>>> ever act on copies (which may then as well be r/w).
>>>
>>> Yes, I am thinking the DM should make a copy host OpRegion and never expose
>>> the host OpRegion to the guest but only a copy of it.
>>>
>>> The reason we need a patch like this is that with the introduction of the
>>> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
>>> so its contents might be unsuitable in the guest address space, so in those cases
>>> we need to patch the copy of the OpRegion that will be exposed to the guest.
>>> If there is an extended VBT the DM will also get a copy of it, make a copy of
>>> it, and expose it to the guest by appending it contiguous with the OpRegion.
>>> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
>>> then it can find the host VBT and make a copy of it without needing hvmloader
>>> to send the rvda and rvds values to it.
>>>
>>> Then, the remaining question is which component (DM or hvmloader) will patch it
>>> if it needs to be patched to make the guest's copy of it compatible with the guest
>>> address space.
>>
>> As I noted earlier, it think it would be advantageous for the Xen platform as whole
>> for the patching to be done in hvmloader. That way, support for extended VBT is
>> automatically added for all implementations of the DM, not just for Qemu. But the
>> downside is that for hvmloader to do the patching, it needs to know the host OpRegion
>> address, which one could argue it should not need to know. This is the only reason I
>> can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
>> avoid disclosing the host OpRegion address to the guest.
> 
> Correction: Actually, with this new scenario, we need not disclose any confidential
> host addresses to hvmloader if the DM removes such information from the copy of
> the OpRegion that it exposes to hvmloader. Then, all hvmloader needs to know to
> ensure the OpRegion is compatible with the guest's address space is the guest
> address of the OpRegion. It need not know either the host OpRegion address or the
> host VBT address.
> 
> So the guidance I need from you to do v3 of the patch is simply to answer these
> two questions.
> 
> 1. Should I write v3 of the patch not only assuming the DM will never expose the
> host OpRegion to hvmloader, but also assuming that the DM is responsible for
> patching the OpRegion to ensure it is compatible with guest address space?
> 
> Or
> 
> 2. Should I write v3 of the patch assuming that hvmloader is responsible for
> patching the OpRegion so it is compatible with the guest address space?

My tentative response is to use option 1, not the least because a mid to long term
plan is to see about removing hvmloader altogether. However, a more firm response
here depends on an answer to the question raised in
<92022f85-9a53-4db8-b489-fc91c86b413c@suse.com> (sorry, the list archive hasn't
caught up yet).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 08:45:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 08:45:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396101.1634150 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyOy-0000YW-08; Thu, 20 Aug 2026 08:45:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396101.1634150; Thu, 20 Aug 2026 08:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyOx-0000YP-To; Thu, 20 Aug 2026 08:45:31 +0000
Received: by outflank-mailman (input) for mailman id 1396101;
 Thu, 20 Aug 2026 08:45:31 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwyOx-0000YJ-Ar
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 08:45:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwyOw-00EZLK-Ns
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:45:30 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86be9a-2eae-0a2a0a5409dd-0a2a450bbafa-38
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:45:30 +0200
Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86beaa-b7e8-0a2a450b0019-d1558035cd84-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:45:30 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-498028b3d5eso23183585e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 01:45:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499b20bdd75sm34417005e9.2.2026.08.20.01.45.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 01:45:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787215530; x=1787820330; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=YHeYPbMObjCR9jPMiWb1yyIm56nHv7GC519kQ3/d948=;
        b=MgUDWB/6QiVfwQM4Kx7SxNu43JGe34I9pgouacCCvzh8K40CtUGW2fRO+IK9K+tkOm
         +Ze45Q9j1wUAOhKwJhCKPqpB1R3vAZl7puIb4A8cGl14YrYYOl3+Bx//UvjV47YQptVy
         00gyFoFKm7XduunYRXyt4YKICpB713HOebUYnomQGtCeotETjROykoCgOnYa49D/goyF
         shUnYA8gVOuOGFfLuNagsxo/VRYEv6PDDfLBmvNVP3feHB2yTX3hTSm3F35mz3CFPkp2
         odoAjfRJZiKMvgJ7pxpPXnDWyzZ5E0IjGGYZTh6KZqn69CAivLQzL8L86j+rkocChu0e
         to6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787215530; x=1787820330;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=YHeYPbMObjCR9jPMiWb1yyIm56nHv7GC519kQ3/d948=;
        b=UqE3if0yWFBIwvtYWzR/Ix/8BcorRuzMIiO1WpNEaJ5wnJOixUlFLyze5C84mVE+u2
         Z4jjqgwEoaKYa4WZacFVR/Ht1O6uNLWuZScth4q70QWl4jZvzME74CHk9GcCcykgUlaZ
         ohuojbTrTUDb6ccIQ88pgzUAoq2w/NTAoQ2kuHNUwLs+Zf+LA0eT4j47Aj6YKyWIiqYe
         pL2rwYrl+zI2eIaEdiEEPe5HrJprBIUE3lxB+zju1NjIYoq6tH1wVKBWBrpceUn8vjD5
         Zae2ZPa66X+W68ok6ZL0BM1go93kMQNRAn3o87BKwgc6Gu23E9DVt2Q9Z6lcIf8mv3rH
         nKwg==
X-Forwarded-Encrypted: i=1; AHgh+Rqhj2PsGHhdeGagbM/o4bBZ5g7EefsbXlCEKD1OQkkIn0yeVuPLkJaxeXwshFxnx2h82sbUvGj+DL8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwDmv//cKxGrPZzRl24BoMr40QR74E5xEZM9enq26HVX+QLJVo7
	B4cpNVc8H3gDay2FAenab6uG2W2As5g+x8gzdbrY+9hEB6IYCztZI0M4ZJnAUJOaDA==
X-Gm-Gg: AR+sD134HxEXnRVWUi7XLfh3kSA5YVtwCgKgzLb+k/IWEV4zc9Bzp6tOCySEQefWoGm
	gYf/h5ImAFmReYh9wFar6Fj2IwApbKgTcx61JG8OuaZCrsJz4/m2FFKRtCq8E2juJELZEET7whG
	HRelOUjHhSyfrvvPQBTilROEZTa5gQPfn0Bv/lEs623mliWfDctHDG5sZ2BK+qitkM5H5oD5Qi7
	JkP/SraY7/Nr7nkr27BeMdpbTZoJEAHcWo1XLqrMydeD/TP1d+hnW/uUYVu5S+1P0N8mdSCS/Vp
	aqSdBslDAJobJCn1q/RsfUCOOTpzLm40IunynevAahCvKnOk8YqlL7dBM5L6cXrTL4m7pinCSmy
	AYia+eelJkyMFHr1VfQVGBQk3gSpKxwfUlXfYNFUHok4atOssEmAQbVDOu2wl2AnK0VbdwPc7tG
	ZnyFXS5sEmpAUwikm/DOfbUVv8gD0e9IR9IXI9Bh/jFfydv6/uEc/1BcIymK85jTpVblCUzGn6P
	m3DKqS+JFozbYwTuJamtj9wHSsP/BsJ/bmt5f2/EiuF0SEQi/1m
X-Received: by 2002:a05:600c:a012:b0:499:52dd:c1f0 with SMTP id 5b1f17b1804b1-499aa180132mr216018195e9.1.1787215529950;
        Thu, 20 Aug 2026 01:45:29 -0700 (PDT)
Message-ID: <aee239df-0582-4973-82ae-65688a7d6b9a@suse.com>
Date: Thu, 20 Aug 2026 10:45:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when
 XSAVE is absent
To: Andrew Mbugua <andrewprecious388@gmail.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech,
 anthony.perard@vates.tech, xen-devel@lists.xenproject.org
References: <20260819180735.135911-1-andrewprecious388@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260819180735.135911-1-andrewprecious388@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787215530-AB6D29EA-36A04AE0/0/0
X-purgate-type: clean
X-purgate-size: 2605

On 19.08.2026 20:07, Andrew Mbugua wrote:
> While running the x86_instruction_emulator fuzzer via AFL, I encountered an assertion failure in the emul_test_read_xcr() function.

Thanks for the report.

> The fuzzer is able to generate a CPU state where cpu_has_xsave is false.

I'm having trouble here: cpu_policy isn't populated from fuzzing input, and

/* Intentionally checking OSXSAVE here. */
#define cpu_has_xsave     (cpu_policy.basic.raw[1].c & (1u << 27))

would mean that upon filling cpu_policy (emul_test_init() ->
x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
suggesting you did the fuzzing on some really old hardware?

> If the fuzzer then generates & feeds an instruction containing AVX,the emulator
> attempts to fetch the FPU state via x86emul_get_fpu(), which then calls emul_test_read_xcr() and hits the ASSERT(cpu_has_xsave). This assertion crashes the fuzzer.
> 
> The crash:
> 1. $ ./afl-harness < findings_dir/master01/...
>    afl-harness: ../../tests/x86_emulator/x86-emulate.c:179: emul_test_read_xcr: Assertion `cpu_has_xsave' failed.
>    Aborted
> 
> 2. The stacktrace:
> (gdb) bt
> data_p=data_p@entry=0x55555604f320 <input> "\244\264\336\346\337\001\254%\247R\216d\204*\234\377\377\224λ\3237/\365ʿX\266?\353\036\227/\0323\351dj\257\v\207\031V֖\235{\036\225|:M\330\336 \314V:&\357\306@\224\331,\301\300\372FW\262.\020\\\276\244\203\242\276\262\022!\337)F&\261\2064\200\200\377I;J\376X41\2061\206\325 \021\017F\026\267\275\340\361\357)\255\343\237n\377\374n\357#ֽ\226\365d",
> size=size@entry=580) at fuzz-emul.c:934

This can't be the complete stack trace.

> Possible fixes:
> To prevent the fuzzer from getting stuck on this state,would it be better for emul_test_read_xcr to return X86EMUL_UNHANDLEABLE (or something similar) instead of ASSERT(cpu_has_xsave) ?

No, I think the assertion is legitimate there. After sending this reply, I'll
post two patches taken off of the (unposted) APX series I have pending, which
I think get things into better shape (and which, with the minor editing I had
to do to pull them out of that series, should be fine to move ahead). On top
of that we then will want to add some sanitization of input state in the
fuzzing harness: CR4.OSXSAVE set and CPUID.XSAVE clear are clearly
contradictory. There are other impossible combinations, and I think we may
want to address some of them at the same time, and we already have
sanitize_input() there. Please let us know whether you'd be willing /
interested to make changes there, or whether we (perhaps I) should.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 08:50:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 08:50:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396117.1634160 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyTt-00029J-KH; Thu, 20 Aug 2026 08:50:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396117.1634160; Thu, 20 Aug 2026 08:50:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyTt-00029C-HN; Thu, 20 Aug 2026 08:50:37 +0000
Received: by outflank-mailman (input) for mailman id 1396117;
 Thu, 20 Aug 2026 08:50:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwyTs-000296-Bh
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 08:50:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwyTr-001PHQ-DD
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:50:35 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86bfd6-bab6-0a2a0a5309dd-0a2a4509966c-24
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:50:35 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86bfdb-be1a-0a2a45090019-d155dd29b989-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:50:35 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47f84023916so1880121f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 01:50:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14c45f1sm11548299f8f.31.2026.08.20.01.50.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 01:50:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787215835; x=1787820635; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=oWC0qrg1/ryjfHCPvG8g/18CQ7An+WEUhSShGNRO3z8=;
        b=P/oOmHFxWygc/TQ3/OvuJ30kJKtr83pIpj8q6teir69fPyNj03zTqxPH4MlbOc6hxr
         6Kwb0jGG87fPOBwUwDtpF/R4Z9wZ1LEuUI+66DXeMfNcFJuc4vdRvYlfF0ydNnN/EiTb
         2yBw1Cjw9ywYHFiQ+iwZkwLCtdwEFKZJkS4d8PyUvcB/uMFNGGRzkKfSyR8non524mGQ
         FSpkk/dOf1rw91RnBPFapnygSguUdBde92VLOAI/YgAgXVzJh8RVsmz4N/usfnojOcV0
         m9xczbmnGshHZCnWukp6EyU8QM7CPm/K+a+6HKrSh1YwcxyDpFBx1Ltz1T+M4CYrxlT/
         b3Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787215835; x=1787820635;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=oWC0qrg1/ryjfHCPvG8g/18CQ7An+WEUhSShGNRO3z8=;
        b=VPnlXY4wCnobOGL0PJzBFaLXpKkZ8VuwQjngNZV2bX+qhIytZvUlkCpIc7Dg7UfeR4
         vBS3ufnP3oMstyggxHYVdtzeHoC1iilD3XkAwUhN1wHFhyskCop4uyjXbslKY0VMMkhm
         bCiwokps3oIdcWMT/tj435ohHYUj1/QFhYQF1HefKdTpg0ZF7KOW70N07qtpQFssrY+X
         qetp9obcGpaGKx0t6S28MDyj1UlLniqb9TesKI18L3i12fqgQ21/XgHAvADE+kAxbFzf
         lqUtJnOgdyyLR2mFYWNWnL7EyL3lRtx8AtqKlDjLHJtGZjiYrawCG5Y1mNSxi7a4Sb8F
         SmVA==
X-Gm-Message-State: AFuF++kwJJN35mhlYWiorAgg6ILuwreaYoMV2z1OoqfSnLCRfc/YdfiR
	uxdmsr+2DVG66OjNIMa8CkaORVE8+OPAY3njmCJffUYPpN/9k47UeMTkX+8VcOCtDZD7p3l6VIG
	b+M6mkQ==
X-Gm-Gg: AR+sD12Etjg+lBpoSwYAi3VQ+3zgKKmdoWYaawpeYrwsDKicR5vwgqLpW78H55mryff
	3jZQ1F9pgit+jSqXilc2ovDqLhRVHKLnV19st1bTRL82UEuTPK1azfEbe+hqA9x0ZSALQkcTaDA
	pZQQXj2R92svq1/JiUoBJkG0t80vkMIQGuHRwOvQs4i5I5QQDvl73nJQPw0nCCRfSdAu+VKLlh6
	qFYZrbEpdZ1PozbC0hXXnAI51Polq+zogHZOmZogNo505CfIviXDWuYdZfEjYxhfdMgK1tBTflt
	erNhzlCyHlIezeM4RY0xkG5gsi0UoJmosY15rxH8wxUHdvALpuywtEJWbDNKoTrV73ZbstBPNRo
	2cchK0R0gC3d6m85PVFY1L6cxuAR0o3eE2TaLj7hGTOph3lCTB0XG3e5Rwl9SJYmXLJRyF1xacs
	EkQWmKzXlkG2SMYJlFByVKvWGX3p+7Cm8r76ZplnqrU1i+iUixkNSl8Bv6FaaU65NTvX8RuR3DY
	Rp+cJ3NT93mm7fF3U6L0RtDsFC+zXj1EH+rxKqK+n8i0l+5sxgOrI4GoWGjYCk=
X-Received: by 2002:a05:6000:1846:b0:47f:7129:6e2d with SMTP id ffacd0b85a97d-482b1fe83d6mr19691556f8f.17.1787215834513;
        Thu, 20 Aug 2026 01:50:34 -0700 (PDT)
Message-ID: <0c3cb1ae-4888-4319-a348-263f7913a7f2@suse.com>
Date: Thu, 20 Aug 2026 10:50:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Andrew Mbugua <andrewprecious388@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 0/2] x86emul: XCR0 handling
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787215835-BD2CC034-FBCCACCE/0/0
X-purgate-type: clean
X-purgate-size: 428

Prompted by Andrew's report [1] I thought it may help if we accelerated two
of the patches I have pending as part of the (so far unposted) APX series.
We previously discussed latching some control register state once early, so
let's start with doing so for XCR0.

[1] https://lists.xen.org/archives/html/xen-devel/2026-08/msg01006.html

1: latch XCR0 early during decode
2: use latched XCR0 in x86emul_get_fpu()

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 08:52:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 08:52:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396127.1634168 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyVQ-0002cp-Vu; Thu, 20 Aug 2026 08:52:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396127.1634168; Thu, 20 Aug 2026 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyVQ-0002ci-Sy; Thu, 20 Aug 2026 08:52:12 +0000
Received: by outflank-mailman (input) for mailman id 1396127;
 Thu, 20 Aug 2026 08:52:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwyVP-0002cc-W8
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 08:52:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwyVP-003Jmg-Ck
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:52:11 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86c033-bab6-0a2a0a5309dd-0a2a4509c90c-26
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:52:11 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86c03a-be1a-0a2a45090019-d1558031a853-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:52:10 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-4980fe6b3beso5751595e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 01:52:10 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa17f202sm120697425e9.13.2026.08.20.01.52.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 01:52:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787215930; x=1787820730; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=IJcAOFJxYzUkoLBuDV15vBU/KPsTSNpfBgAh1I6vk/o=;
        b=RBX8vYbs6cClwkQ+KFLW0Cg3GC4ugayJkKVh/F+Otr+sV2yxxX2Yko/E2eQQXRl9k+
         wVng6bv50iT6RFQSsm/dU58bwbYsB67K87432e09+Le0/Lgs3KxIZK72K3UKRwoZjNcX
         beYyWIyViekQE9A0EbC+wVV/mVvDWxMZ1f0ayCsaBK6FhpysysrchFVGLnGqKGURwjqK
         6ka2DOQsS97UyVfAJZ71Eq+9rwWoPUbhXWF8gryt1FjleuQ2XGNbRx0XrW9sGPM9BmRB
         joxCqDy4wVhgOMuT2v/FeZEitHr/GSXlFaUalhcahdy4f8WR7sYtCgUf17+zh47xyxVj
         sKxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787215930; x=1787820730;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=IJcAOFJxYzUkoLBuDV15vBU/KPsTSNpfBgAh1I6vk/o=;
        b=pG6P7pWZHaj117JLHCUG/LUHnrGy+rWgElyoVsIkFihK3cg0HBDpwSkgF6HyOVSr95
         wh7sA84MfSw0RDs/ldgCooeKvaVf3pnrYKjt23h+A8KATEay9E45w7adzJqHAXtB/QX4
         AMG3zntfFL2T2n8XwQHwe/jpWOVfOgMFgaIxSKn47tjtoZN7HbA33b7vk09TJo9ITG3P
         rhvUrV9hW8zeq4YbieDHUPJV8Q8Tr2TgvRUJySOZBtmQWsMyetHuVuT0Ip/clQOUl8Ui
         g9XPEcrdF3nBaWfhx6d5WbpBnqJO96IQmvN4MibODTduTJTRT5qvh+aiaAa7aZprvJdR
         ZVDA==
X-Gm-Message-State: AOJu0YyaZ/6+xHhqrS1qtbbRSxf3ToADPfMvitmn8Js3v6MX9vkKVgoo
	6JjT/8f/iP6R9/NHNWekEmTlwB2/z4/kYGhxGtV2pFgyxbFfC3KaOFMtlYcg0G03YJaCqLpbvjr
	PrUUpkg==
X-Gm-Gg: AR+sD13HOp1TBB3sQjp9qmpeeLK1Z0aeRl3mmN7xmYZN6KN6/0tJkW+DPmrqOL0HLjg
	MSfra/HXqj73R17YfRgJbPPzA7eg4LNhXfH9MSk66o3wxNGc2NmnKYqzkFjEdyghfaco2Y/M8Mw
	08X7JzIYIf2eDLPHFeiEZaxnLEhdpph7WsClHJEmrY9Vjc0wkkmG1QLr1zTBaDctduhjLH8oRKV
	sKpNKl7xGwR4ZuE24B285u4EV11pI8C64cLJXwAAM6g7YW+le7xtv0MgVu1NCgLn6EmaucfBckX
	7gF+cXgjIOQbxomkUaplx1Yits2nlNx7Pcu032cjeHmIJSNePiAAXl1njIQX3sMRAMd98r2VBnW
	O70clMLj/SWiZfTQHCOMF+wQMKBqZoTqf/hBdyxwoYwRtAHf19dDO1ISnq19lnpRfICpwjQ5bsQ
	6C6RDSnIHxUfO6p29UNPribqmIEV+bVBLXtIAOd19mTSB/mgW7kANdUpetG250f4+T4cbHwlN3l
	mynKZ+WiksgzKgK/3NVnN3l6jc/YAnuHIiZPKTkYVt5ZqUnmMAt
X-Received: by 2002:a05:600c:a11:b0:499:a0a5:e13f with SMTP id 5b1f17b1804b1-499b06a5952mr44471485e9.2.1787215930340;
        Thu, 20 Aug 2026 01:52:10 -0700 (PDT)
Message-ID: <04b55ed1-1103-483f-9bca-72b8955f6cdf@suse.com>
Date: Thu, 20 Aug 2026 10:52:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 1/2] x86emul: latch XCR0 early during decode
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Andrew Mbugua <andrewprecious388@gmail.com>
References: <0c3cb1ae-4888-4319-a348-263f7913a7f2@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <0c3cb1ae-4888-4319-a348-263f7913a7f2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787215930-BCCCF034-2A0849DB/0/0
X-purgate-type: clean
X-purgate-size: 4680

We'll need to consult it to decide whether to treat 0xD5 as a REX2
prefix, and whether to recognize extended EVEX encodings.

Utilize this in adjust_bnd() right away, but leave leveraging in
x86emul_get_fpu() for a separate change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
While not directly relevant in this series, should we perhaps latch CR4
into the state structure as well right away, since we need to read it
here anyway?

--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -1036,6 +1036,24 @@ int x86emul_decode(struct x86_emulate_st
 #endif
     }
 
+    /* Latch XCR0, if available. */
+    if ( ops->read_cr && ops->read_xcr )
+    {
+        unsigned long cr4;
+
+        rc = ops->read_cr(4, &cr4, ctxt);
+        if ( rc == X86EMUL_OKAY && (cr4 & X86_CR4_OSXSAVE) &&
+             ops->read_xcr(0, &s->xcr0, ctxt) != X86EMUL_OKAY )
+            s->xcr0 = 0;
+
+        /*
+         * To ease consuming, strip 64-bit-only state right away for non-64-bit
+         * environments.
+         */
+        if ( !mode_64bit() )
+            s->xcr0 &= ~(X86_XCR0_TILE_CFG | X86_XCR0_TILE_DATA);
+    }
+
     /* Prefix bytes. */
     for ( ; ; )
     {
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -334,6 +334,8 @@ struct x86_emulate_state {
 
     unsigned long ip;
 
+    uint64_t xcr0;
+
     struct stub_exn *stub_exn;
 
 #ifndef NDEBUG
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1234,17 +1234,17 @@ static bool is_branch_step(struct x86_em
     return debugctl & IA32_DEBUGCTLMSR_BTF;
 }
 
-static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
+static void adjust_bnd(const struct x86_emulate_state *s,
+                       struct x86_emulate_ctxt *ctxt,
                        const struct x86_emulate_ops *ops, enum vex_pfx pfx)
 {
-    uint64_t xcr0, bndcfg;
+    uint64_t bndcfg;
     int rc;
 
     if ( pfx == vex_f2 || !cpu_has_mpx || !vcpu_has_mpx() )
         return;
 
-    if ( !ops->read_xcr || ops->read_xcr(0, &xcr0, ctxt) != X86EMUL_OKAY ||
-         !(xcr0 & X86_XCR0_BNDREGS) || !(xcr0 & X86_XCR0_BNDCSR) )
+    if ( !(s->xcr0 & X86_XCR0_BNDREGS) || !(s->xcr0 & X86_XCR0_BNDCSR) )
     {
         ASSERT(!ctxt->event_pending);
         return;
@@ -1952,7 +1952,7 @@ x86_emulate(
     case 0x70 ... 0x7f: /* jcc (short) */
         if ( test_cc(b, _regs.eflags) )
             jmp_rel((int32_t)src.val);
-        adjust_bnd(ctxt, ops, vex.pfx);
+        adjust_bnd(state, ctxt, ops, vex.pfx);
         break;
 
     case 0x80: case 0x81: case 0x82: case 0x83: /* Grp1 */
@@ -2363,7 +2363,7 @@ x86_emulate(
              (rc = ops->insn_fetch(dst.val, NULL, 0, ctxt)) )
             goto done;
         _regs.r(ip) = dst.val;
-        adjust_bnd(ctxt, ops, vex.pfx);
+        adjust_bnd(state, ctxt, ops, vex.pfx);
         break;
 
     case 0xc4: /* les */
@@ -2594,7 +2594,7 @@ x86_emulate(
         op_bytes = ((op_bytes == 4) && mode_64bit()) ? 8 : op_bytes;
         src.val = _regs.r(ip);
         jmp_rel(rel);
-        adjust_bnd(ctxt, ops, vex.pfx);
+        adjust_bnd(state, ctxt, ops, vex.pfx);
         goto push;
     }
 
@@ -2602,7 +2602,7 @@ x86_emulate(
     case 0xeb: /* jmp (short) */
         jmp_rel((int32_t)src.val);
         if ( !(b & 2) )
-            adjust_bnd(ctxt, ops, vex.pfx);
+            adjust_bnd(state, ctxt, ops, vex.pfx);
         break;
 
     case 0xea: /* jmp (far, absolute) */
@@ -2885,14 +2885,14 @@ x86_emulate(
                 goto done;
             _regs.r(ip) = src.val;
             src.val = dst.val;
-            adjust_bnd(ctxt, ops, vex.pfx);
+            adjust_bnd(state, ctxt, ops, vex.pfx);
             goto push;
         case 4: /* jmp (near) */
             if ( (rc = ops->insn_fetch(src.val, NULL, 0, ctxt)) )
                 goto done;
             _regs.r(ip) = src.val;
             dst.type = OP_NONE;
-            adjust_bnd(ctxt, ops, vex.pfx);
+            adjust_bnd(state, ctxt, ops, vex.pfx);
             break;
         case 3: /* call (far, absolute indirect) */
         case 5: /* jmp (far, absolute indirect) */
@@ -4981,7 +4981,7 @@ x86_emulate(
     case X86EMUL_OPC(0x0f, 0x80) ... X86EMUL_OPC(0x0f, 0x8f): /* jcc (near) */
         if ( test_cc(b, _regs.eflags) )
             jmp_rel((int32_t)src.val);
-        adjust_bnd(ctxt, ops, vex.pfx);
+        adjust_bnd(state, ctxt, ops, vex.pfx);
         break;
 
     case X86EMUL_OPC(0x0f, 0x90) ... X86EMUL_OPC(0x0f, 0x9f): /* setcc */



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 08:52:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 08:52:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396129.1634179 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyVn-0002zX-7J; Thu, 20 Aug 2026 08:52:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396129.1634179; Thu, 20 Aug 2026 08:52:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyVn-0002zP-3G; Thu, 20 Aug 2026 08:52:35 +0000
Received: by outflank-mailman (input) for mailman id 1396129;
 Thu, 20 Aug 2026 08:52:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwyVl-0002xm-DB
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 08:52:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwyVk-00Cfd1-Pu
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:52:32 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86c044-bab6-0a2a0a5309dd-0a2a4504e022-28
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:52:32 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86c050-b57f-0a2a45040019-d1558036f030-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:52:32 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so21152035e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 01:52:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b14c45f1sm11559893f8f.31.2026.08.20.01.52.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 01:52:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787215952; x=1787820752; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=ZPnDSCBKcp/+Hix8hZK5uWZ7zXCAvzvq1TTnQ1h7pDo=;
        b=O+UKfh5Sr+eYVUsBTgx6WKz8X8+/zgL3fkOqh4C3gYVaAg5eAHaYuNW5/X+U3S0vnJ
         UP2zKMoTkL3TTk30j4y8ggl6ZcNkVzVNTa19qGclwf9A3kS/15Hps8IRDaFBiUtty27r
         zrzA51wOY+V0FTDBLHa8zmYzfhzH3q6c4rjkI8Q+5QVjbMEmoCR5L42vwybo0/GtVCQl
         2SXDrOwrtP+QoJCUTdZ8s+F+V4EhZSd8shVburN0UV/8wcXYCDiH/jiG4oxIWyvnp8zp
         ErHb1NrqrdB0F0y6Mr7iMw4JWtqLxxsL8lHfojHahmmoU/xu9wmdd1KLPzKy/Rg5otWf
         UW7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787215952; x=1787820752;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=ZPnDSCBKcp/+Hix8hZK5uWZ7zXCAvzvq1TTnQ1h7pDo=;
        b=dABWsTRTLIT+qCqjXYLI9iZc51fMtxGvyBsB44qqP9VALuq5R+fwxJLSFw36tgclQS
         /MOrAc0p9rzrN5fYQc96w1wxCgY+7OT5gteH6PVlaiKeSTmagmjfcPCaNALPEYGZfk+a
         VxmCrXZRk6xIhJBXYTe8G+SX9o1Rjk0F8vQDah7+c4cLutiWyKPlId17LsScllzrZIMi
         ptLuIQTJcBqOWn53kX3aQNdnQn2rsySrWwjpwLIwgli2dxspgmzWSXZd1Ft9YPP6zdrv
         TJTt+LcY65NqyRxcQUQmJNbmcFskL3cW693Uu1AWmm4bmYWi4v0WtTAcZuI7oFm+26IP
         dEQA==
X-Gm-Message-State: AOJu0YxpOWe/sCZyqtB54845HsFWOoXod++dbU81sbk/r6tQl2UFdC++
	2dkWjtk4PZGS0syKfFD5DYywfeLQk2K2GknHDPwddsU/QeAu/bjRqNJPF8P5scf11rKjNhOhPrH
	DvR++sw==
X-Gm-Gg: AR+sD13SaO/7rR3+FUwoFyWqd/aKWccs8rPR/anbc+Q5OedKLpr2O9b0JITDynUzBkA
	foFTwoNOSC9mbKMSzsTMpPYDBWOE8KuuTN9aDhENAPq2t1NU14r8BpZHHgX93suRPZHOOonBFIn
	1ioe0728MZMAatRLBq5mLXIn9SqVHozdfJHTnkt265d7uuU2D6eoAKsoBs4EfHMq0CjVjSViZCB
	9bmqYChxB2CI7bx3iJXyEdsHlKPY2b1SGGjpR0GZf1XFIL6eAUubLXto8RyUj0gtBk8mtM+kg8h
	kFs4wLI4Mm3+sOQ+7eT//Ygit+bGKN4//XNEvKKZvWozbHfbmWrAH5stcv2Px+F2regv43egU8L
	HrdFGeLoHVhmsiARTo1wV9C/YmzD4uFE+s1kSgXK/3mWLGHRpRPkAwjfIspL59WuAH2CBOVe+JH
	ODOcPNKwNXnJu8TYsdwu9bnDiUvJ0OQWpIiI2RwCl6xb5V4VLf2uVEJMtkccatNuISJoZNWiJcy
	J1Aa5txk2pFHq5zJ8a2HYXo5eYnxDKYHkCBWvUKHgojn/yaD2y5
X-Received: by 2002:a05:600c:3b95:b0:495:48d7:f178 with SMTP id 5b1f17b1804b1-499aa1b97ccmr184623225e9.11.1787215952258;
        Thu, 20 Aug 2026 01:52:32 -0700 (PDT)
Message-ID: <39a438f2-e54f-4975-952e-cfcd101c8050@suse.com>
Date: Thu, 20 Aug 2026 10:52:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 2/2] x86emul: use latched XCR0 in x86emul_get_fpu()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Andrew Mbugua <andrewprecious388@gmail.com>
References: <0c3cb1ae-4888-4319-a348-263f7913a7f2@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <0c3cb1ae-4888-4319-a348-263f7913a7f2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787215952-504DBB50-80ADE671/0/0
X-purgate-type: clean
X-purgate-size: 3770

Avoid re-reading, and instead pass state into the function. For
get_fpu() to use "s" as new argument, we need a new local variable in
x86_emulate() though.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
That new local "s" can likely be leveraged to replace explicit uses of
"state" in the function (past the point where the alias #define is).
Long term we probably want to aim at consistently using "s" everywhere
where a struct x86_emulate_state * variable/parameter is needed.
x86emul_get_fpu() isn't using "s" right away just because that would end
up inconsistent with adjacent code (put_fpu() first and foremost). I
could certainly change that.

--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -743,12 +743,13 @@ int x86emul_get_cpl(struct x86_emulate_c
                     const struct x86_emulate_ops *ops);
 
 int x86emul_get_fpu(enum x86_emulate_fpu_type type,
+                    const struct x86_emulate_state *state,
                     struct x86_emulate_ctxt *ctxt,
                     const struct x86_emulate_ops *ops);
 
 #define get_fpu(type)                                           \
 do {                                                            \
-    rc = x86emul_get_fpu(fpu_type = (type), ctxt, ops);         \
+    rc = x86emul_get_fpu(fpu_type = (type), s, ctxt, ops);      \
     if ( rc ) goto done;                                        \
 } while (0)
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -394,36 +394,30 @@ do {
 
 int x86emul_get_fpu(
     enum x86_emulate_fpu_type type,
+    const struct x86_emulate_state *state,
     struct x86_emulate_ctxt *ctxt,
     const struct x86_emulate_ops *ops)
 {
-    uint64_t xcr0;
     int rc;
 
     fail_if(!ops->get_fpu);
     ASSERT(type != X86EMUL_FPU_none);
 
-    if ( type < X86EMUL_FPU_ymm || !ops->read_xcr ||
-         ops->read_xcr(0, &xcr0, ctxt) != X86EMUL_OKAY )
-    {
-        ASSERT(!ctxt->event_pending);
-        xcr0 = 0;
-    }
-
     switch ( type )
     {
     case X86EMUL_FPU_zmm:
-        if ( !(xcr0 & X86_XCR0_ZMM) || !(xcr0 & X86_XCR0_HI_ZMM) ||
-             !(xcr0 & X86_XCR0_OPMASK) )
+        if ( !(state->xcr0 & X86_XCR0_ZMM) ||
+             !(state->xcr0 & X86_XCR0_HI_ZMM) ||
+             !(state->xcr0 & X86_XCR0_OPMASK) )
             return X86EMUL_UNHANDLEABLE;
         /* fall through */
     case X86EMUL_FPU_ymm:
-        if ( !(xcr0 & X86_XCR0_SSE) || !(xcr0 & X86_XCR0_YMM) )
+        if ( !(state->xcr0 & X86_XCR0_SSE) || !(state->xcr0 & X86_XCR0_YMM) )
             return X86EMUL_UNHANDLEABLE;
         break;
 
     case X86EMUL_FPU_opmask:
-        if ( !(xcr0 & X86_XCR0_SSE) || !(xcr0 & X86_XCR0_OPMASK) )
+        if ( !(state->xcr0 & X86_XCR0_SSE) || !(state->xcr0 & X86_XCR0_OPMASK) )
             return X86EMUL_UNHANDLEABLE;
         break;
 
@@ -1310,7 +1304,7 @@ x86_emulate(
     /* Shadow copy of register state. Committed on successful emulation. */
     struct cpu_user_regs _regs = *ctxt->regs;
     const struct cpu_policy *__maybe_unused cp = ctxt->cpu_policy;
-    struct x86_emulate_state state;
+    struct x86_emulate_state state, *s = &state;
     int rc;
     uint8_t b, d, *opc = NULL;
     unsigned int first_byte = 0, elem_bytes, insn_bytes = 0;
@@ -1439,7 +1433,7 @@ x86_emulate(
     /* With a memory operand, fetch the mask register in use (if any). */
     if ( ea.type == OP_MEM && evex.opmsk &&
          x86emul_get_fpu(fpu_type = X86EMUL_FPU_opmask,
-                         ctxt, ops) == X86EMUL_OKAY )
+                         s, ctxt, ops) == X86EMUL_OKAY )
     {
         uint8_t *stb = get_stub(stub);
 



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 09:00:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 09:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396152.1634187 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwydG-0004pr-V0; Thu, 20 Aug 2026 09:00:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396152.1634187; Thu, 20 Aug 2026 09:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwydG-0004pk-Rx; Thu, 20 Aug 2026 09:00:18 +0000
Received: by outflank-mailman (input) for mailman id 1396152;
 Thu, 20 Aug 2026 09:00:17 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwydF-0004pe-KB
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:00:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwydF-001Qtc-0K
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 11:00:17 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86c21f-bab6-0a2a0a5309dd-0a2a4506df6e-22
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 11:00:16 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86c220-195a-0a2a45060019-d1558033e82f-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 11:00:16 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4954f5e8020so11234115e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 02:00:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b1441748sm12110014f8f.8.2026.08.20.02.00.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 02:00:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787216416; x=1787821216; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=Kbk0p0sFdTOXpyHNgmO43sz9czAYt6f+PyD+UeTBAtc=;
        b=PhuKFt5C8g1ytrjAcOvSHpcgdLeOtKW9lBwVqzLUfgNMPW4UvxK/4oYNo+0nq9zeHU
         Kn4QxxIpShloOmRGym7KVU/f44jHdWo8BSeW6qUP5mq0qKsjZjWfU8e6uYMmQmUGEcT3
         VrnaPGzmjghUbXIf97yW/aLt8iNCKKv7IKGkaBK8AcV0MfxjnFkK80XU0TcE9wmvk5di
         cpXDvT76prEyXzs8pYu0//M2BzeCJv0pl3wAD/0Gj1PZfj/a8O3SuIq9BXvKmbrsu/jA
         WX1nRhCpDS1DNCkEBi6LB9zSpznu3zftB+ZrSHKZYDw5TgDJ+zKmsWvBWZbG4YQfW3JJ
         sO0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787216416; x=1787821216;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Kbk0p0sFdTOXpyHNgmO43sz9czAYt6f+PyD+UeTBAtc=;
        b=oCJ45odST1EP31+5fnWxnSeTboQCo+d6hsrD6CWxPHehHzX4/PzQI35y5C1ZJpu7j4
         lZai8BS7YYJMDW9IcPOxUEcjIC/Wwbw1210ORn1B5Dn9bDt1ALVGP+KDOhXg3wty5kWR
         Gya7SqW88bDptq6rR9CYROV8ppnPTh7/liszZ3GPZuf08ykV1DB9ah3p8+WvpGQrqj5d
         vUyI6/cKD/i1fuemxD3sM1hjrz8GXqQLOHoK1IM6EOVAmes71mHc/IM6vsoXxeCP+YQz
         MURnWLS1mY2SOjzlfX18+aQRy2wU27fc5dtKiZKlR0TM0ZJp03G4QQGU3WrrsdRIXwiD
         TXLw==
X-Gm-Message-State: AOJu0YzJnitCLjn6ckIYzUV1AWGnOsk9WmRmoeQwY9dteQurh0Ptr2Cl
	E66hEWb8EVb4bd9poyOkB4qzVZQPMJn109j7cxdagCVMFSCJ592UK+7/NEiYLQT92A==
X-Gm-Gg: AR+sD132zL84jRG5GZTw8cnKMl9lZB/MV1ZT+yeiPVOKQDuIrTXS8T62LXdYqmuyhQf
	MWhXNKE7FRnGWW4jHGua2Q36coAAgFRZLExSpS8MBC3TafRLlIWEIc87vKXgRi2pB81p7B82Yje
	/xluQhzFJSLCPBqDIbMH8SARU91E8kjk33OCJrzLwlgbVQG0eGWV4choe69mqenSboYNYnho0eQ
	ArA37gFSFWjpG/iQDuOS8moEbct2hBGod1TARYiYSWaIaP8F0P5ZO5ebhVsiy8lejkbzJVjs2xI
	aAvamPRBOVKeGPmjrP74t9RwuFWClQmRTupEE51AQIsmJMtfQ8SjO8R/Z/LbimDZiMfGNgphd6W
	9qDzAl9v/1gPvgfDrlZW6MN0gRCLJKNrdrQXzQNBJOGN/VhuCZi/7x20GTWz9FmILIuKnYBVebl
	QaiuXkGaSOsWEPprAC5UoZgodrFSbyHW55E9DThIgMyfx+bMS2tvAOvBnfttrCy/7En6FxExNe0
	L2GOHO0T7EQe10C51rR0Rp7u4sx+WLNRh4Ykoc3XFvTazZTDyjhDI7LK+2zxa0=
X-Received: by 2002:a05:600c:468a:b0:496:c9cd:e7ab with SMTP id 5b1f17b1804b1-499aa172377mr151370065e9.5.1787216415813;
        Thu, 20 Aug 2026 02:00:15 -0700 (PDT)
Message-ID: <149d9810-7f8c-487b-aa5e-208de2f4c2ec@suse.com>
Date: Thu, 20 Aug 2026 11:00:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Ping: [PATCH] Xen/gnttab: improve error handling in
 gnttab_dma_{alloc,free}_pages()
From: Jan Beulich <jbeulich@suse.com>
To: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
 Juergen Gross <jgross@suse.com>, Stefano Stabellini <sstabellini@kernel.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
References: <00493037-e77e-4631-8594-64ad4e46fa40@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <00493037-e77e-4631-8594-64ad4e46fa40@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787216416-F7ACA77B-A8DAF98E/0/0
X-purgate-type: clean
X-purgate-size: 3671

On 16.02.2026 09:55, Jan Beulich wrote:
> Both decrease-reservation and populate-physmap can succeed partially. For
> the former this may be pretty unlikely, but clearly the latter can hit
> both out-of-memory conditions in the hypervisor or denial because of the
> allocation exceeding the domain's allowance (there's no interaction with
> the balloon driver here either).
> 
> In gnttab_dma_free_pages() we simply can't give back to the system what
> hasn't been re-filled with backing memory. For gnttab_dma_alloc_pages()
> both parts of the overall region need dealing with differently.
> 
> While no present caller of gnttab_dma_free_pages() checks its return
> value, also don't use -EFAULT there: It really is an out-of-memory
> condition. (In gnttab_dma_alloc_pages() -EFAULT doesn't look quite right
> either, but I couldn't think of a clearly better error code there.)
> 
> Fixes: 9bdc7304f536 ("xen/grant-table: Allow allocating buffers suitable for DMA")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I'm likely screwing things up, as I can't understand how this is intended
> to work: args->dev_bus_addr shouldn't really be in pseudo-physical address
> space, or else the address isn't suitable for handing to a device in order
> to DMA to/from it. Hence using __phys_to_pfn() on it to then hand the
> result to pfn_to_page() feels bogus. Was all of this perhaps only ever
> intended for (tested with) translated domains? With the uses of
> xenmem_reservation_va_mapping_*() only being masquerade?
> 
> Furthermore the allocated buffer ought to have been contiguous in
> machine / DMA space. Yet the way it's re-populated upon freeing of the
> area doesn't guarantee that at all.
> 
> All of what is done assumes dma_free_{coherent,wc,attr}() is capable of
> freeing piecemeal. I only checked dma_release_from_dev_coherent() to
> fulfill this requirement. If this can't be relied upon, please consider
> this submission as merely a bug report (for someone else to fix).

Even in case this patch is complete rubbish, something wants doing here. May
I therefore ask for feedback (perhaps in the form of a completely different
patch)?

Jan

> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1095,6 +1095,28 @@ int gnttab_dma_alloc_pages(struct gnttab
>  	ret = xenmem_reservation_decrease(args->nr_pages, args->frames);
>  	if (ret != args->nr_pages) {
>  		pr_debug("Failed to decrease reservation for DMA buffer\n");
> +		if (ret >= 0) {
> +			/* Free the part where decrease didn't work. */
> +			size_t done = ret << PAGE_SHIFT;
> +
> +			xenmem_reservation_va_mapping_update(args->nr_pages - ret,
> +							     &args->pages[ret],
> +							     &args->frames[ret]);
> +
> +			if (args->coherent)
> +				dma_free_coherent(args->dev, size - done,
> +						  args->vaddr + done,
> +						  args->dev_bus_addr + done);
> +			else
> +				dma_free_wc(args->dev, size - done,
> +					    args->vaddr + done,
> +					    args->dev_bus_addr + done);
> +
> +			if (!ret) /* Nothing else to do? */
> +				return -EFAULT;
> +
> +			args->nr_pages = ret;
> +		}
>  		ret = -EFAULT;
>  		goto fail;
>  	}
> @@ -1128,7 +1150,12 @@ int gnttab_dma_free_pages(struct gnttab_
>  	ret = xenmem_reservation_increase(args->nr_pages, args->frames);
>  	if (ret != args->nr_pages) {
>  		pr_debug("Failed to increase reservation for DMA buffer\n");
> -		ret = -EFAULT;
> +		/* Can only free what has been re-filled. */
> +		if (!ret)
> +			return -ENOMEM;
> +		if (ret > 0)
> +			args->nr_pages = ret;
> +		ret = -ENOMEM;
>  	} else {
>  		ret = 0;
>  	}



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 09:17:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 09:17:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396173.1634196 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyu9-0006dD-BF; Thu, 20 Aug 2026 09:17:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396173.1634196; Thu, 20 Aug 2026 09:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwyu9-0006d6-7u; Thu, 20 Aug 2026 09:17:45 +0000
Received: by outflank-mailman (input) for mailman id 1396173;
 Thu, 20 Aug 2026 09:17:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wwyu8-0006d0-2q
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 09:17:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwyu7-008EE4-Di
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 11:17:43 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a86c626-2eae-0a2a0a5409dd-0a2a45058ce8-38
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 11:17:43 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a86c637-4cb1-0a2a45050019-d155dd2bc52e-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 11:17:43 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so1292091f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 02:17:43 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482bab42f8esm3871268f8f.28.2026.08.20.02.17.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 20 Aug 2026 02:17:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1787217463; x=1787822263; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0YRikbpNQey1+eawRM8lhO+RG+oxgMmFcY/uhY7bB1k=;
        b=myfvyBRzE3W13nB9dVT9/1kkyxgF3c6FqUFgUjXX+hA7OB7e/5G9ETQixStPj3Xy23
         ll8YhAeVGbixE9X8/oK1nVxMjS6Ol6EGA7fhMeNqTK7JXCAzO+GETPRkKGUMjOWY6KAX
         OuWDE+0BFGLbillNi2EcCYzQnQETH2R/w9M3Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787217463; x=1787822263;
        h=content-transfer-encoding:content-type:mime-version: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=0YRikbpNQey1+eawRM8lhO+RG+oxgMmFcY/uhY7bB1k=;
        b=ZRD9KKdisHdfGd2rD0QHEsb/4KqLuVTd+MqhrKFVbGvwU0sIvJvAztb1TLzFtfTphT
         GV5u7EwWSwLZQeZcfDD+wzdqijrPwCI6pOFfFcUfaq9jX6LieiABH7qARAXSWfjwjvE2
         7PvqHlC78StqP4nSX+y7slrbPwp/MmtbsxwrTkHkyUaeD0tEVcHOXC2KMcAd/yNLHUbc
         Y6/DSIkZGp383IOJEW41+E2vSB+gsTA/o9+QWMC5B4n+jhd/Q0AI0b9YQN1QZrNPJlM4
         3Hkrqpg0CtIaoAmOaQBfhcXozZdg68mPlCxrMxY1uvEEOjnDIYYVKA5G5X6G8rzwkpGi
         KHVQ==
X-Gm-Message-State: AFuF++lBGxCtjJR//iR5Pa/f+Db7MFYtfPSaGESJFQj6ndax9WRW+hX+
	F/SRKy6668DxGT4F/aa8QPaoqe/GASoluvZXtRppCaQLSFT88lO4hTazIMQ7n1VnrY7wvAZblBE
	U/i31zNU=
X-Gm-Gg: AR+sD10YaLN8ujB3MCOZsGNBvD3W6n4Gc20m46F/jDTqDUWunTTvP8Ncnmrp0/Pkej4
	BsjH9vzKg1cGN8SI1TNar7BlMB1ERQvi4fCuxDsTG7idY6SOZUDwHWRrubr20oI23uePU7agiP0
	hcM6QM40d869vQfpbzr1gVhgLJq2ZRt83hthvjf1nq0tUiUiZhM0GqxJNDkvdWF2oIZq4MMhJC3
	Mr9aWpBWaEsKCLWhyp5VTqyxDi4pMJC0NV/fS56iqpusryvsHIS0DdDiwcnZi4t9ALl9eh2fM/n
	jkgxsgdxN195enDwZHSvDGSKaP1uxlEXbHjb1s2+4ue5hZcLTC/oDGI5l8ZLP7dt9XLk6IO54ZG
	3mXCDdoYYxdIyXz+ciqeRf9ilqlo08V5w0RxwzWmXkpfPHhwg5gX13+5cTO63/uVcAwWE7c+0wj
	VP7mk0GkjEit664XYu0YO8Cqrx9zOs8Q2tXpIXs1Ro/e62xW+/FoPVe214j79qJZxS2RRhZEzO6
	aJDnsATtft8+3/R+V1pE/OL2xGUyJgcn1mw0OU=
X-Received: by 2002:a05:6000:60c:b0:481:51ce:542f with SMTP id ffacd0b85a97d-482b1ff29cdmr21373896f8f.21.1787217462458;
        Thu, 20 Aug 2026 02:17:42 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/hvm: Use system descriptor type names in hvm_task_switch()
Date: Thu, 20 Aug 2026 10:17:40 +0100
Message-Id: <20260820091740.2006909-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787217463-243112A1-A28F2885/0/0
X-purgate-type: clean
X-purgate-size: 1195

... rather than magic numbers.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/hvm/hvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 955fc062a5c7..56bc2857389c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3066,7 +3066,8 @@ void hvm_task_switch(
     if ( tr.g )
         tr.limit = (tr.limit << 12) | 0xfffu;
 
-    if ( tr.type != ((taskswitch_reason == TSW_iret) ? 0xb : 0x9) )
+    if ( tr.type != (taskswitch_reason == TSW_iret
+                     ? SYS_DESC_tss_busy : SYS_DESC_tss_avail) )
     {
         hvm_inject_hw_exception(
             (taskswitch_reason == TSW_iret) ? X86_EXC_TS : X86_EXC_GP,
@@ -3192,7 +3193,7 @@ void hvm_task_switch(
             goto out;
     }
 
-    tr.type = 0xb; /* busy 32-bit tss */
+    tr.type = SYS_DESC_tss_busy;
     hvm_set_segment_register(v, x86_seg_tss, &tr);
 
     v->arch.hvm.guest_cr[0] |= X86_CR0_TS;
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 10:11:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 10:11:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396233.1634205 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwzjd-0005YN-2v; Thu, 20 Aug 2026 10:10:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396233.1634205; Thu, 20 Aug 2026 10:10:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwzjd-0005YG-0O; Thu, 20 Aug 2026 10:10:57 +0000
Received: by outflank-mailman (input) for mailman id 1396233;
 Thu, 20 Aug 2026 10:10:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01ea6ee71000c4f3@swg.vates.tech>)
 id 1wwzjb-0005YA-6w
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:10:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwzja-003Y1A-K8
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:10:54 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01ea6ee71000c4f3@swg.vates.tech>)
 id 6a86d2a4-2eae-0a2a0a5409dd-0a2a4508a10e-32
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:10:54 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01ea6ee71000c4f3@swg.vates.tech>)
 id 6a86d2ad-f659-0a2a45080019-b9ff1c12a08d-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:10:54 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01ea6ee71000c4f3.002 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 10:10:51 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id 098BB83827;
 Thu, 20 Aug 2026 12:10:51 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=4qm5c9scI5k9QrGgDOXysqmxP7HMqR6dBOr7citWS2c=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=REzRSqUwR3D48enDnfwZiQSPNoD9Bn7y8q2mRfqQ7MEqD32tXPzbWYfmwR+cufg2hV161/Jqi
 m54GCOcYew4FtC50JNhf1aHm++NUdGGV27uJBt2M5k/zQByCxQ6YRmiiaczrTSfSwM1qc8wbMmu
 oo4WmZH3ANiuZuCjIzIcGhyT4Yh15jBn74skKPpfvF06E37LE4tsKs8XJwhybRkFwEQJqT93Xks
 VhvoLrW8vZqyWy4ygeYdz/8wX/gOJDZel9dvm3mlmqu3KJJ2EZfS9qsQxwR8vArotIsB57NeC2x
 TlNWbxI+XcKknvnk3AmDvPwGNysSxasW8bHYW9mkDYIg==
X-Zone-Loop: 86596bae23cc853c6486b7a5ab5ca5bdd3317fa47225
x-campaign-type: default
x-transaction-id: b82c9f06-7a01-49c6-8e5b-d42ab2bc3da1
x-swg-uid: 01-a14080de-57a1-4062-b9e2-93e711107e14
X-Mailer: Sweego
Message-ID:
 <1787220651.8631fc262581453bbf619ec5b2062170.1a01ea6ee71000c4f3@vates.tech>
x-swg-bid: 1787220651.8631fc262581453bbf619ec5b2062170.1a01ea6ee71000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 20 Aug 2026 12:10:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v7 03/14] x86/domain: Defer domain iommu
 initialization.
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <cover.1763569135.git.teddy.astie@vates.tech>
 <c4a81e284ec202a34b8e983679dead4dc2ae248a.1763569135.git.teddy.astie@vates.tech>
 <4fed56c0-b8b1-408b-bc60-7a1afe05ffa2@suse.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <4fed56c0-b8b1-408b-bc60-7a1afe05ffa2@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------4D01FwRuybd5lRXVN88F05Eb"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787220651142
X-purgate-ID: tlsNG-c1860d/1787220654-D477387B-F8BBB418/0/0
X-purgate-type: clean
X-purgate-size: 7437

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------4D01FwRuybd5lRXVN88F05Eb
Content-Type: multipart/mixed; boundary="------------cr0n2RVqAuRFj7RSMvHdCIH9";
 protected-headers="v1"; hp="clear"
Message-ID: <e92e2be6-75b4-4021-9d06-166d7e4bab39@vates.tech>
Date: Thu, 20 Aug 2026 12:10:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v7 03/14] x86/domain: Defer domain iommu
 initialization.
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <cover.1763569135.git.teddy.astie@vates.tech>
 <c4a81e284ec202a34b8e983679dead4dc2ae248a.1763569135.git.teddy.astie@vates.tech>
 <4fed56c0-b8b1-408b-bc60-7a1afe05ffa2@suse.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <4fed56c0-b8b1-408b-bc60-7a1afe05ffa2@suse.com>

--------------cr0n2RVqAuRFj7RSMvHdCIH9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMTkvMDgvMjAyNiDDoCAxNzoxMCwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g
MjAuMTEuMjAyNSAxMjowOSwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBGb3IgdGhlIElPTU1V
IHJlZGVzaWduLCB0aGUgaW9tbXUgY29udGV4dCBwYWdldGFibGUgaXMgZGVmaW5lZCBvbmNl
IGR1cmluZw0KPj4gaW5pdGlhbGl6YXRpb24uIFdoZW4gcmV1c2luZyBQMk0gcGFnZXRhYmxl
LCB3ZSB3YW50IHRvIGVuc3VyZSB0aGF0IHRoaXMNCj4+IHBhZ2V0YWJsZSBpcyBwcm9wZXJs
eSBpbml0aWFsaXplZC4NCj4+DQo+PiBTaWduZWQtb2ZmLWJ5IFRlZGR5IEFzdGllIDx0ZWRk
eS5hc3RpZUB2YXRlcy50ZWNoPg0KPiANCj4gIEZyb20gd2hhdCBpcyBzYWlkLCBJIGZvciBv
bmUgY2Fubm90IGRlZHVjZSB3aHkgdGhlIG1vdmUgaXMgKGEpIG5lY2Vzc2FyeSBhbmQNCj4g
KGIpIGNvcnJlY3QgLyBzYWZlIHRvIGRvLg0KPiANCj4gSmFuDQo+IA0KPj4gLS0tIGEveGVu
L2FyY2gveDg2L2RvbWFpbi5jDQo+PiArKysgYi94ZW4vYXJjaC94ODYvZG9tYWluLmMNCj4+
IEBAIC05MjcsOSArOTI3LDYgQEAgaW50IGFyY2hfZG9tYWluX2NyZWF0ZShzdHJ1Y3QgZG9t
YWluICpkLA0KPj4gICAgICAgaWYgKCAocmMgPSBpbml0X2RvbWFpbl9pcnFfbWFwcGluZyhk
KSkgIT0gMCApDQo+PiAgICAgICAgICAgZ290byBmYWlsOw0KPj4gICANCj4+IC0gICAgaWYg
KCAocmMgPSBpb21tdV9kb21haW5faW5pdChkLCBjb25maWctPmlvbW11X29wdHMpKSAhPSAw
ICkNCj4+IC0gICAgICAgIGdvdG8gZmFpbDsNCj4+IC0NCj4+ICAgICAgIHBzcl9kb21haW5f
aW5pdChkKTsNCj4+ICAgDQo+PiAgICAgICBpZiAoIGlzX2h2bV9kb21haW4oZCkgKQ0KPj4g
QEAgLTk0OCw2ICs5NDUsOSBAQCBpbnQgYXJjaF9kb21haW5fY3JlYXRlKHN0cnVjdCBkb21h
aW4gKmQsDQo+PiAgICAgICBlbHNlDQo+PiAgICAgICAgICAgQVNTRVJUX1VOUkVBQ0hBQkxF
KCk7IC8qIE5vdCBIVk0gYW5kIG5vdCBQVj8gKi8NCj4+ICAgDQo+PiArICAgIGlmICggKHJj
ID0gaW9tbXVfZG9tYWluX2luaXQoZCwgY29uZmlnLT5pb21tdV9vcHRzKSkgIT0gMCApDQo+
PiArICAgICAgICBnb3RvIGZhaWw7DQo+PiArDQo+PiAgICAgICBpZiAoIChyYyA9IHRzY19z
ZXRfaW5mbyhkLCBYRU5fQ1BVSURfVFNDX01PREVfREVGQVVMVCwgMCwgMCwgMCkpICE9IDAg
KQ0KPj4gICAgICAgew0KPj4gICAgICAgICAgIEFTU0VSVF9VTlJFQUNIQUJMRSgpOw0KPiAN
Cg0KKGEpDQoNCkZvciBub3cgaW4gWGVuLCBpb21tdV9kb21haW5faW5pdCgpIGRvZXNuJ3Qg
Y3JlYXRlIG9yIHJldXNlIGFueSANCnBhZ2V0YWJsZSAoZm9yIGhhcF9wdF9zaGFyZSkgKnll
dCosIHRoaXMgaXMgZGVmZXJyZWQgdG8gDQpwZXItaW1wbGVtZW50YXRpb24gY29kZSB0aGF0
IGlzIGNhbGxlZCBtdWNoIGxhdGVyLg0KDQpUaGUgZW5kIGlkZWEgaXMgdG8gbW92ZSBzb21l
IG9mIHRoZSBwYWdldGFibGUgaW5pdGlhbGl6YXRpb24vdHJhY2tpbmcgdG8gDQppb21tdV9k
b21haW5faW5pdCgpICh0aGVuIHRvIGlvbW11X2NvbnRleHRfaW5pdCgpKSwgYnV0IGluIHRo
ZSANCmhhcF9wdF9zaGFyZSBjYXNlLCB0aGUgUDJNIG5lZWRzIHRvIGJlIGluaXRpYWxpemVk
IGZpcnN0IChlLmcgdGhyb3VnaCANCnBhZ2luZ19lbmFibGUpLg0KDQooYikNCg0KVGhlcmUg
aXMgbm8gZGVwZW5kZW5jeSBvZiBpb21tdV9kb21haW5faW5pdCgpIHRvIGJlIGNhbGxlZCBi
ZWZvcmUgDQpodm1fZG9tYWluX2luaXRpYWxpc2UoKS9wdl9kb21haW5faW5pdGlhbGlzZSgp
LiBJbiBwYXJ0aWN1bGFyLCB3ZSdyZSBub3QgDQphZGRpbmcgbmV3IHAybSBlbnRyaWVzIHRv
IHRoZSBndWVzdCB0aGF0IHdvdWxkIHJlcXVpcmUgSU9NTVUgbWFwcGluZ3MuDQoNClNvIEkg
ZG9uJ3Qgc2VlIGFueSBpc3N1ZSBtb3ZpbmcgdGhlIGNhbGwgbGF0ZXIuDQoNCkFJQSwgaXQn
cyBtb3N0bHkgcHJlcGFyYXRvcnkgcGF0Y2hlcyAodG8gYXZvaWQgbWFraW5nIHRoZSBuZXh0
IG9uZXMgbW9yZSANCmNvbXBsZXggdGhhbiB0aGV5IGFscmVhZHkgYXJlKTsgaXQncyBub3Qg
bmVjZXNzYXJpbHkgdXNlZnVsIG9uIGl0cyBvd24uDQoNClRlZGR5DQo=

--------------cr0n2RVqAuRFj7RSMvHdCIH9--

--------------4D01FwRuybd5lRXVN88F05Eb
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqG0qoFAwAAAAAACgkQZg+p0QLLz9DQ
9Qv/Sap6WTImu6WRERId9yjur0naFGd+6P9WGDszUb+YyxpKO6L9KNJUckNrrHljxejkxz3CdJU+
0PKHbPje7mIpyWoaRivjBgMJPlMu8V0i5GuBc3kWzmrWAdWosUaF6OJ/l42rX8n3P1d8VMFPsyt8
OAs2BowZSANmPH8tJFdzQ9MjTSpwkMb/CxXg2cbsyi4Y92/ltqYJyY+v42tOYEy6+f2Vc6+VvUGE
9DYLDtWQqjMFtPF4ZUh8eXK1cDQq7SDIAwsmIFyrKoe9xQ+pMyduELasxy0Yaw7dHD+x7nT6fZg0
QqW0sf8S80CaImFul2BZh/zerMpz+IBHcFlCZnm4Ye89sR/+cZQrpGGJJThi+4/TR81GCe8B85Iz
PA/FFjozxcN6+w0jnn3B+PBbfi1qlutrlW8/TykcNocjFzlzpbgfKBPdyS/arsyUJ/0Q4jwjsECq
JM3rlpyiqn9Dv5bdt3Aote8Jd25F29A1jEUWxV2+tOroj7NefxSYS8Ut8tb1
=iB/S
-----END PGP SIGNATURE-----

--------------4D01FwRuybd5lRXVN88F05Eb--


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 10:12:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 10:12:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396241.1634214 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwzl2-00060N-Cu; Thu, 20 Aug 2026 10:12:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396241.1634214; Thu, 20 Aug 2026 10:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwzl2-00060E-9V; Thu, 20 Aug 2026 10:12:24 +0000
Received: by outflank-mailman (input) for mailman id 1396241;
 Thu, 20 Aug 2026 10:12:23 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <accek@invisiblethingslab.com>) id 1wwzl1-000608-8Y
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:12:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwzl0-00Cvh9-Ax
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:12:22 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <accek@invisiblethingslab.com>)
 id 6a86d300-8faa-0a2a0a5109dd-0a2a4501b1a0-18
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:12:22 +0200
Received: from [103.168.172.147] (helo=fout-a4-smtp.messagingengine.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <accek@invisiblethingslab.com>)
 id 6a86d304-5984-0a2a45010019-67a8ac93a2bf-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:12:21 +0200
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailfout.phl.internal (Postfix) with ESMTP id 2869BEC011A;
 Thu, 20 Aug 2026 06:12:20 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Thu, 20 Aug 2026 06:12:20 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 20 Aug 2026 06:12:18 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm3 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:Message-ID:MIME-Version:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:from:from:in-reply-to
	:message-id:mime-version:reply-to:subject:subject:to:to; s=fm3;
	 t=1787220740; x=1787307140; bh=sGNqTptE7s6gYdrLB8Z9LpMMoI+yyqIv
	9WSs2rN7GJ8=; b=Me5agFN+E8UF8H0Wp6vy/FgrkD/W2H5Kgfg81IO8JN3JNqFg
	sp9YaS1qz09HwTzWXY+w5MyW9bwHKhb0rjrM6rIYsjiWXSX1Slppyh0XnYoUdSio
	yH9otN71DwCgYZ7+NckQ2lw6NEutJkZQIlVvMTtWhNFbOnr9TGk2YFlocbSJmwci
	kwcWgaK00yj8wgO1d2q1PEy2Onl1JSfc2ETdEVS/rVymz9wNF7VWYCZUfyPyZPhr
	k8vftwI2KCkm7ZFCPeNyZg7kZp47wOQg84IO80D/PekszV7hX1hJvkD1R15i8OdX
	+vugVDDEfADOaq4moL1T37pINFREsyjcdvukBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:content-type:date:date:feedback-id:feedback-id
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1787220740; x=1787307140; bh=sGNqTptE7s6gYdrLB8Z9LpMMoI+y
	yqIv9WSs2rN7GJ8=; b=XieaARD342wcYHvjfXUJ0EC75HZFCzWAjP7lT2kW763J
	0xRj15oGd71EgVYSqHXTxRXQp0jy+afLbJKjmoO+JarTylrxVMdMalON9Yo7F9m8
	xYIA6LO9I4EEWfp4fbz6Y7d1dGeBkm53PjVBIctH7LwnN8wAZRXYWnUukrMvPULj
	TmMguAmAJSE8STJiKJv6Wv5x5SPSo6P+WNTx+wDq0EO38jP5+fJ8l+D6kxQ1r/W7
	Eh7JES6tnz6y0UW51tasqhlygGEXBgaX2pU3DnT7eF6QmrfmWr3Hsx2JVtYYDIFT
	rmg6ko8feWtpAygrAh+ey+nefHUkv8bmal359Varnw==
X-ME-Sender: <xms:A9OGalKiN3MqgffRbvzYQ0NGV0s7o64A3mLrm77PgIYltLiaGJscQg>
    <xme:A9OGajbN68jcWgUx0YNhZgfrEnVxh-dBdawnABnudO3FHCIo8_6tOVoxYy04Ns5l7
    p98eiENAUGzubIN4bFjUH7aiQexjX1KlsoFXN31ATrZFyz2WHk>
X-ME-Received: <xmr:A9OGav-_0FODOrJDz9FzmT546erxU0wvHnPF9PVFfh9itV3rHABHJgAFqD3j6GEDm5qsBXUIizJByQ>
X-ME-Proxy-Cause: dmFkZTGZPi6dpTYlHg6VIiYaWHMvOIezsDyxbHXjcalzNSEsRw8SzB0wyFhWhmZcQagGpE
    OlPNvgg4RMiUTnAebNy8Bpw976A2zZqzYqgOJ30OQloXKVKs9VrQcBADx9G5yD6PbcSMcy
    Qb3vxmzNDwb3mYrBCGbkhfbJv3Uel6h9lvZgqPDI9O9VGVzpP7/zJBrldxFNvmrM/4EGvM
    dtNgoFpV6ZLgsCP0XQjT/JVNu/0KxxjrVVuTOLuhZVpnuEbPoUmSvXXwVJPQtx7nKM3a0i
    KbGnzhOz6CgdcVt59ctG/y+o4XJDfbw6HDsE6QG/2npRTeB6IEOBTQRolBYc7zmfIkpENp
    FmtwyK+l7fsccfI+zWhXa/IUjMDTG92T/SPy0vZe63b1/L9ruYxPNKNNCl3kt/gKnxbK1N
    LB6vzSOHT1+R3rDmIDQGn0OudyEUl2IwvDVJ7QlVD1YlNzP5QTGE+qF/aNnU8Xf73AIMNQ
    KaJTBXl7oNaOugqf1OYExNef6XJGTJvxSRPwEEyM8cm4WPmKZ5R2K+529j50B63v48p7KJ
    oI2TSqnE5frJbIs6gLk8TNDGgl9gWv9xUti4wI1+qygBOHyw8ywppWbUCbYvWIabFZ+RmY
    jbqUm7xPG/WbkHVZKJfQi2fevtfeLjI6/1NtMZcquTBL2FtaA4WTGvTTqGBQ
X-ME-Proxy: <xmx:BNOGasZHJOxNtjUb6QP60v8EUhu2uZ4pVd7ZfZuBA8O7X_KJqLIJcg>
    <xmx:BNOGarNHK0payi0SADoD1knsXriPgmzJLh4RaJohWXDNSKhC40-dXQ>
    <xmx:BNOGagC5KRzxn_VNsOduUy50pe5uWMdwnZvWaTBB9e629n9cv9x7gg>
    <xmx:BNOGaqIg1HmnSJTlb4_p9f0KJe7GArjy9OnVOs6LamWCjmRTELioGg>
    <xmx:BNOGatd79R7eg2AEMjMnbNoj47tM_hPHdLPFBVNlg-PN43Aw8yqKSLG9>
Feedback-ID: i792e4853:Fastmail
From: =?UTF-8?q?Szymon=20Aceda=C5=84ski?= <accek@invisiblethingslab.com>
To: intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org,
	marmarek@invisiblethingslab.com,
	xen-devel@lists.xenproject.org,
	=?UTF-8?q?Szymon=20Aceda=C5=84ski?= <accek@invisiblethingslab.com>,
	stable@vger.kernel.org
Subject: [PATCH] drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV
Date: Thu, 20 Aug 2026 12:12:12 +0200
Message-ID: <20260820101212.1608543-1-accek@invisiblethingslab.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787220742-BF063757-99B9BB67/0/0
X-purgate-type: clean
X-purgate-size: 2351

Fixes display corruption on Xen PV dom0, where DMA buffers are not
guaranteed machine-contiguous, in which case bounce buffering kicks
in, breaking xe's memory coherency assumptions.

Apply the same workaround i915 carries in i915_sg_segment_size() since
commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment").

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382
Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/
Link: https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/ # i915 counterpart
Cc: stable@vger.kernel.org # v6.8+
Signed-off-by: Szymon Acedański <accek@invisiblethingslab.com>
---
 drivers/gpu/drm/xe/xe_bo.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h
index e8081af..152bfcf 100644
--- a/drivers/gpu/drm/xe/xe_bo.h
+++ b/drivers/gpu/drm/xe/xe_bo.h
@@ -9,6 +9,8 @@
 #include <drm/drm_prime.h>
 #include <drm/ttm/ttm_tt.h>
 
+#include <xen/xen.h>
+
 #include "xe_bo_types.h"
 #include "xe_ggtt.h"
 #include "xe_macros.h"
@@ -575,6 +577,23 @@ static inline unsigned int xe_sg_segment_size(struct device *dev)
 	struct scatterlist __maybe_unused sg;
 	size_t max = BIT_ULL(sizeof(sg.length) * 8) - 1;
 
+	/*
+	 * For Xen PV guests pages aren't contiguous in DMA (machine) address
+	 * space.  The DMA API takes care of that both in dma_alloc_* (by
+	 * calling into the hypervisor to make the pages contiguous) and in
+	 * dma_map_* (by bounce buffering).  But xe (like i915, see commit
+	 * 78a07fe777c4) ignores the coherency aspects of the DMA API and thus
+	 * can't cope with bounce buffering actually happening, so add a hack
+	 * here to force small allocations and mappings when running in PV
+	 * mode on Xen.
+	 *
+	 * Note this will still break if bounce buffering is required for other
+	 * reasons, like confidential computing hypervisors or PCIe root ports
+	 * with addressing limitations.
+	 */
+	if (xen_pv_domain())
+		return PAGE_SIZE;
+
 	max = min_t(size_t, max, dma_max_mapping_size(dev));
 
 	/*

base-commit: b4f95affc66ef76342c1f6bf3849f6c8ade6b9d6
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 10:14:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 10:14:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396248.1634223 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwzmm-0006V4-N6; Thu, 20 Aug 2026 10:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396248.1634223; Thu, 20 Aug 2026 10:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wwzmm-0006Ux-KI; Thu, 20 Aug 2026 10:14:12 +0000
Received: by outflank-mailman (input) for mailman id 1396248;
 Thu, 20 Aug 2026 10:14:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wwzmk-0006Un-O3
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:14:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wwzmk-001ecu-0e
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:14:10 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a86d35d-2eae-0a2a0a5409dd-0a2a45039442-42
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:14:09 +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 <jbeulich@suse.com>)
 id 6a86d371-fae8-0a2a45030019-d1558035c92b-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:14:09 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so13674555e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 03:14:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e805a4sm148307885e9.4.2026.08.20.03.14.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 03:14:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787220849; x=1787825649; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ppbOw5X9k2Qa/Zts6LjWZD0nb2M6WaqAEdmIkeX+SBw=;
        b=NDLEifrGxfTdKgJpexlxPLZ47Cd6/kIhv3ruHXpdvsiLXVVdWH2v1MJZ4Ewl+f4W3K
         zAp2ddaVEGX3MOWqFzxzy7+CPV6bNMjCpw+MA88ZNYI1TJ2SN91L1YKIyB0oiHpalbvX
         eoWV/LzdO+mvV4o6gySRsz4ZUxevKJEt2XxV3N75lbT/Av69BJZ0svQjQ37uJdUL6noc
         X2U2unY6imktymlHx5rcZtP8SrY6BL338byIwugSE/xnfrE6DdL8i/VKfofXzBRcgdi7
         q4tTw4P66ddwUR520VfgP9yXnA5x9QBM2VP1dQqz4yNxD9GJ873wnvNbnE3GSZHzackK
         0XNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787220849; x=1787825649;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ppbOw5X9k2Qa/Zts6LjWZD0nb2M6WaqAEdmIkeX+SBw=;
        b=qww2FKiYw2MTMmPLucQgTMswzW7Y8K9StoVgn5OQhS0oEomCMtNlRXq31N0Ol9HEJe
         UzTIAUDknKKNvo86ZHU9U3iaZuW1bH9TIPx7Md4bSVYmzEEH0IgbdW/tH25PvI6MK3/S
         phIs3/Qzv4RwsS2U1bEIilOEjJ++Ie4yjRW5L3VTq1G0QkiMKbURXST3bayL4e+LTwGd
         Q3HrC1A65SLpsmO0iwrzgfwl+nITvZwgn1I9lP3u+bVPKtxAwR+QKnmkXvqHmE705tos
         a5bhicdV4fVyrPDzooXK0E2Th18YW33KtmtmPKR3P/p3W9CSkiMr98NaW+QABa6imyj1
         8t5g==
X-Forwarded-Encrypted: i=1; AHgh+RpNKjxhjpkZqDTfs6xlOIt9D2KaY2cGGG7CHvH7wMQSWijMrGHi1GEjkuECLUo0DygeaTbQsL1Q2bg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPvPjq38z+f6V/BjdyG72Fjp05+HvlxJzGLRZTjqpbeqEuLEqK
	HJenrCeosyOWoVlnq1JsX9T4kkPF1iOatElQLaakvCwaJmTvAbc8fSCJZVWWF0YGV0L2w3pi/Bl
	RA7M9QA==
X-Gm-Gg: AR+sD10yxKsl3X23IBTGIe2+McG+LAsxVuXI/HRtiBANfbcluMHzePEGXTcQNjxKM98
	IJMnJlXmIqIQwUl4G/pIEtaHIGyWOjQSEaUnA007pd8CiiwbVldbCdB73FLVOYtVCzjaTbP1dub
	Sj9kTpS5BOrwI8dIoaogo+C7YoBQAm0z8YiRjI0K09ezwARaROy7B5kmWAZr8K+g+XS0SzgkcIF
	oqwLYHC99ivBa/K0ufdFd9uDvVaASOtzbAMTGh5U13zhhEVMNZkXqluDEXOOdy375lFdqHYsl8H
	LfyEPGMLb/v0wIhgwoiNF/Xu49mUg/ngz+lkUWbkZ6Y4pSJzEFhcq0mUBYjnQYbKBify87dIpyR
	0/4quSQeWKG7KFJ47k/kqiFtvfzl1eivEoCB1+WHjDTCEXko/aeZhK1Ll5uFoaibHO7M9Pnhpmj
	qb4hWWg84LeZmtPbu1zsJrmCOM3jELH7IXjNHkqkpnDuJoqC26j3HMNruhcSsGrpfS7AnidCbQH
	AmGKxY9wX7928LdUJTGHSVrtehJM1xUwaAWhdDRX+aW+yZpvidF
X-Received: by 2002:a05:600c:5288:b0:490:e5c1:b8bf with SMTP id 5b1f17b1804b1-499aa1ea46dmr228459585e9.13.1787220848633;
        Thu, 20 Aug 2026 03:14:08 -0700 (PDT)
Message-ID: <df901857-d12e-4173-a6a8-feca1604d95f@suse.com>
Date: Thu, 20 Aug 2026 12:14:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/hvm: Use system descriptor type names in
 hvm_task_switch()
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260820091740.2006909-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260820091740.2006909-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787220849-6ECCB4E9-55AC5E44/0/0
X-purgate-type: clean
X-purgate-size: 220

On 20.08.2026 11:17, Andrew Cooper wrote:
> ... rather than magic numbers.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 10:35:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 10:35:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396294.1634232 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx06r-0001A3-BX; Thu, 20 Aug 2026 10:34:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396294.1634232; Thu, 20 Aug 2026 10:34:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx06r-00019w-8j; Thu, 20 Aug 2026 10:34:57 +0000
Received: by outflank-mailman (input) for mailman id 1396294;
 Thu, 20 Aug 2026 10:34:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <freddy77@gmail.com>) id 1wx06q-00019q-B2
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:34:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx06o-005WJ9-W5
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:34:54 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a86d844-e002-0a2a0a5209dd-0a2a4506892a-18
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:34:54 +0200
Received: from [74.125.224.47] (helo=mail-yx1-f47.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <freddy77@gmail.com>)
 id 6a86d84c-195a-0a2a45060019-4a7de02fd95e-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:34:53 +0200
Received: by mail-yx1-f47.google.com with SMTP id
 956f58d0204a3-66ca4bdccfaso3310435d50.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 03:34:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787222092; cv=none;
        d=google.com; s=arc-20260327;
        b=TwSiG+yHbfokcF8kPYE4ik5LMM3m9fVdP8SCZGHnPXMlmSVZNrn4rOjeQMpeF/Ehoi
         v+uXSE+2T/YXmOZM/J+1/qJm6drqIJSIdV4tEhErHzUHr/ob09TUl3aRyMU94lRFUIoE
         qrq3fzNJ/SA86suRtGx7VC1XJZwXntyrNmcMok3AMQWUuzFvQmIuyCmDcJcd+oEmaKgY
         yaDcAOnhGYnWUwKjJItLUcty7onBx9H9ZgjDSFz472f/S40YfQ6H4soITjG8ZtzI/7rE
         qeqRkiY1spxGRmONZfyqjQEN3a0zUMaFZUiLX7ez335oq9G346n00fyLWqKEcJ7Kxc1j
         QQoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=An0sPUB5AiII25/KlxNXPAXPhP53SdMwGLmRrNvZ+1A=;
        fh=3EhnpfHPRgJlkI2QNmIe5wJuq7CmX80ySFM1Q7ZfFu0=;
        b=JvOVhUMzN2DRWpzvmMSdJiQgzMWyhob8x7TOm0q2T3y7bwkSy1h4r8W/Y39esBzhF5
         lriaqUAz5nSmfHDEvoXCPolgIaokxUVx1uuSUeBxruEYEREGPA9WO5emddmVWmoKAx9E
         L0v2y/g29I1QpfwTcTXzgYZ9vfTl1wb3guLhL+v3zQPDymkwTiiBU+wPDvQ4g9kvh17b
         S9canSxs1+rpw4L5wByEJPt4dtL9VpdcDC7iWJcT+ZY72aBVkloR+mZqx74B58t2svsp
         XDVn/v2yZJWYvNXQ5oRa+rpwnglpeQcetZC9xYr0QM5hdjQF9QDS0BZi0wbXugfF8/3f
         XwhQ==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787222092; x=1787826892; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to:content-type;
        bh=An0sPUB5AiII25/KlxNXPAXPhP53SdMwGLmRrNvZ+1A=;
        b=IT3+cvPuPdu3wG17YSG3eU7Kr/7xEM3kUfyW3y2jywfVLhNfNGw1oOdLouVcSbJmcg
         IBcqEMbdKhJq5cqSxHbwUAs7vZEausrKsytciweoRggdsTaSYIL4Gr28ut+9kRPD+Agc
         kvMfWBIsR6WfFDMWADcznsA/eU0KJ0IuoOJejOkA+YMK9hv6nZhKKGVzTPCSxQNud3gZ
         DFgXc5r4sdxER4q5E6Ax5Hh03EPU2sN5WyTbavne72I5w6Z3/wfOHaHEyQG+Mt1hBgN6
         gGyGUIXFAdQ1DoZy8I+F+0UflBkJgZWieIYZeGVgxtLCV3nJl7pG7rk4ecY0x+Xji15/
         Jfrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787222092; x=1787826892;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=An0sPUB5AiII25/KlxNXPAXPhP53SdMwGLmRrNvZ+1A=;
        b=EZktn90qE+5mfOLkmlUiJKRDd6lbdcvcb6crZv6htjydM4GGHPee6uEC6gfEmadW3d
         Sg3GT+HqDg6PMDA4v8QqH6shw0khZjp7PdPk0fI2nWt+G6evVsex47Ne4O8TynpaeJo6
         Ib5ACtONAEigYAvVbCnGYkS8OOf5TFyMmDwIFuzz/BHVHXQcO0LHhq1/VMAglR24FZBD
         haZVWVbaD/5jYWvBPJUX38QQg0IgiRPnbHrqMvP5V5BsEGQNU6Y3pGBTpI9OMYY38YId
         cO5ZbWCbL9ugAT5oVjKmBW4SaNihpD5vtR238hiKZ16yLPh8/fEC8xvqEW4jvxpjIU6/
         Q64Q==
X-Forwarded-Encrypted: i=1; AHgh+Rq4avPkX7g5eN5rdlHhj5JaNoUf7AWG6Qnnwpb8thnzlAenFakQjlPK/zMSkPaBuoMpWNAcHstOhTc=@lists.xenproject.org
X-Gm-Message-State: AFuF++mCzEHAvO5uUJvUASdUzzCfUsSHsEp2ufVvQYfuGgpS1Hra+QZj
	Bm7CaIv84gou2NsQLPZKcP+hLkNVE8oaurt6uaJ14i9iaK2Udy63wSs7ufILfNf4fZYi6sRd02I
	Or7CsmPFXmkTRi8HjblnBLeJ1UKxiZ5c=
X-Gm-Gg: AR+sD139i0MeRoivWRRiCcl+rMXATBxM5Nj+pqj9MB4M64law+/E+0rtwnOuYnXxlVO
	X2kA/t5zItnUZvdio+mce/f/k6MjAU1k1MtZl31tXDXhkYwQO6Of4M2hkrTdxLBW2MfoPultloQ
	PtnXwfIJoZO5fQO/Jxu4C3HXbG2nCnK+T/+GrvbWDblQx63ByryFFqp23f7OrwKQn97lwm98nDw
	LJGlGjNo0r3Y3F/TH29mKTBcDx5lrQ1+7hZ3cynJtyzlp5w/XppGww4Z7anQV+cHzOf0YUDSkth
	08rNXyfrULe/BK8PtwOwYLfQq8EUzA1ZMX3IguY4u28HJ2yQd35KXS3aZZlXY92TKi+/qgnLgxI
	HOOArb0A8AOY=
X-Received: by 2002:a05:690e:bcd:b0:66c:df0d:ef0d with SMTP id
 956f58d0204a3-66cdf0df0cdmr333564d50.28.1787222091588; Thu, 20 Aug 2026
 03:34:51 -0700 (PDT)
MIME-Version: 1.0
References: <20260715062206.328049-1-frediano.ziglio@citrix.com>
 <CAHt6W4cG_-=8MBJ+7dWQrLuC2Lf-fLOHDUyGwWDGQn6=9bO1Lw@mail.gmail.com>
 <CAHt6W4fFYs8fMUFer2oRL67voM_NbwtFbD=fJxFiQ5g0cujsMA@mail.gmail.com> <559e68bb-1689-456b-89a5-0a39d3bb3afd@suse.com>
In-Reply-To: <559e68bb-1689-456b-89a5-0a39d3bb3afd@suse.com>
From: Frediano Ziglio <freddy77@gmail.com>
Date: Thu, 20 Aug 2026 11:34:39 +0100
X-Gm-Features: AcwNN1UIErS0I9ozgaITjWV8kD1BmoKLw4ai2AlF9Gma-dT5IUNXkTII1bh_hY0
Message-ID: <CAHt6W4f22gHSiWLz-qvWQT33jmM0_mnwKJCyKXqnG05rGBQs2g@mail.gmail.com>
Subject: Re: [PATCH v8 0/4] Various patches to improve Secure Boot support
To: Jan Beulich <jbeulich@suse.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, "Daniel P. Smith" <dpsmith@apertussolutions.com>, 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= <marmarek@invisiblethingslab.com>, 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-16d1c6/1787222093-F6A7477B-6662CDE6/0/0
X-purgate-type: clean
X-purgate-size: 2591

On Wed, 19 Aug 2026 at 11:12, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 19.08.2026 12:03, Frediano Ziglio wrote:
> > On Sat, 8 Aug 2026 at 07:41, Frediano Ziglio <freddy77@gmail.com> wrote=
:
> >>
> >> On Wed, 15 Jul 2026 at 07:22, Frediano Ziglio <freddy77@gmail.com> wro=
te:
> >>>
> >>> These patches improve support for Secure boot.
> >>> UEFI CA memory mitigation requires memory pages to be not executable =
and
> >>> writable at the same time. So changing permissions and splitting some=
 section
> >>> is required.
> >>> Remove multiboot pieces from EFI executable.
> >>>
> >>> Changes since v1:
> >>> - improved some comments;
> >>> - merged 2 pacthes removing multiboot support in x86 PE;
> >>> - removed a patch dealing with SBAT;
> >>> - other minor changes (see single patches).
> >>>
> >>> Changes since v2:
> >>> - improved some comments.
> >>>
> >>> Changes since v3:
> >>> - Added Acked-by;
> >>> - Improve commit message.
> >>>
> >>> Changes since v4:
> >>> - Messages updates;
> >>> - Clean some dependencies cause by code removal;
> >>> - Add small commit to remove a possibly unused string.
> >>>
> >>> Changes since v5:
> >>> - removed merged commit;
> >>> - remove more code/data from xen.efi output.
> >>>
> >>> Changes since v6:
> >>> - fix commit message.
> >>>
> >>> Changes since v7:
> >>> - added Acked-by, all commit are now acked.
> >>>
> >>> Frediano Ziglio (2):
> >>>   Align relevant sections to 4KB
> >>>   x86: Split .init section to satisfy UEFI CA memory mitigation
> >>>
> >>> Roger Pau Monn=C3=A9 (2):
> >>>   x86/efi: discard multiboot and PVH support for PE binary
> >>>   x86/efi: avoid a relocation in efi_arch_post_exit_boot()
> >>>
> >>>  docs/hypervisor-guide/x86/how-xen-boots.rst |  6 -----
> >>>  xen/arch/x86/boot/head.S                    |  8 +++----
> >>>  xen/arch/x86/efi/efi-boot.h                 |  7 ++++--
> >>>  xen/arch/x86/xen.lds.S                      | 25 ++++++++++++-------=
--
> >>>  xen/tools/combine_two_binaries.py           |  2 +-
> >>>  5 files changed, 25 insertions(+), 23 deletions(-)
> >>
> >> Ping
> >
> > Ping
>
> Andrew had indicated to me (apparently not to you?) that he'd like to
> massage the descriptions some while committing. Hence why I refrained
> from putting any of this in.
>
> Jan

I understand maybe we want better comments and explaining what's
missing/improvable could take more time than updating them directly,
but how many months does this require?
Especially after the changes had different acks.

Frediano


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 11:44:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 11:44:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396316.1634241 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1Bt-0001lI-Ut; Thu, 20 Aug 2026 11:44:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396316.1634241; Thu, 20 Aug 2026 11:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1Bt-0001lB-Rt; Thu, 20 Aug 2026 11:44:13 +0000
Received: by outflank-mailman (input) for mailman id 1396316;
 Thu, 20 Aug 2026 10:47:57 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sshegde@linux.ibm.com>) id 1wx0JR-00031J-5x
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 10:47:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx0JQ-00EwfZ-Iy
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:47:56 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sshegde@linux.ibm.com>)
 id 6a86db51-bab6-0a2a0a5309dd-0a2a4509bdb2-20
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:47:56 +0200
Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sshegde@linux.ibm.com>)
 id 6a86db5b-be1a-0a2a45090019-94a39e05f278-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 12:47:56 +0200
Received: from pps.filterd (m0360072.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67K8psXX503930; Thu, 20 Aug 2026 10:46:59 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g4yu49j7t-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 20 Aug 2026 10:46:58 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67KAfGvU024130;
 Thu, 20 Aug 2026 10:46:57 GMT
Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4g354ynsek-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Thu, 20 Aug 2026 10:46:57 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com
 [10.20.54.101])
 by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 67KAktPu46072234
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 20 Aug 2026 10:46:55 GMT
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 7A9FA20043;
 Thu, 20 Aug 2026 10:46:55 +0000 (GMT)
Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id D8EA120040;
 Thu, 20 Aug 2026 10:46:41 +0000 (GMT)
Received: from [9.39.17.85] (unknown [9.39.17.85])
 by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP;
 Thu, 20 Aug 2026 10:46:41 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=pp1; bh=czT1Im
	PU/vWc2M0tWEKBT0LXpRCVrV75Wfn03rEOF2c=; b=VFp46JEphllpw7qtyJNBx1
	CaVenj+Rdg6kMHAyun/leFK4fPjzBLdY43BTvCm0r20SF8NRJ17NDVEUINVxkX2f
	dujD0NQz3qQ7m0zO3xs9P02S1kxeSEsGvFiTkyy71sDmPCa47W0q7/Nr0em6wVhf
	Th7I4886yY9Ww8KFAZ/sulpfpgo8txaPaUjtuFOn/paI7hzL53leG67MGZ8+i0Am
	LsOim3vbqCPgz/COWWYtl/xy5PayeZbfKOR8IGLm1tbqtfbmwIGP5JExMBBiTmKX
	i7W3MfpeOJdrbuMa+UQRiYtW19e6zAq56CFWAMf3KMWfswNDkwVI+e5cosZ43Txw
	==
Message-ID: <99bdc3e0-0e0f-4cb1-8747-dd7667307492@linux.ibm.com>
Date: Thu, 20 Aug 2026 16:16:40 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH RESEND] sched: Convert paravirt_steal to new static key
 APIs
To: Hongyan Xia <hongyan.xia@transsion.com>
Cc: Jiazi Li <jiazi.li@transsion.com>,
        "virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
        "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        Juergen Gross <jgross@suse.com>, Ajay Kaher <ajay.kaher@broadcom.com>,
        Alexey Makhalov <alexey.makhalov@broadcom.com>,
        Broadcom internal kernel review list
 <bcm-kernel-feedback-list@broadcom.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>,
        WANG Xuerui <kernel@xen0n.name>,
        Madhavan Srinivasan <maddy@linux.ibm.com>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Nicholas Piggin <npiggin@gmail.com>,
        "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
        Paul Walmsley <pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>,
        Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>, Ben Segall <bsegall@google.com>,
        Mel Gorman <mgorman@suse.de>, Valentin Schneider <vschneid@redhat.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>
References: <20260819081207.12150-1-hongyan.xia@transsion.com>
Content-Language: en-US
From: Shrikanth Hegde <sshegde@linux.ibm.com>
In-Reply-To: <20260819081207.12150-1-hongyan.xia@transsion.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-Proofpoint-Reinject: loops=2 maxloops=12
X-Authority-Analysis: v=2.4 cv=CpuPtH4D c=1 sm=1 tr=0 ts=6a86db23 cx=c_pps
 a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=3xJz9W2bAAAA:8
 a=VnNF1IyMAAAA:8 a=iox4zFpeAAAA:8 a=xzwhdZQ7njCJ2XY4-I0A:9 a=QEXdDO2ut3YA:10
 a=amiGZ1mxdzcEAW_x1qlF:22 a=WzC6qhA0u3u7Ye7llzcV:22
X-Proofpoint-ORIG-GUID: 1wZ5c2qM7g5x0jx-qb5t7EiwBQISCVhp
X-Proofpoint-GUID: itVss8-eLfuaCICc2HK-kMCuGgzSwFvE
X-Proofpoint-Spam-Info: AW1haW4tMjYwODIwMDA3NyBTYWx0ZWRfXy1Knef7euqva
 B2wMTxAUFMf0GbqrSemw+AgaY+wNIewR8/vNhiPmdrebwSaAtFgbUClfT7lyMMabKF1jdmhCukv
 nr1v7az3rtSi3DUGh3ib1xdiKCYVnZg=
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODIwMDA3NyBTYWx0ZWRfX60/6Dl3nOmKx
 1lgDs9d2yIy0QyPoRMAQMzaFP01pLEWEulDqKdCZ3F6qDr3NEiEADGM2eMQnstQbmSYnYcBwNjK
 hYFPSUus//RGGLcarRg+E6axxBj3cxk7gBG2T8OjN97OxqZ9rI5pI4vUVXhXILTmckLXOi9a4I3
 MoyHW222X4NoFlq4ynf22eXvKMiPfG/Xu4Q7UUfJRau6RKD4izhXUGu12jnr6O8gXDaA3aZRAOx
 MuuA52c8OIb1esLmNTU4vQce+tqTAWrEo6EbROCul8IF1KNHGDNf/cl8nGs/R4mOfrjSsH3UgUC
 QEfOV3KYChX2RlYM8p6C+EHa7k7heWKVeKCTp/8zCebWTMfdNHtOjUgI9gRkWPhGSC2OMKPO5sR
 VflLI0qnlEsop/LaVZCG8Y9aXymFW6vJu2Q1kpkLrY+WSbBzqGsJpBBazuvASI6CZb6TNG/I2Gs
 KijXc6TfURnVr9wKn/w==
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-19_06,2026-08-19_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 impostorscore=0 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0
 lowpriorityscore=0 spamscore=0 clxscore=1011 priorityscore=1501
 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608200077
X-purgate-ID: tlsNG-bad1c0/1787222876-39EC6034-9C925B3F/0/0
X-purgate-type: clean
X-purgate-size: 8262

Hi Hongyan.

On 8/19/26 1:42 PM, Hongyan Xia wrote:
> From: Hongyan Xia <hongyan.xia@transsion.com>
> 
> paravirt_steal_rq_enabled and paravirt_steal_enabled use raw static_key
> APIs which are now deprecated. Use the new API instead.
> 
> No functional change.
> 

FWIW, looks good to me. One minor nit.

Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>

> Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
> Acked-by: Juergen Gross <jgross@suse.com>
> ---
> Changed in RESEND:
> - Separate the original series into individual patches. They aren't easy
>    to review as a series.
> 
>   arch/arm64/kernel/paravirt.c           | 4 ++--
>   arch/loongarch/kernel/paravirt.c       | 4 ++--
>   arch/powerpc/platforms/pseries/setup.c | 4 ++--
>   arch/riscv/kernel/paravirt.c           | 4 ++--
>   arch/x86/kernel/cpu/vmware.c           | 4 ++--
>   arch/x86/kernel/kvm.c                  | 4 ++--
>   drivers/xen/time.c                     | 4 ++--
>   include/linux/sched/cputime.h          | 6 +++---
>   kernel/sched/core.c                    | 4 ++--
>   kernel/sched/cputime.c                 | 4 ++--
>   10 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
> index 572efb96b23f..30bf61d031eb 100644
> --- a/arch/arm64/kernel/paravirt.c
> +++ b/arch/arm64/kernel/paravirt.c
> @@ -157,9 +157,9 @@ int __init pv_time_init(void)
>   
>   	static_call_update(pv_steal_clock, para_steal_clock);
>   
> -	static_key_slow_inc(&paravirt_steal_enabled);
> +	static_branch_inc(&paravirt_steal_enabled);
>   	if (steal_acc)
> -		static_key_slow_inc(&paravirt_steal_rq_enabled);
> +		static_branch_inc(&paravirt_steal_rq_enabled);
>   
>   	pr_info("using stolen time PV\n");
>   
> diff --git a/arch/loongarch/kernel/paravirt.c b/arch/loongarch/kernel/paravirt.c
> index 10821cce554c..e8965a3f8082 100644
> --- a/arch/loongarch/kernel/paravirt.c
> +++ b/arch/loongarch/kernel/paravirt.c
> @@ -308,10 +308,10 @@ int __init pv_time_init(void)
>   
>   	static_call_update(pv_steal_clock, paravt_steal_clock);
>   
> -	static_key_slow_inc(&paravirt_steal_enabled);
> +	static_branch_inc(&paravirt_steal_enabled);
>   #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
>   	if (steal_acc)
> -		static_key_slow_inc(&paravirt_steal_rq_enabled);
> +		static_branch_inc(&paravirt_steal_rq_enabled);
>   #endif
>   
>   	if (static_key_enabled(&virt_preempt_key))
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index 1223dc961242..8dcbc4bb7025 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -852,9 +852,9 @@ static void __init pSeries_setup_arch(void)
>   			static_branch_enable(&shared_processor);
>   			pv_spinlocks_init();
>   #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
> -			static_key_slow_inc(&paravirt_steal_enabled);
> +			static_branch_inc(&paravirt_steal_enabled);
>   			if (steal_acc)
> -				static_key_slow_inc(&paravirt_steal_rq_enabled);
> +				static_branch_inc(&paravirt_steal_rq_enabled);
>   #endif
>   		}
>   
> diff --git a/arch/riscv/kernel/paravirt.c b/arch/riscv/kernel/paravirt.c
> index 5f56be79cd06..9c13a6f1ea2a 100644
> --- a/arch/riscv/kernel/paravirt.c
> +++ b/arch/riscv/kernel/paravirt.c
> @@ -116,9 +116,9 @@ int __init pv_time_init(void)
>   
>   	static_call_update(pv_steal_clock, pv_time_steal_clock);
>   
> -	static_key_slow_inc(&paravirt_steal_enabled);
> +	static_branch_inc(&paravirt_steal_enabled);
>   	if (steal_acc)
> -		static_key_slow_inc(&paravirt_steal_rq_enabled);
> +		static_branch_inc(&paravirt_steal_rq_enabled);
>   
>   	pr_info("Computing paravirt steal-time\n");
>   
> diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
> index 34b73573b108..f7ab9e7902cf 100644
> --- a/arch/x86/kernel/cpu/vmware.c
> +++ b/arch/x86/kernel/cpu/vmware.c
> @@ -328,9 +328,9 @@ static int vmware_cpu_down_prepare(unsigned int cpu)
>   static __init int activate_jump_labels(void)
>   {
>   	if (has_steal_clock) {
> -		static_key_slow_inc(&paravirt_steal_enabled);
> +		static_branch_inc(&paravirt_steal_enabled);
>   		if (steal_acc)
> -			static_key_slow_inc(&paravirt_steal_rq_enabled);
> +			static_branch_inc(&paravirt_steal_rq_enabled);
>   	}
>   
>   	return 0;
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index dcef84da304b..d3dcd64f22c2 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -1052,9 +1052,9 @@ const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>   static __init int activate_jump_labels(void)
>   {
>   	if (has_steal_clock) {
> -		static_key_slow_inc(&paravirt_steal_enabled);
> +		static_branch_inc(&paravirt_steal_enabled);
>   		if (steal_acc)
> -			static_key_slow_inc(&paravirt_steal_rq_enabled);
> +			static_branch_inc(&paravirt_steal_rq_enabled);
>   	}
>   
>   	return 0;
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index a2be0a4d45b0..a02d48a2aa68 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -169,7 +169,7 @@ void __init xen_time_setup_guest(void)
>   
>   	static_call_update(pv_steal_clock, xen_steal_clock);
>   
> -	static_key_slow_inc(&paravirt_steal_enabled);
> +	static_branch_inc(&paravirt_steal_enabled);
>   	if (xen_runstate_remote)
> -		static_key_slow_inc(&paravirt_steal_rq_enabled);
> +		static_branch_inc(&paravirt_steal_rq_enabled);
>   }
> diff --git a/include/linux/sched/cputime.h b/include/linux/sched/cputime.h
> index e90efaf6d26e..694126411dfe 100644
> --- a/include/linux/sched/cputime.h
> +++ b/include/linux/sched/cputime.h
> @@ -182,9 +182,9 @@ extern unsigned long long
>   task_sched_runtime(struct task_struct *task);
>   
>   #ifdef CONFIG_PARAVIRT
> -struct static_key;
> -extern struct static_key paravirt_steal_enabled;
> -extern struct static_key paravirt_steal_rq_enabled;
> +#include <linux/jump_label.h>

nit:

This looks bit odd to see includes in the middle. I know it is including
only if necessary.
maybe worth an unconditional include in the beginning?

> +DECLARE_STATIC_KEY_FALSE(paravirt_steal_enabled);
> +DECLARE_STATIC_KEY_FALSE(paravirt_steal_rq_enabled);
>   
>   #ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
>   u64 dummy_steal_clock(int cpu);
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 5c07d53e43b5..84d090581a08 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -795,7 +795,7 @@ struct rq *_task_rq_lock(struct task_struct *p, struct rq_flags *rf)
>   
>   /* Use CONFIG_PARAVIRT as this will avoid more #ifdef in arch code. */
>   #ifdef CONFIG_PARAVIRT
> -struct static_key paravirt_steal_rq_enabled;
> +DEFINE_STATIC_KEY_FALSE(paravirt_steal_rq_enabled);
>   #endif
>   
>   static void update_rq_clock_task(struct rq *rq, s64 delta)
> @@ -834,7 +834,7 @@ static void update_rq_clock_task(struct rq *rq, s64 delta)
>   	}
>   #endif
>   #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
> -	if (static_key_false((&paravirt_steal_rq_enabled))) {
> +	if (static_branch_unlikely(&paravirt_steal_rq_enabled)) {
>   		u64 prev_steal;
>   
>   		steal = prev_steal = paravirt_steal_clock(cpu_of(rq));
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 06bddaa738e5..f16970ca81d0 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -255,7 +255,7 @@ void __account_forceidle_time(struct task_struct *p, u64 delta)
>    * occasion account more time than the calling functions think elapsed.
>    */
>   #ifdef CONFIG_PARAVIRT
> -struct static_key paravirt_steal_enabled;
> +DEFINE_STATIC_KEY_FALSE(paravirt_steal_enabled);
>   
>   #ifdef CONFIG_HAVE_PV_STEAL_CLOCK_GEN
>   static u64 native_steal_clock(int cpu)
> @@ -270,7 +270,7 @@ DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
>   static __always_inline u64 steal_account_process_time(u64 maxtime)
>   {
>   #ifdef CONFIG_PARAVIRT
> -	if (static_key_false(&paravirt_steal_enabled)) {
> +	if (static_branch_unlikely(&paravirt_steal_enabled)) {
>   		u64 steal;
>   
>   		steal = paravirt_steal_clock(smp_processor_id());



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 11:47:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 11:47:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396361.1634249 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1FC-0002Jn-DA; Thu, 20 Aug 2026 11:47:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396361.1634249; Thu, 20 Aug 2026 11:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1FC-0002Jd-Ad; Thu, 20 Aug 2026 11:47:38 +0000
Received: by outflank-mailman (input) for mailman id 1396361;
 Thu, 20 Aug 2026 11:47:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wx1FA-0002JV-Tl
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 11:47:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx1F9-000A1t-TJ
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:47:35 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a86e942-8faa-0a2a0a5109dd-0a2a4507de7e-26
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 13:47:35 +0200
Received: from [98.137.68.205] (helo=sonic304-24.consmr.mail.gq1.yahoo.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a86e955-b4ea-0a2a45070019-628944cda295-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 13:47:35 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Aug 2026 11:47:33 +0000
Received: by hermes--production-ne1-6dbcb84f44-s2v5v (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 05be46735015b05d69f7fafd25a3fb31; 
 Thu, 20 Aug 2026 11:47:28 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787226453; bh=+5d7AXa171OJ5dCFJA/kzsOo57trTNuDzCDddNQRDSs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=YhXHa4yIXFkIUn5D7ALa0kF23LKD0NMA9xEKV9E1JwM7PMfNogzCYhl9uInPWtUMV8tPG28fbSvyIPOz4TRLAf32a54eXzZGXGujXfWmk6PDpPv8KrfebTjdLAZH7mNv8hu5UII10/l4iU6CZy0EyPbVCAvcDuK+pGcrpvmGG/gTP5Fdd3GuieTptn/fU998G2uEisWniYbgEk3aIV+6G1PCDRvMSPNiEcaXRoPqhygPzZbi0ulSJIh2dRt9EvnPB6Pej/I4Kh+1V65FzahFPPPZ/VfVOgDuNVpziTab8T8ZwVLeVarZuA7i9aC2vMZqLjl7q2y3mzHU94PehhvqJw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787226453; bh=cboGAWkQw2RHs/mc7qoC16boWmdtbzQ7JsaGLyaSP1h=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=TSK6RyH+M5Uqmd2PNjyMnY2wHeHsev2R82cGooSaeyh3k5Ti6POleiu6vhSsJ+a9WXiMz+Oy/yzH85ex74QckDrJ3HefeZ31e71Brfh8rBLW8DVeo+KCqKw1nvkDOqnLHiK4XqxZx7Sti8QxR9G2z4dut/lu2HmzJkwAm4JVFhicfdtfmIGEEN7sWOvYVfIzeDZylMPn8Qaq1/ZTyuyAcbr0pbPqthuUrioUpYJr2YK29/ekTESF5oJ1iznOUDCtQ+aaAei0z1TiTC24uawzoeRvZp27s5/Fw45HkBthLsKRPtxPXTDInoSuG1FQlFpOH99YgPpgz2GwUoNXs2jDvA==
X-YMail-OSG: GB7pZAUVM1mKxvBYwiVVEQClL7phZxOtEowzSykRFZ_SNvou9Pooum6eEVCtvST
 KR99QwhKJYRm8St16heiflFZSUwXclnywRhdFuanNGA8AgCKEhsBXKfpTbgYSVBZsxJ2K.VCTqZF
 aFEa1Z20LBmIixLlp5ggTOawykJ8ogUxwH_a78P0y9Nk3nmbdXmtj7w2MOh.qPo0TS5ter5E0AGj
 k_Tc7TXE5hSSaMBBUhOSW3P33Vgp8NvzcctRbS3_aYb9.Z9OrKXeCM_ZaMDBNl6oLqIPgJq1GtDs
 bIxr8xebpfxYWuKZTmfgNBkjQ50jktZRRDQEzU6wH4nL9c3OPErQizw6BpDn2wcud0AiYpe_6zlz
 kLIcEnK1azNIPWfHyDdB3JhwcmjcetU5G3yYBg0H9KJHbIlnmoJoZVA4BDJ2S6lQIbNYTiawzd1Z
 OavVACl.WzCLRss2FxnfmbJ_P4fo6DrJyE1y_8PbwqUUYJpGuG9m44672sEGGkaM0EtcNmHic.Q3
 9vU_z2YFC9gtxjG3GUck7lC22Fdc_D3iKVBuJJRjemKtbIhmM1GFFTtm.6.2Db9FmXedZzzZEZwa
 0rSoa.dG62XXMjETea2j7GOToF8mBw5PguYZfY96kViGASt2Buiikj8v9JeWYZHHAt4mrR9mUJQu
 Un..9C2eGNulEMkqd4Bb53cgBal55rq_1KHjiPLXN8BDPf6_hGR38heeLfBq2Ql1BxxlcPmXGKKL
 TUk.Cyp2Evxshyz65aKiaxezAGbQdq.t7zXUouzEEbPPyuCq2nhVjVj4xe7mqXwFOAPkxZMhmb9x
 qMOUwasjigjX3z06WrZNfqssN.gsbNP_EKXh0fbNDiPaQ949APs0cDqjaz_npMmmDTqK2uoUePVh
 2ux0tfklBQQGNJSHsxFReEeqcxl.bYY2hYyUIu_vS5OgBwQRJVX4S4GlcEj_vAubFSHDrI6Y258C
 aZy00VJvgme9sVWb_2T5OgNHBZgpEjD.t5FfACrGSVUCUaG7tpB9uyP.OfUrA5.l0YbhS_y6p_sm
 TWCCJZubrAtXWM1NBEq2uHmfpvzz0WqkOUqIGeRFz0XKreEquUN0Cb_w6qGiU_QbCXwvKDpMbStb
 t.3OoGz6ymjxRBzgtDzOvHIVSJRJLoVD25KqzllWxwQsYgrEpIpt2DuBgIrvUeyweXy_QmlH7i0P
 6PwkNrPPJYqEsAM9wp8e3vKSwmwtoxVmTVjweCUxx9Jrz8oO_qwyjJ4j6DP9zZHPJJZzjw9hsdme
 Sj33rzt.LB7.eyr4k_7PifYlgaQGOdSPMBajmL2O6ESWjVXD9N4z6P84JcVY0PRkWjfMO2oXWz2O
 yfQh5qwfuI4PbhJO6BH.HAPFEu08I2TzNvUvIhdGqPyv5S2DIkWSTEt0.BVDT66DpeSX_v_TUdMI
 oNT2eMs_r3oDko25jbJOPiKdFR.pBEou4Es.7KcuYRsHblFz.r44GIn8qcQGaoXlKsEKs_coHh5m
 F74Y5I0T1xhbBjOKdNC8TsAnFpmzea_o6AaqBuu0nzMky6yNMtyNQixhpFI5sJoOIiJnaLi35Hrq
 OFYypaLNbIHUcV..jgoxW..5loz.PVmCEdoBMzvh6L9IbB.WdPacq1Gh7CE3waXiq6pUpO.Dg8mS
 9YZgSeMkt0jd45i88.URGhSkcqwQUuPRK1t9f1rePnPsgW1cqNm36Ht0KZJ8dPdUVqieQqt6Qi4Z
 MtSu5T8c8P9I_8g_rPlKrm2Xj_70U1psXtNoPSjT1gH2yrisfA_TrzPRvJ639aPkYSWPzZZcK0wK
 OYbX_KKEpcZ6KgxBOJJTclllvUCf.suBuCcBP5uSHDZLLAp35BzkgZ2OVk497UROZAepLl8yIFYi
 Lw_JXvlDiZx9VkG3dqxLcrkXaFGG5Ae5HedX0RIj1WBVkxm5nuOEDpqR5WdJUNjsYH3y9uh68Cnd
 hxCuLfzPPP7f.1eDbGtfszzJO1rUy11a09tbdCNv2N5CqERbqEbkY4UIMmrDDe_nVStXfcMDWknc
 ZWW6lITEQBIBr6Up.p7KE.9vr8z6TG_gV15evD6Q.LkNhitvkkFXc08J.uTJHUiZbYtP.UyjoyEn
 u_.sXz0VYmJG67ee_FPpp5xMPu5sAsLPrBn_.rumsNbK.payEqqGs0UMq2.hyw.zRrAv_vnk5oCm
 .k3geMXIdcH9o2R0K1970jT8umlw7bEmbaADkkNCJYCOyIW22KdKSR8T576azE3ipshKJfDmU2tN
 QTr0yKgsaVQvTbrlSmqmrBgx4m0km_zUUdej2zJ7qSLVhgA--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: c579781b-b73c-4576-82d6-8f0825eada4c
Message-ID: <fa497825-c8f0-4caf-94f5-b37108e31952@aol.com>
Date: Thu, 20 Aug 2026 07:47:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
 <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 8345
X-purgate-ID: tlsNG-ef75cf/1787226455-A68D9AE4-90F4785A/0/0
X-purgate-type: clean
X-purgate-size: 8479

On 8/20/2026 3:51 AM, Jan Beulich wrote:
> On 19.08.2026 19:13, Chuck Zmudzinski wrote:
>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>> about avoiding the layering violation than anything else.
>>>>
>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>
>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>> in hvmloader?
>>>
>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>> screw up that data such that subsequent guests won't work anymore. Hence
>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>> restricted DM as well.
>>>
>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>> treatment.
>> 
>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>> it functions more or less like a BAR region with the devices's ASLS register
>> at offset 0xfc in the PCI device config space of the device acting like the
>> BAR for that region.
> 
> That is, on real hardware a write to that register moves the OpRegion? That
> would need following by the DM then, i.e. the DM would need to indicate the
> original position in the register, and the guest (incl hvmloader) would
> then be free to relocate it.

Why would that "need following by the DM" when the register in the guest is
fully emulated, [1] which means that when the guest (incl hvmloader) writes to the
register, the register on the real hardware is not touched, nor is the OpRegion
in the host address space moved?

Here is how I understand how this works in the current implementation and how
this should be done:

Intel's spec (an old version of it that does not yet define the rvda and rvds
fields) is available online. [2] What that spec says (it is for skylake processors,
released c. 2015 IIRC) is that the ASLS register is a write once register. The
system firmware is to place the OpRegion into memory anywhere below the 4 GiB limit
(because it is a 32-bit register) and mark it as type ACPI NVS memory in the E820 map,
and write once to that register the location of the OpRegion in the address space.
The spec says that from then on it is read-only for the OS graphics driver to consume.

When the IGD is passed through to a Xen HVM guest in the current implementation,
all 32 bits of the ASLS register are emulated from the guest's point of view. That
is, when the guest (hvmloader or seabios/ovmf) writes to it, the register on the
host (i.e. the register on the real, physical hardware) is not touched at all, nor
is the OpRegion moved in the host address space. I am fairly certain this setup of
having the ASLS register emulated is not specific to Qemu but applies to all DMs
that are to interface with the current implementation in hvmloader, because in
hvmloader we have this comment in tools/firmware/hvmloader/pci.c:

                    /*
                     * Write the the OpRegion offset to give the opregion
                     * address to the device model. The device model will trap 
                     * and map the OpRegion at the give address.
                     */

What does it mean to say the device model will trap? I think it means the
device model is to emulate all 32 bits of the ASLS register which will leave
the position of the OpRegion in the host address space unchanged and the ASLS
register on the real hardware untouched.

So, hvmloader need not need know the position of the OpRegion in the host address
space since the DM maps the host OpRegion into the guest address space at the
location it is to be accessed at in the guest. That is what the current
implementation in hvmloader presumes the DM will do, as evidenced by the comment
from hvmloader code quoted above, and it is also exactly what Qemu currently does.
Indeed, it is clear that in the current implementation, the host OpRegion address
is not disclosed to the guest (hvmloader) and the guest is able to access the host
OpRegion without knowing the OpRegion address in the host. That is my understanding
of how the current implementation works.

Now, we are proposing that the DM should expose a copy of the OpRegion to the
guest instead of mapping the host OpRegion into the guest address space. Even with
such a change from the way it is done now, hvmloader still need not know where the
OpRegion is on the host as long as the DM remains responsible (as it is in the current
implementation) for making the copy of the OpRegion for the guest accessible to the
OpRegion at (or near, because currently the address hvmloader writes to the register
is just a hint because the DM adds the offset from the page boundary to the address
in the current implementation) the address hvmloader has requested.

I think there are multiple ways for the DM to do this. It could place the copy of the
OpRegion into the guest memory at or near the address hvmloader requested without
disclosing the address of the OpRegion on the host. It could place the copy of the
OpRegion into the DM domain's memory and grant the guest access to it using grant tables.
There are probably also other ways to do it. IIUC, if the DM uses grant tables, it
would not need to disclose the address of the OpRegion in the host address space to
hvmloader.

There are even more options to accomplish this. For example, in a previous comment
you suggested that perhaps the DM should place a copy of the OpRegion *before* the
guest (hvmloader) ever gains control. I noted that would require making the spec
for how hvmloader computes the position the OpRegion will be at in the guest address
space public, and in that case the DM would compute the correct guest address
for the guest and place the suitably patched copy of the OpRegion into guest memory
at the correct address for the guest and program the ASLS register with the correct
guest address.

In this case, the patch to hvmloader would add a read of the ASLS register which
will allow hvmloader to determine, for example, if more space is needed in the E820
map to accommodate an extended VBT and adjust the E820 map appropriately, and also
in that case the device model would ignore any write that hvmloader currently does
to that register because in this case, the DM has already programmed the register
with the correct address.

So with all the different options about how to do this, my head is spinning and
since with your comments you are confusing me about what approach you think is best,
I cannot at the present time write v3 of this patch. What I need is for you or one
of the other maintainers of hvmloader to *make a decision* about how support for
extended VBT is to be added to the Xen platform. I think I have given you and the
other maintainers enough information to make a decision about how best to add support
for the extended VBT to the Xen platform. I understand it may take some time for
you to process all this information and make the decision, but at the present time
we seem to just be going around in circles discussing this, which is not really the
best use of either your time or my time.

Chuck

[1] The specification for how PCI config space registers are programmed for emulation
    vs. passthrough, please refer to the official PCI specification.
[2] https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:31:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:31:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396420.1634259 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1vK-0000Gj-NZ; Thu, 20 Aug 2026 12:31:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396420.1634259; Thu, 20 Aug 2026 12:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1vK-0000Gc-Kl; Thu, 20 Aug 2026 12:31:10 +0000
Received: by outflank-mailman (input) for mailman id 1396420;
 Thu, 20 Aug 2026 12:31:09 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrewprecious388@gmail.com>) id 1wx1vI-0000GW-RI
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:31:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx1vI-008oRc-7m
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:31:08 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a86f385-bab6-0a2a0a5309dd-0a2a450cade6-22
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:31:08 +0200
Received: from [209.85.160.44] (helo=mail-oa1-f44.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a86f38a-f479-0a2a450c0019-d155a02cd5cd-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:31:07 +0200
Received: by mail-oa1-f44.google.com with SMTP id
 586e51a60fabf-455ee8f529dso626033fac.1
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 05:31:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787229066; cv=none;
        d=google.com; s=arc-20260327;
        b=QIdj+bE476VI3x+OxJh16CHQH5BDL1e+kEQjZbeZuzzpSbWN8iUfwRnnlJ/SMHLKd4
         kZrFinutnRqKkAAMc6muaLVz5iDUt6nvfn160J6YJAxCZGyWW7Tc7pSsUp+xa7O5aoBt
         uqiOsn5P1T/+dquBRFE8ewMBcwa4K59L+O0kDjcGT1pRjFIsbu/YhV2kY+IXMZluCmjD
         THPl8JVNwYSFEg7kOq6uJUJi7WI2uU9mP8lZ7ffr3wcssyLjlKWbN5SRwBUa+aogcFVA
         Ujl7sdxKUqWnLpvGkvyqiOA+IP0kYX8OYodHlMEtRIDJfiS4gaSknQEVmmUoFjo4IduM
         NFbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=DyoPHkPnAOZXaz2MqkVz3ixLJR2/aJEGGzymEm6TGRU=;
        fh=0wl/d2rnHFQXb5nvII1Ro/XhFZih03CHbsnnp7ptCWs=;
        b=hNlwSI1ofsbwXWFkVTh4RgMPhb96hSPufoZsBZyKovlTIJMDJpXqOZaLwuNB9v9TA2
         /sdVmUKS6gq8WWDgr63n4fQzmQnMgombBMyLpVcgCxqPCe5IK/XtS9lmae4/eqEPGXm4
         Tskh4YDmGdBt5/2cyQh/uVcoFq0H2S4bS4EYEuygPGGczDGMhBlm3LXKpIRuhOvUUr5l
         U2vccnDh64GBh38AL6ml/YFuU8mQx/sxokhsBP01zbknbaz+bkqxq+mw/f690hxalb5O
         rAmEo+YxdbhWX2VeQXkt/WDoW7dlgUxIM9H+JH0sdmDLq3QCkMv0KvH18jiDWwTqEfVN
         x3bg==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787229066; x=1787833866; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=DyoPHkPnAOZXaz2MqkVz3ixLJR2/aJEGGzymEm6TGRU=;
        b=jGfVaQTQK3tVGJ3k+fbMLEgTyTVixuU6/nUXCmeCE8et+2IycXre9UQPluKRVMbG++
         84vsudzkzu9QgK7z8hSKdksumWVJOmqZzStYfYwq6clI4DxBWCVFUfWz7KtqZay6gimN
         bNzHK63MIaJP5foe3IUPbnUtV2XrSYH0usmY4BPijPXjDq/nWZ6M80OLVk11tFAepArs
         3p29/dvHH5MuZHMefrqXdALT4yif3WhCU+nVR73xRPpjrhQy1sJDlCvvEguoEtn5u9S4
         mVlKso7ELm+nVDTQRhuj7MQNzgKQ3e5uNZrDETEFf0DV8r6vppOQ2N11WDkaydeqm7ot
         Rshg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787229066; x=1787833866;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=DyoPHkPnAOZXaz2MqkVz3ixLJR2/aJEGGzymEm6TGRU=;
        b=j5OJoeCO4PIlJPdO96dXLo4ANYlNjAhxZo292u+054s+sleUj0htV4NY7RVDBLdYnp
         OseYzoUY8ZAjEnrHE+7gS6wCAym0H+SVUJZl/SjMemKNvitSIiHS3EcyxEsg3t4f8FuS
         Hsm/q8yoVuyokz6fgUVhP8nma9pALQIsFZdN3DVfaYGO+XxsiMOkGkFgNxbpvdIrGAMS
         DLb6c2gUNnPywv5Y+l8mjpbiJGzEHarWgedvk5Y5iwwrulqqc2K0xX+ZukFUzpMzDKSg
         iUnNZ1dlo2rEtIXFOK7AJaoirNhvvOc4r/91m+9/Xx42wtR5tV/5yuIIw4sz0hWFGys5
         Nu7A==
X-Forwarded-Encrypted: i=1; AHgh+RoPpp1n1h2IPxCcP5ZYFLjLAWPVRuYhiRg63L3EYsuO8dHqBXZNekXrNVl8Da3VkbBy+NOrl65yUQg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZabJ/pn4C1sgg143n9jMdfhwV8fARo2iAvoskcHBcpNNzDiF7
	cKawjwa+X8XVYerHYl8n8UVCmz2WZVLX78Va7bfoE9hA1SjreSh22y+mN0g2YlERLzyhRM9wVHf
	4D7+jpc07nG32LmU0j2k+qtMg1XOk1vg=
X-Gm-Gg: AR+sD10e6V1+kLjw6cSkP6aktEty/QEehTwGFd+NfdNXNRt3CMUW82ju4Z/kH+w7U34
	ajVal9lIXDAC/GUlvzpoMR56hF5S5cHH4Av/UjOlWMNUe3+Ze4cFF7+jqAj7h3pB8cE6ceE+S4M
	PMqHNpIWYapC/NBxGmyhj3gLD1rbGqfrJRZ2uqJX+/IE+X8j2BhGG1AIl8+HuifF16KZBY7vcse
	csGD9yDxXj514MUWwjCwYejBj/4tjhLEn54+4N4oLNppFf9kVCYJZrTz8iNUc6vIWZkV9iX+LG5
	cwvICCA5+Z+is8FQAkNPHWg6Jf1PRpuWZtlfXbFMpP4q/ZsmyoMsww==
X-Received: by 2002:a05:6870:8294:b0:457:81d2:cd1e with SMTP id
 586e51a60fabf-462f6335e33mr11703489fac.4.1787229066109; Thu, 20 Aug 2026
 05:31:06 -0700 (PDT)
MIME-Version: 1.0
References: <20260819180735.135911-1-andrewprecious388@gmail.com> <aee239df-0582-4973-82ae-65688a7d6b9a@suse.com>
In-Reply-To: <aee239df-0582-4973-82ae-65688a7d6b9a@suse.com>
From: Andrew Precious <andrewprecious388@gmail.com>
Date: Thu, 20 Aug 2026 15:30:53 +0300
X-Gm-Features: AcwNN1W1kK18gQ89lsoO0YDAZltV7PfM7vroGQlwetXrJklq2lkFybE-NGqfg7s
Message-ID: <CAF14T9mYViiNQfJ8TG1RU0hqf7m6yUH1-yFCzWXXJdQOhmFkgA@mail.gmail.com>
Subject: Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when
 XSAVE is absent
To: Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, 
	anthony.perard@vates.tech, xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="0000000000009e26bb065979b176"
X-purgate-ID: tlsNG-d25034/1787229068-012C8A5B-821E353B/0/0
X-purgate-type: clean
X-purgate-size: 8228

--0000000000009e26bb065979b176
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I just realized that I attached the binary result without the fuzzer error.
To generate the previous assertion error I would have to rerun the fuzzer
again which took many hours(~18hrs). Though that was the only error I found
after that long.

VM machine that I performed the fuzzing on:
- A VM running Debian GNU/Linux 13 (trixie)
- x86_64,QEMU Virtual CPU version 2.5
- Hypervisor vendor: Xen

Main machine:
- x86_64, AMD Ryzen 9 7950X


Also I think I'll also wait for you to make the relevant changes & then
apply the patches locally.


Question seeking advice:
I've been trying to find low-hanging fruit issues within Xen to try and
fix, I currently have a fuzzer running for cpu-policy. It would be nice to
get some pointers on where/what to look for.


On Thu, Aug 20, 2026 at 11:45=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wr=
ote:

> On 19.08.2026 20:07, Andrew Mbugua wrote:
> > While running the x86_instruction_emulator fuzzer via AFL, I encountere=
d
> an assertion failure in the emul_test_read_xcr() function.
>
> Thanks for the report.
>
> > The fuzzer is able to generate a CPU state where cpu_has_xsave is false=
.
>
> I'm having trouble here: cpu_policy isn't populated from fuzzing input, a=
nd
>
> /* Intentionally checking OSXSAVE here. */
> #define cpu_has_xsave     (cpu_policy.basic.raw[1].c & (1u << 27))
>
> would mean that upon filling cpu_policy (emul_test_init() ->
> x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
> suggesting you did the fuzzing on some really old hardware?
>
> > If the fuzzer then generates & feeds an instruction containing AVX,the
> emulator
> > attempts to fetch the FPU state via x86emul_get_fpu(), which then calls
> emul_test_read_xcr() and hits the ASSERT(cpu_has_xsave). This assertion
> crashes the fuzzer.
> >
> > The crash:
> > 1. $ ./afl-harness < findings_dir/master01/...
> >    afl-harness: ../../tests/x86_emulator/x86-emulate.c:179:
> emul_test_read_xcr: Assertion `cpu_has_xsave' failed.
> >    Aborted
> >
> > 2. The stacktrace:
> > (gdb) bt
> > data_p=3Ddata_p@entry=3D0x55555604f320 <input>
> "\244\264\336\346\337\001\254%\247R\216d\204*\234\377\377\224=CE=BB\3237/=
\365=CA=BFX\266?\353\036\227/\0323\351dj\257\v\207\031V=D6=96\235{\036\225|=
:M\330\336
> \314V:&\357\306@\224\331,\301\300\372FW\262.\020\\\276\244\203\242\276\26=
2\022!\337)F&\261\2064\200\200\377I;J\376X41\2061\206\325
> \021\017F\026\267\275\340\361\357)\255\343\237n\377\374n\357#=D6=BD\226\3=
65d",
> > size=3Dsize@entry=3D580) at fuzz-emul.c:934
>
> This can't be the complete stack trace.
>
> > Possible fixes:
> > To prevent the fuzzer from getting stuck on this state,would it be
> better for emul_test_read_xcr to return X86EMUL_UNHANDLEABLE (or somethin=
g
> similar) instead of ASSERT(cpu_has_xsave) ?
>
> No, I think the assertion is legitimate there. After sending this reply,
> I'll
> post two patches taken off of the (unposted) APX series I have pending,
> which
> I think get things into better shape (and which, with the minor editing I
> had
> to do to pull them out of that series, should be fine to move ahead). On
> top
> of that we then will want to add some sanitization of input state in the
> fuzzing harness: CR4.OSXSAVE set and CPUID.XSAVE clear are clearly
> contradictory. There are other impossible combinations, and I think we ma=
y
> want to address some of them at the same time, and we already have
> sanitize_input() there. Please let us know whether you'd be willing /
> interested to make changes there, or whether we (perhaps I) should.
>
> Jan
>

--0000000000009e26bb065979b176
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I just realized that I attached the binary result without =
the fuzzer error. To generate the previous assertion error I would have to =
rerun the fuzzer again which took many hours(~18hrs). Though that was the o=
nly error I found after that long.<br><br>VM machine that I performed the f=
uzzing on:<br>- A VM running Debian GNU/Linux 13 (trixie)<br>- x86_64,QEMU =
Virtual CPU version 2.5<br>- Hypervisor vendor: Xen<br><br>Main machine:<br=
>- x86_64, AMD Ryzen 9 7950X<br><br><br>Also I think I&#39;ll also wait for=
 you to make the relevant changes &amp; then apply the patches locally.<br>=
<br><br>Question seeking advice:<br>I&#39;ve been trying to find low-hangin=
g fruit issues within Xen to try and fix, I currently have a fuzzer running=
 for cpu-policy. It would be nice to get some pointers on where/what to loo=
k for.<br><br></div><br><div class=3D"gmail_quote gmail_quote_container"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 20, 2026 at 11:45=E2=80=AFA=
M Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.com">jbeulich@suse.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On =
19.08.2026 20:07, Andrew Mbugua wrote:<br>
&gt; While running the x86_instruction_emulator fuzzer via AFL, I encounter=
ed an assertion failure in the emul_test_read_xcr() function.<br>
<br>
Thanks for the report.<br>
<br>
&gt; The fuzzer is able to generate a CPU state where cpu_has_xsave is fals=
e.<br>
<br>
I&#39;m having trouble here: cpu_policy isn&#39;t populated from fuzzing in=
put, and<br>
<br>
/* Intentionally checking OSXSAVE here. */<br>
#define cpu_has_xsave=C2=A0 =C2=A0 =C2=A0(cpu_policy.basic.raw[1].c &amp; (=
1u &lt;&lt; 27))<br>
<br>
would mean that upon filling cpu_policy (emul_test_init() -&gt;<br>
x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you<br>
suggesting you did the fuzzing on some really old hardware?<br>
<br>
&gt; If the fuzzer then generates &amp; feeds an instruction containing AVX=
,the emulator<br>
&gt; attempts to fetch the FPU state via x86emul_get_fpu(), which then call=
s emul_test_read_xcr() and hits the ASSERT(cpu_has_xsave). This assertion c=
rashes the fuzzer.<br>
&gt; <br>
&gt; The crash:<br>
&gt; 1. $ ./afl-harness &lt; findings_dir/master01/...<br>
&gt;=C2=A0 =C2=A0 afl-harness: ../../tests/x86_emulator/x86-emulate.c:179: =
emul_test_read_xcr: Assertion `cpu_has_xsave&#39; failed.<br>
&gt;=C2=A0 =C2=A0 Aborted<br>
&gt; <br>
&gt; 2. The stacktrace:<br>
&gt; (gdb) bt<br>
&gt; data_p=3Ddata_p@entry=3D0x55555604f320 &lt;input&gt; &quot;\244\264\33=
6\346\337\001\254%\247R\216d\204*\234\377\377\224=CE=BB\3237/\365=CA=BFX\26=
6?\353\036\227/\0323\351dj\257\v\207\031V=D6=96\235{\036\225|:M\330\336 \31=
4V:&amp;\357\306@\224\331,\301\300\372FW\262.\020\\\276\244\203\242\276\262=
\022!\337)F&amp;\261\2064\200\200\377I;J\376X41\2061\206\325 \021\017F\026\=
267\275\340\361\357)\255\343\237n\377\374n\357#=D6=BD\226\365d&quot;,<br>
&gt; size=3Dsize@entry=3D580) at fuzz-emul.c:934<br>
<br>
This can&#39;t be the complete stack trace.<br>
<br>
&gt; Possible fixes:<br>
&gt; To prevent the fuzzer from getting stuck on this state,would it be bet=
ter for emul_test_read_xcr to return X86EMUL_UNHANDLEABLE (or something sim=
ilar) instead of ASSERT(cpu_has_xsave) ?<br>
<br>
No, I think the assertion is legitimate there. After sending this reply, I&=
#39;ll<br>
post two patches taken off of the (unposted) APX series I have pending, whi=
ch<br>
I think get things into better shape (and which, with the minor editing I h=
ad<br>
to do to pull them out of that series, should be fine to move ahead). On to=
p<br>
of that we then will want to add some sanitization of input state in the<br=
>
fuzzing harness: CR4.OSXSAVE set and CPUID.XSAVE clear are clearly<br>
contradictory. There are other impossible combinations, and I think we may<=
br>
want to address some of them at the same time, and we already have<br>
sanitize_input() there. Please let us know whether you&#39;d be willing /<b=
r>
interested to make changes there, or whether we (perhaps I) should.<br>
<br>
Jan<br>
</blockquote></div>

--0000000000009e26bb065979b176--


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:34:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:34:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396436.1634268 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1yG-0000mJ-3o; Thu, 20 Aug 2026 12:34:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396436.1634268; Thu, 20 Aug 2026 12:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx1yG-0000mC-1A; Thu, 20 Aug 2026 12:34:12 +0000
Received: by outflank-mailman (input) for mailman id 1396436;
 Thu, 20 Aug 2026 12:34:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2a1b2d000c4f3@swg.vates.tech>)
 id 1wx1yD-0000m6-UG
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:34:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx1yD-00CfbR-B3
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:34:09 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2a1b2d000c4f3@swg.vates.tech>)
 id 6a86f431-2eae-0a2a0a5409dd-0a2a450cb6cc-30
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:34:09 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2a1b2d000c4f3@swg.vates.tech>)
 id 6a86f440-f479-0a2a450c0019-b9ff1c2389e7-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:34:09 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2a1b2d000c4f3.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:34:08 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id 7E56481FCD;
 Thu, 20 Aug 2026 14:34:07 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=BXg0cehX6O7yC/DoZ7mwx34IEA3J8VpsXVK2w0IKplg=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=CZjOr8jBvXY0a78NtnB1zy1/bJtkgqvFbYQF4o6nnq4LnvXgrfEIt+Rhw2zy0Ai+AVIuiFCHu
 /ghpWctGll0fMTb0RLOxXdLTkDDqtwI9DSemM+kxKaP2bZGt/cs7Ci18gPm5WOdQf29f7Xhoqhb
 FQFGAiMc0xYDqv6O9wT/7YdHagUKiytw2EjQZzuqns/O7y8v+T4kKnU/q4j3RYR4BlPgEgypBpp
 A74sixN0P/IUDMFtiKmcyI+fHvtblLY9alNreuVMuZg6X1q0ZeYSZ9qCLrdFi/2tNmS4G4smvdj
 NC4FdbAZfwXUSoRyrlphi5FXYmhbo9JtXc+CmzCFU8Qg==
X-Zone-Loop: 9b1a3fc15c31a88503b604e217c984309187a476f685
x-campaign-type: default
x-transaction-id: 3b3d744c-0ff3-4e6a-b8d9-7371b198f2af
x-swg-uid: 01-0663a5c9-8947-4873-ba43-6e909947f52d
X-Mailer: Sweego
Message-ID:
 <1787229248.8631fc262581453bbf619ec5b2062170.1a01f2a1b2d000c4f3@vates.tech>
x-swg-bid: 1787229248.8631fc262581453bbf619ec5b2062170.1a01f2a1b2d000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 20 Aug 2026 14:34:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/23] x86/mtrr: get rid of a static variable on
 pause/restore
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, trenchboot-devel@googlegroups.com
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------WoryyH4F8mbXv18NJg5bF0of"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229247679
X-purgate-ID: tlsNG-d25034/1787229249-038D5A5B-1F729FC1/0/0
X-purgate-type: clean
X-purgate-size: 12837

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------WoryyH4F8mbXv18NJg5bF0of
Content-Type: multipart/mixed; boundary="------------DkKfWCl6O3L0S1X48t3Btqpz";
 protected-headers="v1"; hp="clear"
Message-ID: <c4d1a462-e584-4bb3-8aea-c9cbf5451bbf@vates.tech>
Date: Thu, 20 Aug 2026 14:34:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 01/23] x86/mtrr: get rid of a static variable on
 pause/restore
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, trenchboot-devel@googlegroups.com
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <b36573fda71fdceb3d6049493faf3daff9f64de8.1785668458.git.sergii.dmytruk@3mdeb.com>

--------------DkKfWCl6O3L0S1X48t3Btqpz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDIvMDgvMjAyNiDDoCAxNToxNCwgU2VyZ2lpIERteXRydWsgYSDDqWNyaXTCoDoNCj4g
SW4gYWRkaXRpb24gdG8ga2VlcGluZyB0aGUgc3RhdGUgaW4gb25lIHBsYWNlIGluc3RlYWQg
b2Ygb24gc3RhY2sgYW5kIGluDQo+IGEgc3RhdGljIHZhcmlhYmxlLCB0aGlzIGVuYWJsZXMg
ZXhwb3NpbmcgdGhpcyBmdW5jdGlvbmFsaXR5IHRvIG90aGVyDQo+IHVuaXRzIGluIHRoZSBm
dXR1cmUuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBTZXJnaWkgRG15dHJ1ayA8c2VyZ2lpLmRt
eXRydWtAM21kZWIuY29tPg0KPiAtLS0NCj4gDQo+IE5vdGVzOg0KPiAgICAgIHY0OiB3YXMg
Y2FsbGVkICJ4ODYvbXRycjogZXhwb3NlIGZ1bmN0aW9ucyBmb3IgcGF1c2luZyBjYWNoaW5n
Ig0KPiAgICAgIHY0OiBubyBsb25nZXIgbWFrZXMgYW55dGhpbmcgcHVibGljLCBqdXN0IHVw
ZGF0ZXMgaW1wbGVtZW50YXRpb24NCj4gICAgICB2NDogdGhlIHN0YXRlIHN0cnVjdHVyZSBp
cyBub3cgYW4gb3V0cHV0IHBhcmFtZXRlciBpbnN0ZWFkIG9mIGEgcmV0dXJuIHZhbHVlDQo+
ICAgICAgdjQ6IHN3aXRjaGVzIGZyb20gcmRtc3JsKCkgdG8gcmRtc3IoKSBvbiBvbmUgbGlu
ZSB0aGF0J3MgdXBkYXRlZCBhbnl3YXkNCj4gDQo+ICAgeGVuL2FyY2gveDg2L2NwdS9tdHJy
L2dlbmVyaWMuYyB8IDU1ICsrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLQ0KPiAg
IDEgZmlsZSBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspLCAyNyBkZWxldGlvbnMoLSkNCj4g
DQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY3B1L210cnIvZ2VuZXJpYy5jIGIveGVu
L2FyY2gveDg2L2NwdS9tdHJyL2dlbmVyaWMuYw0KPiBpbmRleCAyM2MyNzllYjlhLi44NmVi
MGY0MDViIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC94ODYvY3B1L210cnIvZ2VuZXJpYy5j
DQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbXRyci9nZW5lcmljLmMNCj4gQEAgLTE0LDYg
KzE0LDExIEBADQo+ICAgI2luY2x1ZGUgPGFzbS9jcHVmZWF0dXJlLmg+DQo+ICAgI2luY2x1
ZGUgIm10cnIuaCINCj4gICANCj4gK3N0cnVjdCBtdHJyX3BhdXNpbmdfc3RhdGUgew0KPiAr
CWJvb2wgcGdlOw0KPiArCXVpbnQ2NF90IGRlZl90eXBlOw0KPiArfTsNCj4gKw0KPiAgIHN0
YXRpYyBjb25zdCBzdHJ1Y3QgZml4ZWRfcmFuZ2VfYmxvY2sgew0KPiAgIAl1aW50MzJfdCBi
YXNlX21zcjsgICAvKiBzdGFydCBhZGRyZXNzIG9mIGFuIE1UUlIgYmxvY2sgKi8NCj4gICAJ
dW5zaWduZWQgaW50IHJhbmdlczsgLyogbnVtYmVyIG9mIE1UUlJzIGluIHRoaXMgYmxvY2sg
ICovDQo+IEBAIC0zOTUsOSArNDAwLDcgQEAgc3RhdGljIGJvb2wgc2V0X210cnJfdmFyX3Jh
bmdlcyh1bnNpZ25lZCBpbnQgaW5kZXgsIHN0cnVjdCBtdHJyX3Zhcl9yYW5nZSAqdnIpDQo+
ICAgCXJldHVybiBjaGFuZ2VkOw0KPiAgIH0NCj4gICANCj4gLXN0YXRpYyB1aW50NjRfdCBk
ZWZ0eXBlOw0KPiAtDQo+IC1zdGF0aWMgdW5zaWduZWQgbG9uZyBzZXRfbXRycl9zdGF0ZSh2
b2lkKQ0KPiArc3RhdGljIHVuc2lnbmVkIGxvbmcgc2V0X210cnJfc3RhdGUodWludDY0X3Qg
KmRlZnR5cGUpDQo+ICAgLyogIFtTVU1NQVJZXSBTZXQgdGhlIE1UUlIgc3RhdGUgZm9yIHRo
aXMgQ1BVLg0KPiAgICAgICA8c3RhdGU+IFRoZSBNVFJSIHN0YXRlIGluZm9ybWF0aW9uIHRv
IHJlYWQuDQo+ICAgICAgIDxjdHh0PiBTb21lIHJlbGV2YW50IENQVSBjb250ZXh0Lg0KPiBA
QCAtNDE1LDE0ICs0MTgsMTIgQEAgc3RhdGljIHVuc2lnbmVkIGxvbmcgc2V0X210cnJfc3Rh
dGUodm9pZCkNCj4gICAJaWYgKG10cnJfc3RhdGUuaGF2ZV9maXhlZCAmJiBzZXRfZml4ZWRf
cmFuZ2VzKG10cnJfc3RhdGUuZml4ZWRfcmFuZ2VzKSkNCj4gICAJCWNoYW5nZV9tYXNrIHw9
IE1UUlJfQ0hBTkdFX01BU0tfRklYRUQ7DQo+ICAgDQo+IC0JLyogIFNldF9tdHJyX3Jlc3Rv
cmUgcmVzdG9yZXMgdGhlIG9sZCB2YWx1ZSBvZiBNVFJSZGVmVHlwZSwNCj4gLQkgICBzbyB0
byBzZXQgaXQgd2UgZmlkZGxlIHdpdGggdGhlIHNhdmVkIHZhbHVlICAqLw0KPiAtCWlmICgo
ZGVmdHlwZSAmIDB4ZmYpICE9IG10cnJfc3RhdGUuZGVmX3R5cGUNCj4gLQkgICAgfHwgTUFT
S19FWFRSKGRlZnR5cGUsIE1UUlJkZWZUeXBlX0UpICE9IG10cnJfc3RhdGUuZW5hYmxlZA0K
PiAtCSAgICB8fCBNQVNLX0VYVFIoZGVmdHlwZSwgTVRSUmRlZlR5cGVfRkUpICE9IG10cnJf
c3RhdGUuZml4ZWRfZW5hYmxlZCkgew0KPiAtCQlkZWZ0eXBlID0gKGRlZnR5cGUgJiB+MHhj
ZmYpIHwgbXRycl9zdGF0ZS5kZWZfdHlwZSB8DQo+IC0JCSAgICAgICAgICBNQVNLX0lOU1Io
bXRycl9zdGF0ZS5lbmFibGVkLCBNVFJSZGVmVHlwZV9FKSB8DQo+IC0JCSAgICAgICAgICBN
QVNLX0lOU1IobXRycl9zdGF0ZS5maXhlZF9lbmFibGVkLCBNVFJSZGVmVHlwZV9GRSk7DQo+
ICsJaWYgKCgqZGVmdHlwZSAmIDB4ZmYpICE9IG10cnJfc3RhdGUuZGVmX3R5cGUNCj4gKwkg
ICAgfHwgTUFTS19FWFRSKCpkZWZ0eXBlLCBNVFJSZGVmVHlwZV9FKSAhPSBtdHJyX3N0YXRl
LmVuYWJsZWQNCj4gKwkgICAgfHwgTUFTS19FWFRSKCpkZWZ0eXBlLCBNVFJSZGVmVHlwZV9G
RSkgIT0gbXRycl9zdGF0ZS5maXhlZF9lbmFibGVkKSB7DQo+ICsJCSpkZWZ0eXBlID0gKCpk
ZWZ0eXBlICYgfjB4Y2ZmKSB8IG10cnJfc3RhdGUuZGVmX3R5cGUgfA0KPiArCQkgICAgICAg
ICAgIE1BU0tfSU5TUihtdHJyX3N0YXRlLmVuYWJsZWQsIE1UUlJkZWZUeXBlX0UpIHwNCj4g
KwkJICAgICAgICAgICBNQVNLX0lOU1IobXRycl9zdGF0ZS5maXhlZF9lbmFibGVkLCBNVFJS
ZGVmVHlwZV9GRSk7DQo+ICAgCQljaGFuZ2VfbWFzayB8PSBNVFJSX0NIQU5HRV9NQVNLX0RF
RlRZUEU7DQo+ICAgCX0NCj4gICANCj4gQEAgLTQzOSw3ICs0NDAsNyBAQCBzdGF0aWMgREVG
SU5FX1NQSU5MT0NLKHNldF9hdG9taWNpdHlfbG9jayk7DQo+ICAgICogaGFzIGJlZW4gY2Fs
bGVkLg0KPiAgICAqLw0KPiAgIA0KPiAtc3RhdGljIGJvb2wgcHJlcGFyZV9zZXQodm9pZCkN
Cj4gK3N0YXRpYyB2b2lkIG10cnJfcGF1c2VfY2FjaGluZyhzdHJ1Y3QgbXRycl9wYXVzaW5n
X3N0YXRlICpzdGF0ZSkNCj4gICB7DQo+ICAgCXVuc2lnbmVkIGxvbmcgY3I0Ow0KPiAgIA0K
PiBAQCAtNDYxLDcgKzQ2Miw5IEBAIHN0YXRpYyBib29sIHByZXBhcmVfc2V0KHZvaWQpDQo+
ICAgCWFsdGVybmF0aXZlKCJ3YmludmQiLCAiIiwgWDg2X0ZFQVRVUkVfWEVOX1NFTEZTTk9P
UCk7DQo+ICAgDQo+ICAgCWNyNCA9IHJlYWRfY3I0KCk7DQo+IC0JaWYgKGNyNCAmIFg4Nl9D
UjRfUEdFKQ0KPiArCXN0YXRlLT5wZ2UgPSBjcjQgJiBYODZfQ1I0X1BHRTsNCj4gKw0KPiAr
CWlmIChzdGF0ZS0+cGdlKQ0KPiAgIAkJd3JpdGVfY3I0KGNyNCAmIH5YODZfQ1I0X1BHRSk7
DQo+ICAgCWVsc2UgaWYgKHVzZV9pbnZwY2lkKQ0KPiAgIAkJaW52cGNpZF9mbHVzaF9hbGwo
KTsNCj4gQEAgLTQ2OSwyNyArNDcyLDI1IEBAIHN0YXRpYyBib29sIHByZXBhcmVfc2V0KHZv
aWQpDQo+ICAgCQl3cml0ZV9jcjMocmVhZF9jcjMoKSk7DQo+ICAgDQo+ICAgCS8qICBTYXZl
IE1UUlIgc3RhdGUgKi8NCj4gLQlyZG1zcmwoTVNSX01UUlJkZWZUeXBlLCBkZWZ0eXBlKTsN
Cj4gKwlzdGF0ZS0+ZGVmX3R5cGUgPSByZG1zcihNU1JfTVRSUmRlZlR5cGUpOw0KPiAgIA0K
PiAgIAkvKiAgRGlzYWJsZSBNVFJScywgYW5kIHNldCB0aGUgZGVmYXVsdCB0eXBlIHRvIHVu
Y2FjaGVkICAqLw0KPiAtCW10cnJfd3Jtc3IoTVNSX01UUlJkZWZUeXBlLCBkZWZ0eXBlICYg
fjB4Y2ZmKTsNCj4gKwltdHJyX3dybXNyKE1TUl9NVFJSZGVmVHlwZSwgc3RhdGUtPmRlZl90
eXBlICYgfjB4Y2ZmKTsNCj4gICANCj4gICAJLyogQWdhaW4sIG9ubHkgZmx1c2ggY2FjaGVz
IGlmIHdlIGhhdmUgdG8uICovDQo+ICAgCWFsdGVybmF0aXZlKCJ3YmludmQiLCAiIiwgWDg2
X0ZFQVRVUkVfWEVOX1NFTEZTTk9PUCk7DQo+IC0NCj4gLQlyZXR1cm4gY3I0ICYgWDg2X0NS
NF9QR0U7DQo+ICAgfQ0KPiAgIA0KPiAtc3RhdGljIHZvaWQgcG9zdF9zZXQoYm9vbCBwZ2Up
DQo+ICtzdGF0aWMgdm9pZCBtdHJyX3Jlc3VtZV9jYWNoaW5nKHN0cnVjdCBtdHJyX3BhdXNp
bmdfc3RhdGUgc3RhdGUpDQoNCkl0IHdvdWxkIGJlIHByZWZlcmFibGUgdG8gaGF2ZSBjb25z
dCBvbiB0aGUgc3RydWN0IG10cnJfcGF1c2luZ19zdGF0ZSANCnN0YXRlIHRvIHBvdGVudGlh
bGx5IGltcHJvdmUgY29kZWdlbiwgYXMgSSBndWVzcyB0aGUgaW50ZW50IGhlcmUgaXMgdG8g
DQpwYXNzIGEgcmVhZC1vbmx5IG9iamVjdC4NCg0KPiAgIHsNCj4gICAJLyogSW50ZWwgKFA2
KSBzdGFuZGFyZCBNVFJScyAqLw0KPiAtCW10cnJfd3Jtc3IoTVNSX01UUlJkZWZUeXBlLCBk
ZWZ0eXBlKTsNCj4gKwltdHJyX3dybXNyKE1TUl9NVFJSZGVmVHlwZSwgc3RhdGUuZGVmX3R5
cGUpOw0KPiAgIA0KPiAgIAkvKiAgRW5hYmxlIGNhY2hlcyAgKi8NCj4gICAJd3JpdGVfY3Iw
KHJlYWRfY3IwKCkgJiB+WDg2X0NSMF9DRCk7DQo+ICAgDQo+ICAgCS8qICBSZWVuYWJsZSBD
UjQuUEdFIChhbHNvIGZsdXNoZXMgdGhlIFRMQikgKi8NCj4gLQlpZiAocGdlKQ0KPiArCWlm
IChzdGF0ZS5wZ2UpDQo+ICAgCQl3cml0ZV9jcjQocmVhZF9jcjQoKSB8IFg4Nl9DUjRfUEdF
KTsNCj4gICAJZWxzZSBpZiAodXNlX2ludnBjaWQpDQo+ICAgCQlpbnZwY2lkX2ZsdXNoX2Fs
bCgpOw0KPiBAQCAtNTAzLDE1ICs1MDQsMTUgQEAgdm9pZCBtdHJyX3NldF9hbGwodm9pZCkN
Cj4gICB7DQo+ICAgCXVuc2lnbmVkIGxvbmcgbWFzaywgY291bnQ7DQo+ICAgCXVuc2lnbmVk
IGxvbmcgZmxhZ3M7DQo+IC0JYm9vbCBwZ2U7DQo+ICsJc3RydWN0IG10cnJfcGF1c2luZ19z
dGF0ZSBwYXVzaW5nX3N0YXRlOw0KPiAgIA0KPiAgIAlsb2NhbF9pcnFfc2F2ZShmbGFncyk7
DQo+IC0JcGdlID0gcHJlcGFyZV9zZXQoKTsNCj4gKwltdHJyX3BhdXNlX2NhY2hpbmcoJnBh
dXNpbmdfc3RhdGUpOw0KPiAgIA0KPiAgIAkvKiBBY3R1YWxseSBzZXQgdGhlIHN0YXRlICov
DQo+IC0JbWFzayA9IHNldF9tdHJyX3N0YXRlKCk7DQo+ICsJbWFzayA9IHNldF9tdHJyX3N0
YXRlKCZwYXVzaW5nX3N0YXRlLmRlZl90eXBlKTsNCj4gICANCj4gLQlwb3N0X3NldChwZ2Up
Ow0KPiArCW10cnJfcmVzdW1lX2NhY2hpbmcocGF1c2luZ19zdGF0ZSk7DQo+ICAgCWxvY2Fs
X2lycV9yZXN0b3JlKGZsYWdzKTsNCj4gICANCj4gICAJLyogIFVzZSB0aGUgYXRvbWljIGJp
dG9wcyB0byB1cGRhdGUgdGhlIGdsb2JhbCBtYXNrICAqLw0KPiBAQCAtNTM2LDEyICs1Mzcs
MTIgQEAgdm9pZCBtdHJyX3NldCgNCj4gICB7DQo+ICAgCXVuc2lnbmVkIGxvbmcgZmxhZ3M7
DQo+ICAgCXN0cnVjdCBtdHJyX3Zhcl9yYW5nZSAqdnI7DQo+IC0JYm9vbCBwZ2U7DQo+ICsJ
c3RydWN0IG10cnJfcGF1c2luZ19zdGF0ZSBwYXVzaW5nX3N0YXRlOw0KPiAgIA0KPiAgIAl2
ciA9ICZtdHJyX3N0YXRlLnZhcl9yYW5nZXNbcmVnXTsNCj4gICANCj4gICAJbG9jYWxfaXJx
X3NhdmUoZmxhZ3MpOw0KPiAtCXBnZSA9IHByZXBhcmVfc2V0KCk7DQo+ICsJbXRycl9wYXVz
ZV9jYWNoaW5nKCZwYXVzaW5nX3N0YXRlKTsNCj4gICANCj4gICAJaWYgKHNpemUgPT0gMCkg
ew0KPiAgIAkJLyogVGhlIGludmFsaWQgYml0IGlzIGtlcHQgaW4gdGhlIG1hc2ssIHNvIHdl
IHNpbXBseSBjbGVhciB0aGUNCj4gQEAgLTU2Miw3ICs1NjMsNyBAQCB2b2lkIG10cnJfc2V0
KA0KPiAgIAkJbXRycl93cm1zcihNU1JfSUEzMl9NVFJSX1BIWVNNQVNLKHJlZyksIHZyLT5t
YXNrKTsNCj4gICAJfQ0KPiAgIA0KPiAtCXBvc3Rfc2V0KHBnZSk7DQo+ICsJbXRycl9yZXN1
bWVfY2FjaGluZyhwYXVzaW5nX3N0YXRlKTsNCj4gICAJbG9jYWxfaXJxX3Jlc3RvcmUoZmxh
Z3MpOw0KPiAgIH0NCj4gICANCg0KV2l0aCB0aGF0IGNoYW5nZSwNCg0KUmV2aWV3ZWQtYnk6
IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KDQo=

--------------DkKfWCl6O3L0S1X48t3Btqpz--

--------------WoryyH4F8mbXv18NJg5bF0of
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqG9D8FAwAAAAAACgkQZg+p0QLLz9Ah
SQv/fY9JLFFBHHoy5VHLS4A+yKyDYULfjO49sBDZm8JtJxo/Mttya2sDpl5YjqPrafeq0rNLicO/
p4tOgPQaIpTRS9DLTWmYUhcdI3+9Vb3vE7E8pSZJki3xgESH92ZMtfAyG+UPxpASww69UYHuyihi
ueUcmbVKueEhUUvfC+JeJrlgpAUP7hPka4/xvHzNNbLWjohq+XuhJpfhFsP6e8KNlS/q3Ib87TBS
0Qz83wWOKvc+QhyBC/UJvZbUdDWZjqJvJTo/2dEr9t7T0RR952BFWrubeXJgh5pGlBwDSi+rDpCH
I/OlwUSJEYCZZEnG2qkouR8EwZwP6PVD/Axrm2T5OQzycncemLHLxDYaFxYf6Ck9clLJ12wDcglE
fxCxN5YBur2OJ/QJ2bS0yEqBNzLMLXr0FrwdmrSs/WIGxijgP78gF7VRucJW5LBVuKKnVjUFcRcb
nBeQ7Em6vNWCiH0I5nnK1z1hCk/jxoq3Bjq+fRaRi9gvuy85AXEnA4J1EXPJ
=mHzq
-----END PGP SIGNATURE-----

--------------WoryyH4F8mbXv18NJg5bF0of--


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:38:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:38:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396447.1634276 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx22F-0001Tl-Mz; Thu, 20 Aug 2026 12:38:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396447.1634276; Thu, 20 Aug 2026 12:38:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx22F-0001Te-K8; Thu, 20 Aug 2026 12:38:19 +0000
Received: by outflank-mailman (input) for mailman id 1396447;
 Thu, 20 Aug 2026 12:38:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2dd31e000c4f3@swg.vates.tech>)
 id 1wx22F-0001TY-5M
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:38:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx22E-00FHVh-Az
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:38:18 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2dd31e000c4f3@swg.vates.tech>)
 id 6a86f527-bab6-0a2a0a5309dd-0a2a450b86e2-4
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:38:18 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2dd31e000c4f3@swg.vates.tech>)
 id 6a86f539-b7e8-0a2a450b0019-b9ff1c239655-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:38:18 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2dd31e000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:38:12 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id E8E0081FCD;
 Thu, 20 Aug 2026 14:38:10 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=SGjtsp1ym7OEP7diKsb4KcHKVUBAe62Kw5T/tQHyg5Y=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id;
 b=S6UKXWkAxqssYnY30I3yv5+uaFJ1FSOWJkjx1cRKq7C5GRB1JwB2o4azvto9w/4ni1rhsgO27
 y7k5jI1XnSCcZ8+3dQFPWOEzhes2G+T5qxyoUWcb40Fcjqt2hQR7DSUkswYxCdxxqNuv/BvC3Rr
 qNuV8dAWrw5OoQkWeZl3/iVaMNJY9dbW6ryiVjZ3sidQm6YVJXR82pRMiztX1SePoMxJEyR/RGZ
 BvUWGkbwK/fPSl+ki799vJCR7+4203k+BT9SInZo8Sh9i0depJiX1YDPKgKIAo8xTKmiYxhcDI3
 q6ISrWxano13aVXqEkrccl4FctlwR4jVjXoZ4MExuOWQ==
X-Zone-Loop: 79a7dde3c40c3e0428b2f6fc7d3df27ab4779ff74899
x-campaign-type: default
x-transaction-id: 7a412ec2-d0d9-439a-9a2e-650fd5b56cc4
x-swg-uid: 01-9684f1d7-ef38-4704-a518-393b9272745c
X-Mailer: Sweego
Message-ID:
 <1787229492.8631fc262581453bbf619ec5b2062170.1a01f2dd31e000c4f3@vates.tech>
x-swg-bid: 1787229492.8631fc262581453bbf619ec5b2062170.1a01f2dd31e000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 0/6] Fix ARM domcreate
Date: Thu, 20 Aug 2026 14:38:05 +0200
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.266d.bc76990160a75c3c.1a01f2dd034.2918ccc90bcf40f9=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229491257
X-purgate-ID: tlsNG-42698a/1787229498-1BED69EA-11D86C43/0/0
X-purgate-type: clean
X-purgate-size: 3759

---=Part.266d.bc76990160a75c3c.1a01f2dd034.2918ccc90bcf40f9=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Michal, Andrew and Jan,
thank you for your reviews! I have addressed your feedback, i=2Ee=2E, GICv=
2
compatibility-mode reporting, ASSERT_UNREACHABLE() for the invalid case,
and the comment typo=2E I also changed patch 4 to no longer bump
XEN_DOMCTL_INTERFACE_VERSION for the XEN_DOMCTL_CONFIG_GIC_NATIVE
removal and I have also updated the timer frequency reporting=2E

Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
---
Changes in v4:
- Patch 1: Added Reviewed-by
- Patch 2: Also report GICv2 support when a GICv3 host has the vGICv2
  compatibility mode enabled
- Patch 3: Fix the missing closing bracket in arch_capabilities_arm_has()
- Patch 4: Don't bump XEN_DOMCTL_INTERFACE_VERSION for the removal of
  XEN_DOMCTL_CONFIG_GIC_NATIVE and report the requested GIC version in
  the "Unsupported GIC version" print
- Patch 5: Always populate the reported timer frequency, including in
  the CNTFRQ_EL0 path, so ACPI guests get a real value instead
  of 0 (previously only reported when booting via DT)
- Patch 6: Shorten the arch_sanitise_domain_config() comment
---
Andrew Cooper (1):
  ARM/sysctl: Expose the supported guest GIC modes in physinfo

Julian Vetter (5):
  xen/arm: report proper GIC version via XEN_DOMCTL_getdomaininfo
  tools/arm: choose GIC version explicitly instead of relying on
    GIC_NATIVE
  xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from the ABI
  xen/arm: report clock_frequency via sysctl physinfo, not createdomain
  xen: make config argument const

 CHANGELOG=2Emd                                  |  4 ++
 =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 17 +++++++++
 tools/libs/light/libxl=2Ec                      |  1 +
 tools/libs/light/libxl_arm=2Ec                  | 30 +++++++++++++--
 tools/libs/light/libxl_types=2Eidl              |  1 +
 tools/ocaml/libs/xc/xenctrl=2Eml                |  1 -
 tools/ocaml/libs/xc/xenctrl=2Emli               |  1 -
 tools/python/xen/lowlevel/xc/xc=2Ec             | 20 +++++++++-
 xen/arch/arm/dom0less-build=2Ec                 |  3 +-
 xen/arch/arm/domain=2Ec                         | 28 +++++---------
 xen/arch/arm/domain_build=2Ec                   |  3 +-
 xen/arch/arm/domctl=2Ec                         |  2 +
 xen/arch/arm/firmware/sci=2Ec                   |  2 +-
 xen/arch/arm/firmware/scmi-smc=2Ec              |  2 +-
 xen/arch/arm/gic=2Ec                            | 16 ++++++++
 xen/arch/arm/include/asm/firmware/sci=2Eh       |  6 +--
 xen/arch/arm/include/asm/gic=2Eh                |  6 +++
 xen/arch/arm/include/asm/time=2Eh               |  6 +--
 xen/arch/arm/include/asm/vgic=2Eh               |  6 +++
 xen/arch/arm/include/asm/vtimer=2Eh             |  3 +-
 xen/arch/arm/sysctl=2Ec                         | 37 +++++++++++++++++++
 xen/arch/arm/time=2Ec                           |  7 ++--
 xen/arch/arm/vgic-v2=2Ec                        |  5 +++
 xen/arch/arm/vtimer=2Ec                         |  4 +-
 xen/arch/ppc/stubs=2Ec                          |  2 +-
 xen/arch/riscv/domain=2Ec                       |  2 +-
 xen/arch/x86/domain=2Ec                         | 16 ++++----
 xen/include/public/arch-arm=2Eh                 | 18 +--------
 xen/include/public/sysctl=2Eh                   | 14 ++++++-
 xen/include/xen/sched=2Eh                       |  5 +--
 30 files changed, 195 insertions(+), 73 deletions(-)

--=20
2=2E53=2E0



-- 
 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vate=
s=2Etech
---=Part.266d.bc76990160a75c3c.1a01f2dd034.2918ccc90bcf40f9=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:40:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:40:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396454.1634286 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24O-0002xg-1l; Thu, 20 Aug 2026 12:40:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396454.1634286; Thu, 20 Aug 2026 12:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24N-0002xZ-V3; Thu, 20 Aug 2026 12:40:31 +0000
Received: by outflank-mailman (input) for mailman id 1396454;
 Thu, 20 Aug 2026 12:40:30 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd47d000c4f3@swg.vates.tech>)
 id 1wx24M-0002xT-Kr
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:40:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx24M-003z3G-1Z
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:40:30 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd47d000c4f3@swg.vates.tech>)
 id 6a86f5b6-8faa-0a2a0a5109dd-0a2a450b8c94-34
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:30 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd47d000c4f3@swg.vates.tech>)
 id 6a86f5bd-b7e8-0a2a450b0019-b9ff1c1287a7-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:29 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2fd47d000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:40:23 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8B5ED83985;
 Thu, 20 Aug 2026 14:40:22 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=tEdvTLm/4KIjlNkjDXt3Fc/qWmYOdBQIKG7le6uW4hA=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=CB4QWdg0yNrRJAtlogzEmS6gTbgTN1S2BZ5RvLM4iP/p1MvPXZZ21nFU5lEjQHSM6EpVcmHK6
 rSVJQXBJKkvhckQhcXgBwHcN+v8UegCCa2WMN+C73tmuUdiWl9nPx2Pmv9B2Dikzj4qcqJQqYo9
 kIislgP2BTXsrRAXTy3LrrQv8NvHB3mFTh7JEYbOi+AbPuGBVAVEFVOf08bkfVNyPa5RabJWV1N
 1o6XQccj/AO+jL/P4YG1V83NJU/ZPhGuoAYo4mDSFj0k7SNG1DoQ9w/hauKObR8fcf9AVH/NlxK
 p2XhNo4Yp7SLuH8xDQj3UvyLV7zx0TKCuLs5kTBuJBDg==
X-Zone-Loop: 792e9c5eadeac0388efc35b52e4f667024d3b3b9ccb6
x-campaign-type: default
x-transaction-id: 0c40c35a-9453-475e-a3ad-ee072efe19d5
x-swg-uid: 01-05a9f7b1-1bd9-4021-9d05-494dba847ebc
X-Mailer: Sweego
Message-ID:
 <1787229623.8631fc262581453bbf619ec5b2062170.1a01f2fd47d000c4f3@vates.tech>
x-swg-bid: 1787229623.8631fc262581453bbf619ec5b2062170.1a01f2fd47d000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 1/6] xen/arm: report proper GIC version via XEN_DOMCTL_getdomaininfo
Date: Thu, 20 Aug 2026 14:40:11 +0200
In-Reply-To: <20260820123805.2033085-1-julian.vetter@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.266e.57d0d7cbe1fd70b5.1a01f2fd25c.b308922d4c5c8c3b=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229622876
X-purgate-ID: tlsNG-42698a/1787229630-1A2C49EA-BE1056C5/0/0
X-purgate-type: clean
X-purgate-size: 2046

---=Part.266e.57d0d7cbe1fd70b5.1a01f2fd25c.b308922d4c5c8c3b=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

When creating a domain on ARM, and passing XEN_DOMCTL_CONFIG_GIC_NATIVE
for the gic_version field in the struct xen_arch_domainconfig,
arch_sanitise_domain_config() resolves this to the approrpiate GIC_V2 or
GIC_V3 version the domain actually has, based on the host's
gic_hw_version()=2E That value is stored in the domain as
d->arch=2Evgic=2Eversion, but can't be queried through any other domctl
later=2E Toolstacks that create and build a domain in the same call
already have this info from the createdomain reply and never need to ask
again=2E

Toolstacks that create a domain and build it later from a separate
process do need to ask again=2E But, the ARM implementation only fills in
info->flags and info->gpaddr_bits=2E info->arch_config is left zeroed, so
XEN_DOMCTL_getdomaininfo always reports gic_version as
XEN_DOMCTL_CONFIG_GIC_NATIVE (0) regardless of what was actually
configured earlier=2E

Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
Reviewed-by: Andrew Cooper <andrew=2Ecooper3@citrix=2Ecom>
Reviewed-by: Michal Orzel <michal=2Eorzel@amd=2Ecom>
---
Changes in v4:
- Added 'Reviewed-by'
---
 xen/arch/arm/domctl=2Ec | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/domctl=2Ec b/xen/arch/arm/domctl=2Ec
index 6c9a3f9920=2E=2Eb76af56fad 100644
--- a/xen/arch/arm/domctl=2Ec
+++ b/xen/arch/arm/domctl=2Ec
@@ -24,6 +24,8 @@ void arch_get_domain_info(const struct domain *d,
     info->flags |=3D XEN_DOMINF_hap;
=20
     info->gpaddr_bits =3D p2m_ipa_bits;
+
+    info->arch_config=2Egic_version =3D d->arch=2Evgic=2Eversion;
 }
=20
 static int handle_vuart_init(struct domain *d,=20
--=20
2=2E53=2E0



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.266e.57d0d7cbe1fd70b5.1a01f2fd25c.b308922d4c5c8c3b=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:40:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:40:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396456.1634295 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24T-0003Bm-8A; Thu, 20 Aug 2026 12:40:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396456.1634295; Thu, 20 Aug 2026 12:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24T-0003Bd-5F; Thu, 20 Aug 2026 12:40:37 +0000
Received: by outflank-mailman (input) for mailman id 1396456;
 Thu, 20 Aug 2026 12:40:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3@swg.vates.tech>)
 id 1wx24S-0003BD-23
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:40:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx24R-005tXc-Eu
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:40:35 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3@swg.vates.tech>)
 id 6a86f5c2-e002-0a2a0a5209dd-0a2a450a9122-2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:35 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3@swg.vates.tech>)
 id 6a86f5c3-f2d2-0a2a450a0019-b9ff1c2295cb-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:35 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2fd64f000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:40:23 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 177FA83989;
 Thu, 20 Aug 2026 14:40:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=zVPmnms4yZExIzoBTd8pTcQJdW2JQmbzJ6vxrYDw3Hg=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=LWCtTzL3XkWivzcj9mV5nQs26/a0JXPOxzoHtS/zRc7yQabTbfwmpUwgMhDIuypBGp4zm0Je/
 IXWqAlIq8izhRKyemxYZRREHyU7ngqM4p2ybW0q6RFMkRKkl0KcHAmcEppZ5zXocSnjJhZMsIxq
 iZw2TOxYjXuN8p5k8k8tTQVBq5gygm5wjYE/quhQjlNq4BoJa0fJTQagnSis2ie7ggnPMFwOv39
 xw+1wkuv47hK/1tHQhmVFMGc+6F0OdFjtu2Qbr1DXnRyPMQCnfwiuGJ9BychB/9OGoOKwTjw7es
 J2+HdwYHJEUMR/c1hFSbyW1rk/B7ujjNvNfVxX7sTB9A==
X-Zone-Loop: ca0b2c7505cf056e1783e506258ed3ea0ff947fdeebb
x-campaign-type: default
x-transaction-id: becf1af0-3b4c-4eab-b815-3bd6c075c48c
x-swg-uid: 01-7af21777-fa85-4209-a91e-cfcffb42f672
X-Mailer: Sweego
Message-ID:
 <1787229623.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3@vates.tech>
x-swg-bid: 1787229623.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 2/6] ARM/sysctl: Expose the supported guest GIC modes in physinfo
Date: Thu, 20 Aug 2026 14:40:12 +0200
In-Reply-To: <20260820124016.2033421-1-julian.vetter@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.266f.fdf67f2d843f1ae7.1a01f2fd457.15f7fc3d5f2e6ac7=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229623383
X-purgate-ID: tlsNG-4011c0/1787229635-50CCBCFC-66C35F09/0/0
X-purgate-type: clean
X-purgate-size: 4737

---=Part.266f.fdf67f2d843f1ae7.1a01f2fd457.15f7fc3d5f2e6ac7=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

From: Andrew Cooper <andrew=2Ecooper3@citrix=2Ecom>

In preparation to simplify the domain creation logic surrounding GIC
version=2E

On a GICv3 host, also report support for GICv2-compatible guests when
the hardware's vGICv2 compatibility mode is enabled, rather than just
the native GIC version=2E

Signed-off-by: Andrew Cooper <andrew=2Ecooper3@citrix=2Ecom>
Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
---
Changes in v4:
- Report GICv2 support when a GICv3 host has vGICv2 compatibility mode
  enabled
- Add ASSERT_UNREACHABLE() for the GIC_INVALID case
- Fix a typo in a comment
---
 xen/arch/arm/include/asm/vgic=2Eh |  6 ++++++
 xen/arch/arm/sysctl=2Ec           | 34 +++++++++++++++++++++++++++++++++
 xen/arch/arm/vgic-v2=2Ec          |  5 +++++
 xen/include/public/sysctl=2Eh     |  2 ++
 4 files changed, 47 insertions(+)

diff --git a/xen/arch/arm/include/asm/vgic=2Eh b/xen/arch/arm/include/asm/=
vgic=2Eh
index 6f9ab1c98c=2E=2E26c53aaf3c 100644
--- a/xen/arch/arm/include/asm/vgic=2Eh
+++ b/xen/arch/arm/include/asm/vgic=2Eh
@@ -433,6 +433,12 @@ unsigned int vgic_max_vcpus(unsigned int domctl_vgic_=
version);
 void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
                       paddr_t vbase, uint32_t aliased_offset);
=20
+#ifdef CONFIG_VGICV2
+bool vgic_v2_hw_enabled(void);
+#else
+static inline bool vgic_v2_hw_enabled(void) { return false; }
+#endif
+
 #ifdef CONFIG_GICV3
 struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
diff --git a/xen/arch/arm/sysctl=2Ec b/xen/arch/arm/sysctl=2Ec
index 32cab4feff=2E=2E8411deb7e2 100644
--- a/xen/arch/arm/sysctl=2Ec
+++ b/xen/arch/arm/sysctl=2Ec
@@ -12,7 +12,11 @@
 #include <xen/dt-overlay=2Eh>
 #include <xen/errno=2Eh>
 #include <xen/hypercall=2Eh>
+
 #include <asm/arm64/sve=2Eh>
+#include <asm/gic=2Eh>
+#include <asm/vgic=2Eh>
+
 #include <public/sysctl=2Eh>
=20
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
@@ -21,6 +25,36 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
=20
     pi->arch_capabilities |=3D MASK_INSR(sve_encode_vl(get_sys_vl_len()),
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
+
+    /*
+     * The GIC version(s) we're happy creating guests with=2E Right now f=
or
+     * simplicity it is tied to the active hardware version, but this wil=
l
+     * cease to be the case if/when the compatibility modes are enabled=
=2E
+     */
+    switch ( gic_hw_version() )
+    {
+    case GIC_V2:
+        pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_GIC_V2;
+        break;
+
+    case GIC_V3:
+        pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_GIC_V3;
+
+        /* GICv3 may additionally support GICv2-compatible guests=2E */
+        if ( vgic_v2_hw_enabled() )
+            pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_GIC_V2;
+        break;
+
+    case GIC_INVALID:
+        /*
+         * Running a control domain without having the GIC sorted yet?
+         * Something's broken, but there's nothing we can do about it her=
e=2E
+         */
+        ASSERT_UNREACHABLE();
+        printk_once(XENLOG_ERR "Unrecognised GIC version %d\n",
+                    gic_hw_version());
+        break;
+    }
 }
=20
 long arch_do_sysctl(struct xen_sysctl *sysctl,
diff --git a/xen/arch/arm/vgic-v2=2Ec b/xen/arch/arm/vgic-v2=2Ec
index 642407fd5b=2E=2E5d758dd93b 100644
--- a/xen/arch/arm/vgic-v2=2Ec
+++ b/xen/arch/arm/vgic-v2=2Ec
@@ -49,6 +49,11 @@ void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, pad=
dr_t csize,
     vgic_v2_hw=2Ealiased_offset =3D aliased_offset;
 }
=20
+bool vgic_v2_hw_enabled(void)
+{
+    return vgic_v2_hw=2Eenabled;
+}
+
 #define NR_TARGETS_PER_ITARGETSR    4U
 #define NR_BITS_PER_TARGET  (32U / NR_TARGETS_PER_ITARGETSR)
=20
diff --git a/xen/include/public/sysctl=2Eh b/xen/include/public/sysctl=2Eh
index c7cd9b4eb0=2E=2Ed20ebf3644 100644
--- a/xen/include/public/sysctl=2Eh
+++ b/xen/include/public/sysctl=2Eh
@@ -106,6 +106,8 @@ struct xen_sysctl_tbuf_op {
=20
 #if defined(__arm__) || defined(__aarch64__)
 #define XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK  (0x1FU)
+#define XEN_SYSCTL_PHYSCAP_ARM_GIC_V2    (1U << 5)
+#define XEN_SYSCTL_PHYSCAP_ARM_GIC_V3    (1U << 6)
 #endif
=20
 struct xen_sysctl_physinfo {
--=20
2=2E53=2E0



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.266f.fdf67f2d843f1ae7.1a01f2fd457.15f7fc3d5f2e6ac7=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:40:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:40:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396457.1634304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24Y-0003Rj-EL; Thu, 20 Aug 2026 12:40:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396457.1634304; Thu, 20 Aug 2026 12:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24Y-0003RT-BQ; Thu, 20 Aug 2026 12:40:42 +0000
Received: by outflank-mailman (input) for mailman id 1396457;
 Thu, 20 Aug 2026 12:40:41 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3@swg.vates.tech>)
 id 1wx24X-0003QM-3L
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:40:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx24W-0023ST-GA
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:40:40 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3@swg.vates.tech>)
 id 6a86f5c5-2eae-0a2a0a5409dd-0a2a45028d6a-18
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:40 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3@swg.vates.tech>)
 id 6a86f5c8-6ca4-0a2a45020019-b9ff1c23a55f-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:40 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2fd7e5000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:40:24 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 9432E83985;
 Thu, 20 Aug 2026 14:40:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=IJH2HUzYWNXRVAto16EctIl+NY5cYVjwj2qJDihG+M0=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=gYQWm7Rj+Oh2ZarD4c4H1sMz5cPAlHKomK222NvZtZrmX7F/o8fbn3Qa9bxWGVSUemNcYV7Li
 /Z7UN6AoEb3ZgPpo4xyfr//1+VZVv9Dly5QIZKhHy4eoX5RasCodcqfQzsjAQhotjFduF+6BsPE
 3iPUmf8Dj0SAGDysvRTvD02p6JSZm7rVQxnmH5A4lL5kJdjVHd1qJaR9ldm1e5R5mi4M8f1Juv+
 XQb++ukeq0mNe+SyYrdUmh42X91EymYxd7oQq+DXVhPbGtrbDefXWUfbNx7YieNrT5M1TnYiKQ/
 m9zw1+oyX7ho54E5lyrgPOfgPWrPAcXXF92qTmJJZiiA==
X-Zone-Loop: a84a9237816b35c13009cb664476e9ef8cefda7aa3ef
x-campaign-type: default
x-transaction-id: 00648aeb-0ac8-40b3-b0ae-1751fc39965c
x-swg-uid: 01-5ef02326-ce55-4969-bf7b-e014a950eadc
X-Mailer: Sweego
Message-ID:
 <1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3@vates.tech>
x-swg-bid: 1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE
Date: Thu, 20 Aug 2026 14:40:13 +0200
In-Reply-To: <20260820124016.2033421-1-julian.vetter@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2670.4ba10b5e3851bf08.1a01f2fd658.85baa265d6fc9dfa=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229623896
X-purgate-ID: tlsNG-720697/1787229640-F16AF2AC-68CFD960/0/0
X-purgate-type: clean
X-purgate-size: 6203

---=Part.2670.4ba10b5e3851bf08.1a01f2fd658.85baa265d6fc9dfa=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently
resolve the domain's GIC version to whatever the host hardware has=2E Xen
then writes the resolved value back into the same in/out
xen_arch_domainconfig the toolstack used as input, which is the kind of
API abuse we're trying to get rid of=2E The struct passed to createdomain
should only be an input parameter=2E

Move the "pick the best available GIC version" decision to the
toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits
already exposed via XEN_SYSCTL_physinfo:

 * libxl__arch_domain_build_info_setdefault() resolves
   LIBXL_GIC_VERSION_DEFAULT to v3 if available, else v2, else fails,
   before the config is built=2E
 * The Python xc=2Edomain_create() binding does the same via a call to
   xc_physinfo()=2E
 * libxl__arch_domain_prepare_config() therefore only ever sees a
   concrete v2/v3 request and just validates it=2E The GIC_NATIVE case is
   dropped since setdefault() always resolves it first=2E

This guarantees no toolstack path can still produce
XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the
Xen side and from the ABI entirely=2E

Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
---
Changes in v4:
- Fix a missing closing bracket in arch_capabilities_arm_has()
---
 =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 17 ++++++++++++++=
++
 tools/libs/light/libxl_arm=2Ec                  | 17 +++++++++++++---
 tools/python/xen/lowlevel/xc/xc=2Ec             | 20 ++++++++++++++++++-
 3 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-tools/arm-arch-capabilities=2Eh b/tools/inc=
lude/xen-tools/arm-arch-capabilities=2Eh
index 4aa4c6c34a=2E=2Ece1b3bdd71 100644
--- a/tools/include/xen-tools/arm-arch-capabilities=2Eh
+++ b/tools/include/xen-tools/arm-arch-capabilities=2Eh
@@ -6,6 +6,7 @@
 #ifndef ARM_ARCH_CAPABILITIES_H
 #define ARM_ARCH_CAPABILITIES_H
=20
+#include <stdbool=2Eh>
 #include <stdint=2Eh>
 #include <xen/sysctl=2Eh>
=20
@@ -25,4 +26,20 @@ unsigned int arch_capabilities_arm_sve(unsigned int arc=
h_capabilities)
 #endif
 }
=20
+/*
+ * Generic test for any single-bit XEN_SYSCTL_PHYSCAP_ARM_* capability, e=
=2Eg=2E
+ * arch_capabilities_arm_has(caps, XEN_SYSCTL_PHYSCAP_ARM_GIC_V2)=2E Mult=
i-bit
+ * fields (like the SVE vector length above) still need their own decoder=
=2E
+ */
+static inline
+bool arch_capabilities_arm_has(unsigned int arch_capabilities,
+                               unsigned int mask)
+{
+#if defined(__arm__) || defined(__aarch64__)
+    return !!(arch_capabilities & mask);
+#else
+    return false;
+#endif
+}
+
 #endif /* ARM_ARCH_CAPABILITIES_H */
diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm=
=2Ec
index 7e9f8a1bc3=2E=2E926d651857 100644
--- a/tools/libs/light/libxl_arm=2Ec
+++ b/tools/libs/light/libxl_arm=2Ec
@@ -196,9 +196,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
     LOG(DEBUG, " - Allocate %u SPIs", config->arch=2Enr_spis);
=20
     switch (d_config->b_info=2Earch_arm=2Egic_version) {
-    case LIBXL_GIC_VERSION_DEFAULT:
-        config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
-        break;
     case LIBXL_GIC_VERSION_V2:
         config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2;
         break;
@@ -1800,6 +1797,20 @@ int libxl__arch_domain_build_info_setdefault(libxl_=
_gc *gc,
     /* Trapping of unmapped accesses enabled by default=2E  */
     libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true);
=20
+    /* Pick the best GIC version available if none was requested=2E */
+    if (b_info->arch_arm=2Egic_version =3D=3D LIBXL_GIC_VERSION_DEFAULT) =
{
+        if (arch_capabilities_arm_has(physinfo->arch_capabilities,
+                                      XEN_SYSCTL_PHYSCAP_ARM_GIC_V3))
+            b_info->arch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V3;
+        else if (arch_capabilities_arm_has(physinfo->arch_capabilities,
+                                           XEN_SYSCTL_PHYSCAP_ARM_GIC_V2)=
)
+            b_info->arch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V2;
+        else {
+            LOG(ERROR, "No supported GIC version found on this host");
+            return ERROR_FAIL;
+        }
+    }
+
     /* Sanitise SVE parameter */
     if (b_info->arch_arm=2Esve_vl) {
         unsigned int max_sve_vl =3D
diff --git a/tools/python/xen/lowlevel/xc/xc=2Ec b/tools/python/xen/lowlev=
el/xc/xc=2Ec
index 7a4bf54597=2E=2Ee9e1d8572e 100644
--- a/tools/python/xen/lowlevel/xc/xc=2Ec
+++ b/tools/python/xen/lowlevel/xc/xc=2Ec
@@ -163,7 +163,25 @@ static PyObject *pyxc_domain_create(XcObject *self,
                                       ~(XEN_X86_EMU_VPCI |
                                         XEN_X86_EMU_USE_PIRQ);
 #elif defined (__arm__) || defined(__aarch64__)
-    config=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
+    {
+        xc_physinfo_t pinfo;
+
+        if ( xc_physinfo(self->xc_handle, &pinfo) !=3D 0 )
+            return pyxc_error_to_exception(self->xc_handle);
+
+        if ( arch_capabilities_arm_has(pinfo=2Earch_capabilities,
+                                       XEN_SYSCTL_PHYSCAP_ARM_GIC_V3) )
+            config=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3;
+        else if ( arch_capabilities_arm_has(pinfo=2Earch_capabilities,
+                                            XEN_SYSCTL_PHYSCAP_ARM_GIC_V2=
) )
+            config=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2;
+        else
+        {
+            errno =3D EINVAL;
+            PyErr_SetFromErrno(xc_error_obj);
+            return NULL;
+        }
+    }
 #else
 #error Architecture not supported
 #endif
--=20
2=2E53=2E0



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.2670.4ba10b5e3851bf08.1a01f2fd658.85baa265d6fc9dfa=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:40:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:40:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396458.1634312 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24e-0003lA-QX; Thu, 20 Aug 2026 12:40:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396458.1634312; Thu, 20 Aug 2026 12:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24e-0003l3-NP; Thu, 20 Aug 2026 12:40:48 +0000
Received: by outflank-mailman (input) for mailman id 1396458;
 Thu, 20 Aug 2026 12:40:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3@swg.vates.tech>)
 id 1wx24d-0003j1-1k
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:40:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx24c-008qNG-EX
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:40:46 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3@swg.vates.tech>)
 id 6a86f5c5-bab6-0a2a0a5309dd-0a2a4505e1e4-26
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:46 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3@swg.vates.tech>)
 id 6a86f5ce-4cb1-0a2a45050019-b9ff1c12b505-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:46 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2fd9fb000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:40:24 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 02F4A83989;
 Thu, 20 Aug 2026 14:40:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=TYfHH6AY5gJ0YFZpBFDfEpxwM5KwAzaJCDzHSqDnKYE=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=t4UBe4cAOzVA4sGeexuhz96I9n53kQdWZzKpubJlkonUPogcOh4rX+ATKRpYook5H1bJG2f3/
 peqc872UagvVDiclnf2rgzk7K/1sPLOaRMQavGVBko3K1glmUnq96MeNWq2z0bLz4YN7Ib971Ol
 82zql2PZ+1JNvXokHuDi66cY0Qo4YlAmHHMkTefCq1fgt5YIBHW0eQEd3RXZuE/6/FDKtoYh3wa
 neOi6HIZtfY4ui3vwtLO/GElCtxy1MpItjr1/aq3QFXfAEU/zqhHY1uOKefhL+Wc1+KdiA+nxia
 IldwUiNlpQwfB/NqMQGyyOKwix04HZtj0kM0cX90XTQg==
X-Zone-Loop: 03c34a37426da6c72bd7e4768ef0942763b17482e873
x-campaign-type: default
x-transaction-id: b3a31fd2-8af8-49c1-aed9-8fc2d85d6069
x-swg-uid: 01-5be70770-e800-4105-8a7d-bf8344122e84
X-Mailer: Sweego
Message-ID:
 <1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3@vates.tech>
x-swg-bid: 1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 4/6] xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from the ABI
Date: Thu, 20 Aug 2026 14:40:14 +0200
In-Reply-To: <20260820124016.2033421-1-julian.vetter@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2671.a7a54a9d4d64e52d.1a01f2fd7f0.256528c5dc464174=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229624304
X-purgate-ID: tlsNG-c201ff/1787229646-2551A2A1-9B386F38/0/0
X-purgate-type: clean
X-purgate-size: 7880

---=Part.2671.a7a54a9d4d64e52d.1a01f2fd7f0.256528c5dc464174=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Now that the toolstack always resolves a concrete GIC_V2 or GIC_V3
before calling createdomain, nothing on the Xen side needs to resolve
GIC_NATIVE either:

 * A new gic_domctl_version() helper returns the XEN_DOMCTL_CONFIG_GIC_*
   value matching the host's gic_hw_version()=2E
 * arch_sanitise_domain_config() uses it to validate that the requested
   version is compatible with the hardware, rather than resolving
   GIC_NATIVE and writing the result back into config->arch=2Egic_version=
=2E
   There's currently no support to run a guest on a GIC version other
   than the host's, so this is just an equality check=2E
 * create_dom0() and arch_parse_dom0less_node(), which both always want
   a vGIC that exactly matches the hardware, use the same helper instead
   of GIC_NATIVE=2E

With nothing left resolving or relying on it, drop
XEN_DOMCTL_CONFIG_GIC_NATIVE from the public ABI=2E Every caller must now
request a concrete GIC_V2 or GIC_V3=2E

This is an incompatible change for any toolstack still passing 0
(formerly GIC_NATIVE) expecting Xen to auto-select a version=2E Add a
CHANGELOG=2Emd entry, noting that available GIC versions can be queried
via XEN_SYSCTL_physinfo=2E

Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
---
Changes in v4:
- Don't bump XEN_DOMCTL_INTERFACE_VERSION for this: it's an API change,
  not an ABI one=2E Leave a comment marking XEN_DOMCTL_CONFIG_GIC_NATIVE
  as removed instead, and mention in the CHANGELOG=2Emd entry that
  available GIC versions can be queried via XEN_SYSCTL_physinfo
- Simplify comment above the GIC version check
- Report requested GIC version in the "Unsupported GIC version" print
---
 CHANGELOG=2Emd                   |  4 ++++
 xen/arch/arm/dom0less-build=2Ec  |  3 ++-
 xen/arch/arm/domain=2Ec          | 24 ++++++++----------------
 xen/arch/arm/domain_build=2Ec    |  3 ++-
 xen/arch/arm/gic=2Ec             | 16 ++++++++++++++++
 xen/arch/arm/include/asm/gic=2Eh |  6 ++++++
 xen/include/public/arch-arm=2Eh  |  2 +-
 7 files changed, 39 insertions(+), 19 deletions(-)

diff --git a/CHANGELOG=2Emd b/CHANGELOG=2Emd
index 356be88351=2E=2E5dfa242030 100644
--- a/CHANGELOG=2Emd
+++ b/CHANGELOG=2Emd
@@ -13,6 +13,10 @@ The format is based on [Keep a Changelog](https://keepa=
changelog=2Ecom/en/1=2E0=2E0/)
 ### Added
=20
 ### Removed
+ - On Arm:
+   - XEN_DOMCTL_CONFIG_GIC_NATIVE has been removed=2E Toolstacks must now
+     explicitly request GIC_V2 or GIC_V3 when creating a domain=2E
+     Available GIC versions can be queried via XEN_SYSCTL_physinfo=2E
  - On x86:
    - The kexec "v1" interface, which was declared obsolete in Xen 4=2E4 (=
2013)=2E
      The only known user was the classic-xen fork of Linux=2E  This does =
not
diff --git a/xen/arch/arm/dom0less-build=2Ec b/xen/arch/arm/dom0less-build=
=2Ec
index 3f48f74226=2E=2E5b01843db4 100644
--- a/xen/arch/arm/dom0less-build=2Ec
+++ b/xen/arch/arm/dom0less-build=2Ec
@@ -23,6 +23,7 @@
 #include <asm/arm64/sve=2Eh>
 #include <asm/domain_build=2Eh>
 #include <asm/firmware/sci=2Eh>
+#include <asm/gic=2Eh>
 #include <asm/grant_table=2Eh>
 #include <asm/setup=2Eh>
=20
@@ -368,7 +369,7 @@ int __init arch_parse_dom0less_node(struct dt_device_n=
ode *node,
     unsigned int flags =3D bd->create_flags;
     uint32_t val;
=20
-    d_cfg->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
+    d_cfg->arch=2Egic_version =3D gic_domctl_version();
     d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;
=20
     if ( domu_dt_sci_parse(node, d_cfg) )
diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec
index baa3a5d708=2E=2E94f8f077e9 100644
--- a/xen/arch/arm/domain=2Ec
+++ b/xen/arch/arm/domain=2Ec
@@ -609,23 +609,15 @@ int arch_sanitise_domain_config(struct xen_domctl_cr=
eatedomain *config)
         return -EINVAL;
     }
=20
-    /* Fill in the native GIC version, passed back to the toolstack=2E */
-    if ( config->arch=2Egic_version =3D=3D XEN_DOMCTL_CONFIG_GIC_NATIVE )
+    /*
+     * There's currently no support to run a guest on a GIC version other
+     * than the host's=2E
+     */
+    if ( config->arch=2Egic_version !=3D gic_domctl_version() )
     {
-        switch ( gic_hw_version() )
-        {
-        case GIC_V2:
-            config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2;
-            break;
-
-        case GIC_V3:
-            config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3;
-            break;
-
-        default:
-            ASSERT_UNREACHABLE();
-            return -EINVAL;
-        }
+        dprintk(XENLOG_INFO, "Unsupported GIC version %u\n",
+                config->arch=2Egic_version);
+        return -EINVAL;
     }
=20
     /* max_vcpus depends on the GIC version, and Xen's compiled limit=2E =
*/
diff --git a/xen/arch/arm/domain_build=2Ec b/xen/arch/arm/domain_build=2Ec
index 72d5316180=2E=2Ecd9509d7b9 100644
--- a/xen/arch/arm/domain_build=2Ec
+++ b/xen/arch/arm/domain_build=2Ec
@@ -26,6 +26,7 @@
 #include <xen/warning=2Eh>
 #include <xen/static-shmem=2Eh>
 #include <asm/device=2Eh>
+#include <asm/gic=2Eh>
 #include <asm/setup=2Eh>
 #include <asm/tee/tee=2Eh>
 #include <asm/pci=2Eh>
@@ -1960,7 +1961,7 @@ void __init create_dom0(void)
     int rc;
=20
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
-    dom0_cfg=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE;
+    dom0_cfg=2Earch=2Egic_version =3D gic_domctl_version();
     dom0_cfg=2Earch=2Enr_spis =3D vgic_def_nr_spis();
     dom0_cfg=2Earch=2Etee_type =3D tee_get_type();
     dom0_cfg=2Emax_vcpus =3D dom0_max_vcpus();
diff --git a/xen/arch/arm/gic=2Ec b/xen/arch/arm/gic=2Ec
index ee75258fc3=2E=2Efc55a65159 100644
--- a/xen/arch/arm/gic=2Ec
+++ b/xen/arch/arm/gic=2Ec
@@ -56,6 +56,22 @@ enum gic_version gic_hw_version(void)
    return gic_hw_ops->info->hw_version;
 }
=20
+uint8_t gic_domctl_version(void)
+{
+    switch ( gic_hw_version() )
+    {
+    case GIC_V2:
+        return XEN_DOMCTL_CONFIG_GIC_V2;
+
+    case GIC_V3:
+        return XEN_DOMCTL_CONFIG_GIC_V3;
+
+    default:
+        ASSERT_UNREACHABLE();
+        return 0;
+    }
+}
+
 unsigned int gic_number_lines(void)
 {
     return gic_hw_ops->info->nr_lines;
diff --git a/xen/arch/arm/include/asm/gic=2Eh b/xen/arch/arm/include/asm/g=
ic=2Eh
index ff22dea40d=2E=2Ede6eabfadd 100644
--- a/xen/arch/arm/include/asm/gic=2Eh
+++ b/xen/arch/arm/include/asm/gic=2Eh
@@ -262,6 +262,12 @@ DECLARE_PER_CPU(uint64_t, lr_mask);
=20
 extern enum gic_version gic_hw_version(void);
=20
+/*
+ * The XEN_DOMCTL_CONFIG_GIC_* value matching the GIC version actually
+ * present on this host=2E
+ */
+extern uint8_t gic_domctl_version(void);
+
 /* Program the IRQ type into the GIC */
 void gic_set_irq_type(struct irq_desc *desc, unsigned int type);
=20
diff --git a/xen/include/public/arch-arm=2Eh b/xen/include/public/arch-arm=
=2Eh
index 7d6f87e8b2=2E=2Ee95fa33eb7 100644
--- a/xen/include/public/arch-arm=2Eh
+++ b/xen/include/public/arch-arm=2Eh
@@ -319,7 +319,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
  * struct xen_arch_domainconfig's ABI is covered by
  * XEN_DOMCTL_INTERFACE_VERSION=2E
  */
-#define XEN_DOMCTL_CONFIG_GIC_NATIVE    0
+/*      XEN_DOMCTL_CONFIG_GIC_NATIVE    0 - removed in Xen 4=2E23 */
 #define XEN_DOMCTL_CONFIG_GIC_V2        1
 #define XEN_DOMCTL_CONFIG_GIC_V3        2
=20
--=20
2=2E53=2E0



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.2671.a7a54a9d4d64e52d.1a01f2fd7f0.256528c5dc464174=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:40:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:40:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396463.1634322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24h-00042N-21; Thu, 20 Aug 2026 12:40:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396463.1634322; Thu, 20 Aug 2026 12:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24g-00042G-VL; Thu, 20 Aug 2026 12:40:50 +0000
Received: by outflank-mailman (input) for mailman id 1396463;
 Thu, 20 Aug 2026 12:40:50 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3@swg.vates.tech>)
 id 1wx24g-00040t-3v
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:40:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx24f-008qNG-Gc
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:40:49 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3@swg.vates.tech>)
 id 6a86f5c5-bab6-0a2a0a5309dd-0a2a4505e1e4-34
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:49 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3@swg.vates.tech>)
 id 6a86f5ce-4cb1-0a2a45050019-b9ff1c12b505-4
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:49 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2fdb8f000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:40:25 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 7D68783985;
 Thu, 20 Aug 2026 14:40:24 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=DTVomOkD5+5YJdD9EWOSdlFdsPA/8xprZDIOodGFay8=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=ETzAuIll5uwg3xJboQeOa62mN+KPEaE+R7XbZaquaJ7JCzay3skW4i7a2JHQJOnj4rvE0drAP
 p+Szx4YT0/KhrSU0oB8/tep/daDqepSO9FgR9JWDf21Klr+1K2IRLIrXbNaPUKm47+lrQ/5YWB5
 ilpW/w3ganfh+DAksNbmfuaGJSaawFtbh9QqxcradXFiuIO0A3I3xocfDuXIA+1GC0x/0OGiL4P
 4dWPLor01GWRMWtG7KQ3URsdQwQoJCIdS4PjU6tLyjrlrcYB/Mxz5lsDkA8KfUDAJJuzXyWV9PU
 z4axkEi4j0VEl6lCUlsJ8jfyotf1GLzB2l3/TXzXk/SA==
X-Zone-Loop: c8859e5d23719a7eb7be0aaef7fb6f46a2c4f4e1e019
x-campaign-type: default
x-transaction-id: fd2726d0-0594-493c-8e4f-41542bbfcab5
x-swg-uid: 01-67747d29-6e6a-4a09-bb53-a995af605499
X-Mailer: Sweego
Message-ID:
 <1787229625.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3@vates.tech>
x-swg-bid: 1787229625.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 5/6] xen/arm: report clock_frequency via sysctl physinfo, not createdomain
Date: Thu, 20 Aug 2026 14:40:15 +0200
In-Reply-To: <20260820124016.2033421-1-julian.vetter@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2672.a59d4b9a9baa91da.1a01f2fd9fa.d7cfef382de3e7c6=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229624826
X-purgate-ID: tlsNG-c201ff/1787229649-71EA92A1-9075DEE3/0/0
X-purgate-type: clean
X-purgate-size: 13207

---=Part.2672.a59d4b9a9baa91da.1a01f2fd9fa.d7cfef382de3e7c6=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The xen_arch_domainconfig=2Eclock_frequency value is populated in
domain_vtimer_init() during XEN_DOMCTL_createdomain from the global
timer_dt_clock_frequency, which comes from the host's DT timer node and
has nothing to do with the domain being created=2E Like now removed
GIC_NATIVE resolution, this is a host-wide system property being
smuggled out through a domain-creation IN struct=2E

Expose it instead as a new arch_clock_frequency_hz field in
XEN_SYSCTL_physinfo, populated via arch_do_physinfo(), and mirroring how
the GIC capability bits were already moved there=2E

Rather than making the field dependant on DT boot, make Xen always
report the timer frequency, either via the DT "clock-frequency" node, or
directly via CNTFRQ_EL0=2E preinit_xen_time() already computes cpu_khz for
every boot path=2E The renamed timer_clock_frequency_hz now captures
whichever of the two produced that value, in full Hz precision, instead
of only recording the DT case=2E So, ACPI guests get a real value too,
allowing to drop the special case=2E

Although the CNTFRQ_EL0 register is 64 bits wide, and some current timer
implementations run at 1GHz, a 32bit value is sufficient to store the
timer value, because it only mirrors the DT 'clock-frequency' property,
which the bindings define as a single 32-bit cell=2E The
XEN_DOMCTL_INTERFACE_VERSION doesn't need to be bumped, because only a
previously zero'ed / ignored field is now used=2E

The xen_arch_domainconfig parameter passed to domain_vtimer_init() is no
longer needed, so drop that parameter entirely=2E libxl now fetches the
frequency via libxl_get_physinfo() in libxl__arch_domain_save_config()
instead of reading it back out of the createdomain reply=2E The OCaml
xen_arch_domainconfig mirror drops the field too=2E

Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
---
Changes in v4:
- Rename timer_dt_clock_frequency to timer_clock_frequency_hz
- Always populate the frequency, and record it on the CNTFRQ_EL0 path in
  preinit_xen_time(), instead of only when booting via DT
- ACPI guests now get a real frequency value instead of 0
---
 tools/libs/light/libxl=2Ec          |  1 +
 tools/libs/light/libxl_arm=2Ec      | 13 ++++++++++++-
 tools/libs/light/libxl_types=2Eidl  |  1 +
 tools/ocaml/libs/xc/xenctrl=2Eml    |  1 -
 tools/ocaml/libs/xc/xenctrl=2Emli   |  1 -
 xen/arch/arm/domain=2Ec             |  2 +-
 xen/arch/arm/include/asm/time=2Eh   |  6 +++---
 xen/arch/arm/include/asm/vtimer=2Eh |  3 +--
 xen/arch/arm/sysctl=2Ec             |  3 +++
 xen/arch/arm/time=2Ec               |  7 ++++---
 xen/arch/arm/vtimer=2Ec             |  4 +---
 xen/include/public/arch-arm=2Eh     | 16 +---------------
 xen/include/public/sysctl=2Eh       | 12 +++++++++++-
 13 files changed, 39 insertions(+), 31 deletions(-)

diff --git a/tools/libs/light/libxl=2Ec b/tools/libs/light/libxl=2Ec
index a1fe16274d=2E=2Eec7e6d3f65 100644
--- a/tools/libs/light/libxl=2Ec
+++ b/tools/libs/light/libxl=2Ec
@@ -410,6 +410,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo =
*physinfo)
     physinfo->cap_gnttab_v2 =3D
         !!(xcphysinfo=2Ecapabilities & XEN_SYSCTL_PHYSCAP_gnttab_v2);
     physinfo->arch_capabilities =3D xcphysinfo=2Earch_capabilities;
+    physinfo->arch_clock_frequency_hz =3D xcphysinfo=2Earch_clock_frequen=
cy_hz;
=20
     GC_FREE;
     return 0;
diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm=
=2Ec
index 926d651857=2E=2Ecf441f0737 100644
--- a/tools/libs/light/libxl_arm=2Ec
+++ b/tools/libs/light/libxl_arm=2Ec
@@ -252,6 +252,9 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
                                    libxl__domain_build_state *state,
                                    const struct xen_domctl_createdomain *=
config)
 {
+    libxl_physinfo info;
+    int rc;
+
     switch (config->arch=2Egic_version) {
     case XEN_DOMCTL_CONFIG_GIC_V2:
         d_config->b_info=2Earch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V=
2;
@@ -264,7 +267,15 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
         return ERROR_FAIL;
     }
=20
-    state->clock_frequency =3D config->arch=2Eclock_frequency;
+    libxl_physinfo_init(&info);
+    rc =3D libxl_get_physinfo(CTX, &info);
+    if (rc) {
+        LOG(ERROR, "failed to get physinfo");
+        libxl_physinfo_dispose(&info);
+        return ERROR_FAIL;
+    }
+    state->clock_frequency =3D info=2Earch_clock_frequency_hz;
+    libxl_physinfo_dispose(&info);
=20
     return 0;
 }
diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl_t=
ypes=2Eidl
index a7893460f0=2E=2Ee24a3253f8 100644
--- a/tools/libs/light/libxl_types=2Eidl
+++ b/tools/libs/light/libxl_types=2Eidl
@@ -1201,6 +1201,7 @@ libxl_physinfo =3D Struct("physinfo", [
     ("cap_gnttab_v1", bool),
     ("cap_gnttab_v2", bool),
     ("arch_capabilities", uint32),
+    ("arch_clock_frequency_hz", uint32), # ARM only
     ], dir=3DDIR_OUT)
=20
 libxl_connectorinfo =3D Struct("connectorinfo", [
diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr=
l=2Eml
index 147afa62c2=2E=2E582897af6d 100644
--- a/tools/ocaml/libs/xc/xenctrl=2Eml
+++ b/tools/ocaml/libs/xc/xenctrl=2Eml
@@ -32,7 +32,6 @@ type xen_arm_arch_domainconfig =3D
   {
     gic_version: int;
     nr_spis: int;
-    clock_frequency: int32;
   }
=20
 type x86_arch_emulation_flags =3D
diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct=
rl=2Emli
index 9fccb2c2c2=2E=2E9414b87164 100644
--- a/tools/ocaml/libs/xc/xenctrl=2Emli
+++ b/tools/ocaml/libs/xc/xenctrl=2Emli
@@ -26,7 +26,6 @@ type vcpuinfo =3D {
 type xen_arm_arch_domainconfig =3D {
   gic_version: int;
   nr_spis: int;
-  clock_frequency: int32;
 }
=20
 type x86_arch_emulation_flags =3D
diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec
index 94f8f077e9=2E=2E96dc65270b 100644
--- a/xen/arch/arm/domain=2Ec
+++ b/xen/arch/arm/domain=2Ec
@@ -710,7 +710,7 @@ int arch_domain_create(struct domain *d,
     if ( (rc =3D domain_vgic_init(d, config->arch=2Enr_spis)) !=3D 0 )
         goto fail;
=20
-    if ( (rc =3D domain_vtimer_init(d, &config->arch)) !=3D 0 )
+    if ( (rc =3D domain_vtimer_init(d)) !=3D 0 )
         goto fail;
=20
     if ( (rc =3D tee_domain_init(d, config->arch=2Etee_type)) !=3D 0 )
diff --git a/xen/arch/arm/include/asm/time=2Eh b/xen/arch/arm/include/asm/=
time=2Eh
index c194dbb9f5=2E=2E07091648a3 100644
--- a/xen/arch/arm/include/asm/time=2Eh
+++ b/xen/arch/arm/include/asm/time=2Eh
@@ -87,10 +87,10 @@ enum timer_ppi
 };
=20
 /*
- * Value of "clock-frequency" in the DT timer node if present=2E
- * 0 means the property doesn't exist=2E
+ * The timer frequency, in Hz, that Xen ended up using: either the DT
+ * "clock-frequency" override, or a direct CNTFRQ_EL0 read=2E
  */
-extern uint32_t timer_dt_clock_frequency;
+extern uint32_t timer_clock_frequency_hz;
=20
 /* Get one of the timer IRQ number */
 unsigned int timer_get_irq(enum timer_ppi ppi);
diff --git a/xen/arch/arm/include/asm/vtimer=2Eh b/xen/arch/arm/include/as=
m/vtimer=2Eh
index 9d4fb4c6e8=2E=2E6bbfcf4e69 100644
--- a/xen/arch/arm/include/asm/vtimer=2Eh
+++ b/xen/arch/arm/include/asm/vtimer=2Eh
@@ -20,8 +20,7 @@
 #ifndef __ARCH_ARM_VTIMER_H__
 #define __ARCH_ARM_VTIMER_H__
=20
-extern int domain_vtimer_init(struct domain *d,
-                              struct xen_arch_domainconfig *config);
+extern int domain_vtimer_init(struct domain *d);
 extern int vcpu_vtimer_init(struct vcpu *v);
 extern bool vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
 extern void virt_timer_save(struct vcpu *v);
diff --git a/xen/arch/arm/sysctl=2Ec b/xen/arch/arm/sysctl=2Ec
index 8411deb7e2=2E=2E789ad78a14 100644
--- a/xen/arch/arm/sysctl=2Ec
+++ b/xen/arch/arm/sysctl=2Ec
@@ -15,6 +15,7 @@
=20
 #include <asm/arm64/sve=2Eh>
 #include <asm/gic=2Eh>
+#include <asm/time=2Eh>
 #include <asm/vgic=2Eh>
=20
 #include <public/sysctl=2Eh>
@@ -26,6 +27,8 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     pi->arch_capabilities |=3D MASK_INSR(sve_encode_vl(get_sys_vl_len()),
                                        XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
=20
+    pi->arch_clock_frequency_hz =3D timer_clock_frequency_hz;
+
     /*
      * The GIC version(s) we're happy creating guests with=2E Right now f=
or
      * simplicity it is tied to the active hardware version, but this wil=
l
diff --git a/xen/arch/arm/time=2Ec b/xen/arch/arm/time=2Ec
index 6955b2788f=2E=2Ebcbd038cb2 100644
--- a/xen/arch/arm/time=2Ec
+++ b/xen/arch/arm/time=2Ec
@@ -35,7 +35,7 @@ uint64_t __read_mostly boot_count;
  * register-mapped time source in the SoC=2E */
 unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz=2E */
=20
-uint32_t __read_mostly timer_dt_clock_frequency;
+uint32_t __read_mostly timer_clock_frequency_hz;
=20
 static unsigned int timer_irq[MAX_TIMER_PPI];
=20
@@ -120,7 +120,7 @@ static void __init preinit_dt_xen_time(void)
     {
         cpu_khz =3D DIV_ROUND(rate, 1000);
         validate_timer_frequency();
-        timer_dt_clock_frequency =3D rate;
+        timer_clock_frequency_hz =3D rate;
     }
 }
=20
@@ -136,7 +136,8 @@ void __init preinit_xen_time(void)
=20
     if ( !cpu_khz )
     {
-        cpu_khz =3D DIV_ROUND(READ_SYSREG(CNTFRQ_EL0) & CNTFRQ_MASK, 1000=
);
+        timer_clock_frequency_hz =3D READ_SYSREG(CNTFRQ_EL0) & CNTFRQ_MAS=
K;
+        cpu_khz =3D DIV_ROUND(timer_clock_frequency_hz, 1000);
         validate_timer_frequency();
     }
=20
diff --git a/xen/arch/arm/vtimer=2Ec b/xen/arch/arm/vtimer=2Ec
index 2e85ff2b6e=2E=2E18f5676158 100644
--- a/xen/arch/arm/vtimer=2Ec
+++ b/xen/arch/arm/vtimer=2Ec
@@ -52,7 +52,7 @@ static void virt_timer_expired(void *data)
     perfc_incr(vtimer_virt_inject);
 }
=20
-int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *co=
nfig)
+int domain_vtimer_init(struct domain *d)
 {
     d->arch=2Evirt_timer_base=2Eoffset =3D get_cycles();
     d->arch=2Evirt_timer_base=2Enanoseconds =3D
@@ -60,8 +60,6 @@ int domain_vtimer_init(struct domain *d, struct xen_arch=
_domainconfig *config)
     d->time_offset=2Eseconds =3D d->arch=2Evirt_timer_base=2Enanoseconds;
     do_div(d->time_offset=2Eseconds, 1000000000);
=20
-    config->clock_frequency =3D timer_dt_clock_frequency;
-
     /*
      * Per the ACPI specification, providing a secure EL1 timer
      * interrupt is optional and will be ignored by non-secure OS=2E
diff --git a/xen/include/public/arch-arm=2Eh b/xen/include/public/arch-arm=
=2Eh
index e95fa33eb7=2E=2Ec7118e7884 100644
--- a/xen/include/public/arch-arm=2Eh
+++ b/xen/include/public/arch-arm=2Eh
@@ -335,7 +335,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA    2
=20
 struct xen_arch_domainconfig {
-    /* IN/OUT */
+    /* IN */
     uint8_t gic_version;
     /* IN - Contains SVE vector length divided by 128 */
     uint8_t sve_vl;
@@ -343,20 +343,6 @@ struct xen_arch_domainconfig {
     uint16_t tee_type;
     /* IN */
     uint32_t nr_spis;
-    /*
-     * OUT
-     * Based on the property clock-frequency in the DT timer node=2E
-     * The property may be present when the bootloader/firmware doesn't
-     * set correctly CNTFRQ which hold the timer frequency=2E
-     *
-     * As it's not possible to trap this register, we have to replicate
-     * the value in the guest DT=2E
-     *
-     * =3D 0 =3D> property not present
-     * > 0 =3D> Value of the property
-     *
-     */
-    uint32_t clock_frequency;
     /* IN */
     uint8_t arm_sci_type;
     /* IN */
diff --git a/xen/include/public/sysctl=2Eh b/xen/include/public/sysctl=2Eh
index d20ebf3644=2E=2E04cb1f3bdc 100644
--- a/xen/include/public/sysctl=2Eh
+++ b/xen/include/public/sysctl=2Eh
@@ -120,7 +120,17 @@ struct xen_sysctl_physinfo {
     uint32_t cpu_khz;
     uint32_t capabilities;/* XEN_SYSCTL_PHYSCAP_??? */
     uint32_t arch_capabilities;/* XEN_SYSCTL_PHYSCAP_{X86,ARM,=2E=2E=2E}_=
??? */
-    uint32_t pad;
+    /*
+     * ARM only=2E The timer frequency, in Hz, that Xen is using=2E Eithe=
r
+     * "clock-frequency" property from DT timer node or CNTFRQ_EL0 value=
=2E
+     *
+     * As it's not possible to trap this register, we have to replicate t=
he
+     * value in the guest DT=2E
+     *
+     * =3D 0 =3D> non-ARM, or the frequency could not be determined=2E
+     * > 0 =3D> The frequency, in Hz=2E
+     */
+    uint32_t arch_clock_frequency_hz;
     uint64_aligned_t total_pages;
     uint64_aligned_t free_pages;
     uint64_aligned_t scrub_pages;
--=20
2=2E53=2E0



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.2672.a59d4b9a9baa91da.1a01f2fd9fa.d7cfef382de3e7c6=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 12:40:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 12:40:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396465.1634330 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24k-0004Lv-Aq; Thu, 20 Aug 2026 12:40:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396465.1634330; Thu, 20 Aug 2026 12:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx24k-0004Lk-7p; Thu, 20 Aug 2026 12:40:54 +0000
Received: by outflank-mailman (input) for mailman id 1396465;
 Thu, 20 Aug 2026 12:40:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fdd85000c4f3@swg.vates.tech>)
 id 1wx24j-0004Jq-Ag
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 12:40:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx24i-0023VV-NS
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:40:52 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fdd85000c4f3@swg.vates.tech>)
 id 6a86f5d0-2eae-0a2a0a5409dd-0a2a4502d090-14
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:52 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f2fdd85000c4f3@swg.vates.tech>)
 id 6a86f5d4-6ca4-0a2a45020019-b9ff1c239b27-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 14:40:52 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f2fdd85000c4f3.00b for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 12:40:25 +0000
Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id E7A4A83989;
 Thu, 20 Aug 2026 14:40:24 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=YtcSxQqS4YFzBpnvn0pxDx3PvCBaPasOhXRJS3dyCSo=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=GVCkzAd3oLzRsafmD67UNnw6ywsYgc62WM13pARht+ZRqoOB6g6RZwfVIx3/o7vZgvYXmXbZP
 uwg+hlNUhpQOw9Fgs4+kzXkR0De1jOxdTndd2XkrUeHTrvXzfmp481eYDAaWoGLoxQ+fC1tCzeI
 xuS9niTYlr42/H5Vrl16nOrtwx22RyAWmOMMc4iV94nsVdTS1yzQN09IkPbXoi6U+0/pn/OH0iO
 mvw/U1UDJF9KuoCp3moNcu54eiFNGMNuBVLBXm714YyF8dLAI3+W/a1jdq5V83X3/GmpAy232XA
 Jy/LWu6wR7zducgbcvw8I3Zqw1A2jITi+hntwMHVddiA==
X-Zone-Loop: ac3894678a425d9bb9f7558cac2eea210de9df955472
x-campaign-type: default
x-transaction-id: a83a3e2a-bd6e-470c-8e0d-3ebce06d27e3
x-swg-uid: 01-7118184d-6c94-4d3d-825f-9c28091b391c
X-Mailer: Sweego
Message-ID:
 <1787229625.8631fc262581453bbf619ec5b2062170.1a01f2fdd85000c4f3@vates.tech>
x-swg-bid: 1787229625.8631fc262581453bbf619ec5b2062170.1a01f2fdd85000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Julian Vetter <julian.vetter@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>,
	Guillaume Thouvenin <guillaume.thouvenin@vates.tech>,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>,
	Julian Vetter <julian.vetter@vates.tech>
Subject: [PATCH v4 6/6] xen: make config argument const
Date: Thu, 20 Aug 2026 14:40:16 +0200
In-Reply-To: <20260820124016.2033421-1-julian.vetter@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2673.17d84e18c8e413dd.1a01f2fdb97.87e72c8dfe524e6a=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787229625239
X-purgate-ID: tlsNG-720697/1787229652-313CC2AC-BFD0C47B/0/0
X-purgate-type: clean
X-purgate-size: 8348

---=Part.2673.17d84e18c8e413dd.1a01f2fdb97.87e72c8dfe524e6a=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

arch_sanitise_domain_config() validates the configuration requested by
the toolstack, and should not fill anything in=2E The config struct passed
to createdomain is supposed to be pure input=2E ARM used to abuse this
(GIC_NATIVE resolution, now removed) to smuggle output back to the
toolstack=2E Making the parameter const stops that type of abuse from
happening on any architecture=2E

The x86 implementation turned out to have its own instance of the same
issue=2E It set XEN_DOMCTL_CDF_oos_off into config->flags for non-HVM
guests=2E Since The sanitisation runs before the function domain_create()
copies config->flags into d->options, this relied on mutating the
toolstack's config to take effect=2E Move the default onto d->options
directly in arch_domain_create() (which runs after d->options is
populated), where all the remaining domain options are resolved=2E This
has the same effect and no mutation of the input config is required=2E

ARM, PPC and RISC-V need no equivalent change, Their implementations
were already read-only=2E

Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
Reviewed-by: Jan Beulich <jbeulich@suse=2Ecom> # x86
---
Changes in v4:
- Simplify arch_sanitise_domain_config() comment
---
 xen/arch/arm/domain=2Ec                   |  2 +-
 xen/arch/arm/firmware/sci=2Ec             |  2 +-
 xen/arch/arm/firmware/scmi-smc=2Ec        |  2 +-
 xen/arch/arm/include/asm/firmware/sci=2Eh |  6 +++---
 xen/arch/ppc/stubs=2Ec                    |  2 +-
 xen/arch/riscv/domain=2Ec                 |  2 +-
 xen/arch/x86/domain=2Ec                   | 16 ++++++++--------
 xen/include/xen/sched=2Eh                 |  5 ++---
 8 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec
index 96dc65270b=2E=2E71fff7692d 100644
--- a/xen/arch/arm/domain=2Ec
+++ b/xen/arch/arm/domain=2Ec
@@ -557,7 +557,7 @@ static bool v8r_el1_msa_domain_sanitise_config(
     }
 }
=20
-int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
+int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con=
fig)
 {
     unsigned int max_vcpus;
     unsigned int flags_required =3D (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_=
hap);
diff --git a/xen/arch/arm/firmware/sci=2Ec b/xen/arch/arm/firmware/sci=2Ec
index aa93cda7f0=2E=2Ef73ed06092 100644
--- a/xen/arch/arm/firmware/sci=2Ec
+++ b/xen/arch/arm/firmware/sci=2Ec
@@ -45,7 +45,7 @@ int sci_domain_init(struct domain *d, struct xen_domctl_=
createdomain *config)
     return cur_mediator->domain_init(d, config);
 }
=20
-int sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
+int sci_domain_sanitise_config(const struct xen_domctl_createdomain *conf=
ig)
 {
     if ( !cur_mediator )
         return 0;
diff --git a/xen/arch/arm/firmware/scmi-smc=2Ec b/xen/arch/arm/firmware/sc=
mi-smc=2Ec
index 0835ddeeec=2E=2Ea973679eaf 100644
--- a/xen/arch/arm/firmware/scmi-smc=2Ec
+++ b/xen/arch/arm/firmware/scmi-smc=2Ec
@@ -82,7 +82,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
 }
=20
 static int
-scmi_smc_domain_sanitise_config(struct xen_domctl_createdomain *config)
+scmi_smc_domain_sanitise_config(const struct xen_domctl_createdomain *con=
fig)
 {
     if ( config->arch=2Earm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE =
&&
          config->arch=2Earm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_=
SMC )
diff --git a/xen/arch/arm/include/asm/firmware/sci=2Eh b/xen/arch/arm/incl=
ude/asm/firmware/sci=2Eh
index 485ce211c9=2E=2E1d566be8e2 100644
--- a/xen/arch/arm/include/asm/firmware/sci=2Eh
+++ b/xen/arch/arm/include/asm/firmware/sci=2Eh
@@ -32,7 +32,7 @@ struct sci_mediator_ops {
      * it to sanitize domain SCI configuration parameters=2E
      * Optional=2E
      */
-    int (*domain_sanitise_config)(struct xen_domctl_createdomain *config)=
;
+    int (*domain_sanitise_config)(const struct xen_domctl_createdomain *c=
onfig);
=20
     /*
      * Called during domain destruction, releases all resources, that
@@ -101,7 +101,7 @@ int sci_domain_init(struct domain *d, struct xen_domct=
l_createdomain *config);
  * Sanitise domain configuration parameters=2E
  *
  */
-int sci_domain_sanitise_config(struct xen_domctl_createdomain *config);
+int sci_domain_sanitise_config(const struct xen_domctl_createdomain *conf=
ig);
=20
 /*
  * Destroy SCI domain instance=2E
@@ -162,7 +162,7 @@ static inline int sci_domain_init(struct domain *d,
 }
=20
 static inline int
-sci_domain_sanitise_config(struct xen_domctl_createdomain *config)
+sci_domain_sanitise_config(const struct xen_domctl_createdomain *config)
 {
     if ( config->arch=2Earm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE =
)
         return -EINVAL;
diff --git a/xen/arch/ppc/stubs=2Ec b/xen/arch/ppc/stubs=2Ec
index a333f06119=2E=2E82a289af85 100644
--- a/xen/arch/ppc/stubs=2Ec
+++ b/xen/arch/ppc/stubs=2Ec
@@ -162,7 +162,7 @@ void arch_vcpu_destroy(struct vcpu *v)
     BUG_ON("unimplemented");
 }
=20
-int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
+int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con=
fig)
 {
     BUG_ON("unimplemented");
 }
diff --git a/xen/arch/riscv/domain=2Ec b/xen/arch/riscv/domain=2Ec
index 2819ff4e7c=2E=2Ee096a53cb5 100644
--- a/xen/arch/riscv/domain=2Ec
+++ b/xen/arch/riscv/domain=2Ec
@@ -289,7 +289,7 @@ void sync_vcpu_execstate(struct vcpu *v)
     /* Nothing to do -- no lazy switching */
 }
=20
-int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
+int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con=
fig)
 {
     return 0;
 }
diff --git a/xen/arch/x86/domain=2Ec b/xen/arch/x86/domain=2Ec
index 4252339978=2E=2E35f591ab5d 100644
--- a/xen/arch/x86/domain=2Ec
+++ b/xen/arch/x86/domain=2Ec
@@ -590,7 +590,7 @@ void arch_vcpu_destroy(struct vcpu *v)
         ASSERT_UNREACHABLE();
 }
=20
-int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
+int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con=
fig)
 {
     bool hvm =3D config->flags & XEN_DOMCTL_CDF_hvm;
     bool hap =3D config->flags & XEN_DOMCTL_CDF_hap;
@@ -633,13 +633,6 @@ int arch_sanitise_domain_config(struct xen_domctl_cre=
atedomain *config)
         return -EINVAL;
     }
=20
-    if ( !hvm )
-        /*
-         * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear
-         * for HVM guests=2E
-         */
-        config->flags |=3D XEN_DOMCTL_CDF_oos_off;
-
     if ( nested_virt && !hvm_nested_virt_supported() )
     {
         dprintk(XENLOG_INFO, "Nested virt requested but not available\n")=
;
@@ -833,6 +826,13 @@ int arch_domain_create(struct domain *d,
=20
     spin_lock_init(&d->arch=2Ee820_lock);
=20
+    /*
+     * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear for H=
VM
+     * guests=2E
+     */
+    if ( !is_hvm_domain(d) )
+        d->options |=3D XEN_DOMCTL_CDF_oos_off;
+
     if ( d->domain_id && cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_=
121) )
     {
         if ( !opt_allow_unsafe )
diff --git a/xen/include/xen/sched=2Eh b/xen/include/xen/sched=2Eh
index 011292e9f7=2E=2E42a6bb545a 100644
--- a/xen/include/xen/sched=2Eh
+++ b/xen/include/xen/sched=2Eh
@@ -755,10 +755,9 @@ static inline void domain_update_node_affinity(struct=
 domain *d)
 }
=20
 /*
- * To be implemented by each architecture, sanity checking the configurat=
ion
- * and filling in any appropriate defaults=2E
+ * To be implemented by each architecture, sanity checking the configurat=
ion=2E
  */
-int arch_sanitise_domain_config(struct xen_domctl_createdomain *config);
+int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con=
fig);
=20
 /*
  * Create a domain: the configuration is only necessary for real domain
--=20
2=2E53=2E0



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.2673.17d84e18c8e413dd.1a01f2fdb97.87e72c8dfe524e6a=---


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 13:00:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 13:00:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396516.1634340 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2NN-00005d-P1; Thu, 20 Aug 2026 13:00:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396516.1634340; Thu, 20 Aug 2026 13:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2NN-00005W-M9; Thu, 20 Aug 2026 13:00:09 +0000
Received: by outflank-mailman (input) for mailman id 1396516;
 Thu, 20 Aug 2026 13:00:08 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3@swg.vates.tech>)
 id 1wx2NM-00005Q-1V
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:00:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx2NK-0026Ok-SH
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:00:06 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3@swg.vates.tech>)
 id 6a86fa56-2eae-0a2a0a5409dd-0a2a450293da-2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:00:06 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3@swg.vates.tech>)
 id 6a86fa56-6ca4-0a2a45020019-b9ff1c2292b9-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:00:06 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a01f41ca51000c4f3.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 20 Aug 2026 13:00:00 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id A3BAA81FCD;
 Thu, 20 Aug 2026 14:59:59 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=LMJ/We7AMBJ6vYMkpXgFRri8ls/9xx3OqrSUFlLzBf8=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=lcGR9zpeN0ksDovTDDd0nyhaO69fvhB2IsL9ThAVq+ZlI98YA93k+51JgSvHhLx7isAD+bDRw
 wahCQV/VjLJLuMDeSdeMm6vN7QQC8m9VS46FPsnu1QPno1NBQPNsIN3m3b6xa/vtdVUmxHtSOem
 aGpFo5ghr3F+v/TyWtBcSqCcmGq8VYO5hSr+upZZ+BlaIGMeemyGIN+oPXOMLfY9IYW2s2+JCZO
 x72Gnr36ZMLz8spGsImneleJtL9kyHI9NSUT1/CfcgwbXqw87a85LD2PdKkdrsi9ehQ2DwZzPUG
 onDNU67mP2U9V17NvS+9EKzCmkzjEAnXagKiQSoLjNkA==
X-Zone-Loop: 24f5647f6d506b4598fdcec18f9eceb7d772106d97ea
x-campaign-type: default
x-transaction-id: f63094c6-d676-4fee-a266-0c81496eb8dc
x-swg-uid: 01-e24ecdd6-f74c-45d5-a2c9-5bd044aa3503
X-Mailer: Sweego
Message-ID:
 <1787230800.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3@vates.tech>
x-swg-bid: 1787230800.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Thu, 20 Aug 2026 14:59:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, trenchboot-devel@googlegroups.com
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------5Ww4dIUB371KC8I2tJ3z0MDE"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787230799830
X-purgate-ID: tlsNG-720697/1787230806-319CB2AC-8063F3CF/0/0
X-purgate-type: clean
X-purgate-size: 12636

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------5Ww4dIUB371KC8I2tJ3z0MDE
Content-Type: multipart/mixed; boundary="------------nYIZYN4huIqDTa0K4qtwXuQG";
 protected-headers="v1"; hp="clear"
Message-ID: <692be7a2-9d21-4d6b-a260-f33643063575@vates.tech>
Date: Thu, 20 Aug 2026 14:59:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>, xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper
 <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, trenchboot-devel@googlegroups.com
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>

--------------nYIZYN4huIqDTa0K4qtwXuQG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDIvMDgvMjAyNiDDoCAxNToxNCwgU2VyZ2lpIERteXRydWsgYSDDqWNyaXTCoDoNCj4g
RnJvbTogTWljaGHFgiDFu3lnb3dza2kgPG1pY2hhbC56eWdvd3NraUAzbWRlYi5jb20+DQo+
IA0KPiBSZXBvcnQgVFhUIGNhcGFiaWxpdGllcyBzbyB0aGF0IGRvbTAgY2FuIHF1ZXJ5IHRo
ZSBJbnRlbCBUWFQgb3IgQU1EDQo+IFNLSU5JVCBzdXBwb3J0IGluZm9ybWF0aW9uIHVzaW5n
IHhsIGRtZXNnLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogTWljaGHFgiDFu3lnb3dza2kgPG1p
Y2hhbC56eWdvd3NraUAzbWRlYi5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IFNlcmdpaSBEbXl0
cnVrIDxzZXJnaWkuZG15dHJ1a0AzbWRlYi5jb20+DQo+IC0tLQ0KPiANCj4gTm90ZXM6DQo+
ICAgICAgdjQ6IGZpeGVkIGNvbmRpdGlvbnMgZm9yIG5vdCByZXBvcnRpbmcgY2FwYWJpbGl0
aWVzIChtYXRjaCBjb3JyZWN0IGNvbW1lbnRzKQ0KPiAgICAgIHY0OiBkZWZpbmUgR0VUU0VD
XyogbWFjcm9zIHVzZWQgb25seSBieSB4ZW4vYXJjaC94ODYvY3B1L2ludGVsLmMgaW4gdGhl
IGZpbGUgaXRzZWxmICh0byBub3QgZGVwZW5kIG9uIFNsYXVuY2gpDQo+ICAgICAgdjQ6IGRv
bid0IHBvc3Rwb25lIHJlc3RvcmluZyBzdGF0ZSBvZiBYODZfQ1I0X1NNWEUsIGRvIGl0IGJl
Zm9yZSBwcmludGluZyB0ZXN0IHJlc3VsdHMNCj4gDQo+ICAgeGVuL2FyY2gveDg2L2NwdS9h
bWQuYyAgIHwgMTYgKysrKysrKysrKysrKw0KPiAgIHhlbi9hcmNoL3g4Ni9jcHUvY3B1Lmgg
ICB8ICAxICsNCj4gICB4ZW4vYXJjaC94ODYvY3B1L2h5Z29uLmMgfCAgMSArDQo+ICAgeGVu
L2FyY2gveDg2L2NwdS9pbnRlbC5jIHwgNTAgKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKw0KPiAgIDQgZmlsZXMgY2hhbmdlZCwgNjggaW5zZXJ0aW9ucygrKQ0K
PiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMgYi94ZW4vYXJjaC94
ODYvY3B1L2FtZC5jDQo+IGluZGV4IDcwNzgzYzlhMGEuLjVlYTE2YWQ4YTggMTAwNjQ0DQo+
IC0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvYW1kLmMNCj4gKysrIGIveGVuL2FyY2gveDg2L2Nw
dS9hbWQuYw0KPiBAQCAtNjE3LDYgKzYxNywyMSBAQCB2b2lkIGFtZF9wcm9jZXNzX2ZyZXEo
Y29uc3Qgc3RydWN0IGNwdWluZm9feDg2ICpjLA0KPiAgIAkJKmxvd19taHogPSBhbWRfcGFy
c2VfZnJlcShjLT5mYW1pbHksIGxvKTsNCj4gICB9DQo+ICAgDQo+ICt2b2lkIGFtZF9sb2df
c2tpbml0KGNvbnN0IHN0cnVjdCBjcHVpbmZvX3g4NiAqYykNCj4gK3sNCj4gKyAgICAvKg0K
PiArICAgICAqIFJ1biBvbmx5IG9uIEJTUCBhbmQgbm90IGR1cmluZyByZXN1bWUgdG8gcmVw
b3J0IHRoZSBjYXBhYmlsaXR5IG9ubHkgb25jZS4NCj4gKyAgICAgKi8NCj4gKyAgICBpZiAo
IHN5c3RlbV9zdGF0ZSA9PSBTWVNfU1RBVEVfcmVzdW1lIHx8IHNtcF9wcm9jZXNzb3JfaWQo
KSApDQo+ICsgICAgICAgIHJldHVybjsNCj4gKw0KPiArICAgIHByaW50aygiQ1BVOiBTS0lO
SVQgY2FwYWJpbGl0eSAiKTsNCj4gKyAgICBpZiAoICF0ZXN0X2JpdChYODZfRkVBVFVSRV9T
S0lOSVQsICZib290X2NwdV9kYXRhLng4Nl9jYXBhYmlsaXR5KSApDQo+ICsgICAgICAgIHBy
aW50aygibm90IHN1cHBvcnRlZFxuIik7DQo+ICsgICAgZWxzZQ0KPiArICAgICAgICBwcmlu
dGsoInN1cHBvcnRlZFxuIik7DQo+ICt9DQo+ICsNCj4gICB2b2lkIGNmX2NoZWNrIGVhcmx5
X2luaXRfYW1kKHN0cnVjdCBjcHVpbmZvX3g4NiAqYykNCj4gICB7DQo+ICAgCWlmIChjID09
ICZib290X2NwdV9kYXRhKQ0KPiBAQCAtMTMyNSw2ICsxMzQwLDcgQEAgc3RhdGljIHZvaWQg
Y2ZfY2hlY2sgaW5pdF9hbWQoc3RydWN0IGNwdWluZm9feDg2ICpjKQ0KPiAgIAkJc2V0dXBf
Zm9yY2VfY3B1X2NhcChYODZfRkVBVFVSRV9YRU5fUkVQX01PVlNCKTsNCj4gICANCj4gICAJ
YW1kX2xvZ19mcmVxKGMpOw0KPiArCWFtZF9sb2dfc2tpbml0KGMpOw0KPiAgIH0NCg0KT24g
d2hpY2ggWGVuIGJyYW5jaCB0aGlzIHBhdGNoIGlzIGJhc2VkID8NCg0KZWFybHlfaW5pdF9h
bWQoKSBkb2Vzbid0IHNlZW0gdG8gaGF2ZSBhbWRfbG9nX2ZyZXEgKHdoaWNoIGlzIGluIGlu
aXRfYW1kIA0KaW5zdGVhZCkuDQoNCj4gICANCj4gICBjb25zdCBzdHJ1Y3QgY3B1X2RldiBf
X2luaXRjb25zdF9jZl9jbG9iYmVyIGFtZF9jcHVfZGV2ID0gew0KPiBkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gveDg2L2NwdS9jcHUuaCBiL3hlbi9hcmNoL3g4Ni9jcHUvY3B1LmgNCj4gaW5k
ZXggYmJlZGU1N2FiMC4uMTc5MzUxOTBiNyAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2
L2NwdS9jcHUuaA0KPiArKysgYi94ZW4vYXJjaC94ODYvY3B1L2NwdS5oDQo+IEBAIC0yMSw2
ICsyMSw3IEBAIGV4dGVybiBib29sIGRldGVjdF9leHRlbmRlZF90b3BvbG9neShzdHJ1Y3Qg
Y3B1aW5mb194ODYgKmMpOw0KPiAgIA0KPiAgIHZvaWQgY2ZfY2hlY2sgZWFybHlfaW5pdF9h
bWQoc3RydWN0IGNwdWluZm9feDg2ICpjKTsNCj4gICB2b2lkIGFtZF9sb2dfZnJlcShjb25z
dCBzdHJ1Y3QgY3B1aW5mb194ODYgKmMpOw0KPiArdm9pZCBhbWRfbG9nX3NraW5pdChjb25z
dCBzdHJ1Y3QgY3B1aW5mb194ODYgKmMpOw0KPiAgIHZvaWQgYW1kX2luaXRfZGVfY2ZnKGNv
bnN0IHN0cnVjdCBjcHVpbmZvX3g4NiAqYyk7DQo+ICAgdm9pZCBhbWRfaW5pdF9sZmVuY2Vf
ZGlzcGF0Y2godm9pZCk7DQo+ICAgdm9pZCBhbWRfaW5pdF9zc2JkKGNvbnN0IHN0cnVjdCBj
cHVpbmZvX3g4NiAqYyk7DQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY3B1L2h5Z29u
LmMgYi94ZW4vYXJjaC94ODYvY3B1L2h5Z29uLmMNCj4gaW5kZXggN2E5ZmMyNWQzMS4uNjA4
YTdjNDMxOSAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2NwdS9oeWdvbi5jDQo+ICsr
KyBiL3hlbi9hcmNoL3g4Ni9jcHUvaHlnb24uYw0KPiBAQCAtOTAsNiArOTAsNyBAQCBzdGF0
aWMgdm9pZCBjZl9jaGVjayBpbml0X2h5Z29uKHN0cnVjdCBjcHVpbmZvX3g4NiAqYykNCj4g
ICAJfQ0KPiAgIA0KPiAgIAlhbWRfbG9nX2ZyZXEoYyk7DQo+ICsJYW1kX2xvZ19za2luaXQo
Yyk7DQo+ICAgfQ0KPiAgIA0KPiAgIGNvbnN0IHN0cnVjdCBjcHVfZGV2IF9faW5pdGNvbnN0
X2NmX2Nsb2JiZXIgaHlnb25fY3B1X2RldiA9IHsNCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo
L3g4Ni9jcHUvaW50ZWwuYyBiL3hlbi9hcmNoL3g4Ni9jcHUvaW50ZWwuYw0KPiBpbmRleCA5
MGM5ZDM2MTg2Li5kZGIzNGMwYzAyIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC94ODYvY3B1
L2ludGVsLmMNCj4gKysrIGIveGVuL2FyY2gveDg2L2NwdS9pbnRlbC5jDQo+IEBAIC0xNCw2
ICsxNCwxMSBAQA0KPiAgIA0KPiAgICNpbmNsdWRlICJjcHUuaCINCj4gICANCj4gKy8qIEVB
WCB2YWx1ZSBmb3IgR0VUU0VDIGxlYWYgZnVuY3Rpb25zLiBJbnRlbCBTRE06IEdFVFNFQ1tD
QVBBQklMSVRJRVNdICovDQo+ICsjZGVmaW5lIEdFVFNFQ19DQVBBQklMSVRJRVMgICAgICAg
ICAgICAgMA0KPiArLyogSW50ZWwgU0RNOiBHRVRTRUMgQ2FwYWJpbGl0eSBSZXN1bHQgRW5j
b2RpbmcgKi8NCj4gKyNkZWZpbmUgR0VUU0VDX0NBUF9UWFRfQ0hJUFNFVCAgICAgICAgICAx
DQo+ICsNCj4gICAvKg0KPiAgICAqIE1TUl9NQ1VfT1BUX0NUUkwgaXMgYSBjb2xsZWN0aW9u
IG9mIHVucmVsYXRlZCBmdW5jdGlvbmFsaXR5LCB3aXRoIHNlcGFyYXRlDQo+ICAgICogZW5h
YmxlbWVudCByZXF1aXJlbWVudHMsIGJ1dCB3aGljaCB3YW50IHRvIGJlIGNvbnNpc3RlbnQg
YWNyb3NzIHRoZSBzeXN0ZW0uDQo+IEBAIC02MjAsNiArNjI1LDQ5IEBAIHN0YXRpYyB2b2lk
IGluaXRfaW50ZWxfcGVyZihzdHJ1Y3QgY3B1aW5mb194ODYgKmMpDQo+ICAgICAgIH0NCj4g
ICB9DQo+ICAgDQo+ICsvKg0KPiArICogUHJpbnQgb3V0IHRoZSBTTVggYW5kIFRYVCBjYXBh
YmlsdGllcywgc28gdGhhdCBkb20wIGNhbiBkZXRlcm1pbmUgaWYgdGhlDQo+ICsgKiBzeXN0
ZW0gaXMgRFJUTS1jYXBhYmxlLg0KPiArICovDQo+ICtzdGF0aWMgdm9pZCBpbnRlbF9sb2df
c214X3R4dCh2b2lkKQ0KPiArew0KPiArICAgIHVuc2lnbmVkIGxvbmcgY3I0X3ZhbCwgZ2V0
c2VjX2NhcHM7DQo+ICsNCj4gKyAgICAvKg0KPiArICAgICAqIFJ1biBvbmx5IG9uIEJTUCBh
bmQgbm90IGR1cmluZyByZXN1bWUgdG8gcmVwb3J0IHRoZSBjYXBhYmlsaXR5IG9ubHkgb25j
ZS4NCj4gKyAgICAgKi8NCj4gKyAgICBpZiAoIHN5c3RlbV9zdGF0ZSA9PSBTWVNfU1RBVEVf
cmVzdW1lIHx8IHNtcF9wcm9jZXNzb3JfaWQoKSApDQo+ICsgICAgICAgIHJldHVybjsNCj4g
Kw0KPiArICAgIHByaW50aygiQ1BVOiBTTVggY2FwYWJpbGl0eSAiKTsNCj4gKyAgICBpZiAo
ICF0ZXN0X2JpdChYODZfRkVBVFVSRV9TTVgsICZib290X2NwdV9kYXRhLng4Nl9jYXBhYmls
aXR5KSApDQo+ICsgICAgew0KPiArICAgICAgICBwcmludGsoIm5vdCBzdXBwb3J0ZWRcbiIp
Ow0KPiArICAgICAgICByZXR1cm47DQo+ICsgICAgfQ0KPiArICAgIHByaW50aygic3VwcG9y
dGVkXG4iKTsNCj4gKw0KPiArICAgIC8qIENhbid0IHJ1biBHRVRTRUMgd2l0aG91dCBWTVgg
YW5kIFNNWCAqLw0KPiArICAgIGlmICggIXRlc3RfYml0KFg4Nl9GRUFUVVJFX1ZNWCwgJmJv
b3RfY3B1X2RhdGEueDg2X2NhcGFiaWxpdHkpICkNCj4gKyAgICAgICAgcmV0dXJuOw0KPiAr
DQo+ICsgICAgY3I0X3ZhbCA9IHJlYWRfY3I0KCk7DQo+ICsgICAgaWYgKCAhKGNyNF92YWwg
JiBYODZfQ1I0X1NNWEUpICkNCj4gKyAgICAgICAgd3JpdGVfY3I0KGNyNF92YWwgfCBYODZf
Q1I0X1NNWEUpOw0KPiArDQo+ICsgICAgYXNtIHZvbGF0aWxlICgiZ2V0c2VjXG4iDQo+ICsg
ICAgICAgIDogIj1hIiAoZ2V0c2VjX2NhcHMpDQo+ICsgICAgICAgIDogImEiIChHRVRTRUNf
Q0FQQUJJTElUSUVTKSwgImIiICgwKSA6KTsNCj4gKw0KPiArICAgIGlmICggIShjcjRfdmFs
ICYgWDg2X0NSNF9TTVhFKSApDQo+ICsgICAgICAgIHdyaXRlX2NyNChjcjRfdmFsICYgflg4
Nl9DUjRfU01YRSk7DQo+ICsNCg0KVGhhdCBsb29rcyB3cm9uZywgdGhlIGxvZ2ljIGlzIHdy
aXR0ZW4gYXMgOiBpZiBTTVhFIGlzIGNsZWFyZWQsIHlvdSANCmNsZWFyIFNNWEUgYWdhaW4u
DQpSZWdhcmRsZXNzLCBpZiB3ZSdyZSBsb29raW5nIHRvIHVzZSBUWFQgbGF0ZXIgb24sIHdv
dWxkbid0IGl0IGJlIA0KcHJlZmVyYWJsZSB0byBrZWVwIFNNWEUgYml0IG9uID8gVGhhdCBt
ZWFucyB3ZSB3b3VsZCBub3Qgb25seSBkbyANCnJlcG9ydGluZyBidXQgImJhc2ljIiBpbml0
aWFsaXphdGlvbi4NCg0KPiArICAgIGlmICggZ2V0c2VjX2NhcHMgJiBHRVRTRUNfQ0FQX1RY
VF9DSElQU0VUICkNCj4gKyAgICAgICAgcHJpbnRrKCJDaGlwc2V0IHN1cHBvcnRzIFRYVFxu
Iik7DQo+ICsgICAgZWxzZQ0KPiArICAgICAgICBwcmludGsoIkNoaXBzZXQgZG9lcyBub3Qg
c3VwcG9ydCBUWFRcbiIpOw0KPiArfQ0KPiArDQo+ICAgc3RhdGljIHZvaWQgY2ZfY2hlY2sg
aW5pdF9pbnRlbChzdHJ1Y3QgY3B1aW5mb194ODYgKmMpDQo+ICAgew0KPiAgIAkvKiBEZXRl
Y3QgdGhlIGV4dGVuZGVkIHRvcG9sb2d5IGluZm9ybWF0aW9uIGlmIGF2YWlsYWJsZSAqLw0K
PiBAQCAtNjM0LDYgKzY4Miw4IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIGluaXRfaW50ZWwo
c3RydWN0IGNwdWluZm9feDg2ICpjKQ0KPiAgIAkJZGV0ZWN0X2h0KGMpOw0KPiAgIAl9DQo+
ICAgDQo+ICsJaW50ZWxfbG9nX3NteF90eHQoKTsNCj4gKw0KPiAgIAkvKiBXb3JrIGFyb3Vu
ZCBlcnJhdGEgKi8NCj4gICAJSW50ZWxfZXJyYXRhX3dvcmthcm91bmRzKGMpOw0KPiAgIA0K
DQpUZWRkeQ0K

--------------nYIZYN4huIqDTa0K4qtwXuQG--

--------------5Ww4dIUB371KC8I2tJ3z0MDE
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqG+k8FAwAAAAAACgkQZg+p0QLLz9A0
Jwv9EZF7DPtiJhv4rCFPnm1OI81u/Sb39PR+e0j0TkNiDDTOX94A+WFezBBH/KQD9T4BdWpEA5Xq
YHhkpojpl7jVQ25wa4MXgboKE/h+u5164WgqNTKwQHKmESQ6APlLrusQFPbqPNKeJe1ej5n1KMsl
+hCZ5Zd0sFcJ9bNRKhHoJFCONi5GurAcMtgF3YQIH+8JfxxX0Rqhi/8tcHYT8OAT0A0T0Pn1Bx3F
csa+Xu3g5vFt5YSLMrtowZz8rGWHhDSZQAU1a6+XrfQk1g6mPE0SoSBB0K3y8rUvLWKCZ4JHrJdv
XCHYAisufJVD2x8nuhE9S5ohluNWjqBPCv67coWUgSQJqud8ifj1D7umpBphx1f2g5NSpqr7OKAe
x2IqURKX5MTQ4mc1rgxAbcxMkvgsGs/ZYtbzOtoPjGOpbdcqrnvhADBmmnI73TmZoMn/pvCce7hD
DS7jiAGPuwKcg4pKAWuX9Qu+8Jb4s3fYfCbPP4BpBN5hPBJuJpgVboXMkaj7
=X/A8
-----END PGP SIGNATURE-----

--------------5Ww4dIUB371KC8I2tJ3z0MDE--


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 13:03:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 13:03:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396528.1634349 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2Qz-0000fN-Br; Thu, 20 Aug 2026 13:03:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396528.1634349; Thu, 20 Aug 2026 13:03:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2Qz-0000fF-8A; Thu, 20 Aug 2026 13:03:53 +0000
Received: by outflank-mailman (input) for mailman id 1396528;
 Thu, 20 Aug 2026 13:03:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wx2Qx-0000f4-74
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:03:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx2Qw-0092QQ-K0
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:03:50 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a86fb33-2eae-0a2a0a5409dd-0a2a4503a1e6-14
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:03:50 +0200
Received: from [98.137.65.146] (helo=sonic309-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a86fb34-fae8-0a2a45030019-62894192a76a-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:03:50 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Aug 2026 13:03:48 +0000
Received: by hermes--production-ne1-6dbcb84f44-wqnk6 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 57e5b9f33273342361b36bf3a60d741b; 
 Thu, 20 Aug 2026 13:03:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787231028; bh=dPE99sHCvypQ23EzktncrpJmi6hmAomsenCsxwBOrio=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=bWVMhEOLOQCP3J+DVEwMfTBDQ7KST/O/8ganoNSXspmHsnA6ZHkZseOlR+KQyXBmZ6TMNWRjwI8o+mqA8iaamNg+46/B70U51EQ7U+TDgxRaHY4XDmWaqwZyTMkIPrQVBb7IJ8G641xtfVGd9omOaDAIeWASsCeNvkdZii2+gauFsxDRG99HWwtby8lWIW5a1LE3I0zDtHcE6HVtmKLdS2WkQw6FW+xFwR8dQ5WRkFwnG4mWVt93l4VY+VaNwVpIMoOrNAg6nvFSCdZ5NrqMy9doum2g3lOlngvDeBMkKTOAnjeMWXHxZ4sGprPv5qlhYx6nIcX4PRUs3xsSjVHuFg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787231028; bh=O8SruZh0pIXQ3xaDfux1pefGZ4Ws/Uijrrp8i9Xsots=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=QY8jhTRF72QPwgjA3QylVMl0QrwCgo/QIsveP+YbVlCNmweGkEojgZHGVsKHwAKCBGUEK3QgRU+zc2qQXlSZtye2c7p3ZfwcaK79zzmzfVRgx37wVFZ/iuWskuE9qQDYOCTp9+l1+3PIs1BIok5AVv6zuwFCBW1P/PREwr3YNKLeVGSZlN0En7qO7Lq8tq8PHF0V9G6w5ZrDrpfCBwEVSjygVIohNB80U0UJnGLf2Lz/a+k/cGZ95QZ6lvB3JdwNLGaSRTA3q2kU/T7pKi4qAI5VRJCuCllKg+vF9o47dpWI1vQdvLYH0Tn3RMXn4xSjSBluLK8iXTfgAguI7zUoFA==
X-YMail-OSG: PbvUjnsVM1mlRT1deoOi1yhsgg9vkToRu0KFJhPE3cSr6BMFqrSSWcnboFmd3w9
 2INKpa1.CfEZT50feO4YJeXsw0xYkIXU9nT3VrxOZlN3ptoJSUhzKmeZylnIdxtxlRugodjl_DeR
 3WUVGRCo58wOwb768KnTWLrhgiyv6cdfrRtWUFbPofgq56ljDddxCefQGip46Pd6RIqcXtRwcoVv
 ZYtpT93XIgSOkQYqFZVCtC_JNMxpojkoV_4kNR3YtsSzQrgdCNE.VFkCeEmW6VM4PB4nWbtf5fF6
 ncv7eQL3NbbhAm5wIcgc4TRKZVBztqE_k3UrC6XxpGw8l84JdP88YJ0_mFxaE8niSihh8oaPYhcq
 UlGRAdlyiR1NLWdiEr4roKl0uuBQy9wqMUXyl_94I8tkMmGQOh7Fp9KsUF_mX0yXoarZ.jyb9Gci
 kHCviHEDo6ke_9ne2YtEo9qW0rJJ5LKh3DOes.Ej.PRcc4RR.rsxBKGsJ3Aqtipdgoot0kvZpKdU
 3XX1WEIczJi.n12lhlxbj916ceAk.kXpxRh2xSQN9d5OkvTTjGS9c8dSIu9AmyDnE5gDsC7e6FG_
 XH_T7I5ihVuBNKCL1gfxSkOJUxrRfpMRK5bUx99XCTWF45xb0Lv4eilVUA1qabwtyHwwZKcebN8s
 7rnLMidPKCKsu94tjXhnSu3jFCZMvfAVY9oIzh1frzY_Y3tal72M3KCdt7A5P30YeOPjHQ8CqYh8
 HS7YaTYEnCRSbsyAPqJ7wvNYAJZknlxKMMDWAQsVBRGiXyYXtFzzQcsW7Ob7mgde5Ck3EPd1Nakg
 e9g4MNPyrn.lz3Ddk8fXv.lJ73XKmxt5k7githmDd9Xb0PyBOF1xJ5nf56SlgoY0jiszrISvv2jV
 0GxQaQaCt9EnNRcauxJ21rdTLzCFPLWm5FxYSfO4su4f4KHGWUo5ceBe66loB.mIzdNbr6cMx4RE
 RmoDhxlww_SML.KfBD6FKWWq2tWbQF_igok_j7mcOI8GSYoKP7kyx5SaaNAs2Z0KTcmEN7vys1mw
 PlV4wDliM8pUwVYpjHL4QLBLBr_SjFxnCWa9Q37ZCwtPuVLaekYsCQv6wgx7dRWONQrAZAUrlOB4
 AV0FW_zBwp0FbHUp0_m7sbGxPTid1V6hcy4Mlq4kLGcOfIu_NzWJpiMWMME1v.s5mTR_eyg8LPqD
 kbGxPAREjV9KZ8qaem9G7lJ.0evDgztlw1xjkYRp5gClFwq_u3SLBFOGk8Ff5wOdIFm.KgaIR6fY
 WupWAkVvDJpw53XJrfdQZRo4r2Dpyr23wQyIxhIXkn3OVX0rVVhkd9D1sF55CffBryCyBVh2YsTR
 8pJPPmZnko27bikv1sYZeKAw6VH48MwIh85ZPNKhjiv4JDhV6eVmjTJkVkNOklfl041YFi2nUG2.
 tS0i8KXYl9bfunNU8SFhHszDPDmtTVMIJRCmqB3Vge_1vlz1tZpa4455zT8PBxc5Hs9eVQAkGLv7
 P5Cqu8XT_GGS0.jR6RjHqgBFvlpRnLw7N__cAxoL1xQNLRl961o.dL_31mSY.4wuFm4di6PUEu4o
 9JFe9NGQY5FMzPPHbwiq3WMwzYdOonCBVnIHbVWOONgJXEx9F2BuvMDt8MgatP6Wng7RzBRGULjx
 R_iHZhLY3s4f.GWvtK0QyoBNbSJp7SGjpGILE3SJWAzhVcVf7tpEOG3RysCTv5MRS1PFZ5Guh15f
 qZcYORo4rtAIre24HJgbEokNeifEHn0uBqPyjvyPn43QtGUkzVBtbO52PuAjLllI2YLHLgrPz5f0
 QTxplbLrwYDd2CTPOR1jxzsGfBrNcjvjq8l0t19kRDq87nt25TUum5s2zPMPtIvq4knpGEcEuFwr
 6pWJ7KX6sU6PvkNKzn62EO8Cx_0PON5wOLnefZyLqvu5RcDDPqF0NL_cTu7GwUw830kBbxyEfem.
 4tjuyfJ5yAhlZZY3nhswc8L2lwRBv9HazwJB8FEFVTrCq6Zvm6A_GWHat9m75xoKGNtbpg_B3PK2
 F0565IeME5yKv7S5I3Buk4BGbO4EYb997x1RmNaE4wQUpE2dXeu.mmUgKoQI6UsGtQiMlK7xHVRz
 Yi2QtOjb8.enjZc3Laa1ElsQzKRDhbi5y6tj3.57e5FxnyNsrCFJhTCQkRaNqv5pCHFzRQTz67Td
 PJNeKBgdYFGSeH3mVZwOQK9.mGtD9Cw83mIUfW0mYUmu50pJlkMsjAxmBs5cfJwE0VX6DrpxLXzT
 SZ1G0fO.8Y33nYygeKO1gp3cnGhgoyLKqAFmcxT9nRcGSbkc-
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 80061041-86f3-416a-9689-bd491a756f1b
Message-ID: <0762fb50-01b5-4ae2-8587-7574020082b4@aol.com>
Date: Thu, 20 Aug 2026 09:03:46 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
 <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
 <f0ffe015-1bc5-4091-8dbe-2b4eee9cec2d@aol.com>
 <b05a3553-398d-4ed0-bbf1-6e93cf385fe2@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <b05a3553-398d-4ed0-bbf1-6e93cf385fe2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 6303
X-purgate-ID: tlsNG-33051d/1787231030-768FA4E9-A21D3A9B/0/0
X-purgate-type: clean
X-purgate-size: 6406

On 8/20/2026 3:58 AM, Jan Beulich wrote:
> On 19.08.2026 21:09, Chuck Zmudzinski wrote:
>> On 8/19/2026 1:49 PM, Chuck Zmudzinski wrote:
>>> On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>>> about avoiding the layering violation than anything else.
>>>>>>
>>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>>
>>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>>> in hvmloader?
>>>>>
>>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>>> restricted DM as well.
>>>>>
>>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>>> treatment. Earlier on we also talked about the region not necessarily being
>>>>> page-aligned. That poses, even with r/o exposure, the question of other
>>>>> data on the same (leading / trailing) pages. This may imply that the
>>>>> copying needs to be done strictly in Dom0, for both DM and guest to only
>>>>> ever act on copies (which may then as well be r/w).
>>>>
>>>> Yes, I am thinking the DM should make a copy host OpRegion and never expose
>>>> the host OpRegion to the guest but only a copy of it.
>>>>
>>>> The reason we need a patch like this is that with the introduction of the
>>>> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
>>>> so its contents might be unsuitable in the guest address space, so in those cases
>>>> we need to patch the copy of the OpRegion that will be exposed to the guest.
>>>> If there is an extended VBT the DM will also get a copy of it, make a copy of
>>>> it, and expose it to the guest by appending it contiguous with the OpRegion.
>>>> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
>>>> then it can find the host VBT and make a copy of it without needing hvmloader
>>>> to send the rvda and rvds values to it.
>>>>
>>>> Then, the remaining question is which component (DM or hvmloader) will patch it
>>>> if it needs to be patched to make the guest's copy of it compatible with the guest
>>>> address space.
>>>
>>> As I noted earlier, it think it would be advantageous for the Xen platform as whole
>>> for the patching to be done in hvmloader. That way, support for extended VBT is
>>> automatically added for all implementations of the DM, not just for Qemu. But the
>>> downside is that for hvmloader to do the patching, it needs to know the host OpRegion
>>> address, which one could argue it should not need to know. This is the only reason I
>>> can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
>>> avoid disclosing the host OpRegion address to the guest.
>> 
>> Correction: Actually, with this new scenario, we need not disclose any confidential
>> host addresses to hvmloader if the DM removes such information from the copy of
>> the OpRegion that it exposes to hvmloader. Then, all hvmloader needs to know to
>> ensure the OpRegion is compatible with the guest's address space is the guest
>> address of the OpRegion. It need not know either the host OpRegion address or the
>> host VBT address.
>> 
>> So the guidance I need from you to do v3 of the patch is simply to answer these
>> two questions.
>> 
>> 1. Should I write v3 of the patch not only assuming the DM will never expose the
>> host OpRegion to hvmloader, but also assuming that the DM is responsible for
>> patching the OpRegion to ensure it is compatible with guest address space?
>> 
>> Or
>> 
>> 2. Should I write v3 of the patch assuming that hvmloader is responsible for
>> patching the OpRegion so it is compatible with the guest address space?
> 
> My tentative response is to use option 1, not the least because a mid to long term
> plan is to see about removing hvmloader altogether. However, a more firm response
> here depends on an answer to the question raised in
> <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com> (sorry, the list archive hasn't
> caught up yet).

I apologize for the tone of my last message which I wrote before I saw this message.
(Unfortunately some of your messages are going to the spam folder, I will try to fix
that, but it seems aol.com's spam filters are not all that smart)

I was really hoping you would answer this question and I appreciate that you are
able to give me a tentative answer favoring option 1. 

To follow up on what I did say in the last message, I think we have exhausted what
you and I can agree on and now would be a good time to pause this discussion and
I will write a new version of the Qemu patches and v3 of this patch assuming what
I said in option 1, and hopefully the Qemu maintainers will help us out by replying
to a version of the Qemu patches that does the patching of the OpRegion in Qemu instead
of in hvmloader. So far none of the Qemu maintainers have replied to my Qemu patches,
unfortunately, but ultimately, we at some point will need their input to decide how
best to do this, so until they respond to the Qemu patchsets I posted, I think we
just have to wait now until they weigh in with their thoughts and opinions.

Chuck


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 13:04:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 13:04:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396532.1634358 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2R9-0000v7-Hd; Thu, 20 Aug 2026 13:04:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396532.1634358; Thu, 20 Aug 2026 13:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2R9-0000ux-E9; Thu, 20 Aug 2026 13:04:03 +0000
Received: by outflank-mailman (input) for mailman id 1396532;
 Thu, 20 Aug 2026 13:04:02 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wx2R8-0000uH-15
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:04:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx2R7-0092Th-DB
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:04:01 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a86fb36-2eae-0a2a0a5409dd-0a2a4505902c-46
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:04:00 +0200
Received: from [98.137.65.204] (helo=sonic311-23.consmr.mail.gq1.yahoo.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a86fb3e-4cb1-0a2a45050019-628941ccaa79-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:04:00 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Aug 2026 13:03:58 +0000
Received: by hermes--production-ne1-6dbcb84f44-46rwf (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID a8e2a332f422a3d65c31f2075610e6e2; 
 Thu, 20 Aug 2026 13:03:54 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787231038; bh=i5Eu7usWgUNGH7tQ609dvRBkhY6X77619nihwt8Hxck=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=L9a2au6QajmBAYpRVifTYsRA9xIrE/C6fhoUacu7q71HnOUzCK9v68r3sGqaf+JKr6f2sMsguAyGVxIr0J+trl5q7zQYSqLAPN/5CRnK9bhiFP0q0mV2jr0sPxpKQMc8WHkiPaFj9tcdB2Wo3HkeSrY2NEs8EdmvHyaO7muMlVlJySiNLXPnUZitg3ADJatsWEG9GN3fClN3DUji4IUBtveaUZnuswYnGWjX8BMb46SoqtzEGACZoL78+L/BwtRO4u8jAtyW3ODBefYD1YhBovYjCBsOHdcWeTMkNbkkRfpEE0LzMQAmwZ8p8u84sV1h4CKJ1pHg31TzavobbMeUeA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787231038; bh=9Wap8fShXxd0pgpjiAndfj3Ogrx9UFL9/1kJ2NV0ulk=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=ulVqXCPlZEb7NJOGoGCfOqFyccJkjDZVnXH7HAdoq+zELagISbn23qxEoIsvX4QS/TyyXR7JYf9eLpz+LvYi1cwtFjg0sIKv2MSt8Xg9NU4/uBz8chA+h0q5dYCtt0FZjARJvMyd4jcWCXLPFo3anuLIZ1O2hG9TJS7OA537TOzuhyRjyns4bTaC4heP7sn8AkSz8gzHortWotnwVsjta2okiGs9/8KL8z/t5KAZaiZ562LgBGWa4jfgx/ywd93TyDlrGrQqbH9nOGIYtI5tPvWpzoRcYrXbrYLpIyM2PLDbbRHo80spiNobxUUq9nz7sDPefPFB6Pkw7iAKrm9IDA==
X-YMail-OSG: _8Jqip0VM1mym9x9D7e3N8UllgSpYO8byynk1hmAkca4Z4RcxhZJIES6LJDP23M
 L5TjHHo0yHBzpbQLYXofs7HpFmbN6LER3dIbAJTXTR9zLYARBc6yUAvWPYwX_E0tkEAAsqrMRHoW
 EsqOjXYAd3E0p6f8CyFQIryfrWm4lCnr2Thg2n40AVkpMTma9r.PjhBT4PtByhRKgLLHs39sFI77
 CzH8Xb6CQKm4Lj8PCoV_8ZLFZefGp0ZXKzBRgPQPZbHAwZyXwerXJ5HSgY2Vgu_Jx8qj82CJR4zj
 xgjNaN4AAx4gWKdePAh5mln8AbYcEENJ3tKXrehSnS6_LdKe4GRAirYuVqpo400NeCp7YiCPvwG0
 ffKM1AQKneX1ydLeG.bnbHtTKplWbLhDOZZRNeNDTUgAAOXnHok9Ve7ab0qMZQsAeMB0nWi_7xgk
 9PeOmdzdncTDoP3XPc8k_Dd6tMNbhmEhFgC6LzWS1J4cSf_AsGx_PdfDlXXjNbygeN0skFfeTCGj
 dEqlcNonbRB.kTAQp10fTFuIIV39P3BihwARbvae9.v3FU_hb.UYSainf9d1j3kY6r3nHc7Zwz0b
 m3Df4ilLie1th1z5bamtIKCVXEvK64a3TC8xpnD5wD_reqUJ77lJ0ECB7XoXMQA27MnJKUPMEtet
 DfmzR_9ltjPHMw60oDDxeFLN_poDC1QOiKQjtDuqdZOvLlPXKu7bD6qLSAaHGbD96ckVt0fohErM
 6EF15lXCVUhn3oFWUFk5K9L3nRImzIm4tuLKRoZ9BARbjWOFTyWyDJEFwr4cCJyrxL4WOQf6fUNL
 uhmODDzRHoWu6fFMTJe1NPjxW2XyDbXC5FjoAQfYgctWvkbxmMC0C89wmrD3XmZYwKvebcLf9KoU
 MsgN8GFWlZY_CZhv0XSSyrY00YU57W1sI2nCBQ.lUjrbWRZd6jO_Xa.PozlZUDGMzpF8mrsbKs2L
 v1xKPBNhQoQIFm5IKGlL7z5ZAKliNlD8hy8fz6lx15Ahgt0inxZylIzMqVvfY3P1cxQa95h3CybX
 2A1aEIM6MJdQcNl4FJvPixwqMdb06a1E3PewQp78SCcRPpu0vKtrY._SvUKt8ZJsEdXkytKzP_.W
 QFcMPPX2.klOk0pO1dofHrSizgxEhmREoq4Z.N9HSEYRoS.MAqN6EgNC.dBPG.JenGf6VsXTblgb
 YAETT6Ci6Pb2Igw9qJixpRib9cznCH3efj6Zn0B7qEcNiXleDpYtpD2X_htJYGzXGk2B21PL9W7g
 6CWTMbl4vrt52lVQkog.nVP3QQa8.huZgSFwJtqJgQS6g7joAP6qxk6a_zSWQVFozGNIILo60FUi
 FK_j27hwn_plhHQrb60I9vxFqYg0q2goARcwefcNKE6.1YRjDPTtohPol9boyH18BSiMYch0oWeI
 oj3NMhRt7yjf9jwiDMGLdH7QiCVRk5Xb0o6LkAEyA96FF72rF1fcQLVhuZy7Kotk2FMlFW.w26Sr
 Y5UuSfvaETsCQh2U7W8YPgB1OKsIO8uD34.OMUWYArDAuOMDMRm9bCU2f.kQo.g1g26vDdg1mdx3
 slfhHcjs4q4CJ.0XpfoirA9SPnFBztdm3t6O6A9m1tQElCyTQhlx9ifRY9bW7eOSUK7sdDYAmPkc
 9uRYmJKM2Xe1pPwGgSEZrzV6r8e3zCSxO.l6snXWR1YV1Dw9A17RstfdHnog6NttMTMiE0GtmG_P
 NcwtEHCjUKVcT_XSlLlhmz22RrN_QmQ6G4t2Iz3_LsrutRGOJBUzvDjKu4tf7NEBqJfH8REi_wit
 XJGpeEE1ztepOiHEHPC37_p9ape_IReiWaIjzHZAhRB8rpFkRQXYfwkeCx2hvhB_0q3SqkU60SoE
 LMdRlevYJY_zPTU2AbYrBqU0oEu.kPPq0OziAjfIAL_6dpSi.UvUKpwUa7Xp.3ES6TSUtWHOIWxQ
 cr87xjJBsFhQJ.aUixBRoT0x4Pn_2BtrlEgxdLnSyOJx7YpSWrqFcrPv0g0qpv2jA3x15nlhsZHL
 p8Lgk4VKj2RkvxnmS.yhlZtY1qW9fwa0egN53SQKwDQ1.xfdxgKFhxpg1fCS3WsxvKCisHnnOyod
 mxRF7aySDYo7UjuyI2XPE8UfZXp8bgmf1iD6zDtk413HV2CT6VtbTG5hNg1KUzgat8eyMojBZ6RW
 WyMPVLew6geHpbowXcAed18VEU_tI.M9K42ATR8j8WpOFg3YJ6XbDpYL9UKOmVZTkySAaOZ8cQuG
 wuSFiNBVLupWIpY0YGMycRkoVeyrUD4yXkYIxuWFaL_5J
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 373cb663-2d27-4eb2-81bf-d41bc8c998ce
Message-ID: <17066d50-9809-47c4-87b2-7f33bfb528ad@aol.com>
Date: Thu, 20 Aug 2026 09:03:55 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
 <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
 <efd82852-484d-4b59-8d04-887533c13dea@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <efd82852-484d-4b59-8d04-887533c13dea@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 3958
X-purgate-ID: tlsNG-c201ff/1787231040-F50A22A1-469DA675/0/0
X-purgate-type: clean
X-purgate-size: 4025

On 8/20/2026 3:53 AM, Jan Beulich wrote:
> On 19.08.2026 19:49, Chuck Zmudzinski wrote:
>> On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>> about avoiding the layering violation than anything else.
>>>>>
>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>
>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>> in hvmloader?
>>>>
>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>> restricted DM as well.
>>>>
>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>> treatment. Earlier on we also talked about the region not necessarily being
>>>> page-aligned. That poses, even with r/o exposure, the question of other
>>>> data on the same (leading / trailing) pages. This may imply that the
>>>> copying needs to be done strictly in Dom0, for both DM and guest to only
>>>> ever act on copies (which may then as well be r/w).
>>>
>>> Yes, I am thinking the DM should make a copy host OpRegion and never expose
>>> the host OpRegion to the guest but only a copy of it.
>>>
>>> The reason we need a patch like this is that with the introduction of the
>>> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
>>> so its contents might be unsuitable in the guest address space, so in those cases
>>> we need to patch the copy of the OpRegion that will be exposed to the guest.
>>> If there is an extended VBT the DM will also get a copy of it, make a copy of
>>> it, and expose it to the guest by appending it contiguous with the OpRegion.
>>> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
>>> then it can find the host VBT and make a copy of it without needing hvmloader
>>> to send the rvda and rvds values to it.
>>>
>>> Then, the remaining question is which component (DM or hvmloader) will patch it
>>> if it needs to be patched to make the guest's copy of it compatible with the guest
>>> address space.
>> 
>> As I noted earlier, it think it would be advantageous for the Xen platform as whole
>> for the patching to be done in hvmloader. That way, support for extended VBT is
>> automatically added for all implementations of the DM, not just for Qemu. But the
>> downside is that for hvmloader to do the patching, it needs to know the host OpRegion
>> address, which one could argue it should not need to know. This is the only reason I
>> can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
>> avoid disclosing the host OpRegion address to the guest.
>> 
>> But we trust hvmloader, don't we, to not abuse this knowledge of the host's OpRegion
>> address?
> 
> No, we cannot (fully) trust hvmloader.

That is good to know.

Chuck


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 13:15:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 13:15:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396553.1634366 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2bk-00030m-FE; Thu, 20 Aug 2026 13:15:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396553.1634366; Thu, 20 Aug 2026 13:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2bk-00030f-CO; Thu, 20 Aug 2026 13:15:00 +0000
Received: by outflank-mailman (input) for mailman id 1396553;
 Thu, 20 Aug 2026 13:14:59 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sergii.dmytruk@3mdeb.com>) id 1wx2bi-00030Z-Ol
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:14:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx2bh-0029Sz-9M
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:14:57 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a86fdd0-8faa-0a2a0a5109dd-0a2a45059ff4-2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:14:56 +0200
Received: from [46.105.44.175] (helo=3.mo561.mail-out.ovh.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sergii.dmytruk@3mdeb.com>)
 id 6a86fdd0-4cb1-0a2a45050019-2e692cafae9f-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:14:56 +0200
Received: from director5.ghost.mail-out.ovh.net (unknown [10.110.0.68])
 by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4hQkSH5rPKz69wD
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 13:14:55 +0000 (UTC)
Received: from ghost-submission-c7b579475-vmddb (unknown [10.110.188.21])
 by director5.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 17BBE1000F3;
 Thu, 20 Aug 2026 13:14:55 +0000 (UTC)
Received: from 3mdeb.com ([37.59.142.98])
 by ghost-submission-c7b579475-vmddb with ESMTPSA
 id nh3nN879hmqx5QkABF4ZfQ
 (envelope-from <sergii.dmytruk@3mdeb.com>); Thu, 20 Aug 2026 13:14:55 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo3617313-selector1 header.d=3mdeb.com header.i="@3mdeb.com" header.h=From
Authentication-Results:garm.ovh; auth=pass (GARM-98R0021f96c00e-7dc3-48e6-9e0d-1216f252883e,
                    D706B0B4A4E5C2B84ADA60A922A966C43F440F90) smtp.auth=sergii.dmytruk@3mdeb.com
X-OVh-ClientIp:176.111.181.215
Date: Thu, 20 Aug 2026 16:14:45 +0300
From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	trenchboot-devel@googlegroups.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
Message-ID: <aob9xUZF12IJhLRz@MjU3Nj>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
 <7489d730-6e91-4d6f-a355-4eaa62698c4c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7489d730-6e91-4d6f-a355-4eaa62698c4c@suse.com>
x-ovh-tracer-id: 18288836615552378332
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: dmFkZTEHja+aRFeNV2ixbeGtjyIMzgB3lg12I9m1uVhB0heuMO+Fzr7REfISj4T8fiDELlRrHvjokHQ0bfgn1CgpXbH73b1YFELft3wll7N3F3tumF3FWLMSVWez8FsU+T8NmQv8K/HIN/EEdznaWa3YmKiwCb6wH4pJaMTbozwSb8KojblEQnoIpOI5bY2Cjq9dJm/r+HZn1WnAzGEm36Ctq1gFV/1NETPPz1n8WCsfGYn1D8OerJOYYwMiAQy3YiM+Sk/cSfF03OC+FDq3mBP8r4pVveTU4Wq7oN+9Gohy0BIk/SoKsSNvy0r+zN8XWmPqh/IB1soU5m2ntLlULfq0jgF2QhM4CdN8F4FC3vq8ZDHsM43HTO1l9Zo7L0bOFvHE3181qrRgk2Ili7uG4zcbjP8qbR8gYt5cbX0lxD5wMOyAV9wQMFIiL1Tz8yoZr/Glf2BWg/7Rvb/4rt1geaatcKGBP2Q+eJ10XjhkITryodNP4/QVNG92zY+3JJAgYexDrdJ0+/S0VoUijJDr/8AQvSiZPnphQAF4fWCamoN2s9cIIGo4VVq1sNgiOPh6wFXyQmqZYpOwNRahnebmVjZW7Rzcmk39vxo4r8nqqFIGGlVmTqwEZSZL2IifATIoAo0h10VqnqoReElZktZkjPCzP1dKTTPFXy1khb0sz49gV4IwmA
DKIM-Signature: a=rsa-sha256; bh=i199ftMT32oqzrbAktF9xI3Y2+Viq/+CBtxR6F9DISQ=;
 c=relaxed/relaxed; d=3mdeb.com; h=From; s=ovhmo3617313-selector1;
 t=1787231695; v=1;
 b=MjQ3d7bdR/RUNl72DSI2OaoetRaIvb7N7VK1KoMPcH16//lxRwC38hfKwL58X8XpaNphe/Cb
 43OFemYTMp97sXb50hWF9MJd3wJ6Zy4gRGvkOZB/GOraea6hh0JLa3FteKrAAPI8loQ23N3HpTh
 ZHwGn9XHttL3WSslmT3vP4ebUG5lZiAvr1WRXWbXQ2zFtPpVXIEr3BZqasKsbiSRSjTLpz8bXTk
 4NIwwEPcn/4uj0utgswUk5JEM97xFUqiO1S67B15iKWsHf/0olnJbgI+rY4bydpkzcAn53Mialu
 VW5DSxMhG3kIjlX0s1aGzO45F9NQrjVgKM+romhkZpQWw==
X-purgate-ID: tlsNG-c201ff/1787231696-734BC2A1-32F65332/0/0
X-purgate-type: clean
X-purgate-size: 5164

On Tue, Aug 18, 2026 at 02:08:48PM +0200, Jan Beulich wrote:
> On 02.08.2026 15:09, Sergii Dmytruk wrote:
> > From: Michał Żygowski <michal.zygowski@3mdeb.com>
> >
> > Report TXT capabilities so that dom0 can query the Intel TXT or AMD
> > SKINIT support information using xl dmesg.
>
> Hmm. I first meant to ask: In how far is this extra logging useful,
> especially as long as we don't use the features just yet? And only then
> I noticed that I must have paid too little attention here already in v3.
> Querying through "xl dmesg" is entirely unreliable. Sooner or later the
> boot messages will scroll off of the ring buffer. Making this a
> query-able interface also would mean we can't alter any of the messages,
> should the want/need arise.
>
> For AMD the situation is easy: It's part of the featureset / CPU policy
> exposed via sysctl. The same is true for SMX on Intel, but the further
> GETSEC output requires some other means to communicate. I wonder whether
> making this part of the CPU policy would make sense, or whether to
> introduce a Dom0-only hypervisor-CPUID bit for it, or whether yet
> something else would be best here. Likely Andrew will have had thoughts
> on this long before ...

I'm not aware of anything relying on this output.  It's just for making
this information more accessible to users that may be wondering if DRTM
has a chance of working (e.g., if hardware supports it and firmware is
properly configured).  The wording may be unfortunate (and needs a fix
anyway), I can change it to

    Report DRTM-related capabilities to enable checking for them in dom0
    using `xl dmesg`.  This targets debug and diagnostic use cases.

if that helps.

> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x86/cpu/amd.c
> > @@ -617,6 +617,21 @@ void amd_process_freq(const struct cpuinfo_x86 *c,
> >  		*low_mhz = amd_parse_freq(c->family, lo);
> >  }
> >
> > +void amd_log_skinit(const struct cpuinfo_x86 *c)
> > +{
> > +    /*
> > +     * Run only on BSP and not during resume to report the capability only once.
> > +     */
> > +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
> > +        return;
>
> If this is BSP-on-boot only, the function really wants to be __init. For that,
> ...
>
> > +    printk("CPU: SKINIT capability ");
> > +    if ( !test_bit(X86_FEATURE_SKINIT, &boot_cpu_data.x86_capability) )
> > +        printk("not supported\n");
> > +    else
> > +        printk("supported\n");
> > +}
> > +
> >  void cf_check early_init_amd(struct cpuinfo_x86 *c)
> >  {
> >  	if (c == &boot_cpu_data)
>
> ... use this condition ...
>
> > @@ -1325,6 +1340,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
> >  		setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
> >
> >  	amd_log_freq(c);
> > +	amd_log_skinit(c);
>
> ... at the call site (and of course also the other one). Same for the Intel
> code, obviously.

OK, thanks.

> > @@ -620,6 +625,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
> >      }
> >  }
> >
> > +/*
> > + * Print out the SMX and TXT capabilties, so that dom0 can determine if the
> > + * system is DRTM-capable.
> > + */
> > +static void intel_log_smx_txt(void)
> > +{
> > +    unsigned long cr4_val, getsec_caps;
> > +
> > +    /*
> > +     * Run only on BSP and not during resume to report the capability only once.
> > +     */
> > +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
> > +        return;
> > +
> > +    printk("CPU: SMX capability ");
> > +    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
> > +    {
> > +        printk("not supported\n");
> > +        return;
> > +    }
> > +    printk("supported\n");
> > +
> > +    /* Can't run GETSEC without VMX and SMX */
> > +    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
> > +        return;
> > +
> > +    cr4_val = read_cr4();
> > +    if ( !(cr4_val & X86_CR4_SMXE) )
> > +        write_cr4(cr4_val | X86_CR4_SMXE);
> > +
> > +    asm volatile ("getsec\n"
> > +        : "=a" (getsec_caps)
> > +        : "a" (GETSEC_CAPABILITIES), "b" (0) :);
>
> Nit (style): Bad indentation, missing blanks, unnecessary \n, and stray colon.
> Overall:
>
>     asm volatile ( "getsec"
>                    : "=a" (getsec_caps)
>                    : "a" (GETSEC_CAPABILITIES), "b" (0) );
>
> I further question the need for volatile here. (Like for we have for CPUID, we
> anyway may want to gain a getsec() wrapper for GETSEC.)

I think `volatile` was added just because it doesn't hurt, rather than
because it's necessary, so it can be dropped.  Can add a wrapper, but
there is only one use so far and a generic wrapper will have to use
64-bit parameters (`GETSEC[EXITAC]` sets RBX).

> > +    if ( !(cr4_val & X86_CR4_SMXE) )
> > +        write_cr4(cr4_val & ~X86_CR4_SMXE);
>
> The clearing of SMXE here is pointless, as the if() already guarantees the bit
> to be clear.

This statement restores the value stored in `cr4_val` (see above).
Maybe should name the variable `old_cr4_val` or `orig_cr4_val`.

Regards


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 13:38:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 13:38:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396578.1634376 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2yp-0006CB-Bc; Thu, 20 Aug 2026 13:38:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396578.1634376; Thu, 20 Aug 2026 13:38:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx2yp-0006C4-8g; Thu, 20 Aug 2026 13:38:51 +0000
Received: by outflank-mailman (input) for mailman id 1396578;
 Thu, 20 Aug 2026 13:38:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wx2yn-0006By-6E
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:38:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx2ym-00FSmu-J3
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:38:48 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a87035c-2eae-0a2a0a5409dd-0a2a450cce8a-28
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:38:48 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a870368-f479-0a2a450c0019-d155802aa497-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:38:48 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-499b57cf2f3so2455765e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 06:38:48 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499a9e784b3sm125852055e9.3.2026.08.20.06.38.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 06:38:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787233128; x=1787837928; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=FwIveaMVZqQ3xr7y6C3rbxssTn7KuMmVWVEyV+AvEn4=;
        b=agS9Qx+1mpBUD6N43AbT7RJKiqMGzrEzAr/gDQEUhi1fqYQ5Ls/kbNKccTjLh4zBaL
         Kvmmix8WVP8yF+YxlanQSSZOOFt7RozeWm9e1k5TZ8CBXUm5B2RCOItt3WUH/MAdnaqy
         T32dpXyPiQkTyJ1OvUP/qOWoyMA/s1pkUE95BmJW4I0HfM2AZ6NZcNJ9DDv5im2SByMI
         E7xF4NFf5Sdm3Oix7oX07XuJdJ1P+BYTpNalxvU3wO8PmSNV8V0Nj51uUjxSL8H5Xxzi
         3ZXoHl3lLf2h4h3TDPj+KjQmPYS6u6iGx7FGgvGlZvi25vU0wUIDox+hqmebG+odW3m7
         nQ2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787233128; x=1787837928;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=FwIveaMVZqQ3xr7y6C3rbxssTn7KuMmVWVEyV+AvEn4=;
        b=iJ8aHGH4o7DK89tgCAfux3Bb12SgIbWWgIL3E+P+RpDfUCZsEA1wEsqGIm19Vp1Nww
         m03yUIIb1Gr3vCBQCMtOmMDAmjBCS2xZJKY6EIrYXYfdgkPHhe0LafaovLW1BvKtWbI3
         9yXT1g394+5GOTTA6Gxa4SNYhcOikV6lm+JeDTRKxa7P637MqjsbfbTC4cQwUkUM+EGL
         xNIoOZXP18B2q1LA7vZs0vvpgSMh97OeIB8HIW2ySnNcoeE7EAOQqZnbq25qsY6D7Otq
         TcPA7/kqwH6a5MOm7PAKv1YuFHZxj2qrVCn+NF/gzPK+xx7mqVTjztYUUevBfpnQx7yV
         x8rg==
X-Forwarded-Encrypted: i=1; AHgh+Ro93L0RTFnaTvXWcOt4EZPyDN1gduO7qmvTRGXtrsVIO6r4/Q08/7DAmIkC/cfdCwWjQZ7/1iqTIhk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2edj/ueFco0QY0IZY6pZKhdkCfUtO5+3AFr4VvH1kGC/AQ/N/
	w2AEwRqJzzykrA5NWbh1+BZIoDXuXYuogXJy3N8bit9bw41pEhHRe5Ks
X-Gm-Gg: AR+sD12JO3K+d2GaWRxSJO5QuJhLYN5iDK7R54JNCDdK7oy2G9YWou6fyBRtRxIRkAC
	F8Mozf60TGQwMUExdtu12qrXq/8mIl2JV4Ung9TyXleP1k8CZokCvVT1WRzByvh5yTYwvqmSs+w
	gSylIOS/I7JRL3Zp4pe9iN58NjoKNZ0y5HAmLrWLjAHmT2HMcRzPFL8bEKA3i+YCa3K+t5hiuHT
	CPBioVKVNdH2g8YuycAP9evihkipggwp/csFVdsdywAYlcUzEiMFxOHgol2WYf94Y0YCfaXotn3
	hItpF0KXhbVpvaNNjL57oyQNmuZOfSUG7TO9aLMFvZk4p2hnXqdT8zPUAPppUOF7USO+gkIg6a5
	To6hcd/EMHSc/d67tDT5f7jFhEgCyQQB20whQ5ZN5LF8QhqH2+PQN4k86eAGMtvCqlcZLOOyh0O
	Cqfc5j8dYJ3Wk4mqxEJWSoPcH08DWV/EL2/GFL2LZfiYBMjNW6NDqfh80yNJxyRpjW08R5gKz/3
	VHdxsBFzAHfCYofnJMWhKQziJb3fW3DqH6/rdqnh3Q=
X-Received: by 2002:a05:600c:674a:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-499b06cbaf2mr104118765e9.7.1787233127709;
        Thu, 20 Aug 2026 06:38:47 -0700 (PDT)
Message-ID: <417b2b37-d805-49a4-a23d-46dd8363a751@gmail.com>
Date: Thu, 20 Aug 2026 15:38:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
 <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
 <aff1f879-48c6-4047-a6c1-237a350e0f35@gmail.com>
 <a64d4714-2215-4bff-9dfa-2cbcc36ce3f2@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <a64d4714-2215-4bff-9dfa-2cbcc36ce3f2@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787233128-03CD3A5B-5C826055/10/73395122804
X-purgate-type: spam
X-purgate-size: 18150



On 8/20/26 9:34 AM, Jan Beulich wrote:
> On 19.08.2026 18:06, Oleksii Kurochko wrote:
>> On 8/13/26 9:15 AM, Jan Beulich wrote:
>>> On 29.07.2026 15:40, Oleksii Kurochko wrote:
>>>> @@ -210,9 +217,162 @@ static always_inline unsigned long get_faulting_gpa(void)
>>>>        return (csr_read(CSR_HTVAL) << 2) | (csr_read(CSR_STVAL) & 0x3);
>>>>    }
>>>>    
>>>> +/*
>>>> + * Determine the trapped instruction which caused a guest MMIO trap.
>>>> + *
>>>> + * Returns true if the trap was redirected to the guest, in which case
>>>> + * the caller must stop emulation and return success. Otherwise *insn
>>>> + * and *insn_len are filled in and the caller should continue decoding.
>>>> + */
>>>> +static bool decode_trapped_insn(unsigned long htinst, unsigned long *insn,
>>>> +                                unsigned int *insn_len)
>>>> +{
>>>> +    if ( htinst & 0x1 )
>>>> +    {
>>>> +        /*
>>>> +         * Bit[0] == 1 implies trapped instruction value is
>>>> +         * transformed instruction or custom instruction.
>>>> +         */
>>>> +        *insn = htinst | INSN_16BIT_MASK;
>>>> +        *insn_len = (htinst & BIT(1, UL)) ? INSN_LEN(*insn) : 2;
>>>
>>> In the if() you don't use BIT(), while here you do. Please be consistent.
>>>
>>> Why the use of INSN_LEN(), when due to the earlier assignment it'll always
>>> yield 4 here?
>>
>> ld/sd instruction which we are trapping here at the moment here could be
>> 2 bit and 4 bit depends on C extension so we need to pass correct
>> instruction length to advance_pc() after it is emulated.
> 
> Well, fine, but how does that matter? I pointed you at the preceding
> assignment, which sets bits 0 and 1. With that INSN_LEN() is guaranteed
> to return (at least) 4 (and it's not presently capable of returning
> values larger than 4).

Oh, right. But considering that htinst can handle only max 31 bits so it 
looks like it can't fit more then 32 bits instructions. But I think it 
is needed ifdef around INSN_LEN to not miss add support for longer 
instructions or just write now more generic macros (or static inline 
function).

> 
>>> Finally, how would the caller know whether it looks at a transformed insn
>>> or (as fetched below) a "normal" one?
>>
>> According to the spec ((part from htinst ... ):
>> On a synchronous exception, if a nonzero value is written, one of the
>> following shall be true about the value:
>>
>> • Bit 0 is 1, and replacing bit 1 with 1 makes the value into a valid
>> encoding of a standard instruction.
>> In this case, the instruction that trapped is the same kind as indicated
>> by the register value, and the register value is the transformation of
>> the trapping instruction, as defined later. For example, if bits 1:0 are
>> binary 11 and the register value is the encoding of a standard LW (load
>> word) instruction, then the trapping instruction is LW, and the register
>> value is the transformation of the trapping LW instruction.
>>
>> • Bit 0 is 1, and replacing bit 1 with 1 makes the value into an
>> instruction encoding that is explicitly designated for a custom
>> instruction (not an unused reserved encoding). This is a custom value.
>> The instruction that trapped is a non-standard instruction. The
>> interpretation of a custom value is not otherwise specified by this
>> standard.
>>
>> • The value is one of the special pseudoinstructions defined later, all
>> of which have bits 1:0 equal to 00.
>>
>> So setting bit 0 to 1 we will guarantee that it is normal "normal"
>> instruction.
> 
> Right. Yet my question was how to distinguish the cases. Or are you trying
> to tell me that distinguishing isn't going to be necessary, anywhere?

Yes, I don't see for now why such distinguish is necessary. But I will 
re-check that point.
> 
>>>> +    }
>>>> +    else
>>>> +    {
>>>> +        struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>>
>>> Pointer-to-const.
>>>
>>>> +        struct trap_info utrap = { 0 };
>>>
>>> Just {} please.
>>>
>>>> +        /*
>>>> +         * Bit[0] == 0 implies trapped instruction value is
>>>> +         * zero or special value.
>>>> +         */
>>>
>>> How come you get away without dealing with pseudoinsns? The insn pointed at
>>> by regs->sepc is of no interest for faults caused by implicit memory accesses
>>> originating from VS-stage address translation.
>>
>> It is really problem but I think it should be resolved much earlier in
>> handle_guest_page_fault(). I will add the following:
>>
>> /*
>>        * A guest page fault taken on an implicit memory access performed for
>>        * VS-stage address translation (reading a PTE, or updating its A/D
>> bits)
>>        * reports a pseudoinstruction in htinst rather than a transformed
>>        * instruction. Such a fault can't be emulated: htval holds the guest
>>        * physical address of a VS-stage PTE rather than of any access the
>> guest
>>        * itself performed (and its two least significant bits are zero
>> instead
>>        * of matching stval), while the instruction at sepc is unrelated
>> to the
>>        * access which actually faulted.
>>        *
>>        * Report an access fault to the guest at the original virtual address,
>>        * which is what stval already holds and what hardware would raise
>> for a
>>        * page table walk hitting an inaccessible address.
>>        */
>>       if ( (htinst == INSN_PSEUDO_VS_LOAD) || (htinst ==
>> INSN_PSEUDO_VS_STORE) )
>>       {
>>           struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>           struct trap_info utrap = {
>>               .scause = (htinst == INSN_PSEUDO_VS_LOAD) ? CAUSE_LOAD_ACCESS
>>                                                         : CAUSE_STORE_ACCESS,
>>               .sepc = regs->sepc,
>>               .stval = csr_read(CSR_STVAL),
>>           };
>>
>>           riscv_trap_redirect(&utrap);
>>           return;
>>       }
> 
> That's not what would happen on bare hardware though, aiui. At least I don't
> think I ever found it being spelled out anywhere what the supposed behavior
> is when a page table resides in unpopulated space.

What do you mean here by "unpopulated space"? IIUC, it means that to 
have things working we should have GVA -> GPA mapping, if there is no 
such mapping then correspondent access bits aren't set and so a 
page-fault exception corresponding to the original access type. So not 
access fault should be here but just correspondent page fault.

If GPA itself is incorrect (it isn't mapped in G-stage) then it looks to 
me that access fault should be generated. But in this case I think we 
won't be here (in handle_guest_page_fault() at all) as just a page fault 
will be generated (so G-stage fault), not guest page fault (VS-fault 
what is the case in the code above but as I told in prev paragraph 
access fault is too much in that case and just page fault will be enough 
and it looks like it is correspond to hardware behavior).
> 
>>>> +        *insn = riscv_vcpu_unpriv_read(true, regs->sepc, &utrap);
>>>> +        if ( utrap.scause )
>>>> +        {
>>>> +            /*
>>>> +             * A G-stage fault here would mean the P2M mapping of the page
>>>> +             * containing the trapped instruction disappeared after it was
>>>> +             * fetched.
>>>
>>> Does it? What about, again, faults from VS-stage address translation while
>>> hardware was trying to fetch an insn? That is ...
>>>
>>>> Nothing removes P2M mappings of a running domain yet,
>>>> +             * so this cannot happen.
>>>
>>> ... the necessary P2M mapping may never have been there.
>>
>> If VS-stage failed then CAUSE_LOAD_PAGE_FAULT will happen so BUG_ON()
>> won't occur and it will be passed to guest to handle it.
> 
> Are you sure? So far it was my understanding that CAUSE_LOAD_PAGE_FAULT
> would happen when VS-stage translation hits e.g. a non-present leaf
> entry. But got an address translation failure while doing the VS-stage
> page walk (i.e. failure to translate the address found in a VS-stage
> PTE to a host address) would raise CAUSE_LOAD_GUEST_PAGE_FAULT.

Sorry, you are right. Then what I suggested before instead of BUG_ON() 
will be enough:
             if ( is_load_guest_page_fault(utrap.scause) )
                 utrap.scause = CAUSE_FETCH_ACCESS;
as if we don't have mapping in G-stage then it looks like guest is 
trying to reach something wrong.
> 
>> BUG_ON() here catches CAUSE_LOAD_GUEST_PAGE_FAULT (G-stage translation
>> failure).
>>
>> Also, as I mentioned above I will change BUG_ON() too:
>>
>>               /*
>>                * 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
>>                */
> 
> What is "bus" here (dym "bug"?), and why is the sentence unfinished?
> 
>>>> +             * TODO: Revisit once P2M mappings can be removed at runtime.
>>>> +             */
>>>> +            BUG_ON(is_load_guest_page_fault(utrap.scause));
>>>> +
>>>> +            utrap.sepc = regs->sepc;
>>>> +            utrap.stval = utrap.sepc;
>>>
>>> How do you know the fault was at .sepc? A 32-bit insn crossing a page boundary
>>> (implying the C extension is available) may well fault only on its higher half.
>>
>> According to the spec, if stval is written with a nonzero value when an
>> instruction access-fault or page-fault exception occurs on a system with
>> variable-length instructions, then stval will contain the virtual
>> address of the portion of the instruction that caused the fault, while
>> sepc will point to the beginning of the instruction.
>>
>> So here, we are trying to emulate what real hardware will do in this
>> case. In regs->sepc, we have the start of the instruction that we didn't
>> touch. sepc is filled according to the spec in this case.
> 
> Right, but utrap.stval is set to the same value, which is explicitly not
> in line with what you say above ("will contain the virtual address of the
> portion of the instruction that caused the fault").>
>> Regarding utrap.stval, we know that utrap.sepc points to the correct
>> part of the faulting address, as we are reading the instruction in
>> 16-bit chunks:
>>
>> HLVX_HU(%[val], %[addr])        ; low 16 bits from sepc
>> andi %[tmp], %[val], 3
>> addi %[tmp], %[tmp], -3
>> bne  %[tmp], zero, 2f           ; if not (insn & 3) == 3 -> 16-bit, end
>> addi %[addr], %[addr], 2        ; <- addr is now sepc+2
>> HLVX_HU(%[tmp], %[addr])        ; high 16 bits, possibly from another page
>>
>> So, if a trap happens while reading the high 16 bits (which may be
>> located on another page), then utrap.sepc, if the read fails, will point
>> to the high part of the instruction, which is what the spec requires.
>>
>> Does that make sense?
> 
> Not really, no. As said above - the code as written guarantees
> utrap.stval == utrap.sepc, and that cannot always be correct.

Oh, right, utrap.stval = utrap.sepc; should be just dropped utrap.stval 
already has a correct value (from ex_handler_trap_info()) which should 
be passed to guest.

> 
>>>> +/*
>>>> + * Check alignment and dispatch a decoded MMIO access to a registered
>>>> + * handler. On success (0), info->data holds the read value for loads.
>>>> + */
>>>> +static int do_mmio(mmio_info_t *info, unsigned long fault_addr,
>>>> +                   unsigned int len)
>>>> +{
>>>> +    /* Fault address should be aligned to length of MMIO */
>>>> +    if ( fault_addr & (len - 1) )
>>>> +        return -EIO;
>>>> +
>>>> +    info->gpa = fault_addr;
>>>> +    info->len = len;
>>>> +
>>>> +    switch ( try_handle_mmio(info) )
>>>> +    {
>>>> +    case IO_HANDLED:
>>>> +        return 0;
>>>> +    case IO_ABORT:
>>>> +        return -EIO;
>>>> +    default:
>>>> +        return -EOPNOTSUPP;
>>>> +    }
>>>> +}
>>>
>>> And there's no indication of "retry needed", e.g. when something changed
>>> between find_mmio_handler() and handle_{read,write}()?
>>
>> I don't have any specific scenario where it is needed now so I don't
>> know what to say.
>> And there is no race between find_mmio_handler() and
>> handle_{read,write}() as find_mmio_handler() returns copy of the
>> structure under read_lock():
> 
> Oh, right, but that's not visible here at all and requires going back to
> patch 04 to realize.

I will update the comment above function:

/*
  * 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.
  */


> 
>>>>    static int emulate_load(unsigned long fault_addr, unsigned long htinst)
>>>>    {
>>>> -    return -EOPNOTSUPP;
>>>> +    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>>> +    mmio_info_t info = { .is_write = false };
>>>> +    unsigned long insn;
>>>> +    unsigned int shift = 0, len, insn_len;
>>>> +    bool is_unsigned = false;
>>>> +    int rc;
>>>> +
>>>> +    if ( decode_trapped_insn(htinst, &insn, &insn_len) )
>>>> +        return 0;
>>>> +
>>>> +    /* Decode length of MMIO and whether it is a sign- or zero-extending load */
>>>> +    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
>>>> +        len = 1;
>>>> +    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
>>>> +    {
>>>> +        len = 1;
>>>> +        is_unsigned = true;
>>>> +    }
>>>> +    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
>>>> +        len = 2;
>>>> +    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
>>>> +    {
>>>> +        len = 2;
>>>> +        is_unsigned = true;
>>>> +    }
>>>> +    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
>>>> +        len = 4;
>>>
>>> Already up to here this demonstrates a weakness of the INSN_MASK_*
>>> set of #define-s (which I similarly observe in binutils, and I expect it
>>> all has the same questionable origin). All INSN_MASK_L* and INSN_MASK_FL*
>>> (also INSN_MASK_S* and INSN_MASK_FS*) are identical, allowing for a nice
>>> switch() to be used here in principle. That said, with access width
>>> nicely encoded in FUNCT3, it's not even clear whether a switch() would
>>> end up being needed / efficient.
>>
>> .......
>>
>>>
>>> Otoh none of these masks cover the pseudoinsns that htinst may supply.
>>
>> As I answered above we should handle that before this function will call
>> so here we won't deal with htinst at all. Of course, if what I wrote
>> above is correct. I will double check before applying that.
>>
>>>
>>> Further, what about A-extension insns? Some (if not all) of them can
>>> plausibly be used on MMIO, I think.
>>
>> I’m not really sure that the A-extension is actively used for MMIO.
> 
> Does the spec preclude their use? I'm unaware of such a restriction.

Definitely no. In this case hypervisor will tell that we can't emulate 
this instruction and then extra handling should be added.

> 
>> At
>> least, Linux doesn’t do that for now, which is why we don’t handle
>> A-extension instructions here.
> 
> Focusing on what present Linux needs is okay, but then remaining gaps
> should (as said on various other occasions before) be clearly marked.
> 
>> I think this is related to the fact that MMIO is usually (if not
>> always?) naturally aligned, and naturally aligned loads and stores are
>> guaranteed by RISC-V to execute atomically.
> 
> How does this matter, when a bit or field in MMIO may serve the purpose
> of e.g. a semaphore?

Then yes it will be an issue and such instruction should be emulated 
(when such use cases will come into play)

> 
>>>> +    {
>>>> +        len = 4;
>>>> +        is_unsigned = true;
>>>> +    }
>>>> +#endif
>>>> +    else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW )
>>>> +    {
>>>> +        len = 4;
>>>> +        insn = RVC_RS2S(insn) << SH_RD;
>>>> +    }
>>>> +    else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP &&
>>>> +              RV_X(insn, SH_RD, 5) )
>>>> +        len = 4;
>>>> +#ifndef CONFIG_RISCV_32
>>>> +    else if ( (insn & INSN_MASK_LD) == INSN_MATCH_LD )
>>>> +        len = 8;
>>>> +    else if ( (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD )
>>>> +    {
>>>> +        len = 8;
>>>> +        insn = RVC_RS2S(insn) << SH_RD;
>>>> +    }
>>>> +    else if ( (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
>>>> +              RV_X(insn, SH_RD, 5) )
>>>> +        len = 8;
>>>> +#endif
>>>> +    else
>>>> +        return -EOPNOTSUPP;
>>>
>>> Because you don't permit F/D/Q for guests (yet), FL* and FS* aren't
>>> covered, I expect?
>>
>> At the moment, I wrote this function with handling of MMIO instruction
>> in mind, which are at the moment ld and sd.
>>
>> Even if to permit F/D/Q then do we really need to trap that
>> instructions? Hypervisor could allow access to FPU to guest and then it
>> will be just a question of context switch to properly save and restore FPU.
> 
> And how would you know FPU loads/stores aren't used against MMIO? Later
> on, once V support is added, even its loads/stores might be used that way.
> Think of video frame buffer accesses, for example.

We will get 'return -EOPNOTSUPP' and so guest will be crashed because we 
don't support such work with MMIO.
And then yes it should be likely to be added in parallel with adding 
F/D/Q support for guest. At the moment, KVM supports, for example, F/D/Q 
but doesn't emulate FPU load/store but I agree that with your example it 
could happen.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 13:56:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 13:56:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396599.1634385 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx3Fh-0000Wt-Oa; Thu, 20 Aug 2026 13:56:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396599.1634385; Thu, 20 Aug 2026 13:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx3Fh-0000Wm-L4; Thu, 20 Aug 2026 13:56:17 +0000
Received: by outflank-mailman (input) for mailman id 1396599;
 Thu, 20 Aug 2026 13:56:15 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ruoyuw560@gmail.com>) id 1wx3Ff-0000WN-TQ
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 13:56:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx3Fd-004Cef-1F
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:56:13 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ruoyuw560@gmail.com>)
 id 6a870776-bab6-0a2a0a5309dd-0a2a45079eaa-20
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:56:13 +0200
Received: from [209.85.216.48] (helo=mail-pj1-f48.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ruoyuw560@gmail.com>)
 id 6a87077b-b4ea-0a2a45070019-d155d830e1ea-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 15:56:12 +0200
Received: by mail-pj1-f48.google.com with SMTP id
 98e67ed59e1d1-38e7109321dso1472780a91.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 06:56:12 -0700 (PDT)
Received: from haichao.tail057a43.ts.net
 ([2001:da8:e000:1206:85a4:b9cf:b578:4307])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3957f9ab4b4sm6653893a91.8.2026.08.20.06.56.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 20 Aug 2026 06:56:10 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787234171; x=1787838971; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=IK7VtHj+yeJrnKBH2mt3PEgztVO6LVM/yM8XqEcV4BY=;
        b=bYEhHylU7fZzWK3DV+nPQbiZnn4JIfjyrTcQVacBESHQVmqY3T1rwxH0ZMeKnRxuQM
         +C0N7UqMlheeFwObIIgZWVvASVVBmHLBCSnU9wZSlMNAp2giF3bYXrXe69fkS/GNgwzL
         WZhbHX2hhhJxLbw43WpSJh6LdMIuD5ecvLxW8n/LsWNfex9KFpTa/EljE0bAKERCNlaM
         T4XnyrbN78N+lJvYk/TBg4n/TXFYdk19DnN598p2walnwhNnRSj/ohLTe7fPlWfNOqhe
         YyHCl7LpzzwLn7LmQdlN33ux6e2jusemVQ9GFgn+NW9uuxIGpRsGl72UAyZF78Ayu7u0
         osTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787234171; x=1787838971;
        h=content-transfer-encoding:mime-version: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=IK7VtHj+yeJrnKBH2mt3PEgztVO6LVM/yM8XqEcV4BY=;
        b=rk/RHRWtDMd4x/WLTSt+kzFr3dGtO82GFHLIzXXsUgXic4Jvl5l8egjjIcuBJPPXsS
         qPgrrtzZyg/O0a+xeDql3RzfOlLhiLDmMjz8o27TDnmj1AOM7p+GQZ0WPAX1Tq+2Sz7+
         QR0XucPE6XYluP8K49hOGnpyvLMgnSxjzDSrHdWUykccUF9QjHrrHEJD+bmXRbfoqmMu
         4hzst8I4b2gfHG8YHEsGEb4oU3h08JXqOnC6NgtcjCHK5wr0Qn/hdzn1ApJOXbT/Kwyf
         Wb3+wS6tGYI/gK12ay2ti+bXBzitQm3J2DLivHhgilK25GrjDUF0qKB3M20hWbOFY2U7
         oUXw==
X-Gm-Message-State: AFuF++lTA+gTC/Uex/BlW2bs7BnfxN0a+viXwTKhE+dxwqocjdAMAwvZ
	t0ckZ1Tz0sukWkbKrODilD2+eOXY4yav1B75ZTj4A00HE1CFTgE+1KO9
X-Gm-Gg: AR+sD12ADH67XCIP4MuPXvD6vkrIxIw7/NLQJl9uCx6jA3pIIivLBB/bVe6Qp3/JkYy
	S7xNKQCX/Dy8XmjAAU5046O3SwG81udR85UM9fBBNTGNk86tQcEz1LJGJRRBbcNHz/Z64dkGrzf
	iV0yy9Epz/+G2EBOw0MoQ8D/P51LPBaFP9QKRpfWxyRZNnSOb1nXyL69pauKOEcxuAEdMMdkoee
	voJ6u9VbqNzLe7WGCmnb1MysS71a6+GCoZqJIEnCX85Aeq2S9kJUwSMPZhkm29QQDBx7grTOnxP
	ZAi38mEN/NL9vIL/l4ikEx/4mDM1XIzo70bRiIDAQz6HE5f5zIJrngt7ztE06wOhesF/Wl9xg2g
	eIKH9J/+4VGQ5phTnN4j/oWffY9QKsljexFUZqcLbxlWqklBzzVix7YyWsqrC3CkO55MnAb+6IG
	DiqEKkUB0Gl76G+kuRVn6xwZP5Euu6zzPbxIipWNW920cI4nlurVpnoYQZT/H2MbNZY5uzGGxqj
	BFUUsc+
X-Received: by 2002:a17:90b:2d05:b0:380:21b7:e727 with SMTP id 98e67ed59e1d1-39581470f03mr25148158a91.14.1787234170841;
        Thu, 20 Aug 2026 06:56:10 -0700 (PDT)
From: Ruoyu Wang <ruoyuw560@gmail.com>
To: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@novell.com>,
	Lukas Wunner <lukas@wunner.de>
Cc: xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Ruoyu Wang <ruoyuw560@gmail.com>
Subject: [PATCH v2] xen/pcifront: Fix PCI device reference leak in AER handling
Date: Thu, 20 Aug 2026 21:56:03 +0800
Message-ID: <20260820135603.3901798-1-ruoyuw560@gmail.com>
X-Mailer: git-send-email 2.51.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787234173-35EC6AE4-DEF991CC/0/0
X-purgate-type: clean
X-purgate-size: 2143

pci_get_domain_bus_and_slot() increments the reference count of the
returned PCI device. pcifront_common_process() drops that reference only
when the device or its driver is missing. All paths for a bound device
either return directly after invoking an error recovery callback or fall
through without calling pci_dev_put(). Consequently, each AER request for
a bound device leaks a reference and can keep the device allocated after
removal.

Declare the looked-up device with __free(pci_dev_put), so every return
path releases the reference after callback dispatch. This keeps the
device alive while its callback runs and balances the lookup without
restructuring the callback returns.

This issue was found by a static analysis checker and confirmed by manual
source review.

Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.")
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
Changes in v2:
- Use __free(pci_dev_put) instead of restructuring the callback returns.

Link: https://lore.kernel.org/r/20260813153138.3953222-1-ruoyuw560@gmail.com/
---
 drivers/pci/xen-pcifront.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index cffc32d660327..0dea8a69fa36c 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -579,16 +579,15 @@ static pci_ers_result_t pcifront_common_process(int cmd,
 	int bus = pdev->sh_info->aer_op.bus;
 	int devfn = pdev->sh_info->aer_op.devfn;
 	int domain = pdev->sh_info->aer_op.domain;
-	struct pci_dev *pcidev;
+	struct pci_dev *pcidev __free(pci_dev_put) =
+		pci_get_domain_bus_and_slot(domain, bus, devfn);
 
 	dev_dbg(&pdev->xdev->dev,
 		"pcifront AER process: cmd %x (bus:%x, devfn%x)",
 		cmd, bus, devfn);
 
-	pcidev = pci_get_domain_bus_and_slot(domain, bus, devfn);
 	if (!pcidev || !pcidev->dev.driver) {
 		dev_err(&pdev->xdev->dev, "device or AER driver is NULL\n");
-		pci_dev_put(pcidev);
 		return PCI_ERS_RESULT_NONE;
 	}
 	pdrv = to_pci_driver(pcidev->dev.driver);
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 14:09:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 14:09:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396612.1634395 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx3S3-0002WD-Vg; Thu, 20 Aug 2026 14:09:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396612.1634395; Thu, 20 Aug 2026 14:09:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx3S3-0002W6-Rb; Thu, 20 Aug 2026 14:09:03 +0000
Received: by outflank-mailman (input) for mailman id 1396612;
 Thu, 20 Aug 2026 14:09:03 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wx3S3-0002W0-0i
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:09:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx3S1-00FXxb-VQ
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 16:09:01 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a870a6f-bab6-0a2a0a5309dd-0a2a4502ed04-48
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 16:09:01 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a870a7d-6ca4-0a2a45020019-d155802cb94a-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 16:09:01 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-499b2981a7bso9498185e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 07:09:01 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa0d6721sm189202335e9.11.2026.08.20.07.08.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 07:08:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787234941; x=1787839741; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=iP3exa7q+yUmtHIF2lquYm5BmWxm+URZQXH/m7lx+E4=;
        b=I0/yJ71OMPb5o+swBxTNulF7I+RCn0bbwoiRHpc+V4qf3tO36CuKjX8yKXh50mGKqV
         upasSz0rRYJ3w56+YT+zCOSY2j8LoO+7k/Hx+hPvChhG0osAzHpU40lxKwt2b4mUi9GT
         v6xSYRoQ5qmSH6jHs6YiuDYCjRl8EIY5zwmjtGsfCD4EBnCcUKNCbnv9g+nFnqZeq+W7
         h49BgfvYM9ONio9oy6z30VsewE3zZBaB3BGD97VhbK1KtrA/s29wyzP6iam6y8Oc7QR0
         70b4ph17SIc4fRJrMVj8U2Fc9f26PQCcVh6yWn368VRQcKWbA8JU5rXUY4/WU7trzwSl
         VAeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787234941; x=1787839741;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=iP3exa7q+yUmtHIF2lquYm5BmWxm+URZQXH/m7lx+E4=;
        b=F3VkyVJPalTWuthtsOTFr/Qky2ikT8qIXhHmUj54ooV8HsdIpHxlV0HNHShk0Bvhl7
         JEfLGAewFp62HxmFeVDnQSNhB3B05Sh8AVN0/r4MGtKglnp0LqNKH7A6AQkZR175OFtw
         rNnPBTFX4Kq2z+1q+CwoQGVicqbpQuRQ7XivRmjSmkrK1wYEWVWSXXhxJG4VOdZxn7CQ
         6x0zJEkNjsCo/4uyn7xI2/qJdqcfa6MpBx3SqxvGJpdauCSSS70gWuIUjKCa7pAzgwXl
         ZyUIH6N4UoLeLQOEkJIB5CMoWTRhiUf/58uMz8uaC1TsiTtkWRLsyk05lNpvfOU2BQfX
         N22g==
X-Forwarded-Encrypted: i=1; AHgh+RqkDjrLAMToYrjzxa3FqlnkakosoFuE3EkhhLXSNPNTmx8x9GtM3rK2F8GIvWyLFuEv3bDrAGWVF9o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/2Z4hRMLeYjSYLkjkrgq6h37wZy4nl+UvKT/5Xz4B45E1Bl3N
	YF7+t+hT4B8hEiyW/jYTYSFMSQQR5xipTk0f8aNMkK7t26i3t+HGGcRLEd4hR1dg+A==
X-Gm-Gg: AR+sD13cwye5MOE9dKg1vZEKlYQxgR6dgIucGXWKC0K0dugDZfn1olptlLfSUb0UkW8
	jQv1MFtPLvSd9bKSEweX6efihxWvGySGZNoZ1+UQRhLdGpjk5saRDFDn8m2fp4tZ9b/u1ft+TmX
	Eiv+74NV+knSXp19IMi3XBi5tsOKCoqfGRaCaTAvxqgHIP7lSDUSXcgImiMcOKKO20+/k4+8QoA
	YOOq6yBv2TJ6RCUINHsMEs6MegTAdtuUdBl9Ft7RLnYx4fUMOhDGfqaDy3loF/dwk+JB+IaRssV
	nExii8XYuO5m2unpHmvXR/xhy4Rz7Y0lSdKsmzgJKHqK/lmN4slyK9dmWiRBU237sHTsao5INqW
	1G82AdLKiKxZS3t5B3I9Eh+L7VNXSDN8aUirl1pxgEJcQ1oS5gLMKm8bfMXlZMRRHlI3Y2iVXtP
	KXTVePidRL5XRrpyMpFyYiZl6WYROtItx7SLugE1WXpEt5vswimpCk3FflsN6a9l+Q/aOjWXcSm
	MQxMsvdF0wWoCD9+NVfMG274X2WC7T0MNHMVkKsJ7hQX8dQvOLBFErpIAtsEzk=
X-Received: by 2002:a05:600c:c08f:b0:499:afcb:24c1 with SMTP id 5b1f17b1804b1-499afcb24demr138394505e9.5.1787234931745;
        Thu, 20 Aug 2026 07:08:51 -0700 (PDT)
Message-ID: <9c006636-cc33-45ae-85cc-800568e6dcf9@suse.com>
Date: Thu, 20 Aug 2026 16:08:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 16/17] xen/riscv: add guest load emulation for trapped
 MMIO accesses
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <cover.1784560663.git.oleksii.kurochko@gmail.com>
 <9b18a20367754605efd6a6b5bf09d4483d9c3ab2.1784560663.git.oleksii.kurochko@gmail.com>
 <7a2e46da-5b1f-448e-aba3-7eefe0a61950@suse.com>
 <aff1f879-48c6-4047-a6c1-237a350e0f35@gmail.com>
 <a64d4714-2215-4bff-9dfa-2cbcc36ce3f2@suse.com>
 <417b2b37-d805-49a4-a23d-46dd8363a751@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <417b2b37-d805-49a4-a23d-46dd8363a751@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787234941-67CBA2AC-800133BF/0/0
X-purgate-type: clean
X-purgate-size: 2611

On 20.08.2026 15:38, Oleksii Kurochko wrote:
> On 8/20/26 9:34 AM, Jan Beulich wrote:
>> On 19.08.2026 18:06, Oleksii Kurochko wrote:
>>> On 8/13/26 9:15 AM, Jan Beulich wrote:
>>>> On 29.07.2026 15:40, Oleksii Kurochko wrote:
>>>>> +        /*
>>>>> +         * Bit[0] == 0 implies trapped instruction value is
>>>>> +         * zero or special value.
>>>>> +         */
>>>>
>>>> How come you get away without dealing with pseudoinsns? The insn pointed at
>>>> by regs->sepc is of no interest for faults caused by implicit memory accesses
>>>> originating from VS-stage address translation.
>>>
>>> It is really problem but I think it should be resolved much earlier in
>>> handle_guest_page_fault(). I will add the following:
>>>
>>> /*
>>>        * A guest page fault taken on an implicit memory access performed for
>>>        * VS-stage address translation (reading a PTE, or updating its A/D
>>> bits)
>>>        * reports a pseudoinstruction in htinst rather than a transformed
>>>        * instruction. Such a fault can't be emulated: htval holds the guest
>>>        * physical address of a VS-stage PTE rather than of any access the
>>> guest
>>>        * itself performed (and its two least significant bits are zero
>>> instead
>>>        * of matching stval), while the instruction at sepc is unrelated
>>> to the
>>>        * access which actually faulted.
>>>        *
>>>        * Report an access fault to the guest at the original virtual address,
>>>        * which is what stval already holds and what hardware would raise
>>> for a
>>>        * page table walk hitting an inaccessible address.
>>>        */
>>>       if ( (htinst == INSN_PSEUDO_VS_LOAD) || (htinst ==
>>> INSN_PSEUDO_VS_STORE) )
>>>       {
>>>           struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
>>>           struct trap_info utrap = {
>>>               .scause = (htinst == INSN_PSEUDO_VS_LOAD) ? CAUSE_LOAD_ACCESS
>>>                                                         : CAUSE_STORE_ACCESS,
>>>               .sepc = regs->sepc,
>>>               .stval = csr_read(CSR_STVAL),
>>>           };
>>>
>>>           riscv_trap_redirect(&utrap);
>>>           return;
>>>       }
>>
>> That's not what would happen on bare hardware though, aiui. At least I don't
>> think I ever found it being spelled out anywhere what the supposed behavior
>> is when a page table resides in unpopulated space.
> 
> What do you mean here by "unpopulated space"?

A physical address range neither populated by RAM nor used by MMIO of any device.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 14:12:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 14:12:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396621.1634404 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx3Vp-00041J-E7; Thu, 20 Aug 2026 14:12:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396621.1634404; Thu, 20 Aug 2026 14:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx3Vp-00041C-AF; Thu, 20 Aug 2026 14:12:57 +0000
Received: by outflank-mailman (input) for mailman id 1396621;
 Thu, 20 Aug 2026 14:12:56 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wx3Vo-000415-D3
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:12:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx3Vn-00CwKe-Ep
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 16:12:55 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a870b56-8faa-0a2a0a5109dd-0a2a45069ca6-40
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 16:12:55 +0200
Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a870b67-195a-0a2a45060019-d1558033d95a-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 16:12:55 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-499acf0fb55so13818755e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 07:12:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499b2b23a00sm37640935e9.3.2026.08.20.07.12.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 07:12:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787235175; x=1787839975; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=eLyn7kDgqyTEdRhm0I3BE/eIB4i5+QEwjBk6DsrXcpc=;
        b=IXv1BqxP04jKWIxU+HTARMpO6IdUMhKdz/YCaLMZet070BmgP9DBlr+FfceikXz8Se
         ZRaeenl+xB6QJdXXbk0E4G5UwVKm/imNDDyW3JSqs2PMGBiPhPQpsBsap0PBYYgMrC5q
         T7FwNFxOj1ZdMmQTdaSjb5+j95IXB/rI2LuEC1oKLivmIf6BTUgC9SB4AvL9iygUv+91
         nc7fl+AV+TO+OdBQ+TzzbxksvqjIN+U22/yXmK6CWYrthnFlLOaGCqFyD1hGRsQ+UgFF
         KjW2Ph0P2gsyH4ZdE9PF+WIOtKXMY9r9cuPtGADr9mwu0nLFCbhuLdBUlu2YRFfpk36I
         WD7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787235175; x=1787839975;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=eLyn7kDgqyTEdRhm0I3BE/eIB4i5+QEwjBk6DsrXcpc=;
        b=gkAth+s/KJgcdih8lUzm62IaSanuX7XKmLjr4qgYlA3FN0grHxWwkrYWBCeQ8gu8sW
         M+slRS/kte41DFb/EpQi1I7qac33CqYa4xFFuoPndKPcBpavZUE79MmftBFSwmvB0wlP
         1StFxKMOTYreU83gEJuaL+tqi7zbvui6rSdmr5LMPy9yRiC/PjNxI4F2rwxSg5b3GXKn
         /XM0wtYozqc7XgW5NzdVr35AFOv9db/oqUII5I0Ayfh3k2EqScYkYf7aj+8yfc4avy57
         rXW4P433+tl4L7IUB2Mj9H4HXK6mef0k1isnbH/2OE2Ayn+hSkdNd3APAobbMlKuFeGE
         BUqg==
X-Forwarded-Encrypted: i=1; AHgh+RoctLqJQ5n/6HNcirL/QvAr6IfnbGtDTkCgPLCoIwGevLlTafdCNarwyAVKa1tPG5Wb6AjDFMXM4ic=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4rM1TUwKUUHAS01EwLONGGI3n2SmmxQY37ff9nkgYVCidqkXH
	d7Ur7LzlX//JqX0HzlvuxWGaTH3aNIQgyngPqNSwra6NDt9CNg1P2fNxPfC5Qgbcgg==
X-Gm-Gg: AR+sD11U5RXT1r7+jup7SZe7LEDekEvY3gTqZidX+AHxVShoi7DhQNad2bCfudMxpLW
	HjmoPO6lkIvKTTxJPPGuomEBca+zygzPIy09fvAMDC+J4OufMvbEl5jsok826csqihJ9xLeb42N
	5gaZq9yygcov0gToG1x3xSytpJzkpxMKxOfw8Qmi10XTTYRC5EI/cDXx5ennyq9xUPg2YZDSLdJ
	RRiWkpgfrySeWCppWd632mxJjjwlgh2SHJ4XLtjmZ59dHL+y5kLocgPEekTc1m1GI1wklCE/3Ar
	+vCrteNr36ZJNKdGD+OdJzSXsEstDhqixEkC8Xs9yARVUmlabjIgth2yGXF43QEDh5+RAaViXXi
	FOU67LNsvbKVmUoyvc2kWLM7RLH7X4sqorXxQZZfJTqnBeTr7hOSW9Rof20kOfU9RUDQ1eCExyH
	9b1uNH5Ae/WlT/QLU5HtbIOz3WhKwHsPPs45rg4zUjBXKQJboK0iOW/zeEgoYd43wXSdkcAlD30
	Am983O31spE8OUmCMMMNjQFpHM8jUiBQoOGAg==
X-Received: by 2002:a05:600c:6211:b0:499:a760:722f with SMTP id 5b1f17b1804b1-499aa1ba0b7mr239862705e9.13.1787235174844;
        Thu, 20 Aug 2026 07:12:54 -0700 (PDT)
Message-ID: <cc9dd2bf-bc0d-48b5-a11b-e1e22e26a3b4@suse.com>
Date: Thu, 20 Aug 2026 16:12:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when
 XSAVE is absent
To: Andrew Precious <andrewprecious388@gmail.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech,
 anthony.perard@vates.tech, xen-devel@lists.xenproject.org
References: <20260819180735.135911-1-andrewprecious388@gmail.com>
 <aee239df-0582-4973-82ae-65688a7d6b9a@suse.com>
 <CAF14T9mYViiNQfJ8TG1RU0hqf7m6yUH1-yFCzWXXJdQOhmFkgA@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAF14T9mYViiNQfJ8TG1RU0hqf7m6yUH1-yFCzWXXJdQOhmFkgA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787235175-F4C0777B-0AF56D2E/0/0
X-purgate-type: clean
X-purgate-size: 1346

On 20.08.2026 14:30, Andrew Precious wrote:
> I just realized that I attached the binary result without the fuzzer error.
> To generate the previous assertion error I would have to rerun the fuzzer
> again which took many hours(~18hrs). Though that was the only error I found
> after that long.
> 
> VM machine that I performed the fuzzing on:
> - A VM running Debian GNU/Linux 13 (trixie)
> - x86_64,QEMU Virtual CPU version 2.5

What does that mean CPUID-wise, seeing that ...

> On Thu, Aug 20, 2026 at 11:45 AM Jan Beulich <jbeulich@suse.com> wrote:
>> On 19.08.2026 20:07, Andrew Mbugua wrote:
>>> While running the x86_instruction_emulator fuzzer via AFL, I encountered
>> an assertion failure in the emul_test_read_xcr() function.
>>
>> Thanks for the report.
>>
>>> The fuzzer is able to generate a CPU state where cpu_has_xsave is false.
>>
>> I'm having trouble here: cpu_policy isn't populated from fuzzing input, and
>>
>> /* Intentionally checking OSXSAVE here. */
>> #define cpu_has_xsave     (cpu_policy.basic.raw[1].c & (1u << 27))
>>
>> would mean that upon filling cpu_policy (emul_test_init() ->
>> x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
>> suggesting you did the fuzzing on some really old hardware?

... there was this aspect that I couldn't understand?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 14:58:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 14:58:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396657.1634411 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4Du-00012V-JU; Thu, 20 Aug 2026 14:58:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396657.1634411; Thu, 20 Aug 2026 14:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4Du-00012O-GL; Thu, 20 Aug 2026 14:58:30 +0000
Received: by outflank-mailman (input) for mailman id 1396657;
 Thu, 20 Aug 2026 14:58:29 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wx4Dt-00012I-8G
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 14:58:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx4Dq-009Lls-QG
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 16:58:26 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a87160c-e002-0a2a0a5209dd-0a2a4508a794-2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 16:58:25 +0200
Received: from [98.137.65.146] (helo=sonic309-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a871610-f659-0a2a45080019-62894192a941-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 16:58:25 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Aug 2026 14:58:23 +0000
Received: by hermes--production-ne1-6dbcb84f44-vcvxd (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 16eeb344b7bc8d6ce5e46c7023ef40a1; 
 Thu, 20 Aug 2026 14:58:20 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787237903; bh=p77KaGKTsaeXAG5o+cyXNB9f2yKatwNXCTXLE+YTHAg=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=NoyC9rOw8RWey/V1PO1SpvZNZ3zEsvyRn74id8qDU9s5/MhzXmXKzMPiU6ymTi2JO/Hjy6azBbH791NRec7SLnzJYqFWvu51toQDqy8cPhRopvUKvxjC5WD0pN7lswKpexRUxY3R8sdKtl6A1Mwe9x9DldHDf0fULrGtZ+JDGiBbjkJkMdYmw0869opX+M98EWCPJoiyFwtI8b/QHsMPIz2SeiZ/vTCBS87s7VIjmLK8vGo5xqdO5ibr8KSJXcfDOFce5JuufNHaHHmIDVaO0jhUKf4D+Vwi3jhz43xQZ6JmiRn502pH6CJFUb2gm1+5W1yn+Dt3ekBIiFuI+KCfkQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787237903; bh=ngpd+xLtVTuYPkIPTLJVC9xtovhuqBfKTw9DyvAO0ov=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=EO2W8p9FNou5eztq8nu0QOg88NTzcLJvA2XCxLMsTPioan1lAOSq9v5LRBs8nsyRKpp/N2CcpGKB9m9Xsl4WJxU77BmZqncdb2zB1QBcB5iRSZb6+PxmmbSeKjIVx66SsC96bCQV3XNs8r6tLHZh3k3zUzjhKRA3jkjPbi8cu389nJ3n8/n13Q4wGa2TEghZ67w8DNjO16AEL6AZpjodwNRlOSbg4FW6WvFroqFeokcNZGL+KBumy7yyOryDcAU3+Lk+zMCeJ4Bgh3VfOuvYKMA3piqL/j9zyIPOHtcryYOGqvjcInNgxdffU2Xbl7ZwgFY6gN72FutfVfgqNa1YNQ==
X-YMail-OSG: 4m.E8lEVM1lobNUVJSQfmBbsGPNSHtIk7w8KuisfZQNf.TPOO.iJ86AmnWbvhBQ
 aiGyhOTLAQ6SWmCpumRQZIR9nAFXmH_doE45.snMJWsAOpwJVVhx2hUZjw03_rzHxmsFyqjC.FTs
 Z4XPKjMlvvIIegazg9BuKyJXu7TR_IO_C5ei6qTx0ryNPHOwfK7SRrBIMk_eu6.mCOjsDaEtD6hF
 lZAMoweJpB_gUhiJefDyPk1CgN0gM.z0hj4uG74R5xGP1SMekKp3EU27tZT9cXTmh0J3XFRF.hBX
 rs5PRluGBLw7sTqspVveQ05W.lHPb9C7xZKPol0.Bcc3eLuBKaY9..MPbVU7ZKHtXH_UVb9YfBSK
 I8kvbktx8NH0aukIyzRX2KdFmPxg7RdqmQqLme65UOTndRc9.xj9d1.aGIyw4Zio2_qv0MJcTl1N
 k3qM_Hzfx5zJ2zwgLD7c7KIw_QT3GY1q2osDq3veW24E1PWM3E2d9I4jG48JXOMfBARbfs122OtJ
 nlbpFFvS2R1OnD0UQKIHtpAT4C.7jpS9XlkrMGvjsd5Bfo1jHj9fva4re7v4x3oJdU6f7eMMOnFS
 sAuVWX4c3M6uDCKOEU1octUs.IMZpM87Y7h5XB9aNL4CIhdsy_evwv9ZV9hKDgRjcH94DbTbkNwX
 P628gydnPs.Y8w8FctL6_jtljedK47bW9Kd9NmE8dxb_YtXSoQ0MfbZA7Otga9QNYNB6EEiSrbEe
 K40HMdYJ_FVcDV199I9rhUsPDsNTYia3RW30PHaqvDoxj2gKdP5p7NBQ9X8nie2KPmttYp7ZtSdc
 c5cQ73ZiXpdEhNhuYHshfB0DC06jKHaiyTdhX8_RQKGqH5zpWAvvtXmvutLa1OTbst1l4p1REoMz
 RDtdA9HuVpdnx2hNYDQv0H3mxSz31qTcfEg5tUOQvBwRydC_f8avi0FO7zzkj84i29FvqrlXfHVf
 0OnkrS9Td9RjZNuaGqq_G9OJWv_lhb67l.UJYBM7.75m42QST7EcFaoExNLJ1MYwNdZKKg5qI67_
 U4zHKA_88uusMGsFCP55igjWg_Bya8rW4xqyVlsiwmZwBVANtEPB.cM.zZD04onuerhnYQwXWY7Y
 okBGLvVKdeV5hbPQ1aBw5c3Qai_4FbcsAgpK8VQylkt07.JeXLyjp_epj71azR_TxQXI.2XtrKsT
 sKAYlmhshOwgJ24xQQqA1Z6iLoLbegVgCqUSyofiMl2yeOjAxLGSE..vdXlcgS_tCz6GYUELEm7H
 VnyWMoa.FNL0S5.aOYIQRgfMw0zFOGprEyTO8UMPjjedYqe.Te9KQ3PNMcz2uR44TEvgZ1ogEfKr
 X0OH_pyXZojtTFdWO0J8bTsUEZBFAnSQztYQ5bZCibCNY76r73NgjPTT8PZJussU8UB_8QOKOzYE
 uluE_XAWWT9MI2zq0_LbMrND2Gw0hpDGE1ejqpg2A.YeBYPFHfub6ST1ONY8tPdNhzTiOa7.D6Dd
 yL3ns3Ck_9nr7MqYwrXrCtyDtkXzcNpoqNadABPpI4ogRq0x4fiaK5EjEM2FwQ9P2bIVP9MsvM1s
 hVOdr67mYTk0AOj0kqQRlnOOtti9XaVc9qVESrQP_o_gIW4HNFYBHeWCzpGz0sbz5yLOaNKIRqwe
 Dpm4DF62yMfL3Bip0OWWr0RBXqZ9t_D4uFcD07k..86V7XCd8bv7pOW5JGN77jfqPiUGaC72of_u
 7OzcqBb.10dKxN1qX6v1LieOF0hYW5GIvhoCamI3V0o4LgCRPhSRL2chprnmGqMnDrsq264MQCWB
 0v.lBNmyxgHhb8nQ8v0bNZSuuTi_Dd6t6SJE_HUqXvGLsPQ_Vqbrk1g6U3Q7A2NQOtMSV._6ukK0
 WhRsY326FGk56Epi_IyM0iuE5qjQ.E0q3hCewUhretDV.YCAkLZhUNTuBrmO2ruKfsQDVQiInVNZ
 LKLUqiHQWZ.qErKNmE6HkguQi1YwXMseeGeu.6qu__MBB8Iux93EU4GNwGFlwuGZIhgRuKvaWV.z
 Vl_pfUEGF957n9_yGgLVIoODueJIej8IV.WspGygn.AJJuEiarWBVtbm8BVwo7OEV41bm6CnfRo3
 IpmbafeGzWOdo0PNskx7Lnzcu6kI01NRHK6eS1iezFCbuJNYDRFloDey.GM1vDdm9APp41XhtLK2
 b1cNNwtZrbt9nIQ7sDH_IVYNodGIQHLNs_.PifD39uKcLHRZotMhrrjAUb9BD8KTTTTEKWtGXY5X
 ADJzUjb_aCYtCZm5vFjQgW4HxsVJb51I32mfFstzIgNtEyz0A
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: e23b1bdc-5454-427f-903c-24bde30c282a
Message-ID: <ef5995a3-10c3-40e3-95f6-3bd678aef4c4@aol.com>
Date: Thu, 20 Aug 2026 10:58:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
From: Chuck Zmudzinski <brchuckz@aol.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <682975cc-4857-42b2-badf-b638869f3268@aol.com>
 <7ab98288-0c5e-472d-87dd-5586e60027bb@aol.com>
 <f0ffe015-1bc5-4091-8dbe-2b4eee9cec2d@aol.com>
 <b05a3553-398d-4ed0-bbf1-6e93cf385fe2@suse.com>
 <0762fb50-01b5-4ae2-8587-7574020082b4@aol.com>
Content-Language: en-US
In-Reply-To: <0762fb50-01b5-4ae2-8587-7574020082b4@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 8247
X-purgate-ID: tlsNG-c1860d/1787237905-CDF4787B-A84B314A/0/0
X-purgate-type: clean
X-purgate-size: 8396

On 8/20/2026 9:03 AM, Chuck Zmudzinski wrote:
> On 8/20/2026 3:58 AM, Jan Beulich wrote:
>> On 19.08.2026 21:09, Chuck Zmudzinski wrote:
>>> On 8/19/2026 1:49 PM, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 11:47 AM, Chuck Zmudzinski wrote:
>>>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>>>> about avoiding the layering violation than anything else.
>>>>>>>
>>>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>>>
>>>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>>>> in hvmloader?
>>>>>>
>>>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>>>> restricted DM as well.
>>>>>>
>>>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>>>> treatment. Earlier on we also talked about the region not necessarily being
>>>>>> page-aligned. That poses, even with r/o exposure, the question of other
>>>>>> data on the same (leading / trailing) pages. This may imply that the
>>>>>> copying needs to be done strictly in Dom0, for both DM and guest to only
>>>>>> ever act on copies (which may then as well be r/w).
>>>>>
>>>>> Yes, I am thinking the DM should make a copy host OpRegion and never expose
>>>>> the host OpRegion to the guest but only a copy of it.
>>>>>
>>>>> The reason we need a patch like this is that with the introduction of the
>>>>> rvda/rvds fields into the OpRegion, the OpRegion is not always position-independent
>>>>> so its contents might be unsuitable in the guest address space, so in those cases
>>>>> we need to patch the copy of the OpRegion that will be exposed to the guest.
>>>>> If there is an extended VBT the DM will also get a copy of it, make a copy of
>>>>> it, and expose it to the guest by appending it contiguous with the OpRegion.
>>>>> Since in this scenario we are assuming the DM knows the contents of the OpRegion,
>>>>> then it can find the host VBT and make a copy of it without needing hvmloader
>>>>> to send the rvda and rvds values to it.
>>>>>
>>>>> Then, the remaining question is which component (DM or hvmloader) will patch it
>>>>> if it needs to be patched to make the guest's copy of it compatible with the guest
>>>>> address space.
>>>>
>>>> As I noted earlier, it think it would be advantageous for the Xen platform as whole
>>>> for the patching to be done in hvmloader. That way, support for extended VBT is
>>>> automatically added for all implementations of the DM, not just for Qemu. But the
>>>> downside is that for hvmloader to do the patching, it needs to know the host OpRegion
>>>> address, which one could argue it should not need to know. This is the only reason I
>>>> can think of to do the patching of the OpRegion in the DM instead of in hvmloader: to
>>>> avoid disclosing the host OpRegion address to the guest.
>>> 
>>> Correction: Actually, with this new scenario, we need not disclose any confidential
>>> host addresses to hvmloader if the DM removes such information from the copy of
>>> the OpRegion that it exposes to hvmloader. Then, all hvmloader needs to know to
>>> ensure the OpRegion is compatible with the guest's address space is the guest
>>> address of the OpRegion. It need not know either the host OpRegion address or the
>>> host VBT address.
>>> 
>>> So the guidance I need from you to do v3 of the patch is simply to answer these
>>> two questions.
>>> 
>>> 1. Should I write v3 of the patch not only assuming the DM will never expose the
>>> host OpRegion to hvmloader, but also assuming that the DM is responsible for
>>> patching the OpRegion to ensure it is compatible with guest address space?
>>> 
>>> Or
>>> 
>>> 2. Should I write v3 of the patch assuming that hvmloader is responsible for
>>> patching the OpRegion so it is compatible with the guest address space?
>> 
>> My tentative response is to use option 1, not the least because a mid to long term
>> plan is to see about removing hvmloader altogether. However, a more firm response
>> here depends on an answer to the question raised in
>> <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com> (sorry, the list archive hasn't
>> caught up yet).

Ah, I see this message is the one you sent me earlier today about this patch and now
the list archive has caught up so for those who might be reading this thread here
is the link:

https://lore.kernel.org/xen-devel/92022f85-9a53-4db8-b489-fc91c86b413c@suse.com/

Well, I did try to answer this question here:

https://lore.kernel.org/xen-devel/fa497825-c8f0-4caf-94f5-b37108e31952@aol.com/

My answer is based on the fact, as far as I understand it, the ASLS register
on the real hardware is not touched when the guest writes to it because in our
case the register is fully emulated and the guest can only access and write to or
read from the emulated virtual register, not the real register on the hardware.

Also, we have this code in Qemu (hw/xen/xen_pt_config_init.c):

static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
    /* Intel IGFX OpRegion reg */
    {
        .offset     = 0x0,
        .size       = 4,
        .init_val   = 0,
        .emu_mask   = 0xFFFFFFFF,
        .u.dw.read   = xen_pt_intel_opregion_read,
        .u.dw.write  = xen_pt_intel_opregion_write,
    },

Do you see that emu_mask setting of 0xFFFFFFFF? As I understand it, that means
that all 32 bits of the register are emulated, and none of the bits are passed
through to the real device.

Also, I can quote from the (admittedly outdated) spec for the OpRegion that is
available online [1] which says this about the ASLS register of the IGD PCI device
in section 5.1.2 of that document:

> This register is a software scratch register and is not used by hardware
> other than to hold the state software has set.

I think this means that even if the real hardware register on the device was exposed
to the guest and the guest wrote a different address to the register, it would
*not* "move" the host OpRegion anywhere because, as the spec says, the register is
not used by hardware but by software (the system BIOS software) to let the graphics
driver know where it can find the OpRegion. But the guest *cannot* access the real
ASLS register on the device in our implementation nor in my proposed implementation
in v2 of this patch or in any of the other ways to solve this problem that we
have discussed in this thread.

So I don't understand how the question you raise poses a serious problem.

But if you are not an expert on the PCI specification and how the PCI config space
registers can be programmed with emulated bits and passthrough bits, and if you
don't trust my understanding of it either, then I think we need to wait for
experts on the PCI specification to weigh in and answer your question before we
can move forward.

Chuck

[1] https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html

    To actually see the spec, click on the "OpRegion Specification" link in the page
    shown above and download the pdf file that link points to. It is still live, I
    checked it today.


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 15:09:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 15:09:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396672.1634421 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4OK-0002k2-Ku; Thu, 20 Aug 2026 15:09:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396672.1634421; Thu, 20 Aug 2026 15:09:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4OK-0002jv-I4; Thu, 20 Aug 2026 15:09:16 +0000
Received: by outflank-mailman (input) for mailman id 1396672;
 Thu, 20 Aug 2026 15:09:14 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wx4OI-0002jp-JI
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:09:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx4OH-004NgU-Rv
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:09:13 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a871891-8faa-0a2a0a5109dd-0a2a4502a652-20
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:09:13 +0200
Received: from [40.107.200.36]
 (helo=CH5PR02CU005.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a871898-6ca4-0a2a45020019-286bc824f783-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:09:13 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by MW4PR03MB6473.namprd03.prod.outlook.com (2603:10b6:303:120::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Thu, 20 Aug
 2026 15:09:08 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Thu, 20 Aug 2026
 15:09:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lN5GpbMLGHJFQPxQhgKEODHo3SDBhxfcFmdSmJ7X54aCPgalg6Y5UMQVsEZlon1rrVUaKmOFr7bAgXEGRldO4P70JwuaAV1knLo8ZD6gQRlGw7gSaVEGn+Lt+40t3xvkCl6WazlMYEi8bO5QC0+1iJtPuJo5wLFFfMJOgJba7krBrUgnYhAoQT5DY3heeHhdTdoKreT6bKU3oL/ZreJVOftbgoSPWodHJwWWTQt6/uFajaN/1zinXdoNDBuM5WPgfB4caEAMUpPgHfQ72jip8DdNWvegereN2WuWDHoiUoIUnFf76HolnumT+8vGuSSXjfSt3e4nDRMEFS/SjBFwOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZpvuoUaSYhmUHpOYB7wjRy7wb/MJXEAjKPYiufdKG9Q=;
 b=d/YSvznqn8sp7cAt8x/cKoYyNGyPFIoPTJquNyGHMPVD2K/EYJmaWCpdMBJDwJBrek4k1LBX4ravkM0kBiuWDgVsf9vJ2B169xKwzIeuRy2JTYgqX1FPxbSwl1iqZ0UrTPYdcztXqUhjigQKtGAp9B0WT0ttiDtj8qWOVmcbxyOwxnmMvXewYQfO14QZKoolQYzkRtjg433Wjpill8MvCMu5iSnQTi86uVjMxUl7FthINrzuxuI7719aofqBdx43chyUk5UmCzVQyCzmejED5NVpAsyEZI+r1uvkj+ld5zNE7WNTO8FBTWMZvdvnlwuhZKJrErFhcicXQ8BvYSeyIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZpvuoUaSYhmUHpOYB7wjRy7wb/MJXEAjKPYiufdKG9Q=;
 b=kqjLlylRJ9VEUqUV2Fhxskapjbfzx2htv8vrsjBaeICZTGMrET474aIROcJk2lly6B7NM1tqaZg8XIFA2JoHxDJOqWRH6WjvEnVmAESHUeWkyfNmPGqJp37bDGPYy2rznVA5a0x0aVCTSo/QOoQrr0fkcCEFteTHNeHZmC15DmU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <34000818-5bd8-4329-bd4c-e6f72843dd75@citrix.com>
Date: Thu, 20 Aug 2026 16:09:04 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich
 <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
To: Teddy Astie <teddy.astie@vates.tech>,
 Sergii Dmytruk <sergii.dmytruk@3mdeb.com>, xen-devel@lists.xenproject.org
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
 <1787230800.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3@vates.tech>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1787230800.8631fc262581453bbf619ec5b2062170.1a01f41ca51000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0679.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:351::12) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW4PR03MB6473:EE_
X-MS-Office365-Filtering-Correlation-Id: 4bfacaaa-3530-47df-8739-08defeccfb81
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|22082099003|4143699003|11063799006|18002099003|56012099006|6133799003|10067099003;
X-Microsoft-Antispam-Message-Info:
	vx9s3SpQGabWs8sdbDJG1ESwoxrGbJwDaPUKxi0e/q/meso4lFGWgYGD/xIJXq0UDXo3UEW2fhv6NtladoXng5Z6wVyToFTKa0xgdDF9A59lMp/4RDSn2r6Q4Ugn6EZD7L78nVLQCuuXiTIsnY/6LTN7H+fXZg6P6ZvfNy2YK61K0j1RZECLiJDCnOoHXy9dFQB/jNkP5VsV1btqE62bXctVJooyKxqMkRKOJutwUoQbrOky1PbWW9Om9rXI7pikdGdJ8fuWKqOueoP0lPuus89Wbctz2I9/JkkImbcR2Utnt5DKkaO9+JtNV6kJAM85HBynfDfB1EyWyL0rsWEbneYoM7CgMLURhrViPiJFYV8piPlJJWQMONn3yVTfIbcv5j8Of2HOlB/UQBLXsoBiXisXFkOysFMC6kg1itfkmO/7oiBINl3RxrOd3rUdKt8YVzrVd3a6YqGaIIqLGwufsW5u/qcSgXXZwPxU2B7Vl8CeCMhWBVKNhcwYoWsuasVHwks2ozvbczvf9bJF02Q8K7BL6V1zRzXaMyJ/ciBYtDentI9CFk7N9ZSCeOG8vyzbw4GK9qtQE9SFDq7Di2tB6B7Xg3YZJ3ybvXUHKBUOnqKk6zbnrfbwXJj5SjsPKGRUIriVHSn12qoUJ+H9Afi66d8s09J7t2wj85bH47vkYVE=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(22082099003)(4143699003)(11063799006)(18002099003)(56012099006)(6133799003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?eGpKM3k4aTNGQXdSWnQ5TmdRQjdYd3EzdUFBdFVGUFduTXNNeHlKVVk2Sk9p?=
 =?utf-8?B?c2RRd0xDUzFEWm91b0t4M05YSjhhZTF2cDhiUDVMbzd3eXZRZFRyeXp2Sk9L?=
 =?utf-8?B?ZCt4eU5idVExdk1OWWpKOVB4UzlwZ2ZBNE9WZlNkT1N5Sld4OWZ5blNNQmIz?=
 =?utf-8?B?alRQTFB6U29Jd3RmZHZNMjBWUzU4eGVWOHdlZTlpa1Y3N3g3Y0tpYS9qU0Yv?=
 =?utf-8?B?ZXFHV1d6ZzFCUVBRbnRyMi9aNlhDa2lwaGZmU3JGZlRON0hmWjE5L2wrUjhJ?=
 =?utf-8?B?RFhnYnk3S3RzOU5WbFk2QkxQUU9rZEM4eCtITEtSU0RUT0tSbmtlL0tmMlo2?=
 =?utf-8?B?UUlZcHZUKysxcCs4WWdhSzlOQ1JKYjJaUHhTcWxWTnk1NkxyUnl0RDBwdWpx?=
 =?utf-8?B?TUJlcEt1aHI5QXJ0UkVQdDRVdWl2WGtJWENBc0ZwWXRwWGdzNEJDdWlJekNh?=
 =?utf-8?B?MUNPK01EaFN4cE9jV1VpZ1FkRWFjOHRLQmROdytmYWlKNTkyeThRSWZPbTJC?=
 =?utf-8?B?bU8vcE9EcllXMytHcDNodDJ2dWZiNXZtSVVBdm5GMGVobWpaUHJvODViNTdM?=
 =?utf-8?B?blZJUGdmd3hxa1RNVC9Td2ZMbGdFQ0xqY0Y2bGM4Qkw1aWVYYitUWThDT2ZF?=
 =?utf-8?B?LytxQk5PSm9PTGFUUXE0OSt6aDNiTVZNeGJWZm03THUyQjJLcEkyNThoWUhM?=
 =?utf-8?B?RnpXTkxidG14UEpxdTZ1dDNkS1dTck8vcitudTIwblVrNUY2OGVOUFlrQ2Vh?=
 =?utf-8?B?ZEhMOEZHNTlFMDlPMTBBZFU4Vko2S3ZTSDh2VjJaZkJvbmhYeXhka1BUUzRX?=
 =?utf-8?B?L3BJdUJHS0Q5K3hOSmFLcVVEdnhZN3kwczF0Nm9yQkwrbHhJUmIwNVc5eVN0?=
 =?utf-8?B?RTUzWDIwSnlQYVJ4ZHkyVmNaVkxFZlMvRjBxc0FvUW91YzE2akdWNk85THh4?=
 =?utf-8?B?b096QTNSN0t2NnZkVUpGUElVaDEyTS8rRTk2VG1WT3JMaS84N3dLaFVzcTRa?=
 =?utf-8?B?bSt3Y0ZodFN5S0NnUTFUS3Y0U202NkdEWkE1RnliTXRvbDBrOFVNMHNZVHlq?=
 =?utf-8?B?WFhVZEdJeDRreGpGdlZRNWlBcUlIdEdGNnZPNXVpa3ZCN2ltZ2lPMnFkWjZO?=
 =?utf-8?B?Snd5bkE5SlJCQkFSZFVXUkhJWm1POTU0MHYvMFltUXE5K2YxWWc4Rzc5ZUlV?=
 =?utf-8?B?NThMbnR2dTNjL1RqdXBqV0NTN2JlZThqKytBaXBuSWpQTnJYeXFvZFJ4N0Rh?=
 =?utf-8?B?RWhPaU1rRjR2WDJhZHpaZHNibEQwYk8reXZucEtaM1hDT2RWRHN1L3ZiQzdz?=
 =?utf-8?B?UmtXYldwbEgrNFRuMU9qWnJoS3dON3JZL05yTTJvajFHMm1adWZNZ2luN3lo?=
 =?utf-8?B?cVZuV3UxYWVUdXB0Wm5NaXJXU0d0WWM5RmRHOEgxMy9UcFF6YzRYdUNBNTAr?=
 =?utf-8?B?bFdKMUFSVFIrZXZlZDMrYTVRd2tiaXFBOXhjcUhheXFJaEh1R2E2VzUwSFpa?=
 =?utf-8?B?VjkzR01tSWtxSXdpcDl2YVg2TkdPSlNPUGdRVVpxbXhETTVuekZGV0ozNmNX?=
 =?utf-8?B?Qlk2S0NoQWw4R3ZTSXNBZEp5ZVoxRjZJWmVIQ0FzaEVlUE9BcWRGdE43a1Yz?=
 =?utf-8?B?OXFQalU0OXhuVHlrbGNDN0FTM1VSMGNqWk5vT29OZkwyaXlyK21lWGxXR0Mz?=
 =?utf-8?B?VnlMY0V6SHlIMzNBUVc3UHlyZk1SZHhXVzg4NFZmQlNRY2tVUjI5MXE2eDJu?=
 =?utf-8?B?Q2U2TXhVNFB5N0lUbU1tQm1uMGZWemRPS1dhUGF4eStzMEZnY2srNDc0L1I0?=
 =?utf-8?B?dnhQTnNGUmZvR2hmb1FUWXEvT2hadm9RWTc4T3BxY3BOSlkwQXZVa21yWVpo?=
 =?utf-8?B?MFdCaytnanY5N2pySm5sMFp0ZmJQNUQxZzViZlNadkhZMXFBS0wvc01xYWJM?=
 =?utf-8?B?SzMyeGM3THUxUXNNQXh2UlA5UWgrQTl0dndMYkpBaldrODVmbzl0Um9pSHZa?=
 =?utf-8?B?Qjd1b0d3VEJPN3VGMUNtU3NiNy9VSGJ3ZnRjdkhCSXkxNDA3RkFjaVl0QXZm?=
 =?utf-8?B?V2hHWlRnWlFFazh2SG9OQlFSb3R2czNuN2xFOVFiemtnUlV1Q1A2c05UaFA3?=
 =?utf-8?B?N3lkWHZ3NVVHNkc1VFE1dUVwRkE3emV0czRrUGJNMldqNWRJUXdZWFNvbGdx?=
 =?utf-8?B?VXJrMkl2VjgzT0sva1VITVB1TU9VU0ppVDlqNHRYRWt2R2tCcGxkVXF3ZDB4?=
 =?utf-8?B?VEpGL2lrWFkrTUdCNmdnK3l1V2ozYUVtTEVZL3RGNTZ3WWo4cEkzV2hFcjE5?=
 =?utf-8?B?cXFRTzNIZGtndFVlMW5QN011ckVoaWl0VEdZQ2QycVY2b3lqd3ExQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bfacaaa-3530-47df-8739-08defeccfb81
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2026 15:09:08.1409
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 18iKpKyowI/JQsbaGhFIH8MvPbTaDuB96hh+vAWja7R1NlODy0Kdyb9CNNmGXvx3COxIcwpJNSB1axfI3zMYeEyYMKdMvoEjtEqyj8V7Y7g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6473
X-purgate-ID: tlsNG-720697/1787238553-309C32AC-5AD203F2/0/0
X-purgate-type: clean
X-purgate-size: 2558

On 20/08/2026 1:59 pm, Teddy Astie wrote:
> Le 02/08/2026 à 15:14, Sergii Dmytruk a écrit :
>> From: Michał Żygowski <michal.zygowski@3mdeb.com>
>>
>> Report TXT capabilities so that dom0 can query the Intel TXT or AMD
>> SKINIT support information using xl dmesg.
>>
>> Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
>> Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
>> ---
>>
>> Notes:
>>      v4: fixed conditions for not reporting capabilities (match
>> correct comments)
>>      v4: define GETSEC_* macros used only by xen/arch/x86/cpu/intel.c
>> in the file itself (to not depend on Slaunch)
>>      v4: don't postpone restoring state of X86_CR4_SMXE, do it before
>> printing test results
>>
>>   xen/arch/x86/cpu/amd.c   | 16 +++++++++++++
>>   xen/arch/x86/cpu/cpu.h   |  1 +
>>   xen/arch/x86/cpu/hygon.c |  1 +
>>   xen/arch/x86/cpu/intel.c | 50 ++++++++++++++++++++++++++++++++++++++++
>>   4 files changed, 68 insertions(+)
>>
>> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
>> index 70783c9a0a..5ea16ad8a8 100644
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -617,6 +617,21 @@ void amd_process_freq(const struct cpuinfo_x86 *c,
>>           *low_mhz = amd_parse_freq(c->family, lo);
>>   }
>>   +void amd_log_skinit(const struct cpuinfo_x86 *c)
>> +{
>> +    /*
>> +     * Run only on BSP and not during resume to report the
>> capability only once.
>> +     */
>> +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
>> +        return;
>> +
>> +    printk("CPU: SKINIT capability ");
>> +    if ( !test_bit(X86_FEATURE_SKINIT, &boot_cpu_data.x86_capability) )
>> +        printk("not supported\n");
>> +    else
>> +        printk("supported\n");
>> +}
>> +
>>   void cf_check early_init_amd(struct cpuinfo_x86 *c)
>>   {
>>       if (c == &boot_cpu_data)
>> @@ -1325,6 +1340,7 @@ static void cf_check init_amd(struct
>> cpuinfo_x86 *c)
>>           setup_force_cpu_cap(X86_FEATURE_XEN_REP_MOVSB);
>>         amd_log_freq(c);
>> +    amd_log_skinit(c);
>>   }
>
> On which Xen branch this patch is based ?
>
> early_init_amd() doesn't seem to have amd_log_freq (which is in
> init_amd instead).

See the cover letter:

base-commit: 7c77acd452fb6a3079661e75ebb5cf23ed985cc7

$ git describe 7c77acd452fb6a3079661e75ebb5cf23ed985cc7
4.23-dev-119-g7c77acd452fb

so it's something recent.


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 15:17:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 15:17:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396691.1634431 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4WV-0004X5-Du; Thu, 20 Aug 2026 15:17:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396691.1634431; Thu, 20 Aug 2026 15:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4WV-0004Wy-9o; Thu, 20 Aug 2026 15:17:43 +0000
Received: by outflank-mailman (input) for mailman id 1396691;
 Thu, 20 Aug 2026 15:17:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wx4WT-0004Vf-E1
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:17:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx4WS-006MjR-Qp
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:17:40 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a871a92-e002-0a2a0a5209dd-0a2a4507e1ac-8
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:17:40 +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 <jbeulich@suse.com>)
 id 6a871a94-b4ea-0a2a45070019-d155802fc96a-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:17:40 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-493b966dd74so15931185e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 08:17:40 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499aa1755b2sm150805015e9.11.2026.08.20.08.17.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 08:17:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787239060; x=1787843860; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Rl5QcO73K5cmGbV3jP4c1s1CL404p5yxt0emdniJZis=;
        b=eCPos1He0Vl8OKd6r4cuK4zi7Chd45Y0X+G8T59TDk2jfkfJtjHxkoEH4+ibmV8HAf
         Ol0RHZx0ZXhiuLc+ij+S6xMVS2AX3T8YhWIQHo6j8x9evSE7HXdsPAfwQmXk6ov91DWY
         OEN571REklVhZ7PSCmNeHH/eRjUI2qDju7x0d/ppWu4FpG3T8T6OHmGD0Y6DuHakE4gG
         3owwtGYX0AUdfLEYd2sC+4NUY+Sa84vOq4q+RZ3yL80uGHZRMFjZWwYzIegyCRHKGvYK
         MfTIDsk5y6C/QfhmF+jLwprkU2sCTCkyAYpNE1PALkOmaXHFluBb3lj/digbaXS0O3n4
         TOLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787239060; x=1787843860;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Rl5QcO73K5cmGbV3jP4c1s1CL404p5yxt0emdniJZis=;
        b=VB4IMr8m9OO57L2UowaZNS1ZLhNiyxOi4uM8wwBbbdZb7TKt7CT+ZRN3hWdXFzcQ9v
         u3cZOvX5lWpUpFJiyA8KqU2wM1tB7zEW4tWr10cYpLIOWwTF9FT6zZvZ/ZBfA8egvpT1
         fRd6l+qIX861566pPNJ8IOa2SIh1nNDGxAy138vidPUH3EDYxQns+n6znAypJH8yDw5E
         XUbmtK/cl7HFcxiwayQHjk4sQqtIdd3rFxGbh8kqve9vTjIbOtst7Dis9Ch/DkQn1STy
         Ekmt6a5rWLjVe95P7mTDJx7v15BnSd4GRhJtnf1i8JT+qspoB4snDwppV5sl9AqfEvAR
         Uu0w==
X-Forwarded-Encrypted: i=1; AHgh+Rq1UZ0Ab/k1hb5yK21HDPeAm6z55mahsI74YhJWwCsmysTRO0yFfTJkZq8oAAJbvuDncPmR051U9WY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlE/dzGuNeW81udaCsyfTfOsg/Tv4CvM8W6eL5V2QTCWo0bOy0
	rEXlrZz4XpeJNbqHBR8ib93ekvzlG4TYd8apDCYrZ46wHaajocESAgwVB6/6q/4dNw==
X-Gm-Gg: AR+sD10nNNBUuWuqiApdI4DVXFhH39Ek31SC95NwVoQpC1qkrS+wqq1hfiUhkJ8vmq/
	EEPloTC1IdzpO2ht11P6Js3DpeC7OiNbrdEoDQROCz6CkkhX2ZmB9sgCZK2EXu0RvBV37rgqCIj
	Sc1Yd3O1lI/6OM5P7Q/L6rURRsqotsbn5YCyiTec5IZQPu/U3v4Rchif2MFaPcvEtv/Hjo9wpzm
	qW1UVw0ddih3/TnnSTaabiQ8aRxOm3ZaW0FaDfwnz0laZoiNQdYDQ490ncyRgI1qhZKWEFpJNj0
	Z8g0IndO5/wSCb8Yoamf5zqkrOJHR3GWSh30PecZLwLoIBy5re6wikFBRRsgXq52rFJyj25bMwr
	DEhE3UOMCChA5YzaH4s+MO2G5MLb6tdC0pvX+56TijHXWI4XoZ6jtZEpF4XY0XgP960NAordVwi
	uISoggQTXmkjLQK2XiBLwGRJ7aSfQzMgevjcZhXVHwjZZLbTd3HeHBe+F6ayR+Lov3ywV/txgJG
	xmQVSu5RpFLVxfAftOx7J+EVCeg/kqK1Rjn27l7uoSlZwozsLWU
X-Received: by 2002:a05:600c:1908:b0:499:5210:c537 with SMTP id 5b1f17b1804b1-499aa17d6d8mr215467635e9.1.1787239060097;
        Thu, 20 Aug 2026 08:17:40 -0700 (PDT)
Message-ID: <42521391-885c-4b96-96e9-5da2e4b5efa1@suse.com>
Date: Thu, 20 Aug 2026 17:17:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
 <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
 <fa497825-c8f0-4caf-94f5-b37108e31952@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fa497825-c8f0-4caf-94f5-b37108e31952@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787239060-A4AC8AE4-69D3739C/0/0
X-purgate-type: clean
X-purgate-size: 3099

On 20.08.2026 13:47, Chuck Zmudzinski wrote:
> On 8/20/2026 3:51 AM, Jan Beulich wrote:
>> On 19.08.2026 19:13, Chuck Zmudzinski wrote:
>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>> about avoiding the layering violation than anything else.
>>>>>
>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>
>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>> in hvmloader?
>>>>
>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>> restricted DM as well.
>>>>
>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>> treatment.
>>>
>>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>>> it functions more or less like a BAR region with the devices's ASLS register
>>> at offset 0xfc in the PCI device config space of the device acting like the
>>> BAR for that region.
>>
>> That is, on real hardware a write to that register moves the OpRegion? That
>> would need following by the DM then, i.e. the DM would need to indicate the
>> original position in the register, and the guest (incl hvmloader) would
>> then be free to relocate it.
> 
> Why would that "need following by the DM" when the register in the guest is
> fully emulated, [1] which means that when the guest (incl hvmloader) writes to the
> register, the register on the real hardware is not touched, nor is the OpRegion
> in the host address space moved?

You said it's BAR-like. If the guest writes to a BAR, the referenced MMIO
region moves accordingly.

> Here is how I understand how this works in the current implementation and how
> this should be done:

I'm sorry, but this is getting out of hand, at least as far as I'm concerned.
I've been trying to help, but even just reading your replies has already been
taking way more time than I would have wanted to spend here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 15:22:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 15:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396699.1634438 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4aq-00063O-SV; Thu, 20 Aug 2026 15:22:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396699.1634438; Thu, 20 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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wx4aq-00063H-Pf; Thu, 20 Aug 2026 15:22:12 +0000
Received: by outflank-mailman (input) for mailman id 1396699;
 Thu, 20 Aug 2026 15:22:11 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <lukas@wunner.de>) id 1wx4ap-00063B-K9
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:22:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx4ao-002VkU-JM
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:22:10 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <lukas@wunner.de>)
 id 6a871ba1-bab6-0a2a0a5309dd-0a2a4501b944-6
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:22:10 +0200
Received: from [144.76.133.104] (helo=mailout3.hostsharing.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <lukas@wunner.de>)
 id 6a871ba2-5984-0a2a45010019-904c8568d3f9-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:22:10 +0200
Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384
 client-signature ECDSA (secp384r1) client-digest SHA384)
 (Client CN "*.hostsharing.net",
 Issuer "GlobalSign GCC R6 AlphaSSL CA 2025" (verified OK))
 by mailout3.hostsharing.net (Postfix) with ESMTPS id E4884295A;
 Thu, 20 Aug 2026 17:22:09 +0200 (CEST)
Received: by h08.hostsharing.net (Postfix, from userid 100393)
 id B18B761024E6; Thu, 20 Aug 2026 17:22:09 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Date: Thu, 20 Aug 2026 17:22:09 +0200
From: Lukas Wunner <lukas@wunner.de>
To: Ruoyu Wang <ruoyuw560@gmail.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@novell.com>, xen-devel@lists.xenproject.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] xen/pcifront: Fix PCI device reference leak in AER
 handling
Message-ID: <aocboedc16afKkcR@wunner.de>
References: <20260820135603.3901798-1-ruoyuw560@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260820135603.3901798-1-ruoyuw560@gmail.com>
X-purgate-ID: tlsNG-d62444/1787239330-1F46D757-D36C5387/0/0
X-purgate-type: clean
X-purgate-size: 1098

On Thu, Aug 20, 2026 at 09:56:03PM +0800, Ruoyu Wang wrote:
> pci_get_domain_bus_and_slot() increments the reference count of the
> returned PCI device. pcifront_common_process() drops that reference only
> when the device or its driver is missing. All paths for a bound device
> either return directly after invoking an error recovery callback or fall
> through without calling pci_dev_put(). Consequently, each AER request for
> a bound device leaks a reference and can keep the device allocated after
> removal.
> 
> Declare the looked-up device with __free(pci_dev_put), so every return
> path releases the reference after callback dispatch. This keeps the
> device alive while its callback runs and balances the lookup without
> restructuring the callback returns.
> 
> This issue was found by a static analysis checker and confirmed by manual
> source review.
> 
> Fixes: 956a9202cd12 ("xen-pcifront: Xen PCI frontend driver.")
> Suggested-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>

Reviewed-by: Lukas Wunner <lukas@wunner.de>


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 15:49:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 15:49:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396724.1634449 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx50f-0000jm-VS; Thu, 20 Aug 2026 15:48:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396724.1634449; Thu, 20 Aug 2026 15:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx50f-0000jf-Ry; Thu, 20 Aug 2026 15:48:53 +0000
Received: by outflank-mailman (input) for mailman id 1396724;
 Thu, 20 Aug 2026 15:48:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wx50f-0000jZ-BZ
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:48:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx50e-002Zcu-7P
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:48:52 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8721e0-bab6-0a2a0a5309dd-0a2a450194bc-4
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:48:52 +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 <jbeulich@suse.com>)
 id 6a8721e3-5984-0a2a45010019-d1558034c0b7-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:48:52 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-4996f1ee4a4so21341325e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 08:48:52 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499b20a14c6sm56786445e9.0.2026.08.20.08.48.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 20 Aug 2026 08:48:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787240931; x=1787845731; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=iinPbohH6fqNl4HDjuYqaLgTG5kg0eT66Sa++6k7gCc=;
        b=Z8TskbFF+Nbtk+APFE9wA2V9GYQjbYMI5cKG5790q/vJlBJkrJFxJSnMUig84XSNEr
         oN+TrOEDo5PnMXNlELKLiNgvb9fE+tqaYYxsqOWuyZYRd4Dq9f03IRFuEoPYpNKpVMN4
         5NNXkJECZVzTQ2gBMTroVuRotrBtCAjmXEv4Ty2+kwMjv4G4eIeTn5PoWM1GYxgoOgO0
         5IhaIm0Ww4mXqvsglbAC+cfVuaGbAMOuU4cP7+vz8JrUvZIXrwF3YJJiZqb1I2IGeZRh
         MCu6RGl1dUutXtUHcNJ3xAk0RPuHjSI8zNGDdeGlKarRztB22jbaRLH8QMRQZ612GIh0
         eWhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787240931; x=1787845731;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=iinPbohH6fqNl4HDjuYqaLgTG5kg0eT66Sa++6k7gCc=;
        b=aW6ggWOefo+HdEDPmpdKa/FTEhxdd8UtoxFgWoKZ00n5QH5q1itf+suoVEuMhswnvt
         DW9Olk1w5CzmEB4qWkszRCQPyUeTQ6EtwU5NjbSC7wiMoHnScywveivZ5zVrU8UvjQpk
         N70ZHM0XeoTIxzeNEq+1T2UsFMSeW30VKbDWgnM8uiMzf4/onacqKacMNt81VyZTyueZ
         czZp5jMvMx0a0DMaI+LWoTEBNtHnJyGG5PvB49RI86Ev+1YfMHBXn8pkV+YLdS8WB9MX
         2hXdgBnjabox+JX3OwYO/BaKwSEts5pwjheDORXyQ4CBaxFT42JTCO6oA1Km9JzwR6Qs
         tO8g==
X-Forwarded-Encrypted: i=1; AHgh+RrCwmjtEK4ivBb0fsqjCxCJDJ5/6rGv73ePhzjP2KsYlk165rnWCyxrd+r84XLjAuBM0kp32gOACJg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzM5GB/vyDWCkWhZ7GTsOEag/5nSFvcNH6T+7IBq8jbGJh6C5WL
	0JaPooZ8orRgI0kVOoguajIRToPzlc1JU9EllW9yw1SCVl/iY9xJq+GLNjxNutcYrA==
X-Gm-Gg: AR+sD12f6ts1SwpiHILqgxmlF2W5JRlcm8yb4cq/IJd0egQEkdANKBY1NH703ZnAz28
	/mxnEa+8MtRNeqf4ps/8dOouhGEDW7yIFS446N1hQCXFoYD6Ycj6r1uVf4Z9QA43Qq0HrjPCQix
	NhkwmryNwH8zqsxs1UYaBUtjsFpKuIjuL1PsqZixIaA4d0yJZE6th8ENcNmdSviMOBMorktKkji
	pb/S4t4VbR6/c8XqN8Q2/riWhFo83mSOIvvw4Az2FvTrvFkxAtiAyYIZ2xU2CUIgwjqLMB/jnDL
	TmDSqs2mWve2pifiTqVVG7F7ZEubrN86xtpTDUNhEvslcC4DqAXfu0IAIgjsl6Ug9neJuwIY/pp
	yg76+ZJFYtLh7kFV6uDLL3anFQjJ6GOtvJmwzgiHpHGGSDIzOVH48c2F9pHhlQTMO+CIrBL586j
	H4nr/eM8EzkkP5HQSdoq+stFusgBLfZ35ybTaHg/EiRD4Yz+FDq6zsvGYdgGmxvUjYVo0ufcMgf
	qnDgpPZQnvz0MysMQoaVWI+vAk1Vu8MQlxI2Qal8Kd/oHJF2OaY
X-Received: by 2002:a05:600c:3f12:b0:499:7a4f:d13d with SMTP id 5b1f17b1804b1-499aa199777mr251546475e9.4.1787240931584;
        Thu, 20 Aug 2026 08:48:51 -0700 (PDT)
Message-ID: <b64ee197-3186-47ed-89b1-5cdeec1c0cff@suse.com>
Date: Thu, 20 Aug 2026 17:48:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
 <7489d730-6e91-4d6f-a355-4eaa62698c4c@suse.com> <aob9xUZF12IJhLRz@MjU3Nj>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <aob9xUZF12IJhLRz@MjU3Nj>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787240932-1E27A757-FF3C8412/0/0
X-purgate-type: clean
X-purgate-size: 4394

On 20.08.2026 15:14, Sergii Dmytruk wrote:
> On Tue, Aug 18, 2026 at 02:08:48PM +0200, Jan Beulich wrote:
>> On 02.08.2026 15:09, Sergii Dmytruk wrote:
>>> From: Michał Żygowski <michal.zygowski@3mdeb.com>
>>>
>>> Report TXT capabilities so that dom0 can query the Intel TXT or AMD
>>> SKINIT support information using xl dmesg.
>>
>> Hmm. I first meant to ask: In how far is this extra logging useful,
>> especially as long as we don't use the features just yet? And only then
>> I noticed that I must have paid too little attention here already in v3.
>> Querying through "xl dmesg" is entirely unreliable. Sooner or later the
>> boot messages will scroll off of the ring buffer. Making this a
>> query-able interface also would mean we can't alter any of the messages,
>> should the want/need arise.
>>
>> For AMD the situation is easy: It's part of the featureset / CPU policy
>> exposed via sysctl. The same is true for SMX on Intel, but the further
>> GETSEC output requires some other means to communicate. I wonder whether
>> making this part of the CPU policy would make sense, or whether to
>> introduce a Dom0-only hypervisor-CPUID bit for it, or whether yet
>> something else would be best here. Likely Andrew will have had thoughts
>> on this long before ...
> 
> I'm not aware of anything relying on this output.  It's just for making
> this information more accessible to users that may be wondering if DRTM
> has a chance of working (e.g., if hardware supports it and firmware is
> properly configured).  The wording may be unfortunate (and needs a fix
> anyway), I can change it to
> 
>     Report DRTM-related capabilities to enable checking for them in dom0
>     using `xl dmesg`.  This targets debug and diagnostic use cases.
> 
> if that helps.

Yes, please. Provided we need this separate output at all. Furthermore,
if we need it, wouldn't it better be adjacent with other extended VT-x /
SVM features?

>>> @@ -620,6 +625,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
>>>      }
>>>  }
>>>
>>> +/*
>>> + * Print out the SMX and TXT capabilties, so that dom0 can determine if the
>>> + * system is DRTM-capable.
>>> + */
>>> +static void intel_log_smx_txt(void)
>>> +{
>>> +    unsigned long cr4_val, getsec_caps;
>>> +
>>> +    /*
>>> +     * Run only on BSP and not during resume to report the capability only once.
>>> +     */
>>> +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
>>> +        return;
>>> +
>>> +    printk("CPU: SMX capability ");
>>> +    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
>>> +    {
>>> +        printk("not supported\n");
>>> +        return;
>>> +    }
>>> +    printk("supported\n");
>>> +
>>> +    /* Can't run GETSEC without VMX and SMX */
>>> +    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
>>> +        return;
>>> +
>>> +    cr4_val = read_cr4();
>>> +    if ( !(cr4_val & X86_CR4_SMXE) )
>>> +        write_cr4(cr4_val | X86_CR4_SMXE);
>>> +
>>> +    asm volatile ("getsec\n"
>>> +        : "=a" (getsec_caps)
>>> +        : "a" (GETSEC_CAPABILITIES), "b" (0) :);
>>
>> Nit (style): Bad indentation, missing blanks, unnecessary \n, and stray colon.
>> Overall:
>>
>>     asm volatile ( "getsec"
>>                    : "=a" (getsec_caps)
>>                    : "a" (GETSEC_CAPABILITIES), "b" (0) );
>>
>> I further question the need for volatile here. (Like for we have for CPUID, we
>> anyway may want to gain a getsec() wrapper for GETSEC.)
> 
> I think `volatile` was added just because it doesn't hurt, rather than
> because it's necessary, so it can be dropped.  Can add a wrapper, but
> there is only one use so far and a generic wrapper will have to use
> 64-bit parameters (`GETSEC[EXITAC]` sets RBX).

Well, if it'll remain just one use, maybe indeed too early for having a
wrapper.

>>> +    if ( !(cr4_val & X86_CR4_SMXE) )
>>> +        write_cr4(cr4_val & ~X86_CR4_SMXE);
>>
>> The clearing of SMXE here is pointless, as the if() already guarantees the bit
>> to be clear.
> 
> This statement restores the value stored in `cr4_val` (see above).
> Maybe should name the variable `old_cr4_val` or `orig_cr4_val`.

Naming wasn't my point here. My point was that masking off a bit that's
already off is pretty clearly useless code.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 15:49:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 15:49:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396726.1634456 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx50r-0000yp-4g; Thu, 20 Aug 2026 15:49:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396726.1634456; Thu, 20 Aug 2026 15:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx50r-0000yg-1v; Thu, 20 Aug 2026 15:49:05 +0000
Received: by outflank-mailman (input) for mailman id 1396726;
 Thu, 20 Aug 2026 15:49:03 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wx50p-0000y6-Ks
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 15:49:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx50p-00Fmsb-1Q
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:49:03 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8721c7-e002-0a2a0a5209dd-0a2a45059354-48
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:49:02 +0200
Received: from [40.93.194.11]
 (helo=SN4PR0501CU005.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8721ed-4cb1-0a2a45050019-285dc20be5b3-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 17:49:02 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by SA0PR03MB5641.namprd03.prod.outlook.com (2603:10b6:806:b0::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Thu, 20 Aug
 2026 15:48:59 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.007; Thu, 20 Aug 2026
 15:48:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ja7vhr5fpibeqQGlBlMvm6M3XzIhLwV5BBF6fE4NtCg5PqNuOxyks3vrl8LfpoL80/nT+7VXg22hLkLK3qlUM0eBUcHvxUSW7FVCEfbT3ZAtJCHRUYcSlDrDsSMM/khQWG2HUuU8JMhBoMFWEpuOUunfPSVLVz3ExZAARhkfvItjeV0YwrGTIskNC2wM/u5mu3h87MKmPpHKIexG1xusdwY68Ic8uTrZKQHF/p6ndq161t9AnJWAr20XziFKXBc6KhQLXD7CqdNQ67wTtxGSwj44+gfHs4NnZfAhJBZ/00i5pO8X1mLl9/yryWaAQsDPnDQiuCbXXe4rnRx2CkjB5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZnefJuIRu0wkShkqU7DiAD46jww2B8UbsQLxsP1uhIg=;
 b=TSEdDm5z9Mzcpy6prFB0/yEpXX8xRFt5AbETnYKgM4Hr511JaGGQST9LSWsJb/KtijWg/yWTQLjB4n5431JeU6+SyTuTxhkvkOzp+jME8kbUQQ/KtytpaLxopoiavVeuIVF8QjEoYcVhsAppFQLqGLDhiSd6Zex68Cq7P95fOCIQ7S17UGnv/JuhZsJNpclBzxeLwmeEei2WvB3AzQtE2fZH4Ln8t78H4s4k2Z20mYCfkmrt7HF59fUY7oGnNL/rVzJYARurAtLzeLJi2Qd7ggq0YAaJmgHTGOw1jWYSuEs+1QZ/E+cD57aakTmQW4ii4PxY4/qVd5C1LK57nT2+RA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZnefJuIRu0wkShkqU7DiAD46jww2B8UbsQLxsP1uhIg=;
 b=NY+HhPihdfTvrF20pp1TjyCTgIE6w1u6b9FqoWQHASFLFCuS5cRv3nyhjajaX4/Q1fjrsoCQP9oycmhMLbeLPK6RIhEQrOHlTGZmek6xOWUaKQBXEwNi89gdf37WufdA7FXFAbJQFz29Vknp9nrcZ02c/MrxRs+JWWSGkNy+se4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <fd51f8a9-b09b-4aaa-8aa9-13a65d0aaa5d@citrix.com>
Date: Thu, 20 Aug 2026 16:48:55 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, trenchboot-devel@googlegroups.com,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 02/23] x86/cpu: report SMX, TXT and SKINIT capabilities
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>, Jan Beulich <jbeulich@suse.com>
References: <cover.1785668458.git.sergii.dmytruk@3mdeb.com>
 <be993e757550b69a6f94f89476ba71131b434741.1785668458.git.sergii.dmytruk@3mdeb.com>
 <7489d730-6e91-4d6f-a355-4eaa62698c4c@suse.com> <aob9xUZF12IJhLRz@MjU3Nj>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <aob9xUZF12IJhLRz@MjU3Nj>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0545.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:319::13) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA0PR03MB5641:EE_
X-MS-Office365-Filtering-Correlation-Id: 61c97f37-83e1-4969-e620-08defed28ce0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|10067099003|56012099006|4143699003|6133799003|3023799007|22082099003|18002099003|11063799006|5023799004;
X-Microsoft-Antispam-Message-Info:
	4dHmmItxiJT4FsgpFe84jvEZzUtjOicIBmd2Zvoc2SQ+ZNo5/lQux5JiMytKFo5Wae/B36fQwWDKC0x7uK9CLPWU/duzm0sbePq9zlDmPI+bvX8vqmzPEsSVQkJufG+R/S5Bh4dJZnZ+SfIj6tFnpP8lfQcPY7Nr4O9ryJJjEgOMzfbQuiTGO3d/TnfRxWIO88Rvl4g7hVgZpEhJAn0v6wgDt+63l0d+1EaDc0200niryWlsV3xDlC+HBWHHzaKLGMh7dwfguYX0vaum+Unwbc0uqlfp+6+2NBJ8DJocadePTlaSuq+c1FH0cCBoH8CP9RmFHuoouqcb5eGHw5Dppgi4s8cdmZuEcoOHp5pYTLIOVOLUY81fWLtBVTt4spo6PbSdKqEo4p7XmvA3SPDOSXAJSneEVoDLWJit5JHS/ER9JEFzFnZbhRnGMUvqalHHJvjGcrLORSwykrnJzaJ7i0YN1dWcaIkH+2P2N/3mzlJ3Z7C6onbQoR7cYDUCbJugDnLhdRaA286FPli5elBIgCcGrTmOM5JwP18e/8EHQkkGc6/trYhTAhuqDeE16PmTgdeP3PrevFdINEy2KFw5b2kQ5N0lSbckqDhq7aj9b/JjnQzMa5+NHqBRTLhbhwsME0Ua5D3daoLn0DzeMFyW8IK6VLq6mM0jCl1gdiYnaCQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(10067099003)(56012099006)(4143699003)(6133799003)(3023799007)(22082099003)(18002099003)(11063799006)(5023799004);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MEo3bFplOGl1cEtUYTJCcjhzZFA4Rld2S3l0RnhmRG01aDBtQTJubnhrM1o2?=
 =?utf-8?B?Ujd1RE9qMDhvS0k5QXZXUk1XblhnRFRVVk8zVFBOWUYvWVprT0U3bVV1WHFs?=
 =?utf-8?B?aUhlSE9qcitRR0JyVnZ2bkExTW9Wd0d5TWdPTEIvZTI2OGpqK3lsREFFVFNL?=
 =?utf-8?B?eWF0NkN4eG1mQTRHMitXTlpvWlFKV20vY3JIenpTVjB2bmZ4MDllWjNwZTdK?=
 =?utf-8?B?MmZXbzE2UmZGSy9EdStVTmhQV3Zsa3U4ZjNSZlNkYzNRQ2cyUm1XMitGL2NR?=
 =?utf-8?B?VkE1a0ltTndpUDFFWDkwZTA4RWUxUW9iaGRXZit2eDh4aEdhVEU1Z0VZZlBr?=
 =?utf-8?B?RC9Ha2dzSGs4NVRlMWk3djcxcWV5bCtsanROSFBHVEh4T0J2Vmt3dHhHYjNW?=
 =?utf-8?B?WEtFQmR2dWp6NFhldlRvR0FLK1V3R0ZoUnQ2cmJTcUk2KzczSFZ4TkVPaVZV?=
 =?utf-8?B?WEMrekd2cTltKzBrbHg2VUpKdUxXbXdCeHp4TXFuRHNKbEVCVHhHc2hJUTI2?=
 =?utf-8?B?RDlQTDBsc0ZzU0JJa0trVTZqeGFpSmNZeGhsQkRXM0l2Z2dOVEVKUnU2R3Rs?=
 =?utf-8?B?emwxejJTUEowbTIxcmxhcHdFR1UrdkFTUE1pZStlOHF6dHF3L2ZkejByUUk5?=
 =?utf-8?B?MnlLSUR1YzhiNmljTlZWYWZLYWE4QWVqelk3SFZDNnJJTVUrZmEwNkpabldo?=
 =?utf-8?B?V0R5UFhNM3lLS1I0SVg1THkrYUFsU2lwdDc5R2xDYUZwWWtrSmtWLythRlV0?=
 =?utf-8?B?Y0EwVkkrSEV4d3NSVUpvTnZnUnl6OUJ6YnlCZ0JUSFVxK3lsa0dBay9ldC9C?=
 =?utf-8?B?czU0TkhyNExNYUlWNmpiSXgzT2tIbXZZbmVPcVRUWWU2VEpwdkkwRkphYm9H?=
 =?utf-8?B?NU5mMWdmMzQ4bjlpMXNVWGwvdURITzNQWmUvMjFlYzF6REN0WXhCY1BCT1NG?=
 =?utf-8?B?VWU4L1F1SFltVUFOdVBUYVhaYStwQ21seTFHMjV4R0Z1cmdtVlduUkxKN0Uz?=
 =?utf-8?B?bmhpM0pDRDZrVGgwczk1dXpyRFZWZy8zeHJLN3daNVFlbDd1MmRsTVVWL244?=
 =?utf-8?B?U1F1RURPQU85U2RvUXpyaU83OE5wTDVEeVV0V09tSUpaS1lxTFNZREkxUVBC?=
 =?utf-8?B?RUdWZmhlTFQ0UDA5TUxtd0xUZ3cvdVROc1FQQ2Njc2JDWlM3MHJHblIzNTVN?=
 =?utf-8?B?a2psdUpBVG5hNDBNZlRVQVM4VXFaTzdzRVpidFpWRldRRXovOXNYUFNTODVi?=
 =?utf-8?B?N3pSSS9UclBRQnk1amg1VFEyVVlRTklKM2FRRDlGQ2hPdWJoczliM0I3VWwr?=
 =?utf-8?B?dUVPNU9DOFJSZXpvVmJSVGpOK0NXUmtZelA1SlpBeldqekEwM2h4cDE5TGlP?=
 =?utf-8?B?NExsd0FsRWwwRU1zNlRSTlQrcHIza0ZRQm02azk5VENwY1JVREc2NFJyY2pW?=
 =?utf-8?B?cVRCTW1mekdqT3NPMEhCT2NhMzZHbHR0b0VNVWNnZmVtdWxLY2N2WVlNZ0lY?=
 =?utf-8?B?dnk4SmNTOFh3WFNmYS9LM3JReGg2YTRIYkRDVEFuNklhTGhPd0Z1cWVYdzZt?=
 =?utf-8?B?ZCtzUUpwSDc2S3A2TGJ2N0lZakkxb25qODhKZDR5VllUOEZqQ1F1VXQ2OHFR?=
 =?utf-8?B?WjJLTWtKZXAzb3luejlTbUQ1TkhkQTFnVjRVcDM5OXdYK1NkakxWMTdFMWk2?=
 =?utf-8?B?VjRPaDhTYzQxRUh6ZXY1YVNOeDVJUjlVaGIxOUo3VzBsTEdLUk05VkR3TS8w?=
 =?utf-8?B?eGFaVWxwM0QwWm5ZWXZTVUwwSjRiRHVFaGVHZkw0KzkrRGNvUVE4dXBRUWN2?=
 =?utf-8?B?QWxMRkJFYUZlK2x3RVBEbjVyTHp1U0lrd2YzakJyeDA0SWVSTjVWQk1wS05m?=
 =?utf-8?B?KzUyRmpoZWVCaExlL3lQa1VvQ3FHZ3pSZlEwa0lZVmg2QUs5dEtNNC9rbXp4?=
 =?utf-8?B?Tk5UdmtCU1h1c3hHNlAyT25yaURRZm5CcjUyRkV6M1V6KzBlM3cvRXIvMW9v?=
 =?utf-8?B?b0piZ0R4aFRKcFkxdWVVTDVaOTBjRUFlR0ZROEE3S2cwcmU3czN1a0thTFRj?=
 =?utf-8?B?bTlKSnR3Q0dlcjVDOTR5T29Xb09sYmN3NWJLUFJ2U1JNb25mUi9BVy9xbVpF?=
 =?utf-8?B?ZFBVOU11MWIxb3ZhVHFPalF4T2tEeDFnbG5BQzdkTWJ0ZVNXbENTd0JPOXQz?=
 =?utf-8?B?NWFnWVc3SWwxd3B3QWpJQlNleGV0WE5TOXJmWmNLOVN0NGZJazJndWVsb2k3?=
 =?utf-8?B?dTB5bzhtSUYzWTFFYjBVWVMvWENNL1pMbWYySHFYSlNTUnZxV0F2a1NNQ0Vh?=
 =?utf-8?B?cy9ueVdmb1ZDS0syRFRWQ0kyMC90dmlCbDFBUUNtMVVvOWppa01BUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61c97f37-83e1-4969-e620-08defed28ce0
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2026 15:48:59.4232
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: DziTmE5b4hlYcYmeXgr3O0VNoKbcmNMGwWtH7LixpCyYX9C5o+bzTFYVC+HHv9IfFtAzfkZs8YozAZsQ4RDb3/sBmnXSzYVQYYQLdjTCzTo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5641
X-purgate-ID: tlsNG-c201ff/1787240942-2491C2A1-69471347/0/0
X-purgate-type: clean
X-purgate-size: 2733

On 20/08/2026 2:14 pm, Sergii Dmytruk wrote:
> On Tue, Aug 18, 2026 at 02:08:48PM +0200, Jan Beulich wrote:
>> On 02.08.2026 15:09, Sergii Dmytruk wrote:
>>> @@ -620,6 +625,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c)
>>>      }
>>>  }
>>>
>>> +/*
>>> + * Print out the SMX and TXT capabilties, so that dom0 can determine if the
>>> + * system is DRTM-capable.
>>> + */
>>> +static void intel_log_smx_txt(void)
>>> +{
>>> +    unsigned long cr4_val, getsec_caps;
>>> +
>>> +    /*
>>> +     * Run only on BSP and not during resume to report the capability only once.
>>> +     */
>>> +    if ( system_state == SYS_STATE_resume || smp_processor_id() )
>>> +        return;
>>> +
>>> +    printk("CPU: SMX capability ");
>>> +    if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) )
>>> +    {
>>> +        printk("not supported\n");
>>> +        return;
>>> +    }
>>> +    printk("supported\n");
>>> +
>>> +    /* Can't run GETSEC without VMX and SMX */
>>> +    if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) )
>>> +        return;
>>> +
>>> +    cr4_val = read_cr4();
>>> +    if ( !(cr4_val & X86_CR4_SMXE) )
>>> +        write_cr4(cr4_val | X86_CR4_SMXE);
>>> +
>>> +    asm volatile ("getsec\n"
>>> +        : "=a" (getsec_caps)
>>> +        : "a" (GETSEC_CAPABILITIES), "b" (0) :);
>> Nit (style): Bad indentation, missing blanks, unnecessary \n, and stray colon.
>> Overall:
>>
>>     asm volatile ( "getsec"
>>                    : "=a" (getsec_caps)
>>                    : "a" (GETSEC_CAPABILITIES), "b" (0) );
>>
>> I further question the need for volatile here. (Like for we have for CPUID, we
>> anyway may want to gain a getsec() wrapper for GETSEC.)
> I think `volatile` was added just because it doesn't hurt, rather than
> because it's necessary, so it can be dropped.  Can add a wrapper, but
> there is only one use so far and a generic wrapper will have to use
> 64-bit parameters (`GETSEC[EXITAC]` sets RBX).

GETSEC is a horrible instruction.  The different functions (eax input)
produce and consume different registers,

This in turn requires different volatilities.  GETSEC[CAPABILITIES] and
GETSEC[PARAMETERS] should be non-volatile (they're read-only operation
without interesting side effects which the optimiser can safely discard)
whereas GETSEC[ENTERACCS] or GETSEC[SENTER] are really "jump into new
processor mode".  They're both longjmp-like so are considered volatile
by virtue of having no outputs.

I was going to request a getsec.h header to abstract these away.  Having
more than one location where we need to carefully check the asm
constraints against the SDM is too many.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 16:54:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 16:54:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396795.1634465 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx61c-00027b-It; Thu, 20 Aug 2026 16:53:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396795.1634465; Thu, 20 Aug 2026 16:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx61c-00027U-GE; Thu, 20 Aug 2026 16:53:56 +0000
Received: by outflank-mailman (input) for mailman id 1396795;
 Thu, 20 Aug 2026 16:53:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wx61b-00027N-4r
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 16:53:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx61a-009VT8-Hl
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 18:53:54 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a87311e-2eae-0a2a0a5409dd-0a2a4506e01a-48
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 18:53:53 +0200
Received: from [98.137.68.83] (helo=sonic306-20.consmr.mail.gq1.yahoo.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a87311f-195a-0a2a45060019-62894453b38f-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 18:53:53 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Aug 2026 16:53:51 +0000
Received: by hermes--production-ne1-6dbcb84f44-zgjzx (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 0e1f3b90d557886b25a60727f48865c3; 
 Thu, 20 Aug 2026 16:53:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787244831; bh=/yV4R5NzJGPzKwxTljvmVXReS9/rwKyLShBsLglW/rs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=Cx2zSdmcK3MChGRdKASNki1ezPweR2xOnmlyMXFVhbX0plAJUG87GrvSqOEGEfXa3CsUxwzXjzPaXP8DanH08u92M5Zejc5NhEXWQhG07oP1BxNFGMpMPYN+4PV5hvBaQNuiitzYKL3v2f4rpOmcm5lcN2FtPVF9Fu+cYKkMhQ+8iRBb3TTU3njkNAnYf51u8JI1/l/J94gXIT0n4OrIO17V3jjqjq0UnGdycFEWHeoGzhqVKSTIqNfkOyte72I3A9AGPPWRA5kwZP1BMYOlbjqwNCAiZPTNijYeLfQxiBjFMG6L8P2o35UWZXs0psfVBAfsqDTK9i16X3IQnLddHw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787244831; bh=CE2JA2Sclqf9mkH9no660+GL2stY3IEaJeUjOtGsGJy=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=VNVtLCU7r3dVtH1GLSsgeucHqjtYYqrprgXOFvcScPQ5DVDfZ6A6aFd2GbeeMiRvpkXEPBnUWo6M2j4mP7WaLRw0blUpzL1D0PL7AuJ7TxE1uf43sEZl0oWhYzrafTY/YEh2BWVZs8ZF/INStc7OQpECmaNkOWISn8Weq+IYtsPxVXeaYLoRkXoBIWKK+5eCJtTvfsIZzQcXWhfX44RXr33zOQvh0Mty8JFurPrOS7GSriTWd2Lm0leVuButqkMYRRZk6WPPoa54b7vBWBR+AV3Z6XFCjXAwUZV8ESVtmqlqKtPSITkwmSo6mevCR5raqVDghtYmL7IRoJ8VNBYLoQ==
X-YMail-OSG: k13RWPQVM1nofh4wzMQKD2h6h7VfI.0eJE92YP.9a6hPYZG5nHx7N6xXjaPMX5Q
 rIGK5WO31wGLAQe2WRy6QQtHHEFvj9pNriILh7SkQAMCgkzKGgspxEYhbMIwmZ62nRO.vq8ZHMXY
 LJqHTojYZItq.E9k24SiPpLMpMQxhA1n3p0n.WKCrDD7AP_V3p69t2RGjk9i01iB8MZj9lfs1JQF
 ye0Hx_8vb8FWPhdlpmxHa3hF8hVPtuZ426M967pG2fYnNfBP9A5Y4.ngpsbwYJLspw7h8Z3Sfxgn
 HOqfOTQqt8fmgQuNmWitOPaFb_He9THaonZ9MWxbQGU8WL6ObkexMIjMsc2o9dkXNzD4yRRjFHJZ
 xNewFtmm3s2AXPVRi4qNQo6Re..8A.7Q4TY1sg6zhzV1VEvWsQFSFktB0O.sBE3EmmPwnsAmq3kg
 AneFvaHaYxJ3l6g6B.bQnYCYMxLNQ1PCQ9XYM4XK3jsVO7Ehb9x8yZtvGeByd1ScvnBPw.EyuSVA
 hk_MOa7z0E6MbR3Ic3Qn4F1szKoSNwsJ5ow.vsdMS_CWXjdnHJgnGyKx.zb97Uq7Gw64F33Gaa0c
 UHxw_FWRYjXrSyA.9NO6VIKfvCDk7rjPp_XSLsO4zVm7A0JkUlXXq70CTvlk3ltGmHcLupfDhcz5
 dSKaaPbh28b9Vzafjj10aMiVDq40ZuhO18_SalrwBxVMGjhjmKGeFgOAy0ydt1wAEsYqwg7pn9Mx
 rKhoAPCxQVBhvj3Z8WjAPsaTOoXFuWVxXAwPuTyp7WKSJ81bnEpJnEsfavDj1UiWJrAFJQUezqhe
 7Nl86Fyz2vm6gxFqS2NTwuzQoQIxtOvuQB4x0rx92FucGjDO1M_gWuW4TGSxgpLD6NYRY_VYfUIk
 U5VPwint5K4ch4SbApRW4PaF223dyTSAV0oupYPlU.RyVMwd8Q7MCt_Txkue585iTsgeP23tJt74
 qPycLfZ53k0JIqp76F_AO1zUughMz_KIvbLRvZPgvax_Zd7YnNnxsWuCdyMQD_vyeCrD6LFGRTFd
 5ceJjgwfAmehfloEcvDZGLZ7bqyCKf3coRkLSvhsmAoUaS2nGJtAycAbjssVGaqrVFaUmF8Ok_ln
 LpNA6xliW42FP479dZYnm8YyiQ5WaMv2QdYiuUzkU7x2JEKok0s8opSn7C.X_.UbJP6L3brh5P1q
 7w8m5VX0F6DfuYeEDEbzIFOdWbW_IPgF00XsjeUMyfrzFB8LT6ehhp59bR3Xn2iKnZWaCKpcltB9
 5bR_PiA_whlKU4IZJxwW.KyNDSbaKh9QOXEyrfhI.r9mp.x.tV0s6ujopnwnE1Z.H1X2_NWMhAiF
 lYvsDxdxNGRdRy6h8s_oBQLAQ60CxudXPs7rH1ofU7WyuqAajemOoP1W9Y_a3SIqrA4U2chGXF73
 Dk4rOuDFP8MS_llz9LJgus8oXcauzNgYI7_R1hDuNk5pVnIP9NPMSkcNhUtZ0JzeUw3Sv8OnLulG
 bUo7R.vh_6dcamdAkgBUSqTZoFpCHyy_bbPM3hIuRM9U5SM_WN00RfDY4TVERkAt3q3AydWMFhyN
 1vgZ8wC.4TTmVxlR2pzDPu1Vsij91Oe8H4eyXbGnHgLIhtVhguQ75ocnyXHhEhrPBLBZBTRMcHnb
 L8DDJD3eiX6Ukepk8IUlZSEJVA0B44ux64eL9HEe4ARjlnKvhFK30NkovxHKKdAcLSLbDeP1_GXx
 .9F4BoO9UwEijCv6qfkzplb3Enbq9r80XwirEvkvZuI5tL9JiMTojBE_FmdGTTcujQQoSLiPEhPp
 yhCQ3TqhqtJp5D1CXpXo0CgczLgXcl9yarCGEIxaZWFGMXTrr1TVssRdVGvUSoDDoLXvEOR.Sqgs
 PO_b2fj1HG.lvhiOP.6lM0MPnfXUKmsB6GnX2TXITgzsAkJ9hQRuIJSqbPLXmlwptIv25SJfLqql
 L4XRpf1ZgDZDzTuCDRJX6Jwe1LQJj0Dxd2d7TJtov.EjvQF46I5PYd2ZTT9tv4GujeVqaCRz879n
 qlFqkoqODnkv7FAV7A8azFOlxJQVZr0i.feGOaSYx8BI2MsBD7BslQVbLRM5oyiBfeN.LSVPz5Wi
 hMD6.goD0NbWUYmUcJT2KVpopBNzzfbysHoETZDyJbn8l9tYl5G5e9c1nPnpgbZmKaZ25PF_8fqR
 AcD.B_TwM8E9j.4u8Y5QexDyF6hzyOBg6peg_0aDBpLtUXh6nlysACV4uDImz207WGLT6EmJDEAk
 BFkkv2ldbJ2bCbVfzdCUHqWtLzwH_8O.E1EOLdEkqVpXWRw--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: e1a62dcc-4c51-4a7c-b09c-19a8a2cc0f22
Message-ID: <e86404e8-9966-44ab-86d1-4bd01a551313@aol.com>
Date: Thu, 20 Aug 2026 12:53:47 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <da2200cd-def7-4cce-a6c2-9f9ac9e202ce@suse.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
 <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
 <fa497825-c8f0-4caf-94f5-b37108e31952@aol.com>
 <42521391-885c-4b96-96e9-5da2e4b5efa1@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <42521391-885c-4b96-96e9-5da2e4b5efa1@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 3753
X-purgate-ID: tlsNG-16d1c6/1787244833-FDA0C77B-4F11ADAD/0/0
X-purgate-type: clean
X-purgate-size: 3825

On 8/20/2026 11:17 AM, Jan Beulich wrote:
> On 20.08.2026 13:47, Chuck Zmudzinski wrote:
>> On 8/20/2026 3:51 AM, Jan Beulich wrote:
>>> On 19.08.2026 19:13, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>>> about avoiding the layering violation than anything else.
>>>>>>
>>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>>
>>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>>> in hvmloader?
>>>>>
>>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>>> restricted DM as well.
>>>>>
>>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>>> treatment.
>>>>
>>>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>>>> it functions more or less like a BAR region with the devices's ASLS register
>>>> at offset 0xfc in the PCI device config space of the device acting like the
>>>> BAR for that region.
>>>
>>> That is, on real hardware a write to that register moves the OpRegion? That
>>> would need following by the DM then, i.e. the DM would need to indicate the
>>> original position in the register, and the guest (incl hvmloader) would
>>> then be free to relocate it.
>> 
>> Why would that "need following by the DM" when the register in the guest is
>> fully emulated, [1] which means that when the guest (incl hvmloader) writes to the
>> register, the register on the real hardware is not touched, nor is the OpRegion
>> in the host address space moved?
> 
> You said it's BAR-like. If the guest writes to a BAR, the referenced MMIO
> region moves accordingly.

It's BAR-like, but it is not actually a BAR (and the OpRegion is not exactly
an MMIO region either (it is actually and ACPI thing), so that is not relevant
to this patch.

Also, it is fully emulated so when the guest writes to it, the real register on the
real device is not touched, as I have said multiple times in my responses to your
question.

> 
>> Here is how I understand how this works in the current implementation and how
>> this should be done:
> 
> I'm sorry, but this is getting out of hand, at least as far as I'm concerned.
> I've been trying to help, but even just reading your replies has already been
> taking way more time than I would have wanted to spend here.
> 

Fair enough. Thank you for the time you have spent on this patch, and also thank
you for clearly stating that you don't want to spend any more time on it. So
I consider this patch dead unless and until another maintainer shows some interest
in it.

Chuck


From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:26:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:26:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396831.1634476 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6XO-0006aL-Vp; Thu, 20 Aug 2026 17:26:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396831.1634476; Thu, 20 Aug 2026 17:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6XO-0006aE-Ra; Thu, 20 Aug 2026 17:26:46 +0000
Received: by outflank-mailman (input) for mailman id 1396831;
 Thu, 20 Aug 2026 17:26:45 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1wx6XN-0006a8-0q
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:26:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wx6XM-00DOP2-E4
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 19:26:44 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a8738be-8faa-0a2a0a5109dd-0a2a450a9f1a-16
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 19:26:44 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a8738d4-f2d2-0a2a450a0019-d155dd2cec96-3
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 19:26:44 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-476a130c138so198986f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 20 Aug 2026 10:26:44 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482b1450e54sm15723147f8f.11.2026.08.20.10.26.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 20 Aug 2026 10:26:43 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1787246804; x=1787851604; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wgLPlbFuKEHfiYq/TVIyUa+qi/9cDify939NcBfcSmk=;
        b=cS51ea0NEyiGgKKZu3uiJ+mccPhml18/9gitSgJFgVcoCqvjmr/i9OvpkLKZ4z9p2M
         vP+z2YwZcVIaFD+Qy1qDCtDG+ylq1/ZiLSUV+ysk/eVfV9aWkWBOUEheCd7XpRIlP13k
         5YcPBySymzGbtY5e86HlxjymM+F/5rQMaKGwA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787246804; x=1787851604;
        h=content-transfer-encoding:content-type:mime-version: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=wgLPlbFuKEHfiYq/TVIyUa+qi/9cDify939NcBfcSmk=;
        b=gl/t9cKAILA/zu3FKfdtmwG3+Q6I1razXc0dwXRscxAzh2f0rMr5mQfqo1uhSg/UaR
         XjkBj8ruG35usm5MWcIZ3j7TokszkuZvC12gy+BPzSf1aQx4pg24UNFtuV31M6itp+zU
         k2Zy9JPnuwHQae8U7CIag75OsTZMcxYqDk3Y/NjmJ4cfKwqF+BAsQVjxHr10Hn7BSrG0
         4bjclhcAY7I2DHr7clnOkKFeUxIOJFDwtvnZ8G97Btd+KRg7bsOT8sZedFg9kQN6UQg1
         0Fd+6OlyqGXD7Y5MV/yOatBZWBL5/h3JLtiEqTTjDqeEBI+ilS/E+LBy9hlmiUBlHiwp
         c/8Q==
X-Gm-Message-State: AFuF++k/sApqxnL5T22S9rZDzhcLFz8CFdXYpBZV7Qdi1wXTgaRwsXnq
	Kf8kG4cQLZ/FtvCraATwXp4WiB0ADlM8WCXh9Qw8gPj+7Fhuop7p4AGctYW222/fMvahmSQ9pme
	Zv/6RBwM=
X-Gm-Gg: AR+sD10+ySDNsyeobjqF8mtoRHImLn+fkbHUJL6uBDrMzv5vS4imBGDtIrT8cOP9Z1s
	QxcS8e0sZr3suWNWcTy5FSMLrfxk61mJLKPNl0fryqZ5GM+qHZOIpZX1s++ypt6nYcE9oCeeDs6
	twKggoEQ+8vEXvN0Vo6cjoj+h35boIb4AjLLKV9whh/CHGOfy/zKNHBJCTB8HcQQqyqd7R5Ve4M
	D/eKPJ2VbO+Td/6cWsgWsq1tBmeODb8eEgZX6lDC3ys1ccx1HcfQsOgYo6V8XCda4T/z1Vd1GY1
	6sfMxTqkqivyY9wAb2HtSI5Fgk7pUR7fPEPSjhMPL+yOvA54iknehKE4yAHUVXU5a9fc/XuGGmM
	qF0uY3qNROLkEledzQl1RzXl2Dd93SGfwhr1amv6K3P0U182r7kbuLMYUvF6Ghxl2yaULh5kVj+
	wsreb/S3CpzzDYDo6HBsl72AjKpkhu709hMPyN+owIPpX90qtYNC0pj1X99ZGUsI4rT28FHgJRt
	CWYzUOh8jL96iu3Huw6krlBlj8bN8+GfUphQrU=
X-Received: by 2002:a05:6000:1884:b0:47f:9557:8d77 with SMTP id ffacd0b85a97d-482c0b97893mr408001f8f.10.1787246803560;
        Thu, 20 Aug 2026 10:26:43 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH] x86/amd: Expand comment about NullSelectorClearsBase
Date: Thu, 20 Aug 2026 18:26:40 +0100
Message-Id: <20260820172640.2072049-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787246804-52ADCCFC-8F8EEF42/0/0
X-purgate-type: clean
X-purgate-size: 2497

Rework detect_zen2_null_seg_behaviour() to use the new MSR infrastructure.

Zen2 doesn't have WRMSRNS so don't bother relaxing the write.  All it will do
is insert a useless alternative.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger@xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>

Naming Zen2/3 in init_hygon() isn't ideal, but the early hygons really were
not far removed from the AMD microarchitectures.
---
 xen/arch/x86/cpu/amd.c   | 17 ++++++++---------
 xen/arch/x86/cpu/hygon.c |  5 ++++-
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 70783c9a0af0..ddd73f64c2d5 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -828,15 +828,11 @@ void amd_init_spectral_chicken(void)
 
 void __init detect_zen2_null_seg_behaviour(void)
 {
-	uint64_t base;
-
-	wrmsrl(MSR_FS_BASE, 1);
-	asm volatile ( "mov %0, %%fs" :: "r" (0) );
-	rdmsrl(MSR_FS_BASE, base);
-
-	if (base == 0)
-		setup_force_cpu_cap(X86_FEATURE_NSCB);
+    wrmsr(MSR_FS_BASE, 1);
+    asm volatile ( "mov %0, %%fs" :: "r" (0) );
 
+    if ( rdmsr(MSR_FS_BASE) == 0 )
+        setup_force_cpu_cap(X86_FEATURE_NSCB);
 }
 
 static void cf_check fam17_disable_c6(void *arg)
@@ -1110,7 +1106,10 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 	if (c->family == 0x17)
 		amd_init_spectral_chicken();
 
-	/* Probe for NSCB on Zen2 CPUs when not virtualised */
+	/*
+	 * Zen3 and later enumerate NullSelectorClearsBase.  Zen2 has this
+	 * behaviour but doesn't enumerate it.  Probe when not virtualised.
+	 */
 	if (!cpu_has_hypervisor && !cpu_has_nscb && c == &boot_cpu_data &&
 	    c->family == 0x17)
 		detect_zen2_null_seg_behaviour();
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
index 7a9fc25d3157..ef19c2b36783 100644
--- a/xen/arch/x86/cpu/hygon.c
+++ b/xen/arch/x86/cpu/hygon.c
@@ -39,7 +39,10 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c)
 
 	amd_init_ssbd(c);
 
-	/* Probe for NSCB on Zen2 CPUs when not virtualised */
+	/*
+	 * Zen3 and later enumerate NullSelectorClearsBase.  Zen2 has this
+	 * behaviour but doesn't enumerate it.  Probe when not virtualised.
+	 */
 	if (!cpu_has_hypervisor && !cpu_has_nscb && c == &boot_cpu_data &&
 	    c->family == 0x18)
 		detect_zen2_null_seg_behaviour();
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396845.1634485 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6o8-0000sc-AY; Thu, 20 Aug 2026 17:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396845.1634485; Thu, 20 Aug 2026 17:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6o8-0000sV-6d; Thu, 20 Aug 2026 17:44:04 +0000
Received: by outflank-mailman (input) for mailman id 1396845;
 Thu, 20 Aug 2026 17:44:02 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6o6-0000sJ-9t
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:02 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o5-00E233-18;
 Thu, 20 Aug 2026 17:44:01 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o4-00DjFg-2C;
 Thu, 20 Aug 2026 17:44:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:Message-ID:Date:Subject:Cc:To:From;
	bh=4gjc2syBetsa8lvBC5l7yduRaUYNpizoHytXTmGrQPQ=; b=wrE2mtrh3bah6n6aqKG58FbOKo
	iEV0XRuOMYLuXpaePRAEDwBmk6k76Z5KgMMbz8i62ba6DibQRZOivb0MpvDvrhFDiEUJ7LdqAVWri
	Rh8M8zpxyOu87v1wJQZLUdUfbCO5oYL669ezFU3Udcedj2mmi7qF4D+bu2zLDx/wBhCY=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area mapping rework
Date: Thu, 20 Aug 2026 18:43:40 +0100
Message-ID: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is the first batch of patches continuing the x86 Address Space
Isolation (ASI) work that Roger posted as "x86: adventures in Address
Space Isolation" (v1 [1], v2 [2]).  I've taken over finishing it up
and getting it upstream.

Rather than re-posting the whole stack (nearly 60 patches) each time,
I'd like to run this as a rolling series: post a reviewable slice from
the front, drop patches as they are committed, and append the next
ones as they mature.  Each batch should stand on its own; the cover
letter of each will say where it sits in the larger picture.

A "map" of the entire series -- grouped into logical chunks, with the
dependencies between patches -- is maintained here:

https://xenbits.xenproject.org/people/gdunlap/asi-series-deps.html

Note that the graph above is a work in progress; dependency lines may
change as more of the series is vetted.  Note also that the full
series includes a design doc as patch 1; that's not ready for
publication yet, so patches 1-7 of this series correspond to nodes 2-8
of the graph.

The problem this slice addresses: the per-domain area already has
central machinery for building its page-tables and for managing the
backing pages it owns itself (create_perdomain_mapping() and friends);
what it lacks is a way to install a caller's own pages at a chosen
address.  The PV GDT and LDT code fills that gap privately, by having
create_perdomain_mapping() hand back aliases of the L1 tables it
builds and stashing them in d->arch.pv.gdt_ldt_l1tab; mapping updates
are then written through the stash, bypassing the interface.  That
arrangement assumes a single, domain-wide set of per-domain
page-tables, which stops holding once the per-domain area becomes
per-vCPU (the next slices).

This slice closes the gap centrally:

 - Patch 1 moves the per-domain page-table allocations from the
   domheap to the xenheap.  The page-tables (not the data pages they
   map) are then reachable through their always-mapped alias from any
   context, so walking them needs no mapcache -- including from the
   context switch.
 - Patch 2 introduces populate_perdomain_mapping() on top: a single
   writer for the per-domain area, installing caller-owned pages at a
   chosen address by walking the always-mapped page-tables.
 - Patches 3-5 convert the Xen-GDT slot, the guest GDT, and the guest
   LDT paths to it.
 - Patch 6 removes the stash.  Patch 7 simplifies
   create_perdomain_mapping(), whose L1-capture mode existed only to
   build the stash.

One point reviewers may want to look at specifically: patch 1 changes
where the per-domain page-tables are allocated from, and its commit
message discusses the (minor) NUMA-placement consequence.

Relative to v2: patch 1 is new -- v2 kept the page-tables in the
domheap and walked them through map_domain_page(), with a linear-map
fast path for the currently-running vCPU; making the page-tables
always-mapped lets one plain walk serve every caller and context, and
the context switch keeps its existing structure.  The populate patch
is split from its first user; the LDT demand-map now goes through
populate_perdomain_mapping() rather than writing linear entries;
pv_destroy_gdt() keeps mapping torn-down slots read-only to the zero
page (in v2 they became empty -- a guest-visible partial revert of
cf6d39f819); and the domain -> vCPU parameter switches move to the
next slice.  Per-patch changes are noted below each patch's "---".

Testing:
 - Each patch builds (x86_64, CONFIG_DEBUG=y); tier-1 qemu boot at
   the tip.
 - The series passes the Xen GitLab CI pipeline, including the
   hardware runner:
    https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2776674713
 - On an Intel NUC, debug build: XTF pv64 and pv32pae suites (the
   latter with cet=no-shstk,no-ibt pv=32, since CET disables PV32);
   plus an LDT exerciser in a PV Linux guest (modify_ldt() with 1-16
   page LDTs, demand-faulting every page, LAR beyond the limit,
   shrinking, teardown; also with the guest's vCPUs bounced across
   pCPUs) -- thousands of rounds, no assertions or "unable to map"
   reports.

[1] https://lore.kernel.org/xen-devel/20240726152206.28411-1-roger.pau@citrix.com/
[2] https://lore.kernel.org/xen-devel/20250108142659.99490-1-roger.pau@citrix.com/

George Dunlap (1):
  x86/mm: allocate the per-domain page-tables from the xenheap

Roger Pau Monné (6):
  x86/mm: introduce populate_perdomain_mapping()
  x86/pv: use populate_perdomain_mapping() to map the Xen GDT
  x86/pv: set/clear guest GDT mappings using
    populate_perdomain_mapping()
  x86/pv: update guest LDT mappings using
    {populate,destroy}_perdomain_mapping()
  x86/pv: remove stashing of GDT/LDT L1 page-tables
  x86/mm: simplify create_perdomain_mapping() interface

 xen/arch/x86/domain.c               |  17 ++-
 xen/arch/x86/domain_page.c          |  10 +-
 xen/arch/x86/hvm/hvm.c              |   2 +-
 xen/arch/x86/include/asm/desc.h     |   6 +-
 xen/arch/x86/include/asm/domain.h   |  14 +-
 xen/arch/x86/include/asm/mm.h       |   9 +-
 xen/arch/x86/mm.c                   | 225 +++++++++++++++++-----------
 xen/arch/x86/pv/descriptor-tables.c |  57 ++++---
 xen/arch/x86/pv/domain.c            |  16 +-
 xen/arch/x86/pv/mm.c                |  16 +-
 xen/arch/x86/smpboot.c              |  14 +-
 xen/arch/x86/traps.c                |   4 +-
 xen/arch/x86/x86_64/mm.c            |   3 +-
 13 files changed, 221 insertions(+), 172 deletions(-)


base-commit: 669f8c502aeaa538f8407013ba04461e71361ed4
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396847.1634502 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6o9-0001Hq-RB; Thu, 20 Aug 2026 17:44:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396847.1634502; Thu, 20 Aug 2026 17:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6o9-0001Hj-O1; Thu, 20 Aug 2026 17:44:05 +0000
Received: by outflank-mailman (input) for mailman id 1396847;
 Thu, 20 Aug 2026 17:44:04 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6o8-00015l-R5
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:04 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o8-00E23U-0B;
 Thu, 20 Aug 2026 17:44:03 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o7-00DjFg-1e;
 Thu, 20 Aug 2026 17:44:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=uIVVXYNBp/ouS5mM6fbgcFwcP3APHMH5u1xUU28Itjw=; b=vzAZ3DGb7CsElFQ64hD05qH3Vw
	Rx4tQ/GJZg+MWIcm2oDqeGutDxIXPhpXVHDda7QlhU0JOn7+rSQNzYbdyMTyyJt5l6gauzFbFGRQT
	ekAUEi3k/u+wwTHYRSkN+WkLQYO4rrgSFR5mshKUrMSjILW97fYLAVfSyv2V9hCRRAns=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 2/7] x86/mm: introduce populate_perdomain_mapping()
Date: Thu, 20 Aug 2026 18:43:42 +0100
Message-ID: <20260820-asi-part1-2-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monné <roger.pau@citrix.com>

The per-domain area already has central machinery for building its
page-tables and for managing the backing pages it owns itself:
create_perdomain_mapping() / destroy_perdomain_mapping(), used by the
mapcache bitmaps, the compat argument-translation area, and the
GDT/LDT slots alike.  What the interface lacks is a way to install a
caller's own pages at a chosen address.  The PV GDT and LDT code
open-codes its own modifications to the per-domain area, capturing
aliases of its L1 tables at creation time
(create_perdomain_mapping()'s pl1tab argument) and stashing them in
d->arch.pv.gdt_ldt_l1tab.

Introduce populate_perdomain_mapping(v, va, mfn, nr, flags) to close
this gap, giving the perdomain area's rules a single place to live.
populate_perdomain_mapping writes the given MFNs, with the given
page-table flags, into v's view of the per-domain area by walking its
per-domain page-tables.  Those are xenheap pages, reached through
their always-mapped alias, so the walk involves no mapping and is
usable from any context -- including the context switch, before the
incoming vcpu's page-tables are loaded.  Callers don't need to know
where the page-tables live, how the area is structured, or whether it
is per-domain or per-vcpu.

We require the range to already have been populated down to the L1
tables by create_perdomain_mapping().  TLB flushing is left to the
caller.  A present entry not owned by the area (!_PAGE_AVAIL0) is
replaced.  A present entry owned by the area (_PAGE_AVAIL0, installed
by create_perdomain_mapping() itself) is freed and replaced: such a
page is referenced only by the mapping, so displacing it without
freeing it would leak it.  Nothing in this series replaces area-owned
backing, so the free is marked ASSERT_UNREACHABLE(); note that freeing
requires a context where the allocator may be entered -- IRQs enabled,
not in interrupt context (see ASSERT_ALLOC_CONTEXT()) -- so any future
caller replacing area-owned backing must not do so from the context
switch path.  Missing page-table structure is a hypervisor bug and
BUG_ON(): there is no safe continuation, least of all from the context
switch, where the next descriptor fetch through an unmapped GDT slot
would be fatal.

Subsequent patches convert the users of the stashed L1 tables to this
interface, starting with the Xen slots of the full GDT; the stash --
which could in any case not represent per-vcpu mappings without being
replicated for every vcpu and slot -- is then removed, leaving
create_perdomain_mapping() to manage only the page-table structure and
the pages the area owns itself.  Later parts of the series use the new
interface for their own mappings rather than adding further
mechanisms.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
Changes since the previously posted version:
- Split the introduction of populate_perdomain_mapping() from its first
   user (previously one patch: "x86/pv: introduce function to populate
   perdomain area and use it to map Xen GDT").
- Drop the linear-map fast path and the sync_local_execstate() call:
   with the per-domain page-tables in the xenheap (previous patch) the
   walk needs no mapping, so a single path serves all callers and
   contexts.
- Keep the ASSERT_UNREACHABLE() + free_domheap_page() handling of a
   replaced area-owned entry, and document the allocation-context
   requirement it places on callers replacing such entries.  BUG_ON()
   missing page-table structure, instead of domain_crash().
- Take the page-table flags as a parameter (the Xen GDT and guest GDT
   slots want RW mappings; the zero page backing torn-down GDT slots is
   mapped read-only, as today).
- Document the contract in a header comment.
- Make the mfn parameter const and nr unsigned int, matching
   {create,destroy}_perdomain_mapping().
- Drop the unused cr3_mfn() helper.

Considered, but not done to limit churn against the previously posted
version: splitting the interface into a "populate" variant (any present
entry is a bug) and an "update" variant (replacement expected), so that
call sites declare their intent and unexpected collisions become
detectable.  Of the eventual call sites in the wider series, roughly
half are of each kind.  Could be done as a follow-up if there is
interest.
---
 xen/arch/x86/include/asm/mm.h |  3 ++
 xen/arch/x86/mm.c             | 68 +++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)

diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 2254a7e3fe..1888807394 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -606,6 +606,9 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 int create_perdomain_mapping(struct domain *d, unsigned long va,
                              unsigned int nr, l1_pgentry_t **pl1tab,
                              struct page_info **ppg);
+void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
+                                const mfn_t *mfn, unsigned int nr,
+                                unsigned int flags);
 void destroy_perdomain_mapping(struct domain *d, unsigned long va,
                                unsigned int nr);
 void free_perdomain_mappings(struct domain *d);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 38a0f984fc..1810971677 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6311,6 +6311,74 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
     return rc;
 }
 
+/*
+ * Map @nr pages, @mfn[0..nr-1], at consecutive pages from @va in v's view of
+ * the per-domain area, with page-table @flags.  The range must lie within a
+ * single per-domain slot, and must already have been plumbed down to the L1
+ * tables by create_perdomain_mapping(): missing structure is a bug.  A
+ * present entry not owned by the area (no _PAGE_AVAIL0) is silently
+ * replaced, as that is how callers update their mappings; a present
+ * area-owned entry is freed and replaced, which constrains the calling
+ * context (see the comment in the body).  No TLB flushing is done: the
+ * caller decides whether the old translations can still be cached
+ * anywhere.
+ *
+ * The walk goes through the always-mapped xenheap alias of the per-domain
+ * page-tables, so it needs nothing from the current address space and is
+ * usable from any context -- including the context switch, before the
+ * incoming vcpu's page-tables are loaded.
+ */
+void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
+                                const mfn_t *mfn, unsigned int nr,
+                                unsigned int flags)
+{
+    l1_pgentry_t *l1tab = NULL, *pl1e;
+    const l3_pgentry_t *l3tab;
+    const l2_pgentry_t *l2tab;
+
+    ASSERT(va >= PERDOMAIN_VIRT_START &&
+           va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
+    ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
+    /* Area-owned pages are installed by create_perdomain_mapping() only. */
+    ASSERT(!(flags & _PAGE_AVAIL0));
+
+    l3tab = v->domain->arch.perdomain_l3;
+    BUG_ON(!l3tab);
+    BUG_ON(!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT));
+
+    l2tab = maddr_to_virt(l3e_get_paddr(l3tab[l3_table_offset(va)]));
+
+    for ( ; nr--; va += PAGE_SIZE, mfn++ )
+    {
+        if ( !l1tab || !l1_table_offset(va) )
+        {
+            const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va);
+
+            BUG_ON(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT));
+            l1tab = maddr_to_virt(l2e_get_paddr(*pl2e));
+        }
+
+        pl1e = &l1tab[l1_table_offset(va)];
+
+        /*
+         * An area-owned entry (installed by create_perdomain_mapping(),
+         * marked _PAGE_AVAIL0) holds the only reference to its page, so
+         * displacing it means freeing it.  Nothing in this series replaces
+         * area-owned backing, hence the ASSERT_UNREACHABLE(); any future
+         * caller doing so must run where freeing is permitted -- IRQs
+         * enabled, not in interrupt context (see ASSERT_ALLOC_CONTEXT())
+         * -- which the context switch path is not.
+         */
+        if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) )
+        {
+            ASSERT_UNREACHABLE();
+            free_domheap_page(l1e_get_page(*pl1e));
+        }
+
+        l1e_write(pl1e, l1e_from_mfn(*mfn, flags));
+    }
+}
+
 void destroy_perdomain_mapping(struct domain *d, unsigned long va,
                                unsigned int nr)
 {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396846.1634490 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6o8-0000vG-HR; Thu, 20 Aug 2026 17:44:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396846.1634490; Thu, 20 Aug 2026 17:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6o8-0000v4-D0; Thu, 20 Aug 2026 17:44:04 +0000
Received: by outflank-mailman (input) for mailman id 1396846;
 Thu, 20 Aug 2026 17:44:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6o7-0000sP-3b
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o6-00E23K-1p;
 Thu, 20 Aug 2026 17:44:02 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o6-00DjFg-07;
 Thu, 20 Aug 2026 17:44:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=cEDD9mG2oPJvt6c9y//9kSMyh8V/fAJEbBVdy3IMrMU=; b=JOC6YU5ZVo9GVFtmytXAbvbrsj
	CTSBtdd+DAtuDSjpPO4AaLsztgfgGZfoEfav+R65oU3ro7b1ZuO2cUD0RHmNLub1yJjN11xyEn6F7
	OjYj5G5+4bQMeiGcFAw0bykcl3C1x2zGYYJmL/BgR/jzwE2kLEckZ5S+YznQh8PDAoLk=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 1/7] x86/mm: allocate the per-domain page-tables from the xenheap
Date: Thu, 20 Aug 2026 18:43:41 +0100
Message-ID: <20260820-asi-part1-1-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The per-domain area's L3, L2 and L1 page-tables are currently
domain-heap pages with no owner, and accessed through
map_domain_page() whenever they need editing.  That has two costs.
First, every edit not going through the linear mappings of the loaded
page-tables goes through map_domain_page() per level.  Even now that is
sometimes a mapcache round trip; once the direct map becomes on-demand
it always will be.  Second, the mapcache is not usable everywhere;
specifically, it cannot be called in the context switch before the
incoming vCPU's page-tables are loaded.

Currently the Xen slot of a PV vcpu's full GDT is written during context
switch; that works by special-casing the GDT/LDT L1 tables into the
xenheap and stashing their addresses in d->arch.pv.gdt_ldt_l1tab.
Later in the series the mappings of the guest's root page-table (for
the XPTI root sync) and of the CPU's own stack (for per-CPU stack
isolation) need writing at context switch too, and per-vCPU roots add
writes on the PV kernel/user switch and new-CR3 paths.

Instead of adding more ad-hoc pointers, or arranging to be able to
call map_domain_page() from within a context switch, allocate *all* of
the per-domain page-tables from the xenheap.  Keep a pointer directly
to the L3 page within the xenheap, and when walking the page-tables,
use the MFN in the entry to reconstruct the virtual address of the
xenheap page directly.  Xenheap pages are mapped in every context, so
the tables can be edited from anywhere through their always-mapped
alias: no mapcache, no special case for the context switch.  Under the
planned on-demand direct map, xenheap pages remain mapped at that
alias for their lifetime, so this stays true.

It may seem strange for a series whose end goal is to move things out
of global mappings to start by requiring a further class of pages to
stay globally mapped.  The series is about protecting *guest* data.
The pages in question here hold page-table entries only -- MFNs and
flags, reachable through the linear mappings whenever the tables are
loaded anyway -- not guest data; XPTI's per-CPU root page-tables are
xenheap pages by the same reasoning.  The pages mapped *by* these
tables (GDT/LDT frames, the mapcache's targets, the compat
argument-translation area) are unaffected and stay domain-heap pages.

The "capture" mode of create_perdomain_mapping() no longer needs to take
its L1s from a different heap than the others; it now only records the
pointers.  The is_xen_heap_page() check in free_perdomain_mappings() goes
away with it.  No change for callers.

Two side effects to note.  First, the tables are subject to the
xenheap allocation limit (within the PV-visible direct map), as the
stashed L1s, the GDTs and XPTI's root page-tables already are -- a few
pages per vcpu at most.

Second, the xenheap allocator takes no domain, so there is no
round-robin over the domain's node affinity: so we place the tables
with MEMF_node(domain_to_node(d)), on the node of the domain's first
vcpu (or the allocating CPU's node before it exists), as the stashed
L1s already were.

Assisted-by: Claude Code:claude-fable-5
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
 xen/arch/x86/domain.c             |   4 +-
 xen/arch/x86/include/asm/domain.h |   3 +-
 xen/arch/x86/mm.c                 | 121 ++++++++++--------------------
 3 files changed, 45 insertions(+), 83 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 996b50af7a..163a2c97ae 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2015,8 +2015,8 @@ void cf_check paravirt_ctxt_switch_to(struct vcpu *v)
 
     if ( root_pgt )
         root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] =
-            l4e_from_page(v->domain->arch.perdomain_l3_pg,
-                          __PAGE_HYPERVISOR_RW);
+            l4e_from_paddr(__pa(v->domain->arch.perdomain_l3),
+                           __PAGE_HYPERVISOR_RW);
 
     if ( unlikely(v->arch.dr7 & DR7_ACTIVE_MASK) )
         activate_debugregs(v);
diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 2d0a915410..5275bb10ea 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -332,7 +332,8 @@ struct monitor_write_data {
 
 struct arch_domain
 {
-    struct page_info *perdomain_l3_pg;
+    /* Xenheap page: the per-domain page-tables are always mapped. */
+    l3_pgentry_t *perdomain_l3;
 
     /* I/O-port admin-specified access capabilities. */
     struct rangeset *ioport_caps;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b158742408..38a0f984fc 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1679,7 +1679,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
 
     /* Slot 260: Per-domain mappings. */
     l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
-        l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
+        l4e_from_mfn(virt_to_mfn(d->arch.perdomain_l3), __PAGE_HYPERVISOR_RW);
 
     /* Slot 4: Per-domain mappings mirror. */
     BUILD_BUG_ON(IS_ENABLED(CONFIG_PV32) &&
@@ -6219,54 +6219,47 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
     l3_pgentry_t *l3tab;
     l2_pgentry_t *l2tab;
     l1_pgentry_t *l1tab;
+    unsigned int memflags = MEMF_node(domain_to_node(d));
     int rc = 0;
 
     ASSERT(va >= PERDOMAIN_VIRT_START &&
            va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
 
-    if ( !d->arch.perdomain_l3_pg )
+    /*
+     * The per-domain page-tables come from the xenheap, so that they can be
+     * edited from any context through their always-mapped alias, without
+     * going through the mapcache -- in particular from the context switch,
+     * which writes the incoming vcpu's tables before loading them.
+     */
+    l3tab = d->arch.perdomain_l3;
+    if ( !l3tab )
     {
-        pg = alloc_domheap_page(d, MEMF_no_owner);
-        if ( !pg )
+        l3tab = alloc_xenheap_pages(0, memflags);
+        if ( !l3tab )
             return -ENOMEM;
-        l3tab = __map_domain_page(pg);
         clear_page(l3tab);
-        d->arch.perdomain_l3_pg = pg;
-        if ( !nr )
-        {
-            unmap_domain_page(l3tab);
-            return 0;
-        }
+        d->arch.perdomain_l3 = l3tab;
     }
-    else if ( !nr )
+
+    if ( !nr )
         return 0;
-    else
-        l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
 
     ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
 
     if ( !(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT) )
     {
-        pg = alloc_domheap_page(d, MEMF_no_owner);
-        if ( !pg )
-        {
-            unmap_domain_page(l3tab);
+        l2tab = alloc_xenheap_pages(0, memflags);
+        if ( !l2tab )
             return -ENOMEM;
-        }
-        l2tab = __map_domain_page(pg);
         clear_page(l2tab);
-        l3tab[l3_table_offset(va)] = l3e_from_page(pg, __PAGE_HYPERVISOR_RW);
+        l3tab[l3_table_offset(va)] = l3e_from_mfn(virt_to_mfn(l2tab),
+                                                  __PAGE_HYPERVISOR_RW);
     }
     else
-        l2tab = map_l2t_from_l3e(l3tab[l3_table_offset(va)]);
-
-    unmap_domain_page(l3tab);
+        l2tab = maddr_to_virt(l3e_get_paddr(l3tab[l3_table_offset(va)]));
 
     if ( !pl1tab && !ppg )
-    {
-        unmap_domain_page(l2tab);
         return 0;
-    }
 
     for ( l1tab = NULL; !rc && nr--; )
     {
@@ -6274,33 +6267,22 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
 
         if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
         {
+            l1tab = alloc_xenheap_pages(0, memflags);
+            if ( !l1tab )
+            {
+                rc = -ENOMEM;
+                break;
+            }
             if ( pl1tab && !IS_NIL(pl1tab) )
             {
-                l1tab = alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-                if ( !l1tab )
-                {
-                    rc = -ENOMEM;
-                    break;
-                }
                 ASSERT(!pl1tab[l2_table_offset(va)]);
                 pl1tab[l2_table_offset(va)] = l1tab;
-                pg = virt_to_page(l1tab);
-            }
-            else
-            {
-                pg = alloc_domheap_page(d, MEMF_no_owner);
-                if ( !pg )
-                {
-                    rc = -ENOMEM;
-                    break;
-                }
-                l1tab = __map_domain_page(pg);
             }
             clear_page(l1tab);
-            *pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR_RW);
+            *pl2e = l2e_from_mfn(virt_to_mfn(l1tab), __PAGE_HYPERVISOR_RW);
         }
         else if ( !l1tab )
-            l1tab = map_l1t_from_l2e(*pl2e);
+            l1tab = maddr_to_virt(l2e_get_paddr(*pl2e));
 
         if ( ppg &&
              !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) )
@@ -6321,15 +6303,10 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
 
         va += PAGE_SIZE;
         if ( rc || !nr || !l1_table_offset(va) )
-        {
-            /* Note that this is a no-op for the alloc_xenheap_page() case. */
-            unmap_domain_page(l1tab);
             l1tab = NULL;
-        }
     }
 
     ASSERT(!l1tab);
-    unmap_domain_page(l2tab);
 
     return rc;
 }
@@ -6343,15 +6320,15 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
            va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS));
     ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1)));
 
-    if ( !d->arch.perdomain_l3_pg )
+    l3tab = d->arch.perdomain_l3;
+    if ( !l3tab )
         return;
 
-    l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
     pl3e = l3tab + l3_table_offset(va);
 
     if ( l3e_get_flags(*pl3e) & _PAGE_PRESENT )
     {
-        const l2_pgentry_t *l2tab = map_l2t_from_l3e(*pl3e);
+        const l2_pgentry_t *l2tab = maddr_to_virt(l3e_get_paddr(*pl3e));
         const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va);
         unsigned int i = l1_table_offset(va);
 
@@ -6359,7 +6336,7 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
         {
             if ( l2e_get_flags(*pl2e) & _PAGE_PRESENT )
             {
-                l1_pgentry_t *l1tab = map_l1t_from_l2e(*pl2e);
+                l1_pgentry_t *l1tab = maddr_to_virt(l2e_get_paddr(*pl2e));
 
                 for ( ; nr && i < L1_PAGETABLE_ENTRIES; --nr, ++i )
                 {
@@ -6367,8 +6344,6 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
                         free_domheap_page(l1e_get_page(l1tab[i]));
                     l1tab[i] = l1e_empty();
                 }
-
-                unmap_domain_page(l1tab);
             }
             else if ( nr + i < L1_PAGETABLE_ENTRIES )
                 break;
@@ -6378,60 +6353,46 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va,
             ++pl2e;
             i = 0;
         }
-
-        unmap_domain_page(l2tab);
     }
-
-    unmap_domain_page(l3tab);
 }
 
 void free_perdomain_mappings(struct domain *d)
 {
-    l3_pgentry_t *l3tab;
+    l3_pgentry_t *l3tab = d->arch.perdomain_l3;
     unsigned int i;
 
-    if ( !d->arch.perdomain_l3_pg )
+    if ( !l3tab )
         return;
 
-    l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
-
     for ( i = 0; i < PERDOMAIN_SLOTS; ++i)
         if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )
         {
-            struct page_info *l2pg = l3e_get_page(l3tab[i]);
-            l2_pgentry_t *l2tab = __map_domain_page(l2pg);
+            l2_pgentry_t *l2tab = maddr_to_virt(l3e_get_paddr(l3tab[i]));
             unsigned int j;
 
             for ( j = 0; j < L2_PAGETABLE_ENTRIES; ++j )
                 if ( l2e_get_flags(l2tab[j]) & _PAGE_PRESENT )
                 {
-                    struct page_info *l1pg = l2e_get_page(l2tab[j]);
+                    l1_pgentry_t *l1tab =
+                        maddr_to_virt(l2e_get_paddr(l2tab[j]));
 
                     if ( l2e_get_flags(l2tab[j]) & _PAGE_AVAIL0 )
                     {
-                        l1_pgentry_t *l1tab = __map_domain_page(l1pg);
                         unsigned int k;
 
                         for ( k = 0; k < L1_PAGETABLE_ENTRIES; ++k )
                             if ( perdomain_l1e_needs_freeing(l1tab[k]) )
                                 free_domheap_page(l1e_get_page(l1tab[k]));
-
-                        unmap_domain_page(l1tab);
                     }
 
-                    if ( is_xen_heap_page(l1pg) )
-                        free_xenheap_page(page_to_virt(l1pg));
-                    else
-                        free_domheap_page(l1pg);
+                    free_xenheap_page(l1tab);
                 }
 
-            unmap_domain_page(l2tab);
-            free_domheap_page(l2pg);
+            free_xenheap_page(l2tab);
         }
 
-    unmap_domain_page(l3tab);
-    free_domheap_page(d->arch.perdomain_l3_pg);
-    d->arch.perdomain_l3_pg = NULL;
+    free_xenheap_page(l3tab);
+    d->arch.perdomain_l3 = NULL;
 }
 
 static void write_sss_token(unsigned long *ptr)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396848.1634510 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oB-0001V5-1m; Thu, 20 Aug 2026 17:44:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396848.1634510; Thu, 20 Aug 2026 17:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oA-0001Uy-VT; Thu, 20 Aug 2026 17:44:06 +0000
Received: by outflank-mailman (input) for mailman id 1396848;
 Thu, 20 Aug 2026 17:44:06 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6oA-0001My-3L
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:06 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o9-00E23e-1a;
 Thu, 20 Aug 2026 17:44:05 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6o8-00DjFg-3D;
 Thu, 20 Aug 2026 17:44:05 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=KyUzHauc47Dbzb+CzrzMBc+T+6WI7kFJLHChZreYt2Y=; b=WW9phl8g1HvvMFoIU0fHSEPlwm
	Q47FtqfSVIV4WP5EZyUC2aONk9rsUMyxNacn7zzrw+bwnNs8YzqNmpRXUJzp6snu1J8fbwRHdU7YK
	pI6Mo9L2eEmogfFaBCZaw5lgp5imqJIbA/W0v1UyGJDDSTgMDT1NYyNIOODvowJtFeG4=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 3/7] x86/pv: use populate_perdomain_mapping() to map the Xen GDT
Date: Thu, 20 Aug 2026 18:43:43 +0100
Message-ID: <20260820-asi-part1-3-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monné <roger.pau@citrix.com>

Currently, update_xen_slot_in_full_gdt() uses the stashed pointer in
d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's page-tables with
Xen's GDT, by writing a stashed per-cpu copy of a pre-baked L1 entry
(either 64-bit or compat version).

Now that all perdomain pagetables are allocated from the xenheap and
their root L3 stashed in d->arch.perdomain_l3,
d->arch.pv.gdt_ldt_l1tab is redundant.  Remove one user by switching
update_xen_slot_in_full_gdt() to using populate_perdomain_mapping().

Since populate_perdomain_mapping() takes an mfn rather than an l1e,
cache the mfn of the per-cpu page instead.  As a side effect, this
consolidates the setting of the flags into a single place.  Continue
to check that the per-cpu value we're using has been initialized:
per-CPU data starts out zeroed, and no GDT can live at MFN 0.

What was one store through a cached pointer is now an out-of-line
walk (L3 pointer, L3e, L2e, then the L1e) on every PV context switch:
three dependent loads, negligible next to the CR3 write that follows.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
Changes since the previously posted version:
- populate_perdomain_mapping() introduction split into the previous
   patch; this patch is now just the Xen GDT conversion.
- Retain the "GDT MFN cached" check as ASSERT(mfn_x(mfn)).
---
 xen/arch/x86/domain.c           | 13 +++++++++----
 xen/arch/x86/include/asm/desc.h |  6 ++++--
 xen/arch/x86/smpboot.c          | 14 +++++---------
 xen/arch/x86/traps.c            |  4 ++--
 4 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 163a2c97ae..f5b2eef95a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2062,11 +2062,16 @@ static always_inline bool need_full_gdt(const struct domain *d)
 
 static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsigned int cpu)
 {
-    ASSERT(per_cpu(gdt_l1e, cpu).l1); /* Confirm these have been cached. */
+    mfn_t mfn = !is_pv_32bit_vcpu(v) ? per_cpu(gdt_mfn, cpu)
+                                     : per_cpu(compat_gdt_mfn, cpu);
 
-    l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE,
-              !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu)
-                                   : per_cpu(compat_gdt_l1e, cpu));
+    /* Confirm the GDT MFNs have been cached (MFN 0 is never a GDT). */
+    ASSERT(mfn_x(mfn));
+
+    populate_perdomain_mapping(v,
+                               GDT_VIRT_START(v) +
+                               (FIRST_RESERVED_GDT_PAGE << PAGE_SHIFT),
+                               &mfn, 1, __PAGE_HYPERVISOR_RW);
 }
 
 static void load_full_gdt(const struct vcpu *v, unsigned int cpu)
diff --git a/xen/arch/x86/include/asm/desc.h b/xen/arch/x86/include/asm/desc.h
index dcbdac3ff7..a26df9fbe9 100644
--- a/xen/arch/x86/include/asm/desc.h
+++ b/xen/arch/x86/include/asm/desc.h
@@ -44,6 +44,8 @@
 
 #ifndef __ASSEMBLER__
 
+#include <xen/mm-frame.h>
+
 #define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
 
 /* Fix up the RPL of a guest segment selector. */
@@ -136,10 +138,10 @@ struct __packed desc_ptr {
 
 extern seg_desc_t boot_gdt[];
 DECLARE_PER_CPU(seg_desc_t *, gdt);
-DECLARE_PER_CPU(l1_pgentry_t, gdt_l1e);
+DECLARE_PER_CPU(mfn_t, gdt_mfn);
 extern seg_desc_t boot_compat_gdt[];
 DECLARE_PER_CPU(seg_desc_t *, compat_gdt);
-DECLARE_PER_CPU(l1_pgentry_t, compat_gdt_l1e);
+DECLARE_PER_CPU(mfn_t, compat_gdt_mfn);
 DECLARE_PER_CPU(bool, full_gdt_loaded);
 
 static inline void lgdt(const struct desc_ptr *gdtr)
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 84e9e4beed..9246945506 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1085,8 +1085,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
     if ( gdt == NULL )
         goto out;
     per_cpu(gdt, cpu) = gdt;
-    per_cpu(gdt_l1e, cpu) =
-        l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
+    per_cpu(gdt_mfn, cpu) = _mfn(virt_to_mfn(gdt));
     memcpy(gdt, boot_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
     BUILD_BUG_ON(NR_CPUS > 0x10000);
     gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu;
@@ -1095,8 +1094,7 @@ static int cpu_smpboot_alloc(unsigned int cpu)
     per_cpu(compat_gdt, cpu) = gdt = alloc_xenheap_pages(0, memflags);
     if ( gdt == NULL )
         goto out;
-    per_cpu(compat_gdt_l1e, cpu) =
-        l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW);
+    per_cpu(compat_gdt_mfn, cpu) = _mfn(virt_to_mfn(gdt));
     memcpy(gdt, boot_compat_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE);
     gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu;
 #endif
@@ -1174,15 +1172,13 @@ void __init smp_prepare_cpus(void)
     print_cpu_info(0);
 
     /*
-     * Cache {,compat_}gdt_l1e for the BSP now that physically relocation is
+     * Cache {,compat_}gdt_mfn for the BSP now that physically relocation is
      * done.  It must be after physical relocation of Xen, and before the
      * first context_switch().
      */
-    this_cpu(gdt_l1e) =
-        l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
+    this_cpu(gdt_mfn) = _mfn(virt_to_mfn(boot_gdt));
     if ( IS_ENABLED(CONFIG_PV32) )
-        this_cpu(compat_gdt_l1e) =
-            l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW);
+        this_cpu(compat_gdt_mfn) = _mfn(virt_to_mfn(boot_compat_gdt));
 
     boot_cpu_physical_apicid = get_apic_id();
     x86_cpu_to_apicid[0] = boot_cpu_physical_apicid;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 1774966305..2fcaa413f7 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -71,10 +71,10 @@ DEFINE_PER_CPU(uint64_t, efer);
 static DEFINE_PER_CPU(unsigned long, last_extable_addr);
 
 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, gdt);
-DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, gdt_l1e);
+DEFINE_PER_CPU_READ_MOSTLY(mfn_t, gdt_mfn);
 #ifdef CONFIG_PV32
 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, compat_gdt);
-DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, compat_gdt_l1e);
+DEFINE_PER_CPU_READ_MOSTLY(mfn_t, compat_gdt_mfn);
 #endif
 
 /*
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396849.1634520 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oD-0001kZ-8z; Thu, 20 Aug 2026 17:44:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396849.1634520; Thu, 20 Aug 2026 17:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oD-0001kQ-5b; Thu, 20 Aug 2026 17:44:09 +0000
Received: by outflank-mailman (input) for mailman id 1396849;
 Thu, 20 Aug 2026 17:44:07 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6oB-0001bY-FY
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:07 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oA-00E23p-36;
 Thu, 20 Aug 2026 17:44:06 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oA-00DjFg-1U;
 Thu, 20 Aug 2026 17:44:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=OfHOX4KyRE8Utb0GZ4BSRadT0zqgRSmp6GLhoRcTwLQ=; b=4y8MUZHlsbdrNBj6nQMCbGKCqH
	MJjbkHibEvm8XvbREkZQ2NncE0+meWnXz2bWyFrtcq009390MduLx7ClFKeeLzMKh77AN9y08MFfU
	xiV4wJsHh3aWu70+F9BJwXexJZBd+Rahe46P3k31wITsF9aStyysvGRjdlaOBL/XT+UY=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 4/7] x86/pv: set/clear guest GDT mappings using populate_perdomain_mapping()
Date: Thu, 20 Aug 2026 18:43:44 +0100
Message-ID: <20260820-asi-part1-4-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monné <roger.pau@citrix.com>

Until the previous patch, update_xen_slot_in_full_gdt() used the
stashed pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming
vCPU's page tables with Xen's GDT; this was necessary because
perdomain pagetables were mapped from the domheap by default, and
map_domain_page() couldn't be called in a context switch.  Having a
handy pointer to an always-mapped version of the GDT/LDT L1 table,
other sites which modify the table started using it for convenience,
even if they weren't called from within a context switch.  One example
is pv_{set,destroy}_gdt.

Now that all perdomain pagetables are allocated from the xenheap and
their root L3 stashed in d->arch.perdomain_l3,
d->arch.pv.gdt_ldt_l1tab is redundant.  The previous patch removed one
user by modifying update_xen_slot_in_full_gdt() to call
populate_perdomain_mapping().  Continue that process by switching both
pv_{set,destroy}_gdt() to it as well.

pv_destroy_gdt() currently loops over the L1 entries directly,
extracting the MFN from each, dropping the type and reference unless
it was the zero page, and replacing the entry with a read-only mapping
of the zero page.  Since we no longer have the L1 to hand, drop the
references using v->arch.pv.gdt_frames[] instead, and install the
zero-page mappings with a single populate_perdomain_mapping() call.
This makes gdt_frames[] consistently the source of truth for MFNs.

Behaviour is unchanged: torn-down slots map the zero page read-only,
as they have since cf6d39f819 ("x86/PV: properly populate descriptor
tables"), so that LAR/LSL/VERR/VERW on a selector beyond the guest's
limit clear ZF as on native rather than taking a #PF-converted #GP --
and as every PV vCPU's unused slots do from the start, pv_set_gdt()
tearing down the old GDT (zero page included) before installing the
new one.

In the case of pv_set_gdt, we have a slightly awkward situation with
types.  The ABI with the guest uses unsigned long[], but
populate_perdomain_mapping wants an array of mfn_t.
v->arch.pv.gdt_frames being unsigned long means we can just copy from
it across the guest ABI with no conversions.  We could in theory
convert it to mfn_t[] instead, and then pass v->arch.pv.gdt_frames
into populate_perdomain_mapping; but then we'd need to add a
conversion on all the places where frames are copied out.  We choose
instead to copy frames into a temporary mfn_t array on the stack to
pass into populate_perdomain_mapping.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
Changes since the previously posted version:
- Retain the gdt_ents zeroing when tearing down the GDT (its removal
   was queried by Jan).
- Map torn-down slots read-only to the zero page (via the
   populate_perdomain_mapping() flags parameter) rather than removing
   the mappings with destroy_perdomain_mapping(): empty slots would be
   a guest-visible partial revert of cf6d39f819 (see the commit
   message).  With the destroy call gone, its v->arch.cr3 guard --
   also queried by Jan -- goes too: the zero-page rewrite runs
   unconditionally.
- Keep gdt_frames[] as unsigned long[] rather than switching it to
   mfn_t[] as Jan suggested; the commit message explains the
   trade-off.
- Retitle: destroy_perdomain_mapping() is no longer used here.
---
 xen/arch/x86/pv/descriptor-tables.c | 37 ++++++++++++++++++-----------
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
index 8a32b9ae5c..5dda5bffe3 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -49,33 +49,42 @@ bool pv_destroy_ldt(struct vcpu *v)
 
 void pv_destroy_gdt(struct vcpu *v)
 {
-    l1_pgentry_t *pl1e = pv_gdt_ptes(v);
-    mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page));
-    l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO);
+    const mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page));
+    mfn_t zero_mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)];
     unsigned int i;
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
     v->arch.pv.gdt_ents = 0;
-    for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ )
+
+    for ( i = 0; i < ARRAY_SIZE(zero_mfns); i++ )
     {
-        mfn_t mfn = l1e_get_mfn(pl1e[i]);
+        zero_mfns[i] = zero_mfn;
 
-        if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) &&
-             !mfn_eq(mfn, zero_mfn) )
-            put_page_and_type(mfn_to_page(mfn));
+        /* MFN 0 can never pass get_page_and_type(), so 0 marks unused slots. */
+        if ( !v->arch.pv.gdt_frames[i] )
+            continue;
 
-        l1e_write(&pl1e[i], zero_l1e);
+        put_page_and_type(mfn_to_page(_mfn(v->arch.pv.gdt_frames[i])));
         v->arch.pv.gdt_frames[i] = 0;
     }
+
+    /*
+     * Point every slot at the zero page, read-only: a descriptor fetch from
+     * the unused part of the GDT then finds a not-present descriptor rather
+     * than a missing mapping, so LAR/LSL/VERR/VERW on a selector beyond the
+     * guest's limit clear ZF as they do on native, instead of faulting.
+     */
+    populate_perdomain_mapping(v, GDT_VIRT_START(v), zero_mfns,
+                               ARRAY_SIZE(zero_mfns), __PAGE_HYPERVISOR_RO);
 }
 
 int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
                unsigned int entries)
 {
     struct domain *d = v->domain;
-    l1_pgentry_t *pl1e;
     unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512);
+    mfn_t mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)];
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
@@ -90,6 +99,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
         if ( !mfn_valid(mfn) ||
              !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) )
             goto fail;
+
+        mfns[i] = mfn;
     }
 
     /* Tear down the old GDT. */
@@ -97,12 +108,10 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[],
 
     /* Install the new GDT. */
     v->arch.pv.gdt_ents = entries;
-    pl1e = pv_gdt_ptes(v);
     for ( i = 0; i < nr_frames; i++ )
-    {
         v->arch.pv.gdt_frames[i] = frames[i];
-        l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW));
-    }
+    populate_perdomain_mapping(v, GDT_VIRT_START(v), mfns, nr_frames,
+                               __PAGE_HYPERVISOR_RW);
 
     return 0;
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396850.1634530 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oE-0001yd-HM; Thu, 20 Aug 2026 17:44:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396850.1634530; Thu, 20 Aug 2026 17:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oE-0001yR-Ck; Thu, 20 Aug 2026 17:44:10 +0000
Received: by outflank-mailman (input) for mailman id 1396850;
 Thu, 20 Aug 2026 17:44:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6oC-0001kB-VQ
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:08 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oC-00E247-1M;
 Thu, 20 Aug 2026 17:44:08 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oB-00DjFg-2z;
 Thu, 20 Aug 2026 17:44:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=R1q6Hy5ynYIAwwjvHwGLb/Kb5YMqyXOjLpgHFR8Cx8w=; b=pdYwYHiyc31hVa8zA+xb6TO8bJ
	loPp6CKyaWscSnC9EfUqCb4GVETAO7ezbJOlK0dPnM9b5nNZ69wzKl2uUvM/00AYg4VvwyWmVgq9I
	Vyu9oSD9IpdbKnKv1GoCJyOqMsClNuJQ36cpm5m3dASBwytVbPXKOqHkBY61dtRHpN54=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 5/7] x86/pv: update guest LDT mappings using {populate,destroy}_perdomain_mapping()
Date: Thu, 20 Aug 2026 18:43:45 +0100
Message-ID: <20260820-asi-part1-5-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monné <roger.pau@citrix.com>

Until two patches ago, update_xen_slot_in_full_gdt() used the stashed
pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vCPU's page
tables with Xen's GDT; this was necessary because perdomain pagetables
were mapped from the domheap by default, and map_domain_page() couldn't
be called in a context switch.  Having a handy pointer to an
always-mapped version of the GDT/LDT L1 table, other sites which modify
the table started using it for convenience, even if they weren't called
from within a context switch.  These include pv_map_ldt_shadow_page()
and pv_destroy_ldt().

Now that all perdomain pagetables are allocated from the xenheap and
their root L3 stashed in d->arch.perdomain_l3,
d->arch.pv.gdt_ldt_l1tab is redundant.  The previous two patches
removed the GDT users; continue that process by refactoring the LDT
sites as well.

pv_map_ldt_shadow_page() is, by definition, always modifying the
currently-running vCPU: it runs from the #PF handler for a guest-mode
descriptor fetch, and running the guest implies its page tables are
loaded.  So it could simply write the linear recursive mappings
directly.  Go through populate_perdomain_mapping() anyway, to keep a
single writer for the per-domain area.

For pv_destroy_ldt(), use destroy_perdomain_mapping().

Previously, pv_destroy_ldt() used the L1 LDT entries themselves to
determine which MFNs to drop type and count references to.  Since we
don't have the L1 handy, we must now keep the MFNs corresponding to L1
slots in an array in the vCPU structure, as we do in the GDT case.

Note that mappings_dropped (the return value of pv_destroy_ldt()) now
reflects the *number of valid MFNs in this array*, not *the number of
non-empty L1 entries*.  This introduces an invariant we must maintain:
pv_map_ldt_shadow_page() writes both the array entry and the mapping,
and pv_destroy_ldt() clears both, so the two stay in lockstep.

Also note that, unlike pv_destroy_gdt() from the previous patch,
pv_destroy_ldt() doesn't fill in the values with zero_l1e (see
61031e64d3), so there's no change here.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
Changes since the previously posted version:
- Initialise ldt_frames[] ahead of the first fail-able initialisation step.
- Call destroy_perdomain_mapping() with its existing domain parameter;
   the switch to a vCPU parameter moves to a future patch.
- Use populate_perdomain_mapping() in pv_map_ldt_shadow_page() rather
   than open-coding the linear-map write; retitle accordingly.
- Comment the INVALID_MFN skip in pv_destroy_ldt(): the LDT is
   demand-faulted, so its pages may be sparsely mapped (Alejandro's
   question on v2).
- Rewrite commit message (including describing the ldt_frames[]
   array's role directly, as Jan asked).
---
 xen/arch/x86/include/asm/domain.h   |  2 ++
 xen/arch/x86/pv/descriptor-tables.c | 20 +++++++++++---------
 xen/arch/x86/pv/domain.c            |  4 ++++
 xen/arch/x86/pv/mm.c                | 16 ++++++++++++----
 4 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 5275bb10ea..2c9efd59bf 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -542,6 +542,8 @@ struct pv_vcpu
     struct trap_info *trap_ctxt;
 
     unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE];
+    /* Max LDT entries is 8192, so 8192 * 8 = 64KiB (16 pages). */
+    mfn_t ldt_frames[16];
     unsigned long ldt_base;
     unsigned int gdt_ents, ldt_ents;
 
diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c
index 5dda5bffe3..261bf29c90 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -20,28 +20,30 @@
  */
 bool pv_destroy_ldt(struct vcpu *v)
 {
-    l1_pgentry_t *pl1e;
+    const unsigned int nr_frames = ARRAY_SIZE(v->arch.pv.ldt_frames);
     unsigned int i, mappings_dropped = 0;
-    struct page_info *page;
 
     ASSERT(!in_irq());
 
     ASSERT(v == current || !vcpu_cpu_dirty(v));
 
-    pl1e = pv_ldt_ptes(v);
+    destroy_perdomain_mapping(v->domain, LDT_VIRT_START(v), nr_frames);
 
-    for ( i = 0; i < 16; i++ )
+    for ( i = 0; i < nr_frames; i++ )
     {
-        if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) )
-            continue;
+        mfn_t mfn = v->arch.pv.ldt_frames[i];
+        struct page_info *page;
 
-        page = l1e_get_page(pl1e[i]);
-        l1e_write(&pl1e[i], l1e_empty());
-        mappings_dropped++;
+        /* The LDT is demand-faulted, so its pages may be sparsely mapped. */
+        if ( mfn_eq(mfn, INVALID_MFN) )
+            continue;
 
+        v->arch.pv.ldt_frames[i] = INVALID_MFN;
+        page = mfn_to_page(mfn);
         ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page);
         ASSERT_PAGE_IS_DOMAIN(page, v->domain);
         put_page_and_type(page);
+        mappings_dropped++;
     }
 
     return mappings_dropped;
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 0c42ae58aa..7ddab1949f 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -340,10 +340,14 @@ void pv_vcpu_destroy(struct vcpu *v)
 int pv_vcpu_initialise(struct vcpu *v)
 {
     struct domain *d = v->domain;
+    unsigned int i;
     int rc;
 
     ASSERT(!is_idle_domain(d));
 
+    for ( i = 0; i < ARRAY_SIZE(v->arch.pv.ldt_frames); i++ )
+        v->arch.pv.ldt_frames[i] = INVALID_MFN;
+
     rc = pv_create_gdt_ldt_l1tab(v);
     if ( rc )
         return rc;
diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c
index 5378299b8c..da280d7757 100644
--- a/xen/arch/x86/pv/mm.c
+++ b/xen/arch/x86/pv/mm.c
@@ -53,7 +53,8 @@ bool pv_map_ldt_shadow_page(unsigned int offset)
     struct vcpu *curr = current;
     struct domain *currd = curr->domain;
     struct page_info *page;
-    l1_pgentry_t gl1e, *pl1e, nl1e;
+    l1_pgentry_t gl1e;
+    mfn_t mfn;
     unsigned long linear = curr->arch.pv.ldt_base + offset;
 
     BUG_ON(in_irq());
@@ -87,10 +88,17 @@ bool pv_map_ldt_shadow_page(unsigned int offset)
         return false;
     }
 
-    pl1e = &pv_ldt_ptes(curr)[offset >> PAGE_SHIFT];
-    nl1e = l1e_from_pfn(l1e_get_pfn(gl1e), __PAGE_HYPERVISOR_RW);
+    mfn = page_to_mfn(page);
+    curr->arch.pv.ldt_frames[offset >> PAGE_SHIFT] = mfn;
 
-    l1e_write(pl1e, nl1e);
+    /*
+     * Running the guest implies its page-tables are loaded, so the linear
+     * mappings would do; go through the interface anyway to keep a single
+     * writer for the per-domain area.
+     */
+    populate_perdomain_mapping(curr,
+                               LDT_VIRT_START(curr) + (offset & PAGE_MASK),
+                               &mfn, 1, __PAGE_HYPERVISOR_RW);
 
     return true;
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396851.1634538 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oF-0002Ei-UW; Thu, 20 Aug 2026 17:44:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396851.1634538; Thu, 20 Aug 2026 17:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oF-0002EZ-PI; Thu, 20 Aug 2026 17:44:11 +0000
Received: by outflank-mailman (input) for mailman id 1396851;
 Thu, 20 Aug 2026 17:44:10 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6oE-0001yp-G0
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:10 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oD-00E24I-2r;
 Thu, 20 Aug 2026 17:44:09 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oD-00DjFg-1F;
 Thu, 20 Aug 2026 17:44:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=oJNvo8JLdTW3Dqid1mmBEIeehjw6UcTmR3AblTiyPqc=; b=YbMXUi63sZKy5I28G0wUZLoKxQ
	y7swpzEgPhHbQxJ5BItN+sT9hbK/KHHwbKYrYM4gFA/AFnebVE8RqPxOxAX3feR+behZhCI/6xig8
	/oYIzm68ix8KF2TLDHF2xgENXKiwUJsugl1DFqPvlttX3zzhl1FXMtLrQBHxkOAdzZbs=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 6/7] x86/pv: remove stashing of GDT/LDT L1 page-tables
Date: Thu, 20 Aug 2026 18:43:46 +0100
Message-ID: <20260820-asi-part1-6-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monné <roger.pau@citrix.com>

There are no remaining users of the stashed L1 page-tables in
d->arch.pv.gdt_ldt_l1tab.  Remove it, and all helpers.

pv_create_gdt_ldt_l1tab() now passes NIL() rather than the stash
array.  create_perdomain_mapping() still eagerly allocates the L1
tables covering the GDT/LDT range, but their addresses are no longer
handed back.  Doing this is necessary because
populate_perdomain_mapping() only fills existing tables, and treats
missing structure as a bug.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
Changes since the previously posted version:
- Note the implications of changing from pointer to NIL() in
   pv_create_gdt_ldt_l1tab().  In v2 this also changed where new
   GDT/LDT L1 tables were allocated from: upstream's capture mode
   takes them from the xenheap (the stashed pointer has to stay
   usable), the NIL() mode from the domheap.  Here they come from the
   xenheap in all modes ("x86/mm: allocate the per-domain page-tables
   from the xenheap"), so the switch only stops the addresses being
   handed back.
---
 xen/arch/x86/include/asm/domain.h |  9 ---------
 xen/arch/x86/pv/domain.c          | 10 +---------
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
index 2c9efd59bf..7eab2ff597 100644
--- a/xen/arch/x86/include/asm/domain.h
+++ b/xen/arch/x86/include/asm/domain.h
@@ -287,8 +287,6 @@ struct time_scale {
 
 struct pv_domain
 {
-    l1_pgentry_t **gdt_ldt_l1tab;
-
     atomic_t nr_l4_pages;
 
     /* Is a 32-bit PV guest? */
@@ -525,13 +523,6 @@ struct arch_domain
 #define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
 #define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
 
-#define gdt_ldt_pt_idx(v) \
-      ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
-#define pv_gdt_ptes(v) \
-    ((v)->domain->arch.pv.gdt_ldt_l1tab[gdt_ldt_pt_idx(v)] + \
-     (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & (L1_PAGETABLE_ENTRIES - 1)))
-#define pv_ldt_ptes(v) (pv_gdt_ptes(v) + 16)
-
 struct pv_vcpu
 {
     /* map_domain_page() mapping cache. */
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 7ddab1949f..35d1761c9c 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -315,7 +315,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
 {
     return create_perdomain_mapping(v->domain, GDT_VIRT_START(v),
                                     1U << GDT_LDT_VCPU_SHIFT,
-                                    v->domain->arch.pv.gdt_ldt_l1tab,
+                                    NIL(l1_pgentry_t *),
                                     NULL);
 }
 
@@ -389,8 +389,6 @@ void pv_domain_destroy(struct domain *d)
                               GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
 
     XFREE(d->arch.pv.cpuidmasks);
-
-    FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);
 }
 
 void noreturn cf_check continue_pv_domain(void);
@@ -406,12 +404,6 @@ int pv_domain_initialise(struct domain *d)
 
     pv_l1tf_domain_init(d);
 
-    d->arch.pv.gdt_ldt_l1tab =
-        alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-    if ( !d->arch.pv.gdt_ldt_l1tab )
-        goto fail;
-    clear_page(d->arch.pv.gdt_ldt_l1tab);
-
     if ( levelling_caps & ~LCAP_faulting &&
          (d->arch.pv.cpuidmasks = xmemdup(&cpuidmask_defaults)) == NULL )
         goto fail;
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 20 17:44:13 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Aug 2026 17:44:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1396852.1634547 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oH-0002Uh-8y; Thu, 20 Aug 2026 17:44:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1396852.1634547; Thu, 20 Aug 2026 17:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wx6oH-0002U3-4W; Thu, 20 Aug 2026 17:44:13 +0000
Received: by outflank-mailman (input) for mailman id 1396852;
 Thu, 20 Aug 2026 17:44:12 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wx6oG-0002Hb-2t
 for xen-devel@lists.xenproject.org; Thu, 20 Aug 2026 17:44:12 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oF-00E24S-17;
 Thu, 20 Aug 2026 17:44:11 +0000
Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.tail87ea19.ts.net)
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wx6oE-00DjFg-2j;
 Thu, 20 Aug 2026 17:44:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From;
	bh=/Kcw94vkaHCxYDdapb519eUOueMrlstSp7fpRrLXQ38=; b=ljM+ma/aVDVEQo/PRvbC3bv2Zd
	rJmyXQwNQTKn/Ou5LBOPke8rER0kGMa3abJV/NVi9hyp4nHoaPD1jDxFTVOXjnsvZq8XJGzoRMlc9
	OEKN4lQE6XKS1AE6YG99iqB0HR8R2I9SAH4RT4B0rc1DFV68ZgKSTUIR7bFMfwLigPeE=;
From: George Dunlap <gwd@xenproject.org>
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 7/7] x86/mm: simplify create_perdomain_mapping() interface
Date: Thu, 20 Aug 2026 18:43:47 +0100
Message-ID: <20260820-asi-part1-7-f2dbd92b8459@xenproject.org>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Roger Pau Monné <roger.pau@citrix.com>

create_perdomain_mapping()'s interface is richer than any caller needs.
The paging structure for the requested range is built to a depth
selected by the pl1tab and ppg arguments, each of which distinguishes
NULL from NIL() from a real pointer:

 - nr == 0: only ensure the per-domain L3 exists; nothing else is
   allocated, and the other arguments are ignored.
 - pl1tab == a pointer: allocate the L1 tables covering the range, and
   return their addresses in the array -- the mode that existed to
   build the GDT/LDT stash.
 - pl1tab == NIL(): allocate the L1 tables, and return nothing.
 - pl1tab == NULL: do not plumb L1 tables for their own sake (they are
   still allocated on demand if data-page population requires them).
 - ppg == a pointer: allocate and install zeroed data pages across the
   range, and return their struct page_info pointers in the array.
 - ppg == NIL(): allocate and install the zeroed data pages, but hand
   nothing back; the pages are reachable only through the mapping.
 - ppg == NULL: do not allocate data pages.
 - both NULL, nr > 0: stop after the slot's L2; do not plumb L1 tables
   at all.

Very few of these modes have users now.  The last user of the
pl1tab capture mode was removed when we removed the GDT/LDT stash.
The ppg capture mode never had any users.  Nothing uses the both-NULL
L2-only mode with nr != 0.  What remains is exactly one bit of
information: whether the caller wants the range populated with zeroed,
area-owned data pages, or merely plumbed down to the L1 tables, ready
for populate_perdomain_mapping() to install caller-owned pages.

Replace the two arguments with a boolean expressing that bit.  With the
stashing mode gone the NIL()/IS_NIL() macros lose their last user, so
drop them as well; and document the resulting interface.

No caller changes behaviour: every existing call maps onto the boolean
exactly.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: George Dunlap <gwd@xenproject.org>
---
Changes since the previously posted version:
- Drop the now-unused NIL()/IS_NIL() macros as requested during review
- Describe the prior interface in the commit message and add a doc
   comment for the simplified one.
---
 xen/arch/x86/domain_page.c    | 10 ++++-----
 xen/arch/x86/hvm/hvm.c        |  2 +-
 xen/arch/x86/include/asm/mm.h |  6 +-----
 xen/arch/x86/mm.c             | 40 +++++++++++++++++++++++------------
 xen/arch/x86/pv/domain.c      |  4 +---
 xen/arch/x86/x86_64/mm.c      |  3 +--
 6 files changed, 35 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 72c00194f3..1c1deeeebc 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -246,8 +246,7 @@ int mapcache_domain_init(struct domain *d)
     spin_lock_init(&dcache->lock);
 
     return create_perdomain_mapping(d, (unsigned long)dcache->inuse,
-                                    2 * bitmap_pages + 1,
-                                    NIL(l1_pgentry_t *), NULL);
+                                    2 * bitmap_pages + 1, false);
 }
 
 int mapcache_vcpu_init(struct vcpu *v)
@@ -264,16 +263,15 @@ int mapcache_vcpu_init(struct vcpu *v)
     if ( ents > dcache->entries )
     {
         /* Populate page tables. */
-        int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents,
-                                          NIL(l1_pgentry_t *), NULL);
+        int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents, false);
 
         /* Populate bit maps. */
         if ( !rc )
             rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse,
-                                          nr, NULL, NIL(struct page_info *));
+                                          nr, true);
         if ( !rc )
             rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage,
-                                          nr, NULL, NIL(struct page_info *));
+                                          nr, true);
 
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 955fc062a5..e8fbe7ba27 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -620,7 +620,7 @@ int hvm_domain_initialise(struct domain *d,
     INIT_LIST_HEAD(&d->arch.hvm.mmcfg_regions);
     INIT_LIST_HEAD(&d->arch.hvm.msix_tables);
 
-    rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
+    rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, false);
     if ( rc )
         goto fail;
 
diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h
index 1888807394..30eaec9179 100644
--- a/xen/arch/x86/include/asm/mm.h
+++ b/xen/arch/x86/include/asm/mm.h
@@ -600,12 +600,8 @@ long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-#define NIL(type) ((type *)-sizeof(type))
-#define IS_NIL(ptr) (!((uintptr_t)(ptr) + sizeof(*(ptr))))
-
 int create_perdomain_mapping(struct domain *d, unsigned long va,
-                             unsigned int nr, l1_pgentry_t **pl1tab,
-                             struct page_info **ppg);
+                             unsigned int nr, bool populate);
 void populate_perdomain_mapping(const struct vcpu *v, unsigned long va,
                                 const mfn_t *mfn, unsigned int nr,
                                 unsigned int flags);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 1810971677..aa26d12ac2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6211,9 +6211,33 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e)
            (_PAGE_PRESENT | _PAGE_AVAIL0);
 }
 
+/*
+ * Ensure the paging structure for [va, va + nr * PAGE_SIZE) of d's
+ * per-domain area is in place, allocating whichever levels are missing:
+ * the (domain-wide) L3 root, the slot's L2, and all L1 tables covering
+ * the range.  The page-tables come from the xenheap, so that they stay
+ * reachable through their always-mapped alias; populated pages come from
+ * the domain heap.  The range must lie within a single per-domain slot
+ * (one L3 entry), and already-present levels and entries are left
+ * untouched, so calls are idempotent over existing ranges.
+ *
+ * nr == 0: only ensure the per-domain L3 itself exists; populate is
+ * ignored.  Used to set the area up before any sub-range is known.
+ *
+ * populate == false: stop once the L1 tables are in place.  The range is
+ * then ready for caller-owned pages to be mapped and unmapped via
+ * populate_perdomain_mapping() / destroy_perdomain_mapping(), which only
+ * fill (or clear) existing tables; populate treats missing structure as a
+ * bug, destroy skips it.
+ *
+ * populate == true: additionally install a freshly allocated, zeroed page
+ * at every not-yet-present entry in the range.  Such pages are marked
+ * _PAGE_AVAIL0, "owned by the per-domain area": teardown frees them (see
+ * perdomain_l1e_needs_freeing()), whereas caller-owned mappings are only
+ * ever unmapped.
+ */
 int create_perdomain_mapping(struct domain *d, unsigned long va,
-                             unsigned int nr, l1_pgentry_t **pl1tab,
-                             struct page_info **ppg)
+                             unsigned int nr, bool populate)
 {
     struct page_info *pg;
     l3_pgentry_t *l3tab;
@@ -6258,9 +6282,6 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
     else
         l2tab = maddr_to_virt(l3e_get_paddr(l3tab[l3_table_offset(va)]));
 
-    if ( !pl1tab && !ppg )
-        return 0;
-
     for ( l1tab = NULL; !rc && nr--; )
     {
         l2_pgentry_t *pl2e = l2tab + l2_table_offset(va);
@@ -6273,26 +6294,19 @@ int create_perdomain_mapping(struct domain *d, unsigned long va,
                 rc = -ENOMEM;
                 break;
             }
-            if ( pl1tab && !IS_NIL(pl1tab) )
-            {
-                ASSERT(!pl1tab[l2_table_offset(va)]);
-                pl1tab[l2_table_offset(va)] = l1tab;
-            }
             clear_page(l1tab);
             *pl2e = l2e_from_mfn(virt_to_mfn(l1tab), __PAGE_HYPERVISOR_RW);
         }
         else if ( !l1tab )
             l1tab = maddr_to_virt(l2e_get_paddr(*pl2e));
 
-        if ( ppg &&
+        if ( populate &&
              !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) )
         {
             pg = alloc_domheap_page(d, MEMF_no_owner);
             if ( pg )
             {
                 clear_domain_page(page_to_mfn(pg));
-                if ( !IS_NIL(ppg) )
-                    *ppg++ = pg;
                 l1tab[l1_table_offset(va)] =
                     l1e_from_page(pg, __PAGE_HYPERVISOR_RW | _PAGE_AVAIL0);
                 l2e_add_flags(*pl2e, _PAGE_AVAIL0);
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 35d1761c9c..15a8238aff 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -314,9 +314,7 @@ int switch_compat(struct domain *d)
 static int pv_create_gdt_ldt_l1tab(struct vcpu *v)
 {
     return create_perdomain_mapping(v->domain, GDT_VIRT_START(v),
-                                    1U << GDT_LDT_VCPU_SHIFT,
-                                    NIL(l1_pgentry_t *),
-                                    NULL);
+                                    1U << GDT_LDT_VCPU_SHIFT, false);
 }
 
 static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 8eadab7933..ffeda06e08 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -733,8 +733,7 @@ void __init zap_low_mappings(void)
 int setup_compat_arg_xlat(struct vcpu *v)
 {
     return create_perdomain_mapping(v->domain, ARG_XLAT_START(v),
-                                    PFN_UP(COMPAT_ARG_XLAT_SIZE),
-                                    NULL, NIL(struct page_info *));
+                                    PFN_UP(COMPAT_ARG_XLAT_SIZE), true);
 }
 
 void free_compat_arg_xlat(struct vcpu *v)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 21 04:13:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 04:13:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397072.1634556 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxGd2-0004Ow-3d; Fri, 21 Aug 2026 04:13:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397072.1634556; Fri, 21 Aug 2026 04:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxGd1-0004Oo-Ue; Fri, 21 Aug 2026 04:13:15 +0000
Received: by outflank-mailman (input) for mailman id 1397072;
 Fri, 21 Aug 2026 04:13:14 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mhklinux@outlook.com>) id 1wxGcz-0004Oi-TR
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 04:13:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxGcx-00AhyR-Vp
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 06:13:11 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mhklinux@outlook.com>)
 id 6a87d022-bab6-0a2a0a5309dd-0a2a45079f9a-18
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 06:13:11 +0200
Received: from [52.103.1.0] (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mhklinux@outlook.com>)
 id 6a87d056-b4ea-0a2a45070019-34670100c77b-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 06:13:11 +0200
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by SA1PR02MB9758.namprd02.prod.outlook.com (2603:10b6:806:373::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Fri, 21 Aug
 2026 04:13:06 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%3]) with mapi id 15.21.0339.008; Fri, 21 Aug 2026
 04:13:06 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=outlook.com header.i="@outlook.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=faf6PAn6grplnPPA8bsRN9eBcLQa23f1cRjb8HLUEBwqgJY23EOl8XjBH+qFphKFlVF0tLN/F5wyLoRuFxk/cw9fV+/vBdJs3iyYJQUDA/itQgovYbvWaZSChMaSYKBzLLYrStKwrSP+lQ8jaWH7WZZgjQfQyAg8WX/ZBGzvnhatAYPNwOsVUfO0Xm6W573uAeIEesMbjrbVBFG3JEsh8X6V82EW3mao3ahHkr/9rhWgf5r1zhtwjUaWN37mz5DEGgKoxsNyhIt3CquyeCWx+9HYzroJOXAJY3K8FrMFRsmMvHhHLbN29Dx6VYYbiahDIy2Kmxj6U/3MIJfh2tAE7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZFO8zrhqtB66cXJ33SuIgQV5/DBxessQoz1LFr6UcfM=;
 b=Kyc8TaG1qr343TKoVJdVFeHFQ7p1BpUq3nnDVGmEfif1SpIFcnUnOmG3o4ql+sLFIS1qWgN7zR14Of7ykIYKe30JJVChgvZc1zXSoc9XAa7brAdY5ye42bFlc/6hQadLnt5KL56nfM6hWB7Qm0XGka0gJtU3s5ZyTxAgyRJzM9I074tnI06++rLDzr7SU+6kZbE5jE9DgFaSbtud6Z5igW8+9NTVQ49/sLhqeuw2gM+xfsYPrc/KZ4heDyn/jzH3ofn8Py2beSCrG4f0/oY8kTX/2BD7lgX7M9X8+PxCKqKKaKFj4ZJXs2zF7ffFPQbmrX9tnDQk2nPmYNV0xth69Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZFO8zrhqtB66cXJ33SuIgQV5/DBxessQoz1LFr6UcfM=;
 b=n9paxuXBIzPpMMrgaqCD794zank0ubKqBqfwTSpoKIvYuz4720XKS5YLZotrj1aE4TBg4PmCbrkr4JBGCt09/36t3cirkM49LcL12a185JqsaTRyQrAO4SkfzdPQBpNzyca7vg0DwJSV4jyqUwrkr+FaeKakDRC1dERSyqA8wLD2CjD0GUnbddAKSnrEHlupzgXA/2uJcFOmw0008EB/sEb6A4D8vXc5Cinxqr051u5GFHZzvjrB0fYfZH0PITsJKLcjFtREvTiwuTQflcWiRybeQdyGAn44FKXxTT5QUTby+dE6Vsnk4lt2GNQuDjk4d32FnMkvtCax9ct5IYEqGg==
From: Michael Kelley <mhklinux@outlook.com>
To: Juergen Gross <jgross@suse.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>,
	"linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "virtualization@lists.linux.dev"
	<virtualization@lists.linux.dev>, "linux-edac@vger.kernel.org"
	<linux-edac@vger.kernel.org>, "linux-pci@vger.kernel.org"
	<linux-pci@vger.kernel.org>, "linux-pm@vger.kernel.org"
	<linux-pm@vger.kernel.org>, "linux-coco@lists.linux.dev"
	<linux-coco@lists.linux.dev>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>, "linux-ide@vger.kernel.org"
	<linux-ide@vger.kernel.org>, "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>, "linux-crypto@vger.kernel.org"
	<linux-crypto@vger.kernel.org>, "linux-gpio@vger.kernel.org"
	<linux-gpio@vger.kernel.org>, "linux-hwmon@vger.kernel.org"
	<linux-hwmon@vger.kernel.org>, "linux-mtd@lists.infradead.org"
	<linux-mtd@lists.infradead.org>, "platform-driver-x86@vger.kernel.org"
	<platform-driver-x86@vger.kernel.org>, "linux-fbdev@vger.kernel.org"
	<linux-fbdev@vger.kernel.org>
CC: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>, Namhyung Kim
	<namhyung@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander
 Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>,
	Ian Rogers <irogers@google.com>, Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>, "K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, Dexuan
 Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>, Sean
 Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Ajay
 Kaher <ajay.kaher@broadcom.com>, Alexey Makhalov
	<alexey.makhalov@broadcom.com>, Broadcom internal kernel review list
	<bcm-kernel-feedback-list@broadcom.com>, Josh Poimboeuf
	<jpoimboe@kernel.org>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, Pu
 Wen <puwen@hygon.cn>, Tony Luck <tony.luck@intel.com>, Reinette Chatre
	<reinette.chatre@intel.com>, Dave Martin <Dave.Martin@arm.com>, James Morse
	<james.morse@arm.com>, Babu Moger <babu.moger@amd.com>, Tony W Wang-oc
	<TonyWWang-oc@zhaoxin.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Andy
 Lutomirski <luto@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, "Rafael J.
 Wysocki" <rafael@kernel.org>, Pavel Machek <pavel@kernel.org>, Kiryl
 Shutsemau <kas@kernel.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>, Len Brown <lenb@kernel.org>,
	Damien Le Moal <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>, David
 Airlie <airlied@redhat.com>, Olivia Mackall <olivia@selenic.com>, Herbert Xu
	<herbert@gondor.apana.org.au>, Viresh Kumar <viresh.kumar@linaro.org>, Huang
 Rui <ray.huang@amd.com>, Mario Limonciello <mario.limonciello@amd.com>, Perry
 Yuan <perry.yuan@amd.com>, K Prateek Nayak <kprateek.nayak@amd.com>, Srinivas
 Pandruvada <srinivas.pandruvada@linux.intel.com>, Yazen Ghannam
	<yazen.ghannam@amd.com>, Linus Walleij <linusw@kernel.org>, Bartosz
 Golaszewski <brgl@kernel.org>, Guenter Roeck <linux@roeck-us.net>, Artem
 Bityutskiy <artem.bityutskiy@linux.intel.com>, Artem Bityutskiy
	<dedekind1@gmail.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman
	<gregkh@linuxfoundation.org>, Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>,
	Ashok Raj <ashok.raj.linux@gmail.com>, Hans de Goede <hansg@kernel.org>,
	=?utf-8?B?SWxwbyBKw6RydmluZW4=?= <ilpo.jarvinen@linux.intel.com>, Rajneesh
 Bhardwaj <irenic.rajneesh@gmail.com>, David E Box <david.e.box@intel.com>,
	Daniel Lezcano <daniel.lezcano@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>, Helge Deller <deller@gmx.de>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-geode@lists.infradead.org" <linux-geode@lists.infradead.org>
Subject: RE: [PATCH v2 12/13] treewide: convert rdmsrq() from a macro to an
 inline function
Thread-Topic: [PATCH v2 12/13] treewide: convert rdmsrq() from a macro to an
 inline function
Thread-Index: AQINTp4TPtSs6ebCNDDLlaH1nXSnpAH3JEcqtjc5VeA=
Date: Fri, 21 Aug 2026 04:13:05 +0000
Message-ID:
 <SN6PR02MB4157769F2FAEB7D78259164ED4A32@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260819102314.1499258-1-jgross@suse.com>
 <20260819102314.1499258-13-jgross@suse.com>
In-Reply-To: <20260819102314.1499258-13-jgross@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|SA1PR02MB9758:EE_
x-ms-office365-filtering-correlation-id: 0eaa3b97-02b3-491e-1f8c-08deff3a8045
x-microsoft-antispam:
 BCL:0;ARA:14566002|41001999006|25010399006|4140399003|8062599012|31061999003|24021099003|8060799015|37011999003|19110799012|15080799012|55001999006|13091999003|440099028|3412199025|102099032|31055399003|52005399003|40105399003|2607281247196008;
x-microsoft-antispam-message-info:
 =?utf-8?B?VE5jb3pZT3lrd3UvVklPb0ZabFZoczZDTTJGM2VaWFlLSkxEb0kwZUtpTGs4?=
 =?utf-8?B?RjRjVXBBTzdtcHA2aGdoN3dVRGtyT2c1bGNTT0dBSExNSDVFbWJwRHNqUnBR?=
 =?utf-8?B?NUxSUjI0QlAyZlRYd3M4WVNEN0xaT0kxVE1CeHk5MElwdHdSUlQ3d3g3YytC?=
 =?utf-8?B?VjN0RElNWjRrZ3ZWY2R4S251MEhZdzFWdWo5a0RkMVRCUGZCS2RvQVMxdjRp?=
 =?utf-8?B?T1dLQ0tWbFBTVnpTeUFabnhKZktaYkdNRWJjd00wRjN2VjZDZ3d6WkE0d2w4?=
 =?utf-8?B?QlBMZFIzUGlSbGR6Vk8xQVNkNVZSaTQvNERSMDJOZUdWSXJuSHE0NXBFZFoz?=
 =?utf-8?B?MHhTaW5KL01QV2grYTdad3Rqb0crdk1OMVAwUHZBbjNiVmpPU09nQnBkd2NT?=
 =?utf-8?B?M1BBeTV1ZXQ0SDZud0pvbEdxc2pSV05HbUN3aWNodTN1bndDRTdzeGhlUjhv?=
 =?utf-8?B?eGlxZ296MXZjTTU1WmtZWU5zbFpnRysydmlnb0xwZm9RZ3NjV1dWeVYzNUFD?=
 =?utf-8?B?U3RSNWJBUDdvZThxWkZwcTVDVGN3dmxoNEJmVVo2UW5qMEhzdFVBNXMzTlpt?=
 =?utf-8?B?aU1VMThWdFc0V293R2V0Z1RWYW5ZeEhEZjBJZk5IeW9kRFVId0tyKzF3TDFN?=
 =?utf-8?B?THRxY3pVREVBeFVGSVl2RFhOYUNCRnlTR1dCYkNqdDZ1OG8wN3NBRnBZeVB6?=
 =?utf-8?B?YUorOWVhRHhFWFlHTFJuYmtIeGU3OU1rblhVOHkvZVZhcTJBcVRCWjBPRE5w?=
 =?utf-8?B?L011MEZIbE9hK0dGdkQxVm0xVUZ0dFcyRG5wMCs2cEZidUt3U1VDUWhLQVdk?=
 =?utf-8?B?alFKUkxrZUhpL2t1cTBDYUZ4T1YvN0dpU0tDSXB5ZDdDUmViZFk4UGNTQXRm?=
 =?utf-8?B?VWJZTkNSVitHL3h4c3NVM2RuKyswRVhFSURoa2U1bTFOY3Z5d1hCczMralF2?=
 =?utf-8?B?WUpaQUpmWHlDWkxrd3NsZ3Zia3ozdnBVU0M2MmNrT2xNUWorRGxOVzhnQnI1?=
 =?utf-8?B?My9xbE1qUmNTOE5YdmxLUXJFZkhJcTdNVkdhZzRsV0J6MDFieXVCeFdKWEdC?=
 =?utf-8?B?OEluWGRYUTIxNVZNVDg1L3ovbzBiSzR5U29iWXdzeTlIakZUUi9PVDF5Ri9T?=
 =?utf-8?B?NHAvSU14WE9SS3VENDMyVElBWmxnU0dZL1BZWHZMenYrY3pXdXY3V3J5N0o0?=
 =?utf-8?B?ZUdrUUJLU1VHRi9qSUZYMWJJM3pGMkZCZnZHTE9FbjFMay90UzU0NkVqVVJP?=
 =?utf-8?B?Wlh3WlBxVlJNcGZQdWd6ZmhIWEhLSmxVUVYwWVVvSEVnRFZRUzJBNkVabEhZ?=
 =?utf-8?B?WkpUSDlvRk55L3RoM1BkNG1BWjNteTk4eG5IczQ3KzJyUkJRb1FJdW1KeGt2?=
 =?utf-8?B?TjhXcWVVditaKy8rdVUzb0JIV2VpbTRlOTg2UEd1T3RHRGg4QUtHZno2d1o0?=
 =?utf-8?B?eldwb3NJQUVNSTIyZHcvRnpPYzZha1RqR0QrSHlpNlo0em1TY2l5VHo3Nm5B?=
 =?utf-8?Q?y0IhSY=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?QmM3eFlkSHNPYWVSaWpRaDVqT2g3dE5Edk9DUnVvSVc2aTZPTVprd2VGYUdx?=
 =?utf-8?B?LzFsRW1hODBnZmVwUGExU3Ftc21jYlZBbDk2Z2pTVjFSYlhFY1ZrTmZTc3Fp?=
 =?utf-8?B?RTNQTHlBZC9jZit0NHVkV1pjQTZtU1hiK0lhank3cUl4a21BYUdKNkw3NFNn?=
 =?utf-8?B?aStuMk1uYytLNGlSRUxDc2NoWWJkR2ZiOUYxRkJ3OFpMUHZRaHFCcUJjS2Vv?=
 =?utf-8?B?V1B3Rmd5bll2Uk1FcUdpZ1pIQU93S3VsVmM2VXlORURwbm1Od2pQYkkzWUxJ?=
 =?utf-8?B?ZU9aMG9UbTk4V2ErVXhCQVAzRTZIV3FEZ0N4L3IzUVZIRFl1TndVdG1pQmhP?=
 =?utf-8?B?SnUyZjE5Q2l4dDVXbXBMOEJibDl2TUgweURkMjFyL3ZTOTc1QUlaTFhUa01q?=
 =?utf-8?B?THMvS3ordk8zYzR2MnBHR1I0Z1M2YmwweE9kWEF2Y3RmRFJ4clhvaWFhRUdr?=
 =?utf-8?B?UmtHSlVxUzBrRFByN0pwUHAyaEFTUmVrLy92Q1VjRytpZTA2b3dnTTB1ZEU5?=
 =?utf-8?B?VExNeVA1cHBabHo3dXFVajJUb1c5RVFFUjZuRWRVU1ZpdHZyN1Ura1VVWDB3?=
 =?utf-8?B?NDN6T3g3aHU5Mm1wMHFFWkgxNWVXTHI1blNPSEVZWkhQL0xXcXVMVEE0SE8x?=
 =?utf-8?B?Z0FUUWNkdkJDNko3VEh3K0dOV1dyK1c4WU9NYzd2SUVralUyczFRWlplSUlj?=
 =?utf-8?B?M3pWdW9pc1RzZ25ya0dXMjRUZnpaOUpNYWJycmllWHBRMUgyNncxNWg4d2Fw?=
 =?utf-8?B?MndtWHQvWlhkaXVmUTBSN014VFlvNkxKb0xjaWFtUTJTdGhyY2R5N25YaERK?=
 =?utf-8?B?aEJkK1VheE9wNEZYOW5KY2h0Ty9TNllaRXhFWkw0cnlpMUsvYUROVkVHWUdH?=
 =?utf-8?B?QkZYZXZwZCs2bUNqNkp1ZndVdGl1ZjlsaW5OYmhKSmlkMExqejdlQjkwcy91?=
 =?utf-8?B?ZEdYOVNSREx3NUJBZHBuc2RkWnJ5OVRNYndxNC9YM2hSRzBKSjVFL2swZkt0?=
 =?utf-8?B?K1NSQlRvaEhvU2tmVysxc1dWcXZ5bnhoTlZEUHA5UVFLZzJ1YUg3aTcrN0NK?=
 =?utf-8?B?VUFXUkJPZ0hhejRGNFY2ZndQMWhzOXk2cDZYTFlHNTNjUnI0cjg5cmJsTXc3?=
 =?utf-8?B?MExzT0o0ZFVEeG9xU2dxS2wwVytjSDRrenJjL05Ncnp3bmF3L2lPZkxETWtD?=
 =?utf-8?B?YzRydFB6ZlZ0VjdwdGlVY3h2bm1MeXh3UjZQQTVabkxScU00UVB0dXYwcHVG?=
 =?utf-8?B?R2s0TGFNMEFuV1ZmMlp4c0lLQXBJemFOMmhjZ2lEMXJ2Z1BIVFJLRFV3UHNz?=
 =?utf-8?B?UHVvc3F4MTBEOGxEZlhVYWdXM0ttaDk1TEVUaU1Yb3pKOWxoODEwYzFha0JR?=
 =?utf-8?B?UDRxZnNlaXJmZm54bWZ2a3VCdHRmVXFvR2lZOXBuR0htN0gzUFJKdDdXbHEy?=
 =?utf-8?B?YjJIRnMzRzRJQW5LUjYxSFFIU0cxbU8zc1l4TDltV1psc2dKMkkySHN0VU1h?=
 =?utf-8?B?QXcrNThabVU3cFFBOCtneVNDbHkxQXdjUzQ4N2M4NzlDQWZmUjcvNS9OYWFt?=
 =?utf-8?B?dEF1dkorcm90ZzZZQkJjQjJWMjFyYVZvZ2V0OHhWdDk4Lzd5UHAxSU85RUkz?=
 =?utf-8?B?b2d0YlRUZXExN2wrZUVHaC9BdlVWeGM1M2c4Y2F5cjNsQm55TG0vZmVhYnBn?=
 =?utf-8?B?U011azlvWnlOZlFWemJGcXR0bkxRanN0WE5xU1V1UkVwNDlTbFNOYmNqVHFz?=
 =?utf-8?B?MU43c1ZlUG50WnFrM0hZWE5sNEN1U0d6SnRwVEE2Y0RCYkdhK0RNZ1dNMEVi?=
 =?utf-8?Q?NBDvWmZW+2kzq14/wMMlZbp8tNDkCgF/8lz/s=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0eaa3b97-02b3-491e-1f8c-08deff3a8045
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2026 04:13:05.8171
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR02MB9758
X-purgate-ID: tlsNG-ef75cf/1787285591-A74D3AE4-CB4A36F8/0/0
X-purgate-type: clean
X-purgate-size: 21906

RnJvbTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPiBTZW50OiBXZWRuZXNkYXksIEF1
Z3VzdCAxOSwgMjAyNiAzOjIzIEFNDQo+IA0KPiBUb2RheSByZG1zcnEoKSBpcyBhIG1hY3JvIHVz
aW5nIGl0cyBzZWNvbmQgcGFyYW1ldGVyIGFzIHRoZSB0YXJnZXQgZm9yDQo+IHN0b3JpbmcgdGhl
IHJlYWQgTVNSIHZhbHVlLg0KPiANCj4gQ29udmVydCByZG1zcnEoKSB0byBhbiBpbmxpbmUgZnVu
Y3Rpb24gcmV0dXJuaW5nIHRoZSBNU1IgdmFsdWUuDQo+IA0KPiBUaGUgdXNlcnMgaGF2ZSBiZWVu
IGNvbnZlcnRlZCB1c2luZyB0aGUgZm9sbG93aW5nIHNlbWFudGljIHBhdGNoOg0KPiANCj4gICAv
LyBPcHRpb25zOiAtLWluY2x1ZGUtaGVhZGVycw0KPiANCj4gICB2aXJ0dWFsIHBhdGNoDQo+ICAg
dmlydHVhbCByZXBvcnQNCj4gDQo+ICAgQEANCj4gICBleHByZXNzaW9uIG1zciwgdmFsOw0KPiAg
IEBADQo+ICAgKA0KPiAgIC0gcmRtc3JxKG1zcix2YWwpDQo+ICAgKyB2YWwgPSByZG1zcnEobXNy
KQ0KPiAgICkNCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNl
LmNvbT4NCj4gLS0tDQo+ICBhcmNoL3g4Ni9jb2NvL3Nldi9jb3JlLmMgICAgICAgICAgICAgICAg
ICAgICAgfCAgMiArLQ0KPiAgYXJjaC94ODYvZXZlbnRzL2FtZC9icnMuYyAgICAgICAgICAgICAg
ICAgICAgIHwgIDQgKy0tDQo+ICBhcmNoL3g4Ni9ldmVudHMvYW1kL2NvcmUuYyAgICAgICAgICAg
ICAgICAgICAgfCAgNCArLS0NCj4gIGFyY2gveDg2L2V2ZW50cy9hbWQvaWJzLmMgICAgICAgICAg
ICAgICAgICAgICB8IDE4ICsrKysrLS0tLS0NCj4gIGFyY2gveDg2L2V2ZW50cy9hbWQvbGJyLmMg
ICAgICAgICAgICAgICAgICAgICB8ICA4ICsrLS0tDQo+ICBhcmNoL3g4Ni9ldmVudHMvYW1kL3Bv
d2VyLmMgICAgICAgICAgICAgICAgICAgfCAgOCArKy0tLQ0KPiAgYXJjaC94ODYvZXZlbnRzL2Ft
ZC91bmNvcmUuYyAgICAgICAgICAgICAgICAgIHwgIDQgKy0tDQo+ICBhcmNoL3g4Ni9ldmVudHMv
Y29yZS5jICAgICAgICAgICAgICAgICAgICAgICAgfCAyMCArKysrKy0tLS0tLQ0KPiAgYXJjaC94
ODYvZXZlbnRzL2ludGVsL2NvcmUuYyAgICAgICAgICAgICAgICAgIHwgMTEgKysrLS0tDQo+ICBh
cmNoL3g4Ni9ldmVudHMvaW50ZWwvY3N0YXRlLmMgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAg
YXJjaC94ODYvZXZlbnRzL2ludGVsL2RzLmMgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4g
IGFyY2gveDg2L2V2ZW50cy9pbnRlbC9rbmMuYyAgICAgICAgICAgICAgICAgICB8ICA2ICsrLS0N
Cj4gIGFyY2gveDg2L2V2ZW50cy9pbnRlbC9sYnIuYyAgICAgICAgICAgICAgICAgICB8IDE0ICsr
KystLS0tDQo+ICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvcDQuYyAgICAgICAgICAgICAgICAgICAg
fCAgNiArKy0tDQo+ICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvcDYuYyAgICAgICAgICAgICAgICAg
ICAgfCAgNCArLS0NCj4gIGFyY2gveDg2L2V2ZW50cy9pbnRlbC9wdC5jICAgICAgICAgICAgICAg
ICAgICB8IDEyICsrKy0tLS0NCj4gIGFyY2gveDg2L2V2ZW50cy9pbnRlbC91bmNvcmUuYyAgICAg
ICAgICAgICAgICB8ICAyICstDQo+ICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvdW5jb3JlX25obWV4
LmMgICAgICAgICAgfCAgNCArLS0NCj4gIGFyY2gveDg2L2V2ZW50cy9pbnRlbC91bmNvcmVfc25i
LmMgICAgICAgICAgICB8ICAyICstDQo+ICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvdW5jb3JlX3Nu
YmVwLmMgICAgICAgICAgfCAgNiArKy0tDQo+ICBhcmNoL3g4Ni9ldmVudHMvbXNyLmMgICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAgYXJjaC94ODYvZXZlbnRzL3BlcmZfZXZlbnQu
aCAgICAgICAgICAgICAgICAgIHwgIDYgKystLQ0KPiAgYXJjaC94ODYvZXZlbnRzL3JhcGwuYyAg
ICAgICAgICAgICAgICAgICAgICAgIHwgIDQgKy0tDQo+ICBhcmNoL3g4Ni9ldmVudHMvemhhb3hp
bi9jb3JlLmMgICAgICAgICAgICAgICAgfCAgNiArKy0tDQo+ICBhcmNoL3g4Ni9oeXBlcnYvaHZf
YXBpYy5jICAgICAgICAgICAgICAgICAgICAgfCAgNiArKy0tDQo+ICBhcmNoL3g4Ni9oeXBlcnYv
aHZfaW5pdC5jICAgICAgICAgICAgICAgICAgICAgfCAyNiArKysrKysrLS0tLS0tLQ0KPiAgYXJj
aC94ODYvaHlwZXJ2L2h2X3NwaW5sb2NrLmMgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gIGFy
Y2gveDg2L2luY2x1ZGUvYXNtL2FwaWMuaCAgICAgICAgICAgICAgICAgICB8ICA0ICstLQ0KPiAg
YXJjaC94ODYvaW5jbHVkZS9hc20vZGVidWdyZWcuaCAgICAgICAgICAgICAgIHwgIDIgKy0NCj4g
IGFyY2gveDg2L2luY2x1ZGUvYXNtL2ZzZ3NiYXNlLmggICAgICAgICAgICAgICB8ICAyICstDQo+
ICBhcmNoL3g4Ni9pbmNsdWRlL2FzbS9rdm1faG9zdC5oICAgICAgICAgICAgICAgfCAgMiArLQ0K
PiAgYXJjaC94ODYvaW5jbHVkZS9hc20vbXNyLmggICAgICAgICAgICAgICAgICAgIHwgMTUgKysr
Ky0tLS0NCj4gIGFyY2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0LmggICAgICAgICAgICAgICB8
ICA4ICsrLS0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvYXBpYy9hcGljLmMgICAgICAgICAgICAgICAg
ICAgfCAxNCArKysrLS0tLQ0KPiAgYXJjaC94ODYva2VybmVsL2FwaWMvYXBpY19udW1hY2hpcC5j
ICAgICAgICAgIHwgIDYgKystLQ0KPiAgYXJjaC94ODYva2VybmVsL2NldC5jICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgIDIgKy0NCj4gIGFyY2gveDg2L2tlcm5lbC9jcHUvYW1kLmMgICAgICAg
ICAgICAgICAgICAgICB8IDE0ICsrKystLS0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvY3B1L2FwZXJm
bXBlcmYuYyAgICAgICAgICAgICAgfCAgOCArKy0tLQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS9i
dWdzLmMgICAgICAgICAgICAgICAgICAgIHwgMTIgKysrLS0tLQ0KPiAgYXJjaC94ODYva2VybmVs
L2NwdS9idXNfbG9jay5jICAgICAgICAgICAgICAgIHwgIDggKystLS0NCj4gIGFyY2gveDg2L2tl
cm5lbC9jcHUvY2VudGF1ci5jICAgICAgICAgICAgICAgICB8ICA4ICsrLS0tDQo+ICBhcmNoL3g4
Ni9rZXJuZWwvY3B1L2NvbW1vbi5jICAgICAgICAgICAgICAgICAgfCAxMiArKystLS0tDQo+ICBh
cmNoL3g4Ni9rZXJuZWwvY3B1L2ZlYXRfY3RsLmMgICAgICAgICAgICAgICAgfCAgNCArLS0NCj4g
IGFyY2gveDg2L2tlcm5lbC9jcHUvaHlnb24uYyAgICAgICAgICAgICAgICAgICB8ICA0ICstLQ0K
PiAgYXJjaC94ODYva2VybmVsL2NwdS9pbnRlbC5jICAgICAgICAgICAgICAgICAgIHwgIDYgKyst
LQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS9pbnRlbF9lcGIuYyAgICAgICAgICAgICAgIHwgIDQg
Ky0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvY3B1L21jZS9hbWQuYyAgICAgICAgICAgICAgICAgfCAg
NCArLS0NCj4gIGFyY2gveDg2L2tlcm5lbC9jcHUvbWNlL2NvcmUuYyAgICAgICAgICAgICAgICB8
ICA4ICsrLS0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvY3B1L21jZS9pbmplY3QuYyAgICAgICAgICAg
ICAgfCAgMiArLQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS9tY2UvaW50ZWwuYyAgICAgICAgICAg
ICAgIHwgMTggKysrKystLS0tLQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS9tY2UvcDUuYyAgICAg
ICAgICAgICAgICAgIHwgIDggKystLS0NCj4gIGFyY2gveDg2L2tlcm5lbC9jcHUvbWNlL3dpbmNo
aXAuYyAgICAgICAgICAgICB8ICAyICstDQo+ICBhcmNoL3g4Ni9rZXJuZWwvY3B1L21pY3JvY29k
ZS9pbnRlbC5jICAgICAgICAgfCAgMiArLQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS9tc2h5cGVy
di5jICAgICAgICAgICAgICAgIHwgIDYgKystLQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS9tdHJy
L2FtZC5jICAgICAgICAgICAgICAgIHwgIDQgKy0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvY3B1L210
cnIvY2xlYW51cC5jICAgICAgICAgICAgfCAgNCArLS0NCj4gIGFyY2gveDg2L2tlcm5lbC9jcHUv
bXRyci9nZW5lcmljLmMgICAgICAgICAgICB8IDMyICsrKysrKysrLS0tLS0tLS0tDQo+ICBhcmNo
L3g4Ni9rZXJuZWwvY3B1L210cnIvbXRyci5jICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAgYXJj
aC94ODYva2VybmVsL2NwdS9yZXNjdHJsL2NvcmUuYyAgICAgICAgICAgIHwgIDIgKy0NCj4gIGFy
Y2gveDg2L2tlcm5lbC9jcHUvcmVzY3RybC9tb25pdG9yLmMgICAgICAgICB8ICA0ICstLQ0KPiAg
YXJjaC94ODYva2VybmVsL2NwdS9yZXNjdHJsL3BzZXVkb19sb2NrLmMgICAgIHwgIDQgKy0tDQo+
ICBhcmNoL3g4Ni9rZXJuZWwvY3B1L3Jlc2N0cmwvcmR0Z3JvdXAuYyAgICAgICAgfCAgMiArLQ0K
PiAgYXJjaC94ODYva2VybmVsL2NwdS90b3BvbG9neS5jICAgICAgICAgICAgICAgIHwgIDIgKy0N
Cj4gIGFyY2gveDg2L2tlcm5lbC9jcHUvdG9wb2xvZ3lfYW1kLmMgICAgICAgICAgICB8ICA0ICst
LQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS90cmFuc21ldGEuYyAgICAgICAgICAgICAgIHwgIDIg
Ky0NCj4gIGFyY2gveDg2L2tlcm5lbC9jcHUvdHN4LmMgICAgICAgICAgICAgICAgICAgICB8IDEw
ICsrKy0tLQ0KPiAgYXJjaC94ODYva2VybmVsL2NwdS91bXdhaXQuYyAgICAgICAgICAgICAgICAg
IHwgIDIgKy0NCj4gIGFyY2gveDg2L2tlcm5lbC9jcHUvemhhb3hpbi5jICAgICAgICAgICAgICAg
ICB8ICA0ICstLQ0KPiAgYXJjaC94ODYva2VybmVsL2ZwdS9jb3JlLmMgICAgICAgICAgICAgICAg
ICAgIHwgIDIgKy0NCj4gIGFyY2gveDg2L2tlcm5lbC9ocGV0LmMgICAgICAgICAgICAgICAgICAg
ICAgICB8ICAyICstDQo+ICBhcmNoL3g4Ni9rZXJuZWwva3ZtLmMgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgMiArLQ0KPiAgYXJjaC94ODYva2VybmVsL21tY29uZi1mYW0xMGhfNjQuYyAgICAg
ICAgICAgIHwgIDYgKystLQ0KPiAgYXJjaC94ODYva2VybmVsL3Byb2Nlc3MuYyAgICAgICAgICAg
ICAgICAgICAgIHwgIDQgKy0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvcHJvY2Vzc182NC5jICAgICAg
ICAgICAgICAgICAgfCAxNCArKysrLS0tLQ0KPiAgYXJjaC94ODYva2VybmVsL3Noc3RrLmMgICAg
ICAgICAgICAgICAgICAgICAgIHwgIDggKystLS0NCj4gIGFyY2gveDg2L2tlcm5lbC90cmFwcy5j
ICAgICAgICAgICAgICAgICAgICAgICB8ICA0ICstLQ0KPiAgYXJjaC94ODYva2VybmVsL3RzYy5j
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gIGFyY2gveDg2L2tlcm5lbC90c2Nf
bXNyLmMgICAgICAgICAgICAgICAgICAgICB8ICA2ICsrLS0NCj4gIGFyY2gveDg2L2tlcm5lbC90
c2Nfc3luYy5jICAgICAgICAgICAgICAgICAgICB8ICA2ICsrLS0NCj4gIGFyY2gveDg2L2t2bS9z
dm0vcG11LmMgICAgICAgICAgICAgICAgICAgICAgICB8ICA0ICstLQ0KPiAgYXJjaC94ODYva3Zt
L3N2bS9zdm0uYyAgICAgICAgICAgICAgICAgICAgICAgIHwgIDQgKy0tDQo+ICBhcmNoL3g4Ni9r
dm0vdm14L25lc3RlZC5jICAgICAgICAgICAgICAgICAgICAgfCAgNCArLS0NCj4gIGFyY2gveDg2
L2t2bS92bXgvcG11X2ludGVsLmMgICAgICAgICAgICAgICAgICB8ICA4ICsrLS0tDQo+ICBhcmNo
L3g4Ni9rdm0vdm14L3NneC5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgNiArKy0tDQo+ICBh
cmNoL3g4Ni9rdm0vdm14L3ZteC5jICAgICAgICAgICAgICAgICAgICAgICAgfCAzNiArKysrKysr
KystLS0tLS0tLS0tDQo+ICBhcmNoL3g4Ni9rdm0veDg2LmMgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgOCArKy0tLQ0KPiAgYXJjaC94ODYvbGliL2luc24tZXZhbC5jICAgICAgICAgICAg
ICAgICAgICAgIHwgIDYgKystLQ0KPiAgYXJjaC94ODYvbGliL21zci1zbXAuYyAgICAgICAgICAg
ICAgICAgICAgICAgIHwgIDIgKy0NCj4gIGFyY2gveDg2L21tL3BhdC9tZW10eXBlLmMgICAgICAg
ICAgICAgICAgICAgICB8ICAyICstDQo+ICBhcmNoL3g4Ni9wY2kvYW1kX2J1cy5jICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgOCArKy0tLQ0KPiAgYXJjaC94ODYvcGxhdGZvcm0vb2xwYy9vbHBj
LXhvMS1ydGMuYyAgICAgICAgIHwgIDYgKystLQ0KPiAgYXJjaC94ODYvcGxhdGZvcm0vb2xwYy9v
bHBjLXhvMS1zY2kuYyAgICAgICAgIHwgIDIgKy0NCj4gIGFyY2gveDg2L3Bvd2VyL2NwdS5jICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IDEwICsrKy0tLQ0KPiAgYXJjaC94ODYvcmVhbG1vZGUv
aW5pdC5jICAgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gIGFyY2gveDg2L3ZpcnQvaHcu
YyAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICA4ICsrLS0tDQo+ICBhcmNoL3g4Ni92aXJ0
L3N2bS9zZXYuYyAgICAgICAgICAgICAgICAgICAgICAgfCAxOCArKysrKy0tLS0tDQo+ICBhcmNo
L3g4Ni92aXJ0L3ZteC90ZHgvdGR4LmMgICAgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAgYXJj
aC94ODYveGVuL3N1c3BlbmQuYyAgICAgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gIGRy
aXZlcnMvYWNwaS9wcm9jZXNzb3JfcGVyZmxpYi5jICAgICAgICAgICAgICB8ICAyICstDQo+ICBk
cml2ZXJzL2F0YS9wYXRhX2NzNTUzNS5jICAgICAgICAgICAgICAgICAgICAgfCAgNCArLS0NCj4g
IGRyaXZlcnMvYXRhL3BhdGFfY3M1NTM2LmMgICAgICAgICAgICAgICAgICAgICB8ICAyICstDQo+
ICBkcml2ZXJzL2NoYXIvYWdwL252aWRpYS1hZ3AuYyAgICAgICAgICAgICAgICAgfCAgNiArKy0t
DQo+ICBkcml2ZXJzL2NoYXIvaHdfcmFuZG9tL3ZpYS1ybmcuYyAgICAgICAgICAgICAgfCAgNCAr
LS0NCj4gIGRyaXZlcnMvY3B1ZnJlcS9hY3BpLWNwdWZyZXEuYyAgICAgICAgICAgICAgICB8ICA4
ICsrLS0tDQo+ICBkcml2ZXJzL2NwdWZyZXEvYW1kLXBzdGF0ZS5jICAgICAgICAgICAgICAgICAg
fCAgNCArLS0NCj4gIGRyaXZlcnMvY3B1ZnJlcS9lX3Bvd2Vyc2F2ZXIuYyAgICAgICAgICAgICAg
ICB8IDIwICsrKysrLS0tLS0tDQo+ICBkcml2ZXJzL2NwdWZyZXEvaW50ZWxfcHN0YXRlLmMgICAg
ICAgICAgICAgICAgfCAzMCArKysrKysrKy0tLS0tLS0tDQo+ICBkcml2ZXJzL2NwdWZyZXEvbG9u
Z2hhdWwuYyAgICAgICAgICAgICAgICAgICAgfCAxMiArKystLS0tDQo+ICBkcml2ZXJzL2NwdWZy
ZXEvbG9uZ3J1bi5jICAgICAgICAgICAgICAgICAgICAgfCAxNiArKysrLS0tLS0NCj4gIGRyaXZl
cnMvY3B1ZnJlcS9wb3dlcm5vdy1rNy5jICAgICAgICAgICAgICAgICB8IDEwICsrKy0tLQ0KPiAg
ZHJpdmVycy9jcHVmcmVxL3Bvd2Vybm93LWs4LmMgICAgICAgICAgICAgICAgIHwgIDggKystLS0N
Cj4gIGRyaXZlcnMvY3B1ZnJlcS9zcGVlZHN0ZXAtY2VudHJpbm8uYyAgICAgICAgICB8ICA0ICst
LQ0KPiAgZHJpdmVycy9jcHVmcmVxL3NwZWVkc3RlcC1saWIuYyAgICAgICAgICAgICAgIHwgMTQg
KysrKy0tLS0NCj4gIGRyaXZlcnMvZWRhYy9hbWQ2NF9lZGFjLmMgICAgICAgICAgICAgICAgICAg
ICB8ICA2ICsrLS0NCj4gIGRyaXZlcnMvZ3Bpby9ncGlvLWNzNTUzNS5jICAgICAgICAgICAgICAg
ICAgICB8ICAyICstDQo+ICBkcml2ZXJzL2h2L21zaHZfdnRsX21haW4uYyAgICAgICAgICAgICAg
ICAgICAgfCAgMiArLQ0KPiAgZHJpdmVycy9od21vbi9od21vbi12aWQuYyAgICAgICAgICAgICAg
ICAgICAgIHwgIDQgKy0tDQo+ICBkcml2ZXJzL2lkbGUvaW50ZWxfaWRsZS5jICAgICAgICAgICAg
ICAgICAgICAgfCAyNiArKysrKysrLS0tLS0tLQ0KPiAgZHJpdmVycy9taXNjL2NzNTUzNS1tZmdw
dC5jICAgICAgICAgICAgICAgICAgIHwgIDYgKystLQ0KPiAgZHJpdmVycy9tdGQvbmFuZC9yYXcv
Y3M1NTN4X25hbmQuYyAgICAgICAgICAgIHwgIDYgKystLQ0KPiAgZHJpdmVycy9wbGF0Zm9ybS94
ODYvaW50ZWwvaWZzL2xvYWQuYyAgICAgICAgIHwgMTAgKysrLS0tDQo+ICBkcml2ZXJzL3BsYXRm
b3JtL3g4Ni9pbnRlbC9pZnMvcnVudGVzdC5jICAgICAgfCAgOCArKy0tLQ0KPiAgZHJpdmVycy9w
bGF0Zm9ybS94ODYvaW50ZWwvcG1jL2NucC5jICAgICAgICAgIHwgIDIgKy0NCj4gIC4uLi9pbnRl
bC9zcGVlZF9zZWxlY3RfaWYvaXNzdF9pZl9tYm94X21zci5jICB8ICA2ICsrLS0NCj4gIC4uLi9p
bnRlbC9zcGVlZF9zZWxlY3RfaWYvaXNzdF90cG1pX2NvcmUuYyAgICB8ICAyICstDQo+ICBkcml2
ZXJzL3BsYXRmb3JtL3g4Ni9pbnRlbF9pcHMuYyAgICAgICAgICAgICAgfCAyMCArKysrKy0tLS0t
LQ0KPiAgZHJpdmVycy9wb3dlcmNhcC9pbnRlbF9yYXBsX21zci5jICAgICAgICAgICAgIHwgIDIg
Ky0NCj4gIGRyaXZlcnMvdGhlcm1hbC9pbnRlbC9pbnRlbF9oZmkuYyAgICAgICAgICAgICB8ICA4
ICsrLS0tDQo+ICBkcml2ZXJzL3RoZXJtYWwvaW50ZWwvdGhlcm1fdGhyb3QuYyAgICAgICAgICAg
fCAyMiArKysrKystLS0tLS0NCj4gIGRyaXZlcnMvdGhlcm1hbC9pbnRlbC94ODZfcGtnX3RlbXBf
dGhlcm1hbC5jICB8ICA2ICsrLS0NCj4gIGRyaXZlcnMvdmlkZW8vZmJkZXYvZ2VvZGUvZGlzcGxh
eV9neC5jICAgICAgICB8ICAyICstDQo+ICBkcml2ZXJzL3ZpZGVvL2ZiZGV2L2dlb2RlL2d4ZmJf
Y29yZS5jICAgICAgICAgfCAgMiArLQ0KPiAgZHJpdmVycy92aWRlby9mYmRldi9nZW9kZS9seGZi
X29wcy5jICAgICAgICAgIHwgMTggKysrKystLS0tLQ0KPiAgZHJpdmVycy92aWRlby9mYmRldi9n
ZW9kZS9zdXNwZW5kX2d4LmMgICAgICAgIHwgIDggKystLS0NCj4gIGRyaXZlcnMvdmlkZW8vZmJk
ZXYvZ2VvZGUvdmlkZW9fZ3guYyAgICAgICAgICB8ICA4ICsrLS0tDQo+ICBpbmNsdWRlL2xpbnV4
L2NzNTUzNS5oICAgICAgICAgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAgMTM2IGZpbGVzIGNo
YW5nZWQsIDQ4NCBpbnNlcnRpb25zKCspLCA0ODYgZGVsZXRpb25zKC0pDQo+IA0KDQpbc25pcF0N
Cg0KPiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYvaHlwZXJ2L2h2X2FwaWMuYyBiL2FyY2gveDg2L2h5
cGVydi9odl9hcGljLmMNCj4gaW5kZXggOTVmMTc4MmQxZTE3Li40ZTMwZjlhMTFiYzQgMTAwNjQ0
DQo+IC0tLSBhL2FyY2gveDg2L2h5cGVydi9odl9hcGljLmMNCj4gKysrIGIvYXJjaC94ODYvaHlw
ZXJ2L2h2X2FwaWMuYw0KPiBAQCAtMzgsNyArMzgsNyBAQCBzdGF0aWMgdTY0IGh2X2FwaWNfaWNy
X3JlYWQodm9pZCkNCj4gIHsNCj4gIAl1NjQgcmVnX3ZhbDsNCj4gDQo+IC0JcmRtc3JxKEhWX1g2
NF9NU1JfSUNSLCByZWdfdmFsKTsNCj4gKwlyZWdfdmFsID0gcmRtc3JxKEhWX1g2NF9NU1JfSUNS
KTsNCj4gIAlyZXR1cm4gcmVnX3ZhbDsNCj4gIH0NCj4gDQo+IEBAIC02NCwxMCArNjQsMTAgQEAg
c3RhdGljIHUzMiBodl9hcGljX3JlYWQodTMyIHJlZykNCj4gDQo+ICAJc3dpdGNoIChyZWcpIHsN
Cj4gIAljYXNlIEFQSUNfRU9JOg0KPiAtCQlyZG1zcnEoSFZfWDY0X01TUl9FT0ksIHJlZ192YWwu
cSk7DQo+ICsJCXJlZ192YWwucSA9IHJkbXNycShIVl9YNjRfTVNSX0VPSSk7DQo+ICAJCXJldHVy
biByZWdfdmFsLmw7DQo+ICAJY2FzZSBBUElDX1RBU0tQUkk6DQo+IC0JCXJkbXNycShIVl9YNjRf
TVNSX1RQUiwgcmVnX3ZhbC5xKTsNCj4gKwkJcmVnX3ZhbC5xID0gcmRtc3JxKEhWX1g2NF9NU1Jf
VFBSKTsNCj4gIAkJcmV0dXJuIHJlZ192YWwubDsNCj4gDQo+ICAJZGVmYXVsdDoNCj4gZGlmZiAt
LWdpdCBhL2FyY2gveDg2L2h5cGVydi9odl9pbml0LmMgYi9hcmNoL3g4Ni9oeXBlcnYvaHZfaW5p
dC5jDQo+IGluZGV4IDU1YThiNmRlMjg2NS4uYmM4ZjkxMTE0ODY4IDEwMDY0NA0KPiAtLS0gYS9h
cmNoL3g4Ni9oeXBlcnYvaHZfaW5pdC5jDQo+ICsrKyBiL2FyY2gveDg2L2h5cGVydi9odl9pbml0
LmMNCj4gQEAgLTEwMSw3ICsxMDEsNyBAQCBzdGF0aWMgaW50IGh5cGVydl9pbml0X2doY2Iodm9p
ZCkNCj4gIAkgKiByZXR1cm5lZCBieSBNU1JfQU1ENjRfU0VWX0VTX0dIQ0IgaXMgYWJvdmUgc2hh
cmVkDQo+ICAJICogbWVtb3J5IGJvdW5kYXJ5IGFuZCBtYXAgaXQgaGVyZS4NCj4gIAkgKi8NCj4g
LQlyZG1zcnEoTVNSX0FNRDY0X1NFVl9FU19HSENCLCBnaGNiX2dwYSk7DQo+ICsJZ2hjYl9ncGEg
PSByZG1zcnEoTVNSX0FNRDY0X1NFVl9FU19HSENCKTsNCj4gDQo+ICAJLyogTWFzayBvdXQgdlRP
TSBiaXQgYW5kIG1hcCBhcyBkZWNyeXB0ZWQgKi8NCj4gIAlnaGNiX2dwYSAmPSB+bXNfaHlwZXJ2
LnNoYXJlZF9ncGFfYm91bmRhcnk7DQo+IEBAIC0xMzQsNyArMTM0LDcgQEAgc3RhdGljIGludCBo
dl9jcHVfaW5pdCh1bnNpZ25lZCBpbnQgY3B1KQ0KPiAgCQkgKiBGb3Igcm9vdCBwYXJ0aXRpb24g
d2UgZ2V0IHRoZSBoeXBlcnZpc29yIHByb3ZpZGVkIFZQIGFzc2lzdA0KPiAgCQkgKiBwYWdlLCBp
bnN0ZWFkIG9mIGFsbG9jYXRpbmcgYSBuZXcgcGFnZS4NCj4gIAkJICovDQo+IC0JCXJkbXNycShI
Vl9YNjRfTVNSX1ZQX0FTU0lTVF9QQUdFLCBtc3IuYXNfdWludDY0KTsNCj4gKwkJbXNyLmFzX3Vp
bnQ2NCA9IHJkbXNycShIVl9YNjRfTVNSX1ZQX0FTU0lTVF9QQUdFKTsNCj4gIAkJKmh2cCA9IG1l
bXJlbWFwKG1zci5wZm4gPDwgSFZfWDY0X01TUl9WUF9BU1NJU1RfUEFHRV9BRERSRVNTX1NISUZU
LA0KPiAgCQkJCVBBR0VfU0laRSwgTUVNUkVNQVBfV0IpOw0KPiAgCX0gZWxzZSB7DQo+IEBAIC0x
ODMsNyArMTgzLDcgQEAgc3RhdGljIHZvaWQgaHZfcmVlbmxpZ2h0ZW5tZW50X25vdGlmeShzdHJ1
Y3Qgd29ya19zdHJ1Y3QgKmR1bW15KQ0KPiAgew0KPiAgCXN0cnVjdCBodl90c2NfZW11bGF0aW9u
X3N0YXR1cyBlbXVfc3RhdHVzOw0KPiANCj4gLQlyZG1zcnEoSFZfWDY0X01TUl9UU0NfRU1VTEFU
SU9OX1NUQVRVUywgKih1NjQgKikmZW11X3N0YXR1cyk7DQo+ICsJKih1NjQgKikmZW11X3N0YXR1
cyA9IHJkbXNycShIVl9YNjRfTVNSX1RTQ19FTVVMQVRJT05fU1RBVFVTKTsNCj4gDQo+ICAJLyog
RG9uJ3QgaXNzdWUgdGhlIGNhbGxiYWNrIGlmIFRTQyBhY2Nlc3NlcyBhcmUgbm90IGVtdWxhdGVk
ICovDQo+ICAJaWYgKGh2X3JlZW5saWdodGVubWVudF9jYiAmJiBlbXVfc3RhdHVzLmlucHJvZ3Jl
c3MpDQo+IEBAIC0xOTYsMTEgKzE5NiwxMSBAQCB2b2lkIGh5cGVydl9zdG9wX3RzY19lbXVsYXRp
b24odm9pZCkNCj4gIAl1NjQgZnJlcTsNCj4gIAlzdHJ1Y3QgaHZfdHNjX2VtdWxhdGlvbl9zdGF0
dXMgZW11X3N0YXR1czsNCj4gDQo+IC0JcmRtc3JxKEhWX1g2NF9NU1JfVFNDX0VNVUxBVElPTl9T
VEFUVVMsICoodTY0ICopJmVtdV9zdGF0dXMpOw0KPiArCSoodTY0ICopJmVtdV9zdGF0dXMgPSBy
ZG1zcnEoSFZfWDY0X01TUl9UU0NfRU1VTEFUSU9OX1NUQVRVUyk7DQo+ICAJZW11X3N0YXR1cy5p
bnByb2dyZXNzID0gMDsNCj4gIAl3cm1zcnEoSFZfWDY0X01TUl9UU0NfRU1VTEFUSU9OX1NUQVRV
UywgKih1NjQgKikmZW11X3N0YXR1cyk7DQo+IA0KPiAtCXJkbXNycShIVl9YNjRfTVNSX1RTQ19G
UkVRVUVOQ1ksIGZyZXEpOw0KPiArCWZyZXEgPSByZG1zcnEoSFZfWDY0X01TUl9UU0NfRlJFUVVF
TkNZKTsNCj4gIAl0c2Nfa2h6ID0gZGl2NjRfdTY0KGZyZXEsIDEwMDApOw0KPiAgfQ0KPiAgRVhQ
T1JUX1NZTUJPTF9HUEwoaHlwZXJ2X3N0b3BfdHNjX2VtdWxhdGlvbik7DQo+IEBAIC0yNjAsNyAr
MjYwLDcgQEAgdm9pZCBjbGVhcl9odl90c2NjaGFuZ2VfY2Iodm9pZCkNCj4gIAlpZiAoIWh2X3Jl
ZW5saWdodGVubWVudF9hdmFpbGFibGUoKSkNCj4gIAkJcmV0dXJuOw0KPiANCj4gLQlyZG1zcnEo
SFZfWDY0X01TUl9SRUVOTElHSFRFTk1FTlRfQ09OVFJPTCwgKih1NjQgKikmcmVfY3RybCk7DQo+
ICsJKih1NjQgKikmcmVfY3RybCA9IHJkbXNycShIVl9YNjRfTVNSX1JFRU5MSUdIVEVOTUVOVF9D
T05UUk9MKTsNCj4gIAlyZV9jdHJsLmVuYWJsZWQgPSAwOw0KPiAgCXdybXNycShIVl9YNjRfTVNS
X1JFRU5MSUdIVEVOTUVOVF9DT05UUk9MLCAqKHU2NCAqKSZyZV9jdHJsKTsNCj4gDQo+IEBAIC0y
OTcsNyArMjk3LDcgQEAgc3RhdGljIGludCBodl9jcHVfZGllKHVuc2lnbmVkIGludCBjcHUpDQo+
ICAJCQkgKi8NCj4gIAkJCW1lbXVubWFwKGh2X3ZwX2Fzc2lzdF9wYWdlW2NwdV0pOw0KPiAgCQkJ
aHZfdnBfYXNzaXN0X3BhZ2VbY3B1XSA9IE5VTEw7DQo+IC0JCQlyZG1zcnEoSFZfWDY0X01TUl9W
UF9BU1NJU1RfUEFHRSwgbXNyLmFzX3VpbnQ2NCk7DQo+ICsJCQltc3IuYXNfdWludDY0ID0gcmRt
c3JxKEhWX1g2NF9NU1JfVlBfQVNTSVNUX1BBR0UpOw0KPiAgCQkJbXNyLmVuYWJsZSA9IDA7DQo+
ICAJCX0NCj4gIAkJd3Jtc3JxKEhWX1g2NF9NU1JfVlBfQVNTSVNUX1BBR0UsIG1zci5hc191aW50
NjQpOw0KPiBAQCAtMzA2LDcgKzMwNiw3IEBAIHN0YXRpYyBpbnQgaHZfY3B1X2RpZSh1bnNpZ25l
ZCBpbnQgY3B1KQ0KPiAgCWlmIChodl9yZWVubGlnaHRlbm1lbnRfY2IgPT0gTlVMTCkNCj4gIAkJ
cmV0dXJuIDA7DQo+IA0KPiAtCXJkbXNycShIVl9YNjRfTVNSX1JFRU5MSUdIVEVOTUVOVF9DT05U
Uk9MLCAqKCh1NjQgKikmcmVfY3RybCkpOw0KPiArCSooKHU2NCAqKSZyZV9jdHJsKSA9IHJkbXNy
cShIVl9YNjRfTVNSX1JFRU5MSUdIVEVOTUVOVF9DT05UUk9MKTsNCj4gIAlpZiAocmVfY3RybC50
YXJnZXRfdnAgPT0gaHZfdnBfaW5kZXhbY3B1XSkgew0KPiAgCQkvKg0KPiAgCQkgKiBSZWFzc2ln
biByZWVubGlnaHRlbm1lbnQgbm90aWZpY2F0aW9ucyB0byBzb21lIG90aGVyIG9ubGluZQ0KPiBA
QCAtMzc3LDcgKzM3Nyw3IEBAIHN0YXRpYyBpbnQgaHZfc3VzcGVuZCh2b2lkICpkYXRhKQ0KPiAg
CWh2X3NldF9oeXBlcmNhbGxfcGcoTlVMTCk7DQo+IA0KPiAgCS8qIERpc2FibGUgdGhlIGh5cGVy
Y2FsbCBwYWdlIGluIHRoZSBoeXBlcnZpc29yICovDQo+IC0JcmRtc3JxKEhWX1g2NF9NU1JfSFlQ
RVJDQUxMLCBoeXBlcmNhbGxfbXNyLmFzX3VpbnQ2NCk7DQo+ICsJaHlwZXJjYWxsX21zci5hc191
aW50NjQgPSByZG1zcnEoSFZfWDY0X01TUl9IWVBFUkNBTEwpOw0KPiAgCWh5cGVyY2FsbF9tc3Iu
ZW5hYmxlID0gMDsNCj4gIAl3cm1zcnEoSFZfWDY0X01TUl9IWVBFUkNBTEwsIGh5cGVyY2FsbF9t
c3IuYXNfdWludDY0KTsNCj4gDQo+IEBAIC0zOTQsNyArMzk0LDcgQEAgc3RhdGljIHZvaWQgaHZf
cmVzdW1lKHZvaWQgKmRhdGEpDQo+ICAJV0FSTl9PTihyZXQpOw0KPiANCj4gIAkvKiBSZS1lbmFi
bGUgdGhlIGh5cGVyY2FsbCBwYWdlICovDQo+IC0JcmRtc3JxKEhWX1g2NF9NU1JfSFlQRVJDQUxM
LCBoeXBlcmNhbGxfbXNyLmFzX3VpbnQ2NCk7DQo+ICsJaHlwZXJjYWxsX21zci5hc191aW50NjQg
PSByZG1zcnEoSFZfWDY0X01TUl9IWVBFUkNBTEwpOw0KPiAgCWh5cGVyY2FsbF9tc3IuZW5hYmxl
ID0gMTsNCj4gIAloeXBlcmNhbGxfbXNyLmd1ZXN0X3BoeXNpY2FsX2FkZHJlc3MgPQ0KPiAgCQl2
bWFsbG9jX3RvX3Bmbihodl9oeXBlcmNhbGxfcGdfc2F2ZWQpOw0KPiBAQCAtNTI5LDcgKzUyOSw3
IEBAIHZvaWQgX19pbml0IGh5cGVydl9pbml0KHZvaWQpDQo+ICAJaWYgKGh2X2h5cGVyY2FsbF9w
ZyA9PSBOVUxMKQ0KPiAgCQlnb3RvIGNsZWFuX2d1ZXN0X29zX2lkOw0KPiANCj4gLQlyZG1zcnEo
SFZfWDY0X01TUl9IWVBFUkNBTEwsIGh5cGVyY2FsbF9tc3IuYXNfdWludDY0KTsNCj4gKwloeXBl
cmNhbGxfbXNyLmFzX3VpbnQ2NCA9IHJkbXNycShIVl9YNjRfTVNSX0hZUEVSQ0FMTCk7DQo+ICAJ
aHlwZXJjYWxsX21zci5lbmFibGUgPSAxOw0KPiANCj4gIAlpZiAoaHZfcm9vdF9wYXJ0aXRpb24o
KSkgew0KPiBAQCAtNjcxLDcgKzY3MSw3IEBAIHZvaWQgaHlwZXJ2X3JlcG9ydF9wYW5pYyhzdHJ1
Y3QgcHRfcmVncyAqcmVncywgbG9uZyBlcnIsIGJvb2wgaW5fZGllKQ0KPiAgCQlyZXR1cm47DQo+
ICAJcGFuaWNfcmVwb3J0ZWQgPSB0cnVlOw0KPiANCj4gLQlyZG1zcnEoSFZfWDY0X01TUl9HVUVT
VF9PU19JRCwgZ3Vlc3RfaWQpOw0KPiArCWd1ZXN0X2lkID0gcmRtc3JxKEhWX1g2NF9NU1JfR1VF
U1RfT1NfSUQpOw0KPiANCj4gIAl3cm1zcnEoSFZfWDY0X01TUl9DUkFTSF9QMCwgZXJyKTsNCj4g
IAl3cm1zcnEoSFZfWDY0X01TUl9DUkFTSF9QMSwgZ3Vlc3RfaWQpOw0KPiBAQCAtNzA1LDcgKzcw
NSw3IEBAIGJvb2wgaHZfaXNfaHlwZXJ2X2luaXRpYWxpemVkKHZvaWQpDQo+ICAJICogdGhhdCB0
aGUgaHlwZXJjYWxsIHBhZ2UgaXMgc2V0dXANCj4gIAkgKi8NCj4gIAloeXBlcmNhbGxfbXNyLmFz
X3VpbnQ2NCA9IDA7DQo+IC0JcmRtc3JxKEhWX1g2NF9NU1JfSFlQRVJDQUxMLCBoeXBlcmNhbGxf
bXNyLmFzX3VpbnQ2NCk7DQo+ICsJaHlwZXJjYWxsX21zci5hc191aW50NjQgPSByZG1zcnEoSFZf
WDY0X01TUl9IWVBFUkNBTEwpOw0KPiANCj4gIAlyZXR1cm4gaHlwZXJjYWxsX21zci5lbmFibGU7
DQo+ICB9DQo+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9oeXBlcnYvaHZfc3BpbmxvY2suYyBiL2Fy
Y2gveDg2L2h5cGVydi9odl9zcGlubG9jay5jDQo+IGluZGV4IDZiNGJkZWExODIxOC4uN2VmMmQ3
OTRlMmU4IDEwMDY0NA0KPiAtLS0gYS9hcmNoL3g4Ni9oeXBlcnYvaHZfc3BpbmxvY2suYw0KPiAr
KysgYi9hcmNoL3g4Ni9oeXBlcnYvaHZfc3BpbmxvY2suYw0KPiBAQCAtNTAsNyArNTAsNyBAQCBz
dGF0aWMgdm9pZCBodl9xbG9ja193YWl0KHU4ICpieXRlLCB1OCB2YWwpDQo+ICAJaWYgKFJFQURf
T05DRSgqYnl0ZSkgPT0gdmFsKSB7DQo+ICAJCXVuc2lnbmVkIGxvbmcgbXNyX3ZhbDsNCj4gDQo+
IC0JCXJkbXNycShIVl9YNjRfTVNSX0dVRVNUX0lETEUsIG1zcl92YWwpOw0KPiArCQltc3JfdmFs
ID0gcmRtc3JxKEhWX1g2NF9NU1JfR1VFU1RfSURMRSk7DQo+IA0KPiAgCQkodm9pZCltc3JfdmFs
Ow0KPiAgCX0NCg0KW3NuaXBdDQoNCj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L2tlcm5lbC9jcHUv
bXNoeXBlcnYuYyBiL2FyY2gveDg2L2tlcm5lbC9jcHUvbXNoeXBlcnYuYw0KPiBpbmRleCAxODVk
NGY2NzdlYzAuLjY1YWQyMzVlZjVjNiAxMDA2NDQNCj4gLS0tIGEvYXJjaC94ODYva2VybmVsL2Nw
dS9tc2h5cGVydi5jDQo+ICsrKyBiL2FyY2gveDg2L2tlcm5lbC9jcHUvbXNoeXBlcnYuYw0KPiBA
QCAtNzQsNyArNzQsNyBAQCB1NjQgaHZfZ2V0X25vbl9uZXN0ZWRfbXNyKHVuc2lnbmVkIGludCBy
ZWcpDQo+ICAJaWYgKGh2X2lzX3N5bmljX21zcihyZWcpICYmIG1zX2h5cGVydi5wYXJhdmlzb3Jf
cHJlc2VudCkNCj4gIAkJaHZfaXZtX21zcl9yZWFkKHJlZywgJnZhbHVlKTsNCj4gIAllbHNlDQo+
IC0JCXJkbXNycShyZWcsIHZhbHVlKTsNCj4gKwkJdmFsdWUgPSByZG1zcnEocmVnKTsNCj4gIAly
ZXR1cm4gdmFsdWU7DQo+ICB9DQo+ICBFWFBPUlRfU1lNQk9MX0dQTChodl9nZXRfbm9uX25lc3Rl
ZF9tc3IpOw0KPiBAQCAtMzk5LDcgKzM5OSw3IEBAIHN0YXRpYyB1bnNpZ25lZCBsb25nIGh2X2dl
dF90c2Nfa2h6KHZvaWQpDQo+ICB7DQo+ICAJdW5zaWduZWQgbG9uZyBmcmVxOw0KPiANCj4gLQly
ZG1zcnEoSFZfWDY0X01TUl9UU0NfRlJFUVVFTkNZLCBmcmVxKTsNCj4gKwlmcmVxID0gcmRtc3Jx
KEhWX1g2NF9NU1JfVFNDX0ZSRVFVRU5DWSk7DQo+IA0KPiAgCXJldHVybiBmcmVxIC8gMTAwMDsN
Cj4gIH0NCj4gQEAgLTY0NSw3ICs2NDUsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgbXNfaHlwZXJ2
X2luaXRfcGxhdGZvcm0odm9pZCkNCj4gIAkJICovDQo+ICAJCXU2NAlodl9sYXBpY19mcmVxdWVu
Y3k7DQo+IA0KPiAtCQlyZG1zcnEoSFZfWDY0X01TUl9BUElDX0ZSRVFVRU5DWSwgaHZfbGFwaWNf
ZnJlcXVlbmN5KTsNCj4gKwkJaHZfbGFwaWNfZnJlcXVlbmN5ID0gcmRtc3JxKEhWX1g2NF9NU1Jf
QVBJQ19GUkVRVUVOQ1kpOw0KPiAgCQlodl9sYXBpY19mcmVxdWVuY3kgPSBkaXZfdTY0KGh2X2xh
cGljX2ZyZXF1ZW5jeSwgSFopOw0KPiAgCQlsYXBpY190aW1lcl9wZXJpb2QgPSBodl9sYXBpY19m
cmVxdWVuY3k7DQo+ICAJCXByX2luZm8oIkh5cGVyLVY6IExBUElDIFRpbWVyIEZyZXF1ZW5jeTog
JSN4XG4iLA0KDQpGb3IgdGhpcyBIeXBlci1WIHNwZWNpZmljIGNvZGUsDQoNClJldmlld2VkLWJ5
OiBNaWNoYWVsIEtlbGxleSA8bWhrbGludXhAb3V0bG9vay5jb20+DQoNCg0KDQo=


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 08:19:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 08:19:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397178.1634564 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKTO-0000x0-Cc; Fri, 21 Aug 2026 08:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397178.1634564; Fri, 21 Aug 2026 08:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKTO-0000ws-95; Fri, 21 Aug 2026 08:19:34 +0000
Received: by outflank-mailman (input) for mailman id 1397178;
 Fri, 21 Aug 2026 08:19:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wxKTN-0000wm-64
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 08:19:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxKTM-00F3DR-J7
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 10:19:32 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a880a08-2eae-0a2a0a5409dd-0a2a450aaf9e-32
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:19:32 +0200
Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a880a14-f2d2-0a2a450a0019-d155da2bc9e3-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:19:32 +0200
Received: by mail-ej1-f43.google.com with SMTP id
 a640c23a62f3a-c2020421077so124229466b.3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 01:19:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2459223816sm387149366b.57.2026.08.21.01.19.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 21 Aug 2026 01:19:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787300372; x=1787905172; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=xJgbi0Hxi0iwuDDgvhe2MiVZefgarGN88Is5Ns8OqNQ=;
        b=CVQrvIrftej8OoXjFYmEQcUlFB+7FrWpYF7H43FQ17CkpjXKc7NNCTodAi1JDg06DJ
         +RNYTzZm4WsTZO1iLoxwS//Lp429KNDnMwgGTvBeabaFnYUTNuBli28PQinhKGs+W+jq
         u8REn/DrC4fYpfrHW7N5pKUA/6oY0aFtwZkQWHzD504VnHRaXyghHT2xEPbZcsLw2NjX
         l70OgVeIaKfwsCOHo2jpVvjxPAGXKCI7wZroJvFhEHIzRrUDWdrmLd3nE+MjvGbAp37W
         pt8Bon3/RJEcY+ZYnyr8yGVDF9aXR7jAul0b7ACcQ33gi7XDZ5r4fqsm+0cweYEMH7js
         LNXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787300372; x=1787905172;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=xJgbi0Hxi0iwuDDgvhe2MiVZefgarGN88Is5Ns8OqNQ=;
        b=jmjoLTSJ99kvNeofzr1JCgPzr7YI+Y4bbJmQcsL1qMwRDYOJgqTo3aQ0o8GX8NYAvW
         y0f118ZmKM15A0Bp20eO4S+mh//MYVuZlabNfhVdMTEPBzNsbqoluGAAS/wAQqRnUPRx
         6BJXozkDwuKGIfmoeULBcdSCaWGON20v0hjBHDqaJVrJRJPoQ09eE1j/o0DLQ+SDB8d8
         0n9dnneCUlIeAs+QI0CV9yYHozPTC6fzbCctqUQM3A6GRDotaclMwN2y9KgegZQS5eOx
         u2t/UcHxTWSIuWYMWrdRYwwnePLsO7gr6/0xP+S7IR5v5LErjxTSroj3HH02WhS97d57
         RxpA==
X-Forwarded-Encrypted: i=1; AHgh+RrgrBWbYqZyWqXkhLmOExLKM7TMKo3x7jJMPVWFDU1ZT+L+vrburTVkk66BWSPnX3qahpCZgFGk5SA=@lists.xenproject.org
X-Gm-Message-State: AFuF++mkduS5AgvMIjYTfmKnKU9YNIS+2lwdmAvwbZndfpGETYsSKLgn
	KcBwfNnhfsND92xeUVLp2vNnvSWq2HvIy+kvp4JUwqeEFpkaVdx5suEaFwAzSkf+Zg==
X-Gm-Gg: AR+sD13nH2jjYKOY0tGWqunt4XCOu8ih7QDlaAx9hhMGMbHdMYsNwtyVA3n5HQ7KgpI
	2OJCabcy1Kc63RAy9W+XGthqnstGoC8fR7b3vtzpGWzg5BjxETdHc32q5BSTFOuC3j5Y49vnzqx
	Ubcg5lYnRZZu1yGyGtsCUC2dpZCaE/KpEBKhrnFHhJ7Ey7XU36slBOE0nO6E1Kqb0/wDkTHVs5B
	gsyKjin+JdsQ9v7K/ghirBtUSrXQMKOXctm7ZVUFEa9QEHn8izCTBUjpr+WY8Q9hbeLQ8EVk+lW
	jyiDb2MpgP6fpW1zjGQutT8DqQCnm+EZQmEoldtoTzlqGvKeoSIUHb+MlF6m/sddneUhyTpjEtU
	BI4tYnCthSKIC9nfjZtkhS58CPMkPX92jJm31qfJWSp4twmZSOB0Jzj07/+bfMDI7J3HYRzy8pB
	9fZrk/Wnn5pinuLsQEiPReu7EZq4THEVKYaK5dn3q1w1KcvkyDquHdB8gsRQa8tG+7XKQh9FF5N
	M/PY6/WDh4fVtTw3HtMZZ95js5EXX6SDm7jlHqVkGMNnQG+syGT
X-Received: by 2002:a05:6938:a08f:10b0:c20:f871:1018 with SMTP id a640c23a62f3a-c246b4bc19bmr333973866b.21.1787300371859;
        Fri, 21 Aug 2026 01:19:31 -0700 (PDT)
Message-ID: <069cb01d-47b2-41c5-9956-611b338964e9@suse.com>
Date: Fri, 21 Aug 2026 10:19:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Chuck Zmudzinski <brchuckz@aol.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <de56c8bd-f0e8-4fe9-8cf5-f6807698176c@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
 <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
 <fa497825-c8f0-4caf-94f5-b37108e31952@aol.com>
 <42521391-885c-4b96-96e9-5da2e4b5efa1@suse.com>
 <e86404e8-9966-44ab-86d1-4bd01a551313@aol.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <e86404e8-9966-44ab-86d1-4bd01a551313@aol.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787300372-512C8CFC-42CC16A0/0/0
X-purgate-type: clean
X-purgate-size: 4366

On 20.08.2026 18:53, Chuck Zmudzinski wrote:
> On 8/20/2026 11:17 AM, Jan Beulich wrote:
>> On 20.08.2026 13:47, Chuck Zmudzinski wrote:
>>> On 8/20/2026 3:51 AM, Jan Beulich wrote:
>>>> On 19.08.2026 19:13, Chuck Zmudzinski wrote:
>>>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>>>> about avoiding the layering violation than anything else.
>>>>>>>
>>>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>>>
>>>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>>>> in hvmloader?
>>>>>>
>>>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>>>> restricted DM as well.
>>>>>>
>>>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>>>> treatment.
>>>>>
>>>>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>>>>> it functions more or less like a BAR region with the devices's ASLS register
>>>>> at offset 0xfc in the PCI device config space of the device acting like the
>>>>> BAR for that region.
>>>>
>>>> That is, on real hardware a write to that register moves the OpRegion? That
>>>> would need following by the DM then, i.e. the DM would need to indicate the
>>>> original position in the register, and the guest (incl hvmloader) would
>>>> then be free to relocate it.
>>>
>>> Why would that "need following by the DM" when the register in the guest is
>>> fully emulated, [1] which means that when the guest (incl hvmloader) writes to the
>>> register, the register on the real hardware is not touched, nor is the OpRegion
>>> in the host address space moved?
>>
>> You said it's BAR-like. If the guest writes to a BAR, the referenced MMIO
>> region moves accordingly.
> 
> It's BAR-like, but it is not actually a BAR (and the OpRegion is not exactly
> an MMIO region either (it is actually and ACPI thing), so that is not relevant
> to this patch.
> 
> Also, it is fully emulated so when the guest writes to it, the real register on the
> real device is not touched, as I have said multiple times in my responses to your
> question.

No matter how often you said that, I never put that under question. I was asking
about the behavior of writes (where the behavior on bare hardware would need to
be reflected in the behavior of the emulated register).

>>> Here is how I understand how this works in the current implementation and how
>>> this should be done:
>>
>> I'm sorry, but this is getting out of hand, at least as far as I'm concerned.
>> I've been trying to help, but even just reading your replies has already been
>> taking way more time than I would have wanted to spend here.
> 
> Fair enough. Thank you for the time you have spent on this patch, and also thank
> you for clearly stating that you don't want to spend any more time on it. So
> I consider this patch dead unless and until another maintainer shows some interest
> in it.

I didn't say I would not look at future versions of the patch. However, for me
to (usefully) do so, things need to be presented in a way that I can understand
without knowing all the details of IGD.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 08:42:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 08:42:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397204.1634574 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKpQ-0004uc-3d; Fri, 21 Aug 2026 08:42:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397204.1634574; Fri, 21 Aug 2026 08:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKpQ-0004uV-0U; Fri, 21 Aug 2026 08:42:20 +0000
Received: by outflank-mailman (input) for mailman id 1397204;
 Fri, 21 Aug 2026 08:42:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <den@valinux.co.jp>) id 1wxKpO-0004uP-Dj
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 08:42:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxKpM-00FwbT-Cm
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 10:42:16 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <den@valinux.co.jp>)
 id 6a880f67-8faa-0a2a0a5109dd-0a2a450cc664-0
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:42:15 +0200
Received: from [52.101.228.89]
 (helo=OS0P286CU011.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <den@valinux.co.jp>)
 id 6a880f64-f479-0a2a450c0019-3465e459e8f1-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:42:14 +0200
Received: from TY7P286MB7722.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:38f::10)
 by TY7P286MB6259.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:32c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Fri, 21 Aug
 2026 08:42:10 +0000
Received: from TY7P286MB7722.JPNP286.PROD.OUTLOOK.COM
 ([fe80::2305:327c:28ec:9b32]) by TY7P286MB7722.JPNP286.PROD.OUTLOOK.COM
 ([fe80::2305:327c:28ec:9b32%3]) with mapi id 15.21.0339.007; Fri, 21 Aug 2026
 08:42:09 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Abn3M+ddf18ino3y6o5QP0Ku0WzkoPo3BExkME66jAkpsAfPBJWWu7CADedfIgnFtMi2Krepg42AxlUydOc4gSHSrZ4xVKior6ZqrIaS0yimgRscL+6IHOkQ/hFhEKN6QTMLE9EGTJQeJ35VmCWShPgmkchoLWIS86v22pF7HuP7AqJRzH9InReCM1jlMjPzL5rgDYhm/0bjXDKsXV7UcxruI8MUyofyZPmWEXQmHe8ztivFeDYwFuwLeDhdSHjyeXjTnBfdcY03ug9+LGLT3KZ3pAABvtvigYsmjN9Ej1dLCBwthEdTiGDdzbWD2n7X56FL0nEoK1El1EqbSp+yKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nSMVGeuaLgvVlkD44jgGyhemh9VA7QAPohCs4cR4/QY=;
 b=zGE9z1MbcOrzujK4Ant3NeXohCAlUoN+nVFJzuZE01rcUxmwZyElDCJB5yXkK76hfEOJ8Lqk/CAoh5WrwWNp1YCgkvbj1hKtXRuxlwrGBDLrZTnYfKKaFuVb5H1xtMLw1qlCFRh3NIJs5oGcgRlv18zNWTcAe+0cKIh52TNOwVUZByQvmFhiMgjWD3vSGsob2YtZMKwSDjrCEmvHcCPrl928Aac98fU0H/BnrUMxWss9CgTi4UrJL5sDm+FLnhJcz7Z8+Rkfb3cJe7XoyUwcItN132P7qIu/OYMOPO9dw+51qSoE41lEAK5jYm4wou8DfEMatIz06nUpuK9F/Q1HaA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nSMVGeuaLgvVlkD44jgGyhemh9VA7QAPohCs4cR4/QY=;
 b=FV3kTJ4JN+s3gzqFD1Iz2+8YS9Mldgb+qGYwwuTCTTqBh4ZE2BFkJqbJEAGwoKMBawffEnONpp2jEWuFRdMKsVPC3d7Agai3/suVSKs7tp1TQSbxYYNjSQqJzwXi9fZ+/puOtJtwLglzeFdNKxQNVK5FFYJFYYqn/lCBqDSsutQ=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Koichiro Den <den@valinux.co.jp>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] xen/privcmd: Only claim ioreqs matching an ioeventfd
Date: Fri, 21 Aug 2026 17:41:12 +0900
Message-ID: <20260821084112.2374949-1-den@valinux.co.jp>
X-Mailer: git-send-email 2.51.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4PR01CA0116.jpnprd01.prod.outlook.com
 (2603:1096:405:379::16) To TY7P286MB7722.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:405:38f::10)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: TY7P286MB7722:EE_|TY7P286MB6259:EE_
X-MS-Office365-Filtering-Correlation-Id: 8acddfd7-fb63-4ce1-d87d-08deff6016ce
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|10070799003|1800799024|366016|10067099003|56012099006|18002099003;
X-Microsoft-Antispam-Message-Info:
	qpYnDOPNYSEfcqaAzyy7VttNEe/KPKLdwWL8XcCAK9HbQCGdbY9Yowcpp043ZwK8f4HzM/VqTW9WoY4FJguhaBKsOxnCsQWGMRN00lgkvDRdcm73jsWM3hYV/j+3K+55BvQQzLzFxz267cLEfKUV5pUkP0NAbYPJWq2Pj/immWxaccLV5HDncOSGpxwjqRdwKAm+T/5WNqL3Z3T0QLAKa1WEdiHyBPr6GCUrARnRgyp1nOKn63FJHdW+Qri6BXSxyKDWo271hBlfelvXAiYyT37SLedUrIvO0ixdoMBRHys18wKurfyl2ZP/jf3NvEACZ4WD509IoWFI45My+mdfNX5V6688fxaIK4CUDkX3AuId5b1Vq8f6lvDuyLZd2YDLEuV4Q5IyPod1d/FZnYEKCq5DTRcminyTMlvf958meCVZ28pwjwtG0H/G6lMlf+Q7w/1EHx76dwLxY1qVkod86J7Y8rhqi2DkiR8cTG73X7fRMreE+A8iwszWkYaxpSxqJ1UXYOqzS64cxLJboeD8BCMqYTx6GwuCNoCs/EUUo3ZUFdeHlx8KmthrHQwPhB+BFh9XqMoooRjb2wJqLsrmc9iSFaGJPvhsqlG+SAx5ne9x9XlBNCiQSsyvpWeU+LUa9Gw3Z3hDiQdACYineU/lUTM693mPuOgdRJb0jqgmJrg=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TY7P286MB7722.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(10070799003)(1800799024)(366016)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?DZgUrxb/u0wk0rl4fe9suhB0PYuVVWmFa3HiOHen+vF0oe5nIGaHCM/RcwED?=
 =?us-ascii?Q?FMTAGB17Q74yStT0/eqQ+A7493FlvpKex2A7TLWq/SK5XWNl28Bl96bOhZg1?=
 =?us-ascii?Q?ke4LlEuI+dr9LC7GD+8KkUiwEQgB0EezGfkn/G7TNZvOB0oTe2A3uwwGsmWd?=
 =?us-ascii?Q?JkX0GN0spfnXUcCiauvI+4zsL5ZKy2cf5cV4iDYuuE3FWRY3cSu1NGn34+UC?=
 =?us-ascii?Q?dNlt7FXPsEAipMwwWK/ow1sGpAPcw1ZxPqyFexZcOkeoEnKaGlggp9376B1p?=
 =?us-ascii?Q?MYTWU5MAkoaDHHc7GPxlasgX1pxTNIjwNWbMHe6hxRLacv3V/z1xM/ojhseL?=
 =?us-ascii?Q?LDMn7fksuNRQyQAv7yYzE79Upgt71/zlOcrv1K237ivgBR671yUAUxTK2lWS?=
 =?us-ascii?Q?yWXhYI4r3ZX04VjhqIOxCBHSaQ4gyg5S2kUHFkEVUH6w6AdlSC2ZDlFAMLK3?=
 =?us-ascii?Q?SDlEsMAaXU2xqblKAn7nBcBhC1hU0K7eL1yeYNVQg6aiUEKmbcLTg9cpgs2V?=
 =?us-ascii?Q?s8Q0D09iLyTm3kH4h1FfuThV64hE64+RSbp/qrm4Iwq2ZmEaTi2VbMxm3qzw?=
 =?us-ascii?Q?gHm7KDAh5d1Oe0Q2VOrfdF79eYJgkAG/HiZ55aAL8YozYW0jPki8kcjjoQiZ?=
 =?us-ascii?Q?tReZvub9xqoCuIQLIdrV+4p1vgK+zLP0cy5FTuaY6sFDSI9nnkygZ2R45UU2?=
 =?us-ascii?Q?yTr6EZV4KQrrZCK8OhQpGs0t+GtgKF/s68LNLurIijjcG93oTpnUdEjnZwh+?=
 =?us-ascii?Q?XI3uxwR4IZwyXJhhQMieo09X+WsClegdokl0znT3Fs7yr6tMpWvcMF4ySyqw?=
 =?us-ascii?Q?S/bh4ZtyBRyzNOYGqvbQsyBzXpuGp2bKymtTHARQzdiMcaQx4LIyl9KNLVXe?=
 =?us-ascii?Q?VKSJME2d7r+3cpl3/cNSmAdIH8s6oT1PDcb3NvLtxQ2iEkNnalwuEKON3FG7?=
 =?us-ascii?Q?ykfPjGp97wQOtF/5wwVB6Q3T1gd0jAxyjQN6x/obYSHStqmjVpqWNA6VXAjH?=
 =?us-ascii?Q?/f3ky7sngQ+IO8vfYPOdRi/yMf2nBOb4E1ixuAPvgpMuOvteUR4bOBKf1cjp?=
 =?us-ascii?Q?+pfHIATAyZRni64i4o8E8t4lMrBvZqCcyPqJjttpbwZ3leyNfu9umhFc0oma?=
 =?us-ascii?Q?QGpkUjXbNBaHz0lXBLAPWWeQ48VvYsEJHC0fzrgVF9sfSM9DncrljhoaNZ5x?=
 =?us-ascii?Q?f/9iw+AxCbyP9PC8vGGiXUqnLTY8Q3xtQAJsRY2k7rDM3PkBGBzT5RH/CP8y?=
 =?us-ascii?Q?Hmi9dCSgczaLirfOUwyx84SH86ePgBeSfoDFto10XKjMUsezMwB6EtMdMxr6?=
 =?us-ascii?Q?GAyCD9jkLMUcvaSR35frHXURdMUwpdKIG4CrwkuD3Z5eAFP+M8sRB7uB4Eji?=
 =?us-ascii?Q?BeuItxAIbrh3OJJ5Uircg5X1kclDrqqO1FE0NoJHosDIF+v/+Q/4X8bFoYzS?=
 =?us-ascii?Q?M7uHQSKEOdef1trOMJuAJIHTWdis2e0bEGLG0ITmJYAQ3Q8zYbRg+T0sgu2X?=
 =?us-ascii?Q?+j6BpIwcjogEZ7xDQ2gnwJB50SYPjS3Xh6LUTJSD/TFnUqyvpeVR+o6J2onc?=
 =?us-ascii?Q?k7Wp+H4aVz5fn5ozPTjddTxE8bipWvegLKKftdKR4X9HUH/v7VwKFEg/GRoU?=
 =?us-ascii?Q?34QQ0rjVQxWw7GTum0QlzhfcJj0tkv2EwMjKbeHhlAHA2JRYQyjtIAOWK76L?=
 =?us-ascii?Q?up7C8bGGLBdg20fwhp8xUk1gJv7Owybobb39CguCeAsrQgCOrtY3mgugvt9V?=
 =?us-ascii?Q?WnzyELUd1GDoDXJm0lC593e4XQLoHwuJFax805OMnwgPnFUDKE1h?=
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 8acddfd7-fb63-4ce1-d87d-08deff6016ce
X-MS-Exchange-CrossTenant-AuthSource: TY7P286MB7722.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2026 08:42:09.8968
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hssqArvtqZemSTUEFuBM4UqZ7FHcTLApOX/W/xCd6YZMjYKosAYk12qGmT9BZsK/J/YKoDl3mPH2r74WaWuR5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY7P286MB6259
X-purgate-ID: tlsNG-d25034/1787301735-50520A5B-E93D9B01/0/0
X-purgate-type: clean
X-purgate-size: 3600

The ioeventfd handler shares its event channel with the userspace device
model. It must only claim requests that match a registered ioeventfd.
Other requests are left for userspace.

ioeventfd_interrupt() currently marks every MMIO write INPROCESS before
looking for a match. For an unmatched request it drops the lock and
restores READY. Userspace may see INPROCESS and skip it. Restoring READY
does not send another notification. If userspace handles the request at
the same time, the READY store may overwrite its state.

Find a matching ioeventfd before changing the request state.

The lock now protects only the ioeventfd list. Use explicit virt_*mb()
barriers for the ioreq shared with Xen.

Fixes: f0d7db7b3324 ("xen: privcmd: Add support for ioeventfd")
Cc: stable@vger.kernel.org
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
 drivers/xen/privcmd.c | 47 +++++++++++++++++--------------------------
 1 file changed, 18 insertions(+), 29 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 7cfc28f1bb86..c67ec6d282cf 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -1169,51 +1169,40 @@ static irqreturn_t ioeventfd_interrupt(int irq, void *dev_id)
 	struct privcmd_kernel_ioreq *kioreq = port->kioreq;
 	struct ioreq *ioreq = &kioreq->ioreq[port->vcpu];
 	struct privcmd_kernel_ioeventfd *kioeventfd;
-	unsigned int state = STATE_IOREQ_READY;
+	bool matched = false;
 
-	if (ioreq->state != STATE_IOREQ_READY ||
-	    ioreq->type != IOREQ_TYPE_COPY || ioreq->dir != IOREQ_WRITE)
+	if (ioreq->state != STATE_IOREQ_READY)
 		return IRQ_NONE;
 
-	/*
-	 * We need a barrier, smp_mb(), here to ensure reads are finished before
-	 * `state` is updated. Since the lock implementation ensures that
-	 * appropriate barrier will be added anyway, we can avoid adding
-	 * explicit barrier here.
-	 *
-	 * Ideally we don't need to update `state` within the locks, but we do
-	 * that here to avoid adding explicit barrier.
-	 */
+	/* Xen publishes the request before changing its state to READY. */
+	virt_rmb();
 
-	spin_lock(&kioreq->lock);
-	ioreq->state = STATE_IOREQ_INPROCESS;
+	if (ioreq->type != IOREQ_TYPE_COPY || ioreq->dir != IOREQ_WRITE)
+		return IRQ_NONE;
 
+	spin_lock(&kioreq->lock);
 	list_for_each_entry(kioeventfd, &kioreq->ioeventfds, list) {
 		if (ioreq->addr == kioeventfd->addr + VIRTIO_MMIO_QUEUE_NOTIFY &&
 		    ioreq->size == kioeventfd->addr_len &&
 		    (ioreq->data & QUEUE_NOTIFY_VQ_MASK) == kioeventfd->vq) {
+			/* Finish reading the request before claiming it. */
+			virt_mb();
+			ioreq->state = STATE_IOREQ_INPROCESS;
 			eventfd_signal(kioeventfd->eventfd);
-			state = STATE_IORESP_READY;
+			matched = true;
 			break;
 		}
 	}
 	spin_unlock(&kioreq->lock);
 
-	/*
-	 * We need a barrier, smp_mb(), here to ensure writes are finished
-	 * before `state` is updated. Since the lock implementation ensures that
-	 * appropriate barrier will be added anyway, we can avoid adding
-	 * explicit barrier here.
-	 */
-
-	ioreq->state = state;
-
-	if (state == STATE_IORESP_READY) {
-		notify_remote_via_evtchn(port->port);
-		return IRQ_HANDLED;
-	}
+	if (!matched)
+		return IRQ_NONE;
 
-	return IRQ_NONE;
+	/* Publish the response only after signaling the eventfd. */
+	virt_wmb();
+	ioreq->state = STATE_IORESP_READY;
+	notify_remote_via_evtchn(port->port);
+	return IRQ_HANDLED;
 }
 
 static void ioreq_free(struct privcmd_kernel_ioreq *kioreq)

base-commit: d330fb86a7170f845123ae82d95df440fad9b707
-- 
2.51.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 21 08:45:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 08:45:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397212.1634583 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKsW-0005Qr-Gh; Fri, 21 Aug 2026 08:45:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397212.1634583; Fri, 21 Aug 2026 08:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKsW-0005Qk-E1; Fri, 21 Aug 2026 08:45:32 +0000
Received: by outflank-mailman (input) for mailman id 1397212;
 Fri, 21 Aug 2026 08:45:31 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wxKsV-0005Qe-2t
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 08:45:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxKsU-002iPY-5T
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 10:45:30 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a881026-bab6-0a2a0a5309dd-0a2a4508a2c2-8
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:45:30 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a881029-f659-0a2a45080019-d155da36e17b-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:45:30 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c1c50c1e29bso118717966b.3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 01:45:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c246366aa88sm292453366b.38.2026.08.21.01.45.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 21 Aug 2026 01:45:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787301929; x=1787906729; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=lBbFK2jV5MuGwqpe35Vzt6pdsmgB9MKRf+D1wVaaeBY=;
        b=YfQppZeYPZxAPIXcgaTd1yItScaDsbWF2IwQOBoH3HfQflhnjo8a2X0ly3G2SJW89C
         lVXTWJ3NfpQ/MqvhJIbEn5nn2fkZBYZzqW7Zs0dV7dtMpCP/WRPoJmQqKCkHfnrftdU7
         ljHhPyQAd9cYrNaF2vQ1x9u2etKlglQnb2ovhJIhuebFREHWcWvjSuvxxTeShN8nusrS
         TNUHIyHBOw+J/3n3mtYlSwOZK9HqmzwJpGDJjUkqRerPF5yJrn5ycYUWW0vtXKAypsEc
         bWxgWJQ7j+85ATfv9AmpQUkX5rEFMmoSxrHcYSYP1SvxjOWKMk0Mz8ax7BI1EQ6z5GUa
         4c6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787301929; x=1787906729;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=lBbFK2jV5MuGwqpe35Vzt6pdsmgB9MKRf+D1wVaaeBY=;
        b=VwWF1QFDvWeGUmdQNto2beSBxJteaGBo3Vfndt2Nryejkq+Snblm3WiClgEA5Hu2LV
         LTt67ncmi61pXHfDGKAvqlzrpbbS5hUPRFpnMxmeUMTuv9XjjIBsvCyMugdr6B4FIAGH
         AAUFepnzDld4Q5pkJFn2hSmh/E2zW1CUPH3T41bGFrsdp+Zw6KIobIklZ0Zd0/4uC7rB
         pjYjwPXDQed2IS9VKSYGumM9fZMW7xkGaSMl5IHZHucarELn0oUVDSsClZfsQBfIVcs4
         6hz6vsdCj9N7lzlKvCJs+DZuCgQJcrR1PysvG5DPyIi1gWG7JiPrB7jet6uo8+cisInu
         hr/Q==
X-Forwarded-Encrypted: i=1; AHgh+RrgsrxmeiJ2v5w6o1Z8CK5YSCTn3pI/CK/TFZMHnGQj1k2b/p09e07DeMgdYZqWmHYNi6aW/urxdpU=@lists.xenproject.org
X-Gm-Message-State: AFuF++kV+FdP5PD0JqvKudy879ma/BqT/9atwY0TGoNTSkKmE+Out5XA
	pMRVBupdIDxJU3jv9lUQl5kmJR8KpEo8ej3WCEN1VJgviJhOpLule2YB9nuJ4B08dg==
X-Gm-Gg: AR+sD13gkJnCWH8A3Ee4MdMHCwngfxd7guJ81eCQfbwDu8HcSwPNbGbYjPFEPTtaHKw
	Nl7Sth8eARZwYljP9XDCww5mFNJIU6FEI8dtL0yJEv93+H5THs4Z8f2qYfNGUZak6TbXoNZoHb3
	eb24JTE5YaPI21YacPxDlr82nKkGLbjNHOaLvGvYVBXfLOYZVNIOxtPkq6mBbK3Vj7oei3aNQuT
	BR0X7hAskA8l84UUEQ0JjC8aohVTXaDgi5lS6KrBGMdN1YUI+ci2JQ6gXuVYb/v5Z/G4wFnNbAB
	5vmvGV973PXIE6QBTvan4WIrBHKe7Ifyoij7l+0sztABBiUkcw4pDYO+ciwRIZRsCd5jlS6sLQY
	Lj5H4aNR1JO3AGVHCgIUWa4y/q/uF9O7dcWeoL2iPGaOpCSBXbi9WaO4H+FE7DI+dkWX/v24wxH
	vXMEGXHNwuRZZngD32JT9MNrlKPedsKuHoWB3nmNXoO6HUq4FscA+XNRla6tyKBxaLSmfleqXGj
	y9SR8fLmENOm8j79NCTLwQw0k4/PeHMZU2n8W/EuqRR3FgmzrFk0nDYKI6mshw=
X-Received: by 2002:a17:907:3c83:b0:c21:7584:fc58 with SMTP id a640c23a62f3a-c246a60cd41mr503998966b.12.1787301929532;
        Fri, 21 Aug 2026 01:45:29 -0700 (PDT)
Message-ID: <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
Date: Fri, 21 Aug 2026 10:45:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: George Dunlap <gwd@xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787301930-DFAD487B-D099EA2C/0/0
X-purgate-type: clean
X-purgate-size: 856

On 20.08.2026 19:43, George Dunlap wrote:
> One point reviewers may want to look at specifically: patch 1 changes
> where the per-domain page-tables are allocated from, and its commit
> message discusses the (minor) NUMA-placement consequence.

While I don't recall which recent patch (series) it was, I can't very well
say "no new xenheap allocations please" there without also saying so here.
I've read over patch 1's description, and while it tries to justify this
accordingly, I still remain concerned. I think we simply have to accept
the mapping overhead, to avoid allocating from a pool which - over time -
is representing a decreasing portion of total memory systems have (on
average, and not even considering systems with extremely sparse memory
layouts, and with perhaps PDX compression not doing good enough to
compensate).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 08:51:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 08:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397230.1634591 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKyF-00075o-7g; Fri, 21 Aug 2026 08:51:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397230.1634591; Fri, 21 Aug 2026 08:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxKyF-00075h-4l; Fri, 21 Aug 2026 08:51:27 +0000
Received: by outflank-mailman (input) for mailman id 1397230;
 Fri, 21 Aug 2026 08:51:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wxKyE-00075b-Fs
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 08:51:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxKyD-00BLsr-LR
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 10:51:25 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a88117a-bab6-0a2a0a5309dd-0a2a4508d552-22
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:51:22 +0200
Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a88118a-f659-0a2a45080019-d155da2fe975-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 10:51:22 +0200
Received: by mail-ej1-f47.google.com with SMTP id
 a640c23a62f3a-c1670dad7a8so140094366b.3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 01:51:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c24589e1b22sm335368666b.9.2026.08.21.01.51.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 21 Aug 2026 01:51:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787302282; x=1787907082; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=PFT/pHnrSFjXlJZiw9C1ljCMjkuf3hUnHlq7EH6Wz5Y=;
        b=QXVdJtDU/CTyxXgCjbQHR7J6W2VjpwRMZKynwlIIUq5t3DvgpVe6kATnvPQto78I05
         J4b+Qq/nY9QRVcNW8Z9enFMuLZNfRy52csaaYEujioGRB4/d6GFV4Ft5Cnb2U3QnFytT
         QOXobIc6E00My1FT9/orxEFvCR/ChK3BNMkS4InvT4ONfraNoMK7iKju14DKsoHyICy5
         bnR1clGKZYeL+1/Ntri4WFHhyORkk3+RmxigDSqQFQB/BZGhHSuP7zDUtbIhYXyq2d3w
         G0n1fFZ6jZWqO8zqyVQZTOxJhb0hz7CPfDXGRfV+x1TV8r3eMe5/eS/p/n7bvYs3q7lA
         bpyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787302282; x=1787907082;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=PFT/pHnrSFjXlJZiw9C1ljCMjkuf3hUnHlq7EH6Wz5Y=;
        b=WDcJqpF+u8RKPHxXSdmsPeR5We0VS3qNa5e4D0ICJkpw4ojhks5rfFttg3hL96tyKH
         fhk9iW3q0DdxRxkLGagPvuYzNQN+RWF5yl75Z+7tjDI4UbpJc0BlWeZY0a62GUIVUSV9
         ZLt8ogOldwPmvqUwWX6VBnSMi4BqHnTyk/kxEmy8SnSwlqJFA6cLwfqnfB55QLI8hbRj
         ATGpnQMSPGi04ICn8W2HzO+gDlLsfNhFR+rgTNomMv5cVIkpHpJ5xrjCnxCbo8aTSxQQ
         jUtHPG5b0YTKDPQp0OQ8S6c0OHxsG5BAwA0cJCVdOATluZ2va4QOV/Qs62eRSEO5jLyf
         iIpA==
X-Forwarded-Encrypted: i=1; AHgh+RrFx81D+V/qgUhe1k+LdNkOyHfKYseHQs03oLohLriGQJhlaWYZAEohWg5kZ1zgkGB1SEfirHeopfI=@lists.xenproject.org
X-Gm-Message-State: AFuF++m8SwJbcOLrnlQnrIr2Xt34VkvHEvVqrFXc1lI8rgrPaiA6QgLN
	xgXONzM6UNmyxTQRX5foeRvTa86oLaInmYZRd/zdm3n0ePIjMtqFBLLNcbnZCaGTHQ==
X-Gm-Gg: AR+sD13T4hAG+nyCECh/ndNRn7/lVgFrM3KTNdHqMpb5GFL+RV67Xj883QkR01tTnEb
	6u0xqgM1/S2PTxP0eFER4kDVkiFNCMfqGLpfOID9kHgxV9cSEVOKT94VDea9KIpKovkG2gON/0Q
	XZUs7ktoTsYiIo/Aar4mrXlPvgj+5sDpBRzF0JnMsYerCtGzweWzfBm4Wzl13MUPVNG3HGdODZ2
	Luz9L3KbL6Qak8sb6vpy8XJDsaNH1+LC8L53sL75Z7oqMEt+7S8uKvcsXd0y7RcwD1LUqGkuC0w
	p0iakWn2eT0xdRIEsX2jS9HjcMxtEbpkW0/+VFGjSlusUe9qZ1YbZ/DrJCnr+od7OlWB9lwEYXE
	h5qgMUieszAdtGPnA64fAfXSnXDBPVb1+uTz26pU/Le1NDxLJkeCAiWNElAveDaQZRzXMGFmRkk
	ofjTsXZ257hpKjr+UUr5hVkzA92yzxTXRxwunUwmvHXcos+Y19eKSELMJ9Kz/PRV21kSBFcQjEh
	T8ObVYlw0Pa5rza30wJkXJIvcxH4ykeHlp2EztLCBat9MZkd+8W
X-Received: by 2002:a17:907:9308:b0:c12:695b:8876 with SMTP id a640c23a62f3a-c246a39efb5mr530633466b.5.1787302282308;
        Fri, 21 Aug 2026 01:51:22 -0700 (PDT)
Message-ID: <79a5b821-e2c9-4e64-b2cf-1f839e2037d0@suse.com>
Date: Fri, 21 Aug 2026 10:51:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/amd: Expand comment about NullSelectorClearsBase
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Xen-devel <xen-devel@lists.xenproject.org>
References: <20260820172640.2072049-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260820172640.2072049-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787302282-D574B87B-A9C1E3F1/0/0
X-purgate-type: clean
X-purgate-size: 821

On 20.08.2026 19:26, Andrew Cooper wrote:
> Rework detect_zen2_null_seg_behaviour() to use the new MSR infrastructure.
> 
> Zen2 doesn't have WRMSRNS so don't bother relaxing the write.  All it will do
> is insert a useless alternative.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> Naming Zen2/3 in init_hygon() isn't ideal, but the early hygons really were
> not far removed from the AMD microarchitectures.

I wonder what we should do about Hygon. Just recently I saw patches going into
somewhere (gcc?) to support recent hardware. We haven't seen any contributions
in many years to keep our support up-to-date. We may want/need to consider
removing support if that code is effectively unmaintained.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 09:25:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 09:25:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397253.1634601 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxLUh-0003FS-L0; Fri, 21 Aug 2026 09:24:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397253.1634601; Fri, 21 Aug 2026 09:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxLUh-0003FL-IG; Fri, 21 Aug 2026 09:24:59 +0000
Received: by outflank-mailman (input) for mailman id 1397253;
 Fri, 21 Aug 2026 09:24:59 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrewprecious388@gmail.com>) id 1wxLUg-0003FF-Pm
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 09:24:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxLUf-00BSQU-Gq
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 11:24:57 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a881965-2eae-0a2a0a5409dd-0a2a450aa7aa-18
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 11:24:57 +0200
Received: from [209.85.214.181] (helo=mail-pl1-f181.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a881967-f2d2-0a2a450a0019-d155d6b5bde7-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 11:24:57 +0200
Received: by mail-pl1-f181.google.com with SMTP id
 d9443c01a7336-2d032846c95so9371275ad.1
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 02:24:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787304295; cv=none;
        d=google.com; s=arc-20260327;
        b=PUdZuYt0Gpv4mFYislA0tzERfE11BIQRgBZft4+NwLQyQh1sX5e5N437XUu2S9yvNO
         OwzwT85M6i46zRTV+HN/h6GtwnM3UL6d22rozfLePv+8iv49MCjMIdFDC6GOfcITTew8
         IsvXtCjEynYILIRjD6BZFP8UrZZn34smI6Q6D1yUBpkYH1KBFXR7e5g4rhWrl1RJz15X
         z+2xXYzXx9xasBygHvteh3yA2EMGznLoSWGWRKnCUAXq5lZh5cdSanJXq2zSdChbMFoK
         BePGbk8tKSsU0gET3/5oc9K39rT14FiReCvLQFGRIOJWybqulZGS7xV/NmALI2d8sHmB
         U2jg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=E4nRm5b1hbQERUTszUQ51KBYoIjLDjCPQXKWoXXPZq4=;
        fh=SygEH9Z7MBlxPm51gae5A7uhhF1jD0TC8uv8zGf6b6I=;
        b=nTw2u7HAbswSSSAQ3WrnlJ7RusPE3k24v6bfwFaeoWEmVNMW4nR04lXyyneo0Q/b8Z
         Vrc6XceKIlC81eO5aMUcP2b2u4GXZ3iN4c7YyR80US/AzCiijvRV9WssqiAMARmErtZP
         Ntu7rT+T6yLufYJw9RxpA3s8UK1mDQWI3rgY+Bf4p6FueLtPquy6gO9mScLzYORmsgMB
         3+09Eov+aGFTXIaxI0OeoopmL+mznoD+XRQOC61UKvvgajFkLH+InNbz6Kt9Pe6tWYZf
         Wev8Hu8HZ3jozrASSoymJkHbmBFs92kpGkvMRxXgQ7Q0Zu8gHZuuAO6ov3H9hOSXaw1h
         NWgA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787304295; x=1787909095; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=E4nRm5b1hbQERUTszUQ51KBYoIjLDjCPQXKWoXXPZq4=;
        b=CBHKIFkXTulQ3F21EmlsOhKt9P5suMBeZMAQOkn2iCuHIetHGkslF/doiAdXda4Z5C
         rxhpeyyXHUPkK+iHwxUMtDz6B2ve1V8MCqxiqxb4R/qJQU1J6Re3Ws56GNRdA0zOLC1P
         yS4MNPHCMJEMgYd/bxOOIz+oA9Tk+6rU/cD3qIGI0OHWHSbcK9GPYCCm1ByRKWz5+y8D
         5NigW2CWc0HCa4AzU+99JHxZ+/SSre9/2o/t8JbAycVQ6lBDUSMjKWqW4YRTEauqXsb1
         BnaVmmdpXhYh8Q8bfcfjf2gCs0FV2U+GcYGEyqaLLcAYofoAvif7fmXLzrh9yfeW7WCN
         3p0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787304295; x=1787909095;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=E4nRm5b1hbQERUTszUQ51KBYoIjLDjCPQXKWoXXPZq4=;
        b=HXmHKtecMfn6gZ4yaobV2xkAgZnGEOXuuxpuiQ0dHCfaG1HUerBH6PgOlaJT31qH7C
         Osv9Pdbn7SLox09Qf1LB0NaOOn/LRg3c0DMNW3dLuos1FL8XjqdxRjG2IwxmxHV+zIYo
         Iixy1mnsFlb7kQCu02YOGjwHU82lCN2ciiE8u67ovGXZWnh4c10kNxo7qQhfXC4eseHK
         Dz9dueo6/b2csNlD6O1aYG0DWVUlL0m1C+jt3cvBuUSIAEXwYzrt63GzaowANJaYJsBI
         PTrOT+w9leeolRSpcePJHgy2JKsUVXVp5tLgiS3vf2LQf5U3FiGcd1hpqheU/LCpTwLa
         ba0w==
X-Forwarded-Encrypted: i=1; AHgh+Rqk+0kX4+TcsKUpJczAdB5qHnHt9WB/NL6xOnmQy/ixtir2lboM4I7KVeYF3lIAv6UByObnRsDwS0E=@lists.xenproject.org
X-Gm-Message-State: AFuF++lPk1NSl4FwKwhsTCyOrU/bY6eGqgGjISvX6D+sK+sSwu7g9znD
	aATMbnT/U5aBqMU7+F7EljDBvPs2TlitUAIK17UbdjPPnU67a1K8GXFZ4MrsXG5J2NeCECHP+2M
	vM4g7Aojx1SBChkn3ajgfHcNslF0r5xc=
X-Gm-Gg: AR+sD10x8VKuMkoCA/lulR2InJLii/T8t9BzDZcS1mLkHk54mP/dkerY/JJmNVHISdx
	2xZmVSkMtM0HL97pJaXBJm7P6OncpI6GPi4WMkGx3+abYDFJEr2egVy65xwMBy+Af/s49v1J9cR
	KDj1Jpv9ISgL+4ViL2CfmA9vpmuAVloTp0wSHGuoI/QDlejnaivIUY8RUnFbpIWefQ++aeR4QHl
	2XwlWUPhbqrPQsgmNlWIX3w8v5BXUvH9BcBPfjeDs/4AfIdBKRi7r3hu7RBPr3BBEXOnAqowJ5C
	xWGtQ5ddZYpCD/S8801NDyyOA1H5nkRGPv20iZOY62E=
X-Received: by 2002:a17:90b:5844:b0:393:1d92:db5 with SMTP id
 98e67ed59e1d1-395c35e1199mr10444070a91.10.1787304295198; Fri, 21 Aug 2026
 02:24:55 -0700 (PDT)
MIME-Version: 1.0
References: <20260819180735.135911-1-andrewprecious388@gmail.com>
 <aee239df-0582-4973-82ae-65688a7d6b9a@suse.com> <CAF14T9mYViiNQfJ8TG1RU0hqf7m6yUH1-yFCzWXXJdQOhmFkgA@mail.gmail.com>
 <cc9dd2bf-bc0d-48b5-a11b-e1e22e26a3b4@suse.com>
In-Reply-To: <cc9dd2bf-bc0d-48b5-a11b-e1e22e26a3b4@suse.com>
From: Andrew Precious <andrewprecious388@gmail.com>
Date: Fri, 21 Aug 2026 12:24:44 +0300
X-Gm-Features: AcwNN1XD9Ne6SN2pN3isA7YECmb-UQH7wC6LwMf0mF6l9QOacjfOWzZfzbV14zc
Message-ID: <CAF14T9nLwfEh_cb+vrh43RWvk3e0WEDvoemL4wD4vmVrbdPVDg@mail.gmail.com>
Subject: Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when
 XSAVE is absent
To: Jan Beulich <jbeulich@suse.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, 
	anthony.perard@vates.tech, xen-devel@lists.xenproject.org
Content-Type: multipart/alternative; boundary="0000000000009ef45706598b3597"
X-purgate-ID: tlsNG-4011c0/1787304297-52EDACFC-8BEF4390/0/0
X-purgate-type: clean
X-purgate-size: 4813

--0000000000009ef45706598b3597
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My thinking before was that the fuzzer mutated some bytes that made the
emulator think cpu_has_xsave was false.

But now I believe that this was caused by an environment issue caused by
the default QEMU virtual cpu model.

The VM has no OSXSAVE flag(but the host does), x86_cpu_policy_fill_native()
initializes with the OSXSAVE bit cleared,hits the assert(cpu_has_xsave)
which then aborts the fuzzer.

On Thu, Aug 20, 2026 at 5:13=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wro=
te:

> On 20.08.2026 14:30, Andrew Precious wrote:
> > I just realized that I attached the binary result without the fuzzer
> error.
> > To generate the previous assertion error I would have to rerun the fuzz=
er
> > again which took many hours(~18hrs). Though that was the only error I
> found
> > after that long.
> >
> > VM machine that I performed the fuzzing on:
> > - A VM running Debian GNU/Linux 13 (trixie)
> > - x86_64,QEMU Virtual CPU version 2.5
>
> What does that mean CPUID-wise, seeing that ...
>
> > On Thu, Aug 20, 2026 at 11:45=E2=80=AFAM Jan Beulich <jbeulich@suse.com=
> wrote:
> >> On 19.08.2026 20:07, Andrew Mbugua wrote:
> >>> While running the x86_instruction_emulator fuzzer via AFL, I
> encountered
> >> an assertion failure in the emul_test_read_xcr() function.
> >>
> >> Thanks for the report.
> >>
> >>> The fuzzer is able to generate a CPU state where cpu_has_xsave is
> false.
> >>
> >> I'm having trouble here: cpu_policy isn't populated from fuzzing input=
,
> and
> >>
> >> /* Intentionally checking OSXSAVE here. */
> >> #define cpu_has_xsave     (cpu_policy.basic.raw[1].c & (1u << 27))
> >>
> >> would mean that upon filling cpu_policy (emul_test_init() ->
> >> x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
> >> suggesting you did the fuzzing on some really old hardware?
>
> ... there was this aspect that I couldn't understand?
>
> Jan
>

--0000000000009ef45706598b3597
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My thinking before was that the fuzzer mutated some bytes =
that made the emulator think cpu_has_xsave was false.<br><br>But now I beli=
eve that this was caused by an environment issue caused by the default QEMU=
 virtual cpu model.<br><br>The VM has no OSXSAVE flag(but the host does), x=
86_cpu_policy_fill_native() initializes with the OSXSAVE bit cleared,hits t=
he assert(cpu_has_xsave) which then aborts the fuzzer.<br></div><br><div cl=
ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Thu, Aug 20, 2026 at 5:13=E2=80=AFPM Jan Beulich &lt;<a href=3D"mai=
lto:jbeulich@suse.com">jbeulich@suse.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">On 20.08.2026 14:30, Andrew Preciou=
s wrote:<br>
&gt; I just realized that I attached the binary result without the fuzzer e=
rror.<br>
&gt; To generate the previous assertion error I would have to rerun the fuz=
zer<br>
&gt; again which took many hours(~18hrs). Though that was the only error I =
found<br>
&gt; after that long.<br>
&gt; <br>
&gt; VM machine that I performed the fuzzing on:<br>
&gt; - A VM running Debian GNU/Linux 13 (trixie)<br>
&gt; - x86_64,QEMU Virtual CPU version 2.5<br>
<br>
What does that mean CPUID-wise, seeing that ...<br>
<br>
&gt; On Thu, Aug 20, 2026 at 11:45=E2=80=AFAM Jan Beulich &lt;<a href=3D"ma=
ilto:jbeulich@suse.com" target=3D"_blank">jbeulich@suse.com</a>&gt; wrote:<=
br>
&gt;&gt; On 19.08.2026 20:07, Andrew Mbugua wrote:<br>
&gt;&gt;&gt; While running the x86_instruction_emulator fuzzer via AFL, I e=
ncountered<br>
&gt;&gt; an assertion failure in the emul_test_read_xcr() function.<br>
&gt;&gt;<br>
&gt;&gt; Thanks for the report.<br>
&gt;&gt;<br>
&gt;&gt;&gt; The fuzzer is able to generate a CPU state where cpu_has_xsave=
 is false.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m having trouble here: cpu_policy isn&#39;t populated from f=
uzzing input, and<br>
&gt;&gt;<br>
&gt;&gt; /* Intentionally checking OSXSAVE here. */<br>
&gt;&gt; #define cpu_has_xsave=C2=A0 =C2=A0 =C2=A0(cpu_policy.basic.raw[1].=
c &amp; (1u &lt;&lt; 27))<br>
&gt;&gt;<br>
&gt;&gt; would mean that upon filling cpu_policy (emul_test_init() -&gt;<br=
>
&gt;&gt; x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are =
you<br>
&gt;&gt; suggesting you did the fuzzing on some really old hardware?<br>
<br>
... there was this aspect that I couldn&#39;t understand?<br>
<br>
Jan<br>
</blockquote></div>

--0000000000009ef45706598b3597--


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 10:44:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 10:44:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397335.1634610 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxMjD-0004qd-4x; Fri, 21 Aug 2026 10:44:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397335.1634610; Fri, 21 Aug 2026 10:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxMjD-0004qV-1G; Fri, 21 Aug 2026 10:44:03 +0000
Received: by outflank-mailman (input) for mailman id 1397335;
 Fri, 21 Aug 2026 10:44:01 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <arthurborsboom@gmail.com>) id 1wxMjB-0004qP-Fg
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 10:44:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxMjA-000UIL-9f
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 12:44:00 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <arthurborsboom@gmail.com>)
 id 6a882bd6-8faa-0a2a0a5109dd-0a2a4505bdfc-44
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 12:44:00 +0200
Received: from [209.85.160.49] (helo=mail-oa1-f49.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <arthurborsboom@gmail.com>)
 id 6a882bef-4cb1-0a2a45050019-d155a031c12d-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 12:44:00 +0200
Received: by mail-oa1-f49.google.com with SMTP id
 586e51a60fabf-4560d6f82edso815319fac.3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 03:43:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787309038; cv=none;
        d=google.com; s=arc-20260327;
        b=DIXucL+DLyVi2AC6P/fAJz2YvnuBhCeIQYoy/l7RCXbEvVssRWyh7iQpdTB8kwJuWj
         2MCz3TNxp7jkQZAKgl3IFMTvYi04kGS5fMyj5QGkfRzLoz4qJK1ACLpi08D7qcGLYM+5
         cO40IP+b6w60ErFp2hzWmASWtW6zIU2JRokg/teAyZmCpRSfDEgHG5MadZNGZGTbgwSS
         vyl8WfZL8DNLPCiUV5ldijC7nJBWfjkt2B2ZfLjxiE8Oph4pkdaPqpOnptFddwF/hrLu
         M3tUr4fmbFstYjEZYnYD5UHppitdsqw4oo094xls94oPvP34ABQv4lJws2pAvy4kfeVh
         N5xA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=ZOWR9w+g70hihMLaUF4mY1ts2YmnaEWXRZ8CiJLICRQ=;
        fh=7sFv6QZAJlpg3YTCZX0B+j1POgKz6Tmh3lBntxDYpAE=;
        b=YoS95d+6gg7o56NcdeYSxXBTCFs8ikzbvu+VNAQ/bnYnjqBwHOFwJQ+t417KmzIy6N
         WktkMTHvUanfAV2ejk5mL0yTdPknhvqaIznQ+TmgzsqnWa9TJ6VjbNsRK8JtKvFbH4Oi
         QPatsh9/MPz0si0xp0b31IYcmUcMLq2o23GnrzTM7zTRQ81V3tKNwDDbpE6XnTAuSQuv
         CBoDKGBh8rtEgt/ou2z2qkByhGVroDDJ2LpkXlPikQOZh7juOdN/529gvzMrwYAP6bSr
         t0Or5LgXE2k8Ip4V1Igy6Ax24Eg+hV72OlGTQZeKZYHQL+i5J8tn88+mvm47vFaQxZ+5
         Bqqw==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787309038; x=1787913838; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ZOWR9w+g70hihMLaUF4mY1ts2YmnaEWXRZ8CiJLICRQ=;
        b=Lyau5IL7uzE605tWizAtn6HPYvqDxQzC6iM7T04Z42MOb52fvfYayLH/5XNgJ47zNQ
         A+K/AtNaNJAVzBSuD9i6+BDuYoxzJhpP/W/wIBGfT9nqhy0UGGDWP62f4tIAS03hnrwh
         2H9lfgHx6fArKVRhjeDPQXY75BvdeC7cMNPSGF+IKoWbWsp9lM1C3TgX2TtEK97aAZJ0
         /xCuWSfVK2tzeFKFIDeA9NRcn0d1ZnNlYhbhzdKwbMHKfqC1h1TG9km09Hz+EJEH0Tof
         ELXtC81GkdqA3DWULyaqseQCE+00422tx+MMKmwtve+RHbEFnDE4mrqANL+uOucYcnic
         IluA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787309038; x=1787913838;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=ZOWR9w+g70hihMLaUF4mY1ts2YmnaEWXRZ8CiJLICRQ=;
        b=X9uVunLSCYSMh9aOx3FuKNfVP8AyhjPq8Z+l5X+6iukC+Vc9gfws/VH2T7EGNeF+tl
         RZ892A+HUrk5YAi8rPl5XwJJNnTIRjW9CsGjlH3ZqgkZwqai4MfRUgvHI495XdtdaXyx
         MK1v2YAsj3lhucwXEtRbC6mv0WIvP/t1IirJbV1eDocvb4QTRc7D8UA5erVuNeV2UAhd
         2XAmxYAL9VizxG8nhEdRZ+8/ydug40ISknleWCPE7oHL7YgPbNBJpe2opWHfd+IRnQW5
         rGwN8RKKoFC+zrn0X4EvWcDb+xOvFR4f2UGxqO10WOU/3GLhwhQ1HrDH3KiayXgK3x/g
         8Rqg==
X-Gm-Message-State: AOJu0YxAOfYQ2O33qx8ZOm7cDg8slNbbPNlhBIcclhcivQaOAoR0Aenf
	fxMwpvfrTeBdYa6EVOSBf0aWg3FOVo5qQZg1EcNP+enKw9c/1mRyqzOONEpGssbQiKYhV9zBmYo
	BYC9s5QTfvcvCJcu0Aix+3J/Oq+v4ZPk=
X-Gm-Gg: AR+sD12jVGbsr9ZYMOoWDTjtYSQb9FrS8ygmDrxdYNjykJApQS0/BeLnmt1sbERKqSz
	ZBYGdGOa1qyMTeUQtp9+UwazxZnWa8BAe94Xfblun91/PZCfQAViqpk0RF4t666h+cldHecdvJC
	jJ95p61EHVRZsmHI6yu3JhRMdqM4dAyhhK82Lwa/Ognro8NYXBwriJinwD24k3pwH+buVR1jHGc
	iResHbwNBSNwNLYqRJqK52UKnCf/Dk0ljLdjaSOlRe/ITzG7UwwVyrSDnPLK5Gu0RIKT20JlGnJ
	AlWI8FhkCgkEmKGOGCl95znVs3iWN5pXbGtEMog08O47lfQjxaeOWe6rmYCCTBfRSYrWGSVLx/N
	3NEOG9HNJ9fwCt+g1YS3TJ2ejmUsm0ChTuPTiAd8KA1mT9E9I2Ud4uw8IhYNxifPR6HBHwTlq/V
	a21TFFgZP3x0s=
X-Received: by 2002:a05:6808:6f85:b0:497:d1e7:5e90 with SMTP id
 5614622812f47-4b2ef484825mr5208862b6e.18.1787309038430; Fri, 21 Aug 2026
 03:43:58 -0700 (PDT)
MIME-Version: 1.0
References: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
 <4a1b5392-93b9-4b9e-bf65-3fb280f385fa@suse.com> <CALUcmU=QNXA8gs8JYy01tLVOH-y8mjZM-GxKzOCoA_3e2QFVwQ@mail.gmail.com>
 <83abdfca-70f3-479d-b7ed-929567c4254d@suse.com>
In-Reply-To: <83abdfca-70f3-479d-b7ed-929567c4254d@suse.com>
From: Arthur Borsboom <arthurborsboom@gmail.com>
Date: Fri, 21 Aug 2026 12:43:40 +0200
X-Gm-Features: AcwNN1Xgl6KFcWGcJH9v3WhpgwhY6UMMbE8UobaFWUGJpE8_HmHns0rOxb3Gnoc
Message-ID: <CALUcmU=QyfQyPL6U9yc2T-HRL1d6cArp5N5O3ob3TyqxHTabtA@mail.gmail.com>
Subject: Re: [BUG] Linux kernel crash in amd_smn_init during PVH Dom0 boot on
 AMD EPYC
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c201ff/1787309040-24D1E2A1-ED118A07/0/0
X-purgate-type: clean
X-purgate-size: 2839

Hi Jan,

The fact that you take the time to tell your side of the story, tells
me you are a different person, than the initial message gave the
impression to me.

I guess we started off on the wrong foot.
Nevertheless, maybe the open source development world is not my place to be.

Thanks for your answer and indeed being one of the people who actually
answers mails from strangers/newbees.
This message won't arrive on the mailing list, because I have
unsubscribed myself, so it is just for you :-)

Enjoy your day.

On Wed, 19 Aug 2026 at 09:52, Jan Beulich <jbeulich@suse.com> wrote:
>
> On 19.08.2026 09:09, Arthur Borsboom wrote:
> >> Well, a pretty natural question: What amount of research have you done yourself?
> >
> > Lovely response. You really know how to motivate people and welcome
> > them into a community.
> >
> > It has taken me about 1,5 day of work to find out why the screen
> > remained black, to determine where the problem was, how to retrieve
> > potential info by a serial-over-LAN console, subscribe to the mailing
> > list, and create this bug report to help.
> >
> > But don't worry, I won't do any debugging anymore for the Xen project,
> > you have made sure of that. No need to respond.
>
> Well, no, I can't really skip responding here. Yes, there was a risk that
> you may take my reply as "not welcoming". Yet please can you try to see
> both sides of the medal? From your initial report, which effectively
> wasn't much more than the dumping of a log with the traces of a crash,
> how could anyone have concluded how little or much work it was for you to
> get there. As much as you have felt offended by my reply, I consider such
> reports as an abuse as well: This is xen-devel@, not xen-users@, and I
> think it is only fair for us to expect that reporters check whether their
> problem was reported before, and whether therefore a fix already exists.
>
> In fact, looking back - you did identify the earlier report. I clearly
> scrolled down too quickly, and I'm sorry for that. The question then is,
> though: What did you expect from re-reporting the issue to xen-devel@?
> A patch for the issue is in flight, yet that patch to be taken is
> nothing any of the Xen developers really have much control over: It's
> not Xen interfacing code in Linux which is affected. So I continue to
> have the feeling that this wasn't helpful at all, and my putting time
> into finding the (apparently) most recent variant of the pending fix was
> not valued / pointless, as I ended up offending you be a non-technical
> aspect of my reply.
>
> As a result I wonder: Would it have left you with better feelings if
> your mail was left entirely unresponded to (as would end up reasonably
> likely, according to my observations over many years)?
>
> Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 13:12:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 13:12:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397486.1634619 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxP2c-00071l-95; Fri, 21 Aug 2026 13:12:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397486.1634619; Fri, 21 Aug 2026 13:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxP2c-00071e-6Q; Fri, 21 Aug 2026 13:12:14 +0000
Received: by outflank-mailman (input) for mailman id 1397486;
 Fri, 21 Aug 2026 13:12:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <brchuckz@aol.com>) id 1wxP2a-00071Y-7K
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 13:12:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxP2Z-007Fcl-KP
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:12:11 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a884ea2-bab6-0a2a0a5309dd-0a2a45019c48-32
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 15:12:11 +0200
Received: from [98.137.68.147] (helo=sonic302-21.consmr.mail.gq1.yahoo.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <brchuckz@aol.com>)
 id 6a884ea9-5984-0a2a45010019-628944938efb-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 15:12:11 +0200
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Aug 2026 13:12:09 +0000
Received: by hermes--production-bf1-54b5569bdc-7hp85 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID be8bd0e2097ea023fd1597134141cdef; 
 Fri, 21 Aug 2026 13:12:07 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787317929; bh=5zVYd1XG2alULCFSufa2I5v6mNIHhhyo27EKgEpsIMs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=D4yB+rRQni0q1CvKdI5RbLiG5JiRHSg6tH38U/lEhlp0kxgtcmAefoweXoxysRFocIT/hF7MPgp12TtYEL7j94ocjsr9xz/d23BSp0LCRCqcGRaQgo4n11rvji3Wk7BmETNCqQWlF3PNlsmjjs2VZuttB/i0dn7ZQBB79XPsgfUQ+E1UA7qfL/c+jxpUQwKhCuSH2rE3QADgAoarCnMWDhxj2PFEk+G9T97CpuKAcu5psWJmRP+vnf8iGafTEB4mEsdkDALRCZLZIO3V7Mpjig1K5O/3lX8cccPhnwS6tiLSCC+vcBn7nONlPziBtRi6CcEs95hUr38VZnNtBYSLsw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787317929; bh=sB5lDNfJerqyBHBh0LK6YLb0P4q43K0eOVdEd/EhEyL=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=J1rsFamuBdhDgqC5KOZ2+dz7lpeVl8ltHjDiUD2EgOPZisKwM6YHHslJTKzOSIPstMDccdm+jju6U/3iUXJsuzhS4+n5QbcYjtZtYPJpg0WVash8nVW1subkSGBn/mCqK4Hidki7r34nG3N7cXSN7S6W7pxKRGddLXXUJLuKmLaE4DaXIJEJKfP/xkePBYG9T5bO3PW28kzxtOyTCdANMQQuJIn4L2ZNRqjH3q8Pw7+xalcvfXhnlcfrjTI1gk9+vk3ezt/Oxhq/Ou+vAAiWeZ5wQ7n3hRDO25pQcO5ZBK7gXtjMgum9KXluVHMT06kTkwgQRz97GPuAwuFydqWBNA==
X-YMail-OSG: 8VWMebkVM1kbktK5MBYZ5yNojDJ_0o4ar9Ck8xZh7LK_MQ38mYB1XlTclm6EdLm
 IKctxdjrDTQkT39m.niTrAv461Q2kAy.jc_n8LAJWQbrIXOmBUSZQ5Hd7lyTdfFTG_5oWgc.maao
 sqP0mg6BeqYR7Nsi6PPeubCKk6e.RV4ZKGCMhMU3StzF7nnpStJBPjj8TTtbhTS_Fdn8fi.roZOo
 7mZxLk.rXayh_mZioN3hA1_ctvijaqV9CETOZFRE1yzo2qSq8948XG1J1shbt4.TNFnqmUQMjgUb
 NJ1qdjS5bM3dAKZf7AT_nF9OmgSw7ye1KbC0DCtSmUxgSmWYIpo34AUIIfLRyvk1_0O0HMJnAqLY
 9Jdu1KU12SEq9HCPyqBhtQYa.qOI4YGZhZkiS6iONCLUhkbopSfwDriUS1qfp9LpDowT5MLk4Hlv
 b933D_BZ.dugMBPokxm5yzNsPYIvwJ0OVAOn5Vtg5TRz3M5OtDI2nYEwrBTQLJ6fcGiy.32ucTyn
 KRmrN8PTuQiO1UQJFwddsKqTgtWuglOJzlzVBCW2RJ3Zvd4EiIyB5a4_F.iRz1oAStl9E1_V.Z9A
 p2fEbELvyCC0QjyM5Vtl0BFMI_3AnFj6nfeb_QXY5e9QEUrP7U_4uX_O.HOqPTyXVXqPdYyUybtZ
 97YIj.Rb7WwkBss0DmNRebwjvSJqXWKDQfVfwduwmx5jVFx13CWv_g4tKVUaDFEQglYFEyKPTKy2
 6LZ7hjLcgPbbjHXNhfMyXfVf6JW3UuWOI2f7HvEQbAkfJ2eSHFFEhPAmrHxs.M7A3aYxGWGv_vCK
 j4CX8HEEC7YRRnZXDcnHjfIYsCJWZyz_8gjmmZHZjVRXEqClkSobOI6zlZv9kCEV83TtcdHOgD9w
 pRlis9SqokoGiWRu2fAfcfDcZ08Ia7et6_uPTzkNxIbuNig7o24THtbRLpAmYtPhuQpl3uWDp6j2
 KC_gOlNzkPfToidVY0RbMxYaE666yPf9.IoMexIguIpkjkKXfTFnuDxxFb.thaEG6rxcChRRDiAj
 rtJIl2uKSealiTjxMP3EjSvW7HBzQpqG0mw9GjbG_EZp7G9ahOHKelmYjtflRYvIFKeQlR5k60eZ
 _WMloQMa1zHpJXkITjrwBnHqGzi_ryc0hcysfBUSY26qGhHgAanqBCopgRGObhkHGuzY9_2anaaz
 qFrx0O2fksuHi3exJ5bLJ8hGT8w6h2UjmIm1gmJ6d85DHwYK0DnH7SwF3zx_9rqZCUwfjxRtNMl4
 NRjpuYTh700oRO3J.2Lmgz6viuKQKZ846c7d0h_93wmMi7K28RlSQNb0NZIbvWOlT7WfO2QWQ2r.
 9y6V93_t4fYaIYbHnCHiU0QoGk0IJQnrkUIjJudnXOXjuoTejyU_aBTDSpBlP7ii8gDXm7oVp8bu
 JS642ZGu8kKZrxOHcwCuPYPZvmtWN5z.EPnm7v2vW_KVNfOYDtMjbL4CsWnBLk_I.93bGFk5zmSE
 mF3IGOGHt7cU_0N41LUlAr2SQqphMr.gXeaqsc1jZAH.fs5aWQbj4rcBIC5yfLFLXbHhSZshk0lU
 KOpIAXWfes4NUjEBAOmCN7MKIbMoT.W1i93FPL44kDY0LlCzNRuseTB_lNjqN0aJgNjKkEXsfe3u
 U.rYpCVdWljIsxyWCTGgLlUkDWBrjvMNHYprpdgvkMoVvbvAk13.MYhUnaOoekjnXMxrpobKpfqn
 lgBjFziF947cBnNlQzHAXZfBbkMu0x9RIcMUvE8k0.56J0QiBAykGza0GCrB4611.EjVA5KA9bCf
 Hkc.woZnLHjMJ5Xl0KeVuFxD0V5c5PMXneZNPoDFyUuxt7jv5ltXIkcDGwlhvqv__SIOWBRM5CMX
 3nVNWgo5HxvkwrjIQ9pDWXtZZ3pD25EgKdwK6wtI0W7YtJhkOGUysWTWX3RvdRSz3CuQuDG48ex5
 AgQSlHR__QptP4HoTy1CCLT2KJnHZwef9YGDMF9AkKJVUzZU5Ap5S4ZFf8Yvs54B3ZCMiIviOJLV
 5SmyoOU7WP5tpoUS0PSINRmRJ6ZwIwQsG8bd.22JLdGDMUk41my5fbyprYeNIJ2C6XHzBieADxuJ
 istIyW1ru9p3k.b9Jy6c3_UC.r9bpHI03dcKkB8PxR3QKRSZtdElWHDGI2PPewOURY5hYnUQjLxj
 isPJZTsGTs7BEGZuHiwfiuz9HLjgsCBJPdXuhd8OOV5ksDlxpjTl2KFRX8WOV8SafZatqK9I1rEd
 vOZ9AkSW1qgSdzleLEP3U8trYIUOu4jHHExlQoagYqvcXxw--
X-Sonic-MF: <brchuckz@aol.com>
X-Sonic-ID: 5c5ac2a8-00ef-4873-a97d-076503ba1328
Message-ID: <24008713-2516-4a26-ab37-acdfc174a5bd@aol.com>
Date: Fri, 21 Aug 2026 09:12:05 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT
 support
To: Jan Beulich <jbeulich@suse.com>
Cc: qemu-devel@nongnu.org, Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>, Tomita Moeko <tomitamoeko@gmail.com>,
 xen-devel <xen-devel@lists.xenproject.org>
References: <20260802050824.10554-1-brchuckz.ref@aol.com>
 <02a7dc18-4184-4e86-84cb-121769187f71@suse.com>
 <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com>
 <d6e603bf-8dc5-4ac7-842f-ff9d1f67b98f@suse.com>
 <fdec0b6b-eddf-4a36-a755-c67963daa9ea@aol.com>
 <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com>
 <bb44067c-6739-4e83-a0fd-cc7ea797048f@aol.com>
 <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com>
 <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com>
 <db8fd04d-bbc7-41c7-8473-b821d7f77d5f@aol.com>
 <302ed12f-40ca-405c-80ca-ac4f2785d754@suse.com>
 <cdae1785-4d9a-4aab-929e-de55c26b7b94@aol.com>
 <10cd9f6b-678b-407b-a51e-70e9ed7a35fd@aol.com>
 <131b1252-b108-4b4c-8457-673ff0d20d5e@suse.com>
 <b14969c8-9676-404e-b7cc-ce13a6d7ff94@aol.com>
 <92022f85-9a53-4db8-b489-fc91c86b413c@suse.com>
 <fa497825-c8f0-4caf-94f5-b37108e31952@aol.com>
 <42521391-885c-4b96-96e9-5da2e4b5efa1@suse.com>
 <e86404e8-9966-44ab-86d1-4bd01a551313@aol.com>
 <069cb01d-47b2-41c5-9956-611b338964e9@suse.com>
Content-Language: en-US
From: Chuck Zmudzinski <brchuckz@aol.com>
In-Reply-To: <069cb01d-47b2-41c5-9956-611b338964e9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Content-Length: 4788
X-purgate-ID: tlsNG-d62444/1787317931-BDE78757-A8F3A6E9/0/0
X-purgate-type: clean
X-purgate-size: 4875

On 8/21/2026 4:19 AM, Jan Beulich wrote:
> On 20.08.2026 18:53, Chuck Zmudzinski wrote:
>> On 8/20/2026 11:17 AM, Jan Beulich wrote:
>>> On 20.08.2026 13:47, Chuck Zmudzinski wrote:
>>>> On 8/20/2026 3:51 AM, Jan Beulich wrote:
>>>>> On 19.08.2026 19:13, Chuck Zmudzinski wrote:
>>>>>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>>>>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>>>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM can get
>>>>>>>>> a copy of the OpRegion and read its contents so most of this can be done in the
>>>>>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch will be more
>>>>>>>>> about avoiding the layering violation than anything else.
>>>>>>>>
>>>>>>>> However, there is one advantage, from the viewpoint of the Xen virtualization platform
>>>>>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in the DM.
>>>>>>>>
>>>>>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide a common
>>>>>>>> solution for extended VBT support for Intel IGD devices that would be compatible with
>>>>>>>> all DM implementations, not just with Qemu. So why not do the patching of the OpRegion
>>>>>>>> in hvmloader?
>>>>>>>
>>>>>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>>>>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>>>>>> screw up that data such that subsequent guests won't work anymore. Hence
>>>>>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>>>>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>>>>>> restricted DM as well.
>>>>>>>
>>>>>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>>>>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>>>>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>>>>>> treatment.
>>>>>>
>>>>>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>>>>>> it functions more or less like a BAR region with the devices's ASLS register
>>>>>> at offset 0xfc in the PCI device config space of the device acting like the
>>>>>> BAR for that region.
>>>>>
>>>>> That is, on real hardware a write to that register moves the OpRegion? That
>>>>> would need following by the DM then, i.e. the DM would need to indicate the
>>>>> original position in the register, and the guest (incl hvmloader) would
>>>>> then be free to relocate it.
>>>>
>>>> Why would that "need following by the DM" when the register in the guest is
>>>> fully emulated, [1] which means that when the guest (incl hvmloader) writes to the
>>>> register, the register on the real hardware is not touched, nor is the OpRegion
>>>> in the host address space moved?
>>>
>>> You said it's BAR-like. If the guest writes to a BAR, the referenced MMIO
>>> region moves accordingly.
>> 
>> It's BAR-like, but it is not actually a BAR (and the OpRegion is not exactly
>> an MMIO region either (it is actually and ACPI thing), so that is not relevant
>> to this patch.
>> 
>> Also, it is fully emulated so when the guest writes to it, the real register on the
>> real device is not touched, as I have said multiple times in my responses to your
>> question.
> 
> No matter how often you said that, I never put that under question. I was asking
> about the behavior of writes (where the behavior on bare hardware would need to
> be reflected in the behavior of the emulated register).
> 
>>>> Here is how I understand how this works in the current implementation and how
>>>> this should be done:
>>>
>>> I'm sorry, but this is getting out of hand, at least as far as I'm concerned.
>>> I've been trying to help, but even just reading your replies has already been
>>> taking way more time than I would have wanted to spend here.
>> 
>> Fair enough. Thank you for the time you have spent on this patch, and also thank
>> you for clearly stating that you don't want to spend any more time on it. So
>> I consider this patch dead unless and until another maintainer shows some interest
>> in it.
> 
> I didn't say I would not look at future versions of the patch. However, for me
> to (usefully) do so, things need to be presented in a way that I can understand
> without knowing all the details of IGD.

Thanks for clarifying. If I do v3 I will try to present things in a way that clearly
answers the questions you have raised here about IGD and provide more information
about IGD than I did in v1/v2 for those who don't know all the details of it.

If I do a v3, you will of course be on the Cc list since I expect you will be one of
the maintainers of the affected code.

Chuck


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 15:17:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 15:17:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397586.1634629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxQzo-0004a6-Pq; Fri, 21 Aug 2026 15:17:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397586.1634629; Fri, 21 Aug 2026 15:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxQzo-0004Zz-LS; Fri, 21 Aug 2026 15:17:28 +0000
Received: by outflank-mailman (input) for mailman id 1397586;
 Fri, 21 Aug 2026 15:17:27 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wxQzn-0004Zt-Tf
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:17:27 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wxQzn-00Ffpw-2B
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:17:27 +0000
Received: from mail-lf1-f46.google.com ([209.85.167.46])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wxQzn-00BBRT-11
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:17:27 +0000
Received: by mail-lf1-f46.google.com with SMTP id
 2adb3069b0e04-5b29599b81cso1373339e87.1
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 08:17:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=T1PpgdtQwbwMYo5qfX3DzMgUut62FE++zqKeHeljF68=; b=Um7JnCXCxteR0aF45/GlNfgiOU
	q/7OI2ZhIa+IA3pJDbL4UXKjR6tTtnjeYfqUeTIFlgXDN8lO9VViXX9L3XkKjhH+8fBLC0DXbNCsF
	rZ+o/S231MQaET31I9wAnSLz8lXEHSgq43T6DfjF4lYX/3TFtxUulmQQ39vr/Jsyahkc=;
X-Forwarded-Encrypted: i=1; AHgh+RqXWFMDdkDIAKZSEcHtC0y5MxptK3Ovt7gfUjeqTiwl2qmMPL6P8LA29pSJcdDn8QxVFEFWsNofbcs=@lists.xenproject.org
X-Gm-Message-State: AFuF++lh6CY3BO83jgCXv4J2HnSY5OsnUvTuZWb2HPe+koT3RqufDgrt
	WTh5XMzmKWltXfZpsMPgvKjWsaMA+iW594J7LEtnxYMmYGelJF3SX8sr0019sCCmiVt2xCO5iaa
	PeysVAuS34KZS0LcZlBj388GX+yr8n0o=
X-Received: by 2002:a05:6512:12d2:b0:5ae:bf31:54ed with SMTP id
 2adb3069b0e04-5b4841e89cbmr2139198e87.7.1787325446029; Fri, 21 Aug 2026
 08:17:26 -0700 (PDT)
MIME-Version: 1.0
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org> <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
In-Reply-To: <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Fri, 21 Aug 2026 16:17:13 +0100
X-Gmail-Original-Message-ID: <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
X-Gm-Features: AcwNN1W2W86zxeq2b6bOTUIXo21OgaFUEH1osK008rlWSMtOz2Kn24olPD2OdBc
Message-ID: <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 21, 2026 at 9:45=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wro=
te:
>
> On 20.08.2026 19:43, George Dunlap wrote:
> > One point reviewers may want to look at specifically: patch 1 changes
> > where the per-domain page-tables are allocated from, and its commit
> > message discusses the (minor) NUMA-placement consequence.
>
> While I don't recall which recent patch (series) it was, I can't very wel=
l
> say "no new xenheap allocations please" there without also saying so here=
.
> I've read over patch 1's description, and while it tries to justify this
> accordingly, I still remain concerned. I think we simply have to accept
> the mapping overhead, to avoid allocating from a pool which - over time -
> is representing a decreasing portion of total memory systems have (on
> average, and not even considering systems with extremely sparse memory
> layouts, and with perhaps PDX compression not doing good enough to
> compensate).

You should certainly have the same resistance to adding new xenheap
allocations.  But looking at the numbers, I don't see that we're
anywhere near the point where we say, "Absolutely no new xenheap
allocations, regardless of the cost."  domheap+vmap looks like it was
cheap and easy alternative for Teddy, but the alternatives here
aren't, compared to the cost of extra xenheap allocations.

So let's lay everything out.

My understanding is that we have the following two issues allocating
things in the xenheap on systems larger than 4T:

- The total amount of xenheap space is limited to 4 TiB of virtual
  address space.  On some systems, this may correspond to 4 TiB of
  actual RAM; but on a machine whose RAM layout is sparser, the
  actual RAM addressable in this window may be far less

- It's not symmetric NUMA-wise; so the larger the system, the more of
  the xenheap will end up being from the same NUMA node.  This will
  limit Xen's ability to have NUMA-local data structures, and its
  ability to give NUMA-local data to guests running on node 0.

Looking at this series as a whole, although the first patch adds pages
to the xenheap, the end goal of the rest of the work is to remove
pages from the xenheap. Things added in:

- Making the perdomain area per-vCPU, with its pagetables allocated
  from the xenheap, adds a per-vCPU L3 plus an L2+L1 pair for each
  slot in use.  This totals 5 pages/vCPU for HVM guests and 8 pages/vCPU
  for PV guests.

  (Note that the GDT/LDT L1s are already allocated from the xenheap
  today, but per-domain rather than per-vCPU.)

Things removed:

- Per-pCPU stacks -- 8 xenheap pages / pCPU

- AMD VMCB - one xenheap page / vCPU

- VMX guest MSR area: 1 page per vCPU

- sub-page XSAVE areas (~2.7 KiB/vCPU of xmalloc pool today; planned
  follow-on work aggregating other miscellaneous xmalloc'd guest state
  should take this to about a page per vCPU)

To do some math: current security-supported limits for x86 are 4096
pCPUs on a 12TiB system.  Suppose we have an 8:1 vCPU:pCPU ratio, and
an average of 8 vcpus per domain.  So 32768 total vCPUs and 4096
domains.  On a Full ASI system, vcpu-pt on all domains, per-CPU stacks
on, all Intel HVM domains, we get numbers like the following:

Added to xenheap:

- Per-vCPU tables, 5/vCPU (L3; mapcache L2+L1; state-window L2+L1):
  5 =C3=97 32,768 =3D 163,840 pages =3D 640 MiB
- Per-pCPU stack tables, 2/pCPU: 2 =C3=97 4,096 =3D 8,192 pages =3D 32 MiB
  (=E2=86=92 0: these are only written at CPU bring-up and tear-down, so we
  have already moved them to the domheap in the working branch --
  which also makes them NUMA-local unconditionally)
- Per-domain tables: replaced by the per-vCPU sets in vcpu-pt mode =E2=86=
=92 0
- Total added: 172,032 pages =3D 672 MiB

Removed from xenheap:

- Stacks, 8/pCPU: 8 =C3=97 4,096 =3D 32,768 pages =3D 128 MiB
- XSAVE, ~2.7 KiB/vCPU from the xmalloc pools: 32,768 =C3=97 2.7 KiB =E2=89=
=88
  21,600 pages =E2=89=88 86 MiB (0 if guests get AMX =E2=80=94 those areas =
are domheap
  today)
- VMX guest MSR page: lazily allocated, typically absent =E2=86=92 0 (upper
  bound 128 MiB if every vCPU used one)
- Total removed: =E2=89=88 54,400 pages =E2=89=88 214 MiB

Net: +117,600 pages ~ +458 MiB =E2=80=94 against a 4 TiB window (0.011%), o=
n
a 12 TiB host (0.0036%).

An AMD HVM fleet would include VMCB removal (32,768 pages =3D 128 MiB) =E2=
=86=92
net +330 MiB. A PV fleet is the worst case =E2=80=94 8 tables/vCPU (add
GDT/LDT L2+L1 and the per-vCPU root) =E2=86=92 1,056 MiB added, 214 removed=
,
net +842 MiB.

I have explored a number of other options, to various levels of depth.

One is map_domain_page_irqoff(): If the caller promises to keep
interrupts disabled until unmap_domain_page_irqoff(), we can safely
perform maps in a context switch without having to worry about
sync_lazy_execstate.  (This was actually implemented and almost sent
on Tuesday evening, when I noticed your review of Roger's v2 saying,
"Question is whether it's a good idea in the first place to start
using map_domain_page() from the context switch path.  Surely there
are possible alternatives.")  This maps all vcpu pages from the
domheap, adding nothing to the xenheap *or* the vmap area.  But it
costs 9 map/unmap pairs *per context switch*.

I absolutely reject the idea that because on a 12TiB system with 32k
PV vCPUs, we take up an extra 0.02% of the xenheap area, that a laptop
running QubesOS has to do 9 maps and unmaps per context switch.  That
is not a valid cost/benefits tradeoff.  In the worst case we could
just add a switch to such a system, allowing people who find their
xenheap too full to use the mapcache version instead.  (We could even
turn this on automatically at boot based on projected xenheap
utilization.)

There are other options I've explored:

- domheap + vmap; basically, allocate from domheap, map in the vmap
  area.  On paper this sounds like the same thing; the problem is that
  we don't have a simple MFN -> VA mapping, as we do in the xenheap
  case, so the walk is a lot harder; we start to have to do lookups,
  significantly increasing the cost over simple memory reads and math.
  (This is the difference from the intremap table on the VT-d thread:
  that's a leaf structure reached from a single pointer, so a
  permanent vmap costs nothing there.  Pagetable hierarchies are
  exactly the case where the MFN -> VA step is critical: each entry
  read yields an MFN, which the walk has to turn into the next VA.)
  And if we're concerned about "xenheap creep", when we have a 4 TiB
  ceiling, shouldn't we also be worried about "vmap creep", when we
  have a 64 GiB ceiling?

- Stash everything we need; basically, an extension of the current
  gdt_ldt_l1tab functionality.  Allocate everything from the domheap,
  map it in the vmap area (moving gdt_ldt_l1tab there as well), keep
  pointers to all the things we need to modify on context switch, so
  we don't need to walk the tables.  This would basically be, three
  pointers per vCPU: a pointer to its GDT/LDT L1, a pointer to its
  per-vCPU L3, and a pointer to the per-vCPU root_pgt.  (This would
  put ~384 MiB of mappings into the 64 GiB vmap region -- 0.6%, shared
  with ioremap and the fixmap -- to avoid 0.02% of the xenheap
  window.)

Both the vmap options have two complications, compared to the posted
option.  One thing to worry about here would be the additional stress
on the vmap allocator: It's a linear bitmap scan under one global
lock, designed for dozens-to-hundreds of ioremaps, not ~100k
long-lived single-page mappings (32k vCPUs x 3 pages per vCPU in the
"stash everything" case).

The second is that we begin to run into bootstrapping issues.  With
the xenheap approach, we can begin building and walking pagetables
very early in boot in the same manner in which they'll be walked
throughout Xen's lifecycle.  With the vmap approach, we need to deal
with the fact that the vmap area itself isn't up until later.

The final option I looked at was mapping the incoming vcpu's linear
map to edit it ("altlinmap").  That still adds a map/unmap per context
switch, and requires some additional complication to handle
ASI/non-ASI systems.

Xen already consistently allocates its page tables from the xenheap
whenever it needs to access them during a context switch:
alloc_xen_pagetable() has allocated from the domheap since Hongyan's
directmap-removal preparation (those tables are only ever walked in
contexts where map_domain_page() works), but XPTI's per-CPU root_pgt
is alloc_xenheap_page(), precisely because it has to be written on the
context-switch path.  The same for the PV GDT / LDT L1 tables.  The
series follows the same rule for the same reason.

Ultimately, I think there's a lot of wisdom in the saying, "Premature
optimization is the root of all evil."  As I said, it's certainly
right to be on our guard against adding things to xenheap, and look at
alternatives; but we're nowhere near the point where we need to say,
"Absolutely nothing added, regardless of the cost."  The design here
is not locking us into the pages long-term; alternate designs have a
significant cost in terms of authoring, reviewing, code complexity and
maintenance, and code performance.  At such time as we find systems
where the xenheap allocations introduced in this series become a
problem, we have a number of potential ways to mitigate the problem,
including switching to mapcache *on systems with the problem*, or
switching to a number of the other more complicated approaches.

 -George


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 15:36:21 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 15:36:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397606.1634636 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxRI0-0007O1-6R; Fri, 21 Aug 2026 15:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397606.1634636; Fri, 21 Aug 2026 15:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxRI0-0007Nu-3e; Fri, 21 Aug 2026 15:36:16 +0000
Received: by outflank-mailman (input) for mailman id 1397606;
 Fri, 21 Aug 2026 15:36:15 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wxRHz-0007No-6G
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:36:15 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wxRHz-00FgDQ-0E
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:36:14 +0000
Received: from mail-lf1-f43.google.com ([209.85.167.43])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wxRHy-00EKSW-2Q
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 15:36:14 +0000
Received: by mail-lf1-f43.google.com with SMTP id
 2adb3069b0e04-5b45f1cd80eso1113714e87.2
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 08:36:14 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=corrnl7HApta/FO6dLF3SnGijbG7Uv8u4S7s9KnN4Ak=; b=ZBv+hlrvWz+6SCsHuOUTf4IOEH
	AgnHqW+2UgB6175+58itShf4cQgTlljlLoYNdUD2YEDDp7EztsAnpIb2pTA/LKhVRXJGVyU0ztV1U
	kdDLbd1ApwxSXEjLFZlCiEc4yD2xD6mzC8T+v3EzZhfhyBBTnktRJdgF6e/jhNjO6tVU=;
X-Forwarded-Encrypted: i=1; AHgh+Rp925OCODeIbRXbk/mP0imHu/NOBPKK14iRwBwUhI7uS+aExyq8MRHTtexbO1qnQ8gTIG18au195nE=@lists.xenproject.org
X-Gm-Message-State: AFuF++lc+ghklyB4jk0Xzv91DTUjYx0sd7IMowkuOWooecJIpINNKbMN
	EB7eYfgZQfjJHY1kIEZHS2/RRgxBpVmmKIZGHYOoa4Zya6iBiEt/rPIx4ztMh0zTnRlV7cIYidZ
	ewmIFdAEkVOszq5x+JsYqZpRWpNCVRx0=
X-Received: by 2002:a05:6512:1519:10b0:5b2:b808:6913 with SMTP id
 2adb3069b0e04-5b48422b619mr1734292e87.11.1787326573653; Fri, 21 Aug 2026
 08:36:13 -0700 (PDT)
MIME-Version: 1.0
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com> <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
In-Reply-To: <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
From: George Dunlap <gwd@xenproject.org>
Date: Fri, 21 Aug 2026 16:36:00 +0100
X-Gmail-Original-Message-ID: <CAFLBxZYZLMzMwt8uOgVGgjYvZDGgX4sH5ukqf0Vuo6Rxao2JPg@mail.gmail.com>
X-Gm-Features: AcwNN1X8bJAu6NAmy1LkhtXLfWlwzVjQrLKO699ydTTBWJtyKYcOHfh8mPtlEfQ
Message-ID: <CAFLBxZYZLMzMwt8uOgVGgjYvZDGgX4sH5ukqf0Vuo6Rxao2JPg@mail.gmail.com>
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 21, 2026 at 4:17=E2=80=AFPM George Dunlap <gwd@xenproject.org> =
wrote:

> Ultimately, I think there's a lot of wisdom in the saying, "Premature
> optimization is the root of all evil."  As I said, it's certainly
> right to be on our guard against adding things to xenheap, and look at
> alternatives; but we're nowhere near the point where we need to say,
> "Absolutely nothing added, regardless of the cost."  The design here
> is not locking us into the pages long-term; alternate designs have a
> significant cost in terms of authoring, reviewing, code complexity and
> maintenance, and code performance.

To get a sense of how much this approach simplifies things, look at
how patch 1 of this series simplified create_perdomain_mapping; and
look at how much simpler patch 2 is compared to Roger's implementation
[1].  The xenheap option is way easier to review and maintain.

 -George

[1] https://marc.info/?l=3Dxen-devel&m=3D173634640624259


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 20:42:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 20:42:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397824.1634645 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxW4c-0003ps-MD; Fri, 21 Aug 2026 20:42:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397824.1634645; Fri, 21 Aug 2026 20:42:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxW4c-0003pk-IO; Fri, 21 Aug 2026 20:42:46 +0000
Received: by outflank-mailman (input) for mailman id 1397824;
 Fri, 21 Aug 2026 20:42:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jason.Andryuk@amd.com>) id 1wxW4a-0003pe-5J
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 20:42:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxW4Z-00009j-F1
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 22:42:43 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a88b822-8faa-0a2a0a5109dd-0a2a45048ac8-16
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 22:42:42 +0200
Received: from [40.93.201.52]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jason.Andryuk@amd.com>)
 id 6a88b840-b57f-0a2a45040019-285dc934cbb0-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 22:42:42 +0200
Received: from SA1PR04CA0011.namprd04.prod.outlook.com (2603:10b6:806:2ce::18)
 by DS7PR12MB5742.namprd12.prod.outlook.com (2603:10b6:8:71::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.11; Fri, 21 Aug
 2026 20:42:32 +0000
Received: from SN1PEPF000252A1.namprd05.prod.outlook.com
 (2603:10b6:806:2ce:cafe::79) by SA1PR04CA0011.outlook.office365.com
 (2603:10b6:806:2ce::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.11 via Frontend Transport; Fri,
 21 Aug 2026 20:42:31 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SN1PEPF000252A1.mail.protection.outlook.com (10.167.242.8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Fri, 21 Aug 2026 20:42:30 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 21 Aug
 2026 15:42:30 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 21 Aug
 2026 15:42:30 -0500
Received: from [172.31.17.222] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Fri, 21 Aug 2026 15:42:30 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ivpANpnQ6k8Kwa/TyT0ks+0uMxtZkzWlVKhYtul0bSnO5lYRmRpvu45uPqlFitiBNPPHCsl6o8flVUMG+4RqOzs1zmgG/Jn1iuzGr9cwj2lhMgsi8hdoSnpOcwPFOFy+mKPjqCJPth6B1k3jDQy1TB8JQldwcPjmUk6nE2dOc0JePNPGbfyFVOAooHcdH5qvdOYQRFAUNbRYNAInM1t8eHtClK9lNQD2ZsJLjWq6yADtsZbIG3/gLNJdpVF+TRagpgPs8ei4OnqUCoNFXgenXIh4wBnCDCDbJDPkvQ7qCME861Eos5BSHifuSsULGgNBxy2SSQtCwNGZyEyu/2jj/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WfLPMpH8LtRG8qnXzF/foDvebuOFDGtRC45knZK6XFQ=;
 b=yl5qqf0BCM8ByovaDWP5fG6IbsCihBOTiE09sA3hm4XT4Q0rPYfczVJBrh3iJEggcJpjOO7ixitQhpeFoyGa1uJZcY/ul2WCg53IRnBgoVz5IKUzIeL8DlFmrBsBmPYWUA6bDGgYCy0UmgPyMlc+nYdYnqZXUtPOohDmCg7h3GSWwKHW/6SGgGg6RoccEPgSdI9xZZGiM4krjstB70TyVzByu9hTjhXmbkMt2lUpLRfXBOySwmcvkqZshDFkSLXVrT2dK5D+AdleHHvoeOqde9YOu1FmD9vgzQh4bceedaZQrDCSGB7Anuyp+RolnR/ECOdDOa1Y2dkJuB3ujIWB6Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WfLPMpH8LtRG8qnXzF/foDvebuOFDGtRC45knZK6XFQ=;
 b=wpTWSvm04I6h+9XZOgCKJncsDf97pOv89q0ubTlGdYcpUV6BwuOlHn+kZYPlhGUIZ/V2dYf00FGOXYcukynEjH5+0dTdZDVAlJdlMIIMqK8gbDr67QTbAMbRJkvxmSkE0EK5fLnJpA5CDLUXDVirop5v4FAjqDtyry3FsUxaEzE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <170401c0-0d3b-4481-ad3b-e3f149a4843e@amd.com>
Date: Fri, 21 Aug 2026 16:42:29 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [BUG] Linux kernel crash in amd_smn_init during PVH Dom0 boot on
 AMD EPYC
To: Arthur Borsboom <arthurborsboom@gmail.com>, Jan Beulich
	<jbeulich@suse.com>
CC: <xen-devel@lists.xenproject.org>
References: <CALUcmUkm7eL2RtqAn3fJxrMdY4aj8AYzkFZfs7LVwntSLa44Wg@mail.gmail.com>
 <4a1b5392-93b9-4b9e-bf65-3fb280f385fa@suse.com>
 <CALUcmU=QNXA8gs8JYy01tLVOH-y8mjZM-GxKzOCoA_3e2QFVwQ@mail.gmail.com>
Content-Language: en-US
From: Jason Andryuk <jason.andryuk@amd.com>
In-Reply-To: <CALUcmU=QNXA8gs8JYy01tLVOH-y8mjZM-GxKzOCoA_3e2QFVwQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF000252A1:EE_|DS7PR12MB5742:EE_
X-MS-Office365-Filtering-Correlation-Id: 64840380-124a-4bc9-e50a-08deffc4b8f6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700016|1800799024|23010399003|82310400026|10067099003|4143699003|56012099006|11063799006|13003099007|6133799003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	Hfvug27uX88TrL1XSlSUAdg3kAKpHIZBsz1tLXWJ0py5usMp9MXErfroHQxcci2iqQX0OXbyFJj3x/EJFii00eIZojRbOYu9giVmqNCKq+HfnJ4zW8xTWIFsIoHyzjTrE+fACDOBEXrgunsrb5ACcCIzZRmBvtcWmILxOfMPKkJoho0Y/SIt+JQBrokR6B7mxxWSp27a5opEWez/E8+Ak3bpORPi+aa4V2iv3FF/kcf5KadEWbRrTwSc7UQOujv50l5AgRefbdUJZmdNCHCDeGiP6tKCBtjYkyHLkvP5A8l1u96LbX3vC5iS5lQEjU7ojTZKTxOBwTX/ayh1SgK5+LfuYMuYpQWiP0YL0TV5G+ocVWslFoY+J2M+LSzDO5W7OrVd62C1qKL+XTbgAzlhdcujcPeIUMvIPt3/j/HN0EGh6giopR4DCm+fat8AtczRaJfzFqcby5TQBJ8ekokQnV37OwnTbQY2733viETCk5AZJi1Xw7nhwAnT4XCuNvmLgeWQUOTm475kTT6oa1w5lstbmRSidLbhatIVPJjK/8rXO3AVW6UkgBE95U70G2Pq4JpvTcoLWnssqtv23CXWlg2Kv3P9pLd5I+CBynNeIkRGGS6LRBD+v6C/QVp+UAu63JQUjdenxpYxnxYmlg2MM3VASYv79hDANHW16iZIVk4=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(23010399003)(82310400026)(10067099003)(4143699003)(56012099006)(11063799006)(13003099007)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	bqgxChAk7XlRnS2n+Dbcn9SKEIqmFasSal2UtWf5Nfzs/zAlXz119h3kPMMJEmx2VqGGO5p5Ar5dJu/X5PksbwA6attqZHMb73WTV8HbQAwPVUMNYTL82saCRnc/I5OmjUjLBFH6UBRDwl9CHuUKoRGZsfO1By/utd+oN07rmxyVnnoziKvg5EZWjrtRD9xlSxYgnfnAWHIttOvPsmDGLNv3Bo0pU0sB+4sPG+iA6blqm/QuOGPSUJtcrXkTOWVMXGo6mDc+v11peMoM3lrWOZR+qASUpkyMKrB0QZMcy5udpURISP4oUtPRZhBkjCyPRAJVaLnW319SsnyoV5POoa4O3lf0rjOpY00imfSlSiqCUsS029GkfBIETovC+LVW7akEvYz091OZeOOqh6X6wGvfemQz67Fj7LkB87PTgHTApVFE0Mh0LSATlwWgDfkL
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2026 20:42:30.9629
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 64840380-124a-4bc9-e50a-08deffc4b8f6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF000252A1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5742
X-purgate-ID: tlsNG-ebf023/1787344962-C22D4B50-2ECBCDF4/0/0
X-purgate-type: clean
X-purgate-size: 1551

On 2026-08-19 03:09, Arthur Borsboom wrote:
> It has taken me about 1,5 day of work to find out why the screen
> remained black, to determine where the problem was, how to retrieve
> potential info by a serial-over-LAN console, subscribe to the mailing
> list, and create this bug report to help.

Yes, this is annoying :/

> On Wed, 19 Aug 2026 at 08:50, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 18.08.2026 23:47, Arthur Borsboom wrote:
>>> Hi,
>>>
>>> I am encountering an early Linux kernel crash when booting a PVH
>>> Dom0 on an AMD EPYC system (Family 19h Model 97). PV boot on the
>>> same system works fine. The crash occurs during amd_smn_init due
>>> to a divide-by-zero exception.

That looks like the same issue I am trying to fix.

>>> There is a potentially related bug report discussing a Linux patch
>>> addressing AMD SMN initialization under Xen PVH:
>>>
>>> https://patchew.org/linux/20260623211904.3674-1-jason.andryuk@amd.com/
>>>
>>> It seems there was an ongoing discussion between Linux devs who
>>> seem to have the need to align with Xen devs for a proper/future-proof fix.
>>> I am submitting this report to share raw hardware trace data and
>>> help move this forward.

Yes, there was some discussion, but we have agreed on an approach.
>> [1] https://patchew.org/linux/20260814214255.83127-1-jason.andryuk@amd.com/20260814214255.83127-2-jason.andryuk@amd.com/
This v2 is basically what was suggested by a maintainer, so it should be 
picked up - hopefully soon.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Aug 21 21:00:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Aug 2026 21:00:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1397847.1634655 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxWLN-0006Tl-4d; Fri, 21 Aug 2026 21:00:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1397847.1634655; Fri, 21 Aug 2026 21:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxWLN-0006T5-1V; Fri, 21 Aug 2026 21:00:05 +0000
Received: by outflank-mailman (input) for mailman id 1397847;
 Fri, 21 Aug 2026 21:00:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wxWLL-00067M-JN
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 21:00:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxWLK-004LYT-Ss
 for xen-devel@lists.xenproject.org; Fri, 21 Aug 2026 23:00:02 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a88bc2d-bab6-0a2a0a5309dd-0a2a450aa2d2-14
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 23:00:02 +0200
Received: from [40.107.209.62]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a88bc51-f2d2-0a2a450a0019-286bd13eed23-3
 for <xen-devel@lists.xenproject.org>; Fri, 21 Aug 2026 23:00:02 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by BLAPR03MB5602.namprd03.prod.outlook.com (2603:10b6:208:284::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.11; Fri, 21 Aug
 2026 20:59:59 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.008; Fri, 21 Aug 2026
 20:59:59 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ys053x1ZWfn+P9AQt6T195JEEWpJGzD2nBS/XXdCi8lrgPsfokl+Kr/+4bn6Ilbkr1x6dxtzx5Y9FWJ7Ghn1MkQLnbctkLXOubhMGCXTTRFbeG9x6n3kJVaRWB2kjMRrXpJDalQ3Az/IiqFFMTep21i1PtjxDKN+8pGBhD3hDNu3opaXpqZ/I5DrdcUHZwlsQIsuLk926LUbCIO4wanGNHYLZWn3ItInwTdOqdDXmAsbl6fkf76wDi9NLyK2AklPiLZ+Z9LOzJsgN7vkOtHd/Aexn2LNqzqKOIg9VfTBpYDJbQow0rKAEt8aqevDvD8itkQ/fh+y94zyho1AJdeGVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Kzf1sG+yQdDpFyAaYBignx+5rMTEZquy3WfCDRt5Zgo=;
 b=r3t3NSHtV95BVEqV6yJxVRhwEctBuv2A7uLhd8FpUC929qNSKkbTyl5BfZME/IgiB52NubZzZ8DNOk/wubr2kuIBGDBxOmW/QHQCoMpE51pTzS3RcxunL9Ou1ZIMyv/DNfkh2LObP2IO8BsZ8Bnu/jrSbRcp7I/l0rWZGo3d3UpNjflRH0Kw7bc/8UrncLHRyMOEWw92VInszQIc9gbQ3/iQLb/Ghf/H4E6bCwqipCeXnS6nOLsCr1mj5E6TRg1vbToobMBYVh+CClK/8MEL6QE2T0dbeqAq6wU9tqIRs0v5+CPcxvpbyKrIJUq9RMUxZtyGkbdZLD9pYdPts/VZ8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Kzf1sG+yQdDpFyAaYBignx+5rMTEZquy3WfCDRt5Zgo=;
 b=OfKzNR6HnhTqs449DBuVN6OU8LZZEcP6MvZgv7/dJ293CVk/MVLvekCH5hLdcvu+hAv4emn48c5O6AMjutsi5By4WkS/wjO5CJ0Zn4L0ySCVldvIGfxWritXra6We4AWO5cYsm+KBQhcD3T35R6ye202z3sMmi37/CdEKK0i/vw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <62208647-56ef-46b3-a64f-666716864b1b@citrix.com>
Date: Fri, 21 Aug 2026 21:59:55 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
 Jan Beulich <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 3/7] x86/pv: use populate_perdomain_mapping() to map the
 Xen GDT
To: George Dunlap <gwd@xenproject.org>, xen-devel@lists.xenproject.org
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <20260820-asi-part1-3-f2dbd92b8459@xenproject.org>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260820-asi-part1-3-f2dbd92b8459@xenproject.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO3P265CA0020.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:387::14) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BLAPR03MB5602:EE_
X-MS-Office365-Filtering-Correlation-Id: 9077c5f7-b927-497d-f1e1-08deffc72946
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|22082099003|18002099003|56012099006|4143699003|11063799006|10067099003;
X-Microsoft-Antispam-Message-Info:
	b9I1VSyujmwa2bLzvKX/qPRhgdMBGyfp18Jh9KmVNi9I3aW9x2L2dv1CIlAImIUDOBBhE6/WkVHSI4gm9OP09CEygr9twtM/fWMmKlapqXwhZ6xPVRDDG8KV51sM3yL6Dgr6J0liD4gXMWUOvvdhAXlchTx1LR73RcIkwU3nM76eZZFKqNwNql0SGE8Ps7IEeiB+LugNbXMwwiqQLrPoCnnXhR9XX3ZsXp1CnFSgvO7etHnMuVbfsaCHY290ISM6LuNm1yfSU1ZDlMv0RDtOqZ3LV2qkraYDTyUZTA2/zoiO07VKN0+hLq04ZywbwI8GGQE1H/tURfDj6FoM4+kZ+xhQla/iG3V5ELrs4fTSzG1NwSE9RykhJMiXLqhwpcVlLdEEbXDJpJy3iJY6e4ARQ5KotGgq+psPcdwsnSP4bOWXl8ob5x4ApwQ6bEYCcjq1x4FOD2Qt2vK5CdGyXxfgNUne/zxrXOs0rDj/hvy+eDH9GfTFnOf2BLNem2GZvTlpISU6IEVgo/dq7XBKVVzThmzt7oL1ajOjiDBIStRYrLwxFm3wvLA01SF9DVvsZzAb4NuVAkmOhySFrMU5FbjibX7cQaeWypV/Hx8EODu/xxKLwxMgJKTenm9bd3kJo052nNJIG/0hUSHzqjUhrtZZOOUsjeGh6tMsFwQ/6hPFRPo=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?SkVjTEZ4cnI1cmNNaHIyZVgyODJjVXc0eEpTODJtbnBZUlp0eGRvN2M3b2lW?=
 =?utf-8?B?eFRFSjFBMXRNeGF3TTdQTzhGRDFCWXdhcGRsdSs3TEdtQXlyb1dsV1BiR1Y4?=
 =?utf-8?B?aUdSWFdST1ZBUERXNi9FTERwWFJwR3pFdXhVVmtPVzdRcnNGNlRSSFI5QWxP?=
 =?utf-8?B?VjE2SXJGN1NFQk93ZUgwOGtvbDNHa1VPUldzQ2dpTTVaZ2JkYnRlZzVRM3Mr?=
 =?utf-8?B?N3BsSnZhcHlVL3JYTUsrMmZuMDdYTGcyVWltZmtpT0owSFFyeE1ZR2JoM3Jq?=
 =?utf-8?B?M1Juc0lJbDAyWmIyMFNxRWFQK3VnVCtNeDQ3d1ltdTZuN0ZhYlRCSXF2eUxG?=
 =?utf-8?B?K08weldQZ1ZQcXdVN09Fclp6S3VjaTRlYlhMeUs5d1RRemN0SGhkalk4SFBs?=
 =?utf-8?B?a0JicTdDOFFkbitLTHdnUXdGZnpJeTJYQjdWN2RXSmJUbTNPYTVqQ2tKU2lW?=
 =?utf-8?B?WXkxbmV2Ti9YcE14TlM2YUxHdWozaTFEaGVSUG1iYVUrZXpEaHFtb1FDMmNB?=
 =?utf-8?B?N2pBdlRXQ1RDaThHb3FQVEpFbmxERzZNeFpzRVBrbUV2YmsyU0EvWUhUZlNI?=
 =?utf-8?B?NHV1WEF5YTB4TjNnbmNjcmtEeTRNRk9NQlRJSjAxTVNDMkRqT3JhZmlBQmtE?=
 =?utf-8?B?VC9BTE5XaEVLM1cxeDBlTHRUN0FEL0F5aHQ4VVFnL0Y4cyttbjl0d0NHTC80?=
 =?utf-8?B?TWxWWDYybFM5Q0JudkRrd3VOT21DYkROeHJhYkR6dW9KNjVWSzdVdEw3eDhP?=
 =?utf-8?B?MUc0b2o4SFYxbjVxMnlReTFLdVJXZFdiMFVsSEZ1WmdHYmZhNSs3VmxWb3lI?=
 =?utf-8?B?NjBmNGhDeVhzRkNPYVkzM3BjcTZIQ2s0NlpMZVFuS0JNeVNNckpZL0JpdHM1?=
 =?utf-8?B?SEpyMnZ3allIK3U2TjR3eUVDalUzTUU0TkZvcjkydnNFa1BTNnp3T3lidW40?=
 =?utf-8?B?bW5xNGlPZGRIdC83SWd1SGFHait6SVlHN2s5Zyt6b280QUhwZkZuZjcvREJ2?=
 =?utf-8?B?WG85bC9QM3BKeXJnZ25QancxRVRpYUlRSElXbU9Jd2REaHNIekhNQW5lOTJM?=
 =?utf-8?B?WEN2RmNEUTBNaDdqeXRBbWQydDkvUzdyNU1XUlZNSjRvaGZSL2lZcXVxVEsx?=
 =?utf-8?B?alkvdFVGZ01NNW9jVEVUS2dnVlV6dFV1ZHZsOUFUTDVUbVNDQjB6SVhPRWJi?=
 =?utf-8?B?bHpHeTlmb0JLL3RRbVpVdmk5YjRyNVhqSjI2anhlMEw0VjNEYTBaOTkwNXdN?=
 =?utf-8?B?djIrYUdzS0dVVmdhb0E2cURKZEdoZ1JKdUMwT1dVNFE1cUZ1TVdTcWZrUUM4?=
 =?utf-8?B?WmYxRzdndnVLdFdFd0dGMlpHRVBtMmNBQXh6blloTzR5RGxpWG42Sm1kMFJl?=
 =?utf-8?B?KzJEOFY0WUxkNi82TDhEQStDTm5Ha3JYcEZpRmgydkc5cGRzOUsyblZBRWJL?=
 =?utf-8?B?TEV3SGJQVW9HOWJ3elJZVjVxTUVQRTVVUHZXbEVCUEZmbG02ZTdTZ0FYdHh1?=
 =?utf-8?B?ZTRRNE5xU3UzQ0ozR09QeXQvWDFNbEdMK1krQ09OVC9aRGlKa2dNbjlNcXJP?=
 =?utf-8?B?WEpoTnRJOEV0KzFDTXlMUUptczdDdkp1NmVvY2trSUJ2azhLOFZNeWd6dVpH?=
 =?utf-8?B?UkEwTHlBcG8zMzNWZ01zQWhoNGlBSlNHbUVCNjJ5dVEvMEUzTlpFSGZpcXFS?=
 =?utf-8?B?WTE1QVlHeDg3V1BHVno3SUJuUEg5TjAzTFF2ZS9Kckw1K1Z1Y0tLRW1FSXlL?=
 =?utf-8?B?QkJSUlB3aTVpRlU2OWp3bWV1ejg2Q1p6N3JiOVQ1OWtWQVU2MndwSVJqV3Jr?=
 =?utf-8?B?bnVsRk5rcFpkQTNuMm92WU9leW5pU2d0cm1Sem0zdXUyUDIzY1Z6eXd5clZo?=
 =?utf-8?B?OVhsa1FLbU5vNERNWWY0ejBjejhLRGM4NDNyenc1TXJUcFFjaE9zVEYzODl5?=
 =?utf-8?B?NSttc2htQ0kwSmp1UGdmeVd4Y3ZFN1h1cnMxejF0MGZTek5Na0NrMVhORnEr?=
 =?utf-8?B?RkkwWnhsRjFFVGRhZzFvUnpqM0RpNU1oRmw1amZJMEwxTWZyeDlZZWFzMk5U?=
 =?utf-8?B?dUUyRzA1QnQ2N3FHbmNqclFaVDZVTDI3dEFBdWk5cWNnUUJKV3ZOdmswUVpV?=
 =?utf-8?B?SEhFRWk3VGtsc3BYWWw0N013SXQzTnNEcEpINWVYTG5yZnhjVTJqYkZOc3dX?=
 =?utf-8?B?aEdwWnVBT05idjlDOEo3amZBMkdORVJRUGtLcnBWbndUZUtYYUpqSlVLQ3RJ?=
 =?utf-8?B?ZWNPUllqbkRtdndIRSs1Y25YSElTcU1rWmN1V0NVQ29rWCthU0ZMbGsxZzBn?=
 =?utf-8?B?cFBPTitWam5qNjl2dXlLbzNoaWtaR3Nnb0E4ZUtiUzVxeHMvaW9YUFZxcVA0?=
 =?utf-8?Q?ubhL/5aqmPn6OoC0=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9077c5f7-b927-497d-f1e1-08deffc72946
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2026 20:59:59.0992
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7P502RYFPaWxBKpCIA5yYcP5KkJ729LTaaewjCg41J60IWn0SFEO0UzQJOo01+xfq2PAWOp/NNLLE3LtfhDpD59dpuhklAmdKibZYk5cCaw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5602
X-purgate-ID: tlsNG-4011c0/1787346002-534D7CFC-1AC46A41/0/0
X-purgate-type: clean
X-purgate-size: 1573

On 20/08/2026 6:43 pm, George Dunlap wrote:
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 1774966305..2fcaa413f7 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -71,10 +71,10 @@ DEFINE_PER_CPU(uint64_t, efer);
>  static DEFINE_PER_CPU(unsigned long, last_extable_addr);
>  
>  DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, gdt);
> -DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, gdt_l1e);
> +DEFINE_PER_CPU_READ_MOSTLY(mfn_t, gdt_mfn);
>  #ifdef CONFIG_PV32
>  DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, compat_gdt);
> -DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, compat_gdt_l1e);
> +DEFINE_PER_CPU_READ_MOSTLY(mfn_t, compat_gdt_mfn);
>  #endif

I am not convinced by this change.

The reason we had the L1e stashed in the first place is because mfn <->
maddr conversions are expensive.  Stashing the L1e in this way proved to
be a win in the context switch path, despite the fragility it added by
needing to maintain a second form of the same data.

mfn <-> maddr conversions have changed expense since the optimisation
was first put in, but one form is now even more expensive than when the
optimisation was first put in.

Stashing the L1e means doing the conversion once at boot.  Anything else
means doing it on every context switch path.

So what this patch is doing is still keeping the double copy (the
fragility) but reintroducing the expensive part of the operation into
the context switch path.  If you can't keep it being L1e, there's
probably no point keeping the optimisation at all.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat Aug 22 13:33:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 13:33:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398132.1634664 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxlpv-0008Ub-6a; Sat, 22 Aug 2026 13:32:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398132.1634664; Sat, 22 Aug 2026 13:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxlpv-0008UI-0W; Sat, 22 Aug 2026 13:32:39 +0000
Received: by outflank-mailman (input) for mailman id 1398132;
 Sat, 22 Aug 2026 13:32:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dg@treblig.org>) id 1wxlps-0008UC-St
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 13:32:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxlpq-001Vrc-KO; Sat, 22 Aug 2026 15:32:35 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dg@treblig.org>)
 id 6a89a4dd-bab6-0a2a0a5309dd-0a2a450683f2-22
 for <multiple-recipients>; Sat, 22 Aug 2026 15:32:34 +0200
Received: from [46.235.229.95] (helo=mx.treblig.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dg@treblig.org>)
 id 6a89a4ef-195a-0a2a45060019-2eebe55fca10-3
 for <multiple-recipients>; Sat, 22 Aug 2026 15:32:31 +0200
Received: from dg by mx.treblig.org with local (Exim 4.98.2)
 (envelope-from <dg@treblig.org>) id 1wxlpg-00000003p9d-1nWo;
 Sat, 22 Aug 2026 13:32:24 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=bytemarkmx header.d=treblig.org header.i="@treblig.org" header.h="Content-Type:MIME-Version:Message-ID:Subject:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org
	; s=bytemarkmx; h=Content-Type:MIME-Version:Message-ID:Subject:From:Date:From
	:Subject; bh=dioNt5cqvnzuIs/06AJxSQMQHsaZlQOp9S/ZwPDhvSQ=; b=RH33WSxrBI/e66iA
	LpHxUE2cqVLu+GSVRZYtMH8VNKFNkaz5Bc/TJMLgqISEB6uI39PYGffz+aIG89pd6vjeCPp6qUPLi
	1s3sNf8GPMUMUBQaH8JN9AA3KKx1zmsGtsPFLR5Gt0VfP044qr+YLN0LpAlkvS+zfpcyv8jyCnc5H
	2uRLsfEx7WgrfAdY2vSA2sSZ80MYVY8tHAH8xYz/cA0jK5UMibmfodN8S7kzl9ybMqXMczSuSox93
	h8hToss8dwtHzZLnd1Px070OEIkzWo+CqQY8xa06pl+YXiNwI4gRB5/sTn1/4EQWFMsYPDUIXuTJy
	InvAslrlzsPaGK04EA==;
Date: Sat, 22 Aug 2026 13:32:24 +0000
From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org,
	Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= <philmd@mailo.com>,
	Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= <berrange@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alex =?iso-8859-1?Q?Benn=E9e?= <alex.bennee@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
	Ani Sinha <anisinha@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Brian Cain <brian.cain@oss.qualcomm.com>,
	David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Eric Farman <farman@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	David Hildenbrand <david@kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Hyman Huang <infra.ai.cloud@bitdeer.com>,
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>,
	Chinmay Rath <rathc@linux.ibm.com>,
	Glenn Miles <milesg@linux.ibm.com>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Weiwei Li <liwei1518@gmail.com>,
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
	Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
	Chao Liu <chao.liu@processmission.com>,
	Yoshinori Sato <yoshinori.sato@nifty.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org,
	kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
Subject: Re: [PATCH v3 37/49] monitor: tighten monitor_printf*()
Message-ID: <aomk6PSm5FcuMbv4@gallifrey>
References: <20260816-qemu-no-hmp-v3-0-e53fc35bc550@redhat.com>
 <20260816-qemu-no-hmp-v3-37-e53fc35bc550@redhat.com>
 <aoW91OUi2w68yBTR@gallifrey>
 <CAMxuvaz4RA8mSKYZJz9TqVgkRkt0APtdYCO1LOw+qrA3Jj494A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMxuvaz4RA8mSKYZJz9TqVgkRkt0APtdYCO1LOw+qrA3Jj494A@mail.gmail.com>
X-Chocolate: 70 percent or better cocoa solids preferably
X-Operating-System: Linux/6.12.101+deb13-amd64 (x86_64)
X-Uptime: 13:30:55 up 15 days, 17:08,  2 users,  load average: 0.04, 0.03,
 0.00
User-Agent: Mutt/2.2.13 (2024-03-09)
X-purgate-ID: tlsNG-16d1c6/1787405552-FC4034DB-6E249719/0/0
X-purgate-type: clean
X-purgate-size: 306323

* Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> Hi
> 
> On Wed, Aug 19, 2026 at 6:30 PM Dr. David Alan Gilbert <dave@treblig.org> wrote:
> >
> > * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > > Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> > > monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> > > the first parameter from Monitor * to MonitorHMP * to enforce type
> > > safety. The implementation is also simplified: monitor_hmp_vprintf now
> > > directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> > > dispatch via moncls->vprintf.
> > >
> > > The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> > > cast, they are fixed in the following commits.
> > >
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > Hmm, this patch is HUGE.
> > What are the chances of anyone being able to apply this without it conflicting
> > in a bunch of places?
> > Wouldn't it be better to split it into adding the monitor_hmp_ named versions,
> > then splitting the uses into one patch by area and then
> > trickling them in?
> 
> It's possible, but I can take care of the eventual conflicts as well,
> it's not moving so fast.

Hmm well OK, but I think it's going to make it a PITA to merge!
I'd split it into:
  a) Adding the new monitor_hmp_ versions
  b) A bunch doing the switch over
  c) Removing the old named versions.

Dave

> thanks
> 
> >
> > Dave
> >
> > > ---
> > >  audio/audio-hmp-cmds.c                  |   6 +-
> > >  backends/cryptodev-hmp-cmds.c           |   9 +-
> > >  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
> > >  chardev/char-hmp-cmds.c                 |  12 +-
> > >  disas/disas-mon.c                       |  10 +-
> > >  docs/devel/style.rst                    |   2 +-
> > >  docs/devel/writing-monitor-commands.rst |   8 +-
> > >  dump/dump-hmp-cmds.c                    |   5 +-
> > >  hw/char/virtio-serial-bus.c             |  10 +-
> > >  hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
> > >  hw/core/sysbus.c                        |   5 +-
> > >  hw/hexagon/hexagon_tlb.c                |  44 ++---
> > >  hw/i386/kvm/xen-stubs.c                 |   6 +-
> > >  hw/i386/kvm/xen_evtchn.c                |  21 +--
> > >  hw/i386/sgx-hmp-stub.c                  |   3 +-
> > >  hw/i386/sgx.c                           |  29 ++-
> > >  hw/misc/auxbus.c                        |   9 +-
> > >  hw/misc/mos6522-stub.c                  |   3 +-
> > >  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++-------
> > >  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
> > >  hw/pci/pci-stub.c                       |   3 +-
> > >  hw/s390x/s390-skeys.c                   |   9 +-
> > >  hw/s390x/s390-stattrib.c                |  20 +--
> > >  hw/uefi/ovmf-log.c                      |   5 +-
> > >  hw/usb/bus.c                            |  11 +-
> > >  hw/usb/host-libusb.c                    |  21 ++-
> > >  hw/virtio/virtio-hmp-cmds.c             | 297 +++++++++++++++----------------
> > >  hw/xen/xen-bus.c                        |   5 +-
> > >  include/disas/disas.h                   |   4 +-
> > >  include/monitor/hmp.h                   |  12 +-
> > >  migration/dirtyrate.c                   |  46 +++--
> > >  migration/migration-hmp-cmds.c          | 305 ++++++++++++++++----------------
> > >  monitor/hmp-cmds.c                      | 141 +++++++--------
> > >  monitor/hmp.c                           | 143 +++++++--------
> > >  monitor/monitor-internal.h              |   6 -
> > >  monitor/monitor.c                       |  33 ++--
> > >  net/net-hmp-cmds.c                      |  31 ++--
> > >  net/slirp.c                             |  31 ++--
> > >  qom/qom-hmp-cmds.c                      |  27 ++-
> > >  replay/replay-debugging.c               |   5 +-
> > >  stats/stats-hmp-cmds.c                  |  57 +++---
> > >  stubs/hmp-cmd-info_sev.c                |   3 +-
> > >  stubs/monitor-core.c                    |   2 +-
> > >  system/dirtylimit-hmp-cmds.c            |  10 +-
> > >  system/qdev-monitor.c                   |  19 +-
> > >  system/runstate-hmp-cmds.c              |  16 +-
> > >  system/tpm-hmp-cmds.c                   |  29 ++-
> > >  target/i386/cpu-apic.c                  |   3 +-
> > >  target/i386/monitor.c                   | 152 ++++++++--------
> > >  target/i386/sev.c                       |  35 ++--
> > >  target/m68k/monitor.c                   |   3 +-
> > >  target/ppc/monitor.c                    |   3 +-
> > >  target/riscv/monitor.c                  |  55 +++---
> > >  target/sh4/monitor.c                    |  29 ++-
> > >  target/sparc/monitor.c                  |   3 +-
> > >  target/xtensa/monitor.c                 |   3 +-
> > >  tests/unit/test-util-sockets.c          |   2 +-
> > >  tools/qemu-vnc/clipboard.c              |   4 +-
> > >  tools/qemu-vnc/stubs.c                  |   2 +-
> > >  trace/trace-hmp-cmds.c                  |  12 +-
> > >  ui/ui-hmp-cmds.c                        | 115 ++++++------
> > >  util/error-report.c                     |   2 +-
> > >  util/qemu-print.c                       |   4 +-
> > >  63 files changed, 1214 insertions(+), 1329 deletions(-)
> > >
> > > diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
> > > index 4d326ec99fdf..94182fe1d71f 100644
> > > --- a/audio/audio-hmp-cmds.c
> > > +++ b/audio/audio-hmp-cmds.c
> > > @@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
> > >
> > >  void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int i;
> > >      CaptureState *s;
> > >
> > >      warn_report_once("'info capture' is deprecated since v10.2, to be removed");
> > >
> > >      for (s = capture_head.lh_first, i = 0; s; s = s->entries.le_next, ++i) {
> > > -        monitor_printf(mon, "[%d]: ", i);
> > > +        monitor_hmp_printf(hmp, "[%d]: ", i);
> > >          s->ops.info (s->opaque);
> > >      }
> > >  }
> > > @@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *path = qdict_get_str(qdict, "path");
> > >      int freq = qdict_get_try_int(qdict, "freq", 44100);
> > >      int bits = qdict_get_try_int(qdict, "bits", 16);
> > > @@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
> > >      s = g_malloc0 (sizeof (*s));
> > >
> > >      if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
> > > -        monitor_printf(mon, "Failed to add wave capture\n");
> > > +        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
> > >          g_free (s);
> > >          return;
> > >      }
> > > diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
> > > index fb62428d795a..aafa4b970d24 100644
> > > --- a/backends/cryptodev-hmp-cmds.c
> > > +++ b/backends/cryptodev-hmp-cmds.c
> > > @@ -19,7 +19,6 @@
> > >
> > >  void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      QCryptodevInfoList *il;
> > >      QCryptodevBackendServiceTypeList *sl;
> > >      QCryptodevBackendClientList *cl;
> > > @@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
> > >                  services = tmp_services;
> > >              }
> > >          }
> > > -        monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
> > > +        monitor_hmp_printf(hmp, "%s: service=[%s]\n", info->id, services);
> > >
> > >          for (cl = info->client; cl; cl = cl->next) {
> > >              QCryptodevBackendClient *client = cl->value;
> > > -            monitor_printf(mon, "    queue %" PRIu32 ": type=%s\n",
> > > -                           client->queue,
> > > -                           QCryptodevBackendType_str(client->type));
> > > +            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=%s\n",
> > > +                               client->queue,
> > > +                               QCryptodevBackendType_str(client->type));
> > >          }
> > >      }
> > >
> > > diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-cmds.c
> > > index a2666e2f1b9b..7bae4d425c6d 100644
> > > --- a/block/monitor/block-hmp-cmds.c
> > > +++ b/block/monitor/block-hmp-cmds.c
> > > @@ -89,7 +89,6 @@ out:
> > >
> > >  void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      DriveInfo *dinfo;
> > >      QemuOpts *opts;
> > > @@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      switch (dinfo->type) {
> > >      case IF_NONE:
> > > -        monitor_printf(mon, "OK\n");
> > > +        monitor_hmp_printf(hmp, "OK\n");
> > >          break;
> > >      default:
> > >          error_setg(&err, "Can't hot-add drive to type %d", dinfo->type);
> > > @@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdict)
> > >      hmp_handle_error(hmp, err);
> > >  }
> > >
> > > -static void print_block_info(Monitor *mon, BlockInfo *info,
> > > +static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
> > >                               BlockDeviceInfo *inserted, bool verbose)
> > >  {
> > > +    Monitor *mon = MONITOR(hmp);
> > >      ImageInfo *image_info;
> > >
> > >      assert(!info || !info->inserted || info->inserted == inserted);
> > > @@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
> > >      if (info && *info->device) {
> > >          monitor_puts(mon, info->device);
> > >          if (inserted && inserted->node_name) {
> > > -            monitor_printf(mon, " (%s)", inserted->node_name);
> > > +            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
> > >          }
> > >      } else {
> > >          assert(info || inserted);
> > > @@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
> > >      }
> > >
> > >      if (inserted) {
> > > -        monitor_printf(mon, ": %s (%s%s%s%s)\n",
> > > -                       inserted->file,
> > > -                       inserted->drv,
> > > -                       inserted->ro ? ", read-only" : "",
> > > -                       inserted->encrypted ? ", encrypted" : "",
> > > -                       inserted->active ? "" : ", inactive");
> > > +        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
> > > +                           inserted->file,
> > > +                           inserted->drv,
> > > +                           inserted->ro ? ", read-only" : "",
> > > +                           inserted->encrypted ? ", encrypted" : "",
> > > +                           inserted->active ? "" : ", inactive");
> > >      } else {
> > > -        monitor_printf(mon, ": [not inserted]\n");
> > > +        monitor_hmp_printf(hmp, ": [not inserted]\n");
> > >      }
> > >
> > >      if (info) {
> > >          if (info->qdev) {
> > > -            monitor_printf(mon, "    Attached to:      %s\n", info->qdev);
> > > +            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info->qdev);
> > >          }
> > >          if (info->has_io_status && info->io_status != BLOCK_DEVICE_IO_STATUS_OK) {
> > > -            monitor_printf(mon, "    I/O status:       %s\n",
> > > -                           BlockDeviceIoStatus_str(info->io_status));
> > > +            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
> > > +                               BlockDeviceIoStatus_str(info->io_status));
> > >          }
> > >
> > >          if (info->removable) {
> > > -            monitor_printf(mon, "    Removable device: %slocked, tray %s\n",
> > > -                           info->locked ? "" : "not ",
> > > -                           info->tray_open ? "open" : "closed");
> > > +            monitor_hmp_printf(hmp, "    Removable device: %slocked, tray %s\n",
> > > +                               info->locked ? "" : "not ",
> > > +                               info->tray_open ? "open" : "closed");
> > >          }
> > >      }
> > >
> > > @@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
> > > -                   inserted->cache->writeback ? "writeback" : "writethrough",
> > > -                   inserted->cache->direct ? ", direct" : "",
> > > -                   inserted->cache->no_flush ? ", ignore flushes" : "");
> > > +    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
> > > +                       inserted->cache->writeback ? "writeback" : "writethrough",
> > > +                       inserted->cache->direct ? ", direct" : "",
> > > +                       inserted->cache->no_flush ? ", ignore flushes" : "");
> > >
> > >      if (inserted->backing_file) {
> > > -        monitor_printf(mon,
> > > -                       "    Backing file:     %s "
> > > -                       "(chain depth: %" PRId64 ")\n",
> > > -                       inserted->backing_file,
> > > -                       inserted->backing_file_depth);
> > > +        monitor_hmp_printf(hmp,
> > > +                           "    Backing file:     %s "
> > > +                           "(chain depth: %" PRId64 ")\n",
> > > +                           inserted->backing_file,
> > > +                           inserted->backing_file_depth);
> > >      }
> > >
> > >      if (inserted->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF) {
> > > -        monitor_printf(mon, "    Detect zeroes:    %s\n",
> > > +        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
> > >                  BlockdevDetectZeroesOptions_str(inserted->detect_zeroes));
> > >      }
> > >
> > >      if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
> > >          inserted->iops || inserted->iops_rd || inserted->iops_wr)
> > >      {
> > > -        monitor_printf(mon, "    I/O throttling:   bps=%" PRId64
> > > +        monitor_hmp_printf(hmp, "    I/O throttling:   bps=%" PRId64
> > >                          " bps_rd=%" PRId64  " bps_wr=%" PRId64
> > >                          " bps_max=%" PRId64
> > >                          " bps_rd_max=%" PRId64
> > > @@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
> > >      }
> > >
> > >      if (verbose) {
> > > -        monitor_printf(mon, "\nImages:\n");
> > > +        monitor_hmp_printf(hmp, "\nImages:\n");
> > >          image_info = inserted->image;
> > >          while (1) {
> > >              bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, false);
> > > @@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
> > >
> > >  void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      BlockInfoList *block_list, *info;
> > >      BlockDeviceInfoList *blockdev_list, *blockdev;
> > >      const char *device = qdict_get_try_str(qdict, "device");
> > > @@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
> > >          }
> > >
> > >          if (info != block_list) {
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >
> > > -        print_block_info(mon, info->value, info->value->inserted,
> > > +        print_block_info(hmp, info->value, info->value->inserted,
> > >                           verbose);
> > >          printed = true;
> > >      }
> > > @@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
> > >          }
> > >
> > >          if (blockdev != blockdev_list) {
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >
> > > -        print_block_info(mon, NULL, blockdev->value, verbose);
> > > +        print_block_info(hmp, NULL, blockdev->value, verbose);
> > >      }
> > >      qapi_free_BlockDeviceInfoList(blockdev_list);
> > >  }
> > >
> > >  void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      BlockStatsList *stats_list, *stats;
> > >
> > >      stats_list = qmp_query_blockstats(false, false, NULL);
> > > @@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
> > >              continue;
> > >          }
> > >
> > > -        monitor_printf(mon, "%s%s: idle_time_ns=%" PRId64 "\n",
> > > -                       stats != stats_list ? "\n" : "",
> > > -                       stats->value->device,
> > > -                       stats->value->stats->idle_time_ns);
> > > -        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
> > > -                       "operations", "total_time_ns", "merged");
> > > -        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
> > > -                       " %10" PRId64 "\n",
> > > -                       stats->value->stats->rd_bytes,
> > > -                       stats->value->stats->rd_operations,
> > > -                       stats->value->stats->rd_total_time_ns,
> > > -                       stats->value->stats->rd_merged);
> > > -        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
> > > -                       " %10" PRId64 "\n",
> > > -                       stats->value->stats->wr_bytes,
> > > -                       stats->value->stats->wr_operations,
> > > -                       stats->value->stats->wr_total_time_ns,
> > > -                       stats->value->stats->wr_merged);
> > > -        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
> > > -                       "",
> > > -                       stats->value->stats->flush_operations,
> > > -                       stats->value->stats->flush_total_time_ns);
> > > +        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=%" PRId64 "\n",
> > > +                           stats != stats_list ? "\n" : "",
> > > +                           stats->value->device,
> > > +                           stats->value->stats->idle_time_ns);
> > > +        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes",
> > > +                           "operations", "total_time_ns", "merged");
> > > +        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
> > > +                           " %10" PRId64 "\n",
> > > +                           stats->value->stats->rd_bytes,
> > > +                           stats->value->stats->rd_operations,
> > > +                           stats->value->stats->rd_total_time_ns,
> > > +                           stats->value->stats->rd_merged);
> > > +        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
> > > +                           " %10" PRId64 "\n",
> > > +                           stats->value->stats->wr_bytes,
> > > +                           stats->value->stats->wr_operations,
> > > +                           stats->value->stats->wr_total_time_ns,
> > > +                           stats->value->stats->wr_merged);
> > > +        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
> > > +                           "",
> > > +                           stats->value->stats->flush_operations,
> > > +                           stats->value->stats->flush_total_time_ns);
> > >      }
> > >
> > >      qapi_free_BlockStatsList(stats_list);
> > > @@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      BlockJobInfoList *list;
> > >
> > >      list = qmp_query_block_jobs(&error_abort);
> > >
> > >      if (!list) {
> > > -        monitor_printf(mon, "No active jobs\n");
> > > +        monitor_hmp_printf(hmp, "No active jobs\n");
> > >          return;
> > >      }
> > >
> > >      while (list) {
> > >          if (list->value->type == JOB_TYPE_STREAM) {
> > > -            monitor_printf(mon, "Streaming device %s: Completed %" PRId64
> > > -                           " of %" PRId64 " bytes, speed limit %" PRId64
> > > -                           " bytes/s\n",
> > > -                           list->value->device,
> > > -                           list->value->offset,
> > > -                           list->value->len,
> > > -                           list->value->speed);
> > > +            monitor_hmp_printf(hmp, "Streaming device %s: Completed %" PRId64
> > > +                               " of %" PRId64 " bytes, speed limit %" PRId64
> > > +                               " bytes/s\n",
> > > +                               list->value->device,
> > > +                               list->value->offset,
> > > +                               list->value->len,
> > > +                               list->value->speed);
> > >          } else {
> > > -            monitor_printf(mon, "Type %s, device %s: Completed %" PRId64
> > > -                           " of %" PRId64 " bytes, speed limit %" PRId64
> > > -                           " bytes/s\n",
> > > -                           JobType_str(list->value->type),
> > > -                           list->value->device,
> > > -                           list->value->offset,
> > > -                           list->value->len,
> > > -                           list->value->speed);
> > > +            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" PRId64
> > > +                               " of %" PRId64 " bytes, speed limit %" PRId64
> > > +                               " bytes/s\n",
> > > +                               JobType_str(list->value->type),
> > > +                               list->value->device,
> > > +                               list->value->offset,
> > > +                               list->value->len,
> > > +                               list->value->speed);
> > >          }
> > >          list = list->next;
> > >      }
> > > @@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      BlockDriverState *bs, *bs1;
> > >      BdrvNextIterator it1;
> > >      QEMUSnapshotInfo *sn_tab, *sn;
> > > @@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> > >      nb_sns = bdrv_snapshot_list(bs, &sn_tab);
> > >
> > >      if (nb_sns < 0) {
> > > -        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
> > > +        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_sns);
> > >          return;
> > >      }
> > >
> > > @@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> > >      }
> > >
> > >      if (no_snapshot) {
> > > -        monitor_printf(mon, "There is no snapshot available.\n");
> > > +        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
> > >          return;
> > >      }
> > >
> > > @@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> > >              }
> > >          }
> > >      }
> > > -    monitor_printf(mon, "List of snapshots present on all disks:\n");
> > > +    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n");
> > >
> > >      if (total > 0) {
> > >          bdrv_snapshot_dump(NULL);
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >          for (i = 0; i < total; i++) {
> > >              sn = &sn_tab[global_snapshots[i]];
> > >              /*
> > > @@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> > >               */
> > >              pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
> > >              bdrv_snapshot_dump(sn);
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >      } else {
> > > -        monitor_printf(mon, "None\n");
> > > +        monitor_hmp_printf(hmp, "None\n");
> > >      }
> > >
> > >      QTAILQ_FOREACH(image_entry, &image_list, next) {
> > >          if (QTAILQ_EMPTY(&image_entry->snapshots)) {
> > >              continue;
> > >          }
> > > -        monitor_printf(mon,
> > > -                       "\nList of partial (non-loadable) snapshots on '%s':\n",
> > > -                       image_entry->imagename);
> > > +        monitor_hmp_printf(hmp,
> > > +                           "\nList of partial (non-loadable) snapshots on '%s':\n",
> > > +                           image_entry->imagename);
> > >          bdrv_snapshot_dump(NULL);
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >          QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) {
> > >              bdrv_snapshot_dump(&snapshot_entry->sn);
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >      }
> > >
> > > @@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
> > >      g_free(global_snapshots);
> > >  }
> > >
> > > -void hmp_change_medium(Monitor *mon, const char *device, const char *target,
> > > +void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
> > >                         const char *arg, const char *read_only, bool force,
> > >                         Error **errp)
> > >  {
> > > diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
> > > index 71017fd2d19e..fb0560054b7b 100644
> > > --- a/chardev/char-hmp-cmds.c
> > > +++ b/chardev/char-hmp-cmds.c
> > > @@ -26,12 +26,11 @@
> > >
> > >  void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      ChardevInfoList *char_info, *info;
> > >
> > >      char_info = qmp_query_chardev(NULL);
> > >      for (info = char_info; info; info = info->next) {
> > > -        monitor_printf(mon, "%s: filename=%s\n", info->value->label,
> > > +        monitor_hmp_printf(hmp, "%s: filename=%s\n", info->value->label,
> > >                                                   info->value->filename);
> > >      }
> > >
> > > @@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      uint32_t size = qdict_get_int(qdict, "size");
> > >      const char *chardev = qdict_get_str(qdict, "device");
> > >      char *data;
> > > @@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
> > >          unsigned char ch = data[i];
> > >
> > >          if (ch == '\\') {
> > > -            monitor_printf(mon, "\\\\");
> > > +            monitor_hmp_printf(hmp, "\\\\");
> > >          } else if ((ch < 0x20 && ch != '\n' && ch != '\t') || ch == 0x7F) {
> > > -            monitor_printf(mon, "\\u%04X", ch);
> > > +            monitor_hmp_printf(hmp, "\\u%04X", ch);
> > >          } else {
> > > -            monitor_printf(mon, "%c", ch);
> > > +            monitor_hmp_printf(hmp, "%c", ch);
> > >          }
> > >
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >      g_free(data);
> > >  }
> > >
> > > diff --git a/disas/disas-mon.c b/disas/disas-mon.c
> > > index bc9dec3a7761..32e4220181a8 100644
> > > --- a/disas/disas-mon.c
> > > +++ b/disas/disas-mon.c
> > > @@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
> > >  }
> > >
> > >  /* Disassembler for the monitor.  */
> > > -void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> > > +void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
> > >                     int nb_insn, bool is_physical)
> > >  {
> > >      int count, i;
> > > @@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> > >      s.info.buffer_vma = pc;
> > >
> > >      if (s.info.cap_arch >= 0 && cap_disas_monitor(&s.info, pc, nb_insn)) {
> > > -        monitor_puts(mon, ds->str);
> > > +        monitor_puts(MONITOR(hmp), ds->str);
> > >          return;
> > >      }
> > >
> > >      if (!s.info.print_insn) {
> > > -        monitor_printf(mon, "0x%08" PRIx64
> > > -                       ": Asm output not supported on this arch\n", pc);
> > > +        monitor_hmp_printf(hmp, "0x%08" PRIx64
> > > +                           ": Asm output not supported on this arch\n", pc);
> > >          return;
> > >      }
> > >
> > > @@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> > >          pc += count;
> > >      }
> > >
> > > -    monitor_puts(mon, ds->str);
> > > +    monitor_puts(MONITOR(hmp), ds->str);
> > >  }
> > > diff --git a/docs/devel/style.rst b/docs/devel/style.rst
> > > index 6c5f94cc5098..6876d3a59ec7 100644
> > > --- a/docs/devel/style.rst
> > > +++ b/docs/devel/style.rst
> > > @@ -754,7 +754,7 @@ Error handling and reporting
> > >  Reporting errors to the human user
> > >  ----------------------------------
> > >
> > > -Do not use printf(), fprintf() or monitor_printf().  Instead, use
> > > +Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
> > >  error_report() or error_vreport() from error-report.h.  This ensures the
> > >  error is reported in the right place (current monitor or stderr), and in
> > >  a uniform format.
> > > diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
> > > index 7ae7efe32759..baf94cbdefab 100644
> > > --- a/docs/devel/writing-monitor-commands.rst
> > > +++ b/docs/devel/writing-monitor-commands.rst
> > > @@ -479,7 +479,7 @@ The HMP command
> > >
> > >  Here's the HMP counterpart of the query-option-roms command::
> > >
> > > - void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
> > > + void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
> > >   {
> > >       Error *err = NULL;
> > >       OptionRomInfoList *info_list, *tail;
> > > @@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-roms command::
> > >
> > >       for (tail = info_list; tail; tail = tail->next) {
> > >           info = tail->value;
> > > -         monitor_printf(mon, "%s", info->filename);
> > > +         monitor_hmp_printf(mon, "%s", info->filename);
> > >           if (info->has_bootindex) {
> > > -             monitor_printf(mon, " %" PRId64, info->bootindex);
> > > +             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
> > >           }
> > > -         monitor_printf(mon, "\n");
> > > +         monitor_hmp_printf(mon, "\n");
> > >       }
> > >
> > >       qapi_free_OptionRomInfoList(info_list);
> > > diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
> > > index 104ab5d2a53a..c7045c2d7314 100644
> > > --- a/dump/dump-hmp-cmds.c
> > > +++ b/dump/dump-hmp-cmds.c
> > > @@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      DumpQueryResult *result = qmp_query_dump(NULL);
> > >
> > >      assert(result && result->status < DUMP_STATUS__MAX);
> > > -    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status));
> > > +    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->status));
> > >
> > >      if (result->status == DUMP_STATUS_ACTIVE) {
> > >          float percent = 0;
> > >          assert(result->total != 0);
> > >          percent = 100.0 * result->completed / result->total;
> > > -        monitor_printf(mon, "Finished: %.2f %%\n", percent);
> > > +        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
> > >      }
> > >
> > >      qapi_free_DumpQueryResult(result);
> > > diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
> > > index 02604740f86a..33fdc0846ac3 100644
> > > --- a/hw/char/virtio-serial-bus.c
> > > +++ b/hw/char/virtio-serial-bus.c
> > > @@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
> > >  {
> > >      VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
> > >
> > > -    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
> > > -                   indent, "", port->id,
> > > -                   port->guest_connected ? "on" : "off",
> > > -                   port->host_connected ? "on" : "off",
> > > -                   port->throttled ? "on" : "off");
> > > +    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
> > > +                       indent, "", port->id,
> > > +                       port->guest_connected ? "on" : "off",
> > > +                       port->host_connected ? "on" : "off",
> > > +                       port->throttled ? "on" : "off");
> > >  }
> > >
> > >  /* This function is only used if a port id is not provided by the user */
> > > diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
> > > index 702c798ccc56..10a633af0780 100644
> > > --- a/hw/core/machine-hmp-cmds.c
> > > +++ b/hw/core/machine-hmp-cmds.c
> > > @@ -27,7 +27,6 @@
> > >
> > >  void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CpuInfoFastList *cpu_list, *cpu;
> > >
> > >      cpu_list = qmp_query_cpus_fast(NULL);
> > > @@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
> > >              active = '*';
> > >          }
> > >
> > > -        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
> > > -                       cpu->value->cpu_index);
> > > -        monitor_printf(mon, " thread_id=%" PRId64 " model=%s\n",
> > > -                       cpu->value->thread_id, cpu_model);
> > > +        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
> > > +                           cpu->value->cpu_index);
> > > +        monitor_hmp_printf(hmp, " thread_id=%" PRId64 " model=%s\n",
> > > +                           cpu->value->thread_id, cpu_model);
> > >      }
> > >
> > >      qapi_free_CpuInfoFastList(cpu_list);
> > > @@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      HotpluggableCPUList *l = qmp_query_hotpluggable_cpus(&err);
> > >      HotpluggableCPUList *saved = l;
> > > @@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "Hotpluggable CPUs:\n");
> > > +    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
> > >      while (l) {
> > > -        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
> > > -        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
> > > -                       l->value->vcpus_count);
> > > +        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
> > > +        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
> > > +                           l->value->vcpus_count);
> > >          if (l->value->qom_path) {
> > > -            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_path);
> > > +            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->qom_path);
> > >          }
> > >
> > >          c = l->value->props;
> > > -        monitor_printf(mon, "  CPUInstance Properties:\n");
> > > +        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
> > >          if (c->has_node_id) {
> > > -            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
> > > +            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
> > >          }
> > >          if (c->has_drawer_id) {
> > > -            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
> > > +            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
> > >          }
> > >          if (c->has_book_id) {
> > > -            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
> > > +            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
> > >          }
> > >          if (c->has_socket_id) {
> > > -            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
> > > +            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
> > >          }
> > >          if (c->has_die_id) {
> > > -            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
> > > +            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
> > >          }
> > >          if (c->has_cluster_id) {
> > > -            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
> > > -                           c->cluster_id);
> > > +            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n",
> > > +                               c->cluster_id);
> > >          }
> > >          if (c->has_module_id) {
> > > -            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
> > > -                           c->module_id);
> > > +            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n",
> > > +                               c->module_id);
> > >          }
> > >          if (c->has_core_id) {
> > > -            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
> > > +            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
> > >          }
> > >          if (c->has_thread_id) {
> > > -            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
> > > +            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
> > >          }
> > >
> > >          l = l->next;
> > > @@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      MemdevList *memdev_list = qmp_query_memdev(&err);
> > >      MemdevList *m = memdev_list;
> > > @@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
> > >      while (m) {
> > >          v = string_output_visitor_new(false, &str);
> > >          visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_abort);
> > > -        monitor_printf(mon, "memory backend: %s\n", m->value->id);
> > > -        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
> > > -        monitor_printf(mon, "  merge: %s\n",
> > > -                       m->value->merge ? "true" : "false");
> > > -        monitor_printf(mon, "  dump: %s\n",
> > > -                       m->value->dump ? "true" : "false");
> > > -        monitor_printf(mon, "  prealloc: %s\n",
> > > -                       m->value->prealloc ? "true" : "false");
> > > -        monitor_printf(mon, "  share: %s\n",
> > > -                       m->value->share ? "true" : "false");
> > > +        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
> > > +        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->size);
> > > +        monitor_hmp_printf(hmp, "  merge: %s\n",
> > > +                           m->value->merge ? "true" : "false");
> > > +        monitor_hmp_printf(hmp, "  dump: %s\n",
> > > +                           m->value->dump ? "true" : "false");
> > > +        monitor_hmp_printf(hmp, "  prealloc: %s\n",
> > > +                           m->value->prealloc ? "true" : "false");
> > > +        monitor_hmp_printf(hmp, "  share: %s\n",
> > > +                           m->value->share ? "true" : "false");
> > >          if (m->value->has_reserve) {
> > > -            monitor_printf(mon, "  reserve: %s\n",
> > > -                           m->value->reserve ? "true" : "false");
> > > +            monitor_hmp_printf(hmp, "  reserve: %s\n",
> > > +                               m->value->reserve ? "true" : "false");
> > >          }
> > > -        monitor_printf(mon, "  policy: %s\n",
> > > -                       HostMemPolicy_str(m->value->policy));
> > > +        monitor_hmp_printf(hmp, "  policy: %s\n",
> > > +                           HostMemPolicy_str(m->value->policy));
> > >          visit_complete(v, &str);
> > > -        monitor_printf(mon, "  host nodes: %s\n", str);
> > > +        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
> > >
> > >          g_free(str);
> > >          visit_free(v);
> > >          m = m->next;
> > >      }
> > >
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >
> > >      qapi_free_MemdevList(memdev_list);
> > >      hmp_handle_error(hmp, err);
> > > @@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      KvmInfo *info;
> > >
> > >      info = qmp_query_kvm(NULL);
> > > -    monitor_printf(mon, "kvm support: ");
> > > +    monitor_hmp_printf(hmp, "kvm support: ");
> > >      if (info->present) {
> > > -        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disabled");
> > > +        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "disabled");
> > >      } else {
> > > -        monitor_printf(mon, "not compiled\n");
> > > +        monitor_hmp_printf(hmp, "not compiled\n");
> > >      }
> > >
> > >      qapi_free_KvmInfo(info);
> > > @@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      AcceleratorInfo *info;
> > >      AcceleratorList *accel;
> > >
> > > @@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
> > >      for (accel = info->present; accel; accel = accel->next) {
> > >          char trail = accel->next ? ' ' : '\n';
> > >          if (info->enabled == accel->value) {
> > > -            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value), trail);
> > > +            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->value), trail);
> > >          } else {
> > > -            monitor_printf(mon, "%s%c", Accelerator_str(accel->value), trail);
> > > +            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->value), trail);
> > >          }
> > >      }
> > >
> > > @@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      UuidInfo *info;
> > >
> > >      info = qmp_query_uuid(NULL);
> > > -    monitor_printf(mon, "%s\n", info->UUID);
> > > +    monitor_hmp_printf(hmp, "%s\n", info->UUID);
> > >      qapi_free_UuidInfo(info);
> > >  }
> > >
> > >  void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      BalloonInfo *info;
> > >      Error *err = NULL;
> > >
> > > @@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
> > > +    monitor_hmp_printf(hmp, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
> > >
> > >      qapi_free_BalloonInfo(info);
> > >  }
> > > @@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      uint32_t size = qdict_get_int(qdict, "size");
> > >      const char *filename = qdict_get_str(qdict, "filename");
> > >      uint64_t addr = qdict_get_int(qdict, "val");
> > > @@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
> > >      int cpu_index = monitor_hmp_get_cpu_index(hmp);
> > >
> > >      if (cpu_index < 0) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >
> > > @@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      MemoryDeviceInfoList *info_list = qmp_query_memory_devices(&err);
> > >      MemoryDeviceInfoList *info;
> > > @@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
> > >              case MEMORY_DEVICE_INFO_KIND_NVDIMM:
> > >                  di = value->type == MEMORY_DEVICE_INFO_KIND_DIMM ?
> > >                       value->u.dimm.data : value->u.nvdimm.data;
> > > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > > -                               MemoryDeviceInfoKind_str(value->type),
> > > -                               di->id ? di->id : "");
> > > -                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->addr);
> > > -                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot);
> > > -                monitor_printf(mon, "  node: %" PRId64 "\n", di->node);
> > > -                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size);
> > > -                monitor_printf(mon, "  memdev: %s\n", di->memdev);
> > > -                monitor_printf(mon, "  hotplugged: %s\n",
> > > -                               di->hotplugged ? "true" : "false");
> > > -                monitor_printf(mon, "  hotpluggable: %s\n",
> > > -                               di->hotpluggable ? "true" : "false");
> > > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> > > +                                   MemoryDeviceInfoKind_str(value->type),
> > > +                                   di->id ? di->id : "");
> > > +                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di->addr);
> > > +                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->slot);
> > > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->node);
> > > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->size);
> > > +                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
> > > +                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
> > > +                                   di->hotplugged ? "true" : "false");
> > > +                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
> > > +                                   di->hotpluggable ? "true" : "false");
> > >                  break;
> > >              case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
> > >                  vpi = value->u.virtio_pmem.data;
> > > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > > -                               MemoryDeviceInfoKind_str(value->type),
> > > -                               vpi->id ? vpi->id : "");
> > > -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
> > > -                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size);
> > > -                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
> > > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> > > +                                   MemoryDeviceInfoKind_str(value->type),
> > > +                                   vpi->id ? vpi->id : "");
> > > +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
> > > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->size);
> > > +                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev);
> > >                  break;
> > >              case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
> > >                  vmi = value->u.virtio_mem.data;
> > > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > > -                               MemoryDeviceInfoKind_str(value->type),
> > > -                               vmi->id ? vmi->id : "");
> > > -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
> > > -                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node);
> > > -                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
> > > -                               vmi->requested_size);
> > > -                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size);
> > > -                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->max_size);
> > > -                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
> > > -                               vmi->block_size);
> > > -                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
> > > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> > > +                                   MemoryDeviceInfoKind_str(value->type),
> > > +                                   vmi->id ? vmi->id : "");
> > > +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
> > > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->node);
> > > +                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "\n",
> > > +                                   vmi->requested_size);
> > > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->size);
> > > +                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", vmi->max_size);
> > > +                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
> > > +                                   vmi->block_size);
> > > +                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev);
> > >                  break;
> > >              case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
> > >                  se = value->u.sgx_epc.data;
> > > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > > -                               MemoryDeviceInfoKind_str(value->type),
> > > -                               se->id ? se->id : "");
> > > -                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
> > > -                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size);
> > > -                monitor_printf(mon, "  node: %" PRId64 "\n", se->node);
> > > -                monitor_printf(mon, "  memdev: %s\n", se->memdev);
> > > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> > > +                                   MemoryDeviceInfoKind_str(value->type),
> > > +                                   se->id ? se->id : "");
> > > +                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
> > > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->size);
> > > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->node);
> > > +                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
> > >                  break;
> > >              case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
> > >                  hi = value->u.hv_balloon.data;
> > > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > > -                               MemoryDeviceInfoKind_str(value->type),
> > > -                               hi->id ? hi->id : "");
> > > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> > > +                                   MemoryDeviceInfoKind_str(value->type),
> > > +                                   hi->id ? hi->id : "");
> > >                  if (hi->has_memaddr) {
> > > -                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
> > > -                                   hi->memaddr);
> > > +                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n",
> > > +                                       hi->memaddr);
> > >                  }
> > > -                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->max_size);
> > > +                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", hi->max_size);
> > >                  if (hi->memdev) {
> > > -                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
> > > +                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memdev);
> > >                  }
> > >                  break;
> > >              case MEMORY_DEVICE_INFO_KIND_SP_MEM:
> > >                  spmi = value->u.sp_mem.data;
> > > -                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
> > > -                               MemoryDeviceInfoKind_str(value->type),
> > > -                               spmi->id ? spmi->id : "");
> > > -                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->addr);
> > > -                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->node);
> > > -                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->size);
> > > -                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
> > > +                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
> > > +                                   MemoryDeviceInfoKind_str(value->type),
> > > +                                   spmi->id ? spmi->id : "");
> > > +                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spmi->addr);
> > > +                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi->node);
> > > +                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi->size);
> > > +                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev);
> > >                  break;
> > >              default:
> > >                  g_assert_not_reached();
> > > @@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      GuidInfo *info = qmp_query_vm_generation_id(&err);
> > >      if (info) {
> > > -        monitor_printf(mon, "%s\n", info->guid);
> > > +        monitor_hmp_printf(hmp, "%s\n", info->guid);
> > >      }
> > >      hmp_handle_error(hmp, err);
> > >      qapi_free_GuidInfo(info);
> > > @@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      MemoryInfo *info = qmp_query_memory_size_summary(&err);
> > >      if (info) {
> > > -        monitor_printf(mon, "base memory: %" PRIu64 "\n",
> > > -                       info->base_memory);
> > > +        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
> > > +                           info->base_memory);
> > >
> > >          if (info->has_plugged_memory) {
> > > -            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
> > > -                           info->plugged_memory);
> > > +            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
> > > +                               info->plugged_memory);
> > >          }
> > >
> > >          qapi_free_MemoryInfo(info);
> > > diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> > > index 13df7cbafe10..82130ba04698 100644
> > > --- a/hw/core/sysbus.c
> > > +++ b/hw/core/sysbus.c
> > > @@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
> > >  static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > >  {
> > >      SysBusDevice *s = SYS_BUS_DEVICE(dev);
> > > +    MonitorHMP *hmp = MONITOR_HMP(mon);
> > >      hwaddr size;
> > >      int i;
> > >
> > >      for (i = 0; i < s->num_mmio; i++) {
> > >          size = memory_region_size(s->mmio[i].memory);
> > > -        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> > > -                       indent, "", s->mmio[i].addr, size);
> > > +        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> > > +                           indent, "", s->mmio[i].addr, size);
> > >      }
> > >  }
> > >
> > > diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
> > > index 2d878cee736d..576929ff224b 100644
> > > --- a/hw/hexagon/hexagon_tlb.c
> > > +++ b/hw/hexagon/hexagon_tlb.c
> > > @@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t entry)
> > >
> > >  bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
> > >  {
> > > +    MonitorHMP *hmp = MONITOR_HMP(mon);
> > > +
> > >      if (GET_PTE_V(entry)) {
> > >          uint64_t PA = hex_tlb_phys_addr(entry);
> > >          uint64_t VA = hex_tlb_virt_addr(entry);
> > > -        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
> > > -        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
> > > -                       " A1:%" PRId64 " A0:%" PRId64,
> > > -                       GET_PTE_V(entry),
> > > -                       GET_PTE_G(entry),
> > > -                       GET_PTE_ATR1(entry),
> > > -                       GET_PTE_ATR0(entry));
> > > -        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
> > > -                       GET_PTE_ASID(entry), VA);
> > > -        monitor_printf(mon,
> > > -                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
> > > -                       " U:%" PRId64 " C:%" PRId64,
> > > -                       GET_PTE_X(entry),
> > > -                       GET_PTE_W(entry),
> > > -                       GET_PTE_R(entry),
> > > -                       GET_PTE_U(entry),
> > > -                       GET_PTE_C(entry));
> > > -        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
> > > -                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
> > > -                       hex_tlb_page_size_bytes(entry));
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
> > > +        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
> > > +                           " A1:%" PRId64 " A0:%" PRId64,
> > > +                           GET_PTE_V(entry),
> > > +                           GET_PTE_G(entry),
> > > +                           GET_PTE_ATR1(entry),
> > > +                           GET_PTE_ATR0(entry));
> > > +        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
> > > +                           GET_PTE_ASID(entry), VA);
> > > +        monitor_hmp_printf(hmp,
> > > +                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
> > > +                           " U:%" PRId64 " C:%" PRId64,
> > > +                           GET_PTE_X(entry),
> > > +                           GET_PTE_W(entry),
> > > +                           GET_PTE_R(entry),
> > > +                           GET_PTE_U(entry),
> > > +                           GET_PTE_C(entry));
> > > +        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
> > > +                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
> > > +                           hex_tlb_page_size_bytes(entry));
> > > +        monitor_hmp_printf(hmp, "\n");
> > >          return true;
> > >      }
> > >
> > > diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
> > > index ab1eb14f99e0..5ed71583281a 100644
> > > --- a/hw/i386/kvm/xen-stubs.c
> > > +++ b/hw/i386/kvm/xen-stubs.c
> > > @@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
> > >
> > >  void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
> > > +    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
> > >  }
> > >
> > >  void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
> > > +    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
> > >  }
> > > diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
> > > index 00dff6ee8760..b2135020f27f 100644
> > > --- a/hw/i386/kvm/xen_evtchn.c
> > > +++ b/hw/i386/kvm/xen_evtchn.c
> > > @@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **errp)
> > >
> > >  void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      EvtchnInfoList *iter, *info_list;
> > >      Error *err = NULL;
> > >
> > > @@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
> > >      for (iter = info_list; iter; iter = iter->next) {
> > >          EvtchnInfo *info = iter->value;
> > >
> > > -        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info->vcpu,
> > > -                       EvtchnPortType_str(info->type));
> > > +        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, info->vcpu,
> > > +                           EvtchnPortType_str(info->type));
> > >          if (info->type != EVTCHN_PORT_TYPE_IPI) {
> > > -            monitor_printf(mon,  "(");
> > > +            monitor_hmp_printf(hmp,  "(");
> > >              if (info->remote_domain) {
> > > -                monitor_printf(mon, "%s:", info->remote_domain);
> > > +                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
> > >              }
> > > -            monitor_printf(mon, "%d)", info->target);
> > > +            monitor_hmp_printf(hmp, "%d)", info->target);
> > >          }
> > >          if (info->pending) {
> > > -            monitor_printf(mon, " PENDING");
> > > +            monitor_hmp_printf(hmp, " PENDING");
> > >          }
> > >          if (info->masked) {
> > > -            monitor_printf(mon, " MASKED");
> > > +            monitor_hmp_printf(hmp, " MASKED");
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >      }
> > >
> > >      qapi_free_EvtchnInfoList(info_list);
> > > @@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int port = qdict_get_int(qdict, "port");
> > >      Error *err = NULL;
> > >
> > > @@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
> > >      if (err) {
> > >          hmp_handle_error(hmp, err);
> > >      } else {
> > > -        monitor_printf(mon, "Delivered port %d\n", port);
> > > +        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
> > >      }
> > >  }
> > > -
> > > diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
> > > index a4848ae1d1a7..b7afb26886a8 100644
> > > --- a/hw/i386/sgx-hmp-stub.c
> > > +++ b/hw/i386/sgx-hmp-stub.c
> > > @@ -12,6 +12,5 @@
> > >
> > >  void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    monitor_printf(mon, "SGX is not available in this QEMU\n");
> > > +    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
> > >  }
> > > diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
> > > index 77b41d234c9f..634e33e819ce 100644
> > > --- a/hw/i386/sgx.c
> > > +++ b/hw/i386/sgx.c
> > > @@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
> > >
> > >  void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      SgxEpcSectionList *section_list, *section;
> > >      g_autoptr(SgxInfo) info = qmp_query_sgx(&err);
> > > @@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
> > >          error_report_err(err);
> > >          return;
> > >      }
> > > -    monitor_printf(mon, "SGX support: %s\n",
> > > -                   info->sgx ? "enabled" : "disabled");
> > > -    monitor_printf(mon, "SGX1 support: %s\n",
> > > -                   info->sgx1 ? "enabled" : "disabled");
> > > -    monitor_printf(mon, "SGX2 support: %s\n",
> > > -                   info->sgx2 ? "enabled" : "disabled");
> > > -    monitor_printf(mon, "FLC support: %s\n",
> > > -                   info->flc ? "enabled" : "disabled");
> > > +    monitor_hmp_printf(hmp, "SGX support: %s\n",
> > > +                       info->sgx ? "enabled" : "disabled");
> > > +    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
> > > +                       info->sgx1 ? "enabled" : "disabled");
> > > +    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
> > > +                       info->sgx2 ? "enabled" : "disabled");
> > > +    monitor_hmp_printf(hmp, "FLC support: %s\n",
> > > +                       info->flc ? "enabled" : "disabled");
> > >
> > >      section_list = info->sections;
> > >      for (section = section_list; section; section = section->next) {
> > > -        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
> > > -                       section->value->node);
> > > -        monitor_printf(mon, "size=%" PRIu64 "\n",
> > > -                       section->value->size);
> > > +        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
> > > +                           section->value->node);
> > > +        monitor_hmp_printf(hmp, "size=%" PRIu64 "\n",
> > > +                           section->value->size);
> > >          size += section->value->size;
> > >      }
> > > -    monitor_printf(mon, "total size=%" PRIu64 "\n",
> > > -                   size);
> > > +    monitor_hmp_printf(hmp, "total size=%" PRIu64 "\n",
> > > +                       size);
> > >  }
> > >
> > >  bool check_sgx_support(void)
> > > diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
> > > index ac2525b90fec..ffa76f83016b 100644
> > > --- a/hw/misc/auxbus.c
> > > +++ b/hw/misc/auxbus.c
> > > @@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > >
> > >      s = AUX_SLAVE(dev);
> > >
> > > -    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> > > -                   indent, "",
> > > -                   object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
> > > -                   memory_region_size(s->mmio));
> > > +    monitor_hmp_printf(MONITOR_HMP(mon),
> > > +                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
> > > +                       indent, "",
> > > +                       object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
> > > +                       memory_region_size(s->mmio));
> > >  }
> > >
> > >  void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
> > > diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
> > > index 6a7d76292f00..154cd32ed88b 100644
> > > --- a/hw/misc/mos6522-stub.c
> > > +++ b/hw/misc/mos6522-stub.c
> > > @@ -12,6 +12,5 @@
> > >
> > >  void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n");
> > > +    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU\n");
> > >  }
> > > diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp-cmds.c
> > > index 6405ce26dd65..5099d59cc620 100644
> > > --- a/hw/net/rocker/rocker-hmp-cmds.c
> > > +++ b/hw/net/rocker/rocker-hmp-cmds.c
> > > @@ -22,7 +22,6 @@
> > >
> > >  void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *name = qdict_get_str(qdict, "name");
> > >      RockerSwitch *rocker;
> > >      Error *err = NULL;
> > > @@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "name: %s\n", rocker->name);
> > > -    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
> > > -    monitor_printf(mon, "ports: %d\n", rocker->ports);
> > > +    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
> > > +    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
> > > +    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
> > >
> > >      qapi_free_RockerSwitch(rocker);
> > >  }
> > >
> > >  void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      RockerPortList *list, *port;
> > >      const char *name = qdict_get_str(qdict, "name");
> > >      Error *err = NULL;
> > > @@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "            ena/    speed/ auto\n");
> > > -    monitor_printf(mon, "      port  link    duplex neg?\n");
> > > +    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
> > > +    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
> > >
> > >      for (port = list; port; port = port->next) {
> > > -        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
> > > -                       port->value->name,
> > > -                       port->value->enabled ? port->value->link_up ?
> > > -                       "up" : "down" : "!ena",
> > > -                       port->value->speed == 10000 ? "10G" : "??",
> > > -                       port->value->duplex ? "FD" : "HD",
> > > -                       port->value->autoneg ? "Yes" : "No");
> > > +        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
> > > +                           port->value->name,
> > > +                           port->value->enabled ? port->value->link_up ?
> > > +                           "up" : "down" : "!ena",
> > > +                           port->value->speed == 10000 ? "10G" : "??",
> > > +                           port->value->duplex ? "FD" : "HD",
> > > +                           port->value->autoneg ? "Yes" : "No");
> > >      }
> > >
> > >      qapi_free_RockerPortList(list);
> > > @@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      RockerOfDpaFlowList *list, *info;
> > >      const char *name = qdict_get_str(qdict, "name");
> > >      uint32_t tbl_id = qdict_get_try_int(qdict, "tbl_id", -1);
> > > @@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
> > > +    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
> > >
> > >      for (info = list; info; info = info->next) {
> > >          RockerOfDpaFlow *flow = info->value;
> > > @@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> > >          RockerOfDpaFlowAction *action = flow->action;
> > >
> > >          if (flow->hits) {
> > > -            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
> > > -                           key->priority, key->tbl_id, flow->hits);
> > > +            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
> > > +                               key->priority, key->tbl_id, flow->hits);
> > >          } else {
> > > -            monitor_printf(mon, "%-4d %-3d     ",
> > > -                           key->priority, key->tbl_id);
> > > +            monitor_hmp_printf(hmp, "%-4d %-3d     ",
> > > +                               key->priority, key->tbl_id);
> > >          }
> > >
> > >          if (key->has_in_pport) {
> > > -            monitor_printf(mon, " pport %d", key->in_pport);
> > > +            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
> > >              if (mask->has_in_pport) {
> > > -                monitor_printf(mon, "(0x%x)", mask->in_pport);
> > > +                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
> > >              }
> > >          }
> > >
> > >          if (key->has_vlan_id) {
> > > -            monitor_printf(mon, " vlan %d",
> > > -                           key->vlan_id & VLAN_VID_MASK);
> > > +            monitor_hmp_printf(hmp, " vlan %d",
> > > +                               key->vlan_id & VLAN_VID_MASK);
> > >              if (mask->has_vlan_id) {
> > > -                monitor_printf(mon, "(0x%x)", mask->vlan_id);
> > > +                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
> > >              }
> > >          }
> > >
> > >          if (key->has_tunnel_id) {
> > > -            monitor_printf(mon, " tunnel %d", key->tunnel_id);
> > > +            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
> > >              if (mask->has_tunnel_id) {
> > > -                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
> > > +                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
> > >              }
> > >          }
> > >
> > >          if (key->has_eth_type) {
> > >              switch (key->eth_type) {
> > >              case 0x0806:
> > > -                monitor_printf(mon, " ARP");
> > > +                monitor_hmp_printf(hmp, " ARP");
> > >                  break;
> > >              case 0x0800:
> > > -                monitor_printf(mon, " IP");
> > > +                monitor_hmp_printf(hmp, " IP");
> > >                  break;
> > >              case 0x86dd:
> > > -                monitor_printf(mon, " IPv6");
> > > +                monitor_hmp_printf(hmp, " IPv6");
> > >                  break;
> > >              case 0x8809:
> > > -                monitor_printf(mon, " LACP");
> > > +                monitor_hmp_printf(hmp, " LACP");
> > >                  break;
> > >              case 0x88cc:
> > > -                monitor_printf(mon, " LLDP");
> > > +                monitor_hmp_printf(hmp, " LLDP");
> > >                  break;
> > >              default:
> > > -                monitor_printf(mon, " eth type 0x%04x", key->eth_type);
> > > +                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_type);
> > >                  break;
> > >              }
> > >          }
> > > @@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> > >              if ((strcmp(key->eth_src, "01:00:00:00:00:00") == 0) &&
> > >                  mask->eth_src &&
> > >                  (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
> > > -                monitor_printf(mon, " src <any mcast/bcast>");
> > > +                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
> > >              } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") == 0) &&
> > >                  mask->eth_src &&
> > >                  (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
> > > -                monitor_printf(mon, " src <any ucast>");
> > > +                monitor_hmp_printf(hmp, " src <any ucast>");
> > >              } else {
> > > -                monitor_printf(mon, " src %s", key->eth_src);
> > > +                monitor_hmp_printf(hmp, " src %s", key->eth_src);
> > >                  if (mask->eth_src) {
> > > -                    monitor_printf(mon, "(%s)", mask->eth_src);
> > > +                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
> > >                  }
> > >              }
> > >          }
> > > @@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> > >              if ((strcmp(key->eth_dst, "01:00:00:00:00:00") == 0) &&
> > >                  mask->eth_dst &&
> > >                  (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
> > > -                monitor_printf(mon, " dst <any mcast/bcast>");
> > > +                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
> > >              } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") == 0) &&
> > >                  mask->eth_dst &&
> > >                  (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
> > > -                monitor_printf(mon, " dst <any ucast>");
> > > +                monitor_hmp_printf(hmp, " dst <any ucast>");
> > >              } else {
> > > -                monitor_printf(mon, " dst %s", key->eth_dst);
> > > +                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
> > >                  if (mask->eth_dst) {
> > > -                    monitor_printf(mon, "(%s)", mask->eth_dst);
> > > +                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
> > >                  }
> > >              }
> > >          }
> > >
> > >          if (key->has_ip_proto) {
> > > -            monitor_printf(mon, " proto %d", key->ip_proto);
> > > +            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
> > >              if (mask->has_ip_proto) {
> > > -                monitor_printf(mon, "(0x%x)", mask->ip_proto);
> > > +                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
> > >              }
> > >          }
> > >
> > >          if (key->has_ip_tos) {
> > > -            monitor_printf(mon, " TOS %d", key->ip_tos);
> > > +            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
> > >              if (mask->has_ip_tos) {
> > > -                monitor_printf(mon, "(0x%x)", mask->ip_tos);
> > > +                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
> > >              }
> > >          }
> > >
> > >          if (key->ip_dst) {
> > > -            monitor_printf(mon, " dst %s", key->ip_dst);
> > > +            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
> > >          }
> > >
> > >          if (action->has_goto_tbl || action->has_group_id ||
> > >              action->has_new_vlan_id) {
> > > -            monitor_printf(mon, " -->");
> > > +            monitor_hmp_printf(hmp, " -->");
> > >          }
> > >
> > >          if (action->has_new_vlan_id) {
> > > -            monitor_printf(mon, " apply new vlan %d",
> > > -                           ntohs(action->new_vlan_id));
> > > +            monitor_hmp_printf(hmp, " apply new vlan %d",
> > > +                               ntohs(action->new_vlan_id));
> > >          }
> > >
> > >          if (action->has_group_id) {
> > > -            monitor_printf(mon, " write group 0x%08x", action->group_id);
> > > +            monitor_hmp_printf(hmp, " write group 0x%08x", action->group_id);
> > >          }
> > >
> > >          if (action->has_goto_tbl) {
> > > -            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
> > > +            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
> > >          }
> > >
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >      }
> > >
> > >      qapi_free_RockerOfDpaFlowList(list);
> > > @@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      RockerOfDpaGroupList *list, *g;
> > >      const char *name = qdict_get_str(qdict, "name");
> > >      uint8_t type = qdict_get_try_int(qdict, "type", 9);
> > > @@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "id (decode) --> buckets\n");
> > > +    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
> > >
> > >      for (g = list; g; g = g->next) {
> > >          RockerOfDpaGroup *group = g->value;
> > >          bool set = false;
> > >
> > > -        monitor_printf(mon, "0x%08x", group->id);
> > > +        monitor_hmp_printf(hmp, "0x%08x", group->id);
> > >
> > > -        monitor_printf(mon, " (type %s", group->type == 0 ? "L2 interface" :
> > > +        monitor_hmp_printf(hmp, " (type %s", group->type == 0 ? "L2 interface" :
> > >                                           group->type == 1 ? "L2 rewrite" :
> > >                                           group->type == 2 ? "L3 unicast" :
> > >                                           group->type == 3 ? "L2 multicast" :
> > > @@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
> > >                                           "unknown");
> > >
> > >          if (group->has_vlan_id) {
> > > -            monitor_printf(mon, " vlan %d", group->vlan_id);
> > > +            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
> > >          }
> > >
> > >          if (group->has_pport) {
> > > -            monitor_printf(mon, " pport %d", group->pport);
> > > +            monitor_hmp_printf(hmp, " pport %d", group->pport);
> > >          }
> > >
> > >          if (group->has_index) {
> > > -            monitor_printf(mon, " index %d", group->index);
> > > +            monitor_hmp_printf(hmp, " index %d", group->index);
> > >          }
> > >
> > > -        monitor_printf(mon, ") -->");
> > > +        monitor_hmp_printf(hmp, ") -->");
> > >
> > >          if (group->has_set_vlan_id && group->set_vlan_id) {
> > >              set = true;
> > > -            monitor_printf(mon, " set vlan %d",
> > > -                           group->set_vlan_id & VLAN_VID_MASK);
> > > +            monitor_hmp_printf(hmp, " set vlan %d",
> > > +                               group->set_vlan_id & VLAN_VID_MASK);
> > >          }
> > >
> > >          if (group->set_eth_src) {
> > >              if (!set) {
> > >                  set = true;
> > > -                monitor_printf(mon, " set");
> > > +                monitor_hmp_printf(hmp, " set");
> > >              }
> > > -            monitor_printf(mon, " src %s", group->set_eth_src);
> > > +            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
> > >          }
> > >
> > >          if (group->set_eth_dst) {
> > >              if (!set) {
> > > -                monitor_printf(mon, " set");
> > > +                monitor_hmp_printf(hmp, " set");
> > >              }
> > > -            monitor_printf(mon, " dst %s", group->set_eth_dst);
> > > +            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
> > >          }
> > >
> > >          if (group->has_ttl_check && group->ttl_check) {
> > > -            monitor_printf(mon, " check TTL");
> > > +            monitor_hmp_printf(hmp, " check TTL");
> > >          }
> > >
> > >          if (group->has_group_id && group->group_id) {
> > > -            monitor_printf(mon, " group id 0x%08x", group->group_id);
> > > +            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_id);
> > >          }
> > >
> > >          if (group->has_pop_vlan && group->pop_vlan) {
> > > -            monitor_printf(mon, " pop vlan");
> > > +            monitor_hmp_printf(hmp, " pop vlan");
> > >          }
> > >
> > >          if (group->has_out_pport) {
> > > -            monitor_printf(mon, " out pport %d", group->out_pport);
> > > +            monitor_hmp_printf(hmp, " out pport %d", group->out_pport);
> > >          }
> > >
> > >          if (group->has_group_ids) {
> > >              struct uint32List *id;
> > >
> > > -            monitor_printf(mon, " groups [");
> > > +            monitor_hmp_printf(hmp, " groups [");
> > >              for (id = group->group_ids; id; id = id->next) {
> > > -                monitor_printf(mon, "0x%08x", id->value);
> > > +                monitor_hmp_printf(hmp, "0x%08x", id->value);
> > >                  if (id->next) {
> > > -                    monitor_printf(mon, ",");
> > > +                    monitor_hmp_printf(hmp, ",");
> > >                  }
> > >              }
> > > -            monitor_printf(mon, "]");
> > > +            monitor_hmp_printf(hmp, "]");
> > >          }
> > >
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >      }
> > >
> > >      qapi_free_RockerOfDpaGroupList(list);
> > > diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
> > > index 51d95d76620e..500f821246a9 100644
> > > --- a/hw/pci/pci-hmp-cmds.c
> > > +++ b/hw/pci/pci-hmp-cmds.c
> > > @@ -24,54 +24,55 @@
> > >  #include "qapi/qapi-commands-pci.h"
> > >  #include "qemu/cutils.h"
> > >
> > > -static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
> > > +static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *dev)
> > >  {
> > > +    Monitor *mon = MONITOR(hmp);
> > >      PciMemoryRegionList *region;
> > >
> > > -    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
> > > -    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n",
> > > -                   dev->slot, dev->function);
> > > -    monitor_printf(mon, "    ");
> > > +    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
> > > +    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 ":\n",
> > > +                       dev->slot, dev->function);
> > > +    monitor_hmp_printf(hmp, "    ");
> > >
> > >      if (dev->class_info->desc) {
> > >          monitor_puts(mon, dev->class_info->desc);
> > >      } else {
> > > -        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_class);
> > > +        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q_class);
> > >      }
> > >
> > > -    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
> > > -                   dev->id->vendor, dev->id->device);
> > > +    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
> > > +                       dev->id->vendor, dev->id->device);
> > >      if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
> > > -        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
> > > -                       dev->id->subsystem_vendor, dev->id->subsystem);
> > > +        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
> > > +                           dev->id->subsystem_vendor, dev->id->subsystem);
> > >      }
> > >
> > >      if (dev->has_irq) {
> > > -        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
> > > -                       dev->irq, (char)('A' + dev->irq_pin - 1));
> > > +        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
> > > +                           dev->irq, (char)('A' + dev->irq_pin - 1));
> > >      }
> > >
> > >      if (dev->pci_bridge) {
> > > -        monitor_printf(mon, "      BUS %" PRId64 ".\n",
> > > -                       dev->pci_bridge->bus->number);
> > > -        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
> > > -                       dev->pci_bridge->bus->secondary);
> > > -        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
> > > -                       dev->pci_bridge->bus->subordinate);
> > > +        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
> > > +                           dev->pci_bridge->bus->number);
> > > +        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
> > > +                           dev->pci_bridge->bus->secondary);
> > > +        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n",
> > > +                           dev->pci_bridge->bus->subordinate);
> > >
> > > -        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
> > > -                       dev->pci_bridge->bus->io_range->base,
> > > -                       dev->pci_bridge->bus->io_range->limit);
> > > +        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
> > > +                           dev->pci_bridge->bus->io_range->base,
> > > +                           dev->pci_bridge->bus->io_range->limit);
> > >
> > > -        monitor_printf(mon,
> > > -                       "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
> > > -                       dev->pci_bridge->bus->memory_range->base,
> > > -                       dev->pci_bridge->bus->memory_range->limit);
> > > +        monitor_hmp_printf(hmp,
> > > +                           "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
> > > +                           dev->pci_bridge->bus->memory_range->base,
> > > +                           dev->pci_bridge->bus->memory_range->limit);
> > >
> > > -        monitor_printf(mon, "      prefetchable memory range "
> > > -                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
> > > -                       dev->pci_bridge->bus->prefetchable_range->base,
> > > -                       dev->pci_bridge->bus->prefetchable_range->limit);
> > > +        monitor_hmp_printf(hmp, "      prefetchable memory range "
> > > +                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
> > > +                           dev->pci_bridge->bus->prefetchable_range->base,
> > > +                           dev->pci_bridge->bus->prefetchable_range->limit);
> > >      }
> > >
> > >      for (region = dev->regions; region; region = region->next) {
> > > @@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
> > >          addr = region->value->address;
> > >          size = region->value->size;
> > >
> > > -        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->bar);
> > > +        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->value->bar);
> > >
> > >          if (!strcmp(region->value->type, "io")) {
> > >              if (addr != PCI_BAR_UNMAPPED) {
> > > -                monitor_printf(mon, "I/O at 0x%04" PRIx64
> > > +                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
> > >                                      " [0x%04" PRIx64 "]\n",
> > >                                 addr, addr + size - 1);
> > >              } else {
> > > -                monitor_printf(mon, "I/O (not mapped)\n");
> > > +                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
> > >              }
> > >          } else {
> > >              if (addr != PCI_BAR_UNMAPPED) {
> > > -                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
> > > +                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRIx64
> > >                                     " [0x%08" PRIx64 "]\n",
> > >                                 region->value->mem_type_64 ? 64 : 32,
> > >                                 region->value->prefetch ? " prefetchable" : "",
> > >                                 addr, addr + size - 1);
> > >              } else {
> > > -                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
> > > -                               region->value->mem_type_64 ? 64 : 32,
> > > -                               region->value->prefetch ? " prefetchable" : "");
> > > +                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\n",
> > > +                                   region->value->mem_type_64 ? 64 : 32,
> > > +                                   region->value->prefetch ? " prefetchable" : "");
> > >              }
> > >          }
> > >      }
> > >
> > > -    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
> > > +    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
> > >
> > >      if (dev->pci_bridge) {
> > >          if (dev->pci_bridge->has_devices) {
> > >              PciDeviceInfoList *cdev;
> > >              for (cdev = dev->pci_bridge->devices; cdev; cdev = cdev->next) {
> > > -                hmp_info_pci_device(mon, cdev->value);
> > > +                hmp_info_pci_device(hmp, cdev->value);
> > >              }
> > >          }
> > >      }
> > > @@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
> > >
> > >  void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      PciInfoList *info_list, *info;
> > >
> > >      info_list = qmp_query_pci(&error_abort);
> > > @@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
> > >          PciDeviceInfoList *dev;
> > >
> > >          for (dev = info->value->devices; dev; dev = dev->next) {
> > > -            hmp_info_pci_device(mon, dev->value);
> > > +            hmp_info_pci_device(hmp, dev->value);
> > >          }
> > >      }
> > >
> > > @@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > >  {
> > > +    MonitorHMP *hmp = MONITOR_HMP(mon);
> > >      PCIDevice *d = (PCIDevice *)dev;
> > >      int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
> > >      const pci_class_desc *desc = get_class_desc(class);
> > > @@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
> > >          snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
> > >      }
> > >
> > > -    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
> > > -                   "pci id %04x:%04x (sub %04x:%04x)\n",
> > > -                   indent, "", ctxt, pci_dev_bus_num(d),
> > > -                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
> > > -                   pci_get_word(d->config + PCI_VENDOR_ID),
> > > -                   pci_get_word(d->config + PCI_DEVICE_ID),
> > > -                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
> > > -                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
> > > +    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
> > > +                       "pci id %04x:%04x (sub %04x:%04x)\n",
> > > +                       indent, "", ctxt, pci_dev_bus_num(d),
> > > +                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
> > > +                       pci_get_word(d->config + PCI_VENDOR_ID),
> > > +                       pci_get_word(d->config + PCI_DEVICE_ID),
> > > +                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
> > > +                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
> > >      for (i = 0; i < PCI_NUM_REGIONS; i++) {
> > >          r = &d->io_regions[i];
> > >          if (!r->size) {
> > >              continue;
> > >          }
> > > -        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
> > > -                       " [0x%"FMT_PCIBUS"]\n",
> > > -                       indent, "",
> > > -                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
> > > -                       r->addr, r->addr + r->size - 1);
> > > +        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
> > > +                           " [0x%"FMT_PCIBUS"]\n",
> > > +                           indent, "",
> > > +                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
> > > +                           r->addr, r->addr + r->size - 1);
> > >      }
> > >  }
> > >
> > >  void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      const char *id = qdict_get_str(qdict, "id");
> > >      const char *error_name;
> > > @@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
> > >      }
> > >
> > >
> > > -    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
> > > -                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
> > > -                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> > > +    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
> > > +                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
> > > +                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> > >
> > >  out:
> > >      hmp_handle_error(hmp, err);
> > > diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
> > > index a80e34175462..7e2797300ba0 100644
> > > --- a/hw/pci/pci-stub.c
> > > +++ b/hw/pci/pci-stub.c
> > > @@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    monitor_printf(mon, "PCI devices not supported\n");
> > > +    monitor_hmp_printf(hmp, "PCI devices not supported\n");
> > >  }
> > >
> > >  /* kvm-all wants this */
> > > diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
> > > index d8afaf730639..b5e56a16cce1 100644
> > > --- a/hw/s390x/s390-skeys.c
> > > +++ b/hw/s390x/s390-skeys.c
> > > @@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
> > >
> > >  void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      S390SKeysState *ss = s390_get_skeys_device();
> > >      S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
> > >      uint64_t addr = qdict_get_int(qdict, "addr");
> > > @@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      /* Quick check to see if guest is using storage keys*/
> > >      if (!skeyclass->skeys_are_enabled(ss)) {
> > > -        monitor_printf(mon, "Error: This guest is not using storage keys\n");
> > > +        monitor_hmp_printf(hmp, "Error: This guest is not using storage keys\n");
> > >          return;
> > >      }
> > >
> > >      if (!address_space_access_valid(&address_space_memory,
> > >                                      addr & TARGET_PAGE_MASK, TARGET_PAGE_SIZE,
> > >                                      false, MEMTXATTRS_UNSPECIFIED)) {
> > > -        monitor_printf(mon, "Error: The given address is not valid\n");
> > > +        monitor_hmp_printf(hmp, "Error: The given address is not valid\n");
> > >          return;
> > >      }
> > >
> > >      r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
> > >      if (r < 0) {
> > > -        monitor_printf(mon, "Error: %s\n", strerror(-r));
> > > +        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "  key: 0x%X\n", key);
> > > +    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
> > >  }
> > >
> > >  void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
> > > diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
> > > index b4a405455901..644298f7f0b2 100644
> > > --- a/hw/s390x/s390-stattrib.c
> > > +++ b/hw/s390x/s390-stattrib.c
> > > @@ -61,7 +61,6 @@ void s390_stattrib_init(void)
> > >
> > >  void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      S390StAttribState *sas = s390_get_stattrib_device();
> > >      S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
> > >      uint64_t what = qdict_get_int(qdict, "mode");
> > > @@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      r = sac->set_migrationmode(sas, what, &local_err);
> > >      if (r < 0) {
> > > -        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
> > > +        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_err));
> > >          error_free(local_err);
> > >      }
> > >  }
> > >
> > >  void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      S390StAttribState *sas = s390_get_stattrib_device();
> > >      S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
> > >      uint64_t addr = qdict_get_int(qdict, "addr");
> > > @@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      vals = g_try_malloc(buflen);
> > >      if (!vals) {
> > > -        monitor_printf(mon, "Error: %s\n", strerror(errno));
> > > +        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
> > >          return;
> > >      }
> > >
> > >      len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
> > >      if (len < 0) {
> > > -        monitor_printf(mon, "Error: %s", strerror(-len));
> > > +        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
> > >          goto out;
> > >      }
> > >
> > > -    monitor_printf(mon, "  CMMA attributes, "
> > > -                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
> > > -                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
> > > +    monitor_hmp_printf(hmp, "  CMMA attributes, "
> > > +                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
> > > +                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
> > >      for (cx = 0; cx < len; cx++) {
> > >          if (cx % 8 == 7) {
> > > -            monitor_printf(mon, "%02x\n", vals[cx]);
> > > +            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
> > >          } else {
> > > -            monitor_printf(mon, "%02x", vals[cx]);
> > > +            monitor_hmp_printf(hmp, "%02x", vals[cx]);
> > >          }
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >
> > >  out:
> > >      g_free(vals);
> > > diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
> > > index 0d59a74ad60e..0249eea2cfe9 100644
> > > --- a/hw/uefi/ovmf-log.c
> > > +++ b/hw/uefi/ovmf-log.c
> > > @@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_size, uint64_t max_size,
> > >
> > >  void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      g_autofree gchar *log_esc = NULL;
> > >      g_autofree guchar *log_out = NULL;
> > >      Error *err = NULL;
> > > @@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      if (log->version) {
> > >          g_autofree gchar *esc = g_strescape(log->version, NULL);
> > > -        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
> > > +        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
> > >      }
> > >
> > >      log_out = g_base64_decode(log->log, &log_len);
> > >      log_esc = g_strescape((gchar *)log_out, "\r\n");
> > > -    monitor_printf(mon, "%s\n", log_esc);
> > > +    monitor_hmp_printf(hmp, "%s\n", log_esc);
> > >  }
> > > diff --git a/hw/usb/bus.c b/hw/usb/bus.c
> > > index 9b9b2e7c2f8f..fe3dbfa2227c 100644
> > > --- a/hw/usb/bus.c
> > > +++ b/hw/usb/bus.c
> > > @@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
> > >
> > >  static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
> > >  {
> > > +    MonitorHMP *hmp = MONITOR_HMP(mon);
> > >      USBDevice *dev = USB_DEVICE(qdev);
> > >      USBBus *bus = usb_bus_from_device(dev);
> > >
> > > -    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
> > > -                   indent, "", bus->busnr, dev->addr,
> > > -                   dev->port ? dev->port->path : "-",
> > > -                   usb_speed(dev->speed), dev->product_desc,
> > > -                   dev->attached ? ", attached" : "");
> > > +    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
> > > +                       indent, "", bus->busnr, dev->addr,
> > > +                       dev->port ? dev->port->path : "-",
> > > +                       usb_speed(dev->speed), dev->product_desc,
> > > +                       dev->attached ? ", attached" : "");
> > >  }
> > >
> > >  static char *usb_get_dev_path(DeviceState *qdev)
> > > diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> > > index c02343d3a655..9b9f26a1078e 100644
> > > --- a/hw/usb/host-libusb.c
> > > +++ b/hw/usb/host-libusb.c
> > > @@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
> > >
> > >  void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      libusb_device **devs = NULL;
> > >      struct libusb_device_descriptor ddesc;
> > >      char port[16];
> > > @@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
> > >              continue;
> > >          }
> > >          usb_host_get_port(devs[i], port, sizeof(port));
> > > -        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
> > > -                       libusb_get_bus_number(devs[i]),
> > > -                       libusb_get_device_address(devs[i]),
> > > -                       port,
> > > -                       speed_name[libusb_get_device_speed(devs[i])]);
> > > -        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
> > > -        monitor_printf(mon, " USB device %04x:%04x",
> > > -                       ddesc.idVendor, ddesc.idProduct);
> > > +        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
> > > +                           libusb_get_bus_number(devs[i]),
> > > +                           libusb_get_device_address(devs[i]),
> > > +                           port,
> > > +                           speed_name[libusb_get_device_speed(devs[i])]);
> > > +        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass);
> > > +        monitor_hmp_printf(hmp, " USB device %04x:%04x",
> > > +                           ddesc.idVendor, ddesc.idProduct);
> > >          if (ddesc.iProduct) {
> > >              libusb_device_handle *handle;
> > >              if (libusb_open(devs[i], &handle) == 0) {
> > > @@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
> > >                                                     ddesc.iProduct,
> > >                                                     name, sizeof(name));
> > >                  libusb_close(handle);
> > > -                monitor_printf(mon, ", %s", name);
> > > +                monitor_hmp_printf(hmp, ", %s", name);
> > >              }
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >      }
> > >      libusb_free_device_list(devs, 1);
> > >  }
> > > diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
> > > index fb36c8b9274c..e5da6f00699d 100644
> > > --- a/hw/virtio/virtio-hmp-cmds.c
> > > +++ b/hw/virtio/virtio-hmp-cmds.c
> > > @@ -12,77 +12,76 @@
> > >  #include "qobject/qdict.h"
> > >
> > >
> > > -static void hmp_virtio_dump_protocols(Monitor *mon,
> > > +static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
> > >                                        VhostDeviceProtocols *pcol)
> > >  {
> > >      strList *pcol_list = pcol->protocols;
> > >      while (pcol_list) {
> > > -        monitor_printf(mon, "\t%s", pcol_list->value);
> > > +        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
> > >          pcol_list = pcol_list->next;
> > >          if (pcol_list != NULL) {
> > > -            monitor_printf(mon, ",\n");
> > > +            monitor_hmp_printf(hmp, ",\n");
> > >          }
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >      if (pcol->has_unknown_protocols) {
> > > -        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
> > > -                       pcol->unknown_protocols);
> > > +        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n",
> > > +                           pcol->unknown_protocols);
> > >      }
> > >  }
> > >
> > > -static void hmp_virtio_dump_status(Monitor *mon,
> > > +static void hmp_virtio_dump_status(MonitorHMP *hmp,
> > >                                     VirtioDeviceStatus *status)
> > >  {
> > >      strList *status_list = status->statuses;
> > >      while (status_list) {
> > > -        monitor_printf(mon, "\t%s", status_list->value);
> > > +        monitor_hmp_printf(hmp, "\t%s", status_list->value);
> > >          status_list = status_list->next;
> > >          if (status_list != NULL) {
> > > -            monitor_printf(mon, ",\n");
> > > +            monitor_hmp_printf(hmp, ",\n");
> > >          }
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >      if (status->has_unknown_statuses) {
> > > -        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
> > > -                       status->unknown_statuses);
> > > +        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n",
> > > +                           status->unknown_statuses);
> > >      }
> > >  }
> > >
> > > -static void hmp_virtio_dump_features(Monitor *mon,
> > > +static void hmp_virtio_dump_features(MonitorHMP *hmp,
> > >                                       VirtioDeviceFeatures *features)
> > >  {
> > >      strList *transport_list = features->transports;
> > >      while (transport_list) {
> > > -        monitor_printf(mon, "\t%s", transport_list->value);
> > > +        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
> > >          transport_list = transport_list->next;
> > >          if (transport_list != NULL) {
> > > -            monitor_printf(mon, ",\n");
> > > +            monitor_hmp_printf(hmp, ",\n");
> > >          }
> > >      }
> > >
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >      strList *list = features->dev_features;
> > >      if (list) {
> > >          while (list) {
> > > -            monitor_printf(mon, "\t%s", list->value);
> > > +            monitor_hmp_printf(hmp, "\t%s", list->value);
> > >              list = list->next;
> > >              if (list != NULL) {
> > > -                monitor_printf(mon, ",\n");
> > > +                monitor_hmp_printf(hmp, ",\n");
> > >              }
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >      }
> > >
> > >      if (features->has_unknown_dev_features) {
> > > -        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
> > > -                       features->unknown_dev_features2,
> > > -                       features->unknown_dev_features);
> > > +        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
> > > +                           features->unknown_dev_features2,
> > > +                           features->unknown_dev_features);
> > >      }
> > >  }
> > >
> > >  void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      VirtioInfoList *list = qmp_x_query_virtio(&err);
> > >      VirtioInfoList *node;
> > > @@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
> > >      }
> > >
> > >      if (list == NULL) {
> > > -        monitor_printf(mon, "No VirtIO devices\n");
> > > +        monitor_hmp_printf(hmp, "No VirtIO devices\n");
> > >          return;
> > >      }
> > >
> > >      node = list;
> > >      while (node) {
> > > -        monitor_printf(mon, "%s [%s]\n", node->value->path,
> > > -                       node->value->name);
> > > +        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
> > > +                           node->value->name);
> > >          node = node->next;
> > >      }
> > >      qapi_free_VirtioInfoList(list);
> > > @@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      const char *path = qdict_get_try_str(qdict, "path");
> > >      VirtioStatus *s = qmp_x_query_virtio_status(path, &err);
> > > @@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "%s:\n", path);
> > > -    monitor_printf(mon, "  device_name:             %s %s\n",
> > > -                   s->name, s->vhost_dev ? "(vhost)" : "");
> > > -    monitor_printf(mon, "  device_id:               %d\n", s->device_id);
> > > -    monitor_printf(mon, "  vhost_started:           %s\n",
> > > -                   s->vhost_started ? "true" : "false");
> > > -    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name);
> > > -    monitor_printf(mon, "  broken:                  %s\n",
> > > -                   s->broken ? "true" : "false");
> > > -    monitor_printf(mon, "  disabled:                %s\n",
> > > -                   s->disabled ? "true" : "false");
> > > -    monitor_printf(mon, "  disable_legacy_check:    %s\n",
> > > -                   s->disable_legacy_check ? "true" : "false");
> > > -    monitor_printf(mon, "  started:                 %s\n",
> > > -                   s->started ? "true" : "false");
> > > -    monitor_printf(mon, "  use_started:             %s\n",
> > > -                   s->use_started ? "true" : "false");
> > > -    monitor_printf(mon, "  start_on_kick:           %s\n",
> > > -                   s->start_on_kick ? "true" : "false");
> > > -    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
> > > -                   s->use_guest_notifier_mask ? "true" : "false");
> > > -    monitor_printf(mon, "  vm_running:              %s\n",
> > > -                   s->vm_running ? "true" : "false");
> > > -    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
> > > -    monitor_printf(mon, "  queue_sel:               %d\n",
> > > -                   s->queue_sel);
> > > -    monitor_printf(mon, "  isr:                     %d\n", s->isr);
> > > -    monitor_printf(mon, "  endianness:              %s\n",
> > > -                   s->device_endian);
> > > -    monitor_printf(mon, "  status:\n");
> > > -    hmp_virtio_dump_status(mon, s->status);
> > > -    monitor_printf(mon, "  Guest features:\n");
> > > -    hmp_virtio_dump_features(mon, s->guest_features);
> > > -    monitor_printf(mon, "  Host features:\n");
> > > -    hmp_virtio_dump_features(mon, s->host_features);
> > > -    monitor_printf(mon, "  Backend features:\n");
> > > -    hmp_virtio_dump_features(mon, s->backend_features);
> > > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > > +    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
> > > +                       s->name, s->vhost_dev ? "(vhost)" : "");
> > > +    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->device_id);
> > > +    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
> > > +                       s->vhost_started ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_name);
> > > +    monitor_hmp_printf(hmp, "  broken:                  %s\n",
> > > +                       s->broken ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  disabled:                %s\n",
> > > +                       s->disabled ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
> > > +                       s->disable_legacy_check ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  started:                 %s\n",
> > > +                       s->started ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  use_started:             %s\n",
> > > +                       s->use_started ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
> > > +                       s->start_on_kick ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
> > > +                       s->use_guest_notifier_mask ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
> > > +                       s->vm_running ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
> > > +    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
> > > +                       s->queue_sel);
> > > +    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr);
> > > +    monitor_hmp_printf(hmp, "  endianness:              %s\n",
> > > +                       s->device_endian);
> > > +    monitor_hmp_printf(hmp, "  status:\n");
> > > +    hmp_virtio_dump_status(hmp, s->status);
> > > +    monitor_hmp_printf(hmp, "  Guest features:\n");
> > > +    hmp_virtio_dump_features(hmp, s->guest_features);
> > > +    monitor_hmp_printf(hmp, "  Host features:\n");
> > > +    hmp_virtio_dump_features(hmp, s->host_features);
> > > +    monitor_hmp_printf(hmp, "  Backend features:\n");
> > > +    hmp_virtio_dump_features(hmp, s->backend_features);
> > >
> > >      if (s->vhost_dev) {
> > > -        monitor_printf(mon, "  VHost:\n");
> > > -        monitor_printf(mon, "    nvqs:           %d\n",
> > > -                       s->vhost_dev->nvqs);
> > > -        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
> > > -                       s->vhost_dev->vq_index);
> > > -        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
> > > -                       s->vhost_dev->max_queues);
> > > -        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
> > > -                       s->vhost_dev->n_mem_sections);
> > > -        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
> > > -                       s->vhost_dev->n_tmp_sections);
> > > -        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
> > > -                       s->vhost_dev->backend_cap);
> > > -        monitor_printf(mon, "    log_enabled:    %s\n",
> > > -                       s->vhost_dev->log_enabled ? "true" : "false");
> > > -        monitor_printf(mon, "    log_size:       %"PRId64"\n",
> > > -                       s->vhost_dev->log_size);
> > > -        monitor_printf(mon, "    Features:\n");
> > > -        hmp_virtio_dump_features(mon, s->vhost_dev->features);
> > > -        monitor_printf(mon, "    Acked features:\n");
> > > -        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
> > > -        monitor_printf(mon, "    Protocol features:\n");
> > > -        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features);
> > > +        monitor_hmp_printf(hmp, "  VHost:\n");
> > > +        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
> > > +                           s->vhost_dev->nvqs);
> > > +        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
> > > +                           s->vhost_dev->vq_index);
> > > +        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
> > > +                           s->vhost_dev->max_queues);
> > > +        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
> > > +                           s->vhost_dev->n_mem_sections);
> > > +        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
> > > +                           s->vhost_dev->n_tmp_sections);
> > > +        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
> > > +                           s->vhost_dev->backend_cap);
> > > +        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
> > > +                           s->vhost_dev->log_enabled ? "true" : "false");
> > > +        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
> > > +                           s->vhost_dev->log_size);
> > > +        monitor_hmp_printf(hmp, "    Features:\n");
> > > +        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
> > > +        monitor_hmp_printf(hmp, "    Acked features:\n");
> > > +        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
> > > +        monitor_hmp_printf(hmp, "    Protocol features:\n");
> > > +        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features);
> > >      }
> > >
> > >      qapi_free_VirtioStatus(s);
> > > @@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      const char *path = qdict_get_try_str(qdict, "path");
> > >      int queue = qdict_get_int(qdict, "queue");
> > > @@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "%s:\n", path);
> > > -    monitor_printf(mon, "  device_name:          %s (vhost)\n",
> > > -                   s->name);
> > > -    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick);
> > > -    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call);
> > > -    monitor_printf(mon, "  VRing:\n");
> > > -    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
> > > -    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
> > > -                   s->desc_phys);
> > > -    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
> > > -    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
> > > -                   s->avail_phys);
> > > -    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size);
> > > -    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
> > > -                   s->used_phys);
> > > -    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
> > > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > > +    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
> > > +                       s->name);
> > > +    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->kick);
> > > +    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->call);
> > > +    monitor_hmp_printf(hmp, "  VRing:\n");
> > > +    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
> > > +    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
> > > +                       s->desc_phys);
> > > +    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_size);
> > > +    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
> > > +                       s->avail_phys);
> > > +    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_size);
> > > +    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
> > > +                       s->used_phys);
> > > +    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_size);
> > >
> > >      qapi_free_VirtVhostQueueStatus(s);
> > >  }
> > >
> > >  void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      const char *path = qdict_get_try_str(qdict, "path");
> > >      int queue = qdict_get_int(qdict, "queue");
> > > @@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "%s:\n", path);
> > > -    monitor_printf(mon, "  device_name:          %s\n", s->name);
> > > -    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index);
> > > -    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
> > > -    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
> > > -    monitor_printf(mon, "  signalled_used:       %d\n",
> > > -                   s->signalled_used);
> > > -    monitor_printf(mon, "  signalled_used_valid: %s\n",
> > > -                   s->signalled_used_valid ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > > +    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
> > > +    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_index);
> > > +    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
> > > +    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_idx);
> > > +    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
> > > +                       s->signalled_used);
> > > +    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
> > > +                       s->signalled_used_valid ? "true" : "false");
> > >      if (s->has_last_avail_idx) {
> > > -        monitor_printf(mon, "  last_avail_idx:       %d\n",
> > > -                       s->last_avail_idx);
> > > +        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
> > > +                           s->last_avail_idx);
> > >      }
> > >      if (s->has_shadow_avail_idx) {
> > > -        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
> > > -                       s->shadow_avail_idx);
> > > +        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
> > > +                           s->shadow_avail_idx);
> > >      }
> > > -    monitor_printf(mon, "  VRing:\n");
> > > -    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num);
> > > -    monitor_printf(mon, "    num_default:  %"PRId32"\n",
> > > -                   s->vring_num_default);
> > > -    monitor_printf(mon, "    align:        %"PRId32"\n",
> > > -                   s->vring_align);
> > > -    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
> > > -                   s->vring_desc);
> > > -    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
> > > -                   s->vring_avail);
> > > -    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
> > > -                   s->vring_used);
> > > +    monitor_hmp_printf(hmp, "  VRing:\n");
> > > +    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_num);
> > > +    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
> > > +                       s->vring_num_default);
> > > +    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
> > > +                       s->vring_align);
> > > +    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
> > > +                       s->vring_desc);
> > > +    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
> > > +                       s->vring_avail);
> > > +    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
> > > +                       s->vring_used);
> > >
> > >      qapi_free_VirtQueueStatus(s);
> > >  }
> > >
> > >  void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      const char *path = qdict_get_try_str(qdict, "path");
> > >      int queue = qdict_get_int(qdict, "queue");
> > > @@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "%s:\n", path);
> > > -    monitor_printf(mon, "  device_name: %s\n", e->name);
> > > -    monitor_printf(mon, "  index:   %d\n", e->index);
> > > -    monitor_printf(mon, "  desc:\n");
> > > -    monitor_printf(mon, "    descs:\n");
> > > +    monitor_hmp_printf(hmp, "%s:\n", path);
> > > +    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
> > > +    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
> > > +    monitor_hmp_printf(hmp, "  desc:\n");
> > > +    monitor_hmp_printf(hmp, "    descs:\n");
> > >
> > >      list = e->descs;
> > >      while (list) {
> > > -        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
> > > -                       list->value->addr, list->value->len);
> > > +        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
> > > +                           list->value->addr, list->value->len);
> > >          if (list->value->flags) {
> > >              strList *flag = list->value->flags;
> > > -            monitor_printf(mon, " (");
> > > +            monitor_hmp_printf(hmp, " (");
> > >              while (flag) {
> > > -                monitor_printf(mon, "%s", flag->value);
> > > +                monitor_hmp_printf(hmp, "%s", flag->value);
> > >                  flag = flag->next;
> > >                  if (flag) {
> > > -                    monitor_printf(mon, ", ");
> > > +                    monitor_hmp_printf(hmp, ", ");
> > >                  }
> > >              }
> > > -            monitor_printf(mon, ")");
> > > +            monitor_hmp_printf(hmp, ")");
> > >          }
> > >          list = list->next;
> > >          if (list) {
> > > -            monitor_printf(mon, ",\n");
> > > +            monitor_hmp_printf(hmp, ",\n");
> > >          }
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > -    monitor_printf(mon, "  avail:\n");
> > > -    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
> > > -    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
> > > -    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
> > > -    monitor_printf(mon, "  used:\n");
> > > -    monitor_printf(mon, "    flags: %d\n", e->used->flags);
> > > -    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
> > > +    monitor_hmp_printf(hmp, "\n");
> > > +    monitor_hmp_printf(hmp, "  avail:\n");
> > > +    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
> > > +    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
> > > +    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
> > > +    monitor_hmp_printf(hmp, "  used:\n");
> > > +    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
> > > +    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
> > >
> > >      qapi_free_VirtioQueueElement(e);
> > >  }
> > > diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
> > > index a563f6066bb4..4075b5b001ae 100644
> > > --- a/hw/xen/xen-bus.c
> > > +++ b/hw/xen/xen-bus.c
> > > @@ -103,10 +103,11 @@ abort:
> > >
> > >  static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
> > >  {
> > > +    MonitorHMP *hmp = MONITOR_HMP(mon);
> > >      XenDevice *xendev = XEN_DEVICE(dev);
> > >
> > > -    monitor_printf(mon, "%*sname = '%s' frontend_id = %u\n",
> > > -                   indent, "", xendev->name, xendev->frontend_id);
> > > +    monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
> > > +                       indent, "", xendev->name, xendev->frontend_id);
> > >  }
> > >
> > >  static char *xen_bus_get_dev_path(DeviceState *dev)
> > > diff --git a/include/disas/disas.h b/include/disas/disas.h
> > > index c702b1effc1c..47daa9b4d2df 100644
> > > --- a/include/disas/disas.h
> > > +++ b/include/disas/disas.h
> > > @@ -1,13 +1,15 @@
> > >  #ifndef QEMU_DISAS_H
> > >  #define QEMU_DISAS_H
> > >
> > > +#include "monitor/hmp.h"
> > > +
> > >  /* Disassemble this for me please... (debugging). */
> > >  #ifdef CONFIG_TCG
> > >  void disas(FILE *out, const void *code, size_t size);
> > >  void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db);
> > >  #endif
> > >
> > > -void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
> > > +void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
> > >                     int nb_insn, bool is_physical);
> > >
> > >  #ifdef CONFIG_PLUGIN
> > > diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> > > index 3fd17048b319..f10bf83df86d 100644
> > > --- a/include/monitor/hmp.h
> > > +++ b/include/monitor/hmp.h
> > > @@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *chardev_id,
> > >
> > >  MonitorHMP *monitor_cur_hmp(void);
> > >
> > > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> > >      G_GNUC_PRINTF(2, 0);
> > > -int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
> > > -void monitor_printc(Monitor *mon, int ch);
> > > +int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
> > > +void monitor_hmp_printc(MonitorHMP *mon, int ch);
> > >
> > >  void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
> > >  int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> > > @@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
> > >  int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
> > >
> > >  bool hmp_handle_error(MonitorHMP *hmp, Error *err);
> > > -void hmp_help_cmd(Monitor *mon, const char *name);
> > > +void hmp_help_cmd(MonitorHMP *hmp, const char *name);
> > >  strList *hmp_split_at_comma(const char *str);
> > >
> > >  void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
> > > @@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDict *qdict);
> > >  void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
> > >  void hmp_change(MonitorHMP *hmp, const QDict *qdict);
> > >  #ifdef CONFIG_VNC
> > > -void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
> > > +void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
> > >                      const char *arg, const char *read_only, bool force,
> > >                      Error **errp);
> > >  #endif
> > > -void hmp_change_medium(Monitor *mon, const char *device, const char *target,
> > > +void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
> > >                         const char *arg, const char *read_only, bool force,
> > >                         Error **errp);
> > >  void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
> > > diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
> > > index 3c0931796ce2..bdbb2aaa99db 100644
> > > --- a/migration/dirtyrate.c
> > > +++ b/migration/dirtyrate.c
> > > @@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool has_calc_time_unit,
> > >
> > >  void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      DirtyRateInfo *info = query_dirty_rate_info(TIME_UNIT_SECOND);
> > >
> > > -    monitor_printf(mon, "Status: %s\n",
> > > -                   DirtyRateStatus_str(info->status));
> > > -    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
> > > -                   info->start_time);
> > > +    monitor_hmp_printf(hmp, "Status: %s\n",
> > > +                       DirtyRateStatus_str(info->status));
> > > +    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
> > > +                       info->start_time);
> > >      if (info->mode == DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
> > > -        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
> > > -                       info->sample_pages);
> > > +        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
> > > +                           info->sample_pages);
> > >      }
> > > -    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
> > > -                   info->calc_time);
> > > -    monitor_printf(mon, "Mode: %s\n",
> > > -                   DirtyRateMeasureMode_str(info->mode));
> > > -    monitor_printf(mon, "Dirty rate: ");
> > > +    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
> > > +                       info->calc_time);
> > > +    monitor_hmp_printf(hmp, "Mode: %s\n",
> > > +                       DirtyRateMeasureMode_str(info->mode));
> > > +    monitor_hmp_printf(hmp, "Dirty rate: ");
> > >      if (info->has_dirty_rate) {
> > > -        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
> > > +        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate);
> > >          if (info->has_vcpu_dirty_rate) {
> > >              DirtyRateVcpuList *rate, *head = info->vcpu_dirty_rate;
> > >              for (rate = head; rate != NULL; rate = rate->next) {
> > > -                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
> > > -                               " (MB/s)\n", rate->value->id,
> > > -                               rate->value->dirty_rate);
> > > +                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
> > > +                                   " (MB/s)\n", rate->value->id,
> > > +                                   rate->value->dirty_rate);
> > >              }
> > >          }
> > >      } else {
> > > -        monitor_printf(mon, "(not ready)\n");
> > > +        monitor_hmp_printf(hmp, "(not ready)\n");
> > >      }
> > >
> > >      qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
> > > @@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int64_t sec = qdict_get_try_int(qdict, "second", 0);
> > >      int64_t sample_pages = qdict_get_try_int(qdict, "sample_pages_per_GB", -1);
> > >      bool has_sample_pages = (sample_pages != -1);
> > > @@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> > >      Error *err = NULL;
> > >
> > >      if (!sec) {
> > > -        monitor_printf(mon, "Incorrect period length specified!\n");
> > > +        monitor_hmp_printf(hmp, "Incorrect period length specified!\n");
> > >          return;
> > >      }
> > >
> > >      if (dirty_ring && dirty_bitmap) {
> > > -        monitor_printf(mon, "Either dirty ring or dirty bitmap "
> > > -                       "can be specified!\n");
> > > +        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
> > > +                           "can be specified!\n");
> > >          return;
> > >      }
> > >
> > > @@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "Starting dirty rate measurement with period %"PRIi64
> > > -                   " seconds\n", sec);
> > > -    monitor_printf(mon, "[Please use 'info dirty_rate' to check results]\n");
> > > +    monitor_hmp_printf(hmp, "Starting dirty rate measurement with period %"PRIi64
> > > +                       " seconds\n", sec);
> > > +    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check results]\n");
> > >  }
> > > diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
> > > index 73a974259478..6fe189471899 100644
> > > --- a/migration/migration-hmp-cmds.c
> > > +++ b/migration/migration-hmp-cmds.c
> > > @@ -36,23 +36,23 @@
> > >  #include "options.h"
> > >  #include "migration.h"
> > >
> > > -static void migration_global_dump(Monitor *mon)
> > > +static void migration_global_dump(MonitorHMP *hmp)
> > >  {
> > >      MigrationState *ms = migrate_get_current();
> > >
> > > -    monitor_printf(mon, "Globals:\n");
> > > -    monitor_printf(mon, "  store-global-state: %s\n",
> > > -                   ms->store_global_state ? "on" : "off");
> > > -    monitor_printf(mon, "  only-migratable: %s\n",
> > > -                   only_migratable ? "on" : "off");
> > > -    monitor_printf(mon, "  send-configuration: %s\n",
> > > -                   ms->send_configuration ? "on" : "off");
> > > -    monitor_printf(mon, "  send-section-footer: %s\n",
> > > -                   ms->send_section_footer ? "on" : "off");
> > > -    monitor_printf(mon, "  send-switchover-start: %s\n",
> > > -                   ms->send_switchover_start ? "on" : "off");
> > > -    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
> > > -                   ms->clear_bitmap_shift);
> > > +    monitor_hmp_printf(hmp, "Globals:\n");
> > > +    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
> > > +                       ms->store_global_state ? "on" : "off");
> > > +    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
> > > +                       only_migratable ? "on" : "off");
> > > +    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
> > > +                       ms->send_configuration ? "on" : "off");
> > > +    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
> > > +                       ms->send_section_footer ? "on" : "off");
> > > +    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
> > > +                       ms->send_switchover_start ? "on" : "off");
> > > +    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
> > > +                       ms->clear_bitmap_shift);
> > >  }
> > >
> > >  static const gchar *format_time_str(uint64_t us)
> > > @@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
> > >      return g_strdup_printf("%"PRIu64" %s", us, units[index]);
> > >  }
> > >
> > > -static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> > > +static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *info)
> > >  {
> > >      if (info->has_postcopy_blocktime) {
> > > -        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
> > > -                       info->postcopy_blocktime);
> > > +        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\n",
> > > +                           info->postcopy_blocktime);
> > >      }
> > >
> > >      if (info->has_postcopy_vcpu_blocktime) {
> > > @@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> > >          const char *sep = "";
> > >          int count = 0;
> > >
> > > -        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
> > > +        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
> > >
> > >          while (item) {
> > > -            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
> > > +            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
> > >              item = item->next;
> > >              /* Each line 10 vcpu results, newline if there's more */
> > >              sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
> > >          }
> > > -        monitor_printf(mon, "]\n");
> > > +        monitor_hmp_printf(hmp, "]\n");
> > >      }
> > >
> > >      if (info->has_postcopy_latency) {
> > > -        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
> > > -                       info->postcopy_latency);
> > > +        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n",
> > > +                           info->postcopy_latency);
> > >      }
> > >
> > >      if (info->has_postcopy_non_vcpu_latency) {
> > > -        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
> > > -                       info->postcopy_non_vcpu_latency);
> > > +        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
> > > +                           info->postcopy_non_vcpu_latency);
> > >      }
> > >
> > >      if (info->has_postcopy_vcpu_latency) {
> > > @@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> > >          const char *sep = "";
> > >          int count = 0;
> > >
> > > -        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
> > > +        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
> > >
> > >          while (item) {
> > > -            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
> > > +            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
> > >              item = item->next;
> > >              /* Each line 10 vcpu results, newline if there's more */
> > >              sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
> > >          }
> > > -        monitor_printf(mon, "]\n");
> > > +        monitor_hmp_printf(hmp, "]\n");
> > >      }
> > >
> > >      if (info->has_postcopy_latency_dist) {
> > >          uint64List *item = info->postcopy_latency_dist;
> > >          int count = 0;
> > >
> > > -        monitor_printf(mon, "Postcopy Latency Distribution:\n");
> > > +        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
> > >
> > >          while (item) {
> > >              g_autofree const gchar *from = format_time_str(1UL << count);
> > >              g_autofree const gchar *to = format_time_str(1UL << (count + 1));
> > >
> > > -            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
> > > -                           from, to, item->value);
> > > +            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
> > > +                               from, to, item->value);
> > >              item = item->next;
> > >              count++;
> > >          }
> > > @@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
> > >
> > >  void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      bool show_all = qdict_get_try_bool(qdict, "all", false);
> > >      MigrationInfo *info;
> > >
> > > @@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      if (info->blocked_reasons) {
> > >          strList *reasons = info->blocked_reasons;
> > > -        monitor_printf(mon, "Outgoing migration blocked:\n");
> > > +        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
> > >          while (reasons) {
> > > -            monitor_printf(mon, "  %s\n", reasons->value);
> > > +            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
> > >              reasons = reasons->next;
> > >          }
> > >      }
> > >
> > >      if (info->has_status) {
> > > -        monitor_printf(mon, "Status: \t\t%s",
> > > -                       MigrationStatus_str(info->status));
> > > +        monitor_hmp_printf(hmp, "Status: \t\t%s",
> > > +                           MigrationStatus_str(info->status));
> > >          if ((info->status == MIGRATION_STATUS_FAILED ||
> > >               info->status == MIGRATION_STATUS_POSTCOPY_PAUSED) &&
> > >              info->error_desc) {
> > > -            monitor_printf(mon, " (%s)\n", info->error_desc);
> > > +            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
> > >          } else {
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >
> > >          if (info->total_time) {
> > > -            monitor_printf(mon, "Time (ms): \t\ttotal=%" PRIu64,
> > > -                           info->total_time);
> > > +            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=%" PRIu64,
> > > +                               info->total_time);
> > >              if (info->has_setup_time) {
> > > -                monitor_printf(mon, ", setup=%" PRIu64,
> > > -                               info->setup_time);
> > > +                monitor_hmp_printf(hmp, ", setup=%" PRIu64,
> > > +                                   info->setup_time);
> > >              }
> > >              if (info->has_expected_downtime) {
> > > -                monitor_printf(mon, ", exp_down=%" PRIu64,
> > > -                               info->expected_downtime);
> > > +                monitor_hmp_printf(hmp, ", exp_down=%" PRIu64,
> > > +                                   info->expected_downtime);
> > >              }
> > >              if (info->has_downtime) {
> > > -                monitor_printf(mon, ", down=%" PRIu64,
> > > -                               info->downtime);
> > > +                monitor_hmp_printf(hmp, ", down=%" PRIu64,
> > > +                                   info->downtime);
> > >              }
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >      }
> > >
> > >      if (info->has_remaining) {
> > >          g_autofree char *remaining = size_to_str(info->remaining);
> > > -        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
> > > +        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
> > >      }
> > >
> > >      if (info->has_socket_address) {
> > >          SocketAddressList *addr;
> > >
> > > -        monitor_printf(mon, "Sockets: [\n");
> > > +        monitor_hmp_printf(hmp, "Sockets: [\n");
> > >
> > >          for (addr = info->socket_address; addr; addr = addr->next) {
> > >              char *s = socket_uri(addr->value);
> > > -            monitor_printf(mon, "\t%s\n", s);
> > > +            monitor_hmp_printf(hmp, "\t%s\n", s);
> > >              g_free(s);
> > >          }
> > > -        monitor_printf(mon, "]\n");
> > > +        monitor_hmp_printf(hmp, "]\n");
> > >      }
> > >
> > >      if (info->ram) {
> > > @@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
> > >          g_autofree char *str_multifd = size_to_str(info->ram->multifd_bytes);
> > >          g_autofree char *str_postcopy = size_to_str(info->ram->postcopy_bytes);
> > >
> > > -        monitor_printf(mon, "RAM info:\n");
> > > -        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
> > > -                       info->ram->mbps);
> > > -        monitor_printf(mon, "  Sizes: \t\tpagesize=%s, total=%s\n",
> > > -                       str_psize, str_total);
> > > -        monitor_printf(mon, "  Transfers: \t\ttransferred=%s, remain=%s\n",
> > > -                       str_transferred, str_remaining);
> > > -        monitor_printf(mon, "    Channels: \t\tprecopy=%s, "
> > > -                       "multifd=%s, postcopy=%s",
> > > -                       str_precopy, str_multifd, str_postcopy);
> > > +        monitor_hmp_printf(hmp, "RAM info:\n");
> > > +        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
> > > +                           info->ram->mbps);
> > > +        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=%s, total=%s\n",
> > > +                           str_psize, str_total);
> > > +        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=%s, remain=%s\n",
> > > +                           str_transferred, str_remaining);
> > > +        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=%s, "
> > > +                           "multifd=%s, postcopy=%s",
> > > +                           str_precopy, str_multifd, str_postcopy);
> > >
> > >          if (info->vfio) {
> > >              g_autofree char *str_vfio = size_to_str(info->vfio->transferred);
> > >
> > > -            monitor_printf(mon, ", vfio=%s", str_vfio);
> > > +            monitor_hmp_printf(hmp, ", vfio=%s", str_vfio);
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >
> > > -        monitor_printf(mon, "    Page Types: \tnormal=%" PRIu64
> > > -                       ", zero=%" PRIu64 "\n",
> > > -                       info->ram->normal, info->ram->duplicate);
> > > -        monitor_printf(mon, "  Page Rates (pps): \ttransfer=%" PRIu64,
> > > -                       info->ram->pages_per_second);
> > > +        monitor_hmp_printf(hmp, "    Page Types: \tnormal=%" PRIu64
> > > +                           ", zero=%" PRIu64 "\n",
> > > +                           info->ram->normal, info->ram->duplicate);
> > > +        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=%" PRIu64,
> > > +                           info->ram->pages_per_second);
> > >          if (info->ram->dirty_pages_rate) {
> > > -            monitor_printf(mon, ", dirty=%" PRIu64,
> > > -                           info->ram->dirty_pages_rate);
> > > +            monitor_hmp_printf(hmp, ", dirty=%" PRIu64,
> > > +                               info->ram->dirty_pages_rate);
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >
> > > -        monitor_printf(mon, "  Others: \t\tdirty_syncs=%" PRIu64,
> > > -                       info->ram->dirty_sync_count);
> > > +        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=%" PRIu64,
> > > +                           info->ram->dirty_sync_count);
> > >          if (info->ram->postcopy_requests) {
> > > -            monitor_printf(mon, ", postcopy_req=%" PRIu64,
> > > -                           info->ram->postcopy_requests);
> > > +            monitor_hmp_printf(hmp, ", postcopy_req=%" PRIu64,
> > > +                               info->ram->postcopy_requests);
> > >          }
> > >          if (info->ram->downtime_bytes) {
> > > -            monitor_printf(mon, ", downtime_bytes=%" PRIu64,
> > > -                           info->ram->downtime_bytes);
> > > +            monitor_hmp_printf(hmp, ", downtime_bytes=%" PRIu64,
> > > +                               info->ram->downtime_bytes);
> > >          }
> > >          if (info->ram->dirty_sync_missed_zero_copy) {
> > > -            monitor_printf(mon, ", zerocopy_fallbacks=%" PRIu64,
> > > -                           info->ram->dirty_sync_missed_zero_copy);
> > > +            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=%" PRIu64,
> > > +                               info->ram->dirty_sync_missed_zero_copy);
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >      }
> > >
> > >      if (!show_all) {
> > >          goto out;
> > >      }
> > >
> > > -    migration_global_dump(mon);
> > > +    migration_global_dump(hmp);
> > >
> > >      if (info->xbzrle_cache) {
> > > -        monitor_printf(mon, "XBZRLE: size=%" PRIu64
> > > -                       ", transferred=%" PRIu64
> > > -                       ", pages=%" PRIu64
> > > -                       ", miss=%" PRIu64 "\n"
> > > -                       "  miss_rate=%0.2f"
> > > -                       ", encode_rate=%0.2f"
> > > -                       ", overflow=%" PRIu64 "\n",
> > > -                       info->xbzrle_cache->cache_size,
> > > -                       info->xbzrle_cache->bytes,
> > > -                       info->xbzrle_cache->pages,
> > > -                       info->xbzrle_cache->cache_miss,
> > > -                       info->xbzrle_cache->cache_miss_rate,
> > > -                       info->xbzrle_cache->encoding_rate,
> > > -                       info->xbzrle_cache->overflow);
> > > +        monitor_hmp_printf(hmp, "XBZRLE: size=%" PRIu64
> > > +                           ", transferred=%" PRIu64
> > > +                           ", pages=%" PRIu64
> > > +                           ", miss=%" PRIu64 "\n"
> > > +                           "  miss_rate=%0.2f"
> > > +                           ", encode_rate=%0.2f"
> > > +                           ", overflow=%" PRIu64 "\n",
> > > +                           info->xbzrle_cache->cache_size,
> > > +                           info->xbzrle_cache->bytes,
> > > +                           info->xbzrle_cache->pages,
> > > +                           info->xbzrle_cache->cache_miss,
> > > +                           info->xbzrle_cache->cache_miss_rate,
> > > +                           info->xbzrle_cache->encoding_rate,
> > > +                           info->xbzrle_cache->overflow);
> > >      }
> > >
> > >      if (info->has_cpu_throttle_percentage) {
> > > -        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
> > > -                       info->cpu_throttle_percentage);
> > > +        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
> > > +                           info->cpu_throttle_percentage);
> > >      }
> > >
> > >      if (info->has_dirty_limit_throttle_time_per_round) {
> > > -        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n",
> > > -                       info->dirty_limit_throttle_time_per_round);
> > > +        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 "\n",
> > > +                           info->dirty_limit_throttle_time_per_round);
> > >      }
> > >
> > >      if (info->has_dirty_limit_ring_full_time) {
> > > -        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
> > > -                       info->dirty_limit_ring_full_time);
> > > +        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
> > > +                           info->dirty_limit_ring_full_time);
> > >      }
> > >
> > > -    migration_dump_blocktime(mon, info);
> > > +    migration_dump_blocktime(hmp, info);
> > >  out:
> > >      qapi_free_MigrationInfo(info);
> > >  }
> > >
> > >  void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      MigrationCapabilityStatusList *caps, *cap;
> > >
> > >      caps = qmp_query_migrate_capabilities(NULL);
> > >
> > >      if (caps) {
> > >          for (cap = caps; cap; cap = cap->next) {
> > > -            monitor_printf(mon, "%s: %s\n",
> > > -                           MigrationCapability_str(cap->value->capability),
> > > -                           cap->value->state ? "on" : "off");
> > > +            monitor_hmp_printf(hmp, "%s: %s\n",
> > > +                               MigrationCapability_str(cap->value->capability),
> > > +                               cap->value->state ? "on" : "off");
> > >          }
> > >      }
> > >
> > >      qapi_free_MigrationCapabilityStatusList(caps);
> > >  }
> > >
> > > -static void monitor_print_cpr_exec_command(Monitor *mon, strList *args)
> > > +static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *args)
> > >  {
> > > -    monitor_printf(mon, "%s:",
> > > +    monitor_hmp_printf(hmp, "%s:",
> > >          MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
> > >
> > >      while (args) {
> > > -        monitor_printf(mon, " %s", args->value);
> > > +        monitor_hmp_printf(hmp, " %s", args->value);
> > >          args = args->next;
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >  }
> > >
> > >  void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      MigrationParameters *params;
> > >      MigrationState *s = migrate_get_current();
> > >
> > >      params = qmp_query_migrate_parameters(NULL);
> > >
> > >      if (params) {
> > > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIAL),
> > >              params->announce_initial);
> > > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
> > >              params->announce_max);
> > > -        monitor_printf(mon, "%s: %" PRIu64 "\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS),
> > >              params->announce_rounds);
> > > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
> > >              params->announce_step);
> > >          assert(params->has_throttle_trigger_threshold);
> > > -        monitor_printf(mon, "%s: %u\n",
> > > +        monitor_hmp_printf(hmp, "%s: %u\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD),
> > >              params->throttle_trigger_threshold);
> > >          assert(params->has_cpu_throttle_initial);
> > > -        monitor_printf(mon, "%s: %u\n",
> > > +        monitor_hmp_printf(hmp, "%s: %u\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
> > >              params->cpu_throttle_initial);
> > >          assert(params->has_cpu_throttle_increment);
> > > -        monitor_printf(mon, "%s: %u\n",
> > > +        monitor_hmp_printf(hmp, "%s: %u\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
> > >              params->cpu_throttle_increment);
> > >          assert(params->has_cpu_throttle_tailslow);
> > > -        monitor_printf(mon, "%s: %s\n",
> > > +        monitor_hmp_printf(hmp, "%s: %s\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW),
> > >              params->cpu_throttle_tailslow ? "on" : "off");
> > >          assert(params->has_max_cpu_throttle);
> > > -        monitor_printf(mon, "%s: %u\n",
> > > +        monitor_hmp_printf(hmp, "%s: %u\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTLE),
> > >              params->max_cpu_throttle);
> > >          assert(params->tls_creds);
> > > -        monitor_printf(mon, "%s: '%s'\n",
> > > +        monitor_hmp_printf(hmp, "%s: '%s'\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
> > >                         params->tls_creds->u.s);
> > >          assert(params->tls_hostname);
> > > -        monitor_printf(mon, "%s: '%s'\n",
> > > +        monitor_hmp_printf(hmp, "%s: '%s'\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
> > >                         params->tls_hostname->u.s);
> > >          assert(params->tls_authz);
> > > -        monitor_printf(mon, "%s: '%s'\n",
> > > +        monitor_hmp_printf(hmp, "%s: '%s'\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
> > >                         params->tls_authz->u.s);
> > >          assert(params->has_max_bandwidth);
> > > -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
> > >              params->max_bandwidth);
> > >          assert(params->has_avail_switchover_bandwidth);
> > > -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVER_BANDWIDTH),
> > >              params->avail_switchover_bandwidth);
> > >          assert(params->has_max_postcopy_bandwidth);
> > > -        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH),
> > >              params->max_postcopy_bandwidth);
> > >          assert(params->has_downtime_limit);
> > > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
> > >              params->downtime_limit);
> > >          assert(params->has_x_checkpoint_delay);
> > > -        monitor_printf(mon, "%s: %u ms\n",
> > > +        monitor_hmp_printf(hmp, "%s: %u ms\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
> > >              params->x_checkpoint_delay);
> > > -        monitor_printf(mon, "%s: %u\n",
> > > +        monitor_hmp_printf(hmp, "%s: %u\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
> > >              params->multifd_channels);
> > > -        monitor_printf(mon, "%s: %s\n",
> > > +        monitor_hmp_printf(hmp, "%s: %s\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRESSION),
> > >              MultiFDCompression_str(params->multifd_compression));
> > >          assert(params->has_zero_page_detection);
> > > -        monitor_printf(mon, "%s: %s\n",
> > > +        monitor_hmp_printf(hmp, "%s: %s\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETECTION),
> > >              qapi_enum_lookup(&ZeroPageDetection_lookup,
> > >                  params->zero_page_detection));
> > > -        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
> > >              params->xbzrle_cache_size);
> > >
> > >          if (s->has_block_bitmap_mapping) {
> > >              const BitmapMigrationNodeAliasList *bmnal;
> > >
> > > -            monitor_printf(mon, "%s:\n",
> > > -                           MigrationParameter_str(
> > > -                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
> > > +            monitor_hmp_printf(hmp, "%s:\n",
> > > +                               MigrationParameter_str(
> > > +                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
> > >
> > >              for (bmnal = params->block_bitmap_mapping;
> > >                   bmnal;
> > > @@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
> > >                  const BitmapMigrationNodeAlias *bmna = bmnal->value;
> > >                  const BitmapMigrationBitmapAliasList *bmbal;
> > >
> > > -                monitor_printf(mon, "  '%s' -> '%s'\n",
> > > -                               bmna->node_name, bmna->alias);
> > > +                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
> > > +                                   bmna->node_name, bmna->alias);
> > >
> > >                  for (bmbal = bmna->bitmaps; bmbal; bmbal = bmbal->next) {
> > >                      const BitmapMigrationBitmapAlias *bmba = bmbal->value;
> > >
> > > -                    monitor_printf(mon, "    '%s' -> '%s'\n",
> > > -                                   bmba->name, bmba->alias);
> > > +                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
> > > +                                       bmba->name, bmba->alias);
> > >                  }
> > >              }
> > >          }
> > >
> > > -        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
> > >          MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD),
> > >          params->x_vcpu_dirty_limit_period);
> > >
> > > -        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
> > > +        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT),
> > >              params->vcpu_dirty_limit);
> > >
> > >          assert(params->has_mode);
> > > -        monitor_printf(mon, "%s: %s\n",
> > > +        monitor_hmp_printf(hmp, "%s: %s\n",
> > >              MigrationParameter_str(MIGRATION_PARAMETER_MODE),
> > >              qapi_enum_lookup(&MigMode_lookup, params->mode));
> > >
> > >          if (params->has_direct_io) {
> > > -            monitor_printf(mon, "%s: %s\n",
> > > -                           MigrationParameter_str(
> > > -                               MIGRATION_PARAMETER_DIRECT_IO),
> > > -                           params->direct_io ? "on" : "off");
> > > +            monitor_hmp_printf(hmp, "%s: %s\n",
> > > +                               MigrationParameter_str(
> > > +                                   MIGRATION_PARAMETER_DIRECT_IO),
> > > +                               params->direct_io ? "on" : "off");
> > >          }
> > >
> > >          if (params->has_x_rdma_chunk_size) {
> > > -            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
> > > -                           MigrationParameter_str(
> > > -                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
> > > -                           params->x_rdma_chunk_size);
> > > +            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
> > > +                               MigrationParameter_str(
> > > +                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
> > > +                               params->x_rdma_chunk_size);
> > >          }
> > >
> > >          assert(params->has_cpr_exec_command);
> > > -        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
> > > +        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
> > >      }
> > >
> > >      qapi_free_MigrationParameters(params);
> > > @@ -857,12 +854,12 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
> > >      if (uri_cpr) {
> > >          if (migrate_mode() != MIG_MODE_CPR_TRANSFER) {
> > >              error_setg(&err, "-c can only be used in cpr-transfer mode");
> > > -            hmp_handle_error(mon, err);
> > > +            hmp_handle_error(hmp, err);
> > >              return;
> > >          }
> > >
> > >          if (!migrate_uri_parse(uri_cpr, &channel_cpr, &err)) {
> > > -            hmp_handle_error(mon, err);
> > > +            hmp_handle_error(hmp, err);
> > >              return;
> > >          }
> > >
> > > @@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
> > >          HMPMigrationStatus *status;
> > >
> > >          if (!hmp->use_readline) {
> > > -            monitor_printf(mon, "terminal does not allow synchronous "
> > > -                           "migration, continuing detached\n");
> > > +            monitor_hmp_printf(hmp, "terminal does not allow synchronous "
> > > +                               "migration, continuing detached\n");
> > >              return;
> > >          }
> > >          monitor_suspend(mon);
> > > diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> > > index 89cc19c2431d..1834e3c1f697 100644
> > > --- a/monitor/hmp-cmds.c
> > > +++ b/monitor/hmp-cmds.c
> > > @@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
> > >
> > >  void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      NameInfo *info;
> > >
> > >      info = qmp_query_name(NULL);
> > >      if (info->name) {
> > > -        monitor_printf(mon, "%s\n", info->name);
> > > +        monitor_hmp_printf(hmp, "%s\n", info->name);
> > >      }
> > >      qapi_free_NameInfo(info);
> > >  }
> > >
> > >  void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      VersionInfo *info;
> > >
> > >      info = qmp_query_version(NULL);
> > >
> > > -    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> > > -                   info->qemu->major, info->qemu->minor, info->qemu->micro,
> > > -                   info->package);
> > > +    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> > > +                       info->qemu->major, info->qemu->minor, info->qemu->micro,
> > > +                       info->package);
> > >
> > >      qapi_free_VersionInfo(info);
> > >  }
> > > @@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *op = qdict_get_try_str(qdict, "op");
> > >
> > >      if (op == NULL) {
> > >          bool on = qsp_is_enabled();
> > >
> > > -        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off");
> > > +        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "off");
> > >          return;
> > >      }
> > >      if (!strcmp(op, "on")) {
> > > @@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int64_t cpu_index;
> > >
> > >      /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands that
> > >              use it are converted to the QAPI */
> > >      cpu_index = qdict_get_int(qdict, "index");
> > >      if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
> > > -        monitor_printf(mon, "invalid CPU index\n");
> > > +        monitor_hmp_printf(hmp, "invalid CPU index\n");
> > >      }
> > >  }
> > >
> > > @@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_change(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *device = qdict_get_str(qdict, "device");
> > >      const char *target = qdict_get_str(qdict, "target");
> > >      const char *arg = qdict_get_try_str(qdict, "arg");
> > > @@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  #ifdef CONFIG_VNC
> > >      if (strcmp(device, "vnc") == 0) {
> > > -        hmp_change_vnc(mon, device, target, arg, read_only, force, &err);
> > > +        hmp_change_vnc(hmp, device, target, arg, read_only, force, &err);
> > >      } else
> > >  #endif
> > >      {
> > > -        hmp_change_medium(mon, device, target, arg, read_only, force, &err);
> > > +        hmp_change_medium(hmp, device, target, arg, read_only, force, &err);
> > >      }
> > >
> > >      hmp_handle_error(hmp, err);
> > > @@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
> > >      IOThreadInfoList *info;
> > >      IOThreadInfo *value;
> > >
> > >      for (info = info_list; info; info = info->next) {
> > >          value = info->value;
> > > -        monitor_printf(mon, "%s:\n", value->id);
> > > -        monitor_printf(mon, "  thread_id=%" PRId64 "\n", value->thread_id);
> > > -        monitor_printf(mon, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
> > > -        monitor_printf(mon, "  poll-grow=%" PRId64 "\n", value->poll_grow);
> > > -        monitor_printf(mon, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
> > > -        monitor_printf(mon, "  poll-weight=%" PRId64 "\n", value->poll_weight);
> > > -        monitor_printf(mon, "  aio-max-batch=%" PRId64 "\n",
> > > -                       value->aio_max_batch);
> > > +        monitor_hmp_printf(hmp, "%s:\n", value->id);
> > > +        monitor_hmp_printf(hmp, "  thread_id=%" PRId64 "\n", value->thread_id);
> > > +        monitor_hmp_printf(hmp, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
> > > +        monitor_hmp_printf(hmp, "  poll-grow=%" PRId64 "\n", value->poll_grow);
> > > +        monitor_hmp_printf(hmp, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
> > > +        monitor_hmp_printf(hmp, "  poll-weight=%" PRId64 "\n", value->poll_weight);
> > > +        monitor_hmp_printf(hmp, "  aio-max-batch=%" PRId64 "\n",
> > > +                           value->aio_max_batch);
> > >      }
> > >
> > >      qapi_free_IOThreadInfoList(info_list);
> > > @@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_help(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
> > > +    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
> > >  }
> > >
> > >  void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      /*
> > >       * Send an ANSI escape sequence:
> > >       * "\x1b[H" - move cursor to top-left
> > >       * "\x1b[2J" - clear visible screen
> > >       * "\x1b[3J" - clear scrollback
> > >       */
> > > -    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
> > > +    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
> > >  }
> > >
> > >  void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    hmp_help_cmd(mon, "info");
> > > +    hmp_help_cmd(hmp, "info");
> > >  }
> > >
> > >  void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
> > > @@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int i;
> > >      const char *str;
> > >
> > > @@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
> > >          if (!str) {
> > >              break;
> > >          }
> > > -        monitor_printf(mon, "%d: '%s'\n", i, str);
> > > +        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
> > >          i++;
> > >      }
> > >  }
> > > @@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_log(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int mask;
> > >      const char *items = qdict_get_str(qdict, "items");
> > >      Error *err = NULL;
> > > @@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
> > >      } else {
> > >          mask = qemu_str_to_log_mask(items);
> > >          if (!mask) {
> > > -            hmp_help_cmd(mon, "log");
> > > +            hmp_help_cmd(hmp, "log");
> > >              return;
> > >          }
> > >      }
> > > @@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      const char *device = qdict_get_try_str(qdict, "device");
> > >
> > > @@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
> > >      if (!gdbserver_start(device, &err)) {
> > >          error_report_err(err);
> > >      } else if (strcmp(device, "none") == 0) {
> > > -        monitor_printf(mon, "Disabled gdbserver\n");
> > > +        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
> > >      } else {
> > > -        monitor_printf(mon, "Waiting for gdb connection on device '%s'\n",
> > > -                       device);
> > > +        monitor_hmp_printf(hmp, "Waiting for gdb connection on device '%s'\n",
> > > +                           device);
> > >      }
> > >  }
> > >
> > >  void hmp_print(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int format = qdict_get_int(qdict, "format");
> > >      hwaddr val = qdict_get_int(qdict, "val");
> > >
> > >      switch(format) {
> > >      case 'o':
> > > -        monitor_printf(mon, "%#" HWADDR_PRIo, val);
> > > +        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
> > >          break;
> > >      case 'x':
> > > -        monitor_printf(mon, "%#" HWADDR_PRIx, val);
> > > +        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
> > >          break;
> > >      case 'u':
> > > -        monitor_printf(mon, "%" HWADDR_PRIu, val);
> > > +        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
> > >          break;
> > >      default:
> > >      case 'd':
> > > -        monitor_printf(mon, "%" HWADDR_PRId, val);
> > > +        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
> > >          break;
> > >      case 'c':
> > > -        monitor_printc(mon, val);
> > > +        monitor_hmp_printc(hmp, val);
> > >          break;
> > >      }
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >  }
> > >
> > >  void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      uint32_t addr;
> > >      uint16_t sum;
> > >      uint32_t start = qdict_get_int(qdict, "start");
> > > @@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
> > >          sum = (sum >> 1) | (sum << 15);
> > >          sum += val;
> > >      }
> > > -    monitor_printf(mon, "%05d\n", sum);
> > > +    monitor_hmp_printf(hmp, "%05d\n", sum);
> > >  }
> > >
> > >  void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int size = qdict_get_int(qdict, "size");
> > >      int addr = qdict_get_int(qdict, "addr");
> > >      int has_index = qdict_haskey(qdict, "index");
> > > @@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
> > >          suffix = 'l';
> > >          break;
> > >      }
> > > -    monitor_printf(mon, "port%c[0x%04x] = 0x%0*x\n",
> > > -                   suffix, addr, size * 2, val);
> > > +    monitor_hmp_printf(hmp, "port%c[0x%04x] = 0x%0*x\n",
> > > +                       suffix, addr, size * 2, val);
> > >  }
> > >
> > >  void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
> > > @@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *local_err = NULL;
> > >      const char *bootdevice = qdict_get_str(qdict, "bootdevice");
> > >
> > > @@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
> > >      if (local_err) {
> > >          error_report_err(local_err);
> > >      } else {
> > > -        monitor_printf(mon, "boot device list now set to %s\n", bootdevice);
> > > +        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bootdevice);
> > >      }
> > >  }
> > >
> > > @@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
> > > +    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
> > >  }
> > >  #endif
> > >
> > > @@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
> > >
> > >  void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
> > >      int vcpu = qdict_get_try_int(qdict, "vcpu", -1);
> > >      CPUState *cs;
> > >
> > >      if (all_cpus) {
> > >          CPU_FOREACH(cs) {
> > > -            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
> > > +            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
> > >              cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
> > >          }
> > >      } else {
> > > @@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >          if (!cs) {
> > >              if (vcpu >= 0) {
> > > -                monitor_printf(mon, "CPU#%d not available\n", vcpu);
> > > +                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu);
> > >              } else {
> > > -                monitor_printf(mon, "No CPU available\n");
> > > +                monitor_hmp_printf(hmp, "No CPU available\n");
> > >              }
> > >              return;
> > >          }
> > >
> > > -        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
> > > +        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
> > >          cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
> > >      }
> > >  }
> > > @@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
> > >  static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
> > >                          uint64_t addr, bool is_physical)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int l, line_size, i, max_digits, len;
> > >      uint8_t buf[16];
> > >      uint64_t v;
> > > @@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
> > >      const bool big_endian = target_big_endian();
> > >
> > >      if (!cs && (format == 'i' || !is_physical)) {
> > > -        monitor_printf(mon, "Can not dump without CPU\n");
> > > +        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
> > >          return;
> > >      }
> > >
> > >      if (format == 'i') {
> > > -        monitor_disas(mon, cs, addr, count, is_physical);
> > > +        monitor_disas(hmp, cs, addr, count, is_physical);
> > >          return;
> > >      }
> > >
> > > @@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
> > >      }
> > >
> > >      while (len > 0) {
> > > -        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
> > > +        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
> > >          l = len;
> > >          if (l > line_size) {
> > >              l = line_size;
> > > @@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
> > >              MemTxResult r = address_space_read(as, addr,
> > >                                                 MEMTXATTRS_UNSPECIFIED, buf, l);
> > >              if (r != MEMTX_OK) {
> > > -                monitor_printf(mon, " Cannot access memory\n");
> > > +                monitor_hmp_printf(hmp, " Cannot access memory\n");
> > >                  break;
> > >              }
> > >          } else {
> > >              if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
> > > -                monitor_printf(mon, " Cannot access memory\n");
> > > +                monitor_hmp_printf(hmp, " Cannot access memory\n");
> > >                  break;
> > >              }
> > >          }
> > > @@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
> > >                  v = (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
> > >                  break;
> > >              }
> > > -            monitor_printf(mon, " ");
> > > +            monitor_hmp_printf(hmp, " ");
> > >              switch (format) {
> > >              case 'o':
> > > -                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
> > > +                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
> > >                  break;
> > >              case 'x':
> > > -                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
> > > +                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v);
> > >                  break;
> > >              case 'u':
> > > -                monitor_printf(mon, "%*" PRIu64, max_digits, v);
> > > +                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
> > >                  break;
> > >              case 'd':
> > > -                monitor_printf(mon, "%*" PRId64, max_digits, v);
> > > +                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
> > >                  break;
> > >              case 'c':
> > > -                monitor_printc(mon, v);
> > > +                monitor_hmp_printc(hmp, v);
> > >                  break;
> > >              }
> > >              i += wsize;
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >          addr += l;
> > >          len -= l;
> > >      }
> > > @@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      hwaddr addr = qdict_get_int(qdict, "addr");
> > >      Error *local_err = NULL;
> > >      MemoryRegion *mr = NULL;
> > > @@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
> > > -                   " (%s) is %p\n",
> > > -                   addr, mr->name, ptr);
> > > +    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
> > > +                       " (%s) is %p\n",
> > > +                       addr, mr->name, ptr);
> > >
> > >      memory_region_unref(mr);
> > >  }
> > >
> > >  void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      vaddr addr = qdict_get_int(qdict, "addr");
> > >      CPUState *cs = monitor_hmp_get_cpu(hmp);
> > >      TranslateForDebugResult tres;
> > >
> > >      if (!cs) {
> > > -        monitor_printf(mon, "No cpu\n");
> > > +        monitor_hmp_printf(hmp, "No cpu\n");
> > >          return;
> > >      }
> > >
> > >      if (!cpu_translate_for_debug(cs, addr, &tres)) {
> > > -        monitor_printf(mon, "Unmapped\n");
> > > +        monitor_hmp_printf(hmp, "Unmapped\n");
> > >      } else {
> > > -        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
> > > +        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
> > >      }
> > >  }
> > >
> > > @@ -806,7 +786,6 @@ out:
> > >
> > >  void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      hwaddr addr = qdict_get_int(qdict, "addr");
> > >      Error *local_err = NULL;
> > >      MemoryRegion *mr = NULL;
> > > @@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
> > >      if (local_err) {
> > >          error_report_err(local_err);
> > >      } else {
> > > -        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRIx
> > > -                       " (%s) is 0x%" PRIx64 "\n",
> > > -                       addr, mr->name, (uint64_t) physaddr);
> > > +        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR_PRIx
> > > +                           " (%s) is 0x%" PRIx64 "\n",
> > > +                           addr, mr->name, (uint64_t) physaddr);
> > >      }
> > >
> > >      memory_region_unref(mr);
> > > diff --git a/monitor/hmp.c b/monitor/hmp.c
> > > index 2484a2310dff..e5f8b9c576e0 100644
> > > --- a/monitor/hmp.c
> > > +++ b/monitor/hmp.c
> > > @@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, bool val, Error **errp)
> > >      hmp->use_readline = val;
> > >  }
> > >
> > > -int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > > -    G_GNUC_PRINTF(2, 0);
> > >  static void monitor_hmp_accept_input(Monitor *mon);
> > >  static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
> > >  static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp);
> > > @@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, const void *data)
> > >                                     monitor_hmp_get_readline,
> > >                                     monitor_hmp_set_readline);
> > >
> > > -    moncls->vprintf = monitor_hmp_vprintf;
> > >      moncls->accept_input = monitor_hmp_accept_input;
> > >
> > >      ucc->complete = monitor_hmp_complete;
> > > @@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
> > >      hmp->use_readline = true;
> > >  }
> > >
> > > -int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > > -{
> > > -    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
> > > -    return monitor_puts(mon, buf);
> > > -}
> > > -
> > >  static void monitor_hmp_accept_input(Monitor *mon)
> > >  {
> > >      qemu_mutex_lock(&mon->mon_lock);
> > > @@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
> > >          /* prompt is printed on return from the command handler */
> > >          return 0;
> > >      } else {
> > > -        monitor_printf(&hmp->parent_obj,
> > > -                       "terminal does not support password prompting\n");
> > > +        monitor_hmp_printf(hmp, "terminal does not support password prompting\n");
> > >          return -ENOTTY;
> > >      }
> > >  }
> > > @@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
> > >      return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
> > >  }
> > >
> > > -static void help_cmd_dump_one(Monitor *mon,
> > > +static void help_cmd_dump_one(MonitorHMP *mon,
> > >                                const HMPCommand *cmd,
> > >                                char **prefix_args,
> > >                                int prefix_args_nb)
> > > @@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
> > >      }
> > >
> > >      for (i = 0; i < prefix_args_nb; i++) {
> > > -        monitor_printf(mon, "%s ", prefix_args[i]);
> > > +        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
> > >      }
> > > -    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
> > > +    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
> > >  }
> > >
> > >  /* @args[@arg_index] is the valid command need to find in @cmds */
> > > -static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
> > > +static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
> > >                            char **args, int nb_args, int arg_index)
> > >  {
> > >      const HMPCommand *cmd;
> > > @@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
> > >      }
> > >
> > >      /* Command not found */
> > > -    monitor_printf(mon, "unknown command: '");
> > > +    monitor_hmp_printf(mon, "unknown command: '");
> > >      for (i = 0; i <= arg_index; i++) {
> > > -        monitor_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
> > > +        monitor_hmp_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
> > >      }
> > >  }
> > >
> > > -void hmp_help_cmd(Monitor *mon, const char *name)
> > > +void hmp_help_cmd(MonitorHMP *mon, const char *name)
> > >  {
> > >      char *args[MAX_ARGS];
> > >      int nb_args = 0;
> > > @@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
> > >          /* special case for log, directly dump and return */
> > >          if (!strcmp(name, "log")) {
> > >              const QEMULogItem *item;
> > > -            monitor_printf(mon, "Log items (comma separated):\n");
> > > -            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs");
> > > +            monitor_hmp_printf(mon, "Log items (comma separated):\n");
> > > +            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all logs");
> > >              for (item = qemu_log_items; item->mask != 0; item++) {
> > > -                monitor_printf(mon, "%-15s %s\n", item->name, item->help);
> > > +                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item->help);
> > >              }
> > >  #ifdef CONFIG_TRACE_LOG
> > > -            monitor_printf(mon, "trace:PATTERN   enable trace events\n");
> > > -            monitor_printf(mon, "\nUse \"log trace:help\" to get a list of "
> > > -                           "trace events.\n\n");
> > > +            monitor_hmp_printf(mon, "trace:PATTERN   enable trace events\n");
> > > +            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a list of "
> > > +                               "trace events.\n\n");
> > >  #endif
> > >              return;
> > >          }
> > > @@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
> > >  static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char *name);
> > >
> > >  static G_NORETURN G_GNUC_PRINTF(2, 3)
> > > -void expr_error(Monitor *mon, const char *fmt, ...)
> > > +void expr_error(MonitorHMP *mon, const char *fmt, ...)
> > >  {
> > >      va_list ap;
> > >      va_start(ap, fmt);
> > > -    monitor_vprintf(mon, fmt, ap);
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_vprintf(mon, fmt, ap);
> > > +    monitor_hmp_printf(mon, "\n");
> > >      va_end(ap);
> > >      siglongjmp(expr_env, 1);
> > >  }
> > > @@ -475,9 +465,9 @@ static void next(void)
> > >      }
> > >  }
> > >
> > > -static int64_t expr_sum(Monitor *mon);
> > > +static int64_t expr_sum(MonitorHMP *mon);
> > >
> > > -static int64_t expr_unary(Monitor *mon)
> > > +static int64_t expr_unary(MonitorHMP *mon)
> > >  {
> > >      int64_t n;
> > >      char *p;
> > > @@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
> > >                  pch++;
> > >              }
> > >              *q = 0;
> > > -            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
> > > -                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
> > > +            if (!gdb_get_register(mon, &reg, buf)
> > > +                && get_monitor_def(mon, &reg, buf) < 0) {
> > >                  expr_error(mon, "unknown register");
> > >              }
> > >              n = reg;
> > > @@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
> > >      return n;
> > >  }
> > >
> > > -static int64_t expr_prod(Monitor *mon)
> > > +static int64_t expr_prod(MonitorHMP *mon)
> > >  {
> > >      int64_t val, val2;
> > >      int op;
> > > @@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
> > >      return val;
> > >  }
> > >
> > > -static int64_t expr_logic(Monitor *mon)
> > > +static int64_t expr_logic(MonitorHMP *mon)
> > >  {
> > >      int64_t val, val2;
> > >      int op;
> > > @@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
> > >      return val;
> > >  }
> > >
> > > -static int64_t expr_sum(Monitor *mon)
> > > +static int64_t expr_sum(MonitorHMP *mon)
> > >  {
> > >      int64_t val, val2;
> > >      int op;
> > > @@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
> > >      return val;
> > >  }
> > >
> > > -static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
> > > +static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
> > >  {
> > >      pch = *pp;
> > >      if (sigsetjmp(expr_env, 0)) {
> > > @@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
> > >      return 0;
> > >  }
> > >
> > > -static int get_double(Monitor *mon, double *pval, const char **pp)
> > > +static int get_double(MonitorHMP *mon, double *pval, const char **pp)
> > >  {
> > >      const char *p = *pp;
> > >      char *tailp;
> > > @@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval, const char **pp)
> > >
> > >      d = strtod(p, &tailp);
> > >      if (tailp == p) {
> > > -        monitor_printf(mon, "Number expected\n");
> > > +        monitor_hmp_printf(mon, "Number expected\n");
> > >          return -1;
> > >      }
> > >      if (d != d || d - d != 0) {
> > >          /* NaN or infinity */
> > > -        monitor_printf(mon, "Bad number\n");
> > > +        monitor_hmp_printf(mon, "Bad number\n");
> > >          return -1;
> > >      }
> > >      *pval = d;
> > > @@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
> > >                                                 const char **cmdp,
> > >                                                 HMPCommand *table)
> > >  {
> > > -    Monitor *mon = &hmp->parent_obj;
> > >      const char *p;
> > >      const HMPCommand *cmd;
> > >      char cmdname[256];
> > > @@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
> > >
> > >      cmd = search_dispatch_table(table, cmdname);
> > >      if (!cmd) {
> > > -        monitor_printf(mon, "unknown command: '%.*s'\n",
> > > -                       (int)(p - cmdp_start), cmdp_start);
> > > +        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
> > > +                           (int)(p - cmdp_start), cmdp_start);
> > >          return NULL;
> > >      }
> > >      if (!cmd_available(cmd)) {
> > > -        monitor_printf(mon, "Command '%.*s' not available "
> > > -                            "until machine initialization has completed.\n",
> > > -                       (int)(p - cmdp_start), cmdp_start);
> > > +        monitor_hmp_printf(hmp, "Command '%.*s' not available "
> > > +                           "until machine initialization has completed.\n",
> > > +                           (int)(p - cmdp_start), cmdp_start);
> > >          return NULL;
> > >      }
> > >
> > > @@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
> > >   * Else, insert command arguments into a QDict, and return it.
> > >   * Note: On success, caller has to free the QDict structure.
> > >   */
> > > -static QDict *monitor_parse_arguments(Monitor *mon,
> > > +static QDict *monitor_parse_arguments(MonitorHMP *mon,
> > >                                        const char **endp,
> > >                                        const HMPCommand *cmd)
> > >  {
> > > @@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                  if (ret < 0) {
> > >                      switch (c) {
> > >                      case 'F':
> > > -                        monitor_printf(mon, "%s: filename expected\n",
> > > -                                       cmd->name);
> > > +                        monitor_hmp_printf(mon, "%s: filename expected\n",
> > > +                                           cmd->name);
> > >                          break;
> > >                      case 'B':
> > > -                        monitor_printf(mon, "%s: block device name expected\n",
> > > -                                       cmd->name);
> > > +                        monitor_hmp_printf(mon, "%s: block device name expected\n",
> > > +                                           cmd->name);
> > >                          break;
> > >                      default:
> > > -                        monitor_printf(mon, "%s: string expected\n", cmd->name);
> > > +                        monitor_hmp_printf(mon, "%s: string expected\n", cmd->name);
> > >                          break;
> > >                      }
> > >                      goto fail;
> > > @@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                      }
> > >                  next:
> > >                      if (*p != '\0' && !qemu_isspace(*p)) {
> > > -                        monitor_printf(mon, "invalid char in format: '%c'\n",
> > > -                                       *p);
> > > +                        monitor_hmp_printf(mon, "invalid char in format: '%c'\n",
> > > +                                           *p);
> > >                          goto fail;
> > >                      }
> > >                      if (format < 0) {
> > > @@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                  }
> > >                  /* Check if 'i' is greater than 32-bit */
> > >                  if ((c == 'i') && ((val >> 32) & 0xffffffff)) {
> > > -                    monitor_printf(mon, "\'%s\' has failed: ", cmd->name);
> > > -                    monitor_printf(mon, "integer is for 32-bit values\n");
> > > +                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd->name);
> > > +                    monitor_hmp_printf(mon, "integer is for 32-bit values\n");
> > >                      goto fail;
> > >                  } else if (c == 'M') {
> > >                      if (val < 0) {
> > > -                        monitor_printf(mon, "enter a positive value\n");
> > > +                        monitor_hmp_printf(mon, "enter a positive value\n");
> > >                          goto fail;
> > >                      }
> > >                      val *= MiB;
> > > @@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                  }
> > >                  ret = qemu_strtosz_MiB(p, &end, &val);
> > >                  if (ret < 0 || val > INT64_MAX) {
> > > -                    monitor_printf(mon, "invalid size\n");
> > > +                    monitor_hmp_printf(mon, "invalid size\n");
> > >                      goto fail;
> > >                  }
> > >                  qdict_put_int(qdict, key, val);
> > > @@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                      }
> > >                  }
> > >                  if (*p && !qemu_isspace(*p)) {
> > > -                    monitor_printf(mon, "Unknown unit suffix\n");
> > > +                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
> > >                      goto fail;
> > >                  }
> > >                  qdict_put(qdict, key, qnum_from_double(val));
> > > @@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                  } else if (p - beg == 3 && !memcmp(beg, "off", p - beg)) {
> > >                      val = false;
> > >                  } else {
> > > -                    monitor_printf(mon, "Expected 'on' or 'off'\n");
> > > +                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n");
> > >                      goto fail;
> > >                  }
> > >                  qdict_put_bool(qdict, key, val);
> > > @@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                      p++;
> > >                      if (c != *p) {
> > >                          if (!is_valid_option(p, typestr)) {
> > > -                            monitor_printf(mon, "%s: unsupported option -%c\n",
> > > -                                           cmd->name, *p);
> > > +                            monitor_hmp_printf(mon, "%s: unsupported option -%c\n",
> > > +                                               cmd->name, *p);
> > >                              goto fail;
> > >                          } else {
> > >                              skip_key = 1;
> > > @@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                          }
> > >                          ret = get_str(buf, sizeof(buf), &p);
> > >                          if (ret < 0) {
> > > -                            monitor_printf(mon, "%s: value expected for -%c\n",
> > > -                                           cmd->name, *tmp);
> > > +                            monitor_hmp_printf(mon, "%s: value expected for -%c\n",
> > > +                                               cmd->name, *tmp);
> > >                              goto fail;
> > >                          }
> > >                          qdict_put_str(qdict, key, buf);
> > > @@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >                  }
> > >                  len = strlen(p);
> > >                  if (len <= 0) {
> > > -                    monitor_printf(mon, "%s: string expected\n",
> > > -                                   cmd->name);
> > > +                    monitor_hmp_printf(mon, "%s: string expected\n",
> > > +                                       cmd->name);
> > >                      goto fail;
> > >                  }
> > >                  qdict_put_str(qdict, key, p);
> > > @@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >              break;
> > >          default:
> > >          bad_type:
> > > -            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
> > > +            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
> > >              goto fail;
> > >          }
> > >          g_free(key);
> > > @@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
> > >          p++;
> > >      }
> > >      if (*p != '\0') {
> > > -        monitor_printf(mon, "%s: extraneous characters at the end of line\n",
> > > -                       cmd->name);
> > > +        monitor_hmp_printf(mon, "%s: extraneous characters at the end of line\n",
> > > +                           cmd->name);
> > >          goto fail;
> > >      }
> > >
> > > @@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const char *cmdline)
> > >
> > >      if (!cmd->cmd && !cmd->cmd_info_hrt) {
> > >          /* FIXME: is it useful to try autoload modules here ??? */
> > > -        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not available.\n",
> > > -                       (int)(cmdline - cmd_start), cmd_start);
> > > +        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n",
> > > +                           (int)(cmdline - cmd_start), cmd_start);
> > >          return;
> > >      }
> > >
> > > -    qdict = monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd);
> > > +    qdict = monitor_parse_arguments(hmp, &cmdline, cmd);
> > >      if (!qdict) {
> > >          while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
> > >              cmdline--;
> > >          }
> > > -        monitor_printf(&hmp->parent_obj,
> > > -                       "Try \"help %.*s\" for more information\n",
> > > -                       (int)(cmdline - cmd_start), cmd_start);
> > > +        monitor_hmp_printf(hmp,
> > > +                           "Try \"help %.*s\" for more information\n",
> > > +                           (int)(cmdline - cmd_start), cmd_start);
> > >          return;
> > >      }
> > >
> > > @@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint8_t *buf, int size)
> > >          }
> > >      } else {
> > >          if (size == 0 || buf[size - 1] != 0) {
> > > -            monitor_printf(&hmp->parent_obj, "corrupted command\n");
> > > +            monitor_hmp_printf(hmp, "corrupted command\n");
> > >          } else {
> > >              handle_hmp_command(hmp, (char *)buf);
> > >          }
> > > @@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEvent event)
> > >          break;
> > >
> > >      case CHR_EVENT_OPENED:
> > > -        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
> > > -                       "information\n", QEMU_VERSION);
> > > +        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for more "
> > > +                           "information\n", QEMU_VERSION);
> > >          qemu_mutex_lock(&mon->mon_lock);
> > >          hmp->reset_seen = 1;
> > >          if (!mon->mux_out && hmp->use_readline) {
> > > @@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_printf(void *opaque,
> > >      MonitorHMP *hmp = opaque;
> > >      va_list ap;
> > >      va_start(ap, fmt);
> > > -    monitor_vprintf(&hmp->parent_obj, fmt, ap);
> > > +    monitor_hmp_vprintf(hmp, fmt, ap);
> > >      va_end(ap);
> > >  }
> > >
> > > diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
> > > index afdda1386080..c198c12eaa00 100644
> > > --- a/monitor/monitor-internal.h
> > > +++ b/monitor/monitor-internal.h
> > > @@ -108,12 +108,6 @@ typedef struct HMPCommand {
> > >  struct MonitorClass {
> > >      ObjectClass parent_class;
> > >
> > > -    /*
> > > -     * If non-NULL, the monitor is able to print messages
> > > -     * for attention of the client user
> > > -     */
> > > -    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
> > > -        G_GNUC_PRINTF(2, 0);
> > >      /*
> > >       * If non-NULL, the monitor is able to send event
> > >       * notifications back to the client
> > > diff --git a/monitor/monitor.c b/monitor/monitor.c
> > > index 8528af6f79b8..da76e6e4ac19 100644
> > > --- a/monitor/monitor.c
> > > +++ b/monitor/monitor.c
> > > @@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
> > >      return monitor_puts_locked(mon, str);
> > >  }
> > >
> > > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> > >  {
> > > -    MonitorClass *moncls;
> > > +    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
> > >
> > >      if (!mon) {
> > >          return -1;
> > >      }
> > >
> > > -    moncls = MONITOR_GET_CLASS(mon);
> > > -    if (!moncls->vprintf) {
> > > -        return -1;
> > > -    }
> > > -
> > > -    return moncls->vprintf(mon, fmt, ap);
> > > +    return monitor_puts(MONITOR(mon), buf);
> > >  }
> > >
> > > -int monitor_printf(Monitor *mon, const char *fmt, ...)
> > > +int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
> > >  {
> > >      int ret;
> > >
> > >      va_list ap;
> > >      va_start(ap, fmt);
> > > -    ret = monitor_vprintf(mon, fmt, ap);
> > > +    ret = monitor_hmp_vprintf(mon, fmt, ap);
> > >      va_end(ap);
> > >      return ret;
> > >  }
> > >
> > > -void monitor_printc(Monitor *mon, int c)
> > > +void monitor_hmp_printc(MonitorHMP *mon, int c)
> > >  {
> > > -    monitor_printf(mon, "'");
> > > +    monitor_hmp_printf(mon, "'");
> > >      switch(c) {
> > >      case '\'':
> > > -        monitor_printf(mon, "\\'");
> > > +        monitor_hmp_printf(mon, "\\'");
> > >          break;
> > >      case '\\':
> > > -        monitor_printf(mon, "\\\\");
> > > +        monitor_hmp_printf(mon, "\\\\");
> > >          break;
> > >      case '\n':
> > > -        monitor_printf(mon, "\\n");
> > > +        monitor_hmp_printf(mon, "\\n");
> > >          break;
> > >      case '\r':
> > > -        monitor_printf(mon, "\\r");
> > > +        monitor_hmp_printf(mon, "\\r");
> > >          break;
> > >      default:
> > >          if (c >= 32 && c <= 126) {
> > > -            monitor_printf(mon, "%c", c);
> > > +            monitor_hmp_printf(mon, "%c", c);
> > >          } else {
> > > -            monitor_printf(mon, "\\x%02x", c);
> > > +            monitor_hmp_printf(mon, "\\x%02x", c);
> > >          }
> > >          break;
> > >      }
> > > -    monitor_printf(mon, "'");
> > > +    monitor_hmp_printf(mon, "'");
> > >  }
> > >
> > >  static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
> > > diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
> > > index 5b1c678f5d89..0d718d78aef9 100644
> > > --- a/net/net-hmp-cmds.c
> > > +++ b/net/net-hmp-cmds.c
> > > @@ -28,26 +28,25 @@
> > >  #include "qemu/help_option.h"
> > >  #include "qemu/option.h"
> > >
> > > -static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
> > > +static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *ci)
> > >  {
> > >      NetFilterInfoList *f;
> > >
> > > -    monitor_printf(mon, "%s: index=%" PRIu32 ",type=%s,%s\n",
> > > -                   ci->name, ci->queue_index,
> > > -                   NetClientDriver_str(ci->type), ci->info_str);
> > > +    monitor_hmp_printf(hmp, "%s: index=%" PRIu32 ",type=%s,%s\n",
> > > +                       ci->name, ci->queue_index,
> > > +                       NetClientDriver_str(ci->type), ci->info_str);
> > >      if (ci->filters) {
> > > -        monitor_printf(mon, "filters:\n");
> > > +        monitor_hmp_printf(hmp, "filters:\n");
> > >          for (f = ci->filters; f; f = f->next) {
> > > -            monitor_printf(mon, "  - %s: type=%s%s%s\n",
> > > -                           f->value->name, f->value->type,
> > > -                           f->value->info[0] ? "," : "", f->value->info);
> > > +            monitor_hmp_printf(hmp, "  - %s: type=%s%s%s\n",
> > > +                               f->value->name, f->value->type,
> > > +                               f->value->info[0] ? "," : "", f->value->info);
> > >          }
> > >      }
> > >  }
> > >
> > >  void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      Error *err = NULL;
> > >      g_autoptr(NetworkInfo) info = qmp_x_query_network(&err);
> > >      NetHubInfoList *h;
> > > @@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
> > >      for (h = info->hubs; h; h = h->next) {
> > >          NetHubPortInfoList *p;
> > >
> > > -        monitor_printf(mon, "hub %d\n", (int)h->value->id);
> > > +        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
> > >          for (p = h->value->ports; p; p = p->next) {
> > >              if (p->value->peer) {
> > > -                monitor_printf(mon, " \\ %s: ", p->value->name);
> > > -                hmp_print_client_info(mon, p->value->peer);
> > > +                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
> > > +                hmp_print_client_info(hmp, p->value->peer);
> > >              } else {
> > > -                monitor_printf(mon, " \\ %s\n", p->value->name);
> > > +                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
> > >              }
> > >          }
> > >      }
> > > @@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
> > >          NetworkClientInfo *ci = entry->value;
> > >
> > >          if (!ci->peer || ci->type == NET_CLIENT_DRIVER_NIC) {
> > > -            hmp_print_client_info(mon, ci);
> > > +            hmp_print_client_info(hmp, ci);
> > >          } /* else it's a netdev connected to a NIC, printed with the NIC */
> > >          if (ci->peer && ci->type == NET_CLIENT_DRIVER_NIC) {
> > > -            monitor_printf(mon, " \\ ");
> > > -            hmp_print_client_info(mon, ci->peer);
> > > +            monitor_hmp_printf(hmp, " \\ ");
> > > +            hmp_print_client_info(hmp, ci->peer);
> > >          }
> > >      }
> > >  }
> > > diff --git a/net/slirp.c b/net/slirp.c
> > > index d5c190b48b76..6fbefa9ed1d7 100644
> > > --- a/net/slirp.c
> > > +++ b/net/slirp.c
> > > @@ -711,22 +711,22 @@ error:
> > >      return -1;
> > >  }
> > >
> > > -static SlirpState *slirp_lookup(Monitor *mon, const char *id)
> > > +static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
> > >  {
> > >      if (id) {
> > >          NetClientState *nc = qemu_find_netdev(id);
> > >          if (!nc) {
> > > -            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
> > > +            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", id);
> > >              return NULL;
> > >          }
> > >          if (strcmp(nc->model, "user")) {
> > > -            monitor_printf(mon, "invalid device specified\n");
> > > +            monitor_hmp_printf(hmp, "invalid device specified\n");
> > >              return NULL;
> > >          }
> > >          return DO_UPCAST(SlirpState, nc, nc);
> > >      } else {
> > >          if (QTAILQ_EMPTY(&slirp_stacks)) {
> > > -            monitor_printf(mon, "user mode network stack not in use\n");
> > > +            monitor_hmp_printf(hmp, "user mode network stack not in use\n");
> > >              return NULL;
> > >          }
> > >          return QTAILQ_FIRST(&slirp_stacks);
> > > @@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const char *id)
> > >
> > >  void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      /* TODO: support removing unix fwd */
> > >      struct sockaddr_in host_addr = {
> > >          .sin_family = AF_INET,
> > > @@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
> > >      const char *arg2 = qdict_get_try_str(qdict, "arg2");
> > >
> > >      if (arg2) {
> > > -        s = slirp_lookup(mon, arg1);
> > > +        s = slirp_lookup(hmp, arg1);
> > >          src_str = arg2;
> > >      } else {
> > > -        s = slirp_lookup(mon, NULL);
> > > +        s = slirp_lookup(hmp, NULL);
> > >          src_str = arg1;
> > >      }
> > >      if (!s) {
> > > @@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
> > >      err = slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr, host_port);
> > >  #endif
> > >
> > > -    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
> > > -                   err ? "not found" : "removed");
> > > +    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_str,
> > > +                       err ? "not found" : "removed");
> > >      return;
> > >
> > >   fail_syntax:
> > > -    monitor_printf(mon, "invalid format\n");
> > > +    monitor_hmp_printf(hmp, "invalid format\n");
> > >  }
> > >
> > >  static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
> > > @@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
> > >
> > >  void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *redir_str;
> > >      SlirpState *s;
> > >      const char *arg1 = qdict_get_str(qdict, "arg1");
> > >      const char *arg2 = qdict_get_try_str(qdict, "arg2");
> > >
> > >      if (arg2) {
> > > -        s = slirp_lookup(mon, arg1);
> > > +        s = slirp_lookup(hmp, arg1);
> > >          redir_str = arg2;
> > >      } else {
> > > -        s = slirp_lookup(mon, NULL);
> > > +        s = slirp_lookup(hmp, NULL);
> > >          redir_str = arg1;
> > >      }
> > >      if (s) {
> > > @@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **errp)
> > >
> > >  void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      g_autoptr(UsernetInfoList) list = NULL;
> > >      UsernetInfoList *entry;
> > >
> > >      list = qmp_x_query_usernet(&error_abort);
> > >      for (entry = list; entry; entry = entry->next) {
> > >          UsernetInfo *ui = entry->value;
> > > -        monitor_printf(mon, "Hub %d (%s):\n%s",
> > > -                       ui->has_hub_id ? (int)ui->hub_id : -1,
> > > -                       ui->hub_name, ui->info);
> > > +        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
> > > +                           ui->has_hub_id ? (int)ui->hub_id : -1,
> > > +                           ui->hub_name, ui->info);
> > >      }
> > >  }
> > >
> > > diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
> > > index 2e2eb33371e2..bbf5980332a4 100644
> > > --- a/qom/qom-hmp-cmds.c
> > > +++ b/qom/qom-hmp-cmds.c
> > > @@ -20,13 +20,12 @@
> > >
> > >  void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *path = qdict_get_try_str(qdict, "path");
> > >      ObjectPropertyInfoList *list;
> > >      Error *err = NULL;
> > >
> > >      if (path == NULL) {
> > > -        monitor_printf(mon, "/\n");
> > > +        monitor_hmp_printf(hmp, "/\n");
> > >          return;
> > >      }
> > >
> > > @@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
> > >          while (list != NULL) {
> > >              ObjectPropertyInfo *value = list->value;
> > >
> > > -            monitor_printf(mon, "%s (%s)\n",
> > > -                           value->name, value->type);
> > > +            monitor_hmp_printf(hmp, "%s (%s)\n",
> > > +                               value->name, value->type);
> > >              list = list->next;
> > >          }
> > >          qapi_free_ObjectPropertyInfoList(start);
> > > @@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *path = qdict_get_str(qdict, "path");
> > >      const char *property = qdict_get_str(qdict, "property");
> > >      Error *err = NULL;
> > > @@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      if (err == NULL) {
> > >          GString *str = qobject_to_json_pretty(obj, true);
> > > -        monitor_printf(mon, "%s\n", str->str);
> > > +        monitor_hmp_printf(hmp, "%s\n", str->str);
> > >          g_string_free(str, true);
> > >      }
> > >
> > > @@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
> > >      int indent;
> > >  } QOMCompositionState;
> > >
> > > -static void print_qom_composition(Monitor *mon, Object *obj, int indent);
> > > +static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent);
> > >
> > >  static int qom_composition_compare(const void *a, const void *b)
> > >  {
> > > @@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj, void *opaque)
> > >      return 0;
> > >  }
> > >
> > > -static void print_qom_composition(Monitor *mon, Object *obj, int indent)
> > > +static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent)
> > >  {
> > >      GArray *children = g_array_new(false, false, sizeof(Object *));
> > >      const char *name;
> > > @@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
> > >      } else {
> > >          name = object_get_canonical_path_component(obj);
> > >      }
> > > -    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
> > > -                   object_get_typename(obj));
> > > +    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
> > > +                       object_get_typename(obj));
> > >
> > >      object_child_foreach(obj, insert_qom_composition_child, children);
> > >      g_array_sort(children, qom_composition_compare);
> > >
> > >      for (i = 0; i < children->len; i++) {
> > > -        print_qom_composition(mon, g_array_index(children, Object *, i),
> > > +        print_qom_composition(hmp, g_array_index(children, Object *, i),
> > >                                indent + 2);
> > >      }
> > >      g_array_free(children, TRUE);
> > > @@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
> > >
> > >  void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *path = qdict_get_try_str(dict, "path");
> > >      Object *obj;
> > >      bool ambiguous = false;
> > > @@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
> > >      if (path) {
> > >          obj = object_resolve_path(path, &ambiguous);
> > >          if (!obj) {
> > > -            monitor_printf(mon, "Path '%s' could not be resolved.\n", path);
> > > +            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\n", path);
> > >              return;
> > >          }
> > >          if (ambiguous) {
> > > -            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", path);
> > > +            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\n", path);
> > >              return;
> > >          }
> > >      } else {
> > >          obj = qdev_get_machine();
> > >      }
> > > -    print_qom_composition(mon, obj, 0);
> > > +    print_qom_composition(hmp, obj, 0);
> > >  }
> > >
> > >  void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
> > > diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
> > > index ef69d23ff507..965565715ef2 100644
> > > --- a/replay/replay-debugging.c
> > > +++ b/replay/replay-debugging.c
> > > @@ -33,11 +33,10 @@ bool replay_running_debug(void)
> > >
> > >  void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      if (replay_mode == REPLAY_MODE_NONE) {
> > > -        monitor_printf(mon, "Record/replay is not active\n");
> > > +        monitor_hmp_printf(hmp, "Record/replay is not active\n");
> > >      } else {
> > > -        monitor_printf(mon,
> > > +        monitor_hmp_printf(hmp,
> > >              "%s execution '%s': instruction count = %"PRId64"\n",
> > >              replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
> > >              replay_get_filename(), replay_get_current_icount());
> > > diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
> > > index cd1f1deb58bc..3d556c745d61 100644
> > > --- a/stats/stats-hmp-cmds.c
> > > +++ b/stats/stats-hmp-cmds.c
> > > @@ -14,11 +14,11 @@
> > >  #include "qobject/qdict.h"
> > >  #include "qapi/error.h"
> > >
> > > -static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
> > > +static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue *value)
> > >  {
> > >      const char *unit = NULL;
> > > -    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(value->type),
> > > -                   value->has_unit || value->exponent ? ", " : "");
> > > +    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str(value->type),
> > > +                       value->has_unit || value->exponent ? ", " : "");
> > >
> > >      if (value->has_unit) {
> > >          if (value->unit == STATS_UNIT_SECONDS) {
> > > @@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
> > >      if (unit && value->base == 10 &&
> > >          value->exponent >= -18 && value->exponent <= 18 &&
> > >          value->exponent % 3 == 0) {
> > > -        monitor_puts(mon, si_prefix(value->exponent));
> > > +        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
> > >      } else if (unit && value->base == 2 &&
> > >                 value->exponent >= 0 && value->exponent <= 60 &&
> > >                 value->exponent % 10 == 0) {
> > >
> > > -        monitor_puts(mon, iec_binary_prefix(value->exponent));
> > > +        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent));
> > >      } else if (value->exponent) {
> > >          /* Use exponential notation and write the unit's English name */
> > > -        monitor_printf(mon, "* %d^%d%s",
> > > -                       value->base, value->exponent,
> > > -                       value->has_unit ? " " : "");
> > > +        monitor_hmp_printf(hmp, "* %d^%d%s",
> > > +                           value->base, value->exponent,
> > > +                           value->has_unit ? " " : "");
> > >          unit = NULL;
> > >      }
> > >
> > >      if (value->has_unit) {
> > > -        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
> > > +        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->unit));
> > >      }
> > >
> > >      /* Print bucket size for linear histograms */
> > >      if (value->type == STATS_TYPE_LINEAR_HISTOGRAM && value->has_bucket_size) {
> > > -        monitor_printf(mon, ", bucket size=%d", value->bucket_size);
> > > +        monitor_hmp_printf(hmp, ", bucket size=%d", value->bucket_size);
> > >      }
> > > -    monitor_printf(mon, ")");
> > > +    monitor_hmp_printf(hmp, ")");
> > >  }
> > >
> > >  static StatsSchemaValueList *find_schema_value_list(
> > > @@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
> > >      return NULL;
> > >  }
> > >
> > > -static void print_stats_results(Monitor *mon, StatsTarget target,
> > > +static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
> > >                                  bool show_provider,
> > >                                  StatsResult *result,
> > >                                  StatsSchemaList *schema)
> > > @@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
> > >      StatsList *stats_list;
> > >
> > >      if (!schema_value_list) {
> > > -        monitor_printf(mon, "failed to find schema list for %s\n",
> > > -                       StatsProvider_str(result->provider));
> > > +        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
> > > +                           StatsProvider_str(result->provider));
> > >          return;
> > >      }
> > >
> > >      if (show_provider) {
> > > -        monitor_printf(mon, "provider: %s\n",
> > > -                       StatsProvider_str(result->provider));
> > > +        monitor_hmp_printf(hmp, "provider: %s\n",
> > > +                           StatsProvider_str(result->provider));
> > >      }
> > >
> > >      for (stats_list = result->stats; stats_list;
> > > @@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
> > >          /* Find schema entry */
> > >          while (!g_str_equal(stats->name, schema_value->name)) {
> > >              if (!schema_value_list->next) {
> > > -                monitor_printf(mon, "failed to find schema entry for %s\n",
> > > -                               stats->name);
> > > +                monitor_hmp_printf(hmp, "failed to find schema entry for %s\n",
> > > +                                   stats->name);
> > >                  return;
> > >              }
> > >              schema_value_list = schema_value_list->next;
> > >              schema_value = schema_value_list->value;
> > >          }
> > >
> > > -        print_stats_schema_value(mon, schema_value);
> > > +        print_stats_schema_value(hmp, schema_value);
> > >
> > >          if (stats_value->type == QTYPE_QNUM) {
> > > -            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scalar);
> > > +            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.scalar);
> > >          } else if (stats_value->type == QTYPE_QBOOL) {
> > > -            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "yes" : "no");
> > > +            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ? "yes" : "no");
> > >          } else if (stats_value->type == QTYPE_QLIST) {
> > >              uint64List *list;
> > >              int i;
> > >
> > > -            monitor_printf(mon, ": ");
> > > +            monitor_hmp_printf(hmp, ": ");
> > >              for (list = stats_value->u.list, i = 1;
> > >                   list;
> > >                   list = list->next, i++) {
> > > -                monitor_printf(mon, "[%d]=%" PRId64 " ", i, list->value);
> > > +                monitor_hmp_printf(hmp, "[%d]=%" PRId64 " ", i, list->value);
> > >              }
> > > -            monitor_printf(mon, "\n");
> > > +            monitor_hmp_printf(hmp, "\n");
> > >          }
> > >      }
> > >  }
> > > @@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target, const char *names,
> > >
> > >  void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *target_str = qdict_get_str(qdict, "target");
> > >      const char *provider_str = qdict_get_try_str(qdict, "provider");
> > >      const char *names = qdict_get_try_str(qdict, "names");
> > > @@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      target = qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &err);
> > >      if (err) {
> > > -        monitor_printf(mon, "invalid stats target %s\n", target_str);
> > > +        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_str);
> > >          goto exit_no_print;
> > >      }
> > >      if (provider_str) {
> > >          provider = qapi_enum_parse(&StatsProvider_lookup, provider_str, -1, &err);
> > >          if (err) {
> > > -            monitor_printf(mon, "invalid stats provider %s\n", provider_str);
> > > +            monitor_hmp_printf(hmp, "invalid stats provider %s\n", provider_str);
> > >              goto exit_no_print;
> > >          }
> > >      }
> > > @@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
> > >          goto exit;
> > >      }
> > >      for (entry = stats; entry; entry = entry->next) {
> > > -        print_stats_results(mon, target, provider_str == NULL, entry->value, schema);
> > > +        print_stats_results(hmp, target, provider_str == NULL, entry->value, schema);
> > >      }
> > >
> > >  exit:
> > >      if (err) {
> > > -        monitor_printf(mon, "%s\n", error_get_pretty(err));
> > > +        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
> > >      }
> > >  exit_no_print:
> > >      error_free(err);
> > > diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
> > > index 6f2b87d1ad10..c9c1d10c165c 100644
> > > --- a/stubs/hmp-cmd-info_sev.c
> > > +++ b/stubs/hmp-cmd-info_sev.c
> > > @@ -12,6 +12,5 @@
> > >
> > >  void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > > -    monitor_printf(mon, "SEV is not available in this QEMU\n");
> > > +    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
> > >  }
> > > diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
> > > index b0c7002bd406..094b80721003 100644
> > > --- a/stubs/monitor-core.c
> > > +++ b/stubs/monitor-core.c
> > > @@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
> > >  {
> > >  }
> > >
> > > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> > >  {
> > >      /*
> > >       * Pretend 'g_test_message' is our monitor console to
> > > diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.c
> > > index 75194add7931..fb9338e9aef6 100644
> > > --- a/system/dirtylimit-hmp-cmds.c
> > > +++ b/system/dirtylimit-hmp-cmds.c
> > > @@ -17,7 +17,6 @@
> > >
> > >  void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      int64_t cpu_index = qdict_get_try_int(qdict, "cpu_index", -1);
> > >      Error *err = NULL;
> > >
> > > @@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query "
> > > -                   "dirty limit for virtual CPU]\n");
> > > +    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to query "
> > > +                       "dirty limit for virtual CPU]\n");
> > >  }
> > >
> > >  void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> > > @@ -50,13 +49,12 @@ out:
> > >
> > >  void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      DirtyLimitInfoList *info;
> > >      g_autoptr(DirtyLimitInfoList) head = NULL;
> > >      Error *err = NULL;
> > >
> > >      if (!dirtylimit_in_service()) {
> > > -        monitor_printf(mon, "Dirty page limit not enabled!\n");
> > > +        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
> > >          return;
> > >      }
> > >
> > > @@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
> > >      }
> > >
> > >      for (info = head; info != NULL; info = info->next) {
> > > -        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
> > > +        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
> > >                              " current rate %"PRIi64 " (MB/s)\n",
> > >                              info->value->cpu_index,
> > >                              info->value->limit_rate,
> > > diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> > > index 5c2de2f53cc9..3860ada2a237 100644
> > > --- a/system/qdev-monitor.c
> > > +++ b/system/qdev-monitor.c
> > > @@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
> > >      return ret;
> > >  }
> > >
> > > -#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ## __VA_ARGS__)
> > > +#define qdev_printf(fmt, ...) \
> > > +    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
> > >
> > > -static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
> > > +static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
> > >                               int indent)
> > >  {
> > >      for (int i = 0, n = dc->props_count_; i < n; ++i) {
> > > @@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int ind
> > >      }
> > >  }
> > >
> > > -static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
> > > +static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
> > >  {
> > > +    Monitor *mon = MONITOR(hmp);
> > >      ObjectClass *class;
> > >      NamedGPIOList *ngl;
> > >      NamedClockList *ncl;
> > > @@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
> > >      }
> > >      class = object_get_class(OBJECT(dev));
> > >      do {
> > > -        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
> > > +        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
> > >          class = object_class_get_parent(class);
> > >      } while (class != object_class_by_name(TYPE_DEVICE));
> > >      bus_print_dev(dev->parent_bus, mon, dev, indent);
> > >  }
> > >
> > > -static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
> > > +static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)
> > >  {
> > >      BusChild *kid;
> > >
> > > @@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
> > >          qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
> > >                      dev->id ? dev->id : "");
> > >          if (details) {
> > > -            qdev_print(mon, dev, indent + 2);
> > > +            qdev_print(hmp, dev, indent + 2);
> > >          }
> > >          QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
> > > -            qbus_print(mon, child_bus, indent + 2, details);
> > > +            qbus_print(hmp, child_bus, indent + 2, details);
> > >          }
> > >      }
> > >  }
> > > @@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
> > >
> > >  void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      bool details = !qdict_get_try_bool(qdict, "brief", false);
> > >
> > >      if (sysbus_get_default()) {
> > > -        qbus_print(mon, sysbus_get_default(), 0, details);
> > > +        qbus_print(hmp, sysbus_get_default(), 0, details);
> > >      }
> > >  }
> > >
> > > diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
> > > index 051ee45ee74c..ad70b53f8abf 100644
> > > --- a/system/runstate-hmp-cmds.c
> > > +++ b/system/runstate-hmp-cmds.c
> > > @@ -25,33 +25,31 @@
> > >
> > >  void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      StatusInfo *info;
> > >
> > >      info = qmp_query_status(NULL);
> > >
> > > -    monitor_printf(mon, "VM status: %s",
> > > -                   info->running ? "running" : "paused");
> > > +    monitor_hmp_printf(hmp, "VM status: %s",
> > > +                       info->running ? "running" : "paused");
> > >
> > >      if (!info->running && info->status != RUN_STATE_PAUSED) {
> > > -        monitor_printf(mon, " (%s)", RunState_str(info->status));
> > > +        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
> > >      }
> > >
> > > -    monitor_printf(mon, "\n");
> > > +    monitor_hmp_printf(hmp, "\n");
> > >
> > >      qapi_free_StatusInfo(info);
> > >  }
> > >
> > >  void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *option = qdict_get_try_str(qdict, "option");
> > >      AccelState *accel = current_accel();
> > >      bool newval;
> > >
> > >      if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
> > > -        monitor_printf(mon,
> > > -                       "This accelerator does not support setting one-insn-per-tb\n");
> > > +        monitor_hmp_printf(hmp,
> > > +                           "This accelerator does not support setting one-insn-per-tb\n");
> > >          return;
> > >      }
> > >
> > > @@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
> > >      } else if (!strcmp(option, "off")) {
> > >          newval = false;
> > >      } else {
> > > -        monitor_printf(mon, "unexpected option %s\n", option);
> > > +        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
> > >          return;
> > >      }
> > >      /* If the property exists then setting it can never fail */
> > > diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
> > > index 094c3f16cf50..35406e24d2c3 100644
> > > --- a/system/tpm-hmp-cmds.c
> > > +++ b/system/tpm-hmp-cmds.c
> > > @@ -13,7 +13,6 @@
> > >
> > >  void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >  #ifdef CONFIG_TPM
> > >      TPMInfoList *info_list, *info;
> > >      Error *err = NULL;
> > > @@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >      info_list = qmp_query_tpm(&err);
> > >      if (err) {
> > > -        monitor_printf(mon, "TPM device not supported\n");
> > > +        monitor_hmp_printf(hmp, "TPM device not supported\n");
> > >          error_free(err);
> > >          return;
> > >      }
> > >
> > >      if (info_list) {
> > > -        monitor_printf(mon, "TPM device:\n");
> > > +        monitor_hmp_printf(hmp, "TPM device:\n");
> > >      }
> > >
> > >      for (info = info_list; info; info = info->next) {
> > >          TPMInfo *ti = info->value;
> > > -        monitor_printf(mon, " tpm%d: model=%s\n",
> > > -                       c, TpmModel_str(ti->model));
> > > +        monitor_hmp_printf(hmp, " tpm%d: model=%s\n",
> > > +                           c, TpmModel_str(ti->model));
> > >
> > > -        monitor_printf(mon, "  \\ %s: type=%s",
> > > -                       ti->id, TpmType_str(ti->options->type));
> > > +        monitor_hmp_printf(hmp, "  \\ %s: type=%s",
> > > +                           ti->id, TpmType_str(ti->options->type));
> > >
> > >          switch (ti->options->type) {
> > >          case TPM_TYPE_PASSTHROUGH:
> > >              tpo = ti->options->u.passthrough.data;
> > > -            monitor_printf(mon, "%s%s%s%s",
> > > -                           tpo->path ? ",path=" : "",
> > > -                           tpo->path ?: "",
> > > -                           tpo->cancel_path ? ",cancel-path=" : "",
> > > -                           tpo->cancel_path ?: "");
> > > +            monitor_hmp_printf(hmp, "%s%s%s%s",
> > > +                               tpo->path ? ",path=" : "",
> > > +                               tpo->path ?: "",
> > > +                               tpo->cancel_path ? ",cancel-path=" : "",
> > > +                               tpo->cancel_path ?: "");
> > >              break;
> > >          case TPM_TYPE_EMULATOR:
> > >              teo = ti->options->u.emulator.data;
> > > -            monitor_printf(mon, ",chardev=%s", teo->chardev);
> > > +            monitor_hmp_printf(hmp, ",chardev=%s", teo->chardev);
> > >              break;
> > >          case TPM_TYPE__MAX:
> > >              break;
> > >          }
> > > -        monitor_printf(mon, "\n");
> > > +        monitor_hmp_printf(hmp, "\n");
> > >          c++;
> > >      }
> > >      qapi_free_TPMInfoList(info_list);
> > >  #else
> > > -    monitor_printf(mon, "TPM device not supported\n");
> > > +    monitor_hmp_printf(hmp, "TPM device not supported\n");
> > >  #endif /* CONFIG_TPM */
> > >  }
> > > diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
> > > index 3ae20f004b64..5d69ece15034 100644
> > > --- a/target/i386/cpu-apic.c
> > > +++ b/target/i386/cpu-apic.c
> > > @@ -82,7 +82,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
> > >
> > >  void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUState *cs;
> > >
> > >      if (qdict_haskey(qdict, "apic-id")) {
> > > @@ -98,7 +97,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >
> > >      if (!cs) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >      x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
> > > diff --git a/target/i386/monitor.c b/target/i386/monitor.c
> > > index 72bcab131f77..46762540ba65 100644
> > > --- a/target/i386/monitor.c
> > > +++ b/target/i386/monitor.c
> > > @@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
> > >      return addr;
> > >  }
> > >
> > > -static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
> > > +static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
> > >                        hwaddr pte, hwaddr mask)
> > >  {
> > >      addr = addr_canonical(env, addr);
> > >
> > > -    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
> > > -                   " %c%c%c%c%c%c%c%c%c\n",
> > > -                   addr,
> > > -                   pte & mask,
> > > -                   pte & PG_NX_MASK ? 'X' : '-',
> > > -                   pte & PG_GLOBAL_MASK ? 'G' : '-',
> > > -                   pte & PG_PSE_MASK ? 'P' : '-',
> > > -                   pte & PG_DIRTY_MASK ? 'D' : '-',
> > > -                   pte & PG_ACCESSED_MASK ? 'A' : '-',
> > > -                   pte & PG_PCD_MASK ? 'C' : '-',
> > > -                   pte & PG_PWT_MASK ? 'T' : '-',
> > > -                   pte & PG_USER_MASK ? 'U' : '-',
> > > -                   pte & PG_RW_MASK ? 'W' : '-');
> > > +    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
> > > +                       " %c%c%c%c%c%c%c%c%c\n",
> > > +                       addr,
> > > +                       pte & mask,
> > > +                       pte & PG_NX_MASK ? 'X' : '-',
> > > +                       pte & PG_GLOBAL_MASK ? 'G' : '-',
> > > +                       pte & PG_PSE_MASK ? 'P' : '-',
> > > +                       pte & PG_DIRTY_MASK ? 'D' : '-',
> > > +                       pte & PG_ACCESSED_MASK ? 'A' : '-',
> > > +                       pte & PG_PCD_MASK ? 'C' : '-',
> > > +                       pte & PG_PWT_MASK ? 'T' : '-',
> > > +                       pte & PG_USER_MASK ? 'U' : '-',
> > > +                       pte & PG_RW_MASK ? 'W' : '-');
> > >  }
> > >
> > > -static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      unsigned int l1, l2;
> > > @@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >          if (pde & PG_PRESENT_MASK) {
> > >              if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
> > >                  /* 4M pages */
> > > -                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
> > > +                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1));
> > >              } else {
> > >                  for(l2 = 0; l2 < 1024; l2++) {
> > >                      pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
> > >                                                 attrs, NULL);
> > >                      if (pte & PG_PRESENT_MASK) {
> > > -                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
> > > +                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
> > >                                    pte & ~PG_PSE_MASK,
> > >                                    ~0xfff);
> > >                      }
> > > @@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >      }
> > >  }
> > >
> > > -static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      unsigned int l1, l2, l3;
> > > @@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                  if (pde & PG_PRESENT_MASK) {
> > >                      if (pde & PG_PSE_MASK) {
> > >                          /* 2M pages with PAE, CR4.PSE is ignored */
> > > -                        print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
> > > +                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), pde,
> > >                                    ~((hwaddr)(1 << 20) - 1));
> > >                      } else {
> > >                          pt_addr = pde & 0x3fffffffff000ULL;
> > > @@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                              pte = address_space_ldq_le(as, pt_addr + l3 * 8,
> > >                                                         attrs, NULL);
> > >                              if (pte & PG_PRESENT_MASK) {
> > > -                                print_pte(mon, env, (l1 << 30) + (l2 << 21)
> > > +                                print_pte(hmp, env, (l1 << 30) + (l2 << 21)
> > >                                            + (l3 << 12),
> > >                                            pte & ~PG_PSE_MASK,
> > >                                            ~(hwaddr)0xfff);
> > > @@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >  }
> > >
> > >  #ifdef TARGET_X86_64
> > > -static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
> > > +static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as,
> > >          uint64_t l0, uint64_t pml4_addr)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > > @@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
> > >
> > >              if (pdpe & PG_PSE_MASK) {
> > >                  /* 1G pages, CR4.PSE is ignored */
> > > -                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
> > > +                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
> > >                          pdpe, 0x3ffffc0000000ULL);
> > >                  continue;
> > >              }
> > > @@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
> > >
> > >                  if (pde & PG_PSE_MASK) {
> > >                      /* 2M pages, CR4.PSE is ignored */
> > > -                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
> > > +                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
> > >                              (l3 << 21), pde, 0x3ffffffe00000ULL);
> > >                      continue;
> > >                  }
> > > @@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
> > >                      pte = address_space_ldq_le(as, pt_addr + l4 * 8,
> > >                                                 attrs, NULL);
> > >                      if (pte & PG_PRESENT_MASK) {
> > > -                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
> > > +                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
> > >                                  (l2 << 30) + (l3 << 21) + (l4 << 12),
> > >                                  pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
> > >                      }
> > > @@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
> > >      }
> > >  }
> > >
> > > -static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      uint64_t l0;
> > > @@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >      for (l0 = 0; l0 < 512; l0++) {
> > >          pml5e = address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, NULL);
> > >          if (pml5e & PG_PRESENT_MASK) {
> > > -            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL);
> > > +            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL);
> > >          }
> > >      }
> > >  }
> > > @@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >
> > >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env;
> > >      AddressSpace *as;
> > >
> > >      env = monitor_hmp_get_cpu_env(hmp);
> > >      if (!env) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >
> > >      if (!(env->cr[0] & CR0_PG_MASK)) {
> > > -        monitor_printf(mon, "PG disabled\n");
> > > +        monitor_hmp_printf(hmp, "PG disabled\n");
> > >          return;
> > >      }
> > >      as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
> > > @@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  #ifdef TARGET_X86_64
> > >          if (env->hflags & HF_LMA_MASK) {
> > >              if (env->cr[4] & CR4_LA57_MASK) {
> > > -                tlb_info_la57(mon, env, as);
> > > +                tlb_info_la57(hmp, env, as);
> > >              } else {
> > > -                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
> > > +                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
> > >              }
> > >          } else
> > >  #endif
> > >          {
> > > -            tlb_info_pae32(mon, env, as);
> > > +            tlb_info_pae32(hmp, env, as);
> > >          }
> > >      } else {
> > > -        tlb_info_32(mon, env, as);
> > > +        tlb_info_32(hmp, env, as);
> > >      }
> > >  }
> > >
> > > -static void mem_print(Monitor *mon, CPUArchState *env,
> > > +static void mem_print(MonitorHMP *hmp, CPUArchState *env,
> > >                        hwaddr *pstart, int *plast_prot,
> > >                        hwaddr end, int prot)
> > >  {
> > > @@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState *env,
> > >      prot1 = *plast_prot;
> > >      if (prot != prot1) {
> > >          if (*pstart != -1) {
> > > -            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
> > > -                           HWADDR_FMT_plx " %c%c%c\n",
> > > -                           addr_canonical(env, *pstart),
> > > -                           addr_canonical(env, end),
> > > -                           addr_canonical(env, end - *pstart),
> > > -                           prot1 & PG_USER_MASK ? 'u' : '-',
> > > -                           'r',
> > > -                           prot1 & PG_RW_MASK ? 'w' : '-');
> > > +            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
> > > +                               HWADDR_FMT_plx " %c%c%c\n",
> > > +                               addr_canonical(env, *pstart),
> > > +                               addr_canonical(env, end),
> > > +                               addr_canonical(env, end - *pstart),
> > > +                               prot1 & PG_USER_MASK ? 'u' : '-',
> > > +                               'r',
> > > +                               prot1 & PG_RW_MASK ? 'w' : '-');
> > >          }
> > >          if (prot != 0)
> > >              *pstart = end;
> > > @@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *env,
> > >      }
> > >  }
> > >
> > > -static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      unsigned int l1, l2;
> > > @@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >          if (pde & PG_PRESENT_MASK) {
> > >              if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
> > >                  prot = pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
> > > -                mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                mem_print(hmp, env, &start, &last_prot, end, prot);
> > >              } else {
> > >                  for(l2 = 0; l2 < 1024; l2++) {
> > >                      pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
> > > @@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                      } else {
> > >                          prot = 0;
> > >                      }
> > > -                    mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                    mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                  }
> > >              }
> > >          } else {
> > >              prot = 0;
> > > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> > >          }
> > >      }
> > >      /* Flush last range */
> > > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> > > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> > >  }
> > >
> > > -static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      unsigned int l1, l2, l3;
> > > @@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                      if (pde & PG_PSE_MASK) {
> > >                          prot = pde & (PG_USER_MASK | PG_RW_MASK |
> > >                                        PG_PRESENT_MASK);
> > > -                        mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                        mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                      } else {
> > >                          pt_addr = pde & 0x3fffffffff000ULL;
> > >                          for (l3 = 0; l3 < 512; l3++) {
> > > @@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                              } else {
> > >                                  prot = 0;
> > >                              }
> > > -                            mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                            mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                          }
> > >                      }
> > >                  } else {
> > >                      prot = 0;
> > > -                    mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                    mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                  }
> > >              }
> > >          } else {
> > >              prot = 0;
> > > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> > >          }
> > >      }
> > >      /* Flush last range */
> > > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> > > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
> > >  }
> > >
> > >
> > >  #ifdef TARGET_X86_64
> > > -static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      int prot, last_prot;
> > > @@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                          prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
> > >                                         PG_PRESENT_MASK);
> > >                          prot &= pml4e;
> > > -                        mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                        mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                      } else {
> > >                          pd_addr = pdpe & 0x3fffffffff000ULL;
> > >                          for (l3 = 0; l3 < 512; l3++) {
> > > @@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                                      prot = pde & (PG_USER_MASK | PG_RW_MASK |
> > >                                                    PG_PRESENT_MASK);
> > >                                      prot &= pml4e & pdpe;
> > > -                                    mem_print(mon, env, &start,
> > > +                                    mem_print(hmp, env, &start,
> > >                                                &last_prot, end, prot);
> > >                                  } else {
> > >                                      pt_addr = pde & 0x3fffffffff000ULL;
> > > @@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                                          } else {
> > >                                              prot = 0;
> > >                                          }
> > > -                                        mem_print(mon, env, &start,
> > > +                                        mem_print(hmp, env, &start,
> > >                                                    &last_prot, end, prot);
> > >                                      }
> > >                                  }
> > >                              } else {
> > >                                  prot = 0;
> > > -                                mem_print(mon, env, &start,
> > > +                                mem_print(hmp, env, &start,
> > >                                            &last_prot, end, prot);
> > >                              }
> > >                          }
> > >                      }
> > >                  } else {
> > >                      prot = 0;
> > > -                    mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                    mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                  }
> > >              }
> > >          } else {
> > >              prot = 0;
> > > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> > >          }
> > >      }
> > >      /* Flush last range */
> > > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
> > > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
> > >  }
> > >
> > > -static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > > +static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
> > >  {
> > >      const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
> > >      int prot, last_prot;
> > > @@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >          end = l0 << 48;
> > >          if (!(pml5e & PG_PRESENT_MASK)) {
> > >              prot = 0;
> > > -            mem_print(mon, env, &start, &last_prot, end, prot);
> > > +            mem_print(hmp, env, &start, &last_prot, end, prot);
> > >              continue;
> > >          }
> > >
> > > @@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >              end = (l0 << 48) + (l1 << 39);
> > >              if (!(pml4e & PG_PRESENT_MASK)) {
> > >                  prot = 0;
> > > -                mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                  continue;
> > >              }
> > >
> > > @@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                  end = (l0 << 48) + (l1 << 39) + (l2 << 30);
> > >                  if (pdpe & PG_PRESENT_MASK) {
> > >                      prot = 0;
> > > -                    mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                    mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                      continue;
> > >                  }
> > >
> > > @@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                      prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
> > >                              PG_PRESENT_MASK);
> > >                      prot &= pml5e & pml4e;
> > > -                    mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                    mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                      continue;
> > >                  }
> > >
> > > @@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                      end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
> > >                      if (pde & PG_PRESENT_MASK) {
> > >                          prot = 0;
> > > -                        mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                        mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                          continue;
> > >                      }
> > >
> > > @@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                          prot = pde & (PG_USER_MASK | PG_RW_MASK |
> > >                                  PG_PRESENT_MASK);
> > >                          prot &= pml5e & pml4e & pdpe;
> > > -                        mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                        mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                          continue;
> > >                      }
> > >
> > > @@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
> > >                          } else {
> > >                              prot = 0;
> > >                          }
> > > -                        mem_print(mon, env, &start, &last_prot, end, prot);
> > > +                        mem_print(hmp, env, &start, &last_prot, end, prot);
> > >                      }
> > >                  }
> > >              }
> > >          }
> > >      }
> > >      /* Flush last range */
> > > -    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
> > > +    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
> > >  }
> > >  #endif /* TARGET_X86_64 */
> > >
> > >  void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env;
> > >      AddressSpace *as;
> > >
> > >      env = monitor_hmp_get_cpu_env(hmp);
> > >      if (!env) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >
> > >      if (!(env->cr[0] & CR0_PG_MASK)) {
> > > -        monitor_printf(mon, "PG disabled\n");
> > > +        monitor_hmp_printf(hmp, "PG disabled\n");
> > >          return;
> > >      }
> > >      as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
> > > @@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
> > >  #ifdef TARGET_X86_64
> > >          if (env->hflags & HF_LMA_MASK) {
> > >              if (env->cr[4] & CR4_LA57_MASK) {
> > > -                mem_info_la57(mon, env, as);
> > > +                mem_info_la57(hmp, env, as);
> > >              } else {
> > > -                mem_info_la48(mon, env, as);
> > > +                mem_info_la48(hmp, env, as);
> > >              }
> > >          } else
> > >  #endif
> > >          {
> > > -            mem_info_pae32(mon, env, as);
> > > +            mem_info_pae32(hmp, env, as);
> > >          }
> > >      } else {
> > > -        mem_info_32(mon, env, as);
> > > +        mem_info_32(hmp, env, as);
> > >      }
> > >  }
> > >
> > > diff --git a/target/i386/sev.c b/target/i386/sev.c
> > > index 4473d02981ff..36a62e58be95 100644
> > > --- a/target/i386/sev.c
> > > +++ b/target/i386/sev.c
> > > @@ -756,33 +756,32 @@ SevInfo *qmp_query_sev(Error **errp)
> > >
> > >  void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      SevInfo *info = sev_get_info();
> > >
> > >      if (!info || !info->enabled) {
> > > -        monitor_printf(mon, "SEV is not enabled\n");
> > > +        monitor_hmp_printf(hmp, "SEV is not enabled\n");
> > >          goto out;
> > >      }
> > >
> > > -    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
> > > -    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
> > > -    monitor_printf(mon, "build: %d\n", info->build_id);
> > > -    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
> > > -                   info->api_minor);
> > > +    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->sev_type));
> > > +    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
> > > +    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
> > > +    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
> > > +                       info->api_minor);
> > >
> > >      if (sev_snp_enabled()) {
> > > -        monitor_printf(mon, "debug: %s\n",
> > > -                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
> > > -                                                                       : "off");
> > > -        monitor_printf(mon, "SMT allowed: %s\n",
> > > -                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
> > > -                                                                       : "off");
> > > +        monitor_hmp_printf(hmp, "debug: %s\n",
> > > +                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
> > > +                                                                           : "off");
> > > +        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
> > > +                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
> > > +                                                                           : "off");
> > >      } else {
> > > -        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
> > > -        monitor_printf(mon, "debug: %s\n",
> > > -                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
> > > -        monitor_printf(mon, "key-sharing: %s\n",
> > > -                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
> > > +        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
> > > +        monitor_hmp_printf(hmp, "debug: %s\n",
> > > +                           info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
> > > +        monitor_hmp_printf(hmp, "key-sharing: %s\n",
> > > +                           info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
> > >      }
> > >
> > >  out:
> > > diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
> > > index 5645a5d4d4f5..23c25283b27a 100644
> > > --- a/target/m68k/monitor.c
> > > +++ b/target/m68k/monitor.c
> > > @@ -12,11 +12,10 @@
> > >
> > >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
> > >
> > >      if (!env1) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >
> > > diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
> > > index 5769829bdd7e..6e8a075f5a41 100644
> > > --- a/target/ppc/monitor.c
> > > +++ b/target/ppc/monitor.c
> > > @@ -13,11 +13,10 @@
> > >
> > >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
> > >
> > >      if (!env1) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >      dump_mmu(env1);
> > > diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
> > > index 4c9c0c793b36..59cc04b3d0fb 100644
> > > --- a/target/riscv/monitor.c
> > > +++ b/target/riscv/monitor.c
> > > @@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, target_ulong addr)
> > >      return addr;
> > >  }
> > >
> > > -static void print_pte_header(Monitor *mon)
> > > +static void print_pte_header(MonitorHMP *hmp)
> > >  {
> > > -    monitor_printf(mon, PTE_HEADER_FIELDS);
> > > -    monitor_printf(mon, PTE_HEADER_DELIMITER);
> > > +    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
> > > +    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
> > >  }
> > >
> > > -static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
> > > +static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr,
> > >                        hwaddr paddr, target_ulong size, int attr)
> > >  {
> > >      /* sanity check on vaddr */
> > > @@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
> > >          return;
> > >      }
> > >
> > > -    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
> > > -                   " %c%c%c%c%c%c%c\n",
> > > -                   addr_canonical(va_bits, vaddr),
> > > -                   paddr, size,
> > > -                   attr & PTE_R ? 'r' : '-',
> > > -                   attr & PTE_W ? 'w' : '-',
> > > -                   attr & PTE_X ? 'x' : '-',
> > > -                   attr & PTE_U ? 'u' : '-',
> > > -                   attr & PTE_G ? 'g' : '-',
> > > -                   attr & PTE_A ? 'a' : '-',
> > > -                   attr & PTE_D ? 'd' : '-');
> > > +    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
> > > +                       " %c%c%c%c%c%c%c\n",
> > > +                       addr_canonical(va_bits, vaddr),
> > > +                       paddr, size,
> > > +                       attr & PTE_R ? 'r' : '-',
> > > +                       attr & PTE_W ? 'w' : '-',
> > > +                       attr & PTE_X ? 'x' : '-',
> > > +                       attr & PTE_U ? 'u' : '-',
> > > +                       attr & PTE_G ? 'g' : '-',
> > > +                       attr & PTE_A ? 'a' : '-',
> > > +                       attr & PTE_D ? 'd' : '-');
> > >  }
> > >
> > > -static void walk_pte(Monitor *mon, AddressSpace *as,
> > > +static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
> > >                       hwaddr base, target_ulong start,
> > >                       int level, int ptidxbits, int ptesize, int va_bits,
> > >                       target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
> > > @@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
> > >                  if ((*last_attr != attr) ||
> > >                      (*last_paddr + *last_size != paddr) ||
> > >                      (last_start + *last_size != start)) {
> > > -                    print_pte(mon, va_bits, *vbase, *pbase,
> > > +                    print_pte(hmp, va_bits, *vbase, *pbase,
> > >                                *last_paddr + *last_size - *pbase, *last_attr);
> > >
> > >                      *vbase = start;
> > > @@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
> > >                  *last_size = pgsize;
> > >              } else {
> > >                  /* pointer to the next level of the page table */
> > > -                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, ptesize,
> > > +                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, ptesize,
> > >                           va_bits, vbase, pbase, last_paddr,
> > >                           last_size, last_attr);
> > >              }
> > > @@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
> > >
> > >  }
> > >
> > > -static void mem_info_svxx(Monitor *mon, CPUArchState *env)
> > > +static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
> > >  {
> > >      AddressSpace *as = env_cpu(env)->as;
> > >      int levels, ptidxbits, ptesize, vm, va_bits;
> > > @@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
> > >      va_bits = PGSHIFT + levels * ptidxbits;
> > >
> > >      /* print header */
> > > -    print_pte_header(mon);
> > > +    print_pte_header(hmp);
> > >
> > >      vbase = -1;
> > >      pbase = -1;
> > > @@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
> > >      last_attr = 0;
> > >
> > >      /* walk page tables, starting from address 0 */
> > > -    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
> > > +    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
> > >               &vbase, &pbase, &last_paddr, &last_size, &last_attr);
> > >
> > >      /* don't forget the last one */
> > > -    print_pte(mon, va_bits, vbase, pbase,
> > > +    print_pte(hmp, va_bits, vbase, pbase,
> > >                last_paddr + last_size - pbase, last_attr);
> > >  }
> > >
> > >  void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env;
> > >
> > >      env = monitor_hmp_get_cpu_env(hmp);
> > >      if (!env) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >
> > >      if (!riscv_cpu_cfg(env)->mmu) {
> > > -        monitor_printf(mon, "S-mode MMU unavailable\n");
> > > +        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
> > >          return;
> > >      }
> > >
> > >      if (riscv_cpu_mxl(env) == MXL_RV32) {
> > >          if (!(env->satp & SATP32_MODE)) {
> > > -            monitor_printf(mon, "No translation or protection\n");
> > > +            monitor_hmp_printf(hmp, "No translation or protection\n");
> > >              return;
> > >          }
> > >      } else {
> > >          if (!(env->satp & SATP64_MODE)) {
> > > -            monitor_printf(mon, "No translation or protection\n");
> > > +            monitor_hmp_printf(hmp, "No translation or protection\n");
> > >              return;
> > >          }
> > >      }
> > >
> > > -    mem_info_svxx(mon, env);
> > > +    mem_info_svxx(hmp, env);
> > >  }
> > >
> > >  #ifdef CONFIG_TCG
> > > diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
> > > index 4e443152bf56..62998a9a57cb 100644
> > > --- a/target/sh4/monitor.c
> > > +++ b/target/sh4/monitor.c
> > > @@ -26,33 +26,32 @@
> > >  #include "monitor/monitor.h"
> > >  #include "monitor/hmp.h"
> > >
> > > -static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
> > > +static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
> > >  {
> > > -    monitor_printf(mon, " tlb%i:\t"
> > > -                   "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
> > > -                   "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
> > > -                   "dirty=%hhu writethrough=%hhu\n",
> > > -                   idx,
> > > -                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
> > > -                   tlb->v, tlb->sh, tlb->c, tlb->pr,
> > > -                   tlb->d, tlb->wt);
> > > +    monitor_hmp_printf(hmp, " tlb%i:\t"
> > > +                       "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
> > > +                       "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
> > > +                       "dirty=%hhu writethrough=%hhu\n",
> > > +                       idx,
> > > +                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
> > > +                       tlb->v, tlb->sh, tlb->c, tlb->pr,
> > > +                       tlb->d, tlb->wt);
> > >  }
> > >
> > >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env = monitor_hmp_get_cpu_env(hmp);
> > >      int i;
> > >
> > >      if (!env) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >
> > > -    monitor_printf (mon, "ITLB:\n");
> > > +    monitor_hmp_printf(hmp, "ITLB:\n");
> > >      for (i = 0 ; i < ITLB_SIZE ; i++)
> > > -        print_tlb (mon, i, &env->itlb[i]);
> > > -    monitor_printf (mon, "UTLB:\n");
> > > +        print_tlb(hmp, i, &env->itlb[i]);
> > > +    monitor_hmp_printf(hmp, "UTLB:\n");
> > >      for (i = 0 ; i < UTLB_SIZE ; i++)
> > > -        print_tlb (mon, i, &env->utlb[i]);
> > > +        print_tlb(hmp, i, &env->utlb[i]);
> > >  }
> > > diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
> > > index e826e584a918..36f109cbb568 100644
> > > --- a/target/sparc/monitor.c
> > > +++ b/target/sparc/monitor.c
> > > @@ -29,11 +29,10 @@
> > >
> > >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
> > >
> > >      if (!env1) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >      dump_mmu(env1);
> > > diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
> > > index b7b7387706f3..b9c4089b0fb1 100644
> > > --- a/target/xtensa/monitor.c
> > > +++ b/target/xtensa/monitor.c
> > > @@ -28,11 +28,10 @@
> > >
> > >  void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
> > >
> > >      if (!env1) {
> > > -        monitor_printf(mon, "No CPU available\n");
> > > +        monitor_hmp_printf(hmp, "No CPU available\n");
> > >          return;
> > >      }
> > >      dump_mmu(env1);
> > > diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
> > > index b2a884529598..530a3fee3c13 100644
> > > --- a/tests/unit/test-util-sockets.c
> > > +++ b/tests/unit/test-util-sockets.c
> > > @@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
> > >   */
> > >  Monitor *monitor_cur(void) { return cur_mon; }
> > >  Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
> > > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort(); }
> > > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) { abort(); }
> > >
> > >  #ifndef _WIN32
> > >  static void test_socket_fd_pass_name_good(void)
> > > diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
> > > index f62b2f294952..81a09ec5adfa 100644
> > > --- a/tools/qemu-vnc/clipboard.c
> > > +++ b/tools/qemu-vnc/clipboard.c
> > > @@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboardRequest *req)
> > >          "Cancelled clipboard request");
> > >
> > >      g_clear_object(&req->invocation);
> > > -    g_clear_handle_id(&req->timeout_id, g_source_remove);;
> > > +    g_clear_handle_id(&req->timeout_id, g_source_remove);
> > >  }
> > >
> > >  static gboolean
> > > @@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *info)
> > >          vnc_dbus_clipboard_complete_request(
> > >              req->invocation, info, req->type);
> > >          g_clear_object(&req->invocation);
> > > -        g_clear_handle_id(&req->timeout_id, g_source_remove);;
> > > +        g_clear_handle_id(&req->timeout_id, g_source_remove);
> > >          return;
> > >      }
> > >
> > > diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
> > > index 26597fefaa99..0aa50a901d37 100644
> > > --- a/tools/qemu-vnc/stubs.c
> > > +++ b/tools/qemu-vnc/stubs.c
> > > @@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
> > >      return NULL;
> > >  }
> > >
> > > -int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
> > > +int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
> > >  {
> > >      return -1;
> > >  }
> > > diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
> > > index 5a8158f4f4b6..a68f5b900d7c 100644
> > > --- a/trace/trace-hmp-cmds.c
> > > +++ b/trace/trace-hmp-cmds.c
> > > @@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qdict)
> > >  #ifdef CONFIG_TRACE_SIMPLE
> > >  void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *op = qdict_get_try_str(qdict, "op");
> > >      const char *arg = qdict_get_try_str(qdict, "arg");
> > >
> > > @@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
> > >              st_set_trace_file(arg);
> > >          }
> > >      } else {
> > > -        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
> > > -        hmp_help_cmd(mon, "trace-file");
> > > +        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
> > > +        hmp_help_cmd(hmp, "trace-file");
> > >      }
> > >  }
> > >  #endif
> > >
> > >  void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *name = qdict_get_try_str(qdict, "name");
> > >      TraceEventInfoList *events;
> > >      TraceEventInfoList *elem;
> > > @@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
> > >      }
> > >
> > >      for (elem = events; elem != NULL; elem = elem->next) {
> > > -        monitor_printf(mon, "%s : state %u\n",
> > > -                       elem->value->name,
> > > -                       elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
> > > +        monitor_hmp_printf(hmp, "%s : state %u\n",
> > > +                           elem->value->name,
> > > +                           elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
> > >      }
> > >      qapi_free_TraceEventInfoList(events);
> > >  }
> > > diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
> > > index 186209fd0234..f611dd7ee457 100644
> > > --- a/ui/ui-hmp-cmds.c
> > > +++ b/ui/ui-hmp-cmds.c
> > > @@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      MouseInfoList *mice_list, *mouse;
> > >
> > >      mice_list = qmp_query_mice(NULL);
> > >      if (!mice_list) {
> > > -        monitor_printf(mon, "No mouse devices connected\n");
> > > +        monitor_hmp_printf(hmp, "No mouse devices connected\n");
> > >          return;
> > >      }
> > >
> > >      for (mouse = mice_list; mouse; mouse = mouse->next) {
> > > -        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
> > > -                       mouse->value->current ? '*' : ' ',
> > > -                       mouse->value->index, mouse->value->name,
> > > -                       mouse->value->absolute ? " (absolute)" : "");
> > > +        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
> > > +                           mouse->value->current ? '*' : ' ',
> > > +                           mouse->value->index, mouse->value->name,
> > > +                           mouse->value->absolute ? " (absolute)" : "");
> > >      }
> > >
> > >      qapi_free_MouseInfoList(mice_list);
> > > @@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
> > >
> > >  #ifdef CONFIG_VNC
> > >  /* Helper for hmp_info_vnc_clients, _servers */
> > > -static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
> > > +static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
> > >                                    const char *name)
> > >  {
> > > -    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
> > > -                   name,
> > > -                   info->host,
> > > -                   info->service,
> > > -                   NetworkAddressFamily_str(info->family),
> > > -                   info->websocket ? " (Websocket)" : "");
> > > +    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
> > > +                       name,
> > > +                       info->host,
> > > +                       info->service,
> > > +                       NetworkAddressFamily_str(info->family),
> > > +                       info->websocket ? " (Websocket)" : "");
> > >  }
> > >
> > >  /* Helper displaying and auth and crypt info */
> > > -static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
> > > +static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent,
> > >                                     VncPrimaryAuth auth,
> > >                                     VncVencryptSubAuth *vencrypt)
> > >  {
> > > -    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
> > > -                   VncPrimaryAuth_str(auth),
> > > -                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
> > > +    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
> > > +                       VncPrimaryAuth_str(auth),
> > > +                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
> > >  }
> > >
> > > -static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *client)
> > > +static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *client)
> > >  {
> > >      while (client) {
> > >          VncClientInfo *cinfo = client->value;
> > >
> > > -        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Client");
> > > -        monitor_printf(mon, "    x509_dname: %s\n",
> > > -                       cinfo->x509_dname ?: "none");
> > > -        monitor_printf(mon, "    sasl_username: %s\n",
> > > -                       cinfo->sasl_username ?: "none");
> > > +        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Client");
> > > +        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
> > > +                           cinfo->x509_dname ?: "none");
> > > +        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
> > > +                           cinfo->sasl_username ?: "none");
> > >
> > >          client = client->next;
> > >      }
> > >  }
> > >
> > > -static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
> > > +static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *server)
> > >  {
> > >      while (server) {
> > >          VncServerInfo2 *sinfo = server->value;
> > > -        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "Server");
> > > -        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
> > > +        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "Server");
> > > +        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
> > >                                 sinfo->has_vencrypt ? &sinfo->vencrypt : NULL);
> > >          server = server->next;
> > >      }
> > > @@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
> > >
> > >  void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      VncInfo2List *info2l, *info2l_head;
> > >      Error *err = NULL;
> > >
> > > @@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
> > >          return;
> > >      }
> > >      if (!info2l) {
> > > -        monitor_printf(mon, "None\n");
> > > +        monitor_hmp_printf(hmp, "None\n");
> > >          return;
> > >      }
> > >
> > >      while (info2l) {
> > >          VncInfo2 *info = info2l->value;
> > > -        monitor_printf(mon, "%s:\n", info->id);
> > > -        hmp_info_vnc_servers(mon, info->server);
> > > -        hmp_info_vnc_clients(mon, info->clients);
> > > +        monitor_hmp_printf(hmp, "%s:\n", info->id);
> > > +        hmp_info_vnc_servers(hmp, info->server);
> > > +        hmp_info_vnc_clients(hmp, info->clients);
> > >          if (!info->server) {
> > >              /*
> > >               * The server entry displays its auth, we only need to
> > >               * display in the case of 'reverse' connections where
> > >               * there's no server.
> > >               */
> > > -            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
> > > +            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
> > >                                 info->has_vencrypt ? &info->vencrypt : NULL);
> > >          }
> > >          if (info->display) {
> > > -            monitor_printf(mon, "  Display: %s\n", info->display);
> > > +            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
> > >          }
> > >          info2l = info2l->next;
> > >      }
> > > @@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
> > >  #ifdef CONFIG_SPICE
> > >  void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      SpiceChannelList *chan;
> > >      SpiceInfo *info;
> > >      const char *channel_name;
> > > @@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
> > >      info = qmp_query_spice(NULL);
> > >
> > >      if (!info->enabled) {
> > > -        monitor_printf(mon, "Server: disabled\n");
> > > +        monitor_hmp_printf(hmp, "Server: disabled\n");
> > >          goto out;
> > >      }
> > >
> > > -    monitor_printf(mon, "Server:\n");
> > > +    monitor_hmp_printf(hmp, "Server:\n");
> > >      if (info->has_port) {
> > > -        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
> > > -                       info->host, info->port);
> > > +        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
> > > +                           info->host, info->port);
> > >      }
> > >      if (info->has_tls_port) {
> > > -        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
> > > -                       info->host, info->tls_port);
> > > +        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n",
> > > +                           info->host, info->tls_port);
> > >      }
> > > -    monitor_printf(mon, "    migrated: %s\n",
> > > -                   info->migrated ? "true" : "false");
> > > -    monitor_printf(mon, "        auth: %s\n", info->auth);
> > > -    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
> > > -    monitor_printf(mon, "  mouse-mode: %s\n",
> > > -                   SpiceQueryMouseMode_str(info->mouse_mode));
> > > +    monitor_hmp_printf(hmp, "    migrated: %s\n",
> > > +                       info->migrated ? "true" : "false");
> > > +    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
> > > +    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_version);
> > > +    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
> > > +                       SpiceQueryMouseMode_str(info->mouse_mode));
> > >
> > >      if (!info->has_channels || info->channels == NULL) {
> > > -        monitor_printf(mon, "Channels: none\n");
> > > +        monitor_hmp_printf(hmp, "Channels: none\n");
> > >      } else {
> > >          for (chan = info->channels; chan; chan = chan->next) {
> > > -            monitor_printf(mon, "Channel:\n");
> > > -            monitor_printf(mon, "     address: %s:%s%s\n",
> > > -                           chan->value->host, chan->value->port,
> > > -                           chan->value->tls ? " [tls]" : "");
> > > -            monitor_printf(mon, "     session: %" PRId64 "\n",
> > > -                           chan->value->connection_id);
> > > -            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "\n",
> > > -                           chan->value->channel_type, chan->value->channel_id);
> > > +            monitor_hmp_printf(hmp, "Channel:\n");
> > > +            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
> > > +                               chan->value->host, chan->value->port,
> > > +                               chan->value->tls ? " [tls]" : "");
> > > +            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
> > > +                               chan->value->connection_id);
> > > +            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId64 "\n",
> > > +                               chan->value->channel_type, chan->value->channel_id);
> > >
> > >              channel_name = "unknown";
> > >              if (chan->value->channel_type > 0 &&
> > > @@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
> > >                  channel_name = channel_names[chan->value->channel_type];
> > >              }
> > >
> > > -            monitor_printf(mon, "     channel name: %s\n", channel_name);
> > > +            monitor_hmp_printf(hmp, "     channel name: %s\n", channel_name);
> > >          }
> > >      }
> > >
> > > @@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
> > >      monitor_hmp_read_command(opaque, 1);
> > >  }
> > >
> > > -void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
> > > +void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
> > >                      const char *arg, const char *read_only, bool force,
> > >                      Error **errp)
> > >  {
> > > @@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
> > >          return;
> > >      }
> > >      if (!arg) {
> > > -        MonitorHMP *hmp = MONITOR_HMP(mon);
> > >          monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
> > >      } else {
> > >          qmp_change_vnc_password(arg, errp);
> > > @@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t key_length)
> > >
> > >  void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
> > >  {
> > > -    Monitor *mon = MONITOR(hmp);
> > >      const char *keys = qdict_get_str(qdict, "keys");
> > >      KeyValue *v = NULL;
> > >      KeyValueList *head = NULL, **tail = &head;
> > > @@ -432,7 +427,7 @@ out:
> > >      return;
> > >
> > >  err_out:
> > > -    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
> > > +    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, keys);
> > >      goto out;
> > >  }
> > >
> > > diff --git a/util/error-report.c b/util/error-report.c
> > > index 70cbd174ffae..c20e157780fa 100644
> > > --- a/util/error-report.c
> > > +++ b/util/error-report.c
> > > @@ -38,7 +38,7 @@ error_vprintf_mon(const char *fmt, va_list ap)
> > >      MonitorHMP *hmp = monitor_cur_hmp();
> > >
> > >      if (hmp) {
> > > -        return monitor_vprintf(MONITOR(hmp), fmt, ap);
> > > +        return monitor_hmp_vprintf(hmp, fmt, ap);
> > >      }
> > >
> > >      return vfprintf(stderr, fmt, ap);
> > > diff --git a/util/qemu-print.c b/util/qemu-print.c
> > > index 0eecc05b0330..aabe670fda01 100644
> > > --- a/util/qemu-print.c
> > > +++ b/util/qemu-print.c
> > > @@ -23,7 +23,7 @@ int qemu_vprintf(const char *fmt, va_list ap)
> > >  {
> > >      MonitorHMP *hmp = monitor_cur_hmp();
> > >      if (hmp) {
> > > -        return monitor_vprintf(MONITOR(hmp), fmt, ap);
> > > +        return monitor_hmp_vprintf(hmp, fmt, ap);
> > >      }
> > >      return vprintf(fmt, ap);
> > >  }
> > > @@ -54,7 +54,7 @@ int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
> > >  {
> > >      if (!stream) {
> > >          MonitorHMP *hmp = monitor_cur_hmp();
> > > -        return hmp ? monitor_vprintf(MONITOR(hmp), fmt, ap) : -1;
> > > +        return hmp ? monitor_hmp_vprintf(hmp, fmt, ap) : -1;
> > >      }
> > >      return vfprintf(stream, fmt, ap);
> > >  }
> > >
> > > --
> > > 2.55.0.543.g5ebe2ebe4ea8
> > >
> > --
> >  -----Open up your eyes, open up your mind, open up your code -------
> > / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> > \        dave @ treblig.org |                               | In Hex /
> >  \ _________________________|_____ http://www.treblig.org   |_______/
> >
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/


From xen-devel-bounces@lists.xenproject.org Sat Aug 22 18:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 18:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398248.1634699 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWr-0006Ow-6l; Sat, 22 Aug 2026 18:33:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398248.1634699; Sat, 22 Aug 2026 18:33:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWr-0006Ol-3L; Sat, 22 Aug 2026 18:33:17 +0000
Received: by outflank-mailman (input) for mailman id 1398248;
 Sat, 22 Aug 2026 18:33:15 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mfo@igalia.com>) id 1wxqWp-0006O9-OM
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 18:33:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxqWp-006G9Z-5I
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 20:33:15 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb5f-bab6-0a2a0a5309dd-0a2a450ce090-8
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:15 +0200
Received: from [213.97.179.56] (helo=fanzine2.igalia.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb6a-f479-0a2a450c0019-d561b338cafe-3
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:15 +0200
Received: from 186-249-148-4.shared.desktop.com.br ([186.249.148.4]
 helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa 
 (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1wxqWg-007bWT-2k; Sat, 22 Aug 2026 20:33:06 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:
	MIME-Version:Subject:Date:From:From:Reply-To;
	bh=KORz1Q6LN2S1qss23Rp2FxzHVmjdGy5eAsOyJ8LP8DE=; b=eWq9lcDUFjq4cazwokKPFifDbT
	10Qazbh7iMb0SIeZZDywA9Z1h60qVk/3mVGCzACps0digm7EUwGtjA0aHvzQiPXETbzZCCmtr0xYL
	r1MAPHj4L+UIQ7YEBxTQjww8uFjqaLZoqRi/vYBTHnRqM8oyCHsBHCWOwAUzN3EX/NyQzjAmvHfBL
	kmS8lgeXag4ewv8uLXYmd7f3QB6k484nBy9bGeXRZg6Efy8PRY8i8KdeSIvf51Pqyh21DvzHm+QUb
	xEqNRsvJdmM5BL+xvw8bHVhDN2VpedmJ25G1C2ejk94gFIW1iJpacz1YLYRXUtt9i+3A099GIk+eC
	a0Dhcd3A==;
From: Mauricio Faria de Oliveira <mfo@igalia.com>
Date: Sat, 22 Aug 2026 15:33:19 -0300
Subject: [PATCH v9 3/5] x86/asm: group inline string functions
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260822-pvh-kasan-inline-v9-3-e70ef3b75b6a@igalia.com>
References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
In-Reply-To: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, 
 Juergen Gross <jgross@suse.com>, Alexey Dobriyan <adobriyan@gmail.com>, 
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
 Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, 
 xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira <mfo@igalia.com>
X-Mailer: b4 0.14.2
X-purgate-ID: tlsNG-d25034/1787423595-012C8A5B-00D7687C/0/0
X-purgate-type: clean
X-purgate-size: 2271

Group the __inline string functions in the same header.

Use <asm/shared/string.h> since __inline_memcmp() must remain there for use
by arch/x86/boot/string.c.

No functional changes.

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
---
 arch/x86/include/asm/shared/string.h | 21 +++++++++++++++++++++
 arch/x86/include/asm/string.h        | 21 +--------------------
 2 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h
index 06c1d5e5013e4d59cfb49866d10e164362d2c4cc..ab033d27c581e44ba3f5a494ca29e31776be51f2 100644
--- a/arch/x86/include/asm/shared/string.h
+++ b/arch/x86/include/asm/shared/string.h
@@ -2,6 +2,27 @@
 #ifndef _ASM_X86_SHARED_STRING_H
 #define _ASM_X86_SHARED_STRING_H
 
+static __always_inline void *__inline_memcpy(void *to, const void *from, size_t len)
+{
+	void *ret = to;
+
+	asm volatile("rep movsb"
+		     : "+D" (to), "+S" (from), "+c" (len)
+		     : : "memory");
+	return ret;
+}
+
+static __always_inline void *__inline_memset(void *s, int v, size_t n)
+{
+	void *ret = s;
+
+	asm volatile("rep stosb"
+		     : "+D" (s), "+c" (n)
+		     : "a" ((uint8_t)v)
+		     : "memory");
+	return ret;
+}
+
 /*
  * This inline memcmp() returns 0 (equal) or 1 (not equal).
  * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than)
diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 9cb5aae7fba9ffcf0f5af8f939d30467750ccaa9..dbf59f0d4cca71e2ddce0d8764aeec8782236669 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -8,25 +8,6 @@
 # include <asm/string_64.h>
 #endif
 
-static __always_inline void *__inline_memcpy(void *to, const void *from, size_t len)
-{
-	void *ret = to;
-
-	asm volatile("rep movsb"
-		     : "+D" (to), "+S" (from), "+c" (len)
-		     : : "memory");
-	return ret;
-}
-
-static __always_inline void *__inline_memset(void *s, int v, size_t n)
-{
-	void *ret = s;
-
-	asm volatile("rep stosb"
-		     : "+D" (s), "+c" (n)
-		     : "a" ((uint8_t)v)
-		     : "memory");
-	return ret;
-}
+#include <asm/shared/string.h>
 
 #endif /* _ASM_X86_STRING_H */

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sat Aug 22 18:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 18:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398245.1634673 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWm-0005mf-Gn; Sat, 22 Aug 2026 18:33:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398245.1634673; Sat, 22 Aug 2026 18:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWm-0005mW-D1; Sat, 22 Aug 2026 18:33:12 +0000
Received: by outflank-mailman (input) for mailman id 1398245;
 Sat, 22 Aug 2026 18:33:11 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mfo@igalia.com>) id 1wxqWl-0005mF-IF
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 18:33:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxqWk-00A7NX-An
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 20:33:10 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb36-e002-0a2a0a5209dd-0a2a4505d466-26
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:09 +0200
Received: from [213.97.179.56] (helo=fanzine2.igalia.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb65-4cb1-0a2a45050019-d561b338b6d6-3
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:09 +0200
Received: from 186-249-148-4.shared.desktop.com.br ([186.249.148.4]
 helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa 
 (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1wxqWY-007bWT-8S; Sat, 22 Aug 2026 20:32:58 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:
	MIME-Version:Subject:Date:From:From:Reply-To;
	bh=n2eXcmcuOEY5+UkfCm5BTRwUz6gPnjMX1HXpAy+v/E8=; b=cP6yEYns8j2dRwJXrWoFYQ5BVR
	qfq6ToaLjISpVJANbLI3P1DvSluu2WkFJEVIqY4tE2Z7T9SwN1Jdw+eF0y1CxZ7RmG92O2tAcRVkv
	LjqxzDHDLDiX7wDdGalIqKDBD+LU6DXJEezoQ06jxmkGwWW/1jdUEHTdES/+mh1beEwdMW3c3i8Ds
	VPHlyVJd8FnmCKFLJaEuusG1OuniSIPpRQmnWuyT9gp9r16spbqif03L9VUxfuKJBW+GaPwopDlHF
	GXkGqQWsMf8e6DlaWBbu6z1gw/Ypw830A2mbdmFKoQlrvC24qcuV3zeLzYdBYueKWItwzWNzzvZ3n
	e5tBH3ow==;
From: Mauricio Faria de Oliveira <mfo@igalia.com>
Date: Sat, 22 Aug 2026 15:33:17 -0300
Subject: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com>
References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
In-Reply-To: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, 
 Juergen Gross <jgross@suse.com>, Alexey Dobriyan <adobriyan@gmail.com>, 
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
 Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, 
 xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira <mfo@igalia.com>
X-Mailer: b4 0.14.2
X-purgate-ID: tlsNG-c201ff/1787423589-2491C2A1-02535D52/0/0
X-purgate-type: clean
X-purgate-size: 1843

According to the GCC documentation, conditions in the flags register
(e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].

Also, clobbers (e.g., "cc") may not overlap with an output operand [2].

Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
"=@ccnz" output operand.

    """
    6.11.2.4 Flag Output Operands

        On some targets, a special form of output operand exists by which
        conditions in the flags register may be outputs of the asm. [...]

    6.11.2.6 Clobbers and Scratch Registers

        While the compiler is aware of changes to entries listed in the
        output operands, [...]

        Clobber descriptions may not in any way overlap with an input or
        output operand. [...]
    """

Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/
Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()")
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1]
Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2]
---
 arch/x86/boot/string.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 1632d40e1f545ae0665597069b568ea6b6c263e5..03278b4393887cb71cb063818d3378c4f52b06f8 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len)
 	asm volatile("test %3, %3\n\t"
 		     "repe cmpsb"
 		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
-		     : : "cc", "memory");
+		     : : "memory");
 	return diff;
 }
 

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sat Aug 22 18:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 18:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398246.1634682 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWn-0005z3-NE; Sat, 22 Aug 2026 18:33:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398246.1634682; Sat, 22 Aug 2026 18:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWn-0005yw-KL; Sat, 22 Aug 2026 18:33:13 +0000
Received: by outflank-mailman (input) for mailman id 1398246;
 Sat, 22 Aug 2026 18:33:12 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mfo@igalia.com>) id 1wxqWl-0005mG-Pw
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 18:33:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxqWk-006G9Z-MI
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 20:33:10 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb5f-bab6-0a2a0a5309dd-0a2a450ce090-6
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:09 +0200
Received: from [213.97.179.56] (helo=fanzine2.igalia.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb64-f479-0a2a450c0019-d561b338c2f6-3
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:09 +0200
Received: from 186-249-148-4.shared.desktop.com.br ([186.249.148.4]
 helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa 
 (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1wxqWU-007bWT-BY; Sat, 22 Aug 2026 20:32:54 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:
	Message-Id:Date:Subject:From:From:Reply-To;
	bh=+CpOtGeYoMEyuqqLY9qyKy2e9TMQp/hYdp8ZVK/CpDo=; b=YHOASPNYg9lrnpVvQAHX5d1NRV
	LpkBkplQp+cuTcTHQl7BcKxNQSOEmu5QXVqid0MkDK2Ig1uJL82x5wzOuS9uWbi+903TATPAGa9HT
	lEgIqZc1Ys0nBcw5FTUVnvyceI94jKi4aTt5zZe6qk7Fa8mO2771uY+fjKlug0+g17wEhg4klzqHw
	AP+WbBuapasPyPNJ+2GwQgSd+SplKsESoSalmpRtXpqUn5xl6YdZ97Po89TLGTjDfGRHCrdMn1MqM
	pMK8UsSKxEsR7jG6R9qJfmGRprm+xgO8V0+B/d6WCuXnjs/mdSERoQb0cHOZX55QWKSdVcq68IRhI
	/qcdHfQw==;
From: Mauricio Faria de Oliveira <mfo@igalia.com>
Subject: [PATCH v9 0/5] x86/pvh: fix unbootable VMs again (PVH + KASAN)
Date: Sat, 22 Aug 2026 15:33:16 -0300
Message-Id: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-B4-Tracking: v=1; b=H4sIAGzriWoC/33RwU7DMAwG4FeZciYocRKn4cR7IA6u62wRo5taV
 IGmvTvZLitqxPG35M+2fFGzTEVm9bK7qEmWMpfTWEN62ik+0LgXXYaaFRhA4wH0eTnoD5pp1GU
 8llE0SiaOMdseoqpt50ly+b6Tb+81H8r8dZp+7hMWe6v+gy1WGx0FbfLOe07wWvZ0LPTMp0910
 xZYC7EhQBWAQ+y7gXNG2gjuIQQwDcFVoZdBIiZG4bgR/FrAhuCrQM4aQYIgPGyE8BDQtXYIVQh
 AmVNMvXR2I+BDiMY2BLxdQSkZH4ZMKW+EuBKgJcQquK4uQMGwZLMRurXgGkJXBbYZgW3AHP5+8
 3q9/gIv2tP6fwIAAA==
X-Change-ID: 20260422-pvh-kasan-inline-6efac77f1b27
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, 
 Juergen Gross <jgross@suse.com>, Alexey Dobriyan <adobriyan@gmail.com>, 
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
 Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, 
 xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira <mfo@igalia.com>
X-Mailer: b4 0.14.2
X-purgate-ID: tlsNG-d25034/1787423589-022C0A5B-9DA478F2/0/0
X-purgate-type: clean
X-purgate-size: 8170

The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back.

Booting directly from vmlinux (instead of bzImage) now fails with gcc-14/15
(but works with gcc-12/13) if CONFIG_KASAN_GENERIC is set, on Ubuntu 25.10.

The PVH code is required/supposed not to use the KASAN memory access check
in the kernel entry point as KASAN has not yet been setup, or an exception
is hit and the boot fails.

This was previously described and addressed with __builtin_mem{cmp,set}():
- commit 661362e3dcab ("xen, pvh: fix unbootable VMs (PVH + KASAN - AMD_MEM_ENCRYPT)")
- commit 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()")
- commit fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()")

However, even with __builtin the compiler may decide to use the out of line
function instead of the inline implementation. So, that does not really fix
the issue unconditionally; see details below.

In order to address this, it's required to switch to inline implementations
that do not depend on the compiler.

There's such a memset() in <asm/string.h> and memcmp() in 'boot/string.c'.
Use them instead of builtins in PVH entry.

Testing:

- Booting from vmlinux (fixed) and bzImage (still works) using
  allnoconfig + CONFIG_PVH + CONFIG_KASAN with gcc-12/13/14/15.

- Building with CONFIG_KEXEC_FILE, CONFIG_CFI and !CONFIG_KASAN with LLVM 20
  (check for a build error not caught previously).

Details/Debugging:

- Only CONFIG_PVH (works):

  make allnoconfig
  ./scripts/config \
    -e 64BIT -e HYPERVISOR_GUEST -e PVH \
    -e SERIAL_8250 -e SERIAL_8250_CONSOLE
  make olddefconfig
  make -j$(nproc) vmlinux

  qemu-system-x86_64 \
    -accel kvm -nodefaults -nographic -serial stdio \
    -kernel vmlinux -append 'console=ttyS0'
  ...
  SeaBIOS (version ...)
  Booting from ROM...
  Linux version ...
  ...
  <Ctrl-C>

- With CONFIG_KASAN (fails)

  ./scripts/config -e KASAN
  make olddefconfig
  make -j$(nproc) vmlinux

  qemu-system-x86_64 \
    -accel kvm -nodefaults -nographic -serial stdio \
    -kernel vmlinux -append 'console=ttyS0'
  ...
  SeaBIOS (version ...)
  Booting from ROM...
  <QEMU reboot loop, flashing the text above>

- Debugging:

  Enable debug info and rebuild.

  QEMU: enable and wait for GDB, stop rebooting, remain running.

  qemu-system-x86_64 \
    -s -S -no-reboot -no-shutdown \
    <other options>

  gdb vmlinux
  (gdb) target remote localhost:1234
  ...
  (gdb) c
  ...
  Thread 2 received signal SIGQUIT, Quit.
  ...
  (gdb) info threads
    Id   Target Id                    Frame
    1    Thread 1.1 (CPU#0 [running]) bytes_is_nonzero (
      start=0xfffffbfff031eebe <error: Cannot access memory at address 0xfffffbfff031eebe>, size=1)
      at .../linux/mm/kasan/generic.c:98
  * 2    Thread 1.2 (CPU#1 [halted ]) 0x00000000000fd0a9 in ?? ()
  ...
  (gdb) thr 1
  ...
  (gdb) bt
  #0  bytes_is_nonzero (start=0xfffffbfff031eebe <error: Cannot access memory at address 0xfffffbfff031eebe>, size=1)
      at .../linux/mm/kasan/generic.c:98
  #1  memory_is_nonzero (start=0xfffffbfff031eebe, end=0xfffffbfff031eebf) at .../linux/mm/kasan/generic.c:115
  #2  memory_is_poisoned_n (addr=0xffffffff818f75f0, size=8) at .../linux/mm/kasan/generic.c:140
  #3  memory_is_poisoned (addr=0xffffffff818f75f0, size=8) at .../linux/mm/kasan/generic.c:172
  #4  check_region_inline (addr=0xffffffff818f75f0, size=8, write=false, ret_ip=18446744071585002062)
      at .../linux/mm/kasan/generic.c:191
  #5  kasan_check_range (addr=addr@entry=0xffffffff818f75f0, size=size@entry=8, write=write@entry=false,
      ret_ip=18446744071585002062) at .../linux/mm/kasan/generic.c:200
  #6  0xffffffff813eb283 in __asan_loadN (addr=addr@entry=0xffffffff818f75f0, size=size@entry=8)
      at .../linux/mm/kasan/generic.c:278
  #7  0xffffffff815df24e in memcmp (cs=cs@entry=0xffffffff818f75f0, ct=ct@entry=0x1be2fe4, count=<optimized out>,
      count@entry=12) at .../linux/lib/string.c:683
  #8  0xffffffff81ba2323 in cpuid_base_hypervisor (sig=0xffffffff818f75f0 "XenVMMXenVMM", leaves=2)
      at .../linux/arch/x86/include/asm/cpuid/api.h:206
  #9  xen_cpuid_base () at .../linux/arch/x86/include/asm/xen/hypervisor.h:46
  #10 xen_prepare_pvh () at .../linux/arch/x86/platform/pvh/enlighten.c:119
  #11 0x0000000001ba2588 in ?? ()
  #12 0x0000000000000000 in ?? ()
  (gdb)

  Frames #7-#8 show the non-builtin memcmp() (lib/string.c) was called
  even with __builtin_memcmp() being used in cpuid_base_hypervisor().

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
---
Changes in v9:
- Patch 1: new patch in v9 to fix the patch submitted separately in v8.
- Rebased to next-20260821.
- Link to v8: https://lore.kernel.org/r/20260723-pvh-kasan-inline-v8-0-c1f62c156f52@igalia.com

Changes in v8:
- Patch 2 in v7 was submitted separately as requested, and the
  rest of this series was rebased on top of it (Borislav Petkov).
  Link: https://lore.kernel.org/all/20260723-x86-memcmp-asm-v2-1-d93ecb43797f@igalia.com/
- Patch 2 in v8:
  - Mention 'No functional changes' (Borislav Petkov).
  - Remove comment at the top of the header (Borislav Petkov).
- Link to v7: https://lore.kernel.org/r/20260721-pvh-kasan-inline-v7-0-38979a50cef0@igalia.com

Changes in v7:
- Patch 2 (added):
  - Address pre-existing issues in 'asm' (Borislav Petkov, Sashiko).
- Link to v6: https://lore.kernel.org/r/20260701-pvh-kasan-inline-v6-0-ba99045dfa9f@igalia.com

Changes in v6:
- Patch 1:
  - Explain the return value difference between __inline_memcmp() and memcmp().
- Patch 2 (added):
  - Group __inline string functions in <asm/shared/string.h>.
- Link to v5: https://lore.kernel.org/r/20260630-pvh-kasan-inline-v5-0-52afc979be81@igalia.com

Changes in v5:
- Create a minimal separate header in <asm/shared/string.h> instead,
  to be used by 'boot/setup.c' and <asm/string.h> (Borislav Petkov).
- Patch 1 (in v4/v3) is no longer needed; removed.
- Patch 1 (in v5):
  - Briefly mention there are issues with <asm/string.h>.
  - Remove 'Reviewed-by: Jurgen Gross' to be conservative
    (same code change and result, but the means changed).
- Link to v4: https://lore.kernel.org/r/20260526-pvh-kasan-inline-v4-0-a310e6a25ecd@igalia.com

Changes in v4:
- Patch 1: address Juergen's feedback:
  - s/In next patch/In a future patch/.
  - Move footnote (Reasons not to include...) after "---".
- Add 'Reviewed-by: Juergen Gross' in patches 1 and 2 as well.
- Link to v3: https://lore.kernel.org/r/20260520-pvh-kasan-inline-v3-0-bede769c6ec7@igalia.com

Changes in v3:
- Create and use a separate header for inline string functions
  to fix a build error reported by kernel test robot (patch 1).
- That also removes '#ifndef _SETUP/#endif' in <asm/string.h>.
- Link to v2: https://lore.kernel.org/r/20260427-pvh-kasan-inline-v2-0-2c57b8dcff6a@igalia.com

Changes in v2:
- Add comment about the return value of __inline_memcmp() in patch 1. (v3: now 2)
- Add 'Reviewed-by: Juergen Gross' in patches 2 and 3 (v3: now 3 and 4).
- Link to v1: https://lore.kernel.org/r/20260422-pvh-kasan-inline-v1-0-7e6194344c92@igalia.com

---
Mauricio Faria de Oliveira (5):
      x86/boot: Remove "cc" clobber from memcmp()
      x86/asm, x86/boot: expose inline memcmp()
      x86/asm: group inline string functions
      x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base()
      x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh()

 arch/x86/boot/string.c               | 13 ++--------
 arch/x86/include/asm/cpuid/api.h     |  2 +-
 arch/x86/include/asm/shared/string.h | 47 ++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/string.h        | 21 +---------------
 arch/x86/platform/pvh/enlighten.c    |  3 ++-
 5 files changed, 53 insertions(+), 33 deletions(-)
---
base-commit: 903c1cf6dff9964e71eda98a39e2e5d442050472
change-id: 20260422-pvh-kasan-inline-6efac77f1b27

Best regards,
-- 
Mauricio Faria de Oliveira <mfo@igalia.com>



From xen-devel-bounces@lists.xenproject.org Sat Aug 22 18:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 18:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398249.1634710 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWv-0006fG-EA; Sat, 22 Aug 2026 18:33:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398249.1634710; Sat, 22 Aug 2026 18:33:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWv-0006f9-9w; Sat, 22 Aug 2026 18:33:21 +0000
Received: by outflank-mailman (input) for mailman id 1398249;
 Sat, 22 Aug 2026 18:33:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mfo@igalia.com>) id 1wxqWt-0006cv-AV
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 18:33:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxqWs-00A7NX-NA
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 20:33:18 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eaf9-e002-0a2a0a5209dd-0a2a4501c03e-42
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:18 +0200
Received: from [213.97.179.56] (helo=fanzine2.igalia.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb6e-5984-0a2a45010019-d561b338cbd2-3
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:18 +0200
Received: from 186-249-148-4.shared.desktop.com.br ([186.249.148.4]
 helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa 
 (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1wxqWj-007bWT-Vu; Sat, 22 Aug 2026 20:33:10 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:
	MIME-Version:Subject:Date:From:From:Reply-To;
	bh=H2GAc7mtrFpKl87p+adcJZhrkVbc1evwDywNzt1ulrU=; b=H7scH/f9ODImbbUeyRMgVs7MXe
	Nr3swyCLfgndRrDO16yiFdMGz4KKClK2UPeUFBZKVfLxmIqMoKb3T/QUykYiNYSaZ+lSiBkOAWs8K
	mPeTyiyzWVBYg9kn5vwI13IGSEJN/hnVR7zvusHc8vC26fNDy9EUiMtHFDEj94edspLbLPj0qPZq4
	ef0YCA0Glz2UqWlN13YuFbgT6H+EpD/oSjikDrT4RmtRcavY+AxKlreaSo2i+Izsrzy5b2QqYq13E
	x23H4ImJH+EvyLOnra8OZnARhQqFHaeyv6Doe0SPuSjiGkp9KCVP5E1viUqPqeS0iUv4cIYeaQW6V
	m0Hwf4Qg==;
From: Mauricio Faria de Oliveira <mfo@igalia.com>
Date: Sat, 22 Aug 2026 15:33:20 -0300
Subject: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining
 memcmp() in hypervisor_cpuid_base()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com>
References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
In-Reply-To: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, 
 Juergen Gross <jgross@suse.com>, Alexey Dobriyan <adobriyan@gmail.com>, 
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
 Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, 
 xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira <mfo@igalia.com>
X-Mailer: b4 0.14.2
X-purgate-ID: tlsNG-d62444/1787423598-C4359757-A7687FBB/0/0
X-purgate-type: clean
X-purgate-size: 1458

Even with __builtin the compiler may decide to use the out of line function
instead of the inline implementation.

The existing code is broken with gcc-14/15 but not gcc-12/13 (Ubuntu 25.10)
and vmlinux no longer boots with CONFIG_PVH if CONFIG_KASAN_GENERIC is set.

For testing purposes, if the size argument is reduced from 12 to 8 then the
compiler decides to use the inline implementation; that shows results vary.

Switch the builtin to the inline implementation to address it.

Fixes: 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()")
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/cpuid/api.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 82eddfa2347b32b76c2ea9b85f005ca5416ac71f..2d9f3d4d63de6e721f275d9e80d372edbdfedf30 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -204,7 +204,7 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves)
 		 * from PVH early boot code before instrumentation is set up
 		 * and memcmp() itself may be instrumented.
 		 */
-		if (!__builtin_memcmp(sig, signature, 12) &&
+		if (!__inline_memcmp(sig, signature, 12) &&
 		    (leaves == 0 || ((eax - base) >= leaves)))
 			return base;
 	}

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sat Aug 22 18:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 18:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398247.1634686 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWn-00061f-VM; Sat, 22 Aug 2026 18:33:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398247.1634686; Sat, 22 Aug 2026 18:33:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWn-00061W-RP; Sat, 22 Aug 2026 18:33:13 +0000
Received: by outflank-mailman (input) for mailman id 1398247;
 Sat, 22 Aug 2026 18:33:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mfo@igalia.com>) id 1wxqWm-0005mL-7w
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 18:33:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxqWl-00A7NX-L6
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 20:33:11 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb36-e002-0a2a0a5209dd-0a2a4505d466-28
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:11 +0200
Received: from [213.97.179.56] (helo=fanzine2.igalia.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb66-4cb1-0a2a45050019-d561b33894d8-3
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:11 +0200
Received: from 186-249-148-4.shared.desktop.com.br ([186.249.148.4]
 helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa 
 (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1wxqWc-007bWT-5S; Sat, 22 Aug 2026 20:33:02 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:
	MIME-Version:Subject:Date:From:From:Reply-To;
	bh=MfLC1dIVusQxZmyyohtK3IB4hBpAg/kOqSLp9mxwz1M=; b=o1Z+vuNGqvlMK/ozeR0ZPZbzr1
	gAQJqvr5CTnKAOkG9FSljuSrO7FBTDKKyyxvLqRc0XQYtRff6BhHSr6b2JpR8m8aqc3MYeM8fhc7u
	C5rwoS4DgpDkFS2xMIqzIMu4VHDgWluOs6s236Wx+O6j7O0z0FoMWlIt5GbxY6MwBRs5xNFuKz7ut
	GOU0x8Sho2S8rnKR2SZzqU1YpjnhxkZSMunIiVO9M2TZzt25+FiG0ysrCy8nBQihnZLZD8RUWVwUu
	0iig+O6Dt7z1KJcrkzHM27AKSg+JjS/hcQZek133GV2/n+ZY6sEroD+a4QyRaV8CJZa8AIfcZn9/A
	7oo4Zviw==;
From: Mauricio Faria de Oliveira <mfo@igalia.com>
Date: Sat, 22 Aug 2026 15:33:18 -0300
Subject: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com>
References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
In-Reply-To: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, 
 Juergen Gross <jgross@suse.com>, Alexey Dobriyan <adobriyan@gmail.com>, 
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
 Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, 
 xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira <mfo@igalia.com>
X-Mailer: b4 0.14.2
X-purgate-ID: tlsNG-c201ff/1787423591-72AB72A1-1E083120/0/0
X-purgate-type: clean
X-purgate-size: 2617

Move the inline memcmp function currently only available in 'boot/string.c'
into the shared string function header <asm/shared/string.h> to be reused.

This is not done through <asm/string.h> to avoid pulling unnecessary code
in 'boot/string.c' that causes build errors in 'boot/compressed/string.c'
and 'purgatory/purgatory.ro'.

No functional changes.

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>

---

Thanks to David Laight for noticing the return value difference between
inline and regular memcmp().
---
 arch/x86/boot/string.c               | 13 ++-----------
 arch/x86/include/asm/shared/string.h | 26 ++++++++++++++++++++++++++
 2 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 03278b4393887cb71cb063818d3378c4f52b06f8..be454a6864225f3a972c3e81826b77ed4e8a57fe 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -15,6 +15,7 @@
 #include <linux/errno.h>
 #include <linux/limits.h>
 #include <asm/asm.h>
+#include <asm/shared/string.h>
 #include "ctype.h"
 #include "string.h"
 
@@ -31,17 +32,7 @@
 
 int memcmp(const void *s1, const void *s2, size_t len)
 {
-	bool diff;
-
-	/*
-	 * Make sure ZF is properly set in the len==0 case because in it,
-	 * RCX==0 and the REPE; CMPSB won't get executed.
-	 */
-	asm volatile("test %3, %3\n\t"
-		     "repe cmpsb"
-		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
-		     : : "memory");
-	return diff;
+	return __inline_memcmp(s1, s2, len);
 }
 
 /*
diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h
new file mode 100644
index 0000000000000000000000000000000000000000..06c1d5e5013e4d59cfb49866d10e164362d2c4cc
--- /dev/null
+++ b/arch/x86/include/asm/shared/string.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_SHARED_STRING_H
+#define _ASM_X86_SHARED_STRING_H
+
+/*
+ * This inline memcmp() returns 0 (equal) or 1 (not equal).
+ * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than)
+ * to indicate ordering as well.
+ */
+static __always_inline int __inline_memcmp(const void *s1, const void *s2, size_t len)
+{
+	bool diff;
+
+	/*
+	 * Make sure ZF is properly set in the len==0 case because in it,
+	 * RCX==0 and the REPE; CMPSB won't get executed.
+	 */
+	asm volatile("test %3, %3\n\t"
+		     "repe cmpsb"
+		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
+		     : : "memory");
+
+	return diff;
+}
+
+#endif /* _ASM_X86_SHARED_STRING_H */

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sat Aug 22 18:33:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Aug 2026 18:33:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398250.1634718 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWx-0006vl-PP; Sat, 22 Aug 2026 18:33:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398250.1634718; Sat, 22 Aug 2026 18:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wxqWx-0006vc-MF; Sat, 22 Aug 2026 18:33:23 +0000
Received: by outflank-mailman (input) for mailman id 1398250;
 Sat, 22 Aug 2026 18:33:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mfo@igalia.com>) id 1wxqWx-0006tv-22
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 18:33:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wxqWw-006G9Z-FG
 for xen-devel@lists.xenproject.org; Sat, 22 Aug 2026 20:33:22 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89ead9-bab6-0a2a0a5309dd-0a2a450bb682-48
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:22 +0200
Received: from [213.97.179.56] (helo=fanzine2.igalia.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mfo@igalia.com>)
 id 6a89eb71-b7e8-0a2a450b0019-d561b338ce4e-3
 for <xen-devel@lists.xenproject.org>; Sat, 22 Aug 2026 20:33:22 +0200
Received: from 186-249-148-4.shared.desktop.com.br ([186.249.148.4]
 helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa 
 (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1wxqWn-007bWT-T1; Sat, 22 Aug 2026 20:33:14 +0200
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:
	MIME-Version:Subject:Date:From:From:Reply-To;
	bh=zBAAE6UPiVcuOT4Hdx5zYoG+Uei+rPkEJSxQ4+nbtAc=; b=dMe2VFbXG6LVZ97XCcOZogZ+Xl
	pKsLTJrh/GztxOCmUVySpFIS2alUMuV7GQayR1mRTdceykiWxoYxkoXRUr9C11Pz+F5zH8JYYNNBn
	Yi34qxXxtXJTg9qskyzCCk3Jp0JFGk+HajY3LrNFeIupDUyEn8sDEd69O8PSekVprWRmtrcY6qz0h
	dUJQRc9gZjDsw6kVPls2+HBH9cXK6TLxG74P7DLapJem2fZLzH96NXtGfJcYVp2IOW7ZVmk1fr3ma
	GCZ4xsK38gihLmcLo7yiNGxFgLlrLScn9kh7auOPKiiCL0IrA/QuBeKySEhAsDxw/ap2dp4nINRux
	PDVnSvmg==;
From: Mauricio Faria de Oliveira <mfo@igalia.com>
Date: Sat, 22 Aug 2026 15:33:21 -0300
Subject: [PATCH v9 5/5] x86/pvh: fix unbootable VMs by really inlining
 memset() in xen_prepare_pvh()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260822-pvh-kasan-inline-v9-5-e70ef3b75b6a@igalia.com>
References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
In-Reply-To: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, 
 Juergen Gross <jgross@suse.com>, Alexey Dobriyan <adobriyan@gmail.com>, 
 Boris Ostrovsky <boris.ostrovsky@oracle.com>, 
 Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, 
 xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira <mfo@igalia.com>
X-Mailer: b4 0.14.2
X-purgate-ID: tlsNG-42698a/1787423602-2C39B9EA-375CAE9E/0/0
X-purgate-type: clean
X-purgate-size: 1416

Even with __builtin the compiler may decide to use the out of line function
instead of the inline implementation.

This particular one (still) generated the inline implementation as expected
(at least in these compiler versions) but this is not guaranteed to remain.

Switch the builtin to the inline implementation to address it.

Fixes: fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()")
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/platform/pvh/enlighten.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index f2053cbe9b0ce3d2178938269607c652ae8f528e..cb442cbd9d828619421babb281bfe9759edbca8a 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -8,6 +8,7 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 #include <asm/x86_init.h>
+#include <asm/string.h>
 
 #include <asm/xen/interface.h>
 
@@ -129,7 +130,7 @@ void __init xen_prepare_pvh(void)
 	 * This must not compile to "call memset" because memset() may be
 	 * instrumented.
 	 */
-	__builtin_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
+	__inline_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
 	hypervisor_specific_init(xen_guest);
 

-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sun Aug 23 14:29:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Aug 2026 14:29:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398437.1634727 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wy9Bc-0000ta-Mi; Sun, 23 Aug 2026 14:28:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398437.1634727; Sun, 23 Aug 2026 14:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wy9Bc-0000tS-H9; Sun, 23 Aug 2026 14:28:36 +0000
Received: by outflank-mailman (input) for mailman id 1398437;
 Sun, 23 Aug 2026 14:28:34 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wy9Ba-0000tM-SH
 for xen-devel@lists.xenproject.org; Sun, 23 Aug 2026 14:28:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wy9Ba-003hFF-98
 for xen-devel@lists.xenproject.org; Sun, 23 Aug 2026 16:28:34 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8b0337-bab6-0a2a0a5309dd-0a2a450abd48-48
 for <xen-devel@lists.xenproject.org>; Sun, 23 Aug 2026 16:28:34 +0200
Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8b0391-f2d2-0a2a450a0019-a065830982a4-3
 for <xen-devel@lists.xenproject.org>; Sun, 23 Aug 2026 16:28:34 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id 42672839A6CA;
 Sun, 23 Aug 2026 10:26:35 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech
Subject: Re: Re: [PATCH v3] x86/nSVM: Check injected event consistency
Date: Sun, 23 Aug 2026 15:24:24 +0100
Message-ID: <20260823142426.2931564-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <affe36be-1638-4ff1-bbc1-d970f3547abe@suse.com>
References: <affe36be-1638-4ff1-bbc1-d970f3547abe@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787495314-59BC0CFC-2B175EBE/0/0
X-purgate-type: clean
X-purgate-size: 6062

On 13.08.2026 10:12, Jan Beulich wrote:
>On 06.08.2026 19:23, Abdelkareem Abdelsaamad wrote:
>> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has
>> debugging complications, security and performance implications. The APM
>> volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that
>> result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are
>> • Reserved values of TYPE have been specified.
>> • TYPE = 3 (exception) has been specified with a vector that does not
>>   correspond to an exception (this includes vector 2, which is an NMI, not
>>   an exception).
>> 
>> Extend the VMCB validation to check for such inconsistency.
>> 
>> The collection of the invalid exception vectors are ported from the upstream
>> KVM commit
>> ("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust
>> the checks from the commit to align with the APM Volume #2 and Volume #3
>> (40332—Rev. 4.40—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which
>
>Isn't this 4.10, just like you have it further up?
Yes, that's correct. I'll fix this to 4.10 in v4.
>> should not be valid on the x86 64-bit (long mode) platforms. The adjustment is
>> posted to the KVM mailing commit patch thread
>> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/
>> 
>> Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
>> ---
>> Changes in v3:
>> - Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to 
>>   non-64-bit guests to prevent impossible guest-mode state injections
>>   per AMD APM Volumes 2 & 3.
>> - Refactored exception vector validation from if-conditions to a switch
>>   statement to improve readability and extensibility.
>> - Restricted X86_EXC_CP (21) vector injection to hosts with enabled CET
>>   to prevent VMRUN failures on hardware without CET support.
>
>When reading this, I was puzzled, but the code below is correct: It's not
>the host you check, but the guest's CR4.
Right, this should refer to the guest's CR4. I will update this in v4.
>> @@ -320,6 +320,41 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
>>      svm_dump_sel("  TR", &vmcb->tr);
>>  }
>>  
>> +static bool is_valid_svm_vmcb_injected_exception_vector(
>
>Is in particular "svm" but perhaps also "vmcb" really relevant in the name
>here (which is a static helper)?
I will change to a shorter function name is_valid_injected_exception_vector in
v4.
>
>> +    const struct vmcb_struct *vmcb, uint8_t vmcb_injected_vector)
>> +{
>> +    switch ( vmcb_injected_vector )
>> +    {
>> +    case X86_EXC_DE:
>> +    case X86_EXC_DB:
>> +    case X86_EXC_BP:
>> +    case X86_EXC_UD:
>> +    case X86_EXC_NM:
>> +    case X86_EXC_DF:
>> +    case X86_EXC_TS:
>> +    case X86_EXC_NP:
>> +    case X86_EXC_SS:
>> +    case X86_EXC_GP:
>> +    case X86_EXC_PF:
>> +    case X86_EXC_MF:
>> +    case X86_EXC_AC:
>> +    case X86_EXC_MC:
>> +    case X86_EXC_XM:
>
>Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set?
This logic was ported and adopted from the KVM. The intent is to avoid
injecting invalid events on the platforms where the vector is entirely
reserved, rather than blocking valid events where a capability is not
opted-in.The X86_EXC_XM vector is valid (not reserved) on SVM-supported
platforms. I performed some testing with Naples and Genoa platforms, injecting
this vector resulted in a guest triple fault rather than a VMEXIT_INVALID. This
shows that event delivery succeeded and did not trigger VMEXIT_INVALID
>
>> +    case X86_EXC_HV:
>> +    case X86_EXC_SX:
>
>Are #HV and #SX really permitted without any constraints?
The same reasoning for X86_EXC_SX applies here.

For X86_EXC_HV, this vector is associated with SEV-SNP guests on AMD platforms.
I performed testing on both Genoa and Naples guests, injecting this event
always triggered a VMEXIT_INVALID. Based on these results, I will drop this
specific vector from the permitted events in v4.
>
>> +        return true;
>> +    case X86_EXC_OF:
>> +    case X86_EXC_BR:
>> +        return !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l);
>
>Nit: No need for parentheses on the rhs of the ||.
I will drop in v4.
>
>> +    case X86_EXC_VC:
>> +        return vmcb_get_sev_es(vmcb);
>> +    case X86_EXC_CP:
>> +        return !!(vmcb_get_cr4(vmcb) & X86_CR4_CET);
>
>No need for !! when converting to bool.
I will drop in v4.
>
>> +    default:
>> +        return false;
>> +    }
>
>Throughout: Blank lines please between non-fall-through case blocks.
I will change in v4.
>
>> @@ -392,6 +433,16 @@ bool svm_vmcb_isvalid(
>>          PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
>>                 vmcb->event_inj.raw);
>>  
>> +    if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) )
>> +        PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n",
>> +               vmcb_injected_type);
>> +
>> +    if ( (vmcb_injected_type == X86_ET_HW_EXC) &&
>> +         !is_valid_svm_vmcb_injected_exception_vector(
>> +             vmcb, vmcb_injected_vector) )
>
>Nit: Indentation is off by one here. The anchor on the earlier line isn't the
>'!' but the 'i'.
I will change in v4.
>
>> +        PRINTF("eventinj: Invalid Injected Event. Exception type: 
>> (%#"PRIx8"),"
>> +               " with a vector: (%#"PRIx8") does not belong to an exception 
>> on"
>> +               " the platform \n", vmcb_injected_type, vmcb_injected_vector);
>
>This message is quite a bit too long. There's also a stray blank ahead of the
>\n. And further arguments after one that was already wrapped across lines want
>to start on a separate line.
I will properly wrap the subsequent arguments in v4. I will change the message
to be more concise to something like
"eventinj: Invalid exception type: (%#"PRIx8") vector: (%#"PRIx8") for the "
"platform\n"
>
>Jan


From xen-devel-bounces@lists.xenproject.org Sun Aug 23 16:15:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Aug 2026 16:15:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398491.1634736 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyAr8-0006pu-UI; Sun, 23 Aug 2026 16:15:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398491.1634736; Sun, 23 Aug 2026 16:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyAr8-0006pm-RK; Sun, 23 Aug 2026 16:15:34 +0000
Received: by outflank-mailman (input) for mailman id 1398491;
 Sun, 23 Aug 2026 16:15:33 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wyAr7-0006pg-HG
 for xen-devel@lists.xenproject.org; Sun, 23 Aug 2026 16:15:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyAr6-005Vxn-E4
 for xen-devel@lists.xenproject.org; Sun, 23 Aug 2026 18:15:32 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8b1c75-8faa-0a2a0a5109dd-0a2a4509b824-22
 for <xen-devel@lists.xenproject.org>; Sun, 23 Aug 2026 18:15:32 +0200
Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8b1ca3-be1a-0a2a45090019-a0658309d838-3
 for <xen-devel@lists.xenproject.org>; Sun, 23 Aug 2026 18:15:32 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id 88F7D8355FC0;
 Sun, 23 Aug 2026 12:13:33 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Subject: [PATCH v4] x86/nSVM: Check injected event consistency
Date: Sun, 23 Aug 2026 17:11:24 +0100
Message-ID: <88078b2a2eb1f741a39562fc493330e6ee26c61c.1787497752.git.abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787501732-FD06B034-BE789805/0/0
X-purgate-type: clean
X-purgate-size: 6647

On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has
debugging complications, security and performance implications. The APM
volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that
result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are
• Reserved values of TYPE have been specified.
• TYPE = 3 (exception) has been specified with a vector that does not
  correspond to an exception (this includes vector 2, which is an NMI, not
  an exception).

Extend the VMCB validation to check for such inconsistency.

The collection of the invalid exception vectors are ported from the upstream
KVM commit
("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust
the checks from the commit to align with the APM Volume #2 and Volume #3
(40332—Rev. 4.10—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which
should not be valid on the x86 64-bit (long mode) platforms. The adjustment is
posted to the KVM mailing commit patch thread
https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/

Injecting the vector X86_EXC_HV is also found to trigger VMEXIT_INVALID with
the Xen hypervisor. Drop the X86_EXC_HV vector from the permitted vectors.

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Changes in v4:
- Reject the injected events with the valid bit not set.
- Fix the APM revision details.
- Rename the is_valid_svm_vmcb_injected_exception_vector to the shorter
  is_valid_injected_exception_vector.
- Address coding style comments regarding !! operator usage for boolean
  returns, concise debug messaging for reserved vectors, and blank lines
  between non-fall-through case blocks.
- Drop the X86_EXC_HV from the permitted vectors.

Changes in v3:
- Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to
  non-64-bit guests to prevent impossible guest-mode state injections
  per AMD APM Volumes 2 & 3.
- Refactored exception vector validation from if-conditions to a switch
  statement to improve readability and extensibility.
- Restricted X86_EXC_CP (21) vector injection to guests with enabled CET
  to prevent VMRUN failures on hardware without CET support.

Changes in v2:
- Remove the redundant SVM_EVENT_INJ_TYPE_MASK and SVM_EVENT_INJ_VEC_MASK
  constants.
- Correct the Injected Event Type consistency check to disallow the injection
  of reserved type 1 events.
---
Testing:
 - Using a locally developed XTF nested virt setup, I manually tested VMRUN
   instruction handling with a malformed VMCB:
   1) Inject event with the type (7).
      The hypervisor logs show the message
      (XEN) [  645.155609] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid
            Injected Event Type: (0x7)
   2) Inject event with the exception value (3) and the vector value (2) for
      NMI. The hypervisor logs show the message
      (XEN) [  645.157277] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid
            exception type: (0x3) vector: (0x2) for the platform. 
   3) Inject event with the exception value (3) and the vector value (21) for
      the X86_EXC_CP (Control-Flow Protection).
      Without the changes included:
          On the Naples host, where the vector was not yet known to the
          hardware. VMRUN immediately triggers VMEXIT_INVALID.
          On the Genoa host, VMRUN immediately triggers VMEXIT_VMMCALL.
      With the changes included:
          On the Naples host and the Genoa host, VMEXIT_INVALID is reported back
          without VMRUN execution.

 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2783297011
---
 xen/arch/x86/hvm/svm/vmcb.c | 58 +++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 975a1eaef8..f983179dc8 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
     svm_dump_sel("  TR", &vmcb->tr);
 }
 
+static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb,
+    uint8_t vmcb_injected_vector)
+{
+    switch ( vmcb_injected_vector )
+    {
+    case X86_EXC_DE:
+    case X86_EXC_DB:
+    case X86_EXC_BP:
+    case X86_EXC_UD:
+    case X86_EXC_NM:
+    case X86_EXC_DF:
+    case X86_EXC_TS:
+    case X86_EXC_NP:
+    case X86_EXC_SS:
+    case X86_EXC_GP:
+    case X86_EXC_PF:
+    case X86_EXC_MF:
+    case X86_EXC_AC:
+    case X86_EXC_MC:
+    case X86_EXC_XM:
+    case X86_EXC_SX:
+        return true;
+
+    case X86_EXC_OF:
+    case X86_EXC_BR:
+        return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l;
+
+    case X86_EXC_VC:
+        return vmcb_get_sev_es(vmcb);
+
+    case X86_EXC_CP:
+        return vmcb_get_cr4(vmcb) & X86_CR4_CET;
+
+    default:
+        return false;
+    }
+}
+
 bool svm_vmcb_isvalid(
     const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v,
     bool verbose)
@@ -330,6 +368,12 @@ bool svm_vmcb_isvalid(
     unsigned long cr4 = vmcb_get_cr4(vmcb);
     unsigned long valid;
     uint64_t efer = vmcb_get_efer(vmcb);
+    uint8_t vmcb_injected_type = vmcb->event_inj.type;
+    uint8_t vmcb_injected_vector = vmcb->event_inj.vector;
+    uint8_t vmcb_valid_event_inj_types_mask = (1 << X86_ET_EXT_INTR) |
+                                              (1 << X86_ET_NMI) |
+                                              (1 << X86_ET_HW_EXC) |
+                                              (1 << X86_ET_SW_INT);
 
 #define PRINTF(fmt, args...) do { \
     if ( !verbose ) return true; \
@@ -392,6 +436,20 @@ bool svm_vmcb_isvalid(
         PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
                vmcb->event_inj.raw);
 
+    if ( !vmcb->event_inj.v )
+        PRINTF("eventinj: valid bit is not set (%#"PRIx64")\n",
+               vmcb->event_inj.raw);
+
+    if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) )
+        PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n",
+               vmcb_injected_type);
+
+    if ( (vmcb_injected_type == X86_ET_HW_EXC) &&
+         !is_valid_injected_exception_vector(vmcb, vmcb_injected_vector) )
+        PRINTF("eventinj: Invalid exception type: (%#"PRIx8") vector: "
+               "(%#"PRIx8") for the platform\n",
+               vmcb_injected_type, vmcb_injected_vector);
+
 #undef PRINTF
     return ret;
 }
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398602.1634808 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMO-0008Dp-Qq; Mon, 24 Aug 2026 01:20:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398602.1634808; Mon, 24 Aug 2026 01:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMO-0008Di-Ny; Mon, 24 Aug 2026 01:20:24 +0000
Received: by outflank-mailman (input) for mailman id 1398602;
 Mon, 24 Aug 2026 01:20:23 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMN-00089r-2F
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMM-00Cy13-FS
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:22 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9bbf-2eae-0a2a0a5409dd-0a2a4509d37a-48
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:22 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c55-be1a-0a2a45090019-cddcb120710e-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:22 +0200
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67O002f64065363; Mon, 24 Aug 2026 01:20:11 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g72j1sdhu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:10 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUjg013312; Mon, 24 Aug 2026 01:20:10 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xtw-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:10 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmW5024683;
 Mon, 24 Aug 2026 01:20:09 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-8; Mon, 24 Aug 2026 01:20:09 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=38jU8
	IIonVi12pQd4z21bPmb4kb4ECiPZZIFqO5pnuc=; b=pScvHeuAnFaWyC2fLr0tu
	rnK+ZjY9niD/EvSZTO3T2+YUhWSLITVC6hZ3IC6XAGzbPxBKySQP8/a8eRvtqZF9
	1JdLkZzyny/rLLEIp2+c9aTpm8b0pyIQNLz2eAuKfzVDOxUzqckjskwt0oQkncjW
	y5zLH3XGJBSYbND6PlqS9BIo7FqRWwvTcHtqfJGYuFAxf1Rb4jzA8QjzDpMSG6Jt
	XuvoVb4+LoF9fpJIFSQHMsM0NZnpMWmTV59v1T3HHRsSvF/4EoaFs87U9QG9ArDg
	vGcpr8PgE+njSrGm6b4jSqmsvTpqxPcB7Q33ghtktr47lq3D5c4IRmeKh6G1+mEp
	w==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 7/8] hw/acpi/ged: Support forced PCI unplug
Date: Sun, 23 Aug 2026 18:13:37 -0700
Message-ID: <20260824011420.752806-8-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX24Chf8itq7kY
 c0iNGcrg2LAQYuKnGGGof6DEc5T0g8uxuU5MknKuRYVbahwnf5i/OhEpRLgeAM7Dt9fvMLlU/Zu
 JWVG8c0/lNV34IrtQvl/u4laiCRADkbE2JbG64JpT7b3bQgYs5cg
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfXypoIER7KOFEN
 yyOZFSUuWb97Na0ZmDw9aCkSMXjadybURfwMgWOU8R7nlBwKgN0Ybriz+mQ8l27GupAVOO3ngOz
 0WWJDJ8ldYaIkhrLfG6uxHqmeuObwA79mMoGflM5nUAwGAaCNGN4SuWQbapMEJ4UzjTjTB5BwuR
 Tcqrv+3M5EzTdGdcrIxcOJ+7Vfsi0XSAixwnJ73jkZiNpbvALgWQKvThQxbofGpuQCR619f8TgW
 o5W+PfCHSv7Z5PIsjmIo+/S/B+N23aVxIidj8G7TlBRnwvn2Lu7o+Y03cP52vcrpIIt5XJita2z
 +yh6Evo5COtnvGhbpNPD5iHEadc74wIcuslvOSiHRkuK4lr6rKLTAqmKT2ZvzF054kT6uzei3kD
 efkLZdlaDsNYJGxuXl0Djxoi0JkRDPJyL27YigFLEgc2VEUpyS04ssiojdaXWrnk2zEbmToYQYm
 bAR2w+M4DrPTjJcyXsXeejR6lkuC3rB0NjTI/1PU=
X-Proofpoint-GUID: W6iMb0pF__v8G2uZQ2ZPsCy8u0z8KVqP
X-Authority-Analysis: v=2.4 cv=Wek8rUhX c=1 sm=1 tr=0 ts=6a8b9c4a b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=o5oIOnhZENCTenyL_yNV:22 a=yPCof4ZbAAAA:8 a=G0a9BTs-aq7rllif8c0A:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-ORIG-GUID: W6iMb0pF__v8G2uZQ2ZPsCy8u0z8KVqP
X-purgate-ID: tlsNG-bad1c0/1787534422-FC610034-DA0F896A/0/0
X-purgate-type: clean
X-purgate-size: 1728

Support forced PCI unplug for generic event device (ged). This enables
forced removal for ACPI PCI hotplug on arm64 virt machines while rejecting
non-PCI devices.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/acpi/generic_event_device.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index 9e9416d406..3c041f5c26 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -314,6 +314,20 @@ static void acpi_ged_unplug_cb(HotplugHandler *hotplug_dev,
     }
 }
 
+static void acpi_ged_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                     DeviceState *dev, Error **errp)
+{
+    AcpiGedState *s = ACPI_GED(hotplug_dev);
+
+    if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+        acpi_pcihp_device_force_unplug_cb(hotplug_dev, &s->pcihp_state,
+                                          dev, errp);
+    } else {
+        error_setg(errp, "acpi: forced device unplug for unsupported device"
+                   " type: %s", object_get_typename(OBJECT(dev)));
+    }
+}
+
 static void acpi_ged_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list)
 {
     AcpiGedState *s = ACPI_GED(adev);
@@ -603,6 +617,7 @@ static void acpi_ged_class_init(ObjectClass *class, const void *data)
     hc->plug = acpi_ged_device_plug_cb;
     hc->unplug_request = acpi_ged_unplug_request_cb;
     hc->unplug = acpi_ged_unplug_cb;
+    hc->force_unplug = acpi_ged_force_unplug_cb;
     resettable_class_set_parent_phases(rc, NULL, ged_reset_hold, NULL,
                                        &gedc->parent_phases);
 
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398600.1634799 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJML-0007ua-LP; Mon, 24 Aug 2026 01:20:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398600.1634799; Mon, 24 Aug 2026 01:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJML-0007th-Fk; Mon, 24 Aug 2026 01:20:21 +0000
Received: by outflank-mailman (input) for mailman id 1398600;
 Mon, 24 Aug 2026 01:20:20 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMK-0007bX-Kj
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMK-008wuR-1U
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:20 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c21-bab6-0a2a0a5309dd-0a2a450ae05e-12
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:19 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c52-f2d2-0a2a450a0019-cddcb1206432-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:19 +0200
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67NNt1FD4056749; Mon, 24 Aug 2026 01:20:08 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g72j1sdht-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:07 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUaD013237; Mon, 24 Aug 2026 01:20:07 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xsb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:07 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmW3024683;
 Mon, 24 Aug 2026 01:20:06 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-7; Mon, 24 Aug 2026 01:20:06 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=aTU6W
	vwCf7dVFveRp+8Di7qF8n2TK1NxXJQMZxinPeE=; b=h+NJIWBFVetrCAi6JPQMq
	AnZre7DU29ds7rqUasZtpPzPuZ3euvUW10mHK+tuic0pdes4MIH1iiMRdAeG6Wx4
	UkeIdxvdZnhQx4Jhtpcx1wbIUmuBuJUcQmlOtqBMUue48Dt/uYEqCzONjSc6efn8
	nXNZptIM1DGZ1NSLIIfe/zv5DzVaZ/iz6BCtRgt+DI631cx6BSYunnxETOw6w/ZT
	2CIbNyNL+9dTjWgtMjDcHfjOKRMBiwfvIBrNLnner9LnSjct/Pqj9K8LdovdtUzj
	dnmJI0LlM0WsSJ6LG7EUJktRUR6VpqCMCsCLMu5eG06rQIcl+DQzH22aE6zkOfav
	w==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 6/8] hw/acpi/ich9: Support forced PCI unplug
Date: Sun, 23 Aug 2026 18:13:36 -0700
Message-ID: <20260824011420.752806-7-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfXz9YOZ9qDy8HS
 +SghGegefBKikkhHiHni+UOguA7ph92WpeC5j+tg0tD/71PJyCnN0y+p6HH0J9DdGygzEn0qN9Q
 N8Vpym8vv6fAp9PbYFSCMiq/oSHsDv2UgTBICsP5Yrj9iQhO6BPs
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX4rJccOSNWSDH
 ePO5OlzXZFL00+0OOA6BTz8zLWPUznzKMDCJBIAzVgQftNo52LqRmAEvDitqBOdwAx1dy7fD5dl
 N62MxNPp5KDPYRs3d7N55R5f5uc2lRzKJocY8tw3VcuuKTou4DcpFiZ+ud2eand4vFyGbR9mUM5
 Dc6nio5El7HqsTdIaxTxR1Fwtjwo3uvCtpiHPvEBC+Iq1xYqhF1aUqJP54bc3EFSern7AwY/p67
 1/V2ZUO6KtpRLU+g+H3DYFE8kXcffZYlYRRz4PNNybF3UBIKSQKeiU1k34sngAiLefzIMWwog6F
 wijyu79VehyMfdQVbx17/XI2/kRr9CM8aI7V21A/eF3fXFzlTu4npEn1E8QKDYt/E5GWoWfO2kR
 7kHrqf1hgalIDJn6WELVTDHts3lqU85oXPhrxCGr8cFhlBdiV1dEQBOIi0Swt6Hbfs3j10al3hO
 thPb48eBM0/6LXCsMTrcWwtN5+UvgSd5DoRI5GeA=
X-Proofpoint-GUID: vHD5v_s0FE83Tiu0YxCJBrdfCIEalDCo
X-Authority-Analysis: v=2.4 cv=Wek8rUhX c=1 sm=1 tr=0 ts=6a8b9c47 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=o5oIOnhZENCTenyL_yNV:22 a=yPCof4ZbAAAA:8 a=WNH3IyxyIQbYLsLU91AA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-ORIG-GUID: vHD5v_s0FE83Tiu0YxCJBrdfCIEalDCo
X-purgate-ID: tlsNG-4011c0/1787534419-506CECFC-31AB1BBB/0/0
X-purgate-type: clean
X-purgate-size: 2691

Support forced PCI unplug for ICH9. This enables forced removal for ACPI
PCI hotplug on q35 machines while rejecting non-PCI devices.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/acpi/ich9.c         | 15 +++++++++++++++
 hw/isa/lpc_ich9.c      |  1 +
 include/hw/acpi/ich9.h |  2 ++
 3 files changed, 18 insertions(+)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 5e8f8a7eaf..4bcaf3858b 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -528,6 +528,21 @@ void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
     }
 }
 
+void ich9_pm_device_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                    DeviceState *dev, Error **errp)
+{
+    ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
+
+    if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+        acpi_pcihp_device_force_unplug_cb(hotplug_dev,
+                                          &lpc->pm.acpi_pci_hotplug,
+                                          dev, errp);
+    } else {
+        error_setg(errp, "acpi: forced device unplug for not supported device"
+                   " type: %s", object_get_typename(OBJECT(dev)));
+    }
+}
+
 bool ich9_pm_is_hotpluggable_bus(HotplugHandler *hotplug_dev, BusState *bus)
 {
     ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index edf9783ec8..6d734ffc47 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -908,6 +908,7 @@ static void ich9_lpc_class_init(ObjectClass *klass, const void *data)
     hc->plug = ich9_pm_device_plug_cb;
     hc->unplug_request = ich9_pm_device_unplug_request_cb;
     hc->unplug = ich9_pm_device_unplug_cb;
+    hc->force_unplug = ich9_pm_device_force_unplug_cb;
     hc->is_hotpluggable_bus = ich9_pm_is_hotpluggable_bus;
     adevc->ospm_status = ich9_pm_ospm_status;
     adevc->send_event = ich9_send_gpe;
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index 30990fcef5..cc9f50a60f 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -93,6 +93,8 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev,
                                       DeviceState *dev, Error **errp);
 void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
                               Error **errp);
+void ich9_pm_device_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                    DeviceState *dev, Error **errp);
 bool ich9_pm_is_hotpluggable_bus(HotplugHandler *hotplug_dev, BusState *bus);
 
 void ich9_pm_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398596.1634763 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMI-000720-Ct; Mon, 24 Aug 2026 01:20:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398596.1634763; Mon, 24 Aug 2026 01:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMI-00071s-AJ; Mon, 24 Aug 2026 01:20:18 +0000
Received: by outflank-mailman (input) for mailman id 1398596;
 Mon, 24 Aug 2026 01:20:16 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMG-00070g-IX
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMF-008wuR-Vd
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:15 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c21-bab6-0a2a0a5309dd-0a2a450ae05e-10
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:15 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c4d-f2d2-0a2a450a0019-cddca5202b3e-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:15 +0200
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67NNGJJp129681; Mon, 24 Aug 2026 01:19:59 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g73n79bqb-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:59 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUMx013225; Mon, 24 Aug 2026 01:19:58 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xmk-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:57 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmVv024683;
 Mon, 24 Aug 2026 01:19:57 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-4; Mon, 24 Aug 2026 01:19:57 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=o1MVW
	yxP3jMV2LjBZ5MFVpAxRVDRz0Duhs68xTBpXHQ=; b=J34IT8lY11ReMNdj8nfV8
	twCPp2ctcv+ehSDUl4DjBCA6u8hLI7PU++mpmzahIeZZmguU+qlfBJTF8Kzaq0me
	nxNQnivcq7r3eAX/OORaK34CwLSlZuqcwd5b3Cp+9OqFFZ8+CmU0ZfgBPmat25aa
	KWn/m1Vd7aGwDPcKYAnF0oQJdh0TcZO7mFmSji/18THmvLVNO5lk1BCaeM6fTqL2
	1BHXO1jAu06BSI56mAUlzw/lVtkDSELIz/kUNKfkDnc2BpMrg/COOuh51YNzDsb8
	5pwPX+rTs/OPA25hBf5J0krnTf9aWJDTETmiWNiFLVUZEkqi7vZgQ5N6GLPweb2+
	w==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 3/8] qdev: Support forced device_del in QMP and HMP
Date: Sun, 23 Aug 2026 18:13:33 -0700
Message-ID: <20260824011420.752806-4-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX1V1IPWwVdfcS
 eXs0te3xFWOXdO6BoZvxCXT4GQCSBT5R7F0d4BADl7L3lUHuOr3RTWRzkbth0unfBU5m53HmZI0
 dkfqdGo78ppGi3v5PMed89Nele1DU6zhW2N/4ok48vOY5mDIx2WmQZno8d/cliY8/xKywCLPuGt
 8pGIPioXNu4/XB2iw/zjQPnCS2HHo0MhBZ4V4dxfWN6xVWhUxi8jo6MLKZvsIBw6RR/E0Mnpy7P
 QdHaI2AqIcfM9p0WcgmJvFi81Eq9WUUEYwngL4LUdCQo/hCC8FTAyRys8VxQeaDNGt+k3jkcRm/
 EHNlHNzvsMpocACMEN5tgoZcG6IblPP92/zYXjIoI34yATnASWGDK3hrqqlqMZNd6cILEoC8mRk
 rXG8Re+Fjq1EnAfYiId8nEtfSB1Mdj4u7CJTprtMlC2RUcJnLuqsHh255y4ODTDJun9O7yh+DMR
 YoeP6J8/sUmKpvM49GZxfDeLGTjJf0L0aLRQ59Eo=
X-Proofpoint-ORIG-GUID: 7H4XMNOBu3TKzfSJd7HuTZ9YSddM9Gng
X-Authority-Analysis: v=2.4 cv=Os9/DS/t c=1 sm=1 tr=0 ts=6a8b9c3f b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=EIcjfB9IiI4px24ztqRk:22 a=yPCof4ZbAAAA:8 a=VK-ukoX-n8eK6wX5QKAA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX4rgmhFCdIY8n
 y/gjdQdOF3Gaw9tA7jadsiTfFTbwMzSeg/I1l8qb8sSzCVzEhJQQTzTPOEGO8c4SycTXhsyE+Gb
 YGJe5qwQxtOC3ezaxm6/32s5tFE7hopLJW2pmrpbWR5T1f6XZE8c
X-Proofpoint-GUID: 7H4XMNOBu3TKzfSJd7HuTZ9YSddM9Gng
X-purgate-ID: tlsNG-4011c0/1787534415-536D6CFC-6F581DA1/0/0
X-purgate-type: clean
X-purgate-size: 4161

Add an optional force argument to the QMP device_del command and expose it
in HMP as "device_del -f".

When force is requested, qdev_unplug() bypasses the pending deletion guard
and asks the selected hotplug controller to complete removal through its
force_unplug callback. Controllers that do not implement the callback
reject the operation.

Forced removal bypasses guest cooperation.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hmp-commands.hx       | 11 ++++++-----
 qapi/qdev.json        | 11 +++++++++--
 system/qdev-monitor.c | 11 +++++++----
 3 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 43ff220b5f..022502b20f 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -708,17 +708,18 @@ ERST
 
     {
         .name       = "device_del",
-        .args_type  = "id:s",
-        .params     = "device",
-        .help       = "remove device",
+        .args_type  = "force:-f,id:s",
+        .params     = "[-f] device",
+        .help       = "remove device, use -f to force removal",
         .cmd        = hmp_device_del,
         .command_completion = device_del_completion,
     },
 
 SRST
-``device_del`` *id*
+``device_del`` [*-f*] *id*
   Remove device *id*. *id* may be a short ID
-  or a QOM object path.
+  or a QOM object path.  Use -f to force removal without waiting for
+  guest cooperation.
 ERST
 
     {
diff --git a/qapi/qdev.json b/qapi/qdev.json
index 974cf9c583..cb5b5ad1db 100644
--- a/qapi/qdev.json
+++ b/qapi/qdev.json
@@ -90,6 +90,11 @@
 #
 # @id: the device's ID or QOM path
 #
+# @force: if true, remove the device without waiting for guest
+#     cooperation.  The guest may still be using the device.  This can
+#     cause guest-visible errors, I/O failures, or guest crashes.
+#     (since 11.2)
+#
 # Errors:
 #     - If @id is not a valid device, DeviceNotFound
 #
@@ -101,7 +106,9 @@
 #    will automatically complete removal for all devices.  If a
 #    guest-side error in the hot removal process is detected, the
 #    device will not be removed and a `DEVICE_UNPLUG_GUEST_ERROR`
-#    event is sent.  Some errors cannot be detected.
+#    event is sent.  Some errors cannot be detected.  If @force is
+#    true, guest cooperation is bypassed, but backend cleanup is still
+#    performed through the device's normal unrealize path.
 #
 # Since: 0.14
 #
@@ -117,7 +124,7 @@
 #          "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
 #     <- { "return": {} }
 ##
-{ 'command': 'device_del', 'data': {'id': 'str'} }
+{ 'command': 'device_del', 'data': {'id': 'str', '*force': 'bool'} }
 
 ##
 # @DEVICE_DELETED:
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index fa3cae246b..ca10a25c46 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -956,11 +956,13 @@ void qdev_unplug(DeviceState *dev, bool force, Error **errp)
     error_propagate(errp, local_err);
 }
 
-void qmp_device_del(const char *id, Error **errp)
+void qmp_device_del(const char *id, bool has_force, bool force, Error **errp)
 {
     DeviceState *dev = find_device_state(id, false, errp);
+    bool do_force = has_force && force;
+
     if (dev != NULL) {
-        if (dev->pending_deleted_event &&
+        if (!do_force && dev->pending_deleted_event &&
             (dev->pending_deleted_expires_ms == 0 ||
              dev->pending_deleted_expires_ms > qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL))) {
             error_setg(errp, "Device %s is already in the "
@@ -968,7 +970,7 @@ void qmp_device_del(const char *id, Error **errp)
             return;
         }
 
-        qdev_unplug(dev, false, errp);
+        qdev_unplug(dev, do_force, errp);
     }
 }
 
@@ -1046,9 +1048,10 @@ out:
 void hmp_device_del(Monitor *mon, const QDict *qdict)
 {
     const char *id = qdict_get_str(qdict, "id");
+    bool force = qdict_get_try_bool(qdict, "force", false);
     Error *err = NULL;
 
-    qmp_device_del(id, &err);
+    qmp_device_del(id, true, force, &err);
     hmp_handle_error(mon, err);
 }
 
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398595.1634754 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJME-0006mC-32; Mon, 24 Aug 2026 01:20:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398595.1634754; Mon, 24 Aug 2026 01:20:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMD-0006m4-WB; Mon, 24 Aug 2026 01:20:13 +0000
Received: by outflank-mailman (input) for mailman id 1398595;
 Mon, 24 Aug 2026 01:20:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMC-0006bE-Ml
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMB-00AZzb-8B
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:11 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c28-e002-0a2a0a5209dd-0a2a45068ddc-12
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:11 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c49-195a-0a2a45060019-cddca5201442-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:10 +0200
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67NKeTTk080588; Mon, 24 Aug 2026 01:19:56 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g72p9sd8k-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:56 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUex013276; Mon, 24 Aug 2026 01:19:55 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xkr-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:54 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmVt024683;
 Mon, 24 Aug 2026 01:19:54 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-3; Mon, 24 Aug 2026 01:19:54 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=rUdN0
	aeKDSMQqE11yR1hJ7bU2ydRSC3JxdFwpQzV/nk=; b=NCFIEJvt2ZBHnB8T0AxWy
	ZOXACdKzmXfuTtW7FEFMm2K/ZuyzrInrJZtGHsH7ihoGH993WKuow1razVzq4Wr4
	GdZMQTv2ZU8JMNoYeLOzc2HCz1aTyKLjGSFmJtmYYWpLXxSOO7JfYRAbGlVIBNAo
	0+HgW2Yf6X/lVDZLclcGl+JazsEtnaPCAkhTcS7/iVtjnA/5HAqh/c1AcS3Y7lko
	+PKjIk3G3d6qbxEHZZuMzIbznhEIPfyIFDHUSmTAgk0RJvRKuN4qWwp2Ago+JpDl
	H7Jsta9rkcevTSxQaqoC3UYr1LTLI14RrQ7uqm798paKocIlh1TfjjKFeCcZVx/7
	w==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 2/8] qdev: hotplug: Add force_unplug handler callback
Date: Sun, 23 Aug 2026 18:13:32 -0700
Message-ID: <20260824011420.752806-3-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-ORIG-GUID: G6ZUnmDnatOdqyyPUSBLTMwgv6ngryTY
X-Authority-Analysis: v=2.4 cv=EqfiaycA c=1 sm=1 tr=0 ts=6a8b9c3c b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=x0eKOSpe3m1H3M0S9YoZ:22 a=yPCof4ZbAAAA:8 a=R0-9NCqHhopK7IinchQA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-GUID: G6ZUnmDnatOdqyyPUSBLTMwgv6ngryTY
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfXxWgLRDFowCsU
 5e+mNH+Ar5z8qIYae8wTu+DgxKud9tTIHDzx9xOtBiNas0QiqJSgvtZzng1XokCXEUwPevvItpS
 K15PQn51jTzyad8GpI1IKHED71M/ZeFSv+jrrATnaDM2jPU9u1Ah54zHBhbApL7cEwKjuyvBn6E
 K2ZZUaVNyfYte5gyB6dUGYpG+CoHNBn071ncpSUkZFtQCduuiObJwyUrhizr6a7PTB0XyR/DL3H
 nS/diGOxLEDmdx7RJ9h3VBnI3bQAneooxjI1SXLFgR8O8SdHCP5fVu69LyrSls07OCp4bihD5gy
 QEzQjCyPwAynUB1TSuLXGsLCrx5wRKrUI9CR3Px39+5h3sy3KrVed6E7ECr2DCSv9CWzvAi8j9g
 0/cK1B07edIJHRDcz7b3/Lg2wqo9h930FRrCNKUt7Uusf3x3+iFb6R45W/chExfJdnUk57y1yjR
 tfOhubkfOiUMtv+GNcp6gCZ4CWxKtQtxiP2IoMBU=
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfXwd+CFlCS9IfR
 8VEsTphbiUSSvdZcRBkpKBOm9QlsVre4/GuUwmpUFQGlHeoPCXtj7lqH35E6Ca9CP+cRvz4DASN
 0F1r2h/E3xz7o8pAfFRkpEnKv5rnZihU+DSLydPiOvnYvvHfZZZJ
X-purgate-ID: tlsNG-16d1c6/1787534411-F76C877B-FEFE9ED5/0/0
X-purgate-type: clean
X-purgate-size: 3795

Add a HotplugHandlerClass force_unplug callback and a wrapper used by the
generic qdev unplug path.

When qdev_unplug() is called with force=true, delegate to the hotplug
controller if it implements force_unplug. Controllers without the callback
return a normal error. This makes forced removal available only for
controllers that explicitly implement the operation.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/core/hotplug.c         | 11 +++++++++++
 include/hw/core/hotplug.h | 12 ++++++++++++
 system/qdev-monitor.c     | 10 +++++++++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/hw/core/hotplug.c b/hw/core/hotplug.c
index 68aabad8ae..0e44d98cf7 100644
--- a/hw/core/hotplug.c
+++ b/hw/core/hotplug.c
@@ -57,6 +57,17 @@ void hotplug_handler_unplug(HotplugHandler *plug_handler,
     }
 }
 
+void hotplug_handler_force_unplug(HotplugHandler *plug_handler,
+                                  DeviceState *plugged_dev,
+                                  Error **errp)
+{
+    HotplugHandlerClass *hdc = HOTPLUG_HANDLER_GET_CLASS(plug_handler);
+
+    if (hdc->force_unplug) {
+        hdc->force_unplug(plug_handler, plugged_dev, errp);
+    }
+}
+
 static const TypeInfo hotplug_handler_info = {
     .name          = TYPE_HOTPLUG_HANDLER,
     .parent        = TYPE_INTERFACE,
diff --git a/include/hw/core/hotplug.h b/include/hw/core/hotplug.h
index a9840ed485..300ac4fa8f 100644
--- a/include/hw/core/hotplug.h
+++ b/include/hw/core/hotplug.h
@@ -48,6 +48,8 @@ typedef void (*hotplug_fn)(HotplugHandler *plug_handler,
  * @unplug: unplug callback.
  *          Used for device removal with devices that implement
  *          asynchronous and synchronous (surprise) removal.
+ * @force_unplug: force unplug callback.
+ *                Used to complete enforced removal without guest cooperation.
  * @is_hotpluggable_bus: called to check if bus/its parent allow hotplug on bus
  */
 struct HotplugHandlerClass {
@@ -59,6 +61,7 @@ struct HotplugHandlerClass {
     hotplug_fn plug;
     hotplug_fn unplug_request;
     hotplug_fn unplug;
+    hotplug_fn force_unplug;
     bool (*is_hotpluggable_bus)(HotplugHandler *plug_handler, BusState *bus);
 };
 
@@ -96,4 +99,13 @@ void hotplug_handler_unplug_request(HotplugHandler *plug_handler,
 void hotplug_handler_unplug(HotplugHandler *plug_handler,
                             DeviceState *plugged_dev,
                             Error **errp);
+
+/**
+ * hotplug_handler_force_unplug:
+ *
+ * Calls #HotplugHandlerClass.force_unplug callback of @plug_handler.
+ */
+void hotplug_handler_force_unplug(HotplugHandler *plug_handler,
+                                  DeviceState *plugged_dev,
+                                  Error **errp);
 #endif
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 3606a347a0..fa3cae246b 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -937,7 +937,15 @@ void qdev_unplug(DeviceState *dev, bool force, Error **errp)
     /* If device supports async unplug just request it to be done,
      * otherwise just remove it synchronously */
     hdc = HOTPLUG_HANDLER_GET_CLASS(hotplug_ctrl);
-    if (hdc->unplug_request) {
+
+    if (force) {
+        if (!hdc->force_unplug) {
+            error_setg(&local_err, "Device '%s' does not support forced unplug",
+                       dev->id ? dev->id : object_get_typename(OBJECT(dev)));
+        } else {
+            hotplug_handler_force_unplug(hotplug_ctrl, dev, &local_err);
+        }
+    } else if (hdc->unplug_request) {
         hotplug_handler_unplug_request(hotplug_ctrl, dev, &local_err);
     } else {
         hotplug_handler_unplug(hotplug_ctrl, dev, &local_err);
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398597.1634769 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMI-00074k-N1; Mon, 24 Aug 2026 01:20:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398597.1634769; Mon, 24 Aug 2026 01:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMI-00074V-HZ; Mon, 24 Aug 2026 01:20:18 +0000
Received: by outflank-mailman (input) for mailman id 1398597;
 Mon, 24 Aug 2026 01:20:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMH-00070j-3C
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMG-00Cy13-2O
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:16 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c46-2eae-0a2a0a5409dd-0a2a4501a1d6-2
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:16 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c4e-5984-0a2a45010019-cddca5202e80-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:15 +0200
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67NNoaSp184913; Mon, 24 Aug 2026 01:19:53 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g73n79bq9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:53 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUFU013327; Mon, 24 Aug 2026 01:19:52 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xjv-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:51 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmVr024683;
 Mon, 24 Aug 2026 01:19:51 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-2; Mon, 24 Aug 2026 01:19:51 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=R5A5r
	X8ZNolp5d6iXru1bTvNH5HsxNPxzQWKsW5ngQk=; b=gexwkAxCTCU2CTSujcgAK
	3b40guQVoS/q1ESM3aJSUtXJBCg0qBsResRkB2M8et1OZhAYd5AfOADKiZFK/9yW
	zVTXzoIVmND4T2DxKG9/n6yY3sd6MDElh4006CGkkrG8EClIyT5DdXKmC0RZK6tW
	izvuAndZ5I01MA1cV2Bo3edh3sCIW2taWutahqRAej+Ae7l07omLFWsyPqtb7xFX
	MNFS3Dj147awOAezMukwigAmo90TekjjY+Xb7tOEs/85+dkNd4kALHnZINMyfr2R
	wpC8fIDrSxc5/sEeNjMUPitQmxWEu0ofbLNa3VSH1NudrD7PTAoDilxeG9w32iEP
	Q==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 1/8] qdev: Add force argument to qdev_unplug
Date: Sun, 23 Aug 2026 18:13:31 -0700
Message-ID: <20260824011420.752806-2-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX0pZHNniCXxvo
 +jYK89Xqx9BAiviF5TDhspqHIW99mm31IX6CyflKwUVl4yjJq97il/iY4iuqP+Z806+R1k78DX/
 RxzPoZv4I7SqKF9v8pJNyZhIlIjIVFRzLIAWKgpf02BgLC+kXyjx9tRGvIVwLyJb0l1ZDyOVi6l
 g2z7npr3VTEALBmvYct58QWhdGTGDJhN8cYem57Em8MJQV5CR+5+ZNCxdAZahWF/ORj0pWtmAup
 dmZtx/b2/QIOIFvM99diCzYM90nMqW1xPNw/aUMN9sCvlo67oovCYRzHYxXwFfFotrARKhgQ7ms
 vE6ReUgiewTyerpp1V5QkaaBTdetvJr1lK2UsvF7Qh4u+6nMZak5n2p7OTZCYuWfJSF5cNsF87j
 xptUB80Gg09hbRA4BHVmANBGETue9A/ma014LFXodMcjHj7fCV1C+xT8VQl2qWU8lm7pdWGvkqH
 zMpM8usZTyeSOAYkE0mTcCEhmKWF+X9vCUL0ZZsw=
X-Proofpoint-ORIG-GUID: zjVPwpTg9rN1xiA-29n-6Ur4p4ty26Y7
X-Authority-Analysis: v=2.4 cv=Os9/DS/t c=1 sm=1 tr=0 ts=6a8b9c39 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=EIcjfB9IiI4px24ztqRk:22 a=yPCof4ZbAAAA:8 a=DmdIBfvRwVG_7NqPh9cA:9
 a=O8hF6Hzn-FEA:10 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf
 awl=host:13521
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX3/8k42mkVOnG
 5hfcO/Qymt00VmDX9zzro68WRF+zuLyRDXj2XcOGiqF+VWdd+i0MFvP0zFX7BGXvg3jSzWxnFG8
 CDp5NJP1zNEOhZlN0rwLTfGnn4OPrTlR9V8HciqVOSkAtTMww6yK
X-Proofpoint-GUID: zjVPwpTg9rN1xiA-29n-6Ur4p4ty26Y7
X-purgate-ID: tlsNG-d62444/1787534416-C4F47757-E080D29F/0/0
X-purgate-type: clean
X-purgate-size: 5214

Add a force argument to qdev_unplug() and update all existing callers to
pass false.

No functional change.

The upcoming patches will add the hotplug controller callback used to
implement it to force detach a PCI device.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/s390x/s390-pci-bus.c     | 4 ++--
 hw/vfio/ap.c                | 2 +-
 hw/vfio/ccw.c               | 2 +-
 hw/vfio/pci.c               | 2 +-
 hw/xen/xen-legacy-backend.c | 2 +-
 hw/xen/xen_pvdev.c          | 2 +-
 include/hw/core/qdev.h      | 2 +-
 system/qdev-monitor.c       | 4 ++--
 8 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index eff980fdfe..11ff9bcce5 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -1276,7 +1276,7 @@ static void s390_pcihost_unplug_request(HotplugHandler *hotplug_dev,
         }
 
         pbdev->pci_unplug_request_processed = true;
-        qdev_unplug(DEVICE(pbdev), errp);
+        qdev_unplug(DEVICE(pbdev), false, errp);
     } else if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
         pbdev = S390_PCI_DEVICE(dev);
 
@@ -1287,7 +1287,7 @@ static void s390_pcihost_unplug_request(HotplugHandler *hotplug_dev,
          * is not blocked, e.g. because it's a PCI bridge).
          */
         if (pbdev->pdev && !pbdev->pci_unplug_request_processed) {
-            qdev_unplug(DEVICE(pbdev->pdev), errp);
+            qdev_unplug(DEVICE(pbdev->pdev), false, errp);
             return;
         }
         pbdev->pci_unplug_request_processed = false;
diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
index 6e2a1223ea..8e7c72dc8b 100644
--- a/hw/vfio/ap.c
+++ b/hw/vfio/ap.c
@@ -79,7 +79,7 @@ static void vfio_ap_req_notifier_handler(void *opaque)
         return;
     }
 
-    qdev_unplug(DEVICE(vapdev), &err);
+    qdev_unplug(DEVICE(vapdev), false, &err);
 
     if (err) {
         warn_reportf_err(err, VFIO_MSG_PREFIX, vapdev->vdev.name);
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index c3dc7c1962..c7d48966dc 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -282,7 +282,7 @@ static void vfio_ccw_req_notifier_handler(void *opaque)
         return;
     }
 
-    qdev_unplug(DEVICE(vcdev), &err);
+    qdev_unplug(DEVICE(vcdev), false, &err);
     if (err) {
         warn_reportf_err(err, VFIO_MSG_PREFIX, vcdev->vdev.name);
     }
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 428ab2f069..aafa841241 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3328,7 +3328,7 @@ static void vfio_req_notifier_handler(void *opaque)
         return;
     }
 
-    qdev_unplug(DEVICE(vdev), &err);
+    qdev_unplug(DEVICE(vdev), false, &err);
     if (err) {
         warn_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
     }
diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index 7977b52712..4aa0339887 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -186,7 +186,7 @@ static struct XenLegacyDevice *xen_be_get_xendev(const char *type, int dom,
     xendev->evtchndev = qemu_xen_evtchn_open();
     if (xendev->evtchndev == NULL) {
         xen_pv_printf(NULL, 0, "can't open evtchn device\n");
-        qdev_unplug(DEVICE(xendev), NULL);
+        qdev_unplug(DEVICE(xendev), false, NULL);
         return NULL;
     }
     qemu_set_cloexec(qemu_xen_evtchn_fd(xendev->evtchndev));
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index e36370e2ee..9518f5b3b5 100644
--- a/hw/xen/xen_pvdev.c
+++ b/hw/xen/xen_pvdev.c
@@ -273,7 +273,7 @@ void xen_pv_del_xendev(struct XenLegacyDevice *xendev)
 
     QTAILQ_REMOVE(&xendevs, xendev, next);
 
-    qdev_unplug(DEVICE(xendev), NULL);
+    qdev_unplug(DEVICE(xendev), false, NULL);
 }
 
 void xen_pv_insert_xendev(struct XenLegacyDevice *xendev)
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 37f7d33551..c1daa74914 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -527,7 +527,7 @@ bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp);
  * or NULL if there aren't any.
  */
 HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
-void qdev_unplug(DeviceState *dev, Error **errp);
+void qdev_unplug(DeviceState *dev, bool force, Error **errp);
 int qdev_sync_config(DeviceState *dev, Error **errp);
 void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
                                   DeviceState *dev, Error **errp);
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 00fed791cc..3606a347a0 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -912,7 +912,7 @@ static DeviceState *find_device_state(const char *id, bool use_generic_error,
     return dev;
 }
 
-void qdev_unplug(DeviceState *dev, Error **errp)
+void qdev_unplug(DeviceState *dev, bool force, Error **errp)
 {
     HotplugHandler *hotplug_ctrl;
     HotplugHandlerClass *hdc;
@@ -960,7 +960,7 @@ void qmp_device_del(const char *id, Error **errp)
             return;
         }
 
-        qdev_unplug(dev, errp);
+        qdev_unplug(dev, false, errp);
     }
 }
 
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398598.1634781 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMJ-0007S4-UA; Mon, 24 Aug 2026 01:20:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398598.1634781; Mon, 24 Aug 2026 01:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMJ-0007Rd-Or; Mon, 24 Aug 2026 01:20:19 +0000
Received: by outflank-mailman (input) for mailman id 1398598;
 Mon, 24 Aug 2026 01:20:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMH-00071F-Rp
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMH-00AZzb-8q
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:17 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c28-e002-0a2a0a5209dd-0a2a45068ddc-16
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:17 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c4f-195a-0a2a45060019-cddcb12056a8-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:17 +0200
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67NNt1FC4056749; Mon, 24 Aug 2026 01:20:02 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g72j1sdhp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:01 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUje013312; Mon, 24 Aug 2026 01:20:01 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xne-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:01 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmVx024683;
 Mon, 24 Aug 2026 01:20:00 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-5; Mon, 24 Aug 2026 01:20:00 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=clxy8
	VJLIb7ZVJZkEiuc8N2CQZhizNUvRA7//cEUtk4=; b=hvsHAuMhUGs6xaYlqVxp/
	bo5JnIHFTW1HpVlJmyaHv30W0b6+NG/pTtZ7S2WHEsBeRMfPDwiOs/eB5p6H8/vW
	2TDcJQfJ0hcXSSxCc5MMecZAUQGcYYkm+QWUTM9WwL4rlcrRMOGDze/sBUHVcglu
	C5rB/ZccJHTjE3kNE1sPg4LF/iKWWZBWZAgQ1MSMcI3T6GabaUerFmEgZL5/IUjw
	zmEfWDRWRLxGoKSbKDl+RqHEYG+E5jMxLP5BaPE97u4UcHp/UsMGT59rawmPPECX
	cC+ulxmbQ5VTaLqSG0W9Oqc9bafXSnG+Q9DqM1+tC5zJzNZ8aOOX8vCxTxvNPIGH
	A==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 4/8] hw/acpi/pcihp: Add forced slot unplug helper
Date: Sun, 23 Aug 2026 18:13:34 -0700
Message-ID: <20260824011420.752806-5-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX2FZAv+NEUzMh
 0/f+D6S5WYim0n+8BmCp6KjrBXbs+jJMsdc5T6R3e9Xkl2pF6lgcmCWIyomY8ag7ITGJfRjgbmp
 GNrmiT0ppLxwZz8+mxz5cpK1saXK0NOosQmGm/EqiHgS0Sx5vbG5
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfXyJNsWrGl5CgZ
 2HDfYy7qKdHFHQqmRLTgn/EHqM17beE4ci0yr9qKKO/1ZB5eY19THVJurYZY62rst7Szl9uDbe0
 O477WhCm610LcWZEDH3mnTid139r/318CtQalmAfQB3qoaYddB+FiGMcjeWJBdnndIebrZemEG/
 kAMmVRrxn7HvSKKQBAlzgSzdybZU3ZXh0Jd4DBwiNMsAxaQyWSovQB8T7Mxxj36234cIp2xZSyE
 UslijqD6FqtBW2ZhzES7idcXNlyuUA23wSN/hzJTO1ZXKypghjuV0YDKQr9K6k6O2SSOtJT7x62
 cYjn8fxIrQalceoRiIY8Ocj6VGib1LfLnygWMyhrRXPkPZ8DSDrDjQj21f8OOpK8wkjVBncSnJ8
 UZLpdXFJzwaI5KPf2giTtoOIheR5XxKK0RXjRfF0xIfp8pr5+PIgq5NCGPrDG714LQOpzwtwvcA
 egfsm6g3eE+pDoR3WVl6fNz7/uPHVGPiayaIflXU=
X-Proofpoint-GUID: Cx5bsTKMuR6dct4cv0ju6y6bw1dVa-YM
X-Authority-Analysis: v=2.4 cv=Wek8rUhX c=1 sm=1 tr=0 ts=6a8b9c41 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=o5oIOnhZENCTenyL_yNV:22 a=yPCof4ZbAAAA:8 a=ux9k6O4l50MFplsCWjgA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-ORIG-GUID: Cx5bsTKMuR6dct4cv0ju6y6bw1dVa-YM
X-purgate-ID: tlsNG-16d1c6/1787534417-1F4C977B-BF8E7114/0/0
X-purgate-type: clean
X-purgate-size: 2978

Add acpi_pcihp_device_force_unplug_cb() to complete PCI slot removal
through the existing ACPI PCI hotplug eject path.

Forced unplug intentionally does not introduce a separate teardown
sequence. It lets management trigger the same slot completion helper that
is already reachable when the guest writes the ACPI EJ register.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/acpi/acpi-pci-hotplug-stub.c |  6 ++++++
 hw/acpi/pcihp.c                 | 17 +++++++++++++++++
 include/hw/acpi/pcihp.h         |  3 +++
 3 files changed, 26 insertions(+)

diff --git a/hw/acpi/acpi-pci-hotplug-stub.c b/hw/acpi/acpi-pci-hotplug-stub.c
index d58ea726a8..9451a45c0b 100644
--- a/hw/acpi/acpi-pci-hotplug-stub.c
+++ b/hw/acpi/acpi-pci-hotplug-stub.c
@@ -30,6 +30,12 @@ void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev,
 {
 }
 
+void acpi_pcihp_device_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                       AcpiPciHpState *s, DeviceState *dev,
+                                       Error **errp)
+{
+}
+
 void acpi_pcihp_reset(AcpiPciHpState *s)
 {
 }
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 87162ff2c0..7a1f2b873a 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -367,6 +367,23 @@ void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev,
     acpi_send_event(DEVICE(hotplug_dev), ACPI_PCI_HOTPLUG_STATUS);
 }
 
+void acpi_pcihp_device_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                       AcpiPciHpState *s, DeviceState *dev,
+                                       Error **errp)
+{
+    PCIDevice *pdev = PCI_DEVICE(dev);
+    int slot = PCI_SLOT(pdev->devfn);
+    int bsel = acpi_pcihp_get_bsel(pci_get_bus(pdev));
+
+    if (bsel < 0) {
+        error_setg(errp, "Unsupported bus. Bus doesn't have property '"
+                   ACPI_PCIHP_PROP_BSEL "' set");
+        return;
+    }
+
+    acpi_pcihp_eject_slot(s, bsel, 1U << slot);
+}
+
 bool acpi_pcihp_is_hotpluggable_bus(AcpiPciHpState *s, BusState *bus)
 {
     Object *o = OBJECT(bus->parent);
diff --git a/include/hw/acpi/pcihp.h b/include/hw/acpi/pcihp.h
index efce5fd2e1..13c131b8e8 100644
--- a/include/hw/acpi/pcihp.h
+++ b/include/hw/acpi/pcihp.h
@@ -75,6 +75,9 @@ void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s,
 void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev,
                                          AcpiPciHpState *s, DeviceState *dev,
                                          Error **errp);
+void acpi_pcihp_device_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                       AcpiPciHpState *s, DeviceState *dev,
+                                       Error **errp);
 
 void build_acpi_pci_hotplug(Aml *table, AmlRegionSpace rs, uint64_t pcihp_addr);
 void build_append_pci_dsm_func0_common(Aml *ctx, Aml *retvar);
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398599.1634785 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMK-0007U3-5d; Mon, 24 Aug 2026 01:20:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398599.1634785; Mon, 24 Aug 2026 01:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMK-0007Sj-12; Mon, 24 Aug 2026 01:20:20 +0000
Received: by outflank-mailman (input) for mailman id 1398599;
 Mon, 24 Aug 2026 01:20:18 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMI-00071S-5E
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMH-00AZzb-Ia
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:17 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c28-e002-0a2a0a5209dd-0a2a45068ddc-18
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:17 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c50-195a-0a2a45060019-cddcb120582a-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:17 +0200
Received: from pps.filterd (m0246630.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67O00kWL3992865; Mon, 24 Aug 2026 01:20:05 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g726bhdp9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:04 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FURi013245; Mon, 24 Aug 2026 01:20:04 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xq4-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:04 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmW1024683;
 Mon, 24 Aug 2026 01:20:03 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-6; Mon, 24 Aug 2026 01:20:03 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=ZkCph
	0zQMEceV1V18yZjC3gcjw4ROxQqcgj3PoAbDGw=; b=K+ppLH/PCrj/wbA/jzZyt
	bdWHWQsvBzJP3uHHw0XVLHrTgqphOE8xm6sv4c059cmQtpVO+0EohzFiC2r2t2wJ
	gbK72cj5QYQpd4zlR3Pj5JlySk2DNqIxDPow3OPvB5cyzuuO2eJCNc917BuBXFbE
	B1Hf1v3SmNbum+TIuj2ohgbbVcc5dEPwqwSFc6Bud1ubjYj0CDPxUqXZuEjuKmUS
	jmw1wUjZVY9yejj23QxQERzBShuELPBA12M1EM/r1y6o/lOa4tz4r1wUGxIU44Wx
	0MmIrv1Li2sqU2zPBS71UGJi9LiBxcq0UyzBAOGjgXb2mK5kDV477Q24t0TpV3S5
	g==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 5/8] hw/acpi/piix4: Support forced PCI unplug
Date: Sun, 23 Aug 2026 18:13:35 -0700
Message-ID: <20260824011420.752806-6-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Authority-Analysis: v=2.4 cv=Q6niJY2a c=1 sm=1 tr=0 ts=6a8b9c44 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=x4eqshVgHu-cdnggieHk:22 a=yPCof4ZbAAAA:8 a=sVUD1VjQnF4y5snLtUwA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfXxvMG/AodywxN
 jCyivwTyKNJb7pSvrie6I6RuCokvMF818rlPF/8bsoT0lCdzDmVzD4+NE+ApH2tNNrMR29QI5vH
 anCSfJXwMSn8z9g4yRkYBLJhEllboYQdR0mYgvtnTOI2tygxcVXlp2gXMcNjY5bdMTVdVy3XRpy
 laFF9tvkH1QdRK0yFgl/ZdEyTF158dwT7d72qSHbJhdpZhUKFap93RJxyPEeEwVvBtD2bExAJc3
 A7Kx3mGRPcsDclRFwoGTz+j1hA6geSYW8y/l98FSUO1P4W9EQc33VoswjNARv9DLmJbxvOXNwMG
 JD3psO7dHlYK+SouXuCgwMhr9MeH2LxvI6+LOvBTjJZwc/RT3Gx/aw9pHyRj+Pi1DfUMQzPLjRr
 F+54t1AGpMLhGcirKbnldfuTeZLRSmF/vvsrA+AycOv/aNGvPYM537nGfrH7CS7qtDhHT+77DU5
 YJtx4JTtE1XpJo83Aw2HghZBAnRKht72ekQZFnFs=
X-Proofpoint-GUID: BQ11WiPJKvoDJTnITlj-K1M2Dpi6kofY
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX7PdpZXwEuZUR
 Kgpvj5Y7N7TTyuKSMp5OJlRcXWjHfLjfn7glgHYeRaDpIakhtEpRIbV+XwtwlegXouqk0gUb+/J
 7oNzYP0rhwchNLwIlmNs4M0BGlJHxMf85/XFZ/BF0V0dvNDxdY2C
X-Proofpoint-ORIG-GUID: BQ11WiPJKvoDJTnITlj-K1M2Dpi6kofY
X-purgate-ID: tlsNG-16d1c6/1787534417-1ECC577B-B3BCA6E3/0/0
X-purgate-type: clean
X-purgate-size: 1666

Support forced PCI unplug for PIIX4. This enables forced removal for ACPI
PCI hotplug on i440fx machines while rejecting non-PCI devices.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/acpi/piix4.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 9b7f50c7af..7cfdcb7935 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -383,6 +383,20 @@ static void piix4_device_unplug_cb(HotplugHandler *hotplug_dev,
     }
 }
 
+static void piix4_device_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                         DeviceState *dev, Error **errp)
+{
+    PIIX4PMState *s = PIIX4_PM(hotplug_dev);
+
+    if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+        acpi_pcihp_device_force_unplug_cb(hotplug_dev, &s->acpi_pci_hotplug,
+                                          dev, errp);
+    } else {
+        error_setg(errp, "acpi: forced device unplug for not supported device"
+                   " type: %s", object_get_typename(OBJECT(dev)));
+    }
+}
+
 static bool piix4_is_hotpluggable_bus(HotplugHandler *hotplug_dev,
                                       BusState *bus)
 {
@@ -604,6 +618,7 @@ static void piix4_pm_class_init(ObjectClass *klass, const void *data)
     hc->plug = piix4_device_plug_cb;
     hc->unplug_request = piix4_device_unplug_request_cb;
     hc->unplug = piix4_device_unplug_cb;
+    hc->force_unplug = piix4_device_force_unplug_cb;
     hc->is_hotpluggable_bus = piix4_is_hotpluggable_bus;
     adevc->ospm_status = piix4_ospm_status;
     adevc->send_event = piix4_send_gpe;
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398594.1634745 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMC-0006bR-Um; Mon, 24 Aug 2026 01:20:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398594.1634745; Mon, 24 Aug 2026 01:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMC-0006bF-Pf; Mon, 24 Aug 2026 01:20:12 +0000
Received: by outflank-mailman (input) for mailman id 1398594;
 Mon, 24 Aug 2026 01:20:11 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMB-0006as-6f
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJM9-0000mT-B5
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:09 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c41-8faa-0a2a0a5109dd-0a2a4504aa5e-4
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:08 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c47-b57f-0a2a45040019-cddca52007ca-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:08 +0200
Received: from pps.filterd (m0246627.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67NNp0ps4046632; Mon, 24 Aug 2026 01:19:50 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g72by1cvh-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:50 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FTpG013204; Mon, 24 Aug 2026 01:19:49 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xhy-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:19:48 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmVp024683;
 Mon, 24 Aug 2026 01:19:48 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-1; Mon, 24 Aug 2026 01:19:47 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=corp-2025-04-25; bh=47lJmUqdv0eBZXC4QoeOtUFhB877q
	P3XUHgjRFnI1cE=; b=V9brxdzYqf9FuhxInQiANy4S+nNJs0abuLiAncz75vGiS
	fEFLGOcWiXZrOlQyAl5v//Ch77VGQDwngnxXgSqHYniJJLIFfMRRy3i7A7nGetXf
	lQodCD7eSAYPW/kjGRLyiJM6FkeXuLuNVYURsc4rps5dU/KZpfUKneukljI9PtPL
	lQ1udgjEGgrHPOtFwV+B2/tiztJSKOtt+r/jXzekkSpWbsJxnIsYO38Xotd5mier
	vh49zeuBUon9cmBlaZZPbRADDa3995yM+hz+78mika5nw2Qc0ou1fAwJw6ucFjPP
	wcQLzp1zQZJcbhlneyeMy5pxyLur3ZktvQcfWAaeA==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug
Date: Sun, 23 Aug 2026 18:13:30 -0700
Message-ID: <20260824011420.752806-1-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=904 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX3BF2TB91yoxr
 J4S8XZdgPFf9o24g9LQzGnntjof/oDB/7xKrKOlQ4S6p8Znos6VamXoOeTjImw+KOkSntrkBO3L
 V7B43TV4RNO0beNfNjKnSzpHEVUg6F5GgdsmkrhyTDAT7omFFEf5oKZC+rVNjL/3H0fl0zZ+jo6
 c4FjufpmUrDCx0twHW0VxntMzS0lDSOKjBrRAuyK9gRvmlJJPzHci3vnbrCVSjM744/aBMCrekv
 C+TOfcpl2eFbJICIsjNGyVlO/YE430FWCBh5lM47cYUUo5HGdzyCFe2bpZ/nmMN8+i7USfIbtdJ
 9ddUY68T4GfjERKl7CkFUx7SqIYBpIzPQWPKApZ2bbLI5Ns2f71C8uSXbwpkQ1U+AFSlmnQwNLQ
 XiAU1VLcO9aj+r2/67qtRqMYLkaTPIAadcJ3e8Whj46Krz7YNCdZnCHx/3LQkX1QIpBGnH9Cryq
 LK30Cq6M5p9LqXahnrkaIuPhfKRT1+xqVow1XT/4=
X-Proofpoint-GUID: kXNlk9faoRWpNtS_08ftUnZQijJ94D1Q
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX1Ad5XuEgQrKe
 wbBpPbFVxeMEar49WkGuCY0fGdIwGy8qO8VFQ4HFr3CL//K+Wfgk0XypouAesePDkd+1BM6iTCK
 XDOuSWlSbVu4OujNRbFAWa0z9kS/sZ0mno3sk0q9Wx5vhIET7vKW
X-Authority-Analysis: v=2.4 cv=fqTsol4f c=1 sm=1 tr=0 ts=6a8b9c36 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=RD47p0oAkeU5bO7t-o6f:22 a=p0WdMEafAAAA:8 a=bvKi9n43um0Dy7nFDjwA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-ORIG-GUID: kXNlk9faoRWpNtS_08ftUnZQijJ94D1Q
X-purgate-ID: tlsNG-ebf023/1787534408-C14D3B50-78290CD1/0/0
X-purgate-type: clean
X-purgate-size: 4208

Hot-unplugging a PCI device can require cooperation from the guest. For
ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest
eventually writes the ACPI PCI eject register. For PCIe native hotplug,
QEMU notifies the guest through the PCIe hotplug mechanism and waits for
the slot unplug flow to complete. Only after that completion does QEMU
unrealize the device and emit DEVICE_DELETED.

This can leave a device stuck in the unplug pending state when the guest
does not cooperate. Examples include:

1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is
unavailable.

2. The guest is stalled and cannot handle the hot-unplug event. For
example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this
for ACPI-based hot-unplug.

3. The device was attached to a slot that the guest cannot use. For
example, a pcie-root-port only supports slot 0. If a device is added to a
non-zero slot below a pcie-root-port, the guest may never discover the
device and therefore may never complete the unplug request.

The non-zero slot case has also been discussed in:

hw/pci: warn when PCIe device is plugged into non-zero slot of downstream port
https://gitlab.com/qemu-project/qemu/-/commit/ca92eb5defcf9d1c2106341744a73a03cf26e824

hw/pci: add comment to explain checking for available function 0 in pci hotplug
https://gitlab.com/qemu-project/qemu/-/commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5

pci: don't skip function 0 occupancy verification for devfn auto assign
https://gitlab.com/qemu-project/qemu/-/commit/e228d62b4af29bca698ec57efdceb46f392f5444

For example, if root-port.1 is a pcie-root-port, the following command adds
a vhost-scsi-pci device to an invalid slot:

(qemu) device_add vhost-scsi-pci,id=scsi01,wwpn=naa.5001405324af0985,bus=root-port.1,addr=01.0
warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device only allows plugging into slot 0.

In this situation, the device may be impossible to remove through normal
guest-cooperative hot-unplug. Production environments also need a host side
recovery option when the guest kernel is the reason that unplug does not
complete.

This series adds a force option to QMP device_del and HMP device_del. When
requested, QEMU asks the selected hotplug controller to complete the unplug
through a new force_unplug callback.

This series implements forced unplug for ACPI PCI hotplug and PCIe native
hotplug, which cover common pc/q35/virt cases. SHPC is not implemented by
this series.


Dongli Zhang (8):
  qdev: Add force argument to qdev_unplug
  qdev: hotplug: Add force_unplug handler callback
  qdev: Support forced device_del in QMP and HMP
  hw/acpi/pcihp: acpi/pcihp: Add forced slot unplug helper
  hw/acpi/piix4: Support forced PCI unplug
  hw/acpi/ich9: Support forced PCI unplug
  hw/acpi/ged: Support forced PCI unplug
  hw/pci/pcie: Support forced PCIe native unplug

 hmp-commands.hx                 | 11 ++++++-----
 hw/acpi/acpi-pci-hotplug-stub.c |  6 ++++++
 hw/acpi/generic_event_device.c  | 15 +++++++++++++++
 hw/acpi/ich9.c                  | 15 +++++++++++++++
 hw/acpi/pcihp.c                 | 17 +++++++++++++++++
 hw/acpi/piix4.c                 | 15 +++++++++++++++
 hw/core/hotplug.c               | 11 +++++++++++
 hw/isa/lpc_ich9.c               |  1 +
 hw/pci/pcie.c                   | 20 ++++++++++++++++++++
 hw/pci/pcie_port.c              |  1 +
 hw/s390x/s390-pci-bus.c         |  4 ++--
 hw/vfio/ap.c                    |  2 +-
 hw/vfio/ccw.c                   |  2 +-
 hw/vfio/pci.c                   |  2 +-
 hw/xen/xen-legacy-backend.c     |  2 +-
 hw/xen/xen_pvdev.c              |  2 +-
 include/hw/acpi/ich9.h          |  2 ++
 include/hw/acpi/pcihp.h         |  3 +++
 include/hw/core/hotplug.h       | 12 ++++++++++++
 include/hw/core/qdev.h          |  2 +-
 include/hw/pci/pcie.h           |  2 ++
 qapi/qdev.json                  | 11 +++++++++--
 system/qdev-monitor.c           | 23 +++++++++++++++++------
 23 files changed, 160 insertions(+), 21 deletions(-)

base-commit: eea8fe61b8be8f3016e522e6af24924a0266ca95

Thank you very much!

Dongli Zhang



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 01:20:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 01:20:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398607.1634816 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMT-00009d-4J; Mon, 24 Aug 2026 01:20:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398607.1634816; Mon, 24 Aug 2026 01:20:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyJMT-00009Q-14; Mon, 24 Aug 2026 01:20:29 +0000
Received: by outflank-mailman (input) for mailman id 1398607;
 Mon, 24 Aug 2026 01:20:27 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wyJMR-00005x-Oz
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 01:20:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyJMR-00AZzb-5z
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 03:20:27 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c28-e002-0a2a0a5209dd-0a2a45068ddc-28
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:27 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8b9c59-195a-0a2a45060019-cddcb12089c8-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 03:20:26 +0200
Received: from pps.filterd (m0246632.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67O0Ap2W4093319; Mon, 24 Aug 2026 01:20:14 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g73csscpa-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:13 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67O1FUME013326; Mon, 24 Aug 2026 01:20:13 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84kh6xva-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 01:20:13 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67O1JmW7024683;
 Mon, 24 Aug 2026 01:20:12 GMT
Received: from localhost.localdomain (ca-dev80.us.oracle.com [10.211.9.80])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4g84kh6xgy-9; Mon, 24 Aug 2026 01:20:12 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=XvAUB
	QoXJbUB6s9aMnBe/fHC44+ByRRCLPqOgVKeuAU=; b=Y0MpiKVRey6ei+1/34zOS
	a54gCEOHbdPQ0e9QzNvN7YHTt/eLHnxWj7sjJvNF2TJRlfQf/Tna/zXYCYPQGOsu
	o1CqeNiGYjSJMGBaArYHjqmUBEm3ANVefTsbiI9iExpTiDy/O57OlmKoqKzwWLgl
	BN/TsUqm5hUUNy3+glZvAXk4ZnOWP3fgDGi5nblbnFlkDQlaGIx3LM/GdVx2zZkb
	Co+49SOAYPcwz8wPGYiWr6ZlHsWu8O+ahTvDh2C4si7U4DiEtj/oYMNSP23zn2rq
	wz/6oGnKTX9wcZ2NRNifFzhtT4lFeyJLzixh7m7BRIqP1rK0HXHDCWBFqU/l7k+E
	Q==
From: Dongli Zhang <dongli.zhang@oracle.com>
To: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
Subject: [PATCH 8/8] hw/pci/pcie: Support forced PCIe native unplug
Date: Sun, 23 Aug 2026 18:13:38 -0700
Message-ID: <20260824011420.752806-9-dongli.zhang@oracle.com>
X-Mailer: git-send-email 2.43.5
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_01,2026-08-21_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0
 suspectscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0
 lowpriorityscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608240009
X-Authority-Analysis: v=2.4 cv=D+h37PRj c=1 sm=1 tr=0 ts=6a8b9c4e b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=3I1J8UUJPc9JN9BFgKH3:22 a=yPCof4ZbAAAA:8 a=IQMDJlptZtJ-cjhD5E0A:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX5rG4lXUBNxHq
 T+o4qRB20FbSQ3VkEDo0kDPEQGcipZoPjbrAhux1NKndowjuN2sBil13UbyffaoxT7I9OStPXoi
 oKpY3xlRnw7DYH40382c7wXgk/SqNQDdbi87Fh/QPyJY6loUC8Sr
X-Proofpoint-ORIG-GUID: 9fPHksSYfaSWwaY-VGY-i5dZnZuVka1r
X-Proofpoint-GUID: 9fPHksSYfaSWwaY-VGY-i5dZnZuVka1r
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDAwOSBTYWx0ZWRfX99x47b0T2hs4
 lWe2QX2cJi8aWQ+T2BCIwD9hyY9fQuc6qYrHdLK7e21Lrxi/eqwyM9CGGMUG2mL/oGHCX1eDZ6a
 0q4EfeIACp+Nma3vsITTIYdWUcLayceHZoNmgJNLX3qktn6sUQoihHoxqEVb/vM2Dv3us7m1XP6
 WBcSb+U/E9Qem2YaUlL8mQz23is7gLawKUVDH1DquPuoaEkXetx87y9DBQntyDfAYXxZsUDEKyY
 wQ74G0acFOp8+UdjmyJq2zAp9IXCubuw4oZuhqGITPuGdvP0eF6h4GdaSmHiO1kWYseA3LjWbLo
 OKoqIaYi0A6QMS0ZHvJyxoacdJbz8K+qdnUPmaZl5eWRuruUjGELJE5J+3jTvgZqZgwOGmKO8i6
 PrltezR6ziKJrdjqpFv48rH8574fr0utBHzDEF91JkSbp6wQUx0FagpotuTD2qPdgewWfVgxjrH
 KxOLfVz0YUlGY1MOH/1+bfXrMHFYzPuk52BZaBnk=
X-purgate-ID: tlsNG-16d1c6/1787534427-FDA0C77B-B16D083D/0/0
X-purgate-type: clean
X-purgate-size: 2937

Support forced PCIe native unplug by implementing force_unplug method.

The forced path completes the pending slot unplug immediately through the
existing PCIe slot removal helper, clears the attention button pressed
status bit, and notifies the hotplug event.

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
 hw/pci/pcie.c         | 20 ++++++++++++++++++++
 hw/pci/pcie_port.c    |  1 +
 include/hw/pci/pcie.h |  2 ++
 3 files changed, 23 insertions(+)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 4622c75e48..bd967ca73b 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -666,6 +666,26 @@ void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev,
     pcie_cap_slot_push_attention_button(hotplug_pdev);
 }
 
+void pcie_cap_slot_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                   DeviceState *dev, Error **errp)
+{
+    PCIDevice *hotplug_pdev = PCI_DEVICE(hotplug_dev);
+    uint8_t *exp_cap = hotplug_pdev->config + hotplug_pdev->exp.exp_cap;
+    uint32_t sltcap = pci_get_word(exp_cap + PCI_EXP_SLTCAP);
+
+    if ((sltcap & PCI_EXP_SLTCAP_HPC) == 0) {
+        error_setg(errp, "Hot-unplug failed: "
+                   "unsupported by the port device '%s'",
+                   DEVICE(hotplug_pdev)->id);
+        return;
+    }
+
+    pcie_cap_slot_do_unplug(hotplug_pdev);
+    pci_word_test_and_clear_mask(exp_cap + PCI_EXP_SLTSTA,
+                                 PCI_EXP_SLTSTA_ABP);
+    hotplug_event_notify(hotplug_pdev);
+}
+
 /* pci express slot for pci express root/downstream port
    PCI express capability slot registers */
 void pcie_cap_slot_init(PCIDevice *dev, PCIESlot *s)
diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c
index dbb6032160..4806c8289b 100644
--- a/hw/pci/pcie_port.c
+++ b/hw/pci/pcie_port.c
@@ -221,6 +221,7 @@ static void pcie_slot_class_init(ObjectClass *oc, const void *data)
     hc->plug = pcie_cap_slot_plug_cb;
     hc->unplug = pcie_cap_slot_unplug_cb;
     hc->unplug_request = pcie_cap_slot_unplug_request_cb;
+    hc->force_unplug = pcie_cap_slot_force_unplug_cb;
     hc->is_hotpluggable_bus = pcie_slot_is_hotpluggable_bus;
 }
 
diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h
index 71ba94874b..08c6c81f34 100644
--- a/include/hw/pci/pcie.h
+++ b/include/hw/pci/pcie.h
@@ -154,6 +154,8 @@ void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
                              Error **errp);
 void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev,
                                      DeviceState *dev, Error **errp);
+void pcie_cap_slot_force_unplug_cb(HotplugHandler *hotplug_dev,
+                                   DeviceState *dev, Error **errp);
 
 void pcie_pasid_common_init(PCIDevice *dev, uint16_t offset,
                             uint8_t pasid_width, bool exec_perm, bool priv_mod);
-- 
2.43.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 04:46:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 04:46:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398680.1634827 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyMZT-0001wm-5I; Mon, 24 Aug 2026 04:46:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398680.1634827; Mon, 24 Aug 2026 04:46:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyMZT-0001wb-1H; Mon, 24 Aug 2026 04:46:07 +0000
Received: by outflank-mailman (input) for mailman id 1398680;
 Mon, 24 Aug 2026 04:46:06 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wyMZR-0001wQ-A5
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 04:46:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyMZP-00FJ0b-19
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 06:46:03 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a8bcc6e-bab6-0a2a0a5309dd-0a2a4509e97a-22
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 06:46:00 +0200
Received: from [52.101.125.79]
 (helo=TYVP286CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a8bcc85-be1a-0a2a45090019-34657d4f4956-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 06:45:59 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by TYYP286MB4363.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:10f::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 04:45:55 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0339.012; Mon, 24 Aug 2026
 04:45:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yTbEvEUht2E71Uxt04MXZfX8O/7dbxKwoCRCQIrs8OzeUOaSDzhoDn16IFtjKiokWfpeWijji1JAV6zVVT+JbHYTSbJEwjwbptTqa1d4ufYBEqh3sF3o41yvS5wDNcnssnM3xRQ8zkNPUd77jFmj+dlu79nF8xiQ6xbKNloEhUl/os2Up+bs31duj7gMG6eIf5/ifvZBVGc/WkTKMsy0JERSqG4HjyUI4WZmnBAoRRgttn2kCCy4AQNh88EbjhSGqb/XMmLOe8eRAIrgujpIOX2nnsdviiouvfV4qa8NOCAXkULS2JDTAMqVp8wHMkExKMGRmaLuUkv1a8fpBhhN2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZNsV9Vmr5QU6JBhaP1i8d8InudzRJvIDKi80RWCWSnY=;
 b=evhg8rE1E0vaWURq/pIW7kE2lKGPiGiQq7nnOEZaEBIZ0QZq+uh9DyGpMtQuuDgJqsl0ZyED+/iRQ7H9i9c3pCSkihoB/ulnLSyCAAel0A3ZmlEHS+AEGeS3cVB1Pg/H66QhxPjdLxfNcLE+eJ5OzzdyaRVe7RaAobWQ0LZR1DizbUoS4yehg+UMitgXHxvj+hnrtHFbDw+wKULp6BFcALehXSuogmgc6FNeWV6MUBhnNl9hRg4F0C3iV3ruijEP0znsjHPTFovBs2YbjDlaJ5SIgq16jmjdhNtjZb9HkKDPWn+33TnqyMz8WaFjZBa/5U9BASDqZKbVLPN35Ba7VQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZNsV9Vmr5QU6JBhaP1i8d8InudzRJvIDKi80RWCWSnY=;
 b=jwxYQ4UpYRq5pdiAfr+0eQ1IVLkz5q94lpVIDffzZIdq9DJ4icPG68oMCtucVa8p0xXfvLeVbFZMRqQKjlSpMeTYvG1/6+bv0qdOpEt+OFAdWJApdbmP2TkpjHm8ajocYo7OXxxJyxCW6y7OEgHYIyMO7RdHf3ZCupvX3+sBn48=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: xen-devel@lists.xenproject.org
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>
Subject: [PATCH v3] xen/arm: Hide PMU registers from the guest, when the vPMU feature is disabled.
Date: Mon, 24 Aug 2026 13:45:30 +0900
Message-ID: <20260824044530.301938-1-taka@valinux.co.jp>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TY4PR01CA0127.jpnprd01.prod.outlook.com
 (2603:1096:405:379::14) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:458::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYYP286MB4363:EE_
X-MS-Office365-Filtering-Correlation-Id: 04305166-0107-4358-fbf3-08df019a94ea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|7416014|366016|1800799024|10070799003|10067099003|56012099006|6133799003|18002099003;
X-Microsoft-Antispam-Message-Info:
	o+Vu3UlKunGCi+fXinBBzjuSetdVZWyZtvZo9Q2qfWrtWCOma64XoQzJc7Ej7f2KsNGHXYMIx3KKsxcDQfR5qaPj3YvVm/GwNumrIxsyNfBvIHjs1I8olrs1dNsr3JVINTbP1H85q0QwawlSsirSoLLnnuMM6gW0j81ZjhQULR9JvkxYAKNPyvim4qhYL2zLoo4tAEw/CsD5+fFcE8pLb5odD0ZL02w2W2XXytHPWPxRJq4rZxfDIp49BaL+5oFtBn1g/h0lEb1apz4pNecKXsw6YkVECnqLSZQnXUh373TI1nSj/KxF+9nuFbTct5nrBMbiy/OnouAMjkoU31Wf1zcWpk01p1eQZUOKJ4wxvdOVDRNdFCneC3bjUvPjSRwUJyEUSSzzSznptcD8mmHEAn8Py4nmkzoNjxgBeUlBCJG2GBONnyf2mfsJCnb0Md3HUO/i2NxVfD4N8egwSx+7/Y4NYl1yB+Oq+LRVwO2bTlENfjnf0wn5z9eb1HKJo1xVBwRZnWg18R/fJqtvuLR9W4X/JdlnDI3zd0gZ+Y83vuagLwTueZCm0PpK05IeOjvRBLl5JjUiOasighvwbfgDTqwmdNDJMxeoHQDlkMQ6rRDrOf1LVMRnL/AUND4L1ywMFvdv9MqmmTF2O5YChlxBjVcqCpiU27EkTUhkwpJ4e+4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(366016)(1800799024)(10070799003)(10067099003)(56012099006)(6133799003)(18002099003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?D9lpxebitr0/0XeXrkQ8D3TW6nefWHkLpFjNvgR5nGRCVWsw2MZfWZ/E/Z1W?=
 =?us-ascii?Q?5QgZqH19zNbfdcdIrfOaNq3Zvjxo95O/8hw/71Q/HgVZnxA4fo+j0SMloUWJ?=
 =?us-ascii?Q?LSE1LKdce/awHo/o23VolxW64OkPS+k1LssorHasOgJnWzoHk77iA+qPOP6G?=
 =?us-ascii?Q?+nz8hCBIO52WIDgWrvb4xw/ef05hMMx3bkqQPAOjw9sYutV0YzPlE+qydY9E?=
 =?us-ascii?Q?mKBjTwBCo9GoDd09LFcLJURKH8Wk7Es2wwoze9GC722eVk+ETrHXWkHL8maR?=
 =?us-ascii?Q?pseYuWQCiJCkI//2R4qUb/8GY0gKFyqfx3BPC0Xb63s1GsP5KHhrJMww8yyp?=
 =?us-ascii?Q?CmQKUZzJidbo+ZNG5SxR70iobtUbWpgGhJfulyZH821C5nToS6zmxYrkrVz9?=
 =?us-ascii?Q?d1b0kfRB3LLjRgcg5yfIatHgy5bYPryoFzt5G7ATzedBp5wcucKtdcWgjB0V?=
 =?us-ascii?Q?sI8YLc2apm+A2IchYZbAQSjTJ+IE5fDPv3GJs2fQwttBsiCbThYOJ2KhXzo/?=
 =?us-ascii?Q?OofsnyZ6xxoDBub0SCWaf0JE7MyygyUE6lO4Aj4jkY70p798BLMEUWng+mTg?=
 =?us-ascii?Q?o/37iaflcI35lgHBk8gpmWaL1fyljfersp5H8i85dawBqHI2KpVGT8G53LQm?=
 =?us-ascii?Q?VG6Ujz2akDPguqeRloWboQOIvvnxqyJkrPfKdPmJLMS2sRQAkuayAN9ywD5h?=
 =?us-ascii?Q?bTA2cnbYQVaVHgeNaBwZ4dpCzqTs+BMKxpP8pwp/unYbR0ewFonYytWS4KSa?=
 =?us-ascii?Q?09LlFHYuWTyGEdAQAVoutdHR5RKk3H9CRFAykyfwP0nI3hPxPSfP5kNVaKu4?=
 =?us-ascii?Q?p6cmwid2f1fgkNMV3lH0yoPFpCt6WWxqot6HRpwqHzsBtRygcDDiQ2t8RmJ2?=
 =?us-ascii?Q?VFuTu+ZP7cGeKVdvK606mWjsjNtS4F/d4xvhZ9GDBi0oiRNbkkMmCZVoESlY?=
 =?us-ascii?Q?dSaGOuedT2zu00enXNELwjBRmD3uErsvjC8kb4CviNdyJvKT8EEgbB47ydh0?=
 =?us-ascii?Q?2VK3Uihz/iic7i/eVo/F/Vx5b0Oy91KH3fx3qnRrZUCXc+60DT2VIRsoRjZu?=
 =?us-ascii?Q?13SLYRMH3KhvEweyu+gaVSche8gCckSgwrmHhp3ZCkjFEc9XIG+iNetIDCx1?=
 =?us-ascii?Q?8jaWLPlN+hZfm4TgBj0LJ9VRFD76k46sZvr9k618zYHu1Ow28Cs6B4ikABA+?=
 =?us-ascii?Q?RIHHu0ev+aFziI2nrI5+YkVmVIp14xtxjQoKfc2RGGiEqv6n9D0Sfpv7JM/d?=
 =?us-ascii?Q?WTwsghLxWDarc73K9A394FBgoXh4ki3+Q+LzHRmDH2pDDveNOhzOU2n7uldi?=
 =?us-ascii?Q?YQGGLYn1mAv5ZTbkn0ffpHRJsuPhlkf80peVwfFdqu6UT4OFy1b1oa5B18qI?=
 =?us-ascii?Q?16QKTXPcxFiZrp6kW5t4u8oFKS8u0B2P/R8RgurKLUzW04pDYV/QUnX6pJGy?=
 =?us-ascii?Q?LsIleDRSeeCX7Brk4CrU6yScpTDcshFXmZjArKLhajhauP6nceHY+UyKtok9?=
 =?us-ascii?Q?4xXWGXQJ6LKrOCzip3uoaoE9QxVTfYjLfv3ok7czKNiRvWMZdcwy4TmmhItZ?=
 =?us-ascii?Q?BkrxQ+OfiBwlXMMXAa4QYg6xjfydKbsP8sjkSOvRbrCLByHPtxOrB2PeZM48?=
 =?us-ascii?Q?JP1UJ97xOy38C1NGUkDigKv1adevdJUiryeaZwb5w7quAVwG3/tVGG1tTJNn?=
 =?us-ascii?Q?0T9/IU214Xqt5hTFu29ZdGBgasmeVhuIYdhA8dAqAvuskzygbYv9F8xvXQOE?=
 =?us-ascii?Q?FibmCABz9tqMONhaNF8ccTxrc5lHqbX3HoG2xbR0w4XPfsmj89uae7iloLdN?=
X-MS-Exchange-AntiSpam-MessageData-1: Fet2HLd2qWD2jw==
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: 04305166-0107-4358-fbf3-08df019a94ea
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2026 04:45:54.7298
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: FOBEvTsCxCuL3DeUj2WspNYBRB099EQBiyz8OPNIxB2/9MnVXiNvRWqr3MqLGMbGiP/aJX17GJ/iWrijifbDlQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB4363
X-purgate-ID: tlsNG-bad1c0/1787546760-3BED6034-5F20EA84/0/0
X-purgate-type: clean
X-purgate-size: 12645

On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
causes the domain to probe advanced PMU feature based on system ID
register ID_AA64DFR0_EL1. During this probe, Linux accesses PMMIR_EL1,
which causes unhandled register traps and crashes the domain.

To address this issue, implement the following:

- Add emulation for ID_AA64DFR{0,1}_EL1, ID_DFR{0,1}_EL1 and
  ID_DFR{0,1} register accesses for guest domains.
- Hide PMU registers from a guest domain when its vPMU feature is
  disabled.
- Proactively make SPE, TRBE, BRBE, Trace Extensions and ITE
  inaccessible to arm64 guest domains and hide TraceFilt, MMapTrc
  and CopTrc to arm32 guest domains, as they could potentially cause
  similar issues.

Fixes: dbb948110a0e ("xen: Expose the PMU to the guests")
Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
Fixes: 3669a1cb9598 ("xen/arm: create a cpuinfo structure for guest")
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
---
Changes in v3:
 * Mask PMU-related fields in ID_AA64DFR1_EL1 and ID_DFR1 when a guest
   domain lacks the vPMU feature.
 * Add emulation for AArch32 PMMIR register accesses performed by
   32-bit guest domains without the vPMU feature.
 * Code cleanups.

Note: The combination of AArch32 EL1 and PMUv3 could not be verified,
      as no real ARM CPU implements both while the Arm Architecture
      Reference Manual for A-profile architecture allows it.


 xen/arch/arm/arm64/vsysreg.c          | 74 +++++++++++++++++++++++++--
 xen/arch/arm/cpufeature.c             | 14 +++++
 xen/arch/arm/domain.c                 |  2 +-
 xen/arch/arm/include/asm/arm64/hsr.h  |  1 +
 xen/arch/arm/include/asm/cpregs.h     |  1 +
 xen/arch/arm/include/asm/cpufeature.h | 27 +++++++---
 xen/arch/arm/vcpreg.c                 | 33 +++++++++++-
 xen/include/xen/sched.h               |  5 ++
 8 files changed, 143 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index d9e3619dfb..1d1f7b0631 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -227,6 +227,11 @@ void do_sysreg(struct cpu_user_regs *regs,
      */
     case HSR_SYSREG_PMINTENSET_EL1:
     case HSR_SYSREG_PMINTENCLR_EL1:
+    case HSR_SYSREG_PMMIR_EL1:
+        /*
+         * Accessible from EL1 only, but if EL0 trap happens handle as
+         * undef.
+         */
         return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
     case HSR_SYSREG_PMUSERENR_EL0:
         /* RO at EL0. RAZ/WI at EL1 */
@@ -300,8 +305,36 @@ void do_sysreg(struct cpu_user_regs *regs,
     GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
     GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
     GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
-    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
-    GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
+
+    case HSR_SYSREG_ID_DFR0_EL1:
+    {
+        struct domain *d = v->domain;
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(d) )
+        {
+            info_dbg32.perfmon = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[0]);
+    }
+
+    case HSR_SYSREG_ID_DFR1_EL1:
+    {
+        struct domain *d = v->domain;
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(d) )
+        {
+            info_dbg32.mtpmu = 0;
+            info_dbg32.hpmn0 = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[1]);
+    }
+
     GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
     GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
     GENERATE_TID3_INFO(ID_MMFR1_EL1, mm32, 1)
@@ -342,8 +375,41 @@ void do_sysreg(struct cpu_user_regs *regs,
     }
 
     GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
-    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
-    GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
+
+    case HSR_SYSREG_ID_AA64DFR0_EL1:
+    {
+        struct domain *d = v->domain;
+        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
+
+        if ( !is_vpmu_domain(d) )
+        {
+            info_dbg64.pmu_ver = 0;
+            info_dbg64.pmss = 0;
+            info_dbg64.mtpmu = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg64.bits[0]);
+    }
+
+    case HSR_SYSREG_ID_AA64DFR1_EL1:
+    {
+        struct domain *d = v->domain;
+        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
+
+        if ( !is_vpmu_domain(d) )
+        {
+            info_dbg64.syspmuid = 0;
+            info_dbg64.spmu = 0;
+            info_dbg64.pmicntr = 0;
+            info_dbg64.ebep = 0;
+            info_dbg64.dpfzs = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg64.bits[1]);
+    }
+
     GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
     GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
     GENERATE_TID3_INFO(ID_AA64MMFR0_EL1, mm64, 0)
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 94d14fb6a9..05f4d0f5df 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -219,8 +219,22 @@ static int __init create_domain_cpuinfo(void)
     domain_cpuinfo.isa64.api = 0;
     domain_cpuinfo.isa64.gpa = 0;
     domain_cpuinfo.isa64.gpi = 0;
+
+    /* Hide SPE, TRBE, BRBE, Trace Extensions and ITE */
+    domain_cpuinfo.dbg64.trace_ver = 0;
+    domain_cpuinfo.dbg64.pms_ver = 0;
+    domain_cpuinfo.dbg64.trace_filt = 0;
+    domain_cpuinfo.dbg64.trace_buffer = 0;
+    domain_cpuinfo.dbg64.ext_trc_buff = 0;
+    domain_cpuinfo.dbg64.brbe = 0;
+    domain_cpuinfo.dbg64.ite = 0;
 #endif
 
+    /* Hide Trace Extensions for AArch32 domain */
+    domain_cpuinfo.dbg32.coptrc = 0;
+    domain_cpuinfo.dbg32.mmaptrc = 0;
+    domain_cpuinfo.dbg32.tracefilt = 0;
+
     /* Hide AMU support */
 #ifdef CONFIG_ARM_64
     domain_cpuinfo.pfr64.amu = 0;
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index baa3a5d708..a739dd157e 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -501,7 +501,7 @@ int arch_vcpu_create(struct vcpu *v)
     v->arch.hcr_el2 = get_default_hcr_flags();
 
     v->arch.mdcr_el2 = HDCR_TDRA | HDCR_TDOSA | HDCR_TDA;
-    if ( !(v->domain->options & XEN_DOMCTL_CDF_vpmu) )
+    if ( !is_vpmu_domain(v->domain) )
         v->arch.mdcr_el2 |= HDCR_TPM | HDCR_TPMCR;
 
     if ( (rc = vcpu_vgic_init(v)) != 0 )
diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h
index 1495ccddea..ed18184cc7 100644
--- a/xen/arch/arm/include/asm/arm64/hsr.h
+++ b/xen/arch/arm/include/asm/arm64/hsr.h
@@ -84,6 +84,7 @@
 #define HSR_SYSREG_FAR_EL1        HSR_SYSREG(3,0,c6, c0,0)
 #define HSR_SYSREG_PMINTENSET_EL1 HSR_SYSREG(3,0,c9,c14,1)
 #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
+#define HSR_SYSREG_PMMIR_EL1      HSR_SYSREG(3,0,c9,c14,6)
 #define HSR_SYSREG_MAIR_EL1       HSR_SYSREG(3,0,c10,c2,0)
 #define HSR_SYSREG_AMAIR_EL1      HSR_SYSREG(3,0,c10,c3,0)
 #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
index a7503a190f..e03218b51e 100644
--- a/xen/arch/arm/include/asm/cpregs.h
+++ b/xen/arch/arm/include/asm/cpregs.h
@@ -246,6 +246,7 @@
 #define PMINTENSET      p15,0,c9,c14,1  /* Perf. Mon. Interrupt Enable Set Register */
 #define PMINTENCLR      p15,0,c9,c14,2  /* Perf. Mon. Interrupt Enable Clear Register */
 #define PMOVSSET        p15,0,c9,c14,3  /* Perf. Mon. Overflow Flag Status Set register */
+#define PMMIR           p15,0,c9,c14,6  /* Perf. Mon. Performance Monitors Machine Identification Register */
 
 /* CP15 CR10: */
 #define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index bf902a3970..c554686415 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -208,7 +208,7 @@ struct cpuinfo_arm {
         };
     } pfr64;
 
-    union {
+    union cpuinfo_dbg64 {
         register_t bits[2];
         struct {
             /* DFR0 */
@@ -216,19 +216,31 @@ struct cpuinfo_arm {
             unsigned long trace_ver:4;
             unsigned long pmu_ver:4;
             unsigned long brps:4;
-            unsigned long __res0:4;
+            unsigned long pmss:4;
             unsigned long wrps:4;
             unsigned long __res1:4;
             unsigned long ctx_cmps:4;
             unsigned long pms_ver:4;
             unsigned long double_lock:4;
             unsigned long trace_filt:4;
-            unsigned long __res2:4;
+            unsigned long trace_buffer:4;
             unsigned long mtpmu:4;
-            unsigned long __res3:12;
+            unsigned long brbe:4;
+            unsigned long ext_trc_buff:4;
+            unsigned long hpmn0:4;
 
             /* DFR1 */
-            unsigned long __res4:64;
+            unsigned long syspmuid:8;
+            unsigned long brps1:8;
+            unsigned long wrps1:8;
+            unsigned long ctx_cmps1:8;
+            unsigned long spmu:4;
+            unsigned long pmicntr:4;
+            unsigned long able:4;
+            unsigned long ite:4;
+            unsigned long ebep:4;
+            unsigned long dpfzs:4;
+            unsigned long abl_cmps:8;
         };
     } dbg64;
 
@@ -408,7 +420,7 @@ struct cpuinfo_arm {
         };
     } pfr32;
 
-    union {
+    union cpuinfo_dbg32 {
         register_t bits[2];
         struct {
             /* DFR0 */
@@ -426,7 +438,8 @@ struct cpuinfo_arm {
 
             /* DFR1 */
             unsigned long mtpmu:4;
-            unsigned long __res1:28;
+            unsigned long hpmn0:4;
+            unsigned long __res1:24;
 #ifdef CONFIG_ARM_64
             unsigned long __res2:32;
 #endif
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index 3205c7df46..a660cb0734 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -305,6 +305,7 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
     case HSR_CPREG32(PMXEVTYPER):
     case HSR_CPREG32(PMXEVCNTR):
     case HSR_CPREG32(PMOVSSET):
+    case HSR_CPREG32(PMMIR):
         /*
          * Accessible at EL0 only if PMUSERENR_EL0.EN is set. We
          * emulate that register as 0 above.
@@ -320,8 +321,36 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
     GENERATE_TID3_INFO(ID_PFR0, pfr32, 0)
     GENERATE_TID3_INFO(ID_PFR1, pfr32, 1)
     GENERATE_TID3_INFO(ID_PFR2, pfr32, 2)
-    GENERATE_TID3_INFO(ID_DFR0, dbg32, 0)
-    GENERATE_TID3_INFO(ID_DFR1, dbg32, 1)
+
+    case HSR_CPREG32(ID_DFR0):
+    {
+        struct domain *d = v->domain;
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(d) )
+        {
+            info_dbg32.perfmon = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[0]);
+    }
+
+    case HSR_CPREG32(ID_DFR1):
+    {
+        struct domain *d = v->domain;
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(d) )
+        {
+            info_dbg32.mtpmu = 0;
+            info_dbg32.hpmn0 = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[1]);
+    }
+
     GENERATE_TID3_INFO(ID_AFR0, aux32, 0)
     GENERATE_TID3_INFO(ID_MMFR0, mm32, 0)
     GENERATE_TID3_INFO(ID_MMFR1, mm32, 1)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index eef10c2ea2..e352e2b38e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1269,6 +1269,11 @@ static always_inline bool is_iommu_enabled(const struct domain *d)
     return evaluate_nospec(d->options & XEN_DOMCTL_CDF_iommu);
 }
 
+static inline bool is_vpmu_domain(const struct domain *d)
+{
+    return d->options & XEN_DOMCTL_CDF_vpmu;
+}
+
 #ifdef CONFIG_MEM_PAGING
 # define mem_paging_enabled(d) vm_event_check_ring((d)->vm_event_paging)
 #else
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 07:12:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 07:12:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398693.1634834 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyOqa-0003UV-NZ; Mon, 24 Aug 2026 07:11:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398693.1634834; Mon, 24 Aug 2026 07:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyOqa-0003UO-Kx; Mon, 24 Aug 2026 07:11:56 +0000
Received: by outflank-mailman (input) for mailman id 1398693;
 Mon, 24 Aug 2026 07:11:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dfaggioli@suse.com>) id 1wyOqZ-0003UI-Oy
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 07:11:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyOqX-00739i-Mb
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 09:11:53 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dfaggioli@suse.com>)
 id 6a8beeab-2eae-0a2a0a5409dd-0a2a4506b9cc-36
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 09:11:53 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dfaggioli@suse.com>)
 id 6a8beeb9-195a-0a2a45060019-c387df83dc70-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 09:11:53 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id D1CBB3E29;
 Mon, 24 Aug 2026 07:11:44 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 586D313332;
 Mon, 24 Aug 2026 07:11:44 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id vJsjErDui2poXQAAD6G6ig
 (envelope-from <dfaggioli@suse.com>); Mon, 24 Aug 2026 07:11:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787555509; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=jJ8qGw+agFErzPYv0YCncP3NT4a3nGW2CIWK9s/ZZZA=;
	b=rL+EL+MWW0IqpTQeWdQ4ZNoRkHYomq2i8Oftw0qi9rbBMWIhxtNVbAzEq74pc1b6zhWmuj
	PA4sTcxre9+SMbN2Thb0abFaGijHyDlL9GUcoVb8PxY9QUj8b9CrgFuCTz9IXoabZdgE/K
	vlk+xG5S2dFyDXHWwcjnDZylHh92Gp0=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=boEpiZM1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787555504; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:  content-transfer-encoding:content-transfer-encoding;
	bh=jJ8qGw+agFErzPYv0YCncP3NT4a3nGW2CIWK9s/ZZZA=;
	b=boEpiZM1/G7aZB5zrtrOnw9MYhMQ0hdQTmvI9rBARKvkdggVzCPo3HCtWWrp4OnI0R9kYu
	UBCDeyQ+qvFuihIErnJL0jUhpFhTIcQ7Hm6MCfSNRuVm8KLGlQdBfJYfQFWcSTWJVJSQk3
	310i8sSE8p0vDQRdtsIMLnrhkHsgWWI=
From: Dario Faggioli <dfaggioli@suse.com>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org,
	sstabellini@kernel.org,
	anthony@xenproject.org,
	edgar.iglesias@gmail.com,
	philmd@mailo.com,
	odaki@rsg.ci.i.u-tokyo.ac.jp,
	Dario Faggioli <dfaggioli@suse.com>
Subject: [RFC PATCH 0/1] hw/display/xenfb: always register vfb and allocate console early
Date: Mon, 24 Aug 2026 09:11:15 +0200
Message-ID: <20260824071116.935828-1-dfaggioli@suse.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:url,suse.com:mid,suse.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_CC(0.00)[lists.xenproject.org,kernel.org,xenproject.org,gmail.com,mailo.com,rsg.ci.i.u-tokyo.ac.jp,suse.com];
	MIME_TRACE(0.00)[0:+];
	TAGGED_RCPT(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_SEVEN(0.00)[8];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+]
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level: 
X-Rspamd-Queue-Id: D1CBB3E29
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-purgate-ID: tlsNG-16d1c6/1787555513-FD40B77B-B1E0AA59/0/0
X-purgate-type: clean
X-purgate-size: 2045

Hello,

We've been having an issue with Xen PV and PVH guests' console since:

https://bugzilla.suse.com/show_bug.cgi?id=1232712
https://lists.nongnu.org/archive/html/qemu-devel/2024-12/msg02294.html

Back then, until our QEMU 11.0 package, I "solved" it locally by reverting
these two commits:

6ece1df966 hw/xen: Register framebuffer backend via xen_backend_init()
e99441a379 ui/curses: Do not use console_select()

For the 11.1 package, I decided it was enough and finally managed to find
the time to investigate a bit more (and, yes, I know I should have done
this earlier, but never could... Sorry :-( ).

>From my debugging, these are the problems:

1. Commit 6ece1df966 restricted the vfb backend registration under an
   'if (vga_interface_type == VGA_XENFB)'. However, it can happen that the
   -vga parameter is just not provided (e.g., for PV and PVH guests) and the
   backend is never initialized.

2. Once the backend is registered, xenfb defers the QemuConsole creation to
   fb_initialise(). The VNC server, though, starts earlier, finds no active
   consoles, and binds to the dummy surface (black screen showing the message
   "This VM has no graphic display device"). Furthermore, since the removal
   of console_select(), such surface is never dropped for switching to the
   actual xenfb console.

I have drafted a patch to address both issues. It removes the
vga_interface_type check and moves qemu_graphic_console_create() to fb_init()
so the console is created "early enough".

I am sending this as an RFC because, although it fixes the problem in my
testing, I am no expert in the QEMU UI subsystem and I am not sure that these
are the correct and/or the best solutions.

I'm happy to try to come up and/or to test different approaches and/or patches.

Thanks and Regards,
Dario

Dario Faggioli (1):
  hw/display/xenfb: always register vfb and allocate console early

 hw/display/xenfb.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 07:12:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 07:12:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398697.1634843 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyOr6-0003sk-V4; Mon, 24 Aug 2026 07:12:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398697.1634843; Mon, 24 Aug 2026 07:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyOr6-0003sb-SY; Mon, 24 Aug 2026 07:12:28 +0000
Received: by outflank-mailman (input) for mailman id 1398697;
 Mon, 24 Aug 2026 07:12:28 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dfaggioli@suse.com>) id 1wyOr6-0003sR-Ba
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 07:12:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyOr5-000tfE-EU
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 09:12:27 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dfaggioli@suse.com>)
 id 6a8beeb9-8faa-0a2a0a5109dd-0a2a4501e50a-0
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 09:11:53 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dfaggioli@suse.com>)
 id 6a8beeb9-5984-0a2a45010019-c387df829436-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 09:11:53 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id 5E5D3865B9;
 Mon, 24 Aug 2026 07:11:45 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id DBDF013335;
 Mon, 24 Aug 2026 07:11:44 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id QDQDM7Dui2poXQAAD6G6ig
 (envelope-from <dfaggioli@suse.com>); Mon, 24 Aug 2026 07:11:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787555509; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=RQQzKc7fXgnyMVrT3Qi+0O4dsqzanUM4EfhHa4x9i88=;
	b=GRStE1zEjdoaZF7EeV1Qc7jRkK7AFsxQA8zdFSVrPuizxFKRrAFOHMrsza/kFNsjB79xxE
	JWtob8YtgEk2/+f8py9pZJf21SN362D2Bn2CJ2V6sRbyF0OlfhUzhq+tOwyXACWVqPx9uR
	06HjGZgDUwehZ+NfSocrJmxgXwu/2PI=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=Rp8Zz61W
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787555505; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=RQQzKc7fXgnyMVrT3Qi+0O4dsqzanUM4EfhHa4x9i88=;
	b=Rp8Zz61WHAlZSqPrBHhVp2p/cTyKMXbTTswW8U98VQ8PoqXtbEqdD2SPXx9rqtAGKRbO0F
	2t3vqe9Rrjo+QVmXF7QGBMVTSs4I5ZjQ2B4ECwskTSUdOX1qbCXwC1PtO565DKAo+RStmP
	xYPR1XbzwMgxVfg4/qLGwPTPBq2KlQM=
From: Dario Faggioli <dfaggioli@suse.com>
To: qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org,
	sstabellini@kernel.org,
	anthony@xenproject.org,
	edgar.iglesias@gmail.com,
	philmd@mailo.com,
	odaki@rsg.ci.i.u-tokyo.ac.jp,
	Dario Faggioli <dfaggioli@suse.com>
Subject: [RFC PATCH 1/1] hw/display/xenfb: always register vfb and allocate console early
Date: Mon, 24 Aug 2026 09:11:16 +0200
Message-ID: <20260824071116.935828-2-dfaggioli@suse.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <20260824071116.935828-1-dfaggioli@suse.com>
References: <20260824071116.935828-1-dfaggioli@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.51
X-Spam-Level: 
X-Rspamd-Action: no action
X-Rspamd-Queue-Id: 5E5D3865B9
X-Spamd-Result: default: False [-1.51 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SUSPICIOUS_RECIPS(1.50)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,suse.com:dkim];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_SEVEN(0.00)[8];
	FREEMAIL_CC(0.00)[lists.xenproject.org,kernel.org,xenproject.org,gmail.com,mailo.com,rsg.ci.i.u-tokyo.ac.jp,suse.com];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-purgate-ID: tlsNG-d62444/1787555513-BDC79757-20543C4E/0/0
X-purgate-type: clean
X-purgate-size: 2659

This commit addresses a black console issues for Xen PV and PVH guests.

In fact, commit 6ece1df966 ("hw/xen: Register framebuffer backend via
xen_backend_init()") introduced a check before registering the vfb
backend. Problem is that the '-vga' agrument may not be present (e.g.,
for PV/PVH guests started with 'xl') and this causes the backend to be
silently ignored.

This commit restores the unconditional registration of the vfb backend.

Furthermore, even with the backend always being registered, the fact
that xenfb allocates the QemuConsole asynchronously in fb_initialise()
looks problematic. In fact, when the UI initializes, it finds 0 active
consoles and it permanently allocates a dummy surface showing the
message "This VM has no graphic display device". And since the removal
of console_select() there's no way to dynamically switch to the xenfb
console, when it is finally up and running.

This commit works around the issue by moving console creation to
fb_init(), so that VNC attaches to it immediately. The surface is then
updated normally via qemu_console_set_surface() once the guest framebuffer
is mapped.

Fixes: 6ece1df966 ("hw/xen: Register framebuffer backend via xen_backend_init()")
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
 hw/display/xenfb.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index ae302b217f..3a0cdc0578 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -851,9 +851,14 @@ static void xenfb_handle_events(struct XenFB *xenfb)
 
 static int fb_init(struct XenLegacyDevice *xendev)
 {
+    struct XenFB *fb = container_of(xendev, struct XenFB, c.xendev);
+
 #ifdef XENFB_TYPE_RESIZE
     xenstore_write_be_int(xendev, "feature-resize", 1);
 #endif
+
+    fb->con = qemu_graphic_console_create(NULL, 0, &xenfb_ops, fb);
+
     return 0;
 }
 
@@ -882,8 +887,6 @@ static int fb_initialise(struct XenLegacyDevice *xendev)
     if (rc != 0)
         return rc;
 
-    fb->con = qemu_graphic_console_create(NULL, 0, &xenfb_ops, fb);
-
     if (xenstore_read_fe_int(xendev, "feature-update", &fb->feature_update) == -1)
         fb->feature_update = 0;
     if (fb->feature_update)
@@ -973,9 +976,6 @@ static const GraphicHwOps xenfb_ops = {
 static void xen_ui_register_backend(void)
 {
     xen_be_register("vkbd", &xen_kbdmouse_ops);
-
-    if (vga_interface_type == VGA_XENFB) {
-        xen_be_register("vfb", &xen_framebuffer_ops);
-    }
+    xen_be_register("vfb", &xen_framebuffer_ops);
 }
 xen_backend_init(xen_ui_register_backend);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 07:41:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 07:41:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398707.1634852 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyPJB-0007uv-40; Mon, 24 Aug 2026 07:41:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398707.1634852; Mon, 24 Aug 2026 07:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyPJB-0007uo-1N; Mon, 24 Aug 2026 07:41:29 +0000
Received: by outflank-mailman (input) for mailman id 1398707;
 Mon, 24 Aug 2026 07:41:28 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wyPJA-0007ui-2W
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 07:41:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyPJ8-005XZj-Ox
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 09:41:26 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8bf592-e002-0a2a0a5209dd-0a2a4504afb0-38
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 09:41:26 +0200
Received: from [209.85.208.50] (helo=mail-ed1-f50.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8bf5a6-b57f-0a2a45040019-d155d032c45a-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 09:41:26 +0200
Received: by mail-ed1-f50.google.com with SMTP id
 4fb4d7f45d1cf-6a18840e2abso5436018a12.0
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 00:41:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a59dd550bcsm7944233a12.0.2026.08.24.00.41.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 24 Aug 2026 00:41:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787557286; x=1788162086; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=6FjKIhLvuDC2eEldBE9utv0h1r0RkC7q9zuRaTDtrKA=;
        b=NuY+TVbKpa9t11DlzV2khy6j8ZO9QGmS9vnia8+X7VJQzXOaiDlschqoK1/IEzdZNh
         /2KfUwtF7szoTRQ0b7S+QHPX1P1wFkKyRLvuD2UnFA8DmM5XOSP3n4JwAOW4dYMxrCke
         ZHYI6fbquyCJTFWy7vm5CFGihpOBrvU6RiiwcaFRALuCtKF7oW+ESnmQF5G5Z++9H1Ef
         sipEBMWceXZfrvdrka5/Ca1M5Ex/TFxRvRy15kUC9jnUMIOrJWh6V0122YafYWc4OIxU
         OwSCTI3U5r34j6RI3513I8qpo2EbiGtJAVIkaWiCHwNnWhPAOajkvDuiOvpSkXRLbCg0
         QyeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787557286; x=1788162086;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=6FjKIhLvuDC2eEldBE9utv0h1r0RkC7q9zuRaTDtrKA=;
        b=Yr7Y6A8TBKypbcfmWpyypGbIYZybKOt9h5JOg1raqbvujk1aB7/aapR5Yzov3DlcCY
         FvAVPnNsaqDFV/XNtBL0kXywE2oRn3BVdzUd5/4QE4y0lKvNxfgqADeEHbgPRWsRyDFg
         O25WjZ5R0AVy6yrhWsW3nsA5bQ5b9jVfm8H2NEXi8C7N3RXA1q52nr74wSXFzt3fAlcA
         MJ0A7Ksibr2ZuAD5eypsWUTj1WsolVpkcjKnqPjsUf5YMTz1RCxoCYtoXs8bDOjhWzJ2
         iAeCI9cBttokRxs0pETHCwwSts1HnOHeoxMjuodREsslUwoCTNYM7bRkq8ahFHCrtiBR
         mUYg==
X-Gm-Message-State: AFuF++mwlJj6qFOFDM7cUxWofGwjlAnwhIcO3kYQtPK/ABoRE8uBsyI2
	Rl3JYJ4qsvzfImdvHgFPQ0fbOu0quLOSYfqZo2hQV4lOnT0iXsDTVklzJD+OPEAoUs9MzTEZd+F
	UCfiBdA==
X-Gm-Gg: AR+sD13TGCDg8X5FQp82jooOjTCWMlYRleAy/aR/n++zjao0yWXmL4B24mtjjTSMBix
	28HdnokgK265wkTFxDyxrjzMBAgzwNIHDKpeFeg6VnlEMQu4CR+QsQ2YPcG8DyzVQvTfSoMHaoc
	qekRn091RYR0Aye7w9XMBZbMLH8/p+pF2He+ET7WcRf8sQb0WKkro6AwSiaooGpPAU3jyflU4ox
	eiPYmqW2ZHGd8lkGSXzz6zaJ4F9eUi1EWjVHeMwMM+gffrLFpIGfRo34Gqw7rpndiqKJQ237CPs
	ifPGigwAYFwExPV+O4uNC8+8HIk9wvYfpehQz+YLZDod4tdrzkygJsrTeKNiAho1boMJr5FKCuJ
	UyaxzkJQmY9OZ0ajbsjtscEoUxQ1gNlqzPAQ0yPO5OHk2tyUhXuhfrqYHjFGZaHRpBO5sEOZb9I
	IOB7d+TcqRJFS9CaWmhGEBJCG1gVTf6xz7NBzRgtZAatDcfN52HtLpKcP5CBxI1EW+R+sZuKfaZ
	ak6dtMawP4kW6+gfX01c2vqyCxwsstd+XTOEaceSEQ8hz4zmKuk
X-Received: by 2002:a05:6402:4342:b0:6a3:f8ab:19f7 with SMTP id 4fb4d7f45d1cf-6a582b7d8b0mr19827503a12.11.1787557286102;
        Mon, 24 Aug 2026 00:41:26 -0700 (PDT)
Message-ID: <d3d188c2-32c5-45ee-9b10-1f4ee1b85c6e@suse.com>
Date: Mon, 24 Aug 2026 09:41:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Andrew Mbugua <andrewprecious388@gmail.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86emul/fuzz: sanitize CR4 values
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787557286-C30CDB50-8A834B66/0/0
X-purgate-type: clean
X-purgate-size: 5663

While the CPU policy is obtained from hardware, the CRn values to start
with are taken from fuzzed input. Since most CR4 bits can only be set when
the respective feature is indicated as available by CPUID, the emulator
often only checks the CR4 bit. Without sanitization, assertions like the
one in emul_test_read_xcr() (checking XSAVE support) could therefore
trigger.

Omit most paging-only bits from sanitization, as the core emulator doesn't
itself walk page tables. LA57 wants checking for the bit being used by
CANONICALIZE_MAYBE().

Reported-by: Andrew Mbugua <andrewprecious388@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
For this to have the overall intended effect, the previously submitted
https://lists.xen.org/archives/html/xen-devel/2026-08/msg01018.html
also need including.

UINTR is omitted, as the feature reportedly is about to be deprecated by
Intel, and hence we may never add support for it to the emulator. (We also
don't have X86_CR4_UINTR in x86-defns.h.)

Checks like the one for VMXE, SMXE, CET, and FRED are forward-looking, as
the emulator is yet to gain support for those.

--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -825,6 +825,58 @@ static void sanitize_input(struct x86_em
     regs->entry_vector = 0;
 
     /*
+     * Most CR4 bits can only be set when corresponding CPUID bits are set.
+     * (In such cases the emulator may only check the CR4 bit.)
+     */
+    if ( !cpu_policy.basic.vme )
+        c->cr[4] &= ~(X86_CR4_VME | X86_CR4_PVI);
+
+    if ( !cpu_policy.basic.tsc )
+        c->cr[4] &= ~X86_CR4_TSD;
+
+    if ( !cpu_policy.basic.de )
+        c->cr[4] &= ~X86_CR4_DE;
+
+    if ( !cpu_policy.basic.fxsr )
+        c->cr[4] &= ~X86_CR4_OSFXSR;
+
+    if ( !cpu_policy.basic.sse )
+        c->cr[4] &= ~X86_CR4_OSXMMEXCPT;
+
+    if ( !cpu_policy.feat.umip )
+        c->cr[4] &= ~X86_CR4_UMIP;
+
+    if ( !cpu_policy.feat.la57 )
+        c->cr[4] &= ~X86_CR4_LA57;
+
+    if ( !cpu_policy.basic.vmx )
+        c->cr[4] &= ~X86_CR4_VMXE;
+
+    if ( !cpu_policy.basic.smx )
+        c->cr[4] &= ~X86_CR4_SMXE;
+
+    if ( !cpu_policy.feat.fsgsbase )
+        c->cr[4] &= ~X86_CR4_FSGSBASE;
+
+    if ( !cpu_policy.basic.pcid )
+        c->cr[4] &= ~X86_CR4_PCIDE;
+
+    if ( !cpu_policy.basic.xsave || !cpu_has_xsave )
+        c->cr[4] &= ~X86_CR4_OSXSAVE;
+
+    if ( !cpu_policy.feat.pku )
+        c->cr[4] &= ~X86_CR4_PKE;
+
+    if ( !cpu_policy.feat.cet_ss && !cpu_policy.feat.cet_ibt )
+        c->cr[4] &= ~X86_CR4_CET;
+
+    if ( !cpu_policy.feat.pks )
+        c->cr[4] &= ~X86_CR4_PKS;
+
+    if ( !cpu_policy.feat.fred )
+        c->cr[4] &= ~X86_CR4_FRED;
+
+    /*
      * For both RIP and RSP make sure we test with canonical values in at
      * least a fair number of cases. As all other registers aren't tied to
      * special addressing purposes, leave everything else alone.
@@ -839,10 +891,14 @@ static void sanitize_input(struct x86_em
     if ( c->cr[0] & X86_CR0_PG )
         c->cr[0] |= X86_CR0_PE;
 
-    /* EFLAGS.VM not available in long mode */
+    /* EFLAGS.VM not available in long mode, but CR4.PAE is required. */
     if ( long_mode_active(ctxt) )
+    {
         regs->rflags &= ~X86_EFLAGS_VM;
 
+        c->cr[4] |= X86_CR4_PAE;
+    }
+
     /* EFLAGS.VM implies 16-bit mode */
     if ( regs->rflags & X86_EFLAGS_VM )
     {
@@ -862,12 +918,63 @@ static bool check_state(struct x86_emula
     const struct fuzz_corpus *c = s->corpus;
     const struct cpu_user_regs *regs = &c->regs;
 
-    if ( long_mode_active(ctxt) && !(c->cr[0] & X86_CR0_PG) )
+    if ( long_mode_active(ctxt) &&
+         (!(c->cr[0] & X86_CR0_PG) || !(c->cr[4] & X86_CR4_PAE)) )
         return false;
 
     if ( (c->cr[0] & X86_CR0_PG) && !(c->cr[0] & X86_CR0_PE) )
         return false;
 
+    if ( (c->cr[4] & (X86_CR4_VME | X86_CR4_PVI)) && !cpu_policy.basic.vme )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_TSD) && !cpu_policy.basic.tsc )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_DE) && !cpu_policy.basic.de )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_OSFXSR) && !cpu_policy.basic.fxsr )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_OSXMMEXCPT) && !cpu_policy.basic.sse )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_UMIP) && !cpu_policy.feat.umip )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_LA57) && !cpu_policy.feat.la57 )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_VMXE) && !cpu_policy.basic.vmx )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_SMXE) && !cpu_policy.basic.smx )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_FSGSBASE) && !cpu_policy.feat.fsgsbase )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_PCIDE) && !cpu_policy.basic.pcid )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_OSXSAVE) &&
+         (!cpu_policy.basic.xsave || !cpu_has_xsave) )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_PKE) && !cpu_policy.feat.pku )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_CET) &&
+         !cpu_policy.feat.cet_ss && !cpu_policy.feat.cet_ibt )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_PKS) && !cpu_policy.feat.pks )
+        return false;
+
+    if ( (c->cr[4] & X86_CR4_FRED) && !cpu_policy.feat.fred )
+        return false;
+
     if ( (regs->rflags & X86_EFLAGS_VM) &&
          (c->segments[x86_seg_cs].db || c->segments[x86_seg_ss].db) )
         return false;


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 08:32:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 08:32:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398727.1634862 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyQ6Y-0006NU-2v; Mon, 24 Aug 2026 08:32:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398727.1634862; Mon, 24 Aug 2026 08:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyQ6Y-0006NN-0F; Mon, 24 Aug 2026 08:32:30 +0000
Received: by outflank-mailman (input) for mailman id 1398727;
 Mon, 24 Aug 2026 08:32:27 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wyQ6V-0006NH-JZ
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 08:32:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyQ6U-009yh5-I9
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 10:32:26 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8c018c-8faa-0a2a0a5109dd-0a2a4503d2e4-40
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 10:32:26 +0200
Received: from [40.93.195.68]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8c0197-fae8-0a2a45030019-285dc3446c73-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 10:32:25 +0200
Received: from MW4PR03CA0230.namprd03.prod.outlook.com (2603:10b6:303:b9::25)
 by PH7PR12MB7116.namprd12.prod.outlook.com (2603:10b6:510:1ef::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 08:32:15 +0000
Received: from CO1PEPF000075F0.namprd03.prod.outlook.com
 (2603:10b6:303:b9:cafe::13) by MW4PR03CA0230.outlook.office365.com
 (2603:10b6:303:b9::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.12 via Frontend Transport; Mon,
 24 Aug 2026 08:32:15 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CO1PEPF000075F0.mail.protection.outlook.com (10.167.249.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Mon, 24 Aug 2026 08:32:14 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 24 Aug
 2026 03:32:13 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 24 Aug
 2026 03:32:07 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 24 Aug 2026 03:32:05 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RWi1OV5B5b6GMqyGJJUp4MK+pMuLh2kc2lJOnB5iEbDd9lxShiqcWuhtpji9R0t/iVAFXWvk2lgtdHsbxjJHIhve52+PxkfsN0su6VgWGEgZ+uQvmQ3wdpM7pCq0VfIjNfNKW7U/WZcRwUynblnqjoOSLVJxEP7m9th7OPJJxdFYPeAqah/L/8w5j89r7gzHy7CG65+eEv8NMLJYlsesnSjB2fUFM1hy1NEjXirPZaY9+RLryQrMnoQ/VRsRaXOimrHwDTqmEH7066Li7vLzhPunbxt2+0Ka/0ce/HfeuFwbgxpo5TARJdOGCsm/Lxn3gm2yUnufJ/pn/gDr38voDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rXv1eM1QauodCGZrPbnY9WZ44vQeU7Ima24VUPC+cDQ=;
 b=NCSVraOmpUcjb3jU2yg0aEktxs+5cbKflEb17yRgWK32ibwMDbe5kSZabi5WCKkLteJ1k4dBEwFztGns+MHuzoN4sxV6LQcCyzYdq3/ZEEMgJXEVjvdr27GxO0HTKRHs+CiBn4mNZv5VLecWBWoXTOPnCBaVQXD32THM7qpTMbVn8CvBHJ9Hts4+RN2FZMANl64i2t9I/oIN6q6zJV7qr7vKmQYtXhp4GyUrrtY6vfF1F5qHwbCTwwejBTk5kVRIGQu8wr9+aGYLLRcg+kLGCD8LYK84NuwL8PndT84CEXO86G0p4yysBaKHS6UsqERItX4beQaUIroS91QQGc5n9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=valinux.co.jp smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rXv1eM1QauodCGZrPbnY9WZ44vQeU7Ima24VUPC+cDQ=;
 b=Q5L1X1ou+moqfb/wbhekeADMYSnCbI1QyMwNFvdCMIttIsgvaqz+ZkHe/Fs2KwzNd7XplxDK05r/xzSxmAo706QalMqq2xjkzWTlGgmkenANAU1mmzFSUsinLTrKG2pVEBPVlOn3ns/GCoKbShuisR+f74Co8RgKjwxWFHAevNo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <e6edf3f8-5085-4b5b-acdb-ac17402e86ee@amd.com>
Date: Mon, 24 Aug 2026 10:32:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
To: Hirokazu Takahashi <taka@valinux.co.jp>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger@xenproject.org>
References: <20260824044530.301938-1-taka@valinux.co.jp>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260824044530.301938-1-taka@valinux.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000075F0:EE_|PH7PR12MB7116:EE_
X-MS-Office365-Filtering-Correlation-Id: 00cf9173-cdf8-4dd7-f566-08df01ba3371
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|36860700016|23010399003|7416014|376014|56012099006|10067099003|11063799006|6133799003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	oOHUi+jRIadxIEkGqsV1NalaV0rd3I2BcV0iSUptn3y+zkB1dLz+YxwrzouK7QHrjkrDfApquYodGkFvC+MnOUe4s8ER+mqW0gvrpjKxrPWJHMx7NBkESFz2SmUU7wJnOUSBMZxQx+DX8jyrObB0CvHKchBz0qb1tfIJXLrDjKiF8rt/4MTlfUgXcxcdMZjOuWOgb8nQ1ZUrfsY8LoDjFSu9k5PGHC+3g4MbBwl4aB4Samu4Hz7V3jr3ad28A4ovA6DvwxGkjTIGDeCu0/++PtI28mJCiTQHQkd5XVMpZ48j73WAtow63frvANdGBfT7lTRAKeYz+UA7r0reA1fT9XZyBwIVmBHOhujiIJ2bw2y84IO6tzVRXHzkLUzKK/2+SlcLQH2Pq8/ldhyVW8+HAioyPKUmHXD0Zd5jKMCE7bu15i/FT8tGWcZB3COqVwhrMucjulNuHJt+P1VAmSPlJvRzL7pITfxGdLfp50wGGShrJq6E4vhzaukXtggBa8+q4nCcij++IYyzVqlQ+sWb0HOG+t4I5WzZQ2iHH5KNqsD1gvF1hZ8SnnMI27luVDFd9FJe/ISAWYBpwHt5WJ5vaHmy8+AcVaLVP6RD2mdskU/nI0YYQ7QMS6zvXm8IsemXfeLRXouwBB5z4T+OG0URLeK/oetcPGVrYXFvoRQG/wMD45S8pfXRaCqgISngLJqiyVsNj0FR1XrdvECE8hAOYw==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(23010399003)(7416014)(376014)(56012099006)(10067099003)(11063799006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Tv4C2vpFe1ri8afLd/F85PRdba1vPW2cV34hqnaozsjQBnKBprpVEV5LuQiUQNT9T9cZ7GyUCQWXFutTdvrlFsRPu67DyJdQ5fmK73HGVTrqXEpa3mH+xCrXGU/L2ZXIy4u3tJBrTPbjVG2+Qw77iTZKKkGWEcD1TNSi6D6MhDNnkA9oSf04N2J2depOxh5I4KT8rj7q3STrWAz9H/hhdRQjbO0ng4ul6hVKzjL6OMbd+dDqBkwTBmElp/QZhwkhc/sFhTKpgzfajAQZLp26gCggPpY1D3A1GE0zkovNp8u7AqNdZVeB7nIrklnaQuRakwdmtrRhUFWal9Dpu0g7/BeBVD5FfNmuesoIkgJUmpwD52EdZX7GeuoDBHVqqOKPUffSIXXy2z3EHvvjXp0qTBAIt9du6phtAblXJRAzFGTygTW0gKnoJgeChbR35bmO
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2026 08:32:14.7697
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 00cf9173-cdf8-4dd7-f566-08df01ba3371
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000075F0.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7116
X-purgate-ID: tlsNG-33051d/1787560345-772F54E9-02004E2F/0/0
X-purgate-type: clean
X-purgate-size: 14154



On 24-Aug-26 06:45, Hirokazu Takahashi wrote:
> On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
> causes the domain to probe advanced PMU feature based on system ID
> register ID_AA64DFR0_EL1. During this probe, Linux accesses PMMIR_EL1,
> which causes unhandled register traps and crashes the domain.
> 
> To address this issue, implement the following:
> 
> - Add emulation for ID_AA64DFR{0,1}_EL1, ID_DFR{0,1}_EL1 and
>   ID_DFR{0,1} register accesses for guest domains.
> - Hide PMU registers from a guest domain when its vPMU feature is
>   disabled.
> - Proactively make SPE, TRBE, BRBE, Trace Extensions and ITE
>   inaccessible to arm64 guest domains and hide TraceFilt, MMapTrc
>   and CopTrc to arm32 guest domains, as they could potentially cause
>   similar issues.
> 
> Fixes: dbb948110a0e ("xen: Expose the PMU to the guests")
> Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
> Fixes: 3669a1cb9598 ("xen/arm: create a cpuinfo structure for guest")
> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
> ---
> Changes in v3:
>  * Mask PMU-related fields in ID_AA64DFR1_EL1 and ID_DFR1 when a guest
>    domain lacks the vPMU feature.
>  * Add emulation for AArch32 PMMIR register accesses performed by
>    32-bit guest domains without the vPMU feature.
>  * Code cleanups.
> 
> Note: The combination of AArch32 EL1 and PMUv3 could not be verified,
>       as no real ARM CPU implements both while the Arm Architecture
>       Reference Manual for A-profile architecture allows it.
> 
> 
>  xen/arch/arm/arm64/vsysreg.c          | 74 +++++++++++++++++++++++++--
>  xen/arch/arm/cpufeature.c             | 14 +++++
>  xen/arch/arm/domain.c                 |  2 +-
>  xen/arch/arm/include/asm/arm64/hsr.h  |  1 +
>  xen/arch/arm/include/asm/cpregs.h     |  1 +
>  xen/arch/arm/include/asm/cpufeature.h | 27 +++++++---
>  xen/arch/arm/vcpreg.c                 | 33 +++++++++++-
>  xen/include/xen/sched.h               |  5 ++
>  8 files changed, 143 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index d9e3619dfb..1d1f7b0631 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -227,6 +227,11 @@ void do_sysreg(struct cpu_user_regs *regs,
>       */
>      case HSR_SYSREG_PMINTENSET_EL1:
>      case HSR_SYSREG_PMINTENCLR_EL1:
> +    case HSR_SYSREG_PMMIR_EL1:
> +        /*
> +         * Accessible from EL1 only, but if EL0 trap happens handle as
> +         * undef.
> +         */
This comment was recently removed, so please do not re-introduce it.

>          return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
>      case HSR_SYSREG_PMUSERENR_EL0:
>          /* RO at EL0. RAZ/WI at EL1 */
> @@ -300,8 +305,36 @@ void do_sysreg(struct cpu_user_regs *regs,
>      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
>      GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
>      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
> -    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
> -    GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
> +
> +    case HSR_SYSREG_ID_DFR0_EL1:
> +    {
> +        struct domain *d = v->domain;
There is no need for a separate local variable if it's only used once. In this
series, please just use `v->domain` for `is_vpmu_domain()`.

> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !is_vpmu_domain(d) )
> +        {
Please omit the braces for a single line `if` block.

> +            info_dbg32.perfmon = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg32.bits[0]);
> +    }
> +
> +    case HSR_SYSREG_ID_DFR1_EL1:
> +    {
> +        struct domain *d = v->domain;
> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !is_vpmu_domain(d) )
> +        {
> +            info_dbg32.mtpmu = 0;
> +            info_dbg32.hpmn0 = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg32.bits[1]);
> +    }
> +
>      GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
>      GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
>      GENERATE_TID3_INFO(ID_MMFR1_EL1, mm32, 1)
> @@ -342,8 +375,41 @@ void do_sysreg(struct cpu_user_regs *regs,
>      }
>  
>      GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
> -    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
> -    GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
> +
> +    case HSR_SYSREG_ID_AA64DFR0_EL1:
> +    {
> +        struct domain *d = v->domain;
> +        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
> +
> +        if ( !is_vpmu_domain(d) )
> +        {
> +            info_dbg64.pmu_ver = 0;
> +            info_dbg64.pmss = 0;
> +            info_dbg64.mtpmu = 0;
Why don't you clear hpmn0?

> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg64.bits[0]);
> +    }
> +
> +    case HSR_SYSREG_ID_AA64DFR1_EL1:
> +    {
> +        struct domain *d = v->domain;
> +        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
> +
> +        if ( !is_vpmu_domain(d) )
> +        {
> +            info_dbg64.syspmuid = 0;
> +            info_dbg64.spmu = 0;
System PMU accesses undef for a vPMU-enabled domain too. Clear them together
with SPE, TRBE, etc.

> +            info_dbg64.pmicntr = 0;
> +            info_dbg64.ebep = 0;
FEAT_EBEP is Armv9 just like SEBEP, so you should apply my comments to it as well.

> +            info_dbg64.dpfzs = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg64.bits[1]);
> +    }
> +
>      GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
>      GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
>      GENERATE_TID3_INFO(ID_AA64MMFR0_EL1, mm64, 0)
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 94d14fb6a9..05f4d0f5df 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -219,8 +219,22 @@ static int __init create_domain_cpuinfo(void)
>      domain_cpuinfo.isa64.api = 0;
>      domain_cpuinfo.isa64.gpa = 0;
>      domain_cpuinfo.isa64.gpi = 0;
> +
> +    /* Hide SPE, TRBE, BRBE, Trace Extensions and ITE */
> +    domain_cpuinfo.dbg64.trace_ver = 0;
> +    domain_cpuinfo.dbg64.pms_ver = 0;
> +    domain_cpuinfo.dbg64.trace_filt = 0;
> +    domain_cpuinfo.dbg64.trace_buffer = 0;
> +    domain_cpuinfo.dbg64.ext_trc_buff = 0;
> +    domain_cpuinfo.dbg64.brbe = 0;
> +    domain_cpuinfo.dbg64.ite = 0;
>  #endif
>  
> +    /* Hide Trace Extensions for AArch32 domain */
> +    domain_cpuinfo.dbg32.coptrc = 0;
> +    domain_cpuinfo.dbg32.mmaptrc = 0;
> +    domain_cpuinfo.dbg32.tracefilt = 0;
> +
>      /* Hide AMU support */
>  #ifdef CONFIG_ARM_64
>      domain_cpuinfo.pfr64.amu = 0;
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index baa3a5d708..a739dd157e 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -501,7 +501,7 @@ int arch_vcpu_create(struct vcpu *v)
>      v->arch.hcr_el2 = get_default_hcr_flags();
>  
>      v->arch.mdcr_el2 = HDCR_TDRA | HDCR_TDOSA | HDCR_TDA;
> -    if ( !(v->domain->options & XEN_DOMCTL_CDF_vpmu) )
> +    if ( !is_vpmu_domain(v->domain) )
>          v->arch.mdcr_el2 |= HDCR_TPM | HDCR_TPMCR;
>  
>      if ( (rc = vcpu_vgic_init(v)) != 0 )
> diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h
> index 1495ccddea..ed18184cc7 100644
> --- a/xen/arch/arm/include/asm/arm64/hsr.h
> +++ b/xen/arch/arm/include/asm/arm64/hsr.h
> @@ -84,6 +84,7 @@
>  #define HSR_SYSREG_FAR_EL1        HSR_SYSREG(3,0,c6, c0,0)
>  #define HSR_SYSREG_PMINTENSET_EL1 HSR_SYSREG(3,0,c9,c14,1)
>  #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
> +#define HSR_SYSREG_PMMIR_EL1      HSR_SYSREG(3,0,c9,c14,6)
>  #define HSR_SYSREG_MAIR_EL1       HSR_SYSREG(3,0,c10,c2,0)
>  #define HSR_SYSREG_AMAIR_EL1      HSR_SYSREG(3,0,c10,c3,0)
>  #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index a7503a190f..e03218b51e 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -246,6 +246,7 @@
>  #define PMINTENSET      p15,0,c9,c14,1  /* Perf. Mon. Interrupt Enable Set Register */
>  #define PMINTENCLR      p15,0,c9,c14,2  /* Perf. Mon. Interrupt Enable Clear Register */
>  #define PMOVSSET        p15,0,c9,c14,3  /* Perf. Mon. Overflow Flag Status Set register */
> +#define PMMIR           p15,0,c9,c14,6  /* Perf. Mon. Performance Monitors Machine Identification Register */
Please drop "Performance Monitors". It's the same as "Perf. Mon".

>  
>  /* CP15 CR10: */
>  #define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index bf902a3970..c554686415 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -208,7 +208,7 @@ struct cpuinfo_arm {
>          };
>      } pfr64;
>  
> -    union {
> +    union cpuinfo_dbg64 {
>          register_t bits[2];
>          struct {
>              /* DFR0 */
> @@ -216,19 +216,31 @@ struct cpuinfo_arm {
>              unsigned long trace_ver:4;
>              unsigned long pmu_ver:4;
>              unsigned long brps:4;
> -            unsigned long __res0:4;
> +            unsigned long pmss:4;
>              unsigned long wrps:4;
>              unsigned long __res1:4;
>              unsigned long ctx_cmps:4;
>              unsigned long pms_ver:4;
>              unsigned long double_lock:4;
>              unsigned long trace_filt:4;
> -            unsigned long __res2:4;
> +            unsigned long trace_buffer:4;
>              unsigned long mtpmu:4;
> -            unsigned long __res3:12;
> +            unsigned long brbe:4;
> +            unsigned long ext_trc_buff:4;
> +            unsigned long hpmn0:4;
>  
>              /* DFR1 */
> -            unsigned long __res4:64;
> +            unsigned long syspmuid:8;
> +            unsigned long brps1:8;
> +            unsigned long wrps1:8;
> +            unsigned long ctx_cmps1:8;
> +            unsigned long spmu:4;
> +            unsigned long pmicntr:4;
> +            unsigned long able:4;
> +            unsigned long ite:4;
> +            unsigned long ebep:4;
> +            unsigned long dpfzs:4;
> +            unsigned long abl_cmps:8;
>          };
>      } dbg64;
>  
> @@ -408,7 +420,7 @@ struct cpuinfo_arm {
>          };
>      } pfr32;
>  
> -    union {
> +    union cpuinfo_dbg32 {
>          register_t bits[2];
>          struct {
>              /* DFR0 */
> @@ -426,7 +438,8 @@ struct cpuinfo_arm {
>  
>              /* DFR1 */
>              unsigned long mtpmu:4;
> -            unsigned long __res1:28;
> +            unsigned long hpmn0:4;
> +            unsigned long __res1:24;
>  #ifdef CONFIG_ARM_64
>              unsigned long __res2:32;
>  #endif
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index 3205c7df46..a660cb0734 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -305,6 +305,7 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
>      case HSR_CPREG32(PMXEVTYPER):
>      case HSR_CPREG32(PMXEVCNTR):
>      case HSR_CPREG32(PMOVSSET):
> +    case HSR_CPREG32(PMMIR):
PMMIR is EL1 only, so it does not belong to this block and this comment. Place
it next to PMINTENCLR.

>          /*
>           * Accessible at EL0 only if PMUSERENR_EL0.EN is set. We
>           * emulate that register as 0 above.
> @@ -320,8 +321,36 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
>      GENERATE_TID3_INFO(ID_PFR0, pfr32, 0)
>      GENERATE_TID3_INFO(ID_PFR1, pfr32, 1)
>      GENERATE_TID3_INFO(ID_PFR2, pfr32, 2)
> -    GENERATE_TID3_INFO(ID_DFR0, dbg32, 0)
> -    GENERATE_TID3_INFO(ID_DFR1, dbg32, 1)
> +
> +    case HSR_CPREG32(ID_DFR0):
> +    {
> +        struct domain *d = v->domain;
> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !is_vpmu_domain(d) )
> +        {
> +            info_dbg32.perfmon = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
This breaks the arm32 build (you should always at least build test the patches):
s/hsr.sysreg.read/cp32.read/

> +                                  info_dbg32.bits[0]);
> +    }
> +
> +    case HSR_CPREG32(ID_DFR1):
> +    {
> +        struct domain *d = v->domain;
> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !is_vpmu_domain(d) )
> +        {
> +            info_dbg32.mtpmu = 0;
> +            info_dbg32.hpmn0 = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg32.bits[1]);
> +    }
> +
>      GENERATE_TID3_INFO(ID_AFR0, aux32, 0)
>      GENERATE_TID3_INFO(ID_MMFR0, mm32, 0)
>      GENERATE_TID3_INFO(ID_MMFR1, mm32, 1)
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index eef10c2ea2..e352e2b38e 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1269,6 +1269,11 @@ static always_inline bool is_iommu_enabled(const struct domain *d)
>      return evaluate_nospec(d->options & XEN_DOMCTL_CDF_iommu);
>  }
>  
> +static inline bool is_vpmu_domain(const struct domain *d)
> +{
> +    return d->options & XEN_DOMCTL_CDF_vpmu;
> +}
> +
>  #ifdef CONFIG_MEM_PAGING
>  # define mem_paging_enabled(d) vm_event_check_ring((d)->vm_event_paging)
>  #else

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 09:02:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 09:02:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398737.1634870 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyQZH-000264-9l; Mon, 24 Aug 2026 09:02:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398737.1634870; Mon, 24 Aug 2026 09:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyQZH-00025x-6t; Mon, 24 Aug 2026 09:02:11 +0000
Received: by outflank-mailman (input) for mailman id 1398737;
 Mon, 24 Aug 2026 09:02:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wyQZG-00025r-4L
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 09:02:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyQZD-001Epp-SN
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 11:02:07 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8c088e-bab6-0a2a0a5309dd-0a2a4502cf2c-2
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 11:02:07 +0200
Received: from [209.85.208.53] (helo=mail-ed1-f53.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8c088f-6ca4-0a2a45020019-d155d035a957-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 11:02:07 +0200
Received: by mail-ed1-f53.google.com with SMTP id
 4fb4d7f45d1cf-6a156627e22so7638100a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 02:02:07 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c249606b5aasm1154638666b.4.2026.08.24.02.02.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 24 Aug 2026 02:02:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787562127; x=1788166927; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=WsNyoIyXX9pw8H/0gpGeZi5E86BAgz2aWVDaotX6wYs=;
        b=XarqSKgLfKI26SVijESk7nMQEoEzrYPdIlsS4y5/e8FhDB8Xt6AE18quS66oEz2DP8
         cTWoZVAb+cABM7Sk2pGPmriEMVfmGeA4xejjLUt9aH6RWf9yqlI5Hn8IIPFFlDKEbXFC
         4zV5ScxtgkQ6y20UWm9PKPE7S/fA4GiCQdAvhAOlL8V8WhJjT2SU20IYexCyegO+TmA9
         XBbhFmAXZz56cSkGxxVNcYp4OaeumYY1kWTBT6VGXMT+4PmZKwH1u+ipQUJ6Y/WSI/Ku
         tz7ifR6SfBP2snMWEhHpxMTV5M+hwBEc4xbIbsgFi2ta5PF95CHi0zxeXsIAnpXf3OIF
         BzAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787562127; x=1788166927;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=WsNyoIyXX9pw8H/0gpGeZi5E86BAgz2aWVDaotX6wYs=;
        b=KORmqhf9zMutK1bDTqi4HeibTDDDqkxulvG2tk2GfoGZYJ/ap8jubM8saw6CdBdTas
         1j1B1yXQ0VoTyJ2jGeaMRugrdHDETFvBiVspdS4GogHqPLaYQdwtIjMLnyALls4N6rTE
         xPLuVALgLxhdwQE200Z3HFEmzoFBjIvI1s8zsjLPHMx1F3l95IueFMwLgHdnBTSHRPT+
         +8/jeQIFllIV2yvUMLn+rMSrJ5D2Yzsf3wOeY/K2+cnZriCHagTMYk6+CpWxym8h71fp
         fLUjiBaEg4HIkwXKxfZOdgOCdH8Z0eVed+VJybb/yKBcyDezymCvz7sUfsLU+8FKy1V0
         di0Q==
X-Forwarded-Encrypted: i=1; AHgh+RopF4s8rR4Lqy7NajfCs2O8A/U8UXcq7kLN46MW0X/C5fDrRtpgjLsK+ktZKurk++hB02YAqS5i4vc=@lists.xenproject.org
X-Gm-Message-State: AFuF++laVkrPXm1yzpmyYZRCmepqJvygWJYQ4mHPkOwQ9sv1+xYVVwHM
	XWQ6HqwFMLzvGWb5qHx6UsxaVZw1m5RuXjr4yviODzXJcWOJxc1Ge2WKZjprw/GJMg==
X-Gm-Gg: AR+sD10xiPEwXegl0a93LfeNa5x2GfzgZ4PKKwdYLjNs+QSD/9gEDMrIe5JpZzn3I0o
	rO0Atr3IPJFsD87adDYH78JMmm4pBB5DwoUoD6zT1ip7VAcEGHaIZMMDaeynvFeBB0c3jGmaUai
	hZG+kQKOUvajGxRBIEFiknV22wsuPITEVD0Lwk9NfPWv/7Pmp6Qahx/vG614fHHk2+bAoR7T77B
	SGYAanNLTbAlr3TJFjC+p+f+cql1RWfVaYpTv33fxDyHEBeoVmObdrHOQh3lF+sXYkryRlcJzBN
	LK4TNneLj7gYHq30B3ZprazfXR+cq++4AnmGLnn5EcURHhDtNMVD0r3rY42y33YU8igFdaJuECS
	CxVex2ysw4aSsAuz9tUDZcve5Y/ch1dJXXvhUKUrLp9O3wLtEcGrGlie/n7ItgSAPsXw47coMub
	v/Cku66mxp4CJo/ots3oDsP64SXEAP+WbMUtSSSDx4f/uL7DhaxcKY3wcUuBniArZYNy42tBYxC
	R/lhAK9Ks6F3L3U4S3/L2nqDYtadNFBSUlWWehzJ4ZR8y+ZiNXn
X-Received: by 2002:a17:907:e1c6:10b0:c24:d6f0:aa0 with SMTP id a640c23a62f3a-c24d6f07ce6mr137547866b.11.1787562125670;
        Mon, 24 Aug 2026 02:02:05 -0700 (PDT)
Message-ID: <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com>
Date: Mon, 24 Aug 2026 11:02:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: George Dunlap <gwd@xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
 <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787562127-319CB2AC-00DA5CA0/0/0
X-purgate-type: clean
X-purgate-size: 12000

On 21.08.2026 17:17, George Dunlap wrote:
> On Fri, Aug 21, 2026 at 9:45 AM Jan Beulich <jbeulich@suse.com> wrote:
>> On 20.08.2026 19:43, George Dunlap wrote:
>>> One point reviewers may want to look at specifically: patch 1 changes
>>> where the per-domain page-tables are allocated from, and its commit
>>> message discusses the (minor) NUMA-placement consequence.
>>
>> While I don't recall which recent patch (series) it was, I can't very well
>> say "no new xenheap allocations please" there without also saying so here.
>> I've read over patch 1's description, and while it tries to justify this
>> accordingly, I still remain concerned. I think we simply have to accept
>> the mapping overhead, to avoid allocating from a pool which - over time -
>> is representing a decreasing portion of total memory systems have (on
>> average, and not even considering systems with extremely sparse memory
>> layouts, and with perhaps PDX compression not doing good enough to
>> compensate).
> 
> You should certainly have the same resistance to adding new xenheap
> allocations.  But looking at the numbers, I don't see that we're
> anywhere near the point where we say, "Absolutely no new xenheap
> allocations, regardless of the cost."

Well, that depends, and in part on the longer term plans with ASI. It has
been my (silent) assumption that eventually the directmap would go away
altogether when ASI is in use, with the VA space freed (almost?) all
becoming available for vmap(). With the disappearance of directmap, the
xenheap would naturally disappear as well. Hence putting stuff there in
new work actually adds to our technical debt.

>  domheap+vmap looks like it was
> cheap and easy alternative for Teddy, but the alternatives here
> aren't, compared to the cost of extra xenheap allocations.
> 
> So let's lay everything out.
> 
> My understanding is that we have the following two issues allocating
> things in the xenheap on systems larger than 4T:
> 
> - The total amount of xenheap space is limited to 4 TiB of virtual
>   address space.  On some systems, this may correspond to 4 TiB of
>   actual RAM; but on a machine whose RAM layout is sparser, the
>   actual RAM addressable in this window may be far less
> 
> - It's not symmetric NUMA-wise; so the larger the system, the more of
>   the xenheap will end up being from the same NUMA node.  This will
>   limit Xen's ability to have NUMA-local data structures, and its
>   ability to give NUMA-local data to guests running on node 0.
> 
> Looking at this series as a whole, although the first patch adds pages
> to the xenheap, the end goal of the rest of the work is to remove
> pages from the xenheap. Things added in:
> 
> - Making the perdomain area per-vCPU, with its pagetables allocated
>   from the xenheap, adds a per-vCPU L3 plus an L2+L1 pair for each
>   slot in use.  This totals 5 pages/vCPU for HVM guests and 8 pages/vCPU
>   for PV guests.
> 
>   (Note that the GDT/LDT L1s are already allocated from the xenheap
>   today, but per-domain rather than per-vCPU.)
> 
> Things removed:
> 
> - Per-pCPU stacks -- 8 xenheap pages / pCPU
> 
> - AMD VMCB - one xenheap page / vCPU
> 
> - VMX guest MSR area: 1 page per vCPU
> 
> - sub-page XSAVE areas (~2.7 KiB/vCPU of xmalloc pool today; planned
>   follow-on work aggregating other miscellaneous xmalloc'd guest state
>   should take this to about a page per vCPU)
> 
> To do some math: current security-supported limits for x86 are 4096
> pCPUs on a 12TiB system.  Suppose we have an 8:1 vCPU:pCPU ratio, and
> an average of 8 vcpus per domain.  So 32768 total vCPUs and 4096
> domains.  On a Full ASI system, vcpu-pt on all domains, per-CPU stacks
> on, all Intel HVM domains, we get numbers like the following:
> 
> Added to xenheap:
> 
> - Per-vCPU tables, 5/vCPU (L3; mapcache L2+L1; state-window L2+L1):
>   5 × 32,768 = 163,840 pages = 640 MiB
> - Per-pCPU stack tables, 2/pCPU: 2 × 4,096 = 8,192 pages = 32 MiB
>   (→ 0: these are only written at CPU bring-up and tear-down, so we
>   have already moved them to the domheap in the working branch --
>   which also makes them NUMA-local unconditionally)
> - Per-domain tables: replaced by the per-vCPU sets in vcpu-pt mode → 0
> - Total added: 172,032 pages = 672 MiB
> 
> Removed from xenheap:
> 
> - Stacks, 8/pCPU: 8 × 4,096 = 32,768 pages = 128 MiB
> - XSAVE, ~2.7 KiB/vCPU from the xmalloc pools: 32,768 × 2.7 KiB ≈
>   21,600 pages ≈ 86 MiB (0 if guests get AMX — those areas are domheap
>   today)
> - VMX guest MSR page: lazily allocated, typically absent → 0 (upper
>   bound 128 MiB if every vCPU used one)
> - Total removed: ≈ 54,400 pages ≈ 214 MiB
> 
> Net: +117,600 pages ~ +458 MiB — against a 4 TiB window (0.011%), on
> a 12 TiB host (0.0036%).

While these percentiles in particular of course look very tiny, they are
applicable only on systems having no meaningful gaps in the physical
address map. And even more generally I find all of these calculations
only partly convincing, not the least because you start out from numbers
which look pretty contrived when comparing to actual systems which would
run the new code. (Using more realistic real-system values may end up
going in favor of what you want to convey, or it may not.)

> I have explored a number of other options, to various levels of depth.
> 
> One is map_domain_page_irqoff(): If the caller promises to keep
> interrupts disabled until unmap_domain_page_irqoff(), we can safely
> perform maps in a context switch without having to worry about
> sync_lazy_execstate.  (This was actually implemented and almost sent
> on Tuesday evening, when I noticed your review of Roger's v2 saying,
> "Question is whether it's a good idea in the first place to start
> using map_domain_page() from the context switch path.  Surely there
> are possible alternatives.")  This maps all vcpu pages from the
> domheap, adding nothing to the xenheap *or* the vmap area.  But it
> costs 9 map/unmap pairs *per context switch*.

But why would not using vmap() be a necessary conclusion of my initial
comment? All I'm objecting to are new uses of the xenheap.

> I absolutely reject the idea that because on a 12TiB system with 32k
> PV vCPUs, we take up an extra 0.02% of the xenheap area, that a laptop
> running QubesOS has to do 9 maps and unmaps per context switch.  That
> is not a valid cost/benefits tradeoff.  In the worst case we could
> just add a switch to such a system, allowing people who find their
> xenheap too full to use the mapcache version instead.  (We could even
> turn this on automatically at boot based on projected xenheap
> utilization.)

Maybe, yet extra overhead may be a necessary (but hopefully only
transient) price to pay in the course of the transformation.

> There are other options I've explored:
> 
> - domheap + vmap; basically, allocate from domheap, map in the vmap
>   area.  On paper this sounds like the same thing; the problem is that
>   we don't have a simple MFN -> VA mapping, as we do in the xenheap
>   case, so the walk is a lot harder; we start to have to do lookups,
>   significantly increasing the cost over simple memory reads and math.
>   (This is the difference from the intremap table on the VT-d thread:
>   that's a leaf structure reached from a single pointer, so a
>   permanent vmap costs nothing there.  Pagetable hierarchies are
>   exactly the case where the MFN -> VA step is critical: each entry
>   read yields an MFN, which the walk has to turn into the next VA.)

The pages used here are entirely private to logic handling those page
tables. Hence a struct page_info field can very likely be used to stash
the VA of a permanent mapping. (Feels like similarly I must have
suggested this somewhere else recently, yet I don't recall the context.)

>   And if we're concerned about "xenheap creep", when we have a 4 TiB
>   ceiling, shouldn't we also be worried about "vmap creep", when we
>   have a 64 GiB ceiling?

Absolutely, and I have been mentioning the need to consider growing this
area in a number of situations (one iirc again pretty recently).

> - Stash everything we need; basically, an extension of the current
>   gdt_ldt_l1tab functionality.  Allocate everything from the domheap,
>   map it in the vmap area (moving gdt_ldt_l1tab there as well), keep
>   pointers to all the things we need to modify on context switch, so
>   we don't need to walk the tables.  This would basically be, three
>   pointers per vCPU: a pointer to its GDT/LDT L1, a pointer to its
>   per-vCPU L3, and a pointer to the per-vCPU root_pgt.  (This would
>   put ~384 MiB of mappings into the 64 GiB vmap region -- 0.6%, shared
>   with ioremap and the fixmap -- to avoid 0.02% of the xenheap
>   window.)
> 
> Both the vmap options have two complications, compared to the posted
> option.  One thing to worry about here would be the additional stress
> on the vmap allocator: It's a linear bitmap scan under one global
> lock, designed for dozens-to-hundreds of ioremaps, not ~100k
> long-lived single-page mappings (32k vCPUs x 3 pages per vCPU in the
> "stash everything" case).

Indeed, heavier use of that allocator may require work to be done there.

> The second is that we begin to run into bootstrapping issues.  With
> the xenheap approach, we can begin building and walking pagetables
> very early in boot in the same manner in which they'll be walked
> throughout Xen's lifecycle.  With the vmap approach, we need to deal
> with the fact that the vmap area itself isn't up until later.

Valid concern, yet surely possible to deal with.

> The final option I looked at was mapping the incoming vcpu's linear
> map to edit it ("altlinmap").  That still adds a map/unmap per context
> switch, and requires some additional complication to handle
> ASI/non-ASI systems.
> 
> Xen already consistently allocates its page tables from the xenheap
> whenever it needs to access them during a context switch:
> alloc_xen_pagetable() has allocated from the domheap since Hongyan's
> directmap-removal preparation (those tables are only ever walked in
> contexts where map_domain_page() works), but XPTI's per-CPU root_pgt
> is alloc_xenheap_page(), precisely because it has to be written on the
> context-switch path.  The same for the PV GDT / LDT L1 tables.  The
> series follows the same rule for the same reason.

"Rule" is a strong word. XPTI at the time needed to be done quickly.
The inability to map_domain_page() from the context switch path left
xenheap as the only viable option. Whereas with ASI, as said at the
top, phasing out directmap (and hence xenheap) as a concept is (imo) a
mid- to long-term goal.

> Ultimately, I think there's a lot of wisdom in the saying, "Premature
> optimization is the root of all evil."  As I said, it's certainly
> right to be on our guard against adding things to xenheap, and look at
> alternatives; but we're nowhere near the point where we need to say,
> "Absolutely nothing added, regardless of the cost."  The design here
> is not locking us into the pages long-term; alternate designs have a
> significant cost in terms of authoring, reviewing, code complexity and
> maintenance, and code performance.  At such time as we find systems
> where the xenheap allocations introduced in this series become a
> problem, we have a number of potential ways to mitigate the problem,
> including switching to mapcache *on systems with the problem*, or
> switching to a number of the other more complicated approaches.

I'm a little puzzled by you talking of "optimization" (premature or
not) here. In my initial reply I did point out a functional aspect, and
I made clear that I'm aware that this is going to have a performance
impact. I.e. quite the opposite of "optimization".

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 09:30:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 09:30:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398745.1634880 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyR0v-0006eK-CX; Mon, 24 Aug 2026 09:30:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398745.1634880; Mon, 24 Aug 2026 09:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyR0v-0006eD-9c; Mon, 24 Aug 2026 09:30:45 +0000
Received: by outflank-mailman (input) for mailman id 1398745;
 Mon, 24 Aug 2026 09:30:43 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wyR0t-0006e7-M2
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 09:30:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyR0s-0019Rk-6f
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 11:30:42 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8c0f31-8faa-0a2a0a5109dd-0a2a4503db62-34
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 11:30:42 +0200
Received: from [40.107.208.28]
 (helo=PH0PR06CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8c0f40-fae8-0a2a45030019-286bd01c26c1-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 11:30:41 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CO1PR03MB5716.namprd03.prod.outlook.com (2603:10b6:303:94::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 09:30:37 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.012; Mon, 24 Aug 2026
 09:30:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d69nsy+SK6yf7zOf86X05X25x13sCk+OHqFP7vR6rW9rxppXdF1/CRnq0A7FNU1z0nFm2MxcdoJ2cRetdlS95x11bhJ6H98WEKWQehGpTaNZzSUo/mIETu//6K5eIgIQhh99K1oJeF1BG3DWVDaozU13533cwDpwtnLnqsFPQ1W/pONQFhEm8bdHddb2mvgUoiJjvIBFX/SbgmwEl8CyJrdqqzLvEUR0LOVntdvFXqBYkTqhDjOsu5T1W3xpAsOrIuO67AzHndiwozscv6sFwXz+7VIfJ6+F8bRF2FN1nro1g7H3Om9MSOSNcTWytYC4zENlxq1i0rSYA0GYzUoQzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xpgqEA7U3s3ys2xJSmSljcRHZ0ngwkE3kq8BdjAA1ZM=;
 b=XUS7i2wZ8bxSuh2F06kXi1zLtLdO6+Xjda4PARDTnPHsJM8kOLCRZSQuB+DNLIAiV/kxRy9whRbyfQpicen5SxUVbAKKogpEr7C5TMx9OP5AZs7peZj98Qd+2zw8wGzdjU182kJA5QcfGc8bVQoBcdM9wLMnngZ2olGJi1E5Fz4iehqjdHmWFVLrs2MzWxAx0GX9yp88fUGHfKim1tunaWmOO6Tt4t78OSL0ovGFE16kNkVxSX3TXNdisztAs87GQZTAHxGokO/jDG9xS6Bgmdlzs37a7yNOeFW06rt4acLFQT9Xhm+bzFV3IHhzYdifO/rPtNoYLFxsovTmo2B7iA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xpgqEA7U3s3ys2xJSmSljcRHZ0ngwkE3kq8BdjAA1ZM=;
 b=wNd7ZhBzsb+8AxIauk6J/EPgYPz+YHa3K6GTQ4FSdDCcOpYvKxIZtC3Sk709r0ItvTIV3FayAUXDJA6F6M+7RnWqr6Bo8MXB/F5fRzvS+tppNG2A6Zq8QWynSoPK6sGM48VoAlYiqkU/uEq4JLrqRxBx7XGyCuOHuQVYbBsgsig=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <d938b635-1cdd-46d9-8083-c6f9251ebc85@citrix.com>
Date: Mon, 24 Aug 2026 10:30:34 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Andrew Mbugua <andrewprecious388@gmail.com>
Subject: Re: [PATCH] x86emul/fuzz: sanitize CR4 values
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <d3d188c2-32c5-45ee-9b10-1f4ee1b85c6e@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <d3d188c2-32c5-45ee-9b10-1f4ee1b85c6e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P265CA0055.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2af::11) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5716:EE_
X-MS-Office365-Filtering-Correlation-Id: 6b61ba37-0a14-4dde-70f4-08df01c25b1c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|10067099003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	Q7xYYaB9Kfjf1ZT//j8npxlGv20+FJlBgdLu+TvCCH5qkvNis3RA5cGF/6fjpbDV3iBxN0y/knAZd/6iNE+CM6F1pQbx5PhnICD+4H5/eh9hQOkth2tl2O6g6ixN9kEdpUd4RCQWIxzWfGT8LEag/qvDDSwHB8/xzrB9m6SBBQhDZ9KjiFGEEAwTVZGtWcGkosh4c8MvyY15Z1zhtHIwQtI5q9PN+BN3BHpvbaz3c9ipHn5JEWYShAoTtEqwBhGtt+aVOCsJ8J3VMS6R9vI5xLxaYg32z29H/I6N4RGaKOC7kNhtn38sPK3GYvvkFbjSOWz5PWnVaOIbjtVCdQqqxISJ7fw4iU8LldlkhwqjRmeCaTSDQknYpPTovxaPo3fH/Zdy8El9Juz/ddPYnKo20dN323mVKjE0G1mEMHGKySzfVmcpYkEDfefcHq5qS57giBP5bfkHL1GhvutPM9BNvjw1EscrWL0FvoCb3QAUzs6NXMwg7Kn17y32KQ/tEBrvHqUUDORL8MHsvuh6UeH0xl9ViL1aAEFMYGMBqZaVPBc6oZRd1RRaO206f1BuTYiZsNoTAg60O2OO/geVoIQShgoVUQ7QPfafIzSxicW/OywTXROX5BHUFz5wch4Ib2RvoDYHl0TuxZikNeSp+Gqi++txUxaalhJgKg2buUXk1cw=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dlpoTTZtME1oMUdlVjdiNDE1ZFRWSTh6Um1hS0R0NEk0MkJFOVQ5c0tEYnRT?=
 =?utf-8?B?MWZmak5QUmpTanUrMmI3d0l6d09mU2hUN0pXSlp1L0tSbjFuaWc2dGhnRUth?=
 =?utf-8?B?b3JTVzVuL2JqY1NxUXM5N3BzTmg4ZzlVWTBIalBmRXpXMVlWbi9hM01ZRkdO?=
 =?utf-8?B?WkhORVNCSGtmTVB1d0xvWlByTDR1c2gwZFBjN2ZSMUFjL2ppekJHajBNMzR0?=
 =?utf-8?B?TUY2SE04c0Fpb01ob1B5MkZIWlpSbXdranFtQmQzeEo1SkcweW8xcERJWGxL?=
 =?utf-8?B?TWhLbmNEd21ZWHhWc1lqT1h0MGRvTUFQVWc1REFtYmpRRndXYkI4d3Y4bDNB?=
 =?utf-8?B?cG1VVSswME1iMjNZR002N1UxcW5TWW5YN3NJTTBSNnhmV1JHd05yYlJ3OHU3?=
 =?utf-8?B?UWRXbURESFlHdWtkdTA1bXkxd3Uxa0tFY0JONjdsWlNYWlRzaVpVaTQrYTE3?=
 =?utf-8?B?U0ZkTWpVczVPTWlEaUt3OHpMS3pLd1AxR2I0dGRqY0RJcXJiYWpWVEdnSHpi?=
 =?utf-8?B?SXJkUUp2dTNZbWFuR0t5eEc1dkR0R1h1eXd0VFpSSm1hUnQvdzZyQ2NrcFAv?=
 =?utf-8?B?elZGajU2dHNaNFQxRjhxUzlmZ3Y1ckhiaEE4VTh0ZmJBQjVPM204NFU1cHp1?=
 =?utf-8?B?MzYwdGh5WTl1cVR6YnJ3VEsya3JSVytBU3JkR3BYV3BkYmFaOGdMMTZDL1Zj?=
 =?utf-8?B?eEdZWCtrbnRVOGkvcTlHS2VTT2w4Wm45NVBwQytjSUE0cFI4MnY2WFl0TVFM?=
 =?utf-8?B?QWlrUUV6Y1hQOVZHTkRUNTJNV2lYdER1NVp6cUc0OEEzcktmaWRHV1RtWUt0?=
 =?utf-8?B?WlNlcUpsQzFBKzNpY05scVJRN3p5ZVNZbVhEUEkwWGp2eXh0VTNUblF5NkQy?=
 =?utf-8?B?WHRlcmNrVTJGNEdDVDdMYzdsanZHWHFvTG9pdVFEWmFCdGpidGdIbU9sMlNN?=
 =?utf-8?B?b3dydlg3bUlWZDN1QzBDd1NzaVIzZCtMUTFiWkxuVS9RVVZNOG1vbnBYUURX?=
 =?utf-8?B?U2NxZGxLRkRIVWdPZGhXSmpkMXFBUnREWGxpbVV6RE9VeDJkK2s3aWJoVWV2?=
 =?utf-8?B?ckhiWnBjS0RaYnlITDlML09rdjN5bkc4MmRWOW0wWGlWbldBRXFEK2luV25Q?=
 =?utf-8?B?REtReCtheEM5TE5CcmhLRmtIQytiamkvalhNdi9GeGdqOVhXOU43TUN3L3p1?=
 =?utf-8?B?bWxHbW40MUNIaDdhdENBa1RBZGVsUmc4a3ZpY1Z1YzhBMDk2TitlZytBdGhB?=
 =?utf-8?B?Y3NyYlFDT2VJRU91cDlHWGZUc2wzVG95VUc5OXpUdjNhTkZHdDhpQjltaFM3?=
 =?utf-8?B?cFJETUp5SXZnaDh3YmJMWWt2di9WRXlENG9QTkZxeU5BRXlGYkhzRHZWbU1I?=
 =?utf-8?B?RFBFRHZrQmxEM3dvL2VLMkx4KzVrL3RYQ3RUUDFyaXRDOWZENWo0cjlGUjlE?=
 =?utf-8?B?VjIwOFlNVHYrLzkvQjdIb0xzUVFpdFhpZXV4bnI0bEFRWnJBYlZWdWxRYWVt?=
 =?utf-8?B?VWxqb0ppai90K1VRUEh1MmNtcFcxMmZCMFpTL1RNMmFRdVpJSGg1cEZIblhH?=
 =?utf-8?B?emI4VktqbkRLM0R1cExSTkl2UXRGcFliZnVUZjNGVDBYdStJb3doQ25Edlhs?=
 =?utf-8?B?dU9sZTR4b2JYTEcxRGNPKzIxeHRpYUo5L05scjM2cXRka0JaRnJ0ankxWFho?=
 =?utf-8?B?R2Rod2pCYWQ0L244Y2NqV0FTT0Q3ekR0SjFYcEdBcFV6R0ZPVEZoVVBUUmtJ?=
 =?utf-8?B?Zklnb2NqcUtxOVVFd3B2eG85NHlBOTFZaEFBWktML2FOYnhTaXcrRmNoa2sy?=
 =?utf-8?B?TjVkZUZLTzRpZDk4eEF3TzRIWTJwM1IzQXp1djRFdklhSzVLWWZBNTdLQWpP?=
 =?utf-8?B?RmJicXBkRk9HZlMyVDMzbTRjMDFydW8vRGZmNm15alE0K0xGL294em5RTExn?=
 =?utf-8?B?NVdneG05ellvTldqOFBFdHRsaVgzSWh1S1dKMVo2L2pTRnZXOWJZZzFWa0ox?=
 =?utf-8?B?ck9qZ3hkbXY4eHdFOVZCOXYwM3BzbzdnTEcrdkpBQUYyZWR5cXdsOENQU2c5?=
 =?utf-8?B?cUlhVkxYdTVzMkpMTGRLMGluVkhRdXNBcFlhL25MMWlocVp3N3hRYmhpNFo3?=
 =?utf-8?B?VkQ5TlJLODc1YksxMFhuaUNVU1RKQkVabVVoTmFpWS9FMDVMUEw0UUJBT29l?=
 =?utf-8?B?YlZOTHhWM2Nnd3pFOFYyMlE3RGFiS3ZURFRoY0FabUU4cnpQZDN0WTkzUHVC?=
 =?utf-8?B?SDQ1U0Y4Yi9temw3N1pTVVRFM2dBazdMUVMxSGVlclhESWR2QjJ0OXhleEo1?=
 =?utf-8?B?djc4T3lYSFc3R1NvTFlEN0dEN2VkcUI2Syt4MkFNTWdOb3ZlSFZmZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b61ba37-0a14-4dde-70f4-08df01c25b1c
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2026 09:30:37.4544
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IzFRPiynZUcWN0IvjBCMkWMUjQ286gjdoM1nTdY5ZrN3TZB55w6U5LEQ6eXjz0mZZznk8DD15IfltU3LD35L5Dt339HLjXNQAn5ZEa6D990=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5716
X-purgate-ID: tlsNG-33051d/1787563842-77CC34E9-FE660082/0/0
X-purgate-type: clean
X-purgate-size: 779

On 24/08/2026 8:41 am, Jan Beulich wrote:
> While the CPU policy is obtained from hardware, the CRn values to start
> with are taken from fuzzed input. Since most CR4 bits can only be set when
> the respective feature is indicated as available by CPUID, the emulator
> often only checks the CR4 bit. Without sanitization, assertions like the
> one in emul_test_read_xcr() (checking XSAVE support) could therefore
> trigger.
>
> Omit most paging-only bits from sanitization, as the core emulator doesn't
> itself walk page tables. LA57 wants checking for the bit being used by
> CANONICALIZE_MAYBE().
>
> Reported-by: Andrew Mbugua <andrewprecious388@gmail.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 09:32:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 09:32:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398753.1634889 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyR2j-0007H9-PU; Mon, 24 Aug 2026 09:32:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398753.1634889; Mon, 24 Aug 2026 09:32:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyR2j-0007H2-Mn; Mon, 24 Aug 2026 09:32:37 +0000
Received: by outflank-mailman (input) for mailman id 1398753;
 Mon, 24 Aug 2026 09:32:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@swg.vates.tech>)
 id 1wyR2i-0007Gu-4k
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 09:32:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyR2h-001LEV-Eu
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 11:32:35 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@swg.vates.tech>)
 id 6a8c0fa9-8faa-0a2a0a5109dd-0a2a4503cea2-22
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 11:32:35 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@swg.vates.tech>)
 id 6a8c0fb2-fae8-0a2a45030019-b9ff1c23a21d-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 11:32:35 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0331d3dbc000c4f3.005 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 24 Aug 2026 09:32:29 +0000
Received: from localhost.localdomain (88-188-240-210.subs.proxad.net
 [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id B1BF181C0F;
 Mon, 24 Aug 2026 11:32:28 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=frKZvkkoHuZO+4+eIBclrbgx87D7UdiHPGG3Sjh8yOc=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id;
 b=My4odkJLBO7r4pTldO8P4Rz15mkVZC8//CHKMqNxraZDX7QQ4nXjO/GJaA5IOvacteE7VvUrB
 OcAoI5srn46SXYRx8M3RCBb+rlJaaDhct5TZE+t3+ScF/OGYlUYwAyTVGrKiHsKv7d69y9oYsUr
 YuL+WnFB5i5QvmhjRKrCFDJXwWQ/NwX3gEdr+8xKxBrDPVSbi9ejcvaPFJuXvgS5F+h9pmqSY32
 G2PpscrTU2cINrFJNQFNJdbrMHN2rEza1N8zS4mNVpdmYH50EVT0IOJCIbrIqaf1TILAvehh/Sp
 Bo3Aqb8Fmj84OJS48e51VpdpvSV3TZgZcUWOqmXIaGlg==
X-Zone-Loop: 3f1f859c254e0d9ecc5ab89c0d9f252527c8cfc0b01d
x-campaign-type: default
x-transaction-id: bd0b3e67-a9e3-473f-9845-76bf1b19e373
x-swg-uid: 01-52ff2f37-3c8a-4b48-bdb7-c16eb44b22d6
X-Mailer: Sweego
Message-ID:
 <1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@vates.tech>
x-swg-bid: 1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Teddy Astie <teddy.astie@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: [PATCH v2] public/xen.h: Update comment on mmu_update sub-command size and PTE alignment
Date: Mon, 24 Aug 2026 11:31:36 +0200
MIME-Version: 1.0
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2999.e393777c230f96c6.1a0331d3b9b.11373df49aec6867=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787563948959
X-purgate-ID: tlsNG-33051d/1787563955-6ECCB4E9-C7AF6876/0/0
X-purgate-type: clean
X-purgate-size: 4750

---=Part.2999.e393777c230f96c6.1a0331d3b9b.11373df49aec6867=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

HYPERVISOR_mmu_update passes a set of request, where each request has a poi=
nter
to the PTE along with a sub-command=2E

The PTE alignment padding is used to transport the sub-command while the r=
est
is used as an address to a PTE entry=2E The current documentation state th=
at the
2 first bits are used for sub-command, hence the other ones for PTE which
imply here a 4-bytes alignment on PTEs=2E

On PV64 and PV32-PAE guests, all pagetable PTEs are 8-bytes aligned, hence
off-by-4 PTEs addresses are always incorrect=2E Non-PAE PV32 guests used
"legacy pagetables" which had 4-byte aligned PTEs=2E However, support had
been completely removed since Xen 4=2E0, and was only available when Xen w=
as
built in 32-bits non-PAE mode [1]=2E

Current Xen logic behaves as if 3 bits are used as sub-command, thus all
off-by-4 PTEs are actually rejected as being unknown sub-commands=2E

Adjust the documentation to match the current logic implemented in Xen,
also expanding the documented sub-command parameter to 3 bits=2E

[1] 84d54d5d8b31 ("i386: Remove non-PAE hypervisor build target=2E")

Signed-off-by: Frediano Ziglio <frediano=2Eziglio@citrix=2Ecom>
Signed-off-by: Teddy Astie <teddy=2Eastie@vates=2Etech>
---
v2:
* Fixed typos
* Added Frediano Ziglio S-o-B
* Added historical note regarding non-PAE Xen=2E

 xen/include/public/xen=2Eh | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/xen/include/public/xen=2Eh b/xen/include/public/xen=2Eh
index 2149b8dd38=2E=2Ecf32e74f14 100644
--- a/xen/include/public/xen=2Eh
+++ b/xen/include/public/xen=2Eh
@@ -218,16 +218,16 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *                     x =3D=3D 0 =3D> PFD =3D=3D DOMID_SELF
  *                     x !=3D 0 =3D> PFD =3D=3D x - 1
  *
- * Sub-commands: ptr[1:0] specifies the appropriate MMU_* command=2E
+ * Sub-commands: ptr[2:0] specifies the appropriate MMU_* command=2E
  * -------------
- * ptr[1:0] =3D=3D MMU_NORMAL_PT_UPDATE:
+ * ptr[2:0] =3D=3D MMU_NORMAL_PT_UPDATE:
  * Updates an entry in a page table belonging to PFD=2E If updating an L1=
 table,
  * and the new table entry is valid/present, the mapped frame must belong=
 to
  * FD=2E If attempting to map an I/O page then the caller assumes the pri=
vilege
  * of the FD=2E
  * FD =3D=3D DOMID_IO: Permit /only/ I/O mappings, at the priv level of t=
he caller=2E
  * FD =3D=3D DOMID_XEN: Map restricted areas of Xen's heap space=2E
- * ptr[:2]  -- Machine address of the page-table entry to modify=2E
+ * ptr[:3]  -- Machine address of the page-table entry to modify=2E
  * val      -- Value to write=2E
  *
  * There also certain implicit requirements when using this hypercall=2E =
The
@@ -260,21 +260,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * hypercall=2E Also if so desired the OS can also try to write to the PT=
E
  * and be trapped by the hypervisor (as the PTE entry is RO)=2E
  *
+ * Note: Historically, Xen had support for non-PAE PV guests with 4-bytes=
 wide
+ *       PTEs (if Xen was built in non-PAE mode); which support got remov=
ed in
+ *       Xen 4=2E0=2E As a result, in current Xen,, all PTE are now alway=
s 8-byte
+ *       aligned which allows expanding sub-commands part (now 3-bits wid=
e)=2E
+ *
  * To deallocate the pages, the operations are the reverse of the steps
  * mentioned above=2E The argument is MMUEXT_UNPIN_TABLE for all levels a=
nd the
  * pagetable MUST not be in use (meaning that the cr3 is not set to it)=
=2E
  *
- * ptr[1:0] =3D=3D MMU_MACHPHYS_UPDATE:
+ * ptr[2:0] =3D=3D MMU_MACHPHYS_UPDATE:
  * Updates an entry in the machine->pseudo-physical mapping table=2E
- * ptr[:2]  -- Machine address within the frame whose mapping to modify=
=2E
+ * ptr[:3]  -- Machine address within the frame whose mapping to modify=
=2E
  *             The frame must belong to the FD, if one is specified=2E
  * val      -- Value to write into the mapping entry=2E
  *
- * ptr[1:0] =3D=3D MMU_PT_UPDATE_PRESERVE_AD:
+ * ptr[2:0] =3D=3D MMU_PT_UPDATE_PRESERVE_AD:
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are O=
Red
  * with those in @val=2E
  *
- * ptr[1:0] =3D=3D MMU_PT_UPDATE_NO_TRANSLATE:
+ * ptr[2:0] =3D=3D MMU_PT_UPDATE_NO_TRANSLATE:
  * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
  * page tables=2E
  *
--=20
2=2E55=2E0



-- 
 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vate=
s=2Etech
---=Part.2999.e393777c230f96c6.1a0331d3b9b.11373df49aec6867=---


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 10:01:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 10:01:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398778.1634937 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyRV0-0003U5-BD; Mon, 24 Aug 2026 10:01:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398778.1634937; Mon, 24 Aug 2026 10:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyRV0-0003Ty-8Q; Mon, 24 Aug 2026 10:01:50 +0000
Received: by outflank-mailman (input) for mailman id 1398778;
 Mon, 24 Aug 2026 10:01:49 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@swg.vates.tech>)
 id 1wyRUz-0003Tp-Ob
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 10:01:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyRUy-00AEvE-MR
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 12:01:48 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@swg.vates.tech>)
 id 6a8c1688-2eae-0a2a0a5409dd-0a2a45038150-6
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 12:01:48 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@swg.vates.tech>)
 id 6a8c168c-fae8-0a2a45030019-b9ff1c23855b-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 12:01:48 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a033380dce000c4f3.005 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 24 Aug 2026 10:01:46 +0000
Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210])
 (Authenticated sender: teddy.astie)
 by mail2.vates.fr (Postfix) with ESMTPSA id DFCC2839DD;
 Mon, 24 Aug 2026 12:01:45 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=BywnPuhetMT0A0RkQQ7IbNbovvOOA9RghZE6yoa/HXI=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=snu/9eANjJ37JCChos/K+2fZU35lAKhafIpPOs6tFf//KIoSxTm0akC+hisQVsG+stxOzF6tI
 nSm7qt0X4BddlIkS8XgCO9EA3RetAv6R4yt0+IetwEsdNMZPmg557GI+Dh5dXs2kTFekMslUPJx
 LldYcplQ6BLXWl1zsxZY6qoxxjvmipNUADp5g5xAXUAojW9ZPbc3f3SUi+vT+hEXWyk1xE+7D9L
 nuQ9kLytZltmGULzkDeYXZnpqpzNspXgo795to9ZNmunsvJ0R/hH8XfTNdm96+rEVQ8sm1SstF/
 C00z/UaKPxBs18ticdX6ShElsF0lnyHLFnndSoSiQjZw==
X-Zone-Loop: 3e44db43f2cdfcd7bda5dc07abfcb03c3b2fbf6a5656
x-campaign-type: default
x-transaction-id: 7efb91de-06d5-4f9f-b466-a42edb4a541c
x-swg-uid: 01-9843a18f-083b-486f-9f43-5f37b74b2b37
X-Mailer: Sweego
Message-ID:
 <1787565706.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@vates.tech>
x-swg-bid: 1787565706.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Mon, 24 Aug 2026 12:01:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/nSVM: Check injected event consistency
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com,
 jason.andryuk@amd.com
References: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------xOmG2CtyRfoh1j4nSw617sNK"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787565706061
X-purgate-ID: tlsNG-33051d/1787565708-6CEDA4E9-2273DB1D/0/0
X-purgate-type: clean
X-purgate-size: 9962

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------xOmG2CtyRfoh1j4nSw617sNK
Content-Type: multipart/mixed; boundary="------------oYCKIjIh6O0BcLZC4UEOryel";
 protected-headers="v1"; hp="clear"
Message-ID: <d331b87a-b59d-41d0-add2-092f51ef54ee@vates.tech>
Date: Mon, 24 Aug 2026 12:01:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/nSVM: Check injected event consistency
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com,
 jason.andryuk@amd.com
References: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Teddy Astie <teddy.astie@vates.tech>
Autocrypt: addr=teddy.astie@vates.tech; keydata=
 xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO
 Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR
 KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH
 tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT
 VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/
 EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S
 PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89
 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz
 LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME
 CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z
 pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE
 v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv
 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP
 eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT
 UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9
 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN
 f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3
 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg
 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv
 fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb
 Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb
 Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov
 XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/
 eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6
 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA
 CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa
 JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj
 by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG
 zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+
 lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off
 O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR
 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D
 x9fhaZEsniw8/bYgC3igkk5YJiOa
In-Reply-To: <95abc420acac6eefc1b97c3c98753d510930ce8a.1785933566.git.abdelkareem.abdelsaamad@citrix.com>

--------------oYCKIjIh6O0BcLZC4UEOryel
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TGUgMDYvMDgvMjAyNiDDoCAxOToyNiwgQWJkZWxrYXJlZW0gQWJkZWxzYWFtYWQgYSDDqWNy
aXTCoDoNCj4gT24gdGhlIEFNRCBwbGF0Zm9ybXMsIGFsbG93aW5nIGEgVk1SVU4gaW5zdHJ1
Y3Rpb24gd2l0aCBhIG1hbGZvcm1lZCBWTUNCIGhhcw0KPiBkZWJ1Z2dpbmcgY29tcGxpY2F0
aW9ucywgc2VjdXJpdHkgYW5kIHBlcmZvcm1hbmNlIGltcGxpY2F0aW9ucy4gVGhlIEFQTQ0K
PiB2b2x1bWUgIzIgMTUuMjAgKDQwMzMyLVJldi4gNC4xMC1KdWx5IDIwMjYpIHN0YXRlcyB0
aGUgdHdvIHBvc3NpYmlsaXRpZXMgdGhhdA0KPiByZXN1bHQgaW4gYSBWTVJVTiBleGl0IHdp
dGggVk1FWElUX0lOVkFMSUQgZHVlIHRvIHRoZSBpbmplY3RlZCBldmVudC4gVGhlc2UgYXJl
DQo+IOKAoiBSZXNlcnZlZCB2YWx1ZXMgb2YgVFlQRSBoYXZlIGJlZW4gc3BlY2lmaWVkLg0K
PiDigKIgVFlQRSA9IDMgKGV4Y2VwdGlvbikgaGFzIGJlZW4gc3BlY2lmaWVkIHdpdGggYSB2
ZWN0b3IgdGhhdCBkb2VzIG5vdA0KPiAgICBjb3JyZXNwb25kIHRvIGFuIGV4Y2VwdGlvbiAo
dGhpcyBpbmNsdWRlcyB2ZWN0b3IgMiwgd2hpY2ggaXMgYW4gTk1JLCBub3QNCj4gICAgYW4g
ZXhjZXB0aW9uKS4NCj4gDQo+IEV4dGVuZCB0aGUgVk1DQiB2YWxpZGF0aW9uIHRvIGNoZWNr
IGZvciBzdWNoIGluY29uc2lzdGVuY3kuDQo+IA0KPiBUaGUgY29sbGVjdGlvbiBvZiB0aGUg
aW52YWxpZCBleGNlcHRpb24gdmVjdG9ycyBhcmUgcG9ydGVkIGZyb20gdGhlIHVwc3RyZWFt
DQo+IEtWTSBjb21taXQNCj4gKCI3ZTc5ZjcxYmNhNWMiIEtWTTogblNWTTogQWRkIG1pc3Np
bmcgY29uc2lzdGVuY3kgY2hlY2sgZm9yIEVWRU5USU5KKS4gQWRqdXN0DQo+IHRoZSBjaGVj
a3MgZnJvbSB0aGUgY29tbWl0IHRvIGFsaWduIHdpdGggdGhlIEFQTSBWb2x1bWUgIzIgYW5k
IFZvbHVtZSAjMw0KPiAoNDAzMzLigJRSZXYuIDQuNDDigJRKdWx5IDIwMjYpIGZvciB0aGUg
WDg2X0VYQ19PRiBhbmQgWDg2X0VYQ19CUiB2ZWN0b3JzIHdoaWNoDQo+IHNob3VsZCBub3Qg
YmUgdmFsaWQgb24gdGhlIHg4NiA2NC1iaXQgKGxvbmcgbW9kZSkgcGxhdGZvcm1zLiBUaGUg
YWRqdXN0bWVudCBpcw0KPiBwb3N0ZWQgdG8gdGhlIEtWTSBtYWlsaW5nIGNvbW1pdCBwYXRj
aCB0aHJlYWQNCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvYWxsLzIwMjYwODAzMjI1NDAy
LjIzMjQ1OTUtMS1hYmRlbGthcmVlbS5hYmRlbHNhYW1hZEBjaXRyaXguY29tLw0KPiANCj4g
U2lnbmVkLW9mZi1ieTogQWJkZWxrYXJlZW0gQWJkZWxzYWFtYWQgPGFiZGVsa2FyZWVtLmFi
ZGVsc2FhbWFkQGNpdHJpeC5jb20+DQo+IC0tLQ0KPiBDaGFuZ2VzIGluIHYzOg0KPiAtIFJl
c3RyaWN0ZWQgWDg2X0VYQ19PRiAoNCkgYW5kIFg4Nl9FWENfQlIgKDUpIHZlY3RvciBpbmpl
Y3Rpb25zIHRvDQo+ICAgIG5vbi02NC1iaXQgZ3Vlc3RzIHRvIHByZXZlbnQgaW1wb3NzaWJs
ZSBndWVzdC1tb2RlIHN0YXRlIGluamVjdGlvbnMNCj4gICAgcGVyIEFNRCBBUE0gVm9sdW1l
cyAyICYgMy4NCj4gLSBSZWZhY3RvcmVkIGV4Y2VwdGlvbiB2ZWN0b3IgdmFsaWRhdGlvbiBm
cm9tIGlmLWNvbmRpdGlvbnMgdG8gYSBzd2l0Y2gNCj4gICAgc3RhdGVtZW50IHRvIGltcHJv
dmUgcmVhZGFiaWxpdHkgYW5kIGV4dGVuc2liaWxpdHkuDQo+IC0gUmVzdHJpY3RlZCBYODZf
RVhDX0NQICgyMSkgdmVjdG9yIGluamVjdGlvbiB0byBob3N0cyB3aXRoIGVuYWJsZWQgQ0VU
DQo+ICAgIHRvIHByZXZlbnQgVk1SVU4gZmFpbHVyZXMgb24gaGFyZHdhcmUgd2l0aG91dCBD
RVQgc3VwcG9ydC4NCj4gDQo+IENoYW5nZXMgaW4gdjI6DQo+IC0gUmVtb3ZlIHRoZSByZWR1
bmRhbnQgU1ZNX0VWRU5UX0lOSl9UWVBFX01BU0sgYW5kIFNWTV9FVkVOVF9JTkpfVkVDX01B
U0sNCj4gICAgY29uc3RhbnRzLg0KPiAtIENvcnJlY3QgdGhlIEluamVjdGVkIEV2ZW50IFR5
cGUgY29uc2lzdGVuY3kgY2hlY2sgdG8gZGlzYWxsb3cgdGhlIGluamVjdGlvbg0KPiAgICBv
ZiByZXNlcnZlZCB0eXBlIDEgZXZlbnRzLg0KPiAtLS0NCg0KKC4uLikNCg0KPiBodHRwczov
L2dpdGxhYi5jb20veGVuLXByb2plY3QvcGVvcGxlL2FhYmRlbHNhL3hlbi8tL3BpcGVsaW5l
cy8yNzM0MjgzNzg4DQo+IC0tLQ0KPiAgIHhlbi9hcmNoL3g4Ni9odm0vc3ZtL3ZtY2IuYyB8
IDUxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gICAxIGZpbGUg
Y2hhbmdlZCwgNTEgaW5zZXJ0aW9ucygrKQ0KPiANCg0KSSB3b3VsZCBhZGQgdGhpcyBuZXds
eSBpbnRyb2R1Y2VkIGZ1bmN0aW9uIGluIHN2bV92bWV4aXRfaGFuZGxlcigpLCB3aGVuIA0K
ZW5jb3VudGVyaW5nIFZNRVhJVF9JTlZBTElEIHRvIGF0dGVtcHQgZ2l2aW5nIG1vcmUgaW5m
b3JtYXRpb24gb2YgdGhlIA0KcHJvYmxlbSAobm9ib2R5IGxpa2VzIHRvIGRlYnVnIFZNRVhJ
VF9JTlZBTElEKS4NCg0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS9zdm0vdm1j
Yi5jIGIveGVuL2FyY2gveDg2L2h2bS9zdm0vdm1jYi5jDQo+IGluZGV4IDk3NWExZWFlZjgu
LjQzNzliYmVmMDkgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL3ZtY2Iu
Yw0KPiArKysgYi94ZW4vYXJjaC94ODYvaHZtL3N2bS92bWNiLmMNCj4gQEAgLTMyMCw2ICsz
MjAsNDEgQEAgdm9pZCBzdm1fdm1jYl9kdW1wKGNvbnN0IGNoYXIgKmZyb20sIGNvbnN0IHN0
cnVjdCB2bWNiX3N0cnVjdCAqdm1jYikNCj4gICAgICAgc3ZtX2R1bXBfc2VsKCIgIFRSIiwg
JnZtY2ItPnRyKTsNCj4gICB9DQo+ICAgDQo+ICtzdGF0aWMgYm9vbCBpc192YWxpZF9zdm1f
dm1jYl9pbmplY3RlZF9leGNlcHRpb25fdmVjdG9yKA0KPiArICAgIGNvbnN0IHN0cnVjdCB2
bWNiX3N0cnVjdCAqdm1jYiwgdWludDhfdCB2bWNiX2luamVjdGVkX3ZlY3RvcikNCj4gK3sN
Cj4gKyAgICBzd2l0Y2ggKCB2bWNiX2luamVjdGVkX3ZlY3RvciApDQo+ICsgICAgew0KPiAr
ICAgIGNhc2UgWDg2X0VYQ19ERToNCj4gKyAgICBjYXNlIFg4Nl9FWENfREI6DQo+ICsgICAg
Y2FzZSBYODZfRVhDX0JQOg0KPiArICAgIGNhc2UgWDg2X0VYQ19VRDoNCj4gKyAgICBjYXNl
IFg4Nl9FWENfTk06DQo+ICsgICAgY2FzZSBYODZfRVhDX0RGOg0KPiArICAgIGNhc2UgWDg2
X0VYQ19UUzoNCj4gKyAgICBjYXNlIFg4Nl9FWENfTlA6DQo+ICsgICAgY2FzZSBYODZfRVhD
X1NTOg0KPiArICAgIGNhc2UgWDg2X0VYQ19HUDoNCj4gKyAgICBjYXNlIFg4Nl9FWENfUEY6
DQo+ICsgICAgY2FzZSBYODZfRVhDX01GOg0KPiArICAgIGNhc2UgWDg2X0VYQ19BQzoNCj4g
KyAgICBjYXNlIFg4Nl9FWENfTUM6DQo+ICsgICAgY2FzZSBYODZfRVhDX1hNOg0KPiArICAg
IGNhc2UgWDg2X0VYQ19IVjoNCg0KQXMgeW91IHBsYW4gdG8gZHJvcCAjSFYgKGR1ZSB0byBi
ZWluZyBTRVYtU05QIHNwZWNpZmljKSwgY291bGQgaXQgYmUgYXQgDQpsZWFzdCBjb21tZW50
ZWQgb3V0OyB3aGljaCB3b3VsZCBoaW50IHRoZSBuZWVkIGZvciBhIGFwcHJvcHJpYXRlIGNo
ZWNrIA0Kd2hlbiBpbXBsZW1lbnRpbmcgU0VWLVNOUCByZXN0cmljdGVkIGluamVjdGlvbnMu
DQoNCj4gKyAgICBjYXNlIFg4Nl9FWENfU1g6DQo+ICsgICAgICAgIHJldHVybiB0cnVlOw0K
PiArICAgIGNhc2UgWDg2X0VYQ19PRjoNCj4gKyAgICBjYXNlIFg4Nl9FWENfQlI6DQo+ICsg
ICAgICAgIHJldHVybiAhKHZtY2JfZ2V0X2VmZXIodm1jYikgJiBFRkVSX0xNQSkgfHwgISh2
bWNiLT5jcy5sKTsNCj4gKyAgICBjYXNlIFg4Nl9FWENfVkM6DQo+ICsgICAgICAgIHJldHVy
biB2bWNiX2dldF9zZXZfZXModm1jYik7DQo+ICsgICAgY2FzZSBYODZfRVhDX0NQOg0KPiAr
ICAgICAgICByZXR1cm4gISEodm1jYl9nZXRfY3I0KHZtY2IpICYgWDg2X0NSNF9DRVQpOw0K
PiArICAgIGRlZmF1bHQ6DQo+ICsgICAgICAgIHJldHVybiBmYWxzZTsNCj4gKyAgICB9DQo+
ICt9DQo+ICsNCg0KDQpUZWRkeQ0K

--------------oYCKIjIh6O0BcLZC4UEOryel--

--------------xOmG2CtyRfoh1j4nSw617sNK
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqMFokFAwAAAAAACgkQZg+p0QLLz9Bi
aQv8CGhL7JwpBjRvW+1yc9ZUnDmBmvOdatjXerwmXFhgd9W6t2BdXvvjdYi+Uz/txces2XCMZXcY
lhH0xpYduAkzro+GMVfsfOSGX/5MNjDe8eTkn3h/YKj7yDopWDPQNHZMhUfsa7ezVuobSsKyeX2w
SFuDoPDMB5Kja8uo2m8cNFpEm3OuIhFVzNt46DK8jMletpK0Edur21W90KCd3j5AdQpKjKEvpEc3
AzOJObN46vTGWOsKIUaMbfuvq1TJf/FaVYWS33OG8sfMdK7EHKH8GV26tA5f1ginGWz3uKgiBAj0
6Qs3bmJmeMgE5SzAHnfyrc0iWZoNVIOC2em5Vg80IZ1/KovPEb85tvlrw9IFGlwo1Hb7lCdjOWdr
9iL5ns1Nmu1uvIjJdlHFY2YGAhFiScXDSZ4UVWqgxU12xYAlerZY//GB9+uaiIv/9IAf21nbILoB
6HLTeKOajq/JSI+7DHLpDrX7UEOdnXQMjro1FTRElXk3JGIyxj0n5KpKeQRR
=h6i2
-----END PGP SIGNATURE-----

--------------xOmG2CtyRfoh1j4nSw617sNK--


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 12:09:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 12:09:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398808.1635007 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyTU2-0002DD-GO; Mon, 24 Aug 2026 12:08:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398808.1635007; Mon, 24 Aug 2026 12:08:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyTU2-0002D4-Cm; Mon, 24 Aug 2026 12:08:58 +0000
Received: by outflank-mailman (input) for mailman id 1398808;
 Mon, 24 Aug 2026 12:08:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wyTU0-0002Cy-H3
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 12:08:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyTTz-00EbC9-B2
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 14:08:55 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8c344a-2eae-0a2a0a5409dd-0a2a450ac44a-22
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 14:08:55 +0200
Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8c3457-f2d2-0a2a450a0019-d155da2fe0c3-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 14:08:55 +0200
Received: by mail-ej1-f47.google.com with SMTP id
 a640c23a62f3a-c1c52d920b8so479739666b.2
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 05:08:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2496734bfcsm1318100366b.43.2026.08.24.05.08.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 24 Aug 2026 05:08:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787573335; x=1788178135; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=j2YhoGNkBJjMBx0aA28w01+IZzX50bmCA+2GGcuYGk8=;
        b=UhI4V6NXtx+nz+j1VJW/JFoirarzU9kosAecdiQXNQXTXJUl6C9kmvwYxnag0A4kye
         Cj1YYNDJmadUwrhIjkJ1UrjCZzuTaL2MpJ6sVlPJz1HlZkeEk9sxxdoH8RUfewDMI3fV
         V7+qI94Lij1WeJkGN6gJgm72AmsvugmovUlthdmnaMMmcUzA1cDFWLdknkLzAqyeNe04
         mOG9vQAics9lvW0Ui3haF9JhR6SOK5mM87p7+vekx8AiEXr0X66jOWCBGHZ7Lo3U2rXL
         cH6IgtvAQovf63azp1bMCC2YPeND/VCBbR0zk2fVjWAYSDtUsk4HJbK4dxBrkh6QSb+j
         HvAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787573335; x=1788178135;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=j2YhoGNkBJjMBx0aA28w01+IZzX50bmCA+2GGcuYGk8=;
        b=VjCc0p1vUlCpi+1ph1o4BOcgEjM23n0buwxDpXD0khQF59cpMOzOgpscn4UkqNAuO5
         mwI7HJtbemhn11Ab1rCFzpI4nanyqmayPo5JUsCWkKdgpj9eJEIoutcN7Ql9cP4LOH96
         DQo6C3cxM31SGFUR43dqQQgEgugk4lv1Wxams+kgQCg0xm+NJqqKYiYj1132VEjWH3Sy
         AmNF9YMlGyCHFd/qzca1QSl//M+8Sluv7RebS2nS2urBP/hbU4osI4mufqcZHgJI+QwA
         iXcFqR1/CcEErLrpK5aj6nMLynBRIpJtKNA3CGu3qGR2RdD2cj8xFVMNTirYs7Hnf3eN
         3BZw==
X-Forwarded-Encrypted: i=1; AHgh+RpMm2Sf4Hfn9ItD5Ll1Yzq4BDREhlkBrFWw7XPyP1pp2ksblWTAVzjZtu30x7YCLa4/LO5ITsVzZ0k=@lists.xenproject.org
X-Gm-Message-State: AFuF++lS9DCYMNHP4dD31NAxQHaV5rAP/LPWVBNM9Bu2GocKOLQlvlIq
	f7XVH4mKNQXYXdZ8FyerXDJXce21/yWXPdTV3nATJa75UHdzH/gmFWcGeAkqW5HbZA==
X-Gm-Gg: AR+sD11omI8broRjdujgebaD8LAPPZjcnnNwdeNzS65bhuEgHmqbb4IMPvzYX/BEYIS
	sjh0iF4X7gBulStoUU4JYyvJFbTUypXuTrm4Sdg4ynWfJaIL/Hxl3t9pYHJeAGoa0+XPBITXvhp
	pB0C3F1u/2cDVhlRLRUFFTdG2K7Xzf1E5bO9+LfRJ3mOPcZelYRBTqHeDb5aQx5AZUFZBZ8B3SC
	sn0Xg1NrBMYakVSTzmbZQBzIyq73Dr8AKGbQNmJJInsdcHjG+QY55zUqWbGree1p2gc6V4aB+uI
	rsBn1wyaTzEBJ2v6PWVyqXXJbMi+Is6cCRBIE9Umb1srXaj4tgGU8SQRPuHcdS+omxdu7Zpawj2
	FclmlQuKuKa4uPmGVLOtVsItjnpbHMo5npcDmSakVhL/mKwYsfLYn5ECOUck4ProRCyLTowmalk
	WXevzFPqjSVcsqYNCQKpk/suKX5GhYyyeRlerCOXX4pKvqR49x0+zvG4rbqDSgiKvj66Ye/LMcS
	9il35KGGz29MTAVP8/RtCsvg4Apw4L1XhNveZhN4YZGbZmNMRri
X-Received: by 2002:a17:907:cd07:b0:c24:b11c:6c05 with SMTP id a640c23a62f3a-c24b11c6ce6mr1310025266b.14.1787573334715;
        Mon, 24 Aug 2026 05:08:54 -0700 (PDT)
Message-ID: <94e4e14c-11bb-48cf-aced-7ed6be8ad34a@suse.com>
Date: Mon, 24 Aug 2026 14:08:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] public/xen.h: Update comment on mmu_update sub-command
 size and PTE alignment
To: Teddy Astie <teddy.astie@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Frediano Ziglio <frediano.ziglio@citrix.com>, xen-devel@lists.xenproject.org
References: <1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787573335-51AC4CFC-1AED0AEF/0/0
X-purgate-type: clean
X-purgate-size: 2493

On 24.08.2026 11:31, Teddy Astie wrote:
> HYPERVISOR_mmu_update passes a set of request, where each request has a pointer
> to the PTE along with a sub-command.
> 
> The PTE alignment padding is used to transport the sub-command while the rest

There's no "alignment padding" here. It's the low bits of a necessarily-aligned
PTE which are used.

> is used as an address to a PTE entry. The current documentation state that the

Nit: states

> 2 first bits are used for sub-command, hence the other ones for PTE which

Better "2 low its", as "first" is ambiguous.

> imply here a 4-bytes alignment on PTEs.

The part after the comma I'm having trouble parsing. Can this please be re-
written some?

> On PV64 and PV32-PAE guests, all pagetable PTEs are 8-bytes aligned, hence
> off-by-4 PTEs addresses are always incorrect. Non-PAE PV32 guests used
> "legacy pagetables" which had 4-byte aligned PTEs. However, support had
> been completely removed since Xen 4.0, and was only available when Xen was
> built in 32-bits non-PAE mode [1].
> 
> Current Xen logic behaves as if 3 bits are used as sub-command, thus all
> off-by-4 PTEs are actually rejected as being unknown sub-commands.
> 
> Adjust the documentation to match the current logic implemented in Xen,
> also expanding the documented sub-command parameter to 3 bits.
> 
> [1] 84d54d5d8b31 ("i386: Remove non-PAE hypervisor build target.")
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>

Did you forget to also add a From: tag?

> @@ -260,21 +260,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>   * hypercall. Also if so desired the OS can also try to write to the PTE
>   * and be trapped by the hypervisor (as the PTE entry is RO).
>   *
> + * Note: Historically, Xen had support for non-PAE PV guests with 4-bytes wide
> + *       PTEs (if Xen was built in non-PAE mode); which support got removed in

A native speaker may correct me, but "which support" reads odd to me. Imo either
"that support" or "support for which" (and then perhaps with a comma in place of
the semicolon).

> + *       Xen 4.0. As a result, in current Xen,, all PTE are now always 8-byte

Nit: Double comma (when perhaps none is needed at all in that place).

> + *       aligned which allows expanding sub-commands part (now 3-bits wide).

Whether the part from "which" onwards is really relevant here I'm not quite sure.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 12:45:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 12:45:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398825.1635052 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyU3J-0007UT-ER; Mon, 24 Aug 2026 12:45:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398825.1635052; Mon, 24 Aug 2026 12:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyU3J-0007UM-B3; Mon, 24 Aug 2026 12:45:25 +0000
Received: by outflank-mailman (input) for mailman id 1398825;
 Mon, 24 Aug 2026 12:45:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Stewart.Hildebrand@amd.com>) id 1wyU3I-0007T3-9m
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 12:45:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyU3H-00EjGy-F1
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 14:45:23 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a8c3cce-2eae-0a2a0a5409dd-0a2a45048eba-44
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 14:45:22 +0200
Received: from [40.107.209.2]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Stewart.Hildebrand@amd.com>)
 id 6a8c3ce1-b57f-0a2a45040019-286bd102b3b9-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 14:45:22 +0200
Received: from DM4PR12MB6472.namprd12.prod.outlook.com (2603:10b6:8:bc::7) by
 IA1PR12MB6019.namprd12.prod.outlook.com (2603:10b6:208:3d5::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.8; Mon, 24 Aug
 2026 12:45:15 +0000
Received: from DM4PR12MB6472.namprd12.prod.outlook.com
 ([fe80::4a4d:4208:3862:fb7a]) by DM4PR12MB6472.namprd12.prod.outlook.com
 ([fe80::4a4d:4208:3862:fb7a%6]) with mapi id 15.21.0339.012; Mon, 24 Aug 2026
 12:45:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WPdpcIQuygFSxM0G2BiE3bP3Gb3vHj+Dz10tiL+h15DoXHFa0AXEy5k9VIqvwEOoOvFb/eiQDK8Hw95hSuRRRWQf2K1vedFxD6ChuNMqb9rO2SRb6laJeAGIRX+42o/WOUAMVpx4uNxd9lweRoxtUBSKUp/ukL470wINRqXZrevdWKcevNuesnRiVyb/SX0yU5ml3/yiir3yx6zH3I92/JlhimBsvxL07awKExfEZeDlBcu6fA1U80cg3oGohFiFsfdlY6cAmWQwyenOH17QezFXvoLCg/EVMtk/3LtLTf5CTkqY97ZxYiyPIBxHM3X/ZFhHu/FggzXCpHRDDEjLWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GqXGEAPZorVAQCgilMyaltjUKRO43w8nx6VC8NlkFSg=;
 b=bxn3cUBot41OryiqRBFd3aRNpfKxUEMrDEcZarxqHPa6Ef0vfvYzhKCu3zlwZMSpI58jckI4h2M22NKv9CL5kdhO7xbZmTyiOsM+71PcIThzVs/VM0v2TEjARQJtFeTL0jqQN8LplqQPoot6jNYp4LxFGMqRQBqNUQ1cUpvRzNltGR5siNRrMiyJ4qOCf++bx3bZwQug8BisPQIQF7A5LCHIHrxtg1qPk4DCB5apjhz8oTnReHhrl/YBSrT6ymF82WKSOXvRa0KXLlE0FWbnyMbv9Yjn//upGNx+eRIWwuypK43LF9m8DLs6iTrN3UiyinU9jy10fs1EUdS34u+5sg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GqXGEAPZorVAQCgilMyaltjUKRO43w8nx6VC8NlkFSg=;
 b=mHgIWnz3luXhDIk5GpgFdSmIYNVFChZa7Srqjj/OhNWMrC9OHgSC0oyHa/+aQln2fuwbJk5ed7m+q171ZSvXFTFE9+ZHtsQ5i6c0mLdCaowr1HyMwPx0KtU25g06oS0RVU5Eah6PXpnVxtAno5iGevbXjSZ/+TWxhu92GcXl3ZA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
Date: Mon, 24 Aug 2026 14:45:11 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
To: Neal Frager <neal.frager@amd.com>, qemu-devel@nongnu.org
Cc: sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com,
 xen-devel@lists.xenproject.org, stefano.stabellini@amd.com,
 micheal.saleab@amd.com, john.ernberg@actia.se, matthew.l.weber3@boeing.com,
 vincent.stehle@arm.com
References: <20260805052723.2823538-1-neal.frager@amd.com>
Content-Language: en-US
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
In-Reply-To: <20260805052723.2823538-1-neal.frager@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR0P281CA0080.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:1e::14) To DM4PR12MB6472.namprd12.prod.outlook.com
 (2603:10b6:8:bc::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR12MB6472:EE_|IA1PR12MB6019:EE_
X-MS-Office365-Filtering-Correlation-Id: 8e2cdfb6-db75-4db4-4a71-08df01dd8b6b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|56012099006|10067099003|6133799003|22082099003|18002099003|11063799006;
X-Microsoft-Antispam-Message-Info:
	R6F/Kk4sikH4CKAH488XnS2/cMI03+Cx1ML21gmDpNigllhtMU0Tvo5FqRhERxAZcXKa2H0Wm4PSwxCxn96lC0OXZFjjX/arsacLqLxwCHkzP1CyD07wKPVjCrbaay2kfj3ox/ss2AWm1ZILEpu/FxPB0vfitrUsaLQQNVS9t90rihr7hqJs1Aedj2haySHz5eLw1Vq4IEtpkxZzbHKhm55/5XzMJXXiGaToXrPhbzQc9W8hktKYd355ps2tIq7PbOsC7ec4XqBMBp0coLkZ3/UrtO/UbQwQShw11f5e4lgayNjiUCh5nSlETVdeWch36oS16ZsXvkzmQuU7JGASxSaEsjDENzZxE9f/wIwnEV28STD+WruixkgJdqSa6lYXTg/lj8whV9RxIKZnvVlP4uEsf2WTDjsTkrcbRCn44OOjAQ9b6WNKMDVfXTaiP1r/d/qAIB0SrIPro27J2mCe4WPm69T8Ewrq2OV9n9fDAjkTNBmOy0NR2A8i1WzbykBuZi6FDSAyZA2fSgzm0bgm8rBWdkpSeqv8BQL9ajJ+x3rPoZGWZGbSDpg3kPF+JXShbvOjUbUrAmhxDx3UZq8UrJGDZcAEePFXEUC4/xl4Bbvy9MZ4PjMmVcGA1XrUpmC95T28JoDE8caFxJgAroz4DSaGfcvsU2I+lQebB446NXw=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB6472.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(56012099006)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?d3JHd05SRFp0ZGRqVmFVNVhDZWtGbk52ZEFjQmUvY0Z4Uy94eW9Sd1J5Yjl3?=
 =?utf-8?B?aW5BSWVyR0xQT1BmdFErejhqckk3MHFLRFV1UHd3dzdQaHdIOGpocHB6NEF3?=
 =?utf-8?B?VnFDSERHU0xYOE1ROXFxb1VUS1JtSGFMbm01TU1Gek1QMERhL2l5NEdvWHJD?=
 =?utf-8?B?OFBvMUJaWndGMUJkNTczY3NJdlJ6TGJDa0xzNWdHSXl0YzVvZ2lZSmlhRjlq?=
 =?utf-8?B?WG9VcDYrSFI3Y0xPZTAzZE8wbnBvMFV6UXhDRVJxc1liQWFaTjBVMnMyTklI?=
 =?utf-8?B?MU5ORjF0R2dQSmVkaFV5TnZ5STdWWnhSWWFTb2cxblY1RGx4T3lsQ2VPeE5V?=
 =?utf-8?B?Mk05RzlJbS9BWjN5eXBja3FLeTBSaW5VbUZGREJSUWZFN2VYbHUyVUVXTXEv?=
 =?utf-8?B?cHFiRXhRakZFQmYzSzhBVVFBTm9FbzIra3lCS01YeE5rWXk1bmpYdzdVdDRn?=
 =?utf-8?B?Vi9RQnZocm56OHlrd0cvQzRSQkdYR2JvcnNTT1NBU0JrWitFbjNueW1lQ1VZ?=
 =?utf-8?B?NWsvR3RDbEtZMlE4VnJVd294U2FjTlpWQmpBQjNqd0tDKzNRK2NGNWVZTHda?=
 =?utf-8?B?MzVoc2lHSndxb0lobTQybkk1OEpIb0dNMEphZWZBa3hQRnFSZnV1MllSaVJ0?=
 =?utf-8?B?dmFQbUJEa281Zk1qRkRkWkk2MDBiZTVLMUtlUUtMWWNCeGdWZW0rbThPM3NH?=
 =?utf-8?B?K1ZlSHpwWDFUakJjTTJmdmJ5THl5L3pNS05JWFlGOEVwcnUrMVdVbjVSaVlu?=
 =?utf-8?B?akJBY1J3amQ0UXVsNytWSVY0a3hZRk5lcnFteGVlVnBhVjFMQjRGa3RqWkhV?=
 =?utf-8?B?aDNTYlJCVzlrVFVEMmFuQndjdEhzakQwK3BOZ3ZCVktuYkpqMGFubGZPV3ZS?=
 =?utf-8?B?Q0c2Y3BJeE0xdG4vOTVSUDFhQjdSdERjUUZYS2g3dFVIU1dydzQzU2d2dXVZ?=
 =?utf-8?B?bHArTTJYbkhhS0JKMkJkVnhvS3N6ZkJ0ZURwUHZ4RkVuNVNXc01TZkR6S3ph?=
 =?utf-8?B?SUlWVzBFbSswSld1VXpnV0QxclFSbjA3dFFpdjhKQkVmRWhVdlg2M3ViN1kz?=
 =?utf-8?B?MWpuYzdMMGpJUjk5aWlRQ0dSWHgvM3BjVHg2c3VWUkUvOGdMTHBhckUwV3o3?=
 =?utf-8?B?WEUrRkxkcU1MUlQ3TjF6UktsS2xmM0NVbkFLNkxKKzdiVS9Eb1dnTFZYVU1O?=
 =?utf-8?B?d05oM3FobVVIYVFkQ1lZU2x1akUwN0kvMnppbWtTN3V6dXJPQ0k3cWJwdEtr?=
 =?utf-8?B?WWUrSlN1b3dzWFM3eWo1eU8zdm05VFRncklDemVSVTBrSldmUWxUNTlhV1ZC?=
 =?utf-8?B?WUloeXZxVXo3amxsUmhqSnZic1EyTkhTb09kc0t0eFFQVzlYeENNek1HVCs1?=
 =?utf-8?B?VjRDdy85VytYc1V3S1E0R3E5ZXVZRHM3VURzQWNvUmFPQVRvUlZzNXBWRXps?=
 =?utf-8?B?bDhjRlNWZEdLUWRHNGo0Ry9KcDcwd2d4bkZtTnhCUjVRN004MFVWTGhPVStK?=
 =?utf-8?B?emJuQVR3TzhSR2FSTHBsRFpSVzZGM21FUm04UmJ2a0NWdy9hNXpwcWs5ejJ5?=
 =?utf-8?B?dVYwSVJCM2ZnaTZiME5rVTgwR3h0d1ZWSDloMnFMTFIxWVMvYVh6WEFpNHFR?=
 =?utf-8?B?VnVKQ2kzL1hKZ1BhWFUxY29wRVJFZFN5YXJQVGc3bW9XVG1LdE1nckUybzhZ?=
 =?utf-8?B?WnVnUWtzZ3hjTnZ1cS9lUWJuM0hYakVremdQQU5RNFVaNldhZUtBdy9od29W?=
 =?utf-8?B?WENtRXcrK2t3N0hnSEZxQWV2VDVkc2tuTVVuT0RhdzFYOTR1djk5UmR3NkZv?=
 =?utf-8?B?K29vbFB2WDZHUkJKMll4QmoxQkRsRG5nRWFXdEVXZnJQSEhkVC9VdkJFZ0h6?=
 =?utf-8?B?dnZqUE4wZnRvMWh3cjY4QmFNcVNoUnpCUVF5NHArU3lJYjI3OG9VMDBURzBa?=
 =?utf-8?B?M212RFJmL0UwN3B5VEM3anhrL3hLcjg2Q1RlRVhjengzcGpJTmhSbXBteGoy?=
 =?utf-8?B?cER1dldQRm1MaUNqR1BWS2RYVDRXKzd0MmdxeWZDSEtjeWFkaTZzYStkUDkx?=
 =?utf-8?B?akl2MDQyUFRZazYvQjFqTHlPRTJ3VVJiRUFZcWV3SkI2Z1ZYaXc5MkUwNFha?=
 =?utf-8?B?dTJwdGZ1cThiNkJIYS9wMTdRVlVOc2NtNUY3MVZIaWI2MFJiUng4U2E1ZU50?=
 =?utf-8?B?ZTh6NW1yK0hiUDhjT2JTMi9tNGV5NEkrdFMzZlhMVmtSQUNqWnNZd1JJakhv?=
 =?utf-8?B?NmFIYUh1UHZxc2piTzU1SDFHRVZucC9jUkVaZk9KbjlHejZsSnJOcVQxRkx1?=
 =?utf-8?Q?GvFtCs6hpLwIjMPzor?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e2cdfb6-db75-4db4-4a71-08df01dd8b6b
X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB6472.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2026 12:45:15.1137
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0zUykAnEZR3KllfoZ2h8hZN68DD2o2qY2sAbkxB+WVrKpF/nLUHLRAwXzz/ZJKS9GUwqtjZ1oRqJ/npY+2X9mQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6019
X-purgate-ID: tlsNG-ebf023/1787575522-C18D1B50-C9E0FBE4/0/0
X-purgate-type: clean
X-purgate-size: 1128

On 8/5/26 07:27, Neal Frager wrote:
> The -I$(XEN_ROOT)/tools/include added to QEMU's extra-cflags causes
> __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included,
> triggering an include-order assertion. Downgrade to a warning since the
> version is consistent in cross-compile.
> Ref: https://github.com/qemu/qemu/commit/e2abfe5ec6
> 
> Signed-off-by: Neal Frager <neal.frager@amd.com>
> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
> ---
>  include/hw/xen/xen_native.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/hw/xen/xen_native.h b/include/hw/xen/xen_native.h
> index 5caf91a616..3e1137efc1 100644
> --- a/include/hw/xen/xen_native.h
> +++ b/include/hw/xen/xen_native.h
> @@ -2,7 +2,7 @@
>  #define QEMU_HW_XEN_NATIVE_H
>  
>  #ifdef __XEN_INTERFACE_VERSION__
> -#error In Xen native files, include xen_native.h before other Xen headers
> +#warning In Xen native files, include xen_native.h before other Xen headers
>  #endif
>  
>  /*


This is a buildroot issue, so I don't believe it's necessary to fix from the
qemu side.


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 13:09:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 13:09:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398842.1635084 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUQB-0002OD-Dv; Mon, 24 Aug 2026 13:09:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398842.1635084; Mon, 24 Aug 2026 13:09:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUQB-0002O6-BE; Mon, 24 Aug 2026 13:09:03 +0000
Received: by outflank-mailman (input) for mailman id 1398842;
 Mon, 24 Aug 2026 13:09:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <neal.frager@amd.com>) id 1wyUQ9-0002Mv-Qz
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 13:09:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyUQ8-00AmRe-HS
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 15:09:00 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a8c4269-bab6-0a2a0a5309dd-0a2a450589c2-8
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:09:00 +0200
Received: from [52.101.46.42]
 (helo=CO1PR03CU002.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a8c4268-4cb1-0a2a45050019-34652e2a66b1-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:08:59 +0200
Received: from BL1PR12MB5032.namprd12.prod.outlook.com (2603:10b6:208:30a::12)
 by CH3PR12MB8658.namprd12.prod.outlook.com (2603:10b6:610:175::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 13:08:53 +0000
Received: from BL1PR12MB5032.namprd12.prod.outlook.com
 ([fe80::3c13:eeb6:d9ef:c95d]) by BL1PR12MB5032.namprd12.prod.outlook.com
 ([fe80::3c13:eeb6:d9ef:c95d%6]) with mapi id 15.21.0339.012; Mon, 24 Aug 2026
 13:08:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=c8DKpipjr9ITkDMQfyaV5WVEbXQQorIytSjhCp57IL9O5pLWRb/3/bIcINUHkMezbx6YcV797JbxMdw8QwHax4Mfn/M0MKHVRyP9MhO0B2NCe3ZQt3g/50ZvSWVPcvSJoj+G8SFGO0Rs7rjpNiU/i1HecjPixao1cRyndI9E53VSbkib27p8/2Hv5aKIouW76ZlKIIv0h86YMAgk4VfiHTIf7w7qxMpzdUK2nKmzhhrpXw5u+BPTd4IoMPkfeIa9oFgieGEpmj7Z8EUjkSAFww5aYXd1B8OX3e6AYbMObErM/Jqbx6IBj5EC8crhEl2AHK54LorRN8YTOQ4WU4h4jg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=j3VJliHozSau3hHOQin8nch2veQW2FHnOwtfxdqPtCg=;
 b=amT58ksDUYrBFpsR3mtrdeHWXd9wkN0pa+xdJpXkVoCrOqKF1dpRyI5NyDSrJXuy4SGc3LDq6wxFY+qLMmZE6UdOqcRaTa2502ULkpbbXDvsMEF/51Qvx10GZh7XW+twb94goXyjT/AukbRZK2jFx5rFyKQQseZBKjhv3sNKxmH9TdfYbYgmGdtkFLxFxr9AyfkapqldokLC91pfruEXCZJg++WxEAGGeDt/W/34+RqFGqm5JoegOKOX+IKku7QTgsxnghDyAL3xUk9SpF6FqxpnJYCv+bbyuZ4zNAXV1ylskVydzpyjq3vD9QxQFPz/BCnhXeFhU6Ru4w20Nm2/pA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=j3VJliHozSau3hHOQin8nch2veQW2FHnOwtfxdqPtCg=;
 b=QL1Rww/uT0b3dkzCBS/zbs7PrKyZaCgujn3EcqW4J4rWQnXPire1uXS6t4znc5ZISEY+v/sB78KhcUdEEwsC0q8eKXivj4p7muYhRqumos+/XyFFbctS8E4jSfhWJ4mlnA+EPXwalvwwjoEYeUL9vk7UOAb3Eo6V/nwlFydbOtY=
From: "Frager, Neal" <neal.frager@amd.com>
To: "Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
CC: "sstabellini@kernel.org" <sstabellini@kernel.org>,
	"anthony@xenproject.org" <anthony@xenproject.org>, "edgar.iglesias@gmail.com"
	<edgar.iglesias@gmail.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>, "Stabellini, Stefano"
	<stefano.stabellini@amd.com>, "Saleab, Micheal" <Micheal.Saleab@amd.com>,
	"john.ernberg@actia.se" <john.ernberg@actia.se>,
	"matthew.l.weber3@boeing.com" <matthew.l.weber3@boeing.com>,
	"vincent.stehle@arm.com" <vincent.stehle@arm.com>
Subject: RE: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
Thread-Topic: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
Thread-Index: AQHdJJsckvnz/cO5N0ySs3v4A11/7LatQ5eAgAAFmcA=
Date: Mon, 24 Aug 2026 13:08:53 +0000
Message-ID:
 <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
References: <20260805052723.2823538-1-neal.frager@amd.com>
 <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
In-Reply-To: <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Enabled=True;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_SetDate=2026-08-24T13:05:13.0000000Z;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Name=AMD
 General
 v26;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_ContentBits=3;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Method=Standard
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5032:EE_|CH3PR12MB8658:EE_
x-ms-office365-filtering-correlation-id: 6ff080b7-9c08-43b3-40da-08df01e0d8f4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|56012099006|10067099003|6133799003|18002099003|22082099003|11063799006|4143699003|38070700021;
x-microsoft-antispam-message-info:
 3DTaVbQKrtK7rlXjQXJq/wVnLxXAhyHOsjAsTKprslkGwBGS0BofYUGVqYb+pItLkMSpoN/gF5Ukjd0mKixfm47K3eb5LBu6iNIVQnE0eLGtaTkFSE3CHmvZf1mg8hL1mXmcAEFi7YyCpIB0IkR+rcPhDkqkaMne+XaxdwZNoRoggy2DfUWgiX8cfATswThax5fngNPcBdxb2rdMCnVFJHZ9lcXhcZhOp/7eg9YNm/VIGtcj3dhTpJr0uMFL4ANDo99BdoCX99mYKdCdQSOgxosNFKlWD1HYeCBQlJLgmRtg6bivfbJ1lIEv4WO6vjqss/Lner9tySOzTpLGsbjtR0UVdcf7bJSUagQ8ey2W2X/G5ghWAQ0Dytc9CcqdndgUaXugsHXTlacS3gXVCoqf7MoOygE8530ZczNgHSjqSNXlWGuOlTnpJYbzd/bbdR7QTIlLLQWb6jMyk+/3PuQP7znygftKN5F+FS/nbgUa98yqIgRqWJUueXlfbpMsiCUqMsjAuJo0YCFaeRWatseo90Twf4l6xvgJKwXyW9g0+uJuLtdJZX8+P7fht9z827eW00AZo+Qbp9PWKDjVAuR8ThMJlwBmsz+XB1L+2fkLNj45jR4cJbovXyUBDUkJgfi9JxjxxwzsxindLsIWDqoy2t6HMmCT7Ez52IJ+tq12KRdR8vguqnYamYzIxble0UZhtiNyv53FIQRvERWOv8KsyciBW76AHcQpjeSs+WNUiu4=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5032.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(56012099006)(10067099003)(6133799003)(18002099003)(22082099003)(11063799006)(4143699003)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TnI1bzJEMC90YitqUzN6QnJTc3pDelFucXNrYUNsSm5HTkhGM1VNcVFUenk2?=
 =?utf-8?B?S3FLTUM1VWxJZml5ZHhwdkhpaHpaMEFXMXNyeHA4QjhUYjFiSnVhM2JsaGxz?=
 =?utf-8?B?U0lyYUZwWlYvQmFpL2F6L3Q3bS9NOE0xNkZiRVBaSzdRdWhLbGNLQ3ptL01E?=
 =?utf-8?B?R0FBR0d1TjNZTk1QTnpMS0tDR1h5Z0luV0tVOCtKc21nTDVVZ0tjNjkzSW43?=
 =?utf-8?B?cC9rNnpkak9UTHhvTWdNRVNONkxWRVYwYlJLUkFSWG82R2ZuZml0clFtVDdP?=
 =?utf-8?B?cVRSS2FKZXduTW1qK0lvQnRWbVNXYm9NNHpEOVh4dENFeWJacTI1Ry8wUHRt?=
 =?utf-8?B?djhUaWRBdXkzWitwaFE1aEtJNGpzT084TEU5bDdzN0dCZzFDajJ6a3d5MUhX?=
 =?utf-8?B?U0tyRlVrdmdCTzhINXZYNTBkOEZVNEp6RldpUlgwSHRzY3BLZHBITi9NM1lR?=
 =?utf-8?B?S3VXbEdKNWhCNy93THFkMk5SeDc1bmFhUjc4SjlQdTRydVRSZEFRUElnWHhw?=
 =?utf-8?B?LzVER3M3OWIrMS9oR0hkM2NVUjhSd2FyRWtIOWl4Nm9LelIrcjBlZXVvaFJx?=
 =?utf-8?B?ZjJtWVRnRnlxRlVxbDVSNnV3c3Y3NytqMnd5d3ZZbzBTRFh3UW9TQi9UYmlX?=
 =?utf-8?B?emM4UXBibmxZbEV2eVVSWnJkbkpPSi8zaFZUdTV1cThvNzV2RE1kKzZnQTda?=
 =?utf-8?B?QUxuNTZJWGprOHYzTTBBS1ROWFN2UVB1U29vdnF2MWRkTy9zUzg2RVA0ZHd2?=
 =?utf-8?B?ZDZuQklJZ0NqWlRyaWtDZENTandpV3FWVjFLcmZ6bHlxVEUxRmoxRis1cGlU?=
 =?utf-8?B?QU5nWTJZUnhhLzdWVG8vUHU2NEJvZHNiOHJtU3hNbEpXUFFjUzJ4bnF6dGl3?=
 =?utf-8?B?NHhCNmp4ZkZkWm51YVJiZ1BuNmphYWc1UGpTK0Y3cFN5Sm5XOXU3WU5tZ3JH?=
 =?utf-8?B?Mm9zNDdvbWlWVWtLWEFteHRicitiYjFNWjRzTVRiV3phNmxMSncwcVJ0R2xV?=
 =?utf-8?B?VnhGd3BrMUxVazZHeElVV2pZMVB6dzR1dGN4TTY1RUlaYUs3blQ3enoxTm9E?=
 =?utf-8?B?T1JuNXNvWm9FWWVtcjNtdi84NkdzZVJWTEh5MXp6ZFJGUVUyZjNmVC9mc0k0?=
 =?utf-8?B?bmM0OGt1S2V1dWE1MUJLekpPSWRjU3JiOE81cUpRNTlDU2dKRmNKKzNBOE02?=
 =?utf-8?B?ckdPbWpkKzBqc0YwQ0NRRHQvblI4RGlPTlNzajFMRkZuRXN6ekJSU3NGQW9S?=
 =?utf-8?B?ZXR6SHFITEtQMmJVUXZwNkF2ejh0Uy95SGNZM0hhTUxnYTloVXYwQ2dJTUt2?=
 =?utf-8?B?THV3b2QvSEZBZDloY2dnZjI2S1dFVnpCdWsxZXcwdmhPTzJzWmZ3TXI4eFdT?=
 =?utf-8?B?b0FmbmphYTFFbTIzb3JKNDJYYWlRWmZ1KysyWllyazBsT2t5TFNQeHB6QnRD?=
 =?utf-8?B?MHltUHU3MEU2SkV4bVB0NUd4N3pCdklaUzBrOFVQVjlFL0pJRXludXdxS2ZX?=
 =?utf-8?B?OWxHS3c2U3UvQ0phMU5nb21wVVp4Mk01ci84SXZMRXRGUTVhdzd2RFJGSFVk?=
 =?utf-8?B?VHZ1Nm9xbTlZUUFTbDJBTEJaTlhqeUtGUUhBaWsvL1VGbDBKcU1GbkZuU1V1?=
 =?utf-8?B?dU4yWkZhbDAvV0trWjhFT2VxQUp4ZDdvMVdJK1MwZjRMUDdhcm0rYnFTblhZ?=
 =?utf-8?B?MWZnK1NoSHI4VnpjUWtaQnNDWElYN1ZwdTluYWtSODd6RHp5Sm5EOGdTbmF4?=
 =?utf-8?B?WVpQd0dTc3dvQUp5WU9BZnYwS0FUWUl6d2hCTnRTRGorUmJmeElaRnR3MTl6?=
 =?utf-8?B?MlVnVUtOdDU5OXp3Ri9WVGNYQkd0OGE1WEdYRzhyYTlsbm1DM2x4ME8xRHF0?=
 =?utf-8?B?Vzg3YU9mOS9OYjdQVVFQY3lUOUl3VWlPOXZaRmM4MXdmR2FCVlRJZngrTkF2?=
 =?utf-8?B?b1ZCRnNHTWhGUm9IZThTelZBREJOSmRmY0VXa3l6VTVaazIrK2xSTEgvVTdK?=
 =?utf-8?B?U1IwU0RIc01tUmZvZURxWHE0YUhkMVBHWitPclFjL0VlTC9uUHZBY0s2aGpL?=
 =?utf-8?B?VnZFNXEzZThPQm1yQ1BRZXNCY2llRFlubktPUnlqalJWTUFFZ3J6cFJLbWhF?=
 =?utf-8?B?MkJRV3ovcmMyVjhuY3dLWnhlSU1kOW8yRmVscU0ycHFZVVAxYzJabk51VmRp?=
 =?utf-8?B?bkk3NVJETVhiOWpBaWVoNENsLzg1MC9lRDZFdjlDNEdRTE9yd0NQK21WWEFR?=
 =?utf-8?B?Rk56aHozVDk2OGJKaXJEOWtGUVJIRk9WTVE4clc5eVMvSUJiV05UUEN3cmxK?=
 =?utf-8?Q?seemUFq6gtmtEXzpvS?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5032.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ff080b7-9c08-43b3-40da-08df01e0d8f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2026 13:08:53.4055
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CVJhnlGn896gmItvqMU9vFgi57J9GOvYVD8se10QoHVDZQPpWuH7mtX0Bq4lcz3z
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8658
X-purgate-ID: tlsNG-c201ff/1787576939-73ABF2A1-F6CEAA78/0/0
X-purgate-type: clean
X-purgate-size: 2382

QU1EIEdlbmVyYWwNCg0KSGkgU3Rld2FydCwNCg0KPiBUaGUgLUkkKFhFTl9ST09UKS90b29scy9p
bmNsdWRlIGFkZGVkIHRvIFFFTVUncyBleHRyYS1jZmxhZ3MgY2F1c2VzDQo+IF9fWEVOX0lOVEVS
RkFDRV9WRVJTSU9OX18gdG8gYmUgZGVmaW5lZCBiZWZvcmUgeGVuX25hdGl2ZS5oIGlzIGluY2x1
ZGVkLA0KPiB0cmlnZ2VyaW5nIGFuIGluY2x1ZGUtb3JkZXIgYXNzZXJ0aW9uLiBEb3duZ3JhZGUg
dG8gYSB3YXJuaW5nIHNpbmNlIHRoZQ0KPiB2ZXJzaW9uIGlzIGNvbnNpc3RlbnQgaW4gY3Jvc3Mt
Y29tcGlsZS4NCj4gUmVmOiBodHRwczovL2dpdGh1Yi5jb20vcWVtdS9xZW11L2NvbW1pdC9lMmFi
ZmU1ZWM2DQo+DQo+IFNpZ25lZC1vZmYtYnk6IE5lYWwgRnJhZ2VyIDxuZWFsLmZyYWdlckBhbWQu
Y29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBWaW5jZW50IFN0ZWhsw6kgPHZpbmNlbnQuc3RlaGxlQGFy
bS5jb20+DQo+IC0tLQ0KPiAgaW5jbHVkZS9ody94ZW4veGVuX25hdGl2ZS5oIHwgMiArLQ0KPiAg
MSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pDQo+DQo+IGRpZmYg
LS1naXQgYS9pbmNsdWRlL2h3L3hlbi94ZW5fbmF0aXZlLmggYi9pbmNsdWRlL2h3L3hlbi94ZW5f
bmF0aXZlLmgNCj4gaW5kZXggNWNhZjkxYTYxNi4uM2UxMTM3ZWZjMSAxMDA2NDQNCj4gLS0tIGEv
aW5jbHVkZS9ody94ZW4veGVuX25hdGl2ZS5oDQo+ICsrKyBiL2luY2x1ZGUvaHcveGVuL3hlbl9u
YXRpdmUuaA0KPiBAQCAtMiw3ICsyLDcgQEANCj4gICNkZWZpbmUgUUVNVV9IV19YRU5fTkFUSVZF
X0gNCj4NCj4gICNpZmRlZiBfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fDQo+IC0jZXJyb3IgSW4g
WGVuIG5hdGl2ZSBmaWxlcywgaW5jbHVkZSB4ZW5fbmF0aXZlLmggYmVmb3JlIG90aGVyIFhlbiBo
ZWFkZXJzDQo+ICsjd2FybmluZyBJbiBYZW4gbmF0aXZlIGZpbGVzLCBpbmNsdWRlIHhlbl9uYXRp
dmUuaCBiZWZvcmUgb3RoZXIgWGVuIGhlYWRlcnMNCj4gICNlbmRpZg0KPg0KPiAgLyoNCg0KDQo+
IFRoaXMgaXMgYSBidWlsZHJvb3QgaXNzdWUsIHNvIEkgZG9uJ3QgYmVsaWV2ZSBpdCdzIG5lY2Vz
c2FyeSB0byBmaXggZnJvbSB0aGUNCj4gcWVtdSBzaWRlLg0KDQpJIGFtIG5vdCBzdXJlIEkgZnVs
bHkgYWdyZWUgaGVyZS4gV2hpbGUgdGhpcyBpcyBhIGJ1aWxkcm9vdCBpZGVudGlmaWVkIGlzc3Vl
LA0KdGhlcmUgY291bGQgYmUgb3RoZXIgdXNlIGNhc2VzIGZvciBfX1hFTl9JTlRFUkZBQ0VfVkVS
U0lPTl9fIHRvIGJlIGRlZmluZWQNCmJlZm9yZSB4ZW5fbmF0aXZlLmggaXMgaW5jbHVkZWQuIEFu
ZCB3aGF0IHdlIGhhdmUgZm91bmQgaXMgdGhhdCBpZg0KX19YRU5fSU5URVJGQUNFX1ZFUlNJT05f
XyB0byBiZSBkZWZpbmVkIGJlZm9yZSB4ZW5fbmF0aXZlLmggaXMgaW5jbHVkZWQsIGl0DQppcyBu
b3QgYSBoYXJkIGVycm9yLiAgRm9yIGJ1aWxkcm9vdCwgdGhlIHFlbXUgd29ya3MganVzdCBmaW5l
IGluIHNwaXRlIG9mDQp0aGlzLg0KDQpTaW5jZSBpdCBpcyBub3QgYSBoYXJkIGVycm9yIGNvbmRp
dGlvbiwgSSBzdGlsbCBiZWxpZXZlIGl0IHNob3VsZCBiZQ0KZG93bmdyYWRlZCB0byBhIHdhcm5p
bmcgaW5zdGVhZCBvZiBhbiBlcnJvci4NCg0KQW5kIHRodXMsIEkgd291bGQgc3RpbGwgbGlrZSB0
aGlzIHBhdGNoIHRvIGJlIGNvbnNpZGVyZWQgZm9yIHRoZSB1cHN0cmVhbQ0KcWVtdS4NCg0KQmVz
dCByZWdhcmRzLA0KTmVhbCBGcmFnZXINCkFNRA0K


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 13:19:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 13:19:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398851.1635094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUaT-0004Du-G4; Mon, 24 Aug 2026 13:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398851.1635094; Mon, 24 Aug 2026 13:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUaT-0004Dn-CI; Mon, 24 Aug 2026 13:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1398851;
 Mon, 24 Aug 2026 13:19:40 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wyUaS-0004Dh-0l
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 13:19:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyUaQ-0086Cw-VU
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 15:19:38 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8c44e9-bab6-0a2a0a5309dd-0a2a45028644-8
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:19:38 +0200
Received: from [52.101.62.47]
 (helo=DM5PR21CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8c44e7-6ca4-0a2a45020019-34653e2f4578-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:19:37 +0200
Received: from BN9PR03CA0097.namprd03.prod.outlook.com (2603:10b6:408:fd::12)
 by IA0PR12MB7508.namprd12.prod.outlook.com (2603:10b6:208:440::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 13:19:27 +0000
Received: from BN5PEPF0004698A.namprd02.prod.outlook.com
 (2603:10b6:408:fd:cafe::70) by BN9PR03CA0097.outlook.office365.com
 (2603:10b6:408:fd::12) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.12 via Frontend Transport; Mon,
 24 Aug 2026 13:19:27 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN5PEPF0004698A.mail.protection.outlook.com (10.167.245.39) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Mon, 24 Aug 2026 13:19:27 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 24 Aug
 2026 08:19:24 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 24 Aug
 2026 08:19:24 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Mon, 24 Aug 2026 08:19:20 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=oxRW0hxsqeikSE7j27zkfLhT94tWEidMzvqjvHotzdwxP5NmsJKe+/hfZdOZ59DzMAimgQ4nZZ+J15k8z5CQnrfoyKG+y7w78Tg/PZY0hBzTzxRBEQYqey6RsgrzfXa5MoJ3iVSUlpAxtg0FfpShMRcRDJ96R+gEL8XTSzKV/UgKk8ZnGmi5DcsVghmlwuwGTWjsSYvChKlTBDs6HQSN0u2Dcym/oNxcRAe/g8a4Ycxugpw013blnkB7l6BIkIIjDr8PLyQNJvM/U3G/b13Doj0qJGL9u9jqGG3jKdg67Rsg/d2uao1QiLhgbVzLHzztnHjWReMU4zgDw+DFGpidKg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XHemzan3hfP0kv9onMwiDOzs2QriJhywKMlRpZFPbbM=;
 b=CnCGu7yj/wdSeFM44UuFvDLVXOZGatia4R1T6U7jB+kxQsyuEm6kpZYdRXAhsvMLr/lzRCoaQmRIyoROLSEMhA6e/0KjN37L0Iq93qM9wUEGwm0eqzE/XuDgmfvbxFAJ+kioESJE54+1GOXuGPMXzR/PFnNed95I+F4VtPq6ps+jz02wWSUkB6tNxioHMBUUziU+o7sWfY+1wv+mmYRs2VIP3dJufHNZG0uAhLHAohVgWCvoivjEAtDx3Sfw6woQRpV3uJF8b6TH88QT/BmUPMQnfUkhx9SAjiquuUUmR2+45PlXEoQRAAGkdyE/JFkykQ0gY3iftTl2vw4arThsTA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XHemzan3hfP0kv9onMwiDOzs2QriJhywKMlRpZFPbbM=;
 b=YTqOyPbtVeBTGxYpEBLfHtVhkCQcnwS2+dGpDAOk4xIqir+vYCP9MUEeAgJUiaxJCG2fI0uxlg7e9mxfzkrK42YbPYUk/Y/FC0SZwAE8UR18Tw1M8RM1PjKIsh6LNPpBFdgZFXFbaqAO3gEOvUhnW3U10fbfMN16FbddeqdTR9Q=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <7a917d2f-eef2-4cad-a4ac-759b6ef3cbc9@amd.com>
Date: Mon, 24 Aug 2026 15:19:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/6] ARM/sysctl: Expose the supported guest GIC modes
 in physinfo
To: Julian Vetter <julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, "Oleksii
 Kurochko" <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
 <1787229623.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3@vates.tech>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1787229623.8631fc262581453bbf619ec5b2062170.1a01f2fd64f000c4f3@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN5PEPF0004698A:EE_|IA0PR12MB7508:EE_
X-MS-Office365-Filtering-Correlation-Id: 848b0db6-76e8-441f-737f-08df01e252a8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|7416014|376014|1800799024|23010399003|82310400026|6133799003|10067099003|56012099006|11063799006|5023799004|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	6I06Mr4YJhucNM/xM03m7QDLj5qh/Sk60yGhlL6yvgiELm2HBySX/R+ar3H3nvfbdwXRsgXwrKXX+WXyRbjnRYSjNnjkRb0NdB8NNgmFjDA9qzbHZOji/9CLAjlwR6JaJ/rjI2gOMGooUn208LcW5cuEBIXZz3BWm/7nIxNIgHR5355oMd0738auDfOkd1sFmSf2CUAplPiWgRNw51cyIUswJ9GYN8ngWJzOUzRIjZcSw9VHVI446RLzRKyo8Aod7g2NnTJ8kt04qwY3I2BN4ZxZSZoTh9YagcLoh+WCOELuasrX+KwkSV7cSxzyFyOmmLPQU7kxsLxHMjtXZmWPGSXutum9CvhGup5BazrTMZqi2rdBlcT8al+6MUQX1v6t+s9IIkD1cr6CGIqjpnrrtoX8vkoVkf3Js9Gf3BA0MmxzUGhStw/xT6fBiK1RJtxRQzJy2CRDrDOFGL+MUYyseI9mXap1hcruGgr51uaUQRjyOD+ARIo9MCOqKcgJMhvpP8x1MyiOuKnuAmjasTU96+ifdSk9iVmMOvce3iyOLq3srHV1sOJnQjLWcJh6W+5BoCnSZis1ja1HJuv6AhNQkxxhhzPrN5hqu9p6gyEfpwshB7tt9mG71NboyhEWlJY3KBJcMzJ8XwHEGeaZsMgNKCyFtQAQGXe44DQHKFAVKM10bKGr/FfKWrx3leKkcqi9lbp7fGDXAJH6OchuvYUNig==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(7416014)(376014)(1800799024)(23010399003)(82310400026)(6133799003)(10067099003)(56012099006)(11063799006)(5023799004)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	2Yq+MZ/yLfTu1ZIIMXFkY3i+VSgposSr+klqLMz9sPBRjzJ+f78oRNYQWAA/HVetfM8l1BB1sX+qqi4Y9qxnApTAO/fk0nvnYm5Zp0jH5cXl8uZNlmUkcKrDGugHav+lm1YbH3+szR8Wrct0lWE2XNtq63NywTtTs+ifc+tMB/OXQrYdy+Jrs+qEmsM0fumA2tsET3YanO+L1ILeg4TftGot+6ZW78nLHNPeTK6l9lEJbOeK103BQ0bDDy2I4RtCwyqG76SSkkJ7ZtLrVsgWmQM63ro8ZpVXXPbVzZ7exbjDCiX/OJFZ71/PfQ4C47L614v3DNWmh6TBSxvs9BH+KoIx7pqREOV82r1zfbo9vJh2eiButY6O48x4FH5enDfv45ECi8hPir4rhkz9jhQAoTG6t5dLRSSvlg4q19/px82EDy+K+nNMeYADswEQixfU
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2026 13:19:27.0481
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 848b0db6-76e8-441f-737f-08df01e252a8
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN5PEPF0004698A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7508
X-purgate-ID: tlsNG-720697/1787577577-313CC2AC-9FD5C06C/0/0
X-purgate-type: clean
X-purgate-size: 4058



On 20-Aug-26 14:40, Julian Vetter wrote:
> From: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> In preparation to simplify the domain creation logic surrounding GIC
> version.
> 
> On a GICv3 host, also report support for GICv2-compatible guests when
> the hardware's vGICv2 compatibility mode is enabled, rather than just
> the native GIC version.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v4:
> - Report GICv2 support when a GICv3 host has vGICv2 compatibility mode
>   enabled
> - Add ASSERT_UNREACHABLE() for the GIC_INVALID case
> - Fix a typo in a comment
> ---
>  xen/arch/arm/include/asm/vgic.h |  6 ++++++
>  xen/arch/arm/sysctl.c           | 34 +++++++++++++++++++++++++++++++++
>  xen/arch/arm/vgic-v2.c          |  5 +++++
>  xen/include/public/sysctl.h     |  2 ++
>  4 files changed, 47 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h
> index 6f9ab1c98c..26c53aaf3c 100644
> --- a/xen/arch/arm/include/asm/vgic.h
> +++ b/xen/arch/arm/include/asm/vgic.h
> @@ -433,6 +433,12 @@ unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version);
>  void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
>                        paddr_t vbase, uint32_t aliased_offset);
>  
> +#ifdef CONFIG_VGICV2
> +bool vgic_v2_hw_enabled(void);
> +#else
> +static inline bool vgic_v2_hw_enabled(void) { return false; }
> +#endif
> +
>  #ifdef CONFIG_GICV3
>  struct rdist_region;
>  void vgic_v3_setup_hw(paddr_t dbase,
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index 32cab4feff..8411deb7e2 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -12,7 +12,11 @@
>  #include <xen/dt-overlay.h>
>  #include <xen/errno.h>
>  #include <xen/hypercall.h>
> +
>  #include <asm/arm64/sve.h>
> +#include <asm/gic.h>
> +#include <asm/vgic.h>
> +
>  #include <public/sysctl.h>
>  
>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> @@ -21,6 +25,36 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>  
>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
> +
> +    /*
> +     * The GIC version(s) we're happy creating guests with. Right now for
> +     * simplicity it is tied to the active hardware version, but this will
> +     * cease to be the case if/when the compatibility modes are enabled.
> +     */
> +    switch ( gic_hw_version() )
> +    {
> +    case GIC_V2:
> +        pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V2;
> +        break;
> +
> +    case GIC_V3:
> +        pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V3;
> +
> +        /* GICv3 may additionally support GICv2-compatible guests. */
> +        if ( vgic_v2_hw_enabled() )
> +            pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V2;
> +        break;
> +
> +    case GIC_INVALID:
> +        /*
> +         * Running a control domain without having the GIC sorted yet?
> +         * Something's broken, but there's nothing we can do about it here.
> +         */
> +        ASSERT_UNREACHABLE();
> +        printk_once(XENLOG_ERR "Unrecognised GIC version %d\n",
> +                    gic_hw_version());
> +        break;
> +    }
>  }
>  
>  long arch_do_sysctl(struct xen_sysctl *sysctl,
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index 642407fd5b..5d758dd93b 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -49,6 +49,11 @@ void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
>      vgic_v2_hw.aliased_offset = aliased_offset;
>  }
>  
> +bool vgic_v2_hw_enabled(void)
> +{
> +    return vgic_v2_hw.enabled;
> +}
There are two implementations of vgicv2 - the "old" default one and a new one
gated by CONFIG_NEW_VGIC. You need to also add this helper to the latter one.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 13:26:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 13:26:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398857.1635102 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUgu-0005rt-1q; Mon, 24 Aug 2026 13:26:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398857.1635102; Mon, 24 Aug 2026 13:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUgt-0005rm-Ue; Mon, 24 Aug 2026 13:26:19 +0000
Received: by outflank-mailman (input) for mailman id 1398857;
 Mon, 24 Aug 2026 13:26:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <peter.maydell@linaro.org>) id 1wyUgs-0005rQ-0K
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 13:26:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyUgr-00225T-2H
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 15:26:17 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <peter.maydell@linaro.org>)
 id 6a8c4677-8faa-0a2a0a5109dd-0a2a4505ca52-8
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:26:16 +0200
Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <peter.maydell@linaro.org>)
 id 6a8c4678-4cb1-0a2a45050019-d155da2abc48-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:26:16 +0200
Received: by mail-ej1-f42.google.com with SMTP id
 a640c23a62f3a-c1c26d7e951so517022866b.0
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 06:26:16 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=linaro.org header.i="@linaro.org" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787577976; cv=none;
        d=google.com; s=arc-20260327;
        b=LmHtVf5ZT84M3Y/rC6fYIaf3ImVMfmgA7GdDLf8Hz2XJhsa6+vizXWK+oZtQOhTuUM
         BsqHoiI9Fsmj5NKzMeSdIOKwuub0rTFWofZGeyXW53y7i5NxKKBtqoJ34KYZwJQagpMq
         j1jUfWZ81lAvcb15jmT+A5/YaXwNJ50DJyudGWVk7zrhHegfcDrlDEkAsroT/n9VpuOJ
         LTbYm4gNGO/dFCZ4eEnOU9dh4teGBhDdIFXbwRu3eXyh148NgMMfOqKFJMeFI+3Gjmo9
         OTXU2P3uJI3ducJTpMJG2rms83NbSXsgCXTj12eXmZbC0Cdl0AEZY0k3NbOXSquEVFYc
         EMlw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=WJOQloOIABkgH6V3JAdZSvG6I3xZcRSyyak3uFeJFGk=;
        fh=Q3MFvgmBVez3lAjgQPyQRycJzUFWQ5jTf8kh/WjsKT4=;
        b=hujInGLYA7LvUUOqJrRgqnd3N9n8oDMpvV+JZqvgmkbnen6SePgk+AIhsBb6apCiao
         52vK6He3wYXGcOvBMpslxhH1WVW1nd45lzmUD4vqqoSLBr4R+E+tsK9USMj+9V5HtYP5
         WMPYEFcVATUUp8o50NODEKtGJ1r2O+UThFklESWQm5l8hsfpK+56Uy0ODraZWIzc1CSf
         fLiDzZgl7h/h0dAQwy8VdozQ7iHhs25qefb/nzXFUemWkanP5vPOgD1c6kjYxjb2meR0
         3+SQJcuC8t39+XQdQL4/ElFP2kXAacGpGQv+6Y68vZShZBiFUQjHdYS9xluPs01YwBrE
         5Kbg==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1787577976; x=1788182776; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=WJOQloOIABkgH6V3JAdZSvG6I3xZcRSyyak3uFeJFGk=;
        b=BZ3l7HwDSqZ2Ogu1Uub4Dx4PbdpnIxGv/Ax8uobXlct4R3WfiYWwqtZVnaq0VvpEXh
         LhXuTkKbLSuAIMVE7V8FXEL37vndxQ8hadnp7dVg+7SrYoE9oQFm+7btTb7eCq/3EYLw
         aHFFGFQml0uDiDcPhUp8nSV0nQmZVJV9Vvyu0KxCul7B68G5j8/Pd1wBgcuR9HmXsmxh
         uzsxkzzANGSwiS8Yu4Uc+/e20CDCIe7qo40PsfG9OliqAkNTS4KCViXD/qYzozy4b3nT
         a/sKW5QoozW0ZdL5SgppFh3UmU13ArIcrc9zBbRxxnPKTGaXz9tU8cCdLbG/GsLwz+/Q
         OyaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787577976; x=1788182776;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=WJOQloOIABkgH6V3JAdZSvG6I3xZcRSyyak3uFeJFGk=;
        b=pzcrGcLh3U2OBIl6fp/RSG1giD2UpjCLRiBLTkr5Fw82LZvdiYcMJypptpFz/rDeEC
         jvlOW+523zrYZyDrdnDvgaKvZq1/QP3kED2S0qrq896KDKXT2I4pUwF18KWO8nN3wd99
         42nAXRRjn6T0zsT6U5itlG7xUTlMFrkUF8vXmPjwm7ctYLR7XkBqtwTraVSrO0UCb+xL
         XoS4HNtcfZLlJt1mlE0cqb5A75KDgEqJ0Zmu0cNYA+cBJDwuHgG8TdTB2Brpeg6oK4zG
         r3nvt7H5EdkmknLhzXXDBib+MtPgPvZWRK4Eld5U1FKH/pJoDv/O0OXkPLpniDbyuZR3
         W3jQ==
X-Forwarded-Encrypted: i=1; AHgh+RqFOwYZPNsrZAkL9vtaMpBjpc5NnhcLdONvgoIyISUlKX9P4CCyXrXQBs1HT4wu24Qm/ausWqg7wz4=@lists.xenproject.org
X-Gm-Message-State: AFuF++nseN5TaxWG+7hW6BDbuczAF2rIZ5rr7Ix82gejMUf5o+T70siz
	pB6NpSXCFVC3VNmwwBMyXF66wz35AXhFt7YLeHv64JQLfh26uTfZHSLieC26KOnbVJJmFX8k/jr
	RckCoz+v+5UMHSwK2335aChW4/+rhUz06Od585+oSJQ==
X-Gm-Gg: AR+sD10LX32G5RNI+wgZzYX2ma6DDRk65DVZtsfsdncyFCEzCsZpAp2SNJZIOBP25TR
	UIolrtkaKq1nZfFjshP4FM5wrfZ5BB5PSJcaZ0ByhewxLsjUhiSd6JRrbk3qz3eMCJOYOwNqXyn
	LfqfPFgU60/P6XApuVETw5LznNa3plIYirmEDdbQ+Mh5f8hncHgq0fuqyyR36UhljU1e4eiXKfR
	WbiqCEeJNnMuaKFeyf6KeOi2sWO+tkzGNNWpn9ob91OwAjBB70OCDN/NutnpfWBefxOIf7sPoOG
	y3ibRyPQmO8sWI9Uv9WnttWdTRxjEwuKoxvvYZkfHKJ0iGpMUPLtffKSLeprykOm3MQ/lCRIFDG
	q0sFWxr0CQkxFEynJnZEUuk+rLl4G
X-Received: by 2002:a17:907:7b93:b0:c20:5213:56f1 with SMTP id
 a640c23a62f3a-c246a60348emr2829725766b.13.1787577975945; Mon, 24 Aug 2026
 06:26:15 -0700 (PDT)
MIME-Version: 1.0
References: <20260805052723.2823538-1-neal.frager@amd.com> <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
 <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
In-Reply-To: <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Mon, 24 Aug 2026 14:26:00 +0100
X-Gm-Features: AcwNN1VvxlRRRHvnKb0O7rD1SVWHvRL8XBQeDCQKBO42isGO3VyXT47Xz83_lqU
Message-ID: <CAFEAcA8sWn1vjm+OFYzwA-jko2vYkFcWPwT6g9=0AeO+JQo-JQ@mail.gmail.com>
Subject: Re: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
To: "Frager, Neal" <neal.frager@amd.com>
Cc: "Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "sstabellini@kernel.org" <sstabellini@kernel.org>, 
	"anthony@xenproject.org" <anthony@xenproject.org>, 
	"edgar.iglesias@gmail.com" <edgar.iglesias@gmail.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
	"Stabellini, Stefano" <stefano.stabellini@amd.com>, "Saleab, Micheal" <Micheal.Saleab@amd.com>, 
	"john.ernberg@actia.se" <john.ernberg@actia.se>, 
	"matthew.l.weber3@boeing.com" <matthew.l.weber3@boeing.com>, 
	"vincent.stehle@arm.com" <vincent.stehle@arm.com>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-c201ff/1787577976-F7CB82A1-10C05EE8/0/0
X-purgate-type: clean
X-purgate-size: 1316

On Mon, 24 Aug 2026 at 14:14, Frager, Neal <neal.frager@amd.com> wrote:
>
> AMD General
>
> Hi Stewart,
>
> > The -I$(XEN_ROOT)/tools/include added to QEMU's extra-cflags causes
> > __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included,
> > triggering an include-order assertion. Downgrade to a warning since the
> > version is consistent in cross-compile.
> > Ref: https://github.com/qemu/qemu/commit/e2abfe5ec6

> > This is a buildroot issue, so I don't believe it's necessary to fix from the
> > qemu side.
>
> I am not sure I fully agree here. While this is a buildroot identified issue,
> there could be other use cases for __XEN_INTERFACE_VERSION__ to be defined
> before xen_native.h is included.

But what, though?

> And what we have found is that if
> __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included, it
> is not a hard error.  For buildroot, the qemu works just fine in spite of
> this.

I think that just means you got lucky. Either there is a hard requirement
for one header to be included before the other (in which case it must
be a #error, and whatever is causing the mis-ordering to happen must be
fixed), or it's fine for the ordering to be either way (in which case it
doesn't even need to be a #warning).

thanks
-- PMM


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 13:31:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 13:31:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398864.1635113 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUla-0007Sd-J2; Mon, 24 Aug 2026 13:31:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398864.1635113; Mon, 24 Aug 2026 13:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyUla-0007SW-F4; Mon, 24 Aug 2026 13:31:10 +0000
Received: by outflank-mailman (input) for mailman id 1398864;
 Mon, 24 Aug 2026 13:31:08 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <neal.frager@amd.com>) id 1wyUlY-0007SP-Gj
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 13:31:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyUlX-0088b2-G9
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 15:31:07 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a8c4797-e002-0a2a0a5209dd-0a2a4508b06c-10
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:31:06 +0200
Received: from [40.107.200.42]
 (helo=CH5PR02CU005.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a8c4799-f659-0a2a45080019-286bc82ae274-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 15:31:06 +0200
Received: from BL1PR12MB5032.namprd12.prod.outlook.com (2603:10b6:208:30a::12)
 by DSVPR12MB999310.namprd12.prod.outlook.com (2603:10b6:8:41e::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 13:31:02 +0000
Received: from BL1PR12MB5032.namprd12.prod.outlook.com
 ([fe80::3c13:eeb6:d9ef:c95d]) by BL1PR12MB5032.namprd12.prod.outlook.com
 ([fe80::3c13:eeb6:d9ef:c95d%6]) with mapi id 15.21.0339.012; Mon, 24 Aug 2026
 13:31:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MGsKRcKZR9hZ+5cgAwV+O1bw5ieNAcHZjCEoBqvSZn3mhHlEFhhYCZ930Xxlu6uQVpfmMEV08Z+tsJ8d9WAVhGJlkWlNo6mtX7H+bcJ81+ax9JIj413nNNfrJE+DuZuk+rg1IaIRdKtgQZJvhBOhx+AXvk5sirj9UIxM8N5/IHFCQ2ubcTnrs66pBMAa7AcVkn84jS9+yn2Wjz55BODqSkp466CoRqIFiQWPn6scJXXSdsR8bgbfMu42eIXxuo0tIwaDzvIZug5Cg5Jw6Kf+eRvQn71VjavJ+S6LPoSKGnRU6qRYOyhv0VmXIUeFMK2Pygjha0AqFuDaLo9trMe/sw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=quEor2gylcZ4dQoDnP21GY4cNRxz+KjlMVJQt7mHae8=;
 b=P3kpeDz5F8UTo5qYHyjGbPGZz5Q5xmnlOp7LKPAx42ocNsoGzXFSalCBeY5Gp8CBtPucpnWT2vQBOG6eBG0dG4CMimNGMusa9vqT02GQxe3x7+ENedkRdF7mkgwUiUlQl/6eX2Tx1ZhkIuKsh5C12fM9WUzUcRDYO36n01b5OAOgct+o7IQx776bwCsxaRS904jw/8MyK+m8oUuivU16khgwajpjCIBFBmo+jLVKvIMLxsJj9NFasFf+T++KAhtqh3OaRYmCLF7J7VsnQJen5L07ntsqamPktTPRW5xP2lGZGdgn6WD1vp/SpCTvznLebJM3ECVFOwCAqEeSbDcQLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=quEor2gylcZ4dQoDnP21GY4cNRxz+KjlMVJQt7mHae8=;
 b=tlyPryuIbkDym5xiLCVq1OEI0Zdza6yGQmQ9mXtcaOjXGNsYI3lVQJbwd7v2yxEE+Z17ehSkRpN/sGN2ogQw+6dO3xFrED6sEG06pyFBTi9zf4sismIJ/aC+c58KL18X7+V1UZhBn0hhHBBNWaUJEiNYasdE7l3zCcDefOkJP+Y=
From: "Frager, Neal" <neal.frager@amd.com>
To: Peter Maydell <peter.maydell@linaro.org>
CC: "Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "sstabellini@kernel.org"
	<sstabellini@kernel.org>, "anthony@xenproject.org" <anthony@xenproject.org>,
	"edgar.iglesias@gmail.com" <edgar.iglesias@gmail.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Stabellini, Stefano" <stefano.stabellini@amd.com>, "Saleab, Micheal"
	<Micheal.Saleab@amd.com>, "john.ernberg@actia.se" <john.ernberg@actia.se>,
	"matthew.l.weber3@boeing.com" <matthew.l.weber3@boeing.com>,
	"vincent.stehle@arm.com" <vincent.stehle@arm.com>
Subject: RE: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
Thread-Topic: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
Thread-Index: AQHdJJsckvnz/cO5N0ySs3v4A11/7LatQ5eAgAAFmcCAAAXOAIAAAMSQ
Date: Mon, 24 Aug 2026 13:31:01 +0000
Message-ID:
 <BL1PR12MB50322B1D97569B5CADEC8E55F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
References: <20260805052723.2823538-1-neal.frager@amd.com>
 <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
 <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
 <CAFEAcA8sWn1vjm+OFYzwA-jko2vYkFcWPwT6g9=0AeO+JQo-JQ@mail.gmail.com>
In-Reply-To:
 <CAFEAcA8sWn1vjm+OFYzwA-jko2vYkFcWPwT6g9=0AeO+JQo-JQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Enabled=True;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_SetDate=2026-08-24T13:28:44.0000000Z;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Name=AMD
 General
 v26;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_ContentBits=3;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Method=Standard
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5032:EE_|DSVPR12MB999310:EE_
x-ms-office365-filtering-correlation-id: 27de5415-703e-4129-ff6b-08df01e3f0cc
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|38070700021|6133799003|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003;
x-microsoft-antispam-message-info:
 ftlHy0XSeh/p9lOxehx2+HpXxAvXChDoQNps/6Wz7BHXgPW0WAoTnlH+vzGEzR77XgQ2bbxZGdxK4NSMZ5gxVaq2zOCFajQbtuYXJZ5NTBelRrl/Kp7tfNZm1g76ATw5Ar5BS7xxAdTsBhfkFAVDafUNzYPtRbmZu79b2u659RdZFNYhCTBBKO35Bvq0EVeu01xJ8puVAYy/NQaon0+GBgC5PfOOP6okKpC4uSblkCkrZJcO1ChdmgbTlbTRSVr2lFcJvc1sbGEl4rE8qCnfJkiCkCDATHfSQUub4JeU+y+XLmlpU92vtJhXVVWWwXEK2pBuzCirC/8ChwNi2yXXEw+9wMG+IMKPKlm70OwV4Kx/2nODbf6fN8Jsja7t97ZOEJG4Gyz2HVundOuYQyEi9J/VafaSLMzg2gEl4IfBpMtNZYLtkMRJgtGjBL9RsQH2Vpv1gkGNtTokoPAd7FHhGQEiyBgk34MqvGCwFW5mHUpCCIpHWU6UaJiuTCEIJNo6JMRuJy6uIfCrOGCvgDcuW68L1txga0R379qtiM9Oo4k6tRwYapq7gf//Tg3r6jtoiMTYfnHV0DbWX8IIw/7Q6SOJe0U3m6cDq6x/MBWRX8YTPROVIawKKPjWc39AScEKa0CZseG3+5hruVsBuvKDzYT7r63XSNibiMsNDmsFSoRkHQKLhtHnvnsJcLpucWVzxkhKDAk6xQiOe+XPVmjGSaNVQJTtsOZLmcePFpHKbws=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5032.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(38070700021)(6133799003)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MzQrYVp3cTlMRTQ2Nk50TzkrSFdSK3RrbzNPK2s2S3VWTjc1aWNzNWZJOVpK?=
 =?utf-8?B?cFFOLzdIUWg1TkRmeVlMeVpYUlV2SUV6MXlUeldyc2hLYm1obi9XM0lqcWNt?=
 =?utf-8?B?aHVtaGhFOEVsTEtMekdVS0lUaG9hYnUxajNEL09BVVJrL1QzVmxWNHRUS1hT?=
 =?utf-8?B?bnExbFU3MENqSHhhclA5em1EMDFQalJOWjc3aU1pZW9iUm9sQ2g3elRUbG9h?=
 =?utf-8?B?VHQ0akp3cm5vTGM5bWtMa0QvemZSVVEzY3hPVlJLMnNzNlVoSFVWY3dXbDNa?=
 =?utf-8?B?ZG5DZVZWd2pTaHlHVk9xUmxjSU1RSUFsOFhGTWdBS2F2b0h2a2dRWkhnWU1W?=
 =?utf-8?B?K0tBdHJYT09QWVBPV0lldUZPdThtYXFKYzZvQ3MzcUJOMlV2ZDlwL3FoZGhz?=
 =?utf-8?B?ZVlObG11d3ZuQlg0clFFWlZGb2JaQ3pSSDZ5aFpsRzl6aFo4KzhqU2FlcFJ5?=
 =?utf-8?B?cFQ1ZjJHbktrZEl6WE5nbzYwN3pZSWZFRHJTYlJkMEZYMjYxNVNlWFVWRDl4?=
 =?utf-8?B?ZVNwN3h0YlpqNndlbUZ2R3hFMlhTbi9rRUtXcXlwUmU2UXVRbmFOYSthK2kv?=
 =?utf-8?B?RTRZRlhWMVNiTDg4U2Q0YWZJVmVwQytLZFdlclFwU285U1FUQXVLRlhZeHhq?=
 =?utf-8?B?MUgrOUM3a2drcGMxYzRuYkhCRGs5VWtYVGtaSEdGK1FnRVhmQUdzMUhhQVFn?=
 =?utf-8?B?ci9DRHlHb21ibFhNNWYwUzlGYi9va2lXOWN1TnJLU0o0em1YOG1qbWNVVm50?=
 =?utf-8?B?WTdRNzVlVFROU1h4d2xJMCtVUUdoRjRETTNyWUlOZUpKd3pqMjJpYWNsMTJi?=
 =?utf-8?B?SkRpYkxOTFUyWGRZc3lUcTg5SEc4andWTHphb0kvTkw5RTM2RGtKL3RhdlBY?=
 =?utf-8?B?NlE0ZHpWR2k5OG04V1hRTnl5T2FBZStmNjNFRGg1S0F6b1pSWHFOMTRWVXg4?=
 =?utf-8?B?a1ZqdjFIQjByanJuMXprc2pFeFlCOWhjQmZaWGFYdGlsaWJ4M2Q1WGlZS25D?=
 =?utf-8?B?RFcyc3BtaVhaaXp2Q2FzdEx5ckowbk5ncWJFYjl0SVBybzBlK1ZmL1BxWSsx?=
 =?utf-8?B?Q1VKVFVXanlXQXREWGIxZXJaK0tvam01UkhUeWIxcHlpbkhiS3p3eFZ2bktC?=
 =?utf-8?B?QnhndVJSbFZCZ1pneW1nNFU3b0ZKQnFiRzIxQ1MycWVXblFmZXdUQ1BqRFo4?=
 =?utf-8?B?MHFYS01aLzV1RGlpQmdxT2tGYnpiZ1RTcVV5VEt1M3lYakQ5VmQxRGtJbzhJ?=
 =?utf-8?B?bVdUdGk5eUo0QVBZUjNnTUxabkNmcTE4U04xVGhzck9wckZjR09DVlhMdFBq?=
 =?utf-8?B?dEFiRFFyanQ1TG1DTnVPVE91ajVXK1R2S0U5dG1nb0UzZG1GTTlocjdBajYw?=
 =?utf-8?B?WW5LRXZYeHFJWTlBdVVPQTFhNG9uVTRZbzZJYllBT0ZTaVIrM3V3V1JsYXhx?=
 =?utf-8?B?c0p4dkpIb0x6aE80ZGhHM0dvVUhOR252Y2lqRXZvMkhVbG41Rm9tek5CYjha?=
 =?utf-8?B?RExWS1F6RDhMS2NjbS9zYXJkb3dtU3hpTWxJZ3ZudGM5MHJuZHdmUGlXTlQz?=
 =?utf-8?B?ZFczbjU0ZGhhWWJxUG15dTIwYzZncjhaL3lkNmo0T0xzTTl5U1ltZ3J0UVBO?=
 =?utf-8?B?Qmh3TnhjM1IxYnd3ZmNEOVBuRVVMTXA4cWpiSm9qZi9QSUdQZDZQbk1wM1Vt?=
 =?utf-8?B?MnJjdWZ1eXpuZTVvL3UzazNKL00wL0Z6emRZTk00OTkyTFFZRFlZVmRqNFhj?=
 =?utf-8?B?K3lzSEUwZDZ4cFFDdUMxQldFSnpyRlRDY0IrUFd3MCtqdjFXWUFSN00rb0xC?=
 =?utf-8?B?RHlmVUhDbGhhaUdNV0RVZXYyNU0rdmVwOWFPU3NhR3V3MmM5L0RvNUE3OGpX?=
 =?utf-8?B?MDNKMHpLQmlkZUJSbzZ4Q1VTWXFIaVp0V3lqUkZpUkN5Rmk3dzV5Sk8ydU1h?=
 =?utf-8?B?UDk4Q1FldWI2blhQK2o0Smd1NGllbDNuNmV5Z0dQbXRmWlJHemczckdCcTY2?=
 =?utf-8?B?aXFqMGduV1RwZlJZaXFjalptYVpwNU5HZFowenBIL3RNUGM3MnNhRzFpUkhu?=
 =?utf-8?B?MUZzdm5qM1QremZJM2hncy90ZDFlNEJreTBlcXNram5XOHhlb05UeDFNSDY2?=
 =?utf-8?B?eHhQMklDdFlpOGlmcTZxV0F2aGtyMGt0LzJuUVY3R0xhMHR2cDdpUjFXN05Y?=
 =?utf-8?B?OGFtdVRDV3dkbmFoem5GSGl5c0VsM08rTktSajlDMWVUZlg5cDVKalAxdERm?=
 =?utf-8?B?Qy9CcHJJdWg2dXlmRGNpeTUyMnRmeHdvY0dOMVo1c0VRWFliOXc0L1ZWQk1n?=
 =?utf-8?Q?e7jMPaW5us8DGAUq9r?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5032.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 27de5415-703e-4129-ff6b-08df01e3f0cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2026 13:31:01.8847
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: e6oHlze76a1qQvRn8vjgKaPUShJQVAarM/qQgeVey3AVG/2gk7YA8Rlcvl6uWzwF
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR12MB999310
X-purgate-ID: tlsNG-c1860d/1787578266-D654487B-6F69CD01/0/0
X-purgate-type: clean
X-purgate-size: 2028

QU1EIEdlbmVyYWwNCg0KSGkgUGV0ZXIsDQoNCj4NCj4gSGkgU3Rld2FydCwNCj4NCj4gPiBUaGUg
LUkkKFhFTl9ST09UKS90b29scy9pbmNsdWRlIGFkZGVkIHRvIFFFTVUncyBleHRyYS1jZmxhZ3Mg
Y2F1c2VzDQo+ID4gX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXyB0byBiZSBkZWZpbmVkIGJlZm9y
ZSB4ZW5fbmF0aXZlLmggaXMgaW5jbHVkZWQsDQo+ID4gdHJpZ2dlcmluZyBhbiBpbmNsdWRlLW9y
ZGVyIGFzc2VydGlvbi4gRG93bmdyYWRlIHRvIGEgd2FybmluZyBzaW5jZSB0aGUNCj4gPiB2ZXJz
aW9uIGlzIGNvbnNpc3RlbnQgaW4gY3Jvc3MtY29tcGlsZS4NCj4gPiBSZWY6IGh0dHBzOi8vZ2l0
aHViLmNvbS9xZW11L3FlbXUvY29tbWl0L2UyYWJmZTVlYzYNCg0KPiA+IFRoaXMgaXMgYSBidWls
ZHJvb3QgaXNzdWUsIHNvIEkgZG9uJ3QgYmVsaWV2ZSBpdCdzIG5lY2Vzc2FyeSB0byBmaXggZnJv
bSB0aGUNCj4gPiBxZW11IHNpZGUuDQo+DQo+IEkgYW0gbm90IHN1cmUgSSBmdWxseSBhZ3JlZSBo
ZXJlLiBXaGlsZSB0aGlzIGlzIGEgYnVpbGRyb290IGlkZW50aWZpZWQgaXNzdWUsDQo+IHRoZXJl
IGNvdWxkIGJlIG90aGVyIHVzZSBjYXNlcyBmb3IgX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXyB0
byBiZSBkZWZpbmVkDQo+IGJlZm9yZSB4ZW5fbmF0aXZlLmggaXMgaW5jbHVkZWQuDQoNCj4gQnV0
IHdoYXQsIHRob3VnaD8NCg0KPiBBbmQgd2hhdCB3ZSBoYXZlIGZvdW5kIGlzIHRoYXQgaWYNCj4g
X19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXyB0byBiZSBkZWZpbmVkIGJlZm9yZSB4ZW5fbmF0aXZl
LmggaXMgaW5jbHVkZWQsIGl0DQo+IGlzIG5vdCBhIGhhcmQgZXJyb3IuICBGb3IgYnVpbGRyb290
LCB0aGUgcWVtdSB3b3JrcyBqdXN0IGZpbmUgaW4gc3BpdGUgb2YNCj4gdGhpcy4NCg0KDQo+IEkg
dGhpbmsgdGhhdCBqdXN0IG1lYW5zIHlvdSBnb3QgbHVja3kuIEVpdGhlciB0aGVyZSBpcyBhIGhh
cmQgcmVxdWlyZW1lbnQNCj4gZm9yIG9uZSBoZWFkZXIgdG8gYmUgaW5jbHVkZWQgYmVmb3JlIHRo
ZSBvdGhlciAoaW4gd2hpY2ggY2FzZSBpdCBtdXN0DQo+IGJlIGEgI2Vycm9yLCBhbmQgd2hhdGV2
ZXIgaXMgY2F1c2luZyB0aGUgbWlzLW9yZGVyaW5nIHRvIGhhcHBlbiBtdXN0IGJlDQo+IGZpeGVk
KSwgb3IgaXQncyBmaW5lIGZvciB0aGUgb3JkZXJpbmcgdG8gYmUgZWl0aGVyIHdheSAoaW4gd2hp
Y2ggY2FzZSBpdA0KPiBkb2Vzbid0IGV2ZW4gbmVlZCB0byBiZSBhICN3YXJuaW5nKS4NCg0KRnJv
bSBteSB2aWV3LCB0aGUgb3JkZXIgdGhlIGhlYWRlciBmaWxlcyBhcmUgaW5jbHVkZWQgZG9lcyBu
b3QgbWF0dGVyLCBhbmQNCnRoaXMgc2hvdWxkIG5vdCBiZSBhbiBlcnJvci4gIEkgYWdyZWUgd2l0
aCByZW1vdmluZyB0aGUgd2FybmluZyBhcyB3ZWxsLCBpZg0KdGhhdCBpcyB3aGF0IHdlIGFsbCBh
Z3JlZSBvbiBpbiB0aGUgZW5kLg0KDQpCZXN0IHJlZ2FyZHMsDQpOZWFsIEZyYWdlcg0KQU1EDQo=


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 14:13:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 14:13:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398875.1635121 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVQP-0004oM-L9; Mon, 24 Aug 2026 14:13:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398875.1635121; Mon, 24 Aug 2026 14:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVQP-0004oF-Hm; Mon, 24 Aug 2026 14:13:21 +0000
Received: by outflank-mailman (input) for mailman id 1398875;
 Mon, 24 Aug 2026 14:13:20 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <peter.maydell@linaro.org>) id 1wyVQO-0004nq-FZ
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 14:13:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyVQM-002AhK-Cs
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 16:13:18 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <peter.maydell@linaro.org>)
 id 6a8c517e-2eae-0a2a0a5409dd-0a2a45069f78-0
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:13:18 +0200
Received: from [74.125.224.44] (helo=mail-yx1-f44.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <peter.maydell@linaro.org>)
 id 6a8c517d-195a-0a2a45060019-4a7de02cd170-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:13:18 +0200
Received: by mail-yx1-f44.google.com with SMTP id
 956f58d0204a3-66825847b2cso3690101d50.3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 07:13:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=linaro.org header.i="@linaro.org" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
ARC-Seal: i=1; a=rsa-sha256; t=1787580797; cv=none;
        d=google.com; s=arc-20260327;
        b=Qeg06ijEBpORyr9Gl8Ew6ZO5gbWGtAlZl83SwIHJFH8CVT7tNeI7yl/nHpfWuRZNJj
         0LlSa797EwyMM7VhhTfYNvERVJAg12jSOOMVgRY+OGXy3oxHz2K/ucE0a3X8sWwiIqyK
         Isk5luHTQLQ8Ae6JrZLBtyL4XMZGhhtdabL9C3760HU9qJ9kbFHj3zoQ6USDP7TzPflS
         EueXxxg0TP5n3Gi4Sy076mRQKBWwbDCXOXj1l0zh3k7muewvgp8vJjL15q4ySU3XuROi
         KmfWzZ4pedGyoxpPhhSK7qcghue647vZBskUW5sd67lHDTUgjJ7IVzznu6joJ9wMcJgh
         QeEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=i90qMMZqov8wxYQ380J3TeVkiRq0NLJOwuvPuDjyrj0=;
        fh=sv8mYavBC6Z+YQNb7RBJnfB0wI4gDSvMcgATypxev0M=;
        b=lqMnEU+1Fmwbs2hulQllQmMWuzlhaqhLkqJ/Szk+Oav9mtPliSf8mGklnuN9HkDBHK
         HEsHUBsTA8nw4xPfJl/txWswB3xhZmJDZ25o6+8dFYu28bCUkgUYwvHlp/mZ+JlAc4Bm
         sAIAxQbyCQVYALZ/o8nuz0o/3A87NX/SzNXP+0ykscLoPVh8U75T+b0JtJTrKgV+vqDo
         UdKKLz75I3MQ7ghgaZJ5k5nVO1gap6mSE/3mZp6Y681jlJZCyBSHCQ84PRDbK8pgtlSd
         hjyRzMOC7baaIte5sv5SF+4OgmT3xEmzWEAytJHLDAFk6oKO6txhxaynYeKld9NTmKhK
         R4KA==;
        darn=lists.xenproject.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1787580797; x=1788185597; darn=lists.xenproject.org;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=i90qMMZqov8wxYQ380J3TeVkiRq0NLJOwuvPuDjyrj0=;
        b=pC+SbYFhtQmSazvGjNjDJefjVhlGADMWsgr4i8PNtQR4ErF+l/T7+rvVCwMdREmyuu
         zJKMnQs/SK8IJDWlBw2fSne2DUilN/MvQDWVDh1Me7i3/2em9L8wZs0NxvznyWwNXWxn
         7JBujxyoBsKAebiK+hCHGI/kToOi3LYNhmRCgmM62EKf3je0l51DyrS5PwsFrTljnWjp
         yiKs/PsqiPw8bcu/M6vnHzWV5z8k8t7eJMo78DHGNlFS1k1KiQNYZbkZycKjU5Dp8RjX
         gn8/4b4u2SNQS7xd7dVaCddO+xL5yC3kq2olwmi2LRVFO6+sjagAOgNyMtvL/g72Nkhh
         T8ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787580797; x=1788185597;
        h=content-type:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=i90qMMZqov8wxYQ380J3TeVkiRq0NLJOwuvPuDjyrj0=;
        b=FPjSAzGK6JvQsqHhNFT5KxeoFjUSkU7gqwtAkph8TvBUAtAxd+DbzLgSZyagqnfHtZ
         S0AW1WbVLJOT/rCPKulH2I4PHwSqvqOqBzyix68+ZE78dvPRsnyssEhROvZgoYFrhf4I
         hURAaSiu9I5ZO2L3XavYVwJVMEe8N0pHtFSNOiqxg+6AOBB/SXOj/E1byfhdxoKjX10y
         XDtAGle8Wu1KNDTl2euF9S6D8Y1svLYyG+hcpYGFiEGTz2tjxOc/tDQTMlmLmf7VFtsS
         DxtqTbjl1VGe4tYIzq1/mqM/JRjGPq5uHNOp8Y82Mwd90/j+1r4VsD5Z+DNXzl+q9gT7
         4v4A==
X-Forwarded-Encrypted: i=1; AHgh+RqLKKpI6Y8Ivj3Ee5JDUfWlDQ+Gx3YxnWleysyH8Lrzgh0HjWVyMXTO4xly3U38buD1Edpu7peb6Hw=@lists.xenproject.org
X-Gm-Message-State: AFuF++l0NzkrAhlbpbjQx+VTio4avBxKlF8GKeZUVI5cJpXHqwE3x0EK
	ORPA6KB3ldunBV1LUxyh0/WJ5YE+sf6tD900U0Ww0WrpO7loWTdJAdVJFOT8otTyZs+CfoCMDHL
	p9w0MvGCPGuMRcOGCVtvXyGvbTgdKjON3BGMX92VQfQ==
X-Gm-Gg: AR+sD12wad5vU7Caff6NvH0sIrRgaUpPe3jHiImF7Nye/NHor1K/7W6PU3VsOmKeRjA
	qcJsFHW3mRl1hBG2sAh5OrE50tbhXkicf1DZcLGJsPQ2mUVHfCgIpz20txoDqjSwPBchGrT2tpM
	P04Zg3yWe8n5uNFW38/k+PDzDgGZ6lPDNhAxeOcz1g7NjUQ2tqmU4Bjf+mnLXhyWkeqfYLzgz8g
	yJWDdnZiuPqVg1XygWqHhuGedwR+LL9tgFrmA8lWy18AfgkFSaVU/NH5jR1rf4BhR4BO1vaI11v
	uoXJFRvKrgjVrvwkiK59YgWi75lr34k8dFlaMCPjPZYA3vlByK9cni3UbfRSKvF/8a8PyUv9IJu
	t8RTjGq/Pz1XZq1eTME7sVTnWdT1B
X-Received: by 2002:a53:ac9d:0:b0:66c:9f99:9133 with SMTP id
 956f58d0204a3-66cf21bc69cmr6817963d50.29.1787580796530; Mon, 24 Aug 2026
 07:13:16 -0700 (PDT)
MIME-Version: 1.0
References: <20260805052723.2823538-1-neal.frager@amd.com> <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
 <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
 <CAFEAcA8sWn1vjm+OFYzwA-jko2vYkFcWPwT6g9=0AeO+JQo-JQ@mail.gmail.com> <BL1PR12MB50322B1D97569B5CADEC8E55F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
In-Reply-To: <BL1PR12MB50322B1D97569B5CADEC8E55F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Mon, 24 Aug 2026 15:13:04 +0100
X-Gm-Features: AcwNN1VxiYK2jXYCrQnBcioJAtVp2kRV-_L71rBTzoEWsRsEjGV3LGfW0swuAp0
Message-ID: <CAFEAcA9rWqo92nt1StDuBwUjbV0eqdAA921nozpjQHDF_ARJyg@mail.gmail.com>
Subject: Re: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
To: "Frager, Neal" <neal.frager@amd.com>
Cc: "Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>, 
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "sstabellini@kernel.org" <sstabellini@kernel.org>, 
	"anthony@xenproject.org" <anthony@xenproject.org>, 
	"edgar.iglesias@gmail.com" <edgar.iglesias@gmail.com>, 
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
	"Stabellini, Stefano" <stefano.stabellini@amd.com>, "Saleab, Micheal" <Micheal.Saleab@amd.com>, 
	"john.ernberg@actia.se" <john.ernberg@actia.se>, 
	"matthew.l.weber3@boeing.com" <matthew.l.weber3@boeing.com>, 
	"vincent.stehle@arm.com" <vincent.stehle@arm.com>
Content-Type: text/plain; charset="UTF-8"
X-purgate-ID: tlsNG-16d1c6/1787580798-F627077B-FAC9D719/0/0
X-purgate-type: clean
X-purgate-size: 2517

On Mon, 24 Aug 2026 at 14:31, Frager, Neal <neal.frager@amd.com> wrote:
>
> AMD General
>
> Hi Peter,
>
> >
> > Hi Stewart,
> >
> > > The -I$(XEN_ROOT)/tools/include added to QEMU's extra-cflags causes
> > > __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included,
> > > triggering an include-order assertion. Downgrade to a warning since the
> > > version is consistent in cross-compile.
> > > Ref: https://github.com/qemu/qemu/commit/e2abfe5ec6
>
> > > This is a buildroot issue, so I don't believe it's necessary to fix from the
> > > qemu side.
> >
> > I am not sure I fully agree here. While this is a buildroot identified issue,
> > there could be other use cases for __XEN_INTERFACE_VERSION__ to be defined
> > before xen_native.h is included.
>
> > But what, though?
>
> > And what we have found is that if
> > __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included, it
> > is not a hard error.  For buildroot, the qemu works just fine in spite of
> > this.
>
>
> > I think that just means you got lucky. Either there is a hard requirement
> > for one header to be included before the other (in which case it must
> > be a #error, and whatever is causing the mis-ordering to happen must be
> > fixed), or it's fine for the ordering to be either way (in which case it
> > doesn't even need to be a #warning).
>
> From my view, the order the header files are included does not matter, and
> this should not be an error.  I agree with removing the warning as well, if
> that is what we all agree on in the end.

The rationale for the header ordering is in the comment in include/hw/xen/xen.h:

/*
 * C files using Xen toolstack libraries will have included those headers
 * already via xen_native.h, and having __XEM_TOOLS__ defined will have
 * automatically set __XEN_INTERFACE_VERSION__ to the latest supported
 * by the *system* Xen headers which were transitively included.
 *
 * C files which are part of the internal emulation, and which did not
 * include xen_native.h, may need this defined so that the Xen headers
 * imported to include/hw/xen/interface/ will expose the appropriate API
 * version.
 *
 * This is why there's a rule that xen_native.h must be included first.
 */

...basically, if something doesn't include xen_native.h before xen.h
then __XEN_INTERFACE_VERSION__ can end up defined to the wrong thing.
(Disclaimer: I'm not a Xen expert, I'm just applying Chesterton's Fence.)

thanks
-- PMM


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 14:24:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 14:24:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398882.1635131 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVao-0006c8-Hz; Mon, 24 Aug 2026 14:24:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398882.1635131; Mon, 24 Aug 2026 14:24:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVao-0006c0-ER; Mon, 24 Aug 2026 14:24:06 +0000
Received: by outflank-mailman (input) for mailman id 1398882;
 Mon, 24 Aug 2026 14:24:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jjherne@linux.ibm.com>) id 1wyVan-0006bu-B3
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 14:24:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyVal-00F213-VZ
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 16:24:04 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jjherne@linux.ibm.com>)
 id 6a8c53f1-8faa-0a2a0a5109dd-0a2a45018bde-38
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:24:03 +0200
Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jjherne@linux.ibm.com>)
 id 6a8c53fe-5984-0a2a45010019-94a39e057790-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:23:59 +0200
Received: from pps.filterd (m0353725.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67OD1eKp826579; Mon, 24 Aug 2026 14:23:46 GMT
Received: from ppma12.dal12v.mail.ibm.com
 (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g726e9xgr-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 24 Aug 2026 14:23:45 +0000 (GMT)
Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1])
 by ppma12.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67OEBK0g007232;
 Mon, 24 Aug 2026 14:23:44 GMT
Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72])
 by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4g7p3pxn38-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 24 Aug 2026 14:23:44 +0000 (GMT)
Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com
 [10.241.53.105])
 by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 67OENgFt31457946
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Mon, 24 Aug 2026 14:23:43 GMT
Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id CE46058065;
 Mon, 24 Aug 2026 14:23:42 +0000 (GMT)
Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 1206458061;
 Mon, 24 Aug 2026 14:23:41 +0000 (GMT)
Received: from [0.0.0.0] (unknown [9.61.159.18])
 by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP;
 Mon, 24 Aug 2026 14:23:40 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=pp1; bh=snuerj
	iE6rg8DooF2vkNelHRwkN/IsrVBTzEqx2GOVo=; b=DKIPCW/STZ4s7EAhBy0b69
	5hdZHTRnsVULSxXVMjdnB4p305f7CYZ70YfCOFL8oMj56/uYL9RBQmMUL6lAIRmp
	Hqgu/lTbvqpOT3jyNn0gCIIYGttPcKCK2wEjV5LwIi57LJuDqeFSBlktEK/QNcvU
	xmGXRTCmCkur+pmc+WKz/kUn0efxNZXumSeda0q8xcMK2oSuHJle9TijkGQQ9jAQ
	31mLoTV/S1AyRx0v3PfSR67zc+crl1PGulzU4kJvYIgTjBu3wKAoeV7tWsqXkZkS
	mhtjGjKp0cSJRZjFOqE0/BcqqoG1Vz9Z4KdwSX7K+qIBVEHLJYzbw3Z+dVGliiFg
	==
Message-ID: <e0d602cf-012f-4e1b-a7a9-a17724e80d96@linux.ibm.com>
Date: Mon, 24 Aug 2026 09:51:29 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/8] qdev: Add force argument to qdev_unplug
To: Dongli Zhang <dongli.zhang@oracle.com>, qemu-devel@nongnu.org,
        qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org
Cc: dave@treblig.org, mst@redhat.com, imammedo@redhat.com, anisinha@redhat.com,
        philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com,
        alifm@linux.ibm.com, farman@linux.ibm.com,
        richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org,
        pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com,
        alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com,
        sstabellini@kernel.org, anthony@xenproject.org,
        edgar.iglesias@gmail.com, pbonzini@redhat.com, berrange@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
 <20260824011420.752806-2-dongli.zhang@oracle.com>
Content-Language: en-US
From: "Jason J. Herne" <jjherne@linux.ibm.com>
In-Reply-To: <20260824011420.752806-2-dongli.zhang@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
X-Proofpoint-Reinject: loops=2 maxloops=12
X-Authority-Analysis: v=2.4 cv=TfimcxQh c=1 sm=1 tr=0 ts=6a8c53f2 cx=c_pps
 a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=RnoormkPH1_aCDwRdu11:22 a=V8glGbnc2Ofi9Qvn3v5h:22 a=VnNF1IyMAAAA:8
 a=FruuJEGAiHTvyaHKMgMA:9 a=QEXdDO2ut3YA:10
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI0MDExOCBTYWx0ZWRfX/sGe/3QdJoQm
 qPzp0gLAcfanbJPTl1nR4nUu/o1R9m2DvR2DzEOnuZ2rrrhasEpaA6zrcjQBZ261SaYqBRtAm1J
 MLG90I/dS1ECTlDlzr3tqrZpf+GfOvw=
X-Proofpoint-GUID: XiL9O1weRXIWbPKfJOeN-9rFunGOTdur
X-Proofpoint-ORIG-GUID: ZlIk7Ysfmegwkpi-yzgmKjQdmmBW57Ng
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI0MDExOCBTYWx0ZWRfX6qxJAEXyn3y7
 n59RSs33gjCun9mhaKmZCCvuSN60lT8xFfj1cU/xGRHFo4u2wzhIoOC0Qj1c0LwU0XQEzxhugY+
 2N+0HTRai78ltEAf1Jp++opGT8zPdvvc/6lX/K0nlBbYSKxaqiUlp/rQbOlTAN0riExHvql2ZnX
 +Xk7WZ5NCJlf/Ryx9T1jbiM08INw1BMmOGgpWwEJoRmUeputjaehKPzPklHN3xT2YVxW3lyxQNk
 IzFWhAknDyN8tVZOERBdceVRXSGaHbij/0qPM/Hs8WAAm76JH1JhOSCUH/WV8ugpfvPp9pUblA0
 uNERqKsGuCVs1eaYr8HHqKYWQyXTAI1ceh0VnSk8uXIpNnom39xuNaVmDA7gpXiNUa9usRjvxOF
 qiZNlJOH9XvM+6wTTF5+f+p/c/o19+Wcl3Ugq7dlRdXgqgjgV6oPCj6E02Gz21sgzgAQig1uyjo
 V2/kWGVPrZs0i1DePKA==
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-24_04,2026-08-24_01,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 suspectscore=0 spamscore=0 bulkscore=0 malwarescore=0 priorityscore=1501
 lowpriorityscore=0 clxscore=1011 phishscore=0 impostorscore=0 adultscore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608240118
X-purgate-ID: tlsNG-d62444/1787581439-1D272757-112CE8CD/0/0
X-purgate-type: clean
X-purgate-size: 537



On 8/23/26 9:13 PM, Dongli Zhang wrote:
> ...
> diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
> index 6e2a1223ea..8e7c72dc8b 100644
> --- a/hw/vfio/ap.c
> +++ b/hw/vfio/ap.c
> @@ -79,7 +79,7 @@ static void vfio_ap_req_notifier_handler(void *opaque)
>           return;
>       }
>   
> -    qdev_unplug(DEVICE(vapdev), &err);
> +    qdev_unplug(DEVICE(vapdev), false, &err);
>   
>       if (err) {
>           warn_reportf_err(err, VFIO_MSG_PREFIX, vapdev->vdev.name);
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 14:42:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 14:42:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398890.1635138 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVsu-0001PM-Vq; Mon, 24 Aug 2026 14:42:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398890.1635138; Mon, 24 Aug 2026 14:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVsu-0001PE-Sb; Mon, 24 Aug 2026 14:42:48 +0000
Received: by outflank-mailman (input) for mailman id 1398890;
 Mon, 24 Aug 2026 14:42:47 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <berrange@redhat.com>) id 1wyVst-0001P5-2y
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 14:42:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyVsr-00HBFn-JU
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 16:42:45 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8c585c-e002-0a2a0a5209dd-0a2a450aa2bc-22
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:42:45 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8c585f-f2d2-0a2a450a0019-aa0a857c6691-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:42:45 +0200
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-260-G0JcXDphOs-FociHKCrOfA-1; Mon,
 24 Aug 2026 10:42:35 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id B9642183459B; Mon, 24 Aug 2026 14:42:30 +0000 (UTC)
Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 73B821955F10; Mon, 24 Aug 2026 14:42:23 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787582559;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:in-reply-to:in-reply-to:  references:references;
	bh=u+NBWWqcUHs5ssfN5Rb0Q5HairH34nNGEaNv1uLG/do=;
	b=jSC4PEPwWANmX9ATVi8aMc6GvRGxiJi6QvZ10M0ip6hWjgI4sXKOKnyRNVmVAgzb8XuW+w
	lULZokKUH6fsuAXJrR13Ms1FOST8z+jAXr3LO3xD5J+mgd+hQ8bkOgnRJQ8s9z7LnDCe8j
	AmhC3829l5cr7ip6cahDS5CVCwA6RG0=
X-MC-Unique: G0JcXDphOs-FociHKCrOfA-1
X-Mimecast-MFC-AGG-ID: G0JcXDphOs-FociHKCrOfA_1787582551
Date: Mon, 24 Aug 2026 15:42:20 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: Dongli Zhang <dongli.zhang@oracle.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org, dave@treblig.org, mst@redhat.com,
	imammedo@redhat.com, anisinha@redhat.com, philmd@mailo.com,
	aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com,
	farman@linux.ibm.com, richard.henderson@linaro.org,
	iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com,
	borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org,
	clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com,
	sstabellini@kernel.org, anthony@xenproject.org,
	edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com,
	armbru@redhat.com, joe.jin@oracle.com
Subject: Re: [PATCH 3/8] qdev: Support forced device_del in QMP and HMP
Message-ID: <aoxYTO8UkzzXvKOc@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
 <20260824011420.752806-4-dongli.zhang@oracle.com>
MIME-Version: 1.0
In-Reply-To: <20260824011420.752806-4-dongli.zhang@oracle.com>
User-Agent: Mutt/2.4.0 (2026-06-19)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12
X-Mimecast-MFC-PROC-ID: iyvXw9rJy7DNJsLPuHBrn3zR4XIf7xnV0MCeZGzzAe0_1787582551
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-purgate-ID: tlsNG-4011c0/1787582565-585CBCFC-EB06941F/0/0
X-purgate-type: clean
X-purgate-size: 3320

On Sun, Aug 23, 2026 at 06:13:33PM -0700, Dongli Zhang wrote:
> Add an optional force argument to the QMP device_del command and expose it
> in HMP as "device_del -f".
> 
> When force is requested, qdev_unplug() bypasses the pending deletion guard
> and asks the selected hotplug controller to complete removal through its
> force_unplug callback. Controllers that do not implement the callback
> reject the operation.
> 
> Forced removal bypasses guest cooperation.

This sentence is rather missing the punchline....

  Force removal bypasses guest cooperation and may result in guest
  errors, I/O failures, or guest panics. The guest OS cannot be
  trusted after force removal until a full power cycle has been
  performed.

I'm rather on the fence as to whether it is a good idea to enable
this feature or not. If it is used by a cloud admin without knowledge
of the guest owner, its use is liable to lead to hard-to-debug/diagnose
problems in the guest OS.

If a guest OS is not honouring an unplug request and the host owner needs
to force reclaim a resource, power off is always there as the failsafe.

> diff --git a/qapi/qdev.json b/qapi/qdev.json
> index 974cf9c583..cb5b5ad1db 100644
> --- a/qapi/qdev.json
> +++ b/qapi/qdev.json
> @@ -90,6 +90,11 @@
>  #
>  # @id: the device's ID or QOM path
>  #
> +# @force: if true, remove the device without waiting for guest
> +#     cooperation.  The guest may still be using the device.  This can
> +#     cause guest-visible errors, I/O failures, or guest crashes.

I'd want to be warning in a stronger way.


 This is a dangerous operation that can cause guest-visible errors,
 I/O failures, or guest crashes. The guest OS state should not be
 trusted after a forced device removal, until a full power cycle has
 been performed.


> +#     (since 11.2)
> +#
>  # Errors:
>  #     - If @id is not a valid device, DeviceNotFound
>  #
> @@ -101,7 +106,9 @@
>  #    will automatically complete removal for all devices.  If a
>  #    guest-side error in the hot removal process is detected, the
>  #    device will not be removed and a `DEVICE_UNPLUG_GUEST_ERROR`
> -#    event is sent.  Some errors cannot be detected.
> +#    event is sent.  Some errors cannot be detected.  If @force is
> +#    true, guest cooperation is bypassed, but backend cleanup is still
> +#    performed through the device's normal unrealize path.
>  #
>  # Since: 0.14
>  #
> @@ -117,7 +124,7 @@
>  #          "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
>  #     <- { "return": {} }
>  ##
> -{ 'command': 'device_del', 'data': {'id': 'str'} }
> +{ 'command': 'device_del', 'data': {'id': 'str', '*force': 'bool'} }
>  
>  ##
>  # @DEVICE_DELETED:
> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
> index fa3cae246b..ca10a25c46 100644
> --- a/system/qdev-monitor.c
> +++ b/system/qdev-monitor.c
> @@ -956,11 +956,13 @@ void qdev_unplug(DeviceState *dev, bool force, Error **errp)
>      error_propagate(errp, local_err);
>  }

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 14:45:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 14:45:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398898.1635149 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVvG-0001z2-CI; Mon, 24 Aug 2026 14:45:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398898.1635149; Mon, 24 Aug 2026 14:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyVvG-0001yv-8c; Mon, 24 Aug 2026 14:45:14 +0000
Received: by outflank-mailman (input) for mailman id 1398898;
 Mon, 24 Aug 2026 14:45:12 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <berrange@redhat.com>) id 1wyVvE-0001xk-En
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 14:45:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyVvD-00CbXe-Dv
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 16:45:11 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8c58f5-8faa-0a2a0a5109dd-0a2a4501a056-10
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:45:11 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8c58f6-5984-0a2a45010019-aa0a857cebe9-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 16:45:10 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-634-0lVCBpGIPpa5qIn8mlZKmw-1; Mon,
 24 Aug 2026 10:45:06 -0400
Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 9C75018608D3; Mon, 24 Aug 2026 14:44:59 +0000 (UTC)
Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 6758230002EF; Mon, 24 Aug 2026 14:44:52 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787582709;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:in-reply-to:in-reply-to:  references:references;
	bh=EPOW8a1Tm5zdmBXLIQzgCEl2lsjK7trOWqEpSuUEMD8=;
	b=Q3fqVUoe9mllwv/6i4NVdPhiuN1ACpLFUBe5CuQORE0Yn5TXZeilPzIbZI7FdB8aistIkk
	7iNY3+h9gn3REznpfI/kCMbJPwbpHCTD5xfgio241vPoUCHyuW0cijMVl1KExBuv+KXKhd
	mMey5d7wPd33SthgtB6VyWb0SPyStVI=
X-MC-Unique: 0lVCBpGIPpa5qIn8mlZKmw-1
X-Mimecast-MFC-AGG-ID: 0lVCBpGIPpa5qIn8mlZKmw_1787582700
Date: Mon, 24 Aug 2026 15:44:49 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: Dongli Zhang <dongli.zhang@oracle.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org, dave@treblig.org, mst@redhat.com,
	imammedo@redhat.com, anisinha@redhat.com, philmd@mailo.com,
	aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com,
	farman@linux.ibm.com, richard.henderson@linaro.org,
	iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com,
	borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org,
	clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com,
	sstabellini@kernel.org, anthony@xenproject.org,
	edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com,
	armbru@redhat.com, joe.jin@oracle.com
Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe
 native hot-unplug
Message-ID: <aoxY4Rxst2qAyn5z@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
MIME-Version: 1.0
In-Reply-To: <20260824011420.752806-1-dongli.zhang@oracle.com>
User-Agent: Mutt/2.4.0 (2026-06-19)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4
X-Mimecast-MFC-PROC-ID: cl8Le9jqAnXR1Rmnr1zvpPL4DK9sh8MbAMlh2DiJvOo_1787582700
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-purgate-ID: tlsNG-d62444/1787582711-BE27A757-B8F3E1D9/0/0
X-purgate-type: clean
X-purgate-size: 5160

On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote:
> Hot-unplugging a PCI device can require cooperation from the guest. For
> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest
> eventually writes the ACPI PCI eject register. For PCIe native hotplug,
> QEMU notifies the guest through the PCIe hotplug mechanism and waits for
> the slot unplug flow to complete. Only after that completion does QEMU
> unrealize the device and emit DEVICE_DELETED.
> 
> This can leave a device stuck in the unplug pending state when the guest
> does not cooperate. Examples include:
> 
> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is
> unavailable.
> 
> 2. The guest is stalled and cannot handle the hot-unplug event. For
> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this
> for ACPI-based hot-unplug.
> 
> 3. The device was attached to a slot that the guest cannot use. For
> example, a pcie-root-port only supports slot 0. If a device is added to a
> non-zero slot below a pcie-root-port, the guest may never discover the
> device and therefore may never complete the unplug request.
> 
> The non-zero slot case has also been discussed in:
> 
> hw/pci: warn when PCIe device is plugged into non-zero slot of downstream port
> https://gitlab.com/qemu-project/qemu/-/commit/ca92eb5defcf9d1c2106341744a73a03cf26e824
> 
> hw/pci: add comment to explain checking for available function 0 in pci hotplug
> https://gitlab.com/qemu-project/qemu/-/commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5
> 
> pci: don't skip function 0 occupancy verification for devfn auto assign
> https://gitlab.com/qemu-project/qemu/-/commit/e228d62b4af29bca698ec57efdceb46f392f5444
> 
> For example, if root-port.1 is a pcie-root-port, the following command adds
> a vhost-scsi-pci device to an invalid slot:
> 
> (qemu) device_add vhost-scsi-pci,id=scsi01,wwpn=naa.5001405324af0985,bus=root-port.1,addr=01.0
> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device only allows plugging into slot 0.

This rather looks like it should be a fatal error, not a mere warning.

If I follow the commit ca92eb5def it links to https://bugzilla.redhat.com/show_bug.cgi?id=2128929
which states that this configuration is going to lead to a crash in
QEMU on guest OS shutdown. IMHO that crash is sufficient to justify
making this a fatal error.

If we actually wanted this to remain a warning, then that shutdown
crash would need to be fixed.

> 
> In this situation, the device may be impossible to remove through normal
> guest-cooperative hot-unplug. Production environments also need a host side
> recovery option when the guest kernel is the reason that unplug does not
> complete.
> 
> This series adds a force option to QMP device_del and HMP device_del. When
> requested, QEMU asks the selected hotplug controller to complete the unplug
> through a new force_unplug callback.
> 
> This series implements forced unplug for ACPI PCI hotplug and PCIe native
> hotplug, which cover common pc/q35/virt cases. SHPC is not implemented by
> this series.
> 
> 
> Dongli Zhang (8):
>   qdev: Add force argument to qdev_unplug
>   qdev: hotplug: Add force_unplug handler callback
>   qdev: Support forced device_del in QMP and HMP
>   hw/acpi/pcihp: acpi/pcihp: Add forced slot unplug helper
>   hw/acpi/piix4: Support forced PCI unplug
>   hw/acpi/ich9: Support forced PCI unplug
>   hw/acpi/ged: Support forced PCI unplug
>   hw/pci/pcie: Support forced PCIe native unplug
> 
>  hmp-commands.hx                 | 11 ++++++-----
>  hw/acpi/acpi-pci-hotplug-stub.c |  6 ++++++
>  hw/acpi/generic_event_device.c  | 15 +++++++++++++++
>  hw/acpi/ich9.c                  | 15 +++++++++++++++
>  hw/acpi/pcihp.c                 | 17 +++++++++++++++++
>  hw/acpi/piix4.c                 | 15 +++++++++++++++
>  hw/core/hotplug.c               | 11 +++++++++++
>  hw/isa/lpc_ich9.c               |  1 +
>  hw/pci/pcie.c                   | 20 ++++++++++++++++++++
>  hw/pci/pcie_port.c              |  1 +
>  hw/s390x/s390-pci-bus.c         |  4 ++--
>  hw/vfio/ap.c                    |  2 +-
>  hw/vfio/ccw.c                   |  2 +-
>  hw/vfio/pci.c                   |  2 +-
>  hw/xen/xen-legacy-backend.c     |  2 +-
>  hw/xen/xen_pvdev.c              |  2 +-
>  include/hw/acpi/ich9.h          |  2 ++
>  include/hw/acpi/pcihp.h         |  3 +++
>  include/hw/core/hotplug.h       | 12 ++++++++++++
>  include/hw/core/qdev.h          |  2 +-
>  include/hw/pci/pcie.h           |  2 ++
>  qapi/qdev.json                  | 11 +++++++++--
>  system/qdev-monitor.c           | 23 +++++++++++++++++------
>  23 files changed, 160 insertions(+), 21 deletions(-)
> 
> base-commit: eea8fe61b8be8f3016e522e6af24924a0266ca95
> 
> Thank you very much!
> 
> Dongli Zhang
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



From xen-devel-bounces@lists.xenproject.org Mon Aug 24 15:28:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 15:28:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398908.1635156 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyWb4-0008Oq-GW; Mon, 24 Aug 2026 15:28:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398908.1635156; Mon, 24 Aug 2026 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyWb4-0008Oj-DW; Mon, 24 Aug 2026 15:28:26 +0000
Received: by outflank-mailman (input) for mailman id 1398908;
 Mon, 24 Aug 2026 15:28:25 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wyWb3-0008Od-O7
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 15:28:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyWb1-00FByX-IF
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 17:28:23 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8c6314-bab6-0a2a0a5309dd-0a2a4501b990-6
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 17:28:23 +0200
Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8c6317-5984-0a2a45010019-d155d029c8a8-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 17:28:23 +0200
Received: by mail-ed1-f41.google.com with SMTP id
 4fb4d7f45d1cf-69f7fa1c548so6630281a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 08:28:23 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a59e1ae4efsm8417898a12.21.2026.08.24.08.28.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 24 Aug 2026 08:28:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787585303; x=1788190103; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=C0w//u/qJWr+kuDQy+jVRr5v515n51WvczSsO9LbPJw=;
        b=DHDH3+U7RWNAxFUAgynLd5UgZorxleEdfAfr1T/nL5ANOotDYxlW08E7uyyEj4eKGK
         Bznigh9IOUz0nLbY3sOKM45gg/iPlOkXiUsH2EqCnjFmSGcGyuTB2gaYS6Y0egrqfBQl
         YGb+q5uE6j1b84hPqCwmQstX4sEOiuMvBWqocz6y8IxyoOflMihsLZ1CL4/yuUHdK+Uh
         CPjfrJWYLoZd8Cz0tjkojJeUSl2Bhk9weDXZM0bl327SXZnDJ9v2XtFFIjYYpQMXYoWP
         GD/ELijr4TyprqfgdUGSYyy4PXDggF4b7BVYZ09AtGOFkmfv9fMbJXZJHxa5/+iC32mt
         HCYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787585303; x=1788190103;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=C0w//u/qJWr+kuDQy+jVRr5v515n51WvczSsO9LbPJw=;
        b=IykM546whR43Ad86PPCodw89um/N5uQ/iKE+0TuTQvCWxy+FTOFL2b7Dy3YFTxJLgy
         Eq5u1yYSSGnU4PVE+ZpxzUWqSBV/fcr466H3E0FLM/QL0VD17WFEd8lVGc6WQmUUJo/r
         qVkmXoN7gkeN2l/3n8kxTBPvPGN3Etz4FsgXLoRRoNbLDe7jpebehJs5hrat/IMaPCso
         Km2IdDEVuwzztGpWYMILuWj9knvBZ+XfTeDKZxwKYtrywouag/LMINE2AB0/3N4yy7li
         1E1hOKknq2Y6jrlxfivkgjkynkPoz3v/Vs4dhi9dnJ6/NQWvDzz6OoEgxVvCyeW2ggpv
         JZcQ==
X-Gm-Message-State: AFuF++m/gWByXzE+ta00/speijflwDwZ5u9Hny/FGYVpKOSpjC/sa16l
	pm52afz0etZGRGkRRHr7im5J8g+oUHQ5puSSAFl2MsdjNT9OlNtIp49pbGbXAOQD2vGoy+gAxuP
	ZmuhzCg==
X-Gm-Gg: AR+sD10hryEWSywnvwJxVDmRm93iAQixnHnL4wJlA6Pk8jurbbYkYv548uiet7PrR1j
	6r+lzn2PW1XWiFQuO2E9p4fe74S9DKkmW/3jVDaY3JJYCEoM/OyEwGgZzCTjEsoehQAvXk2TJCW
	8pW7JPap5LT7G4IBLFuSGQ91gpYHy5DnvmHBSQ42Ojez080twd05IzsNSJcVu2tdoNgmXyPPynI
	mALG3O4vzfWozRSCro6Rf6ScVAXMEWg2Q4VLviH36O32M832HwUY1xik7GbzUr8U4FLdt1M44cs
	8B9D+2bP5v3Lr39Q77SEdQnLcyxRgcIU8rfdYw5f+XOacjXZsh2XHzOzrikuY7mPo5gufNCYa0E
	TMfF0qZpasLrR6coI6LLNOiVqaQzqdQ8ZY1MfRe3E2He4fk67n2vYvvX+oDh5wKWz8GzE8kxZZu
	S5iMcAVuztKbRRSwx+C4nXXIW7RjOOjZKKij7eBBtnN5UwCX4N8JZod9k5Hk85l3Xo+blBkYX7f
	S8+SdsafNkFBmMuE/IJHJvM1w1nmMzn7grrU3wMJDdnttyExjsT
X-Received: by 2002:a05:6402:1ecb:b0:6a3:f74d:6a47 with SMTP id 4fb4d7f45d1cf-6a582987b8emr19723865a12.0.1787585302987;
        Mon, 24 Aug 2026 08:28:22 -0700 (PDT)
Message-ID: <82707437-c95d-43f2-8c3c-f9038288876a@suse.com>
Date: Mon, 24 Aug 2026 17:28:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] symbols: also special-case symbols aliasing _sinittext
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787585303-1E07B757-3FEEF735/0/0
X-purgate-type: clean
X-purgate-size: 1247

A recent 4.22 randconfig build job hit a situation where (LIVEPATCH=n,
i.e. --all-symbols not specified) both __note_gnu_build_id_end and
_erodata aliased _sinittext on the 1st linking pass, but they didn't on
the 2nd one. As a result two fewer symbols were emitted on the 2nd pass,
causing $(call compare-symbol-tables, ...) to fail.

Extend the existing "corner case" by also considering aliases with these
two symbols (_stext really shouldn't have anything ahead of it), but
discard only non-text symbols.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -223,6 +223,13 @@ static int symbol_valid(struct sym_entry
 		    (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")) ||
 		    (s->addr == _eextratext && strcmp((char*)s->sym + offset, "_eextratext")))
 			return 0;
+		/* Same for non-text aliases of _sinittext or _sextratext. */
+		if (toupper(*s->sym) != 'T'
+		    && ((s->addr == _sinittext
+		         && strcmp((char *)s->sym + offset, "_sinittext"))
+		        || (s->addr == _sextratext
+		            && strcmp((char *)s->sym + offset, "_sextratext"))))
+			return 0;
 	}
 
 	/* Exclude symbols which vary between passes. */


From xen-devel-bounces@lists.xenproject.org Mon Aug 24 17:56:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Aug 2026 17:56:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398935.1635206 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyYuG-0002N4-K0; Mon, 24 Aug 2026 17:56:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398935.1635206; Mon, 24 Aug 2026 17:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyYuG-0002Mx-Gy; Mon, 24 Aug 2026 17:56:24 +0000
Received: by outflank-mailman (input) for mailman id 1398935;
 Mon, 24 Aug 2026 17:56:23 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wyYuE-0002MZ-Ud
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 17:56:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyYuC-008lQ8-5Y
 for xen-devel@lists.xenproject.org; Mon, 24 Aug 2026 19:56:20 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8c85a4-e002-0a2a0a5209dd-0a2a450bc47a-44
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 19:56:19 +0200
Received: from [40.93.194.63]
 (helo=SN4PR0501CU005.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8c85c2-b7e8-0a2a450b0019-285dc23fabeb-3
 for <xen-devel@lists.xenproject.org>; Mon, 24 Aug 2026 19:56:19 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by LV5PR03MB8412.namprd03.prod.outlook.com (2603:10b6:408:35f::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Mon, 24 Aug
 2026 17:56:16 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0339.012; Mon, 24 Aug 2026
 17:56:16 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wRhus86doozq+tax/aCrEsz7DUBHHCuvEIQIuZPb3TJXiiokJOqgNjCM1OKt2bOpdtIfTvt3E4+OlsEY50/sDDbcacppGw7VfxMRUvNdqiUosQFD08lbx6HUjscdpn5vfJRxV/aLAqv1uqH9xiIfZAukHIz6RXym3E0u9QVmmXd8iBB5nl0A3h29qp1+xfu7e7L2Vu+a1VySe8LYitJYwbwRNT8f7c4OF7NEbMhC/fWGoftLiMJ0k8HNmz9eXH5vmxyUHrE7mOUsKHJcGNHStazuzSgLI6TcFSqvg/99+M8cL/+G5zELUyK04N4s1bZezcVU2uaI498Omm9BJcHS5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6ICbahNI9SzHs3KL+ndDaQxrDtFROP5FKgMakgp4Zww=;
 b=E3ldTcSljVTcCAmTON+nrH55C8ZtEQKYmgx+4WcyCopgQ6Rp7ab8UbQt6tDk/O+n834AWo/rLe5iWWR+qcyU23apTjUew5JBjfKBRW+Hsofph1fPcJAKz+p2f61T7NR5egAdWWpwuYdttu1hAT6LybYOWGcHj55TlWPgYzcFyPuLnHyPbexoyf69wEtXviVT1lRxALPZ+q4pQDhoz8kDw0vVKtACtOtm32CP9yA43HGYwv0pqQR4HnJNK8jGGwVaYi+oOnr2MANX5Rfejmmpnr7+U9x9i1c8N/A7gwHjMX7UiH7fAWMTXprZdqT0Hx+T2hRPBsDXi8wuRFGQkw3nJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6ICbahNI9SzHs3KL+ndDaQxrDtFROP5FKgMakgp4Zww=;
 b=xnwdFFFUZ5yThA57YTsv8EbRujJOifHqsKqC/wi/NKqeqgB4nFoQhm1iX2ny2IuYPFkE0z8k8mxLMBHbaKNDMs2lY4DgTMlHy457b2bWfcVrH6c1VYq4q8HESWT1ttqahKjFK7s1IDNKd2c1K/7E+lhCPB3x0CAqx9giHhtNaI4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <ea290b1f-5d40-48e3-9a64-1799244c6e64@citrix.com>
Date: Mon, 24 Aug 2026 18:56:11 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 "Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>,
 "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
 "sstabellini@kernel.org" <sstabellini@kernel.org>,
 "anthony@xenproject.org" <anthony@xenproject.org>,
 "edgar.iglesias@gmail.com" <edgar.iglesias@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
 "Stabellini, Stefano" <stefano.stabellini@amd.com>,
 "Saleab, Micheal" <Micheal.Saleab@amd.com>,
 "john.ernberg@actia.se" <john.ernberg@actia.se>,
 "matthew.l.weber3@boeing.com" <matthew.l.weber3@boeing.com>,
 "vincent.stehle@arm.com" <vincent.stehle@arm.com>
Subject: Re: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
To: Peter Maydell <peter.maydell@linaro.org>,
 "Frager, Neal" <neal.frager@amd.com>
References: <20260805052723.2823538-1-neal.frager@amd.com>
 <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
 <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
 <CAFEAcA8sWn1vjm+OFYzwA-jko2vYkFcWPwT6g9=0AeO+JQo-JQ@mail.gmail.com>
 <BL1PR12MB50322B1D97569B5CADEC8E55F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
 <CAFEAcA9rWqo92nt1StDuBwUjbV0eqdAA921nozpjQHDF_ARJyg@mail.gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <CAFEAcA9rWqo92nt1StDuBwUjbV0eqdAA921nozpjQHDF_ARJyg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0358.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:18d::21) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV5PR03MB8412:EE_
X-MS-Office365-Filtering-Correlation-Id: 46fb5c23-3ed3-4740-b11c-08df0208fe89
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|7416014|6133799003|56012099006|11063799006|10067099003|4143699003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	RU2oSGHjF3o88MCcxcxg+XuZIdfXZGSmjJBC2wpTMT6CtIaqsCx9uFXD0PgY8RXVJFM034Qv54hcRZ8z45tq9TFwMtjCq6SG2D+cDDm0e74jjHU9ZXhj1282QlPjNXK6cNTUAjOyjl0/MqPwFkEWFQdVLsv4S3TlNUw44PBqejFe1/yegH7FClxsh45OVexT5fV2jJk6SnUY8u2+Eyx0KO/2yi/N5KrszaFsq8rh0wYGSkmLrVGSVJPx8TSl6XCs/HNOuE2ycb1fRCOt14MXAjBlqWscieoVp/y7ymUeIDgQyvnIdPgqqFibBWgBkN7LrlyeShADAhC9JnGq8c0q9k9Lgd2uya7PMLKbmS1RzUu3hkaAIYuLzKWuR/ltqAdTTKsOLB0pXYa9Nig+fDpSLXdFpWk3uw0CdujerGH+3XtcF7Y/8r0tttB3MgtMNR6poOs1GuCT8aQAisYKDVpUf4rLyJruoMfm32gxilcGyVVKiy3A6lvuCGPlqvp9O9Gf4UIRumaGMA5v6J2r5tfh55017iV65P73b/5u4uVOp6r+dGmf/PE4lYY5HC0XQFYGnOn5zVQ4G8zjn2hT1HHTsAIoJfbUT8SIWVyacEw4Hz+zV9biHof7X8TaA3L7EIpLeTJT1DQf8biVx1mlgdHqjyeBA2dJEjIokSauigF7WEA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(7416014)(6133799003)(56012099006)(11063799006)(10067099003)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?REJzeG4yY1JUbzlLVnA0ZkxOMVgxWHJPVEdjVDBOckV5REFxa0lEL2xUeHZs?=
 =?utf-8?B?emdFTlRRUVUwaXUvVG9WRytPaThaU29BcEJoaXdUSGhYVnFWMjM2RU1EM3I4?=
 =?utf-8?B?V1FCQUNYUEg2Wk5PUXVBNFZpc1VDUEdubG1iOXczM3hscjM2YUE0d3gwZTFN?=
 =?utf-8?B?dHQ2ZGpXSzhwVER6NWRlZXh6Z3JuUG8rYWVTL1BYcWVQWlBUKzM5U2xYUEd4?=
 =?utf-8?B?WWxBYTlWZ0o5OVJpTFhTeTAvbk1GTnVrNjBKNlpLR1pwR0d6OXY4dm1VY1Bo?=
 =?utf-8?B?TWpPZ3ExRytpbHhwNWRJaXFsVWJTSGRkTzlsdEMvSzJqdHl2WjlDT016d3g5?=
 =?utf-8?B?emRKUFl3ZGdJYlNhN0Ryb2F2YXdmekx0bGtNUytDZmNWaXhocnpGSzFTMFU3?=
 =?utf-8?B?ZFhVNFhKM3hzNWZmcXFxN2V6QXZpdk9CdkhmbElKaDZFWEJ3ME9mWGpLR25Z?=
 =?utf-8?B?ZTFBZS9MU24rZ3hrZ1B1RFZmQ002MUppc3BIRHBNU1luczYzejFMRmVNaDNk?=
 =?utf-8?B?OHhaYklRNnB4c1c3dWErMzIrbmJUMXlnUVNjK1ZsTVA1dzdBMTVxRzNvaG9l?=
 =?utf-8?B?Z2tMd3RETDBaWFVkRi9aTWFJS0swaHFraFBqb0FXNGdsaE1oK0UrQVhPdFcr?=
 =?utf-8?B?SzhaQ2todDFLQVhLZEcvTGFkUUlCcGxSbUoxRC9RUHVzRE1HNFZycnB0NVRF?=
 =?utf-8?B?SHIrM3BFeVJjVGZBNmdwWVYwTTd6dk5IcFlPYk5XKzRHWTVHR05SVUtwSm9G?=
 =?utf-8?B?UURxRk5hQ0ZLbG5wQklLWWxTMGxVeDlVQ0NvV1hOTFN6WTJGVTVCcUhUSENk?=
 =?utf-8?B?WEdOV0VGSjhyTXAvRHZGMFJRYVk5RTRkV3ZNMzVRL2hMWVN3aVo2T1pBR3po?=
 =?utf-8?B?ZmJmd3kzRm1mTld2Vi85QllKdmhzZ3IzTlBoUmpzUXhUa0FZNFVoZEpWR05O?=
 =?utf-8?B?ZkQ2VWJxaDlpNUZDejdXcENYYzVEYlVaNy8zM3dhY09SZlRaVGpodDQyZFhT?=
 =?utf-8?B?ZTJ0cUtYWm9rZWo1amdjUEZ6aitVLzlnaDZVbVZQN1ZvdUpOSnZpaXlyQ2pX?=
 =?utf-8?B?aWMyRGMwNTFOYWUzRjZZNmtjVFE4QjRwakh0T3U0TjhXdENZeXE0YUJFVDBE?=
 =?utf-8?B?eHlXYkRndmNwUjNOajFoTXdPN3FtM2xmc0ljN0xuYVJUVHdIb05EeENDcnlL?=
 =?utf-8?B?VXZrb2lZMGFzeVJmUEhuQldNU3BWRE5DbEVPbkdURnpuUXRDeWF1THdtVis0?=
 =?utf-8?B?MHRsVTJ2dEMzNzhZSzF1YmRjQUhCK1hXcmd2ZC9YL0hwb2RXeFlNay9mUFJx?=
 =?utf-8?B?bEhkRC9ud2VpcVFXSVdaS1hwbnpWNFh4UlJMbnVqanNEak1BZWJyODBHRmlR?=
 =?utf-8?B?KzF0VHovdDlhNnhqNlpqUFc5NXVxUUZ4ZHRaeFVmNEhRS2t5Y0RwTnVPaEJ4?=
 =?utf-8?B?UEVsWkhTcDIyc1FaZjZEZ0c4SVJ1WmEybmFHOWxyZ242eVNtTGltUHZRZ05D?=
 =?utf-8?B?akxOeTArM3JUc0lTeEx2U2hEb3htdXBWUkRBZDRjOWtRNGNCSGkzNENRcFhU?=
 =?utf-8?B?TEJXSWJONGh4RDZibzBIMS9aWEhlTFEvUkNsQ1FpNVRYdTRaZFJTcWE3ZXQv?=
 =?utf-8?B?bGs5TmJVWTFaNWJ5RkhZbXduZElaSDJKWVJEM0l3a1NINE04SU0rU1Z3bE4v?=
 =?utf-8?B?eS95c0k5TXZ1VGEydVc3MFZ6Z0pVS2pKRksxeE0zVi8xdEVtZ3NFendZZjlN?=
 =?utf-8?B?a1Yzby9JR3pXRWJDeXNMaWRseHhHMHllQ0MwMUg2eEVtQlFCc09sTXE3eXd6?=
 =?utf-8?B?Sms1WE5ia2RBczV6SEFabE9RQkl1OGhDSFlwN01lcVBzTngxQUlkYUVENEtl?=
 =?utf-8?B?LzBpNWhnNnpLTzlUYzA2WnJyUlJiM0Q1c0E5a2JyeHN2TmJYRnVGcW5PMDRl?=
 =?utf-8?B?Tm1TeWhrOGtDZGxISTRubVpaNmRQL0RZT0FYUy9QUkVvSWZhenZUOHV5MVRO?=
 =?utf-8?B?RDdId0NBWUpvNXdJZmprc25mU21ma1FhM0FnMWFHN3NORzdpTWVtRmZtUVlS?=
 =?utf-8?B?R2ZDREI3QldmK29UZDRLL213S1ZzMmt0MUlzc0p2OGd6cVFwMzNNTW5hbEZR?=
 =?utf-8?B?VHE0NEVSSFk3NnMrcVp6S2R0cExSUm9YbVNqUUs2RjMwalE1L1BKWmxxMFBq?=
 =?utf-8?B?dnREU2JjVHVSTnNhazZPTkVhait2VytNcW5KWExZL1ZGajNGVEZmYjdTVUow?=
 =?utf-8?B?SjR2bTJ4em9DQmR6MGdHRnF1cGFrQ3c3cGt1dUZ5Tm5YVjN3Q1gwaGg0aEx4?=
 =?utf-8?B?THNxZFB1SW5MdEhheGpQZnZqbktObFJpKzdzbWtwQ0M0aVRZSXEyUT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 46fb5c23-3ed3-4740-b11c-08df0208fe89
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2026 17:56:16.4964
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IclTcyAiQzZBQl0/70ikw92l5/5ee4P6Vzl5tj/Y1/w8hgM/x47t2hyrLOn9ZiAk6aviEEHB00BUJtA/kdVYaeYPvaAh1IyhoCkrOxh12cA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8412
X-purgate-ID: tlsNG-42698a/1787594179-AAEDE9EA-E7D55C05/0/0
X-purgate-type: clean
X-purgate-size: 2919

On 24/08/2026 3:13 pm, Peter Maydell wrote:
> On Mon, 24 Aug 2026 at 14:31, Frager, Neal <neal.frager@amd.com> wrote:
>> AMD General
>>
>> Hi Peter,
>>
>>> Hi Stewart,
>>>
>>>> The -I$(XEN_ROOT)/tools/include added to QEMU's extra-cflags causes
>>>> __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included,
>>>> triggering an include-order assertion. Downgrade to a warning since the
>>>> version is consistent in cross-compile.
>>>> Ref: https://github.com/qemu/qemu/commit/e2abfe5ec6
>>>> This is a buildroot issue, so I don't believe it's necessary to fix from the
>>>> qemu side.
>>> I am not sure I fully agree here. While this is a buildroot identified issue,
>>> there could be other use cases for __XEN_INTERFACE_VERSION__ to be defined
>>> before xen_native.h is included.
>>> But what, though?
>>> And what we have found is that if
>>> __XEN_INTERFACE_VERSION__ to be defined before xen_native.h is included, it
>>> is not a hard error.  For buildroot, the qemu works just fine in spite of
>>> this.
>>
>>> I think that just means you got lucky. Either there is a hard requirement
>>> for one header to be included before the other (in which case it must
>>> be a #error, and whatever is causing the mis-ordering to happen must be
>>> fixed), or it's fine for the ordering to be either way (in which case it
>>> doesn't even need to be a #warning).
>> From my view, the order the header files are included does not matter, and
>> this should not be an error.  I agree with removing the warning as well, if
>> that is what we all agree on in the end.
> The rationale for the header ordering is in the comment in include/hw/xen/xen.h:
>
> /*
>  * C files using Xen toolstack libraries will have included those headers
>  * already via xen_native.h, and having __XEM_TOOLS__ defined will have

Lovely typo there.

The define __XEN_TOOLS__ is woefully misnamed.  This is an error of
Xen's, which I've not had time to fix yet.

It should be named __XEN_UNSTABLE_APIS__, and thinking of it like this
will make it's purpose a whole lot clearer.

>  * automatically set __XEN_INTERFACE_VERSION__ to the latest supported
>  * by the *system* Xen headers which were transitively included.
>  *
>  * C files which are part of the internal emulation, and which did not
>  * include xen_native.h, may need this defined so that the Xen headers
>  * imported to include/hw/xen/interface/ will expose the appropriate API
>  * version.
>  *
>  * This is why there's a rule that xen_native.h must be included first.
>  */
>
> ...basically, if something doesn't include xen_native.h before xen.h
> then __XEN_INTERFACE_VERSION__ can end up defined to the wrong thing.
> (Disclaimer: I'm not a Xen expert, I'm just applying Chesterton's Fence.)

__XEN_INTERFACE_VERSION__ does alter structures.  It must be consistent
across a codebase.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 00:25:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 00:25:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398980.1635215 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyeyA-0008BL-JH; Tue, 25 Aug 2026 00:24:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398980.1635215; Tue, 25 Aug 2026 00:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyeyA-0008BD-Dl; Tue, 25 Aug 2026 00:24:50 +0000
Received: by outflank-mailman (input) for mailman id 1398980;
 Tue, 25 Aug 2026 00:24:49 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Volodymyr_Babchuk@epam.com>) id 1wyey8-0008B7-UQ
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 00:24:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyey7-003LED-Iy
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 02:24:47 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce09d-bab6-0a2a0a5309dd-0a2a450580c8-20
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:24:47 +0200
Received: from [52.101.84.73]
 (helo=DB3PR0202CU003.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce0cf-4cb1-0a2a45050019-34655449d18f-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:24:47 +0200
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29)
 by AS8PR03MB7829.eurprd03.prod.outlook.com (2603:10a6:20b:34d::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug
 2026 00:24:44 +0000
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0339.012; Tue, 25 Aug 2026
 00:24:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VUBt18oZA8MyWNlF+gon1rAmBrSjY1RVo47o6P+Ecekp8Nnrw8hqF2EqhrE8+MGUF5mkmuoe+YRLqMOQCAt0DCYQoI9uMRS3HSgX8iCR1yFdPgYzWO5ESweJ5lh3eUKnE6no9KEVsz6TiTELJib66/lfK4blTVzHb93UETmR3ZlXUUsPypkqCF3DzqC4sNJ2KF+x2DYP2jk9y5dyqO0aH6omnelbte7AW5SeTq6BwjqglAZKMlboDPWSm8qnhgFROmVIfCPz5Se3JEZ4X8OCdhx+9dLaK35blJ1auuoxet+ZCw83q+3DuAODtjBSLW5YXkcdffSMrBYVc7qZcA0YXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yKQxHODn3PTiP7tFxDfDWbkpNzL//blYLstN+umUeH0=;
 b=HEe7HYKQ99GpQeQqP7X6ZmI6TlH++HqKo+1feMv/UxesLdcQWa17evlw7z6OWaLRJvex+qVKtSMXFGhje4xM7ijEe9qeKzfm4T3DIccV/mc95IUpyo1WaBEnLW7ZMBy1MT2sIBJRPnMBuUssuGAY5cKQ7trw5/sQmYv2LEnOk/ulae34Hc8lxBMYWkm/Z15W4/fRRW8FCaj/GFY2QrZW1mCWUBtc5m6AD0v3xDBDX+C+gQ4cRPRyBZso+I15X40dTXx5WXjt0DFEp7f2r0YcWNSok4Fe2KtJRjbvXLCaqViZ7kls9UE3aMWYSAwj/C+ny6DUWgDbubVfNWUNQTZMhA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=yKQxHODn3PTiP7tFxDfDWbkpNzL//blYLstN+umUeH0=;
 b=L8jzjIcbQBj0KAsaSzgunR2qKTHRXvBDHR1ozcSNFOzamdfYdNaT6O1OYM/6puE0GJWq27kU8O1oaG6t3erEaAa/0RCljitEFay0GxgYY+2cdJmb4ti4d9BVui5yUusPRI4jn+8h8tV2slHiN4WQSbtQIhc7Gk9TShpKvq2gEl8LGJZIzoecrDD876zPrDuX5IpJxJaf5HRDZA7TDrQrpal5USRRIQE7JQbshZipxmcL2JLSoaw82Dyr6q3HxmGAlltxL2Y/6YNL96Eab2Bnzep70wlxorjMEg35Lj8NETDO3PMIdf3bTL/wAhuDwRWUoMopjDATaJcaCgVxqS/7+w==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Mykola Kvach <Mykola_Kvach@epam.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v3 1/4] xen/arm: make is_espi() a pure range predicate
Thread-Topic: [PATCH v3 1/4] xen/arm: make is_espi() a pure range predicate
Thread-Index: AQHdLwVdfsi6UdltJkiqddovOzt6jQ==
Date: Tue, 25 Aug 2026 00:24:44 +0000
Message-ID: <87o6erxd1a.fsf@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
	<8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com>
In-Reply-To:
 <8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com>
	(Mykola Kvach's message of "Tue, 18 Aug 2026 14:32:59 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: mu4e 1.14.3; emacs 30.2
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB7829:EE_
x-ms-office365-filtering-correlation-id: 344abb91-afec-446e-0dcf-08df023f4333
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|42112799006|23010399003|366016|1800799024|376014|56012099006|10067099003|6133799003|11063799006|18002099003|22082099003|4143699003|5023799004|38070700021;
x-microsoft-antispam-message-info:
 NErrj9KypNNbINjQWvHfkA0ymBt0B0r4ESun+6E4H/5vo6WLUvGZTIED0ilgjkA/USRfNI8942ikI2oqd0X837sffk4hel/AyizjGqKP0M4qaFXqG0hxbCKvn70+RbqlGo6u6thRBvhTyIa0lqbpfU5X6iEaPHo5kYJJ8pD+5Ixj8D0v+CgYl48e/u3AA9ayBV/p7pn2DD1HvEdn1BW64tA9WqXcF50PGMgCn66VJCc+rzvqZ5txgzPVVxa9lPK9GahMG9VXaUnlRg6wfSh/cJTCukHXWg1aT1b6s9NaFiDHkX6g2JyzsJxHt+3vHEAFypLyw7TeTOhAvBeQyVlERkRbSJRcmHROn9fvWFHSM2s9SuCpZDN78JmPpjpS8M5XXM5XDt5iIXpvPWPkSIeEv6XTTcc90EDWRNhUQDgJFyuYGHrXTBxUcl489H3+xQZzZXjGDqCr1baZz7/Vaq/iHp01q1ynKf7O/1gYIh/oQqO4vlcoMfQLduh+XcZbX+KsKuk8fcaTIia4GzPO6TNYfGbxJTINOV68/f5iETgtb3PAwp5BpsJTnt+2vOwRp9QhkPbgmyCBZvDnmGcXOTANCSLR8YA1HWPuMEsBn365uwO3nT87gvJ8hVRxUdwniVaUq3MZ+emH73qscdg4GG4KaK/yB0rOaUMTwZZTduOW9JmOrDkD1fyKRQe9WKUkiCziZ1zjJFjPqh3XihntMF6THVJ8NlQHL17au9nVbfITrgc=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(23010399003)(366016)(1800799024)(376014)(56012099006)(10067099003)(6133799003)(11063799006)(18002099003)(22082099003)(4143699003)(5023799004)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?82fuhx8tm2Z4xGsyD2WdGnp2TDf1tGsEWKUG7uANbTFs+KYyI1Qi5udnFu?=
 =?iso-8859-1?Q?hZjH+DPPLGoIyoEQ02smKhV/x/Ss/gFK85YLs1l2tXj07gvdS7Ar+YS0Pj?=
 =?iso-8859-1?Q?CgClCtzejqbEVz3p5DP07sfvHPyr8huqqByHzYcqlVoAemzk367wWvF+5j?=
 =?iso-8859-1?Q?Uj07iyarEJ1c//ORxKa+/h+MIwJ2nE9MV2rH8At9EYR1UcRbSHFj/pFfuH?=
 =?iso-8859-1?Q?Jrou0OaGZVeXpWXznqVRh6zGzzjadW9q8zaSBOPa1ZOkj84MjDCQzuUi9M?=
 =?iso-8859-1?Q?cLUpW6OqApJz+tWGl1ML3TY71TJ5HG2dVzXZej4KeB7f/9PP03F2ySyCr8?=
 =?iso-8859-1?Q?uhi4zVYrQ2rRFVA9TeEJd1qfbMrODVVXnHmakBeNp1oUYaMQk1Csk7F+Zq?=
 =?iso-8859-1?Q?wkMkiE6CKNxBzBPCxhvRm/02OhaXvVCF4SotYHou0L4sjxBXosdb9adIYJ?=
 =?iso-8859-1?Q?S0/OFY+nrzPXsjNGN5MX/Fr4oybW7pEMLS6qnmZndWi9kfCahWs0be5gxm?=
 =?iso-8859-1?Q?q2ULU9M4nq1d9STJ0LXnCVS7hgpDnyubaMf0tym93Kbo2jeS9SUl9+KPGT?=
 =?iso-8859-1?Q?iG1IX9I05boH+nZM8pYFqtcwtTU9XZgq9Ay+ALSrSKqH8cJRQ6buOI5vMl?=
 =?iso-8859-1?Q?OjyyWXAxSB4fT++KU1cH3JSm03F/zTtuiQ5rjm//7865WwJK+Jwcet2OHB?=
 =?iso-8859-1?Q?KvFLAO6w8XiMHzFbPXBEk4weRJt4dB8DGg8VD6uZNK7ytC3FC5zIPUPWEb?=
 =?iso-8859-1?Q?nds4RWXZagirSEG3gFYYQd4N1t6yNz4cMy/Z8tXcwIeWwInf8vLVw/F2ll?=
 =?iso-8859-1?Q?b/Su+RPlps8xjMwsnNNDjV8jAZbljRxJkDfCKDt3wZeOx+o49UN6qJfSrm?=
 =?iso-8859-1?Q?KAuxgcVbVND/OVnZbbMUjs0ZXX42ZYULmS/ZOYLBSmNxZywIp9Zi84Dk0V?=
 =?iso-8859-1?Q?2+jQkjFXulfr59XVfHIFKg4XphBcD/5nGuafcOdUE/jAfAay559PkQujFN?=
 =?iso-8859-1?Q?Xx+iXT58hWJtmtobAO7LQd1rAeQ60p6NkB901TTB78DOdRWGer/6hFTI9/?=
 =?iso-8859-1?Q?6vUNnWML1LGN4iK/zCisn6JOgwTVhvJbJSjVhkyNYbC6bHPjW1E5Y7Pwbo?=
 =?iso-8859-1?Q?KgKwMTC+DDWkTxGHzP0NwNAcR2kiIgHT7dAE5B8bcqeqMDuGIDUhMx0E8s?=
 =?iso-8859-1?Q?PJFCPIPveYy5N5V88WEIKPKcLepeGke4BF1EgtspHDlhin/UWZ/3T5n4pq?=
 =?iso-8859-1?Q?v/hnzMnsXQM9ZZ2GZs1CmuB41f1P4xpQnA6arC6n9MUOBE44+2fgdhZYXv?=
 =?iso-8859-1?Q?iaXBmSqcXG25S/vrb+1/AlVH7vdMr60qzykzon9G6qXX8e4sSY/s486DBd?=
 =?iso-8859-1?Q?aN0K04k2OhKJeZ5VmPR/H53b9FCWFuJHHKJ/0ZDrdvqsfjcjfqN6ow7SAv?=
 =?iso-8859-1?Q?sY1/TRo1fruDMWQ1BVNX5fXQo7IPg+gJICSf7Vj0J0hnHhI9BHmPoY35Rw?=
 =?iso-8859-1?Q?7ywjP8RnEVjQjUsRNf+mf06nbqKMhnhkF7OtENpwTaq6TuFJzaBXUwJojl?=
 =?iso-8859-1?Q?2lrgphpdWTXkT5zAGLSQVzHv12n/esgvIBvkcAMuHCqnAVKgxXAXGotXQm?=
 =?iso-8859-1?Q?TnDuqi4bbulwrh2swS0yBI/K7M/gMj9K0n+AcTFYqa0b6h4oOmzeFRmj68?=
 =?iso-8859-1?Q?/n7n8qJVpuJ/kjaLkVgui/6yyeVAjGHRxkpPEn07uKQWWFx0T3Y3ad7AMS?=
 =?iso-8859-1?Q?KlIdGyF/h3xvUkJwGqS0DThRHq+Ly755AHH+MSuf5UI53oCDjT2C6x0l4E?=
 =?iso-8859-1?Q?ITBpDI7o6n4o5V5IrEk+EQi5V7g7zWI=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 344abb91-afec-446e-0dcf-08df023f4333
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2026 00:24:44.3063
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bMDXvpPPpbh17dTFaA82SY0tYpLhvRrhi+Bxz5MRi948ew32v8jRyUiKbFD/cD0LkaTPEICsE2+tCoZaBii3cPFv3Cna/jqj4io0vrtrKM8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7829
X-purgate-ID: tlsNG-c201ff/1787617487-724B42A1-915D65EC/0/0
X-purgate-type: clean
X-purgate-size: 3753

Hi Mykola,

Mykola Kvach <mykola_kvach@epam.com> writes:

> is_espi() currently changes its result according to CONFIG_GICV3_ESPI
> and asserts when an eSPI INTID is passed to a build without eSPI
> support.

Probably you want to reword this part of the commit message. I think you
wanted to say that "assertion fails when an eSPI INTID is passed to a
build without eSPI support".

> This makes a range predicate carry configuration policy and
> causes callers to depend on its hidden side effects.

I'm not sure that I got this.

>
> Make is_espi() report only whether an INTID is in the architectural
> eSPI range. Gate eSPI handling explicitly at call sites and preserve
> the debug checks on paths where an eSPI is invalid without compiled-in
> support.
>
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v3:
> - New preparatory cleanup requested during review.
> ---
>  xen/arch/arm/gic.c             |  5 ++++-
>  xen/arch/arm/include/asm/irq.h | 11 -----------
>  xen/arch/arm/vgic.c            |  4 ++--
>  3 files changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 078049e741..075e1d2c50 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -348,7 +348,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int i=
s_fiq)
>          /* Reading IRQ will ACK it */
>          irq =3D gic_hw_ops->read_irq();
> =20
> -        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) || is_esp=
i(irq) )
> +        ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq));

I am not sure that it is a good idea to put ASSERT on value that we got
from external source. What if Xen is build without CONFIG_GICV3_ESPI but
hardware really reports an eSPI?

> +
> +        if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) ||
> +             (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)) )
>          {
>              isb();
>              do_IRQ(regs, irq, is_fiq);
> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/ir=
q.h
> index 09788dbfeb..c29f3d04a3 100644
> --- a/xen/arch/arm/include/asm/irq.h
> +++ b/xen/arch/arm/include/asm/irq.h
> @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq)
> =20
>  static inline bool is_espi(unsigned int irq)
>  {
> -#ifdef CONFIG_GICV3_ESPI
>      return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID;
> -#else
> -    /*
> -     * The function should not be called for eSPIs when CONFIG_GICV3_ESP=
I is
> -     * disabled. Returning false allows the compiler to optimize the cod=
e
> -     * when the config is disabled, while the assert ensures that out-of=
-range
> -     * array resources are not accessed.
> -     */
> -    ASSERT(!(irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID));
> -    return false;
> -#endif
>  }
> =20
>  static inline unsigned int espi_intid_to_idx(unsigned int intid)
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index e5aca17dcb..e14123a30a 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -718,8 +718,9 @@ struct pending_irq *spi_to_pending(struct domain *d, =
unsigned int irq)
>      unsigned int idx;
> =20
>      ASSERT(irq >=3D NR_LOCAL_IRQS);
> +    ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq));
> =20
> -    if ( is_espi(irq) )
> +    if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq) )
>      {
>          unsigned int nr_spis =3D d->arch.vgic.nr_spis;
> =20
> @@ -949,4 +950,3 @@ void vgic_check_inflight_irqs_pending(struct vcpu *v,=
 unsigned int rank, uint32_
>   * indent-tabs-mode: nil
>   * End:
>   */
> -

Please refrain from unneeded changes.



--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 00:30:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 00:30:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398989.1635224 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyf3w-0001KC-7U; Tue, 25 Aug 2026 00:30:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398989.1635224; Tue, 25 Aug 2026 00:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyf3w-0001K5-4I; Tue, 25 Aug 2026 00:30:48 +0000
Received: by outflank-mailman (input) for mailman id 1398989;
 Tue, 25 Aug 2026 00:30:47 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Volodymyr_Babchuk@epam.com>) id 1wyf3v-0001Jz-6F
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 00:30:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyf3u-00GAKc-FX
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 02:30:46 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce13d-e002-0a2a0a5209dd-0a2a4502aaf0-36
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:30:46 +0200
Received: from [40.107.130.98]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce235-6ca4-0a2a45020019-286b82623749-4
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:30:46 +0200
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29)
 by AMCPR03MB911348.eurprd03.prod.outlook.com (2603:10a6:20b:783::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.11; Tue, 25 Aug
 2026 00:30:43 +0000
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0339.012; Tue, 25 Aug 2026
 00:30:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Jeb+vW8+y21E+EzLtXzaK2afTib5c5WOI2VhA+rzkS9lubnyqPT7EiBtx1fWwtY+DiWkNwLiTbqSirmJucp49lv/nvULcOFfbbNyt/FAyc+6dAdtcsG8iQbamR9t4uTanEzG7S2b9idFc90lVESsH1pOyMD36aD+XO5hCafpfF/f6cJABr4ROLgvIOvospr88i81E4OjrrZ6oFKM+JeO+puNVv5LKWYIi+mB51ifHM2vdBPjsDAdcZdIW6D45IbfxQfSLArPAUxs52HlVdXEdr1Ta0lKratZ98k8N0THcaN6dNLIu0cpYl4XU3hG+QwEBaejeGJ2Jr3omc2L0Ins9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ocv7winbKFqyZnOpLmAxx/gJ5F+ljN7dUelB4N7SnH8=;
 b=Evl2CVT8yRL9xcIECKfnWYFedPxj2reFqQ+yQK1EEIo4fNIS0eZUT7caF82jEr2gxCgOmGXuOK1OonkeK4l0MSwFJoJZCGb78sow3clF4gs8iS++4tDrbxSz4gN2MLCy6K8w0IqpMs+FblK8Pg245Nv8IcyQU6mYdKUVwpmF5ZWp2eWLZ3JQtYkgqPcwMxoSn/t5TwVQaFA5pkU6SoQsmW/U1WW2/TT+Tg6PwA4Cq+uvEA9E269bxaEOhn/PHO5amVLa0sGW+Dkp0qI3il3cSgNO8QUmEXTbN4ejxIzqzX8cKLursyjpVeKNkoXS2gPRqAW6s4TbiBmvvqyC7W+rfg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ocv7winbKFqyZnOpLmAxx/gJ5F+ljN7dUelB4N7SnH8=;
 b=rwG99uOuCjmPoAUVsyPiYVvRNGqFj81h8bvV6nLP8bCWiFWDIAXgpEcEvouL+3MSJfTs+2z28Cja2nmrB4Ia/tgW3jXGEEWVK5OSo6jYJVzM/+q3ZR49PhePzS8YJeCj8XGCEAOeQRn3q1sOIkueVs+bFMQ97i1wLOhxRGXNVtWcG22lzljX3N8sN2dDfTNwsikIyE6/31MERM9TfYS1LuzF/6T5mJgNDVUsxvss5k6Ryw+KUR6BoDf3dGqoBuBvbj/AAcdI8QAobm6ueb9tKpuum50hr4pwVT6pUiAt3D9GVorpGWn9BDeDbMiiyg/mM5pOl8dESbWT9y5bJ7Y5VA==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Mykola Kvach <Mykola_Kvach@epam.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v3 2/4] xen/arm: validate IRQs before descriptor lookup
Thread-Topic: [PATCH v3 2/4] xen/arm: validate IRQs before descriptor lookup
Thread-Index: AQHdLwVdAIZJNP04UUyt5fXJ8PQg0A==
Date: Tue, 25 Aug 2026 00:30:43 +0000
Message-ID: <87fr03xcr1.fsf@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
	<355ff5a0aab671894a527ccb7b5999db6b168de3.1787050437.git.mykola_kvach@epam.com>
In-Reply-To:
 <355ff5a0aab671894a527ccb7b5999db6b168de3.1787050437.git.mykola_kvach@epam.com>
	(Mykola Kvach's message of "Tue, 18 Aug 2026 14:33:00 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: mu4e 1.14.3; emacs 30.2
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AMCPR03MB911348:EE_
x-ms-office365-filtering-correlation-id: 95c00883-5875-460f-0249-08df02401946
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|42112799006|1800799024|366016|23010399003|38070700021|10067099003|56012099006|4143699003|11063799006|18002099003|22082099003;
x-microsoft-antispam-message-info:
 9jQ4qY+p0tUvctpHVLj17GjRdYDecHVRZwu0Ng+fMVAHQPEa0Sm6KBntcmBaJJKemNqUrYKpPzeZQMKJB4k63IP8fLvAaIyyBSayOQaMaDpiyf/iXo6a49Mdm/3hz0r+zt7hNR8VgMh/xDIO5Jvv4k26sxhkGV6qOz1qJEW1om1vBe8mCv0gnFzj5ToZXbBP1T01Nk93ZKYEd4Bv8pLc69KUKi+yxk+BoRn4fw5devBEtPMeI+MsoB8ByYmAtyBTo7FJGtd9eBIgOoNyWG+Pbvb4ezEFzYaIEDIJguDFJSl6D2muD7Ho25oE95TpsKHl+CXBeOjJOfr4HwdAxDK1F0Wa4jdfdqG+ayfydBntB9otOQuTRzC079Cb7t+NqGrBpIqFXHcDwKYsLTqH1lRZtwkGFO9snYeyyWZl+8LCfWpAHcn5Wwzn8F3g9KUe37jYBsnuyuJFxdDdK9FjpukAt2IQhmqHWkp5wLUSBlv9pGLNYlCj4OnaiSc5Pxfbx/TFbdzLdH35Lvg377hUSOvTtM8TJyVxi0XBdyQ3ciaEa2HFdL79VreFNEKP9qw4fp3rVBBv7k2rAyUdDbuMlCHxOGzqYyr/4cIkyp2lPvjdAm8GglS52oZiSdrIaiUx3Zjhgeu3dRbA5gaF7IqgGVk/Gt2MwGEcz672JEErcz2f2cwhZmeGz2n43Zsn7MT0mLbS1d62EfbVv3D601kZAe4uOX9MkHD6vfoSgMzAUzo3Pe4=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(42112799006)(1800799024)(366016)(23010399003)(38070700021)(10067099003)(56012099006)(4143699003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?VSyhJ2XxCN/BQJOISB0UWwtHZ3MuGjzavkbIiIRf+tJNpKih8M0cTqqFmu?=
 =?iso-8859-1?Q?eQ4L9yqmOfy3YaPKittLSGKvTcgOxWoA5xWNn+Y+1TTua1R0nyc9f+rhg0?=
 =?iso-8859-1?Q?m+cUjB8zdZt8+SPKs6XA2EuwaZyHnK/QrTB08k4/fYpu4t9Oy/qpyIKoxy?=
 =?iso-8859-1?Q?1jSuDe4aTK9dJZUHauVU8Zum5iLDBKw2ADK7pbU9bVkOvBUe5al1H85h7m?=
 =?iso-8859-1?Q?KJ6ShQgAUumPrEelMCEwX+hDEPHARvgNbqBaWVAAtmN72coz/fZFuMbRB8?=
 =?iso-8859-1?Q?Gm9/2DlXzmD3VXhyOOx4aZl1hjHRwkcaUXmILZHpJs2l+3v6AtX17Qd/16?=
 =?iso-8859-1?Q?Ie/XGoxsM4FGy3JbQd57DB6+JavEmrLhIHBkRm2ihIAZZSgRONL5ZQ/EC9?=
 =?iso-8859-1?Q?PENlKPytp+oTyEF7gVxexz80pCwc10EtaAyOKezC4+VBl90Zn7tTuHOkaR?=
 =?iso-8859-1?Q?yr5RdAjptr/PAH0wa4Y00EbvGkbigJvW6BPc8T9wMguN9RFfDnc8Rmk9YX?=
 =?iso-8859-1?Q?kIcwZQtyea9N5KieQs+OJENZXrhOn7Ewm19Cs2CGOcyNwWc57rNiTf7Sy/?=
 =?iso-8859-1?Q?J6kXSgZu3s6EtwKc4SCEGJ8apds2v6W1H/Py1dsv1n5mtIJk4BKLIcMGk2?=
 =?iso-8859-1?Q?s/XX6lYgaaj3biFK/AcgNTd5TjfHwE1RH3Dbqqx0toVztctKn3WJXPh6Od?=
 =?iso-8859-1?Q?f0R+iQN7lowVIx9s6ZKOvfOg5St0p+MkVdkRUAbULrMBEdk05BNLWu+xUL?=
 =?iso-8859-1?Q?YTtkicUw+RwHTkBaUfbhVv4N3fWrlSY4hZCP2jh/eOyAxOL74k6e2fvUk5?=
 =?iso-8859-1?Q?L2rjNDcozJe15zWZY1vBmGvHEbS9mzyMGSWjIdN6bZf686LfXoncWO/Mpf?=
 =?iso-8859-1?Q?sfeEjOw7QsFpSxi1OV8FCUE490oRHNt+Q/9gzIzD2i+dGIt27LigWOIPWt?=
 =?iso-8859-1?Q?eN06GKxmVXJYja+Plg7OOBkk1QowYThVfzrTuZE78Myknn9ZOTNOsXCgj9?=
 =?iso-8859-1?Q?AXZAAVWSxY5g6y5p7Cf9RMwxaiOgEzAsXFFtUacyrmicZXFMVrVgppmZ5j?=
 =?iso-8859-1?Q?ynRzewLjmZuHaA6A6iEMAdngp3jQoUNuEqM060YW8vEl0LbbBMnLBoEKPC?=
 =?iso-8859-1?Q?8/OI+0lR9aIhtKFGb53YiadA5c/Igv4SCTAXMAy/3LLiTE86nZMr1NeG/2?=
 =?iso-8859-1?Q?z+dypV6LUgULuSiwutr5bBAHo2fIyV2a15UkJrOajxqKK8BwN0LMI9phiD?=
 =?iso-8859-1?Q?4K9cMslgrJpqvIQlxzvtvacwXU2CFsHtm4RVa1TxRqgtSATs331eyZub9x?=
 =?iso-8859-1?Q?ZqY9gnTfjpcgqpZOOQiCzM1UbXOwwy0BsFVMIcVhritX369qNpyLSof1S4?=
 =?iso-8859-1?Q?vf2UOGrjQEcy8BDiM9naG6zchUFIWdvZvVMLYYQFRO/SEXnmq+5Rcsbj+y?=
 =?iso-8859-1?Q?qeeOjX1Fy2ZXIuwC823Lyx7tDgqiksKfqa47W7HJRyj+JSur+UZFF1UDAT?=
 =?iso-8859-1?Q?J7AfJFAQA12JzxWJ5d2CnWZ6yaulV2TUmNfDbh9RHCf5SPUGAk30fP+zzN?=
 =?iso-8859-1?Q?T1XaV3nWO8a5MYz0zzOlQbZKC7F5PKNyLWLH3tr8pNAIm6nHB9gg4NyuSH?=
 =?iso-8859-1?Q?rT/JoPb7YGXiWoZrbekeoKSZpNVGsof4h9oUnRIxIvsTdX+vhisyV5cJdw?=
 =?iso-8859-1?Q?5guGsVjiJB+wMJb5le2HNHCZ6i3kZSozwapS3oRPlOmjTpO2NJrNfKkPLL?=
 =?iso-8859-1?Q?xENrZC2vzpPNQ3kVmXCBrRmumLneLkAI8REcnY27yhgmdDz7q67Pmi7uOq?=
 =?iso-8859-1?Q?4TmYokkoAx9Tr3TnEYKIYaI5vzXsCIc=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95c00883-5875-460f-0249-08df02401946
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2026 00:30:43.4634
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: z9TI86cA/sYIoelrTKEYdybIoe/zaUPjexhqbqoZ7bxB2IhgUAbUbCremLgVJYSfGrVEqOBAEIJpHEpC58aWZVtebyKYKSrH1EU0wdMBbCM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMCPR03MB911348
X-purgate-ID: tlsNG-720697/1787617846-30FCE2AC-2738744E/0/0
X-purgate-type: clean
X-purgate-size: 4115

Hi,

Mykola Kvach <mykola_kvach@epam.com> writes:

> GICv3 eSPI support makes nr_irqs span the architectural INTID namespace
> through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[=
]
> and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs=
.
> INTIDs 1024 through 4095 have no backing descriptors.
>
> Validation based only on nr_irqs accepts an INTID in this gap.
> __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or
> update unrelated Xen memory.
>
> Reject INTIDs that the GIC reports as unimplemented in setup_irq() before
> looking up a descriptor. irq_set_spi_type() can run before the implemente=
d
> GIC line counts are available, so validate descriptor-backed ranges there
> before looking up a descriptor.
>
> Assert the regular descriptor bound in __irq_to_desc() so direct callers
> cannot silently index the sparse gap in debug builds.
>
> Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI rang=
e")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v3:
> - Add the requested bound assertion and retain the SPI-only comment.
>
> Changes in v2:
> - Validate descriptor-backed ranges in irq_set_spi_type().
> - Validate implemented GIC lines in setup_irq().
> - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled.
> ---
>  xen/arch/arm/irq.c | 26 ++++++++++++++++++++++----
>  1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 73e58a5108..bf14180f97 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -23,6 +23,12 @@ const unsigned int nr_irqs =3D IS_ENABLED(CONFIG_GICV3=
_ESPI) ?
>                                          (ESPI_MAX_INTID + 1) :
>                                          NR_IRQS;
> =20
> +static bool irq_has_desc(unsigned int irq)

You are using this function only in one place, where you are actually
testing for SPI. So, maybe introduce irq_is_spi() helper instead? And
use it below?

> +{
> +    return irq < NR_IRQS ||
> +           (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq));
> +}
> +
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
> =20
> @@ -76,7 +82,6 @@ static int __init init_espi_data(void)
>      return 0;
>  }
>  #else
> -

Please, no unnecessary changes

>  static int __init init_espi_data(void)
>  {
>      return 0;
> @@ -95,6 +100,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq)
>          return espi_to_desc(irq);
>  #endif
> =20
> +    ASSERT(irq < NR_IRQS);
> +
>      return &irq_desc[irq-NR_LOCAL_IRQS];
>  }
> =20
> @@ -416,6 +423,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags=
, struct irqaction *new)
>      struct irq_desc *desc;
>      bool disabled;
> =20
> +    if ( !gic_is_valid_line(irq) )
> +        return -EINVAL;
> +
>      desc =3D irq_to_desc(irq);
> =20
>      spin_lock_irqsave(&desc->lock, flags);
> @@ -647,13 +657,21 @@ static bool irq_validate_new_type(unsigned int curr=
, unsigned int new)
>  int irq_set_spi_type(unsigned int spi, unsigned int type)
>  {
>      unsigned long flags;
> -    struct irq_desc *desc =3D irq_to_desc(spi);
> +    struct irq_desc *desc;
>      int ret =3D -EBUSY;
> =20
> -    /* This function should not be used for other than SPIs */
> -    if ( spi < NR_LOCAL_IRQS )
> +    /*
> +     * This function should not be used for other than SPIs.
> +     *
> +     * The implemented GIC line counts are not available when early
> +     * callers configure IRQ types. Check descriptor storage here; setup=
_irq()
> +     * validates the implemented line before the interrupt is used.
> +     */
> +    if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) )

So here you can just call if ( !irq_is_spi(spi) )

>          return -EINVAL;
> =20
> +    desc =3D irq_to_desc(spi);
> +
>      spin_lock_irqsave(&desc->lock, flags);
> =20
>      if ( !irq_validate_new_type(desc->arch.type, type) )

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 00:35:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 00:35:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1398997.1635232 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyf8A-0001ru-Ma; Tue, 25 Aug 2026 00:35:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1398997.1635232; Tue, 25 Aug 2026 00:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyf8A-0001rn-Jl; Tue, 25 Aug 2026 00:35:10 +0000
Received: by outflank-mailman (input) for mailman id 1398997;
 Tue, 25 Aug 2026 00:35:09 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Volodymyr_Babchuk@epam.com>) id 1wyf89-0001rh-C5
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 00:35:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyf88-00GArl-Eo
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 02:35:08 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce2e2-2eae-0a2a0a5409dd-0a2a45099d0a-34
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:35:08 +0200
Received: from [40.107.162.134]
 (helo=PA4PR04CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce33c-be1a-0a2a45090019-286ba286365f-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:35:08 +0200
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29)
 by AMCPR03MB911348.eurprd03.prod.outlook.com (2603:10a6:20b:783::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.11; Tue, 25 Aug
 2026 00:35:04 +0000
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0339.012; Tue, 25 Aug 2026
 00:35:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yA6tEdzl+yk+nhHu9/uohAN1JOCiLWTFYKraKz2r7FqnjnFECeavhXIeFYiXlqYhn4HV4yvb3qDqjr+UZsQNhmBNQ0XQxm6n3UwlHltaz47Xp/QL68RuHcVPgdXsbS0iYMdCt1m9aYZCWKbCvSXLB98tIUhyGTKPyNRdK1wHMgoiueuqFNVEobC4E4PH7B8hYxjO94GVwpLZBB/hpknXBE7uI4VDTwOPuCCZMwG4aQrEncXyj5fZ+mSgIRKk9frDAMGSXAFH82+JMJQJkIb0UhuOY6RznlvdF5nvGTLOYQSmXf+zp1Gisy1QJASjzL+14Xmj9Kb3LY9lhCtvQ093vA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/sfnGUn9sk2ypzeOnAxwvAMGBuBXq4UJKhuzevtahgk=;
 b=lfkSEEXCgYdNSL/zl4p3eHUvpQ65eo/VoHb7T7URGzualAsfvUPFQRW3EiI+FDwverd0QgOwL/mbtV9f7Uq3KL1H/v8ZcfTIUNVOcTbW98WCHNDdMt//FhHX4lRnzRYcMmM7EM/X2yH/6ZCjMfLJdLnjMBj41GqzwDXCBn4ZbUobht2D+vlmMs1ODXkKW0heYHX1MCsQOYNyCJQEUmOfHo66SO3SJbEv07W5ITXDFY9Tt4xPzF3SroYDWm1KRtoiwmO6TA4LGVW4JWtSP8GNCDg8RJJc/LTK6HIuTTRmAM7wzQnyj+rDbxrWcrPpuHZZqhStEEnrUFJQda4Ma8MPuA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/sfnGUn9sk2ypzeOnAxwvAMGBuBXq4UJKhuzevtahgk=;
 b=EWeNjwyhG5+AlCiFQU7B1WWt1AQFOJp68J76CBvBp7lfulIoZy0JgC2zRw5cIABv1l9g7UDnpJWCVn2dWa83De5xivSXNn4UB12HBBf6HnaXq2pV61yJyg5J+u3WZgUVsSYy6EfuAjwNOQRiYD38833J034DPg8pXXy6EEgizoAGXwIZ0ETgwOULZyYH1RglYu/pvWqR+7KHhSubH3mP+GjJFsmsM8Csr+vWm45wGCyx1u3UF8nwLBX7F5uZVQa2gxeZcbxyMh3WtInegZYYgQTGDf+6pR6iDGMVAL7S0zZwPKbbtRv83eul7osVd5uDnIBnJEH3hlxAlviXs40I4w==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Mykola Kvach <Mykola_Kvach@epam.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v3 3/4] xen/arm: vgic: free eSPIs using the bitmap index
Thread-Topic: [PATCH v3 3/4] xen/arm: vgic: free eSPIs using the bitmap index
Thread-Index: AQHdLwVeXVghDArU/UODCEwm7oqaSQ==
Date: Tue, 25 Aug 2026 00:35:04 +0000
Message-ID: <874igjxcjs.fsf@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
	<d359777c9fe4c4e1a53b93dea14e36adc4f39e00.1787050437.git.mykola_kvach@epam.com>
In-Reply-To:
 <d359777c9fe4c4e1a53b93dea14e36adc4f39e00.1787050437.git.mykola_kvach@epam.com>
	(Mykola Kvach's message of "Tue, 18 Aug 2026 14:33:01 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: mu4e 1.14.3; emacs 30.2
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AMCPR03MB911348:EE_
x-ms-office365-filtering-correlation-id: 863033fd-c07a-4b80-2ff6-08df0240b4e3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|42112799006|1800799024|366016|23010399003|38070700021|6133799003|10067099003|56012099006|4143699003|11063799006|18002099003|22082099003;
x-microsoft-antispam-message-info:
 pt6eygrtYW0kawf+l9400unZF6Nc7P6uw9BdTD/3MENft+jM9n9QEHxvQeLKJuou+0Xj4W9nWDoJcqQ+wZqWQOzTFCCjm8ICHGVs1Gr1T2BBcH189cpftn7DVZaXSbOo6HhnaD31qLK7F+MUMqtbrkU23By61LHrUYwNuclz+FMD22HKoG+fO+JAqlwEVT5fzMVcMf8eXqAh5M7PotzpEbv3RPTcH29zqLvEoR9b5obAvtSpnrB55WJkKaatq5i1L3YYtacfdFLZkRUebmE8Nb96GisBA+K362tmAexTI+9wyHV4NW4p9QeY7lYiElwnJ6QJveeTjbQIE8gdub2iNdYgleMfbZPhhB/2fDFd77Ru6wv10pPim/BmEXyEMmQ+Ey5SmO/O7gQc1MmvkfvmdK1nkBXVIFIHNgsTu0BB09I+VldAyKK6xS/uaWIvvF4AHuyKSTGlX8GwmWOJ7p052xRMrDirXDvc1iGRJkqFGCMb0ujceMVebvSukdveX+TmK2M+tIu/WUsAObsj4fVLQ+A4gvkURyElVlaViGvUz5dHP/R+/d/ILy+xdZEcxxyyJ42NcrELgXwSmclezhnnDC0NsvsEtVPQD/H6ck3IXYiV5wxYGefZwErxJdHS4lRTGOniQCScTQi/S0fj9D81xFt2oN25grmzSqaR4YwPBClskOkVh/2nGVHwvPzDqKSVJ/9XO6we3cgrp9BoDEbA4hkSDy9YzXYltbFnZgOjHEc=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(42112799006)(1800799024)(366016)(23010399003)(38070700021)(6133799003)(10067099003)(56012099006)(4143699003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?lawlTcAPjfaTckxAuaBNi1TkSqw4zwnF9uH7hHUyFS1jUpp6EvA47dWjXB?=
 =?iso-8859-1?Q?SOwWvMZdrEw4IV/bohVg/LvuAl7pj2zciCr6ykr+HPPrS3YSwuLtAwOgM9?=
 =?iso-8859-1?Q?qyCg7IB9MU4/k93WjXGDINJZ+9GrMBn1ZW4jJrNIDc2SuaHfYVS97M/t8U?=
 =?iso-8859-1?Q?KVchw2UUy9iry8IKNB3VNGmEEPCwJOXGkDGEyG9JFMBkXI5Ax1GWaplAsg?=
 =?iso-8859-1?Q?13JmV0453ClCPYxkJjJiKwAZpGd0M1QUDq6hXihxx/yGVaodcK2wu1O3q5?=
 =?iso-8859-1?Q?GtAHAf5y6WPQIa5UG1AQNJrpyuq20mut37XkjMvMyQWexvT36tg+wBQFLf?=
 =?iso-8859-1?Q?gg2k6FelKF9YXMcSB4lUvFECT+h9egcinmTgmReYs7ROBgqtHCJYdCuw96?=
 =?iso-8859-1?Q?25TqDjQZQ17OYP1shVuA1UH8VvvNu0+1RPLLRlffJUfMiPer+vF/f5nSLD?=
 =?iso-8859-1?Q?v40nBj5jTRH+rrltCL2aIiu9rlxhFrESu8zD42fyrVB73ao7+c0GuwCWEa?=
 =?iso-8859-1?Q?9W4o+jrkKBHwv1ZNpQ/49K+9QxxW8x8qSO+2ZVnxvJSnFDRmyHr+EmYOQW?=
 =?iso-8859-1?Q?zRO5stC7id4vItrjdyuAobM4UC/zGc8zIH7LmLUzYUyOop2W9QzWAM/v3Z?=
 =?iso-8859-1?Q?e9iQrZBRD912gu0r6KVAKamwtPHO5QlX4G/KXe7oLBxy3wq0qEtuwiW5kI?=
 =?iso-8859-1?Q?bFfOQo28qeT33TIxr8g6sxF+YfuK1tYtGYlSZigGqNmbQpAU4XRGsx5rVt?=
 =?iso-8859-1?Q?typdUXA2mzW9Rv+2fGtsRVemgFEKyKO/3EAyZ9ZZ7A6nGT+IyHMWim9sgt?=
 =?iso-8859-1?Q?6dCxujjMPird+/uANmeRTPGj96QQE3izGkWGzYjjSXGKD2cWrBtb+IrxBr?=
 =?iso-8859-1?Q?7NRQsv7Tkv3Gy7+kr7BHp1yPoe3TZry8Gd7glYT700/HQVnuvD7puNtBXs?=
 =?iso-8859-1?Q?Jrg878yepWqG5azFWV9E10qvlmqpBRZw9cKA5jGRplfpmZ23UY2w4R1HmB?=
 =?iso-8859-1?Q?kcUFVNM1kA6BLWGjep6YvLYaXcb4fuli4Ec3773WNntU4T0n3vq1QNFhUq?=
 =?iso-8859-1?Q?n4D2A7H2ELeqd3cdkNMjmTScw+Oyy5mIuCow4PE58OVnuv344neVkbUiJd?=
 =?iso-8859-1?Q?3dJ6Q0w/reMJ0e/q5/IAEGtgu7cDxVvMt9pCmDqWJP1GNtaJhpsiMWW03g?=
 =?iso-8859-1?Q?yQrYBRgJqAg98UHmvi6CLqaygMpT/89ZwXqxGSjQM9rNx34TISn/jVESEs?=
 =?iso-8859-1?Q?2Z607wkZjDvvHqurRifJ03YY8GtCguRjJueju+BPoOQoJlH49tWy2AjjOr?=
 =?iso-8859-1?Q?7dZrwRpJlGn+xDlGzNvxPFPfHFBy9hE9qw7SBwREE7+x32nCELk0sXUUG9?=
 =?iso-8859-1?Q?MsiEgOEL7voPElcPp9gTFgwONoctKlZHa0HnfSUoMr61brfyeUd0Xj+4Xz?=
 =?iso-8859-1?Q?7EOdty5OMz7oDJPsgFmWnYmw8rADiGMzfObxwNUC1v3bs454Wu22mqdb7d?=
 =?iso-8859-1?Q?0JPIpgTbMXuHj1ZI3Wq5i951G4moWz29cjO4jjkPqNHnhKdrQghj5F7ML4?=
 =?iso-8859-1?Q?WpLVbSbQsmLR5j7CZwxOOSOp43OZRp6mXBFGkc7hm4Ll+qZB8yON5TdPAY?=
 =?iso-8859-1?Q?cyiK3tymdTxNAZG4NOmV6vIjVmTTya7lxo2Boif9lzlkPDy6vzXSoc/oFT?=
 =?iso-8859-1?Q?qIgzBKm7r7ufCjsEJj2NUAhQoXCl7cgvT1zqVt9EjMwTLR/pzza2MF9LvG?=
 =?iso-8859-1?Q?3soRKGF2pf5ESonqizqUeRSVYJCpodMUUctqzzKnfwkcFyqnV3PXp3Cd7o?=
 =?iso-8859-1?Q?PbIBnuFT6KqhXtCtPOPQ/Jrr+fhITwE=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 863033fd-c07a-4b80-2ff6-08df0240b4e3
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2026 00:35:04.5256
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QykTCO1yIhQGwxpI/OHDETtz47NvrrjelgRdE6mg8Ngjz4lP3PleI+TkcrAxQ6GZt7EfgPle7WEMZ4GNU6vjkHgg8LdwUJCyVm3drOSqIkI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMCPR03MB911348
X-purgate-ID: tlsNG-bad1c0/1787618108-3B8D1034-DA6193A8/0/0
X-purgate-type: clean
X-purgate-size: 3186

Hi,


I have only one small question to this patch. Please see below.

Mykola Kvach <mykola_kvach@epam.com> writes:

> The allocated_irqs bitmap in the existing vGIC implementation stores eSPI
> allocation bits immediately after the regular vIRQ bits.
> vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap inde=
x,
> but vgic_free_virq() used the raw INTID.
>
> Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bi=
t.
> This writes beyond allocated_irqs and leaves the intended eSPI bit set.
> Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind=
,
> and during vPL011 teardown.
>
> Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reservin=
g
> and freeing vIRQs. Validate a vIRQ before clearing its allocation bit.
>
> Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended=
 SPIs")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v3:
> - Adapt virq_to_idx() to the configuration-neutral is_espi() helper.
>
> Changes in v2:
> - Call is_espi() without a configuration guard.
> ---
>  xen/arch/arm/vgic.c | 27 ++++++++++++++++-----------
>  1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index e14123a30a..e541348a5c 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -33,6 +33,16 @@ static inline unsigned int idx_to_virq(struct domain *=
d, unsigned int idx)
>      return idx;
>  }
> =20
> +static inline unsigned int virq_to_idx(struct domain *d, unsigned int vi=
rq)
> +{
> +    ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq));
> +
> +    if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) )
> +        return espi_intid_to_idx(virq) + vgic_num_irqs(d);
> +
> +    return virq;
> +}
> +
>  bool vgic_is_valid_line(struct domain *d, unsigned int virq)
>  {
>  #ifdef CONFIG_GICV3_ESPI
> @@ -849,19 +859,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union=
 hsr hsr)
> =20
>  bool vgic_reserve_virq(struct domain *d, unsigned int virq)
>  {
> -    unsigned int idx =3D virq;
> -
>      if ( !vgic_is_valid_line(d, virq) )
>          return false;
> =20
> -    if ( is_espi(virq) )
> -    {
> -        unsigned int num_regular_irqs =3D vgic_num_irqs(d);
> -
> -        idx =3D espi_intid_to_idx(virq) + num_regular_irqs;
> -    }
> -
> -    return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs);
> +    return !test_and_set_bit(virq_to_idx(d, virq),
> +                             d->arch.vgic.allocated_irqs);
>  }
> =20
>  int vgic_allocate_virq(struct domain *d, bool spi)
> @@ -898,7 +900,10 @@ int vgic_allocate_virq(struct domain *d, bool spi)
> =20
>  void vgic_free_virq(struct domain *d, unsigned int virq)
>  {
> -    clear_bit(virq, d->arch.vgic.allocated_irqs);
> +    if ( !vgic_is_valid_line(d, virq) )

Is this really can happen during normal runtime?

> +        return;
> +
> +    clear_bit(virq_to_idx(d, virq), d->arch.vgic.allocated_irqs);
>  }
> =20
>  unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version)

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 00:41:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 00:41:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399004.1635242 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyfEL-0003Qr-8P; Tue, 25 Aug 2026 00:41:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399004.1635242; Tue, 25 Aug 2026 00:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyfEL-0003Qk-4x; Tue, 25 Aug 2026 00:41:33 +0000
Received: by outflank-mailman (input) for mailman id 1399004;
 Tue, 25 Aug 2026 00:41:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Volodymyr_Babchuk@epam.com>) id 1wyfEJ-0003Qe-8J
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 00:41:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyfEI-003MnI-BZ
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 02:41:30 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce46e-bab6-0a2a0a5309dd-0a2a450c8d34-18
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:41:30 +0200
Received: from [52.101.65.92]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a8ce4b9-f479-0a2a450c0019-3465415c8ca3-4
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:41:30 +0200
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29)
 by PA6PR03MB10322.eurprd03.prod.outlook.com (2603:10a6:102:3d5::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug
 2026 00:41:26 +0000
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0339.012; Tue, 25 Aug 2026
 00:41:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=C9dstg/B3uTq8ygybz/N7VfoVkEJwE7Pq6gH+FOOTuHrLix9ogdA0qr0hBuAE7tJIAfiM6UnBzq4VkVR4/kR81lm5lzygccFdEhqH0Kg8uS+26/VpRauCugfOuuxcxr9Km/9G4sD4ilDtylF+gkk0DMNowSzKJtA/OhXxA0dE7EgKzXrtBrqKRloE0vGoJxDDd6SPDR7k5bWDufDrCARF4vQkCZeqDoXUMEXZu7Xfd9+yruaGDIhxXr838csa94tgW/kB2mZqQK37c6o3OqS1jlPRCwILxrGAtfC/hG6JzIfCIuFAgAoXJMh4vhx1Q3g8I5K+b7BDH7kJ/bUTQ9NSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9fPZb6IXciKqdn7cnZ1RMus09M3qUtKZeZmBPaBctNs=;
 b=PQ00KGbnFjn7QKiIUtm5ozDKGqoiM6UOKfmMSm2+nX929tBVnBjWcyRoj3HTMm2YAG0Hm5N6ohZEvBimZdUdU2l+aCE/q+rS/8ALhmuu4NqvraJ9zzg0wgomkJQiEZBQ6YOhg8qSKBw0YJNhsGBHbn3RbTig08VKSt+WK8CXdX129SwI/uK0xHmmbx/OmeTcnsN0Cryus/YTH1hAIM6BIgrNwP9YbadjpojGU3TWMt35x/+pVs0aBWuJJZ7si38fcHp0zG3osMZ2ju3OeYU/P5ZNO+V5EReOyt0WXZrCSAWqnkSg7LqHQLM5/2c4C6bvuIpFzB/u4AFQ9NyOthQbPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9fPZb6IXciKqdn7cnZ1RMus09M3qUtKZeZmBPaBctNs=;
 b=ufkC2x0cOxgMlcMyGeIn8oF5STcSvr1/7ZfA2aGoStuXnqU72Y6GwzlFIwDLwqqCI7Our3iZhp2dLIoijdNipS44WyZLs9GjgZy5yKj8mmdlZDV9bDj3GdpJs1Qa38Z1z92rmQZEKdqqNtjfgoOWipLIircQ1OttfVBJZUFg1xkY3lP51iySM5XSmqzF21ff453RI2WzDd4q+0NMFtxhebD/9YOwe8vof+cI62/ufUshVJAJQQvqkrsBOKigFZ9Xpnj3Q+ciFAvsSbZl1CbwhREYVURH8bfkX7U/QCi6PNPYGZLHGuFAs5hGDkJGLrrvPkfXY5GBXf6/bPyiHfPhQw==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Mykola Kvach <Mykola_Kvach@epam.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD
	<anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger@xenproject.org>, Jens Wiklander
	<jenswi@kernel.org>
Subject: Re: [PATCH v3 4/4] xen/arm: handle irq_set_type() failures
Thread-Topic: [PATCH v3 4/4] xen/arm: handle irq_set_type() failures
Thread-Index: AQHdLwVfgQe3/BFv+UOd2uF5vMSNtA==
Date: Tue, 25 Aug 2026 00:41:25 +0000
Message-ID: <87v78zvxor.fsf@epam.com>
References: <cover.1787050437.git.mykola_kvach@epam.com>
	<a960bc4917d4673cd1920cada2cfdb7eb7475f23.1787050437.git.mykola_kvach@epam.com>
In-Reply-To:
 <a960bc4917d4673cd1920cada2cfdb7eb7475f23.1787050437.git.mykola_kvach@epam.com>
	(Mykola Kvach's message of "Tue, 18 Aug 2026 14:33:02 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: mu4e 1.14.3; emacs 30.2
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|PA6PR03MB10322:EE_
x-ms-office365-filtering-correlation-id: 6683d2c9-2f89-4e39-8e04-08df02419813
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|42112799006|376014|7416014|23010399003|18002099003|22082099003|11063799006|56012099006|38070700021|6133799003|4143699003|10067099003;
x-microsoft-antispam-message-info:
 UkejqaFJWRe94jueSvjX+ZArVQ5ExU/xH8Gr1NRYO4mrJ7vEGhySxkdEP/avz009Lfx6qqxjRM5O+oE9WYU1BYEn83FgT+dLdz/AjkbXYPU28WeuVfrnI6Tf2/PSIvIW879qsTCbqp/NW8+o2jqsZZxYebgooBpr7CEaIWj/BgwtnrNmOwr9fAROqkGx7zPvH3LaDUtUGO2tatDZKXncj0HHdaE0k0XxYZjn436MzcuG7ndBHWGzY3nNSPEGFx/Jq6pMtB0Oy9oT/MTxkk5rcKktrep1uL8vl50Mx+8z91JRRTPFROjC5iAPA5wHkQObgj70Jsbr5ffU+WRTJYWkI6EftPHR8+8psMCV8wfZyqGG76F0Y0REojj7Wlly2MrFWjUrQ2Am3JKCe0G82bv/NOoxQuspoChzS7GbjfrVi6Hhtasw/OYULlFe5Sl0C23XH0zii/NrIwgY/XXkKjdIQxtC1i2/yw3c8qikmvKQtiLqSDfTCPq3e0xaCnsTV/5knZn+SPG5VAmeXJrK97cTgcwIuUJ3OLXJHInowNmWg2QqHRaPgLqyqQr3LDY22t+tgT66LbbgjYHzdxuoED7GqUAU/abh9ywfV7hG86XD7TyYH4JbUtCeR0o9p86WJq1ZGu+R6U2SGInrcPfTZtW4twJj1Rc6tXniCnj4GgEF/ceIhrrQtAXBg/SW0sHNu+9JGUTYseUvt/pKvn6JPKJhjOdfVHujoNfKIcYFzXP6HoE=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(42112799006)(376014)(7416014)(23010399003)(18002099003)(22082099003)(11063799006)(56012099006)(38070700021)(6133799003)(4143699003)(10067099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?mTLhSIU9P2lQssga/jpdbF1/9MwKoSh5IKQ5/EQmowmWW74GZPrC88JHQx?=
 =?iso-8859-1?Q?zx7bTT8RVcPabG3/9NNFTNH86emxqZ8Urwmai5seWGJmJssrEZu85xr43E?=
 =?iso-8859-1?Q?o1Wo10AhGd+YNMTF2kIjHSjynCCCxTcpo6FOQpJQMf/xxQg3+uCI5bMypk?=
 =?iso-8859-1?Q?ZPJ+2Unqa2IPIap6uQ1d1ns8FFO5POD0nUVq2HdCLz9ylj/IF5xyI/l/Xy?=
 =?iso-8859-1?Q?K7sbFOVNliETk6itNSlfHH+9TFmjgMwFPJtKrL9jHuqfOyn+UFXmoHn5MA?=
 =?iso-8859-1?Q?pjy2pXMH04OgG8DL3hRrfbODQIPv6SaMDquBCgdSeL0gRZR4l5UwNRMApO?=
 =?iso-8859-1?Q?nnpNp7dE/YNdjYUDG7dLiRSponeU8BpEvm1J4FHI1iuZOSCCNP35qC4Tiq?=
 =?iso-8859-1?Q?BhHsOpnSG8D4aX9kBJQ0N9v2IDL3jd4L9xt3CAtQpJEJzTTsw0oYtv6rdD?=
 =?iso-8859-1?Q?TmXqEuAPbIZwcHSmJGIEKzAru7pGvZQ5Asr1oI1KxQLCZyiSViGUVLlkT7?=
 =?iso-8859-1?Q?+WaAkjpvqF++GlpSi9tpCbQVScBff3NPI2+6lM+6GwPVr7+gIyBcYWSJJm?=
 =?iso-8859-1?Q?b3bdVckOPK2eF2zsrLe47T2QVBwPCpS4GHS2Ou3/CHkJJWFgCwkWWEeBYd?=
 =?iso-8859-1?Q?aVMacQVvQ5RXVLLSdvZGmKqU3voeUKn210VAsYjBIsQqAiyn7/cMnPnRbY?=
 =?iso-8859-1?Q?aVrIr8mJJbDagiviUnN+TkMOXPpnQuF+/HOwODIkEH/NEIVmtt1rqvlTAJ?=
 =?iso-8859-1?Q?u8v4Qhe0d1qdhOVHjunS446yVwgGGdf6BHBA8EtmtqynBQ8z87dkrKDPt2?=
 =?iso-8859-1?Q?0K/kPNlDYap1+yR7e0wm/mYqzTug/O76rT5AUu/bKodO0kiXXtL3eDOBKT?=
 =?iso-8859-1?Q?CnHVIbkyD4rMlsEduUQxKEZB2OGcIGbn0RFdmlMUs8eXlyBRHhb07osaUF?=
 =?iso-8859-1?Q?9WVMv008MekZEMP3zWzrtf3lwo0iQ5RBCaIRGsdseUG+Vx/dLfeO0Pkx4u?=
 =?iso-8859-1?Q?M17cM0IIXTT8KTRQ4U7RNdhJhft9A9nNliFTTXrPzQK3+D7Qqj0crFOYjC?=
 =?iso-8859-1?Q?AgEflo41qdzlStAAs0z7r1Pb97zMhls4kQB77ve4Cc4sWXPGldMeOUZGgV?=
 =?iso-8859-1?Q?1e85kpVXfErLeYDSQQZtg+BfebLYqqJrQCi4ZmDfcg6uDI0qzP8YaX/pbp?=
 =?iso-8859-1?Q?ZSZZRzGL8Cld8TI7+2YUEGw6kx36kTjJ2vifn3B3ZF2TZSNR5NdcN2P01z?=
 =?iso-8859-1?Q?xYY0t197hiDQWDTOQy/eWOw6K9jDc/wb7loCrH9pP3RA4UpZebzOYqfTMq?=
 =?iso-8859-1?Q?Z483hUz6FxhzVAKeFdFrv6GuBmmgd/frW4Q9F+3W/p1pm6o+twgu5Hk4ax?=
 =?iso-8859-1?Q?lWtlDoKh8iGwJ9jIkzLDCsPRsC3LusFf2pMgry6k45cJMCf1FOvLkm/p2j?=
 =?iso-8859-1?Q?GPw4oadAlgZfgusvLZifsJCrpCGgl3LeZrIbpPiAB2DPYDkiiqT+qw+c7p?=
 =?iso-8859-1?Q?k4wuIIKBfzB2hky/IF9eMnyOPhyqtaob9zSYZx597+Oya2L9d7KICngyFM?=
 =?iso-8859-1?Q?CW3AV6YS81+oO5IRyuojCakUp7vAp+uvG4vApYzCvxGmv3xaaBokBse9M7?=
 =?iso-8859-1?Q?vk+anNsFbgNccVwyA4c/q0QsQLjj6WC82I8x2GkomBaLnWs4tYst6et3YI?=
 =?iso-8859-1?Q?fVi/NttjwKf5GJ0maL4Oz2KxZp1/hCok6cj11qpEjvh8FDqrAXZh2LnkSM?=
 =?iso-8859-1?Q?AKQxVL54iVSip0fKFpsVGHWkAIKwZwK0ZIb1GNJ9pbcGXtabq039QQmrA5?=
 =?iso-8859-1?Q?EQoEYJu8c7IAX6Cbjz1td4OQdnz5wzY=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6683d2c9-2f89-4e39-8e04-08df02419813
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2026 00:41:25.7266
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FdYOGq1bkNZNGi6yOTxOB30I3i53vSPLqAcwhlAl8gKMM7pVKfKx/NZD3LJnYDL62ssQowGZfdgZFQKRaSm4C47unKgbfbyO4U/2dhCIGTk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR03MB10322
X-purgate-ID: tlsNG-d25034/1787618490-51737A5B-6B5E6E14/0/0
X-purgate-type: clean
X-purgate-size: 8712

Hi,

Mykola Kvach <mykola_kvach@epam.com> writes:

> Several Arm firmware initialization paths discard irq_set_type()'s return
> value, violating MISRA C Rule 17.7. If trigger configuration fails,
> initialization continues with an IRQ that was not configured as requested=
.
>
> GTDT and MADT retain rejected timer and maintenance INTIDs.
> check_timer_irq_cfg() and release_irq() later perform unconditional
> descriptor lookups on those values. Xen has no backing descriptors for
> INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds
> access.
>
> Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store tim=
er
> INTIDs only after successful trigger configuration, make GTDT parsing
> failure fatal, and stop UART or notification setup when trigger
> configuration fails.
>
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>

Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

> ---
> Changes in v3:
> - Avoid partial state updates and simplify maintenance IRQ setup.
>
> Changes in v2:
> - New patch.
> ---
>  xen/arch/arm/gic-v2.c        | 15 +++++++++------
>  xen/arch/arm/gic-v3.c        | 15 +++++++++------
>  xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++-
>  xen/arch/arm/time.c          | 18 ++++++++++++++----
>  xen/drivers/char/ns16550.c   |  8 ++++++--
>  xen/drivers/char/pl011.c     |  4 +++-
>  6 files changed, 51 insertions(+), 20 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 43a379fdda..a24d387e7d 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1166,17 +1166,20 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_head=
er *header,
>      /* Read from APIC table and fill up the GIC variables */
>      if ( cpu_base_assigned =3D=3D 0 )
>      {
> +        int rc;
> +
> +        rc =3D irq_set_type(processor->vgic_interrupt,
> +                          processor->flags & ACPI_MADT_VGIC_IRQ_MODE ?
> +                          IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK);
> +
> +        if ( rc )
> +            return rc;
> +
>          cbase =3D processor->base_address;
>          csize =3D SZ_8K;
>          hbase =3D processor->gich_base_address;
>          vbase =3D processor->gicv_base_address;
>          gicv2_info.maintenance_irq =3D processor->vgic_interrupt;
> -
> -        if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
> -            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH)=
;
> -        else
> -            irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK=
);
> -
>          cpu_base_assigned =3D 1;
>      }
>      else
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index acdac22953..b32a9b5009 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1743,15 +1743,18 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_head=
er *header,
>      /* Read from APIC table and fill up the GIC variables */
>      if ( !cpu_base_assigned )
>      {
> +        int rc;
> +
> +        rc =3D irq_set_type(processor->vgic_interrupt,
> +                          processor->flags & ACPI_MADT_VGIC_IRQ_MODE ?
> +                          IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK);
> +
> +        if ( rc )
> +            return rc;
> +
>          cbase =3D processor->base_address;
>          vbase =3D processor->gicv_base_address;
>          gicv3_info.maintenance_irq =3D processor->vgic_interrupt;
> -
> -        if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
> -            irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH)=
;
> -        else
> -            irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK=
);
> -
>          cpu_base_assigned =3D 1;
>      }
>      else
> diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
> index 186e726412..d08d0a3366 100644
> --- a/xen/arch/arm/tee/ffa_notif.c
> +++ b/xen/arch/arm/tee/ffa_notif.c
> @@ -407,7 +407,16 @@ void ffa_notif_init(void)
>          irq =3D resp.a2;
>          notif_sri_irq =3D irq;
>          if ( irq >=3D NR_GIC_SGI )
> -            irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
> +        {
> +            ret =3D irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
> +            if ( ret )
> +            {
> +                printk(XENLOG_ERR
> +                       "ffa: irq_set_type irq %u failed: error %d\n",
> +                       irq, ret);
> +                return;
> +            }
> +        }
>          ret =3D request_irq(irq, 0, notif_irq_handler, "FF-A notif", NUL=
L);
>          if ( ret )
>          {
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 6955b2788f..39b5eabe7c 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -60,20 +60,27 @@ static int __init arch_timer_acpi_init(struct acpi_ta=
ble_header *header)
>  {
>      u32 irq_type;
>      struct acpi_table_gtdt *gtdt;
> +    int rc;
> =20
>      gtdt =3D container_of(header, struct acpi_table_gtdt, header);
> =20
>      /* Initialize all the generic timer IRQ variable from GTDT table */
>      irq_type =3D acpi_get_timer_irq_type(gtdt->non_secure_el1_flags);
> -    irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
> +    rc =3D irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
> +    if ( rc )
> +        return rc;
>      timer_irq[TIMER_PHYS_NONSECURE_PPI] =3D gtdt->non_secure_el1_interru=
pt;
> =20
>      irq_type =3D acpi_get_timer_irq_type(gtdt->virtual_timer_flags);
> -    irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
> +    rc =3D irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
> +    if ( rc )
> +        return rc;
>      timer_irq[TIMER_VIRT_PPI] =3D gtdt->virtual_timer_interrupt;
> =20
>      irq_type =3D acpi_get_timer_irq_type(gtdt->non_secure_el2_flags);
> -    irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
> +    rc =3D irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
> +    if ( rc )
> +        return rc;
>      timer_irq[TIMER_HYP_PPI] =3D gtdt->non_secure_el2_interrupt;
> =20
>      return 0;
> @@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_tab=
le_header *header)
> =20
>  static void __init preinit_acpi_xen_time(void)
>  {
> -    acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
> +    int rc =3D acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
> +
> +    if ( rc )
> +        panic("Timer: Failed to configure interrupts from GTDT: %d\n", r=
c);
>  }
>  #else
>  static void __init preinit_acpi_xen_time(void) { }
> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
> index 120ac09d23..eb608ab8b4 100644
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void=
 *data)
>      struct acpi_table_header *table;
>      struct acpi_table_spcr *spcr;
>      acpi_status status;
> +    int rc;
>      /*
>       * Same as the DT part.
>       * Only support one UART on ARM which happen to be ns16550_com[0].
> @@ -1959,6 +1960,11 @@ static int __init ns16550_acpi_uart_init(const voi=
d *data)
>          return -EINVAL;
>      }
> =20
> +    /* The trigger/polarity information is not available in spcr. */
> +    rc =3D irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> +    if ( rc )
> +        return rc;
> +
>      ns16550_init_common(uart);
> =20
>      /*
> @@ -1975,8 +1981,6 @@ static int __init ns16550_acpi_uart_init(const void=
 *data)
>      uart->reg_shift =3D spcr->serial_port.bit_offset;
>      uart->reg_width =3D spcr->serial_port.access_width;
> =20
> -    /* The trigger/polarity information is not available in spcr. */
> -    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
>      uart->irq =3D spcr->interrupt;
> =20
>      uart->vuart.base_addr =3D uart->io_base;
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index a336241033..97c53c11e0 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -363,7 +363,9 @@ static int __init pl011_acpi_uart_init(const void *da=
ta)
>              spcr->interface_type =3D=3D ACPI_DBG2_SBSA_32);
> =20
>      /* trigger/polarity information is not available in spcr */
> -    irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> +    res =3D irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH);
> +    if ( res )
> +        return res;
> =20
>      /* TODO - mmio32 proper handling (for now set to true) */
>      res =3D pl011_uart_init(spcr->interrupt, spcr->serial_port.address,

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 04:34:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 04:34:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399039.1635251 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyirR-0005NO-OS; Tue, 25 Aug 2026 04:34:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399039.1635251; Tue, 25 Aug 2026 04:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyirR-0005NG-KS; Tue, 25 Aug 2026 04:34:09 +0000
Received: by outflank-mailman (input) for mailman id 1399039;
 Tue, 25 Aug 2026 04:34:08 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wyirO-0005N8-HX
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 04:34:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyirN-009noE-4V
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 06:34:05 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a8d1b11-bab6-0a2a0a5309dd-0a2a4501cb88-40
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 06:34:04 +0200
Received: from [52.101.125.141]
 (helo=TYVP286CU001.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a8d1b34-5984-0a2a45010019-34657d8d74ab-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 06:33:59 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by OSOP286MB7742.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:467::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug
 2026 04:33:54 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0339.012; Tue, 25 Aug 2026
 04:33:53 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mmESx522xrtaBhsQ5l84SFnJKJt7bl4ywWcBkQQI7pQzOfPortHdaFpM6WXPRJ2o54F8IQS+LKpNEnrZbJ46QrO5LxeRX+vaeGo1AYAO7xaAgJ1cZMmI2eXFPrO6wd9xdzNd8nAQejOtEX8xXxM3Svcrge5qNrf4wh7xv3UgumwzbzhJXUnOE6iJd47orluZwMkoWUFxUtpvUwlPmA9+zeTOponDABjDX1w581hvJXQbiaNoQ/xopDe6BkF/f3AhmgCEpOXnaM8f9Y4VhdD+Doyy/RaOoECunMBCpib1fzsWCMmnzFxKD9ovhEEidQSevwBIs7YrEwrCDsHzzbbR0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aSXJLd3NZY45/QGN9d/73fOosRtWj4l059gGuSH6Wzs=;
 b=jnm/XYkNrd+V5gtwUqtAcCAkkYxHWg2RVgWLxuiLyXOLksKullbRF1aIqEOAoVF6Szx9WgNkuSLUaCTfRiiFpr/NtMgo+4Rv8+cmPjrAoBwRTJuWUGWPAm/hGYx79l4wu52gO5FPPgAIrxYRTAYIquOJNEgkmICZncvMK/wGHQ2RyAdc2As4Nj8iXz/NKja++Zwo9J6XTPYb0yHmfwv7kbG0XtHUN8Yq8FltpYVdjNPV11/ZR6yxH7YWjvw4yLJqh9flIVvqXibsNaqxDYkaoVI7RQGw5xGKrx1Xoaobfg2xquXZbqPQEDgXCy7S815wB0Tj9T4YmyZtORmYWqxfgw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=aSXJLd3NZY45/QGN9d/73fOosRtWj4l059gGuSH6Wzs=;
 b=SnmucV3I8GKVxlHe/GSsErPu7bMlAhuGexnJ/ZsI2GDvGXX2KdB7ewTftx+GPG577gOjjhcfejH/QvXMzN/YQN5nbpfXzzsboZFPHwRl5aztKvYpyN8vGHpro3y6hfQmE52iHMEEGENwrJT9nJRfE3n+oFajxn8KvUwoXkMbCjU=
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: "Orzel, Michal" <michal.orzel@amd.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, Jan
 Beulich <jbeulich@suse.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger@xenproject.org>
Subject: RE: [PATCH v3] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
Thread-Topic: [PATCH v3] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
Thread-Index: AQHdM4NyLvQAa8Bus0iwWtzTdZAy7ras3w4AgAENCoA=
Date: Tue, 25 Aug 2026 04:33:53 +0000
Message-ID:
 <OS9P286MB7222E529B1FC372B81A1E3FA82AF2@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
References: <20260824044530.301938-1-taka@valinux.co.jp>
 <e6edf3f8-5085-4b5b-acdb-ac17402e86ee@amd.com>
In-Reply-To: <e6edf3f8-5085-4b5b-acdb-ac17402e86ee@amd.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OS9P286MB7222:EE_|OSOP286MB7742:EE_
x-ms-office365-filtering-correlation-id: d215895e-e12f-46d0-e04e-08df026211d0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|38070700021|10067099003|56012099006|4143699003|18002099003|22082099003;
x-microsoft-antispam-message-info:
 AmWuEqJlVFgRWMx2SAiO5zc/MCalapnyDHXqxq1+iCLNC/qLObqPMco1iisPV+vL2Lk7fbxxIP8bBWI2UBFXmcat7gan27ZmNKh+DcIAYs21nhGmkjuvkuVR111sRYc6mD1Ya7GC2Dk4arOVlyq4a8gMCRRPTqheNA32qr9LRVFXMTjjWyWUJ8l9ZvedJeRXkcLZ9YWE2rH+Lj6zeCQS4UFuhKq0Lhd+gwjmIg0qEq9utmDS7Jo17gV54+bsb5M7CM6IFn7Rz9LvXEFvnUUDcvHx3Z8OTdRJ+LyYnj3tKoI2BynTHKA4S3hsNR40bINSWm/X9ThzVIqWRS+HexgaY1aLmVypptBz1jkspalDMkS7bSJo0+8waP/CEMdCW3c2LWej0wpZHIbn8KrIxeQgrz/d7dbSkkYmoVzIk09iNdLtMDNQtHG7CnbLA1XMAH9aqScVrwXrI+bXa3QiCDNnZRNPSnzSu0SsjO5ZSXWqHUBWNufdjdGrZFNyzov4/NFR1cBXwkzI1f3xdtHM8xnbg8Ti4ejo69vb0xT+x7QbwjqfxHpbV983Tuq1NR2Icto3x0sgR1rJHTWMvrqXQudJZ1eKSy1kuvn2fWXCyOUTUMQlF9aOP7k6Z5wprP1dWSASTLD/KY4/i2EtAVvCiNXdIV4unEAdC+gfyDVHNEQ90Dq/lMoHrH9IMHTSed7Mc81M367RqfHBxg8ZirSc2ZegSh7DPH4hhgetBteJ7PCmBZg=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(38070700021)(10067099003)(56012099006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TzhRcVF3UlFZVlJ2aHE2aUQzb1Y1bTBuKzBSeHZxaWQvai9LQTJJdVYyTXJ2?=
 =?utf-8?B?dFNjanlubEp5NTBYUlVtYTBNMXVjYjdrWUhTWGJRbzRlTTVId1B6YlBsUFo1?=
 =?utf-8?B?M29FVVA5N3Q2TWRCRU9zNFRnVytiRi9iWkNKajJPSE9lcWV1UFZRWU1mamJ3?=
 =?utf-8?B?bDdTYWlUY0xTREl6Z3Y3eTVvR0VVcTR2bVc0K016ZFJkeFd2VzdGa2R0blNN?=
 =?utf-8?B?MXdXRlMreUR3Nnc2QTNyY3RUMTR1akE2UjJCVzcwZzNkRngxOUN5aFcwZ0Yv?=
 =?utf-8?B?WkFwM2dBQklMQUlPZjd1Wm9uY1F4Q3RSZWtUb1hqdTdxYjZuNDFvNThTaVFv?=
 =?utf-8?B?N1VlK1NoQTNnRUdoNXJ1VXFmaGF0MG9VSEVvNFF4L3piT1ZwVGtjSEtjYm1J?=
 =?utf-8?B?cU90M1NXdXV2ZVBablhoS0IvNjRCM3VnYTZoNmhSb3ZqZkVZUGtwUjVNMzZV?=
 =?utf-8?B?S1Y5TUN1OTRhZDEwYnlSV2Fqc213TmFmajV5RU9EdFB4a3lKUWdPVnRETGVv?=
 =?utf-8?B?MW5HRzg2bzVKZ0xEZTBCb0ZrVlNnYmlDN0Yrb3k0Y2RlbUFXZGVGTFdZd002?=
 =?utf-8?B?L1RRV0tmZzVHNURTelRCZkh0NnpQalFPN1lZd2VTQzZsTWh0QlpIeEttZGo1?=
 =?utf-8?B?Ukt1cmsyWFhLd0xOS2g0b3lFT1V5K2tHSnVxZ0pFeThJSjZWSFRsMS9BNFBP?=
 =?utf-8?B?TTVudTg0TGFZUk12U05ocnl5TElqRnVYVmpoeWhQc2JXZXh3bnhnZlNhMkt1?=
 =?utf-8?B?R0QyM1ppTEJnclZTL2NOSnh2NlRXb2RrNGJNakFZa1BVWmlGODRpSCtHQm9m?=
 =?utf-8?B?Z1pZVTMwY3pZVitUbGZnVUMrbXFtTmNRRDExSzBZRlJRclFYRGdINW4wR0dT?=
 =?utf-8?B?TmFERUJRZE1odk5JajltUDNYQ1hGZkR6cERabXROUHJkR3VISWJwSDZHdk95?=
 =?utf-8?B?WkNlcTR4MHM4enJyaEp6cFVORzRSeklreDkyUXorOG1ad2tpRTJCUHI4eWxR?=
 =?utf-8?B?Ry9UWHlQbzAwb09Bb2ZqK2hyMUl0eGFZMUdKV3NRaUdrYWE1ZTNPQTlycXFl?=
 =?utf-8?B?UUtMVXZKLzFmWGYyMWE2ZE1yb2tYNzJ4ZkorYU5rNXZrZjlCRDZlUjYxaFZ5?=
 =?utf-8?B?b2Z0MG0rUGsraTlMc1hHZmQwUG0wUzdzN0VuWGNicTEzTkxpR2ZUNWhLclNi?=
 =?utf-8?B?dDdUNWNGY1ZwSFN3eDdWTGxINzVVcFQvSlZtRStNZC9ibUMrOUF3d0k1VVVJ?=
 =?utf-8?B?S2gzdVpBSUZwSnNIQ0cvTEZqOGkxSXBQenA1dTBodFdvdldtd0U3aUxFMktK?=
 =?utf-8?B?WE9FN2Y4cWJ5ZGxoUlQwYVdSYlRLQkU3ZkFKSmhOTDZzV3JzUFEzbFF1S3Yr?=
 =?utf-8?B?RHRFalNKY2p4M25PeHNtNkZRZS9wanFhYW80SnB2UVdkSDlKMTlyQzVjMG1J?=
 =?utf-8?B?MDRjaTNvNjBLVEx4OUY3N1JQSmdnMnZURW92WDRCYWx3M0NuU24xVGJxWWF5?=
 =?utf-8?B?Tjhmb1NPOE5VQVJZS21sckNmaUJ6NFdqZW9UT05KckJ4ZnoydEhNTkVHcXRn?=
 =?utf-8?B?T0tNNUFKd1lIdVVLNWp1clROcVZPNzU4MnJycUFraEJ2THdQem1MMElvZXZH?=
 =?utf-8?B?dWtJN0E5TXBQcXNiL1lXS3poQkRZWTFjdk4remhIN0JGQ0JFOGN3bXY5SmtM?=
 =?utf-8?B?d0ZiWEVLZGtFME94SERvTzR0enRyeFUybzRRQ29ZNnpPV0xwdGh3OHphN1li?=
 =?utf-8?B?ZFlncUdQaFNVUTZKT3kyZmt2UWJGT0NFZnZEK3BmWHZvRmxWL3l4aEFYYVRp?=
 =?utf-8?B?NEI1OWNIQ3lDdEtZRVAydzY0SVBmMHpYUytCMSthZ01MUHpHL2pldkwxNktK?=
 =?utf-8?B?SGN1WFlldmx6dy8wZC9XM0ljbGkyYUJvdmpzcnE0S3V1cFlwcGJLdURTTlZa?=
 =?utf-8?B?NDNtejFDUHRlWmZrSWhJb2F1enZzdFNWQ2U3RmFBY0FSQ1VrMXg0Nng3a0xZ?=
 =?utf-8?B?R0szcDRycHV0OXJuMkNuS2NDY3pWMXJjZ2hqc2lLSG43eDVIT2JxZW02Yi90?=
 =?utf-8?B?VExvNUNYWitvei85bGxQdFU4bnNhUzNOUTB3Z2VCQUNhL1ZHU2l0cU5TeGJV?=
 =?utf-8?B?cnVWZjdlYkwxeGNzQ3Y0NjhRRHFyWU9hZGxRS1NiUjRxTk9mSVpyWjl3MlN2?=
 =?utf-8?B?aWVYZ2pFZGk1MTN3ZllhZmdLRHlVeFdpMFR5UmJRbGEyM1NwU01ZMlNNcDkv?=
 =?utf-8?B?QWdITXU5VFBvblI1WXF1ckpmOXI3ZDFQU0xVRldqMTJ4TlVDODR2SVRHOVlv?=
 =?utf-8?Q?znodGHR00qxIvy9B8L?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: d215895e-e12f-46d0-e04e-08df026211d0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2026 04:33:53.8319
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4mEuN9K4cpl/HwQVzumZfuxWQA1tw4ZJ6RuYMlAMlmW/63hIAB0fJrwWvya61fXsbHKC8X90CnxdqQBlPGtXyg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSOP286MB7742
X-purgate-ID: tlsNG-d62444/1787632444-1E27A757-FE1907CC/0/0
X-purgate-type: clean
X-purgate-size: 6856

SGkgTWljaGFsLA0KDQo+ID4gLS0tIGEveGVuL2FyY2gvYXJtL2FybTY0L3ZzeXNyZWcuYw0KPiA+
ICsrKyBiL3hlbi9hcmNoL2FybS9hcm02NC92c3lzcmVnLmMNCj4gPiBAQCAtMjI3LDYgKzIyNywx
MSBAQCB2b2lkIGRvX3N5c3JlZyhzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywNCj4gPiAgICAg
ICAqLw0KPiA+ICAgICAgY2FzZSBIU1JfU1lTUkVHX1BNSU5URU5TRVRfRUwxOg0KPiA+ICAgICAg
Y2FzZSBIU1JfU1lTUkVHX1BNSU5URU5DTFJfRUwxOg0KPiA+ICsgICAgY2FzZSBIU1JfU1lTUkVH
X1BNTUlSX0VMMToNCj4gPiArICAgICAgICAvKg0KPiA+ICsgICAgICAgICAqIEFjY2Vzc2libGUg
ZnJvbSBFTDEgb25seSwgYnV0IGlmIEVMMCB0cmFwIGhhcHBlbnMgaGFuZGxlIGFzDQo+ID4gKyAg
ICAgICAgICogdW5kZWYuDQo+ID4gKyAgICAgICAgICovDQo+IFRoaXMgY29tbWVudCB3YXMgcmVj
ZW50bHkgcmVtb3ZlZCwgc28gcGxlYXNlIGRvIG5vdCByZS1pbnRyb2R1Y2UgaXQuDQoNCk9rYXku
DQoNCj4gPiAgICAgICAgICByZXR1cm4gaGFuZGxlX3Jhel93aShyZWdzLCByZWdpZHgsIGhzci5z
eXNyZWcucmVhZCwgaHNyLCAxKTsNCj4gPiAgICAgIGNhc2UgSFNSX1NZU1JFR19QTVVTRVJFTlJf
RUwwOg0KPiA+ICAgICAgICAgIC8qIFJPIGF0IEVMMC4gUkFaL1dJIGF0IEVMMSAqLw0KDQoNCj4g
PiAtICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9ERlIwX0VMMSwgZGJnMzIsIDApDQo+ID4gLSAg
ICBHRU5FUkFURV9USUQzX0lORk8oSURfREZSMV9FTDEsIGRiZzMyLCAxKQ0KPiA+ICsNCj4gPiAr
ICAgIGNhc2UgSFNSX1NZU1JFR19JRF9ERlIwX0VMMToNCj4gPiArICAgIHsNCj4gPiArICAgICAg
ICBzdHJ1Y3QgZG9tYWluICpkID0gdi0+ZG9tYWluOw0KPiBUaGVyZSBpcyBubyBuZWVkIGZvciBh
IHNlcGFyYXRlIGxvY2FsIHZhcmlhYmxlIGlmIGl0J3Mgb25seSB1c2VkIG9uY2UuIEluIHRoaXMN
Cj4gc2VyaWVzLCBwbGVhc2UganVzdCB1c2UgYHYtPmRvbWFpbmAgZm9yIGBpc192cG11X2RvbWFp
bigpYC4NCg0KT2theS4NCg0KPiA+ICsgICAgICAgIHVuaW9uIGNwdWluZm9fZGJnMzIgaW5mb19k
YmczMiA9IGRvbWFpbl9jcHVpbmZvLmRiZzMyOw0KPiA+ICsNCj4gPiArICAgICAgICBpZiAoICFp
c192cG11X2RvbWFpbihkKSApDQo+ID4gKyAgICAgICAgew0KPiBQbGVhc2Ugb21pdCB0aGUgYnJh
Y2VzIGZvciBhIHNpbmdsZSBsaW5lIGBpZmAgYmxvY2suDQoNCk9rYXkuDQoNCj4gPiArICAgICAg
ICAgICAgaW5mb19kYmczMi5wZXJmbW9uID0gMDsNCj4gPiArICAgICAgICB9DQo+ID4gKw0KPiA+
ICsgICAgICAgIHJldHVybiBoYW5kbGVfcm9fcmVhZF92YWwocmVncywgcmVnaWR4LCBoc3Iuc3lz
cmVnLnJlYWQsIGhzciwgMSwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGluZm9fZGJnMzIuYml0c1swXSk7DQo+ID4gKyAgICB9DQoNCj4gPiAtICAgIEdFTkVSQVRFX1RJ
RDNfSU5GTyhJRF9BQTY0REZSMF9FTDEsIGRiZzY0LCAwKQ0KPiA+IC0gICAgR0VORVJBVEVfVElE
M19JTkZPKElEX0FBNjRERlIxX0VMMSwgZGJnNjQsIDEpDQo+ID4gKw0KPiA+ICsgICAgY2FzZSBI
U1JfU1lTUkVHX0lEX0FBNjRERlIwX0VMMToNCj4gPiArICAgIHsNCj4gPiArICAgICAgICBzdHJ1
Y3QgZG9tYWluICpkID0gdi0+ZG9tYWluOw0KPiA+ICsgICAgICAgIHVuaW9uIGNwdWluZm9fZGJn
NjQgaW5mb19kYmc2NCA9IGRvbWFpbl9jcHVpbmZvLmRiZzY0Ow0KPiA+ICsNCj4gPiArICAgICAg
ICBpZiAoICFpc192cG11X2RvbWFpbihkKSApDQo+ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAg
ICAgICBpbmZvX2RiZzY0LnBtdV92ZXIgPSAwOw0KPiA+ICsgICAgICAgICAgICBpbmZvX2RiZzY0
LnBtc3MgPSAwOw0KPiA+ICsgICAgICAgICAgICBpbmZvX2RiZzY0Lm10cG11ID0gMDsNCj4gV2h5
IGRvbid0IHlvdSBjbGVhciBocG1uMD8NCg0KT2theSwgSSB3aWxsIGFsc28gY2xlYXIgaHBtbjAu
DQoNCj4gPiArICAgICAgICB9DQo+ID4gKw0KPiA+ICsgICAgICAgIHJldHVybiBoYW5kbGVfcm9f
cmVhZF92YWwocmVncywgcmVnaWR4LCBoc3Iuc3lzcmVnLnJlYWQsIGhzciwgMSwNCj4gPiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm9fZGJnNjQuYml0c1swXSk7DQo+ID4g
KyAgICB9DQo+ID4gKw0KPiA+ICsgICAgY2FzZSBIU1JfU1lTUkVHX0lEX0FBNjRERlIxX0VMMToN
Cj4gPiArICAgIHsNCj4gPiArICAgICAgICBzdHJ1Y3QgZG9tYWluICpkID0gdi0+ZG9tYWluOw0K
PiA+ICsgICAgICAgIHVuaW9uIGNwdWluZm9fZGJnNjQgaW5mb19kYmc2NCA9IGRvbWFpbl9jcHVp
bmZvLmRiZzY0Ow0KPiA+ICsNCj4gPiArICAgICAgICBpZiAoICFpc192cG11X2RvbWFpbihkKSAp
DQo+ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAgICAgICBpbmZvX2RiZzY0LnN5c3BtdWlkID0g
MDsNCj4gPiArICAgICAgICAgICAgaW5mb19kYmc2NC5zcG11ID0gMDsNCj4gU3lzdGVtIFBNVSBh
Y2Nlc3NlcyB1bmRlZiBmb3IgYSB2UE1VLWVuYWJsZWQgZG9tYWluIHRvby4gQ2xlYXIgdGhlbSB0
b2dldGhlcg0KPiB3aXRoIFNQRSwgVFJCRSwgZXRjLg0KDQpVbmRlcnN0b29kLg0KDQo+ID4gKyAg
ICAgICAgICAgIGluZm9fZGJnNjQucG1pY250ciA9IDA7DQo+ID4gKyAgICAgICAgICAgIGluZm9f
ZGJnNjQuZWJlcCA9IDA7DQo+IEZFQVRfRUJFUCBpcyBBcm12OSBqdXN0IGxpa2UgU0VCRVAsIHNv
IHlvdSBzaG91bGQgYXBwbHkgbXkgY29tbWVudHMgdG8gaXQgYXMgd2VsbC4NCg0KT2theS4NCiAN
Cj4gPiArICAgICAgICAgICAgaW5mb19kYmc2NC5kcGZ6cyA9IDA7DQo+ID4gKyAgICAgICAgfQ0K
PiA+ICsNCj4gPiArICAgICAgICByZXR1cm4gaGFuZGxlX3JvX3JlYWRfdmFsKHJlZ3MsIHJlZ2lk
eCwgaHNyLnN5c3JlZy5yZWFkLCBoc3IsIDEsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBpbmZvX2RiZzY0LmJpdHNbMV0pOw0KPiA+ICsgICAgfQ0KDQo+ID4gLS0tIGEv
eGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2NwcmVncy5oDQo+ID4gKysrIGIveGVuL2FyY2gvYXJt
L2luY2x1ZGUvYXNtL2NwcmVncy5oDQo+ID4gQEAgLTI0Niw2ICsyNDYsNyBAQA0KPiA+ICAjZGVm
aW5lIFBNSU5URU5TRVQgICAgICBwMTUsMCxjOSxjMTQsMSAgLyogUGVyZi4gTW9uLiBJbnRlcnJ1
cHQgRW5hYmxlDQo+IFNldCBSZWdpc3RlciAqLw0KPiA+ICAjZGVmaW5lIFBNSU5URU5DTFIgICAg
ICBwMTUsMCxjOSxjMTQsMiAgLyogUGVyZi4gTW9uLiBJbnRlcnJ1cHQgRW5hYmxlDQo+IENsZWFy
IFJlZ2lzdGVyICovDQo+ID4gICNkZWZpbmUgUE1PVlNTRVQgICAgICAgIHAxNSwwLGM5LGMxNCwz
ICAvKiBQZXJmLiBNb24uIE92ZXJmbG93IEZsYWcNCj4gU3RhdHVzIFNldCByZWdpc3RlciAqLw0K
PiA+ICsjZGVmaW5lIFBNTUlSICAgICAgICAgICBwMTUsMCxjOSxjMTQsNiAgLyogUGVyZi4gTW9u
LiBQZXJmb3JtYW5jZQ0KPiBNb25pdG9ycyBNYWNoaW5lIElkZW50aWZpY2F0aW9uIFJlZ2lzdGVy
ICovDQo+IFBsZWFzZSBkcm9wICJQZXJmb3JtYW5jZSBNb25pdG9ycyIuIEl0J3MgdGhlIHNhbWUg
YXMgIlBlcmYuIE1vbiIuDQoNCk9rYXkNCg0KPiA+IC0tLSBhL3hlbi9hcmNoL2FybS92Y3ByZWcu
Yw0KPiA+ICsrKyBiL3hlbi9hcmNoL2FybS92Y3ByZWcuYw0KPiA+IEBAIC0zMDUsNiArMzA1LDcg
QEAgdm9pZCBkb19jcDE1XzMyKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLCBjb25zdA0KPiB1
bmlvbiBoc3IgaHNyKQ0KPiA+ICAgICAgY2FzZSBIU1JfQ1BSRUczMihQTVhFVlRZUEVSKToNCj4g
PiAgICAgIGNhc2UgSFNSX0NQUkVHMzIoUE1YRVZDTlRSKToNCj4gPiAgICAgIGNhc2UgSFNSX0NQ
UkVHMzIoUE1PVlNTRVQpOg0KPiA+ICsgICAgY2FzZSBIU1JfQ1BSRUczMihQTU1JUik6DQo+IFBN
TUlSIGlzIEVMMSBvbmx5LCBzbyBpdCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhpcyBibG9jayBhbmQg
dGhpcyBjb21tZW50LiBQbGFjZQ0KPiBpdCBuZXh0IHRvIFBNSU5URU5DTFIuDQoNCk9rYXkNCg0K
PiA+IEBAIC0zMjAsOCArMzIxLDM2IEBAIHZvaWQgZG9fY3AxNV8zMihzdHJ1Y3QgY3B1X3VzZXJf
cmVncyAqcmVncywgY29uc3QNCj4gdW5pb24gaHNyIGhzcikNCj4gPiAgICAgIEdFTkVSQVRFX1RJ
RDNfSU5GTyhJRF9QRlIwLCBwZnIzMiwgMCkNCj4gPiAgICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJ
RF9QRlIxLCBwZnIzMiwgMSkNCj4gPiAgICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9QRlIyLCBw
ZnIzMiwgMikNCj4gPiAtICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9ERlIwLCBkYmczMiwgMCkN
Cj4gPiAtICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9ERlIxLCBkYmczMiwgMSkNCj4gPiArDQo+
ID4gKyAgICBjYXNlIEhTUl9DUFJFRzMyKElEX0RGUjApOg0KPiA+ICsgICAgew0KPiA+ICsgICAg
ICAgIHN0cnVjdCBkb21haW4gKmQgPSB2LT5kb21haW47DQo+ID4gKyAgICAgICAgdW5pb24gY3B1
aW5mb19kYmczMiBpbmZvX2RiZzMyID0gZG9tYWluX2NwdWluZm8uZGJnMzI7DQo+ID4gKw0KPiA+
ICsgICAgICAgIGlmICggIWlzX3ZwbXVfZG9tYWluKGQpICkNCj4gPiArICAgICAgICB7DQo+ID4g
KyAgICAgICAgICAgIGluZm9fZGJnMzIucGVyZm1vbiA9IDA7DQo+ID4gKyAgICAgICAgfQ0KPiA+
ICsNCj4gPiArICAgICAgICByZXR1cm4gaGFuZGxlX3JvX3JlYWRfdmFsKHJlZ3MsIHJlZ2lkeCwg
aHNyLnN5c3JlZy5yZWFkLCBoc3IsIDEsDQo+IFRoaXMgYnJlYWtzIHRoZSBhcm0zMiBidWlsZCAo
eW91IHNob3VsZCBhbHdheXMgYXQgbGVhc3QgYnVpbGQgdGVzdCB0aGUgcGF0Y2hlcyk6DQo+IHMv
aHNyLnN5c3JlZy5yZWFkL2NwMzIucmVhZC8NCg0KSSB3aWxsIGZpeCBpdC4NCg0KPiA+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5mb19kYmczMi5iaXRzWzBdKTsNCj4gPiAr
ICAgIH0NCj4gPiArDQoNClRoYW5rIHlvdSwNCkhpcm9rYXp1IFRha2FoYXNoaS4NCg==


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 06:23:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 06:23:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399052.1635260 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wykZZ-0002OG-9D; Tue, 25 Aug 2026 06:23:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399052.1635260; Tue, 25 Aug 2026 06:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wykZZ-0002O9-5w; Tue, 25 Aug 2026 06:23:49 +0000
Received: by outflank-mailman (input) for mailman id 1399052;
 Tue, 25 Aug 2026 06:23:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wykZY-0002Nw-BX
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 06:23:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wykZV-001HsD-TF
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:23:45 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8d34ed-bab6-0a2a0a5309dd-0a2a450cd374-6
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 08:23:45 +0200
Received: from [52.101.52.69]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8d34f0-f479-0a2a450c0019-346534456d20-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 08:23:45 +0200
Received: from CH0PR03CA0090.namprd03.prod.outlook.com (2603:10b6:610:cc::35)
 by SA1PR12MB7444.namprd12.prod.outlook.com (2603:10b6:806:2b3::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug
 2026 06:23:40 +0000
Received: from CH1PEPF0000AD7D.namprd04.prod.outlook.com
 (2603:10b6:610:cc:cafe::91) by CH0PR03CA0090.outlook.office365.com
 (2603:10b6:610:cc::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.339.12 via Frontend Transport; Tue,
 25 Aug 2026 06:23:40 +0000
Received: from satlexmb07.amd.com (149.199.90.133) by
 CH1PEPF0000AD7D.mail.protection.outlook.com (10.167.244.86) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Tue, 25 Aug 2026 06:23:39 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 25 Aug
 2026 01:23:39 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Tue, 25 Aug 2026 01:23:37 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q50lXs27T1iuc+qqZSwZqfAYqKCFngoqRAyFST/Lw0IYHdyP0DBcMaGlrp3ieM70SsKxV7oHuIqj/YHQdOEVgEPEmKgN0pa0uxLRVnEBPEiGDAXq45rha1dUSJmOB1kLMLv+x17+TDbN3BhfXnwCskbSVttoyvzx/8J2tn/SMyba/dRS5oI32zSUIquNLV8KvS8lTFm/JplFnq417SKaxPFOAjUMh0G1R+jrZOxyqn6I6XprRleJ29VVuj5bZWwsmOS3R6mwD5wsY8FbUuSF/FJTCwjw2oZQzBNqmoW6VcWr0Dsanhm/3uHUOZS8NHNn4jkm927Vt0/X2Uq9cvEAlw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IeCCh4kl9hMtFac2eqyAM41Qpl9zaBARN10w+J2uS9I=;
 b=C3ncx6cfHQr5BG32krzz/+MAn/YDbFfsOL7huQJKvIVX103ILFZ8tDi/CElrReyWalb9vq8PUK+ZRygMLhrPczf7Obu06w6p4z7O7NJj98Jef5IuGCS+0qnqVlC9uG0V/RM6NPGjXLcFUj//4LwEK8N8GnVeTHH21ASPkh4Yn3rEzRET0JkEl+7diFz9rijolmSN3LjRtFZJQTXiVKknt3+p6cDAwFbc9o5U2aJXDdkLWXgO6sH/gyLDbE27UB1rNNjv1lp7ZpeOEbhO1XzRhwsHR3JWbEGQEzbHGq2un9ucRhq2Wwxa29Bzh5ypnL591m1JDoQo6ExYDNARclaF9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
 is 149.199.90.133) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=amd.com; dmarc=fail (p=quarantine sp=quarantine pct=100)
 action=quarantine header.from=amd.com; dkim=none (message not signed);
 arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IeCCh4kl9hMtFac2eqyAM41Qpl9zaBARN10w+J2uS9I=;
 b=VBX7eOZZOqKRSfuMJe6KXDL7/omU+NVmtmEebGi1iKpAcgQaNOopY5JgSjxnFHAoRcCeVmBHYS/A+WPhmvpjq/ZO9931yk1aZwaquPG4EnnYLj8uYhIjrWZxBsiYsVomqUuJAR+u1eyfRsnGAXxw4EBmv2RNEkkHKJXcR/kZKtA=
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
 149.199.90.133) smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine header.from=amd.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 amd.com discourages use of 149.199.90.133 as permitted sender)
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH 0/2] panic_PAR refactoring
Date: Tue, 25 Aug 2026 08:23:27 +0200
Message-ID: <20260825062329.16762-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7D:EE_|SA1PR12MB7444:EE_
X-MS-Office365-Filtering-Correlation-Id: 4f701afe-2637-4346-f2f1-08df02716793
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|82310400026|36860700016|1800799024|376014|56012099006|11063799006|10067099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	4nM+G7FXB6kXsrWjTUNdBwsTCDSOb+MgSahHaz0XXhH0uSV/pENHeQWyOTGdKyPAgulxyorZ+IMn4Qld2TrUOTYzaS6uoahQOU8JE2m1nMHcNGtSdiB5CHxdMBn4LM+nsiJOCD5zTDhySWqB+5K9FbrsN/DqtQ6FpM4hWow+ZCvv1HcBZ4qzdHtuQaSuIbU7j2N+/KukWH95GQhBBSg90OFMKO9o5Qyjvf67rzL3JH8Nmq84LBffbPferXNSEIadJ3LC5un1g0QSCOfYKWs1AuvQhIDmpWccPYbkJxDWe12gtGKIYqRtiG+U+pxbTfNO52VeePLAzf4PsJOOy7hxep8lLfaQLvhajiXF1ncbGg4mytszMVBYF45QqmqfraZpYU8O4lxbrfbZYVrxAb+cupjnKqwrveuJpj7EEsnImLhmjfdHSlYBVjusKnUmst73LFhC/YG74pXMcH6EEpnyRG5NOkXy/QjRqZH3xQ/wlZh6Aw2Kh+D/SGpM7dZUWKZC8QoEbJ3EhSI5kyVT06rPw6+x7eyXwZ+kAnC8PHfVsvny4ir1PbnRZIfOWWnUNb5c38QRuWecWS/mikzjPfst5vwiNkmBD5RAN6P46fKWLtWWKwqp1H1e9ucgZOWCnVG4aZuvABbql+pjPIDDv9jdNUbyJIqzGse8fmbwRQ/liKURoT/2zLu9XdjgLPUdNsG2ibKy+BhI6iPL41RVF9epPQ==
X-Forefront-Antispam-Report:
	CIP:149.199.90.133;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:unknown-90-133.xilinx.com;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(36860700016)(1800799024)(376014)(56012099006)(11063799006)(10067099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	14JvVfqsgzZojymRqRfaeK8P1Ybq9MN5vy6rmLI3C1rUOo+p5KDoQ6vGVIm64ur9epMv/T8us3dbXbRX10z1RHZdhxdmBiBSa3PsTEf2or7lhrhNcl1PE90MiLL1FSW2Wb4Gtb590cNX52udj74XX7m8lTHAVbBzgfDTgC8j+YDajzwO+rI5WP4rptDR3bk19OLmbOjx9PhiSulLwkp1aUEkCFW+vOK4d1Z1lANSuLNGxaN947YI8vPKTIpog9OGSePGKDuE2Lj1MCvwcbAiM4iL/Jqdj4GU2IwFVgvQznwo/qDKmfZe3zhEeGgWyKGIBS/ALyPj31lQHbVeXkAp0tGiH7ofSg37nBLqdzaAzSmRCVHZkKLhlSxmLgn6hzG38/GSshzsTqPR6fZbRKJLAlJPyyuaVqNVDhAzo46YTowB7etWg0DzGXDVOY9y0obq
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2026 06:23:39.9780
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f701afe-2637-4346-f2f1-08df02716793
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[149.199.90.133];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD7D.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7444
X-purgate-ID: tlsNG-d25034/1787639025-51B35A5B-ABB7C8EB/0/0
X-purgate-type: clean
X-purgate-size: 334

Michal Orzel (2):
  xen/arm: traps: report level 0 faults in panic_PAR()
  xen/arm: traps: drop unreachable stage 2 decoding from panic_PAR()

 xen/arch/arm/include/asm/processor.h |  3 ++-
 xen/arch/arm/traps.c                 | 25 +++++++++++++++++--------
 2 files changed, 19 insertions(+), 9 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 06:23:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 06:23:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399053.1635265 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wykZZ-0002Q2-Gs; Tue, 25 Aug 2026 06:23:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399053.1635265; Tue, 25 Aug 2026 06:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wykZZ-0002Pa-CR; Tue, 25 Aug 2026 06:23:49 +0000
Received: by outflank-mailman (input) for mailman id 1399053;
 Tue, 25 Aug 2026 06:23:48 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wykZY-0002Nx-BX
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 06:23:48 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wykZX-001HsD-9q
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:23:47 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8d34d4-bab6-0a2a0a5309dd-0a2a4509a984-32
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 08:23:46 +0200
Received: from [40.93.198.43]
 (helo=CY7PR03CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8d34f0-be1a-0a2a45090019-285dc62b6adb-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 08:23:46 +0200
Received: from CH5PR04CA0014.namprd04.prod.outlook.com (2603:10b6:610:1f4::26)
 by CH8PR12MB9742.namprd12.prod.outlook.com (2603:10b6:610:27a::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug
 2026 06:23:42 +0000
Received: from CH1PEPF0000AD7C.namprd04.prod.outlook.com
 (2603:10b6:610:1f4:cafe::94) by CH5PR04CA0014.outlook.office365.com
 (2603:10b6:610:1f4::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.6 via Frontend Transport; Tue, 25
 Aug 2026 06:23:42 +0000
Received: from satlexmb07.amd.com (149.199.90.133) by
 CH1PEPF0000AD7C.mail.protection.outlook.com (10.167.244.84) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Tue, 25 Aug 2026 06:23:41 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 25 Aug
 2026 01:23:41 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Tue, 25 Aug 2026 01:23:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UlqT/v8uI6IiJbJvn84yXdaH6jVZCpLjMZhqb8KySW4cUzz5SOJCbvPbkmr8KwCH4hxp+cnQAdWFHdxhwI6uwhgTUiVDt4XvkBkxQ8GPgAr3rQOUU9tOY45Nr+JgvRKBDG3b9M0yqZh1pSdqQdki8elzSwUWyrsLTcUlYB5MR+FNinTxBc+5LNrZTJfwu1ahaS7z8IwsPwf8hG5tRlEDBdrDx74Pg10vQisCUevO6B0Q4tHQ9bSkn3jnIrAR5wTuod/+6VaOV3kBWpNC4CSKsqXEcxGaX7ZHdlIe2CLT2BBtGQPzizcpGLvXD/pMllpeyjsD8YIuUxKVtFcwA66mWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=t0tG7LxrvduKAPMs/G1qHGRWDG7gX+0MAt1PYS3j94A=;
 b=YRq52nREsAAJGrsDA3pK1XpmdG2aahRiGvPfPyMJkGzrJyJgnEZnCcCpGdYvEMerer1PFBznK8RKRidxTJi3Dy06Lrpje+sT39EoQ2WTI1fEa2YHKXny0o6nDG5n8AZiiT++iHk5affvWkLraspJeWuLGwLhsjO1eHobgXMCp5aF2DG7XxgqMA6Q86D6Vuno7GL7pywPtXLeGmUf25jIZwZP0mZpGmy9esxRiIF2WossA4an62FDdOPh1wj/28tDVZSrd6MwlAj8BThjJsiH2EOnkVRfxqFEo3Ivhziloo/Kfz+F/OUIuZbOYn5Hbw7Usn6EXto0m+uNqOLR4yk7tw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
 is 149.199.90.133) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=amd.com; dmarc=fail (p=quarantine sp=quarantine pct=100)
 action=quarantine header.from=amd.com; dkim=none (message not signed);
 arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=t0tG7LxrvduKAPMs/G1qHGRWDG7gX+0MAt1PYS3j94A=;
 b=LEa3B8/GjREJYJivUoW2hkOG3JSRFGlqUKH8oXkMPsapmitN3jOE6nKVmsXMjNaKZXJzonaYzXY2MyjJ2eClRvSEhYv74Ls6Gv89uLkQ7SKqMfHzTxosKPpCLSCHQNwvnWoSN03LHn7+FpsqqpBteo7tt7zpKDX49Ww72XjBYKA=
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
 149.199.90.133) smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine header.from=amd.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 amd.com discourages use of 149.199.90.133 as permitted sender)
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH 1/2] xen/arm: traps: report level 0 faults in panic_PAR()
Date: Tue, 25 Aug 2026 08:23:28 +0200
Message-ID: <20260825062329.16762-2-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260825062329.16762-1-michal.orzel@amd.com>
References: <20260825062329.16762-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7C:EE_|CH8PR12MB9742:EE_
X-MS-Office365-Filtering-Correlation-Id: 12248c47-8c5b-44de-9ecd-08df027168b0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|82310400026|36860700016|376014|1800799024|18002099003|22082099003|56012099006|11063799006|10067099003|3023799007;
X-Microsoft-Antispam-Message-Info:
	cE8d0hOQ85Mn2MzdTgNgdWpwJw+OAIkKyZjgI0qZcs0JLiBQoCEBiJRomUBpgyGqjlqRztMO2JxbOnY+ueQtw54XpImgE4D/jHMn8ZwoTLSRkq+Gv/okw+p4nX6NHDmqytfDtEljyI4y3lBN0PAHVOBwVSB+sT58g2vuT/wrXoo9g1RFx+6mv57UVo7jiZWAleyIanYAIVZXWpSjB5C1k3rnoysjgOlmGvCraVFaAFmexejdeXshjOfyixK0Ylv2ugPGgj5HOH+QuQCvfWG6soQn/MDqCiPuvLAUlRSvmTF/1ZMPhHtArw8VGWG4bs9GxdwwZanEz3N9g0ViMz/huqGFeD6TCX/r1M8EH2daIqITqm9jxeB/VnpmBlupelcYoEz/dhoIWQQo/UcbAzNZFgPbobc33Wz3hVWM4lL6XW1We6o+wHAsZ1uQybhy3MwDgcOmr/m4saClU1YWVikgFhiRwq3E+f2sweayUbGThP3OZb42GDiYZffbx8kgNVGNMmZk6XLXyMtjcQMMOYVq2oWIWOB7q5iePFZHJcLZjJz0GnwEUKtvp8L3BttyQjf69ESgFUrvBHpOXUamtgA0HPP1DT4WzLd1QSdHNfezFgXrxiNxrKZQuYmNmpZVTAFKIt5rhaccGEmwF3SyRy3oinW08vlnRuCMTW6SkK0JtDOfYzolY2Y8TDhXnkh+KQ0jwQeMNK0j348Bar4AVD1ucg==
X-Forefront-Antispam-Report:
	CIP:149.199.90.133;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:unknown-90-133.xilinx.com;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(36860700016)(376014)(1800799024)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	kiyoA7XlN1MvYiP/IEErxZ/mNadawhY6HPLOTtCZwo3oXQc+j0xleWmLMtmACKxZ+nq+h/bGHxR9uG2lfjDOXDUOz9nV2pOQziKUX8K+ZVAOVtWXXsSPZgLvCmALPESvGYsMNPkSyyEWwOvrSBvwyWr6QyyqudOzJHH1ECcIDffguWRqoHfMhZ7kRThSdbD90eem3Hk8ZTyYCvZH3OV8M/ROipB3E0RljU1Jty9wHnExH+16HZgrquAhkIrzK2yCJWHrRM2X9weEArQRhGG4gKQFtuTzG1Rkwo6xocUUPyOjw818uWwn9JkIcQIfEkr56/EJ7LcsoSiP7dljbIPo4DjTpj+Fg+fffoXSSrxVRmjidbpn0NMIuiFgitSTB2i8VlD4bCEK1C8+hmJlr7GXy0VbocUsizLY+A1b//sVo2UwNHR7ylntbxQ8HS82/5+e
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2026 06:23:41.9454
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 12248c47-8c5b-44de-9ecd-08df027168b0
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[149.199.90.133];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD7C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR12MB9742
X-purgate-ID: tlsNG-bad1c0/1787639026-FCC15034-4C6AC49A/0/0
X-purgate-type: clean
X-purgate-size: 2420

decode_fsc() derives the fault level from the low two bits of the FSC, so
level 0 is a valid output: FSC_FLT_TRANS is 0x04, i.e. "translation fault,
level 0".

This is reachable on arm64 because xen_pgtable is the zeroeth-level root,
but fsc_level_str() has no case for it and prints " (level invalid)"
instead. At the time the function was created Xen used only three levels.

Add the missing case. On arm32 the zeroeth level does not exist, hence
guard the case by CONFIG_ARM_64.

While at it, make decode_fsc() decode also address size faults.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/arch/arm/include/asm/processor.h | 2 ++
 xen/arch/arm/traps.c                 | 8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index a3753c317fff..509040a1cdc0 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -521,6 +521,7 @@ extern register_t __cpu_logical_map[];
 /*
  * 543210 BIT
  * 00XXLL -- XX Fault Level LL
+ * ..00LL -- Address Size Fault LL
  * ..01LL -- Translation Fault LL
  * ..10LL -- Access Fault LL
  * ..11LL -- Permission Fault LL
@@ -534,6 +535,7 @@ extern register_t __cpu_logical_map[];
 #define FSC_TYPE_OTH   (_AC(0x02,U)<<4)
 #define FSC_TYPE_IMPL  (_AC(0x03,U)<<4)
 
+#define FSC_FLT_ADDR_SIZE (0x00)
 #define FSC_FLT_TRANS  (0x04)
 #define FSC_FLT_ACCESS (0x08)
 #define FSC_FLT_PERM   (0x0c)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0c01f37ad6b4..dc0ec8a345ed 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -307,6 +307,10 @@ static const char *decode_fsc(uint32_t fsc, int *level)
 
     switch ( fsc & 0x3f )
     {
+    case FSC_FLT_ADDR_SIZE ... FSC_FLT_ADDR_SIZE + 3:
+        msg = "Address size fault";
+        *level = fsc & FSC_LL_MASK;
+        break;
     case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
         msg = "Translation fault";
         *level = fsc & FSC_LL_MASK;
@@ -363,6 +367,10 @@ static const char *fsc_level_str(int level)
     switch ( level )
     {
     case -1: return "";
+#ifdef CONFIG_ARM_64
+    /* On arm32 the zeroeth level does not exist */
+    case 0:  return " at level 0";
+#endif
     case 1:  return " at level 1";
     case 2:  return " at level 2";
     case 3:  return " at level 3";
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 06:23:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 06:23:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399054.1635278 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wykZh-0002qI-RL; Tue, 25 Aug 2026 06:23:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399054.1635278; Tue, 25 Aug 2026 06:23:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wykZh-0002qB-Nk; Tue, 25 Aug 2026 06:23:57 +0000
Received: by outflank-mailman (input) for mailman id 1399054;
 Tue, 25 Aug 2026 06:23:56 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wykZg-0002p7-Ct
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 06:23:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wykZf-007bIM-Dy
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:23:55 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8d34f9-e002-0a2a0a5209dd-0a2a4502ecf2-10
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 08:23:55 +0200
Received: from [40.93.195.6]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8d34f9-6ca4-0a2a45020019-285dc306d149-4
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 08:23:54 +0200
Received: from SJ0PR03CA0165.namprd03.prod.outlook.com (2603:10b6:a03:338::20)
 by CY8PR12MB7100.namprd12.prod.outlook.com (2603:10b6:930:60::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug
 2026 06:23:44 +0000
Received: from SJ5PEPF000001C9.namprd05.prod.outlook.com
 (2603:10b6:a03:338:cafe::36) by SJ0PR03CA0165.outlook.office365.com
 (2603:10b6:a03:338::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.7 via Frontend Transport; Tue, 25
 Aug 2026 06:23:44 +0000
Received: from satlexmb08.amd.com (149.199.90.133) by
 SJ5PEPF000001C9.mail.protection.outlook.com (10.167.242.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Tue, 25 Aug 2026 06:23:43 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 25 Aug
 2026 01:23:43 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 25 Aug
 2026 01:23:42 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Tue, 25 Aug 2026 01:23:41 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lYSiyxEm/tT+8AbAVSiXaCS5HqCqek/ylawjTIenGgKXtGz74fs/jAOQ1oV+KhExLgzHOzNfIH96n9prtYG/PflASEOkSB4cNlpy012MqBQInWhA2zGFFbEF0ZrGXKoadsieBCJn5tt5iO3Bb8J7+VTsv1xNeC+zMXvr5xUm4grSHT119ZPIuPKrxEA2WXGNgOmvewr3UjWRHmMmyFjc1okgoEjLbzGkfRX8knnCYaMRmeZYNs6GqlOSdLEIXW71a1qkurK6OJhhfa/IZwgQWKYbvCvFUSMIcSRA3cd941yHi5dRY1XCFRIkark0jC4A2DUy63aQ4xs7yWgrDky+0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=n4jxQvxAE1oi5hVrdaQxGmUbeCaHi8CJIvOPCare3V4=;
 b=xu8Acbcg+h+YrDOitbMIGnUxOENRRXZW4l4gOojKgqmS3XfAUF+0UPDh7c4pgeKgv+w3gghDq0fwaguxFBb4sH9HpCNhHiRFGjSrhVPQpWhQHYQo7Wti1XjjnNIU7G+Yvqv/nCq/MXwiaN7J4BRaWyZs/sURlCt6v+qa3os8JvLjEqtE9xe/2leeIHsiGfchqlK6gKYb4nTZGBNalwUw6UvHKdPwvs7GbOf+M6FhpiORi8fsIDPz6TZ1LzlheZL7KWjwldRa7k7Kyzr/3/qE77sUBsZJXExvpZfm8Qg5L3xHhFVi2EHwZ/Uhy2eBbreWK/7Nb+VrhF7pA2MqXpToSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
 is 149.199.90.133) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=amd.com; dmarc=fail (p=quarantine sp=quarantine pct=100)
 action=quarantine header.from=amd.com; dkim=none (message not signed);
 arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=n4jxQvxAE1oi5hVrdaQxGmUbeCaHi8CJIvOPCare3V4=;
 b=nJ/amJxEKD77HGqbYcCltDBbpkWL+Y4ne5ezz9DSjcXqGcl03Vr0yBvSrH8aV9avFm6YkO5MMdfu4EtFTgLydbgrvhBJkJKvIQy+zuIuF+6TUAOP9JIcop4tUlpGLN4JYhuHLfyO9E7PpnDp3jPSqcyJF8EHsLxVs2dNSpJqaZo=
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
 149.199.90.133) smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine header.from=amd.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 amd.com discourages use of 149.199.90.133 as permitted sender)
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Michal Orzel <michal.orzel@amd.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH 2/2] xen/arm: traps: drop unreachable stage 2 decoding from panic_PAR()
Date: Tue, 25 Aug 2026 08:23:29 +0200
Message-ID: <20260825062329.16762-3-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260825062329.16762-1-michal.orzel@amd.com>
References: <20260825062329.16762-1-michal.orzel@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C9:EE_|CY8PR12MB7100:EE_
X-MS-Office365-Filtering-Correlation-Id: b03bdb35-2d08-4c46-0036-08df027169d8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|1800799024|82310400026|36860700016|376014|56012099006|10067099003|22082099003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	hLsmZfnpRuObw/XfEkWPrKZs/n7HMmeRsDROFkDFImKKaH8cRr4aYbWukaJtwxg3d0SQz5QemxGDeVLC2Z11XyMpcVavaJv0dTgP/q1+UQRkKEEvUohIxlozi6tTnTStC+2VrKijRRXtbIXMoZlkXOe7WoWdD0/dVCJka+KwaiDYaVoG+vJBMIZziOcuDFiLCRHGkbZ4CBUqNLHTn5+S8PtIWNQXNtM4QdlZZ6ovEnUvCcRdwKc4QAP8bqXMuQ9wHbzlHJIxDHtREgwN61QpHJagy5nQRiPQhrSpHZw6MO1GK+BOsd4BCsDeEfsfT6vU8mWJxbHL4gnmLnbi0yihAUOMJmcS7OztoASG9ZqXCxlTdvqqAESoZ2ZHx3HdajIQ+ZA7lzKsN4nx0qIP6+EgD22npZPe9p14KDl8APlcwZFuS27WRHpburO/vATBXxXb6H50aWgquyBXH7+Fza6U+h8cwTrivXntzP/OsQc0lz1PFDDnUAcLObPx2b9XGN5wjIhbEQ+gsWH8SNz8/9dIxgII/zoxmUI3vpcAxWqIYSHPHUNeF8ddK55n7xbStGM54awnFQkV7+wtrT/XgUXxDklsxzXTGvNqlkCkTlPJrT6vju8BGvIWUhb8iBr776WCyv9yfQH9LuNU1OBaardRkkg1675+ukSHCGX4KLYYuzSm9Ngl1K24K7oJRgzV5TCI70obhV6TApA9bRf09O055w==
X-Forefront-Antispam-Report:
	CIP:149.199.90.133;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:unknown-90-133.xilinx.com;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(82310400026)(36860700016)(376014)(56012099006)(10067099003)(22082099003)(11063799006)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	QYuvrVdsaEDnjECsUt9liYEnaRi6lO6fAhUn3UfxSLC76SPXeTcY3W5jinUtU5WwQDVr1ao/7u8iZrVmclMxj9TSsyx3IgAsFn0EJkWT4aW7PG9NblAZLb6katMx3B5DFHsKBCtHCgFHKV8ue869ktyQcUgvGoO1omODyY1nDsltihrj5CoDCIQFQar1eLnXEKtBbzAFWOEJedjdpVZqJCBXRcgura83o6/Y59NX6+RZSUhU7dhwfaA7YVgLSPMmQ1OjCcAqvB6yOmLhtyGjqEPEQ9Hngk5CY4HrIsmXsy82Eh/jXdX0FnzbVPm04WhEB7HyTRZZpcUtNqgqUyu7gSwS8pTxYRz7VALaejSp2Xl6qDmZC6V2KB4y72b4yt8XqMlfx9R6AoFSqSF+5CgoTM3UwuLI8fsfj249jQ3KMGua4bkCD1zgBNoXoYnCLsg9
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2026 06:23:43.8915
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b03bdb35-2d08-4c46-0036-08df027169d8
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[149.199.90.133];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001C9.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7100
X-purgate-ID: tlsNG-720697/1787639035-67CBA2AC-95602C8C/0/0
X-purgate-type: clean
X-purgate-size: 2545

panic_PAR() is only called from va_to_par(), which translates using
__va_to_par(), i.e. "at s1e2r" on arm64 and ATS1HR on arm32. Both
perform an EL2 stage 1 only translation, so PAR.S (PAR_STAGE2) and
PAR.PTW (PAR_STAGE21) can never be set.

This has been the case since commit a14447dbcf171 ("xen: arm: do not
panic when failing to translate a guest address"), which made
gva_to_par() and gva_to_ipa() return -EFAULT instead of calling
panic_PAR() for guest translations.

Print stage 1 unconditionally and keep an ASSERT() to document the
invariant. PAR_STAGE21 has no user left, so drop it. While at it, fix
the spacing in the decode_fsc() call.

No functional change intended.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/arch/arm/include/asm/processor.h |  1 -
 xen/arch/arm/traps.c                 | 17 +++++++++--------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 509040a1cdc0..8ee8f88fb4cb 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -507,7 +507,6 @@ extern register_t __cpu_logical_map[];
 /* .... If F == 1 */
 #define PAR_FSC_SHIFT   (1)
 #define PAR_FSC_MASK    (_AC(0x3f,U)<<PAR_FSC_SHIFT)
-#define PAR_STAGE21     (_AC(1,U)<<8)     /* Stage 2 Fault During Stage 1 Walk */
 #define PAR_STAGE2      (_AC(1,U)<<9)     /* Stage 2 Fault */
 
 /* If F == 0 */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index dc0ec8a345ed..1c2bdb7d02c7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -382,16 +382,17 @@ void panic_PAR(uint64_t par)
 {
     const char *msg;
     int level = -1;
-    int stage = par & PAR_STAGE2 ? 2 : 1;
-    int second_in_first = !!(par & PAR_STAGE21);
 
-    msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
+    /*
+     * The only caller translates using "at s1e2r" (arm64) or ATS1HR
+     * (arm32), i.e. an EL2 stage 1 only translation.
+     */
+    ASSERT(!(par & PAR_STAGE2));
+
+    msg = decode_fsc((par & PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
 
-    printk("PAR: %016"PRIx64": %s stage %d%s%s\n",
-           par, msg,
-           stage,
-           second_in_first ? " during second stage lookup" : "",
-           fsc_level_str(level));
+    printk("PAR: %016"PRIx64": %s stage 1%s\n",
+           par, msg, fsc_level_str(level));
 
     panic("Error during Hypervisor-to-physical address translation\n");
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 07:39:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 07:39:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399075.1635286 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wylke-0004Fx-V4; Tue, 25 Aug 2026 07:39:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399075.1635286; Tue, 25 Aug 2026 07:39:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wylke-0004Fq-S4; Tue, 25 Aug 2026 07:39:20 +0000
Received: by outflank-mailman (input) for mailman id 1399075;
 Tue, 25 Aug 2026 07:39:19 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykyta_Poturai@epam.com>) id 1wylkc-0004Fi-Qp
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 07:39:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wylka-00EVdH-2b
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 09:39:16 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a8d4697-e002-0a2a0a5209dd-0a2a450387e8-44
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 09:39:16 +0200
Received: from [52.101.65.96]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykyta_Poturai@epam.com>)
 id 6a8d46a3-fae8-0a2a45030019-346541600823-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 09:39:15 +0200
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by DU4PR03MB10717.eurprd03.prod.outlook.com
 (2603:10a6:10:580::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Tue, 25 Aug
 2026 07:39:12 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::b8c6:f37a:987a:beb%4]) with mapi id 15.21.0339.012; Tue, 25 Aug 2026
 07:39:11 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Nrw3vmonMJAZojqvURj4wcvelSv6rdXOhR19Pe+nYWfxYwK3a7zJPSm7TX+3q5QG5g/rYmRMeueLkj185eTde2IqOJXJq/3lFFwFSHo1Mn/99Oxq58apeqlEHAfY+4s+HEILwEiXs/6HeYGnVr++A5hDv31mxp6IocaZ20Uty17HTI9zpLx47GpEvJkENh37bQqsXXqsZ43ZyJOq6Zw8lGerk05eUnAt9w/6D2T+IixCGlrQFxcIKyQCNM7IGFadAnIUI7VD1gBoihj1KIwc4E84ed8WNF/kMN6lXrJY8wTAJuWHGJ/FQACKuPOQD/9aLVtg04nPPMGCwgeiYauVRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+TPth6n2kKy+a6Rmzs5qWLzPCLDtD1Tl3cujxRxaLKo=;
 b=fQrJELPC7giL30Z63zJqye8uOr77fC687HdllK80RGvtPCXt2N7wDsK96D4FEd/IwYlvmPuCo3VY6koLjaSY0daYdmcbii/VfiDapRSGcts0yLY4txfWCtt6Qk4m858JNioLJpmtGCg2ym3yTWD9KxGBr0atMM2wRp5fhvGy5RMrHq6SITYcCzqVemFCniTXOJtHkNxGP946/z9f1xj1Gei/4C+mhbePMCTRvhE2vazltb5lXyABLdZKbCtZjHZuV2BrcqAahUwmbyva7UPWEhZkaLgYhcpVwpP8BN/RF8I2m6jAhNSg2PkynHMKnMP1yzY7DAn7yqNLG713DL8RZg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+TPth6n2kKy+a6Rmzs5qWLzPCLDtD1Tl3cujxRxaLKo=;
 b=Dlrkpa/6DGyRyFEVsLh928o/Ozfv29OjLUqn/L+oBCe+9L8xGSFurgxy7zZtOxf8xqAs78vTPrtn4Mu0DQedV7I7JTSGzHOVAqRbtBVpoYGuOV1eiP1FOMFpdcN1VfYFup1G8dtXM4vigLQA3uqEVfVTuo43c0+P9bQh2aox3KIsn+MoMUe5kI5b6yj1jotKHzCNDcNuV8GCS4wYbOB8NZSH9gp4Lkcy1l1QaSmmmGos3EsB666ds/JWnLFBoXw4UdFB8a+etcxRQkkkTz5gFh4oy/76uXIU8VRUjBDoNGecHO+B2/ONlV+tGc5GDXktxoeuuR/GwznmQerxXjJaTQ==
From: Mykyta Poturai <Mykyta_Poturai@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Mykyta Poturai <Mykyta_Poturai@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, Rahul Singh <rahul.singh@arm.com>,
	Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>
Subject: [PATCH v4] xen/arm: smmuv3: Add support for removing devices
Thread-Topic: [PATCH v4] xen/arm: smmuv3: Add support for removing devices
Thread-Index: AQHdNGTRISDv+UsXckyT4/28tjPeAA==
Date: Tue, 25 Aug 2026 07:39:10 +0000
Message-ID:
 <56e7734d60ad8cca4279a71b4beb21ca51250386.1787303836.git.mykyta_poturai@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PAVPR03MB10102:EE_|DU4PR03MB10717:EE_
x-ms-office365-filtering-correlation-id: b9266c6c-0ac1-43eb-0ef2-08df027bf451
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|38070700021|6133799003|56012099006|10067099003|11063799006|18002099003;
x-microsoft-antispam-message-info:
 3eFVAoewuKuIsuwAXizEfBGCU/XRwW5NdjCFqhljGJ6lgsbKmpmnBcXqTHnawjniyaqGCGihcYbaGcgyUYrrVC+b+keF6U/7j31Kgegl20yodbTq4jtJ0x3T0T/KUUVwEXI6/x022azqT004F8WkM7eijwoBFY1HGE1zUqUztPkxnpjZUrEqBgjQkYEItkOAMGgjFf2e79/xGSOZHrTWuQ/FWyTFvluTTR75h6RRQx5VGsvaMe2NvGytBgY5W2sRlvmPSr1IRDSnXcwzJjPAME41a5Jbx1dR4gF15kQ3yV2wjgc6y/2Y4uCiNmvZtxo5XS8jkrb9/JqZpyC+wHOErIc0H1WxZPCcwChtF88x4KK9fujVswkTWmnxuiSI0h2Kh59PPK6aNyUw+2nCNXbdrzRpeR8gu6+mIM56EveH78gIxlJTYP02jm3GMR1ZSVOD+KeO7N3v7C2yY36vOGo/sTsEtYvvcLUT4ig1U40127kKoiqkvuKS2X3z1KitN1NsQ7Y+Ewq9THOUJJhhjTiIN0pIFJTQT98HRJQkUthJE2Sm4OW7QgOdZ0tv1kRHGn1KDydkgeexPj7f/pYUWRKIYuLt32Sc/ZYjHNTsNz0wgtpDFDBS9WWVTU702DoVJmBCzeZOBMN4HsfZX54mQtc2QYwb9UjViW6rmo8a2H0DwOo=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(38070700021)(6133799003)(56012099006)(10067099003)(11063799006)(18002099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?0xgk+Kk0XM0sKz2eowk8+RgwUU45X0LtqDkHtEIslpSCvWDZBha+bz/5iZ?=
 =?iso-8859-1?Q?MKCBTJkLP/fRhqHgllEq3nbsB6wWwIisfJEEkjsi3ybYq8Zg1sHp9Ydog9?=
 =?iso-8859-1?Q?ff8QD3kxekQPvnFqM1PePwUhiW2x2Qu96MzjqeU/M76BHgJqZ7dqxARh2V?=
 =?iso-8859-1?Q?X5DPOJOE9G4HsVstSGEx7f0ZC+rnAGK5lcFsjcz353g7dhzWtje80EqRy1?=
 =?iso-8859-1?Q?WAV/uMScuQ5meUBExtmPirRyfC5k6WWvPmFbCEoq/Tb8CidmsaC2Y5I6R8?=
 =?iso-8859-1?Q?i1RBVvh/WPAu1hVhMxm8VJWht4NZudS1JKdSIBWW5qMvNRRJos29HOBevq?=
 =?iso-8859-1?Q?koSjf622q6Gw58vPZOAxQN7/f1bJU+y/qZbUJPrrkJMeYfohaiwfNCXxA1?=
 =?iso-8859-1?Q?anLSSz6i783sxGYBS9W2h5CA8Uo1aR1YrzakdSNtli/2q5SgvUyRVYBCCN?=
 =?iso-8859-1?Q?QlXDInmO32bkpG6iTjxpqydo3BEEIDH4Z4d8TvxS6qcWEQzkr0YBXEpSdg?=
 =?iso-8859-1?Q?6NaCe+RX18YN/8dSYqgSqpjlfsGYD2qBuaoyAw+cz9IYVVYu0uTGNKyvBr?=
 =?iso-8859-1?Q?zdYefje76L1XZg6xe18d9DVHn6mA+tytNDgtX6Ljy+3E0Tc+sxctqz4Inq?=
 =?iso-8859-1?Q?s66aljpyjEAttEobRX0H6TUX+aIGLTcBZqbGNQmfLaZDZIgJE2483ddkh1?=
 =?iso-8859-1?Q?ZcV/8WKeofdKGKKxd0glGv6K4csaNOpeUNoDPZnnQ7kGG93PabIfWl/vHC?=
 =?iso-8859-1?Q?SQU8nArO2Hc3eYQtWGAQUFHLpgumdIK+xzutxd8rXnFXeVbOGljfZAtqZ3?=
 =?iso-8859-1?Q?6HY7oIcFCPZpk4xh8tatPiWXWvjMi1Y1/YdVODX4ZHhF4TDSSL40scvC5E?=
 =?iso-8859-1?Q?NesVPUlKQAb5IKSc2PDlYhu7lLKK/GvLnaa5dD8O8LlYW/ULJWKCEU3Lxr?=
 =?iso-8859-1?Q?wBuKHZ3mgn428mWQIccIwIPaum/i9sk5OlJ+CGG/7P9UIbxJ0tzLGd3Qdl?=
 =?iso-8859-1?Q?4vOTcWCBAC10dJrraBqJTtw0EQ2uwyvWju1l+Hz22B/rOh4sDrB6RHZjQq?=
 =?iso-8859-1?Q?Q53u9tW/BGcTl6WMT8bxAYx3HT/9oHfhsJpLkeWKXlKMi7d1i3f11SX4dG?=
 =?iso-8859-1?Q?fCEkA2E0HR5CPZVt10S9lOAVCCwaI6fkbvBtfL6GAR6GZpD71Iyqem3tds?=
 =?iso-8859-1?Q?CUf3ZIRqwQeT7KaFzqExCZvwq7tvJLcNeb2sBYfzcvit8DHHQwtUMwnOCC?=
 =?iso-8859-1?Q?uYa+UaLKit6FJR3loJwItOrCsT/T2+ikIRWV34cfdrD19VM1oCboYnLHzn?=
 =?iso-8859-1?Q?Iz18C8h/WXWQeBWwel6PgaXpsWrbtva1dOs5Rjs1/GlMTjNA6jPwAiimk1?=
 =?iso-8859-1?Q?xa9y8Vt8u5Kdc8uvC2w6jta7oIvrgqqgQLzh8b0DDDCSiN8Ic60hvtnEh2?=
 =?iso-8859-1?Q?eURmjoum3fmMNn12kH/gdhHv+MRKvmp2/DskKzTWR5/vol2p7iT03gsAum?=
 =?iso-8859-1?Q?S4Kg6rrkToLUHplkiqyNF+4t/FTTzkm5SObvOFm5U6SDjrETRpGMXlgCTx?=
 =?iso-8859-1?Q?H9JQS0tNJoEWMuDGhSeTQGVFpimcrioQD+wv4Z1hUpGBrnRPO9nzlWic8D?=
 =?iso-8859-1?Q?GVxVat4Hz2wFNIjUSYd0KYMmip5BlWyM/zE0u7fqAmlA4gg9YpCgi9/7lA?=
 =?iso-8859-1?Q?hXoFbqYBZWI2YHAI8kzHaoRjdsGgWU+pujyMlFG9XB2kixuM7goTyw9m2y?=
 =?iso-8859-1?Q?kVKle805HdpYqHeRhsUFaUnHS2pnbP4/XdkusV7amPoxtcbS+lIVm008JV?=
 =?iso-8859-1?Q?ObBKsLfr6WwMJkRgTuWI3Amd+2V1IMc=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB10102.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b9266c6c-0ac1-43eb-0ef2-08df027bf451
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2026 07:39:11.2583
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kflpUuYwVmaoQC/g4ZjSnH/lXh4YZZz1IUavaZ96yl1wsDhNZ6re88jss2SL2a+tJ5bnTWC5mcqB2IRw3U465g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR03MB10717
X-purgate-ID: tlsNG-33051d/1787643555-778C54E9-7C830563/0/0
X-purgate-type: clean
X-purgate-size: 6393

Allow for removing devices from SMMUv3. arm_smmu_deassign_dev handles
most of the work by disabling ATS and zeroing STEs. Additionally, unset
the dt_device_is_protected flag and free no longer needed smmu_master.
Free iommu_fwspec for PCI devices only, for DT devices it is handled by
generic IOMMU layer.

Rework dt_device_set_protected to accept a boolean parameter, update
callsites.

Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
---

Tested on QEMU with SRIOV series[1] by repeatedly enabling/disabling
VFs.

[1]: https://patchew.org/Xen/cover.1772806036.git.mykyta._5Fpoturai@epam.co=
m/

V3->V4:
* s/u8/uint8_t/
* assert pcidevs_locked
* assert deassignment is only reachable by PCI
* fix build error with HAS_PCI=3Dn

V2->V3:
* free fwspec for pci devices
* remove testing note from commit message

V1->V2:
* check for phantom functions
* simplify pci/dt device split
* improve error handling
* don't try to free master for unprotected devices
* rework dt_device_set_protected
---
 xen/drivers/passthrough/arm/ipmmu-vmsa.c |  2 +-
 xen/drivers/passthrough/arm/smmu-v3.c    | 77 +++++++++++++++++++++++-
 xen/drivers/passthrough/arm/smmu.c       |  4 +-
 xen/include/xen/device_tree.h            |  5 +-
 4 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthr=
ough/arm/ipmmu-vmsa.c
index fa9ab9cb13..0648f9b407 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -1367,7 +1367,7 @@ static int ipmmu_add_device(u8 devfn, struct device *=
dev)
         }
=20
         /* Let Xen know that the master device is protected by an IOMMU. *=
/
-        dt_device_set_protected(dev_to_dt(dev));
+        dt_device_set_protected(dev_to_dt(dev), true);
     }
 #ifdef CONFIG_HAS_PCI
     if ( dev_is_pci(dev) )
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthroug=
h/arm/smmu-v3.c
index bf153227db..3578f36259 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -1493,6 +1493,80 @@ static int arm_smmu_assign_dev(struct domain *d, u8 =
devfn, struct device *dev,
 static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn,
 				 struct device *dev);
=20
+static int arm_smmu_remove_device(uint8_t devfn, struct device *dev)
+{
+	struct arm_smmu_master *master;
+	struct iommu_fwspec *fwspec;
+	struct domain *d =3D NULL;
+
+	fwspec =3D dev_iommu_fwspec_get(dev);
+	if ( !fwspec )
+		return -ENODEV;
+
+	master =3D dev_iommu_priv_get(dev);
+	if ( !master )
+		return -ENODEV;
+
+#ifdef CONFIG_HAS_PCI
+	if ( dev_is_pci(dev) )
+	{
+		struct pci_dev *pdev =3D dev_to_pci(dev);
+
+		/* Ignore calls for phantom functions */
+		if ( devfn !=3D pdev->devfn )
+			return 0;
+
+		ASSERT(pcidevs_locked());
+
+		d =3D pdev->domain;
+	}
+	else
+#endif
+	{
+		if ( !dt_device_is_protected(dev_to_dt(dev)) )
+		{
+			dev_err(dev, "Not added to SMMUv3\n");
+			return -ENODEV;
+		}
+
+		dt_device_set_protected(dev_to_dt(dev), false);
+		if ( master->domain && master->domain->d )
+			d =3D master->domain->d;
+	}
+
+	if ( d )
+	{
+		int ret;
+
+		/*
+		 * For DT devices, iommu_remove_dt_device() returns -EBUSY if the
+		 * device is still assigned, so d is always NULL on the DT path.
+		 */
+		ASSERT(dev_is_pci(dev));
+
+		ret =3D arm_smmu_deassign_dev(d, devfn, dev);
+		/* This should never fail because we already checked the domain */
+		ASSERT(!ret);
+	}
+
+	arm_smmu_disable_pasid(master);
+
+	dev_info(dev, "Removed master device (SMMUv3 %s StreamIds %u)\n",
+		 dev_name(fwspec->iommu_dev), fwspec->num_ids);
+
+	xfree(master);
+	dev_iommu_priv_set(dev, NULL);
+
+	/*
+	 * For DT devices the fwspec is freed by iommu subsystem, but for PCI
+	 * devices we need to free it here
+	 */
+	if ( IS_ENABLED(CONFIG_HAS_PCI) && dev_is_pci(dev) )
+	    iommu_fwspec_free(dev);
+
+	return 0;
+}
+
 static int arm_smmu_add_device(u8 devfn, struct device *dev)
 {
 	int i, ret;
@@ -1571,7 +1645,7 @@ static int arm_smmu_add_device(u8 devfn, struct devic=
e *dev)
 		}
=20
 		/* Let Xen know that the master device is protected by an IOMMU. */
-		dt_device_set_protected(dev_to_dt(dev));
+		dt_device_set_protected(dev_to_dt(dev), true);
 	}
=20
 	dev_info(dev, "Added master device (SMMUv3 %s StreamIds %u)\n",
@@ -2867,6 +2941,7 @@ static const struct iommu_ops arm_smmu_iommu_ops =3D =
{
 	.unmap_page		=3D arm_iommu_unmap_page,
 	.dt_xlate		=3D arm_smmu_dt_xlate,
 	.add_device		=3D arm_smmu_add_device,
+	.remove_device		=3D arm_smmu_remove_device,
 };
=20
 static __init int arm_smmu_dt_init(struct dt_device_node *dev,
diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/a=
rm/smmu.c
index d63c901551..4d2f71f152 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -825,7 +825,7 @@ static int arm_smmu_dt_add_device_legacy(struct arm_smm=
u_device *smmu,
 	if ( !dev_is_pci(dev) )
 	{
 		/* Xen: Let Xen know that the device is protected by an SMMU */
-		dt_device_set_protected(dev_node);
+		dt_device_set_protected(dev_node, true);
 	}
=20
 	for (i =3D 0; i < fwspec->num_ids; ++i) {
@@ -862,7 +862,7 @@ static int arm_smmu_dt_remove_device_legacy(struct arm_=
smmu_device *smmu,
=20
 	if ( !dev_is_pci(dev) )
 		/* Protected by dt_host_lock and dtdevs_lock as caller holds these locks=
. */
-		dev_node->is_protected =3D false;
+		dt_device_set_protected(dev_node, false);
=20
 	kfree(master);
 	return 0;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 06d7643622..76ae1e674a 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -300,9 +300,10 @@ static inline domid_t dt_device_used_by(const struct d=
t_device_node *device)
     return device->used_by;
 }
=20
-static inline void dt_device_set_protected(struct dt_device_node *device)
+static inline void dt_device_set_protected(struct dt_device_node *device,
+                                           bool protected)
 {
-    device->is_protected =3D true;
+    device->is_protected =3D protected;
 }
=20
 static inline bool dt_device_is_protected(const struct dt_device_node *dev=
ice)
--=20
2.55.0


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:40:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:40:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399096.1635296 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymhl-00056t-JB; Tue, 25 Aug 2026 08:40:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399096.1635296; Tue, 25 Aug 2026 08:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymhl-00056m-GD; Tue, 25 Aug 2026 08:40:25 +0000
Received: by outflank-mailman (input) for mailman id 1399096;
 Tue, 25 Aug 2026 08:40:24 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymhk-00056g-Fo
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:40:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymhi-00AYTC-8v
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:40:22 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d54f2-e002-0a2a0a5209dd-0a2a4503ecaa-18
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:40:22 +0200
Received: from [209.85.208.51] (helo=mail-ed1-f51.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d54f6-fae8-0a2a45030019-d155d033e1fd-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:40:22 +0200
Received: by mail-ed1-f51.google.com with SMTP id
 4fb4d7f45d1cf-6a157f90752so7487060a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:40:22 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a59e0228f1sm8831048a12.10.2026.08.25.01.40.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:40:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647222; x=1788252022; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=k5L4MZXgoTsz0rrLeS+BAK7kXsIkRduO4K4YCMEgEiU=;
        b=aUXcCfrgWrXI3L5L9QAgiD9XpyMiWIT9ix3qIzQceF7UKQlxgnntHKRoHA9T+zL1g3
         QlV6YjUiwytIpgabHpaE1S+WhIddHLMjUVufvVyndMEhaMNWdlwn6J5UOwfmMYImEs8h
         74d7sxfcX0idHEkbF/8nGPaxtOHaGHA+HduWjZRufhXflX+UpoLU/us4AnU48MFvQZJV
         gIVD1quCGCG1Ck5xV5mSrIQ9vmP34JuvHZ2fOE1wp6hmmc4ADTQS+b83g7lJluTAhkpm
         h8v4Le1P+akk1Hg13Bket0tcShqEs5Zu0xD3FnZUaHkofUQ+yWcKTxObVKgBvcze2gU0
         6P5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647222; x=1788252022;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=k5L4MZXgoTsz0rrLeS+BAK7kXsIkRduO4K4YCMEgEiU=;
        b=OKC5QmQGQBbkvEynl97z+UrYAl4DDgWX+qxcLUDqQAqgHA6VGkdgzbZveO754dt0LN
         65Qfs/SOJZz2leofA/9pUd9Lg0xnPcjGZFO8qRRbHFvjY7JrDqtrEaA0Assnf0VpO5d/
         Z+5ZzQnvIJP7QC/V7FEX90G29WuS/kxFEViaIHa7xxWpyzYR43e2IhiK4EbKe831uAcp
         brn2ZiSofmpxxMBZZ0rBr2yKx3spPGEbzvPnkXAwb+X427H4K+fo4PtdbbgMjQlg5nLq
         GFanUe4ygg6c+Lv9H0pnSQUqcZ4B1doNnJfCjVpACzYsVZ9BWxVcxZ+mhvUcjj7irN33
         tIKA==
X-Gm-Message-State: AFuF++lH58clwiZ/qRST4UrkUwQ+i1QeqRdNYldTjjqmSE2p+cxvvH3J
	Ckrnpvgf9nUq0OUhKrgDbDIdm99v+edycS6XDFCMoXU7h20wAyvvbd0ZqNdIxn6muJ3acyggS0a
	jAkIRSw==
X-Gm-Gg: AR+sD12htFUUr2MqS8cNhb34L9Jpiafhg+Ub2Q2pXqEU/kPrCiVQRFKNU5oRTM2UdoP
	LDAUN8wPo3l1v6lyUV8lE7NhGGlLVDS7EEF4hKWCvp8Yed7PhSs57Ea+kkZ5N4v7LBTsap92d1L
	x0gsjX2UGp04nJ3T3djVtzQ8l2Rj3oeByriJGsT0qOMZMwpYLAOPiFTAtGwzk9t0YX0sKWl/fv8
	Jn68jWLRxtkzQzi/7qic+MPuxChH64pExhr83kmQ5JF0WXqyuTZXB/hB8ubxQDdBuU/MtS5iKls
	PJXKnEwtTcjyFb7Iizd8NotLM/MMDCE5XthXezqF4Uq2E+u46cqWp+pi5dDhhlS7oi+1y8llp+Z
	OE3p8dNdAw4MUVMhH63xmB4Fl16wbowTwuwjzCiAgI0e+GfS3ANlDa5X/7dnTjCCtsyGgBGh5m4
	5Alhbpv4mIaXVIqpy6JN36vN2gQ1sn1dHQtQ/+/L2pC51HZcdI/6zUUxzXnuDu6eghJuG4Esl3I
	UFL2G5SjzTtmaTpBDkV/0zTd0dIzsLxhWI7uVampJ1aLdV/020k
X-Received: by 2002:a05:6402:50cc:b0:6a3:8525:b9da with SMTP id 4fb4d7f45d1cf-6a5c40b1a17mr5406572a12.4.1787647221665;
        Tue, 25 Aug 2026 01:40:21 -0700 (PDT)
Message-ID: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Date: Tue, 25 Aug 2026 10:40:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 0/6] build: split and unify linking of final image(s)
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787647222-75C804E9-91EBFDB3/0/0
X-purgate-type: clean
X-purgate-size: 592

The monolithic rules, largely but not entirely identical between ports,
were pretty ugly to fiddle with. Break them up, and use (largely) the
same rules for all ports (x86'es xen.efi being somewhat special, though).

The final two patches are related only in so far as they address
observations made while doing the conversion.

1: x86: split xen-syms/xen.efi linking rules
2: Arm: split xen-syms linking rule
3: RISC-V: split xen-syms linking rule
4: PPC: split xen-syms linking rule
5: build: move $(all-symbols-*)
6: RISC-V: place .sdata / .srodata / .riscv.attributes

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:41:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:41:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399102.1635305 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymia-0005aT-0j; Tue, 25 Aug 2026 08:41:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399102.1635305; Tue, 25 Aug 2026 08:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymiZ-0005aM-TM; Tue, 25 Aug 2026 08:41:15 +0000
Received: by outflank-mailman (input) for mailman id 1399102;
 Tue, 25 Aug 2026 08:41:15 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymiY-0005Zr-Rn
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:41:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymiY-00AYh7-8W
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:41:14 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d5522-e002-0a2a0a5209dd-0a2a450be558-26
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:41:14 +0200
Received: from [209.85.208.44] (helo=mail-ed1-f44.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d552a-b7e8-0a2a450b0019-d155d02ca471-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:41:14 +0200
Received: by mail-ed1-f44.google.com with SMTP id
 4fb4d7f45d1cf-6a3819e8be8so1206193a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:41:14 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5d82a283dsm200072a12.11.2026.08.25.01.41.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:41:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647274; x=1788252074; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=5lrpRDANObULG+2e3IFRktVcA5tLIZikgbLUJ0GCgH0=;
        b=F5A7deQ+cP7iIzXnfjWxmJGyfbhB+mHA21TueYn5nP++r003yhNygrVwmoKQtCl3aK
         sfeTZRURZ7tAXkh1TTOpHGCS00gsaglHqWt9mrZzW5rclJWFOEjosX0qmLHxxTWiKXho
         ASzuuC+7lD9ikao3XinWSAE695nQl0xCOa5Y6+wnAlr0PwKPJFgdueUUNQM3UXwGr7f1
         UaRqEDj0ptdUV6Rihnhr2cFaUN8jNDoIFsQrYmXcEBjrLhTdZqY+MqjGuPPKJFE42zqj
         oexQwFPb8r1/krNwkAiJZqueF6u1WKPsOxDw8QYZ90NzW4zr8Yzwk2PGvHVBPHXalqnh
         M8WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647274; x=1788252074;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=5lrpRDANObULG+2e3IFRktVcA5tLIZikgbLUJ0GCgH0=;
        b=qIbNNc2RPzwAzUNhZtx7C2BCoEDx3UK6q4Iga5g33I2B9MC7NLo8VxE/sqCYJQEpOe
         9hgREzef0V/QAOdL5/6hzzfCCF4AXOFOWHeS5CUNMiQkQwlmowE+lW52RsIUgt67WQV7
         Kpq+L9azWXbp/FMLopHztzldfcEmaaomQXrZYfS0jDFJ7KLrL9smxdkiNe7t6WQew8RL
         GrzSHd6yn3wlv2Vvs4nkooiDVzJdlyRJzT8QtCT78/zSKJNWdsiOWef05NXih+A+YaVH
         X1k5w0vOMrfG5zyZ+1COWtVDBdPs669YcVZGbPKHpQJwqJxOUOz2kTP0CiIOhxDZ2WIi
         uDvw==
X-Gm-Message-State: AFuF++kJ3EJ/GffZN5ESrVYsdq7Yn3PmoFq6AEmryS/bY/PRr59LT0yH
	3Rb76k6i9tCJy5EFqpmJP2/WOGsEXOU9Jj8aeG89fIjyO530SonHEfNGUZIqIFuyhq/5n0S38a8
	6xP+o3w==
X-Gm-Gg: AR+sD124LYvBnvh1fIviRTozAdZKqk6l+KkuITSRKc5RYWmFvzgTLKLzCBnVoWJ/MOh
	hVukeXsXuAGusKw/+SLgIm18Kewm/J9biaxttAMYzmdzvJMaZ7vKL2iG0B/DMgrC04XDYpfFMp/
	wojtgh1FcHGDGxW+4YllLslAGaLqYHEg7zJND8i/8RHqZZfgDslxnLlCotZjcFMr9oysgI3zTZn
	aZg9JIqwrr2tZkCW0us5a/gpdsdj3lYFaX9rNYbuBXxjXE8Lwvzpy+ninecqijuuBJVJnadu76p
	GIGdbOFEJR92cazrwOU0L3z8Ou8ZE3XpwGb/aUANW8eN+TUNFoz5SnvR25/EhscJqqXJh3+iYy8
	IVxHor+XkiRvipP7vQ4KL/gr9dY7UwHRwTomaTtqKxpBO0Kb8qINwUg5tMCCZoYe72bLdAlmt86
	PlPpsQLQ0KWj19IHphJVLtS+5TtR107DQEIkhKy30lkhyTdRF/c4m6XWw4a/x2wcLfO36sJhqE7
	tMfOtkomn4qm7jlXdlckyFDLfw0cmfn1n/5cQJczHRB0XxGE/jy
X-Received: by 2002:aa7:df09:0:b0:6a3:ebc7:60b0 with SMTP id 4fb4d7f45d1cf-6a5c3e82496mr3727661a12.3.1787647273774;
        Tue, 25 Aug 2026 01:41:13 -0700 (PDT)
Message-ID: <ccccc6f3-c16e-4988-9677-85d9ca6e30ce@suse.com>
Date: Tue, 25 Aug 2026 10:41:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 1/6] x86: split xen-syms/xen.efi linking rules
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787647274-ABAD09EA-2B4945A2/0/0
X-purgate-type: clean
X-purgate-size: 9827

Doing so, besides (hopefully) adding clarity (not the least by way of
using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations. For xen-syms move re-usable helper rules to a new
scripts/Makefile.link.

While doing so, re-order .map file creation (which can in principle fail)
and check-endbr.sh invocation ahead of putting in place the final image
(which is now the result of a simple rename).

Also drop --source-name= from the tools/symbols invocation which has
--empty passed, for being meaningless there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I'd like to keep the "beautification" part, i.e. transforming to
$(if_changed ...) machinery, separate.

The check-endbr.sh invocation doesn't fit neatly into this model. I was
considering to move it into $(TARGET)'s rule, but that's not very nice
either (both because it'd be odd [strictly speaking: wrong] for xen.efi,
and because it would reduce parallelism).

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -102,12 +102,6 @@ notes_phdrs = --notes
 endif
 endif
 
-syms-warn-dup-y := --warn-dup
-syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
-syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
-
-orphan-handling-$(call ld-option,--orphan-handling=warn) += --orphan-handling=warn
-
 $(TARGET): TMP = $(dot-target).elf32
 $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 	$(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) $(XEN_IMG_OFFSET)
@@ -119,31 +113,11 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort $(syms-warn-dup-y) \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	$(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o)
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(orphan-handling-y) $(dot-target).2.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
-ifeq ($(CONFIG_XEN_IBT),y)
-	$(SHELL) $(srctree)/tools/check-endbr.sh $@
-endif
+LAST_LINKING_PASS := 2
+
+final-image-check-$(CONFIG_XEN_IBT) = $(SHELL) $(srctree)/tools/check-endbr.sh $<
+
+include scripts/Makefile.link
 
 $(obj)/note.o: $(TARGET)-syms
 	$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $< $@.bin
@@ -191,51 +165,65 @@ note_file_option ?= $(note_file)
 
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds
+
+.$(TARGET).efi.%.o: .$(TARGET).efi.%.S FORCE
+	$(call if_changed,cc_o_S)
+
+.$(TARGET).efi.1r.S: .$(TARGET).efi.0 $(if $(relocs-dummy),.$(TARGET).efi.alt.0)
+.$(TARGET).efi.2r.S: .$(TARGET).efi.1 $(if $(relocs-dummy),.$(TARGET).efi.alt.1)
+
+.$(TARGET).efi.0r.o: $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
+	ln -sf $< $@
+
+.$(TARGET).efi.%r.S:
+	$(MKRELOC) $^ > $@
+
+.$(TARGET).efi.0s.S:
+	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+
+.$(TARGET).efi.1s.S: .$(TARGET).efi.0
+.$(TARGET).efi.2s.S: .$(TARGET).efi.1
+
+.$(TARGET).efi.%s.S:
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+ 	    --source-name=$(TARGET).efi.S \
+	  > $@
+
+# See above for why $(note_file) needs removing here.
+efi-objs = $(filter-out $(note_file),$(filter %.o,$^))
+
+.$(TARGET).efi.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \
+                  .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \
+	      --strip-debug $(note_file_option) -o $@
+
+.$(TARGET).efi.alt.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \
+                      .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds
+	$(LD) $(call EFI_LDFLAGS,$(ALT_BASE)) -T $(obj)/efi.lds $(efi-objs) \
+	      --strip-debug $(note_file_option) -o $@
+
+.$(TARGET).efi.2: $(objtree)/prelink.o $(obj)/efi/relocs-empty.o \
+                  .$(TARGET).efi.2r.o .$(TARGET).efi.2s.o $(note_file) \
+                  $(obj)/efi.lds
+	$(call compare-symbol-tables, .$(TARGET).efi.1r.o, .$(TARGET).efi.2r.o)
+	$(call compare-symbol-tables, .$(TARGET).efi.1s.o, .$(TARGET).efi.2s.o)
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \
+	      $(orphan-handling-y) $(note_file_option) -o $@
+
+$(TARGET).efi: .$(TARGET).efi.2
 ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "No debug info in $(@F)"
 endif
-	$(objtree)/tools/symbols $(all_symbols) --source-name=$(@F).S --empty \
-		> $(dot-target).0s.S
-	$(MAKE) $(build)=$(@D) .$(@F).0s.o
-	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-	          $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< $(relocs-dummy) \
-	                $(dot-target).0s.o $(note_file_option) --strip-debug \
-	                -o $(dot-target).$(base).0 &&) :
-	$(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).0) \
-		> $(dot-target).1r.S
-	$(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-                  --source-name=$(@F).S \
-		> $(dot-target).1s.S
-	$(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
-	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-	          $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $<  --strip-debug \
-	                $(dot-target).1r.o $(dot-target).1s.o $(note_file_option) \
-	                -o $(dot-target).$(base).1 &&) :
-	$(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).1) \
-		> $(dot-target).2r.S
-	$(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-                  --source-name=$(@F).S \
-		> $(dot-target).2s.S
-	$(MAKE) $(build)=$(@D) .$(@F).2r.o .$(@F).2s.o
-	$(call compare-symbol-tables, $(dot-target).1r.o, $(dot-target).2r.o)
-	$(call compare-symbol-tables, $(dot-target).1s.o, $(dot-target).2s.o)
-	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \
-	      $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \
-	      $(note_file_option) -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
+	  > $@.map
 ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $< $@.elf
 endif
+	$(final-image-check-y)
+	mv $< $@
 	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
-ifeq ($(CONFIG_XEN_IBT),y)
-	$(SHELL) $(srctree)/tools/check-endbr.sh $@
-endif
 else
 $(TARGET).efi: FORCE
 	rm -f $@
--- /dev/null
+++ b/xen/scripts/Makefile.link
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0
+# ==========================================================================
+# Helper rules for linking xen-syms
+# ==========================================================================
+
+syms-warn-dup-y := --warn-dup
+syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
+syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
+
+orphan-handling-$(call ld-option,--orphan-handling=warn) := --orphan-handling=warn
+
+final-image-check-y ?= true
+
+.$(TARGET)-syms.%.o: .$(TARGET)-syms.%.S FORCE
+	$(call if_changed,cc_o_S)
+
+.$(TARGET)-syms.0.S:
+	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+
+.$(TARGET)-syms.1.S: .$(TARGET)-syms.0
+.$(TARGET)-syms.2.S: .$(TARGET)-syms.1
+.$(TARGET)-syms.3.S: .$(TARGET)-syms.2
+
+.$(TARGET)-syms.%.S:
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
+	  > $@
+
+.$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
+	      $(build_id_linker) --strip-debug -o $@
+
+.$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \
+                                      .$(TARGET)-syms.$(LAST_LINKING_PASS).o \
+                                      $(obj)/xen.lds
+	$(call compare-symbol-tables, \
+	       .$(TARGET)-syms.$(shell expr $(LAST_LINKING_PASS) - 1).o, \
+	       .$(TARGET)-syms.$(LAST_LINKING_PASS).o)
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
+	      $(build_id_linker) $(orphan-handling-y) -o $@
+
+$(TARGET)-syms: .$(TARGET)-syms.$(LAST_LINKING_PASS)
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
+	  > $@.map
+	$(final-image-check-y)
+	mv $< $@
+	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:42:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:42:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399111.1635315 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymjU-000652-8u; Tue, 25 Aug 2026 08:42:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399111.1635315; Tue, 25 Aug 2026 08:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymjU-00064v-5M; Tue, 25 Aug 2026 08:42:12 +0000
Received: by outflank-mailman (input) for mailman id 1399111;
 Tue, 25 Aug 2026 08:42:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymjS-00064i-Fj
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:42:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymjR-0042i1-Sf
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:42:09 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d555a-e002-0a2a0a5209dd-0a2a4509cd9e-34
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:42:09 +0200
Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d5561-be1a-0a2a45090019-d155d030b9dc-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:42:09 +0200
Received: by mail-ed1-f48.google.com with SMTP id
 4fb4d7f45d1cf-6a082b3671fso7263860a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:42:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5d3d75550sm853569a12.3.2026.08.25.01.42.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:42:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647329; x=1788252129; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=F1cEm7rJzS56mS2/4sRHBA3+kz3xYZ64wP1egs+rTXc=;
        b=bk9JaJ2GWQVjNWd/fJzKuaTLxxjnJ6NdzUw+7bdAA1MPdlw7G6iAfSnVPyh3z2CFpI
         BD3V4p0CL6qNOWT/hcYg3/YIrSjP2iyIK0+d6kvx/vy98/NBCvK7vehuzEt0T+b1dtWt
         wea7RsLY7JB7wJD5mtsS9cyL3NhY3pttnzMW+hf490gel1gRik7oJyfs7sBQvnKzS8xJ
         +KZb6E6PdI6tHR7eK0gsOlbbWcJfMWMjwB8v0JiUqqICoINYOeowa7VWtMM9MpmHfCfQ
         5Y5bjqEAa2nXaopC911xX9kktpYCoeuKzp10vG4HuTkXX89ANNnhQG4LjqqV4hDGZwp8
         Da6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647329; x=1788252129;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=F1cEm7rJzS56mS2/4sRHBA3+kz3xYZ64wP1egs+rTXc=;
        b=oKR//tYp3tyxAeWc07HP4mBAjkckimfWrw3IP9wUYjdp2tHJzJXlkfphUdwa9xhIXC
         pr/Z9Hnnpx0fwFLnkBqaW6OEOmd5TB0CP8v7mS7d2UD8PVWSgIY8cR0vFQwdkgczY0SW
         Yn+4iTAohezDKyrJM/rKzjmROWRaZaGoIIj8jXCfYQI8rWOp4KrybWi6CGbh8CQu6+JW
         TNfwI06fVHv6KdNz+wdPHrS516kBYvbR9lzrOsnZ5l1GaJuiZO0HEUio1KCEi/5mgM52
         8p7fjTEm1Hf/Ntcuw3jzeIZWWC4VyvQ7G2oJ/4UweZw0Q4lGDNuoI8DK2jHlDJ5PO7iN
         8ZNQ==
X-Gm-Message-State: AFuF++l3noMJwrkc11arb5U1rxHqL3RtXTrIiuJq56kF6hH9omzQmh3u
	4mc1dZUVWjtVO7iH3WQx6erg5hxxVVS3tKVXnpJ5iRtX4eh6I38kBrLNgsuN3wSHaLnleOf7anw
	XsOHEmA==
X-Gm-Gg: AR+sD11won+aOYUebDp2dioqR69ow+wFx0lUL5ou24Ckx61iAzDNyCz9znwS7DkUVGJ
	+SuwuMZ2H8vSWCvgMOnuDTclOajhTe1Ff6ETfHYXtbF/mPR2BVvU2ox3DwHN8B5+l0VUS9Cq+ZI
	Qzu5JZOz8RFU0t+1lGk8ZxL0fLY5J5+YHlSIalY2UTSkgAnYTgvKvodf6ArXt87xNzer9pYjVHM
	tJLiIhLNJnnssgk5UMReuswgrpXvlDWyr0FTREfJyktJcU1iO4TUnzL8K4fFpD5TJf1LTk9FeFg
	h7d3esUVths9HHBr8hLKCCh3WCzl0llx1OUzg/3PxipXrzK/mPr+rHE8jBEo+vVCWkQ4YR+2Qe5
	61eERj6M0YVPZT+ujJQ4bqCIIuD2ltIOPYo/NrZHmNx71oqD/I0E+5KkIkz+y0/b4HiubgV/E7k
	+iKIvR2o40oG9GqcUJQpjKWq0LLM3IuFXzo0Flz6Bcu0/Zh1x6g8hG60JQo4fLQoXa784Zs+zlK
	zWsk/XVtz6K24csA2VWgiI8MtDX18AGEtTRzLn3MALV9PBlrVOK
X-Received: by 2002:a05:6402:a214:10b0:6a5:d694:6e9 with SMTP id 4fb4d7f45d1cf-6a5d6940777mr645550a12.2.1787647329386;
        Tue, 25 Aug 2026 01:42:09 -0700 (PDT)
Message-ID: <0294ccd6-6a22-4cab-9654-56c18bbe37f8@suse.com>
Date: Tue, 25 Aug 2026 10:42:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 2/6] Arm: split xen-syms linking rule
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787647329-FD469034-AAF50E60/0/0
X-purgate-type: clean
X-purgate-size: 3812

Doing so, besides (hopefully) adding clarity (not the least by way of
[re-]using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations.

By re-using the generic rules introduced when the respective x86 rule was
split,
- the .map file now isn't created after the final binary anymore,
- --strip-debug is passed to $(LD) during early linking passes (for
  consistency the option is also explicitly added to the optional linking
  pass rule),
- CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
  now properly respected.
Orphan section checking, otoh, is getting suppressed for now, until the
about a dozen warnings which would result have been taken care of.

While the 4th linking step continues to be avoided when possible, a
redundant invocation of $(NM) and tools/symbols (plus the assembling of
the resulting .S file) is hopefully deemed acceptable.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
As for the x86 patch, I'd like to keep the "beautification" part, i.e.
transforming to $(if_changed ...) machinery, separate.

--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -84,40 +84,12 @@ ifeq ($(CONFIG_ARM_64),y)
 	ln -sf $(@F) $@.efi
 endif
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
-	then \
-		set -e; \
-		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-		    $(dot-target).2.o -o $(dot-target).2; \
-		$(NM) -pa --format=sysv $(dot-target).2 \
-			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-			> $(dot-target).3.S; \
-		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
-		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
-	else \
-		ln -sf $(dot-target).2.o $(dot-target).3.o; \
-	fi
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).3.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+LAST_LINKING_PASS := 3
+
+include scripts/Makefile.link
+
+# Suppress orphan section checking for the time being.
+orphan-handling-y :=
 
 .PHONY: include
 include:
--- a/xen/scripts/Makefile.link
+++ b/xen/scripts/Makefile.link
@@ -31,6 +31,19 @@ final-image-check-y ?= true
 	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
 	      $(build_id_linker) --strip-debug -o $@
 
+ifneq ($(LAST_LINKING_PASS),2)
+
+.$(TARGET)-syms.2: $(objtree)/prelink.o .$(TARGET)-syms.2.o $(obj)/xen.lds
+	if ! { $(call compare-symbol-tables, .$(TARGET)-syms.1.o, .$(TARGET)-syms.2.o) >/dev/null; }; \
+	then \
+		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
+		      $(build_id_linker) --strip-debug -o $@; \
+	else \
+		ln -sf .$(TARGET)-syms.1 $@; \
+	fi
+
+endif
+
 .$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \
                                       .$(TARGET)-syms.$(LAST_LINKING_PASS).o \
                                       $(obj)/xen.lds



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:42:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:42:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399116.1635322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymk4-0006WV-Ey; Tue, 25 Aug 2026 08:42:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399116.1635322; Tue, 25 Aug 2026 08:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymk4-0006WO-CO; Tue, 25 Aug 2026 08:42:48 +0000
Received: by outflank-mailman (input) for mailman id 1399116;
 Tue, 25 Aug 2026 08:42:46 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymk2-0006W6-EJ
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:42:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymk1-0042qT-RK
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:42:45 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d5582-e002-0a2a0a5209dd-0a2a450bce72-20
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:42:45 +0200
Received: from [209.85.208.47] (helo=mail-ed1-f47.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d5585-b7e8-0a2a450b0019-d155d02faca4-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:42:45 +0200
Received: by mail-ed1-f47.google.com with SMTP id
 4fb4d7f45d1cf-6a10d02ff43so8741943a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:42:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a59e02a8fbsm18170188a12.13.2026.08.25.01.42.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:42:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647365; x=1788252165; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=JoSzWl9u/xDhO1ZqChlyScExhg2WyeKTzD6iriK6Voc=;
        b=J1nXtJffqqp0xVvaSg5M45MRqo7cCbuYtDYf/XI91gYJe5hkuYQ3EBwghQNZ3jiGzt
         OV1/nSMjEJurIaYpaekkdizaCZMaSCOzTYT4s64k7Y0HHSmmg1OK97HjFE5V5yqWiBHz
         lF5TUeFUF32kmqhTuBOgwvlBcH8vZt8g3R0VZ3jB7H1aeOIt/0UIasnPqmosNYnKv2Wd
         NtJ9iMD2hk5hGHQFFtPnfJuHZXApwFFJinaASemWMfvk76D/1DQ8dFIl0qN+BOvJDG/H
         Qgfzm9FAQZCtOeH94q+y/0i+0BBorxHNGrEsIcK3kHId/DQtO0V+gkSS0FUrG9mgLvpM
         +yUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647365; x=1788252165;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=JoSzWl9u/xDhO1ZqChlyScExhg2WyeKTzD6iriK6Voc=;
        b=cAclz8jaLQFQuMNz+IjHiYbd1j4Aicez9luV58CGJi4dXtMg4RoBPhLtTeXiFDRIeK
         GS1GeCpTcbXM8Jm2zP9N5+HztUAX7OTVF2myHHZSCxu4L7aCtbmR7VSvHzVxXFhsJDa1
         0UJthtu5/4AObBVRxHvQrQQjEfkog0GXuT01wn8/1jsFAlPyh32JzFwlPPReUT08s+hu
         SQPf4QUcsKfWx1dZlugtJ2rPpJ6D4ofWsuX4GWUhsNyYEmYrp50zpixKGhFGf1WBGWRu
         2Ehlf1rpBmQQLVuLYdP+zguRAR6hKKbJ/bIGE12gfOzfGPEg+Mi2812F6L3zDPW9iM86
         5JgA==
X-Gm-Message-State: AFuF++l5KLyxHHEfFv9q/u1jbC1ACaG9oNZOXwzIAiQ/0OiQWI6ug8tU
	IjSseu7fEHdGWEEdLj6m0YFRFoRNIiKoG6uBVm0LYrH8RntGaY9O5iou1wTP19L/M1LfGqjWsd3
	Kvf5gLw==
X-Gm-Gg: AR+sD12n/rqoJByCq1u7NvTvhP7KuBNaknTzxzL9ZOilpakoyQRBBByNBDiRPL07/dL
	91cO1vDtsIVcGIsQoIgVMQ7GPA8kpM+f5ClpeyeTquOjFwNrg85A9aWKGoD/3ka7Cs+zzaaXigJ
	jOwUKUG6lz7lui/F3mSjAH/ogGNL4419SQBQKLTrZGqKWBpUmj93iWkP+/kgEZZy6pNmPjw4ljR
	EEZyVq1EgsqS/wMwAVyx2xaTD/1VJRm15i3/fYq47vu0lzlpV5gftW9I6W3ct72I/RcZ6mcWDPc
	dEi+Z24YnWUnjZzyQGHwYQJr8yHscSX7as49hJFJlIixi1Vm2YUX9/XjIFcVb0T5LnKKqTNjJ37
	5XduCOVA0mv39SQLQNNZojrysSVVlD1N3lQ1TfL+5zdMzAc5Ahve65z+AWgex3x/aei+ry3Jx4x
	7YREt7H32t3VPeXHfTPccfKEZb1UgElYkhL+/Bmie/H1Q70IknKXxJiU4CcC8jtrGvbwyxIitCG
	Q6BPdsxQ2FJH5lTzi/W2Z0FQVIHERY8X14poqvztOx8f3yCxzwFe8c3uNKYSiA=
X-Received: by 2002:a05:6402:428e:b0:6a1:fd14:8835 with SMTP id 4fb4d7f45d1cf-6a42eea5ed7mr36418894a12.0.1787647365372;
        Tue, 25 Aug 2026 01:42:45 -0700 (PDT)
Message-ID: <f5ee642c-967f-444f-885a-fbbae6445020@suse.com>
Date: Tue, 25 Aug 2026 10:42:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 3/6] RISC-V: split xen-syms linking rule
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787647365-AB6D29EA-35DFF45C/0/0
X-purgate-type: clean
X-purgate-size: 2927

Doing so, besides (hopefully) adding clarity (not the least by way of
[re-]using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations.

By re-using the generic rules introduced when the respective x86 rule was
split,
- the .map file now isn't created after the final binary anymore,
- --strip-debug is passed to $(LD) during early linking passes (for
  consistency the option is also explicitly added to the optional linking
  pass rule),
- CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
  now properly respected.
Orphan section checking, otoh, is getting suppressed for now, until the
about a dozen warnings which would result have been taken care of.

While the 4th linking step continues to be avoided when possible, a
redundant invocation of $(NM) and tools/symbols (plus the assembling of
the resulting .S file) is hopefully deemed acceptable.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -31,40 +31,12 @@ obj-y += vtimer.o
 $(TARGET): $(TARGET)-syms
 	$(OBJCOPY) -O binary -S $< $@
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
-	then \
-		set -e; \
-		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-		    $(dot-target).2.o -o $(dot-target).2; \
-		$(NM) -pa --format=sysv $(dot-target).2 \
-			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-			> $(dot-target).3.S; \
-		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
-		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
-	else \
-		ln -sf $(dot-target).2.o $(dot-target).3.o; \
-	fi
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).3.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+LAST_LINKING_PASS := 3
+
+include scripts/Makefile.link
+
+# Suppress orphan section checking for the time being.
+orphan-handling-y :=
 
 $(obj)/xen.lds: $(src)/xen.lds.S FORCE
 	$(call if_changed_dep,cpp_lds_S)



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:43:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:43:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399125.1635332 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymkp-00075C-RS; Tue, 25 Aug 2026 08:43:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399125.1635332; Tue, 25 Aug 2026 08:43:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymkp-000755-NS; Tue, 25 Aug 2026 08:43:35 +0000
Received: by outflank-mailman (input) for mailman id 1399125;
 Tue, 25 Aug 2026 08:43:34 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymko-00074l-Ct
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:43:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymkn-004RbY-Pf
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:43:33 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d55a9-8faa-0a2a0a5109dd-0a2a450a9400-40
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:43:33 +0200
Received: from [209.85.218.49] (helo=mail-ej1-f49.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d55b5-f2d2-0a2a450a0019-d155da31f0cb-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:43:33 +0200
Received: by mail-ej1-f49.google.com with SMTP id
 a640c23a62f3a-c214e625259so673609466b.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:43:33 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c249606b4f1sm1688249766b.3.2026.08.25.01.43.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:43:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647413; x=1788252213; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=z+XcKNuFMvLMilDPsUpM4PMWFJxDvjvamUF6fgbTnzs=;
        b=NnuT/sdZGQqeZVkOFh1LVk+2qFF+7WpAEqRpvunwTDnZH9toFkYcGQNSV985cvqyoE
         wL/wVGLnrK7WQHkqJLbo0ARP1wus/naYgBeg5PAZ7oUiUm4KPhX09+hybdIMHClB3YGr
         D6i3YaKt3DXcm+qaJbyk9/zwaIpj8kj/nilIgR1a0yHAzapHnPtF9wMVJc0pkE81FDgf
         rdutB6sIl3I6RastngTJ6tlmIDOeSfkt9qZKaDQb70gfZUZL/NUwVNeiBpUWwQ9LU6sq
         +DM1OArFJFGjrDaQLcmffxoSPHLggKcOZ+HSZu19kHeEWB+wBMyM1xVjXDvSY56z+2+s
         6Ssg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647413; x=1788252213;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=z+XcKNuFMvLMilDPsUpM4PMWFJxDvjvamUF6fgbTnzs=;
        b=mFm25WG2lxrrhJ9JgUy0nFfv3nZCr5lzZEPHUO7P7Qs4DttUtbc2hZdV7QVDH5u2BU
         sOiDZzq8w/sv8F4pOGVaygCHpcBZK7jGXtuKX3L5qYeTMNEvHiEa+H5But3p8iASUYHK
         tmDruZKy4Oq0Xfo2eceJOOSMdFVPVivnbdBv1G/ot4TvOolvbjul6mm+PPQLNQ842ETX
         dUSJ75wNxc1NDXkgW/T54DHiU31T8unuUhEz5XxnyJhQKdkv8Q73JzQjUmpS//TfPBvP
         Zk8r82Z73skamUnvoHXBNVUdoFgfFGkdonwoIYPqub3+NSG07X263K/ljqp5ePvArD8Z
         /gsQ==
X-Gm-Message-State: AFuF++kdWRzTiyIZ0T+hL7wmBvgDJ0JPznaQO3g/De07pEEX8HQclLzj
	lKIKfoOY7XXSjH26Vg1mYUFeQJqakNt+u+z+iOn8q4J9E/t68lGXjg/yO8nkvVgA4Jznm7rtlHh
	JeYXUMQ==
X-Gm-Gg: AR+sD12u2D3Yvg9p9t+gOxMnJfZvi17qoSXxzxN3nowY8k2wPg6VVs5iRPWO4qIEVFR
	LUYIhhzT73+N5Xc4G0BuyyhCGOxjesN7ViTpcEZv/fpI4Z8e5sUnZdYyIKN+ACzlXMMzt58hjNq
	vPNcMjmy2g3dsmszZf/WMj21siyQL+bKzzrdYWF4K+qObq+Ua86gNDKnHrUb9btElt8AWVfGKTC
	+N9LYrux5sEmww8eD6WJkqOpJBnNGp+m3wl5W3mbNsmFDD4BfTRH91Vc1OrYDeTo7w0ioq9NaMq
	09w2N6MkWizPm92F9MF5ZVEAppU34mOGdvb76hBQiwJfctZARJkLn3DpWOPokKv9otpG/gwwc5C
	N5p9TpCkasc0qlp+UUfDfSB9hA93hE93RznVVJzRW0K/udpj2ent72GLdFKD4wdlI9t+yhu6+hQ
	2pZOpk74vOyqLJmy7WZrYQxitkj/saE2XT1cFth5vi5yzvpw8mM2c5mnX9hWj+dk2BilalRtNSg
	WRHlcwwUwOAylB5+Q2ydEdo1RhPaw7NpcxSE+XbXmDAlvaoKhc8
X-Received: by 2002:a17:907:9607:b0:c19:6d4a:425b with SMTP id a640c23a62f3a-c24e5b55311mr540507366b.18.1787647413233;
        Tue, 25 Aug 2026 01:43:33 -0700 (PDT)
Message-ID: <69413b7a-cf81-49c2-a975-f528412d5062@suse.com>
Date: Tue, 25 Aug 2026 10:43:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 4/6] PPC: split xen-syms linking rule
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Timothy Pearson <tpearson@raptorengineering.com>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787647413-58DC7CFC-85F7E7E9/0/0
X-purgate-type: clean
X-purgate-size: 2219

Doing so, besides (hopefully) adding clarity (not the least by way of
[re-]using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations.

By re-using the generic rules introduced when the respective x86 rule was
split,
- the .map file now isn't created after the final binary anymore,
- --strip-debug is passed to $(LD) during early linking passes (for
  consistency the option is also explicitly added to the optional linking
  pass rule),
- CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
  now properly respected.
Orphan section checking, otoh, is getting suppressed for now, until the
about a dozen warnings which would result have been taken care of.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ppc/Makefile
+++ b/xen/arch/ppc/Makefile
@@ -11,28 +11,12 @@ obj-y += tlb-radix.o
 $(TARGET): $(TARGET)-syms
 	cp -f $< $@
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	$(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o)
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).2.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+LAST_LINKING_PASS := 2
+
+include scripts/Makefile.link
+
+# Suppress orphan section checking for the time being.
+orphan-handling-y :=
 
 $(obj)/xen.lds: $(src)/xen.lds.S FORCE
 	$(call if_changed_dep,cpp_lds_S)



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:44:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399131.1635340 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymlQ-0007XV-1u; Tue, 25 Aug 2026 08:44:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399131.1635340; Tue, 25 Aug 2026 08:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymlP-0007XO-V1; Tue, 25 Aug 2026 08:44:11 +0000
Received: by outflank-mailman (input) for mailman id 1399131;
 Tue, 25 Aug 2026 08:44:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymlO-0007X8-IJ
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:44:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymlN-004RqC-V4
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:44:09 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d55b9-e002-0a2a0a5209dd-0a2a45058308-48
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:44:09 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d55d9-4cb1-0a2a45050019-d155da36b01e-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:44:09 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c16794450aeso655651566b.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:44:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c249606a8edsm1644205166b.6.2026.08.25.01.44.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:44:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647449; x=1788252249; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=FTgctcTu5XvkaEOJLrKjmgwxIb3vR/Qle8yZ7WKT+e4=;
        b=GBH6AC1jr9SK7HF1WM8zcrX6Zv2oNW+hnyNJ0A1vf7NJw7/G+MFOPJPHmnLUux7/XM
         168XXkck/E5GuNOmUNytqEZUF+F64QdLyz0dF/u2DF7DyOU1io5UdlXMYePAtJsXc5Gj
         NZq2Gt0NKWDuZmyXFTIJOMdIMu9n+RHzmHg0mp76Ct4o/435bY9gBeJeo6eEGRqKExyw
         OMiBXtv7Db7q5+ibnXxrdvCpVc8Jyx+BWLonnBTsFopP8Xhe8J3r1Uqo9UBD/qgjbSVV
         BD0eTxqwIaSmEI99OmZdkOcHYD3d6jpdSynLYPszHRnqGOnUGicHj4uhwYsvD9uX182e
         2GEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647449; x=1788252249;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=FTgctcTu5XvkaEOJLrKjmgwxIb3vR/Qle8yZ7WKT+e4=;
        b=WEd85EFz9P1Z0hV7OZI1tRYECebIZlpoCuUXCcG/Eu2qTF8JwrNX/6nJRZGPDejBol
         epaneHFQd4yB8pQlEZU41nzstnqo3j3/aJ6t3MJh1li+cBMDHlO5gBR1NTuDsgx9vqES
         7BmzrE0HBMfh/eqoyi+gdM7ZaFvUJzqENWVblUrP8bamnvtpj9lx9a24Q7yQiMdfB2yv
         BEhXRR42upAnNFnV1ra0mnw6hO/0vXVOkRk6xxtfkPdGVZ4Nm6/T6iFmysaAI4UJrfE5
         qe4BYZRSDS436k5a+1e4IHJRXOcDPI/MMr9nv6huHsBYx4R98oOwS88GqVzrjC3q8MEs
         2nRA==
X-Gm-Message-State: AFuF++nCkrSKoduHiRa93opakOLzVd2vVKoq73g8Ruw1u93Bl2BEl2lc
	akDmsAl/s4GQJnpsy8MRvfDWSYa1OLxxlOGmdYVSUz1ltN6VXLZNDXE8Yvzz0xrPx0lOoH1BtQ6
	9gb9e6A==
X-Gm-Gg: AR+sD13wNr0dY6CZSwqvhbjX87ZSae9kCJnQwv67oMytJWDlZPzzGYaOr76J+WaJaqx
	KdX7s8ThgTZZR21pXdqyksrTWBIsdWzzvmJVOnL/sXv1S/igmL1y7I/UcVHgILFqrX/mtg8N/tB
	mOUZOyS6veYfE+n761cUiB3652DhqEYiW812aQgtUDCn1jbT2ivvBRHtAMl58WUd3HA8gv3Gion
	Yq9lQzkjGVErkyNYXQbN2BW7/JCUFKmSczDO2Uk+U25ni5a59zAJg7NUG7B38ZFebjARU127QWk
	XfartZEZECz3gRH0hpWByLdGxQsH0Ldc3CUuUue7EsBcu6sUlSZ6E+1fLvUL4EoUqW/MSM+7211
	OgoB72R/Asd7WOVef3p0U3LyxW2PXkHnTcdVgkwntl9/5yjEx8/vtYW7/tRzjjgiySPF6aWQ8gh
	xf8XiVuj9GV23jCgAiZdhbLTls1UYVp9fgiARAjqe7mEjJMcoGfyA8tWC2mCmIrdWhILrp/v+PC
	Wo6Ti4gH71OXm+I8SG8ds/WnAIo/T5War71j1WsQln/qDaCESUKcCIr9b0lp7I=
X-Received: by 2002:a17:906:f049:b0:c16:126b:98b4 with SMTP id a640c23a62f3a-c246a2ef584mr3520987366b.3.1787647449449;
        Tue, 25 Aug 2026 01:44:09 -0700 (PDT)
Message-ID: <09e481bc-b2ca-4480-93ad-1a45c7d45073@suse.com>
Date: Tue, 25 Aug 2026 10:44:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 5/6] build: move $(all-symbols-*)
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787647449-247132A1-1681B5FC/0/0
X-purgate-type: clean
X-purgate-size: 2850

With the final linking logic now consolidated in scripts/Makefile.link,
$(all-symbols-*) also doesn't need setting anymore in (and passing down
from) the top level Makefile, 

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -465,10 +465,6 @@ ALL_OBJS-$(CONFIG_CRYPTO) += crypto/buil
 ARCH_LIBS-y               :=
 ALL_LIBS-y                := lib/lib.a
 
-all-symbols-y :=
-all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols
-all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name
-
 include $(srctree)/arch/$(SRCARCH)/arch.mk
 
 # define new variables to avoid the ones defined in Config.mk
@@ -622,8 +618,7 @@ $(TARGET): outputmakefile asm-generic FO
 	$(Q)$(MAKE) $(build)=arch/$(SRCARCH) include
 	$(Q)$(MAKE) $(build)=. arch/$(SRCARCH)/include/asm/asm-offsets.h
 	$(Q)$(MAKE) $(build)=. MKRELOC=$(MKRELOC) 'ALL_OBJS=$(ALL_OBJS-y)' \
-	            'ALL_LIBS=$(ARCH_LIBS-y) $(ALL_LIBS-y)' \
-	            'all_symbols=$(all-symbols-y)' $@
+	            'ALL_LIBS=$(ARCH_LIBS-y) $(ALL_LIBS-y)' $@
 
 SUBDIRS = xsm arch common crypto drivers lib test
 define all_sources
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -179,14 +179,14 @@ ifeq ($(XEN_BUILD_PE),y)
 	$(MKRELOC) $^ > $@
 
 .$(TARGET).efi.0s.S:
-	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+	$(objtree)/tools/symbols $(all-symbols-y) --empty > $@
 
 .$(TARGET).efi.1s.S: .$(TARGET).efi.0
 .$(TARGET).efi.2s.S: .$(TARGET).efi.1
 
 .$(TARGET).efi.%s.S:
 	$(NM) -pa --format=sysv $< \
-	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+	  | $(objtree)/tools/symbols $(all-symbols-y) --sysv --sort \
  	    --source-name=$(TARGET).efi.S \
 	  > $@
 
--- a/xen/scripts/Makefile.link
+++ b/xen/scripts/Makefile.link
@@ -3,6 +3,10 @@
 # Helper rules for linking xen-syms
 # ==========================================================================
 
+all-symbols-y :=
+all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols
+all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name
+
 syms-warn-dup-y := --warn-dup
 syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
 syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
@@ -15,7 +19,7 @@ final-image-check-y ?= true
 	$(call if_changed,cc_o_S)
 
 .$(TARGET)-syms.0.S:
-	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+	$(objtree)/tools/symbols $(all-symbols-y) --empty > $@
 
 .$(TARGET)-syms.1.S: .$(TARGET)-syms.0
 .$(TARGET)-syms.2.S: .$(TARGET)-syms.1
@@ -23,7 +27,7 @@ final-image-check-y ?= true
 
 .$(TARGET)-syms.%.S:
 	$(NM) -pa --format=sysv $< \
-	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+	  | $(objtree)/tools/symbols $(all-symbols-y) --sysv --sort \
 	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
 	  > $@
 



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 08:45:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 08:45:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399137.1635349 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymmC-00083O-9I; Tue, 25 Aug 2026 08:45:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399137.1635349; Tue, 25 Aug 2026 08:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wymmC-00083H-6b; Tue, 25 Aug 2026 08:45:00 +0000
Received: by outflank-mailman (input) for mailman id 1399137;
 Tue, 25 Aug 2026 08:44:59 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wymmB-000831-41
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 08:44:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wymmA-00AZJQ-Gs
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 10:44:58 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d55fd-2eae-0a2a0a5409dd-0a2a45079e92-40
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:44:58 +0200
Received: from [209.85.208.45] (helo=mail-ed1-f45.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d560a-b4ea-0a2a45070019-d155d02dd4b0-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 10:44:58 +0200
Received: by mail-ed1-f45.google.com with SMTP id
 4fb4d7f45d1cf-6a144c8eea2so8105011a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 01:44:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a59e0126edsm14169067a12.7.2026.08.25.01.44.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 01:44:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787647498; x=1788252298; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=PVJaUDGprniCHOdS15F0kmtFEIvAxLzg9FMvZh5Wvbg=;
        b=eQVZz19qPywpzlSOp1/6UNuvjsSGVaJVQSC5nlS3Mr7ucnbIeZhao3hA1j1WnLvp/q
         cn6cY1lLRguJZS9zaG+x/MpcMMROFlpCcq3JWbWxktqPSSk6I/h4j0pVcujQ2CMdv42B
         5Tsb1NnSR/jmN9hpqZwjK572G5hIH5gGja04gjcNL77Rc6Xjn/LadErRF9pVNCzuGLCF
         yhrD65A+ualLjLRtMw/V/C363fAu3a89oMMDPGyWfI017GJ1PctCViUohk1ImHTwhy4Y
         soFBdy6ss42zwMMS0x1KuzgvAk6ygi/kMQe2XLLE6Y6/2LnC6gsJuAjoTbtiftjqD/y9
         biiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787647498; x=1788252298;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=PVJaUDGprniCHOdS15F0kmtFEIvAxLzg9FMvZh5Wvbg=;
        b=BtXhF6f4QweUEuQgWhLC4fsr53ElR7eo+CKdq/rh1Kf48Tc2qm2f5Ymzms9v4ZNGe9
         JWAoR/7TQvFdVw5nxhYQqOAY7p15IbCwEMUjDol51FXHgn/tEsLsuqWAF03L52e/Kpsr
         oOUUOnSEx8HmjYO4d5er9R5OdYwbYS3g8jW6RVQAVOJQiD6rwpUXni+1IsVgnWyAtjZK
         PkuJ7HnbqvMdFfbM+T9L2FPqaBDs1INmvwFg3gj+ZE854VHGPVn9Mdzo8qr6LKqgtRWA
         CoFzGGvBLIC4q8mcoceIPj0Qgsg6VZxatUEGGEtnYgrZ1Bqk0E9O5cgODr7uRlDQiC5c
         NSGQ==
X-Gm-Message-State: AFuF++l45sqTlJndtvRtkz9ajfnLCJskj0tsAluBl+xUI2IgKPMf5L+s
	kYJ9+KLKQXwbdcQU5GEd0GMESWzLsGRVuPAdjjCSL7+leespgPaC8epICknf1o17/W9iTv7J300
	+8QawUA==
X-Gm-Gg: AR+sD11Rks5/3spY9TkNeVInOvNaObvv98j2CmqJXOQAqG06u0KOf9cCkFqwgbt1VHN
	+jFL7IatecU3NPcVDf3PHwjhfPlclhJqDmEkEH4oCLY88Tl+u9iDCBanHqu3PCU+m1sOmnK6n45
	ridDgJg+KoWbgHA6niscm2pxDw+WfD/vI172c/oVdX3CFn/MoQjEX9AS7FdzUSsp4KgIKY2jGCL
	QHKq+DnjgddTOyX4kNLsshbYOoRqpuxP9EQfup2zBoTxmwHep4pC8YU2zvOE76H2YEXivvzz9+c
	aFoHxk6s+s2fXZhndHyTIAgl3EHG6c0NRaIvSJxsAQX3vO3o0zGGhFS9nacYf5X3z0Qio//OcTU
	uu5r5GOztci0ZEAuaZgAyU/J4BccV/Jqcp5Atsk8e0b1rMIyuBT+8JoK2Bwk3U6oG1sez3QiMtp
	E0BPHPleVGVb83Rwg4sKI1AjJGy6UGZWaVFFTB0nlr/YG/OO8cTtcX7NVyv+/IbVMFFEZMA5K1Q
	tgRD7BZALNC72O070JXOubgGD8iK3RBYh4f8t4Jw8GbpF2T8NZY
X-Received: by 2002:a05:6402:a0cd:b0:6a1:babc:5b9e with SMTP id 4fb4d7f45d1cf-6a582b0b815mr25053651a12.5.1787647498006;
        Tue, 25 Aug 2026 01:44:58 -0700 (PDT)
Message-ID: <2c162d3b-a038-44f6-85db-6481e1f36138@suse.com>
Date: Tue, 25 Aug 2026 10:44:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 6/6] RISC-V: place .sdata / .srodata / .riscv.attributes
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787647498-374D3AE4-02A0BF6D/0/0
X-purgate-type: clean
X-purgate-size: 1611

Of the short-data sections, only .sbss is presently mentioned in the
linker script. Place them next to, but ahead of their "normal" data
sections.

.riscv.attributes can go towards the tail of the image, next to (ahead of)
debug info.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Seeing where .sbss lives, does positioning really not matter at all? I
would have expected that short-data sections want to live close together,
and specifically close to .text / .init.text (seeing that such data is
accessed using AUIPC). I'm puzzled that the psABI doesn't even mention
them, hence leaving it open how exactly they are to be used.

What remains to eliminate orphan section warnings is the placement of
.note.GNU-stack (which perhaps wants dealing with on all of Arm, PPC, and
RISC-V together, ideally unifying with x86) and (odd at the first glance,
but dealt with on x86 as well, i.e. may again want unifying) that of a
number of .rela.* sections.

--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -44,6 +44,8 @@ SECTIONS
 
         BUGFRAMES
 
+        *(.srodata)
+        *(.srodata.*)
         *(.rodata)
         *(.rodata.*)
         VPCI_ARRAY
@@ -92,6 +94,7 @@ SECTIONS
         SCHEDULER_ARRAY
         HYPFS_PARAM
 
+        *(.sdata .sdata.*)
         *(.data .data.*)
         CONSTRUCTORS
     } :text
@@ -162,6 +165,8 @@ SECTIONS
     /* Section for the device tree blob (if any). */
     .dtb : { *(.dtb) } :text
 
+    .riscv.attributes : { *(.riscv.attributes) } :text
+
     DWARF2_DEBUG_SECTIONS
 
     DISCARD_SECTIONS



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 09:21:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 09:21:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399154.1635360 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wynLX-0005Qt-3K; Tue, 25 Aug 2026 09:21:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399154.1635360; Tue, 25 Aug 2026 09:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wynLW-0005Qm-UQ; Tue, 25 Aug 2026 09:21:30 +0000
Received: by outflank-mailman (input) for mailman id 1399154;
 Tue, 25 Aug 2026 09:21:29 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wynLV-0005Qg-Jq
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 09:21:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wynLU-001uUQ-2D
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 11:21:28 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d5e8d-bab6-0a2a0a5309dd-0a2a450ad572-34
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 11:21:27 +0200
Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d5e97-f2d2-0a2a450a0019-d155d029c5d8-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 11:21:27 +0200
Received: by mail-ed1-f41.google.com with SMTP id
 4fb4d7f45d1cf-6a422090b14so6037617a12.1
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 02:21:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5d6499c0csm561812a12.25.2026.08.25.02.21.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 02:21:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787649687; x=1788254487; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=RHw1r7kmsfrd+VJzkoe5mR3jU5Bspag4uDuAfrhECes=;
        b=G4KOd5sS+0NdwenMgVSoGCY4uPNgmF51xEz7c9nMnANATmezto6nfmNJle16hDLVyU
         QKTAYjc45e+8xSOU8IhuxjT6c16dgE02GzpB6a8W6ZiaPPjUoGK6Cb23zT5jarqUMw+Q
         MHaZJAtNiVtAyCbPnasv6m2vRSDttdESOKb4C+ROexKFvZs6i51+kE87eG5FIozIUkbH
         nhPa5bcF1aTOJuZAnqXeeBVuU7pAhqPyTmYnhaC2/jArJBQUedzebKkSUPRywP8+6ZC/
         WjfzMH6XHDIPjuYElExJRDU6IiHkOzFmnz17Hp/XocnjJ9oqpClPPUMM9e/nqnHO3dmI
         ABpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787649687; x=1788254487;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=RHw1r7kmsfrd+VJzkoe5mR3jU5Bspag4uDuAfrhECes=;
        b=aINC8vcDH88ni9csjq0aM6JXzinOthGulCbUDrLQR9qhZHS4gaRRWDYPzuT4X/Ri1B
         OVQPq+PmK3OYE/Xzl3facKoqOhBwAqlXeLXRaZ6WRlMGUhcwHSCdaJ1kX/XgkcuARorb
         +o6KTYj9eEiQV/Tsjw3zPPwkTEM2n0M08O8ADycrP73uxBQXkOHLM1DZnIm2kD0+h4Cj
         6iqHN1VCDHGwwq39mDxceXEeIkYR9nYp3Zt27P105iQh5oTxVxJODp6cW0zaSd1lFsl1
         eLz7rgvQWnWUE8BdExT/IeXsCEwV2jGcYE2MDctTFO0Q3xC0ScLdsAOaAJdDWgalgAoc
         LVSA==
X-Gm-Message-State: AFuF++kncimdGJA+OQe4sJ3GLln9nm4h/j7HNDeNn3SRTyWYb8oiXGZk
	d2+VS6Jz+uCSSAUmTKkWNSpQ1G1ULqjd2CgSOG2OEZChDL26fRrfCmHFft4MEPapDI2i9Q3Ox4Q
	f6PhuSw==
X-Gm-Gg: AR+sD13eocD+zenjrszWGk5WrF4+5EF68+A4U4DUpp5xwXZ+7+u6Is47rZN79wDrLw9
	L7wZQ2QsbZ3ZXCOy1QGDJ/3j6pNmSY8HwDnPNiwOdjVB4R1jhPiaXnrLZIpxMP9WYM7Ip0MpRPc
	ZCmaXzQ5FI20Y32L1WaI28EJBkjoS7+0MVXbcMupgIAFx1tcC2oeqH3qx38JJmLphS/+LYxMPtY
	SVBQ/i3FKH4dQjGvs1y+0fr9VmPfi7+L7t5SC1byg0OO6Y9gmRNrQ8XFVjdLATBkk9E0ozlbYKA
	k4YwWRCL1Mr1+3lDVLVGq6P8DM8j0iHvUiudqtXI9tuCueg1fmxKq4tjaAF4vKKNVzIZKbHBWYx
	LsSVtaIpk6K77l3SY68i6jVvQ5uWi7Ee7K4k8sRVMb/rJktRmao+Z00FmOsS02eI8BWKpQYoRg1
	iAK1XtxPtxSesj7OhDqZUOg8cHR2gSDI/HOWpP7OJGxMWQFV9E2G2C//q0CWnLZHgbUgnG03D3k
	GSQ8cPuMnUMRRW+7zMAG2zy5q7Q+xDh0AlDHpRDM92efK8dLUpsxpuB6b2H/Xo=
X-Received: by 2002:a05:6402:a0d0:b0:6a3:71fd:4083 with SMTP id 4fb4d7f45d1cf-6a582b7db5amr27205969a12.9.1787649687262;
        Tue, 25 Aug 2026 02:21:27 -0700 (PDT)
Message-ID: <27ca9f33-9354-451c-8f17-358511d6ee34@suse.com>
Date: Tue, 25 Aug 2026 11:21:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] x86: split xen-syms/xen.efi linking rules
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
 <ccccc6f3-c16e-4988-9677-85d9ca6e30ce@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ccccc6f3-c16e-4988-9677-85d9ca6e30ce@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787649687-585CBCFC-E9173B85/0/0
X-purgate-type: clean
X-purgate-size: 2495

On 25.08.2026 10:41, Jan Beulich wrote:
> --- /dev/null
> +++ b/xen/scripts/Makefile.link
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# ==========================================================================
> +# Helper rules for linking xen-syms
> +# ==========================================================================
> +
> +syms-warn-dup-y := --warn-dup
> +syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
> +syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
> +
> +orphan-handling-$(call ld-option,--orphan-handling=warn) := --orphan-handling=warn
> +
> +final-image-check-y ?= true
> +
> +.$(TARGET)-syms.%.o: .$(TARGET)-syms.%.S FORCE
> +	$(call if_changed,cc_o_S)
> +
> +.$(TARGET)-syms.0.S:
> +	$(objtree)/tools/symbols $(all_symbols) --empty > $@
> +
> +.$(TARGET)-syms.1.S: .$(TARGET)-syms.0
> +.$(TARGET)-syms.2.S: .$(TARGET)-syms.1
> +.$(TARGET)-syms.3.S: .$(TARGET)-syms.2
> +
> +.$(TARGET)-syms.%.S:
> +	$(NM) -pa --format=sysv $< \
> +	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> +	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
> +	  > $@
> +
> +.$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds
> +	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
> +	      $(build_id_linker) --strip-debug -o $@
> +
> +.$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \
> +                                      .$(TARGET)-syms.$(LAST_LINKING_PASS).o \
> +                                      $(obj)/xen.lds
> +	$(call compare-symbol-tables, \
> +	       .$(TARGET)-syms.$(shell expr $(LAST_LINKING_PASS) - 1).o, \
> +	       .$(TARGET)-syms.$(LAST_LINKING_PASS).o)
> +	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
> +	      $(build_id_linker) $(orphan-handling-y) -o $@
> +
> +$(TARGET)-syms: .$(TARGET)-syms.$(LAST_LINKING_PASS)
> +	$(NM) -pa --format=sysv $< \
> +	  | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
> +	  > $@.map
> +	$(final-image-check-y)
> +	mv $< $@
> +	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*

Noticing only after sending: We will need to limit what is removed here. Removing
all intermediate files means the full linking process will always be redone, even
during "make install-xen" as root. Alternatively we should consider explicitly
avoiding any rebuilding in that case, much like e.g. x86 Linux Makefile logic does.
Thoughts?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 11:42:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 11:42:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399183.1635368 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wypXv-0005yo-Mk; Tue, 25 Aug 2026 11:42:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399183.1635368; Tue, 25 Aug 2026 11:42:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wypXv-0005yh-Jp; Tue, 25 Aug 2026 11:42:27 +0000
Received: by outflank-mailman (input) for mailman id 1399183;
 Tue, 25 Aug 2026 11:42:26 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wypXu-0005yb-Nd
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 11:42:26 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wypXu-004vzN-1L
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 11:42:26 +0000
Received: from mail-lf1-f47.google.com ([209.85.167.47])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wypXt-00HLmH-3B
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 11:42:26 +0000
Received: by mail-lf1-f47.google.com with SMTP id
 2adb3069b0e04-5b0148201fbso4191652e87.3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 04:42:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=yBQU37hqUoKtbMQ4pVzLFDUBUC8LRb+kRQfwB5YVEgY=; b=n0g9pwH0h50ZRvNAt0qGnWwZpF
	NW0rCaqaihE0uMyCecyT05eUFgG2LDaTkxbELeAETRezjnmdion68pNHRc+KuA/S+iG0BKb4J3tpH
	nU8ZOh8HPDziUApbuoKTKIBWaOAjb3uF+Hatm+mHpQXKrqi6bkys3tsAIp7obqb0/U8M=;
X-Forwarded-Encrypted: i=1; AHgh+RonJcatoAEc2xTqw9v+pHKoUzH753d/znrFLNLhM/aUPNZLJPeOnoy664B8Mye5nH3FvS+SzWQJuqE=@lists.xenproject.org
X-Gm-Message-State: AFuF++mrNyjv4VQUXvTbParL/2CnRNUPAFvjuLtgu6IeMRz49X61nUz0
	vWBKmsfN1N73O/4nCZgEZjUNxe3ZcBPFVRlefYYfHlewaT+EWMRclEkexJ1riz9NMdInjXmKc+G
	ap/xpWFSFZwkmEP9nYKvaoQBAyPf5aLo=
X-Received: by 2002:a05:6512:691:b0:5b2:e5b7:2419 with SMTP id
 2adb3069b0e04-5b49cd606b3mr2094380e87.5.1787658144688; Tue, 25 Aug 2026
 04:42:24 -0700 (PDT)
MIME-Version: 1.0
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com> <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
 <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com>
In-Reply-To: <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Tue, 25 Aug 2026 12:42:12 +0100
X-Gmail-Original-Message-ID: <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
X-Gm-Features: AcwNN1WeBD7-ShqIv6056gt7-SMnWmmHi6BxcaYpkhtmayuSEmOLFoM4ZCCyweI
Message-ID: <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 24, 2026 at 10:02=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wr=
ote:
> On 21.08.2026 17:17, George Dunlap wrote:
> > On Fri, Aug 21, 2026 at 9:45=E2=80=AFAM Jan Beulich <jbeulich@suse.com>=
 wrote:
> >> On 20.08.2026 19:43, George Dunlap wrote:
> >>> One point reviewers may want to look at specifically: patch 1 changes
> >>> where the per-domain page-tables are allocated from, and its commit
> >>> message discusses the (minor) NUMA-placement consequence.
> >>
> >> While I don't recall which recent patch (series) it was, I can't very =
well
> >> say "no new xenheap allocations please" there without also saying so h=
ere.
> >> I've read over patch 1's description, and while it tries to justify th=
is
> >> accordingly, I still remain concerned. I think we simply have to accep=
t
> >> the mapping overhead, to avoid allocating from a pool which - over tim=
e -
> >> is representing a decreasing portion of total memory systems have (on
> >> average, and not even considering systems with extremely sparse memory
> >> layouts, and with perhaps PDX compression not doing good enough to
> >> compensate).
> >
> > You should certainly have the same resistance to adding new xenheap
> > allocations.  But looking at the numbers, I don't see that we're
> > anywhere near the point where we say, "Absolutely no new xenheap
> > allocations, regardless of the cost."
>
> Well, that depends, and in part on the longer term plans with ASI. It has
> been my (silent) assumption that eventually the directmap would go away
> altogether when ASI is in use, with the VA space freed (almost?) all
> becoming available for vmap(). With the disappearance of directmap, the
> xenheap would naturally disappear as well. Hence putting stuff there in
> new work actually adds to our technical debt.

I do think that makes sense as a long-term goal.  Actually, I asked
Fable to do an audit of xenheap allocations, asking it to classify
them as to whether they needed xenheap's key properties (easy mfn <->
va conversion, available in early boot), and it reckoned only about 4%
of the allocations (by volume) in the example system I did numbers for
needed xenheap-specific properties.  Lots of things just need *some*
global mapping somewhere, and would probably actually overall benefit
from being moved to the vmap, so they wouldn't be restricted to a
single NUMA node.  Grant frames were the biggest chunk.

The xenheap / vmap split is certainly something I would now consider a
large piece of technical debt; moving towards paying that off is
certainly something I think worth achieving, provided the rest of the
maintainers are on board.

(Imagine how differently this conversation would have gone, if in the
first email you had said, "Actually, I thought one of the main goals
of this series was to get rid of the xenheap altogether, so that we
could switch to having a single large vmap area instead?")

> While these percentiles in particular of course look very tiny, they are
> applicable only on systems having no meaningful gaps in the physical
> address map. And even more generally I find all of these calculations
> only partly convincing, not the least because you start out from numbers
> which look pretty contrived when comparing to actual systems which would
> run the new code. (Using more realistic real-system values may end up
> going in favor of what you want to convey, or it may not.)

To be honest, I'm inclined to think that they're not very convincing
because you don't actually have an idea what the problem is.  You
didn't specify what you were worried about, so I tried to guess a
scenario that I considered 95th-percentile worse case.  I don't know
what kinds of sparse memory layout machines you have in mind -- are
they written down anywhere, so that contributors can read and
understand what they need to consider *before* implementing?  Even now
you haven't even said what about my scenario you consider unrealistic,
much less told me parameters you think are more realistic.

I don't even know exactly what failure mode you're worried about.  Two
kinds of potential failures I know about:
 - Performance impacted because pages can't be NUMA-local
 - Toolstack operations (including domain creation) fail because
xenheap has been exhausted.

If you're willing to accept 9 map/unmap operations on *all* systems,
then NUMA-non-local accesses can't be that big of an issue for you.

On the fairly largish system / load that I tried to estimate, the
total xenheap usage was less than 3GiB in the worst case.  Let's
double that just for safety sake: Do there exist systems whose memory
is so sparse that even with PDX compression, they can't even scrounge
together 6GiB below the 4TiB limit?  If so, I think a much better
solution would be to document that such systems may be able to support
a lower degree of oversubscribing than most systems, and leave it at
that.

In short: I can't imagine a scenario where a larger xenheap is an
issue we should be concerned about.

It's not up to me to guess what sorts of numbers would allay your
concern.  If you want me to consider a large xenheap to be a problem
on its own, it is now your job to articulate, first, at least one
target system (hardware and configuration) you think would be
problematic;  and secondly, exactly what bad thing you're worried
about happening.  Only then do I have any hope of addressing your
concerns.  Until that time, I don't consider "the xenheap is getting
too large" objection to be valid.

Objections I will consider:
- xenheap has poorer NUMA locality
- The xenheap/vmap split is a big ugly unnecessary bit of technical
debt; Xen would be far better if we could get rid of the xenheap
altogether.  Every additional user of xenheap is another patch in a
series converting xenheap to vmap.

> > One is map_domain_page_irqoff(): If the caller promises to keep
> > interrupts disabled until unmap_domain_page_irqoff(), we can safely
> > perform maps in a context switch without having to worry about
> > sync_lazy_execstate.  (This was actually implemented and almost sent
> > on Tuesday evening, when I noticed your review of Roger's v2 saying,
> > "Question is whether it's a good idea in the first place to start
> > using map_domain_page() from the context switch path.  Surely there
> > are possible alternatives.")  This maps all vcpu pages from the
> > domheap, adding nothing to the xenheap *or* the vmap area.  But it
> > costs 9 map/unmap pairs *per context switch*.
>
> But why would not using vmap() be a necessary conclusion of my initial
> comment? All I'm objecting to are new uses of the xenheap.

I'm trying to list all the advantages and disadvantages of the various
options I've explored.  You've agreed that growing the vmap region is
*also* something we need to worry about; and that the vmap allocator
may not be ready to become a performance-critical part of the system.
Furthermore, as Roger pointed out privately, regardless of where the
global mapping lives (vmap or sparsely-mapped xenheap), having a
global mapping at all means global TLB flushes whenever we destroy a
vCPU; and in any case, in principle we'd like to avoid exposing any
data whatsoever.  Using the mapcache avoids all those problems, for a
different cost.

> > Ultimately, I think there's a lot of wisdom in the saying, "Premature
> > optimization is the root of all evil."
> > ...
> I'm a little puzzled by you talking of "optimization" (premature or
> not) here. In my initial reply I did point out a functional aspect, and
> I made clear that I'm aware that this is going to have a performance
> impact. I.e. quite the opposite of "optimization".

"Optimize" in the terms of "improve", not necessarily in terms of cycle cou=
nt.

The point of the principle is to say this:  First, build it correctly,
in a way that is simple, clear, robust, and easy to write, review, and
maintain.  *Then*, after you've measured that there is a problem,
where there is a problem, and so on, should you put in extra effort
and add extra complication, only to areas where you know there will be
some material benefit.

You've argued that we should avoid using xenheap because it will have
some negative impacts on large systems with sparse memory layouts; in
other words, you're asking me to *optimize* for those use cases, at
the expense of more typical systems.  In isolation, this principle
would say: take the xenheap option first, as it's clean and fast in
the common case, and measure it on a target systems (or at least,
estimate what the impact would be based on modeling).  Once you have
reason to believe there will be a problem, then introduce code
complications based on the actual issue you find.

> > There are other options I've explored:
> >
> > - domheap + vmap; basically, allocate from domheap, map in the vmap
> >   area.  On paper this sounds like the same thing; the problem is that
> >   we don't have a simple MFN -> VA mapping, as we do in the xenheap
> >   case, so the walk is a lot harder; we start to have to do lookups,
> >   significantly increasing the cost over simple memory reads and math.
> >   (This is the difference from the intremap table on the VT-d thread:
> >   that's a leaf structure reached from a single pointer, so a
> >   permanent vmap costs nothing there.  Pagetable hierarchies are
> >   exactly the case where the MFN -> VA step is critical: each entry
> >   read yields an MFN, which the walk has to turn into the next VA.)
>
> The pages used here are entirely private to logic handling those page
> tables. Hence a struct page_info field can very likely be used to stash
> the VA of a permanent mapping. (Feels like similarly I must have
> suggested this somewhere else recently, yet I don't recall the context.)

This is an interesting idea, particularly for a full xenheap -> vmap
change.  Probably too complicated for this series (see below).

> Absolutely, and I have been mentioning the need to consider growing this
> area in a number of situations (one iirc again pretty recently).
...
> Indeed, heavier use of that allocator may require work to be done there.
...
> Valid concern, yet surely possible to deal with.

One thing you do need to consider:  There are at least 45 patches to
get to the most basic form of extra security (no direct-map, FPU/XSAVE
moved to domheap); and another 13 after that to move to per-cpu
stacks.  I'm engaged until November to work on this.  If we don't have
significant progress by then, there may be no ASI at all (at least for
a long time), and thus no hope of getting rid of the xenheap.  If
every batch of 7 patches takes a month to get through, we're not going
to be anywhere close by November.  So you need to be strategic about
what kinds of additional work you ask me to do: what does a solution
look like that is both technically acceptable, and achieves measurable
progress by November?

If we had all the time in the world, we could consider trying to
convert the entire xenheap to vmap as the first step.  (Even on the
fairly large system I tried to describe, the xenheap was only around
3GiB; still plenty of room in the vmap area to get us by until the
direct map is gone.)  I don't think that's really viable, as there's
quite a long tail of allocations that would probably end up being
haggled over before we even began the ASI series itself.

So let's try to take stock.  We can't safely remove the direct-map
unless we have per-vcpu mapcaches.  We can't really say we've isolated
the system while all pCPU stacks, with random bits of guest state, are
visible to all other pCPUs. We can't have per-vcpu mapcaches or
per-CPU stack maps unless we have per-cpu root pagetables for PV
guests.  Both require modifying per-pCPU bits of pagetables of the
incoming vCPU on a context switch.

We have four ways of mapping in general: xenheap, vmap, mapcache, or
(for the pagetables) the linear map.

For the first three, we have several different ways of arriving at the
entries.  Both Roger's v2 and my v1 start at the top and walk down the
pagetables.  For the mapcache, this seems relatively heavy.  I thought
xenheap would be just simple math, but with PDX on all the time,
that's more expensive than it looks.  vmap would require looking into
stashing a pointer into an unused (by xenheap pages) portion of the
struct page_info.

But the other approach is to stash references to just the page we need
to modify -- basically, rather than get rid of gdt_ldt_l1tab, add two
more instances.  For xenheap or vmap, this would be pointers to the
virtual addresses; but it's also possible to do in the mapcache
version, by stashing the mfn of the exact table we need to map.  In
all cases, for the context switch, it's just three references.

Both global-mapping options expose Xen pagetables.  We've agreed these
are not sensitive, but also in general our posture is that we
shouldn't reveal anything unless it buys us something.  They also both
require host-wide TLB shootdowns on vCPU tear-down.

In the spirit of "measure before optimizing", I did some tests of the
mapcache-walk variant.  On my NUC, at the end of the series, I get:

- baseline: 1480 cycles / context switch
- xenheap-walk: 2460 cycles / context switch
- mapcache-walk: 6440 cycles / context switch

By default Xen has a context switch rate limit of 1ms, so the
difference isn't measurable.  If you disable the ratelimit and do a
"ping flood" microbenchmark, the mapcache-walk reduces performance by
a whopping 70% (41k pings per second -> 12k pings per second).

If it weren't for the general intent to move away form xenheap, I'd
argue more strenuously that we should take the series as I've posted
it.  As it stands, I think the performance of mapcache-walk is
acceptable enough for a first cut, particularly given that we have two
potential optimizations already (caching MFNs rather than walking
pagetables as an easy option, switching to vmap as a slightly more
complicated one).

It's annoying that Tuesday evening I didn't know that you hated
xenheap allocations, and had only a mild distaste for mapping in a
context switch, or I might have implemented vmap instead.  At any
rate, I'll move forward with mapcache-walk, which we can later look at
optimizing by stashing the relevant MFNs so we can avoid the walk.

If anyone doesn't like that, let me know sooner rather than later, so
we can avoid wasting more time.

 -George

 -George


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 12:01:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 12:01:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399194.1635377 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyppo-0000SW-9b; Tue, 25 Aug 2026 12:00:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399194.1635377; Tue, 25 Aug 2026 12:00:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyppo-0000SO-6E; Tue, 25 Aug 2026 12:00:56 +0000
Received: by outflank-mailman (input) for mailman id 1399194;
 Tue, 25 Aug 2026 12:00:55 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wyppm-0000SH-N8
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 12:00:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyppl-00FLtq-G3
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:00:53 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a8d83ef-bab6-0a2a0a5309dd-0a2a4506c396-26
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 14:00:53 +0200
Received: from [195.135.223.130] (helo=smtp-out1.suse.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a8d83f5-195a-0a2a45060019-c387df82a34a-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 14:00:53 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out1.suse.de (Postfix) with ESMTPS id B611F86CC6;
 Tue, 25 Aug 2026 12:00:44 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 788B513331;
 Tue, 25 Aug 2026 12:00:44 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id G+VTHOyDjWrTYAAAD6G6ig
 (envelope-from <jgross@suse.com>); Tue, 25 Aug 2026 12:00:44 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787659248; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=nYI6Tw5TM49GzToIO3x4eefLbl+QFgyn24vAbLiQGGE=;
	b=MdQBFbphi0aiHvmD8WC9KuO/rIFvwE9TDmqmP2og2jj2ZU1HYsT6MBIbs2dP6mkrD8yonS
	tf8R8Y8QdA5E8naSmPLQp/si5IFEAAjayL7Ha4sGtb5rYxN6OLdb3OR8EWffkG7jUwmJZB
	TBTbhVz+u5J6viY9c60z/KVqgQWX388=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=kgznDe6c
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787659244; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=nYI6Tw5TM49GzToIO3x4eefLbl+QFgyn24vAbLiQGGE=;
	b=kgznDe6cAWgOkw54YfiiLkbfWJXOrQZoyk0MvaWAfXemvBSOtBEgwbGyL1MC2ReP88S5V2
	A8j0FI0vyOl6wcenzFCRgQY40IAgXmF0Y6XKbD47un3MFCta79THr6KocHuQ5xhpMhm7ib
	TLydZsVO9+KIbILDtSC6G1MeO/fGOcw=
Message-ID: <c654817b-dc5c-4e3b-be7a-156432af1dbf@suse.com>
Date: Tue, 25 Aug 2026 14:00:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: George Dunlap <gwd@xenproject.org>, Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
 <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
 <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com>
 <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------2jktY701EIsqVP6R2djx5EbY"
X-Spamd-Result: default: False [-6.41 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	HAS_ATTACHMENT(0.00)[];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,suse.com:dkim,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]
X-Spam-Flag: NO
X-Spam-Score: -6.41
X-Spam-Level: 
X-Rspamd-Queue-Id: B611F86CC6
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-purgate-ID: tlsNG-16d1c6/1787659253-F500977B-3834091A/0/0
X-purgate-type: clean
X-purgate-size: 11890

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------2jktY701EIsqVP6R2djx5EbY
Content-Type: multipart/mixed; boundary="------------rBTJ0QPH0xXRrlonZW0NjZYI";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: George Dunlap <gwd@xenproject.org>, Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Message-ID: <c654817b-dc5c-4e3b-be7a-156432af1dbf@suse.com>
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
 <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
 <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com>
 <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
In-Reply-To: <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------rBTJ0QPH0xXRrlonZW0NjZYI
Content-Type: multipart/mixed; boundary="------------vBSusJ8khJoKDQ6QU4axMhnM"

--------------vBSusJ8khJoKDQ6QU4axMhnM
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjUuMDguMjYgMTM6NDIsIEdlb3JnZSBEdW5sYXAgd3JvdGU6DQo+IE9uIE1vbiwgQXVn
IDI0LCAyMDI2IGF0IDEwOjAy4oCvQU0gSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29t
PiB3cm90ZToNCj4+IE9uIDIxLjA4LjIwMjYgMTc6MTcsIEdlb3JnZSBEdW5sYXAgd3JvdGU6
DQo+Pj4gT24gRnJpLCBBdWcgMjEsIDIwMjYgYXQgOTo0NeKAr0FNIEphbiBCZXVsaWNoIDxq
YmV1bGljaEBzdXNlLmNvbT4gd3JvdGU6DQo+Pj4+IE9uIDIwLjA4LjIwMjYgMTk6NDMsIEdl
b3JnZSBEdW5sYXAgd3JvdGU6DQo+Pj4+PiBPbmUgcG9pbnQgcmV2aWV3ZXJzIG1heSB3YW50
IHRvIGxvb2sgYXQgc3BlY2lmaWNhbGx5OiBwYXRjaCAxIGNoYW5nZXMNCj4+Pj4+IHdoZXJl
IHRoZSBwZXItZG9tYWluIHBhZ2UtdGFibGVzIGFyZSBhbGxvY2F0ZWQgZnJvbSwgYW5kIGl0
cyBjb21taXQNCj4+Pj4+IG1lc3NhZ2UgZGlzY3Vzc2VzIHRoZSAobWlub3IpIE5VTUEtcGxh
Y2VtZW50IGNvbnNlcXVlbmNlLg0KPj4+Pg0KPj4+PiBXaGlsZSBJIGRvbid0IHJlY2FsbCB3
aGljaCByZWNlbnQgcGF0Y2ggKHNlcmllcykgaXQgd2FzLCBJIGNhbid0IHZlcnkgd2VsbA0K
Pj4+PiBzYXkgIm5vIG5ldyB4ZW5oZWFwIGFsbG9jYXRpb25zIHBsZWFzZSIgdGhlcmUgd2l0
aG91dCBhbHNvIHNheWluZyBzbyBoZXJlLg0KPj4+PiBJJ3ZlIHJlYWQgb3ZlciBwYXRjaCAx
J3MgZGVzY3JpcHRpb24sIGFuZCB3aGlsZSBpdCB0cmllcyB0byBqdXN0aWZ5IHRoaXMNCj4+
Pj4gYWNjb3JkaW5nbHksIEkgc3RpbGwgcmVtYWluIGNvbmNlcm5lZC4gSSB0aGluayB3ZSBz
aW1wbHkgaGF2ZSB0byBhY2NlcHQNCj4+Pj4gdGhlIG1hcHBpbmcgb3ZlcmhlYWQsIHRvIGF2
b2lkIGFsbG9jYXRpbmcgZnJvbSBhIHBvb2wgd2hpY2ggLSBvdmVyIHRpbWUgLQ0KPj4+PiBp
cyByZXByZXNlbnRpbmcgYSBkZWNyZWFzaW5nIHBvcnRpb24gb2YgdG90YWwgbWVtb3J5IHN5
c3RlbXMgaGF2ZSAob24NCj4+Pj4gYXZlcmFnZSwgYW5kIG5vdCBldmVuIGNvbnNpZGVyaW5n
IHN5c3RlbXMgd2l0aCBleHRyZW1lbHkgc3BhcnNlIG1lbW9yeQ0KPj4+PiBsYXlvdXRzLCBh
bmQgd2l0aCBwZXJoYXBzIFBEWCBjb21wcmVzc2lvbiBub3QgZG9pbmcgZ29vZCBlbm91Z2gg
dG8NCj4+Pj4gY29tcGVuc2F0ZSkuDQo+Pj4NCj4+PiBZb3Ugc2hvdWxkIGNlcnRhaW5seSBo
YXZlIHRoZSBzYW1lIHJlc2lzdGFuY2UgdG8gYWRkaW5nIG5ldyB4ZW5oZWFwDQo+Pj4gYWxs
b2NhdGlvbnMuICBCdXQgbG9va2luZyBhdCB0aGUgbnVtYmVycywgSSBkb24ndCBzZWUgdGhh
dCB3ZSdyZQ0KPj4+IGFueXdoZXJlIG5lYXIgdGhlIHBvaW50IHdoZXJlIHdlIHNheSwgIkFi
c29sdXRlbHkgbm8gbmV3IHhlbmhlYXANCj4+PiBhbGxvY2F0aW9ucywgcmVnYXJkbGVzcyBv
ZiB0aGUgY29zdC4iDQo+Pg0KPj4gV2VsbCwgdGhhdCBkZXBlbmRzLCBhbmQgaW4gcGFydCBv
biB0aGUgbG9uZ2VyIHRlcm0gcGxhbnMgd2l0aCBBU0kuIEl0IGhhcw0KPj4gYmVlbiBteSAo
c2lsZW50KSBhc3N1bXB0aW9uIHRoYXQgZXZlbnR1YWxseSB0aGUgZGlyZWN0bWFwIHdvdWxk
IGdvIGF3YXkNCj4+IGFsdG9nZXRoZXIgd2hlbiBBU0kgaXMgaW4gdXNlLCB3aXRoIHRoZSBW
QSBzcGFjZSBmcmVlZCAoYWxtb3N0PykgYWxsDQo+PiBiZWNvbWluZyBhdmFpbGFibGUgZm9y
IHZtYXAoKS4gV2l0aCB0aGUgZGlzYXBwZWFyYW5jZSBvZiBkaXJlY3RtYXAsIHRoZQ0KPj4g
eGVuaGVhcCB3b3VsZCBuYXR1cmFsbHkgZGlzYXBwZWFyIGFzIHdlbGwuIEhlbmNlIHB1dHRp
bmcgc3R1ZmYgdGhlcmUgaW4NCj4+IG5ldyB3b3JrIGFjdHVhbGx5IGFkZHMgdG8gb3VyIHRl
Y2huaWNhbCBkZWJ0Lg0KPiANCj4gSSBkbyB0aGluayB0aGF0IG1ha2VzIHNlbnNlIGFzIGEg
bG9uZy10ZXJtIGdvYWwuICBBY3R1YWxseSwgSSBhc2tlZA0KPiBGYWJsZSB0byBkbyBhbiBh
dWRpdCBvZiB4ZW5oZWFwIGFsbG9jYXRpb25zLCBhc2tpbmcgaXQgdG8gY2xhc3NpZnkNCj4g
dGhlbSBhcyB0byB3aGV0aGVyIHRoZXkgbmVlZGVkIHhlbmhlYXAncyBrZXkgcHJvcGVydGll
cyAoZWFzeSBtZm4gPC0+DQo+IHZhIGNvbnZlcnNpb24sIGF2YWlsYWJsZSBpbiBlYXJseSBi
b290KSwgYW5kIGl0IHJlY2tvbmVkIG9ubHkgYWJvdXQgNCUNCj4gb2YgdGhlIGFsbG9jYXRp
b25zIChieSB2b2x1bWUpIGluIHRoZSBleGFtcGxlIHN5c3RlbSBJIGRpZCBudW1iZXJzIGZv
cg0KPiBuZWVkZWQgeGVuaGVhcC1zcGVjaWZpYyBwcm9wZXJ0aWVzLiAgTG90cyBvZiB0aGlu
Z3MganVzdCBuZWVkICpzb21lKg0KPiBnbG9iYWwgbWFwcGluZyBzb21ld2hlcmUsIGFuZCB3
b3VsZCBwcm9iYWJseSBhY3R1YWxseSBvdmVyYWxsIGJlbmVmaXQNCj4gZnJvbSBiZWluZyBt
b3ZlZCB0byB0aGUgdm1hcCwgc28gdGhleSB3b3VsZG4ndCBiZSByZXN0cmljdGVkIHRvIGEN
Cj4gc2luZ2xlIE5VTUEgbm9kZS4gIEdyYW50IGZyYW1lcyB3ZXJlIHRoZSBiaWdnZXN0IGNo
dW5rLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IEknbSBjdXJyZW50bHkgd29ya2luZyBvbiBhIHBh
dGNoIHNlcmllcyB3aGljaCB3aWxsIG5lZWQNCnRvIGNvbnZlcnQgZ3JhbnQgZnJhbWVzIGFu
ZCBzb21lIG90aGVyIHhlbmhlYXAgYWxsb2NhdGlvbnMgdG8gdXNlIGRvbWhlYXANCmFuZCB2
bWFwKCkuDQoNCkN1cnJlbnRseSB0aGlzIGlzIGp1c3QgYSBwcm9vZiBvZiBjb25jZXB0IGZv
ciBYZW4gc3VtbWl0LCBidXQgSSBleHBlY3QNCnRoaXMgdG8gYmVjb21lIG1hdHVyZSBhZnRl
ciBzb21lIGZlZWRiYWNrIEkgaG9wZSB0byBnZXQgdGhlcmUuDQoNCg0KSnVlcmdlbg0K
--------------vBSusJ8khJoKDQ6QU4axMhnM
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------vBSusJ8khJoKDQ6QU4axMhnM--

--------------rBTJ0QPH0xXRrlonZW0NjZYI--

--------------2jktY701EIsqVP6R2djx5EbY
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqNg+wFAwAAAAAACgkQsN6d1ii/Ey8z
eQf6AtamFtk9zos2M2YL5I/mwhqVIMAuRUGs71xGYZLadKjvsEJ10JbUa7x6bREJ621VSen7gzFF
5M3Yfv8xDG0f/Kpu6LTjVbtRHdbLRt3EYix71F5S/QSX2+4czKq8bbw2KU+tKOfoUXOBFDBQzoyr
rbMDe2d7rNL3kRtiLtOCq/qIwMwBM75VvThzGAI5NhU70zZH6uD3Xd6+iXDAHCQic1Ur621648AH
uz85afuv4NLtflMNrG9cOlcYZ2arJ/YqSXuLzUtvf6OQg66E96LgQkWtD1HeyzGAHK49nj5z5BQ5
PC5J6scClf0tbHvCGvRFzeenDpAP9eHmJgDbkTtm6A==
=7oOB
-----END PGP SIGNATURE-----

--------------2jktY701EIsqVP6R2djx5EbY--


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 13:03:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 13:03:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399215.1635386 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyqoN-00087h-LE; Tue, 25 Aug 2026 13:03:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399215.1635386; Tue, 25 Aug 2026 13:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyqoN-00087a-Ih; Tue, 25 Aug 2026 13:03:31 +0000
Received: by outflank-mailman (input) for mailman id 1399215;
 Tue, 25 Aug 2026 13:03:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wyqoM-00087U-VK
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 13:03:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyqoL-00A0Ge-KH
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 15:03:29 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d9294-2eae-0a2a0a5409dd-0a2a450189aa-46
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 15:03:29 +0200
Received: from [209.85.218.53] (helo=mail-ej1-f53.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d92a1-5984-0a2a45010019-d155da35e47d-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 15:03:29 +0200
Received: by mail-ej1-f53.google.com with SMTP id
 a640c23a62f3a-c197eaaab00so785061066b.0
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 06:03:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c24966f8f08sm1767864666b.35.2026.08.25.06.03.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 06:03:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787663009; x=1788267809; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=3abfLYtbhqo3sPLXfuqbsLtONQCvD+Y+HQH1s9WWDbA=;
        b=azsN4Keg1LWnE1/2Q7x+Vf7TDDW+If1fObgyx9HP6NjwS5GcIfAZYR3SdbB3XMa1oE
         NgGXeVf0Uco28A+mfswN/mZPRLDGgvbZXyvRtxYGEe7KS1xpS+C7Gcne41+GvjIrHdSM
         2r8xvF1Y/qs4GnHr63prupkyC9Q3IT7MJQdhTb4KmwgqMC4pXxvr+nOLQEl7BwY6wKCw
         TZO3jMpsZRZRno6z7MoHOk3Q4iEGDSfRa07HSm8bDxqcJcEtiN/bAnVVzqHu7LMU/1pl
         D5qDJGZkPOGrwE7bBM9grw2QRFxPxpRGVyKyOw/sf7HA0CAqQYYbz4ra9P/RU/gJq5b5
         tMLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787663009; x=1788267809;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=3abfLYtbhqo3sPLXfuqbsLtONQCvD+Y+HQH1s9WWDbA=;
        b=bwzHI11QskYbVJi4RGdL0iTiQBm6BhWyDJWZDavepuDllj60sBUJP5gUaeJwTcOmRF
         JwCrsFihV2smEDZg0SxTB6IeDtzzsN8n6u+U3R9bk1guSchRzPn/vPc0LVBCM63tZIkX
         mb1wZ+nLcJH1HhlsNcYNbwC7nnaypnU77Trp6blWdC7QbbY778DPGIixwn+loKveAL+7
         /BHjvOWk9OFAkUjSUe5OdXTC6CyxIZJnPdKb7dZHAR8hqxlnG0FuItEk/aVTRvJ650AT
         XgzJo1Ed70zHVmPgP/ecIp8bRZMBZGIXQdhlbn1EYB9FKiDqB/7tJqyUWmgdXge+uQUc
         ic3Q==
X-Gm-Message-State: AFuF++ku0SpQwrx8NqVHETdH/HTpqwQItpH4+/6s9PvaIfT7yaJn0Y62
	SNRVN9d53wGjX+Xf+ipn5Jna/6b6A3ANhmOPnRSUEgrDPA3OPTXJf8IpcXm8r15ECtgym+oNZ5S
	II/DSfQ==
X-Gm-Gg: AR+sD13oMd1lr3jaxMt9iY6qRzee617UmRnxhBdcYq5PYipB1bn29C0XhlqHqKZ4dKj
	nrmt6mq03zfHCeBfRUlb0xUt89/79dMBSSnC415dPh5Vi4ol6P07BCyv6wsjDJ6CsREDSRHCXyG
	gSYX/MhZXjkb5mXHRG8yiJbZ84fUEphvBaP2IG/vDyPfEVeIlft8Wp9CTsX4OWhYLkuWm742lP4
	iYadsIJOvzYq+eOZulfrbJ25sWDK+oM2SxPDQYKX3uykF0hRVILdJ42UYoUuy/DKzfqLHga+QhL
	gRFvEIzNQMViUKWlio00Q2w1J03pV0ZGC64TsCpU/JU4Uuy7EbvuHjl1oxlZyCbEOZLB98CkDaT
	W1etLXLalQzd7Zr0XWGmC/FygxCs5h049eei3jExRi6fuUvo41T3gO2gPjRIGrOaBtNDXb8JJtI
	g12rtug3m16EmEy/q2qVr2rpLS/WmIWJ+eAjiBtmoETufJaoQMaYjNAUTTmdauWxSuX2IcHjQlq
	bg8x2aJR0oEAJ+G/hz8k3iPLvOnrYmGVl+si5TQMe/fedXoeOMI
X-Received: by 2002:a17:907:6d0c:b0:c19:fb6e:5fec with SMTP id a640c23a62f3a-c24e600d291mr687677366b.18.1787663008599;
        Tue, 25 Aug 2026 06:03:28 -0700 (PDT)
Message-ID: <d18c88ad-6688-4c01-bce8-681f68e04f5f@suse.com>
Date: Tue, 25 Aug 2026 15:03:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/6] x86: split xen-syms/xen.efi linking rules
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
References: <fb75dbda-63a5-4ebd-abf6-5ce6b3b5ba3f@suse.com>
 <ccccc6f3-c16e-4988-9677-85d9ca6e30ce@suse.com>
 <27ca9f33-9354-451c-8f17-358511d6ee34@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <27ca9f33-9354-451c-8f17-358511d6ee34@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787663009-BC359757-FE23A956/0/0
X-purgate-type: clean
X-purgate-size: 2610

On 25.08.2026 11:21, Jan Beulich wrote:
> On 25.08.2026 10:41, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/scripts/Makefile.link
>> @@ -0,0 +1,49 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# ==========================================================================
>> +# Helper rules for linking xen-syms
>> +# ==========================================================================
>> +
>> +syms-warn-dup-y := --warn-dup
>> +syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
>> +syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
>> +
>> +orphan-handling-$(call ld-option,--orphan-handling=warn) := --orphan-handling=warn
>> +
>> +final-image-check-y ?= true
>> +
>> +.$(TARGET)-syms.%.o: .$(TARGET)-syms.%.S FORCE
>> +	$(call if_changed,cc_o_S)
>> +
>> +.$(TARGET)-syms.0.S:
>> +	$(objtree)/tools/symbols $(all_symbols) --empty > $@
>> +
>> +.$(TARGET)-syms.1.S: .$(TARGET)-syms.0
>> +.$(TARGET)-syms.2.S: .$(TARGET)-syms.1
>> +.$(TARGET)-syms.3.S: .$(TARGET)-syms.2
>> +
>> +.$(TARGET)-syms.%.S:
>> +	$(NM) -pa --format=sysv $< \
>> +	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>> +	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
>> +	  > $@
>> +
>> +.$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds
>> +	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
>> +	      $(build_id_linker) --strip-debug -o $@
>> +
>> +.$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \
>> +                                      .$(TARGET)-syms.$(LAST_LINKING_PASS).o \
>> +                                      $(obj)/xen.lds
>> +	$(call compare-symbol-tables, \
>> +	       .$(TARGET)-syms.$(shell expr $(LAST_LINKING_PASS) - 1).o, \
>> +	       .$(TARGET)-syms.$(LAST_LINKING_PASS).o)
>> +	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
>> +	      $(build_id_linker) $(orphan-handling-y) -o $@
>> +
>> +$(TARGET)-syms: .$(TARGET)-syms.$(LAST_LINKING_PASS)
>> +	$(NM) -pa --format=sysv $< \
>> +	  | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
>> +	  > $@.map
>> +	$(final-image-check-y)
>> +	mv $< $@
>> +	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> 
> Noticing only after sending: We will need to limit what is removed here. Removing
> all intermediate files means the full linking process will always be redone, even
> during "make install-xen" as root.

Actually it can be kept like this, but intermediate files need marking
as such, and $(if_changed ...) shouldn't be used (at least for the
moment).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 13:28:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 13:28:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399236.1635395 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyrCg-0002lJ-IO; Tue, 25 Aug 2026 13:28:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399236.1635395; Tue, 25 Aug 2026 13:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyrCg-0002lC-FP; Tue, 25 Aug 2026 13:28:38 +0000
Received: by outflank-mailman (input) for mailman id 1399236;
 Tue, 25 Aug 2026 13:28:37 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wyrCf-0002l6-PP
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 13:28:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyrCe-002jYd-Ei
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 15:28:36 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d987e-bab6-0a2a0a5309dd-0a2a450ae090-8
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 15:28:32 +0200
Received: from [209.85.218.50] (helo=mail-ej1-f50.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8d9880-f2d2-0a2a450a0019-d155da32b8ca-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 15:28:32 +0200
Received: by mail-ej1-f50.google.com with SMTP id
 a640c23a62f3a-c20e70a0962so727126866b.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 06:28:32 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c249685ab63sm1728728466b.50.2026.08.25.06.28.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 06:28:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787664512; x=1788269312; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cJggQA6AcIJyW0vWh0BHsMQ+AEm79IycoXNzRuRXB2k=;
        b=feXT1K6TnUdqfiuKG2Ce3us8QPjpt6BWNk39ljl+qxH/FUa6WuusO58LQmz03QuTFk
         r431puLgdRw27VYYHAmIqzgHuTIrEUKlFS8zrHO6GHGie2suBeBpw+973t2MZ9qr7ShB
         ze7c7otMUkSSiqum8e8ijTTfHzuWb6K+8AyQJldu9aBQdr87Rp5OZI6ACZMhd9lwulOd
         JOzWg3eDuEqr2+BdddzBL+u23t7f2LNEh0A9hHCYPFrJWATqc4DU/kyu/a7/6XXH/L2N
         yPLPKKvoY4IapahVOUeWcbipJhZX+upAs4s9yLcBbiqvcrYhoEMSb7gAq0IaudrFMZqk
         z7BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787664512; x=1788269312;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=cJggQA6AcIJyW0vWh0BHsMQ+AEm79IycoXNzRuRXB2k=;
        b=T7mFahIVUN+XC39QzHieljEFtEGFe3paNOR3udDfGT0qU9wwbOWVNNVoVvMe9O1HTX
         4Ldyy93dnEejSoE3JEDNqTYiIHCQkVUh8hPfjWI57HJ6m2GyQ/m9/uVGhunS9kTxprfn
         T4zFnZZ/gGh9N7EoofffGsZ25xV9g3WB4auJyR/dnumIjbCbiFW1qVMLI+4lUTngXlEZ
         K3+hYtKIqsMPM03vwxZrJE+Tt5KLURtQ++JwKqS21Roo1RjAfyWgbWHZ7SCtQUltMRTY
         FdX9G7WzBMzeurkNsRYuEVOeADR3uHAXcgkuWXw8/6Me8+wRVKh/oIroxy0bNMAHVPMN
         PrOA==
X-Forwarded-Encrypted: i=1; AHgh+RoVnREkm3kxyZowXsBvUVd6h6hMtcYv+2doOpWa6cVSgjR3d/6DejUTQIyxQ/JbJoNFmFsjGqgzi3c=@lists.xenproject.org
X-Gm-Message-State: AFuF++lG4DOsvjO77n3pXE3i3je5sXC3i7c8F5Uk37YiW931ZtTTU98z
	kQLP8zZG2sewzUjzltSA2nrLZZg0Eq5jVDrjGKgtk6GJwalzTl2r85cxr6/pkN4mOg==
X-Gm-Gg: AR+sD10vx97GrQmj0TbZ2pcGeKVzl60mLh4d/HDSH4Lno2Ei+YnypqLfwPWA5jMOAVu
	tuCnDLG144+i20GPXJVFoMQSv8z6wk0x/eK3GTfFIK3/PbkccwFCC69i5dKwLQa7l2LlLy41OmW
	+ADhXcl8S1NVL4zwwX0Y6iF+8agEir+/KB+VB8YpQe1l+xVzJdOOaxIHZHXhp6Trhz0KAavDPBe
	V/7mUeFHmoseZ0y6BscZKhaysLaizGfjf4YAktokwSwzYn/0ctfCpp00Ac06WLh6FNmLXg5p1AA
	CyZuK7NbkzbKLmxyBLc8JbCXeNZJYZ7kPOaoKAfR4rhfJNV3qcKgQSCodT92Bh3VQFbe5hzRp/y
	x0goVA8aH+xeWNe+W1QK4CQyrG5adUo4GJ+efN/o17Ypsq6diUsfS0YQjkOlO38fCwuaDlEpn2o
	x4CAd3/JS4Or2qOaAThmVYn9zmqFg5gTUaq0Yrm5BQdq2X7C+R448QwEP9z0Ujr3OrzBLtKYJuG
	TC2RIRuSXeR4semoHUpUOg86b06WFHo8ID5Q5kGsOiGX72yl5yM
X-Received: by 2002:a17:907:ea8b:b0:c21:2c32:e2da with SMTP id a640c23a62f3a-c246a5f4515mr4267561966b.8.1787664512080;
        Tue, 25 Aug 2026 06:28:32 -0700 (PDT)
Message-ID: <f34b38e3-4f77-49e2-a69f-aea153f53787@suse.com>
Date: Tue, 25 Aug 2026 15:28:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: George Dunlap <gwd@xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com>
 <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
 <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com>
 <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787664512-51EC2CFC-112D4314/0/0
X-purgate-type: clean
X-purgate-size: 2899

On 25.08.2026 13:42, George Dunlap wrote:
> On Mon, Aug 24, 2026 at 10:02 AM Jan Beulich <jbeulich@suse.com> wrote:
>> While these percentiles in particular of course look very tiny, they are
>> applicable only on systems having no meaningful gaps in the physical
>> address map. And even more generally I find all of these calculations
>> only partly convincing, not the least because you start out from numbers
>> which look pretty contrived when comparing to actual systems which would
>> run the new code. (Using more realistic real-system values may end up
>> going in favor of what you want to convey, or it may not.)
> 
> To be honest, I'm inclined to think that they're not very convincing
> because you don't actually have an idea what the problem is.  You
> didn't specify what you were worried about, so I tried to guess a
> scenario that I considered 95th-percentile worse case.  I don't know
> what kinds of sparse memory layout machines you have in mind -- are
> they written down anywhere, so that contributors can read and
> understand what they need to consider *before* implementing?  Even now
> you haven't even said what about my scenario you consider unrealistic,
> much less told me parameters you think are more realistic.

What I specifically considered unrealistic is that you use huge pCPU and
vCPU counts. Yes, you're trying to do a worst case estimate, yet at the
same time you're assuming huge amounts of memory to be available (which
doesn't represent a "worst case").

As to sparse layouts - ones which have led to the two forms of PDX
compression are well known (I think). The need for more recent (offset)
form is a good example of what could go wrong here: New machines can
always come with new layouts, potentially requiring new compressions
approaches. So what I'm concerned about is effectively _any_ sparse
layout that we may encounter without having a suitable PDX compression
method readily available.

> I don't even know exactly what failure mode you're worried about.  Two
> kinds of potential failures I know about:
>  - Performance impacted because pages can't be NUMA-local
>  - Toolstack operations (including domain creation) fail because
> xenheap has been exhausted.

One thing I can't help thinking you keep overlooking throughout your
reply: xenheap and domheap aren't separate. There being only a
relatively small part of it needed for the worst case estimate you did
means nothing as to exhausting the xenheap in practice: Almost the
entirety of it (with the DMA reserve being somewhat protected) can be
used to build domains. Once in that state, allocations would fail no
matter that large swathes of domheap might (have become) available
(again).

That said, with what you indicated at the very bottom of your reply,
it looks like this part of the discussion has become largely moot.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 14:20:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 14:20:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399252.1635405 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys0R-0001Bk-75; Tue, 25 Aug 2026 14:20:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399252.1635405; Tue, 25 Aug 2026 14:20:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys0R-0001BD-1u; Tue, 25 Aug 2026 14:20:03 +0000
Received: by outflank-mailman (input) for mailman id 1399252;
 Tue, 25 Aug 2026 14:20:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@swg.vates.tech>)
 id 1wys0O-0000rj-J9
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:20:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wys0N-0059UO-SZ
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 16:19:59 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@swg.vates.tech>)
 id 6a8da486-2eae-0a2a0a5409dd-0a2a450bc6c4-10
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:19:59 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@swg.vates.tech>)
 id 6a8da48f-b7e8-0a2a450b0019-b9ff1c22a7c5-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:19:59 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0394ac7f2000c4f3.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 25 Aug 2026 14:19:57 +0000
Received: from [192.168.1.49] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: julian.vetter)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8CC7C83274;
 Tue, 25 Aug 2026 16:19:56 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=u97rfPbz3xsGMVtDrfGCIiKOaJT5M7k/QkRGG3lW9Cw=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=Z54AI6zvRbFBmcgsqeJwSntWmfsvCMZOiQlZ6dlSXt8/mKx5hbutCxpkCHw9YYpV1olD8oIf2
 eVFSp4MewhdAvnSPRFP6no65blD5OvFOnFD7/IpkTykswBkNYyJx7sbBRQMBn31NTo4dGSEvG7i
 skMuW/UezwzS/Y4pVsap2UxuWC2ufk8C+RE9CAFqJwEJ7hW2hqN2egMqbP+i1dywFBXC/BNfoDe
 hualPjI/5HJ8zJJfeNQJNk3VndngLIoMUeEez1Rs5/CAwDrUWuUESa1HDBufC6D41BbZvO8vdbE
 VO/IKU+zeUkZvDFICNFtalap0RlOuDk4YPCGrbaO/2yQ==
X-Zone-Loop: b659c29a28e08754c13d90a6aa320db24d834af98647
x-campaign-type: default
x-transaction-id: 90d8b0ea-8456-4b4e-ba01-6d8445466996
x-swg-uid: 01-4602cf69-b639-4b74-a7d2-1a27d1b86590
X-Mailer: Sweego
Message-ID:
 <1787667597.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@vates.tech>
x-swg-bid: 1787667597.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Tue, 25 Aug 2026 16:19:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/3] ioreq: switch ioreq page allocation to vmap
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260420093820.825969-1-julian.vetter@vates.tech>
 <20260420093820.825969-2-julian.vetter@vates.tech>
 <35a08d22-1e95-4e02-a7e9-7f392ef11722@suse.com>
Content-Language: en-US
From: Julian Vetter <julian.vetter@vates.tech>
In-Reply-To: <35a08d22-1e95-4e02-a7e9-7f392ef11722@suse.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2b1e.98ce00ae3019bacf.1a0394ac5bb.43e3200d7ca5731=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787667596738
X-purgate-ID: tlsNG-42698a/1787667599-AB0DD9EA-4E2194C3/0/0
X-purgate-type: clean
X-purgate-size: 6677

---=Part.2b1e.98ce00ae3019bacf.1a0394ac5bb.43e3200d7ca5731=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 8/18/26 3:06 PM, Jan Beulich wrote:
> On 20=2E04=2E2026 11:38, Julian Vetter wrote:
>> Switch the Xen-side ioreq page mapping from prepare_ring_for_helper() /
>> map_domain_page_global() to explicit vmap(), to ensure vmap_to_page()
>> can recover the struct page_info * uniformly during teardown=2E
>=20
> What's after the comma isn't really the main reason for this patch, is i=
t?
> Describing this aspect =2E=2E=2E
>=20
>> This is a prerequisite for multi-page ioreq support: the non-buf ioreq
>> region will need to span multiple pages for domains with more vCPUs tha=
n
>> fit in a single page, and vmap() is the natural interface for contiguou=
s
>> multi-page Xen VA mappings=2E
>>
>> In non-debug builds map_domain_page_global() uses the directmap for low
>> MFNs rather than vmap(), so this change has a small overhead in the
>> common case=2E Debug builds already used vmap() indirectly=2E
>>
>> With both paths using vmap(), vmap_to_page() can recover the struct
>> page_info * uniformly, so drop the 'page' field from struct ioreq_page
>> and update all callers accordingly=2E
>=20
> =2E=2E=2E here (at the bottom) is fully sufficient=2E
>=20
>> Signed-off-by: Julian Vetter <julian=2Evetter@vates=2Etech>
>> ---
>> Changes in v6:
>> - Updated commit message to clearly specify why these changes are made
>> - Added comment to say that this is {prepare,destroy}_ring_for_helper()
>>    just using vmap_to_page() + v{map,unmap}()
>> - Kept proper ordering in ioreq_server_free_mfn(), first clearing the v=
a
>>    pointer before unmapping
>=20
> Yet then you didn't extend the same consideration =2E=2E=2E
>=20
>> @@ -128,8 +129,13 @@ static void hvm_unmap_ioreq_gfn(struct ioreq_serve=
r *s, bool buf)
>>       if ( gfn_eq(iorp->gfn, INVALID_GFN) )
>>           return;
>>  =20
>> -    destroy_ring_for_helper(&iorp->va, iorp->page);
>> -    iorp->page =3D NULL;
>> +    /* Equivalent to destroy_ring_for_helper(), using vmap_to_page()=
=2E */
>> +    if ( iorp->va )
>> +    {
>> +        put_page_and_type(vmap_to_page(iorp->va));
>> +        vunmap(iorp->va);
>> +        iorp->va =3D NULL;
>> +    }
>=20
> =2E=2E=2E to here=2E (Really we should perhaps introduce VUNMAP(), much =
like we
> have XFREE(), XVFREE(), etc=2E)
>=20
> Further the ordering doesn't match destroy_ring_for_helper(), which unma=
ps
> first and only then drops the page refs=2E
>=20
>> @@ -162,12 +171,40 @@ static int hvm_map_ioreq_gfn(struct ioreq_server =
*s, bool buf)
>>       if ( gfn_eq(iorp->gfn, INVALID_GFN) )
>>           return -ENOMEM;
>>  =20
>> -    rc =3D prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page,
>> -                                 &iorp->va);
>> -
>> +    /*
>> +     * Equivalent to prepare_ring_for_helper() using vmap()=2E Using v=
map()
>> +     * rather than map_domain_page_global() ensures vmap_to_page() can
>> +     * recover the struct page_info * uniformly at teardown, which is
>> +     * needed to support multi-page ioreq mappings (see nr_ioreq_pages=
())=2E
>> +     */
>=20
> "is needed" is too strong, I think - surely there would be a way to hand=
le
> that without vmap_to_page(), by tracking all struct page_info * separate=
ly=2E
>=20
>> @@ -309,15 +310,16 @@ static int ioreq_server_alloc_mfn(struct ioreq_se=
rver *s, bool buf)
>>   static void ioreq_server_free_mfn(struct ioreq_server *s, bool buf)
>>   {
>>       struct ioreq_page *iorp =3D buf ? &s->bufioreq : &s->ioreq;
>> -    struct page_info *page =3D iorp->page;
>> +    struct page_info *page;
>> +    void *va;
>>  =20
>> -    if ( !page )
>> +    if ( !iorp->va )
>>           return;
>>  =20
>> -    iorp->page =3D NULL;
>> -
>> -    unmap_domain_page_global(iorp->va);
>> +    va =3D iorp->va;
>=20
> Please can this be the initializer of the variable, for the if() above t=
o
> then use that local var?
>=20
>> @@ -333,7 +335,8 @@ bool is_ioreq_server_page(struct domain *d, const s=
truct page_info *page)
>>  =20
>>       FOR_EACH_IOREQ_SERVER(d, id, s)
>>       {
>> -        if ( (s->ioreq=2Epage =3D=3D page) || (s->bufioreq=2Epage =3D=
=3D page) )
>> +        if ( (s->ioreq=2Eva && vmap_to_page(s->ioreq=2Eva) =3D=3D page=
) ||
>> +             (s->bufioreq=2Eva && vmap_to_page(s->bufioreq=2Eva) =3D=
=3D page) )
>>           {
>>               found =3D true;
>>               break;
>=20
> You mention in the description that some extra overhead is introduced=2E=
 The
> (generally) two page walks done here are particularly concerning=2E Sinc=
e we
> have a valid struct page_info * available here, I wonder if we shouldn't
> aid this lookup by recording the VA in one of struct page_info's fields=
=2E
> Afaics vmap() doesn't use any of the fields, so it should be relatively
> easy to determine a field to use for this purpose=2E The more involved p=
art
> would then be to make sure the field (in other struct page_info instance=
s)
> is also properly different from any VA vmap() may return=2E

Hello Jan,

Thank you again for your feedback! I will wait then for Anthony's=20
decision regarding whether the multi-page ioreq support and the ioreq_t=20
growth should be combined into a single effort, before I proceed further=
=20
with a v7=2E

I just wanted to clarify one thing regarding the overhead I mentioned in=
=20
the first patch's commit message ("this change has a small overhead in=20
the common case")=2E Here, I was referring to vmap()/vunmap() replacing=20
map_domain_page_global()=2E Where map_domain_page_global() has a directmap=
=20
fast path=2E I didn't mean the overhead of the added vmap_to_page()=2E I=
=20
should maybe clarify this better in my next iteration's commit message=2E

On your suggestion to cache the VA in struct page_info to speed up the=20
vmap_to_page() lookups in is_ioreq_server_page(): I looked through the=20
tree, and that function currently has only one caller=20
sh_remove_all_mappings() (in xen/arch/x86/mm/shadow/common=2Ec) and is=20
only reached in a failure case=2E Given that, and given how widely shared=
=20
and size-critical struct page_info is, I'm wondering whether it's really=
=20
worth touching it for the gain of not having to do the 2 lookups=2E What=
=20
do you think?

Thanks,
Julian

>
> Jan



-- 
 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vate=
s=2Etech
---=Part.2b1e.98ce00ae3019bacf.1a0394ac5bb.43e3200d7ca5731=---


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 14:26:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 14:26:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399262.1635414 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys6W-0002O0-R9; Tue, 25 Aug 2026 14:26:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399262.1635414; Tue, 25 Aug 2026 14:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys6W-0002Nr-Ly; Tue, 25 Aug 2026 14:26:20 +0000
Received: by outflank-mailman (input) for mailman id 1399262;
 Tue, 25 Aug 2026 14:26:19 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wys6V-0002Nj-C0
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:26:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wys6S-005Ym4-HX
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 16:26:16 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da5fc-8faa-0a2a0a5109dd-0a2a4502e6fe-14
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:26:16 +0200
Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da608-6ca4-0a2a45020019-d155da2bd09c-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:26:16 +0200
Received: by mail-ej1-f43.google.com with SMTP id
 a640c23a62f3a-c15cd3fd760so590907466b.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 07:26:16 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2496297c7dsm1767520066b.20.2026.08.25.07.26.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 07:26:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787667976; x=1788272776; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=izWfnk9aze89Z+Z4Dc7jlmjmkMhPkAe1QNXnL4qSw9c=;
        b=IzSKSfu1Gj0PW6u68y8pbbd2ZTMrHIzB354Tmwkbx8mIjoipr+/ETEB3nTFDFEJ7WI
         Qn99a35AqpXVVnlsBR+FJa9zcWnzpphaOuVjJS/uGdbziAwe7PQorkBX61sdJBZ3RFaW
         cuAzG9+G3izLwG4GcAnsg82CgzeCichRkfQyu4al+a1oNNUYu8ne9ZFjuS5r3PE/5LUA
         aVbOsQFwms6PBZe0DEEBSJ72T4Opdwoj/PS9e55v33QiB4fTwIvaUBQvmb+y7sGNlNWG
         dS53JfwsnlPqHQMfsf7QqlTn2nFPtHshPzBkFI7inrBdvdaQOlS0xnWS/9lMeEvK6ohE
         vxQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787667976; x=1788272776;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=izWfnk9aze89Z+Z4Dc7jlmjmkMhPkAe1QNXnL4qSw9c=;
        b=IdrvJBaxw/ucSNT3QKGkzEO3zfb8MEfBKTQ9A8T0gLSVxFkmYaFhVqVr6AvSQbBjTC
         xgf6X6vGx8GIeuSIFkJPjLHCaohkKrRklFTEp8ZIpRjdTIyLQySj/EeAn4kVb03EfjQF
         K8RVQPs7QHQL/nEMaVFyx04fiGOvZ6Da4MAas5v5Fa2dWzWVA/XPDO/DSHB7Ar83N9GU
         uHdfAN2LOXtlJtfIRdm1h2wLJLy+6zZkuwVcQIDkM67n3pK/lbKGhlrvSxUemO6kLnfc
         +ztmQ3iswPCInw4UQ9xPFPcRki70BtxAejEEaIFfHlCHbfl2TwgoXSU4mHwZomjUCTFt
         R0Gg==
X-Gm-Message-State: AFuF++n7KaH/lZkHSx2QRMqeGc71JeWyFxUoSImavMPRwCzDcwQsLOBG
	2AdlvjEnoELJ4Y53RyrRST+kktGW/g6PNeCByApcTXxp7JzUr0lzbg5jNMpvwDufbxBV13Qvbyh
	nZ8f8Bw==
X-Gm-Gg: AR+sD10VtAkdcNQyoJFoCW2WrZPxaoyyK6TeWzoeuY88Ytt8n9WtE7C7RneAQ74HrtG
	GCAXfG6dLNBwXbcfu/s/kvXM6lw1NSq0S5oExhmm04YFfGOQ3cOoEkjFxf1yQL+PLk9S0oPWlQU
	wPdVrqwianpAnexoobWl58f3LolxICpmpMq90zWpCfbVX3yKE8oJQkf3t74FRpeoPodYPbZKxdj
	a88bOpNn9k5PRKcktF72ARV6SSnvLMO/v40PxYSq6d7B6gO5U4Rf1bdVpWDhxqKXsItP00j/6/k
	i6rpzOg00++3Pv2j+zkGPak3FHm25EGVEsQAmKMNR7s4NMEEADsFj+nPRSmaHuLBIzYH9j0aaSE
	F4S1Up1f46p4od7jJ8KExyyx/1R0RdCqcaqP2Cuxz4KVaFy9ttglyyUWrxP1OyHNEMr2VZmyEh1
	jFJBLfqlrCNjPqNrDjgA7/zd1bmisPRBriFgqB3VEcWrLjqWxF3EEAQH/Whhsh/MlmpQmP+6oy1
	13ZfhYjKR54aq0xSzmyhjYHEhX4Vo4jyRhYdvVgOBMDlxhdNKXqF20fEtJjeAo=
X-Received: by 2002:a17:906:6312:b0:c24:6445:d19 with SMTP id a640c23a62f3a-c24926f3cf9mr3326881766b.17.1787667975854;
        Tue, 25 Aug 2026 07:26:15 -0700 (PDT)
Message-ID: <bd5ed50e-e537-4033-b5b9-98167886690a@suse.com>
Date: Tue, 25 Aug 2026 16:26:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 0/2] symbols: aliasing at text section boundaries
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787667976-F36BF2AC-AFB3934C/0/0
X-purgate-type: clean
X-purgate-size: 135

1: drop _{s,e}extratext
2: also special-case symbols aliasing _sinittext

v2: New 1st patch, simplifying what's now patch2.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 14:28:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 14:28:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399268.1635421 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys8b-0002uj-3R; Tue, 25 Aug 2026 14:28:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399268.1635421; Tue, 25 Aug 2026 14:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys8b-0002uc-0O; Tue, 25 Aug 2026 14:28:29 +0000
Received: by outflank-mailman (input) for mailman id 1399268;
 Tue, 25 Aug 2026 14:28:27 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wys8Z-0002uW-Kp
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:28:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wys8Z-00AFOK-1Z
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 16:28:27 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da689-bab6-0a2a0a5309dd-0a2a45018ca8-8
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:28:27 +0200
Received: from [209.85.208.51] (helo=mail-ed1-f51.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da68a-5984-0a2a45010019-d155d033a44d-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:28:26 +0200
Received: by mail-ed1-f51.google.com with SMTP id
 4fb4d7f45d1cf-6a3819e8be8so1938409a12.0
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 07:28:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5de8b6412sm14817a12.2.2026.08.25.07.27.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 07:27:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787668106; x=1788272906; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=nqPzEpldMcM/b3Zq3teNAXBIm5xTZsMOW+hKxk/P+ws=;
        b=DP+5OWDKgTEKiROOcPNeCXG/OUFGf1/Kq+7CeeEfrlCWXs6Hb7WwL2Dw3X8K/MyBaZ
         a2uNFJs5EQlUuQNUXJnzmj0mLQBho8I8V7c0I92zAUq/vRQOnr33hJgmvoXzDuH3XWqm
         O2jUM4bjkbFVkn71bG5XibgMswQIueG/TD/Bg8IFTRVa2L6BXj25+6Vxatf/uKDU3ell
         ODJcKYBjbAyUlIPwp28xwYPRDN9lg/6BW1YgLoEKciw21v58yMgqWoXTuXiuoB7SVPvM
         T6akrSkzji8nhaxHYOQMxMNPh8KVwwpO/7+FGiAnYwFx0ZGg539HB4GHsNhQLC7P8hEr
         CysA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787668106; x=1788272906;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=nqPzEpldMcM/b3Zq3teNAXBIm5xTZsMOW+hKxk/P+ws=;
        b=moJCxsFsjyMqcNNd47JISn7/BWiIVcKFxjG5cz0FWmMeqxRIX6YymGtgQRXFYL4zUq
         RCNNZQz7TwqJ0qGhVO8Ge2U/73l9v280z0CzbQ1dnKa5Rv/grFTQjU+YTjxH2uTl+oSh
         Law9HP+SsR+iglTb1QyDQtAR5qQjUKFtBCLJDJlJxEs7I42gEQ3PqFdm1qp+7yzpUi1e
         q68xu25YCSaFZXo04G4pw82DxDTTmm5dLGddhLhv+4Nyb5T/K0L2+qh2yhm6ZIfBMeHk
         x4ZKKGdfHVFxpFwRrysYaMwvZtjU52h15+C43KF+JwGg40JGTRQlD8+vW4MOZEKlAgxI
         iosA==
X-Gm-Message-State: AFuF++mTln5ywO4eucllhFsbORHPfPRUKKun9bIFmmtB/FAt0b6NIINt
	exgSVHMkRDVh7eJExnK/TDdYq9KTt5ajaDBGPRHveYLeT/tPjQ+PoH9YBGy60ojJKNg+ppyM1zh
	+x9rGhg==
X-Gm-Gg: AR+sD10Tpib6O8CCYB/QHu2ZjbqofL184JpNSApWq1yfUgtiprJUBNXefI0J4E/aOJ9
	wfO0a+obb1cu8DBX5GBEtevoy3Rl6y81ipgZ9JiUIAd9QFDxTg4uM019ecf9A1l3RCFB3RP5l4l
	xnxZlaqR9vZ47VOLGl3JL+XxZKNq2uSGCVUfXav8uwGBSQ51tAY+J+xBJLQx2+V1zmI6yHH93o6
	LQJ1g12GxOG7GM06EFKjlR9oRpcg4cJZ7vbyJoGZDqD/4NfA7aBJLgHti6A+o+9+lk5YhKfaBpP
	Ish2/D3DtzRfl5MWB4E1wiFxPzcjr1AB6C9EjB0PZo3neyGzQNiMOotc6ZZuB71+ZVclgBkTtMu
	J/MrMDIF6e0I62Pzp15UjJfHDBoyPrUG2704PcWJ1XfGYIKUfY7nzZRv7OHbwVNr2EqRxcQF78z
	V+baPdqOZZ7q+vzruDlO0RLMCB4GG6mwf2gLGOO+kU9bdpPhCMvQ9+6N4Z6iWZQF0JL11NI8PJm
	aa4duknkSmm2c29DCjdKETzGtvskdYnYPUzL5wTQkTv+JPOCB8X
X-Received: by 2002:a05:6402:504c:b0:6a5:d8f0:dc0d with SMTP id 4fb4d7f45d1cf-6a5d8f0dd7dmr2529001a12.8.1787668106595;
        Tue, 25 Aug 2026 07:28:26 -0700 (PDT)
Message-ID: <69cbb2b8-8fed-4aa0-b1c6-0cbe135cb062@suse.com>
Date: Tue, 25 Aug 2026 16:27:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 1/2] symbols: drop _{s,e}extratext
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <bd5ed50e-e537-4033-b5b9-98167886690a@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <bd5ed50e-e537-4033-b5b9-98167886690a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787668107-1E465757-FE55F059/0/0
X-purgate-type: clean
X-purgate-size: 2250

We're only about 18.5 years late with this: See Linux commit a3b81113fb66
("remove support for un-needed _extratext section"), i.e. from the 2.6.25
dev cycle.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -52,7 +52,7 @@ struct sym_entry {
 
 static struct sym_entry *table;
 static unsigned int table_size, table_cnt;
-static unsigned long long _stext, _etext, _sinittext, _einittext, _sextratext, _eextratext;
+static unsigned long long _stext, _etext, _sinittext, _einittext;
 static int all_symbols = 0;
 static int sort_by_name = 0;
 static int map_only = 0;
@@ -148,10 +148,6 @@ static int read_symbol(FILE *in, struct
 		_sinittext = s->addr;
 	else if (strcmp(sym, "_einittext") == 0)
 		_einittext = s->addr;
-	else if (strcmp(sym, "_sextratext") == 0)
-		_sextratext = s->addr;
-	else if (strcmp(sym, "_eextratext") == 0)
-		_eextratext = s->addr;
 	else if (toupper((uint8_t)stype) == 'A')
 	{
 		/* Keep these useful absolute symbols */
@@ -210,18 +206,16 @@ static int symbol_valid(struct sym_entry
 	 * and inittext sections are discarded */
 	if (!all_symbols) {
 		if ((s->addr < _stext || s->addr > _etext)
-		    && (s->addr < _sinittext || s->addr > _einittext)
-		    && (s->addr < _sextratext || s->addr > _eextratext))
+		    && (s->addr < _sinittext || s->addr > _einittext))
 			return 0;
 		/* Corner case.  Discard any symbols with the same value as
-		 * _etext _einittext or _eextratext; they can move between pass
-		 * 1 and 2 when the symbols data are added.  If these symbols
-		 * move then they may get dropped in pass 2, which breaks the
+		 * _etext or _einittext; they can move between pass 1 and 2
+		 * when the symbols data are added.  If these symbols move
+		 * then they may get dropped in pass 2, which breaks the
 		 * symbols rules.
 		 */
 		if ((s->addr == _etext && strcmp((char*)s->sym + offset, "_etext")) ||
-		    (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")) ||
-		    (s->addr == _eextratext && strcmp((char*)s->sym + offset, "_eextratext")))
+		    (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")))
 			return 0;
 	}
 



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 14:29:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 14:29:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399276.1635431 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys9Z-0003OZ-BS; Tue, 25 Aug 2026 14:29:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399276.1635431; Tue, 25 Aug 2026 14:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wys9Z-0003OQ-8M; Tue, 25 Aug 2026 14:29:29 +0000
Received: by outflank-mailman (input) for mailman id 1399276;
 Tue, 25 Aug 2026 14:29:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wys9Y-0003OI-IB
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:29:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wys9X-002uBq-VD
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 16:29:27 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da6bc-8faa-0a2a0a5109dd-0a2a4501d396-22
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:29:27 +0200
Received: from [209.85.208.54] (helo=mail-ed1-f54.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da6c7-5984-0a2a45010019-d155d036f132-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:29:27 +0200
Received: by mail-ed1-f54.google.com with SMTP id
 4fb4d7f45d1cf-6a3fda88184so7391946a12.3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 07:29:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c24968d5f59sm1785070966b.63.2026.08.25.07.29.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 07:29:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787668167; x=1788272967; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=LwGdXU8fMsj4QrOOPPW6ftweTPADKeSV8stRdnz5RIQ=;
        b=L1oCRw9/ROYhxJrMXqNnTjOGfLM2hZd0g30uhjXLvchkTPMS8vARz34ylFYRwVq9Vr
         /HE8jwGP1q8q47VH6Cglx2/xJstVPSOpic/MS36JpXfQbGMGLVAsgGZWhkaimRQNV/7r
         f5hnrB6cx96Yy1+9nwEUkh5R+yGG2j+XpjBcUutBHsxU8NgmOYRmtXLWCBtKrr/xC9fb
         27BAPB/+7pzmuU5szy/79DPn4go7K+kbdi3zKSbEyprGDbkJZSHe+0sq5dIkOzfinKJp
         1Gwc69qoTtuhgQOK13U0z+vi9ZZRqBNqDpfiUIDG8bnC4ljoQdX4csJTy21QP+USxqD3
         /PCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787668167; x=1788272967;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=LwGdXU8fMsj4QrOOPPW6ftweTPADKeSV8stRdnz5RIQ=;
        b=GkgjQCOo9jTbRKC9ZkVrn3uIkKcrzZO+GRPk/ySA2qN9SD5foOcdZV0gwxLFpSiNjs
         kWPa/B2LCD6e5mSCxtw0xsh5yWmV071K+mU2F/Q6se8PwQyaee52hpsQF6yLr1Xv7JW+
         XpcWgwvJ7wbRp+Ndt1zctLKuhqnJw1F2z+WaJ7rlzdwQ5lqpu8J0eJ1IxKz/qVlo/p6+
         1j0UgH131AhZCVFFnRjngKfv02OrxMtQhNzEc62vg6NzytqjugOfThBWrJQSP54WPqHl
         IU9YyjQZtCP8el1Cchas1z+Pai8Ri71e0mRLhbrGvxxQFTp6fu/IGANbloBeqT0SA6z1
         ItMw==
X-Gm-Message-State: AFuF++kOAqAiA1ULW9icHka3oYiKEpXDUyqP0dgXwn+pafJbfuZg4GVG
	XRW0GJtghNjCLFcwLz19k261RJRIILxKjLA1wr5zMyCymVD2/a36SIVvLdZwJ5FnerDQNSEsJ48
	ZPyI7GA==
X-Gm-Gg: AR+sD13bEiSObXxwyVrVX6fyk+ukyEFY6A+R9gMm2Y1bauXsumC9MX7JRo93KdLEw7/
	PFX0M3NApL/aINHWw3FE6v7Ywl1T0DoFJIrEciKK3TDV710iMUmcbH8f3OesJLq+uVCQaVmjSBf
	lqSSR3J+lJS7vj60D1nh/3Jl72Itb9dX4j/akIsERscu4UovhIAmdDER5X+petd1YJsFxWGhjgI
	Os4mJIhzFRLlpSsEizwWX6SgOoiLqqZO6vElbDvlKfZAWkFUpTA/C0OKo56rLGVN3P/Lh0cHd9E
	VNYBYVR3AC3Oc8639dWTz1Zwx642URhFv8m4Ds4ZJlDv74huSMcE8ob40Myq7DTsesFdIeo8/Fl
	GQrIdxbEoBxlGvgLggW2lfaLX5JFRAZ/RjYjN/O17E1gU9G56KIBm/r5JhbQ8h7eKyuFlWd6IZd
	zag5tFoU+wAlCfwHQoOYycSacceJAuNCn3I22eGd5cj7m09eCbZ9pJkiWf+q3AgjUHU5MlzIoYn
	m9wWrS0q7SiHUMSCMn0zHYdKaoGOsFHmNhshhrvopPznmVOVClp
X-Received: by 2002:a05:6938:a089:20b0:c25:379:f37b with SMTP id a640c23a62f3a-c250379fa26mr237718966b.13.1787668167330;
        Tue, 25 Aug 2026 07:29:27 -0700 (PDT)
Message-ID: <fd7dc2f7-6505-42e2-8eaf-fb8e9af21bd4@suse.com>
Date: Tue, 25 Aug 2026 16:29:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 2/2] symbols: also special-case symbols aliasing _sinittext
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <bd5ed50e-e537-4033-b5b9-98167886690a@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <bd5ed50e-e537-4033-b5b9-98167886690a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787668167-BE27A757-4EC6F454/0/0
X-purgate-type: clean
X-purgate-size: 1190

A recent 4.22 randconfig build job hit a situation where (LIVEPATCH=n,
i.e. --all-symbols not specified) both __note_gnu_build_id_end and
_erodata aliased _sinittext on the 1st linking pass, but they didn't on
the 2nd one. As a result two fewer symbols were emitted on the 2nd pass,
causing $(call compare-symbol-tables, ...) to fail.

Extend the existing "corner case" by also considering aliases with
_sinittext (_stext really shouldn't have anything ahead of it), but
discard only non-text symbols.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Re-base over _{s,e}extratext removal. Add const to cast.

--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -217,6 +217,11 @@ static int symbol_valid(struct sym_entry
 		if ((s->addr == _etext && strcmp((char*)s->sym + offset, "_etext")) ||
 		    (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")))
 			return 0;
+		/* Same for non-text aliases of _sinittext or _sextratext. */
+		if (toupper(*s->sym) != 'T'
+		    && s->addr == _sinittext
+		    && strcmp((const char *)s->sym + offset, "_sinittext"))
+			return 0;
 	}
 
 	/* Exclude symbols which vary between passes. */



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 14:41:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 14:41:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399286.1635440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wysKm-00069N-CW; Tue, 25 Aug 2026 14:41:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399286.1635440; Tue, 25 Aug 2026 14:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wysKm-00069G-9i; Tue, 25 Aug 2026 14:41:04 +0000
Received: by outflank-mailman (input) for mailman id 1399286;
 Tue, 25 Aug 2026 14:41:03 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wysKl-00069A-0e
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:41:03 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wysKk-004zYK-37
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:41:02 +0000
Received: from mail-yx1-f41.google.com ([74.125.224.41])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wysKk-009gMc-21
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:41:02 +0000
Received: by mail-yx1-f41.google.com with SMTP id
 956f58d0204a3-66d07ddf077so3622624d50.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 07:41:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=zZqurIMiQ8XRcdYQqTxXeKAok7x6pdmHT8SXFDedHMo=; b=ceVLHMHEZUYiykGAZxyClZrtEN
	8u6NKuRr2xeNVOCm8sNHnN3Dx4Zo9hk9S3zZLqZBSh0e7TEzG2adHDFwhyL1dpr6Dt7tRmI5Pm//X
	uB+Kiwxyn++xzI+u8J+CeXXCFAawPGzf7ypvlS+5GsQ+cCwDFPwgkwF7cj2lWD5I1vEg=;
X-Forwarded-Encrypted: i=1; AHgh+RrkelFwstXg97omnpUe/0qQ6KTXrGkAj+LguPer+ag5CwVQO0bmQzyi1nxeARPWl/8im+2UyeHfMDk=@lists.xenproject.org
X-Gm-Message-State: AFuF++lkyelrxD0BnCIdgAeIByAgY7sHDbUe39pnRvnaxaVMhJZgNiTH
	NRLm/Ik9oaQWYvvMQ088cgsAUenVOqtqUWHH8Hsbj8VE6UqXsFtPFhsZtNwdEvNkTutCrG4I7WG
	YcS/0I1N4ZJc/5SwvLruegKOM2uCSL0k=
X-Received: by 2002:a05:690e:120c:b0:66d:1a5a:1d27 with SMTP id
 956f58d0204a3-66d1a5a1ecdmr1885941d50.12.1787668862196; Tue, 25 Aug 2026
 07:41:02 -0700 (PDT)
MIME-Version: 1.0
References: <20260820-asi-part1-0-f2dbd92b8459@xenproject.org>
 <ec040560-4377-474d-a929-3080b74bb0af@suse.com> <CAFLBxZbQD7HgdYK3-yzaMOt4P2geO2PSOSDi4-c3KHZ96DDifg@mail.gmail.com>
 <044095b7-3c8d-40da-9d21-281c522a49ae@suse.com> <CAFLBxZa0Fmmic1JLwHOdFCn1=rGP6Un2q1ZxBa1DpsO_AAmD6A@mail.gmail.com>
 <f34b38e3-4f77-49e2-a69f-aea153f53787@suse.com>
In-Reply-To: <f34b38e3-4f77-49e2-a69f-aea153f53787@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Tue, 25 Aug 2026 15:40:48 +0100
X-Gmail-Original-Message-ID: <CAFLBxZZKyuXc0j08Q9wqsHXVGD1LPSLB=Fxx6XLFsBQgzjrOmw@mail.gmail.com>
X-Gm-Features: AcwNN1Wc9W-MLBwND-XdCKd5XmrEINpG2L0AcF0qEOn3XZC3C8UxPLggJ6PUilU
Message-ID: <CAFLBxZZKyuXc0j08Q9wqsHXVGD1LPSLB=Fxx6XLFsBQgzjrOmw@mail.gmail.com>
Subject: Re: [PATCH 0/7] x86: Address Space Isolation, part 1: per-domain area
 mapping rework
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 25, 2026 at 2:28=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wro=
te:
>
> On 25.08.2026 13:42, George Dunlap wrote:
> > On Mon, Aug 24, 2026 at 10:02=E2=80=AFAM Jan Beulich <jbeulich@suse.com=
> wrote:
> >> While these percentiles in particular of course look very tiny, they a=
re
> >> applicable only on systems having no meaningful gaps in the physical
> >> address map. And even more generally I find all of these calculations
> >> only partly convincing, not the least because you start out from numbe=
rs
> >> which look pretty contrived when comparing to actual systems which wou=
ld
> >> run the new code. (Using more realistic real-system values may end up
> >> going in favor of what you want to convey, or it may not.)
> >
> > To be honest, I'm inclined to think that they're not very convincing
> > because you don't actually have an idea what the problem is.  You
> > didn't specify what you were worried about, so I tried to guess a
> > scenario that I considered 95th-percentile worse case.  I don't know
> > what kinds of sparse memory layout machines you have in mind -- are
> > they written down anywhere, so that contributors can read and
> > understand what they need to consider *before* implementing?  Even now
> > you haven't even said what about my scenario you consider unrealistic,
> > much less told me parameters you think are more realistic.
>
> What I specifically considered unrealistic is that you use huge pCPU and
> vCPU counts. Yes, you're trying to do a worst case estimate, yet at the
> same time you're assuming huge amounts of memory to be available (which
> doesn't represent a "worst case").

Let me point out that you still haven't named exact numbers -- you're
still offloading that to me to try to guess or imagine.

The v1 series I posted adds a few pages per vCPU and a few pages per
pCPU into the xenheap. The problem is using up too much of the xenheap
address space.  So obviously to make a reasonable worst-case that
you're not going to dismiss as contrived, I need to maximize my pCPU
count and vCPU count.  pCPUs is easy -- we're documented as supporting
4096.  How many is a reasonable number of domains and vcpus?  Well, in
general, pCPUs are an effective limit to how many vCPUs you have total
on the system; an 8:1 vCPU overcommit is high, but not preposterously
high.

I don't understand your point about huge amounts of memory.  If you're
talking about *total RAM used*, it doesn't matter whether it comes
from the domheap or the xenheap.  The only possible reason to say
domheap is OK but xenheap is not is if you're concerned about RAM
above the 4TiB boundary.  Which can only happen on system with large
amounts of RAM, or systems with really sparse memory layouts.  Does
the analysis really change at all whether you're using 12TiB or 6TiB?

> As to sparse layouts - ones which have led to the two forms of PDX
> compression are well known (I think). The need for more recent (offset)
> form is a good example of what could go wrong here: New machines can
> always come with new layouts, potentially requiring new compressions
> approaches. So what I'm concerned about is effectively _any_ sparse
> layout that we may encounter without having a suitable PDX compression
> method readily available.

"There may be some new layout that doesn't compress well" -- it's not
uncommon for random bits of new hardware not to work well until we
supply a patch to fix it.  The position you're supporting is
effectively: "We must absolutely avoid a situation where some unknown
system is temporarily restricted in how many vCPUs it can create due
to a sparse address space, even if it means making the context switch
4x as expensive for every single current user."  I just don't think
that's a reasonable position in any shape or form.

> > I don't even know exactly what failure mode you're worried about.  Two
> > kinds of potential failures I know about:
> >  - Performance impacted because pages can't be NUMA-local
> >  - Toolstack operations (including domain creation) fail because
> > xenheap has been exhausted.
>
> One thing I can't help thinking you keep overlooking throughout your
> reply: xenheap and domheap aren't separate. There being only a
> relatively small part of it needed for the worst case estimate you did
> means nothing as to exhausting the xenheap in practice: Almost the
> entirety of it (with the DMA reserve being somewhat protected) can be
> used to build domains. Once in that state, allocations would fail no
> matter that large swathes of domheap might (have become) available
> (again).

Right, so if Xen allocates too much domheap from the directmap region,
the xenheap may be not be able to allocate any more, even if there's
plenty of memory.

So something like the following:

We have 8TiB of RAM, 4 nodes, 2TiB per node.  The user wants to start
4 2TiB guests, one pinned to each node; so she starts d1 on node 1, d2
on node 2, then tries d3 and can't start it because although there's
still 4TiB of RAM left, all the memory below 4TiB was handed out to
guests already.

Is that what you had in mind?

If I didn't agree that the xenheap represents technical debt that
needs to be removed anyway, I'd say a simpler solution would be to do
do some simple xenheap reservation, based on various factors
(including number of pCPUs, and the total amount of RAM).  Reserving
6GiB on an 8TiB system would have very little impact (the first guest
would either need to be a bit smaller, or have, and would make the
whole problem go away essentially.  The first guest would either need
to be less than 0.1% smaller, or have 0.1% of its pages on a different
node.

> That said, with what you indicated at the very bottom of your reply,
> it looks like this part of the discussion has become largely moot.

Yes, but I also want to challenge your operating principles -- to get
you to state more clearly what you're concerned about.  Also, in order
to either get you to relax a bit about the xenheap growing, or to help
you articulate more clearly what problems which contributors need to
address.

 -George


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 14:43:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 14:43:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399293.1635448 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wysMk-0006fV-O3; Tue, 25 Aug 2026 14:43:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399293.1635448; Tue, 25 Aug 2026 14:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wysMk-0006fO-LD; Tue, 25 Aug 2026 14:43:06 +0000
Received: by outflank-mailman (input) for mailman id 1399293;
 Tue, 25 Aug 2026 14:43:05 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wysMi-0006f8-Vj
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 14:43:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wysMi-000tev-Cc
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 16:43:04 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da9e9-8faa-0a2a0a5109dd-0a2a4501956c-18
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:43:04 +0200
Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8da9f8-5984-0a2a45010019-d155da2bc58b-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 16:43:04 +0200
Received: by mail-ej1-f43.google.com with SMTP id
 a640c23a62f3a-c2074710751so884685866b.1
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 07:43:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c2496297189sm1755855566b.22.2026.08.25.07.43.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 07:43:01 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787668984; x=1788273784; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=w9ohPoMvB1GBbUcpCPI8mlfQmj/aqTcFkYWbjjT18W8=;
        b=FUNxraqyS2uNS31ibQaUNmGr32JlG/BJ0z1wxnwXiYuauGzdPuAXL2/daZvVi8ED5Z
         BfoxuZdDdXk3HTdMjxRoRNgkUdyN5EU3582xvtRlXb7l35Jte6edd/euNK5thrlS/WH6
         aC80y5B6+p0XSWRx7KeBAsG6YMDyB8NDR4XqSBu7Z6+ghKgq6fXZ9z6bOPN+42lW9MRy
         HPfg1jaoTUV3ceGEZZGlPRO7Lf1ZvYKwXzBu74j2mJJR8anGRBSZ7x1KkD4SOQQ4wVeK
         0VOGQ/dN2yuQzUvr2fp6g525j6xNNDGpNTnJ9fD76DNDHs7cAZPht570EDX3U0Juc1xl
         Orxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787668984; x=1788273784;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=w9ohPoMvB1GBbUcpCPI8mlfQmj/aqTcFkYWbjjT18W8=;
        b=iNhlOKMsqTZQkHv8D6MXVuI4Tvpi9bz3bPSIehov3LN03yZnlaDgn823099Sxvp1Pi
         bu0dT/UgQA6bOdsMKbukTFr5RLl2UIFK7YqbW9qF6wOnfK3TnlGNU72XI5r7x+coQG9U
         ba+qAOaLrMNY9L4XVKtfgFll+FXKWvBPcaJMPrEZ++Qge4AEO97l2HuF1MMLFhRPpDWX
         tN/ToiX0SPpD5hY07X0T7ToDUkSWuwLfrIndaIWd9aCMajc0zhtGfOOJ0VbxVsbKvmdm
         wMKaigd9cBTWt7VsYxADNYjJ6chtoxR4ek6ZbVHzx8RotOO8dTzch+t8qZ7jXPYxeUnT
         nseg==
X-Forwarded-Encrypted: i=1; AHgh+RptEVSWbzRUcap8+D50XqLsd7wZvSI7uGIRAAvJc3U8U2khvvp7/4uy5bL4XKUnxy2qKwp1P9SOtPk=@lists.xenproject.org
X-Gm-Message-State: AFuF++lcSpP4uh4dhmr9MdujeUhOBgY7TVcl058YQy5B8rGNu5jOCyZQ
	1QlXPVcVhnVLz7aoBpvjjB056KM2q/3GfODUIrJXgPMOsaxjK5BIdQfPvIoY/ww3uw==
X-Gm-Gg: AR+sD10rDBv6ggwZYSRrJExPxK5hwMwLvi1+eIvG2v2OYUzEvkNmy9BnPqh8wSl5ANq
	mPvtzI7E7ZelLJayZrRvklbNGrlMMNm5rJohkSzagYijLBPSxrsfhbggyB9LC8XSeU5QIh78RgU
	TyUymsfLwUCoselaVZXQDkT+wbgQUjbSQck2VUvXC+gjE2sbGhR4UqAbySp/F9JYkb3QptLK4vj
	ucI8kegfprqxWyxzKDOE8Ey5X0XOnh75utdK3ENFwvC/miA2Y0/lBALgfSzbkxIYqRlEElHlvJp
	FeiUWVqKQFQ+5+sT7RInTk7v+WBco2m/Dq8l76Vadh+GUMYHPG/KIPfxhAo9LHQUyUdljkrhh3d
	ox7Kw7fI4/USGW9BW95pf8wGwCsvHhkBqNBBqgp1HiBw+DK16YYdWGxuXMZA/EOBboa5xlYEPT6
	irqPd74zufX7FB4tpfNkackWfP+wW9HokhJjxQCyUscBC3IyZ6gR825eXvrWkxdw5KbJSUVSkFo
	wrW7zYw+0MnnnHwgPe0ZNO12ST522mmlNbOd7fiOuT1ftMYlbQy
X-Received: by 2002:a17:907:e009:20b0:c24:e0dc:8b66 with SMTP id a640c23a62f3a-c24e0dcd3d7mr746836466b.6.1787668983779;
        Tue, 25 Aug 2026 07:43:03 -0700 (PDT)
Message-ID: <6dff46c2-443f-4b9f-bdd9-de3017becca9@suse.com>
Date: Tue, 25 Aug 2026 16:43:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/3] ioreq: switch ioreq page allocation to vmap
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <20260420093820.825969-1-julian.vetter@vates.tech>
 <20260420093820.825969-2-julian.vetter@vates.tech>
 <35a08d22-1e95-4e02-a7e9-7f392ef11722@suse.com>
 <1787667597.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1787667597.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787668984-BCB45757-2783207F/0/0
X-purgate-type: clean
X-purgate-size: 2812

On 25.08.2026 16:19, Julian Vetter wrote:
> On 8/18/26 3:06 PM, Jan Beulich wrote:
>> On 20.04.2026 11:38, Julian Vetter wrote:
>>> @@ -333,7 +335,8 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
>>>   
>>>       FOR_EACH_IOREQ_SERVER(d, id, s)
>>>       {
>>> -        if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
>>> +        if ( (s->ioreq.va && vmap_to_page(s->ioreq.va) == page) ||
>>> +             (s->bufioreq.va && vmap_to_page(s->bufioreq.va) == page) )
>>>           {
>>>               found = true;
>>>               break;
>>
>> You mention in the description that some extra overhead is introduced. The
>> (generally) two page walks done here are particularly concerning. Since we
>> have a valid struct page_info * available here, I wonder if we shouldn't
>> aid this lookup by recording the VA in one of struct page_info's fields.
>> Afaics vmap() doesn't use any of the fields, so it should be relatively
>> easy to determine a field to use for this purpose. The more involved part
>> would then be to make sure the field (in other struct page_info instances)
>> is also properly different from any VA vmap() may return.
> 
> Hello Jan,
> 
> Thank you again for your feedback! I will wait then for Anthony's 
> decision regarding whether the multi-page ioreq support and the ioreq_t 
> growth should be combined into a single effort, before I proceed further 
> with a v7.
> 
> I just wanted to clarify one thing regarding the overhead I mentioned in 
> the first patch's commit message ("this change has a small overhead in 
> the common case"). Here, I was referring to vmap()/vunmap() replacing 
> map_domain_page_global(). Where map_domain_page_global() has a directmap 
> fast path. I didn't mean the overhead of the added vmap_to_page(). I 
> should maybe clarify this better in my next iteration's commit message.
> 
> On your suggestion to cache the VA in struct page_info to speed up the 
> vmap_to_page() lookups in is_ioreq_server_page(): I looked through the 
> tree, and that function currently has only one caller 
> sh_remove_all_mappings() (in xen/arch/x86/mm/shadow/common.c) and is 
> only reached in a failure case. Given that, and given how widely shared 
> and size-critical struct page_info is, I'm wondering whether it's really 
> worth touching it for the gain of not having to do the 2 lookups. What 
> do you think?

Hmm, indeed. Yet how would we prevent new uses from being hit? At least
a comment may want adding somewhere (where it's not too easy to overlook).

That said, why the mention of "size-critical" when I said "determine a
field", not "add a field"? (Really in different context I've suggested
the same as a possibility to George, for his ASI work.)

Jan


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 15:26:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 15:26:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399317.1635459 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyt2B-0003bA-QR; Tue, 25 Aug 2026 15:25:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399317.1635459; Tue, 25 Aug 2026 15:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wyt2B-0003b3-Mh; Tue, 25 Aug 2026 15:25:55 +0000
Received: by outflank-mailman (input) for mailman id 1399317;
 Tue, 25 Aug 2026 15:25:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marmarek@invisiblethingslab.com>) id 1wyt29-0003aw-NG
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 15:25:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wyt28-009HRo-5q
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 17:25:52 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a8db3fa-bab6-0a2a0a5309dd-0a2a4502d858-6
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 17:25:52 +0200
Received: from [202.12.124.154] (helo=fhigh-b3-smtp.messagingengine.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marmarek@invisiblethingslab.com>)
 id 6a8db3fd-6ca4-0a2a45020019-ca0c7c9ae11b-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 17:25:50 +0200
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 9324D7A012F;
 Tue, 25 Aug 2026 11:25:48 -0400 (EDT)
Received: from phl-frontend-03 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Tue, 25 Aug 2026 11:25:48 -0400
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 25 Aug 2026 11:25:47 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm3 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm3 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm3; t=1787671548;
	 x=1787757948; bh=UOtbtAmf2ZFQ9HUbrtpF8rOLiDXRmAvIzLZdI5iFIoE=; b=
	NvFs7YDg/qo0/MeQCDLCS6yfXwv78/rv+XMv8mAt8D6yhji3mqBsUW9L09XSIaN4
	czeNSaX+R9MWM3IRY0kmINW68qz90KC1MnSADCE576Z6dC5Ix1ZQvj1r+bnyLMcx
	Tv/P4f4IslhQAG011fH+FHRXqUFU3rKPSHtQ+X2BfSfxmaJ5KVXN+CJhO0WDaDT+
	l3Tr5FlvC7fWsRzM9NEhKZyazLULlqOrudALEh5JVB+phaAxTMLXmxfsKBjpPA1X
	93iOdqFKZH5iv++wberNC2+7EQqZKshm8th1c7lKepk5NMRqUhioEp9vFaDwqQ3i
	vB+sVwxznVMq74rBcuyNmQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:subject:subject:to
	:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=
	1787671548; x=1787757948; bh=UOtbtAmf2ZFQ9HUbrtpF8rOLiDXRmAvIzLZ
	dI5iFIoE=; b=Pz7Np16GfPANcEZhdyQ2hZe9vUF6sA9vZ0LjpTgG1g6EdPPp91w
	fn7VAbZqF+dfkvBdoyAHm4uOBV385Kd9eJm/zUWvOWa/OjYBCFZez/YChOfkUgPq
	PfS+prJwZoy9b0/Cv8k2bj81GpuxkKLRnyl6djUrRDNxdhGpm7my4JFrENGdp0Ju
	DAmV5RLz8xmQEA+6mwQBzxzJR+ksoMXJnFDqpZcpdwXE3ueOftyJv53+Hf95Go2D
	9XrHsa1YYvUrd+qYAKuUoK+kmLOmjuLeDGMXz3dGZB7yFUlkOK9bzmK7G/mkLx/b
	jwrTQVvw8HONx29YYjXRy1k3Gb8OJtjQIaw==
X-ME-Sender: <xms:_LONapUXU36_GCwyQfo3uZ6RkSwPPuk5AhcgnNRYNSb52uoNL95_ug>
    <xme:_LONagfPGX8ujXQS4eXujppb4fnKdqFIDVBKfZIeNTI7a2iafMejSTQ0Da0HMp83T
    C7QG6qDv-nO1EN7x-z1gZRD-LZDT37XsP9Yedm8XxaA0d9pJiE>
X-ME-Received: <xmr:_LONatsChN3L9uGpMYHd0X0_oya_hVpcCgASfxQs-QT6qMp9a2zBHjkgzrV7-SZ8E7KQ9LZvC0ApDv_eUl_z4eJWNyrGPeZT8YU>
X-ME-Proxy-Cause: dmFkZTErKQoUc1EFlCkg0FLQ9ECRHHLXJK1mMM3+xTKl7ay4Ew8B4QCWYnsTYAopL5auz2
    EbMNE6ODnLYI1WtQLfabBhgBM97aEL0zt+m4IsHpOa7bBPeHjZbqROD6ce1PKiXdhlRGwN
    2l4Hro7jzmMWzv7UHtYTAvkamoM0zAj0TkejklZe4Do7eMunhyuEEMyb282KNlDb05BKZQ
    T3VY/0ByfdMCLVE8Fnrz3Bp9uHBb4NMUtuH0KTq/tJeCtsQvvlWjxzAqRNStiA5O3XapAa
    Np/DfRcUaTVKMm0BHb6aG20wBYhkSCElgxh4W4A+nNCNdgQ48I8XTFri389yQin9I6AaSC
    kl9aYEQ3KF7CBfnMc7SnI0rjWrlPV0kF2hRY/88p9mbtD4prnTGMynJ0IJiWbguQdKe5lL
    RnLMMwQxzV+cviE7dgEmU+U2S1qW8nbehFlKV2Eo7++QpCG0NcRWIvyckqXRS/DBJbMvc/
    DUhK2nEKko0M+3RxIEfYUgF5tv50G5Jipkt0nke1GsOHjSxJkC0WTYKs5bmCDDoVemZpyG
    A3i+YY10fSxNv/pTWqGBnD5wVb9mtHznmdoAdDn270PO1StSG1/BXzSSWqqgS/8scKDIMm
    kD7n6JQ1Dp5Z9e4RC6Xn5M4lry9AQ7Prb3DlS3tz3HtSr5YOemdcoO7TXhDg
X-ME-Proxy: <xmx:_LONan8jS_2G8SAKfW6FgBVtdYZeUgoniVg-cJEU56zxl7RxOKwnow>
    <xmx:_LONag30C2stactqU_aCW_vy34Y6q6XL2tWuWy6bMJWuGqQnS9_xAw>
    <xmx:_LONakDxUpfE41c_L-2AVMZhUo3Z8crpcCeLpxryrckSadnyVjj2xA>
    <xmx:_LONakeASTBU3fAH9Pd8kSNsJvMF-kYJuhjrABsKbYE7M_NcssTUxg>
    <xmx:_LONatRGBVBBwmaAm5fJSX5dR3kTcrZcnXPDMBpg7rQFivPT49tauqwV>
Feedback-ID: i1568416f:Fastmail
Date: Tue, 25 Aug 2026 17:25:45 +0200
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@citrix.com>
Subject: Re: [PATCH test-artifacts v4 13/13] Setup ssh access to test systems
Message-ID: <ao2z-V1K_tDz8u26@mail-itl>
References: <cover.30e6171ddf1c6a72eadf4af0a77c892d4f18d811.1777898148.git-series.marmarek@invisiblethingslab.com>
 <13f837cd9f394d3b4eddb4849156b8ed5d06d31b.1777898148.git-series.marmarek@invisiblethingslab.com>
 <1779458083.8631fc262581453bbf619ec5b2062170.19e4ff78945000f373@vates.tech>
 <alpine.DEB.2.22.394.2605261201180.182011@ubuntu-linux-20-04-desktop>
 <ah24pfWb_orPRaJG@mail-itl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="s05IUUr9rd2cnQjr"
Content-Disposition: inline
In-Reply-To: <ah24pfWb_orPRaJG@mail-itl>
X-purgate-ID: tlsNG-720697/1787671550-F30B02AC-F7DD6316/0/0
X-purgate-type: clean
X-purgate-size: 2538

--s05IUUr9rd2cnQjr
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Aug 2026 17:25:45 +0200
From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= <marmarek@invisiblethingslab.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
	xen-devel@lists.xenproject.org,
	Roger Pau =?utf-8?B?PT91dGYtOD9CP1RXOXVic09wPz0=?= <roger.pau@citrix.com>
Subject: Re: [PATCH test-artifacts v4 13/13] Setup ssh access to test systems

On Mon, Jun 01, 2026 at 06:51:49PM +0200, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Tue, May 26, 2026 at 12:02:23PM -0700, Stefano Stabellini wrote:
> > On Fri, 22 May 2026, Anthony PERARD wrote:
> > > On Mon, May 04, 2026 at 02:35:52PM +0200, Marek Marczykowski-G=C3=B3r=
ecki wrote:
> > > > For this add also bridge package, so xenbr0 can be configured with
> > > > /etc/network/interfaces.
> > > > This allows extracting more logs out of the test system.
> > > >=20
> > > > Create empty /etc/network/interfaces, so the 'networking' service s=
tarts
> > > > cleanly even if no interfaces are configured this way. This is
> > > > necessary, as dropbear service depends on networking.
> > > >=20
> > > > Signed-off-by: Marek Marczykowski-G=C3=B3recki <marmarek@invisiblet=
hingslab.com>
> > >=20
> > > Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
> >=20
> > Since Anthony has reviewed the entire series, on the whole series:
> >=20
> > Acked-by: Stefano Stabellini <sstabellini@kernel.org>
>=20
> Thanks.
>=20
> I seem to have forgotten the "test-artifacts" subject tag (adding now).

AFAICT this series is fully acked, is there anything preventing
committing it?

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--s05IUUr9rd2cnQjr
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqNs/kACgkQ24/THMrX
1ywcTwf8Cb+gYk2IHF7OABQV9sKHM2YZnVLL8gg2WbkC4uHI0B3i8gdIvmf4kKXV
wqfgm2LExzs7TOLMiyMoCbPWHSB5UV42RkNrlUcU5yBf/SSwsZmk9Q4qDSxXsMcS
2a0DcQE+W6uye1lrDXVgzFUmpoaaGtSwPKJdKdeviz8/4Ya015J3HafCgYjKj54T
3P/q3/r7xD/xL/uoZDIOvKa4x+WYneG5h718n7mmSsiv8DpWGJnOnllT1wmr8yaC
lU1uepTe4bVKP9SR0AY+z65yc3zoAGNq/+1SVUfnOch/4FP4z+8ZWrHjqjStT7dA
kmBdk/qcYd/Or1jZdrdIUcbel44huQ==
=GOaJ
-----END PGP SIGNATURE-----

--s05IUUr9rd2cnQjr--


From xen-devel-bounces@lists.xenproject.org Tue Aug 25 16:06:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 16:06:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399334.1635467 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wytfa-000110-KY; Tue, 25 Aug 2026 16:06:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399334.1635467; Tue, 25 Aug 2026 16:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wytfa-00010t-H8; Tue, 25 Aug 2026 16:06:38 +0000
Received: by outflank-mailman (input) for mailman id 1399334;
 Tue, 25 Aug 2026 16:06:37 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wytfZ-00010n-8o
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 16:06:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wytfY-00Brca-Ag
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 18:06:36 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a8dbd70-bab6-0a2a0a5309dd-0a2a4502c59a-26
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 18:06:36 +0200
Received: from [209.85.218.52] (helo=mail-ej1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a8dbd8c-6ca4-0a2a45020019-d155da34b888-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 18:06:36 +0200
Received: by mail-ej1-f52.google.com with SMTP id
 a640c23a62f3a-c20e70a0962so764138266b.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 09:06:36 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a88ac5csm19461166b.40.2026.08.25.09.06.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 09:06:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787673996; x=1788278796; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=WDijApkDgns953IQEs3qT974eR4YLNg3THaJQ2Gagys=;
        b=Pb0LnHTTcA51T2tbNl2LvBGzuUw4Y0+vU2hB9knMotSBpEcELnOlqFpTKT5k0TyD8i
         nQH/WzQ1q7ccsiwvG//4siWd7VI2b3kFgWs4aCJmGwZxa8kDW09UQ9dB0AeQaXygk9rv
         Zqpt2IC7yiikEkhCO9+tWfofengc/wX5biQvuBe5DWfky02pJ92T71XTEGSTYW5z7nAx
         2Rup+xadK46HSZstS0CaoDRRhQnVNKeZTIEE4MCwUu3HyajquAOBnFhG1PAjq4mwer0/
         q697BRYXcduP2hAaQkb5Keb6VBo6l/bn2Md1shq7lWlyNN4GWRgGW98tVHhVl90TIJ3z
         +wFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787673996; x=1788278796;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=WDijApkDgns953IQEs3qT974eR4YLNg3THaJQ2Gagys=;
        b=GBgNx5IX1CHTi/wmtUa8WbHnVtvjn/gKJiNT7yck9s0n3eWIvvLi3vBEVQRc8EuKOt
         j+VdQSNSuy7EU4F4QzYTYkJeR6eAVjqcLJlBlQccuOacYjNuZ9BTgpZtE36BxSeIh7DW
         pryy7ZdvD4fWpl+ZiQWNi3NpDQN7EUots3Z5CGhW2HG38IGVIZat7TMqoOAqum/yFm/Q
         LU639Ex3vhqKTr26AvbWWh4sRRcIOw0ATVifufCv75cCkH7tmB4OD18ItGKbrChktm1i
         niC0Net7WDE8RlIfDEw9769E8t6Kxed/+g7k9QAmvMJpK/G9B1YWv+nWXo+snU1j1FqD
         RcwA==
X-Forwarded-Encrypted: i=1; AHgh+Rqu/PPCmU/LdD8pWZG0FIyhZIMc9ZmKXXT1e2omCE4i9cJ6a1r1Vutm8LuFMFrID6L05V0kNbQKCnk=@lists.xenproject.org
X-Gm-Message-State: AFuF++nZqpW0EI5Li5ih0qhLhktQFBsiSabTmsFQ8Itx6ZoiGqL4jsZv
	p1XwMqCoZIVHkg+guGzKEGDuejV/LSs+/cyuIe/UrMAF1/PvXL6yh3nNwIK9FA==
X-Gm-Gg: AR+sD11RWVrS39kHBSEg3ZodL4wU86FkPw9zW80ZguGn1FDqqoWwIwD1kixNRm8qdOh
	8Yp15KuS0OOe+QHGxOssaRDVfsXzxONNDlAx0YjkkM1hCGeF3ksm7gchazcQIRU/8pIhrC3hboJ
	GJdQazwbpRJ2fCBR62xQLyZEqx0eXamJVcA2mXtHZSizqyWL40CulvF/JnLlk4GL43KMhOFQ00Y
	5ytb+0aE7WX7Sxx2g/kfbcFcG1oIW0aLsOigPJ9pud33BHq3Urm/MBzkuC9zTDnqibxDP8nlECM
	7+R5KS8bHKLCHFTL/5bmfOumT57ZG1DCtrll2X80cbC5wvHngqZWeqefB29IqqVxCAZ7eA5lJv5
	04h5EFIDhuRGqeDcpTx3RF92+InCg4iit0vIhTARuFk2X0h/g40udlBFKklZ9XYboFjsEo+snvT
	DX1purCwy8C7UN7q80lqcZAYyYw4WQx2mBh0BzYM6jlPfCjb5oTOX9WNSOtHJVYG/II6WTt2g5E
	6FhJUSB6ty3gFYfxXx9Z0yNJ97ou2I4NJe/yozDOfE=
X-Received: by 2002:a17:906:99c4:b0:c20:af9d:4544 with SMTP id a640c23a62f3a-c246a4e6388mr3653739066b.6.1787673995403;
        Tue, 25 Aug 2026 09:06:35 -0700 (PDT)
Message-ID: <4c0f0abd-b036-46fe-a93e-7df4ffcc20ca@gmail.com>
Date: Tue, 25 Aug 2026 18:06:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7 16/20] xen/riscv: implement IRQ routing for device
 passthrough
To: Jan Beulich <jbeulich@suse.com>
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 xen-devel@lists.xenproject.org
References: <cover.1785836421.git.oleksii.kurochko@gmail.com>
 <cbbaea00bd461284f6440dbd11653a64f7434b94.1785836421.git.oleksii.kurochko@gmail.com>
 <0fe5fa72-e10c-41c1-8f4c-749cf241bf29@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <0fe5fa72-e10c-41c1-8f4c-749cf241bf29@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787673996-67CBA2AC-89B7494A/10/73395122804
X-purgate-type: spam
X-purgate-size: 18342



On 8/18/26 12:18 PM, Jan Beulich wrote:
> On 04.08.2026 17:48, Oleksii Kurochko wrote:
>> dom0less device passthrough requires granting guest domains access to
>> device interrupts. Introduce map_device_irqs_to_domain() to enumerate
>> a DT node's interrupt properties, skipping those not owned by
>> the primary interrupt controller (as at the moment I haven't seen usages
>> of it), and map_irq_to_domain() to grant domain access and configure
>> Xen's interrupt descriptor accordingly. Sharing IRQ between domains is
>> rejected.
>>
>> Both map_irq_to_domain() and map_device_irqs_to_domain() are marked
>> __overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to
>> __init, so the functions are init-only and need no XSM check; with
>> CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime
>> entry point is dt_overlay_domctl(), which performs the XSM checks at the
>> domctl layer.  RISC-V does not wire up DT overlay yet, so today these are
>> strictly __init; if/when overlay support is added, the domctl-level XSM
>> gating must be added together with it, as on Arm.
>>
>> route_irq_to_guest() and release_irq() manage irq_desc ownership for
>> guest-assigned interrupts. Each assignment carries a small irq_guest
>> structure as irqaction::dev_id, recording the owning domain and virtual
>> IRQ number which is 1:1 mapped to physical IRQ number. A per-domain
>> vIRQ allocation bitmap (used_irqs in struct vintc), managed by
>> vintc_reserve_virq(), prevents the same vIRQ being claimed twice.
>>
>> Host and guest interrupts may differ in some operations (EOI timing in
>> particular, possibly others): a host IRQ is completed once Xen's handler
>> runs, whereas a passthrough IRQ must defer the physical completion until
>> the guest issues its own EOI, otherwise a still-asserted level line would
>> immediately retrigger and storm. This affects only the .end callback;
>> the rest of hw_interrupt_type is shared, hence the separate host and
>> guest hw_interrupt_type instances.
>>
>> With APLIC+IMSIC, guest interrupts are delivered directly by hardware
>> through the IMSIC, bypassing do_IRQ(). The _IRQ_GUEST branch in
>> do_IRQ() is therefore left as BUG() until a platform without direct
>> IMSIC delivery is encountered.
>>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

[...]

>> Updates
>>
>> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
>> Changes in v7:
>>   - Build device.c as device.init.o: everything it provides is
>>     __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB
>>     stays Arm-only.  Unlike Arm, which picks device.o/device.init.o based
>>     on that config, RISC-V cannot enable it, so the choice is
>>     unconditional for now.
>>   - Don't have release_irq() free the guest IRQ info anymore: set
>>     free_on_release = false and free 'info' explicitly in
>>     release_guest_irq(), i.e. reinstate the xvfree() dropped in v5.  The
>>     action stays embedded in struct irq_guest, so a single allocation
>>     still covers both, but it no longer has to be the structure's first
>>     member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer
>>     that merely happened to coincide with the allocation base are gone.
>>     The ->dev_id concern from v5 doesn't apply: release_irq() clears
>>     desc->action under desc->lock and waits for in-flight handling before
>>     returning, so nothing can observe ->dev_id once 'info' is freed.
>>   - Move 'action' to the end of struct irq_guest and reword its comment
>>     accordingly.
>>   - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that
>>     the embedded action is fully initialized (action.handler was left
>>     uninitialized before).
>>   - route_irq_to_guest(): free 'info' via the common free_info label when
>>     intc_route_irq_to_guest() fails, now that release_irq() no longer
>>     frees it.
>>   - Drop a stray blank line ahead of release_irq().
>> ---
>> ---
> 
> Why does this appear a 2nd time? All of the above is already long / verbose
> enough.

A rebase issue. all these changes were initially in the separate patch 
and after squashed I missed to remove this part.

I will drop it.
> 
>> @@ -101,12 +119,31 @@ int domain_vintc_init(struct domain *d)
>>           break;
>>       }
>>   
>> +    if ( !ret )
>> +    {
>> +        d->arch.vintc->used_irqs =
>> +            xvzalloc_array(unsigned long,
>> +                           BITS_TO_LONGS(d->arch.vintc->nr_virqs));
>> +        if ( !d->arch.vintc->used_irqs )
>> +            ret = -ENOMEM;
>> +    }
>> +
>>       return ret;
>>   }
> 
> Patch 13 doesn't arrange for domain_vintc_deinit() to be called when
> domain_vintc_init() fails. Ideally that would change, or else you'd
> now need to call the function in the error case from here.


I will add a call of domain_vintc_deinit() in arch_domain_destroy() in 
patch 13:

  void arch_domain_destroy(struct domain *d)
  {
-    printk(XENLOG_WARNING "%s: unimplemented\n", __func__);
+    printk(XENLOG_WARNING "%s: not fully implemented\n", __func__);
+
+    domain_vintc_deinit(d);
  }

> In either
> case ...
> 
>>   void domain_vintc_deinit(struct domain *d)
>>   {
>>       const enum intc_variant variant = intc_hw_ops->info->hw_variant;
>> +    unsigned int virq;
>> +
>> +    if ( !d->arch.vintc )
>> +        return;
>> +
>> +    for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ )
>> +        if ( test_bit(virq, d->arch.vintc->used_irqs) )
>> +            release_guest_irq(d, virq);
>> +
>> +    XVFREE(d->arch.vintc->used_irqs);
> 
> ... this function will then need to become resilient against being
> called with partially initialized state.

I will update it to:

  void domain_vintc_deinit(struct domain *d)
  {
      const enum intc_variant variant = intc_hw_ops->info->hw_variant;
-    unsigned int virq;

      if ( !d->arch.vintc )
          return;

-    for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ )
-        if ( test_bit(virq, d->arch.vintc->used_irqs) )
-            release_guest_irq(d, virq);
+    if ( d->arch.vintc->used_irqs )
+    {
+        unsigned int virq;
+
+        for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ )
+            if ( test_bit(virq, d->arch.vintc->used_irqs) )
+                release_guest_irq(d, virq);

-    XVFREE(d->arch.vintc->used_irqs);
+        XVFREE(d->arch.vintc->used_irqs);
+    }


> 
>> @@ -118,3 +155,11 @@ void domain_vintc_deinit(struct domain *d)
>>           break;
>>       }
>>   }
>> +
>> +bool vintc_reserve_virq(const struct domain *d, unsigned int virq)
>> +{
>> +    if ( virq >= d->arch.vintc->nr_virqs )
>> +        return false;
>> +
>> +    return !test_and_set_bit(virq, d->arch.vintc->used_irqs);
>> +}
> 
> Is the present caller of this going to remain the only one? If so,
> __overlay_init would want using here as well. If not - will future
> callers appear on paths which are exposed to guests? If in turn so,
> speculation safety may need adding here.

I don't see any others calls of it in downstream. So I will add 
__overlay_init.

> 
>> @@ -227,3 +250,206 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
>>       spin_unlock(&desc->lock);
>>       irq_exit();
>>   }
>> +
>> +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc)
>> +{
>> +    ASSERT(spin_is_locked(&desc->lock));
>> +    ASSERT(test_bit(_IRQ_GUEST, &desc->status));
>> +    ASSERT(desc->action != NULL);
> 
> Btw, no need for the " != NULL" part.

I will drop it.

> 
>> +    return desc->action->dev_id;
>> +}
>> +
>> +void release_irq(unsigned int irq, const void *dev_id)
>> +{
>> +    struct irq_desc *desc;
>> +    unsigned long flags;
>> +    struct irqaction *action, **action_ptr;
>> +
>> +    desc = irq_to_desc(irq);
> 
> Can't this (once again) be the initializer of the variable?
> 
>> +    spin_lock_irqsave(&desc->lock, flags);
>> +
>> +    action_ptr = &desc->action;
> 
> Same for this one, which also doesn't require the lock to be held.

I will apply both remarks.

> 
>> +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
>> +    for ( ;; )
>> +    {
>> +        action = *action_ptr;
>> +        if ( !action )
>> +        {
>> +            printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", irq);
>> +            spin_unlock_irqrestore(&desc->lock, flags);
>> +            return;
>> +        }
>> +
>> +        if ( action->dev_id == dev_id )
>> +            break;
>> +
>> +        action_ptr = &action->next;
>> +    }
>> +
>> +    /* Found it - remove it from the action list */
>> +    *action_ptr = action->next;
>> +#else
>> +    action = *action_ptr;
>> +    *action_ptr = NULL;
>> +#endif
>> +
>> +    /* If this was the last action, shut down the IRQ */
>> +    if ( !desc->action )
>> +    {
>> +        desc->handler->shutdown(desc);
>> +        __clear_bit(_IRQ_GUEST, &desc->status);
>> +    }
>> +
>> +    spin_unlock_irqrestore(&desc->lock, flags);
>> +
>> +    /*
>> +     * Wait to make sure it's not being used on another CPU.
>> +     *
>> +     * The read barrier pairs with the spin_unlock() in do_IRQ(): once we
>> +     * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the
>> +     * writes do_IRQ() made to desc (e.g. desc->action) before releasing the
>> +     * lock, so it is safe to free the action below.
>> +     */
>> +    do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) );
>> +
>> +    if ( action->free_on_release )
>> +        xvfree(action);
>> +}
>> +
>> +int release_guest_irq(struct domain *d, unsigned int virq)
>> +{
>> +    struct irq_desc *desc = irq_to_desc(virq);
>> +    struct irq_guest *info;
>> +    unsigned long flags;
>> +    int ret = -EINVAL;
>> +
>> +    spin_lock_irqsave(&desc->lock, flags);
>> +
>> +    if ( !test_bit(_IRQ_GUEST, &desc->status) )
>> +        goto unlock_err;
>> +
>> +    info = irq_get_guest_info(desc);
>> +    if ( d != info->d )
>> +        goto unlock_err;
>> +
>> +    /*
>> +     * Live IRQ unrouting from a running domain is not supported: the tear-down
>> +     * drops desc->lock across release_irq()/xvfree() and relies on no
>> +     * concurrent route_irq_to_guest() being issued for this domain. Only permit
>> +     * it for a dying domain, where assignment is frozen and no new routes can
>> +     * appear.
>> +     */
>> +    if ( !d->is_dying )
>> +    {
>> +        ret = -EBUSY;
>> +        goto unlock_err;
>> +    }
>> +
>> +    /*
>> +     * Clear _IRQ_GUEST while still holding the lock so that a concurrent
>> +     * release_guest_irq() for the same IRQ observes it and bails out, rather
>> +     * than capturing the same 'info' and double-freeing it below.
>> +     */
>> +    __clear_bit(_IRQ_GUEST, &desc->status);
>> +
>> +    spin_unlock_irqrestore(&desc->lock, flags);
>> +
>> +    release_irq(desc->irq, info);
>> +    xvfree(info);
> 
> While in the v7 revlog you claim there is no issue here, imo there (still) is.
> You obtain "info" with the lock held, then drop the lock, for release_irq() to
> re-acquire. If a similar pattern was used elsewhere (info obtained under lock,
> lock dropped, then using info), the pointer would go stale the moment you free
> it here. Imo for this to be safe _and_ not setting a bad precendent, you need
> a variant of release_irq() which is passed desc with the lock already held.
> release_irq() itself (if to be called from anywhere else) would then be a thin
> wrapper around it.

I agree that it will be safer in general.

I will introduce:

static void irq_release_action(const struct irq_desc *desc,
                                struct irqaction *action)
{
     /*
      * Wait to make sure it's not being used on another CPU.
      *
      * The read barrier pairs with the spin_unlock() in do_IRQ(): once we
      * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the
      * writes do_IRQ() made to desc (e.g. desc->action) before 
releasing the
      * lock, so it is safe to free the action below.
      */
     do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) );

     if ( action->free_on_release )
         xvfree(action);
}

+void release_irq(unsigned int irq, const void *dev_id)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action;
+    unsigned long flags;
+
+    spin_lock_irqsave(&desc->lock, flags);
+    action = irq_detach_action(desc, dev_id);
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    if ( action )
+        irq_release_action(desc, action);
+}

Where irq_detach_action() will be almost what release_irq() was before:

+static struct irqaction *irq_detach_action(struct irq_desc *desc,
+                                           const void *dev_id)
  {
-    struct irq_desc *desc = irq_to_desc(irq);
-    unsigned long flags;
      struct irqaction *action, **action_ptr = &desc->action;

-    spin_lock_irqsave(&desc->lock, flags);
+    ASSERT(spin_is_locked(&desc->lock));
+
  #ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
      for ( ;; )
      {
          action = *action_ptr;
-        if ( !action )
-        {
-            printk(XENLOG_WARNING "Trying to free already-free IRQ 
%u\n", irq);
-            spin_unlock_irqrestore(&desc->lock, flags);
-            return;
-        }
-
-        if ( action->dev_id == dev_id )
+        if ( !action || (action->dev_id == dev_id) )
              break;

          action_ptr = &action->next;
      }
+#else
+    action = *action_ptr;
+#endif
+
+    if ( !action )
+    {
+        printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n",
+               desc->irq);
+        return NULL;
+    }

      /* Found it - remove it from the action list */
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
      *action_ptr = action->next;
  #else
-    action = *action_ptr;
      *action_ptr = NULL;
  #endif

@@ -298,8 +309,22 @@ void release_irq(unsigned int irq, const void *dev_id)
          __clear_bit(_IRQ_GUEST, &desc->status);
      }

-    spin_unlock_irqrestore(&desc->lock, flags);
+    return action;
+}

and then release_guest_irq() (the end) will be changed in the following way:

....
     /*
      * Detaching the action happens with desc->lock still held, so that a
      * concurrent release_guest_irq() for the same IRQ sees _IRQ_GUEST 
already
      * cleared and bails out, rather than capturing the same 'info' and
      * double-freeing it below.
      */
     action = irq_detach_action(desc, info);

     spin_unlock_irqrestore(&desc->lock, flags);

     if ( action )
         irq_release_action(desc, action);

     xvfree(info);

     return 0;

> 
>> +/* Route an IRQ to a specific guest */
>> +int route_irq_to_guest(struct domain *d, unsigned int virq,
>> +                       unsigned int irq, const char *devname)
>> +{
>> +    struct irq_guest *info;
>> +    struct irq_desc *desc;
>> +    unsigned long flags;
>> +    int retval = 0;
>> +
>> +    if ( d->is_dying )
>> +        return -EINVAL;
>> +
>> +    desc = irq_to_desc(irq);
> 
> Imo this either wants to be the initializer of the variable, or (perhaps
> better here) it wants to move immediately ahead of ...
> 
>> +    info = xvzalloc(struct irq_guest);
>> +    if ( !info )
>> +        return -ENOMEM;
>> +
>> +    info->d = d;
>> +    info->virq = virq;
>> +
>> +    info->action.dev_id = info;
>> +    info->action.name = devname;
>> +    /* The action is part of 'info', thus it is freed together with it. */
>> +    info->action.free_on_release = false;
>> +
>> +    spin_lock_irqsave(&desc->lock, flags);
> 
> ... this.

I will move initialization here.

> 
>> +    /*
>> +     * If the IRQ is already used by someone
>> +     *  - If it's the same domain -> Xen doesn't need to update the IRQ desc.
>> +     *  For safety check if we are not trying to assign the IRQ to a
>> +     *  different vIRQ.
>> +     *  - Otherwise -> For now, don't allow the IRQ to be shared between
>> +     *  Xen and domains.
>> +     */
>> +    if ( desc->action != NULL )
>> +    {
>> +        if ( test_bit(_IRQ_GUEST, &desc->status) )
>> +        {
>> +            struct domain *ad = irq_get_guest_info(desc)->d;
>> +
>> +            if ( d != ad )
>> +            {
>> +                printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n",
>> +                       irq, ad);
>> +                retval = -EBUSY;
>> +            }
>> +            else if ( irq_get_guest_info(desc)->virq != virq )
>> +            {
>> +                printk(XENLOG_G_ERR
>> +                       "%pd: IRQ %u is already assigned to vIRQ %u\n",
>> +                       d, irq, irq_get_guest_info(desc)->virq);
>> +                retval = -EBUSY;
>> +            }
>> +        }
>> +        else
>> +        {
>> +            printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
>> +            retval = -EBUSY;
>> +        }
>> +        goto out;
>> +    }
>> +
>> +    retval = _setup_irq(desc, 0, &info->action);
>> +    if ( retval )
>> +        goto out;
>> +
>> +    retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY);
>> +
>> +    spin_unlock_irqrestore(&desc->lock, flags);
>> +
>> +    if ( retval )
>> +    {
>> +        release_irq(desc->irq, info);
> 
> Like above, I think you want to avoid transiently dropping the lock here.

With suggested above it will look like:

      retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY);
-
-    spin_unlock_irqrestore(&desc->lock, flags);
-
      if ( retval )
      {
-        release_irq(desc->irq, info);
+        struct irqaction *action = irq_detach_action(desc, info);
+
+        spin_unlock_irqrestore(&desc->lock, flags);
+
+        if ( action )
+            irq_release_action(desc, action);
+
          goto free_info;
      }

+    spin_unlock_irqrestore(&desc->lock, flags);
+
      return 0;

   out:

Thanks.

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Tue Aug 25 18:46:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 18:46:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399377.1635475 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywAS-0004Bu-Gq; Tue, 25 Aug 2026 18:46:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399377.1635475; Tue, 25 Aug 2026 18:46:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywAS-0004Bn-EF; Tue, 25 Aug 2026 18:46:40 +0000
Received: by outflank-mailman (input) for mailman id 1399377;
 Tue, 25 Aug 2026 18:46:39 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrewprecious388@gmail.com>) id 1wywAR-0004Bh-QU
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 18:46:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wywAQ-005jvt-Pe
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 20:46:38 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a8de30d-2eae-0a2a0a5409dd-0a2a4504b478-8
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 20:46:38 +0200
Received: from [209.85.208.46] (helo=mail-ed1-f46.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrewprecious388@gmail.com>)
 id 6a8de30e-b57f-0a2a45040019-d155d02ec8e6-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 20:46:38 +0200
Received: by mail-ed1-f46.google.com with SMTP id
 4fb4d7f45d1cf-69f7fa1c548so150900a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 11:46:38 -0700 (PDT)
Received: from debian.debian ([102.213.48.6]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5deafc5fbsm788440a12.29.2026.08.25.11.46.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 11:46:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787683598; x=1788288398; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qDmNtQPJrIeDcaKmZnWEk6NqB3Ijs7mbrXXLbwSCRrs=;
        b=RlGHPwBTSSZ/Rg6PfUfgTmgslAa2LzFTIEpLET+Xw5r8T4d3fov2NUGa7PLE46mNLE
         vOF09frdSgY/TscLsJc90BO1QqyCAnmZwifCpTy+wmhEji9z69JUG15mV2ZxCefQAxOA
         TLtcYQOwVT9REeBV0x3vm2FqvCoK1q8hIzlylb82/EReZZrgqgqZHu04M56TR2hpHdIL
         aZlKejGqBMxo5rxX3I39LdmQ73iJANEsI42S7QD/eF1e7TQa3FyU15B+wMsmRY3PBkJJ
         qK9NXqXFW/jBwk/3DWZWtqV//LusKmjs/ePGc2l1Gt7IhPr/3Oknv6kjEt4EuDRJRd+e
         IB4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787683598; x=1788288398;
        h=content-transfer-encoding:content-type:mime-version: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=qDmNtQPJrIeDcaKmZnWEk6NqB3Ijs7mbrXXLbwSCRrs=;
        b=LLYZN6UUq11PaoT9qWWOKCiOM6hHOdXiyP/mf3a0CQySeJ66C7hYrOXBH/XalVPNl7
         bZvdmq/X9gHf6GGYBGRT7MwOYhKP+JuWDuMVrOtOEGWuyva4YfgcxQiwc5/yyXd8E9nk
         3WUUXC4sZEXOE2gAT9V3qhAnvHk1liOD8N0O6lbemUUFAaUT73i39vKzQujwqC23cF3c
         XhtUH1LGqW9W75pUmsJnO2lmjl1yqE/FiqIWq89QhlBlaUw+U73epPzT9UGgxqFyYXjN
         R1RZfS8CGnXZxC7XsQxwen0Y3naNf80YTO7mgeGJZk23Xs7ce2qLoVOwx1QC518Cv6MY
         DKzA==
X-Gm-Message-State: AFuF++lHQGGwU1/IE07wGR7PYX5JUs1v5djMdOYNodzu2hxdhzjsPWur
	cV5NZH7iSsZEuKuTxslvxhyiqtJUvGNLEJhs3cfpHes34dwDe/dqgrExZdisToN/Elc=
X-Gm-Gg: AR+sD11db+CGOROvthgtuaJMh4L4nrIA9ny2UIUcfLVEtAYJcHlTN25EGn3sJdxoJ90
	u6FQzZ6l8CqIYflXGUze4yulcrccbnIv3ewDzAmElMcbNgjqzWZdL6BW6adS3fn4fFrh40RwFc7
	4f7WWYOy4iSxjTjLu8ZidefopDu3cj8VOUMeg+zMXxaSNIV2CdJ0Ja1O9pDT/9mv4iUisQ1XHJY
	C3fIN6Tc6V0NW+4Vh6GjNQ5DtsCGqlMsYhiK2CxkAXMnwGw19ra9ZZ1bliWcMdeaJ1bpjZEM9se
	L6N1exp4Z4Av15nbVNqB7EtTvLTGuqd9vGF4E0K57RMvNiiJbjGSVJKlTq5WLJhrZTl8aq3k9qP
	Tt35Hc4FTus+C6KZHrxhOIrtS//AMxkXMuTUvDQWn80/3gIs20R4n/x6fkZPi/kISUTI0g20cm8
	6sujQT1oBQ7HWJMf/5qKuPFYs+TPRJtIDJKBkBhZR4ZTllnWne9sl+lRslKdZX3l+TTVZu1g==
X-Received: by 2002:a05:6402:5057:b0:6a5:dd97:23ea with SMTP id 4fb4d7f45d1cf-6a5df65b681mr1015758a12.11.1787683598073;
        Tue, 25 Aug 2026 11:46:38 -0700 (PDT)
From: Andrew Mbugua <andrewprecious388@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	samuel.thibault@ens-lyon.org,
	Andrew Mbugua <andrewprecious388@gmail.com>
Subject: [PATCH] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings in PolarSSL
Date: Tue, 25 Aug 2026 21:46:04 +0300
Message-ID: <20260825184605.79318-1-andrewprecious388@gmail.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787683598-52ECEB50-D1F5776D/0/0
X-purgate-type: clean
X-purgate-size: 1726

When compiling Xen with GCC 14, I get a compiler warning originating from the /polarssl-x86_64/library about a memset element size mismatch:

ssl_tls.c: In function ‘ssl_session_reset’:
ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
1778 |     memset( ssl->ctx_enc, 0, 128 );
|     ^~~~~~
ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
1779 |     memset( ssl->ctx_dec, 0, 128 );
|     ^~~~~~

This patch introduces a build-time patch to PolarSSL that replaces the hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean compilation without warnings.

Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
---
 stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch

diff --git a/stubdom/patches/polarssl-gcc14-memset.patch b/stubdom/patches/polarssl-gcc14-memset.patch
new file mode 100644
index 0000000000..d98664d0a8
--- /dev/null
+++ b/stubdom/patches/polarssl-gcc14-memset.patch
@@ -0,0 +1,13 @@
+--- a/library/ssl_tls.c
++++ b/library/ssl_tls.c
+@@ -1775,8 +1775,8 @@
+     memset( ssl->iv_dec, 0, 16 );
+     memset( ssl->mac_enc, 0, 32 );
+     memset( ssl->mac_dec, 0, 32 );
+-    memset( ssl->ctx_enc, 0, 128 );
+-    memset( ssl->ctx_dec, 0, 128 );
++    memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) );
++    memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) );
+ 
+      md5_starts( &ssl->fin_md5  );
+     sha1_starts( &ssl->fin_sha1 );
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 19:12:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 19:12:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399387.1635485 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZ3-000823-DF; Tue, 25 Aug 2026 19:12:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399387.1635485; Tue, 25 Aug 2026 19:12:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZ3-00081w-9t; Tue, 25 Aug 2026 19:12:05 +0000
Received: by outflank-mailman (input) for mailman id 1399387;
 Tue, 25 Aug 2026 19:12:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wywZ1-00081q-KW
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 19:12:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wywZ1-00Ewkz-1I
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 21:12:03 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de8fb-e002-0a2a0a5209dd-0a2a450a89bc-10
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:02 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de901-f2d2-0a2a450a0019-aa0a857ce2ff-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:02 +0200
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-418-9fDIjUJcONS6cFtfvgj5hQ-1; Tue,
 25 Aug 2026 15:11:55 -0400
Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id C513618C104B; Tue, 25 Aug 2026 19:11:51 +0000 (UTC)
Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.114])
 by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 2869930002F7; Tue, 25 Aug 2026 19:11:49 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787685121;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=UAVq8jQ2W8GQMPKZh9lwo20fWbzMAGBwvQIsMg5/FCI=;
	b=OFXGD3815PL5Qylt2Do92u8vHpn/89T8Ug3lpFihm6x81QhPt8yDEFMbrWpl2Bw+R/57Bb
	l88t+IYFBODjiXeLbDIDEXSPqYKu8f4CcEHBKysZ0fzfsLhYcS2a+ekB/bknDjEhgVQIUW
	W1gqTNM6CP9z6x4AHGIt4JbCpwnM1PM=
X-MC-Unique: 9fDIjUJcONS6cFtfvgj5hQ-1
X-Mimecast-MFC-AGG-ID: 9fDIjUJcONS6cFtfvgj5hQ_1787685112
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Tue, 25 Aug 2026 23:09:36 +0400
Subject: [PATCH v4 29/49] monitor: isolate HMP declarations in hmp.h
MIME-Version: 1.0
Message-Id: <20260825-qemu-no-hmp-v4-29-af60857c2fbe@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
In-Reply-To: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, Brian Cain <brian.cain@oss.qualcomm.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Jason Wang <jasowangio@gmail.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=15816;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=n8fT+96oEvudRuUgQ/dnx3uxsW6aOGEO6iYpiyOTIXQ=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqjeiHMbeCsIaocGDO9Y0JrkRvOQPBT9wWDsX/i
 T+t9yX7FG2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCao3ohwAKCRDa6OEJdZac
 5SqyD/98pXJ+2rTVWhJDv2+W7vZXwaDhugqM+eSZowAaTap8SXdKf2vpneqGF7szUuSGA0REczp
 MdqmCmM0X1hYudkxOpb26I/4iLgK7fjPhoJw/M0vyX3OAQ7KN1mlSP2Qq0MOyX4jpHPowArR9rb
 h5dM8tLSTanHBXmgVYZhDPgW5dsVyCyYtuqakjaUZ/qBVOpmiC/L3welEVYy8qecIGsnPSsCXr8
 91aHPwh9ooMgss3EuOtXr87uB8ZmCfZ5meMmTm7+m/6qnldX1FSPvSq8U0Kx59yheL+/YgwtABb
 5XaLGuEjOmtlqT5OgUn9T+byv783I07iXgX6PUIfx1BE88rpjKDTurL9ELtS+dGgeqAef2ChOBg
 3E9cJq3bo+YvA0X9TTmZdl1CR0rewG3ZgxuZaJIs5piygPJQt6C5P4hWPCOow3WIT1gSSAIkU8R
 AJmXk9aZhnxKJHpa2m5QD8iZftNQ3WJ3LQhBlqESWFsE7fArMzBQUpd8/iMAJ3IY3FAL1bZJ6HH
 TIPzmE+Y1s4k3mbsntGRAlpEQXTV/P891U6X353m0EVBgj/V/TzjJmsipfyg4Oc537x6NXQENs1
 R4CQjD72G/Exl5kZnNMfYwffMaQTN8D/TXGU0NQEMySYAR4cJDNRTqM8++8HlZ+8kABEhWKOHlA
 XmxijGls1xjmuGA==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4
X-Mimecast-MFC-PROC-ID: mhsu2O7-F07pEq0JfJftYB-8wD49YFRwAn2bfrL5biI_1787685112
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787685122-4BAD4CFC-FE0F3C3E/0/0
X-purgate-type: clean
X-purgate-size: 15818

Also rename password & commands with hmp in the name, while at it.
Other functions need larger changes which we will take care of next.

Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 accel/accel-system.c           |  1 +
 accel/tcg/monitor.c            |  1 +
 chardev/char.c                 |  2 +-
 disas/disas-mon.c              |  1 +
 gdbstub/system.c               |  2 +-
 hw/char/virtio-serial-bus.c    |  1 +
 hw/core/machine-hmp-cmds.c     |  1 -
 hw/core/sysbus.c               |  1 +
 hw/hexagon/hexagon_tlb.c       |  1 +
 hw/misc/auxbus.c               |  1 +
 hw/usb/bus.c                   |  1 +
 hw/usb/host-libusb.c           |  1 +
 hw/xen/xen-bus.c               |  1 +
 include/monitor/hmp.h          | 21 +++++++++++++++++++++
 include/monitor/monitor.h      | 18 ------------------
 monitor/hmp.c                  |  8 ++++----
 monitor/monitor-internal.h     |  1 +
 net/slirp.c                    |  1 +
 stubs/monitor-core.c           |  1 +
 stubs/monitor-internal.c       |  2 +-
 target/rx/disas.c              |  1 +
 tests/unit/test-util-sockets.c |  1 +
 tools/qemu-vnc/stubs.c         |  1 +
 trace/trace-hmp-cmds.c         |  1 -
 ui/ui-hmp-cmds.c               |  4 ++--
 util/error-report.c            |  2 +-
 util/qemu-print.c              |  1 +
 27 files changed, 48 insertions(+), 30 deletions(-)

diff --git a/accel/accel-system.c b/accel/accel-system.c
index 9176665202d2..977804c4048a 100644
--- a/accel/accel-system.c
+++ b/accel/accel-system.c
@@ -28,6 +28,7 @@
 #include "qom/compat-properties.h"
 #include "qapi/qapi-commands-accelerator.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "hw/core/boards.h"
 #include "hw/core/cpu.h"
 #include "accel/accel-ops.h"
diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
index be5c1950177c..74170ddef708 100644
--- a/accel/tcg/monitor.c
+++ b/accel/tcg/monitor.c
@@ -11,6 +11,7 @@
 #include "qapi/type-helpers.h"
 #include "qapi/qapi-commands-machine.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/tcg.h"
 #include "tcg/tcg.h"
 #include "internal-common.h"
diff --git a/chardev/char.c b/chardev/char.c
index c6c8133f5c1d..9da0911e503c 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -24,7 +24,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "monitor/qmp-helpers.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index 9c693618c277..bc9dec3a7761 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -10,6 +10,7 @@
 #include "system/memory.h"
 #include "hw/core/cpu.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 /*
  * Get LENGTH bytes from info's buffer, at target address memaddr.
diff --git a/gdbstub/system.c b/gdbstub/system.c
index 070bc26f416c..8a1cdb11db36 100644
--- a/gdbstub/system.c
+++ b/gdbstub/system.c
@@ -29,7 +29,7 @@
 #include "hw/core/boards.h"
 #include "chardev/char.h"
 #include "chardev/char-fe.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "internals.h"
 
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index c1973f0248fc..02604740f86a 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -25,6 +25,7 @@
 #include "qemu/module.h"
 #include "migration/qemu-file-types.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/queue.h"
 #include "hw/core/qdev-properties.h"
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 686304bafab5..1c700aad3587 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -15,7 +15,6 @@
 
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-builtin-visit.h"
 #include "qapi/qapi-commands-accelerator.h"
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 3e1160ee921d..13df7cbafe10 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -21,6 +21,7 @@
 #include "qapi/error.h"
 #include "hw/core/sysbus.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index b6d4aff389e5..2d878cee736d 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -12,6 +12,7 @@
 #include "hw/core/resettable.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 877f34560626..ac2525b90fec 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -33,6 +33,7 @@
 #include "hw/misc/auxbus.h"
 #include "hw/i2c/i2c.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 
 #ifndef DEBUG_AUX
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 3b6fbd46ac3f..9b9b2e7c2f8f 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -9,6 +9,7 @@
 #include "system/system.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "qemu/cutils.h"
 
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index b9f3ad3f66dd..af67d5dfeb10 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -48,6 +48,7 @@
 #include "qapi/error.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "qemu/module.h"
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index dfad2bc5085f..a563f6066bb4 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -17,6 +17,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/xen/xen-bus-helper.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "qobject/qdict.h"
 #include "system/system.h"
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 9258a049bffb..166cd4100c63 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -18,6 +18,9 @@
 #include "qapi/qapi-types-common.h"
 #include "monitor/monitor.h"
 
+#define TYPE_MONITOR_HMP "monitor-hmp"
+OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
+
 #define HMP_STUB(cmd) \
     void hmp_##cmd(Monitor *mon, const QDict *qdict) \
     { \
@@ -30,6 +33,24 @@ struct MonitorDef {
     int64_t (*get_value)(Monitor *mon, const MonitorDef *md, int offset);
 };
 
+void monitor_new_hmp(const char *id, const char *chardev_id,
+                     bool use_readline, Error **errp);
+
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+    G_GNUC_PRINTF(2, 0);
+int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_printc(Monitor *mon, int ch);
+
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque);
+
+void monitor_register_hmp(const char *name, bool info,
+                          void (*cmd)(Monitor *mon, const QDict *qdict));
+void monitor_register_hmp_info_hrt(const char *name,
+                                   HumanReadableText *(*handler)(Error **errp));
+
+
 CPUArchState *mon_get_cpu_env(Monitor *mon);
 CPUState *mon_get_cpu(Monitor *mon);
 
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 9f048ba103b5..72a8f6ea5b4f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -10,9 +10,6 @@
 #define TYPE_MONITOR "monitor"
 OBJECT_DECLARE_TYPE(Monitor, MonitorClass, MONITOR);
 
-#define TYPE_MONITOR_HMP "monitor-hmp"
-OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
-
 #define TYPE_MONITOR_QMP "monitor-qmp"
 OBJECT_DECLARE_TYPE(MonitorQMP, MonitorQMPClass, MONITOR_QMP);
 
@@ -30,8 +27,6 @@ void monitor_init_globals_core(void);
 char *monitor_compat_id(void);
 void monitor_new_qmp(const char *id, const char *chardev_id,
                      bool pretty, Error **errp);
-void monitor_new_hmp(const char *id, const char *chardev_id,
-                     bool use_readline, Error **errp);
 int monitor_new(MonitorOptions *opts, bool allow_hmp, Error **errp);
 int monitor_new_opts(QemuOpts *opts, Error **errp);
 void monitor_cleanup(void);
@@ -43,28 +38,15 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp);
 int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp);
 
 int monitor_puts(Monitor *mon, const char *str);
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
 void monitor_flush(Monitor *mon);
 int monitor_get_cpu_index(Monitor *mon);
 
 int monitor_puts_locked(Monitor *mon, const char *str);
 void monitor_flush_locked(Monitor *mon);
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt);
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque);
-
 AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
                                 const char *opaque, Error **errp);
 int monitor_fdset_dup_fd_add(int64_t fdset_id, int flags, Error **errp);
 void monitor_fdset_dup_fd_remove(int dup_fd);
 
-void monitor_register_hmp(const char *name, bool info,
-                          void (*cmd)(Monitor *mon, const QDict *qdict));
-void monitor_register_hmp_info_hrt(const char *name,
-                                   HumanReadableText *(*handler)(Error **errp));
-
 #endif /* MONITOR_H */
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 8134dfaad4bb..b4d05d47c4bf 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -136,7 +136,7 @@ static void monitor_command_cb(void *opaque, const char *cmdline,
     monitor_resume(&hmp->parent_obj);
 }
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt)
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt)
 {
     if (!hmp->rs) {
         return;
@@ -148,8 +148,8 @@ void monitor_read_command(MonitorHMP *hmp, int show_prompt)
     }
 }
 
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque)
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque)
 {
     if (hmp->rs) {
         readline_start(hmp->rs, "Password: ", 1, readline_func, opaque);
@@ -1647,7 +1647,7 @@ static void monitor_hmp_complete(UserCreatable *uc, Error **errp)
                                     monitor_readline_flush,
                                     hmp,
                                     monitor_find_completion);
-            monitor_read_command(hmp, 0);
+            monitor_hmp_read_command(hmp, 0);
         }
 
         qemu_chr_fe_set_handlers(&hmp->parent_obj.chr,
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index fdeeeb853636..ee9ba0c8231e 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -27,6 +27,7 @@
 
 #include "chardev/char-fe.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 #include "qapi/qapi-types-control.h"
 #include "qapi/qapi-types-qom.h"
diff --git a/net/slirp.c b/net/slirp.c
index 517dd23be14b..9bf09a2c8bc9 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -36,6 +36,7 @@
 #include "clients.h"
 #include "hub.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/sockets.h"
 #include <libslirp.h>
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index a7c32297c90a..b0c7002bd406 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 
 Monitor *monitor_cur(void)
diff --git a/stubs/monitor-internal.c b/stubs/monitor-internal.c
index 731fad221ecc..6f69f1f14ae4 100644
--- a/stubs/monitor-internal.c
+++ b/stubs/monitor-internal.c
@@ -1,6 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
 {
diff --git a/target/rx/disas.c b/target/rx/disas.c
index 67b932882914..0eb2ee6f4507 100644
--- a/target/rx/disas.c
+++ b/target/rx/disas.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 #include "disas/dis-asm.h"
 #include "qemu/bitops.h"
+#include "monitor/hmp.h"
 #include "cpu.h"
 
 typedef struct DisasContext {
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index ab3f39c3efb5..b2a884529598 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -24,6 +24,7 @@
 #include "qapi/error.h"
 #include "socket-helpers.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 static void test_fd_is_socket_bad(void)
 {
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 1c82d8cff430..26597fefaa99 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -9,6 +9,7 @@
 #include "system/runstate.h"
 #include "hw/core/qdev.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "migration/vmstate.h"
 
 bool runstate_is_running(void)
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 390173095cff..c8f0133abecf 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -25,7 +25,6 @@
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
 #include "monitor/hmp-completion.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-trace.h"
 #include "qobject/qdict.h"
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 806a7bece7cb..4ef459490ba2 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -327,7 +327,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
                                 void *readline_opaque)
 {
     qmp_change_vnc_password(password, NULL);
-    monitor_read_command(opaque, 1);
+    monitor_hmp_read_command(opaque, 1);
 }
 
 void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
@@ -344,7 +344,7 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
     }
     if (!arg) {
         MonitorHMP *hmp = MONITOR_HMP(mon);
-        monitor_read_password(hmp, hmp_change_read_arg, NULL);
+        monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
     }
diff --git a/util/error-report.c b/util/error-report.c
index f333af9249b9..aaa15bc79827 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -11,7 +11,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 
 /*
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 7b9591035e57..a2d1f0244168 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -12,6 +12,7 @@
 
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/qemu-print.h"
 
 /*

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 19:12:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 19:12:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399393.1635494 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZd-0008RV-Lo; Tue, 25 Aug 2026 19:12:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399393.1635494; Tue, 25 Aug 2026 19:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZd-0008RO-IY; Tue, 25 Aug 2026 19:12:41 +0000
Received: by outflank-mailman (input) for mailman id 1399393;
 Tue, 25 Aug 2026 19:12:40 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wywZc-0008RC-Cx
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 19:12:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wywZb-0069WB-Q2
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 21:12:39 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de91e-e002-0a2a0a5209dd-0a2a450ab4bc-6
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:39 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de926-f2d2-0a2a450a0019-aa0a817cae25-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:39 +0200
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-613-jc1F5kuNMgCFWJ1OoF_V0A-1; Tue,
 25 Aug 2026 15:12:34 -0400
Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 9DB4618C0FEF; Tue, 25 Aug 2026 19:12:32 +0000 (UTC)
Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.114])
 by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 79C8F30002F7; Tue, 25 Aug 2026 19:12:31 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787685158;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=57QfcTR5j/zJ5KMJTDu3qOnAc1zj+QlnuAt4vX2DJrQ=;
	b=SoyWS7eBvrH/fxRhefT2W9N4C1sQozLRobQ9cql0ycx6eBKHV7egvLkeuSCoiBsnlfyftd
	TE3twQvjiUvsfzH6XC192zjmAIUqqjczm5v55WVmmqbxJEiA5Nio63EtVe7ZcQ5GlpVOyg
	Zl+TG2MkZJR9Vp9NAcwQAIaCmh8X4TA=
X-MC-Unique: jc1F5kuNMgCFWJ1OoF_V0A-1
X-Mimecast-MFC-AGG-ID: jc1F5kuNMgCFWJ1OoF_V0A_1787685152
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Tue, 25 Aug 2026 23:09:45 +0400
Subject: [PATCH v4 38/49] qdev-monitor: make print_dev() callback take
 MonitorHMP
MIME-Version: 1.0
Message-Id: <20260825-qemu-no-hmp-v4-38-af60857c2fbe@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
In-Reply-To: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>, 
 Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=8798;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=TnV/ecEwZ8dNWntwBJ1/B+qLywO2KqD7Jgy5xW81cUE=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqjeiI1ORwMVhtLFs/MqLkfYMW91qiIkX2bbWKf
 zaoUdClu3aJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCao3oiAAKCRDa6OEJdZac
 5RPJD/9voh4Ssrd7KFIE0Of1vZrgv5Zzbs1/rJAoLNlOOYasoOJkkCKkLa1JiPZnapucPEmaZgk
 tJIpDEUZjgDr4MYLEMX1Ef67nCjqNJwWZvZSNzmdPaCqtjfCwtQ0Ssq8pz5nBHaqwn2bw/pPXap
 yRtz7/QjwE8RGAx8ARfyqqRjiqMFbCAqF0Dy4m2povT+XADWrKkocSmET2f8/6r0yW+AvLzX8Y7
 mIdXyGQyPOPdtz7Sw5wUs6Oi84opLDTv3E0IqvqXlGgWTwDfFClnuf49OFxYDv7OlLFjtkBtxQf
 Q9Zohr7W0CcYFy4H1vYfFTSE0EG2On8Ko+M5o0JsLwmXHwsQCxbuAiIgNnVzWbNOR5nokD5489P
 KwZaItJuo8vmzQ9I24Dw8GQxZ29/qh1ARZFs5ppqgXxIxT992Ll8s3ZknfqZ2MOPNj2zwm62K2I
 99ZzagmgL8Q5tdL3yRe2h3qiMjxbm5dFHZEzHtrxELmoV5qjP5HkMkiQ6WN0mquoT0Frsk4k31l
 HrOA5RjvIhGOF2v3QBPw4pSC4fPyLA3yzimjelERjskqygwttoTQ9z+StNDCsTfqDTmE7f+FvAk
 swtTMwRUm96FjFpwGc5LQ3aOEWOM1hiKl1vYkgo9DgXXyt7/BldDn4F+MT5ItYID3qGc9eYB3Yc
 IPsRMZMFKhJfXJA==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4
X-Mimecast-MFC-PROC-ID: KlfHz8KkB4YBx1zGPM7KXSFQ4hVNcIMY9_XSkYL8pF4_1787685152
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787685159-538D5CFC-31B1F244/0/0
X-purgate-type: clean
X-purgate-size: 8800

The callback is specific to HMP context, avoid unsafe MONITOR_HMP()
cast.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/char/virtio-serial-bus.c | 6 +++---
 hw/core/sysbus.c            | 5 ++---
 hw/misc/auxbus.c            | 7 +++----
 hw/pci/pci-hmp-cmds.c       | 3 +--
 hw/pci/pci-internal.h       | 2 +-
 hw/usb/bus.c                | 5 ++---
 hw/xen/xen-bus.c            | 3 +--
 include/hw/core/qdev.h      | 3 ++-
 system/qdev-monitor.c       | 7 +++----
 9 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 33fdc0846ac3..4dcc4516e45e 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -834,11 +834,11 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+    monitor_hmp_printf(hmp, "%*sport %d, guest %s, host %s, throttle %s\n",
                        indent, "", port->id,
                        port->guest_connected ? "on" : "off",
                        port->host_connected ? "on" : "off",
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 82130ba04698..31c4fdf79d48 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,7 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -249,10 +249,9 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ffa76f83016b..0bb89c5a60ab 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,7 +47,7 @@
 } while (0)
 
 
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
@@ -288,7 +288,7 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
     AUXSlave *s;
@@ -300,8 +300,7 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon),
-                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+    monitor_hmp_printf(hmp, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
                        indent, "",
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 500f821246a9..bcccfaf07f4d 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,9 +135,8 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
diff --git a/hw/pci/pci-internal.h b/hw/pci/pci-internal.h
index a7d6d8a7324e..b7231fab5dc9 100644
--- a/hw/pci/pci-internal.h
+++ b/hw/pci/pci-internal.h
@@ -16,7 +16,7 @@ extern PCIHostStateList pci_host_bridges;
 
 const pci_class_desc *get_class_desc(int class);
 PCIBus *pci_find_bus_nr(PCIBus *bus, int bus_num);
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+void pcibus_dev_print(MonitorHMP *mon, DeviceState *dev, int indent);
 
 int pcie_aer_parse_error_string(const char *error_name,
                                 uint32_t *status, bool *correctable);
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index fe3dbfa2227c..8bd25a9d872a 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,7 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -544,9 +544,8 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 4075b5b001ae..b81a067e7753 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,9 +101,8 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
-static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
+static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 37f7d3355193..1391dc060caf 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -10,6 +10,7 @@
 #include "qom/object.h"
 #include "hw/core/hotplug.h"
 #include "hw/core/resettable.h"
+#include "monitor/hmp.h"
 
 /**
  * DOC: The QEMU Device API
@@ -323,7 +324,7 @@ struct BusClass {
     ObjectClass parent_class;
 
     /* FIXME first arg should be BusState */
-    void (*print_dev)(Monitor *mon, DeviceState *dev, int indent);
+    void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 3860ada2a237..13ac9f8f3be1 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -790,18 +790,17 @@ static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
     }
 }
 
-static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int indent)
+static void bus_print_dev(BusState *bus, MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     BusClass *bc = BUS_GET_CLASS(bus);
 
     if (bc->print_dev) {
-        bc->print_dev(mon, dev, indent);
+        bc->print_dev(hmp, dev, indent);
     }
 }
 
 static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -828,7 +827,7 @@ static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
         qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
-    bus_print_dev(dev->parent_bus, mon, dev, indent);
+    bus_print_dev(dev->parent_bus, hmp, dev, indent);
 }
 
 static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 19:12:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 19:12:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399394.1635503 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZf-0000F6-3Q; Tue, 25 Aug 2026 19:12:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399394.1635503; Tue, 25 Aug 2026 19:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZe-0000E0-Tr; Tue, 25 Aug 2026 19:12:42 +0000
Received: by outflank-mailman (input) for mailman id 1399394;
 Tue, 25 Aug 2026 19:12:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wywZc-0008RD-Rg
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 19:12:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wywZb-00CDYd-RL
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 21:12:39 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de900-8faa-0a2a0a5109dd-0a2a4506ab2e-28
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:39 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de926-195a-0a2a45060019-aa0a817ce05d-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:39 +0200
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-107-3V-NR7mON9-SCl6skE93Sg-1; Tue,
 25 Aug 2026 15:12:33 -0400
Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 5F482195FCDD; Tue, 25 Aug 2026 19:12:25 +0000 (UTC)
Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.114])
 by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 6B0EE18005B4; Tue, 25 Aug 2026 19:12:21 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787685157;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=B3gfQeMRpqcT6fvw5+6QDwVK+TK1Gu++g6G25wuWQdY=;
	b=MdMQZlzioRmHVdImIe/Ul2ZJEmyyj6vOWTx8lDbxCAiQoCzr1KeHqPXotmmuaTWYPdUnhy
	A/oJMw/vwSH1Cwz+Tm6iotJtRBpk2NNA9Y3UVCV5V0j5pVyvjVpBH40hlfmQY3nq9USdep
	660c8t9a5DYKrVV/q9xqqtAdXpiqrPM=
X-MC-Unique: 3V-NR7mON9-SCl6skE93Sg-1
X-Mimecast-MFC-AGG-ID: 3V-NR7mON9-SCl6skE93Sg_1787685145
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Tue, 25 Aug 2026 23:09:43 +0400
Subject: [PATCH v4 36/49] monitor: tighten monitor_printf*()
MIME-Version: 1.0
Message-Id: <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
In-Reply-To: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, 
 "Gonglei (Arei)" <arei.gonglei@huawei.com>, 
 zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>, 
 Hanna Reitz <hreitz@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Ani Sinha <anisinha@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, 
 Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Marcelo Tosatti <mtosatti@redhat.com>, 
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, 
 Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>, 
 Halil Pasic <pasic@linux.ibm.com>, 
 Christian Borntraeger <borntraeger@linux.ibm.com>, 
 Jason Herne <jjherne@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, 
 Matthew Rosato <mjrosato@linux.ibm.com>, 
 Ilya Leoshkevich <iii@linux.ibm.com>, David Hildenbrand <david@kernel.org>, 
 Cornelia Huck <cohuck@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>, 
 Fabiano Rosas <farosas@suse.de>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Stefan Berger <stefanb@linux.vnet.ibm.com>, Zhao Liu <zhao1.liu@intel.com>, 
 Nicholas Piggin <npiggin@gmail.com>, Chinmay Rath <rathc@linux.ibm.com>, 
 Glenn Miles <milesg@linux.ibm.com>, 
 Harsh Prateek Bora <harshpb@linux.ibm.com>, 
 Palmer Dabbelt <palmer@dabbelt.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Weiwei Li <liwei1518@gmail.com>, 
 Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, 
 Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
 Chao Liu <chao.liu@processmission.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, 
 kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, 
 xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=268258;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=deAi5Oa+Rn2mNob+zYtTDbsvfemyws/tuR7OyEF6fto=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqjeiI/nalr50MvmayuYNRrnwgrUrOISz1ndShm
 4mx6cUO2HiJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCao3oiAAKCRDa6OEJdZac
 5exzD/4oqHqbL4A2MpsJTYXt21iUWonjxnVLUquYdYKxXn0r5Wmm2TEcnKsXrZEUVt6bu5Hu8gz
 Cynvh417Z0qDOQ7M/U4ETGU8XXSdeDFM15jpr13ar5E/UafxluyZepHzcuTZJaDqXGNlLCDijtK
 HM3huWDj0d0kIJ311zwbc/MTlmtnlsY7Qcw16avNdmoy15c+5L+Ml6PFIj6VbtTaXVWW3qlsj+Q
 ZdBZhxWGSKEbBkjhYKuYHIn+wwNSH8v2JM71Jo3rBcS2gVJJBisYScKcX37g+drErztRFSCOULU
 0zWxbluycNHy93vGPOZAMWo5pfPmMk2RgGQvX95Rynqut5ykdQR6eDcA76kSmxtSuBINZxys00E
 bK7fmfNQL4dUKTKsTIaO5/izTHZ2ouy7OfMW0vsyAe44O6qfbGyU/7Gr3GQqc/HwFm+U2J2lnSb
 J58jJUrBqWAZQYXciFQj2fLRvDQxueoU1HBjavcCW+eKOhsALKhcJ2DcFFS/N0H2gbM8+vasZua
 jtFfYEaxmO5KBpQeKB/aUrJ/EY06SkfqpGcPzMlTga9M1gnHCJzHM1tAk5pV8gqYE6U4HMt2kfd
 H5qa/FzVS2436LJh7BmDqvZX9BihTECd4pmP+wrVHLbe7hzYkAD5+xlm//FoU6h2kEl5axxQqmf
 LJ05XsVgwFyQaqg==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93
X-Mimecast-MFC-PROC-ID: qWF6G0ce1GPhftmOi4Po1xAQQUtVOR2ADIzTtmLr2CY_1787685145
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787685159-FDA0C4DB-A19B3320/0/0
X-purgate-type: clean
X-purgate-size: 268260

Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
the first parameter from Monitor * to MonitorHMP * to enforce type
safety. The implementation is also simplified: monitor_hmp_vprintf now
directly calls g_strdup_vprintf + monitor_puts, removing the virtual
dispatch via moncls->vprintf.

The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
cast, they are fixed in the following commits.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 audio/audio-hmp-cmds.c                  |   6 +-
 backends/cryptodev-hmp-cmds.c           |   9 +-
 block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
 chardev/char-hmp-cmds.c                 |  12 +-
 disas/disas-mon.c                       |  10 +-
 docs/devel/style.rst                    |   2 +-
 docs/devel/writing-monitor-commands.rst |   8 +-
 dump/dump-hmp-cmds.c                    |   5 +-
 hw/char/virtio-serial-bus.c             |  10 +-
 hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
 hw/core/sysbus.c                        |   5 +-
 hw/hexagon/hexagon_tlb.c                |  44 ++---
 hw/i386/kvm/xen-stubs.c                 |   6 +-
 hw/i386/kvm/xen_evtchn.c                |  21 +--
 hw/i386/sgx-hmp-stub.c                  |   3 +-
 hw/i386/sgx.c                           |  29 ++-
 hw/misc/auxbus.c                        |   9 +-
 hw/misc/mos6522-stub.c                  |   3 +-
 hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
 hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
 hw/pci/pci-stub.c                       |   3 +-
 hw/s390x/s390-skeys.c                   |   9 +-
 hw/s390x/s390-stattrib.c                |  20 +--
 hw/uefi/ovmf-log.c                      |   5 +-
 hw/usb/bus.c                            |  11 +-
 hw/usb/host-libusb.c                    |  21 ++-
 hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++---------------
 hw/xen/xen-bus.c                        |   5 +-
 include/disas/disas.h                   |   4 +-
 include/monitor/hmp.h                   |  12 +-
 migration/dirtyrate.c                   |  46 +++--
 migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----------------
 monitor/hmp-cmds.c                      | 141 +++++++--------
 monitor/hmp.c                           | 143 +++++++--------
 monitor/monitor-internal.h              |   6 -
 monitor/monitor.c                       |  33 ++--
 net/net-hmp-cmds.c                      |  31 ++--
 net/slirp.c                             |  31 ++--
 qom/qom-hmp-cmds.c                      |  27 ++-
 replay/replay-debugging.c               |   5 +-
 stats/stats-hmp-cmds.c                  |  57 +++---
 stubs/hmp-cmd-info_sev.c                |   3 +-
 stubs/monitor-core.c                    |   2 +-
 system/dirtylimit-hmp-cmds.c            |  10 +-
 system/qdev-monitor.c                   |  19 +-
 system/runstate-hmp-cmds.c              |  16 +-
 system/tpm-hmp-cmds.c                   |  29 ++-
 target/i386/cpu-apic.c                  |   3 +-
 target/i386/monitor.c                   | 152 ++++++++--------
 target/i386/sev.c                       |  35 ++--
 target/m68k/monitor.c                   |   3 +-
 target/ppc/monitor.c                    |   3 +-
 target/riscv/monitor.c                  |  55 +++---
 target/sh4/monitor.c                    |  29 ++-
 target/sparc/monitor.c                  |   3 +-
 target/xtensa/monitor.c                 |   3 +-
 tests/unit/test-util-sockets.c          |   2 +-
 tools/qemu-vnc/clipboard.c              |   4 +-
 tools/qemu-vnc/stubs.c                  |   2 +-
 trace/trace-hmp-cmds.c                  |  12 +-
 ui/ui-hmp-cmds.c                        | 115 ++++++------
 util/error-report.c                     |   2 +-
 util/qemu-print.c                       |  11 +-
 63 files changed, 1219 insertions(+), 1327 deletions(-)

diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
index 4d326ec99fdf..94182fe1d71f 100644
--- a/audio/audio-hmp-cmds.c
+++ b/audio/audio-hmp-cmds.c
@@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
 
 void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     CaptureState *s;
 
     warn_report_once("'info capture' is deprecated since v10.2, to be removed");
 
     for (s = capture_head.lh_first, i = 0; s; s = s->entries.le_next, ++i) {
-        monitor_printf(mon, "[%d]: ", i);
+        monitor_hmp_printf(hmp, "[%d]: ", i);
         s->ops.info (s->opaque);
     }
 }
@@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     int freq = qdict_get_try_int(qdict, "freq", 44100);
     int bits = qdict_get_try_int(qdict, "bits", 16);
@@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
     s = g_malloc0 (sizeof (*s));
 
     if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
-        monitor_printf(mon, "Failed to add wave capture\n");
+        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
         g_free (s);
         return;
     }
diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
index fb62428d795a..aafa4b970d24 100644
--- a/backends/cryptodev-hmp-cmds.c
+++ b/backends/cryptodev-hmp-cmds.c
@@ -19,7 +19,6 @@
 
 void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     QCryptodevInfoList *il;
     QCryptodevBackendServiceTypeList *sl;
     QCryptodevBackendClientList *cl;
@@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
                 services = tmp_services;
             }
         }
-        monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
+        monitor_hmp_printf(hmp, "%s: service=[%s]\n", info->id, services);
 
         for (cl = info->client; cl; cl = cl->next) {
             QCryptodevBackendClient *client = cl->value;
-            monitor_printf(mon, "    queue %" PRIu32 ": type=%s\n",
-                           client->queue,
-                           QCryptodevBackendType_str(client->type));
+            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=%s\n",
+                               client->queue,
+                               QCryptodevBackendType_str(client->type));
         }
     }
 
diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-cmds.c
index a2666e2f1b9b..7bae4d425c6d 100644
--- a/block/monitor/block-hmp-cmds.c
+++ b/block/monitor/block-hmp-cmds.c
@@ -89,7 +89,6 @@ out:
 
 void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     DriveInfo *dinfo;
     QemuOpts *opts;
@@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 
     switch (dinfo->type) {
     case IF_NONE:
-        monitor_printf(mon, "OK\n");
+        monitor_hmp_printf(hmp, "OK\n");
         break;
     default:
         error_setg(&err, "Can't hot-add drive to type %d", dinfo->type);
@@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdict)
     hmp_handle_error(hmp, err);
 }
 
-static void print_block_info(Monitor *mon, BlockInfo *info,
+static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
                              BlockDeviceInfo *inserted, bool verbose)
 {
+    Monitor *mon = MONITOR(hmp);
     ImageInfo *image_info;
 
     assert(!info || !info->inserted || info->inserted == inserted);
@@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     if (info && *info->device) {
         monitor_puts(mon, info->device);
         if (inserted && inserted->node_name) {
-            monitor_printf(mon, " (%s)", inserted->node_name);
+            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
         }
     } else {
         assert(info || inserted);
@@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (inserted) {
-        monitor_printf(mon, ": %s (%s%s%s%s)\n",
-                       inserted->file,
-                       inserted->drv,
-                       inserted->ro ? ", read-only" : "",
-                       inserted->encrypted ? ", encrypted" : "",
-                       inserted->active ? "" : ", inactive");
+        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
+                           inserted->file,
+                           inserted->drv,
+                           inserted->ro ? ", read-only" : "",
+                           inserted->encrypted ? ", encrypted" : "",
+                           inserted->active ? "" : ", inactive");
     } else {
-        monitor_printf(mon, ": [not inserted]\n");
+        monitor_hmp_printf(hmp, ": [not inserted]\n");
     }
 
     if (info) {
         if (info->qdev) {
-            monitor_printf(mon, "    Attached to:      %s\n", info->qdev);
+            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info->qdev);
         }
         if (info->has_io_status && info->io_status != BLOCK_DEVICE_IO_STATUS_OK) {
-            monitor_printf(mon, "    I/O status:       %s\n",
-                           BlockDeviceIoStatus_str(info->io_status));
+            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
+                               BlockDeviceIoStatus_str(info->io_status));
         }
 
         if (info->removable) {
-            monitor_printf(mon, "    Removable device: %slocked, tray %s\n",
-                           info->locked ? "" : "not ",
-                           info->tray_open ? "open" : "closed");
+            monitor_hmp_printf(hmp, "    Removable device: %slocked, tray %s\n",
+                               info->locked ? "" : "not ",
+                               info->tray_open ? "open" : "closed");
         }
     }
 
@@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
         return;
     }
 
-    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
-                   inserted->cache->writeback ? "writeback" : "writethrough",
-                   inserted->cache->direct ? ", direct" : "",
-                   inserted->cache->no_flush ? ", ignore flushes" : "");
+    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
+                       inserted->cache->writeback ? "writeback" : "writethrough",
+                       inserted->cache->direct ? ", direct" : "",
+                       inserted->cache->no_flush ? ", ignore flushes" : "");
 
     if (inserted->backing_file) {
-        monitor_printf(mon,
-                       "    Backing file:     %s "
-                       "(chain depth: %" PRId64 ")\n",
-                       inserted->backing_file,
-                       inserted->backing_file_depth);
+        monitor_hmp_printf(hmp,
+                           "    Backing file:     %s "
+                           "(chain depth: %" PRId64 ")\n",
+                           inserted->backing_file,
+                           inserted->backing_file_depth);
     }
 
     if (inserted->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF) {
-        monitor_printf(mon, "    Detect zeroes:    %s\n",
+        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
                 BlockdevDetectZeroesOptions_str(inserted->detect_zeroes));
     }
 
     if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
         inserted->iops || inserted->iops_rd || inserted->iops_wr)
     {
-        monitor_printf(mon, "    I/O throttling:   bps=%" PRId64
+        monitor_hmp_printf(hmp, "    I/O throttling:   bps=%" PRId64
                         " bps_rd=%" PRId64  " bps_wr=%" PRId64
                         " bps_max=%" PRId64
                         " bps_rd_max=%" PRId64
@@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (verbose) {
-        monitor_printf(mon, "\nImages:\n");
+        monitor_hmp_printf(hmp, "\nImages:\n");
         image_info = inserted->image;
         while (1) {
             bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, false);
@@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
 
 void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockInfoList *block_list, *info;
     BlockDeviceInfoList *blockdev_list, *blockdev;
     const char *device = qdict_get_try_str(qdict, "device");
@@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (info != block_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, info->value, info->value->inserted,
+        print_block_info(hmp, info->value, info->value->inserted,
                          verbose);
         printed = true;
     }
@@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (blockdev != blockdev_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, NULL, blockdev->value, verbose);
+        print_block_info(hmp, NULL, blockdev->value, verbose);
     }
     qapi_free_BlockDeviceInfoList(blockdev_list);
 }
 
 void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockStatsList *stats_list, *stats;
 
     stats_list = qmp_query_blockstats(false, false, NULL);
@@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
 
-        monitor_printf(mon, "%s%s: idle_time_ns=%" PRId64 "\n",
-                       stats != stats_list ? "\n" : "",
-                       stats->value->device,
-                       stats->value->stats->idle_time_ns);
-        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
-                       "operations", "total_time_ns", "merged");
-        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->rd_bytes,
-                       stats->value->stats->rd_operations,
-                       stats->value->stats->rd_total_time_ns,
-                       stats->value->stats->rd_merged);
-        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->wr_bytes,
-                       stats->value->stats->wr_operations,
-                       stats->value->stats->wr_total_time_ns,
-                       stats->value->stats->wr_merged);
-        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
-                       "",
-                       stats->value->stats->flush_operations,
-                       stats->value->stats->flush_total_time_ns);
+        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=%" PRId64 "\n",
+                           stats != stats_list ? "\n" : "",
+                           stats->value->device,
+                           stats->value->stats->idle_time_ns);
+        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes",
+                           "operations", "total_time_ns", "merged");
+        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->rd_bytes,
+                           stats->value->stats->rd_operations,
+                           stats->value->stats->rd_total_time_ns,
+                           stats->value->stats->rd_merged);
+        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->wr_bytes,
+                           stats->value->stats->wr_operations,
+                           stats->value->stats->wr_total_time_ns,
+                           stats->value->stats->wr_merged);
+        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
+                           "",
+                           stats->value->stats->flush_operations,
+                           stats->value->stats->flush_total_time_ns);
     }
 
     qapi_free_BlockStatsList(stats_list);
@@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockJobInfoList *list;
 
     list = qmp_query_block_jobs(&error_abort);
 
     if (!list) {
-        monitor_printf(mon, "No active jobs\n");
+        monitor_hmp_printf(hmp, "No active jobs\n");
         return;
     }
 
     while (list) {
         if (list->value->type == JOB_TYPE_STREAM) {
-            monitor_printf(mon, "Streaming device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Streaming device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         } else {
-            monitor_printf(mon, "Type %s, device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           JobType_str(list->value->type),
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               JobType_str(list->value->type),
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         }
         list = list->next;
     }
@@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockDriverState *bs, *bs1;
     BdrvNextIterator it1;
     QEMUSnapshotInfo *sn_tab, *sn;
@@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     nb_sns = bdrv_snapshot_list(bs, &sn_tab);
 
     if (nb_sns < 0) {
-        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
+        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_sns);
         return;
     }
 
@@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (no_snapshot) {
-        monitor_printf(mon, "There is no snapshot available.\n");
+        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
         return;
     }
 
@@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
             }
         }
     }
-    monitor_printf(mon, "List of snapshots present on all disks:\n");
+    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n");
 
     if (total > 0) {
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         for (i = 0; i < total; i++) {
             sn = &sn_tab[global_snapshots[i]];
             /*
@@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
              */
             pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
             bdrv_snapshot_dump(sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     } else {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
     }
 
     QTAILQ_FOREACH(image_entry, &image_list, next) {
         if (QTAILQ_EMPTY(&image_entry->snapshots)) {
             continue;
         }
-        monitor_printf(mon,
-                       "\nList of partial (non-loadable) snapshots on '%s':\n",
-                       image_entry->imagename);
+        monitor_hmp_printf(hmp,
+                           "\nList of partial (non-loadable) snapshots on '%s':\n",
+                           image_entry->imagename);
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) {
             bdrv_snapshot_dump(&snapshot_entry->sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
@@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     g_free(global_snapshots);
 }
 
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp)
 {
diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
index 71017fd2d19e..fb0560054b7b 100644
--- a/chardev/char-hmp-cmds.c
+++ b/chardev/char-hmp-cmds.c
@@ -26,12 +26,11 @@
 
 void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     ChardevInfoList *char_info, *info;
 
     char_info = qmp_query_chardev(NULL);
     for (info = char_info; info; info = info->next) {
-        monitor_printf(mon, "%s: filename=%s\n", info->value->label,
+        monitor_hmp_printf(hmp, "%s: filename=%s\n", info->value->label,
                                                  info->value->filename);
     }
 
@@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *chardev = qdict_get_str(qdict, "device");
     char *data;
@@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
         unsigned char ch = data[i];
 
         if (ch == '\\') {
-            monitor_printf(mon, "\\\\");
+            monitor_hmp_printf(hmp, "\\\\");
         } else if ((ch < 0x20 && ch != '\n' && ch != '\t') || ch == 0x7F) {
-            monitor_printf(mon, "\\u%04X", ch);
+            monitor_hmp_printf(hmp, "\\u%04X", ch);
         } else {
-            monitor_printf(mon, "%c", ch);
+            monitor_hmp_printf(hmp, "%c", ch);
         }
 
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     g_free(data);
 }
 
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index bc9dec3a7761..32e4220181a8 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
 }
 
 /* Disassembler for the monitor.  */
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical)
 {
     int count, i;
@@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
     s.info.buffer_vma = pc;
 
     if (s.info.cap_arch >= 0 && cap_disas_monitor(&s.info, pc, nb_insn)) {
-        monitor_puts(mon, ds->str);
+        monitor_puts(MONITOR(hmp), ds->str);
         return;
     }
 
     if (!s.info.print_insn) {
-        monitor_printf(mon, "0x%08" PRIx64
-                       ": Asm output not supported on this arch\n", pc);
+        monitor_hmp_printf(hmp, "0x%08" PRIx64
+                           ": Asm output not supported on this arch\n", pc);
         return;
     }
 
@@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
         pc += count;
     }
 
-    monitor_puts(mon, ds->str);
+    monitor_puts(MONITOR(hmp), ds->str);
 }
diff --git a/docs/devel/style.rst b/docs/devel/style.rst
index 6c5f94cc5098..6876d3a59ec7 100644
--- a/docs/devel/style.rst
+++ b/docs/devel/style.rst
@@ -754,7 +754,7 @@ Error handling and reporting
 Reporting errors to the human user
 ----------------------------------
 
-Do not use printf(), fprintf() or monitor_printf().  Instead, use
+Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
 error_report() or error_vreport() from error-report.h.  This ensures the
 error is reported in the right place (current monitor or stderr), and in
 a uniform format.
diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
index 7ae7efe32759..baf94cbdefab 100644
--- a/docs/devel/writing-monitor-commands.rst
+++ b/docs/devel/writing-monitor-commands.rst
@@ -479,7 +479,7 @@ The HMP command
 
 Here's the HMP counterpart of the query-option-roms command::
 
- void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
+ void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
  {
      Error *err = NULL;
      OptionRomInfoList *info_list, *tail;
@@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-roms command::
 
      for (tail = info_list; tail; tail = tail->next) {
          info = tail->value;
-         monitor_printf(mon, "%s", info->filename);
+         monitor_hmp_printf(mon, "%s", info->filename);
          if (info->has_bootindex) {
-             monitor_printf(mon, " %" PRId64, info->bootindex);
+             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
          }
-         monitor_printf(mon, "\n");
+         monitor_hmp_printf(mon, "\n");
      }
 
      qapi_free_OptionRomInfoList(info_list);
diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
index 104ab5d2a53a..c7045c2d7314 100644
--- a/dump/dump-hmp-cmds.c
+++ b/dump/dump-hmp-cmds.c
@@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DumpQueryResult *result = qmp_query_dump(NULL);
 
     assert(result && result->status < DUMP_STATUS__MAX);
-    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status));
+    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->status));
 
     if (result->status == DUMP_STATUS_ACTIVE) {
         float percent = 0;
         assert(result->total != 0);
         percent = 100.0 * result->completed / result->total;
-        monitor_printf(mon, "Finished: %.2f %%\n", percent);
+        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
     }
 
     qapi_free_DumpQueryResult(result);
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 02604740f86a..33fdc0846ac3 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
-                   indent, "", port->id,
-                   port->guest_connected ? "on" : "off",
-                   port->host_connected ? "on" : "off",
-                   port->throttled ? "on" : "off");
+    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+                       indent, "", port->id,
+                       port->guest_connected ? "on" : "off",
+                       port->host_connected ? "on" : "off",
+                       port->throttled ? "on" : "off");
 }
 
 /* This function is only used if a port id is not provided by the user */
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 702c798ccc56..10a633af0780 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -27,7 +27,6 @@
 
 void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CpuInfoFastList *cpu_list, *cpu;
 
     cpu_list = qmp_query_cpus_fast(NULL);
@@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
             active = '*';
         }
 
-        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
-                       cpu->value->cpu_index);
-        monitor_printf(mon, " thread_id=%" PRId64 " model=%s\n",
-                       cpu->value->thread_id, cpu_model);
+        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
+                           cpu->value->cpu_index);
+        monitor_hmp_printf(hmp, " thread_id=%" PRId64 " model=%s\n",
+                           cpu->value->thread_id, cpu_model);
     }
 
     qapi_free_CpuInfoFastList(cpu_list);
@@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     HotpluggableCPUList *l = qmp_query_hotpluggable_cpus(&err);
     HotpluggableCPUList *saved = l;
@@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Hotpluggable CPUs:\n");
+    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
     while (l) {
-        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
-        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
-                       l->value->vcpus_count);
+        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
+        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
+                           l->value->vcpus_count);
         if (l->value->qom_path) {
-            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_path);
+            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->qom_path);
         }
 
         c = l->value->props;
-        monitor_printf(mon, "  CPUInstance Properties:\n");
+        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
         if (c->has_node_id) {
-            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
+            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
         }
         if (c->has_drawer_id) {
-            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
+            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
         }
         if (c->has_book_id) {
-            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
+            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
         }
         if (c->has_socket_id) {
-            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
+            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
         }
         if (c->has_die_id) {
-            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
+            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
         }
         if (c->has_cluster_id) {
-            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
-                           c->cluster_id);
+            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n",
+                               c->cluster_id);
         }
         if (c->has_module_id) {
-            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
-                           c->module_id);
+            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n",
+                               c->module_id);
         }
         if (c->has_core_id) {
-            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
+            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
         }
         if (c->has_thread_id) {
-            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
+            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
         }
 
         l = l->next;
@@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemdevList *memdev_list = qmp_query_memdev(&err);
     MemdevList *m = memdev_list;
@@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
     while (m) {
         v = string_output_visitor_new(false, &str);
         visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_abort);
-        monitor_printf(mon, "memory backend: %s\n", m->value->id);
-        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
-        monitor_printf(mon, "  merge: %s\n",
-                       m->value->merge ? "true" : "false");
-        monitor_printf(mon, "  dump: %s\n",
-                       m->value->dump ? "true" : "false");
-        monitor_printf(mon, "  prealloc: %s\n",
-                       m->value->prealloc ? "true" : "false");
-        monitor_printf(mon, "  share: %s\n",
-                       m->value->share ? "true" : "false");
+        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
+        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->size);
+        monitor_hmp_printf(hmp, "  merge: %s\n",
+                           m->value->merge ? "true" : "false");
+        monitor_hmp_printf(hmp, "  dump: %s\n",
+                           m->value->dump ? "true" : "false");
+        monitor_hmp_printf(hmp, "  prealloc: %s\n",
+                           m->value->prealloc ? "true" : "false");
+        monitor_hmp_printf(hmp, "  share: %s\n",
+                           m->value->share ? "true" : "false");
         if (m->value->has_reserve) {
-            monitor_printf(mon, "  reserve: %s\n",
-                           m->value->reserve ? "true" : "false");
+            monitor_hmp_printf(hmp, "  reserve: %s\n",
+                               m->value->reserve ? "true" : "false");
         }
-        monitor_printf(mon, "  policy: %s\n",
-                       HostMemPolicy_str(m->value->policy));
+        monitor_hmp_printf(hmp, "  policy: %s\n",
+                           HostMemPolicy_str(m->value->policy));
         visit_complete(v, &str);
-        monitor_printf(mon, "  host nodes: %s\n", str);
+        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
 
         g_free(str);
         visit_free(v);
         m = m->next;
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_MemdevList(memdev_list);
     hmp_handle_error(hmp, err);
@@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     KvmInfo *info;
 
     info = qmp_query_kvm(NULL);
-    monitor_printf(mon, "kvm support: ");
+    monitor_hmp_printf(hmp, "kvm support: ");
     if (info->present) {
-        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disabled");
+        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "disabled");
     } else {
-        monitor_printf(mon, "not compiled\n");
+        monitor_hmp_printf(hmp, "not compiled\n");
     }
 
     qapi_free_KvmInfo(info);
@@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     AcceleratorInfo *info;
     AcceleratorList *accel;
 
@@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
     for (accel = info->present; accel; accel = accel->next) {
         char trail = accel->next ? ' ' : '\n';
         if (info->enabled == accel->value) {
-            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->value), trail);
         } else {
-            monitor_printf(mon, "%s%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->value), trail);
         }
     }
 
@@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     UuidInfo *info;
 
     info = qmp_query_uuid(NULL);
-    monitor_printf(mon, "%s\n", info->UUID);
+    monitor_hmp_printf(hmp, "%s\n", info->UUID);
     qapi_free_UuidInfo(info);
 }
 
 void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BalloonInfo *info;
     Error *err = NULL;
 
@@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
+    monitor_hmp_printf(hmp, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
 
     qapi_free_BalloonInfo(info);
 }
@@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *filename = qdict_get_str(qdict, "filename");
     uint64_t addr = qdict_get_int(qdict, "val");
@@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
     int cpu_index = monitor_hmp_get_cpu_index(hmp);
 
     if (cpu_index < 0) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
@@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryDeviceInfoList *info_list = qmp_query_memory_devices(&err);
     MemoryDeviceInfoList *info;
@@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
             case MEMORY_DEVICE_INFO_KIND_NVDIMM:
                 di = value->type == MEMORY_DEVICE_INFO_KIND_DIMM ?
                      value->u.dimm.data : value->u.nvdimm.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               di->id ? di->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->addr);
-                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot);
-                monitor_printf(mon, "  node: %" PRId64 "\n", di->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size);
-                monitor_printf(mon, "  memdev: %s\n", di->memdev);
-                monitor_printf(mon, "  hotplugged: %s\n",
-                               di->hotplugged ? "true" : "false");
-                monitor_printf(mon, "  hotpluggable: %s\n",
-                               di->hotpluggable ? "true" : "false");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   di->id ? di->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di->addr);
+                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->slot);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
+                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
+                                   di->hotplugged ? "true" : "false");
+                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
+                                   di->hotpluggable ? "true" : "false");
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
                 vpi = value->u.virtio_pmem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vpi->id ? vpi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size);
-                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vpi->id ? vpi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
                 vmi = value->u.virtio_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vmi->id ? vmi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node);
-                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
-                               vmi->requested_size);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size);
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->max_size);
-                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
-                               vmi->block_size);
-                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vmi->id ? vmi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->node);
+                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "\n",
+                                   vmi->requested_size);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", vmi->max_size);
+                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
+                                   vmi->block_size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
                 se = value->u.sgx_epc.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               se->id ? se->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size);
-                monitor_printf(mon, "  node: %" PRId64 "\n", se->node);
-                monitor_printf(mon, "  memdev: %s\n", se->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   se->id ? se->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->size);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->node);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
                 hi = value->u.hv_balloon.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               hi->id ? hi->id : "");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   hi->id ? hi->id : "");
                 if (hi->has_memaddr) {
-                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
-                                   hi->memaddr);
+                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n",
+                                       hi->memaddr);
                 }
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->max_size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", hi->max_size);
                 if (hi->memdev) {
-                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
+                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memdev);
                 }
                 break;
             case MEMORY_DEVICE_INFO_KIND_SP_MEM:
                 spmi = value->u.sp_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               spmi->id ? spmi->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->addr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->size);
-                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   spmi->id ? spmi->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spmi->addr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev);
                 break;
             default:
                 g_assert_not_reached();
@@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     GuidInfo *info = qmp_query_vm_generation_id(&err);
     if (info) {
-        monitor_printf(mon, "%s\n", info->guid);
+        monitor_hmp_printf(hmp, "%s\n", info->guid);
     }
     hmp_handle_error(hmp, err);
     qapi_free_GuidInfo(info);
@@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryInfo *info = qmp_query_memory_size_summary(&err);
     if (info) {
-        monitor_printf(mon, "base memory: %" PRIu64 "\n",
-                       info->base_memory);
+        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
+                           info->base_memory);
 
         if (info->has_plugged_memory) {
-            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
-                           info->plugged_memory);
+            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
+                               info->plugged_memory);
         }
 
         qapi_free_MemoryInfo(info);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 13df7cbafe10..82130ba04698 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
     for (i = 0; i < s->num_mmio; i++) {
         size = memory_region_size(s->mmio[i].memory);
-        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                       indent, "", s->mmio[i].addr, size);
+        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                           indent, "", s->mmio[i].addr, size);
     }
 }
 
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index 2d878cee736d..576929ff224b 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t entry)
 
 bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
+
     if (GET_PTE_V(entry)) {
         uint64_t PA = hex_tlb_phys_addr(entry);
         uint64_t VA = hex_tlb_virt_addr(entry);
-        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
-        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
-                       " A1:%" PRId64 " A0:%" PRId64,
-                       GET_PTE_V(entry),
-                       GET_PTE_G(entry),
-                       GET_PTE_ATR1(entry),
-                       GET_PTE_ATR0(entry));
-        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
-                       GET_PTE_ASID(entry), VA);
-        monitor_printf(mon,
-                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
-                       " U:%" PRId64 " C:%" PRId64,
-                       GET_PTE_X(entry),
-                       GET_PTE_W(entry),
-                       GET_PTE_R(entry),
-                       GET_PTE_U(entry),
-                       GET_PTE_C(entry));
-        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
-                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
-                       hex_tlb_page_size_bytes(entry));
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
+        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
+                           " A1:%" PRId64 " A0:%" PRId64,
+                           GET_PTE_V(entry),
+                           GET_PTE_G(entry),
+                           GET_PTE_ATR1(entry),
+                           GET_PTE_ATR0(entry));
+        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
+                           GET_PTE_ASID(entry), VA);
+        monitor_hmp_printf(hmp,
+                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
+                           " U:%" PRId64 " C:%" PRId64,
+                           GET_PTE_X(entry),
+                           GET_PTE_W(entry),
+                           GET_PTE_R(entry),
+                           GET_PTE_U(entry),
+                           GET_PTE_C(entry));
+        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
+                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
+                           hex_tlb_page_size_bytes(entry));
+        monitor_hmp_printf(hmp, "\n");
         return true;
     }
 
diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
index ab1eb14f99e0..5ed71583281a 100644
--- a/hw/i386/kvm/xen-stubs.c
+++ b/hw/i386/kvm/xen-stubs.c
@@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 00dff6ee8760..b2135020f27f 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **errp)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     EvtchnInfoList *iter, *info_list;
     Error *err = NULL;
 
@@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
     for (iter = info_list; iter; iter = iter->next) {
         EvtchnInfo *info = iter->value;
 
-        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info->vcpu,
-                       EvtchnPortType_str(info->type));
+        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, info->vcpu,
+                           EvtchnPortType_str(info->type));
         if (info->type != EVTCHN_PORT_TYPE_IPI) {
-            monitor_printf(mon,  "(");
+            monitor_hmp_printf(hmp,  "(");
             if (info->remote_domain) {
-                monitor_printf(mon, "%s:", info->remote_domain);
+                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
             }
-            monitor_printf(mon, "%d)", info->target);
+            monitor_hmp_printf(hmp, "%d)", info->target);
         }
         if (info->pending) {
-            monitor_printf(mon, " PENDING");
+            monitor_hmp_printf(hmp, " PENDING");
         }
         if (info->masked) {
-            monitor_printf(mon, " MASKED");
+            monitor_hmp_printf(hmp, " MASKED");
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_EvtchnInfoList(info_list);
@@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int port = qdict_get_int(qdict, "port");
     Error *err = NULL;
 
@@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
     if (err) {
         hmp_handle_error(hmp, err);
     } else {
-        monitor_printf(mon, "Delivered port %d\n", port);
+        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
     }
 }
-
diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
index a4848ae1d1a7..b7afb26886a8 100644
--- a/hw/i386/sgx-hmp-stub.c
+++ b/hw/i386/sgx-hmp-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SGX is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
 }
diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
index 77b41d234c9f..634e33e819ce 100644
--- a/hw/i386/sgx.c
+++ b/hw/i386/sgx.c
@@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     SgxEpcSectionList *section_list, *section;
     g_autoptr(SgxInfo) info = qmp_query_sgx(&err);
@@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
         error_report_err(err);
         return;
     }
-    monitor_printf(mon, "SGX support: %s\n",
-                   info->sgx ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX1 support: %s\n",
-                   info->sgx1 ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX2 support: %s\n",
-                   info->sgx2 ? "enabled" : "disabled");
-    monitor_printf(mon, "FLC support: %s\n",
-                   info->flc ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX support: %s\n",
+                       info->sgx ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
+                       info->sgx1 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
+                       info->sgx2 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "FLC support: %s\n",
+                       info->flc ? "enabled" : "disabled");
 
     section_list = info->sections;
     for (section = section_list; section; section = section->next) {
-        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
-                       section->value->node);
-        monitor_printf(mon, "size=%" PRIu64 "\n",
-                       section->value->size);
+        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
+                           section->value->node);
+        monitor_hmp_printf(hmp, "size=%" PRIu64 "\n",
+                           section->value->size);
         size += section->value->size;
     }
-    monitor_printf(mon, "total size=%" PRIu64 "\n",
-                   size);
+    monitor_hmp_printf(hmp, "total size=%" PRIu64 "\n",
+                       size);
 }
 
 bool check_sgx_support(void)
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ac2525b90fec..ffa76f83016b 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                   indent, "",
-                   object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
-                   memory_region_size(s->mmio));
+    monitor_hmp_printf(MONITOR_HMP(mon),
+                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                       indent, "",
+                       object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
+                       memory_region_size(s->mmio));
 }
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
index 6a7d76292f00..154cd32ed88b 100644
--- a/hw/misc/mos6522-stub.c
+++ b/hw/misc/mos6522-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU\n");
 }
diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp-cmds.c
index 6405ce26dd65..5099d59cc620 100644
--- a/hw/net/rocker/rocker-hmp-cmds.c
+++ b/hw/net/rocker/rocker-hmp-cmds.c
@@ -22,7 +22,6 @@
 
 void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_str(qdict, "name");
     RockerSwitch *rocker;
     Error *err = NULL;
@@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "name: %s\n", rocker->name);
-    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
-    monitor_printf(mon, "ports: %d\n", rocker->ports);
+    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
+    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
+    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
 
     qapi_free_RockerSwitch(rocker);
 }
 
 void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerPortList *list, *port;
     const char *name = qdict_get_str(qdict, "name");
     Error *err = NULL;
@@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "            ena/    speed/ auto\n");
-    monitor_printf(mon, "      port  link    duplex neg?\n");
+    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
+    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
 
     for (port = list; port; port = port->next) {
-        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
-                       port->value->name,
-                       port->value->enabled ? port->value->link_up ?
-                       "up" : "down" : "!ena",
-                       port->value->speed == 10000 ? "10G" : "??",
-                       port->value->duplex ? "FD" : "HD",
-                       port->value->autoneg ? "Yes" : "No");
+        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
+                           port->value->name,
+                           port->value->enabled ? port->value->link_up ?
+                           "up" : "down" : "!ena",
+                           port->value->speed == 10000 ? "10G" : "??",
+                           port->value->duplex ? "FD" : "HD",
+                           port->value->autoneg ? "Yes" : "No");
     }
 
     qapi_free_RockerPortList(list);
@@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaFlowList *list, *info;
     const char *name = qdict_get_str(qdict, "name");
     uint32_t tbl_id = qdict_get_try_int(qdict, "tbl_id", -1);
@@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
+    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
 
     for (info = list; info; info = info->next) {
         RockerOfDpaFlow *flow = info->value;
@@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         RockerOfDpaFlowAction *action = flow->action;
 
         if (flow->hits) {
-            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
-                           key->priority, key->tbl_id, flow->hits);
+            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
+                               key->priority, key->tbl_id, flow->hits);
         } else {
-            monitor_printf(mon, "%-4d %-3d     ",
-                           key->priority, key->tbl_id);
+            monitor_hmp_printf(hmp, "%-4d %-3d     ",
+                               key->priority, key->tbl_id);
         }
 
         if (key->has_in_pport) {
-            monitor_printf(mon, " pport %d", key->in_pport);
+            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
             if (mask->has_in_pport) {
-                monitor_printf(mon, "(0x%x)", mask->in_pport);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
             }
         }
 
         if (key->has_vlan_id) {
-            monitor_printf(mon, " vlan %d",
-                           key->vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " vlan %d",
+                               key->vlan_id & VLAN_VID_MASK);
             if (mask->has_vlan_id) {
-                monitor_printf(mon, "(0x%x)", mask->vlan_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
             }
         }
 
         if (key->has_tunnel_id) {
-            monitor_printf(mon, " tunnel %d", key->tunnel_id);
+            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
             if (mask->has_tunnel_id) {
-                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
             }
         }
 
         if (key->has_eth_type) {
             switch (key->eth_type) {
             case 0x0806:
-                monitor_printf(mon, " ARP");
+                monitor_hmp_printf(hmp, " ARP");
                 break;
             case 0x0800:
-                monitor_printf(mon, " IP");
+                monitor_hmp_printf(hmp, " IP");
                 break;
             case 0x86dd:
-                monitor_printf(mon, " IPv6");
+                monitor_hmp_printf(hmp, " IPv6");
                 break;
             case 0x8809:
-                monitor_printf(mon, " LACP");
+                monitor_hmp_printf(hmp, " LACP");
                 break;
             case 0x88cc:
-                monitor_printf(mon, " LLDP");
+                monitor_hmp_printf(hmp, " LLDP");
                 break;
             default:
-                monitor_printf(mon, " eth type 0x%04x", key->eth_type);
+                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_type);
                 break;
             }
         }
@@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_src, "01:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
             } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any ucast>");
+                monitor_hmp_printf(hmp, " src <any ucast>");
             } else {
-                monitor_printf(mon, " src %s", key->eth_src);
+                monitor_hmp_printf(hmp, " src %s", key->eth_src);
                 if (mask->eth_src) {
-                    monitor_printf(mon, "(%s)", mask->eth_src);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
                 }
             }
         }
@@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_dst, "01:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
             } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any ucast>");
+                monitor_hmp_printf(hmp, " dst <any ucast>");
             } else {
-                monitor_printf(mon, " dst %s", key->eth_dst);
+                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
                 if (mask->eth_dst) {
-                    monitor_printf(mon, "(%s)", mask->eth_dst);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
                 }
             }
         }
 
         if (key->has_ip_proto) {
-            monitor_printf(mon, " proto %d", key->ip_proto);
+            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
             if (mask->has_ip_proto) {
-                monitor_printf(mon, "(0x%x)", mask->ip_proto);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
             }
         }
 
         if (key->has_ip_tos) {
-            monitor_printf(mon, " TOS %d", key->ip_tos);
+            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
             if (mask->has_ip_tos) {
-                monitor_printf(mon, "(0x%x)", mask->ip_tos);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
             }
         }
 
         if (key->ip_dst) {
-            monitor_printf(mon, " dst %s", key->ip_dst);
+            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
         }
 
         if (action->has_goto_tbl || action->has_group_id ||
             action->has_new_vlan_id) {
-            monitor_printf(mon, " -->");
+            monitor_hmp_printf(hmp, " -->");
         }
 
         if (action->has_new_vlan_id) {
-            monitor_printf(mon, " apply new vlan %d",
-                           ntohs(action->new_vlan_id));
+            monitor_hmp_printf(hmp, " apply new vlan %d",
+                               ntohs(action->new_vlan_id));
         }
 
         if (action->has_group_id) {
-            monitor_printf(mon, " write group 0x%08x", action->group_id);
+            monitor_hmp_printf(hmp, " write group 0x%08x", action->group_id);
         }
 
         if (action->has_goto_tbl) {
-            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
+            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaFlowList(list);
@@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaGroupList *list, *g;
     const char *name = qdict_get_str(qdict, "name");
     uint8_t type = qdict_get_try_int(qdict, "type", 9);
@@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "id (decode) --> buckets\n");
+    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
 
     for (g = list; g; g = g->next) {
         RockerOfDpaGroup *group = g->value;
         bool set = false;
 
-        monitor_printf(mon, "0x%08x", group->id);
+        monitor_hmp_printf(hmp, "0x%08x", group->id);
 
-        monitor_printf(mon, " (type %s", group->type == 0 ? "L2 interface" :
+        monitor_hmp_printf(hmp, " (type %s", group->type == 0 ? "L2 interface" :
                                          group->type == 1 ? "L2 rewrite" :
                                          group->type == 2 ? "L3 unicast" :
                                          group->type == 3 ? "L2 multicast" :
@@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
                                          "unknown");
 
         if (group->has_vlan_id) {
-            monitor_printf(mon, " vlan %d", group->vlan_id);
+            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
         }
 
         if (group->has_pport) {
-            monitor_printf(mon, " pport %d", group->pport);
+            monitor_hmp_printf(hmp, " pport %d", group->pport);
         }
 
         if (group->has_index) {
-            monitor_printf(mon, " index %d", group->index);
+            monitor_hmp_printf(hmp, " index %d", group->index);
         }
 
-        monitor_printf(mon, ") -->");
+        monitor_hmp_printf(hmp, ") -->");
 
         if (group->has_set_vlan_id && group->set_vlan_id) {
             set = true;
-            monitor_printf(mon, " set vlan %d",
-                           group->set_vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " set vlan %d",
+                               group->set_vlan_id & VLAN_VID_MASK);
         }
 
         if (group->set_eth_src) {
             if (!set) {
                 set = true;
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " src %s", group->set_eth_src);
+            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
         }
 
         if (group->set_eth_dst) {
             if (!set) {
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " dst %s", group->set_eth_dst);
+            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
         }
 
         if (group->has_ttl_check && group->ttl_check) {
-            monitor_printf(mon, " check TTL");
+            monitor_hmp_printf(hmp, " check TTL");
         }
 
         if (group->has_group_id && group->group_id) {
-            monitor_printf(mon, " group id 0x%08x", group->group_id);
+            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_id);
         }
 
         if (group->has_pop_vlan && group->pop_vlan) {
-            monitor_printf(mon, " pop vlan");
+            monitor_hmp_printf(hmp, " pop vlan");
         }
 
         if (group->has_out_pport) {
-            monitor_printf(mon, " out pport %d", group->out_pport);
+            monitor_hmp_printf(hmp, " out pport %d", group->out_pport);
         }
 
         if (group->has_group_ids) {
             struct uint32List *id;
 
-            monitor_printf(mon, " groups [");
+            monitor_hmp_printf(hmp, " groups [");
             for (id = group->group_ids; id; id = id->next) {
-                monitor_printf(mon, "0x%08x", id->value);
+                monitor_hmp_printf(hmp, "0x%08x", id->value);
                 if (id->next) {
-                    monitor_printf(mon, ",");
+                    monitor_hmp_printf(hmp, ",");
                 }
             }
-            monitor_printf(mon, "]");
+            monitor_hmp_printf(hmp, "]");
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaGroupList(list);
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 51d95d76620e..500f821246a9 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -24,54 +24,55 @@
 #include "qapi/qapi-commands-pci.h"
 #include "qemu/cutils.h"
 
-static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
+static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *dev)
 {
+    Monitor *mon = MONITOR(hmp);
     PciMemoryRegionList *region;
 
-    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
-    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n",
-                   dev->slot, dev->function);
-    monitor_printf(mon, "    ");
+    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
+    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 ":\n",
+                       dev->slot, dev->function);
+    monitor_hmp_printf(hmp, "    ");
 
     if (dev->class_info->desc) {
         monitor_puts(mon, dev->class_info->desc);
     } else {
-        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_class);
+        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q_class);
     }
 
-    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
-                   dev->id->vendor, dev->id->device);
+    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
+                       dev->id->vendor, dev->id->device);
     if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
-        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
-                       dev->id->subsystem_vendor, dev->id->subsystem);
+        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
+                           dev->id->subsystem_vendor, dev->id->subsystem);
     }
 
     if (dev->has_irq) {
-        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
-                       dev->irq, (char)('A' + dev->irq_pin - 1));
+        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
+                           dev->irq, (char)('A' + dev->irq_pin - 1));
     }
 
     if (dev->pci_bridge) {
-        monitor_printf(mon, "      BUS %" PRId64 ".\n",
-                       dev->pci_bridge->bus->number);
-        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->secondary);
-        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->subordinate);
+        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
+                           dev->pci_bridge->bus->number);
+        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->secondary);
+        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->subordinate);
 
-        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
-                       dev->pci_bridge->bus->io_range->base,
-                       dev->pci_bridge->bus->io_range->limit);
+        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
+                           dev->pci_bridge->bus->io_range->base,
+                           dev->pci_bridge->bus->io_range->limit);
 
-        monitor_printf(mon,
-                       "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->memory_range->base,
-                       dev->pci_bridge->bus->memory_range->limit);
+        monitor_hmp_printf(hmp,
+                           "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->memory_range->base,
+                           dev->pci_bridge->bus->memory_range->limit);
 
-        monitor_printf(mon, "      prefetchable memory range "
-                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->prefetchable_range->base,
-                       dev->pci_bridge->bus->prefetchable_range->limit);
+        monitor_hmp_printf(hmp, "      prefetchable memory range "
+                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->prefetchable_range->base,
+                           dev->pci_bridge->bus->prefetchable_range->limit);
     }
 
     for (region = dev->regions; region; region = region->next) {
@@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
         addr = region->value->address;
         size = region->value->size;
 
-        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->bar);
+        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->value->bar);
 
         if (!strcmp(region->value->type, "io")) {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "I/O at 0x%04" PRIx64
+                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
                                     " [0x%04" PRIx64 "]\n",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "I/O (not mapped)\n");
+                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
             }
         } else {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
+                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRIx64
                                    " [0x%08" PRIx64 "]\n",
                                region->value->mem_type_64 ? 64 : 32,
                                region->value->prefetch ? " prefetchable" : "",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
-                               region->value->mem_type_64 ? 64 : 32,
-                               region->value->prefetch ? " prefetchable" : "");
+                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\n",
+                                   region->value->mem_type_64 ? 64 : 32,
+                                   region->value->prefetch ? " prefetchable" : "");
             }
         }
     }
 
-    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
+    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
 
     if (dev->pci_bridge) {
         if (dev->pci_bridge->has_devices) {
             PciDeviceInfoList *cdev;
             for (cdev = dev->pci_bridge->devices; cdev; cdev = cdev->next) {
-                hmp_info_pci_device(mon, cdev->value);
+                hmp_info_pci_device(hmp, cdev->value);
             }
         }
     }
@@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
 
 void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     PciInfoList *info_list, *info;
 
     info_list = qmp_query_pci(&error_abort);
@@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
         PciDeviceInfoList *dev;
 
         for (dev = info->value->devices; dev; dev = dev->next) {
-            hmp_info_pci_device(mon, dev->value);
+            hmp_info_pci_device(hmp, dev->value);
         }
     }
 
@@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
@@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
         snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
     }
 
-    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
-                   "pci id %04x:%04x (sub %04x:%04x)\n",
-                   indent, "", ctxt, pci_dev_bus_num(d),
-                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                   pci_get_word(d->config + PCI_VENDOR_ID),
-                   pci_get_word(d->config + PCI_DEVICE_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
+    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
+                       "pci id %04x:%04x (sub %04x:%04x)\n",
+                       indent, "", ctxt, pci_dev_bus_num(d),
+                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+                       pci_get_word(d->config + PCI_VENDOR_ID),
+                       pci_get_word(d->config + PCI_DEVICE_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
         if (!r->size) {
             continue;
         }
-        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
-                       " [0x%"FMT_PCIBUS"]\n",
-                       indent, "",
-                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
-                       r->addr, r->addr + r->size - 1);
+        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
+                           " [0x%"FMT_PCIBUS"]\n",
+                           indent, "",
+                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
+                           r->addr, r->addr + r->size - 1);
     }
 }
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *id = qdict_get_str(qdict, "id");
     const char *error_name;
@@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
     }
 
 
-    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
-                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
-                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
+                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
+                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
 
 out:
     hmp_handle_error(hmp, err);
diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
index a80e34175462..7e2797300ba0 100644
--- a/hw/pci/pci-stub.c
+++ b/hw/pci/pci-stub.c
@@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "PCI devices not supported\n");
+    monitor_hmp_printf(hmp, "PCI devices not supported\n");
 }
 
 /* kvm-all wants this */
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index d8afaf730639..b5e56a16cce1 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
 
 void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390SKeysState *ss = s390_get_skeys_device();
     S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 
     /* Quick check to see if guest is using storage keys*/
     if (!skeyclass->skeys_are_enabled(ss)) {
-        monitor_printf(mon, "Error: This guest is not using storage keys\n");
+        monitor_hmp_printf(hmp, "Error: This guest is not using storage keys\n");
         return;
     }
 
     if (!address_space_access_valid(&address_space_memory,
                                     addr & TARGET_PAGE_MASK, TARGET_PAGE_SIZE,
                                     false, MEMTXATTRS_UNSPECIFIED)) {
-        monitor_printf(mon, "Error: The given address is not valid\n");
+        monitor_hmp_printf(hmp, "Error: The given address is not valid\n");
         return;
     }
 
     r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s\n", strerror(-r));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
         return;
     }
 
-    monitor_printf(mon, "  key: 0x%X\n", key);
+    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
 }
 
 void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index b4a405455901..644298f7f0b2 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -61,7 +61,6 @@ void s390_stattrib_init(void)
 
 void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t what = qdict_get_int(qdict, "mode");
@@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 
     r = sac->set_migrationmode(sas, what, &local_err);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
+        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_err));
         error_free(local_err);
     }
 }
 
 void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 
     vals = g_try_malloc(buflen);
     if (!vals) {
-        monitor_printf(mon, "Error: %s\n", strerror(errno));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
         return;
     }
 
     len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
     if (len < 0) {
-        monitor_printf(mon, "Error: %s", strerror(-len));
+        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
         goto out;
     }
 
-    monitor_printf(mon, "  CMMA attributes, "
-                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
-                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
+    monitor_hmp_printf(hmp, "  CMMA attributes, "
+                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
+                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
     for (cx = 0; cx < len; cx++) {
         if (cx % 8 == 7) {
-            monitor_printf(mon, "%02x\n", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
         } else {
-            monitor_printf(mon, "%02x", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x", vals[cx]);
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
 out:
     g_free(vals);
diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
index 0d59a74ad60e..0249eea2cfe9 100644
--- a/hw/uefi/ovmf-log.c
+++ b/hw/uefi/ovmf-log.c
@@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_size, uint64_t max_size,
 
 void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autofree gchar *log_esc = NULL;
     g_autofree guchar *log_out = NULL;
     Error *err = NULL;
@@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 
     if (log->version) {
         g_autofree gchar *esc = g_strescape(log->version, NULL);
-        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
+        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
     }
 
     log_out = g_base64_decode(log->log, &log_len);
     log_esc = g_strescape((gchar *)log_out, "\r\n");
-    monitor_printf(mon, "%s\n", log_esc);
+    monitor_hmp_printf(hmp, "%s\n", log_esc);
 }
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 9b9b2e7c2f8f..fe3dbfa2227c 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
 
 static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
-    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
-                   indent, "", bus->busnr, dev->addr,
-                   dev->port ? dev->port->path : "-",
-                   usb_speed(dev->speed), dev->product_desc,
-                   dev->attached ? ", attached" : "");
+    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
+                       indent, "", bus->busnr, dev->addr,
+                       dev->port ? dev->port->path : "-",
+                       usb_speed(dev->speed), dev->product_desc,
+                       dev->attached ? ", attached" : "");
 }
 
 static char *usb_get_dev_path(DeviceState *qdev)
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index c02343d3a655..9b9f26a1078e 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
 
 void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     libusb_device **devs = NULL;
     struct libusb_device_descriptor ddesc;
     char port[16];
@@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
         usb_host_get_port(devs[i], port, sizeof(port));
-        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
-                       libusb_get_bus_number(devs[i]),
-                       libusb_get_device_address(devs[i]),
-                       port,
-                       speed_name[libusb_get_device_speed(devs[i])]);
-        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
-        monitor_printf(mon, " USB device %04x:%04x",
-                       ddesc.idVendor, ddesc.idProduct);
+        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
+                           libusb_get_bus_number(devs[i]),
+                           libusb_get_device_address(devs[i]),
+                           port,
+                           speed_name[libusb_get_device_speed(devs[i])]);
+        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass);
+        monitor_hmp_printf(hmp, " USB device %04x:%04x",
+                           ddesc.idVendor, ddesc.idProduct);
         if (ddesc.iProduct) {
             libusb_device_handle *handle;
             if (libusb_open(devs[i], &handle) == 0) {
@@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
                                                    ddesc.iProduct,
                                                    name, sizeof(name));
                 libusb_close(handle);
-                monitor_printf(mon, ", %s", name);
+                monitor_hmp_printf(hmp, ", %s", name);
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
     libusb_free_device_list(devs, 1);
 }
diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
index fb36c8b9274c..e5da6f00699d 100644
--- a/hw/virtio/virtio-hmp-cmds.c
+++ b/hw/virtio/virtio-hmp-cmds.c
@@ -12,77 +12,76 @@
 #include "qobject/qdict.h"
 
 
-static void hmp_virtio_dump_protocols(Monitor *mon,
+static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
                                       VhostDeviceProtocols *pcol)
 {
     strList *pcol_list = pcol->protocols;
     while (pcol_list) {
-        monitor_printf(mon, "\t%s", pcol_list->value);
+        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
         pcol_list = pcol_list->next;
         if (pcol_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (pcol->has_unknown_protocols) {
-        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
-                       pcol->unknown_protocols);
+        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n",
+                           pcol->unknown_protocols);
     }
 }
 
-static void hmp_virtio_dump_status(Monitor *mon,
+static void hmp_virtio_dump_status(MonitorHMP *hmp,
                                    VirtioDeviceStatus *status)
 {
     strList *status_list = status->statuses;
     while (status_list) {
-        monitor_printf(mon, "\t%s", status_list->value);
+        monitor_hmp_printf(hmp, "\t%s", status_list->value);
         status_list = status_list->next;
         if (status_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (status->has_unknown_statuses) {
-        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
-                       status->unknown_statuses);
+        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n",
+                           status->unknown_statuses);
     }
 }
 
-static void hmp_virtio_dump_features(Monitor *mon,
+static void hmp_virtio_dump_features(MonitorHMP *hmp,
                                      VirtioDeviceFeatures *features)
 {
     strList *transport_list = features->transports;
     while (transport_list) {
-        monitor_printf(mon, "\t%s", transport_list->value);
+        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
         transport_list = transport_list->next;
         if (transport_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     strList *list = features->dev_features;
     if (list) {
         while (list) {
-            monitor_printf(mon, "\t%s", list->value);
+            monitor_hmp_printf(hmp, "\t%s", list->value);
             list = list->next;
             if (list != NULL) {
-                monitor_printf(mon, ",\n");
+                monitor_hmp_printf(hmp, ",\n");
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (features->has_unknown_dev_features) {
-        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
-                       features->unknown_dev_features2,
-                       features->unknown_dev_features);
+        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
+                           features->unknown_dev_features2,
+                           features->unknown_dev_features);
     }
 }
 
 void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     VirtioInfoList *list = qmp_x_query_virtio(&err);
     VirtioInfoList *node;
@@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (list == NULL) {
-        monitor_printf(mon, "No VirtIO devices\n");
+        monitor_hmp_printf(hmp, "No VirtIO devices\n");
         return;
     }
 
     node = list;
     while (node) {
-        monitor_printf(mon, "%s [%s]\n", node->value->path,
-                       node->value->name);
+        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
+                           node->value->name);
         node = node->next;
     }
     qapi_free_VirtioInfoList(list);
@@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     VirtioStatus *s = qmp_x_query_virtio_status(path, &err);
@@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:             %s %s\n",
-                   s->name, s->vhost_dev ? "(vhost)" : "");
-    monitor_printf(mon, "  device_id:               %d\n", s->device_id);
-    monitor_printf(mon, "  vhost_started:           %s\n",
-                   s->vhost_started ? "true" : "false");
-    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name);
-    monitor_printf(mon, "  broken:                  %s\n",
-                   s->broken ? "true" : "false");
-    monitor_printf(mon, "  disabled:                %s\n",
-                   s->disabled ? "true" : "false");
-    monitor_printf(mon, "  disable_legacy_check:    %s\n",
-                   s->disable_legacy_check ? "true" : "false");
-    monitor_printf(mon, "  started:                 %s\n",
-                   s->started ? "true" : "false");
-    monitor_printf(mon, "  use_started:             %s\n",
-                   s->use_started ? "true" : "false");
-    monitor_printf(mon, "  start_on_kick:           %s\n",
-                   s->start_on_kick ? "true" : "false");
-    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
-                   s->use_guest_notifier_mask ? "true" : "false");
-    monitor_printf(mon, "  vm_running:              %s\n",
-                   s->vm_running ? "true" : "false");
-    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
-    monitor_printf(mon, "  queue_sel:               %d\n",
-                   s->queue_sel);
-    monitor_printf(mon, "  isr:                     %d\n", s->isr);
-    monitor_printf(mon, "  endianness:              %s\n",
-                   s->device_endian);
-    monitor_printf(mon, "  status:\n");
-    hmp_virtio_dump_status(mon, s->status);
-    monitor_printf(mon, "  Guest features:\n");
-    hmp_virtio_dump_features(mon, s->guest_features);
-    monitor_printf(mon, "  Host features:\n");
-    hmp_virtio_dump_features(mon, s->host_features);
-    monitor_printf(mon, "  Backend features:\n");
-    hmp_virtio_dump_features(mon, s->backend_features);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
+                       s->name, s->vhost_dev ? "(vhost)" : "");
+    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->device_id);
+    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
+                       s->vhost_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_name);
+    monitor_hmp_printf(hmp, "  broken:                  %s\n",
+                       s->broken ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disabled:                %s\n",
+                       s->disabled ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
+                       s->disable_legacy_check ? "true" : "false");
+    monitor_hmp_printf(hmp, "  started:                 %s\n",
+                       s->started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_started:             %s\n",
+                       s->use_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
+                       s->start_on_kick ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
+                       s->use_guest_notifier_mask ? "true" : "false");
+    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
+                       s->vm_running ? "true" : "false");
+    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
+    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
+                       s->queue_sel);
+    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr);
+    monitor_hmp_printf(hmp, "  endianness:              %s\n",
+                       s->device_endian);
+    monitor_hmp_printf(hmp, "  status:\n");
+    hmp_virtio_dump_status(hmp, s->status);
+    monitor_hmp_printf(hmp, "  Guest features:\n");
+    hmp_virtio_dump_features(hmp, s->guest_features);
+    monitor_hmp_printf(hmp, "  Host features:\n");
+    hmp_virtio_dump_features(hmp, s->host_features);
+    monitor_hmp_printf(hmp, "  Backend features:\n");
+    hmp_virtio_dump_features(hmp, s->backend_features);
 
     if (s->vhost_dev) {
-        monitor_printf(mon, "  VHost:\n");
-        monitor_printf(mon, "    nvqs:           %d\n",
-                       s->vhost_dev->nvqs);
-        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
-                       s->vhost_dev->vq_index);
-        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
-                       s->vhost_dev->max_queues);
-        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
-                       s->vhost_dev->n_mem_sections);
-        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
-                       s->vhost_dev->n_tmp_sections);
-        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
-                       s->vhost_dev->backend_cap);
-        monitor_printf(mon, "    log_enabled:    %s\n",
-                       s->vhost_dev->log_enabled ? "true" : "false");
-        monitor_printf(mon, "    log_size:       %"PRId64"\n",
-                       s->vhost_dev->log_size);
-        monitor_printf(mon, "    Features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->features);
-        monitor_printf(mon, "    Acked features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
-        monitor_printf(mon, "    Protocol features:\n");
-        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features);
+        monitor_hmp_printf(hmp, "  VHost:\n");
+        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
+                           s->vhost_dev->nvqs);
+        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
+                           s->vhost_dev->vq_index);
+        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
+                           s->vhost_dev->max_queues);
+        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
+                           s->vhost_dev->n_mem_sections);
+        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
+                           s->vhost_dev->n_tmp_sections);
+        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
+                           s->vhost_dev->backend_cap);
+        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
+                           s->vhost_dev->log_enabled ? "true" : "false");
+        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
+                           s->vhost_dev->log_size);
+        monitor_hmp_printf(hmp, "    Features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
+        monitor_hmp_printf(hmp, "    Acked features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
+        monitor_hmp_printf(hmp, "    Protocol features:\n");
+        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features);
     }
 
     qapi_free_VirtioStatus(s);
@@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s (vhost)\n",
-                   s->name);
-    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick);
-    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call);
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
-    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
-                   s->desc_phys);
-    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
-    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
-                   s->avail_phys);
-    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size);
-    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
-                   s->used_phys);
-    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
+                       s->name);
+    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->kick);
+    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->call);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
+    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
+                       s->desc_phys);
+    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_size);
+    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
+                       s->avail_phys);
+    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_size);
+    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
+                       s->used_phys);
+    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_size);
 
     qapi_free_VirtVhostQueueStatus(s);
 }
 
 void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s\n", s->name);
-    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index);
-    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
-    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
-    monitor_printf(mon, "  signalled_used:       %d\n",
-                   s->signalled_used);
-    monitor_printf(mon, "  signalled_used_valid: %s\n",
-                   s->signalled_used_valid ? "true" : "false");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
+    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_index);
+    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
+    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_idx);
+    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
+                       s->signalled_used);
+    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
+                       s->signalled_used_valid ? "true" : "false");
     if (s->has_last_avail_idx) {
-        monitor_printf(mon, "  last_avail_idx:       %d\n",
-                       s->last_avail_idx);
+        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
+                           s->last_avail_idx);
     }
     if (s->has_shadow_avail_idx) {
-        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
-                       s->shadow_avail_idx);
+        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
+                           s->shadow_avail_idx);
     }
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num);
-    monitor_printf(mon, "    num_default:  %"PRId32"\n",
-                   s->vring_num_default);
-    monitor_printf(mon, "    align:        %"PRId32"\n",
-                   s->vring_align);
-    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
-                   s->vring_desc);
-    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
-                   s->vring_avail);
-    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
-                   s->vring_used);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_num);
+    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
+                       s->vring_num_default);
+    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
+                       s->vring_align);
+    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
+                       s->vring_desc);
+    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
+                       s->vring_avail);
+    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
+                       s->vring_used);
 
     qapi_free_VirtQueueStatus(s);
 }
 
 void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name: %s\n", e->name);
-    monitor_printf(mon, "  index:   %d\n", e->index);
-    monitor_printf(mon, "  desc:\n");
-    monitor_printf(mon, "    descs:\n");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
+    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
+    monitor_hmp_printf(hmp, "  desc:\n");
+    monitor_hmp_printf(hmp, "    descs:\n");
 
     list = e->descs;
     while (list) {
-        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
-                       list->value->addr, list->value->len);
+        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
+                           list->value->addr, list->value->len);
         if (list->value->flags) {
             strList *flag = list->value->flags;
-            monitor_printf(mon, " (");
+            monitor_hmp_printf(hmp, " (");
             while (flag) {
-                monitor_printf(mon, "%s", flag->value);
+                monitor_hmp_printf(hmp, "%s", flag->value);
                 flag = flag->next;
                 if (flag) {
-                    monitor_printf(mon, ", ");
+                    monitor_hmp_printf(hmp, ", ");
                 }
             }
-            monitor_printf(mon, ")");
+            monitor_hmp_printf(hmp, ")");
         }
         list = list->next;
         if (list) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
-    monitor_printf(mon, "  avail:\n");
-    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
-    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
-    monitor_printf(mon, "  used:\n");
-    monitor_printf(mon, "    flags: %d\n", e->used->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
+    monitor_hmp_printf(hmp, "\n");
+    monitor_hmp_printf(hmp, "  avail:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
+    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
+    monitor_hmp_printf(hmp, "  used:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
 
     qapi_free_VirtioQueueElement(e);
 }
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index a563f6066bb4..4075b5b001ae 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -103,10 +103,11 @@ abort:
 
 static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
-    monitor_printf(mon, "%*sname = '%s' frontend_id = %u\n",
-                   indent, "", xendev->name, xendev->frontend_id);
+    monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
+                       indent, "", xendev->name, xendev->frontend_id);
 }
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
diff --git a/include/disas/disas.h b/include/disas/disas.h
index c702b1effc1c..47daa9b4d2df 100644
--- a/include/disas/disas.h
+++ b/include/disas/disas.h
@@ -1,13 +1,15 @@
 #ifndef QEMU_DISAS_H
 #define QEMU_DISAS_H
 
+#include "monitor/hmp.h"
+
 /* Disassemble this for me please... (debugging). */
 #ifdef CONFIG_TCG
 void disas(FILE *out, const void *code, size_t size);
 void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db);
 #endif
 
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical);
 
 #ifdef CONFIG_PLUGIN
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 3fd17048b319..f10bf83df86d 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *chardev_id,
 
 MonitorHMP *monitor_cur_hmp(void);
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
     G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_hmp_printc(MonitorHMP *mon, int ch);
 
 void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
 int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
@@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
 int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
 
 bool hmp_handle_error(MonitorHMP *hmp, Error *err);
-void hmp_help_cmd(Monitor *mon, const char *name);
+void hmp_help_cmd(MonitorHMP *hmp, const char *name);
 strList *hmp_split_at_comma(const char *str);
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
@@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_change(MonitorHMP *hmp, const QDict *qdict);
 #ifdef CONFIG_VNC
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp);
 #endif
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp);
 void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 3c0931796ce2..bdbb2aaa99db 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool has_calc_time_unit,
 
 void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyRateInfo *info = query_dirty_rate_info(TIME_UNIT_SECOND);
 
-    monitor_printf(mon, "Status: %s\n",
-                   DirtyRateStatus_str(info->status));
-    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
-                   info->start_time);
+    monitor_hmp_printf(hmp, "Status: %s\n",
+                       DirtyRateStatus_str(info->status));
+    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
+                       info->start_time);
     if (info->mode == DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
-        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
-                       info->sample_pages);
+        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
+                           info->sample_pages);
     }
-    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
-                   info->calc_time);
-    monitor_printf(mon, "Mode: %s\n",
-                   DirtyRateMeasureMode_str(info->mode));
-    monitor_printf(mon, "Dirty rate: ");
+    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
+                       info->calc_time);
+    monitor_hmp_printf(hmp, "Mode: %s\n",
+                       DirtyRateMeasureMode_str(info->mode));
+    monitor_hmp_printf(hmp, "Dirty rate: ");
     if (info->has_dirty_rate) {
-        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
+        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate);
         if (info->has_vcpu_dirty_rate) {
             DirtyRateVcpuList *rate, *head = info->vcpu_dirty_rate;
             for (rate = head; rate != NULL; rate = rate->next) {
-                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
-                               " (MB/s)\n", rate->value->id,
-                               rate->value->dirty_rate);
+                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
+                                   " (MB/s)\n", rate->value->id,
+                                   rate->value->dirty_rate);
             }
         }
     } else {
-        monitor_printf(mon, "(not ready)\n");
+        monitor_hmp_printf(hmp, "(not ready)\n");
     }
 
     qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
@@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t sec = qdict_get_try_int(qdict, "second", 0);
     int64_t sample_pages = qdict_get_try_int(qdict, "sample_pages_per_GB", -1);
     bool has_sample_pages = (sample_pages != -1);
@@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
     Error *err = NULL;
 
     if (!sec) {
-        monitor_printf(mon, "Incorrect period length specified!\n");
+        monitor_hmp_printf(hmp, "Incorrect period length specified!\n");
         return;
     }
 
     if (dirty_ring && dirty_bitmap) {
-        monitor_printf(mon, "Either dirty ring or dirty bitmap "
-                       "can be specified!\n");
+        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
+                           "can be specified!\n");
         return;
     }
 
@@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Starting dirty rate measurement with period %"PRIi64
-                   " seconds\n", sec);
-    monitor_printf(mon, "[Please use 'info dirty_rate' to check results]\n");
+    monitor_hmp_printf(hmp, "Starting dirty rate measurement with period %"PRIi64
+                       " seconds\n", sec);
+    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check results]\n");
 }
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index a164a59080c5..6fe189471899 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -36,23 +36,23 @@
 #include "options.h"
 #include "migration.h"
 
-static void migration_global_dump(Monitor *mon)
+static void migration_global_dump(MonitorHMP *hmp)
 {
     MigrationState *ms = migrate_get_current();
 
-    monitor_printf(mon, "Globals:\n");
-    monitor_printf(mon, "  store-global-state: %s\n",
-                   ms->store_global_state ? "on" : "off");
-    monitor_printf(mon, "  only-migratable: %s\n",
-                   only_migratable ? "on" : "off");
-    monitor_printf(mon, "  send-configuration: %s\n",
-                   ms->send_configuration ? "on" : "off");
-    monitor_printf(mon, "  send-section-footer: %s\n",
-                   ms->send_section_footer ? "on" : "off");
-    monitor_printf(mon, "  send-switchover-start: %s\n",
-                   ms->send_switchover_start ? "on" : "off");
-    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
-                   ms->clear_bitmap_shift);
+    monitor_hmp_printf(hmp, "Globals:\n");
+    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
+                       ms->store_global_state ? "on" : "off");
+    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
+                       only_migratable ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
+                       ms->send_configuration ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
+                       ms->send_section_footer ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
+                       ms->send_switchover_start ? "on" : "off");
+    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
+                       ms->clear_bitmap_shift);
 }
 
 static const gchar *format_time_str(uint64_t us)
@@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
     return g_strdup_printf("%"PRIu64" %s", us, units[index]);
 }
 
-static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
+static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *info)
 {
     if (info->has_postcopy_blocktime) {
-        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
-                       info->postcopy_blocktime);
+        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\n",
+                           info->postcopy_blocktime);
     }
 
     if (info->has_postcopy_vcpu_blocktime) {
@@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency) {
-        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_latency);
+        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_latency);
     }
 
     if (info->has_postcopy_non_vcpu_latency) {
-        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_non_vcpu_latency);
+        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_non_vcpu_latency);
     }
 
     if (info->has_postcopy_vcpu_latency) {
@@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency_dist) {
         uint64List *item = info->postcopy_latency_dist;
         int count = 0;
 
-        monitor_printf(mon, "Postcopy Latency Distribution:\n");
+        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
 
         while (item) {
             g_autofree const gchar *from = format_time_str(1UL << count);
             g_autofree const gchar *to = format_time_str(1UL << (count + 1));
 
-            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
-                           from, to, item->value);
+            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
+                               from, to, item->value);
             item = item->next;
             count++;
         }
@@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
 
 void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool show_all = qdict_get_try_bool(qdict, "all", false);
     MigrationInfo *info;
 
@@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 
     if (info->blocked_reasons) {
         strList *reasons = info->blocked_reasons;
-        monitor_printf(mon, "Outgoing migration blocked:\n");
+        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
         while (reasons) {
-            monitor_printf(mon, "  %s\n", reasons->value);
+            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
             reasons = reasons->next;
         }
     }
 
     if (info->has_status) {
-        monitor_printf(mon, "Status: \t\t%s",
-                       MigrationStatus_str(info->status));
+        monitor_hmp_printf(hmp, "Status: \t\t%s",
+                           MigrationStatus_str(info->status));
         if ((info->status == MIGRATION_STATUS_FAILED ||
              info->status == MIGRATION_STATUS_POSTCOPY_PAUSED) &&
             info->error_desc) {
-            monitor_printf(mon, " (%s)\n", info->error_desc);
+            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
         } else {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
         if (info->total_time) {
-            monitor_printf(mon, "Time (ms): \t\ttotal=%" PRIu64,
-                           info->total_time);
+            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=%" PRIu64,
+                               info->total_time);
             if (info->has_setup_time) {
-                monitor_printf(mon, ", setup=%" PRIu64,
-                               info->setup_time);
+                monitor_hmp_printf(hmp, ", setup=%" PRIu64,
+                                   info->setup_time);
             }
             if (info->has_expected_downtime) {
-                monitor_printf(mon, ", exp_down=%" PRIu64,
-                               info->expected_downtime);
+                monitor_hmp_printf(hmp, ", exp_down=%" PRIu64,
+                                   info->expected_downtime);
             }
             if (info->has_downtime) {
-                monitor_printf(mon, ", down=%" PRIu64,
-                               info->downtime);
+                monitor_hmp_printf(hmp, ", down=%" PRIu64,
+                                   info->downtime);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
     if (info->has_remaining) {
         g_autofree char *remaining = size_to_str(info->remaining);
-        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
+        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
     }
 
     if (info->has_socket_address) {
         SocketAddressList *addr;
 
-        monitor_printf(mon, "Sockets: [\n");
+        monitor_hmp_printf(hmp, "Sockets: [\n");
 
         for (addr = info->socket_address; addr; addr = addr->next) {
             char *s = socket_uri(addr->value);
-            monitor_printf(mon, "\t%s\n", s);
+            monitor_hmp_printf(hmp, "\t%s\n", s);
             g_free(s);
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->ram) {
@@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
         g_autofree char *str_multifd = size_to_str(info->ram->multifd_bytes);
         g_autofree char *str_postcopy = size_to_str(info->ram->postcopy_bytes);
 
-        monitor_printf(mon, "RAM info:\n");
-        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
-                       info->ram->mbps);
-        monitor_printf(mon, "  Sizes: \t\tpagesize=%s, total=%s\n",
-                       str_psize, str_total);
-        monitor_printf(mon, "  Transfers: \t\ttransferred=%s, remain=%s\n",
-                       str_transferred, str_remaining);
-        monitor_printf(mon, "    Channels: \t\tprecopy=%s, "
-                       "multifd=%s, postcopy=%s",
-                       str_precopy, str_multifd, str_postcopy);
+        monitor_hmp_printf(hmp, "RAM info:\n");
+        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
+                           info->ram->mbps);
+        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=%s, total=%s\n",
+                           str_psize, str_total);
+        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=%s, remain=%s\n",
+                           str_transferred, str_remaining);
+        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=%s, "
+                           "multifd=%s, postcopy=%s",
+                           str_precopy, str_multifd, str_postcopy);
 
         if (info->vfio) {
             g_autofree char *str_vfio = size_to_str(info->vfio->transferred);
 
-            monitor_printf(mon, ", vfio=%s", str_vfio);
+            monitor_hmp_printf(hmp, ", vfio=%s", str_vfio);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "    Page Types: \tnormal=%" PRIu64
-                       ", zero=%" PRIu64 "\n",
-                       info->ram->normal, info->ram->duplicate);
-        monitor_printf(mon, "  Page Rates (pps): \ttransfer=%" PRIu64,
-                       info->ram->pages_per_second);
+        monitor_hmp_printf(hmp, "    Page Types: \tnormal=%" PRIu64
+                           ", zero=%" PRIu64 "\n",
+                           info->ram->normal, info->ram->duplicate);
+        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=%" PRIu64,
+                           info->ram->pages_per_second);
         if (info->ram->dirty_pages_rate) {
-            monitor_printf(mon, ", dirty=%" PRIu64,
-                           info->ram->dirty_pages_rate);
+            monitor_hmp_printf(hmp, ", dirty=%" PRIu64,
+                               info->ram->dirty_pages_rate);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "  Others: \t\tdirty_syncs=%" PRIu64,
-                       info->ram->dirty_sync_count);
+        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=%" PRIu64,
+                           info->ram->dirty_sync_count);
         if (info->ram->postcopy_requests) {
-            monitor_printf(mon, ", postcopy_req=%" PRIu64,
-                           info->ram->postcopy_requests);
+            monitor_hmp_printf(hmp, ", postcopy_req=%" PRIu64,
+                               info->ram->postcopy_requests);
         }
         if (info->ram->downtime_bytes) {
-            monitor_printf(mon, ", downtime_bytes=%" PRIu64,
-                           info->ram->downtime_bytes);
+            monitor_hmp_printf(hmp, ", downtime_bytes=%" PRIu64,
+                               info->ram->downtime_bytes);
         }
         if (info->ram->dirty_sync_missed_zero_copy) {
-            monitor_printf(mon, ", zerocopy_fallbacks=%" PRIu64,
-                           info->ram->dirty_sync_missed_zero_copy);
+            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=%" PRIu64,
+                               info->ram->dirty_sync_missed_zero_copy);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (!show_all) {
         goto out;
     }
 
-    migration_global_dump(mon);
+    migration_global_dump(hmp);
 
     if (info->xbzrle_cache) {
-        monitor_printf(mon, "XBZRLE: size=%" PRIu64
-                       ", transferred=%" PRIu64
-                       ", pages=%" PRIu64
-                       ", miss=%" PRIu64 "\n"
-                       "  miss_rate=%0.2f"
-                       ", encode_rate=%0.2f"
-                       ", overflow=%" PRIu64 "\n",
-                       info->xbzrle_cache->cache_size,
-                       info->xbzrle_cache->bytes,
-                       info->xbzrle_cache->pages,
-                       info->xbzrle_cache->cache_miss,
-                       info->xbzrle_cache->cache_miss_rate,
-                       info->xbzrle_cache->encoding_rate,
-                       info->xbzrle_cache->overflow);
+        monitor_hmp_printf(hmp, "XBZRLE: size=%" PRIu64
+                           ", transferred=%" PRIu64
+                           ", pages=%" PRIu64
+                           ", miss=%" PRIu64 "\n"
+                           "  miss_rate=%0.2f"
+                           ", encode_rate=%0.2f"
+                           ", overflow=%" PRIu64 "\n",
+                           info->xbzrle_cache->cache_size,
+                           info->xbzrle_cache->bytes,
+                           info->xbzrle_cache->pages,
+                           info->xbzrle_cache->cache_miss,
+                           info->xbzrle_cache->cache_miss_rate,
+                           info->xbzrle_cache->encoding_rate,
+                           info->xbzrle_cache->overflow);
     }
 
     if (info->has_cpu_throttle_percentage) {
-        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
-                       info->cpu_throttle_percentage);
+        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
+                           info->cpu_throttle_percentage);
     }
 
     if (info->has_dirty_limit_throttle_time_per_round) {
-        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n",
-                       info->dirty_limit_throttle_time_per_round);
+        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 "\n",
+                           info->dirty_limit_throttle_time_per_round);
     }
 
     if (info->has_dirty_limit_ring_full_time) {
-        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
-                       info->dirty_limit_ring_full_time);
+        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
+                           info->dirty_limit_ring_full_time);
     }
 
-    migration_dump_blocktime(mon, info);
+    migration_dump_blocktime(hmp, info);
 out:
     qapi_free_MigrationInfo(info);
 }
 
 void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationCapabilityStatusList *caps, *cap;
 
     caps = qmp_query_migrate_capabilities(NULL);
 
     if (caps) {
         for (cap = caps; cap; cap = cap->next) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationCapability_str(cap->value->capability),
-                           cap->value->state ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationCapability_str(cap->value->capability),
+                               cap->value->state ? "on" : "off");
         }
     }
 
     qapi_free_MigrationCapabilityStatusList(caps);
 }
 
-static void monitor_print_cpr_exec_command(Monitor *mon, strList *args)
+static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *args)
 {
-    monitor_printf(mon, "%s:",
+    monitor_hmp_printf(hmp, "%s:",
         MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
 
     while (args) {
-        monitor_printf(mon, " %s", args->value);
+        monitor_hmp_printf(hmp, " %s", args->value);
         args = args->next;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationParameters *params;
     MigrationState *s = migrate_get_current();
 
     params = qmp_query_migrate_parameters(NULL);
 
     if (params) {
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIAL),
             params->announce_initial);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
             params->announce_max);
-        monitor_printf(mon, "%s: %" PRIu64 "\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS),
             params->announce_rounds);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
             params->announce_step);
         assert(params->has_throttle_trigger_threshold);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD),
             params->throttle_trigger_threshold);
         assert(params->has_cpu_throttle_initial);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
             params->cpu_throttle_initial);
         assert(params->has_cpu_throttle_increment);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
             params->cpu_throttle_increment);
         assert(params->has_cpu_throttle_tailslow);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW),
             params->cpu_throttle_tailslow ? "on" : "off");
         assert(params->has_max_cpu_throttle);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTLE),
             params->max_cpu_throttle);
         assert(params->tls_creds);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
                        params->tls_creds->u.s);
         assert(params->tls_hostname);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
                        params->tls_hostname->u.s);
         assert(params->tls_authz);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
                        params->tls_authz->u.s);
         assert(params->has_max_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
             params->max_bandwidth);
         assert(params->has_avail_switchover_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVER_BANDWIDTH),
             params->avail_switchover_bandwidth);
         assert(params->has_max_postcopy_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH),
             params->max_postcopy_bandwidth);
         assert(params->has_downtime_limit);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
             params->downtime_limit);
         assert(params->has_x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u ms\n",
+        monitor_hmp_printf(hmp, "%s: %u ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
             params->x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
             params->multifd_channels);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRESSION),
             MultiFDCompression_str(params->multifd_compression));
         assert(params->has_zero_page_detection);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETECTION),
             qapi_enum_lookup(&ZeroPageDetection_lookup,
                 params->zero_page_detection));
-        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
             MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
             params->xbzrle_cache_size);
 
         if (s->has_block_bitmap_mapping) {
             const BitmapMigrationNodeAliasList *bmnal;
 
-            monitor_printf(mon, "%s:\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
+            monitor_hmp_printf(hmp, "%s:\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
 
             for (bmnal = params->block_bitmap_mapping;
                  bmnal;
@@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
                 const BitmapMigrationNodeAlias *bmna = bmnal->value;
                 const BitmapMigrationBitmapAliasList *bmbal;
 
-                monitor_printf(mon, "  '%s' -> '%s'\n",
-                               bmna->node_name, bmna->alias);
+                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
+                                   bmna->node_name, bmna->alias);
 
                 for (bmbal = bmna->bitmaps; bmbal; bmbal = bmbal->next) {
                     const BitmapMigrationBitmapAlias *bmba = bmbal->value;
 
-                    monitor_printf(mon, "    '%s' -> '%s'\n",
-                                   bmba->name, bmba->alias);
+                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
+                                       bmba->name, bmba->alias);
                 }
             }
         }
 
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
         MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD),
         params->x_vcpu_dirty_limit_period);
 
-        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT),
             params->vcpu_dirty_limit);
 
         assert(params->has_mode);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MODE),
             qapi_enum_lookup(&MigMode_lookup, params->mode));
 
         if (params->has_direct_io) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_DIRECT_IO),
-                           params->direct_io ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_DIRECT_IO),
+                               params->direct_io ? "on" : "off");
         }
 
         if (params->has_x_rdma_chunk_size) {
-            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
-                           params->x_rdma_chunk_size);
+            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
+                               params->x_rdma_chunk_size);
         }
 
         assert(params->has_cpr_exec_command);
-        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
+        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
     }
 
     qapi_free_MigrationParameters(params);
@@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
         HMPMigrationStatus *status;
 
         if (!hmp->use_readline) {
-            monitor_printf(mon, "terminal does not allow synchronous "
-                           "migration, continuing detached\n");
+            monitor_hmp_printf(hmp, "terminal does not allow synchronous "
+                               "migration, continuing detached\n");
             return;
         }
         monitor_suspend(mon);
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 89cc19c2431d..1834e3c1f697 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     NameInfo *info;
 
     info = qmp_query_name(NULL);
     if (info->name) {
-        monitor_printf(mon, "%s\n", info->name);
+        monitor_hmp_printf(hmp, "%s\n", info->name);
     }
     qapi_free_NameInfo(info);
 }
 
 void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VersionInfo *info;
 
     info = qmp_query_version(NULL);
 
-    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
-                   info->qemu->major, info->qemu->minor, info->qemu->micro,
-                   info->package);
+    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+                       info->qemu->major, info->qemu->minor, info->qemu->micro,
+                       info->package);
 
     qapi_free_VersionInfo(info);
 }
@@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
 
     if (op == NULL) {
         bool on = qsp_is_enabled();
 
-        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off");
+        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "off");
         return;
     }
     if (!strcmp(op, "on")) {
@@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index;
 
     /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands that
             use it are converted to the QAPI */
     cpu_index = qdict_get_int(qdict, "index");
     if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
-        monitor_printf(mon, "invalid CPU index\n");
+        monitor_hmp_printf(hmp, "invalid CPU index\n");
     }
 }
 
@@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *device = qdict_get_str(qdict, "device");
     const char *target = qdict_get_str(qdict, "target");
     const char *arg = qdict_get_try_str(qdict, "arg");
@@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
     if (strcmp(device, "vnc") == 0) {
-        hmp_change_vnc(mon, device, target, arg, read_only, force, &err);
+        hmp_change_vnc(hmp, device, target, arg, read_only, force, &err);
     } else
 #endif
     {
-        hmp_change_medium(mon, device, target, arg, read_only, force, &err);
+        hmp_change_medium(hmp, device, target, arg, read_only, force, &err);
     }
 
     hmp_handle_error(hmp, err);
@@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
     IOThreadInfoList *info;
     IOThreadInfo *value;
 
     for (info = info_list; info; info = info->next) {
         value = info->value;
-        monitor_printf(mon, "%s:\n", value->id);
-        monitor_printf(mon, "  thread_id=%" PRId64 "\n", value->thread_id);
-        monitor_printf(mon, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
-        monitor_printf(mon, "  poll-grow=%" PRId64 "\n", value->poll_grow);
-        monitor_printf(mon, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
-        monitor_printf(mon, "  poll-weight=%" PRId64 "\n", value->poll_weight);
-        monitor_printf(mon, "  aio-max-batch=%" PRId64 "\n",
-                       value->aio_max_batch);
+        monitor_hmp_printf(hmp, "%s:\n", value->id);
+        monitor_hmp_printf(hmp, "  thread_id=%" PRId64 "\n", value->thread_id);
+        monitor_hmp_printf(hmp, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
+        monitor_hmp_printf(hmp, "  poll-grow=%" PRId64 "\n", value->poll_grow);
+        monitor_hmp_printf(hmp, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
+        monitor_hmp_printf(hmp, "  poll-weight=%" PRId64 "\n", value->poll_weight);
+        monitor_hmp_printf(hmp, "  aio-max-batch=%" PRId64 "\n",
+                           value->aio_max_batch);
     }
 
     qapi_free_IOThreadInfoList(info_list);
@@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
+    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
 }
 
 void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /*
      * Send an ANSI escape sequence:
      * "\x1b[H" - move cursor to top-left
      * "\x1b[2J" - clear visible screen
      * "\x1b[3J" - clear scrollback
      */
-    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
+    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
 }
 
 void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, "info");
+    hmp_help_cmd(hmp, "info");
 }
 
 void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
@@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     const char *str;
 
@@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
         if (!str) {
             break;
         }
-        monitor_printf(mon, "%d: '%s'\n", i, str);
+        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
         i++;
     }
 }
@@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int mask;
     const char *items = qdict_get_str(qdict, "items");
     Error *err = NULL;
@@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
     } else {
         mask = qemu_str_to_log_mask(items);
         if (!mask) {
-            hmp_help_cmd(mon, "log");
+            hmp_help_cmd(hmp, "log");
             return;
         }
     }
@@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *device = qdict_get_try_str(qdict, "device");
 
@@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
     if (!gdbserver_start(device, &err)) {
         error_report_err(err);
     } else if (strcmp(device, "none") == 0) {
-        monitor_printf(mon, "Disabled gdbserver\n");
+        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
     } else {
-        monitor_printf(mon, "Waiting for gdb connection on device '%s'\n",
-                       device);
+        monitor_hmp_printf(hmp, "Waiting for gdb connection on device '%s'\n",
+                           device);
     }
 }
 
 void hmp_print(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int format = qdict_get_int(qdict, "format");
     hwaddr val = qdict_get_int(qdict, "val");
 
     switch(format) {
     case 'o':
-        monitor_printf(mon, "%#" HWADDR_PRIo, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
         break;
     case 'x':
-        monitor_printf(mon, "%#" HWADDR_PRIx, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
         break;
     case 'u':
-        monitor_printf(mon, "%" HWADDR_PRIu, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
         break;
     default:
     case 'd':
-        monitor_printf(mon, "%" HWADDR_PRId, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
         break;
     case 'c':
-        monitor_printc(mon, val);
+        monitor_hmp_printc(hmp, val);
         break;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t addr;
     uint16_t sum;
     uint32_t start = qdict_get_int(qdict, "start");
@@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
         sum = (sum >> 1) | (sum << 15);
         sum += val;
     }
-    monitor_printf(mon, "%05d\n", sum);
+    monitor_hmp_printf(hmp, "%05d\n", sum);
 }
 
 void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int size = qdict_get_int(qdict, "size");
     int addr = qdict_get_int(qdict, "addr");
     int has_index = qdict_haskey(qdict, "index");
@@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
         suffix = 'l';
         break;
     }
-    monitor_printf(mon, "port%c[0x%04x] = 0x%0*x\n",
-                   suffix, addr, size * 2, val);
+    monitor_hmp_printf(hmp, "port%c[0x%04x] = 0x%0*x\n",
+                       suffix, addr, size * 2, val);
 }
 
 void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
@@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *local_err = NULL;
     const char *bootdevice = qdict_get_str(qdict, "bootdevice");
 
@@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "boot device list now set to %s\n", bootdevice);
+        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bootdevice);
     }
 }
 
@@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
+    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
 }
 #endif
 
@@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
 
 void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
     int vcpu = qdict_get_try_int(qdict, "vcpu", -1);
     CPUState *cs;
 
     if (all_cpus) {
         CPU_FOREACH(cs) {
-            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
             cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
         }
     } else {
@@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 
         if (!cs) {
             if (vcpu >= 0) {
-                monitor_printf(mon, "CPU#%d not available\n", vcpu);
+                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu);
             } else {
-                monitor_printf(mon, "No CPU available\n");
+                monitor_hmp_printf(hmp, "No CPU available\n");
             }
             return;
         }
 
-        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
         cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
     }
 }
@@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                         uint64_t addr, bool is_physical)
 {
-    Monitor *mon = MONITOR(hmp);
     int l, line_size, i, max_digits, len;
     uint8_t buf[16];
     uint64_t v;
@@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     const bool big_endian = target_big_endian();
 
     if (!cs && (format == 'i' || !is_physical)) {
-        monitor_printf(mon, "Can not dump without CPU\n");
+        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
         return;
     }
 
     if (format == 'i') {
-        monitor_disas(mon, cs, addr, count, is_physical);
+        monitor_disas(hmp, cs, addr, count, is_physical);
         return;
     }
 
@@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     }
 
     while (len > 0) {
-        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
+        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
         l = len;
         if (l > line_size) {
             l = line_size;
@@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
             MemTxResult r = address_space_read(as, addr,
                                                MEMTXATTRS_UNSPECIFIED, buf, l);
             if (r != MEMTX_OK) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         } else {
             if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         }
@@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                 v = (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
                 break;
             }
-            monitor_printf(mon, " ");
+            monitor_hmp_printf(hmp, " ");
             switch (format) {
             case 'o':
-                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
+                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
                 break;
             case 'x':
-                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
+                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v);
                 break;
             case 'u':
-                monitor_printf(mon, "%*" PRIu64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
                 break;
             case 'd':
-                monitor_printf(mon, "%*" PRId64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
                 break;
             case 'c':
-                monitor_printc(mon, v);
+                monitor_hmp_printc(hmp, v);
                 break;
             }
             i += wsize;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         addr += l;
         len -= l;
     }
@@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
-                   " (%s) is %p\n",
-                   addr, mr->name, ptr);
+    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
+                       " (%s) is %p\n",
+                       addr, mr->name, ptr);
 
     memory_region_unref(mr);
 }
 
 void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     vaddr addr = qdict_get_int(qdict, "addr");
     CPUState *cs = monitor_hmp_get_cpu(hmp);
     TranslateForDebugResult tres;
 
     if (!cs) {
-        monitor_printf(mon, "No cpu\n");
+        monitor_hmp_printf(hmp, "No cpu\n");
         return;
     }
 
     if (!cpu_translate_for_debug(cs, addr, &tres)) {
-        monitor_printf(mon, "Unmapped\n");
+        monitor_hmp_printf(hmp, "Unmapped\n");
     } else {
-        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
+        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
     }
 }
 
@@ -806,7 +786,6 @@ out:
 
 void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRIx
-                       " (%s) is 0x%" PRIx64 "\n",
-                       addr, mr->name, (uint64_t) physaddr);
+        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR_PRIx
+                           " (%s) is 0x%" PRIx64 "\n",
+                           addr, mr->name, (uint64_t) physaddr);
     }
 
     memory_region_unref(mr);
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 2484a2310dff..e5f8b9c576e0 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, bool val, Error **errp)
     hmp->use_readline = val;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
 static void monitor_hmp_accept_input(Monitor *mon);
 static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
 static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp);
@@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, const void *data)
                                    monitor_hmp_get_readline,
                                    monitor_hmp_set_readline);
 
-    moncls->vprintf = monitor_hmp_vprintf;
     moncls->accept_input = monitor_hmp_accept_input;
 
     ucc->complete = monitor_hmp_complete;
@@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
     hmp->use_readline = true;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-{
-    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
-    return monitor_puts(mon, buf);
-}
-
 static void monitor_hmp_accept_input(Monitor *mon)
 {
     qemu_mutex_lock(&mon->mon_lock);
@@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
         /* prompt is printed on return from the command handler */
         return 0;
     } else {
-        monitor_printf(&hmp->parent_obj,
-                       "terminal does not support password prompting\n");
+        monitor_hmp_printf(hmp, "terminal does not support password prompting\n");
         return -ENOTTY;
     }
 }
@@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
     return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
 }
 
-static void help_cmd_dump_one(Monitor *mon,
+static void help_cmd_dump_one(MonitorHMP *mon,
                               const HMPCommand *cmd,
                               char **prefix_args,
                               int prefix_args_nb)
@@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
     }
 
     for (i = 0; i < prefix_args_nb; i++) {
-        monitor_printf(mon, "%s ", prefix_args[i]);
+        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
     }
-    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
+    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
 }
 
 /* @args[@arg_index] is the valid command need to find in @cmds */
-static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
+static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
                           char **args, int nb_args, int arg_index)
 {
     const HMPCommand *cmd;
@@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
     }
 
     /* Command not found */
-    monitor_printf(mon, "unknown command: '");
+    monitor_hmp_printf(mon, "unknown command: '");
     for (i = 0; i <= arg_index; i++) {
-        monitor_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
+        monitor_hmp_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
     }
 }
 
-void hmp_help_cmd(Monitor *mon, const char *name)
+void hmp_help_cmd(MonitorHMP *mon, const char *name)
 {
     char *args[MAX_ARGS];
     int nb_args = 0;
@@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
         /* special case for log, directly dump and return */
         if (!strcmp(name, "log")) {
             const QEMULogItem *item;
-            monitor_printf(mon, "Log items (comma separated):\n");
-            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs");
+            monitor_hmp_printf(mon, "Log items (comma separated):\n");
+            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all logs");
             for (item = qemu_log_items; item->mask != 0; item++) {
-                monitor_printf(mon, "%-15s %s\n", item->name, item->help);
+                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item->help);
             }
 #ifdef CONFIG_TRACE_LOG
-            monitor_printf(mon, "trace:PATTERN   enable trace events\n");
-            monitor_printf(mon, "\nUse \"log trace:help\" to get a list of "
-                           "trace events.\n\n");
+            monitor_hmp_printf(mon, "trace:PATTERN   enable trace events\n");
+            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a list of "
+                               "trace events.\n\n");
 #endif
             return;
         }
@@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
 static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char *name);
 
 static G_NORETURN G_GNUC_PRINTF(2, 3)
-void expr_error(Monitor *mon, const char *fmt, ...)
+void expr_error(MonitorHMP *mon, const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(mon, fmt, ap);
-    monitor_printf(mon, "\n");
+    monitor_hmp_vprintf(mon, fmt, ap);
+    monitor_hmp_printf(mon, "\n");
     va_end(ap);
     siglongjmp(expr_env, 1);
 }
@@ -475,9 +465,9 @@ static void next(void)
     }
 }
 
-static int64_t expr_sum(Monitor *mon);
+static int64_t expr_sum(MonitorHMP *mon);
 
-static int64_t expr_unary(Monitor *mon)
+static int64_t expr_unary(MonitorHMP *mon)
 {
     int64_t n;
     char *p;
@@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
                 pch++;
             }
             *q = 0;
-            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
-                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
+            if (!gdb_get_register(mon, &reg, buf)
+                && get_monitor_def(mon, &reg, buf) < 0) {
                 expr_error(mon, "unknown register");
             }
             n = reg;
@@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
     return n;
 }
 
-static int64_t expr_prod(Monitor *mon)
+static int64_t expr_prod(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
     return val;
 }
 
-static int64_t expr_logic(Monitor *mon)
+static int64_t expr_logic(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
     return val;
 }
 
-static int64_t expr_sum(Monitor *mon)
+static int64_t expr_sum(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
     return val;
 }
 
-static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
+static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
 {
     pch = *pp;
     if (sigsetjmp(expr_env, 0)) {
@@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
     return 0;
 }
 
-static int get_double(Monitor *mon, double *pval, const char **pp)
+static int get_double(MonitorHMP *mon, double *pval, const char **pp)
 {
     const char *p = *pp;
     char *tailp;
@@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval, const char **pp)
 
     d = strtod(p, &tailp);
     if (tailp == p) {
-        monitor_printf(mon, "Number expected\n");
+        monitor_hmp_printf(mon, "Number expected\n");
         return -1;
     }
     if (d != d || d - d != 0) {
         /* NaN or infinity */
-        monitor_printf(mon, "Bad number\n");
+        monitor_hmp_printf(mon, "Bad number\n");
         return -1;
     }
     *pval = d;
@@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
                                                const char **cmdp,
                                                HMPCommand *table)
 {
-    Monitor *mon = &hmp->parent_obj;
     const char *p;
     const HMPCommand *cmd;
     char cmdname[256];
@@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
 
     cmd = search_dispatch_table(table, cmdname);
     if (!cmd) {
-        monitor_printf(mon, "unknown command: '%.*s'\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
     if (!cmd_available(cmd)) {
-        monitor_printf(mon, "Command '%.*s' not available "
-                            "until machine initialization has completed.\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "Command '%.*s' not available "
+                           "until machine initialization has completed.\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
 
@@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
  * Else, insert command arguments into a QDict, and return it.
  * Note: On success, caller has to free the QDict structure.
  */
-static QDict *monitor_parse_arguments(Monitor *mon,
+static QDict *monitor_parse_arguments(MonitorHMP *mon,
                                       const char **endp,
                                       const HMPCommand *cmd)
 {
@@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 if (ret < 0) {
                     switch (c) {
                     case 'F':
-                        monitor_printf(mon, "%s: filename expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: filename expected\n",
+                                           cmd->name);
                         break;
                     case 'B':
-                        monitor_printf(mon, "%s: block device name expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: block device name expected\n",
+                                           cmd->name);
                         break;
                     default:
-                        monitor_printf(mon, "%s: string expected\n", cmd->name);
+                        monitor_hmp_printf(mon, "%s: string expected\n", cmd->name);
                         break;
                     }
                     goto fail;
@@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 next:
                     if (*p != '\0' && !qemu_isspace(*p)) {
-                        monitor_printf(mon, "invalid char in format: '%c'\n",
-                                       *p);
+                        monitor_hmp_printf(mon, "invalid char in format: '%c'\n",
+                                           *p);
                         goto fail;
                     }
                     if (format < 0) {
@@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 /* Check if 'i' is greater than 32-bit */
                 if ((c == 'i') && ((val >> 32) & 0xffffffff)) {
-                    monitor_printf(mon, "\'%s\' has failed: ", cmd->name);
-                    monitor_printf(mon, "integer is for 32-bit values\n");
+                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd->name);
+                    monitor_hmp_printf(mon, "integer is for 32-bit values\n");
                     goto fail;
                 } else if (c == 'M') {
                     if (val < 0) {
-                        monitor_printf(mon, "enter a positive value\n");
+                        monitor_hmp_printf(mon, "enter a positive value\n");
                         goto fail;
                     }
                     val *= MiB;
@@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 ret = qemu_strtosz_MiB(p, &end, &val);
                 if (ret < 0 || val > INT64_MAX) {
-                    monitor_printf(mon, "invalid size\n");
+                    monitor_hmp_printf(mon, "invalid size\n");
                     goto fail;
                 }
                 qdict_put_int(qdict, key, val);
@@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 }
                 if (*p && !qemu_isspace(*p)) {
-                    monitor_printf(mon, "Unknown unit suffix\n");
+                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
                     goto fail;
                 }
                 qdict_put(qdict, key, qnum_from_double(val));
@@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 } else if (p - beg == 3 && !memcmp(beg, "off", p - beg)) {
                     val = false;
                 } else {
-                    monitor_printf(mon, "Expected 'on' or 'off'\n");
+                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n");
                     goto fail;
                 }
                 qdict_put_bool(qdict, key, val);
@@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     p++;
                     if (c != *p) {
                         if (!is_valid_option(p, typestr)) {
-                            monitor_printf(mon, "%s: unsupported option -%c\n",
-                                           cmd->name, *p);
+                            monitor_hmp_printf(mon, "%s: unsupported option -%c\n",
+                                               cmd->name, *p);
                             goto fail;
                         } else {
                             skip_key = 1;
@@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                         }
                         ret = get_str(buf, sizeof(buf), &p);
                         if (ret < 0) {
-                            monitor_printf(mon, "%s: value expected for -%c\n",
-                                           cmd->name, *tmp);
+                            monitor_hmp_printf(mon, "%s: value expected for -%c\n",
+                                               cmd->name, *tmp);
                             goto fail;
                         }
                         qdict_put_str(qdict, key, buf);
@@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 len = strlen(p);
                 if (len <= 0) {
-                    monitor_printf(mon, "%s: string expected\n",
-                                   cmd->name);
+                    monitor_hmp_printf(mon, "%s: string expected\n",
+                                       cmd->name);
                     goto fail;
                 }
                 qdict_put_str(qdict, key, p);
@@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
             break;
         default:
         bad_type:
-            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
+            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
             goto fail;
         }
         g_free(key);
@@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
         p++;
     }
     if (*p != '\0') {
-        monitor_printf(mon, "%s: extraneous characters at the end of line\n",
-                       cmd->name);
+        monitor_hmp_printf(mon, "%s: extraneous characters at the end of line\n",
+                           cmd->name);
         goto fail;
     }
 
@@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const char *cmdline)
 
     if (!cmd->cmd && !cmd->cmd_info_hrt) {
         /* FIXME: is it useful to try autoload modules here ??? */
-        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not available.\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
-    qdict = monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd);
+    qdict = monitor_parse_arguments(hmp, &cmdline, cmd);
     if (!qdict) {
         while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
             cmdline--;
         }
-        monitor_printf(&hmp->parent_obj,
-                       "Try \"help %.*s\" for more information\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp,
+                           "Try \"help %.*s\" for more information\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
@@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint8_t *buf, int size)
         }
     } else {
         if (size == 0 || buf[size - 1] != 0) {
-            monitor_printf(&hmp->parent_obj, "corrupted command\n");
+            monitor_hmp_printf(hmp, "corrupted command\n");
         } else {
             handle_hmp_command(hmp, (char *)buf);
         }
@@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEvent event)
         break;
 
     case CHR_EVENT_OPENED:
-        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
-                       "information\n", QEMU_VERSION);
+        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for more "
+                           "information\n", QEMU_VERSION);
         qemu_mutex_lock(&mon->mon_lock);
         hmp->reset_seen = 1;
         if (!mon->mux_out && hmp->use_readline) {
@@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_printf(void *opaque,
     MonitorHMP *hmp = opaque;
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(&hmp->parent_obj, fmt, ap);
+    monitor_hmp_vprintf(hmp, fmt, ap);
     va_end(ap);
 }
 
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index afdda1386080..c198c12eaa00 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -108,12 +108,6 @@ typedef struct HMPCommand {
 struct MonitorClass {
     ObjectClass parent_class;
 
-    /*
-     * If non-NULL, the monitor is able to print messages
-     * for attention of the client user
-     */
-    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
-        G_GNUC_PRINTF(2, 0);
     /*
      * If non-NULL, the monitor is able to send event
      * notifications back to the client
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 8528af6f79b8..da76e6e4ac19 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
     return monitor_puts_locked(mon, str);
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
-    MonitorClass *moncls;
+    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
 
     if (!mon) {
         return -1;
     }
 
-    moncls = MONITOR_GET_CLASS(mon);
-    if (!moncls->vprintf) {
-        return -1;
-    }
-
-    return moncls->vprintf(mon, fmt, ap);
+    return monitor_puts(MONITOR(mon), buf);
 }
 
-int monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
 {
     int ret;
 
     va_list ap;
     va_start(ap, fmt);
-    ret = monitor_vprintf(mon, fmt, ap);
+    ret = monitor_hmp_vprintf(mon, fmt, ap);
     va_end(ap);
     return ret;
 }
 
-void monitor_printc(Monitor *mon, int c)
+void monitor_hmp_printc(MonitorHMP *mon, int c)
 {
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
     switch(c) {
     case '\'':
-        monitor_printf(mon, "\\'");
+        monitor_hmp_printf(mon, "\\'");
         break;
     case '\\':
-        monitor_printf(mon, "\\\\");
+        monitor_hmp_printf(mon, "\\\\");
         break;
     case '\n':
-        monitor_printf(mon, "\\n");
+        monitor_hmp_printf(mon, "\\n");
         break;
     case '\r':
-        monitor_printf(mon, "\\r");
+        monitor_hmp_printf(mon, "\\r");
         break;
     default:
         if (c >= 32 && c <= 126) {
-            monitor_printf(mon, "%c", c);
+            monitor_hmp_printf(mon, "%c", c);
         } else {
-            monitor_printf(mon, "\\x%02x", c);
+            monitor_hmp_printf(mon, "\\x%02x", c);
         }
         break;
     }
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
 }
 
 static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
index 5b1c678f5d89..0d718d78aef9 100644
--- a/net/net-hmp-cmds.c
+++ b/net/net-hmp-cmds.c
@@ -28,26 +28,25 @@
 #include "qemu/help_option.h"
 #include "qemu/option.h"
 
-static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
+static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *ci)
 {
     NetFilterInfoList *f;
 
-    monitor_printf(mon, "%s: index=%" PRIu32 ",type=%s,%s\n",
-                   ci->name, ci->queue_index,
-                   NetClientDriver_str(ci->type), ci->info_str);
+    monitor_hmp_printf(hmp, "%s: index=%" PRIu32 ",type=%s,%s\n",
+                       ci->name, ci->queue_index,
+                       NetClientDriver_str(ci->type), ci->info_str);
     if (ci->filters) {
-        monitor_printf(mon, "filters:\n");
+        monitor_hmp_printf(hmp, "filters:\n");
         for (f = ci->filters; f; f = f->next) {
-            monitor_printf(mon, "  - %s: type=%s%s%s\n",
-                           f->value->name, f->value->type,
-                           f->value->info[0] ? "," : "", f->value->info);
+            monitor_hmp_printf(hmp, "  - %s: type=%s%s%s\n",
+                               f->value->name, f->value->type,
+                               f->value->info[0] ? "," : "", f->value->info);
         }
     }
 }
 
 void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     g_autoptr(NetworkInfo) info = qmp_x_query_network(&err);
     NetHubInfoList *h;
@@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
     for (h = info->hubs; h; h = h->next) {
         NetHubPortInfoList *p;
 
-        monitor_printf(mon, "hub %d\n", (int)h->value->id);
+        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
         for (p = h->value->ports; p; p = p->next) {
             if (p->value->peer) {
-                monitor_printf(mon, " \\ %s: ", p->value->name);
-                hmp_print_client_info(mon, p->value->peer);
+                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
+                hmp_print_client_info(hmp, p->value->peer);
             } else {
-                monitor_printf(mon, " \\ %s\n", p->value->name);
+                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
             }
         }
     }
@@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
         NetworkClientInfo *ci = entry->value;
 
         if (!ci->peer || ci->type == NET_CLIENT_DRIVER_NIC) {
-            hmp_print_client_info(mon, ci);
+            hmp_print_client_info(hmp, ci);
         } /* else it's a netdev connected to a NIC, printed with the NIC */
         if (ci->peer && ci->type == NET_CLIENT_DRIVER_NIC) {
-            monitor_printf(mon, " \\ ");
-            hmp_print_client_info(mon, ci->peer);
+            monitor_hmp_printf(hmp, " \\ ");
+            hmp_print_client_info(hmp, ci->peer);
         }
     }
 }
diff --git a/net/slirp.c b/net/slirp.c
index d5c190b48b76..6fbefa9ed1d7 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -711,22 +711,22 @@ error:
     return -1;
 }
 
-static SlirpState *slirp_lookup(Monitor *mon, const char *id)
+static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
 {
     if (id) {
         NetClientState *nc = qemu_find_netdev(id);
         if (!nc) {
-            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
+            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", id);
             return NULL;
         }
         if (strcmp(nc->model, "user")) {
-            monitor_printf(mon, "invalid device specified\n");
+            monitor_hmp_printf(hmp, "invalid device specified\n");
             return NULL;
         }
         return DO_UPCAST(SlirpState, nc, nc);
     } else {
         if (QTAILQ_EMPTY(&slirp_stacks)) {
-            monitor_printf(mon, "user mode network stack not in use\n");
+            monitor_hmp_printf(hmp, "user mode network stack not in use\n");
             return NULL;
         }
         return QTAILQ_FIRST(&slirp_stacks);
@@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const char *id)
 
 void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /* TODO: support removing unix fwd */
     struct sockaddr_in host_addr = {
         .sin_family = AF_INET,
@@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         src_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         src_str = arg1;
     }
     if (!s) {
@@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     err = slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr, host_port);
 #endif
 
-    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
-                   err ? "not found" : "removed");
+    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_str,
+                       err ? "not found" : "removed");
     return;
 
  fail_syntax:
-    monitor_printf(mon, "invalid format\n");
+    monitor_hmp_printf(hmp, "invalid format\n");
 }
 
 static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
@@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
 
 void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *redir_str;
     SlirpState *s;
     const char *arg1 = qdict_get_str(qdict, "arg1");
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         redir_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         redir_str = arg1;
     }
     if (s) {
@@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **errp)
 
 void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autoptr(UsernetInfoList) list = NULL;
     UsernetInfoList *entry;
 
     list = qmp_x_query_usernet(&error_abort);
     for (entry = list; entry; entry = entry->next) {
         UsernetInfo *ui = entry->value;
-        monitor_printf(mon, "Hub %d (%s):\n%s",
-                       ui->has_hub_id ? (int)ui->hub_id : -1,
-                       ui->hub_name, ui->info);
+        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
+                           ui->has_hub_id ? (int)ui->hub_id : -1,
+                           ui->hub_name, ui->info);
     }
 }
 
diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
index 2e2eb33371e2..bbf5980332a4 100644
--- a/qom/qom-hmp-cmds.c
+++ b/qom/qom-hmp-cmds.c
@@ -20,13 +20,12 @@
 
 void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(qdict, "path");
     ObjectPropertyInfoList *list;
     Error *err = NULL;
 
     if (path == NULL) {
-        monitor_printf(mon, "/\n");
+        monitor_hmp_printf(hmp, "/\n");
         return;
     }
 
@@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
         while (list != NULL) {
             ObjectPropertyInfo *value = list->value;
 
-            monitor_printf(mon, "%s (%s)\n",
-                           value->name, value->type);
+            monitor_hmp_printf(hmp, "%s (%s)\n",
+                               value->name, value->type);
             list = list->next;
         }
         qapi_free_ObjectPropertyInfoList(start);
@@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     const char *property = qdict_get_str(qdict, "property");
     Error *err = NULL;
@@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 
     if (err == NULL) {
         GString *str = qobject_to_json_pretty(obj, true);
-        monitor_printf(mon, "%s\n", str->str);
+        monitor_hmp_printf(hmp, "%s\n", str->str);
         g_string_free(str, true);
     }
 
@@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
     int indent;
 } QOMCompositionState;
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent);
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent);
 
 static int qom_composition_compare(const void *a, const void *b)
 {
@@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj, void *opaque)
     return 0;
 }
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent)
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent)
 {
     GArray *children = g_array_new(false, false, sizeof(Object *));
     const char *name;
@@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
     } else {
         name = object_get_canonical_path_component(obj);
     }
-    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
-                   object_get_typename(obj));
+    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
+                       object_get_typename(obj));
 
     object_child_foreach(obj, insert_qom_composition_child, children);
     g_array_sort(children, qom_composition_compare);
 
     for (i = 0; i < children->len; i++) {
-        print_qom_composition(mon, g_array_index(children, Object *, i),
+        print_qom_composition(hmp, g_array_index(children, Object *, i),
                               indent + 2);
     }
     g_array_free(children, TRUE);
@@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
 
 void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(dict, "path");
     Object *obj;
     bool ambiguous = false;
@@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
     if (path) {
         obj = object_resolve_path(path, &ambiguous);
         if (!obj) {
-            monitor_printf(mon, "Path '%s' could not be resolved.\n", path);
+            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\n", path);
             return;
         }
         if (ambiguous) {
-            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", path);
+            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\n", path);
             return;
         }
     } else {
         obj = qdev_get_machine();
     }
-    print_qom_composition(mon, obj, 0);
+    print_qom_composition(hmp, obj, 0);
 }
 
 void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index ef69d23ff507..965565715ef2 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -33,11 +33,10 @@ bool replay_running_debug(void)
 
 void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     if (replay_mode == REPLAY_MODE_NONE) {
-        monitor_printf(mon, "Record/replay is not active\n");
+        monitor_hmp_printf(hmp, "Record/replay is not active\n");
     } else {
-        monitor_printf(mon,
+        monitor_hmp_printf(hmp,
             "%s execution '%s': instruction count = %"PRId64"\n",
             replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
             replay_get_filename(), replay_get_current_icount());
diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
index cd1f1deb58bc..3d556c745d61 100644
--- a/stats/stats-hmp-cmds.c
+++ b/stats/stats-hmp-cmds.c
@@ -14,11 +14,11 @@
 #include "qobject/qdict.h"
 #include "qapi/error.h"
 
-static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
+static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue *value)
 {
     const char *unit = NULL;
-    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(value->type),
-                   value->has_unit || value->exponent ? ", " : "");
+    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str(value->type),
+                       value->has_unit || value->exponent ? ", " : "");
 
     if (value->has_unit) {
         if (value->unit == STATS_UNIT_SECONDS) {
@@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
     if (unit && value->base == 10 &&
         value->exponent >= -18 && value->exponent <= 18 &&
         value->exponent % 3 == 0) {
-        monitor_puts(mon, si_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
     } else if (unit && value->base == 2 &&
                value->exponent >= 0 && value->exponent <= 60 &&
                value->exponent % 10 == 0) {
 
-        monitor_puts(mon, iec_binary_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent));
     } else if (value->exponent) {
         /* Use exponential notation and write the unit's English name */
-        monitor_printf(mon, "* %d^%d%s",
-                       value->base, value->exponent,
-                       value->has_unit ? " " : "");
+        monitor_hmp_printf(hmp, "* %d^%d%s",
+                           value->base, value->exponent,
+                           value->has_unit ? " " : "");
         unit = NULL;
     }
 
     if (value->has_unit) {
-        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
+        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->unit));
     }
 
     /* Print bucket size for linear histograms */
     if (value->type == STATS_TYPE_LINEAR_HISTOGRAM && value->has_bucket_size) {
-        monitor_printf(mon, ", bucket size=%d", value->bucket_size);
+        monitor_hmp_printf(hmp, ", bucket size=%d", value->bucket_size);
     }
-    monitor_printf(mon, ")");
+    monitor_hmp_printf(hmp, ")");
 }
 
 static StatsSchemaValueList *find_schema_value_list(
@@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
     return NULL;
 }
 
-static void print_stats_results(Monitor *mon, StatsTarget target,
+static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
                                 bool show_provider,
                                 StatsResult *result,
                                 StatsSchemaList *schema)
@@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
     StatsList *stats_list;
 
     if (!schema_value_list) {
-        monitor_printf(mon, "failed to find schema list for %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
+                           StatsProvider_str(result->provider));
         return;
     }
 
     if (show_provider) {
-        monitor_printf(mon, "provider: %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "provider: %s\n",
+                           StatsProvider_str(result->provider));
     }
 
     for (stats_list = result->stats; stats_list;
@@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
         /* Find schema entry */
         while (!g_str_equal(stats->name, schema_value->name)) {
             if (!schema_value_list->next) {
-                monitor_printf(mon, "failed to find schema entry for %s\n",
-                               stats->name);
+                monitor_hmp_printf(hmp, "failed to find schema entry for %s\n",
+                                   stats->name);
                 return;
             }
             schema_value_list = schema_value_list->next;
             schema_value = schema_value_list->value;
         }
 
-        print_stats_schema_value(mon, schema_value);
+        print_stats_schema_value(hmp, schema_value);
 
         if (stats_value->type == QTYPE_QNUM) {
-            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scalar);
+            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.scalar);
         } else if (stats_value->type == QTYPE_QBOOL) {
-            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "yes" : "no");
+            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ? "yes" : "no");
         } else if (stats_value->type == QTYPE_QLIST) {
             uint64List *list;
             int i;
 
-            monitor_printf(mon, ": ");
+            monitor_hmp_printf(hmp, ": ");
             for (list = stats_value->u.list, i = 1;
                  list;
                  list = list->next, i++) {
-                monitor_printf(mon, "[%d]=%" PRId64 " ", i, list->value);
+                monitor_hmp_printf(hmp, "[%d]=%" PRId64 " ", i, list->value);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 }
@@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target, const char *names,
 
 void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *target_str = qdict_get_str(qdict, "target");
     const char *provider_str = qdict_get_try_str(qdict, "provider");
     const char *names = qdict_get_try_str(qdict, "names");
@@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 
     target = qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &err);
     if (err) {
-        monitor_printf(mon, "invalid stats target %s\n", target_str);
+        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_str);
         goto exit_no_print;
     }
     if (provider_str) {
         provider = qapi_enum_parse(&StatsProvider_lookup, provider_str, -1, &err);
         if (err) {
-            monitor_printf(mon, "invalid stats provider %s\n", provider_str);
+            monitor_hmp_printf(hmp, "invalid stats provider %s\n", provider_str);
             goto exit_no_print;
         }
     }
@@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
         goto exit;
     }
     for (entry = stats; entry; entry = entry->next) {
-        print_stats_results(mon, target, provider_str == NULL, entry->value, schema);
+        print_stats_results(hmp, target, provider_str == NULL, entry->value, schema);
     }
 
 exit:
     if (err) {
-        monitor_printf(mon, "%s\n", error_get_pretty(err));
+        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
     }
 exit_no_print:
     error_free(err);
diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
index 6f2b87d1ad10..c9c1d10c165c 100644
--- a/stubs/hmp-cmd-info_sev.c
+++ b/stubs/hmp-cmd-info_sev.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SEV is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
 }
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index b0c7002bd406..094b80721003 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
 {
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     /*
      * Pretend 'g_test_message' is our monitor console to
diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.c
index 75194add7931..fb9338e9aef6 100644
--- a/system/dirtylimit-hmp-cmds.c
+++ b/system/dirtylimit-hmp-cmds.c
@@ -17,7 +17,6 @@
 
 void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index = qdict_get_try_int(qdict, "cpu_index", -1);
     Error *err = NULL;
 
@@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query "
-                   "dirty limit for virtual CPU]\n");
+    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to query "
+                       "dirty limit for virtual CPU]\n");
 }
 
 void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
@@ -50,13 +49,12 @@ out:
 
 void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyLimitInfoList *info;
     g_autoptr(DirtyLimitInfoList) head = NULL;
     Error *err = NULL;
 
     if (!dirtylimit_in_service()) {
-        monitor_printf(mon, "Dirty page limit not enabled!\n");
+        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
         return;
     }
 
@@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (info = head; info != NULL; info = info->next) {
-        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
+        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
                             " current rate %"PRIi64 " (MB/s)\n",
                             info->value->cpu_index,
                             info->value->limit_rate,
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 5c2de2f53cc9..3860ada2a237 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
     return ret;
 }
 
-#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ## __VA_ARGS__)
+#define qdev_printf(fmt, ...) \
+    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
 
-static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
+static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
                              int indent)
 {
     for (int i = 0, n = dc->props_count_; i < n; ++i) {
@@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int ind
     }
 }
 
-static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
+static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
+    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
     }
     class = object_get_class(OBJECT(dev));
     do {
-        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
+        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
     bus_print_dev(dev->parent_bus, mon, dev, indent);
 }
 
-static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
+static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)
 {
     BusChild *kid;
 
@@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
         qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
                     dev->id ? dev->id : "");
         if (details) {
-            qdev_print(mon, dev, indent + 2);
+            qdev_print(hmp, dev, indent + 2);
         }
         QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
-            qbus_print(mon, child_bus, indent + 2, details);
+            qbus_print(hmp, child_bus, indent + 2, details);
         }
     }
 }
@@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
 
 void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool details = !qdict_get_try_bool(qdict, "brief", false);
 
     if (sysbus_get_default()) {
-        qbus_print(mon, sysbus_get_default(), 0, details);
+        qbus_print(hmp, sysbus_get_default(), 0, details);
     }
 }
 
diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
index 051ee45ee74c..ad70b53f8abf 100644
--- a/system/runstate-hmp-cmds.c
+++ b/system/runstate-hmp-cmds.c
@@ -25,33 +25,31 @@
 
 void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     StatusInfo *info;
 
     info = qmp_query_status(NULL);
 
-    monitor_printf(mon, "VM status: %s",
-                   info->running ? "running" : "paused");
+    monitor_hmp_printf(hmp, "VM status: %s",
+                       info->running ? "running" : "paused");
 
     if (!info->running && info->status != RUN_STATE_PAUSED) {
-        monitor_printf(mon, " (%s)", RunState_str(info->status));
+        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_StatusInfo(info);
 }
 
 void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *option = qdict_get_try_str(qdict, "option");
     AccelState *accel = current_accel();
     bool newval;
 
     if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
-        monitor_printf(mon,
-                       "This accelerator does not support setting one-insn-per-tb\n");
+        monitor_hmp_printf(hmp,
+                           "This accelerator does not support setting one-insn-per-tb\n");
         return;
     }
 
@@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
     } else if (!strcmp(option, "off")) {
         newval = false;
     } else {
-        monitor_printf(mon, "unexpected option %s\n", option);
+        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
         return;
     }
     /* If the property exists then setting it can never fail */
diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
index 094c3f16cf50..35406e24d2c3 100644
--- a/system/tpm-hmp-cmds.c
+++ b/system/tpm-hmp-cmds.c
@@ -13,7 +13,6 @@
 
 void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
 #ifdef CONFIG_TPM
     TPMInfoList *info_list, *info;
     Error *err = NULL;
@@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 
     info_list = qmp_query_tpm(&err);
     if (err) {
-        monitor_printf(mon, "TPM device not supported\n");
+        monitor_hmp_printf(hmp, "TPM device not supported\n");
         error_free(err);
         return;
     }
 
     if (info_list) {
-        monitor_printf(mon, "TPM device:\n");
+        monitor_hmp_printf(hmp, "TPM device:\n");
     }
 
     for (info = info_list; info; info = info->next) {
         TPMInfo *ti = info->value;
-        monitor_printf(mon, " tpm%d: model=%s\n",
-                       c, TpmModel_str(ti->model));
+        monitor_hmp_printf(hmp, " tpm%d: model=%s\n",
+                           c, TpmModel_str(ti->model));
 
-        monitor_printf(mon, "  \\ %s: type=%s",
-                       ti->id, TpmType_str(ti->options->type));
+        monitor_hmp_printf(hmp, "  \\ %s: type=%s",
+                           ti->id, TpmType_str(ti->options->type));
 
         switch (ti->options->type) {
         case TPM_TYPE_PASSTHROUGH:
             tpo = ti->options->u.passthrough.data;
-            monitor_printf(mon, "%s%s%s%s",
-                           tpo->path ? ",path=" : "",
-                           tpo->path ?: "",
-                           tpo->cancel_path ? ",cancel-path=" : "",
-                           tpo->cancel_path ?: "");
+            monitor_hmp_printf(hmp, "%s%s%s%s",
+                               tpo->path ? ",path=" : "",
+                               tpo->path ?: "",
+                               tpo->cancel_path ? ",cancel-path=" : "",
+                               tpo->cancel_path ?: "");
             break;
         case TPM_TYPE_EMULATOR:
             teo = ti->options->u.emulator.data;
-            monitor_printf(mon, ",chardev=%s", teo->chardev);
+            monitor_hmp_printf(hmp, ",chardev=%s", teo->chardev);
             break;
         case TPM_TYPE__MAX:
             break;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         c++;
     }
     qapi_free_TPMInfoList(info_list);
 #else
-    monitor_printf(mon, "TPM device not supported\n");
+    monitor_hmp_printf(hmp, "TPM device not supported\n");
 #endif /* CONFIG_TPM */
 }
diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
index af67f00dad32..96d6ad897275 100644
--- a/target/i386/cpu-apic.c
+++ b/target/i386/cpu-apic.c
@@ -85,7 +85,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
 
 void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUState *cs;
 
     if (qdict_haskey(qdict, "apic-id")) {
@@ -101,7 +100,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 
 
     if (!cs) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 72bcab131f77..46762540ba65 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
     return addr;
 }
 
-static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
+static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
                       hwaddr pte, hwaddr mask)
 {
     addr = addr_canonical(env, addr);
 
-    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
-                   " %c%c%c%c%c%c%c%c%c\n",
-                   addr,
-                   pte & mask,
-                   pte & PG_NX_MASK ? 'X' : '-',
-                   pte & PG_GLOBAL_MASK ? 'G' : '-',
-                   pte & PG_PSE_MASK ? 'P' : '-',
-                   pte & PG_DIRTY_MASK ? 'D' : '-',
-                   pte & PG_ACCESSED_MASK ? 'A' : '-',
-                   pte & PG_PCD_MASK ? 'C' : '-',
-                   pte & PG_PWT_MASK ? 'T' : '-',
-                   pte & PG_USER_MASK ? 'U' : '-',
-                   pte & PG_RW_MASK ? 'W' : '-');
+    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
+                       " %c%c%c%c%c%c%c%c%c\n",
+                       addr,
+                       pte & mask,
+                       pte & PG_NX_MASK ? 'X' : '-',
+                       pte & PG_GLOBAL_MASK ? 'G' : '-',
+                       pte & PG_PSE_MASK ? 'P' : '-',
+                       pte & PG_DIRTY_MASK ? 'D' : '-',
+                       pte & PG_ACCESSED_MASK ? 'A' : '-',
+                       pte & PG_PCD_MASK ? 'C' : '-',
+                       pte & PG_PWT_MASK ? 'T' : '-',
+                       pte & PG_USER_MASK ? 'U' : '-',
+                       pte & PG_RW_MASK ? 'W' : '-');
 }
 
-static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 /* 4M pages */
-                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
+                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1));
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
+                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
                                   pte & ~PG_PSE_MASK,
                                   ~0xfff);
                     }
@@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
     }
 }
 
-static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 if (pde & PG_PRESENT_MASK) {
                     if (pde & PG_PSE_MASK) {
                         /* 2M pages with PAE, CR4.PSE is ignored */
-                        print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
+                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), pde,
                                   ~((hwaddr)(1 << 20) - 1));
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
@@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             pte = address_space_ldq_le(as, pt_addr + l3 * 8,
                                                        attrs, NULL);
                             if (pte & PG_PRESENT_MASK) {
-                                print_pte(mon, env, (l1 << 30) + (l2 << 21)
+                                print_pte(hmp, env, (l1 << 30) + (l2 << 21)
                                           + (l3 << 12),
                                           pte & ~PG_PSE_MASK,
                                           ~(hwaddr)0xfff);
@@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
 }
 
 #ifdef TARGET_X86_64
-static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
+static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as,
         uint64_t l0, uint64_t pml4_addr)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
@@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
             if (pdpe & PG_PSE_MASK) {
                 /* 1G pages, CR4.PSE is ignored */
-                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
+                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
                         pdpe, 0x3ffffc0000000ULL);
                 continue;
             }
@@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
                 if (pde & PG_PSE_MASK) {
                     /* 2M pages, CR4.PSE is ignored */
-                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
+                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
                             (l3 << 21), pde, 0x3ffffffe00000ULL);
                     continue;
                 }
@@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
                     pte = address_space_ldq_le(as, pt_addr + l4 * 8,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
+                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
                                 (l2 << 30) + (l3 << 21) + (l4 << 12),
                                 pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
                     }
@@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
     }
 }
 
-static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     uint64_t l0;
@@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
     for (l0 = 0; l0 < 512; l0++) {
         pml5e = address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, NULL);
         if (pml5e & PG_PRESENT_MASK) {
-            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL);
+            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL);
         }
     }
 }
@@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                tlb_info_la57(mon, env, as);
+                tlb_info_la57(hmp, env, as);
             } else {
-                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
+                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
             }
         } else
 #endif
         {
-            tlb_info_pae32(mon, env, as);
+            tlb_info_pae32(hmp, env, as);
         }
     } else {
-        tlb_info_32(mon, env, as);
+        tlb_info_32(hmp, env, as);
     }
 }
 
-static void mem_print(Monitor *mon, CPUArchState *env,
+static void mem_print(MonitorHMP *hmp, CPUArchState *env,
                       hwaddr *pstart, int *plast_prot,
                       hwaddr end, int prot)
 {
@@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     prot1 = *plast_prot;
     if (prot != prot1) {
         if (*pstart != -1) {
-            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
-                           HWADDR_FMT_plx " %c%c%c\n",
-                           addr_canonical(env, *pstart),
-                           addr_canonical(env, end),
-                           addr_canonical(env, end - *pstart),
-                           prot1 & PG_USER_MASK ? 'u' : '-',
-                           'r',
-                           prot1 & PG_RW_MASK ? 'w' : '-');
+            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
+                               HWADDR_FMT_plx " %c%c%c\n",
+                               addr_canonical(env, *pstart),
+                               addr_canonical(env, end),
+                               addr_canonical(env, end - *pstart),
+                               prot1 & PG_USER_MASK ? 'u' : '-',
+                               'r',
+                               prot1 & PG_RW_MASK ? 'w' : '-');
         }
         if (prot != 0)
             *pstart = end;
@@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     }
 }
 
-static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 prot = pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
@@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     } else {
                         prot = 0;
                     }
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
-static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     if (pde & PG_PSE_MASK) {
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                       PG_PRESENT_MASK);
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             } else {
                                 prot = 0;
                             }
-                            mem_print(mon, env, &start, &last_prot, end, prot);
+                            mem_print(hmp, env, &start, &last_prot, end, prot);
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
 
 #ifdef TARGET_X86_64
-static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                                        PG_PRESENT_MASK);
                         prot &= pml4e;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pd_addr = pdpe & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                     prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                                   PG_PRESENT_MASK);
                                     prot &= pml4e & pdpe;
-                                    mem_print(mon, env, &start,
+                                    mem_print(hmp, env, &start,
                                               &last_prot, end, prot);
                                 } else {
                                     pt_addr = pde & 0x3fffffffff000ULL;
@@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                         } else {
                                             prot = 0;
                                         }
-                                        mem_print(mon, env, &start,
+                                        mem_print(hmp, env, &start,
                                                   &last_prot, end, prot);
                                     }
                                 }
                             } else {
                                 prot = 0;
-                                mem_print(mon, env, &start,
+                                mem_print(hmp, env, &start,
                                           &last_prot, end, prot);
                             }
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
 }
 
-static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
         end = l0 << 48;
         if (!(pml5e & PG_PRESENT_MASK)) {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
             continue;
         }
 
@@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
             end = (l0 << 48) + (l1 << 39);
             if (!(pml4e & PG_PRESENT_MASK)) {
                 prot = 0;
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
                 continue;
             }
 
@@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 end = (l0 << 48) + (l1 << 39) + (l2 << 30);
                 if (pdpe & PG_PRESENT_MASK) {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                             PG_PRESENT_MASK);
                     prot &= pml5e & pml4e;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
                     if (pde & PG_PRESENT_MASK) {
                         prot = 0;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                 PG_PRESENT_MASK);
                         prot &= pml5e & pml4e & pdpe;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         } else {
                             prot = 0;
                         }
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     }
                 }
             }
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
 }
 #endif /* TARGET_X86_64 */
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                mem_info_la57(mon, env, as);
+                mem_info_la57(hmp, env, as);
             } else {
-                mem_info_la48(mon, env, as);
+                mem_info_la48(hmp, env, as);
             }
         } else
 #endif
         {
-            mem_info_pae32(mon, env, as);
+            mem_info_pae32(hmp, env, as);
         }
     } else {
-        mem_info_32(mon, env, as);
+        mem_info_32(hmp, env, as);
     }
 }
 
diff --git a/target/i386/sev.c b/target/i386/sev.c
index a3f6ee95aaed..7b2eb75fd480 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -786,33 +786,32 @@ SevInfo *qmp_query_sev(Error **errp)
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SevInfo *info = sev_get_info();
 
     if (!info || !info->enabled) {
-        monitor_printf(mon, "SEV is not enabled\n");
+        monitor_hmp_printf(hmp, "SEV is not enabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
-    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
-    monitor_printf(mon, "build: %d\n", info->build_id);
-    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
-                   info->api_minor);
+    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->sev_type));
+    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
+    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
+    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
+                       info->api_minor);
 
     if (sev_snp_enabled()) {
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
-                                                                       : "off");
-        monitor_printf(mon, "SMT allowed: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
-                                                                       : "off");
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
+                                                                           : "off");
+        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
+                                                                           : "off");
     } else {
-        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
-        monitor_printf(mon, "key-sharing: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
+        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
+        monitor_hmp_printf(hmp, "key-sharing: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
     }
 
 out:
diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
index 5645a5d4d4f5..23c25283b27a 100644
--- a/target/m68k/monitor.c
+++ b/target/m68k/monitor.c
@@ -12,11 +12,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
index 5769829bdd7e..6e8a075f5a41 100644
--- a/target/ppc/monitor.c
+++ b/target/ppc/monitor.c
@@ -13,11 +13,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
index 4c9c0c793b36..59cc04b3d0fb 100644
--- a/target/riscv/monitor.c
+++ b/target/riscv/monitor.c
@@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, target_ulong addr)
     return addr;
 }
 
-static void print_pte_header(Monitor *mon)
+static void print_pte_header(MonitorHMP *hmp)
 {
-    monitor_printf(mon, PTE_HEADER_FIELDS);
-    monitor_printf(mon, PTE_HEADER_DELIMITER);
+    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
+    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
 }
 
-static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
+static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr,
                       hwaddr paddr, target_ulong size, int attr)
 {
     /* sanity check on vaddr */
@@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
         return;
     }
 
-    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
-                   " %c%c%c%c%c%c%c\n",
-                   addr_canonical(va_bits, vaddr),
-                   paddr, size,
-                   attr & PTE_R ? 'r' : '-',
-                   attr & PTE_W ? 'w' : '-',
-                   attr & PTE_X ? 'x' : '-',
-                   attr & PTE_U ? 'u' : '-',
-                   attr & PTE_G ? 'g' : '-',
-                   attr & PTE_A ? 'a' : '-',
-                   attr & PTE_D ? 'd' : '-');
+    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
+                       " %c%c%c%c%c%c%c\n",
+                       addr_canonical(va_bits, vaddr),
+                       paddr, size,
+                       attr & PTE_R ? 'r' : '-',
+                       attr & PTE_W ? 'w' : '-',
+                       attr & PTE_X ? 'x' : '-',
+                       attr & PTE_U ? 'u' : '-',
+                       attr & PTE_G ? 'g' : '-',
+                       attr & PTE_A ? 'a' : '-',
+                       attr & PTE_D ? 'd' : '-');
 }
 
-static void walk_pte(Monitor *mon, AddressSpace *as,
+static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
                      hwaddr base, target_ulong start,
                      int level, int ptidxbits, int ptesize, int va_bits,
                      target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
@@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 if ((*last_attr != attr) ||
                     (*last_paddr + *last_size != paddr) ||
                     (last_start + *last_size != start)) {
-                    print_pte(mon, va_bits, *vbase, *pbase,
+                    print_pte(hmp, va_bits, *vbase, *pbase,
                               *last_paddr + *last_size - *pbase, *last_attr);
 
                     *vbase = start;
@@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 *last_size = pgsize;
             } else {
                 /* pointer to the next level of the page table */
-                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, ptesize,
+                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, ptesize,
                          va_bits, vbase, pbase, last_paddr,
                          last_size, last_attr);
             }
@@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
 
 }
 
-static void mem_info_svxx(Monitor *mon, CPUArchState *env)
+static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
 {
     AddressSpace *as = env_cpu(env)->as;
     int levels, ptidxbits, ptesize, vm, va_bits;
@@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     va_bits = PGSHIFT + levels * ptidxbits;
 
     /* print header */
-    print_pte_header(mon);
+    print_pte_header(hmp);
 
     vbase = -1;
     pbase = -1;
@@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     last_attr = 0;
 
     /* walk page tables, starting from address 0 */
-    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
+    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
              &vbase, &pbase, &last_paddr, &last_size, &last_attr);
 
     /* don't forget the last one */
-    print_pte(mon, va_bits, vbase, pbase,
+    print_pte(hmp, va_bits, vbase, pbase,
               last_paddr + last_size - pbase, last_attr);
 }
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!riscv_cpu_cfg(env)->mmu) {
-        monitor_printf(mon, "S-mode MMU unavailable\n");
+        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
         return;
     }
 
     if (riscv_cpu_mxl(env) == MXL_RV32) {
         if (!(env->satp & SATP32_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     } else {
         if (!(env->satp & SATP64_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     }
 
-    mem_info_svxx(mon, env);
+    mem_info_svxx(hmp, env);
 }
 
 #ifdef CONFIG_TCG
diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
index 4e443152bf56..62998a9a57cb 100644
--- a/target/sh4/monitor.c
+++ b/target/sh4/monitor.c
@@ -26,33 +26,32 @@
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
 
-static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
+static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
 {
-    monitor_printf(mon, " tlb%i:\t"
-                   "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
-                   "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
-                   "dirty=%hhu writethrough=%hhu\n",
-                   idx,
-                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
-                   tlb->v, tlb->sh, tlb->c, tlb->pr,
-                   tlb->d, tlb->wt);
+    monitor_hmp_printf(hmp, " tlb%i:\t"
+                       "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
+                       "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
+                       "dirty=%hhu writethrough=%hhu\n",
+                       idx,
+                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
+                       tlb->v, tlb->sh, tlb->c, tlb->pr,
+                       tlb->d, tlb->wt);
 }
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env = monitor_hmp_get_cpu_env(hmp);
     int i;
 
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
-    monitor_printf (mon, "ITLB:\n");
+    monitor_hmp_printf(hmp, "ITLB:\n");
     for (i = 0 ; i < ITLB_SIZE ; i++)
-        print_tlb (mon, i, &env->itlb[i]);
-    monitor_printf (mon, "UTLB:\n");
+        print_tlb(hmp, i, &env->itlb[i]);
+    monitor_hmp_printf(hmp, "UTLB:\n");
     for (i = 0 ; i < UTLB_SIZE ; i++)
-        print_tlb (mon, i, &env->utlb[i]);
+        print_tlb(hmp, i, &env->utlb[i]);
 }
diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
index e826e584a918..36f109cbb568 100644
--- a/target/sparc/monitor.c
+++ b/target/sparc/monitor.c
@@ -29,11 +29,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
index b7b7387706f3..b9c4089b0fb1 100644
--- a/target/xtensa/monitor.c
+++ b/target/xtensa/monitor.c
@@ -28,11 +28,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index b2a884529598..530a3fee3c13 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
  */
 Monitor *monitor_cur(void) { return cur_mon; }
 Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort(); }
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) { abort(); }
 
 #ifndef _WIN32
 static void test_socket_fd_pass_name_good(void)
diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
index f62b2f294952..81a09ec5adfa 100644
--- a/tools/qemu-vnc/clipboard.c
+++ b/tools/qemu-vnc/clipboard.c
@@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboardRequest *req)
         "Cancelled clipboard request");
 
     g_clear_object(&req->invocation);
-    g_clear_handle_id(&req->timeout_id, g_source_remove);;
+    g_clear_handle_id(&req->timeout_id, g_source_remove);
 }
 
 static gboolean
@@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *info)
         vnc_dbus_clipboard_complete_request(
             req->invocation, info, req->type);
         g_clear_object(&req->invocation);
-        g_clear_handle_id(&req->timeout_id, g_source_remove);;
+        g_clear_handle_id(&req->timeout_id, g_source_remove);
         return;
     }
 
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 26597fefaa99..0aa50a901d37 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
     return NULL;
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     return -1;
 }
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 5a8158f4f4b6..a68f5b900d7c 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_TRACE_SIMPLE
 void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
     const char *arg = qdict_get_try_str(qdict, "arg");
 
@@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
             st_set_trace_file(arg);
         }
     } else {
-        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
-        hmp_help_cmd(mon, "trace-file");
+        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
+        hmp_help_cmd(hmp, "trace-file");
     }
 }
 #endif
 
 void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_try_str(qdict, "name");
     TraceEventInfoList *events;
     TraceEventInfoList *elem;
@@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (elem = events; elem != NULL; elem = elem->next) {
-        monitor_printf(mon, "%s : state %u\n",
-                       elem->value->name,
-                       elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
+        monitor_hmp_printf(hmp, "%s : state %u\n",
+                           elem->value->name,
+                           elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
     }
     qapi_free_TraceEventInfoList(events);
 }
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 186209fd0234..f611dd7ee457 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MouseInfoList *mice_list, *mouse;
 
     mice_list = qmp_query_mice(NULL);
     if (!mice_list) {
-        monitor_printf(mon, "No mouse devices connected\n");
+        monitor_hmp_printf(hmp, "No mouse devices connected\n");
         return;
     }
 
     for (mouse = mice_list; mouse; mouse = mouse->next) {
-        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
-                       mouse->value->current ? '*' : ' ',
-                       mouse->value->index, mouse->value->name,
-                       mouse->value->absolute ? " (absolute)" : "");
+        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
+                           mouse->value->current ? '*' : ' ',
+                           mouse->value->index, mouse->value->name,
+                           mouse->value->absolute ? " (absolute)" : "");
     }
 
     qapi_free_MouseInfoList(mice_list);
@@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
 /* Helper for hmp_info_vnc_clients, _servers */
-static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
+static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
                                   const char *name)
 {
-    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
-                   name,
-                   info->host,
-                   info->service,
-                   NetworkAddressFamily_str(info->family),
-                   info->websocket ? " (Websocket)" : "");
+    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
+                       name,
+                       info->host,
+                       info->service,
+                       NetworkAddressFamily_str(info->family),
+                       info->websocket ? " (Websocket)" : "");
 }
 
 /* Helper displaying and auth and crypt info */
-static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
+static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent,
                                    VncPrimaryAuth auth,
                                    VncVencryptSubAuth *vencrypt)
 {
-    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
-                   VncPrimaryAuth_str(auth),
-                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
+    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
+                       VncPrimaryAuth_str(auth),
+                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
 }
 
-static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *client)
+static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *client)
 {
     while (client) {
         VncClientInfo *cinfo = client->value;
 
-        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Client");
-        monitor_printf(mon, "    x509_dname: %s\n",
-                       cinfo->x509_dname ?: "none");
-        monitor_printf(mon, "    sasl_username: %s\n",
-                       cinfo->sasl_username ?: "none");
+        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Client");
+        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
+                           cinfo->x509_dname ?: "none");
+        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
+                           cinfo->sasl_username ?: "none");
 
         client = client->next;
     }
 }
 
-static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
+static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *server)
 {
     while (server) {
         VncServerInfo2 *sinfo = server->value;
-        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "Server");
-        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
+        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "Server");
+        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
                                sinfo->has_vencrypt ? &sinfo->vencrypt : NULL);
         server = server->next;
     }
@@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
 
 void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VncInfo2List *info2l, *info2l_head;
     Error *err = NULL;
 
@@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
     if (!info2l) {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
         return;
     }
 
     while (info2l) {
         VncInfo2 *info = info2l->value;
-        monitor_printf(mon, "%s:\n", info->id);
-        hmp_info_vnc_servers(mon, info->server);
-        hmp_info_vnc_clients(mon, info->clients);
+        monitor_hmp_printf(hmp, "%s:\n", info->id);
+        hmp_info_vnc_servers(hmp, info->server);
+        hmp_info_vnc_clients(hmp, info->clients);
         if (!info->server) {
             /*
              * The server entry displays its auth, we only need to
              * display in the case of 'reverse' connections where
              * there's no server.
              */
-            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
+            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
                                info->has_vencrypt ? &info->vencrypt : NULL);
         }
         if (info->display) {
-            monitor_printf(mon, "  Display: %s\n", info->display);
+            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
         }
         info2l = info2l->next;
     }
@@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_SPICE
 void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SpiceChannelList *chan;
     SpiceInfo *info;
     const char *channel_name;
@@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
     info = qmp_query_spice(NULL);
 
     if (!info->enabled) {
-        monitor_printf(mon, "Server: disabled\n");
+        monitor_hmp_printf(hmp, "Server: disabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "Server:\n");
+    monitor_hmp_printf(hmp, "Server:\n");
     if (info->has_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
-                       info->host, info->port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
+                           info->host, info->port);
     }
     if (info->has_tls_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
-                       info->host, info->tls_port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n",
+                           info->host, info->tls_port);
     }
-    monitor_printf(mon, "    migrated: %s\n",
-                   info->migrated ? "true" : "false");
-    monitor_printf(mon, "        auth: %s\n", info->auth);
-    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
-    monitor_printf(mon, "  mouse-mode: %s\n",
-                   SpiceQueryMouseMode_str(info->mouse_mode));
+    monitor_hmp_printf(hmp, "    migrated: %s\n",
+                       info->migrated ? "true" : "false");
+    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
+    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_version);
+    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
+                       SpiceQueryMouseMode_str(info->mouse_mode));
 
     if (!info->has_channels || info->channels == NULL) {
-        monitor_printf(mon, "Channels: none\n");
+        monitor_hmp_printf(hmp, "Channels: none\n");
     } else {
         for (chan = info->channels; chan; chan = chan->next) {
-            monitor_printf(mon, "Channel:\n");
-            monitor_printf(mon, "     address: %s:%s%s\n",
-                           chan->value->host, chan->value->port,
-                           chan->value->tls ? " [tls]" : "");
-            monitor_printf(mon, "     session: %" PRId64 "\n",
-                           chan->value->connection_id);
-            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "\n",
-                           chan->value->channel_type, chan->value->channel_id);
+            monitor_hmp_printf(hmp, "Channel:\n");
+            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
+                               chan->value->host, chan->value->port,
+                               chan->value->tls ? " [tls]" : "");
+            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
+                               chan->value->connection_id);
+            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId64 "\n",
+                               chan->value->channel_type, chan->value->channel_id);
 
             channel_name = "unknown";
             if (chan->value->channel_type > 0 &&
@@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
                 channel_name = channel_names[chan->value->channel_type];
             }
 
-            monitor_printf(mon, "     channel name: %s\n", channel_name);
+            monitor_hmp_printf(hmp, "     channel name: %s\n", channel_name);
         }
     }
 
@@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
     monitor_hmp_read_command(opaque, 1);
 }
 
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp)
 {
@@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
         return;
     }
     if (!arg) {
-        MonitorHMP *hmp = MONITOR_HMP(mon);
         monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
@@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t key_length)
 
 void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *keys = qdict_get_str(qdict, "keys");
     KeyValue *v = NULL;
     KeyValueList *head = NULL, **tail = &head;
@@ -432,7 +427,7 @@ out:
     return;
 
 err_out:
-    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
+    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, keys);
     goto out;
 }
 
diff --git a/util/error-report.c b/util/error-report.c
index aa278de6646a..78ccb6ea608e 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -36,7 +36,7 @@ static int G_GNUC_PRINTF(2, 0)
 error_vprintf_mon(MonitorHMP *hmp, const char *fmt, va_list ap)
 {
     if (hmp) {
-        return monitor_vprintf(MONITOR(hmp), fmt, ap);
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
 
     return vfprintf(stderr, fmt, ap);
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 5d4143d425a1..5938f2b6c338 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -13,6 +13,7 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
+#include "qom/object.h"
 #include "qemu/qemu-print.h"
 
 /*
@@ -23,8 +24,13 @@
 int qemu_vprintf(const char *fmt, va_list ap)
 {
     Monitor *cur_mon = monitor_cur();
+
+    /* for all monitors: QMP & HMP */
     if (cur_mon) {
-        return monitor_vprintf(cur_mon, fmt, ap);
+        /* don't use monitor_cur_hmp(), to avoid a second lookup */
+        MonitorHMP *hmp = (MonitorHMP *)
+            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP);
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vprintf(fmt, ap);
 }
@@ -55,7 +61,8 @@ int qemu_printf(const char *fmt, ...)
 int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
 {
     if (!stream) {
-        return monitor_vprintf(monitor_cur(), fmt, ap);
+        MonitorHMP *hmp = monitor_cur_hmp();
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vfprintf(stream, fmt, ap);
 }

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Tue Aug 25 19:12:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Aug 2026 19:12:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399398.1635512 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZs-0000cD-JK; Tue, 25 Aug 2026 19:12:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399398.1635512; Tue, 25 Aug 2026 19:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wywZs-0000c6-GO; Tue, 25 Aug 2026 19:12:56 +0000
Received: by outflank-mailman (input) for mailman id 1399398;
 Tue, 25 Aug 2026 19:12:55 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wywZr-0000bT-QO
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 19:12:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wywZr-0069WB-7A
 for xen-devel@lists.xenproject.org; Tue, 25 Aug 2026 21:12:55 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de91e-e002-0a2a0a5209dd-0a2a450ab4bc-24
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:55 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a8de936-f2d2-0a2a450a0019-aa0a857c841f-3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:12:55 +0200
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-eR1SK0X7NtqLKSA6GRE-jQ-1; Tue,
 25 Aug 2026 15:12:50 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id CC4B41955F1F; Tue, 25 Aug 2026 19:12:47 +0000 (UTC)
Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.114])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 96F2B1955F0C; Tue, 25 Aug 2026 19:12:46 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787685173;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=S+aPoqqisu2J1a6Pr1LukLQArfAFqh3ZKUjQId9ja9Q=;
	b=GTDjEDY96iGN3Ih7joQsmUCbvbBOyrPCXesDqv/RBh503YU/Duh/aspOXNfbQrj3iBK2UC
	enUXPi+ahxeiKVlLyJEXqrxZUPjOLGu6ZqRtNkxDP0Zt9QYe82R2YXvwwT7KwhftkUwdJO
	3jzecdDdw+xBrFSIIls0gOOOKVug6aM=
X-MC-Unique: eR1SK0X7NtqLKSA6GRE-jQ-1
X-Mimecast-MFC-AGG-ID: eR1SK0X7NtqLKSA6GRE-jQ_1787685168
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Tue, 25 Aug 2026 23:09:49 +0400
Subject: [PATCH v4 42/49] hw: guard BusClass::print_dev with CONFIG_HMP
MIME-Version: 1.0
Message-Id: <20260825-qemu-no-hmp-v4-42-af60857c2fbe@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
In-Reply-To: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=9448;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=DXclgUj/8CLlvYxtSJ1BdyFBBPgVkYBaEJYVSnhsRxE=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqjeiIY3eGI48Kf0/aoiQ/MKgC5Wp2woFurnxxS
 F0lWsgFNX2JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCao3oiAAKCRDa6OEJdZac
 5WsND/wPl9/v92x/AquvMWdZ7rOg9DwenVSjQrgi/syQ0XPxEnuU+BHW+vlRlhR589DQBK2JWux
 whjt1aLkn4GALepRB5E0sb//roHo1ZL/q/NtTCm80KMl2DIzoYmHMRE9ti0jia4yXhEB+/5weh3
 duFyQM6L0T4VjWf5hCEXQObSK6tFNjpo5lHKh2221Olk/39vrXFGBZ09tkm8FEM9O4Tmw+mdRX/
 TdmN2/TPQh8IIqBG4IcNi7b+cSdn6jN03LH1RvlObtcX+EPfGmR7yUY5tqT/St87Q9wkK64jVH6
 Z5kUu/8yyyN9UBFJMb9WRHgqZxz6XPeyJLm1oGjuRndTjsa/yqey+0blEI82/jvIc2IVRSWoRRg
 NwUE48TuAh18Z/y/nRdL9EJezQidLYFunldTAf9esvGjqRfePHAGmUVA4sdzydMGSmlukuD3I27
 VfOTAYt4VNVzvz0ti0VZ3pJ/gTrQeUgaUygsEFts4ch3cGiUdeJNikOW8WRp2Udgp/KRyjyhAph
 AwHY9BCRwoYna9TwznrW18P8ZXhM5+rzu2VsuCYAvgC3tQnslsSut1QiLmA8FOmZBxrh7TpRP0b
 1Zej4GBAE74/uaZ+3jqzzvr/VXTr9u21Yxa+Zt0wQTcy+ymsoP3nG5p2waObhk1gXBP4xBVVBbU
 fsT43EF7iIos1fQ==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12
X-Mimecast-MFC-PROC-ID: 13JeL9OTXl5uVED9xyt1r2bsU1OEaPcaLrZlpCRir4o_1787685168
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787685175-583CCCFC-5991F728/0/0
X-purgate-type: clean
X-purgate-size: 9450

The print_dev callback is only used by HMP 'info qtree'. Guard the field
in BusClass, all implementations, and the caller with CONFIG_HMP.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/char/virtio-serial-bus.c |  6 ++++++
 hw/core/sysbus.c            |  6 ++++++
 hw/misc/auxbus.c            | 16 +++++++++++-----
 hw/pci/pci-hmp-cmds.c       |  2 ++
 hw/pci/pci.c                |  2 ++
 hw/usb/bus.c                |  6 ++++++
 hw/xen/xen-bus.c            |  4 ++++
 include/hw/core/qdev.h      |  2 ++
 8 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 4dcc4516e45e..83a033ce8555 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,9 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -823,8 +825,10 @@ static const Property virtser_props[] = {
 
 static void virtser_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
     k->print_dev = virtser_bus_dev_print;
+#endif
 }
 
 static const TypeInfo virtser_bus_info = {
@@ -834,6 +838,7 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
@@ -844,6 +849,7 @@ static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent
                        port->host_connected ? "on" : "off",
                        port->throttled ? "on" : "off");
 }
+#endif
 
 /* This function is only used if a port id is not provided by the user */
 static uint32_t find_free_port_id(VirtIOSerial *vser)
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 31c4fdf79d48..fe8f867a8d9c 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,9 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -76,7 +78,9 @@ static void system_bus_class_init(ObjectClass *klass, const void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = sysbus_dev_print;
+#endif
     k->get_fw_dev_path = sysbus_get_fw_dev_path;
 }
 
@@ -249,6 +253,7 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
@@ -261,6 +266,7 @@ static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            indent, "", s->mmio[i].addr, size);
     }
 }
+#endif
 
 static char *sysbus_get_fw_dev_path(DeviceState *dev)
 {
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 0bb89c5a60ab..3f17784d9b8a 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,18 +47,22 @@
 } while (0)
 
 
+#ifdef CONFIG_HMP
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
 static void aux_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
 
     /* AUXSlave has an MMIO so we need to change the way we print information
      * in monitor.
      */
     k->print_dev = aux_slave_dev_print;
+#endif
 }
 
 AUXBus *aux_bus_init(DeviceState *parent, const char *name)
@@ -91,11 +95,6 @@ void aux_map_slave(AUXSlave *aux_dev, hwaddr addr)
     memory_region_add_subregion(bus->aux_io, addr, aux_dev->mmio);
 }
 
-static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
-{
-    return (dev == DEVICE(bus->bridge));
-}
-
 I2CBus *aux_get_i2c_bus(AUXBus *bus)
 {
     return aux_bridge_get_i2c_bus(bus->bridge);
@@ -288,6 +287,12 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
+#ifdef CONFIG_HMP
+static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
+{
+    return (dev == DEVICE(bus->bridge));
+}
+
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
@@ -305,6 +310,7 @@ static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
 }
+#endif
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
 {
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index bcccfaf07f4d..879011da1384 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,6 +135,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
+#ifdef CONFIG_HMP
 void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     PCIDevice *d = (PCIDevice *)dev;
@@ -170,6 +171,7 @@ void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            r->addr, r->addr + r->size - 1);
     }
 }
+#endif
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d3191609e283..9e5db9529379 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -290,7 +290,9 @@ static void pci_bus_class_init(ObjectClass *klass, const void *data)
     ResettableClass *rc = RESETTABLE_CLASS(klass);
     FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = pcibus_dev_print;
+#endif
     k->get_dev_path = pcibus_get_dev_path;
     k->get_fw_dev_path = pcibus_get_fw_dev_path;
     k->realize = pci_bus_realize;
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 8bd25a9d872a..5cc5ffec33a1 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,9 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -32,7 +34,9 @@ static void usb_bus_class_init(ObjectClass *klass, const void *data)
     BusClass *k = BUS_CLASS(klass);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = usb_bus_dev_print;
+#endif
     k->get_dev_path = usb_get_dev_path;
     k->get_fw_dev_path = usb_get_fw_dev_path;
     hc->unplug = qdev_simple_device_unplug_cb;
@@ -544,6 +548,7 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     USBDevice *dev = USB_DEVICE(qdev);
@@ -555,6 +560,7 @@ static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
                        usb_speed(dev->speed), dev->product_desc,
                        dev->attached ? ", attached" : "");
 }
+#endif
 
 static char *usb_get_dev_path(DeviceState *qdev)
 {
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index b81a067e7753..1762816bf469 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,6 +101,7 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
+#ifdef CONFIG_HMP
 static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     XenDevice *xendev = XEN_DEVICE(dev);
@@ -108,6 +109,7 @@ static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
                        indent, "", xendev->name, xendev->frontend_id);
 }
+#endif
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
 {
@@ -386,7 +388,9 @@ static void xen_bus_class_init(ObjectClass *class, const void *data)
     BusClass *bus_class = BUS_CLASS(class);
     HotplugHandlerClass *hotplug_class = HOTPLUG_HANDLER_CLASS(class);
 
+#ifdef CONFIG_HMP
     bus_class->print_dev = xen_bus_print_dev;
+#endif
     bus_class->get_dev_path = xen_bus_get_dev_path;
     bus_class->realize = xen_bus_realize;
     bus_class->unrealize = xen_bus_unrealize;
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 1391dc060caf..f054a214fc6a 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -323,8 +323,10 @@ DECLARE_OBJ_CHECKERS(BusState, BusClass,
 struct BusClass {
     ObjectClass parent_class;
 
+#ifdef CONFIG_HMP
     /* FIXME first arg should be BusState */
     void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
+#endif
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 04:58:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 04:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399561.1635566 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iK-0004RT-Pp; Wed, 26 Aug 2026 04:58:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399561.1635566; Wed, 26 Aug 2026 04:58:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iK-0004RL-M0; Wed, 26 Aug 2026 04:58:16 +0000
Received: by outflank-mailman (input) for mailman id 1399561;
 Wed, 26 Aug 2026 04:58:15 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wz5iJ-0004Qy-KG
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 04:58:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz5iI-00758C-7i
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:58:14 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7247-e002-0a2a0a5209dd-0a2a450aa3fc-44
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:14 +0200
Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7266-f2d2-0a2a450a0019-d155d029f04b-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:14 +0200
Received: by mail-ed1-f41.google.com with SMTP id
 4fb4d7f45d1cf-69fc9f25118so508554a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:58:14 -0700 (PDT)
Received: from notebook.. ([88.230.44.160]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b43a0sm278781666b.52.2026.08.25.21.58.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 21:58:13 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787720294; x=1788325094; 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=7in3bnZnBsyVu6luHl4QWHPZitMbNPCAzBx2BqoAsCA=;
        b=eoGTwLymht+g5v/LFun8r9HWVMIo5a5fJb9JtOHiQha+hGNjp5QXbU9JRcb5SqtDN2
         8BQkPjfwBv2IHJr2JIDc6h2bnsv4hRoJIcuhpMLr7KPspLVLw58QtgEAKIrMhrz+i8R3
         qmHLfY1vTyaMXAhw7Z7cbUgs3Wh/E/haN3f7p95M9iI3uGGqguoYBRFhaGFegR74XVqm
         cSJsxVyBPMNjeKjGmHsbFDqP/zyX6XLpg+cxoxz5n7x6Yeq8g9KqagmvoN44bplRsdDk
         JKH8WfbGIiw8Zl72qOrB32246lXlzlhLHzYNRnpmuSfRu+mT20+iWfeq6p++3w7gEWFj
         02lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787720294; x=1788325094;
        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=7in3bnZnBsyVu6luHl4QWHPZitMbNPCAzBx2BqoAsCA=;
        b=U40MkrIb5xhj7t/YdOF49DNclK4X283RXUKh5zCKxMgerluNBELXthkBVj2dm9LAHA
         DYHqKfLdtmB+eaTozdYlzE8QrdHC1taHNJ0UnO3JtU0QeUM3UmWe9uvdXKCmAQIZeop6
         leOBQf+baiu3LukQ6AdS52jX2COIvK/TIXYvcEVrxcrp1eX3vIGzu4l1pJHuLcNV4jPE
         /jR1BRvXnI2AvcuZMJTW5/h+GQOTi8wvMECN1HmbiNlBLrB2j8yPCUbSNRPIDmHpDFcL
         V3BUeLpO0tVGNJEG3y1ulgC29hgQqwF3hmFUozTiLJ/yAMnKTHzx7/pseziH6hBrN+bj
         KRUQ==
X-Gm-Message-State: AFuF++lurlWSsXZA5DeL9bCUqDkme/lpLx5RLPpoSIcp4WQRQgmOmiYP
	sUDzo67qZrYv85rJ7hM14Gp8Vzsqb2SLklnMZzkCdoDLp9VKAL7hzAXZJvtv9A==
X-Gm-Gg: AR+sD11s3GhVpPYA/SSRA5bVAFvoCpf/DjbxQWETRC17rwZ59etL6r44AMrGhtJOJ5z
	zVHh+G9ov30n/Qi8ZTFuQ6VnF+syQePNqFQBvSf+c+npjzd7cWTiwOBP1g5dPmw72in/QatldEf
	7ae2D7ftSixZqMKNfXjc4Q0rQPsNVmXrnCyprdI41r1o4v8drrVCpEsvsSSnoYR4hQwVmRf7cvA
	SbyKeu42c/5Gsq6Mf75tXmnw/dTQFCsrOlpEDrZIT15VfqQVo0x6yYd5Xu1XhLKh8V61woN3Mgt
	eeR+c0dwjketmU/2ezTh512OPw3I/nekYloYvEjrYT/JU/wLVc7sX1ZA8oMAfniFzejYJagTgfm
	13gilavpV27Zn4Ll93hoXLM4JfroqANiXjphcQFVJJmeyvq5/WNQ29vIIN+qzvn1MpouWkXQo3K
	4VMNsBKBPCnNrLKlaLgOVRWjeqReZ6M80kwohbVubnj/SjKWlrYqSvfHoMfTPcxg==
X-Received: by 2002:a17:907:d08f:b0:c24:adf4:5c73 with SMTP id a640c23a62f3a-c250baf7e8amr492583166b.1.1787720293656;
        Tue, 25 Aug 2026 21:58:13 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	dfaggioli@suse.com,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	gwd@xenproject.org,
	enr0n@ubuntu.com,
	michal.orzel@amd.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control
Date: Wed, 26 Aug 2026 07:57:16 +0300
Message-Id: <20260826045720.5779-2-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260826045720.5779-1-frn1furkan10@gmail.com>
References: <20260826045720.5779-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787720294-5A3DCCFC-3BDAB81C/0/0
X-purgate-type: clean
X-purgate-size: 7027

RTDS has no admission control: nothing stops the sum of all admitted
units' (budget/period) reservations in a cpupool from exceeding
what its pCPUs can actually provide. Once that happens, none of the
EDF deadline guarantees this scheduler is built around still hold
for the units sharing that pool.

Introduce admission control to prevent this: reject a reservation
whenever admitting it would push a cpupool's units over its capacity.
Track a running utilization total per cpupool, and enforce it in
rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a
unit's creation and destruction. This catches the default
period/budget every new unit gets.

Utilization is represented as a fixed-point value: budget is
left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period.
A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing
the multiply for large enough budgets. Rather than widen the
arithmetic to tolerate any input, the input itself is bounded:
rt_validate_params() rejects any budget above RTDS_MAX_BUDGET,
chosen as the largest value that can be left-shifted by
RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in
rt_unit_utilization() can never overflow.

A cpupool's capacity rt_utilization_cap() scales with the number of
scheduling resources in it. It is calculated as:
(number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100),
where RTDS_UTIL_CAP_PCT controls how much of that capacity can
actually be reserved; at 100% (its current value), all of it can be.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/rt.c | 105 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 104 insertions(+), 1 deletion(-)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 0e9f04ea72..9126320801 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -114,6 +114,24 @@
  */
 #define RTDS_MAX_PRIORITY_LEVEL (~0U)
 
+/*
+ * Fixed-point scale for utilization (budget/period)
+ */
+#define RTDS_UTIL_SHIFT     20
+#define RTDS_UTIL_SCALE     (1ULL << RTDS_UTIL_SHIFT)
+
+/*
+ * Largest budget safe to left-shift by RTDS_UTIL_SHIFT without
+ * overflowing 64 bits. Enforced in rt_validate_params().
+ */
+#define RTDS_MAX_BUDGET_BITS  (64 - RTDS_UTIL_SHIFT)
+#define RTDS_MAX_BUDGET       ((1ULL << RTDS_MAX_BUDGET_BITS) - 1)
+
+/*
+ * % of a cpupool's sched_resource capacity admitted units may sum up to.
+ */
+#define RTDS_UTIL_CAP_PCT   100
+
 /*
  * UPDATE_LIMIT_SHIFT: a constant used in rt_update_deadline(). When finding
  * the next deadline, performing addition could be faster if the difference
@@ -195,6 +213,9 @@ struct rt_private {
     struct list_head replq;     /* ordered list of units that need replenishment */
 
     cpumask_t tickled;          /* cpus been tickled */
+
+    /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */
+    uint64_t utilization;
 };
 
 /*
@@ -635,6 +656,54 @@ replq_reinsert(const struct scheduler *ops, struct rt_unit *svc)
         set_timer(&rt_priv(ops)->repl_timer, rearm_svc->cur_deadline);
 }
 
+/*
+ * budget << RTDS_UTIL_SHIFT can't overflow: rt_validate_params()
+ * caps budget at RTDS_MAX_BUDGET. period == 0 means "no
+ * reservation" (a unit being removed), not an error.
+ */
+static uint64_t
+rt_unit_utilization(s_time_t period, s_time_t budget)
+{
+    if ( period <= 0 )
+        return 0;
+
+    return ((uint64_t)budget << RTDS_UTIL_SHIFT) / (uint64_t)period;
+}
+
+/*
+ * Utilization capacity of the cpupool domain d resides in.
+ */
+static uint64_t
+rt_utilization_cap(const struct domain *d)
+{
+    unsigned int cpus = cpumask_weight(cpupool_domain_master_cpumask(d));
+
+    return (uint64_t)cpus * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100;
+}
+
+/*
+ * Replaces a unit's reservation and updates prv->utilization
+ * to match. Growth that would push utilization over the
+ * cpupool's cap is refused. Removing a unit or shrinking
+ * a unit's reservation always succeed.
+ */
+static int
+rt_admission_test(struct rt_private *prv, const struct domain *d,
+		   s_time_t old_period, s_time_t old_budget,
+		   s_time_t new_period, s_time_t new_budget)
+{
+    uint64_t old_util = rt_unit_utilization(old_period, old_budget);
+    uint64_t new_util = rt_unit_utilization(new_period, new_budget);
+    uint64_t total    = prv->utilization - old_util + new_util;
+
+    if ( new_util > old_util && total > rt_utilization_cap(d) )
+        return -EINVAL;
+
+    prv->utilization = total;
+
+    return 0;
+}
+
 /*
  * Pick a valid resource for the unit vc
  * Valid resource of an unit is intesection of unit's affinity
@@ -864,6 +933,7 @@ rt_free_domdata(const struct scheduler *ops, void *data)
 static void * cf_check
 rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd)
 {
+    struct rt_private *prv = rt_priv(ops);
     struct rt_unit *svc;
 
     /* Allocate per-UNIT info */
@@ -881,9 +951,30 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd)
     __set_bit(__RTDS_extratime, &svc->flags);
     svc->priority_level = 0;
     svc->period = RTDS_DEFAULT_PERIOD;
+
     if ( !is_idle_unit(unit) )
+    {
+        unsigned long flags;
+        int rc;
+
         svc->budget = RTDS_DEFAULT_BUDGET;
 
+        spin_lock_irqsave(&prv->lock, flags);
+        rc = rt_admission_test(prv, unit->domain, 0, 0,
+                                svc->period, svc->budget);
+        spin_unlock_irqrestore(&prv->lock, flags);
+
+        if ( rc )
+        {
+            printk(XENLOG_WARNING
+                   "RTDS: ADMISSION CONTROL: refusing unit %u of d%d,"
+                   " would exceed utilization capacity of the cpupool\n",
+                   unit->unit_id, unit->domain->domain_id);
+            xfree(svc);
+            return NULL;
+        }
+    }
+
     SCHED_STAT_CRANK(unit_alloc);
 
     return svc;
@@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd)
 static void cf_check
 rt_free_udata(const struct scheduler *ops, void *priv)
 {
+    struct rt_private *prv = rt_priv(ops);
     struct rt_unit *svc = priv;
 
+    if ( svc && !is_idle_unit(svc->unit) )
+    {
+        unsigned long flags;
+
+        spin_lock_irqsave(&prv->lock, flags);
+        rt_admission_test(prv, svc->unit->domain,
+                           svc->period, svc->budget, 0, 0);
+        spin_unlock_irqrestore(&prv->lock, flags);
+    }
+
     xfree(svc);
 }
 
@@ -1389,7 +1491,8 @@ rt_validate_params(const struct xen_domctl_sched_rtds *rtds,
     s_time_t b = MICROSECS(rtds->budget);
 
     if ( p < RTDS_MIN_PERIOD || p > RTDS_MAX_PERIOD ||
-         b < RTDS_MIN_BUDGET || b > p )
+         b < RTDS_MIN_BUDGET || b > p ||
+         b > (s_time_t)RTDS_MAX_BUDGET )
         return -EINVAL;
 
     *period = p;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 04:58:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 04:58:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399560.1635557 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iD-0004Ec-Jq; Wed, 26 Aug 2026 04:58:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399560.1635557; Wed, 26 Aug 2026 04:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iD-0004EK-Eq; Wed, 26 Aug 2026 04:58:09 +0000
Received: by outflank-mailman (input) for mailman id 1399560;
 Wed, 26 Aug 2026 04:58:09 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wz5iC-0004EE-Un
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 04:58:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz5iC-004T7d-87
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:58:08 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7216-8faa-0a2a0a5109dd-0a2a45059ac2-42
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:08 +0200
Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7260-4cb1-0a2a45050019-d155da30a9ee-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:08 +0200
Received: by mail-ej1-f48.google.com with SMTP id
 a640c23a62f3a-c169ae1cb26so321175366b.1
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:58:08 -0700 (PDT)
Received: from notebook.. ([88.230.44.160]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b43a0sm278781666b.52.2026.08.25.21.58.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 21:58:07 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787720288; x=1788325088; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=v8auABwK2FVkoBZdhUexmZlVI3gSW8A7YBA8gzVO9pk=;
        b=X6bkHgPs/V1M6Zijbs6TVMvzU+0t8bNrFs1ShpbPBhbDBK6v3OeIBlUw0Sgah4NKAv
         hu9s7sBjyPsouho+2e9MJQQfuR6HEmN/P1K6AMpVl9J3y6OqsmvY2u+Vpuio3i6HmRrI
         eciO3J8J8M+sFlizikPmOB2QfLckBuNQCLusoxX73AvbWX9i1wvWWeI0rUBmh3mRN63X
         zzO+YM7yr5U774pL6yei5snQ9iIddPkQZpLd6sQ4k+ZotcrExICeSFjc/5aPwsO7Nfa3
         mcBnlD5vWdEUYFkm9nUvSHLDMlA9B8072RssC15FbZUZfNkV86wK1QAd9WmHsjUzlI5g
         KANQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787720288; x=1788325088;
        h=content-transfer-encoding:mime-version: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=v8auABwK2FVkoBZdhUexmZlVI3gSW8A7YBA8gzVO9pk=;
        b=YaPz0upNgp5YqxSD99Q30Ek71J4LKoJ2K/4Ug3Xg8d9Q0kn4+v3kO5dZfeWG4fUbp9
         pIKvICNlWnxoEj35XBXN1IOXeWhDhDAokWhFZ8SZYQWKqusal38jiwgP2488xlcnj8bk
         X+eqg50W17DIcwqxqx7CXhV3Us3T5c2p1kFZHm0i2esR/rJ6HqOiJE3/J43sDmIUUh5x
         2Gs0WBYBroq+sek85brT/6I0mF1hygiyd2eCbwDIHeJNVqhoN9hwfSoB+0149CncY9eB
         PyYbxIZYjaSkcvBhZJOyiBt0pyLp7GDC7t2YAbUetGXtXfNoI+5UAvghmzS5LOtZGmtQ
         weTQ==
X-Gm-Message-State: AFuF++lc+gvJvOniH6lWp2OU0r1VzKSZE8QDjmdPnqUbjqXiVBMvMH4Q
	3OkGqcWGSNtFLHJ1mGCrE2L7PWMJWkIvVDFgbE24Tx89p5M3WUTZAlyoGKf5Rg==
X-Gm-Gg: AR+sD10gYTQSxvJDd38O4Zq6DoFN8DEJAngPVkUDdGrqo8LV5uvgGx7hdJ061Ny2j0k
	i6qHwJABf4J2/v1JHp3D6b6YAqkWOfvNmmnISjY8d6pbVjE09fjZiP17hMgqRqgwHnlJxNUywe3
	TDDpmt7gU4iFSQWyK/GuhZyrG1RzzMjkubbalC8xbdFpLiwTHIR78a2q3ln2qNJ49KWlHy1/I2L
	xT7uHrgX7+00INYjnugfYgy72yBqLeGMWbizwqMh+nNXgj97H908PMtb8/ixNuJNLWyJyPGWp6D
	cD7xR6vOIWTcvc0LNDDydThxjzCUOPulL6cEIWFIB6EuvclmPcEvx6Q0ubYRmPqE6BEOGsjd6dM
	35x1V9f8sN+B69D3SPMWzR4WlMmxJByIUwxDmILnZO0M9CpX29DB0UP+i4Z0LEUN5xU3ebJQWdm
	jvFJLSbR5mkQTXg79bNl82HtKUpyknbOFpNWGVcg8vmDJdj7oqqR5sH4TEBVxz
X-Received: by 2002:a17:906:5147:20b0:c25:58e:8d64 with SMTP id a640c23a62f3a-c25058e9f37mr590370566b.12.1787720287647;
        Tue, 25 Aug 2026 21:58:07 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	dfaggioli@suse.com,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	gwd@xenproject.org,
	enr0n@ubuntu.com,
	michal.orzel@amd.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 0/5] xen/sched: rtds: add per-cpupool admission control
Date: Wed, 26 Aug 2026 07:57:15 +0300
Message-Id: <20260826045720.5779-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787720288-730B22A1-A698D853/0/0
X-purgate-type: clean
X-purgate-size: 2236

RTDS currently has no admission control: nothing stops the sum of
all admitted units' (budget/period) reservations in a cpupool from
exceeding what its pCPUs can actually provide. Once that happens,
the global-EDF deadline guarantees the scheduler is built around no
longer hold for any unit sharing that pool.

This series adds admission control to prevent that, tracks and
report utilization, and makes the check toggleable per cpupool so
an operator can disable it if they intentionally want to overcommit.

Patch 1 introduces the core mechanism: a running utilization total
per cpupool, a fixed-point representation of a unit's (budget/period),
and a capacity check enforced in rt_alloc_udata()/rt_free_udata() -
the lifecycle hooks that catch every new unit's default reservation.

Patch 2 extends the same check to domctl, so growing an existing
reservation via xl sched-rtds is checked too.

Patch 3 reports a cpupool's admitted utilization agains its capacity
via the 'r' debug key.

Patch 4 makes admission control itself toggleable per cpupool
(enabled by default) via sysctl.

Patch 5 wires that toggle through libxl and adds -s/-a to
xl sched-rtds, and documents it.

Furkan Caliskan (5):
  xen/sched: rtds: add global-EDF utilization admission control
  xen/sched: rtds: enforce admission control in xl sched-rtds
  xen/sched: rtds: report utilization and cap via debug key
  xen/sched: rtds: make admission control cpupool-wide toggleable
  tools: expose admission control toggle via xl sched-rtds

 docs/man/xl.1.pod.in                 |  20 +++
 tools/golang/xenlight/helpers.gen.go |  23 +++
 tools/golang/xenlight/types.gen.go   |   4 +
 tools/include/libxl.h                |   4 +
 tools/include/xenctrl.h              |   6 +
 tools/libs/ctrl/xc_rt.c              |  40 ++++++
 tools/libs/light/libxl_sched.c       |  46 ++++++
 tools/libs/light/libxl_types.idl     |   5 +
 tools/xl/xl_cmdtable.c               |   8 +-
 tools/xl/xl_sched.c                  | 103 +++++++++++++-
 xen/common/sched/rt.c                | 205 ++++++++++++++++++++++++++-
 xen/include/public/sysctl.h          |   5 +
 12 files changed, 463 insertions(+), 6 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 04:58:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 04:58:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399564.1635576 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iT-0004iw-4W; Wed, 26 Aug 2026 04:58:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399564.1635576; Wed, 26 Aug 2026 04:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iT-0004in-0C; Wed, 26 Aug 2026 04:58:25 +0000
Received: by outflank-mailman (input) for mailman id 1399564;
 Wed, 26 Aug 2026 04:58:23 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wz5iR-0004hi-No
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 04:58:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz5iR-00758C-4a
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:58:23 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e725f-e002-0a2a0a5209dd-0a2a450bdaf6-14
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:23 +0200
Received: from [209.85.208.43] (helo=mail-ed1-f43.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e726e-b7e8-0a2a450b0019-d155d02bd0cf-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:23 +0200
Received: by mail-ed1-f43.google.com with SMTP id
 4fb4d7f45d1cf-6a1542cdb53so536379a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:58:23 -0700 (PDT)
Received: from notebook.. ([88.230.44.160]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b43a0sm278781666b.52.2026.08.25.21.58.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 21:58:22 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787720302; x=1788325102; 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=hmp+WJMlrY3UcNmiM1sdN0nUxrpak314iM4OXbwb3nk=;
        b=hveCGDcj7mvrKOKVTeoqQx6bS+Ff2Iri2qf+c4WElaGQJw4hLZPxV79J5uVpUYqwrw
         +XyWr682bYGqI9DUWcDqyP7v75merarD4l5xVd/v+sMcwfz8REdzNz/xJFhEl30wQwL/
         RNwut8sZTztFN7aKgLC2vQUuE4fmXd9iv6u/+cpUiTwHxmLfO+cJ0KVNJ5d4RuZZsXo6
         uzqxe8XvrHgU2yqQqdQ1Iqu8aDK52zp5pdlGOGx/mLt7TbwHE/BJvigBuw5p4Pgr61Si
         J3lnWqzJWZQ7BRx2KDdF9tD7NbeMexmh9OPA8rgXq2yXZy0uVsGc6qrxLvs6zz0QHJWT
         sHHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787720302; x=1788325102;
        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=hmp+WJMlrY3UcNmiM1sdN0nUxrpak314iM4OXbwb3nk=;
        b=aEogs4N+OrEh7MFayt1V8NFfzxrvHUmiJ8/mNFPNaiLbx/D1YfVODRpUG2Pbo0Oqsj
         NkQCi7POXV79YLsuFm8jt/XBulraB5vBPTvZCX5jwEdN7uTJB/NFAt1zuUUgp8diwMFk
         HBprxO+MptmH3zJ5TuKm3rLDq/bVbtF8MJ2YBEPBHwdQRy80cVHIaZA+wY6SjCx0ezN/
         EdYEmG2+Ovw7G1aiPnfbaefBAZHKn0zj9G5d2/0VwwCWGLOg+cvjD61qHOpP41BKyC+x
         xQvkFZVsEUDleKrVHa8XY9kRzeoMTKqMOyV8MgZV2kMyAJYeu5tCzO/shUh4hGXvmyIX
         31SA==
X-Gm-Message-State: AFuF++l5iA7T0EHiKMRstoF1SWZixAnaE2EmC2FNMGTSJOComsPeeb34
	hchss9ZrNPwLx/R7LbfNJxHddbNjny80nXCNDJPnX+1h+6VjhiZz6PPVLRgbuQ==
X-Gm-Gg: AR+sD11Yj/B5nWlTGzW2KHmV/0vSHfclmucvLqEGHTIm6rfjqm+eefpeK1ceTS2+0pT
	7lLgzCpn5WgezSc/yyepzJkgkjqsj4WFn+nq1FXdmv2L44rvRUNga99mEIwn3aH+Dob9Inm3X83
	kgxoErHoIC0PRYMcXPr664rBr2/4puZNc01qKuqOQZ/w24osDiyXXgR34Q987LDyNttDdb7aNRp
	iV24AH1vJu9rp5NBmcGEyd1cYqxhlVAuS5Awf+d7UMMleLYl/NK2FnVx/bMn+ePOkqLv4h+pNXJ
	Ik0w6pQWcQOA3XnD9lYFJp+KlBe82hSx1g2ihATJblB72yIFGkpjIPmHtaegnT7Z/tYG5D5mAMC
	+YtFof1pQC5Fcka0SGjTqD5pUGkadfvQolByzLozbKDtx0rM3hlKiZYNCTt8h2te79evNWr2/Xb
	wMRhta0RssmkYAKeiQJB9ed1S89q1SKPgmEXn1u3PQN3MMdh12ocqpO4cK2gLG
X-Received: by 2002:a17:906:9fce:b0:c1f:1520:4de5 with SMTP id a640c23a62f3a-c250bb50762mr467606766b.1.1787720302595;
        Tue, 25 Aug 2026 21:58:22 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	dfaggioli@suse.com,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	gwd@xenproject.org,
	enr0n@ubuntu.com,
	michal.orzel@amd.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds
Date: Wed, 26 Aug 2026 07:57:17 +0300
Message-Id: <20260826045720.5779-3-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260826045720.5779-1-frn1furkan10@gmail.com>
References: <20260826045720.5779-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787720303-190CD9EA-E23DD40F/0/0
X-purgate-type: clean
X-purgate-size: 3238

Now that we have introduced admission control for new and
removed units. Extend it to XEN_DOMCTL_SCHEDOP_putinfo and
putvcpuinfo, so growing an existing reservation via
xl sched-rtds is checked too.

putinfo sets the same (period, budget) for every unit of a
domain at once, so it tests the whole domain's utilization
delta atomically, rather than unit-by-unit, which could
spuriously reject an overall-acceptable change depending on
iteration order.

putvcpuinfo changes one unit at a time, so it just calls
rt_admission_test() directly.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/rt.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 9126320801..9643a277fe 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1527,11 +1527,43 @@ rt_dom_cntl(
         op->u.rtds.budget = RTDS_DEFAULT_BUDGET / MICROSECS(1);
         break;
     case XEN_DOMCTL_SCHEDOP_putinfo:
+    {
+        uint64_t dom_old_util = 0, new_util, new_total;
+        unsigned int nr_units = 0;
+
         rc = rt_validate_params(&op->u.rtds, &period, &budget);
         if ( rc )
             break;
 
+        new_util = rt_unit_utilization(period, budget);
+
         spin_lock_irqsave(&prv->lock, flags);
+
+        /*
+         * Same (period, budget) for every unit of d: test and commit
+         * the domain's whole utilization delta atomically, rather
+         * than unit-by-unit, which could spuriously reject an
+         * overall-acceptable change depending on iteration order.
+         */
+        for_each_sched_unit ( d, unit )
+        {
+            svc = rt_unit(unit);
+            dom_old_util += rt_unit_utilization(svc->period, svc->budget);
+            nr_units++;
+        }
+
+        new_total = prv->utilization - dom_old_util +
+                    (uint64_t)nr_units * new_util;
+
+        if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) )
+        {
+            rc = -EINVAL;
+            spin_unlock_irqrestore(&prv->lock, flags);
+            break;
+        }
+
+        prv->utilization = new_total;
+
         for_each_sched_unit ( d, unit )
         {
             svc = rt_unit(unit);
@@ -1540,6 +1572,7 @@ rt_dom_cntl(
         }
         spin_unlock_irqrestore(&prv->lock, flags);
         break;
+    }
     case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
     case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
         while ( index < op->u.v.nr_vcpus )
@@ -1584,6 +1617,15 @@ rt_dom_cntl(
 
                 spin_lock_irqsave(&prv->lock, flags);
                 svc = rt_unit(d->vcpu[local_sched.vcpuid]->sched_unit);
+
+                rc = rt_admission_test(prv, d, svc->period, svc->budget,
+                                        period, budget);
+                if ( rc )
+                {
+                    spin_unlock_irqrestore(&prv->lock, flags);
+                    break;
+                }
+
                 svc->period = period;
                 svc->budget = budget;
                 if ( local_sched.u.rtds.flags & XEN_DOMCTL_SCHEDRT_extra )
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 04:58:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 04:58:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399565.1635584 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iY-0004zU-BX; Wed, 26 Aug 2026 04:58:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399565.1635584; Wed, 26 Aug 2026 04:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5iY-0004zN-7U; Wed, 26 Aug 2026 04:58:30 +0000
Received: by outflank-mailman (input) for mailman id 1399565;
 Wed, 26 Aug 2026 04:58:28 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wz5iW-0004xc-HW
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 04:58:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz5iV-004T7d-FY
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:58:27 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7272-8faa-0a2a0a5109dd-0a2a4509d3da-2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:27 +0200
Received: from [209.85.218.49] (helo=mail-ej1-f49.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7273-be1a-0a2a45090019-d155da31dc31-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:27 +0200
Received: by mail-ej1-f49.google.com with SMTP id
 a640c23a62f3a-c250c6a6a6eso78960966b.0
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:58:27 -0700 (PDT)
Received: from notebook.. ([88.230.44.160]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b43a0sm278781666b.52.2026.08.25.21.58.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 21:58:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787720307; x=1788325107; 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=TQK6s/nICmBYwEM1TUDiv/Axq0E/+KEAZYQp/00aSKg=;
        b=Afzdwf7rtune7IktrggN56ozLtFp69ledyu0hTVhrm0ReVE0o+jTOUYblRpsy45GPs
         8EfW0hHvXtbZXsJW0Zmv2jfqA+JnZ1Od2zbpobYpp6KKbIQrLiEmVTMt7RwDwCcgWZ0x
         g2P9XA/ifVlkxE695ekQ+xYkXT6pkI17QitHgDyASyFGqhk4sdwkiEO/E1crWAmzYM3m
         PcvzO47VtlHQvSVSVhVL73hAfQ8uI4hCKmZCVJFluMRWiAQTXU6Gx6wyGnq9sFxxiOKV
         tBSdT9KJu8vxmr8wxIGAU/z6z78WXLk0OVJdFRMoCNkbjBVADZfO7Kcwt9lDqmutZD40
         tbKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787720307; x=1788325107;
        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=TQK6s/nICmBYwEM1TUDiv/Axq0E/+KEAZYQp/00aSKg=;
        b=mCxSePc5nSzxL+sPTbzjaj4yT6mtX5zc9M4YjmTdl6CrYven1IZ7AGKRYYhJymmIm9
         bTd0BojS/ZVejbNB0HQ2vo40rGkJvnydAhx+NcQIClkDL/7fJE93N4vCR+IsKSEuayu/
         nj70vXm9fCesgI4jP0RJIgi0Lhx3xnAk157v8plUD3FP8bufeuQ99hvQnN0hKC/+rp12
         6J2OgVMwUA/L7i/QocjmZSXkNPp4Y0CsNDhus0APbUYQUyKcrKt2scHUVbJfX7NrhDny
         mmEO03YRuwVN5wVz2tSlI7pmbvUyPrX/EYlVrEAOWEKO97b840Me+zhBO5kP8uMgsz5G
         Y/hw==
X-Gm-Message-State: AFuF++nXuoQclnnwcuIY1wmvNTQFClVE/f6m2Gxn9QcerD1InrTu7sHz
	XpohHa3DnospnD96MLRnRE/1C9CMZV9s488TElMJov9wavXNrct5hMWMb5vpBg==
X-Gm-Gg: AR+sD12h7fDzh3Z2X6dLiDh2wv1UD0e3xP/Ise4go3+vveVekZCylOFm67kwIBM4Ua7
	5KF9Zihwa5mfHvfHSRIPmv66uzIrHv54wb000lGObc9ES9f8BEsSzs52dU+tWpL3j16V77r4yl4
	x5RYoABZ/GQQSG3QK17lZTXhjIbDlMZcrvRkow65RvQ6KIeXBM8amD9k1tvTYsCtHJ91dfEe2Oi
	YBtZEW12OvhlVxT2bp+Pt7yq7SaWIOjYsXLej9PCGEVyCilS4XQVU/4WyZrIyUdcaqVNMAtrl9G
	KUWE6TdHRCP58y61Y6VPsiImpyvxuSEJ2/nUxXdHeIzTHJCTrduzxuSnwl/jGaERRIlH2W7vPku
	kifFL0PkE+K3I6AZwXUa54kPat+ZoLNow+FAP2thFeSAwTW5Wl5TEAjAZ5eXnfU8tIdMOE2mKbE
	qNWPQsvlrd3LjV/so52YnJmqUs9Hp3yHImiQJDn8EFYiOz5s4BKtfWEEhZNco6
X-Received: by 2002:a17:907:94cb:b0:c20:f913:9337 with SMTP id a640c23a62f3a-c250c30cdddmr394534166b.20.1787720306723;
        Tue, 25 Aug 2026 21:58:26 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	dfaggioli@suse.com,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	gwd@xenproject.org,
	enr0n@ubuntu.com,
	michal.orzel@amd.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 3/5] xen/sched: rtds: report utilization and cap via debug key
Date: Wed, 26 Aug 2026 07:57:18 +0300
Message-Id: <20260826045720.5779-4-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260826045720.5779-1-frn1furkan10@gmail.com>
References: <20260826045720.5779-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787720307-BD8C1034-75BD8437/0/0
X-purgate-type: clean
X-purgate-size: 1178

Print a cpupool's admitted utilization against its capacity in the
'r' debug ky (xl debug-keys r), so an operator can see the total
usage of a cpupool.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/rt.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 9643a277fe..0582c0094d 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -399,12 +399,22 @@ rt_dump(const struct scheduler *ops)
     const struct rt_unit *svc;
     const struct rt_dom *sdom;
     unsigned long flags;
+    uint64_t cap;
 
     spin_lock_irqsave(&prv->lock, flags);
 
     if ( list_empty(&prv->sdom) )
         goto out;
 
+    cap = (uint64_t)cpumask_weight(ops->cpupool->res_valid) *
+          RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100;
+
+    if ( cap )
+        printk("Utilization: %llu%% of capacity\n",
+               (unsigned long long)(prv->utilization * 100 / cap));
+    else
+        printk("Utilization: cpupool has no capacity\n");
+
     runq = rt_runq(ops);
     depletedq = rt_depletedq(ops);
     replq = rt_replq(ops);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 04:58:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 04:58:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399567.1635594 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5ic-0005M2-IB; Wed, 26 Aug 2026 04:58:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399567.1635594; Wed, 26 Aug 2026 04:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5ic-0005Lv-Dv; Wed, 26 Aug 2026 04:58:34 +0000
Received: by outflank-mailman (input) for mailman id 1399567;
 Wed, 26 Aug 2026 04:58:32 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wz5ia-0005Ga-Ob
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 04:58:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz5ia-006gp8-5P
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:58:32 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e726a-2eae-0a2a0a5409dd-0a2a450acf9c-14
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:32 +0200
Received: from [209.85.218.45] (helo=mail-ej1-f45.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e7278-f2d2-0a2a450a0019-d155da2dad13-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:32 +0200
Received: by mail-ej1-f45.google.com with SMTP id
 a640c23a62f3a-c250c6a6a9aso50214966b.1
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:58:32 -0700 (PDT)
Received: from notebook.. ([88.230.44.160]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b43a0sm278781666b.52.2026.08.25.21.58.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 21:58:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787720311; x=1788325111; 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=IoJGB6t5A5yVoQBOIDHzvIHt2FzWFgHAlTPuWE7dzHM=;
        b=RhrFIf51Ymw/lrj5LwkqCSd5HO6pt4REofbWHiY3pu9crS2n0UwXkx8c5cqkV811ET
         u0+Lu7zEEwW4xIJdA7Jz1EbCShYKxIxDrN5PyrxHH10jkZyATY9l/rzxfZxqM9Igv6Qu
         sC0EM5KvxPuVx7geZDZB/n/no6AM7aMGyPFKGk/1SOSqa9IUTjC6aaJX3UlBJJT1YKrT
         UiW423v4h4/cHeWZWYF5JIJUw3/rVJazXFETnrXY6TYly4C76W2jBPIJOogYii9/EIIX
         CDVPi93clnVLSpOT36IR6uhoUGs7MSg+FFC8A8yxJ1t+gI4Bp49Wr6T8We0h6OGi0VKB
         oHEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787720311; x=1788325111;
        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=IoJGB6t5A5yVoQBOIDHzvIHt2FzWFgHAlTPuWE7dzHM=;
        b=A7NDK674FdYjiAorHap0rTGB7dlsIUK/WvkTWRr+X8J6ngFaY/OZqKsPDMKd+79Psy
         TSM68Slf5oh6MPWnDTvxRCUoQzdf6EjxaOVZRemQXICwhj2iAKTB6rDkugyftiGy9n7H
         Z4dviOw7IBwvnZbGk+bXRXoWmRs2+E7MR6bjcUSyXLKxyFsASwN6V6+15HsWx5v8w6kl
         OtE3hwEiUl7sXKk/yRxIAXy2WowAByD4Bb5Hv6A9oE3MgclLOcoJrdvrMD9AsTkgS1bR
         3iSHGrMqfmLlHjoH9ZaP/hOZwth3P4Vf32oK+rGGe5Ki0uyX9pyI6fRNrSZswVauQeYt
         /sBQ==
X-Gm-Message-State: AFuF++nzJjRLDssXJK1vm/ICsuFdfPe/AKvwxFIQJ3U9sHhcrcYQtpJ9
	uNOPf1onPgXATZODXLOvFlhY6t65jN0ph1ucHmNoEnR/zvTR/Nd4RcOeeuSJRg==
X-Gm-Gg: AR+sD11yKTd7d0+lz3MDeP240dC4FOWhwQ9xh6dZ2SIuN8pRFN617qVI8XPZBa+RjKL
	XX9vo1KusmXjnVY+/rhh5EJ+cg5YaAx2OzN6t0VU1hWgyrNsG/ZzT6z0vQiVrefLwLky4rP8dT6
	JuPTq/IKcUlhWt2j67CY54ZHgnCOk9cgP+5v2Q981hVP0g0Ci/HsEm1VcIx2iEIFM8CctPGLGfy
	wuVFV4unjyKPw1n7VscRfGIfrvD8YuU75aNJ7m/ySamyKZIhFEiunlcWPTFjx9j64rvIeQJFFZM
	tpgIAqyafqBii6A0FC1BC+n6KT0IwTiHbuyC2nVFNy7Bb5lWuBgyDZQcZOoCqLdraqZmW0dSspH
	NDrhdOmJQI8VvDNqSN7xIyQePcqiUtOMnY0cIONswY89iKrvsZvy8O8CvnigHLuahKA8+AlgLh7
	+xj/cyi9cpbPxw2BUOY5t7ENbP1TcqJuXStb+p5blJoJzNVyj7qj4L/PIq4zSdVw==
X-Received: by 2002:a17:907:c08c:b0:c21:752f:c44e with SMTP id a640c23a62f3a-c250bc0f7e6mr524107766b.16.1787720311567;
        Tue, 25 Aug 2026 21:58:31 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	dfaggioli@suse.com,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	gwd@xenproject.org,
	enr0n@ubuntu.com,
	michal.orzel@amd.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable
Date: Wed, 26 Aug 2026 07:57:19 +0300
Message-Id: <20260826045720.5779-5-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260826045720.5779-1-frn1furkan10@gmail.com>
References: <20260826045720.5779-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787720312-520C1CFC-EA64CAE0/0/0
X-purgate-type: clean
X-purgate-size: 5736

Add a per-cpupool on/off switch for RTDS admission control via
XEN_SYSCTL_scheduler_op, enabled by default, so an operator can
disable/enable enforcement for a pool.

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 xen/common/sched/rt.c       | 56 ++++++++++++++++++++++++++++++++++---
 xen/include/public/sysctl.h |  5 ++++
 2 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 0582c0094d..b150f84242 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -216,6 +216,8 @@ struct rt_private {
 
     /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */
     uint64_t utilization;
+
+    bool admission_control_enabled; /* on/off flag for admission control. */
 };
 
 /*
@@ -409,6 +411,9 @@ rt_dump(const struct scheduler *ops)
     cap = (uint64_t)cpumask_weight(ops->cpupool->res_valid) *
           RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100;
 
+    printk("Admission control: %s\n",
+            prv->admission_control_enabled ? "enabled" : "disabled");
+
     if ( cap )
         printk("Utilization: %llu%% of capacity\n",
                (unsigned long long)(prv->utilization * 100 / cap));
@@ -694,8 +699,8 @@ rt_utilization_cap(const struct domain *d)
 /*
  * Replaces a unit's reservation and updates prv->utilization
  * to match. Growth that would push utilization over the
- * cpupool's cap is refused. Removing a unit or shrinking
- * a unit's reservation always succeed.
+ * cpupool's cap is refused if admission control is enabled.
+ * Removing a unit or shrinking a unit's reservation always succeed.
  */
 static int
 rt_admission_test(struct rt_private *prv, const struct domain *d,
@@ -706,7 +711,8 @@ rt_admission_test(struct rt_private *prv, const struct domain *d,
     uint64_t new_util = rt_unit_utilization(new_period, new_budget);
     uint64_t total    = prv->utilization - old_util + new_util;
 
-    if ( new_util > old_util && total > rt_utilization_cap(d) )
+    if ( prv->admission_control_enabled &&
+         new_util > old_util && total > rt_utilization_cap(d) )
         return -EINVAL;
 
     prv->utilization = total;
@@ -773,6 +779,7 @@ rt_init(struct scheduler *ops)
     INIT_LIST_HEAD(&prv->runq);
     INIT_LIST_HEAD(&prv->depletedq);
     INIT_LIST_HEAD(&prv->replq);
+    prv->admission_control_enabled = true;
 
     ops->sched_data = prv;
     rc = 0;
@@ -1565,8 +1572,14 @@ rt_dom_cntl(
         new_total = prv->utilization - dom_old_util +
                     (uint64_t)nr_units * new_util;
 
-        if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) )
+        if ( prv->admission_control_enabled &&
+             new_total > prv->utilization && new_total > rt_utilization_cap(d) )
         {
+            printk(XENLOG_WARNING
+                   "RTDS: ADMISSION CONTROL: refusing d%d,"
+                   " would exceed utilization capacity of the cpupool\n",
+                   d->domain_id);
+
             rc = -EINVAL;
             spin_unlock_irqrestore(&prv->lock, flags);
             break;
@@ -1632,6 +1645,11 @@ rt_dom_cntl(
                                         period, budget);
                 if ( rc )
                 {
+                    printk(XENLOG_WARNING
+                           "RTDS: ADMISSION CONTROL: refusing vcpu %u of d%d,"
+                           " would exceed utilization capacity of the cpupool\n",
+                           local_sched.vcpuid, d->domain_id);
+
                     spin_unlock_irqrestore(&prv->lock, flags);
                     break;
                 }
@@ -1691,6 +1709,33 @@ rt_dom_cntl(
     return rc;
 }
 
+#ifdef CONFIG_SYSCTL
+static int cf_check
+rt_sys_cntl(const struct scheduler *ops,
+             struct xen_sysctl_scheduler_op *sc)
+{
+    struct xen_sysctl_rtds_schedule *params = &sc->u.sched_rtds;
+    struct rt_private *prv = rt_priv(ops);
+    unsigned long flags;
+
+    switch ( sc->cmd )
+    {
+    case XEN_SYSCTL_SCHEDOP_putinfo:
+        spin_lock_irqsave(&prv->lock, flags);
+        prv->admission_control_enabled = params->admission_control_enabled;
+        spin_unlock_irqrestore(&prv->lock, flags);
+        break;
+    case XEN_SYSCTL_SCHEDOP_getinfo:
+        spin_lock_irqsave(&prv->lock, flags);
+        params->admission_control_enabled = prv->admission_control_enabled;
+        spin_unlock_irqrestore(&prv->lock, flags);
+        break;
+    }
+
+    return 0;
+}
+#endif
+
 /*
  * The replenishment timer handler picks units
  * from the replq and does the actual replenishment.
@@ -1791,6 +1836,9 @@ static const struct sched_ops sched_rtds_def = {
     .remove_unit    = rt_unit_remove,
 
     .adjust         = rt_dom_cntl,
+#ifdef CONFIG_SYSCTL
+    .adjust_global  = rt_sys_cntl,
+#endif
 
     .pick_resource  = rt_res_pick,
     .do_schedule    = rt_schedule,
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index c7cd9b4eb0..f1bf3293e3 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -814,6 +814,10 @@ struct xen_sysctl_credit2_schedule {
     uint32_t ratelimit_us;
 };
 
+struct xen_sysctl_rtds_schedule {
+    bool admission_control_enabled;
+};
+
 /* XEN_SYSCTL_scheduler_op */
 /* Set or get info? */
 #define XEN_SYSCTL_SCHEDOP_putinfo 0
@@ -828,6 +832,7 @@ struct xen_sysctl_scheduler_op {
         } sched_arinc653;
         struct xen_sysctl_credit_schedule sched_credit;
         struct xen_sysctl_credit2_schedule sched_credit2;
+        struct xen_sysctl_rtds_schedule sched_rtds;
     } u;
 };
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 04:58:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 04:58:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399572.1635603 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5ih-0005fi-Pq; Wed, 26 Aug 2026 04:58:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399572.1635603; Wed, 26 Aug 2026 04:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz5ih-0005fY-Kt; Wed, 26 Aug 2026 04:58:39 +0000
Received: by outflank-mailman (input) for mailman id 1399572;
 Wed, 26 Aug 2026 04:58:38 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wz5ig-0005dV-16
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 04:58:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz5if-00758C-EF
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:58:37 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e725f-e002-0a2a0a5209dd-0a2a450bdaf6-24
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:37 +0200
Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a8e727d-b7e8-0a2a450b0019-d155da2ff019-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:58:37 +0200
Received: by mail-ej1-f47.google.com with SMTP id
 a640c23a62f3a-c250a2bc3b3so58361166b.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 21:58:37 -0700 (PDT)
Received: from notebook.. ([88.230.44.160]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b43a0sm278781666b.52.2026.08.25.21.58.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 25 Aug 2026 21:58:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787720317; x=1788325117; 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=FHRsXuEnf7BCXLP3eamT1pJU7X7xpT0JlychFCHzOuM=;
        b=iVPKiUlRX8AAxHG1yp5yA9fUy0Zkw02z6k7Xx6Tf38C3C3DqB+/c/zIp4HkAqSKZC5
         pLVV7Fnwujmaui/HZ1fNZzGLyox6O1Pj3DcNRSE3ylqBOPGODAwZbiFvDJS+OOelPHUS
         h7i3JMa2Zz4Zy8o0Z3WsI4BneZB3trsLQCfVNrTMiv6WsA4HS2eN6+84AJuNxOw94WtM
         yLzNUwd7uQLEbfNIEQA58fBh9ZaOnIUye6WCpxtIjImkB6EJw+F3AeE42xW3eVWg8MH3
         CKPW7a3SuIAYFBFHXwr0Vs/27J2i4uAbURSMuSHugW/5Zb1aqRqxvKqGMSPrrYmcAXxK
         azWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787720317; x=1788325117;
        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=FHRsXuEnf7BCXLP3eamT1pJU7X7xpT0JlychFCHzOuM=;
        b=MvFQ1EiIL7eAEKaIfiSqJ5rd/GjOFeDW+cZ5+rSiAgd8JFJ8UDWgkcPy2P3bNrbItT
         UlDDuPtNzJY6LMhy53qcSxOIlr1iQTJgTug9O8S5PTbKR7WMzx9Kjx0btY+iDDSzQ2GW
         iGeTfiUJR5/qg8Hrt9och1s9AovnM0W8FkzXZS2jUpZk0PhIZV6W+WCZqKjE/16DlmJk
         +AmH6aaE+R5WDfkG1BFxLumkic3r+tAHx9A2qZPdfUcrn8O6B7wgia5mQSzFS0Wi8X1x
         c8qJ/xQDtqkBAfGUh6nP8du4KE+ncAHpMFjYJGwFvETLWUk2fU1WDK3Ej4OngEH14eYb
         q1xw==
X-Gm-Message-State: AFuF++lLlqPih7HAx6iIRWE6JQNRw2CHry3y2cjqjTjL0UFmlg+uCLEi
	nO4C5in7KFAEgHw33GIqHeH11NdqfxbGEu+bMKkLoezSO1wyWrhYScgh8eXzGg==
X-Gm-Gg: AR+sD10ufEkf79cFAnJmafVVlwHGSJKtwwoZ7kVJdxJwSMBXYLzn1GXPqDOQ0UCsWyh
	QxktJMzcGxo3uUEtam/wvn6k+RoW71rWQ1N0in4MA5Sk8B/79r8An7tIMaNfEU1QSqPkYxrGrq4
	cbn5l30JGVi7LPpubZAmUb563Huo+YmZFIB//mZw9jNeu5iPQEezA1LGfRa5iTPVO2Luu+f/XZ1
	3xftOjAgQcu7DuCcHus+PiHmmnjftNnQ3XGEksKgXgGJw4WVZ2CZzwP1jVjxOxB+JoVXCTKAqPr
	5DofZFurzvVvZLbt3lQk+3SkEyOeXwX4fXN9bu74UVlaFDt6PQT8pBb54ASuWpZPAO8JBPM0SDv
	F2tx4mvZTUaYxKf7TSn5/AqAFwEnCatAt/9Q9ydrddklVvufMyS5YTMk8jZut8d/me4j2uk5ggp
	y4s+swAptOyxG85OnLR7WjLFs1iH/7j3ibIXuRW67v0E82Ii6UKQnHF3/nyEPJ
X-Received: by 2002:a17:906:ba83:b0:c25:544:3aec with SMTP id a640c23a62f3a-c250baf9b5amr516177966b.5.1787720316767;
        Tue, 25 Aug 2026 21:58:36 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	roger@xenproject.org,
	dfaggioli@suse.com,
	anthony.perard@vates.tech,
	julien@xen.org,
	sstabellini@kernel.org,
	gwd@xenproject.org,
	enr0n@ubuntu.com,
	michal.orzel@amd.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH 5/5] tools: expose admission control toggle via xl sched-rtds
Date: Wed, 26 Aug 2026 07:57:20 +0300
Message-Id: <20260826045720.5779-6-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260826045720.5779-1-frn1furkan10@gmail.com>
References: <20260826045720.5779-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787720317-1B6D29EA-8C33FBC3/0/0
X-purgate-type: clean
X-purgate-size: 16058

Wire the per-cpupool admission-control switch through libxl
to xl sched-rtds, and document it.

Add -s/--schedparam to list or set pool-wide RTDS scheduler
parameters, and -a/--admission to enable or disable admission
control for a cpupool ("-c pool -s -a 0/1").

Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
 docs/man/xl.1.pod.in                 |  20 ++++++
 tools/golang/xenlight/helpers.gen.go |  23 ++++++
 tools/golang/xenlight/types.gen.go   |   4 ++
 tools/include/libxl.h                |   4 ++
 tools/include/xenctrl.h              |   6 ++
 tools/libs/ctrl/xc_rt.c              |  40 +++++++++++
 tools/libs/light/libxl_sched.c       |  46 ++++++++++++
 tools/libs/light/libxl_types.idl     |   5 ++
 tools/xl/xl_cmdtable.c               |   8 ++-
 tools/xl/xl_sched.c                  | 103 +++++++++++++++++++++++++--
 10 files changed, 254 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 88ccf7ad82..51405f4e33 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -1230,6 +1230,16 @@ the unreserved system resource.
 
 Restrict output to domains in the specified cpupool.
 
+=item B<-s>, B<--schedparam>
+
+Specify to list or set pool-wide scheduler parameters.
+
+=item B<-a ADMISSION_CONTROL>, B<--admission=ADMISSION_CONTROL>
+
+Binary flag to enable or disable admission control for the cpupool.
+When enabled (the default), a reservation is rejected if admitting
+it would exceed the cpupool's utilization capacity.
+
 =back
 
 B<EXAMPLE>
@@ -1293,6 +1303,16 @@ e.g., "xl sched-rtds -d vm1 -v 0 -p 100 -b 50 -e 1 -v 3 -p 300 -b 150 -e 0".
 To change the parameters of all the VCPUs of a domain, use B<-v all>,
 e.g., "xl sched-rtds -d vm1 -v all -p 500 -b 250 -e 1".
 
+4) Use B<-c CPUPOOL -s> to see whether admission control is enabled
+for a cpupool, and B<-c CPUPOOL -s -a> to change it:
+
+    xl sched-rtds -c pool-rt -s
+    Cpupool pool-rt: sched=RTDS admission-control=enabled
+
+    xl sched-rtds -c pool-rt -s -a 0
+    xl sched-rtds -c pool-rt -s
+    Cpupool pool-rt: sched=RTDS admission-control=disabled
+
 =back
 
 =back
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index b0c09da910..18ab0731ef 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -4192,6 +4192,29 @@ func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error){x
  return nil
  }
 
+// NewSchedRtdsParams returns an instance of SchedRtdsParams initialized with defaults.
+func NewSchedRtdsParams() (*SchedRtdsParams, error) {
+var (
+x SchedRtdsParams
+xc C.libxl_sched_rtds_params)
+
+C.libxl_sched_rtds_params_init(&xc)
+
+if err := x.fromC(&xc); err != nil {
+return nil, err }
+
+return &x, nil}
+
+func (x *SchedRtdsParams) fromC(xc *C.libxl_sched_rtds_params) error {
+ x.AdmissionControlEnabled = bool(xc.admission_control_enabled)
+
+ return nil}
+
+func (x *SchedRtdsParams) toC(xc *C.libxl_sched_rtds_params) (err error){xc.admission_control_enabled = C.bool(x.AdmissionControlEnabled)
+
+ return nil
+ }
+
 // NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults.
 func NewDomainRemusInfo() (*DomainRemusInfo, error) {
 var (
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index e0fd78ec03..897100d9b6 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -1231,6 +1231,10 @@ type SchedCredit2Params struct {
 RatelimitUs int
 }
 
+type SchedRtdsParams struct {
+AdmissionControlEnabled bool
+}
+
 type DomainRemusInfo struct {
 Interval int
 AllowUnsafe Defbool
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 7c098edab6..ff993c38b7 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -2797,6 +2797,10 @@ int libxl_sched_credit2_params_get(libxl_ctx *ctx, uint32_t poolid,
                                    libxl_sched_credit2_params *scinfo);
 int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid,
                                    libxl_sched_credit2_params *scinfo);
+int libxl_sched_rtds_params_get(libxl_ctx *ctx, uint32_t poolid,
+                                libxl_sched_rtds_params *scinfo);
+int libxl_sched_rtds_params_set(libxl_ctx *ctx, uint32_t poolid,
+                                libxl_sched_rtds_params *scinfo);
 
 /* Scheduler Per-domain parameters */
 
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 9f00d4a19d..6f4ea7ca62 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -897,6 +897,12 @@ int xc_sched_rtds_vcpu_get(xc_interface *xch,
                            uint32_t domid,
                            struct xen_domctl_schedparam_vcpu *vcpus,
                            uint32_t num_vcpus);
+int xc_sched_rtds_params_set(xc_interface *xch,
+                             uint32_t cpupool_id,
+                             struct xen_sysctl_rtds_schedule *schedule);
+int xc_sched_rtds_params_get(xc_interface *xch,
+                             uint32_t cpupool_id,
+                             struct xen_sysctl_rtds_schedule *schedule);
 
 int
 xc_sched_arinc653_schedule_set(
diff --git a/tools/libs/ctrl/xc_rt.c b/tools/libs/ctrl/xc_rt.c
index 3cb3fbb923..fb3f567d4f 100644
--- a/tools/libs/ctrl/xc_rt.c
+++ b/tools/libs/ctrl/xc_rt.c
@@ -130,3 +130,43 @@ int xc_sched_rtds_vcpu_get(xc_interface *xch,
 
     return rc;
 }
+
+int xc_sched_rtds_params_set(xc_interface *xch,
+                             uint32_t cpupool_id,
+                             struct xen_sysctl_rtds_schedule *schedule)
+{
+    struct xen_sysctl sysctl = {};
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
+
+    sysctl.u.scheduler_op.u.sched_rtds = *schedule;
+
+    if ( do_sysctl(xch, &sysctl) )
+        return -1;
+
+    *schedule = sysctl.u.scheduler_op.u.sched_rtds;
+
+    return 0;
+}
+
+int xc_sched_rtds_params_get(xc_interface *xch,
+                             uint32_t cpupool_id,
+                             struct xen_sysctl_rtds_schedule *schedule)
+{
+    struct xen_sysctl sysctl = {};
+
+    sysctl.cmd = XEN_SYSCTL_scheduler_op;
+    sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+    sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS;
+    sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo;
+
+    if ( do_sysctl(xch, &sysctl) )
+        return -1;
+
+    *schedule = sysctl.u.scheduler_op.u.sched_rtds;
+
+    return 0;
+}
diff --git a/tools/libs/light/libxl_sched.c b/tools/libs/light/libxl_sched.c
index 2d6635dae7..ae4379cf09 100644
--- a/tools/libs/light/libxl_sched.c
+++ b/tools/libs/light/libxl_sched.c
@@ -397,6 +397,52 @@ int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid,
     return rc;
 }
 
+int libxl_sched_rtds_params_get(libxl_ctx *ctx, uint32_t poolid,
+                                libxl_sched_rtds_params *scinfo)
+{
+    struct xen_sysctl_rtds_schedule sparam;
+    int r, rc;
+    GC_INIT(ctx);
+
+    r = xc_sched_rtds_params_get(ctx->xch, poolid, &sparam);
+    if (r < 0) {
+        LOGE(ERROR, "getting RTDS scheduler parameters");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    scinfo->admission_control_enabled = sparam.admission_control_enabled;
+
+    rc = 0;
+out:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_sched_rtds_params_set(libxl_ctx *ctx, uint32_t poolid,
+                                libxl_sched_rtds_params *scinfo)
+{
+    struct xen_sysctl_rtds_schedule sparam;
+    int r, rc;
+    GC_INIT(ctx);
+
+    sparam.admission_control_enabled = scinfo->admission_control_enabled;
+
+    r = xc_sched_rtds_params_set(ctx->xch, poolid, &sparam);
+    if (r < 0) {
+        LOGE(ERROR, "Setting RTDS scheduler parameters");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    scinfo->admission_control_enabled = sparam.admission_control_enabled;
+
+    rc = 0;
+out:
+    GC_FREE;
+    return rc;
+}
+
 static int sched_credit2_domain_get(libxl__gc *gc, uint32_t domid,
                                     libxl_domain_sched_params *scinfo)
 {
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index a7893460f0..d3121ea277 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -1286,6 +1286,11 @@ libxl_sched_credit2_params = Struct("sched_credit2_params", [
     ("ratelimit_us", integer),
     ], dispose_fn=None)
 
+libxl_sched_rtds_params = Struct("sched_rtds_params", [
+    ("admission_control_enabled", bool),
+    ], dispose_fn=None)
+
+
 libxl_domain_remus_info = Struct("domain_remus_info",[
     ("interval",             integer),
     ("allow_unsafe",         libxl_defbool),
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 502244f683..e48d5c5edc 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -295,13 +295,19 @@ const struct cmd_spec cmd_table[] = {
     { "sched-rtds",
       &main_sched_rtds, 0, 1,
       "Get/set rtds scheduler parameters",
-      "[-d <Domain> [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]] [-e[=Extratime]]]",
+      "[-d <Domain> [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]] [-e[=Extratime]]]\n"
+      "                [-c <Cpupool> -s [-a[=ADMISSION_CONTROL]]]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-v VCPUID/all, --vcpuid=VCPUID/all    VCPU to modify or output;\n"
       "               Using '-v all' to modify/output all vcpus\n"
       "-p PERIOD, --period=PERIOD     Period (us)\n"
       "-b BUDGET, --budget=BUDGET     Budget (us)\n"
       "-e Extratime, --extratime=Extratime Extratime (1=yes, 0=no)\n"
+      "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to domains in CPUPOOL\n"
+      "-s, --schedparam               List or set pool-wide scheduler parameters\n"
+      "-a ADMISSION_CONTROL, --admission=ADMISSION_CONTROL\n"
+      "               Enable or disable admission control for the cpupool\n"
+      "               (1=enabled, 0=disabled); requires -s\n"
     },
     { "domid",
       &main_domid, 0, 0,
diff --git a/tools/xl/xl_sched.c b/tools/xl/xl_sched.c
index 73cd7040cd..7257d1854b 100644
--- a/tools/xl/xl_sched.c
+++ b/tools/xl/xl_sched.c
@@ -246,6 +246,28 @@ static int sched_credit2_pool_output(uint32_t poolid)
     return 0;
 }
 
+static int sched_rtds_params_set(int poolid,
+                                 libxl_sched_rtds_params *scinfo)
+{
+    if (libxl_sched_rtds_params_set(ctx, poolid, scinfo)) {
+        fprintf(stderr, "libxl_sched_rtds_params_set failed.\n");
+        return 1;
+    }
+
+    return 0;
+}
+
+static int sched_rtds_params_get(int poolid,
+                                 libxl_sched_rtds_params *scinfo)
+{
+    if (libxl_sched_rtds_params_get(ctx, poolid, scinfo)) {
+        fprintf(stderr, "libxl_sched_rtds_params_get failed.\n");
+        return 1;
+    }
+
+    return 0;
+}
+
 static int sched_rtds_domain_output(
     int domid)
 {
@@ -339,10 +361,15 @@ static int sched_rtds_vcpu_output_all(int domid,
 
 static int sched_rtds_pool_output(uint32_t poolid)
 {
-    char *poolname;
+    libxl_sched_rtds_params scparam;
+    char *poolname = libxl_cpupoolid_to_name(ctx, poolid);
 
-    poolname = libxl_cpupoolid_to_name(ctx, poolid);
-    printf("Cpupool %s: sched=RTDS\n", poolname);
+    if (sched_rtds_params_get(poolid, &scparam))
+        printf("Cpupool %s: [sched params unavailable]\n", poolname);
+    else
+        printf("Cpupool %s: sched=RTDS admission-control=%s\n",
+                poolname,
+                scparam.admission_control_enabled ? "enabled" : "disabled");
 
     free(poolname);
     return 0;
@@ -715,6 +742,8 @@ int main_sched_credit2(int argc, char **argv)
  * -d [domid] -v [vcpuid 1] [params] -v [vcpuid 2] [params] ...  :
  * Set per-VCPU params for domain
  * -d [domid] -v all [params]  : Set all per-VCPU params for domain
+ * -c [cpupool] -s  : List pool-wide scheduling parameters for cpupool
+ * -c [cpupool] -s -a [0|1]  : Set admission control for cpupool
  */
 int main_sched_rtds(int argc, char **argv)
 {
@@ -736,7 +765,10 @@ int main_sched_rtds(int argc, char **argv)
     bool opt_b = false;
     bool opt_e = false;
     bool opt_v = false;
+    bool opt_s = false;
+    bool opt_a = false;
     bool opt_all = false; /* output per-dom parameters */
+    bool admission_control = false;
     int opt, i, rc, r;
     static struct option opts[] = {
         {"domain", 1, 0, 'd'},
@@ -745,10 +777,12 @@ int main_sched_rtds(int argc, char **argv)
         {"extratime", 1, 0, 'e'},
         {"vcpuid",1, 0, 'v'},
         {"cpupool", 1, 0, 'c'},
+        {"schedparam", 0, 0, 's'},
+        {"admission", 1, 0, 'a'},
         COMMON_LONG_OPTS
     };
 
-    SWITCH_FOREACH_OPT(opt, "d:p:b:e:v:c", opts, "sched-rtds", 0) {
+    SWITCH_FOREACH_OPT(opt, "d:p:b:e:v:c:a:s", opts, "sched-rtds", 0) {
     case 'd':
         dom = optarg;
         break;
@@ -801,6 +835,19 @@ int main_sched_rtds(int argc, char **argv)
     case 'c':
         cpupool = optarg;
         break;
+    case 's':
+        opt_s = true;
+        break;
+    case 'a':
+        if (strcmp(optarg, "0") && strcmp(optarg, "1"))
+        {
+            fprintf(stderr, "Invalid admission_control value.\n");
+            r = EXIT_FAILURE;
+            goto out;
+        }
+        admission_control = strtol(optarg, NULL, 10);
+        opt_a = true;
+        break;
     }
 
     if (cpupool && (dom || opt_p || opt_b || opt_e || opt_v || opt_all)) {
@@ -809,6 +856,11 @@ int main_sched_rtds(int argc, char **argv)
         r = EXIT_FAILURE;
         goto out;
     }
+    if (opt_s && (dom || opt_p || opt_b || opt_e || opt_v || opt_all)) {
+        fprintf(stderr, "-s cannot be combined with domain/VCPU options.\n");
+        r = EXIT_FAILURE;
+        goto out;
+    }
     if (!dom && (opt_p || opt_b || opt_e || opt_v)) {
         fprintf(stderr, "Missing parameters.\n");
         r = EXIT_FAILURE;
@@ -831,6 +883,49 @@ int main_sched_rtds(int argc, char **argv)
         r = EXIT_FAILURE;
         goto out;
     }
+    if (opt_a && !opt_s) {
+        fprintf(stderr, "-a/--admission requires -s/--schedparam.\n");
+        r = EXIT_FAILURE;
+        goto out;
+    }
+
+    if (opt_s)
+    {
+        libxl_sched_rtds_params scparam;
+        uint32_t poolid = 0;
+
+        if (cpupool) {
+            if (libxl_cpupool_qualifier_to_cpupoolid(ctx, cpupool,
+                                                      &poolid, NULL) ||
+                !libxl_cpupoolid_is_valid(ctx, poolid)) {
+                fprintf(stderr, "Unknown cpupool \'%s\'\n", cpupool);
+                r = EXIT_FAILURE;
+                goto out;
+            }
+        }
+
+        if (!opt_a) { /* output pool-wide scheduling parameters */
+            if (sched_rtds_pool_output(poolid)) {
+                r = EXIT_FAILURE;
+                goto out;
+            }
+        } else { /* set pool-wide scheduling parameters */
+            if (sched_rtds_params_get(poolid, &scparam)) {
+                r = EXIT_FAILURE;
+                goto out;
+            }
+
+            scparam.admission_control_enabled = admission_control;
+
+            if (sched_rtds_params_set(poolid, &scparam)) {
+                r = EXIT_FAILURE;
+                goto out;
+            }
+        }
+
+        r = EXIT_SUCCESS;
+        goto out;
+    }
 
     if ((!dom) && opt_all) {
         /* get all domain's per-vcpu rtds scheduler parameters */
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 05:21:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 05:21:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399612.1635611 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz64R-0003GE-Nn; Wed, 26 Aug 2026 05:21:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399612.1635611; Wed, 26 Aug 2026 05:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz64R-0003G7-KX; Wed, 26 Aug 2026 05:21:07 +0000
Received: by outflank-mailman (input) for mailman id 1399612;
 Wed, 26 Aug 2026 05:21:06 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <neal.frager@amd.com>) id 1wz64Q-0003G1-5t
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 05:21:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz64P-006jwg-FI
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 07:21:05 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a8e77a6-8faa-0a2a0a5109dd-0a2a450987be-28
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 07:21:05 +0200
Received: from [40.93.196.70]
 (helo=SA9PR02CU001.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <neal.frager@amd.com>)
 id 6a8e77bf-be1a-0a2a45090019-285dc4467129-4
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 07:21:04 +0200
Received: from BL1PR12MB5032.namprd12.prod.outlook.com (2603:10b6:208:30a::12)
 by CYYPR12MB8654.namprd12.prod.outlook.com (2603:10b6:930:c9::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug
 2026 05:21:00 +0000
Received: from BL1PR12MB5032.namprd12.prod.outlook.com
 ([fe80::3c13:eeb6:d9ef:c95d]) by BL1PR12MB5032.namprd12.prod.outlook.com
 ([fe80::3c13:eeb6:d9ef:c95d%6]) with mapi id 15.21.0360.005; Wed, 26 Aug 2026
 05:21:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uM+teSsEmwMJ3j/lpRMKgxFiy3b6UJH6v5d3SfppwyK779SRzgRKJOEDAKv1FUQKOz1j4XiBmNJusYU9UozvXI3ozLUlCwDY+PFO6WlSQpUxSJ7ckmk0eZUM1HSQCNEusi2bJvfOwpxvBLoH7XKFAYPpndowGX4mDnAB7f8dC0w18ciyMQjUiSyh54+y420bumMf3Xutwa8P3+NNvYYbKxsZegOs03z3hON81BB9LtgRk0H9ZAZY1aIcWup3ZpbF6eubaalz+akGuz0lgG8y1+5SVTynyxFi4DMce054Jp9GjUScmF/t/du2kX9NJghBImLar4T8QEa40C2cXRrUsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Qeph0ERCuFewIyge3tZoQqMVmcwLOq8YQEGPliQsyaQ=;
 b=EvFPdjnbFeTNoBULv7ODpBm7dFuUcNyAfOWV2yOvJfsmOFTgFHlnXUTbHmb4/d7WqWL+1WMYqu9pkJf5F+Or5reE8NjnBMuJadcVIzhBzPwKC3Nfv7/Y2NmU9olw3y7DDinXJ7TT4v32UHv38s/sPAkaC6dqdKW3MzgrCIIwxjqtc4BT+MnL7TRfMeVehWsCicQIduR9Ub71ai01utTsZa6/II9zGFrQ2TIpad1pRLT+PUOdSxIf/eOBbduo9jNddIe117byvGYukakGY+vctsUYIUGNVQBv9CfvdYdua4GEzg+SJQbEADzILY+TPJn4fxvZS6OuqTHpl67Oe1C8XA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Qeph0ERCuFewIyge3tZoQqMVmcwLOq8YQEGPliQsyaQ=;
 b=e7zuJ2N6p1jyyy5VfmQi2QKFSAejiON3n5XmxvAS8Ktgv58jPvF2wwpbzFdllFwU4Ab+1beI8I1X1LVLLNIW91hEwhB8ZBvC71s7wnQk1ORd1gaL4BwIyCotJfbI7flUGs+QJ9UMX361DZMU0jw7DiJeA7riH+sj14RQgcwbHNg=
From: "Frager, Neal" <neal.frager@amd.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Peter Maydell
	<peter.maydell@linaro.org>
CC: "Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "sstabellini@kernel.org"
	<sstabellini@kernel.org>, "anthony@xenproject.org" <anthony@xenproject.org>,
	"edgar.iglesias@gmail.com" <edgar.iglesias@gmail.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Stabellini, Stefano" <stefano.stabellini@amd.com>, "Saleab, Micheal"
	<Micheal.Saleab@amd.com>, "john.ernberg@actia.se" <john.ernberg@actia.se>,
	"matthew.l.weber3@boeing.com" <matthew.l.weber3@boeing.com>,
	"vincent.stehle@arm.com" <vincent.stehle@arm.com>
Subject: RE: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
Thread-Topic: [PATCH v1 1/1] include/hw/xen/xen_native.h: downgrade
 include-order assertion to warning
Thread-Index:
 AQHdJJsckvnz/cO5N0ySs3v4A11/7LatQ5eAgAAFmcCAAAXOAIAAAMSQgAAMYwCAAD5WgIACUOOw
Date: Wed, 26 Aug 2026 05:21:00 +0000
Message-ID:
 <BL1PR12MB5032167D2EBD91C753110996F0AE2@BL1PR12MB5032.namprd12.prod.outlook.com>
References: <20260805052723.2823538-1-neal.frager@amd.com>
 <2383a98d-d88d-415d-9de1-aa68a5d215fe@amd.com>
 <BL1PR12MB5032F21E0E2A6F17398B6D76F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
 <CAFEAcA8sWn1vjm+OFYzwA-jko2vYkFcWPwT6g9=0AeO+JQo-JQ@mail.gmail.com>
 <BL1PR12MB50322B1D97569B5CADEC8E55F0A02@BL1PR12MB5032.namprd12.prod.outlook.com>
 <CAFEAcA9rWqo92nt1StDuBwUjbV0eqdAA921nozpjQHDF_ARJyg@mail.gmail.com>
 <ea290b1f-5d40-48e3-9a64-1799244c6e64@citrix.com>
In-Reply-To: <ea290b1f-5d40-48e3-9a64-1799244c6e64@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
 MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Enabled=True;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_SetDate=2026-08-26T05:18:12.0000000Z;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Name=AMD
 General
 v26;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_ContentBits=3;MSIP_Label_198e8dea-a4f3-4850-b16a-fd6d2b1302b4_Method=Standard
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5032:EE_|CYYPR12MB8654:EE_
x-ms-office365-filtering-correlation-id: aa10cee5-8428-4d9c-c6b0-08df0331d0d3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|38070700021|6133799003|10067099003|11063799006|4143699003|56012099006|22082099003|18002099003;
x-microsoft-antispam-message-info:
 WyspDGisBZzsmrrFHlSSS8l5bib9ziBKo4p7yF2DkXrFMIRmatz/gZKY2LqMIJWnK4CJ67jJZu0GzQSxwlu7Iz3texf0KI9uaGCLAp5TOl6veKI0V6ygGK/h42qV0A/oj7+b8ok4PP/EFHJ1SOWEstA80caGrNgTLykKsrfJzEK5GStZQXWYUuxf8hxGPvnOgMpVlGW1+B6MIkYQ71t+BUN+OUsUrGGnL2stC0K7xfjAwDIvnEADFJeJmnSKXwuMSAVNd1uQx/d9oclF4eIKFVwsv7Qfn32vH81+c4wzkKGW1FFnkeHXT+KDcv53MvN5g87DbQDyYncUnLmCsEzOpNHuSTgdz4UhDq5GwbCRh3Xh2fX+rumNTNA6pJCGC8KB11QkXGJtaovsmPEy//ZJCxj6nQTAmQxkoDMDlIOsiAeSEdbBswC2mpmjI/yYHakFq1utmh2Q4QHInmfPtu1g9L1RJ57gtiD/dQH85JpazTObEwMW8ErfmL3BWfpSNYmwlXSb+7EXwK0JYaEl2eM8/SqMVJgthb6SaxMN4Vfc+hnOO/WX2Fi287T/jZj3RhgzOqWYE6X0l82qC35BMaJXcZbt130/Iuo9KMz3fjtDbAap4VOgKIRrPiezEFXc8UsdRVqzQOwybgNCrDXz53rmmiCruDuLXE4ja7ets8QCVx3LlfUBe+i209V6MfpCgVo5fVicUTiVVcNpvxtHNv0qWCehxDfNnrBr6upcB5zhLgk=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5032.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(38070700021)(6133799003)(10067099003)(11063799006)(4143699003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?a2o4enlFUGkrM1cvQzRaOWk1WXFwNmhoa1FYNW5PN0VGdkFYUzRLaUtaaENw?=
 =?utf-8?B?T25FaVdaUGlpc2F3ZG1tb3FlT3pLMW9zc1NUNFZrM3BUc1NxbmlZS3pJOU5a?=
 =?utf-8?B?NUFsSzZHQTNkeit6VUJCSktPVE9yR2ZoZDN3Z2VUa3AyQzR1RFpSYVloNHl0?=
 =?utf-8?B?UHBvR3poZ2xWSk5PTzg1SFo3R082UWZyemZnZTUyUzU4WXdBQXpzOVB1Mndm?=
 =?utf-8?B?b3cxZ2RTY1dya0Mrd3g3ZEg4TXpRemkxVlNBbTBISnhseE1Sb0VEMUtTMzNi?=
 =?utf-8?B?eXBxWm5ERFFKZVozMUp5SUUrbjFFVWF6emlaeTFQNHNNbkJSTUorSThmUStk?=
 =?utf-8?B?UEtjamtZUHFzRjFVaklxekRpQTgvTHBKeW5lbjRBdUhHdTF5WWI1cmQvV1pE?=
 =?utf-8?B?VWJtQ2p0MVg4K2RTcncvYjdNd2RJMTZSa05waDJHZ2ZQQThndm5nbGdZMzl0?=
 =?utf-8?B?VTJOS2tta3V0T0tiT0VORXV1c3NhNXpMWndWSm5admJyZzZYRkxkemlOb3B5?=
 =?utf-8?B?b3hYT2pqRTRJR1doOU14L2JSa2Z1SzZacWRqOXhqcTRua2RSRGowamVXNDRZ?=
 =?utf-8?B?d3RkUHFGR2t6cG5KdjkxK1ZjcEl5WGc4NUdrZUhkL1JtRm4zamZncGloSkdq?=
 =?utf-8?B?U3JHeldndHNCdjZ1eUhtRTkxUm52SGRKdUxrd2pwV0orSnIvNW1oUHp3aTRs?=
 =?utf-8?B?U1Vyd292dDBMTTRnNHFyMlIrWG9oVC96N1lyTTZtR1VVS2pUTEVHaE8yNUVk?=
 =?utf-8?B?cDh0aTNFV3E2alN5VTN2Uk0yb2VLd0lESmEvYlJzQitZZjRUYjU3TE1iczQ4?=
 =?utf-8?B?K0F3amlXK0tDRVBKbmZVRnRTYUdySTEwdnZjdTA2dk1WT1RVUXdZWUhFK05M?=
 =?utf-8?B?VGRha1I4ZnZiaTBIbXFzOEE0VHRmNERDTVQzb0dXTHJ2eVM0VitWNjM1c0dk?=
 =?utf-8?B?QnlvTENlUE5MR3IzOTlaQ1F6aTZ5ZGxTekUvWWh1ekNGVFNicGJwT3BIbzcx?=
 =?utf-8?B?N2ZZSmpHckZjREtyRnEzb3NIc1E3WGpCd1c3RWQrM21yU0Q4bEE4MEh2elgz?=
 =?utf-8?B?dVV4WmVlWlFmK3dIYld0blRBaEZIaFNLYzJXVTczVzdlL2FKSUNneHJ2VTF5?=
 =?utf-8?B?VmtBSEgrN3o0ODJLYmtLeVZkS1lONUN6Q3dwcnRrQVRMeXk0dGlrWkZkaSt5?=
 =?utf-8?B?aVdSRUhMVDdNRWN2b1k2ZmdvcUVnZVZIRHNOdkw5UWtzQVd6Q1pXdVptY2F6?=
 =?utf-8?B?Q2NiSXVSQ09GeFNKWGtNWWkxclROL0IySjJBVC83TDU0RVZXWDZwcXVzN21I?=
 =?utf-8?B?Z3Z5RndQQlYySjJxSVlqWGxaMEgzdVU0aC9RTWk1V2x0YjJvVmpnTGs4K3hS?=
 =?utf-8?B?Nk9mU3drOWZvVWIzQWUzMkhUNmRBYVBNWGZ5UVprN1VCMDI1cmhia1VlQ0FF?=
 =?utf-8?B?RmRkeVpWcXJvMUhKUytJRHZ3SVZydVpodXRYM0s1TDlZL2dLb0JQOWU4Rm96?=
 =?utf-8?B?WGl5QXVJQ0ltWkliV1BTYnFSK2NBMlpFcjZaNC9YUERjR04xc1UyRUlTQ1cr?=
 =?utf-8?B?N3hsdTdTY2UvbEttak5ZVGpuN1JEV25MTGlnMFNrT3pMeHRwNzlkRjFCbjNI?=
 =?utf-8?B?TmswYWxUOCtKam13YXpKYW5Ob09aNCs2c2ZIOE9nbkhxbGNpeVRUdDB4b291?=
 =?utf-8?B?NHJsMFcyaGkvQWlUbmxhSlhCRkgwSGNqSC9SVzlaNCtrWlRSd0E2S08zSTBL?=
 =?utf-8?B?eC9peWtCaG1TNDZnVXpyQzRleUFTT29HODJjMVBSMGZ1WER0elFRT2hkWjY2?=
 =?utf-8?B?bnJKTE5wQWJuUFdhV25yYTQzS29FOFRKaUVNeWtxVHJIS1B5V0p5eGlTamFC?=
 =?utf-8?B?NFpDeDQxWjlFUXFvdy8vUmdodWhLL2RBOUpBOTNOaHZLaXVPQW1BM1QzUHhZ?=
 =?utf-8?B?MDdLYnhEWi9VcjhUWjN2YVV5MDdOeHorTXFNQUJUYjl1T3llWExMN1I1RTB5?=
 =?utf-8?B?VVAyelJuUXE4YW9SNnZKMXNZOGU5WlI5Yk5sZ3h2TlR0SUpJTHgvOUkwb0pQ?=
 =?utf-8?B?TURCUFpwTmVwd3RiZXpCL25NbS9WOHBrSUxIUjQ3b2lrWEFyeW1hY0dpZ1hi?=
 =?utf-8?B?SVJFM0JUblJRL1ljZkVmNEQ3eFVHTHd3Z3h2WE5uRXRRaWllZC9JVnZmQVVy?=
 =?utf-8?B?R003MXZtdlBjaUxmMzdQN0gxOWJhSFRpOHdadzFKLzluWnhHQ01DeVlvL3c3?=
 =?utf-8?B?MG1IZG1OSzdyY3RzdVpVdjZaR3EzbkZJQllRVTlIZjFmaE1zaFQ2amJoSEFU?=
 =?utf-8?Q?tOR5fUoUDYmZFFo2XX?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5032.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aa10cee5-8428-4d9c-c6b0-08df0331d0d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2026 05:21:00.1379
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0StR98g12Wy1tJ8RZOksFvwRMZoEtfmT3+bwLcBETRoI2XI6SZpHCuQJrXvHlseE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8654
X-purgate-ID: tlsNG-bad1c0/1787721665-BDEC6034-0BD55200/0/0
X-purgate-type: clean
X-purgate-size: 4226

QU1EIEdlbmVyYWwNCg0KSGkgQW5kcmV3LCBQZXRlciwNCg0KPiBPbiBNb24sIDI0IEF1ZyAyMDI2
IGF0IDE0OjMxLCBGcmFnZXIsIE5lYWwgPG5lYWwuZnJhZ2VyQGFtZC5jb20+IHdyb3RlOg0KPj4g
QU1EIEdlbmVyYWwNCj4+DQo+PiBIaSBQZXRlciwNCj4+DQo+Pj4gSGkgU3Rld2FydCwNCj4+Pg0K
Pj4+PiBUaGUgLUkkKFhFTl9ST09UKS90b29scy9pbmNsdWRlIGFkZGVkIHRvIFFFTVUncyBleHRy
YS1jZmxhZ3MgY2F1c2VzDQo+Pj4+IF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gdG8gYmUgZGVm
aW5lZCBiZWZvcmUgeGVuX25hdGl2ZS5oIGlzIGluY2x1ZGVkLA0KPj4+PiB0cmlnZ2VyaW5nIGFu
IGluY2x1ZGUtb3JkZXIgYXNzZXJ0aW9uLiBEb3duZ3JhZGUgdG8gYSB3YXJuaW5nIHNpbmNlIHRo
ZQ0KPj4+PiB2ZXJzaW9uIGlzIGNvbnNpc3RlbnQgaW4gY3Jvc3MtY29tcGlsZS4NCj4+Pj4gUmVm
OiBodHRwczovL2dpdGh1Yi5jb20vcWVtdS9xZW11L2NvbW1pdC9lMmFiZmU1ZWM2DQo+Pj4+IFRo
aXMgaXMgYSBidWlsZHJvb3QgaXNzdWUsIHNvIEkgZG9uJ3QgYmVsaWV2ZSBpdCdzIG5lY2Vzc2Fy
eSB0byBmaXggZnJvbSB0aGUNCj4+Pj4gcWVtdSBzaWRlLg0KPj4+IEkgYW0gbm90IHN1cmUgSSBm
dWxseSBhZ3JlZSBoZXJlLiBXaGlsZSB0aGlzIGlzIGEgYnVpbGRyb290IGlkZW50aWZpZWQgaXNz
dWUsDQo+Pj4gdGhlcmUgY291bGQgYmUgb3RoZXIgdXNlIGNhc2VzIGZvciBfX1hFTl9JTlRFUkZB
Q0VfVkVSU0lPTl9fIHRvIGJlIGRlZmluZWQNCj4+PiBiZWZvcmUgeGVuX25hdGl2ZS5oIGlzIGlu
Y2x1ZGVkLg0KPj4+IEJ1dCB3aGF0LCB0aG91Z2g/DQo+Pj4gQW5kIHdoYXQgd2UgaGF2ZSBmb3Vu
ZCBpcyB0aGF0IGlmDQo+Pj4gX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXyB0byBiZSBkZWZpbmVk
IGJlZm9yZSB4ZW5fbmF0aXZlLmggaXMgaW5jbHVkZWQsIGl0DQo+Pj4gaXMgbm90IGEgaGFyZCBl
cnJvci4gIEZvciBidWlsZHJvb3QsIHRoZSBxZW11IHdvcmtzIGp1c3QgZmluZSBpbiBzcGl0ZSBv
Zg0KPj4+IHRoaXMuDQo+Pg0KPj4+IEkgdGhpbmsgdGhhdCBqdXN0IG1lYW5zIHlvdSBnb3QgbHVj
a3kuIEVpdGhlciB0aGVyZSBpcyBhIGhhcmQgcmVxdWlyZW1lbnQNCj4+PiBmb3Igb25lIGhlYWRl
ciB0byBiZSBpbmNsdWRlZCBiZWZvcmUgdGhlIG90aGVyIChpbiB3aGljaCBjYXNlIGl0IG11c3QN
Cj4+PiBiZSBhICNlcnJvciwgYW5kIHdoYXRldmVyIGlzIGNhdXNpbmcgdGhlIG1pcy1vcmRlcmlu
ZyB0byBoYXBwZW4gbXVzdCBiZQ0KPj4+IGZpeGVkKSwgb3IgaXQncyBmaW5lIGZvciB0aGUgb3Jk
ZXJpbmcgdG8gYmUgZWl0aGVyIHdheSAoaW4gd2hpY2ggY2FzZSBpdA0KPj4+IGRvZXNuJ3QgZXZl
biBuZWVkIHRvIGJlIGEgI3dhcm5pbmcpLg0KPj4gRnJvbSBteSB2aWV3LCB0aGUgb3JkZXIgdGhl
IGhlYWRlciBmaWxlcyBhcmUgaW5jbHVkZWQgZG9lcyBub3QgbWF0dGVyLCBhbmQNCj4+IHRoaXMg
c2hvdWxkIG5vdCBiZSBhbiBlcnJvci4gIEkgYWdyZWUgd2l0aCByZW1vdmluZyB0aGUgd2Fybmlu
ZyBhcyB3ZWxsLCBpZg0KPj4gdGhhdCBpcyB3aGF0IHdlIGFsbCBhZ3JlZSBvbiBpbiB0aGUgZW5k
Lg0KPiBUaGUgcmF0aW9uYWxlIGZvciB0aGUgaGVhZGVyIG9yZGVyaW5nIGlzIGluIHRoZSBjb21t
ZW50IGluIGluY2x1ZGUvaHcveGVuL3hlbi5oOg0KPg0KPiAvKg0KPiAgKiBDIGZpbGVzIHVzaW5n
IFhlbiB0b29sc3RhY2sgbGlicmFyaWVzIHdpbGwgaGF2ZSBpbmNsdWRlZCB0aG9zZSBoZWFkZXJz
DQo+ICAqIGFscmVhZHkgdmlhIHhlbl9uYXRpdmUuaCwgYW5kIGhhdmluZyBfX1hFTV9UT09MU19f
IGRlZmluZWQgd2lsbCBoYXZlDQoNCj4gTG92ZWx5IHR5cG8gdGhlcmUuDQoNCj4gVGhlIGRlZmlu
ZSBfX1hFTl9UT09MU19fIGlzIHdvZWZ1bGx5IG1pc25hbWVkLiAgVGhpcyBpcyBhbiBlcnJvciBv
Zg0KPiBYZW4ncywgd2hpY2ggSSd2ZSBub3QgaGFkIHRpbWUgdG8gZml4IHlldC4NCg0KPiBJdCBz
aG91bGQgYmUgbmFtZWQgX19YRU5fVU5TVEFCTEVfQVBJU19fLCBhbmQgdGhpbmtpbmcgb2YgaXQg
bGlrZSB0aGlzDQo+IHdpbGwgbWFrZSBpdCdzIHB1cnBvc2UgYSB3aG9sZSBsb3QgY2xlYXJlci4N
Cg0KPiAgKiBhdXRvbWF0aWNhbGx5IHNldCBfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fIHRvIHRo
ZSBsYXRlc3Qgc3VwcG9ydGVkDQo+ICAqIGJ5IHRoZSAqc3lzdGVtKiBYZW4gaGVhZGVycyB3aGlj
aCB3ZXJlIHRyYW5zaXRpdmVseSBpbmNsdWRlZC4NCj4gICoNCj4gICogQyBmaWxlcyB3aGljaCBh
cmUgcGFydCBvZiB0aGUgaW50ZXJuYWwgZW11bGF0aW9uLCBhbmQgd2hpY2ggZGlkIG5vdA0KPiAg
KiBpbmNsdWRlIHhlbl9uYXRpdmUuaCwgbWF5IG5lZWQgdGhpcyBkZWZpbmVkIHNvIHRoYXQgdGhl
IFhlbiBoZWFkZXJzDQo+ICAqIGltcG9ydGVkIHRvIGluY2x1ZGUvaHcveGVuL2ludGVyZmFjZS8g
d2lsbCBleHBvc2UgdGhlIGFwcHJvcHJpYXRlIEFQSQ0KPiAgKiB2ZXJzaW9uLg0KPiAgKg0KPiAg
KiBUaGlzIGlzIHdoeSB0aGVyZSdzIGEgcnVsZSB0aGF0IHhlbl9uYXRpdmUuaCBtdXN0IGJlIGlu
Y2x1ZGVkIGZpcnN0Lg0KPiAgKi8NCj4NCj4gLi4uYmFzaWNhbGx5LCBpZiBzb21ldGhpbmcgZG9l
c24ndCBpbmNsdWRlIHhlbl9uYXRpdmUuaCBiZWZvcmUgeGVuLmgNCj4gdGhlbiBfX1hFTl9JTlRF
UkZBQ0VfVkVSU0lPTl9fIGNhbiBlbmQgdXAgZGVmaW5lZCB0byB0aGUgd3JvbmcgdGhpbmcuDQo+
IChEaXNjbGFpbWVyOiBJJ20gbm90IGEgWGVuIGV4cGVydCwgSSdtIGp1c3QgYXBwbHlpbmcgQ2hl
c3RlcnRvbidzIEZlbmNlLikNCg0KPiBfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fIGRvZXMgYWx0
ZXIgc3RydWN0dXJlcy4gIEl0IG11c3QgYmUgY29uc2lzdGVudA0KPiBhY3Jvc3MgYSBjb2RlYmFz
ZS4NCg0KU3Rld2FydCBpZGVudGlmaWVkIGEgYmV0dGVyIHNvbHV0aW9uIGZvciB0aGlzIGJ1aWxk
cm9vdCBpc3N1ZSwgc28gSSBhbQ0Kd2l0aGRyYXdpbmcgdGhpcyBwYXRjaC4gIFRoaXMgcGF0Y2gg
aXMgbm90IG5lY2Vzc2FyeS4gIFRoYW5rIHlvdS4NCg0KQmVzdCByZWdhcmRzLA0KTmVhbCBGcmFn
ZXINCkFNRA0K


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 06:14:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 06:14:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399633.1635619 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz6uG-0002Dx-Cd; Wed, 26 Aug 2026 06:14:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399633.1635619; Wed, 26 Aug 2026 06:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz6uG-0002Dq-9r; Wed, 26 Aug 2026 06:14:40 +0000
Received: by outflank-mailman (input) for mailman id 1399633;
 Wed, 26 Aug 2026 06:14:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wz6uF-0002Di-5H
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:14:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz6uB-00Bxk9-Lc
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:14:35 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8e843b-bab6-0a2a0a5309dd-0a2a4507b616-48
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 08:14:35 +0200
Received: from [209.85.208.42] (helo=mail-ed1-f42.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8e844b-b4ea-0a2a45070019-d155d02ac0da-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 08:14:35 +0200
Received: by mail-ed1-f42.google.com with SMTP id
 4fb4d7f45d1cf-6a17211b9ecso1238691a12.2
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 23:14:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5deae9a75sm2448693a12.28.2026.08.25.23.14.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 23:14:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787724875; x=1788329675; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=tiSCojhdiH2JeEvty2kEuMzpDUHyn8pRiRkSiqHcmFg=;
        b=EYVqTbS7OkQBHT4B1no5eJbjUzGQyy6auRroHybF/OmEL7c2rErJJlluX2wTiTYfEI
         SKSbWCilnZDcClyq8+i/aRUdFBbe0It4tZ3XrEhvgFd3tScW/1YBCiwFWS5DQKzJWddF
         1lyKg9dLQyysEINrDOFbRSK0QUNO9FPSDJlWTNsRb1gMO8IvyPMVkWzhlhDmL5jqQHiu
         0lC/q+Ncz6enS9vyhmH4X4rnC18aGdY6XNDYJz1pmXQSLeRSAPStu/5WrE58LDoMfQ47
         aSo4vmrH3nUwg0kqTgvLcgspUroTD2WAV5r+WOX11D8iIawHT0fBfYjwLxKa6WYflwqq
         a9wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787724875; x=1788329675;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=tiSCojhdiH2JeEvty2kEuMzpDUHyn8pRiRkSiqHcmFg=;
        b=K7LDgNIsEeKAZhLArls/ocxqvy1PSalj3EjjU0utJLi0gMQtJ496N3bO6h5sOX891o
         fGKm4e7XAmZRaL1rEq5YyFnO6Utu3eKNvSRdEPE+UXYvtP2gIR/vLAoUYXGT1zp+GlTu
         8PQNIHymJ7fEuNl2JMaXIVOS7OsZAKqP1qoeGKxeyK0lTryOMK8NIvnYflqXtJai3fSw
         LkrryZPbwU6Qb0vfDyzT50mO+XzO8Eg7tw6WrLUgnArDnOWjSQIJj2koL4mRbx11myyJ
         SOy9pc+cB7+d5QsVciu3x228B5dq/bEUtRTwA+Sqzn/a3ieLcnH/10y2m+mr1vDw0Ai0
         pitw==
X-Forwarded-Encrypted: i=1; AHgh+RrP59oHLcEa5DttT2NJzv8p4QY383NTezijXP9/IX4pC3MBhWSg/zkJ5Yt1lE1o74IlWWontKKjJK0=@lists.xenproject.org
X-Gm-Message-State: AFuF++neuzC3J87llZ1AUs9/eu5sUmL95TMDyWWxvMCADz9RVqJFaQxU
	X7k62esiom2BP4AKu+KknQ9skMvpD2kqrjwrUEqpRjXIWHQwNAAuzp8E9wEakXNbtg==
X-Gm-Gg: AR+sD11zLaMUDdSsP54m+4hF0wizleomkRGqzNoJ2aDje4eo8UMSrV4xnI8h+NZvBEQ
	jtwWxdg9XTYdqbWbY18/ZlbNV7OjeMp38NdwgnPR0VXeq7qh1mdR+hRqYNMMXeAMq3cLRiX0fW1
	sZGq5KdjBeEKOR/9MLO/xsDzHoRjxvlzawI950b4wDxkFTU2/ei/CkKECNRfLpIPkLycW9XcLvC
	FCtVVH8qAMPjvSXXaf/OupgJibYpDZJXqjK1vA1uhPp+qsq9A6AX8V7LTQRjpzEkLK1Ss6Z+Qf6
	El7ccF7N06Dne79l2hjLGEM18Bz+EfwR88wVs+3J5IX2MjWi8HQbBQuA/q2CJjaxS7GkwdySJFF
	O2EqeyMs7f+YdlwpzGNp7TCNbvcX/zW15UgkH7ZnWRCZMXFefPjb3CYo8IptZVxg0cNWact1uNI
	biH4EgYOOu5E3ojPBraNr0MNmJW54L3YXASiXrW7L+74v7ZgBM20CyscUmy73tfxAR+JgnDyxcU
	lelTokrbc47VUGJJ9kVTAiHwt2YKJqrxbg0XM1HbfR5buv7Jdfi
X-Received: by 2002:a05:6402:1586:b0:6a5:d8f0:dc12 with SMTP id 4fb4d7f45d1cf-6a5df64dd40mr5539605a12.14.1787724874966;
        Tue, 25 Aug 2026 23:14:34 -0700 (PDT)
Message-ID: <deeae7d9-b37e-4d60-95fe-a87b7ef59859@suse.com>
Date: Wed, 26 Aug 2026 08:14:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/5] xen/sched: rtds: make admission control cpupool-wide
 toggleable
To: Furkan Caliskan <frn1furkan10@gmail.com>
Cc: jgross@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org,
 dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org,
 sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com,
 michal.orzel@amd.com, xen-devel@lists.xenproject.org
References: <20260826045720.5779-1-frn1furkan10@gmail.com>
 <20260826045720.5779-5-frn1furkan10@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260826045720.5779-5-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787724875-A5EC6AE4-BD7CA39D/0/0
X-purgate-type: clean
X-purgate-size: 1471

On 26.08.2026 06:57, Furkan Caliskan wrote:
> @@ -1691,6 +1709,33 @@ rt_dom_cntl(
>      return rc;
>  }
>  
> +#ifdef CONFIG_SYSCTL
> +static int cf_check
> +rt_sys_cntl(const struct scheduler *ops,
> +             struct xen_sysctl_scheduler_op *sc)
> +{
> +    struct xen_sysctl_rtds_schedule *params = &sc->u.sched_rtds;
> +    struct rt_private *prv = rt_priv(ops);
> +    unsigned long flags;
> +
> +    switch ( sc->cmd )
> +    {
> +    case XEN_SYSCTL_SCHEDOP_putinfo:
> +        spin_lock_irqsave(&prv->lock, flags);
> +        prv->admission_control_enabled = params->admission_control_enabled;
> +        spin_unlock_irqrestore(&prv->lock, flags);
> +        break;
> +    case XEN_SYSCTL_SCHEDOP_getinfo:
> +        spin_lock_irqsave(&prv->lock, flags);
> +        params->admission_control_enabled = prv->admission_control_enabled;
> +        spin_unlock_irqrestore(&prv->lock, flags);
> +        break;
> +    }

Blank line please between non-fall-through case blocks.

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -814,6 +814,10 @@ struct xen_sysctl_credit2_schedule {
>      uint32_t ratelimit_us;
>  };
>  
> +struct xen_sysctl_rtds_schedule {
> +    bool admission_control_enabled;
> +};

In the public headers only fixed-width types may be used. The width of
bool is ABI-dependent (no matter that it's exceedingly unlikely to ever
be other than the same size as char).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 06:33:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 06:33:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399647.1635628 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz7Cc-00051a-PY; Wed, 26 Aug 2026 06:33:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399647.1635628; Wed, 26 Aug 2026 06:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz7Cc-00051S-Lq; Wed, 26 Aug 2026 06:33:38 +0000
Received: by outflank-mailman (input) for mailman id 1399647;
 Wed, 26 Aug 2026 06:33:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wz7Cb-00051M-1M
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 06:33:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz7Ca-00G6IR-8x
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:33:36 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8e88b1-bab6-0a2a0a5309dd-0a2a4507c9aa-36
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 08:33:36 +0200
Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8e88c0-b4ea-0a2a45070019-d155da2ad1d2-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 08:33:36 +0200
Received: by mail-ej1-f42.google.com with SMTP id
 a640c23a62f3a-c2055573c8cso75582466b.3
 for <xen-devel@lists.xenproject.org>; Tue, 25 Aug 2026 23:33:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a7303casm431017666b.25.2026.08.25.23.33.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 25 Aug 2026 23:33:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787726016; x=1788330816; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=um4yUsDv8cKb/Tn8csIrcU7+wnb9hBIUF0Hp/FAFH7g=;
        b=eN+VVzLHAXBQ7PwZ/XyNr1cjazx5E/qsEF6Wz3P8UY4JHkPhp7ZRFRyjabQmICzovz
         QKAvOaDJHr2xrQqk4wWOdeE8bUtirONeFen8A1kWd36W5SRZOY0PHvIVRi+90J3hfwET
         vDFBYSP4ZBOb70+lJr9n+0T6dPb/T8zao15dq29LlQKjATihW9rj6i1amTrBbNZDkjJK
         OPgjbICjKnJeXfJgBZeHDA+ncAh9WfqBt5XZ07tPDqFADMOd5C64mWLzAEi3NXFUlsP6
         1MKoXaFqU94sgk0gliRhM+G3CVgMJTk0c5xM1kEZQOCZasDdTmf/idGLhthdvzwrif6X
         eiqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787726016; x=1788330816;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=um4yUsDv8cKb/Tn8csIrcU7+wnb9hBIUF0Hp/FAFH7g=;
        b=oo4navzLw3Nsegwq9RmYwdRkuHPSHCI1ey0TA9PfIzaZIKuCy2LVp4Q03BgOXpiFj1
         EdH4LtbhDYeg/ipXYqOvokyQGcEi7hHvMjfj0bzosIFVQCk/OJ8hwU9BKBQFWeQC09D/
         SP/dC/mFDG9DlDAy0EZTBiAdP9nZDgfTwAaOmoH8NclQ//OJjVu8h15MgJJA39+O0N4x
         OJMxqlfjAQBCg/D6tAKcGlIksDjC9cKWZGMJvYu1nUievFtSLTegXFOxFQw+kB1+jOim
         pPXcufekOqxAk2GMnhWj49VrFcAw12ScEez7PVHnO4koOVH3XwC9iaEyrzALdzCUJlbL
         XdfQ==
X-Forwarded-Encrypted: i=1; AHgh+Rr7Agp+AZjo/jqyKi4dV6vTHa7idfl4zfLSb6uZZc2TWJT0uvHzr9KZlMCNc2i24sOMZ4oH+QtWdmw=@lists.xenproject.org
X-Gm-Message-State: AFuF++mwuqjT59XGBBSC37YpzVLse/SCTwO6p7Uzuzp3CHzLsJHgB6CB
	0ZQlZJu28aT7wkX/GfHHPFm6K/pgWBNFJSuaYy61qcguV7ZM0vGcJ4p26zpRp+Dg/g==
X-Gm-Gg: AR+sD12fLiPnz6l1P8GUv1z0b0Z9Amk5SaZtHu5j5tsmRBot5nqR06MvdIsA5awp15j
	b4LznhNDAJcab6H5LJbW9kYstyplai2SDJQwKzreFAzk/4rPtGnwCZlePvWxUHWq/LeTqNmNyRb
	Bey8+w0D6CpZcT3RDyAtoiNi1Cs/gKXpECDULsKyB31a/p+mBZ0/nyeTG/BlXJP/0vqfINCQ0kW
	eX+qiCGawdYcF8xMnj0B9gGXgN2QeOAvY012MfdhWjLOV4vCmcR40TJ/kGs1MhRJqT6w0Q3BMcP
	PyRVdnB/SriZhNGR2Ms6YFJZHLsC7EouPY0FLfAo/ouif++q+6t3jlsBOrGpZOjdnCCJI1P/LCS
	x6nVzSlMNCtT3wdJbztklN5frftfyAEmL0wtOuC2sgk8KceXaaTKhhgktR6elMs8ol8j+Jim4Ld
	Ut0vrCY5z+Abs6lX/iNwDXrGYk49gU0BdThaFAULmycAqXJX/jyr+522MAM3YA9INrbgeA3bIv/
	hVRGLl+gPnSfdX2/HpddB41tdLo8gVCYXTYYKCMuWe/A9zBiXZ8
X-Received: by 2002:a17:907:c499:b0:c24:6390:decf with SMTP id a640c23a62f3a-c250c329353mr501402566b.16.1787726015706;
        Tue, 25 Aug 2026 23:33:35 -0700 (PDT)
Message-ID: <22091019-92ea-4de5-b470-2eb40d819dd1@suse.com>
Date: Wed, 26 Aug 2026 08:33:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings
 in PolarSSL
To: Andrew Mbugua <andrewprecious388@gmail.com>
Cc: jgross@suse.com, samuel.thibault@ens-lyon.org,
 xen-devel@lists.xenproject.org
References: <20260825184605.79318-1-andrewprecious388@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260825184605.79318-1-andrewprecious388@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787726016-348C9AE4-0DDCE437/0/0
X-purgate-type: clean
X-purgate-size: 2146

On 25.08.2026 20:46, Andrew Mbugua wrote:
> When compiling Xen with GCC 14, I get a compiler warning originating from the /polarssl-x86_64/library about a memset element size mismatch:
> 
> ssl_tls.c: In function ‘ssl_session_reset’:
> ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
> 1778 |     memset( ssl->ctx_enc, 0, 128 );
> |     ^~~~~~
> ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
> 1779 |     memset( ssl->ctx_dec, 0, 128 );
> |     ^~~~~~
> 
> This patch introduces a build-time patch to PolarSSL that replaces the hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean compilation without warnings.

First a formal note: Commit messages want limiting to 75 characters per
line (some even say 72).

Then: You introduce a patch which isn't used anywhere. What use is such
a patch? You also ...

> Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
> ---
>  stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>  create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch

... introduce it in a new patches/ subdir, when all other patches live
right beneath stubdom/.

> --- /dev/null
> +++ b/stubdom/patches/polarssl-gcc14-memset.patch
> @@ -0,0 +1,13 @@
> +--- a/library/ssl_tls.c
> ++++ b/library/ssl_tls.c
> +@@ -1775,8 +1775,8 @@
> +     memset( ssl->iv_dec, 0, 16 );
> +     memset( ssl->mac_enc, 0, 32 );
> +     memset( ssl->mac_dec, 0, 32 );
> +-    memset( ssl->ctx_enc, 0, 128 );
> +-    memset( ssl->ctx_dec, 0, 128 );
> ++    memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) );
> ++    memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) );

Don't you mean sizeof(ssl->ctx_enc) and sizeof(ssl->ctx_dec) respectively?
Otherwise it looks like you're making a bad situation worse.

Judging from surrounding style, there also looks to be a blank missing each,
ahead of the new inner closing parenthesis.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 07:26:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 07:26:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399665.1635654 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz81R-0003Zf-OF; Wed, 26 Aug 2026 07:26:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399665.1635654; Wed, 26 Aug 2026 07:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz81R-0003ZY-L0; Wed, 26 Aug 2026 07:26:09 +0000
Received: by outflank-mailman (input) for mailman id 1399665;
 Wed, 26 Aug 2026 07:26:08 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Zhao.Jiaqing@amd.com>) id 1wz81P-0003ZS-VL
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 07:26:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz81O-0006oY-Be
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 09:26:06 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Zhao.Jiaqing@amd.com>)
 id 6a8e9503-2eae-0a2a0a5409dd-0a2a450288da-28
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 09:26:06 +0200
Received: from [52.101.201.43]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Zhao.Jiaqing@amd.com>)
 id 6a8e950c-6ca4-0a2a45020019-3465c92b21b2-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 09:26:05 +0200
Received: from CY5PR22CA0080.namprd22.prod.outlook.com (2603:10b6:930:80::19)
 by SJ0PR12MB6880.namprd12.prod.outlook.com (2603:10b6:a03:485::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.12; Wed, 26 Aug
 2026 07:25:51 +0000
Received: from CY4PEPF0000EE35.namprd05.prod.outlook.com
 (2603:10b6:930:80:cafe::3e) by CY5PR22CA0080.outlook.office365.com
 (2603:10b6:930:80::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.8 via Frontend Transport; Wed, 26
 Aug 2026 07:25:51 +0000
Received: from satlexmb07.amd.com (149.199.90.133) by
 CY4PEPF0000EE35.mail.protection.outlook.com (10.167.242.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Wed, 26 Aug 2026 07:25:50 +0000
Received: from zjiaqing-dev.amd.com (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 26 Aug
 2026 02:25:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FUbrDCt87TUHqMcTARr8GSI0MmAW+dwPkwUTCiekhcKvVvlNzjbPzL8GEEZcHC2yqeabIej+LFXMMdN8jPEk1lh/LjwmOLeXRHM7KgUZ3Bfp6spLAShWqqEfFXEypXF1O44J2quuaYq5GUWI3os9zvJO6DrnNfrfnlhVckxb+GLK+YE2Q2vixGppDRyOxw5GglEiLcO8Jzi0gmVNJ2CWLMNB9Fm38sCe+jDBnTb9uahMBQd9EQEzxXi6OnThoNEDIDuFISQBakw79Ml53rB0PtFlyR/w7p6lIyLpAr1EjzhpUpwcPMv69vtJJAEgYaHXWIZnEWxZAfEgyEprtRujcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8VD7YGXn1R4mrSF8Z9nVENyoKgDNQ1X3q79iAvYgzDY=;
 b=NBeU+vgTTV1GTQXYEUNGYmijRlc2LjqxxsyGJzueB+LT/mpWVkzOg4U2cFFntkcAbWfk6ha2i6mJCFo0301zIqaotuYo4ivjwalJw803ZLfAUES3s4PC0o/XwK7QFN7ZWfe4/Zh2Eg2o8AZKx6xJpqVEDwS9I8rzZrh/AxLNzOGlSL7BlhVUcUKuzJ+UjWN3qDlTkEgroC6LiePCLHYcUjgcFn4k4vkeffVPsFyHAQjTCyEC9d+LtjfrsGtAPLqigOSfEdp15xk5brxwxJ8my2m3OATqYKxR2pqPorDBve05OjkfN6Ydfgs9LnpTUmST2imydmg+h1yLR37SdEFDyA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
 is 149.199.90.133) smtp.rcpttodomain=lists.xenproject.org
 smtp.mailfrom=amd.com; dmarc=fail (p=quarantine sp=quarantine pct=100)
 action=quarantine header.from=amd.com; dkim=none (message not signed);
 arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8VD7YGXn1R4mrSF8Z9nVENyoKgDNQ1X3q79iAvYgzDY=;
 b=ojLc/KxHYeGR0rGiR9KwomHwpppXYBnaETWZAr5bj+/gGnwJxU1oXAgmUj4pw+43GWpCjrnnL6vJ/taY2SF/tFYOhuCDJI7JLzM8HnubdLivGC4RMqPWejdKXSzTjjQUT/iI0IBr7HioNWmlITzXqC2OW1yiSjpcWJ6A8GJhwDI=
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
 149.199.90.133) smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine header.from=amd.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 amd.com discourages use of 149.199.90.133 as permitted sender)
From: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Teddy Astie <teddy.astie@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Jiaqing Zhao
	<Zhao.Jiaqing@amd.com>, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?=
	<roger@xenproject.org>
Subject: [PATCH] x86/cpuid: gate the hypervisor PV-only leaf on is_pv_domain()
Date: Wed, 26 Aug 2026 15:25:26 +0800
Message-ID: <20260826072526.767424-1-Zhao.Jiaqing@amd.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com
 (10.181.42.216)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE35:EE_|SJ0PR12MB6880:EE_
X-MS-Office365-Filtering-Correlation-Id: 6f762f29-ea15-4440-ef90-08df03434152
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|23010399003|376014|82310400026|1800799024|10067099003|11063799006|18002099003|56012099006|3023799007;
X-Microsoft-Antispam-Message-Info:
	0v+ahpYOFjZnYs7ymZg6uGvaJbqBgyrBV2hVXQ5NQCMVrU/oy0ddqvloASiSGXTYAKvPto8NM36Rssjo5MkLEDu+/ZovryVtq2K/AFYWsUFky2cVEJ65CvOlDicoHdrKicIs19VI2o2Hp1yQZE2HcX2Yh7bkfEy4/APBLPRLToMxtmAA5W1D3ljQ6OB0OOZM0zzG6Y9wbeReI3ZADsgp+YUiDXI/tRw6M2x6Hd8EvIKz9onMYaSGnw5sXjOyYCRmhS79F/XtkUfS3n/t3rNOc2Z4K39LWRoioklwp5q8C2jGjGp7vFgxWXMLEEUfrsp5IG+YBo0+ihN1WrbY5EDjtCPJQMkXzjS3tTGRAUbUlcM4nWip4fuvAyRb/Atcxjd3wMmA6pKkWQ+Kof+3RCEL/QmZQtsqpTkuN58wFDOgFtwsZv8U+En4r6DzBng4BmnPFluZQOWuqyySEldl9ixoFylWRFULywEs0aWyyXcEK0tISOTKyoHcF13LaBFQ5qY5VBIAVQbZh5IM+3ZxTpR20aWCdd+GHIFCq05IbDBi7Zx+O6lbA2Ro76d3H8kOQao4NZNSRjlTOIPyEDqvCuxX5DTNVGVZV1/cBN1UeR72J9PTlNjTRQ5LEXgM6RKEdZZ4xQ+iVkZL1NiDHn4rVPhgoK+BpV6Q4tS+EDBZZb/o7hmLU24KS+TqPmRXH0Gsm4uHMJFTXD8CTJb0pYYheYcpUQ==
X-Forefront-Antispam-Report:
	CIP:149.199.90.133;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:unknown-90-133.xilinx.com;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(376014)(82310400026)(1800799024)(10067099003)(11063799006)(18002099003)(56012099006)(3023799007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	lYR5LWIrJVI3jBFCfBJn7Si3OFsrKXwpz1tpIfTlKm+TgkwAN8YgUzlYXTK0FLLn3rUHXCn8oR18g9teVfUZbZTPkfySlwAYoJOeyfFh1Yw+PerM+nAFQRam9AR6TxQ+JVHy2bk1WFAeC3d7otVUUMZ0MYgBvWMArhLKijbkntVrC+X1GgN8EHparR/933PEtciP+GlkhGf57/utAFZCFtBn/kmAfnuV6nplOABSryHVN1n9mG+TJdKaFqKw7tbgyLHyxBXz7JyQll4KoFh2CQxVdCmmv/PZDd+gYjQF8ySvZjlG4+99z3+6GZ50cmpad3Aw1toJ8QMxWX7FJe2rIr4ZGK0ALkgCfvzzcEaisBO/Ti1WNODbiOVf8shmR+7/gc91IHg5J28GBw162PVEgxCQm74gFobF48OT7GcCLaVmo3VQGmy7jzbtzwbnPZjd
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 07:25:50.2658
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f762f29-ea15-4440-ef90-08df03434152
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[149.199.90.133];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE35.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6880
X-purgate-ID: tlsNG-720697/1787729166-674BE2AC-05BD3BC5/0/0
X-purgate-type: clean
X-purgate-size: 929

Hypervisor leaf 5 is PV-specific, but is gated with !is_hvm_domain(),
which stays a runtime test in a build without PV support. Test for a
PV domain directly so the compiler can discard the leaf when
CONFIG_PV is disabled.

Suggested-by: Roger Pau Monné <roger@xenproject.org>
Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
---
 xen/arch/x86/cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 6e9b15c9c3..a9aeb2d268 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -157,7 +157,7 @@ static void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf,
         break;
 
     case 5: /* PV-specific parameters */
-        if ( is_hvm_domain(d) || subleaf != 0 )
+        if ( !is_pv_domain(d) || subleaf != 0 )
             break;
 
         res->b = flsl(get_upper_mfn_bound()) + PAGE_SHIFT;
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 08:29:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 08:29:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399698.1635682 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz90H-0003Xp-IY; Wed, 26 Aug 2026 08:29:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399698.1635682; Wed, 26 Aug 2026 08:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz90H-0003Xi-Fz; Wed, 26 Aug 2026 08:29:01 +0000
Received: by outflank-mailman (input) for mailman id 1399698;
 Wed, 26 Aug 2026 08:28:59 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wz90F-0003Xc-JP
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:28:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz90F-00CQ2z-09
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 10:28:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ea3be-8faa-0a2a0a5109dd-0a2a4507b7f4-42
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 10:28:58 +0200
Received: from [209.85.208.47] (helo=mail-ed1-f47.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ea3c6-b4ea-0a2a45070019-d155d02fbdbc-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 10:28:54 +0200
Received: by mail-ed1-f47.google.com with SMTP id
 4fb4d7f45d1cf-6a38098734bso1105655a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 01:28:54 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5deaa8473sm4067116a12.21.2026.08.26.01.28.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 01:28:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787732934; x=1788337734; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=DywgHdCmnUOIWC8SRrCzIw91lBf8ROON0CehWTXQdrI=;
        b=dk4JC3CKPEM8jzPQWlCYSz6hafZKTFklwrLDlsDJ1G3PPoylNj3fZ1g8v7JHB+Nkmr
         xAi4AMr8oQV7MSNjPYoVu+GVx5tmaWbnUO89o9FAzZVgYi+SORE0epAOFDf5hvJzLHtV
         YDowjFvcOED0gazsdQFsnMJkKEAx24q4m92x8wB3paILK97f1MIDLotwm2v9mzHgszQf
         vQGnH7YrbMVn2yz2CmoLJQM8OCfpDykIJ5qCxb4moJL+ZeimpauWp7tT4Z7zy72kXU+v
         QSJpFCzJRyp4NpNGjD6juufP2bwDBMasp3qp0A7UrPxzS3UI4+3eonoyroMKVSZqOJbO
         QPCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787732934; x=1788337734;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=DywgHdCmnUOIWC8SRrCzIw91lBf8ROON0CehWTXQdrI=;
        b=S580s+3uIEaVNSHFWKtlJK89jOJqKW9REwzvGb1Gk4PHRVwrf+S2z7ouQEhc5qutr6
         AKRo4wwt9iWgTW3y8xmFbn7Exs4Wc+JA1IbNaOkbnb75QcKdwhholZjXRpKzQAYwVuEv
         qR/ZQaEYMRUjq+S31y9Hn6rIUPMF1R6zwJkkL9jryvTcXplH+L4b3ybZ4EMqXZDrR1jo
         QZwlfYsxWzf/JLmeaaolg7tXYHY3svCdWdnt22S38rkNVgbtxdqumazoNOd1LtKOPoVn
         yh0YPmEYw+PeHkwf2+wKD3DDvse3hsjZ1N7yPReyZ/mJMj/e2aVuIc+LC5Cuc0RFB37O
         ssxg==
X-Gm-Message-State: AFuF++m4tDslNjE4/cl2Dpos4NmP7mULoDQxt1G5pdYkqgEKeFJknuR3
	3Tu88ExEm9MVqitxHf8rpfipY/Feup1DYH/2DKgRNp5AgAtTNu/f3F3PsR54f2xKE3QtSjoCKwa
	NvzZFKA==
X-Gm-Gg: AR+sD11DXW9N9GQdGkPmXTp0rGsDluz67vsNV7hWHeC+ArBQ9uC7NseT+C9M8HzaTV8
	/klmQig6xj7WmoTXUohxp7OwcK03L4pYQ/+PygmuB+2f1KMolLO8m6hnrZEWbjPJV6MvPtZcKQc
	tm+qWv7mT12v69nI66NZ2MbEVMULyx9qSGur57mIXHDV5J//MVX5xhAjeHmLWpBq2SDrL5hr59p
	X64ateUcwkukonAytUpZFUXf1X8ZLaXX3A7k1kbQrP7Kx24cwnjM/WKiviemzaTTv7VFZ/MPBXK
	tvjIlmqECeEn/j0UOwHpEZbTSWzKt3xz2mgN3BJwK/qRn8RCDNKn3WkhXE4Qssa9FyJMJlRgxmh
	9hobCyO5ZrbbZKrg6WMGqHkAqWfFO1zVVr86sW5p83tejyegk+MlMd60xAjduJBJ0BKP7KA0n1l
	JaiYRnpadt6CGkDnFON7A0LdR48JU7QVUVvNH3ZF3tsQ6kkssZPfKLDvVl0wOuFhk1uqnTpoJHj
	n1ytz6cdtwW22uwmobD51i29ip77bi0siS36ky6SYEXqfFSghMu
X-Received: by 2002:a05:6402:52dc:b0:69a:a4cb:2882 with SMTP id 4fb4d7f45d1cf-6a5df6209bdmr6269331a12.9.1787732934557;
        Wed, 26 Aug 2026 01:28:54 -0700 (PDT)
Message-ID: <da410944-fd1d-4309-837d-04d99074c084@suse.com>
Date: Wed, 26 Aug 2026 10:28:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] symbols: also special-case symbols aliasing
 _sinittext
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <bd5ed50e-e537-4033-b5b9-98167886690a@suse.com>
 <fd7dc2f7-6505-42e2-8eaf-fb8e9af21bd4@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <fd7dc2f7-6505-42e2-8eaf-fb8e9af21bd4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787732935-34AC8AE4-19CFB893/0/0
X-purgate-type: clean
X-purgate-size: 1362

On 25.08.2026 16:29, Jan Beulich wrote:
> A recent 4.22 randconfig build job hit a situation where (LIVEPATCH=n,
> i.e. --all-symbols not specified) both __note_gnu_build_id_end and
> _erodata aliased _sinittext on the 1st linking pass, but they didn't on
> the 2nd one. As a result two fewer symbols were emitted on the 2nd pass,
> causing $(call compare-symbol-tables, ...) to fail.
> 
> Extend the existing "corner case" by also considering aliases with
> _sinittext (_stext really shouldn't have anything ahead of it), but
> discard only non-text symbols.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: Re-base over _{s,e}extratext removal. Add const to cast.
> 
> --- a/xen/tools/symbols.c
> +++ b/xen/tools/symbols.c
> @@ -217,6 +217,11 @@ static int symbol_valid(struct sym_entry
>  		if ((s->addr == _etext && strcmp((char*)s->sym + offset, "_etext")) ||
>  		    (s->addr == _einittext && strcmp((char*)s->sym + offset, "_einittext")))
>  			return 0;
> +		/* Same for non-text aliases of _sinittext or _sextratext. */

I've locally dropped this leftover mention of _sextratext.

Jan

> +		if (toupper(*s->sym) != 'T'
> +		    && s->addr == _sinittext
> +		    && strcmp((const char *)s->sym + offset, "_sinittext"))
> +			return 0;
>  	}
>  
>  	/* Exclude symbols which vary between passes. */
> 



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 08:33:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 08:33:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399706.1635692 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz94s-000555-3J; Wed, 26 Aug 2026 08:33:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399706.1635692; Wed, 26 Aug 2026 08:33:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz94s-00054x-06; Wed, 26 Aug 2026 08:33:46 +0000
Received: by outflank-mailman (input) for mailman id 1399706;
 Wed, 26 Aug 2026 08:33:45 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wz94r-00054r-31
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:33:45 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wz94r-006ZIo-0A
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:33:44 +0000
Received: from mail-lf1-f44.google.com ([209.85.167.44])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wz94q-002NKK-2N
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:33:44 +0000
Received: by mail-lf1-f44.google.com with SMTP id
 2adb3069b0e04-5b013084dc2so561459e87.0
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 01:33:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=alVlmarvLODuZpIteA7bAr3edUlSESmByVLnlwcbe7o=; b=zMrjUN93zjb+noBiw2NZxObHqI
	FptXC6SX0ZE/olrrE6T+2/fcP8gtva2rL/+LUxBPxGD0nKMLXGUojYQOCN+illq9LxihERlIdVOug
	uvr3DgwdqDA7CR2ysEW8dHUprTd10Mw+HLAAx8ge3AZaN2TGc5GcUbw5sNHLyHZ0FzHw=;
X-Forwarded-Encrypted: i=1; AHgh+Rq3AaUDnytzPCgKeaNGPWSqDSXw5YaeK9+SlTUyM1cNzpDflMm8ln0QbYzI4VD2Ix22t6fYJwvXEMo=@lists.xenproject.org
X-Gm-Message-State: AFuF++kEtKEz0pvJabkDak+btfoXYLfi7jR+6JfJH+yJE5/Gnn0YBOfR
	TkurJfjwHbY0zFWVPsg8TjXz2X9y3Hbm42IxH7yNwCdsanUaVqWqER/jgEhRxZfQo3n4AnSEvnY
	n5A+jrFIOmM0ACcnKFpPISo+cTLPF/tA=
X-Received: by 2002:a05:6512:23a5:b0:5ae:bfd6:1bc1 with SMTP id
 2adb3069b0e04-5b4a9061a82mr1313370e87.14.1787733223550; Wed, 26 Aug 2026
 01:33:43 -0700 (PDT)
MIME-Version: 1.0
References: <20260420093820.825969-1-julian.vetter@vates.tech>
 <20260420093820.825969-2-julian.vetter@vates.tech> <35a08d22-1e95-4e02-a7e9-7f392ef11722@suse.com>
 <1787667597.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@vates.tech>
In-Reply-To: <1787667597.8631fc262581453bbf619ec5b2062170.1a0394ac7f2000c4f3@vates.tech>
From: George Dunlap <gwd@xenproject.org>
Date: Wed, 26 Aug 2026 09:33:31 +0100
X-Gmail-Original-Message-ID: <CAFLBxZY0_3pF5bgt4uT1e+TChVioTqbb_z5T31rFaK_zB+S10Q@mail.gmail.com>
X-Gm-Features: AcwNN1X-dyat42p5dH2nqpm0Q1NjHhbWoBpEC4D-Df-aV4nk2y7-Pwv7G6iCgws
Message-ID: <CAFLBxZY0_3pF5bgt4uT1e+TChVioTqbb_z5T31rFaK_zB+S10Q@mail.gmail.com>
Subject: Re: [PATCH v6 1/3] ioreq: switch ioreq page allocation to vmap
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Jan Beulich <jbeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Anthony PERARD <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>, 
	Julien Grall <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 25, 2026 at 3:20=E2=80=AFPM Julian Vetter <julian.vetter@vates.=
tech> wrote:
> Thank you again for your feedback! I will wait then for Anthony's
> decision regarding whether the multi-page ioreq support and the ioreq_t
> growth should be combined into a single effort, before I proceed further
> with a v7.

BTW, if we're considering modifying the ioreq server protocol, I have
a few requests to consider from an ASI perspective.

Basically, at the moment, ioreq vcpu rings are grouped by backend; so
each vcpu shares a ring with all other vcpus; meaning that, in theory,
one vcpu could read the payload of another vcpu's IO operations.  This
isn't critical, but the more isolation the better.

What would be more convenient from an ASI perspective would be to have
per-vcpu data shared on separate pages.  One design would be to have a
single ioreq page per vcpu, with all ioreq server rings on the single
page.  What would perhaps be nicer long-term is to figure out a way
for all per-vcpu shared structures to share a single page (or set of
pages).

Not sure how this fits with the ioreq_t growth or multi-page ioreq
support, but thought it would be worthwhile to toss out there for
consideration:  At least to make ioreq page isolation less difficult,
and perhaps to make it easier.

 -George


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 08:55:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 08:55:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399714.1635701 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz9Pa-00087M-N2; Wed, 26 Aug 2026 08:55:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399714.1635701; Wed, 26 Aug 2026 08:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz9Pa-00087F-KD; Wed, 26 Aug 2026 08:55:10 +0000
Received: by outflank-mailman (input) for mailman id 1399714;
 Wed, 26 Aug 2026 08:55:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <berrange@redhat.com>) id 1wz9PZ-000873-2A
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 08:55:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz9PX-007OvW-KL
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 10:55:07 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8ea9df-8faa-0a2a0a5109dd-0a2a45039898-32
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 10:55:07 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8ea9ea-fae8-0a2a45030019-aa0a817cc461-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 10:55:07 +0200
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-473-t03T1JrFMG6NkCjYtxZrkg-1; Wed,
 26 Aug 2026 04:55:01 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 088181954ADD; Wed, 26 Aug 2026 08:54:53 +0000 (UTC)
Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 25B3B1803A44; Wed, 26 Aug 2026 08:54:36 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787734505;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=QcEyEJ2C65GQ7/5bh8oNJgVP3iQUPaFAtGbhQuIC7mw=;
	b=OYASRYLZ7lzZJDqANKpQ+nkHAuVQaOtpG9Iq10lvlGgkaKnTs3R99WEs1CtLf9QF1G+bkd
	tnmRmOi9Qz3jKSdWOALkFhmEqoqdE/Cp/s+ocQ/T3WxoqBLD5xSj9vnJdFyy4XO14J70b7
	lIsqKHQ8aUk09GHEqiXi6fVBoFhmI6I=
X-MC-Unique: t03T1JrFMG6NkCjYtxZrkg-1
X-Mimecast-MFC-AGG-ID: t03T1JrFMG6NkCjYtxZrkg_1787734496
Date: Wed, 26 Aug 2026 09:54:34 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org, dave@treblig.org,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@mailo.com>,
	Markus Armbruster <armbru@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
	Ani Sinha <anisinha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
	Brian Cain <brian.cain@oss.qualcomm.com>,
	David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	David Hildenbrand <david@kernel.org>,
	Cornelia Huck <cohuck@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Hyman Huang <infra.ai.cloud@bitdeer.com>,
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>,
	Chinmay Rath <rathc@linux.ibm.com>,
	Glenn Miles <milesg@linux.ibm.com>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Weiwei Li <liwei1518@gmail.com>,
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
	Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
	Chao Liu <chao.liu@processmission.com>,
	Yoshinori Sato <yoshinori.sato@nifty.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org,
	kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
Subject: Re: [PATCH v4 36/49] monitor: tighten monitor_printf*()
Message-ID: <ao6pyiBkHZJz_9JR@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com>
MIME-Version: 1.0
In-Reply-To: <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com>
User-Agent: Mutt/2.4.0 (2026-06-19)
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: 8JdZlk036ZZ-6_z1m1Kj25tebBlxAA-RA1S6CNEqKhA_1787734496
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787734507-778F24E9-5BA6C851/0/0
X-purgate-type: clean
X-purgate-size: 6168

On Tue, Aug 25, 2026 at 11:09:43PM +0400, Marc-André Lureau wrote:
> Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> the first parameter from Monitor * to MonitorHMP * to enforce type
> safety. The implementation is also simplified: monitor_hmp_vprintf now
> directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> dispatch via moncls->vprintf.
> 
> The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> cast, they are fixed in the following commits.
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  audio/audio-hmp-cmds.c                  |   6 +-
>  backends/cryptodev-hmp-cmds.c           |   9 +-
>  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
>  chardev/char-hmp-cmds.c                 |  12 +-
>  disas/disas-mon.c                       |  10 +-
>  docs/devel/style.rst                    |   2 +-
>  docs/devel/writing-monitor-commands.rst |   8 +-
>  dump/dump-hmp-cmds.c                    |   5 +-
>  hw/char/virtio-serial-bus.c             |  10 +-
>  hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
>  hw/core/sysbus.c                        |   5 +-
>  hw/hexagon/hexagon_tlb.c                |  44 ++---
>  hw/i386/kvm/xen-stubs.c                 |   6 +-
>  hw/i386/kvm/xen_evtchn.c                |  21 +--
>  hw/i386/sgx-hmp-stub.c                  |   3 +-
>  hw/i386/sgx.c                           |  29 ++-
>  hw/misc/auxbus.c                        |   9 +-
>  hw/misc/mos6522-stub.c                  |   3 +-
>  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
>  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
>  hw/pci/pci-stub.c                       |   3 +-
>  hw/s390x/s390-skeys.c                   |   9 +-
>  hw/s390x/s390-stattrib.c                |  20 +--
>  hw/uefi/ovmf-log.c                      |   5 +-
>  hw/usb/bus.c                            |  11 +-
>  hw/usb/host-libusb.c                    |  21 ++-
>  hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++---------------
>  hw/xen/xen-bus.c                        |   5 +-
>  include/disas/disas.h                   |   4 +-
>  include/monitor/hmp.h                   |  12 +-
>  migration/dirtyrate.c                   |  46 +++--
>  migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----------------
>  monitor/hmp-cmds.c                      | 141 +++++++--------
>  monitor/hmp.c                           | 143 +++++++--------
>  monitor/monitor-internal.h              |   6 -
>  monitor/monitor.c                       |  33 ++--
>  net/net-hmp-cmds.c                      |  31 ++--
>  net/slirp.c                             |  31 ++--
>  qom/qom-hmp-cmds.c                      |  27 ++-
>  replay/replay-debugging.c               |   5 +-
>  stats/stats-hmp-cmds.c                  |  57 +++---
>  stubs/hmp-cmd-info_sev.c                |   3 +-
>  stubs/monitor-core.c                    |   2 +-
>  system/dirtylimit-hmp-cmds.c            |  10 +-
>  system/qdev-monitor.c                   |  19 +-
>  system/runstate-hmp-cmds.c              |  16 +-
>  system/tpm-hmp-cmds.c                   |  29 ++-
>  target/i386/cpu-apic.c                  |   3 +-
>  target/i386/monitor.c                   | 152 ++++++++--------
>  target/i386/sev.c                       |  35 ++--
>  target/m68k/monitor.c                   |   3 +-
>  target/ppc/monitor.c                    |   3 +-
>  target/riscv/monitor.c                  |  55 +++---
>  target/sh4/monitor.c                    |  29 ++-
>  target/sparc/monitor.c                  |   3 +-
>  target/xtensa/monitor.c                 |   3 +-
>  tests/unit/test-util-sockets.c          |   2 +-
>  tools/qemu-vnc/clipboard.c              |   4 +-
>  tools/qemu-vnc/stubs.c                  |   2 +-
>  trace/trace-hmp-cmds.c                  |  12 +-
>  ui/ui-hmp-cmds.c                        | 115 ++++++------
>  util/error-report.c                     |   2 +-
>  util/qemu-print.c                       |  11 +-
>  63 files changed, 1219 insertions(+), 1327 deletions(-)




> diff --git a/util/qemu-print.c b/util/qemu-print.c
> index 5d4143d425a1..5938f2b6c338 100644
> --- a/util/qemu-print.c
> +++ b/util/qemu-print.c
> @@ -13,6 +13,7 @@
>  #include "qemu/osdep.h"
>  #include "monitor/monitor.h"
>  #include "monitor/hmp.h"
> +#include "qom/object.h"
>  #include "qemu/qemu-print.h"
>  
>  /*
> @@ -23,8 +24,13 @@
>  int qemu_vprintf(const char *fmt, va_list ap)
>  {
>      Monitor *cur_mon = monitor_cur();
> +
> +    /* for all monitors: QMP & HMP */
>      if (cur_mon) {
> -        return monitor_vprintf(cur_mon, fmt, ap);
> +        /* don't use monitor_cur_hmp(), to avoid a second lookup */
> +        MonitorHMP *hmp = (MonitorHMP *)
> +            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP);
> +        return monitor_hmp_vprintf(hmp, fmt, ap);

This isn't the same semantics AFAICT.

Original code, if monitor_cur() == QMP, we call monitor_vprintf()
which will return -1.

New code, if monitor_cur() == QMP, we will get a NULL back from
object_dynamic_cast which we then pass into monitor_hmp_vprintf
which will then crash on monitor_puts() IIUC.

>      }
>      return vprintf(fmt, ap);
>  }
> @@ -55,7 +61,8 @@ int qemu_printf(const char *fmt, ...)
>  int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
>  {
>      if (!stream) {
> -        return monitor_vprintf(monitor_cur(), fmt, ap);
> +        MonitorHMP *hmp = monitor_cur_hmp();
> +        return monitor_hmp_vprintf(hmp, fmt, ap);

Same, this should crash on QMP now IIUC.

>      }
>      return vfprintf(stream, fmt, ap);
>  }
> 
> -- 
> 2.55.0.543.g5ebe2ebe4ea8
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 09:04:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 09:04:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399725.1635710 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz9YO-0001P1-L6; Wed, 26 Aug 2026 09:04:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399725.1635710; Wed, 26 Aug 2026 09:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wz9YO-0001Ou-Hu; Wed, 26 Aug 2026 09:04:16 +0000
Received: by outflank-mailman (input) for mailman id 1399725;
 Wed, 26 Aug 2026 09:04:15 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <berrange@redhat.com>) id 1wz9YN-0001Oo-6f
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 09:04:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wz9YM-00CX3E-10
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 11:04:14 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8eac0a-8faa-0a2a0a5109dd-0a2a450bb008-16
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 11:04:13 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8eac0b-b7e8-0a2a450b0019-aa0a857c8077-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 11:04:12 +0200
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-658-VIg-u96BNVaDP5wBPRPqIA-1; Wed,
 26 Aug 2026 05:04:07 -0400
Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id EBEFE1953996; Wed, 26 Aug 2026 09:04:05 +0000 (UTC)
Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 79316195422E; Wed, 26 Aug 2026 09:04:02 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787735051;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=dMUx3CkXN0hFHp2GTyMbE3ZjLMT8j6sNqup++Lhq3UU=;
	b=DMzUEC32KF1svLL/+Zkv6ua3yga8r5+NnHKEeExu4nP/f4NYh/SbYV/sJJl6Bf8EEI0Mfr
	h+CH/WTqEtdvTOVUnlibRCB9LmsK3yMAD21LbbZS0+RLaqHgKnIUeRH6pZNbeUIRxVYBPo
	2uVdhw5SJXGSW5ng+JMyTLwWS+N75a4=
X-MC-Unique: VIg-u96BNVaDP5wBPRPqIA-1
X-Mimecast-MFC-AGG-ID: VIg-u96BNVaDP5wBPRPqIA_1787735046
Date: Wed, 26 Aug 2026 10:03:59 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org, dave@treblig.org,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@mailo.com>,
	Markus Armbruster <armbru@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 42/49] hw: guard BusClass::print_dev with CONFIG_HMP
Message-ID: <ao6r_y3LVtdhCnLj@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-42-af60857c2fbe@redhat.com>
MIME-Version: 1.0
In-Reply-To: <20260825-qemu-no-hmp-v4-42-af60857c2fbe@redhat.com>
User-Agent: Mutt/2.4.0 (2026-06-19)
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17
X-Mimecast-MFC-PROC-ID: W7hrufOA-hhfotAyZ14bLbxmSW9vpn-gwWSKgAt9mNk_1787735046
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787735052-19AC09EA-DBBDEE38/0/0
X-purgate-type: clean
X-purgate-size: 1009

On Tue, Aug 25, 2026 at 11:09:49PM +0400, Marc-André Lureau wrote:
> The print_dev callback is only used by HMP 'info qtree'. Guard the field
> in BusClass, all implementations, and the caller with CONFIG_HMP.
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  hw/char/virtio-serial-bus.c |  6 ++++++
>  hw/core/sysbus.c            |  6 ++++++
>  hw/misc/auxbus.c            | 16 +++++++++++-----
>  hw/pci/pci-hmp-cmds.c       |  2 ++
>  hw/pci/pci.c                |  2 ++
>  hw/usb/bus.c                |  6 ++++++
>  hw/xen/xen-bus.c            |  4 ++++
>  include/hw/core/qdev.h      |  2 ++
>  8 files changed, 39 insertions(+), 5 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 09:42:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 09:42:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399757.1635735 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzA96-0007JT-Hm; Wed, 26 Aug 2026 09:42:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399757.1635735; Wed, 26 Aug 2026 09:42:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzA96-0007JM-EU; Wed, 26 Aug 2026 09:42:12 +0000
Received: by outflank-mailman (input) for mailman id 1399757;
 Wed, 26 Aug 2026 09:42:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzA94-0007JG-Nw
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 09:42:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzA94-00Cfk4-0f
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 11:42:10 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8eb4f0-2eae-0a2a0a5409dd-0a2a450be5ee-2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 11:42:09 +0200
Received: from [209.85.208.44] (helo=mail-ed1-f44.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8eb4f1-b7e8-0a2a450b0019-d155d02cd05f-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 11:42:09 +0200
Received: by mail-ed1-f44.google.com with SMTP id
 4fb4d7f45d1cf-6a1542cdb53so839181a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 02:42:09 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5deae9a75sm3007795a12.28.2026.08.26.02.42.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 02:42:08 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787737329; x=1788342129; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0L1OoA+cy53hgMy4ifmRPpFL/hiiCmBpvNWDGhfyJu0=;
        b=GAo/L2xhXvS1TQVKRYdZt+ilEtggBDJD1XsmSDtH65NJGxRvFDI0IY602uuirTf1Z4
         d8YI5KLkDeP9RoQNKa7UJLBcmYIZgMjCmvrMpSX7WXuCJ0Zl/aNk/v8up5B1aQ0UFRfH
         35n6W6nS4AO4kar+Hy3yT3qBuQOyvYM2SW7CCpxO5IUSq3o0V/4OvxQ107W8b/dawTAO
         /hahRHfBtfdsYp6jKafww/iEDMS9Ipa7V7h5CM9LCFNF7e/VhukY5kjBQ0VvCc8O99LW
         8wACxHL7Tw3zCK/Xyk6EbAaiYU0Eofkml5lUtBYyu2dbw5vVddw2/GRB7gyWmICRDwXb
         rMww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787737329; x=1788342129;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=0L1OoA+cy53hgMy4ifmRPpFL/hiiCmBpvNWDGhfyJu0=;
        b=tTlYM9eV3PBiEY8UsOnMlN9OCY2RMqaguwcD/4RrX9zRm/KZ381JSYVUq4XoZHnseO
         c5fOZ1DGzlHqSbOASvqGpxmy3sFMu57ZC3ndcSyJoI9CAXx/GbEeYRQcuvSdcJAnYG8y
         AYiC9ZNIn14Q7BpH6niA0UBuRrffby+9yuH9Ahb60LQmPzk1kxO2EF0k0MbnowCZlQpe
         8ism/fjbeagIhX9DBOiyXdKoRRsKYQgjQBx1T/Y7On/TvzeE4JU0937u0l/DvZHHqpBO
         FBXpMdV4Cc9m4MiWE/d9NbFfYgoLjSnUgqDFTsNfCczIePfBW4Y7dyzv5wNuZtIn3jd+
         BAhg==
X-Forwarded-Encrypted: i=1; AHgh+RrURAnTlzsXvbdwtrtegAUjK7gr4eH6opBOdjEJrXt6zgRLb1UytxKvzao6A6v1kTHdbV+G/IgV3HM=@lists.xenproject.org
X-Gm-Message-State: AFuF++kVmFNB24aZwr4wt+fmEKmtMRfUDobjqRtqyugzdhbCzMhP3/d9
	DZFFxDg5tXypNIkPqh8g1VV/oxKAvnYSySqrVeSWqv76lkio3fldfrrTHptw+oIDQg==
X-Gm-Gg: AR+sD12UNiMoGrliznmIYTmplrXkQt4AK91ofKXPmyScfpDULSfbovU27zkqr2SpqVw
	AYnvjnmdoacxvWZ+x6u8EBfZczYDctQtxdsALiaKkFr/O3zYu+rSMPv19tSrBzsxSazzimU9hl9
	wbe8zVCBOy/dYDqDrIfCC3mpH3q4Q0+ZujDZYolJhEkkunbga7RaJjhz2SV2fa0XjRDzLnHVb0Z
	kG2rf7Ik8YvdZIDwzr+ul7WYa9LtMOCwNdhB9dzXlToMogHrwgPB37IVj/r9Pl7CPy1+JWp8/3q
	5eFSKOdTYiKPfuypK5svlJNOeNUDBZv118piZLim0Hz5+rzSDAmkfHIFLY5CRpHe7j8eXM9v5z0
	i4xoYghFDaGn3xd3w9993zIDaNrOFHqvUaWX8OlmOXKULLqxCsqFvRxibgX8QlfspSSwjoANxoF
	vYIsq/piFgQCuzBSaPewobYRCouf6Ti0NjR5fjeddVyGdcuUHoFEmtEwYV3nPSXot5H4K9A4dvV
	Y+UMjy6b94rLv/NJtqckQEE0VnIcxlPlu5Ee4+o8RNdXCSaTH9h
X-Received: by 2002:a05:6402:458a:b0:698:6084:db7f with SMTP id 4fb4d7f45d1cf-6a5df62b3b2mr8080449a12.10.1787737329389;
        Wed, 26 Aug 2026 02:42:09 -0700 (PDT)
Message-ID: <2aa33f72-8577-4eed-98d2-099b0ced2cb7@suse.com>
Date: Wed, 26 Aug 2026 11:42:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/cpuid: gate the hypervisor PV-only leaf on
 is_pv_domain()
To: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
Cc: Teddy Astie <teddy.astie@vates.tech>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 xen-devel@lists.xenproject.org
References: <20260826072526.767424-1-Zhao.Jiaqing@amd.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <20260826072526.767424-1-Zhao.Jiaqing@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787737329-ABED69EA-D9F24F0D/0/0
X-purgate-type: clean
X-purgate-size: 442

On 26.08.2026 09:25, Jiaqing Zhao wrote:
> Hypervisor leaf 5 is PV-specific, but is gated with !is_hvm_domain(),
> which stays a runtime test in a build without PV support. Test for a
> PV domain directly so the compiler can discard the leaf when
> CONFIG_PV is disabled.
> 
> Suggested-by: Roger Pau Monné <roger@xenproject.org>
> Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@amd.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 09:42:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 09:42:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399758.1635744 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzA9A-0007WE-Nm; Wed, 26 Aug 2026 09:42:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399758.1635744; Wed, 26 Aug 2026 09:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzA9A-0007W7-Kj; Wed, 26 Aug 2026 09:42:16 +0000
Received: by outflank-mailman (input) for mailman id 1399758;
 Wed, 26 Aug 2026 09:42:15 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mlureau@redhat.com>) id 1wzA99-0007Vj-8i
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 09:42:15 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzA97-00BUrd-El
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 11:42:13 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mlureau@redhat.com>)
 id 6a8eb4f4-e002-0a2a0a5209dd-0a2a450aca08-2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 11:42:13 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mlureau@redhat.com>)
 id 6a8eb4f4-f2d2-0a2a450a0019-aa0a857cb9f1-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 11:42:13 +0200
Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com
 [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-172-BYEdn3DRMtaF2x2TrpJcXA-1; Wed, 26 Aug 2026 05:42:09 -0400
Received: by mail-pg1-f198.google.com with SMTP id
 41be03b00d2f7-cc132709c76so1307930a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 02:42:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787737331;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=cSRhiRnZLNoz4j1O+xumJH2wghFBy7JpPCbRlPFYp/4=;
	b=BE5lLIv9tN0kJDqudX7h8Of/0pOWavxJFmqxcQ0N+1wmLCfwHlYMD17+CYbxMf/kl4vJre
	LmEx8JqYrw3nBBeuVTkSar+fJHF+U9qF1MYYSFqtn9RwTxgS/vJvsJi9pFEuYRJnIC3Csa
	rt2wC9jilS6ifBEpfcqhlsCFcr72YTs=
X-MC-Unique: BYEdn3DRMtaF2x2TrpJcXA-1
X-Mimecast-MFC-AGG-ID: BYEdn3DRMtaF2x2TrpJcXA_1787737328
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787737328; x=1788342128;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cSRhiRnZLNoz4j1O+xumJH2wghFBy7JpPCbRlPFYp/4=;
        b=iZFcHZaEe0yhXR8NM0UarjiSzRtNS9Xi6MszlYK7EqOs5TzCsHg0ntk50krE9hpAFr
         uYDESj2QUxEXgvWTqz2TVR+vR8jAe81qVsct9CRq2tjdANs4kJcy9WVdgxxKoe70PXxa
         uL4LEWjnV8kJZNsYZcgRSMkKot8AK8x66Z0bi/5FOEL0pYrM+01SzYpLsrI3idovhxef
         +kts6MLRET1E5rGnnqc7WCjQnJOnH7y3wvTolnXgupol036RaUqAaRRWxTWLy2HMKq1B
         tIwwdfthV9Ux3sq/rU+XJ48+MzxjFWYgKsq2V31h9wQmC8qqa7sIkJlpFgDLjLaFefnI
         LBqg==
X-Forwarded-Encrypted: i=1; AHgh+RpP92P1SIfV6OOtdr6yHOpsITKS6f/LZpqQGA3I5ksTG4lx2KnyRDXpUSwup5CdbC/juEki99gmKG4=@lists.xenproject.org
X-Gm-Message-State: AFuF++misSmlUbmKJU+wfihHxnq9YKvT9h+BNR1y0R70nGoGAyc6B/VP
	iGXASOUmnSpy1PlnQYZ86p+xbReih4Sud7w/PWrGOiX33+VJr55QlqR1ihP7JNuNn+wC5hE7MW8
	7xKj71W93opa5boVoRihnQRCa5SvXl1LC19TEsADAsrsG+tjFsB/ZPkpmysKGI/MRWmprwrf+a1
	BiSufkE0/CYYM3HhxfeAtU57TrZ/4FZPkLvHzSU375vM0=
X-Gm-Gg: AR+sD13wy2NYe/q577JlInXZsPihhAPDB5ty8soaZQ1D8317A86MapEEk3wa+b4ef1j
	HnjUex6xjWDiDQvQBuVVF23B5AU9V81/AE3LV5GR1HuUAFTVoYVplXAzJm1XETTR5u4Am1NrhsU
	qrDZ/CsjkBMKojfgDqpy5pt9B3iHy0Dwm6NcapSrKbOxOs++LsMaz8VtVouQguSse1du8x/zg3q
	p86hvXElnqLn76GViATAa2bKENKx8LV2Xat00+sLi+m6AtIbq5qEOlMYBk5CjsvBCdg8a3RWSun
	YQ==
X-Received: by 2002:a05:6a20:2584:b0:3cc:8344:1213 with SMTP id adf61e73a8af0-3cf83531791mr9386642637.8.1787737328152;
        Wed, 26 Aug 2026 02:42:08 -0700 (PDT)
X-Received: by 2002:a05:6a20:2584:b0:3cc:8344:1213 with SMTP id
 adf61e73a8af0-3cf83531791mr9386473637.8.1787737327525; Wed, 26 Aug 2026
 02:42:07 -0700 (PDT)
MIME-Version: 1.0
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com> <ao6pyiBkHZJz_9JR@redhat.com>
In-Reply-To: <ao6pyiBkHZJz_9JR@redhat.com>
From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= <marcandre.lureau@redhat.com>
Date: Wed, 26 Aug 2026 13:41:55 +0400
X-Gm-Features: AcwNN1UW47qL6Xcco1r65R6n9lM9Iv0EQgjkA8oE2IKKhKY4fAQjALpMF87caYU
Message-ID: <CAMxuvaz+85Pw=sZG2jXL5jJ_2=kkR5_P69-AZ6bzhVbGTA+5Xg@mail.gmail.com>
Subject: Re: [PATCH v4 36/49] monitor: tighten monitor_printf*()
To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, dave@treblig.org, 
	=?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= <philmd@mailo.com>, 
	Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, 
	"Gonglei (Arei)" <arei.gonglei@huawei.com>, zhenwei pi <zhenwei.pi@linux.dev>, 
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>, 
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, Ani Sinha <anisinha@redhat.com>, 
	"Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
	Brian Cain <brian.cain@oss.qualcomm.com>, David Woodhouse <dwmw2@infradead.org>, 
	Paul Durrant <paul@xen.org>, Richard Henderson <richard.henderson@linaro.org>, 
	Marcelo Tosatti <mtosatti@redhat.com>, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, 
	Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>, 
	Halil Pasic <pasic@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, 
	Jason Herne <jjherne@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, 
	Matthew Rosato <mjrosato@linux.ibm.com>, Ilya Leoshkevich <iii@linux.ibm.com>, 
	David Hildenbrand <david@kernel.org>, Cornelia Huck <cohuck@redhat.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD <anthony@xenproject.org>, 
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Hyman Huang <infra.ai.cloud@bitdeer.com>, 
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>, 
	Samuel Thibault <samuel.thibault@ens-lyon.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>, 
	Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>, 
	Chinmay Rath <rathc@linux.ibm.com>, Glenn Miles <milesg@linux.ibm.com>, 
	Harsh Prateek Bora <harshpb@linux.ibm.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Alistair Francis <alistair.francis@wdc.com>, Weiwei Li <liwei1518@gmail.com>, 
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
	Chao Liu <chao.liu@processmission.com>, Yoshinori Sato <yoshinori.sato@nifty.com>, 
	Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, kvm@vger.kernel.org, 
	qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, 
	qemu-riscv@nongnu.org
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: _-_nXBBwZ-BAl_PppTmh1o0BoGqsliRyHMfRoiQGWqU_1787737328
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-4011c0/1787737333-59DDFCFC-4E84E677/0/0
X-purgate-type: clean
X-purgate-size: 6660

Hi

On Wed, Aug 26, 2026 at 12:54=E2=80=AFPM Daniel P. Berrang=C3=A9 <berrange@=
redhat.com> wrote:
>
> On Tue, Aug 25, 2026 at 11:09:43PM +0400, Marc-Andr=C3=A9 Lureau wrote:
> > Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> > monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> > the first parameter from Monitor * to MonitorHMP * to enforce type
> > safety. The implementation is also simplified: monitor_hmp_vprintf now
> > directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> > dispatch via moncls->vprintf.
> >
> > The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> > cast, they are fixed in the following commits.
> >
> > Signed-off-by: Marc-Andr=C3=A9 Lureau <marcandre.lureau@redhat.com>
> > ---
> >  audio/audio-hmp-cmds.c                  |   6 +-
> >  backends/cryptodev-hmp-cmds.c           |   9 +-
> >  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
> >  chardev/char-hmp-cmds.c                 |  12 +-
> >  disas/disas-mon.c                       |  10 +-
> >  docs/devel/style.rst                    |   2 +-
> >  docs/devel/writing-monitor-commands.rst |   8 +-
> >  dump/dump-hmp-cmds.c                    |   5 +-
> >  hw/char/virtio-serial-bus.c             |  10 +-
> >  hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
> >  hw/core/sysbus.c                        |   5 +-
> >  hw/hexagon/hexagon_tlb.c                |  44 ++---
> >  hw/i386/kvm/xen-stubs.c                 |   6 +-
> >  hw/i386/kvm/xen_evtchn.c                |  21 +--
> >  hw/i386/sgx-hmp-stub.c                  |   3 +-
> >  hw/i386/sgx.c                           |  29 ++-
> >  hw/misc/auxbus.c                        |   9 +-
> >  hw/misc/mos6522-stub.c                  |   3 +-
> >  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
> >  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
> >  hw/pci/pci-stub.c                       |   3 +-
> >  hw/s390x/s390-skeys.c                   |   9 +-
> >  hw/s390x/s390-stattrib.c                |  20 +--
> >  hw/uefi/ovmf-log.c                      |   5 +-
> >  hw/usb/bus.c                            |  11 +-
> >  hw/usb/host-libusb.c                    |  21 ++-
> >  hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++--------=
-------
> >  hw/xen/xen-bus.c                        |   5 +-
> >  include/disas/disas.h                   |   4 +-
> >  include/monitor/hmp.h                   |  12 +-
> >  migration/dirtyrate.c                   |  46 +++--
> >  migration/migration-hmp-cmds.c          | 301 ++++++++++++++++--------=
--------
> >  monitor/hmp-cmds.c                      | 141 +++++++--------
> >  monitor/hmp.c                           | 143 +++++++--------
> >  monitor/monitor-internal.h              |   6 -
> >  monitor/monitor.c                       |  33 ++--
> >  net/net-hmp-cmds.c                      |  31 ++--
> >  net/slirp.c                             |  31 ++--
> >  qom/qom-hmp-cmds.c                      |  27 ++-
> >  replay/replay-debugging.c               |   5 +-
> >  stats/stats-hmp-cmds.c                  |  57 +++---
> >  stubs/hmp-cmd-info_sev.c                |   3 +-
> >  stubs/monitor-core.c                    |   2 +-
> >  system/dirtylimit-hmp-cmds.c            |  10 +-
> >  system/qdev-monitor.c                   |  19 +-
> >  system/runstate-hmp-cmds.c              |  16 +-
> >  system/tpm-hmp-cmds.c                   |  29 ++-
> >  target/i386/cpu-apic.c                  |   3 +-
> >  target/i386/monitor.c                   | 152 ++++++++--------
> >  target/i386/sev.c                       |  35 ++--
> >  target/m68k/monitor.c                   |   3 +-
> >  target/ppc/monitor.c                    |   3 +-
> >  target/riscv/monitor.c                  |  55 +++---
> >  target/sh4/monitor.c                    |  29 ++-
> >  target/sparc/monitor.c                  |   3 +-
> >  target/xtensa/monitor.c                 |   3 +-
> >  tests/unit/test-util-sockets.c          |   2 +-
> >  tools/qemu-vnc/clipboard.c              |   4 +-
> >  tools/qemu-vnc/stubs.c                  |   2 +-
> >  trace/trace-hmp-cmds.c                  |  12 +-
> >  ui/ui-hmp-cmds.c                        | 115 ++++++------
> >  util/error-report.c                     |   2 +-
> >  util/qemu-print.c                       |  11 +-
> >  63 files changed, 1219 insertions(+), 1327 deletions(-)
>
>
>
>
> > diff --git a/util/qemu-print.c b/util/qemu-print.c
> > index 5d4143d425a1..5938f2b6c338 100644
> > --- a/util/qemu-print.c
> > +++ b/util/qemu-print.c
> > @@ -13,6 +13,7 @@
> >  #include "qemu/osdep.h"
> >  #include "monitor/monitor.h"
> >  #include "monitor/hmp.h"
> > +#include "qom/object.h"
> >  #include "qemu/qemu-print.h"
> >
> >  /*
> > @@ -23,8 +24,13 @@
> >  int qemu_vprintf(const char *fmt, va_list ap)
> >  {
> >      Monitor *cur_mon =3D monitor_cur();
> > +
> > +    /* for all monitors: QMP & HMP */
> >      if (cur_mon) {
> > -        return monitor_vprintf(cur_mon, fmt, ap);
> > +        /* don't use monitor_cur_hmp(), to avoid a second lookup */
> > +        MonitorHMP *hmp =3D (MonitorHMP *)
> > +            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP);
> > +        return monitor_hmp_vprintf(hmp, fmt, ap);
>
> This isn't the same semantics AFAICT.
>
> Original code, if monitor_cur() =3D=3D QMP, we call monitor_vprintf()
> which will return -1.
>
> New code, if monitor_cur() =3D=3D QMP, we will get a NULL back from
> object_dynamic_cast which we then pass into monitor_hmp_vprintf
> which will then crash on monitor_puts() IIUC.

monitor_hmp_vprintf() has an early return, if given NULL monitor, it return=
s -1.

>
> >      }
> >      return vprintf(fmt, ap);
> >  }
> > @@ -55,7 +61,8 @@ int qemu_printf(const char *fmt, ...)
> >  int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
> >  {
> >      if (!stream) {
> > -        return monitor_vprintf(monitor_cur(), fmt, ap);
> > +        MonitorHMP *hmp =3D monitor_cur_hmp();
> > +        return monitor_hmp_vprintf(hmp, fmt, ap);
>
> Same, this should crash on QMP now IIUC.
>
> >      }
> >      return vfprintf(stream, fmt, ap);
> >  }
> >
> > --
> > 2.55.0.543.g5ebe2ebe4ea8
> >
>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 10:04:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 10:04:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399776.1635761 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzAUV-0002aE-Gs; Wed, 26 Aug 2026 10:04:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399776.1635761; Wed, 26 Aug 2026 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzAUV-0002a7-DC; Wed, 26 Aug 2026 10:04:19 +0000
Received: by outflank-mailman (input) for mailman id 1399776;
 Wed, 26 Aug 2026 10:04:18 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <berrange@redhat.com>) id 1wzAUT-0002a1-Tz
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 10:04:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzAUS-00GnVh-P9
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:04:16 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8eba13-bab6-0a2a0a5309dd-0a2a45018c9c-32
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 12:04:12 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <berrange@redhat.com>)
 id 6a8eba1b-5984-0a2a45010019-aa0a857c5e23-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 12:04:12 +0200
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-528-hzOFc47gMD27ZIlhwAbX6w-1; Wed,
 26 Aug 2026 06:04:07 -0400
Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 10553190FFB4; Wed, 26 Aug 2026 10:04:00 +0000 (UTC)
Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 58E0440E; Wed, 26 Aug 2026 10:03:43 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787738651;
	h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=yA81iAgWN+lZLxuNDfTXoR2CGhanHz154Xrqq+MkBZU=;
	b=bRRAi2djJ9LsMMfaLmwslh1CO/8xEij+GFJ2DP4b/qe3H3ELIgNNtNbbYqw7PS0uvO80d8
	hoI4UFVn2HXBaiSGLKqj+DW6Cq4rySoKYfNHHgtTpKMJF9Pi2iXSj76gIXWdzAUO4tj8st
	7x4UTRGHS7fWeiCxR3Mbo/ALOnBgHno=
X-MC-Unique: hzOFc47gMD27ZIlhwAbX6w-1
X-Mimecast-MFC-AGG-ID: hzOFc47gMD27ZIlhwAbX6w_1787738641
Date: Wed, 26 Aug 2026 11:03:41 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org, dave@treblig.org,
	Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= <philmd@mailo.com>,
	Markus Armbruster <armbru@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>,
	Hanna Reitz <hreitz@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>,
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
	Ani Sinha <anisinha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
	Brian Cain <brian.cain@oss.qualcomm.com>,
	David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Jason Herne <jjherne@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	David Hildenbrand <david@kernel.org>,
	Cornelia Huck <cohuck@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony@xenproject.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Hyman Huang <infra.ai.cloud@bitdeer.com>,
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>,
	Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>,
	Chinmay Rath <rathc@linux.ibm.com>,
	Glenn Miles <milesg@linux.ibm.com>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Weiwei Li <liwei1518@gmail.com>,
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
	Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
	Chao Liu <chao.liu@processmission.com>,
	Yoshinori Sato <yoshinori.sato@nifty.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org,
	kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org,
	xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
Subject: Re: [PATCH v4 36/49] monitor: tighten monitor_printf*()
Message-ID: <ao65_XCKmkpm9s2F@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com>
 <ao6pyiBkHZJz_9JR@redhat.com>
 <CAMxuvaz+85Pw=sZG2jXL5jJ_2=kkR5_P69-AZ6bzhVbGTA+5Xg@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAMxuvaz+85Pw=sZG2jXL5jJ_2=kkR5_P69-AZ6bzhVbGTA+5Xg@mail.gmail.com>
User-Agent: Mutt/2.4.0 (2026-06-19)
X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95
X-Mimecast-MFC-PROC-ID: o2FWTm0jkmXCfVlj-Dscpxj_C-V2Ch-Jjn2Ce2OiMC0_1787738641
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787738652-1DC79757-E465F955/0/0
X-purgate-type: clean
X-purgate-size: 6542

On Wed, Aug 26, 2026 at 01:41:55PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Aug 26, 2026 at 12:54 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Tue, Aug 25, 2026 at 11:09:43PM +0400, Marc-André Lureau wrote:
> > > Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> > > monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> > > the first parameter from Monitor * to MonitorHMP * to enforce type
> > > safety. The implementation is also simplified: monitor_hmp_vprintf now
> > > directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> > > dispatch via moncls->vprintf.
> > >
> > > The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> > > cast, they are fixed in the following commits.
> > >
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > ---
> > >  audio/audio-hmp-cmds.c                  |   6 +-
> > >  backends/cryptodev-hmp-cmds.c           |   9 +-
> > >  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
> > >  chardev/char-hmp-cmds.c                 |  12 +-
> > >  disas/disas-mon.c                       |  10 +-
> > >  docs/devel/style.rst                    |   2 +-
> > >  docs/devel/writing-monitor-commands.rst |   8 +-
> > >  dump/dump-hmp-cmds.c                    |   5 +-
> > >  hw/char/virtio-serial-bus.c             |  10 +-
> > >  hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
> > >  hw/core/sysbus.c                        |   5 +-
> > >  hw/hexagon/hexagon_tlb.c                |  44 ++---
> > >  hw/i386/kvm/xen-stubs.c                 |   6 +-
> > >  hw/i386/kvm/xen_evtchn.c                |  21 +--
> > >  hw/i386/sgx-hmp-stub.c                  |   3 +-
> > >  hw/i386/sgx.c                           |  29 ++-
> > >  hw/misc/auxbus.c                        |   9 +-
> > >  hw/misc/mos6522-stub.c                  |   3 +-
> > >  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
> > >  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
> > >  hw/pci/pci-stub.c                       |   3 +-
> > >  hw/s390x/s390-skeys.c                   |   9 +-
> > >  hw/s390x/s390-stattrib.c                |  20 +--
> > >  hw/uefi/ovmf-log.c                      |   5 +-
> > >  hw/usb/bus.c                            |  11 +-
> > >  hw/usb/host-libusb.c                    |  21 ++-
> > >  hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++---------------
> > >  hw/xen/xen-bus.c                        |   5 +-
> > >  include/disas/disas.h                   |   4 +-
> > >  include/monitor/hmp.h                   |  12 +-
> > >  migration/dirtyrate.c                   |  46 +++--
> > >  migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----------------
> > >  monitor/hmp-cmds.c                      | 141 +++++++--------
> > >  monitor/hmp.c                           | 143 +++++++--------
> > >  monitor/monitor-internal.h              |   6 -
> > >  monitor/monitor.c                       |  33 ++--
> > >  net/net-hmp-cmds.c                      |  31 ++--
> > >  net/slirp.c                             |  31 ++--
> > >  qom/qom-hmp-cmds.c                      |  27 ++-
> > >  replay/replay-debugging.c               |   5 +-
> > >  stats/stats-hmp-cmds.c                  |  57 +++---
> > >  stubs/hmp-cmd-info_sev.c                |   3 +-
> > >  stubs/monitor-core.c                    |   2 +-
> > >  system/dirtylimit-hmp-cmds.c            |  10 +-
> > >  system/qdev-monitor.c                   |  19 +-
> > >  system/runstate-hmp-cmds.c              |  16 +-
> > >  system/tpm-hmp-cmds.c                   |  29 ++-
> > >  target/i386/cpu-apic.c                  |   3 +-
> > >  target/i386/monitor.c                   | 152 ++++++++--------
> > >  target/i386/sev.c                       |  35 ++--
> > >  target/m68k/monitor.c                   |   3 +-
> > >  target/ppc/monitor.c                    |   3 +-
> > >  target/riscv/monitor.c                  |  55 +++---
> > >  target/sh4/monitor.c                    |  29 ++-
> > >  target/sparc/monitor.c                  |   3 +-
> > >  target/xtensa/monitor.c                 |   3 +-
> > >  tests/unit/test-util-sockets.c          |   2 +-
> > >  tools/qemu-vnc/clipboard.c              |   4 +-
> > >  tools/qemu-vnc/stubs.c                  |   2 +-
> > >  trace/trace-hmp-cmds.c                  |  12 +-
> > >  ui/ui-hmp-cmds.c                        | 115 ++++++------
> > >  util/error-report.c                     |   2 +-
> > >  util/qemu-print.c                       |  11 +-
> > >  63 files changed, 1219 insertions(+), 1327 deletions(-)
> >
> >
> >
> >
> > > diff --git a/util/qemu-print.c b/util/qemu-print.c
> > > index 5d4143d425a1..5938f2b6c338 100644
> > > --- a/util/qemu-print.c
> > > +++ b/util/qemu-print.c
> > > @@ -13,6 +13,7 @@
> > >  #include "qemu/osdep.h"
> > >  #include "monitor/monitor.h"
> > >  #include "monitor/hmp.h"
> > > +#include "qom/object.h"
> > >  #include "qemu/qemu-print.h"
> > >
> > >  /*
> > > @@ -23,8 +24,13 @@
> > >  int qemu_vprintf(const char *fmt, va_list ap)
> > >  {
> > >      Monitor *cur_mon = monitor_cur();
> > > +
> > > +    /* for all monitors: QMP & HMP */
> > >      if (cur_mon) {
> > > -        return monitor_vprintf(cur_mon, fmt, ap);
> > > +        /* don't use monitor_cur_hmp(), to avoid a second lookup */
> > > +        MonitorHMP *hmp = (MonitorHMP *)
> > > +            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP);
> > > +        return monitor_hmp_vprintf(hmp, fmt, ap);
> >
> > This isn't the same semantics AFAICT.
> >
> > Original code, if monitor_cur() == QMP, we call monitor_vprintf()
> > which will return -1.
> >
> > New code, if monitor_cur() == QMP, we will get a NULL back from
> > object_dynamic_cast which we then pass into monitor_hmp_vprintf
> > which will then crash on monitor_puts() IIUC.
> 
> monitor_hmp_vprintf() has an early return, if given NULL monitor, it returns -1.

Hmm, I feel like we should be dealing with NULL in this method, as it
is surprising to be calling a monitor_hmp_XXX method in scenario where
QMP is a (theoretical) possibility.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 10:56:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 10:56:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399794.1635770 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzBIy-000160-8E; Wed, 26 Aug 2026 10:56:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399794.1635770; Wed, 26 Aug 2026 10:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzBIy-00015t-4u; Wed, 26 Aug 2026 10:56:28 +0000
Received: by outflank-mailman (input) for mailman id 1399794;
 Wed, 26 Aug 2026 10:56:27 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wzBIv-00015n-Le
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 10:56:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzBIt-00E9xk-QL
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:56:23 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a8ec656-8faa-0a2a0a5109dd-0a2a4505de3a-6
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 12:56:23 +0200
Received: from [40.107.74.133]
 (helo=OS0P286CU010.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a8ec650-4cb1-0a2a45050019-286b4a85c5f0-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 12:56:18 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by OS9P286MB6502.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:416::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug
 2026 10:56:13 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0360.006; Wed, 26 Aug 2026
 10:56:13 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=d9Ub0eSr9T/nqdh+FlatfnzSA6lEG8w/vWrEZVaZL9RUNOhpCF3D6W3KMe3NH3zo3SnRtpOAp5acTZ2WlpaaBymM2O6IiJ/nX87nNsWmMMac+AuP3ZIOU10123EyqaY/wVYq5vm5egln3554FOkbCEGmSsip9i5aMkt2X9jRj5+OaajMywOhw3WmuFxEyozGy4YSOIyBsoDlKcpFNyPi3i1PDbP6m2rWDB+76LRN3EBMyzZV2RL5DYt0X0g4/4HaBOJInmY31wwwjINP50vxOhpZEmPvcTPrB3oEtdsBmH3HBjYlA1yveorWLpIdy9H1lrV4ojpegKJkCxbKptgdog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7BV5ymcB0KmD5GHTclbU2cH18oLhvNxYW2OZLODsz5Y=;
 b=czZOjEul0XTDWW6846wQN4eY2gNBJ/soamIMUTSl3VnCFFoAbiLbJ2Ujn+6P4NxWFZrSnm7YVzO/1nCnv4LAnjZ8xWyEgkku/QaEnlX1F3Fl4WRpNxW27IEkEH5FezNipGoQypADfQV2dsB69rkb+pxxcl6/eJ8BwOIo4i3/15nz6Im8E4owc2J0SZiqeB0iAVD3kFWr1/OoXF1L/A+mjTNnKNu/i3IyqFL3DeTtgB2V6+M6mFpaOE61nbC9srnttjkqdcRwwJPqtWQAiAyGcQwTziNiCeiwbQQU1XMCCFKRNwmezPd0CJMTi1XVm+d2uCGArKSu8crTP1S/L0rd6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7BV5ymcB0KmD5GHTclbU2cH18oLhvNxYW2OZLODsz5Y=;
 b=shf+YPwBIBLjpex6DDXbbsOcdZezIei9oDnTAPHVCnxSTk91WstCVcDL42AO+ooO9mRDJziB4u3kamwM5xZD2XrAe2R6YlZKivOevJ3kjW51wQ0e/4G1iACXqH8fGpwywRskBs6x8cLN7sh6mIYNAIKq+Opi6q1/+4qVZh9wYzY=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: xen-devel@lists.xenproject.org
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>
Subject: [PATCH v4] xen/arm: Hide PMU registers from the guest, when the vPMU feature is disabled.
Date: Wed, 26 Aug 2026 19:55:28 +0900
Message-ID: <20260826105529.364192-1-taka@valinux.co.jp>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: TYCP286CA0344.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:400:38e::16) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 (2603:1096:604:458::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|OS9P286MB6502:EE_
X-MS-Office365-Filtering-Correlation-Id: d6fb0f6a-9687-496f-cce7-08df0360a52b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|10070799003|7416014|376014|23010399003|18002099003|10067099003|56012099006|6133799003;
X-Microsoft-Antispam-Message-Info:
	tM6OixdhPstTFNaWVggkdKSjwnoc8wXWYqlISjP4qMjqRECw0JVfLm3DoE9DrGWJrO5q/izLRc6j6x2+doDWNpxTUb6uvI0XMmq3yUYdVCZmfqiqvMkXYTYCvLnyVay/3teTl4L4/rIdcrA3PnfEWHnlHv+yxr5sAqqjwRPpHaiYegUPKzRvfiBLJmcLuy91tDTPdCD9DzGNGpffNSnmKzKJAg0+8dlfawCOsPTkudhdHVhpPhOzRlUigb3JXGlFqtiAK5lKOT4dDhbiL7OPP+hThwvi21YygTdFtBXV/ddPSYg/nGptFwx5xNw5GRIrpI7W29z+RhIaBEmtQs24l3dqHUseVIlKgv+7afJVIeQ8hNcE0P7w4pFHkpJmzJltoYKCJKVvyhvKFwxqC4pyYwWIAyn1C6FxMwrCaI+2L2sKYASsTbdOyLFqGhOUD2ZUuEaQTFEjg63RkvyJ1pUKOE6UCTBvCkExOqM85B9LOLGf7z+d8SMbG4rtlUY1RYneXvihQVw6lHlMqM/i7xW7T6LMCXU9Ar9+eZY9nl99Q+R/uYdt6oLYv8ekOqZB8y5yraDa8Cby7wgd/srX5e1emLDVO75d+lKV5jo3zpIJJsbN+uGZWIHF5I9HY1MczsV8SR9StdQtBAA2sVz3oe14QbxSufIIjxa80v3A9PwmKyU=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(10070799003)(7416014)(376014)(23010399003)(18002099003)(10067099003)(56012099006)(6133799003);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?JZABnMVykzTke4uSWzutuV6KuP+teO84Oqm7HheqYu5477q9K8bN9YUk9Qwo?=
 =?us-ascii?Q?mTzsMfJIo0SQcQffkLZEU51DAEadrUbnqO2CknBQkPdqiGLhQDLWYF5juptr?=
 =?us-ascii?Q?KkOXIDKIVh2KOPGkQnPNlWc9dAigKZjQr128zihmKO8SP05eyieGwwBCE/ls?=
 =?us-ascii?Q?BY1JVulz7s7EE6RoWJbFB3c9G6yI19bueZFkTvVTNNnLp7x6duhKXyejUL4E?=
 =?us-ascii?Q?lTq6L/WOqQ7eO8h4Wh2/GtdhX+n6XBoVsHfFgd5ouPLs9qcCSNIKUU0QttyT?=
 =?us-ascii?Q?fNySXoDIYvHMh19tv5udsLEMJJpnpE7MqFaIT60MaxrIcU1HT/yN2UYpxXiC?=
 =?us-ascii?Q?myaXznvDlxqWXeWhRBitagPPR0ocgcWN/8kvLjNjaZ2laW7VIyT6YP3sbqXo?=
 =?us-ascii?Q?YWDSUTm12bYopmlr+qkbb+KaYsTVgK5+xL7bboCDlCMX0VX/Sv4d3ETr0UdO?=
 =?us-ascii?Q?Nvv6o/hlHHuVu0YfYWL9gdhhu/zNcOCebK8H9hMrnu1WbXHG1yJmqdm9GZrr?=
 =?us-ascii?Q?SXto8BTm64Hmt7omSO28J3Ko8XNxe5+VyWGhnNKxAqzHGSgwXJT30vN6RcD2?=
 =?us-ascii?Q?0ahOuiCewApuOY6blCI2FCyt0u6BEQL9YYPM3NyIENYDhVTxhVRvu/VqfHVL?=
 =?us-ascii?Q?KUJU+8LGHR2UIF1wvj34Stivs+2HzkAjIgy0yLxLSKpbVjBltNKAOCUVHTWi?=
 =?us-ascii?Q?gbM/ZwDlBn547DsAbEEwSYzxsl5+tv1fW7eep9qnTi0A0/GyBqIaFLu8kLqS?=
 =?us-ascii?Q?thIQlvTcq36IMcfVoB3todkZQknRALIDa7tAHtGa+94mJMtbhyuzbmSkZKtM?=
 =?us-ascii?Q?2PGaY9HRk6LodSqzOYVqLnMMKy6k97JjSnJ8SrBasSIFkHhzSHP5fVD19seH?=
 =?us-ascii?Q?LAnSbD62vqw11KijqxCQ51p4fUa6UOloH7o0r4ncBEF0xic09ZMUdfyhQ43g?=
 =?us-ascii?Q?m8ZTSPhIdlL3DJa81U0b5aJuME6MiOjlytamcL4htIXuxBfyetoTqkoNiuGz?=
 =?us-ascii?Q?8SsItAJ3yYWTEPI4z4xLjZRWK1tl8q1cpA8uXC7d+o33FxvbcZxdAuuIm6Lm?=
 =?us-ascii?Q?qexa4jsUZTgOrKirwrrJFrnEqEydMt2aO9j+5ooYLZmc3A4tIJ+Z3hy+d5M8?=
 =?us-ascii?Q?dH3KBaQFjqv/pNN9g1pjGSUBHkhDMGoQStsCA3mhNqS1pRhUwtu/V+/Ywnrz?=
 =?us-ascii?Q?1F9COy+fXlfGcxOmJft01UXyuhQ2+CijSub41aJ8aGzPsYjhZWeJ/V8pxuAA?=
 =?us-ascii?Q?gCGdGu27IjLpWvl+hID1ION+IBWE+baydIK6R301l2/IqWTwEwLUIsVhZSLr?=
 =?us-ascii?Q?sxDtUTMSNyo3whKw+noAaZNo7Y5xjDIGBA29X4OQoOWM0Gz7mOaK4uGCTTfh?=
 =?us-ascii?Q?hWoXcfg1or2RfHoTjUOLTrQKWY3JWeucThY5/YQ/fg0xMgwO6y/xtqgMH/UV?=
 =?us-ascii?Q?KhiyEziMU82I5FQJPBQaZKZFQbm9HB6JPRMiuHTIHBRZNSlkZTEauRb+4gR3?=
 =?us-ascii?Q?aJrv/7zyvUe2VE+0UwvWvTI6s1Th8/2HkKL7xkMNNh2SfU/dh3yucvoqfGkl?=
 =?us-ascii?Q?j5MLO+9/dh/hX+xEVLorJTfe0FjvFSaTH+9Xk2MRpm3GuRIJEJ+ZW72M4SVc?=
 =?us-ascii?Q?zhsRVozbev3yqX8eu3uXbktPaVXKVZbeapWe/TGbWF/lOrRNCDgl8fwK+ILu?=
 =?us-ascii?Q?PsI3faEt+FboiN/PBA8tZCS4APwi+YmN7/Q4dmJOiFSoz0AOMKXPG41kLDcw?=
 =?us-ascii?Q?asSEskkyQ0+tACA1D5Jnq4wtX1ls2yjh0u/9myQs1TEejvIrrehS973I/LLa?=
X-MS-Exchange-AntiSpam-MessageData-1: 5bOK/sQ7V2TvvA==
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: d6fb0f6a-9687-496f-cce7-08df0360a52b
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 10:56:13.4200
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: l9qJ9UC5UdKYfgwPj5i8xjG2+A43464u5Aim6eZpTCBVuwHGSIargOBV5gbhCVrJCFG9xSiNfhHbYMnTLsWbOA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS9P286MB6502
X-purgate-ID: tlsNG-c201ff/1787741783-72AB72A1-08187B02/0/0
X-purgate-type: clean
X-purgate-size: 12152

On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
causes the domain to probe advanced PMU feature based on system ID
register ID_AA64DFR0_EL1. During this probe, Linux accesses PMMIR_EL1,
which causes unhandled register traps and crashes the domain.

To address this issue, implement the following:

- Add emulation for ID_AA64DFR{0,1}_EL1, ID_DFR{0,1}_EL1 and
  ID_DFR{0,1} register accesses for guest domains.
- Hide PMU registers from a guest domain when its vPMU feature is
  disabled.
- Proactively make SPE, TRBE, BRBE, Trace Extensions, SPMU, ITE and
  EBEP inaccessible to arm64 guest domains and hide TraceFilt,
  MMapTrc and CopTrc to arm32 guest domains, as they could
  potentially cause similar issues.

Fixes: dbb948110a0e ("xen: Expose the PMU to the guests")
Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
Fixes: 3669a1cb9598 ("xen/arm: create a cpuinfo structure for guest")
Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
---
Changes in v4:
 * Hide FEAT_HPMN0 from guests when the vPMU feature is disabled.
 * Unconditionally hide FEAT_SPMU and FEAT_EBEP from guest domains.
 * Fix arm32 build failure in vcpreg.c.
 * Perform code cleanups and address coding style feedback.

 xen/arch/arm/arm64/vsysreg.c          | 62 +++++++++++++++++++++++++--
 xen/arch/arm/cpufeature.c             | 17 ++++++++
 xen/arch/arm/domain.c                 |  2 +-
 xen/arch/arm/include/asm/arm64/hsr.h  |  1 +
 xen/arch/arm/include/asm/cpregs.h     |  1 +
 xen/arch/arm/include/asm/cpufeature.h | 27 +++++++++---
 xen/arch/arm/vcpreg.c                 | 29 ++++++++++++-
 xen/include/xen/sched.h               |  5 +++
 8 files changed, 130 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index d9e3619dfb..bf612a133d 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -227,6 +227,7 @@ void do_sysreg(struct cpu_user_regs *regs,
      */
     case HSR_SYSREG_PMINTENSET_EL1:
     case HSR_SYSREG_PMINTENCLR_EL1:
+    case HSR_SYSREG_PMMIR_EL1:
         return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
     case HSR_SYSREG_PMUSERENR_EL0:
         /* RO at EL0. RAZ/WI at EL1 */
@@ -300,8 +301,32 @@ void do_sysreg(struct cpu_user_regs *regs,
     GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
     GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
     GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
-    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
-    GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
+
+    case HSR_SYSREG_ID_DFR0_EL1:
+    {
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(v->domain) )
+            info_dbg32.perfmon = 0;
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[0]);
+    }
+
+    case HSR_SYSREG_ID_DFR1_EL1:
+    {
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(v->domain) )
+        {
+            info_dbg32.mtpmu = 0;
+            info_dbg32.hpmn0 = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg32.bits[1]);
+    }
+
     GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
     GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
     GENERATE_TID3_INFO(ID_MMFR1_EL1, mm32, 1)
@@ -342,8 +367,37 @@ void do_sysreg(struct cpu_user_regs *regs,
     }
 
     GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
-    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
-    GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
+
+    case HSR_SYSREG_ID_AA64DFR0_EL1:
+    {
+        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
+
+        if ( !is_vpmu_domain(v->domain) )
+        {
+            info_dbg64.pmu_ver = 0;
+            info_dbg64.pmss = 0;
+            info_dbg64.mtpmu = 0;
+            info_dbg64.hpmn0 = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg64.bits[0]);
+    }
+
+    case HSR_SYSREG_ID_AA64DFR1_EL1:
+    {
+        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
+
+        if ( !is_vpmu_domain(v->domain) )
+        {
+            info_dbg64.pmicntr = 0;
+            info_dbg64.dpfzs = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+                                  info_dbg64.bits[1]);
+    }
+
     GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
     GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
     GENERATE_TID3_INFO(ID_AA64MMFR0_EL1, mm64, 0)
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 94d14fb6a9..88478fea46 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -219,8 +219,25 @@ static int __init create_domain_cpuinfo(void)
     domain_cpuinfo.isa64.api = 0;
     domain_cpuinfo.isa64.gpa = 0;
     domain_cpuinfo.isa64.gpi = 0;
+
+    /* Hide SPE, TRBE, BRBE, Trace Extensions, SPMU, ITE and EBEP */
+    domain_cpuinfo.dbg64.trace_ver = 0;
+    domain_cpuinfo.dbg64.pms_ver = 0;
+    domain_cpuinfo.dbg64.trace_filt = 0;
+    domain_cpuinfo.dbg64.trace_buffer = 0;
+    domain_cpuinfo.dbg64.ext_trc_buff = 0;
+    domain_cpuinfo.dbg64.brbe = 0;
+    domain_cpuinfo.dbg64.syspmuid = 0;
+    domain_cpuinfo.dbg64.spmu = 0;
+    domain_cpuinfo.dbg64.ite = 0;
+    domain_cpuinfo.dbg64.ebep = 0;
 #endif
 
+    /* Hide Trace Extensions for AArch32 domain */
+    domain_cpuinfo.dbg32.coptrc = 0;
+    domain_cpuinfo.dbg32.mmaptrc = 0;
+    domain_cpuinfo.dbg32.tracefilt = 0;
+
     /* Hide AMU support */
 #ifdef CONFIG_ARM_64
     domain_cpuinfo.pfr64.amu = 0;
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index baa3a5d708..a739dd157e 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -501,7 +501,7 @@ int arch_vcpu_create(struct vcpu *v)
     v->arch.hcr_el2 = get_default_hcr_flags();
 
     v->arch.mdcr_el2 = HDCR_TDRA | HDCR_TDOSA | HDCR_TDA;
-    if ( !(v->domain->options & XEN_DOMCTL_CDF_vpmu) )
+    if ( !is_vpmu_domain(v->domain) )
         v->arch.mdcr_el2 |= HDCR_TPM | HDCR_TPMCR;
 
     if ( (rc = vcpu_vgic_init(v)) != 0 )
diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h
index 1495ccddea..ed18184cc7 100644
--- a/xen/arch/arm/include/asm/arm64/hsr.h
+++ b/xen/arch/arm/include/asm/arm64/hsr.h
@@ -84,6 +84,7 @@
 #define HSR_SYSREG_FAR_EL1        HSR_SYSREG(3,0,c6, c0,0)
 #define HSR_SYSREG_PMINTENSET_EL1 HSR_SYSREG(3,0,c9,c14,1)
 #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
+#define HSR_SYSREG_PMMIR_EL1      HSR_SYSREG(3,0,c9,c14,6)
 #define HSR_SYSREG_MAIR_EL1       HSR_SYSREG(3,0,c10,c2,0)
 #define HSR_SYSREG_AMAIR_EL1      HSR_SYSREG(3,0,c10,c3,0)
 #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
index a7503a190f..3f62b38dc0 100644
--- a/xen/arch/arm/include/asm/cpregs.h
+++ b/xen/arch/arm/include/asm/cpregs.h
@@ -246,6 +246,7 @@
 #define PMINTENSET      p15,0,c9,c14,1  /* Perf. Mon. Interrupt Enable Set Register */
 #define PMINTENCLR      p15,0,c9,c14,2  /* Perf. Mon. Interrupt Enable Clear Register */
 #define PMOVSSET        p15,0,c9,c14,3  /* Perf. Mon. Overflow Flag Status Set register */
+#define PMMIR           p15,0,c9,c14,6  /* Perf. Mon. Machine Identification Register */
 
 /* CP15 CR10: */
 #define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index bf902a3970..c554686415 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -208,7 +208,7 @@ struct cpuinfo_arm {
         };
     } pfr64;
 
-    union {
+    union cpuinfo_dbg64 {
         register_t bits[2];
         struct {
             /* DFR0 */
@@ -216,19 +216,31 @@ struct cpuinfo_arm {
             unsigned long trace_ver:4;
             unsigned long pmu_ver:4;
             unsigned long brps:4;
-            unsigned long __res0:4;
+            unsigned long pmss:4;
             unsigned long wrps:4;
             unsigned long __res1:4;
             unsigned long ctx_cmps:4;
             unsigned long pms_ver:4;
             unsigned long double_lock:4;
             unsigned long trace_filt:4;
-            unsigned long __res2:4;
+            unsigned long trace_buffer:4;
             unsigned long mtpmu:4;
-            unsigned long __res3:12;
+            unsigned long brbe:4;
+            unsigned long ext_trc_buff:4;
+            unsigned long hpmn0:4;
 
             /* DFR1 */
-            unsigned long __res4:64;
+            unsigned long syspmuid:8;
+            unsigned long brps1:8;
+            unsigned long wrps1:8;
+            unsigned long ctx_cmps1:8;
+            unsigned long spmu:4;
+            unsigned long pmicntr:4;
+            unsigned long able:4;
+            unsigned long ite:4;
+            unsigned long ebep:4;
+            unsigned long dpfzs:4;
+            unsigned long abl_cmps:8;
         };
     } dbg64;
 
@@ -408,7 +420,7 @@ struct cpuinfo_arm {
         };
     } pfr32;
 
-    union {
+    union cpuinfo_dbg32 {
         register_t bits[2];
         struct {
             /* DFR0 */
@@ -426,7 +438,8 @@ struct cpuinfo_arm {
 
             /* DFR1 */
             unsigned long mtpmu:4;
-            unsigned long __res1:28;
+            unsigned long hpmn0:4;
+            unsigned long __res1:24;
 #ifdef CONFIG_ARM_64
             unsigned long __res2:32;
 #endif
diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
index 3205c7df46..db8909d96e 100644
--- a/xen/arch/arm/vcpreg.c
+++ b/xen/arch/arm/vcpreg.c
@@ -292,6 +292,7 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
             return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
     case HSR_CPREG32(PMINTENSET):
     case HSR_CPREG32(PMINTENCLR):
+    case HSR_CPREG32(PMMIR):
         return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
     case HSR_CPREG32(PMCR):
     case HSR_CPREG32(PMCNTENSET):
@@ -320,8 +321,32 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
     GENERATE_TID3_INFO(ID_PFR0, pfr32, 0)
     GENERATE_TID3_INFO(ID_PFR1, pfr32, 1)
     GENERATE_TID3_INFO(ID_PFR2, pfr32, 2)
-    GENERATE_TID3_INFO(ID_DFR0, dbg32, 0)
-    GENERATE_TID3_INFO(ID_DFR1, dbg32, 1)
+
+    case HSR_CPREG32(ID_DFR0):
+    {
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(v->domain) )
+            info_dbg32.perfmon = 0;
+
+        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1,
+                                  info_dbg32.bits[0]);
+    }
+
+    case HSR_CPREG32(ID_DFR1):
+    {
+        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
+
+        if ( !is_vpmu_domain(v->domain) )
+        {
+            info_dbg32.mtpmu = 0;
+            info_dbg32.hpmn0 = 0;
+        }
+
+        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1,
+                                  info_dbg32.bits[1]);
+    }
+
     GENERATE_TID3_INFO(ID_AFR0, aux32, 0)
     GENERATE_TID3_INFO(ID_MMFR0, mm32, 0)
     GENERATE_TID3_INFO(ID_MMFR1, mm32, 1)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index eef10c2ea2..e352e2b38e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1269,6 +1269,11 @@ static always_inline bool is_iommu_enabled(const struct domain *d)
     return evaluate_nospec(d->options & XEN_DOMCTL_CDF_iommu);
 }
 
+static inline bool is_vpmu_domain(const struct domain *d)
+{
+    return d->options & XEN_DOMCTL_CDF_vpmu;
+}
+
 #ifdef CONFIG_MEM_PAGING
 # define mem_paging_enabled(d) vm_event_check_ring((d)->vm_event_paging)
 #else
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 11:49:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 11:49:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399820.1635788 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzC8H-0008Ra-3V; Wed, 26 Aug 2026 11:49:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399820.1635788; Wed, 26 Aug 2026 11:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzC8G-0008RT-WE; Wed, 26 Aug 2026 11:49:29 +0000
Received: by outflank-mailman (input) for mailman id 1399820;
 Wed, 26 Aug 2026 11:49:27 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzC8F-0008QJ-QC
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 11:49:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzC8E-00H6sA-E1
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 13:49:26 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed2c2-bab6-0a2a0a5309dd-0a2a4509bd18-10
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 13:49:26 +0200
Received: from [209.85.208.43] (helo=mail-ed1-f43.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed2c6-be1a-0a2a45090019-d155d02bd5f6-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 13:49:26 +0200
Received: by mail-ed1-f43.google.com with SMTP id
 4fb4d7f45d1cf-6a18e24ad25so1134635a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 04:49:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5deac24f1sm3779661a12.23.2026.08.26.04.49.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 04:49:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787744966; x=1788349766; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Ss+YAR07JAD2fP8Xw057WPMldxuT1tgMd9itna7uDYs=;
        b=S+nmjldk/NDQYpCuR+yofeIGw0OFY3vZFArRTjUlOgDHVPJHg0UemMmFHPkZfYlrm3
         O7v/vZfxEXgycXGtlER7daPpPRsyGD9ZzaLOCLLVkKNv1BJsdodn6NaO1Md80OKlraVc
         OZxBg4ni0YBz79Sd96DunC01D++gy+7nt8NIX140NRzCZNQ2pPJG/HbSuDr0eyTmnZvE
         ti+bAiz2zpE1tfsYFEKbu6hcOb5l2/sNDbyRlV9LPaD2mJfbVeJtxc33DCcpn7YEi2BF
         2QZu04ItCzfY0GN1XA6/Qm+LVIExlV92UikmBNRcRkLX5DNCe3F5UuTO9UE44JyOhbv2
         93TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787744966; x=1788349766;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Ss+YAR07JAD2fP8Xw057WPMldxuT1tgMd9itna7uDYs=;
        b=BS1Y1gOfHIRVyC/3zbp9ZkEG152oVVRMoBIRDHioIneBn7NUrLmQW/tu33Z/fdM6HB
         mF0taakQ3WoEKg36YxbESOG2ilrZbyF5QhnfapvDsRuWNQHh1iteBlVXrNnav1yW2BGs
         iiWJVRfCZS9LpMQtsHblJwHSL7rswYjOhoe84tRQwvZK2W9yuOlygNzArznw5ld8c1Xb
         tqXOhgJy6mzskNfjePYregQPy96SmC+BrjirrNHzphNGEQHIeogxxIjmFwXRjI2JfWNl
         C57bh4ZbgEb6/LgeYpS3VgR1L2O91VkYI7rwwqQrx02XKnpePh22wh3RrxZ/AjXuOKYH
         cq8A==
X-Gm-Message-State: AFuF++kMlbqdnd/BNxNuKqGgGp9uA+N4zoSY0OPr7Cjtck2yuesQofh3
	AJu20vdVwqrYOpghPEyrn9i9A1eF5W/QVKl006usrVz2URbxrNAQDJJIoeUZE1sSOvJj39WG8Ze
	GEZUGgw==
X-Gm-Gg: AR+sD12LZIdDR07uFsCeUBUTJFufHi06MZoNiNosjdaXZmsLg/a52fwQrp4sNFb2bSU
	mejFw4kwlUVGgjb3YIWD/l3js50MngGsCgdxLhoWMAYX8V6Ak2mQHoRcfoZMvNazCE7mKOBjZqg
	0GhvOTykCF4y7tcj9YPWnbZqPL2gFK9ZeyZPIZ4bGZdDycd5IlCBG7H13RkC33fH3hDFDTiCID9
	75BG9nibs79mfNRsa93TLoaVmGzYFmdJhYRuNaP2wESUnzOOz+Fjw6qlfzDNo5lrt0G4SE5jmzR
	danr2kPUUd25RiWzcYTHGE9FZ1gR2u4v6FLOPpmH1/Iw5dkBRKxKnIqE1Iz/kFyvFHS/fqwWGqz
	VbHOov4SPQz1v4cR06dLz2M6w8xktLrwlPGw8+WIJsOHblJAdwymPwxpcIkOsGgedDyTWnqZ8RS
	ci620DybebwQWOihzb7hH8kiJCj1gqeDGu3+KsUbA0QL/dx5/0RtaK1Y5zhSwK+U9FelpJtFSVm
	vhGrbVlr30ZNoZj8Fz5evb+sxb5wexUVQuA3oN/4GQCAD8N4QAKN3HnTziDiBLp
X-Received: by 2002:a05:6402:210d:b0:6a4:2ee:5c6d with SMTP id 4fb4d7f45d1cf-6a5df5e3966mr8005779a12.6.1787744965646;
        Wed, 26 Aug 2026 04:49:25 -0700 (PDT)
Message-ID: <53e4e1d5-ccb6-4400-b440-7ec9a7273ac8@suse.com>
Date: Wed, 26 Aug 2026 13:49:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86: replace a few more is_hvm_*() by is_pv_*()
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787744966-FD469034-A51DA306/0/0
X-purgate-type: clean
X-purgate-size: 7657

Along the lines of [1]. Both (respectively negated) can be used
interchangeably when no system domains are (potentially) involved.

For gtime_to_gtsc():
- with !is_hvm_domain() and HVM=n the conditional but not its body would
  disappear,
- with is_pv_domain() and PV=n, the conditional and its body will
  disappear.
Then mirror the change to gtsc_to_gtime() for consistency.

For mem_sharing_control() vm_event_toggle_singlestep(), as VM_EVENT /
MEM_SHARING depend on HVM anyway, the !is_hvm() form can't ever become
compile-time constant, while the is_pv() form can. Same for PoD code,
HVM-specific pieces of shadow/{common,multi}.c, and everything in
shadow/hvm.c.

[1] https://lists.xen.org/archives/html/xen-devel/2026-08/msg01156.html

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Pretty likely there are more instances of this pattern that could do with
using the opposite predicate. However, e.g. further is_{hvm,pv}() uses in
time.c look to be asking for a little more trickery to benefit both PV=n
and HVM=n (not at the same time, of course).

As to system domains, and as previously pointed out: is_pv_domain() is odd
there for the PV=n case. With PV=y it returns true there, while with PV=n
it yields false.

--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1509,7 +1509,7 @@ static inline int mem_sharing_control(st
 {
     if ( enable )
     {
-        if ( unlikely(!is_hvm_domain(d) || !cpu_has_vmx) )
+        if ( unlikely(is_pv_domain(d) || !cpu_has_vmx) )
             return -EOPNOTSUPP;
 
         if ( unlikely(!hap_enabled(d)) )
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -353,7 +353,7 @@ void p2m_pod_get_mem_target(const struct
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    ASSERT(is_hvm_domain(d));
+    ASSERT(!is_pv_domain(d));
 
     pod_lock(p2m);
     lock_page_alloc(p2m);
@@ -1432,7 +1432,7 @@ bool p2m_pod_active(const struct domain
     struct p2m_domain *p2m;
     bool res;
 
-    if ( !is_hvm_domain(d) )
+    if ( is_pv_domain(d) )
         return false;
 
     p2m = p2m_get_hostp2m(d);
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -171,7 +171,7 @@ void shadow_promote(struct domain *d, mf
     {
         page->shadow_flags = 0;
 #ifdef CONFIG_HVM
-        if ( is_hvm_domain(d) )
+        if ( !is_pv_domain(d) )
             page->pagetable_dying = false;
 #endif
     }
@@ -1520,7 +1520,7 @@ int sh_remove_all_mappings(struct domain
                    mfn_x(gmfn), gfn_x(gfn),
                    page->count_info, page->u.inuse.type_info,
                    is_special_page(page),
-                   (is_hvm_domain(d) && is_ioreq_server_page(d, page)));
+                   (!is_pv_domain(d) && is_ioreq_server_page(d, page)));
     }
 
     paging_unlock(d);
@@ -2318,7 +2318,7 @@ void shadow_teardown(struct domain *d, b
     d->arch.paging.mode &= ~PG_log_dirty;
 
 #ifdef CONFIG_HVM
-    if ( is_hvm_domain(d) && d->arch.hvm.dirty_vram.sh )
+    if ( !is_pv_domain(d) && d->arch.hvm.dirty_vram.sh )
     {
         xfree(d->arch.hvm.dirty_vram.sh->sl1ma);
         xfree(d->arch.hvm.dirty_vram.sh->dirty_bitmap);
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -315,7 +315,7 @@ const struct x86_emulate_ops *shadow_ini
     const struct vcpu *curr = current;
     unsigned long addr;
 
-    ASSERT(is_hvm_vcpu(curr));
+    ASSERT(!is_pv_vcpu(curr));
 
     memset(sh_ctxt, 0, sizeof(*sh_ctxt));
 
@@ -361,7 +361,7 @@ void shadow_continue_emulation(struct sh
 {
     unsigned long addr, diff;
 
-    ASSERT(is_hvm_vcpu(current));
+    ASSERT(!is_pv_vcpu(current));
 
     /*
      * We don't refetch the segment bases, because we don't emulate
@@ -1217,7 +1217,7 @@ void shadow_vram_get_mfn(mfn_t mfn, unsi
     unsigned long gfn;
     struct sh_dirty_vram *dirty_vram = d->arch.hvm.dirty_vram.sh;
 
-    ASSERT(is_hvm_domain(d));
+    ASSERT(!is_pv_domain(d));
 
     if ( !dirty_vram /* tracking disabled? */ ||
          !(l1f & _PAGE_RW) /* read-only mapping? */ ||
@@ -1247,7 +1247,7 @@ void shadow_vram_put_mfn(mfn_t mfn, unsi
     unsigned long gfn;
     struct sh_dirty_vram *dirty_vram = d->arch.hvm.dirty_vram.sh;
 
-    ASSERT(is_hvm_domain(d));
+    ASSERT(!is_pv_domain(d));
 
     if ( !dirty_vram /* tracking disabled? */ ||
          !(l1f & _PAGE_RW) /* read-only mapping? */ ||
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -601,7 +601,7 @@ _sh_propagate(struct vcpu *v,
         sflags &= ~_PAGE_RW;
 
 #ifdef CONFIG_HVM
-    if ( unlikely(level == 1) && is_hvm_domain(d) )
+    if ( unlikely(level == 1) && !is_pv_domain(d) )
     {
         struct sh_dirty_vram *dirty_vram = d->arch.hvm.dirty_vram.sh;
 
@@ -2240,7 +2240,7 @@ static int cf_check sh_page_fault(
 #ifdef CONFIG_HVM
             /* Magic MMIO marker: extract gfn for MMIO address */
             ASSERT(sh_l1e_is_mmio(sl1e));
-            ASSERT(is_hvm_vcpu(v));
+            ASSERT(!is_pv_vcpu(v));
             gpa = gfn_to_gaddr(sh_l1e_mmio_get_gfn(sl1e)) | (va & ~PAGE_MASK);
             perfc_incr(shadow_fault_fast_mmio);
             SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
@@ -2562,7 +2562,7 @@ static int cf_check sh_page_fault(
     /* Need to hand off device-model MMIO to the device model */
     if ( p2mt == p2m_mmio_dm )
     {
-        ASSERT(is_hvm_vcpu(v));
+        ASSERT(!is_pv_vcpu(v));
 
         sh_audit_gw(v, &gw);
         gpa = guest_walk_to_gpa(&gw);
@@ -2589,7 +2589,7 @@ static int cf_check sh_page_fault(
      * CR0.WP is clear, we must emulate faulting supervisor writes to
      * allow the guest to write through read-only PTEs.  Emulate if the
      * fault was a non-user write to a present page.  */
-    if ( is_hvm_domain(d)
+    if ( !is_pv_domain(d)
          && unlikely(!hvm_wp_enabled(v))
          && regs->error_code == (PFEC_write_access|PFEC_page_present)
          && mfn_valid(gmfn) )
@@ -3718,7 +3718,7 @@ static void cf_check sh_pagetable_dying(
     unsigned long l3gfn;
     mfn_t l3mfn;
 
-    ASSERT(is_hvm_domain(d));
+    ASSERT(!is_pv_domain(d));
 
     gcr3 = v->arch.hvm.guest_cr[3];
     /* fast path: the pagetable belongs to the current context */
@@ -3794,7 +3794,7 @@ static void cf_check sh_pagetable_dying(
     mfn_t smfn, gmfn;
     p2m_type_t p2mt;
 
-    ASSERT(is_hvm_domain(d));
+    ASSERT(!is_pv_domain(d));
 
     gmfn = get_gfn_query(d, _gfn(gpa >> PAGE_SHIFT), &p2mt);
     paging_lock(d);
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -2867,7 +2867,7 @@ custom_param("tsc", tsc_parse);
 
 uint64_t gtime_to_gtsc(const struct domain *d, uint64_t time)
 {
-    if ( !is_hvm_domain(d) )
+    if ( is_pv_domain(d) )
     {
         if ( time < d->arch.vtsc_offset )
             return -scale_delta(d->arch.vtsc_offset - time,
@@ -2880,7 +2880,7 @@ uint64_t gtime_to_gtsc(const struct doma
 #ifdef CONFIG_HVM
 uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc)
 {
-    ASSERT(is_hvm_domain(d));
+    ASSERT(!is_pv_domain(d));
     return scale_delta(tsc, &d->arch.vtsc_to_ns);
 }
 #endif /* CONFIG_HVM */
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -65,7 +65,7 @@ void vm_event_toggle_singlestep(struct d
                          VM_EVENT_FLAG_FAST_SINGLESTEP)) )
         return;
 
-    if ( !is_hvm_domain(d) )
+    if ( is_pv_domain(d) )
         return;
 
     ASSERT(atomic_read(&v->vm_event_pause_count));


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 11:50:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 11:50:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399829.1635796 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzC9A-0001U7-Do; Wed, 26 Aug 2026 11:50:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399829.1635796; Wed, 26 Aug 2026 11:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzC9A-0001U0-BC; Wed, 26 Aug 2026 11:50:24 +0000
Received: by outflank-mailman (input) for mailman id 1399829;
 Wed, 26 Aug 2026 11:50:24 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wzC99-0001Tu-PL
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 11:50:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzC99-008Fuj-2T
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 13:50:23 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8ed2f9-8faa-0a2a0a5109dd-0a2a450191f4-18
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 13:50:22 +0200
Received: from [52.101.56.67]
 (helo=BN1PR04CU002.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8ed2fd-5984-0a2a45010019-346538433dab-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 13:50:22 +0200
Received: from BY1P220CA0015.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::10)
 by LV3PR12MB9168.namprd12.prod.outlook.com (2603:10b6:408:19a::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug
 2026 11:50:18 +0000
Received: from MWH0EPF000A6730.namprd04.prod.outlook.com
 (2603:10b6:a03:5c3:cafe::20) by BY1P220CA0015.outlook.office365.com
 (2603:10b6:a03:5c3::10) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.10 via Frontend Transport; Wed,
 26 Aug 2026 11:50:17 +0000
Received: from satlexmb07.amd.com (149.199.90.133) by
 MWH0EPF000A6730.mail.protection.outlook.com (10.167.249.22) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Wed, 26 Aug 2026 11:50:17 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Wed, 26 Aug
 2026 06:50:11 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Wed, 26 Aug 2026 06:50:07 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mNpeF+1UZ+MkdshT+Gl3+QQeY+rjpiGAKu7OF0uv0QoKTyOLTOizgLnVWKjOJgvpqnECPhbe+6ydDGwg19QIB9aAc7uaNAzi/G1lrxlyCoY+WaedFgYTDQ263ZoC5yWxmHJiOLI/ug3mwGzmYy0EKB00uKb/wYb93qke5FxRfgQHhG8skljB+htAnd7QtRl/lQ3RQz7zB82UlBp72SMv89bTvXpLw+xYgvO8J3baDV2yqmbqGvLNz/31DxqJI6NdRMZ5O8uJeOLfCh/Cq/zDYol53GLcis4qcseGC7L6aKmRsbdQWYygFQo97/EY8qoxzQeEOdrSCQhcyMXONQUt/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DeAf8T8FMc5gDq2Yy7gMjj4jkKJy6FbTP5bBEtXmlWY=;
 b=P44Y+rsydO5+01gc5Fy6ArCfa4cucDBWcIsQSTevSJJtVKTTLFZ6eQW5BBBBWDQW6EDxqYpg/7426i/moLQZgInXdrev25zQG5tDQeVYq2Pe7V9JGV+EVv3iluxUYnXw6BL+zP76VBb77LJVlWwh5iBNnmQZ7ProWrWBIrDe8EO2HT8ETEJ7vn6EmoNmiGgKhI1wopdUJvpaaMAf50qgE6nwRZAaHcb2zN0hjTiMv1Xz0T1+Bq5bSrSvKJmKFwQYipsoa6beYQ2hNSI2wYBCzTbxvrIsST+rhGB7vK6IV2pKpSEhD64rSPb+N5wEYGezZPOFJngAds6ktkJ72lzWmg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
 is 149.199.90.133) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com;
 dmarc=fail (p=quarantine sp=quarantine pct=100) action=quarantine
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=DeAf8T8FMc5gDq2Yy7gMjj4jkKJy6FbTP5bBEtXmlWY=;
 b=chJC0EPnaXFcMGgAasCDVnqdSDtP9G9Jy5B53vIfc5HVB134EThKT0loSp8VooQBy9kbEiK1GuujOgDWVDgkWKinczQaW/t56/bjXlH5D4tSCHgPFJQkj3SPIwi0gZn/FCI2sTa9frJBvuSaoj571hqrnRSr+rLXRNaYsZjNHcw=
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
 149.199.90.133) smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine header.from=amd.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 amd.com discourages use of 149.199.90.133 as permitted sender)
Message-ID: <850183ed-f297-4be2-9c68-ab8be0080030@amd.com>
Date: Wed, 26 Aug 2026 13:50:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/6] tools/arm: choose GIC version explicitly instead
 of relying on GIC_NATIVE
To: Julian Vetter <julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, Oleksii
 Kurochko <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
 <1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3@vates.tech>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd7e5000c4f3@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000A6730:EE_|LV3PR12MB9168:EE_
X-MS-Office365-Filtering-Correlation-Id: 7b2fd55e-bcd5-4282-d36e-08df036832de
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|23010399003|82310400026|1800799024|7416014|376014|56012099006|10067099003|6133799003|18002099003|22082099003|11063799006|4143699003;
X-Microsoft-Antispam-Message-Info:
	tTCDZ+T6+Z86kHfwXGyGTAuuZvmKh1p86sFA8Zu4fwrKXK+U3vwzGHNj/5BGI7T0XrSkj6sOhD1jPfqDrszeVv+kCqiZggLV9ZrlfEmDTiDhhC8iGliGBSLV4xLHSuqZfrfsUZ/gdbH6vCPpAOwsJtraknBcUpvmroEHQ2TC2H2H0gZx8rAhMfkkiLYt+PWUMEkHmRR+yJy00z+pIPvpF2/ORe/k7meXpohaE8PE+whV8TXeY44fgU/dKpb3hfq7bavsbdohCDrmCetAaUx4//77D+7R+Y4kBNAKC8U25WjuHqwWiP0fAs86DJTjs4p7ZNijce5gNgIOwa5Qgk8cka43lyhNe1W7RH7psaND5xvuevrm6cDejTQwrybYPSfooXRR2S+VFLc4NkNyo5QRPioN81oR9XiwigRf9h6rBqKEbMVHz5ZEwvPcuvGrGl6I6lmFHC/deFScjxJBVwUzJQym5FsLWSQtejebj4tKdUCYRJIWzothrezeI0at3s8qkQUKIdsyL4JYzkwcKeSPwUWGCd+WXX/oav8UWmfvSk9tj44K4rM+j2WutswfaiQPLNlEfqp1j4uwxEjtn5C8QxBZee7Tt+1TtB8XcKwdGh7CaEylDeUXm7fgEeDWH2aNr97K/UNHwhYZ4m4OUNQWzjlCaT2v8lzxmF0gGU4AaupZCY8p8gu8Ev2fzRdOsDHDJatr6k6gffWq1/E/utbbgg==
X-Forefront-Antispam-Report:
	CIP:149.199.90.133;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:unknown-90-133.xilinx.com;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(82310400026)(1800799024)(7416014)(376014)(56012099006)(10067099003)(6133799003)(18002099003)(22082099003)(11063799006)(4143699003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	wgQkW+lGr+aSZ2KlX0w5viZFYwm4QNtjzriltWSV+JGLnrb2JP1j49uuDO2FOdddIj5soXt0bJjQnuV69dHLhtypIzlJeOVBOZHEsZwuDsVP6PqVBljGAq0jtBmIEM0Q74dYJW86Zq8fSMjjFPKBjMZXRn79y4xAxETC8IPrqYDD49tGOmhhiAI+nBptycw5XOc+nKjXW6MkX4Ckz0XMv+uksT4ezRzVM/Rs3dJpXnwDSPzj0QC1W6DcLNDlN9FpiWwg9+Yegi3eutUpD35A+TBXqChGwOFGTV2sBkdhPtKXEGN1zsuhEEX90iBOvXMGIpO6EDxut/jdtxFtwZXbzg4waAlGmvdpXBKyH6WKiaR61vup72O5gCDphw1SHNq2uVcCBNOqom7McO/Jxmme2lvbfU1fSsK3OeZuMZd1AME3pTrSLERjhtJroZJyApVr
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 11:50:17.3538
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b2fd55e-bcd5-4282-d36e-08df036832de
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[149.199.90.133];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000A6730.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9168
X-purgate-ID: tlsNG-d62444/1787745022-1F46D757-1A8A4247/0/0
X-purgate-type: clean
X-purgate-size: 2755



On 20-Aug-26 14:40, Julian Vetter wrote:
> XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently
> resolve the domain's GIC version to whatever the host hardware has. Xen
> then writes the resolved value back into the same in/out
> xen_arch_domainconfig the toolstack used as input, which is the kind of
> API abuse we're trying to get rid of. The struct passed to createdomain
> should only be an input parameter.
> 
> Move the "pick the best available GIC version" decision to the
> toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits
> already exposed via XEN_SYSCTL_physinfo:
> 
>  * libxl__arch_domain_build_info_setdefault() resolves
>    LIBXL_GIC_VERSION_DEFAULT to v3 if available, else v2, else fails,
`LIBXL_GIC_VERSION_DEFAULT` should be renamed to `LIBXL_GIC_VERSION_NONE` to
denote that the user did not set any particular version. With your change there
is no default and `libxl__arch_domain_build_info_setdefault()` resolves it
before anything else can see it.

>    before the config is built.
>  * The Python xc.domain_create() binding does the same via a call to
>    xc_physinfo().
>  * libxl__arch_domain_prepare_config() therefore only ever sees a
>    concrete v2/v3 request and just validates it. The GIC_NATIVE case is
>    dropped since setdefault() always resolves it first.
> 
> This guarantees no toolstack path can still produce
> XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the
> Xen side and from the ABI entirely.
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v4:
> - Fix a missing closing bracket in arch_capabilities_arm_has()
> ---
>  .../include/xen-tools/arm-arch-capabilities.h | 17 ++++++++++++++++
>  tools/libs/light/libxl_arm.c                  | 17 +++++++++++++---
>  tools/python/xen/lowlevel/xc/xc.c             | 20 ++++++++++++++++++-
You need to update the documentation (i.e. xl.cfg) too.

>  3 files changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-tools/arm-arch-capabilities.h b/tools/include/xen-tools/arm-arch-capabilities.h
> index 4aa4c6c34a..ce1b3bdd71 100644
> --- a/tools/include/xen-tools/arm-arch-capabilities.h
> +++ b/tools/include/xen-tools/arm-arch-capabilities.h
> @@ -6,6 +6,7 @@
>  #ifndef ARM_ARCH_CAPABILITIES_H
>  #define ARM_ARCH_CAPABILITIES_H
>  
> +#include <stdbool.h>
>  #include <stdint.h>
>  #include <xen/sysctl.h>
>  
> @@ -25,4 +26,20 @@ unsigned int arch_capabilities_arm_sve(unsigned int arch_capabilities)
>  #endif
>  }
>  
> +/*
> + * Generic test for any single-bit XEN_SYSCTL_PHYSCAP_ARM_* capability, e.g.
What makes the implementation single-bit?

Otherwise, LGTM.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 11:57:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 11:57:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399838.1635805 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCG3-0002JF-3i; Wed, 26 Aug 2026 11:57:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399838.1635805; Wed, 26 Aug 2026 11:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCG3-0002J8-0S; Wed, 26 Aug 2026 11:57:31 +0000
Received: by outflank-mailman (input) for mailman id 1399838;
 Wed, 26 Aug 2026 11:57:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCG1-0002Hx-Oe
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 11:57:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCG1-00D3Cr-1M
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 13:57:29 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed49a-8faa-0a2a0a5109dd-0a2a4504bfb2-16
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 13:57:28 +0200
Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed4a8-b57f-0a2a45040019-d155da30ac7b-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 13:57:28 +0200
Received: by mail-ej1-f48.google.com with SMTP id
 a640c23a62f3a-c2530cabcf4so18463866b.0
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 04:57:28 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9b2817sm465635266b.53.2026.08.26.04.57.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 04:57:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Content-Language:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745448; x=1788350248; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to
         :cc:subject:date:message-id:reply-to:content-type;
        bh=YC0UNEN4nZ3HK0sJ7RDWvZcwbOtHVAF0XSsvZEItZHE=;
        b=IFiesb6Ne9Fxk8U+LmenJxUhA7Prjp+AGWXvT49htMNG8ZGTdt1cXOUDlnuntvFsHB
         7HJqLDcStn2hNoT/yChpbnwDzA2nm1wv9riHO5DxBKqv3t4JcO282I6D2T6KJKSvXUuV
         C9NjWHNrscAY9ry3SSdBasmKNwvc0uByCkj9BdTkHJiQTimJe0TFlo37Vj9Q3RiLin4c
         0jxmKeioErFcRWK6Vxjcd7zVHt8zT6YawU98tlYFCERPE6HUZ05azlEx0hO1BVL86/oO
         +YSETAotNO+C846aZ61WVoFF/eDWh4vtiIlNG+j8gNx4aPF/YaQqMdH9VrF1WEHlI/p8
         hwZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745448; x=1788350248;
        h=content-transfer-encoding:content-type:autocrypt:content-language
         :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=YC0UNEN4nZ3HK0sJ7RDWvZcwbOtHVAF0XSsvZEItZHE=;
        b=DGLa/+zJYhDmtv2d2pCtB7mh/BV7zGc9nKQ6x/KcEPzgyBqlJBKGC2svC7a5aLXwxi
         cNnqhyAXCRT9IHRFXAbFmABDLZH4yzcWxMDYHIgWqPCw7nuFh+JoAt1yjCAlqEukj4Nj
         S7RUrlyn8NbGF1bRMGIn64fIU2M1roqbEScSE6S0mtIki6S3u7V3GH9cO7g31baVGSp6
         3Sald8Y9ciLb5rOuatP3940xSnH4ed/etksttxKvAVyfbyS5c4uBbPH1Wg9TKeygyamn
         sYGR2kQWgpVWVfTYjSMephawDfboR5gHrvzgJT7Ha0rnFj5/5/wGrpJ/fKms0n9Hc6Xp
         ilZg==
X-Gm-Message-State: AFuF++kPidaz3d88OGaVRhy14rYoze8WZokYb4jK+emEJ0AeuqZSSjUx
	A+MF2WPR54LyAaw7izvBvpuyHF9IJEVptPt9LpcKxRetv4MCrp7n73U8AXbVRffOdl1HXTCMW7r
	s7Dn5MQ==
X-Gm-Gg: AR+sD109Zw4EeZpqdqEaj1tfhk9e1Ol1s9x4qjn/4S+1ttGmwz/9zkr9LDYvttrRtpI
	LuRZPkuHf4Cbh/CYUG5lxyvshio+QQu6HDy3q7k+pDpK/5Rvrqt2yWQrAH8BD/1cp8Nz8/7aKCw
	ZRWvZhDK91EKFpLseEVuoWj7FnxUeXPlqLP8G4Seuu/ox6ojFkx3yCiLqy3g7+22ZvRpf1lTIBp
	7o8fsXL/n01qS7YmvQDJRMtPQK9Ro5zCT0m7qbBLL7GLpiUGqMU9vlQO7fu/7/kD/RjKziYcoky
	PV5QpisN+fFbjT5tlYntfI0u059gaeOSQ0E7Dcn6+tCQjS8r3VDlhBwuhXp2VlA1uChDyzt96PF
	b6fNEFSwMCpokaflEeaAyLVcJJDx/Hj/wFD4D8X6RErQAhWKpGVDq7SdgVJnSI/2KMSMaRdSdvg
	FPimsJ1ZjF+x5LAnjbCirLSBVutSAKCKp/Ig/wTh0YZVBenf1YxoP/1HeuI68QNCxULsl4yCoWQ
	PuqVqXptox77EGiKPLSk1q8FarSgqGo4UbV/JT2WgVkiHKCBs0te60eszn3PrI=
X-Received: by 2002:a17:907:7249:b0:c21:752f:c3f7 with SMTP id a640c23a62f3a-c250bc127b0mr792726366b.18.1787745448459;
        Wed, 26 Aug 2026 04:57:28 -0700 (PDT)
Message-ID: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Date: Wed, 26 Aug 2026 13:57:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v2 0/7] build: split and unify linking of final image(s)
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787745448-518D1B50-217AEDDD/0/0
X-purgate-type: clean
X-purgate-size: 854

The monolithic rules, largely but not entirely identical between ports,
were pretty ugly to fiddle with. They also ended up going out of sync
when really they would better have stayed consistent. Break them up,
and use (largely) the same rules for all ports (x86'es xen.efi being
somewhat special, though).

The final three patches are related only in so far as they address
observations made while doing the conversion.

v2 addresses an install issue I had noticed too late, and has one new
patch. See individual patches for details (if any).

1: x86: split xen-syms/xen.efi linking rules
2: Arm: split xen-syms linking rule
3: RISC-V: split xen-syms linking rule
4: PPC: split xen-syms linking rule
5: build: move $(all-symbols-*)
6: build: move $(compare-symbol-tables)
7: RISC-V: place .sdata / .srodata / .riscv.attributes

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:00:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:00:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399846.1635814 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCIv-00041n-Js; Wed, 26 Aug 2026 12:00:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399846.1635814; Wed, 26 Aug 2026 12:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCIv-00041g-H4; Wed, 26 Aug 2026 12:00:29 +0000
Received: by outflank-mailman (input) for mailman id 1399846;
 Wed, 26 Aug 2026 12:00:28 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCIu-00041V-08
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:00:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCIs-003gjf-9q
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:00:26 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed557-2eae-0a2a0a5409dd-0a2a4504c16a-10
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:00:26 +0200
Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed55a-b57f-0a2a45040019-d155da29ec46-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:00:26 +0200
Received: by mail-ej1-f41.google.com with SMTP id
 a640c23a62f3a-c2022323c37so109569966b.0
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:00:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a5d62easm471153166b.6.2026.08.26.05.00.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:00:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745626; x=1788350426; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=fpxZNvLH3hGMzLfQMWG/zcRVETLgvOyxelfjtLNifPY=;
        b=dxbiUKv3Z3mUNZ5Ml3ROYUbSlzFmxBoWSATDmEBRcAn9k6cRjbbulb3U5bZ7jYtYP8
         +a/Mnti/jjA0NikPcjhu2Mp3oye9E0m3szBLHK6KUdrcqiwG5GSyL6QbCwz864DxxqdO
         OiW0MTwR5BFNeZeumLJLn5mwYOYG6WUUE22cDXOd2u1qm5+aaxt8Ng21NIgowK7jt4zq
         qafkHVipI4WnF0vuRa7hQulCdwX1rRxOVZdC7jbkVilH7vld7pAjrsid8JyX7lVgL5Rm
         luRAYuigGfQIghOEHS1dIF2Npr3IqZ0h5Wa0JexSAGH/6MC/uABurMCMROBtNrU9KSwQ
         fSug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745626; x=1788350426;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=fpxZNvLH3hGMzLfQMWG/zcRVETLgvOyxelfjtLNifPY=;
        b=CXVQk1m9X3Fxz8vlqdAjjtPCGpGMXtVEKovqGqazGN5dNRt40XXfX+PxSP3EJpexxc
         W4wR9NqB/mzFC0xUZRTd6l+jKXWaPtrT/82QBn5rRgXy+zwb0vNqoG0XaHoKx5IBL5nW
         fskJJb+9UcYZQ+khWEaoZWQ9+2i9AFBRg7eMw+EQ2+LK1EaccdAoB7n6loNQtn4eTqVT
         XRK0AIwx4uRlpiqtKKpHxj07PKHG+EB7D0MzLkauZ1eozUO4KK6saxvd2dexVyORlx6y
         IWuXO85yNPFQQBLXFs+fORYaiWWv/5/4B2QVLfbF6X2FPEAg0VYxu+qsQji/m1ubU6+1
         KYPw==
X-Gm-Message-State: AFuF++m9f4BFn2bPBqb4LSCQAJOoFn02djqiTyVvXtvZGRzUewUIiJih
	4YnPHL8tSaa0Od7e6kpvqHWwJTzB3HUSO9TztdamEfhk6pyojsBRB+1ArBDYIzcvwPiufpSmdQp
	uRCKBlA==
X-Gm-Gg: AR+sD115gH7PSUdwcZR2HtpwAcjiI3jClzC3v55CAxmI92m8VbobDC/UXhbg+mp0mFl
	gVI2pf+cpwAtfSy6Af9DP9Hl9jIv7JzvpC3ApsSK0wFGKkIidT0MLfDwpis0xD9XT0FxEOXAeVG
	xbDO4eP80bHXeItj7qelTNk50VUltYxauzCNB5TC61ekKbGY8DyPaKTY6s+YliUBYZViqnTB0Y+
	yVIIIhUKWMwVdgYHwPaJXoJkXfaEYYvboD0yyj18v6LRP3zh9Yg/02/kI7vgbtzoUDJC07SlVek
	6xWt4pO1Lg7wWuYp0os577nx7dukgIbZUmxubQXXGdJkXB5ehBixD6TqK3D8CImPH66+AWntEnb
	5kSvXEe8HcrtfZRA1nD6odkQxnC6UZxy24NRsTFbIZqll/vekoJeFIPeVU1fqZSgZtCzR+ADMLa
	fNoBH8I3NLt8+bXzlwbSG2khWQGPMkLcfQ198G7iIAoJpRGBzmCNavKTFv4MtiJJWk+aRkq416n
	SzrxSxDe2QbEfKR7RDQ9FacUXFAtL/Zf7eVRJuUhHLm2Wrs1p4Guw==
X-Received: by 2002:a17:907:e1d3:20b0:c25:d03:6794 with SMTP id a640c23a62f3a-c250d036dcdmr570529266b.16.1787745625231;
        Wed, 26 Aug 2026 05:00:25 -0700 (PDT)
Message-ID: <8e1b4212-ddb6-424a-91cf-ed80d985825c@suse.com>
Date: Wed, 26 Aug 2026 14:00:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 1/7] x86: split xen-syms/xen.efi linking rules
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787745626-C2AC8B50-32C3FAAE/0/0
X-purgate-type: clean
X-purgate-size: 10503

Doing so, besides (hopefully) adding clarity (not the least by way of
using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations. For xen-syms move re-usable helper rules to a new
scripts/Makefile.link.

While doing so, re-order .map file creation (which can in principle fail)
and check-endbr.sh invocation ahead of putting in place the final image
(which is now the result of a simple rename).

Also drop --source-name= from the tools/symbols invocation which has
--empty passed, for being meaningless there.

Note that the original "rm" at the end of the rule needs limiting:
Removing intermediate files (which $(MAKE) doesn't itself remove) would
cause re-linking even when installing as root (when common/version.o is
left unaltered, and hence an incremental build should do nothing as long
as nothing else changed in the source tree).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I'd like to keep the "beautification" part, i.e. transforming to more use
of Kbuild.include machinery, separate.

The check-endbr.sh invocation doesn't fit neatly into this model. I was
considering to move it into $(TARGET)'s rule, but that's not very nice
either (both because it'd be odd [strictly speaking: wrong] for xen.efi,
and because it would reduce parallelism).
---
v2: Mark intermediate files as such. Don't use $(if_changed ...).

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -102,12 +102,6 @@ notes_phdrs = --notes
 endif
 endif
 
-syms-warn-dup-y := --warn-dup
-syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
-syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
-
-orphan-handling-$(call ld-option,--orphan-handling=warn) += --orphan-handling=warn
-
 $(TARGET): TMP = $(dot-target).elf32
 $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 	$(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) $(XEN_IMG_OFFSET)
@@ -119,31 +113,11 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort $(syms-warn-dup-y) \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	$(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o)
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(orphan-handling-y) $(dot-target).2.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
-ifeq ($(CONFIG_XEN_IBT),y)
-	$(SHELL) $(srctree)/tools/check-endbr.sh $@
-endif
+LAST_LINKING_PASS := 2
+
+final-image-check-$(CONFIG_XEN_IBT) = $(SHELL) $(srctree)/tools/check-endbr.sh $<
+
+include scripts/Makefile.link
 
 $(obj)/note.o: $(TARGET)-syms
 	$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $< $@.bin
@@ -191,51 +165,69 @@ note_file_option ?= $(note_file)
 
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc
-$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds
+
+.INTERMEDIATE: $(addprefix .$(TARGET).efi., \
+                           $(foreach n, 0 1 2, \
+                                     $(n) alt.$(n) $(n)r.o $(n)s.o $(n)r.S $(n)s.S))
+
+.$(TARGET).efi.%.o: .$(TARGET).efi.%.S FORCE
+	$(call cmd,cc_o_S)
+
+.$(TARGET).efi.1r.S: .$(TARGET).efi.0 $(if $(relocs-dummy),.$(TARGET).efi.alt.0)
+.$(TARGET).efi.2r.S: .$(TARGET).efi.1 $(if $(relocs-dummy),.$(TARGET).efi.alt.1)
+
+.$(TARGET).efi.0r.o: $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
+	ln -sf $< $@
+
+.$(TARGET).efi.%r.S:
+	$(MKRELOC) $^ > $@
+
+.$(TARGET).efi.0s.S:
+	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+
+.$(TARGET).efi.1s.S: .$(TARGET).efi.0
+.$(TARGET).efi.2s.S: .$(TARGET).efi.1
+
+.$(TARGET).efi.%s.S:
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+ 	    --source-name=$(TARGET).efi.S \
+	  > $@
+
+# See above for why $(note_file) needs removing here.
+efi-objs = $(filter-out $(note_file),$(filter %.o,$^))
+
+.$(TARGET).efi.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \
+                  .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \
+	      --strip-debug $(note_file_option) -o $@
+
+.$(TARGET).efi.alt.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \
+                      .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds
+	$(LD) $(call EFI_LDFLAGS,$(ALT_BASE)) -T $(obj)/efi.lds $(efi-objs) \
+	      --strip-debug $(note_file_option) -o $@
+
+.$(TARGET).efi.2: $(objtree)/prelink.o $(obj)/efi/relocs-empty.o \
+                  .$(TARGET).efi.2r.o .$(TARGET).efi.2s.o $(note_file) \
+                  $(obj)/efi.lds
+	$(call compare-symbol-tables, .$(TARGET).efi.1r.o, .$(TARGET).efi.2r.o)
+	$(call compare-symbol-tables, .$(TARGET).efi.1s.o, .$(TARGET).efi.2s.o)
+	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \
+	      $(orphan-handling-y) $(note_file_option) -o $@
+
+$(TARGET).efi: .$(TARGET).efi.2
 ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)"
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "No debug info in $(@F)"
 endif
-	$(objtree)/tools/symbols $(all_symbols) --source-name=$(@F).S --empty \
-		> $(dot-target).0s.S
-	$(MAKE) $(build)=$(@D) .$(@F).0s.o
-	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-	          $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< $(relocs-dummy) \
-	                $(dot-target).0s.o $(note_file_option) --strip-debug \
-	                -o $(dot-target).$(base).0 &&) :
-	$(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).0) \
-		> $(dot-target).1r.S
-	$(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-                  --source-name=$(@F).S \
-		> $(dot-target).1s.S
-	$(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o
-	$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
-	          $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $<  --strip-debug \
-	                $(dot-target).1r.o $(dot-target).1s.o $(note_file_option) \
-	                -o $(dot-target).$(base).1 &&) :
-	$(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).1) \
-		> $(dot-target).2r.S
-	$(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-                  --source-name=$(@F).S \
-		> $(dot-target).2s.S
-	$(MAKE) $(build)=$(@D) .$(@F).2r.o .$(@F).2s.o
-	$(call compare-symbol-tables, $(dot-target).1r.o, $(dot-target).2r.o)
-	$(call compare-symbol-tables, $(dot-target).1s.o, $(dot-target).2s.o)
-	$(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \
-	      $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \
-	      $(note_file_option) -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
+	  > $@.map
 ifeq ($(CONFIG_DEBUG_INFO),y)
-	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf
+	$(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $< $@.elf
 endif
+	$(final-image-check-y)
+	mv $< $@
 	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
-ifeq ($(CONFIG_XEN_IBT),y)
-	$(SHELL) $(srctree)/tools/check-endbr.sh $@
-endif
 else
 $(TARGET).efi: FORCE
 	rm -f $@
--- /dev/null
+++ b/xen/scripts/Makefile.link
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0
+# ==========================================================================
+# Helper rules for linking xen-syms
+# ==========================================================================
+
+syms-warn-dup-y := --warn-dup
+syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
+syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
+
+orphan-handling-$(call ld-option,--orphan-handling=warn) := --orphan-handling=warn
+
+final-image-check-y ?= true
+
+.INTERMEDIATE: $(addprefix .$(TARGET)-syms.,$(foreach n,0 1 2 3,$(n) $(n).o $(n).S))
+
+.$(TARGET)-syms.%.o: .$(TARGET)-syms.%.S
+	$(call cmd,cc_o_S)
+
+.$(TARGET)-syms.0.S:
+	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+
+.$(TARGET)-syms.1.S: .$(TARGET)-syms.0
+.$(TARGET)-syms.2.S: .$(TARGET)-syms.1
+.$(TARGET)-syms.3.S: .$(TARGET)-syms.2
+
+.$(TARGET)-syms.%.S:
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
+	  > $@
+
+.$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
+	      $(build_id_linker) --strip-debug -o $@
+
+.$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \
+                                      .$(TARGET)-syms.$(LAST_LINKING_PASS).o \
+                                      $(obj)/xen.lds
+	$(call compare-symbol-tables, \
+	       .$(TARGET)-syms.$(shell expr $(LAST_LINKING_PASS) - 1).o, \
+	       .$(TARGET)-syms.$(LAST_LINKING_PASS).o)
+	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
+	      $(build_id_linker) $(orphan-handling-y) -o $@
+
+$(TARGET)-syms: .$(TARGET)-syms.$(LAST_LINKING_PASS)
+	$(NM) -pa --format=sysv $< \
+	  | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
+	  > $@.map
+	$(final-image-check-y)
+	mv $< $@
+	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:01:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:01:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399854.1635822 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCJQ-0004Qy-RP; Wed, 26 Aug 2026 12:01:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399854.1635822; Wed, 26 Aug 2026 12:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCJQ-0004Qr-Ot; Wed, 26 Aug 2026 12:01:00 +0000
Received: by outflank-mailman (input) for mailman id 1399854;
 Wed, 26 Aug 2026 12:00:59 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCJP-0004Qf-Nw
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:00:59 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCJO-007yRD-QD
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:00:58 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed573-8faa-0a2a0a5109dd-0a2a450bd9b6-38
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:00:58 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed57a-b7e8-0a2a450b0019-d155da36d8fc-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:00:58 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c197e7e4e94so126656666b.2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:00:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5de8d1c80sm3194925a12.10.2026.08.26.05.00.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:00:56 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745658; x=1788350458; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=Q+1gClmmk9yATyoZyczF2GlL3Oy9KQPuz5fqFvtjMX0=;
        b=dVTuJhhBvxdBGBfYzXJRdhFiAZu0fEEh3y9nDc9LXsyjQHfJtLg66yqFBXzG/As4k6
         kgc/E7fp5co2uKAfQHdK6O2F4lhuxyxJmQlpPgjEiBYsZT0rXSThSxyECZvkSl5lVbub
         zxCj6b+7T25RDquguNZiB7F6LZ4FGCEjaSmeUhxxiK24WxHI/97OLnKUdz7qKPfVsWWU
         ruJoubYG0rOMw9JrlRfMqIwDIEYOX+wl/y9y9yhdG3m8f5pFvf68jHk9l/vxjl6QBaeT
         8IglTPDVh2jLEf3lEZlFOf8SRuhbdaW5UXX/JKMBDvCorCjIjrpNhwaciN4faWfIQSyS
         0oIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745658; x=1788350458;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Q+1gClmmk9yATyoZyczF2GlL3Oy9KQPuz5fqFvtjMX0=;
        b=lhKc8Gh4bBBimLvmoaQTySiUy49whPabaaOdFHy2klcr02H+pmpIhcr6B4sVbs4iXS
         OBsAGwBtf/dUPK1B7lTY5hHaLiejf4V4NWfYSmd8fQkG1nhBo0Gp3odDQpPeRZ+VikhR
         EZEKP8i+/FXQkfnlrC2UBS8a9WzWHNaDLgzR6a+aaE0vYGHyYdze22ttiWuEr6V1gfBc
         +vLsEy8WcToVaJCNGT/iU0FXMNPq9rTqrrsAnt5Efo0kOfhzYpfejss4BdO5X8RX/JS0
         /07QPe53KA1o9csdtKgDO6kAVLp+/S1Ele21cNz/wlC4pirO3iNyK3n5saT6q9WYA1nf
         MF/g==
X-Gm-Message-State: AFuF++mOXGSeNbVVE+1QvcSuvI6PJFJYKKrZalDga//Y8X9FpqAZYOUo
	mR9y5pREANk8bAjKmGnjZTlKJr6uRzLGLxNFzjwc/BQlU9EbqzQVq5pgFJ9+USvsdWEz7izCcx2
	G1R+5dg==
X-Gm-Gg: AR+sD10XiWGqZBWAlh7kwH121tfJagDTvlbCwuTOvToVMi6+Lc1mCpmeQZgHnOAYRO5
	djmxDfVBkq/6FSBfk3nvtutaZpae+2ilWjFG1q8mLT5wKaz9MCU8dTU6NV5j+3M9AyLowmPU0kz
	9cK8zLcZLdBK9bHv54Bdx/UJzkiKzDUF5hsCQlLGLyAbhpRbHciBKb5jIyrBSvOgz87GmGewWSA
	gFd7Uuf9tF/brxWtIDXWZti2cUnSjjJu2vg3JDHOZTaozXVF2YVTd/fjomjPB3BCl1UdsXhCCXF
	jBKOrhTNmb9Ar5rRl/7acomMYVF+Yt8bBPy9wZhqUjK1wxRwUgT7Svo7xl6DhT+B7VRH9yzmnrd
	qOtDtdmJwiBYgLe0AD9C4udomhfC0uk6CBdGYDZIqYOrreLTxJPWoDxi4zFmQ4RekbaIJ2BP//N
	+/CamZpVH8uP4IPjIL9d0czSy/+0Rzi4N6dNoRj7rbGzEkwprir5/aaKKpgCneOQhJPoR0D9aMV
	lWfi4Cm5ZLaPfr7Ikk2Bf00jrLqEyqm/K7U+C6/Mr0mUfMg3G9kZA==
X-Received: by 2002:a17:907:d0e:b0:c1f:c7f0:b433 with SMTP id a640c23a62f3a-c250bc09ef9mr830455966b.9.1787745657993;
        Wed, 26 Aug 2026 05:00:57 -0700 (PDT)
Message-ID: <483052d4-b70e-4005-8b10-4ecf509bf40a@suse.com>
Date: Wed, 26 Aug 2026 14:00:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 2/7] Arm: split xen-syms linking rule
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787745658-A9EC69EA-9C085975/0/0
X-purgate-type: clean
X-purgate-size: 3821

Doing so, besides (hopefully) adding clarity (not the least by way of
[re-]using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations.

By re-using the generic rules introduced when the respective x86 rule was
split,
- the .map file now isn't created after the final binary anymore,
- --strip-debug is passed to $(LD) during early linking passes (for
  consistency the option is also explicitly added to the optional linking
  pass rule),
- CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
  now properly respected.
Orphan section checking, otoh, is getting suppressed for now, until the
about a dozen warnings which would result have been taken care of.

While the 4th linking step continues to be avoided when possible, a
redundant invocation of $(NM) and tools/symbols (plus the assembling of
the resulting .S file) is hopefully deemed acceptable.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
As for the x86 patch, I'd like to keep the "beautification" part, i.e.
transforming to more use of Kbuild.include machinery, separate.

--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -84,40 +84,12 @@ ifeq ($(CONFIG_ARM_64),y)
 	ln -sf $(@F) $@.efi
 endif
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
-	then \
-		set -e; \
-		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-		    $(dot-target).2.o -o $(dot-target).2; \
-		$(NM) -pa --format=sysv $(dot-target).2 \
-			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-			> $(dot-target).3.S; \
-		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
-		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
-	else \
-		ln -sf $(dot-target).2.o $(dot-target).3.o; \
-	fi
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).3.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+LAST_LINKING_PASS := 3
+
+include scripts/Makefile.link
+
+# Suppress orphan section checking for the time being.
+orphan-handling-y :=
 
 .PHONY: include
 include:
--- a/xen/scripts/Makefile.link
+++ b/xen/scripts/Makefile.link
@@ -33,6 +33,19 @@ final-image-check-y ?= true
 	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
 	      $(build_id_linker) --strip-debug -o $@
 
+ifneq ($(LAST_LINKING_PASS),2)
+
+.$(TARGET)-syms.2: $(objtree)/prelink.o .$(TARGET)-syms.2.o $(obj)/xen.lds
+	if ! { $(call compare-symbol-tables, .$(TARGET)-syms.1.o, .$(TARGET)-syms.2.o) >/dev/null; }; \
+	then \
+		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
+		      $(build_id_linker) --strip-debug -o $@; \
+	else \
+		ln -sf .$(TARGET)-syms.1 $@; \
+	fi
+
+endif
+
 .$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \
                                       .$(TARGET)-syms.$(LAST_LINKING_PASS).o \
                                       $(obj)/xen.lds



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:02:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:02:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399862.1635832 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCKR-0004xz-5S; Wed, 26 Aug 2026 12:02:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399862.1635832; Wed, 26 Aug 2026 12:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCKR-0004xq-1v; Wed, 26 Aug 2026 12:02:03 +0000
Received: by outflank-mailman (input) for mailman id 1399862;
 Wed, 26 Aug 2026 12:02:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCKP-0004xi-0f
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:02:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCKO-007ypd-Dl
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:02:00 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed5b6-8faa-0a2a0a5109dd-0a2a450cc15e-12
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:02:00 +0200
Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed5b8-f479-0a2a450c0019-d155d030a904-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:02:00 +0200
Received: by mail-ed1-f48.google.com with SMTP id
 4fb4d7f45d1cf-6a156627e22so3714199a12.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:02:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a6fd676sm480327466b.17.2026.08.26.05.01.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:01:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745719; x=1788350519; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=JoSzWl9u/xDhO1ZqChlyScExhg2WyeKTzD6iriK6Voc=;
        b=e/g0LNKNCWo355GYtsuRfOvg6lvT9qmGn7BviBR86tGpyzlsgocFJZGwFQajsZXkbI
         g/PLGjcqqyIh4it6S2sQWvCKs3+KI7rnU+OzoAAixya7ovAxwSC5AtkLRUhUgobDLMZK
         r8c50g/4W1ViXfpUNeZJ2kS+rjz7fbl25UaGvdnaju2tNvK38LMMpoRjvFXmkJleDBf8
         x2P09Uxb2IiN2DirnxdCWC69s1uqy4Ty4jxlIr8ypAot5HmgJxFDD11ZalstdoHEsUX0
         GK/1St1AEYS1duafTPh/wJaZQ2/5Dg83vPlbdowF73lzZD+IUL7E7bs3dNUUl5JlDj5j
         6lLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745719; x=1788350519;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=JoSzWl9u/xDhO1ZqChlyScExhg2WyeKTzD6iriK6Voc=;
        b=DOrxEPKhM7GTK2X5PH6lQSAAiboI1pvG1lHviUbFyjD0udgGMeEnvMU6WQSwCdh5sy
         nQGf9IdCqlqnjjiL2EGmBlP+A4OY+ATdTIx+cj1dKWkMyTzYEnfLXOCuOuxwAC1ysCoz
         BmE7G7iPLXuUTwhRaNeNeIjO7ltkDxWrXhnOKnrNzBd4pfd0WALELjyxu3hEoIc8lJbG
         Zxee0Okp+eR2vFBe2ee5SwiwGjaUzoIVy69T2fDYLTQwK9UJlB9yixH7VaFxkzzhqTpc
         tsPvcjH1Jmt4J7SsVl48RemHNIuewZzfl5mjRN24PZcjahMzpRzzeZGBFhBqK8+iUvV1
         4N9Q==
X-Gm-Message-State: AFuF++lh4mYNEPSjK5cOWaAIXjfpGlHzBZOEScW2Ga+saQl2/5m8zxsJ
	b5CC+FYm/LlJn0d/0/MZ0iJYvNaOqu1AXzYGPu2rCyN2dYn34d0uEYnqYPcPqiijT23NXBbgB+M
	VaHTTqA==
X-Gm-Gg: AR+sD135L4tCaR2nXDymVNBWAM2CvgLmDJHt4Fcjlhul1k0HqqMY8+cEYuH4QIeFx8n
	wPvVLzJ2zCf0Dhi/+ULv35psq+Ghy6C+5j8o4NDGPdJs/k5f2yaCLz0EWmSGoYVK/oEpUIVjXRg
	P8iQxWEQEE0XHCGV0QSdTtbeUipKnaW1YJCeOAkfJ179fIDtQILFuVrephIxwqpz2fAbOqOxnYK
	U5bEyUl5DiFNU65n2cTWPylxUGUnDibTcLZlLiubZmwoem0wyyvDXb8vJGW3DkZaHZo/Bt9PrAx
	kOPDy+F8KkvatndZvnUc9exVPwvgZ+9k65ib32XwmRgrZQytj8JMS3S4CA7Zc3ynQrgvtBZ+M6m
	FpvQfSnpzDzqufpyCwjexfSqvcuokazt5sRhw+4Z+jVXbT3KYvEwjwpAKDugogcaLxf6Y8TfehQ
	amUf519sdYXQf848c56vT+5vJb5Lx0PS89G01WCQqEyDpBbUHfYZSf2CmPZ5nh4NgR95tl7faIy
	iM+/IkBcp9LX+/W1YeaPGJC2/VodtzfHXFKxEZY4Ot6rhsFM5aU
X-Received: by 2002:a17:907:a0cf:b0:c1c:49d9:4c34 with SMTP id a640c23a62f3a-c24e2db3d7bmr1737380766b.11.1787745688069;
        Wed, 26 Aug 2026 05:01:28 -0700 (PDT)
Message-ID: <6f4b26ce-2797-4c17-bfdf-8effd2026a6a@suse.com>
Date: Wed, 26 Aug 2026 14:01:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 3/7] RISC-V: split xen-syms linking rule
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787745720-014C7A5B-4E4DC9A0/0/0
X-purgate-type: clean
X-purgate-size: 2927

Doing so, besides (hopefully) adding clarity (not the least by way of
[re-]using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations.

By re-using the generic rules introduced when the respective x86 rule was
split,
- the .map file now isn't created after the final binary anymore,
- --strip-debug is passed to $(LD) during early linking passes (for
  consistency the option is also explicitly added to the optional linking
  pass rule),
- CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
  now properly respected.
Orphan section checking, otoh, is getting suppressed for now, until the
about a dozen warnings which would result have been taken care of.

While the 4th linking step continues to be avoided when possible, a
redundant invocation of $(NM) and tools/symbols (plus the assembling of
the resulting .S file) is hopefully deemed acceptable.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -31,40 +31,12 @@ obj-y += vtimer.o
 $(TARGET): $(TARGET)-syms
 	$(OBJCOPY) -O binary -S $< $@
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
-	then \
-		set -e; \
-		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-		    $(dot-target).2.o -o $(dot-target).2; \
-		$(NM) -pa --format=sysv $(dot-target).2 \
-			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-			> $(dot-target).3.S; \
-		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
-		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
-	else \
-		ln -sf $(dot-target).2.o $(dot-target).3.o; \
-	fi
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).3.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+LAST_LINKING_PASS := 3
+
+include scripts/Makefile.link
+
+# Suppress orphan section checking for the time being.
+orphan-handling-y :=
 
 $(obj)/xen.lds: $(src)/xen.lds.S FORCE
 	$(call if_changed_dep,cpp_lds_S)



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:02:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:02:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399863.1635841 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCKW-0005Cg-Eb; Wed, 26 Aug 2026 12:02:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399863.1635841; Wed, 26 Aug 2026 12:02:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCKW-0005CZ-BO; Wed, 26 Aug 2026 12:02:08 +0000
Received: by outflank-mailman (input) for mailman id 1399863;
 Wed, 26 Aug 2026 12:02:07 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCKV-0005C4-0n
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:02:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCKU-008IR5-Dg
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:02:06 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed5b5-e002-0a2a0a5209dd-0a2a450bc60c-36
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:02:06 +0200
Received: from [209.85.218.53] (helo=mail-ej1-f53.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed5be-b7e8-0a2a450b0019-d155da35b574-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:02:06 +0200
Received: by mail-ej1-f53.google.com with SMTP id
 a640c23a62f3a-c15f020a223so120064466b.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:02:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9ef92csm466088866b.63.2026.08.26.05.01.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:01:59 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745726; x=1788350526; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=z+XcKNuFMvLMilDPsUpM4PMWFJxDvjvamUF6fgbTnzs=;
        b=C9hmPpoxI9AlTed9Xf+JSawc5A6n9bvRgg8l6eMnmbCSh9ROchlGqu2ZUhXSTGTJgp
         DKKQL9UheUFiJTc98R3ccNFhmYkLnVoDnz1DFJPgOg5KRt4mw3qcZ1l7ZGlpNehI44US
         6CyETH9km4ogkp65fbBJNU3gsIJZK0O1bkwTmhHRUDNn1ExCAG0HWBCqLP70utKUqSf3
         47dTfffBsIH5reOczd0mF552VdpsKvoU5PTn/P47pGV/QHoH+m1G6rpOOoKtTezpm0b3
         Eir0SQG4vju/QblKcgZzYWFELSoiYv+YjMQJCg/ODqof5UxElr7H9EgYrAU1bR5koBLq
         NvyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745726; x=1788350526;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=z+XcKNuFMvLMilDPsUpM4PMWFJxDvjvamUF6fgbTnzs=;
        b=a8bwdnFJo9BEqOZMPVaNjN+JdBR0Q0oHxzcXRnrwTKVXuaBug+FKqhpIDiB7eUZKUC
         qia1wPK3DwrZaJVv/q7o4G3M5ON2zjRWPK3ZFn9M3oJcJOY37WOVyZKndEq48kwn3/Mz
         EAX7nev7mOf6IF16dML5ArE2IJ6RXQ8e0ALisTn65kOwfZWUsoKogArtJgZx+klMXHfM
         oWnY1M2LFV2YDexVugUtCXUW7jg+5AbG13EV7fetQPCXXiCPKVmMRVNEIC8ujmH5ZRL6
         I0xIQ6t1eQunxpBRHqqsvva8oKr3zbROYzyd2TgbYATBp6Mn7//akFMgteKfEPJf5hB4
         w/rA==
X-Gm-Message-State: AFuF++l+p6qRjnQGyPgAlkIDCfyGti+RsSV2wg65c2HMOJ1cGRjScU3h
	2cy6wxtCAfne7Rg2n8zYLMo1gsr9mawMHjHyuNqv9tx+xyjqJCdzq5UOVPeXj7XFFBuBYYe+TN1
	rcZ3cZg==
X-Gm-Gg: AR+sD100UlYY/kVQ6eVbtJgUqJedOjOmEyJLxs+LLeG/kcGjQKD03kSLxNsLvinev+k
	gwcBTva9JTnIEEGAuNUfeQktBd7ZcHai4fQEQVc5HYyWzq8/NybHDi5DzNCLWrDSs2xD5Bt3M4c
	lfr3fSKk3NdJh3ISluuoElVN8GTnMBYdZClJhE2XfsCEAXnE5VQjoh3pACgl3odcjS5UuqN2aK3
	VtzWkgyrTFRbpUcNnP24sC/x2ZNVDI4otq6FUhiCkyfEQMmf3DVnAuFPSjCBMBY1lOiCQfqdUtr
	VAR//E/hz7m2CXOMfOiJFYdWh7P1YV0WA398xL+I8SsSewZzLORjhLAr0kYVKmKkqYkSizYJSAk
	1lS5FDC1/dnCRaET7kbvkhEsQToh+ceG6905xdvSQmCtlXskpt7IcuW2YjQQORcRdGgE/5uIOh5
	2B3lxn7WWIVHD4rZv9Xh4wek6oAwQU3b7a1RWIdzeUwWRlSpkBiAlfej9r+WTEM1If3saVUpYpZ
	jK27Yavtpi2a7Fi/ZuR3q6n056YV/r+eiw3PbttU59zIjBVlc8rguhCFR+87iY=
X-Received: by 2002:a17:907:6093:b0:c08:417e:3696 with SMTP id a640c23a62f3a-c250c318ec5mr740932566b.20.1787745723171;
        Wed, 26 Aug 2026 05:02:03 -0700 (PDT)
Message-ID: <85bc5cc5-285e-481f-bacd-8421abae169c@suse.com>
Date: Wed, 26 Aug 2026 14:01:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 4/7] PPC: split xen-syms linking rule
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Timothy Pearson <tpearson@raptorengineering.com>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787745726-196C29EA-0485E033/0/0
X-purgate-type: clean
X-purgate-size: 2219

Doing so, besides (hopefully) adding clarity (not the least by way of
[re-]using pattern rules where possible), also avoids explicit recursive
$(MAKE) invocations.

By re-using the generic rules introduced when the respective x86 rule was
split,
- the .map file now isn't created after the final binary anymore,
- --strip-debug is passed to $(LD) during early linking passes (for
  consistency the option is also explicitly added to the optional linking
  pass rule),
- CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
  now properly respected.
Orphan section checking, otoh, is getting suppressed for now, until the
about a dozen warnings which would result have been taken care of.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ppc/Makefile
+++ b/xen/arch/ppc/Makefile
@@ -11,28 +11,12 @@ obj-y += tlb-radix.o
 $(TARGET): $(TARGET)-syms
 	cp -f $< $@
 
-$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
-	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
-	$(MAKE) $(build)=$(@D) $(dot-target).0.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	      $(dot-target).0.o -o $(dot-target).0
-	$(NM) -pa --format=sysv $(dot-target).0 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).1.S
-	$(MAKE) $(build)=$(@D) $(dot-target).1.o
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).1.o -o $(dot-target).1
-	$(NM) -pa --format=sysv $(dot-target).1 \
-		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
-		> $(dot-target).2.S
-	$(MAKE) $(build)=$(@D) $(dot-target).2.o
-	$(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o)
-	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
-	    $(dot-target).2.o -o $@
-	$(NM) -pa --format=sysv $@ \
-		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
-		> $@.map
-	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
+LAST_LINKING_PASS := 2
+
+include scripts/Makefile.link
+
+# Suppress orphan section checking for the time being.
+orphan-handling-y :=
 
 $(obj)/xen.lds: $(src)/xen.lds.S FORCE
 	$(call if_changed_dep,cpp_lds_S)



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:03:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:03:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399876.1635851 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCLO-0005w9-NM; Wed, 26 Aug 2026 12:03:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399876.1635851; Wed, 26 Aug 2026 12:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCLO-0005w2-JO; Wed, 26 Aug 2026 12:03:02 +0000
Received: by outflank-mailman (input) for mailman id 1399876;
 Wed, 26 Aug 2026 12:03:01 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCLN-0005vl-BE
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:03:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCLM-005gag-O8
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:03:00 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed5f0-bab6-0a2a0a5309dd-0a2a4505b254-26
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:03:00 +0200
Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed5f4-4cb1-0a2a45050019-d155da36dd5e-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:03:00 +0200
Received: by mail-ej1-f54.google.com with SMTP id
 a640c23a62f3a-c15b1da6b82so98913666b.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:03:00 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a6fda4fsm525644466b.16.2026.08.26.05.02.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:02:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745780; x=1788350580; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=/YkZgeYdj2H9TEbe6ZemxBOWAqqSLB5TfcHMI7phaMk=;
        b=YMu/bwNAIX72vNbbQg76rUE2gD8L/kMqn1ngtkqKJIvLBhfsWdSSmks3NInit92Clt
         RkSD4btiaXj+I7UpKPyASy9xdkJ7vJxxxvifBSnj0y27S+RDPOWYW9Vef6R6dmEXQxbe
         cGM8ydTaxq5F/mbOMfhCouhTpYmtZrr6RTvo+q7YI6XMx+r29rrSptEJlyo148pUkDyW
         c88hIqXai0TrJAEBkyxAVn9xBytcwODAL/qV/+XzQVUkBR2b1Mc/ULJ4PmKMP+n/q6zY
         ydmrOgf/iO6Yn2gj9ywe1B+eBVEhbffDSnytREv+gEVRryhPgh3ipv5a7vb3Ov2vSjNn
         2gyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745780; x=1788350580;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=/YkZgeYdj2H9TEbe6ZemxBOWAqqSLB5TfcHMI7phaMk=;
        b=rL/qhNQAMh9MLyT/1rHRQA3QyghumcHrairMWEZYktjZZFA2eGe5gEaShrhFQuSzVY
         Sq7JmQm/XMfrP+qbhY6ZOGwo2Zt4KFJq4PEj0Z3D068gKAGinrogO2J9WDJ0NLZcbe/P
         Hi9p7OVtgux7sZtP5/MxeUaQ2HfL5vUeMw6ofNiuDfoCgHYWScn+5tN7jup2RIPcoRUl
         IjqNDvPyB36Ylh/6LZv8o9iyYO5/LEH7YEPtRcAuuYy/ZhXuQBD2Wk1qtyverEKtHRHP
         +7HbKwtrIhEE6mxfHWb0s9On+29F13jOiT6fnvAjVQlPY1si9Dy4g8htFtgtFKLx6eXx
         21wQ==
X-Gm-Message-State: AFuF++kyaVlcbsKmjbA5BigLTuVFDgTdXgWCPtNaMOXCp8+48mfBz3ef
	vjBREf4CeeWfZHOZr3nm/W3ztAW2mAXksWHgQiQDyBsakJlnbH6IVl6Nlu/0BuGnJa88PMNlw3a
	J6bF+hQ==
X-Gm-Gg: AR+sD11blJ3nwkjBacoi2CU3E6J/zrhBRfOxNRoReW5bIvDz4WjU1k5mPuB+Bj+S+az
	iuW4bN9HrH5hZZ6XEWUkTkoRaoQZJ+VTYcKd4Dnl7XzqTBAgwnlf05Bp5/dtHIT5mCAzagN7oAW
	CPWBCY/24zUvkj13fwuwZiEivnf/VV5hEGFh5n8UmMmOabjbkX9rKP7NIR0uF3UUIkp+aTrSmYc
	r76vWxBbN1QTYgZcpn1XwQA+pyJ1QuzWzybEU28iAucTxrKHrLaBb09Nxf6CzSPmm90ubybfZk3
	OvDu/oKFxaLxmcG4Ro2pig3ciJfrUlruJx4PGtjUMHQPc5XloZF/0HvWHDyQE4cSOupsHUiwGQ6
	4FCg858Zrzpg5DO+098KhQzzqR/rgT7ufaZ7OVScorghHDGiLjZj9c8G+D39iSpIukvqYM5e7ql
	iFaalnWzja3hrnf+AUnqrvaMlvpg/czB78wyfWvGr9c68t4/msSq0S6RDnMPJCeQfyv+bgE49+N
	CLTQTcOGsZqFQRPtQQ3AmHBGVIKgUQCYbAQ3r+h6hSzO7gwCD7e
X-Received: by 2002:a17:907:6089:b0:c25:31b4:5f15 with SMTP id a640c23a62f3a-c2531b46428mr72923166b.1.1787745779652;
        Wed, 26 Aug 2026 05:02:59 -0700 (PDT)
Message-ID: <af402588-3a7d-4923-96e1-f5761b445889@suse.com>
Date: Wed, 26 Aug 2026 14:02:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 5/7] build: move $(all-symbols-*)
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Teddy Astie <teddy.astie@vates.tech>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787745780-728B62A1-213CE5E7/0/0
X-purgate-type: clean
X-purgate-size: 2842

With the final linking logic now consolidated in scripts/Makefile.link,
$(all-symbols-*) also doesn't need setting anymore in (and passing down
from) the top level Makefile.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -465,10 +465,6 @@ ALL_OBJS-$(CONFIG_CRYPTO) += crypto/buil
 ARCH_LIBS-y               :=
 ALL_LIBS-y                := lib/lib.a
 
-all-symbols-y :=
-all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols
-all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name
-
 include $(srctree)/arch/$(SRCARCH)/arch.mk
 
 # define new variables to avoid the ones defined in Config.mk
@@ -622,8 +618,7 @@ $(TARGET): outputmakefile asm-generic FO
 	$(Q)$(MAKE) $(build)=arch/$(SRCARCH) include
 	$(Q)$(MAKE) $(build)=. arch/$(SRCARCH)/include/asm/asm-offsets.h
 	$(Q)$(MAKE) $(build)=. MKRELOC=$(MKRELOC) 'ALL_OBJS=$(ALL_OBJS-y)' \
-	            'ALL_LIBS=$(ARCH_LIBS-y) $(ALL_LIBS-y)' \
-	            'all_symbols=$(all-symbols-y)' $@
+	            'ALL_LIBS=$(ARCH_LIBS-y) $(ALL_LIBS-y)' $@
 
 SUBDIRS = xsm arch common crypto drivers lib test
 define all_sources
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -183,14 +183,14 @@ ifeq ($(XEN_BUILD_PE),y)
 	$(MKRELOC) $^ > $@
 
 .$(TARGET).efi.0s.S:
-	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+	$(objtree)/tools/symbols $(all-symbols-y) --empty > $@
 
 .$(TARGET).efi.1s.S: .$(TARGET).efi.0
 .$(TARGET).efi.2s.S: .$(TARGET).efi.1
 
 .$(TARGET).efi.%s.S:
 	$(NM) -pa --format=sysv $< \
-	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+	  | $(objtree)/tools/symbols $(all-symbols-y) --sysv --sort \
  	    --source-name=$(TARGET).efi.S \
 	  > $@
 
--- a/xen/scripts/Makefile.link
+++ b/xen/scripts/Makefile.link
@@ -3,6 +3,10 @@
 # Helper rules for linking xen-syms
 # ==========================================================================
 
+all-symbols-y :=
+all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols
+all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name
+
 syms-warn-dup-y := --warn-dup
 syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=
 syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup
@@ -17,7 +21,7 @@ final-image-check-y ?= true
 	$(call cmd,cc_o_S)
 
 .$(TARGET)-syms.0.S:
-	$(objtree)/tools/symbols $(all_symbols) --empty > $@
+	$(objtree)/tools/symbols $(all-symbols-y) --empty > $@
 
 .$(TARGET)-syms.1.S: .$(TARGET)-syms.0
 .$(TARGET)-syms.2.S: .$(TARGET)-syms.1
@@ -25,7 +29,7 @@ final-image-check-y ?= true
 
 .$(TARGET)-syms.%.S:
 	$(NM) -pa --format=sysv $< \
-	  | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
+	  | $(objtree)/tools/symbols $(all-symbols-y) --sysv --sort \
 	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
 	  > $@
 



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:03:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:03:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399880.1635859 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCLq-0006Mu-U3; Wed, 26 Aug 2026 12:03:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399880.1635859; Wed, 26 Aug 2026 12:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCLq-0006Mn-Qw; Wed, 26 Aug 2026 12:03:30 +0000
Received: by outflank-mailman (input) for mailman id 1399880;
 Wed, 26 Aug 2026 12:03:30 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCLp-0006LQ-SV
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:03:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCLp-005gjq-9H
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:03:29 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed60a-bab6-0a2a0a5309dd-0a2a4503df2c-16
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:03:29 +0200
Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed611-fae8-0a2a45030019-d155d029e8d1-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:03:29 +0200
Received: by mail-ed1-f41.google.com with SMTP id
 4fb4d7f45d1cf-6a3efa2b38aso1560130a12.2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:03:29 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9ef382sm383284966b.58.2026.08.26.05.03.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:03:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745809; x=1788350609; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=eso5Vy60QRY0iW7T/56aNIKLGvEodCAr0Gzsj7Z1ZWc=;
        b=gNWPHhPOxtKB2VsKod/QIJZGUiOYy6tRBBcyroD8BRBhy/mdqKQKb0FCukZrPo2EiJ
         DBOIAvBsi6o+xLNRbKUH8pwFE33VFRCRQozyNwiMxGsnuygNOjPaHSGi0hfl7S06KEch
         WnolD2j49+4S65kWVY6t9/+QHc4TUEd3ISp04lMO4pLDFdnDK3puoqFNtN6k+X145LbW
         mezmqoax6CxNeSPpObwkKvuR0MLC/gw+hBLVGhARR0pr/8UDaPDaOYRnBTatJAIh/Fe+
         7lWPD3iPeh4qoiljq4EtT55f1kegi+ZpGmopwhNuLRh4n5NHnuJWBi5KTWdG65N2e0k5
         0yuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745809; x=1788350609;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=eso5Vy60QRY0iW7T/56aNIKLGvEodCAr0Gzsj7Z1ZWc=;
        b=mabWoP1RixgoOXrA9WRU6qEf+7KpW2O9mIEMX+eSPnvXpVWsjiG4JZuUpBCnl0e5Dx
         Q6B5kanZEbLVpQPLi1Md6on0Ctfy47kM0RmgeEVmdC6dftckLlrckDBdUkoptDzIYhjQ
         uecI36E0g/uOiz64IhNQ3nPJtzJc7ZET29oQjsSfdVHM934S28h/kXEK4BA+NBEuRD7T
         T7CNr6wIfsU31/YM8nOO3Mp+5WKUHAbQ1GiXyCUB7rw1qQxJ6s9qPfhC+BiFNQN+KAqf
         Up6RFOnSI2PdAtpGQq0euSasdRRrl1en2j2Y8TC1ZKC2SN8mSW0YK1TNpII6D3dAHUac
         y6Hg==
X-Gm-Message-State: AFuF++kY/OZ0fkmhvI5bJn1C/dRnvtk5y4/U3lrTFrRHIDoY2Q+MY3mg
	2/PSwxSnDEM3PUlFPJwKwUSUUgAzsF7J8FwJb003LkSa9mEVH369KxN4kaD2JlPvJEi8wVAkryV
	9syNOZg==
X-Gm-Gg: AR+sD13TggQZFM41bLP12WyYv9hAwclVjpTF1xbfu5B+OFz1DHt/PtFOsFzMRpuJ9jw
	hfSCs78bqx+CrO57Iti4mkG5d+ZyaVRZ9wKbBSSFLcr676GYNVEvWnl+Kz1UFXrx58guPN6GG2L
	MWPzLaU8Fuv8tar7pI0UaTTA1NuPivALEYfb9nwNBTFsHE/20F61dS+HqqDaDPfNqep0R1YxzHv
	hJhdkdH6rb2UF8c0tGu5M9pmgcVCyhE5FbLZy/8k10utjUyP+ecBwJZBAakFcLDgz7gYwsUhTbX
	5mvYhH6vCpz/jBRY0fbm8KgvSU6GkWwn0xfTgWPVuQwxdcOC7A2oKeB+Ct9jEhWOxRyFzYlpALG
	DxWYkLT/yaUxo8iQMiV6fYYPD6KQFuyoDY11oIZh9G23vAOr6MLnIFBrLqfUyVvzS3nBIl7QrH7
	rNQL/wfccvxomMOsxMsiUIkwF/H2W2En5zxkUQcszNvYyPXkk9ZvH4ap/bgZaEYQJnuoJ7/3SYZ
	WWwC4aW/Pq8xYrhJN59GFVxyRhoH5A2QzCL3KCXQQ/UxaWMqdO9vw==
X-Received: by 2002:a17:906:730e:b0:c1f:bda0:a771 with SMTP id a640c23a62f3a-c250c363aa9mr755151166b.13.1787745808567;
        Wed, 26 Aug 2026 05:03:28 -0700 (PDT)
Message-ID: <f569f2ea-cf1f-4e28-8097-f81397368e73@suse.com>
Date: Wed, 26 Aug 2026 14:03:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 6/7] build: move $(compare-symbol-tables)
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787745809-766FB4E9-64F4D46B/0/0
X-purgate-type: clean
X-purgate-size: 1830

With the final linking logic now consolidated in scripts/Makefile.link,
$(compare-symbol-tables) also doesn't need setting anymore in
Kbuild.include.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: New.

--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -56,19 +56,6 @@ define filechk
 	fi
 endef
 
-###
-# Compare the symbol tables of two object files.  As diff's -I option isn't
-# standardized, the name difference of the two object files needs abstracting
-# out.
-define compare-symbol-tables
-    ln -f $(1) $(@D)/.cst.$$$$; \
-    $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(1).sym; \
-    ln -f $(2) $(@D)/.cst.$$$$; \
-    $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(2).sym; \
-    rm -f $(@D)/.cst.$$$$; \
-    diff -u $(1).sym $(2).sym
-endef
-
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
--- a/xen/scripts/Makefile.link
+++ b/xen/scripts/Makefile.link
@@ -33,6 +33,18 @@ final-image-check-y ?= true
 	    $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \
 	  > $@
 
+# Compare the symbol tables of two object files.  As diff's -I option isn't
+# standardized, the name difference of the two object files needs abstracting
+# out.
+define compare-symbol-tables
+    ln -f $(1) $(@D)/.cst.$$$$; \
+    $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(1).sym; \
+    ln -f $(2) $(@D)/.cst.$$$$; \
+    $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(2).sym; \
+    rm -f $(@D)/.cst.$$$$; \
+    diff -u $(1).sym $(2).sym
+endef
+
 .$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds
 	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \
 	      $(build_id_linker) --strip-debug -o $@



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:04:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:04:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399887.1635867 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCMc-0006ss-5P; Wed, 26 Aug 2026 12:04:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399887.1635867; Wed, 26 Aug 2026 12:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCMc-0006sl-2J; Wed, 26 Aug 2026 12:04:18 +0000
Received: by outflank-mailman (input) for mailman id 1399887;
 Wed, 26 Aug 2026 12:04:16 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCMa-0006sa-8e
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:04:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCMZ-00BxmO-LJ
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:04:15 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed637-e002-0a2a0a5209dd-0a2a4501ae1e-46
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:04:15 +0200
Received: from [209.85.208.49] (helo=mail-ed1-f49.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8ed63f-5984-0a2a45010019-d155d031f188-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:04:15 +0200
Received: by mail-ed1-f49.google.com with SMTP id
 4fb4d7f45d1cf-6a3fda88184so1394525a12.3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:04:15 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5de5f7bb8sm4136250a12.0.2026.08.26.05.04.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:04:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787745855; x=1788350655; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=PVJaUDGprniCHOdS15F0kmtFEIvAxLzg9FMvZh5Wvbg=;
        b=KMdC/QqtF/Y8eVryPDTB3FtPMsr/0rIrycpSjMbG8pcfShOJl0EitJWIoXerHerVwS
         zvI4gRXylX0o+TeUqqjMRP1Uk4LiGb+9enl3fDciv7WRabYiFRehBlN0Ap3a6j9sK5yL
         cEi9+no7YdU2cL8HQwUPL2l1W3MwW++DNtji5ssJPxHZj67f/R9re2AiEkJJNr+MZqqa
         SApyPylbrc/jgl7Aw9NCHwXKga8tfHc/VLjCMGdf2NpIsXFXRGsGjxdzEUK+EzqnZ5Ks
         tYJL4UycAmxz6HwlP4yqX0f7ghzxCu7tL/Wx0bE//VjDwpsyKbrtbeby7Z9Zh1kazdpT
         /Q+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787745855; x=1788350655;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=PVJaUDGprniCHOdS15F0kmtFEIvAxLzg9FMvZh5Wvbg=;
        b=idlsWV5xeuFn6Vg2qXYSU454l0ZHxptWsJXX1D0ch2qtdVilylR+34oQKhfgBIHsGE
         lTcvTkB49XMhl9CANskBniun5LBVZkAB7DEomVtK4XSptP0H8DXO+lAiXJoCyzfMenld
         LxpO9V7RI2JKYEpKPkTtSZX/XJ1tBmeyvaP9LrVsY0nxA92LMtd+gDW0Tq8dfj/cm5eu
         b+udMjn0KOF3zkPqWzfV7l6ps5Jrycv6OOLM7e1Yolf/UlwLzvkb6m1gY3lKbtspE4FZ
         tEZHBM1wH+kYtB2nZ0XFjoTtIQ9+lDtFuFBjj4bIK7E96EX1h3DvXYv+g+hvvKavL7kf
         j0Bg==
X-Gm-Message-State: AFuF++lG5+VAC6V9Iqa0HHdmxCYyjcv8AVAe732ZZ6CIG5Ds1L1StUQr
	gkABZNhtWjHi8xulz7O+GDMr2Rg0HcNxrw73nL/ydgJbu31UAoHcz8zf37TENe++4mYPCLMFzwl
	OArQ7TQ==
X-Gm-Gg: AR+sD12miPAVgvDgs6DihHvYRqSzDyNIRZHeJtBYd6AcXh/D5qzybz90m5G4F22VeKt
	c/yvgpvYFeqLizklDiKTzjwvOJK9Ff5arsG7GLNtcx7at+gTteqn8M2vGXk2WurvKWg9UyMx86E
	3XLzNh425WoiGbO2/R6HwcgpI7st2lVWRA0IfOg9q9OocJJHi6hD9kKttZM4ZRoSutQXCCqRTeR
	pQE/1yGJ4pdXM+9UPel+uAFd59IsVnqXTlkFM22CEWTIWdDCv3dJYmd1BK9pHfpxAnWyVbd9BVh
	Xynxdk5WJO37mIC/nKCxDUCraRksRSwzXuqiDuDSvvI4wTjNxh6Srl+pEuXytuycT3jeojcNfCa
	Ib6/ZReSt0OGr4bX3FuN2VYm8TCYlIJEEluCndRvj6sv1OQ2nLc/WO0YmNLewD9Pkpc4nzwmv5t
	6nM4/b5MGHALoP04Mvor+kMcRzqnl2Qqnta/fe/SuFXmiMm6GjT8mkhmbIFNLKdUjV0Ouzh3SlD
	0E9CPR0ZHNTtAJEyuDz4WBNR+j9oMKCBxY83CFcFURpHdRAKz17zpKS4wR+LxU=
X-Received: by 2002:a05:6402:190c:b0:6a1:29ca:681e with SMTP id 4fb4d7f45d1cf-6a5df5e18c6mr7616941a12.7.1787745850414;
        Wed, 26 Aug 2026 05:04:10 -0700 (PDT)
Message-ID: <f26f80e3-0b2d-429a-895c-b8003d1c5a38@suse.com>
Date: Wed, 26 Aug 2026 14:04:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v2 7/7] RISC-V: place .sdata / .srodata / .riscv.attributes
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Oleksii Kurochko <oleksii.kurochko@gmail.com>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787745855-BD341757-289A1949/0/0
X-purgate-type: clean
X-purgate-size: 1611

Of the short-data sections, only .sbss is presently mentioned in the
linker script. Place them next to, but ahead of their "normal" data
sections.

.riscv.attributes can go towards the tail of the image, next to (ahead of)
debug info.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Seeing where .sbss lives, does positioning really not matter at all? I
would have expected that short-data sections want to live close together,
and specifically close to .text / .init.text (seeing that such data is
accessed using AUIPC). I'm puzzled that the psABI doesn't even mention
them, hence leaving it open how exactly they are to be used.

What remains to eliminate orphan section warnings is the placement of
.note.GNU-stack (which perhaps wants dealing with on all of Arm, PPC, and
RISC-V together, ideally unifying with x86) and (odd at the first glance,
but dealt with on x86 as well, i.e. may again want unifying) that of a
number of .rela.* sections.

--- a/xen/arch/riscv/xen.lds.S
+++ b/xen/arch/riscv/xen.lds.S
@@ -44,6 +44,8 @@ SECTIONS
 
         BUGFRAMES
 
+        *(.srodata)
+        *(.srodata.*)
         *(.rodata)
         *(.rodata.*)
         VPCI_ARRAY
@@ -92,6 +94,7 @@ SECTIONS
         SCHEDULER_ARRAY
         HYPFS_PARAM
 
+        *(.sdata .sdata.*)
         *(.data .data.*)
         CONSTRUCTORS
     } :text
@@ -162,6 +165,8 @@ SECTIONS
     /* Section for the device tree blob (if any). */
     .dtb : { *(.dtb) } :text
 
+    .riscv.attributes : { *(.riscv.attributes) } :text
+
     DWARF2_DEBUG_SECTIONS
 
     DISCARD_SECTIONS



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 12:36:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 12:36:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399919.1635892 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCrT-0003ca-QU; Wed, 26 Aug 2026 12:36:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399919.1635892; Wed, 26 Aug 2026 12:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzCrT-0003cT-Nf; Wed, 26 Aug 2026 12:36:11 +0000
Received: by outflank-mailman (input) for mailman id 1399919;
 Wed, 26 Aug 2026 12:36:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzCrS-0003cN-3A
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 12:36:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzCrQ-0085EP-4f
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:36:08 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8eddae-2eae-0a2a0a5409dd-0a2a4502db4e-16
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:36:04 +0200
Received: from [209.85.208.52] (helo=mail-ed1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8eddb4-6ca4-0a2a45020019-d155d034dc9c-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 14:36:04 +0200
Received: by mail-ed1-f52.google.com with SMTP id
 4fb4d7f45d1cf-69c600f76ccso1406693a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 05:36:04 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a9ef4d2sm359613266b.59.2026.08.26.05.36.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 05:36:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787747764; x=1788352564; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=rv3V08n1rNWcfH/Wq0wKEeP+mXrRm3kizeLFPwSWLhY=;
        b=adfZchmCAKiv8NPfyWAXfNBx1SkefDpDM01wpDVZzd9A3I5bxC0tdbYKaHbGBiDNpp
         ZoQvbXhuhw17vV7xEdAVwy/lv6OxLUUDzdYG06y/UZAcwsNiUAqziFVAKUG18PD7Zfzv
         xjDKaUOSsFH94SRLn+SipUsS4mWQhk8v2Lps2Uu9QlU18fvHxeI0E1lJyPlu5br32Ic1
         NxnIZRz1nKT4IMk78ABd1iv3cMD2ocoDNmBbdAQM3Z2nQZkgIrkaOhMd5uqHzG9Ezipj
         yCXcB7ypGiqPv6w0ivuqQduY0TZkdIRSVU/gOw6R8n8HdtWXX5epV60LsuguQ3ntWRdu
         ZmGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787747764; x=1788352564;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=rv3V08n1rNWcfH/Wq0wKEeP+mXrRm3kizeLFPwSWLhY=;
        b=ZZNrJpCAV4U/g+6+7IJE89eM9KveK7Hb67S4+inyRa3xeSkA1pR0gJHXllP7XF781t
         m/V6VIlNm+jEGgoi8cqYgg0lLyEiPFj3O6IChF8KJS96oirOzl4DRItTQ2ie2+y97Jxi
         aNuZ8JvG/kJzLHu5nuSBLJjlG08eA75JpFeScR1FHhP8+473/IXZK4E+iWZepLqlsd4c
         XQVgtHKA0jPoLkjFrD0Imp0glt80ABl+oQlH4ZeurrRt9BTBxYdIuae6828hEA6FsEld
         Ik9KO4swztgT11eYs9quM3UGdkmMIx9WLpKWzvGhehRO4S23YvvdW5HmH5sLQI4rFc9L
         oO6Q==
X-Gm-Message-State: AFuF++nAHNvkrRKpFaXg4OdqxFWg+CtHQx3hui51bnE1HN7vB+xO0FCu
	vYE9yAFtnuyqVJuBoi6tfKe5TMmEj6HydVeag1i78r94K042hS/3IW4gUPwDru9ray/TG4afpiP
	vs83ufA==
X-Gm-Gg: AR+sD12TAIVk7FkdD5SZ+OaSqT7V8tiEaBrefR8YMXbO2MScw2A3JjAFfEETbBzb1mo
	I2NoBpgYRmMKdDNOCKKoCT1h0KompoQJa0XvX2GDR340K+eNANeljAA0EHg3wnEBXxsK2kxiH+9
	zA60JuKnqFzZIUiH3BptWsLygjmz5VDfq0wDE0/Utt20ndRtAjuS5/J9QUhLwPnwoaj9pAHah8D
	+RYrIUPt6w6TJ6ssnGrlVELWokR5LfRjyt6i9hEQd03VN1Zok9QBPDGOQAM9CX1n4wwC+dDVfeF
	EflrdVOepJddl5Jx9oUc2orq9KghlIE9cq6xd44VZa9hrWwPTN8E3gvXjGrJZ9pnRYv8qubya3a
	hOBRfUTLA+dQAz35fQXgmrMwDEa/ElsAAx4DggnUVrAxjHgNSWWOexvvLvwdTczgz6e/bq2sfQ8
	GRP4qP/SsBiCNdzQJEfseJYR6Iz01mILlq7M1Qt5sFHJ/l0lTuHNVQFPMlBvX4F+TwrkAs5Jkcz
	xDl75bHkThJIuGxCSB7lpxxXiDESmTIvcIy2O33c/94oHw/yJbW
X-Received: by 2002:a17:907:72c1:b0:c20:1c9d:8d4b with SMTP id a640c23a62f3a-c250bb05c0fmr805557266b.2.1787747764400;
        Wed, 26 Aug 2026 05:36:04 -0700 (PDT)
Message-ID: <b9c89c9f-20e1-441c-bf77-7da42eafdae3@suse.com>
Date: Wed, 26 Aug 2026 14:36:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, George Dunlap <gwd@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86: always park offline CPUs
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787747764-F18AC2AC-7DDEEEF2/0/0
X-purgate-type: clean
X-purgate-size: 6947

While on AMD (or Hygon) CPUs the situation isn't as bad wrt broadcasting
of #MC, some "multicast" can still happen. Therefore the reasoning to park
CPUs rather than fully offlining them applies everywhere.

Don't retain the dependency on the "mce=" cmdline option either: That
option may best be dropped as well, as not enabling MCE will result in a
shutdown when #MC would otherwise be raised.

Drop the global variable, using a #define (just like common code does)
instead. Outside of common code, simplify expressions / code accordingly.
(In common code we still have to cater for x86 wanting it different from
everyone else.)

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
As it was never actually used after its introduction, we may want to
further consider dropping CPU_REMOVE again.

I was almost certain that we would have at least one place (presumably a
CPU notifier handler) were we assumed no parking for AMD/Hygon. Yet I
couldn't find anything; did I overlook the crucial bits?

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -436,7 +436,7 @@ static void cf_check dump_cx(unsigned ch
 
         if ( cpu_online(cpu) )
             print_acpi_power(cpu, power);
-        else if ( park_offline_cpus )
+        else
             printk("CPU%u parked in state %u (C%u)\n", cpu,
                    power->last_state ? power->last_state->idx : 1,
                    power->last_state ? power->last_state->type : 1);
@@ -1360,7 +1360,7 @@ long set_cx_pminfo(uint32_t acpi_id, str
          * If we've just learned of more available C states, wake the CPU if
          * it's parked, so it can go back to sleep in perhaps a deeper state.
          */
-        if ( park_offline_cpus && apic_id != BAD_APICID )
+        if ( apic_id != BAD_APICID )
         {
             unsigned long flags;
 
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -432,9 +432,6 @@ void __init early_cpu_init(bool verbose)
 		paddr_bits -= (ebx >> 6) & 0x3f;
 	}
 
-	if (!(c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)))
-		park_offline_cpus = opt_mce;
-
 	initialize_cpu_data(0);
 }
 
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -716,15 +716,8 @@ static int cf_check cpu_callback(
         rc = cpu_bank_alloc(cpu);
         break;
 
-    case CPU_UP_CANCELED:
-    case CPU_DEAD:
-        if ( !park_offline_cpus )
-            cpu_bank_free(cpu);
-        break;
-
     case CPU_REMOVE:
-        if ( park_offline_cpus )
-            cpu_bank_free(cpu);
+        cpu_bank_free(cpu);
         break;
     }
 
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -181,12 +181,8 @@ static int cf_check update_clusterinfo(
              !cond_alloc_cpumask_var(&per_cpu(scratch_mask, cpu)) )
             err = -ENOMEM;
         break;
-    case CPU_UP_CANCELED:
-    case CPU_DEAD:
+
     case CPU_REMOVE:
-        if ( park_offline_cpus == (action != CPU_REMOVE) ||
-             system_state == SYS_STATE_suspend )
-            break;
         if ( per_cpu(cluster_cpus, cpu) )
         {
             cpumask_clear_cpu(cpu, per_cpu(cluster_cpus, cpu));
--- a/xen/arch/x86/include/asm/percpu.h
+++ b/xen/arch/x86/include/asm/percpu.h
@@ -1,7 +1,7 @@
 #ifndef __X86_PERCPU_H__
 #define __X86_PERCPU_H__
 
-#define PARK_OFFLINE_CPUS_VAR
+#define park_offline_cpus true
 
 /*
  * Force uses of per_cpu() with an invalid area to attempt to access the
--- a/xen/arch/x86/include/asm/smp.h
+++ b/xen/arch/x86/include/asm/smp.h
@@ -25,12 +25,6 @@ DECLARE_PER_CPU(cpumask_var_t, scratch_c
 DECLARE_PER_CPU(cpumask_var_t, hpet_scratch_cpumask);
 DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
 
-/*
- * Do we, for platform reasons, need to actually keep CPUs online when we
- * would otherwise prefer them to be off?
- */
-extern bool park_offline_cpus;
-
 void smp_send_nmi_allbutself(void);
 
 void send_IPI_mask(const cpumask_t *mask, int vector);
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -80,16 +80,12 @@ void __init set_nr_cpu_ids(unsigned int
 	printk(XENLOG_INFO "SMP: Allowing %u CPUs (%d hotplug CPUs)\n",
 	       max_cpus, max_t(int, max_cpus - num_processors, 0));
 
-	if (!park_offline_cpus)
-		tot_cpus = max_cpus;
 	nr_cpu_ids = min(tot_cpus, NR_CPUS + 0u);
 	if (nr_cpu_ids < num_processors)
 	{
 		unaccounted_cpus = true;
-		if (park_offline_cpus)
-			printk(XENLOG_WARNING
-			       "SMP: Cannot bring up %u further CPUs\n",
-			       num_processors - nr_cpu_ids);
+		printk(XENLOG_WARNING "SMP: Cannot bring up %u further CPUs\n",
+		       num_processors - nr_cpu_ids);
 	}
 
 #ifndef nr_cpumask_bits
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2144,8 +2144,7 @@ void asmlinkage __init noreturn __start_
             /* Set up node_to_cpumask based on cpu_to_node[]. */
             numa_add_cpu(i);
 
-            if ( (park_offline_cpus || num_online_cpus() < max_cpus) &&
-                 !cpu_online(i) )
+            if ( !cpu_online(i) )
             {
                 ret = cpu_up(i);
                 if ( ret != 0 )
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -92,9 +92,7 @@ void send_IPI_mask(const cpumask_t *mask
     if ( system_state > SYS_STATE_smp_boot &&
          !unaccounted_cpus && !disabled_cpus && !cpu_in_hotplug_context() &&
          /* NB: get_cpu_maps lock requires enabled interrupts. */
-         local_irq_is_enabled() && (cpus_locked = get_cpu_maps()) &&
-         (park_offline_cpus ||
-          cpumask_equal(&cpu_online_map, &cpu_present_map)) )
+         local_irq_is_enabled() && (cpus_locked = get_cpu_maps()) )
         cpumask_or(scratch, mask, cpumask_of(smp_processor_id()));
     else
     {
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -67,8 +67,6 @@ DEFINE_PER_CPU_READ_MOSTLY(struct stubs,
 cpumask_t cpu_online_map __read_mostly;
 EXPORT_SYMBOL(cpu_online_map);
 
-bool __read_mostly park_offline_cpus;
-
 unsigned int __read_mostly nr_sockets;
 cpumask_t **__read_mostly socket_cpumask;
 static cpumask_t *secondary_socket_cpumask;
@@ -1149,7 +1147,7 @@ static int cf_check cpu_smpboot_callback
         break;
     case CPU_UP_CANCELED:
     case CPU_DEAD:
-        cpu_smpboot_free(cpu, !park_offline_cpus);
+        cpu_smpboot_free(cpu, false);
         break;
     case CPU_REMOVE:
         cpu_smpboot_free(cpu, true);
--- a/xen/include/xen/percpu.h
+++ b/xen/include/xen/percpu.h
@@ -34,7 +34,7 @@
 #include <xen/types.h>
 #include <asm/current.h>
 
-#ifndef PARK_OFFLINE_CPUS_VAR
+#if !defined(PARK_OFFLINE_CPUS_VAR) && !defined(park_offline_cpus)
 /*
  * Do we, for platform reasons, need to actually keep CPUs online when we
  * would otherwise prefer them to be off?


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 13:05:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 13:05:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399929.1635905 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzDJE-00083X-0K; Wed, 26 Aug 2026 13:04:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399929.1635905; Wed, 26 Aug 2026 13:04:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzDJD-00083Q-TD; Wed, 26 Aug 2026 13:04:51 +0000
Received: by outflank-mailman (input) for mailman id 1399929;
 Wed, 26 Aug 2026 13:04:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <mlureau@redhat.com>) id 1wzDJD-000834-0h
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 13:04:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzDJ9-00HLFy-G7
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 15:04:47 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <mlureau@redhat.com>)
 id 6a8ee46c-bab6-0a2a0a5309dd-0a2a4501d188-10
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 15:04:47 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <mlureau@redhat.com>)
 id 6a8ee46e-5984-0a2a45010019-aa0a857cb76f-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 15:04:47 +0200
Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com
 [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-384-qf1VUEI1NT-6Wqszt1hsew-1; Wed, 26 Aug 2026 09:04:44 -0400
Received: by mail-pj1-f72.google.com with SMTP id
 98e67ed59e1d1-38f5ac7354dso1432819a91.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:04:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787749486;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=oYVc9rcGEnzzR41SIfmJfIkt0WWDTdKBFsBRE9m9Ol0=;
	b=i+0qPnV+2ySestF3H3Lwti26st1iDHKX7qDMeQeZ5Z/x2HXCjdvxOP4X0il9Blhe89AIFF
	NUhlyC+rcANqnhXYF8zL9VJevFaaTDva9EdfqaTW66WvAuc9PC2NHqbn9HlD2uhq3u3HUp
	xmMlxDWrOqLAGBEwX6DUi8IduVJTkZ0=
X-MC-Unique: qf1VUEI1NT-6Wqszt1hsew-1
X-Mimecast-MFC-AGG-ID: qf1VUEI1NT-6Wqszt1hsew_1787749484
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787749483; x=1788354283;
        h=content-transfer-encoding:content-type:cc:to:subject:message-id
         :date:from:in-reply-to:references:mime-version:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=oYVc9rcGEnzzR41SIfmJfIkt0WWDTdKBFsBRE9m9Ol0=;
        b=TPiawxz8Nl3aRA2yXaTuJztNdUGAkZGY8i+ztg5PakidLbn1iQ2XHaxkKRU2Ntczut
         +qOyqaxJKSTZxnBiDSlXTvq3kwLi+A+gVjnyyYxUiHtY4JRW42OQbnlnJnIuf8Fzb0Hh
         T87zQrH3bzmnVCm3rG3htYY+8bIRvMEd9KpOVk+gILCX5Sv0zMqcubLxQm4WW8nsYRnu
         /7+E3pYa9Mh+DGZPcppNMZkOnPDkqWhNwYiTBDw/s26hzw4AqOFx9gWe6CcrSJer2rBQ
         Qo/B5eFOvLzLTbW1Z6HfdBOvFOKwiBCJ3TWhYWC96BbqbCT6Avg3eEZay2uqCrDYS/pA
         byPA==
X-Forwarded-Encrypted: i=1; AHgh+RogvD9+1N7exFSF9sK4/Nz3zAxBgjVcP6wegrvItvRpKM/FZQqF/BaqVEimBUfTOyv8QPxTZ1t8nU4=@lists.xenproject.org
X-Gm-Message-State: AFuF++kJ09Cy+pRVuoHmWOErJ1Ehni4qrSwgXRb9ACATeai2k9lwZ3c3
	tEI6NSgI/L5Ro7Rfrm4HlFA9RPLA7k5mvg6owjelVUtSf0rGoCIf9egBtwW+5lHqhe4INM4tH1X
	BVPTRt1CjUs0qB+vRZ9fEYHr+95uBPAqaxUgZizL931dqiT9lOLFv6UDr9ylAXDapaAKXxVxu3a
	KTVmPde/vb1KMK4m3zfzx5yatdN3dNjeX6yTt+2hRmoGI=
X-Gm-Gg: AR+sD11NTTCZX1XYKIUW+sqySDgkVBQfFTZmh3AUjFqgEEMBS2OpD3pAinrzl+Q0gc9
	i+TjJOnXukpj7zYI7eU8DyL+Ut/PTE8bf/FPGoHwBUKErPtJ0iUBsMeQAfJCayDAhtbIQ95kMJa
	X9u7ShXSDucnKM6icxdIMBoplS08lvZ57kYYNOQJ3k0fIlY9jhfS0z3l/nVAVEWyjMKXyeTnrTP
	qk19B75pUkzzqctI7HUw1oZ5RFQX+uItJmtK55HvKEB/B9muCV1Lm7YC93Us12ydqDkbyzb2uMT
	hA==
X-Received: by 2002:a17:90b:5107:b0:37f:fb1d:63fa with SMTP id 98e67ed59e1d1-3966d9e5ecfmr14607057a91.15.1787749483028;
        Wed, 26 Aug 2026 06:04:43 -0700 (PDT)
X-Received: by 2002:a17:90b:5107:b0:37f:fb1d:63fa with SMTP id
 98e67ed59e1d1-3966d9e5ecfmr14606542a91.15.1787749481523; Wed, 26 Aug 2026
 06:04:41 -0700 (PDT)
MIME-Version: 1.0
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com> <ao6pyiBkHZJz_9JR@redhat.com>
 <CAMxuvaz+85Pw=sZG2jXL5jJ_2=kkR5_P69-AZ6bzhVbGTA+5Xg@mail.gmail.com> <ao65_XCKmkpm9s2F@redhat.com>
In-Reply-To: <ao65_XCKmkpm9s2F@redhat.com>
From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= <marcandre.lureau@redhat.com>
Date: Wed, 26 Aug 2026 17:04:29 +0400
X-Gm-Features: AcwNN1UokCmDa7kHDxB9ZTq3xrLUmyLSJ7h0c4jfatvRCC3sSrStOXkF7y4zowA
Message-ID: <CAMxuvayGzQtu1COC5G1D+CKZuXmhCeDV5fZMvYtiK95eMh+i3A@mail.gmail.com>
Subject: Re: [PATCH v4 36/49] monitor: tighten monitor_printf*()
To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, dave@treblig.org, 
	=?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= <philmd@mailo.com>, 
	Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, 
	"Gonglei (Arei)" <arei.gonglei@huawei.com>, zhenwei pi <zhenwei.pi@linux.dev>, 
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>, 
	Paolo Bonzini <pbonzini@redhat.com>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>, 
	Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, Ani Sinha <anisinha@redhat.com>, 
	"Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
	Brian Cain <brian.cain@oss.qualcomm.com>, David Woodhouse <dwmw2@infradead.org>, 
	Paul Durrant <paul@xen.org>, Richard Henderson <richard.henderson@linaro.org>, 
	Marcelo Tosatti <mtosatti@redhat.com>, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, 
	Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>, 
	Halil Pasic <pasic@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, 
	Jason Herne <jjherne@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, 
	Matthew Rosato <mjrosato@linux.ibm.com>, Ilya Leoshkevich <iii@linux.ibm.com>, 
	David Hildenbrand <david@kernel.org>, Cornelia Huck <cohuck@redhat.com>, 
	Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD <anthony@xenproject.org>, 
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Hyman Huang <infra.ai.cloud@bitdeer.com>, 
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>, 
	Samuel Thibault <samuel.thibault@ens-lyon.org>, Stefan Berger <stefanb@linux.vnet.ibm.com>, 
	Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>, 
	Chinmay Rath <rathc@linux.ibm.com>, Glenn Miles <milesg@linux.ibm.com>, 
	Harsh Prateek Bora <harshpb@linux.ibm.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
	Alistair Francis <alistair.francis@wdc.com>, Weiwei Li <liwei1518@gmail.com>, 
	Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
	Chao Liu <chao.liu@processmission.com>, Yoshinori Sato <yoshinori.sato@nifty.com>, 
	Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
	Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, kvm@vger.kernel.org, 
	qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, 
	qemu-riscv@nongnu.org
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: 4ioSzqpDfxOQwyXJqgE-qPf-XPHsu7_fmbSUrqFClkQ_1787749484
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-purgate-ID: tlsNG-d62444/1787749487-1FC69757-0FA25AB4/0/0
X-purgate-type: clean
X-purgate-size: 7219

Hi

On Wed, Aug 26, 2026 at 2:04=E2=80=AFPM Daniel P. Berrang=C3=A9 <berrange@r=
edhat.com> wrote:
>
> On Wed, Aug 26, 2026 at 01:41:55PM +0400, Marc-Andr=C3=A9 Lureau wrote:
> > Hi
> >
> > On Wed, Aug 26, 2026 at 12:54=E2=80=AFPM Daniel P. Berrang=C3=A9 <berra=
nge@redhat.com> wrote:
> > >
> > > On Tue, Aug 25, 2026 at 11:09:43PM +0400, Marc-Andr=C3=A9 Lureau wrot=
e:
> > > > Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> > > > monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changi=
ng
> > > > the first parameter from Monitor * to MonitorHMP * to enforce type
> > > > safety. The implementation is also simplified: monitor_hmp_vprintf =
now
> > > > directly calls g_strdup_vprintf + monitor_puts, removing the virtua=
l
> > > > dispatch via moncls->vprintf.
> > > >
> > > > The dev_print() callbacks are temporarily using the MONITOR_HMP(mon=
)
> > > > cast, they are fixed in the following commits.
> > > >
> > > > Signed-off-by: Marc-Andr=C3=A9 Lureau <marcandre.lureau@redhat.com>
> > > > ---
> > > >  audio/audio-hmp-cmds.c                  |   6 +-
> > > >  backends/cryptodev-hmp-cmds.c           |   9 +-
> > > >  block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
> > > >  chardev/char-hmp-cmds.c                 |  12 +-
> > > >  disas/disas-mon.c                       |  10 +-
> > > >  docs/devel/style.rst                    |   2 +-
> > > >  docs/devel/writing-monitor-commands.rst |   8 +-
> > > >  dump/dump-hmp-cmds.c                    |   5 +-
> > > >  hw/char/virtio-serial-bus.c             |  10 +-
> > > >  hw/core/machine-hmp-cmds.c              | 213 +++++++++++---------=
--
> > > >  hw/core/sysbus.c                        |   5 +-
> > > >  hw/hexagon/hexagon_tlb.c                |  44 ++---
> > > >  hw/i386/kvm/xen-stubs.c                 |   6 +-
> > > >  hw/i386/kvm/xen_evtchn.c                |  21 +--
> > > >  hw/i386/sgx-hmp-stub.c                  |   3 +-
> > > >  hw/i386/sgx.c                           |  29 ++-
> > > >  hw/misc/auxbus.c                        |   9 +-
> > > >  hw/misc/mos6522-stub.c                  |   3 +-
> > > >  hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
> > > >  hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
> > > >  hw/pci/pci-stub.c                       |   3 +-
> > > >  hw/s390x/s390-skeys.c                   |   9 +-
> > > >  hw/s390x/s390-stattrib.c                |  20 +--
> > > >  hw/uefi/ovmf-log.c                      |   5 +-
> > > >  hw/usb/bus.c                            |  11 +-
> > > >  hw/usb/host-libusb.c                    |  21 ++-
> > > >  hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++----=
-----------
> > > >  hw/xen/xen-bus.c                        |   5 +-
> > > >  include/disas/disas.h                   |   4 +-
> > > >  include/monitor/hmp.h                   |  12 +-
> > > >  migration/dirtyrate.c                   |  46 +++--
> > > >  migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----=
------------
> > > >  monitor/hmp-cmds.c                      | 141 +++++++--------
> > > >  monitor/hmp.c                           | 143 +++++++--------
> > > >  monitor/monitor-internal.h              |   6 -
> > > >  monitor/monitor.c                       |  33 ++--
> > > >  net/net-hmp-cmds.c                      |  31 ++--
> > > >  net/slirp.c                             |  31 ++--
> > > >  qom/qom-hmp-cmds.c                      |  27 ++-
> > > >  replay/replay-debugging.c               |   5 +-
> > > >  stats/stats-hmp-cmds.c                  |  57 +++---
> > > >  stubs/hmp-cmd-info_sev.c                |   3 +-
> > > >  stubs/monitor-core.c                    |   2 +-
> > > >  system/dirtylimit-hmp-cmds.c            |  10 +-
> > > >  system/qdev-monitor.c                   |  19 +-
> > > >  system/runstate-hmp-cmds.c              |  16 +-
> > > >  system/tpm-hmp-cmds.c                   |  29 ++-
> > > >  target/i386/cpu-apic.c                  |   3 +-
> > > >  target/i386/monitor.c                   | 152 ++++++++--------
> > > >  target/i386/sev.c                       |  35 ++--
> > > >  target/m68k/monitor.c                   |   3 +-
> > > >  target/ppc/monitor.c                    |   3 +-
> > > >  target/riscv/monitor.c                  |  55 +++---
> > > >  target/sh4/monitor.c                    |  29 ++-
> > > >  target/sparc/monitor.c                  |   3 +-
> > > >  target/xtensa/monitor.c                 |   3 +-
> > > >  tests/unit/test-util-sockets.c          |   2 +-
> > > >  tools/qemu-vnc/clipboard.c              |   4 +-
> > > >  tools/qemu-vnc/stubs.c                  |   2 +-
> > > >  trace/trace-hmp-cmds.c                  |  12 +-
> > > >  ui/ui-hmp-cmds.c                        | 115 ++++++------
> > > >  util/error-report.c                     |   2 +-
> > > >  util/qemu-print.c                       |  11 +-
> > > >  63 files changed, 1219 insertions(+), 1327 deletions(-)
> > >
> > >
> > >
> > >
> > > > diff --git a/util/qemu-print.c b/util/qemu-print.c
> > > > index 5d4143d425a1..5938f2b6c338 100644
> > > > --- a/util/qemu-print.c
> > > > +++ b/util/qemu-print.c
> > > > @@ -13,6 +13,7 @@
> > > >  #include "qemu/osdep.h"
> > > >  #include "monitor/monitor.h"
> > > >  #include "monitor/hmp.h"
> > > > +#include "qom/object.h"
> > > >  #include "qemu/qemu-print.h"
> > > >
> > > >  /*
> > > > @@ -23,8 +24,13 @@
> > > >  int qemu_vprintf(const char *fmt, va_list ap)
> > > >  {
> > > >      Monitor *cur_mon =3D monitor_cur();
> > > > +
> > > > +    /* for all monitors: QMP & HMP */
> > > >      if (cur_mon) {
> > > > -        return monitor_vprintf(cur_mon, fmt, ap);
> > > > +        /* don't use monitor_cur_hmp(), to avoid a second lookup *=
/
> > > > +        MonitorHMP *hmp =3D (MonitorHMP *)
> > > > +            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP)=
;
> > > > +        return monitor_hmp_vprintf(hmp, fmt, ap);
> > >
> > > This isn't the same semantics AFAICT.
> > >
> > > Original code, if monitor_cur() =3D=3D QMP, we call monitor_vprintf()
> > > which will return -1.
> > >
> > > New code, if monitor_cur() =3D=3D QMP, we will get a NULL back from
> > > object_dynamic_cast which we then pass into monitor_hmp_vprintf
> > > which will then crash on monitor_puts() IIUC.
> >
> > monitor_hmp_vprintf() has an early return, if given NULL monitor, it re=
turns -1.
>
> Hmm, I feel like we should be dealing with NULL in this method, as it
> is surprising to be calling a monitor_hmp_XXX method in scenario where
> QMP is a (theoretical) possibility.

"hmp" would be NULL in that case, but I agree it's a bit confusing.

I would go as far and make hmp required for the call, but I can't
review all the code paths to monitor_hmp_(v)printf()
I'll add an early return in qemu-print.c

>
>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 13:34:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 13:34:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399937.1635913 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzDlx-0004Cz-40; Wed, 26 Aug 2026 13:34:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399937.1635913; Wed, 26 Aug 2026 13:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzDlx-0004Cs-1E; Wed, 26 Aug 2026 13:34:33 +0000
Received: by outflank-mailman (input) for mailman id 1399937;
 Wed, 26 Aug 2026 13:34:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzDlv-0004Cm-TI
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 13:34:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzDlu-008Z0w-Gy
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 15:34:30 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8eeb64-2eae-0a2a0a5409dd-0a2a4507bf40-6
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 15:34:30 +0200
Received: from [209.85.167.42] (helo=mail-lf1-f42.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8eeb65-b4ea-0a2a45070019-d155a72ae992-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 15:34:30 +0200
Received: by mail-lf1-f42.google.com with SMTP id
 2adb3069b0e04-5b4740ec30cso810254e87.3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 06:34:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a5d62f7sm508146766b.2.2026.08.26.06.33.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 06:33:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787751269; x=1788356069; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=MVsUp2iFe/J1GYqAnbcpzPHu4UL6ElgwxmStYaLSmkc=;
        b=PThtRjcnQL/k+meaR6O59cbXOSWmQdSwhbRWZVVDyvglHl7kYCkGORDoXSEJ/QeaSB
         Btkztqy9R093DpQMSRBQ/zKhPghiPlvLf+OQBL+YgnDAtsaSwZR1wyA34/XLm47D9IqV
         Q/jkAxn/ZnE4FdBnE2yCJ7P9GnnW9zqRMKI8t5i9JDRmC4gq/ehcSzcc2cWne4J5TWMN
         UoxMMJ6KtmxUDM5Pp1nU2w5i9KxKGE2tWdnXoBTdYB4eEKsDoN5Z8znzv3w1rcQ90Cx6
         ilzPwAks7gWXYCEd7p1eFrnBPczw32PKW5sGC1efXU0zNIRv2VUWjZlzENT4Nos8S2Ff
         h6GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787751269; x=1788356069;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=MVsUp2iFe/J1GYqAnbcpzPHu4UL6ElgwxmStYaLSmkc=;
        b=drsVD7ZIoFVFsy2gk1ceBv8gs6ImnqsnLzi0Ku6tMPz1sbAJB4WjSz3Dbdam+bF38d
         SposA38n9Rau5NtoMgwCQA7odx/C/5veYRYSG2wMhfJ44YaWQr2GF4rBrbNA4SSinuIi
         zIPYFKji868gw6GWu14Yb/5akCzrCBuvOvkHBnCCpySxP9lueBk+okOxAC6eO18dWmb0
         Ih35giVQKONPFpKZqmXwXTWwETc4/3VypkHUtng0XaFHavr/6c037uUID7kLlrikWCvs
         Lm5SAZnXZwoM4KfucigVRvPGYr4snWJK+h9TKBrn9kqSurPNgDunxi3vsTVFJCOGqKUR
         XPpA==
X-Forwarded-Encrypted: i=1; AHgh+RqaqnLN1u9jaBkhUxe+yRn8XR0dCnsQVJPT67Dcl3PXah66i4lwoCKDFHlU7dBwehK6n/Mfxc8C6BQ=@lists.xenproject.org
X-Gm-Message-State: AFuF++nxn+v8S8yXjEJOwJ4H5TPUAsBux0MrIvwQ8lKGBfhWRl/fko5C
	i68usPQYzQF8ByGomS7kNgp6h7UDJk4WdYXgbRkyKEp/VvuZ7bmp5xNflOJXykhymZ6p8PHvU79
	5v+IouQ==
X-Gm-Gg: AR+sD13wmBlt+mL/3OZgWLcczP7/3YTuNa1Bv6p+UwNnS2GF7d6zukq215mk8+PpB/g
	KhAKSppi00vElqyEtlbNtFKhkACJhtUdWDhxMFRGBeC8X07HnMhAbcqtSo3Nv1fG2UloE+xc/bB
	wu+jhwKaOhL2My63J5FMcM3OPKzL8TDf+VKft+qmiab7hHA38kUF6YHNazDgTgclrBwxJxWpeXi
	Y13BkNfaT75pZM/zqRPXma9Ywiz8LRZzsgSde13nM/k9thGq1DB8aEBSRVK0SpkwESrAx+4G9h+
	6Iz9psh7bKSoWd5fOX6nMU2iWSOB6Nl1FhBN0Y2uXV0g6piMw1iqv2T8PBPHsVGmpcT+FBfvEHE
	YCUXMKqgu9ERw5m/RoJfGDq98Rb27FPCd67FAjJNHuXTUUXxqWmmO1wU6dTir/77nDr6hVLI94N
	zc0rhjTAbXn0D89AAmic8OFlboRGGyGN++hRe1ByEb9ILHVmm0DihaDgvTn+1SYaNHAqA7HGTJr
	rDdQJkbpBHltuxp9bZ3nkZCsiukEOyX2s1PitfbBmxmTex4Ku2J
X-Received: by 2002:a17:907:9349:b0:c19:fb6e:5fec with SMTP id a640c23a62f3a-c250c392a2bmr784069566b.18.1787751234685;
        Wed, 26 Aug 2026 06:33:54 -0700 (PDT)
Message-ID: <d9512f79-a05c-447b-98c5-7dfb14ef5347@suse.com>
Date: Wed, 26 Aug 2026 15:33:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] x86/nSVM: Check injected event consistency
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com,
 teddy.astie@vates.tech, xen-devel@lists.xenproject.org
References: <88078b2a2eb1f741a39562fc493330e6ee26c61c.1787497752.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <88078b2a2eb1f741a39562fc493330e6ee26c61c.1787497752.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787751270-35CC7AE4-F941E97C/0/0
X-purgate-type: clean
X-purgate-size: 6241

On 23.08.2026 18:11, Abdelkareem Abdelsaamad wrote:
> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has
> debugging complications, security and performance implications. The APM
> volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that
> result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are
> • Reserved values of TYPE have been specified.
> • TYPE = 3 (exception) has been specified with a vector that does not
>   correspond to an exception (this includes vector 2, which is an NMI, not
>   an exception).
> 
> Extend the VMCB validation to check for such inconsistency.
> 
> The collection of the invalid exception vectors are ported from the upstream
> KVM commit
> ("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust
> the checks from the commit to align with the APM Volume #2 and Volume #3
> (40332—Rev. 4.10—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which
> should not be valid on the x86 64-bit (long mode) platforms. The adjustment is
> posted to the KVM mailing commit patch thread
> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/
> 
> Injecting the vector X86_EXC_HV is also found to trigger VMEXIT_INVALID with
> the Xen hypervisor. Drop the X86_EXC_HV vector from the permitted vectors.

Is this matched by anything in the PM? There is "#HV is only allowed to be
injected into VMSAs that execute with Restricted Injection." Which suggests
#HV can be injected, but only under a certain condition. Following what
Teddy said towards v3, this may want expressing by a separate case block
also returning false, but having a comment.

> --- a/xen/arch/x86/hvm/svm/vmcb.c
> +++ b/xen/arch/x86/hvm/svm/vmcb.c
> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
>      svm_dump_sel("  TR", &vmcb->tr);
>  }
>  
> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb,
> +    uint8_t vmcb_injected_vector)
> +{
> +    switch ( vmcb_injected_vector )
> +    {
> +    case X86_EXC_DE:
> +    case X86_EXC_DB:
> +    case X86_EXC_BP:
> +    case X86_EXC_UD:
> +    case X86_EXC_NM:
> +    case X86_EXC_DF:
> +    case X86_EXC_TS:
> +    case X86_EXC_NP:
> +    case X86_EXC_SS:
> +    case X86_EXC_GP:
> +    case X86_EXC_PF:
> +    case X86_EXC_MF:
> +    case X86_EXC_AC:
> +    case X86_EXC_MC:

Is #MC valid to inject without CR4.MCE set?

> +    case X86_EXC_XM:

As before: Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set?

> +    case X86_EXC_SX:

Again as before: Is #SX really permitted without any constraints? You did
reply to both comments on v3, but that outcome isn't reflected here. The
more that what you said there could equally apply ...

> +        return true;
> +
> +    case X86_EXC_OF:
> +    case X86_EXC_BR:
> +        return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l;
> +
> +    case X86_EXC_VC:
> +        return vmcb_get_sev_es(vmcb);
> +
> +    case X86_EXC_CP:
> +        return vmcb_get_cr4(vmcb) & X86_CR4_CET;

... e.g. here. That is, if a CR4 (or other) check is needed here, but not
for #XM (or #SX), that's surely worth (briefly) commenting upon. The more
that, afaics, none of this is spelled out in the PM.

> @@ -330,6 +368,12 @@ bool svm_vmcb_isvalid(
>      unsigned long cr4 = vmcb_get_cr4(vmcb);
>      unsigned long valid;
>      uint64_t efer = vmcb_get_efer(vmcb);
> +    uint8_t vmcb_injected_type = vmcb->event_inj.type;
> +    uint8_t vmcb_injected_vector = vmcb->event_inj.vector;
> +    uint8_t vmcb_valid_event_inj_types_mask = (1 << X86_ET_EXT_INTR) |
> +                                              (1 << X86_ET_NMI) |
> +                                              (1 << X86_ET_HW_EXC) |
> +                                              (1 << X86_ET_SW_INT);

The absence of X86_ET{_PRIV,}_SW_EXC likely wants a brief comment, as that's
a peculiarity of SVM. Alternatively how about introducing X86_ET_SVM_ALL (or
some such) as a #define somewhere?

> @@ -392,6 +436,20 @@ bool svm_vmcb_isvalid(
>          PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
>                 vmcb->event_inj.raw);
>  
> +    if ( !vmcb->event_inj.v )
> +        PRINTF("eventinj: valid bit is not set (%#"PRIx64")\n",
> +               vmcb->event_inj.raw);

I understand the parentheses in the log message here. Yet ...

> +    if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) )

If vmcb_injected_type really could take all possible uint8_t values (see
below), this shift would be at risk of becoming UB. And uint8_t is a
stronger hint that all possible values may appear than unsigned int is.

> +        PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n",
> +               vmcb_injected_type);

... what purpose do they serve here (and below)?

As to the use of PRIx8: Imo that's unnecessary to use. We assume
sizeof(int) >= 4, and every type smaller than that will be promoted to
int. Just %#x will hence do here (and below), improving readability.
Furthermore, the use of fixed-width types here is in conflict with
./CODING_STYLE anyway. I'm willing to accept it for variables holding
vector numbers (albeit longer term they will apparently need to widen
anyway), but the other two should be unsigned int.

> +    if ( (vmcb_injected_type == X86_ET_HW_EXC) &&
> +         !is_valid_injected_exception_vector(vmcb, vmcb_injected_vector) )
> +        PRINTF("eventinj: Invalid exception type: (%#"PRIx8") vector: "
> +               "(%#"PRIx8") for the platform\n",

Does "for the platform" really add any value? With it dropped, the
whole format string could also go on a single line (which we generally
prefer).

One more check would likely be worthwhile doing: We have X86_EXC_HAVE_EC,
and vmcb->event_inj.ev could also do with checking.

Finally a more general comment: svm_vmcb_isvalid() is used solely out of
nestedsvm.c. I hence think it would better move there, and such moving
would better come ahead of adding more code (which would then also need
moving).

Jan


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 14:40:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 14:40:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399974.1635930 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzEnu-0005rs-Qd; Wed, 26 Aug 2026 14:40:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399974.1635930; Wed, 26 Aug 2026 14:40:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzEnu-0005rl-Ny; Wed, 26 Aug 2026 14:40:38 +0000
Received: by outflank-mailman (input) for mailman id 1399974;
 Wed, 26 Aug 2026 14:40:37 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzEnt-0005rf-FA
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:40:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzEns-004D82-Ra
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 16:40:36 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8efadf-bab6-0a2a0a5309dd-0a2a4503b318-16
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 16:40:36 +0200
Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8efae4-fae8-0a2a45030019-d155d030eca2-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 16:40:36 +0200
Received: by mail-ed1-f48.google.com with SMTP id
 4fb4d7f45d1cf-69fab5a852cso1787223a12.0
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 07:40:36 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a5de8ea655sm4727760a12.12.2026.08.26.07.40.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 07:40:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787755236; x=1788360036; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=x/i5WmFJBUVq4Pl1gDWpNV2HVBRbeX+AeaNUt+aYYbY=;
        b=MuLKUOMMXoCDPy0oUvc8SX1iByiVixla1+5mbtSdxEDPk7/f65OwiXdqi1wqYAib+d
         8Mrh5I6clxqb9au8h/ny0VQ8ga7VA1AUWhyr32XuViICZh69P1Kka6zQiVjCBwqN3PA3
         Y3bkXJzfwyNQcClxp2SKFjy3uaR29qsa8k3LphJuZcWT7S80APR0FbumgP8sHzllnP+1
         er3/sdDs8JWhrexGx7axf7MexvWCDMKheO17UiCLkiIPlJutTISK9UgpMfwUsgKFxFAo
         WO/lJb71m1NzBnr9pgqMjRa7lySgs/DWlRsYOzC46bMn3Aq42fcNdVKEwT3ZWROZOMSQ
         rMTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787755236; x=1788360036;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=x/i5WmFJBUVq4Pl1gDWpNV2HVBRbeX+AeaNUt+aYYbY=;
        b=IV698mFn2iS8/BpIlQeUL8cZ2sAD1MBqOWtB4b2Raha3+WmZiqJEKt+VPuykJbWfg6
         O0y4RX1T3ogC1bPlvYnx9xCEXgL1DKVQdZrjiNF9oT70hTpcAWH9hDt4CIAaOC5IfFY0
         7xxll+y2tgnAM0UI/YpVKV4OkX8BE5aZppWjsB88I3WHRCvu8n47sWwH6qq2R2Src2f3
         rZeb0/SfPn2xSDe3Zo8CqXc0KeXdvfAwHHCLRa5/kgXME7D+5a0Hz3B6/RsXlFQP4AtR
         iSAAKlCTNYYUTK7mIImxyyBnT+PU2cLY9jS3DZO6ocLLrfVmv7Rf1Leo/Z7i6zOB4BVG
         5aVA==
X-Gm-Message-State: AFuF++nksEsltQzpBSwqCz5XGx0sl27ybD96Ulo7/fvvoxHsZoMzV7FU
	S5oHQBapIT1d2e5UKY9ppHS0/FqcSFlHnYt2mvIDstduaMqXBw5USA76/pVz2jaE/VWK4X7qaHC
	ktJFbnQ==
X-Gm-Gg: AR+sD137ksC4pedO25dyAPcVShqau8QKeqPZXW+NJCjfkca6UDqLpR3KosRa4pFlhnV
	uJO15hvPYoPwWq8vSMMdA5J/ASh1RFAi2v6vxnzrLntBcyk9j+hxx0FkLSEBdzwlipYfK6+qol1
	SYl2baHEl9FCNAQ/k6TXMZgvDaJqLxBBjA+BFDMOoP6srURYpVkVbVmkZN5Y+W8iNBKFiwv9PMi
	1Pl/DxcOLr7AnGCLq3/55ZbBD+yY14qLrCGvVnOKwmrLpxJ3igPnDVfNP/3NLUF+6Il3SL2mmMk
	wqKYxcs/96SouQSP/F2hvqfa4aJZl7qV8VWvAOF4btW1+bZsx+GGjMKhw+kJF+YH5rRn+bto6Mt
	YMnvAzvs4RrB+5LHlQdZ+Miz69Iy4MHRHYBX9Uakce6Tn34SQpPoLARi0kI/DPYtuJGIRzkJngq
	peL8NA4a6ApBoAZfUduNRXMR1Tn4AyPuaB6oRo5OrGBrMQoniq+JM6lpiADBES5DBrkhoV2rJTC
	qCUTqg9U4/DFefMjzXgirc2uXVqzegqXbf/PdL/N9586YQ1/KLJ
X-Received: by 2002:a05:6402:2312:b0:6a5:f202:c1c7 with SMTP id 4fb4d7f45d1cf-6a5f202c2d3mr2378244a12.8.1787755236311;
        Wed, 26 Aug 2026 07:40:36 -0700 (PDT)
Message-ID: <ff35bc09-aa7e-4bc7-b3e8-43fe765c2cda@suse.com>
Date: Wed, 26 Aug 2026 16:40:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH] x86/IO-APIC: replace redundant irq_trigger() call
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787755236-6CADC4E9-FA81AC6D/0/0
X-purgate-type: clean
X-purgate-size: 772

Just having called the function and stored the result, there's no point in
calling it again right away with the same argument; the stored result can
be used instead. And the stored result also doesn't need overwriting again
with the same value.

No functional change intended.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1089,10 +1089,8 @@ static void __init setup_IO_APIC_irqs(vo
             entry.trigger = irq_trigger(idx);
             entry.polarity = irq_polarity(idx);
 
-            if (irq_trigger(idx)) {
-                entry.trigger = 1;
+            if (entry.trigger)
                 entry.mask = 1;
-            }
 
             irq = pin_2_irq(idx, apic, pin);
 


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 14:42:47 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 14:42:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1399981.1635939 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzEpx-0006Oo-5V; Wed, 26 Aug 2026 14:42:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1399981.1635939; Wed, 26 Aug 2026 14:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzEpx-0006Oh-2k; Wed, 26 Aug 2026 14:42:45 +0000
Received: by outflank-mailman (input) for mailman id 1399981;
 Wed, 26 Aug 2026 14:42:43 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wzEpv-0006Ob-8x
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 14:42:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzEpt-008Syi-I4
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 16:42:41 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8efb38-e002-0a2a0a5209dd-0a2a450989d0-48
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 16:42:41 +0200
Received: from [52.101.53.43]
 (helo=BL0PR03CU003.outbound.protection.outlook.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a8efb60-be1a-0a2a45090019-3465352b55bd-4
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 16:42:41 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PH7PR03MB6943.namprd03.prod.outlook.com (2603:10b6:510:15b::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug
 2026 14:42:37 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.006; Wed, 26 Aug 2026
 14:42:36 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M79N6PRZKRxLI15FYIICDQFy9N4C6twcYimhGSwsKxaUCuFHfq/x4hZqWRQF+oWMwaaKzUoSXzTd0SaY/WDhTJq7nCaC9B5tVIWw2sVcUwNLY+Siwb1VczUHR3/vP+T/fVLWPmO6we8/2V1rHrDG93c41O7k7/TZ4Q8lnW1Wny+xejiPf0ulsNDEp6nW3HW+U7oga7K2eAcOoISpjScqVVj/mdiPHPeIV9tuhECz9aw/i40TQk5UKZLL64+Ug1nGvXuDOpbo6bb/iRe2+wlwN0FkUFMl5BnFdgbb7Z8jSeCbhGf3+6BO4Cdm89+csam3th+8a5ZHwKmhEB5B1amAPQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nIw8x0AOzlMeZVy20wssjgNYi5QuOTCa7cTowLZ3L+k=;
 b=C+/oYj42nS1SvbSla4U53nv/hV0964bZnxCjQdJX+p/XJKX9WOGRM+5KPo23qwlwXQiEbztdfZtdT7LSyZplbPcOgEQ0mpTBqUkKrsc+ORCINabVV4C0IxAq9eGDbrH1vOg/bBjzcUbE96v5ibWOD6LBW/av0ukSv37jcSupVMy1GEdlAyytweoyighn22T83LkU75WgNECm6n0vdMntSmcabeMWLfFl/VeRs3KT0A7SduRJdA+jVl7N6MudUiVKIk8BFgxmTS6F/uEil1IGedGungGFLVXIzFiizExCD10f0vTAarRF8MhYkhuWgJWRenV/Ql0GY42qIar563AfXg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nIw8x0AOzlMeZVy20wssjgNYi5QuOTCa7cTowLZ3L+k=;
 b=YgME41RnEMsDW9RAoCVYQ+Xwe25lJMig/fChrJqli0Bi8BRJIHvrJKjo4YoswEFjLpb1i7OwZ+a+1+tsM77XJOLggS78DJIMa9VahF21e3+/w5SkojnWbg9iJRoYml2G/eBvfAobOgkClSpCJnzpPD+e7tReQLck8yoNXjX7Ez4=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <fbbdd0e6-4a4e-43a9-b313-6d06f4a465f9@citrix.com>
Date: Wed, 26 Aug 2026 15:42:33 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Subject: Re: [PATCH] x86/IO-APIC: replace redundant irq_trigger() call
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <ff35bc09-aa7e-4bc7-b3e8-43fe765c2cda@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <ff35bc09-aa7e-4bc7-b3e8-43fe765c2cda@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO2P123CA0082.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:138::15) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH7PR03MB6943:EE_
X-MS-Office365-Filtering-Correlation-Id: 9f2a13ea-0cb0-4e50-ac04-08df0380458a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|22082099003|18002099003|11063799006|56012099006|10067099003;
X-Microsoft-Antispam-Message-Info:
	zVOUk3t356WEudQL0BTUy/PUSnKSL3dj0eIMEKCSTPYcoddc0QfE3SHXYoU6ob0uI22q+QpdzH8scl/9J+/tnhzK7bqRQPokSJBGgWclxf0c+TDwx3nSZQ5p7W+YXGPbaTrx8uudZ9T4MWlyiI+g/ylJjFXj+va/6EDnw40ww0zJHktZ/i4BgguLqpJpRDRbIijN78W50hbf15PeOlKOyGpAAucPYaic9w9yl794hZX96Ye1aJuo7Qo9SxFWGAnDFZIpn98ThjKCsNDHrdHsAkgz6eRgm8SGFF0zbca8vf06ubBhcxf4X5b2ThZUIptu+qmjKUyfKHod9e7LaSjk2G7MHYtNmt9dcilfUwWEEPyLOFcZ4ViU6kZ9eXL0J00lWnL/9CilXy0X4/jzK4ASnAnvQ47Dq8csWBRocPabBhjM90ItU2w0cQGoD1gOo07xxs4tXhFEnx1w4919kJtA5RLjS+StGMSoIoIN/75n8w9Pq1IaGZVJ4k5LFdgVNeI22IsXrI5nKwr3QVICjA33UIISmdg2e5yNHcHk8F4BW6c5G6WGxUzfdfx9F0l3pOx9ZmvP4ptOkZc0B5oXB8KpsMg61ljziGiNXSpMFmQD3pKjfUyKCG/qgrZUJ/+KcSM/plMe1rHIHZoeeJ2HkCkGaD2NMoRbwDG/shkTYV8jb5M=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(22082099003)(18002099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a0loOUNaTjBrcXN0SW0rVzFxdW1Bc2RmZENERlE5U0s1R1B0RjNFTnA5a3VT?=
 =?utf-8?B?RE9Bcmo5RDYxOTQzR0IwRGM3MVlyMzRCQ2pSSkExZzV3VlVhTkZEck5sZVNC?=
 =?utf-8?B?ZTZaRHFDamlrSFozWHhFK1JESXhUdG9VanlMaGVmWmJ1TSt5SFlGc2VoNU5V?=
 =?utf-8?B?WHZTNkFNMkZrL214S3RmQWoycGt5NnRrVGxVQmVaa2Y1MEQzS0czV2tnMDVF?=
 =?utf-8?B?WlJ3djd0S0twMUwzeFo0L0xzbWVhQXpSMTV4Z0NrM2s0WFRwK0lkbUU3Nis1?=
 =?utf-8?B?ZE1qdWhiSy9uUnZ1M0Jzc3dMTE9qcHlOREZtajFLYUZZSVRROC9KU0JxR2hy?=
 =?utf-8?B?UFJNdFZYNk5OZlVNd2llVzdCNFRUQmNMR2JIdFhXL2FWazQ3MVVwdDZuSi9l?=
 =?utf-8?B?VU1pa1Yyb3BHbDVWNHZQMmxOc3NxZ3N4bnZYLzdhOHR1S3BablNlVjVmTmF3?=
 =?utf-8?B?dTVvR3hLaHBmT2V5WkpsRytKNkc0RmpVVDFjTnlGQlZnSm9JNUc1UFc3cGxo?=
 =?utf-8?B?V1FLQUhQVTdqb1g0K2JYRXZSdkN5NWFkWTRkTFlUWVpGdFdzTHFSZVJGdVNH?=
 =?utf-8?B?QVVGMUtlVVZGa2VGQzM3UTBZTEh4WUREZk1yaGdZYmpNb0l4cDVoKzdhL3VM?=
 =?utf-8?B?SXhDT1UzMnFzTjVlQWw2MFlnOWtDd1NxQVhnWC8yRzNPQXR4WlVyYkwveW1W?=
 =?utf-8?B?NDJJMzA3K3F5d241S3MzNTd3dE1Rc2I2WkpiYXNhYlJSYkE0OGdiYms5cXRl?=
 =?utf-8?B?TDZzRmI4UUpPK1c4SmQxbVV5NHd3QnFtQ2R0a0hFMHlZdzlwb1NOdEZSZVZY?=
 =?utf-8?B?M1JwVG0yUFBvK1NLR3o0TVNBWUpLZVo5dnFsMkZUdEZJQjZpcStCK21ZK1NX?=
 =?utf-8?B?Nk9weVF2eG1YbFUwMVczcWswczVkZm44QjJnWHA0b0prank1SVR5cG40ZDlQ?=
 =?utf-8?B?OVl4enAvbUN2Ujl5VXdlbExRcGRvQlp2cENxQkdDREI2WEFTYS95cGdvczhp?=
 =?utf-8?B?ZzdVOXhSMGphTzBCSHg3R2s0OURZMEhwRnlSRXRJd1Fta1RsbHpvN2JyQzMz?=
 =?utf-8?B?RG5MT3BsU0JBdk1WZndLbmhadnllMnhzakRzU1ArcHA2aGU2V0gxeEhaSkJh?=
 =?utf-8?B?TnpaRzhrZXZQMGF0RGorRGFadjhNYlJIQ1JLWEhRT0RmcTdLa2ZRQmk4c0xV?=
 =?utf-8?B?RWY3ZlBJbG9LblZNbjZlU2xvSTFzZE1KbnRhcTZKUVgvRWttTVdLb3RkRHJx?=
 =?utf-8?B?VmMrTTVTOFowYy80MlRybmc5MDN3c0dpSjNnRmNnN1haSHFtZE9UUW1OTzRE?=
 =?utf-8?B?Q0dQOWZIZDdONTRSRzI5dDFVUnl2dXdQRkVnT21NSGRwNGhWbHgxbm8vMS9y?=
 =?utf-8?B?cUR6SXkrRVJ0OEVMYnF5bVREY2VnRHNRWmxkZU4vR3krUi92Z2dOS0RBNW9v?=
 =?utf-8?B?TEVQeHZJUUpqSG1IRXFqcFpiNHhKMk5HaXYvUHg4UkFpdHUrZEpQblkrblQ4?=
 =?utf-8?B?Zld4Tlh0NkEzM0twUENIQXFEbEZ0MTByWmdJdmU3UGlTd1pFSVgxazJEREx1?=
 =?utf-8?B?TU0vTDkvb3JWVTZXSDlqQithSEI4TG1HZUFQNWhadWtsYVcrK2RQZmtkelRv?=
 =?utf-8?B?Wk9xeFliOWVMUzR4dHc1a0FkS1J0ZDIzdStLZ3lBMGtNVjcySUlReUlwOURr?=
 =?utf-8?B?bXRjUy8yZlFlOFVZcjFFRm1nVklLNzNwWVozWmxQV0FEcGlHU29OZWNBRVg4?=
 =?utf-8?B?MDZSZWNGSWtWVXBDZUJqdDVlVVZYdW1vSStXSEViLys0OUlrcjQyckJkNVFM?=
 =?utf-8?B?UzRHYVc0Vlo0Nkw1bjRoN0ZDTUlrdkN6Y2NQckxOS250TFUvbXFkV0x4clZV?=
 =?utf-8?B?eWMyUkg3WlZ5MHVIVTBIYXlONUVGR2RRVDNPTWpIdHJzSHExSTJ5b0NIMytW?=
 =?utf-8?B?cE4yTGpKZHI2VU1pV3l1UWpRNmNBTDQrdFdSZmVPd29paWQvcFVQNkIybVM1?=
 =?utf-8?B?TGlyekFManJHdmhybUdTK0R0dzNDT3Nlb3grZHcyRXJHRzJpcE1lYUcraXd3?=
 =?utf-8?B?eUNIL0t6cHRvVERFbVVaR2lqQjNVVFJ1Z3QrdS83cEJNSEZvWTdhVFBBcHdo?=
 =?utf-8?B?K0tBb0gxb09pdWxOclVuZFF3RHN5WXViaHh4SnFjZys3aVArMmNMUms0Y1JF?=
 =?utf-8?B?UmVacitPZmV5bW5DU1ErK0RZNFZxREtvNmJ3S0tUN2YvejdlTFZ1RnlZZGdG?=
 =?utf-8?B?YktoSi9xNzdBK29OR2ErOGFtdlFoN0RSZVBzRWova2RGOW5WRVVUTU05Ym5z?=
 =?utf-8?B?RnhtNGF5d1NvWTNpamxpalM0REhtb1Yzd1lNNG9lWVNzek50NWJCQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f2a13ea-0cb0-4e50-ac04-08df0380458a
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 14:42:36.8080
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Noj40m1gje7+EJYarcHrGxoQRdoRku/xMHpXwG8ga7FY8Ayat1/5CZi34v5ZxUFtpiYqT2MxI8RK3Xp9OlCsN/UoyApUf1yhMMn6ZyxYEdY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB6943
X-purgate-ID: tlsNG-bad1c0/1787755361-BCECE034-C21DED05/0/0
X-purgate-type: clean
X-purgate-size: 445

On 26/08/2026 3:40 pm, Jan Beulich wrote:
> Just having called the function and stored the result, there's no point in
> calling it again right away with the same argument; the stored result can
> be used instead. And the stored result also doesn't need overwriting again
> with the same value.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 15:48:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 15:48:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400017.1635956 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzFr8-0006R5-Pj; Wed, 26 Aug 2026 15:48:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400017.1635956; Wed, 26 Aug 2026 15:48:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzFr8-0006Qy-N5; Wed, 26 Aug 2026 15:48:02 +0000
Received: by outflank-mailman (input) for mailman id 1400017;
 Wed, 26 Aug 2026 15:48:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <olekstysh@gmail.com>) id 1wzFr7-0006Qs-5u
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 15:48:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzFr6-008cOu-J5
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 17:48:00 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <olekstysh@gmail.com>)
 id 6a8f0aaf-e002-0a2a0a5209dd-0a2a4508a264-6
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 17:48:00 +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 <olekstysh@gmail.com>)
 id 6a8f0ab0-f659-0a2a45080019-d155802ab0f7-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 17:48:00 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49b0dbfbf7bso366025e9.2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 08:48:00 -0700 (PDT)
Received: from [10.17.80.122] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499dc981bf3sm31219935e9.8.2026.08.26.08.47.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 08:47:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787759280; x=1788364080; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=XReb/tURPpSv7wHa2G008+5hJ+djpIqcqcy5gPwUZsM=;
        b=h/4cSV1zs54cHvOCjP1yuHhg7OG5y2ScODkmNbWujKyseLLp1WCfDNXkGYid9LI+jN
         giMPRuTkn6p8Sr1G3b+FWI42fFz6tKe2S3FJAEf5CRPqkZ2gMorDS0jZUVTse8DiiO+w
         akxiMNVdsAABrBKHXpRrQFLQuZ6OLC/Jti8wQlph3phkyvdqeyzHDIA2yOm3+L35mDXA
         lNnDYljV1/7wCwM00n8YknbEM+HXllCsjJLuzaaaUurzc+Gd4/IoeBKLDnFI9ILRpaJw
         gSy97K7ZGU832cPWjtQpo+pEtq+NmIWnFbZxaLgrKlpVSJkCzoiQHFkBSwmFhNODSAOm
         EjSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787759280; x=1788364080;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=XReb/tURPpSv7wHa2G008+5hJ+djpIqcqcy5gPwUZsM=;
        b=YduvQt9FtwF+xlB/3u+glh/GqkLG7QLDKBm5eVP/k3a964ijUF8we/EX5B5vlaGTW3
         xaU2g4742GyIdHF2+VRiA1R7GDcvaMcn9O3jrfu8yDH3hEcfaF1VxWY4b6TGDzKv6/Kx
         /2uTJ/JgBOTGs0szkKuSj3uI/sW7iqrt1IeC34JWqtRFcrRfkEHcUykLK2m/ubRV3U9n
         LqAhDgbGXjubSDfdFhiEeYxpTFwkiktyMf/DyscANG6uut3cQWKktxNXupfYeZrXKnNM
         +ZcxW5Bp0NhuJTUIujN4sNvvfseN6T0WRJZvkLEF1vSI/Pd1aWHdgOV/VXDm1AKiMDvD
         FKTA==
X-Forwarded-Encrypted: i=1; AHgh+RrnU26Sl92Mld2bHJ9lYuY81HYAlNdd/J491NAgGWD2KkTaeqpmGW0VZwbl913VT9Sl/jE72tfuXNY=@lists.xenproject.org
X-Gm-Message-State: AFuF++lAYJpToAUp8GaExnvTb8s2h2hiuLuzBeAhoNYNubVLwAZOoE0D
	Lv7F8Ei2MUMSJnYCZgsqd73O8D+Fo+RfKNR8ZsnfvEGdZ4/dWdzeFYGy
X-Gm-Gg: AR+sD10NU9RjekcIwu0+5SRub831PttGBZRJbNT6v08xS5fVW95Z8emLmrTwRoy9poh
	DH8e+9J5LxEiMF+l8tFBBDaENzjpUU/n3/+Lpzxo1l3XRg+RYv0zdGMEroqePGG4XeC0/HEIwqy
	NRZ0me0eVzadsVc2uRHswyJ2gxAXqLN3Wsn25Csn7ij1flo+ZvA9dLq8DlWj+GEC+9XGajN/KXv
	vLEzcxtFNJhtDcQmYcVP7zoZz4jQaYBgncgvAs7DiWH1HIVVFxOnVJZn76Z21VsAVv56XWm4pyO
	ULdop6K3PB7orxeTjKg05gbYMmzOzg3aYYB0Wq+6MjgjSiNbrY4vu5/CrCAf8ME1WojuQjO06IK
	spuQbn3ME/x/6jPASVfx+jRbGfVcnqtIDuZSIRA/ePolQZvnhD/JdNaCBm453fPZtBt7ilBlNjB
	9sRu0vZgyuQ+c4BxAr7O5BpfCrDSfzgPxIuPYhjVKgpcJ8LDlXvP4f087ny64hMKLbgQNQPALmw
	DWaA8IDfClOF7FqxFtOkg==
X-Received: by 2002:a05:600c:8518:b0:499:a5c8:c6f3 with SMTP id 5b1f17b1804b1-499dc6e998cmr83031495e9.3.1787759279703;
        Wed, 26 Aug 2026 08:47:59 -0700 (PDT)
Message-ID: <c576b8de-b149-4d60-bc7d-436e06039832@gmail.com>
Date: Wed, 26 Aug 2026 18:47:57 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/arm: traps: report level 0 faults in panic_PAR()
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260825062329.16762-1-michal.orzel@amd.com>
 <20260825062329.16762-2-michal.orzel@amd.com>
Content-Language: en-US
From: Oleksandr Tyshchenko <olekstysh@gmail.com>
In-Reply-To: <20260825062329.16762-2-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787759280-CD94A87B-040E9015/0/0
X-purgate-type: clean
X-purgate-size: 3260



On 8/25/26 09:23, Michal Orzel wrote:

Hello Michal


> decode_fsc() derives the fault level from the low two bits of the FSC, so
> level 0 is a valid output: FSC_FLT_TRANS is 0x04, i.e. "translation fault,
> level 0".
> 
> This is reachable on arm64 because xen_pgtable is the zeroeth-level root,
> but fsc_level_str() has no case for it and prints " (level invalid)"
> instead. At the time the function was created Xen used only three levels.
> 
> Add the missing case. On arm32 the zeroeth level does not exist, hence
> guard the case by CONFIG_ARM_64.
> 
> While at it, make decode_fsc() decode also address size faults.
> 
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>


Patch looks ok to me, so:
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

but I have a comment below:

> ---
>   xen/arch/arm/include/asm/processor.h | 2 ++
>   xen/arch/arm/traps.c                 | 8 ++++++++
>   2 files changed, 10 insertions(+)
> 
> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
> index a3753c317fff..509040a1cdc0 100644
> --- a/xen/arch/arm/include/asm/processor.h
> +++ b/xen/arch/arm/include/asm/processor.h
> @@ -521,6 +521,7 @@ extern register_t __cpu_logical_map[];
>   /*
>    * 543210 BIT
>    * 00XXLL -- XX Fault Level LL
> + * ..00LL -- Address Size Fault LL
>    * ..01LL -- Translation Fault LL
>    * ..10LL -- Access Fault LL
>    * ..11LL -- Permission Fault LL
> @@ -534,6 +535,7 @@ extern register_t __cpu_logical_map[];
>   #define FSC_TYPE_OTH   (_AC(0x02,U)<<4)
>   #define FSC_TYPE_IMPL  (_AC(0x03,U)<<4)
>   
> +#define FSC_FLT_ADDR_SIZE (0x00)
>   #define FSC_FLT_TRANS  (0x04)
>   #define FSC_FLT_ACCESS (0x08)
>   #define FSC_FLT_PERM   (0x0c)
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 0c01f37ad6b4..dc0ec8a345ed 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -307,6 +307,10 @@ static const char *decode_fsc(uint32_t fsc, int *level)
>   
>       switch ( fsc & 0x3f )
>       {
> +    case FSC_FLT_ADDR_SIZE ... FSC_FLT_ADDR_SIZE + 3:
> +        msg = "Address size fault";
> +        *level = fsc & FSC_LL_MASK;
> +        break;
>       case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
>           msg = "Translation fault";
>           *level = fsc & FSC_LL_MASK;
> @@ -363,6 +367,10 @@ static const char *fsc_level_str(int level)
>       switch ( level )
>       {
>       case -1: return "";
> +#ifdef CONFIG_ARM_64
> +    /* On arm32 the zeroeth level does not exist */
> +    case 0:  return " at level 0";
> +#endif


NIT: Before this patch fsc of 0x00 fell through to default, so it 
printed "Unknown Failure" and level stayed -1. After the patch Arm32 
decodes 0x00 as an address size fault and sets *level = 0, while case 0: 
in fsc_level_str() is compiled out there, so the print becomes "Address 
size fault (level invalid)". So I would either drop the #ifdef (to keep 
the two hunks consistent), or not set the level on Arm32.

That said, I will not insist on the change, my R-b stands either way.


>       case 1:  return " at level 1";
>       case 2:  return " at level 2";
>       case 3:  return " at level 3";



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 15:53:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 15:53:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400024.1635966 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzFwX-0008EH-C3; Wed, 26 Aug 2026 15:53:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400024.1635966; Wed, 26 Aug 2026 15:53:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzFwX-0008EA-8y; Wed, 26 Aug 2026 15:53:37 +0000
Received: by outflank-mailman (input) for mailman id 1400024;
 Wed, 26 Aug 2026 15:53:36 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wzFwV-0008E4-PU
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 15:53:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzFwV-004ODN-2x
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 17:53:35 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8f0bfb-e002-0a2a0a5209dd-0a2a4509a3ce-2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 17:53:34 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8f0bfd-be1a-0a2a45090019-cddca5208af8-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 17:53:34 +0200
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67QEu0OR2499174; Wed, 26 Aug 2026 15:53:16 GMT
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g73n7e9gh-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 26 Aug 2026 15:53:15 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67QFofLG012609; Wed, 26 Aug 2026 15:53:14 GMT
Received: from co1pr03cu002.outbound.protection.outlook.com
 (mail-westus2azon11010060.outbound.protection.outlook.com [52.101.46.60])
 by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4g86hgfwvt-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
 Wed, 26 Aug 2026 15:53:14 +0000 (GMT)
Received: from CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7)
 by IA1PR10MB6123.namprd10.prod.outlook.com (2603:10b6:208:3a9::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug
 2026 15:53:09 +0000
Received: from CO1PR10MB5506.namprd10.prod.outlook.com
 ([fe80::da72:a0a9:5f18:cda4]) by CO1PR10MB5506.namprd10.prod.outlook.com
 ([fe80::da72:a0a9:5f18:cda4%6]) with mapi id 15.21.0382.005; Wed, 26 Aug 2026
 15:53:08 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=0/A8DnCCc2jsDsg4wlS1MABE/w+iLY/vkVsrq6r0xZg=; b=
	P/FWLtnKtspXnOW6qk96r87GbEMtn6dvZUOO1x0PtJ2SSDW0xNoRD5ar4v9+Ow3g
	+9BySTNemn/dp6O7UQwY7Gm+qBaLA1ZPtmK6s5KJTfHY0HbgEA4ORXXKRMBl2w+O
	3i/JJrUu43o/iLKfA1fFX9wlhPLhrx009xLWDN5mq4eC0H1pB5Q0jsF67s/APRs5
	7okd76sHK9M5DxL9whSEhHwng9V7ags+cJTchuYsZCRbUT7ptAKKv5PpgyE63X0c
	gTYqVElzLt+gb8JfPcZaLOGF5cnoZjJRLmdfZUGcIeSB3uRSAKgK9Q6MYmes2vaw
	9mPKZwMEfD5q9iRXsWk85Q==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=R3r8NXvVuFK0YBTC9/ItgoR7by8AS6FGi4Prd3ukxwrcj9fKWa0zQ/G0ljzxvnWkMb9SHdFOVBRnPPO3dUwp43GDSAqpqy5NsuWZBpcs/Dhogwm63Bxfn9NsKXPU1yvlVFmEZw8PWnGtP9xogkcwazFwdnN78b1p16kPJNKwwNiBoLCXkDmaFivEz+Zi/YKtlKWiNgIJ8n9jZxzajWLJJS2JpX5Yng0xUJBH7tNAw9cSutMezGtbcPHBqC+Xqk54CyGWgQZHIk+wjFCLYor73OptyKn2sStN3AozW0HM6EPD6nKWcfQfCYnMsVd/bDRhYUC2ZM+Ut7LC9stUW8pKfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0/A8DnCCc2jsDsg4wlS1MABE/w+iLY/vkVsrq6r0xZg=;
 b=LmDmZJj/aIqMPZnnd5JV343uQ65lN7NadfqYIUngQELZL5PGr3gYpvG5abUIOA6b3gllDD4IltS+b8naebHQgDHDnMUtRPP8esMv1zc2khM1PYtA9HYhv25iYZB8yBHVKVqfs9ZUSi7z/Rwp5MouFjLc1sqdLTdOJw2bzH6YYTQUuNHW6FHcMwc8n7azr+MNCO5ok3CfwD9mSY748V9uyaDQW3OZXTguUwXFZW4x/DvCLjUzuYMTTqAD2K6ggncRY3dNZlIyfrEoaoMz9W3Z4n2766uB++lpOhQxJOIcMXc11pOuImTA+ATbVge47GdgY5ZugYJl03Dn1k538eyQCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=0/A8DnCCc2jsDsg4wlS1MABE/w+iLY/vkVsrq6r0xZg=;
 b=Nv6WgxDMkD/bVyqAU+dgfAd1lf2FV49mm53jIpkSyyqr9qo3oPBCSJHQAvo/GMLMzHTeT+vskdOa47kJ0/cPmMG0xu1ToVrkpcSvwzfCLyHu3+bXca0BhzLFQL+c3Qu8VvlauYc3i9qNWxMfNk1GFUPd1iddx2Ivi9IuBsO2nNg=
Message-ID: <e9630f86-0c9c-4846-b3a5-237f7a052be8@oracle.com>
Date: Wed, 26 Aug 2026 08:53:04 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/8] qdev: Support forced device_del in QMP and HMP
To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org, dave@treblig.org, mst@redhat.com,
        imammedo@redhat.com, anisinha@redhat.com, philmd@mailo.com,
        aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com,
        farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com,
        david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com,
        cohuck@redhat.com, alex@shazbot.org, clg@redhat.com,
        akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org,
        anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
 <20260824011420.752806-4-dongli.zhang@oracle.com>
 <aoxYTO8UkzzXvKOc@redhat.com>
Content-Language: en-US
From: Dongli Zhang <dongli.zhang@oracle.com>
In-Reply-To: <aoxYTO8UkzzXvKOc@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: PH8PR02CA0002.namprd02.prod.outlook.com
 (2603:10b6:510:2d0::11) To CO1PR10MB5506.namprd10.prod.outlook.com
 (2603:10b6:303:161::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PR10MB5506:EE_|IA1PR10MB6123:EE_
X-MS-Office365-Filtering-Correlation-Id: da192af0-9b7a-46ae-2258-08df038a1f89
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|13003099007|6133799003|3023799007|4133799003|10067099003|56012099006|4143699003|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	n6dpMtwxManI56moXK6lRuHKxv2iO3Og9rM8eRvAbrbssK5rTZFx4DhVkaJDuXma7nCiwyMvXZUZYmxjaFYS4Ada5Y/YvP7+V0n/AuBiSWCzOxsjQIsvYMOVuKUJpeRBgYx72v+ItaFv+CqYuVXgzZ2bwsnhBtsqenLpkzO7wWEkXRL5nPuYU9c8lwW71LytiKvAhb/VSY2kETJKkTyFw8uGVoY/YxyeXGx+JglckQoPG9NJo2BjXGPiWEsqJXJoO7slc3dxbZwXdEnvYARxxdTMLuChouCRiFZzj6axFHjw7GJMTymQF4z6GRCRzelOG3mibBZq7ko9MLZxMzNDhia+O3xA1WhBolO3SqHs/5NGQD/lpRWIPtMXRLH3pFpyku+EZAYjXt8eCgZFLnUw5qhzAXVGfcZvZmJTN9QTlepXr1+NcSPU6EsP7OE79wt5hpf49Zkq1XA7nuBVWZfJ6czXP2jFIyedDXLXTFIrAuhcTvyJmFB/o31hKeHeB1SVUJHNyhwTS9ocXp5NOZyk9rzPmbjmNUBCaI5kxnh/mfP5kkCybUx3EjfIpGhMKlm9tWoKVqGDFC9Hh4pbmQmnNrrvVNvSdyDx342wENSYfG8=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR10MB5506.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(13003099007)(6133799003)(3023799007)(4133799003)(10067099003)(56012099006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QmZCdk5KWHhSTDhGZ0dpRElXdFFYZEhNZ0FtM3k2N2hnemZWSWMyQjQ1Smta?=
 =?utf-8?B?R05rb3hKYTgzQmE1T3NJYnNTUnozWVQ2SmNEaUh2dU9RQ3lRYUV4RC9scTN6?=
 =?utf-8?B?ekxhSmU2SnJUMklEM0M4Q0lDakxhbXFtN2IwM2FtbUtiQTlidHJBR1hKUGpN?=
 =?utf-8?B?cnd2bmo3Mm5hU0hONVpscVg5TGtndUdFcjlrTmlkM0tjUTJ1T1RTSUs3UVZE?=
 =?utf-8?B?djJkQ1JURVBvNVBucElYRE8zN0hFVm9mWTBJNzNKcDJNeGs2bTB2MHZ4V2dx?=
 =?utf-8?B?aHdTazdGUzFqQVNVQ0swbWdIQ0lrczVTTXdxZHdxN2RLL0o2bVQyMHVDUlEw?=
 =?utf-8?B?d3hGeWlybCtXc2Q0cmFqQ1E0WXJRQXpISm1iSWN5dDdQM3A3RWlYNlh2eUJs?=
 =?utf-8?B?U1pXTllxSm9wT3cwUHg4N1FiZnpMY3Bod0paYi9sUE8wZ2F0VnFxdU54VllS?=
 =?utf-8?B?bkwweHhrcjBJWEo1RGxRcmdPRTdLN0FsUmllZEp5MjZnckc2dXVRS0xkeVUw?=
 =?utf-8?B?WU5ZbWFYZHU1WHQvR0VRNWxwcmYrS0gyRWFHWER6NHdIdHB0cVdrdG5xdWU1?=
 =?utf-8?B?SG9aeGs2RFBiYWRxYTFYbmtjZkhmWkJYdHZCdW5laUNvYjZsL2pBWEt1ZzRT?=
 =?utf-8?B?NVZFNzBxVUFVU3E2aWVlY29QR2JjMjVkeXZXS1lLZEFrNWFJWVUvTTVLazdx?=
 =?utf-8?B?MEVvdFFKbUNaeGN4Y292Y05VekdKd1lwdVZOTUV4M2haNlpZVHpiRWx2WVMw?=
 =?utf-8?B?Sk5FNUNDL01LT21QQWlGdEd1anFveUlhcWQ0cXVTK3RaclVta3BSWjZDV3VI?=
 =?utf-8?B?QUZkd3FLK3FFTERKak0yNWs5RC96UlFEM3llK0p3VlV0QXBlMWxkakl5R1JN?=
 =?utf-8?B?anNWQS9PZDNRSUswMW12R0JlcXFRdU9KUjI5ZVRFanY4SlU3V2lLVjZ3UTFS?=
 =?utf-8?B?dHhJN3c4ZCt6N1NSNmd6SjBUdzU1b2x6ak1xMmxLQjJyRzNMVGQydFB3NmJ0?=
 =?utf-8?B?MGF0RjBuUG42NXpncGJMbXhJeHpNbStDNGJETXhZZkVFc1c0dWcxc3NBRlZp?=
 =?utf-8?B?M2c5SlFFOHdnQTdHOEFEeGJmQVZxOFl0MmhXUTFuUlVremo3Q3p5NGVrSGkv?=
 =?utf-8?B?OGx3dEZkUFNCU21ZRVJHVlRWUWFrZCs3VENadW8rZUFXS0tBSUo5RWhFc3dx?=
 =?utf-8?B?eTNuZEF3a2pjdWpxR2pIQmhhdHU1NlRsUjVDN0R3WmIxUWtCdEtHUHJUSitU?=
 =?utf-8?B?NVhMdW9KZVR1RW5ZbGVvb3ZTQ3RpdENYYmtNbC9HUGdnV2hOT0d5NzcyclJK?=
 =?utf-8?B?WGsxU3NkWGdxQ0k0QjZjcWU1eHRMcFltMHVtWTg5eWs0d1VkZmVXT2VrR3Bm?=
 =?utf-8?B?YUxlYmNnU3V0SWNSZzdvMnhJeDA3aC8xaWlwb0hhU0J1NFBGUG1TZlVyWUlC?=
 =?utf-8?B?NXlSaXVYTm1xL1pQUEthVzJOS1JReDZ0MnV0VUIrN3UxcXZMcjNMU0x5aDlI?=
 =?utf-8?B?Mk1xczRrSjdxR2FtMG9LeGtoYXJCUzJyR05hdmJ6LzdKaE5QMVVWUU9WdXAr?=
 =?utf-8?B?WkFBdE5GalZTZDVKM1kwZzF3ZU14NFpSRjBlMHFSREppUitKdThVSVF2VGtM?=
 =?utf-8?B?bnduajZGa3g1alhLVU1PQ0lGaXR6aVdHdUJBVForYVpMY1JHSit4TllFZ1pT?=
 =?utf-8?B?VDdLZWRCZysxbEhHZHlxdXA2YVVHejgvajZIajBMM0pIU2tQcFBsMm8rcXRD?=
 =?utf-8?B?ai9JdFFiNFMzc1Y0eWl1Tzc2aU85K3ZmNExJZFJHL0xlKzJVazFBcU8wTjB2?=
 =?utf-8?B?c3U2eHRuNTZzTmE3SlJSNmEwRWxERlFFWEFYN21vOGhxZVYrVncyZFRZSEQx?=
 =?utf-8?B?V0laUVVNS2JKVVJkR05uMFZ3SU1MV2xHMTRZOUxTL0hHNTFBenRiSnVmWmhT?=
 =?utf-8?B?NDV4MEg1OVRBQ1NIM00yNnR6NTR0aEJ5WFNLb3NNSlBvSHBGaEo3ZEdmUXR1?=
 =?utf-8?B?dVR6TEdTaEs1R1ZhbXI5eUM0MEozdGpLWUNUeDNnOWRFY2hSRDNTRmQ5N0dE?=
 =?utf-8?B?SmZ2RUk0eXQ2Tnh2enFVVWc5eCtYQlBEcFVsSytQNlJVYmJUTWNFeFlaSW5U?=
 =?utf-8?B?MnhqdWdyS2NWVVdlS2lyelp0a2VsRW1JcW5Jd25VRk1tQ2VqbE5SM1ljdTZG?=
 =?utf-8?B?MkFiSWk4SHlUc0hVc1lId200ZXBTN281Q0ZHKzZPb05TOGd3SE4yRzg5RGdU?=
 =?utf-8?B?TXl4Mkt2Q1A2LzZ2RXM0RHlmWU5JRW5sZ2dmWUkyMkxrZHhtZjEwOTlpK2dH?=
 =?utf-8?B?TXBpeHIyWndhcXIrWFN0NXVBVStZRzhKVFNYVXpwb1QzRlQ4K2NsSXVpaXhE?=
 =?utf-8?Q?dQLt0PlwnU9Med78=3D?=
X-Exchange-RoutingPolicyChecked:
	ZgEw9wfzFBcUbQJKXLVBbyYIDMnjyNBlGaqL+fe4lputLJOhztHMMMhEIlSulEyCOsl9OaNdRQsBQv3LhrKmI4J22ZS+N5b84khWZAYMkpkG0/EfSFeHvZCz6PKPZwHa57FCSSEQnfz4HOzHSuM0ylYaFLZ8dwfAeda8j0+6GHKEan0LuKY9lbAXOTEZph7opKSoFMuIaTIVJNQikN2cqBcsrsmFVuXskcV2a7ZBWMUs9z7WT5emonJZ2q1Zs24Fum+/RWN9SKPOyE1UHlig438sIRTlG26CONcls7tdSOgXbFHMBo0Xo5hH3z/1iCnuf8vTCJM8ImiBPY0bl4306A==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	AmIadBCqhWRJihZTJytSnpDvpq1Ydgdi8xKOCVewR1hcy850HDhDMrcgaFKvIREJm3jhXjlF+dtDmNCkIMmER494kN+6QQdibevDM/0lt5HbKSLgoHzygL6LZqyFSaWpZnDwLKjkiPLOUjEfda0vYPafCSvV8oA5qykXKmVoWMxvNN25Sy+3eO28v+9bXoQ2n6P+CamyD0BFJTDXGpf29nPT1ARxRrUXwK+F9bLeK9E4VZbq4jdcKIBMgYqkyg76Iu8ks6GXqVMYyIGSGkrqjqQD1jnYAiv/2lttRS31SmEq64gLMnTULlTa5WAO1D5SS2LGHYo8e0PN8oYVKNpBwB9WZ8nJLr1+lyrzYXJa3yN1XBp2WWPRSqliWog5d0wkEkoULrweAkfn/3g9myxLErkiC/O+G8AG0paum0sXzZHlHe0A2mK80YSgJGe5RYwiHCloGTBqqFZq46enO5tZdFc2sojEyAMNeUE1DGJA2Q3R11sn/o//qVhuJ3VbRrx9VzSqt1nuB2rdVGgbuJ9pEvUgPQIgXotxwHlpHN/ED+62rDR+AXvZgxpbwiQCmEhcdeS7MHYeYVUPd66KScDurnM32fjkjvaLkHI+fdULbHc=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: da192af0-9b7a-46ae-2258-08df038a1f89
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB5506.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 15:53:08.0471
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /eteGN+dqsPn5lDJ3RlWR1GfKcGuqvOXHvZsEgHC/el7DKDh9VP3BWMnErufIbqd1kjHHQf5PeU2fSOpPrXk3Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB6123
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-26_04,2026-08-26_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 malwarescore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0
 bulkscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2606160000 definitions=main-2608260132
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI2MDEzMiBTYWx0ZWRfX982KFWchEVd1
 QdVlvAfAajimDoItsBsVigGulod/KY/nf8XTnziquEzjjGAPwPSi6r7bMkzAsxie6DfL9QiWe/Z
 Vsb9ReKSVCKY2u2HOSFZwbfMf83thrfa+V3m2gVTxWoO073U3TudI0VRkujcex7zWzQZ4gOPrge
 Z2CXw8LGiMBiWs23I+hh3Vy0mry4FCcYKWiXw/Wg5gaOWYtJR4kTgbFQNCg2T84Px/orsmYiUOU
 RG4hFYAQ4lgUbz3h/iY4CYYrb55ugsBXANMgenG3vtC5tiaaJKjOtMBg9mtIGiGa7jpQPSpVx6k
 VeVmyYAQ50lYfvDPFo7WpFD/1rLhYVrqkKU3vD7B7gU3TusjFJELI/XgAl6Sl/jKmQK5MwP66i3
 pum2ocJjgns16vm7rOzhsLXWLUD0NN7CudpPQirAZ8JqUf0isZJjYXAywra8CQeABmSglVfR/tl
 dk9R8/X7EeUm14sdlM8PgHa66MhVMmwW2s2kvgPc=
X-Proofpoint-ORIG-GUID: mg_XTCcmfTT-G7pHZie8u_HufaPVrwV5
X-Authority-Analysis: v=2.4 cv=Os9/DS/t c=1 sm=1 tr=0 ts=6a8f0beb b=1 cx=c_pps
 a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10
 a=Sv0fKeRqtYgA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=jiCTI4zE5U7BLdzWsZGv:22 a=EIcjfB9IiI4px24ztqRk:22 a=uherdBYGAAAA:8
 a=E2OFlpCjAAAA:8 a=vqL-DJG3AAAA:8 a=SqMvC5kiAAAA:8 a=J7Vs0gARAAAA:8
 a=iXcLlBOuAAAA:8 a=j9CL5N7RkkbU71RAcT8A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10
 a=l0t8tTNIJzRGstKQVvrs:22 a=N5whb6oI2XAsh5LpMrx1:22 a=_o8VnCo6Hb5Oqlm6Mk7M:22
 a=GK7RtA2AnwkbbjW1WRsD:22 a=U82d2PgYpd_3u6iqMSvn:22 a=5yU3S35YU4bGjq-dph-N:22
 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:12101
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI2MDEzMiBTYWx0ZWRfX4YgsYxj7b7pQ
 GsPe+mSN4P07W++R4pGolCXlGbXIDkK1CeO/FXfvDH8BygBJ0FvjND/zHEpT9Dw71644MFcrU+l
 DvTuigbirq7BD10gjAaJ5wVgtulUjtK1tTXY9vIGz3khahSTYOaI
X-Proofpoint-GUID: mg_XTCcmfTT-G7pHZie8u_HufaPVrwV5
X-purgate-ID: tlsNG-bad1c0/1787759614-3B4D3034-277A5E76/0/0
X-purgate-type: clean
X-purgate-size: 6258



On Mon, Aug 24, 2026 7:42:20AM -0700, Daniel P. Berrangé wrote:
> On Sun, Aug 23, 2026 at 06:13:33PM -0700, Dongli Zhang wrote:
>> Add an optional force argument to the QMP device_del command and expose it
>> in HMP as "device_del -f".
>> 
>> When force is requested, qdev_unplug() bypasses the pending deletion guard
>> and asks the selected hotplug controller to complete removal through its
>> force_unplug callback. Controllers that do not implement the callback
>> reject the operation.
>> 
>> Forced removal bypasses guest cooperation.
> 
> This sentence is rather missing the punchline....
> 
>   Force removal bypasses guest cooperation and may result in guest
>   errors, I/O failures, or guest panics. The guest OS cannot be
>   trusted after force removal until a full power cycle has been
>   performed.
> 
> I'm rather on the fence as to whether it is a good idea to enable
> this feature or not. If it is used by a cloud admin without knowledge
> of the guest owner, its use is liable to lead to hard-to-debug/diagnose
> problems in the guest OS.
> 
> If a guest OS is not honouring an unplug request and the host owner needs
> to force reclaim a resource, power off is always there as the failsafe.

Developers with knowledge of PCI/PCIe/ACPI and system kernels (Linux, Windows,
and BSD) know that the guest VM needs to follow the appropriate protocol to
power off or eject the device from the VM side so that QEMU can safely remove
the device and send the QMP DEVICE_DELETED event to the cloud administrator.

Assume two scenarios:

1. Due to an issue with the guest VM or QEMU, the device is never detected or
used by the guest VM. Especially for ACPI-based hotplug, allowing a forced
detach enables the user or administrator to avoid having an un-detected device
stuck in the VM.

This is safe as device is never used by guest VM kernel.

2. The VM owner may expect QEMU to unplug the device even when the guest VM is
not cooperating. This provides an option with a clear warning: yes, we can
forcibly detach the PCI device, but doing so carries risks.

Thank you very much!

Dongli Zhang

> 
>> diff --git a/qapi/qdev.json b/qapi/qdev.json
>> index 974cf9c583..cb5b5ad1db 100644
>> --- a/qapi/qdev.json
>> +++ b/qapi/qdev.json
>> @@ -90,6 +90,11 @@
>>  #
>>  # @id: the device's ID or QOM path
>>  #
>> +# @force: if true, remove the device without waiting for guest
>> +#     cooperation.  The guest may still be using the device.  This can
>> +#     cause guest-visible errors, I/O failures, or guest crashes.
> 
> I'd want to be warning in a stronger way.
> 
> 
>  This is a dangerous operation that can cause guest-visible errors,
>  I/O failures, or guest crashes. The guest OS state should not be
>  trusted after a forced device removal, until a full power cycle has
>  been performed.
> 
> 
>> +#     (since 11.2)
>> +#
>>  # Errors:
>>  #     - If @id is not a valid device, DeviceNotFound
>>  #
>> @@ -101,7 +106,9 @@
>>  #    will automatically complete removal for all devices.  If a
>>  #    guest-side error in the hot removal process is detected, the
>>  #    device will not be removed and a `DEVICE_UNPLUG_GUEST_ERROR`
>> -#    event is sent.  Some errors cannot be detected.
>> +#    event is sent.  Some errors cannot be detected.  If @force is
>> +#    true, guest cooperation is bypassed, but backend cleanup is still
>> +#    performed through the device's normal unrealize path.
>>  #
>>  # Since: 0.14
>>  #
>> @@ -117,7 +124,7 @@
>>  #          "arguments": { "id": "/machine/peripheral-anon/device[0]" } }
>>  #     <- { "return": {} }
>>  ##
>> -{ 'command': 'device_del', 'data': {'id': 'str'} }
>> +{ 'command': 'device_del', 'data': {'id': 'str', '*force': 'bool'} }
>>  
>>  ##
>>  # @DEVICE_DELETED:
>> diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
>> index fa3cae246b..ca10a25c46 100644
>> --- a/system/qdev-monitor.c
>> +++ b/system/qdev-monitor.c
>> @@ -956,11 +956,13 @@ void qdev_unplug(DeviceState *dev, bool force, Error **errp)
>>      error_propagate(errp, local_err);
>>  }
> 
> With regards,
> Daniel
> -- 
> |: https://urldefense.com/v3/__https://berrange.com__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAJ3UvkOW$ <https://urldefense.com/v3/__https://berrange.com__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAJ3UvkOW$>       ~~        https://urldefense.com/v3/__https://hachyderm.io/@berrange__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qADJDqpwa$ <https://urldefense.com/v3/__https://hachyderm.io/@berrange__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qADJDqpwa$> :|
> |: https://urldefense.com/v3/__https://libvirt.org__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAPWCfpLe$ <https://urldefense.com/v3/__https://libvirt.org__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAPWCfpLe$>          ~~          https://urldefense.com/v3/__https://entangle-photo.org__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAN7fX7fq$ <https://urldefense.com/v3/__https://entangle-photo.org__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAN7fX7fq$> :|
> |: https://urldefense.com/v3/__https://pixelfed.art/berrange__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAH19vj8f$ <https://urldefense.com/v3/__https://pixelfed.art/berrange__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAH19vj8f$>   ~~    https://urldefense.com/v3/__https://fstop138.berrange.com__;!!ACWV5N9M2RV99hQ!
> Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-
> DL2qAJz0R0XI$ <https://urldefense.com/v3/__https://fstop138.berrange.com__;!!ACWV5N9M2RV99hQ!Np_bt2bKAVenBs32tlW80kBTAEEBD9uY3zjXBII-WZ6Yj3TRV1O5I7WsA70hJm0q3YdPBwu-DL2qAJz0R0XI$> :|
> 



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 16:16:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 16:16:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400037.1635975 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzGIU-00048f-8D; Wed, 26 Aug 2026 16:16:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400037.1635975; Wed, 26 Aug 2026 16:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzGIU-00048Y-3y; Wed, 26 Aug 2026 16:16:18 +0000
Received: by outflank-mailman (input) for mailman id 1400037;
 Wed, 26 Aug 2026 16:16:16 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dongli.zhang@oracle.com>) id 1wzGIS-00048S-2i
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 16:16:16 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzGIQ-008zzI-RR
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 18:16:14 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8f112d-8faa-0a2a0a5109dd-0a2a4503c832-38
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 18:16:14 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dongli.zhang@oracle.com>)
 id 6a8f114d-fae8-0a2a45030019-cddcb1200b00-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 18:16:14 +0200
Received: from pps.filterd (m0246632.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67QEtr842160199; Wed, 26 Aug 2026 16:15:56 GMT
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4g73csxcr6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Wed, 26 Aug 2026 16:15:55 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67QGAG0p018105; Wed, 26 Aug 2026 16:15:54 GMT
Received: from bn8pr05cu002.outbound.protection.outlook.com
 (mail-eastus2azon11011010.outbound.protection.outlook.com [52.101.57.10])
 by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 4g84bsbas1-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
 Wed, 26 Aug 2026 16:15:54 +0000 (GMT)
Received: from CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7)
 by DS4PR10MB997596.namprd10.prod.outlook.com (2603:10b6:8:31a::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug
 2026 16:15:50 +0000
Received: from CO1PR10MB5506.namprd10.prod.outlook.com
 ([fe80::da72:a0a9:5f18:cda4]) by CO1PR10MB5506.namprd10.prod.outlook.com
 ([fe80::da72:a0a9:5f18:cda4%6]) with mapi id 15.21.0382.005; Wed, 26 Aug 2026
 16:15:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=eUlWXSPmG5Oj35GDHQ8dXvXUpIBp8XGO8wlhNWDuUtQ=; b=
	BtDjGgokf6867I1MUhOJRG+jIMwpY5sQVKVIcvPQ8iAJ1L0xJSPJjERwPtycHdQQ
	bE2yzJumJGAyPWr0MH3DwjxW9H0Yx2FE3pBcvqCMPZcpQbeH+uNr137MbRDgnpO5
	UTaELf2BVdJ1vyhrMzcDMMpf3h1Z5P7tsrbnBfNI/yjAckf73ezAoRYc/udSQi6f
	AlTLYqA6PtzBEM8nXe64T/Y+ZMUH/7m6NS0uJRw/MZ9XVVgub2s1KHJbImdaxSFV
	1etcg7Vfx45Mp+Wit3/u8GQvHEMdx6fk5EZwSalbRNzJCvRmgeBuugHxE8anxET5
	hnRzS6JPy6evayieQmqJcA==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=cle9CLSKWY5ML+rAO+MSFehHgL8ePD68pNmMvgMddW+jAjiPYm4xLoY8YagkMwcCTiX3CiyExlTlDGEnjzXkyd11cxHpJW/if6wBB82fF9x5qu5Tef1TXyzhZDxMAUuDXNCG+nQc4xstIs0o/ZTy6p2n6A2Y84yZHy67dqAi9n3UbZy/BM8KPFyWZWYWfJdCugC1fhp/T5FBp6CzDZO+R0cresrP8C/gCqM/oLbLaHwQJHZBPvpCHLoMCtxkzcQrnmnmW3Rm13lsI2rSiUZMBA1e1GVciUVRMTaYyGrQ+6vOqTrcOWfeLIokjBG3s74cK9H+0sCbD8v+lHpODp80Vg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eUlWXSPmG5Oj35GDHQ8dXvXUpIBp8XGO8wlhNWDuUtQ=;
 b=m5lX8TxAe3CjZXG3hZXzwVtcUP8vbrj4k3drJWrLQ81r8AOLUB9XfSdQ6qbuvYbP2UpRLiwgER10J4jfvfAq19DRSFm9B8Yifjm7d9LTz/SY8EkbLykO2LsPUSG6QxTUODabgz9MxZ6kSAF2RgQIWk9SD1zSfIR0CMQL+XNLX+INiSemCdasPKPzySEYlTNChAhyUWHFyHBk5AJQMatTv668moW2ZVVmX8ya8VGkVmlTcleMGIu4KyomRm3PP3uuCD3gnLwi4/T/PRyYCtvP35ybmaio29O261n03GaP9GLM0qwcE3RTWnxfTDUM8ap+o9D1GS+N6p237utT6ZGXBA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=eUlWXSPmG5Oj35GDHQ8dXvXUpIBp8XGO8wlhNWDuUtQ=;
 b=0AtQWX/vdUDIbfU1MsguoP3nMa1ls29OVszdO1RbzUwt1MNW06zIpTi6ffmmmqLswSBDWf79C4DirkcWYN+q54Lb/hk06XZZMIYNZsbbuCgUA0JSYedZWWeZ91VEcuhDXShOIRmPF1EII6PYtAiknNhN//IuDYBbfDBfEBMhaiM=
Message-ID: <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com>
Date: Wed, 26 Aug 2026 09:15:47 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe
 native hot-unplug
To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org, dave@treblig.org, mst@redhat.com,
        imammedo@redhat.com, anisinha@redhat.com, philmd@mailo.com,
        aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com,
        farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com,
        david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com,
        cohuck@redhat.com, alex@shazbot.org, clg@redhat.com,
        akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org,
        anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com,
        eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com
References: <20260824011420.752806-1-dongli.zhang@oracle.com>
 <aoxY4Rxst2qAyn5z@redhat.com>
Content-Language: en-US
From: Dongli Zhang <dongli.zhang@oracle.com>
In-Reply-To: <aoxY4Rxst2qAyn5z@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: PH8PR22CA0015.namprd22.prod.outlook.com
 (2603:10b6:510:2d1::23) To CO1PR10MB5506.namprd10.prod.outlook.com
 (2603:10b6:303:161::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PR10MB5506:EE_|DS4PR10MB997596:EE_
X-MS-Office365-Filtering-Correlation-Id: 8fdca74e-4c30-4f12-7c7a-08df038d4b5b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|23010399003|7416014|366016|1800799024|6133799003|10067099003|4143699003|56012099006|22082099003|18002099003|13003099007;
X-Microsoft-Antispam-Message-Info:
	xkMoaoHhCCBC0C9Y8ZsWcIIxBZYPUfy/Oh3/lBn1WLEVBksuw1364bY+TCXt/JsEEPrciz7FhTv7rCkEm2V8soqc40a7O/ZFiNgoBlk1JDmOT1W3peQYhYU/9cGI7WmJiNVhXhxCjp91hazFOtjg8dy1YiIl86PmQXwmARk7w24jbtamRP3P/8BI7TwzPBpaekQg+9tSpYtbIcGefhZZgS4scP/7BGJRZW+zLHIe7DHDDLFZuK41lXCa5VMULX8vs744ioVkQ0/9dLk8s/LOhx/Q94Wc3WKEgB967Arzxh6pMqSTwtnn0ZdSke18V242cu/iGd07+pAfGdovLv26PnYTGVYsanCTYxoAnfX0kNWHIdh/gifyotlWbD5d9m4SqU2NqIA9ttgiCfI9RXSwl6gNiLpvA78QGD411Ka1GOR/YOrE281UHZ+ela21RTBOHZCZYI0Bigb5zRjq29JghT+iQvgcluvIQzndVblPv6vEHU6bZRe4ZPMesN+j/0kS/q9Fd6JwyTJFuG+CkZ9JTGJjAMVo8pCc6aPhsvhXwbaROvg4CwCmtjyKBCKM7Xtq91M3BDx2ronn8LoY88cQts3TSnUamBbWAo9E3xtoNZv656uVWd/21l7JhkFuUevVPeeLET6ZV2oAmekHuKT5/SYTJIn+LoKRdP2758dqFWY=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR10MB5506.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(7416014)(366016)(1800799024)(6133799003)(10067099003)(4143699003)(56012099006)(22082099003)(18002099003)(13003099007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?M2d5Y1JtbzNrOEkyaHZEZVhxOUxRVStCVGpJYWg4N2NudWN3V3p0K3RiNnY5?=
 =?utf-8?B?WWc5aFVkQVdWdXVXbVRLY0NEaXkveGJJVEVlNk5Id0RnVUtRV1hWbGh3bXh0?=
 =?utf-8?B?Zk9iaUpXeWQvdXJUZU5tL24xNGdWMXUzZ0pmVHlBMDFUZDJMZUc4RzhoT1RD?=
 =?utf-8?B?OXdsSTU0MlMzS2VLVXZyckxMdVZTSm82UGhEenVZWUR4S0NXa2hoZlVRQ0RV?=
 =?utf-8?B?TWhhQnNsWmcxbXRGd3c4RVBnUFpVR0hmZWlGRlpCY1E2MVE2ajFORVh4MWho?=
 =?utf-8?B?SDN2eFEyUVVUL2gyemVJK0RvdUc4MmZoQlB2Z1huYzdlYXdNdSs2aTRhaWJ6?=
 =?utf-8?B?TEc3TkJHU3ZWdi8zbjh6WjBFcm5uUXNtRmpjNjUxcWRNcXhzZ1JEejZHNUdZ?=
 =?utf-8?B?YU1IQUdBSVBXenZPNEljMTJvU2NqbVZsc0NjckQ1bFZXT0IyVy9DOFU2d0hi?=
 =?utf-8?B?a3hHT2E5aWtxTSt1N28wcDRFb3d5S0t6WFl0djhBOFh5UXFkVVRSVXVycnFt?=
 =?utf-8?B?dUYrRmtTbnBvSGRaSTQweGJJKzJEWHhyMlhlY0xyS0pmMVN2UG9KMVlsKzd3?=
 =?utf-8?B?WENwbitTSC9yaWJPVjNBSHhzY2Zyc0Z4eFd2SVBQOFo0OEpONUxudmJlQUZG?=
 =?utf-8?B?VVlJVjdoY2ppUm5OQy95YU1EWGVWd3pjbkNmTER5MGZRY2xBREx3SzcyTDBp?=
 =?utf-8?B?WE96ekhSTmExTjdEdk9FYWVIb1FHeUJVdFVQVFJTZ00yR2dvRUhuNGszd1Er?=
 =?utf-8?B?cExCTzNnZWdiVW1ib3ZuVjA0OU1MYU9SRVJHUHd5ekZ3d1V2UTk0UWVrL2p1?=
 =?utf-8?B?VXh6VXdnSkV1bEJmaXh1djVzZVVrdlM4czlpMnRuUFFaQVRBQ2FLQnMxOFpQ?=
 =?utf-8?B?R09sNDhHVEJ4WGJLb3ZIZ0RqU2JCcm14eGpuTTAwYlljQ0JHMTRtcndEVHNO?=
 =?utf-8?B?SHg3STNNV2QrdnVzdDA5QzBZbmZiaHluY2ZZaytmeHA0cTJwemcrRW9GejlX?=
 =?utf-8?B?YTdwSm1jQ1hjeUdwaVM1cCsrUEdvSG5YNUs0R3F5NS9XbEtuMnEyQnluVHVk?=
 =?utf-8?B?aXNmVVZjdVRYQ2pkZjVEc1ZIQWZKOEt4R1BVVVZNT2trVkgxVlMrKzFWREVS?=
 =?utf-8?B?aUdmRVlzQ3ZNdFYxVkk0NDNWck9vbVZvTW0yS21nVmtDWFJidnp2dmhMbHZO?=
 =?utf-8?B?RUIxY1phQkdBc1dzaGVYL3hnUDBsczlNQUUvR1VTV0t0TGZWck1QTjE4cHFN?=
 =?utf-8?B?Tk0yamlnaUFrNFQ0UzBBeW5JNGFFTjcwVHVnMTV3TXlCU2FmbE1FYWk2RGU0?=
 =?utf-8?B?YzhXODdMMXB0bVM2eTk2aFlJTXVKdjdKRXgrUlQ5RCt5RFlTeGFYNVNxYlBs?=
 =?utf-8?B?OXp0cHZDeFNaQUQwdzFMV3ZFelNzeU1SNVI3cW5MMkM4Qzk0T0xUeGkvRkZQ?=
 =?utf-8?B?WmoyY1drcVhTbHdFM09sVm9jUld6cGdIN095WFR6dGlCOGN3eTROcTJueGw0?=
 =?utf-8?B?VFlqTHNVU0Nvc1NWMmljMjltWGdmMFRiNlp6NWJjalN1R0JRYWNTcHRodGI3?=
 =?utf-8?B?MldCOXpjYjQxQTA5SjFJNHMvTjVnSUNmRHQ4WVVIaXpkemF3aEpmOXFyZjMz?=
 =?utf-8?B?Tmh2bVdOQ0dreURrN3NaS1dFQThTK3Qxemd6OHVSZ3YreWpkSm5ZOGxDYk5o?=
 =?utf-8?B?WjU3dVRrOU0zOGY5QkJHbVVUVHhkamNxdkZteFN5OVoyTmh4RHBFa3hxRk91?=
 =?utf-8?B?clJXK1Zqa3BoSHNZUTZSb2FCblpCbSt0RU81RGdrWGptRFpSUUFIcG14VVpi?=
 =?utf-8?B?ZEtkTmZGQmU2RFpuNlpSaTNRN1lPMENhMWhVUUR1K0UxaTRTM1RjNWUxdXZX?=
 =?utf-8?B?aDhwTjNtVzlrMmVJN0w3TmplempTdTBPdFNMbElwaEV4b0c3MDJmUEYyTmFl?=
 =?utf-8?B?WlBKWVQ5aDJ4S284ZU1tV0VDZEExNGtGa0NIT0JZR25Td1VkeVdESy9hMHB5?=
 =?utf-8?B?d1kxZDlCK0xQbWhNdFdUNEFyZnBrZWFJcW1YeEhsOFFTbFhrTTdzZGlXMTZV?=
 =?utf-8?B?MDM1YnBETnFmeWpBb0RTblF2QkJQT2phQW9OaE8rRXd4TmtFK1VLWnF1Z0Za?=
 =?utf-8?B?WkM4YUpEWmd5WDhjc09aTkpwbWdaOXdpbENkSkhZSy8xZWthVkI3WnR0MTAy?=
 =?utf-8?B?bUJsZ2xZVmlobytpaW12WUdtaXFDK2Z5L3ZTUjdUa25TQ0xiM2RrM1FNUlZi?=
 =?utf-8?B?OFlURHBZWkxwblZFY0Q1cnNTTkhHTERjUEIxWENvdWdFWXExa0dNRDRsWENy?=
 =?utf-8?B?Tm14c003THlTWCtYcUpBRTFnY29YVmFiTE0wZGFHQTdqdGRqTkI4dz09?=
X-Exchange-RoutingPolicyChecked:
	nPPvl2TLjsJb81E5M+fPcqscphimuHbBWGbES/hvGzZ1ljUNZA7mkOEObqESPxxeNTYWeF9XAzQJIcYoQEzmO6sPpoabLbdKfAK2YuZE65mWMkwUpkhe+Hl+ObkXX8bc7L2kFaF49K49EVpvamsvBNYbOJfT3oemXWLxQ5M34/o57ghpERLJkUzh2MLPK+oEsPO5QjXbgpHRTHTWUjCQmHvzo5XFkNrWZ0ngd4ALBxVsk5aF8zJ3p1enG11r5Eu5zvA5aAkcrw2IQvAvV2SoUSYPRGGHxmw9DpWQE+/92xOhSXIG+u1Hc41/SocE9JIA8lTLV9xsLKFijTS1ZypIlw==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	WZGJ3XZP2HtT9XiWiHCLMkhaqwvGXO/IRretTw66IuERUQd0ZLpdtEbzHgzV5jnOP4Swz8LlgnLmcn3sDlPJ9OejG0bj9Spsl6F/TehxiB9qIv4S5Dd6Bi+PJcf850MYcfIYoOesmQEwmzlJK0UxcygQ7af0+Ouyuclq4W5JUdKiLPHQ1PAvixEei9t2GukyGiZKzo8NVqU5uFEU4IPrC8mQts1xX0rcasvaG42ROrhNS0IJgzeBFx0ZpuP8Nsfz4xthNunXhRQWvY8MML2nLRjldxbR6Fc+KwaW21jD6nloi1ZEYWmQu05NOmgHI/PSOW0+a4v1A6KultTxL39JOog3icK08mZEsn1t2IfcBEuwNWntNG6aAw9oHSorTqz/ymyBlT76rQzXXE+6EuB4drW9nxZ3H1kd2eMWUZ0BnEo7ILJ4jIBI5+gUEtP2Le2lU0nOTpgg3se1D0HYAlwVLK/bvY6NYl6Ue9wA9UyBQhUBrtQwbwi5J0oF4VOHqMX8rZxI+kChko4K+JQvxADzE3rfMHQ67ihyYK0gYxtigcfFdzlkb+II1dEvmXA4IeJfIU/I4lHX7bG2GcZqpHE7KvxVK8/v4UPv8nciTH7DwbY=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8fdca74e-4c30-4f12-7c7a-08df038d4b5b
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB5506.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 16:15:50.0748
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tJ1CcUO2ZwseAwzuVNSdL0VHzniH7iCey94xIL4TsZXSe/VvHhXzXfrWbKqLpb0bbHOlXIYew3y9Zu12eSFQRA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR10MB997596
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-26_04,2026-08-26_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0
 bulkscore=0 malwarescore=0 suspectscore=0 adultscore=0 mlxlogscore=999
 spamscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2606160000 definitions=main-2608260135
X-Authority-Analysis: v=2.4 cv=D+h37PRj c=1 sm=1 tr=0 ts=6a8f113c cx=c_pps
 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10
 a=Sv0fKeRqtYgA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=jiCTI4zE5U7BLdzWsZGv:22 a=3I1J8UUJPc9JN9BFgKH3:22 a=p0WdMEafAAAA:8
 a=20KFwNOVAAAA:8 a=qYsLzjvYBfPyXXnyIu4A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI2MDEzNSBTYWx0ZWRfX5dCmTLm/Be4P
 OPr6WfIVh7vXU7Ap9h2RE6A4iTzMxzmi4pzZtnw8SFkqWsjVzN+QjODZZ49UlIgnAyYBKKr4EU2
 8i+eGC/uetvMUHH6WTxoM52MdPNTVzdRSMy20D95jFrVdTU3w7S7
X-Proofpoint-ORIG-GUID: aNDFm8w0a05hj3U6IyaBU7ioYmWHrVxq
X-Proofpoint-GUID: aNDFm8w0a05hj3U6IyaBU7ioYmWHrVxq
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI2MDEzNSBTYWx0ZWRfXycupZ1cz3UD5
 GW1Mfwwz99AFVbke+3L4oz+dzvc/kL//LXIz+yzscFABiUAeZKL0dSF0MN5y2j7Wa4H78CcUocy
 7OFRAgXJZYshluFcpfa5GeZWVwgrCf9Ex0WNcocL7qAQPUZsSp2kW8hN81jNb+14ZZWmWkK7eSX
 BzzpqFC04kashfjn1E9ys6J/mHLBuum3beMBNdaBeX9I1GatysvPQfQhtILEeh629ECKP2XNVs6
 YPQuU3yjXvGCOZx4uzIkQDARqO5XY9DlOQ+FbsE9uTi8jZcFp6qrFtCowbXEbAMMDu2owiBfMNB
 kK6vUXi+LEzTu+AFdh6mCDnB+IgDXfJabDnB4qKb0CcC7lP1upa2rEdnUizqML04xC2cDDm5WMj
 +yRnaY7wG3QUetT1QJQURwHqN/OVzF/qTb+FH5geDDHH4e1HdtxL2QwiLpLc9Yv/KoYETKRTu1i
 kgmcdSuWkLwRXg4idog==
X-purgate-ID: tlsNG-33051d/1787760974-75EFF4E9-838A8197/0/0
X-purgate-type: clean
X-purgate-size: 3127



On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrangé wrote:
> On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote:
>> Hot-unplugging a PCI device can require cooperation from the guest. For
>> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest
>> eventually writes the ACPI PCI eject register. For PCIe native hotplug,
>> QEMU notifies the guest through the PCIe hotplug mechanism and waits for
>> the slot unplug flow to complete. Only after that completion does QEMU
>> unrealize the device and emit DEVICE_DELETED.
>> 
>> This can leave a device stuck in the unplug pending state when the guest
>> does not cooperate. Examples include:
>> 
>> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is
>> unavailable.
>> 
>> 2. The guest is stalled and cannot handle the hot-unplug event. For
>> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this
>> for ACPI-based hot-unplug.
>> 
>> 3. The device was attached to a slot that the guest cannot use. For
>> example, a pcie-root-port only supports slot 0. If a device is added to a
>> non-zero slot below a pcie-root-port, the guest may never discover the
>> device and therefore may never complete the unplug request.
>> 
>> The non-zero slot case has also been discussed in:
>> 
>> hw/pci: warn when PCIe device is plugged into non-zero slot of downstream port
>> https://gitlab.com/qemu-project/qemu/-/commit/
> ca92eb5defcf9d1c2106341744a73a03cf26e824
>> 
>> hw/pci: add comment to explain checking for available function 0 in pci hotplug
>> https://gitlab.com/qemu-project/qemu/-/
> commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5
>> 
>> pci: don't skip function 0 occupancy verification for devfn auto assign
>> https://gitlab.com/qemu-project/qemu/-/commit/
> e228d62b4af29bca698ec57efdceb46f392f5444
>> 
>> For example, if root-port.1 is a pcie-root-port, the following command adds
>> a vhost-scsi-pci device to an invalid slot:
>> 
>> (qemu) device_add vhost-scsi-pci,id=scsi01,wwpn=naa.5001405324af0985,bus=root-port.1,addr=01.0
>> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device only allows plugging into slot 0.
> 
> This rather looks like it should be a fatal error, not a mere warning.
> 
> If I follow the commit ca92eb5def it links to https://bugzilla.redhat.com/show_bug.cgi?id=2128929
> which states that this configuration is going to lead to a crash in
> QEMU on guest OS shutdown. IMHO that crash is sufficient to justify
> making this a fatal error.
> 
> If we actually wanted this to remain a warning, then that shutdown
> crash would need to be fixed.
> 

Thank you very much!

I see that the issue has been fixed. The ticket mentions the following.

"What I am observing is that it seems when the slot ID != 0, the guest OS seems
to ignore this and we never seem to hit ich9_pm_device_unplug_cb()."

Based on my experience and evaluation, ACPI-based hotplug is more likely to
encounter an issue where the guest VM does not respond to an unplug operation.

Thank you very much!

Dongli Zhang



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 16:48:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 16:48:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400053.1635984 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzGnq-0008Jp-Ht; Wed, 26 Aug 2026 16:48:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400053.1635984; Wed, 26 Aug 2026 16:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzGnq-0008Ji-F5; Wed, 26 Aug 2026 16:48:42 +0000
Received: by outflank-mailman (input) for mailman id 1400053;
 Wed, 26 Aug 2026 16:48:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <olekstysh@gmail.com>) id 1wzGno-0008Jc-S2
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 16:48:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzGno-00ChQL-8S
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 18:48:40 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <olekstysh@gmail.com>)
 id 6a8f18d1-8faa-0a2a0a5109dd-0a2a45098cc4-8
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 18:48:40 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <olekstysh@gmail.com>)
 id 6a8f18e8-be1a-0a2a45090019-d155dd2de0c1-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 18:48:40 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f3b39f2a1so923113f8f.2
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 09:48:40 -0700 (PDT)
Received: from [10.17.80.122] (ll-22.209.223.85.sovam.net.ua. [85.223.209.22])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e2756112sm3487300f8f.0.2026.08.26.09.48.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 09:48:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787762920; x=1788367720; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=NgE/O1AZRzshLUk9BL0AEIhrigcYhGm+DM3i7xBTKOQ=;
        b=Nw6s9rRkmrYfLIQm1wXBNxFydGi5z2RIbCsYMFOkMSeLObhY+e+3R8EhepGo8XYz7e
         eMsIHKafqK09jYqgI+lPvUW5cplXlAWaIyow5vWlzGqlyMB3piDthAmTFMWWwU5+y5kf
         En3b7bxOugHCXx8Eu0thBjqO/i7TtMzMETz6kCogTQ4t+BhwWrUBhvDw1Q5iC1clP2ot
         o7efg5dDIrU6WekLb3616qwwN4VOFyD38YKreKqkGrPWi4f+HQaC8FjdrCeuNnctoBuU
         WG9SKSdeoMq8lEPeIwtB9OYS9lRaTFXcHjVsY3FAfCF9mR9Yg0Nv+zQIdEwWb2kz8bCK
         m93Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787762920; x=1788367720;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=NgE/O1AZRzshLUk9BL0AEIhrigcYhGm+DM3i7xBTKOQ=;
        b=Yuu0ANgvNYbfiywqdN+JXA/0Zd7fCFsD4UW2tSgVDMOd8W56wxBdqxH5lNGdDEN/ZW
         HlofbCrrK+YsFF51b1aEDYSQs+DueLuOg6LD/V1c3e9X2Ed9dzHyL0XfYjMeCBI7LM73
         EdYAq0aPSd7HmthrGSjGRt+eef76ifO11JTfIcUR5kSyLNHKdvFb+1qJNqwW87zKy3hC
         Lnrq1EM0Gp6CCrvLqr2OCYlqysH3CHqH5rSOlrssQ3Wx9myvE8wfMoYEFwLYUhvt54rg
         ZB/g3sJWkDmrPUn7T8oBzIJ1nzIcsqujhsALGhBX8cwHqNiLfr/SfiY+P3i9UlMU4VBr
         snWw==
X-Forwarded-Encrypted: i=1; AHgh+RpA05NquZHjPdPfBQRU2JW6vgpAXEJrvzBEPjqukWcgT82rG7mZ6flSFAUDGWdNFvNdEBdNYM2GAmU=@lists.xenproject.org
X-Gm-Message-State: AFuF++nt00e3a6Hcjr++d7sAywfhoxeWR5pno5sHXYlFWpuVoYdv9UCT
	pIs9CQGjkcYejW6QbLeqrYg6RTXksmVsBQhnV4hOiaStifaO7epVCOuz
X-Gm-Gg: AR+sD106dnjZN29i3wmijZiiQ3kLIRtgfHhtmzKMrxVtZ1/E9mxGODlbt1pRIPUXny1
	IPCEHUVEOH11vCmInH5xV9O1anfiTA/5ZTbCJXzNFoXHjwKyGRi2NdhkVhQDpmCLn02ZBP1QEQG
	+jMhsWEVezfrqoyYVWKqPuD8rpnOmcKhnVMgpWQIFxHbWauuE+T/Owju2149mkCrT1xq3GlyVVA
	sCXMyua4O1V091IILwbs3hHJaqn5LTUUDHr8qSSj3CCPBQhNQlJZiN82ChTpu+y7ayQRckEZvaI
	HDTGfR1Ttgk5GL7uQSFpeFk0EnlfOyBS+MqFESDy19y+XatRYE7mQPBxfxMFq5feqU0QB3S/wWz
	xqR05l60YgkTPa5rd3ZDRpWIQ+NO3LKcDYE5AMg4I+spjqCtBLpvChEgAdj38klZgLoszLitBF9
	P6uFPSWAsJWNx2yRNYN1EfjW1S5Ihtw/KN0pwP/oXuSypLjlkyM7TQ72LGxhu90mk/RK/h1LkDW
	YvqT5ozMORAo1rL3OF+J09j++LTa5A=
X-Received: by 2002:a05:6000:2f89:b0:47f:d011:f644 with SMTP id ffacd0b85a97d-482e26963f8mr9485572f8f.4.1787762919527;
        Wed, 26 Aug 2026 09:48:39 -0700 (PDT)
Message-ID: <621ee1f0-1ccf-4e6c-909b-4c0ebf594bf0@gmail.com>
Date: Wed, 26 Aug 2026 19:48:37 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen/arm: traps: drop unreachable stage 2 decoding
 from panic_PAR()
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260825062329.16762-1-michal.orzel@amd.com>
 <20260825062329.16762-3-michal.orzel@amd.com>
Content-Language: en-US
From: Oleksandr Tyshchenko <olekstysh@gmail.com>
In-Reply-To: <20260825062329.16762-3-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-bad1c0/1787762920-3BED6034-517480DE/0/0
X-purgate-type: clean
X-purgate-size: 2811



On 8/25/26 09:23, Michal Orzel wrote:

Hello Michal

> panic_PAR() is only called from va_to_par(), which translates using
> __va_to_par(), i.e. "at s1e2r" on arm64 and ATS1HR on arm32. Both
> perform an EL2 stage 1 only translation, so PAR.S (PAR_STAGE2) and
> PAR.PTW (PAR_STAGE21) can never be set.
> 
> This has been the case since commit a14447dbcf171 ("xen: arm: do not
> panic when failing to translate a guest address"), which made
> gva_to_par() and gva_to_ipa() return -EFAULT instead of calling
> panic_PAR() for guest translations.
> 
> Print stage 1 unconditionally and keep an ASSERT() to document the
> invariant. PAR_STAGE21 has no user left, so drop it. While at it, fix
> the spacing in the decode_fsc() call.
> 
> No functional change intended.
> 
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>


> ---
>   xen/arch/arm/include/asm/processor.h |  1 -
>   xen/arch/arm/traps.c                 | 17 +++++++++--------
>   2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
> index 509040a1cdc0..8ee8f88fb4cb 100644
> --- a/xen/arch/arm/include/asm/processor.h
> +++ b/xen/arch/arm/include/asm/processor.h
> @@ -507,7 +507,6 @@ extern register_t __cpu_logical_map[];
>   /* .... If F == 1 */
>   #define PAR_FSC_SHIFT   (1)
>   #define PAR_FSC_MASK    (_AC(0x3f,U)<<PAR_FSC_SHIFT)
> -#define PAR_STAGE21     (_AC(1,U)<<8)     /* Stage 2 Fault During Stage 1 Walk */
>   #define PAR_STAGE2      (_AC(1,U)<<9)     /* Stage 2 Fault */
>   
>   /* If F == 0 */
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index dc0ec8a345ed..1c2bdb7d02c7 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -382,16 +382,17 @@ void panic_PAR(uint64_t par)
>   {
>       const char *msg;
>       int level = -1;
> -    int stage = par & PAR_STAGE2 ? 2 : 1;
> -    int second_in_first = !!(par & PAR_STAGE21);
>   
> -    msg = decode_fsc( (par&PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
> +    /*
> +     * The only caller translates using "at s1e2r" (arm64) or ATS1HR
> +     * (arm32), i.e. an EL2 stage 1 only translation.
> +     */
> +    ASSERT(!(par & PAR_STAGE2));
> +
> +    msg = decode_fsc((par & PAR_FSC_MASK) >> PAR_FSC_SHIFT, &level);
>   
> -    printk("PAR: %016"PRIx64": %s stage %d%s%s\n",
> -           par, msg,
> -           stage,
> -           second_in_first ? " during second stage lookup" : "",
> -           fsc_level_str(level));
> +    printk("PAR: %016"PRIx64": %s stage 1%s\n",
> +           par, msg, fsc_level_str(level));
>   
>       panic("Error during Hypervisor-to-physical address translation\n");
>   }



From xen-devel-bounces@lists.xenproject.org Wed Aug 26 17:02:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 17:02:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400061.1635992 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzH1P-0002e2-Jl; Wed, 26 Aug 2026 17:02:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400061.1635992; Wed, 26 Aug 2026 17:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzH1P-0002dv-H2; Wed, 26 Aug 2026 17:02:43 +0000
Received: by outflank-mailman (input) for mailman id 1400061;
 Wed, 26 Aug 2026 17:02:41 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wzH1N-0002dp-Al
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 17:02:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzH1M-001lj4-7m
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 19:02:40 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8f1c28-8faa-0a2a0a5109dd-0a2a45018662-14
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 19:02:40 +0200
Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8f1c2c-5984-0a2a45010019-a0658309d7f6-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 19:02:36 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id ADA0D83646FA;
 Wed, 26 Aug 2026 13:00:36 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech
Subject: Re: Re: [PATCH v1] x86/nSVM: Expose the FlushByASID CPU Capability to L1 guests
Date: Wed, 26 Aug 2026 17:58:10 +0100
Message-ID: <20260826165819.2990238-1-abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <73e2a6fd-8cd9-4dc1-9a83-e48baec6c13e@suse.com>
References: <73e2a6fd-8cd9-4dc1-9a83-e48baec6c13e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787763757-C5341757-70C8D2AA/0/0
X-purgate-type: clean
X-purgate-size: 2181

On 13.08.2026 17:29, Jan Beulich wrote:
>On 13.08.2026 16:56, Abdelkareem Abdelsaamad wrote:
>> On the AMD platforms, the Xen hypervisor requires the FlushByASID CPU
>> capability to support HVM nested virtualization (see start_nested_svm).
>> Consequently, the L1 hypervisor must report FlushByASID CPU capability support
>> when intercepting CPUID instruction for the CPU feature from the L2 guest to
>> support nested virtualization levels beyond L1. Extend the exposed HVM CPU
>> policy to surface this CPU feature support for the guests.
>
>While the change makes sense, I have to admit that I consider it a stretch
>to justify changes by multi-level nesting, when a single level of nesting
>is in need of a lot of work to actually behave sensibly. Further, "to
>support nested virtualization levels beyond L1" looks pretty Xen-centric:
>Other hypervisors may permit this without the feature.
I believe the change is actually necessary for the single-level nesting
support. Xen was meant only as an example of an L1 hypervisor requiring this
feature from L0; VMware has the same requirement (see Launchpad Bug #2008583).
I will update the commit message in v2 to clarify this and remove the
Xen-centric phrasing. Just to ensure we are aligned—did you have any concerns
that exposing this feature can cause incorrect behavior?
>
>> While at it remove the dangling `exitinfo1 = ns_vmcb->exitinfo1;` assignment
>> inside the nested exit handling of svm_vmexit_handler().
>
>Unrelated adjustments to somewhat nearby or related code are generally
>okay, but here you're touching a different file and entirely unrelated
>code. I think the two changes want splitting.
I agree. I will drop in v2. I just came across it while verifying the VMExit
for the CPUID intercept is properly injected into the L2.
>
>And the CPUID test that XTF has wasn't suitable?
I tried with the CPUID test from the XTF, it does require nestedhvm=1 in the
configuration but it gave the same results. I will update the testing
section accordingly in v2.
>Finally: Can you please drop Roger's old email address that you still
>had on Cc?
I will correct it.
>
>Jan




From xen-devel-bounces@lists.xenproject.org Wed Aug 26 17:55:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 17:55:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400120.1636004 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzHqN-00016b-Gg; Wed, 26 Aug 2026 17:55:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400120.1636004; Wed, 26 Aug 2026 17:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzHqN-00016U-E0; Wed, 26 Aug 2026 17:55:23 +0000
Received: by outflank-mailman (input) for mailman id 1400120;
 Wed, 26 Aug 2026 17:55:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <philmd@oss.qualcomm.com>) id 1wzHqM-00016O-IZ
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 17:55:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzHqL-00DzpF-Vg
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 19:55:21 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a8f2828-8faa-0a2a0a5109dd-0a2a450c9236-36
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 19:55:21 +0200
Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a8f2888-f479-0a2a450c0019-cddcb4837060-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 19:55:21 +0200
Received: from pps.filterd (m0279868.ppops.net [127.0.0.1])
 by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67QGunot1310536
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 17:55:19 GMT
Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com
 [209.85.160.197])
 by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ga03a9baw-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 17:55:19 +0000 (GMT)
Received: by mail-qt1-f197.google.com with SMTP id
 d75a77b69052e-52dcf1bb6e9so1325661cf.1
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 10:55:19 -0700 (PDT)
Received: from [10.254.188.74] (134.171.88.92.rev.sfr.net. [92.88.171.134])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c250a5d68desm904935366b.10.2026.08.26.10.55.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 10:55:17 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:Cc:To:Content-Language:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=
	cc:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=
	N+D1dHFIktfWOUtW20rGGierHYR2ew9U5aCa22Ma8B4=; b=Db3Eh64G3/1/dhQn
	DGnNMwGUw6E20COHcfPjREIbO0WCBuMQ20pD14QvxB8bbou1xfVbX9BlGu3wOFYP
	FRT7jMdhj75M8tTK885ZyOxbaX4qEXA5QK0zMnPI0rPR+SUbfTU2gpbxqs0XMLjx
	xln4+6f+QYWgqFxPXSJEcL8d8i7fB4Oup/klvteOPgX79tfqUh1PvwTqKnLr7qz2
	jIXRNoQVR9Y9L+i9bJEyjm0oeVLIqiajd792ktPc93nTcolPEFJUk5rMcueovmDq
	bprCweF47sdBWlGGdWYRg70akn+BPGbqhnVKdE0FOZr4CyC5N5ShjHK5eKPYlK3/
	DdUINA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=oss.qualcomm.com; s=google; t=1787766918; x=1788371718; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=N+D1dHFIktfWOUtW20rGGierHYR2ew9U5aCa22Ma8B4=;
        b=OS56Yv24ws21trScgrxw0MzlypLzWPSXmHolfB86nL4fXO6R30RWuPY+AlB/SeEXjt
         MC1DVEyMP4RrwQSGAgjntxNAIlqT5mshZ02c5POg8pQBEd3zkc77cJDDJFGd2aSA/8yc
         EGCwiqZjSfLsDMqyFvdyBptOP9ZI52aDOQbkkeHvrBK4cZzUmPKKkad1PeRw6SLNwzU6
         ZfSXn5NpfwJ7Yd3fxRhWVSOUkDFEUjaybtNMiU9cTCX4tkNSt1cvSbFDUeI1ailVIq8y
         1d7kkjO/Uw0HBnICDhm5SgZ7tCvCXKHAYOSHr2poFb4xH3OO6TnhlJLuSv4CBZp8RFxt
         hn6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787766918; x=1788371718;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=N+D1dHFIktfWOUtW20rGGierHYR2ew9U5aCa22Ma8B4=;
        b=otvaNa/79v/zDO92vvkUtTZEF5mqTk5sV1yRsrM3TUQ/wxHNwyQvK6ZRmXUHbe5w1t
         mw4886K1JSbLl1zlPWGrVsOLCSarNVR4Txn2c32EW8NyMcCu9yqVuFtymkKEC43+0mp5
         sRedBAHxroHHqDoAJb8yuXqPnsFxHPaoOVjuXgmTNuoSOJ3iOiTrxE7Gnuh4X+aKOCAl
         bLXb/g02sxNvAfjyuBJUR1FPxKT1/vvyD5aXiwwYAgLsYxqpZMOMMA5mhb9SOdOSh/dv
         adKdygVSyJWBdTPIso33Ih3x16cPkh8/oVLkgafbTqs8Db5zXSaEv1f7xYOGXDjyG27v
         Heug==
X-Forwarded-Encrypted: i=1; AHgh+RpGO3CGY1StcLLJpmFgvANWyFS/EWB7TLEc6FcLXOH2nB2Ov9VqtdcoDbtrLdMUqSDJYwCw6GaS/no=@lists.xenproject.org
X-Gm-Message-State: AFuF++lXsKn0hww27MTHlSeHiWTuqthYNxF/xEkY/2PA+3/EDGqldJpf
	pT+j2siuYPWRu20gsIib+J34uETkf+5OjsSBkQbQPoHdOswSUJ8OwTfvVuqag2w3ZAh6NpK5k+P
	z/OfDOd8JlLzsd1IhW58s7H3RlPsJgNriRhXV3JtPnMkf5lfSwsLDQ6UTd6PxZNetrPkxxg==
X-Gm-Gg: AR+sD12PzJ/jFQSjxFUmpeIIkTgtG+RqjXnhckwLXAKe+x8E+C0YffqVfW6NvT4tdPK
	4yT6t3ByVLkDfC/JBjGoiQUZCMOQXOX9qg9uyGacQcP21VR2MPQ05sbYbH/1+ydbR4eTBZyl69E
	69llGH3B5meFuwQ5yvoWnQAsJLyBfiWCDHg5tt6AuXKpdjRLtnvuipdSq2D9r3sB76SSckmU8eg
	CZsdmZWDJthI611SUecuOHi+3a4FnapzV52cUCvAqLQM0amwQEjuhBWWXbAS4ygg7XoDXNWDSuc
	QO/WERyR87AiuB4MaQtk+w4QXXK/l4ANx6G7h1mXtSNgntOzh+cMgXP3SyIy3I5kdF6F7ILaS4q
	I7h/q4RAYGvIYCIm6GZaOIEL9Gox4ulxvB7WvI8YYUFE=
X-Received: by 2002:a05:622a:2d3:b0:517:6fc2:4760 with SMTP id d75a77b69052e-52fa1a9aa93mr10470891cf.9.1787766918514;
        Wed, 26 Aug 2026 10:55:18 -0700 (PDT)
X-Received: by 2002:a05:622a:2d3:b0:517:6fc2:4760 with SMTP id d75a77b69052e-52fa1a9aa93mr10470361cf.9.1787766917986;
        Wed, 26 Aug 2026 10:55:17 -0700 (PDT)
Message-ID: <a75ef05f-9357-44ee-91cc-811375bfd300@oss.qualcomm.com>
Date: Wed, 26 Aug 2026 19:55:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 29/49] monitor: isolate HMP declarations in hmp.h
Content-Language: en-US
To: =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>,
        qemu-devel@nongnu.org
Cc: dave@treblig.org,
        =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?=
 <philmd@mailo.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 <berrange@redhat.com>,
        Markus Armbruster <armbru@redhat.com>,
        Richard Henderson <richard.henderson@linaro.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
        Brian Cain <brian.cain@oss.qualcomm.com>,
        Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Anthony PERARD <anthony@xenproject.org>,
        "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
        Samuel Thibault <samuel.thibault@ens-lyon.org>,
        Jason Wang <jasowangio@gmail.com>,
        Yoshinori Sato
 <yoshinori.sato@nifty.com>,
        Stefan Hajnoczi <stefanha@redhat.com>, xen-devel@lists.xenproject.org
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-29-af60857c2fbe@redhat.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>
In-Reply-To: <20260825-qemu-no-hmp-v4-29-af60857c2fbe@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Proofpoint-GUID: BlPYHATXis8_vFwB6ZXg1S3qRqIQi7ak
X-Authority-Analysis: v=2.4 cv=VdLH+lp9 c=1 sm=1 tr=0 ts=6a8f2887 cx=c_pps
 a=EVbN6Ke/fEF3bsl7X48z0g==:117 a=o1isufRNksZXpKP+aqnsag==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22
 a=3WJfbomfAAAA:8 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=PA9M43id2i3nLZc8FP0A:9
 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=a_PwQJl-kcHnX1M80qC6:22
 a=1cNuO-ABBywtgFSQhe9S:22
X-Proofpoint-ORIG-GUID: BlPYHATXis8_vFwB6ZXg1S3qRqIQi7ak
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI2MDE0OSBTYWx0ZWRfX3HyPVQKDGaSC
 3vEEh6s5q2IEPTA/af1vHH97jUSuGzs8d7u8WlOUsSvSu2V9dwrFPExrPBe9qGXqLSwZ64SpDjV
 oFcL+rVqw5bxpcHYsNojmY2g19lYFKDT2dCzaTX0ZXIt/2wmheZDjDkC5pCakZCk+lr1Yr6rhEn
 uVhxi6vNhhriIc5hxxWgT/G5o5jEKh0c8qCwD6JHKdM9KrhJe7ZLsdW0FFP5AhejLwtAn1uBDIR
 xLR+ZDGw9XGzecpwz65fQ0T/6Tg+HXx1ofPL22mmYhgHBf5V+1l003jNz8P1EoZ/XCHuKlotKnt
 CsFkQWOWsMRffYtR3VsQ6bDC0eXj4LT5IgN5I3I/fUzJkjHuhfu5qP9vKbpNzMA1lx6vFPlvR/Y
 P5aFVoD3YCH3QvyS6cOqCl6/OJOp+NoWLwYPKJPRyKuKRD5Me414nRM5jSprxmkWXDfEcwctUPu
 o3sbKMiiWKC7tXPE9sg==
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI2MDE0OSBTYWx0ZWRfX2OTmx/nuMxqV
 wagQtn5BcPsQG0Vkrk6g4S74iNErGBOi0gs+aTgod7RW80L8QXNdCyUNRacyng7hkSuKdCY2XnO
 i5/V4buDS2HBYGMKC3M1Tu2YyzI17CI=
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-26_05,2026-08-26_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 clxscore=1015 impostorscore=0 lowpriorityscore=0 bulkscore=0
 priorityscore=1501 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0
 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc=
 route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000
 definitions=main-2608260149
X-purgate-ID: tlsNG-d25034/1787766921-50321A5B-ED4475C0/0/0
X-purgate-type: clean
X-purgate-size: 1660

On 25/8/26 21:09, Marc-André Lureau wrote:
> Also rename password & commands with hmp in the name, while at it.
> Other functions need larger changes which we will take care of next.
> 
> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>   accel/accel-system.c           |  1 +
>   accel/tcg/monitor.c            |  1 +
>   chardev/char.c                 |  2 +-
>   disas/disas-mon.c              |  1 +
>   gdbstub/system.c               |  2 +-
>   hw/char/virtio-serial-bus.c    |  1 +
>   hw/core/machine-hmp-cmds.c     |  1 -
>   hw/core/sysbus.c               |  1 +
>   hw/hexagon/hexagon_tlb.c       |  1 +
>   hw/misc/auxbus.c               |  1 +
>   hw/usb/bus.c                   |  1 +
>   hw/usb/host-libusb.c           |  1 +
>   hw/xen/xen-bus.c               |  1 +
>   include/monitor/hmp.h          | 21 +++++++++++++++++++++
>   include/monitor/monitor.h      | 18 ------------------
>   monitor/hmp.c                  |  8 ++++----
>   monitor/monitor-internal.h     |  1 +
>   net/slirp.c                    |  1 +
>   stubs/monitor-core.c           |  1 +
>   stubs/monitor-internal.c       |  2 +-
>   target/rx/disas.c              |  1 +
>   tests/unit/test-util-sockets.c |  1 +
>   tools/qemu-vnc/stubs.c         |  1 +
>   trace/trace-hmp-cmds.c         |  1 -
>   ui/ui-hmp-cmds.c               |  4 ++--
>   util/error-report.c            |  2 +-
>   util/qemu-print.c              |  1 +
>   27 files changed, 48 insertions(+), 30 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>


From xen-devel-bounces@lists.xenproject.org Wed Aug 26 18:14:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Aug 2026 18:14:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400131.1636014 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzI8L-000435-VI; Wed, 26 Aug 2026 18:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400131.1636014; Wed, 26 Aug 2026 18:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzI8L-00042y-SF; Wed, 26 Aug 2026 18:13:57 +0000
Received: by outflank-mailman (input) for mailman id 1400131;
 Wed, 26 Aug 2026 18:13:57 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 1wzI8K-00042s-VZ
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 18:13:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzI8J-008uc1-VY
 for xen-devel@lists.xenproject.org; Wed, 26 Aug 2026 20:13:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8f2ca3-e002-0a2a0a5209dd-0a2a4508d810-34
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 20:13:55 +0200
Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <abdelkareem.abdelsaamad@citrix.com>)
 id 6a8f2ce2-f659-0a2a45080019-a0658308caa2-3
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 20:13:55 +0200
Received: from fedora.eng.citrite.net (unknown [10.113.40.46])
 by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 0A31E4510A2F;
 Wed, 26 Aug 2026 14:12:05 -0400 (EDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
From: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
To: xen-devel@lists.xenproject.org,
	jbeulich@suse.com
Cc: andrew.cooper3@citrix.com,
	roger@xenproject.org,
	jason.andryuk@amd.com,
	teddy.astie@vates.tech,
	Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Subject: [PATCH v2] x86/nSVM: Expose the FlushByASID CPU feature support to L1 guests
Date: Wed, 26 Aug 2026 19:09:37 +0100
Message-ID: <616bf3633e902f2fdba5d00691653d3bb82444ce.1787765809.git.abdelkareem.abdelsaamad@citrix.com>
X-Mailer: git-send-email 2.53.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787768035-DF6D687B-3BC6A441/0/0
X-purgate-type: clean
X-purgate-size: 2354

Some hypervisors explicitly require FlushByASID capability to function under
nested virtualization; otherwise, they fail to boot or run nested guests, see
see Xen's start_nested_svm and (1) and (2). To ensure functional nested
virtualization support and allow L1 hypervisors to correctly detect this
hardware capability, extend the exposed HVM CPU policy to surface the
FlushByASID CPU feature to the L1 guests when nestedhvm is enabled.

(1) VMWare (Launchpad Bug #2008583) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2008583
(2) https://lore.kernel.org/all/b9915c9c-4cf6-051a-2d91-44cc6380f455@proxmox.com/T/#u

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Changes in V2:
- Commit Message: Rephrased to clearly state that exposing this flag is a
  functional dependency for some hypervisors and hence for nested
  virtualization support.
- Code Cleanup: Dropped the unrelated change that removed the dangling 
  'exitinfo1 = ns_vmcb->exitinfo1;' assignment inside svm_vmexit_handler().
- Testing: Updated the testing notes to the successful validation using the XTF
  CPUID test.
---
Testing:
 - Using XTF CPUID test with nestedhvm=1
   - without the change, EDX returns 0x4AB (the FlushByASID 6th bit is not
     set).
     8000000a:ffffffff -> 00000001:00008000:00000000:000004ab
   - with the change, EDX returns 0x4EB (the FlushByASID 6th bit is set).
     8000000a:ffffffff -> 00000001:00008000:00000000:000004eb
 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2793662718
---
 xen/arch/x86/cpu-policy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index eddcd9778f..48a3185eed 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -843,6 +843,7 @@ static void __init calculate_hvm_max_policy(void)
         p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
                                (1u << SVM_FEATURE_LBRV) |
                                (1u << SVM_FEATURE_NRIPS) |
+                               (1u << SVM_FEATURE_FLUSHBYASID) |
                                (1u << SVM_FEATURE_PAUSEFILTER) |
                                (1u << SVM_FEATURE_DECODEASSISTS));
         /* Enable features which are always emulated. */
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 05:52:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 05:52:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400311.1636023 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzT2T-0005qZ-KX; Thu, 27 Aug 2026 05:52:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400311.1636023; Thu, 27 Aug 2026 05:52:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzT2T-0005qR-FY; Thu, 27 Aug 2026 05:52:37 +0000
Received: by outflank-mailman (input) for mailman id 1400311;
 Thu, 27 Aug 2026 05:52:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzT2S-0005qL-RR
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 05:52:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzT2S-0033bH-4l
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 07:52:36 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8fd08e-e002-0a2a0a5209dd-0a2a45049ae2-24
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 07:52:35 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a8fd0a3-b57f-0a2a45040019-d155dd33ccf0-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 07:52:35 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47f633e6058so1266302f8f.0
 for <xen-devel@lists.xenproject.org>; Wed, 26 Aug 2026 22:52:35 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28dc0d6sm6758168f8f.18.2026.08.26.22.52.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 26 Aug 2026 22:52:34 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787809955; x=1788414755; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=YO1u/fRL+aimoEXPc0EgFEsF7jAcrCcNsZWgq1BcbkU=;
        b=FTxZl43sA72+QktW4Uoq5lmhgsWj2PMnS2JILOcevpV9FOQ6O/J5XApkwKg7w6h4UY
         7KG4jT0CdkVQMdu9Op5lod5In5eLM58AkQS599unIh8XJzdb2YMTgoRZleBSxk9hfMXz
         mJ37ciy7YtWWPIf4A9lJJDQKchJe6GF0F+I+ZQmByAjzTnQzDHkupmmNpNAISkK2uEMP
         7Yb3ocNsBJ6BvV00SGHlv7HIDSN71m89RRu3C1DA79APTJF+kIdnXr1spEQON+ixjPfL
         e3BM/i11xqIJVDFGdP9XSFpYL6x7n1bee00mjE2htEgdANlw91mVTE0KDZNbmFa4JF1R
         mlHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787809955; x=1788414755;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=YO1u/fRL+aimoEXPc0EgFEsF7jAcrCcNsZWgq1BcbkU=;
        b=WTwEH/qo+oTZat0nJlJnw30LIfxppKXBvt8+i3/91/LOakX9A+srfol4bh/60ZBNgl
         jBvNhNj8+kEY7lm6uPbm2sR1jtTHHsBPMVXIEA7JxcbLYZmFCUsHNd79r5mnzv9/HfW0
         FhjW4e3iv+xupiBJdSdNApXlbjc7VqCo1bxbVWbMCftiiHAa6LVo1hriz9hL0WyHz06F
         B8N1bxU2me1fMAlkcIdhEBAeHQtggjAOQTMUIg6gNrpprIs4HhCQLiNww+FiY83CEb2g
         kJG5NG//YYk3v0JHShsxuxicSFYVx2OHwJ9KtC3Iiqk5GfmTgQEVnVMCVRj1isvbuc0/
         jtNw==
X-Forwarded-Encrypted: i=1; AHgh+RrcNydnIcWJpZI8HKI4X2WU21SLRcK/YyLLUBggGPL5phkCDP91BVhHi2zofY8eknwu4b5hP1dTcpY=@lists.xenproject.org
X-Gm-Message-State: AFuF++n1Wtw8vfxnvrL3VY0Wdj20L8ZCQ4pp1YoJ5Vw/UWKs/nm8KTXY
	Pxve8JHFRzhCEQUJal4/LLk9/Ye+CMrJzAGoUtQPqR2f2TKvfZERwgPNdcAbgdB/8SnPKC+ecCe
	4Q3QL1A==
X-Gm-Gg: AR+sD11t3dANLoyApzOyGe3ppzoiQ5YyNFkN+WN2nflwTDVMpsW0frhw1MS+IWaqDK8
	mR7RiEKtHFoHV72f+dQWPxMiKhX4ySxbQePGyaRxy7DQ9Z78KKPK0zpWYxQ/k+6M8iuy+877R7o
	blB9QszFhVAysRQSYdBe8h7im9Dd+Bhn2kgwvW1QssbvGHi/sQjSCe8XZB+buesqnoEFs+FEA4n
	y0IRR9MMexwQydJasVkZ2J762Qnvl7mrvmIEs/rW9I/Ic1tAbw7nMj2EXyMJl0ja6OsJ4rD6sia
	axahPG8arEr5QBi/Jmd4h8udmGZjIMI7M4xxe2W6fEMZBq78V3YuKsLHk1tZJJJJNvk1Pwr7npz
	qaMJCE2DatzK+hf2SAtOAuzxapgPr9AqsfjZNfMBOXblfX387emAqqmUsqbPc3xKa5t45TxuyuE
	m0M4o1z42dUEOAMuxjUyu8wJhKxhqSWMUyG44Uy3DBTo+QDUgLgfVtMrEI4/3vX6NYytl5jiZXL
	7Cm1LCHuFFGP+/R8nhMYW7OcZMx5RJKs7M/pfgsK1vNHNBaqkbf
X-Received: by 2002:a05:6000:2503:b0:482:984d:fdd2 with SMTP id ffacd0b85a97d-482e26f8247mr14373236f8f.20.1787809955308;
        Wed, 26 Aug 2026 22:52:35 -0700 (PDT)
Message-ID: <57c498a4-863e-48c7-815d-3c70b1432d33@suse.com>
Date: Thu, 27 Aug 2026 07:52:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] x86/nSVM: Expose the FlushByASID CPU feature support
 to L1 guests
To: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com,
 teddy.astie@vates.tech, xen-devel@lists.xenproject.org
References: <616bf3633e902f2fdba5d00691653d3bb82444ce.1787765809.git.abdelkareem.abdelsaamad@citrix.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <616bf3633e902f2fdba5d00691653d3bb82444ce.1787765809.git.abdelkareem.abdelsaamad@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787809955-534C3B50-D3416492/0/0
X-purgate-type: clean
X-purgate-size: 931

On 26.08.2026 20:09, Abdelkareem Abdelsaamad wrote:
> Some hypervisors explicitly require FlushByASID capability to function under
> nested virtualization; otherwise, they fail to boot or run nested guests, see
> see Xen's start_nested_svm and (1) and (2). To ensure functional nested
> virtualization support and allow L1 hypervisors to correctly detect this
> hardware capability, extend the exposed HVM CPU policy to surface the
> FlushByASID CPU feature to the L1 guests when nestedhvm is enabled.
> 
> (1) VMWare (Launchpad Bug #2008583) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2008583
> (2) https://lore.kernel.org/all/b9915c9c-4cf6-051a-2d91-44cc6380f455@proxmox.com/T/#u
> 
> Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

For the future: Please send patches To: just the list, with maintainers
uniformly on Cc:.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 08:06:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 08:06:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400378.1636044 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzV7y-0006W7-5a; Thu, 27 Aug 2026 08:06:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400378.1636044; Thu, 27 Aug 2026 08:06:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzV7y-0006W0-2K; Thu, 27 Aug 2026 08:06:26 +0000
Received: by outflank-mailman (input) for mailman id 1400378;
 Thu, 27 Aug 2026 08:06:24 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wzV7v-0006Vu-PH
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 08:06:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzV7u-008Gtc-O6
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 10:06:22 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8feffb-e002-0a2a0a5209dd-0a2a4507e91c-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 10:06:22 +0200
Received: from [40.93.201.22]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8feffc-b4ea-0a2a45070019-285dc9162bc8-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 10:06:22 +0200
Received: from PH8PR21CA0020.namprd21.prod.outlook.com (2603:10b6:510:2ce::27)
 by LV9PR12MB9781.namprd12.prod.outlook.com (2603:10b6:408:2f6::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.8; Thu, 27 Aug
 2026 08:06:16 +0000
Received: from CY4PEPF0000EE3E.namprd03.prod.outlook.com
 (2603:10b6:510:2ce:cafe::7) by PH8PR21CA0020.outlook.office365.com
 (2603:10b6:510:2ce::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 27
 Aug 2026 08:06:16 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000EE3E.mail.protection.outlook.com (10.167.242.16) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Thu, 27 Aug 2026 08:06:16 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 03:06:15 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 03:06:15 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Thu, 27 Aug 2026 03:06:13 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Im/6bqQxd008rY52RhF4liCZqOu+S40TivLuTvefvemtTKhiwsp1YAEFtlokn1wPtP8aEhw8l3dLPNcTAfFQzNZF3cowzPVWOau6isTBZLs+vJNnCSg4MWdPUiFkVRdGiHultF74t/yb1O0ZtjNSVJ9M38UcKQsvVlj1WGDbPaTad9oCrajmXqZusSjQ55Y4LYpmnwOzWvNoPSrR+aIfbaET7e1zUF1mGwMtUhz4UAb0jBfFTWlQuLPbl36QkMZFEoi7wx31g0cc2VAUcij0J/iUysHywKkpjLMiak8NE7nF1kqJzK/OhuXbJkSiu5o2vyy/o0m/NpSNSw+ve8bljg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZEaxfZAWJIHlSTm8VRYPdw0ibwhWKWp4iBrTrG9GQoo=;
 b=pVk9foKnK4mAv3VgMSg5LKCUjNbuv47YR1TTdkTpNo0B3Ikl7jTcayPTOM2zYcEfCcm7P/h2MDk8r5hrNmkGFK33jczxAtfJ+205j6ule72yCIzcEpB6pX8cH5ZdjxJnhxW7Kd9VxGjx2b89XgBmsoOhJDD8VFIr9myx2YsrljKbzR/0YqhuXsW+NK5BK4KFup1To1MujL0EJ88Ai7oPxXbOKYgt2TzhlGisqNt5BSBw6Yx5uenYlDwWqZ02L/bIiOvFMPuEXEP2T0LDs07rw8oXMRikoEK40C2gf9i+vsZa99ak+fy5hzMBEB8qClTOqMXE39qFgqH58ewF64YZ9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=valinux.co.jp smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZEaxfZAWJIHlSTm8VRYPdw0ibwhWKWp4iBrTrG9GQoo=;
 b=ptqBoWQg44XdRS50EI88pDcPKtuLiGoEhWMJ/j0RLkaUY5zwFeZTofTWYqxIeHN1UvZgqo+Vg7y/qyItIKvada8dkq8kc37//+aJCgZJgo9vErEyhsJGHYpGW3/LxWBNPkHFY49U0uJvVfuOlZOXrYouEsyVKh6fxrNsyMOtjL0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <0b43902d-395b-4dc0-9098-451951f7f840@amd.com>
Date: Thu, 27 Aug 2026 10:06:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: "Orzel, Michal" <michal.orzel@amd.com>
Subject: Re: [PATCH v4] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
To: Hirokazu Takahashi <taka@valinux.co.jp>, <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, "Jan
 Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger@xenproject.org>
References: <20260826105529.364192-1-taka@valinux.co.jp>
Content-Language: en-US
In-Reply-To: <20260826105529.364192-1-taka@valinux.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3E:EE_|LV9PR12MB9781:EE_
X-MS-Office365-Filtering-Correlation-Id: 1207a5a4-581f-48b3-c230-08df041211ab
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|36860700016|23010399003|1800799024|82310400026|10067099003|56012099006|6133799003|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	T0NUqK3e3V2mXqXOhGg9CdfXpUVzBqm1b0QUyHCFuthEEfTVWmjVCfDdLUzAl9AlGKpHWhqXxvCHGVHo5fkxy+ImKUWKY1lmyZCAZhg+v9UNEwOBibQW8d63J6Dsr2GXkIomVBV1ZkS1V6ndR59ho7ZSCZn4txBQBhHz0yKC3MOp3JgmGoSF8glMoY7Tz//HUFtM7oKA4hXyhs99S6mse5pkUtm+iH6e78XYRrECSn6aSa4XndqIgy9DKl1JcvGs7rHeyVzCwF4aBwzwsnuXnIR84cSwJFu1cgAen/+l9um6oYOzfnd6GFhcppKAS0UGncmFCyUx46b905pN/cdML/y6AW4P1lXr9AO5esqvrFh1ht7Vrtlrl+zwwIGwPxjC/ig4DNTPCIk+L0gcxqVelVWNfa5RlskVOodFV5OwYkBkvXSKFuK3MwEYBJcIb0HW9VxVpMvWmZ0s06jn1LBy6d9DDlD60iKOKlnJ1eKum1SuTad6bWrmwjKLYiDjhaockjtTIKtmPFveoaQLgbMBOd3iTFgag/Sjb3KgB5cSjZ18FB8ck1EELr1aRnqpEOpfNRqHpLalHDcpojc1XYE/3zW6V7dAkOcI7wwwNiBlIGE1RE1cl2UhDHbWpr0mnjpYf5WyKld5ahMFC12t+P+XIYVimsL1xI2DiMOUeN1rBGw/mR81tiOvkaduhimBLgjdagrtyfzUKhdQBb7EFsllaA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700016)(23010399003)(1800799024)(82310400026)(10067099003)(56012099006)(6133799003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	UUre23Z6JswYcvUqHxjr7cbqs8hBV2h0GN/MJCMpOWKjfMH5nFlP5g6+vhjNU/nM7hWRevGmufl8HnebgdTD86PJaE35M7AtdtWXuhyHdI4sBxNGALddLFmilWRocqbu1+JlNnIhgKS0gzaYn07zomCTtrJBM6V8opORPa/ecbwVzxQiRP0HvRC06FzzgrsP7x5P0XvSr42/1bBR4x/4/sc2Cxi9rCVS7Kjnrlk4hbmA4IVmGXxl50oNCzA6lR+RdJO5ruVow3nhKYvqK1H9Ht2K/9hj3vIsruplMoY4mlwCCSux30/4L/0Pe6qP7ppf5DzcNVvP/o9wDWml3uk6OvscTSRzQxVnxa2bYV8lsvMywYlDWOCIg2GTqrrGJOFcvIVvHTJXMTWwHMUp52jhO9dq064QyESGEoDFCO/zH6OXy4bC1zRC2rO23xVH6MlW
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 08:06:16.1648
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1207a5a4-581f-48b3-c230-08df041211ab
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE3E.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR12MB9781
X-purgate-ID: tlsNG-ef75cf/1787817982-A66DAAE4-DD7830D6/0/0
X-purgate-type: clean
X-purgate-size: 11221



On 26-Aug-26 12:55, Hirokazu Takahashi wrote:
> On ARMv8.4-A and newer platforms, booting Dom0 Linux with ACPI enabled
> causes the domain to probe advanced PMU feature based on system ID
> register ID_AA64DFR0_EL1. During this probe, Linux accesses PMMIR_EL1,
> which causes unhandled register traps and crashes the domain.
> 
> To address this issue, implement the following:
> 
> - Add emulation for ID_AA64DFR{0,1}_EL1, ID_DFR{0,1}_EL1 and
>   ID_DFR{0,1} register accesses for guest domains.
> - Hide PMU registers from a guest domain when its vPMU feature is
>   disabled.
> - Proactively make SPE, TRBE, BRBE, Trace Extensions, SPMU, ITE and
>   EBEP inaccessible to arm64 guest domains and hide TraceFilt,
>   MMapTrc and CopTrc to arm32 guest domains, as they could
>   potentially cause similar issues.
> 
> Fixes: dbb948110a0e ("xen: Expose the PMU to the guests")
> Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64")
> Fixes: 3669a1cb9598 ("xen/arm: create a cpuinfo structure for guest")
> Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp>
> ---
> Changes in v4:
>  * Hide FEAT_HPMN0 from guests when the vPMU feature is disabled.
>  * Unconditionally hide FEAT_SPMU and FEAT_EBEP from guest domains.
>  * Fix arm32 build failure in vcpreg.c.
>  * Perform code cleanups and address coding style feedback.
> 
>  xen/arch/arm/arm64/vsysreg.c          | 62 +++++++++++++++++++++++++--
>  xen/arch/arm/cpufeature.c             | 17 ++++++++
>  xen/arch/arm/domain.c                 |  2 +-
>  xen/arch/arm/include/asm/arm64/hsr.h  |  1 +
>  xen/arch/arm/include/asm/cpregs.h     |  1 +
>  xen/arch/arm/include/asm/cpufeature.h | 27 +++++++++---
>  xen/arch/arm/vcpreg.c                 | 29 ++++++++++++-
>  xen/include/xen/sched.h               |  5 +++
>  8 files changed, 130 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> index d9e3619dfb..bf612a133d 100644
> --- a/xen/arch/arm/arm64/vsysreg.c
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -227,6 +227,7 @@ void do_sysreg(struct cpu_user_regs *regs,
>       */
>      case HSR_SYSREG_PMINTENSET_EL1:
>      case HSR_SYSREG_PMINTENCLR_EL1:
> +    case HSR_SYSREG_PMMIR_EL1:
>          return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
>      case HSR_SYSREG_PMUSERENR_EL0:
>          /* RO at EL0. RAZ/WI at EL1 */
> @@ -300,8 +301,32 @@ void do_sysreg(struct cpu_user_regs *regs,
>      GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0)
>      GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1)
>      GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2)
> -    GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0)
> -    GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1)
> +
> +    case HSR_SYSREG_ID_DFR0_EL1:
> +    {
> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !is_vpmu_domain(v->domain) )
> +            info_dbg32.perfmon = 0;
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg32.bits[0]);
> +    }
> +
> +    case HSR_SYSREG_ID_DFR1_EL1:
> +    {
> +        union cpuinfo_dbg32 info_dbg32 = domain_cpuinfo.dbg32;
> +
> +        if ( !is_vpmu_domain(v->domain) )
> +        {
> +            info_dbg32.mtpmu = 0;
> +            info_dbg32.hpmn0 = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg32.bits[1]);
> +    }
> +
>      GENERATE_TID3_INFO(ID_AFR0_EL1, aux32, 0)
>      GENERATE_TID3_INFO(ID_MMFR0_EL1, mm32, 0)
>      GENERATE_TID3_INFO(ID_MMFR1_EL1, mm32, 1)
> @@ -342,8 +367,37 @@ void do_sysreg(struct cpu_user_regs *regs,
>      }
>  
>      GENERATE_TID3_INFO(ID_AA64PFR1_EL1, pfr64, 1)
> -    GENERATE_TID3_INFO(ID_AA64DFR0_EL1, dbg64, 0)
> -    GENERATE_TID3_INFO(ID_AA64DFR1_EL1, dbg64, 1)
> +
> +    case HSR_SYSREG_ID_AA64DFR0_EL1:
> +    {
> +        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
> +
> +        if ( !is_vpmu_domain(v->domain) )
> +        {
> +            info_dbg64.pmu_ver = 0;
> +            info_dbg64.pmss = 0;
> +            info_dbg64.mtpmu = 0;
> +            info_dbg64.hpmn0 = 0;
> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg64.bits[0]);
> +    }
> +
> +    case HSR_SYSREG_ID_AA64DFR1_EL1:
> +    {
> +        union cpuinfo_dbg64 info_dbg64 = domain_cpuinfo.dbg64;
> +
> +        if ( !is_vpmu_domain(v->domain) )
> +        {
> +            info_dbg64.pmicntr = 0;
> +            info_dbg64.dpfzs = 0;
FEAT_SPE_DPFZS depends on SPE, and you already clear pms_ver. Move it next to
clearing pms_ver.

> +        }
> +
> +        return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
> +                                  info_dbg64.bits[1]);
> +    }
> +
>      GENERATE_TID3_INFO(ID_AA64ISAR0_EL1, isa64, 0)
>      GENERATE_TID3_INFO(ID_AA64ISAR1_EL1, isa64, 1)
>      GENERATE_TID3_INFO(ID_AA64MMFR0_EL1, mm64, 0)
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 94d14fb6a9..88478fea46 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -219,8 +219,25 @@ static int __init create_domain_cpuinfo(void)
>      domain_cpuinfo.isa64.api = 0;
>      domain_cpuinfo.isa64.gpa = 0;
>      domain_cpuinfo.isa64.gpi = 0;
> +
> +    /* Hide SPE, TRBE, BRBE, Trace Extensions, SPMU, ITE and EBEP */
> +    domain_cpuinfo.dbg64.trace_ver = 0;
> +    domain_cpuinfo.dbg64.pms_ver = 0;
> +    domain_cpuinfo.dbg64.trace_filt = 0;
> +    domain_cpuinfo.dbg64.trace_buffer = 0;
> +    domain_cpuinfo.dbg64.ext_trc_buff = 0;
> +    domain_cpuinfo.dbg64.brbe = 0;
> +    domain_cpuinfo.dbg64.syspmuid = 0;
> +    domain_cpuinfo.dbg64.spmu = 0;
> +    domain_cpuinfo.dbg64.ite = 0;
> +    domain_cpuinfo.dbg64.ebep = 0;
>  #endif
>  
> +    /* Hide Trace Extensions for AArch32 domain */
> +    domain_cpuinfo.dbg32.coptrc = 0;
> +    domain_cpuinfo.dbg32.mmaptrc = 0;
> +    domain_cpuinfo.dbg32.tracefilt = 0;
> +
>      /* Hide AMU support */
>  #ifdef CONFIG_ARM_64
>      domain_cpuinfo.pfr64.amu = 0;
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index baa3a5d708..a739dd157e 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -501,7 +501,7 @@ int arch_vcpu_create(struct vcpu *v)
>      v->arch.hcr_el2 = get_default_hcr_flags();
>  
>      v->arch.mdcr_el2 = HDCR_TDRA | HDCR_TDOSA | HDCR_TDA;
> -    if ( !(v->domain->options & XEN_DOMCTL_CDF_vpmu) )
> +    if ( !is_vpmu_domain(v->domain) )
>          v->arch.mdcr_el2 |= HDCR_TPM | HDCR_TPMCR;
>  
>      if ( (rc = vcpu_vgic_init(v)) != 0 )
> diff --git a/xen/arch/arm/include/asm/arm64/hsr.h b/xen/arch/arm/include/asm/arm64/hsr.h
> index 1495ccddea..ed18184cc7 100644
> --- a/xen/arch/arm/include/asm/arm64/hsr.h
> +++ b/xen/arch/arm/include/asm/arm64/hsr.h
> @@ -84,6 +84,7 @@
>  #define HSR_SYSREG_FAR_EL1        HSR_SYSREG(3,0,c6, c0,0)
>  #define HSR_SYSREG_PMINTENSET_EL1 HSR_SYSREG(3,0,c9,c14,1)
>  #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
> +#define HSR_SYSREG_PMMIR_EL1      HSR_SYSREG(3,0,c9,c14,6)
>  #define HSR_SYSREG_MAIR_EL1       HSR_SYSREG(3,0,c10,c2,0)
>  #define HSR_SYSREG_AMAIR_EL1      HSR_SYSREG(3,0,c10,c3,0)
>  #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
> diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h
> index a7503a190f..3f62b38dc0 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -246,6 +246,7 @@
>  #define PMINTENSET      p15,0,c9,c14,1  /* Perf. Mon. Interrupt Enable Set Register */
>  #define PMINTENCLR      p15,0,c9,c14,2  /* Perf. Mon. Interrupt Enable Clear Register */
>  #define PMOVSSET        p15,0,c9,c14,3  /* Perf. Mon. Overflow Flag Status Set register */
> +#define PMMIR           p15,0,c9,c14,6  /* Perf. Mon. Machine Identification Register */
>  
>  /* CP15 CR10: */
>  #define MAIR0           p15,0,c10,c2,0  /* Memory Attribute Indirection Register 0 AKA PRRR */
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index bf902a3970..c554686415 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -208,7 +208,7 @@ struct cpuinfo_arm {
>          };
>      } pfr64;
>  
> -    union {
> +    union cpuinfo_dbg64 {
>          register_t bits[2];
>          struct {
>              /* DFR0 */
> @@ -216,19 +216,31 @@ struct cpuinfo_arm {
>              unsigned long trace_ver:4;
>              unsigned long pmu_ver:4;
>              unsigned long brps:4;
> -            unsigned long __res0:4;
> +            unsigned long pmss:4;
>              unsigned long wrps:4;
>              unsigned long __res1:4;
>              unsigned long ctx_cmps:4;
>              unsigned long pms_ver:4;
>              unsigned long double_lock:4;
>              unsigned long trace_filt:4;
> -            unsigned long __res2:4;
> +            unsigned long trace_buffer:4;
>              unsigned long mtpmu:4;
> -            unsigned long __res3:12;
> +            unsigned long brbe:4;
> +            unsigned long ext_trc_buff:4;
> +            unsigned long hpmn0:4;
>  
>              /* DFR1 */
> -            unsigned long __res4:64;
> +            unsigned long syspmuid:8;
> +            unsigned long brps1:8;
> +            unsigned long wrps1:8;
> +            unsigned long ctx_cmps1:8;
> +            unsigned long spmu:4;
> +            unsigned long pmicntr:4;
> +            unsigned long able:4;
> +            unsigned long ite:4;
> +            unsigned long ebep:4;
> +            unsigned long dpfzs:4;
> +            unsigned long abl_cmps:8;
>          };
>      } dbg64;
>  
> @@ -408,7 +420,7 @@ struct cpuinfo_arm {
>          };
>      } pfr32;
>  
> -    union {
> +    union cpuinfo_dbg32 {
>          register_t bits[2];
>          struct {
>              /* DFR0 */
> @@ -426,7 +438,8 @@ struct cpuinfo_arm {
>  
>              /* DFR1 */
>              unsigned long mtpmu:4;
> -            unsigned long __res1:28;
> +            unsigned long hpmn0:4;
> +            unsigned long __res1:24;
>  #ifdef CONFIG_ARM_64
>              unsigned long __res2:32;
>  #endif
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index 3205c7df46..db8909d96e 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -292,6 +292,7 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr)
>              return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
>      case HSR_CPREG32(PMINTENSET):
>      case HSR_CPREG32(PMINTENCLR):
> +    case HSR_CPREG32(PMMIR):
There's a comment above this block that we don't trap ID_DFR0 which is not true.
It should be dropped as part of this patch.

I'll do the fixes on commit. Thanks for the patch.

Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 08:23:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 08:23:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400393.1636053 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzVOJ-000165-LX; Thu, 27 Aug 2026 08:23:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400393.1636053; Thu, 27 Aug 2026 08:23:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzVOJ-00015y-Hu; Thu, 27 Aug 2026 08:23:19 +0000
Received: by outflank-mailman (input) for mailman id 1400393;
 Thu, 27 Aug 2026 08:23:18 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wzVOI-00015s-IK
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 08:23:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzVOH-00GsUX-3t
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 10:23:17 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8ff3e6-bab6-0a2a0a5309dd-0a2a45058638-36
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 10:23:16 +0200
Received: from [40.93.201.42]
 (helo=CY3PR05CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a8ff3f3-4cb1-0a2a45050019-285dc92a99b8-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 10:23:16 +0200
Received: from BN9PR03CA0228.namprd03.prod.outlook.com (2603:10b6:408:f8::23)
 by PH7PR12MB7456.namprd12.prod.outlook.com (2603:10b6:510:20f::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.9; Thu, 27 Aug
 2026 08:23:11 +0000
Received: from BL6PEPF00022572.namprd02.prod.outlook.com
 (2603:10b6:408:f8:cafe::45) by BN9PR03CA0228.outlook.office365.com
 (2603:10b6:408:f8::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.10 via Frontend Transport; Thu,
 27 Aug 2026 08:23:10 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BL6PEPF00022572.mail.protection.outlook.com (10.167.249.40) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Thu, 27 Aug 2026 08:23:10 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 03:23:10 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 03:23:10 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Thu, 27 Aug 2026 03:23:09 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xVI5ZO19z8T2TDHj9V5yl6Cy7TCA7aTY0qHf8WdLOiqbVnUH/c9WzDt/U6XLhHI5UTw6TdZw4ukitLoT2k8RMgxSOOVhvlI1OBQ4I6nAk5W67w3ffJ4VGZoLKMABSbp6avbnAdQRTnM4DsS8K/W+gBXDHfhoW87POvaWukR5iH2nvBYGQDnwD7Efow+qMnfJVB0ozpznXwSKf1F0/FyIstB0zBAw+wMNwOuODUV1MH3EfK49SFQw3xxIS7OLblcBQmg+0/lwFDH0JXXc0Y2f5TWitmDlmlGMiujk2II9PqtDllLAdT5833eiSzncoTcnZ7c5dYfUsdwQMqR+KS38mA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PjoiI3jA92lSsQgwZ4R8+YsMenuPk2Dm0CBsOMgBuBg=;
 b=rZp534xfMdqiDmtFSvvGJUMGb7PjERYYPauH6da0KaPUtGrqAq+EhwlaKI/t4yQ2JOM1wlTo9WZt4a/MuJeu++iDv+QQfxIh5GwN+eU3bTfPTgYTnn3idq9kAO4j+fhzpxVCxNpi1HNuST8nwLUju+fLx4TiNIXeZEBM9Bue7XV2RCKz9VEsSkKvA7lf42oK28pCqxRuLw9BwmU9lV4K5PTwUnCT+3X/LY4GaGXOa3M4inPYj/Tufq6DL1X2X3pIysPxDhOp/4nz6LVD3bRsMms6l8BYec3RO8gj/LODks8IIHfhyTSCgTPcESQ7FBcB7dBNjPbh3+smSB4vVU1Pbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PjoiI3jA92lSsQgwZ4R8+YsMenuPk2Dm0CBsOMgBuBg=;
 b=nIZC9zNov25xAZHZByyKqExNjbLL7saC/LFV1bM0of/SZOhM9S0X8aKx0A0Fsn3yq4wIw1CmxylXxZIDjIeyvgSqIUmIWlb/1IiIed9BJE9nfPUser2rrVslfq5TfuOnAI50KjrwDAbRX+3YRKYZJhJj3vzEq1Gu/1A2v/p1J68=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <4e82e859-9c0b-4467-a80c-210379a64e84@amd.com>
Date: Thu, 27 Aug 2026 10:23:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] xen/arm: traps: report level 0 faults in panic_PAR()
To: Oleksandr Tyshchenko <olekstysh@gmail.com>,
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>
References: <20260825062329.16762-1-michal.orzel@amd.com>
 <20260825062329.16762-2-michal.orzel@amd.com>
 <c576b8de-b149-4d60-bc7d-436e06039832@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <c576b8de-b149-4d60-bc7d-436e06039832@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF00022572:EE_|PH7PR12MB7456:EE_
X-MS-Office365-Filtering-Correlation-Id: c87a4d5c-894c-40ae-1655-08df04146e6d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|36860700016|1800799024|23010399003|10067099003|3023799007|18002099003|22082099003|11063799006|4143699003|56012099006;
X-Microsoft-Antispam-Message-Info:
	N68s8D5fEP5Og5k0UpvxQD3BRNoVS3M+DkQlTaTPP0tNLUSzw44ufDoGs5kFFl8OiMkwx9KayLvVNG4u+9dM7jliy/kzElSjG4RnYMekXF4cPmWS5uviBDF68B5enscmP0zzQRqV8pMLGmOOvx2kFeQ8wz30/TLgykOT/5GWuTsp+xoSiImjsZmLLd5RgyJi55Sv70j632gJRhG5jTl9NCtOA737a9dfK7BoUolS0XasCV3K1p3ysILJ23n3DLaXQY7x69b7GgKvqeCLQ+UCddQHKp8Xq+DBufXo8qDB2qMet0oaQwkmNoImFZ0hMteOHNIK4QVfdq5OsNVbsp2F9lIACg/KvkhUQyrxHAub7s5Fe7swqER6HuuypM5yNQfTOvK3bbGNHGgbXQH60cHZ8HNaP2imlGX/xfrY5Y5u5E3qfWlpJHys/E/1VjoTINq5c21kC5qIfzKXyYLcBAffmz1EQt/ivlfuiLf3A5fKCo9UwkgD4l5qXeaZRtk8rWqDxuUdzfWBvZ1qdCGHoLftx6+HaYkj8Dl2Gzw0SFQVfO5YiuFG4IZbOHLZdZdU+V2uFFatsn/sNeptOnroDD8O9neKFoV4zaCDDy2VDs1yb6Mp6OOqIyOMKSxO5IsVsFiHORpK8DKyOoq0GqBdZbRFRRUUULZKXTehLBGb289Vpoo8OgaHxzO/9oQXd78gkhtLLrWQTclt8WWvzKx1+/ting==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700016)(1800799024)(23010399003)(10067099003)(3023799007)(18002099003)(22082099003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	N1F+SetQAOuLeKB3fI0FjgSSdq5YvpWg4vgQ5Es67P8LRF0pbTRKbdz5BU3dJV96nEGVukGvKmyN1ogdK9tBWhECF7Qx/oZJNHjE34v2Ige96kdCOVA8NW5Qqp4Ex/ybc1U5rAA5jULvdCS5y/EqnXeAvj8wc8eboDV/5sHT/xRKjlhkefXdwodjzbbopHMbMSfv14okR4j9j39811UReAO/4yS9uFJSUW+l59sS0veuAVXxbEihZkjAm/4+U+9O3D0oQlz1EXsDzpNqrF57mP3E7FhggKtwUvDP0lohK750zJUs7HR6I0S0hBNDvcmH28O4LGV5P759NPF5nYEZkzt5gO1v4HhxaEuTBMlvpHrn3quhkYxEuhy3aV649aDYL6d46G39+Zw1W8SLLY426EeEDo+xc0W6F5zQ0Bf4bygYOtj1Z+sUiMVhCjCdbT+E
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 08:23:10.7956
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c87a4d5c-894c-40ae-1655-08df04146e6d
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF00022572.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7456
X-purgate-ID: tlsNG-c201ff/1787818996-F70B22A1-1EC709B2/0/0
X-purgate-type: clean
X-purgate-size: 3442



On 26-Aug-26 17:47, Oleksandr Tyshchenko wrote:
> 
> 
> On 8/25/26 09:23, Michal Orzel wrote:
> 
> Hello Michal
> 
> 
>> decode_fsc() derives the fault level from the low two bits of the FSC, so
>> level 0 is a valid output: FSC_FLT_TRANS is 0x04, i.e. "translation fault,
>> level 0".
>>
>> This is reachable on arm64 because xen_pgtable is the zeroeth-level root,
>> but fsc_level_str() has no case for it and prints " (level invalid)"
>> instead. At the time the function was created Xen used only three levels.
>>
>> Add the missing case. On arm32 the zeroeth level does not exist, hence
>> guard the case by CONFIG_ARM_64.
>>
>> While at it, make decode_fsc() decode also address size faults.
>>
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> 
> 
> Patch looks ok to me, so:
> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> 
> but I have a comment below:
> 
>> ---
>>   xen/arch/arm/include/asm/processor.h | 2 ++
>>   xen/arch/arm/traps.c                 | 8 ++++++++
>>   2 files changed, 10 insertions(+)
>>
>> diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
>> index a3753c317fff..509040a1cdc0 100644
>> --- a/xen/arch/arm/include/asm/processor.h
>> +++ b/xen/arch/arm/include/asm/processor.h
>> @@ -521,6 +521,7 @@ extern register_t __cpu_logical_map[];
>>   /*
>>    * 543210 BIT
>>    * 00XXLL -- XX Fault Level LL
>> + * ..00LL -- Address Size Fault LL
>>    * ..01LL -- Translation Fault LL
>>    * ..10LL -- Access Fault LL
>>    * ..11LL -- Permission Fault LL
>> @@ -534,6 +535,7 @@ extern register_t __cpu_logical_map[];
>>   #define FSC_TYPE_OTH   (_AC(0x02,U)<<4)
>>   #define FSC_TYPE_IMPL  (_AC(0x03,U)<<4)
>>   
>> +#define FSC_FLT_ADDR_SIZE (0x00)
>>   #define FSC_FLT_TRANS  (0x04)
>>   #define FSC_FLT_ACCESS (0x08)
>>   #define FSC_FLT_PERM   (0x0c)
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 0c01f37ad6b4..dc0ec8a345ed 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -307,6 +307,10 @@ static const char *decode_fsc(uint32_t fsc, int *level)
>>   
>>       switch ( fsc & 0x3f )
>>       {
>> +    case FSC_FLT_ADDR_SIZE ... FSC_FLT_ADDR_SIZE + 3:
>> +        msg = "Address size fault";
>> +        *level = fsc & FSC_LL_MASK;
>> +        break;
>>       case FSC_FLT_TRANS ... FSC_FLT_TRANS + 3:
>>           msg = "Translation fault";
>>           *level = fsc & FSC_LL_MASK;
>> @@ -363,6 +367,10 @@ static const char *fsc_level_str(int level)
>>       switch ( level )
>>       {
>>       case -1: return "";
>> +#ifdef CONFIG_ARM_64
>> +    /* On arm32 the zeroeth level does not exist */
>> +    case 0:  return " at level 0";
>> +#endif
> 
> 
> NIT: Before this patch fsc of 0x00 fell through to default, so it 
> printed "Unknown Failure" and level stayed -1. After the patch Arm32 
> decodes 0x00 as an address size fault and sets *level = 0, while case 0: 
> in fsc_level_str() is compiled out there, so the print becomes "Address 
> size fault (level invalid)". So I would either drop the #ifdef (to keep 
> the two hunks consistent), or not set the level on Arm32.
Actually, FSC 0 means address size fault at...:
 - on AArch64: level 0 OR translation table base register
 - on AArch32: translation table base register
so I will say: "at level 0 or TTBR" and drop the #ifdef.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:35:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400439.1636085 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWWI-0001ti-Ns; Thu, 27 Aug 2026 09:35:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400439.1636085; Thu, 27 Aug 2026 09:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWWI-0001tb-L5; Thu, 27 Aug 2026 09:35:38 +0000
Received: by outflank-mailman (input) for mailman id 1400439;
 Thu, 27 Aug 2026 09:35:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@swg.vates.tech>)
 id 1wzWWH-0001tV-0s
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:35:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWWG-002LJp-7a
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:35:36 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@swg.vates.tech>)
 id 6a9004cc-2eae-0a2a0a5409dd-0a2a45028de4-44
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:35:36 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@swg.vates.tech>)
 id 6a9004e7-6ca4-0a2a45020019-b9ff1c2381d1-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:35:36 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a04293255c000c4f3.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:35:34 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id D883383B61;
 Thu, 27 Aug 2026 11:35:33 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=yr+BwYUQPHoth+lckl1Y1HxUO1/zH4gLPlVTMB+7FjU=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:feedback-id;
 b=akpAJegsghONgX8tR8T/TKyCowx9P32QVocooajTl2Mf0S7Jp9iZUGjFJNkwNWeanBOsmt7DL
 +uh2Ntp0LRj9xF1ylfaKrriGadNc8SxCVigqFN8/2AQq5qG7tKofiJriu/Ufeye8iVnkvyHnPRS
 bq8XgM1PjspdCyWEppJLmoG5U78Y/3Jq42WKIaLt+0dZJ5CklE4ommthusrrywuZ/pwgIjCh74E
 cXvC464G1qzDYqcTVkHyLD5wVEHzTbw5EA8kXRecEXoepf4EGjsIYCSi55rkAj/DUs3UDMWOCnz
 3lQJ76semMjgOFDZELEABi8j5bm6Ek+yWYO5mflGyAIg==
X-Zone-Loop: 9906721adfdcb6f1efebe3e6b51e2627c408f1e7d0dc
x-campaign-type: default
x-transaction-id: 925ebd3f-d5ed-451c-a14e-f0f4960fb5fd
x-swg-uid: 01-3737171c-5a9e-44b2-8360-433b3f0ff558
X-Mailer: Sweego
Message-ID:
 <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
x-swg-bid: 1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: baptiste.leduc38@gmail.com,
	xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Doug Goldstein <cardoe@cardoe.com>
Subject: [PATCH v2 0/6] automation: add QTB test framework for riscv64 smoke tests
Date: Thu, 27 Aug 2026 11:35:31 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823334063
X-purgate-ID: tlsNG-720697/1787823336-319CB2AC-9BAE4548/0/0
X-purgate-type: clean
X-purgate-size: 8156

v1 was posted on 2026-08-10 with no response yet (13 business days). This
v2 also fixes a bug flagged during internal review, see "Changes since v1"
below.

Xen is being made safety certifiable to IEC 61508 SIL 3 and ISO 26262 ASIL
D, with Arm and x86 as the current targets [1]. Evidence at those levels is
requirements based testing plus structural coverage, produced automatically
and repeatably in CI.

QTB (QEMU Test Bench) [2] is the framework AMD wrote for it as part of the
Xen safety initiative. It drives a live QEMU instance over qtest, QMP and
GDB, so a test has full access to the machine while emulation runs: read
and write the consoles, inspect registers and memory, inject interrupts and
faults, all from Python and all reproducible in a pipeline. QTB is not
upstream in QEMU yet, but is planned to be.

RISC-V is not in the certification scope today. It is also the youngest
port, so it has close to no test infrastructure to undo, which makes it the
cheapest place to adopt QTB. Starting the riscv64 tests on the framework
now means the port grows its tests in the shape certification asks for as
the port itself grows, instead of a pile of expect scripts to convert later
if riscv64 ever becomes a certification target. It also puts a second
architecture on QTB, which is useful to the framework itself before it is
proposed to QEMU upstream.

Concretely, the riscv64 CI coverage today is one expect script,
automation/scripts/qemu-smoke-riscv64.sh, which boots Xen alone under QEMU
and greps a single string out of one serial console. The machine it boots
is hardcoded, so a second configuration means a second script, and a test
with a DomU in it means growing guest handling from scratch.

This series replaces that script with a data-driven framework using QTB. A
machine is a YAML entry (pcpus, scheduler, interrupt controller, boot
arguments), a test type is a small Python class saying what to do with a
booted machine, and a test binds a machine to that type's expectations.
Adding a configuration to CI is then a config change and a job stanza.

Patch 1 goes to test-artifacts [3] and must land first, since patches 2-6
run inside the container it adds. Patches 2-6 go to xen.git.

test-artifacts [3]:
- Add a QTB container to run the Xen riscv64 tests
    debian:13-qtb-riscv64, carrying qemu.qtb from AMD's QEMU fork and the
    dtc/fdt dependencies the framework needs at run time.

xen.git:
- automation/qtb: add jinja2 device trees for riscv64 smoke tests
    The host tree varies with hart count, MMU type and device set, so it is
    rendered per machine from a template rather than shipping one static
    .dts per configuration.
- automation/qtb: add Python QTB framework with the console-test type
    The base layer every test type builds on (machine catalog lookup, host
    DT generation, QEMU invocation, per-console log capture) plus the first
    test type, which asserts every string listed in console-test.yaml is
    printed on the expected console.
- automation/qtb: add unit tests for the QTB framework
    pytest coverage of the QEMU-agnostic parts, for developers only.
- automation/qtb: add QTB framework README
    How to add a machine, add a test type and run one locally.
- CI: run the riscv64 smoke test via QTB framework console-test
    Repoints qemu-smoke-riscv64-gcc at the framework and drops
    qemu-smoke-riscv64.sh, which then has no caller left.

Testing: Unit tests + QEMU only, as the existing riscv64 CI does.
qemu-smoke-riscv64-gcc runs the same check as before.

The catalog ships a single Xen-only machine, since Xen cannot boot a DomU
on RISC-V yet. DomU machines plus an irq-test type using QTest interrupt
injection follow once DomU support lands.

CI pipeline:
https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2795907042

[1] https://elisa.tech/blog/2026/07/22/the-final-phase-of-xen-safety-solving-coverage-and-residual-gaps-stefano-stabellini-amd/
[2] https://gitlab.com/xen-project/people/amd/qemu/-/tree/safety
[3] https://gitlab.com/xen-project/hardware/test-artifacts
[4] https://lore.kernel.org/xen-devel/1786980254.8631fc262581453bbf619ec5b2062170.1a01052c27d000c4f3@vates.tech/

---
Changes since v1:
- Resolve qemu-system-riscv64 from $PATH instead of pinning qemu-9.0.0 in
  test.yaml, dropping the now-unneeded OpenSBI entry too: the
  13-qtb-riscv64 container already bundles both (flagged by Zheng Zhang
  during internal review [4]). Also drops the qemu-9.0.0-riscv64
  test-artifacts dependency noted above.

Baptiste Le Duc (5):
  automation/qtb: add jinja2 device trees for riscv64 smoke tests
  automation/qtb: add Python QTB framework with the console-test type
  automation/qtb: add unit tests for the QTB framework
  automation/qtb: add QTB framework README
  CI: run the riscv64 smoke test via QTB framework console-test

 .gitlab-ci.yml                                |   3 +
 automation/gitlab-ci/test.yaml                |  20 +-
 automation/scripts/qemu-smoke-riscv64.sh      |  19 --
 automation/scripts/qemu_smoke_riscv64.py      | 122 ++++++++++
 automation/scripts/qtb/__init__.py            |   2 +
 automation/scripts/qtb/riscv/README.md        | 182 +++++++++++++++
 automation/scripts/qtb/riscv/__init__.py      |   9 +
 automation/scripts/qtb/riscv/config.py        | 119 ++++++++++
 automation/scripts/qtb/riscv/config.yaml      |  17 ++
 .../qtb/riscv/console_test/__init__.py        |   4 +
 .../qtb/riscv/console_test/console-test.yaml  |  18 ++
 .../qtb/riscv/console_test/console_test.py    | 145 ++++++++++++
 automation/scripts/qtb/riscv/dt.py            |  57 +++++
 .../scripts/qtb/riscv/dts/qemu-host.dts.j2    | 160 +++++++++++++
 automation/scripts/qtb/riscv/machine.py       |  57 +++++
 automation/scripts/qtb/riscv/paths.py         |  60 +++++
 automation/scripts/qtb/riscv/qtb_test.py      |  53 +++++
 automation/scripts/qtb/riscv/unit/__init__.py |   2 +
 automation/scripts/qtb/riscv/unit/conftest.py |  42 ++++
 .../scripts/qtb/riscv/unit/test_config.py     | 121 ++++++++++
 .../qtb/riscv/unit/test_console_test.py       | 217 ++++++++++++++++++
 automation/scripts/qtb/riscv/unit/test_dt.py  |  99 ++++++++
 .../scripts/qtb/riscv/unit/test_machine.py    |  60 +++++
 .../scripts/qtb/riscv/unit/test_temp_dir.py   |  42 ++++
 .../scripts/qtb/riscv/unit/test_xen_dt.py     |  46 ++++
 automation/scripts/qtb/riscv/xen_dt.py        |  58 +++++
 26 files changed, 1709 insertions(+), 25 deletions(-)
 delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh
 create mode 100755 automation/scripts/qemu_smoke_riscv64.py
 create mode 100644 automation/scripts/qtb/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/README.md
 create mode 100644 automation/scripts/qtb/riscv/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/config.py
 create mode 100644 automation/scripts/qtb/riscv/config.yaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/console_test/console-test.yaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/console_test.py
 create mode 100644 automation/scripts/qtb/riscv/dt.py
 create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2
 create mode 100644 automation/scripts/qtb/riscv/machine.py
 create mode 100644 automation/scripts/qtb/riscv/paths.py
 create mode 100644 automation/scripts/qtb/riscv/qtb_test.py
 create mode 100644 automation/scripts/qtb/riscv/unit/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/unit/conftest.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_config.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_console_test.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_dt.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_machine.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_temp_dir.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_xen_dt.py
 create mode 100644 automation/scripts/qtb/riscv/xen_dt.py



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:38:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:38:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400446.1636094 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYf-0002Q7-2u; Thu, 27 Aug 2026 09:38:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400446.1636094; Thu, 27 Aug 2026 09:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYf-0002Q0-0G; Thu, 27 Aug 2026 09:38:05 +0000
Received: by outflank-mailman (input) for mailman id 1400446;
 Thu, 27 Aug 2026 09:38:03 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <taka@valinux.co.jp>) id 1wzWYd-0002PW-54
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:38:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWYc-003lK1-0L
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:38:02 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a900573-8faa-0a2a0a5109dd-0a2a450ca04c-16
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:01 +0200
Received: from [52.101.125.120]
 (helo=TYVP286CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <taka@valinux.co.jp>)
 id 6a900576-f479-0a2a450c0019-34657d781a30-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:00 +0200
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18)
 by TY7P286MB6497.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:323::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 09:37:56 +0000
Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
 ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 09:37:56 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UDfPGptbznJCrMlpjYOjro/TitqGdQ9zthZELG5o/l1xuH0N6FBydisIPIuZMTq1s8x50nr3sw8NbcdcOkuSRbGCp0mcYBqvcAsgP/aIdDwg+QJbi6KHAoJYEN2B8Jbb4Yq/FpnOPCHsWHgivBZtPji0viqeDie8/KRBPBY/7Bi5qndUZ73HoYVmeYHxTXpFEsN1kvKs6ZVe1Oz0dTD/JThgIdgAW3LDFc35PdkYOBGNr/wSb0vmQohWVj5b9ehdK8474UvbiliUebIRZG39a9mQZihvjsUZtAcF93yGfTvI3EzXHh4E3URj/e6eUc2qIOGNUdVR2kdpG2MDU30+rA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sCeOMY6Y7jhwow2tCclK/InDBVOjMxUUTpXDvDqawlw=;
 b=abZ99EKgTJEyZj8a8sXUavuHgObtsfG7QX7HBOXmagPMdzWL+aUDVQZTHWBUEBjG1YlwIMFbZ1xLV+/EJv2GuzewKKPiio9amoBJ1u8P5BvfCdS+3p6W6UyreIVoi4lk5zGgOl03ifYucO5CSS7IUQcud5msnDtEpD+zNfcRpccC1xHTRdZ+eW9C2ubDfd2yV/soLxIlH8U+xmJwvw7Dn+OuL5LDrd34V2XBHUMduo1PWWpOYcpyMb/hyL3EZ+DoOnru/MRKSvKVGCal15fVQuGXL+9VylzRLdtdxSgM5JR8pzwU73/TT1RNkVudZKWCeuTTYyF/EWqykW8KMlRQsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=valinux.co.jp; dmarc=pass action=none
 header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sCeOMY6Y7jhwow2tCclK/InDBVOjMxUUTpXDvDqawlw=;
 b=Ln83qIOg5VFxWOQZM27yq1MHkffbRoA0qt9JV9bQaRUpQt/pN1lGVyrqk48UsjaV8koJ0BQ9MsYdtff0hpvVs85/OXD748EHrz89E8UirH9keyCTz0lfD7V283ooFFKSUVkVLHUbHCmgNp/7zcuz5d6gvD3ywbfNqBQ8Pwwp48M=
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: "Orzel, Michal" <michal.orzel@amd.com>, "xen-devel@lists.xenproject.org"
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Anthony PERARD <anthony.perard@vates.tech>, Jan
 Beulich <jbeulich@suse.com>, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	<roger@xenproject.org>
Subject: RE: [PATCH v4] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
Thread-Topic: [PATCH v4] xen/arm: Hide PMU registers from the guest, when the
 vPMU feature is disabled.
Thread-Index: AQHdNUmClLFiR6ETN0eEmaF3vHz5G7axi0EAgAAZbpA=
Date: Thu, 27 Aug 2026 09:37:55 +0000
Message-ID:
 <OS9P286MB722232EB6A2BDECFF093D43982AD2@OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM>
References: <20260826105529.364192-1-taka@valinux.co.jp>
 <0b43902d-395b-4dc0-9098-451951f7f840@amd.com>
In-Reply-To: <0b43902d-395b-4dc0-9098-451951f7f840@amd.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=valinux.co.jp;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TY7P286MB6497:EE_
x-ms-office365-filtering-correlation-id: 46546a92-ef2a-45f3-142d-08df041edfc8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|7416014|23010399003|376014|38070700021|4143699003|6133799003|10067099003|56012099006|18002099003|22082099003;
x-microsoft-antispam-message-info:
 WEQFvqNxzI8a79dyY/kCMfntybmpXD8SDNSB7U7Ydip6I36h5NPePI2AbHMXUw3Vp2xf8jCc0LKAdEbM79uPl39TnbJSdva+bu9oLRxT+niWsRG/wcbJRVWki5mYzls9DnlNWiger+WRpPZ/8Nyscl8+aaBLqid1SJ4ui9J3xWFA4T7I5sPfk6nJDVXtDrJYQGelbr7bruaydBLKifbD/wN0Zfr3fVO7DZtZGeGvghvbhEnW3yKGwGC06RoC0mO/xKZwGcppClWswg9gw57niQWEIyxaN5HaEmergpTq+m9KGLgkZr35xnWACJIlgb2Is6ivLxs7DCieQ773ZrQTpncv4CXDN6iL70JrLcf4Ust8HOTh7EoEUsGZvpamqSjt+ES8TW1zqg4Q1uav3CwGa1PskqJYmk+b0YvYwpNjGaN3cQwrO4mETQfPGu/xgZqqQERjE27OAMVXPyav99JSszLjho+XG9x3YnEX5BvMbwmrxihZVXrKnZguiZU5zUoWMVfzqufwtTkh1nbl89+g8QYwCSHTTa3+BpZ152K0JxmBXWjMoSQsuCkgR1EXJTrOpmECTmVPJZVGv+TlAZoSh8iywukQOJMx9IuUV4GC65LmTRQ5ujt+TDlC+LQ+3ZKiqvYhs+p/Y/kjAGHFsesO1+932Jn2nJGr+eAY/thA11JJni2IIsc1yFUtM1CPyF+CECj1vmSOB4hY7qnCXmUQ0w==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(23010399003)(376014)(38070700021)(4143699003)(6133799003)(10067099003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?YjNId21JZkp4NXJGcnBJQmthWVBOb25OenRmRE14K0toRnNQdEVIL2lSU3Ur?=
 =?utf-8?B?SkJ3bVVtNWRuZzNMb05OWGpKekR5N0I5TjdGN0NjTTRZekVod1dYVlYwS1kw?=
 =?utf-8?B?MkVsbzFCbkdKYzlXem80eGl2QkxubitpTVRWYzAzQytwSHhWSFUyampTR0oy?=
 =?utf-8?B?YlBUYmZtNHluWVdNSm9yemVEcTczRUVIQjhZOXc4ZHVoQVZYeHlWbEFzR3NO?=
 =?utf-8?B?KzIwM2NwL1RSM0ZXS0Q3RDB5aVVPbDc0QzBqQXptNXFnZGNzTVNQendWdkU2?=
 =?utf-8?B?QkhnV3RmZTBMUENWZi92cFNsNVRuVmFRTE93YkROOWdROHJmTDZmS2hoQ1Zr?=
 =?utf-8?B?anBEa0Z6ZitPUjJGN0lxOHRhUElSQmFzSExiT1VQZ0NrSlpQNGt3eGdITnJD?=
 =?utf-8?B?eGpFMzVFdmpMQmowbm8wWlRUWURzM3MyeEdYYUdEbGh6NDNWMTFFbmpBWUVu?=
 =?utf-8?B?Y0RyT01FQk5CdFFsN2hVNm1zNFRDcUM0dmV0c1czMjVaOFVVNVNyS2I2NWVN?=
 =?utf-8?B?Y1JFc0hTVzU3cmQveUxmZVFuQ2txOVQxUUtuOHgrcmc4TGpZcXd6NGFVT2tG?=
 =?utf-8?B?VnhZcnVsaGRBUXlJd3NiT1o4bmdDZUJVVFhJNGg5dFFKeEZMR3h1UFBKUFU0?=
 =?utf-8?B?NGdhZmZyWmVTR25TZmNPeUIxbWY0VVcySXZkRDdJZTI2WTFPZzgyVUVzZ1o0?=
 =?utf-8?B?M2FWc0FsaytveDF3dmpWZjUwK2dnOWlnWHorTVlSMkN1MzRwZzVjUjBzQWlj?=
 =?utf-8?B?RjFMN1J3Ly9hMkhsalUveHRGWXE0Z0k4Yk1zMG1BTmFlVHZCSFJ2RUxEOFB1?=
 =?utf-8?B?ZWZzWk03R2F1ME5UTVNiYjZSd1NzL3Vjb2sxRyt5ZVkya1hEcE56NWhQZU0r?=
 =?utf-8?B?WUx3STBMMnFSK0wybHNRNFZSZFpwd3Z4MWtzdEt6d2QzK1NsSURoQWMvbnNm?=
 =?utf-8?B?WkpGemZHNlhNME9FMm1JdnpzU09vS29EUlRXdFFMMk85SmVpSkFBU3dSdkp0?=
 =?utf-8?B?UnZSUjhOeXN1eG8wbjhwOEM4SmRNZnJzT05BWExwK2tUMVk3RVUvb1RydTZC?=
 =?utf-8?B?a2pyR2VDSkliRVdsYUFiRFJzcS8yUW1Yd0xtTDRMbTZZdnBsc1Iwd0QyU3Z4?=
 =?utf-8?B?Y2pCM1Z5UnZXYTU5NlNQQ2tPNERGTXRyNG85VkFFNGVmaVhyMXJGUWpTaGQv?=
 =?utf-8?B?WmNZL2lscVgxNlBZNXZ0K09RT0hCUDdyNTVDSCs3aVJBU0NnZTM4aTlzYTcv?=
 =?utf-8?B?ZWdieGxKbHdXdlZZM09mMmRXRHFJT0YyaVQ2RmNJRWt5WXJWTjRGNE9POHJB?=
 =?utf-8?B?cWdEdi9qaVR4QTVXS3lERlFPYUhtVmNtTWVaSFRKQ0JZcmZBLzFsQnk0dWdw?=
 =?utf-8?B?dTEvcDRiV0MyNnczVmhnbVIya1FuTXRHVHV3WDBOSGdNVXpkYkpMdHh4bC9B?=
 =?utf-8?B?OG4zdy9OWU5ZejFaMkN2UndDSW1vVzZ3eWhwbEVjVUowc054SjRGcFNBeGY2?=
 =?utf-8?B?NHB5TklVK01aL2NBSnU2amlBUmd5NkNGTGtTb3JOSlVFK1ZMQ3ZDcHhPNHIr?=
 =?utf-8?B?V0RsUWFxNUxXUEYyN3NnOW5DcXZ5ZzRvUkJXUWVzVmw0ODUwcHVQUUVtNnk5?=
 =?utf-8?B?c3VQVGJ0c25MWmxrNVpWZG11cGgySVR0Qkh3MXhVUHBpcHNleit4ekozL0hH?=
 =?utf-8?B?ZmdSWm9CU21XN2hITkoyK0lYQ2xtR3ZkZXJvQ3JVU0VxRUc1Z0RUOEFsaEo4?=
 =?utf-8?B?OWFuUE83azlPZk9ZMGt4ZDdYanE1a3JxRkc2SEI1S0k4VnJrN0tkUmRwa0w2?=
 =?utf-8?B?eUh1S0RHd0dJSGVLZHZWMzZZaVVoc0RsZTlQMGZ3OG13OVpCT0w4aTN1RUMx?=
 =?utf-8?B?ZXc0ZUllM0NLb0U3dnFPRDdKSkEzTVVtb3V4SnM2UHVZVGdFVGZBeXBaajVl?=
 =?utf-8?B?UEVINTBLSCt1OWxYQlRLSU14K2M0cFZobWNCRFgrU29jKzJpK1Y1a01PdkdJ?=
 =?utf-8?B?ZDJNbSs3VUJIdVZ0cHEwUytDVWthNXBNRWV2TlJDWXI2UWRqeTEvcE4waFc3?=
 =?utf-8?B?QnJ0YXhVMFltdElSeW9wWEhteHRDY2VoNHY1NC9sTTRzTXdlSUdwazZyd3hz?=
 =?utf-8?B?VEppSC9VV2J3MytJcXV0aFlVN2NxR29FOGk0RG12c0F4U2hPbkc1SE0reDJF?=
 =?utf-8?B?bjNxbjEyUE9uQ3lRbzZkYWVnVEU1SnJpOE9GNm9GTnFiWlNCR0ZvM0E0Nnh0?=
 =?utf-8?B?Q29BN1ptTVdOMkkzc0NQMVhYVU9sbWhCSWhRYVFuME4xcnloMW1kYUcwajJU?=
 =?utf-8?Q?+2QZ1Ky3YrvkwSysCf?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: valinux.co.jp
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 46546a92-ef2a-45f3-142d-08df041edfc8
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2026 09:37:55.9322
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fb96r6eWnViosIRpdqLYOcA1ZYsMk8PpMHqs+I3fW5nx++AbObIq5Xljg1AosZImd1L9HBncoIQxBwZlIyiE+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY7P286MB6497
X-purgate-ID: tlsNG-d25034/1787823481-778D5A5B-12D32622/0/0
X-purgate-type: clean
X-purgate-size: 17248

SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3IGFuZCBmb3Ig
aGFuZGxpbmcgdGhlIHJlbWFpbmluZyBtaW5vciBmaXhlcyBvbiBjb21taXQhDQoNClRoYW5rIHlv
dSwsDQpIaXJva2F6dSBUYWthaGFzaGkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiBGcm9tOiBPcnplbCwgTWljaGFsIDxtaWNoYWwub3J6ZWxAYW1kLmNvbT4NCj4gU2VudDogVGh1
cnNkYXksIEF1Z3VzdCAyNywgMjAyNiA1OjA2IFBNDQo+IFRvOiBIaXJva2F6dSBUYWthaGFzaGkg
PHRha2FAdmFsaW51eC5jby5qcD47IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBD
YzogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPjsgSnVsaWVuIEdy
YWxsIDxqdWxpZW5AeGVuLm9yZz47DQo+IEJlcnRyYW5kIE1hcnF1aXMgPGJlcnRyYW5kLm1hcnF1
aXNAYXJtLmNvbT47IFZvbG9keW15ciBCYWJjaHVrDQo+IDxWb2xvZHlteXJfQmFiY2h1a0BlcGFt
LmNvbT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBBbnRo
b255IFBFUkFSRA0KPiA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IEphbiBCZXVsaWNoIDxq
YmV1bGljaEBzdXNlLmNvbT47IFJvZ2VyIFBhdQ0KPiBNb25uw6kgPHJvZ2VyQHhlbnByb2plY3Qu
b3JnPg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHY0XSB4ZW4vYXJtOiBIaWRlIFBNVSByZWdpc3Rl
cnMgZnJvbSB0aGUgZ3Vlc3QsIHdoZW4gdGhlDQo+IHZQTVUgZmVhdHVyZSBpcyBkaXNhYmxlZC4N
Cj4gDQo+IA0KPiANCj4gT24gMjYtQXVnLTI2IDEyOjU1LCBIaXJva2F6dSBUYWthaGFzaGkgd3Jv
dGU6DQo+ID4gT24gQVJNdjguNC1BIGFuZCBuZXdlciBwbGF0Zm9ybXMsIGJvb3RpbmcgRG9tMCBM
aW51eCB3aXRoIEFDUEkgZW5hYmxlZA0KPiA+IGNhdXNlcyB0aGUgZG9tYWluIHRvIHByb2JlIGFk
dmFuY2VkIFBNVSBmZWF0dXJlIGJhc2VkIG9uIHN5c3RlbSBJRA0KPiA+IHJlZ2lzdGVyIElEX0FB
NjRERlIwX0VMMS4gRHVyaW5nIHRoaXMgcHJvYmUsIExpbnV4IGFjY2Vzc2VzIFBNTUlSX0VMMSwN
Cj4gPiB3aGljaCBjYXVzZXMgdW5oYW5kbGVkIHJlZ2lzdGVyIHRyYXBzIGFuZCBjcmFzaGVzIHRo
ZSBkb21haW4uDQo+ID4NCj4gPiBUbyBhZGRyZXNzIHRoaXMgaXNzdWUsIGltcGxlbWVudCB0aGUg
Zm9sbG93aW5nOg0KPiA+DQo+ID4gLSBBZGQgZW11bGF0aW9uIGZvciBJRF9BQTY0REZSezAsMX1f
RUwxLCBJRF9ERlJ7MCwxfV9FTDEgYW5kDQo+ID4gICBJRF9ERlJ7MCwxfSByZWdpc3RlciBhY2Nl
c3NlcyBmb3IgZ3Vlc3QgZG9tYWlucy4NCj4gPiAtIEhpZGUgUE1VIHJlZ2lzdGVycyBmcm9tIGEg
Z3Vlc3QgZG9tYWluIHdoZW4gaXRzIHZQTVUgZmVhdHVyZSBpcw0KPiA+ICAgZGlzYWJsZWQuDQo+
ID4gLSBQcm9hY3RpdmVseSBtYWtlIFNQRSwgVFJCRSwgQlJCRSwgVHJhY2UgRXh0ZW5zaW9ucywg
U1BNVSwgSVRFIGFuZA0KPiA+ICAgRUJFUCBpbmFjY2Vzc2libGUgdG8gYXJtNjQgZ3Vlc3QgZG9t
YWlucyBhbmQgaGlkZSBUcmFjZUZpbHQsDQo+ID4gICBNTWFwVHJjIGFuZCBDb3BUcmMgdG8gYXJt
MzIgZ3Vlc3QgZG9tYWlucywgYXMgdGhleSBjb3VsZA0KPiA+ICAgcG90ZW50aWFsbHkgY2F1c2Ug
c2ltaWxhciBpc3N1ZXMuDQo+ID4NCj4gPiBGaXhlczogZGJiOTQ4MTEwYTBlICgieGVuOiBFeHBv
c2UgdGhlIFBNVSB0byB0aGUgZ3Vlc3RzIikNCj4gPiBGaXhlczogMDdiOWFjZWExMTZlICgieGVu
L2FybTogQWRkIGhhbmRsZXIgZm9yIElEIHJlZ2lzdGVycyBvbiBhcm02NCIpDQo+ID4gRml4ZXM6
IDM2NjlhMWNiOTU5OCAoInhlbi9hcm06IGNyZWF0ZSBhIGNwdWluZm8gc3RydWN0dXJlIGZvciBn
dWVzdCIpDQo+ID4gU2lnbmVkLW9mZi1ieTogSGlyb2thenUgVGFrYWhhc2hpIDx0YWthQHZhbGlu
dXguY28uanA+DQo+ID4gLS0tDQo+ID4gQ2hhbmdlcyBpbiB2NDoNCj4gPiAgKiBIaWRlIEZFQVRf
SFBNTjAgZnJvbSBndWVzdHMgd2hlbiB0aGUgdlBNVSBmZWF0dXJlIGlzIGRpc2FibGVkLg0KPiA+
ICAqIFVuY29uZGl0aW9uYWxseSBoaWRlIEZFQVRfU1BNVSBhbmQgRkVBVF9FQkVQIGZyb20gZ3Vl
c3QgZG9tYWlucy4NCj4gPiAgKiBGaXggYXJtMzIgYnVpbGQgZmFpbHVyZSBpbiB2Y3ByZWcuYy4N
Cj4gPiAgKiBQZXJmb3JtIGNvZGUgY2xlYW51cHMgYW5kIGFkZHJlc3MgY29kaW5nIHN0eWxlIGZl
ZWRiYWNrLg0KPiA+DQo+ID4gIHhlbi9hcmNoL2FybS9hcm02NC92c3lzcmVnLmMgICAgICAgICAg
fCA2Mg0KPiArKysrKysrKysrKysrKysrKysrKysrKysrLS0NCj4gPiAgeGVuL2FyY2gvYXJtL2Nw
dWZlYXR1cmUuYyAgICAgICAgICAgICB8IDE3ICsrKysrKysrDQo+ID4gIHhlbi9hcmNoL2FybS9k
b21haW4uYyAgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiA+ICB4ZW4vYXJjaC9hcm0vaW5jbHVk
ZS9hc20vYXJtNjQvaHNyLmggIHwgIDEgKw0KPiA+ICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v
Y3ByZWdzLmggICAgIHwgIDEgKw0KPiA+ICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vY3B1ZmVh
dHVyZS5oIHwgMjcgKysrKysrKysrLS0tDQo+ID4gIHhlbi9hcmNoL2FybS92Y3ByZWcuYyAgICAg
ICAgICAgICAgICAgfCAyOSArKysrKysrKysrKystDQo+ID4gIHhlbi9pbmNsdWRlL3hlbi9zY2hl
ZC5oICAgICAgICAgICAgICAgfCAgNSArKysNCj4gPiAgOCBmaWxlcyBjaGFuZ2VkLCAxMzAgaW5z
ZXJ0aW9ucygrKSwgMTQgZGVsZXRpb25zKC0pDQo+ID4NCj4gPiBkaWZmIC0tZ2l0IGEveGVuL2Fy
Y2gvYXJtL2FybTY0L3ZzeXNyZWcuYw0KPiBiL3hlbi9hcmNoL2FybS9hcm02NC92c3lzcmVnLmMN
Cj4gPiBpbmRleCBkOWUzNjE5ZGZiLi5iZjYxMmExMzNkIDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9h
cmNoL2FybS9hcm02NC92c3lzcmVnLmMNCj4gPiArKysgYi94ZW4vYXJjaC9hcm0vYXJtNjQvdnN5
c3JlZy5jDQo+ID4gQEAgLTIyNyw2ICsyMjcsNyBAQCB2b2lkIGRvX3N5c3JlZyhzdHJ1Y3QgY3B1
X3VzZXJfcmVncyAqcmVncywNCj4gPiAgICAgICAqLw0KPiA+ICAgICAgY2FzZSBIU1JfU1lTUkVH
X1BNSU5URU5TRVRfRUwxOg0KPiA+ICAgICAgY2FzZSBIU1JfU1lTUkVHX1BNSU5URU5DTFJfRUwx
Og0KPiA+ICsgICAgY2FzZSBIU1JfU1lTUkVHX1BNTUlSX0VMMToNCj4gPiAgICAgICAgICByZXR1
cm4gaGFuZGxlX3Jhel93aShyZWdzLCByZWdpZHgsIGhzci5zeXNyZWcucmVhZCwgaHNyLCAxKTsN
Cj4gPiAgICAgIGNhc2UgSFNSX1NZU1JFR19QTVVTRVJFTlJfRUwwOg0KPiA+ICAgICAgICAgIC8q
IFJPIGF0IEVMMC4gUkFaL1dJIGF0IEVMMSAqLw0KPiA+IEBAIC0zMDAsOCArMzAxLDMyIEBAIHZv
aWQgZG9fc3lzcmVnKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzLA0KPiA+ICAgICAgR0VORVJB
VEVfVElEM19JTkZPKElEX1BGUjBfRUwxLCBwZnIzMiwgMCkNCj4gPiAgICAgIEdFTkVSQVRFX1RJ
RDNfSU5GTyhJRF9QRlIxX0VMMSwgcGZyMzIsIDEpDQo+ID4gICAgICBHRU5FUkFURV9USUQzX0lO
Rk8oSURfUEZSMl9FTDEsIHBmcjMyLCAyKQ0KPiA+IC0gICAgR0VORVJBVEVfVElEM19JTkZPKElE
X0RGUjBfRUwxLCBkYmczMiwgMCkNCj4gPiAtICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9ERlIx
X0VMMSwgZGJnMzIsIDEpDQo+ID4gKw0KPiA+ICsgICAgY2FzZSBIU1JfU1lTUkVHX0lEX0RGUjBf
RUwxOg0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIHVuaW9uIGNwdWluZm9fZGJnMzIgaW5mb19k
YmczMiA9IGRvbWFpbl9jcHVpbmZvLmRiZzMyOw0KPiA+ICsNCj4gPiArICAgICAgICBpZiAoICFp
c192cG11X2RvbWFpbih2LT5kb21haW4pICkNCj4gPiArICAgICAgICAgICAgaW5mb19kYmczMi5w
ZXJmbW9uID0gMDsNCj4gPiArDQo+ID4gKyAgICAgICAgcmV0dXJuIGhhbmRsZV9yb19yZWFkX3Zh
bChyZWdzLCByZWdpZHgsIGhzci5zeXNyZWcucmVhZCwgaHNyLCAxLA0KPiA+ICsgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaW5mb19kYmczMi5iaXRzWzBdKTsNCj4gPiArICAgIH0N
Cj4gPiArDQo+ID4gKyAgICBjYXNlIEhTUl9TWVNSRUdfSURfREZSMV9FTDE6DQo+ID4gKyAgICB7
DQo+ID4gKyAgICAgICAgdW5pb24gY3B1aW5mb19kYmczMiBpbmZvX2RiZzMyID0gZG9tYWluX2Nw
dWluZm8uZGJnMzI7DQo+ID4gKw0KPiA+ICsgICAgICAgIGlmICggIWlzX3ZwbXVfZG9tYWluKHYt
PmRvbWFpbikgKQ0KPiA+ICsgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgaW5mb19kYmczMi5t
dHBtdSA9IDA7DQo+ID4gKyAgICAgICAgICAgIGluZm9fZGJnMzIuaHBtbjAgPSAwOw0KPiA+ICsg
ICAgICAgIH0NCj4gPiArDQo+ID4gKyAgICAgICAgcmV0dXJuIGhhbmRsZV9yb19yZWFkX3ZhbChy
ZWdzLCByZWdpZHgsIGhzci5zeXNyZWcucmVhZCwgaHNyLCAxLA0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaW5mb19kYmczMi5iaXRzWzFdKTsNCj4gPiArICAgIH0NCj4g
PiArDQo+ID4gICAgICBHRU5FUkFURV9USUQzX0lORk8oSURfQUZSMF9FTDEsIGF1eDMyLCAwKQ0K
PiA+ICAgICAgR0VORVJBVEVfVElEM19JTkZPKElEX01NRlIwX0VMMSwgbW0zMiwgMCkNCj4gPiAg
ICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9NTUZSMV9FTDEsIG1tMzIsIDEpDQo+ID4gQEAgLTM0
Miw4ICszNjcsMzcgQEAgdm9pZCBkb19zeXNyZWcoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3Ms
DQo+ID4gICAgICB9DQo+ID4NCj4gPiAgICAgIEdFTkVSQVRFX1RJRDNfSU5GTyhJRF9BQTY0UEZS
MV9FTDEsIHBmcjY0LCAxKQ0KPiA+IC0gICAgR0VORVJBVEVfVElEM19JTkZPKElEX0FBNjRERlIw
X0VMMSwgZGJnNjQsIDApDQo+ID4gLSAgICBHRU5FUkFURV9USUQzX0lORk8oSURfQUE2NERGUjFf
RUwxLCBkYmc2NCwgMSkNCj4gPiArDQo+ID4gKyAgICBjYXNlIEhTUl9TWVNSRUdfSURfQUE2NERG
UjBfRUwxOg0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIHVuaW9uIGNwdWluZm9fZGJnNjQgaW5m
b19kYmc2NCA9IGRvbWFpbl9jcHVpbmZvLmRiZzY0Ow0KPiA+ICsNCj4gPiArICAgICAgICBpZiAo
ICFpc192cG11X2RvbWFpbih2LT5kb21haW4pICkNCj4gPiArICAgICAgICB7DQo+ID4gKyAgICAg
ICAgICAgIGluZm9fZGJnNjQucG11X3ZlciA9IDA7DQo+ID4gKyAgICAgICAgICAgIGluZm9fZGJn
NjQucG1zcyA9IDA7DQo+ID4gKyAgICAgICAgICAgIGluZm9fZGJnNjQubXRwbXUgPSAwOw0KPiA+
ICsgICAgICAgICAgICBpbmZvX2RiZzY0LmhwbW4wID0gMDsNCj4gPiArICAgICAgICB9DQo+ID4g
Kw0KPiA+ICsgICAgICAgIHJldHVybiBoYW5kbGVfcm9fcmVhZF92YWwocmVncywgcmVnaWR4LCBo
c3Iuc3lzcmVnLnJlYWQsIGhzciwgMSwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGluZm9fZGJnNjQuYml0c1swXSk7DQo+ID4gKyAgICB9DQo+ID4gKw0KPiA+ICsgICAg
Y2FzZSBIU1JfU1lTUkVHX0lEX0FBNjRERlIxX0VMMToNCj4gPiArICAgIHsNCj4gPiArICAgICAg
ICB1bmlvbiBjcHVpbmZvX2RiZzY0IGluZm9fZGJnNjQgPSBkb21haW5fY3B1aW5mby5kYmc2NDsN
Cj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCAhaXNfdnBtdV9kb21haW4odi0+ZG9tYWluKSApDQo+
ID4gKyAgICAgICAgew0KPiA+ICsgICAgICAgICAgICBpbmZvX2RiZzY0LnBtaWNudHIgPSAwOw0K
PiA+ICsgICAgICAgICAgICBpbmZvX2RiZzY0LmRwZnpzID0gMDsNCj4gRkVBVF9TUEVfRFBGWlMg
ZGVwZW5kcyBvbiBTUEUsIGFuZCB5b3UgYWxyZWFkeSBjbGVhciBwbXNfdmVyLiBNb3ZlIGl0DQo+
IG5leHQgdG8NCj4gY2xlYXJpbmcgcG1zX3Zlci4NCj4gDQo+ID4gKyAgICAgICAgfQ0KPiA+ICsN
Cj4gPiArICAgICAgICByZXR1cm4gaGFuZGxlX3JvX3JlYWRfdmFsKHJlZ3MsIHJlZ2lkeCwgaHNy
LnN5c3JlZy5yZWFkLCBoc3IsIDEsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbmZvX2RiZzY0LmJpdHNbMV0pOw0KPiA+ICsgICAgfQ0KPiA+ICsNCj4gPiAgICAgIEdF
TkVSQVRFX1RJRDNfSU5GTyhJRF9BQTY0SVNBUjBfRUwxLCBpc2E2NCwgMCkNCj4gPiAgICAgIEdF
TkVSQVRFX1RJRDNfSU5GTyhJRF9BQTY0SVNBUjFfRUwxLCBpc2E2NCwgMSkNCj4gPiAgICAgIEdF
TkVSQVRFX1RJRDNfSU5GTyhJRF9BQTY0TU1GUjBfRUwxLCBtbTY0LCAwKQ0KPiA+IGRpZmYgLS1n
aXQgYS94ZW4vYXJjaC9hcm0vY3B1ZmVhdHVyZS5jIGIveGVuL2FyY2gvYXJtL2NwdWZlYXR1cmUu
Yw0KPiA+IGluZGV4IDk0ZDE0ZmI2YTkuLjg4NDc4ZmVhNDYgMTAwNjQ0DQo+ID4gLS0tIGEveGVu
L2FyY2gvYXJtL2NwdWZlYXR1cmUuYw0KPiA+ICsrKyBiL3hlbi9hcmNoL2FybS9jcHVmZWF0dXJl
LmMNCj4gPiBAQCAtMjE5LDggKzIxOSwyNSBAQCBzdGF0aWMgaW50IF9faW5pdCBjcmVhdGVfZG9t
YWluX2NwdWluZm8odm9pZCkNCj4gPiAgICAgIGRvbWFpbl9jcHVpbmZvLmlzYTY0LmFwaSA9IDA7
DQo+ID4gICAgICBkb21haW5fY3B1aW5mby5pc2E2NC5ncGEgPSAwOw0KPiA+ICAgICAgZG9tYWlu
X2NwdWluZm8uaXNhNjQuZ3BpID0gMDsNCj4gPiArDQo+ID4gKyAgICAvKiBIaWRlIFNQRSwgVFJC
RSwgQlJCRSwgVHJhY2UgRXh0ZW5zaW9ucywgU1BNVSwgSVRFIGFuZCBFQkVQICovDQo+ID4gKyAg
ICBkb21haW5fY3B1aW5mby5kYmc2NC50cmFjZV92ZXIgPSAwOw0KPiA+ICsgICAgZG9tYWluX2Nw
dWluZm8uZGJnNjQucG1zX3ZlciA9IDA7DQo+ID4gKyAgICBkb21haW5fY3B1aW5mby5kYmc2NC50
cmFjZV9maWx0ID0gMDsNCj4gPiArICAgIGRvbWFpbl9jcHVpbmZvLmRiZzY0LnRyYWNlX2J1ZmZl
ciA9IDA7DQo+ID4gKyAgICBkb21haW5fY3B1aW5mby5kYmc2NC5leHRfdHJjX2J1ZmYgPSAwOw0K
PiA+ICsgICAgZG9tYWluX2NwdWluZm8uZGJnNjQuYnJiZSA9IDA7DQo+ID4gKyAgICBkb21haW5f
Y3B1aW5mby5kYmc2NC5zeXNwbXVpZCA9IDA7DQo+ID4gKyAgICBkb21haW5fY3B1aW5mby5kYmc2
NC5zcG11ID0gMDsNCj4gPiArICAgIGRvbWFpbl9jcHVpbmZvLmRiZzY0Lml0ZSA9IDA7DQo+ID4g
KyAgICBkb21haW5fY3B1aW5mby5kYmc2NC5lYmVwID0gMDsNCj4gPiAgI2VuZGlmDQo+ID4NCj4g
PiArICAgIC8qIEhpZGUgVHJhY2UgRXh0ZW5zaW9ucyBmb3IgQUFyY2gzMiBkb21haW4gKi8NCj4g
PiArICAgIGRvbWFpbl9jcHVpbmZvLmRiZzMyLmNvcHRyYyA9IDA7DQo+ID4gKyAgICBkb21haW5f
Y3B1aW5mby5kYmczMi5tbWFwdHJjID0gMDsNCj4gPiArICAgIGRvbWFpbl9jcHVpbmZvLmRiZzMy
LnRyYWNlZmlsdCA9IDA7DQo+ID4gKw0KPiA+ICAgICAgLyogSGlkZSBBTVUgc3VwcG9ydCAqLw0K
PiA+ICAjaWZkZWYgQ09ORklHX0FSTV82NA0KPiA+ICAgICAgZG9tYWluX2NwdWluZm8ucGZyNjQu
YW11ID0gMDsNCj4gPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbWFpbi5jIGIveGVuL2Fy
Y2gvYXJtL2RvbWFpbi5jDQo+ID4gaW5kZXggYmFhM2E1ZDcwOC4uYTczOWRkMTU3ZSAxMDA2NDQN
Cj4gPiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluLmMNCj4gPiArKysgYi94ZW4vYXJjaC9hcm0v
ZG9tYWluLmMNCj4gPiBAQCAtNTAxLDcgKzUwMSw3IEBAIGludCBhcmNoX3ZjcHVfY3JlYXRlKHN0
cnVjdCB2Y3B1ICp2KQ0KPiA+ICAgICAgdi0+YXJjaC5oY3JfZWwyID0gZ2V0X2RlZmF1bHRfaGNy
X2ZsYWdzKCk7DQo+ID4NCj4gPiAgICAgIHYtPmFyY2gubWRjcl9lbDIgPSBIRENSX1REUkEgfCBI
RENSX1RET1NBIHwgSERDUl9UREE7DQo+ID4gLSAgICBpZiAoICEodi0+ZG9tYWluLT5vcHRpb25z
ICYgWEVOX0RPTUNUTF9DREZfdnBtdSkgKQ0KPiA+ICsgICAgaWYgKCAhaXNfdnBtdV9kb21haW4o
di0+ZG9tYWluKSApDQo+ID4gICAgICAgICAgdi0+YXJjaC5tZGNyX2VsMiB8PSBIRENSX1RQTSB8
IEhEQ1JfVFBNQ1I7DQo+ID4NCj4gPiAgICAgIGlmICggKHJjID0gdmNwdV92Z2ljX2luaXQodikp
ICE9IDAgKQ0KPiA+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJtNjQv
aHNyLmgNCj4gYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYXJtNjQvaHNyLmgNCj4gPiBpbmRl
eCAxNDk1Y2NkZGVhLi5lZDE4MTg0Y2M3IDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9hcmNoL2FybS9p
bmNsdWRlL2FzbS9hcm02NC9oc3IuaA0KPiA+ICsrKyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2Fz
bS9hcm02NC9oc3IuaA0KPiA+IEBAIC04NCw2ICs4NCw3IEBADQo+ID4gICNkZWZpbmUgSFNSX1NZ
U1JFR19GQVJfRUwxICAgICAgICBIU1JfU1lTUkVHKDMsMCxjNiwgYzAsMCkNCj4gPiAgI2RlZmlu
ZSBIU1JfU1lTUkVHX1BNSU5URU5TRVRfRUwxIEhTUl9TWVNSRUcoMywwLGM5LGMxNCwxKQ0KPiA+
ICAjZGVmaW5lIEhTUl9TWVNSRUdfUE1JTlRFTkNMUl9FTDEgSFNSX1NZU1JFRygzLDAsYzksYzE0
LDIpDQo+ID4gKyNkZWZpbmUgSFNSX1NZU1JFR19QTU1JUl9FTDEgICAgICBIU1JfU1lTUkVHKDMs
MCxjOSxjMTQsNikNCj4gPiAgI2RlZmluZSBIU1JfU1lTUkVHX01BSVJfRUwxICAgICAgIEhTUl9T
WVNSRUcoMywwLGMxMCxjMiwwKQ0KPiA+ICAjZGVmaW5lIEhTUl9TWVNSRUdfQU1BSVJfRUwxICAg
ICAgSFNSX1NZU1JFRygzLDAsYzEwLGMzLDApDQo+ID4gICNkZWZpbmUgSFNSX1NZU1JFR19JQ0Nf
U0dJMVJfRUwxICBIU1JfU1lTUkVHKDMsMCxjMTIsYzExLDUpDQo+ID4gZGlmZiAtLWdpdCBhL3hl
bi9hcmNoL2FybS9pbmNsdWRlL2FzbS9jcHJlZ3MuaA0KPiBiL3hlbi9hcmNoL2FybS9pbmNsdWRl
L2FzbS9jcHJlZ3MuaA0KPiA+IGluZGV4IGE3NTAzYTE5MGYuLjNmNjJiMzhkYzAgMTAwNjQ0DQo+
ID4gLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2NwcmVncy5oDQo+ID4gKysrIGIveGVu
L2FyY2gvYXJtL2luY2x1ZGUvYXNtL2NwcmVncy5oDQo+ID4gQEAgLTI0Niw2ICsyNDYsNyBAQA0K
PiA+ICAjZGVmaW5lIFBNSU5URU5TRVQgICAgICBwMTUsMCxjOSxjMTQsMSAgLyogUGVyZi4gTW9u
LiBJbnRlcnJ1cHQgRW5hYmxlDQo+IFNldCBSZWdpc3RlciAqLw0KPiA+ICAjZGVmaW5lIFBNSU5U
RU5DTFIgICAgICBwMTUsMCxjOSxjMTQsMiAgLyogUGVyZi4gTW9uLiBJbnRlcnJ1cHQgRW5hYmxl
DQo+IENsZWFyIFJlZ2lzdGVyICovDQo+ID4gICNkZWZpbmUgUE1PVlNTRVQgICAgICAgIHAxNSww
LGM5LGMxNCwzICAvKiBQZXJmLiBNb24uIE92ZXJmbG93IEZsYWcNCj4gU3RhdHVzIFNldCByZWdp
c3RlciAqLw0KPiA+ICsjZGVmaW5lIFBNTUlSICAgICAgICAgICBwMTUsMCxjOSxjMTQsNiAgLyog
UGVyZi4gTW9uLiBNYWNoaW5lDQo+IElkZW50aWZpY2F0aW9uIFJlZ2lzdGVyICovDQo+ID4NCj4g
PiAgLyogQ1AxNSBDUjEwOiAqLw0KPiA+ICAjZGVmaW5lIE1BSVIwICAgICAgICAgICBwMTUsMCxj
MTAsYzIsMCAgLyogTWVtb3J5IEF0dHJpYnV0ZSBJbmRpcmVjdGlvbg0KPiBSZWdpc3RlciAwIEFL
QSBQUlJSICovDQo+ID4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9jcHVm
ZWF0dXJlLmgNCj4gYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vY3B1ZmVhdHVyZS5oDQo+ID4g
aW5kZXggYmY5MDJhMzk3MC4uYzU1NDY4NjQxNSAxMDA2NDQNCj4gPiAtLS0gYS94ZW4vYXJjaC9h
cm0vaW5jbHVkZS9hc20vY3B1ZmVhdHVyZS5oDQo+ID4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1
ZGUvYXNtL2NwdWZlYXR1cmUuaA0KPiA+IEBAIC0yMDgsNyArMjA4LDcgQEAgc3RydWN0IGNwdWlu
Zm9fYXJtIHsNCj4gPiAgICAgICAgICB9Ow0KPiA+ICAgICAgfSBwZnI2NDsNCj4gPg0KPiA+IC0g
ICAgdW5pb24gew0KPiA+ICsgICAgdW5pb24gY3B1aW5mb19kYmc2NCB7DQo+ID4gICAgICAgICAg
cmVnaXN0ZXJfdCBiaXRzWzJdOw0KPiA+ICAgICAgICAgIHN0cnVjdCB7DQo+ID4gICAgICAgICAg
ICAgIC8qIERGUjAgKi8NCj4gPiBAQCAtMjE2LDE5ICsyMTYsMzEgQEAgc3RydWN0IGNwdWluZm9f
YXJtIHsNCj4gPiAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyB0cmFjZV92ZXI6NDsNCj4gPiAg
ICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBwbXVfdmVyOjQ7DQo+ID4gICAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgYnJwczo0Ow0KPiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVz
MDo0Ow0KPiA+ICsgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBtc3M6NDsNCj4gPiAgICAgICAg
ICAgICAgdW5zaWduZWQgbG9uZyB3cnBzOjQ7DQo+ID4gICAgICAgICAgICAgIHVuc2lnbmVkIGxv
bmcgX19yZXMxOjQ7DQo+ID4gICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgY3R4X2NtcHM6NDsN
Cj4gPiAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBwbXNfdmVyOjQ7DQo+ID4gICAgICAgICAg
ICAgIHVuc2lnbmVkIGxvbmcgZG91YmxlX2xvY2s6NDsNCj4gPiAgICAgICAgICAgICAgdW5zaWdu
ZWQgbG9uZyB0cmFjZV9maWx0OjQ7DQo+ID4gLSAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgX19y
ZXMyOjQ7DQo+ID4gKyAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdHJhY2VfYnVmZmVyOjQ7DQo+
ID4gICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgbXRwbXU6NDsNCj4gPiAtICAgICAgICAgICAg
dW5zaWduZWQgbG9uZyBfX3JlczM6MTI7DQo+ID4gKyAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcg
YnJiZTo0Ow0KPiA+ICsgICAgICAgICAgICB1bnNpZ25lZCBsb25nIGV4dF90cmNfYnVmZjo0Ow0K
PiA+ICsgICAgICAgICAgICB1bnNpZ25lZCBsb25nIGhwbW4wOjQ7DQo+ID4NCj4gPiAgICAgICAg
ICAgICAgLyogREZSMSAqLw0KPiA+IC0gICAgICAgICAgICB1bnNpZ25lZCBsb25nIF9fcmVzNDo2
NDsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBzeXNwbXVpZDo4Ow0KPiA+ICsgICAg
ICAgICAgICB1bnNpZ25lZCBsb25nIGJycHMxOjg7DQo+ID4gKyAgICAgICAgICAgIHVuc2lnbmVk
IGxvbmcgd3JwczE6ODsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBjdHhfY21wczE6
ODsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBzcG11OjQ7DQo+ID4gKyAgICAgICAg
ICAgIHVuc2lnbmVkIGxvbmcgcG1pY250cjo0Ow0KPiA+ICsgICAgICAgICAgICB1bnNpZ25lZCBs
b25nIGFibGU6NDsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBpdGU6NDsNCj4gPiAr
ICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBlYmVwOjQ7DQo+ID4gKyAgICAgICAgICAgIHVuc2ln
bmVkIGxvbmcgZHBmenM6NDsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBhYmxfY21w
czo4Ow0KPiA+ICAgICAgICAgIH07DQo+ID4gICAgICB9IGRiZzY0Ow0KPiA+DQo+ID4gQEAgLTQw
OCw3ICs0MjAsNyBAQCBzdHJ1Y3QgY3B1aW5mb19hcm0gew0KPiA+ICAgICAgICAgIH07DQo+ID4g
ICAgICB9IHBmcjMyOw0KPiA+DQo+ID4gLSAgICB1bmlvbiB7DQo+ID4gKyAgICB1bmlvbiBjcHVp
bmZvX2RiZzMyIHsNCj4gPiAgICAgICAgICByZWdpc3Rlcl90IGJpdHNbMl07DQo+ID4gICAgICAg
ICAgc3RydWN0IHsNCj4gPiAgICAgICAgICAgICAgLyogREZSMCAqLw0KPiA+IEBAIC00MjYsNyAr
NDM4LDggQEAgc3RydWN0IGNwdWluZm9fYXJtIHsNCj4gPg0KPiA+ICAgICAgICAgICAgICAvKiBE
RlIxICovDQo+ID4gICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgbXRwbXU6NDsNCj4gPiAtICAg
ICAgICAgICAgdW5zaWduZWQgbG9uZyBfX3JlczE6Mjg7DQo+ID4gKyAgICAgICAgICAgIHVuc2ln
bmVkIGxvbmcgaHBtbjA6NDsNCj4gPiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBfX3JlczE6
MjQ7DQo+ID4gICNpZmRlZiBDT05GSUdfQVJNXzY0DQo+ID4gICAgICAgICAgICAgIHVuc2lnbmVk
IGxvbmcgX19yZXMyOjMyOw0KPiA+ICAjZW5kaWYNCj4gPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gv
YXJtL3ZjcHJlZy5jIGIveGVuL2FyY2gvYXJtL3ZjcHJlZy5jDQo+ID4gaW5kZXggMzIwNWM3ZGY0
Ni4uZGI4OTA5ZDk2ZSAxMDA2NDQNCj4gPiAtLS0gYS94ZW4vYXJjaC9hcm0vdmNwcmVnLmMNCj4g
PiArKysgYi94ZW4vYXJjaC9hcm0vdmNwcmVnLmMNCj4gPiBAQCAtMjkyLDYgKzI5Miw3IEBAIHZv
aWQgZG9fY3AxNV8zMihzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncywgY29uc3QNCj4gdW5pb24g
aHNyIGhzcikNCj4gPiAgICAgICAgICAgICAgcmV0dXJuIGhhbmRsZV9yYXpfd2kocmVncywgcmVn
aWR4LCBjcDMyLnJlYWQsIGhzciwgMSk7DQo+ID4gICAgICBjYXNlIEhTUl9DUFJFRzMyKFBNSU5U
RU5TRVQpOg0KPiA+ICAgICAgY2FzZSBIU1JfQ1BSRUczMihQTUlOVEVOQ0xSKToNCj4gPiArICAg
IGNhc2UgSFNSX0NQUkVHMzIoUE1NSVIpOg0KPiBUaGVyZSdzIGEgY29tbWVudCBhYm92ZSB0aGlz
IGJsb2NrIHRoYXQgd2UgZG9uJ3QgdHJhcCBJRF9ERlIwIHdoaWNoIGlzIG5vdA0KPiB0cnVlLg0K
PiBJdCBzaG91bGQgYmUgZHJvcHBlZCBhcyBwYXJ0IG9mIHRoaXMgcGF0Y2guDQo+IA0KPiBJJ2xs
IGRvIHRoZSBmaXhlcyBvbiBjb21taXQuIFRoYW5rcyBmb3IgdGhlIHBhdGNoLg0KPiANCj4gUmV2
aWV3ZWQtYnk6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQo+IA0KPiB+TWlj
aGFsDQo=


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:38:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:38:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400447.1636104 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYj-0002eC-E4; Thu, 27 Aug 2026 09:38:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400447.1636104; Thu, 27 Aug 2026 09:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYj-0002e2-9w; Thu, 27 Aug 2026 09:38:09 +0000
Received: by outflank-mailman (input) for mailman id 1400447;
 Thu, 27 Aug 2026 09:38:07 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Sergiy_Kibrik@epam.com>) id 1wzWYh-0002d7-LH
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:38:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWYh-002LkA-21
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:38:07 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a90057f-bab6-0a2a0a5309dd-0a2a450ca456-0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:07 +0200
Received: from [40.107.130.73]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a90057c-f479-0a2a450c0019-286b82493340-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:06 +0200
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AS2PR03MB9562.eurprd03.prod.outlook.com (2603:10a6:20b:599::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.8; Thu, 27 Aug
 2026 09:38:01 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0360.006; Thu, 27 Aug 2026
 09:38:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=f+t5lHy6xG6wsH2yuZzIWRr3r8a4KiPkFT4LUPIcWT0HcJrqNNbETq3vy+ZD+Prg0AkD3QrmY+/qZeoGcwBqlx0PBjBUR4zl0KmZXVrdBkra+rMVmEuPdbStG+dwqVxnP9YVff9MqRYNSnihPfNSqQHoQEieHOOV6zfe/6r8S9SQgmZb+dRe1mIPqphDt4RGwDNmu0onk0w6F3LtoRoVZEe+n+pcDy5A62fOwapvTi0xCSW8hxqDiju9cUYHPLpIpOgeaW2+UuMZwryvKDD1eqaqu0IAvkD9KbZe7oYXqZwXFpqmqxpMxg0+misEjFBliN5eAJp2V4c67ghWPLyVQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SgziTV3hVaV5ve/1Bw1hIfKe/GnHCsU5TuUVeBnQKfQ=;
 b=GQ3Yp6yRtDOqgKOvqCVI8JEFhAGf3qElRpzIpDi2ppaZjtQmZ8g4k5npm4nAzJ14vBJ3IqAc5FFS1fGAnYHlegUeunKuXREcnEZ6YgBw2Qr6TYttGOAlM17hCytKhR5K555QX6pZVoiKcE576JwpboJXzUjMbS6fTeQMKdphxuLBFB4vgFg8B5JMwbU3izBcViTsdBmQuE9zWO69vO6sWmie+Gz9fGckooijFzgHDX2L3T2WoQ4p6bQ2AcIACsZiG6UGdYw0/nqkfoeCdmV28FmbTyyamnXxRxpi7scuw+tOQl8IJ0mex1qRTWE6jtnMf8Umx7eFpLOzThNEKrk8yA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SgziTV3hVaV5ve/1Bw1hIfKe/GnHCsU5TuUVeBnQKfQ=;
 b=i+WAeEYh6m5hoshdVQ0IDM4iV5NesisBkkLZG4snoYayVIqFxGz8Adhz2YJiUyvhlQS0aadrK1k77g1RVVr3Xewq9eKvLG6nyg5vkuI8QFL67HXZy+xUlYjJgAKjOniTgUULUCaMys11AnsCDatGxAZeG0M8ejWNKTvpxu+RydsVMupWJ7PMxal/eP4Y84QIrrNwaPvytmulJo0t3/SXxrz2nCXEAPLKI2ZbSgHokFfh9uau/xSKFMQlXFSigbffq9LFC/ox1sAZNQxHyiAtzXgZk0q+/9DTF0FzVphgNPDlWLG5uS5hkVRPH7MbS9m41bdpQVAFwRjn5i22v9oDdg==
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>, Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>
Subject: [PATCH v1 0/2] XSM labels support in dom0less
Thread-Topic: [PATCH v1 0/2] XSM labels support in dom0less
Thread-Index: AQHdNgfA1drElJutwEqAemyOuAaNVg==
Date: Thu, 27 Aug 2026 09:38:00 +0000
Message-ID: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|AS2PR03MB9562:EE_
x-ms-office365-filtering-correlation-id: f631fe75-9492-4d0f-c06b-08df041ee2b5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|38070700021|11063799006|6133799003|10067099003|56012099006|18002099003;
x-microsoft-antispam-message-info:
 +5yhiouHXzDMuCNkHAVpdoQVMSSKPnmB7t/WkGa4v+3q26WUk5u6sNGd2O9i98g3Tildq82Se4nulf1hf5l+atooSTr2n/smSEfBycRZ62NhBQ1SIJdHjKk/Ws3bT8b7n1lgPL931NvAq454l6XwRDul1leTv3ZcDuXD/CUgamFJYtCmN6RtEy5SzBCBRzvROaLaw3HJpwk6VzuT+TF9plgHIkQEtU/u3d72wREyZ0PvivaKmtib5MficufeitaFQAakjS2uIZ4LbJxXht6K7fCYqabProBrfjO5c2bOp7J/4nhYZkQXwDIrBWLUJQlrhjT9RmEmdbkGGMYiV1NujTAM7V9TSETib4OlwMJHolLsW7PmS6RHymyGL9/SjJpOZ26JWdgK8h/6KAVmhscbdUzxLJMzKef5jaRgvySt7JXxh8PZj8cKe7EhNUmu6X4djuvBnvj4t+DXpp/D92L9+pfRfvx1fEU3xIoRiO7qz3F78z7GLRNCeh3AF36KjfguUcxKSwLv39kLsPbpl+eRd5Z/gPvAYWwoCfLBX5Qi4JeygfLNnTjif8F5tYmZa2QSP+RM2B36yxS/Py6DzFiRrxmqxFawU2jSMyecReEvP71zQozkKbR0gabqGr9lbzliTUj0L4BZTR1aOIIPRenf1IK/owONz0fr2tMMpbFuPQglewDB0JJ2cRaYRMzqLTxdHNA1iDvwXWfHRpIrYx9PkTAzitESwrMFhEQ2Npnil9o=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(38070700021)(11063799006)(6133799003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?V3dNQmJnRGNlTXJyaW9WeTJJZSs2SkhLNEFaWHJIRThnVjloMW40UVFFNWJl?=
 =?utf-8?B?M0lsZFRsaDhPWWpZa20xeDc0WmtHRG0wSHpmc2YzaTlCbkRacnpPWUVtV3NC?=
 =?utf-8?B?cktaY0NjMGdEUXRFQ3FxSk9pUWlwelYzMGtZRFRxMU5YTHRWTThaK3A0a2Q5?=
 =?utf-8?B?d0w4VTdBZk82M25QeHdkTFF0MHVWMDB0UHNPeWcvRzdQK1ZqWVp6WWZUcGZa?=
 =?utf-8?B?dVdDVXcvVDU1SmtEa2toNkZLTnlUSjNialRsUGp6RXhhZi9Xd3NSbG94VmFG?=
 =?utf-8?B?Sm5uaXFDQlZLaXpodVNFV3JzSmxyN1JSUkdISFZVYThrLytsVHpReTVLbVlz?=
 =?utf-8?B?a09UY3JocGpQeWpXeFlrRFl3T2JUb0hnRWxsM0Y2aExpVVUyM0V3eFZpNE1K?=
 =?utf-8?B?UXQ2eUpDZTRHQTArckdwSnZqVnQ1cWcwS0ZZQzREN0VSK3FqR3QxM1lTY0tv?=
 =?utf-8?B?YjVjbHlrZW1WUm14dGE5MEEyNTJMQ2dodjZoRWtCeEVLQ0M3V1E4MjJjQTdO?=
 =?utf-8?B?Y0dYT2Joa2l3aXdCeTFGeDVYazVQcVpOUGpNa291dTlhYkdxSndvQXBwRXVa?=
 =?utf-8?B?K2hxWWpXZXUrU2N2TFppcFJlaXJKOEpHS0pNMzBpZE1xTHhBK1hwdEN1ZHpP?=
 =?utf-8?B?RExVTGVNOUFrV0Q5N2pvZThJeUdvdFJud2t5bmhKdXVlVlQ1bG9iV3dlYk1s?=
 =?utf-8?B?clJYOHg0K24zcytvRkRFdzR6RmdKbEZ6OU01ZG51dDJSUmJlWHhPYUVFUWg1?=
 =?utf-8?B?THJyVmVONFd6VlF4YVhQS0UzckQ4NmFDQXZ5eUZMUDBoL3AxeFR2cGxIUWtI?=
 =?utf-8?B?K2RaOUNEa1RjdHYyT3JhaXNZaTJpZU9tYXZja0pJSUloTlJBWUsxTlc0eGZs?=
 =?utf-8?B?QkJwL1RkYSs5eWVpYUFqb3pjNzQrWEhDUnZXa3ZUblkxaHRaTmM4VzMzcjhm?=
 =?utf-8?B?OXpCY2Q5WUVoOHo0OGE3VlZtMk9zazFvcGNlVDI3dm5oZGRBOGdObGVQb2Fm?=
 =?utf-8?B?NW5YZGhib01UcHZjVHh4NDBxeWtScFRTZHY0R1Jjbkk2S2M5MjdSU3NNYThB?=
 =?utf-8?B?TTl4Y01UekFua2pseW1vNFhNMllRNmFBdUk3eEczZWcvMDNrenRxOFphTFpx?=
 =?utf-8?B?cEpMTGFiT0N6aXV1ckJLTDd4eFFZSldKeWFaMTAvdmFEb24vYXU1YUFnMWFl?=
 =?utf-8?B?ZzBqWFNOU0JDUUNGMTV6c0xQVnJtd3NwMU5oT09ETmRPNEhKMGJMM3lFbXkw?=
 =?utf-8?B?dHlFd3hyYTNaZS9PRjR0dU15SnVPNkJzZHBod1Z5QUVGNWVkWjg0cWVUOTho?=
 =?utf-8?B?TnVrZStFQ1Jwdi9vNU4zYit5b1dIK3JuOW43eGYvMGgyVFNOTzcvNFRPL3Jn?=
 =?utf-8?B?blI2L2NnWEFUK1ZyNnVVTk85aGdXWmJpQlVCVS9iVG9NNDJhWEN4djBpT2NN?=
 =?utf-8?B?UjBZcU95bzdMQnhZQTAxUkNSdlpDWWd2SksvaUxVZ1labitUSS9Gam10T1Fo?=
 =?utf-8?B?cU1CS3BZMG94V1BwUzM4Y3REbEtDK05XVkxlZ01IdDFUNUNlV1VuMjNiUUZ4?=
 =?utf-8?B?OUF4UWVxaHZIUTE1NndvSkZwdGhiTXNSa2JXN2VvMEQ5RUU2VEFWNEJVNjh2?=
 =?utf-8?B?K0VjdmdWVDU5cDZYbnFuRExYL00xV0djdFRkS0d4SzVtcUNSQVF4K1BWcllt?=
 =?utf-8?B?WFlvMGZhQUR2eTJDcXkxRFVETVo3SWNUSDcwWG80MlpvU2dSQWZsK0R0QVJ6?=
 =?utf-8?B?MUxFWTVKMUh2alROR1gvMUZuY1lGUk0xeitFdmlDNWF6SHl1Qm9LaFRSNk01?=
 =?utf-8?B?YzQ2R0NrVzl4Nzl4all1WHpGdm9XQWxPUi9YeEJ1U2RZZHliWnMyK3g4S2ZO?=
 =?utf-8?B?SVJJbGRzQjBDZDIzWnk3WGp1RWRSTHFvb3NWOUg2SFNmUXFpU2ROQTNnV29r?=
 =?utf-8?B?bFhoNks1dHNLUStDZDhPY1gxcnpmM0JWMUk0VDErSXZyUkZHcVZlR0s3eWpq?=
 =?utf-8?B?UFJacVVYb2V3ejBsMnNGeisxa0R2UVJFMHo3NG9kL09mQUJqSDFDT2kzcVB4?=
 =?utf-8?B?VWwrTWVSNG9uS1ExcjNrTkNDdGJHb2l5M3VrZlozMENTb3NDVWsyTzJvT2tk?=
 =?utf-8?B?eXFGdVJ4Vm1JTGF3VkRYZExJNnJjUk1nOW1JbFhLWGVOYlp5RWd3ek50YkNT?=
 =?utf-8?B?aEltNysrWEF0UDVrMXYra3B6SmJRQkw5WHA5aGdtRHFXNEJtd09HMm5UWFgz?=
 =?utf-8?B?dDhQQVl4ZEJjTit6WCsydFR1Q1VTbXZ6SnV0TVZnTEt3c3NsbUwrUFVIVXpM?=
 =?utf-8?B?bStFQ0phaVpsL1F6WjNTUXdtUnZnVWNUR3gwUEZOSm94ZzNJM1g4QT09?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f631fe75-9492-4d0f-c06b-08df041ee2b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2026 09:38:00.8471
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: W/ozBgqlgBpXycrR8Zoi2yepJirdDLQz1Wcj3YoFk6p44iGbBVlhFA/6povdZU+idVlTI5g7cxt83tJKHR6kMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9562
X-purgate-ID: tlsNG-d25034/1787823486-766DEA5B-23656ED2/0/0
X-purgate-type: clean
X-purgate-size: 1492

Q3VycmVudGx5IEZMQVNLIGNhbid0IHJlYWxseSBiZSBlbmZvcmNlZCBmb3IgZG9tYWlucyBiZWlu
ZyBicm91Z2h0IHVwIGluDQpkb20wbGVzcyBtb2RlLCBhcyBzZWN1cml0eSBjb250ZXh0cyBhcmUg
bm90IGFzc2lnbmVkIGZvciBkb21haW5zIGluIHRoaXMNCmNvbmZpZ3VyYXRpb24uIFRodXMgZG9t
YWlucyBhcmUgbGVmdCB3aXRoIGRlZmF1bHQgU0VDSU5JVFNJRF9VTkxBQkVMRUQgU0lEDQp3aGlj
aCBwb2xpY3kgZm9yYmlkcyB0byBjcmVhdGU6DQoNCiAgICAoWEVOKSBbICAgIDAuNjM3Mzc5XSBh
dmM6ICBkZW5pZWQgIHsgY3JlYXRlIH0gZm9yIGN1cnJlbnQ9ZFtJRExFXSBzY29udGV4dD1zeXN0
ZW1fdTpzeXN0ZW1fcjp4ZW5ib290X3QgdGNvbnRleHQ9c3lzdGVtX3U6c3lzdGVtX3I6dW5sYWJl
bGVkX3QgdGNsYXNzPWRvbWFpbg0KDQpUaGlzIHNlcmllcyBleHRlbmRzIGRvbTBsZXNzIGJpbmRp
bmdzIHdpdGggYWJpbGl0eSB0byBwcm92aWRlIGh1bWFuLXJlYWRhYmxlDQpzZWN1cml0eSBjb250
ZXh0IGluIGRvbWFpbidzIERUUyBjb25maWd1cmF0aW9uLCByZXBsaWNhdGluZyBhIHRvb2xzdGFj
aw0KYXBwcm9hY2ggYW5kIG5hbWluZy4NCg0KIC1TZXJnaXkNCg0KU2VyZ2l5IEtpYnJpayAoMik6
DQogIGZsYXNrOiBhZGQgY29uc3QgcXVhbGlmaWVyIHRvIHNlY3VyaXR5X2NvbnRleHRfdG9fc2lk
KCkNCiAgY29tbW9uOiBkb20wbGVzcy1iaW5kaW5nczogaW50cm9kdWNlIFhTTSBsYWJlbHMNCg0K
IGRvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQgICAgICB8ICA4ICsrKysrKysr
DQogeGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9NYWtlZmlsZSAgICAgICAgICAgIHwgIDIgKysNCiB4
ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBsZXNzLWJpbmRpbmdzLmMgfCAxMSArKysrKysrKysr
Kw0KIHhlbi94c20vZmxhc2svaW5jbHVkZS9zZWN1cml0eS5oICAgICAgICAgICB8ICAyICstDQog
eGVuL3hzbS9mbGFzay9zcy9zZXJ2aWNlcy5jICAgICAgICAgICAgICAgIHwgIDIgKy0NCiA1IGZp
bGVzIGNoYW5nZWQsIDIzIGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pDQoNCi0tIA0KMi40
My4wDQo=


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:38:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:38:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400448.1636110 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYj-0002gw-OE; Thu, 27 Aug 2026 09:38:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400448.1636110; Thu, 27 Aug 2026 09:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYj-0002gg-Hl; Thu, 27 Aug 2026 09:38:09 +0000
Received: by outflank-mailman (input) for mailman id 1400448;
 Thu, 27 Aug 2026 09:38:08 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Sergiy_Kibrik@epam.com>) id 1wzWYi-0002dJ-09
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:38:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWYh-002LkA-D4
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:38:07 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a90057f-bab6-0a2a0a5309dd-0a2a450ca456-2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:07 +0200
Received: from [40.107.130.73]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a90057c-f479-0a2a450c0019-286b82493340-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:07 +0200
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AS2PR03MB9562.eurprd03.prod.outlook.com (2603:10a6:20b:599::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.8; Thu, 27 Aug
 2026 09:38:01 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0360.006; Thu, 27 Aug 2026
 09:38:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=th+imLn7P8Q4jh7KHsShJh9bDfhhF4qcaVWVKV/Mmyum/waR3DlgS/OTMSi5ki5WWt4UXO6tRSP4TgWP+xqdLV1jo6wISULkmQA2MnWr0YvxsFK0di8lL9tG883+LCJCYxvvvwQpJaMsywGEQsly+JhqztR6K4uag0+2a6tjaWB8pR9i2qB7RU2ikVvOyA8Hc0ikRH8TBYfk57nwRl0ZDHBOz0LJaIhgTcplJkR283tIvD8yvZlJkpSs+ylSNKVs012B//giFi7CpunKSja/3vx43C5T/twuhJKZ9BmV60TZ79kQ/cvilHWMGd1lXetPjekAHjbPrbGsgZlyT2LNcA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gwmCA8Q9O7G1J/I8ZQMK0FpJAXxpRT2z/dIkKHMIEdY=;
 b=csHwo+VSS0KUxEI9e2YVMRZZPLSd386074dr+e3pm5JRhGnysqOU1ik9zzYgt0zys6FShPPd1Im2qm/IuA3yE/qbhQJsTxW0otFrTGH2ghnXx1AL2915bb/XVxEOKBcs769GpFTyoy3C4rzlwtneIAu/QzAuqk3LFVEAHCNfwLXU6hI8wPJu0YjuO1+fY1wAeIe2igd72hPanUNUHZxRn06aJm/GeSGbWG7rMIn9gsM7KrG+sB2RRcM4CUxGpXaLf6XHWvuXRzGR3Nyv+kPnk6PfQrcih4HT92CA9yzmYgt8AvqyRV+qAH3PO8aODujfYSrVtK65BUccvjmCIBkkVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gwmCA8Q9O7G1J/I8ZQMK0FpJAXxpRT2z/dIkKHMIEdY=;
 b=QPNUg2qIdNp0TrIQxSR8fqMuo+qmvdVhPAhKQLNmp90Sdq50oV/VAqguEWKrauZN3fk+q8xUn0+0Day7zRGLIJHzdHIW8D8SDqvDG7VCtCKqwfHtg+SWO9qXQqPJlj6yoAJFEfaA+bUqcbOeC4QumCQEVCaNdYRv5P8JiJjF3BdFOyrSHMjllYlLUExzox9yItZyqz1SDcMG1xWr2Q2TZNdfOk++WMzRSkfOapExHLG3P0yGXAKqYRoRJSxRj4rhXrQWycuI17jkc0UGShMuiEnrU6VTKDDOgsTnWRS4AYfkpHX5o1mm0ZbCXRO86FtrVbEVHbAsrBlDnX01tDm9EA==
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
Subject: [PATCH v1 1/2] flask: add const qualifier to
 security_context_to_sid()
Thread-Topic: [PATCH v1 1/2] flask: add const qualifier to
 security_context_to_sid()
Thread-Index: AQHdNgfAVxs877kedUqP8J7OTWLOvA==
Date: Thu, 27 Aug 2026 09:38:01 +0000
Message-ID:
 <ee0ce49467ac1ee1cdd017323e70c8a865269f39.1787821757.git.Sergiy_Kibrik@epam.com>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
In-Reply-To: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|AS2PR03MB9562:EE_
x-ms-office365-filtering-correlation-id: 89c5b2b4-b60f-493a-e12a-08df041ee2e8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|38070700021|11063799006|10067099003|56012099006|22082099003|18002099003;
x-microsoft-antispam-message-info:
 kF/7e+e53lgACPHSAqZLCSHvDG60PMc1n7SPk/DRysCE4OHJ527bAAafhlsur/hIXUnRn87EMjn7ihZhRHryOwTeOHkT4cSctVR3+7X4zWUDKs27Uvquk1dFBwSDYnCV51ZH8NSY4hP7pkhIvHNE9cWHWmBFWuqMnEHJPrNdFuMcNHpFfUTxMMmwGCxhZCXmo41/Ez7VEAufqgZgtBTAJ0kEFjzj/HaMoF1YqmWKRONr63vNQczD3BDe01E0WV610q6jkmyHkcouItERTlVoizYZaz+b2Ay5PH1LR8TzxB6UZ9wXKubpI9kDeseHbEgRMbrUnKYQvhgk/pzDcV9qG43+CD4k4m0LRm+CwQiMpW4dtotpqZ7I9iE46nQA7+LNYztaJbzSLPXjdvtnf9H0R291vGbNeiH8737YGAuvasq9V5e8T9O+n2nwhKLvjDrG41RyJPHe0pSuT4KcZkiRm6QX5SllmEX0cqmmK6UsEQnEBr08JhKOepgTzWM2/eLUD+E713fTthWWQtUsMPndHUZwhvXb9SGkwegpN9SBBCZsaMjiAxrZf9iDWdKjN+/332xPo6eFMI05Gu9/oGe2Im78XeZQ3TQB4V1LQji6x8K1g/36sZDwv5NmRD0MY8bXJKnFmaURmnkkltHrea69rpEQYEo2J4XqqO+LYngLWO5AHIZeeKRmy0MkJdxHwnvHs/qYkoIKJTF67L+fspB2l1liACus4pXgkaJbIEnpbu4=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(38070700021)(11063799006)(10067099003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OXVrYXNqb1Ric3lBQjBzNU1kalFTM2JqTWJuc3FsS29rVTJ5eHF2UUFWcVYx?=
 =?utf-8?B?TlFPdnZFMmJEK2doT2IwRXg2Z1BaRENBblBOc3pQMmNpdWM3MEFmVTh5Wkk2?=
 =?utf-8?B?R0t3dDd0ZGdXVmdQckdxZ0YzbFZhMUJtSU9WNlQxYWdmeWRETXhid2RZZ3Mx?=
 =?utf-8?B?bkpLRFVUWjJsUG9MU1MvRDB1OWdlSkdoTEZzNS9zemVvd2QwM1F1SGpHVGZh?=
 =?utf-8?B?Zm1LRjFxREZxYmFnVHBHbXYvSFNGdUdHa0ZZUUF4VHdwQi9CV1Fwdyt1SXE3?=
 =?utf-8?B?YjdIRitpNUtFeDhwcFZDSHFQTmh2TnFncGtRdGlOanV2SktyV0dQdVRxQ1FD?=
 =?utf-8?B?UWtwUThOTUtjNWRBbDRsRWpTS2NmWTZMTkRLNnEvbEFObkw2eWxycjVjcDJ2?=
 =?utf-8?B?cHJuV3RGMFFFa2plaG5YZnphdWw5WXl1K1VpbXQyTkNLcFVFeDJJbEVpRlNu?=
 =?utf-8?B?bkwxNUpHNUFDRGMvczNlZW5YRXVFdmROY08va05XR00rbUdWeEFpYVFlUzV3?=
 =?utf-8?B?RjNHcXVmS3dPY1dOVFFnb1hXbHNqajVhZDlvak92Yy9GZHhXeUZaSlEvUlVE?=
 =?utf-8?B?eE40b291VFJSRlpaaFBoWGV4ZmR0RmJ1R08xOUtJWnQreklMam9UZkViNnlC?=
 =?utf-8?B?dys5REVIa1IxcndVTUgrMXFzOWVsWXU3TkZLZnh4MlExNGs4ZzRmck1MVmVk?=
 =?utf-8?B?ekxHdkNUVzlvMjNsVW9ORDlsbm96ZE5uV0tLcWxPUWN2UEkwaWtxVVZNYS8r?=
 =?utf-8?B?RHNhSjZBaXA3MlY0UjhEekhnbjFXdUlyTnY2VklrZ29JdVFiMkUyaGxlSUE2?=
 =?utf-8?B?ZTVvak0xN2dEc29aR21WMDNvaWsyQWNIVU44dEFyMStUeHA2TytReGhvUyt6?=
 =?utf-8?B?V2s5TFZxZmZTYUY2REhZMmdlVFRwTlNvdDVWSDJlUThWb2FmQ1lxVTlOMmIw?=
 =?utf-8?B?eHVzMjc4dXVXZzdhYVlkak5XT0x6VkdlOGRRRGJJd2N1SzlISDV1OHlFc3lz?=
 =?utf-8?B?SEUzZWtReUhLUUovRW5UNW9LNmtSTzdsbFVyeXNuam5reFdxenlvczVOdWRD?=
 =?utf-8?B?Q2FlMStVRWRKa1JrVEtndUZpcUE5eTRPeHRBY3k5WDFWQkJhWGRhRFovMnUx?=
 =?utf-8?B?QXcyU0ttTndXVit5dVFUaGNNaWMrVVdqNEhBdUFiczcrWWlZWGJSRXZ4ajQx?=
 =?utf-8?B?NEgxQUZ3czQ1WklFVzJKNWs0N2liVnFQNTdaMUVEcW0zYkliSUlDVjZKM3R4?=
 =?utf-8?B?Y1ZFV0lSKzRYS0p6ajFiQWRzUnFybHNjWnFKZG8yVklKOWVNdktWeFhzbnA2?=
 =?utf-8?B?MnRaejNWY243UDZJdHhGckpJeEo2UWhIaEkrcWZEcFNiMG5zUnFOTElNVlor?=
 =?utf-8?B?bG5kQXUxdm9iUHNKVUxpSmlkM2dGd0MydEtuMVZnY2xhQjRzUlY4THhRVkVy?=
 =?utf-8?B?UWVocGE2cGpkZTRpYXpZclNnek9IR05aR0xLYU5RSER3R2R5VTZTTDNIbysv?=
 =?utf-8?B?ajJCNGVlVmlBWDBkc09ibUFTRUlSMDdPaWpwc3I0eHJKSVpEak5WMHN1aC9t?=
 =?utf-8?B?UVhMT3VHRGVURHFzaHQzQ3lKVWszM0UvQ3o5bURZUUw5WUNmNmJIR2dOdm5P?=
 =?utf-8?B?ajBsWk81Yitjb1d5MUpZNXZRNGZ3K2VJanRySVpGSXAyUTVjbTcrSU5LS0xm?=
 =?utf-8?B?aDViQ21RaTlVUlVpMFVlMU55YWdnYWZRSjlHQ0ZYV3pQTXY1SS9sSlJSSnU5?=
 =?utf-8?B?bVA0dHY2MXRhTmRLMjZuWk95cXZuZm8rcDV4ZTdqSllXMjJaaXQrZGFpSFJh?=
 =?utf-8?B?b2tob0MzSUhOSEhwQUdKK1dkZ3ZqNG5wMVpjeDFSWTN5eDZob2tDSjZ4QUVE?=
 =?utf-8?B?Z0JQMms1MDZ3a0EycHBLV3BaLzdiZjhqc1hVMnhYakZDRWxpTTl3dmJKemgv?=
 =?utf-8?B?dlIyaExKT3JKUjRVYUpFQzVaQTdKM21OdnZHN01LUnJpT2l4Y1pZM2dDejJz?=
 =?utf-8?B?aXoyUjBGc09aQVcwN1BvM1BPWDdGZkdKQUpIWUlHQ2VVdnZMRlNESXlQb3Fm?=
 =?utf-8?B?czhnY1k0eGxkQmp6MmN4WHY2UUxnaWJ2V0tMN2srUFpPOHhzUURNUjg2OExL?=
 =?utf-8?B?ckJqU2VLc1dadUNPU0o2NytzdWczMXVuZ0c4alNMUWJaQjljODMxNW5FOUt4?=
 =?utf-8?B?bUlSTDJQcUZvZUZLNEVqdS9QMnR5amU5VlY2QzdGQWp5OThzQTVVbzY3cmV1?=
 =?utf-8?B?SisrOGE0WU5pSm5NWjgwanFOd28zbk1STEFvUEc5dWhoL255SmYrN1pKYmUv?=
 =?utf-8?B?c2ovMWZ3UzdwLzlUdG84Rm85RWZaZnFHckpRYnUveUY1YXhQOW1TQT09?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89c5b2b4-b60f-493a-e12a-08df041ee2e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2026 09:38:01.1679
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bZBK9Ka6hD4VPvsoRUC7btbmwLsU1f8OlBOG4LKDXSZyNrIxEbSfqkSy2LSLoV1x4t0yaaRgcJsJF327TljKyg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9562
X-purgate-ID: tlsNG-d25034/1787823487-006CEA5B-C45B0A7B/0/0
X-purgate-type: clean
X-purgate-size: 2042

VGhlIGZ1bmN0aW9uIGRvZXMgbm90IG1vZGlmeSBjb250ZXh0IGFyZ3VtZW50Lg0KQWxzbyBpdCBn
aXZlcyBtb3JlIGZsZXhpYmlsaXR5IHRvIHRoaXMgQVBJIHVzYWdlLCBiZWNhdXNlIHNvbWUgY29u
dGV4dCBzdHJpbmdzDQppbiBYZW4gYXJlIGFsc28gY29uc3QgY2hhciouDQoNClNpZ25lZC1vZmYt
Ynk6IFNlcmdpeSBLaWJyaWsgPFNlcmdpeV9LaWJyaWtAZXBhbS5jb20+DQotLS0NCiB4ZW4veHNt
L2ZsYXNrL2luY2x1ZGUvc2VjdXJpdHkuaCB8IDIgKy0NCiB4ZW4veHNtL2ZsYXNrL3NzL3NlcnZp
Y2VzLmMgICAgICB8IDIgKy0NCiAyIGZpbGVzIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBk
ZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdpdCBhL3hlbi94c20vZmxhc2svaW5jbHVkZS9zZWN1cml0
eS5oIGIveGVuL3hzbS9mbGFzay9pbmNsdWRlL3NlY3VyaXR5LmgNCmluZGV4IGVjOGI0NDJhOGYu
LmEyYzVmNDIzZjggMTAwNjQ0DQotLS0gYS94ZW4veHNtL2ZsYXNrL2luY2x1ZGUvc2VjdXJpdHku
aA0KKysrIGIveGVuL3hzbS9mbGFzay9pbmNsdWRlL3NlY3VyaXR5LmgNCkBAIC03Niw3ICs3Niw3
IEBAIGludCBzZWN1cml0eV9jaGFuZ2Vfc2lkKHUzMiBzc2lkLCB1MzIgdHNpZCwgdTE2IHRjbGFz
cywgdTMyICpvdXRfc2lkKTsNCiANCiBpbnQgc2VjdXJpdHlfc2lkX3RvX2NvbnRleHQodTMyIHNp
ZCwgY2hhciAqKnNjb250ZXh0LCB1MzIgKnNjb250ZXh0X2xlbik7DQogDQotaW50IHNlY3VyaXR5
X2NvbnRleHRfdG9fc2lkKGNoYXIgKnNjb250ZXh0LCB1MzIgc2NvbnRleHRfbGVuLCB1MzIgKm91
dF9zaWQpOw0KK2ludCBzZWN1cml0eV9jb250ZXh0X3RvX3NpZChjb25zdCBjaGFyICpzY29udGV4
dCwgdTMyIHNjb250ZXh0X2xlbiwgdTMyICpvdXRfc2lkKTsNCiANCiBpbnQgc2VjdXJpdHlfZ2V0
X2FsbG93X3Vua25vd24odm9pZCk7DQogDQpkaWZmIC0tZ2l0IGEveGVuL3hzbS9mbGFzay9zcy9z
ZXJ2aWNlcy5jIGIveGVuL3hzbS9mbGFzay9zcy9zZXJ2aWNlcy5jDQppbmRleCAzNWFkMTAzNGNh
Li43NjRhYzdkMWQ4IDEwMDY0NA0KLS0tIGEveGVuL3hzbS9mbGFzay9zcy9zZXJ2aWNlcy5jDQor
KysgYi94ZW4veHNtL2ZsYXNrL3NzL3NlcnZpY2VzLmMNCkBAIC04MTMsNyArODEzLDcgQEAgb3V0
Og0KICAqIFJldHVybnMgLSVFSU5WQUwgaWYgdGhlIGNvbnRleHQgaXMgaW52YWxpZCwgLSVFTk9N
RU0gaWYgaW5zdWZmaWNpZW50DQogICogbWVtb3J5IGlzIGF2YWlsYWJsZSwgb3IgMCBvbiBzdWNj
ZXNzLg0KICAqLw0KLWludCBzZWN1cml0eV9jb250ZXh0X3RvX3NpZChjaGFyICpzY29udGV4dCwg
dTMyIHNjb250ZXh0X2xlbiwgdTMyICpzaWQpDQoraW50IHNlY3VyaXR5X2NvbnRleHRfdG9fc2lk
KGNvbnN0IGNoYXIgKnNjb250ZXh0LCB1MzIgc2NvbnRleHRfbGVuLCB1MzIgKnNpZCkNCiB7DQog
ICAgIGNoYXIgKnNjb250ZXh0MjsNCiAgICAgc3RydWN0IGNvbnRleHQgY29udGV4dDsNCi0tIA0K
Mi40My4wDQo=


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:38:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:38:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400449.1636114 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYk-0002mk-39; Thu, 27 Aug 2026 09:38:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400449.1636114; Thu, 27 Aug 2026 09:38:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWYj-0002lZ-S0; Thu, 27 Aug 2026 09:38:09 +0000
Received: by outflank-mailman (input) for mailman id 1400449;
 Thu, 27 Aug 2026 09:38:09 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Sergiy_Kibrik@epam.com>) id 1wzWYj-0002di-0V
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:38:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWYi-002LkA-DH
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:38:08 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a90057f-bab6-0a2a0a5309dd-0a2a450ca456-10
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:08 +0200
Received: from [40.107.130.73]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a90057c-f479-0a2a450c0019-286b82493340-5
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:38:07 +0200
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AS2PR03MB9562.eurprd03.prod.outlook.com (2603:10a6:20b:599::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.8; Thu, 27 Aug
 2026 09:38:01 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0360.006; Thu, 27 Aug 2026
 09:38:01 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y5B62HZCXOcSnbOIpvrch9/Mrar3dohzhh2j8iAC4Qei5E3QK+tKALpf1KhP8oa7VDbBAL+F+hCGQF7wxLlMkeqeW7N1vwsNUQLI9vXWHJLPjabVc9JKHXufQBizZXmXbZAhf0QC4cimLvjp3kElB+ChVrysEYDCm2HKpDtksAS/BMMjz74Y0GCcJINC2I5POe/puHOv22LNZlnl0Cq9YUR1X2bDCpe25aAssJX+I2oQ8UacmeBpfTvWaiHVcJLlXug0nXndiqa1e6zbdGUxz8YGJHK2Bg4PdPRTJikRJmMN3OZQ61Bg4FiJL+/AT2lVR14BgOtc+AI1DeOVlA6G9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6hUzwFJQA/zIrKfA9M7At2QegoMA77ggOg6gny1kC54=;
 b=cGYt4HighruKOFXFBpoQe3M7y4X8M/TVhL+cbXFhpEoADP0e/y92qVZdoN68oGUrey05J6T+YikwiNGsLiHcCrb310z94z/doFIFfFA7zzol1bgwgfeI7mUbN/aKUAhYJF1xXZeeFUuhdFg/XC2ZWs38aCfZW+4htqeuBoIgnOKtp1LP1bQIOZGAJOilJfgGLhLlR2N4seNpbsufBEePDgJXEc/vt8Yu6qAwMtm77wyoFrqoPcPV01QxVjoT4hSZ5a0wj4BGO2C56i9VfaTq9BRF2+P/VLSUBqRYTlnrLpSH6bDAOSemCTZDuJSe6S1RQfuXPcadlKEM6BR3qSwu+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6hUzwFJQA/zIrKfA9M7At2QegoMA77ggOg6gny1kC54=;
 b=B7oCOVwhvhcIHvxcslTeC7EJXzenuapiq+tcsWGzw3QrSqKBz5S6hD6vo2DsWCk+IghE2ExobBc2OJ4J5eKtyfx/V7nV1iIRW0aX+rq4NQCIv6Kv4Jz0diZphVu8zOjBa9s/wdDuuGME0u2/80pU/fCnIJlpJENVU+z0KMRpWGsph92rTkapta/RsXdtkgbB87Rc3itv4ObiJ78gmULKstKq12mSqPF9lO5dBxPxwnT8drViwPLC7y7MZZX2CnrWOhmftKVx4IqqhRSXj5zeG/9ZAvH+RA5EoSukjOIUwnfrA8zy5myrLEmqJIE27OVQuFWDpYnvE0MfZkr4d5czOQ==
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, Volodymyr
 Babchuk <Volodymyr_Babchuk@epam.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
Subject: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels
Thread-Topic: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels
Thread-Index: AQHdNgfAHPmcI5IBhUGZU0o2oDVW1A==
Date: Thu, 27 Aug 2026 09:38:01 +0000
Message-ID:
 <e97ab666be0d667dc823c3d881ac9ed76267a7a5.1787821757.git.Sergiy_Kibrik@epam.com>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
In-Reply-To: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|AS2PR03MB9562:EE_
x-ms-office365-filtering-correlation-id: bae71e0c-836a-4483-57bf-08df041ee33b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|38070700021|11063799006|6133799003|10067099003|56012099006|22082099003|18002099003;
x-microsoft-antispam-message-info:
 rV3KnQpwSkGWtrQjLmjioGsc3+UoqreuFxbG/Zw5vPAoBYtJSbVwAoP3saiHNVop9mLC3UiepEpSyuBiWqbl03VqguvB/ExPd+E++fhTF+L/VqhQvOyUSBQPWOPMyeWsqoFT85o6pEp6ui4GgWfPC2rwguqyEzqJG+IHjdKp18MkBzsHRljNI8xtIeI14hlues2/uthRZ6u/qMmEvtWkLUsCa1CxqfakQoqofU9WY156hfpBkZ8t4VDzw4okhRXhY4qgdnUcs+gMJOhMYhL1DnwKfk3pOjW4mATUlUl28iYSZpkeZZtQdR/VC+mZ5TDsyKNTW1smPoEOp3ZOvwhzDdnWlR5XaH1rHMS2zs09t8F8iSTO12tVGKU4j8nMguewfVZHwA1ULAOx7rshe3SsWV8qRYL8ZW4f0F9rpApyUIbeCJz4MM+CvneCwcXn3Q0Yg1lVe2VUpeyku7niMB9c8W5HsfhbSGPLe42lmvhV3BayLo1G1c0Q0xzretvYI8G7ywbaV51Qcz11glFJWEHdSwH5qe7/WHAXrqo9w0gb33PKZjxCKmok+LZncyvoySXDy1iwxuqa0C1YZGuKOq9iLMep+8lbNDDXoi3HJ92CjXg4JmJRV9P9cVCdtg1/avEVy4uarNrS6nO9Kob5f9XoYoN0PFvgUmRRg91a42+96w9ubbOjzvz0amB/0ggXiKvtW+YYc4bv2TW9Y3nsX4P9wxs4MIm4sh1Z04Ew2d1/unY=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(38070700021)(11063799006)(6133799003)(10067099003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OHJ4ZENsZ2ZrMXJldXBPV3NETkc1cUdydGI2TDkxY0Z3VHJyNk12Y1lLOHhM?=
 =?utf-8?B?Z1dydWxuMWkxZm9LMXVxY1VTblVPM1Ryd3NybzNScnNHcFNEOEFaRlpDN2tQ?=
 =?utf-8?B?ZHZTb2tZZkVPSkw2cEFTb1AvOUdkZnArNWxCNzkrQjFRVVNaM3Z0ZEVlNThB?=
 =?utf-8?B?Y1NZUjdVa2JNdVVkVndZYmozbHdNejBuVTNhdjQybS9ZL0hGb2NWN0QvcGZl?=
 =?utf-8?B?aSt2Um84ZUVQNE91SWJjcTgyeE5TSGFGZzNRcWMrSDRtR094dmpIczNDTVpw?=
 =?utf-8?B?MCtJN0Z6d0NYdmMxSEh5cEpBZUY3bnpKMXhoRE96TlZkaWxiTlY3d2tOV2tw?=
 =?utf-8?B?RHZjY3Zid0RXTysxbSsrYmdSWWxVWFZIOTVyL2ZTdTNLU1IzTFZ6eE9OOU1m?=
 =?utf-8?B?LzNzY1pYaFhQS1ZSZjlrR0RHQ3IvL01UbFpweWtMVmQ2YmJRMlRDb1J5M3hZ?=
 =?utf-8?B?T1dISzVReTJRQVhCdmNWRjF3OWx4L0J4MXJBMkFwSmlqQ005eXpwQlpObkV1?=
 =?utf-8?B?N2FtckZNQmRtbE5EcE96VE56RXY4Z2ZreTNRYkV4L3RtWWdyektqUFpxRmNx?=
 =?utf-8?B?clUzblFCb1VCSUI1VEJhd2ZKRngwa2djWWFuU0dmTGVoVkNiTkN0MkpPTkJy?=
 =?utf-8?B?QkN6U0Z0QVl1QlVQTWNVM29JbEd0NkRFUWp1QmMzczdaYWhPTlpFRHdtQzZT?=
 =?utf-8?B?NWlJZWoyNzhaaWViTW0rQlArWGVnVnV5N0dMWnZxWkZQYWxmZXhaTGtHWFhr?=
 =?utf-8?B?c01yTzBqMDRHRFNpRHdST2FqQ1RQNzBudUVmbkJ1N0dTcytXU2lYS1IrVmo0?=
 =?utf-8?B?QkF0WDFHTms3T2pZZHliY2JTcWE3S0hhUStlMkNJU1Y0eHkwdkxST3lPZGpH?=
 =?utf-8?B?R09aczNkWHROdkF1bE1HYjlhQTg3bUpJV2ovMWpGTmsrcmZCSHNzSU5ybnBy?=
 =?utf-8?B?WXJkS2FJWUxPNTVXOVBsR2l5ZTZvNzQ1dUJvaWorMkF3Kzh3M1RQVFFwVWkx?=
 =?utf-8?B?cTZhTjlPRVA5VWVDMzF6a1RVZ3FpRXZBYVVMY3laZUVhaWt6RkQ1c3dtMisw?=
 =?utf-8?B?S0YyNkovTWpEY2tHcmdPeEZ0VEZwUXRFU1pmV2wwN0IxOXZWK1JubWZpQ0Mv?=
 =?utf-8?B?bkRXVGpkWStXM00yblkwd2VoY0p1Tk9Nc1RKQTgrTDkxS1JpQjY3NzJuUmNW?=
 =?utf-8?B?VHM3UDJnQWg5TE4wWE1BMzRzWHRYQmhWS2hZanhRcVAxMlEyTERXTXBla3JT?=
 =?utf-8?B?eXNaWitvNDN0bUFodHJ5aXVyNEs0ZkowZm8vd3JEeWE1dGRSL1QrYnFKeXpZ?=
 =?utf-8?B?RXFIakJpdlA0UHpXWVhwTTdvanBuanVPd3VaVGNuSjdKQ0NoeUNrWjF4TTRH?=
 =?utf-8?B?UWhMbjF1VDYydnFGSHRTaURkdG1EK2UzNlpxT1FtaWwyeEU4T1lpVEtocmRU?=
 =?utf-8?B?a3JNa0J0a3dKR1dQZVhjN0M0ZjRwcUpIazhncmxYd1B3TEwvK00wWCtETFU3?=
 =?utf-8?B?aFhtMzZWR0NTTDU2OVN4S0xOSVNnekIwL3RteER2a3paWkljSEttSFF0QnpX?=
 =?utf-8?B?djlEbUJaZW55TzdHa3pPcDJaa0ZPdGE4eUNUSkVtOWM5Y2tITmNYQ21aVGJz?=
 =?utf-8?B?WkgzSHBvci9XTnhhYnFMdGFFaDJHSXBpK3o5dlpOcUkxUlMwNDN1a0M1UWc4?=
 =?utf-8?B?eENTUmNhQmlTSmZlcmxjRjVNTmY1SDErSHZqc1d3Y3htRmR2YzZvajdWVmhX?=
 =?utf-8?B?NHYyQzFlRDh5c2FoYjcvRXkxY21EYWplM1NvL1pIVEZzbEVPVE9Oa2FQbkRu?=
 =?utf-8?B?eXYwejhqc2ZCVGY0SXRlMFMzRXNWSGhxY0FFUjQydC9oMGVpL2lST2VRWGZJ?=
 =?utf-8?B?MUNPdFVNQXJJaVFpMjdrZkJ3RGJqUnAvbmhHY3RKMVkyeWI2ZTFLaTNXbkVO?=
 =?utf-8?B?YS8xMXJ0eUsxRkFEVGRqbW1LR1kvRFJtQ2NvQ3FTNTBwYmdUQWlnbVRUbHc3?=
 =?utf-8?B?MmlpVWszM2RCKzFsTldIRkdsTFhHN3gwRndGajlsaGx2UUNNL0ZickNrbkl1?=
 =?utf-8?B?M2xpdHZ4aE9VQU9GN3dkcVJTRzVCTFI4aC9wMmpFT0tmbFdUdFVsRWp5eGJZ?=
 =?utf-8?B?MmZudVFMbWNocGRyVXFxQ1dHeGdYNUl2WWNUVmVQdWozWVhTdGQ3Yy8yRy9x?=
 =?utf-8?B?ZU9YZXlHUVVGU2ZjM2JaOWFuWUFvN2h3ZEE3RmpCUSttQ29FZjBCeGtQUkJ0?=
 =?utf-8?B?cnVEdWlYNjRVclNMOGRPeC81WkhJOEVXN1VBUXg0OWJpeHMyZzd5SDEzUzVQ?=
 =?utf-8?B?ZUQ1V2Z6R3IzbjlvdWd0b1hVdEQvdytPay9PWEtnRTdNRmpIaTJZUT09?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <D9114834568C8D4FB8D9C4A502935E6B@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bae71e0c-836a-4483-57bf-08df041ee33b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2026 09:38:01.6047
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tGmSB3PGwY4KGn0Cl4v69oVXC+5n47Q9nd3V2vgW3bK0hs/syCLtJVTKJOmapzt/RNDajitMqwN/+31dPJJV4w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9562
X-purgate-ID: tlsNG-d25034/1787823487-024DFA5B-16147642/0/0
X-purgate-type: clean
X-purgate-size: 5006

QWRkICJzZWNsYWJlbCIgcHJvcGVydHkgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHNlY3VyaXR5IGxh
YmVsIGZvciBhIGRvbWFpbg0Kd2hlbiBYU00gRmxhc2sgaXMgZW5hYmxlZCwgc2ltaWxhciB0byB4
bCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpDdXJyZW50bHkgZ3Vlc3QgZG9tYWluIGNhbid0IGJl
IGNyZWF0ZWQgYnkgWGVuIGluIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb24gd2hlbg0KRmxhc2sgaXMg
ZW5hYmxlZCwgYXMgZG9tYWluIGlzIGFzc2lnbmVkICJzeXN0ZW1fdTpzeXN0ZW1fcjp1bmxhYmVs
ZWRfdCIgbGFiZWwNCmJ5IGRlZmF1bHQsIHdoaWNoIEZsYXNrIGRlbmllcyB0byBjcmVhdGUgYWNj
b3JkaW5nIHRvIGN1cnJlbnQgcG9saWN5Lg0KDQpTaWduZWQtb2ZmLWJ5OiBTZXJnaXkgS2licmlr
IDxTZXJnaXlfS2licmlrQGVwYW0uY29tPg0KLS0tDQogZG9jcy9taXNjL2FybS9kZXZpY2UtdHJl
ZS9ib290aW5nLnR4dCAgICAgIHwgIDggKysrKysrKysNCiB4ZW4vY29tbW9uL2RldmljZS10cmVl
L01ha2VmaWxlICAgICAgICAgICAgfCAgMiArKw0KIHhlbi9jb21tb24vZGV2aWNlLXRyZWUvZG9t
MGxlc3MtYmluZGluZ3MuYyB8IDExICsrKysrKysrKysrDQogMyBmaWxlcyBjaGFuZ2VkLCAyMSBp
bnNlcnRpb25zKCspDQoNCmRpZmYgLS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jv
b3RpbmcudHh0IGIvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KaW5kZXgg
YmNiMDZiYzc5Ni4uZmNjN2JlMGZmYiAxMDA2NDQNCi0tLSBhL2RvY3MvbWlzYy9hcm0vZGV2aWNl
LXRyZWUvYm9vdGluZy50eHQNCisrKyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGlu
Zy50eHQNCkBAIC0zNDUsNiArMzQ1LDEyIEBAIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVz
Og0KICAgICBub3QgcGFzc2VkLiBUaGlzIGNvbmZpZ3VyYXRpb24gcmVxdWlyZXMgc3RhdGljIGFs
bG9jYXRpb24gKHhlbixzdGF0aWMtbWVtKQ0KICAgICBhbmQgZGlyZWN0IG1hcHBpbmcgKGRpcmVj
dC1tYXApLg0KIA0KKy0gc2VjbGFiZWwNCisNCisgICAgQSBzdHJpbmcgcHJvcGVydHkgc3BlY2lm
eWluZyBhbiBYU00gc2VjdXJpdHkgbGFiZWwgdG8gdGhpcyBkb21haW4uIEVmZmVjdGl2ZQ0KKyAg
ICBvbmx5IHdoZW4gRkxBU0sgaXMgZW5hYmxlZC4gRG9tYWlucyB3aWxsIGJlIGNsYXNzaWZpZWQg
4oCcdW5sYWJlbGVk4oCdIGlmDQorICAgIHRoaXMgcHJvcGVydHkgbm90IHNwZWNpZmllZC4NCisN
CiBVbmRlciB0aGUgInhlbixkb21haW4iIGNvbXBhdGlibGUgbm9kZSwgb25lIG9yIG1vcmUgc3Vi
LW5vZGVzIGFyZSBwcmVzZW50DQogZm9yIHRoZSBEb21VIGtlcm5lbCBhbmQgcmFtZGlzay4NCiAN
CkBAIC00MjIsNiArNDI4LDcgQEAgY2hvc2VuIHsNCiAgICAgICAgIG1lbW9yeSA9IDwwIDEzMTA3
Mj47DQogICAgICAgICBjcHVzID0gPDI+Ow0KICAgICAgICAgdnBsMDExOw0KKyAgICAgICAgc2Vj
bGFiZWwgPSAic3lzdGVtX3U6c3lzdGVtX3I6ZG9tVV90IjsNCiANCiAgICAgICAgIHZjcHUwIHsN
CiAgICAgICAgICAgICBjb21wYXRpYmxlID0gInhlbix2Y3B1IjsNCkBAIC00NTMsNiArNDYwLDcg
QEAgY2hvc2VuIHsNCiAgICAgICAgICNzaXplLWNlbGxzID0gPDB4MT47DQogICAgICAgICBtZW1v
cnkgPSA8MCA2NTUzNj47DQogICAgICAgICBjcHVzID0gPDE+Ow0KKyAgICAgICAgc2VjbGFiZWwg
PSAic3lzdGVtX3U6c3lzdGVtX3I6ZG9tVV90IjsNCiANCiAgICAgICAgIG1vZHVsZUAweDRjMDAw
MDAwIHsNCiAgICAgICAgICAgICBjb21wYXRpYmxlID0gIm11bHRpYm9vdCxrZXJuZWwiLCAibXVs
dGlib290LG1vZHVsZSI7DQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9NYWtl
ZmlsZSBiL3hlbi9jb21tb24vZGV2aWNlLXRyZWUvTWFrZWZpbGUNCmluZGV4IDkwMzZlNDU1ZDYu
LmU0ZGUyOTI1MzMgMTAwNjQ0DQotLS0gYS94ZW4vY29tbW9uL2RldmljZS10cmVlL01ha2VmaWxl
DQorKysgYi94ZW4vY29tbW9uL2RldmljZS10cmVlL01ha2VmaWxlDQpAQCAtMTEsMyArMTEsNSBA
QCBvYmotJChDT05GSUdfRE9NQUlOX0JVSUxEX0hFTFBFUlMpICs9IGtlcm5lbC5vDQogb2JqLSQo
Q09ORklHX1NUQVRJQ19FVlRDSE4pICs9IHN0YXRpYy1ldnRjaG4uaW5pdC5vDQogb2JqLSQoQ09O
RklHX1NUQVRJQ19NRU1PUlkpICs9IHN0YXRpYy1tZW1vcnkuaW5pdC5vDQogb2JqLSQoQ09ORklH
X1NUQVRJQ19TSE0pICs9IHN0YXRpYy1zaG1lbS5pbml0Lm8NCisNCitDRkxBR1MteSArPSAtSSQo
c3JjdHJlZSkveHNtL2ZsYXNrL2luY2x1ZGUNCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL2Rldmlj
ZS10cmVlL2RvbTBsZXNzLWJpbmRpbmdzLmMgYi94ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBs
ZXNzLWJpbmRpbmdzLmMNCmluZGV4IDQxZDcyZDBkNTguLmJmZmQyZWM2NWQgMTAwNjQ0DQotLS0g
YS94ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBsZXNzLWJpbmRpbmdzLmMNCisrKyBiL3hlbi9j
b21tb24vZGV2aWNlLXRyZWUvZG9tMGxlc3MtYmluZGluZ3MuYw0KQEAgLTExLDYgKzExLDggQEAN
CiAjaW5jbHVkZSA8cHVibGljL2Jvb3RmZHQuaD4NCiAjaW5jbHVkZSA8cHVibGljL2RvbWN0bC5o
Pg0KIA0KKyNpbmNsdWRlIDxzZWN1cml0eS5oPg0KKw0KIGludCBfX2luaXQgcGFyc2VfZG9tMGxl
c3Nfbm9kZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUsDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cnVjdCBib290X2RvbWFpbiAqYmQpDQogew0KQEAgLTIxLDYgKzIzLDcg
QEAgaW50IF9faW5pdCBwYXJzZV9kb20wbGVzc19ub2RlKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAq
bm9kZSwNCiAgICAgYm9vbCBoYXNfZHRiID0gZmFsc2U7DQogICAgIGJvb2wgaW9tbXUgPSBmYWxz
ZTsNCiAgICAgY29uc3QgY2hhciAqZG9tMGxlc3NfaW9tbXUgPSBOVUxMOw0KKyAgICBjb25zdCBj
aGFyICp4c21fc2VjbGFiZWwgPSBOVUxMOw0KIA0KICAgICBpZiAoICFkdF9kZXZpY2VfaXNfY29t
cGF0aWJsZShub2RlLCAieGVuLGRvbWFpbiIpICkNCiAgICAgICAgIHJldHVybiAtRU5PRU5UOw0K
QEAgLTE0MSw1ICsxNDQsMTMgQEAgaW50IF9faW5pdCBwYXJzZV9kb20wbGVzc19ub2RlKHN0cnVj
dCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSwNCiAgICAgICAgIHBhbmljKCInbGxjLWNvbG9ycycgZm91
bmQsIGJ1dCBMTEMgY29sb3JpbmcgaXMgZGlzYWJsZWRcbiIpOw0KICNlbmRpZg0KIA0KKyAgICBp
ZiAoIElTX0VOQUJMRUQoQ09ORklHX1hTTV9GTEFTSykgJiYNCisgICAgICAgICAhZHRfcHJvcGVy
dHlfcmVhZF9zdHJpbmcobm9kZSwgInNlY2xhYmVsIiwgJnhzbV9zZWNsYWJlbCkgKQ0KKyAgICB7
DQorICAgICAgICBpZiAoIHNlY3VyaXR5X2NvbnRleHRfdG9fc2lkKHhzbV9zZWNsYWJlbCwgc3Ry
bGVuKHhzbV9zZWNsYWJlbCksDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZkX2NmZy0+c3NpZHJlZikgKQ0KKyAgICAgICAgICAgIHBhbmljKCJJbnZhbGlkIHNlY3VyaXR5
IGNvbnRleHQgZm9yIGRvbWFpbjogJXNcbiIsIHhzbV9zZWNsYWJlbCk7DQorICAgIH0NCisNCiAg
ICAgcmV0dXJuIGFyY2hfcGFyc2VfZG9tMGxlc3Nfbm9kZShub2RlLCBiZCk7DQogfQ0KLS0gDQoy
LjQzLjANCg==


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:43:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:43:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400480.1636141 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdf-0005gE-Vj; Thu, 27 Aug 2026 09:43:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400480.1636141; Thu, 27 Aug 2026 09:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdf-0005g7-Rb; Thu, 27 Aug 2026 09:43:15 +0000
Received: by outflank-mailman (input) for mailman id 1400480;
 Thu, 27 Aug 2026 09:43:14 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@swg.vates.tech>)
 id 1wzWde-0005Td-FO
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:43:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWdd-00B8Qw-S7
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:43:13 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@swg.vates.tech>)
 id 6a9006a5-8faa-0a2a0a5109dd-0a2a4506caa8-26
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:13 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@swg.vates.tech>)
 id 6a9006b1-195a-0a2a45060019-b9ff1c2295af-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:13 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0429a1050000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:43:08 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 16CE283B2D;
 Thu, 27 Aug 2026 11:43:07 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=sbEkocC2EuCtg3d1VQNUGSyKIv15JnFJv8WCsyhEZIU=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=t2DyFejTbgi9masF0k9lA2VrdJpmtdqwdkwebJSSyrbdrv5mT+Lj0o0IAShKPkfp8p/wFXkmT
 aonTBkB/GS12Q/6nWrjn7Mf9V+S7Pquru+HAHxzXCVcwr+kpsoC2a8NWCr1k/HTqsQo6VIkQHx1
 HdGvadcW2gNnnhxTAa0jqSUBCJR//pmmdiiCzSO1WOIF5R94TsBxDoj+tzyxhI1BVsRs5NxGmz9
 w37uRsjGxAuc1apmBgpnucy7VVL3yg7Z5QzLNO9cYkz5dwSXAvlFOGzptbdE/nCoX+fOiecT1eY
 f8zwRnI0WrufqBDpekvUBgVJD6Bjeec5KVxIvSOTJVtA==
X-Zone-Loop: 52ebf5fdabd5f7c4a8336b4b7b4a14c75c1fc4a217c0
x-campaign-type: default
x-transaction-id: 604569c2-b308-4713-b81c-144e4520ef14
x-swg-uid: 01-17b6331a-b3e4-4096-9bcc-a833dfc66e74
X-Mailer: Sweego
Message-ID:
 <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech>
x-swg-bid: 1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests
Date: Thu, 27 Aug 2026 11:42:48 +0200
In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823787186
X-purgate-ID: tlsNG-16d1c6/1787823793-F440377B-4AF80189/0/0
X-purgate-type: clean
X-purgate-size: 6917

The dom0less RISC-V smoke tests need a host device tree describing the
platform (CPUs, APLIC/IMSIC, uart). It varies per machine (hart count, MMU
type), so a single static .dts cannot cover the test matrix.

Add dts/qemu-host.dts.j2, a template of the QEMU virt platform in
aia=aplic-imsic mode: per-hart cpu/cpu-intc nodes, the M- and S-mode APLIC
and IMSIC pairs, CLINT and the ns16550a uart. It takes ncpus, mmu_type and
xen_bootargs as arguments.

Values QEMU hardcodes are set as named constants matching their source
symbols (QEMU_UART0_IRQ, QEMU_IRQCHIP_NUM_SOURCES, ...) rather than
open-coded, so a QEMU-side change is easy to trace.

The template is inert on its own: the generated dtb will be used in next
patch.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 .../scripts/qtb/riscv/dts/qemu-host.dts.j2    | 160 ++++++++++++++++++
 1 file changed, 160 insertions(+)
 create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2

diff --git a/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2
new file mode 100644
index 0000000000..13a8e983ce
--- /dev/null
+++ b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2
@@ -0,0 +1,160 @@
+/dts-v1/;
+
+{#-
+ * Jinja2 QEMU "virt" platform device tree for Xen RISC-V tests.
+ *
+ * Interrupt controller: APLIC in MSI mode + IMSIC
+ * (QEMU -M virt,aia=aplic-imsic).
+ *
+ * Rendered by xen_dt.py.
+ *
+ * Variables:
+ *   ncpus        - number of physical harts                (int, >= 1)
+ *   mmu_type     - Xen host MMU type, e.g. "sv39"          (string)
+ *   xen_bootargs - Xen command line                        (string)
+ *
+ * Per-hart nodes are labelled cpu<i> / cpu<i>_intc and referenced with &label.
+ *
+ * No `aia-guests=N`, so no VS-mode guest files: IMSIC reg size is
+ * ncpus * page size.
+-#}
+{#- Values QEMU hardcodes, need to be described to Xen -#}
+{%- set QEMU_TIMEBASE_FREQUENCY = 10000000 %}   {#- RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ -#}
+{%- set QEMU_IRQCHIP_NUM_SOURCES = 96 %}        {#- VIRT_IRQCHIP_NUM_SOURCES (virt.h) -#}
+{%- set QEMU_IRQCHIP_NUM_MSIS = 255 %}          {#- VIRT_IRQCHIP_NUM_MSIS -#}
+{%- set QEMU_UART_CLOCK_FREQUENCY = 3686400 %}  {#- create_fdt_uart() -#}
+{%- set QEMU_UART0_IRQ = 10 %}                  {#- UART0_IRQ -#}
+{%- set QEMU_IMSIC_PAGE_SZ = 0x1000 %}          {#- IMSIC_MMIO_PAGE_SZ -#}
+
+{%- set IRQ_TYPE_LEVEL_HIGH = 4 %}
+{%- set APLIC_IRQ_CELLS = 2 %}
+
+{%- set IRQ_M_SOFT = 3 %}
+{%- set IRQ_M_TIMER = 7 %}
+{%- set IRQ_S_EXT = 9 %}
+{%- set IRQ_M_EXT = 11 %}
+
+/ {
+    #address-cells = <0x02>;
+    #size-cells = <0x02>;
+    compatible = "riscv-virtio";
+    model = "riscv-virtio,qemu";
+
+    memory@80000000 {
+        device_type = "memory";
+        reg = <0x00 0x80000000 0x00 0x80000000>;
+    };
+
+    cpus {
+        #address-cells = <0x01>;
+        #size-cells = <0x00>;
+        timebase-frequency = <{{ QEMU_TIMEBASE_FREQUENCY }}>;
+{% for i in range(ncpus) %}
+        cpu{{ i }}: cpu@{{ i }} {
+            device_type = "cpu";
+            reg = <0x{{ '%x' % i }}>;
+            status = "okay";
+            compatible = "riscv";
+            riscv,cbop-block-size = <0x40>;
+            riscv,cboz-block-size = <0x40>;
+            riscv,cbom-block-size = <0x40>;
+            riscv,isa = "rv64imafdch_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_smstateen_svpbmt_smaia_ssaia";
+            mmu-type = "riscv,{{ mmu_type }}";
+
+            cpu{{ i }}_intc: interrupt-controller@{{ i }} {
+                #interrupt-cells = <0x01>;
+                interrupt-controller;
+                compatible = "riscv,cpu-intc";
+            };
+        };
+{% endfor %}
+        cpu-map {
+
+            cluster0 {
+{% for i in range(ncpus) %}
+                core{{ i }} {
+                    cpu = <&cpu{{ i }}>;
+                };
+{% endfor %}
+            };
+        };
+    };
+
+    soc {
+        #address-cells = <0x02>;
+        #size-cells = <0x02>;
+        compatible = "simple-bus";
+        ranges;
+
+        serial@10000000 {
+            interrupts = <{{ QEMU_UART0_IRQ }} {{ IRQ_TYPE_LEVEL_HIGH }}>;
+            interrupt-parent = <&aplic_s>;
+            clock-frequency = <{{ QEMU_UART_CLOCK_FREQUENCY }}>;
+            reg = <0x00 0x10000000 0x00 0x100>;
+            compatible = "ns16550a";
+        };
+
+        aplic_s: aplic@d000000 {
+            riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>;
+            reg = <0x00 0xd000000 0x00 0x8000>;
+            msi-parent = <&imsic_s>;
+            interrupt-controller;
+            #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>;
+            compatible = "riscv,aplic";
+        };
+
+        aplic@c000000 {
+            riscv,delegate = <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCES }}>;
+            riscv,children = <&aplic_s>;
+            riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>;
+            reg = <0x00 0xc000000 0x00 0x8000>;
+            msi-parent = <&imsic_m>;
+            interrupt-controller;
+            #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>;
+            compatible = "riscv,aplic";
+        };
+
+        imsic_s: imsics@28000000 {
+            riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>;
+            reg = <0x00 0x28000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>;
+            interrupts-extended = <
+                {%- for i in range(ncpus) %}
+                    &cpu{{ i }}_intc {{ IRQ_S_EXT }}
+                {%- endfor %}
+            >;
+            msi-controller;
+            interrupt-controller;
+            #interrupt-cells = <0x00>;
+            compatible = "riscv,imsics";
+        };
+
+        imsic_m: imsics@24000000 {
+            riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>;
+            reg = <0x00 0x24000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>;
+            interrupts-extended = <
+                {%- for i in range(ncpus) %}
+                    &cpu{{ i }}_intc {{ IRQ_M_EXT }}
+                {%- endfor %}
+            >;
+            msi-controller;
+            interrupt-controller;
+            #interrupt-cells = <0x00>;
+            compatible = "riscv,imsics";
+        };
+
+        clint@2000000 {
+            interrupts-extended = <
+                {%- for i in range(ncpus) %}
+                    &cpu{{ i }}_intc {{ IRQ_M_SOFT }} &cpu{{ i }}_intc {{ IRQ_M_TIMER }}
+                {%- endfor %}
+            >;
+            reg = <0x00 0x2000000 0x00 0x10000>;
+            compatible = "sifive,clint0", "riscv,clint0";
+        };
+    };
+
+    chosen {
+        stdout-path = "/soc/serial@10000000";
+        xen,xen-bootargs = "{{ xen_bootargs }}";
+    };
+};


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:43:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:43:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400479.1636132 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWde-0005Tr-QF; Thu, 27 Aug 2026 09:43:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400479.1636132; Thu, 27 Aug 2026 09:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWde-0005Ti-L9; Thu, 27 Aug 2026 09:43:14 +0000
Received: by outflank-mailman (input) for mailman id 1400479;
 Thu, 27 Aug 2026 09:43:12 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzWdc-0005TX-ST
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:43:12 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWdc-00B8Qw-94
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:43:12 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@swg.vates.tech>)
 id 6a9006a5-8faa-0a2a0a5109dd-0a2a4506caa8-20
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:12 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@swg.vates.tech>)
 id 6a9006af-195a-0a2a45060019-b9ff1c12a20f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:12 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0429a0db7000c4f3.004 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:43:07 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 656DC81230;
 Thu, 27 Aug 2026 11:43:06 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=+fIlO9mf1bNb6w2Vy7RTkh4SsFCS7tMV++tpqFsgJCE=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=FkPrl4dpV8RQmqZi2y9uisTYaUlsQ9UyRpJM+Fepfexh4sjknAVUjb86QPX1q1WYy/mDoZudC
 Z1oqeoT1rIG+gVszk3SnI8NjxBu9lNkTwnJsCe0OUYzszmypD3Pq/PEqEGVcgTtxWYyjXiSJKw0
 +YPPLqVDi0NuMyyNL1yMP+e+JoaH5/WBWJj0N34GaxiIAoHmvN4elod4UkQv3sjeTT/VkOeoSXq
 qpLmgPotZlPnaYtFyDJ+vyS7b+Ejgm0CjOkofuxLgzuPxaZ8cZdt1k5xegybT/46M54hFW1Hm3k
 iD1GiKgQq4FuyCvaEdQ2yD/wx1r43SZ3t/fgLNTXBimA==
X-Zone-Loop: ea63cb4949b7c6921f821a088449c34448928466fe93
x-campaign-type: default
x-transaction-id: 049912a5-1f7d-4876-aba9-f756917953f3
x-swg-uid: 01-3f407e4b-4268-461f-97cb-edbe9143ad2a
X-Mailer: Sweego
Message-ID:
 <1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3@vates.tech>
x-swg-bid: 1787823787.8631fc262581453bbf619ec5b2062170.1a0429a0db7000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 1/6] Add a QTB container to run the Xen riscv64 tests
Date: Thu, 27 Aug 2026 11:42:47 +0200
In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823786578
X-purgate-ID: tlsNG-16d1c6/1787823792-FD80D77B-67A9A57B/10/63158204843
X-purgate-type: spam
X-purgate-size: 2965

QTB (QEMU Test Bench) is a Python framework, developed as part of AMD's Xen
safety initiative, that drives a live QEMU instance over qtest and QMP. It
gives a test full access to the machine while the emulation runs: read and
write the consoles, inspect the registers and the memory, inject interrupts.

For now the riscv64 CI tests only use it to read the Xen console in the
smoke test, since DomU is not supported yet. Once it is, the same
framework will read and write the DomU consoles and inject IRQs, so the
tests can assert an interrupt reaches the expected guest and vCPU.

QTB is not upstream in QEMU yet, though it is planned to be, so get the
framework from AMD's fork gitlab.com/xen-project/people/amd/qemu and
pip-installs qemu.qtb from it.

Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 containerize                            |  1 +
 images/debian/13-qtb-riscv64.dockerfile | 45 +++++++++++++++++++++++++
 2 files changed, 46 insertions(+)
 create mode 100644 images/debian/13-qtb-riscv64.dockerfile

diff --git a/containerize b/containerize
index dad9afa..477b670 100755
--- a/containerize
+++ b/containerize
@@ -31,6 +31,7 @@ case "_${CONTAINER}" in
     _alpine-3.24-arm64-base) CONTAINER="${BASE}/alpine:3.24-arm64-base" ;;
     _alpine-3.24-arm64-build) CONTAINER="${BASE}/alpine:3.24-arm64-build" ;;
     _alpine-3.24-x86_64-base) CONTAINER="${BASE}/alpine:3.24-x86_64-base" ;;
+    _debian-13-qtb-riscv64) CONTAINER="${BASE}/debian:13-qtb-riscv64" ;;
     _alpine-3.24-x86_64-build|_) CONTAINER="${BASE}/alpine:3.24-x86_64-build" ;;
 esac
 
diff --git a/images/debian/13-qtb-riscv64.dockerfile b/images/debian/13-qtb-riscv64.dockerfile
new file mode 100644
index 0000000..86215d3
--- /dev/null
+++ b/images/debian/13-qtb-riscv64.dockerfile
@@ -0,0 +1,45 @@
+# syntax=docker/dockerfile:1
+FROM --platform=linux/amd64 debian:trixie-slim
+LABEL maintainer.name="The Xen Project"
+LABEL maintainer.email="xen-devel@lists.xenproject.org"
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+ARG QEMU_REPO=https://gitlab.com/xen-project/people/amd/qemu.git
+ARG QEMU_COMMIT=24cd7e5c0d7e4db8e651f091d0b9da2e7c58dbab
+
+RUN <<EOF
+#!/bin/bash
+    set -eu
+
+    useradd --create-home user
+
+    apt-get update
+
+    DEPS=(# Base environment
+        ca-certificates
+        device-tree-compiler
+        git
+        python3-jinja2
+        python3-minimal
+        python3-pip
+        python3-yaml
+
+        # Qemu for test phase
+        qemu-system-riscv64
+    )
+
+    apt-get -y --no-install-recommends install "${DEPS[@]}"
+
+    # QTB framework
+    git init /tmp/qemu
+    git -C /tmp/qemu fetch --depth 1 "$QEMU_REPO" "$QEMU_COMMIT"
+    git -C /tmp/qemu checkout FETCH_HEAD
+    pip install --break-system-packages /tmp/qemu/python[qtb]
+
+    rm -rf /tmp/qemu
+    rm -rf /var/lib/apt/lists/*
+EOF
+
+USER user
+WORKDIR /build
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:43:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:43:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400481.1636149 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdj-0005ul-4w; Thu, 27 Aug 2026 09:43:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400481.1636149; Thu, 27 Aug 2026 09:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdj-0005ue-2C; Thu, 27 Aug 2026 09:43:19 +0000
Received: by outflank-mailman (input) for mailman id 1400481;
 Thu, 27 Aug 2026 09:43:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@swg.vates.tech>)
 id 1wzWdh-0005t3-52
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:43:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWdg-00Fwyk-I1
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:43:16 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@swg.vates.tech>)
 id 6a9006ab-2eae-0a2a0a5409dd-0a2a450c8740-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:16 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@swg.vates.tech>)
 id 6a9006b4-f479-0a2a450c0019-b9ff1c23ac25-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:16 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0429a1248000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:43:08 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id C8E9881230;
 Thu, 27 Aug 2026 11:43:07 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=gmD+/yUGFmr+Kw4z5rV1wyYCJPmGDuI5iAWOZKM9ipI=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=lF//gPMh4IZ7JGz9ltPnd+NVQwLcrfDWrXXCsze08igi3HH/jOA9CeZ1HYTQXZmrAZTpZkzTd
 KhPz6gzf01HoqqafjMANLMI5ltC5/UUa1+tAfzuMPRP5ZKgUJM6BrZCJr/WtFHHAHvwC9KwXpVU
 ue/DWzmsNs8JDfalJd1R94TCOUoqAK5KOUva1olnZ4dsFZUNN2ubXlniLy37aDVVAGtIJhROqa7
 zAablxk+AEhvgyUk+RGFi4SvThCaLt9lG0FAPFOZUFu6u1uVrX4T3CdJhpBvTrR+hDRbcRquJoy
 ZwZcJejbyaw5LBc8zsdb7YgVF7TQfh8MoNu4s72MkPBg==
X-Zone-Loop: e0465787c52ba03e2322fc009b167e8a3ec347e8619e
x-campaign-type: default
x-transaction-id: ca1f5808-1918-4b1d-ab19-ccf96af2fa07
x-swg-uid: 01-ddb26cfa-a869-405e-a862-3831fc4020b1
X-Mailer: Sweego
Message-ID:
 <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3@vates.tech>
x-swg-bid: 1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1248000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 3/6] automation/qtb: add Python QTB framework with the console-test type
Date: Thu, 27 Aug 2026 11:42:49 +0200
In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823787917
X-purgate-ID: tlsNG-d25034/1787823796-028DDA5B-019E4CE5/0/0
X-purgate-type: clean
X-purgate-size: 30584

Port qemu-smoke-riscv64.sh from shell to a Python QTB framework that drives
QEMU over qtest/QMP and the console to run riscv64 smoke tests.

The framework is based on AMD's QTB (QEMU Test Bench) framework, which is
not yet upstream in QEMU but is planned to be soon. This is a riscv64
adaptation of it.

The framework:
  - parses a test config (config.yaml) into typed machine descriptions
    (config.py). The host device tree of a machine is compiled on first
    use of MachineConfig.dt, so a run that never boots (`list`, or a
    config error) does not invoke dtc.
  - generates the Xen host device tree from a Jinja2 template and compiles
    it to a DTB with dtc (xen_dt.py, dt.py).
  - assembles the QEMU command line in RiscvTestMachine (machine.py),
    resolving artifact paths via paths.py.
  - defines an abstract RiscvQtbTest base shared by every test type
    (qtb_test.py).
  - wires it together behind a CLI: the test type is a leading positional
    with `list` and `run` subcommands (qemu_smoke_riscv64.py).

console-test test type comes with it. It boots a machine from the shared
catalog and asserts every expected string is printed on Xen's own console
within the timeout. Its tests live in console-test.yaml, which maps console
indices to the expected output strings. This makes it straightforward to
add support for a domU console index once Xen provides it.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 automation/scripts/qemu_smoke_riscv64.py      | 122 +++++++++++++++
 automation/scripts/qtb/__init__.py            |   2 +
 automation/scripts/qtb/riscv/__init__.py      |   9 ++
 automation/scripts/qtb/riscv/config.py        | 119 ++++++++++++++
 automation/scripts/qtb/riscv/config.yaml      |  17 ++
 .../qtb/riscv/console_test/__init__.py        |   4 +
 .../qtb/riscv/console_test/console-test.yaml  |  18 +++
 .../qtb/riscv/console_test/console_test.py    | 145 ++++++++++++++++++
 automation/scripts/qtb/riscv/dt.py            |  57 +++++++
 automation/scripts/qtb/riscv/machine.py       |  57 +++++++
 automation/scripts/qtb/riscv/paths.py         |  60 ++++++++
 automation/scripts/qtb/riscv/qtb_test.py      |  53 +++++++
 automation/scripts/qtb/riscv/xen_dt.py        |  58 +++++++
 13 files changed, 721 insertions(+)
 create mode 100755 automation/scripts/qemu_smoke_riscv64.py
 create mode 100644 automation/scripts/qtb/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/config.py
 create mode 100644 automation/scripts/qtb/riscv/config.yaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/console_test/console-test.yaml
 create mode 100644 automation/scripts/qtb/riscv/console_test/console_test.py
 create mode 100644 automation/scripts/qtb/riscv/dt.py
 create mode 100644 automation/scripts/qtb/riscv/machine.py
 create mode 100644 automation/scripts/qtb/riscv/paths.py
 create mode 100644 automation/scripts/qtb/riscv/qtb_test.py
 create mode 100644 automation/scripts/qtb/riscv/xen_dt.py

diff --git a/automation/scripts/qemu_smoke_riscv64.py b/automation/scripts/qemu_smoke_riscv64.py
new file mode 100755
index 0000000000..f338fafcc2
--- /dev/null
+++ b/automation/scripts/qemu_smoke_riscv64.py
@@ -0,0 +1,122 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+"""CLI launcher for the qtb riscv64 dom0less tests.
+
+The test type comes first (e.g. `console-test`), then a command. Each type
+reads its own config file, which ships with the type.
+
+Commands:
+    list  Print every test the type defines in the config, then exit.
+    run   Boot one test's machine under QEMU and drive it to a pass/fail
+          verdict.
+
+Usage:
+    ./qemu_smoke_riscv64.py console-test list
+    ./qemu_smoke_riscv64.py console-test run dom0less-1smp-0domu-1vcpu-aplic-imsic-null
+"""
+
+from __future__ import annotations
+
+import argparse
+import logging
+import sys
+from collections.abc import Sequence
+from traceback import extract_tb, format_exc
+
+from qtb.riscv import RiscvQtbTest, TEST_TYPES, RiscvTestMachine, cleanup_temp_dir
+
+logger = logging.getLogger(__name__)
+
+
+def _run_test(test: RiscvQtbTest, log_dir: str | None) -> int:
+    """Compile the machine's device trees, boot it, and run the test."""
+    vm = RiscvTestMachine(test.machine, timeout=test.timeout, log_dir=log_dir)
+    try:
+        with vm:
+            vm.launch()
+            test.run(vm)
+    except Exception as exc:
+        print(
+            f"FAIL: {test.name}: {type(exc).__name__}: {exc}",
+            file=sys.stderr,
+            flush=True,
+        )
+        return 1
+
+    print(f"PASS: {test.name}", flush=True)
+    return 0
+
+
+def _cmd_list(ns: argparse.Namespace) -> int:
+    """`<type> list`: print every test the type defines."""
+    for name in ns.cls.list_tests(ns.cls.config_file):
+        print(name)
+    return 0
+
+
+def _cmd_run(ns: argparse.Namespace) -> int:
+    """`<type> run`: build the named test and drive it to a verdict."""
+    test = ns.cls.from_config(ns.cls.config_file, ns.test)
+    return _run_test(test, ns.log_dir)
+
+
+def setup_parser() -> argparse.ArgumentParser:
+    parser = argparse.ArgumentParser(
+        description="Launch a qtb riscv64 dom0less test: "
+        "qemu_smoke_riscv64.py <type> <command>.",
+    )
+    common_args = argparse.ArgumentParser(add_help=False)
+    common_args.add_argument(
+        "-v", "--verbose", action="store_true", help="Print debug output"
+    )
+    run_args = argparse.ArgumentParser(add_help=False)
+    run_args.add_argument("test", help="Name of the test to run.")
+    run_args.add_argument(
+        "--log-dir",
+        default=None,
+        metavar="DIR",
+        help="Directory for all logs (QEMU process log, qtest, and the "
+        "consoles as con<N>.log). When unset, no logs are written.",
+    )
+
+    # qemu_smoke_riscv64.py <type> <command>
+    types = parser.add_subparsers(dest="type", required=True)
+    for cls in TEST_TYPES:
+        desc = cls.description
+        cmds = types.add_parser(
+            cls.type_id, help=desc, description=desc
+        ).add_subparsers(dest="command", required=True)
+        cmds.add_parser(
+            "list",
+            parents=[common_args],
+            description=desc,
+            help="List the tests for the type and exit.",
+        ).set_defaults(func=_cmd_list, cls=cls)
+        cmds.add_parser(
+            "run",
+            parents=[common_args, run_args],
+            description=desc,
+            help="Run one test.",
+        ).set_defaults(func=_cmd_run, cls=cls)
+
+    return parser
+
+
+def main(argv: Sequence[str] | None = None) -> int:
+    ns = setup_parser().parse_args(argv)
+    logging.basicConfig(
+        level=logging.DEBUG if ns.verbose else logging.WARNING, format="%(message)s"
+    )
+    try:
+        return ns.func(ns)
+    except Exception as exc:
+        logger.debug(format_exc())
+        frame = extract_tb(exc.__traceback__)[-1]
+        print(f"{frame.filename}:{frame.lineno}: {exc}")
+        return 2
+    finally:
+        cleanup_temp_dir()
+
+
+if __name__ == "__main__":
+    sys.exit(main())
diff --git a/automation/scripts/qtb/__init__.py b/automation/scripts/qtb/__init__.py
new file mode 100644
index 0000000000..a0e6e76cb2
--- /dev/null
+++ b/automation/scripts/qtb/__init__.py
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""QTB (QEMU Test Bench) test frameworks."""
diff --git a/automation/scripts/qtb/riscv/__init__.py b/automation/scripts/qtb/riscv/__init__.py
new file mode 100644
index 0000000000..6a6c48be32
--- /dev/null
+++ b/automation/scripts/qtb/riscv/__init__.py
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""QTB riscv64 test framework package."""
+
+from .qtb_test import RiscvQtbTest
+from .console_test import ConsoleTest
+from .machine import RiscvTestMachine
+from .paths import cleanup_temp_dir
+
+TEST_TYPES: tuple[type[RiscvQtbTest], ...] = (ConsoleTest,)
diff --git a/automation/scripts/qtb/riscv/config.py b/automation/scripts/qtb/riscv/config.py
new file mode 100644
index 0000000000..b5068d6bfb
--- /dev/null
+++ b/automation/scripts/qtb/riscv/config.py
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""YAML config parser for qtb-based Xen riscv64 tests.
+
+Parsing steps:
+    - validate the YAML
+    - build the dataclasses: the host device tree is compiled on first use
+      of MachineConfig.dt
+"""
+
+from __future__ import annotations
+
+import functools
+import inspect
+from dataclasses import dataclass
+from functools import cached_property
+from pathlib import Path
+
+import yaml
+
+from .paths import resolve_binary, resolve_path
+from .xen_dt import DeviceTree, build_xen_device_tree
+
+XEN_MMU_TYPE_DEFAULT: str = "sv48"
+XEN_BOOTARGS_DEFAULT: str = ""
+
+MACHINE_MEMORY: int = 2048
+MACHINE_INTERRUPT_CONTROLLER: str = "aplic-imsic"
+
+
+def required_keys(argument_name: str, keys: set, label: str = ""):
+    """Validate the dict passed as `argument_name` has every key in `keys`."""
+    keys = set(keys)
+
+    def decorate(func):
+        sig = inspect.signature(func)
+
+        @functools.wraps(func)
+        def wrapper(*args, **kwargs):
+            arg = sig.bind(*args, **kwargs).arguments[argument_name]
+            missing = keys - arg.keys()
+            if missing:
+                raise ValueError(
+                    f"{label or func.__name__} missing keys: {sorted(missing)}"
+                )
+            return func(*args, **kwargs)
+
+        return wrapper
+
+    return decorate
+
+
+@dataclass
+class BinariesConfig:
+    xen: Path
+
+
+@required_keys("raw", {"xen"}, label="binaries config")
+def _parse_binaries(raw: dict) -> BinariesConfig:
+    return BinariesConfig(xen=resolve_binary(raw["xen"]))
+
+
+@required_keys("raw", {"pcpu"}, label="machine config")
+def _parse_machine(
+    raw: dict,
+    binaries: BinariesConfig,
+    machine: str,
+) -> MachineConfig:
+    return MachineConfig(
+        name=machine,
+        pcpu=raw["pcpu"],
+        binaries=binaries,
+        mmu_type=raw.get("mmu_type", XEN_MMU_TYPE_DEFAULT),
+        xen_bootargs=raw.get("xen_bootargs", XEN_BOOTARGS_DEFAULT),
+    )
+
+
+@dataclass(frozen=True)
+class MachineConfig:
+    """One named machine: the test-agnostic description of what to boot.
+
+    A machine is reusable across test types; a test (see RiscvQtbTest
+    subclasses) picks a machine by name and layers its own parameters on top.
+    """
+
+    name: str
+    pcpu: int
+    binaries: BinariesConfig
+    mmu_type: str  # Xen (host) MMU type, injected into the host dts cpus.
+    xen_bootargs: str
+
+    @classmethod
+    def from_config(cls, file_name: str, machine: str) -> MachineConfig:
+        """Build only the single named machine from the catalog at `path`.
+
+        A test run boots one machine, so there is no need to construct the
+        whole catalog: parse the YAML, validate the shared binaries, and
+        build just the requested entry.
+        """
+        fpath: Path = resolve_path(file_name)
+        raw: dict = yaml.safe_load(fpath.read_text())
+
+        required = ("binaries", "machines")
+        missing = [k for k in required if k not in raw]
+        if missing:
+            raise ValueError(f"Global config {file_name} missing keys: {missing}")
+
+        binaries: BinariesConfig = _parse_binaries(raw["binaries"])
+
+        machines = raw["machines"]
+        if machine not in machines:
+            known = ", ".join(sorted(machines)) or "(none)"
+            raise ValueError(f"unknown machine {machine!r}; known machines: {known}")
+
+        return _parse_machine(machines[machine], binaries, machine)
+
+    @cached_property
+    def dt(self) -> DeviceTree:
+        """Host device tree, compiled on first use."""
+        return build_xen_device_tree(self)
diff --git a/automation/scripts/qtb/riscv/config.yaml b/automation/scripts/qtb/riscv/config.yaml
new file mode 100644
index 0000000000..94897827b7
--- /dev/null
+++ b/automation/scripts/qtb/riscv/config.yaml
@@ -0,0 +1,17 @@
+# Shared config for the qtb riscv64 tests
+#
+# A machine is the test-agnostic description of what to boot (cpus, Xen command
+# line). Test YAMLs (e.g. console-test.yaml) pick a machine by name and layer
+# their own parameters on top.
+#
+# Path resolution (see paths.py): `binaries:` entries resolve against
+# $QTB_BINARIES_DIR env var if defined else `binaries`. Absolute paths used
+# as-is.
+
+binaries:
+  xen:      xen
+
+machines:
+  dom0less-1smp-0domu-1vcpu-aplic-imsic-null:
+    xen_bootargs: "sched=null"
+    pcpu: 1
diff --git a/automation/scripts/qtb/riscv/console_test/__init__.py b/automation/scripts/qtb/riscv/console_test/__init__.py
new file mode 100644
index 0000000000..5db5569965
--- /dev/null
+++ b/automation/scripts/qtb/riscv/console_test/__init__.py
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""console-test type package."""
+
+from .console_test import ConsoleTest
diff --git a/automation/scripts/qtb/riscv/console_test/console-test.yaml b/automation/scripts/qtb/riscv/console_test/console-test.yaml
new file mode 100644
index 0000000000..cec0edc510
--- /dev/null
+++ b/automation/scripts/qtb/riscv/console_test/console-test.yaml
@@ -0,0 +1,18 @@
+# Console string expectation test (run with: qemu_smoke_riscv64.py console-test run <test>).
+#
+# Each test uses a machine from config.yaml and maps a console index to the list
+# of string(s) expected on that console: 0 is Xen's own console. The runner boots
+# the machine and asserts each string is printed within the timeout. Nothing is
+# injected.
+#
+# Test options:
+#   timeout: int  # timeout between each string match (in seconds)
+#   attempts: int # number of tries for a wait before failing. Default 3 (min = 1)
+
+machine_catalog: config.yaml
+
+tests:
+  dom0less-1smp-0domu-1vcpu-aplic-imsic-null:
+    machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null
+    expect:
+      0: ["All set up"]
diff --git a/automation/scripts/qtb/riscv/console_test/console_test.py b/automation/scripts/qtb/riscv/console_test/console_test.py
new file mode 100644
index 0000000000..95540fd388
--- /dev/null
+++ b/automation/scripts/qtb/riscv/console_test/console_test.py
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Console string expectation test (`type: console-test`).
+
+Per console: assert each expected string is printed within the timeout.
+Nothing is injected; this only watches console output.
+
+YAML (console-test.yaml): each test names the machine it boots (tests may
+share one) and maps a console index to the string(s) expected on it: 0 is
+Xen's own console.
+
+    machine_catalog: config.yaml
+    tests:
+      dom0less-1smp-0domu-1vcpu-aplic-imsic-null:  # test name (run positional)
+        machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null  # from config.yaml
+        expect:                                    # console index -> string(s)
+          0: [All set up]
+"""
+
+from __future__ import annotations
+
+import logging
+from typing import ClassVar
+
+import pexpect
+import yaml
+
+from ..paths import resolve_path
+from ..config import MachineConfig, required_keys
+from ..qtb_test import TIMEOUT_DEFAULT, RiscvQtbTest
+from ..machine import RiscvTestMachine
+
+logger = logging.getLogger(__name__)
+
+TYPE_ID: str = "console-test"
+
+CONFIG_FILE_DEFAULT: str = "console_test/console-test.yaml"
+DESCRIPTION_DEFAULT: str = "Assert expected string(s) are printed on the Xen console"
+ATTEMPTS_DEFAULT: int = 3
+
+XEN_CONS_IDX: int = 0
+
+
+class ConsoleTest(RiscvQtbTest):
+    type_id: ClassVar[str] = TYPE_ID
+    description: ClassVar[str] = DESCRIPTION_DEFAULT
+    config_file: ClassVar[str] = CONFIG_FILE_DEFAULT
+
+    def __init__(self, raw: dict, test_name: str) -> None:
+        self.name, self.data, self.machine = self._parse_test_cfg(raw, test_name)
+
+        self.expect = self.data["expect"]  # expected console string
+
+        self.timeout = int(self.data.get("timeout", TIMEOUT_DEFAULT))
+        if self.timeout < 1:
+            raise ValueError("timeout < 1, must be at least 1")
+
+        self.attempts = int(self.data.get("attempts", ATTEMPTS_DEFAULT))
+        if self.attempts < 1:
+            raise ValueError("attempts < 1, must be at least 1")
+
+    @staticmethod
+    def _load_yaml(path) -> dict:
+        return yaml.safe_load(resolve_path(path).read_text())
+
+    @classmethod
+    def from_config(cls, config_file: str, test_name: str) -> ConsoleTest:
+        return cls(cls._load_yaml(config_file), test_name)
+
+    @staticmethod
+    @required_keys("test_data", {"machine", "expect"})
+    def _parse_test_data(
+        machine_catalog: str, test_data: dict, test_name: str
+    ) -> tuple[str, dict, MachineConfig]:
+        """Parse test data dictionary"""
+        test_machine = MachineConfig.from_config(machine_catalog, test_data["machine"])
+
+        def invalid(why: str) -> ValueError:
+            return ValueError(
+                f"test {test_name!r}: {why}; expected "
+                f"{{{XEN_CONS_IDX}: ['str1', 'str2', ...]}}"
+            )
+
+        expect = test_data["expect"]
+        if not isinstance(expect, dict) or expect.keys() != {XEN_CONS_IDX}:
+            raise invalid(
+                f"expect must map console index {XEN_CONS_IDX} (Xen's own "
+                f"console, the only one) and nothing else, got {expect!r}"
+            )
+        strings = expect[XEN_CONS_IDX]
+        if not isinstance(strings, list):
+            raise invalid(
+                f"{ConsoleTest.config_file} expects a list of string(s), "
+                f"got {type(strings).__name__}"
+            )
+        if not strings:
+            raise invalid("Xen has no expected string")
+        if not all(isinstance(s, str) and s for s in strings):
+            raise invalid(f"Xen expects non-empty strings, got {strings!r}")
+        return (test_name, test_data, test_machine)
+
+    @staticmethod
+    @required_keys("raw", {"machine_catalog", "tests"})
+    def _parse_test_cfg(raw: dict, test_name: str) -> tuple[str, dict, MachineConfig]:
+        """Read the config: return the named test dict and its machine."""
+
+        tests = raw["tests"]
+        if test_name not in tests:
+            known = ", ".join(sorted(tests)) or "(none)"
+            raise ValueError(f"unknown test {test_name!r}; known tests: {known}")
+
+        test_data = tests[test_name]
+        return ConsoleTest._parse_test_data(
+            raw["machine_catalog"], test_data, test_name
+        )
+
+    @staticmethod
+    def list_tests(config_file: str) -> list[str]:
+        tests = ConsoleTest._load_yaml(config_file).get("tests")
+        if not tests:
+            logger.warning("no 'tests' key found in %s", config_file)
+            return []
+        return list(tests)
+
+    @staticmethod
+    def _console(vm: RiscvTestMachine):
+        """Xen's own console (con0)."""
+        if vm.console is None:
+            raise RuntimeError("Xen console not wired up, machine not launched?")
+        return vm.console
+
+    def run(self, vm: RiscvTestMachine) -> None:
+        cons = self._console(vm)
+        for strings in self.expect.values():
+            for s in strings:
+                self._expect_string(cons, s)
+
+    def _expect_string(self, cons, expected: str) -> None:
+        """Wait for `expected` on the console, retrying on timeout."""
+        for attempt in range(self.attempts):
+            try:
+                cons.expect_exact(expected, timeout=self.timeout)
+                return
+            except pexpect.TIMEOUT:
+                if attempt == self.attempts - 1:
+                    raise
diff --git a/automation/scripts/qtb/riscv/dt.py b/automation/scripts/qtb/riscv/dt.py
new file mode 100644
index 0000000000..f0376979e5
--- /dev/null
+++ b/automation/scripts/qtb/riscv/dt.py
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Device tree (DT) handling: compile a .dts source into a .dtb"""
+
+from __future__ import annotations
+
+import logging
+import subprocess
+from pathlib import Path
+
+logger = logging.getLogger(__name__)
+
+
+def _compile_dts(src: Path, out: Path):
+    """Run dtc to compile .dts `src` into the .dtb file at `out`"""
+    try:
+        p = subprocess.run(
+            ["dtc", "-I", "dts", "-O", "dtb", "-o", str(out), str(src)],
+            check=True,
+            capture_output=True,
+            text=True,
+        )
+        logger.debug("dtc %s: stdout: %s stderr: %s", src, p.stdout, p.stderr)
+
+    except FileNotFoundError as e:
+        raise RuntimeError("dtc not found in PATH; install device-tree-compiler") from e
+    except subprocess.CalledProcessError as e:
+        raise RuntimeError(
+            f"dtc failed on {str(src)!r} (exit {e.returncode}):\n"
+            f" stdout: {e.stdout}\n stderr: {e.stderr}"
+        ) from e
+
+
+def compile_to_dtb(src: Path, out: Path) -> Path:
+    """
+    Compile a .dts source to a .dtb under out dir and return the .dtb path.
+
+    Raises FileNotFoundError if `src` or `out` don't exist.
+    """
+    if not src.exists():
+        raise FileNotFoundError(
+            f"Device tree source {str(src)!r} not found"
+        )
+
+    if not out.exists():
+        raise FileNotFoundError(f"Device Tree output dir: {out} doesn't exist")
+
+    dtb = out / (src.stem + ".dtb")
+    _compile_dts(src, dtb)
+    return dtb
+
+
+def write_dts(text: str, name: str, out_dir: Path) -> Path:
+    """Write generated .dts text to <out_dir>/<name>.dts; return its path."""
+    src = out_dir / f"{name}.dts"
+    src.parent.mkdir(parents=True, exist_ok=True)
+    src.write_text(text)
+    return src
diff --git a/automation/scripts/qtb/riscv/machine.py b/automation/scripts/qtb/riscv/machine.py
new file mode 100644
index 0000000000..74a05dfc82
--- /dev/null
+++ b/automation/scripts/qtb/riscv/machine.py
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""QtbMachine for riscv64."""
+
+from __future__ import annotations
+
+from collections.abc import Sequence
+
+from qemu.qtb import QtbMachine
+
+from .config import MACHINE_INTERRUPT_CONTROLLER, MACHINE_MEMORY, MachineConfig
+from .paths import resolve_from_path
+
+
+class RiscvTestMachine(QtbMachine):
+    arch_name = "riscv64"
+    gdb_arch = "riscv:rv64"
+
+    qemu_bin = "qemu-system-riscv64"
+
+    def __init__(
+        self,
+        mc: MachineConfig,
+        *,
+        timeout: int,
+        log_dir: str | None = None,
+    ) -> None:
+        self.machine_conf = mc
+        super().__init__(
+            memory=MACHINE_MEMORY,
+            cpus=mc.pcpu,
+            mirror_console=False,
+            timeout=timeout,
+            log_dir=log_dir,
+        )
+
+    def _machine_args(self, memory: int, cpus: int) -> Sequence[str]:
+        machine = self.machine_conf
+        machine_opt = f"virt,aclint=off,aia={MACHINE_INTERRUPT_CONTROLLER}"
+        # Xen has no sstc support yet.
+        cpu_opt = "rv64,svpbmt=on,smstateen=on,sstc=off"
+        return [
+            "-dtb",
+            str(machine.dt.dtb),
+            "-M",
+            machine_opt,
+            "-cpu",
+            cpu_opt,
+            "-smp",
+            str(cpus),
+            "-m",
+            str(memory),
+            "-kernel",
+            str(machine.binaries.xen),
+        ]
+
+    def _resolve_binary(self) -> str:
+        return str(resolve_from_path(self.qemu_bin))
diff --git a/automation/scripts/qtb/riscv/paths.py b/automation/scripts/qtb/riscv/paths.py
new file mode 100644
index 0000000000..237f1bf502
--- /dev/null
+++ b/automation/scripts/qtb/riscv/paths.py
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Path helpers: resolve pkg-relative paths."""
+
+from __future__ import annotations
+
+import os
+import shutil
+import tempfile
+from functools import lru_cache
+from pathlib import Path
+
+# Every relative path in this module is resolved against this base.
+_BASE = Path(__file__).resolve().parent
+
+# Build artifacts, overridable for CI.
+_BINARIES_BASE = Path(os.environ.get("QTB_BINARIES_DIR") or _BASE / "binaries")
+
+
+@lru_cache(maxsize=1)
+def _temp_dir_handle() -> tempfile.TemporaryDirectory:
+    return tempfile.TemporaryDirectory(prefix="qtb-")
+
+
+def temp_dir() -> Path:
+    """Process-wide scratch dir for generated/compiled artifacts (singleton)."""
+    return Path(_temp_dir_handle().name)
+
+
+def cleanup_temp_dir() -> None:
+    """Remove the scratch dir, if one was created, and clear the cache."""
+    if _temp_dir_handle.cache_info().currsize:
+        _temp_dir_handle().cleanup()
+        _temp_dir_handle.cache_clear()
+
+
+def resolve_path(file_name: str) -> Path:
+    """Resolve `file_name` against _BASE, absolute paths pass through."""
+    return _resolve_under(file_name, _BASE)
+
+
+def resolve_binary(file_name: str) -> Path:
+    """Resolve a build artifact against _BINARIES_BASE, absolute paths pass through."""
+    return _resolve_under(file_name, _BINARIES_BASE)
+
+
+def resolve_from_path(file_name: str) -> Path:
+    """Resolve an executable on $PATH, absolute paths pass through."""
+    path = shutil.which(file_name)
+    if not path:
+        raise FileNotFoundError(f"cannot resolve {file_name!r}: not an executable on $PATH")
+    return Path(path)
+
+
+def _resolve_under(file_name: str, base: Path) -> Path:
+    """Resolve `file_name` against `base`, absolute paths pass through."""
+    p = Path(file_name)
+    path = p if p.is_absolute() else base / p
+    if not path.exists():
+        raise FileNotFoundError(f"cannot resolve {str(path)!r}: does not exist")
+    return path
diff --git a/automation/scripts/qtb/riscv/qtb_test.py b/automation/scripts/qtb/riscv/qtb_test.py
new file mode 100644
index 0000000000..872fbc2fa9
--- /dev/null
+++ b/automation/scripts/qtb/riscv/qtb_test.py
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Abstract base for the qtb riscv64 test types.
+
+A test type is a RiscvQtbTest subclass owning a config file that describes its
+tests, each bound to a machine from the shared catalog.
+"""
+
+from __future__ import annotations
+
+from abc import ABC, abstractmethod
+from typing import ClassVar
+
+from .config import MachineConfig
+from .machine import RiscvTestMachine
+
+# Default per-test timeout (seconds)
+TIMEOUT_DEFAULT: int = 120
+
+
+class RiscvQtbTest(ABC):
+    """One runnable test bound to the machine it boots.
+
+    A subclass sets `type_id`, `description`, and `config_file`, and implements
+    `from_config` to parse its config file, `list_tests` to enumerate the tests
+    it declares, and `run` to drive the test logic.
+    """
+
+    # Set by each concrete subclass.
+    type_id: ClassVar[str] = ""
+    # One-line summary of what the type does, shown in the CLI help.
+    description: ClassVar[str] = ""
+    # Config file the type reads its tests from, resolved pkg-relative.
+    config_file: ClassVar[str] = ""
+
+    # Set by the subclass parser.
+    name: str
+    data: dict
+    machine: MachineConfig
+    timeout: int = TIMEOUT_DEFAULT
+
+    @classmethod
+    @abstractmethod
+    def from_config(cls, config_file: str, test_name: str) -> RiscvQtbTest:
+        """Build the test named `test_name` from `config_file`."""
+
+    @staticmethod
+    @abstractmethod
+    def list_tests(config_file: str) -> list[str]:
+        """Return the names of every test declared in the config file."""
+
+    @abstractmethod
+    def run(self, vm: RiscvTestMachine) -> None:
+        """Drive the running machine and assert the expected result."""
diff --git a/automation/scripts/qtb/riscv/xen_dt.py b/automation/scripts/qtb/riscv/xen_dt.py
new file mode 100644
index 0000000000..8881b01b36
--- /dev/null
+++ b/automation/scripts/qtb/riscv/xen_dt.py
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Build the Xen host device tree for a MachineConfig.
+
+The tree is rendered from its Jinja2 template (dts/qemu-host.dts.j2), which
+takes the hart count, the Xen MMU type and the Xen command line, then compiled
+to a DTB with dtc.
+"""
+
+from __future__ import annotations
+
+from dataclasses import dataclass
+from functools import lru_cache
+from pathlib import Path
+from typing import TYPE_CHECKING
+from jinja2 import Environment, FileSystemLoader
+
+from .paths import resolve_path, temp_dir
+from .dt import compile_to_dtb, write_dts
+
+if TYPE_CHECKING:  # config imports this module, so only import it for typing.
+    from .config import MachineConfig
+
+# Directory holding the Jinja2 platform device tree templates.
+_DTS_DIR = "dts"
+
+
+@dataclass(frozen=True)
+class DeviceTree:
+    """Compiled device trees for one machine launch."""
+
+    dts: Path
+    dtb: Path
+
+
+@lru_cache(maxsize=1)
+def _env() -> Environment:
+    return Environment(
+        loader=FileSystemLoader(resolve_path(_DTS_DIR)),
+        keep_trailing_newline=True,
+    )
+
+
+def _render_xen_dts(machine: MachineConfig) -> str:
+    """Render the Xen host device tree source text for `machine`."""
+    tmpl = _env().get_template("qemu-host.dts.j2")
+    return tmpl.render(
+        ncpus=machine.pcpu,
+        mmu_type=machine.mmu_type,
+        xen_bootargs=machine.xen_bootargs,
+    )
+
+
+def build_xen_device_tree(machine: MachineConfig) -> DeviceTree:
+    """Compile `machine` device tree into the shared scratch dir."""
+    out = temp_dir()
+    dts: Path = write_dts(_render_xen_dts(machine), machine.name, out)
+    dtb: Path = compile_to_dtb(dts, out)
+    return DeviceTree(dts=dts, dtb=dtb)


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:43:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:43:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400482.1636154 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdj-0005xi-F4; Thu, 27 Aug 2026 09:43:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400482.1636154; Thu, 27 Aug 2026 09:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdj-0005xO-97; Thu, 27 Aug 2026 09:43:19 +0000
Received: by outflank-mailman (input) for mailman id 1400482;
 Thu, 27 Aug 2026 09:43:17 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@swg.vates.tech>)
 id 1wzWdh-0005t6-Fg
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:43:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWdg-00Fwyk-Sf
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:43:16 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@swg.vates.tech>)
 id 6a9006ab-2eae-0a2a0a5409dd-0a2a450c8740-18
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:16 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@swg.vates.tech>)
 id 6a9006b4-f479-0a2a450c0019-b9ff1c23ac25-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:16 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0429a13b8000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:43:08 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 4AE4483B2D;
 Thu, 27 Aug 2026 11:43:08 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=6mJ8pRhovm2+57Ktp8ucrhFg2lizqcmzFInUehED0eY=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=ntsIHfGb7RobZHhoTvpUvXEdWsN0TRDx0g5GdBbPfCEwb3ZOL7/1dRdhZdw9Y7zpQf9v6JeNG
 SIQHeAQI1b8SbBQO21UeAUDtapmexb+1oscdZR34Ux08Ego/CeI1aYDGwTMmuLvPguO6BcpIlAX
 Iiwtn412nN5k8umuzKqNmr2SmT3YkagWsmCxtBh4ykP0+CWt4rEitm8EOk1YuSYa9zDQN6ZMeze
 V7u9TncLzlIvXHYgtaTpYH9U4BgkPv4tYxxAPicT/hAwhZgSOaAWjaiIUXbluz04fMbyw+C+eFy
 wIeVB9NEENP4eDY2CW+l/CM8W28xujnoanN3tl+o60Bg==
X-Zone-Loop: f549f6904b0c164413a1efaa9959808997ab1665a6b7
x-campaign-type: default
x-transaction-id: 616ba5a6-bfce-46ac-a600-21a132984cd4
x-swg-uid: 01-2acc789e-fd0d-4ed6-8569-fac68cd69c8a
X-Mailer: Sweego
Message-ID:
 <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3@vates.tech>
x-swg-bid: 1787823789.8631fc262581453bbf619ec5b2062170.1a0429a13b8000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 4/6] automation/qtb: add unit tests for the QTB framework
Date: Thu, 27 Aug 2026 11:42:50 +0200
In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823788399
X-purgate-ID: tlsNG-d25034/1787823796-01AC4A5B-345BE6C6/0/0
X-purgate-type: clean
X-purgate-size: 24135

The QTB framework is meant to be extended: new test types, new machines and
new device trees aim to be added by other people.

Add pytest coverage of the framework's functions, and of the console-test
type's config validation and expect/retry loop, so that such changes get
immediate feedback and existing behaviour does not silently regress.

The suite covers 100% of the framework's statements, so a new code path
added without a test shows up as a coverage drop.

The tests are meant to be run locally, from the Xen tree root:

    python3 -m pytest automation/scripts/qtb/riscv/unit/

and, with pytest-cov installed, the coverage report is:

    python3 -m pytest --cov=automation/scripts/qtb \
        automation/scripts/qtb/riscv/unit/

The tests drive fakes rather than QEMU, so they need no artifacts to run.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 automation/scripts/qtb/riscv/unit/__init__.py |   2 +
 automation/scripts/qtb/riscv/unit/conftest.py |  42 ++++
 .../scripts/qtb/riscv/unit/test_config.py     | 121 ++++++++++
 .../qtb/riscv/unit/test_console_test.py       | 217 ++++++++++++++++++
 automation/scripts/qtb/riscv/unit/test_dt.py  |  99 ++++++++
 .../scripts/qtb/riscv/unit/test_machine.py    |  60 +++++
 .../scripts/qtb/riscv/unit/test_temp_dir.py   |  42 ++++
 .../scripts/qtb/riscv/unit/test_xen_dt.py     |  46 ++++
 8 files changed, 629 insertions(+)
 create mode 100644 automation/scripts/qtb/riscv/unit/__init__.py
 create mode 100644 automation/scripts/qtb/riscv/unit/conftest.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_config.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_console_test.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_dt.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_machine.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_temp_dir.py
 create mode 100644 automation/scripts/qtb/riscv/unit/test_xen_dt.py

diff --git a/automation/scripts/qtb/riscv/unit/__init__.py b/automation/scripts/qtb/riscv/unit/__init__.py
new file mode 100644
index 0000000000..b234dc5303
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/__init__.py
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""pytest tests of the framework's own logic."""
diff --git a/automation/scripts/qtb/riscv/unit/conftest.py b/automation/scripts/qtb/riscv/unit/conftest.py
new file mode 100644
index 0000000000..576eaf13b1
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/conftest.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Shared pytest fixtures for the qtb unit tests."""
+
+from __future__ import annotations
+
+import pytest
+
+from ..config import MachineConfig
+
+
+@pytest.fixture
+def make_file(tmp_path):
+    """Return a factory creating a file of `size` bytes, yielding its path."""
+
+    def _make(name: str, size: int = 16) -> str:
+        p = tmp_path / name
+        p.write_bytes(b"\0" * size)
+        return str(p)
+
+    return _make
+
+
+@pytest.fixture
+def make_machine():
+    """Return a factory building a MachineConfig for tests."""
+
+    def _make(
+        *,
+        name="m",
+        binaries=None,
+        mmu="sv48",
+        xen_bootargs="",
+    ) -> MachineConfig:
+        return MachineConfig(
+            name=name,
+            pcpu=4,
+            binaries=binaries,
+            mmu_type=mmu,
+            xen_bootargs=xen_bootargs,
+        )
+
+    return _make
diff --git a/automation/scripts/qtb/riscv/unit/test_config.py b/automation/scripts/qtb/riscv/unit/test_config.py
new file mode 100644
index 0000000000..422ba2a5ea
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_config.py
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Unit tests for the YAML machine-catalog parser."""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+import pytest
+import yaml
+
+from ..config import (
+    XEN_BOOTARGS_DEFAULT,
+    XEN_MMU_TYPE_DEFAULT,
+    MachineConfig,
+    _parse_binaries,
+)
+
+
+@pytest.fixture
+def binaries(make_file):
+    """Raw binaries dict pointing at an existing file."""
+    return {"xen": make_file("xen")}
+
+
+# ---- _parse_binaries ----
+
+
+def test_parse_binaries_resolves_existing_paths(binaries):
+    assert _parse_binaries(binaries).xen == Path(binaries["xen"])
+
+
+def test_parse_binaries_missing_key_raises(binaries):
+    del binaries["xen"]
+    with pytest.raises(ValueError, match="missing keys"):
+        _parse_binaries(binaries)
+
+
+def test_parse_binaries_missing_file_raises(binaries, tmp_path):
+    binaries["xen"] = str(tmp_path / "absent")
+    with pytest.raises(FileNotFoundError):
+        _parse_binaries(binaries)
+
+
+# ---- MachineConfig.from_config ----
+
+
+def _write_yaml(tmp_path, binaries, name="machine-a", **machine_overrides):
+    machine = {
+        "pcpu": 1,
+        "xen_bootargs": "com1=poll sched=null",
+    }
+    machine.update(machine_overrides)
+    doc = {"binaries": binaries, "machines": {name: machine}}
+    path = tmp_path / "config.yaml"
+    path.write_text(yaml.safe_dump(doc))
+    return str(path)
+
+
+def test_from_config_builds_machineconfig(tmp_path, binaries):
+    path = _write_yaml(tmp_path, binaries)
+
+    mc = MachineConfig.from_config(path, "machine-a")
+
+    assert mc.name == "machine-a"
+    assert mc.pcpu == 1
+    assert mc.xen_bootargs == "com1=poll sched=null"
+    assert mc.binaries.xen == Path(binaries["xen"])
+
+
+def test_from_config_applies_optional_defaults(tmp_path, binaries):
+    # A machine with only the required keys falls back to the module defaults.
+    path = _write_yaml(
+        tmp_path,
+        binaries,
+        name="bare",
+        mmu_type=None,
+        xen_bootargs=None,
+    )
+    # Drop the keys set to None so the parser sees them as absent.
+    doc = yaml.safe_load(Path(path).read_text())
+    for k in ("mmu_type", "xen_bootargs"):
+        doc["machines"]["bare"].pop(k, None)
+    Path(path).write_text(yaml.safe_dump(doc))
+
+    mc = MachineConfig.from_config(path, "bare")
+
+    assert mc.mmu_type == XEN_MMU_TYPE_DEFAULT
+    assert mc.xen_bootargs == XEN_BOOTARGS_DEFAULT
+
+
+def test_from_config_missing_machine_key_raises(tmp_path, binaries):
+    path = _write_yaml(tmp_path, binaries, name="bare")
+    doc = yaml.safe_load(Path(path).read_text())
+    del doc["machines"]["bare"]["pcpu"]
+    Path(path).write_text(yaml.safe_dump(doc))
+
+    with pytest.raises(ValueError, match="machine config missing keys"):
+        MachineConfig.from_config(path, "bare")
+
+
+def test_from_config_missing_top_level_key_raises(tmp_path, binaries):
+    path = _write_yaml(tmp_path, binaries)
+    doc = yaml.safe_load(Path(path).read_text())
+    del doc["binaries"]
+    Path(path).write_text(yaml.safe_dump(doc))
+
+    with pytest.raises(ValueError, match="missing keys: \\['binaries'\\]"):
+        MachineConfig.from_config(path, "machine-a")
+
+
+def test_from_config_unknown_machine_raises(tmp_path, binaries):
+    path = _write_yaml(tmp_path, binaries)
+    with pytest.raises(ValueError, match="unknown machine 'nope'"):
+        MachineConfig.from_config(path, "nope")
+
+
+def test_from_config_missing_binary_raises(tmp_path, binaries):
+    binaries["xen"] = str(tmp_path / "gone")
+    path = _write_yaml(tmp_path, binaries)
+    with pytest.raises(FileNotFoundError):
+        MachineConfig.from_config(path, "machine-a")
diff --git a/automation/scripts/qtb/riscv/unit/test_console_test.py b/automation/scripts/qtb/riscv/unit/test_console_test.py
new file mode 100644
index 0000000000..cf15ed3b1b
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_console_test.py
@@ -0,0 +1,217 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Unit tests for the console-test test type (console_test.py)."""
+
+from __future__ import annotations
+
+from itertools import chain, repeat
+from unittest import mock
+
+import pexpect
+import pytest
+
+from ..console_test.console_test import ConsoleTest
+from ..config import MachineConfig
+
+
+# ---- helpers ----
+
+
+def _parse_test_data(machine, expect, name="dummy"):
+    """Validate `expect` against `machine`, without reading a catalog file."""
+    test_data = {"machine": "box", "expect": expect}
+    with mock.patch.object(MachineConfig, "from_config", return_value=machine):
+        return ConsoleTest._parse_test_data("config.yaml", test_data, name)
+
+
+def _console(fail_times: int = 0, matches: int = 1) -> mock.Mock:
+    """Stand in for a pexpect spawn: `fail_times` timeouts, then `matches` hits.
+
+    Every wait past `matches` times out, so a test that waits more often than it
+    should fails instead of silently passing.
+    """
+    cons = mock.Mock()
+    cons.expect_exact.side_effect = chain(
+        [pexpect.TIMEOUT("nope")] * fail_times,
+        [None] * matches,
+        repeat(pexpect.TIMEOUT("nope")),
+    )
+    return cons
+
+
+def _asked(cons: mock.Mock) -> list[str]:
+    """The strings waited for on `cons`, one entry per attempt (matched or not)."""
+    return [call.args[0] for call in cons.expect_exact.call_args_list]
+
+
+def _test(expect, machine, **opts):
+    """Build a ConsoleTest bound to `machine`, skipping the YAML read."""
+    raw = {
+        "machine_catalog": "config.yaml",
+        "tests": {"dummy": {"machine": "box", "expect": expect, **opts}},
+    }
+    with mock.patch.object(MachineConfig, "from_config", return_value=machine):
+        return ConsoleTest(raw, "dummy")
+
+
+# ---- _parse_test_data ----
+
+
+def test_parse_test_data_accepts_a_list_of_strings(make_machine):
+    machine = make_machine()
+    name, data, got = _parse_test_data(machine, {0: ["Hello", "All set up"]})
+    assert (name, got) == ("dummy", machine)
+    assert data["expect"] == {0: ["Hello", "All set up"]}
+
+
+def test_parse_test_data_bare_string_raises(make_machine):
+    # A bare string is refused, not wrapped: the YAML must spell out the list.
+    machine = make_machine()
+    with pytest.raises(ValueError, match="expects a list of string"):
+        _parse_test_data(machine, {0: "All set up"})
+
+
+@pytest.mark.parametrize(
+    "expect",
+    [
+        {-1: ["All set up"]},  # console index below Xen's
+        {1: ["All set up"]},  # console index above Xen's
+        {0: ["All set up"], 1: ["More"]},  # Xen's + another unknown
+        ["All set up"],  # no console index
+        None,
+        "All set up",  # not a map at all
+    ],
+)
+def test_parse_test_data_not_the_xen_console_map_raises(expect, make_machine):
+    machine = make_machine()
+    with pytest.raises(ValueError, match="must map console index 0"):
+        _parse_test_data(machine, expect)
+
+
+def test_parse_test_data_empty_list_raises(make_machine):
+    machine = make_machine()
+    with pytest.raises(ValueError, match="Xen has no expected string"):
+        _parse_test_data(machine, {0: []})
+
+
+def test_parse_test_data_empty_string_in_list_raises(make_machine):
+    machine = make_machine()
+    with pytest.raises(ValueError, match="Xen expects non-empty strings"):
+        _parse_test_data(machine, {0: ["All set up", ""]})
+
+
+def test_parse_test_data_missing_expect_raises():
+    with pytest.raises(ValueError, match="missing keys"):
+        ConsoleTest._parse_test_data("config.yaml", {"machine": "box"}, "dummy")
+
+
+# ---- _parse_test_cfg ----
+
+
+def test_parse_test_cfg_missing_machine_catalog_raises():
+    with pytest.raises(ValueError, match="missing keys"):
+        ConsoleTest._parse_test_cfg({"tests": {}}, "dummy")
+
+
+def test_parse_test_cfg_unknown_test_raises():
+    raw = {"machine_catalog": "config.yaml", "tests": {"a": {}}}
+    with pytest.raises(ValueError, match="unknown test 'dummy'"):
+        ConsoleTest._parse_test_cfg(raw, "dummy")
+
+
+# ---- __init__ ----
+
+
+def test_timeout_and_attempts_are_read(make_machine):
+    test = _test({0: ["All set up"]}, make_machine(), timeout=7, attempts=2)
+    assert (test.timeout, test.attempts) == (7, 2)
+
+
+def test_timeout_below_one_raises(make_machine):
+    with pytest.raises(ValueError, match="timeout < 1"):
+        _test({0: ["All set up"]}, make_machine(), timeout=0)
+
+
+def test_attempts_below_one_raises(make_machine):
+    with pytest.raises(ValueError, match="attempts < 1"):
+        _test({0: ["All set up"]}, make_machine(), attempts=0)
+
+
+# ---- run ----
+
+
+def test_run_expects_each_string_in_order_on_con0(make_machine):
+    test = _test({0: ["first", "then"]}, make_machine())
+    vm = mock.Mock(console=_console(matches=2))
+
+    test.run(vm)
+
+    assert _asked(vm.console) == ["first", "then"]
+
+
+def test_run_xen_console_not_wired_raises(make_machine):
+    test = _test({0: ["All set up"]}, make_machine())
+    vm = mock.Mock(console=None)
+
+    with pytest.raises(RuntimeError, match="not launched"):
+        test.run(vm)
+
+
+# ---- _expect_string ----
+
+
+def test_expect_string_retries_after_a_timeout(make_machine):
+    test = _test({0: ["All set up"]}, make_machine(), attempts=3)
+    cons = _console(fail_times=2)
+
+    test._expect_string(cons, "All set up")
+
+    assert _asked(cons) == ["All set up"] * 3
+
+
+def test_expect_string_raises_once_attempts_are_spent(make_machine):
+    test = _test({0: ["All set up"]}, make_machine(), attempts=2)
+    cons = _console(matches=0)
+
+    with pytest.raises(pexpect.TIMEOUT):
+        test._expect_string(cons, "All set up")
+
+    assert _asked(cons) == ["All set up"] * 2
+
+
+# ---- config IO ----
+
+
+def test_list_tests_reads_the_type_yaml():
+    names = ConsoleTest.list_tests("console_test/console-test.yaml")
+    assert "dom0less-1smp-0domu-1vcpu-aplic-imsic-null" in names
+
+
+def test_list_tests_without_a_tests_key_returns_empty():
+    with mock.patch.object(ConsoleTest, "_load_yaml", return_value={}):
+        assert ConsoleTest.list_tests("console-test.yaml") == []
+
+
+def test_from_config_builds_instance(make_machine):
+    machine = make_machine()
+
+    raw = {
+        "machine_catalog": "config.yaml",
+        "tests": {"dummy": {"machine": "box", "expect": {0: ["All set up"]}}},
+    }
+    # Mock the YAML read and the catalog lookup: only the build logic is under test.
+    with (
+        mock.patch.object(ConsoleTest, "_load_yaml", return_value=raw),
+        mock.patch.object(MachineConfig, "from_config", return_value=machine),
+    ):
+        test = ConsoleTest.from_config("console-test.yaml", "dummy")
+
+    assert test.name == "dummy"
+    assert test.type_id == "console-test"
+    assert test.machine is machine
+    assert test.expect == {0: ["All set up"]}
+
+
+def test_from_config_unknown_test_raises():
+    # Also pins from_config's argument order (config file, then test name).
+    with pytest.raises(ValueError, match="unknown test 'nope'"):
+        ConsoleTest.from_config("console_test/console-test.yaml", "nope")
diff --git a/automation/scripts/qtb/riscv/unit/test_dt.py b/automation/scripts/qtb/riscv/unit/test_dt.py
new file mode 100644
index 0000000000..2201a8651f
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_dt.py
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Unit tests for the device-tree compile path (dt.py)."""
+
+from __future__ import annotations
+
+import shutil
+from unittest import mock
+
+import pytest
+
+from .. import dt
+
+_HAS_DTC = shutil.which("dtc") is not None
+_MINIMAL_DTS = "/dts-v1/;\n/ { };\n"
+
+
+# ---- _compile_dts (dtc wrapper) ----
+
+
+def test_compile_dts_invokes_dtc(tmp_path):
+    src = tmp_path / "in.dts"
+    src.write_text(_MINIMAL_DTS)
+    dtb = tmp_path / "in.dtb"
+
+    with mock.patch.object(dt.subprocess, "run") as run:
+        dt._compile_dts(src, dtb)
+
+    run.assert_called_once()
+    argv = run.call_args.args[0]
+    assert argv == ["dtc", "-I", "dts", "-O", "dtb", "-o", str(dtb), str(src)]
+    assert run.call_args.kwargs["check"] is True
+    assert run.call_args.kwargs["capture_output"] is True
+
+
+def test_compile_dts_missing_dtc_raises_runtimeerror(tmp_path):
+    src, dtb = tmp_path / "a.dts", tmp_path / "a.dtb"
+    src.write_text(_MINIMAL_DTS)
+
+    with mock.patch.object(dt.subprocess, "run", side_effect=FileNotFoundError):
+        with pytest.raises(RuntimeError, match="dtc not found"):
+            dt._compile_dts(src, dtb)
+
+
+def test_compile_dts_dtc_failure_raises_runtimeerror(tmp_path):
+    src, dtb = tmp_path / "a.dts", tmp_path / "a.dtb"
+    src.write_text(_MINIMAL_DTS)
+    err = dt.subprocess.CalledProcessError(1, "dtc", output="out", stderr="syntax error")
+
+    with mock.patch.object(dt.subprocess, "run", side_effect=err):
+        with pytest.raises(RuntimeError, match="syntax error"):
+            dt._compile_dts(src, dtb)
+
+
+# ---- compile_to_dtb path handling ----
+
+
+def test_compile_to_dtb_missing_source_raises_filenotfound(tmp_path):
+    with pytest.raises(FileNotFoundError, match="not found"):
+        dt.compile_to_dtb(tmp_path / "nope.dts", tmp_path)
+
+
+def test_compile_to_dtb_missing_out_dir_raises_filenotfound(tmp_path):
+    src = tmp_path / "a.dts"
+    src.write_text(_MINIMAL_DTS)
+
+    with pytest.raises(FileNotFoundError, match="doesn't exist"):
+        dt.compile_to_dtb(src, tmp_path / "absent")
+
+
+def test_compile_to_dtb_source_goes_to_out_dir_with_dtb_suffix(tmp_path):
+    src = tmp_path / "host-1smp.dts"
+    src.write_text(_MINIMAL_DTS)
+    out = tmp_path / "binaries"
+    out.mkdir()
+
+    with mock.patch.object(dt, "_compile_dts") as compile_mock:
+        result = dt.compile_to_dtb(src, out)
+
+    assert result == out / "host-1smp.dtb"
+    compile_mock.assert_called_once_with(src, out / "host-1smp.dtb")
+
+
+# ---- write_dts ----
+
+
+def test_write_dts_writes_source_under_out_dir(tmp_path):
+    src = dt.write_dts(_MINIMAL_DTS, name="unit", out_dir=tmp_path)
+
+    assert src == tmp_path / "unit.dts"
+    assert src.read_text() == _MINIMAL_DTS
+
+
+@pytest.mark.skipif(not _HAS_DTC, reason="dtc not installed")
+def test_write_then_compile_produces_dtb(tmp_path):
+    src = dt.write_dts(_MINIMAL_DTS, name="unit", out_dir=tmp_path)
+    dtb = dt.compile_to_dtb(src, tmp_path)
+
+    assert dtb.is_file()
+    assert dtb.suffix == ".dtb"
diff --git a/automation/scripts/qtb/riscv/unit/test_machine.py b/automation/scripts/qtb/riscv/unit/test_machine.py
new file mode 100644
index 0000000000..68a1564072
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_machine.py
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Unit tests for RiscvTestMachine QEMU argument assembly."""
+
+from __future__ import annotations
+
+from stat import S_IEXEC
+from unittest import mock
+
+from ..machine import RiscvTestMachine
+from ..config import MACHINE_MEMORY, BinariesConfig
+
+
+def _binaries(tmp_path):
+    xen = tmp_path / "xen"
+    xen.write_bytes(b"")
+    return BinariesConfig(xen=xen)
+
+
+def _machine(mc) -> RiscvTestMachine:
+    """Build the machine with QtbMachine.__init__ stubbed out (it spawns QEMU)."""
+    with mock.patch("qemu.qtb.QtbMachine.__init__", return_value=None):
+        return RiscvTestMachine(mc, timeout=30)
+
+
+def test_init_forwards_cpus_to_qtbmachine(tmp_path, make_machine):
+    mc = make_machine(name="machine", binaries=_binaries(tmp_path))
+
+    with mock.patch("qemu.qtb.QtbMachine.__init__", return_value=None) as base_init:
+        vm = RiscvTestMachine(mc, timeout=30, log_dir="/logs")
+
+    assert vm.machine_conf is mc
+    assert base_init.call_args.kwargs == {
+        "memory": MACHINE_MEMORY,
+        "cpus": mc.pcpu,
+        "mirror_console": False,
+        "timeout": 30,
+        "log_dir": "/logs",
+    }
+
+
+def test_resolve_qemu_on_path(tmp_path, make_machine, monkeypatch):
+    qemu = tmp_path / "qemu-system-riscv64"
+    qemu.write_bytes(b"")
+    qemu.chmod(S_IEXEC)
+    monkeypatch.setenv("PATH", str(tmp_path))
+    mc = make_machine(name="machine", binaries=_binaries(tmp_path))
+
+    assert _machine(mc)._resolve_binary() == str(qemu)
+
+
+
+def test_machine_args_wires_kernel_and_dtb_but_no_bios(tmp_path, make_machine):
+    mc = make_machine(name="machine", binaries=_binaries(tmp_path))
+
+    args = list(_machine(mc)._machine_args(memory=2048, cpus=4))
+
+    assert args[args.index("-kernel") + 1] == str(mc.binaries.xen)
+    assert args[args.index("-dtb") + 1] == str(mc.dt.dtb)
+    assert args[args.index("-m") + 1] == "2048"
+    assert args[args.index("-smp") + 1] == "4"
diff --git a/automation/scripts/qtb/riscv/unit/test_temp_dir.py b/automation/scripts/qtb/riscv/unit/test_temp_dir.py
new file mode 100644
index 0000000000..d595d824d7
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_temp_dir.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Unit tests for the temp_dir scratch-directory singleton."""
+
+from __future__ import annotations
+
+import pytest
+
+from .. import paths
+
+
+@pytest.fixture(autouse=True)
+def _reset_singleton():
+    # Force each test to begin with fresh temp dir
+    yield
+    paths.cleanup_temp_dir()
+
+
+def test_temp_dir_exists_and_prefixed():
+    d = paths.temp_dir()
+    assert d.is_dir()
+    assert d.name.startswith("qtb-")
+
+
+def test_temp_dir_is_singleton():
+    assert paths.temp_dir() == paths.temp_dir()
+
+
+def test_temp_dir_handle_kept_alive():
+    h = paths._temp_dir_handle()
+    assert h is paths._temp_dir_handle()
+    assert h.name == str(paths.temp_dir())
+
+
+def test_cleanup_temp_dir_removes_and_resets():
+    d = paths.temp_dir()
+    assert d.is_dir()
+    paths.cleanup_temp_dir()
+    assert not d.exists()
+    # Cache reset: next call builds a fresh, existing dir, not the gone one.
+    fresh = paths.temp_dir()
+    assert fresh.is_dir()
+    assert fresh != d
diff --git a/automation/scripts/qtb/riscv/unit/test_xen_dt.py b/automation/scripts/qtb/riscv/unit/test_xen_dt.py
new file mode 100644
index 0000000000..37c4055b31
--- /dev/null
+++ b/automation/scripts/qtb/riscv/unit/test_xen_dt.py
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only
+"""Unit tests for xen_dt device-tree generation."""
+
+from __future__ import annotations
+
+from unittest import mock
+
+from .. import xen_dt
+
+
+# ---- _render_xen_dts ----
+
+
+def test_render_injects_bootargs(make_machine):
+    machine = make_machine(xen_bootargs="com1=poll sched=null")
+    out = xen_dt._render_xen_dts(machine)
+
+    assert 'xen,xen-bootargs = "com1=poll sched=null";' in out
+
+
+def test_render_injects_xen_mmu_type(make_machine):
+    machine = make_machine(mmu="sv39")
+    out = xen_dt._render_xen_dts(machine)
+
+    assert 'mmu-type = "riscv,sv39";' in out
+
+
+# ---- build_xen_device_tree ----
+
+
+def test_build_xen_device_tree_compiles(tmp_path, make_machine):
+    machine = make_machine(name="unit-test")
+    dts = tmp_path / "unit-test.dts"
+    dtb = tmp_path / "unit-test.dtb"
+    with (
+        mock.patch.object(xen_dt, "temp_dir", return_value=tmp_path),
+        mock.patch.object(xen_dt, "write_dts", return_value=dts) as write_dts,
+        mock.patch.object(xen_dt, "compile_to_dtb", return_value=dtb) as compile_to_dtb,
+    ):
+        result = xen_dt.build_xen_device_tree(machine)
+
+    write_dts.assert_called_once()
+    assert write_dts.call_args.args[1] == machine.name
+    compile_to_dtb.assert_called_once_with(dts, tmp_path)
+    assert result.dts == dts
+    assert result.dtb == dtb


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:43:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:43:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400483.1636168 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdo-0006RS-Sd; Thu, 27 Aug 2026 09:43:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400483.1636168; Thu, 27 Aug 2026 09:43:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdo-0006RI-OR; Thu, 27 Aug 2026 09:43:24 +0000
Received: by outflank-mailman (input) for mailman id 1400483;
 Thu, 27 Aug 2026 09:43:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@swg.vates.tech>)
 id 1wzWdn-0006Oz-Hz
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:43:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWdm-00AoWH-Uk
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:43:22 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@swg.vates.tech>)
 id 6a9006ad-e002-0a2a0a5209dd-0a2a4508ba2a-48
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:22 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@swg.vates.tech>)
 id 6a9006ba-f659-0a2a45080019-b9ff1c22aa53-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:22 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0429a155d000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:43:09 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id D77DC81230;
 Thu, 27 Aug 2026 11:43:08 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=euv1GKoVBRcVfOMKB9vvDBqdsaalOO1hGV5PMr23tAI=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=S1WARVRDzC3L9J/lVdNZ9KNGpcxecckW0Mi0iXhWSBGlPtmgIkvMRv59WML/ehuBa11xHCNl7
 GRjVD8PNvreQYoZqUcxD8LIGiUqIp/8UdhloSOXsmSGAXyyCWSN/ebNq0NmXhT7EH2SU6F8d1BL
 GHgheKikl4be4OWStsO3p78ZeKLviBsW1HvafHRMZ6QsLNP6sxltYoSf6AfFDVV2Bn9DhXlIRvY
 wdan5sdvQEIhGOmcQBLWWu/guIhS7lL/hMVB+94NX2dA4MK1Q5V1l1gy6kyhOoISw+IGfegctRs
 zfdFykhN1T2zDs7TVKguKiqmeCcu5ZRWh3qIYHD8uFdA==
X-Zone-Loop: 979fe070d2e3795f14efb2f7b7383ec99d3be8436984
x-campaign-type: default
x-transaction-id: da2da8be-e678-48f8-be08-ab76297a3d86
x-swg-uid: 01-344139b8-3069-4c6a-a68e-f1ac67380296
X-Mailer: Sweego
Message-ID:
 <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech>
x-swg-bid: 1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 6/6] CI: run the riscv64 smoke test via QTB framework console-test
Date: Thu, 27 Aug 2026 11:42:52 +0200
In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823788970
X-purgate-ID: tlsNG-c1860d/1787823802-CD34D87B-C4E01DE3/0/0
X-purgate-type: clean
X-purgate-size: 4129

qemu-smoke-riscv64-gcc drove QEMU through
automation/scripts/qemu-smoke-riscv64.sh, an expect wrapper whose machine
description (cpus, memory, device tree, console wiring) lived in the script
itself. The QTB framework now owns all of that: machines come from the
shared catalog, expectations from the test type's own YAML.

Turn .qemu-riscv64 into a template running qemu_smoke_riscv64.py <type> run
<test> in the qtb-riscv64 container, machine and test picked per job
through QTB_TEST_TYPE/QTB_TEST. The container comes from the test-artifacts
registry, hence the new ARTIFACTS_REGISTRY next to the existing
ARTIFACTS_REPO/ARTIFACTS_BRANCH. QTB_BINARIES_DIR points at the artifacts
of the job (Xen only currently, but aims to have initrd and linux images
when dom0less will be supported). QTB_LOG_DIR collects the per-console
logs, kept on failure and on success.

Point qemu-smoke-riscv64-gcc at that template, running the console-test
type on dom0less-1smp-0domu-1vcpu-aplic-imsic-null: a Xen-only machine, so
the smoke check is Xen's own "All set up" on console 0, the same string the
expect script waited for.

Drop automation/scripts/qemu-smoke-riscv64.sh as it has no caller left in
the CI after this patch and drop smoke.serial from the .qemu-riscv64
artifacts since no riscv64 job uses it anymore, the logs are now kept under
QTB_LOG_DIR.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 .gitlab-ci.yml                           |  3 +++
 automation/gitlab-ci/test.yaml           | 20 ++++++++++++++------
 automation/scripts/qemu-smoke-riscv64.sh | 19 -------------------
 3 files changed, 17 insertions(+), 25 deletions(-)
 delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f42a9abeaa..15f93b8634 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -11,6 +11,9 @@ variables:
   ARTIFACTS_BRANCH:
     description: "Branch in test-artifacts to use"
     value: master
+  ARTIFACTS_REGISTRY:
+    description: "Registry holding the test-artifacts containers"
+    value: registry.gitlab.com/xen-project/hardware/test-artifacts
   LINUX_JOB_X86_64:
     description: "Job name in test-artifacts to use for Linux x86_64"
     value: linux-6.6.56-x86_64
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 61adc1baff..e9dd147380 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -72,14 +72,21 @@
     TEST_TIMEOUT_OVERRIDE: 120
 
 .qemu-riscv64:
+  image: ${ARTIFACTS_REGISTRY}/${CONTAINER}
   extends: .test-jobs-common
   variables:
-    CONTAINER: debian:13-riscv64
-    LOGFILE: qemu-smoke-riscv64.log
+    CONTAINER: debian:13-qtb-riscv64
+    QTB_LOG_DIR: qtb-logs
+    QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries
+  script:
+    - ./automation/scripts/qemu_smoke_riscv64.py
+      ${QTB_TEST_TYPE}
+      run
+      ${QTB_TEST}
+      --log-dir ${QTB_LOG_DIR}
   artifacts:
     paths:
-      - smoke.serial
-      - '*.log'
+      - ${QTB_LOG_DIR}
     when: always
   tags:
     - x86_64
@@ -779,8 +786,9 @@ qemu-xtf-argo-x86_64-gcc-debug:
 
 qemu-smoke-riscv64-gcc:
   extends: .qemu-riscv64
-  script:
-    - ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE}
+  variables:
+    QTB_TEST_TYPE: console-test
+    QTB_TEST: dom0less-1smp-0domu-1vcpu-aplic-imsic-null
   needs:
     - debian-13-riscv64-gcc-debug
 
diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh
deleted file mode 100755
index c0b1082a08..0000000000
--- a/automation/scripts/qemu-smoke-riscv64.sh
+++ /dev/null
@@ -1,19 +0,0 @@
-#!/bin/bash
-
-set -ex -o pipefail
-
-# Run the test
-rm -f smoke.serial
-
-export TEST_CMD="qemu-system-riscv64 \
-    -M virt,aia=aplic-imsic \
-    -cpu rv64,svpbmt=on \
-    -smp 1 \
-    -nographic \
-    -m 2g \
-    -kernel binaries/xen"
-
-export TEST_LOG="smoke.serial"
-export PASSED="All set up"
-
-./automation/scripts/console.exp |& sed 's/\r\+$//'


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:43:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:43:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400484.1636173 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdp-0006Uq-8c; Thu, 27 Aug 2026 09:43:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400484.1636173; Thu, 27 Aug 2026 09:43:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWdp-0006UT-1X; Thu, 27 Aug 2026 09:43:25 +0000
Received: by outflank-mailman (input) for mailman id 1400484;
 Thu, 27 Aug 2026 09:43:23 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@swg.vates.tech>)
 id 1wzWdn-0006OC-Gw
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:43:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWdm-00AoWH-Ep
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:43:22 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@swg.vates.tech>)
 id 6a9006ad-e002-0a2a0a5209dd-0a2a4508ba2a-42
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:22 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@swg.vates.tech>)
 id 6a9006b8-f659-0a2a45080019-b9ff1c12af39-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:43:20 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0429a1484000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 09:43:09 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 9413D83B32;
 Thu, 27 Aug 2026 11:43:08 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=7bSuJNzprWfjbzLQMqWGQPycYoufJkdjbgVndy19/bs=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=MsNcnMmp4UIMF8WiJYhRETCynXGqhLHnSXz5lL4IWWjZvhFoNocv+q3uIPWe0psQW534iwfyy
 PgVe1GOLeaENEzjxVE6IBtVKzzG05PtZ8lTcyabogWbf8fsLrzp0IM4HKt6RUcrC6HO7B+yHYOr
 YLHFKJFK+JqRlCj9ogLx+DQJcLkIPSeIJSJsfwPi2GYJHl36ok9KgfLHX2ojrlr29k1bxPGJIFW
 +FKOAbf7DqPTrO8M6gwj1+n9F5l0MLEpiB1ubwzUKRY6Smrd2gr2oroWS0TFJizWemr+PeEgj4D
 vcsUmIY8/BQ8WXWx926ZFCWjN1B32mzltuwCXASOIoVw==
X-Zone-Loop: 6ba272c28740d1c7ee60548b8ae2d6428574eae73383
x-campaign-type: default
x-transaction-id: 61ee72db-108d-4708-9d11-c2b3ecd9acdc
x-swg-uid: 01-d2edfc05-4cf1-4eef-a57c-8b8064b8cc43
X-Mailer: Sweego
Message-ID:
 <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3@vates.tech>
x-swg-bid: 1787823789.8631fc262581453bbf619ec5b2062170.1a0429a1484000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Doug Goldstein <cardoe@cardoe.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 5/6] automation/qtb: add QTB framework README
Date: Thu, 27 Aug 2026 11:42:51 +0200
In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787823788688
X-purgate-ID: tlsNG-c1860d/1787823801-CCB7187B-6472FC02/0/0
X-purgate-type: clean
X-purgate-size: 7495

Document the qtb riscv64 test framework in a README.

It covers:
  - the core concepts (machine, test type, test) and how they map to files
  - the source files layout
  - the CLI: `qemu_smoke_riscv64.py <type> <command>`, with "console-test"
    as the type
  - the config files: the machine catalog and a type's own `<type>.yaml`
  - the Jinja2 device-tree templates under dts/
  - how to add a test (config-only) and how to add a new test type.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 automation/scripts/qtb/riscv/README.md | 182 +++++++++++++++++++++++++
 1 file changed, 182 insertions(+)
 create mode 100644 automation/scripts/qtb/riscv/README.md

diff --git a/automation/scripts/qtb/riscv/README.md b/automation/scripts/qtb/riscv/README.md
new file mode 100644
index 0000000000..c173714d75
--- /dev/null
+++ b/automation/scripts/qtb/riscv/README.md
@@ -0,0 +1,182 @@
+qtb riscv64 test framework
+==========================
+
+A small framework that boots Xen under QEMU on riscv64 and drives it to a
+pass/fail verdict automatically from its console output.
+
+It is built on QEMU's qtb (QEMU Test Bench) Python package, which gives
+programmatic control of a QEMU process over QMP and qtest, plus access to the
+consoles.
+
+What it does
+------------
+
+1. Reads a machine description (what to boot: cpus, Xen command line) and a
+   test description (what to assert).
+2. Generates the host device tree.
+3. Launches QEMU with Xen.
+4. Reads the console and checks what Xen printed.
+
+Core concepts
+-------------
+
+- Machine: test-agnostic description of what to boot. Reusable across test
+  types. `config.yaml` -> `MachineConfig`.
+- Test type: a `RiscvQtbTest` subclass implementing the logic of a kind of test
+  (e.g. `console-test`). Identified by `type_id`. See `console_test/`.
+- Test: one named, runnable instance of a type: a machine plus the type's
+  parameters. Lives in the type's `<type>.yaml`.
+
+A test type owns a config file describing its tests, each test names a machine
+from the shared catalog (`config.yaml`) and layers its own parameters on top.
+
+Layout
+------
+
+```
+qemu_smoke_riscv64.py        CLI entry point (<type> run | list)
+
+qtb/riscv/                   This framework
+  __init__.py                Public API
+  qtb_test.py                RiscvQtbTest ABC every test type derives from
+  config.py                  Machine catalog parser -> MachineConfig
+  xen_dt.py                  Generates the host device tree from its Jinja2 template
+  dt.py                      Compile .dts -> .dtb with dtc
+  paths.py                   Path resolution (pkg-relative)
+  machine.py                 RiscvTestMachine: assembles the QEMU command line
+
+  config.yaml                The machine catalog (shared across test types)
+  dts/                       Jinja2 device-tree templates (host, common)
+
+  console_test/              The console-test type
+    __init__.py
+    console_test.py          ConsoleTest implementation
+    console-test.yaml        Its tests
+
+  unit/                      pytest unit tests of the framework logic itself
+```
+
+How a type is selected
+----------------------
+
+The test type is the first positional argument (`qemu_smoke_riscv64.py console-test run
+...`). The CLI builds one subcommand per entry of `TEST_TYPES` (`__init__.py`),
+named after the type's `type_id`.
+
+Each type declares the `config_file` it reads its tests from.
+
+Prerequisites
+-------------
+
+- `qemu.qtb`, QEMU's Python package (`python/` in the QEMU tree)
+- `jinja2`, `pyyaml`, `pexpect`
+- `dtc` (device-tree-compiler)
+- `qemu-system-riscv64`
+- the `xen` binary a machine boots
+
+CLI usage
+---------
+
+Run from `automation/scripts/`, or give the full path from the Xen tree root
+(`./automation/scripts/qemu_smoke_riscv64.py ...`), which is what CI does.
+
+```
+# List every test the type defines in its config:
+./qemu_smoke_riscv64.py console-test list
+
+# Run one test (drives it to PASS/FAIL, exit 0/1):
+./qemu_smoke_riscv64.py console-test run dom0less-1smp-0domu-1vcpu-aplic-imsic-null \
+    --log-dir qtb-logs
+```
+
+`--log-dir` (run only) collects the QEMU process log, the qtest log, and each
+console as `con<N>.log`: `con0.log` is Xen's own console, the only one wired
+up today. Omit it to write no logs. `-v/--verbose` raises the
+log level to debug.
+
+Config files
+------------
+
+`config.yaml` is the machine catalog. `binaries:` are build artifacts resolved
+under `binaries/` (overridable with `$QTB_BINARIES_DIR`); absolute paths pass
+through.
+
+Machine entries omit any optional field left at its default.
+Here are the parameters:
+
+- `pcpu` (required): host physical cpus.
+- `mmu_type` (default `sv48`): Xen host MMU type.
+- `xen_bootargs` (default `""`): Xen command line.
+
+`<type>.yaml` describes the tests of that type.
+
+`console-test`
+--------------
+
+A test names a machine and maps a console index to the string(s) expected on
+that console: index 0 is Xen's own console (`con0`, logged as `con0.log`).
+
+```
+machine_catalog: config.yaml    # the catalog to resolve machine names against
+tests:
+  dom0less-1smp-0domu-1vcpu-aplic-imsic-null:
+    machine: dom0less-1smp-0domu-1vcpu-aplic-imsic-null   # a name in config.yaml
+    expect:
+      0: [All set up]           # Xen itself must print "All set up"
+```
+
+Logic, per console:
+
+1. read the console
+2. wait for each expected string in turn, in the order listed
+3. bound each wait by `timeout` seconds, retrying a timed-out wait up to
+   `attempts` times
+
+The map itself must not be empty, otherwise the test would pass without
+asserting anything.
+
+Device trees (dts/)
+-------------------
+
+Jinja2 template, generated per machine and compiled with dtc:
+
+- `qemu-host.dts.j2` - the Xen host tree: the hart count, the host MMU type and
+  the Xen command line.
+
+Adding a test
+-------------
+
+To add a test to an existing type (e.g. `console-test`):
+
+1. Pick a machine from `config.yaml`, or add a new one under `machines:` (set
+   `pcpu`, and any optional field that differs from its default — see the
+   field list above).
+2. Add a test entry under `tests:` in the type's `<type>.yaml`, naming that
+   machine and supplying the type's own parameters (for `console-test`, one
+   `expect` list per console).
+3. Run it: `./qemu_smoke_riscv64.py console-test run <your-test-name>`.
+
+No code change is needed, a test is pure config.
+
+Adding a new test type
+----------------------
+
+1. Create `mytype/` with `mytype.py` defining a `RiscvQtbTest` subclass: set
+   `type_id`, `description`, and `config_file`, and implement `from_config`,
+   `list_tests`, and `run(vm)`.
+2. Add `mytype/__init__.py` that does `from .mytype import MyType`.
+3. Add `MyType` to `TEST_TYPES` in `__init__.py` so the CLI exposes it.
+
+Unit tests
+----------
+
+The `unit/` directory holds pytest tests of the framework's own logic (config
+parsing, device-tree rendering, QEMU arg assembly). They do not boot QEMU and
+are independent of the CI smoke tests, but they import the framework, so they
+need the prerequisites above plus `pytest`.
+
+Run from the Xen tree root:
+
+```
+python3 -m pytest automation/scripts/qtb/riscv/unit/
+```


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 09:54:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 09:54:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400525.1636186 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWnz-0001a6-CG; Thu, 27 Aug 2026 09:53:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400525.1636186; Thu, 27 Aug 2026 09:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzWnz-0001Zz-84; Thu, 27 Aug 2026 09:53:55 +0000
Received: by outflank-mailman (input) for mailman id 1400525;
 Thu, 27 Aug 2026 09:53:53 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wzWnx-0001Zt-IB
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 09:53:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzWnw-00Aqn7-V7
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:53:52 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a90092d-8faa-0a2a0a5109dd-0a2a4503b7cc-10
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:53:52 +0200
Received: from [52.101.46.51]
 (helo=CO1PR03CU002.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a90092e-fae8-0a2a45030019-34652e33c6a9-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 11:53:52 +0200
Received: from IA1P220CA0020.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:464::13)
 by PH7PR12MB7258.namprd12.prod.outlook.com (2603:10b6:510:206::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 09:53:40 +0000
Received: from BL6PEPF00020E63.namprd04.prod.outlook.com
 (2603:10b6:208:464:cafe::9) by IA1P220CA0020.outlook.office365.com
 (2603:10b6:208:464::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.9 via Frontend Transport; Thu, 27
 Aug 2026 09:53:39 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BL6PEPF00020E63.mail.protection.outlook.com (10.167.249.24) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Thu, 27 Aug 2026 09:53:39 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 04:53:39 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Thu, 27 Aug 2026 04:53:36 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZZeE7Q8IEF5Ctz+9xNDm0jcXmzKDLj2Hw84P6bBzYH9lYB9TGxFzAFv7PDrkFvj945RJrS5YDaVBBhI0ZkTrh+UHgW4sTB5o1WgTMSTYpQP8xVwZezx5sBJD4QC2dEc+LmEgn/2GljyjAhzgKWCBM3X+gzKmlQX1g1H3vviRNMbaWZVUXNIAnGDWNewzYD9I8R8073P63c4JZp+XRK3aHsteZalm6DNRbOCrucFj42IdmIq0fnhtpUFyFXCr532RrBvNjOqmsJurQzQ4y/lFhsKAv2yx1q4QjTgPyQNVNdifIp8ql7nHAbvAL1rEoNR2+NWrt1vW30mzVfcay7xnZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=r24cShevZoiwAPq94XAE5C0fCywcD+cnxHSXfZpm9UM=;
 b=yrfX9KdWelwLFTn2V2VWKeYdkgIRX0JgB6V2RNppANE82De93dOTuWlJrjN/hfFtZ+BynRsnvpMAxbkLA/dNpZx1BsNdaj7FLiHIe/mbAsykvfCFknO9ZR5Ml43+aM7ME4kjJrik4B/y3oS6n2MVaKsPp51Hnt+i/41q2BJfAl+yyDHjAZ2MCsgoDi2NI45iCC5C7+xRH3lKc7LIP0M3esChJ+UDFeI8C3VxIVUBjf0sxP5EM0v6DoY6LZCwqqplGqYNsY8ixUtQYWibnIc6Z50KwzW3l2JugbMeNqka8b9jfvWkjhjlB41Bx0AhGGw/5wPtDbv/Tyxc8QQfTNyszg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=r24cShevZoiwAPq94XAE5C0fCywcD+cnxHSXfZpm9UM=;
 b=5UCRa+sVZkItbwrkwuJSlO9wANZrRQoKWU/+kl2hpcjDU/eobH+JYugVohEG1xTmqgkbBaduzlWS4Q4euwzI1co9DGn2XkBAxbUY/3+wgAR+Tip+FbX9WXBni2MkyuGqCFFbs0G/ttRn4xXja5KSL2XgLLNHCUuPDjgZMBhEcXo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <1dd99dc8-2dd4-4603-912b-74ec94671ce0@amd.com>
Date: Thu, 27 Aug 2026 11:53:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 4/6] xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from
 the ABI
To: Julian Vetter <julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, Oleksii
 Kurochko <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
 <1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3@vates.tech>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1787229624.8631fc262581453bbf619ec5b2062170.1a01f2fd9fb000c4f3@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF00020E63:EE_|PH7PR12MB7258:EE_
X-MS-Office365-Filtering-Correlation-Id: 303a1e44-c62c-4029-c154-08df0421125c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|1800799024|82310400026|23010399003|36860700016|10067099003|6133799003|22082099003|18002099003|11063799006|5023799004|4143699003|56012099006|13003099007;
X-Microsoft-Antispam-Message-Info:
	HNhY3nXIRCMoqFS+MfSt+P1IdKEcpo8CIBMFMrOxgJxhboe6g7Yc8BrvoeEAq2tUpQwwfjgFtaTEO2LkqvHZhNzXuz14AmuiYzSHjhdG0yzfkOCCdVNOXylO9z9D1uhA1HbVMgsrX/4i3wI7szgZm1Tr982Q12aLTYCrzqWJHDBmY5o0Km5ZwkjMFBSIqGvggM3GR/IrLeLdqRx6NgMyg4a/l8Fx3k9UAtK7JwmSme4hYjKG1SJplH2zIij7xAS7XP9KtEz5KWU/aWZoPGmgU8hRYlZmhFCt9n5PHtrNMaVncmTPRRyoRqsV5qwriDGKxJaDacqEfbqHDiUqXs570vMa4sKCplvu509Psj08RSd5BYqemg5irZCy8w9kOLV23+kVAvm5QRFIawAtjkrqhQ3++p9/g7Zw3vjFDiPdJIt+a/bUkDH9RGKcBmGMxRZyeWQ6oZ5o4LUWi5BVG98eHbJYpHRr1+RVW/X3yniO3yZwzLhE4FwB8/sg0wRc/ucWCYw5Cmhau3SpW2TDd8N2Jc/ydwHUI7QqsDI60aETjXM+hYYJfRzkW/2Vi+OfyhB2B8sr/6gvS0tiedTFb4+mAZ46BFXkULhpfcNxu0v7O4h5/qDNggjTEujU0TxMHG6fObuGL+K3qlq+l2gBSehVxA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(82310400026)(23010399003)(36860700016)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(5023799004)(4143699003)(56012099006)(13003099007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	D2Wopvy4n2eec1F2t5ZOQEezh6G7D8xvGNh8obXaPnvtEwu3HLKw/WvgOyQDXplxJDx2pSP2RO2JkS4JKcO+Q3HZ6E36uQ4/tpweH0r/vMfJgszRtVof6wOXu/hy5EkLnlosZrUVys/2Ssrj31+JkSV+rZSMVmvZfhJZqEYaQ1wOUsMnikvEwIeNEhcSdaED8vhxQBp8QHiO6ZqG3Ub7gJNelrvTBlbL5bE9ghOI+0pssTo86Fy9ze9Neza80SqxyfFXfTNRchRqT7nf0L2xNBVJhZZE0B9mDKtWYJ17VkTg2WBF7vAXP16pxdUj8eVrhyTCs1a0vvyiy1iV2+E9wgUGEXbzVy+ltivuMkjKxlrJ6h6cDqF2igBj22ln7ZMhYn9od7s8Z4GqbqktisGTjOBygEDh+kBG9tDRd9DYItEDcJjqfQuEWX4acMAdLELX
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 09:53:39.7954
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 303a1e44-c62c-4029-c154-08df0421125c
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF00020E63.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7258
X-purgate-ID: tlsNG-33051d/1787824432-75A814E9-E0720815/0/0
X-purgate-type: clean
X-purgate-size: 8436



On 20-Aug-26 14:40, Julian Vetter wrote:
> Now that the toolstack always resolves a concrete GIC_V2 or GIC_V3
> before calling createdomain, nothing on the Xen side needs to resolve
> GIC_NATIVE either:
> 
>  * A new gic_domctl_version() helper returns the XEN_DOMCTL_CONFIG_GIC_*
>    value matching the host's gic_hw_version().
>  * arch_sanitise_domain_config() uses it to validate that the requested
>    version is compatible with the hardware, rather than resolving
>    GIC_NATIVE and writing the result back into config->arch.gic_version.
>    There's currently no support to run a guest on a GIC version other
>    than the host's, so this is just an equality check.
>  * create_dom0() and arch_parse_dom0less_node(), which both always want
>    a vGIC that exactly matches the hardware, use the same helper instead
>    of GIC_NATIVE.
> 
> With nothing left resolving or relying on it, drop
> XEN_DOMCTL_CONFIG_GIC_NATIVE from the public ABI. Every caller must now
> request a concrete GIC_V2 or GIC_V3.
> 
> This is an incompatible change for any toolstack still passing 0
> (formerly GIC_NATIVE) expecting Xen to auto-select a version. Add a
> CHANGELOG.md entry, noting that available GIC versions can be queried
> via XEN_SYSCTL_physinfo.
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v4:
> - Don't bump XEN_DOMCTL_INTERFACE_VERSION for this: it's an API change,
>   not an ABI one. Leave a comment marking XEN_DOMCTL_CONFIG_GIC_NATIVE
>   as removed instead, and mention in the CHANGELOG.md entry that
>   available GIC versions can be queried via XEN_SYSCTL_physinfo
> - Simplify comment above the GIC version check
> - Report requested GIC version in the "Unsupported GIC version" print
> ---
>  CHANGELOG.md                   |  4 ++++
>  xen/arch/arm/dom0less-build.c  |  3 ++-
>  xen/arch/arm/domain.c          | 24 ++++++++----------------
>  xen/arch/arm/domain_build.c    |  3 ++-
>  xen/arch/arm/gic.c             | 16 ++++++++++++++++
>  xen/arch/arm/include/asm/gic.h |  6 ++++++
>  xen/include/public/arch-arm.h  |  2 +-
>  7 files changed, 39 insertions(+), 19 deletions(-)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 356be88351..5dfa242030 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -13,6 +13,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>  ### Added
>  
>  ### Removed
> + - On Arm:
> +   - XEN_DOMCTL_CONFIG_GIC_NATIVE has been removed. Toolstacks must now
> +     explicitly request GIC_V2 or GIC_V3 when creating a domain.
> +     Available GIC versions can be queried via XEN_SYSCTL_physinfo.
>   - On x86:
>     - The kexec "v1" interface, which was declared obsolete in Xen 4.4 (2013).
>       The only known user was the classic-xen fork of Linux.  This does not
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 3f48f74226..5b01843db4 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -23,6 +23,7 @@
>  #include <asm/arm64/sve.h>
>  #include <asm/domain_build.h>
>  #include <asm/firmware/sci.h>
> +#include <asm/gic.h>
>  #include <asm/grant_table.h>
>  #include <asm/setup.h>
>  
> @@ -368,7 +369,7 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node,
>      unsigned int flags = bd->create_flags;
>      uint32_t val;
>  
> -    d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> +    d_cfg->arch.gic_version = gic_domctl_version();
>      d_cfg->flags |= XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap;
>  
>      if ( domu_dt_sci_parse(node, d_cfg) )
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index baa3a5d708..94f8f077e9 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -609,23 +609,15 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>          return -EINVAL;
>      }
>  
> -    /* Fill in the native GIC version, passed back to the toolstack. */
> -    if ( config->arch.gic_version == XEN_DOMCTL_CONFIG_GIC_NATIVE )
> +    /*
> +     * There's currently no support to run a guest on a GIC version other
> +     * than the host's.
> +     */
> +    if ( config->arch.gic_version != gic_domctl_version() )
>      {
> -        switch ( gic_hw_version() )
> -        {
> -        case GIC_V2:
> -            config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
> -            break;
> -
> -        case GIC_V3:
> -            config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
> -            break;
> -
> -        default:
> -            ASSERT_UNREACHABLE();
> -            return -EINVAL;
> -        }
> +        dprintk(XENLOG_INFO, "Unsupported GIC version %u\n",
> +                config->arch.gic_version);
> +        return -EINVAL;
>      }
I don't understand. How are you going to support a rightful request (supported
today) for a vGICv2 on a host GICv3 that supports GICv2 by legacy mode? Your
previous patches already expose this configuration via sysctl. We should allow
it and in `arch_sanitise_domain_config()` Xen should just check if the passed
domctl GIC version is indeed supported.

At this point I also realized that your previous patch only uses sysctl
information if no GIC version was selected by the guest. I think it would be
better for the toolstack to read it also when the version is explicitly selected
to allow a faster failure not requiring the trip to Xen.

>  
>      /* max_vcpus depends on the GIC version, and Xen's compiled limit. */
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 72d5316180..cd9509d7b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -26,6 +26,7 @@
>  #include <xen/warning.h>
>  #include <xen/static-shmem.h>
>  #include <asm/device.h>
> +#include <asm/gic.h>
>  #include <asm/setup.h>
>  #include <asm/tee/tee.h>
>  #include <asm/pci.h>
> @@ -1960,7 +1961,7 @@ void __init create_dom0(void)
>      int rc;
>  
>      /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> -    dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> +    dom0_cfg.arch.gic_version = gic_domctl_version();
>      dom0_cfg.arch.nr_spis = vgic_def_nr_spis();
>      dom0_cfg.arch.tee_type = tee_get_type();
>      dom0_cfg.max_vcpus = dom0_max_vcpus();
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index ee75258fc3..fc55a65159 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -56,6 +56,22 @@ enum gic_version gic_hw_version(void)
>     return gic_hw_ops->info->hw_version;
>  }
>  
> +uint8_t gic_domctl_version(void)
`gic_domctl_hw_version()` would be a better fit to clearly denote that it
returns the HW version translated to domctl field.

> +{
> +    switch ( gic_hw_version() )
> +    {
> +    case GIC_V2:
> +        return XEN_DOMCTL_CONFIG_GIC_V2;
> +
> +    case GIC_V3:
> +        return XEN_DOMCTL_CONFIG_GIC_V3;
> +
> +    default:
> +        ASSERT_UNREACHABLE();
> +        return 0;
> +    }
> +}
> +
>  unsigned int gic_number_lines(void)
>  {
>      return gic_hw_ops->info->nr_lines;
> diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h
> index ff22dea40d..de6eabfadd 100644
> --- a/xen/arch/arm/include/asm/gic.h
> +++ b/xen/arch/arm/include/asm/gic.h
> @@ -262,6 +262,12 @@ DECLARE_PER_CPU(uint64_t, lr_mask);
>  
>  extern enum gic_version gic_hw_version(void);
>  
> +/*
> + * The XEN_DOMCTL_CONFIG_GIC_* value matching the GIC version actually
> + * present on this host.
> + */
> +extern uint8_t gic_domctl_version(void);
> +
>  /* Program the IRQ type into the GIC */
>  void gic_set_irq_type(struct irq_desc *desc, unsigned int type);
>  
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 7d6f87e8b2..e95fa33eb7 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -319,7 +319,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>   * struct xen_arch_domainconfig's ABI is covered by
>   * XEN_DOMCTL_INTERFACE_VERSION.
>   */
> -#define XEN_DOMCTL_CONFIG_GIC_NATIVE    0
> +/*      XEN_DOMCTL_CONFIG_GIC_NATIVE    0 - removed in Xen 4.23 */
>  #define XEN_DOMCTL_CONFIG_GIC_V2        1
>  #define XEN_DOMCTL_CONFIG_GIC_V3        2
>  

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 11:34:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 11:34:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400588.1636205 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzYMq-0006pp-8w; Thu, 27 Aug 2026 11:34:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400588.1636205; Thu, 27 Aug 2026 11:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzYMq-0006pi-6N; Thu, 27 Aug 2026 11:34:00 +0000
Received: by outflank-mailman (input) for mailman id 1400588;
 Thu, 27 Aug 2026 11:33:58 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wzYMn-0006pc-Pc
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 11:33:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzYMl-00917C-7z
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 13:33:55 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a902086-2eae-0a2a0a5409dd-0a2a4501cc96-38
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 13:33:54 +0200
Received: from [52.101.201.8]
 (helo=PH7PR06CU001.outbound.protection.outlook.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a9020a0-5984-0a2a45010019-3465c9081f19-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 13:33:54 +0200
Received: from BY3PR04CA0006.namprd04.prod.outlook.com (2603:10b6:a03:217::11)
 by PHXPR12MB999256.namprd12.prod.outlook.com (2603:10b6:510:3ca::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.10; Thu, 27 Aug
 2026 11:33:46 +0000
Received: from SJ1PEPF00002319.namprd03.prod.outlook.com
 (2603:10b6:a03:217:cafe::20) by BY3PR04CA0006.outlook.office365.com
 (2603:10b6:a03:217::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.10 via Frontend Transport; Thu,
 27 Aug 2026 11:33:46 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 SJ1PEPF00002319.mail.protection.outlook.com (10.167.242.229) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.360.3 via Frontend Transport; Thu, 27 Aug 2026 11:33:45 +0000
Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 06:33:43 -0500
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com
 (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 06:33:43 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Thu, 27 Aug 2026 06:33:39 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NHqpIPAAWkSsI3i5F2nxLkGRjmHl9GDFNvD/y/4dW3bml8JDoETSD/bHhIbjMd5cVCG9IGfbehVEOk+7khgGd8zmd+9K1NZXLvzXjJeUwT1bSCXZOR3WftRaLgWGbVcBsMbUgV+aDdfOa6I7JYsupJWn6J9EU+RRYrI9bNOEQF+FPGgAEmjkeQlROy2WiekPzKsOXpDtRmo0lkWujd+w9fCAxBXPy9GBVIy58uFbjG81H6rDtRSnpEHw6pyupJzdxOlc4GT+lQjpbbrlg0afK97IZxLlWm40NZC1D0XBPJwCDHKVMwDcvZ2txd/Yg61hVdeKkQAZWrMbkndBsbn5qA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=i+IG0YjbwUBcfGAukbLobS15jYceW1vbr7Zm+mLlg8A=;
 b=q+IxbBKy6NV56CYfg8F4CHAkq2IPUCCgehHidZsKkP9nrLPPDddTWU9rFqGPJO9Pi5FZXqbtsUmS2XYhP09fqvNZCLLLYETR1ZZ1BNWXawViwmKT5J9G0GE7f/jatUeIs8ITY5FQuJP8rwGr6BM830jTe7xw6//QjkmMnSKE493WYgKa2+MNGxMU86bG2/VVdyyAiZPe6Zo1dJaAcL6X0EMU2UbPPGbdNeCCKnImKjLfgZKqh4tBswwjROds4SgZ3y7mUmYCf3Ag8fkwgxgMdVLgRtwdg4H2KHWpxy24R5DTnJolpken25x5xnhRACsJ3H0yTD8eNYtHsFv+MlWzKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=i+IG0YjbwUBcfGAukbLobS15jYceW1vbr7Zm+mLlg8A=;
 b=v1p1SPMU4fz8X7N368+WzkT8GeiI21l3n8CO+rPkCjcDGlU4gAVvs840ooFJ7Vs8v4rf1p13LIHu3kqnUN8kYvqwm9TjsbYvlwoTCW6DR1dO3XYXmyCOziUUa/2y7a6xlSoaobQ1y2XcgahLKT6uX2zZFXz3zwqI2bWZEdf2AQY=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <0a316355-3fb8-451e-883f-5cf906e1b1c2@amd.com>
Date: Thu, 27 Aug 2026 13:33:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 5/6] xen/arm: report clock_frequency via sysctl
 physinfo, not createdomain
To: Julian Vetter <julian.vetter@vates.tech>, <xen-devel@lists.xenproject.org>
CC: Anthony PERARD <anthony.perard@vates.tech>, Andrew Cooper
	<andrew.cooper3@citrix.com>, Jan Beulich <jbeulich@suse.com>, Julien Grall
	<julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>, Juergen Gross <jgross@suse.com>,
	Andrii Sultanov <andriy.sultanov@vates.tech>, Guillaume Thouvenin
	<guillaume.thouvenin@vates.tech>, =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?=
	<marmarek@invisiblethingslab.com>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksii Moisieiev <oleksii_moisieiev@epam.com>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, "Oleksii
 Kurochko" <oleksii.kurochko@gmail.com>, Teddy Astie <teddy.astie@vates.tech>
References: <20260820123805.2033085-1-julian.vetter@vates.tech>
 <20260820124016.2033421-1-julian.vetter@vates.tech>
 <1787229625.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3@vates.tech>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <1787229625.8631fc262581453bbf619ec5b2062170.1a01f2fdb8f000c4f3@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ1PEPF00002319:EE_|PHXPR12MB999256:EE_
X-MS-Office365-Filtering-Correlation-Id: 76fd22e3-5faf-4870-e0ba-08df042f0e3e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700016|1800799024|82310400026|376014|7416014|23010399003|22082099003|18002099003|56012099006|3023799007|6133799003|11063799006|4143699003|5023799004|10067099003;
X-Microsoft-Antispam-Message-Info:
	pQwUyyNQ+wphidtCzG+ftIuleQgQT/SjfK1jlhhW97J+13xSyV/OSakGr5+3JiCnwO+ewvhfyLTwkgjubRTe2e9C8SZk1JJuJyh2BKBoMXTknQTcrm+OG4ndhi864j/nySQqBZjNkGNqFJWbeZvp1zk/DABotaFWEtdTPXOVfyvbiQP/zGV18g85R/xzxopABml9N5Tgso9OkatGdbPvoUICLORF+VKSekBHKyhgX2SQOP6ZCpx2NJhUvgpcWRR8P9Xf9V48sepullqobwf+NoqSfB0xzJ1r3s1/9C7LcgmyeYsesqKKp8bSkIXWZxMkiJMumBYefVMZNbrJbuv7bpXNSuo/WFkg9tyn1v2ApxoCF1rwKEfqQ9kzDXUnQAGsWyuCTVGDFq3lz3XiPazpVLBQvJSOuKXi4Zpf/jWdFStefXcgBFHQsEfJd/WewSNelqOcCbqtz4p20xgwt3kQT1vHfqchwM0M0x6kGJLFsmgKc3gVOM3ZZQrV9gVTzUxIVmqn1j5nfWe81kqhTAX8bH/SkXSXQZjWRTb6t1IY3ckcsexpWms41wG/t7nmb4KGK5yXSu0OaVEu/EHUU1YetQCRhuo32vAFDXMAhkYhekA8VHEmGa0mZwg8z0om3NAXcotNqU9/gMnsIpBfeVK6zcsTx5AvxxlTVVBOmaAlXOp8ojKNcmCElN9PGccs4Ul1V45IQpwMvfshIqH1GgekXA==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(82310400026)(376014)(7416014)(23010399003)(22082099003)(18002099003)(56012099006)(3023799007)(6133799003)(11063799006)(4143699003)(5023799004)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	UcsHiPs/HndlMnkwSQZel84+nt6C761fMH8SjskocFvnzvFw6tT68mFdjWIfpqw3xMMCFrWbrFKH5kDHKTwmTgzNI8SqGetEqMAP+8xmHbqUOIIPJVfVr/s4fz7e7rk0w8K75hIwm+76PKN1TAnvEHjUp0hxyNPre4VwOWdMmP5DLIHf5tKy8nKYMLnhgzp+TTU1zfhGAnleUmSXyEKIszK0oI2X9TsbOattHFdyltolH++l7z+tbiQiPb0UZrkbu2vCRlS8hNqNBn4O3Z+HAdbvOaNy9koKDPK/vBxy3ptdkG59++j97NwdSxewyYrqqPYtjgElqNBwIagegBS9svogWdTfjZaVIs/i4nwVQQfcaEGe3B/rYfH/brrq1q4dB1spLXdnf6/5AylTIxZa8QsP+Ax6MKqqpGdVTV33p0ZUCcgrr7e8BGmjg6SvL7Zn
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 11:33:45.8175
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 76fd22e3-5faf-4870-e0ba-08df042f0e3e
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ1PEPF00002319.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR12MB999256
X-purgate-ID: tlsNG-d62444/1787830434-C495A757-AA199CAC/0/0
X-purgate-type: clean
X-purgate-size: 13638



On 20-Aug-26 14:40, Julian Vetter wrote:
> The xen_arch_domainconfig.clock_frequency value is populated in
> domain_vtimer_init() during XEN_DOMCTL_createdomain from the global
> timer_dt_clock_frequency, which comes from the host's DT timer node and
> has nothing to do with the domain being created. Like now removed
> GIC_NATIVE resolution, this is a host-wide system property being
> smuggled out through a domain-creation IN struct.
> 
> Expose it instead as a new arch_clock_frequency_hz field in
> XEN_SYSCTL_physinfo, populated via arch_do_physinfo(), and mirroring how
> the GIC capability bits were already moved there.
> 
> Rather than making the field dependant on DT boot, make Xen always
> report the timer frequency, either via the DT "clock-frequency" node, or
> directly via CNTFRQ_EL0. preinit_xen_time() already computes cpu_khz for
> every boot path. The renamed timer_clock_frequency_hz now captures
> whichever of the two produced that value, in full Hz precision, instead
> of only recording the DT case. So, ACPI guests get a real value too,
> allowing to drop the special case.
> 
> Although the CNTFRQ_EL0 register is 64 bits wide, and some current timer
> implementations run at 1GHz, a 32bit value is sufficient to store the
> timer value, because it only mirrors the DT 'clock-frequency' property,
> which the bindings define as a single 32-bit cell. The
> XEN_DOMCTL_INTERFACE_VERSION doesn't need to be bumped, because only a
> previously zero'ed / ignored field is now used.
I think you meant sysctl here where you're re-using the padding. For domctl, you
remove the member in the middle so the following fields have changed offsets and
the struct changes size from 16 to 12B. I think the version should be bumped.

> 
> The xen_arch_domainconfig parameter passed to domain_vtimer_init() is no
> longer needed, so drop that parameter entirely. libxl now fetches the
> frequency via libxl_get_physinfo() in libxl__arch_domain_save_config()
> instead of reading it back out of the createdomain reply. The OCaml
> xen_arch_domainconfig mirror drops the field too.
> 
> Signed-off-by: Julian Vetter <julian.vetter@vates.tech>
> ---
> Changes in v4:
> - Rename timer_dt_clock_frequency to timer_clock_frequency_hz
> - Always populate the frequency, and record it on the CNTFRQ_EL0 path in
>   preinit_xen_time(), instead of only when booting via DT
> - ACPI guests now get a real frequency value instead of 0
> ---
>  tools/libs/light/libxl.c          |  1 +
>  tools/libs/light/libxl_arm.c      | 13 ++++++++++++-
>  tools/libs/light/libxl_types.idl  |  1 +
>  tools/ocaml/libs/xc/xenctrl.ml    |  1 -
>  tools/ocaml/libs/xc/xenctrl.mli   |  1 -
>  xen/arch/arm/domain.c             |  2 +-
>  xen/arch/arm/include/asm/time.h   |  6 +++---
>  xen/arch/arm/include/asm/vtimer.h |  3 +--
>  xen/arch/arm/sysctl.c             |  3 +++
>  xen/arch/arm/time.c               |  7 ++++---
>  xen/arch/arm/vtimer.c             |  4 +---
>  xen/include/public/arch-arm.h     | 16 +---------------
>  xen/include/public/sysctl.h       | 12 +++++++++++-
>  13 files changed, 39 insertions(+), 31 deletions(-)
> 
> diff --git a/tools/libs/light/libxl.c b/tools/libs/light/libxl.c
> index a1fe16274d..ec7e6d3f65 100644
> --- a/tools/libs/light/libxl.c
> +++ b/tools/libs/light/libxl.c
> @@ -410,6 +410,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
>      physinfo->cap_gnttab_v2 =
>          !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_gnttab_v2);
>      physinfo->arch_capabilities = xcphysinfo.arch_capabilities;
> +    physinfo->arch_clock_frequency_hz = xcphysinfo.arch_clock_frequency_hz;
>  
>      GC_FREE;
>      return 0;
> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
> index 926d651857..cf441f0737 100644
> --- a/tools/libs/light/libxl_arm.c
> +++ b/tools/libs/light/libxl_arm.c
> @@ -252,6 +252,9 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
>                                     libxl__domain_build_state *state,
>                                     const struct xen_domctl_createdomain *config)
>  {
> +    libxl_physinfo info;
> +    int rc;
> +
>      switch (config->arch.gic_version) {
>      case XEN_DOMCTL_CONFIG_GIC_V2:
>          d_config->b_info.arch_arm.gic_version = LIBXL_GIC_VERSION_V2;
> @@ -264,7 +267,15 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
>          return ERROR_FAIL;
>      }
>  
> -    state->clock_frequency = config->arch.clock_frequency;
> +    libxl_physinfo_init(&info);
> +    rc = libxl_get_physinfo(CTX, &info);
> +    if (rc) {
> +        LOG(ERROR, "failed to get physinfo");
> +        libxl_physinfo_dispose(&info);
> +        return ERROR_FAIL;
> +    }
> +    state->clock_frequency = info.arch_clock_frequency_hz;
`make_timer_node()` will now put clock-frequency into every libxl guest DT which
is not correct. I'm not sure how you want to signal to the toolstack that the
frequency comes from the DT property and not from the CNTFRQ.

> +    libxl_physinfo_dispose(&info);
>  
>      return 0;
>  }
> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
> index a7893460f0..e24a3253f8 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -1201,6 +1201,7 @@ libxl_physinfo = Struct("physinfo", [
>      ("cap_gnttab_v1", bool),
>      ("cap_gnttab_v2", bool),
>      ("arch_capabilities", uint32),
> +    ("arch_clock_frequency_hz", uint32), # ARM only
>      ], dir=DIR_OUT)
>  
>  libxl_connectorinfo = Struct("connectorinfo", [
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index 147afa62c2..582897af6d 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -32,7 +32,6 @@ type xen_arm_arch_domainconfig =
>    {
>      gic_version: int;
>      nr_spis: int;
> -    clock_frequency: int32;
>    }
>  
>  type x86_arch_emulation_flags =
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index 9fccb2c2c2..9414b87164 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -26,7 +26,6 @@ type vcpuinfo = {
>  type xen_arm_arch_domainconfig = {
>    gic_version: int;
>    nr_spis: int;
> -  clock_frequency: int32;
>  }
>  
>  type x86_arch_emulation_flags =
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 94f8f077e9..96dc65270b 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -710,7 +710,7 @@ int arch_domain_create(struct domain *d,
>      if ( (rc = domain_vgic_init(d, config->arch.nr_spis)) != 0 )
>          goto fail;
>  
> -    if ( (rc = domain_vtimer_init(d, &config->arch)) != 0 )
> +    if ( (rc = domain_vtimer_init(d)) != 0 )
>          goto fail;
>  
>      if ( (rc = tee_domain_init(d, config->arch.tee_type)) != 0 )
> diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h
> index c194dbb9f5..07091648a3 100644
> --- a/xen/arch/arm/include/asm/time.h
> +++ b/xen/arch/arm/include/asm/time.h
> @@ -87,10 +87,10 @@ enum timer_ppi
>  };
>  
>  /*
> - * Value of "clock-frequency" in the DT timer node if present.
> - * 0 means the property doesn't exist.
> + * The timer frequency, in Hz, that Xen ended up using: either the DT
> + * "clock-frequency" override, or a direct CNTFRQ_EL0 read.
>   */
> -extern uint32_t timer_dt_clock_frequency;
> +extern uint32_t timer_clock_frequency_hz;
>  
>  /* Get one of the timer IRQ number */
>  unsigned int timer_get_irq(enum timer_ppi ppi);
> diff --git a/xen/arch/arm/include/asm/vtimer.h b/xen/arch/arm/include/asm/vtimer.h
> index 9d4fb4c6e8..6bbfcf4e69 100644
> --- a/xen/arch/arm/include/asm/vtimer.h
> +++ b/xen/arch/arm/include/asm/vtimer.h
> @@ -20,8 +20,7 @@
>  #ifndef __ARCH_ARM_VTIMER_H__
>  #define __ARCH_ARM_VTIMER_H__
>  
> -extern int domain_vtimer_init(struct domain *d,
> -                              struct xen_arch_domainconfig *config);
> +extern int domain_vtimer_init(struct domain *d);
>  extern int vcpu_vtimer_init(struct vcpu *v);
>  extern bool vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr);
>  extern void virt_timer_save(struct vcpu *v);
> diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
> index 8411deb7e2..789ad78a14 100644
> --- a/xen/arch/arm/sysctl.c
> +++ b/xen/arch/arm/sysctl.c
> @@ -15,6 +15,7 @@
>  
>  #include <asm/arm64/sve.h>
>  #include <asm/gic.h>
> +#include <asm/time.h>
>  #include <asm/vgic.h>
>  
>  #include <public/sysctl.h>
> @@ -26,6 +27,8 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>      pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>                                         XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>  
> +    pi->arch_clock_frequency_hz = timer_clock_frequency_hz;
> +
>      /*
>       * The GIC version(s) we're happy creating guests with. Right now for
>       * simplicity it is tied to the active hardware version, but this will
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 6955b2788f..bcbd038cb2 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -35,7 +35,7 @@ uint64_t __read_mostly boot_count;
>   * register-mapped time source in the SoC. */
>  unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
>  
> -uint32_t __read_mostly timer_dt_clock_frequency;
> +uint32_t __read_mostly timer_clock_frequency_hz;
>  
>  static unsigned int timer_irq[MAX_TIMER_PPI];
>  
> @@ -120,7 +120,7 @@ static void __init preinit_dt_xen_time(void)
>      {
>          cpu_khz = DIV_ROUND(rate, 1000);
>          validate_timer_frequency();
> -        timer_dt_clock_frequency = rate;
> +        timer_clock_frequency_hz = rate;
>      }
>  }
>  
> @@ -136,7 +136,8 @@ void __init preinit_xen_time(void)
>  
>      if ( !cpu_khz )
>      {
> -        cpu_khz = DIV_ROUND(READ_SYSREG(CNTFRQ_EL0) & CNTFRQ_MASK, 1000);
> +        timer_clock_frequency_hz = READ_SYSREG(CNTFRQ_EL0) & CNTFRQ_MASK;
> +        cpu_khz = DIV_ROUND(timer_clock_frequency_hz, 1000);
>          validate_timer_frequency();
>      }
>  
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 2e85ff2b6e..18f5676158 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -52,7 +52,7 @@ static void virt_timer_expired(void *data)
>      perfc_incr(vtimer_virt_inject);
>  }
>  
> -int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
> +int domain_vtimer_init(struct domain *d)
>  {
>      d->arch.virt_timer_base.offset = get_cycles();
>      d->arch.virt_timer_base.nanoseconds =
> @@ -60,8 +60,6 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
>      d->time_offset.seconds = d->arch.virt_timer_base.nanoseconds;
>      do_div(d->time_offset.seconds, 1000000000);
>  
> -    config->clock_frequency = timer_dt_clock_frequency;
> -
>      /*
>       * Per the ACPI specification, providing a secure EL1 timer
>       * interrupt is optional and will be ignored by non-secure OS.
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index e95fa33eb7..c7118e7884 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -335,7 +335,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>  #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA    2
>  
>  struct xen_arch_domainconfig {
> -    /* IN/OUT */
> +    /* IN */
>      uint8_t gic_version;
>      /* IN - Contains SVE vector length divided by 128 */
>      uint8_t sve_vl;
> @@ -343,20 +343,6 @@ struct xen_arch_domainconfig {
>      uint16_t tee_type;
>      /* IN */
>      uint32_t nr_spis;
> -    /*
> -     * OUT
> -     * Based on the property clock-frequency in the DT timer node.
> -     * The property may be present when the bootloader/firmware doesn't
> -     * set correctly CNTFRQ which hold the timer frequency.
> -     *
> -     * As it's not possible to trap this register, we have to replicate
> -     * the value in the guest DT.
> -     *
> -     * = 0 => property not present
> -     * > 0 => Value of the property
> -     *
> -     */
> -    uint32_t clock_frequency;
>      /* IN */
>      uint8_t arm_sci_type;
>      /* IN */
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index d20ebf3644..04cb1f3bdc 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -120,7 +120,17 @@ struct xen_sysctl_physinfo {
>      uint32_t cpu_khz;
>      uint32_t capabilities;/* XEN_SYSCTL_PHYSCAP_??? */
>      uint32_t arch_capabilities;/* XEN_SYSCTL_PHYSCAP_{X86,ARM,...}_??? */
> -    uint32_t pad;
> +    /*
> +     * ARM only. The timer frequency, in Hz, that Xen is using. Either
> +     * "clock-frequency" property from DT timer node or CNTFRQ_EL0 value.
> +     *
> +     * As it's not possible to trap this register, we have to replicate the
> +     * value in the guest DT.
> +     *
> +     * = 0 => non-ARM, or the frequency could not be determined.
I'm struggle to understand the second condition. On Arm we validate the
frequency to be at least 1kHZ, so this field cannot be 0 on Arm.

> +     * > 0 => The frequency, in Hz.
> +     */
> +    uint32_t arch_clock_frequency_hz;
>      uint64_aligned_t total_pages;
>      uint64_aligned_t free_pages;
>      uint64_aligned_t scrub_pages;

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 13:49:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 13:49:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400655.1636215 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzaTe-0006fj-JT; Thu, 27 Aug 2026 13:49:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400655.1636215; Thu, 27 Aug 2026 13:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzaTe-0006fc-Gh; Thu, 27 Aug 2026 13:49:10 +0000
Received: by outflank-mailman (input) for mailman id 1400655;
 Thu, 27 Aug 2026 13:49:09 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <gwd@xenproject.org>) id 1wzaTd-0006fW-Sg
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 13:49:09 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wzaTd-008MzX-2b
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 13:49:09 +0000
Received: from mail-lf1-f44.google.com ([209.85.167.44])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <gwd@xenproject.org>) id 1wzaTd-00BHYJ-1U
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 13:49:09 +0000
Received: by mail-lf1-f44.google.com with SMTP id
 2adb3069b0e04-5b5e18f0439so434889e87.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 06:49:09 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc
	:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version;
	bh=LLe9bL3tsHJGzzgHCRj31tZ7b1+COS93qx+rWxkgyfI=; b=N1hBI4cRYGU4+HV9pYuiOcWAux
	u1o9ATUqzvPMR+L4pv9Dvhl0YukhDLzhk8bGxibDiq2S0+nzSoFue7mOwjZe2hYnBLYCQ98y5tx67
	7LDDmgIHLsG/qTvetELwc9OPh3x5lUJzyIurEErHd9r3UlPDqsZipgiW0+Zs1ja066Y0=;
X-Gm-Message-State: AFuF++ldKmmdM3aIUeH1TXHRp8JEpzZfk4FjGav7DYta1w0VoYNkAYia
	ysR+7y4n3ZVT/Tn83G49Memo2ITDf465Zds4CNciwXDiltYDCdp35BGfTOW+bHhOMIKfeE0zgyp
	TykwvcKMKqMTle+PQbkjScsRI4lqw4cQ=
X-Received: by 2002:a05:6512:63d7:20b0:5b1:5b11:8eab with SMTP id
 2adb3069b0e04-5b4a90a106cmr3882835e87.15.1787838548046; Thu, 27 Aug 2026
 06:49:08 -0700 (PDT)
MIME-Version: 1.0
References: <b9c89c9f-20e1-441c-bf77-7da42eafdae3@suse.com>
In-Reply-To: <b9c89c9f-20e1-441c-bf77-7da42eafdae3@suse.com>
From: George Dunlap <gwd@xenproject.org>
Date: Thu, 27 Aug 2026 14:48:54 +0100
X-Gmail-Original-Message-ID: <CAFLBxZb=n9T1MhgQyOZOns=3Ns6MzyTN08s2ruBo4oDQXypmUw@mail.gmail.com>
X-Gm-Features: AcwNN1VnyUkC_2eHLUJCr92YQE45rh2eut-_WuAJceVeCAYB6__TvzcJ8eqt3Fw
Message-ID: <CAFLBxZb=n9T1MhgQyOZOns=3Ns6MzyTN08s2ruBo4oDQXypmUw@mail.gmail.com>
Subject: Re: [PATCH] x86: always park offline CPUs
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
	Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
	Stefano Stabellini <sstabellini@kernel.org>, Anthony PERARD <anthony.perard@vates.tech>, 
	Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
	Teddy Astie <teddy.astie@vates.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 26, 2026 at 1:36=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wro=
te:
>
> While on AMD (or Hygon) CPUs the situation isn't as bad wrt broadcasting
> of #MC, some "multicast" can still happen. Therefore the reasoning to par=
k
> CPUs rather than fully offlining them applies everywhere.
>
> Don't retain the dependency on the "mce=3D" cmdline option either: That
> option may best be dropped as well, as not enabling MCE will result in a
> shutdown when #MC would otherwise be raised.
>
> Drop the global variable, using a #define (just like common code does)
> instead. Outside of common code, simplify expressions / code accordingly.
> (In common code we still have to cater for x86 wanting it different from
> everyone else.)
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> As it was never actually used after its introduction, we may want to
> further consider dropping CPU_REMOVE again.
>
> I was almost certain that we would have at least one place (presumably a
> CPU notifier handler) were we assumed no parking for AMD/Hygon. Yet I
> couldn't find anything; did I overlook the crucial bits?

FWIW, the per-CPU stack mapping bit of the ASI series I have would
almost certainly have tripped over such an instance if it existed, but
didn't.

I've tested this patch on an Intel box, whose behavior in theory
shouldn't change.  Not sure if that warrants a Tested-by, given that
the main change should happen on an AMD box.

 -George


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400678.1636269 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9b-0005bN-C5; Thu, 27 Aug 2026 14:32:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400678.1636269; Thu, 27 Aug 2026 14:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9b-0005bD-8J; Thu, 27 Aug 2026 14:32:31 +0000
Received: by outflank-mailman (input) for mailman id 1400678;
 Thu, 27 Aug 2026 14:32:29 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9Z-0005BE-EK
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9Y-00Bhds-R8
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:28 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a70-2eae-0a2a0a5409dd-0a2a4503e56a-28
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:28 +0200
Received: from [52.101.66.115]
 (helo=DUZPR83CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a7c-fae8-0a2a45030019-3465427316e5-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:28 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:27 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:27 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZriI0Jig/PJCbuQ7/Aw2aGN6P3KMI9A7cU/efEWT9qzTSRwglW12g664tjbohGji1yGHXG5s8oVOryHVbNUEWAATMRR9R8cAg2R7uMsb9C/hmWaD9Vnh79doZr0LvA+m6ONZkC/Cg79eeAWwK+B/x3XwsNmvEW/f6W8J30/6mpRJV7btKLjZg4mNbJzMPwdw0XzlG84zu0KkYxGOuvUEiT4uU01+nsdlv0wFCygeABhGrR9qyzTz1M1eaZGXoLP0X0cHp6p0HqLVsNWWMovA82rA5HPkVYXjqQGXMGz1us/wR9bIvvj1j9XFebcIklHjUS/VhNNxlt3Fxu7nopdYfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hMlbOayQe38CqlIr8+dJvSe7ICFcj440kGZXZ+TcuZI=;
 b=ITFvtmO5L9CpI1pHdSX/XQLJEUIDreDEcQhPEscZ81Lo2INTJ73Sv/gIA2W2CYtRxHfXYWtL/A9rkhKLQHPrz5LeP8tF/WTP95Els+d9m/29OiPxkjalU4dOrCuV0nffkCTPTG8QB8aCiRdjEr/1KGekXVrJCXYht+hDPBs0Y44ivmogGg7xz20ISafLCf/ZDIyjCGVhm4kizJwBlBV8K9I8hOD6Px/HWkZVBA5s5PnihyhPDFZUWbiYiVij2V9mtWjk7zu/EJUcram7gQCuj/92MKzzfII6YjV41852sSgEdbWai2pvmGKlkUrHmHcwnp1YUhNOQ56uvZ9l+7u7Ag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hMlbOayQe38CqlIr8+dJvSe7ICFcj440kGZXZ+TcuZI=;
 b=HlXtXKxZwXD5S1o89zfVGXutD26Pn3qSfCEV7dGF4x2RvT2x8LD5hs8yiRGnGef6t0TyxG01ELfMABupWugEYsEkps/sOPgWie7EfKPxtxlMs3lOBIsRJ5PnTnCW69zYbqLVns+keo8PQnEZTwanakL0ihcDQL2+Lld/ae1kyD+pzC3ekG59IQ1lz3xpsXBB7w0KsDSKDYabdC0DAJeeimCNAvpSBS6SHWwsYQexQJCEngdHyRXwautlij9pGzv35QVPDiTKcwtVnwYZzB8N+zeKhL5lYSDhC6sqt91yw1aE4eRoXw67Cemf3UrMd1HrT7GbmFEB91t41gpd2xhRuw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 05/13] xen/arm: gic-v3: add ITS suspend/resume support
Date: Thu, 27 Aug 2026 17:31:53 +0300
Message-ID: <1d14b9ad58e88f19450999a6c2ce476ed31531e3.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: a59995c7-07b1-489a-c0eb-08df04480464
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|7416014|1800799024|10067099003|6133799003|3023799007|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	+nGucR34CHaK7xpAQsVcvz5xp3GkKP+7U9izTB+U49VYZ9bozTjT4sIhh+9SvmkOpRz7leP+NEtEaH+Sg8sMoRP8uq5gAM3s3YDFE1Om/6J6O9W/ca2lPoTPn9xLV9ND2hyRPZ4Zm3IBshC/hWQgd5k/O9PL+NaF24ZfxcwMP+6w0n9hPal6wAc/T83Rr4iaEJh5qLRDj+cXIoEreojmL//BZfKCqwr9LfhmM79flc8abylb/adG4eOmLGJFYtMf2R3Oxnj27MbVCV1kKABCsZ7ax6LeYudzlnPEE3Q7u5ZLD/4tAlSDFU1ngEmyKcfBJksbkjW7CKNwfBtZaV4zoPSKXb/GXZrkrsMMKciUMj5+euTenN1wNkD8EBV7rZ+FGad6ODPUIIMYQOXuZ1dfTIDyu4cwLKgZDPV+82TASZc/hTrae4cFh5IxppLo/OB4PVOg284TE1OeY30/jYMk9TMaR/139mXCy7GXtm9uqGExmbN5XKNkFpcrNGOTYoCHtodLB5DngicY+QJqTQGuAzUoQsTlPl/ENHDnluIamzPhDE8ertcCK5d1jABmY2rekSfegYn2ClATg+4gBOlaEfFs9ZnIsgHaG3fABf29YMk31hw7FjxVJpx5ywFeyFJ0xfZipmuQ9SjBn6v0+Qj5mNzjg5udpaq2WLiCysIEsBo=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(7416014)(1800799024)(10067099003)(6133799003)(3023799007)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ZOqfYy7ldZVEh4BIVP2rojKCXSd1SEpZ8GVt+65CM2yG0+bM84GYdllC7t6K?=
 =?us-ascii?Q?WrTmWE+IQ+mD2KSpDVJSD6pp2Uk2iINgB3o1LoRKEg4R7IzSylbmdbCnEkRL?=
 =?us-ascii?Q?C+tV4+x+io33I4sHoJf4X82W2rIou5kDi4Hkp3J2Jvfq9dWjvT7icNjSf+yC?=
 =?us-ascii?Q?mY6gWLyvU6KIjdliw4cUNIGuX9fHC9CwsxwWMhRZaAFOS9VU5pwGUD+8HBns?=
 =?us-ascii?Q?A1CnXTELzc/GM6LJvz7m9xX01hmolfybywuBhsy0J31FwzIc1SUmZod+oIj6?=
 =?us-ascii?Q?JRoLjzipMZeqO8nCW/Xk+NClwIr3yAkbmVslGEKESOI49p7M8+gMo0Y1gT4D?=
 =?us-ascii?Q?0P/0bHUHirv5sX38TN4GTaPfVmMwpv62S5J95H8oY3YH+wnvOdzqeZIjFOVS?=
 =?us-ascii?Q?/RXKocyDvnFG9OB9nZTKKD4io6V76cmAAgC1B2NvDCv+ITqnsEhCJpFzkCkZ?=
 =?us-ascii?Q?eO+sEjIzGwYm9bnGQgiqSRK5EeHbwMYgtNUQFC3RIbFf4Q3r7+1e45tOzyqF?=
 =?us-ascii?Q?CuBsLU9SDHmjPSEzftQB7RISACxUctJ8JldYr/hfi+P8jM/pJINnAbiQDpOh?=
 =?us-ascii?Q?9a+9kd8BGT1JZfVtsToq5fTP5d8O4jW1x68RnV7Ti5FEfuTi2GDJpt2iULhl?=
 =?us-ascii?Q?rekM3WyZSrKrjf2qcE0JWfqALeqQ/hOC2SkARP7IRfKMJMfDdBW6ZGWYF9B3?=
 =?us-ascii?Q?QCCBEsFzOx7E6X2LRnzqKLwfq2xpoGt6DVsxJJi0ZGpZu7NINEPDp9+hYHAe?=
 =?us-ascii?Q?ZGNln9cVa+13kd/ktjTh5HcYodoeV/2zCox8nz/rQSr9wzBIiVECTdKzOmWR?=
 =?us-ascii?Q?y54YWbv5kH/4n7dO979/xyBD5dR067GfzPsVGwBCTJHGwdwn8xPg2pjh7m3d?=
 =?us-ascii?Q?PPBp21nEkT8nXCq2KF5Pa76tXwGm4FinjSbYBGyvF+OH78V9673gW1x5qD0X?=
 =?us-ascii?Q?WGV+lQ+ooYaOehhZZCwERuIExH18M2nJavZ+JR/Z5QfmgKmK29fSXt1zp3qp?=
 =?us-ascii?Q?hKt6Db9VoU48EljiliyOKw3LIZ7hmN/5MwnUrYaklolh+JTH0NBJEMMveFks?=
 =?us-ascii?Q?uLH09/+1KpRU2ivU1St9gqwZ3kutq2UR8AsiSVIaAyj8VhsKLK9TpMRYoTux?=
 =?us-ascii?Q?Q8DzwTDosAcrnQZKWK6bw8DVCLy9uMZDsbOCqgF8j2oQ8TL0TM1NwTRYNdE3?=
 =?us-ascii?Q?4+qU+zfOMhFMTDiQ4oMGS89NVRYXYXNOxtjxkPSN+MOSaO508GmoOY6+hq7p?=
 =?us-ascii?Q?16XJ4LYLGzcbKLgm4q48gzkkThWXaE683EteTZpbo/anxMDVKuFcjZbnLWbj?=
 =?us-ascii?Q?uCpvjoYVyNZ1cGav8DSIaY0wins2KJhy5AbD6n2rkVMZ/vai6wU6vQznJCtZ?=
 =?us-ascii?Q?kF4UtDBbtjplgmRdDpPc9S4d/IoSMRKKO4HBokgu3R8hKIwPIhK2aCO8ibSX?=
 =?us-ascii?Q?HSkaA5+urElK/IIZKTDsIhH09VkGBhbi/t/jwkuWqzRS94F6gVXTmKXHwhz+?=
 =?us-ascii?Q?XPvhjn0rWfu1UUZBEOeLlmh0Fwvk/FgPf+TROVzZpvAhp+keDeKGjFIA72wv?=
 =?us-ascii?Q?tng5i5BR+x+KfOFg0q6fPG1NrlYsuq5zELa0I4HZ25Cz9BElpHRrRZQFXTlw?=
 =?us-ascii?Q?GJ2uw3Q6G5tLtzsdB7kU5zHBYMu81cyBegEoy9qDzvuJxPrORBjxGrfl2LZs?=
 =?us-ascii?Q?yIUbCrvVDv6aYQDgKw7j1q85yejO1qtObIGtwA6T0LJJHv96dW9gWrqDBjN2?=
 =?us-ascii?Q?lTz/o8IyAA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a59995c7-07b1-489a-c0eb-08df04480464
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:26.9171
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0+fEh5B1OdB0lk0kHecO0vT6SyqvYu46pYQKrv7ucKF8aXyWxZNaaZqS1Eeo3jUCue84MmO8vXxAovaG5HwBdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-33051d/1787841148-764FC4E9-F1492407/0/0
X-purgate-type: clean
X-purgate-size: 11113

Handle system suspend/resume for GICv3 with an ITS present so LPIs keep
working after firmware powers the GIC down.

Save and restore the ITS CTLR, CBASER and BASER registers. On resume,
re-establish the collection mapping only when the collection is held in
the ITS itself. Memory-backed collections are restored through the
restored GITS_BASER tables and must not be remapped unconditionally.

Add list_for_each_entry_continue_reverse() in list.h for the ITS suspend
error path that needs to roll back partially saved state.

Based on Linux commit dba0bc7b76dc:
"irqchip/gic-v3-its: Add ability to save/restore ITS state".
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in V10:
- Replay MAPC on resume only for collections held in the ITS itself, as
  indicated by GITS_TYPER.HCC. Memory-backed collections are restored
  through GITS_BASER and are no longer remapped unconditionally.
- Make the current Xen col_id == cpu assumption explicit in the ITS
  resume path.
- Use "unpredictable" instead of "undefined" in the CBASER/BASER restore
  comment.

Changes in V9:
- fix the ITS suspend/resume coding-style nits;
- preserve the saved GITS_CTLR state while masking the read-only
  QUIESCENT bit.

Changes in V8:
- Reword the CBASER/CWRITER comment to match Xen and drop the stale Linux
  cmd_write reference.
- Clarify the list_for_each_entry_continue_reverse() comment.
- Factor out per-ITS helpers for collection setup and resume.
- Restore each ITS and re-establish its collection mapping in the same
  loop, so a failed ITS resume is not followed by MAPC/SYNC on that
  un-restored instance.
- panic in case when resume of an ITS failed
- cleanup baser cache during suspend
---
 xen/arch/arm/gic-v3-its.c             | 146 ++++++++++++++++++++++++--
 xen/arch/arm/gic-v3.c                 |  11 +-
 xen/arch/arm/include/asm/gic_v3_its.h |  28 +++++
 xen/include/xen/list.h                |  14 +++
 4 files changed, 189 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 7560d46c6d..dd53209865 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -335,6 +335,22 @@ static int its_send_cmd_inv(struct host_its *its,
     return its_send_command(its, cmd);
 }
 
+static int gicv3_its_setup_collection_single(struct host_its *its,
+                                             unsigned int cpu)
+{
+    int ret;
+
+    ret = its_send_cmd_mapc(its, cpu, cpu);
+    if ( ret )
+        return ret;
+
+    ret = its_send_cmd_sync(its, cpu);
+    if ( ret )
+        return ret;
+
+    return gicv3_its_wait_commands(its);
+}
+
 /* Set up the (1:1) collection mapping for the given host CPU. */
 int gicv3_its_setup_collection(unsigned int cpu)
 {
@@ -343,15 +359,7 @@ int gicv3_its_setup_collection(unsigned int cpu)
 
     list_for_each_entry(its, &host_its_list, entry)
     {
-        ret = its_send_cmd_mapc(its, cpu, cpu);
-        if ( ret )
-            return ret;
-
-        ret = its_send_cmd_sync(its, cpu);
-        if ( ret )
-            return ret;
-
-        ret = gicv3_its_wait_commands(its);
+        ret = gicv3_its_setup_collection_single(its, cpu);
         if ( ret )
             return ret;
     }
@@ -1211,6 +1219,126 @@ int gicv3_its_init(void)
     return 0;
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+int gicv3_its_suspend(void)
+{
+    struct host_its *its;
+    int ret;
+
+    list_for_each_entry( its, &host_its_list, entry )
+    {
+        unsigned int i;
+        void __iomem *base = its->its_base;
+
+        /*
+         * By the time Xen reaches gic_suspend(), every domain is already in
+         * SHUTDOWN_suspend, so ITS-targeting interrupt sources are expected
+         * to have been quiesced by the owning OS before SYSTEM_SUSPEND.
+         */
+        /* Preserve saved GITS_CTLR state, excluding read-only QUIESCENT. */
+        its->suspend_ctx.ctlr = readl_relaxed(base + GITS_CTLR) &
+                                ~GITS_CTLR_QUIESCENT;
+        ret = gicv3_disable_its(its);
+        if ( ret )
+        {
+            writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR);
+            goto err;
+        }
+
+        its->suspend_ctx.cbaser = readq_relaxed(base + GITS_CBASER);
+
+        for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
+        {
+            uint64_t baser = readq_relaxed(base + GITS_BASER0 + i * 8);
+
+            its->suspend_ctx.baser[i] = 0;
+
+            if ( !(baser & GITS_VALID_BIT) )
+                continue;
+
+            its->suspend_ctx.baser[i] = baser;
+        }
+    }
+
+    return 0;
+
+ err:
+    list_for_each_entry_continue_reverse( its, &host_its_list, entry )
+        writel_relaxed(its->suspend_ctx.ctlr, its->its_base + GITS_CTLR);
+
+    return ret;
+}
+
+static int gicv3_its_resume_single(struct host_its *its, unsigned int cpu)
+{
+    void __iomem *base = its->its_base;
+    unsigned int i;
+    int ret;
+    uint64_t typer;
+    unsigned int col_id = cpu; /* Xen currently uses col_id == cpu. */
+
+    /*
+     * Make sure that the ITS is disabled. If it fails to quiesce,
+     * don't restore it since writing to CBASER or BASER<n>
+     * registers is unpredictable according to the GIC v3 ITS
+     * Specification.
+     */
+    WARN_ON(readl_relaxed(base + GITS_CTLR) & GITS_CTLR_ENABLE);
+    ret = gicv3_disable_its(its);
+    if ( ret )
+        return ret;
+
+    writeq_relaxed(its->suspend_ctx.cbaser, base + GITS_CBASER);
+
+    /*
+     * Writing CBASER resets CREADR to 0, so reset CWRITER to
+     * keep the command queue pointers aligned.
+     */
+    writeq_relaxed(0, base + GITS_CWRITER);
+
+    /* Restore GITS_BASER from the value cache. */
+    for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
+    {
+        uint64_t baser = its->suspend_ctx.baser[i];
+
+        if ( !(baser & GITS_VALID_BIT) )
+            continue;
+
+        writeq_relaxed(baser, base + GITS_BASER0 + i * 8);
+    }
+
+    writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR);
+
+    typer = readq_relaxed(base + GITS_TYPER);
+
+    /*
+     * Only collections with IDs below HCC are held in the ITS itself
+     * and lose their state across an ITS reset/power loss. Memory-backed
+     * collections are restored by restoring GITS_BASER and must not be
+     * remapped here.
+     */
+    if ( col_id < GITS_TYPER_HCC(typer) )
+        return gicv3_its_setup_collection_single(its, cpu);
+
+    return 0;
+}
+
+void gicv3_its_resume(void)
+{
+    struct host_its *its;
+    unsigned int cpu = smp_processor_id();
+    int ret;
+
+    list_for_each_entry( its, &host_its_list, entry )
+    {
+        ret = gicv3_its_resume_single(its, cpu);
+        if ( ret )
+            panic("GICv3: ITS@%"PRIpaddr": failed to restore during resume: %d\n",
+                   its->addr, ret);
+    }
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
 
 /*
  * Local variables:
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 038bf41142..6b025c023d 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -2186,10 +2186,14 @@ static int gicv3_suspend(void)
     if ( ret )
         goto out_enable_iface;
 
-    ret = gicv3_disable_redist();
+    ret = gicv3_its_suspend();
     if ( ret )
         goto out_enable_iface;
 
+    ret = gicv3_disable_redist();
+    if ( ret )
+        goto out_its_resume;
+
     /* Save GICR configuration */
     gicv3_redist_wait_for_rwp();
 
@@ -2229,6 +2233,9 @@ static int gicv3_suspend(void)
 
     return 0;
 
+ out_its_resume:
+    gicv3_its_resume();
+
  out_enable_iface:
     if ( gicv3_enable_redist() )
         panic("GICv3: Failed to re-enable redistributor after suspend abort\n");
@@ -2355,6 +2362,8 @@ static void gicv3_resume(void)
 
     gicv3_redist_wait_for_rwp();
 
+    gicv3_its_resume();
+
     WRITE_SYSREG(gicv3_ctx.cpu.sre_el2, ICC_SRE_EL2);
     isb();
 
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
index fc5a84892c..0f8cb16e41 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -43,6 +43,11 @@
 #define GITS_CTLR_QUIESCENT             BIT(31, UL)
 #define GITS_CTLR_ENABLE                BIT(0, UL)
 
+#define GITS_TYPER_HCC_SHIFT            24
+#define GITS_TYPER_HCC_MASK             0xffUL
+#define GITS_TYPER_HCC(r)               (((r) >> GITS_TYPER_HCC_SHIFT) & \
+                                                 GITS_TYPER_HCC_MASK)
+
 #define GITS_TYPER_PTA                  BIT(19, UL)
 #define GITS_TYPER_DEVIDS_SHIFT         13
 #define GITS_TYPER_DEVIDS_MASK          (0x1fUL << GITS_TYPER_DEVIDS_SHIFT)
@@ -129,6 +134,13 @@ struct host_its {
     spinlock_t cmd_lock;
     void *cmd_buf;
     unsigned int flags;
+#ifdef CONFIG_SYSTEM_SUSPEND
+    struct suspend_ctx {
+        uint32_t ctlr;
+        uint64_t cbaser;
+        uint64_t baser[GITS_BASER_NR_REGS];
+    } suspend_ctx;
+#endif
 };
 
 /* Map a collection for this host CPU to each host ITS. */
@@ -204,6 +216,11 @@ uint64_t gicv3_its_get_cacheability(void);
 uint64_t gicv3_its_get_shareability(void);
 unsigned int gicv3_its_get_memflags(void);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+int gicv3_its_suspend(void);
+void gicv3_its_resume(void);
+#endif
+
 #else
 
 #ifdef CONFIG_ACPI
@@ -271,6 +288,17 @@ static inline int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
     return 0;
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+static inline int gicv3_its_suspend(void)
+{
+    return 0;
+}
+
+static inline void gicv3_its_resume(void)
+{
+}
+#endif
+
 #endif /* CONFIG_HAS_ITS */
 
 #endif
diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h
index 98d8482dab..2aab274157 100644
--- a/xen/include/xen/list.h
+++ b/xen/include/xen/list.h
@@ -535,6 +535,20 @@ static inline void list_splice_init(struct list_head *list,
          &(pos)->member != (head);                                        \
          (pos) = list_entry((pos)->member.next, typeof(*(pos)), member))
 
+/**
+ * list_for_each_entry_continue_reverse - iterate backwards from the given point
+ * @pos:    the type * to use as a loop cursor.
+ * @head:   the head for your list.
+ * @member: the name of the list_head within the struct.
+ *
+ * Iterate over list of given type backwards, starting from the element previous
+ * to the current one in list order.
+ */
+#define list_for_each_entry_continue_reverse(pos, head, member)           \
+    for ((pos) = list_entry((pos)->member.prev, typeof(*(pos)), member);  \
+         &(pos)->member != (head);                                        \
+         (pos) = list_entry((pos)->member.prev, typeof(*(pos)), member))
+
 /**
  * list_for_each_entry_from - iterate over list of given type from the
  *                            current point
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400677.1636254 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9Z-000572-5L; Thu, 27 Aug 2026 14:32:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400677.1636254; Thu, 27 Aug 2026 14:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9Y-00055O-Um; Thu, 27 Aug 2026 14:32:28 +0000
Received: by outflank-mailman (input) for mailman id 1400677;
 Thu, 27 Aug 2026 14:32:27 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9X-0004k5-MC
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9X-000Qzn-2h
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:27 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a65-e002-0a2a0a5209dd-0a2a4504a44e-46
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:27 +0200
Received: from [40.107.130.87]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a7a-b57f-0a2a45040019-286b82575a96-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:26 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:25 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TYo+4RTFdMAc5wgviewGf7WS7RSeAMdOXbFM6YoW9j9K00/SfX8RzV3fE8hajHbPd8egREjJ3JUeZR1Y5o2dO8ttqLE4y8z8mzKsxYm3f1tjkTKCF2alKY/L6RQTgEByVeduwHDHCsqlf67FkzI7X/0oU1x302ONbmB8b1pXgKK0JhNsyUEaaEIC+S1HUpV0uHQ3qkxbZg7WqpZNncBNnVhnhl5FT4Ou3OJLCY+NFLr/DPRgq6MsMuLyIBezmdNns91PE7DVW8UoGpbrpqif9WltWjvSMezkt/Vj7VTVYQ4vWe8htskGl1oH7VuPtvn9me++kCnyMyLcm5JxoBaMBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AybgVadg88br4oFv49MMcNnv89Nd8MDn3fBE6QRzNfk=;
 b=yk6Wfxhlj9Gp/roXV8/twiJJIJeZM7SO8SzpbMvw8KWO0ilcq74M6eqH76FdFXQCR0BCWW0USIx4pSNv0aAO8EC95rHSokMCHmEP5Z6EdF99ymuVbUq/3qc1qZDmkRvf81Iv07XO5bVcwtp7q1ii3OAz98JsBf2yFuTo5a2qhID5Zp4oR7mXnxxmJvuXjG32U2IQ4J7he0n3to7IATbeMjp5z3sdid1TmUDSzQF3tYZTfRvZbJEr59pmlNdfM6Jo6hjTAio9jUJMBCP0dZRKBbCWbykKFr13qYW2GKBTbmcvudOTAvh9bnEAHkR4aWv8/xxyruGBMfjZsKqiRVhQKw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=AybgVadg88br4oFv49MMcNnv89Nd8MDn3fBE6QRzNfk=;
 b=AUixo00z/ZRwoB1PETuaHeM7huBnuzfGNfB0OI/2BUnkaDSB2tfnaxDnpQkX+UQyNAOxyr8GbRbXuXTJzugTyt+dhh9WoLpeCpTrsRIHXLM3cvM7n1TZXBz18LxVnTD6LstM1AdstBK5/lZXZLNeAjUgSD/yE+gQXPTLraeaBlVOOIHpDsZViYdnAYjputfUdXcu7Acftea1H42AsDaD7Q0X75BQpS1QXkYtDJUAEPrp2Adx2s7F5xPAqirlhBVCTF/R8E94HkUqf9PQH/tYPZ0ewzWy71IMKKFP7tL3EtOqa8xXUdmuVwXaLT9Y5x/iReZJUIAOgkXSWVGkAzFGog==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 04/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions
Date: Thu, 27 Aug 2026 17:31:52 +0300
Message-ID: <1f311886ad3162f59749210c7dce26f9d089d010.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 28aba7c4-2905-4562-27f8-08df04480361
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|5023799004|56012099006;
X-Microsoft-Antispam-Message-Info:
	H8r6JjHxZRydPtXeREeK2/1eRMy4/Fd27nDwtvzFPWMv+4FC1F72EVNEb8yFbwu2v3v/9kk3AWaFZJcaYr47jybC6tnY8qXX+I8N6Nq4SaYyuPPT/tWLLhlbIypgieoVNb2LVWwcbDSUEFZA32R4i5MLzHLB+woYGWvzRolM9v18S2MblwludWsAz1h84vjn7AX8RxwlFqvXs2fU3Jn1GGtDYa5V40idDM/7YUE7NA5zBNXr+idONXvHY6ObOB77yuE+raWcvSo9Ivg4j2sTcmSLB7UXQUoGHOt01Yt4iTWu+SmYo5aItlaJDlOe2k2WXGJbIv+/63pislHGXjK/jGY85wfSLh+dvNSIDrU4toNRRjPEHpy9cJOf/04vVm3W64EzuctUdNQkwNHAw9MSTOEH/yjbCI6QhRSzMahGbOThl/UReeKLPbxhLB3Ir/3TDyMYkG+V9mL8fgUszF8wZr2KAMSPCwkG8yYNB2IOoRAzU3VIR7MNyCxW1xZBQOwOlPzZ184DMwixYWD8PUTGdR5nJZjfOQlPXcv9Gk7YN9mJrd4c2JV9kCCCQ/ibepjT3r/zjpcO7rY8+dlaEWV1VAc2Cx4PBOBb+slyigq6eJnYY17TWcqIjjOxPgnH7+fam1ZQT0/fpt0OI5bhU/WzCc3hLSlow36u9eyT8DR+KQI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(5023799004)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?kG28Knq4+yeIfQ5IDUeGFV4A80YEma6HumL/b1u9ovpTmGEq0PwYIq2RZHKY?=
 =?us-ascii?Q?We3nW7PdNcqMz1NGy00aR4IFD6WThQSvHR5qkO+l0/cRAS1f7BQ+Ty3ZtG9g?=
 =?us-ascii?Q?XyfWxscdU+W8tZ2Z1LfLuQiFmU4Wt41Hy3rvVEX2oEO0QxnIYlimc9zBB3UW?=
 =?us-ascii?Q?rSNHtwrvfvVweUZWEUd+0971aqB93pvlsaKaLYCoevoVvBUXimSPkB1X8m/p?=
 =?us-ascii?Q?CBpucKoaBkXP1/81IeAPx21FPfH9GB2ybnIqSVRKt6ZWj2b2XUgug3aAEIER?=
 =?us-ascii?Q?B1QJobvZwscUksOsD/uP+ZcdrB4gdhwx2kT0cdnGiASXrTOLI+ulbKCCK5Nz?=
 =?us-ascii?Q?uHud6kFN92mC0cjNeB2H5V91uyOIIkdF91seVRIZo1wHbitoEsOncN2w9W5f?=
 =?us-ascii?Q?NQQMTDScDDgP+3vpCU4PyKOwedhB0RrPR+RYau+JDKL1duAibNHc0Oi1ZoYt?=
 =?us-ascii?Q?AlU/CYjBqfWoSe2Enc/OoPKYWw9QV7Kf/skOIZbrS2aUjHJ3R/+ZeVSiv5x2?=
 =?us-ascii?Q?Wu01AW6OAOiqTQ1TveQ1neGT8pMV/dbm9XqF1KzXkn7ozklE9ilBj7iVQz03?=
 =?us-ascii?Q?93k2onzqu0c4cFSzC+7yA+VSLu9c6ckKxP19xuTW+aN8VIz05YZrz3VxnpBQ?=
 =?us-ascii?Q?5kRr3tr1oGHWR5axPFOTorR4ld3ZBqQpPKkXFYyCZBExNoD4PrsHvFEOMrAf?=
 =?us-ascii?Q?ePSkLE6j7xxmQab3SEjuuqb97AVF21lL7dzFGHiKgJ+fvH8qbM+ofbXLznQ1?=
 =?us-ascii?Q?+vX1/oW2zxEEXm06n1pAt2eiVZKIMNN97fL8GQ4qtvrsQLeImOGsUruaPpGK?=
 =?us-ascii?Q?b4Gi3MQ18f9VK4X4kvLt5sL/SUsqRu2/SjyZb+Y85viWogTbmw5rTlI8xTWs?=
 =?us-ascii?Q?65zEs57+nbEaDtA9I8tcimAq8TXU7MFqy4XlsnxPFw5MntQ3Vqo4rDsAZZPN?=
 =?us-ascii?Q?mCVl/JPKoD265u3ihok1BDKoSxyDxKFKIaPe5FvOU1B94tpooNQYFxFFInnI?=
 =?us-ascii?Q?FdmC4nLhfzxvWbdS85OPI5iWti8gAsZUvcqsdXvJ6UWi2rzJGVRtUBPBvoZy?=
 =?us-ascii?Q?TvgafFPj07RcOoFlDL0q7bww640/nWqwh4ZoroKQlCCihBP8t/mPqusVpi/m?=
 =?us-ascii?Q?X7EmJB2N6jVD2jskcClVCpsY1k4lU3MUy7fONfnGuNML7kmTiusrgcy54xmb?=
 =?us-ascii?Q?/tWEEBf6MPOkbCv2MSmoNREaG2XFdzB2IaWas/KVujbllcxhu3wd9Qw+79SK?=
 =?us-ascii?Q?bWrQVaNqH/8pr6MEErcjISALqSTJNXm3Wwdf77Ap6yJDlWJdX9DyDEoQPLi+?=
 =?us-ascii?Q?W55gcYAOvVhNk2cMva7RFZSKM5IQdWOd+xGQb7nNQr+u3E5t15nG6TPcre2q?=
 =?us-ascii?Q?cjETkaXyMNY8azqOOUAP9Vw9eCYPdWTgqkKbru8RuZMc5AZOYl1HTcTiZZ5n?=
 =?us-ascii?Q?tcdjKGtR7GueKfrBv1v4eZPepzW9Tzs9ZmrbJ7/lkV7qSGA+pPt8+G7zn0lv?=
 =?us-ascii?Q?GyadjAKQO1S86XFQ7ilWF3VT43F/51V2G+cK6Ge9yT18W+mtqfgM+OOv/pnY?=
 =?us-ascii?Q?jf6atB1oaJU8X5wFN2f9iAsf6ZHkxRMoFR1MtZAbWsnq5ot7ZqNUmCtbsgZg?=
 =?us-ascii?Q?dq3miwEh7ZImXriLo3MpoemsJB+qLZx9e3OOhReQtbWurJjyxw+KPwkmHexh?=
 =?us-ascii?Q?30JaKLfOoabGXT882xJv/u1yzND4KyRnfglMsBZXg5SR4isWZH064TFXkUer?=
 =?us-ascii?Q?3ss/9eWfMA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 28aba7c4-2905-4562-27f8-08df04480361
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:25.2921
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ESz4E8+l7MLNKxZSLrqzGJC9x5sY/+ILZoKU9naLUjLIR6Bgok2uBu6GYFH1/gfWmwzG6juCpg4jNpKmAJG/Gw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-ebf023/1787841147-50CDFB50-CF4C0D41/0/0
X-purgate-type: clean
X-purgate-size: 21035

System suspend may lead to a state where GIC would be powered down.
Therefore, Xen should save/restore the context of GIC on suspend/resume.

Note that the context consists of states of registers which are
controlled by the hypervisor. Other GIC registers which are accessible
by guests are saved/restored on context switch.

Before continuing suspend, also verify that the physical CPU interface
has no Group 1 active-priority state left. Use ICC_CTLR_EL1.PRIbits to
decide which ICC_AP1R<n>_EL1 registers are implemented, so Xen does not
read an unimplemented AP1R register.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in V10:
- abort suspend when the physical Group 1 active-priority state is still
  present, deriving accessible ICC_AP1R<n>_EL1 registers from
  ICC_CTLR_EL1.PRIbits;
- re-enable the redistributor before restoring CPU and virtual interface
  state on the suspend abort path;
- panic if the redistributor cannot be re-enabled on the suspend abort path;
- avoid saving/restoring reserved GICD_IPRIORITYR and GICD_IROUTER entries
  for a partially populated last SPI block;
- disable Distributor group forwarding while preserving affinity routing
  state before restoring Distributor configuration;
- disable SPI/eSPI forwarding and wait for RWP before restoring
  GICD_ICFGR<n>.Int_config.

Changes in V9:
- fix the suspend-context comment typo and split dist_ctx declarations;
- restore ICC_IGRPEN1_EL1 on the suspend error path;
- re-initialize GICD_IGROUPRnE during resume;
- restore GICD_IROUTER only after re-enabling ARE_NS during resume.

Changes in V8:
- use right rdist base for prop/pend baser and ctrl

Changes in V7:
- restore LPI regs on resume
- add timeout during redist disabling
- squash with suspend/resume handling for GICv3 eSPI registers
- drop ITS guard paths so suspend/resume always runs; switch missing ctx
  allocation to panic
- trim TODO comments; narrow redistributor storage to PPI icfgr
- keep distributor context allocation even without ITS; adjust resume
  to use GENMASK(31, 0) for clearing enables
- drop storage of the SGI configuration register, as SGIs are always
  edge-triggered
---
 xen/arch/arm/gic-v3-lpi.c                |   3 +
 xen/arch/arm/gic-v3.c                    | 458 ++++++++++++++++++++++-
 xen/arch/arm/include/asm/arm64/sysregs.h |   5 +
 xen/arch/arm/include/asm/gic_v3_defs.h   |   3 +
 4 files changed, 466 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 847da26ff7..a63c8c4979 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -467,6 +467,9 @@ static int cpu_callback(struct notifier_block *nfb, unsigned long action,
     switch ( action )
     {
     case CPU_UP_PREPARE:
+        if ( system_state == SYS_STATE_resume )
+            break;
+
         rc = gicv3_lpi_allocate_pendtable(cpu);
         if ( rc )
             printk(XENLOG_ERR "Unable to allocate the pendtable for CPU%lu\n",
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b16888ad84..038bf41142 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1078,12 +1078,12 @@ out:
     return res;
 }
 
-static void gicv3_hyp_disable(void)
+static void gicv3_hyp_enable(bool enable)
 {
     register_t hcr;
 
     hcr = READ_SYSREG(ICH_HCR_EL2);
-    hcr &= ~GICH_HCR_EN;
+    hcr = enable ? (hcr | GICH_HCR_EN) : (hcr & ~GICH_HCR_EN);
     WRITE_SYSREG(hcr, ICH_HCR_EL2);
     isb();
 }
@@ -1190,7 +1190,7 @@ static void gicv3_disable_interface(void)
     spin_lock(&gicv3.lock);
 
     gicv3_cpu_disable();
-    gicv3_hyp_disable();
+    gicv3_hyp_enable(false);
 
     spin_unlock(&gicv3.lock);
 }
@@ -1926,6 +1926,450 @@ static bool gic_dist_supports_lpis(void)
     return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+/* This struct represents a block of 32 IRQs */
+struct dist_irq_block {
+    uint32_t icfgr[2];
+    uint32_t ipriorityr[8];
+    uint64_t irouter[32];
+    uint32_t isactiver;
+    uint32_t isenabler;
+};
+
+struct redist_ctx {
+    uint32_t ctlr;
+    uint32_t icfgr; /* only PPIs stored */
+    uint32_t igroupr;
+    uint32_t ipriorityr[8];
+    uint32_t isactiver;
+    uint32_t isenabler;
+
+    uint64_t pendbase;
+    uint64_t propbase;
+};
+
+/* GICv3 registers to be saved/restored on system suspend/resume */
+struct gicv3_ctx {
+    struct dist_ctx {
+        uint32_t ctlr;
+        struct dist_irq_block *irqs;
+        struct dist_irq_block *espi_irqs;
+    } dist;
+
+    /* have only one rdist structure for last running CPU during suspend */
+    struct redist_ctx rdist;
+
+    struct cpu_ctx {
+        uint32_t ctlr;
+        uint32_t pmr;
+        uint32_t bpr;
+        uint32_t sre_el2;
+        uint32_t grpen;
+    } cpu;
+};
+
+static struct gicv3_ctx gicv3_ctx;
+
+static void __init gicv3_alloc_context(void)
+{
+    uint32_t blocks = DIV_ROUND_UP(gicv3_info.nr_lines, 32);
+
+    /* The spec allows for systems without any SPIs */
+    if ( blocks > 1 )
+    {
+        gicv3_ctx.dist.irqs = xzalloc_array(struct dist_irq_block, blocks - 1);
+        if ( !gicv3_ctx.dist.irqs )
+            panic("Failed to allocate memory for GICv3 suspend context\n");
+    }
+
+#ifdef CONFIG_GICV3_ESPI
+    if ( !gic_number_espis() )
+        return;
+
+    blocks = gic_number_espis() / 32;
+    gicv3_ctx.dist.espi_irqs = xzalloc_array(struct dist_irq_block, blocks);
+    if ( !gicv3_ctx.dist.espi_irqs )
+        panic("Failed to allocate memory for GICv3 eSPI suspend context\n");
+#endif
+}
+
+static int gicv3_disable_redist(void)
+{
+    void __iomem *waker = GICD_RDIST_BASE + GICR_WAKER;
+    s_time_t deadline;
+
+    /*
+     * Avoid infinite loop if Non-secure does not have access to GICR_WAKER.
+     * See Arm IHI 0069H.b, 12.11.42 GICR_WAKER:
+     *     When GICD_CTLR.DS == 0 and an access is Non-secure accesses to this
+     *     register are RAZ/WI.
+     */
+    if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) )
+        return 0;
+
+    deadline = NOW() + MILLISECS(1000);
+
+    writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, waker);
+    while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) == 0 )
+    {
+        if ( NOW() > deadline )
+        {
+            printk("GICv3: Timeout waiting for redistributor to sleep\n");
+            return -ETIMEDOUT;
+        }
+        cpu_relax();
+        udelay(10);
+    }
+
+    return 0;
+}
+
+#define GET_SPI_REG_OFFSET(name, is_espi) \
+    ((is_espi) ? GICD_##name##nE : GICD_##name)
+
+static void gicv3_store_spi_irq_block(struct dist_irq_block *irqs,
+                                      unsigned int i, unsigned int nr_irqs,
+                                      bool is_espi)
+{
+    void __iomem *base;
+    unsigned int irq, nr_priority_regs;
+
+    ASSERT(nr_irqs && nr_irqs <= 32);
+    nr_priority_regs = DIV_ROUND_UP(nr_irqs, 4);
+
+    base = GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + i * sizeof(irqs->icfgr);
+    irqs->icfgr[0] = readl_relaxed(base);
+    irqs->icfgr[1] = readl_relaxed(base + 4);
+
+    base = GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi);
+    base += i * sizeof(irqs->ipriorityr);
+    for ( irq = 0; irq < nr_priority_regs; irq++ )
+        irqs->ipriorityr[irq] = readl_relaxed(base + 4 * irq);
+
+    base = GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi);
+    base += i * sizeof(irqs->irouter);
+    for ( irq = 0; irq < nr_irqs; irq++ )
+        irqs->irouter[irq] = readq_relaxed_non_atomic(base + 8 * irq);
+
+    base = GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi);
+    base += i * sizeof(irqs->isactiver);
+    irqs->isactiver = readl_relaxed(base);
+
+    base = GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi);
+    base += i * sizeof(irqs->isenabler);
+    irqs->isenabler = readl_relaxed(base);
+}
+
+static void gicv3_restore_spi_irq_config(struct dist_irq_block *irqs,
+                                         unsigned int i, unsigned int nr_irqs,
+                                         bool is_espi)
+{
+    void __iomem *base;
+    unsigned int irq, nr_priority_regs;
+
+    ASSERT(nr_irqs && nr_irqs <= 32);
+    nr_priority_regs = DIV_ROUND_UP(nr_irqs, 4);
+
+    base = GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + i * sizeof(irqs->icfgr);
+    writel_relaxed(irqs->icfgr[0], base);
+    writel_relaxed(irqs->icfgr[1], base + 4);
+
+    base = GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi);
+    base += i * sizeof(irqs->ipriorityr);
+    for ( irq = 0; irq < nr_priority_regs; irq++ )
+        writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq);
+}
+
+static void gicv3_restore_spi_irq_routing(struct dist_irq_block *irqs,
+                                          unsigned int i, unsigned int nr_irqs,
+                                          bool is_espi)
+{
+    void __iomem *base;
+    unsigned int irq;
+
+    ASSERT(nr_irqs && nr_irqs <= 32);
+
+    base = GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi);
+    base += i * sizeof(irqs->irouter);
+    for ( irq = 0; irq < nr_irqs; irq++ )
+        writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq);
+}
+
+static void gicv3_disable_spi_irq_block(unsigned int i, bool is_espi)
+{
+    void __iomem *base;
+
+    base = GICD + GET_SPI_REG_OFFSET(ICENABLER, is_espi) + i * 4;
+    writel_relaxed(GENMASK(31, 0), base);
+}
+
+static void gicv3_restore_spi_irq_state(struct dist_irq_block *irqs,
+                                        unsigned int i, bool is_espi)
+{
+    void __iomem *base;
+
+    base = GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi);
+    base += i * sizeof(irqs->isenabler);
+    writel_relaxed(irqs->isenabler, base);
+
+    base = GICD + GET_SPI_REG_OFFSET(ICACTIVER, is_espi) + i * 4;
+    writel_relaxed(GENMASK(31, 0), base);
+
+    base = GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi);
+    base += i * sizeof(irqs->isactiver);
+    writel_relaxed(irqs->isactiver, base);
+}
+
+static int gicv3_check_ap1r(unsigned int n, register_t apr)
+{
+    if ( !apr )
+        return 0;
+
+    printk(XENLOG_ERR "GICv3: suspend aborted: ICC_AP1R%u_EL1=%#"
+           PRIregister"\n", n, apr);
+
+    return -EBUSY;
+}
+
+static int gicv3_check_active_priorities(register_t ctlr)
+{
+    unsigned int pribits = MASK_EXTR(ctlr, ICC_CTLR_EL1_PRIBITS_MASK) + 1;
+    int ret;
+
+    /*
+     * Xen enables physical Group 1 interrupts through ICC_IGRPEN1_EL1,
+     * so only the physical Group 1 active-priority registers are relevant
+     * here. Use ICC_CTLR_EL1.PRIbits for the physical CPU interface, not
+     * ICH_VTR_EL2, which describes the virtual interface. ICC_AP1R1_EL1 is
+     * only implemented with at least 6 physical priority bits, and
+     * ICC_AP1R2_EL1/ICC_AP1R3_EL1 with at least 7.
+     */
+    switch ( pribits )
+    {
+    case 8:
+    case 7:
+        ret = gicv3_check_ap1r(3, READ_SYSREG(ICC_AP1R3_EL1));
+        if ( ret )
+            return ret;
+        ret = gicv3_check_ap1r(2, READ_SYSREG(ICC_AP1R2_EL1));
+        if ( ret )
+            return ret;
+        /* Fall through */
+    case 6:
+        ret = gicv3_check_ap1r(1, READ_SYSREG(ICC_AP1R1_EL1));
+        if ( ret )
+            return ret;
+        /* Fall through */
+    default:
+        return gicv3_check_ap1r(0, READ_SYSREG(ICC_AP1R0_EL1));
+    }
+}
+
+static int gicv3_suspend(void)
+{
+    unsigned int i, nr_irqs;
+    void __iomem *base;
+    int ret;
+    struct redist_ctx *rdist = &gicv3_ctx.rdist;
+
+    /* Save GICC configuration */
+    gicv3_ctx.cpu.ctlr     = READ_SYSREG(ICC_CTLR_EL1);
+    gicv3_ctx.cpu.pmr      = READ_SYSREG(ICC_PMR_EL1);
+    gicv3_ctx.cpu.bpr      = READ_SYSREG(ICC_BPR1_EL1);
+    gicv3_ctx.cpu.sre_el2  = READ_SYSREG(ICC_SRE_EL2);
+    gicv3_ctx.cpu.grpen    = READ_SYSREG(ICC_IGRPEN1_EL1);
+
+    gicv3_disable_interface();
+
+    ret = gicv3_check_active_priorities(gicv3_ctx.cpu.ctlr);
+    if ( ret )
+        goto out_enable_iface;
+
+    ret = gicv3_disable_redist();
+    if ( ret )
+        goto out_enable_iface;
+
+    /* Save GICR configuration */
+    gicv3_redist_wait_for_rwp();
+
+    base = GICD_RDIST_BASE;
+
+    rdist->ctlr = readl_relaxed(base + GICR_CTLR);
+
+    rdist->propbase = readq_relaxed(base + GICR_PROPBASER);
+    rdist->pendbase = readq_relaxed(base + GICR_PENDBASER);
+
+    base = GICD_RDIST_SGI_BASE;
+
+    /* Save priority on PPI and SGI interrupts */
+    for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ )
+        rdist->ipriorityr[i] = readl_relaxed(base + GICR_IPRIORITYR0 + 4 * i);
+
+    rdist->isactiver = readl_relaxed(base + GICR_ISACTIVER0);
+    rdist->isenabler = readl_relaxed(base + GICR_ISENABLER0);
+    rdist->igroupr   = readl_relaxed(base + GICR_IGROUPR0);
+    rdist->icfgr     = readl_relaxed(base + GICR_ICFGR1);
+
+    /* Save GICD configuration */
+    gicv3_dist_wait_for_rwp();
+    gicv3_ctx.dist.ctlr = readl_relaxed(GICD + GICD_CTLR);
+
+    for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ )
+    {
+        nr_irqs = min(32U, gicv3_info.nr_lines - i * 32);
+        gicv3_store_spi_irq_block(gicv3_ctx.dist.irqs + i - 1, i, nr_irqs,
+                                  false);
+    }
+
+#ifdef CONFIG_GICV3_ESPI
+    for ( i = 0; i < gic_number_espis() / 32; i++ )
+        gicv3_store_spi_irq_block(gicv3_ctx.dist.espi_irqs + i, i, 32, true);
+#endif
+
+    return 0;
+
+ out_enable_iface:
+    if ( gicv3_enable_redist() )
+        panic("GICv3: Failed to re-enable redistributor after suspend abort\n");
+
+    gicv3_hyp_enable(true);
+    WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1);
+    isb();
+
+    return ret;
+}
+
+static void gicv3_resume(void)
+{
+    int ret;
+    unsigned int i, nr_irqs;
+    uint32_t dist_ctlr;
+    void __iomem *base;
+    struct redist_ctx *rdist = &gicv3_ctx.rdist;
+
+    dist_ctlr = gicv3_ctx.dist.ctlr & GICD_CTLR_ARE_NS;
+
+    /* Disable group forwarding while preserving affinity routing state. */
+    writel_relaxed(dist_ctlr, GICD + GICD_CTLR);
+    gicv3_dist_wait_for_rwp();
+
+    /*
+     * IHI0069H.b 12.9.9 says changing GICD_ICFGR<n>.Int_config
+     * while the interrupt is individually enabled is UNPREDICTABLE.
+     * Disable SPIs first; 4.7.1 defines GICD_ICENABLER<n>, n > 0,
+     * as the per-SPI disable mechanism.
+     */
+    for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ )
+        gicv3_disable_spi_irq_block(i, false);
+
+#ifdef CONFIG_GICV3_ESPI
+    for ( i = 0; i < gic_number_espis() / 32; i++ )
+        gicv3_disable_spi_irq_block(i, true);
+#endif
+
+    gicv3_dist_wait_for_rwp();
+
+    for ( i = NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i += 32 )
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * 4);
+
+    for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ )
+    {
+        nr_irqs = min(32U, gicv3_info.nr_lines - i * 32);
+        gicv3_restore_spi_irq_config(gicv3_ctx.dist.irqs + i - 1, i, nr_irqs,
+                                     false);
+    }
+
+#ifdef CONFIG_GICV3_ESPI
+    for ( i = 0; i < gic_number_espis() / 32; i++ )
+    {
+        writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + i * 4);
+        gicv3_restore_spi_irq_config(gicv3_ctx.dist.espi_irqs + i, i, 32,
+                                     true);
+    }
+#endif
+
+    if ( dist_ctlr )
+    {
+        for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ )
+        {
+            nr_irqs = min(32U, gicv3_info.nr_lines - i * 32);
+            gicv3_restore_spi_irq_routing(gicv3_ctx.dist.irqs + i - 1, i,
+                                          nr_irqs, false);
+        }
+
+#ifdef CONFIG_GICV3_ESPI
+        for ( i = 0; i < gic_number_espis() / 32; i++ )
+            gicv3_restore_spi_irq_routing(gicv3_ctx.dist.espi_irqs + i, i,
+                                          32, true);
+#endif
+    }
+
+    for ( i = 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ )
+        gicv3_restore_spi_irq_state(gicv3_ctx.dist.irqs + i - 1, i, false);
+
+#ifdef CONFIG_GICV3_ESPI
+    for ( i = 0; i < gic_number_espis() / 32; i++ )
+        gicv3_restore_spi_irq_state(gicv3_ctx.dist.espi_irqs + i, i, true);
+#endif
+
+    writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR);
+    gicv3_dist_wait_for_rwp();
+
+    ret = gicv3_lpi_init_rdist(GICD_RDIST_BASE);
+    /*
+     * If LPIs are already enabled, assume firmware or the still-powered
+     * redistributor has valid PROPBASER/PENDBASER and skip reprogramming.
+     * Return -EBUSY so callers can ignore this case.
+     */
+    if ( ret && ret != -ENODEV && ret != -EBUSY )
+        panic("GICv3: Failed to re-initialize LPIs during resume\n");
+    else if ( ret == -EBUSY ) /* extra checks, just to be sure */
+    {
+        base = GICD_RDIST_BASE;
+        if ( readq_relaxed(base + GICR_PROPBASER) != rdist->propbase ||
+             readq_relaxed(base + GICR_PENDBASER) != rdist->pendbase )
+            panic("GICv3: LPIs already enabled with unexpected PROPBASER/PENDBASER during resume\n");
+    }
+
+    /* Restore GICR (Redistributor) configuration */
+    if ( gicv3_enable_redist() )
+        panic("GICv3: Failed to re-enable redistributor during resume\n");
+
+    base = GICD_RDIST_SGI_BASE;
+
+    writel_relaxed(GENMASK(31, 0), base + GICR_ICENABLER0);
+    gicv3_redist_wait_for_rwp();
+
+    for ( i = 0; i < NR_GIC_LOCAL_IRQS / 4; i++ )
+        writel_relaxed(rdist->ipriorityr[i], base + GICR_IPRIORITYR0 + i * 4);
+
+    writel_relaxed(rdist->isactiver, base + GICR_ISACTIVER0);
+    writel_relaxed(rdist->igroupr,   base + GICR_IGROUPR0);
+    writel_relaxed(rdist->icfgr,     base + GICR_ICFGR1);
+
+    gicv3_redist_wait_for_rwp();
+
+    writel_relaxed(rdist->isenabler, base + GICR_ISENABLER0);
+    writel_relaxed(rdist->ctlr, GICD_RDIST_BASE + GICR_CTLR);
+
+    gicv3_redist_wait_for_rwp();
+
+    WRITE_SYSREG(gicv3_ctx.cpu.sre_el2, ICC_SRE_EL2);
+    isb();
+
+    /* Restore CPU interface (System registers) */
+    WRITE_SYSREG(gicv3_ctx.cpu.pmr,   ICC_PMR_EL1);
+    WRITE_SYSREG(gicv3_ctx.cpu.bpr,   ICC_BPR1_EL1);
+    WRITE_SYSREG(gicv3_ctx.cpu.ctlr,  ICC_CTLR_EL1);
+    WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1);
+    isb();
+
+    gicv3_hyp_init();
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 /* Set up the GIC */
 static int __init gicv3_init(void)
 {
@@ -2011,6 +2455,10 @@ static int __init gicv3_init(void)
 
     gicv3_hyp_init();
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+    gicv3_alloc_context();
+#endif
+
 out:
     spin_unlock(&gicv3.lock);
 
@@ -2050,6 +2498,10 @@ static const struct gic_hw_operations gicv3_ops = {
 #endif
     .iomem_deny_access   = gicv3_iomem_deny_access,
     .do_LPI              = gicv3_do_LPI,
+#ifdef CONFIG_SYSTEM_SUSPEND
+    .suspend             = gicv3_suspend,
+    .resume              = gicv3_resume,
+#endif
 };
 
 static int __init gicv3_dt_preinit(struct dt_device_node *node, const void *data)
diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h
index f3c11d871e..2261620316 100644
--- a/xen/arch/arm/include/asm/arm64/sysregs.h
+++ b/xen/arch/arm/include/asm/arm64/sysregs.h
@@ -16,6 +16,11 @@
 #define ICC_SRE_EL1               S3_0_C12_C12_5
 #define ICC_IGRPEN1_EL1           S3_0_C12_C12_7
 
+#define ICC_AP1R0_EL1             S3_0_C12_C9_0
+#define ICC_AP1R1_EL1             S3_0_C12_C9_1
+#define ICC_AP1R2_EL1             S3_0_C12_C9_2
+#define ICC_AP1R3_EL1             S3_0_C12_C9_3
+
 #define ICH_VSEIR_EL2             S3_4_C12_C9_4
 #define ICC_SRE_EL2               S3_4_C12_C9_5
 #define ICH_HCR_EL2               S3_4_C12_C11_0
diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/include/asm/gic_v3_defs.h
index 3714cfeb7d..f741587322 100644
--- a/xen/arch/arm/include/asm/gic_v3_defs.h
+++ b/xen/arch/arm/include/asm/gic_v3_defs.h
@@ -94,12 +94,15 @@
 #define GICD_TYPE_LPIS               (1U << 17)
 
 #define GICD_CTLR_RWP                (1UL << 31)
+#define GICD_CTLR_DS                 (1U << 6)
 #define GICD_CTLR_ARE_NS             (1U << 4)
 #define GICD_CTLR_ENABLE_G1A         (1U << 1)
 #define GICD_CTLR_ENABLE_G1          (1U << 0)
 #define GICD_IROUTER_SPI_MODE_ANY    (1UL << 31)
 
 #define GICC_CTLR_EL1_EOImode_drop   (1U << 1)
+#define ICC_CTLR_EL1_PRIBITS_SHIFT   8
+#define ICC_CTLR_EL1_PRIBITS_MASK    (0x7U << ICC_CTLR_EL1_PRIBITS_SHIFT)
 
 #define GICR_WAKER_ProcessorSleep    (1U << 1)
 #define GICR_WAKER_ChildrenAsleep    (1U << 2)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400676.1636243 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9Y-0004rw-FQ; Thu, 27 Aug 2026 14:32:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400676.1636243; Thu, 27 Aug 2026 14:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9Y-0004pr-B7; Thu, 27 Aug 2026 14:32:28 +0000
Received: by outflank-mailman (input) for mailman id 1400676;
 Thu, 27 Aug 2026 14:32:26 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9W-0004Xw-Gr
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9V-009cNd-Th
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:25 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a71-bab6-0a2a0a5309dd-0a2a4505841a-22
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:25 +0200
Received: from [52.101.83.137]
 (helo=GVXPR05CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a78-4cb1-0a2a45050019-34655389bf6c-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:25 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by GVXPR03MB10457.eurprd03.prod.outlook.com (2603:10a6:150:156::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:17 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=B0qJQLC5kH64Shf1cUH+loy+VcNLh+ENSvIMlXDT0cqQewjk7folOh1O95n1brQofFkgeAje/hL/zPjjh+Fri7g+qqJqWstr1AU/yXAnIaFCJDsfoBNnkYgnyUApGgzXgbYy8kl56pRCyrZD/Yvcnd+KLvWoulMhpzgMl0X6Z8wM5C4zEXQFptrXoxog1597ZAuAkglaVIZa24GPGeddwndDFshoyw2McMPU5JDD5MoMjQhewQAbg0+83SCJaz3wKjAQJPCTCFVfp6FU7JvhICIFGT7OMVKcA/lGJSAjRJXhO/dBcU/Ou5rG6TAaYkrOOJB8IRA5AmlkBBrK/FG1EA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=EettckwyIzU3fk0kj65Ks0GzBorqIrbtyNKzklvpFMA=;
 b=PKfLcVDs65nQGZtftWMxoUXr/b5gU2edUcolyfqZsVU2Z+yrhjvRAUA+7KwHbuVry2M0wjzjk+AydEpPMLEbKo1eQ7Q6GNTGjhSjutnvSIRRQdIilQSU26aGZ0IthGh/UJPqcJWlbWD/s3OFqYIzW/yU5AMO3c81tCUBDeJ7cpp1mnaIKvjWTucbyXmkywEi8/GCM7bvlWp9RRduF3UtSxvPtjHuzlmFW32zgUwX+BGbCechykGtFujxSQyPAopz3xEdflXl1tXWuoq6fopRRyUSNgsFmEBmHJb/2Ctar0+mvtL5e9E/XmQnywmvftU6thDmAbaWCzoarg6ORcDl1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=EettckwyIzU3fk0kj65Ks0GzBorqIrbtyNKzklvpFMA=;
 b=dopVucxC5lKvZGyFD8dao3IgvNs10gdgsA/twNY48TtfhUl4ltitApR5UJ42CUvUfgeMLPim6nwBYG6zU5D7hMKf6KJ6mFOAOKrE9ncwr/DZOG9vmSnLTxWolYr6D/na4k7lRCMh3McmXHj2B9dHkaW7OIP4ITypCrP58c8nYziPJDOFJ6HOdSm/zyZXLNSMyEgNSw0AUqIdpJvBGB56RlvFoOxiRIA1CrQwFawfXGX1XA5vpnKlKgoB4cfoaSowCuEMr8r5vy6j0c7MTiY1GUKmycUjSPQ7Avohyg7rYpGVx3/hJFjqp1iYU5w10lpc5e+i7DkI3tkZeHl7ekH35Q==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Julien Grall <jgrall@amazon.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 01/13] xen/arm: Add suspend and resume timer helpers
Date: Thu, 27 Aug 2026 17:31:49 +0300
Message-ID: <12bf671ae959fa2266cce3681855c658b117db99.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GVXPR03MB10457:EE_
X-MS-Office365-Filtering-Correlation-Id: 3aa413e7-6285-40ec-a6b8-08df0447feb8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|6133799003|3023799007|18002099003|22082099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	R2KezgcpjoUINpvfnDM1am5vYmjrGHTxqlpTFlMnzjhxkQM2bvc7YdiOigBuWon99ZQLwWn0M3L3ILJjgRQ+9XINC+JIi29NEgON5zvzvntvTmSrwbAE16t9IJckllnsxsmw5RTvbnzOUcLoic/4w4t99RnVuG/GdjNhALq1U0TsHlfw9PCV7J+8DeHYPLCl6V2ny8q18W9zT7LUevn6QL2ptvjBBOblQ+Mkt4l6LaH60a/QWoePQ9RdcJqQZxwmgy5mydp/mdZLrqoSRim+h+kaEohUva6AC8BOVq3BstP3EyOvvBfaK22z7xA2DcPGfNHEqBqrLBnms98iDub+svBCkccL1oWCIjFH2KkyWBL7vL75TIsmzOL0l7tUhcr/MzJOxD2VGg6PehceXPpl2xUU2HL6g2X7s5nvV9rsYuAP57PvMjcRA8BXlm5VULgNERmM4KHWkRHXH4op0Wr3KKue5gl7Up7fjgE1t6M4n7DfNLr6o5MyzLlmmt9QGJVUKThQmitJV8kqyc9YBe5T7tnCtc1ZEH8G2Un3iD2eu+FGTKE62CWm/0buZEstVNeWi0AYEX5JeH5Jumdlu3w2q4FaxUrOY6S4/Vu94CuRP0LQB3JcjqTtzOcLAg7KtFp/XV1lETnIpsIZ3srtDvNR2dwFBuYYup9JQPQC8r+xFyA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?il11xafZToRmJaotdqIrZVrLthrE/o917JydXxFElpZ/bXgTF+wj13+eppeq?=
 =?us-ascii?Q?TCfCcLSGkD92bxN7v6GDnAa/mXlQ556Age8yC6dKZ1l8/L/0U1s54qgmjOcS?=
 =?us-ascii?Q?2M6A3NJdiF4wxRHPAJ3notQLgiJfYJtj/ZFSekoUKyOBz70l3j94UvpSdmA3?=
 =?us-ascii?Q?WgRpujojVfHezrlohWi2gBgduWFjFfBRYQPtjGsaChG0AqxElV1NcQpZQwwE?=
 =?us-ascii?Q?6Y8TtGS5Jk5kuDwcYCkz+wwcAksBAqGtXVgXMxt83RaNWiuyJotoSColfNft?=
 =?us-ascii?Q?DZ+j8MQ1HOi1udtTt/JFdvgN7Y0yrVCR+j1BUjJkhyV+uOZp/8HcsykpzDIA?=
 =?us-ascii?Q?NZdxtobszL0hob+OTaV/4oLBGsnkScXFG1BomWYqfn0cuOGE7ZoaghIxIZTq?=
 =?us-ascii?Q?Toh2cFwM97YoxzsFt0H3iKcUJZQksxGVWiM3yKlLO2krXutBXoeeuuWAZjr7?=
 =?us-ascii?Q?nIoAggySZo9hkpwCIQC75Uyi99grGwuTkCFKqpGvOnae7JpFzB3wzIPxl8Nt?=
 =?us-ascii?Q?SA0XwTM881kpWDyuyN1T32Oy4F4nq4tPmLN25C3fTnbbM6G5YrfO3ulex0Dw?=
 =?us-ascii?Q?iOyUDojzln/YTG24UxLifiiPTi0vk3ZY6weqsoQtsp/OhNwDCdFBeZ2Xgfq7?=
 =?us-ascii?Q?Tn3Dpmf4ZZO7gnKnrajvLVmLcgqYeKAIcPtcahJnjvBGq/BGs8xa1hfAoJvO?=
 =?us-ascii?Q?sQE8PZx9g9QEI20y/ZMsVaTbtB0FPxbxTSYoulzTIYP8fcTPUKSnFIpHffr6?=
 =?us-ascii?Q?dDB+IdVLi7xutz2b6MFcbcCczNjuWzhIOM0/jdvp1mMtbaQ13CUaZtCfOL0B?=
 =?us-ascii?Q?/ZOmlwW3ukuqmzZhawfS0SKCz82BPT+4gOzm2Rm70E3cOoMBnp8YNL3pbKVC?=
 =?us-ascii?Q?wqV8w3zF0yLJ29Qcr1ElLMxcIVSTX+/yX4+tHOAWPbg/ojjiw0M9fOQSbjVv?=
 =?us-ascii?Q?T+qT+Q2nbc/RXIDzzgLLA8IP18k1YiOGUl5h8yaYHopIekD0PErfFL6JG3XH?=
 =?us-ascii?Q?1JjolKf6YT6g5T9stB+cWAWrMltHwiJRpLHmhLrabBichig3yBOQUA/cVQ41?=
 =?us-ascii?Q?EEqZVEy46kGOYH3fce14IYjAZ/WUagbsFGftV4kxBCNawDzxA7W2SwEZo5Yh?=
 =?us-ascii?Q?oEzck916MGYUFJYRwUvvBOPzLVFhJx5ehqaXIQ/F5AQE58QO3HFoNVSyZ2De?=
 =?us-ascii?Q?yKJaui7qG4YR7RvkQU5SK7CGDhaLgkMD+ri0UUW4amTNCj0vUUy9Id8K+Rxt?=
 =?us-ascii?Q?8C1e4ByZxxlIaKLUaoClRnN1j9s6BLdSsxsiLnGe5xOlehnJmE4mSEHXe7KQ?=
 =?us-ascii?Q?8MMnogkjFDPi4BmZNTyvhUPVjFRXE8dj/RuFGnGjBJADKmh3Zxh2dXOOvr2U?=
 =?us-ascii?Q?cxoH1UbLQjPCESSHKMiVPEUsvUjHjNh7VE3PnFDqRK+SL4hBOq2UcA6dCasQ?=
 =?us-ascii?Q?cyWVCUlP0Fdgg8IjASKMTNMpelT6RY3mwtKuqkZeeQjvLv6ySi5zhH2+g4Li?=
 =?us-ascii?Q?AoPMbc7jDBLMb8WRVkm3JFVGQMAWaiLpr83lWtHyvf10Csu9GUraocHJ2kBb?=
 =?us-ascii?Q?JbUWWZXixKqD0bxonHnVfiCXyFzDSq3HtJrFWVwACT+JCE2tysIpCMFgsbEw?=
 =?us-ascii?Q?11lLZQxmWEOsX5VURXXOsUsQmofo2Txg7Qld62HQEPxSg9KEJQnwTbuKWqXx?=
 =?us-ascii?Q?TclASfixOO7tMeCl6wvAnib6BlV4hNlJGnGLUZfJcOLmLKZ6uTTHviGz0N1f?=
 =?us-ascii?Q?WA907MTMBA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3aa413e7-6285-40ec-a6b8-08df0447feb8
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:17.3823
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: HEjYJmZX+sNApIZrfByAvcCK4lZgpgUtV3wOva6q+Fx33Pv5TZJGT0cDESe3JMKRV9HbNRFqWrBcXRP28Z7pAQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10457
X-purgate-ID: tlsNG-c201ff/1787841145-F6CB02A1-473AB062/0/0
X-purgate-type: clean
X-purgate-size: 5064

From: Mirela Simonovic <mirela.simonovic@aggios.com>

Timer interrupts must be disabled while the system is suspended to prevent
spurious wake-ups. Suspending timers in Xen consists of disabling the
physical timer and the hypervisor timer on the current CPU. The virtual
timer does not need explicit handling here, as it is already disabled on
vCPU context switch and its state is restored per-vCPU on the next context
restore.

Resuming consists of raising TIMER_SOFTIRQ, which prompts the generic
timer code to reprogram the hypervisor timer with the correct timeout.

Xen does not use or expose the physical timer, so it remains disabled
across suspend/resume.

Introduce a new helper, disable_phys_hyp_timers(), to encapsulate disabling
of the physical and hypervisor timers.

Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in V7:
  - Dropped EL1/EL2 wording; use "physical timer" and "hypervisor timer"
  - Renamed helper to disable_phys_hyp_timers() to reflect its actual scope
  - Clarified virtual timer handling (disabled on vCPU switch-out, restored
    on context restore) and added comments in suspend/resume paths
  - Added resume comment explaining which timers are restored by
    TIMER_SOFTIRQ
---
 xen/arch/arm/include/asm/time.h |  5 ++++
 xen/arch/arm/time.c             | 44 ++++++++++++++++++++++++++++-----
 2 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h
index c194dbb9f5..9313b157ea 100644
--- a/xen/arch/arm/include/asm/time.h
+++ b/xen/arch/arm/include/asm/time.h
@@ -105,6 +105,11 @@ void preinit_xen_time(void);
 
 void force_update_vcpu_system_time(struct vcpu *v);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+void time_suspend(void);
+void time_resume(void);
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 #endif /* __ARM_TIME_H__ */
 /*
  * Local variables:
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index be54b87438..680535a2ca 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -298,6 +298,14 @@ static void check_timer_irq_cfg(unsigned int irq, const char *which)
 static DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_hyp);
 static DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, irq_virt);
 
+/* Disable physical and hypervisor timers on the current CPU */
+static inline void disable_phys_hyp_timers(void)
+{
+    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Physical timer disabled */
+    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
+    isb();
+}
+
 /* Set up the timer interrupt on this CPU */
 void init_timer_interrupt(void)
 {
@@ -308,9 +316,7 @@ void init_timer_interrupt(void)
     WRITE_SYSREG64(0, CNTVOFF_EL2);     /* No VM-specific offset */
     /* Do not let the VMs program the physical timer, only read the physical counter */
     WRITE_SYSREG(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2);
-    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Physical timer disabled */
-    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Hypervisor's timer disabled */
-    isb();
+    disable_phys_hyp_timers();
 
     hyp_action->name = "hyptimer";
     hyp_action->handler = htimer_interrupt;
@@ -335,9 +341,7 @@ void init_timer_interrupt(void)
  */
 static void deinit_timer_interrupt(void)
 {
-    WRITE_SYSREG(0, CNTP_CTL_EL0);    /* Disable physical timer */
-    WRITE_SYSREG(0, CNTHP_CTL_EL2);   /* Disable hypervisor's timer */
-    isb();
+    disable_phys_hyp_timers();
 
     release_irq(timer_irq[TIMER_HYP_PPI], NULL);
     release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
@@ -377,6 +381,34 @@ void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds)
     /* XXX update guest visible wallclock time */
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+void time_suspend(void)
+{
+    /* CNTV already disabled by virt_timer_save() during vcpu context switch. */
+    disable_phys_hyp_timers();
+}
+
+void time_resume(void)
+{
+    /*
+     * Raising TIMER_SOFTIRQ triggers generic timer code to reprogram the
+     * hypervisor timer with the correct timeout (not known here).
+     *
+     * Xen doesn't use or expose the physical timer, so it remains disabled
+     * across suspend/resume.
+     *
+     * The virtual timer state is restored per-vCPU on the next context switch.
+     *
+     * No further action is needed to restore timekeeping after power down,
+     * since the system counter is unaffected. See ARM DDI 0487 L.a, D12.1.2
+     * "The system counter must be implemented in an always-on power domain."
+     */
+    raise_softirq(TIMER_SOFTIRQ);
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static int cpu_time_callback(struct notifier_block *nfb,
                              unsigned long action,
                              void *hcpu)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400674.1636233 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9X-0004kd-VW; Thu, 27 Aug 2026 14:32:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400674.1636233; Thu, 27 Aug 2026 14:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9X-0004kU-Qz; Thu, 27 Aug 2026 14:32:27 +0000
Received: by outflank-mailman (input) for mailman id 1400674;
 Thu, 27 Aug 2026 14:32:25 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9V-0004Xj-O0
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9U-000Qzn-Nl
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:24 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a65-e002-0a2a0a5209dd-0a2a4504a44e-36
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:24 +0200
Received: from [52.101.66.83]
 (helo=DUZPR83CU001.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a78-b57f-0a2a45040019-34654253f636-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:24 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:20 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:20 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iYxQHlnJyjKKzdnSVq67W1dwMPg2h0rJxjh7tyeKrDQ3g1DPjJHoj7hR+FHj4HN7UCZuKHTDVidPbbzSizzj1Krk15V8XBWWCb2dWalKBe0on1kIaI92/PcmonR9a0+xWqy1YKC23jV/+H4Pa1/4juX68Gq6OxEnSxpZDaXG26EpxhtpijbK5A0NAthfDF3KKFtrdXgSpgwUrMFJVMDcW+dQ5T7UeEuVPTS8tB6egfk6NbtGPgLgD/23uvuQRAE+ExoOTCbhyHX7yggIn3lCfIF/tybyknSG5epH73wz+KHTRJXJBKQW6Gau50H9LbBGoYxpdXtIzH4dlKMEqPkctQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jO7EUGeyoQEGGunXwzy8J/17wNQG1UNxL9yQPMYMpUM=;
 b=FECQXFU5DcD27dGpjREAaUfIkK+S/GhaC9AcOh5+sTvb/dhWsLMx36SlEeBM9ii7aBiDehkX/SGsjvzG63LOd/NF4vWniU7lxGFScRZNN2uAE3cVcnfx/8+KzWkpxTRUap2dcqSYsVPp+kRQNZF222IA8PqcK/CUcIwPL+dJK0ZJPLX/y1IG9Ff2zZol2ZMam3oe4ZLWg0OjfE5O5RDXYnNNYzhWDZtup4YT3E5GVvrIstK+StEvS2u4w7ZLO9kxFC11CRtrO6Fen0wxedCxePOJcezDY9xIvT+iWjRoMLlhk0FkpJF5J2DYYhCcCKeeHIw6TdtSc1bWL6wSWgy30w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jO7EUGeyoQEGGunXwzy8J/17wNQG1UNxL9yQPMYMpUM=;
 b=Dg1NGSTQKu7nn8YMgjzm/m0+VnKVg2ON2TfcCEc7BySrm/E7M2mN36KEWQdu/ltBG+ohrnhgJbR+yCOhJtqGlmIYqdwd09QO8VelCEyQLPguX/utnRbF6y4JpC/srA6jVv/rw0NYMrD8X7Fyx9kGsB/U5AEyskUukNoL5tYmwPZk1Ibioi6LjUAol8GSxRL3G2QuSAgNVyV6fjI4bzS1c49BpU3+dGwB3CxhhqZe3E8eIqYT0bkn8vw++kIZm9yE810vYPhGuYJWH80pnFHvuvEiup6H6SGjlz716tV8wfhG6ABwCKgu42FapUJSMzkgMEfCBJX5y4hslchjplb7Fw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions
Date: Thu, 27 Aug 2026 17:31:50 +0300
Message-ID: <dbdba04cd531cf2f3ccfc0b7e8dbcb4925b25055.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: c123b811-6289-4549-c1f4-08df04480071
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|20046099003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	EmrXMXhfj4/P4YvmOLEYQWu5greyJ5ehdEhsdGDAP4xwkBOg+PxAtj2KMhyGTxHspKkffc7Pszamzu6otGAnWneT7Ha+SA08y9taGjzUV/puWvxG8cZoHlNG/McywrXqD4DsS6qhPh+vqxSpyZV6+xhIh55GiMIdl6z0/H4aRnFfWr9GN9xvCAzhHwuVL5MTPToafN8pN+eRaGzPfIxqb8HWggae3dz5uNszQ2FQVkK0FH16ZafI4dIsZ/RjrN+FhmgcYaMTMp+Bga+2MRxtRwQ4aHl1AdMJabqVQO++b9cShi9GVynpfzlvgr7Ve96XjRb0HsYXBprC22zY8oBMV9GDWw4qPKbEAz2wdKgZvh6jJXqZvKOT3FW04AKqNb0lJPWA0b9lVI+ZTnBC3f/z/f0JRnQM8B66qhWVJD5P0qWalji1A0AIX+GdFLuhMZb81VXThxZsJVwanS1mTkWx771CsMU2k3m8VyWhi0UysY4QPZvtah3e3vku5+0IbfOOaXaEZ7D8BnLhR7n7iIcd4U1MpTtjNlaNFpVnDvRbg2xXGyT755oIhAzLvKr01V8hBE7tbBltlMHLZcSPmNzOOo1Mx6JoG91TFIH/VVMm8VIjDkWPOs85qcUC8My3qK1VtKBsELbVxJBMKn+lCXp6Z7/Wmso2ZsCFOcW8Da9PjKg=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(20046099003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?uNrEU7rER3V4KaWm21YaeHq9bkIdZfihcn1R7uE4anS3a2W3Ts08O1jomVd+?=
 =?us-ascii?Q?FlJALKLpnY4lkd2ESwGspBRQePOo487H1MBgey8BloDtDc4kA4Qi1EMCa2+1?=
 =?us-ascii?Q?gu5aSIAPhTy4o4T4zbPUyqApZ0z6GZcLY15XBR+pwkBSJJrUfsB92gZFyS7V?=
 =?us-ascii?Q?KM526Y1L3TwjvKPgkDtNgbF4jA0ytXf+aCn2dOcvrxWYDSSowJXlo6hvvkZs?=
 =?us-ascii?Q?a1ulH4+ZO4LVSqUxwleF+/kepmhAPrcDElcqJ+SSjiiemBHgooA+PPaBqdaj?=
 =?us-ascii?Q?yEzruv4ROmaoDgS8vQZpWkxwtik3pqfy7g1Pccrlg/MZUR5TFmkss+AepZwr?=
 =?us-ascii?Q?v+isupxu6rzhcS0CWGxnAbhxQrtp2CFaX4JDNeR3WkE0wE+Bb5oJhmrbDd2E?=
 =?us-ascii?Q?EYgIt2vyUKqYsDbwBCoVBz66f8Cc9kAR1p8wNvZ7cNI1Vuf5UglGfWrCXDlf?=
 =?us-ascii?Q?DzjMNfy0rSh8SDvzz+EPW/eI1s80+cXd8kcXkN8Nx6lY5YsC74UmnEzRYj9d?=
 =?us-ascii?Q?7woBHsA29FvtLeTHuC8qsHsC6XEndm0smJxI/hZprN3A7H9Z/LPSesF4eRpS?=
 =?us-ascii?Q?T/L2GAyNSv/Ap17fmg9fhsyQ1iJguQxvZA94wtC7ha+4kxLLTQ+MD/zzbnNq?=
 =?us-ascii?Q?ZmOKh0ON0J3FKPENCnzzJvYgkjCPpQo1s6ZdQh0DavBPH3OfgigCQa3MSlqF?=
 =?us-ascii?Q?z7NPtv70mH5OUy/s6m2cHENWp4milrU1/hJdjIygoyvaM7amdkvOeHH2recj?=
 =?us-ascii?Q?XaieRTkMjF3WlSGL3cWz6lyHngfPyPWNWxKraFEy0yf015sw74J0VVBrBf/k?=
 =?us-ascii?Q?z7sEE8UH5KXVbxByPCastSUOkBGMafharWH0cVrlzxA4fJCw7xdpDgIaFp50?=
 =?us-ascii?Q?q81ec+3GQnyFq1IjfgynCZr2+E0pln2eivcv1+PGSrLutlj/7vNEa7rKODCY?=
 =?us-ascii?Q?drvbl8odirOdBlqZPUgpcuXavNeJyxcNt42YhWw9x7WET8iQx1pNsk8eZpzR?=
 =?us-ascii?Q?kkGlvgPdiQc97iY6qJncpqu9DbmJoki5z2QNCcMkFYfiXeo8O6fA+i/LIqdp?=
 =?us-ascii?Q?SH68SM/nl0/zed8JkUlLml+BQE6JaMVZONe4txjF42m47yY0G3J8afSZT/Kr?=
 =?us-ascii?Q?gy58fG/07+XdoiceT3JlPgrkVGFyRhdJ6tSwVRAPPqTi2Ada9HOr0jY35wEd?=
 =?us-ascii?Q?rzY8sxRVLHErhZmrbSiRIUAPFmevAjygxtd9upy+vHfnwwv5Z9p2lYYk+P2b?=
 =?us-ascii?Q?wCAVqW0UGd1aEJjSqlDwIx8ZRHFfTqeueEG9r8/JhT0D3jz+4n7SJdhy5Fk1?=
 =?us-ascii?Q?HjBRIKF8scWUJ4yunZjY/f7pKXRzX3giJBwU2HohhUj2ytlUgBaejGahkmTp?=
 =?us-ascii?Q?KLSAMr29kyGjZjs6v18RaEljN5ahFBp+/Pzpia6uUdyGyiNjy9rK6VXjeDwQ?=
 =?us-ascii?Q?bneaKIFmZMERr9kshv3mm6WXiA3YJ0HtR9vYevz9RYjvMim+ybaV1fu+t1Lb?=
 =?us-ascii?Q?pE6AQanwwojZ4955C5wPHRrFRzzXhDEn8OPRKkYUt2JE/c6bg7GCwfQwIjg7?=
 =?us-ascii?Q?DwvE0GPuxT5eJPqtp2fgP4XmgZRnC0S+mk0AQCCmWtDw5oZKopUMo/AoxV8O?=
 =?us-ascii?Q?EovrLb56e5A666bqp2FNoRexA67npqyhGyLXQC+d61yeAgeyCsRejkm889R1?=
 =?us-ascii?Q?nl6g6nVXbDmVG7IjmrpqJiSQ/BRxg5mHCNhdpJtDLAhF5PGsO12zZFwemCeY?=
 =?us-ascii?Q?bKct9cBY6g=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c123b811-6289-4549-c1f4-08df04480071
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:20.2975
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: EhfOi/q1aHvvO1+baLhxV7V9yeiPN3594GCFsUarsFPUDtoZBtOz+lnKEhZujEwM4bHO2ETLmAmt4/b3ywyIkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-ebf023/1787841144-C20D5B50-D8DA8AA3/0/0
X-purgate-type: clean
X-purgate-size: 13573

From: Mirela Simonovic <mirela.simonovic@aggios.com>

System suspend may lead to a state where GIC would be powered down.
Therefore, Xen should save/restore the context of GIC on suspend/resume.

Note that the context consists of states of registers which are
controlled by the hypervisor. Other GIC registers which are accessible
by guests are saved/restored on context switch.

Transient physical SGI pending state (GICD_CPENDSGIRn/GICD_SPENDSGIRn)
is intentionally excluded. CPU-interface active-priority state is also
not restored across suspend/resume. Xen reaches the final suspend path
at a quiescent point, so there is no active-priority execution context
to replay after resume. Enforce this with a runtime check after
disabling the CPU interface: if any implemented GICC_APRn word is still
non-zero, restore GICC_CTLR and abort suspend with -EBUSY.

This does not apply to distributor active state. With GICv2 EOImode==1,
EOIR only drops the interrupt priority; final deactivation is a separate
step. For guest-routed interrupts, Xen can have already EOIed the physical
IRQ while deactivation is still pending on the vGIC/GICV path. Therefore
GICD_ISACTIVER is preserved as architectural in-flight interrupt state.

Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in V10:
- Limit GICC_APR<n> active-priority checks to APR bits visible from
  the Xen CPU-interface view.
- Avoid touching reserved GICD_IPRIORITYR/GICD_ITARGETSR words when the
  last implemented interrupt block is partial.
- Restore distributor configuration before restoring interrupt enable
  state, so GICD_ICFGR is written while the corresponding interrupts are
  disabled.

Changes in V9:
- Skip saving/restoring GICD_ITARGETSR0..7 because SGI/PPI target
  registers hold no state (read-only on MP, RAZ/WI on UP).
- Add a runtime GICC_APRn quiescence check after disabling the CPU
  interface, and restore GICC_CTLR before returning -EBUSY.

Changes in V8:
- disable cpu interface + distributor before suspend
- change 0xffffffff to GENMASK;
- cosmetic changes;

Changes in V7:
- Allocate one contiguous memory block for the GICv2 dist suspend context.
- gicv2_resume() no longer unconditionally re-enables the distributor/CPU
  interface; it now writes back the saved CTLR values as-is.
- gicv2_alloc_context() now returns 0 on success and panics on failure,
  since suspend context allocation is not recoverable.
---
 xen/arch/arm/gic-v2.c          | 226 +++++++++++++++++++++++++++++++++
 xen/arch/arm/gic.c             |  29 +++++
 xen/arch/arm/include/asm/gic.h |  12 ++
 3 files changed, 267 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 43a379fdda..a0ef6ffc7f 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1108,6 +1108,223 @@ static int gicv2_iomem_deny_access(struct domain *d)
     return iomem_deny_access(d, mfn, mfn + nr - 1);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+/* This struct represents block of 32 IRQs */
+struct irq_block {
+    uint32_t icfgr[2]; /* 2 registers of 16 IRQs each */
+    uint32_t ipriorityr[8];
+    uint32_t isenabler;
+    uint32_t isactiver;
+    uint32_t itargetsr[8];
+};
+
+/* GICv2 registers to be saved/restored on system suspend/resume */
+struct gicv2_context {
+    /* GICC context */
+    struct cpu_ctx {
+        uint32_t ctlr;
+        uint32_t pmr;
+        uint32_t bpr;
+    } cpu;
+
+    /* GICD context */
+    struct dist_ctx {
+        uint32_t ctlr;
+        /* Includes banked SGI/PPI state for the boot CPU. */
+        struct irq_block *irqs;
+    } dist;
+};
+
+static struct gicv2_context gic_ctx;
+
+#define GICV2_NR_APRS          4
+#define GICV2_APR_BITS_PER_REG 32U
+
+static int gicv2_check_active_priorities(uint32_t bpr)
+{
+    unsigned int i, apr_bits, nr_aprs;
+
+    /*
+     * Xen writes GICC_BPR to 0 during CPU init and does not change it. Per
+     * IHI0048B.b, a write below the implementation minimum reads back as the
+     * minimum supported BPR value. Table 4-47 maps that Xen-visible BPR value
+     * to the visible GICC_APR<n> bits. Avoid reading APR registers outside
+     * that visible range.
+     *
+     * This covers both GICv2 with and without Security Extensions.
+     */
+    apr_bits = 1U << (7 - (bpr & 0x7));
+    nr_aprs = DIV_ROUND_UP(apr_bits, GICV2_APR_BITS_PER_REG);
+
+    ASSERT(nr_aprs <= GICV2_NR_APRS);
+
+    for ( i = 0; i < nr_aprs; i++ )
+    {
+        unsigned int bits = min(GICV2_APR_BITS_PER_REG,
+                                apr_bits - i * GICV2_APR_BITS_PER_REG);
+        uint32_t mask = GENMASK(bits - 1, 0);
+        uint32_t apr = readl_gicc(GICC_APR + i * 4) & mask;
+
+        if ( !apr )
+            continue;
+
+        printk(XENLOG_ERR "GICv2: suspend aborted: GICC_APR%u=%#08x\n",
+               i, apr);
+        return -EBUSY;
+    }
+
+    return 0;
+}
+
+static int gicv2_suspend(void)
+{
+    unsigned int i, blocks = DIV_ROUND_UP(gicv2_info.nr_lines, 32);
+    int ret;
+
+    /* Save GICC_CTLR configuration. */
+    gic_ctx.cpu.ctlr = readl_gicc(GICC_CTLR);
+
+    /* Quiesce the GIC CPU interface before suspend. */
+    gicv2_cpu_disable();
+
+    gic_ctx.cpu.bpr = readl_gicc(GICC_BPR);
+
+    /*
+     * Check the active-priority state for the group Xen drives through the
+     * CPU interface. GICC_CTL_ENABLE enables Group 0 without SecurityExtn and
+     * Group 1 in Xen's Non-secure view with SecurityExtn, and in both cases
+     * the relevant state is visible through GICC_APRn. The APR layout is
+     * implementation-defined, so only test the bits visible from Xen's CPU
+     * interface view instead of reading every possible APR register.
+     */
+    ret = gicv2_check_active_priorities(gic_ctx.cpu.bpr);
+    if ( ret )
+    {
+        writel_gicc(gic_ctx.cpu.ctlr, GICC_CTLR);
+        return ret;
+    }
+
+    gic_ctx.cpu.pmr = readl_gicc(GICC_PMR);
+
+    /* Save GICD configuration */
+    gic_ctx.dist.ctlr = readl_gicd(GICD_CTLR);
+    writel_gicd(0, GICD_CTLR);
+
+    for ( i = 0; i < blocks; i++ )
+    {
+        struct irq_block *irqs = gic_ctx.dist.irqs + i;
+        size_t j, off = i * sizeof(irqs->isenabler);
+        size_t nr_regs = ARRAY_SIZE(irqs->ipriorityr);
+
+        if ( i == blocks - 1 )
+            nr_regs = DIV_ROUND_UP(gicv2_info.nr_lines - i * 32, 4);
+
+        irqs->isenabler = readl_gicd(GICD_ISENABLER + off);
+
+        /*
+         * Save distributor active state as part of the hypervisor-owned
+         * physical interrupt state. In GICv2 EOImode==1, EOIR only drops the
+         * priority; final deactivation is separate. For guest-routed
+         * interrupts, Xen may have EOIed the physical IRQ while the guest/vGIC
+         * side still owns the deactivate step. Therefore GICD_ISACTIVER can
+         * legitimately remain set even though transient SGI pending state and
+         * CPU-interface active-priority state are expected to be quiesced here.
+         */
+        irqs->isactiver = readl_gicd(GICD_ISACTIVER + off);
+
+        off = i * sizeof(irqs->ipriorityr);
+        for ( j = 0; j < nr_regs; j++ )
+            irqs->ipriorityr[j] = readl_gicd(GICD_IPRIORITYR + off + j * 4);
+
+        /*
+         * GICD_ITARGETSR0..7 cover SGIs/PPIs and hold no state to save:
+         * they are read-only on multiprocessor implementations and RAZ/WI
+         * on uniprocessor implementations.
+         */
+        if ( i )
+        {
+            off = i * sizeof(irqs->itargetsr);
+            for ( j = 0; j < nr_regs; j++ )
+                irqs->itargetsr[j] = readl_gicd(GICD_ITARGETSR + off + j * 4);
+        }
+
+        off = i * sizeof(irqs->icfgr);
+        for ( j = 0; j < ARRAY_SIZE(irqs->icfgr); j++ )
+            irqs->icfgr[j] = readl_gicd(GICD_ICFGR + off + j * 4);
+    }
+
+    return 0;
+}
+
+static void gicv2_resume(void)
+{
+    unsigned int i, blocks = DIV_ROUND_UP(gicv2_info.nr_lines, 32);
+
+    gicv2_cpu_disable();
+    /* Disable distributor */
+    writel_gicd(0, GICD_CTLR);
+
+    for ( i = 0; i < blocks; i++ )
+    {
+        struct irq_block *irqs = gic_ctx.dist.irqs + i;
+        size_t j, off = i * sizeof(irqs->isenabler);
+        size_t nr_regs = ARRAY_SIZE(irqs->ipriorityr);
+
+        if ( i == blocks - 1 )
+            nr_regs = DIV_ROUND_UP(gicv2_info.nr_lines - i * 32, 4);
+
+        writel_gicd(GENMASK(31, 0), GICD_ICENABLER + off);
+
+        off = i * sizeof(irqs->icfgr);
+        for ( j = 0; j < ARRAY_SIZE(irqs->icfgr); j++ )
+            writel_gicd(irqs->icfgr[j], GICD_ICFGR + off + j * 4);
+
+        off = i * sizeof(irqs->ipriorityr);
+        for ( j = 0; j < nr_regs; j++ )
+            writel_gicd(irqs->ipriorityr[j], GICD_IPRIORITYR + off + j * 4);
+
+        /*
+         * GICD_ITARGETSR0..7 cover SGIs/PPIs and hold no state to save:
+         * they are read-only on multiprocessor implementations and RAZ/WI
+         * on uniprocessor implementations.
+         */
+        if ( i )
+        {
+            off = i * sizeof(irqs->itargetsr);
+            for ( j = 0; j < nr_regs; j++ )
+                writel_gicd(irqs->itargetsr[j], GICD_ITARGETSR + off + j * 4);
+        }
+
+        off = i * sizeof(irqs->isenabler);
+        writel_gicd(irqs->isenabler, GICD_ISENABLER + off);
+
+        writel_gicd(GENMASK(31, 0), GICD_ICACTIVER + off);
+        writel_gicd(irqs->isactiver, GICD_ISACTIVER + off);
+    }
+
+    /* Restore distributor control state. */
+    writel_gicd(gic_ctx.dist.ctlr, GICD_CTLR);
+
+    /* Restore GIC CPU interface configuration */
+    writel_gicc(gic_ctx.cpu.pmr, GICC_PMR);
+    writel_gicc(gic_ctx.cpu.bpr, GICC_BPR);
+
+    /* Enable GIC CPU interface */
+    writel_gicc(gic_ctx.cpu.ctlr, GICC_CTLR);
+}
+
+static void __init gicv2_alloc_context(void)
+{
+    uint32_t blocks = DIV_ROUND_UP(gicv2_info.nr_lines, 32);
+
+    gic_ctx.dist.irqs = xzalloc_array(struct irq_block, blocks);
+    if ( !gic_ctx.dist.irqs )
+        panic("Failed to allocate memory for GICv2 suspend context\n");
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 #ifdef CONFIG_ACPI
 static unsigned long gicv2_get_hwdom_extra_madt_size(const struct domain *d)
 {
@@ -1312,6 +1529,11 @@ static int __init gicv2_init(void)
 
     spin_unlock(&gicv2.lock);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+    /* Allocate memory to be used for saving GIC context during the suspend */
+    gicv2_alloc_context();
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
     return 0;
 }
 
@@ -1355,6 +1577,10 @@ static const struct gic_hw_operations gicv2_ops = {
     .map_hwdom_extra_mappings = gicv2_map_hwdom_extra_mappings,
     .iomem_deny_access   = gicv2_iomem_deny_access,
     .do_LPI              = gicv2_do_LPI,
+#ifdef CONFIG_SYSTEM_SUSPEND
+    .suspend             = gicv2_suspend,
+    .resume              = gicv2_resume,
+#endif /* CONFIG_SYSTEM_SUSPEND */
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 078049e741..ffc11f36a1 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -438,6 +438,35 @@ int gic_iomem_deny_access(struct domain *d)
     return gic_hw_ops->iomem_deny_access(d);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+int gic_suspend(void)
+{
+    /* Must be called by boot CPU#0 with interrupts disabled */
+    ASSERT(!local_irq_is_enabled());
+    ASSERT(!smp_processor_id());
+
+    if ( !gic_hw_ops->suspend || !gic_hw_ops->resume )
+        return -ENOSYS;
+
+    return gic_hw_ops->suspend();
+}
+
+void gic_resume(void)
+{
+    /*
+     * Must be called by boot CPU#0 with interrupts disabled after gic_suspend
+     * has returned successfully.
+     */
+    ASSERT(!local_irq_is_enabled());
+    ASSERT(!smp_processor_id());
+    ASSERT(gic_hw_ops->resume);
+
+    gic_hw_ops->resume();
+}
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static int cpu_gic_callback(struct notifier_block *nfb,
                             unsigned long action,
                             void *hcpu)
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h
index ee2c26adb4..29bb9a89a4 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -301,6 +301,12 @@ extern int gicv_setup(struct domain *d);
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(struct vcpu *v);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+/* Suspend/resume */
+extern int gic_suspend(void);
+extern void gic_resume(void);
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 /* SGI (AKA IPIs) */
 enum gic_sgi {
     GIC_SGI_EVENT_CHECK,
@@ -444,6 +450,12 @@ struct gic_hw_operations {
     int (*iomem_deny_access)(struct domain *d);
     /* Handle LPIs, which require special handling */
     void (*do_LPI)(unsigned int lpi);
+#ifdef CONFIG_SYSTEM_SUSPEND
+    /* Save GIC configuration due to the system suspend */
+    int (*suspend)(void);
+    /* Restore GIC configuration due to the system resume */
+    void (*resume)(void);
+#endif /* CONFIG_SYSTEM_SUSPEND */
 };
 
 extern const struct gic_hw_operations *gic_hw_ops;
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400679.1636274 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9b-0005hG-R0; Thu, 27 Aug 2026 14:32:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400679.1636274; Thu, 27 Aug 2026 14:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9b-0005g4-N4; Thu, 27 Aug 2026 14:32:31 +0000
Received: by outflank-mailman (input) for mailman id 1400679;
 Thu, 27 Aug 2026 14:32:30 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9a-0005YV-Fj
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9Z-00Bhds-SO
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:29 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a76-2eae-0a2a0a5409dd-0a2a450a9b26-24
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:29 +0200
Received: from [52.101.70.104]
 (helo=AS8PR04CU009.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a7d-f2d2-0a2a450a0019-34654668eba3-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:29 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:28 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QyO7YBXf/CCLnB4/bAL3/np3ta4q4f42hpaL7eOPNtohc4aATut9taoWd1Eh/H8hekQhtxqhExpWH/HVP4w88E1ob8HhiqPUUNKbumrrB7kTNIewrDM+r4d/JsE2g6UpPFEIIOZbuqh1HpT7tCR7RirHPwKFNmo/yN9GdnfSd5Z3k4Xc663/ZN2a7nElSbcWwSeJVrWdZQnajFIkfO+8GIfHqeEOjxkYySiEJY6i75kHmljsG+BZsF5Z3sSCJQMWwOCHEXucu1rHHUBHcR8j4VFrPXV1tX1M+0J3J5mDf/sv2Bt9LlBrKp/vNIeRentkyVoAp50QOLoNsRKqRJbyeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RRVpxeM0gaRhUjO9d6z4tc/MJuoIRCJQUNdQDfFlEeE=;
 b=VARt32hi3xGVmuyyUU5x3u/RsUw7+pghpFU44XsOunP/yrTVlXCT+iJiRAKKNy1RKVGiqNYAu/+tKIZUXZifDIi0V897aOsa6AsbcCm3ncDiAoap4kRey+UltKjvdzmBkT7iIasvPQOyLIO7jE+8xrglEOGzcro+efZVsndVagolYE4C9bWFXmh/jFQJ7lswStYjI/mxv+Bi1DEo3m5pU23UaabmUsGoQKzLC9I5ybTIQY8OgIH+xKeo9TiyNUiD60Hs/H+w17IkoxgxRl4eehmO8SO61a6E9vT4XGglrxrU8uyFbL+jCxhuwJ4+GtCKh5i6ixOBRs7W0dbqrr7slg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=RRVpxeM0gaRhUjO9d6z4tc/MJuoIRCJQUNdQDfFlEeE=;
 b=uHpcEn935f7ZYnv/Te7agOeRpdO+oxjkDHZJzFHNTD8lLUICFu7sWgutQArn0ExR2PV1/Rp0wzcDBqjQ4GbZh+hgucy4+9Tv56Pu6iAUmlqYEwNFMFo+vijglJJmHjifsumcipVGEfwQBeatEi8eguEhXm3EN0CWrak6v6Wz6NybKvl4upF/EjqhX1ia+uLVcnAn40nCcMbWRgCM5f8XpfVPrlMVapNC7IxjTQPknxzVgrMPOLc2ARCMBs8/USZVaREcHGSUJk1Ui5+cMI/g2XJbzNCresbPkv1kqvyeL0qzLe03lyjrrq2sWv9sJ/xbLRdeQbhOLDG0UfYR4YjMRQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Jens Wiklander <jenswi@kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 06/13] xen/arm: tee: keep init_tee_secondary() for hotplug and resume
Date: Thu, 27 Aug 2026 17:31:54 +0300
Message-ID: <623be9a0a5603073f25d009979ab49b611e7dddc.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 20ff1a46-1f41-46da-6b64-08df04480543
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	D5cQCBHHoVMToy8zwI4ulCHMSEYvtc9+Eea/ui+1R2/EXREk+380EhvJEqY+g+Ci/Qp4bzDIfq6DUQbYbqpifUVD3HnLdPJf2ZuG7gKBjgdInHv6tKRziI2oanyxKRG7mECOCMh9Y9Uaf+a3MNXKWV23E6FXLhDljZGuW3KYmzY4ewFBZvISfDik6WLBM5pDzflbJT6EUahieIYY2Fh81EEbK5AG5KopDugiKpryjydmCDdrN42TBheEhYhobe5wsmlF4jiOLXRFJO874ZNVTlGICN8ZPyzNZ1TTUavs183glTcvMCCWzPHABOQeiPI/kTKUJVfKP6ejdpDUx5MGm2a9eGZYh2wZgBRzVCnOCfwqNbHkxa6P40ABBqNZ2SJ3jU1F/Cja54LAqfEm+zwPJ4eRirYnYKAbXR/AXI/wvymGjlqXuvBPHEG3vNAl9U7DKKbsAi4bKAWT7bKvempk/mAxwQHEIJZYhg4yCw7cQ82E555a4nzJc56vPJh/K6xCDXX0htXSmzBw9RgJ9kDdFLRzcLW3fpqX+WvzkLN+JncP3zWiM4YjfnQKB9bYA1J4HYOMHkUlrr0NM4CqdabNmrOolxHpEUEqFUecp8Rc5wnjFDzp4FcO2urTUsfaopdI/Sm4aBvCXwVyjeYDXpFq1ZqnrPjV4VRB03ZzPeOO9eM=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?IKgKNA/cuMOeSX82C8B2ONGfykqmLJIQ/HQxpHQgTEdWiDN8z6aaG6SP9Bdl?=
 =?us-ascii?Q?a77sf6zgy0O6VR5zEmnr3jzE3LZEJ/yu+Nqj/Ile8nR7Q+BVDXAudGDwvClf?=
 =?us-ascii?Q?QFsVnrWliZ0nMn2KMvixRs2n4rpMVtHxEXhoIFty4dnh8+jSEjX1Nha2Jt0y?=
 =?us-ascii?Q?0urE3b6Iv62f8LxXELfgEDjR8aOha7ggeFe10y0+q1tR+LhFjFglZ1O1WZMp?=
 =?us-ascii?Q?FiOoROXDZF4THYgJZ3L/443gIdmPjAgNPRvZ1RqzAsd3/7i7PlCSJk8W1UzV?=
 =?us-ascii?Q?9O+RFA8mRA8SFlvwYlcNL2lvUn+xJDbzYWxOf5b5Bby52PhiPH0VijmtmyaJ?=
 =?us-ascii?Q?h1012ZZuNdgZosPiUcMp5FBEMvHx9MfBha/vlQiMOgJeCpNvJx5E1qeFvczt?=
 =?us-ascii?Q?MG19COlF9jx8qDKSQBrEgAs3YU6EkwXkaRs55FUKkxP6zfpLX+kz3XuOoX02?=
 =?us-ascii?Q?JDHutVF2C8SAyKnmp3d+fuga2lbaDOOlPVj5vPpIXRLY4810SuGGdM6tsMvj?=
 =?us-ascii?Q?kf8hszE6oH9aJLjE3TIkvi5/la+8OqydM+5IZv2jAxjL2WfJawGK/yYCKiwX?=
 =?us-ascii?Q?YekJswpgHtxm4xyVnGmce4VoM3StidKhqk2UYyJpgKL+Q4NVFa1Nc2JIXE0c?=
 =?us-ascii?Q?0Z4RofZm4F0bjRjQYMBsyNqj4TvggTvBwZzMJ70CFLhmqBDcqaTGPpYigOQ8?=
 =?us-ascii?Q?59nIHrj+/vVXoJ2Keg3G11XipWEJvPFRED4U3NGE5WHQ3Mxshyhyd4Eqruu4?=
 =?us-ascii?Q?D0mRrEYq+CI+WytMih5Rh2Qj8xqA75/gDIfPthr4RXfgXwbP3EpWeJ5jHg5M?=
 =?us-ascii?Q?agPBl22N3GUD52blrfxAYiC8/hhjABCHuyKIthBkwbkYlm885SwavGkz8T0D?=
 =?us-ascii?Q?BHwGM7bllkt4nohsgNlPAuvPOE4m/0oM5nPvhEFdtVBVDNcrxv/Ll3wPvsIn?=
 =?us-ascii?Q?f/c9fdKnuifEgs7dfEHgxa9fgo13ZIbblWRwAgoxuBLJjsBSih6HMXDc/y/P?=
 =?us-ascii?Q?eAtPXLegPqjWxBH33kXv2WeHfGXEFC0dWbn7/0ZT6h3Hqqbz1dqWuQrsjGVv?=
 =?us-ascii?Q?fvdgJ0G+vyH7illgrZcXhiC+WPUUyd6arBH4Ltqz2wfxs/O1bkKyjMB3eWgF?=
 =?us-ascii?Q?LAJy5foLv96/UUJYv18VyyMG+VmKI6vsktqiBUc2OgN3oDXS8PBvO5XTv23y?=
 =?us-ascii?Q?9P+oFg7YiWHuqghoJgvcfpvKGcRUvrOynj8Ls1Y5aMPStLTTl3AQKzFE9afq?=
 =?us-ascii?Q?t8W97xvRJqXrmDphXaTscIoiJ4i4bLFUPft8bWsWMfU3HotLyhiOE4y0QAAS?=
 =?us-ascii?Q?nsh5eakFFIPZ9ZqlMfha5STH+paev/GPovqRBHE7bhtxk52iVpUEUuKK+B5v?=
 =?us-ascii?Q?Z4c20roz9VTgBkhDxvNCoFtO6V+hl27sE4dG5MPyKiWRq2ik3CW7VYRawD54?=
 =?us-ascii?Q?UF/1UDxf0d47gu5xXoBBlyE/V1UgZJjExXNLzyfZPswDwAJeCI4dqE2NCEq7?=
 =?us-ascii?Q?yx1XgBGiHZ1HIk//JL9CfjF8+f7Dyxylpb32WAc0NJMxfoIynTzhXJL4qwzw?=
 =?us-ascii?Q?fwFyTe1xP67I9kEs7qKNj3uTbLqhXxXXbPBQhFr75t62nsp/DFdSb8qyKFuH?=
 =?us-ascii?Q?QkgOFQVTAr6KqFCh6s6ucOUh+L9RiyQXPIUD1jpSWFqT9eZev2lqUOIVog6N?=
 =?us-ascii?Q?l+4AhbccHNmKZilFNj27VNA1eWlLhx/npOT1hkoxd7bbKXXPhV/2uM2QxLAV?=
 =?us-ascii?Q?odGtKVvbzw=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20ff1a46-1f41-46da-6b64-08df04480543
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:28.3954
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: f7uvZyByX5GadplGM3a0mXEi1cjFccTEMTw0z2rUU3f6NGaoAOQ7LC+rgCtMdrVjxXT3pn2XNJJTOSSAim+YXw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-4011c0/1787841149-595C3CFC-2A7B50F7/0/0
X-purgate-type: clean
X-purgate-size: 1017

init_tee_secondary() was marked __init and freed after boot. Calling it
from the CPU hotplug/resume path then executed discarded code, which
could crash Xen. Drop __init so the TEE mediator secondary init can run
safely on hotplugged and resumed CPUs.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
 xen/arch/arm/tee/tee.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
index 8501443c8e..00e561fc78 100644
--- a/xen/arch/arm/tee/tee.c
+++ b/xen/arch/arm/tee/tee.c
@@ -128,7 +128,7 @@ static int __init tee_init(void)
 
 presmp_initcall(tee_init);
 
-void __init init_tee_secondary(void)
+void init_tee_secondary(void)
 {
     if ( cur_mediator && cur_mediator->ops->init_secondary )
         cur_mediator->ops->init_secondary();
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400675.1636237 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9Y-0004ln-6i; Thu, 27 Aug 2026 14:32:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400675.1636237; Thu, 27 Aug 2026 14:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9Y-0004lK-1w; Thu, 27 Aug 2026 14:32:28 +0000
Received: by outflank-mailman (input) for mailman id 1400675;
 Thu, 27 Aug 2026 14:32:26 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9W-0004Xu-7s
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9V-009cNd-KC
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:25 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a78-bab6-0a2a0a5309dd-0a2a450ca9d8-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:25 +0200
Received: from [40.107.130.101]
 (helo=MRWPR03CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a79-f479-0a2a450c0019-286b82652c5b-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:25 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:23 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:23 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=C3v6TzNBY7Kn8BT1F9BRvwMzy/iGCuk3sNkP4ckAuCYrT+1OnD0i3Qbu5KfhGI1kdh0y7um4d3s/W02627E/WBQbHP3lSWPb5fC90/51QRqXgoSx2uEARD6yrw1f+5KYklFNTI3iyvzKDpIpn5BpcCqacKxB5BXDkmTqDFS0JgbXX4tLCNXDLSamGRFo+XntwtZgHkn90v2pengYOJchSW9VV8tLQzIC7RTeV59X5JzkIvYKxtiOG+e//P5SYfMhY3SsayiS6kSsmXyNQ0H2nEDETTt0wJBvB2O5B3YTAhUCK/FrxNo689IV3QQLyEIQF0bgMARa34S0Og78LG5ZRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sB/RFfs74+GICdQ6AM31qkw97XkZfD7mC0XQ1Y1nMno=;
 b=WajoJ+LNW5AgQG8jJUScJQHa72tIcsramMZg4vnLVpvnttYTd11dqfMqw5iJZ7Y/ZsYmQZ12CnszdIlogfsaLpZR3bSXfQbDd9qB9ylhJ0rArVOE5XX3qF2PcBfYPToVaqna7jLhgEV9YN3hfiegJNihbY52T2tI46qgRXq/IWLCr8ruaWZJ2epR1e/P6TrnDDJTw3ULP76JIyYa5C98T6Gy7YTQw04DsXex9+PQIcPpkTu0026CJ+ZNXBWmx8QH51b8AG62VnnjTtNIM1PiJviPE8wgDSMiJpbSpwp8d08EPgbHOLwcr/yqgJLIuAOjbimvBstwwB3vzRbHH/vlNw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sB/RFfs74+GICdQ6AM31qkw97XkZfD7mC0XQ1Y1nMno=;
 b=TjtpsK54tuR9akWHOiaX4hKaxDD4J6VteM3kA4SF0lgLeA9X44HLvLwi+CG9A9u/T6jTNDJKRHyRkK+4cku2cewYmzDz7QMIHs9E+1kmnSpa84zlZZIEjfTAHKw33DjIl1U4n4NAS19+e3YsTJsZrto2XVXwcUjpI5N8Fxi2bLpZNL/YrxN/SfqckCpjr+H5gRJR56wYDXOIMSYArSLFhO+1ni5+YapN9JDpoQBmD1sp18hywH1Bu4EkExZ6o1XLP40kNPXXTlsoW1zZrH93sTPoor97x5AAjNWALIC5Vctl8dxc8Kuq6y4xEwbdxOqn/E3yvBnCzBMv9DBABErs2g==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 03/13] xen/arm: gic-v3: tolerate retained redistributor LPI state across CPU_OFF
Date: Thu, 27 Aug 2026 17:31:51 +0300
Message-ID: <54a655ad51d994b46dff43e67c969a31772cec4b.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: e2c3dcd7-25e2-444d-6b85-08df0448026d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	aE9vGWpW0eWbLtavphJOqDC2sq2g2UDP33X7RbFgx6NkvoM7O4rYtof8s3HfEbOsFyD6Sb5V1oPh0tMvZz2a4vgpvG5LXeLqPn88GNHuJKWLWsJ33fcdIW0cSHUseimV1XA6YVI1z0Q3EzC6IVzLf90J5v6r0COJztoDybfluJEsIfR9WSifQ88HwCAFaDvrLY8jD3pR/2xqS6dOtFxmvLdxVJZfG6RNUFPL9OPkuQH15Qy50ksddxYloZ5nHNgt+0HQHHRERdlySKbe+IKVEkv7zN0By82xhXnFThl3524P5J9GFmNhUajT39p+4DvwgtyJ09VK1WFoapPv9Z86VSlg7BnmNYfgyaNl3Ij8u+xSMskktxQNQK5sIUWmm5+RC4EYjCEZjdiu4lT1d2lctybH7+VKW8kf0AkbeiT+9a1WodmblyKCl8Qfx6WGMqjBGwXD/8qNZKTyoOVcsH2ztvlDyDq2XRCK3UMehDUvCMtgxrAmjXEHKzGUoxsJ7J15X/F3tmTF0+2QE98BuOa71Ps0OoXfXz95lR2l6O+B1T6z+f8fBKCOXJLyQ7n0j7p3NjHBp6LmAP5FEVfFhZG29rZKj4/qeP2Y/wmD7eRQjjaBTP5KmBkS9Idi2R8ieXVA6QOG/iCLqHzz82Z0A7qhVWRXhnP4KTIFAW/7ZqGVl54=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?xASgQvdk9+2VWbtPwPMmfg55+i1zGqLjaXN0lLSagc6F/X6Iuk43Fn4Mq2O7?=
 =?us-ascii?Q?8zycpmfKMNWZxVryIDd8CXTqnxD2ZCvGPsS7nq/TLujzILLLC/i0Oy1lqYAZ?=
 =?us-ascii?Q?OlXJ9yYzk9GisobwHWPvD8p9Qn5W/6OaXO7kRNkv9CArwoo5U0MYzfcuPItg?=
 =?us-ascii?Q?ErM1POO/gtdh1s0QjfxvcbyphY7pN1X0HEKl9twpJj77GzIawccPI+D0g+Mr?=
 =?us-ascii?Q?97p4wM7lwBR8GWv2X50Xdr36q6wCPAv/U9zvHjp3eXMRWOMFSdZhd8uMALj2?=
 =?us-ascii?Q?tTAdQx33NBMK8YKstJf4ZwLWSuc3VgCvD9x5R4FSdUE/9Qw0/s6frDjK8p7f?=
 =?us-ascii?Q?099yxKefzjgAEC0/xsa2Q/eIM9GEvnvwtMNd84pEm7Ek9/zM5i/jQIsDbJHq?=
 =?us-ascii?Q?InGlZk+kylJ7F7tre5cs8I+7IDJy1YVSYjgAOACW38nWqksXWQv2G3+g35d8?=
 =?us-ascii?Q?Gsv0x6UVU+tzlB8feiTCD152VAkR5FosssI5r4LF1aWm7KbjNPv558PN+JB9?=
 =?us-ascii?Q?OIF9NGP8wc+aLCoU3A/bHj1eGPK3PvSOOP5XX5AVQhhPlpQSjBH4Gz9YPb1t?=
 =?us-ascii?Q?e+Y9Yx0qlQXj7k6zUP449HByRpd9yCEat5P/MSG87ctObCJjP3vGoHLPx0tl?=
 =?us-ascii?Q?i7X0SXoXH9z2QbiiWFUDrlme8NTbdjfxL4Uiv9AxnGED6svotxpozB0ep/Do?=
 =?us-ascii?Q?ZUKt2KRMC8s4Q3PLt5ci81quCmcRcoYYJcLvj6N8nYf6RsZStLb1EucLK60I?=
 =?us-ascii?Q?BW1A3rx7I2ktAELzQuELv4AgLGPTVcDuzVALJEaXThLrq72tVdYJHQN2xT6d?=
 =?us-ascii?Q?GUdGaT7FyTtUGX5ZngCinhMR38gokVSVV28gc4/hlL6BHWd2uxr11Gre3ql0?=
 =?us-ascii?Q?nnyZ9xOEqDnumsuXG94QnfX6aBdgrmBmcUEpdTp2BfJbeNMC46m5ziajLUvf?=
 =?us-ascii?Q?KMKmaMr3OMat94BuMhUcr0qhMAg7hUIplQPtQW69yZAi65K0uA1VjYM5QmFw?=
 =?us-ascii?Q?VasXrt9TMNwvbjSoEu41/2c3IoasNz9J2KI3a+jvxGe3tTN0c4Gf+jPYN5xo?=
 =?us-ascii?Q?BO9fZIsNFXGTp74J1aCo4JJx6ENYhZNYm2aBfQCpnGKWR02G0XUrkTytEFqG?=
 =?us-ascii?Q?6qP33ATDepDbNQETuMS/f5qkuljvcl6L7GoT/17f2IhedSY91GsxRRWqL9kG?=
 =?us-ascii?Q?7NjX51Bcqk3aRY0CKVJyM496TtWpTHv/htR4vF7+BChdZ6rMtOGk7kyiIBeE?=
 =?us-ascii?Q?41kpqhkClb3LT3mmfkfoMUise/rKDCINvTXfSnBd3ygtUWZ0S5RQvX1T6Jyx?=
 =?us-ascii?Q?zkQUg9CXNMJHl7YAs3WGV6yWMXZ6qfvgGYiblFh6JFmNO5EmFcbb8IwQqu7k?=
 =?us-ascii?Q?LWkEwQAdKobTF3GIYKp0YI69TBVmzxGJhIwuYolbONmC40Z6mYcH+z2EMUbO?=
 =?us-ascii?Q?N+WaLZHZQEMwPzSOWwKzjx1AAzJZ7Ad2oGhw/0q1KyGgkxezchl/JdjTLGp5?=
 =?us-ascii?Q?oikMbNlSH3IJTqisryo5l5reLs4d3RVI3POUbVO8tOt6r0fLnu/oP0g6dMiB?=
 =?us-ascii?Q?s8H5Z319Sj43ETomQkYQlZWAdmifOloQULAE8L173V2qPWPwyk10EdbsrDxR?=
 =?us-ascii?Q?6F7+CorCAGgJ20FNg+n7bjH8rAL/9YtKo1hbDUso6DF8EmQfKWvhvVckSLz3?=
 =?us-ascii?Q?qu57Vhdu7HSP/KSRLqmPzk7gm6JTVA/TV1FHPNJcR3dXNJgJot4JTIbBUDKM?=
 =?us-ascii?Q?l5z/coewow=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e2c3dcd7-25e2-444d-6b85-08df0448026d
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:23.6005
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rx0F+W1Of38FyfJnBosLQD+G/ngamb7XVCS2OR9/6T8X6v1A0UzsukDhiQy+Gba7LV4oy9q+A/Ojxi9nivYTFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-d25034/1787841145-766DEA5B-5377B1D6/0/0
X-purgate-type: clean
X-purgate-size: 9556

PSCI does not guarantee that a GICv3 redistributor is powered down across
CPU_OFF -> CPU_ON.

DEN0022F.b says CPU_OFF powers down the calling core (5.5) and CPU_ON
brings the core back with a defined initial CPU state (5.6, 6.4).
However, PSCI leaves interrupt migration and GIC re-initialization to the
supervisory software/firmware stack: the caller must migrate interrupts
away before CPU_OFF (5.5.2), and the execution context that is lost in a
powerdown state must be saved and restored by software (6.8). PSCI also
calls out GIC management explicitly in 6.8, including retargeting SPIs,
preventing PPIs/SGIs from targeting a powered down CPU, and reinitializing
the CPU interface after CPU_ON.

This matches the GIC architecture. IHI0069H.b Chapter 11.1 requires the PE
and CPU interface to share a power domain, but explicitly allows the
associated redistributor, distributor, and ITS to remain powered while the
PE and CPU interface are off. All other GIC power-management behavior is
IMPLEMENTATION DEFINED. DEN0050D Chapter 4.2, "Generic Interrupt
Controller (GIC)", says the GICv3 redistributor may live either in the AP
core power domain or in a relatively always-on parent domain. So after
CPU_OFF -> CPU_ON a secondary CPU can legitimately come back to a live
redistributor with GICR_CTLR.EnableLPIs still set.

Handle that case in the LPI setup path instead of assuming a fully reset
redistributor.

The LPI path needs special care because the GIC spec makes redistributor
LPI state sticky and partially implementation defined. IHI0069H.b 5.1.1
and 5.1.2 say that changing GICR_PROPBASER or GICR_PENDBASER while
GICR_CTLR.EnableLPIs == 1 is UNPREDICTABLE. After clearing EnableLPIs,
software must wait for GICR_CTLR.RWP == 0 before touching the pending
table. The architecture also permits implementations where, once
EnableLPIs has been set, clearing it again is not guaranteed to work.
Where an ITS is present, the spec strongly recommends moving LPIs to
another redistributor before clearing EnableLPIs.

Because of that, treat a retained EnableLPIs state as valid when the
redistributor still points at Xen's expected PROPBASER/PENDBASER tables.
Only try to clear EnableLPIs when the retained configuration does not
match Xen's state, and wait for RWP before reprogramming the tables.

This is also consistent with platform firmware reality: PSCI and the GIC
architecture allow platform-specific redistributor power handling, and not
all platform firmware implementations force a full redistributor power-off
through implementation-defined controls during CPU_OFF. Xen therefore needs
to tolerate retained redistributor state on secondary CPU bring-up.

Keep gicv3_populate_rdist() resident as well, because gicv3_cpu_init()
reuses it on secondary CPU bring-up after init.

Tested using Xen's non-boot CPU disable/enable path on Arm
FVP_Base_RevC-2xAEMvA, both with and without:
-C gic_distributor.allow-LPIEN-clear=1
-C gic_distributor.GICR-clear-enable-supported=1
and on Orange Pi 5.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v10:
- Drop unrelated gicv3_populate_rdist() printk() format cleanups to keep
  the patch focused on retained redistributor LPI state.

Changes in v9:
- move gicv3_do_wait_for_rwp prototype from its related header to gic.h
- drop __init from gicv3_populate_rdist(), which is reused on secondary
  CPU bring-up after boot
- changed print format for smp_processor_id in gicv3_populate_rdist func
- cosmetic changes
---
 xen/arch/arm/gic-v3-lpi.c      | 77 +++++++++++++++++++++++++++++++++-
 xen/arch/arm/gic-v3.c          | 15 ++++---
 xen/arch/arm/include/asm/gic.h |  4 ++
 3 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 9ee338edc2..847da26ff7 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -81,6 +81,13 @@ static DEFINE_PER_CPU(struct lpi_redist_data, lpi_redist);
 #define MAX_NR_HOST_LPIS   (lpi_data.max_host_lpi_ids - LPI_OFFSET)
 #define HOST_LPIS_PER_PAGE      (PAGE_SIZE / sizeof(union host_lpi))
 
+#define GICR_PROPBASER_XEN_MASK  GENMASK_ULL(51, 12)
+/*
+ * For retained redistributor state, match the pending table by address only.
+ * Attribute bits such as PTZ may not read back with the programmed value.
+ */
+#define GICR_PENDBASER_XEN_MASK  GENMASK_ULL(51, 16)
+
 static union host_lpi *gic_get_host_lpi(uint32_t plpi)
 {
     union host_lpi *block;
@@ -296,6 +303,60 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
     return 0;
 }
 
+static uint64_t gicv3_lpi_expected_proptable(void)
+{
+    return virt_to_maddr(lpi_data.lpi_property);
+}
+
+static uint64_t gicv3_lpi_expected_pendtable(void)
+{
+    return virt_to_maddr(this_cpu(lpi_redist).pending_table);
+}
+
+static bool gicv3_lpi_tables_match(void __iomem *rdist_base)
+{
+    uint64_t propbase, pendbase;
+
+    if ( !lpi_data.lpi_property || !this_cpu(lpi_redist).pending_table )
+        return false;
+
+    propbase = readq_relaxed(rdist_base + GICR_PROPBASER);
+    pendbase = readq_relaxed(rdist_base + GICR_PENDBASER);
+
+    return ((propbase & GICR_PROPBASER_XEN_MASK) ==
+            (gicv3_lpi_expected_proptable() & GICR_PROPBASER_XEN_MASK)) &&
+           ((pendbase & GICR_PENDBASER_XEN_MASK) ==
+            (gicv3_lpi_expected_pendtable() & GICR_PENDBASER_XEN_MASK));
+}
+
+static int gicv3_lpi_disable_lpis(void __iomem *rdist_base)
+{
+    uint32_t reg = readl_relaxed(rdist_base + GICR_CTLR);
+    int ret;
+
+    if ( !(reg & GICR_CTLR_ENABLE_LPIS) )
+        return 0;
+
+    writel_relaxed(reg & ~GICR_CTLR_ENABLE_LPIS, rdist_base + GICR_CTLR);
+
+    /*
+     * The spec only guarantees programmability when we have observed the bit
+     * cleared. Where clearing is supported, RWP must reach 0 before touching
+     * PROPBASER/PENDBASER again.
+     */
+    wmb();
+
+    ret = gicv3_do_wait_for_rwp(rdist_base, GICR_CTLR_RWP);
+    if ( ret )
+        return ret;
+
+    reg = readl_relaxed(rdist_base + GICR_CTLR);
+    if ( reg & GICR_CTLR_ENABLE_LPIS )
+        return -EBUSY;
+
+    return 0;
+}
+
 /*
  * Tell a redistributor about the (shared) property table, allocating one
  * if not already done.
@@ -374,7 +435,21 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base)
     /* Make sure LPIs are disabled before setting up the tables. */
     reg = readl_relaxed(rdist_base + GICR_CTLR);
     if ( reg & GICR_CTLR_ENABLE_LPIS )
-        return -EBUSY;
+    {
+        if ( gicv3_lpi_tables_match(rdist_base) )
+            return -EBUSY;
+
+        ret = gicv3_lpi_disable_lpis(rdist_base);
+        if ( ret == -EBUSY )
+        {
+            printk(XENLOG_ERR
+                   "GICv3: CPU%u: LPIs still enabled with unexpected redistributor tables\n",
+                   smp_processor_id());
+            return -EINVAL;
+        }
+        if ( ret )
+            return ret;
+    }
 
     ret = gicv3_lpi_set_pendtable(rdist_base);
     if ( ret )
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index acdac22953..b16888ad84 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -275,7 +275,7 @@ static void gicv3_enable_sre(void)
 }
 
 /* Wait for completion of a distributor/redistributor change */
-static void gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit)
+int gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit)
 {
     uint32_t val;
     bool timeout = false;
@@ -299,17 +299,22 @@ static void gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit)
     } while ( 1 );
 
     if ( timeout )
+    {
         dprintk(XENLOG_ERR, "RWP timeout\n");
+        return -ETIMEDOUT;
+    }
+
+    return 0;
 }
 
 static void gicv3_dist_wait_for_rwp(void)
 {
-    gicv3_do_wait_for_rwp(GICD, GICD_CTLR_RWP);
+    (void)gicv3_do_wait_for_rwp(GICD, GICD_CTLR_RWP);
 }
 
 static void gicv3_redist_wait_for_rwp(void)
 {
-    gicv3_do_wait_for_rwp(GICD_RDIST_BASE, GICR_CTLR_RWP);
+    (void)gicv3_do_wait_for_rwp(GICD_RDIST_BASE, GICR_CTLR_RWP);
 }
 
 static void gicv3_wait_for_rwp(int irq)
@@ -863,7 +868,7 @@ static bool gicv3_enable_lpis(void)
     return true;
 }
 
-static int __init gicv3_populate_rdist(void)
+static int gicv3_populate_rdist(void)
 {
     int i;
     uint32_t aff;
@@ -931,7 +936,7 @@ static int __init gicv3_populate_rdist(void)
                     gicv3_set_redist_address(rdist_addr, procnum);
 
                     ret = gicv3_lpi_init_rdist(ptr);
-                    if ( ret && ret != -ENODEV )
+                    if ( ret && ret != -ENODEV && ret != -EBUSY )
                     {
                         printk("GICv3: CPU%d: Cannot initialize LPIs: %u\n",
                                smp_processor_id(), ret);
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h
index 29bb9a89a4..68003ab116 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -301,6 +301,10 @@ extern int gicv_setup(struct domain *d);
 extern void gic_save_state(struct vcpu *v);
 extern void gic_restore_state(struct vcpu *v);
 
+#ifdef CONFIG_GICV3
+int gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit);
+#endif
+
 #ifdef CONFIG_SYSTEM_SUSPEND
 /* Suspend/resume */
 extern int gic_suspend(void);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400673.1636223 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9W-0004YA-MY; Thu, 27 Aug 2026 14:32:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400673.1636223; Thu, 27 Aug 2026 14:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9W-0004Y1-Jt; Thu, 27 Aug 2026 14:32:26 +0000
Received: by outflank-mailman (input) for mailman id 1400673;
 Thu, 27 Aug 2026 14:32:25 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9V-0004Xi-Ch
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:25 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9U-00Bhds-3O
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:24 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a76-2eae-0a2a0a5409dd-0a2a450a9b26-6
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:24 +0200
Received: from [52.101.83.141]
 (helo=GVXPR05CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a77-f2d2-0a2a450a0019-3465538d5b1d-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:23 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by GVXPR03MB10457.eurprd03.prod.outlook.com (2603:10a6:150:156::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:15 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:15 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M8x4jbEcwSwnlHSPoWLppWVHJTFNf09GDFKfjf3zWy+m3eBhKt7t3TJgoiF6/QBI555Be2x9DdQq0zohiW/RosdY1d+629+768eTmS/zRpXV3pXFXbyz7IRZgFrY/k75zy0SnBss+oWoDpCxGtHF9RhZyTTvRdvvdKaVn6F066KJCe+OeMBKX79tRkOl6AzeQ0Uf9fww+8p3RLE+povaAXd4d8K8LJYhZaZVeBt2Kekt1k9EOHq7wVOX7E0wBu4Oi2wHveaH707o7pigh6bwg6t1hywjA+jX8s9gWmGNWukSgYMLU0dwDlDjZa2V8XyVHTXPjs32GW4AQPz2knEXuw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=cn8AOFfHK66mM6rV8XQzylPhaIZpE6GKNfQnG9WiURk=;
 b=rOQN75tCS3CaM2Fuscpr8Xo+VAYWpuBCozd+q9BCIsbVNM9rarjcxutlCqlmPo2GVy+IM6tAEEkdZe5hlEN1WP1lPlOLDH035gWqLVFNYqGfUXOjTfrg1e0AIXjBRcwFp2HG25hw34L+slGOcEG/2ydF9LhUgLrOzIgXn7dLixn1+XO2jR2DYnjA6Fea0PoaoTiumVyyHGo53ViGNqgAfzy7ARTlF0EFN+1u2lN/QPkni9TIySmoNvsfzn5xMFfJdoZuZgwm3oqVHsHEZmIXd/Yncanlejglmxk1fdRY7BjGNFY+XYwYF5FpC2wcVcRJ71wFL9CbLbephwXWKRIhkA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=cn8AOFfHK66mM6rV8XQzylPhaIZpE6GKNfQnG9WiURk=;
 b=MlAJK7xZArdaW6PyDbuM0owluH3adN/KDxX8gw8rptL4p2BfgGapcj9MZBFSfwTdmL7iYkJlxNzV2eQRu3NGaRSaLHD8Fo9wA/nh1PQNE1dLoVVYzZpGV7hMdI7xibyEp4lyGGX27oQMrT1oiNG9dqD5wXazbrPKEJNbsIa2pf5d29FWG+v3SJnYUTUgOGv4aSf0gicIQjtr1BVz8QEfry5eEazYqgV/sL8IVacORAX4wOXB0RIxs/Lu4PnwnXgq5nloPKr43AnRdDnMuEMhWWhLWCs02xgSFMPHprrBDd5rg2HFn7006vmPHcCzioJOOEnbuUuAaODzHfqMuC3SRg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jens Wiklander <jenswi@kernel.org>,
	Rahul Singh <rahul.singh@arm.com>
Subject: [PATCH v12 00/13] Add initial Xen Suspend-to-RAM support on ARM64
Date: Thu, 27 Aug 2026 17:31:48 +0300
Message-ID: <cover.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GVXPR03MB10457:EE_
X-MS-Office365-Filtering-Correlation-Id: 7872f4e1-ce2b-4874-edca-08df0447fd81
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|7416014|10067099003|6133799003|18002099003|5023799004|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	JjqyA7GcF4rDhPOIdjUNTKlKgXZnJ4RaivGu/wmN+KOYUS0XIFJJ6v+Jx0FHl0t2vSmwWQzOLf6qQshHhhtVAtw+OZBczVjXbDbOeC6MX+M/pKYqfX7l1VBkFn5Y8Zqzv60MTlicKBxxzys/FhA+so+0WSK+c1JAjem4w8MTZfUAp31mMINxl4OdAghNFJ36cArG+fWE+7UsuDwvImXzZjp4DM+2ZHYS4DwbP4Yzwcn4XKJ4tfIf9aT1qifI5Ri2BAkwJVGLayiyjCJ1hXWd6UMKRbhCoXWFrgDmU/sF3yIQ9PsEDPIb761nRbuDiI6wORdqhMTqZ0jMwaYPykI/KgnE90EkINGqaiJi5Aeisx5CeGTSG6lKMLBeTJbTCbjw5VE3rsSqnEri1xld7QE2jC5Y7zIAhfaPshawZeE3BOv4Ynino1NNk0sPGsBpSA/INdT8Yd7gROU3Y71s8CGm/g+8JCJLh+d7T7dX4ZvdzdHAG01XLXqCvl41FY8o+etE+l/fm1WInw2kDIuAKRSZpRElvky+SjUfEHB6JJDUvLV0TrYstfiXagXM0AzU0sF4NFcXSOF5cfOcFHGebqPmZJF7KvdKlprfr6xfqftI7h1tUvpn3m95NB8wDbD+p8bOyuP8WkjeRiTFzGHmrVwv3cTZJi5G0ppjnJ56juqB7/U=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(7416014)(10067099003)(6133799003)(18002099003)(5023799004)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?7q4yR93iPu1g3IY+DrBCgOwgCfZzw7Nd/EuLc2vjde8p2xN+Jc4r/mENMJVQ?=
 =?us-ascii?Q?ggx2mPbJH5kn6OZhUM4B8kumTG1sSWBNq6FpSRnucKodINIZ8QB61Zr1zUXn?=
 =?us-ascii?Q?1EuB/ncFrP2fbTazdYAuOBZ5+PuPwVVOlWcxBImWPoYdtjj/DAzj1IA93Y+A?=
 =?us-ascii?Q?fq0iNaySi20SI0mmorG2pHMeoSNP1t2E9DG6riw65HsT8mmWOfZg6HQERY9e?=
 =?us-ascii?Q?wuEEri556YS9tneAh7YHIwczFPBuURe2EJbp6DjsIVCEvlWvJJvfgUr4D5IR?=
 =?us-ascii?Q?qc8DuDe4XabXh/KJjUPsuall+HEaql1toWTb1AC+YqfHZVqJnBv0CX1O+Qnp?=
 =?us-ascii?Q?i+YnFuxe4oupn5HayhrRq7zrXYwXvRoUb4kriTZMVaUfmVcMm/+/pNfBNI1k?=
 =?us-ascii?Q?Er33zSNzDYusWBXOs9nFyzc9mJ9hd9xk0Bc1qnuU0MiqXEh9K394kXf9N0B0?=
 =?us-ascii?Q?EpiHjuDdTTvxzWVdrQ/mo0PqEuH5vo31Ggj4Pvp520BZpNwHKXbWjm+Qb0op?=
 =?us-ascii?Q?tmya0NLG2D/BkHcrt5JfOZPNJnlVwyTxh5IZkKL1QyaPhYbUZmhpr/23HUsI?=
 =?us-ascii?Q?rGdbfV4dInWexu7xYgJLYrZppW/Vr38egGNGuVjmc6jrRBqI3wSJYEzdlI5a?=
 =?us-ascii?Q?dMI0EaTCDFjD/HH0nvVGGBVYuJUmYUBD+aH8wC1HI+95L8tq0Mg3VccAzoIc?=
 =?us-ascii?Q?ry/F6z3IHUwqVSQS6Ad63HnShsDRAwUii7Rvu1mDuHA4xbHR1e3bQ1sYVll+?=
 =?us-ascii?Q?Yw4gX9eYL/AfDN/r/eYKlgj+8n7PYddJfmKk7+OzuTX9z8AuXrWLquyGGcKJ?=
 =?us-ascii?Q?t/Xpxu0Pm/vGtUIqqRe1ztrmfBvqmz4vZwhsNPXVB7gd5L0jw4z5BLqFc0+P?=
 =?us-ascii?Q?/nBDpHPhQ8CvxfG6FP0OEGCTCfr0d/JBK1oVXYqLG5hctbXuR3NUmL6veEmR?=
 =?us-ascii?Q?MYV6ML+CMknDdO86l6mMGFDhZ/g47rAT2o0T4zoxyR4ZvfyUb4fvoIlULc3P?=
 =?us-ascii?Q?p6PFZgH+W+BJ5H2AqJJNghNU+GjL+qEj4tX5mXcAbo37UHFfAKtBXIqxi99d?=
 =?us-ascii?Q?8QciU5y5knmn0UVwUvbTAElRxgreYeaqRD8yiyW1bqeCPD+NKnuz+6CuDd4f?=
 =?us-ascii?Q?dv0iDrMcUeAxkAyHJBygGqh8DT7b3ga04f1wk2+H8u8WarpE5TX5W3Xtz3bV?=
 =?us-ascii?Q?a1R14dNSrUHFsnCwxao8SZ0nhaPJeWqOC67UGU9r5FOZUUZhtF8Tz/ZKTKGx?=
 =?us-ascii?Q?o5/jL3xo+Pxm/hFlOwok61bWMFxZ6zapXmfmjiOPusUEjqA8cZK8e92UzW8e?=
 =?us-ascii?Q?5m12Mc1GvMYG9lpNAppd3sTlLOPWbXhumCmW/vqU7yUcfq6ckOEwk1bsvEWl?=
 =?us-ascii?Q?IhTwfRE/0VZnIvrYbkuY6mzKKjAw+zB197fkFPsNQ4ZzCfyHtopzU/0hP41C?=
 =?us-ascii?Q?QkCgBH5OsZkAF0fItBqHvDD2O9aAqBaJiyiYxsiBU8be8x4kbJYd0SYdxfw7?=
 =?us-ascii?Q?SWAiEkimISiQjj5Nw1xQ80NOGSp4F2EM7/gQHSZu5dN0inf6uzxxYHp4QZey?=
 =?us-ascii?Q?xVPzwxnU6UUKqCn8ZqdM6cT65lwrWk+lJ+TQRY4uU0yIwsuAX6v3LuoLBwZG?=
 =?us-ascii?Q?dMHTW0SJlYjipfRuwROyFhCd3A/dyEHYmbiQVBTOnsu2lenhcMXtkD/7fqzI?=
 =?us-ascii?Q?6kRAtrZVmo/I7Y9gh/kz3dbNrJ9NmiC/66aXvx9sCHtUn++jowpB/yT5CHte?=
 =?us-ascii?Q?+KbVovBwzQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7872f4e1-ce2b-4874-edca-08df0447fd81
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:15.3956
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0Kq0f0SK8EhNbSbbnC/NuppVtciaallDFtWSQ2Jf4FnffdqJfPb58x6ITsBkwjTH2YNEC7031SdtcG90Hhrzhw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10457
X-purgate-ID: tlsNG-4011c0/1787841144-504CFCFC-1854883D/0/0
X-purgate-type: clean
X-purgate-size: 8777

This is part 2 of the ARM Xen system suspend/resume patch series, based
on earlier work by Mirela Simonovic and Mykyta Poturai.

Part 1, covering guest suspend functionality, is already in mainline.

NOTE: Host-wide suspend/resume support is guarded by CONFIG_SYSTEM_SUSPEND,
which can currently only be selected when UNSUPPORTED is set, and thus the
host suspend backend is neither enabled by default nor built in supported
configurations. The separate HAS_HWDOM_SYSTEM_SUSPEND policy bit only changes
how ARM treats SHUTDOWN_suspend from the hardware domain; it does not enable
the host-wide suspend backend by itself.

This version is ported to Xen master and includes extensive improvements
based on reviewer feedback. The patch series restructures code to improve
robustness and maintainability, and implements initial ARM64 host-wide
Suspend-to-RAM support driven by control-domain PSCI SYSTEM_SUSPEND
requests. vPSCI also exposes SYSTEM_SUSPEND as a domain suspend operation
for all domains; attempt-time host-suspend policy failures are reported as
PSCI_DENIED rather than hidden through PSCI_FEATURES.

Key updates in this series:
 - Introduced architecture-specific suspend/resume infrastructure
 - Integrated GICv2/GICv3 suspend and resume, including memory-backed context
   save/restore with error handling
 - Added time and IRQ suspend/resume hooks, ensuring correct timer/interrupt
   state across suspend cycles
 - Implemented proper PSCI SYSTEM_SUSPEND invocation and version checks
 - Added vPSCI SYSTEM_SUSPEND policy for domain suspend and host-wide
   control-domain sequencing
 - Improved state management and recovery in error cases during suspend/resume
 - Added support for IPMMU-VMSA/SMMUv3 context save/restore
 - Added support for GICv3 eSPI registers context save/restore
 - Added support for ITS registers context save/restore
---

Link to CI: https://gitlab.com/xen-project/people/mykola_kvach/xen/-/pipelines/2796733872
---

TODOs:
 - Enable "xl suspend" support on ARM
 - Add suspend/resume CI test for ARM (QEMU if feasible)
 - PCI suspend ?
---

Detailed changelogs can be found in each patch.

Changes in v12:
- Rebase onto the latest master.
- Updated patch 12; all other patches are unchanged.
  No functional changes.

Changes in v11:
- Keep SMMUv3 reset helpers in init text when CONFIG_SYSTEM_SUSPEND is
  disabled.
- Update host suspend policy blockers after review: make the runtime gate
  __ro_after_init, log the SMMUv3 MSI blocker only once, and wrap the Arm
  IOMMU blocker in CONFIG_SYSTEM_SUSPEND.

Changes in v10:
- Clarify the vPSCI SYSTEM_SUSPEND policy summary: keep SYSTEM_SUSPEND
  advertised once implemented and return PSCI_DENIED, rather than
  PSCI_NOT_SUPPORTED, for attempt-time host-suspend policy failures.
- Tighten GICv2/GICv3 suspend/resume based on review feedback: avoid
  reserved interrupt register ranges, check visible active-priority state,
  restore configuration before enable state, and re-enable the redistributor
  before restoring CPU/virtual interface state on abort paths.
- Refine ITS resume so MAPC is replayed only for ITS-backed collections and
  clarify the collection-ID assumptions.
- Rework IPMMU and SMMUv3 resume/suspend handling, including root-before-cache
  IPMMU restore ordering and disabling SMMU interrupt generation before
  suspend.
- Save and restore CNTHCTL_EL2 in the arm64 CPU resume context and simplify
  the resume trampoline/context hand-off.
- Re-apply boot CPU errata/workaround handling after SYSTEM_SUSPEND and move
  set_init_ttbr() declaration to asm/mmu/mm.h.
- Update patch 12 details: shorten SYSTEM_SUSPEND blocker logs, use %pd for
  control-domain logging, mark serial_suspend_available as __ro_after_init,
  and mention the xen/suspend.h struct domain forward declaration.

Changes in v9:
- Split the control-domain SYSTEM_SUSPEND flow so host availability,
  runtime blockers and domain-readiness checks are handled separately from
  the host suspend backend.
- Gate vPSCI SYSTEM_SUSPEND on cached host PSCI support and Xen runtime
  suspend blockers, and log firmware support during initialization.
- Fold the arm64 resume trampoline into the CPU context save/restore patch
  and use asm-offsets-generated RESUME_CTX_* definitions for the assembly
  save/restore path.
- Tighten the GICv2/GICv3/ITS/IPMMU/SMMUv3 suspend/resume paths based on
  review feedback, including state-save/restore fixes and safer failure
  handling.
- Reorder the host suspend/resume phases so timer and GIC state are
  handled with local IRQs disabled and restored before console/IOMMU
  resume.

Changes in v8:
- Rebased to latest master and refreshed the series accordingly.
- Added a new GICv3 patch to tolerate retained redistributor LPI state
  across CPU_OFF/CPU_ON.
- GICv2 suspend now disables the CPU interface and distributor before
  saving state.
- GICv3 suspend/resume fixes the redistributor base used for LPI state.
- ITS and SMMUv3 suspend/resume paths were tightened, with safer
  restore/rollback handling and stricter fatal-error handling.
- System suspend now checks that all domains are already in
  SHUTDOWN_suspend before proceeding, and renames the hardware-domain
  suspend capability/helper for clearer semantics.
- Fixed alignment/cleanup issues in the low-level suspend/resume code.

Changes in v7:
- Timer helper renamed/clarified; virtual/hyper/phys handling documented.
- GICv2 uses one context block; restore saved CTLR; panic on alloc failure.
- GICv3/eSPI/ITS always suspend/resume; restore LPI/eSPI; rdist timeout.
- IPMMU suspend context allocated before PCI setup.
- System suspend: control domain drives host suspend.
- Dropped v6 IRQ descriptor restore patches; use setup_irq and re-register
  local IRQs on resume instead.

For earlier changelogs, please refer to the previous cover letters.

Mirela Simonovic (5):
  xen/arm: Add suspend and resume timer helpers
  xen/arm: gic-v2: Implement GIC suspend/resume functions
  xen/arm64: Save/restore CPU context across SYSTEM_SUSPEND
  xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface)
  xen/arm: Add host system suspend backend

Mykola Kvach (7):
  xen/arm: gic-v3: tolerate retained redistributor LPI state across
    CPU_OFF
  xen/arm: gic-v3: Implement GICv3 suspend/resume functions
  xen/arm: gic-v3: add ITS suspend/resume support
  xen/arm: tee: keep init_tee_secondary() for hotplug and resume
  xen/arm: ffa: fix notification SRI across CPU hotplug/suspend
  xen/arm: smmu-v3: add suspend/resume handlers
  xen/arm: Add vPSCI SYSTEM_SUSPEND policy

Oleksandr Tyshchenko (1):
  iommu/ipmmu-vmsa: Implement suspend/resume callbacks

 xen/arch/arm/Kconfig                     |   2 +
 xen/arch/arm/Makefile                    |   1 +
 xen/arch/arm/arm64/asm-offsets.c         |  21 +
 xen/arch/arm/arm64/head.S                | 122 ++++++
 xen/arch/arm/cpuerrata.c                 |   7 +-
 xen/arch/arm/gic-v2.c                    | 226 +++++++++++
 xen/arch/arm/gic-v3-its.c                | 146 ++++++-
 xen/arch/arm/gic-v3-lpi.c                |  80 +++-
 xen/arch/arm/gic-v3.c                    | 482 ++++++++++++++++++++++-
 xen/arch/arm/gic.c                       |  35 ++
 xen/arch/arm/include/asm/arm64/sysregs.h |   5 +
 xen/arch/arm/include/asm/cpuerrata.h     |   1 +
 xen/arch/arm/include/asm/gic.h           |  16 +
 xen/arch/arm/include/asm/gic_v3_defs.h   |   3 +
 xen/arch/arm/include/asm/gic_v3_its.h    |  28 ++
 xen/arch/arm/include/asm/mmu/mm.h        |   2 +
 xen/arch/arm/include/asm/psci.h          |   4 +
 xen/arch/arm/include/asm/suspend.h       |  37 ++
 xen/arch/arm/include/asm/time.h          |   5 +
 xen/arch/arm/mmu/smpboot.c               |   2 +-
 xen/arch/arm/psci.c                      |  38 +-
 xen/arch/arm/suspend.c                   | 210 ++++++++++
 xen/arch/arm/tee/ffa_notif.c             |  63 ++-
 xen/arch/arm/tee/tee.c                   |   2 +-
 xen/arch/arm/time.c                      |  44 ++-
 xen/arch/arm/vpsci.c                     | 120 +++++-
 xen/common/Kconfig                       |   3 +
 xen/common/domain.c                      |   7 +-
 xen/drivers/char/serial.c                |  12 +
 xen/drivers/passthrough/arm/iommu.c      |   6 +
 xen/drivers/passthrough/arm/ipmmu-vmsa.c | 323 ++++++++++++++-
 xen/drivers/passthrough/arm/smmu-v3.c    | 203 ++++++++--
 xen/include/xen/list.h                   |  14 +
 xen/include/xen/serial.h                 |   1 +
 xen/include/xen/suspend.h                |   2 +
 35 files changed, 2169 insertions(+), 104 deletions(-)
 create mode 100644 xen/arch/arm/suspend.c

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400680.1636287 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9e-00067K-2E; Thu, 27 Aug 2026 14:32:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400680.1636287; Thu, 27 Aug 2026 14:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9d-000670-VA; Thu, 27 Aug 2026 14:32:33 +0000
Received: by outflank-mailman (input) for mailman id 1400680;
 Thu, 27 Aug 2026 14:32:32 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9c-0005jW-3o
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9b-009cRM-GL
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:31 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a78-bab6-0a2a0a5309dd-0a2a450ca9d8-18
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:31 +0200
Received: from [52.101.84.113]
 (helo=DB3PR0202CU003.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a7f-f479-0a2a450c0019-346554711170-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:31 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:29 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Fn8rMzGfE4ZLUVHQ0I2IpZZe5UKUl5UJEVo78oVJDS5FYAmqUhwAl/Jfdhh66J27gPt9lDH35ngDaHvba6MokcaSg1f+58LR1oWzdavas95yj+n41cE1Q9ASmZJup3h/8YItIcT1hdznWEk0i5cZGxoo17mLCQHMelYEaP2LDjHDZdqWEcXk/44BSMvOND49yAJX7XSZlB/7QUKXfN6j1++MFDfL+WjmvJ60JsD8xHMBA1fbeHsSjfxENheHb4sqsDRJAzXIUzLxVvIcZxqVz8cXgXYiP30V3uimfmqxRUvVnpkVxE/gt/skRJrmese/1Vos80xvaIsLUdXAa2CSJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QnPckwdgpBUr+17cYI0AaPCAdJVEhHccUrVHQZ13anc=;
 b=Ypvvo1HoA5/q5hl9L17oXDuZyKC+M+GEHBO6zmHkNXggiOIXIWo55gS+sXPp3BoS39kvsiX7n5aHj1f6qNCeDd99KoGZeOhBquodJGQil5PJoi1RT8HooxbgDlKnbY9ayWHSaTl3c8tBcUzpXv8B+n8iic4IGkD2z6xLQBaMgZr/Y6/tvbV7Y1zEY5j33+Q/Qg24dA43fDDmexWkP+7dLDaZlib2x0gbwyB0LZFwL/QfxO2loYQjxadGTpfCf4M8cQWlwrfroIos8sMJHBqJ9VQNL69/NfQM6WWGAwlbKDrlyZJAc2sj/7BtB3G4e+ttPwFhogr3r4z0TQ9SGi1GVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QnPckwdgpBUr+17cYI0AaPCAdJVEhHccUrVHQZ13anc=;
 b=iBpcHWBE5Lm65ugVx2tKzi7IkTC0gQ4Zs8D/WMjxOVFZOoYgT8MBx8E+4xEpjGgHFkv7aa5IStfQjnBl8yhMejjZovBgnD8y86OKsMRYyrjmVS63es6ws93rixVi3QqnUvYfN/GpaYXz1n4smGoa8RpatpRfeh7RRGx6l53l/WSxsVmjajalnzoMMqVQTZIzC4LFd03tUK0nQ2Q+SNMxLVu+RVA3wruNjMI3YJ5nFkaU7gcB/ip2wKD5rZ/1+8JLnWR+dnopdbNR91LsFxEzMQGAGylKl7BQXEhLtqxHEmRezBWfZQ35UvwNnbDl74PeCdciNcTSiSw0+6M4PSusEA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Jens Wiklander <jenswi@kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 07/13] xen/arm: ffa: fix notification SRI across CPU hotplug/suspend
Date: Thu, 27 Aug 2026 17:31:55 +0300
Message-ID: <cc10888f34e887f739d66312aa871a6df4196204.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 635f6972-d062-43c8-e4be-08df04480617
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	YTxdvptslBbperyDASZj4ZMhQxFzzBDxxcotiyaVQhr1mCLt3MuHXRgCK0JIZV01IyJ2CDqSln76kST/cZTaS2CZKBJ/t4AjIKXXbwY9t2913JFvtwMHIXnIXitFiPFm/JQ7wRZKmRSCP3A0owUUt0YBdUKgzG6vFD25qD9RI0wk4ZiioQh8gRgi36PXSHeNz1DDt1Zy5jDeeCGVkKS1+ltHrr3TF+7WkePUcXiQYkYlD02bLfHYhQKsBo4sKH13r9lQybV7NBJNAQl0yD+DUhMVop7oHak/b6RD1kg9Fr+tHJp+4Xk/MA6e8MS9nDL/BNrhi2/fivD6cWVn2ANLcNii3fdOBzgtAyhbP/jKscvPuBSFLVEv4FdZZ90XVNy9A6g/OmUxojlVYLuePTFgRTI1omnwFGTpu25aPSWFEPnO44narNsl18oxdNaNLJ3BeLRes7CEgxZvljjLlLNyOAN9ySZ396upkOysqkSRQP744nkQmm7KjcouDy6H2qqnkG4MDh6L77Ra5KehxZxDhxB54OIzyO8O7OvvE4pvoVUySxvactlM20NINsutJYh2P5W1MlU9QILNT00YL0RUf5zk+Sf853664PwWl5h1FZKyFC5xmnnkD8kQscjBIumBqpJHDXSt73+75vfKpiV1UCgksNFApwt2gjF049ZKRtg=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?84dF9ur3RfK7p6uyW3uUg2b8/lQCqtaZBn/VmjJzU39hPVMWYkcNpFq4nOz1?=
 =?us-ascii?Q?Q5AY27KmjyijsQihZojjnNG7ezavH5I3WRAjNM0AdM8X+hvM/UDlfAVMJ7s0?=
 =?us-ascii?Q?7HXWCVOLtuGnTA98kBPfpiJAsJzhH1XZDqyC4ZqFtGND1MLv14m8Fa+tgS0q?=
 =?us-ascii?Q?t+75YpVfnO9+3PjqyiNCdqgEb4epnIkmLiX3NTxexe0aaEKs99mARcJvrwMT?=
 =?us-ascii?Q?F2Q1SejyVWWLwUGLHVpTa2sZnMC4F978xVfp6Eb2VsHND/gq0lIr0QzU/54w?=
 =?us-ascii?Q?oQ5JgH7qrsz/uV7YquMY+kyt8CsV6w8R99ODG395QP93S/ooqEhAH4MhF3v9?=
 =?us-ascii?Q?YX8mKPoyvwU9LVxniAWllmATKAma3SGOl9xEIsv9cdcPMgBuCmJJElGUbL9v?=
 =?us-ascii?Q?e0fNFSKI/HjYm0Jiu9XyTjD4SLwr85jPSYIwPlGExKAhoCCzjRsE+ESi+rn7?=
 =?us-ascii?Q?TFg6gsrqM6BmRXeez4t0k/jWzHq9tqSKbdlW66YLkMRfzXYw2d+S9I/Zum2x?=
 =?us-ascii?Q?Bj2YVjR/CJ3yKsaF6millApJFlmrXELyrbqt+TwjijGEcz64v090B3DG7VZq?=
 =?us-ascii?Q?eKsZjpUKY92wAHOPF8UY940UR+TnS6qiWwLDGvQj0qFYD89NCCspzC9FUg8D?=
 =?us-ascii?Q?29FkQ6V8nWoJQtYHs40U+guj/3aHhAgVM6RGEeVZnBfJjGPepSNsO6TDze4j?=
 =?us-ascii?Q?I7oNpZ3STT3DEBLgj2JyWuGTSXFwoMbHnpVQSolBMrfyFEDYodf23W5K11zC?=
 =?us-ascii?Q?UFqXJ46ID0QwcfBb5+9nX94dtOGWq1913GPMOSPkVNZD6akYIcc2hCmqVnkD?=
 =?us-ascii?Q?J4BvXWxryriD4pRDYJMnB9UBQy513a1OAOUuDYel3BDclDXpzOVVBZlU8jT3?=
 =?us-ascii?Q?Da5BoMQ2GTG+kMezgc75zgAAOJ1IDgAcnUqIEos1C93F73cO5+cw7rqwY70e?=
 =?us-ascii?Q?wPTauDVVrNWpQPG501uv4kaQrS0SjC+zxcxTc/JU++215dYpfMkuVlMFSNjD?=
 =?us-ascii?Q?WoympmBawApi7/bAWTQjFJUvPtM4U8QNahF1CpCwX2nKrLtEpJYhzGUQ2uQ6?=
 =?us-ascii?Q?3ab10zX/a7BcdUpoC8XmwWcxYWX0Rd+QWaln94cs3DOxYs+ZZdiRjHTnH+EZ?=
 =?us-ascii?Q?Fxddt1YQCFAmsDW2U4dsPcwY7w3+96Bud7/FEDT5+ohXNTu7xDnc32szo/M0?=
 =?us-ascii?Q?5qU33nDeUE+LcPVcUPuSRARpExQDzcPfvO5XQBJOXUtR6vu4lv3kU+gIA1EY?=
 =?us-ascii?Q?3UFjswcQPmuyJbxFBi2bumrs3ATGk0Hm3m61yO84f0bS+Zr7Ws3uJ/wvNMeR?=
 =?us-ascii?Q?mj3nLCTs/Xd6woGqCT3TWDzQgWqfGM6wXD1HhfFflwiTnM0hb+LLaCmvSP/E?=
 =?us-ascii?Q?K4xZMwd96A5FE073kIAGb5EoqqH/QCtcuKOIcVLS8hT3Ee6MYVWzuTDW8DhB?=
 =?us-ascii?Q?dzFk4R4Rp4B8S3wRWFADfLb5N0W6ubgNZMvUni3Tap8zJSJHquI42s0nSoEw?=
 =?us-ascii?Q?K/0v1TOXcMCads8aeqoXiFD/YD/FzC6XhXbezxSgUSXjds0OQsILvZv6789W?=
 =?us-ascii?Q?ON/JlJOuI075WnuREnFMfOF/gSAPiRBUq9lPZ9wg5h4byD4oBwPYtCRzPJhU?=
 =?us-ascii?Q?oNy2P9rFb960aLcHTeptjvyV+vi0yRtha0j6xT6bkSL1rlaYeGl6YOVsQIDc?=
 =?us-ascii?Q?45nF1J6wApO2xrNvbQDCoB1OC31sH3Itn0FnOpPeplo7iNBAxcUThFZVJOgg?=
 =?us-ascii?Q?rifIbZOZKA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 635f6972-d062-43c8-e4be-08df04480617
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:29.7852
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: t7hrGfMHFvG02mSF/lrmphulIlH2F8a4IRaCIvH0oM8oqiYA/e1e8hhDfjOYjbgGers83Eh4RGRflFVP02NZeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-d25034/1787841151-50B3DA5B-A687D26B/0/0
X-purgate-type: clean
X-purgate-size: 3654

The FF-A notification SRI interrupt handler was not correctly tied to
CPU hotplug and suspend/resume. As a result, CPUs going offline and
back online could end up with stale or missing handlers, breaking
delivery of FF-A notifications.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
 xen/arch/arm/tee/ffa_notif.c | 63 ++++++++++++++++++++++++++++--------
 1 file changed, 50 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
index 186e726412..513c399594 100644
--- a/xen/arch/arm/tee/ffa_notif.c
+++ b/xen/arch/arm/tee/ffa_notif.c
@@ -360,10 +360,28 @@ static int32_t ffa_notification_bitmap_destroy(uint16_t vm_id)
     return ffa_simple_call(FFA_NOTIFICATION_BITMAP_DESTROY, vm_id, 0, 0, 0);
 }
 
-void ffa_notif_init_interrupt(void)
+static DEFINE_PER_CPU_READ_MOSTLY(struct irqaction, sri_irq);
+
+static int request_sri_irq(void)
 {
     int ret;
+    struct irqaction *sri_action = &this_cpu(sri_irq);
+
+    sri_action->name = "FF-A notif";
+    sri_action->handler = notif_irq_handler;
+    sri_action->dev_id = NULL;
+    sri_action->free_on_release = 0;
+
+    ret = setup_irq(notif_sri_irq, 0, sri_action);
+    if ( ret )
+        printk(XENLOG_ERR "ffa: setup_irq irq %u failed: error %d\n",
+               notif_sri_irq, ret);
 
+    return ret;
+}
+
+void ffa_notif_init_interrupt(void)
+{
     if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI )
     {
         /*
@@ -376,14 +394,36 @@ void ffa_notif_init_interrupt(void)
          * pending, while the SPMC in the secure world will not notice that
          * the interrupt was lost.
          */
-        ret = request_irq(notif_sri_irq, 0, notif_irq_handler, "FF-A notif",
-                          NULL);
-        if ( ret )
-            printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n",
-                   notif_sri_irq, ret);
+        request_sri_irq();
     }
 }
 
+static void deinit_ffa_notif_interrupt(void)
+{
+    if ( fw_notif_enabled && notif_sri_irq < NR_GIC_SGI )
+        release_irq(notif_sri_irq, NULL);
+}
+
+static int cpu_ffa_notif_callback(struct notifier_block *nfb,
+                                  unsigned long action,
+                                  void *hcpu)
+{
+    switch ( action )
+    {
+    case CPU_DYING:
+        deinit_ffa_notif_interrupt();
+        break;
+    default:
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_ffa_notif_nfb = {
+    .notifier_call = cpu_ffa_notif_callback,
+};
+
 void ffa_notif_init(void)
 {
     const struct arm_smccc_1_2_regs arg = {
@@ -392,7 +432,6 @@ void ffa_notif_init(void)
     };
     struct arm_smccc_1_2_regs resp;
     unsigned int irq;
-    int ret;
 
     /* Only enable fw notification if all ABIs we need are supported */
     if ( ffa_fw_supports_fid(FFA_NOTIFICATION_BITMAP_CREATE) &&
@@ -408,13 +447,11 @@ void ffa_notif_init(void)
         notif_sri_irq = irq;
         if ( irq >= NR_GIC_SGI )
             irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
-        ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
-        if ( ret )
-        {
-            printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n",
-                   irq, ret);
+
+        if ( request_sri_irq() )
             return;
-        }
+
+        register_cpu_notifier(&cpu_ffa_notif_nfb);
         fw_notif_enabled = true;
     }
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400681.1636297 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9f-0006M5-D6; Thu, 27 Aug 2026 14:32:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400681.1636297; Thu, 27 Aug 2026 14:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9f-0006Lo-6q; Thu, 27 Aug 2026 14:32:35 +0000
Received: by outflank-mailman (input) for mailman id 1400681;
 Thu, 27 Aug 2026 14:32:33 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9d-000655-BK
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9c-000Qzn-Nv
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:32 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a71-e002-0a2a0a5209dd-0a2a45078350-46
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:32 +0200
Received: from [52.101.84.104]
 (helo=DB3PR0202CU003.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a80-b4ea-0a2a45070019-346554687891-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:32 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:31 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:31 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=XgR+T40kyNu2uPG/6CD/7cerSnrv9mwZ36ATtthtamrMq9DTAmiomCv21YwMbR4B+hLBbbkJAU4TfhXiNYQ+hWgV4qCWONqAvQJMh1yz/1DHqozze71qa8r43pvldGRA8G26sMjjfMMT7dV37/0FDnJSJRCcLeLvCt38xeAs/YiRR5o3y6lpuwaRxQ+wYqAF+jo0K1XjtLxaB1sxpND0rcyXkjdKk3qryx6uEnJVvpr0UuYGgJeWVwlFdFnBBZbQg0EomHiXb3O7Oe9cOl+ETkktpkln1ANPVV8y0BDIpgI7jLiPUPihTv6C2dkTOQZ4YHiibL9siYSk3iReXmDgrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nQ4kNGerzyiusut8IWEJPjH9AN7FUvIvVDuMBpOnlU4=;
 b=tFAXYNcJS1R4/eYNwMrx4WRBAdTGjT04f6va93hg3ieggVlmCZfY2uqRlAZ9woqbwGeRn4PDXyTnwi/CuZNeW4v48KWIWv7uPRdu8r/q5AuKT+V+PRTybn5sBTo6Pdn0/8a5VBl/Gw8x9c8QCBQx7VzPsj32RN2Ac4Aa/lwQGTlwCSTkN2zio580epB7IPS40MvZ/1+fLr5u5tPlTrx+ni/wFGndPYR5xEKmila0k1ZrCxXkumZPwhEHrX1NZU3ggHlKtrNTJaAkj9QQ4zTXeGMG2hiLh9AhWglkg+5vYY9yiSA72fbF/NkxiLZx0Suyf03RGcLLLy3/jw1eOruJ9w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nQ4kNGerzyiusut8IWEJPjH9AN7FUvIvVDuMBpOnlU4=;
 b=c5awiz07rnJlCPmkeNHcYyWnRIzqlXbkxzVDT0Iw+HUgpj1T6t0eIJrgy7zS39VSEnsGQrQpfy6JPJ/kCiLuUYQv5gfgBQFizH3x/eNhyqoCdkl5uS/2pgdVKQxSLzkHhHcTp1kFR8hH4cPs0cNgU5c4jtzyiB0l3PZNqluPDiU+cvPL3i8Xf8AuGXXmJtJV4OlzOeXGYIU1IY0mx0t4uc3jw6jZTXPw3fCN3yyGx0E2dsXPfFmqbnkRal9QqZ5FXnKnwiJgILRQXldu4ncALCDiqdnvuXKJhR6oCLmHXkvD7fIB2iD+mLHPo8PsgNYeG6Dp6SYkxBkWCIe+UL9Ewg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 08/13] iommu/ipmmu-vmsa: Implement suspend/resume callbacks
Date: Thu, 27 Aug 2026 17:31:56 +0300
Message-ID: <1f036e7ad5ad6efba635ca029b0fab133300603a.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 69b8b2f8-a490-431e-f4ee-08df044806d4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|5023799004|56012099006;
X-Microsoft-Antispam-Message-Info:
	b/b0Fk8pmKp8Y7yVdlOMNtSPjvEVn/SzMLBQg44KSoPnI6VUyHqvZgRbKt6ENKexfT5W/ST/qJDxyLN8IFeuSumdf+3NbZYMosprWnsre4kSQYgjQLEtDVaVd6sl/DWQQIqFHN5CujCjBNQ/wB5hTNkeeeIEu0Vgx4fzB9ZHTEtuhbbqeKLc75VJhEqo/N7xpRNMCKSOJFPq1mzBsHJm7Je9U8yn/cDN2AM9xlmlMoBhy1/QC+6nhKuWpKbeiJq71OSdUIVmhqmT0c1wRBHLVIAir3W34lNKTcIWlxP6HT3NFe87VrL5D+mFdxrsEgAuhRnRr01T+aQPzyLh/A8VqxUz0urlEqIo0WwSDjDqoMtcNkM66BzZOqoC6HajR+cGQt94M7vO+JhJXtLGJbWIzMVakLt2iPLt7/kPgeWBEzRs0dabBmrn8tydpxdu73ZRibFl/BYxaEC1DVlV4vLUhT6QgRQ2/SooqveMaiRvxcylxq+A6iL8OklNPwOrCx89PQHnnZdM/WY5FQ8VsX6yUW3hyJ2dCxmqLZlSSWmtL2lfr83L7JSa+dB5fHeh1E5/0I6UDPpRWkkg3ulR96vhbuz1uMWoMBHi7pLiPunmPRIudp2/hHw+cdsfV08YQVcuuFp5zX117Ruhy/voRA9YDnDmXAO+onHfQdlGgG/5yek=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(5023799004)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?1w6LC8jBmY3mv6QeFrbOfkt+ZUvekdW8ATObaGxUBb9nGggljULSFHZhpHfY?=
 =?us-ascii?Q?yoS+jgIwJlSCNabWIpNV61XjOpCJr1ueeWnPEdi7c61AhX+N+g5CLfd2EgCV?=
 =?us-ascii?Q?eHPcCDv1aIs+CgtN8jk+8F07+wvPOzdNv80IA1U82JjTJbJK23qZnL7+YjaA?=
 =?us-ascii?Q?SBcItMWcKxNJkqSLqRo4+HXI3NfqrehTVNpGDp3Pic62L90nbSQ2nj7Hh/ab?=
 =?us-ascii?Q?LxNF3zM9DJvBm3yYavr5/2K4hSGw+lg+pvkFa5/5ojZ+JLyyXDdlamf2fiTb?=
 =?us-ascii?Q?35WgOJyBATcpmFbrvhIpKK1Vv4EULp3CL7OkZ53+taXPVWQGiCDAbQIsZaCM?=
 =?us-ascii?Q?lXNjVy+amuWzxE3cyASzEvPdhAmUiCOm+R+w0uItErykFkx2qZhhfA3AY4yf?=
 =?us-ascii?Q?qBXuFRf0S1iEoXZS6HQA8RHOOalLHrMbhLrdfY7K+pG1aNcPSjTYf9bN4MSG?=
 =?us-ascii?Q?zdrVRRUq94asgYPMQ+9Wb5xspZF1naPhd64Mx6m2A+4nqShVGFwdRMsduNFD?=
 =?us-ascii?Q?wPVAWRTiiLqPSPSMvHqax1+ysFf5J0d1QJTJ2uXUzRpemKSnmgfyEAkRWfy8?=
 =?us-ascii?Q?9s39I9jU8kd/FvBDj7GfpgQXp/rJ77oY8R/B+HHEnaSnL6IGOwlUPjfE2vyn?=
 =?us-ascii?Q?A5lHR5qEjC0vcoFn9gYLOaCvWFN7zQLS86KFFtRyWm1m1LH63dU1CkyEwDxS?=
 =?us-ascii?Q?ois7NvHSctLl4SBvqXQ6Hu4SUC/stejrd2kMKTNcuaCqoAC9lYlsYvXhWYIk?=
 =?us-ascii?Q?3Ttc0K5TZZGRt6thfeSXCwu/lj1OwxUe/tU6kC3Al5GYDEjw6cDRsEqYDOVe?=
 =?us-ascii?Q?Xia0FXDBFMaixhgp4twW2ZTdATQ/yj3bbSxi0wfQU+FNhWuzBMYajpiAWnqi?=
 =?us-ascii?Q?89w7XsBXVB/HrtOZgHDzZIl5Knzj4f1ozcUoCWXzgNU56A+IfuYB65aJJirH?=
 =?us-ascii?Q?IVpdSGMzt1CcywzbO8F1DPQRpq8xCG8jG9O0LGfnMfcIx3I9dKLuHy6YEDIh?=
 =?us-ascii?Q?uvyniSZfOunoUSmTM/X2bUZIiZSwrUtgKwAn8dmnUo1S7XnVL5EW70mZVO0B?=
 =?us-ascii?Q?QG5YSoukRbdq7kKaVyoFh9AZXTrXhBnSRfeDvScjVcVgTQyKKAOJaDwRMkyd?=
 =?us-ascii?Q?PBJmqJvvRnjFQpcY+NoyLuTEdasmkUaNApJily+NhIxvZncsMy8fQc4SdXbf?=
 =?us-ascii?Q?oUV9iB6OPIju71/L9pp3/9soeU0AvLfznAxJN/BqNpc8SmN8eUIU+hKx7NIc?=
 =?us-ascii?Q?ScR50YTwHlrxbm/di5idcXSMw/NzgbydV3iYX3MTGa8Nenrq+/gWfqchgPtm?=
 =?us-ascii?Q?YEj6irJRrQEEdzdbtyI/boCUTrm8D4eofaavIzH9pjFHdVdHWzvMM1UfZv2q?=
 =?us-ascii?Q?wKuJXWHLOciZQhLCNoG7J/7EtzkKiaxzkgowrRKhdKb7F66EaGjLbtNt8P6C?=
 =?us-ascii?Q?wSEc27AtV9ZI+N5NCNksn2D/2+10hgwgN/twQg8BAIX997SRl1KoM6VgCsBu?=
 =?us-ascii?Q?6crffB0LnbWPPxfZoLF/59TVg1GM7be0o7q1i5SWI/I6WNDqCTtGjEQQvnNW?=
 =?us-ascii?Q?1pLKBG/Q7msG8MD9+/uUYChKqDEYsn3nf1LdtYXy3OM4K1lzR0yEtKKmBvQp?=
 =?us-ascii?Q?k/qVXk5Or1T6WfXbJUjzObV81ITgDkIaWmOu+/t9BKDynhv8ZFcrlplu5Ayi?=
 =?us-ascii?Q?mzZl1vVkSbhkj6J9alrm0P3D1pC5AMJ+BTDN3HJqYMVWreFebS223Ecmal9Y?=
 =?us-ascii?Q?ZAnpLy/5HQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69b8b2f8-a490-431e-f4ee-08df044806d4
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:30.9850
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6vuYLpc5vxwCGdmzgFgjT5NgKF0WrkjXmYftpDMzyX9qBFYc33x3YY/NQ/TwOJOVk42w0tzQtBHweIQcukYrmA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-ef75cf/1787841152-A58C1AE4-2B60E912/0/0
X-purgate-type: clean
X-purgate-size: 14456

From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Store and restore active context and micro-TLB registers.

On resume, restore Root IPMMU context state before restoring Cache IPMMU
micro-TLB state. Cache IPMMUs select Root contexts through their micro-TLB
configuration, so restoring Cache micro-TLBs before the Root context
registers are restored can expose stale or uninitialized context state.

Tested on R-Car H3 Starter Kit.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in V10:
- Iterate over registered IPMMUs in reverse order during resume so Root IPMMU
  context state is restored before Cache IPMMU micro-TLB state.

Changes in V9:
- set dt_device_set_protected() only after ipmmu_alloc_ctx_suspend()
  succeeds, so DT devices do not remain protected on allocation failure.

Changes in V7:
- moved suspend context allocation before pci stuff
---
 xen/drivers/passthrough/arm/ipmmu-vmsa.c | 323 +++++++++++++++++++++--
 1 file changed, 308 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
index fa9ab9cb13..2e54fa63d6 100644
--- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
+++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
@@ -71,6 +71,8 @@
 })
 #endif
 
+#define dev_dbg(dev, fmt, ...)    \
+    dev_print(dev, XENLOG_DEBUG, fmt, ## __VA_ARGS__)
 #define dev_info(dev, fmt, ...)    \
     dev_print(dev, XENLOG_INFO, fmt, ## __VA_ARGS__)
 #define dev_warn(dev, fmt, ...)    \
@@ -130,6 +132,24 @@ struct ipmmu_features {
     unsigned int imuctr_ttsel_mask;
 };
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+struct ipmmu_reg_ctx {
+    unsigned int imttlbr0;
+    unsigned int imttubr0;
+    unsigned int imttbcr;
+    unsigned int imctr;
+};
+
+struct ipmmu_vmsa_backup {
+    struct device *dev;
+    unsigned int *utlbs_val;
+    unsigned int *asids_val;
+    struct list_head list;
+};
+
+#endif
+
 /* Root/Cache IPMMU device's information */
 struct ipmmu_vmsa_device {
     struct device *dev;
@@ -142,6 +162,9 @@ struct ipmmu_vmsa_device {
     struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX];
     unsigned int utlb_refcount[IPMMU_UTLB_MAX];
     const struct ipmmu_features *features;
+#ifdef CONFIG_SYSTEM_SUSPEND
+    struct ipmmu_reg_ctx *reg_backup[IPMMU_CTX_MAX];
+#endif
 };
 
 /*
@@ -547,6 +570,249 @@ static void ipmmu_domain_free_context(struct ipmmu_vmsa_device *mmu,
     spin_unlock_irqrestore(&mmu->lock, flags);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+static DEFINE_SPINLOCK(ipmmu_devices_backup_lock);
+static LIST_HEAD(ipmmu_devices_backup);
+
+static struct ipmmu_reg_ctx root_pgtable[IPMMU_CTX_MAX];
+
+static uint32_t ipmmu_imuasid_read(struct ipmmu_vmsa_device *mmu,
+                                   unsigned int utlb)
+{
+    return ipmmu_read(mmu, ipmmu_utlb_reg(mmu, IMUASID(utlb)));
+}
+
+static void ipmmu_utlbs_backup(struct ipmmu_vmsa_device *mmu)
+{
+    struct ipmmu_vmsa_backup *backup_data;
+
+    dev_dbg(mmu->dev, "Handle micro-TLBs backup\n");
+
+    spin_lock(&ipmmu_devices_backup_lock);
+
+    list_for_each_entry( backup_data, &ipmmu_devices_backup, list )
+    {
+        struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev);
+        unsigned int i;
+
+        if ( to_ipmmu(backup_data->dev) != mmu )
+            continue;
+
+        for ( i = 0; i < fwspec->num_ids; i++ )
+        {
+            unsigned int utlb = fwspec->ids[i];
+
+            backup_data->asids_val[i] = ipmmu_imuasid_read(mmu, utlb);
+            backup_data->utlbs_val[i] = ipmmu_imuctr_read(mmu, utlb);
+        }
+    }
+
+    spin_unlock(&ipmmu_devices_backup_lock);
+}
+
+static void ipmmu_utlbs_restore(struct ipmmu_vmsa_device *mmu)
+{
+    struct ipmmu_vmsa_backup *backup_data;
+
+    dev_dbg(mmu->dev, "Handle micro-TLBs restore\n");
+
+    spin_lock(&ipmmu_devices_backup_lock);
+
+    list_for_each_entry( backup_data, &ipmmu_devices_backup, list )
+    {
+        struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(backup_data->dev);
+        unsigned int i;
+
+        if ( to_ipmmu(backup_data->dev) != mmu )
+            continue;
+
+        for ( i = 0; i < fwspec->num_ids; i++ )
+        {
+            unsigned int utlb = fwspec->ids[i];
+
+            ipmmu_imuasid_write(mmu, utlb, backup_data->asids_val[i]);
+            ipmmu_imuctr_write(mmu, utlb, backup_data->utlbs_val[i]);
+        }
+    }
+
+    spin_unlock(&ipmmu_devices_backup_lock);
+}
+
+static void ipmmu_domain_backup_context(struct ipmmu_vmsa_domain *domain)
+{
+    struct ipmmu_vmsa_device *mmu = domain->mmu->root;
+    struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id];
+
+    dev_dbg(mmu->dev, "Handle domain context %u backup\n", domain->context_id);
+
+    regs->imttlbr0 = ipmmu_ctx_read_root(domain, IMTTLBR0);
+    regs->imttubr0 = ipmmu_ctx_read_root(domain, IMTTUBR0);
+    regs->imttbcr  = ipmmu_ctx_read_root(domain, IMTTBCR);
+    regs->imctr    = ipmmu_ctx_read_root(domain, IMCTR);
+}
+
+static void ipmmu_domain_restore_context(struct ipmmu_vmsa_domain *domain)
+{
+    struct ipmmu_vmsa_device *mmu = domain->mmu->root;
+    struct ipmmu_reg_ctx *regs = mmu->reg_backup[domain->context_id];
+
+    dev_dbg(mmu->dev, "Handle domain context %u restore\n", domain->context_id);
+
+    ipmmu_ctx_write_root(domain, IMTTLBR0, regs->imttlbr0);
+    ipmmu_ctx_write_root(domain, IMTTUBR0, regs->imttubr0);
+    ipmmu_ctx_write_root(domain, IMTTBCR,  regs->imttbcr);
+    ipmmu_ctx_write_all(domain,  IMCTR,    regs->imctr | IMCTR_FLUSH);
+}
+
+/*
+ * Xen: Unlike Linux implementation, Xen uses a single driver instance
+ * for handling all IPMMUs. There is no framework for ipmmu_suspend/resume
+ * callbacks to be invoked for each IPMMU device. So, we need to iterate
+ * through all registered IPMMUs performing required actions.
+ *
+ * Also take care of restoring special settings, such as translation
+ * table format, etc.
+ */
+static int __must_check ipmmu_suspend(void)
+{
+    struct ipmmu_vmsa_device *mmu;
+
+    if ( !iommu_enabled )
+        return 0;
+
+    printk(XENLOG_DEBUG "ipmmu: Suspending...\n");
+
+    spin_lock(&ipmmu_devices_lock);
+
+    list_for_each_entry( mmu, &ipmmu_devices, list )
+    {
+        if ( ipmmu_is_root(mmu) )
+        {
+            unsigned int i;
+
+            for ( i = 0; i < mmu->num_ctx; i++ )
+            {
+                if ( !mmu->domains[i] )
+                    continue;
+                ipmmu_domain_backup_context(mmu->domains[i]);
+            }
+        }
+        else
+            ipmmu_utlbs_backup(mmu);
+    }
+
+    spin_unlock(&ipmmu_devices_lock);
+
+    return 0;
+}
+
+static void ipmmu_resume(void)
+{
+    struct ipmmu_vmsa_device *mmu;
+
+    if ( !iommu_enabled )
+        return;
+
+    printk(XENLOG_DEBUG "ipmmu: Resuming...\n");
+
+    spin_lock(&ipmmu_devices_lock);
+
+    /*
+     * IPMMUs are registered with list_add(), with Root IPMMU probed first.
+     * Walk backwards to restore Root contexts before Cache micro-TLBs.
+     */
+    list_for_each_entry_reverse( mmu, &ipmmu_devices, list )
+    {
+        uint32_t reg;
+
+        /* Do not use security group function */
+        reg = IMSCTLR + mmu->features->control_offset_base;
+        ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP);
+
+        if ( ipmmu_is_root(mmu) )
+        {
+            unsigned int i;
+
+            /* Use stage 2 translation table format */
+            reg = IMSAUXCTLR + mmu->features->control_offset_base;
+            ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) | IMSAUXCTLR_S2PTE);
+
+            for ( i = 0; i < mmu->num_ctx; i++ )
+            {
+                if ( !mmu->domains[i] )
+                    continue;
+                ipmmu_domain_restore_context(mmu->domains[i]);
+            }
+        }
+        else
+            ipmmu_utlbs_restore(mmu);
+    }
+
+    spin_unlock(&ipmmu_devices_lock);
+}
+
+static int ipmmu_alloc_ctx_suspend(struct device *dev)
+{
+    struct ipmmu_vmsa_backup *backup_data;
+    unsigned int *utlbs_val, *asids_val;
+    struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+    utlbs_val = xzalloc_array(unsigned int, fwspec->num_ids);
+    if ( !utlbs_val )
+        return -ENOMEM;
+
+    asids_val = xzalloc_array(unsigned int, fwspec->num_ids);
+    if ( !asids_val )
+    {
+        xfree(utlbs_val);
+        return -ENOMEM;
+    }
+
+    backup_data = xzalloc(struct ipmmu_vmsa_backup);
+    if ( !backup_data )
+    {
+        xfree(utlbs_val);
+        xfree(asids_val);
+        return -ENOMEM;
+    }
+
+    backup_data->dev = dev;
+    backup_data->utlbs_val = utlbs_val;
+    backup_data->asids_val = asids_val;
+
+    spin_lock(&ipmmu_devices_backup_lock);
+    list_add(&backup_data->list, &ipmmu_devices_backup);
+    spin_unlock(&ipmmu_devices_backup_lock);
+
+    return 0;
+}
+
+#ifdef CONFIG_HAS_PCI
+static void ipmmu_free_ctx_suspend(struct device *dev)
+{
+    struct ipmmu_vmsa_backup *backup_data, *tmp;
+
+    spin_lock(&ipmmu_devices_backup_lock);
+
+    list_for_each_entry_safe( backup_data, tmp, &ipmmu_devices_backup, list )
+    {
+        if ( backup_data->dev == dev )
+        {
+            list_del(&backup_data->list);
+            xfree(backup_data->utlbs_val);
+            xfree(backup_data->asids_val);
+            xfree(backup_data);
+            break;
+        }
+    }
+
+    spin_unlock(&ipmmu_devices_backup_lock);
+}
+#endif /* CONFIG_HAS_PCI */
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain)
 {
     uint64_t ttbr;
@@ -559,6 +825,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain)
         return ret;
 
     domain->context_id = ret;
+#ifdef CONFIG_SYSTEM_SUSPEND
+    domain->mmu->root->reg_backup[ret] = &root_pgtable[ret];
+#endif
 
     /*
      * TTBR0
@@ -615,6 +884,9 @@ static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
     ipmmu_ctx_write_root(domain, IMCTR, IMCTR_FLUSH);
     ipmmu_tlb_sync(domain);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+    domain->mmu->root->reg_backup[domain->context_id] = NULL;
+#endif
     ipmmu_domain_free_context(domain->mmu->root, domain->context_id);
 }
 
@@ -1338,10 +1610,11 @@ static int ipmmu_add_device(u8 devfn, struct device *dev)
     struct iommu_fwspec *fwspec;
 
 #ifdef CONFIG_HAS_PCI
+    int ret;
+
     if ( dev_is_pci(dev) )
     {
         struct pci_dev *pdev = dev_to_pci(dev);
-        int ret;
 
         if ( devfn != pdev->devfn )
             return 0;
@@ -1358,17 +1631,24 @@ static int ipmmu_add_device(u8 devfn, struct device *dev)
     if ( !to_ipmmu(dev) )
         return -ENODEV;
 
-    if ( !dev_is_pci(dev) )
+    if ( !dev_is_pci(dev) && dt_device_is_protected(dev_to_dt(dev)) )
     {
-        if ( dt_device_is_protected(dev_to_dt(dev)) )
-        {
-            dev_err(dev, "Already added to IPMMU\n");
-            return -EEXIST;
-        }
+        dev_err(dev, "Already added to IPMMU\n");
+        return -EEXIST;
+    }
 
-        /* Let Xen know that the master device is protected by an IOMMU. */
-        dt_device_set_protected(dev_to_dt(dev));
+#ifdef CONFIG_SYSTEM_SUSPEND
+    if ( ipmmu_alloc_ctx_suspend(dev) )
+    {
+        dev_err(dev, "Failed to allocate context for suspend\n");
+        return -ENOMEM;
     }
+#endif
+
+    /* Let Xen know that the master device is protected by an IOMMU. */
+    if ( !dev_is_pci(dev) )
+        dt_device_set_protected(dev_to_dt(dev));
+
 #ifdef CONFIG_HAS_PCI
     if ( dev_is_pci(dev) )
     {
@@ -1377,26 +1657,28 @@ static int ipmmu_add_device(u8 devfn, struct device *dev)
         struct pci_host_bridge *bridge;
         struct iommu_fwspec *fwspec_bridge;
         unsigned int utlb_osid0 = 0;
-        int ret;
 
         bridge = pci_find_host_bridge(pdev->seg, pdev->bus);
         if ( !bridge )
         {
             dev_err(dev, "Failed to find host bridge\n");
-            return -ENODEV;
+            ret = -ENODEV;
+            goto free_suspend_ctx;
         }
 
         fwspec_bridge = dev_iommu_fwspec_get(dt_to_dev(bridge->dt_node));
         if ( fwspec_bridge->num_ids < 1 )
         {
             dev_err(dev, "Failed to find host bridge uTLB\n");
-            return -ENXIO;
+            ret = -ENXIO;
+            goto free_suspend_ctx;
         }
 
         if ( fwspec->num_ids < 1 )
         {
             dev_err(dev, "Failed to find uTLB");
-            return -ENXIO;
+            ret = -ENXIO;
+            goto free_suspend_ctx;
         }
 
         rcar4_pcie_osid_regs_init(bridge);
@@ -1405,7 +1687,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev)
         if ( ret < 0 )
         {
             dev_err(dev, "No unused OSID regs\n");
-            return ret;
+            goto free_suspend_ctx;
         }
         reg_id = ret;
 
@@ -1420,7 +1702,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev)
         {
             rcar4_pcie_osid_bdf_clear(bridge, reg_id);
             rcar4_pcie_osid_reg_free(bridge, reg_id);
-            return ret;
+            goto free_suspend_ctx;
         }
     }
 #endif
@@ -1429,6 +1711,13 @@ static int ipmmu_add_device(u8 devfn, struct device *dev)
              dev_name(fwspec->iommu_dev), fwspec->num_ids);
 
     return 0;
+#ifdef CONFIG_HAS_PCI
+ free_suspend_ctx:
+#ifdef CONFIG_SYSTEM_SUSPEND
+    ipmmu_free_ctx_suspend(dev);
+#endif
+    return ret;
+#endif
 }
 
 static int ipmmu_iommu_domain_init(struct domain *d)
@@ -1490,6 +1779,10 @@ static const struct iommu_ops ipmmu_iommu_ops =
     .unmap_page      = arm_iommu_unmap_page,
     .dt_xlate        = ipmmu_dt_xlate,
     .add_device      = ipmmu_add_device,
+#ifdef CONFIG_SYSTEM_SUSPEND
+    .suspend         = ipmmu_suspend,
+    .resume          = ipmmu_resume,
+#endif
 };
 
 static __init int ipmmu_init(struct dt_device_node *node, const void *data)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400682.1636300 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9g-0006SA-0D; Thu, 27 Aug 2026 14:32:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400682.1636300; Thu, 27 Aug 2026 14:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9f-0006R8-PI; Thu, 27 Aug 2026 14:32:35 +0000
Received: by outflank-mailman (input) for mailman id 1400682;
 Thu, 27 Aug 2026 14:32:34 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9e-0006D8-Iy
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9d-000Qzn-Vt
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:34 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a7e-e002-0a2a0a5209dd-0a2a450b8194-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:33 +0200
Received: from [52.101.84.125]
 (helo=DB3PR0202CU003.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a81-b7e8-0a2a450b0019-3465547d8cc2-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:33 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:32 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:32 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Tg73x7On4MakVVR3vXUCenc720XoGuALxaNsGPwhs/p+6EUlV+gfT8VLrqyCYyL0w3C+mz7TFffsk1+qb3fMgmC+yPtrX16up8HsddwtKYALpA8b2cY/F/FzweeYK4a+ZGjbGwpTEAjrzWosVKgd3F9Qkxrr937Dbylm1oIGPECxSq1aUcNyMfQbw9cJm+99U8XV3CPs5COS3bbtMfgBzkcEqa7pEFqhFudIBae392mMjt+267qoVKiw9QGUIWY6Tqm1F/UYcs6Y2aVtDBFNDHHWx3dsLhAn5n6sZqwiroJbYHL/u4wyd7NSdzjIitDdK/8LwgpQn2Y86KuscNhg6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=zuU9qIia0v/KlFmfmQr2PfYUlwI141FZNiLujMqRB9A=;
 b=WLOvlcsnYEZIcrT2HpE0VZ6rfZXSjocAus4d2OdfnJQ8vexYLcM/m1hLxfzguJezCHrPuO6G1l4PrzqkHOh7ckvTARbdnuRhrRaMFFBfrgh3wxJziEh9nlUlmrqJtD/gP4z6WjiLK6f3tAhgxaKustmT8JC3Ku7uLlNyXXVfcnRxDiFpxaTOxDnMpEwnZ9eH0hpTygU3c01hKCBz88Y0nKWl3sGPk3TPIfV/H6WnE21YucQML1dhMKrW/4txNncyITdCXuhsQ5AsDIkRXCIDVPFQ9Lni6iop0/AeflkdErQAxMkyV1cyyavBB8CdZmnJJF1j4UtZWDjrQH2bR9n7yQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zuU9qIia0v/KlFmfmQr2PfYUlwI141FZNiLujMqRB9A=;
 b=B4XJR4yon2vJ9zqHsHms1XZ4NeRSXo61PPfs44CwER3bb1CqCoU+WzEPsiLZPJAq8fxoo5M7u8HUGVLUXa39cBAJrlA5odgLrdPXRzLul5tcJO0W4qhDflGOOIgiELfvXzdjvailsXNR2QIKnJNJCh+4ug/3DffyaqYvstld0FPv+izecYApEbVZSS6XElDHSOnBjGGzOINMyBtcOKWyZ0vjJrity5K/FJ76nDY7Se3BBNKIFras+BOWl0vVadqYwg4eSpeBYoNkse6LOCmWToX6DTy7PTUDu1FvU9aq08JVrowsqSFGMbv7IhjGIuS7srgTO+kSW0BPWapIcQry9Q==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Rahul Singh <rahul.singh@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Pranjal Shrivastava <praan@google.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 09/13] xen/arm: smmu-v3: add suspend/resume handlers
Date: Thu, 27 Aug 2026 17:31:57 +0300
Message-ID: <388056532b9d11c1db1631c1b8385b317ec46e02.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 623f5751-dad1-426e-dc6c-08df0448079d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|3023799007|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	XhAB9+8CRvop6gFxzQHjh/39JWxKqUMbN8Gb+1VhhD1SZZSgjKIutyy+tYvTyCmpg+rcXnrlObiBNsxb2OfJgXWKGelg6ttw6JhPONTiJ5+Rfs2RgrVm4Y1jysIerDrUM7jso09HXjIgH3yrMVpwvh0JIsgBw6gTmhvgBe892eX2htD7zzFVKXqSW4dUfQqaACL6AmoLcnRQsBmBr8Ib1a3kjKUCKw+EF7x/EnQK2Vj31fieqrgsLHTIWhZP5Er1d8CAehd6V8wgND2VRZLXBAUInNeXqY+iLhkRnG3ytr2iRARNqGRB+Zw0sHR+LFnEE9b+63p7BeHdDkecBtTaf9b4gkjct+Ncsro0HaKzy9eIvrNhjsGD5Rt+JYZMovu2TtxY7fsi90MY4W71MehlAnbFPMwd9ldLmBzZ1rougGVENPrI/gUVgUHkOFXaX2rFtKeqtAj/Xf5PgED44qUCX2usifUGgUTC5X5PITaIDiEFWl9IZoHh4hZ2MBhKki8e9fyNp4cczILsfZQuwhW++AFiKKIIqjvAi/pl971N3iByxGlzIb8oaV0yKFaoUDrrVIt9XTPO0kVm2BRTRuDwtGRWoQt9uzlsRuRkSrisUSDBV8gNRa2nizgcUGwMVq72
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(3023799007)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Z3CuWTzOviG1hcj8hc7zr3QMf4df4+TenEV1OK/4mRhJe60y+uX/TTdwLWvB?=
 =?us-ascii?Q?Bm7v59WSkGLQaEc4Sn6qa43z9Q69fDJ1VUZY2aLgYM1SSNZYpir7KEare0Zb?=
 =?us-ascii?Q?4MGwRb0JqnEPC/GLyi4xvvnrrRvJZlcDkfhTSHDQDxCMqHHv6QlW0oBKJANW?=
 =?us-ascii?Q?tDZ6HDuwUZuXS6FXyVa3YQZi+UYcGdaptHsC1GIRZ0C12T6I+uWKGHJI/fyA?=
 =?us-ascii?Q?3YDMGE8fNxWCsTgpFHUqEAchL5bjH8t47wvm3HAE2CU8s3TXOpW9LMCFkYOm?=
 =?us-ascii?Q?96rq3+pjujobDzlcRlyr1jK9H1dGjANcNzBJ+I59GU5dWH13IHPH+Lg7Srhw?=
 =?us-ascii?Q?mG5fCY3jukts04juoTHCrCt9/2RNcldx4LzwC0JlkNKwxRl0b6dwN53kCDhu?=
 =?us-ascii?Q?oTt0TN/0Mutc/SoyeLA9ZfTLS5Y9+T55C6gBf/I/7nQEZu7FWNyOGcSiE7Xa?=
 =?us-ascii?Q?D7+fZ0dIFBjtTiN5UlS9XpH9E1Vjsj6W9nStZ7nQwqxnGZ0H9lyYxyVgDbBR?=
 =?us-ascii?Q?uBcKKe5Gx+/AoRRfDrNnaVcKQSrUBgPGT952113+ACKTNqmjL3hZGy3Ix99B?=
 =?us-ascii?Q?cv5aEc2pLdJSHd7kOxhwClmWnkU1IQuBLWGGdQkFjXHCzTO0cm/3POtvKWkB?=
 =?us-ascii?Q?MEEYFBo7f8I1OFq8Ys2ENa2aAW9ufq/bdoxUm/HfSIFr6XIF3GxRfnLFDaIV?=
 =?us-ascii?Q?FWr7dWNu5c9JTNL92sOq3VdALkGyboWkF5Dk4AI0TlwR3HFy+oogXxJVie9L?=
 =?us-ascii?Q?JVYdOFMEm61nVIOAl1kOi8IffDspFh78P1nxwnn/nRhm9YmbBLzgY/tY+DCf?=
 =?us-ascii?Q?dJAyzSo25kA1Q6AsP79MQbWEBz5G/3pgGF62RXPCDH9pezCH4Moe16DyIV9s?=
 =?us-ascii?Q?kBxHifQxfroD8vDU0YZzhZLSqUR6pOtl0IUVKlkWZ0hTtF8aVpBC5B1+X7Vp?=
 =?us-ascii?Q?U+LA2XzlPYWo8LbPXIKI4OvUPzgMuAdhU/Ccz4gtIlBrdgRkODykPRHliC5z?=
 =?us-ascii?Q?ngXLIeIGCOwx7/I+ON0WUu3UBq7GWY8mZXtYVba6SvNoet5Yu/PrPuwC2PJ2?=
 =?us-ascii?Q?jHhs1525JKEkNBuNG8AjAVzNDQUc3FbL8KrOuReMfuPce5c4mNx06v3pj50C?=
 =?us-ascii?Q?6u/5DMfvQKUpGPPbXVK13etv05wYpRhZ4ttvlXLYZ6qVAujXed3MRZS8yLij?=
 =?us-ascii?Q?sGriPTNKsFV2JU+p0dTbppNY0Q6DMk+2j2laUvgHPxkGmLoRq/8TmnVs28jx?=
 =?us-ascii?Q?AuBNsXg6SAPz/DbLSHUC45i9lDLzoDuafRwuR00EdZiwdnQEpeNFsDiXm9Ok?=
 =?us-ascii?Q?97HPEhF0fMU4TTJbvdnD9r6Z6sr8EdM4kejp2JS3vYq35GOmmLjZEp0zOVDJ?=
 =?us-ascii?Q?jbW/hmw9TOx0NH4yg0BFVw5bF8iFBkvLbWV2EcTbp5pWTkSSD9II5zfCRz5D?=
 =?us-ascii?Q?ok0yNwoQFi//hRwuT3wPlm8PsjxQBm6hMlkFKZ6fek1tQqOX7FD8akOurL4r?=
 =?us-ascii?Q?Z+i1LgrUfq9yk8t0GJ6nFnu05qDovRMdauLPgDPka8ZZO8J/aHoWzQp6Q6in?=
 =?us-ascii?Q?kF3Qj3PFdiSYG5Yd6RcOYaSrP9Hc26+dZr4f6KHvxjNpBskbXF7ctoDrSomt?=
 =?us-ascii?Q?YLscEMUcO3vke0tzGpMLs8BtsPljEfVHbz7EBn4KSq3SfnkgPyFQXaqurkEr?=
 =?us-ascii?Q?6BPVtIvOLndgtrucKAw6MiZJPgV9+DrZiYRfg0hmwAzDDapf16QLBhTNepkv?=
 =?us-ascii?Q?UJqL9o9f6g=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 623f5751-dad1-426e-dc6c-08df0448079d
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:32.3414
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 92hAOWtWTSrQsgs+nRPAdixXDYNR9/UJgMI4YUNKPOxuYG0+NJ53VBVxZQXoyaOpteiUmosePk7kYOYd0sqwUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-42698a/1787841153-AAAD89EA-2DE3372E/0/0
X-purgate-type: clean
X-purgate-size: 11069

Add system suspend/resume callbacks for the Arm SMMUv3 driver.

During suspend, configure GBPA to abort incoming transactions, disable the
translation interface while keeping CMDQ enabled, issue CMD_SYNC to ensure
all previously issued commands have completed, then disable the SMMU IRQs
and SMMU.

Resume uses arm_smmu_device_reset() to reprogram the SMMU and re-enable
translation and interrupt generation.

The IRQ setup split follows the approach from Pranjal Shrivastava's Linux
arm-smmu-v3 runtime/system sleep series: IRQ handlers are requested once
during probe, while reset/resume only restores SMMU hardware state and
re-enables IRQ_CTRL.

Only the pieces relevant to Xen's currently supported SMMUv3 path are
ported here. Xen documents SMMUv3 MSI and PCI ATS as unsupported and not
compiled/tested, so this patch does not restore SMMU MSI IRQ_CFGn registers
nor reinitialize ATS/PRI endpoints. If those paths become usable,
suspend/resume will need corresponding MSI restore and ATS/PRI
quiesce/reinit steps.

Link: https://lore.kernel.org/r/20260414194702.1229094-1-praan@google.com/
Based-on-patch-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in V11:
- Keep arm_smmu_update_gbpa() and arm_smmu_device_reset() in init text when
  CONFIG_SYSTEM_SUSPEND is disabled.

Changes in V10:
- Disable SMMU interrupt generation during suspend before disabling the
  SMMU interface, matching the resume/reset path which re-enables IRQ_CTRL.

Changes in V9:
- Use CMD_SYNC in suspend instead of polling CMDQ_CONS, so the suspend
  path waits for command completion rather than only command consumption.
- Document that arm_smmu_setup_irqs() is probe-only and that future Xen
  SMMUv3 MSI support will need to restore SMMU IRQ_CFGn registers on
  resume.
- Restore the reference to Pranjal's Linux runtime/system sleep series and
  clarify that MSI/ATS/PRI resume handling is outside the supported Xen
  path.
- Prefix the subject with xen/arm for consistency with the rest of the
  Arm suspend/resume series.

Changes in V8:
- Honor ARM_SMMU_FEAT_SEV when draining the CMDQ during suspend, matching
  the existing runtime CMD_SYNC path.
- Fold the suspend rollback reset path into a helper and rename the error
  reporting to describe suspend rollback rather than resume.
- Treat SMMU reset failure during resume as fatal instead of logging and
  continuing with a potentially unusable IOMMU.
- cosmetic changes
---
 xen/drivers/passthrough/arm/smmu-v3.c | 194 +++++++++++++++++++++-----
 1 file changed, 158 insertions(+), 36 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c
index bf153227db..7f1d00fb81 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -94,6 +94,12 @@
 
 #include "smmu-v3.h"
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+#define __init_or_smmu_suspend
+#else
+#define __init_or_smmu_suspend __init
+#endif
+
 #define ARM_SMMU_VTCR_SH_IS		3
 #define ARM_SMMU_VTCR_RGN_WBWA		1
 #define ARM_SMMU_VTCR_TG0_4K		0
@@ -1814,8 +1820,8 @@ static int arm_smmu_write_reg_sync(struct arm_smmu_device *smmu, u32 val,
 }
 
 /* GBPA is "special" */
-static int __init arm_smmu_update_gbpa(struct arm_smmu_device *smmu,
-                                       u32 set, u32 clr)
+static int __init_or_smmu_suspend
+arm_smmu_update_gbpa(struct arm_smmu_device *smmu, u32 set, u32 clr)
 {
 	int ret;
 	u32 reg, __iomem *gbpa = smmu->base + ARM_SMMU_GBPA;
@@ -1995,10 +2001,35 @@ err_free_evtq_irq:
 	return ret;
 }
 
+static int arm_smmu_enable_irqs(struct arm_smmu_device *smmu)
+{
+	int ret;
+	u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN;
+
+	if ( smmu->features & ARM_SMMU_FEAT_PRI )
+		irqen_flags |= IRQ_CTRL_PRIQ_IRQEN;
+
+	/* Enable interrupt generation on the SMMU */
+	ret = arm_smmu_write_reg_sync(smmu, irqen_flags,
+				      ARM_SMMU_IRQ_CTRL, ARM_SMMU_IRQ_CTRLACK);
+	if ( ret )
+	{
+		dev_warn(smmu->dev, "failed to enable irqs\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * Probe-time only: request host IRQs and, when available, program the SMMU's
+ * MSI doorbells. Resume does not restore the SMMU *_IRQ_CFGn MSI registers,
+ * so any host suspend support must treat the active MSI IRQ path as
+ * unsupported until that restore path exists.
+ */
 static int __init arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
 {
 	int ret, irq;
-	u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN;
 
 	/* Disable IRQs first */
 	ret = arm_smmu_write_reg_sync(smmu, 0, ARM_SMMU_IRQ_CTRL,
@@ -2028,22 +2059,7 @@ static int __init arm_smmu_setup_irqs(struct arm_smmu_device *smmu)
 		}
 	}
 
-	if (smmu->features & ARM_SMMU_FEAT_PRI)
-		irqen_flags |= IRQ_CTRL_PRIQ_IRQEN;
-
-	/* Enable interrupt generation on the SMMU */
-	ret = arm_smmu_write_reg_sync(smmu, irqen_flags,
-				      ARM_SMMU_IRQ_CTRL, ARM_SMMU_IRQ_CTRLACK);
-	if (ret) {
-		dev_warn(smmu->dev, "failed to enable irqs\n");
-		goto err_free_irqs;
-	}
-
 	return 0;
-
-err_free_irqs:
-	arm_smmu_free_irqs(smmu);
-	return ret;
 }
 
 static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
@@ -2057,7 +2073,8 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
 	return ret;
 }
 
-static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu)
+static int __init_or_smmu_suspend
+arm_smmu_device_reset(struct arm_smmu_device *smmu)
 {
 	int ret;
 	u32 reg, enables;
@@ -2163,17 +2180,9 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu)
 		}
 	}
 
-	ret = arm_smmu_setup_irqs(smmu);
-	if (ret) {
-		dev_err(smmu->dev, "failed to setup irqs\n");
+	ret = arm_smmu_enable_irqs(smmu);
+	if ( ret )
 		return ret;
-	}
-
-	/* Initialize tasklets for threaded IRQs*/
-	tasklet_init(&smmu->evtq_irq_tasklet, arm_smmu_evtq_tasklet, smmu);
-	tasklet_init(&smmu->priq_irq_tasklet, arm_smmu_priq_tasklet, smmu);
-	tasklet_init(&smmu->combined_irq_tasklet, arm_smmu_combined_irq_tasklet,
-				 smmu);
 
 	/* Enable the SMMU interface, or ensure bypass */
 	if (disable_bypass) {
@@ -2181,20 +2190,16 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	} else {
 		ret = arm_smmu_update_gbpa(smmu, 0, GBPA_ABORT);
 		if (ret)
-			goto err_free_irqs;
+			return ret;
 	}
 	ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0,
 				      ARM_SMMU_CR0ACK);
 	if (ret) {
 		dev_err(smmu->dev, "failed to enable SMMU interface\n");
-		goto err_free_irqs;
+		return ret;
 	}
 
 	return 0;
-
-err_free_irqs:
-	arm_smmu_free_irqs(smmu);
-	return ret;
 }
 
 static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
@@ -2558,10 +2563,23 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev)
 	if (ret)
 		goto out_free;
 
+	ret = arm_smmu_setup_irqs(smmu);
+	if ( ret )
+	{
+		dev_err(smmu->dev, "failed to setup irqs\n");
+		goto out_free;
+	}
+
+	/* Initialize tasklets for threaded IRQs*/
+	tasklet_init(&smmu->evtq_irq_tasklet, arm_smmu_evtq_tasklet, smmu);
+	tasklet_init(&smmu->priq_irq_tasklet, arm_smmu_priq_tasklet, smmu);
+	tasklet_init(&smmu->combined_irq_tasklet, arm_smmu_combined_irq_tasklet,
+				smmu);
+
 	/* Reset the device */
 	ret = arm_smmu_device_reset(smmu);
 	if (ret)
-		goto out_free;
+		goto out_free_irqs;
 
 	/*
 	 * Keep a list of all probed devices. This will be used to query
@@ -2575,6 +2593,8 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev)
 
 	return 0;
 
+out_free_irqs:
+	arm_smmu_free_irqs(smmu);
 
 out_free:
 	arm_smmu_free_structures(smmu);
@@ -2855,6 +2875,104 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d)
 	xfree(xen_domain);
 }
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+
+static void arm_smmu_reset_for_suspend_rollback(struct arm_smmu_device *smmu)
+{
+	int ret = arm_smmu_device_reset(smmu);
+
+	if ( ret )
+		dev_err(smmu->dev, "Failed to reset during suspend rollback: %d\n",
+				ret);
+}
+
+static int arm_smmu_suspend(void)
+{
+	struct arm_smmu_device *smmu;
+	int ret = 0;
+
+	list_for_each_entry(smmu, &arm_smmu_devices, devices)
+	{
+		/* Abort all transactions before disable to avoid spurious bypass */
+		ret = arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
+		if ( ret )
+			goto fail;
+
+		ret = arm_smmu_write_reg_sync(smmu, 0, ARM_SMMU_IRQ_CTRL,
+					ARM_SMMU_IRQ_CTRLACK);
+		if ( ret )
+		{
+			dev_err(smmu->dev, "Timed-out while disabling SMMU irqs\n");
+			goto fail;
+		}
+
+		/* Disable the SMMU via CR0.EN and all queues except CMDQ */
+		ret = arm_smmu_write_reg_sync(smmu, CR0_CMDQEN, ARM_SMMU_CR0,
+					ARM_SMMU_CR0ACK);
+		if ( ret )
+		{
+			dev_err(smmu->dev, "Timed-out while disabling smmu\n");
+			goto fail;
+		}
+
+		/*
+		 * At this point the translation interface is disabled and the
+		 * SMMU won't access translation/config structures, even
+		 * speculatively, as per the IHI0070 spec (section 6.3.9.6).
+		 * CMDQ is still enabled so that a CMD_SYNC can complete any
+		 * previously issued commands.
+		 */
+
+		/* Ensure all previously issued commands have completed. */
+		ret = arm_smmu_cmdq_issue_sync(smmu);
+		if ( ret )
+		{
+			dev_err(smmu->dev, "Timed-out waiting for pending commands\n");
+			goto fail;
+		}
+
+		/* Disable everything */
+		ret = arm_smmu_device_disable(smmu);
+		if ( ret )
+			goto fail;
+
+		dev_dbg(smmu->dev, "Suspended smmu\n");
+	}
+
+	return 0;
+
+ fail:
+	/* Reset the device that failed as well as any already-suspended ones. */
+	arm_smmu_reset_for_suspend_rollback(smmu);
+
+	list_for_each_entry_continue_reverse(smmu, &arm_smmu_devices, devices)
+		arm_smmu_reset_for_suspend_rollback(smmu);
+
+	return ret;
+}
+
+static void arm_smmu_resume(void)
+{
+	int ret;
+	struct arm_smmu_device *smmu;
+
+	list_for_each_entry(smmu, &arm_smmu_devices, devices)
+	{
+		dev_dbg(smmu->dev, "Resuming device\n");
+
+		/*
+		 * The reset will re-initialize all the base addresses, queues,
+		 * prod and cons maintained within struct arm_smmu_device as well as
+		 * re-enable the interrupts.
+		 */
+		ret = arm_smmu_device_reset(smmu);
+		if ( ret )
+			panic("SMMUv3: %s: Failed to reset during resume: %d\n",
+			      dev_name(smmu->dev), ret);
+	}
+}
+#endif
+
 static const struct iommu_ops arm_smmu_iommu_ops = {
 	.page_sizes		= PAGE_SIZE_4K,
 	.init			= arm_smmu_iommu_xen_domain_init,
@@ -2867,6 +2985,10 @@ static const struct iommu_ops arm_smmu_iommu_ops = {
 	.unmap_page		= arm_iommu_unmap_page,
 	.dt_xlate		= arm_smmu_dt_xlate,
 	.add_device		= arm_smmu_add_device,
+#ifdef CONFIG_SYSTEM_SUSPEND
+	.suspend		= arm_smmu_suspend,
+	.resume			= arm_smmu_resume,
+#endif
 };
 
 static __init int arm_smmu_dt_init(struct dt_device_node *dev,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400686.1636315 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9i-0006so-7s; Thu, 27 Aug 2026 14:32:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400686.1636315; Thu, 27 Aug 2026 14:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9i-0006sT-2d; Thu, 27 Aug 2026 14:32:38 +0000
Received: by outflank-mailman (input) for mailman id 1400686;
 Thu, 27 Aug 2026 14:32:36 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9g-0006WR-Cb
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9f-009cRM-Oy
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:35 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a6a-bab6-0a2a0a5309dd-0a2a450890e0-28
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:35 +0200
Received: from [52.101.66.112]
 (helo=DUZPR83CU001.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a83-f659-0a2a45080019-346542705d55-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:35 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:34 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:34 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uKUbVAsI+pp+cJw1KRRY8rZ2r83cgsgJF7tlNRgtdaWp0MLqquLc24lF89eKfjz49HJsuHHiFc1ODDz7+sfnt+40EWK6fLYUD1Zw2XMo6VPhIKE8++O0wkVrH07F3zew7ClY2HW6AbfTOmxma3VW5aSvGRsqLJR/nqlDfUwi0rWm1ISAy6ENknr/Y9sItAEYokTQHtlqV7gUc4FR943J7sYzGB/ds8uBKNMSUfgTHLWa30vu0DJcwsN5uPEEYTLvFhAgdAn91MIOuIPFW5wMXpfkNht5qLgiDr5yzU9OZA0BCbDigUjwzIrCboxkv3eiE6voGC2H8QBADaE7xAjEcw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=30Z8gX2uWqFKyBD7HEL7wO9Upezxb+zNkuX2zZMH2DA=;
 b=gL24C46MH4r/mupIAM9etesSQMCZxKKBOOVqG2W33/6cKAq+BdvcOdXh/tzPxl+3He9WWLRh8n2FnD7jGmV2tcIlBkHfKe0pibhCG5ZA3SbBI2EhpHRNfj1Od9Lcs8JkwkALrcleHB97jSTxdBQ+OUlRaH4ALfst/tB51AzYDyBVoLqNtjI9fxHxVXZxaOYwlCK7kug/dXGnMm1X0WKdfTqFPp71XTSnusodvuD0uihmwS2JJ1Odr+aak6a/YFoTWCiWpl+Lm9MtSrW4tFYDFeemRWGe/R9Vg0WE+TxN+Z7PMRR70FeTnUAvPBxPSFB6oE46Qb1BHyIMTZsyDkH5hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=30Z8gX2uWqFKyBD7HEL7wO9Upezxb+zNkuX2zZMH2DA=;
 b=BnGaKST6rSyr4zRO+ZTF1+9TYAgntnNt4x5DVmi46ApACstkoIZ/dIfyU5/p5mknJosUVPxmGiiOH7ziTUAKj22DDTPYDuettpHjv+ibw5pGm6ikWbjmJes8x2dY0N8Apb5oMelc8iCZKn0tsKFekr/wRtBZVj/zUltfVluFes77qYCqhqmDtyuPOE2fgjxTVQlJ5HydT1QY/eJo8OFHC/fUaD6fyezSipkG6uXDm26F/tzNtgvX55TyB8NwPHUZ3foydsO0RicAkkID9+f9p3Vji2IW7g6DBav2uOTks+4j1Hc2LFD9hc0z3PSq/UcRxZBzds3pdEv0N/XQNeL2Vg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 10/13] xen/arm64: Save/restore CPU context across SYSTEM_SUSPEND
Date: Thu, 27 Aug 2026 17:31:58 +0300
Message-ID: <552b979775f1f67d49f7ac303c1a1d4feafe820a.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: d9f1c2b0-7552-4783-e711-08df044808a6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|5023799004|56012099006;
X-Microsoft-Antispam-Message-Info:
	OzzraU+pu513h3OJK3TCYl6uGvH28dwysVxBegrvJeUhICR6zUL7Zwduudm6n1+7Krvfht+Lx6TGwWoIm2c5dS2yOGICMNvDxMMMmuN7txYpDUc5/jzUkZ+1dWJIuqC1OzTiwqvHU+hXbGpcBP+EUQElIF0fm14H7R+zywSqsaM0Xtm5feSSCtqYaQvf6ViniInECWPwBbZL6eYjMUulELzAbbKzuJ+pxPIJ1yNIb0jCnEIZNMBl3RfO5zwWdUwmtnQQT/JINa7BF5/FKD6U3hOCS5WivZgusU2/sLPz/fmUKRKYFw9krtjMbg1I+lyEFE6ymz6y3qFdgeHiDr/ooNO0m+0TpdgBAkaPVWPB65X2bq/kpGNbPZXatcd5DqIFD4vTfjFqJPycGgO6yzOdoNDwEJ0X1+XWitj+PyqVeVsiG4rUQlpA3TuUa+KA4ynmWzucl6LQ2Q6L1CzYxVeaswhjJQCdqHBAqnWXX8SeYhkGE/xOj/3UotAs5rxL3n44R0HKkrYeD8hzMniW4d9LMPada4a+RDrY9FW4qVAKi3/O0lVqSE6kiLO3CraxvRxCPR9xB5k3+239CdCGyFuVMjTxfupmF+5ZtDgGkWIkmw2vZoHBUyldqq0ZXdo/IIP003SqODPigtvgeD8qrxxCXUJ/l2qIj7Y9LEJcT/BrlRg=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(5023799004)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?MVc8I/MStLmJHVjur218Y9e+vyrND97K61245kob7TNWcOidkqV/wsDMDEZr?=
 =?us-ascii?Q?VJvTAIDQHjB+kFsTDluffGcOvqjNY5uokeyGxDoRgsOY70OZAYifpXHekg8j?=
 =?us-ascii?Q?UO6O7/7ZlLq4Onh9Ts5xKVTpFSxNYkA+/GmoRU59iwcZzm01MaYa/VC2Qllg?=
 =?us-ascii?Q?s3+Nx6CPPoQ6qeK+y44NCpGurYJ3pM6aTIqn/55MbuM6ThjxhaYxVyYkvmyj?=
 =?us-ascii?Q?wna4EbyyMTYUZ+S2MnUQJVYwYHN9XMu44NXFnAJYT9ms9qhdye4BqTdbpyZD?=
 =?us-ascii?Q?FIePXB/+eHrdQcthrirG4NPP8BFCPfCP+5rsh+RZRWfknHXbCwwLmcKcrqqf?=
 =?us-ascii?Q?yvmvhdx0aim1o6mfPJmnJrm4HX+wJlu+Cz7J88rWnxNZ6QCO3LABPKWpzV1h?=
 =?us-ascii?Q?v38oOH96Oui3N6RTwurtAHOgIkFf4LbB+K3xK7YLHzfLD/9XkLXOvqj8B/kG?=
 =?us-ascii?Q?ejByB3QT+/5alwQ3ZrrZO0GAyWPxmQ04iUWyBIthIkdrKADlt5lUC3ZQJv8N?=
 =?us-ascii?Q?O7mjn83AE0Cnc5Ffd8inbB+aXaPX4psEk44Sro3giFaea1OQTKMOKNAj0Q5T?=
 =?us-ascii?Q?u+GJMDQutUnXGzVJGppp0WIH+P7RrVrb+9XsV0rfdezL96nYjHPFAgCplZoF?=
 =?us-ascii?Q?yz5JTlhhlZ1rf4ye5/EBZMJUIwLZQfQPuizsCTAKR6oH7fTwg24xKG3L2WET?=
 =?us-ascii?Q?+Sw0fG5NpD23GxDlz26pq6ROZYfCj+4J1E/VFmsUDA6k4Rkn/gX7PGqx5gJq?=
 =?us-ascii?Q?9cxdFH2JdLS96WbEuO9N6D0FRoGrw3D/kfWC3V71FyAtQVdIr5AWHe3eLE6p?=
 =?us-ascii?Q?vcIc6qxfNUIunlyZNbtdh2LMYXyKK6InJw1mbShCiyPzMjRwlORwzR+lspYj?=
 =?us-ascii?Q?Nm9IKyqBJfv5mjPTf2wSKN2gj8de0SeXfA+lnwVf4WTxrwtr4836KwTLeqKf?=
 =?us-ascii?Q?9wyrtV23zz8P7N3KmZmCe09jdr57qre9UrA4/xCRiEawjR4BHsR+vvj/xtUN?=
 =?us-ascii?Q?uuiepU5eQ7rMQmFW+L6P6bTDFgjGaHoWKyxqd/avIC0eo5BQ26Num+SP0fK5?=
 =?us-ascii?Q?SSCSVskv6BCUrQEFompzBmUa2CYIkAMxDfMAZ9gY07+miUFKMEHPMaPdUQYN?=
 =?us-ascii?Q?gaOc/OMXad3e9LeOIiJlTTUJ5NCaoDn86xrMxe2RMbw0VFMtPpW65G+aOF2J?=
 =?us-ascii?Q?ufRK+g/n1Zm9x6u2ItYRSUbdBVkdkxvFaT6P215dnfx/vT+wRJJiS9xT1QCO?=
 =?us-ascii?Q?2DCnkNjIBjqq8TGcYaUPiM68dLwd5KAeU0KImlYu/TiYepp6rDiTPmuBpQ0n?=
 =?us-ascii?Q?k2HL6bWkxw9yUFLpJi8zoMqrYmitA+XiT4WiOcssESooU4SNXGNnfK20QuQ5?=
 =?us-ascii?Q?x1TlhhwqNNVKBk/Aj35PiYOx9Uth0FoFMeFrtpfsruM6+1QId4O9Q2nA5JDG?=
 =?us-ascii?Q?dmbKrUTkwyzBhSNQuaoovenfCwbLYICsRbdA/YRtTwobbcAQqWeKjbSD5Ae5?=
 =?us-ascii?Q?RLJ2iH5o3n7nOBteWWASluw/DkTHzM/OR+3mg2pvbwtwWNRnfvbPScDGU1ft?=
 =?us-ascii?Q?9Lp0tF8dx02HIy6YOXxhf/b/R7Ewejdxw4uxPaC2MJw+Wp1l/XWXo4pMGLZQ?=
 =?us-ascii?Q?9ElPh1Kh4b4OImVctYKVKiP78RpPRI+V5Qmu3BfyshFZEtXoYuBn3EypUXsw?=
 =?us-ascii?Q?Pp7ilyz6fha5GA0RakVOAqA29Sk/GgnkN6GhCGiWA4EY1iwdCc9gSZbn1oum?=
 =?us-ascii?Q?e/iZCqg+oA=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9f1c2b0-7552-4783-e711-08df044808a6
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:34.0371
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /bhOObLyN9e8artsc02k44fY7FXzkq4GYjDSYOrAx1pJzDlKrNrxCkfVKtPGrXr/jsHIkgDztZ9TklPhkE5roQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-c1860d/1787841155-D775B87B-B93F3847/0/0
X-purgate-type: clean
X-purgate-size: 11487

From: Mirela Simonovic <mirela.simonovic@aggios.com>

On wakeup from PSCI SYSTEM_SUSPEND, Xen re-enters EL2 with the MMU and
data cache disabled. The resume path must first switch back to Xen's
runtime page tables before it can access the saved CPU context using
virtual addresses.

Add an arm64 hyp_resume trampoline that reuses enable_secondary_cpu_mm()
to enable the data cache and MMU, switch to init_ttbr, and resume in the
runtime virtual mapping. The trampoline then restores the saved CPU
general-purpose and system-control register context.

prepare_resume_ctx() must be invoked just before the PSCI system suspend
call is issued to the platform firmware. It saves the current CPU context
and returns a non-zero value so that the caller enters the physical
SYSTEM_SUSPEND call.

On resume, hyp_resume restores the saved context, including the saved link
register. Control therefore returns to the place where prepare_resume_ctx()
was called. To avoid re-entering the suspend path, the restored path sees
prepare_resume_ctx() return zero.

The assembly save/restore code uses offsets generated by asm-offsets.c
from struct resume_cpu_context, keeping the assembly memory accesses in
sync with the C structure layout.

Support for ARM32 is not implemented. Instead, compilation fails with a
build-time error if suspend is enabled for ARM32.

Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v10:
- Save and restore CNTHCTL_EL2 across SYSTEM_SUSPEND

Changes in v9:
- Drop the misleading prepare_resume_ctx() pointer argument and make both
  save/restore paths use the global resume_cpu_context.
- Squash the arm64 resume trampoline into the context save/restore patch.
- Document in code that hyp_resume relies on PSCI initial-state rules.
- Use generic platform firmware wording instead of ATF-specific wording.
- Rename the saved context type/storage to resume_cpu_context and rely on
  implicit zero-initialization for the file-scope object.
- Use asm-offsets.c-generated RESUME_CTX_* offsets to keep the assembly
  save/restore code in sync with struct resume_cpu_context.

Changes in v8:
- Fix alignments in code.

Changes in v7:
- No functional changes, just moved commit.
---
 xen/arch/arm/Makefile              |   1 +
 xen/arch/arm/arm64/asm-offsets.c   |  21 +++++
 xen/arch/arm/arm64/head.S          | 122 +++++++++++++++++++++++++++++
 xen/arch/arm/include/asm/suspend.h |  27 +++++++
 xen/arch/arm/suspend.c             |  14 ++++
 5 files changed, 185 insertions(+)
 create mode 100644 xen/arch/arm/suspend.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b7afd3e58c..788db83ba9 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,6 +51,7 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
+obj-$(CONFIG_SYSTEM_SUSPEND) += suspend.o
 obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += time.o
 obj-y += traps.o
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index 38a3894a3b..5d60406e9c 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -13,6 +13,7 @@
 #include <asm/mm.h>
 #include <asm/setup.h>
 #include <asm/smccc.h>
+#include <asm/suspend.h>
 
 #define DEFINE(_sym, _val)                                                 \
     asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\
@@ -57,6 +58,26 @@ void __dummy__(void)
    OFFSET(INITINFO_stack, struct init_info, stack);
    BLANK();
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+   OFFSET(RESUME_CTX_X19, struct resume_cpu_context, callee_regs[0]);
+   OFFSET(RESUME_CTX_X21, struct resume_cpu_context, callee_regs[2]);
+   OFFSET(RESUME_CTX_X23, struct resume_cpu_context, callee_regs[4]);
+   OFFSET(RESUME_CTX_X25, struct resume_cpu_context, callee_regs[6]);
+   OFFSET(RESUME_CTX_X27, struct resume_cpu_context, callee_regs[8]);
+   OFFSET(RESUME_CTX_X29, struct resume_cpu_context, callee_regs[10]);
+   OFFSET(RESUME_CTX_SP, struct resume_cpu_context, sp);
+   OFFSET(RESUME_CTX_VBAR_EL2, struct resume_cpu_context, vbar_el2);
+   OFFSET(RESUME_CTX_VTCR_EL2, struct resume_cpu_context, vtcr_el2);
+   OFFSET(RESUME_CTX_VTTBR_EL2, struct resume_cpu_context, vttbr_el2);
+   OFFSET(RESUME_CTX_TPIDR_EL2, struct resume_cpu_context, tpidr_el2);
+   OFFSET(RESUME_CTX_MDCR_EL2, struct resume_cpu_context, mdcr_el2);
+   OFFSET(RESUME_CTX_HSTR_EL2, struct resume_cpu_context, hstr_el2);
+   OFFSET(RESUME_CTX_CPTR_EL2, struct resume_cpu_context, cptr_el2);
+   OFFSET(RESUME_CTX_HCR_EL2, struct resume_cpu_context, hcr_el2);
+   OFFSET(RESUME_CTX_CNTHCTL_EL2, struct resume_cpu_context, cnthctl_el2);
+   BLANK();
+#endif
+
    OFFSET(SMCCC_RES_a0, struct arm_smccc_res, a0);
    OFFSET(SMCCC_RES_a2, struct arm_smccc_res, a2);
    OFFSET(ARM_SMCCC_1_2_REGS_X0_OFFS, struct arm_smccc_1_2_regs, a0);
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 72c7b24498..962be716ae 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -561,6 +561,128 @@ END(efi_xen_start)
 
 #endif /* CONFIG_ARM_EFI */
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+/*
+ * int prepare_resume_ctx(void)
+ *
+ * CPU context saved here will be restored on resume in hyp_resume function.
+ * prepare_resume_ctx shall return a non-zero value. Upon restoring context
+ * hyp_resume shall return value zero instead. From C code that invokes
+ * prepare_resume_ctx, the return value is interpreted to determine whether
+ * the context is saved (prepare_resume_ctx) or restored (hyp_resume).
+ */
+FUNC(prepare_resume_ctx)
+        ldr   x0, =resume_cpu_context
+
+        /* Store callee-saved registers */
+        stp   x19, x20, [x0, #RESUME_CTX_X19]
+        stp   x21, x22, [x0, #RESUME_CTX_X21]
+        stp   x23, x24, [x0, #RESUME_CTX_X23]
+        stp   x25, x26, [x0, #RESUME_CTX_X25]
+        stp   x27, x28, [x0, #RESUME_CTX_X27]
+        stp   x29, lr, [x0, #RESUME_CTX_X29]
+
+        /* Store stack-pointer */
+        mov   x2, sp
+        str   x2, [x0, #RESUME_CTX_SP]
+
+        /* Store system control registers */
+        mrs   x2, VBAR_EL2
+        str   x2, [x0, #RESUME_CTX_VBAR_EL2]
+        mrs   x2, VTCR_EL2
+        str   x2, [x0, #RESUME_CTX_VTCR_EL2]
+        mrs   x2, VTTBR_EL2
+        str   x2, [x0, #RESUME_CTX_VTTBR_EL2]
+        mrs   x2, TPIDR_EL2
+        str   x2, [x0, #RESUME_CTX_TPIDR_EL2]
+        mrs   x2, MDCR_EL2
+        str   x2, [x0, #RESUME_CTX_MDCR_EL2]
+        mrs   x2, HSTR_EL2
+        str   x2, [x0, #RESUME_CTX_HSTR_EL2]
+        mrs   x2, CPTR_EL2
+        str   x2, [x0, #RESUME_CTX_CPTR_EL2]
+        mrs   x2, HCR_EL2
+        str   x2, [x0, #RESUME_CTX_HCR_EL2]
+        mrs   x2, CNTHCTL_EL2
+        str   x2, [x0, #RESUME_CTX_CNTHCTL_EL2]
+
+        /* prepare_resume_ctx must return a non-zero value */
+        mov   x0, #1
+        ret
+END(prepare_resume_ctx)
+
+FUNC(hyp_resume)
+        /*
+         * PSCI states that SYSTEM_SUSPEND follows the CPU_SUSPEND initial
+         * state rules, so PSCI-compliant firmware must enter the return
+         * exception level with DAIF masked.
+         */
+
+        /* Initialize the UART if earlyprintk has been enabled. */
+#ifdef CONFIG_EARLY_PRINTK
+        bl    init_uart
+#endif
+        PRINT_ID("- Xen resuming -\r\n")
+
+        bl    check_cpu_mode
+        bl    cpu_init
+
+        ldr   x0, =start
+        adr   x20, start             /* x20 := paddr (start) */
+        sub   x20, x20, x0           /* x20 := phys-offset */
+        ldr   lr, =mmu_resumed
+        b     enable_secondary_cpu_mm
+
+mmu_resumed:
+        /* Now we can access the saved context, so restore it here. */
+        ldr   x0, =resume_cpu_context
+
+        /* Restore callee-saved registers */
+        ldp   x19, x20, [x0, #RESUME_CTX_X19]
+        ldp   x21, x22, [x0, #RESUME_CTX_X21]
+        ldp   x23, x24, [x0, #RESUME_CTX_X23]
+        ldp   x25, x26, [x0, #RESUME_CTX_X25]
+        ldp   x27, x28, [x0, #RESUME_CTX_X27]
+        ldp   x29, lr, [x0, #RESUME_CTX_X29]
+
+        /* Restore stack pointer */
+        ldr   x2, [x0, #RESUME_CTX_SP]
+        mov   sp, x2
+
+        /* Restore system control registers */
+        ldr   x2, [x0, #RESUME_CTX_VBAR_EL2]
+        msr   VBAR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_VTCR_EL2]
+        msr   VTCR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_VTTBR_EL2]
+        msr   VTTBR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_TPIDR_EL2]
+        msr   TPIDR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_MDCR_EL2]
+        msr   MDCR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_HSTR_EL2]
+        msr   HSTR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_CPTR_EL2]
+        msr   CPTR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_HCR_EL2]
+        msr   HCR_EL2, x2
+        ldr   x2, [x0, #RESUME_CTX_CNTHCTL_EL2]
+        msr   CNTHCTL_EL2, x2
+        isb
+
+        /*
+         * Since context is restored return from this function will appear
+         * as return from prepare_resume_ctx. To distinguish a return from
+         * prepare_resume_ctx which is called upon finalizing the suspend,
+         * as opposed to return from this function which executes on resume,
+         * we need to return zero value here.
+         */
+        mov   x0, #0
+        ret
+END(hyp_resume)
+
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 /*
  * Local variables:
  * mode: ASM
diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h
index 31a98a1f1b..c848fc6340 100644
--- a/xen/arch/arm/include/asm/suspend.h
+++ b/xen/arch/arm/include/asm/suspend.h
@@ -3,6 +3,8 @@
 #ifndef ARM_SUSPEND_H
 #define ARM_SUSPEND_H
 
+#include <xen/types.h>
+
 struct domain;
 struct vcpu;
 struct vcpu_guest_context;
@@ -14,6 +16,31 @@ struct resume_info {
 
 void arch_domain_resume(struct domain *d);
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+#ifdef CONFIG_ARM_64
+struct resume_cpu_context {
+    register_t callee_regs[12];
+    register_t sp;
+    register_t vbar_el2;
+    register_t vtcr_el2;
+    register_t vttbr_el2;
+    register_t tpidr_el2;
+    register_t mdcr_el2;
+    register_t hstr_el2;
+    register_t cptr_el2;
+    register_t hcr_el2;
+    register_t cnthctl_el2;
+} __aligned(16);
+#else
+#error "Define resume_cpu_context structure for arm32"
+#endif
+
+extern struct resume_cpu_context resume_cpu_context;
+
+int prepare_resume_ctx(void);
+void hyp_resume(void);
+#endif /* CONFIG_SYSTEM_SUSPEND */
+
 #endif /* ARM_SUSPEND_H */
 
 /*
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
new file mode 100644
index 0000000000..6ea4a0f9cc
--- /dev/null
+++ b/xen/arch/arm/suspend.c
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <asm/suspend.h>
+
+struct resume_cpu_context resume_cpu_context;
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400687.1636323 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9j-00078r-Jo; Thu, 27 Aug 2026 14:32:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400687.1636323; Thu, 27 Aug 2026 14:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9j-00077b-Ek; Thu, 27 Aug 2026 14:32:39 +0000
Received: by outflank-mailman (input) for mailman id 1400687;
 Thu, 27 Aug 2026 14:32:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9h-0006rI-Mt
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9h-00BhhD-3I
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:37 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a7b-2eae-0a2a0a5409dd-0a2a450686cc-12
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:37 +0200
Received: from [52.101.84.77]
 (helo=DB3PR0202CU003.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a84-195a-0a2a45060019-3465544da39b-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:36 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:35 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:35 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=LDSrqmTWQ7H6/vqUK5LcUowSYV6/YX98uMFYzoLNOm77Yqx6OW8cgcDYLbBlQwzohaGdLzGZFnM77hlAvfGLVS517OjWVE4P4zWX5YgwXPaBG9QutLopSuoqZ6T+tH9Qude37YnheMLVwXTdOstNZYvYrsk0KfFqWdYQuacE3Dh5cSEnlLJl6mv2CLPnYmYLJtXpw6H+EngNtTyztRQ6griXKB3NYQQ45+YbVNmF4Nw82YlCld7nzYerxKHXnqYAldtmC5m/wD4/Ql+ZWOw4o+3p+TkGI0dZrF3s0LWO+NTFyleToUTS2zc+vFq/fpKWX/OzxElT2euob1T4A3YmLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=9Q1Fsw7I5VcRKOn6Vwcp1VtMdJtga40n5Ed4Emmc+5c=;
 b=Bk1Ddif56qzNoxkLIIr78ZnO5eZowg6IyxiUS9zx+pE7+FTth9p/lDVUWgqB3YMlES9GQGXOst1x6Uzwu6Hvxw8P8F/mIAwtFGLDEDryLP8dtukpsM3E/Fo19+z6KsPs3XJuZ4rwMkIVmj/T/KoTBXx2zXkpWsiAh2S0YX1CTBmMC2NBk6GEZxyB1EoGTeYVny3lNaCY4SRLDISPVPTKJgEJUrdM0k1Wd/TSjILOjHX6xOIWHzXoK545XJo2s3RkSb81euKRjXNq/ShfFC551fL9/LGET1QUEzmqi0WAQDDOszrdQYYP91no4rGRffWseK57Dxl2OD5HsHKl752H0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=9Q1Fsw7I5VcRKOn6Vwcp1VtMdJtga40n5Ed4Emmc+5c=;
 b=bo+kUXhTJyKsO3EVj4TFDlAu8JmDxsl7l1yhvzlPT6LDVp3OnPtaRd6zovaaW8F7chKPg/2tMxvWu2Zqsbhba9bvLLTfFnYUuf+/SOo4QGX/WYRB0q9302VvzJtQ3wz6pxz0yMvXBslIR3aZjbLSkxA8jetZOKGZZGiXH1W7Te11Yzwr4kj6fZ7g6rNX0qe+OV213P2SBqJDswoNCbFMeaihj4qB4n+/eW2nw37PeWkSGy/Dy8DEPTGaZTX9XAo3bjvz4PbeycvTqaAyoItxKfU/MU7MXh7tVUSluRcrAvg+/BxlcewWNIj0ryXdFrUsyeichdD3RG+b30yySVR4iQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Luca Fancellu <luca.fancellu@arm.com>
Subject: [PATCH v12 11/13] xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface)
Date: Thu, 27 Aug 2026 17:31:59 +0300
Message-ID: <39722280b669cf6b914d7cc70fbda667c123e21d.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 513fd4ac-b84a-4d85-fad2-08df04480979
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|5023799004|56012099006;
X-Microsoft-Antispam-Message-Info:
	HvkDjEfjsnSwVW1ZtkYEiIbFVcpl0PKrgykSG4Di+K9wuKRiJkSIuNkyrt4blBOUYhbXPwhyXdTdAaYiqtsWFjKRa+o4N5/7G+kxlPUzdbZitf6jkaXYVONH/4jxWGgJV9eSZrDRvu546WgzAI3Wxli1wK5E4mpFPROJNNYhhttKVQwfAP61SW5/B8npYcn/OhSoS1Hy8FDK9rDVkOPgVn6Kt0uj/lr47KJX5Rp2bZ8gVq04+3xoKs3JSXeJeQ7IoO76FAxg3ZcpNiSTuE/ldCLt6TUrGIObzYE3MseE/DjmPfEuuv9tL2fPkMgmTBeODy8aT85q9S8NbwPEbO4NSvL37UdJERo57AUje+eA3Q+QMvPiglCZHv5pVNlD6XDudURuxI8+V9Zuy7raQwZKFzHQQywMz+qCcWRJRC+yCfZ1MkafUtyO8l/xvP6f2z7c5vm0S1JKMVQmF5iyiwqlOnY9PI9rCAxmB3BSeVod06I1xSlXIqPy6ssR4aHnnVrdee/rVO0x0+PJwXmLE0ETQ1FiTCbr0N2o9dEufQq9rJ2J95FX91o4SWTKHQujxYNi8+a16Rm08DuC5xZwHfL05GY4DvoTLb/BnlM85qICTU/RlqHJfNFoAlq0DI3zJ49JbQ0m+zhn3TWQI+2EJgIPyJV7tIPfWDJ7vRZMEJIhv24=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(5023799004)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?2MiI7NhxRCZSq3VxkbgCsDPKTHmzE2z5iEu3vaSsqHylDRVa7rz6UDzqmdyP?=
 =?us-ascii?Q?YCgvh7uHbYzPu9LXLlifYDvXzgcwcxuIgbDWP5csOcVq4QABI18Fjp+xsWg9?=
 =?us-ascii?Q?8alYIr11iFuDXYBZIyC23uHqCUMKWCbgSdKQdCatgpKsuI7vDlc2bjahim6L?=
 =?us-ascii?Q?7SWHMUjGDZdJswYcBnfNKY1yjLnusC1A+7ceL1evoI4ibKORxV+3H9jpGZ8n?=
 =?us-ascii?Q?y9rwAe8Yd5hd+LwOpQqo4Dd0Q4Jy99YGAp9Ygqvievz4QSLHRrDJ+fGC/+dh?=
 =?us-ascii?Q?FjgJFzX5bCYgcxppvkAl14CxwqNa3ZfTJsrU/Uh1poHphsO4T2wlo0xTdzlF?=
 =?us-ascii?Q?eC4RcTId2p6b4cLc2e2UZ8H3HDP8HyoYWNaJCB4tvC7gzwuNFj3UleMZUEu0?=
 =?us-ascii?Q?6EdQpMwLW8g2MZhtsfppRnCeMOYUOzLX5nDYoomiJmU36P42NwGcOtF8Al8c?=
 =?us-ascii?Q?MXdRwCwqMOzIU/Nv+jJRL+klLUk1y0CWtd+NgvqThMPILqIxO4ZBZebfGbMw?=
 =?us-ascii?Q?fVk+zoYQBBQ0zU4+oiFtBZHvvyw930gUll4iQbcZhmHPJ1qG4vxu16+Q0WHT?=
 =?us-ascii?Q?jWus1J+YI0WFR3vBaJrwLYtvYI7AdEJwiPx040Zdwh1/N69KEcZa4sWbsVQ8?=
 =?us-ascii?Q?VGIsqzyo8jt1JnAKgOaZT83BtKAi3L+sweypgst5wH07kreW4qsZ+uSO+Yc2?=
 =?us-ascii?Q?u1G7RXXzZxvI3drLEAgfiVHYwTdFPEZty9goe2r58jPaX4Wq9C7YDd5Wul23?=
 =?us-ascii?Q?ApUACAI147/wOp8yR2Q7/yhC9m8fpLC68kNSH0YfH5uEqcDD6VWXf7MSOgl8?=
 =?us-ascii?Q?vvclpD4ozOFzFkD2W3bN1rf2cKkcwbXyYPPRuo1ibG6xtvGMco5XDKrcsxLx?=
 =?us-ascii?Q?+DNh0qCbXLtyIRLXLWB25dCVVwh9VvgBwXViAb6SvAae9L4dLvFiLdfUloSg?=
 =?us-ascii?Q?wFXkaWyxKIjBVQVoTBT/i4r/swIkKNi5TXAB0gX5h2M1tTK4gWHWZkzZOx5t?=
 =?us-ascii?Q?8K/0j490yLBCAT73HUt5o62FQHCFF5NJQLeks5rtCRvShX9dUsxOvAAMaQm8?=
 =?us-ascii?Q?S1mGFs/fdgHqCz8TxIJAhZzoFsBy14/1Fx3PE/0a6RNaemDJIc28xz7zk2if?=
 =?us-ascii?Q?UBZXWSj57z6RYcZdU6kYV60mKzGCdXy0wH4wT8LNc5ITk3CKvrEIiyUCLWZa?=
 =?us-ascii?Q?R/PCGoWzUFsR4pBML1Y4YssQp5yq1jcA/I3D7nnGUMCg5B8ZcgaO9z0UgT3i?=
 =?us-ascii?Q?v7GXYXnxVaONk1Ag8FKCHYeSIMNW7kLiMqUcJZSM801xEemxRZ6Ktpd4VbE/?=
 =?us-ascii?Q?6nq1xjKsWdBTd7n0Wd1C2AjkksZYlUnivRDCH8K976ImdAcVRisRPuasZZQ6?=
 =?us-ascii?Q?CKfRIi5je+f7rqXk6OF/XOUg4+i2OCbSiportUBo/7rSOxR2/I2lVjqNzp3T?=
 =?us-ascii?Q?9k4RvpaNOsACWuBiHNJhU6TWIjH6nYGpvZ/KVZRDw2uqB1cPptc16vCxNmQP?=
 =?us-ascii?Q?+XOGBN4pfgKrNF4zL7pjrdaWkpurRmB7zXFewroT0DWWXsqNSUFBBPJPqEFx?=
 =?us-ascii?Q?ts4pjAmGZ9fGZhhU21KFe1702LBY+KuXouP8j7tA49uqP4UHP3GFkKzSR1GJ?=
 =?us-ascii?Q?2lyI03Qy300DBLJdT1pCqOxQX2fZN2grzHA4NkiLvWg3PcO7oaBKGkP+i6pO?=
 =?us-ascii?Q?oXIkBVNEyzAgSi2EqRmzR1+5SdEaM/M+++ydwqaSgqIKB6J8BmnT9pVIU8Yn?=
 =?us-ascii?Q?ipiSs43C0Q=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 513fd4ac-b84a-4d85-fad2-08df04480979
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:35.4603
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 66gtmKu1bz7oNCxFjfpmfWAAbvsbP5fRE8ltUppVc18fLIcX6OFQ2kjG9Nmktpl14NcDE/jpqQ3lk2u7MSqr3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-16d1c6/1787841157-FE07177B-81165615/0/0
X-purgate-type: clean
X-purgate-size: 4081

From: Mirela Simonovic <mirela.simonovic@aggios.com>

Invoke PSCI SYSTEM_SUSPEND to finalize Xen's suspend sequence on ARM64
platforms. Pass the Xen resume entry point (hyp_resume) to EL3 together
with a zero context ID, matching Linux.

This patch wires up only the host-side PSCI SYSTEM_SUSPEND invocation.
The resume trampoline and context restore are provided by earlier patches
in the series.

Only enable this path when CONFIG_SYSTEM_SUSPEND is set and PSCI
advertises SYSTEM_SUSPEND via PSCI_FEATURES.

Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v9:
- cache SYSTEM_SUSPEND support using PSCI_FEATURES and gate the host call
  on the cached capability
- keep the cached SYSTEM_SUSPEND capability read-only after init
- log whether firmware reports SYSTEM_SUSPEND support
- pass an explicit zero context ID in the SYSTEM_SUSPEND call
- drop the stale note claiming hyp_resume is still a stub
---
 xen/arch/arm/include/asm/psci.h |  1 +
 xen/arch/arm/psci.c             | 31 ++++++++++++++++++++++++++++++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h
index 48a93e6b79..bb3c73496e 100644
--- a/xen/arch/arm/include/asm/psci.h
+++ b/xen/arch/arm/include/asm/psci.h
@@ -23,6 +23,7 @@ int call_psci_cpu_on(int cpu);
 void call_psci_cpu_off(void);
 void call_psci_system_off(void);
 void call_psci_system_reset(void);
+int call_psci_system_suspend(void);
 
 /* Range of allocated PSCI function numbers */
 #define	PSCI_FNUM_MIN_VALUE                 _AC(0,U)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index b6860a7760..e05dae1133 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -17,23 +17,27 @@
 #include <asm/cpufeature.h>
 #include <asm/psci.h>
 #include <asm/acpi.h>
+#include <asm/suspend.h>
 
 /*
  * While a 64-bit OS can make calls with SMC32 calling conventions, for
  * some calls it is necessary to use SMC64 to pass or return 64-bit values.
- * For such calls PSCI_0_2_FN_NATIVE(x) will choose the appropriate
+ * For such calls PSCI_*_FN_NATIVE(x) will choose the appropriate
  * (native-width) function ID.
  */
 #ifdef CONFIG_ARM_64
 #define PSCI_0_2_FN_NATIVE(name)    PSCI_0_2_FN64_##name
+#define PSCI_1_0_FN_NATIVE(name)    PSCI_1_0_FN64_##name
 #else
 #define PSCI_0_2_FN_NATIVE(name)    PSCI_0_2_FN32_##name
+#define PSCI_1_0_FN_NATIVE(name)    PSCI_1_0_FN32_##name
 #endif
 
 uint32_t psci_ver;
 uint32_t smccc_ver;
 
 static uint32_t psci_cpu_on_nr;
+static bool __ro_after_init has_psci_system_suspend;
 
 #define PSCI_RET(res)   ((int32_t)(res).a0)
 
@@ -60,6 +64,25 @@ void call_psci_cpu_off(void)
     }
 }
 
+int call_psci_system_suspend(void)
+{
+#ifdef CONFIG_SYSTEM_SUSPEND
+    struct arm_smccc_res res;
+
+    if ( !has_psci_system_suspend )
+        return PSCI_NOT_SUPPORTED;
+
+    /* Context ID is unused for the Xen resume path. */
+    arm_smccc_smc(PSCI_1_0_FN_NATIVE(SYSTEM_SUSPEND), __pa(hyp_resume), 0,
+                  &res);
+    return PSCI_RET(res);
+#else
+    dprintk(XENLOG_WARNING,
+            "SYSTEM_SUSPEND not supported (CONFIG_SYSTEM_SUSPEND disabled)\n");
+    return PSCI_NOT_SUPPORTED;
+#endif
+}
+
 void call_psci_system_off(void)
 {
     if ( psci_ver > PSCI_VERSION(0, 1) )
@@ -223,9 +246,15 @@ int __init psci_init(void)
 
     psci_init_smccc();
 
+    has_psci_system_suspend =
+        psci_features(PSCI_1_0_FN_NATIVE(SYSTEM_SUSPEND)) == 0;
+
     printk(XENLOG_INFO "Using PSCI v%u.%u\n",
            PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
 
+    printk(XENLOG_DEBUG "PSCI SYSTEM_SUSPEND is %ssupported by firmware\n",
+           has_psci_system_suspend ? "" : "not ");
+
     return 0;
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400691.1636332 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9n-0007XI-0k; Thu, 27 Aug 2026 14:32:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400691.1636332; Thu, 27 Aug 2026 14:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9m-0007X4-Pc; Thu, 27 Aug 2026 14:32:42 +0000
Received: by outflank-mailman (input) for mailman id 1400691;
 Thu, 27 Aug 2026 14:32:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9l-0007PG-2m
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9k-009cUS-Ff
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:40 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a78-bab6-0a2a0a5309dd-0a2a450ca9d8-42
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:40 +0200
Received: from [52.101.69.140]
 (helo=AM0PR83CU005.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a88-f479-0a2a450c0019-3465458c71ef-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:40 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:37 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:37 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=s4hWQZJI9E/semZdqJCS6Y7/wrCOTSBnselnXjentGxliv2RNbGjIB24AYMMwYhb1GK4YglkbCEjGiMAoAcfsFJpYtruW5GKXcZGM3VYH+vBJawIBQ4/E2nHFICiLPdCd07Z6Guq2TA9Jahpd4TrszJQKX/bx2wrEpqUBzD2CuAdK/opB+eRtfjmftavZJE31uDwch+wI72JuRINqfv3V6MI0ZAjjj2DVC5h2Yx7e9VaUtY2Y1QHGp6mn/YTCEv1NLmEgDq84NdWGAxCJV87KbmfH2ehF+hxg28mdkbNHogMrU9EOhZrC8fiBMeFI8elDGxDzBw0d3mYGEsMtndDkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lEekLP9yfwz9eetZjI7ftgzci+TVLnfA4bJRa7yah/w=;
 b=YNBCiYlDvUrXZwO0tmcxO48UPsaWs72q65iH4xOebAWrW6kSK2RJI2fOF8xhQf+lC4klCAzAk3qtMWhtXuFDe2fHNVYxQMRjVmTgOQZB9Wta3YdPQLNAgxPYouDIpjo8ptFlHXoU5TR1JpmgZ1oxdxB8VioyTv6dWVpwWnYv3gWwFXpqMsAhS/inX1IwOCgicfOzcSP2d3KK8ovkKAUs30QihlStYdKGRmWVU8wsVJfOudeQjJ9m1QOb5Mx8kEjivcN/1xLVijqM4XaMsiwpw5K8zF57eFFjLpIUiuGSi8fOnTLAZl1rcMLCy3wNhb26sfrimAc5qk79isvHB/sKAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lEekLP9yfwz9eetZjI7ftgzci+TVLnfA4bJRa7yah/w=;
 b=c1D5C9mkgtoPHMLfnvb8SqifATUzhoLjIZmLRKJ9y5tpJoyVaT51uIMe8qZdMaSV9lzjqOvBwtyXtv07heF7squPTsBu6FmM9TmxHeRp6EBX6zfQr+7uR3B8sRXmdi2adme43cRst1xRWRAO2+bHi6fzWSac+JbY9KUqHPHuEzG4rylDnTIeUB97tN2jfZL4yatEvmLKuyRHSIpLbbfiMOAGLh8fgjB04l9rLYxDTEEalRY908kFZA/7TH0SktSugvGlMlkLP87pESPDMVYLCIvLVGFVJ4ZYJ0A+MD/v/aLsQxDsYRZKHwHqfViuX3BxP4Om2B/1FnbuNae5zsaS0Q==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Rahul Singh <rahul.singh@arm.com>,
	Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>
Subject: [PATCH v12 12/13] xen/arm: Add vPSCI SYSTEM_SUSPEND policy
Date: Thu, 27 Aug 2026 17:32:00 +0300
Message-ID: <1d4cee919353f883f6be9c9de4f317432d61206e.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: 330f1a98-4c1c-42da-21e1-08df04480a96
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|7416014|1800799024|10067099003|6133799003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	zXolfGEyODushOIkfTEjovkeeZCzfUI1yWegjoShm3M7m3y+C+2ZGlx/QX2gE65k5kq4lSIlvptW6dhYGj7JdpOOpl24P4/U6U8vvUFFWO62lXeCw4vUJEx+69jguQ4Xmt4lbAozakoZ9tWJ1uJDpyN/BajRLbr8Lhks3jORLe80fmB5EecU52G7XK1NcYEoUXpDosOshZbLQ1FSBsvzgZKPNomRNDRLu3ZaIXJC8l82fKvfqe+RzMUQx2E6MEpAkCTodVLJfh4Y3Zb5q29ZMD0mqEf/hEQNWdqnSGGQ0xl8VrCRJZ7oCe+25exrVtdEGIm5CKcZNOklcph/wQ1IO4GXVUIJa5uqvIrhRqEDDvyFbUf5WjAW4aoTEzeEHv4A9PRVmdHkRwmP8lJlZUe6E4yO5wFKRGFjGMv3RymEL/aL0/hIJF5OPOr/Fl7TCIkmeBxbwd/2hFfWxTigdoxnGjhUK+oLJ4lkIy/SAi9QUf+m0NNMz7DeGQnU3YPcM7UAik5klp6gJGLxECx4+3dLmlmC3J2NNKsxVW/MYphTAvbOlcyH1KpX6K9crgWONlMukoVn/UfVsOdvHFGO9PFHzv0c950FO6ShhhUKAUocKNQuqppaV/o2kHeaqtNRKNp0BrIyeDjrdHG/8jycsQJYC8NEVJEjXDssdu+sjheGsO0=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(7416014)(1800799024)(10067099003)(6133799003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?klIMHZZ5l34wicensofTSHrkWOZzIZcR/uNwFj6mZ+dnC1iZMYt+IN6kL3UI?=
 =?us-ascii?Q?m79f7CoyKRCopDOWxrJ/mIbqy8t7LowYfp3fLvx/6XijIMOIApJBi+XqUQqK?=
 =?us-ascii?Q?uUpw+wzS9VgjzE0hUAFg2NgtjtbNnNYOlNMHtNVR8mHo3iENhns38aDWmEk2?=
 =?us-ascii?Q?uVY8g4BQ+4GkYNYLTeqzJpuM746xxdFnxHqPwfShZHq/zLY9BVIenWg1G5W9?=
 =?us-ascii?Q?w6uDz2zNedVeuUATnkxuSb0NNZLu/QlxSJQ6Mx7DLSMSimIvh9QSXyJGr2PG?=
 =?us-ascii?Q?rbgPnHDhwvgyABycYLaB8hm+olcGnAD7X/TLdbANwKBOO9Daps3b49u2fU6J?=
 =?us-ascii?Q?lijL/hbZq/iSXIigrtsmyQXHTjZ9Upahl2xPmXU+EGNUrPsP4LNezbLkgAVv?=
 =?us-ascii?Q?beBeS7YwNnDrqdOVqs6/LlxBNLAOswXD//32WrrPDBhwaFLzBNNELnbyb2x3?=
 =?us-ascii?Q?DgEGWkvAoBYx0HdlxfWSs1iEmpHuAU4d2AEq2ym9Do5hpdLK+L0p/xwyoO1n?=
 =?us-ascii?Q?WgXYc27iUFGLH15ozSWC07EIpqdxOCSHOkHByXvdoYmyAwtqQsSakO0RK3j5?=
 =?us-ascii?Q?jkocECyhA1Y3L+7xYmyLY9ST427AavsQIeT1nSI9IEUDF0e9yCTzaJwwO159?=
 =?us-ascii?Q?XBA4zTbgbOxYaZmmHXLcwNZjmjOhwbPbuAs+QwoY7tOjr0hlVQVzbVWR6B4L?=
 =?us-ascii?Q?u/Ek2Lk2XibchkaoM4tDwk0plGHh4e0GG2PH4WaxA7fflU1/3/HdNiQPS6Zn?=
 =?us-ascii?Q?3dICgNuhfmAw0tu1Qux6QTSEzyBERvw8rRA0FM+a4cP10l5ap7i3S27vzDmf?=
 =?us-ascii?Q?EKKDRJnrUhdObvAYVG3fnlwrD1h83EYkpmftOY4uvr7KugfDE3MSuADn5m+D?=
 =?us-ascii?Q?x999HobyBoYAjmMS6i3bzPunvCFmk5LrhtqFaLmB0JeOI0TnV9C92+kKnA3e?=
 =?us-ascii?Q?j86QYoGf2HXt3YmI3At+ouPSZy90xzW8oSWw+1Z4whFBG8FNUGGsHDaSm3bu?=
 =?us-ascii?Q?9QWTDUYjH1yisQZfmPuPWre1NHh/9b3R1i3dn1/wsFFvWPTkG4K/w1yq8VMG?=
 =?us-ascii?Q?zllgw/nnRshiFn0tF3h1FUdSnlbTnidtN3a6gTSws80H+jc15jcM3kXibcJ+?=
 =?us-ascii?Q?YpepwYv4Es/4O46v9oESGXpAPw1jEel3EPpGb7ZSopOSymxNo+w65zp6R72f?=
 =?us-ascii?Q?jcklvf/6ks0a6wvkcboJfHdZPspqUvol9KK9jalJRSOrQUiguE9tvk7S+/wT?=
 =?us-ascii?Q?r21KGUz+f5g+eLBRRn34TXu+LgAP55Qb8BPGUt/RQG6OdEpj9+JA22v2zLFD?=
 =?us-ascii?Q?lkV6VVPxlMF37vhmzau0tXDAgj5wRPsSDejS4+1cdhuLUAUCFQinPpJjyiPy?=
 =?us-ascii?Q?sEq4z79+aoVA8HokgJRA0EsEg2IQPJSUEZa0TVRx28NMVyhw488oBFxnEZSd?=
 =?us-ascii?Q?eaY1HTdurCaBHQoKoxNoyDBi+KRUZl/UrxxyLet5+9FkvigdzlPLAph3yTKL?=
 =?us-ascii?Q?SIZvFj4toAWsV9EPWrYNN6qbDmpaYD3KocV9NUQwXtW7Y90uRZjZpxrAXVbx?=
 =?us-ascii?Q?1Y5m2e9lyUQWPSTeK/K2q6UIbKqq2CrYQfbDYjaZHcIuaKU61gOmZgvo6jmZ?=
 =?us-ascii?Q?gXTlteWQQ2A8TUgqOrvE0b5mH0UeuXm2d0QQFJmazR7RSrJ3HFvPn0lVdbP6?=
 =?us-ascii?Q?phKWXRBiP9bdx7kNWLryCaCXoK+4/AHg0FtJnniUoM5MP1s3Fd6t1J2m7Lbi?=
 =?us-ascii?Q?bqsJj4UZQQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 330f1a98-4c1c-42da-21e1-08df04480a96
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:37.3263
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JjyzeBbecy5cxHJGW7D1+ZLOoBJGw+vbVhDiKVdlpJODya5JDSOIIje+jbl0KaSdiL6PfoqCx8g0X5RVglON9w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-d25034/1787841160-03CD3A5B-79120085/0/0
X-purgate-type: clean
X-purgate-size: 18344

Introduce CONFIG_HAS_HWDOM_SYSTEM_SUSPEND as an architecture-selected
capability for platforms where the hardware domain can be parked with
SHUTDOWN_suspend without calling hwdom_shutdown().

Expose PSCI SYSTEM_SUSPEND as a vPSCI operation for all domains. For
non-control domains, including the hardware domain when it is not acting
as a control domain, the call is handled as a guest/domain suspend request
and parks the domain in SHUTDOWN_suspend.

Control domains need additional sequencing because their SYSTEM_SUSPEND
request is used to coordinate host-wide suspend. A non-last awake control
domain may be parked in SHUTDOWN_suspend without requiring the host
suspend path to be available. The last awake control domain is treated as
the point where the request becomes a host-suspend request, and it may
only proceed when all non-control domains are already in SHUTDOWN_suspend
and the host suspend path is available.

Keep the control-domain sequencing and domain-readiness checks out of
PSCI_FEATURES. They are per-attempt runtime conditions rather than stable
PSCI function availability. Advertise SYSTEM_SUSPEND as implemented by
vPSCI and report attempt-time policy failures as PSCI_DENIED.

Select HAS_HWDOM_SYSTEM_SUSPEND independently from CONFIG_SYSTEM_SUSPEND
so that SHUTDOWN_suspend from the hardware domain can be treated as a
domain suspend state rather than as a hardware-domain initiated host
shutdown. This does not by itself imply that host-wide suspend is
available.

Add host_system_suspend_allowed() to combine the host PSCI SYSTEM_SUSPEND
capability with runtime blockers reported by Xen-owned subsystems. Add
runtime blockers for registered serial, IOMMU, GIC and SMMUv3 MSI IRQ
paths lacking suspend/resume support. These blockers are runtime based,
so they only apply to drivers or paths that Xen actually uses on the
platform. For SMMUv3, the blocker applies only when Xen actually uses the
MSI IRQ path, since resume does not restore the SMMU *_IRQ_CFGn MSI
registers yet.

Add a struct domain forward declaration to xen/suspend.h so the generic
header can expose arch_domain_resume() without requiring a full domain.h
include.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>
---
Changes in V12:
- handle missing is_shut_down, change checking to call of
  domain_shutdown_completed

Changes in V11:
- Mark host_system_suspend_runtime_allowed as __ro_after_init.
- Avoid printing the SMMUv3 MSI IRQ host suspend blocker more than once
  when multiple SMMUv3 instances use MSIs.
- Wrap the Arm IOMMU host suspend blocker in CONFIG_SYSTEM_SUSPEND to make
  its policy-only use explicit.

Changes in V10:
- Return PSCI_DENIED rather than PSCI_NOT_SUPPORTED when the last awake
  control domain cannot proceed to host suspend, keeping PSCI_FEATURES
  stable once SYSTEM_SUSPEND is advertised.
- Shorten SYSTEM_SUSPEND blocker messages and use %pd when logging the
  control domain.
- Mark serial_suspend_available as __ro_after_init.
- Mention the struct domain forward declaration added to xen/suspend.h.

Changes in V9:
- Select HAS_HWDOM_SYSTEM_SUSPEND independently from CONFIG_SYSTEM_SUSPEND
  so that hardware-domain SHUTDOWN_suspend support is not tied to
  host-wide system suspend availability.
- Add runtime host suspend blockers for Xen-owned subsystems lacking
  suspend/resume support.
- Keep vPSCI SYSTEM_SUSPEND advertised through PSCI_FEATURES and enforce
  control-domain sequencing in the call handler.
---
 xen/arch/arm/Kconfig                  |   1 +
 xen/arch/arm/gic.c                    |   6 ++
 xen/arch/arm/include/asm/psci.h       |   3 +
 xen/arch/arm/include/asm/suspend.h    |  10 ++-
 xen/arch/arm/psci.c                   |   7 ++
 xen/arch/arm/suspend.c                |  40 +++++++++
 xen/arch/arm/vpsci.c                  | 114 +++++++++++++++++++++++---
 xen/common/Kconfig                    |   3 +
 xen/common/domain.c                   |   7 +-
 xen/drivers/char/serial.c             |  12 +++
 xen/drivers/passthrough/arm/iommu.c   |   6 ++
 xen/drivers/passthrough/arm/smmu-v3.c |   9 ++
 xen/include/xen/serial.h              |   1 +
 xen/include/xen/suspend.h             |   2 +
 14 files changed, 208 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 843a43897e..9027aa17eb 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -19,6 +19,7 @@ config ARM
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE_DISCOVERY
 	select HAS_DOM0LESS
+	select HAS_HWDOM_SYSTEM_SUSPEND if !MPU
 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
 	select HAS_STACK_PROTECTOR
 	select HAS_STATIC_MEMORY
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index ffc11f36a1..0695474432 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -26,6 +26,7 @@
 #include <asm/device.h>
 #include <asm/io.h>
 #include <asm/gic.h>
+#include <asm/suspend.h>
 #include <asm/vgic.h>
 #include <asm/acpi.h>
 
@@ -44,6 +45,11 @@ static void __init __maybe_unused build_assertions(void)
 void register_gic_ops(const struct gic_hw_operations *ops)
 {
     gic_hw_ops = ops;
+
+#ifdef CONFIG_SYSTEM_SUSPEND
+    if ( !ops->suspend || !ops->resume )
+        host_system_suspend_disable("GIC driver lacks suspend support");
+#endif
 }
 
 static void clear_cpu_lr_mask(void)
diff --git a/xen/arch/arm/include/asm/psci.h b/xen/arch/arm/include/asm/psci.h
index bb3c73496e..142fa1bfe5 100644
--- a/xen/arch/arm/include/asm/psci.h
+++ b/xen/arch/arm/include/asm/psci.h
@@ -24,6 +24,9 @@ void call_psci_cpu_off(void);
 void call_psci_system_off(void);
 void call_psci_system_reset(void);
 int call_psci_system_suspend(void);
+#ifdef CONFIG_SYSTEM_SUSPEND
+bool psci_system_suspend_allowed(void);
+#endif
 
 /* Range of allocated PSCI function numbers */
 #define	PSCI_FNUM_MIN_VALUE                 _AC(0,U)
diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h
index c848fc6340..50dc6e9fdf 100644
--- a/xen/arch/arm/include/asm/suspend.h
+++ b/xen/arch/arm/include/asm/suspend.h
@@ -39,7 +39,15 @@ extern struct resume_cpu_context resume_cpu_context;
 
 int prepare_resume_ctx(void);
 void hyp_resume(void);
-#endif /* CONFIG_SYSTEM_SUSPEND */
+bool host_system_suspend_allowed(void);
+void host_system_suspend_disable(const char *reason);
+
+#else /* !CONFIG_SYSTEM_SUSPEND */
+
+static inline bool host_system_suspend_allowed(void) { return false; }
+static inline void host_system_suspend_disable(const char *reason) {}
+
+#endif
 
 #endif /* ARM_SUSPEND_H */
 
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index e05dae1133..e9d78668fd 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -41,6 +41,13 @@ static bool __ro_after_init has_psci_system_suspend;
 
 #define PSCI_RET(res)   ((int32_t)(res).a0)
 
+#ifdef CONFIG_SYSTEM_SUSPEND
+bool psci_system_suspend_allowed(void)
+{
+    return has_psci_system_suspend;
+}
+#endif
+
 int call_psci_cpu_on(int cpu)
 {
     struct arm_smccc_res res;
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index 6ea4a0f9cc..c7c26bcf03 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -1,9 +1,49 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include <asm/psci.h>
 #include <asm/suspend.h>
 
+#include <xen/lib.h>
+#include <xen/serial.h>
+
 struct resume_cpu_context resume_cpu_context;
 
+/*
+ * Non-PSCI infrastructure can make host suspend impossible even when the PSCI
+ * SYSTEM_SUSPEND conduit is present, e.g. when a Xen-owned driver has no valid
+ * suspend/resume path.
+ *
+ * This gate is checked only when the last awake control domain attempts to
+ * turn a guest SYSTEM_SUSPEND request into a host-suspend request.
+ */
+static bool __ro_after_init host_system_suspend_runtime_allowed = true;
+
+static bool host_serial_suspend_allowed(void)
+{
+    if ( serial_suspend_supported() )
+        return true;
+
+    printk_once(XENLOG_INFO
+                "Host SYSTEM_SUSPEND blocked: serial unsupported\n");
+
+    return false;
+}
+
+bool host_system_suspend_allowed(void)
+{
+    return psci_system_suspend_allowed() &&
+           host_serial_suspend_allowed() &&
+           host_system_suspend_runtime_allowed;
+}
+
+void host_system_suspend_disable(const char *reason)
+{
+    host_system_suspend_runtime_allowed = false;
+
+    printk(XENLOG_INFO "Host SYSTEM_SUSPEND blocked: %s\n",
+           reason ? reason : "unsupported suspend/resume path");
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index ac6af6118f..a41355d75d 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -5,6 +5,7 @@
 
 #include <asm/current.h>
 #include <asm/domain.h>
+#include <asm/suspend.h>
 #include <asm/vgic.h>
 #include <asm/vpsci.h>
 #include <asm/event.h>
@@ -219,6 +220,89 @@ static void do_psci_0_2_system_reset(void)
     domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+/*
+ * Serialise SYSTEM_SUSPEND policy decisions with the domain suspend transition,
+ * so multiple control domains cannot all observe each other as still awake.
+ */
+static DEFINE_SPINLOCK(vpsci_system_suspend_lock);
+
+static bool domain_in_suspend_state(struct domain *d)
+{
+    bool suspended;
+
+    spin_lock(&d->shutdown_lock);
+    suspended = domain_shutdown_completed(d) && (d->shutdown_code == SHUTDOWN_suspend);
+    spin_unlock(&d->shutdown_lock);
+
+    return suspended;
+}
+
+static int32_t domain_psci_system_suspend_policy(struct domain *d)
+{
+    struct domain *other;
+    bool last_awake_control_domain = true;
+    bool awake_non_control_domain = false;
+
+    /* Only control domains participate in sequencing policy. */
+    if ( !is_control_domain(d) )
+        return 0;
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( other )
+    {
+        bool suspended;
+
+        if ( other == d )
+            continue;
+
+        suspended = domain_in_suspend_state(other);
+        if ( suspended )
+            continue;
+
+        if ( is_control_domain(other) )
+        {
+            last_awake_control_domain = false;
+            break;
+        }
+
+        awake_non_control_domain = true;
+    }
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    /*
+     * Another control domain is still awake. This request is only the first
+     * phase of the sequencing: park this control domain and leave the host
+     * running. Host-wide suspend gates must not block this intermediate state.
+     */
+    if ( !last_awake_control_domain )
+        return 0;
+
+    /*
+     * This is the last awake control domain. It must not be parked unless the
+     * request can proceed as a host-suspend request; otherwise Xen would lose
+     * the last domain that can coordinate the system suspend.
+     */
+    if ( awake_non_control_domain )
+    {
+        printk(XENLOG_DEBUG
+               "SYSTEM_SUSPEND denied for %pd: non-control domains awake\n",
+               d);
+        return PSCI_DENIED;
+    }
+
+    /*
+     * Host-wide gates are relevant only for the last-control-domain case. They
+     * must not block parking of a non-last control domain, but they must deny
+     * the last control domain when host suspend is not currently available.
+     */
+    if ( !host_system_suspend_allowed() )
+        return PSCI_DENIED;
+
+    return 0;
+}
+
 static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
 {
     int32_t rc;
@@ -232,10 +316,6 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
     if ( is_64bit_domain(d) && is_thumb )
         return PSCI_INVALID_ADDRESS;
 
-    /* SYSTEM_SUSPEND is not supported for the hardware domain yet */
-    if ( is_hardware_domain(d) )
-        return PSCI_NOT_SUPPORTED;
-
     /* Ensure that all CPUs other than the calling one are offline */
     domain_lock(d);
     for_each_vcpu ( d, v )
@@ -252,16 +332,29 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
     if ( rc )
         return PSCI_DENIED;
 
-    rc = domain_shutdown(d, SHUTDOWN_suspend);
+    spin_lock(&vpsci_system_suspend_lock);
+
+    rc = domain_psci_system_suspend_policy(d);
+    if ( !rc )
+    {
+        rc = domain_shutdown(d, SHUTDOWN_suspend);
+        if ( rc )
+            rc = PSCI_DENIED;
+        else
+        {
+            rctx->ctxt = ctxt;
+            rctx->wake_cpu = current;
+        }
+    }
+
+    spin_unlock(&vpsci_system_suspend_lock);
+
     if ( rc )
     {
         free_vcpu_guest_context(ctxt);
-        return PSCI_DENIED;
+        return rc;
     }
 
-    rctx->ctxt = ctxt;
-    rctx->wake_cpu = current;
-
     gprintk(XENLOG_DEBUG,
             "SYSTEM_SUSPEND requested, epoint=%#"PRIregister", cid=%#"PRIregister"\n",
             epoint, cid);
@@ -287,10 +380,9 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
     case PSCI_0_2_FN32_SYSTEM_RESET:
     case PSCI_1_0_FN32_PSCI_FEATURES:
     case ARM_SMCCC_VERSION_FID:
-        return 0;
     case PSCI_1_0_FN32_SYSTEM_SUSPEND:
     case PSCI_1_0_FN64_SYSTEM_SUSPEND:
-        return is_hardware_domain(current->domain) ? PSCI_NOT_SUPPORTED : 0;
+        return 0;
     default:
         return PSCI_NOT_SUPPORTED;
     }
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index da80fdba84..52bd98f7ad 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -140,6 +140,9 @@ config HAS_EX_TABLE
 config HAS_FAST_MULTIPLY
 	bool
 
+config HAS_HWDOM_SYSTEM_SUSPEND
+	bool
+
 config HAS_IOPORTS
 	bool
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e16f1ac383..10c358c7aa 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1377,6 +1377,11 @@ void __domain_crash(struct domain *d)
     domain_shutdown(d, SHUTDOWN_crash);
 }
 
+static inline bool want_hwdom_shutdown(uint8_t reason)
+{
+    return !IS_ENABLED(CONFIG_HAS_HWDOM_SYSTEM_SUSPEND) ||
+           reason != SHUTDOWN_suspend;
+}
 
 int domain_shutdown(struct domain *d, u8 reason)
 {
@@ -1393,7 +1398,7 @@ int domain_shutdown(struct domain *d, u8 reason)
         d->shutdown_code = reason;
     reason = d->shutdown_code;
 
-    if ( is_hardware_domain(d) )
+    if ( is_hardware_domain(d) && want_hwdom_shutdown(reason) )
         hwdom_shutdown(reason);
 
     if ( domain_shutting_down(d) )
diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c
index cf0abf1893..1cdf4968ac 100644
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -490,6 +490,8 @@ const struct vuart_info *serial_vuart_info(int idx)
 
 #ifdef CONFIG_SYSTEM_SUSPEND
 
+static bool __ro_after_init serial_suspend_available = true;
+
 void serial_suspend(void)
 {
     int i;
@@ -506,6 +508,11 @@ void serial_resume(void)
             com[i].driver->resume(&com[i]);
 }
 
+bool serial_suspend_supported(void)
+{
+    return serial_suspend_available;
+}
+
 #endif /* CONFIG_SYSTEM_SUSPEND */
 
 void __init serial_register_uart(int idx, struct uart_driver *driver,
@@ -514,6 +521,11 @@ void __init serial_register_uart(int idx, struct uart_driver *driver,
     /* Store UART-specific info. */
     com[idx].driver = driver;
     com[idx].uart   = uart;
+
+#ifdef CONFIG_SYSTEM_SUSPEND
+    if ( !driver->suspend || !driver->resume )
+        serial_suspend_available = false;
+#endif
 }
 
 void __init serial_async_transmit(struct serial_port *port)
diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c
index 100545e23f..461e01703e 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -19,6 +19,7 @@
 #include <xen/device_tree.h>
 #include <xen/iommu.h>
 #include <xen/lib.h>
+#include <xen/suspend.h>
 
 #include <asm/device.h>
 
@@ -46,6 +47,11 @@ void __init iommu_set_ops(const struct iommu_ops *ops)
     }
 
     iommu_ops = ops;
+
+#ifdef CONFIG_SYSTEM_SUSPEND
+    if ( !ops->suspend || !ops->resume )
+        host_system_suspend_disable("IOMMU driver lacks suspend support");
+#endif
 }
 
 int __init iommu_hardware_setup(void)
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c
index 7f1d00fb81..16947a12f2 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -91,6 +91,7 @@
 #include <asm/io.h>
 #include <asm/iommu_fwspec.h>
 #include <asm/platform.h>
+#include <asm/suspend.h>
 
 #include "smmu-v3.h"
 
@@ -1866,6 +1867,7 @@ static void arm_smmu_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
 
 static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
 {
+	static bool __ro_after_init host_suspend_blocked_by_msi;
 	struct msi_desc *desc;
 	int ret, nvec = ARM_SMMU_MAX_MSIS;
 	struct device *dev = smmu->dev;
@@ -1910,6 +1912,13 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
 		}
 	}
 
+	if ( !host_suspend_blocked_by_msi )
+	{
+		host_suspend_blocked_by_msi = true;
+		host_system_suspend_disable(
+			"SMMUv3 MSI IRQ path is unsupported for host suspend");
+	}
+
 	/* Add callback to free MSIs on teardown */
 	devm_add_action(dev, arm_smmu_free_msis, dev);
 }
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 8e18445552..418b00ead0 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -137,6 +137,7 @@ const struct vuart_info* serial_vuart_info(int idx);
 /* Serial suspend/resume. */
 void serial_suspend(void);
 void serial_resume(void);
+bool serial_suspend_supported(void);
 #endif
 
 /*
diff --git a/xen/include/xen/suspend.h b/xen/include/xen/suspend.h
index 6f94fd53b0..a941331035 100644
--- a/xen/include/xen/suspend.h
+++ b/xen/include/xen/suspend.h
@@ -6,6 +6,8 @@
 #if __has_include(<asm/suspend.h>)
 #include <asm/suspend.h>
 #else
+struct domain;
+
 static inline void arch_domain_resume(struct domain *d) {}
 #endif
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 14:32:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 14:32:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400692.1636338 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9n-0007be-JF; Thu, 27 Aug 2026 14:32:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400692.1636338; Thu, 27 Aug 2026 14:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzb9n-0007av-8S; Thu, 27 Aug 2026 14:32:43 +0000
Received: by outflank-mailman (input) for mailman id 1400692;
 Thu, 27 Aug 2026 14:32:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Mykola_Kvach@epam.com>) id 1wzb9l-0007R7-8N
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 14:32:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzb9k-009cUS-LG
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:32:40 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a78-bab6-0a2a0a5309dd-0a2a450ca9d8-44
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:40 +0200
Received: from [52.101.69.140]
 (helo=AM0PR83CU005.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Mykola_Kvach@epam.com>)
 id 6a904a88-f479-0a2a450c0019-3465458c71ef-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 16:32:40 +0200
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18)
 by AS8PR03MB6742.eurprd03.prod.outlook.com (2603:10a6:20b:295::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 14:32:39 +0000
Received: from AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com
 ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 14:32:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=T8kVmw4b3XnOTTSq1x6XVEEJufmxxPuap7gf+AJ701tDbyv63zYAIMSyFQx5MyumfgdM2/txpn0MECXNCDskZLeJu6y5QJpTDfyVC1eArodnM4YuwSt0AxYm9gl455FVkL4mkRFiQbLK4WaN6oO/ZNFMmcgvl6mI8ggFOQP0f6WJ0+fahjjbx3EAXVhZvHLlkabVh2ifGMzMbkfGM0vkcyaKD5LHVZGG1owumtZzz7lJDORZBHVUHMminHIuW+u+XBJZdwim5Oyu9bPEavVy18UDCWE89RbggWLj2GUvp/3ksnYuurdYGvlXP8DHOj+MO7gsWndcqPKoCwZtXpBAWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ysoieNwLBuP61lAhmYXVgWNFPxkgEMgRS+eiqfsijP0=;
 b=p8u8auMHcmtHsHTChFgl9NSy1xw9/ZZiuS/qoIRPFC/Q/jNQNomRoZWLFSfeFgbENdA7OIuZl5+7nnA7CiPKE0gB20ltEKSUGHGH0NQrdZcvkQVE3VSHhI5i9qmyZfJSlmcA43qvGULgY405B86/B+BB5gxw42gwQAwYkGFWCvm0C8719kT2NFV3kQxsUDC7ogEbTzBEoF87h2HsxcQeMPpaZIwLWJpnyruBvu4Cy9fV7ytu1gi3PYLjKtFbnHtZIdG6WAxzZU/mLHKSWoWUJ2M/LDz60vX+AjcCPHBUQd+TV57rzttCTXvTQMwgXEQiBNIujzwCv1qd8opJiZEfyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ysoieNwLBuP61lAhmYXVgWNFPxkgEMgRS+eiqfsijP0=;
 b=XUV4tACvUjDkmStJ7lO7cf6evOrd0tURVMNnf5zr2f9Ati0SETPl9xVySNB3rh1KN3C+4OFg/fIgPizBh/xPVd7NfVKUm+nVzAhMG8QOPhvFANAhVtCj8wpvGtOHUyypsFSPhfQFUjnyAyszeGELqoDbOBRPYbJHtnz72MjiklhsMcSqvlp4aIwq6eV3nfYl0zvMp/Xuw7olVX+XD+1I58QYpT8xLhsWD7pB8ty7qwHMy+FfCIlkLcpXKfEomzxJs2U5huiyzOcjC5y0MbUFEnQXURA5lLEwM5AklhUYLkpgq0L3Dq6UE8H7ONGYQBvDhcDmnpHvKlSXbZNwlnFqyA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
From: Mykola Kvach <mykola_kvach@epam.com>
To: xen-devel@lists.xenproject.org
Cc: Mykola Kvach <mykola_kvach@epam.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v12 13/13] xen/arm: Add host system suspend backend
Date: Thu, 27 Aug 2026 17:32:01 +0300
Message-ID: <9d3cf11530edf478ae7a597f1c0934f4b7b1a270.1787838455.git.mykola_kvach@epam.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <cover.1787838455.git.mykola_kvach@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: WA0P291CA0018.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::15) To AS8PR03MB9746.eurprd03.prod.outlook.com
 (2603:10a6:20b:61d::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS8PR03MB6742:EE_
X-MS-Office365-Filtering-Correlation-Id: cb991339-216a-465b-d7c2-08df04480b6a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|3023799007|22082099003|18002099003|11063799006|5023799004|56012099006;
X-Microsoft-Antispam-Message-Info:
	6+lvntYOdSlRwPe1GqKL4v8MK7H/AqkBADk6rk6/d6jWfX9TvyDe0Zdn5AtulpXEhrNL/xTKyIdh+6wWHl2kuvksyEnOJcpEfphCQU4F2LeAxiPoksfQfu1jIO5czuaQrsI1OlIkTPo5zvjEsgMP5g/BYs28VqwDSjcZdADgt1Kpx87QfoX7u9KpkgoYfIKoGjBmObkZ1WHceg88SKy4N2TFwlUBJrZKx5J78YYBVwD4Hx0yICEL90roXzHndeqsV4RY30Oi6uSHGzLVgnaSEsVtB4LojyvGVnj+AsnQnWoSgJEBPKpDgkq1ejAHSj9Ajjbs/9m49NSsaCMOx1SC0j7qcvWkUQJJe/yfERoBLdD7SUCNRZQsPRHDD0dYcY2b2MdkU636DsvcuPq6xb54wQGNA6cXIgm49wJ+24Ccq9Wc4mhUiZy/21+Nsabp5R0Zsm76LH70WwYz94zLcwqZrE6iyCxN3WaX+0qBo4hCtPyvMeI88YkDQAnhh4rLgTJIepCj4ioGivSu8qyoWa+eB7hTs7vM3SAmT24SozWLIHLhloL3uhnmI4ne0njBN9SIwUNJ50HKDbAExswNxKbmKJrss1t9J4Xl8BLayYZ+qVGiSQzuNVdtyqSMUO94p/MXmXepG2Y5N7Yo07JbRaP38xWbSpy4E6VZQNzw710F/cQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(3023799007)(22082099003)(18002099003)(11063799006)(5023799004)(56012099006);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?52g2ttpuEgIDwdKf5+FOMe3op1dwgDLQy0sKyhNZY8c92baL5XsAz1vaVS3b?=
 =?us-ascii?Q?3YqdIpva8lTuYClF4CzcKB10oT1xauIrIfFGU5F9NNwz0xwrcSQBFWtIrh/H?=
 =?us-ascii?Q?YFb7nRT9NnB9ybcadHDiPHxbn9tnIjbhGCL7tS9WBCWXk82oHHqNcyN93e1n?=
 =?us-ascii?Q?lUmeCT6vnVgrjfxV2dnvoYuGBFfy7aQGsFzerc3rHZkCqBvNyS+yYYRXi65F?=
 =?us-ascii?Q?t6wIXPjJyEJ5ASomOAYOTzVDnXa/zbIuSAqWgHFKVNcBJwAZY/mB7j1iwD69?=
 =?us-ascii?Q?CUjjP4e+88dSCXrmh7Cj2K7q//UPZeanvQ1j85LUjivoNNq9e+qhwkd+m7Fq?=
 =?us-ascii?Q?Jw09EONSNA/umK9DT/2w1CbQPf84PYjRVS/0T+CiaOOvxu7iQ/JI4tmFAeLG?=
 =?us-ascii?Q?60umPLx1AFnz+5vjVghj1hEDOjMK+SwbOCicfbUZopgVcXwCp77hwIC4PeRR?=
 =?us-ascii?Q?mrjX46JE+QDoLvFIB3vPpvkx5X85kJhSdUNvsUV71hWmb1GOh4q/J+uIk+10?=
 =?us-ascii?Q?8JgsYRtDc08Bx+SMJUiZFjipB9sk7u72aofXyTXeBBUnQNou0iDwnWSt3kNT?=
 =?us-ascii?Q?R/UQr7hxQDosLi6Zn3WHKF2UkKnO6g1jA7QQxPBuV3SK8kw1YKkEgHbxWlLd?=
 =?us-ascii?Q?Dz5LPTjPZJeEACNQdfB4+GRKgB+KCJsf6nK+77RJ945paEu3cB5YG2Ufnmdo?=
 =?us-ascii?Q?twjyq91sVRCRwjgFvCilda7K2NnrgPGvBGD5KONBL8QOnxhqu4GPhGl3yY85?=
 =?us-ascii?Q?zZXPEjRKywX5ksLD4Uap2d748gk/+/U9XYcdoIorUXdxBDVG3d8wJlbn5v3L?=
 =?us-ascii?Q?pd11vULDLrXwnUhG4hpWiq2REAu0RFERX0EPQEkrfAskpKUjit/3EPYjWEjy?=
 =?us-ascii?Q?rG4m98zUPanc6hStyJmvZFBYeMgA8zuYoBukyUyEfK1oXNlPNw0yL0UaiH0h?=
 =?us-ascii?Q?Zmam0kFXW9DdESj3/1yompmLop2GL4ztdkIV/KLO8pweiYUB9f3Riy0GN4Ru?=
 =?us-ascii?Q?qDfKUdjtPbrhI6NHSu4vsQaeN0dPc1xNfM/lQpJP1VTb3/6adsxpDgP5yMw7?=
 =?us-ascii?Q?xuloZcFoXc4SnObkDz52ao6xZ7FCpjckGCcsLHaXRFjizEHTR40ZyQKa9AY7?=
 =?us-ascii?Q?XGCO/izxXAEbex07xvA8bh9VE0M3/yA9By0k7vKCa1GjEwtxg4Yill6QKnHJ?=
 =?us-ascii?Q?0zpjQQoSYp3Y3XIhGKVjV4qTL6I1pLeez+icwGKQltZyh86ILSBEQEu32D4+?=
 =?us-ascii?Q?v2+Pp0YTHOmlWvpXbvQ9UdxTU5OehhNC3dOuJm2k8csm+biPzHuRl1Q5lWBv?=
 =?us-ascii?Q?G6POD3BD0Uu5IyRPzx32NhuSRnHUdHjlRuovAL1Ywclx7JW0BTTkKm/BxzvG?=
 =?us-ascii?Q?zQEqFqfQWM7bDGam2bW9IH06I+lRxN8iz0zHz07M8HEdyXHEVWYXtsfXDg/e?=
 =?us-ascii?Q?TVtVbMW2EPsn0V/MKI3ZDl0GFxctDgyeMiqZx0sygUX+28gbOlC/HB/Bpvol?=
 =?us-ascii?Q?CyWRuueQo4qC+AtD4hFViABnYZbf8nAAFIOUX21WpN81x0O4ni5JmeJjT4JX?=
 =?us-ascii?Q?SOuzvCbYJB/i/E4OyjhJQPIzeI9chOBs3R2IhUVCboBGl/v1Rq091VkjPKDt?=
 =?us-ascii?Q?3QWP2xd0QEVpZE6YwrZwsOCknzfqIshEFvOL3Gf5Qjh8xap/UsOym7KKu6vb?=
 =?us-ascii?Q?LpnUnQlemziHEiypeI7hQKysAabBEq7rwQ5hvdmCgxYNI+wfs9kbEcecNYdl?=
 =?us-ascii?Q?2yg08PE5OQ=3D=3D?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb991339-216a-465b-d7c2-08df04480b6a
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 14:32:38.7177
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: itrksI7d7A1dJR61Uo5+4ayonXZaw0TKIInO1v4fBbHKYRslJ2g6S2+HpoCr5oegQDnJ5IBcJeH9Z1RakutPZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6742
X-purgate-ID: tlsNG-d25034/1787841160-77AD4A5B-11064161/0/0
X-purgate-type: clean
X-purgate-size: 13927

From: Mirela Simonovic <mirela.simonovic@aggios.com>

Add the Xen-wide suspend/resume backend used after a control-domain
vPSCI SYSTEM_SUSPEND request has been accepted. The vPSCI policy,
runtime driver blockers and control-domain sequencing checks are handled
by the preceding commit; this change adds the code that actually drives
the host suspend attempt.

The backend runs from a tasklet scheduled on pCPU0, because non-boot CPUs
are disabled during suspend. It freezes domains, disables the scheduler
and then disables non-boot CPUs.

Host-side suspend participants are handled in phases. IOMMU and console
state are suspended first. Local IRQs are then disabled before suspending
timer and GIC state. On resume or failure, the completed suspend phases
are unwound in reverse: GIC and timer state are restored while IRQs are
still disabled, local IRQs are restored, and then console and IOMMU state
are restored.

On boot, init_ttbr is normally initialized during secondary CPU hotplug.
On uniprocessor systems this can leave init_ttbr uninitialized, so set it
from the boot CPU before entering suspend.

Note: the code is behind CONFIG_HAS_SYSTEM_SUSPEND, which is currently
only selected when UNSUPPORTED is set and MPU is not set.

Signed-off-by: Mirela Simonovic <mirela.simonovic@aggios.com>
Signed-off-by: Saeed Nowshadi <saeed.nowshadi@xilinx.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in V10:
- Re-apply boot CPU local errata/workaround handling after SYSTEM_SUSPEND,
  before resuming the rest of the host suspend path.
- Move set_init_ttbr() declaration to asm/mmu/mm.h, since it is
  MMU-specific.

Changes in V9:
- Split vPSCI availability policy, runtime host-suspend blockers and the
  domain-readiness precheck into the preceding commit.
- Trigger the host suspend backend from the control-domain SYSTEM_SUSPEND
  path.
- Reorder the host suspend/resume phases so the timer is suspended with
  local IRQs disabled and local IRQs are restored after the GIC and timer
  resume paths, before the console and IOMMU resume paths.
- Move HAS_HWDOM_SYSTEM_SUSPEND and related logic to policy patch.

Changes in V8:
- Add a pre-suspend check in system_suspend() after scheduler_disable() to
  require all domains to be in the shut down state with SHUTDOWN_suspend
  before proceeding with the global suspend flow.
- Drop the common-level depends on !ARM_64 || !SYSTEM_SUSPEND from
  CONFIG_HAS_HWDOM_SHUTDOWN_ON_SUSPEND and model the ARM64 suspend case
  with an arch-selected capability instead.
- Rename CONFIG_HAS_HWDOM_SHUTDOWN_ON_SUSPEND to
  CONFIG_HAS_HWDOM_SYSTEM_SUSPEND.
- Rename need_hwdom_shutdown() to want_hwdom_shutdown().

Changes in V7:
- Control domain is responsible for host suspend.
- Add an empty inline host_system_suspend() function when SYSTEM_SUSPEND
  config is disabled.
- Use IS_ENABLED() for config checking instead of #ifdef.
- Replace #ifdef checks in domain_shutdown() with IS_ENABLED() to simplify
  control flow.
- Factor hardware domain shutdown condition into a helper
  (need_hwdom_shutdown()) to avoid preprocessor directives inside the
  function.
- Squash with iommu suspend/resume commit.
---
 xen/arch/arm/Kconfig                 |   1 +
 xen/arch/arm/cpuerrata.c             |   7 +-
 xen/arch/arm/include/asm/cpuerrata.h |   1 +
 xen/arch/arm/include/asm/mmu/mm.h    |   2 +
 xen/arch/arm/include/asm/suspend.h   |   2 +
 xen/arch/arm/mmu/smpboot.c           |   2 +-
 xen/arch/arm/suspend.c               | 156 +++++++++++++++++++++++++++
 xen/arch/arm/vpsci.c                 |  10 +-
 8 files changed, 177 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 9027aa17eb..da1585ec50 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -9,6 +9,7 @@ config ARM_64
 	select 64BIT
 	select HAS_DOMAIN_TYPE
 	select HAS_FAST_MULTIPLY
+	select HAS_SYSTEM_SUSPEND if !MPU && UNSUPPORTED
 	select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH
 
 config ARM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 3a32183618..e6499aaab3 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -782,6 +782,11 @@ void check_local_cpu_errata(void)
     update_cpu_capabilities(arm_errata, "enabled workaround for");
 }
 
+int enable_local_cpu_errata_workarounds(void)
+{
+    return enable_nonboot_cpu_caps(arm_errata);
+}
+
 void __init enable_errata_workarounds(void)
 {
     enable_cpu_capabilities(arm_errata);
@@ -818,7 +823,7 @@ static int cpu_errata_callback(struct notifier_block *nfb,
          * fixed to expect an error at CPU_STARTING phase.
          */
         ASSERT(system_state != SYS_STATE_boot);
-        rc = enable_nonboot_cpu_caps(arm_errata);
+        rc = enable_local_cpu_errata_workarounds();
         break;
     default:
         break;
diff --git a/xen/arch/arm/include/asm/cpuerrata.h b/xen/arch/arm/include/asm/cpuerrata.h
index 1799a16d7e..b93521326f 100644
--- a/xen/arch/arm/include/asm/cpuerrata.h
+++ b/xen/arch/arm/include/asm/cpuerrata.h
@@ -5,6 +5,7 @@
 #include <asm/alternative.h>
 
 void check_local_cpu_errata(void);
+int enable_local_cpu_errata_workarounds(void);
 void enable_errata_workarounds(void);
 
 #define CHECK_WORKAROUND_HELPER(erratum, feature, arch)         \
diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/asm/mmu/mm.h
index 7f4d59137d..ee73a77777 100644
--- a/xen/arch/arm/include/asm/mmu/mm.h
+++ b/xen/arch/arm/include/asm/mmu/mm.h
@@ -110,6 +110,8 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
 extern void switch_ttbr(uint64_t ttbr);
 extern void relocate_and_switch_ttbr(uint64_t ttbr);
 
+void set_init_ttbr(lpae_t *root);
+
 #endif /* __ARM_MMU_MM_H__ */
 
 /*
diff --git a/xen/arch/arm/include/asm/suspend.h b/xen/arch/arm/include/asm/suspend.h
index 50dc6e9fdf..889a6509d9 100644
--- a/xen/arch/arm/include/asm/suspend.h
+++ b/xen/arch/arm/include/asm/suspend.h
@@ -41,11 +41,13 @@ int prepare_resume_ctx(void);
 void hyp_resume(void);
 bool host_system_suspend_allowed(void);
 void host_system_suspend_disable(const char *reason);
+void host_system_suspend(struct domain *d);
 
 #else /* !CONFIG_SYSTEM_SUSPEND */
 
 static inline bool host_system_suspend_allowed(void) { return false; }
 static inline void host_system_suspend_disable(const char *reason) {}
+static inline void host_system_suspend(struct domain *d) {}
 
 #endif
 
diff --git a/xen/arch/arm/mmu/smpboot.c b/xen/arch/arm/mmu/smpboot.c
index 37e91d72b7..ff508ecf40 100644
--- a/xen/arch/arm/mmu/smpboot.c
+++ b/xen/arch/arm/mmu/smpboot.c
@@ -72,7 +72,7 @@ static void clear_boot_pagetables(void)
     clear_table(boot_third);
 }
 
-static void set_init_ttbr(lpae_t *root)
+void set_init_ttbr(lpae_t *root)
 {
     /*
      * init_ttbr is part of the identity mapping which is read-only. So
diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
index c7c26bcf03..3fe2ffa4fb 100644
--- a/xen/arch/arm/suspend.c
+++ b/xen/arch/arm/suspend.c
@@ -1,10 +1,18 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include <asm/cpuerrata.h>
+#include <asm/cpufeature.h>
+#include <asm/gic.h>
 #include <asm/psci.h>
 #include <asm/suspend.h>
 
+#include <xen/console.h>
+#include <xen/cpu.h>
+#include <xen/iommu.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <xen/serial.h>
+#include <xen/tasklet.h>
 
 struct resume_cpu_context resume_cpu_context;
 
@@ -44,6 +52,154 @@ void host_system_suspend_disable(const char *reason)
            reason ? reason : "unsupported suspend/resume path");
 }
 
+/* Xen suspend. data identifies the domain that initiated suspend. */
+static void system_suspend(void *data)
+{
+    int status;
+    unsigned long flags;
+    struct domain *d = (struct domain *)data;
+
+    BUG_ON(system_state != SYS_STATE_active);
+
+    system_state = SYS_STATE_suspend;
+
+    printk("Xen suspending...\n");
+
+    freeze_domains();
+    scheduler_disable();
+
+    /*
+     * Non-boot CPUs have to be disabled on suspend and enabled on resume
+     * (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI
+     * CPU_OFF to be called by each non-boot CPU. Depending on the underlying
+     * platform capabilities, this may lead to the physical powering down of
+     * CPUs.
+     */
+    status = disable_nonboot_cpus();
+    if ( status )
+    {
+        system_state = SYS_STATE_resume;
+        goto resume_nonboot_cpus;
+    }
+
+    console_start_sync();
+    status = iommu_suspend();
+    if ( status )
+    {
+        system_state = SYS_STATE_resume;
+        goto resume_end_sync;
+    }
+
+    status = console_suspend();
+    if ( status )
+    {
+        dprintk(XENLOG_ERR, "Failed to suspend the console, err=%d\n", status);
+        system_state = SYS_STATE_resume;
+        goto resume_iommu;
+    }
+
+    local_irq_save(flags);
+
+    time_suspend();
+
+    status = gic_suspend();
+    if ( status )
+    {
+        system_state = SYS_STATE_resume;
+        goto resume_time;
+    }
+
+    set_init_ttbr(xen_pgtable);
+
+    /*
+     * Enable identity mapping before entering suspend to simplify
+     * the resume path
+     */
+    update_boot_mapping(true);
+
+    if ( prepare_resume_ctx() )
+    {
+        status = call_psci_system_suspend();
+        /*
+         * If suspend is finalized properly by above system suspend PSCI call,
+         * the code below in this 'if' branch will never execute. Execution
+         * will continue from hyp_resume which is the hypervisor's resume point.
+         * In hyp_resume CPU context will be restored and since link-register is
+         * restored as well, it will appear to return from prepare_resume_ctx.
+         * The difference in returning from prepare_resume_ctx on system suspend
+         * versus resume is in function's return value: on suspend, the return
+         * value is a non-zero value, on resume it is zero. That is why the
+         * control flow will not re-enter this 'if' branch on resume.
+         */
+        if ( status )
+            dprintk(XENLOG_WARNING, "PSCI system suspend failed, err=%d\n",
+                    status);
+
+        system_state = SYS_STATE_resume;
+    }
+    else
+    {
+        system_state = SYS_STATE_resume;
+
+        /*
+         * CPU0 resumes directly from hyp_resume(), bypassing the CPU hotplug
+         * path that re-checks and re-enables errata workarounds for secondary
+         * CPUs.
+         */
+        check_local_cpu_errata();
+        check_local_cpu_features();
+        BUG_ON(enable_local_cpu_errata_workarounds());
+    }
+
+    update_boot_mapping(false);
+
+    gic_resume();
+
+ resume_time:
+    time_resume();
+
+    local_irq_restore(flags);
+
+    console_resume();
+
+ resume_iommu:
+    iommu_resume();
+
+ resume_end_sync:
+    console_end_sync();
+
+ resume_nonboot_cpus:
+    /*
+     * The rcu_barrier() has to be added to ensure that the per cpu area is
+     * freed before a non-boot CPU tries to initialize it (_free_percpu_area()
+     * has to be called before the init_percpu_area()). This scenario occurs
+     * when non-boot CPUs are hot-unplugged on suspend and hotplugged on resume.
+     */
+    rcu_barrier();
+    enable_nonboot_cpus();
+
+    scheduler_enable();
+    thaw_domains();
+
+    system_state = SYS_STATE_active;
+
+    printk("Resume (status %d)\n", status);
+
+    domain_resume(d);
+}
+
+static DECLARE_TASKLET(system_suspend_tasklet, system_suspend, NULL);
+
+void host_system_suspend(struct domain *d)
+{
+    system_suspend_tasklet.data = (void *)d;
+    /*
+     * The suspend procedure has to be finalized by the pCPU#0 (non-boot pCPUs
+     * will be disabled during the suspend).
+     */
+    tasklet_schedule_on_cpu(&system_suspend_tasklet, 0);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index a41355d75d..5134e75c24 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -237,7 +237,8 @@ static bool domain_in_suspend_state(struct domain *d)
     return suspended;
 }
 
-static int32_t domain_psci_system_suspend_policy(struct domain *d)
+static int32_t domain_psci_system_suspend_policy(struct domain *d,
+                                                 bool *host_suspend)
 {
     struct domain *other;
     bool last_awake_control_domain = true;
@@ -300,6 +301,7 @@ static int32_t domain_psci_system_suspend_policy(struct domain *d)
     if ( !host_system_suspend_allowed() )
         return PSCI_DENIED;
 
+    *host_suspend = true;
     return 0;
 }
 
@@ -310,6 +312,7 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
     struct vcpu *v;
     struct domain *d = current->domain;
     bool is_thumb = epoint & 1;
+    bool host_suspend = false;
     struct resume_info *rctx = &d->arch.resume_ctx;
 
     /* THUMB set is not allowed with 64-bit domain */
@@ -334,7 +337,7 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
 
     spin_lock(&vpsci_system_suspend_lock);
 
-    rc = domain_psci_system_suspend_policy(d);
+    rc = domain_psci_system_suspend_policy(d, &host_suspend);
     if ( !rc )
     {
         rc = domain_shutdown(d, SHUTDOWN_suspend);
@@ -359,6 +362,9 @@ static int32_t do_psci_1_0_system_suspend(register_t epoint, register_t cid)
             "SYSTEM_SUSPEND requested, epoint=%#"PRIregister", cid=%#"PRIregister"\n",
             epoint, cid);
 
+    if ( host_suspend )
+        host_system_suspend(d);
+
     return rc;
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400812.1636377 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt8-0003h2-8o; Thu, 27 Aug 2026 15:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400812.1636377; Thu, 27 Aug 2026 15:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt8-0003gt-63; Thu, 27 Aug 2026 15:19:34 +0000
Received: by outflank-mailman (input) for mailman id 1400812;
 Thu, 27 Aug 2026 15:19:32 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt5-0003SX-Sm
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbt5-00C6eJ-9B
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:31 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90556f-8faa-0a2a0a5109dd-0a2a45029182-36
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:31 +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 <oleksii.kurochko@gmail.com>)
 id 6a905583-6ca4-0a2a45020019-d155802bc416-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:31 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49a97714f5dso12076085e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843971; x=1788448771; 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=xSHoAtU8dddLTKoCSKrkez3cQvXSaxG/ZVd2XecEP58=;
        b=jigSFwHCz6gnwy62YTDDCbpStYHF4ILjdNP0zqE6x8Ey2VBtHjW8lVtFEfhso6NzG0
         sg9cqIXbb8gH1DRMXDPR8KfEmXvOlyx1SFtdrqUSHi+LvekUnI+tc02KfC3B0pcO6oJe
         JYy1vXo8bKaXUyVu3AggDPDMdNY1PiTU0wD8sfR1v9xgJ6zL2pLgiLtBKxiqhNs+93Q3
         8BCYuC6SV//FN4GxmbTK2txpIFuOcLEa1Hg6zWKgYwmPIBP0/3jCKvWW+mErRx5izSm8
         zu2g9sJvwcYG++/BoBTAS5tbLFt2kj3/hsX1LDqdG+oerOJjXmPvkpN/LNUavRDOrWOB
         qu5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843971; x=1788448771;
        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=xSHoAtU8dddLTKoCSKrkez3cQvXSaxG/ZVd2XecEP58=;
        b=pz6FDjTNhfFQKVqz3Vm78GUejxW2gRX3+GnRLyatRZH+uwBId6KJ49ZQQrdfL18Keb
         cAaZLP6Qy9fuQ1THkWOZsDDMTmSDGcnGN8aXluRl8t5T8tO22h4OCZbacmnk28WqABH0
         xfqGaxyX48Pz87b52c6hpbcGbhJMYiUYDJVLzohHOtK7f3SOEd7tHR3YzbQWCxekqdMf
         v+aogVhY9CLn7r8Ynn/WYl13moFLJmJMPr714eYZ9fUfGB4YeKy4d19amod5x0nWMxIA
         x2iERH27svGN8G+oBQSrULosLZZu0K0AFXDCofa4sIAW8roC/J28mQW25yc6RnEIasZ8
         cO0Q==
X-Gm-Message-State: AFuF++mlBLQGVPYxErDeGcraaPn/htRWqNnirLmzneGvo5qhx66rHRVs
	Nf91UpX8o1N8h3KwUbI/vhNH5X/5gy/95sob2JgzJHftmdpclBA23U9FzDlMXg==
X-Gm-Gg: AR+sD11QWlvjwhbRF8nUxEOrlRh9Lp2e/+o+8rMS8R/ee1wcHoGQCC6Od7ry+27wa2g
	sZ6pgdlxBiPnnx5u22NO9XfQRCiFDdxOGxdvRImKGvEU4Zu9Jn2wbm5MRHRdLIfJPJ8b0fQQUMo
	lgIIhef5X4rYa4qeJzz44xdLHbJI7OTsQEOmrPqZhSV0DbRo20hTG7+7d7hepKGbPTCQu8PVyU3
	lHthLiIyOj1Qg9myc7r8FU8qoDuVrU+Ioe4aCq1+y72uAW36w6pqf2MGSf8FfMtpyaMtSNrp1WK
	JRb60ri0iD2Yuxl6hDMC1dRrMDOGNMN2VHKRsho0Dxu50BVpqwu25GfayfG8X1sMxZf/tzzDsjB
	tCPkutyUNlL/eTeJSj5X031aPIqmdrWMFWs9KzHS9OGEiRSlROoV1HNAZrvE/K2Qc0nF4s4zl8P
	YkA3FwA+tV4Cubo1liIZpjPDcTD/mBRrbjVOd/Skox3bXtGa0ZX/h4PQkyLv/XYYmrWGHO/On+3
	ivnOWNDwzOMS0zgeTQyZzMOkw2SW5qrGQ==
X-Received: by 2002:a05:600c:5252:b0:49b:9113:e04a with SMTP id 5b1f17b1804b1-49b9113e19amr17664215e9.1.1787843970099;
        Thu, 27 Aug 2026 08:19:30 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 03/20] xen/riscv: Implement construct_domain()
Date: Thu, 27 Aug 2026 17:18:56 +0200
Message-ID: <90ebd418b376cd7b3dc7f234f76f131072417bd9.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787843971-F06A72AC-F38FE7D6/10/73395122804
X-purgate-type: spam
X-purgate-size: 3117

Implement construct_domain() function for RISC-V, which performs initial setup
for the domain's first vCPU, loads the kernel, initrd, and device tree,
and sets up guest CPU registers for boot.

It also creates additional vCPUs up to max_vcpus and assigns the device tree
address and boot cpuid in registers.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v5-v8:
 - Only rebase. Nothing changed.
---
Changes in v4:
 - Drop the blank before v%u in the printk() failure message so the output
   matches that of %pv.
 - Restore Acked-by that was lost in v3.
---
Changes in v3:
 - s/%d/%u for printing vCPU index in the failure message.
 - Drop dprintk() for successful vCPU creation.
---
Changes in v2:
 - Rework construct_domain() to print that vCPU1...n are created using %pv.
 - Use true instead of 1 for initialization of v->is_initialised.
 - Drop unnessary BUG_ON() in construct_domain().
 - Add TODO comment above *_load() functions.
---
---
 xen/arch/riscv/Makefile       |  1 +
 xen/arch/riscv/domain-build.c | 50 +++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+)
 create mode 100644 xen/arch/riscv/domain-build.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 4fcdcf9e24de..2d24670dfc74 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,6 +1,7 @@
 obj-y += aplic.o
 obj-y += cpufeature.o
 obj-y += domain.o
+obj-y += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
new file mode 100644
index 000000000000..5f6f4b6248a5
--- /dev/null
+++ b/xen/arch/riscv/domain-build.c
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include <xen/fdt-domain-build.h>
+#include <xen/fdt-kernel.h>
+#include <xen/init.h>
+#include <xen/sched.h>
+
+#include <asm/current.h>
+#include <asm/guest_access.h>
+
+int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
+{
+    struct vcpu *v = d->vcpu[0];
+    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(v);
+
+    BUG_ON(v->is_initialised);
+
+    /*
+     * At the moment *_load() don't return value and will just panic()
+     * inside.
+     * TODO: it will be good to change that.
+     */
+    kernel_load(kinfo);
+    initrd_load(kinfo, copy_to_guest_phys);
+    dtb_load(kinfo, copy_to_guest_phys);
+
+    regs->sepc = kinfo->entry;
+
+    /* Guest boot cpuid = 0 */
+    regs->a0 = 0;
+    regs->a1 = kinfo->dtb_paddr;
+
+    for ( unsigned int i = 1; i < d->max_vcpus; i++ )
+    {
+        const struct vcpu *tmp_v = vcpu_create(d, i);
+
+        if ( !tmp_v )
+        {
+            printk("Failed to allocate %pdv%u\n", d, i);
+            break;
+        }
+    }
+
+    domain_update_node_affinity(d);
+
+    v->is_initialised = true;
+    clear_bit(_VPF_down, &v->pause_flags);
+
+    return 0;
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400815.1636404 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtB-0004Mo-7o; Thu, 27 Aug 2026 15:19:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400815.1636404; Thu, 27 Aug 2026 15:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtB-0004Mf-3y; Thu, 27 Aug 2026 15:19:37 +0000
Received: by outflank-mailman (input) for mailman id 1400815;
 Thu, 27 Aug 2026 15:19:35 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt9-00044F-N9
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbt9-00Fhjf-4C
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:35 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90556f-e002-0a2a0a5209dd-0a2a4504aa60-48
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:35 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905586-b57f-0a2a45040019-d1558029ade2-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:35 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-49b0dd3c9a0so9183385e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19:35 -0700 (PDT)
Received: from fedora (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843974; x=1788448774; 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=STFNHra9/gv/dSpsPbk0M64rMisoQ8mC24edm4rMW7I=;
        b=fwav/Q4jSfKLP5I8ww1qwdgUhPD0MtMfFWu+OKBM3hE31wwCtkmh6CPcGXQK2Z+gn9
         rXYpNwUWFGVFk/23HI3/c5U8uHFjY+n6k5rY9rYCKp507j9uH8V2u+uoSphO5KNQUGaL
         hMGeDX9ErQIlnBqKt/bb+080NNRvEfefYV7nx/S5/5CPR0Xr83mw/E5duSXnIWiF1wn8
         suMg1vbBGvKwRePYEzKX+v8GMY858fPV423IYIxecERi6MoM+fdqqSPLNgq/kaJSW0Vq
         6TH2YvN8kBRMZA7mNeMCANkngGWGofbR/PlCIVM6Wzy2AS3+7BEyMVmZEDPucbu7LwE+
         wi/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843974; x=1788448774;
        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=STFNHra9/gv/dSpsPbk0M64rMisoQ8mC24edm4rMW7I=;
        b=FWRcNK9/6xfvhKmhIcYMzhI1au1P+9v3xDkFACXtaEXldqE0aD28UnWK1hC9bfKDhc
         LilmBW7GjLj0+b5ECVp+uAFPzgxxh271XXT7ft7jcpX55+sseAbteSg9uYz4BmBkgerw
         tGlvz3z+XirATRCszwx8MMSPzq63YTI0YFy/S8lLPzMp/1hSsR8y7kM3eYY9IrcgS3oL
         D2ZrapH1bNRT5moH4jZO5dlT/Te1Kkgoq6ftL1jdSueIvuqwIpowblIcjewR/qo5Ygtq
         4bHcTKRL3chWmcSnR8j1Gr+C5IS6uJgbM024uC6ryk0QmHRnfGmnRJ4x1gwUk/xUapjG
         EU/g==
X-Gm-Message-State: AFuF++lYhGqaMSXwKOPKFu9QH3tF32MipkxolfVCNzr/7GOw53n5ka4V
	qg5N6r0OYB2bjYJKh4g7jn5aZYnrlEraOcoWRqm3j17DHZT62E+K2CNj7AhJ2A==
X-Gm-Gg: AR+sD13k0eg4RZOf+osTnTSq7/5LixbTtq9w8NxZFmo7dN7mFyHmz6XVYDX65KI1QqQ
	ofWTercjaXdlg8VQnKcqxTcvcOGxd0MlWDdUFZKR1BqMu06A7kE1r3cQaS2ZRMYnk9Pcs/xArGT
	rKM3ksbbmXBdXHXINcIXFaMh2v9dv5DSyTXxPvzWeS6hbwmgns2bhTEC1jzpUsyAOhoSnIWb3S2
	hdwYXCvlIACbsz0o+l0h8yUqE2QWUfVpAUkzT94KlPYsp2G9ph9pmTeQ2QiPNO3sn9MXHOhsr3c
	S5yojlIo9wlKBUYX4vbAafwDFchqXSuJpmdKw5Z4AsJt2pFjepHGKmX2dwD76BV4REgIOzIPTxM
	wLOu3pPhk97Vs0kZIPPY69WKHb0a089nMa3JOe5XcNM4sc8UM6p3aJkRb7bPzaMpSj/pAd0Ba5B
	kOofQlWq/AqvuDnq9j0BHv5IKt8newibnsaoUhw30lrcSCA06f4ZCO+W7VceFaMZKPNh9Crv9Pj
	lwh0idB04axLgw+0UtrY4AIVJHOrWSm
X-Received: by 2002:a05:600c:46cc:b0:49b:909e:922e with SMTP id 5b1f17b1804b1-49b909e92aamr34144205e9.10.1787843974248;
        Thu, 27 Aug 2026 08:19:34 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 06/20] xen/riscv: implement make_timer_node()
Date: Thu, 27 Aug 2026 17:18:59 +0200
Message-ID: <b4182eb14902863f7a13c02a989d4db0fe7f820e.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787843975-510DDB50-74627B63/10/73395122804
X-purgate-type: spam
X-purgate-size: 1618

Generally, in DT for RISC-V there is a document which describes a timer
node (riscv,timer.yaml or sifive,clint.yaml), but the Linux timer driver
is declared with TIMER_OF_DECLARE(riscv_timer, "riscv", ...).
It matches the CPU node (compatible "riscv"), not the timer node itself.
It then calls of_find_compatible_node(NULL, NULL, "riscv,timer") only to
read the optional riscv,timer-cannot-wake-cpu property.

Since Xen does not care about that property for now, make_timer_node() is
implemented to return 0, as no timer node needs to be created for RISC-V
guests.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3-8:
 - Nothing changed. Only rebase.
---
Changes in v2:
 - Acked-by: Jan Beulich <jbeulich@suse.com>
 - Update the commit message.
---
---
 xen/arch/riscv/domain-build.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
index 1af4c48fb30c..d7613721db95 100644
--- a/xen/arch/riscv/domain-build.c
+++ b/xen/arch/riscv/domain-build.c
@@ -3,6 +3,7 @@
 #include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/fdt-kernel.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/sched.h>
 
@@ -154,3 +155,10 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
 
     return fdt_end_node(fdt);
 }
+
+int __init make_timer_node(const struct kernel_info *kinfo)
+{
+    /* There is no need for timer node for RISC-V. */
+
+    return 0;
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400813.1636381 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt8-0003jz-HF; Thu, 27 Aug 2026 15:19:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400813.1636381; Thu, 27 Aug 2026 15:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt8-0003jT-D7; Thu, 27 Aug 2026 15:19:34 +0000
Received: by outflank-mailman (input) for mailman id 1400813;
 Thu, 27 Aug 2026 15:19:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt6-0003cU-PJ
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbt6-004jSy-5z
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:32 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90555c-bab6-0a2a0a5309dd-0a2a4505b6ea-40
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:32 +0200
Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905583-4cb1-0a2a45050019-d155dd2af0c8-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:32 +0200
Received: by mail-wr1-f42.google.com with SMTP id
 ffacd0b85a97d-47f59f25ec4so1184763f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843971; x=1788448771; 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=5FTZ/zgLxaDF0xhm1MbqyrNw+Htw5MQMnzKgTC6ue3Y=;
        b=Zsygbn9FWAId3yuh+IRD0TlI7CnIqpHJaNG1UiVrovfxJrbQjtwO1/vrcWv0CrqIhR
         0DGlLe+0ZUB7G9bucR+G/U6PZlHYRIHGc58eqSeFjrxzQmdSaY6WtIat9BEGqjiIX5oC
         neuETQLIkOvswDx7LDSRdxZs6bVEP/GYQ7GFWkU1ac0mdiQG9laSoG+Bxk2xPonbCUX/
         QkGQ8gLaEBDDfcJN4zug0pEZm7I6usO/oV/30fo0eSqxiPZcoNYUTgEUwy23bRiJr+xx
         8WNLpttTnBv8jBu7TWhNduGKcHHbNsrZwSR5oLYxzOQ5PIRYFD7l9zGILq2aaq5nFzod
         BiFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843971; x=1788448771;
        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=5FTZ/zgLxaDF0xhm1MbqyrNw+Htw5MQMnzKgTC6ue3Y=;
        b=Ql26JcE7ofq/N6GdHNjnzFyDVkE+wgaCqGyImJYHybEZ315h1sNIATJW8BVro08IU0
         2EdgG5optTKL2hNJCAGZn7KbMdf6GAt4CjDePT4T7HoV7uHOxkKL22J67OOqDTgLDsxA
         dhq2IkpD1aSvxxoGksfOE4oh0HNu4USQJO47p0bAP1L2Pjkkaae4n6O3GtVXnft2uQEU
         4grs4vQWWpCNQIawfMpGlNGRCeknN34DyIN4Og844tmPw0/EdfJ6a97e6h21tQB3yFiG
         UAwBSVep3j4PnqaDFwSMd9+ZojdKrZxrRpzfmfcFaEwjpiWlkHTep0DOkOo1Kh8S96Ir
         otRw==
X-Gm-Message-State: AFuF++lnQ7N6nXtWlsr/2UA7sSdqvrDrlBNj34apt8JT/AUgtGi8npjr
	W4oLsl7x96Vg66hckUuTs9KRd+p8xLhlTvOG+NoI5gXOfP6N4s0v8oRasIASlg==
X-Gm-Gg: AR+sD13xrpUAsLSIDM2OImf+x+BHhUibL1Oddi7p7+SGjoZaDETMRr9b1kC089Dw/Nk
	lXbo0oK2rbt0gwjWwKslvk1C10LOM/tFLjFFXMRggmE8TobG6zXiw3Zu/t7YiJjJxluWELtA1R9
	xjk9u07AuhHEklAeymVCtXYH17YLLF0xo0bvxcS3aKWuUJIN5GmeNTNMV2eH9NnSUJaH3Tr00Js
	/ZxfP81i9NT6RBqO8hXA3Qd4cyZ6eBTkFAtNWBj4ydCYk/MLv6EHz1VqOVEjCGXntDWu80QKDwr
	J3VSGp+sjDzg1rR/hIxYwBTAVFpDm/MUT9BnRQ6uVkF6ywy6DE/jm90RHembFA5TZZuFoFmTBxA
	JVMS3+UHRegbWo7ACZr2FCFjFIoQ0MIUZCBaBAWn6Kq2J6nNfs6+FU+F507u9Rq3rA+ELz2WcwJ
	rCsuoshfV58nqdWTU0fy05WgEU4ayrwn/EHZfkoLMy410VxX83kSoRGqZq4hzuFspqN3Bwo8xMD
	0LrpcdmqX6zkrPGm9hMSdruD9aVG9HU
X-Received: by 2002:a05:6000:22c2:b0:482:e658:bb7f with SMTP id ffacd0b85a97d-482e658bdafmr14865213f8f.15.1787843971337;
        Thu, 27 Aug 2026 08:19:31 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 04/20] xen/riscv: introduce guest riscv,isa string
Date: Thu, 27 Aug 2026 17:18:57 +0200
Message-ID: <2eb660bd05c6bf5946a7eae09406266db0c5108f.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787843972-F7ABF2A1-64796977/10/73395122804
X-purgate-type: spam
X-purgate-size: 16987

Introduce build_guest_isa_str() to generate the riscv,isa string to be
passed to the guest via the Device Tree riscv,isa property.

Introduce the per-domain guest ISA bitmap, populated during domain
creation by calling init_guest_isa().

Introduce struct riscv_isa_ext_entry with a new guest_flags field
to filter out ISA extensions that should not be exposed to guests:

- f/d/q/v: FPU and vector context save/restore are not yet implemented
  for guests.
- Z*inx are not exposed either: they aren't in riscv_isa_ext[], so they
  can never be set in riscv_isa and thus never reach a guest, and no
  current hardware/guest-OS advertises or expects them. Supporting them
  would be cheaper than F/D/Q (FP values stay in integer registers Xen
  already context-switches), but is left as future work.
- h: Nested virtualisation is not supported.
- sstc: Xen owns the supervisor timer; guests must use SBI.
- svade: Xen manages hardware A/D bit updates in stage-2 page tables.
- svpbmt: Page-based memory types are not yet wired up in stage-2 code.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v8:
- Replace struct riscv_isa_ext_entry's bool guest_supported with an
  unsigned int guest_flags bitmask (RISCV_ISA_EXT_GUEST_{NONE,RV32,RV64,ANY}),
  so an extension can be withheld from guests of one XLEN only; select the
  bit matching the guest's width with RISCV_ISA_EXT_GUEST_XLEN in
  compute_guest_isa(). Guests are currently of the same width as Xen, so
  RISCV_ISA_EXT_GUEST_XLEN is derived from CONFIG_RISCV_{32,64} for now.
- Add some spaces between # and "error" in build_guest_isa_str().
---
Changes in v7:
- build_guest_isa_str(): drop the struct domain argument and work directly on
  the guest_isa bitmap; make the function static as it has no external users
  anymore.
- build the guest "riscv,isa" string only once, in compute_guest_isa(), and
  store it in an __ro_after_init pointer, instead of rebuilding it for every
  domain: all domains are currently given the same guest ISA, so apply here
  the same reasoning as for the guest_isa bitmap.
- panic() on length calculation, allocation or formatting failure, in line
  with the rest of riscv_fill_hwcap() initialization.
- introduce get_guest_isa_str() accessor and expose it in asm/cpufeature.h
  instead of build_guest_isa_str().
---
Changes in v6:
- build_guest_isa_str() now takes a `const struct domain *d` instead of a
  raw `const unsigned long *isa_bitmap`, to leave room for using more than
  just the bitmap in the future.
- Compute the guest-visible ISA bitmap once at boot, into a new
  __ro_after_init `guest_isa` bitmap (compute_guest_isa(), called at the
  end of riscv_fill_hwcap()), instead of re-deriving it from
  riscv_isa_ext[] on every domain creation in init_guest_isa(). All guests
  currently get the same extension set, so this avoids repeating
  identical work per domain; will need revisiting if/when per-domain ISA
  policy is introduced.
- struct arch_domain's `isa` field is now `const unsigned long *isa`
  instead of an embedded bitmap; init_guest_isa() just points it at the
  shared `guest_isa` bitmap rather than copying bits into a per-domain
  array.
- Mark riscv_isa_ext[] __initconstrel, since its entries hold name pointers
  and the need for relocations requires that the compiler emit the data to
  a writable section.
- Make build_guest_isa_str() __init as it is called during make_cpus_node()
  which is used only (at least, for now) in build time of domain.
---
Changes in v5:
- Introduce struct riscv_isa_ext_entry with a guest_supported field and
  RISCV_ISA_EXT_ENTRY(name, guest_supp) macro for riscv_isa_ext[],
  replacing the ad-hoc guest_unsupp bitmap and init_guest_unsupp().
  Every entry now carries an explicit true/false decision, enforced at
  compile time.
- init_guest_isa() builds d->arch.isa by iterating riscv_isa_ext[]
  directly instead of using bitmap_andnot() against guest_unsupp.
- init_guest_isa() changed to void as it can no longer fail.
- Drop isa_str from struct arch_domain; the ISA string does not need to
  persist over the domain lifetime. build_guest_isa_str() is made
  non-static and declared in cpufeature.h for use when building the
  guest device tree.
- Updated the fix of underflow in build_guest_isa_str().
- Drop unnecessary empty line in cpufeature.h before enum riscv_isa_ext_id.
---
Changes in v4:
 - Add an explicit overflow guard in build_guest_isa_str(): return
   -ENOSPC when buf is non-NULL and total >= size, to avoid the
   size - total underflow being passed to snprintf().
 - Expand the commit message to explain why Zfinx/Zdinx/Zqinx are not
   added to guest_unsupp (not in riscv_isa_ext[], so never set in
   riscv_isa nor exposed to a guest; left as future work)
---
Changes in v3:
 - s/set_bit/__set_bit in init_guest_unsupp() as atomicity isn't needed at
   init time.
 - Drop RISCV_GUEST_ISA_STR_MAX; allocate isa_str dynamically with
   xvmalloc_array().
 - Drop "guest" prefix from d->arch.guest_isa and d->arch.guest_isa_str.
 - Introduce build_guest_isa_str() using snprintf(NULL, 0, ...) to determine
   the needed buffer size; init_guest_isa() calls it once for sizing and once
   to fill, keeping both in a single function so they can't go out of sync.
 - Scope ret inside the loop; initialize total directly from the prefix
   snprintf().
 - Merge "_" separator and extension name into a single snprintf() with
   "%s%s".
 - Replace ASSERT with an explicit error check: if the fill call returns a
   different length, free isa_str and return -EINVAL.
---
Changes in v2:
 - s/guest_unsupp_bmp/guest_unsupp.
 - Drop guest_isa_str.
 - Provide init_guest_isa() instead of polluting match_isa_ext().
 - Drop xlen.
 - Add the comment about guest_unsupp.
 - Update the way how guest_unsupp is init-ed.
 - Drop __initconst for riscv_isa_ext[] as it is used in init_guest_isa()
   which isn't marked as __init as it could be used after init stage.
---
---
 xen/arch/riscv/cpufeature.c             | 200 +++++++++++++++++++++---
 xen/arch/riscv/domain.c                 |   2 +
 xen/arch/riscv/include/asm/cpufeature.h |   5 +
 xen/arch/riscv/include/asm/domain.h     |   3 +
 4 files changed, 186 insertions(+), 24 deletions(-)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 92235fdfd5ab..4bcbf56cb694 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -14,7 +14,9 @@
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <xen/sections.h>
+#include <xen/xvmalloc.h>
 
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
@@ -34,9 +36,64 @@ struct riscv_isa_ext_data {
     .name = #ext_name,                          \
 }
 
+/*
+ * Which guests an extension may be handed out to, by guest XLEN.
+ *
+ * These flags express Xen's policy, not the ISA's rules: extensions which
+ * are architecturally tied to one XLEN (Zilsd on RV32, say) need no special
+ * treatment here, as they can only ever appear in the "riscv,isa" of a host
+ * of that XLEN, and guest_isa is masked against the host ISA bitmap anyway.
+ * They are only of use for extensions Xen chooses not to expose to guests of
+ * a given width despite the hardware implementing them.
+ */
+#define RISCV_ISA_EXT_GUEST_NONE 0
+#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0)
+#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1)
+#define RISCV_ISA_EXT_GUEST_ANY  (RISCV_ISA_EXT_GUEST_RV32 | \
+                                  RISCV_ISA_EXT_GUEST_RV64)
+
+/*
+ * Guests are of the same width as Xen itself for the time being; once guest
+ * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain
+ * property, just as guest_isa below does.
+ */
+#if defined(CONFIG_RISCV_32)
+#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32
+#elif defined(CONFIG_RISCV_64)
+#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64
+#else
+# error "Unsupported RISC-V bitness"
+#endif
+
+struct riscv_isa_ext_entry {
+    unsigned int id;
+    const char *name;
+    unsigned int guest_flags;
+};
+
+#define RISCV_ISA_EXT_ENTRY(ext_name, guest_flgs)       \
+{                                                       \
+    .id          = RISCV_ISA_EXT_ ## ext_name,          \
+    .name        = #ext_name,                           \
+    .guest_flags = guest_flgs,                          \
+}
+
 /* Host ISA bitmap */
 static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
 
+/*
+ * ISA bitmap handed out to every guest.
+ *
+ * All guests are given the same extensions for the time being, so this is
+ * computed once out of riscv_isa_ext[] and riscv_isa, rather than redoing
+ * the walk for every domain created.  Should per-domain ISA policy ever be
+ * introduced, this will need to become per-domain again.
+ */
+static __ro_after_init DECLARE_BITMAP(guest_isa, RISCV_ISA_EXT_MAX);
+
+/* "riscv,isa" string corresponding to guest_isa, shared by all domains. */
+static char *__ro_after_init guest_isa_str;
+
 static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
                                          unsigned long *dt_cpuid)
 {
@@ -120,29 +177,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu,
  * and strncmp() is used in match_isa_ext() to compare extension names instead
  * of strncasecmp().
  */
-const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
-    RISCV_ISA_EXT_DATA(i),
-    RISCV_ISA_EXT_DATA(m),
-    RISCV_ISA_EXT_DATA(a),
-    RISCV_ISA_EXT_DATA(f),
-    RISCV_ISA_EXT_DATA(d),
-    RISCV_ISA_EXT_DATA(q),
-    RISCV_ISA_EXT_DATA(c),
-    RISCV_ISA_EXT_DATA(h),
-    RISCV_ISA_EXT_DATA(zicntr),
-    RISCV_ISA_EXT_DATA(zicsr),
-    RISCV_ISA_EXT_DATA(zifencei),
-    RISCV_ISA_EXT_DATA(zihintpause),
-    RISCV_ISA_EXT_DATA(zihpm),
-    RISCV_ISA_EXT_DATA(zba),
-    RISCV_ISA_EXT_DATA(zbb),
-    RISCV_ISA_EXT_DATA(zbs),
-    RISCV_ISA_EXT_DATA(smaia),
-    RISCV_ISA_EXT_DATA(smstateen),
-    RISCV_ISA_EXT_DATA(ssaia),
-    RISCV_ISA_EXT_DATA(sstc),
-    RISCV_ISA_EXT_DATA(svade),
-    RISCV_ISA_EXT_DATA(svpbmt),
+static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = {
+    RISCV_ISA_EXT_ENTRY(i,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(m,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(a,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(f,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(d,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(q,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(c,            RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(v,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(h,            RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(zicntr,       RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zicsr,        RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zifencei,     RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zihintpause,  RISCV_ISA_EXT_GUEST_ANY),
+    RISCV_ISA_EXT_ENTRY(zihpm,        RISCV_ISA_EXT_GUEST_ANY),
+    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(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),
+    RISCV_ISA_EXT_ENTRY(sstc,         RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(svade,        RISCV_ISA_EXT_GUEST_NONE),
+    RISCV_ISA_EXT_ENTRY(svpbmt,       RISCV_ISA_EXT_GUEST_NONE),
 };
 
 static const struct riscv_isa_ext_data __initconst required_extensions[] = {
@@ -181,7 +239,7 @@ static void __init match_isa_ext(const char *name, const char *name_end,
 
     for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ )
     {
-        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
+        const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];
 
         /*
          * `ext->name` (according to initialization of riscv_isa_ext[]
@@ -480,6 +538,98 @@ bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
     return test_bit(id, isa_bitmap);
 }
 
+static int __init build_guest_isa_str(char *buf, size_t size)
+{
+    char *p = buf;
+    size_t left = size;
+    int total;
+
+#if defined(CONFIG_RISCV_32)
+    total = snprintf(p, left, "rv32");
+#elif defined(CONFIG_RISCV_64)
+    total = snprintf(p, left, "rv64");
+#else
+#   error "Unsupported RISC-V bitness"
+#endif
+
+    if ( total < 0 )
+        return total;
+
+    if ( buf )
+    {
+        if ( (size_t)total >= left )
+            return -ENOSPC;
+
+        p += total;
+        left -= total;
+    }
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(riscv_isa_ext); i++ )
+    {
+        const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];
+        int ret;
+
+        if ( !riscv_isa_extension_available(guest_isa, ext->id) )
+            continue;
+
+        ret = snprintf(p, left, "%s%s",
+                       ext->id >= RISCV_ISA_EXT_BASE ? "_" : "",
+                       ext->name);
+        if ( ret < 0 )
+            return ret;
+
+        total += ret;
+
+        if ( buf )
+        {
+            if ( (size_t)ret >= left )
+                return -ENOSPC;
+
+            p += ret;
+            left -= ret;
+        }
+    }
+
+    return total;
+}
+
+static void __init compute_guest_isa(void)
+{
+    int len;
+
+    for ( unsigned int i = 0; i < ARRAY_SIZE(riscv_isa_ext); i++ )
+    {
+        const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i];
+
+        if ( (ext->guest_flags & RISCV_ISA_EXT_GUEST_XLEN) &&
+             riscv_isa_extension_available(NULL, ext->id) )
+            __set_bit(ext->id, guest_isa);
+    }
+
+    /*
+     * All domains are given the same guest ISA, so the "riscv,isa" string
+     * is built only once here and then shared by all of them.
+     */
+    if ( (len = build_guest_isa_str(NULL, 0)) < 0 )
+        panic("Failed to calculate guest \"riscv,isa\" length: %d\n", len);
+
+    if ( !(guest_isa_str = xvmalloc_array(char, len + 1)) )
+        panic("Failed to allocate guest \"riscv,isa\" string\n");
+
+    if ( build_guest_isa_str(guest_isa_str, len + 1) != len )
+        panic("Failed to build guest \"riscv,isa\" string\n");
+}
+
+void init_guest_isa(struct domain *d)
+{
+    d->arch.isa = guest_isa;
+}
+
+const char *get_guest_isa_str(void)
+{
+    return guest_isa_str;
+}
+
 void __init riscv_fill_hwcap(void)
 {
     unsigned int i;
@@ -527,4 +677,6 @@ void __init riscv_fill_hwcap(void)
     if ( !all_extns_available )
         panic("Look why the extensions above are needed in "
               "https://xenbits.xenproject.org/docs/unstable/misc/riscv/booting.txt\n");
+
+    compute_guest_isa();
 }
diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c
index 2819ff4e7c92..c9933147595e 100644
--- a/xen/arch/riscv/domain.c
+++ b/xen/arch/riscv/domain.c
@@ -308,6 +308,8 @@ int arch_domain_create(struct domain *d,
     if ( is_idle_domain(d) )
         return 0;
 
+    init_guest_isa(d);
+
     if ( (rc = p2m_init(d, config)) != 0)
         goto fail;
 
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
index 0c48d57a03bb..2973eb13a513 100644
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -5,6 +5,7 @@
 #ifndef __ASSEMBLER__
 
 #include <xen/stdbool.h>
+#include <xen/types.h>
 
 /*
  * These macros represent the logical IDs of each multi-letter RISC-V ISA
@@ -44,7 +45,11 @@ enum riscv_isa_ext_id {
     RISCV_ISA_EXT_MAX
 };
 
+struct domain;
+
 void riscv_fill_hwcap(void);
+void init_guest_isa(struct domain *d);
+const char *get_guest_isa_str(void);
 
 bool riscv_isa_extension_available(const unsigned long *isa_bitmap,
                                    enum riscv_isa_ext_id id);
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index 6044ce0feee0..8ae01a5e4dcc 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -7,6 +7,7 @@
 #include <xen/xmalloc.h>
 #include <public/hvm/params.h>
 
+#include <asm/cpufeature.h>
 #include <asm/guest-layout.h>
 #include <asm/p2m.h>
 #include <asm/vtimer.h>
@@ -94,6 +95,8 @@ struct arch_domain {
     struct p2m_domain p2m;
 
     struct paging_domain paging;
+
+    const unsigned long *isa;
 };
 
 #include <xen/sched.h>
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400810.1636359 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt3-0003FW-O3; Thu, 27 Aug 2026 15:19:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400810.1636359; Thu, 27 Aug 2026 15:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt3-0003FP-L2; Thu, 27 Aug 2026 15:19:29 +0000
Received: by outflank-mailman (input) for mailman id 1400810;
 Thu, 27 Aug 2026 15:19:28 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt2-0003Bn-8h
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbt1-00Fhg7-Li
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:27 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90556f-e002-0a2a0a5209dd-0a2a4504aa60-42
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:27 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90557f-b57f-0a2a45040019-d155dd2bade2-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:27 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-482db627cd8so1023923f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843967; x=1788448767; 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=MSA2XSuQON0U1rePCfP+E/HBswfjDsdSbSkNg0cOA2o=;
        b=gsViz1e/yMOUknwCO8JNqfXR6+P1FT5WlYtAWYP6ATIXAhUlwfIZbylEXfIhjQrN+Y
         I3ut/Zq6flJMbFtlhhbg2vevUveu8Aj4gweSqpBOFlMwFHovsw+Oa0IcrweIrYhpScoi
         QepUUbG+2UNlmq4QZCnto/7IRhmlxNjhO4gQ4qXrmkLYG90UutGsaut3KvmRppKCWM+G
         qY+uhZX+QF6D3fVvxGsjF+o6e4PWa77QzBUn8a3AwOluixhfFqov9excJbKms0NEyq2f
         QH458kZkSD7/yPg0ZcCUbf9z+4XAjBIbupstuLlpFIDLh3TyEVrOdvxS0oQBwrByjS6T
         7udA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843967; x=1788448767;
        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=MSA2XSuQON0U1rePCfP+E/HBswfjDsdSbSkNg0cOA2o=;
        b=APRn8GD2O+WKDOdWG1uYyNF+Ql9xdSogra7PPSs8HdPjMmLL3wUGQTeNjlYcUSWRSv
         lSXubyrxg+Rl7Qfc1zfa/h7jQFacVq8NGaPmVdE0ZNCLf6Mwc/FOk5CJJBXC+xHGWzB8
         894TweFson+eCdOMgWJyi6wpfTRMSCK4irmN+XBkqhbbIV/k+Nipx3H45hKK5rVlgHxF
         LHr2W+xFJRoFYN2EUGJK38fiEf6LLFEwiUNxLYzCCBQ12+5jfSVC8kmT0+ccfd3M1Yr4
         Zn6HLtbX3pZbleSRmfvgFqvaKrDUFLn9NzvJ4ZsOHLl2/uNhK107yxwO7GaSdTpSINP2
         fQ5Q==
X-Gm-Message-State: AFuF++lwF2pawGFbkMkbf23zfEK616wJFF78xg4P8FeWb0UCydDyZbNf
	7SX5KIISCW7va+0ZD3z8vQZZReYFp2gP3FOhmR4gxe2LFP/EAH+U4UjGdmvx4g==
X-Gm-Gg: AR+sD12kYhSCFyRM1N5SWv0TQwV8MWnfnKdPnXA36UcWJ07eqDalBuW3SnP94GMzWQH
	R7S8gwieED0YfvMt9TC6uIt/BrRc6rLH8mjo58obqTWNz2B0Qg/eNinUXPOKqQVNfPPOSARRq8u
	/u0MR/Yo+Ji7WNUZp213QOEm4HaAaR6IiAczz4K4+Uwjs1TYIsfrrbG7NlnUoJu4wbffqPF9g9z
	ocQL5ffVxopwI5ZDKt3TqVfvbO+v6PI0BTu2WhXMIVyT0Zl31mL4YMWu4LQl5Xc+ZE06LiG3I1C
	yxUfK75Ti2pXgdf9AL/oqRgNn30breW4B6R64MeEe30xq3qKeNqIkzUljslP/PIGfhq462LSQwr
	zoDqfkxJh4yT+XxBVFLWpZNDGi8bIQqJ8PLoD42//Be8QgW/AHrvpeku7TBXvsBb/LiOMGEOORJ
	AkFVN7qX/sry38bwvp9s0zThFoWPMamAQGJ+hW+DFWcL7Gbb+CA7T+Yx0pxBAEcmyOr7gRo8jTH
	0qOcxP0cOtv39kajEmzP0hfr/SYlcpcHw==
X-Received: by 2002:a05:6000:1889:b0:482:f653:395c with SMTP id ffacd0b85a97d-482f6533a6amr944485f8f.16.1787843966521;
        Thu, 27 Aug 2026 08:19:26 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v8 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page
Date: Thu, 27 Aug 2026 17:18:54 +0200
Message-ID: <5241d1e3f1f1fcaf0c3655d37a5c2d3ec5594711.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787843967-C2ECEB50-A727C7A4/10/73395122804
X-purgate-type: spam
X-purgate-size: 19135

On architectures that run guests in dom0less mode without the PV ABI
(currently RISC-V), no shared_info page is allocated and d->shared_info
remains NULL throughout the domain lifetime.  Several places in common
code access d->shared_info through the shared_info() macro or directly,
causing UBSAN null-pointer errors on such architectures.

Rather than adding runtime NULL guards that are logically unreachable
on x86 and Arm (where shared_info is always allocated), introduce a new
Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm.

On !HAS_SHARED_INFO the shared_info() macro expands to a dereference
of shared_info_absent, an extern pointer that is declared but
intentionally never defined.  Any use of shared_info() that is not
dead-code-eliminated will therefore cause a link-time failure, making
missed guards impossible to overlook.

The 2L event-channel ops call shared_info() and must not be compiled on
architectures without a shared_info page, so event_2l.o is gated on
CONFIG_HAS_SHARED_INFO.  On such architectures evtchn_init() installs the
FIFO ops as a placeholder instead, so that a later guest opt-in to the
FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO
support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated
no-op evtchn_port_ops_none table is installed instead, so that
d->evtchn_port_ops is never NULL.  evtchn_fifo_word_from_port() is
guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe
before evtchn_fifo_init_control() is called by the guest.

With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global
dummy_vcpu_info, so writes through vcpu_info() could leak data between
vCPUs. Reviewing the write paths in common code: the write in
map_guest_area() stores the constant ~0 so nothing serious would happen
if it were leaked; the event_2l.c paths are not compiled on
!HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the
write in vcpu_info_populate() targets the new mapping buffer, not
dummy_vcpu_info.

Outside common code, the remaining writes are x86 PV-specific, for which
CONFIG_HAS_SHARED_INFO=y. No code changes are needed.

Finally, struct domain's shared_info field itself is gated on
CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL
pointer: every user of it is either arch code for an architecture that
selects HAS_SHARED_INFO, or common code already guarded by the same
Kconfig symbol.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v8:
 - Introduce evtchn_preinit().
 - Update some comments in the code.
 - Add Reviewed-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v7:
 - domctl.c: use a plain #ifdef CONFIG_HAS_SHARED_INFO / #else instead of
   the IS_ENABLED() if/else in getdomaininfo(), and set
   info->shared_info_frame to ~0 in the !HAS_SHARED_INFO case.
 - sched.h: drop struct domain's shared_info field when !HAS_SHARED_INFO,
   rather than keeping a field that can only ever be NULL there. All of
   its users are either in arch code selecting HAS_SHARED_INFO or already
   guarded by CONFIG_HAS_SHARED_INFO, so no further changes are needed.
   Update the commit message accordingly.
---
Changes in v6:
 - s/INVALID_GFN_RAW/gfn_x(INVALID_GFN) as INVALID_GFN_RAW was dropped.
 - event_channel.c: make evtchn_none_init() static, moving the
   evtchn_port_ops_none table and its definition above evtchn_reset(),
   their first caller; move the leftover prototype into the #else arm
   of the same #ifndef guard instead of leaving it as a free-standing
   non-static declaration.
 - event_channel.c: evtchn_reset() now follows the same
   IS_ENABLED(CONFIG_HAS_SHARED_INFO) / IS_ENABLED(CONFIG_EVTCHN_FIFO) /
   else cascade already used by evtchn_init(), rather than assuming the
   FIFO ABI is unconditionally available whenever d->evtchn_fifo was set.
 - event_channel.c: narrow the evtchn_port_ops_none / evtchn_none_init
   guard from !CONFIG_HAS_SHARED_INFO to
   !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO, so the placeholder
   cf_check functions are only built for the one combination that
   actually needs them.
 - event_channel.c: fix the evtchn_port_ops_none comment, which claimed
   the ops were never reachable in practice; they are reached whenever
   an event is delivered to (or queried on) a
   !HAS_SHARED_INFO && !EVTCHN_FIFO domain, they just have no ABI to
   record it in and discard it.
 - event_channel.h / event_fifo.c: drop the static inline
   evtchn_fifo_init_ops() stub for !CONFIG_EVTCHN_FIFO; a plain
   declaration outside the #ifdef/#else is enough, matching the
   treatment already given to evtchn_2l_init() and evtchn_none_init().
   Update the "only call site" comment in event_fifo.c to mention both
   evtchn_init() and evtchn_reset().
---
Changes in v5:
 - drop the static inline evtchn_2l_init() stub for !HAS_SHARED_INFO;
   a plain declaration is enough since the only call sites are guarded by
   IS_ENABLED(CONFIG_HAS_SHARED_INFO) and the dead call is eliminated
   before linking.
 - fix a NULL d->evtchn_port_ops dereference when CONFIG_HAS_SHARED_INFO=n
   and CONFIG_EVTCHN_FIFO=n: evtchn_init() was unconditionally calling
   evtchn_fifo_init_ops(), whose !EVTCHN_FIFO stub leaves d->evtchn_port_ops
   unset.  Gate the FIFO branch on IS_ENABLED(CONFIG_EVTCHN_FIFO) and add
   a dedicated evtchn_port_ops_none table for the remaining case. Stubs
   are shared where signatures permit: evtchn_none_noop covers both
   clear_pending and unmask; evtchn_none_false covers both is_pending and
   is_masked. evtchn_none_init() is called only from event_channel.c, so its
   declaration is kept there rather than in event_channel.h.
 - gate evtchn_fifo_init_ops() on !CONFIG_HAS_SHARED_INFO;
   its only call site is in the IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branch
   of evtchn_init(), which is never reached on HAS_SHARED_INFO=y builds.
---
Changes in v4:
 - event_channel.c: drop the redundant evtchn_fifo_init_ops() in the
   else branch of evtchn_reset(); evtchn_fifo_destroy() does not undo the
   ops installed by evtchn_init(), so only the switch back to 2-level ABI
   needs an explicit call.
 - shared.h: simplify the !HAS_SHARED_INFO shared_info() definition to use
   an undefined "extern struct shared_info *shared_info_absent" instead of
   shared_info_absent() with a typeof cast.
 - Extend the commit description to note that vcpu_info()/__vcpu_info()
   uses were also audited: on !HAS_SHARED_INFO vcpu_info_area.map points at
   dummy_vcpu_info, reads are harmless, and writes in common code do not
   open a cross-domain info-leak side channel, so no code changes are
   needed on that path.
---
Changes in v3:
 - Introduce CONFIG_HAS_SHARED_INFO Kconfig symbol selected by x86
   and Arm; RISC-V does not select it.
 - Gate shared_info() macro on CONFIG_HAS_SHARED_INFO; on
   !HAS_SHARED_INFO it calls shared_info_absent() (declared, never
   defined) so any unguarded use produces a link-time error.
 - Replace runtime if (!d->shared_info) guards with IS_ENABLED() at
   call sites so both branches type-check and dead code is eliminated.
 - Guard shared_info_frame assignment in domctl.c.
 - Gate event_2l.o on CONFIG_HAS_SHARED_INFO; use FIFO ops as
   placeholder on !HAS_SHARED_INFO archs instead of dedicated stub
   ops; guard evtchn_fifo_word_from_port() against uninitialised
   d->evtchn_fifo.
 - Add static inline stubs for evtchn_2l_init() (!HAS_SHARED_INFO)
   and evtchn_fifo_init_ops() (!EVTCHN_FIFO) so call sites can use
   IS_ENABLED() without #ifdef.
 - Drop inaccurate changelog entry about "only FIFO ABI" migration.
 - Update the commit message.
 - Drop R-by: Baptiste ... as some extra checks are added.
---
Changes in v2:
 - Update commit message + subject.
 - Drop Fixes tag.
---
 xen/arch/arm/Kconfig       |  1 +
 xen/arch/x86/Kconfig       |  1 +
 xen/common/Kconfig         |  3 +++
 xen/common/Makefile        |  2 +-
 xen/common/domain.c        |  6 ++---
 xen/common/domctl.c        |  4 +++
 xen/common/event_channel.c | 55 +++++++++++++++++++++++++++++++++++---
 xen/common/event_channel.h |  6 +++++
 xen/common/event_fifo.c    | 18 ++++++++++++-
 xen/common/time.c          |  2 ++
 xen/include/xen/event.h    |  2 +-
 xen/include/xen/sched.h    |  2 ++
 xen/include/xen/shared.h   |  6 +++++
 xen/include/xen/time.h     |  5 ++++
 14 files changed, 104 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 843a43897e7b..d748404e82da 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -20,6 +20,7 @@ config ARM
 	select HAS_DEVICE_TREE_DISCOVERY
 	select HAS_DOM0LESS
 	select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
+	select HAS_SHARED_INFO
 	select HAS_STACK_PROTECTOR
 	select HAS_STATIC_MEMORY
 	select HAS_UBSAN
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3ce0774b8d76..e5535ac48467 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -29,6 +29,7 @@ config X86
 	select HAS_PCI_MSI
 	select HAS_PIRQ
 	select HAS_SCHED_GRANULARITY
+	select HAS_SHARED_INFO
 	imply HAS_SOFT_RESET
 	select HAS_UBSAN
 	select HAS_VMAP
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index da80fdba8469..5b289e444fa5 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -158,6 +158,9 @@ config HAS_PMAP
 config HAS_SCHED_GRANULARITY
 	bool
 
+config HAS_SHARED_INFO
+	bool
+
 config HAS_STATIC_MEMORY
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 6018e256147f..f69d47d18934 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/
 obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += domid.o
-obj-y += event_2l.o
+obj-$(CONFIG_HAS_SHARED_INFO) += event_2l.o
 obj-y += event_channel.o
 obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o
 obj-$(CONFIG_GRANT_TABLE) += grant_table.o
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e16f1ac38396..6b52713518da 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -316,9 +316,9 @@ void vcpu_info_reset(struct vcpu *v)
     struct domain *d = v->domain;
 
     v->vcpu_info_area.map =
-        ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS)
-         ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
-         : &dummy_vcpu_info);
+        IS_ENABLED(CONFIG_HAS_SHARED_INFO) && v->vcpu_id < XEN_LEGACY_MAX_VCPUS
+        ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
+        : &dummy_vcpu_info;
 }
 
 static struct domain *alloc_domain_struct(void)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a6210db4fb97..83405a766a54 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -102,9 +102,13 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info)
 #ifdef CONFIG_MEM_PAGING
     info->paged_pages       = atomic_read(&d->paged_pages);
 #endif
+#ifdef CONFIG_HAS_SHARED_INFO
     info->shared_info_frame =
         gfn_x(mfn_to_gfn(d, _mfn(virt_to_mfn(d->shared_info))));
     BUG_ON(SHARED_M2P(info->shared_info_frame));
+#else
+    info->shared_info_frame = ~0;
+#endif
 
     info->cpupool = cpupool_get_id(d);
 
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a7f9cc5fe0ac..bd03e094d096 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -40,6 +40,54 @@
 
 #define consumer_is_xen(e) (!!(e)->xen_consumer)
 
+#if !defined(CONFIG_HAS_SHARED_INFO) && !defined(CONFIG_EVTCHN_FIFO)
+/*
+ * Placeholder ops for domains with neither a shared_info page nor a FIFO
+ * control block. Such a domain has no ABI to record event state in, so these
+ * are reachable whenever an event is delivered to (or queried on) one of its
+ * ports; they just discard/no-op it. They exist to keep d->evtchn_port_ops
+ * non-NULL.
+ */
+static void cf_check evtchn_none_set_pending(
+    struct vcpu *v, struct evtchn *evtchn) {}
+static void cf_check evtchn_none_noop(
+    struct domain *d, struct evtchn *evtchn) {}
+static bool cf_check evtchn_none_false(
+    const struct domain *d, const struct evtchn *evtchn) { return false; }
+static void cf_check evtchn_none_print_state(
+    struct domain *d, const struct evtchn *evtchn) {}
+
+static const struct evtchn_port_ops evtchn_port_ops_none = {
+    .set_pending   = evtchn_none_set_pending,
+    .clear_pending = evtchn_none_noop,
+    .unmask        = evtchn_none_noop,
+    .is_pending    = evtchn_none_false,
+    .is_masked     = evtchn_none_false,
+    .print_state   = evtchn_none_print_state,
+};
+
+static void evtchn_none_init(struct domain *d)
+{
+    d->evtchn_port_ops = &evtchn_port_ops_none;
+}
+#else /* CONFIG_HAS_SHARED_INFO || CONFIG_EVTCHN_FIFO */
+/*
+ * Declaration only; the call in evtchn_preinit() is DCE'd unless both
+ * configs are off.
+ */
+void evtchn_none_init(struct domain *d);
+#endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */
+
+static void evtchn_preinit(struct domain *d)
+{
+    if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) )
+        evtchn_2l_init(d);
+    else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) )
+        evtchn_fifo_init_ops(d);
+    else
+        evtchn_none_init(d);
+}
+
 /*
  * Lock an event channel exclusively. This is allowed only when the channel is
  * free or unbound either when taking or when releasing the lock, as any
@@ -1324,9 +1372,9 @@ int evtchn_reset(struct domain *d, bool resuming)
         rc = -EAGAIN;
     else if ( d->evtchn_fifo )
     {
-        /* Switching back to 2-level ABI. */
+        /* Switching back to the default ABI. */
         evtchn_fifo_destroy(d);
-        evtchn_2l_init(d);
+        evtchn_preinit(d);
     }
 
     write_unlock(&d->event_lock);
@@ -1625,7 +1673,8 @@ void evtchn_check_pollers(struct domain *d, unsigned int port)
 
 int evtchn_init(struct domain *d, unsigned int max_port)
 {
-    evtchn_2l_init(d);
+    evtchn_preinit(d);
+
     d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX);
 
     d->evtchn = alloc_evtchn_bucket(d, 0);
diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h
index dc94a43cc2dd..423c4ee77bd0 100644
--- a/xen/common/event_channel.h
+++ b/xen/common/event_channel.h
@@ -70,6 +70,12 @@ static inline void evtchn_fifo_destroy(struct domain *d)
 }
 #endif /* CONFIG_EVTCHN_FIFO */
 
+/*
+ * Declaration only when !CONFIG_EVTCHN_FIFO; the call in evtchn_preinit() is
+ * DCE'd in that case.
+ */
+void evtchn_fifo_init_ops(struct domain *d);
+
 #endif /* EVENT_CHANNEL_H */
 
 /*
diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
index 611bf8a78801..e4225b1b668e 100644
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -62,6 +62,9 @@ static inline event_word_t *evtchn_fifo_word_from_port(const struct domain *d,
      */
     smp_rmb();
 
+    if ( unlikely(!d->evtchn_fifo) )
+        return NULL;
+
     if ( unlikely(port >= d->evtchn_fifo->num_evtchns) )
         return NULL;
 
@@ -419,6 +422,18 @@ static const struct evtchn_port_ops evtchn_port_ops_fifo =
     .print_state   = evtchn_fifo_print_state,
 };
 
+/*
+ * evtchn_fifo_init_ops()'s only call site is the
+ * IS_ENABLED(CONFIG_EVTCHN_FIFO) branch of evtchn_preinit(), which is never
+ * reached on HAS_SHARED_INFO=y builds because of DCE.
+ */
+#ifndef CONFIG_HAS_SHARED_INFO
+void evtchn_fifo_init_ops(struct domain *d)
+{
+    d->evtchn_port_ops = &evtchn_port_ops_fifo;
+}
+#endif
+
 static int map_guest_page(struct domain *d, uint64_t gfn, void **virt)
 {
     struct page_info *p;
@@ -561,7 +576,8 @@ static void setup_ports(struct domain *d, unsigned int prev_evtchns)
 
         evtchn = evtchn_from_port(d, port);
 
-        if ( guest_test_bit(d, port, &shared_info(d, evtchn_pending)) )
+        if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) &&
+             guest_test_bit(d, port, &shared_info(d, evtchn_pending)) )
             evtchn->pending = true;
 
         evtchn_fifo_set_priority(d, evtchn, EVTCHN_FIFO_PRIORITY_DEFAULT);
diff --git a/xen/common/time.c b/xen/common/time.c
index 2b8c98e2de76..906fb7c71636 100644
--- a/xen/common/time.c
+++ b/xen/common/time.c
@@ -91,6 +91,7 @@ struct tm gmtime(unsigned long t)
     return tbuf;
 }
 
+#ifdef CONFIG_HAS_SHARED_INFO
 void update_domain_wallclock_time(struct domain *d)
 {
     uint32_t *wc_version;
@@ -119,6 +120,7 @@ void update_domain_wallclock_time(struct domain *d)
 
     spin_unlock(&wc_lock);
 }
+#endif /* CONFIG_HAS_SHARED_INFO */
 
 /* Set clock to <secs,usecs> after 00:00:00 UTC, 1 January, 1970. */
 void do_settime(u64 secs, unsigned int nsecs, u64 system_time_base)
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 930190054cf0..595dedf0792c 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -211,7 +211,7 @@ static bool evtchn_usable(const struct evtchn *evtchn)
 
 void evtchn_check_pollers(struct domain *d, unsigned int port);
 
-/* Close all event channels and reset to 2-level ABI. */
+/* Close all event channels and reset to the default ABI. */
 int evtchn_reset(struct domain *d, bool resuming);
 
 /*
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index e352e2b38e7d..73c54794ac02 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -404,7 +404,9 @@ struct domain
 
     struct vcpu    **vcpu;
 
+#ifdef CONFIG_HAS_SHARED_INFO
     shared_info_t   *shared_info;     /* shared data area */
+#endif
 
     rcu_read_lock_t  rcu_lock;
 
diff --git a/xen/include/xen/shared.h b/xen/include/xen/shared.h
index 5b71342cab32..1589e8793f9d 100644
--- a/xen/include/xen/shared.h
+++ b/xen/include/xen/shared.h
@@ -43,7 +43,13 @@ typedef struct vcpu_info vcpu_info_t;
 
 extern vcpu_info_t dummy_vcpu_info;
 
+#ifdef CONFIG_HAS_SHARED_INFO
 #define shared_info(d, field)      __shared_info(d, (d)->shared_info, field)
+#else
+extern struct shared_info *shared_info_absent;
+#define shared_info(d, field) (((void)(d), shared_info_absent)->field)
+#endif /* CONFIG_HAS_SHARED_INFO */
+
 #define vcpu_info(v, field)        \
         __vcpu_info(v, (vcpu_info_t *)(v)->vcpu_info_area.map, field)
 
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 4db24617a97c..09da150c2a40 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -72,7 +72,12 @@ extern bool NOW_good;
 #define version_update_begin(v) (((v) + 1) | 1)
 #define version_update_end(v)   ((v) + 1)
 extern void update_vcpu_system_time(struct vcpu *v);
+
+#ifdef CONFIG_HAS_SHARED_INFO
 extern void update_domain_wallclock_time(struct domain *d);
+#else
+static inline void update_domain_wallclock_time(struct domain *d) {}
+#endif
 
 extern void do_settime(
     u64 secs, unsigned int nsecs, u64 system_time_base);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400811.1636368 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt5-0003Sf-Ui; Thu, 27 Aug 2026 15:19:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400811.1636368; Thu, 27 Aug 2026 15:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt5-0003SY-Rx; Thu, 27 Aug 2026 15:19:31 +0000
Received: by outflank-mailman (input) for mailman id 1400811;
 Thu, 27 Aug 2026 15:19:30 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt4-0003MP-BT
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbt3-004jSy-Ok
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:29 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90557b-bab6-0a2a0a5309dd-0a2a450a977c-26
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:29 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905581-f2d2-0a2a450a0019-d1558030ecc5-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:29 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49b0d8bc2aaso14134165e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843969; x=1788448769; 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=MsTBeA0ZGq8F3SZViAsXelexLz0mB7PPbJbFhEx+BOM=;
        b=KLfVNLQotvj9GJahZDKXe9Gk85p3LD8yXzeiQVkFJpdkxbx/D5wDYwyX/pc6pDisgV
         ehc55BNamBHdNOHKgIzEngzLTted4Domrkw6mdpbixKZDwTBy1iiUl3WPgi9dq5AoOU9
         xh39Bg6R3R2xLsDohxC7tre9tncfmx0bwgOuqZ48f/FkrLZUoqAmB3tp8rEgn4JPWujE
         5zUQAjWutK5K3E3GeKD0kJv9eP6H8UnaGhhn6li7sIzAlm/V6JZ9GaacRn/qhPx+6kWj
         36Li74HzOK8dzOxO3q4YMhdrmbSSBua3eSi52sv8wZ+1B4Cz43fHCac/UXsGuylqGsO8
         ZQhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843969; x=1788448769;
        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=MsTBeA0ZGq8F3SZViAsXelexLz0mB7PPbJbFhEx+BOM=;
        b=r6tY8HENr36MF+ctLQGuyswg6u0G3RctLJ7oNTSJptph130K2QdQLFYLXsYcY+JZLq
         pL0EynJ81bNX7/mDGu/iasQ1WNir89ATaBDylwzRnmns9EIACn3EqeOvekTSFcZ3ZysZ
         QeVw2YZPtDoHUjz8imOZgmIeh6gYXbxDiGqDZXUZFgRQG5aQyeU66H8oYv2rbF7nGydB
         c8Q9O6vNPvARhcLJTt0QGqwlvNY+n3tpjSXIHH/W3cdN7rdOT1zGSuOSIhCr6VkQeuNH
         MTjV6TAiCmd9iLMTqo+SLkBEUpUx2YNnZ3NnovD6hlkSvQWQTEAhA5d03TDy/kL2W4X0
         eLTw==
X-Gm-Message-State: AFuF++n6aagAZi+pqFbfMWLHbQ6TssAYMYsI/9eP2PmwYLUd/tSnIMdX
	Flj2n5BrDFKv6Yuor6q3XeCAsQc6W4Tm9eQtCObSe8eiTPV59ainTV4qam/7XQ==
X-Gm-Gg: AR+sD10C+pwPRLUjcnBNbKlibsnRpxILDX5nHpwRpTUaLCfbyB22jOtw8sdEmvZqnql
	3fedk174XjgT/vg1FWgO6nnTsXqp/vEkae2r5ZiH9mypks9JbqkYKDlf7fg9iw2EH1pDDP3aWT4
	pEjzQJj3AfJOtK1qaHykQ26A8bNPzb7cNGYix6K55DdeeJTPPdqJJJh9978tX6sAHCanxmh0oCJ
	WpXWvoRZxODfVFzQNANt9qzNqVtGHLMddZ3MK/x71DTlgHWcibOWmx6XhHKzGcHGDhX1UJuSmO9
	5W/B6ZaDwzp/BrsCWpqAnObsFeC+kOzdJTOv5QfLncdYNFrWICQa1ryITg1cOjgw5X1MvlgkdA1
	e/sovbrxGGEm2oQb/cnaPkGXlGVLHcemWh/nzu9KrWd5CYF0ySTd1GjOrNOCkCIOa+nNJFCdRsj
	vhyhZ900Whu74E4gApMSFO4/nRI+mFBl4PJDm+iZ3/Z0QG3wGnUJ2Y7iLMXag49r0qb83bYBD07
	T+Z0jNcKQSeUCPaXzY4+NMGEWhj7I+m
X-Received: by 2002:a05:600c:3144:b0:499:79b9:e220 with SMTP id 5b1f17b1804b1-499dc72548dmr187369945e9.10.1787843968764;
        Thu, 27 Aug 2026 08:19:28 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v8 02/20] xen/dom0less: turn max_init_domid into a common variable
Date: Thu, 27 Aug 2026 17:18:55 +0200
Message-ID: <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787843969-583CCCFC-87C1DADB/10/73395122804
X-purgate-type: spam
X-purgate-size: 5825

Until now every architecture carried its own notion of max_init_domid:
Arm defined a real variable (declared in asm/setup.h, defined in
setup.c), while ppc, riscv and x86 each provided a "#define
max_init_domid (0)" stub in their asm/setup.h. This duplicated the same
declaration across all arches and placed a purely dom0less concept in
arch setup headers.

Now that the dom0less build code lives in common (xen/common/
device-tree/dom0less-build.c sets max_init_domid, and the console
serial-input switcher reads it), there is no reason for the symbol to be
per-arch. Provide a single declaration in <xen/dom0less-build.h>, with
the !CONFIG_DOM0LESS_BOOT stub kept there as well, so there is one source
of truth and the arch headers no longer need to mention it. Update
console.c to include <xen/dom0less-build.h> for the declaration instead
of relying on asm/setup.h.

Place the definition in xen/common/domid.c rather than in dom0less-
build.c. The latter is built as dom0less-build.init.o, i.e. the whole
object is relocated into the .init.* sections and freed after boot,
whereas max_init_domid must outlive boot because it is read at runtime
by the console serial-input switcher. domid.c is always linked (obj-y)
and resides in regular (non-init) sections, so it is a correct home for
the variable. It is marked __ro_after_init since it is only updated
while creating boot-time domains and read-only afterwards, and guarded
by CONFIG_DOM0LESS_BOOT as domid.c itself is unconditional.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-8:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Add Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v4:
 - New patch.
---
---
 xen/arch/arm/include/asm/setup.h   | 2 --
 xen/arch/arm/setup.c               | 2 --
 xen/arch/ppc/include/asm/setup.h   | 2 --
 xen/arch/riscv/include/asm/setup.h | 2 --
 xen/arch/x86/include/asm/setup.h   | 2 --
 xen/common/domid.c                 | 5 +++++
 xen/drivers/char/console.c         | 1 +
 xen/include/xen/dom0less-build.h   | 7 +++++++
 8 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 0adfa4993a8f..2af780512540 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -25,8 +25,6 @@ struct map_range_data
     struct rangeset *irq_ranges;
 };
 
-extern domid_t max_init_domid;
-
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
 
 size_t estimate_efi_size(unsigned int mem_nr_banks);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6310a47d68b6..86532d0a35b6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -62,8 +62,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
 bool __read_mostly acpi_disabled;
 #endif
 
-domid_t __read_mostly max_init_domid;
-
 static __used void noreturn init_done(void)
 {
     /* Must be done past setting system_state. */
diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
index e4f64879b68c..956fa6985adb 100644
--- a/xen/arch/ppc/include/asm/setup.h
+++ b/xen/arch/ppc/include/asm/setup.h
@@ -1,6 +1,4 @@
 #ifndef __ASM_PPC_SETUP_H__
 #define __ASM_PPC_SETUP_H__
 
-#define max_init_domid (0)
-
 #endif /* __ASM_PPC_SETUP_H__ */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
index 2215894cfbb1..73ce2f293348 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -5,8 +5,6 @@
 
 #include <xen/types.h>
 
-#define max_init_domid (0)
-
 void setup_mm(void);
 
 void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index b01e83a8ed9f..5925c5f39cff 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -68,6 +68,4 @@ extern bool opt_dom0_verbose;
 extern bool opt_dom0_cpuid_faulting;
 extern bool opt_dom0_msr_relaxed;
 
-#define max_init_domid (0)
-
 #endif
diff --git a/xen/common/domid.c b/xen/common/domid.c
index b0258e477c1a..cd46cf952be6 100644
--- a/xen/common/domid.c
+++ b/xen/common/domid.c
@@ -9,6 +9,11 @@
  */
 
 #include <xen/domain.h>
+#include <xen/dom0less-build.h>
+
+#ifdef CONFIG_DOM0LESS_BOOT
+domid_t __ro_after_init max_init_domid;
+#endif
 
 static DEFINE_SPINLOCK(domid_lock);
 static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index fcacf37c52f0..61e92491e40a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,6 +31,7 @@
 #include <xen/warning.h>
 #include <xen/pv_console.h>
 #include <asm/setup.h>
+#include <xen/dom0less-build.h>
 #include <xen/sections.h>
 #include <xen/consoled.h>
 
diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-build.h
index 4118dec76c0a..8d4da16d1f0a 100644
--- a/xen/include/xen/dom0less-build.h
+++ b/xen/include/xen/dom0less-build.h
@@ -5,6 +5,8 @@
 
 #include <xen/stdbool.h>
 
+#include <public/xen.h>
+
 struct domain;
 
 #ifdef CONFIG_DOM0LESS_BOOT
@@ -13,6 +15,9 @@ struct boot_domain;
 struct dt_device_node;
 struct kernel_info;
 
+/* Highest domain ID assigned to a boot-time (dom0less) domain. */
+extern domid_t max_init_domid;
+
 /*
  * List of possible features for dom0less domUs
  *
@@ -72,6 +77,8 @@ static inline bool is_dom0less_mode(void)
 }
 static inline void set_xs_domain(struct domain *d) {}
 
+#define max_init_domid 0
+
 #endif /* CONFIG_DOM0LESS_BOOT */
 
 #endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400809.1636350 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt1-00031z-EA; Thu, 27 Aug 2026 15:19:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400809.1636350; Thu, 27 Aug 2026 15:19:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt1-00031s-Aq; Thu, 27 Aug 2026 15:19:27 +0000
Received: by outflank-mailman (input) for mailman id 1400809;
 Thu, 27 Aug 2026 15:19:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt0-000310-3N
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbsz-00C6fs-2M
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:25 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905576-2eae-0a2a0a5409dd-0a2a4507be2c-10
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:25 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90557c-b4ea-0a2a45070019-d155dd35c85a-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:25 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-482e2fdf5abso1050748f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19:24 -0700 (PDT)
Received: from fedora (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787843964; x=1788448764; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:mime-version:message-id:date
         :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=8aVeolV88DGRfxdvviYuYAivZzXMsmgnBt8LjtmKoFY=;
        b=fBRD1NbT6MATU3O2lu6mYZ//HHgP7h0sB45VVK46y3WoaPeBy4dllGYks71lIu4EQN
         VzNDlCyEAssUt6GhklYBGfnNCczA9kN4mecafnaUqp5NkxZqvvzJb/n9NBRntugl+ypj
         sY8b9SJd0t8iv+iKKe2U/J8xAwLYuqAuyGYGG6Q1OFScvpy6pOqr51Yz+0qpA+QSjc49
         dG1VOxvuVWOS2LieUTEGmeyRS48GR22BP8zHu9KgVp/CpRDupK9GLCgUUS7/BgTi8AeV
         PSvUfTt5u4Vp5FQOwZ1g3OVuDZyJTwxqSoCL1xDMJ6djbdXlQV/tiveDYx2Mp+e2LeTi
         TGsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843964; x=1788448764;
        h=content-transfer-encoding:content-type:mime-version: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=8aVeolV88DGRfxdvviYuYAivZzXMsmgnBt8LjtmKoFY=;
        b=MCzo4V8slDcRIt1jxb3/yb1pcjn/9iNZfdPeqhJeSgZrT7zIlxN7NlqqCAnQO1mmTN
         Vtb5H/UoPqqNi9Ua8LScC1AoP4TJI5eNj6ll1cIYT5gniz3Y2sFjQDePiqX2p1gGYYkK
         FB5dMku+CmZFDpjcrkUsFhTM/MtBRGRdbzjjT47HwiYUdGrRWYMTUyKsy6i3jF949EOJ
         uGItcY7G8YHk5g6TRxUM3UZrG5grtL4kRutWQBV3/QFfXa5D2vIs3lRE2Q+zAopaPogN
         FXL1gxoOHHHE3BkX6O8G59gDfXdM0S0V11DUaV2y73Ff/yDKL/Ot2cLObLIMWHhF5ahD
         fUyQ==
X-Gm-Message-State: AFuF++kshSRdx8Wsn+LPmePD5c/7rBEb+5sF9xmFYtGpoHAdVW8G8Z+7
	yEnZsil7gOp5HjU2ASKFy5oXRzYiSMCwBm4N61Uf6iLYRz9kXJ2jMwQon+vS/A==
X-Gm-Gg: AR+sD11xiOTgirOdNMSAlzOFJa0VFc33j2WzWsrWN5OwSuDzaJBf/jSUplVFPTaSjxG
	O1nwkh7tCA2NuPaagWpKpd7M1IaG43UY6rN6+ndyGV4P8qzbfaF0V60+//Om5/A9L1b+veuwYU5
	MIYbb3JqnE852szx5rzwNXKDcIOVcqQHo2QXWIIAHC4aiU+oEn8hbarXQt9tqlaTMxcQZAuzkfl
	Dg04k38eoIq+8XpWZhr7+3tqjc8pQPt+sm9KyzPebbx79Y9apFQLg8S08hXMCKcme1tUl5Eul1S
	kRPvM1jMd2Ic3dwh4ewnqf7utxZNPT1eElY+ZlUHFifScjfMceqdEIYn9Sy2lrKMHUtNWPJyHKH
	AVSzQ+us5XwFQSQm73ArGgYRjN/iHvcGcO11yJJwrLj0yl1HgmMwqk0Aa6Etnls/w2boFB7Indc
	IPMUyWtFlwZUNZR56G01pAGER9MBz4oYqJMeIE59Ld8CPpoc63B1JFdurgqU4S8NM9tr/ykqtWF
	jf3wiJuC+SezsxMlyA131FR4/mcphP0
X-Received: by 2002:a05:600c:6206:b0:49b:90cc:3c87 with SMTP id 5b1f17b1804b1-49b90cc3d27mr32771485e9.13.1787843964147;
        Thu, 27 Aug 2026 08:19:24 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>,
	Timothy Pearson <tpearson@raptorengineering.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: [PATCH v8 00/20] Introduce enablemenant of dom0less
Date: Thu, 27 Aug 2026 17:18:53 +0200
Message-ID: <cover.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787843965-A64DBAE4-7D04F02F/10/73395122804
X-purgate-type: spam
X-purgate-size: 6511

This patch series reprensent a bunch of patches necessary to enable common part
of Dom0less.
The stuff necessary to start/launch domains will be introduced separately.

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2796636402

---
Changes in v8:
 - Address the comments.
 - Rename some variable in [PATCH v8 11/20] xen/riscv: introduce per-vCPU IMSIC state.
 - Drop vaplic_init() and vcpu_aplic_deinit() in
   [PATCH v8 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure.
---
Changes in v7:
 - Merged to upstream/staging:
   - xen/riscv: Implement ARCH_PAGING_MEMPOOL
   - xen: arm: update p2m_set_allocation() prototype
   - xen/riscv: do a 4th linking pass if necessary
 - Address the comments from ML.
---
Changes in v6:
 - Merged to upstream/staging:
   - xen: arm: move declaration of map_device_irqs_to_domain() to common header
   - xen/Kconfig: introduce HAS_STATIC_MEMORY
   - xen/riscv: rename enum intc_version to intc_variant
   - xen/riscv: implement prerequisites for domain_create()
 - Move UBSAN fix ("xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page")
   to this patch series as it is connected to "xen/Kconfig: introduce HAS_STATIC_MEMORY".
 - Address the comments from ML.
---
Changes in v5:
 - Add new patch (xen/riscv: do a 4th linking pass if necessary) which fixes
   randconfig job issue.
 - Address comments from ML.
---
Changes in v4:
 - Address comments from ML.
---
Changes in v3:
 - Drop dependency from other patch series
   ([1] https://lore.kernel.org/xen-devel/cover.1778140240.git.oleksii.kurochko@gmail.com/T/#t)
   as it was merged.
 - Reorder patches:
   - move common patches to the start.
   - Move some patches to separate patch series (will be introduced later)
 - Address comments from ML.
---
Changes in v2:
 - Move patch "[PATCH v1 04/27] xen/riscv: rework G-stage mode handling" to
   patch series [1]
 - Address the comments from ML.
 - The following patches were folded into one:
   # xen/riscv: implement init_intc_phandle()
   # xen/riscv: call do_initcalls() in start_xen()
   # xen/riscv: setup system domains
 - The following patch were folded into one:
   # xen/riscv: add vaplic access check
   # xen/riscv: emulate guest writes to virtual APLIC MMIO
   # xen/riscv: emulate guest reads from virtual APLIC MMIO
 - Add new bug fix, not really necessary to this patch series:
   xen/riscv: manage IRQ_DISABLED flag in APLIC irq enable/disable callbacks
---

Oleksii Kurochko (20):
  xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page
  xen/dom0less: turn max_init_domid into a common variable
  xen/riscv: Implement construct_domain()
  xen/riscv: introduce guest riscv,isa string
  xen/riscv: implement make_cpus_node()
  xen/riscv: implement make_timer_node()
  xen/riscv: implement make_arch_nodes()
  xen/riscv: introduce init interrupt controller operations
  xen/riscv: implement make_intc_domU_node()
  xen/riscv: introduce aia_init() and aia_usable()
  xen/riscv: introduce per-vCPU IMSIC state
  xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure
  xen/riscv: introduce (de)initialization helpers for vINTC
  xen/riscv: generate IMSIC DT node for guest domains
  xen/riscv: create APLIC DT node for guest domains
  xen/riscv: implement IRQ routing for device passthrough
  xen/riscv: implement init_intc_phandle()
  xen/riscv: initialize RCU, scheduler, and system domains in
    start_xen()
  xen/riscv: provide init_vuart()
  xen/riscv: add initial dom0less infrastructure support

 xen/arch/arm/Kconfig                      |   1 +
 xen/arch/arm/include/asm/setup.h          |   2 -
 xen/arch/arm/setup.c                      |   2 -
 xen/arch/ppc/include/asm/setup.h          |   2 -
 xen/arch/riscv/Kconfig                    |   2 +
 xen/arch/riscv/Makefile                   |   4 +
 xen/arch/riscv/aia.c                      |  23 ++
 xen/arch/riscv/aplic-priv.h               |  13 ++
 xen/arch/riscv/aplic.c                    |  14 +-
 xen/arch/riscv/cpufeature.c               | 200 +++++++++++++++--
 xen/arch/riscv/device.c                   | 100 +++++++++
 xen/arch/riscv/dom0less-build.c           |  40 ++++
 xen/arch/riscv/domain-build.c             | 192 ++++++++++++++++
 xen/arch/riscv/domain.c                   |  20 +-
 xen/arch/riscv/imsic.c                    | 178 ++++++++++++++-
 xen/arch/riscv/include/asm/aia.h          |  10 +
 xen/arch/riscv/include/asm/aplic.h        |  15 ++
 xen/arch/riscv/include/asm/cpufeature.h   |   5 +
 xen/arch/riscv/include/asm/domain.h       |   7 +
 xen/arch/riscv/include/asm/guest-layout.h |  24 ++
 xen/arch/riscv/include/asm/imsic.h        |  25 +++
 xen/arch/riscv/include/asm/intc.h         |  44 +++-
 xen/arch/riscv/include/asm/irq.h          |   5 +
 xen/arch/riscv/include/asm/setup.h        |   2 -
 xen/arch/riscv/include/asm/vaplic.h       |  34 +++
 xen/arch/riscv/intc.c                     | 117 +++++++++-
 xen/arch/riscv/irq.c                      | 255 ++++++++++++++++++++++
 xen/arch/riscv/setup.c                    |  12 +
 xen/arch/riscv/vaplic.c                   | 138 ++++++++++++
 xen/arch/x86/Kconfig                      |   1 +
 xen/arch/x86/include/asm/setup.h          |   2 -
 xen/common/Kconfig                        |   3 +
 xen/common/Makefile                       |   2 +-
 xen/common/domain.c                       |   6 +-
 xen/common/domctl.c                       |   4 +
 xen/common/domid.c                        |   5 +
 xen/common/event_channel.c                |  55 ++++-
 xen/common/event_channel.h                |   6 +
 xen/common/event_fifo.c                   |  18 +-
 xen/common/time.c                         |   2 +
 xen/drivers/char/console.c                |   1 +
 xen/include/xen/dom0less-build.h          |   7 +
 xen/include/xen/event.h                   |   2 +-
 xen/include/xen/sched.h                   |   2 +
 xen/include/xen/shared.h                  |   6 +
 xen/include/xen/time.h                    |   5 +
 46 files changed, 1552 insertions(+), 61 deletions(-)
 create mode 100644 xen/arch/riscv/aia.c
 create mode 100644 xen/arch/riscv/device.c
 create mode 100644 xen/arch/riscv/domain-build.c
 create mode 100644 xen/arch/riscv/include/asm/aia.h
 create mode 100644 xen/arch/riscv/include/asm/vaplic.h
 create mode 100644 xen/arch/riscv/vaplic.c

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400814.1636395 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt9-00048X-Uv; Thu, 27 Aug 2026 15:19:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400814.1636395; Thu, 27 Aug 2026 15:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbt9-00048P-SA; Thu, 27 Aug 2026 15:19:35 +0000
Received: by outflank-mailman (input) for mailman id 1400814;
 Thu, 27 Aug 2026 15:19:34 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbt8-0003gq-94
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbt7-00Fhjf-MK
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:33 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905555-e002-0a2a0a5209dd-0a2a4508e812-40
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:33 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905585-f659-0a2a45080019-d155dd2fb982-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:33 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47f84023916so784137f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:32 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843973; x=1788448773; 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=7xQsUVTTJIfUyEn5waDQw6z9DwE5RwUDFgt9SnUa9c8=;
        b=j8lukQxuS/NO9x/TTrEJNMWAV3bS8kNaez5NAmJ4QQ96xvicFQ5qGGJQtxoEaHiOBk
         BtTLzcjzkT3gJtGc0R8ZYXxmq62EGSXgi5mpXp2gaktiISn/4bVJiQg+w36dBwv7/Vmd
         LJGxnsBsNhQbFUB9GufKU4yM/PnZ0rnXbypxFC0O/1eDOW3EZcIPbE9L9yPhYwSvdb2v
         V/TDOdYK8Kq8+Z7AO8aikI6KQAWUftmSvczdS+6baIqYAolTRtiGs51186Liz8sPrQcl
         h8ssAo1HtOxc5OqTmGrSlzjWfn1F1pxSIckUnF6ZDBn/JVk1Mese+oI8/JbRS4Z73FR6
         FRxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843973; x=1788448773;
        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=7xQsUVTTJIfUyEn5waDQw6z9DwE5RwUDFgt9SnUa9c8=;
        b=Fia9Cj7sK0+k8g5XZ7cQwzNCvynw+GVCDMoXDwYz+lIEIpBImtHiYA3CG2+vhdfDuZ
         CGFB5zQONFjvResTujJ2LgzAXrJIVUEdWYo34CpZDJ5mGpiUvmR1mvbKuAVgEtsqKiSW
         HJkiAjkJEe9uHMUAwDV8YwNLbz0+xt5UgSsu64Om+taBlN69nqmRtDvVK5qkuZh+K064
         UtWxpFCgQ7qHPb4/TcZ0lBFJcB0g7nDj1bBFl0WvINzv7tQXrj1hpd9+KUeKLzyPR3gt
         M747gXeyp2u4tQgp3cH1SX6GmpTmWzqWzw6p8xu0CTY5+XhEuFD16xUomAzaEhWEpO6w
         kuQg==
X-Gm-Message-State: AFuF++l9nXudgzsxfn95fLfyBsbys/eMLStEuyTOCo2Z4DYYktq2+uxi
	7/o/H6BkuiUn2Q9X/1qoE34WvCAYxntEp2wi2ZB9ZUiXuyiFE9TPZN6q5hEKUg==
X-Gm-Gg: AR+sD13gx1y9QxPKYgj8grEww2L1z8US3Vtknz4JzvPoD7+IQThUHIEJgLAZ6wodVUW
	G+O+yK0RquaeqxbcI8tZfMdljA9e7TYFs83p0zyaOodTgNCY4ziMZDfBikYxvtf8Af5b5bSlNV2
	itGsqG4eJSi2t5QaajYtIsfv525K112S2Hk0A2QtyJAPPTDiDv5stSfXc7OM55xlQqHeCMTzdKu
	jpw1jzroDlP/7k/Nz2+z4VBcgn5BzLV1rB/6o20JxLDwkFoSdwFIuHSm/1Z5I5uRhm5y+kW71Dd
	Lu5cMDI0Emuuh3jBlLSEINn/u/dEWZUQg7It5TK5cFyKOeK9ZeTnQ453i6LRygFK4fomOF+Xq6p
	kgEDMyn8pwzCr4uUjvmT6nioITofVP8oTskZfKhTGYkholAY2E8fkJAFaAuUWYqPajDNXFNKGDQ
	v+Yq/tD1yEyw+ZkqbPu1CWo/MUVxeCO5uA+pVYbODVfGsECvnNBUov7bWf3dSfOPp3U/oZsbDua
	Hb0ycxl2MntiGvEYnMzjqLg3iaKUMakAeV0TCF2v7o=
X-Received: by 2002:a5d:6f09:0:b0:47f:d0fb:ea40 with SMTP id ffacd0b85a97d-482e271392emr23378946f8f.21.1787843972623;
        Thu, 27 Aug 2026 08:19:32 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 05/20] xen/riscv: implement make_cpus_node()
Date: Thu, 27 Aug 2026 17:18:58 +0200
Message-ID: <05b604b2cb8449c538f64fe56dbfff985dd003dd.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787843973-CC57487B-196DC0FF/10/73395122804
X-purgate-type: spam
X-purgate-size: 6164

Implement make_cpus_node() to create cpus node for a guest domain.

This function is going to be use by common dom0less code during
construction domain.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v8:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v7:
- use get_guest_isa_str() for the "riscv,isa" property instead of building
  the string per domain.
- as a consequence, drop the isa_str/len local variables, the
  xvmalloc_array()/xvfree() pair and the <xen/xvmalloc.h> inclusion; with no
  resource left to release, the error paths now return res directly and the
  "out" label is gone.
- s/sizeof/ARRAY_SIZE for snprintf's argument.
- Drop Acked-by: Jan B. as some changes were done so it would be nice if
  Jan B. will review them again.
---
Changes in v6:
 - Update the two build_guest_isa_str() call sites for its new
  `const struct domain *d` signature.
 - Drop build/tools/fixdep from the patch.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v5:
- Drop Acked-by: Jan Beulich <jbeulich@suse.com> as extra changes were done
  because of the changed in prev. patch.
- Move isa_str allocation and construction out of arch_domain_create() and
  into make_cpus_node() as a local variable, since the string is only
  needed during FDT generation. Use a two-call build_guest_isa_str()
  pattern (size probe, then fill) with xvmalloc_array, and convert all
  post-allocation error returns to goto out so xvfree() runs on every path.
---
Changes in v4:
 - Update the comment in make_cpus_node() to match code style.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v3:
 - Add blank line above make_cpus_node() function definition.
 - Move 'unsigned int cpu' from function-level declarations into the for loop.
 - Drop 'uint32_t reg = cpu_to_fdt32(cpu)'; use fdt_property_cell(fdt, "reg", cpu)
   instead of fdt_property(fdt, "reg", &reg, sizeof(reg)) so byte-order adjustment
   is handled internally.
 - Add matching /* interrupt-controller */ start comment; fix end comment to
   /* end interrupt-controller */.
 - Update d->arch.guest_isa_str to ->isa_str in make_cpus_node() function.
---
Changes in v2:
 - s/u32/uint32_t for timebase_frequency local variable.
 - Drop +1 from BUILD_BUG_ON().
 - return fdt_end_node(fdt); instead of res at the end of the function.
---
---
 xen/arch/riscv/domain-build.c | 106 ++++++++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)

diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
index 5f6f4b6248a5..1af4c48fb30c 100644
--- a/xen/arch/riscv/domain-build.c
+++ b/xen/arch/riscv/domain-build.c
@@ -3,8 +3,10 @@
 #include <xen/fdt-domain-build.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/sched.h>
 
+#include <asm/cpufeature.h>
 #include <asm/current.h>
 #include <asm/guest_access.h>
 
@@ -48,3 +50,107 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 
     return 0;
 }
+
+int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
+{
+    int res;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    uint32_t timebase_frequency;
+    bool frequency_valid;
+    void *fdt = kinfo->fdt;
+
+    dt_dprintk("Create cpus node\n");
+
+    if ( !cpus )
+    {
+        dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n");
+        return -ENOENT;
+    }
+
+    frequency_valid = dt_property_read_u32(cpus, "timebase-frequency",
+                                           &timebase_frequency);
+
+    res = fdt_begin_node(fdt, "cpus");
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#address-cells", 1);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#size-cells", 0);
+    if ( res )
+        return res;
+
+    if ( frequency_valid )
+        res = fdt_property_cell(fdt, "timebase-frequency", timebase_frequency);
+
+    for ( unsigned int cpu = 0; cpu < d->max_vcpus; cpu++ )
+    {
+        char buf[64];
+
+        snprintf(buf, ARRAY_SIZE(buf), "cpu@%u", cpu);
+        res = fdt_begin_node(fdt, buf);
+        if ( res )
+            return res;
+
+        res = fdt_property_cell(fdt, "reg", cpu);
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "status", "okay");
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "compatible", "riscv");
+        if ( res )
+            return res;
+
+        BUILD_BUG_ON((sizeof("riscv,") +
+                      sizeof_field(struct gstage_mode_desc, name)) >= sizeof(buf));
+        snprintf(buf, ARRAY_SIZE(buf), "riscv,%s", max_gstage_mode->name);
+        res = fdt_property_string(fdt, "mmu-type", buf);
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "riscv,isa", get_guest_isa_str());
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "device_type", "cpu");
+        if ( res )
+            return res;
+
+        /* Start of interrupt-controller */
+        res = fdt_begin_node(fdt, "interrupt-controller");
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "compatible", "riscv,cpu-intc");
+        if ( res )
+            return res;
+
+        res = fdt_property_cell(fdt, "#interrupt-cells", 1);
+        if ( res )
+            return res;
+
+        res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+        if ( res )
+            return res;
+
+        res = fdt_property_u32(fdt, "phandle", alloc_phandle(kinfo));
+        if ( res )
+            return res;
+
+        /* End of interrupt-controller */
+        res = fdt_end_node(fdt);
+        if ( res )
+            return res;
+
+        res = fdt_end_node(fdt);
+        if ( res )
+            return res;
+    }
+
+    return fdt_end_node(fdt);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400816.1636412 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtC-0004bR-Et; Thu, 27 Aug 2026 15:19:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400816.1636412; Thu, 27 Aug 2026 15:19:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtC-0004bK-BP; Thu, 27 Aug 2026 15:19:38 +0000
Received: by outflank-mailman (input) for mailman id 1400816;
 Thu, 27 Aug 2026 15:19:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtA-0004IV-RZ
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtA-00Fhjf-8V
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:36 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905587-e002-0a2a0a5209dd-0a2a4504a04c-2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:36 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905588-b57f-0a2a45040019-d155dd35d48b-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:36 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-47f93b2fe4cso1288964f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843976; x=1788448776; 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=UQu/lqi3OofaW9Ww27GFTZkZC+QKN3wGxz75zQOuGZs=;
        b=fcRq2/P8KGzvkVJevRrWp5834BoCjahiTUqMy/Zmw+g3RgWNk4qOIAwWAdOLf/KHkN
         tu1LqH6HxWlK+b8s23C+c3JCjoWoe0fplk4G/h+XXpKIC1VAwRjH5LOZrsAXdkL/Scfo
         dRn/H7dsNADsAKMczf5toE0lXRcSLFQHapv6lNTKRReseMJb1wyJUt2gbGaPhu3m+Nob
         0aPVLddlGieWP1zHuMdltUVbkU13T3RoI6FS06Fc/zHz04TyEPSepJf+M4/IG6LaJW/f
         lYQDP36t/r7UKMYQa3y9c+fDvwy2b8TnHDZTOsK3TD6IAB08yhreCs0mQw/EjBhE92qs
         Ncpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843976; x=1788448776;
        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=UQu/lqi3OofaW9Ww27GFTZkZC+QKN3wGxz75zQOuGZs=;
        b=Tp8iqBsYJQv/bOpPPDTYOb0mkc99TL2ewaxoHeR3Xs/vwUzViIqWYrezhuC5ttsfl3
         PEOvXSLW1m+Uya3/6ynGvVJxt/+Kd68OvkPZI5iJJKn78kYJ19kGA3voOL9pqSI+Ws3H
         XjoiGftOO6Iv8IhJ8w0KrXFTvy5rbLRHcL/aNwqInSUoKPYHFyuECQWk3SbLITwUpNAg
         E7gbXDq3qVhXift1N4J5AtPiznYgDzBzKmSvqTgK4Zr93PyC7e61DvZBUI0SzliNN0vu
         VRgaPGKkGmT3SznVTrh+sd2wqJTPyN3zaP3A5XVZhej5rsmnYA4gye65BxMuW+lBBoYz
         703w==
X-Gm-Message-State: AFuF++nU6E6f/pMvI2DH5VauyNQnJRoplBWWIvGSzlj7Smh8dSpiOv1B
	LUf2MJS3utgcAAsaTRsTgzO7wg43IkY4eciRaFES8JK33RcnjT0vqTzwvhs0UA==
X-Gm-Gg: AR+sD11WfVGpm2AlBUz4P/lbcw/Nd037DiySnFPN6Twuon/ABeJRleaCp8QxwUnnkwo
	iDe2M23WrZ8dvFaUwMEEyWFhF7zjE71B6p29LsPrEBYHyg+cMA7vcriQ0z2GIqGDyqDI31isA0d
	5cooMJbV9y0DTzsKTuI5PNwiXlNAPUvCKuGumsvEJcj0ej6iIdLB2/EGxEBmUa9O5tSDCj9tp1E
	9OTuLAzbgXp/Zuw2f9/Q0Gzp9d+O8TwpQJ5T6LDufdg+zugRe+9MzwJTzsboGEdk94JCq3mq+tn
	9htci4TEQukJtn6bd37Qpzf0LadrVpr1WacdVa8PgEa15lu8i/Jis1C5hpQqoQymEPjsGf9o8eD
	WU9d/IZYyOXRFpDq8djCpIXeBbmHPYdHy6PPJw5hLLfh+Yv8aEU9yqkNrLFEnJDPE7gzuR+8cHk
	or9Xi5KeA5BaeSWMbe54NO4JpOo/K+1KKYBzO/N8WE1eRkUnmXr7VDir5d7tkaZGDtLEAV2XXuk
	iXd5E/4sjwvsSNnceuklOOO29llhwy2
X-Received: by 2002:a05:6000:430a:b0:482:e658:bb8e with SMTP id ffacd0b85a97d-482e658bdf2mr18935211f8f.12.1787843975584;
        Thu, 27 Aug 2026 08:19:35 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 07/20] xen/riscv: implement make_arch_nodes()
Date: Thu, 27 Aug 2026 17:19:00 +0200
Message-ID: <12586f15b4beaf73ee4908623aef6ba2e9298ab6.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787843976-C08D9B50-1FDA5C95/10/73395122804
X-purgate-type: spam
X-purgate-size: 1444

No RISC-V-specific nodes need to be created at the moment,
so make_arch_nodes() is implemented to simply return 0.

It is placed in dom0less-build.c as make_arch_nodes() is
only used in the dom0less code path. In the future, it will
be extended to create an emulated UART node.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-v8:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Drop "Add" before Acked-by above the footer.
---
Change in v4:
 - Add lost Acked-by.
---
Changes in v3:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v2:
 - Update the commit message.
---
---
 xen/arch/riscv/dom0less-build.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index a683972e9235..4cc00012aa8d 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -2,10 +2,18 @@
 
 #include <xen/bootfdt.h>
 #include <xen/device_tree.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
 
 #include <asm/p2m.h>
 
+int __init make_arch_nodes(struct kernel_info *kinfo)
+{
+    /* No RISC-V specific nodes need to be made, at the moment. */
+
+    return 0;
+}
+
 int __init arch_parse_dom0less_node(struct dt_device_node *node,
                                     struct boot_domain *bd)
 {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400817.1636422 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtD-0004rw-QR; Thu, 27 Aug 2026 15:19:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400817.1636422; Thu, 27 Aug 2026 15:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtD-0004qs-Lj; Thu, 27 Aug 2026 15:19:39 +0000
Received: by outflank-mailman (input) for mailman id 1400817;
 Thu, 27 Aug 2026 15:19:38 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtC-0004XF-6W
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtB-00C6ki-Jo
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:37 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905589-2eae-0a2a0a5409dd-0a2a4502d400-2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:37 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905589-6ca4-0a2a45020019-d155dd34b1c0-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:37 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47fd66a094eso761505f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843977; x=1788448777; 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=2rqqgtz0m8ycDrWJfyzyeS5VceMq0RnmIpD0J8gdZ2Y=;
        b=FRfjztLMxlgh4cCv5ujKMNq3pZi9G6EjYVsj0dPLaKFlUbhc+xGoLgQ8uHpnAmNSgj
         MfXfL9acJ9Pdr+JEZl3OpZqex5EGntJgt0vkWCPKgqm+OjxVAfTshnQz/KbagC/w3WlJ
         3fuk+UaNxtADu90rLSTw0PsYHp3BESizecerrnebZanCxr/1a32aZEgm7wBLs4POeCaF
         T9OMtrK9mFuVlLNOncKpsyBwEa1izH11SqjZpT8v4s9EbVCmFZXPnKo18HB2AOmQXiWu
         /U2uTSHdkALlrl4TpLByrwwNKcv8d78085oZDGXyZV3az8e0kAdmX/nT7kG9AF6nWI28
         aWzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843977; x=1788448777;
        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=2rqqgtz0m8ycDrWJfyzyeS5VceMq0RnmIpD0J8gdZ2Y=;
        b=RZXY2yP+qz+t5iP7RqcayGQ+icQ1tgKAxdcIC+9gY3hURwRoDK76ZMYMpiHl02RhDO
         yfez4tu1ZT546Z41Jz4s2+8Wy7Gb/N4NWouN8MGYokMlOAL0tGD2Gd9tzt18n50Yg70Q
         a8qinSBvoDv3aUbsoYsqAbnA+Fasfy9U1sJYdA6h+nzyC5d6uvz/5pWbtDfwN7f0Qgxj
         H+POOFtgc985+XGAcmj5ttqAcIt+nILnapOroe5VKSbiOaQy3Gs8iSmveH9DZZxQMgiM
         M49lvBPi3jk/3j6zg0I1U5Nw4SOx3gDRF8JKzEl2gxXPRTRgfiDHd6rZhtrRU81SzUmi
         Gg8g==
X-Gm-Message-State: AFuF++n285LOEDuIfF2QV2/6d5Zy0iciwPR8aRdHBu4q4pMz5FVV/1Br
	otLk5cPVK4hpRSyfgWbLJ5b/dZo1Wd/LlfwcTq0yWKk+cs4CI8PXeG0IWD6MAw==
X-Gm-Gg: AR+sD13JV27QCpxQ5caVLGvZQgKpA12nm0mOam5BdcS7WyrXmG1vN0TBxj1u9B0loEI
	9Vp/2irdvPb9KyHDu5GkmizZW4ePLwZWR5C2+6JooeOywgYSpB9epZjuNOIfmd9qebl+FsIYuTr
	QL2pyOLSo3TZ4rix1za7FGPvDj2c7XEWfAmS+Ktmtq4N8SlcN8B8k0A4qtNEE4Af4+7fM9N9UzX
	be6imu11HBIZOOvWVMbwqg6yMS2NPpo22zY8LIPDWQ498FfgqvyvhF+7ZSmkKV27K0RUrKdrF3R
	8Atb/jlBz6gFAVplS5NPNYHAS3s0ImdarflraONIfR5gGqmJxUgSU2+Ugl9Fx1L7fI8ni5ovEs5
	UuIves4YC0sagfsxhTpFJS80fBdJYy0jebB/lWl02tjmHO865eh/Vm+B7X02YLz6FmtMo5lJpSH
	3V40qziL0pgGNOqalnWtC1a88A/lF+KIXGfodqxKSaLFzdv85BD1dI9QRsUwZvujmgHZO3/Bfo6
	Db0jDC+lLZRNSE5cCEiTaulKncLwb49
X-Received: by 2002:a05:6000:71a:b0:482:e4bc:51a7 with SMTP id ffacd0b85a97d-482e4bc5337mr20087141f8f.11.1787843976925;
        Thu, 27 Aug 2026 08:19:36 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 08/20] xen/riscv: introduce init interrupt controller operations
Date: Thu, 27 Aug 2026 17:19:01 +0200
Message-ID: <7eba48417bb5f5329a054e4bcccabc5139e13dd0.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787843977-F36BF2AC-35DFB46B/10/73395122804
X-purgate-type: spam
X-purgate-size: 4032

Introduce intc_hw_init_ops structure to avoid risky mix of init
function and non-init function.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v5-8:
 - Nothin changed. Only rebase.
---
Changes in v4:
 - Use __initconstrel instead of __initconst for aplic_init_ops as both
   initialized fields incur a relocation.
 - Add Acked-by: ... .
---
Changes in v3:
 - Use __initconst instead of __initdata for const intc_hw_init_ops.
 - Embed const struct intc_hw_operations *ops into intc_hw_init_ops so
   register_intc_ops() takes a single pointer argument.
---
Changes in v2:
 - New patch.
---
---
 xen/arch/riscv/aplic.c            |  8 ++++++--
 xen/arch/riscv/include/asm/intc.h | 10 +++++++---
 xen/arch/riscv/intc.c             | 11 ++++++++---
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index 9f023db5d525..d08401db46b3 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -325,12 +325,16 @@ static const hw_irq_controller aplic_xen_irq_type = {
 
 static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
-    .init                = aplic_init,
     .host_irq_type       = &aplic_xen_irq_type,
     .handle_interrupt    = aplic_handle_interrupt,
     .set_irq_type        = aplic_set_irq_type,
 };
 
+static const struct intc_hw_init_ops __initconstrel aplic_init_ops = {
+    .ops                 = &aplic_ops,
+    .init                = aplic_init,
+};
+
 static int cf_check aplic_irq_xlate(const uint32_t *intspec,
                                     unsigned int intsize,
                                     unsigned int *out_hwirq,
@@ -366,7 +370,7 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat)
 
     dt_irq_xlate = aplic_irq_xlate;
 
-    register_intc_ops(&aplic_ops);
+    register_intc_ops(&aplic_init_ops);
 
     /* Enable supervisor external interrupt */
     csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL));
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 675f703ec97f..d7b34fc15ad1 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -28,8 +28,6 @@ struct intc_info {
 struct intc_hw_operations {
     /* Hold intc hw information */
     const struct intc_info *info;
-    /* Initialize the intc and the boot CPU */
-    int (*init)(void);
 
     /* hw_irq_controller to enable/disable/eoi host irq */
     const struct hw_interrupt_type *host_irq_type;
@@ -43,9 +41,15 @@ struct intc_hw_operations {
     void (*handle_interrupt)(struct cpu_user_regs *regs);
 };
 
+struct intc_hw_init_ops {
+    const struct intc_hw_operations *ops;
+    /* Initialize the intc and the boot CPU */
+    int (*init)(void);
+};
+
 void intc_preinit(void);
 
-void register_intc_ops(const struct intc_hw_operations *ops);
+void register_intc_ops(const struct intc_hw_init_ops *init_ops);
 
 void intc_init(void);
 
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index ea317aea5ad8..3600d23bdb5b 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -12,9 +12,12 @@
 
 static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
 
-void __init register_intc_ops(const struct intc_hw_operations *ops)
+static const struct intc_hw_init_ops *__initdata intc_hw_init_ops;
+
+void __init register_intc_ops(const struct intc_hw_init_ops *init_ops)
 {
-    intc_hw_ops = ops;
+    intc_hw_ops = init_ops->ops;
+    intc_hw_init_ops = init_ops;
 }
 
 void __init intc_preinit(void)
@@ -27,7 +30,9 @@ void __init intc_preinit(void)
 
 void __init intc_init(void)
 {
-    if ( intc_hw_ops->init() )
+    ASSERT(intc_hw_init_ops && intc_hw_init_ops->init);
+
+    if ( intc_hw_init_ops->init() )
         panic("Failed to initialize the interrupt controller drivers\n");
 }
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400819.1636431 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtF-00058X-DB; Thu, 27 Aug 2026 15:19:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400819.1636431; Thu, 27 Aug 2026 15:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtF-00058L-5e; Thu, 27 Aug 2026 15:19:41 +0000
Received: by outflank-mailman (input) for mailman id 1400819;
 Thu, 27 Aug 2026 15:19:39 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtD-0004nW-GK
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtC-00C6ki-TB
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:38 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905589-2eae-0a2a0a5409dd-0a2a4502d400-12
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:38 +0200
Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90558a-6ca4-0a2a45020019-d155dd2de85a-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:38 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-482e4998d28so1200291f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:37 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843978; x=1788448778; 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=0M3EgygiTwyj1BTDY//NIuuLWaR+oYVriRuH7zUtriM=;
        b=HmQfarzbUsV9Eqo6dzQ8Bt0jTde2bfSbrXU4KMUiysvKDVeAzkyrZrdClqR1frpubu
         xv1GNo2Cpomwt9zGBi9NbhKbvgp/6mZGXffDdW3avLRg3i0e8jaSdY2c0riu1iv1TkrH
         NbIevmGCkMTsvVZiFWzMVCb9VnnNXOJzB4Bh2HjUptHwRsHdi84UK7PTVgc34HyCvEDS
         304yqBZcDMj5k/s0w6ROkQSJDDhgHEXkXuYTfUsqXFL1XLVqhY86yFkG88S1pfgd3QiN
         O54we6KEE1VzjCWa/KdRIoGuSmgXcqUHVe+Dr+ohwt+c3uI/VID0OFl+SmnM5TyFAX4b
         O7OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843978; x=1788448778;
        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=0M3EgygiTwyj1BTDY//NIuuLWaR+oYVriRuH7zUtriM=;
        b=oM95EtiKDjb4EDcsLMbjuAtzmdChWgwJqU8weFiTDEAbO3sTcoUjDkIqwROs9WZeQL
         Wn3gpGt76giUtsV/9Jtw0FWwnW12Uyo34dVjd6D9NTrHtTUyVBDVUKvCK8acsXEb2uXB
         FfxZq7paghM4tWHbyKkWyb0Qq2O/xC2fvs43QlTRZ6poNe5XdQukYSHgab/TRvp4I1qi
         K++04HZr2yrTgrhX/CTBONQoa76N8Ia3QRbw9hYtzwQ9IZ4ellL1TpH9NUPcLt8YhzTk
         y0V513pEL6tRufK3NqMoGdOgM8qQDqXodWxz8ulTPnQ3b7nZUA2DA4FwzlM6i1N2XlKo
         yaqQ==
X-Gm-Message-State: AFuF++me78mUyAxe/d2X+o4tQ34K69kO/AOo6WJEb3SW/eg8LqgNz5WP
	CpDqamkNqNXrPdAeo79f4Fc0ia+7JftApJv6NW93bkP7cIBfbr5LrLrrkZHQbg==
X-Gm-Gg: AR+sD10nKLrfwxatEqClmC7HCj4zkv/AirBXJATJQ/aMR05qd7FniQZTJD/IYxODn+A
	/8OlHC4JiSksirZA7x6+nZSrddh9PDOBD92Md8zXqzNsJAnalqBISxsY7Ix1AafP1zFn+wnvGdy
	gXH7XmWZsyMvO18bX0Pz5NVqneyv/M2h1fToxztKxENVdJw5E6aqvR7epaaCgvKaRmz3jtJCn1O
	+etmAX/XBW8RqSKIN6zoJhcU/by4kvHxeyasgw4EhJ0GYTL3yzznnzYn8Nw6Te5GAWBBjmEtjV7
	BCBhFgXOtwNi68heKPfud2bBg1JyM1LB1RYA8b/EJYKoAkLKPOXQ3RHcjB/ELpl2YQbZF7xHc7V
	PaWF+HDSekoxmRjEzuSOdmGB4nL7CqoWTvsFHFbGfzdZP6D8OTN2c6V970GFipdvy0teWbDGuu2
	Cnlodf2VitGktmgZ7jkAJHce9lsbr2vOVacEEYYTUV6glslsTBUv11Qr6OwbvuaPO+1pox+0qDX
	UGK2pDTKB4CjW5Fkhs3FIpntkmLWi0Tew==
X-Received: by 2002:a05:6000:2008:b0:482:c72e:6af4 with SMTP id ffacd0b85a97d-482e2628158mr21154717f8f.0.1787843978226;
        Thu, 27 Aug 2026 08:19:38 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 09/20] xen/riscv: implement make_intc_domU_node()
Date: Thu, 27 Aug 2026 17:19:02 +0200
Message-ID: <a5001a14e8bbf357788af6a9fd9fa1956cc5a548.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787843978-307C22AC-55D4A302/10/73395122804
X-purgate-type: spam
X-purgate-size: 3439

Introduce a RISC-V specific function to create an interrupt controller
Device Tree node for DomU domains during dom0less build.

Add make_intc_domU_node() to the dom0less build path and wire it to
a new generic helper, intc_make_domu_dt_node(), which delegates DT
node creation to the active interrupt controller implementation via
vintc_init_ops.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v5-8:
 - Nothing changed. Onlye rebase.
---
Change in v4:
 - Made local variable vintc pointer-to-const.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3:
 - Use const struct vintc_init_ops *init_ops in struct vintc.
 - Drop redundant intc_hw_ops check in make_intc_domU_node().
 - Drop NULL pointer checks in make_intc_domU_node() as we can't start domU
   without properly created interrupt contoller node.
---
Changes in v2:
 - s/intc_make_domu_dt_node/make_intc_domU_node.
 - introduce separate intc_hw_init_ops structure for init operations.
 - Return -EOPNOTSUPP instead of -ENOSYS.
 - Drop const for kinfo argument as it could be changed by interrupt
   controller node creation code.
 - Refactor make_domu_dt_node().
 - Make make_domu_dt_node part of vintc structure as it looks more logical to be
   there.
---
---
 xen/arch/riscv/include/asm/domain.h |  2 ++
 xen/arch/riscv/include/asm/intc.h   | 10 ++++++++++
 xen/arch/riscv/intc.c               |  8 ++++++++
 3 files changed, 20 insertions(+)

diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index 8ae01a5e4dcc..bd43ed08c22c 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -97,6 +97,8 @@ struct arch_domain {
     struct paging_domain paging;
 
     const unsigned long *isa;
+
+    struct vintc *vintc;
 };
 
 #include <xen/sched.h>
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index d7b34fc15ad1..a4e678fad90b 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -16,6 +16,7 @@ enum intc_variant {
 
 struct cpu_user_regs;
 struct irq_desc;
+struct kernel_info;
 
 struct intc_info {
     enum intc_variant hw_variant;
@@ -47,6 +48,15 @@ struct intc_hw_init_ops {
     int (*init)(void);
 };
 
+struct vintc_init_ops {
+    /* Create interrupt controller node for domain */
+    int (*make_domu_dt_node)(struct kernel_info *kinfo);
+};
+
+struct vintc {
+    const struct vintc_init_ops *init_ops;
+};
+
 void intc_preinit(void);
 
 void register_intc_ops(const struct intc_hw_init_ops *init_ops);
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 3600d23bdb5b..e63da5e22efc 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -3,6 +3,7 @@
 #include <xen/acpi.h>
 #include <xen/bug.h>
 #include <xen/device_tree.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/lib.h>
@@ -72,3 +73,10 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
     intc_set_irq_type(desc, desc->arch.type);
     intc_set_irq_priority(desc, priority);
 }
+
+int __init make_intc_domU_node(struct kernel_info *kinfo)
+{
+    const struct vintc *vintc = kinfo->bd.d->arch.vintc;
+
+    return vintc->init_ops->make_domu_dt_node(kinfo);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400820.1636440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtG-0005NS-KB; Thu, 27 Aug 2026 15:19:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400820.1636440; Thu, 27 Aug 2026 15:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtG-0005NA-FU; Thu, 27 Aug 2026 15:19:42 +0000
Received: by outflank-mailman (input) for mailman id 1400820;
 Thu, 27 Aug 2026 15:19:40 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtE-00051g-Oi
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtE-004jWw-5T
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:40 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905585-bab6-0a2a0a5309dd-0a2a450595fe-20
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:40 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90558b-4cb1-0a2a45050019-d155dd2ebd5f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:40 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-4798bea72f9so571747f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19:40 -0700 (PDT)
Received: from fedora (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843979; x=1788448779; 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=iDttIDGdjdAgP27+7YeB5iYqy8JtAEAvLm+aSBcX5i8=;
        b=opzs6BThVg7mMZG84Z3pG2E2tqkYNqTAw92cY0I76HY2eX6z3M2mxktzDvrKJWEHZo
         hqkSunzEq98KegLy2Erqhu8A+o2DbQ8wJpNjWdW9Y5J1eh5DFPLXXm6pt/XcFMYv8I8i
         58ej8zFUlW66QDCxqRisp/U2yhXKhJ3oDIfkmFDpPMohEPftjHg55R0z76X+PRpD5fDx
         XktNINoRvIW7o7+I5Q3TwBRcLcEObeteFOzN5RrQ4/Ph6gVWZMcxd0KuOLFOcDYT7bkE
         yrHghgIb8gJ0qFDGdVMjmSUUFyU1Xl6UU8RrmAY9AAJI+d3IME+bS5etSInQ+O7Jjxie
         7Q6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843979; x=1788448779;
        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=iDttIDGdjdAgP27+7YeB5iYqy8JtAEAvLm+aSBcX5i8=;
        b=l6oJbEmE6v/qYcVN6nV25aMHJ+Ox2DPf4sREy76L1BdGaoXtBK4T8v9DuSTZJ2WGpE
         rbTpzFIZw0LpBDF7+y/8E6O4hOwha3IfDfyE4MZfc26gnGKjDwXYbSp1FAwvQwH6uzY6
         d6DvujUm6+rJckNerOM6X6TiapPFanJK60CqBMfG4U1nv0LgpZrxSMayGbg+7C+xLfBi
         +gVsw3GolmNJU4vgYpuP+3+Kcgg1L9ZnaClc0f68MxysU/JWCmqausQjY2ulH0gjRP9S
         l5OpfUogZh/L8afkB10UnWGClkYjqlFtyX0y7hTTukkHZ+xJb7N75oDTjsJlWtQYyaCo
         faTA==
X-Gm-Message-State: AFuF++mIEDwGbxBta8o3F+/5kiEEEgoh5HIsqKwpuaRCC8mNq5qUVkdY
	RnUxvhvI+Smtc9eAd6Vi7L1XSHyVRF8eHDgMmgq2gHygPvU4T/85Zphb97ozOg==
X-Gm-Gg: AR+sD131zSIrrewokEwlkcRc2VroRHzVk+ntyRaA3nmEjUIrkg8K3WOrnicN4b+8lBo
	dCvTCTF2ssYt/HCpMJmVWd91Kv7vXICXvoYYM35z5HPwQAtsd2GgedAkXJ2/PU1Ado9aFBIokF1
	pXHwO3QB81wFqzGiqJrTesDmcrPxeVgD5UIjTjPJgYFeGRm5ABlLTfTOiATuYvHhjmaKtC+59C8
	sPapBx8hebbGcrzshBmUJBZdKJDQWY5MiNDvN8cG42GyQMNBQPkQRJNXUI90pus1qFeOrljJs6O
	NitVcgTiBNSIYsdcrFBkR0ZKRDvT13rJWUC9H1OpWDQAZuOBDYpUkFF0P7TRhQJEqlTz+/FXIX7
	gJeoqrC1mwM5OlSFmqFsOJG3/z4Qbcy0snPHXgKOebSmCHvC19zBrT4M+V3O0GqQMME+BFxaPZC
	epiqq7rpEz5zRDVfjK5w6mug6LXD99HxCzP5NWUYJIvdg6EIp15r+hYGj0g7kwP5Ut1r5e+tdzH
	fmx6RMCUJ5mMzRDsAjfdE7ZCX86SXCM
X-Received: by 2002:a05:6000:4285:b0:482:eaa2:7d85 with SMTP id ffacd0b85a97d-482eaa281famr11837675f8f.0.1787843979492;
        Thu, 27 Aug 2026 08:19:39 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 10/20] xen/riscv: introduce aia_init() and aia_usable()
Date: Thu, 27 Aug 2026 17:19:03 +0200
Message-ID: <5e536829eca21aa951ba79344a012c79182b74f0.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787843980-F76BD2A1-73A65196/10/73395122804
X-purgate-type: spam
X-purgate-size: 3240

aia_init() is going to contain all the logic related to AIA initialization.

At the moment, it only checks whether the SSAIA extension is available,
and if so, sets is_aia_usable (which  indicates more than just the
availability of the extension) to true; it also signifies that the necessary
components (to be introduced in follow-up patches) have been initialized.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6-8:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Update the guards in asm/aia.h according to CODING_STYLE:
   s/ASM__RISCV__AIA_H/RISCV_AIA_H.
---
Changes in v4:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3:
 - s/is_aia_usable/_aia_usable to drop the is_ prefix while avoiding
   conflict with the aia_usable() function name.
---
Changes in v2:
 - s/is_aia_available/is_aia_usable.
 - Drop return value for aia_init().
 - s/aia_available()/aia_usable().
---
---
 xen/arch/riscv/Makefile          |  1 +
 xen/arch/riscv/aia.c             | 23 +++++++++++++++++++++++
 xen/arch/riscv/include/asm/aia.h | 10 ++++++++++
 xen/arch/riscv/intc.c            |  3 +++
 4 files changed, 37 insertions(+)
 create mode 100644 xen/arch/riscv/aia.c
 create mode 100644 xen/arch/riscv/include/asm/aia.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 2d24670dfc74..8e7a6370eee2 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,3 +1,4 @@
+obj-y += aia.o
 obj-y += aplic.o
 obj-y += cpufeature.o
 obj-y += domain.o
diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c
new file mode 100644
index 000000000000..e31c9c2d24b6
--- /dev/null
+++ b/xen/arch/riscv/aia.c
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/sections.h>
+#include <xen/types.h>
+
+#include <asm/cpufeature.h>
+
+static bool __ro_after_init _aia_usable;
+
+bool aia_usable(void)
+{
+    return _aia_usable;
+}
+
+void __init aia_init(void)
+{
+    if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) )
+        return;
+
+    _aia_usable = true;
+}
diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h
new file mode 100644
index 000000000000..aaa4bf91fc75
--- /dev/null
+++ b/xen/arch/riscv/include/asm/aia.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef RISCV_AIA_H
+#define RISCV_AIA_H
+
+bool aia_usable(void);
+
+void aia_init(void);
+
+#endif /* RISCV_AIA_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index e63da5e22efc..2864a896b677 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -9,6 +9,7 @@
 #include <xen/lib.h>
 #include <xen/spinlock.h>
 
+#include <asm/aia.h>
 #include <asm/intc.h>
 
 static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
@@ -33,6 +34,8 @@ void __init intc_init(void)
 {
     ASSERT(intc_hw_init_ops && intc_hw_init_ops->init);
 
+    aia_init();
+
     if ( intc_hw_init_ops->init() )
         panic("Failed to initialize the interrupt controller drivers\n");
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400823.1636450 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtI-0005fF-Ae; Thu, 27 Aug 2026 15:19:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400823.1636450; Thu, 27 Aug 2026 15:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtI-0005ep-1D; Thu, 27 Aug 2026 15:19:44 +0000
Received: by outflank-mailman (input) for mailman id 1400823;
 Thu, 27 Aug 2026 15:19:42 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtG-0005LW-JI
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtF-00C6ki-Vi
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:41 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905584-2eae-0a2a0a5409dd-0a2a4506d496-8
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:41 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90558d-195a-0a2a45060019-d155802dddce-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:41 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-499ac87c92bso20688155e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843981; x=1788448781; 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=nZD3gU2yZzrDhjPBJtPeKT6B+BREExRn7A4TAumGyiM=;
        b=mwQagBHRFzWDLIqCxzK9x1b2qb1zAkRX6/hU2hxPcaQPy9gHfW3gVLjV45ITp10aQJ
         /TJ2mphdxA5id6ELmya9G8k1uRRyq2tqnoHZh4HjcwP8O2wGFaT31ryaKSW5IQfliNtn
         kzCLGu1LXrc4gORNRNIug1kl9AV0LsUh4kKVDSUttNFs1IntdZODlI4TfcealRwm19f9
         g6PgxykaliGiQt1MBAeTyYLBvesk7IA2eVdjEYa6nkfy19VEniWThBAVGpt9QmjMgvUA
         +nhh7Ik2jEW6lJAFie38pNIfEMo/NtUe9QAKeTRGV75YNAwmKSaXC7JkFNQA6vOMEAbz
         o3UA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843981; x=1788448781;
        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=nZD3gU2yZzrDhjPBJtPeKT6B+BREExRn7A4TAumGyiM=;
        b=qOdDk1KD+lJmQMwu4UtkXJ+QlMFKN/qcUPl4g2yNmtnY5mStxgIC7C41wt9a+lEG/w
         muaHZAmyj7+gpA8DK0488rUzXiSIsbmFe2cykq60LenO3JpxE9KvLxteC1FGflGR6lHe
         smkE4ncnYUQYyrE07dmiHPn+6LMwi3/ara038MhLu4F1djn1304Eh9G4wbVoK1ebB3z2
         pEUfrmJSdhyzBtN8Y4xbDUWLF3ZP416WWCAdyxJzCVyBpw45DPf0LtP1P/9mzutyWRwo
         ZftKc2YhAnMfIPBoN0FLlfKpGkbi6Pd/OESmavF4+3xpWLZKgWqouFa/T26ay0YctztX
         s3HA==
X-Gm-Message-State: AFuF++ny+StXoL/a3KFf7rjbrKteYaORtMpQK4qLXJsN5LQsiJ2fuA5D
	W0METcRLyZin9WcVPFyB7JnGGwnjmHc7kvBm3C0h2XWEoTM9Epwqkid/iAtkFA==
X-Gm-Gg: AR+sD12tssgsK/MOpUUFG98/TTPjqPIXANMo630tb1p7MLVOH+SKqvxZc0vDOBYaWOD
	9XoVwIS0oGzQI8jRIf/j/YJP9O6c29Ea50LyIUgvqnxZB151AMwxeSiWZSI9GR/IUZsELLrEKPG
	ZKF0Ury9PSpnjAgTrQZ+9ICmwCm9o87gF1Z82Ml5jXXyk37k3mQI7AVy2thniVd4KXmXC0gMOe4
	r1AjhEwF167S7hh7JDWaNT1oaDJAd0rn7wcirCfGBGWOMADAmKTJB+lwEJLqpwnc3z8/tI0HP8S
	Ful7eBMYkJaLlOYVaK+PnynnQ4+dDKE3RChBfsHFKDjiYnU6q48LOJEXuUDwqIfAJxotaW7lekn
	0VD/2pOLP4wl9CkoTuPB5HlJG1ZkbIq/aoZPaQ5RephR6blWbVPZ4H0pAo3PzzhM4Nj1Fa+oy9W
	M1ePZv33hZYMFrkZVZxkCVo8ivMvPvkDC+x6cf0y2ehWgnUrcOf+IegYxk3EBv8OsnFT22UHM4S
	/2X3GFZ2+q8A/Y9BOw7iZxYbvcZDUhIiTk7xtvkRa2R
X-Received: by 2002:a05:600c:6287:b0:499:db27:7b1 with SMTP id 5b1f17b1804b1-499dc8311b7mr198446165e9.15.1787843980654;
        Thu, 27 Aug 2026 08:19:40 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 11/20] xen/riscv: introduce per-vCPU IMSIC state
Date: Thu, 27 Aug 2026 17:19:04 +0200
Message-ID: <86fd78c21e77834c0fb51f0c4e8c410360ea3d64.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787843981-FE47377B-FD561B1A/10/73395122804
X-purgate-type: spam
X-purgate-size: 6596

Each vCPU interacting with the IMSIC requires state to track the
associated guest interrupt file and its backing context.

Introduce a per-vCPU structure to hold IMSIC-related state, including
the guest interrupt file identifier and the CPU providing the backing
VS-file. Access to the guest file identifier is protected by a lock.

Initialize this structure during vCPU setup and store it in arch_vcpu.
The initial state marks the VS-file as software-backed until it becomes
associated with a physical CPU.

Add helper to retrieve the guest interrupt file identifier:
- vcpu_guest_file_id() is going to be used during update of APLIC's
  target register with the pair of information <guest_file_id, cpu_id>
  (to have MSI delivery mode work properly) when guest is trying to
  access vAPLIC's target register.
It will be used in the follow up patches.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Change in v8:
 - Rename imsic_state->vsfile_pcpu to ->*_cpu to reflect better its
   sentinel NR_CPUS.
---
Changes in v6-7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Move v->arch.vimsic_state = imsic_state; after full initialization of
   the struct, so the pointer only becomes globally visible once all
   fields are set up.
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v4:
-  s/w vs h/w IMSIC VS-file commentary for struct vimsic_state:
   - fix the vsfile_pcpu h/w condition:
     "vsfile_pcpu >= 0" -> "vsfile_pcpu < NR_CPUS"
     (the old wording conflicted with the s/w "== NR_CPUS" case).
   - reorder both comment blocks to the "s/w ... / h/w ..." form for readability.
 - drop IMPOSSIBLE_GUEST_FILE_ID: the s/w IMSIC VS-file is always available
   and corresponds to guest_file_id == 0, which xvzalloc() already provides,
   so the explicit initializer in vcpu_imsic_init() and the macro itself
   are unneeded.
---
Changes in v3:
 - Drop const from imsic_set_guest_file_id() and vcpu_imsic_deinit() as
   it only works due to vimsic_state being a pointer member.
 - Use XVFREE() in vcpu_imsic_deinit() to make it idempotent.
 - Fix SW-file typo in struct vimsic_state comments; should be VS-file.
 - Drop imsic_set_guest_file_id() here, it will be added later when it
   will be nessary to initialise guest file id as the correspondendt code
   in this patch series was reworked and there is no need to use this
   function in arch_vcpu_create().
 - Introduce IMPOSSIBLE_GUEST_FILE_ID and init with it ->guest_file_id.
---
Changes in v2:
 - Rename imsic_state to vimsic_state.
 - Use 'unsigned int' for vsfile_pcpu.
 - Drop initialzation of ->guest_file_id as it will be by default zero.
 - Add the comment about ->guest_file_id field.
 - Drop __init for vcpu_imsic_init() as it could be used during post-boot
   vCPU creation.
 - Update the commit message.
 - Drop locks around ->guest_file_id() in  vcpu_guest_file_id() and imsic_set_guest_file_id().
---
---
 xen/arch/riscv/imsic.c              | 35 +++++++++++++++++++++++++++++
 xen/arch/riscv/include/asm/domain.h |  2 ++
 xen/arch/riscv/include/asm/imsic.h  | 22 ++++++++++++++++++
 3 files changed, 59 insertions(+)

diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index f7b70a8da09e..a916def07380 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -16,6 +16,7 @@
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/macros.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/spinlock.h>
 #include <xen/xvmalloc.h>
@@ -56,6 +57,11 @@ do {                            \
     csr_clear(CSR_SIREG, v);    \
 } while (0)
 
+unsigned int vcpu_guest_file_id(const struct vcpu *v)
+{
+    return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id);
+}
+
 void __init imsic_ids_local_delivery(bool enable)
 {
     if ( enable )
@@ -312,6 +318,35 @@ static int imsic_parse_node(const struct dt_device_node *node,
     return 0;
 }
 
+int vcpu_imsic_init(struct vcpu *v)
+{
+    struct vimsic_state *imsic_state;
+
+    /* Allocate IMSIC context */
+    imsic_state = xvzalloc(struct vimsic_state);
+    if ( !imsic_state )
+        return -ENOMEM;
+
+    /* Setup IMSIC context  */
+    rwlock_init(&imsic_state->vsfile_lock);
+
+    /*
+     * xvzalloc() already cleared the context, so guest_file_id == 0, i.e. the
+     * always-available s/w IMSIC VS-file. Only vsfile_cpu needs an explicit
+     * initializer as its s/w VS-file value is NR_CPUS rather than 0.
+     */
+    imsic_state->vsfile_cpu = NR_CPUS;
+
+    v->arch.vimsic_state = imsic_state;
+
+    return 0;
+}
+
+void vcpu_imsic_deinit(struct vcpu *v)
+{
+    XVFREE(v->arch.vimsic_state);
+}
+
 /*
  * Initialize the imsic_cfg structure based on the IMSIC DT node.
  *
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h
index bd43ed08c22c..e035b33ddfdc 100644
--- a/xen/arch/riscv/include/asm/domain.h
+++ b/xen/arch/riscv/include/asm/domain.h
@@ -54,6 +54,8 @@ struct arch_vcpu {
 
     struct vtimer vtimer;
 
+    struct vimsic_state *vimsic_state;
+
     register_t hcounteren;
     register_t hedeleg;
     register_t hideleg;
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index c6c59215df20..5ee954bbf3ef 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -11,6 +11,7 @@
 #ifndef ASM_RISCV_IMSIC_H
 #define ASM_RISCV_IMSIC_H
 
+#include <xen/rwlock.h>
 #include <xen/spinlock.h>
 #include <xen/stdbool.h>
 #include <xen/types.h>
@@ -61,7 +62,24 @@ struct imsic_config {
     spinlock_t lock;
 };
 
+struct vimsic_state {
+    /* IMSIC VS-file */
+    rwlock_t vsfile_lock;
+    /*
+     * s/w IMSIC VS-file -> guest_file_id == 0
+     * h/w IMSIC VS-file -> guest_file_id > 0
+     */
+    unsigned int guest_file_id;
+    /*
+     * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS
+     * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS
+     */
+    unsigned int vsfile_cpu;
+};
+
 struct dt_device_node;
+struct vcpu;
+
 int imsic_init(const struct dt_device_node *node);
 
 const struct imsic_config *imsic_get_config(void);
@@ -71,4 +89,8 @@ void imsic_irq_disable(unsigned int hwirq);
 
 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);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400825.1636457 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtJ-0005v5-Kq; Thu, 27 Aug 2026 15:19:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400825.1636457; Thu, 27 Aug 2026 15:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtJ-0005tp-BI; Thu, 27 Aug 2026 15:19:45 +0000
Received: by outflank-mailman (input) for mailman id 1400825;
 Thu, 27 Aug 2026 15:19:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtH-0005WH-RN
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtG-00BpK6-RC
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:42 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90557e-8faa-0a2a0a5109dd-0a2a4503bb3a-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:42 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90558e-fae8-0a2a45030019-d1558029e0b1-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:42 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-49b8e527d63so6358815e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:41 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843982; x=1788448782; 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=W+cjjAmAdrDUJbwRcaPwXKgv9wbIDWWM3qq0kbN6Frc=;
        b=msN/HimpUNp+PMyESWKUWdql6c57y3RcgPaTAawpsniFSySevQaCLc5ugxXMA6rb3i
         aT3WqnJvavCNx266UZ5kPvnfMue7paq+aviR4yvKPVJoEyNmRG6JvrIfynFWw7D2tVWu
         sxWs8SGId1PdmYmkGAYIque9m5O0bfYEcTr0i31HuqPSH6aTaUCSgIzBORH1p/0z4Bvt
         u/gMaNlIx0/g9bqijaJc56AR0JuAj0n6pe563qQl1GcqHkIDItxw6zpVYaRjOg7yr033
         +5FXlI7J06SIQ3DBAkrAC0zHVHxBlQdQddfJ66JOUBHh4KIR9ufSMml3AB0GRsSwsETq
         zoFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843982; x=1788448782;
        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=W+cjjAmAdrDUJbwRcaPwXKgv9wbIDWWM3qq0kbN6Frc=;
        b=pZ3m+ldethAwdftTVIfuzd/7fT3um4wFBYSglVV0YG+9e8YHE8+13SSg0PHPEhMVjG
         quQglXm9ix4A7a+cJ1fTsSz2qNTNeur/56/QTEmncpVWT/TDsjasrec9vrtE5m/Ihyqh
         3AMr5Vzd4sSBEj0gqTAeteeE9airD3imtdqD/Ki/5txej6nngk2zZ7oDdcodkByurc5F
         0IOSzaDvbSDtqSOUaE10bvgGbEPHA2DNEnnMyXg/0dHjYK/OXW5IvcAguCCYbyCp1lRd
         cl8xmCQ3q02OyRq7rs+1PND1A+zwrg60jbwuAmp0ylgqJEeFG7jFoUQGOgW9/zIeV9dF
         j86g==
X-Gm-Message-State: AFuF++kji0lgegnYHDQRvVUzGzrTP4ijku28pT4WKAXBfLIcVd3wuCEa
	QGPC9i/RfprmGg33BNyJvoJf3y/fs7spWUI8t4CM4LVDtWUztNHpquk+7i4MXg==
X-Gm-Gg: AR+sD10XUbdNMLzpPoYLZunQcEeLtOOVPV+aUhGUA1j+D5hapES+oq44F/KF1H5vBht
	DxyPvBEl6IbIedmhYswUHEz35PVl0+fYfFOgkCVB3xM8armhOdVSTmQAa/JMRN2cZZNoUZGPc7/
	6RvjK+9UJbFeZSdj7pmrz0YTENdoWiWhFFcgAKrJW8UxzVzE4aWCd6qu5PSHv+V28ORHC7kYi8J
	PyZ84sMQaiOogoBydmbUFnudjC6GlCCpK6SjO0en/odXSBok4co06uQuEYzsc3JDVH0DhH7VLZP
	RdcP9JQslwWHfQV3bbHG6uM9YU5/AmoTe8nstdaawZttZ/MB5jc1rAmJ1O73ZZzwE7kGIBxAI9s
	f2avDTCTAsxkIhSRIUNSSh37qU7onIveH6Sx4i5OtC1pDRObTfViwGTkHr4Qk+g2eY/wWaq5d1Y
	SQUb538VW9XnHx8Ze++y6GlaBJpQtof+nXrrDYljKHP+9nuqBdpHdFdOpVxtPf5XDtqDSFXAZLi
	99vevlU+cytnckkIaPfYqRGnInFu0NN
X-Received: by 2002:a05:600c:8b4c:b0:499:a5fc:207e with SMTP id 5b1f17b1804b1-499dc7044c5mr203989825e9.8.1787843981972;
        Thu, 27 Aug 2026 08:19:41 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure
Date: Thu, 27 Aug 2026 17:19:05 +0200
Message-ID: <872d8b9e35d68d0b6ad02ae28e37f37dc931a4d8.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787843982-77CC34E9-26F8A57D/10/73395122804
X-purgate-type: spam
X-purgate-size: 10379

At the current development stage, only domain vINTC init and deinit
operations are required, so implement those first.

Initialize vAPLIC's domaincfg to with the interrupt-enable bit set and
MSI delivery mode selected as the current solution is exepcted to have
always IMSIC, and initialize vintc->ops.

Other operations such as emulate_load(), emulate_store(), and is_access()
will be needed once guests are running and MMIO accesses to APLIC MMIO
range must be handled. These will be introduced separately later.

Introduce a structure to describe a virtual interrupt controller (vINTC)
and a vintc_ops structure, which provides operations to emulate load and
store accesses to interrupt controller MMIOs and to check whether a given
address falls within the MMIO range of a specific virtual interrupt
controller.
Note that already existed init_ops field in struct vintc will be init-ed
for APLIC in the follow up patch.

The vAPLIC implementation of these operations will be provided later
once guests can be run and these operations are actually needed.

Introduce these structures here as they are required for the implementation
of domain_vaplic_init() and domain_vaplic_alloc(). Also, introduce
vaplic_init() and init vintc_ops->vcpu_init() with it.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v8:
 - Drop vaplic_init() and vcpu_aplic_deinit() as they are just calling
   IMSIC related files as we are expecting to work only MSI mode.
 - And add cf_check for vcpu_imsic_(de)init as they are directly used now
   for vintc_ops->vcpu_(de)init.
---
Changes in v7:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
 - Update the comment above init_ops member of vintc structure.
---
Changes in v6:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - Add explanational comments for fields in struct vintc.
 - Drop unnessary empty line in asm/aplic.h.
 - Update the commit message to tell that init_ops will be init-ed later
   in follow up patch.
 - Init. .domaincfg with only APLIC_DOMAINCFG_RO.
 - Update the comment above APLIC_DOMAINCFG_RO.
 - Add defintion for APLIC_DOMAINCFG_BE.
---
Changes in v4:
 - Change subject of the commit.
 - s/APLIC_DOMAINCFG_RO80/APLIC_DOMAINCFG_RO + added a comment above definition.
 - Drop unnessary blank lines.
---
Changes in v3:
 - Drop ASSERT() before vintc->ops->vcpu_init() in arch_vcpu_create(); a
   NULL deref already produces a sufficient backtrace.
 - Parenthesize macro argument in to_vaplic().
 - Drop __init from domain_vaplic_init() and domain_vaplic_deinit() since
   the caller domain_vintc_init() (follow-up patch) is not __init.
 - Remove pointless zero-initializer for rc in vcpu_vaplic_init().
 - Fix domain_vaplic_deinit() to null d->arch.vintc before freeing, making
   the function idempotent.
 - Drop intc_irq_nums(), (*nr_irqs)(void) hook from intc_hw_operations,
   aplic_nr_irqs(), and vintc->nr_irqs field entirely.
 - Rename vcpu_vaplic_init() to vaplic_init() and drop vgein_assign() and
   imsic_set_guest_file_id() calls; those will be introduced/called later,
   where for sure we will know on which pCPU vCPU as it is required for
   proper h/w IMSIC interrupt file calculation, to have this initialization
   in one place.
 - Introduce vaplic_deinit().
---
Changes in v2:
 - s/vcpu/v for function arguments in struct vintc_ops().
 - Update the comment above is_access() and drop const for addr argument.
 - Update to_vaplic() to work with 'struct domain *'.
 - Drop smsiaddrcfg{h} from vaplic_regs struct as they aren't used for now.
 - Drop inclusion of xen/schec.h from intc.c.
 - use result of xvzalloc() as initializer in vpalic_alloc().
 - Drop goto in domain_vaplic_init().
 - s/XVFREE/xvfree.
 - s/aplic/vintc.
 - Drop __init for vcpu_vaplic_init() as it could be called for secondary CPU bring up.
 - Drop vaplic_alloc().
 - Drop vintc_ops struct, embed callbacks iniside struct vintc.
 - Introduce and init vintc irqs for vAPLIC.
 - Introduce intc_irq_nums() to properly initialize number of vAPLIC's irqs.
---
---
 xen/arch/riscv/Makefile             |  1 +
 xen/arch/riscv/domain.c             | 11 ++----
 xen/arch/riscv/imsic.c              |  4 +--
 xen/arch/riscv/include/asm/aplic.h  |  7 ++++
 xen/arch/riscv/include/asm/intc.h   | 12 +++++++
 xen/arch/riscv/include/asm/vaplic.h | 34 +++++++++++++++++++
 xen/arch/riscv/vaplic.c             | 52 +++++++++++++++++++++++++++++
 7 files changed, 111 insertions(+), 10 deletions(-)
 create mode 100644 xen/arch/riscv/include/asm/vaplic.h
 create mode 100644 xen/arch/riscv/vaplic.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 8e7a6370eee2..fcd73c7a2dd5 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -25,6 +25,7 @@ obj-y += smpboot.o
 obj-y += stubs.o
 obj-y += time.o
 obj-y += traps.o
+obj-y += vaplic.o
 obj-y += vmid.o
 obj-y += vm_event.o
 obj-y += vsbi/
diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c
index c9933147595e..45712d305975 100644
--- a/xen/arch/riscv/domain.c
+++ b/xen/arch/riscv/domain.c
@@ -11,6 +11,7 @@
 #include <asm/bitops.h>
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
+#include <asm/intc.h>
 #include <asm/riscv_encoding.h>
 #include <asm/vtimer.h>
 
@@ -155,14 +156,8 @@ int arch_vcpu_create(struct vcpu *v)
     if ( (rc = vcpu_vtimer_init(v)) )
         goto fail;
 
-    /*
-     * As interrupt controller (IC) is not yet implemented,
-     * return an error.
-     *
-     * TODO: Drop this once IC is implemented.
-     */
-    rc = -EOPNOTSUPP;
-    goto fail;
+    if ( (rc = v->domain->arch.vintc->ops->vcpu_init(v)) )
+        goto fail;
 
     return rc;
 
diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index a916def07380..1e285a68fc4c 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -318,7 +318,7 @@ static int imsic_parse_node(const struct dt_device_node *node,
     return 0;
 }
 
-int vcpu_imsic_init(struct vcpu *v)
+int cf_check vcpu_imsic_init(struct vcpu *v)
 {
     struct vimsic_state *imsic_state;
 
@@ -342,7 +342,7 @@ int vcpu_imsic_init(struct vcpu *v)
     return 0;
 }
 
-void vcpu_imsic_deinit(struct vcpu *v)
+void cf_check vcpu_imsic_deinit(struct vcpu *v)
 {
     XVFREE(v->arch.vimsic_state);
 }
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index b0724fe6f360..5a7fcb6ec4f1 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -15,8 +15,15 @@
 
 #include <asm/imsic.h>
 
+/*
+ * 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_SOURCECFG_SM_INACTIVE     0x0
 #define APLIC_SOURCECFG_SM_DETACH       0x1
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index a4e678fad90b..875728885292 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -17,6 +17,7 @@ enum intc_variant {
 struct cpu_user_regs;
 struct irq_desc;
 struct kernel_info;
+struct vcpu;
 
 struct intc_info {
     enum intc_variant hw_variant;
@@ -53,8 +54,19 @@ struct vintc_init_ops {
     int (*make_domu_dt_node)(struct kernel_info *kinfo);
 };
 
+struct vintc_ops {
+    /* Initialize some vINTC-related stuff for a vCPU */
+    int (*vcpu_init)(struct vcpu *v);
+
+    /* Deinitialize some vINTC-related stuff for a vCPU */
+    void (*vcpu_deinit)(struct vcpu *v);
+};
+
 struct vintc {
+    /* Callbacks invoked during domain construction only. */
     const struct vintc_init_ops *init_ops;
+    /* Runtime callbacks used for the lifetime of the guest. */
+    const struct vintc_ops *ops;
 };
 
 void intc_preinit(void);
diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h
new file mode 100644
index 000000000000..96080bfbc23b
--- /dev/null
+++ b/xen/arch/riscv/include/asm/vaplic.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * xen/arch/riscv/vaplic.c
+ *
+ * Virtual RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ */
+
+#ifndef ASM__RISCV__VAPLIC_H
+#define ASM__RISCV__VAPLIC_H
+
+#include <xen/kernel.h>
+#include <xen/types.h>
+
+#include <asm/intc.h>
+
+struct domain;
+
+#define to_vaplic(d) container_of((d)->arch.vintc, struct vaplic, vintc)
+
+struct vaplic_regs {
+    uint32_t domaincfg;
+};
+
+struct vaplic {
+    struct vintc vintc;
+    struct vaplic_regs regs;
+};
+
+int domain_vaplic_init(struct domain *d);
+void domain_vaplic_deinit(struct domain *d);
+
+#endif /* ASM__RISCV__VAPLIC_H */
diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
new file mode 100644
index 000000000000..c9f188b989a3
--- /dev/null
+++ b/xen/arch/riscv/vaplic.c
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * xen/arch/riscv/vaplic.c
+ *
+ * Virtual RISC-V Advanced Platform-Level Interrupt Controller support
+ *
+ * Copyright (c) Microchip.
+ * Copyright (c) Vates
+ */
+
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/xvmalloc.h>
+
+#include <asm/aia.h>
+#include <asm/imsic.h>
+#include <asm/intc.h>
+#include <asm/vaplic.h>
+
+#include "aplic-priv.h"
+
+static const struct vintc_ops vintc_ops = {
+    .vcpu_init = vcpu_imsic_init,
+    .vcpu_deinit = vcpu_imsic_deinit,
+};
+
+int domain_vaplic_init(struct domain *d)
+{
+    struct vaplic *vaplic = xvzalloc(struct vaplic);
+
+    if ( !vaplic )
+        return -ENOMEM;
+
+    d->arch.vintc = &vaplic->vintc;
+    d->arch.vintc->ops = &vintc_ops;
+
+    vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO;
+
+    return 0;
+}
+
+void domain_vaplic_deinit(struct domain *d)
+{
+    struct vaplic *vaplic;
+
+    if ( !d->arch.vintc )
+        return;
+
+    vaplic = to_vaplic(d);
+    d->arch.vintc = NULL;
+    xvfree(vaplic);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400826.1636463 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtK-00064R-Ic; Thu, 27 Aug 2026 15:19:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400826.1636463; Thu, 27 Aug 2026 15:19:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtK-000620-4v; Thu, 27 Aug 2026 15:19:46 +0000
Received: by outflank-mailman (input) for mailman id 1400826;
 Thu, 27 Aug 2026 15:19:44 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtI-0005kT-Nc
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtI-00C6ki-4E
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:44 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905589-2eae-0a2a0a5409dd-0a2a4502d400-32
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:44 +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 <oleksii.kurochko@gmail.com>)
 id 6a90558f-6ca4-0a2a45020019-d155802adc43-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:44 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49978908b35so17282975e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843983; x=1788448783; 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=UB6QIi9ewt7tM857WFc3rZ8Sx0meiAHCBYlBjEcGVaY=;
        b=kKkpGy3raDjNXHmo+Jthwx3Dfak2xYw+ypmUuvTW5QV6YO9UHrqvbxzfNjs+UB2/oD
         o3v9E5OLKO9i5m/r23pOL3mbLCan0x9S/Qdrwc6S0mTPtMs7u/8SqYMfKWcpKtbG4aeO
         yBuaSn94ybH/PsXt++mHYuH7/vI5Dx0y2kTyrjY3FgT/X697Zv9YOuDeP0/lhw5g9ImB
         0LoA9x7ImToj85Bc70LUHN8X0zEzbRRoTLWX212EqNymx5f22zggpm80Lhdh03gWh6Ok
         ksO8wTNJjDFVYxrGkV7Z1M7Vw8XHkeVSKZ2RLB79p/X2pm2lCEaVTwTjoCnR6SbSWyqH
         4Vaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843983; x=1788448783;
        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=UB6QIi9ewt7tM857WFc3rZ8Sx0meiAHCBYlBjEcGVaY=;
        b=cPUMgkWWIk6cAMnRCz2/E/wrGt2q0eSao1GpMOKh6e9kcjsNaacf3jm5j9dycjeO6R
         UAOe8bxZ05rlOpE58EchYOwBhpRQq/XZ/r8qlglKXgHJKD/Uu39teCije2JQU/88gM3Q
         zQZwwPrwcYMoU5unZ1ahuR6GrKWNVD2h9j0fiJnqdYQZPNbY2nqmWwwNu48Ok/GUOTfF
         p0v/kFUXlmtmpylT/W3IGXkrRHTthcOUtVHEXzVtKgwYkTZ5gPF0YTA2UipQ7D3A204t
         PnAYMoPqqzk18NnreHa4lJQGbVxXe36Gzy34GN6S1nxlAciLuUjYVrvz4Oh8D6OnfOVc
         KEZQ==
X-Gm-Message-State: AFuF++mjh927HhUHtdEADU77rbsVlPfAv05cW4Hkz4QM9YRnvwH260pf
	0s7DFigoYWlDzA1Pg2mLSsu0qzrPyOouSZO8HPGTtCj/J2KOY5LFIKETXp2PNg==
X-Gm-Gg: AR+sD12p94kTC/kacSKvuiRSQ/gu6jrhBuTZt/mx2mlSvVVzLxz+4XP6lCt/h/bQv9f
	kjA4Bv8NW1BL4SIxKauTBdEfZtstW4usDDaaQkuIVBgspH7V21dTmUM9MWiIBOpCMvASLi7jJMl
	7uWJkJ0vUMgsgZbqqjSrhW/aqtf19/eZ1YE6ZS+qI2bvJCx1rVNqe5bVE98rx7nvWux0HG3f2VH
	v5u/ZYDOlnOk5ZXpRNOVolH5AmJ8j1AnAV1Wt6jlaLc3ebwq+Mo0+VPCp4xUAf4jNZZeomN3oTH
	PS7tuWrlL3KbFjO1j77a02Slb71wduabLPHJb2aygpy/2UjgbfpBhksZfHn/rv1qTzpfV8Y5f6U
	dSu7J9CEtwj+lBKD/OBprp4sRA1TV3e7E3F8pjtE32vmXampxAYoYpm2ZfYTxOCLffmQ/AXBlJv
	pL5Bt8ctcBbbr4FD9U44DDKyE8eLJikbbn4E894DLCUftjGuohHMXdJiTGXwHVceKVp0YtM/PvE
	DwFW2LXqwAgRK/1vvMV0DRqEvs8xqGNA9K7zTN3kLQ=
X-Received: by 2002:a05:600c:6912:b0:499:cd34:100d with SMTP id 5b1f17b1804b1-499dc703bd3mr211493985e9.7.1787843983291;
        Thu, 27 Aug 2026 08:19:43 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 13/20] xen/riscv: introduce (de)initialization helpers for vINTC
Date: Thu, 27 Aug 2026 17:19:06 +0200
Message-ID: <688352e340872a50af99a51082966669787b1f72.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787843984-F18AC2AC-9C4DB48E/10/73395122804
X-purgate-type: spam
X-purgate-size: 4102

Add common helpers domain_vintc_init() and domain_vintc_deinit() to
allocate and deallocate a virtual interrupt controller (vINTC)
structure and initialize basic virtual interrupt controller registers.

domain_vintc_deinit() isn't called at the moment as arch_domain_destroy()
is implemented as stub at the moment.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v8:
 - Add call of domain_vintc_deinit() to arch_domain_destroy().
 - Update printk message.
 - Drop Acked-by.
---
Changes in v6-7:
 - Nothing changed. Only rebase.
---
Changes in v5:
 - s/printk/printk_once().
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v4:
 - Drop the comment from domain_vintc_init() about guests receiving a
   virtual interrupt controller that mirrors the host hardware as there
   can (and eventually should) be alternatives.
 - Finish renaming intc_version to intc_variant in domain_vintc_(de)init()
   (enum intc_variant, info->hw_variant, local variable) started in the
   prev patch.
---
Changes in v3:
 - Drop redundant printk() from domain_vintc_deinit()'s default case to
   avoid duplicate messages when init fails.
 - Add a comment to domain_vintc_init() clarifying that guests currently
   receive a virtual interrupt controller that mirrors the host hardware.
---
Changes in v2:
 - Drop __init for domain_vintc_(de)init().
 - Update the commit message.
---
---
 xen/arch/riscv/domain.c           |  7 ++++++-
 xen/arch/riscv/include/asm/intc.h |  3 +++
 xen/arch/riscv/intc.c             | 35 +++++++++++++++++++++++++++++++
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c
index 45712d305975..d94652809e36 100644
--- a/xen/arch/riscv/domain.c
+++ b/xen/arch/riscv/domain.c
@@ -291,7 +291,9 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
 
 void arch_domain_destroy(struct domain *d)
 {
-    printk(XENLOG_WARNING "%s: unimplemented\n", __func__);
+    printk(XENLOG_WARNING "%s: not fully implemented\n", __func__);
+
+    domain_vintc_deinit(d);
 }
 
 int arch_domain_create(struct domain *d,
@@ -308,6 +310,9 @@ int arch_domain_create(struct domain *d,
     if ( (rc = p2m_init(d, config)) != 0)
         goto fail;
 
+    if ( (rc = domain_vintc_init(d)) )
+        goto fail;
+
     return rc;
 
  fail:
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 875728885292..6fc0e620e937 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -79,4 +79,7 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 
 void intc_handle_external_irqs(struct cpu_user_regs *regs);
 
+int domain_vintc_init(struct domain *d);
+void domain_vintc_deinit(struct domain *d);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index 2864a896b677..f5c8af6ddea4 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -11,6 +11,7 @@
 
 #include <asm/aia.h>
 #include <asm/intc.h>
+#include <asm/vaplic.h>
 
 static const struct intc_hw_operations *__ro_after_init intc_hw_ops;
 
@@ -83,3 +84,37 @@ int __init make_intc_domU_node(struct kernel_info *kinfo)
 
     return vintc->init_ops->make_domu_dt_node(kinfo);
 }
+
+int domain_vintc_init(struct domain *d)
+{
+    int ret = -EOPNOTSUPP;
+    const enum intc_variant variant = intc_hw_ops->info->hw_variant;
+
+    switch ( variant )
+    {
+    case INTC_APLIC:
+        ret = domain_vaplic_init(d);
+        break;
+
+    default:
+        printk_once("vintc (variant:%d) isn't implemented\n", variant);
+        break;
+    }
+
+    return ret;
+}
+
+void domain_vintc_deinit(struct domain *d)
+{
+    const enum intc_variant variant = intc_hw_ops->info->hw_variant;
+
+    switch ( variant )
+    {
+    case INTC_APLIC:
+        domain_vaplic_deinit(d);
+        break;
+
+    default:
+        break;
+    }
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400829.1636472 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtM-0006Pk-0i; Thu, 27 Aug 2026 15:19:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400829.1636472; Thu, 27 Aug 2026 15:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtL-0006OQ-PY; Thu, 27 Aug 2026 15:19:47 +0000
Received: by outflank-mailman (input) for mailman id 1400829;
 Thu, 27 Aug 2026 15:19:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtK-0005zJ-1n
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtJ-00C6ki-Eb
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:45 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905584-2eae-0a2a0a5409dd-0a2a4506d496-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:45 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905591-195a-0a2a45060019-d155802eb561-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:45 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49557167508so8884265e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19:45 -0700 (PDT)
Received: from fedora (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type: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=1787843985; x=1788448785; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type: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=9qwEd9f+ju7hZ/8uC6ij6YLmcv1QVKWDiXLVpDUqbt0=;
        b=MZJOISWzi1LAq+vX8ht4aOs1JAacPN8R2d+ocD/onaF3aOrHAYaHG30ZYuD5plX8YF
         TOFBI5Fl2Yow2ZDO3QxrJregtm2N8UFsIl2N3CBUyFAZr4bjtMd8M+5gpURKjFoxswyQ
         ci6hVbmh+KIMNrvc2ivosW6ZpVxf1W3y1tyTedu7yBkovyb+YnsJTdihKlq1awn2mNBL
         M3z41lDdNBc8LvGhju7lKuzr52wVNqDY2qfMGnHyVXY+339ZQc9r1kRIy/Mymvm65wTH
         cM9ebLvmPYXglNycxeU0NSdSKxyL+U2NoucfqFfGMbq91dsIiBAUbjECcdHkDur6RjCa
         tWTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843985; x=1788448785;
        h=content-transfer-encoding:content-type: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=9qwEd9f+ju7hZ/8uC6ij6YLmcv1QVKWDiXLVpDUqbt0=;
        b=LNNvSmWU8l0sze6/NZF0gNlxohUZ6jMPKTlk9lDxhWPPuTLxB9Ux/1Xw+Ch8fUoC6W
         axdugWjKOQdkq7oZf7DGVYsCZfpOYZlZ7QyKBGNKfYRDoPECTVZGySQB0otsngvPfNbJ
         gAdsRr/vfjrkqCBKLme0KefUFY1W2lZGMRJSml1JlKl8ji72JqyWa9Ee8qyoH7le2CD1
         WUhzXVK6lfvuwRBGk/mfAvMJGwPqcEuNJdbNFsoNm/tom2FOo72No8AH3V791GQDSXEJ
         sQxWBqHTAR1ifFCzmWyIZ/Tyqg5l0yh5imhPvRtBOIgLK4ZF8ZBRh6keJstk01iCXTym
         Vwfw==
X-Gm-Message-State: AFuF++kMMljTeQ2Hnpmulr9+qkQCCOxY2GBzzFI0xMajh+qANqNQDhT/
	6t/ug+jox3mjqLuZO+9/99Qqafk3PKo2ISfc1pRxuTjjcGYwuuWAcCRKb6KOAg==
X-Gm-Gg: AR+sD12Qr7QAT2z0rOOslSKCWrtAzMUnK+4Eb2F2mLgHi2B17uQOljDQwCiMHuw2aFm
	yjPab90NU0peOA1sKfbx2k8jfSyo2KNNv23qTFrCd+0KCEKCZ2udokMsPlvlI9c78gH8gHUSmqA
	AY2grYmEc2Q225yn6ZxcMb9V7q0/91QjIho06xpn8eal/4Py94ZL7spodRjo5TZ+U/OSN3vE4WU
	/IGex04tZfgJxzleOn0iXqB3Z+NH/L/VVuROTbhUPVNCIowuaQdQf7Vm1jJClWfC5xJPeul+Nwt
	iO67R4Sq9aRTnRHIOo8RXIf9dI+X8g6M9XnDTNnOQCPlsrNJ4U7MjhFqzlS0pFW0CthxyA6komw
	V0Ws3KDeUKXlg8d2RscnofiaBadmnqRDeK+nsLkmzepc2KavtWYhRKzidHRLlkCZZOroTZ5AXee
	/sssu3iRNZSxtnIGnnd23zfZ8hNZja5gDoqs0mWHPoy9piIVQIgeCOzJtYJtl/glXTZNtoYqnJm
	0xue1vD33/99e9n5oVTDk5lryHkoC2b
X-Received: by 2002:a05:600c:1382:b0:493:f140:c3fb with SMTP id 5b1f17b1804b1-499dc70b76dmr175117265e9.7.1787843984684;
        Thu, 27 Aug 2026 08:19:44 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 14/20] xen/riscv: generate IMSIC DT node for guest domains
Date: Thu, 27 Aug 2026 17:19:07 +0200
Message-ID: <6ab7ba5a0e47bba5f77c919ace4834a775f5a3b0.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787843985-F687577B-888D0FA5/10/73395122804
X-purgate-type: spam
X-purgate-size: 10787

Guests using the IMSIC interrupt controller require a corresponding
Device Tree description.

Add support for generating an IMSIC node when building the guest DT.
This allows guests to discover and use the IMSIC interrupt controller.

The value choosen for GUEST_IMSIC_S_BASE is an address which is typically
used for IMSIC and QEMU.

DT-building functions are marked __init because domain creation happens at
boot time, before the init sections are freed. In a typical deployment
libxl creates the interrupt controller node in userspace and hands the
complete FDT to Xen, so these functions are only called during early
domain construction.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v8:
 - Nothing changed. Only rebase.
---
Changes in v7:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v6:
 - Simplify initialization of guest_num_msis.
 - s/sizeof(vimsic_name)/ARRAY_SIZE(...).
 - Add empty line between declaration(s) and statement(s) in make_domu_dt_node().
 - define GUEST_IMSIC_MAX_MSIS as 255U to avoid '+0U' when min(...) is used.
---
Changes in v5:
 - s/GUEST_IMSIC_NUM_MSIS/GUEST_IMSIC_MAX_MSIS throughout.
 - Changed __read_mostly → __ro_after_init on guest_num_msis, since the value
   is set once during __init and never again.
 - Made imsic_parse_node() __init.
 - Moved the min(GUEST_IMSIC_MAX_MSIS, ...) cap into imsic_parse_node() right
   after guest_num_msis is assigned, so the bound is applied once at init
   time rather than on every DT node construction call.
 - Removed the now-unnecessary num_msis local variable from
   vimsic_make_domu_dt_node(); guest_num_msis is used directly.
 - s/snprintf(buf, sizeof(buf), ...)/snprintf(buf, ARRAY_SIZE(buf), ...)
   in guest_imsic_set_interrupt_extended_prop().
 - Added decl. of vimsic_make_domu_dt_node() in this patch instead of next.
---
Changes in v4:
 - Add a comment for guest_num_msis explaining that it is host-dependent
   and therefore identical for every domain, which is why a single global
   is used instead of a per-domain value.
 - Reduce vimsic_name[] from 128 to 32 bytes, which is enough to hold
   "/soc/imsic@" plus a 64-bit hex address.
 - Add a comment before GUEST_IMSIC_S_BASE noting that the value is the
   address typically used for IMSIC by QEMU.
 - s/__ULL/_UL for defintion of GUEST_IMSIC_S_BASE.
---
Changes in v3:
 - s/__ro_after_init/__read_mostly for guest_num_msis.
 - Use IMSIC_MAX_ID as default for guest_num_msis instead of imsic_cfg.nr_ids.
 - Drop base_addr local variable in guest_imsic_make_reg_property(); use
   GUEST_IMSIC_S_BASE directly and introduce size to avoid spelling
   IMSIC_MMIO_PAGE_SZ * d->max_vcpus twice.
 - Change irq_ext type from uint32_t * to __be32 * in
   guest_imsic_set_interrupt_extended_prop().
 - Move phandle declaration into the loop body.
 - Extend commit message to explain why __init is used for DT-building
   functions: libxl creates the interrupt controller node before handing
   the FDT to Xen, so these functions are only invoked during boot-time
   domain construction.
 - Re-order patch before APLIC DT node creation patch.
 - Update commit message.
---
Changes in v2:
 - s/imsic_make_reg_property/guest_imsic_make_reg_property.
 - s/imsic_set_interrupt_extended_prop/guest_imsic_set_interrupt_extended_prop.
 - Use initalizer for regs[] array in imsic_make_reg_property().
 - Move buf[] insde the for() loop.
 - Correct check of returned phandle.
 - Drop local variable len.
 - /s/XVFREE/xvfree in imsic_set_interrupt_extended_prop().
 - Drop initializer for local variable data.
 - s/uint32_t/unsinged int for pos and cpu in imsic_set_interrupt_extended_prop().
 - Drop next_phandle as it is now in common code.
 - Introduce vcpu_imsic_deinit.
 - Refactor vimsic_make_domu_dt_node() to avoid usage of host IMSIC dt node.
---
---
 xen/arch/riscv/imsic.c                    | 143 +++++++++++++++++++++-
 xen/arch/riscv/include/asm/guest-layout.h |   6 +
 xen/arch/riscv/include/asm/imsic.h        |   3 +
 3 files changed, 151 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c
index 1e285a68fc4c..ad0a220edac2 100644
--- a/xen/arch/riscv/imsic.c
+++ b/xen/arch/riscv/imsic.c
@@ -13,8 +13,12 @@
 #include <xen/const.h>
 #include <xen/cpumask.h>
 #include <xen/device_tree.h>
+#include <xen/domain.h>
 #include <xen/errno.h>
+#include <xen/fdt-domain-build.h>
+#include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/macros.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
@@ -34,6 +38,21 @@ static struct imsic_config imsic_cfg = {
     .lock = SPIN_LOCK_UNLOCKED,
 };
 
+/*
+ * Number of MSIs available to a guest. Determined by the host interrupt
+ * controller, so it is identical for every domain -- hence a single global
+ * rather than a per-domain value.
+ */
+static unsigned int __ro_after_init guest_num_msis;
+
+#define GUEST_IMSIC_COMPATIBLE "riscv,imsics"
+
+/*
+ * Value is inspired by what QEMU is using for riscv,num-ids property for IMSIC
+ * node.
+ */
+#define GUEST_IMSIC_MAX_MSIS 255U
+
 #define IMSIC_DISABLE_EIDELIVERY    0
 #define IMSIC_ENABLE_EIDELIVERY     1
 #define IMSIC_DISABLE_EITHRESHOLD   1
@@ -182,7 +201,7 @@ static int __init imsic_get_parent_hartid(const struct dt_device_node *node,
  * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC,
  * which should be ignored by the hypervisor.
  */
-static int imsic_parse_node(const struct dt_device_node *node,
+static int __init imsic_parse_node(const struct dt_device_node *node,
                             unsigned int *nr_parent_irqs,
                             unsigned int *nr_mmios)
 {
@@ -285,6 +304,11 @@ static int imsic_parse_node(const struct dt_device_node *node,
         return -ENOENT;
     }
 
+    if ( dt_property_read_u32(node, "riscv,num-guest-ids", &tmp) )
+        guest_num_msis = min(GUEST_IMSIC_MAX_MSIS, tmp);
+    else
+        guest_num_msis = GUEST_IMSIC_MAX_MSIS;
+
     if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) ||
          (imsic_cfg.nr_ids > IMSIC_MAX_ID) )
     {
@@ -522,3 +546,120 @@ int __init imsic_init(const struct dt_device_node *node)
 
     return rc;
 }
+
+static int __init guest_imsic_make_reg_property(struct domain *d, void *fdt)
+{
+    paddr_t size = IMSIC_MMIO_PAGE_SZ * d->max_vcpus;
+    __be32 regs[4] = {
+        cpu_to_be32(GUEST_IMSIC_S_BASE >> 32),
+        cpu_to_be32(GUEST_IMSIC_S_BASE),
+        cpu_to_be32(size >> 32),
+        cpu_to_be32(size),
+    };
+
+    return fdt_property(fdt, "reg", regs, sizeof(regs));
+}
+
+static int __init guest_imsic_set_interrupt_extended_prop(struct domain *d,
+                                                          void *fdt)
+{
+    unsigned int cpu, pos = 0;
+    __be32 *irq_ext;
+    int res;
+
+    irq_ext = xvzalloc_array(__be32, d->max_vcpus * 2);
+    if ( !irq_ext )
+        return -ENOMEM;
+
+    for ( cpu = 0; cpu < d->max_vcpus; cpu++ )
+    {
+        char buf[64];
+        uint32_t phandle;
+
+        snprintf(buf, ARRAY_SIZE(buf), "/cpus/cpu@%u/interrupt-controller", cpu);
+        phandle = fdt_get_phandle(fdt, fdt_path_offset(fdt, buf));
+
+        if ( !phandle )
+        {
+            res = -ENODEV;
+            goto out;
+        }
+
+        irq_ext[pos++] = cpu_to_be32(phandle);
+        irq_ext[pos++] = cpu_to_be32(IRQ_S_EXT);
+    }
+
+    res = fdt_property(fdt, "interrupts-extended", irq_ext,
+                       d->max_vcpus * 2 * sizeof(*irq_ext));
+
+ out:
+    xvfree(irq_ext);
+
+    return res;
+}
+
+int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo,
+                                    unsigned int *phandle)
+{
+    int res;
+    void *fdt = kinfo->fdt;
+    char vimsic_name[32];
+    unsigned int vimsic_phandle;
+
+    res = snprintf(vimsic_name, ARRAY_SIZE(vimsic_name), "/soc/imsic@%lx",
+                   GUEST_IMSIC_S_BASE);
+    if ( res >= ARRAY_SIZE(vimsic_name) )
+    {
+        dprintk(XENLOG_DEBUG, "vimsic name is truncated\n");
+        return -ENOBUFS;
+    }
+
+    res = fdt_begin_node(fdt, vimsic_name);
+    if ( res )
+        return res;
+
+    res = fdt_property_string(fdt, "compatible", GUEST_IMSIC_COMPATIBLE);
+    if ( res )
+        return res;
+
+    res = guest_imsic_make_reg_property(kinfo->bd.d, fdt);
+    if ( res )
+        return res;
+
+    res = guest_imsic_set_interrupt_extended_prop(kinfo->bd.d, fdt);
+    if ( res )
+        return res;
+
+    res = fdt_property_u32(fdt, "riscv,num-ids", guest_num_msis);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "msi-controller", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_u32(fdt, "#msi-cells", 0);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_u32(fdt, "#interrupt-cells", 0);
+    if ( res )
+        return res;
+
+    vimsic_phandle = alloc_phandle(kinfo);
+    if ( !vimsic_phandle )
+        return -EOVERFLOW;
+
+    res = fdt_property_cell(fdt, "phandle", vimsic_phandle);
+    if ( res )
+        return res;
+
+    if ( phandle )
+        *phandle = vimsic_phandle;
+
+    return fdt_end_node(fdt);
+}
diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h
index 68d95a09394c..5e566450bdfa 100644
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -3,6 +3,12 @@
 
 #include <public/xen.h>
 
+/*
+ * Base address of the guest's supervisor-mode IMSIC. The value is the address
+ * typically used for IMSIC by QEMU.
+ */
+#define GUEST_IMSIC_S_BASE _UL(0x28000000)
+
 #define GUEST_RAM_BANKS   2
 
 /*
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h
index 5ee954bbf3ef..2425430ed116 100644
--- a/xen/arch/riscv/include/asm/imsic.h
+++ b/xen/arch/riscv/include/asm/imsic.h
@@ -78,6 +78,7 @@ struct vimsic_state {
 };
 
 struct dt_device_node;
+struct kernel_info;
 struct vcpu;
 
 int imsic_init(const struct dt_device_node *node);
@@ -93,4 +94,6 @@ int vcpu_imsic_init(struct vcpu *v);
 void vcpu_imsic_deinit(struct vcpu *v);
 unsigned int vcpu_guest_file_id(const struct vcpu *v);
 
+int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phandle);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400830.1636482 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtN-0006jQ-HG; Thu, 27 Aug 2026 15:19:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400830.1636482; Thu, 27 Aug 2026 15:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtN-0006iF-7L; Thu, 27 Aug 2026 15:19:49 +0000
Received: by outflank-mailman (input) for mailman id 1400830;
 Thu, 27 Aug 2026 15:19:47 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtL-0006I3-EN
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtK-00BpK6-RL
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:46 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90557e-8faa-0a2a0a5109dd-0a2a4503bb3a-36
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:46 +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 <oleksii.kurochko@gmail.com>)
 id 6a905592-fae8-0a2a45030019-d155dd2dbc60-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:46 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47f96c5b722so506199f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:45 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843986; x=1788448786; 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=wn2L+RUC5jn8gwgXM/vtHAfcrUXMAm9q6Hgp6yBPabs=;
        b=Il2ESVAoHegQQMqFqNGDY5nf6sQx9PMgyY0IfWhcqEoNhBzhCp/0IcKbGj9TWCR+WA
         XexjLk2iX0ZT/m58lvHw2V1aOw2ZE2Nrv9no9B+SXzh/4fiZ10HHmZ7wSfn0cCeDXPIC
         JyuQXweHJ0lXWYpqvy0f7PcQtS60dxbLoXIePa6FClM1rodsWJkdqW/WxnpBJy1KnIvr
         nG6pvJ4VlomQDgJmbHSoyOFA/Epf0hWtI8381QoM2BDzzIUhg+2nzcKkS0NYfZxIn5AW
         LTuJ/iPnHme7zf+cIiAgI4iDRYyTvC2VA+Aqi99YJAtVuiBGRwt6jKshY5yh81viSmlp
         hWOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843986; x=1788448786;
        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=wn2L+RUC5jn8gwgXM/vtHAfcrUXMAm9q6Hgp6yBPabs=;
        b=GcDEJWo/yOTnTQCHOw///VOhxNcrh0dbxqRAxxQYtcRqGlloBltqdKWhNgsHTkAUK+
         p0bjrYnfdipJESu0tKs7llIUTCsATjmNTA+4qCLt/aLvGdCaw25TCn0tZY84qNIpCxN2
         E6oKYXfbuMjvwTx+PRp9eUX1AogkUBHjtLEpWt6nO5zw7cuTCraibQB8wrhrVEdkSAb6
         Q7+QATKRP4qjG+Sio8+ujeAGsWzdjaL3J98Euu3Gn4wRMTKafPACcrXSD5mbUnVioeyQ
         a3wz2j5UNS6ELXWlV6xJC9Qefy1pGNYzI6AHMr5yau9j3A7jYl+YOmR0RdIQQQ3J/0B3
         kRyA==
X-Gm-Message-State: AFuF++nbyKSTVgxMhUvuDjuvC8T7NMlfKNYEjvhgCUjLhhASoyl3ZJna
	PhV2idXtwuLCHHdhj6ubt+hMhQ4RY/cxA5Be9M3xannyn1y747NkIwsCkchXBA==
X-Gm-Gg: AR+sD103NAhNOVCKjQRET95eBCeW7c+wD4eT+1SvBuQizUGSJJlcxRxmlPRAsE4cxmf
	jYBA2M450rpajdlvz9PX+/Ol1d63XSfAnKWiCSIcvuSD5auIP6MCR07BVwMMxGqnIYbZEiOaZkp
	UZbi52S+A53u8BgemEemNxL0RmLkRBt3YJ1dTEMLmkeaMFJwoE2BrKQKp2TILjOch3senckr8W1
	LX6r/MfRHMOMHMwU9CJDVcagZnsN2nyJ+Cesjutulww1M2ZY3vKgYuuh7yojXRejHFBcFSz3xhn
	9hjt9X6eKMXPQSY+AUSTNbdyH4SG+VKeCRyeL7UzcHhuGTYn7BbbbMu18K/MlwOZCvZgRejz3Dq
	GahT3ESp+9ACkT35ij4Q/ETUvPi7Ios/phO9WjqXBFc7qU9BJrrAuJWoIMBj0XcvD3oCUQ8oOr5
	ekgndn1lG8tu5Enb/gsug+7o4HBjqx3+itpm78wPmTAbiso3KyoMxs7DX0PznfF5klsvAQHy//M
	e7aG42n5KTgemsnLGVEXd/f38RVuHeA
X-Received: by 2002:a5d:5f84:0:b0:482:f2f0:ca3d with SMTP id ffacd0b85a97d-482f2f0cb3bmr8879609f8f.14.1787843986154;
        Thu, 27 Aug 2026 08:19:46 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 15/20] xen/riscv: create APLIC DT node for guest domains
Date: Thu, 27 Aug 2026 17:19:08 +0200
Message-ID: <52158e389059bc11e4f5c88ad3f075ebba98526d.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787843986-772F54E9-56592673/10/73395122804
X-purgate-type: spam
X-purgate-size: 8883

Guests require a Device Tree description of the interrupt controller
topology. Add support for creating an APLIC node when building the
guest DT.

Provide stub for imsic_make_dt_node() it will be introduced properly
in follow-up patch.

The value chosen for GUEST_APLIC_S_BASE is based on QEMU one.

DT-building functions are marked __init because domain creation happens at
boot time, before the init sections are freed. In a typical deployment
libxl creates the interrupt controller node in userspace and hands the
complete FDT to Xen, so these functions are only called during early
domain construction.

Co-developed-by: Romain Caritey <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
changes in v8:
 - Nothing changed. Only rebase.
---
Changes in v7:
 - Update the comment for guest_aplic_num_sources: drop "wired" to be less
   confusing, and mention that it is identical for every domain only for
   now.
 - Use ARRAY_SIZE() instead of sizeof() for the size argument of
   snprintf() in vaplic_make_domu_dt_node().
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v6:
 - Redefine GUEST_APLIC_MAX_SOURCES as 96U to avoid '+OU' in min(...).
 - s/guest_num_sources/guest_aplic_num_sources.
---
Changes in v5:
 - Drop pointless initializer for local variable res in
   vaplic_make_domu_dt_node().
 - Limit guest_num_sources in the similar way to IMSIC.
 - Rename VAPLIC_NUM_SOURCES to GUEST_APLIC_MAX_SOURCES to be aligned with
   the similar place in vIMSIC related code.
---
Changes in v4:
 - Drop spurious <xen/fdt-kernel.h> and <xen/libfdt/libfdt.h> includes from
   aplic.c (mistakenly added, they belong to vaplic.c).
 - Reduce vaplic_name[] from 128 to 32 bytes in vaplic_make_domu_dt_node().
 - Use __initconstrel (with const) for init_ops instead of __initdata.
 - s/__ULL/_UL for defintion of GUEST_APLIC_S_BASE.
---
Changes in v3:
 - Fix rebase conflicts becuase of this patch is reordered after IMSIC DT
   node creation is intoduced.
 - Update the commit message.
 - Move initialization of domaincfg with APLIC_DOMAINCFG_RO80 from this
   patch to earlier.
 - Change paddr_t aplic_size to unsigned int in vaplic_make_domu_dt_node()
   and replace the UB (after it started to be uint) aplic_size >> 32 with
   an explicit 0 in the DT reg property.
 - Add BUILD_BUG_ON() to be sure that aplic size isn't bigger then
   UINT32_MAX.
---
Changes in v2:
 - Avoid as max as possible of host properties inheritance. Only number of
   APLIC's irqs are checked what leads to an introduction of
   get_aplic_irqs_num().
 - Move this patch earlier what leads to an introduction of
   vimsic_make_domu_dt_node() stub.
 - s/vimsic_make_domu_dt_node/imsic_make_domu_dt_node.
 - Refactor vimsic_make_domu_dt_node() to avoid re-usage of APLIC host
   properties.
 - Drop next_phandle as it is now in common code.
 - Drop const for kinfo argument of vimsic_make_domu_dt_node() is is
   going to be updated inside vimsic_make_domu_dt_node().
 - Use introduced before vintc->num_irqs.
---
---
 xen/arch/riscv/aplic-priv.h               | 13 ++++
 xen/arch/riscv/aplic.c                    |  2 +
 xen/arch/riscv/include/asm/aplic.h        |  8 +++
 xen/arch/riscv/include/asm/guest-layout.h |  6 ++
 xen/arch/riscv/vaplic.c                   | 77 +++++++++++++++++++++++
 5 files changed, 106 insertions(+)

diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h
index 85e0d028d1ae..35100d3a64fe 100644
--- a/xen/arch/riscv/aplic-priv.h
+++ b/xen/arch/riscv/aplic-priv.h
@@ -34,4 +34,17 @@ struct aplic_priv {
     const struct imsic_config *imsic_cfg;
 };
 
+/*
+ * Value is inspired by what QEMU is using for riscv,num-sources property for
+ * APLIC node.
+ */
+#define GUEST_APLIC_MAX_SOURCES 96U
+
+/*
+ * Specifies the number of interrupt sources supported by guest APLIC domain.
+ * Could be limited by host interrupt controller and is identical for every
+ * domain for now.
+ */
+extern unsigned int guest_aplic_num_sources;
+
 #endif /* ASM_RISCV_APLIC_PRIV_H */
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index d08401db46b3..c2d7183e1852 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -92,6 +92,8 @@ static int __init cf_check aplic_init(void)
         panic("%s: failed to get number of interrupt sources\n",
               node->full_name);
 
+    guest_aplic_num_sources = min(GUEST_APLIC_MAX_SOURCES, aplic_info.num_irqs);
+
     if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) )
         aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg);
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h
index 5a7fcb6ec4f1..07318aaac25d 100644
--- a/xen/arch/riscv/include/asm/aplic.h
+++ b/xen/arch/riscv/include/asm/aplic.h
@@ -34,6 +34,14 @@
 
 #define APLIC_TARGET_HART_IDX_SHIFT 18
 
+#define APLIC_IDC_SIZE          32
+
+#define APLIC_MIN_SIZE          0x4000
+#define APLIC_SIZE_ALIGN(x)     ROUNDUP(x, APLIC_MIN_SIZE)
+
+#define APLIC_SIZE(nr_cpus)     (APLIC_MIN_SIZE + \
+                                 APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus)))
+
 struct aplic_regs {
     uint32_t domaincfg;         /* 0x0000 */
     uint32_t sourcecfg[1023];   /* 0x0004 */
diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h
index 5e566450bdfa..90603f06bb91 100644
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -3,6 +3,12 @@
 
 #include <public/xen.h>
 
+/*
+ * Base address of the guest's supervisor-mode APLIC. The value is the address
+ * typically used for APLIC by QEMU.
+ */
+#define GUEST_APLIC_S_BASE _UL(0xd000000)
+
 /*
  * Base address of the guest's supervisor-mode IMSIC. The value is the address
  * typically used for IMSIC by QEMU.
diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
index c9f188b989a3..a529a5b1dc49 100644
--- a/xen/arch/riscv/vaplic.c
+++ b/xen/arch/riscv/vaplic.c
@@ -9,6 +9,8 @@
  */
 
 #include <xen/errno.h>
+#include <xen/fdt-kernel.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/sched.h>
 #include <xen/xvmalloc.h>
 
@@ -19,6 +21,80 @@
 
 #include "aplic-priv.h"
 
+unsigned int __ro_after_init guest_aplic_num_sources;
+
+#define VAPLIC_COMPATIBLE "riscv,aplic"
+
+#define FDT_VAPLIC_INT_CELLS 2
+
+static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *kinfo)
+{
+    struct domain *d = kinfo->bd.d;
+    int res;
+    void *fdt = kinfo->fdt;
+    unsigned int msi_parent_phandle;
+    char vaplic_name[32];
+    unsigned int aplic_size = APLIC_SIZE(d->max_vcpus);
+    const __be32 reg[] = {
+        cpu_to_be32(GUEST_APLIC_S_BASE >> 32),
+        cpu_to_be32(GUEST_APLIC_S_BASE),
+        cpu_to_be32(0),
+        cpu_to_be32(aplic_size),
+    };
+
+    BUILD_BUG_ON(APLIC_SIZE(MAX_VIRT_CPUS) > UINT_MAX);
+
+    res = snprintf(vaplic_name, ARRAY_SIZE(vaplic_name), "/soc/aplic@%lx",
+                   GUEST_APLIC_S_BASE);
+    if ( res >= sizeof(vaplic_name) )
+    {
+        dprintk(XENLOG_DEBUG, "vaplic name is truncated\n");
+        return -ENOBUFS;
+    }
+
+    res = vimsic_make_domu_dt_node(kinfo, &msi_parent_phandle);
+    if ( res )
+        return res;
+
+    res = fdt_begin_node(fdt, vaplic_name);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "#interrupt-cells", FDT_VAPLIC_INT_CELLS);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "reg", reg, sizeof(reg));
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "riscv,num-sources", guest_aplic_num_sources);
+    if ( res )
+        return res;
+
+    res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+    if ( res )
+        return res;
+
+    res = fdt_property_string(fdt, "compatible", VAPLIC_COMPATIBLE);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "msi-parent", msi_parent_phandle);
+    if ( res )
+        return res;
+
+    res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc);
+    if ( res )
+        return res;
+
+    return fdt_end_node(fdt);
+}
+
+static const struct vintc_init_ops __initconstrel init_ops = {
+    .make_domu_dt_node = vaplic_make_domu_dt_node,
+};
+
 static const struct vintc_ops vintc_ops = {
     .vcpu_init = vcpu_imsic_init,
     .vcpu_deinit = vcpu_imsic_deinit,
@@ -33,6 +109,7 @@ int domain_vaplic_init(struct domain *d)
 
     d->arch.vintc = &vaplic->vintc;
     d->arch.vintc->ops = &vintc_ops;
+    d->arch.vintc->init_ops = &init_ops;
 
     vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO;
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400833.1636493 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtP-00077P-Mh; Thu, 27 Aug 2026 15:19:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400833.1636493; Thu, 27 Aug 2026 15:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtP-00075c-6z; Thu, 27 Aug 2026 15:19:51 +0000
Received: by outflank-mailman (input) for mailman id 1400833;
 Thu, 27 Aug 2026 15:19:49 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtM-0006dH-UE
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtM-00FhnD-Ah
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:48 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90556a-e002-0a2a0a5209dd-0a2a450c921e-48
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:48 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905594-f479-0a2a450c0019-d155dd35d561-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:48 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-482f2ee53e7so478346f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843988; x=1788448788; 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=auwlONTyxTOBPZaUQysQymvU52k1SzRzbMffDDOn8E8=;
        b=pFhRDQXyjxrw7AFD3KUkEyQdohkoTLKM1pF7M6x0ot7RtRGfFI8lkoNhUiysogiGI5
         PcA+Q+V2DuyNuDCKZ3MNiPmiceXgATrCLLXWTQTsFsL/wgPPGBufi2HIsDch+m7/8G3z
         pOfvp2n763men2z1BKvTMuwxJjyVA6FpJWETLnkWxN88fYUJYjMdQhUO5i0SArmz5Noo
         Ow8TvBD98G6sAvBRVmHMJ/QNFDfCkmdAKMUhmTiR2eu6hKzuBjAu4hUAauGGJXFc8B8n
         JYn1Vg6Y64sSH4Botma2WsL3RhuuEi1l/CzHbmV30apOdL2ZTVLoXJ7rOlY9545Ja6lM
         b6/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843988; x=1788448788;
        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=auwlONTyxTOBPZaUQysQymvU52k1SzRzbMffDDOn8E8=;
        b=TGZyoNhLRFNUqAG+A1keRMdduO/ElkDhTSYPME5/lhe8C4gXSoruw/skjW5ZRgVuZx
         zcbRt+fjasq7SDz29dUT/+C26rs/oQVd4UzEILjNlQi1R7vbe5q5Bo+px33yZVlE994x
         GOevPU3hCHAvIyqLD517AyJ2jyp8D+KQnKvKd275A8QU8ag1V/Wye8jA6JXGrMuspUWB
         66txqwXmqBikYU/kgvUDk5+a8IheOmJ1EKk5LpXFmnddjMCTKGmG3P1eKIAlwEXpFyy7
         Dmegt5W28x5cS8/jKn+MCo1WAXa4KUoLtAdLb6VRl2V6QC2e/I70+RDijFnx3RmJBUDI
         dQkw==
X-Gm-Message-State: AFuF++nRhAEPhBsj8tCH8TniF5s5/L3L9f5QqH8vABxxRgu1SM0ev3F1
	KDy2P36mC2Nm6J8BUyQC1InxBq88bQVJNRGsZRopdxLZDoj0Rx5OglaYX2J5DA==
X-Gm-Gg: AR+sD13n3BZycSox/GZjoCR226c/pLUCZZhhTU7I75wuAR26tbdvoZuPXZqY3uvEpcq
	SZHmLfPF7VP7M/QHWwRwcrpcO/1Oqab2xzKuswqFwfFetdPewqdGEh5JEyrUm9wiG+Rcstq1kGw
	fB2Px+xh4Ugt5mlPP1mYvk2fPZjl06RfkSOeihTb2R0keldhKfL90YgSnxO3jXeVwwgnQzLhPkI
	BuQbCXICEac/xYTtYybr5LJxly8W5VwAmo7w02ZtEnpzOvf5SPWtSnCpoWJyfupQoDZmXnKX7p/
	kqLulnLdrNIUpYLcss+G2xr0nQ0spBF7BGnMh+bitMpbsvGTU5tHVfRc4alhvtb9eFRpxJGLm38
	Vop2LPDkenZQYP6VDZ4vMw6hUxNR0PdqcSG/BRQx6iBQ/IRsEXfUZ25bDOXcnELhD658+06qNit
	In+XgQYiWMuW+aD46gwmt0e5yfisiDZ/5iSQH/zvpGWvEvo7azM0nH61x/wAAbPo3LRKj/8KryU
	/5NOXlYshw9t9E1mA9j7ndAdkJSUwBAfbL8CFi4Byw=
X-Received: by 2002:a05:6000:4698:b0:482:dbe5:d124 with SMTP id ffacd0b85a97d-482e26f04c5mr17284334f8f.19.1787843987432;
        Thu, 27 Aug 2026 08:19:47 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: [PATCH v8 16/20] xen/riscv: implement IRQ routing for device passthrough
Date: Thu, 27 Aug 2026 17:19:09 +0200
Message-ID: <d5ac0f45de409ab0a63b2b17e4fd3cdd47dbffa0.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787843988-028DDA5B-5AC857AA/10/73395122804
X-purgate-type: spam
X-purgate-size: 28211

dom0less device passthrough requires granting guest domains access to
device interrupts.  Introduce map_device_irqs_to_domain() to enumerate
a DT node's interrupt properties, skipping those not owned by
the primary interrupt controller (as at the moment I haven't seen usages
of it), and map_irq_to_domain() to grant domain access and configure
Xen's interrupt descriptor accordingly. Sharing IRQ between domains is
rejected.

Both map_irq_to_domain() and map_device_irqs_to_domain() are marked
__overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to
__init, so the functions are init-only and need no XSM check; with
CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime
entry point is dt_overlay_domctl(), which performs the XSM checks at the
domctl layer.  RISC-V does not wire up DT overlay yet, so today these are
strictly __init; if/when overlay support is added, the domctl-level XSM
gating must be added together with it, as on Arm.

route_irq_to_guest() and release_irq() manage irq_desc ownership for
guest-assigned interrupts.  Each assignment carries a small irq_guest
structure as irqaction::dev_id, recording the owning domain and virtual
IRQ number which is 1:1 mapped to physical IRQ number.  A per-domain
vIRQ allocation bitmap (used_irqs in struct vintc), managed by
vintc_reserve_virq(), prevents the same vIRQ being claimed twice.

Host and guest interrupts may differ in some operations (EOI timing in
particular, possibly others): a host IRQ is completed once Xen's handler
runs, whereas a passthrough IRQ must defer the physical completion until
the guest issues its own EOI, otherwise a still-asserted level line would
immediately retrigger and storm.  This affects only the .end callback;
the rest of hw_interrupt_type is shared, hence the separate host and
guest hw_interrupt_type instances.

With APLIC+IMSIC, guest interrupts are delivered directly by hardware
through the IMSIC, bypassing do_IRQ(). The _IRQ_GUEST branch in
do_IRQ() is therefore left as BUG() until a platform without direct
IMSIC delivery is encountered.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
Changes in v8:
 - vintc_reserve_virq(): return an error code instead of a bool: 0 on
   success, -EEXIST when the vIRQ has already been reserved (which
   legitimately happens for an IRQ shared between devices) and -ERANGE
   when the vIRQ is outside the range the vINTC provides. Document the
   function and its return values.
 - vintc_reserve_virq(): mark it __overlay_init, as its only caller
   map_irq_to_domain() is __overlay_init too. Add the <xen/dt-overlay.h>
   and <xen/errno.h> includes this needs.
 - map_irq_to_domain(): check the return value of vintc_reserve_virq()
   and propagate anything but -EEXIST. Otherwise the IRQ would end up
   routed to the domain without domain_vintc_deinit() ever releasing it
   again. Update the stale comment accordingly.
 - domain_vintc_deinit(): only walk used_irqs and free it if it has
   actually been allocated. domain_vintc_init() can fail after the vINTC
   itself has been allocated, leaving used_irqs NULL.
 - irq.c: split the body of release_irq() into two helpers:
   irq_detach_action(), which removes the action matching dev_id from
   desc->action with desc->lock held, and irq_release_action(), which
   waits for a handler still running on another CPU and frees the action
   with desc->lock dropped. Both document the locking rules they rely on.
   release_irq() is now just a wrapper around the two.
 - release_guest_irq(): use irq_detach_action()/irq_release_action()
   instead of open-coding __clear_bit(_IRQ_GUEST, ...) followed by
   release_irq(), which looked the action up by dev_id a second time.
 - release_guest_irq(): drop the -EBUSY restriction that only allowed
   unrouting from a dying domain. Detaching the action under desc->lock
   now closes the window this was working around.
 - route_irq_to_guest(): on the intc_route_irq_to_guest() failure path,
   detach the action while desc->lock is still held and only release it
   after the lock has been dropped, instead of dropping the lock first
   and calling release_irq().
 - route_irq_to_guest(): initialise desc at its declaration.
 - irq_get_guest_info(): use ASSERT(desc->action) instead of
   ASSERT(desc->action != NULL).
---
Changes in v7:
 - Build device.c as device.init.o: everything it provides is
   __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB
   stays Arm-only.  Unlike Arm, which picks device.o/device.init.o based
   on that config, RISC-V cannot enable it, so the choice is
   unconditional for now.
 - Don't have release_irq() free the guest IRQ info anymore: set
   free_on_release = false and free 'info' explicitly in
   release_guest_irq(), i.e. reinstate the xvfree() dropped in v5. The
   action stays embedded in struct irq_guest, so a single allocation
   still covers both, but it no longer has to be the structure's first
   member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer
   that merely happened to coincide with the allocation base are gone.
   The ->dev_id concern from v5 doesn't apply: release_irq() clears
   desc->action under desc->lock and waits for in-flight handling before
   returning, so nothing can observe ->dev_id once 'info' is freed.
 - Move 'action' to the end of struct irq_guest and reword its comment
   accordingly.
 - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that
   the embedded action is fully initialized (action.handler was left
   uninitialized before).
 - route_irq_to_guest(): free 'info' via the common free_info label when
   intc_route_irq_to_guest() fails, now that release_irq() no longer
   frees it.
 - Drop a stray blank line ahead of release_irq().
---
Changes in v6:
 - size nr_virqs as guest_aplic_num_sources + 1 to reserve APLIC's 1-indexed
   source 0, so the highest source/irq could be reserved.
---
Changes in v5:
 - add early -EINVAL return in route_irq_to_guest() if domain is dying
 - use __clear_bit() instead of clear_bit() in release_guest_irq()
   since desc->lock is already held
 - remove irq_get_domain() wrapper; inline irq_get_guest_info(desc)->d
    at its single call site
 - reword IRQ_GUEST comment in do_IRQ() for clarity
 - move XVFREE(used_irqs) before the switch so it is freed prior to
   variant-specific vintc teardown
 - fix missing space in dt_dprintk() format string split across lines
 - Drop 'inline' for irq_get_guest_info() and leave it only static.
 - Drop xfree(info) from release_guest_irq() to avoid a potential
   dangling-pointer issue with the ->dev_id field. Now that
   'struct irqaction action;' is embedded into 'struct irq_guest',
   'info' will be freed as part of release_irq() at the end.
---
Changes in v4:
 - Update the commit message.
 - Mark map_irq_to_domain() and map_device_irqs_to_domain() as
   __overlay_init (mirroring Arm) and include <xen/dt-overlay.h>.
 - Fix grammar in the controller-skip comment ("IRQ" -> "IRQs").
 - Drop the redundant 'base' local in guest_imsic_make_reg_property();
   use GUEST_IMSIC_S_BASE directly.
 - Rename vintc::irq_nums -> nr_virqs and update all users.
 - Guard domain_vintc_deinit() against a NULL d->arch.vintc.
 - Use smp_rmb() instead of smp_mb() in release_irq()'s wait loop and
   document how it pairs with the spin_unlock() in do_IRQ().
 - In release_guest_irq(), reject live unrouting from a non-dying domain
   (-EBUSY) and clear _IRQ_GUEST under desc->lock so a concurrent
   release for the same IRQ bails out instead of double-freeing 'info'.
 - Tidy spurious whitespace in release_irq()'s spin_lock/unlock calls.
---
Changes in v3:
 - Drop extraneous "to" from "Unable to permit to %pd" message.
 - Move res/irq/rirq to loop scope; use nirq as declaration initializer.
 - Hoist irq_ranges check before the loop (it is loop-invariant).
 - Remove spurious forward declarations (struct dt_device_node, struct
   rangeset) from intc.h; remove all three from setup.h.
 - Use __set_bit() instead of set_bit() in intc_route_irq_to_guest()
   since desc->lock is always held on every write path for desc->status.
 - Use XVFREE() instead of xvfree() in domain_vintc_deinit().
 - Rename allocated_irqs -> used_irqs in struct vintc.
 - Fix dangling desc->action in release_irq()'s !IRQ_HAS_MULTIPLE_ACTION
   path by nulling *action_ptr after saving the action pointer.
 - Use true (not 1) for free_on_release in route_irq_to_guest().
 - Use %pd for domain printing in route_irq_to_guest() error paths.
 - Introduce release_guest_irq() to pair with route_irq_to_guest() and
   plug the irq_guest info leak; call it from domain_vintc_deinit()
   for each vIRQ recorded in used_irqs.
---
Changes in v2:
 - Rework IRQ mapping in more common (similar approach to Arm).
---

1

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

2: refactorign freeing

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

last fix

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 xen/arch/riscv/Makefile           |   1 +
 xen/arch/riscv/aplic.c            |   4 +
 xen/arch/riscv/device.c           | 100 ++++++++++++
 xen/arch/riscv/include/asm/intc.h |   9 ++
 xen/arch/riscv/include/asm/irq.h  |   5 +
 xen/arch/riscv/intc.c             |  60 +++++++
 xen/arch/riscv/irq.c              | 255 ++++++++++++++++++++++++++++++
 xen/arch/riscv/vaplic.c           |   9 ++
 8 files changed, 443 insertions(+)
 create mode 100644 xen/arch/riscv/device.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index fcd73c7a2dd5..3b948c11dd61 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,6 +1,7 @@
 obj-y += aia.o
 obj-y += aplic.o
 obj-y += cpufeature.o
+obj-y += device.init.o
 obj-y += domain.o
 obj-y += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c
index c2d7183e1852..3681f0669efb 100644
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -325,9 +325,13 @@ static const hw_irq_controller aplic_xen_irq_type = {
     .set_affinity = aplic_set_irq_affinity,
 };
 
+/* At the moment there is no difference between guest and Xen ops */
+#define aplic_guest_irq_type aplic_xen_irq_type
+
 static const struct intc_hw_operations aplic_ops = {
     .info                = &aplic_info,
     .host_irq_type       = &aplic_xen_irq_type,
+    .guest_irq_type      = &aplic_guest_irq_type,
     .handle_interrupt    = aplic_handle_interrupt,
     .set_irq_type        = aplic_set_irq_type,
 };
diff --git a/xen/arch/riscv/device.c b/xen/arch/riscv/device.c
new file mode 100644
index 000000000000..fc41c075c772
--- /dev/null
+++ b/xen/arch/riscv/device.c
@@ -0,0 +1,100 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include <xen/device_tree.h>
+#include <xen/dt-overlay.h>
+#include <xen/errno.h>
+#include <xen/iocap.h>
+#include <xen/rangeset.h>
+#include <xen/sched.h>
+
+#include <asm/intc.h>
+
+int __overlay_init map_irq_to_domain(struct domain *d, unsigned int irq,
+                                     bool need_mapping, const char *devname)
+{
+    int res;
+
+    res = irq_permit_access(d, irq);
+    if ( res )
+    {
+        printk(XENLOG_ERR "Unable to permit %pd access to IRQ %u\n", d, irq);
+        return res;
+    }
+
+    if ( need_mapping )
+    {
+        /*
+         * -EEXIST merely means that the IRQ has already been reserved, which
+         * legitimately happens when the IRQ is shared between devices. Any
+         * other failure has to be fatal: the IRQ would otherwise be routed to
+         * the domain without domain_vintc_deinit() ever releasing it again.
+         */
+        res = vintc_reserve_virq(d, irq);
+        if ( res && (res != -EEXIST) )
+        {
+            printk(XENLOG_ERR "Unable to reserve vIRQ %u for %pd\n", irq, d);
+            return res;
+        }
+
+        res = route_irq_to_guest(d, irq, irq, devname);
+        if ( res < 0 )
+        {
+            printk(XENLOG_ERR "Unable to map IRQ%u to %pd\n", irq, d);
+            return res;
+        }
+    }
+
+    dt_dprintk("  - IRQ: %u\n", irq);
+
+    return 0;
+}
+
+int __overlay_init map_device_irqs_to_domain(struct domain *d,
+                                             struct dt_device_node *dev,
+                                             bool need_mapping,
+                                             struct rangeset *irq_ranges)
+{
+    unsigned int i, nirq = dt_number_of_irq(dev);
+
+    if ( irq_ranges )
+        return -EOPNOTSUPP;
+
+    /* Give permission and map IRQs */
+    for ( i = 0; i < nirq; i++ )
+    {
+        int res, irq;
+        struct dt_raw_irq rirq;
+
+        res = dt_device_get_raw_irq(dev, i, &rirq);
+        if ( res )
+        {
+            printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n",
+                   i, dt_node_full_name(dev));
+            return res;
+        }
+
+        /*
+         * Don't map IRQs that have no physical meaning
+         * ie: IRQs whose controller is not APLIC/IMSIC/PLIC.
+         */
+        if ( rirq.controller != dt_interrupt_controller )
+        {
+            dt_dprintk("irq %u not connected to primary controller. Connected to %s\n",
+                       i, dt_node_full_name(rirq.controller));
+            continue;
+        }
+
+        irq = platform_get_irq(dev, i);
+        if ( irq < 0 )
+        {
+            printk("Unable to get irq %u for %s\n", i, dt_node_full_name(dev));
+            return irq;
+        }
+
+        res = map_irq_to_domain(d, irq, need_mapping, dt_node_name(dev));
+        if ( res )
+            return res;
+    }
+
+    return 0;
+}
diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h
index 6fc0e620e937..1bfba7c6155b 100644
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -15,6 +15,7 @@ enum intc_variant {
 };
 
 struct cpu_user_regs;
+struct domain;
 struct irq_desc;
 struct kernel_info;
 struct vcpu;
@@ -34,6 +35,9 @@ struct intc_hw_operations {
     /* hw_irq_controller to enable/disable/eoi host irq */
     const struct hw_interrupt_type *host_irq_type;
 
+    /* hw_irq_controller to enable/disable/eoi guest irq */
+    const struct hw_interrupt_type *guest_irq_type;
+
     /* Set IRQ type */
     void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
     /* Set IRQ priority */
@@ -63,6 +67,8 @@ struct vintc_ops {
 };
 
 struct vintc {
+    unsigned int nr_virqs;
+    unsigned long *used_irqs;
     /* Callbacks invoked during domain construction only. */
     const struct vintc_init_ops *init_ops;
     /* Runtime callbacks used for the lifetime of the guest. */
@@ -76,10 +82,13 @@ void register_intc_ops(const struct intc_hw_init_ops *init_ops);
 void intc_init(void);
 
 void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
+int intc_route_irq_to_guest(struct irq_desc *desc, unsigned int priority);
 
 void intc_handle_external_irqs(struct cpu_user_regs *regs);
 
 int domain_vintc_init(struct domain *d);
 void domain_vintc_deinit(struct domain *d);
 
+int vintc_reserve_virq(const struct domain *d, unsigned int virq);
+
 #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */
diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h
index 62648bdc4252..66067747dc0f 100644
--- a/xen/arch/riscv/include/asm/irq.h
+++ b/xen/arch/riscv/include/asm/irq.h
@@ -52,6 +52,11 @@ void init_IRQ(void);
 
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq);
 
+int route_irq_to_guest(struct domain *d, unsigned int virq,
+                       unsigned int irq, const char *devname);
+
+int release_guest_irq(struct domain *d, unsigned int virq);
+
 #endif /* ASM__RISCV__IRQ_H */
 
 /*
diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c
index f5c8af6ddea4..bca83b4f4fa3 100644
--- a/xen/arch/riscv/intc.c
+++ b/xen/arch/riscv/intc.c
@@ -3,11 +3,15 @@
 #include <xen/acpi.h>
 #include <xen/bug.h>
 #include <xen/device_tree.h>
+#include <xen/dt-overlay.h>
+#include <xen/errno.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/lib.h>
+#include <xen/sched.h>
 #include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
 
 #include <asm/aia.h>
 #include <asm/intc.h>
@@ -78,6 +82,22 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
     intc_set_irq_priority(desc, priority);
 }
 
+int intc_route_irq_to_guest(struct irq_desc *desc,
+                            unsigned int priority)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+
+    ASSERT(intc_hw_ops->guest_irq_type);
+
+    desc->handler = intc_hw_ops->guest_irq_type;
+    __set_bit(_IRQ_GUEST, &desc->status);
+
+    intc_set_irq_type(desc, desc->arch.type);
+    intc_set_irq_priority(desc, priority);
+
+    return 0;
+}
+
 int __init make_intc_domU_node(struct kernel_info *kinfo)
 {
     const struct vintc *vintc = kinfo->bd.d->arch.vintc;
@@ -101,6 +121,15 @@ int domain_vintc_init(struct domain *d)
         break;
     }
 
+    if ( !ret )
+    {
+        d->arch.vintc->used_irqs =
+            xvzalloc_array(unsigned long,
+                           BITS_TO_LONGS(d->arch.vintc->nr_virqs));
+        if ( !d->arch.vintc->used_irqs )
+            ret = -ENOMEM;
+    }
+
     return ret;
 }
 
@@ -108,6 +137,20 @@ void domain_vintc_deinit(struct domain *d)
 {
     const enum intc_variant variant = intc_hw_ops->info->hw_variant;
 
+    if ( !d->arch.vintc )
+        return;
+
+    if ( d->arch.vintc->used_irqs )
+    {
+        unsigned int virq;
+
+        for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ )
+            if ( test_bit(virq, d->arch.vintc->used_irqs) )
+                release_guest_irq(d, virq);
+
+        XVFREE(d->arch.vintc->used_irqs);
+    }
+
     switch ( variant )
     {
     case INTC_APLIC:
@@ -118,3 +161,20 @@ void domain_vintc_deinit(struct domain *d)
         break;
     }
 }
+
+/*
+ * Mark @virq as used by @d so that domain_vintc_deinit() knows that it has to
+ * be released.
+ *
+ * Returns 0 on success, -EEXIST if @virq has already been reserved, which
+ * legitimately happens when an IRQ is shared between devices, and -ERANGE if
+ * @virq is outside the range of the interrupt sources the vINTC provides.
+ */
+int __overlay_init vintc_reserve_virq(const struct domain *d,
+                                      unsigned int virq)
+{
+    if ( virq >= d->arch.vintc->nr_virqs )
+        return -ERANGE;
+
+    return test_and_set_bit(virq, d->arch.vintc->used_irqs) ? -EEXIST : 0;
+}
diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c
index b5066fc3e981..4ba45fc79df2 100644
--- a/xen/arch/riscv/irq.c
+++ b/xen/arch/riscv/irq.c
@@ -12,11 +12,26 @@
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/irq.h>
+#include <xen/sched.h>
 #include <xen/spinlock.h>
+#include <xen/xvmalloc.h>
 
 #include <asm/hardirq.h>
 #include <asm/intc.h>
 
+/* Describe an IRQ assigned to a guest */
+struct irq_guest
+{
+    struct domain *d;
+    unsigned int virq;
+    /*
+     * The action of a guest IRQ has the same lifetime as this structure, so
+     * embed it here to have both covered by a single allocation. Consequently
+     * it must not be freed by release_irq() (see free_on_release below).
+     */
+    struct irqaction action;
+};
+
 static irq_desc_t irq_desc[NR_IRQS];
 
 struct irq_desc *irq_to_desc(unsigned int irq)
@@ -198,6 +213,14 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
     if ( desc->handler->ack )
         desc->handler->ack(desc);
 
+    if ( desc->status & IRQ_GUEST )
+        /*
+         * With APLIC + IMSIC, guest interrupts bypass Xen and are delivered
+         * directly to the guest. Without IMSIC, interrupts would be trapped
+         * by Xen and would need injecting into the guest here.
+         */
+        panic("unimplemented");
+
     if ( desc->status & IRQ_DISABLED )
         goto out;
 
@@ -227,3 +250,235 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq)
     spin_unlock(&desc->lock);
     irq_exit();
 }
+
+static struct irq_guest *irq_get_guest_info(struct irq_desc *desc)
+{
+    ASSERT(spin_is_locked(&desc->lock));
+    ASSERT(test_bit(_IRQ_GUEST, &desc->status));
+    ASSERT(desc->action);
+
+    return desc->action->dev_id;
+}
+
+/*
+ * Detach the action registered with 'dev_id' from 'desc' and, if it was the
+ * last one, shut the interrupt down.
+ *
+ * To be called with desc->lock held, which is still held upon return. The
+ * detached action is returned (NULL if 'dev_id' had no action registered) and
+ * has to be handed to irq_release_action() once the lock has been dropped.
+ */
+static struct irqaction *irq_detach_action(struct irq_desc *desc,
+                                           const void *dev_id)
+{
+    struct irqaction *action, **action_ptr = &desc->action;
+
+    ASSERT(spin_is_locked(&desc->lock));
+
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    for ( ;; )
+    {
+        action = *action_ptr;
+        if ( !action || (action->dev_id == dev_id) )
+            break;
+
+        action_ptr = &action->next;
+    }
+#else
+    action = *action_ptr;
+#endif
+
+    if ( !action )
+    {
+        printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n",
+               desc->irq);
+        return NULL;
+    }
+
+    /* Found it - remove it from the action list */
+#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION
+    *action_ptr = action->next;
+#else
+    *action_ptr = NULL;
+#endif
+
+    /* If this was the last action, shut down the IRQ */
+    if ( !desc->action )
+    {
+        desc->handler->shutdown(desc);
+        __clear_bit(_IRQ_GUEST, &desc->status);
+    }
+
+    return action;
+}
+
+/*
+ * Complete the release of an action detached by irq_detach_action().
+ *
+ * To be called with desc->lock dropped: the lock cannot be held all the way
+ * through, as waiting for a handler still running on another CPU to complete
+ * requires do_IRQ() to be able to acquire the very same lock.
+ *
+ * Once this function has returned, the action (and hence any object embedding
+ * it) is no longer referenced by anyone and may be freed by the caller.
+ */
+static void irq_release_action(const struct irq_desc *desc,
+                               struct irqaction *action)
+{
+    /*
+     * Wait to make sure it's not being used on another CPU.
+     *
+     * The read barrier pairs with the spin_unlock() in do_IRQ(): once we
+     * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the
+     * writes do_IRQ() made to desc (e.g. desc->action) before releasing the
+     * lock, so it is safe to free the action below.
+     */
+    do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) );
+
+    if ( action->free_on_release )
+        xvfree(action);
+}
+
+void release_irq(unsigned int irq, const void *dev_id)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    struct irqaction *action;
+    unsigned long flags;
+
+    spin_lock_irqsave(&desc->lock, flags);
+    action = irq_detach_action(desc, dev_id);
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    if ( action )
+        irq_release_action(desc, action);
+}
+
+int release_guest_irq(struct domain *d, unsigned int virq)
+{
+    struct irq_desc *desc = irq_to_desc(virq);
+    struct irqaction *action;
+    struct irq_guest *info;
+    unsigned long flags;
+    int ret = -EINVAL;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    if ( !test_bit(_IRQ_GUEST, &desc->status) )
+        goto unlock_err;
+
+    info = irq_get_guest_info(desc);
+    if ( d != info->d )
+        goto unlock_err;
+
+    /*
+     * Detaching the action happens with desc->lock still held, so that a
+     * concurrent release_guest_irq() for the same IRQ sees _IRQ_GUEST already
+     * cleared and bails out, rather than capturing the same 'info' and
+     * double-freeing it below.
+     */
+    action = irq_detach_action(desc, info);
+
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    if ( action )
+        irq_release_action(desc, action);
+
+    xvfree(info);
+
+    return 0;
+
+ unlock_err:
+    spin_unlock_irqrestore(&desc->lock, flags);
+    return ret;
+}
+
+/* Route an IRQ to a specific guest */
+int route_irq_to_guest(struct domain *d, unsigned int virq,
+                       unsigned int irq, const char *devname)
+{
+    struct irq_guest *info;
+    struct irq_desc *desc = irq_to_desc(irq);
+    unsigned long flags;
+    int retval = 0;
+
+    if ( d->is_dying )
+        return -EINVAL;
+
+    info = xvzalloc(struct irq_guest);
+    if ( !info )
+        return -ENOMEM;
+
+    info->d = d;
+    info->virq = virq;
+
+    info->action.dev_id = info;
+    info->action.name = devname;
+    /* The action is part of 'info', thus it is freed together with it. */
+    info->action.free_on_release = false;
+
+    spin_lock_irqsave(&desc->lock, flags);
+
+    /*
+     * If the IRQ is already used by someone
+     *  - If it's the same domain -> Xen doesn't need to update the IRQ desc.
+     *  For safety check if we are not trying to assign the IRQ to a
+     *  different vIRQ.
+     *  - Otherwise -> For now, don't allow the IRQ to be shared between
+     *  Xen and domains.
+     */
+    if ( desc->action != NULL )
+    {
+        if ( test_bit(_IRQ_GUEST, &desc->status) )
+        {
+            struct domain *ad = irq_get_guest_info(desc)->d;
+
+            if ( d != ad )
+            {
+                printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n",
+                       irq, ad);
+                retval = -EBUSY;
+            }
+            else if ( irq_get_guest_info(desc)->virq != virq )
+            {
+                printk(XENLOG_G_ERR
+                       "%pd: IRQ %u is already assigned to vIRQ %u\n",
+                       d, irq, irq_get_guest_info(desc)->virq);
+                retval = -EBUSY;
+            }
+        }
+        else
+        {
+            printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
+            retval = -EBUSY;
+        }
+        goto out;
+    }
+
+    retval = _setup_irq(desc, 0, &info->action);
+    if ( retval )
+        goto out;
+
+    retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY);
+    if ( retval )
+    {
+        struct irqaction *action = irq_detach_action(desc, info);
+
+        spin_unlock_irqrestore(&desc->lock, flags);
+
+        if ( action )
+            irq_release_action(desc, action);
+
+        goto free_info;
+    }
+
+    spin_unlock_irqrestore(&desc->lock, flags);
+
+    return 0;
+
+ out:
+    spin_unlock_irqrestore(&desc->lock, flags);
+ free_info:
+    xvfree(info);
+
+    return retval;
+}
diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c
index a529a5b1dc49..14f6e3164a9b 100644
--- a/xen/arch/riscv/vaplic.c
+++ b/xen/arch/riscv/vaplic.c
@@ -113,6 +113,15 @@ int domain_vaplic_init(struct domain *d)
 
     vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO;
 
+    /*
+     * APLIC source 0 is reserved; sources are numbered 1..guest_aplic_num_sources
+     * and used directly as indices into used_irqs. Size the bitmap to
+     * guest_aplic_num_sources + 1 so the highest source has a valid slot
+     * (index 0 stays unused). Without the +1, vintc_reserve_virq() can't record
+     * the top source, so domain_vintc_deinit() never releases it.
+     */
+    d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1;
+
     return 0;
 }
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400834.1636499 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtR-0007F1-A0; Thu, 27 Aug 2026 15:19:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400834.1636499; Thu, 27 Aug 2026 15:19:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtQ-0007Cf-6c; Thu, 27 Aug 2026 15:19:52 +0000
Received: by outflank-mailman (input) for mailman id 1400834;
 Thu, 27 Aug 2026 15:19:50 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtO-0006ly-1X
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtN-004jWw-DX
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:49 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a90558a-bab6-0a2a0a5309dd-0a2a4509ad32-36
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:49 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905595-be1a-0a2a45090019-d155dd2bb9ec-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:49 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-47f84023916so784392f8f.3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843989; x=1788448789; 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=hspl5jZCbYhpDCmk3LQL2TUMtm9DwE0NtljqNNHKmy8=;
        b=PX/afli83Fs28nOZ3KzNexiHUhSmrv+2vhJrRHCMy5aS+EA5Shc44C3Z2a/S1Nxq0a
         VO4f94RMG+9vclW0vRzD+zi9yaDwLT/rgUhBcwf32J7jqZmvaON4elnRKIhhAS3jHSEe
         PKTseGT81oxEwc3nV7AfGLVvkQICnMbvcf/axESrei+Uvl1yrVfFkUnGi4Zvm14evNQD
         XkQu8lw4F73HV/ivZFym3JdKglAjTSsBFI0mujaQyavT/3vMVd+MO8QT5GrTfxdTpcgt
         OTD8EyZJSF+i9JBzynOSEilDdojzCi4uNDm4d/RddjBKx7NMJaJ+t3arJdLJJg2PKV0V
         hy6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843989; x=1788448789;
        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=hspl5jZCbYhpDCmk3LQL2TUMtm9DwE0NtljqNNHKmy8=;
        b=rppqpCsHqwEpxxrSDO6vH7Vix98RPMlKD6vDEDYzoxJMpMTrwqzgxPn6pYdpJwaHhO
         kg/s/7yGNdzae3ONNqo8nA6DvmYVC1ZwSH2pgZcDOG2osiWdReka/let7oXQBXOqAEal
         ZxIX1qF8kJ8W9IuHrApqBuF6RrS3lGsxbvrC0Aj6OODetCVpEi5Tk7R2IRTr6bDp5fq4
         IAqDCd//0scDL99RcoN/K90+r6jJhSN/flyDkHAry/sFVKgnYwxRrVGNWKdJ6hZJjoJl
         FX+vfl0+e732DJYbCWoeSeTOCQ+YXlviTNfYjVWx5yJSA68+xBP9oeS+1mWtjfXE7Zc9
         9yVw==
X-Gm-Message-State: AFuF++m245Y9f5CBW4gOzjKF7QCvp5yYpbelTa9rY3QcDg/CEVzcGwFp
	6bIfvve7nGLPXfKBMcyIuKtSh4iwMpFopemVXkFdlbYpFS66/mjzOs36iWQJcg==
X-Gm-Gg: AR+sD13yyLigdU5rX6WMufrnpEc/sgdl6CNkEZMcOS0ons7dKpPHYlUHO3lBGla5zkc
	1LY6VTlFB0+0G88TfScWLzWlr/qVmJ3lTt07TCsn564NRsvcKjGYbnloMt+2dUTa2hyzMNRo8/h
	Odw1FOQyKZA3lYnfYex+TR88OBsU3L/03vhURCrm96Kbwd7ZoXjbmzK9RSG/OnV5/MTV6S4JpRD
	PfGUc7/GpPyVzAdebuYnvuDJnfuiTyrDKX6uBjXn9/UnSvH/4Ia2k3V63swhJkx08+suswRuLvo
	NhVV61nQkh2iWS37Wu5lBGU8IJaD/n6FOk5XLAEi09CmRcaj0RZq+krZiXoJv1Feu5xWx8AOy79
	ZankA4dN5cYUkV/J8x9ITacMer4G51OVVMhM2h1/cJLV9oh1FhL6J7aF5DCMRHpRYW0AUGn1mcT
	ikFXHqlr3+I3zhaT0HqwznoG9cO9OkL6wOUJTCnMc1vVogH8bQMYUfTuPF7fdlxoC+vSLzemPrn
	39TLXixw03XdyzSj49Wity55JvMQ2LH
X-Received: by 2002:a5d:4cc9:0:b0:482:a9d7:7ced with SMTP id ffacd0b85a97d-482e26f2d68mr18663653f8f.14.1787843988781;
        Thu, 27 Aug 2026 08:19:48 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 17/20] xen/riscv: implement init_intc_phandle()
Date: Thu, 27 Aug 2026 17:19:10 +0200
Message-ID: <f155a2aac8a99f4446d2542ad4550b1bf52d2b86.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787843989-FC610034-D4EE1F8E/10/73395122804
X-purgate-type: spam
X-purgate-size: 1378

Implement init_intc_phandle() to read phandle of interrupt controller
node and save it in kernel->phandle_intc for the future usage during
creation of guest interrupt controller node.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v4-8:
 - Nothing changed. Only rebase.
---
---
 xen/arch/riscv/dom0less-build.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index 4cc00012aa8d..a1fa51b996a7 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -4,9 +4,26 @@
 #include <xen/device_tree.h>
 #include <xen/fdt-kernel.h>
 #include <xen/init.h>
+#include <xen/libfdt/libfdt.h>
 
 #include <asm/p2m.h>
 
+int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
+                             const int node_next, const void *pfdt)
+{
+    if ( dt_node_cmp(name, "intc") == 0 )
+    {
+        uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next);
+
+        if ( phandle_intc != 0 )
+            kinfo->phandle_intc = phandle_intc;
+
+        return 0;
+    }
+
+    return 1;
+}
+
 int __init make_arch_nodes(struct kernel_info *kinfo)
 {
     /* No RISC-V specific nodes need to be made, at the moment. */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400837.1636503 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtS-0007Sb-T3; Thu, 27 Aug 2026 15:19:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400837.1636503; Thu, 27 Aug 2026 15:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtR-0007PM-Tp; Thu, 27 Aug 2026 15:19:53 +0000
Received: by outflank-mailman (input) for mailman id 1400837;
 Thu, 27 Aug 2026 15:19:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtP-000768-DL
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtO-00C6oU-QH
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:50 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905594-2eae-0a2a0a5409dd-0a2a450cba40-8
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:50 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905596-f479-0a2a450c0019-d155dd2bac24-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:50 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-482e5733a5aso1155300f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843990; x=1788448790; 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=A7l2D0jJWYC9jU2joRLXLdGgfpd427nTKM3O84md/I4=;
        b=drivmp/ge10y9xap7MmClKe/wBxJrCuoU8ewyU6qrKdppnWNx6UGimrLsByuVtWyNm
         Lou87WuAKUPIHgKLMHg/gbr99BZGWYSzsNlNjTbWYxcK9761UH8uNYpRGw7pyA6CoU2u
         N1bI9cxeeQU0c9Jh6/tN5BJ46mdG9ddC/6GxW/X4kuNyjm3sy6mbpfEHKD3dJ8lrGRdU
         ZkQtOTGr1IUPbta8Rwgq57O/DxDCXDvDXneOKWzNF/1bLvc4ZgjGBbQ2TluLyxH0is66
         Rgqdq80ASMyiOBWRFnzCkdCGjDDKgL0r6tUC6WaexKA21KV/cFU2hzqyhfhOdV6wzvRw
         hT1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843990; x=1788448790;
        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=A7l2D0jJWYC9jU2joRLXLdGgfpd427nTKM3O84md/I4=;
        b=PZGsgJEdneiVJCxyBeFXNh5c0/Raue6t8bmb+FqEeYsRWgLKH3u7TntfIacEe4fDnM
         kjqB4FVbcP/84/MbNVDViW8+SI9ZEiMjr0wla83Xlv1pNo5NiMsb8wAdhrplsqTnoU+I
         c9BHAHuIiWqknPeR9ZrcdM0vfTMiNXfYmZP47LwAtxwn6zj6qe/ADE9yy8xdefiei+pL
         XtjnFXoqMYkMWKes1phI2lUZ0hn6/0Qvzl72ZU6Qjz9ZN4RBAtlQIGULfDU9/hHV4Fps
         HeumiBWrBIFZF1MQrNCffsIE1W2rKPr2iE120WPyh/QdlPkDI46aWSKa6uv+y04g+0P2
         Niyg==
X-Gm-Message-State: AFuF++kAlAYkvqhYeyadlAjt4nCe1c4DgHXQYKMPl5CtzeuJJ1bLJR7m
	3e07fP2ii34ROImtgff4cdG6em3WnliYJKfdQfxfMDvRV6sQE8MW3HBp1C4ZSw==
X-Gm-Gg: AR+sD134GR6pgf7SIFmSoCJEKjl6CPdw+F8a/qN7v9DK5btDOx9V6f+1DeUFg9aBiR0
	g0lU+n9AKrqd3FeKA1C3TOlWMRRsa8WZD0at2Sj9TVStwHQ1Q46/l+igcIlWSJZLfpGoFqyCx58
	KA1GpcKUVb/pXOJcDYMmmbxc4nG4RGkz6cKWwYfTXWCpjGXYriJhni5xMoIBKEOiSxPVaCBy0WD
	JowlZpJXwWpqctpJ7W2YCBhEzYo5fYLen3dqWkhDno5i8XnSRtAgiGFvXiTyw8ua+ELWkTqQaH5
	8BtS3lu+NSdDRfyk38YvXDgPnbKl4EJlJEreYZ/AIEYZiZmwr/cDn490FWx+MNyLwGkBfTnvFU/
	f2ljR0DZQ5gSArHQa3Vatx3oj//z5Unz1mvgS39NvcIRH2wS1ZWGX/6oylM+PJi0CoVFK6fvFHc
	yJcIA4HnKpjDgcjl3S7lfjJHydUog+gID2v+t46SVUuwVdAu28arUupZ8oDaNm5CHmcQcJwepVo
	1tzihNZ+TGHlXO8H5bQvCrBj4PnUauT
X-Received: by 2002:a05:6000:238a:b0:482:e968:86f9 with SMTP id ffacd0b85a97d-482e968892bmr14902580f8f.14.1787843990084;
        Thu, 27 Aug 2026 08:19:50 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 18/20] xen/riscv: initialize RCU, scheduler, and system domains in start_xen()
Date: Thu, 27 Aug 2026 17:19:11 +0200
Message-ID: <39aa3dec1317e567eb5102a8e6746a4614202ca4.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787843990-004CFA5B-60B65EA5/10/73395122804
X-purgate-type: spam
X-purgate-size: 1560

Wire up the missing early-boot initialization steps in start_xen().

The scheduler must be initialized prior to do_initcalls() because
cpupool_create_pool() is called during initcalls; without it,
BUG_ON(IS_ERR(pool)) is triggered inside cpupool_create_pool().

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v4-8:
 - Nothing changed. Only rebase.
---
Changes in v3:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v2:
 - New patch. Several patches were folded into one.
---
---
 xen/arch/riscv/setup.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 56a0907a855f..c3e98733ebc3 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -6,9 +6,12 @@
 #include <xen/compile.h>
 #include <xen/console.h>
 #include <xen/device_tree.h>
+#include <xen/domain.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
+#include <xen/rcupdate.h>
+#include <xen/sched.h>
 #include <xen/serial.h>
 #include <xen/shutdown.h>
 #include <xen/smp.h>
@@ -156,12 +159,21 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     timer_init();
 
+    rcu_init();
+
+    setup_system_domains();
+
     local_irq_enable();
 
     console_init_postirq();
 
     guest_mm_init();
 
+    scheduler_init();
+    set_current(idle_vcpu[0]);
+
+    do_initcalls();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400842.1636509 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtU-0007ir-Km; Thu, 27 Aug 2026 15:19:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400842.1636509; Thu, 27 Aug 2026 15:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtT-0007gH-I3; Thu, 27 Aug 2026 15:19:55 +0000
Received: by outflank-mailman (input) for mailman id 1400842;
 Thu, 27 Aug 2026 15:19:53 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtQ-0007E1-K9
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtP-00BpK6-TS
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:51 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905597-8faa-0a2a0a5109dd-0a2a45079888-2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:51 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905597-b4ea-0a2a45070019-d155802dec33-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:51 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49b0d8bc2aaso14137115e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19:51 -0700 (PDT)
Received: from fedora (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:51 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843991; x=1788448791; 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=nihbvDgoGb4TJo/cKdORKPVLnJZwrALFzlqr8YYLpAU=;
        b=kpLH7V/zEvPVRYHuCJ3pt4cOvyEd0ZtYlgOrkh/b3nma2u4bgpZ7aXcf0nGbHQDRrq
         IusfvNj4LF946bPRC2zjdAh1NSGL+uCGCHrr/v74qxoAQjDxwQnJYYoBjn5T7dFmsbxd
         xM15Se5msf+kRnzrnx6HM3BZj8wPSLZtJSuKMCpnHfqwRvn4239UddrtDWXV/YNBvrCP
         2f9Uq4PO8Z1FdDhRp1vrcjNSjMm+MmxSPQ8eTOs0vjUfwDnHX1kTRR9s77eELTaLRJIc
         dQinJ/DXu61RFFdY+GrHz8c0QwEa7z3CLOp06u5JWsdr4zlfpEq8F4RQHfyuin6Ox8NC
         B2eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843991; x=1788448791;
        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=nihbvDgoGb4TJo/cKdORKPVLnJZwrALFzlqr8YYLpAU=;
        b=rNtzF2rjPMAkXwOTGS1v0zI0gEbV4F7itTXII5WTDjUzzjuy148RJ4g9bJNO40NHRr
         H77rI8AGKuYQrkhz6Ip+emSdN36pejSDjZB6jW4lgPSO7Ha33eYTrc2I03ln4Ju1Wk1k
         CIZdaWBpm+5gJu0p+rcawmhVdeFIzujEdbMWSZpXjh6ccDqQFkeuHPYOg0FlY5+MWhRY
         0BCEMwLXXagVf+1FPMADSUIDe0N6LIvQBTimvSLrit7HUFh5N53ugtSXDEAsKAHY2VqA
         HQBc8UqdjN4b2V0gQ5yQUerGTZlfsDe1CKm7Y7bf9vg3zMZ2bz5Ggl4VaYaIkJ1KNPqs
         JxBg==
X-Gm-Message-State: AFuF++ncJIwUM4MnSCrnZsetu6EC2OYGlESBx06xlKkJbFYAbDs09P5x
	eXrENuViwi96zocvBPxE/1lF1bj5mrNLBBAEQfGBeAO2o8mPe9bHGYeibjeLIQ==
X-Gm-Gg: AR+sD13MP1wPc4o2+mHQidPhon2jf7IqUfRyndEXpupMXkunZoddifHoyJtrBDswshG
	xGe5Xh9qlV+Ii9rjddgj8o1J/+uiTbX2K2rKLrFZXaIASHCMEDVulAglX4WwnemUNp80cZgeRJN
	Z5HllWN9Dj1Rxf09RwjOPKPCzMqglDVnR3FyN4YrIjNmSCiiFQhCLEGXHOnN/apLOWBHQXBMtkE
	cmpi8cE9a0rbDEt/Fx82fqaagif7jVeGgvoMPr/Mg4hUnGiIsYW9wD+J8Wj0bvOqweOpgEQzRj7
	0kNA+TaljReUe8dIi+7bU6mb8UrLfgiboGtKeFzDqUkX0oGxghAa3J1Mt84M9BrvS7FZ4o15ZX0
	ufhExzOyQNQWbeC2SenupwBLNHbLbnxjqbiq32b909VLGS2Hk58rjg7P0k9e6sC43gL9VMbfzWP
	NQcPYvA2Q6yact7WMi7GJ2f5AQqV+3KrsWXAYwJvKIHPQ7XTd9UZ1r4stz2f/JJ/wklR4mVFCAT
	F9mnoFmjCWvzRrNmtv6krzyPk9D3dVg
X-Received: by 2002:a05:600c:c48f:b0:499:dbc0:370d with SMTP id 5b1f17b1804b1-499dc6eaca4mr163300205e9.2.1787843991237;
        Thu, 27 Aug 2026 08:19:51 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 19/20] xen/riscv: provide init_vuart()
Date: Thu, 27 Aug 2026 17:19:12 +0200
Message-ID: <906eee47f9e9da115209afe96b4efef9893346f1.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787843991-3C817AE4-3804E09F/10/73395122804
X-purgate-type: spam
X-purgate-size: 1391

For debug purpose is enough to have only print messages from guest what is
now implemented in vsbi_legacy_ecall_handler().

For full guesst console support it will better to have something similar to
[1], thereby there is nothing specific should be done, at least, for now
and init_vuart() is provided to make dom0less code buildable.

[1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2602041533440.3175371@ubuntu-linux-20-04-desktop/

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v3-v8:
 - Nothing changed. Only rebase.
---
Changes in v2:
 - Add Acked-by: Jan Beulich <jbeulich@suse.com>.
---
---
 xen/arch/riscv/dom0less-build.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index a1fa51b996a7..d1a51b92936a 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -8,6 +8,14 @@
 
 #include <asm/p2m.h>
 
+int __init init_vuart(struct domain *d, struct kernel_info *kinfo,
+                      const struct dt_device_node *node)
+{
+    /* Nothing to do at the moment */
+
+    return 0;
+}
+
 int __init init_intc_phandle(struct kernel_info *kinfo, const char *name,
                              const int node_next, const void *pfdt)
 {
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:19:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:19:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400844.1636516 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtX-00084R-1W; Thu, 27 Aug 2026 15:19:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400844.1636516; Thu, 27 Aug 2026 15:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbtV-0007zw-HZ; Thu, 27 Aug 2026 15:19:57 +0000
Received: by outflank-mailman (input) for mailman id 1400844;
 Thu, 27 Aug 2026 15:19:54 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbtR-0007Ne-Rj
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:19:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbtR-00C6oU-6u
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:19:53 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905598-2eae-0a2a0a5409dd-0a2a4502a324-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:53 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905599-6ca4-0a2a45020019-d155dd2eed9f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:19:53 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47ddf7b09e5so1880269f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:19: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
 ffacd0b85a97d-482e28f5d01sm10049148f8f.32.2026.08.27.08.19.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:19:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1787843992; x=1788448792; 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=fVKdGetffBRubdmjJd38E0ZcnQQRwEaATMIg4OwbtS0=;
        b=VO0qUWWUuPSk1qaWoG0IuDyUmJ8dMQTjUXCOYhtImrn+shyATsJDyJ33inzEZxCL7w
         z6RGpqPqhtNrUm/qRjJ+sEirI9eszV21gEeorDk+pb5tiFrLCrO0bk0n58oqvlyzI0Hg
         /4Q2q1gCyIpXpSOb+CVJZ1pVYLwTNiZr/jW5xUHKHxWTZhH01s/IdEFS3nzwfBl/BV6/
         aiR4WlWxKgBJPqfqmoSz2azHyrKb4Vb7cSrC7jt7mp1bHA9Av95Ywgm0MYZmnrqHirtR
         Tj8DqQ1eJHsnUWb9szGJRQQd2ghEL7Ahtto68SIYrb1P9q0yozWDZNU9aNW1p/jW4udm
         SDwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787843992; x=1788448792;
        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=fVKdGetffBRubdmjJd38E0ZcnQQRwEaATMIg4OwbtS0=;
        b=iC0SEaeKNb9sFDE8OR2JJ3jfVwNjZErsz9JaP4adMJfJeHNTFsb6C6bn+B586agyCm
         18DybGHuZE2KLwfdKt/dXtLRMt7F4Pn5wI8r6a0+KM6lAJgsIiWs1M+HBUH+xcfeLrjH
         xfHcEpTRZSn9PpMWzi0YnZQnE3uyh02ezzDlVOg1vQmkLt6TrcUo6U7zjmwIqLZxB3N9
         PNeuqQdPuDj82HKmsdlu1uhcrjDXxtuaomEyO3stcxTNqxoCWYdK//PYYK8MNpY4GLuX
         UZ1JuJKHuO/QXLIW3Jn+VhMiE5X62FVRtUjymTb1tf0+mNbx7LZSHkWDuJml+1SQOOa5
         8skw==
X-Gm-Message-State: AFuF++mXYXpBHg1ShUTTCTDjOLFUDLfcEhJh9vn/oNBbaEdrohb9qrhr
	71R6YK7afR0G3CLOZdmhcxtjtQ/TG160T1ekkh8PBDdAVOHX/twMFrvrcpiwbg==
X-Gm-Gg: AR+sD12UMP8A662X0JPAJrkOIxV8XbAaU4LuoYqraHagzjFPM4xkUNzP4U5viqSb9s1
	DIuTXDYSXCiiEVE27kfKdBLBF2+MJoHxuOqfUwzj86JprKzSDoEqJEAu+Thoh4HIulPWxQDhr4K
	qBoNUq7AgcHbhcZSr/K52kuesRNSJ6fp9XYbajqRAWXLu1+/ABSIRuEYvblwPVi55PkXmkoUMlN
	j18KeHcT1c03XFc6TPVsaaRkHLfh58fWFGspern9Mq7f419g6oIeEWJjkg8Jaa0zxaikRSftcnd
	hztLkQoKSC0y4xOARi7cLYSW0toUABzY+ktAGxbfSQkNl2B7gOZz5iRldbrLFaBU/S5PIKRURz1
	Vl7XVOquYDr548FTwWEdCfj10dnahv+qyF0qKea++5ip0hi6lmc7kZFDSBE2qEj2jeER8dtp765
	5oyGZuXQeWTFXcWIAqAw6qPIq5AHtMdeC+IFjrLsPGgHMHYYhDBlSw1PGf72HYg2hgBj7Lbo33V
	KfjO6V/MJeROM3FzMY/3FtSMTIavZ8ouQ==
X-Received: by 2002:a05:6000:29dc:b0:47f:8183:e9b8 with SMTP id ffacd0b85a97d-482e26f2a93mr16922970f8f.22.1787843992513;
        Thu, 27 Aug 2026 08:19:52 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v8 20/20] xen/riscv: add initial dom0less infrastructure support
Date: Thu, 27 Aug 2026 17:19:13 +0200
Message-ID: <bf905ec5249be975ee878d4c6002118f09ba4fc1.1787836900.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787836900.git.oleksii.kurochko@gmail.com>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787843993-66AB52AC-C88A6E13/10/73395122804
X-purgate-type: spam
X-purgate-size: 7397

Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and
providing the minimal architecture hooks required by the common
dom0less infrastructure.

Add stub implementations for architecture-specific helpers used when
building domains from the device tree. These allow the generic
dom0less code to build and let a basic DomU be constructed on RISC-V.
construct_hwdom() and make_hypervisor_node() are still stubs returning
an error: Dom0/hwdom construction isn't supported yet, and the
hypervisor node generation (needed by domains with
DOM0LESS_ENHANCED_NO_XS set) is not implemented. Both are marked with
a TODO and are not reached by the currently supported configurations.

Provide missing helpers and definitions required by the domain
construction code, including domain bitness helpers and the
p2m_set_allocation() prototype.

Additionally define the guest magic memory region (GUEST_MAGIC_BASE /
GUEST_MAGIC_SIZE) in asm/guest-layout.h. The base is arbitrary; the
only constraint is that the region must not overlap guest RAM or the
emulated device regions. It is placed in the unused gap below
GUEST_RAM0_BASE (0x80000000); the constraints are documented next to
the #define-s.

A separate region for grant tables will be introduced at the same time as
the introduction of the grant table for RISC-V.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes in v8:
 - Nothing changed. Only rebase.
---
Changes in v6-7:
 - Acked-by: Jan Beulich <jbeulich@suse.com>.
---
Changes in v5:
 - Reword the comment above defintion of GUEST_MAGIC_BASE.
 - Shrunk the size of GUEST_MAGIC_SIZE to 2Mb as looking on the Arm
   only 4 pages are used and there is no technical reason to have 16Mb for
   that region. (Maybe in case of Arm it is connected that Arm has these
   definitions in public header so more space is reserved to not "break"
   public API in future)
 - Update the commit message with a remark about grant table region
   in guest-layout.h.
---
Changes in v4:
  - Reword the description: the stubs do not let dom0less fully "run"
    since construct_hwdom() and make_hypervisor_node() return an error;
    spell out these limitations instead.
  - Add a TODO comment to construct_hwdom() explaining that Dom0/hwdom
    construction isn't supported yet.
  - Add a TODO comment to make_hypervisor_node() explaining that
    returning an error breaks building of domains with
    DOM0LESS_ENHANCED_NO_XS set, and why that is harmless for now.
  - Document the constraints on GUEST_MAGIC_BASE/GUEST_MAGIC_SIZE next
    to the #define-s and drop the QEMU-based justification (QEMU is not
    involved); the base is simply an arbitrary non-overlapping address.
Changes in v3:
  - Add /* Nothing specific to do for now */ comment to
    arch_handle_passthrough_prop().
  - Use _ULL() instead of xen_mk_ullong() for GUEST_MAGIC_BASE and
    GUEST_MAGIC_SIZE (xen_mk_ullong() is intended for public headers only).
  - Fix GUEST_MAGIC_BASE from 0x39000000 to 0x79000000 to avoid the
    QEMU RISC-V virt machine PCIE_ECAM range.
  - Drop CONFIG_STATIC_MEMORY=n from the CI randconfig; now redundant
    since STATIC_MEMORY depends on HAS_STATIC_MEMORY which RISC-V does
    not select.
Changes in v2:
  - Move declaration of p2m_set_allocation() to p2m-common.h.
  - Add __initdata for max_init_domid and drop initalizer for it.
  - Add CONFIG_STATIC_MEMORY=n to CI's randconfig to avoid
    compilation error because of guest_physmap_add_pages()
    isn't provided.
---
 xen/arch/riscv/Kconfig                    |  2 ++
 xen/arch/riscv/dom0less-build.c           |  7 ++++++
 xen/arch/riscv/domain-build.c             | 28 +++++++++++++++++++++++
 xen/arch/riscv/include/asm/guest-layout.h | 12 ++++++++++
 4 files changed, 49 insertions(+)

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 48520588fe40..d8a348c0cf07 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -6,6 +6,8 @@ config RISCV
 	select GENERIC_BUG_FRAME
 	select GENERIC_UART_INIT
 	select HAS_DEVICE_TREE_DISCOVERY
+	select HAS_DOM0LESS
+	select HAS_DOMAIN_TYPE
 	select HAS_EX_TABLE
 	select HAS_PMAP
 	select HAS_UBSAN
diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c
index d1a51b92936a..0801d7e25059 100644
--- a/xen/arch/riscv/dom0less-build.c
+++ b/xen/arch/riscv/dom0less-build.c
@@ -102,3 +102,10 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node,
 
     return 0;
 }
+
+int __init arch_handle_passthrough_prop(struct kernel_info *kinfo,
+                                        struct dt_device_node *node)
+{
+    /* Nothing specific to do for now */
+    return 0;
+}
diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c
index d7613721db95..1e3abe259ccd 100644
--- a/xen/arch/riscv/domain-build.c
+++ b/xen/arch/riscv/domain-build.c
@@ -156,9 +156,37 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo)
     return fdt_end_node(fdt);
 }
 
+int __init construct_hwdom(struct kernel_info *kinfo,
+                           const struct dt_device_node *node)
+{
+    /*
+     * TODO: Dom0/hwdom construction isn't supported on RISC-V yet, so this
+     * is a stub returning an error. It must be implemented before a hardware
+     * domain can be built from the device tree.
+     */
+
+    return -EOPNOTSUPP;
+}
+
 int __init make_timer_node(const struct kernel_info *kinfo)
 {
     /* There is no need for timer node for RISC-V. */
 
     return 0;
 }
+
+int __init make_hypervisor_node(struct domain *d,
+                                const struct kernel_info *kinfo,
+                                int addrcells, int sizecells)
+{
+    /*
+     * TODO: Generating the hypervisor node isn't implemented yet. Returning
+     * an error here breaks building of any domain (DomU included) whose
+     * dom0less_feature has DOM0LESS_ENHANCED_NO_XS set. This is harmless for
+     * now because Dom0/hwdom construction isn't supported on RISC-V yet
+     * either, and no RISC-V DomU sets that flag, so this path is never taken.
+     * It must be implemented before DOM0LESS_ENHANCED_NO_XS is used.
+     */
+
+    return -EOPNOTSUPP;
+}
diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h
index 90603f06bb91..ceed9125e7e2 100644
--- a/xen/arch/riscv/include/asm/guest-layout.h
+++ b/xen/arch/riscv/include/asm/guest-layout.h
@@ -32,4 +32,16 @@
 #define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
 #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
 
+/*
+ * The guest magic region holds the Xen-reserved pages mapped into the
+ * guest's physical address space. The only real constraint on
+ * GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM
+ * (the GUEST_RAMx banks) or the emulated device regions defined above;
+ * the exact base is otherwise arbitrary. Here it is placed in the unused gap
+ * below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank would work
+ * equally well.
+ */
+#define GUEST_MAGIC_BASE  _UL(0x79000000)
+#define GUEST_MAGIC_SIZE  _UL(0x00200000)
+
 #endif /* ASM_RISCV_GUEST_LAYOUT_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400920.1636548 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvD-0006Gk-Qg; Thu, 27 Aug 2026 15:21:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905604-bab6-0a2a0a5309dd-0a2a4507d2f8-2
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905605-b4ea-0a2a45070019-d1558035bd87-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:41 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-49556f97a9dso6058325e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787844101-344CBAE4-94184493/10/73395122804
X-purgate-type: spam
X-purgate-size: 1482

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 <oleksii.kurochko@gmail.com>
---
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/include/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;
 };
 
 /* 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();
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400919.1636540 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvC-00063H-KN; Thu, 27 Aug 2026 15:21:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1400919.1636540; Thu, 27 Aug 2026 15:21:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvC-00063A-Gw; Thu, 27 Aug 2026 15:21:42 +0000
Received: by outflank-mailman (input) for mailman id 1400919;
 Thu, 27 Aug 2026 15:21:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvA-00060j-SL
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzbv9-009ksf-OI
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:39 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905601-2eae-0a2a0a5409dd-0a2a4504ba94-8
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:39 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905603-b57f-0a2a45040019-d155802ad095-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:39 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49b392ccaacso11898515e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:21:39 -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.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 27 Aug 2026 08:21:38 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-ID:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787844099; x=1788448899; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=CBrU03USIPoQ/ePxJIOS375Vmn7ZObWJdkc5XcTcpQ8=;
        b=LieF0W/8qz841+4ydookV3pxrEidoLymCzDn8jN2shMoiVLDzXWaWZMA3P+rtNHoQt
         ZTstdvUYvvQ6fK5C/XMX7UF9/mAPt08VMb9JgetgWxgFrArWb+YmZard1YaefbtK9it8
         8+oJmFPac6DT3+PNZtqZkaRamqEujNec9FXvAzQeRm0WA6wMIArPu6xUkaP3gU+4GcuP
         g5/dYepgl3oima6jGpERVdnzYNwM2Rcmu+Pg7gh2gP15YAClXeU4PchaYQfgSdlUP6+e
         hQZQ2xbN6+AjO0t29rWQhnDZtr8U3axemh2MQ/NNCKYO9B7nN8zdZiStfJRXWZiadusQ
         w7Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787844099; x=1788448899;
        h=content-transfer-encoding:mime-version: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=CBrU03USIPoQ/ePxJIOS375Vmn7ZObWJdkc5XcTcpQ8=;
        b=W79N6gL73aOskMU2qmUts99pQGY1hyQ/hBprugOwv261Ey1DFE8zXpBh35I4DZOSLW
         7TGDB3Wswyay5RfVRsXrfLz9S0C7E4R3blF83EuYQffhAch7zdwVV+0n0yUWwP/NtbmG
         CGOR6pu+/V01C1n+zxp6q0cq6Fe7TBHcZO2//rOxmzquIsKhCTS29drl06+fGgEH5fDX
         3x19f/kirx62J0r1msHiZKJVIPNqji3SQia+0oIOAQtCOWsti7n07OQ50XJj9HeuIpfv
         xrAKtxyerKAnzXgwj3YoCMgaCpPXDOmHwxCqhoLOIVGac2u2yz1q85LJiWY5zeX/D3RH
         S+gA==
X-Gm-Message-State: AFuF++m1tbHOZQRSDQrTru65WOUEGhtGTH8S3mc9cy/8zv1oV+5elQiD
	s2qiRYUixM9jG3jKff4sp8SJGAa4XbYH6we7lmq0d+VkSj49MHjV0mu6C0gsXg==
X-Gm-Gg: AR+sD120Y44/n3cixcgtl8VYNSA3WcX3Zn7PkDyJWXnf259rM7gN5fJ+pp84s6RtoCe
	y+gBcRK+rRSp7j2HMghtsPUS7kiHmnV6uOC1xr86HzYJ103j7TP3lmQNIwbRcRu7kTJ3rDXrAOq
	us1oq+wxNhZtmxB0wy+Al6RkiDji4qnuTzSe2Tks2JDtMsCmM2ph/27ehib81GtAIUDBa++qFKm
	4OyNyypziRruiEzKZNTCx418bk8Qu3DDNOn3m6DHzKVwd3LLHtEQMQ/MqFMcPGPGQmVfQsnoPvB
	COgzis3ql5CYh9ZKRXOlIRMtktypLrC+YNXF21jaAIqsjNAt8i5coZuNHAsa3NT5tJDI72/SbBj
	D2QkwZYiyZ+Xwm93Mav28CjPK6MitKRz7y91WE0sAN1w8ab0Us3w5W0t3pLSgIaCxLzvVUxLL91
	qhigR/dj+daBB2ZiKoeZj3en/pHg3Lga/DuXx+XLZb5BwfhvXDN1JLFj/LyUwckzcdtoEV6gEoS
	1+Ppxb+let2c8RVOylEKd+eOcuYBBSS
X-Received: by 2002:a05:600c:3f08:b0:499:d513:e507 with SMTP id 5b1f17b1804b1-499dc6efdf9mr218483915e9.2.1787844099025;
        Thu, 27 Aug 2026 08:21:39 -0700 (PDT)
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 00/39] [RISC-V] virtual interrupt controller (vAPLIC/vIMSIC) support
Date: Thu, 27 Aug 2026 17:20:44 +0200
Message-ID: <cover.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787844099-520D5B50-07880D69/10/73395122804
X-purgate-type: spam
X-purgate-size: 12149

Hi all,

This series adds the initial virtual interrupt controller (vINTC) support
for RISC-V guests in Xen, based on the Advanced Interrupt Architecture
(AIA): a virtual APLIC (vAPLIC) in MSI mode backed by a virtual IMSIC
(vIMSIC) using hardware guest interrupt files.

Rather than emulating APLIC in direct-delivery mode (which requires
trap-and-emulate for every interrupt and is costly), the series targets
IMSIC from the start. AIA lets a hart implement several "guest interrupt
files" (up to GEILEN), so external interrupts can be delivered to a vCPU
directly by hardware via the VGEIN field of hstatus, without a hypervisor
round-trip. Xen only has to emulate the APLIC MMIO programming interface
and route the guest's intent onto the physical MSI topology; interrupt
delivery itself stays in hardware.

The work breaks down into a few logical blocks:

Preparatory fixes and cleanups (patches 1-6)
  - Drop the unused pregs field of struct cpu_user_regs and bug.h's
    duplicate instruction length helpers.
  - Program hstatus.VSXL explicitly, as decoding a trapped instruction
    depends on the effective XLEN of the guest.
  - csr_read64() as the counterpart of csr_write64(), used for CSR_TIME so
    that get_cycles() no longer truncates the time counter on RV32, and
    UINT64_MAX rather than ULONG_MAX to disable the VS-timer.
  - Request a G-stage flush on vmenter where VMIDs are unavailable, so a
    domain cannot run on the translations left behind by the one which ran
    on that hart before it.

APLIC groundwork and vAPLIC MMIO emulation (patches 7-11)
  - Add the missing APLIC register offsets/masks needed by both the
    physical and virtual APLIC code, rearranging asm/aplic.h in the style
    of x86's asm/msr-index.h (no functional change).
  - A per-domain MMIO handler table modelled on Arm's framework, so
    emulated devices self-register their GPA ranges and the fault path
    stays agnostic via a single try_handle_mmio() entry point.
  - vAPLIC MMIO read/write emulation. Writes are gated by the domain's
    authorised-IRQ bitmap so a guest cannot touch interrupts it does not
    own, and TARGET writes are translated from virtual to physical
    hart/guest-file indices. Delegation (SOURCECFG.D) is not yet
    supported.
  - Build the physical APLIC's target hart index with aplic_hart_field()
    as well, dropping the last in-tree duplicate of the AIA hart index
    formula, and add a helper to test for APLIC MSI mode.

vCPU context switching (patches 12-15)
  - context_switch() and the helpers it needs: save/restore of H/VS CSRs,
    the virtual timer and P2M context, and __context_switch() in assembly.
    The VMID is claimed in p2m_ctxt_switch_to() rather than at the next
    guest entry, which leaves p2m_handle_vmenter() with nothing to do.
  - Save and restore the AIA CSRs a guest can change (vsiselect and
    hviprio{1,2}), gated by hstateen0 where Smstateen is implemented.
  - vintc_ctxt_switch_{from,to}() wrappers over new ctxt_switch_{from,to}
    hooks in struct vintc_ops, called from the context switch path, plus
    the IMSIC implementation of those hooks: it records which pCPU owns a
    vCPU's guest interrupt file, as the pCPU id is part of the MSI
    address.

Trap and instruction emulation infrastructure (patches 16-26)
  - Extend the exception-table format with type/data fields and add
    EX_TYPE_TRAP_INFO so fixups can capture sepc/scause/stval, and look
    the table up for any trap taken in Xen context rather than for illegal
    instructions only, so that the hlv/hlvx sequences reach their fixup.
  - A guest page-fault handler, and trap_redirect() to forward a
    synchronous trap back into the guest's VS-mode handler for the faults
    which can never become an emulated access.
  - Resolve the faulting guest physical address from htval and stval,
    which first needs Shtvala to be detected, and define all four
    INSN_PSEUDO_VS_* values independently of the hypervisor's XLEN, so
    that a fault taken on an implicit VS-stage access is recognized as one
    rather than mistaken for an MMIO trap.
  - riscv_read_guest() (HLV/HLVX) to read guest memory and instructions
    safely, the decoding helpers shared by both access types, and the load
    and store emulation which dispatches the access through
    try_handle_mmio().

vCPU migration between pCPUs (patches 27-34) (introduced here for better context
of VGEIN fumctions usage)
  - arch_move_irqs(), dispatching through a new move_irqs hook in
    struct vintc_ops down to imsic_migrate_vcpu(), and the case where a
    vCPU has no guest interrupt file to move yet.
  - The move of a vCPU's IMSIC guest interrupt file itself, following the
    sequence the AIA spec prescribes: quiesce and save eidelivery/
    eithreshold of the old file, zero the new one, G-stage remap it,
    retarget the domain's APLIC interrupts at it
    (aplic_reconfigure_target()) and fence off straggler MSIs with a
    genmsi barrier, dump the old file's eip/eie arrays to memory, then
    restore that state into the new file and update the vCPU's
    hstatus.VGEIN.

VGEIN allocation and vCPU bring-up (patches 35-39)
  - Per-pCPU VGEIN (guest interrupt file) allocator: a bitmap of the files
    a hart implements (up to GEILEN) with helpers to assign and release
    one, and an owners[] map so a file reported pending in HGEIP can be
    traced back to the vCPU it belongs to.
  - Watch a descheduled vCPU's guest interrupt file through HGEIE, so that
    a guest blocked on an external interrupt is woken up instead of
    waiting for an unrelated event to schedule it again.
  - Stage-2 map a vCPU's physical guest interrupt file to the fixed
    per-vCPU GPA page the guest expects at offset 0.
  - continue_new_vcpu(): switch to the idle vCPU's own stack for the idle
    vCPU, and enter the guest through the new return_to_new_vcpu() path in
    entry.S for a guest one.
  - imsic_vsfile_attach(), called once the pCPU a vCPU will run on is
    known: it assigns a VGEIN, maps the guest interrupt file and records
    the IMSIC state as a consistent unit.

CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2796779115

The series depends on [1].

[1] https://lore.kernel.org/xen-devel/cover.1787836900.git.oleksii.kurochko@gmail.com/T/#t

---
Changes in v2:
 - The series has grown from 17 to 39 patches. vCPU context switching, vCPU
   migration between pCPUs and the vCPU bring-up path (continue_new_vcpu(),
   attaching an IMSIC h/w interrupt file) are now part of it to have better
   context of how things are using, together with the trap-side pieces the
   MMIO emulation depends on (faulting GPA resolution, Shtvala detection,
   instruction decoding).
 - vintc_state_{save,restore}() became vintc_ctxt_switch_{from,to}() and
   vcpu_aia_init() became imsic_vsfile_attach(); "xen/riscv: manage
   IRQ_DISABLED flag in APLIC irq enable/disable callbacks" is no longer part
   of this series. The remaining changes are described in the per-patch
   changelogs.
---

Oleksii Kurochko (39):
  xen/riscv: drop pregs from struct cpu_user_regs
  xen/riscv: drop bug.h's duplicate instruction length helpers
  xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL
  xen/riscv: introduce csr_read64()
  xen/riscv: request a G-stage flush on vmenter when VMIDs are disabled
  xen/riscv: use UINT64_MAX to disable the VS-timer
  xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h
  xen/riscv: introduce device-agnostic MMIO emulation dispatch
  xen/riscv: implement virtual APLIC MMIO emulation
  xen/riscv: build the target hart index via aplic_hart_field()
  xen/riscv: add helper to check APLIC MSI mode
  xen/riscv: implement vCPU context switching
  xen/riscv: save and restore AIA state on vCPU context switch
  xen/riscv: introduce vintc_ctxt_switch_{from,to}()
  xen/riscv: add IMSIC vCPU context switch handlers
  xen/riscv: extend exception tables with type and data fields
  xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN
  xen/riscv: add guest page fault handling stub
  xen/riscv: implement trap redirection to a guest
  xen/riscv: detect Shtvala
  xen/riscv: resolve the faulting guest physical address
  xen/riscv: add guest memory read helper
  xen/riscv: look up the exception table for any trap taken in Xen
    context
  xen/riscv: add helpers for decoding a trapped load or store
  xen/riscv: add guest load emulation for trapped MMIO accesses
  xen/riscv: add guest store emulation for trapped MMIO accesses
  xen/riscv: introduce arch_move_irqs()
  xen/riscv: handle the case when no vCPU migration is needed
  xen/riscv: introduce aplic_reconfigure_target()
  xen/riscv: prepare new IMSIC VS-file
  xen/riscv: implement APLIC-hart sync barrier for vCPU migration
  xen/riscv: remap interrupts to new IMSIC VS-file
  xen/riscv: dump old interrupt file to memory
  xen/riscv: restore register state in the new IMSIC VS-file
  xen/riscv: add basic VGEIN management for AIA guests
  xen/riscv: wake up a descheduled vCPU on a guest external interrupt
  xen/riscv: map IMSIC interrupt file for vCPUs
  xen/riscv: implement continue_new_vcpu()
  xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu

 xen/arch/riscv/Makefile                     |   2 +
 xen/arch/riscv/aia.c                        | 193 ++++++
 xen/arch/riscv/aplic-priv.h                 |   3 +
 xen/arch/riscv/aplic.c                      | 235 ++++++-
 xen/arch/riscv/cpufeature.c                 |   1 +
 xen/arch/riscv/domain.c                     | 271 +++++++-
 xen/arch/riscv/emulate.c                    | 578 ++++++++++++++++
 xen/arch/riscv/entry.S                      |  67 ++
 xen/arch/riscv/extable.c                    |  70 +-
 xen/arch/riscv/guestcopy.c                  |  87 +++
 xen/arch/riscv/imsic.c                      | 691 ++++++++++++++++++++
 xen/arch/riscv/include/asm/aia.h            |   7 +
 xen/arch/riscv/include/asm/aplic.h          | 130 +++-
 xen/arch/riscv/include/asm/bug.h            |  19 -
 xen/arch/riscv/include/asm/cpufeature.h     |   1 +
 xen/arch/riscv/include/asm/csr.h            |  24 +
 xen/arch/riscv/include/asm/current.h        |   4 +
 xen/arch/riscv/include/asm/domain.h         |  23 +-
 xen/arch/riscv/include/asm/emulate.h        |  10 +
 xen/arch/riscv/include/asm/extable.h        |  64 +-
 xen/arch/riscv/include/asm/gpr-num.h        |  37 ++
 xen/arch/riscv/include/asm/guest_access.h   |   4 +
 xen/arch/riscv/include/asm/imsic.h          |  31 +
 xen/arch/riscv/include/asm/intc.h           |  12 +
 xen/arch/riscv/include/asm/irq.h            |   5 +-
 xen/arch/riscv/include/asm/mmio.h           |  63 ++
 xen/arch/riscv/include/asm/p2m.h            |   1 -
 xen/arch/riscv/include/asm/processor.h      |  16 +-
 xen/arch/riscv/include/asm/riscv_encoding.h |  34 +-
 xen/arch/riscv/include/asm/system.h         |   4 +
 xen/arch/riscv/include/asm/time.h           |   4 +-
 xen/arch/riscv/include/asm/traps.h          |   9 +
 xen/arch/riscv/include/asm/vaplic.h         |   5 +
 xen/arch/riscv/intc.c                       |  22 +
 xen/arch/riscv/mmio.c                       | 176 +++++
 xen/arch/riscv/p2m.c                        |  55 +-
 xen/arch/riscv/riscv64/asm-offsets.c        |  20 +-
 xen/arch/riscv/stubs.c                      |   5 -
 xen/arch/riscv/time.c                       |   4 +-
 xen/arch/riscv/traps.c                      | 110 +++-
 xen/arch/riscv/vaplic.c                     | 358 +++++++++-
 xen/arch/riscv/vmid.c                       |   4 +-
 xen/include/xen/config.h                    |   1 +
 43 files changed, 3281 insertions(+), 179 deletions(-)
 create mode 100644 xen/arch/riscv/emulate.c
 create mode 100644 xen/arch/riscv/include/asm/emulate.h
 create mode 100644 xen/arch/riscv/include/asm/gpr-num.h
 create mode 100644 xen/arch/riscv/include/asm/mmio.h
 create mode 100644 xen/arch/riscv/mmio.c

-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400921.1636553 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvE-0006JW-26; Thu, 27 Aug 2026 15:21:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905605-e002-0a2a0a5209dd-0a2a4506aa28-2
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905606-195a-0a2a45060019-d1558030b16f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:42 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-499ae1c6471so14450135e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787844102-1FECC77B-57640B1F/10/73395122804
X-purgate-type: spam
X-purgate-size: 1984

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 <oleksii.kurochko@gmail.com>
---
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 @@
 
 #define BUG_INSTR "unimp"
 
-/*
- * 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) == INSN_LENGTH_32 ? 4 : 2) \
-
 #endif /* !__ASSEMBLER__ */
 
 #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();
             }
 
-            cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc);
+            cpu_regs->sepc += INSN_LEN(*(uint16_t *)pc);
 
             break;
         }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400922.1636567 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvF-0006i4-Ia; Thu, 27 Aug 2026 15:21:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a9055fd-2eae-0a2a0a5409dd-0a2a45029cdc-14
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905607-6ca4-0a2a45020019-d155dd36ac20-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:43 +0200
Received: by mail-wr1-f54.google.com with SMTP id
 ffacd0b85a97d-482e5733a5aso1156807f8f.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <a3ae79823e24f2e18cef2fac8ffffe7caa608f32.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844103-F26B72AC-C6CE6752/10/73395122804
X-purgate-type: spam
X-purgate-size: 2025

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=64 only must not be recognized for a 32-bit one.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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 = HEDELEG_DEFAULT & csr_masks.hedeleg;
 
-    vcpu_guest_cpu_user_regs(v)->hstatus = 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 =
+        HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(HSTATUS_VSXL_64, HSTATUS_VSXL);
 
     v->arch.hideleg = HIDELEG_DEFAULT & csr_masks.hideleg;
 
diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/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 == 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)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400923.1636574 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvG-0006xf-PR; Thu, 27 Aug 2026 15:21:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a9055ff-e002-0a2a0a5209dd-0a2a450acd1a-24
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905608-f2d2-0a2a450a0019-d155802db59b-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:45 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49557167508so8907035e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787844105-510C9CFC-985064EA/10/73395122804
X-purgate-type: spam
X-purgate-size: 3037

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 <oleksii.kurochko@gmail.com>
---
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 hardware
+ * 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_ = csr_read(csr ## H);               \
+        lo_ = csr_read(csr);                    \
+    } while ( hi_ != 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
 
 #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");
 }
 
-typedef unsigned long cycles_t;
+typedef uint64_t cycles_t;
 
 static inline cycles_t get_cycles(void)
 {
-    return csr_read(CSR_TIME);
+    return csr_read64(CSR_TIME);
 }
 
 void preinit_xen_time(void);
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400924.1636585 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvJ-0007F5-4u; Thu, 27 Aug 2026 15:21:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905600-8faa-0a2a0a5109dd-0a2a4508e25c-14
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90560a-f659-0a2a45080019-d155802aa96d-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:46 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-4954a9e8490so7056565e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1787844106-DF6D687B-ADA8C687/10/73395122804
X-purgate-type: spam
X-purgate-size: 2277

vmid_handle_vmenter() reports that no flush is needed when VMIDs are
unavailable (vmid=off, 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 <oleksii.kurochko@gmail.com>
---
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, which
-     * 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 set
+     * on every entry, so the flush above covers that case.
      */
 }
 
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)
 
     /* Test if VCPU has valid VMID. */
     if ( read_atomic(&vmid->generation) == data->generation )
-        return 0;
+        return false;
 
     /* 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)
 
  disabled:
     vmid->vmid = 0;
-    return 0;
+    return true;
 }
 
 /*
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400925.1636589 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvJ-0007IJ-E8; Thu, 27 Aug 2026 15:21:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a9055ff-e002-0a2a0a5209dd-0a2a450acd1a-34
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90560b-f2d2-0a2a450a0019-d155802fedc9-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:48 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4998b5a63e2so21329235e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787844108-518C5CFC-04893859/10/73395122804
X-purgate-type: spam
X-purgate-size: 1505

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 <oleksii.kurochko@gmail.com>
---
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);
     }
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400926.1636602 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvL-0007ly-Vm; Thu, 27 Aug 2026 15:21:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a9055fd-bab6-0a2a0a5309dd-0a2a4503983c-24
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90560d-fae8-0a2a45030019-d155802aad93-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:49 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49b0dd3c9a0so9201085e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <b3e0c1a662403ea2aa84a1943223ad0885733d0f.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787844109-6EECA4E9-343351B2/10/73395122804
X-purgate-type: spam
X-purgate-size: 5998

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 <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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/asm/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 @@
 
 #include <asm/imsic.h>
 
+/*
+ * 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 = 1: bits [9:0] hold the Child Index, i.e. the source is delegated
+ *           to a child domain (unsupported by Xen);
+ *  - D = 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
 
-#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
 
-#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)
 
-#define APLIC_IDC_SIZE          32
+#define APLIC_IDC_SIZE                  32
 
-#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)
 
-#define APLIC_SIZE(nr_cpus)     (APLIC_MIN_SIZE + \
-                                 APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus)))
+#define APLIC_SIZE(nr_cpus) \
+    (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus)))
 
 struct aplic_regs {
     uint32_t domaincfg;         /* 0x0000 */
@@ -82,7 +138,7 @@ struct aplic_regs {
     uint8_t _reserved11[4088];  /* 0x2008 */
 
     uint32_t genmsi;            /* 0x3000 */
-    uint32_t target[1023];      /* 0x3008 */
+    uint32_t target[1023];      /* 0x3004 */
 };
 
 #endif /* ASM_RISCV_APLIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400927.1636611 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvN-00080V-7L; Thu, 27 Aug 2026 15:21:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a9055fd-2eae-0a2a0a5409dd-0a2a45029cdc-22
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90560e-6ca4-0a2a45020019-d1558029b852-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:50 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-496bb7cdf51so11598645e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch
Date: Thu, 27 Aug 2026 17:20:52 +0200
Message-ID: <a74ff916f76fb95e1e44bfadd45fbc477df00c51.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844110-666B72AC-5A122C66/10/73395122804
X-purgate-type: spam
X-purgate-size: 11906

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 <oleksii.kurochko@gmail.com>
---
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 <xen/sort.h> 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 += intc.o
 obj-y += irq.o
 obj-y += kernel.init.o
 obj-y += mm.o
+obj-y += mmio.o
 obj-y += p2m.o
 obj-y += paging.o
 obj-y += 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 <asm/cpufeature.h>
 #include <asm/csr.h>
 #include <asm/intc.h>
+#include <asm/mmio.h>
 #include <asm/riscv_encoding.h>
 #include <asm/vtimer.h>
 
@@ -316,6 +317,8 @@ int arch_domain_create(struct domain *d,
     if ( (rc = p2m_init(d, config)) != 0)
         goto fail;
 
+    domain_io_init(d);
+
     if ( (rc = domain_vintc_init(d)) )
         goto fail;
 
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/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 @@
 
 #include <asm/cpufeature.h>
 #include <asm/guest-layout.h>
+#include <asm/mmio.h>
 #include <asm/p2m.h>
 #include <asm/vtimer.h>
 
@@ -101,6 +102,8 @@ struct arch_domain {
     const unsigned long *isa;
 
     struct vintc *vintc;
+
+    struct vmmio vmmio;
 };
 
 #include <xen/sched.h>
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 <xen/lib.h>
+#include <xen/rwlock.h>
+
+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 *info);
+
+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 <xen/bsearch.h>
+#include <xen/lib.h>
+#include <xen/rwlock.h>
+#include <xen/sched.h>
+#include <xen/string.h>
+
+#include <asm/current.h>
+#include <asm/mmio.h>
+
+/*
+ * bsearch() comparator: @key holds the address to look up in its addr field,
+ * @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 = key;
+    const struct mmio_handler *handler1 = elem;
+
+    if ( handler0->addr < handler1->addr )
+        return -1;
+
+    if ( handler0->addr >= (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 = &d->arch.vmmio;
+    struct mmio_handler key = { .addr = gpa };
+    const struct mmio_handler *handler;
+
+    read_lock(&vmmio->lock);
+    handler = bsearch(&key, vmmio->handlers, vmmio->num_entries,
+                      sizeof(*handler), cmp_mmio_handler);
+    if ( handler )
+        *out = *handler;
+    read_unlock(&vmmio->lock);
+
+    return handler != NULL;
+}
+
+static enum io_state try_handle_mmio(mmio_info_t *info)
+{
+    struct vcpu *v = current;
+    struct mmio_handler handler = {};
+
+    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 = fault_addr;
+    info->len = 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 = &d->arch.vmmio;
+    struct mmio_handler *handlers = vmmio->handlers;
+    paddr_t end = addr + size;
+    unsigned int i;
+    int rc = 0;
+    bool overlap;
+
+    if ( !ops || !ops->read || !ops->write || !size || end < addr )
+        return -EINVAL;
+
+    write_lock(&vmmio->lock);
+
+    if ( vmmio->num_entries >= ARRAY_SIZE(vmmio->handlers) )
+    {
+        rc = -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 tail
+     * up by one.
+     */
+    for ( i = 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 = (i > 0 && handlers[i - 1].addr + handlers[i - 1].size > addr) ||
+              (i < vmmio->num_entries && end > handlers[i].addr);
+
+    if ( overlap )
+    {
+        rc = -EEXIST;
+        goto out;
+    }
+
+    memmove(&handlers[i + 1], &handlers[i],
+            (vmmio->num_entries - i) * sizeof(*handlers));
+
+    handlers[i] = (struct mmio_handler){
+        .addr = addr,
+        .size = size,
+        .ops = 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 = 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400930.1636620 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvQ-0008QC-K4; Thu, 27 Aug 2026 15:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a9055fd-2eae-0a2a0a5409dd-0a2a45029cdc-30
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905612-6ca4-0a2a45020019-d155802addd0-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:55 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-499ac87c92bso20713995e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844115-F2CB22AC-6949A792/10/73395122804
X-purgate-type: spam
X-purgate-size: 4299

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 operations")
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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 cpumask_t *cpumask)
 static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask_t *mask)
 {
     unsigned int cpu;
-    uint64_t group_index, base_ppn;
-    uint32_t hhxw, lhxw, hhxs, value;
-    const struct imsic_config *imsic = aplic.imsic_cfg;
+    uint32_t value;
 
     /*
      * TODO: Currently, APLIC is supported only with MSI interrupts.
@@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask
 
     ASSERT(spin_is_locked(&desc->lock));
 
-    cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask));
-    hhxw = imsic->group_index_bits;
-    lhxw = 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 = 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 = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2;
-    base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT;
-
-    /* Update hart and EEID in the target register */
-    group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) &
-                  (BIT(hhxw, UL) - 1);
-    value = desc->irq;
-    value |= cpu << APLIC_TARGET_HART_IDX_SHIFT;
-    value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT);
+    cpu = aplic_get_cpu_from_mask(mask);
+
+    /* Update hart index and EIID in the target register */
+    value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) |
+            (desc->irq & APLIC_TARGET_EIID);
 
     spin_lock(&aplic.lock);
 
diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/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)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:21:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:21:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400932.1636629 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvT-0000Lf-8h; Thu, 27 Aug 2026 15:21:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905605-e002-0a2a0a5209dd-0a2a4506aa28-24
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905611-195a-0a2a45060019-d1558036d9cd-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:53 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-499d1ab3f9dso9565155e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-16d1c6/1787844113-F460277B-28EEC48C/10/73395122804
X-purgate-type: spam
X-purgate-size: 26121

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 <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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 == 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;
 
+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 <xen/irq.h>
 #include <xen/mm.h>
 #include <xen/sections.h>
+#include <xen/sched.h>
 #include <xen/spinlock.h>
 #include <xen/types.h>
 #include <xen/vmap.h>
@@ -28,8 +29,6 @@
 #include <asm/io.h>
 #include <asm/riscv_encoding.h>
 
-#define APLIC_DEFAULT_PRIORITY  1
-
 static struct aplic_priv aplic = {
     .lock = SPIN_LOCK_UNLOCKED,
 };
@@ -38,6 +37,127 @@ static struct intc_info __ro_after_init aplic_info = {
     .hw_variant = INTC_APLIC,
 };
 
+/*
+ * The arrangement of IMSIC interrupt files in MMIO space follows a topology
+ * 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 = 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 number
+ *   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 domain
+ * 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-defined
+ * Hart Index format to ensure correct MSI targeting.
+ */
+static unsigned long aplic_hart_field(unsigned int cpu)
+{
+    const struct imsic_config *imsic = imsic_get_config();
+    const struct imsic_msi *msi = &imsic->msi[cpu];
+    /* Low Hart Index Shift */
+    unsigned int lhxs = imsic->guest_index_bits;
+    /* Low Hart Index Width */
+    unsigned int lhxw = imsic->hart_index_bits;
+    /* High Hart Index Width */
+    unsigned int hhxw = imsic->group_index_bits;
+    /* High Hart Index Shift */
+    unsigned int hhxs =
+        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 address.
+     */
+    paddr_t target_addr = msi->base_addr + msi->offset;
+    unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT;
+    unsigned long g =
+        (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) &
+        APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw);
+    unsigned long h =
+        (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 = vcpu_guest_file_id(target_vcpu);
+    unsigned long hart_field = aplic_hart_field(target_vcpu->processor);
+
+    base_val &= APLIC_TARGET_EIID;
+    base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX);
+    base_val |= 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 = 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 which
          * 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]);
     }
 
     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/asm/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 zero
+ * bit 7 and the reserved bits, has to read back as zero, and BE is WARL and
+ * hardwired to 0 as Xen is little-endian only.
+ */
+#define  APLIC_DOMAINCFG_WMASK          (APLIC_DOMAINCFG_IE | \
+                                         APLIC_DOMAINCFG_DM)
 
 #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
 
 #define APLIC_IDC_SIZE                  32
 
@@ -98,6 +108,27 @@
 #define APLIC_SIZE(nr_cpus) \
     (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus)))
 
+/*
+ * 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 */
 };
 
+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/asm/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;
 
+    /*
+     * 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/asm/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;
 
 struct vaplic_regs {
     uint32_t domaincfg;
+
+    uint32_t *target;
 };
 
 struct vaplic {
     struct vintc vintc;
     struct vaplic_regs regs;
+
+    paddr_t regs_start;
+    unsigned int regs_size;
 };
 
 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 <asm/aia.h>
 #include <asm/imsic.h>
 #include <asm/intc.h>
+#include <asm/mmio.h>
 #include <asm/vaplic.h>
 
 #include "aplic-priv.h"
@@ -27,6 +28,279 @@ unsigned int __ro_after_init guest_aplic_num_sources;
 
 #define FDT_VAPLIC_INT_CELLS 2
 
+#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 also
+ * 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 irqn)
+{
+    const struct vaplic *vaplic = to_vaplic(d);
+
+    /* target[0] doesn't exist so irqn == 0 should be impossible */
+    if ( !irqn || irqn >= 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 = word_idx * sizeof(uint32_t) * BITS_PER_BYTE;
+
+    if ( word_idx >= 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 = curr->domain;
+    const struct vaplic *vaplic = to_vaplic(currd);
+    const unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK;
+    uint32_t auth_mask;
+    unsigned int i;
+
+    ASSERT(curr == current);
+
+    switch ( offset )
+    {
+    case APLIC_DOMAINCFG:
+        *out = 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 = 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 = regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK);
+        auth_mask = 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 = regoffset_to_word_idx(offset - APLIC_GENMSI);
+
+        *out = 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 = 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 = curr->domain;
+    unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK;
+
+    ASSERT(curr == 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 =
+            regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK);
+
+        value &= 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 = to_vaplic(currd);
+        struct vcpu *target_vcpu;
+        unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX);
+        /*
+         * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is
+         * subtracted.
+         */
+        unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI);
+
+        if ( !AUTH_IRQ_BIT(currd, srcn) )
+            /* Interrupt not enabled, ignore it */
+            return true;
+
+        target_vcpu = 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 file of
+             * nested guest. The vIMSIC node has no riscv,guest-index-bits
+             * property, so a guest is told its harts have no guest interrupt
+             * files and the field is read-only zero for them. The write isn'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 != 0 is unsupported\n",
+                            currd);
+
+                /* Ignore such writes ... */
+                return true;
+            }
+
+            write_atomic(&vaplic->regs.target[srcn], value);
+
+            value = aplic_msi_target_gen(target_vcpu, value);
+        }
+        else
+        {
+            /*
+             * IPRIO is WARL and zero isn't a legal value for it, so normalize
+             * it once: the guest then reads back exactly what it gets.
+             */
+            unsigned int iprio = MASK_EXTR(value, APLIC_TARGET_IPRIO) ?:
+                                 APLIC_TARGET_IPRIO_DEFAULT;
+            unsigned long h = cpuid_to_hartid(guest_hart_idx);
+
+            value = MASK_INSR(guest_hart_idx, APLIC_TARGET_HART_IDX) |
+                    MASK_INSR(iprio, APLIC_TARGET_IPRIO);
+
+            write_atomic(&vaplic->regs.target[srcn], value);
+
+            value = 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 = to_vaplic(currd);
+
+        vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO |
+                                 (value & APLIC_DOMAINCFG_WMASK);
+
+        return true;
+    }
+
+    default:
+    fail:
+        gdprintk(XENLOG_WARNING,
+                 "Unhandled APLIC write at offset %#x (value %#x)\n", offset,
+                 value);
+
+        return false;
+    }
+
+    aplic_hw_write_reg(offset, value);
+
+    return true;
+}
+
 static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *kinfo)
 {
     struct domain *d = kinfo->bd.d;
@@ -95,6 +369,56 @@ static const struct vintc_init_ops __initconstrel init_ops = {
     .make_domu_dt_node = vaplic_make_domu_dt_node,
 };
 
+static enum io_state cf_check vaplic_mmio_read(struct vcpu *v,
+                                               mmio_info_t *info)
+{
+    uint32_t val;
+
+    ASSERT(v == current);
+
+    if ( info->len != sizeof(uint32_t) ||
+         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
+    {
+        gdprintk(XENLOG_DEBUG,
+                 "VAPLIC: unaligned/wrong-width read gpa=%"PRIpaddr" len=%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 = val;
+
+    return IO_HANDLED;
+}
+
+static enum io_state cf_check vaplic_mmio_write(struct vcpu *v,
+                                                const mmio_info_t *info)
+{
+    ASSERT(v == current);
+
+    if ( info->len != sizeof(uint32_t) ||
+         !IS_ALIGNED(info->gpa, sizeof(uint32_t)) )
+    {
+        gdprintk(XENLOG_DEBUG,
+                 "VAPLIC: unaligned/wrong-width write gpa=%"PRIpaddr" len=%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 = {
+    .read  = vaplic_mmio_read,
+    .write = vaplic_mmio_write,
+};
+
 static const struct vintc_ops vintc_ops = {
     .vcpu_init = vcpu_imsic_init,
     .vcpu_deinit = vcpu_imsic_deinit,
@@ -103,6 +427,7 @@ static const struct vintc_ops vintc_ops = {
 int domain_vaplic_init(struct domain *d)
 {
     struct vaplic *vaplic = xvzalloc(struct vaplic);
+    int rc;
 
     if ( !vaplic )
         return -ENOMEM;
@@ -122,7 +447,29 @@ int domain_vaplic_init(struct domain *d)
      */
     d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1;
 
-    return 0;
+    /* Slot 0 is unused: APLIC source numbering starts at 1 (see used_irqs). */
+    vaplic->regs.target = xvzalloc_array(uint32_t, d->arch.vintc->nr_virqs);
+    if ( !vaplic->regs.target )
+    {
+        d->arch.vintc = NULL;
+        xvfree(vaplic);
+
+        return -ENOMEM;
+    }
+
+    vaplic->regs_start = GUEST_APLIC_S_BASE;
+    vaplic->regs_size = APLIC_SIZE(d->max_vcpus);
+
+    rc = register_mmio_handler(d, &vaplic_mmio_ops,
+                               vaplic->regs_start, vaplic->regs_size);
+    if ( rc )
+    {
+        d->arch.vintc = NULL;
+        xvfree(vaplic->regs.target);
+        xvfree(vaplic);
+    }
+
+    return rc;
 }
 
 void domain_vaplic_deinit(struct domain *d)
@@ -134,5 +481,6 @@ void domain_vaplic_deinit(struct domain *d)
 
     vaplic = to_vaplic(d);
     d->arch.vintc = NULL;
+    xvfree(vaplic->regs.target);
     xvfree(vaplic);
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400938.1636639 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvV-0000jy-Tl; Thu, 27 Aug 2026 15:22:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905609-8faa-0a2a0a5109dd-0a2a4505b4fe-28
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905617-4cb1-0a2a45050019-d1558031d407-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:21:59 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-49954b88fffso19307055e9.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <a36ddb794b06ec9b7c470d9e665126989f4db58a.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787844119-73ABF2A1-270AB87B/10/73395122804
X-purgate-type: spam
X-purgate-size: 1612

Use convient helper instead of open-coding the things.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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 = {
     .hw_variant = INTC_APLIC,
 };
 
+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 topology
  * 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());
 
     ASSERT(spin_is_locked(&desc->lock));
 
@@ -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());
 
     ASSERT(spin_is_locked(&desc->lock));
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400940.1636646 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvX-0000z1-6F; Thu, 27 Aug 2026 15:22:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905610-e002-0a2a0a5209dd-0a2a450bc196-10
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905619-b7e8-0a2a450b0019-d155802fed17-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:01 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4998b5a63e2so21331925e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787844121-1A6DA9EA-2496DA3C/10/73395122804
X-purgate-type: spam
X-purgate-size: 19797

Implement context_switch() and the helpers it needs: save/restore of
H/VS CSRs, virtual timer and P2M context, and __context_switch() in assembly,
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 <oleksii.kurochko@gmail.com>
---
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 <asm/bitops.h>
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
+#include <asm/current.h>
 #include <asm/intc.h>
 #include <asm/mmio.h>
 #include <asm/riscv_encoding.h>
+#include <asm/vmid.h>
 #include <asm/vtimer.h>
 
 struct csr_masks {
@@ -158,6 +160,8 @@ int arch_vcpu_create(struct vcpu *v)
     if ( is_idle_vcpu(v) )
         return 0;
 
+    v->arch.last_cpu = NR_CPUS;
+
     vcpu_csr_init(v);
 
     if ( (rc = vcpu_vtimer_init(v)) )
@@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d,
     return rc;
 }
 
+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 = csr_read(CSR_HEDELEG);
+     * vcpu->arch.hideleg = csr_read(CSR_HIDELEG);
+     * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG);
+     * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN);
+     * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA);
+     *
+     * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) )
+     *     vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0);
+     */
+
+    vcpu->arch.hvip = csr_read(CSR_HVIP);
+
+    vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS);
+    vcpu->arch.vsie = csr_read(CSR_VSIE);
+    vcpu->arch.vstvec = csr_read(CSR_VSTVEC);
+    vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH);
+    vcpu->arch.vscause = csr_read(CSR_VSCAUSE);
+    vcpu->arch.vstval = csr_read(CSR_VSTVAL);
+    vcpu->arch.vsepc = 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 pool.
+     * 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 != 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 = smp_processor_id();
+
+    ASSERT(prev != 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 != 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 may
+         * 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(&current->dirty_cpu, cpu);
+
+    ctxt_switch_to(current);
+
+    write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN);
+
+    current->arch.last_cpu = 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 != next);
+    ASSERT(!vcpu_cpu_dirty(next));
+
+    local_irq_disable();
+
+    set_current(next);
+
+    prev = __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:
 
         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/asm/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;
 
+    /*
+     * 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;
 
     register_t vsatp;
+    register_t vscause;
+    register_t vsepc;
+    register_t vsie;
+    register_t vsscratch;
+    register_t vsstatus;
+    register_t vstval;
+    register_t vstvec;
 
     /*
      * 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_domain *p2m, gfn_t gfn,
 
 void p2m_ctxt_switch_from(struct vcpu *p);
 void p2m_ctxt_switch_to(struct vcpu *n);
-void p2m_handle_vmenter(void);
 
 #endif /* ASM__RISCV__P2M_H */
 
diff --git a/xen/arch/riscv/include/asm/system.h b/xen/arch/riscv/include/asm/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)
 
 #define arch_fetch_and_add(x, v) __sync_fetch_and_add(x, v)
 
+struct vcpu;
+
+struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next);
+
 #endif /* __ASSEMBLER__ */
 
 #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 = csr_swap(CSR_VSATP, 0);
 
     /*
-     * 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().
      */
 }
 
@@ -1524,15 +1523,21 @@ void p2m_ctxt_switch_from(struct vcpu *p)
 void p2m_ctxt_switch_to(struct vcpu *n)
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(n->domain);
+    bool need_flush;
 
     if ( is_idle_vcpu(n) )
         return;
 
+    need_flush = 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();
 
     csr_write(CSR_VSATP, n->arch.vsatp);
 
@@ -1548,48 +1553,6 @@ void p2m_ctxt_switch_to(struct vcpu *n)
     flush_tlb_guest_local();
 }
 
-void p2m_handle_vmenter(void)
-{
-    struct vcpu *curr = current;
-    struct p2m_domain *p2m = p2m_get_hostp2m(curr->domain);
-    struct vcpu_vmid *p_vmid = &curr->arch.vmid;
-    unsigned short old_vmid, new_vmid;
-    bool need_flush;
-
-    BUG_ON(is_idle_vcpu(curr));
-
-    old_vmid = p_vmid->vmid;
-    need_flush = vmid_handle_vmenter(p_vmid);
-    new_vmid = 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 updating
-     * HGATP, as VSATP is not modified here.
-     */
-    if ( old_vmid != 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 VMID
-     * 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, which
-     * 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 set
-     * 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
 
+#include <xen/sched.h>
+#include <xen/types.h>
+
 #include <asm/current.h>
 #include <asm/processor.h>
-#include <xen/types.h>
 
 #define DEFINE(_sym, _val)                                                 \
     asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\
@@ -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)
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
-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);
 
     vcpu_flush_interrupts(curr);
-
-    p2m_handle_vmenter();
 }
 
 static void timer_interrupt(void)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400943.1636656 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvZ-0001J2-0a; Thu, 27 Aug 2026 15:22:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90560b-2eae-0a2a0a5409dd-0a2a45048a6e-44
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90561a-b57f-0a2a45040019-d155802dd03a-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:03 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49b392ccaacso11904575e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787844123-52ECEB50-08C9A4FF/10/73395122804
X-purgate-type: spam
X-purgate-size: 4978

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 <oleksii.kurochko@gmail.com>
---
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;
 }
 
+/*
+ * 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 clear
+ * 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 = csr_read(CSR_HVIP);
 
     vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS);
-    vcpu->arch.vsie = csr_read(CSR_VSIE);
+    vcpu->arch.vsie = csr_read64(CSR_VSIE);
     vcpu->arch.vstvec = csr_read(CSR_VSTVEC);
     vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH);
     vcpu->arch.vscause = csr_read(CSR_VSCAUSE);
     vcpu->arch.vstval = csr_read(CSR_VSTVAL);
     vcpu->arch.vsepc = csr_read(CSR_VSEPC);
+
+    if ( vcpu_has_aia_state(vcpu, SMSTATEEN0_SVSLCT) )
+        vcpu->arch.vsiselect = csr_read(CSR_VSISELECT);
+
+    if ( vcpu_has_aia_state(vcpu, SMSTATEEN0_AIA) )
+    {
+        vcpu->arch.hviprio1 = csr_read64(CSR_HVIPRIO1);
+        vcpu->arch.hviprio2 = csr_read64(CSR_HVIPRIO2);
+    }
 }
 
 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);
 
     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);
+    }
 }
 
 static void ctxt_switch_from(struct vcpu *p)
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/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;
 
     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;
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400944.1636664 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbva-0001b9-HZ; Thu, 27 Aug 2026 15:22:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90560c-bab6-0a2a0a5309dd-0a2a450c9cc8-38
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90561c-f479-0a2a450c0019-d1558036a425-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:04 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-49b0eab380eso10265215e9.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787844124-026DEA5B-2FCEC2F6/10/73395122804
X-purgate-type: spam
X-purgate-size: 2995

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 <oleksii.kurochko@gmail.com>
---
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)
 
     vtimer_ctxt_switch_from(p);
 
+    vintc_ctxt_switch_from(p);
+
     save_csr_regs(p);
 }
 
@@ -462,6 +464,8 @@ static void ctxt_switch_to(struct vcpu *n)
 
     vtimer_ctxt_switch_to(n);
 
+    vintc_ctxt_switch_to(n);
+
     restore_csr_regs(n);
 
     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 {
 
     /* 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);
 };
 
 struct vintc {
@@ -91,4 +97,7 @@ void domain_vintc_deinit(struct domain *d);
 
 int vintc_reserve_virq(const struct domain *d, unsigned int virq);
 
+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 domain *d,
 
     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 = v->domain->arch.vintc->ops;
+
+    ops->ctxt_switch_from(v);
+}
+
+void vintc_ctxt_switch_to(struct vcpu *v)
+{
+    const struct vintc_ops *ops = v->domain->arch.vintc->ops;
+
+    ops->ctxt_switch_to(v);
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400946.1636674 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvc-00021q-Pk; Thu, 27 Aug 2026 15:22:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905610-e002-0a2a0a5209dd-0a2a450bc196-20
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90561d-b7e8-0a2a450b0019-d1558032ec2b-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:05 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49b0d8bc2aaso14161565e9.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787844125-AB8D19EA-408F7B20/10/73395122804
X-purgate-type: spam
X-purgate-size: 4894

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 <Romain.Caritey@microchip.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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 <xen/init.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/macros.h>
+#include <xen/rwlock.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/spinlock.h>
@@ -342,6 +343,28 @@ static int __init imsic_parse_node(const struct dt_device_node *node,
     return 0;
 }
 
+void cf_check imsic_ctxt_switch_from(struct vcpu *v)
+{
+    struct vimsic_state *imsic_state = v->arch.vimsic_state;
+    unsigned long flags;
+
+    /*
+     * A vCPU using the s/w IMSIC VS-file (guest_file_id == 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 = 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/asm/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);
 
 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);
+
 #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 = {
 static const struct vintc_ops vintc_ops = {
     .vcpu_init = vcpu_imsic_init,
     .vcpu_deinit = 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 restore
+     * is always the IMSIC one.
+     */
+    .ctxt_switch_from = imsic_ctxt_switch_from,
+    .ctxt_switch_to = imsic_ctxt_switch_to,
 };
 
 int domain_vaplic_init(struct domain *d)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400948.1636682 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbve-0002N5-9r; Thu, 27 Aug 2026 15:22:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905614-8faa-0a2a0a5109dd-0a2a450ad1c4-38
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90561e-f2d2-0a2a450a0019-d155802fe9a1-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:07 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-499840a2575so14645945e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787844127-536D6CFC-5493F82D/10/73395122804
X-purgate-type: spam
X-purgate-size: 13807

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 <oleksii.kurochko@gmail.com>
---
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 == 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) == 0 rather than
   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 <xen/sort.h>
 #include <xen/virtual_region.h>
 
+#include <asm/csr.h>
 #include <asm/extable.h>
 #include <asm/processor.h>
+#include <asm/traps.h>
 
 #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field)
 
@@ -32,6 +34,12 @@ static void __init cf_check swap_ex(void *a, void *b)
 
     x->fixup = y->fixup + delta;
     y->fixup = tmp.fixup - delta;
+
+    x->type = y->type;
+    y->type = tmp.type;
+
+    x->data = y->data;
+    y->data = tmp.data;
 }
 
 static int cf_check cmp_ex(const void *a, const void *b)
@@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex,
     regs->sepc = ex_fixup(ex);
 }
 
-bool fixup_exception(struct cpu_user_regs *regs)
+#define CHECK_GPR_INDEX(num, name)                      \
+    BUILD_BUG_ON(offsetof(struct cpu_user_regs, name)   \
+                 != (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 order,
+     * 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 =
+        (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 = regs->sepc;
+    trap_info->scause = cause;
+    trap_info->stval = csr_read(CSR_STVAL);
+
+    regs->sepc = ex_fixup(ex);
+}
+
+bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause)
 {
     unsigned long pc = regs->sepc;
     const struct virtual_region *region = find_text_region(pc);
@@ -77,7 +127,23 @@ bool fixup_exception(struct cpu_user_regs *regs)
     if ( !ex )
         return false;
 
-    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;
+    }
 
     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
 
+#include <asm/gpr-num.h>
+
+#define EX_TYPE_FIXUP       0
+#define EX_TYPE_TRAP_INFO   1
+
 #ifdef __ASSEMBLER__
 
-#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
 
-.macro asm_extable, insn, fixup
-    ASM_EXTABLE(\insn, \fixup)
+.macro _asm_extable, insn, fixup
+    ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0)
 .endm
 
 #else /* __ASSEMBLER__ */
@@ -23,20 +30,36 @@
 
 struct cpu_user_regs;
 
-#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"
 
+#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;
 };
 
 extern struct exception_table_entry __start___ex_table[];
 extern struct exception_table_entry __stop___ex_table[];
 
 void sort_exception_tables(void);
-bool fixup_exception(struct cpu_user_regs *regs);
+bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause);
 
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLER__ */
 
 #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_<name> 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/include/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 @@
 
 #ifndef __ASSEMBLER__
 
-/* 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 saved
+ * 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 always
+ * 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/asm/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 @@
 
 #ifndef __ASSEMBLER__
 
+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;
         }
 
-        if ( fixup_exception(cpu_regs) )
+        if ( fixup_exception(cpu_regs, cause) )
             break;
 
         fallthrough;
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:11 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400950.1636686 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvf-0002Wq-3P; Thu, 27 Aug 2026 15:22:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90561c-e002-0a2a0a5209dd-0a2a45079110-14
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905620-b4ea-0a2a45070019-d155802fed7f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:08 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-4998b5a63e2so21333645e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787844128-354C3AE4-75A4F469/10/73395122804
X-purgate-type: spam
X-purgate-size: 3046

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=32 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 <oleksii.kurochko@gmail.com>
---
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/include/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
 
-#if __riscv_xlen == 64
-
 /* 64-bit read for VS-stage address translation (RV64) */
-#define INSN_PSEUDO_VS_LOAD		0x00003000
+#define INSN_PSEUDO_VS_LOAD64		0x00003000
 
 /* 64-bit write for VS-stage address translation (RV64) */
-#define INSN_PSEUDO_VS_STORE	0x00003020
-
-#elif __riscv_xlen == 32
+#define INSN_PSEUDO_VS_STORE64		0x00003020
 
 /* 32-bit read for VS-stage address translation (RV32) */
-#define INSN_PSEUDO_VS_LOAD		0x00002000
+#define INSN_PSEUDO_VS_LOAD32		0x00002000
 
 /* 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
 
 #define INSN_16BIT_MASK			0x3
 #define INSN_32BIT_MASK			0x1c
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:12 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400953.1636694 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvg-0002q8-KG; Thu, 27 Aug 2026 15:22:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905616-2eae-0a2a0a5409dd-0a2a4501a8e6-32
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905621-5984-0a2a45010019-d1558032e01e-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:09 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-49b8e527d63so6385605e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787844129-C4359757-CAD6905E/10/73395122804
X-purgate-type: spam
X-purgate-size: 12235

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 <oleksii.kurochko@gmail.com>
---
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 += domain.o
 obj-y += domain-build.init.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
+obj-y += emulate.o
 obj-y += entry.o
 obj-y += extable.o
 obj-y += 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 <xen/bug.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/types.h>
+
+#include <asm/csr.h>
+#include <asm/current.h>
+#include <asm/emulate.h>
+#include <asm/riscv_encoding.h>
+#include <asm/traps.h>
+
+/*
+ * The hardware-reported details of a guest page fault, gathered once by
+ * handle_guest_page_fault() and passed down to the emulation of the faulted
+ * 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 translation?
+ *
+ * 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 = {};
+
+    switch ( gf->cause )
+    {
+    case CAUSE_FETCH_GUEST_PAGE_FAULT:
+        utrap.scause = CAUSE_FETCH_ACCESS;
+        break;
+
+    case CAUSE_LOAD_GUEST_PAGE_FAULT:
+        utrap.scause = CAUSE_LOAD_ACCESS;
+        break;
+
+    case CAUSE_STORE_GUEST_PAGE_FAULT:
+        utrap.scause = CAUSE_STORE_ACCESS;
+        break;
+
+    default:
+        domain_crash(current->domain, "Impossible cause (%#lx) in %s?\n",
+                     gf->cause, __func__);
+        return;
+    }
+
+    utrap.sepc = gf->regs->sepc;
+    utrap.stval = gf->stval;
+
+    trap_redirect(&utrap);
+}
+
+void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cause)
+{
+    struct guest_fault gf = {
+        .regs = regs,
+        .cause = cause,
+        .htinst = csr_read(CSR_HTINST),
+        .htval = csr_read(CSR_HTVAL),
+        .stval = csr_read(CSR_STVAL),
+        .gpa = 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 recognized
+     * by htinst_is_pseudo(), and the fault requires separate handling (since
+     * 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 = emulate_load(&gf);
+        break;
+
+    case CAUSE_STORE_GUEST_PAGE_FAULT:
+        rc = emulate_store(&gf);
+        break;
+
+    case CAUSE_FETCH_GUEST_PAGE_FAULT:
+        /*
+         * Guest is trying to reach unmapped/unpopulated or G-stage PTE doesn't
+         * allow execution (X=0). Generate fetch fault in this case.
+         */
+        inject_access_fault(&gf);
+        rc = 0;
+        break;
+
+    default:
+        rc = -EOPNOTSUPP;
+        ASSERT_UNREACHABLE();
+        break;
+    }
+
+    if ( rc )
+        domain_crash(current->domain,
+                     "%s: unable to handle guest page fault (cause=%#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 cause);
+
+#endif /* RISCV_EMULATE_H */
diff --git a/xen/arch/riscv/include/asm/traps.h b/xen/arch/riscv/include/asm/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);
 
+/* Reflect @trap back to the guest, i.e. enter its VS-mode trap handler. */
+void trap_redirect(const struct trap_info *trap);
+
 #endif /* __ASSEMBLER__ */
 
 #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 @@
 
 #include <asm/extable.h>
 #include <asm/cpufeature.h>
+#include <asm/emulate.h>
 #include <asm/intc.h>
 #include <asm/processor.h>
 #include <asm/riscv_encoding.h>
@@ -193,6 +194,7 @@ void do_trap(struct cpu_user_regs *cpu_regs)
 {
     register_t pc = cpu_regs->sepc;
     unsigned long cause = csr_read(CSR_SCAUSE);
+    bool from_guest = cpu_regs->hstatus & HSTATUS_SPV;
 
     switch ( cause )
     {
@@ -203,6 +205,19 @@ void do_trap(struct cpu_user_regs *cpu_regs)
         vsbi_handle_ecall(cpu_regs);
         break;
 
+    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) >= 0 )
         {
@@ -251,7 +266,7 @@ void do_trap(struct cpu_user_regs *cpu_regs)
         break;
     }
 
-    if ( cpu_regs->hstatus & HSTATUS_SPV )
+    if ( from_guest )
         check_for_pcpu_work();
 }
 
@@ -275,3 +290,9 @@ enum mc_disposition arch_do_multicall_call(struct mc_state *state)
     BUG_ON("unimplemented");
     return mc_continue;
 }
+
+/* Redirect trap to Guest. */
+void trap_redirect(const struct trap_info *trap)
+{
+    BUG_ON("unimplemented");
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400957.1636703 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvi-0003Bk-D2; Thu, 27 Aug 2026 15:22:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90561e-2eae-0a2a0a5409dd-0a2a4502cbb6-14
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905623-6ca4-0a2a45020019-d155dd30cc50-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:11 +0200
Received: by mail-wr1-f48.google.com with SMTP id
 ffacd0b85a97d-47f633e6058so1725209f8f.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844131-309C32AC-D8EDFA32/10/73395122804
X-purgate-type: spam
X-purgate-size: 5239

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 <oleksii.kurochko@gmail.com>
---
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/include/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
 
+/* 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_state *state)
 /* Redirect trap to Guest. */
 void trap_redirect(const struct trap_info *trap)
 {
-    BUG_ON("unimplemented");
+    struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current);
+    unsigned long vsstatus = 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 &= ~SSTATUS_SPP;
+    if ( regs->sstatus & SSTATUS_SPP )
+        vsstatus |= SSTATUS_SPP;
+
+    /* Change Guest SSTATUS.SPIE bit */
+    vsstatus &= ~SSTATUS_SPIE;
+    if ( vsstatus & SSTATUS_SIE )
+        vsstatus |= SSTATUS_SPIE;
+
+    /* Clear Guest SSTATUS.SIE bit */
+    vsstatus &= ~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 = csr_read(CSR_VSTVEC) & STVEC_BASE_MASK;
+
+    /* Set Guest privilege mode to supervisor */
+    regs->sstatus |= SSTATUS_SPP;
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400960.1636709 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvj-0003Q8-RX; Thu, 27 Aug 2026 15:22:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905616-2eae-0a2a0a5409dd-0a2a4501a8e6-44
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905624-5984-0a2a45010019-d155dd34dcb0-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:12 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47f92e3c14bso1868714f8f.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787844132-1E27A757-2AF5C80E/10/73395122804
X-purgate-type: spam
X-purgate-size: 2034

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 <oleksii.kurochko@gmail.com>
---
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[] = {
     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/include/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,
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400962.1636718 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvl-0003s0-UI; Thu, 27 Aug 2026 15:22:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905616-2eae-0a2a0a5409dd-0a2a4501a8e6-48
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905626-5984-0a2a45010019-d1558030b0f2-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:14 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49b0dbfbf7bso9579045e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address
Date: Thu, 27 Aug 2026 17:21:05 +0200
Message-ID: <c7975a131c229c721b2d4fe81c13fecd8deb4329.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787844134-1F66C757-BC7A22B6/10/73395122804
X-purgate-type: spam
X-purgate-size: 3536

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 <oleksii.kurochko@gmail.com>
---
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 <xen/sched.h>
 #include <xen/types.h>
 
+#include <asm/cpufeature.h>
 #include <asm/csr.h>
 #include <asm/current.h>
 #include <asm/emulate.h>
@@ -62,10 +63,28 @@ static bool htinst_is_pseudo(unsigned long htinst)
     }
 }
 
-/* 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 Shtvala
+     * tells the two apart.
+     *
+     * TODO: where it is absent, recover the address in software rather than
+     * 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 explicit
+     * access they are those of the faulting guest virtual address in stval,
+     * and for an implicit access made for VS-stage translation they are zero.
+     */
+    gf->gpa = ((paddr_t)gf->htval << 2) |
+              (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3));
 }
 
 static int emulate_load(const struct guest_fault *gf)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400966.1636724 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvn-00044q-B0; Thu, 27 Aug 2026 15:22:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905627-8faa-0a2a0a5109dd-0a2a450bdcc6-0
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905627-b7e8-0a2a450b0019-d155802eb420-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:15 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49b14637dfdso5514575e9.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 22/39] xen/riscv: add guest memory read helper
Date: Thu, 27 Aug 2026 17:21:06 +0200
Message-ID: <b68a29b7ef5b2cb83fde405b3854c94a2f44f4d0.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1787844135-194C39EA-EDA43B15/10/73395122804
X-purgate-type: spam
X-purgate-size: 6481

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 <oleksii.kurochko@gmail.com>
---
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 perform
   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 <xen/string.h>
 
 #include <asm/guest_access.h>
+#include <asm/traps.h>
 
 #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, paddr_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 read
+ *
+ * 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. encodings
+ * wider than 32 bits are not supported. Such an encoding cannot be completed
+ * 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 = ~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] "=&r" (tmp), [addr] "+&r" (guest_addr),
+          "+m" (*trap)
+        : [ti] "r" (trap) );
+
+        /*
+         * Although HLVX instructions' explicit memory accesses require execute
+         * permissions, they still raise the same exceptions as other load
+         * instructions, rather than raising fetch exceptions instead.
+         */
+        if ( trap->scause == CAUSE_LOAD_PAGE_FAULT )
+            trap->scause = 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;
+}
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400971.1636734 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvp-0004au-Rt; Thu, 27 Aug 2026 15:22:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905628-2eae-0a2a0a5409dd-0a2a4503e5b2-2
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905629-fae8-0a2a45030019-d1558035c14f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:17 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-49b8687630fso5775785e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <c8c767e5932057e1fe3ca7756246ded691adad4f.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787844137-75EFF4E9-AF1765B4/10/73395122804
X-purgate-type: spam
X-purgate-size: 3676

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 <oleksii.kurochko@gmail.com>
---
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 = csr_read(CSR_SCAUSE);
     bool from_guest = cpu_regs->hstatus & HSTATUS_SPV;
 
+    /*
+     * A synchronous trap taken in Xen context may come from an access done 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 caller
+     * and resume execution past the faulting instruction.
+     *
+     * Traps taken from the guest must never be fixed up: sepc is then a guest
+     * 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 happens
+     * to be listed in the exception table would otherwise be "fixed up" as 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);
 
         vsbi_handle_ecall(cpu_regs);
         break;
@@ -232,9 +255,6 @@ void do_trap(struct cpu_user_regs *cpu_regs)
             break;
         }
 
-        if ( fixup_exception(cpu_regs, cause) )
-            break;
-
         fallthrough;
     default:
         if ( cause & CAUSE_IRQ_FLAG )
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400975.1636742 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvt-0005LN-Gr; Thu, 27 Aug 2026 15:22:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905620-8faa-0a2a0a5109dd-0a2a45098620-28
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90562a-be1a-0a2a45090019-d1558036b129-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:18 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-499ae1c6471so14455615e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787844138-BEAD8034-41E1D51C/10/73395122804
X-purgate-type: spam
X-purgate-size: 15769

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 <oleksii.kurochko@gmail.com>
---
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 @@
  */
 
 #include <xen/bug.h>
+#include <xen/compiler.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <xen/types.h>
@@ -13,9 +14,29 @@
 #include <asm/csr.h>
 #include <asm/current.h>
 #include <asm/emulate.h>
+#include <asm/guest_access.h>
+#include <asm/processor.h>
 #include <asm/riscv_encoding.h>
 #include <asm/traps.h>
 
+/*
+ * Determine the trapped load or store instruction which caused a guest MMIO
+ * 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 faulted
@@ -39,6 +60,71 @@ struct guest_fault {
     paddr_t gpa;
 };
 
+static bool is_load_guest_page_fault(unsigned long scause)
+{
+    return scause == CAUSE_LOAD_GUEST_PAGE_FAULT;
+}
+
+static __maybe_unused void advance_pc(struct cpu_user_regs *regs,
+                                      unsigned int step)
+{
+    regs->sepc += 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 the
+ * 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 configure.
+ *
+ * It is needed to decode a trapped instruction: the encodings which exist only
+ * for XLEN=64 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 == 64 only, the field not existing on RV32 in the first place.
+ */
+static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *regs)
+{
+#ifdef CONFIG_RISCV_32
+    return 32;
+#else
+    unsigned long xl = MASK_EXTR(regs->hstatus, HSTATUS_VSXL);
+
+    if ( (xl == XLEN_FIELD_64) && !(regs->sstatus & SSTATUS_SPP) )
+        xl = 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 left 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. quietly
+         * 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 translation?
@@ -87,6 +173,250 @@ static void resolve_faulting_gpa(struct guest_fault *gf)
               (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3));
 }
 
+/*
+ * 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 the
+ * caller to do. Where it returns false, @di has been filled in and emulation
+ * is to continue.
+ */
+static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf,
+                                              struct decoded_insn *di)
+{
+    unsigned long htinst = 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 such 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] == 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] set 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 compressed
+         * instruction is read from guest memory as is: a trapped one arrives
+         * 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 comes
+         * as the zero special value handled below.
+         */
+        di->insn = htinst | INSN_16BIT_MASK;
+        di->insn_len = (htinst & BIT(1, UL)) ? 4 : 2;
+    }
+    else
+    {
+        const struct cpu_user_regs *regs = gf->regs;
+        struct trap_info utrap = {};
+
+        /*
+         * Bit[0] == 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 = 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 = CAUSE_FETCH_ACCESS;
+
+            utrap.sepc = 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 have
+         * 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 = regs->sepc;
+            utrap.scause = 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 = 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=64 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 = di->insn;
+    /* Register fields of the uncompressed forms ... */
+    unsigned int rd = RV_RD(insn);
+    unsigned int rs2 = 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 one.
+     */
+    unsigned int rs2s = RVC_RS2S(insn);
+    unsigned int rs2c = RVC_RS2(insn);
+
+    di->is_write = false;
+    di->is_unsigned = false;
+    di->reg = rd;
+
+    if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
+        di->len = 1;
+    else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
+    {
+        di->len = 1;
+        di->is_unsigned = true;
+    }
+    else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
+        di->len = 2;
+    else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
+    {
+        di->len = 2;
+        di->is_unsigned = true;
+    }
+    else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
+        di->len = 4;
+    else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU )
+    {
+        di->len = 4;
+        di->is_unsigned = true;
+    }
+    else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW )
+    {
+        di->len = 4;
+        di->reg = rs2s;
+    }
+    /* c.lwsp and c.ldsp are reserved with rd being x0. */
+    else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd )
+        di->len = 4;
+    else if ( xlen == 64 && (insn & INSN_MASK_LD) == INSN_MATCH_LD )
+        di->len = 8;
+    else if ( xlen == 64 && (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD )
+    {
+        di->len = 8;
+        di->reg = rs2s;
+    }
+    else if ( xlen == 64 && (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP &&
+              rd )
+        di->len = 8;
+    else if ( (insn & INSN_MASK_SB) == INSN_MATCH_SB )
+    {
+        di->len = 1;
+        di->is_write = true;
+        di->reg = rs2;
+    }
+    else if ( (insn & INSN_MASK_SH) == INSN_MATCH_SH )
+    {
+        di->len = 2;
+        di->is_write = true;
+        di->reg = rs2;
+    }
+    else if ( (insn & INSN_MASK_SW) == INSN_MATCH_SW )
+    {
+        di->len = 4;
+        di->is_write = true;
+        di->reg = rs2;
+    }
+    else if ( (insn & INSN_MASK_C_SW) == INSN_MATCH_C_SW )
+    {
+        di->len = 4;
+        di->is_write = true;
+        di->reg = rs2s;
+    }
+    else if ( (insn & INSN_MASK_C_SWSP) == INSN_MATCH_C_SWSP )
+    {
+        di->len = 4;
+        di->is_write = true;
+        di->reg = rs2c;
+    }
+    else if ( xlen == 64 && (insn & INSN_MASK_SD) == INSN_MATCH_SD )
+    {
+        di->len = 8;
+        di->is_write = true;
+        di->reg = rs2;
+    }
+    else if ( xlen == 64 && (insn & INSN_MASK_C_SD) == INSN_MATCH_C_SD )
+    {
+        di->len = 8;
+        di->is_write = true;
+        di->reg = rs2s;
+    }
+    else if ( xlen == 64 && (insn & INSN_MASK_C_SDSP) == INSN_MATCH_C_SDSP )
+    {
+        di->len = 8;
+        di->is_write = true;
+        di->reg = 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/include/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 <xen/types.h>
 
 struct domain;
+struct trap_info;
 
 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);
 
+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/include/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
 
+/*
+ * 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 == 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)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400977.1636751 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvv-0005du-5m; Thu, 27 Aug 2026 15:22:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905621-2eae-0a2a0a5409dd-0a2a450aa854-18
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90562b-f2d2-0a2a450a0019-d1558033ed2a-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:19 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-4998b5a63e2so21336015e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787844139-53CD3CFC-BDF5C5AC/10/73395122804
X-purgate-type: spam
X-purgate-size: 6912

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 <oleksii.kurochko@gmail.com>
---
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=64-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 ambiguous
   there: 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.
 - 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 @@
  */
 
 #include <xen/bug.h>
-#include <xen/compiler.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <xen/types.h>
@@ -15,6 +14,7 @@
 #include <asm/current.h>
 #include <asm/emulate.h>
 #include <asm/guest_access.h>
+#include <asm/mmio.h>
 #include <asm/processor.h>
 #include <asm/riscv_encoding.h>
 #include <asm/traps.h>
@@ -65,8 +65,7 @@ static bool is_load_guest_page_fault(unsigned long scause)
     return scause == CAUSE_LOAD_GUEST_PAGE_FAULT;
 }
 
-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 += step;
 }
@@ -88,7 +87,7 @@ static __maybe_unused void advance_pc(struct cpu_user_regs *regs,
  * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for
  * __riscv_xlen == 64 only, the field not existing on RV32 in the first 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 reg)
 {
     ASSERT(reg < 32);
 
@@ -197,8 +195,8 @@ static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs,
  * caller to do. Where it returns false, @di has been filled in and emulation
  * 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 = gf->htinst;
 
@@ -306,8 +304,7 @@ static bool __maybe_unused insn_fetch_faulted(const struct 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 = di->insn;
     /* Register fields of the uncompressed forms ... */
@@ -419,7 +416,41 @@ static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di,
 
 static int emulate_load(const struct guest_fault *gf)
 {
-    return -EOPNOTSUPP;
+    struct cpu_user_regs *regs = gf->regs;
+    mmio_info_t info = { .is_write = false };
+    struct decoded_insn di;
+    unsigned int shift = 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 = BITS_PER_BYTE * (sizeof(unsigned long) - di.len);
+
+#ifdef EMULATE_LOAD_DEBUG
+    gdprintk(XENLOG_DEBUG, "pc=%#lx, addr=%#"PRIpaddr", len=%u, shift=%u\n",
+             regs->sepc, gf->gpa, di.len, shift);
+#endif
+
+    rc = 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 elsewhere.
+     */
+    if ( di.reg )
+        *guest_gpr(regs, di.reg) = (long)(info.data << shift) >> shift;
+
+    advance_pc(regs, di.insn_len);
+
+    return 0;
 }
 
 static int emulate_store(struct guest_fault *gf)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400980.1636756 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvw-0005yd-IO; Thu, 27 Aug 2026 15:22:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90561e-2eae-0a2a0a5409dd-0a2a4502cbb6-26
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90562d-6ca4-0a2a45020019-d155802ba522-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:21 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-495437bb891so9120685e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844141-F12A12AC-FF43D5A4/10/73395122804
X-purgate-type: spam
X-purgate-size: 3716

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 <oleksii.kurochko@gmail.com>
---
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=64-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 ambiguous
   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;
 }
 
-static int emulate_store(struct guest_fault *gf)
+static int emulate_store(const struct guest_fault *gf)
 {
-    return -EOPNOTSUPP;
+    struct cpu_user_regs *regs = gf->regs;
+    mmio_info_t info = { .is_write = 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 = *guest_gpr(regs, di.reg);
+
+    rc = do_mmio(&info, gf->gpa, di.len);
+    if ( rc )
+        return rc;
+
+    advance_pc(regs, di.insn_len);
+
+    return 0;
 }
 
 static void inject_access_fault(const struct guest_fault *gf)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400987.1636764 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbvy-0006D5-7B; Thu, 27 Aug 2026 15:22:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90562c-e002-0a2a0a5209dd-0a2a4505e5e4-4
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90562e-4cb1-0a2a45050019-d1558033b90c-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:22 +0200
Received: by mail-wm1-f51.google.com with SMTP id
 5b1f17b1804b1-499b2981a7bso9943945e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 27/39] xen/riscv: introduce arch_move_irqs()
Date: Thu, 27 Aug 2026 17:21:11 +0200
Message-ID: <df3d3e1be48d9e46e4884c8573550b242efe26db.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787844142-251182A1-AA301120/10/73395122804
X-purgate-type: spam
X-purgate-size: 4235

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 <oleksii.kurochko@gmail.com>
---
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,
 
     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/asm/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);
 
+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 {
 
     /* 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);
 };
 
 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;
 
-static inline void arch_move_irqs(struct vcpu *v)
-{
-    BUG_ON("unimplemented");
-}
+void arch_move_irqs(struct vcpu *v);
 
 int platform_get_irq(const struct dt_device_node *device, int index);
 
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)
 
     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 = 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 = {
      */
     .ctxt_switch_from = imsic_ctxt_switch_from,
     .ctxt_switch_to = imsic_ctxt_switch_to,
+    .move_irqs = imsic_migrate_vcpu,
 };
 
 int domain_vaplic_init(struct domain *d)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400990.1636772 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbw1-0006ns-0f; Thu, 27 Aug 2026 15:22:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90562c-e002-0a2a0a5209dd-0a2a4505e5e4-6
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90562f-4cb1-0a2a45050019-d155dd35c0ad-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:23 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-480001972b8so454855f8f.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <c4f78f50022bd7a75a4deb71199e979beafb4906.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787844143-F62AB2A1-B7CCD5AB/10/73395122804
X-purgate-type: spam
X-purgate-size: 1447

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 <oleksii.kurochko@gmail.com>
---
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,
 
 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 == NR_CPUS )
+        return;
+
     BUG_ON("unimplemented");
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:36 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1400999.1636782 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbw3-0007BO-8s; Thu, 27 Aug 2026 15:22:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905621-2eae-0a2a0a5409dd-0a2a450aa854-32
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905631-f2d2-0a2a450a0019-d155802bc51e-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:25 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49b8ce9b733so6304285e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 29/39] xen/riscv: introduce aplic_reconfigure_target()
Date: Thu, 27 Aug 2026 17:21:13 +0200
Message-ID: <d90832888c1bcb08146a6c36591ac0c31b8b0ce1.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787844145-516C6CFC-3D451505/10/73395122804
X-purgate-type: spam
X-purgate-size: 2895

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 <oleksii.kurochko@gmail.com>
---
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 *target_vcpu,
     return base_val;
 }
 
+void aplic_reconfigure_target(const struct vcpu *v,
+                              unsigned int old_guest_file_id,
+                              unsigned int old_cpu)
+{
+    const struct vintc *vintc = v->domain->arch.vintc;
+    const unsigned long *auth_irq_bmp = vintc->used_irqs;
+    unsigned long old_hart_field = 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 = &aplic.regs->target[irqn - 1];
+        target_val = readl(ptarget);
+
+        guest_index = MASK_EXTR(target_val, APLIC_TARGET_GUEST_IDX);
+        hart_index = MASK_EXTR(target_val, APLIC_TARGET_HART_IDX);
+
+        if ( (guest_index != old_guest_file_id) ||
+             (hart_index != old_hart_field) )
+            continue;
+
+        target_val = 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/asm/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);
 
+void aplic_reconfigure_target(const struct vcpu *v,
+                              unsigned int old_guest_file_id,
+                              unsigned int old_cpu);
+
 #endif /* ASM_RISCV_APLIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401000.1636789 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbw4-0007RM-Qi; Thu, 27 Aug 2026 15:22:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90562c-e002-0a2a0a5209dd-0a2a4505e5e4-12
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905632-4cb1-0a2a45050019-d1558035e460-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:26 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso17665605e9.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787844146-F52A32A1-A3BF8177/10/73395122804
X-purgate-type: spam
X-purgate-size: 9361

Implement first steps of migration a vCPU to a different guest interrupt file
procedure:
- At the old interrupt file, save to memory the values of registers
  eidelivery and eithreshold, and set eidelivery = 0.
- At the new interrupt file, set eidelivery = 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 <oleksii.kurochko@gmail.com>
---
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 */
 
+#include <xen/bug.h>
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/sections.h>
+#include <xen/sched.h>
 #include <xen/types.h>
 
 #include <asm/cpufeature.h>
@@ -21,3 +23,10 @@ void __init aia_init(void)
 
     _aia_usable = 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 <xen/spinlock.h>
 #include <xen/xvmalloc.h>
 
+#include <asm/aia.h>
 #include <asm/imsic.h>
 
 #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)
 
+#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); break;"
+ * 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 (no 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;
 }
 
+/*
+ * 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 == 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 = 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 = csr_read(CSR_VSISELECT);
+    old_hstatus = csr_read(CSR_HSTATUS);
+    new_hstatus = old_hstatus & ~HSTATUS_VGEIN;
+    new_hstatus |= 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 = 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,
 
 void imsic_migrate_vcpu(struct vcpu *v)
 {
+    unsigned int new_vsfile_hgei;
+    unsigned int new_vsfile_cpu;
+    unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1,
+                                          BITS_PER_TYPE(uint64_t));
+    struct imsic_vsfile_data vsfile_data = {
+        .nr_eix = 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 == NR_CPUS )
         return;
 
+    /*
+     * 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 = v->processor;
+
+    new_vsfile_hgei = vgein_assign(v);
+
+    /* We don't support SW interrupt files at the moment. */
+    BUG_ON(!new_vsfile_hgei);
+
+    vsfile_data.hgei = new_vsfile_hgei;
+
+    /* Zero-out new IMSIC VS-file */
+    imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data);
+
     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
 
+struct vcpu;
+
 bool aia_usable(void);
 
 void aia_init(void);
 
+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)
 
 /* It is assumed that sizeof(void *) == __alignof(void *) */
 #define POINTER_ALIGN   __SIZEOF_POINTER__
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401003.1636798 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbw8-00080f-46; Thu, 27 Aug 2026 15:22:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905633-8faa-0a2a0a5109dd-0a2a450293fc-2
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905633-6ca4-0a2a45020019-d155dd2fe4a8-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:27 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-482ea739de2so825835f8f.0
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844147-F3CBA2AC-1E57114B/10/73395122804
X-purgate-type: spam
X-purgate-size: 4460

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 <oleksii.kurochko@gmail.com>
---
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 <asm/imsic.h>
 #include <asm/intc.h>
 #include <asm/io.h>
+#include <asm/processor.h>
 #include <asm/riscv_encoding.h>
+#include <asm/smp.h>
 
 static struct aplic_priv aplic = {
     .lock = SPIN_LOCK_UNLOCKED,
@@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value)
     spin_unlock_irqrestore(&aplic.lock, flags);
 }
 
+/*
+ * 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 = imsic_get_config();
+    unsigned int cpu = smp_processor_id();
+    unsigned long flags;
+    uint32_t val;
+
+    val = 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());
 
+    if ( irq == 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_device_node *node,
         return -ENOENT;
     }
 
+    /* Reserve last identity for APLIC-to-hart synchronization */
+    imsic_cfg.sync_id = imsic_cfg.nr_ids;
+
     /* Compute base address */
     *nr_mmios = 0;
     rc = 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/asm/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
 
 #define APLIC_GENMSI                    0x3000
+#define APLIC_GENMSI_BUSY               BIT(12, U)
 
 #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);
 
+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/asm/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;
 
+    /*
+     * 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;
 
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401007.1636803 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbw8-0008CI-BZ; Thu, 27 Aug 2026 15:22:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905626-e002-0a2a0a5209dd-0a2a4501aa5e-20
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905635-5984-0a2a45010019-d155802fd877-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:29 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-49b0d78a801so11444405e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787844149-BD87F757-2926A577/10/73395122804
X-purgate-type: spam
X-purgate-size: 8276

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 <oleksii.kurochko@gmail.com>
---
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 <xen/xvmalloc.h>
 
 #include <asm/aia.h>
+#include <asm/aplic.h>
 #include <asm/imsic.h>
 
 #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
 
+#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);
 }
 
+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);
 }
 
+static bool imsic_local_is_pending(unsigned int id)
+{
+    unsigned long isel =
+        (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0;
+    unsigned long bit = 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 */
 }
 
+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);
 }
 
+/*
+ * Ensure that all the MSIs the APLIC has already generated for the hart this
+ * 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 APLIC 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 = {
         .nr_eix = nr_hw_eix,
     };
+    struct vimsic_state *imsic_state = v->arch.vimsic_state;
+    unsigned long flags;
+    unsigned int old_vsfile_id;
+    unsigned int old_vsfile_cpu;
 
     /*
      * 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 == NR_CPUS )
         return;
 
+    read_lock_irqsave(&imsic_state->vsfile_lock, flags);
+    old_vsfile_id = imsic_state->guest_file_id;
+    old_vsfile_cpu = 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 == 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.
      */
 
@@ -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_data);
 
+    /* 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 physical
+     *       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 interrupt
+     * 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/asm/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);
 
 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);
 
+int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id);
+
 void imsic_migrate_vcpu(struct vcpu *v);
 
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401009.1636810 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwA-00006p-Qc; Thu, 27 Aug 2026 15:22:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905633-8faa-0a2a0a5109dd-0a2a450293fc-12
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905636-6ca4-0a2a45020019-d155802ef0da-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:31 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so22304785e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory
Date: Thu, 27 Aug 2026 17:21:17 +0200
Message-ID: <efecffa9cd7c4bb6e9ed51b7fd084328fcd4611e.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844151-307C22AC-E86F7F90/10/73395122804
X-purgate-type: spam
X-purgate-size: 6857

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 <oleksii.kurochko@gmail.com>
---
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)
 
     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
 
+/*
+ * 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)
 
+#define imsic_vs_csr_swap(c, v)     \
+({                                  \
+    unsigned long r_;               \
+                                    \
+    csr_write(CSR_VSISELECT, (c));  \
+    r_ = 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__)
 
+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 *data)
     csr_write(CSR_VSISELECT, old_vsiselect);
 }
 
+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 = data;
+    struct imsic_mrif *mrif = idata->mrif;
+    unsigned long new_hstatus, old_hstatus, old_vsiselect;
+
+    old_vsiselect = csr_read(CSR_VSISELECT);
+    old_hstatus = csr_read(CSR_HSTATUS);
+    new_hstatus = old_hstatus & ~HSTATUS_VGEIN;
+    new_hstatus |= ((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 = imsic_vs_csr_swap(IMSIC_EIDELIVERY, 0);
+    mrif->eithreshold = imsic_vs_csr_swap(IMSIC_EITHRESHOLD, 0);
+    for ( i = 0; i < idata->nr_eix; i++ )
+    {
+        eix = &mrif->eix[i];
+        eix->eip[0] = imsic_eix_swap(IMSIC_EIP0 + i * 2, 0);
+        eix->eie[0] = imsic_eix_swap(IMSIC_EIE0 + i * 2, 0);
+#ifdef CONFIG_RISCV_32
+        eix->eip[1] = imsic_eix_swap(IMSIC_EIP0 + i * 2 + 1, 0);
+        eix->eie[1] = 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 = {
+        .hgei = vsfile_id,
+        .nr_eix = nr_eix,
+        .mrif = mrif,
+    };
+
+    /* We can only read clear if we have a IMSIC VS-file */
+    if ( vsfile_cpu == 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 = { };
 
     /*
      * 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.
      */
 
+    /* Read and clear register state from old IMSIC VS-file */
+    imsic_vsfile_read_clear(old_vsfile_id, old_vsfile_cpu, nr_hw_eix, &tmrif);
+
+    /* 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);
 
 unsigned int vgein_assign(struct vcpu *v);
+void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu);
 
 #endif /* RISCV_AIA_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401014.1636818 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwC-0000YX-I5; Thu, 27 Aug 2026 15:22:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90561f-bab6-0a2a0a5309dd-0a2a450cb996-38
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905638-f479-0a2a450c0019-d1558034c5b9-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:32 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49b8ce9b733so6305435e9.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <c7000473af04e618a340270398fb85fffb46ca05.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d25034/1787844152-034D7A5B-887023BB/10/73395122804
X-purgate-type: spam
X-purgate-size: 5244

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 <oleksii.kurochko@gmail.com>
---
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_;                             \
 })
 
+#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, unsigned long val)
     }
 }
 
+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(void *data)
     old_vsiselect = csr_read(CSR_VSISELECT);
     old_hstatus = csr_read(CSR_HSTATUS);
     new_hstatus = old_hstatus & ~HSTATUS_VGEIN;
-    new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT;
+    new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN);
     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.
+     * No atomic accessors are needed to store the values into the MRIF here,
+     * as imsic_vsfile_read_clear() is always called with a pointer to a
+     * temporary MRIF on the stack.
      */
 
     mrif->eidelivery = 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);
 }
 
+static void cf_check imsic_vsfile_local_update(void *data)
+{
+    unsigned int i;
+    struct imsic_mrif_eix *eix;
+    const struct imsic_vsfile_data *idata = data;
+    struct imsic_mrif *mrif = 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 here,
+     * as this is always called with a pointer to a temporary MRIF on the
+     * stack.
+     */
+
+    old_vsiselect = csr_read(CSR_VSISELECT);
+    old_hstatus = csr_read(CSR_HSTATUS);
+    new_hstatus = old_hstatus & ~HSTATUS_VGEIN;
+    new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN);
+    csr_write(CSR_HSTATUS, new_hstatus);
+
+    for ( i = 0; i < idata->nr_eix; i++ )
+    {
+        eix = &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)
 
     /*
      * 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.
      */
 
     /* 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);
 
-    BUG_ON("unimplemented");
+    /* Restore register state in the new IMSIC VS-file */
+    vsfile_data.mrif = &tmrif;
+    imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_data);
+
+    /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */
+    vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN;
+    vcpu_guest_cpu_user_regs(v)->hstatus |=
+            MASK_INSR(new_vsfile_hgei, HSTATUS_VGEIN);
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:49 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401020.1636831 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwG-0001Kk-73; Thu, 27 Aug 2026 15:22:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905628-2eae-0a2a0a5409dd-0a2a4503e5b2-22
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a905639-fae8-0a2a45030019-d155dd2dc5a1-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:33 +0200
Received: by mail-wr1-f45.google.com with SMTP id
 ffacd0b85a97d-47fe2d179e2so1401547f8f.1
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <b84c2624e2f49e99a5f29439f4f01608eb1e5825.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787844153-74A894E9-9526A485/10/73395122804
X-purgate-type: spam
X-purgate-size: 6453

It was decided to add support for IMSIC from the start instead of having APLIC
operate in direct delivery mode, as it requires a trap-and-emulation approach,
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 <oleksii.kurochko@gmail.com>
---
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 */
 
-#include <xen/bug.h>
+#include <xen/bitops.h>
+#include <xen/cpu.h>
 #include <xen/errno.h>
 #include <xen/init.h>
 #include <xen/sections.h>
 #include <xen/sched.h>
+#include <xen/spinlock.h>
 #include <xen/types.h>
 
+#include <asm/aia.h>
 #include <asm/cpufeature.h>
+#include <asm/csr.h>
+#include <asm/current.h>
+
+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);
 
 static bool __ro_after_init _aia_usable;
 
@@ -16,22 +34,137 @@ bool aia_usable(void)
     return _aia_usable;
 }
 
+/* HGEIE is a per-hart CSR, so this has to run on the CPU being initialized. */
+static int vgein_init(void)
+{
+    struct vgein_ctrl *vgein = &this_cpu(vgein);
+
+    spin_lock_init(&vgein->lock);
+
+    csr_write(CSR_HGEIE, ~0UL);
+    vgein->geilen = flsl(csr_read(CSR_HGEIE) >> 1);
+    csr_write(CSR_HGEIE, 0);
+
+    vgein->bmp = 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 = (unsigned long)hcpu;
+    int rc = 0;
+
+    switch ( action )
+    {
+    case CPU_STARTING:
+        rc = 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 = {
+    .notifier_call = 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 = vgein_init()) )
+    {
+        dprintk(XENLOG_ERR, "vgein_init() failed: %d\n", rc);
+        return;
+    }
 
     _aia_usable = true;
+
+    register_cpu_notifier(&cpu_nfb);
 }
 
 unsigned int vgein_assign(struct vcpu *v)
 {
-    BUG_ON("unimplemented\n");
+    unsigned int vgein_id;
+    struct vgein_ctrl *vgein = &per_cpu(vgein, v->processor);
+    unsigned long *bmp = &vgein->bmp;
+    unsigned long flags;
 
-    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 interrupts
+     * 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 interrupts.
+     *   VGEIN is a WLRL field that must be able to hold values between zero
+     *   and the maximum guest external interrupt number (known as GEILEN),
+     *   inclusive.
+     *   When VGEIN=0, no guest external interrupt source is selected for
+     *   VS-level external interrupts.
+     *
+     * So start to search from bit number 1.
+     */
+    vgein_id = find_next_zero_bit(bmp, vgein->geilen + 1, 1);
+
+    if ( vgein_id > vgein->geilen )
+        vgein_id = 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=%#lx\n",
+            __func__, v, vgein_id, v->processor, *bmp);
+#endif
+
+    return vgein_id;
 }
 
 void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu)
 {
-    BUG_ON("unimplemented\n");
+    unsigned long flags;
+    struct vgein_ctrl *vgein = &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=%#lx\n",
+            __func__, v, vgein_id, cpu, vgein->bmp);
+#endif
 }
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:50 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401025.1636841 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwH-0001b4-RE; Thu, 27 Aug 2026 15:22:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905626-e002-0a2a0a5209dd-0a2a4501aa5e-26
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90563a-5984-0a2a45010019-d1558034c120-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:34 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49b8687630fso5778555e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <ed5a8b4d8137d9ce2f291956d19fbeaf61cce7a9.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787844154-BEA66757-6A65D1A5/10/73395122804
X-purgate-type: spam
X-purgate-size: 10845

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 <oleksii.kurochko@gmail.com>
---
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 that
+     * no guest external interrupt source is selected), and geilen can never
+     * exceed BITS_PER_LONG - 1, so indexing this array by the ID directly
+     * always fits.
+     */
+    struct vcpu *owners[BITS_PER_LONG];
     unsigned int geilen;
 };
 
@@ -62,23 +69,25 @@ static int cf_check cpu_callback(struct notifier_block *nfb,
                                  unsigned long action, void *hcpu)
 {
     unsigned int cpu = (unsigned long)hcpu;
-    int rc = 0;
 
     switch ( action )
     {
     case CPU_STARTING:
-        rc = vgein_init();
+    {
+        int rc = 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);
+    return NOTIFY_DONE;
 }
 
 static struct notifier_block cpu_nfb = {
@@ -138,7 +147,10 @@ unsigned int vgein_assign(struct vcpu *v)
     if ( vgein_id > vgein->geilen )
         vgein_id = 0;
     else
+    {
         __set_bit(vgein_id, bmp);
+        vgein->owners[vgein_id] = v;
+    }
 
     spin_unlock_irqrestore(&vgein->lock, flags);
 
@@ -161,6 +173,7 @@ void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu)
     spin_lock_irqsave(&vgein->lock, flags);
     if ( !__test_and_clear_bit(vgein_id, &vgein->bmp) )
         ASSERT_UNREACHABLE();
+    vgein->owners[vgein_id] = NULL;
     spin_unlock_irqrestore(&vgein->lock, flags);
 
 #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 = &this_cpu(vgein);
+
+    hgei_mask = 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 external
+         * 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 = (hstateen0 & csr_masks.hstateen0) |
                             csr_masks.ro_one.hstateen0;
     }
+
+    v->arch.hie = MIP_SGEIP;
 }
 
 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)
 
     write_lock_irqsave(&imsic_state->vsfile_lock, flags);
     imsic_state->vsfile_cpu = 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 HGEIP
+     * 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);
 }
 
 void cf_check imsic_ctxt_switch_to(struct vcpu *v)
 {
-    /* Nothing to do */
+    struct vimsic_state *imsic_state = 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 observe.
+     */
+    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);
 }
 
 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(void *data)
     struct imsic_mrif *mrif = idata->mrif;
     unsigned long new_hstatus, old_hstatus, old_vsiselect;
 
+    /*
+     * The HGEIE bit imsic_ctxt_switch_from() armed belongs to the old owner
+     * only.
+     */
+    csr_clear(CSR_HGEIE, BIT(idata->hgei, UL));
+
     old_vsiselect = csr_read(CSR_VSISELECT);
     old_hstatus = csr_read(CSR_HSTATUS);
     new_hstatus = old_hstatus & ~HSTATUS_VGEIN;
@@ -991,6 +1016,21 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo,
     return fdt_end_node(fdt);
 }
 
+/*
+ * 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 = 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 = &tmrif;
     imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_data);
 
+    /*
+     * 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 switched
+     * 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_data);
+
     /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */
     vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN;
     vcpu_guest_cpu_user_regs(v)->hstatus |=
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);
 
+void hgei_interrupt(void);
+
 #endif /* RISCV_AIA_H */
diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/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;
 
     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 <xen/sched.h>
 #include <xen/softirq.h>
 
-#include <asm/extable.h>
+#include <asm/aia.h>
 #include <asm/cpufeature.h>
 #include <asm/emulate.h>
+#include <asm/extable.h>
 #include <asm/intc.h>
 #include <asm/processor.h>
 #include <asm/riscv_encoding.h>
@@ -273,6 +274,10 @@ void do_trap(struct cpu_user_regs *cpu_regs)
                 timer_interrupt();
                 break;
 
+            case IRQ_S_GEXT:
+                hgei_interrupt();
+                break;
+
             default:
                 intr_handled = false;
                 break;
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:53 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401029.1636853 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwK-0002J0-Rd; Thu, 27 Aug 2026 15:22:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905633-8faa-0a2a0a5109dd-0a2a450293fc-26
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90563b-6ca4-0a2a45020019-d1558036b975-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:36 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-499b2981a7bso9947135e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 37/39] xen/riscv: map IMSIC interrupt file for vCPUs
Date: Thu, 27 Aug 2026 17:21:21 +0200
Message-ID: <ae5965ba43eb691b078f4a6bcf8a87a1f7a5aac5.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787844156-F24B62AC-B68AF592/10/73395122804
X-purgate-type: spam
X-purgate-size: 5116

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 <oleksii.kurochko@gmail.com>
---
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 inside
   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, they
   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 <asm/aia.h>
 #include <asm/aplic.h>
 #include <asm/imsic.h>
+#include <asm/p2m.h>
 
 #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ)
 
@@ -537,9 +538,72 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v)
     read_unlock_irqrestore(&imsic_state->vsfile_lock, flags);
 }
 
+/*
+ * 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 block,
+ * 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 hart.
+ *
+ * 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 where
+ * vGEIN = 0 in the hstatus CSR selects no guest external interrupt source),
+ * requiring the VS-file to be emulated in software.
+ *
+ * Consequently the mapping installed here is only valid as long as the vCPU
+ * 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 = v->domain;
+    unsigned int cpu = v->processor;
+    paddr_t gaddr = GUEST_IMSIC_S_BASE + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id);
+    paddr_t paddr, guest_offset;
+    int res;
+
+    /* Nothing to map in the case of sw interrupt file. */
+    if ( !vsfile_id )
+        return 0;
+
+    guest_offset = vsfile_id * IMSIC_MMIO_PAGE_SZ;
+
+    paddr = 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 = map_regions_p2mt(d, gaddr_to_gfn(gaddr),
+                           PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(paddr),
+                           arch_dt_passthrough_p2m_type());
+    if ( res )
+        dprintk(XENLOG_ERR,
+                "%s: Failed to map %#"PRIpaddr" to the guest at %#"PRIpaddr"\n",
+                __func__, paddr, gaddr);
+
+    return res;
 }
 
 int cf_check vcpu_imsic_init(struct vcpu *v)
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:54 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401032.1636858 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwL-0002Xp-Ng; Thu, 27 Aug 2026 15:22:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a905626-e002-0a2a0a5209dd-0a2a4501aa5e-32
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90563d-5984-0a2a45010019-d1558036f024-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:37 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so22305995e9.2
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu()
Date: Thu, 27 Aug 2026 17:21:22 +0200
Message-ID: <a282887cc08cd9b05f59d46cab9377915e83c61d.1787838835.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.55.0
In-Reply-To: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787844157-BE664757-AFC1CA69/10/73395122804
X-purgate-type: spam
X-purgate-size: 6071

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 <xen/percpu.h> before
this_cpu() is defined and before <xen/sched.h> completes struct vcpu.

idle_loop() is added as a stub on purpose; its real implementation will
come separately later.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
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 <xen/smp.h>
 #include <xen/vmap.h>
 
+#include <asm/aia.h>
+#include <asm/aplic.h>
 #include <asm/bitops.h>
 #include <asm/cpufeature.h>
 #include <asm/csr.h>
 #include <asm/current.h>
+#include <asm/imsic.h>
 #include <asm/intc.h>
 #include <asm/mmio.h>
 #include <asm/riscv_encoding.h>
@@ -140,9 +143,43 @@ static void vcpu_csr_init(struct vcpu *v)
     v->arch.hie = MIP_SGEIP;
 }
 
+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 disabled
+         * to guarantee that the vCPU's CSR state can be safely restored into
+         * the hart without being clobbered by an interrupt trap.
+         *
+         * For example, when return_to_new_vcpu() finishes, it executes sret.
+         * At that point, the hart checks hstatus.SPV=1 and sstatus.SPP=1 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-trivial,
+         * and if left as 0, sret would incorrectly return to HS-mode instead
+         * of VS-mode.
+         *
+         * To avoid this, interrupts are kept disabled during the restore.
+         * Additionally, setting sstatus.SPIE=1 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);
+    }
 }
 
 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)
 
         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 = (vcpu); } while (0)
 #define get_cpu_current(cpu)  per_cpu(curr_vcpu, cpu)
 
+#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 )
 
+#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()]
 
 #endif /* __ASSEMBLER__ */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:22:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:22:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401034.1636866 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzbwO-0002x1-5p; Thu, 27 Aug 2026 15:22:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
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 <xen-devel-bounces@lists.xenproject.org>)
	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 <oleksii.kurochko@gmail.com>)
 id 6a90563b-bab6-0a2a0a5309dd-0a2a4507d6aa-6
 for <xen-devel@lists.xenproject.org>; 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 <oleksii.kurochko@gmail.com>)
 id 6a90563e-b4ea-0a2a45070019-d155802fe169-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:22:38 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-49554ebb87dso21865525e9.3
 for <xen-devel@lists.xenproject.org>; 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-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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 <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Zheng Zhang <zhangzheng@iscas.ac.cn>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
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: <cover.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787844158-360C5AE4-AB5AF2C0/10/73395122804
X-purgate-type: spam
X-purgate-size: 9880

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 <oleksii.kurochko@gmail.com>
---
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 disabled
          * to guarantee that the vCPU's CSR state can be safely restored into
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)
 
 void imsic_update_state(struct vcpu *v, unsigned int guest_file_id)
 {
-    BUG_ON("unimplemented\n");
+    unsigned long flags;
+    struct vimsic_state *vimsic_state = v->arch.vimsic_state;
+    unsigned int cpu = guest_file_id ? v->processor : NR_CPUS;
+
+    write_lock_irqsave(&vimsic_state->vsfile_lock, flags);
+    vimsic_state->guest_file_id = guest_file_id;
+    vimsic_state->vsfile_cpu = cpu;
+    write_unlock_irqrestore(&vimsic_state->vsfile_lock, flags);
 }
 
 void __init imsic_ids_local_delivery(bool enable)
@@ -640,6 +647,16 @@ struct imsic_vsfile_data {
     struct imsic_mrif *mrif;
 };
 
+/*
+ * Number of 64-bit EIx groups needed to cover all the interrupt identities 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);
 }
 
+/*
+ * 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 = vcpu_guest_cpu_user_regs(v)->hstatus;
+
+    hstatus &= ~HSTATUS_VGEIN;
+    hstatus |= MASK_INSR(vsfile_id, HSTATUS_VGEIN);
+
+    vcpu_guest_cpu_user_regs(v)->hstatus = hstatus;
+}
+
+/*
+ * Take a h/w guest interrupt file of 'cpu' for the vCPU: zero the file out,
+ * 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 been
+ * 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 = { .nr_eix = imsic_nr_eix() };
+    unsigned int vsfile_id;
+    int rc;
+
+    vsfile_id = 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 such
+         * 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 = 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 = 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 = DIV_ROUND_UP(imsic_cfg.nr_ids + 1,
-                                          BITS_PER_TYPE(uint64_t));
-    struct imsic_vsfile_data vsfile_data = {
-        .nr_eix = nr_hw_eix,
-    };
+    unsigned int nr_hw_eix = imsic_nr_eix();
     struct vimsic_state *imsic_state = v->arch.vimsic_state;
     unsigned long flags;
     unsigned int old_vsfile_id;
     unsigned int old_vsfile_cpu;
     struct imsic_mrif tmrif = { };
+    struct imsic_vsfile_data vsfile_data = {
+        .nr_eix = nr_hw_eix,
+        .mrif = &tmrif,
+    };
 
     /*
      * 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 = v->processor;
 
-    new_vsfile_hgei = vgein_assign(v);
-
-    /* We don't support SW interrupt files at the moment. */
-    BUG_ON(!new_vsfile_hgei);
-
-    vsfile_data.hgei = new_vsfile_hgei;
-
-    /* Zero-out new IMSIC VS-file */
-    imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data);
-
-    /* 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 = imsic_vsfile_acquire(v, new_vsfile_cpu);
+    if ( !new_vsfile_id )
         return;
-    }
-
-    imsic_update_state(v, new_vsfile_hgei);
 
     /*
      * 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);
 
     /* Restore register state in the new IMSIC VS-file */
-    vsfile_data.mrif = &tmrif;
+    vsfile_data.hgei = new_vsfile_id;
     imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_data);
 
     /*
@@ -1262,7 +1334,23 @@ void imsic_migrate_vcpu(struct vcpu *v)
         imsic_call_on_cpu(new_vsfile_cpu, imsic_local_hgeie_set, &vsfile_data);
 
     /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */
-    vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN;
-    vcpu_guest_cpu_user_regs(v)->hstatus |=
-            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 = 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 once.
+     */
+    vcpu_set_vgein(v, new_vsfile_id);
 }
diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/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 vsfile_id);
 
 void imsic_migrate_vcpu(struct vcpu *v);
 
+void imsic_vsfile_attach(struct vcpu *v);
+
 #endif /* ASM_RISCV_IMSIC_H */
-- 
2.55.0



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:27:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:27:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401146.1636898 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc0g-0000ay-QJ; Thu, 27 Aug 2026 15:27:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401146.1636898; Thu, 27 Aug 2026 15:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc0g-0000ar-NX; Thu, 27 Aug 2026 15:27:22 +0000
Received: by outflank-mailman (input) for mailman id 1401146;
 Thu, 27 Aug 2026 15:27:22 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@swg.vates.tech>)
 id 1wzc0g-0000al-2v
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:27:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzc0f-00BqPT-DX
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:27:21 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@swg.vates.tech>)
 id 6a905733-8faa-0a2a0a5109dd-0a2a4501e450-40
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:27:21 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@swg.vates.tech>)
 id 6a905758-5984-0a2a45010019-b9ff1c23ae87-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:27:21 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a043d52a06000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 15:27:18 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8394983B31;
 Thu, 27 Aug 2026 17:27:17 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=WNHPSrx6fA4RvjHaealJExdGcNW4rz9y9rtrgh5u6r8=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:feedback-id;
 b=KpV4QcYtLR88Y3h5Pp8+Jpyp+04TclQeSieQwRTRTkDbkWH5/iFJe8bXpQx7HX1Ek3PC2juTW
 npnRvWtbQWLHkKM4i7ke1+D2S2TdruqlCE0sxXGf+xiF1DEHMLhTpy9yBEqm9Nz+pn7pZ/UfHo3
 kBaxcoAz+APUp1TuEYC1ZvuSx3z0tMCqrFjeCTTpdPmITAKZfqPtz+2+pW03DVLtMFPUj/y1rqW
 vbic2E6KOpis7wVrBlVNTj6B3U7zo+zEa0OJ7kiS4/trl/MYFOEJ9cNJy5kUwOTh1+SHfjVGdny
 e0wphfgchsAW3iWdxxDNqD10Hz8FR5ZjuD8RXKOxxKow==
X-Zone-Loop: 1d1aff709edee18cd9159b4c29280038aa3b52b16779
x-campaign-type: default
x-transaction-id: 625fba25-e6df-4496-a5cc-cb0edc48beab
x-swg-uid: 01-9f0acbc2-e1d0-48e5-b414-d61443cdf80f
X-Mailer: Sweego
Message-ID:
 <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
x-swg-bid: 1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 0/5] xen/riscv: fix boot on missing extensions and MMU setup bugs
Date: Thu, 27 Aug 2026 17:27:00 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787844437741
X-purgate-ID: tlsNG-d62444/1787844441-C4558757-D636B774/0/0
X-purgate-type: clean
X-purgate-size: 1618

This series introduces bugs fixes that were found while bringing up CI
support for the HiFive Premier P550 board with a basic smoke test. The
board-support series itself will follow separately as it depends on
PLIC/vPLIC and dom0less support that have not been upstreamed yet. This
series carries only the independent fixes found along the way, none of them
need the board-support series to apply.

This series:
- Stop requiring Zihintpause and Svpbmt at boot
    Both are already gated at some call sites that care, drop them
    from required_extensions[] so hardware without them still boots.
- Preset A/D bits in G-stage and in Xen's own page-table mappings
    Avoids an unhandled page fault on Svade/Svadu-less hardware on both
    mapping path.
- Add the missing SFENCE.VMA after enabling paging in turn_on_mmu()
  Required per the Privileged spec when ASID 0 is reused across the satp

CI pipeline:
https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2796673417

Baptiste Le Duc (5):
  xen/riscv: always set A/D bits at boot time
  xen/riscv: preset A/D bits in Xen's own page-table mappings
  xen/riscv: make Svpbmt no longer a required extension
  xen/riscv: make Zihintpause no longer a required extension
  xen/riscv: add SFENCE.VMA after enabling paging

 xen/arch/riscv/cpufeature.c       |  2 -
 xen/arch/riscv/include/asm/page.h | 22 ++++++----
 xen/arch/riscv/mm.c               |  7 ++-
 xen/arch/riscv/p2m.c              | 72 ++++++++++++++++++-------------
 xen/arch/riscv/riscv64/head.S     |  1 +
 5 files changed, 61 insertions(+), 43 deletions(-)



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:33:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:33:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401162.1636907 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6h-00040S-EC; Thu, 27 Aug 2026 15:33:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401162.1636907; Thu, 27 Aug 2026 15:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6h-00040L-BX; Thu, 27 Aug 2026 15:33:35 +0000
Received: by outflank-mailman (input) for mailman id 1401162;
 Thu, 27 Aug 2026 15:33:33 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@swg.vates.tech>)
 id 1wzc6f-0003z6-Pu
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:33:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzc6f-004lPY-3F
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:33:33 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@swg.vates.tech>)
 id 6a9058cd-bab6-0a2a0a5309dd-0a2a4501bec4-0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:33 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@swg.vates.tech>)
 id 6a9058cc-5984-0a2a45010019-b9ff1c22a3e9-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:32 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a043dad0d3000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 15:33:28 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 0FDDB83B2C;
 Thu, 27 Aug 2026 17:33:28 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=lX3gKu4rOIRe3Ekaw+G/MAhrsXOHOk9RXSUMvf3lWds=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=ZrNrmNIK4cVTEAi6nB+/edzEL1qDOO3lJF9uuU2iB5Qqp4ZiMq82hlzHofPvd36xvFTNBFHNd
 idxYifoHi8NPLfhaLsFEKgqA/eaFe6DZiqm5RrKXG6E5/7nauC2x3p3HZ1X2sszEr+0xxPJeOpc
 LvMp9OWpKLGyFyMy2NG7CZqiJR8xdaUH+J8UaMM3Sy9QrwA74y2pBZPLnXq0YIGlBFzPjTzY0De
 e4App96PGHaORFAaRI/h+ErNDRPsfcHAujnq0qr4FrjPIiBCBByIcZbvAy86lbakWuRVhyHCln0
 WvXSWaXh0unbl+EwLNBIwA/qG18bvbj54eWC73W62kTQ==
X-Zone-Loop: 10b4c05640a8da4398d9b25087e118bc2a72120cd49e
x-campaign-type: default
x-transaction-id: 69c5737c-279c-481a-ac8c-8068ba8e385f
x-swg-uid: 01-c127937a-9dcc-4a91-bc29-95335dd5ff6b
X-Mailer: Sweego
Message-ID:
 <1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@vates.tech>
x-swg-bid: 1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 1/5] xen/riscv: always set A/D bits at boot time
Date: Thu, 27 Aug 2026 17:33:15 +0200
In-Reply-To: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787844808264
X-purgate-ID: tlsNG-d62444/1787844812-1DC79757-86441F54/0/0
X-purgate-type: clean
X-purgate-size: 5404

Always set the PTE A/D bits at boot time to avoid an unhandled page fault
on platforms that implement neither Svade nor Svadu, and on platforms that
declare both in the device tree.

Rewrite the comment to enumerate the four possible Svade/Svadu combinations
(inspired by [1]) and set A/D unconditionally, which is correct in all four
cases until Svadu is fully supported (full support requires the SBI FWFT
call to enable hardware updating of A/D bits).

[1] https://lwn.net/Articles/980016/

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 xen/arch/riscv/p2m.c | 70 ++++++++++++++++++++++++++------------------
 1 file changed, 42 insertions(+), 28 deletions(-)

diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 1cea86512c..11dc289f0f 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -591,38 +591,52 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
     e->pte |= PTE_USER;
 
     /*
-     * Two schemes to manage the A and D bits are defined:
-     *   • The Svade extension: when a virtual page is accessed and the A bit
-     *     is clear, or is written and the D bit is clear, a page-fault
-     *     exception is raised.
-     *   • When the Svade extension is not implemented, the following scheme
-     *     applies.
-     *     When a virtual page is accessed and the A bit is clear, the PTE is
-     *     updated to set the A bit. When the virtual page is written and the
-     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
-     *     address translation is in use and is not Bare, the G-stage virtual
-     *     pages may be accessed or written by implicit accesses to VS-level
-     *     memory management data structures, such as page tables.
-     * Thereby to avoid a page-fault in case of Svade is available, it is
-     * necessary to set A and D bits.
+     * Svade and Svadu extensions represent two schemes for managing the PTE
+     * A/D bits. When the PTE A/D bits need to be set, the Svade extension
+     * indicates that a page fault will be raised. In contrast, the Svadu
+     * extension supports hardware updating of the PTE A/D bits.
      *
-     * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI
-     *       delegates page faults to a lower privilege mode and so OpenSBI
-     *       isn't expect to handle page-faults occured in lower modes.
-     *       By setting the A/D bits here, page faults that would otherwise
-     *       be generated due to unset A/D bits will not occur in Xen.
+     * There are 4 possible combinations of these extensions in the device
+     * tree. The default hardware behavior for each is:
      *
-     *       Currently, Xen on RISC-V does not make use of the information
-     *       that could be obtained from handling such page faults, which
-     *       could otherwise be useful for several use cases such as demand
-     *       paging, cache-flushing optimizations, memory access tracking,etc.
+     * 1) Neither Svade nor Svadu present in DT => It is technically unknown
+     *    whether the platform uses Svade or Svadu. Xen should be prepared to
+     *    handle either hardware updating of the PTE A/D bits or page faults
+     *    when they need updating. To support both, Xen always sets the 'A' and
+     *    'D' PTE bits at boot time.
      *
-     *       To support the more general case and the optimizations mentioned
-     *       above, it would be better to stop setting the A/D bits here and
-     *       instead handle page faults that occur due to unset A/D bits.
+     * 2) Only Svade present in DT => Xen must assume Svade to be always
+     *    enabled.
+     *
+     * 3) Only Svadu present in DT => Xen must assume Svadu to be always
+     *    enabled.
+     *
+     * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
+     *    off at boot time by setting A/D bits. To use Svadu, the supervisor
+     *    must explicitly enable it using the SBI FWFT extension.
+     *
+     * The Svade extension is mandatory and the Svadu extension is optional in
+     * the RVA23 profile. Platforms wanting to take advantage of Svadu can
+     * choose option 3. Platforms aware of the profile can choose option 4, and
+     * Linux won't get the benefit of Svadu until the SBI FWFT extension is
+     * available.
+     *
+     * Currently, Xen on RISC-V does not make use of the information that could
+     * be obtained from handling such page faults, which could otherwise be
+     * useful for several use cases such as demand paging, cache-flushing
+     * optimizations, memory access tracking, etc.
+     *
+     * To support the more general case and the optimizations mentioned above,
+     * it would be better to stop setting the A/D bits here and instead handle
+     * page faults that occur due to unset A/D bits.
+     */
+
+    /*
+     * Preset unconditionally for all 4 cases above, harmless when Svadu
+     * manages the bits (case 3). Skipping it for case 3 requires SBI FWFT
+     * which is not yet supported.
      */
-    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
-        e->pte |= PTE_ACCESSED | PTE_DIRTY;
+    e->pte |= PTE_ACCESSED | PTE_DIRTY;
 
     switch ( t )
     {


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:33:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:33:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401163.1636917 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6m-0004FP-Or; Thu, 27 Aug 2026 15:33:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401163.1636917; Thu, 27 Aug 2026 15:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6m-0004FI-L3; Thu, 27 Aug 2026 15:33:40 +0000
Received: by outflank-mailman (input) for mailman id 1401163;
 Thu, 27 Aug 2026 15:33:39 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@swg.vates.tech>)
 id 1wzc6l-0004Cx-9j
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:33:39 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzc6i-004lPY-Nm
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:33:36 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@swg.vates.tech>)
 id 6a9058cd-bab6-0a2a0a5309dd-0a2a4501bec4-8
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:36 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@swg.vates.tech>)
 id 6a9058cc-5984-0a2a45010019-b9ff1c22a3e9-4
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:36 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a043dad225000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 15:33:29 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 954BC83BA7;
 Thu, 27 Aug 2026 17:33:28 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=fail header.s=selector1 header.d=vates.tech header.i="@vates.tech"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=jcfiniJ2HA0oc4SB8mrHlmNbUSh8Qghq5rzk6gnCeY8=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=D/xlDEqVdcgftFYisevE8fJyf/ewwlg7HLKv4qaTmZmuP3oZbsjvAPXqEWzO1tMV/ocuuG6Ml
 E/6NuBzGJMn21s5qperhcoth6RvgeVtO75uIy0BAQDYEfh72lagou4GXo09AXN/mX6Vuec22H+m
 HMZltC/IlkyGWWlQOUtGLLt+B21CVPRdClfypPJvfjz0vNBmNd7poJ/FHWDTHFzX7LN8/DSVPip
 RNII8kTKFhsBc76P1K9lSV40mV3XvOiblYnQ1UV3bOsOsj5JpGWo4Po1gzaGVt6MZd+c39uzt7Z
 Qxh4ognsL2kT3JXPobUwPti7MBnLIPDh4BOoYimG94cA==
X-Zone-Loop: 15c7b58b3f858a58634ac03164e0b85424a6a3df628b
x-campaign-type: default
x-transaction-id: edd5e07d-fa9a-4cb4-aae8-ff9f0fcad810
x-swg-uid: 01-208d7c0e-4823-4280-8031-623dbfa18acb
X-Mailer: Sweego
Message-ID:
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@vates.tech>
x-swg-bid: 1787844809.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 2/5] xen/riscv: preset A/D bits in Xen's own page-table mappings
Date: Thu, 27 Aug 2026 17:33:16 +0200
In-Reply-To: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787844808798
X-purgate-ID: tlsNG-d62444/1787844816-1FC69757-FBF9F4D1/0/0
X-purgate-type: clean
X-purgate-size: 4228

The previous patch made p2m_set_permission() always set the PTE A/D bits to
map pages in G-stage, to avoid a page fault on platforms that implement
neither Svade nor Svadu, or that declare both in the device tree. Xen's own
page tables, built by setup_initial_mapping(), never go through
p2m_set_permission() and need the same fix.

Add PTE_ACCESSED to PTE_LEAF_DEFAULT and make it the minimal common leaf
permission set by dropping PTE_WRITABLE. Rebuild PAGE_HYPERVISOR_RO,
PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX from that common base, with
PAGE_HYPERVISOR_RW also adding PTE_DIRTY. Switch setup_initial_mapping() to
use these macros for its default, text, and rodata permissions instead of
the equivalent raw bit lists.

A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so
update pte_is_table() accordingly.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 xen/arch/riscv/include/asm/page.h | 14 ++++++++------
 xen/arch/riscv/mm.c               |  7 +++----
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index b465a90325..5c02f64a17 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -46,12 +46,12 @@
 #define PTE_PBMT_NOCACHE            BIT(61, UL)
 #define PTE_PBMT_IO                 BIT(62, UL)
 
-#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
+#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_ACCESSED)
 #define PTE_TABLE                   (PTE_VALID)
 
-#define PAGE_HYPERVISOR_RO          (PTE_VALID | PTE_READABLE)
-#define PAGE_HYPERVISOR_RW          (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
-#define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
+#define PAGE_HYPERVISOR_RO          (PTE_LEAF_DEFAULT)
+#define PAGE_HYPERVISOR_RW          (PTE_LEAF_DEFAULT | PTE_WRITABLE | PTE_DIRTY)
+#define PAGE_HYPERVISOR_RX          (PTE_LEAF_DEFAULT | PTE_EXECUTABLE)
 
 #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
 /*
@@ -177,7 +177,8 @@ static inline bool pte_is_table(pte_t p)
      *
      * PAGE_HYPERVISOR_RW contains PTE_VALID too.
      */
-    ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE)));
+    ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=
+           (PTE_VALID | PTE_WRITABLE));
 
     return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID);
 }
@@ -185,7 +186,8 @@ static inline bool pte_is_table(pte_t p)
 static inline bool pte_is_mapping(pte_t p)
 {
     /* See pte_is_table() */
-    ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE)));
+    ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=
+            (PTE_VALID | PTE_WRITABLE));
 
     return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
 }
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 4d3b8c2204..baff49cf09 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -140,7 +140,7 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc,
         case 1: /* Level 0 */
             {
                 unsigned long paddr = (page_addr - map_start) + pa_start;
-                unsigned int permissions = PTE_LEAF_DEFAULT;
+                unsigned int permissions = PAGE_HYPERVISOR_RW;
                 unsigned long addr = is_identity_mapping
                                      ? page_addr : virt_to_maddr(page_addr);
                 pte_t pte_to_be_written;
@@ -149,11 +149,10 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc,
 
                 if ( is_kernel_text(addr) ||
                      is_kernel_inittext(addr) )
-                        permissions =
-                            PTE_EXECUTABLE | PTE_READABLE | PTE_VALID;
+                    permissions = PAGE_HYPERVISOR_RX;
 
                 if ( is_kernel_rodata(addr) )
-                    permissions = PTE_READABLE | PTE_VALID;
+                    permissions = PAGE_HYPERVISOR_RO;
 
                 pte_to_be_written = paddr_to_pte(paddr, permissions);
 


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:33:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:33:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401164.1636925 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6p-0004UM-UA; Thu, 27 Aug 2026 15:33:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401164.1636925; Thu, 27 Aug 2026 15:33:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6p-0004UF-RD; Thu, 27 Aug 2026 15:33:43 +0000
Received: by outflank-mailman (input) for mailman id 1401164;
 Thu, 27 Aug 2026 15:33:42 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@swg.vates.tech>)
 id 1wzc6o-0004FB-4Y
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:33:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzc6l-004lPY-Ha
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:33:39 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@swg.vates.tech>)
 id 6a9058cd-bab6-0a2a0a5309dd-0a2a4501bec4-12
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:39 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@swg.vates.tech>)
 id 6a9058cc-5984-0a2a45010019-b9ff1c22a3e9-5
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:39 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a043dad34e000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 15:33:29 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id E6D7983BA9;
 Thu, 27 Aug 2026 17:33:28 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=24Z5cEfX20FEssAKJ5JDYU2thxtQEXCNuYQwEhaCNHw=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=QIHyA+bDeDRk/w40rfz15NeOGbIH+O8a0WAI8D6bwAMWgFadB14oCyLXs8/GPNRhM5iYxeKRO
 N0mdFG9EBvqJN0Xj53ZnQ9YZIdGLHtKQzM8+7/1XRhoujGnWWDqn4UVW7wKDeL77Z2BMpkI0QBo
 n8p9vP8G5CAhx31nhyP20pAwb4WJ6M2XZZyridtbM+vJSrC1/tK5pL7HH6lzQHO+y/hkAb/jin0
 1r+o5M6U2RCLoo4gvDT/Fl1Dmyo4lgs3qTh88ekJ7RdDR1sHL3Z9U7KdBXGaX+hjxqCS10TLdUc
 2sQkMuoNBy8z1Ho9HJYf/D2FrY2zmkY64mAPPQbHn9Fw==
X-Zone-Loop: 28b1bd41c377b658159428097b5a8916c244f407a400
x-campaign-type: default
x-transaction-id: cd31eacc-04a0-4a67-a765-dc237c755b85
x-swg-uid: 01-a44bb09f-ed3e-4cba-a115-539818405db2
X-Mailer: Sweego
Message-ID:
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@vates.tech>
x-swg-bid: 1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 3/5] xen/riscv: make Svpbmt no longer a required extension
Date: Thu, 27 Aug 2026 17:33:17 +0200
In-Reply-To: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787844809139
X-purgate-ID: tlsNG-d62444/1787844819-1FE68757-E279A184/0/0
X-purgate-type: clean
X-purgate-size: 2988

required_extensions[] panics at boot if Svpbmt is missing, which is a
problem on hardware that doesn't implement it. Xen already checks Svpbmt at
runtime in some places (vcpu_csr_init()), but not everywhere:
p2m_pte_from_mfn() and the PAGE_HYPERVISOR_NOCACHE/WC macros still set the
raw PTE_PBMT* encoding unconditionally.

Drop Svpbmt from required_extensions, and introduce pte_pbmt(), which masks
the requested PBMT encoding down to 0 when Svpbmt is unavailable, using it
in both remaining unguarded spots.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 xen/arch/riscv/cpufeature.c       | 1 -
 xen/arch/riscv/include/asm/page.h | 8 ++++++--
 xen/arch/riscv/p2m.c              | 2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 92235fdfd5..900cb9d772 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -157,7 +157,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
     RISCV_ISA_EXT_DATA(zifencei),
     RISCV_ISA_EXT_DATA(zihintpause),
     RISCV_ISA_EXT_DATA(zbb),
-    RISCV_ISA_EXT_DATA(svpbmt),
 };
 
 static bool __init is_lowercase_extension_name(const char *str)
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 5c02f64a17..6a3749526d 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -11,6 +11,7 @@
 #include <xen/types.h>
 
 #include <asm/atomic.h>
+#include <asm/cpufeature.h>
 #include <asm/page-bits.h>
 
 #define VPN_MASK                    (PAGETABLE_ENTRIES - 1UL)
@@ -54,6 +55,9 @@
 #define PAGE_HYPERVISOR_RX          (PTE_LEAF_DEFAULT | PTE_EXECUTABLE)
 
 #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
+
+#define pte_pbmt(pbmt) \
+    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? (pbmt) : 0UL)
 /*
  * PAGE_HYPERVISOR_NOCACHE is used for ioremap().
  *
@@ -61,8 +65,8 @@
  * is that IO is non-idempotent and strongly ordered, which makes it a good
  * candidate for mapping IOMEM.
  */
-#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PBMT_IO)
-#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE)
+#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_IO))
+#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_NOCACHE))
 
 /*
  * The PTE format does not contain the following bits within itself;
diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
index 11dc289f0f..f6e635ec1d 100644
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -683,7 +683,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t,
         switch ( t )
         {
         case p2m_mmio_direct_io:
-            e.pte |= PTE_PBMT_IO;
+            e.pte |= pte_pbmt(PTE_PBMT_IO);
             break;
 
         default:


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:33:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:33:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401166.1636935 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6u-0004kx-6G; Thu, 27 Aug 2026 15:33:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401166.1636935; Thu, 27 Aug 2026 15:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6u-0004kk-1u; Thu, 27 Aug 2026 15:33:48 +0000
Received: by outflank-mailman (input) for mailman id 1401166;
 Thu, 27 Aug 2026 15:33:46 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@swg.vates.tech>)
 id 1wzc6s-0004aq-F8
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:33:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzc6p-007bb9-T0
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:33:43 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@swg.vates.tech>)
 id 6a9058ce-e002-0a2a0a5209dd-0a2a450a9022-10
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:43 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@swg.vates.tech>)
 id 6a9058d7-f2d2-0a2a450a0019-b9ff1c23b221-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:43 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a043dad47c000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 15:33:29 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 3D89F83B2C;
 Thu, 27 Aug 2026 17:33:29 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=fail header.s=selector1 header.d=vates.tech header.i="@vates.tech"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=3ZcO1+ssVslCiaCEuoWDFgkR6W22kC70bBnwQcv39oY=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=cXAcVeo1nLcGEOkEthVJtxE2u3M9ZF9gjj9iWj8rWu1WMusMOxuYog25IJsxv1+nb+icB2JPU
 4sgykJora6yQMkyuDANVa6ASD4QNa9PIRY97FZqPTro8GNOoT8QU7uUiYGDE1LlTUzq8pe1olu1
 wFE/QowdLso/qW9DalIu8pzYcD6tRSo+AQcl7JVpNInxgx+2u7XJpURu4J9q/jTMpfTNUH8DmFd
 jjckC6/jHD7PNfpn+nZFewpd0XaBmpbIJUjbyNbA5TTd2m9mKbGFQEhWRG2sglTRfrFPgf9rPha
 uUUP9Nbcn4I0XATol5n41vYCUjpvc3G4BalhWUALX3AA==
X-Zone-Loop: a833fcdf142171ad69ff00ae894f0f5a15669006d7dd
x-campaign-type: default
x-transaction-id: b71bae0a-e38a-48c2-acd6-d17711936ae1
x-swg-uid: 01-319944b6-353e-41b7-b338-b7f66bb82921
X-Mailer: Sweego
Message-ID:
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@vates.tech>
x-swg-bid: 1787844809.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 4/5] xen/riscv: make Zihintpause no longer a required extension
Date: Thu, 27 Aug 2026 17:33:18 +0200
In-Reply-To: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787844809439
X-purgate-ID: tlsNG-4011c0/1787844823-51CC3CFC-FF162A8F/0/0
X-purgate-type: clean
X-purgate-size: 1006

required_extensions[] panics at boot if Zihintpause is missing, but Xen
never actually depends on it: cpu_relax() only emits the "pause" when the
extension is implemented and otherwise falls back to the raw fence
encoding, which is a legal no-op on any hart regardless of Zihintpause
support.

Drop it from required_extensions so hardware without Zihintpause
still boots.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 xen/arch/riscv/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
index 900cb9d772..661babc0a6 100644
--- a/xen/arch/riscv/cpufeature.c
+++ b/xen/arch/riscv/cpufeature.c
@@ -155,7 +155,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
     RISCV_ISA_EXT_DATA(h),
     RISCV_ISA_EXT_DATA(zicsr),
     RISCV_ISA_EXT_DATA(zifencei),
-    RISCV_ISA_EXT_DATA(zihintpause),
     RISCV_ISA_EXT_DATA(zbb),
 };
 


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:33:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:33:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401167.1636941 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6u-0004o8-GQ; Thu, 27 Aug 2026 15:33:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401167.1636941; Thu, 27 Aug 2026 15:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzc6u-0004nj-AP; Thu, 27 Aug 2026 15:33:48 +0000
Received: by outflank-mailman (input) for mailman id 1401167;
 Thu, 27 Aug 2026 15:33:47 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@swg.vates.tech>)
 id 1wzc6t-0004jQ-0K
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:33:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzc6s-009mXR-9u
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:33:46 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@swg.vates.tech>)
 id 6a9058d6-bab6-0a2a0a5309dd-0a2a450be46e-12
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:46 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@swg.vates.tech>)
 id 6a9058d9-b7e8-0a2a450b0019-b9ff1c12a07f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:33:46 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a043dad5be000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Thu, 27 Aug 2026 15:33:30 +0000
Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 85ED883BA7;
 Thu, 27 Aug 2026 17:33:29 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=i+HHq2A31VQb2g0bdrLz5UpxPcOvqCH0udYV5TPCDME=;
 h=from:subject:date:message-id:to:cc:mime-version:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=lGSlBITXmfankS51hczo2ipy6y9H1e4NMM6p0eUTdYptAEROv7sCPLjQZ8DbASUPFjRfxof98
 gybPD4j2ZgCf+aXUNe7zcCTVLnk8nEfnVbtFNEIYiLYZZU1BOy6JT1Q1l9b9cueZMxrgn8nmDm/
 latsATuPJ99wfJr8jUI+yrquobdTa+yaLsm1oGOyIaBCilqhF3/WBfHHBcaRuS6AOQ1liAy6Jm0
 iDG/IOQQ/sMNuOjwR5qeO8GlrlrSv1fQr+OLB2aSQ19WhCywXHa04+Sq/OPBCBaIdQyS4Lo92qR
 bswzFEIT6+q7c/ZRpnEvAL1q4sZCOcX8y5zjqw6M+VqA==
X-Zone-Loop: 8dd3241f923ac5462f190502a8fbde2faeef09ccf148
x-campaign-type: default
x-transaction-id: 590e34cd-8d8c-4ef1-b2da-a78619f557c2
x-swg-uid: 01-101f5d24-f1c3-4260-9a82-43a570afc621
X-Mailer: Sweego
Message-ID:
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
x-swg-bid: 1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn,
	Baptiste Le Duc <baptiste.le-duc@vates.tech>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Julien Grall <julien@xen.org>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
Date: Thu, 27 Aug 2026 17:33:19 +0200
In-Reply-To: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787844809736
X-purgate-ID: tlsNG-42698a/1787844826-AAAD89EA-3FF432D2/0/0
X-purgate-type: clean
X-purgate-size: 1850

turn_on_mmu() writes satp to switch on Sv39 paging but never fences
afterwards.

Xen never allocates a non-zero ASID, so per the Privileged spec, sec.
12.2.1 "Supervisor Memory-Management Fence Instruction":

  "If the implementation does not provide ASIDs, or software chooses
  to always use ASID 0, then after every satp write, software should
  execute SFENCE.VMA with rs1=x0."

The spec text around this rule hedges with "may be necessary", but
RISC-V spec co-author Andrew Waterman confirmed on the ISA manual
issue tracker that the fence after a satp write is not optional in
this case: "The SFENCE after the SATP write is definitely necessary
... In general, you need to SFENCE after you've recycled an ASID.
Since we don't use ASIDs in the Linux kernel yet, every context
switch is effectively an ASID reuse, hence the full TLB flush." [1]
The same reasoning applies to Xen: with ASID always 0, this satp
write is indistinguishable from an ASID reuse to the hart, so the
fence is required for correctness.

Add the missing SFENCE.VMA to order those page-table stores before
the hart's first translation under the new mapping.

[1] https://github.com/riscv/riscv-isa-manual/issues/226

Fixes: f5035d480f7a ("xen: add files needed for minimal riscv build")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
---
 xen/arch/riscv/riscv64/head.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S
index 9c40512e61..7f6edc972f 100644
--- a/xen/arch/riscv/riscv64/head.S
+++ b/xen/arch/riscv/riscv64/head.S
@@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
         srli    t1, t1, PAGE_SHIFT
         or      t1, t1, t0
         csrw    CSR_SATP, t1
+        sfence.vma
 
         jr      a0
 END(turn_on_mmu)


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:37:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:37:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401197.1636952 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcA2-0006iq-R5; Thu, 27 Aug 2026 15:37:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401197.1636952; Thu, 27 Aug 2026 15:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcA2-0006ij-OD; Thu, 27 Aug 2026 15:37:02 +0000
Received: by outflank-mailman (input) for mailman id 1401197;
 Thu, 27 Aug 2026 15:37:01 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wzcA1-0006id-Oc
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:37:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcA1-004llq-0R
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:37:01 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a90598f-e002-0a2a0a5209dd-0a2a4504d1ca-20
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:37:00 +0200
Received: from [52.101.57.11]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a90599b-b57f-0a2a45040019-3465390bcaac-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:37:00 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DS7PR03MB5560.namprd03.prod.outlook.com (2603:10b6:5:2d0::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.7; Thu, 27 Aug
 2026 15:36:58 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 15:36:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nMoKXs0KzBdCujxnX5Cne3yegfvy666hBaY1r3JJmS9brwUFEYQ6dINnXGK9e1Oa32yB4FtpwS04IWRQoSDfL8N3jCOT/KqauUnrt406kHQge+ptINKmbhkvDBNKkv6qYT+LcT6sI93QGeXDRIj5v8YDR922Y7Y7lZaMwbOR26bF8XN+mOu6kg/hp9yql+ImCgkHV70J2mX6Cl9KFKWUMiwuw+UBMJw4IIEudp8e2zJHfJxkfB+ykP7MEheW980ABbdSJPCb2YllDRGIvtQBw/Y0dXysp62gqDln+C9oEmemDZZaiApBBcJLWeSPH68PH3o2yQEen/sfQyymmsZs6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=RPWs7/g1X/Mu/0zIUh9LPX/o+wZB03lWsQp7pVaCrwA=;
 b=fkEth9lv7bNFued4OWYGnvjM5yRuuRpBXJHoertlKMK7qkEulr8FzJ0EFgw3SZqulkVoFcOP8XkzX5iBiFIP5cIFIJzZJ8d9l8t1LH85sTs5iPxMEJ61G3MHfvbTGDwnjx+brpPcgDxXPvDfIgyZH+kdR78nAGsswEhdUkVYthCT/QW7envsNxT+ElDlIQJdRXDnebIx+3QtEQpU82mfZjBl3Or+GTPLs/comnKw1aiJCSlOVgWXOSY9sl2l+OBKDAQa+IlV77VwI1/hAEEWYELnsH9wrbq8wxvHZ9Hc50AtBSP8GNs4tF+wUxlYzudJiSfJZkuvQXw8RnEr5e5V6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=RPWs7/g1X/Mu/0zIUh9LPX/o+wZB03lWsQp7pVaCrwA=;
 b=yE4RwtYWHk8iBPU65bIjzMJ5i8A6vvVPVxjLhBjU8xnPfFFcuZN/GWhZJM4wY9y+/be3W5E08k+hIhVeSf0gCo2LWd6O9ZhICGBwh/RknYy4/pHiAEFWBI3q9B6YaE6a2PSGTcmwAstzrWHerBsXmC7XGz0vvzte5pc4xUBOJWs=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <aded3bc6-6d5c-4c3f-879a-be428a8ad36a@citrix.com>
Date: Thu, 27 Aug 2026 16:36:53 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Zheng Zhang <zhangzheng@iscas.ac.cn>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 04/39] xen/riscv: introduce csr_read64()
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 xen-devel@lists.xenproject.org
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <0f7080ea4dc86a8bb3dae39d94e5b03e95d010c0.1787838835.git.oleksii.kurochko@gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <0f7080ea4dc86a8bb3dae39d94e5b03e95d010c0.1787838835.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0136.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:193::15) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5560:EE_
X-MS-Office365-Filtering-Correlation-Id: 4208fa6f-3332-4b96-035e-08df045107bc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|7416014|10067099003|6133799003|3023799007|18002099003|22082099003|4143699003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	A86yzFM1iQO5pqXlW3JIgFZt/BathCozFDgPSnYCFiMUvzfGRFmbvVzEtak/UiNoGx4bT6iQTaTBU96qc2PkQ6RoCyon0NL6rPd+xbUhbQbGLWdjOjM9c3ieg7MMuNb3lAL2ubxs4H3UUu2jUXumtPw2YahOfNqWXBRTOsGG50AI9CJfvX7u7c8f8/4hrlGH7fOCMyO2H2I4M4i+yS0yhZDBh7Xwi/i//KLtmp86xaDLgaXz+CxWenU3jP5YwUH7j5oxWgjBYxch0P021pki5WnfW3D9kRf55PoJ64iNUmxkvIuP2oIhkTQj6jyfqjOUJQORVrIdcOy9/gXANSs5nxDqP9xpOA3T5Hx/R/hNn4Zev80DtTWQRj+PEpDQI8RWbKWoe0GEIvzMUGV12fXjyyK8zS4rmQE0wsHqnBP5f3wmM8WmHCgGwCB7oGh+34cXmo4gCYj0v3TzkjtU1coWPvRnvigqo+cM0tVuVhzfmRTsGQl0ostaEg6RKYPuaWTW5CyljMQbD5KLfQkpiXWbAm3uQHCC/0HlaZFBDFV5t9H0v1FaWVYCIn84WYJT9pHsy61pizAQNLa1XDxSBEaxJwgdH4N6GkPL6B+NC+vBoSFjrer48ybicF7RqOT/EO+H0270OGetJCdpTaStrTzn5r49pfKniBjygj/I8FDq7WA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(7416014)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(4143699003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?WU5Ka0JBNk83NkZlVitCSjIwVXBYU3dnanhuOFVZY3FOMzhuaFlGOG85L3BZ?=
 =?utf-8?B?QnhrL3dGNWI3UVY2T29xRUZLRTE4RTJRUkdwWEgzc0x1VkJnN2VjQVIzRVA4?=
 =?utf-8?B?N3V1TXdIeTN5Y3J1VnlRQlM4dEFQVTNkSEZBRlo4ZVplWG41WWF5SGs1MVpV?=
 =?utf-8?B?eWZVN1EvNHpYUk1WNkNoTFJ4REJQLzMxUWR2QzQwSzNwcEtRQTc0elNtRDdO?=
 =?utf-8?B?c2dwUm40NG9OY013TEVmZW9sZ0hWVlAweldXek9WZXdTNHdNaGxJSFdncWxZ?=
 =?utf-8?B?bVhkTzRUcHgzRkI0bXlDVEJMT25RZ3B1bm40Znk0MGRIQ2JkeEU4RVBJWTBJ?=
 =?utf-8?B?aXVNV2ljdTgvQThObm56TEZpamY2cEFpWnJsOFBXTFRJb0FNT0RmczB0b3cr?=
 =?utf-8?B?bTBQYXNEaXJMa0xvSlpRaDVCNzhuTzZIcDRzaWh2MFhvMFJHRXZ6bHFENmlN?=
 =?utf-8?B?aHgzMHUxTEw5clQxV21QZ3FvODd6MkEyMjB5SDV2dGw3WEltUStFQkhZajFm?=
 =?utf-8?B?aTNETHpQWkYyUzFTdTJvZTNCeE9iQkh4YUZ3QmhqSFZkQjQxN3dCKzZBbTVX?=
 =?utf-8?B?ZmRWT1dsR2NUWHZ4WFk0QVJ3eHhBcGtzTC9wbE96Vm1uY1IyWTNGUkZBZnZM?=
 =?utf-8?B?eXpCV1gzeFNlUGx6WjRPdnM5b2txK1A2T25vN0txZ0p2eWt1NkdrQ09XeXVG?=
 =?utf-8?B?eHZWbVVMRUswTFFJb2ZsSUsrOGV1TVNPTEhvdlVtU3ZMM2NrNmpVbjcxRlN3?=
 =?utf-8?B?VWZlWjkzdHA2VUp5eGtzSS9zdFdxLzZOUUVWR3N3NzlXTHJKOEd1U0hVcitZ?=
 =?utf-8?B?VW43ZXpBZnRjby9FYnEyOWlodnhGVzZmQkJpTlFiWnNzWElJYjVaWUJQZjBk?=
 =?utf-8?B?MGZQSlNYem1UUEJGeUFMN01kdTl6VEZCU0g0emdtVWZpMUZ0TDhrc0wrc0hJ?=
 =?utf-8?B?YXlweHNTUmhmRm9qK0FpTVNtNEliRnFWNDVLSEdkZ0NyZ29veGZuWjZTRWQ1?=
 =?utf-8?B?c2RDSWlDWUUvUDZpbitxRXRZNEhwUnovZWp2S2p0cUNVeFNXMzZZWXZBUzJ0?=
 =?utf-8?B?eGxXbWt5OHBzYmVoNGdFWDcxL0JqWkFyYnN1Q2UrcVpjKzM5TEFPcmlnUXk4?=
 =?utf-8?B?YXN3WVg2RHk2Q0pIMm1nYmtOd0IwbDloNFFoTFFrcUkyUWh5bVQ1eFlwK0dM?=
 =?utf-8?B?YjE1ejFzd3IvdGhQcWVuVy9vdThsSlZERmZ4OFkvRGlhbVQyNlloOG0xVlho?=
 =?utf-8?B?dUFlck84TnFqUFd5dER2QjNOZzFpeW50RUVRNFltd1N5M2cvaTdsQ21TaFZ4?=
 =?utf-8?B?bzAramZDOXVrdHQ5S2V2dm5yZXRCYkZGeFdOUEYvNStvZnk0ZjhvL2xiM3JK?=
 =?utf-8?B?VlIzdmo0T1BBVDl2VDhsQWFwRWZucWNXNE00aU5NREhNYVI5NEcwdDlRYUVW?=
 =?utf-8?B?VW9PRWRRdlFqbVNTVFlQRFNLK2k4Tmh0YXBVR3hxUHBkczY1azZGbU8wdllw?=
 =?utf-8?B?Wk5pQllGREpEVGlKeTBneVVzaTZud0tESlUxbjNTTE5ZbFRsNXNobGtsYkxO?=
 =?utf-8?B?K2Y1SCsrY0lJamNnNGt3NW9pR0pnSXZVQ3dKcGI1YUdoUjN5dkJ2cThONGFh?=
 =?utf-8?B?dkpyYmkzVHdOWHhPL1hsck0wdmRHY3pnRHpQNXAzYUNFOEpydllxZmVpT0NX?=
 =?utf-8?B?dFdSamtuN3lVZkk2TlEyU1lrRGJBazRkVGdmMkt2NzVTdDRUNE5FMG5pcVpj?=
 =?utf-8?B?REhKMUczN3lWNEx2cGFwMTI3a1owRkRvUXJnK3BsL3lwOXRCYlF1TWc5K1I2?=
 =?utf-8?B?UHBCdW0rVmZSRzZURnFUL1NVYmRoWEVudXFBN0NLTzRVRkRaY2kzeGtoQWZ4?=
 =?utf-8?B?MEJNVVlLRmF1bXN3Ym93R0FhNXZ1MFRuZmZJTDJGczVYa0pkamNuVmYrQ3Bs?=
 =?utf-8?B?c3J3WjN2M2RBcEpoMVMvWnc3bGhkQk1qb041R1NXVTJUZVhSVzY1cGUyNlJZ?=
 =?utf-8?B?TkdJemlCU0dUZ25aV2d4ZDl2d2pLMUtzMjk0azkwNys2Si9jUmd5dUgyOEFh?=
 =?utf-8?B?UUl6Lzg4TVVUV1h2MWI4ZkFkVHJuZGN1YmgrZDFjOGN4K0EybVF3d2c2Si9q?=
 =?utf-8?B?ZllmbC9wL0dTdkJLMTQ1aFhkN0JWcFJZUVhUTUZ1bkltS3dEK1lvMnF1NDRy?=
 =?utf-8?B?Yis2NDJtbzF2SUJBV0xFR2IwSXh3YjRGWFJ1azd6VEt0S3dNOVhrYzdlZURK?=
 =?utf-8?B?cWxmclJMWTNvREZvTmxsbDZTU0RZOVYwOG1zZENCKy9uT00rZnlESWxjNFRY?=
 =?utf-8?B?Qlk3U0YxS0hKcjNaZGh3dVpudVdJdDlYelBobU5tVDhXWDBQank1QT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4208fa6f-3332-4b96-035e-08df045107bc
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 15:36:58.0546
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: es1ph1BhL27Z296R17CDhntnW3VdZYdZ6YTcxmKTcVUOqoPQ7edqz49Dw4hC/1FLM6LcRO148JZSWQr3LUlgn10zDiKDl4mgCrFbIrKEbeE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5560
X-purgate-ID: tlsNG-ebf023/1787845020-51CD7B50-CDD7688C/0/0
X-purgate-type: clean
X-purgate-size: 1582

On 27/08/2026 4:20 pm, Oleksii Kurochko wrote:
> 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 hardware
> + * 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_ = csr_read(csr ## H);               \
> +        lo_ = csr_read(csr);                    \
> +    } while ( hi_ != csr_read(csr ## H) );      \
> +                                                \
> +    ((uint64_t)hi_ << 32) | lo_;                \
> +})

This double reads H in the looping case.  You want something more like:

hi = csr_read();
do {
    old = hi;
    lo = csr_read();
} while ( (hi = csr_read()) != old );


Still, this only matters for volatile CSRs, and is unnecessary in the
general case.  I'd suggest naming it csr_volatile_read64().  Most CSRs
can use a simple split access.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:40:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:40:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401210.1636963 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcDb-0000Kh-DD; Thu, 27 Aug 2026 15:40:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401210.1636963; Thu, 27 Aug 2026 15:40:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcDb-0000Ka-9F; Thu, 27 Aug 2026 15:40:43 +0000
Received: by outflank-mailman (input) for mailman id 1401210;
 Thu, 27 Aug 2026 15:40:42 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzcDa-0000KN-99
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:40:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcDZ-00FkYY-30
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:40:41 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905a71-bab6-0a2a0a5309dd-0a2a4508b6c6-22
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:40:41 +0200
Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905a78-f659-0a2a45080019-d1558032ac96-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:40:41 +0200
Received: by mail-wm1-f50.google.com with SMTP id
 5b1f17b1804b1-495590dde14so21626365e9.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:40:41 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e27a9945sm9543491f8f.9.2026.08.27.08.40.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 08:40:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787845240; x=1788450040; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=kzDEVYEo7WZB5nmhHGg2SrGNKjaZ+3k8JrFM6QlK5KU=;
        b=G0yyvNoelk0WKi+m8TZC7dZVd9+JZG0F1wLhpEkD1GQCMf/dtHkiyfBfE5FVkSQcKJ
         LwWpI/JDIhe1nF3SC6zBuXB17X5NX2ubCtrvjAlfLadBuo8huldujdASF24q9/JukqdE
         RXf6XAAAwttWXfnF8QHBDA4r1qtwOteHvAbckwCVfixWKRJEc77BdmIJtKNJ1U+lBCPV
         wvdnOGwyaZEOeXnIam7r5tKiVZ5kLDkgukiacMUHTYTqlNkdDIpslw67+zLS7mt0iVEv
         4jqYCVCIYQozxk6WdX961Cuu5Mi0AF9fYBbUaBUUtT0Xrdj3hW7FslAOtXb/HpT3jq55
         CeLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787845240; x=1788450040;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=kzDEVYEo7WZB5nmhHGg2SrGNKjaZ+3k8JrFM6QlK5KU=;
        b=EUfW2Qs705eDtK/z0UHIXtOa7/izzg5tFiY64NbUF563OjG1pEt9i2PFFudgQ/ijdB
         L0+gu6rWh+IlWk9BpY3h0YSmYMLSv7LZIanL0pKWYSj/VSI2O7MSp/1JOGAfn71vKtrT
         ySf+ansuMNfNIKLpl+3zyuBqdVoqD/l1z3oHI64nWGBSSthBvuCT+uZk6cE+uZqx6MF2
         jPzBaFn+Dv4s44oF1qWwjDFEsy+1DT1hEgqOeWH6MAAD5W4Tkt71pu9EVc954RS9kuju
         xhLMf8w0Iq701OkWU40oa/DvEMOtKMGdly3Ioow/EjeT4hkdg0DQNwGXp5pha9DkShV+
         o/9A==
X-Forwarded-Encrypted: i=1; AHgh+RpHaC+1b4O0J4eqes0Zz5e6SO81S15rkC9xAzmKce2fFTNpixY1gE1TJ18cuqj+ijSBmeWVtCX9MH8=@lists.xenproject.org
X-Gm-Message-State: AFuF++k1AWSreDqleSx2YjsFKTxQ7oyak1wOQY8vZlbbgKSq0vy+QFEy
	Stn1HjcXhpNjSdXrlfwbwM/OBI3S4/Sh09kZ3qGnT8xA8ejKZPvziOSj
X-Gm-Gg: AR+sD11Fj9xuPXnU6SUW8vRXIPCSvA45YurHPxIJFabxvaKrLM00d8u4FbE9w8+ia4g
	2in5sl71y4S4BVoFdnidh5IWo+rxjsSmLHuo/2vV9VZRimk+JYj7ra1jjrJjkp6d1vM10eyinVC
	3bdiQvNYzsZx7RZ8wECu1bpi1v33L+vT4qvroJYpx6snOcIHxjdFgdcKaxCfOWG55G+wyIhurat
	ogZCqzs+hDtOOnuX+AIIvZSs3TjR/2+2NWgLqL+rolkZusTaY9Xzbedw6WsL/XMXvwinQmuQphk
	eXhq6/JdqMDfTyhY9O2OtB5a9U4Fb83pq38MUibKX6Oguy5a/SGcBOUjFtmt0Vxp9/H7m8pPWxY
	IGcXFBl9xPGICoNW8mmXH55Tbzfrcd6z62EFLP0Cd7f7noxfRbM1gLLIJgoFmJZJOarN1HHfcT4
	2jl+eDKxLW02wrE9UqwCRpGstqEfPxIgisDNRe3cQ9OLbNZDXix6tj0qENv9o+EWJjaSmYEEDw3
	RZsfAdFPCc/qdlErY50Duc3Gmh/8ObHD2wbrX3c3O+dx2KFAJCC
X-Received: by 2002:a05:600c:46cc:b0:49b:909e:922e with SMTP id 5b1f17b1804b1-49b909e92aamr36362385e9.10.1787845240450;
        Thu, 27 Aug 2026 08:40:40 -0700 (PDT)
Message-ID: <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com>
Date: Thu, 27 Aug 2026 17:40:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/7] RISC-V: place .sdata / .srodata /
 .riscv.attributes
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <f26f80e3-0b2d-429a-895c-b8003d1c5a38@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <f26f80e3-0b2d-429a-895c-b8003d1c5a38@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787845241-CDF4787B-D226F3F3/10/73395122804
X-purgate-type: spam
X-purgate-size: 6004



On 8/26/26 2:04 PM, Jan Beulich wrote:
> Of the short-data sections, only .sbss is presently mentioned in the
> linker script. Place them next to, but ahead of their "normal" data
> sections.
> 
> .riscv.attributes can go towards the tail of the image, next to (ahead of)
> debug info.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Seeing where .sbss lives, does positioning really not matter at all? I
> would have expected that short-data sections want to live close together,
> and specifically close to .text / .init.text (seeing that such data is
> accessed using AUIPC). I'm puzzled that the psABI doesn't even mention
> them, hence leaving it open how exactly they are to be used.

It doesn't, and the reason is that the relevant proximity isn't to .text 
but to __global_pointer$. The small-data sections exist to let a linker 
script cluster small objects around that anchor so that ld's relaxation 
pass can fold an auipc+load pair into a single gp-relative access (-+2 
KiB window).

That pass is keyed purely on the symbol being defined 
riscv_global_pointer_value() returns 0 otherwise and the relaxation is 
skipped. We define no __global_pointer$ and head.S never loads gp (it 
appears only as a cpu_user_regs slot in entry.S), so every access stays 
the medany auipc form regardless of section.

I confirmed this by linking the same object twice (look at the script 
below, with and without the symbol: without it, zero gp-relative 
accesses; with it, the pairs collapse.

Worth noting the relaxation is section-agnostic: in the test mentioned 
below a 400-byte array in plain .bss got gp-relative too, purely because 
it landed in range. So the sections are a clustering hint, not a 
mechanism ld keys off.

The script I used:
```
mkdir -p /tmp/gp-demo && cd /tmp/gp-demo

# 1. Test code: one small variable (-> .sbss) and one large array (-> .bss)
cat > s.c <<'EOF'
int small_var;                                  /* 4 bytes   -> .sbss */
int big_arr[100];                               /* 400 bytes -> .bss  */
int read_small(void) { return small_var; }
int read_big(void)   { return big_arr[0]; }
EOF

# 2. Linker script WITHOUT __global_pointer$
cat > nogp.lds <<'EOF'
ENTRY(read_small)
SECTIONS {
   . = 0xffffffffc0000000;
   .text : { *(.text) *(.text.*) }
   .data : { *(.sdata .sdata.*) *(.data .data.*) }
   .bss  : { *(.sbss .sbss.*) *(.bss .bss.*) *(COMMON) }
   /DISCARD/ : { *(.comment) *(.note*) *(.riscv.attributes) }
}
EOF

# 3. Same script, but WITH __global_pointer$ defined
sed 's|^  \.data : {|  __global_pointer$ = . + 0x800;\n  .data : {|' 
nogp.lds > gp.lds

riscv64-linux-gnu-gcc -O2 -march=rv64ima -mabi=lp64 -mcmodel=medany \
                       -ffreestanding -c s.c -o s.o

# Check the INPUT sections: .sbss vs plain .bss (the link merges them, so
# inspect s.o, not the linked ELF)
echo "### INPUT sections the symbols live in ###"
riscv64-linux-gnu-objdump -t s.o | grep -E 'small_var|big_arr'

# Link both ways and compare the generated code
for L in nogp gp; do
   riscv64-linux-gnu-ld -T $L.lds s.o -o $L.elf 2>/dev/null
   echo "=============== $L.lds ==============="
   riscv64-linux-gnu-objdump -d --no-show-raw-insn $L.elf \
     | sed -n '/<read_small>:/,/ret/p;/<read_big>:/,/ret/p'
done

```


> 
> What remains to eliminate orphan section warnings is the placement of
> .note.GNU-stack (which perhaps wants dealing with on all of Arm, PPC, and
> RISC-V together, ideally unifying with x86) and (odd at the first glance,
> but dealt with on x86 as well, i.e. may again want unifying) that of a
> number of .rela.* sections.
> 
> --- a/xen/arch/riscv/xen.lds.S
> +++ b/xen/arch/riscv/xen.lds.S
> @@ -44,6 +44,8 @@ SECTIONS
>   
>           BUGFRAMES
>   
> +        *(.srodata)
> +        *(.srodata.*)
>           *(.rodata)
>           *(.rodata.*)
>           VPCI_ARRAY
> @@ -92,6 +94,7 @@ SECTIONS
>           SCHEDULER_ARRAY
>           HYPFS_PARAM
>   
> +        *(.sdata .sdata.*)
>           *(.data .data.*)
>           CONSTRUCTORS
>       } :text
> @@ -162,6 +165,8 @@ SECTIONS
>       /* Section for the device tree blob (if any). */
>       .dtb : { *(.dtb) } :text
>   
> +    .riscv.attributes : { *(.riscv.attributes) } :text
> +

Nit: .riscv.attributes is SHT_RISCV_ATTRIBUTES, i.e. non-alloc.
:text on it is misleading, and without an explicit address it gets 
sh_addr from .(location counter) after .dtb. Could we use matching the 
idiom used for every other non-alloc section in xen.lds.h:
   .riscv.attributes 0 : { *(.riscv.attributes) }
No functional difference either way (objcopy -O binary drops it, and I 
verified a non-alloc output section doesn't advance dot, so nothing 
downstream shifts), so purely consistency.

Is dropping orphan-handling-y := from arch/riscv/Makefile the intended 
end of this series? As if I understand correctly with such defintion we 
will miss warning so everything of that will be missed:

cd xen
riscv64-linux-gnu-ld -T arch/riscv/xen.lds prelink.o 
--orphan-handling=warn -o /tmp/t.elf 2>&1 \
   | grep 'orphan section'
/usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.note.GNU-stack' 
from `prelink.o' being placed in section `.note.GNU-stack'
/usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.text' from 
`prelink.o' being placed in section `.rela.dyn'
/usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.init.text' 
from `prelink.o' being placed in section `.rela.dyn'
/usr/bin/riscv64-linux-gnu-ld: warning: orphan section 
`.rela.data.read_mostly' from `prelink.o' being placed in section 
`.rela.dyn'
/usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.init.data' 
from `prelink.o' being placed in section `.rela.dyn'
/usr/bin/riscv64-linux-gnu-ld: warning: orphan section 
`.rela.text.header' from `prelink.o' being placed in section `.rela.dyn'

Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:54:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:54:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401222.1636971 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcQb-0004WR-EO; Thu, 27 Aug 2026 15:54:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401222.1636971; Thu, 27 Aug 2026 15:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcQb-0004WK-BS; Thu, 27 Aug 2026 15:54:09 +0000
Received: by outflank-mailman (input) for mailman id 1401222;
 Thu, 27 Aug 2026 15:54:07 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1wzcQZ-0004Vv-ND
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:54:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcQY-003SbQ-6c
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:54:06 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a905d77-2eae-0a2a0a5409dd-0a2a4508dcea-38
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:54:05 +0200
Received: from [52.101.46.31]
 (helo=CO1PR03CU002.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a905d9c-f659-0a2a45080019-34652e1fcfbe-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:54:05 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CO1PR03MB7913.namprd03.prod.outlook.com (2603:10b6:303:274::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 15:54:02 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 27 Aug 2026
 15:54:02 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=giSA/179hl7G7gpHaQGs6d3pMVh2pvad00HmDvUM3SkOjcFdtbGmkoVAinw2fxOgfjbRr8dUnuwMl+1KW5YNowfjXBSk3Zx7P+lPz0nBoirQ3k+u7S2JKfnIny8Zk91VrpxT8FSasbqoQ1GWy57m47q6JHEyaJOzvVwQeN51foSMpkKlFTg+wNqFusuyWVi7xWRWm50o7WABmWbluInn+E2rZT79xnwDod8dH20ACVlxjTR4xb5R8ktqh4wUvQ+7Q2Jean6rwVxhvW3sItwZysuG8WCtRuA1OWZiviis+5nMM014se5s64AqpmgMUohjmsCoDE7g8JeSldJVMSHexQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tuNI2a00IKRkgX1VHfLyGsdp3gNtWpTxViEmiJ2soo8=;
 b=cI1okZVSfG+9gMyMNZuOnGShulUARQNuabsBBdJUxEIZs3LrDFydhqLXtlq3aA2MsyR5Xr8NnWbi1j5rHZL2ijULwyNF8clyu441eJIOzYl3vAcFUBMLGPVp40iyJntMVTRg/bB38JvUo5oCFfOnGoU1ofatwY8FWmwNX+e+KQndZs2Aklu3Wa+083IabrJriOVhnxnYiVjTo2WPl78YwHUawJs6la080HYRS/TnzmXUKbbOfbwgQN48bJHM40tSuf4VlMgrc1hPzfcBGpmAK8uQh86W0X+d1TY1N7F114HInSHzVa1hyBDxEtuTVbIdC2mGnhX9bXrM55BbZ6bg0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tuNI2a00IKRkgX1VHfLyGsdp3gNtWpTxViEmiJ2soo8=;
 b=EaGiPa+l5pzdG7LuL7wKSTKhB7U4ZCE6slaBSFHtDDYrsQ7fwe3dT0S6r2qskxe9LsZpumUfb8/V7are/dvqljaRD1SWSPZZJ1HGD3u0FAW+iYtIVxTUq71KKPSEJY0bIgzYgIhIYxx8thxJ6gQCvZJENvCtPyDTcZpyIphibFc=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <fbe6796b-19ef-4be7-9bc5-09d2281157f3@citrix.com>
Date: Thu, 27 Aug 2026 16:53:57 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>
Subject: Re: [PATCH v2 7/7] RISC-V: place .sdata / .srodata /
 .riscv.attributes
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <f26f80e3-0b2d-429a-895c-b8003d1c5a38@suse.com>
 <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P302CA0004.GBRP302.PROD.OUTLOOK.COM
 (2603:10a6:600:2c2::9) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7913:EE_
X-MS-Office365-Filtering-Correlation-Id: c7097832-31a5-4e49-0d33-08df04536a28
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|23010399003|1800799024|10067099003|11063799006|56012099006|4143699003|3023799007|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	pOG6Wa4YnG+TK2g3NLobF2YrySnGVNotTuAOFW0xkKqidpMPwke+F7j22/gRWjO+/RHeSpV6xw84i4Da5Q6EON3JydP4FZrOBuQocOYChL11O+iieq8RlndIPrluK3Uo05i5Nzb/AUDoT519xIMnxiXHu+NFtb7WPgH9EC1O+9ff9JJ6ghTc2/UqltEo6mnJCmjogLG4dUGDqS51JHfLGYWOOyGrOtoYOqqcAdOfmfanrBBl6mcweA/ZYeQzDr/FkQ+UeXO8f/C3tdg5bPJo+RDVdz4Tqoa/GwOrMlXnS7HSPeH0b9/uzCbiZElhEWWFnHV1j7W2JvyvCBcmmqwG7UnC42kSpLuMBT28yd+rll//7cWe66mzBCd0WrTbv9Sqo8pExhqPMTv922yTozGPRwL3XVJlgul5u6dfHfVQEqgvTYta/fGjpudyw6FVA9WEL7XPnrE9L7Bd1KrSGrRKClELhl77X6uUL0hfGpxbj7GcoGO6LF0jPaN+xau2id0w9itgo0h6O002/TY5bCjbkjUX6++8vXwc6mXg4ywsK6SG8rJTOwW8/zRUBA77FL+NrCw7QIokLc7LKADFKiNHWpMQ6ROxxOcUCBe6Hh+bZZKbmCcPlLOyOjYM3eHFTmspXZS3zOoTX4Nift4HQvzh7DcyyCeTZECiMcd04yHmoS8=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(23010399003)(1800799024)(10067099003)(11063799006)(56012099006)(4143699003)(3023799007)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ang5K3M3NWp4UUx0dGJ4WUtpUHFjNU5rVmF5TGdkeXN0a2RGUWRpeGdYK1NH?=
 =?utf-8?B?N3JDc1FaY01FZUF2Yms1dUJKVHN5NHZ2UytTZExwWENGRy9hYjZLcS9ONDlD?=
 =?utf-8?B?THF4REJ5WE9LRzBFcmVFa3MvMThLU0hwL1VOYkF6bGpzdzRGSmVRQVAwaDBO?=
 =?utf-8?B?OVpmS2xtOVdDNk9ZU0p6akt3b0xHVU11MmpZc25zbW9FbEdTYUdiM2lLZGh0?=
 =?utf-8?B?STFDR2lhV09oZ3c0Z2xLK0t3aGRIMXcxa01jK2o2K0NmdCtibVhHYWtZaE11?=
 =?utf-8?B?K1ExWFZza1VMeTBKcnVtbVB6WXU2M2d3OFVTcWNHOWtYbVQzakI4dGFQVFVx?=
 =?utf-8?B?OFJYaTE2TDEwVTd1Tk4zRHV5WTRoOGxiR1BUZXZMMGFic3F3bHA5MUpVb1kr?=
 =?utf-8?B?Q0J3NEUreTJvNTQ5WVdaQ1M5UEhjZEpTcVl4NkRiUFBsMllRaVRid25TNmNk?=
 =?utf-8?B?akF2Q2p2NWpSZGlWNDY5REQvNmdGTGJvczMrSjRqNDJ4OFZQRVB5b2pWU2ZC?=
 =?utf-8?B?bUJ5cjhHSzV3UkF4c1VaQWErN2RNZjVqWVA3cHEvYzlnT0ZQR0JraENURC9v?=
 =?utf-8?B?RUtYTGxoRUxpeDRXWjdHVW5iOGhaUzlkMHFuS0hoWWdrM0d2NmxKaWh3azNy?=
 =?utf-8?B?MEw2ZWQ4U3dOaDNoRElwM3pWTS9GM1h5VFVyM3FIcUUzN1FvbWR4QUhpMTZC?=
 =?utf-8?B?QWNkcGwyS0g4eElRR3dxdStPRWFGcmlGTkYwTm5KUitpYUw3K213aTJuTTZJ?=
 =?utf-8?B?YWpFdjFMUmpsdnZIalVneFNSNmszb2JSWndSNVdIMWpsZUNRanpFYUxaY3hD?=
 =?utf-8?B?dWh4M0N4MTVmd0s2bVpGVENLU3BWTVR4WGg1OERGTXJUOW9UWFExRExVVndx?=
 =?utf-8?B?QkZRdkFLelhGOU16L05sWlVtTlcycVFFSWhKVjBPY014M3dBNGhydVNYRWEw?=
 =?utf-8?B?RSt5SXhla3lUVDVIUzl5TWV0eUpJU0hUSXNLaWhpSkt6ZnBhM3N1NjliOEVO?=
 =?utf-8?B?NldadVJXdjZtTlNPSXUyaFB6LzZ4c3JRUFZJVWh0Z1pFRDZrcDU4Y2E1a09U?=
 =?utf-8?B?bmpuc1Q1VFI5dnA4ckNFSFBBWnJKMFdBajJaNTQycWlmSXczcEN4VTRQWUs4?=
 =?utf-8?B?RUgvUFpGZ0Rpdmg4Zll0Um05Q0x1MDhZbmtzMUJYbjBZemY5cmo1TklXTFNR?=
 =?utf-8?B?SlVsUUZ3dHg5Wkp1YVgxYWlQVUQwMjV3cVd4RE1UQTdGbXBhNjBlQ1lUSUY4?=
 =?utf-8?B?aVZPZjRjTEk5ZnVhaStlVFdnUlVDM0YwZ2QxTFdKSVA5ZUZRRXowQllHaTNO?=
 =?utf-8?B?eWQ2bkUwODIvMklQUUttblBYVG81aFBnVXdpL3N3dEsrSVl3b3ltZGg2OFZr?=
 =?utf-8?B?aTZmOUFJMUtSc2dwN29zN1RVTHk5L3I5SXdEdjlqbmQyZTZHN29lbGs1aHJV?=
 =?utf-8?B?cjRwMHB2eW1ac004OFFMeXQ3T3dSN3FDendaUFZNUDNIeXlqUm1PZFNnK3JV?=
 =?utf-8?B?c2JFNXYvSnhxMHlSNlozSTlIbVdiRG9HM0kzQzBObEkreGhnM2lsaGlxZjBv?=
 =?utf-8?B?YTVDWjU5YW1NYk01bkcrWmVla3R2ZUFQbzJOVE1DVW9CUnoxYXl2dUxmMXQz?=
 =?utf-8?B?V2pFTFhGMkViRzY4aTB1eDVIYlp4bEMzbnk4SkRRcU5OSmVYWWJsekpWSTJO?=
 =?utf-8?B?ZHJ6VTByUHc1RGlWT2JZemxQdEtPTEswZlIxMnRoYlEva05FdVJNbzVkNWd2?=
 =?utf-8?B?NEFDaERISkhGUHhLRHhHVWxXVzlSSWI3eVp1VGp4MHhsa0dwc2VwWmp0TzBE?=
 =?utf-8?B?YlJZalhCY29iUTVjUExEV2pjdUo5RHVjS01yS09ob0k5QkcrRVVBeE5xUmpl?=
 =?utf-8?B?ZHUxNWNidWlNbEdNVExsa2djdVZaemd2SzA1cWF1VENOVVcrSEtNUzROcUFN?=
 =?utf-8?B?UUd4NitvbW1EalBabXZVQUp0OFlTbHdSRW94NzRmTW5uYWJoUExYK0F0aWc2?=
 =?utf-8?B?dldObVZ3V21BR0k3dWpCTDMrZ0JEanFtTm93NEY0OWxvc3MxaHlsTERRQjR0?=
 =?utf-8?B?cGcySWdidi9VeE1CU2tkWlJWQUVhdWdWQUdJUnRuOS9KNHdwOFE5ZWoxUXBL?=
 =?utf-8?B?b085aTFVbnlhcXBicElnM1ViN056RWdXaHdsVXA0T1lwVTNjMTkvSGdpNGhQ?=
 =?utf-8?B?YXpVRU91L2RiM0NBOG1mY1d6YW14RmdiUTRTSHVvUTVQUnVlY1NwYWtKVkZk?=
 =?utf-8?B?V292ZFpaMjYwRUhya3ZLOXBKYXU5dkJjdVFaRVQ3dGVnblo0ME80VjJVTnF1?=
 =?utf-8?B?aGJZMUJuZGp2VEhoMUdHd2lXcVlwcEFMWjh0VS9vT01Qa3o4SmM4QT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c7097832-31a5-4e49-0d33-08df04536a28
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 15:54:02.1547
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2iU477X5Kc9Sxufn2a32yi6qCuhMx8oB8GrNsIN9Wron41tQJGGXKmZaJ4kFjvjiWCZ64Zg4rNcu86eZyNcnwVhG4f5X9bS/ETVB1rTx/gg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7913
X-purgate-ID: tlsNG-c1860d/1787846045-CD14E87B-5B276798/0/0
X-purgate-type: clean
X-purgate-size: 1527

On 27/08/2026 4:40 pm, Oleksii Kurochko wrote:
>
> Is dropping orphan-handling-y := from arch/riscv/Makefile the intended
> end of this series? As if I understand correctly with such defintion
> we will miss warning so everything of that will be missed:
>
> cd xen
> riscv64-linux-gnu-ld -T arch/riscv/xen.lds prelink.o
> --orphan-handling=warn -o /tmp/t.elf 2>&1 \
>   | grep 'orphan section'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
> `.note.GNU-stack' from `prelink.o' being placed in section
> `.note.GNU-stack'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.text'
> from `prelink.o' being placed in section `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
> `.rela.init.text' from `prelink.o' being placed in section `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
> `.rela.data.read_mostly' from `prelink.o' being placed in section
> `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
> `.rela.init.data' from `prelink.o' being placed in section `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
> `.rela.text.header' from `prelink.o' being placed in section `.rela.dyn' 
>

Orphaned sections are a huge source of bugs.  Right now, only x86 has
any kind of orphan warning, so the `orphan-handling-y :=` is maintaining
the existing behaviour.

Longterm we do want to delete that override, but IMO it should be
follow-on work, rather than being part of this series.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:56:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:56:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401230.1636981 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcSq-0005cs-Qu; Thu, 27 Aug 2026 15:56:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401230.1636981; Thu, 27 Aug 2026 15:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcSq-0005cl-NB; Thu, 27 Aug 2026 15:56:28 +0000
Received: by outflank-mailman (input) for mailman id 1401230;
 Thu, 27 Aug 2026 15:56:26 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzcSo-0005cd-Qb
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:56:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcSn-004oWU-Jf
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:56:25 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905e09-8faa-0a2a0a5109dd-0a2a4503c972-42
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:56:25 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a905e29-fae8-0a2a45030019-d155dd35e502-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:56:25 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-4815bce4652so1553900f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:56:25 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e28f854dsm10068456f8f.36.2026.08.27.08.56.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 08:56:24 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787846185; x=1788450985; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Acg5xlPcpI2IlVuCZmrMC6RuFRWhY/MURDTNlQ5CB7Y=;
        b=s7JuPBg9Ba3doIFCDAFvpbW0RprMwUwdJn+1Maxd7qbQJTrsrwPH5PqkvGhik2hObj
         6ttRFfrvzzFMU9u8QzGGYypxehgqYU3Vd0ewEZ0Qt60TVbCzG9w3Rze36xaLyedaqCNZ
         qo6p6qerS5iDW+woeaofErI5gweKHxv1JuryPEkvnR61z9gYmldVNgOEmgweIQ8Zj1WB
         8dqkTexKVSun/LjQdJX1/Un9gREGw1U5hew8bR3x2nRBq4NPZRlAr4gmjWrnV70iRKrF
         TVqXyZEPhTtvG/IKXLVQpqfcB4RahxMNLkZlo/izz+4g825GMpZYC2qUfOWxvKgtZnI6
         NI8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787846185; x=1788450985;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=Acg5xlPcpI2IlVuCZmrMC6RuFRWhY/MURDTNlQ5CB7Y=;
        b=U6dOWzLaT23s5wN2TQICTWipnz7unqJOAvURnysycNIJlL7yNGklORSOJnYjQczymR
         gPCObJYSMPMledwYS3VExPN88v31r0UVcL6EP06Ev1zoYDM49a2l90dlCo5wm5eIRFEs
         0KaSGjjgjUNan53lDmEscjz+fhGYaUoo4Ay44Dxp/fDysdcF6tpaTh1KDRZESxValbEJ
         JkcNEjmxVqFtNjPiDN4I6GkE/RH40wqxCrAfxtJ0Hm3uGQX78N6cYWV5NhwSfhhyAxjW
         1euuEPxNkE7sr5pLRVsf5odxECBROsJ9lUsrzo0Dtmp2zIfh4hJ87JY0BKCrgoXwjsk4
         VNQQ==
X-Forwarded-Encrypted: i=1; AHgh+RqEUkZbFhXXbAge9FiLnKO75K4JetUZ8CUrv0aGg0QYpb87AQpaaUgHg7YBzfgGEd5ywCdgWFcS1r4=@lists.xenproject.org
X-Gm-Message-State: AFuF++nQ8aYsjs5Xdrx4kWPyDIpIyP/lE9EDe132h9kZ6siZKJZ+D7o5
	97Fbs38oz6TlZxvvYs6e0HuIv+kJtG/Gy5ktxsuHsSDcvJXYzLgLPGlH
X-Gm-Gg: AR+sD10G8nVurWoM6QrmzoFUMNCKCm8PTmRVNz6tvLp/8E0KbLGjNxeOUczm/PZ/Nyp
	FsmaPSoBkr8neikghl9OL6dEig6iIUzD6WptxwmRL08ULs6EqhJrNtYBO83G1zeEJ/pLKwtg+2m
	uB4+bjDjtznImFBkiUU1VAYggLtwdJ/M4I85COtyhRUdzFxvv6G9ysb21KeGuDC1D4WXoweI7gA
	eeWguYJFGOq3cV5yNyR91mfpuqjcuPcACxHefo2cHwOmyC8WaBMfLqBAOz4w/y0jp1ZnKEpKgPG
	963YU36tU1MhZrlHd82sBHeFeP0FaUC57//bp4YGD1G5nUOvON62IbzfFcAYfdk1EeMAARaurPx
	tja2l63HxQ6diU7GMTr/oTfMEC7Xfp57b7bcaNMuYBz5C3MPj1mBpE3XqQtsn3rEcryr9YmuijI
	ipwJlsWl/6i5LVa64ayZCyg2786Y1lVrNcEm0JGCSwrzuLgnfNWXPYB8XbTW59vwBxA9bX9xPnh
	tOmbNpdMlx+KhR+hR4cDfGbzwon/ewjUU49svDikkU=
X-Received: by 2002:a5d:64c2:0:b0:482:e10e:58df with SMTP id ffacd0b85a97d-482e26d51e8mr22927647f8f.21.1787846184911;
        Thu, 27 Aug 2026 08:56:24 -0700 (PDT)
Message-ID: <f0510fd7-32fc-4fbd-834e-68bba14150b9@gmail.com>
Date: Thu, 27 Aug 2026 17:56:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/7] RISC-V: split xen-syms linking rule
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <6f4b26ce-2797-4c17-bfdf-8effd2026a6a@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <6f4b26ce-2797-4c17-bfdf-8effd2026a6a@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787846185-776F34E9-EA55D124/10/73395122804
X-purgate-type: spam
X-purgate-size: 4361



On 8/26/26 2:01 PM, Jan Beulich wrote:
> Doing so, besides (hopefully) adding clarity (not the least by way of
> [re-]using pattern rules where possible), also avoids explicit recursive
> $(MAKE) invocations.
> 
> By re-using the generic rules introduced when the respective x86 rule was
> split,
> - the .map file now isn't created after the final binary anymore,
> - --strip-debug is passed to $(LD) during early linking passes (for
>    consistency the option is also explicitly added to the optional linking
>    pass rule),
> - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
>    now properly respected.
> Orphan section checking, otoh, is getting suppressed for now, until the
> about a dozen warnings which would result have been taken care of.
> 
> While the 4th linking step continues to be avoided when possible, a
> redundant invocation of $(NM) and tools/symbols (plus the assembling of
> the resulting .S file) is hopefully deemed acceptable.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -31,40 +31,12 @@ obj-y += vtimer.o
>   $(TARGET): $(TARGET)-syms
>   	$(OBJCOPY) -O binary -S $< $@
>   
> -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
> -	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
> -	$(MAKE) $(build)=$(@D) $(dot-target).0.o
> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -	      $(dot-target).0.o -o $(dot-target).0
> -	$(NM) -pa --format=sysv $(dot-target).0 \
> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> -		> $(dot-target).1.S
> -	$(MAKE) $(build)=$(@D) $(dot-target).1.o
> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -	    $(dot-target).1.o -o $(dot-target).1
> -	$(NM) -pa --format=sysv $(dot-target).1 \
> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> -		> $(dot-target).2.S
> -	$(MAKE) $(build)=$(@D) $(dot-target).2.o
> -	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
> -	then \
> -		set -e; \
> -		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -		    $(dot-target).2.o -o $(dot-target).2; \
> -		$(NM) -pa --format=sysv $(dot-target).2 \
> -			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
> -			> $(dot-target).3.S; \
> -		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
> -		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
> -	else \
> -		ln -sf $(dot-target).2.o $(dot-target).3.o; \
> -	fi
> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
> -	    $(dot-target).3.o -o $@
> -	$(NM) -pa --format=sysv $@ \
> -		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
> -		> $@.map
> -	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
> +LAST_LINKING_PASS := 3
> +
> +include scripts/Makefile.link
> +
> +# Suppress orphan section checking for the time being.
> +orphan-handling-y :=

This works, but I think it's worth reconsidering the shape of it.

It works only by virtue of deferred expansion: $(orphan-handling-y) is
referenced solely inside the recipe of the final-pass rule in 
Makefile.link, so the value that matters is the one in effect when that
recipe is expanded, not when the rule was defined. Nothing states that
requirement, and nothing enforces it.

What makes me uneasy is that the ordering is not merely undocumented,
it's inverted with respect to the obvious reading. Makefile.link has

   orphan-handling-$(call ld-option,--orphan-handling=warn) := 
--orphan-handling=warn

i.e. an unconditional := to orphan-handling-y whenever the linker
supports the option. So an arch that sets orphan-handling-y *before*
the include has its setting silently discarded and ends up with orphan
checking enabled after all: no warning, no error, just a dozen new
linker diagnostics appearing at some later point. And "before the
include" is exactly where one would naturally put it: right next to
LAST_LINKING_PASS, which is the one knob the arch Makefile does set up
front.

I am not insisting on reworking but probably a small comment (in the 
commit mesage at least?) somewhere about that "+orphan-handling-y :=" 
should go after include will be useful.


Thanks.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 15:56:30 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 15:56:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401231.1636990 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcSs-0005q2-7Q; Thu, 27 Aug 2026 15:56:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401231.1636990; Thu, 27 Aug 2026 15:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcSs-0005pq-2e; Thu, 27 Aug 2026 15:56:30 +0000
Received: by outflank-mailman (input) for mailman id 1401231;
 Thu, 27 Aug 2026 15:56:28 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzcSq-0005ck-O4
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:56:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcSq-003T5w-4i
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:56:28 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a905e20-2eae-0a2a0a5409dd-0a2a450886a0-24
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:56:27 +0200
Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a905e2b-f659-0a2a45080019-d1558034e04f-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 17:56:27 +0200
Received: by mail-wm1-f52.google.com with SMTP id
 5b1f17b1804b1-49b8e527d63so6730925e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 08:56:27 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b8d2ba486sm38337815e9.5.2026.08.27.08.56.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 08:56:26 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787846187; x=1788450987; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=HHEE/gXyj0DP9lcj+bQ/1E1HsxUUYdXKZoMB8d/ktNU=;
        b=d2PzyySTh5TsBvo9Xc61FQbX2iudkePTm6WK1qTqLIu4ZW+m6i8A/RG/DOrcosnSa1
         ZtJSQhc6FbH33YD70orFxeqotB+9Mom2Czgz4mu49s60VlPyliV5DXTLyBawPOVuCKKN
         RHp3DaN3oiQxHLmLP2UGU/dK1CajRHakRMy8SCdYFhqHtacfEJEtHoqOvFBFaD3jObz0
         zMnfa0tiwJt2RvIsV2f6NOzYiuxO7qvTCpsH/U7sHpKio8+IThSHUoOwBepAQbkgP2+j
         FlUvSRZJfkM3pC8fFinVexHa7Yf6APm6qkYaiX0b4Ab2Rz0ehVdc3hWYq2pVoW9VJljV
         eScw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787846187; x=1788450987;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=HHEE/gXyj0DP9lcj+bQ/1E1HsxUUYdXKZoMB8d/ktNU=;
        b=nEc7/bFoftvLAWTFXE+BZCZDK+zVqBz75sn0V6smsaRPuFn6HqDNXCNfm1zLv24j9o
         UXfzEyC9CQpBB/ybPfqkNGrYH7UCExw5PzoLaf7T6n/hE/Os/0HgEorh8HYfQIC2im24
         VWm3qsuSys/0j1RdCOYrKt5oCf/mxxptAg2APkFVStY0eVxEPxRi81kAJmxFjgPgVNel
         qd5SrJjxrpPY4KVTxyNsZyOwjnS4+d8fLtYJxOqLM1xbSOfoKM++z1VELOBK4zBSKWpU
         JJA+HW8mQoNC6UuUnrmWCt8h68ISX07eQYC9fjAsXXBYa7/bDgtSZnGElJsrnrh8jVB+
         AphQ==
X-Forwarded-Encrypted: i=1; AHgh+RqkIR9+A0C22BXdOSe6OizusBdnlJH+Ironlm/a8aM1CLBolFeNZcus/wpXPEtFpJD3c4ryjzmemjI=@lists.xenproject.org
X-Gm-Message-State: AFuF++k3ij4qZO/l8JeFtYUNheRzo5YCdNRVVh9/FHuJ0vEScqdthrIF
	uIdnyK28AYJAI4WCVAmBiWtpc/2C2OCxA+x+sOO54sSTJQc02srcFWb3YgXQAmJvEw==
X-Gm-Gg: AR+sD10KNvbSLOHP9T2K3LraVjDjF8E8eC0WtOVkqDjeAT5eechuUQYi69+o73jpJFG
	tjK/17bFISpmqxUkVNiuog0sDGyYyhmwmzN67KAGNpZpCFcwE79CZeubncXyOFhVaxH5GJwV/35
	hNhnc2LTMgTW3O4o61jRWyUkln5+3vHXZ6Cax/6Te8hPygWZ723gzPmC3npLFzO+h1QUmfOqwnN
	jjdON+UL4xaRYguzsn1USOjclnkWYZGp8FpLe7QlWJ0JfxeQS6f28kgZvJw7+VMsC/wLYzx/wJi
	vdPq0sm28VpsZVCaRTb2RW1/2IsaZO8wZZzqHBLXNDqvcKIsny8H2gVnERyvugdIGAjsV/JeX4H
	gEfDZq/X/QCCGIpIVegohP85nE18av+pa8mT6i9xYjOl7hJGCBdwK1gWowPcZ5Yt9eEhR2nkzUc
	Wzsb0Nqw5ivbE6bLRQ4+WkLh7deXATv52MslGt7toLs+WTFfe5bIJMlXxzze1kEvTD1b+jAGFFs
	ajju+scb6bUH/03mmwUqlQD7BbJNAO2IEawj/MrKC29qDn0iWdO
X-Received: by 2002:a05:600c:8518:b0:499:be2d:c290 with SMTP id 5b1f17b1804b1-499dc720ae9mr234254945e9.9.1787846187319;
        Thu, 27 Aug 2026 08:56:27 -0700 (PDT)
Message-ID: <8eebbdd6-d414-49eb-83e6-668f187e6f93@suse.com>
Date: Thu, 27 Aug 2026 17:56:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/7] RISC-V: place .sdata / .srodata /
 .riscv.attributes
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <f26f80e3-0b2d-429a-895c-b8003d1c5a38@suse.com>
 <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787846187-D674387B-F37BB47A/0/0
X-purgate-type: clean
X-purgate-size: 5458

On 27.08.2026 17:40, Oleksii Kurochko wrote:
> On 8/26/26 2:04 PM, Jan Beulich wrote:
>> Of the short-data sections, only .sbss is presently mentioned in the
>> linker script. Place them next to, but ahead of their "normal" data
>> sections.
>>
>> .riscv.attributes can go towards the tail of the image, next to (ahead of)
>> debug info.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> Seeing where .sbss lives, does positioning really not matter at all? I
>> would have expected that short-data sections want to live close together,
>> and specifically close to .text / .init.text (seeing that such data is
>> accessed using AUIPC). I'm puzzled that the psABI doesn't even mention
>> them, hence leaving it open how exactly they are to be used.
> 
> It doesn't, and the reason is that the relevant proximity isn't to .text 
> but to __global_pointer$.

Anything like this still should be set forth by the psABI, so I don't
quite understand your reply.

> The small-data sections exist to let a linker 
> script cluster small objects around that anchor so that ld's relaxation 
> pass can fold an auipc+load pair into a single gp-relative access (-+2 
> KiB window).
> 
> That pass is keyed purely on the symbol being defined 
> riscv_global_pointer_value() returns 0 otherwise and the relaxation is 
> skipped. We define no __global_pointer$ and head.S never loads gp (it 
> appears only as a cpu_user_regs slot in entry.S), so every access stays 
> the medany auipc form regardless of section.
> 
> I confirmed this by linking the same object twice (look at the script 
> below, with and without the symbol: without it, zero gp-relative 
> accesses; with it, the pairs collapse.
> 
> Worth noting the relaxation is section-agnostic: in the test mentioned 
> below a 400-byte array in plain .bss got gp-relative too, purely because 
> it landed in range. So the sections are a clustering hint, not a 
> mechanism ld keys off.

Okay, fine, but what does this mean for placing the small data sections?
I.e. what does this mean for the patch here (which really it shouldn't
have been me to write in the first place)?

>> What remains to eliminate orphan section warnings is the placement of
>> .note.GNU-stack (which perhaps wants dealing with on all of Arm, PPC, and
>> RISC-V together, ideally unifying with x86) and (odd at the first glance,
>> but dealt with on x86 as well, i.e. may again want unifying) that of a
>> number of .rela.* sections.
>>
>> --- a/xen/arch/riscv/xen.lds.S
>> +++ b/xen/arch/riscv/xen.lds.S
>> @@ -44,6 +44,8 @@ SECTIONS
>>   
>>           BUGFRAMES
>>   
>> +        *(.srodata)
>> +        *(.srodata.*)
>>           *(.rodata)
>>           *(.rodata.*)
>>           VPCI_ARRAY
>> @@ -92,6 +94,7 @@ SECTIONS
>>           SCHEDULER_ARRAY
>>           HYPFS_PARAM
>>   
>> +        *(.sdata .sdata.*)
>>           *(.data .data.*)
>>           CONSTRUCTORS
>>       } :text
>> @@ -162,6 +165,8 @@ SECTIONS
>>       /* Section for the device tree blob (if any). */
>>       .dtb : { *(.dtb) } :text
>>   
>> +    .riscv.attributes : { *(.riscv.attributes) } :text
>> +
> 
> Nit: .riscv.attributes is SHT_RISCV_ATTRIBUTES, i.e. non-alloc.
> :text on it is misleading, and without an explicit address it gets 
> sh_addr from .(location counter) after .dtb. Could we use matching the 
> idiom used for every other non-alloc section in xen.lds.h:
>    .riscv.attributes 0 : { *(.riscv.attributes) }
> No functional difference either way (objcopy -O binary drops it, and I 
> verified a non-alloc output section doesn't advance dot, so nothing 
> downstream shifts), so purely consistency.

Well, I compare attributes rather with notes, which we make part of a
segment (on x86 at least). I can drop the :text if it's that what's
needed to get this in, but I'm not fully convinced. But my knowledge
on the purpose and use of attributes also is still somewhat limited.

> Is dropping orphan-handling-y := from arch/riscv/Makefile the intended 
> end of this series?

It is the intended goal, but not by the end of this series.

> As if I understand correctly with such defintion we 
> will miss warning so everything of that will be missed:
> 
> cd xen
> riscv64-linux-gnu-ld -T arch/riscv/xen.lds prelink.o 
> --orphan-handling=warn -o /tmp/t.elf 2>&1 \
>    | grep 'orphan section'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.note.GNU-stack' 
> from `prelink.o' being placed in section `.note.GNU-stack'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.text' from 
> `prelink.o' being placed in section `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.init.text' 
> from `prelink.o' being placed in section `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section 
> `.rela.data.read_mostly' from `prelink.o' being placed in section 
> `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.init.data' 
> from `prelink.o' being placed in section `.rela.dyn'
> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section 
> `.rela.text.header' from `prelink.o' being placed in section `.rela.dyn'

Yes, if the override was dropped, these warnings would appear on every
build. I thought that may not be wanted, hence the override I put in
(really everywhere except for x86, where things were already tidied).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 16:01:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 16:01:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401243.1636999 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcY2-0002FS-Pr; Thu, 27 Aug 2026 16:01:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401243.1636999; Thu, 27 Aug 2026 16:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcY2-0002FK-Li; Thu, 27 Aug 2026 16:01:50 +0000
Received: by outflank-mailman (input) for mailman id 1401243;
 Thu, 27 Aug 2026 16:01:50 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzcY1-0002FE-Re
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:01:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcY0-003Tw0-74
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:01:48 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a905f67-8faa-0a2a0a5109dd-0a2a4503ab5e-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:01:48 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a905f6b-fae8-0a2a45030019-d155dd29d8a3-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:01:48 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-47fecbb7000so1135944f8f.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 09:01:48 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-499dd56dfb8sm70974795e9.3.2026.08.27.09.01.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 09:01:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787846507; x=1788451307; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=QcLMgCFTN25bO7TW3QA46L5cvl4mDFQlktzMwYj2fMk=;
        b=XN5ZfWi5nF6fECIuaGBcPlKfp5lVoOE06wqIy2pck7E3J/n1qoNNiWrVGX+RFVm0qj
         gPUGIvSmuFDF8D27z/awEhq5xgbjBgCKgTNlXnBIVfv0XvcIB6ZBQTrQEy3IQWwTkKOo
         S5WSdVky3LSrkej+wFzfRKbJ1zC/7j7jxrZpn4NhH83brMBfq1fSHeOyneq2UDmHbiFq
         cFlYaUAn4tcCUEWLqTce9uBaBQusFfgjZe0xaUupBU3ilh4XJt5GN6f7UCweGsn12zJe
         BMovZlaurvbs9QQcNlswhxnTXalcl61+aXy0Ed0+FQ6IJgI3e0e9FNp7KAwTCiuct/8+
         HBOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787846507; x=1788451307;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=QcLMgCFTN25bO7TW3QA46L5cvl4mDFQlktzMwYj2fMk=;
        b=FSWe8gBbs7lxeWydJAzDyjITtafNHmis1DpVb/bv/cEL8GslYaXjp54Rkdx/dO26nf
         sXEedUHalJ82MYbufvuq2/lBOBxsBk7Y2BPYcSjNfAkWlQ6wYhneeNqgH6d8mIcs76mW
         q3hBj8gyGXq5QMRkht3KPqqTZgk7DSObBIm8fPcK5n354+0uEW5PtxUT3APGzrIk3jrY
         oo0dinAWNLKdDRRN6EL0XqKeYO18SV862y15M/wn8KpxgXL6jFVZvTXkeXJNOhekR9RE
         WWo97nz9pdkY/SgYijhv7COjGjyMTuZiWhZZr5cBsYHEYyRYjWI3ijLl9N9TwJc593t0
         VK4A==
X-Forwarded-Encrypted: i=1; AHgh+RpPcQiWdLaoMcFLXNVUIsMSLs1VlsgRDA5e5PyF6wCAqXeBJpOcjBjjlJnGHxNn3Hyu6XR6O0CibZE=@lists.xenproject.org
X-Gm-Message-State: AFuF++nAnxV4l7By+wKsp8Jbr9ZDluMVmHRWSErqv0smuUfw5JX9MgJ/
	a8sAy1BYz5lQ7+GdAPxn3BUWDdwIRj2xyGCPQvOMUQYPGDQz+inH779+bUOKAezKGw==
X-Gm-Gg: AR+sD11XpYCdoeWvNr6yTlw9Izi9r4RWrwz6QAtTdhSBO/U4OYPc34g9XNtWfLko2RS
	tK2RxguCa+bt2IUu0aU3wRT3uLIdBteo40uUVpTercyJzoQNRorr83zTAyVbveRUq00Czi29HgI
	Xv7uIJgAk3Pn64NtMxWsQV/u3Yp9PHtBI5HdDwQ5EjJgA++RXWatMZ5JcTEUJ/GWDc4YcReob9j
	nOYlQyXt3VQD0mRl5QTeT4/3sWgjO8J+GnQMLJk1zJv7a/dWE0FgBRJcWp9rewoiAxjD4MTv6dy
	XU0eZM1iJR6kX1XCVpYuQ39ujl6Okdw2p9wXBGijBCwciuY7VmsH186D3SSyvq7zUkkrozZ5Mm9
	1BbdsL0TDPWk+/JL53l5Gt+7MXBXG8SAuSrfqeBelVRdaWnmcS2JfebjUOrUGW34oCPUsq6CYNX
	YDZlXoR+8MkCtHX2G5c5UNT2ZCTfDIhW8+JjO7pHbTCPaf/MPLN3bNCNvkag1x8BoeA3eRW60YW
	shSteXsMBWCQmDEcWzKCNle6oqxs1C+MEWRh5YilJR9yzGfyue6
X-Received: by 2002:a05:600c:3e0b:b0:499:adb5:e7b2 with SMTP id 5b1f17b1804b1-499dc717dcbmr242919395e9.11.1787846507446;
        Thu, 27 Aug 2026 09:01:47 -0700 (PDT)
Message-ID: <15abd61a-045f-47d1-94fb-b5febf28711c@suse.com>
Date: Thu, 27 Aug 2026 18:01:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/7] RISC-V: split xen-syms linking rule
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <6f4b26ce-2797-4c17-bfdf-8effd2026a6a@suse.com>
 <f0510fd7-32fc-4fbd-834e-68bba14150b9@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <f0510fd7-32fc-4fbd-834e-68bba14150b9@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787846508-750864E9-DACE2AF9/0/0
X-purgate-type: clean
X-purgate-size: 4761

On 27.08.2026 17:56, Oleksii Kurochko wrote:
> On 8/26/26 2:01 PM, Jan Beulich wrote:
>> Doing so, besides (hopefully) adding clarity (not the least by way of
>> [re-]using pattern rules where possible), also avoids explicit recursive
>> $(MAKE) invocations.
>>
>> By re-using the generic rules introduced when the respective x86 rule was
>> split,
>> - the .map file now isn't created after the final binary anymore,
>> - --strip-debug is passed to $(LD) during early linking passes (for
>>    consistency the option is also explicitly added to the optional linking
>>    pass rule),
>> - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
>>    now properly respected.
>> Orphan section checking, otoh, is getting suppressed for now, until the
>> about a dozen warnings which would result have been taken care of.
>>
>> While the 4th linking step continues to be avoided when possible, a
>> redundant invocation of $(NM) and tools/symbols (plus the assembling of
>> the resulting .S file) is hopefully deemed acceptable.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/riscv/Makefile
>> +++ b/xen/arch/riscv/Makefile
>> @@ -31,40 +31,12 @@ obj-y += vtimer.o
>>   $(TARGET): $(TARGET)-syms
>>   	$(OBJCOPY) -O binary -S $< $@
>>   
>> -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
>> -	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
>> -	$(MAKE) $(build)=$(@D) $(dot-target).0.o
>> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>> -	      $(dot-target).0.o -o $(dot-target).0
>> -	$(NM) -pa --format=sysv $(dot-target).0 \
>> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>> -		> $(dot-target).1.S
>> -	$(MAKE) $(build)=$(@D) $(dot-target).1.o
>> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>> -	    $(dot-target).1.o -o $(dot-target).1
>> -	$(NM) -pa --format=sysv $(dot-target).1 \
>> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>> -		> $(dot-target).2.S
>> -	$(MAKE) $(build)=$(@D) $(dot-target).2.o
>> -	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
>> -	then \
>> -		set -e; \
>> -		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>> -		    $(dot-target).2.o -o $(dot-target).2; \
>> -		$(NM) -pa --format=sysv $(dot-target).2 \
>> -			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>> -			> $(dot-target).3.S; \
>> -		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
>> -		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
>> -	else \
>> -		ln -sf $(dot-target).2.o $(dot-target).3.o; \
>> -	fi
>> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>> -	    $(dot-target).3.o -o $@
>> -	$(NM) -pa --format=sysv $@ \
>> -		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
>> -		> $@.map
>> -	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>> +LAST_LINKING_PASS := 3
>> +
>> +include scripts/Makefile.link
>> +
>> +# Suppress orphan section checking for the time being.
>> +orphan-handling-y :=
> 
> This works, but I think it's worth reconsidering the shape of it.
> 
> It works only by virtue of deferred expansion: $(orphan-handling-y) is
> referenced solely inside the recipe of the final-pass rule in 
> Makefile.link, so the value that matters is the one in effect when that
> recipe is expanded, not when the rule was defined. Nothing states that
> requirement, and nothing enforces it.
> 
> What makes me uneasy is that the ordering is not merely undocumented,
> it's inverted with respect to the obvious reading. Makefile.link has
> 
>    orphan-handling-$(call ld-option,--orphan-handling=warn) := 
> --orphan-handling=warn
> 
> i.e. an unconditional := to orphan-handling-y whenever the linker
> supports the option. So an arch that sets orphan-handling-y *before*
> the include has its setting silently discarded and ends up with orphan
> checking enabled after all: no warning, no error, just a dozen new
> linker diagnostics appearing at some later point. And "before the
> include" is exactly where one would naturally put it: right next to
> LAST_LINKING_PASS, which is the one knob the arch Makefile does set up
> front.
> 
> I am not insisting on reworking but probably a small comment (in the 
> commit mesage at least?) somewhere about that "+orphan-handling-y :=" 
> should go after include will be useful.

I can add a comment (albeit the ordering looks very obvious to me, and
not counterintuitive at all), but the better thing would be for all
arch-es to quickly deal with getting rid of this override again: No
need for an override, no need for a comment.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 16:07:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 16:07:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401249.1637007 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcdV-0005OV-CU; Thu, 27 Aug 2026 16:07:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401249.1637007; Thu, 27 Aug 2026 16:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzcdV-0005OO-8W; Thu, 27 Aug 2026 16:07:29 +0000
Received: by outflank-mailman (input) for mailman id 1401249;
 Thu, 27 Aug 2026 16:07:27 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzcdT-0005JX-Oz
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:07:27 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzcdQ-00BwIY-VB
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:07:24 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9060b4-8faa-0a2a0a5109dd-0a2a450cba8e-30
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:07:24 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9060bc-f479-0a2a450c0019-d155802db1e9-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:07:24 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-499ae1c6471so14884975e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 09:07:24 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b49bd11c3sm60734465e9.7.2026.08.27.09.07.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 09:07:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787846844; x=1788451644; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=FRLim6j/feVuyl8Yxi6V/xN5B6NazHSdqReW1S+GAPo=;
        b=dwjaqkwhtV96YAqtAXwYJnHsXscMZrQKLyTZx/FnEVWy0ibyaGkADz1QYYPhNmbekl
         2HtOLNqBIaiNGymdRTwtwnv0va1jdp0BHdm6JfQjEeKCx9l9K+eH9SB5aWOFHap7Dmj5
         j+ygtj5+Zjize+awNK1wZlg9siilHwJpVZKvw8JHG5nojxwQVJj5OFj1w6xvp1vRrktN
         IzxZR3A2ccybUHfwDdyGz7D9eIDJJP9+HuW7Wuasvg6XwlJJWzGa0PnEbddodOYUD1SP
         lG/5Zt4YXym0bXt8IWD1b9BB2rFANSET+RMrFPsQTac7xa79/SrrE+QGr6kRmEoUdTzv
         021Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787846844; x=1788451644;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=FRLim6j/feVuyl8Yxi6V/xN5B6NazHSdqReW1S+GAPo=;
        b=dxjWGiKYbTy3awayti3HojxVpPgjbZjZDHs1QS1pwGfH02R7ljwqZj4V/MirnRxqup
         Tqb2sAHjXC1s3+LQZfYT3YTT0mUIH8AkVjCJgVyYAh4IyXREhzFdb6blpZOFeO7mLBbr
         /hAn+0Bbw/agQHfJMPz7+HN+w8EUuwztVWuB+IEfwc78ZgyFtlIScpKD/0iNEPuaGQUz
         8o/OaC2rxuCcfJHb2OCYwkG0NL1VrtTw7LdypNimBcGKwzTj3BqJKfw/XieN9wo9ctUV
         22112obTcuTJaxRJAoc5vcyogoxyrAUyi3imalLWtRc0QulOpkVz0sIaq2TVT4BR4GU3
         MOGw==
X-Forwarded-Encrypted: i=1; AHgh+RrKUgXHy3mlGQfsRZnoLKrBkPyf741TvrjRNoQTgdsCT2kXnLxmzlJlSRyju7De1IIvIxYS7M1XGfw=@lists.xenproject.org
X-Gm-Message-State: AFuF++nm9kYqB+9igd6Vde4dGVtI7jPpwcyjDA0Bg42pNL0zMHyjaaXD
	+IQ2hUcPGrFaSbJqOYHl1lye+0rDa/bVqEUrmBOkTK7yAd4Cn+2N0UEg
X-Gm-Gg: AR+sD11Y0vuxtjuUFk53eVbr+YRXoOL56/IWYJ4fS7AqPIyaKbW6jvsaZF0kPG0iTqw
	Q3xP9SoQUcbV6Ww7xUnjoDfxi38sW0yI2mwnuL7KL7Vs+33OPodanpIGC9LF52rVIyWOJb4txoJ
	a/zE/BgD0Phsqr5k+8VkZ4RMH0qP5z2VK2wKk/miWAdk0CmQOQPorbDT/EMBZgQNt2mfh6cSdYs
	8MFi8TAcpesA++p7kt5Zk9mKiNbuMIKnxnZSr3e4SodgJx2lqdv5SBh2Dbe1X/q1joPnLW0qF6S
	t6/yqJLuLK9vXiq3PsIFVv4/FwJw/ZaFaR9FLOoTZBJJGiAtznQ3Rox6oterMLzfu1t1pxm7CPD
	tRO+2RO4z85ZIkhtg2h6X05kkOtgEN3xMte1VTLOg7gNFlsdWTj5kfE7R/v67VUCTHeXANKJ8iy
	Hp6+RJr0HZgQeVFiTuiw1a8ykFVl94sL/K8XWEzdux0Bz+K30ER42KjlDuRdtTZNokaFyKFAXu/
	2rAjRvIQ3RiujLXL3kzzeyOYH+APYbYJtf3hF6aJTuIX4akvp4oUg==
X-Received: by 2002:a05:600c:c4aa:b0:499:dbae:43d3 with SMTP id 5b1f17b1804b1-499dc71f023mr175886705e9.9.1787846844167;
        Thu, 27 Aug 2026 09:07:24 -0700 (PDT)
Message-ID: <e4652848-4923-49e1-ad2f-c3c46b8ce5d9@gmail.com>
Date: Thu, 27 Aug 2026 18:07:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/7] RISC-V: place .sdata / .srodata /
 .riscv.attributes
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <f26f80e3-0b2d-429a-895c-b8003d1c5a38@suse.com>
 <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com>
 <8eebbdd6-d414-49eb-83e6-668f187e6f93@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <8eebbdd6-d414-49eb-83e6-668f187e6f93@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d25034/1787846844-51B35A5B-07008E2C/10/73395122804
X-purgate-type: spam
X-purgate-size: 6120



On 8/27/26 5:56 PM, Jan Beulich wrote:
> On 27.08.2026 17:40, Oleksii Kurochko wrote:
>> On 8/26/26 2:04 PM, Jan Beulich wrote:
>>> Of the short-data sections, only .sbss is presently mentioned in the
>>> linker script. Place them next to, but ahead of their "normal" data
>>> sections.
>>>
>>> .riscv.attributes can go towards the tail of the image, next to (ahead of)
>>> debug info.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> Seeing where .sbss lives, does positioning really not matter at all? I
>>> would have expected that short-data sections want to live close together,
>>> and specifically close to .text / .init.text (seeing that such data is
>>> accessed using AUIPC). I'm puzzled that the psABI doesn't even mention
>>> them, hence leaving it open how exactly they are to be used.
>>
>> It doesn't, and the reason is that the relevant proximity isn't to .text
>> but to __global_pointer$.
> 
> Anything like this still should be set forth by the psABI, so I don't
> quite understand your reply.
> 
>> The small-data sections exist to let a linker
>> script cluster small objects around that anchor so that ld's relaxation
>> pass can fold an auipc+load pair into a single gp-relative access (-+2
>> KiB window).
>>
>> That pass is keyed purely on the symbol being defined
>> riscv_global_pointer_value() returns 0 otherwise and the relaxation is
>> skipped. We define no __global_pointer$ and head.S never loads gp (it
>> appears only as a cpu_user_regs slot in entry.S), so every access stays
>> the medany auipc form regardless of section.
>>
>> I confirmed this by linking the same object twice (look at the script
>> below, with and without the symbol: without it, zero gp-relative
>> accesses; with it, the pairs collapse.
>>
>> Worth noting the relaxation is section-agnostic: in the test mentioned
>> below a 400-byte array in plain .bss got gp-relative too, purely because
>> it landed in range. So the sections are a clustering hint, not a
>> mechanism ld keys off.
> 
> Okay, fine, but what does this mean for placing the small data sections?
> I.e. what does this mean for the patch here (which really it shouldn't
> have been me to write in the first place)?

I just wnated to show that a position of .sbss doesn't really matter 
based on the example and so true for other .s* and not only .s* 
sections. What means I am okay with your suggested places in the current 
patch.


> 
>>> What remains to eliminate orphan section warnings is the placement of
>>> .note.GNU-stack (which perhaps wants dealing with on all of Arm, PPC, and
>>> RISC-V together, ideally unifying with x86) and (odd at the first glance,
>>> but dealt with on x86 as well, i.e. may again want unifying) that of a
>>> number of .rela.* sections.
>>>
>>> --- a/xen/arch/riscv/xen.lds.S
>>> +++ b/xen/arch/riscv/xen.lds.S
>>> @@ -44,6 +44,8 @@ SECTIONS
>>>    
>>>            BUGFRAMES
>>>    
>>> +        *(.srodata)
>>> +        *(.srodata.*)
>>>            *(.rodata)
>>>            *(.rodata.*)
>>>            VPCI_ARRAY
>>> @@ -92,6 +94,7 @@ SECTIONS
>>>            SCHEDULER_ARRAY
>>>            HYPFS_PARAM
>>>    
>>> +        *(.sdata .sdata.*)
>>>            *(.data .data.*)
>>>            CONSTRUCTORS
>>>        } :text
>>> @@ -162,6 +165,8 @@ SECTIONS
>>>        /* Section for the device tree blob (if any). */
>>>        .dtb : { *(.dtb) } :text
>>>    
>>> +    .riscv.attributes : { *(.riscv.attributes) } :text
>>> +
>>
>> Nit: .riscv.attributes is SHT_RISCV_ATTRIBUTES, i.e. non-alloc.
>> :text on it is misleading, and without an explicit address it gets
>> sh_addr from .(location counter) after .dtb. Could we use matching the
>> idiom used for every other non-alloc section in xen.lds.h:
>>     .riscv.attributes 0 : { *(.riscv.attributes) }
>> No functional difference either way (objcopy -O binary drops it, and I
>> verified a non-alloc output section doesn't advance dot, so nothing
>> downstream shifts), so purely consistency.
> 
> Well, I compare attributes rather with notes, which we make part of a
> segment (on x86 at least). I can drop the :text if it's that what's
> needed to get this in, but I'm not fully convinced. But my knowledge
> on the purpose and use of attributes also is still somewhat limited.

As I mentioned from functional point of view I don't think that it will 
be an issue so generally you could keep :text here.

That why I wrote "Nit:".

Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

> 
>> Is dropping orphan-handling-y := from arch/riscv/Makefile the intended
>> end of this series?
> 
> It is the intended goal, but not by the end of this series.
> 
>> As if I understand correctly with such defintion we
>> will miss warning so everything of that will be missed:
>>
>> cd xen
>> riscv64-linux-gnu-ld -T arch/riscv/xen.lds prelink.o
>> --orphan-handling=warn -o /tmp/t.elf 2>&1 \
>>     | grep 'orphan section'
>> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.note.GNU-stack'
>> from `prelink.o' being placed in section `.note.GNU-stack'
>> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.text' from
>> `prelink.o' being placed in section `.rela.dyn'
>> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.init.text'
>> from `prelink.o' being placed in section `.rela.dyn'
>> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
>> `.rela.data.read_mostly' from `prelink.o' being placed in section
>> `.rela.dyn'
>> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section `.rela.init.data'
>> from `prelink.o' being placed in section `.rela.dyn'
>> /usr/bin/riscv64-linux-gnu-ld: warning: orphan section
>> `.rela.text.header' from `prelink.o' being placed in section `.rela.dyn'
> 
> Yes, if the override was dropped, these warnings would appear on every
> build. I thought that may not be wanted, hence the override I put in
> (really everywhere except for x86, where things were already tidied).

Thanks. Got you. It makes sense.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 16:12:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 16:12:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401254.1637015 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzciH-0008QN-00; Thu, 27 Aug 2026 16:12:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401254.1637015; Thu, 27 Aug 2026 16:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzciG-0008QG-Tf; Thu, 27 Aug 2026 16:12:24 +0000
Received: by outflank-mailman (input) for mailman id 1401254;
 Thu, 27 Aug 2026 16:12:22 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzciE-0008QA-R2
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:12:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzciD-00FoiI-Kl
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:12:21 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9061da-8faa-0a2a0a5109dd-0a2a4508e412-14
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:12:21 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9061e5-f659-0a2a45080019-d155dd2ea8c2-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:12:21 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-47db714766aso894385f8f.0
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 09:12:21 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482e27a9f0esm10798172f8f.10.2026.08.27.09.12.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 09:12:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787847141; x=1788451941; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=mh8+DjiPJ8UjXmQzaIp8K5Yjet64NmMupumjqZqHfow=;
        b=Ofr0W7KMgetaMvohdj5fqj9ci9x3YYleBg0RGTW1ITsJkOv6mZrXCxBgJQifovWlci
         CnzSKE1FBCHDvv6HT8oU0pQAIh+aw1zJnmdNFpZrXuaE50+BsCb452wDSQIvvC/HAJhM
         NVBxCP/ZGkIP6sm4q7LmVHoaueqd2eG3ygc6ruijPZKI38YTu6J2xu2o1BzdwHrL1Gqa
         PAlkUO1vU6PRV1dtSQdOKIBwRrVui+/nxr2IeR8MhMxGF90Ei4wmSEgsbp3Tvz9hZRL/
         d+F3wBYpfKKnRbV7tsOSiL+zN9uR/CbFybd8AW9DWxvmC6c6g1qJjoH0+zwk4WkF8Vx0
         0Vvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787847141; x=1788451941;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=mh8+DjiPJ8UjXmQzaIp8K5Yjet64NmMupumjqZqHfow=;
        b=MQclOgosuIQoBpV83AvWpKz2KDuVLT1J9b+0MdPy5xbzzmYG+tY8z634BGlAQ2pVsL
         7RayMoP73pde97qyvUGHzH6f0VrzPnaBqPI7r6KoO3J+w1JawNn22z60p6ldFst71bq7
         d0joofeUXqHWm7tR08JnUclNQ02ZNzGiYk1kZR7wfZNSnCZSUzVn0Xdl3HlJ1U82lCtd
         S6/yGlhCjSLtM4GOhJifZqd0aPKtbPAUGr/v8oCr6brLpwv02nReSZ6haEJpx+JbcOFR
         7MwL4QSjUg0PQa97CTT1qhuTv+2PdRUeGfaP34TWusTZ3fBuVF1hhziGZw6EHuPc92fv
         k+NA==
X-Forwarded-Encrypted: i=1; AHgh+RrYvCGPgG71p7pLe2GxUwb5wYMWL6zW3wA3fmwvBy8M3tl/JSyoEjHTYwERDnjNoTEHzVbHTQO6ROI=@lists.xenproject.org
X-Gm-Message-State: AFuF++n/PBGImbmJjt9ITmmGRMzXIwUj65wIDovWwhqyHJSvcZB5PpiF
	A2DUCQw4/pGBrFY7ziLW41DzeQBWHx539TPGDEfqgN5yYyBNm4zdA56y
X-Gm-Gg: AR+sD10Z4XZIB1sMn9Vs/OHA4RApdJS89Sfj39yAQ/fV1DiWqaR+ztBEzdunMqn2N8u
	VYUHHjC5uQrV/ItL0ubCU8tBBion9e0DWeUdOuQQbz9l3xQqos/xQ09GugOS+z0PnZlTnWCNe1t
	8xxoGsFFSEKexFYy/nuSgAd2iTodGXQMrcpBFbtk9l67MycXCPx8eTGYAyweevbzUlHSNqJgunf
	Tysx45hv4bcrIt6+OUikk4JYPYc17huhnGX9UdNLgvJ9d/wx7dYXgRB1/5Xz+THAYLv60F7fEPy
	V3ytupoaP1TmDURdVa0BOW2srknJSF5UY7g6+bQ+MwN9Cy5b6nwUVQunIvfvlh7AEiqg6DQGigP
	mEWs9GEqC/Zl1ld8SNBO5dyDqt62FhKomcTtXWF79P1IedL06mJEvN1kta404Bhveh85ghPGdKo
	yzY/+lTOyihRyoYk0oyGjD1fJtB9jKU3wTvZTUYZMiqVNtMFnFSn01s81HL3TG+3DcqWmXtao7k
	CYAgOYFdSI1zzq8aizAeyi4b9JAii+/kFtB/ovQ5Q==
X-Received: by 2002:a05:6000:4903:b0:47f:9158:5924 with SMTP id ffacd0b85a97d-482f75d549emr286783f8f.9.1787847140675;
        Thu, 27 Aug 2026 09:12:20 -0700 (PDT)
Message-ID: <d4169b03-46aa-4bf3-881c-65ea8d970c27@gmail.com>
Date: Thu, 27 Aug 2026 18:12:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/7] RISC-V: split xen-syms linking rule
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com>
 <6f4b26ce-2797-4c17-bfdf-8effd2026a6a@suse.com>
 <f0510fd7-32fc-4fbd-834e-68bba14150b9@gmail.com>
 <15abd61a-045f-47d1-94fb-b5febf28711c@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <15abd61a-045f-47d1-94fb-b5febf28711c@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787847141-D755C87B-FBFB5149/10/73395122804
X-purgate-type: spam
X-purgate-size: 5036



On 8/27/26 6:01 PM, Jan Beulich wrote:
> On 27.08.2026 17:56, Oleksii Kurochko wrote:
>> On 8/26/26 2:01 PM, Jan Beulich wrote:
>>> Doing so, besides (hopefully) adding clarity (not the least by way of
>>> [re-]using pattern rules where possible), also avoids explicit recursive
>>> $(MAKE) invocations.
>>>
>>> By re-using the generic rules introduced when the respective x86 rule was
>>> split,
>>> - the .map file now isn't created after the final binary anymore,
>>> - --strip-debug is passed to $(LD) during early linking passes (for
>>>     consistency the option is also explicitly added to the optional linking
>>>     pass rule),
>>> - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are
>>>     now properly respected.
>>> Orphan section checking, otoh, is getting suppressed for now, until the
>>> about a dozen warnings which would result have been taken care of.
>>>
>>> While the 4th linking step continues to be avoided when possible, a
>>> redundant invocation of $(NM) and tools/symbols (plus the assembling of
>>> the resulting .S file) is hopefully deemed acceptable.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> --- a/xen/arch/riscv/Makefile
>>> +++ b/xen/arch/riscv/Makefile
>>> @@ -31,40 +31,12 @@ obj-y += vtimer.o
>>>    $(TARGET): $(TARGET)-syms
>>>    	$(OBJCOPY) -O binary -S $< $@
>>>    
>>> -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
>>> -	$(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
>>> -	$(MAKE) $(build)=$(@D) $(dot-target).0.o
>>> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>>> -	      $(dot-target).0.o -o $(dot-target).0
>>> -	$(NM) -pa --format=sysv $(dot-target).0 \
>>> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>>> -		> $(dot-target).1.S
>>> -	$(MAKE) $(build)=$(@D) $(dot-target).1.o
>>> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>>> -	    $(dot-target).1.o -o $(dot-target).1
>>> -	$(NM) -pa --format=sysv $(dot-target).1 \
>>> -		| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>>> -		> $(dot-target).2.S
>>> -	$(MAKE) $(build)=$(@D) $(dot-target).2.o
>>> -	if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \
>>> -	then \
>>> -		set -e; \
>>> -		$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>>> -		    $(dot-target).2.o -o $(dot-target).2; \
>>> -		$(NM) -pa --format=sysv $(dot-target).2 \
>>> -			| $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>>> -			> $(dot-target).3.S; \
>>> -		$(MAKE) $(build)=$(@D) $(dot-target).3.o; \
>>> -		$(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \
>>> -	else \
>>> -		ln -sf $(dot-target).2.o $(dot-target).3.o; \
>>> -	fi
>>> -	$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \
>>> -	    $(dot-target).3.o -o $@
>>> -	$(NM) -pa --format=sysv $@ \
>>> -		| $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \
>>> -		> $@.map
>>> -	rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]*
>>> +LAST_LINKING_PASS := 3
>>> +
>>> +include scripts/Makefile.link
>>> +
>>> +# Suppress orphan section checking for the time being.
>>> +orphan-handling-y :=
>>
>> This works, but I think it's worth reconsidering the shape of it.
>>
>> It works only by virtue of deferred expansion: $(orphan-handling-y) is
>> referenced solely inside the recipe of the final-pass rule in
>> Makefile.link, so the value that matters is the one in effect when that
>> recipe is expanded, not when the rule was defined. Nothing states that
>> requirement, and nothing enforces it.
>>
>> What makes me uneasy is that the ordering is not merely undocumented,
>> it's inverted with respect to the obvious reading. Makefile.link has
>>
>>     orphan-handling-$(call ld-option,--orphan-handling=warn) :=
>> --orphan-handling=warn
>>
>> i.e. an unconditional := to orphan-handling-y whenever the linker
>> supports the option. So an arch that sets orphan-handling-y *before*
>> the include has its setting silently discarded and ends up with orphan
>> checking enabled after all: no warning, no error, just a dozen new
>> linker diagnostics appearing at some later point. And "before the
>> include" is exactly where one would naturally put it: right next to
>> LAST_LINKING_PASS, which is the one knob the arch Makefile does set up
>> front.
>>
>> I am not insisting on reworking but probably a small comment (in the
>> commit mesage at least?) somewhere about that "+orphan-handling-y :="
>> should go after include will be useful.
> 
> I can add a comment (albeit the ordering looks very obvious to me, and
> not counterintuitive at all), but the better thing would be for all
> arch-es to quickly deal with getting rid of this override again: No
> need for an override, no need for a comment.

Agree, then no need for the comment:

Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii



> 
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 16:53:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 16:53:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401293.1637026 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzdM7-0001FX-Vz; Thu, 27 Aug 2026 16:53:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401293.1637026; Thu, 27 Aug 2026 16:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzdM7-0001FQ-SW; Thu, 27 Aug 2026 16:53:35 +0000
Received: by outflank-mailman (input) for mailman id 1401293;
 Thu, 27 Aug 2026 16:53:35 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzdM6-0001FK-WC
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:53:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzdM6-003agK-9j
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:53:34 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a906b70-bab6-0a2a0a5309dd-0a2a4502a972-28
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:53:34 +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 <oleksii.kurochko@gmail.com>)
 id 6a906b8e-6ca4-0a2a45020019-d155802ea52a-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:53:34 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-495437bb891so10097475e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 09:53:34 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b91c57943sm1813135e9.2.2026.08.27.09.53.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 09:53:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787849614; x=1788454414; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=uuqSeC9ghPFHhz7Q9l65GkJHNKdcETa7fStrF9vwBX0=;
        b=ZVetvZP5cvpMnbFGx6vMRbBnGYQy36wZEVsKDa4azXO6goTdDLyomb15z7qIOECGgN
         5a3gtcxBUiHeQlCLRxyYWAcLDEq7MAQ/B2wVagFcSiRmg07hO+f38LxWV3NEEqw7v25G
         1qE6Ipm6Vl+KwndGuQS3MLZVYECwFvY35ecYjM4PfS7dFJ0CP8o+hFvEwSZlp2XbX5bi
         gxux8UoNHqdSKGSHW/M9MOQj4H1TUfkmwfn2FeViltRd7j5VTc/djnC5JgOgT9zOkTQ+
         0p5czkk4Q3zFIYwUX3MZ54wXcRg86nfAw6NMSY2co4ne5QnYW0RJh7wg5jlOcUErf1ZW
         /iHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787849614; x=1788454414;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=uuqSeC9ghPFHhz7Q9l65GkJHNKdcETa7fStrF9vwBX0=;
        b=CNBHZD4exccn9EAAmMpkZw+wphZ/q5T7N3uvFrvw5/jZMQ5in6CzIl/c58SdXDxrkj
         nY37Wj1Xntpm0gXuiIMPZsVAPII+m+/f6zr6fEVa45GL9OXg/Baz8GjauJPYumFJksfy
         vBrKZs8gu5LYmQTgEYdS0c8uTPGvw2H44UPC8d+IWmoBl97kD3+ydXEecJ7z90vHxYxu
         2mvILmcXTxKadixvFsM/hrm4/XCAh6s3lFoEIFr3Rn+e66wc4vu2ZCejDPrzhe+mEYEx
         7YBAa/NZHlTJGgsQFexPejYOVxbAs1WRSIPYawoffVFdFAiTNEmfEXQv8BmQxjLrDnt1
         6Kqw==
X-Forwarded-Encrypted: i=1; AHgh+Rpn7EkKrWu7+YtERM2Gk+tuRIRPNp+SW/5VA+/f/PifXVuj9KaA/hcGiAo2R1HGz56p6X+6dKGl+kM=@lists.xenproject.org
X-Gm-Message-State: AFuF++koHtL5p5w5fr4l6uxeT20GXtuAjv7Mu1ZUCHbRGpr+kFdBQCC5
	D3QGIijgsgAbSuV6r19NKnikx7e4VmQC8JEYj5qJcX3ONTsRNSN91C9O
X-Gm-Gg: AR+sD10x/v5vT8fSWLMXkYswNbUCjz6et94bRxcVigJF2p4MlyekqX5Yfq1GJHzqBaK
	MqbSEcbyosb83Dmc6OS/gON31tqCNh6ium6S86WYd/3zp8eqHYrNXbRDV4WM54nO+ycLwUMnX5o
	OZdlg9X6k3Z2QoKPVUVS/NyNsV7C4fy6s7ET0kO8ehXVazB7Z2gJmVtHf0FfjMJpoTdfO4lXTFr
	1dSI7Y0oSYffrJ19cgqapI1ebVX+2MkWzysv7qKuv+uDWlu44IwWzp6hpeAHKwHgJ2mp8AueTY4
	XU1aAw5+PxqPMZHSIFliIuPdmjWDRMACQf9jspLWcrptgP7n5i5RloNochb5Rt2k6M713W7zEhe
	RD4u3+ckWVEKPxdysTyEsWafYYcEtgwbPp6WdzdVuFs0ctpdSPw0RObcce9KHvIkMZIv8+rpDzR
	/xYAKRU++JP8V2FbvEhWeuOJxX49S7izvXZqfRDVbuCMF0Ei2d3gUJDmBTobVG8bbeI0AW4eEHY
	NbbIYWqlMwYT6KLEW8LuvpHZc4rbbfoFzVpd9aYRg==
X-Received: by 2002:a05:600c:1e24:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-49b91a6d41emr8112645e9.7.1787849613616;
        Thu, 27 Aug 2026 09:53:33 -0700 (PDT)
Message-ID: <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Date: Thu, 27 Aug 2026 18:53:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787849614-670B02AC-9605C51D/10/73395122804
X-purgate-type: spam
X-purgate-size: 3262



On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> turn_on_mmu() writes satp to switch on Sv39 paging but never fences
> afterwards.
> 
> Xen never allocates a non-zero ASID, so per the Privileged spec, sec.
> 12.2.1 "Supervisor Memory-Management Fence Instruction":
> 
>    "If the implementation does not provide ASIDs, or software chooses
>    to always use ASID 0, then after every satp write, software should
>    execute SFENCE.VMA with rs1=x0."
> 
> The spec text around this rule hedges with "may be necessary", but
> RISC-V spec co-author Andrew Waterman confirmed on the ISA manual
> issue tracker that the fence after a satp write is not optional in
> this case: "The SFENCE after the SATP write is definitely necessary
> ... In general, you need to SFENCE after you've recycled an ASID.
> Since we don't use ASIDs in the Linux kernel yet, every context
> switch is effectively an ASID reuse, hence the full TLB flush." [1]
> The same reasoning applies to Xen: with ASID always 0, this satp
> write is indistinguishable from an ASID reuse to the hart, so the
> fence is required for correctness.

But at the moment of execution of turn_on_mmu() we don't use any ASID, 
do we? It was used in check_pgtbl_mode_support() but at the end it is done:

     csr_write(CSR_SATP, 0);

     sfence_vma();

So basically Bare mode + flush all TLBs presented before and then up to

...

> 
> Add the missing SFENCE.VMA to order those page-table stores before
> the hart's first translation under the new mapping.
> 
> [1] https://github.com/riscv/riscv-isa-manual/issues/226
> 
> Fixes: f5035d480f7a ("xen: add files needed for minimal riscv build")
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> ---
>   xen/arch/riscv/riscv64/head.S | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S
> index 9c40512e61..7f6edc972f 100644
> --- a/xen/arch/riscv/riscv64/head.S
> +++ b/xen/arch/riscv/riscv64/head.S
> @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
>           srli    t1, t1, PAGE_SHIFT
>           or      t1, t1, t0
>           csrw    CSR_SATP, t1

... ASID isn't used as we are in Bare mode.

What am I missing?

> +        sfence.vma

The one thing which possibly matters here, and could explain why 
sfence.vma is needed, is:
```
Implementations with virtual memory are permitted to perform address 
translations speculatively and earlier than required by an explicit 
memory access, and are permitted to cache them in address translation 
cache structures—including possibly caching the identity mappings from 
effective address to physical address used in Bare translation modes and 
M-mode.
```

So the TLB could potentially be populated with identity mappings, and I 
agree that it would be better to flush those.

I’m not entirely convinced, though, that the reason here is the ASID 
itself. Rather, it seems that we want to flush because of potentially 
cached speculative identity mappings.

If this reasoning looks correct to you, could we update the commit 
message to reflect this rationale for why sfence.vma is needed here?

Thanks.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Thu Aug 27 16:58:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 16:58:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401299.1637034 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzdR5-00041u-GW; Thu, 27 Aug 2026 16:58:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401299.1637034; Thu, 27 Aug 2026 16:58:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzdR5-00041n-DV; Thu, 27 Aug 2026 16:58:43 +0000
Received: by outflank-mailman (input) for mailman id 1401299;
 Thu, 27 Aug 2026 16:58:42 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzdR4-00040s-IS
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 16:58:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzdR3-003bTr-Oc
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:58:41 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a906ca1-bab6-0a2a0a5309dd-0a2a4501e5e6-30
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:58:36 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a906cbc-5984-0a2a45010019-d155802bd8b9-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 18:58:36 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49b0d78a801so12562545e9.2
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 09:58:36 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b49610170sm137236695e9.6.2026.08.27.09.58.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 09:58:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787849916; x=1788454716; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=K2WlaGtCp3aT9Am4Nnc/lITi/fUCYeCl+a0KVbaJhNc=;
        b=qbN8uFMHMyVNlI03SHn4u8MLILCF4ytWnojiEvk2gaCGsJ3Fs9TuArXiHzQl6V6sMB
         JM+xBJjRfPrJVFHEPpqN0qYsCZAzmsAmhkcXnnUJQX+qSpWiPQgQ9BvcAT9y0Y1iLsY7
         7LKJkd3DM9tTwvtzURfjz1MQmchsYCY3hcWUQy8W0gklkLvDN0X/tfbijainkgBK4UPB
         fwAu0mrs7MWaBuA37iePBCZGJDlJ3boXHBmrH6pRqn+s9qc90/hGTESoiSX8NmBXXHJa
         wRnffreYvm0Phl/u8+r9QXgjveBsF5BvUZbRdvh4ZVR61wZTJo2+e1uNTBvAQxx49ncT
         Hy7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787849916; x=1788454716;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=K2WlaGtCp3aT9Am4Nnc/lITi/fUCYeCl+a0KVbaJhNc=;
        b=HGU2pXmARaScfWk6BBhpIiQF3aaDLrf03f7q1LqMUjawSEYKtozD1Tg6kKK0GDJ603
         b8TSobZ1H0uhpfmabxntQV8c4AyTgtU/r1TFfkL3nBxNsllVha5WVcIuy5QROhJvVj0I
         Hgfk6xOSux5WUQUFHAEgzHW2k17xA39UZnxImmfi7d+TzZsyINLQdtnwto7D4j7WWTON
         ZeVflh0ZqmYsNrHAnwMiRfa0r/dFAyPfEe1XyKA7FoDBIb7tOWCmWCY+vprta8H1uNj3
         Ucr09hq0gXyPZByrb8A639tDXxtseviXauZbOHncijAfl/V/lJ3UNCrs/4ygo6e2X/fq
         dr6g==
X-Forwarded-Encrypted: i=1; AHgh+RqxlxjEpehnQcGNSzjhrfnPcVopaLYMRamNbnrZEwtTtPojzlFtuvqRi/tPkB6HLer8c+0Qx5hewSU=@lists.xenproject.org
X-Gm-Message-State: AFuF++lINx43N1TLEU7gG5zDJPD+U5K4upRHo3IBol2uoL2C/Ap4L1TS
	EQteGzJNh5khGQn0dyqsEV6IuwNPkAsIN+IdHh8ComnhFooSRi5FXaQ6
X-Gm-Gg: AR+sD128IMJeDSPWLEAp+Db/EyNacj1s3nDoi25oqgD5E1GUa9TOShsjBMAsRxhE9jg
	ljDoLWvEoFSDDoqW/W/Td20G7atmBCCLvfx42d8ze6T5rARDd4oqKLFwrd46Yki9Tlu7IkAVQ3Z
	VWwrUwg+e+TrSIbyCq19V8U7WCgDEITikezoONim76I3AY7gw3YocW4NtVyqKo3awrHmlwughBT
	uKpFQ3OGOBGDgYDwCKNjNU9qHnn5arLGF2JJ3pKHgEYuUDdXHB4plwuTsyoabSATLhXkgXiksoG
	jH2GASJ5mumeBdwCf0JbFOJaxlACGXqaimMMoO5ZKoPbPxc96JSUfZRxWgTmEzqRdKTJs9ePEoj
	iGRMVO9oWdHIEGnCrUBY7WVRfDT3hmEuKLe/YeeC6x/3koeZAOm+Ia89+rJ/bw65ydLSukVWnec
	T5QIO0a3bI/oHu736bEIBrcMa02AaYNLL+EiWjKo43mdVO8wZHBKFthivJU9/S5b+pOyfZ11Vnw
	J3j36zbHv8/Y1MA13Oy1JyGF9r2JfdQVaMgNK6p3Q==
X-Received: by 2002:a05:600c:c490:b0:499:726a:a017 with SMTP id 5b1f17b1804b1-49b91c17294mr5640925e9.1.1787849916038;
        Thu, 27 Aug 2026 09:58:36 -0700 (PDT)
Message-ID: <b411cdad-4976-4ca2-bd18-d38af991f657@gmail.com>
Date: Thu, 27 Aug 2026 18:58:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
 <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Content-Language: en-US
In-Reply-To: <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787849916-1FE68757-60F27948/10/73395122804
X-purgate-type: spam
X-purgate-size: 4094



On 8/27/26 6:53 PM, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
>> turn_on_mmu() writes satp to switch on Sv39 paging but never fences
>> afterwards.
>>
>> Xen never allocates a non-zero ASID, so per the Privileged spec, sec.
>> 12.2.1 "Supervisor Memory-Management Fence Instruction":
>>
>>    "If the implementation does not provide ASIDs, or software chooses
>>    to always use ASID 0, then after every satp write, software should
>>    execute SFENCE.VMA with rs1=x0."
>>
>> The spec text around this rule hedges with "may be necessary", but
>> RISC-V spec co-author Andrew Waterman confirmed on the ISA manual
>> issue tracker that the fence after a satp write is not optional in
>> this case: "The SFENCE after the SATP write is definitely necessary
>> ... In general, you need to SFENCE after you've recycled an ASID.
>> Since we don't use ASIDs in the Linux kernel yet, every context
>> switch is effectively an ASID reuse, hence the full TLB flush." [1]
>> The same reasoning applies to Xen: with ASID always 0, this satp
>> write is indistinguishable from an ASID reuse to the hart, so the
>> fence is required for correctness.
> 
> But at the moment of execution of turn_on_mmu() we don't use any ASID, 
> do we? It was used in check_pgtbl_mode_support() but at the end it is done:
> 
>      csr_write(CSR_SATP, 0);
> 
>      sfence_vma();
> 
> So basically Bare mode + flush all TLBs presented before and then up to
> 
> ...
> 
>>
>> Add the missing SFENCE.VMA to order those page-table stores before
>> the hart's first translation under the new mapping.
>>
>> [1] https://github.com/riscv/riscv-isa-manual/issues/226
>>
>> Fixes: f5035d480f7a ("xen: add files needed for minimal riscv build")
>> Assisted-by: Claude:claude-opus-5
>> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
>> ---
>>   xen/arch/riscv/riscv64/head.S | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/ 
>> head.S
>> index 9c40512e61..7f6edc972f 100644
>> --- a/xen/arch/riscv/riscv64/head.S
>> +++ b/xen/arch/riscv/riscv64/head.S
>> @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
>>           srli    t1, t1, PAGE_SHIFT
>>           or      t1, t1, t0
>>           csrw    CSR_SATP, t1
> 
> ... ASID isn't used as we are in Bare mode.
> 
> What am I missing?
> 
>> +        sfence.vma
> 
> The one thing which possibly matters here, and could explain why 
> sfence.vma is needed, is:
> ```
> Implementations with virtual memory are permitted to perform address 
> translations speculatively and earlier than required by an explicit 
> memory access, and are permitted to cache them in address translation 
> cache structures—including possibly caching the identity mappings from 
> effective address to physical address used in Bare translation modes and 
> M-mode.
> ```
> 
> So the TLB could potentially be populated with identity mappings, and I 
> agree that it would be better to flush those.
> 
> I’m not entirely convinced, though, that the reason here is the ASID 
> itself. Rather, it seems that we want to flush because of potentially 
> cached speculative identity mappings.
> 
> If this reasoning looks correct to you, could we update the commit 
> message to reflect this rationale for why sfence.vma is needed here?

My suggestion is:

xen/riscv: add SFENCE.VMA after writing satp in turn_on_mmu()

The existing SFENCE.VMA before the satp write only orders the page
table stores from setup_initial_pagetables() against subsequent
implicit reads. It cannot invalidate translations cached after it
retires, and the Privileged spec permits an implementation to
translate speculatively and to cache the identity mappings used in
Bare mode. Such an entry would shadow the Sv39 translation once
paging is on, which matters because turn_on_mmu() jumps to a linker
address that is not identity mapped.

Does it make sense?

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 18:09:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 18:09:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401336.1637044 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzeWs-0004Q3-BQ; Thu, 27 Aug 2026 18:08:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401336.1637044; Thu, 27 Aug 2026 18:08:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzeWs-0004Pw-72; Thu, 27 Aug 2026 18:08:46 +0000
Received: by outflank-mailman (input) for mailman id 1401336;
 Thu, 27 Aug 2026 18:08:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wzeWq-0004Pp-O2
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:08:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzeWq-00CB7W-0e
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 20:08:44 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a907d0c-e002-0a2a0a5209dd-0a2a450bde2a-48
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:08:43 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a907d29-b7e8-0a2a450b0019-888fbc335280-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:08:43 +0200
Received: by mx.zohomail.com with SMTPS id 1787854116654249.51624760089214;
 Thu, 27 Aug 2026 11:08:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1787854118; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=NSaAsp689TJ0MR1KoE8zt+IjAD905tvBylhuZIETCCBQktTqWfPUAOskxZzUWCDAlNHpIqTgQv7HGOphie11akhcRBY0tNuUUmn6kFElTszm/Yx81ktIhaoJAo796iffH7VE6tQdYJ5wFaMPLAxjG3+r2abZB3OqSdF3Q6iLUJA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1787854118; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
	bh=7a5oE4QBukki7nNrLv3r4iRFdjUTs5zM0uoV9vdA7+E=; 
	b=g5uT11L2N6vU0wi0uGrMOapul016+t9pyS9WwcohKNdDCVegfLIg1mVGd/sj6fZ9DxZfQxxUJuNgDCgByyyX/AVuIjMBt5dfVTnV1vFUD6ulh06iDPi8bMBMV+ZCRPtYd/wJZIXHvpXoNSxTDeYuX8vgqDhOXm6Nt0XaC/Sdjwg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1787854118;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc;
	bh=7a5oE4QBukki7nNrLv3r4iRFdjUTs5zM0uoV9vdA7+E=;
	b=W1e7yksXqCppDunTRDCoRubCBOajNRMbufVwKzjl1IbXSrjKfmsU+K29YEanW54q
	zut009Yiv4/I6t3/j3fg1wBqYFrkED/rA1mWdsfK6xGVpOYhBa9I24jUr5dikUuCX/Q
	0T2xczeWCJ8Le+FTtu3hjUfGXFM93Tt8HNJvJjSw=
Message-ID: <c9c9d3bb-e818-41b4-aca9-48724b92346a@apertussolutions.com>
Date: Thu, 27 Aug 2026 14:08:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] flask: add const qualifier to
 security_context_to_sid()
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
 <ee0ce49467ac1ee1cdd017323e70c8a865269f39.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <ee0ce49467ac1ee1cdd017323e70c8a865269f39.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-42698a/1787854123-1BED69EA-248F853A/0/0
X-purgate-type: clean
X-purgate-size: 1666

On 8/27/26 5:38 AM, Sergiy Kibrik wrote:
> The function does not modify context argument.
> Also it gives more flexibility to this API usage, because some context strings
> in Xen are also const char*.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
>   xen/xsm/flask/include/security.h | 2 +-
>   xen/xsm/flask/ss/services.c      | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
> index ec8b442a8f..a2c5f423f8 100644
> --- a/xen/xsm/flask/include/security.h
> +++ b/xen/xsm/flask/include/security.h
> @@ -76,7 +76,7 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid);
>   
>   int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
>   
> -int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
> +int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *out_sid);
>   
>   int security_get_allow_unknown(void);
>   
> diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
> index 35ad1034ca..764ac7d1d8 100644
> --- a/xen/xsm/flask/ss/services.c
> +++ b/xen/xsm/flask/ss/services.c
> @@ -813,7 +813,7 @@ out:
>    * Returns -%EINVAL if the context is invalid, -%ENOMEM if insufficient
>    * memory is available, or 0 on success.
>    */
> -int security_context_to_sid(char *scontext, u32 scontext_len, u32 *sid)
> +int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *sid)
>   {
>       char *scontext2;
>       struct context context;

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 18:10:05 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 18:10:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401344.1637053 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzeY8-00061z-OG; Thu, 27 Aug 2026 18:10:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401344.1637053; Thu, 27 Aug 2026 18:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzeY8-00061H-Jg; Thu, 27 Aug 2026 18:10:04 +0000
Received: by outflank-mailman (input) for mailman id 1401344;
 Thu, 27 Aug 2026 18:10:03 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wzeY7-0005iw-4w
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:10:03 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzeY6-00CBKN-Hw
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 20:10:02 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a907d40-e002-0a2a0a5209dd-0a2a4509da8c-42
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:10:02 +0200
Received: from [165.173.182.51] (helo=sender5-of-o51.zoho.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a907d78-be1a-0a2a45090019-a5adb6339121-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:10:01 +0200
Received: by mx.zohomail.com with SMTPS id 1787854193486239.0961610665347;
 Thu, 27 Aug 2026 11:09:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1787854195; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=gaUi/noafF/XHyT/0unlRfX2UzfFK1aS5zyUDS/dUERlZPWMz/SHXuPUt+l607Ddb7Lbw4vo2aODBrDS1MDuSRqSi7Oqt7CymE1BKN5yVO/JBBKklhiw3BwbVUQ0dYiC0msmfUsm59J29v5o3JupZpxVXkhLewQcqMBBWMHAp7o=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1787854195; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=s/MMjONvpKuV7PnAc6VJr6YSsk2zhvpqMRKavBhEDD0=; 
	b=oMFxqqj7A2Rt06m3zPuq5hVVCcpOMG9UlCBvu/XHU4xOyPnDMayrHHaLPKVcynLpnh6GBlxGxpl6audV5jimBqams1+AMngCtXgAW1IfJ3y+HyOs4mE25QIS/QkmB1AM+p+apaca0Cb/bVpcy33DBPezwk/770vw1PlGInZOxho=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1787854195;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=s/MMjONvpKuV7PnAc6VJr6YSsk2zhvpqMRKavBhEDD0=;
	b=LeHJKKQanCci1jXOaV2mMIAP2gnfSBuEkWTohOyBTe3hmr9RrU0lnkBeur9BF88E
	FAeuvea/8C7cSd4lI+lvc5thkjPkSXu7a3Siy2vKE4KG6DC/lrF8diPetHuYeLsdk/C
	369Jl15QM0ducu2uxLutWc5bAPl/F4O5SdPJec1g=
Message-ID: <35391c92-c01d-43d5-b89a-7eb086a292a5@apertussolutions.com>
Date: Thu, 27 Aug 2026 14:09:54 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
 <julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
 <e97ab666be0d667dc823c3d881ac9ed76267a7a5.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <e97ab666be0d667dc823c3d881ac9ed76267a7a5.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-bad1c0/1787854202-BC4CB034-61C33FA1/0/0
X-purgate-type: clean
X-purgate-size: 3970

On 8/27/26 5:38 AM, Sergiy Kibrik wrote:
> Add "seclabel" property to be able to specify security label for a domain
> when XSM Flask is enabled, similar to xl configuration files.
> 
> Currently guest domain can't be created by Xen in dom0less configuration when
> Flask is enabled, as domain is assigned "system_u:system_r:unlabeled_t" label
> by default, which Flask denies to create according to current policy.
> 
> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
> ---
>   docs/misc/arm/device-tree/booting.txt      |  8 ++++++++
>   xen/common/device-tree/Makefile            |  2 ++
>   xen/common/device-tree/dom0less-bindings.c | 11 +++++++++++
>   3 files changed, 21 insertions(+)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index bcb06bc796..fcc7be0ffb 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -345,6 +345,12 @@ with the following properties:
>       not passed. This configuration requires static allocation (xen,static-mem)
>       and direct mapping (direct-map).
>   
> +- seclabel
> +
> +    A string property specifying an XSM security label to this domain. Effective
> +    only when FLASK is enabled. Domains will be classified “unlabeled” if
> +    this property not specified.
> +
>   Under the "xen,domain" compatible node, one or more sub-nodes are present
>   for the DomU kernel and ramdisk.
>   
> @@ -422,6 +428,7 @@ chosen {
>           memory = <0 131072>;
>           cpus = <2>;
>           vpl011;
> +        seclabel = "system_u:system_r:domU_t";
>   
>           vcpu0 {
>               compatible = "xen,vcpu";
> @@ -453,6 +460,7 @@ chosen {
>           #size-cells = <0x1>;
>           memory = <0 65536>;
>           cpus = <1>;
> +        seclabel = "system_u:system_r:domU_t";
>   
>           module@0x4c000000 {
>               compatible = "multiboot,kernel", "multiboot,module";
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 9036e455d6..e4de292533 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -11,3 +11,5 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
>   obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>   obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
>   obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
> +
> +CFLAGS-y += -I$(srctree)/xsm/flask/include
> diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c
> index 41d72d0d58..bffd2ec65d 100644
> --- a/xen/common/device-tree/dom0less-bindings.c
> +++ b/xen/common/device-tree/dom0less-bindings.c
> @@ -11,6 +11,8 @@
>   #include <public/bootfdt.h>
>   #include <public/domctl.h>
>   
> +#include <security.h>
> +
>   int __init parse_dom0less_node(struct dt_device_node *node,
>                                  struct boot_domain *bd)
>   {
> @@ -21,6 +23,7 @@ int __init parse_dom0less_node(struct dt_device_node *node,
>       bool has_dtb = false;
>       bool iommu = false;
>       const char *dom0less_iommu = NULL;
> +    const char *xsm_seclabel = NULL;
>   
>       if ( !dt_device_is_compatible(node, "xen,domain") )
>           return -ENOENT;
> @@ -141,5 +144,13 @@ int __init parse_dom0less_node(struct dt_device_node *node,
>           panic("'llc-colors' found, but LLC coloring is disabled\n");
>   #endif
>   
> +    if ( IS_ENABLED(CONFIG_XSM_FLASK) &&
> +         !dt_property_read_string(node, "seclabel", &xsm_seclabel) )
> +    {
> +        if ( security_context_to_sid(xsm_seclabel, strlen(xsm_seclabel),
> +                                     &d_cfg->ssidref) )
> +            panic("Invalid security context for domain: %s\n", xsm_seclabel);
> +    }
> +
>       return arch_parse_dom0less_node(node, bd);
>   }

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 18:20:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 18:20:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401353.1637061 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzehx-0000X0-Jp; Thu, 27 Aug 2026 18:20:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401353.1637061; Thu, 27 Aug 2026 18:20:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzehx-0000Wt-Gt; Thu, 27 Aug 2026 18:20:13 +0000
Received: by outflank-mailman (input) for mailman id 1401353;
 Thu, 27 Aug 2026 18:20:11 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wzehv-0000Wg-Fn
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:20:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzehu-000vJ4-KV
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 20:20:10 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a907fb5-2eae-0a2a0a5409dd-0a2a4503a502-26
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:20:09 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a907fd7-fae8-0a2a45030019-888fbc335297-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:20:09 +0200
Received: by mx.zohomail.com with SMTPS id 1787854798994423.41335892118434;
 Thu, 27 Aug 2026 11:19:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1787854801; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=VvYifZm+ID/J48pulKqSqReUyxvCUZZRgFyBY7yFAu5jZq37X97q+3TpzF91mIRwsf26Qo45XU37V5bKTOivTlJ+prLEUv5SJhj2BwwcGhj+RqHWFc6SFIT+SRAzTuMy0LYO+uMvsbvWcu3LQrzh4TGpjeomM4JZy2dx+AIZ+8U=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1787854801; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=vC6jIOYZEU+PKqVSGepJRBncJi7aE2sf/+9ksMpfg5s=; 
	b=m5mMfGR/rVpDfj3y2o48I6ZmM0l/HVlY//6K6XRZRcx5TDe6QtOUzx0ym/9i/lSLU2aFnu+dr3KzIX9GbPOvvsXma1qbaIfLt1ffDgogesBkXsBy3gg5khVFa8iR2A5yuGZYDtyZvEDF1YogROhHW/C5xysl4NMDLrJPci2Xt0A=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1787854801;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=vC6jIOYZEU+PKqVSGepJRBncJi7aE2sf/+9ksMpfg5s=;
	b=rQY2Amq4jXQDEumCCk0qdHSLCNsvBfweiGaE3Jgp2o8+U79su863iKUh1/Oi3XqT
	5ioxvLyTpzfXDbqJPkwqDHXXV+n8U51yBi+xisCo865MGT15WVyGBDDY58E0pDMAc8S
	JMtw6WSBOnu4XdOb9Q1ropbv1ANDnH+nrXdk5pas=
Message-ID: <bb37bbde-40b2-47ce-8273-682805fa4a3a@apertussolutions.com>
Date: Thu, 27 Aug 2026 14:19:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/14] XSM: make xsm_default_action() const-correct
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Frediano Ziglio <frediano.ziglio@cloud.com>,
 Jason Andryuk <jason.andryuk@amd.com>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
 <8df4fd76-2f19-436c-937f-e1cce371bbc5@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <8df4fd76-2f19-436c-937f-e1cce371bbc5@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1787854809-768FA4E9-9266A4BA/0/0
X-purgate-type: clean
X-purgate-size: 797

On 8/17/26 4:51 AM, Jan Beulich wrote:
> To be able to properly use const on dummy hook function parameters, add
> const to both domain pointers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> v2: Split off from Argo patch.
> 
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -76,7 +76,7 @@ void __xsm_action_mismatch_detected(void
>   #endif /* CONFIG_XSM */
>   
>   static always_inline int xsm_default_action(
> -    xsm_default_t action, struct domain *src, struct domain *target)
> +    xsm_default_t action, const struct domain *src, const struct domain *target)
>   {
>       switch ( action ) {
>       case XSM_HOOK:
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 18:24:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 18:24:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401361.1637070 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzelv-00024l-2S; Thu, 27 Aug 2026 18:24:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401361.1637070; Thu, 27 Aug 2026 18:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzelu-00024e-Vl; Thu, 27 Aug 2026 18:24:18 +0000
Received: by outflank-mailman (input) for mailman id 1401361;
 Thu, 27 Aug 2026 18:24:18 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wzelu-00024Y-6G
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:24:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzelt-003mjq-JS
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 20:24:17 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a9080cb-e002-0a2a0a5209dd-0a2a4503b486-8
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:24:17 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a9080cf-fae8-0a2a45030019-888fbc3352a4-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:24:17 +0200
Received: by mx.zohomail.com with SMTPS id 1787855044478593.1115095426314;
 Thu, 27 Aug 2026 11:24:04 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1787855046; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Qa/5Nzk7KEkvNWU1rvfiM7/mAzlk1eM8tpzXPlCMrcu6QuVZZY4dwcOZvec73PE9D4cMNRmVikWsy9rgRW/S84q4UxvIupa/Yu+sEfeCTgaPDH96+00ICiw54zaswPS2LRkVWoOak3359KED+ls61lcqUj0X8BQNudI9Kp5VNVA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1787855046; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=WgcjQHF8Gc4sAyKfmHIZHaXXMFKX771lzyhe2NzUA64=; 
	b=cMEsZXlSFFTNa2H+owvl8j1W4VOCGg3qSA9C/lmX9Yt5Vt5qbya/P4s+V95inkfXvzvH4kEmRQd9OkWSfAz8Z7dryDN9NycqWX1O5Q/eVZ+1hl4N0EyI1swJOM8CGOBGEwUYWgQJRj3uc5o8uSNpaO+ShZ1U1+JBNda/X6TRJxs=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1787855046;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=WgcjQHF8Gc4sAyKfmHIZHaXXMFKX771lzyhe2NzUA64=;
	b=QTjl1/aAjjdYRf6blaW+uzMbjPf86dQ7VHPRnh5VXrPq/Tl37+864PkXJFOzSOcx
	4cC0tqbtDgTiWpIbsGMz0avcIRWENXZOChUVaN279yhJdc7L9KwPrqyodEvrBWvvGCj
	jHrX7gWj2hSHMjcUqwtUct5HPwnbv3ybSNPfUZF0=
Message-ID: <3bca5ff9-cabb-40d2-b1fb-49ddeb810815@apertussolutions.com>
Date: Thu, 27 Aug 2026 14:24:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 05/14] XSM: make Argo hooks well-formed ones
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Jason Andryuk <jason.andryuk@amd.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
 <e73894ff-7ef7-4db0-9d91-45870b0d3c83@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <e73894ff-7ef7-4db0-9d91-45870b0d3c83@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1787855057-764FC4E9-4E92EF66/0/0
X-purgate-type: clean
X-purgate-size: 559

On 8/17/26 4:53 AM, Jan Beulich wrote:
> For whatever reason they didn't have an xsm_default_t first argument (to
> cope with XSM=n mode), making it impossible to (easily) cover them in
> xsm/hooks.h.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> v2: Drop uses of current->domain from dummy handlers. Move const-ification
>      in xsm_default_action() to a separate patch. Re-base over re-ordering
>      of series.
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 18:25:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 18:25:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401368.1637079 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzemz-0002Z0-Am; Thu, 27 Aug 2026 18:25:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401368.1637079; Thu, 27 Aug 2026 18:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzemz-0002Yt-7t; Thu, 27 Aug 2026 18:25:25 +0000
Received: by outflank-mailman (input) for mailman id 1401368;
 Thu, 27 Aug 2026 18:25:24 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <dpsmith@apertussolutions.com>) id 1wzemy-0002Yn-7Y
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 18:25:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzemx-00CDW3-Kb
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 20:25:23 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a9080f6-bab6-0a2a0a5309dd-0a2a4503af32-40
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:25:23 +0200
Received: from [136.143.188.51] (helo=sender4-of-o51.zoho.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <dpsmith@apertussolutions.com>)
 id 6a908111-fae8-0a2a45030019-888fbc3352ab-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 20:25:23 +0200
Received: by mx.zohomail.com with SMTPS id 1787855111753674.7447804924414;
 Thu, 27 Aug 2026 11:25:11 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@apertussolutions.com" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
ARC-Seal: i=1; a=rsa-sha256; t=1787855114; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=FeEH5BGAGbriGuRyme9y7bGTMLgTHK6huIleSv7bK6x+F9I7QD3JiUBORz/Crp96OKOv9tuWUp1arXNSaacUktNJYN/bHrs+8wdW88eEoi6cJbVDnX8ccms94LVpYEwSXdYOWeMsyP+abcKChEPDikRCLSz+1SQRrqNGkeApWE0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1787855114; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=eDsmXfUQvP2ggJTyhPVxuLJ/QReYaX6sZJA5lfs6QQg=; 
	b=iK1fG9xnHIhzYOxoBIqMYgdAcn6SyJmnV6U42Kn7zU1SS/TRoq0mNLhPeTJqNCkHyZTb4lgEQqysLUX1DEwK14N+4JkYR/ueQcPX7BqUKwaQBVv7MK5G3Xpewthek7Nl/vLCD/WeG+BK1eSWw0OrKIm6QSEfd4/NGZ+AiFzU/fY=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=apertussolutions.com;
	spf=pass  smtp.mailfrom=dpsmith@apertussolutions.com;
	dmarc=pass header.from=<dpsmith@apertussolutions.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1787855114;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=eDsmXfUQvP2ggJTyhPVxuLJ/QReYaX6sZJA5lfs6QQg=;
	b=Y1z5Wq9hUNZUhM+kO7k14Wk+5hH0HzoPf7kSdUqifhc+Xqx27LQFHxu4hhlwx35I
	xIPnOPEuPfpH1qf744pVr+EnxcBPggxPd957QoLUDBWkKUtL/AKZWc6q0s56fhRxf3e
	WeHuhrKNGaEYRH7byKo/vFqoPiKkHJzeQ2ks3P5g=
Message-ID: <cf9edc7a-3b7c-4309-9b1c-375236765a2a@apertussolutions.com>
Date: Thu, 27 Aug 2026 14:25:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 06/14] XSM: fold xsm_{,un}map_domain_pirq() hooks
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <ef09b072-c935-459e-bf8b-81c96ff9cc46@suse.com>
 <236a8612-d431-4972-92b3-4d62e8f10bb4@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
In-Reply-To: <236a8612-d431-4972-92b3-4d62e8f10bb4@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External
X-purgate-ID: tlsNG-33051d/1787855123-756834E9-771FC7BD/0/0
X-purgate-type: clean
X-purgate-size: 461

On 8/17/26 4:53 AM, Jan Beulich wrote:
> Like other resource management hooks they are different in just "add
> resource" vs "remove resource". Hence like in other cases a single hook
> can easily serve both purposes. Rename hook and functions to fit
> xsm_io{mem,port}_mapping().
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: Rename hook, functions, and new parameter.
> 

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 19:57:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 19:57:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401421.1637089 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzgE8-0003Ox-Lw; Thu, 27 Aug 2026 19:57:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401421.1637089; Thu, 27 Aug 2026 19:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzgE8-0003Oq-Go; Thu, 27 Aug 2026 19:57:32 +0000
Received: by outflank-mailman (input) for mailman id 1401421;
 Thu, 27 Aug 2026 19:57:31 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ayan.kumar.halder@amd.com>) id 1wzgE6-0003Ok-MS
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 19:57:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzgE5-00GDl4-A7
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 21:57:29 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ayan.kumar.halder@amd.com>)
 id 6a90966e-bab6-0a2a0a5309dd-0a2a4508c178-46
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 21:57:28 +0200
Received: from [40.107.209.41]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ayan.kumar.halder@amd.com>)
 id 6a9096a5-f659-0a2a45080019-286bd12993bb-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 21:57:28 +0200
Received: from BN9PR03CA0201.namprd03.prod.outlook.com (2603:10b6:408:f9::26)
 by DM4PR12MB6328.namprd12.prod.outlook.com (2603:10b6:8:a0::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.8; Thu, 27 Aug
 2026 19:57:19 +0000
Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com
 (2603:10b6:408:f9:cafe::32) by BN9PR03CA0201.outlook.office365.com
 (2603:10b6:408:f9::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.10 via Frontend Transport; Thu,
 27 Aug 2026 19:57:18 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 MN1PEPF0000F0DF.mail.protection.outlook.com (10.167.242.37) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.382.8 via Frontend Transport; Thu, 27 Aug 2026 19:57:18 +0000
Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 27 Aug
 2026 14:57:18 -0500
Received: from [10.71.198.170] (10.180.168.240) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.45 via Frontend
 Transport; Thu, 27 Aug 2026 14:57:16 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=taA2ubgi1m/FUN0kY92dFrxnvoP1xJRpEonJV4O9ZE07ltoSw+gF7upA35ZHuAAN/y5ro/000yDdXTDX8loWiLptKG7FaRiZBagoDqm7wpoCUSn1fG/UZcKc6CsO0/lqZSdqMlXzoV6uToM8NVPwewKtoitN0oME60ElTylAsOTO9rO4jz+4FnUzwSgZFQhlnEcWqtDM3UHdmMIURMDodcTYYJ22pQKMHppsicCXYyZ8gKgU9fDn5doWxia2AyxZoEawbsC3HCLShTBdrYXTiAjhKPhEsXwj0CVJcJKFYaR60qAMUwhbm8vASxLuYISvbVoy8W67hK2gHOX+RsymYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tMfEbo899TzTcpBwUVQqcC0pOsnV+on/UKm8PTsRT/o=;
 b=y6F6g2jMfUxHmM1btBCz3Ye1sizwzniRgtheqcaAHMCg3hY2Zk2i+U2KdNMjzaPMvvN4qFaE1p3up8DwqbXa+DU1P/VQJn3nn3vNbFR1ArQkITcV/B0rnWfaQZ2tRxVGut7aJnujCwd3cNQkKbWlZcRzkV5KBCUucCKPb+0jzUmhD47kdmZCnQPK4dymIMVoKAMFpa0/VEnRB94GRfoFoZUSQZBLP5Fkv6JI9wEdblHqHrQjFQ+I6lprTlcej72EloSvMxNIq0vb4hqSpo/6x89JsRR4yy+49z+zCl0R3w1YXbrogDQ+rN/xHA6Z9r1BHs66MW/lWB4eB8RvxQolZQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tMfEbo899TzTcpBwUVQqcC0pOsnV+on/UKm8PTsRT/o=;
 b=F+eVfEDlUzMcRyXe3CPjKlTuS5daYtatQnPX/bZhuXCYzQh0Qf+heAPgTWjpLCRTJ+p7D0Uh0W8bN9IqX2ziCZBHD0yDpOO5m2L7FwFi0ugrnkOuqw6+ZQ0ju39m8oefcZKC2rO1FrrEPWhovAb2b2fh+Du5D4faUOeckXJmSxU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <5ab7244d-66fb-4f06-a88d-5c64d515e760@amd.com>
Date: Thu, 27 Aug 2026 20:57:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 for 4.23] Add GICv3 SGI boot/self tests in Xen
To: Julien Grall <julien@xen.org>, Ayan Kumar Halder
	<ayan.kumar.halder@amd.com>, <xen-devel@lists.xenproject.org>
CC: Doug Goldstein <cardoe@cardoe.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Andrew Cooper <andrew.cooper3@citrix.com>, "Anthony
 PERARD" <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>,
	"Jan Beulich" <jbeulich@suse.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	<roger.pau@citrix.com>, Bertrand Marquis <bertrand.marquis@arm.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260529170956.49797-1-ayan.kumar.halder@amd.com>
 <b1e5ec80-a6be-4339-a06e-a47110349cd4@xen.org>
Content-Language: en-US
From: "Halder, Ayan Kumar" <ayankuma@amd.com>
In-Reply-To: <b1e5ec80-a6be-4339-a06e-a47110349cd4@xen.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0DF:EE_|DM4PR12MB6328:EE_
X-MS-Office365-Filtering-Correlation-Id: a8fe74e0-fd7a-45de-1c4b-08df0475667f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|82310400026|1800799024|7416014|376014|36860700016|13003099007|11063799006|6133799003|4143699003|5023799004|10067099003|56012099006|18002099003|22082099003|3023799007|10063799003;
X-Microsoft-Antispam-Message-Info:
	oj7urbt/t6W5ct+P6Av998fvRxGZyJvilMRmw5N9G2Iw1Mt4NibKUQleHr9OR5volVOQtJClQUpXJ9UVcy1uRu28atiM/blLQ9o54wybqnnDMK8pYPen4tRccOG0LEKnFFOE17s9ZyxbhdVV32mkDdZPB+2DMN3zRMgqa7lg73AEnUjXvsJJeNJqqaYvI4s6XpBmmITMi/J6sx3y3/UGfvis7eNpCrLN+GEyvWEmsAmORf4GNWhpAF7C7ji4W2ykedpW2mELN1Nyge7Bx7auXkFylUzxyms/VG7pOriWHCC/cIdIa1rZpA86DEykTfo+Q02Kehi21d9ShA4sBQgxODuZFs5uuWNo+kafrcPol0Eh9pzH0t0Waez3wer/4//81iAIGW2EHjjAHvnY8UbvDFhAwl5lJbJdqAU4YmfnkLit7TxZDD/HvJ9FjG1tUbJ4txhCEyvnUOmZJ3n/zq0hqpnI0e0hkxgaPj7rMHLZkM4kQ/VG6niKw2ToFa738nNsbsBUAqZxzgKm/d/5WZAOQ/YU7/kV24J5O23WXjMfjcS3Ibq50VxArjrXbJJrdqdaMXMbuvVEUYo8Thbd/AWr2BjUOX09lYY/zvkIPV97JYJzkkiPPFhwQdWoLO6ZmKH56mUvz5scAuBct1Ek77qk6g==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(1800799024)(7416014)(376014)(36860700016)(13003099007)(11063799006)(6133799003)(4143699003)(5023799004)(10067099003)(56012099006)(18002099003)(22082099003)(3023799007)(10063799003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	Q8vgWheaJ5TASn5fT1e2OWT1lzcJJmW9zIcZ9mDHZgDEDStLSJvcsGmASIBo29d5DWGsXsemTR6/xWIDUzOlH65vfXLC40UUvqj4rwv2if5cQC2HtqKvMpJ+DknD0UTVYBwV80k6TFUEFVqo6rrqTWk8j9eXSkVXxRcpUSLl0yjOmFUomepv6C/mq8c7zaFShgZMtRoH4yxEhKc47LUbXhGSx90XoqPfmrXDPxQJr9C/fXFtXYeEfSI2QOgSfERoKFl5mCmlI5/x8FffFfLR3z0mRJ5GR2Yu3PMApfDr4MD/0sc9Ibq1MuNQTk7zjkpIozsQAOeosJeaJ+i9exGw+2CvmRrdmU+MZXGVJybZI0mQHHER/4WcyrXOVV0igq+ia3IiXuU/S3StseC/aCklRNXYpeyU590opOOwbeDXKUCSJDQ5pgBSkh739na/AgZb
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2026 19:57:18.6758
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a8fe74e0-fd7a-45de-1c4b-08df0475667f
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MN1PEPF0000F0DF.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6328
X-purgate-ID: tlsNG-c1860d/1787860648-D477387B-B8BA7429/0/0
X-purgate-type: clean
X-purgate-size: 22587


On 19/06/2026 22:12, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
>
> On 29/05/2026 18:09, Ayan Kumar Halder wrote:
>> Boot self-tests (also referred to as boot-time tests or power-on
>> self-tests) are intended to validate internal features of Xen during
>> bring-up. They are meant to be run in a debug / validation environment;
>> Xen is not expected to remain functional for production use after the
>> self-tests have executed.
>
> Looking at the code below, isn't Xen functional even after the self-test?

Yes as discussed on Matrix, I have modified the test so that Xen boots 
normally after running the self-test.

Xen will panic if the self test fails.

>
>> The purpose of these tests is to catch
>> hardware configuration issues early and to confirm that the platform
>> on which Xen has been brought up is sane. The expected flow is:
>> build Xen with the self-tests enabled, boot it, inspect the results,
>> and then reboot into the usual production configuration.
>>
>> Introduce the tests to confirm that:
>> 1. A cpu can send SGI 0 to itself
>> 2. A cpu can send SGI 0 to another specific CPU
>> 3. A cpu can send SGI 0 to all the other CPUs
>> 4. A cpu can send SGI 1 to another CPU
>
> I am not sure what you meant by SGI 0 and SGI 1? Below you seem to be 
> use only a SGI (which is neither 0 or 1) except for one specific test: 
> cpu 0 injecting an SGI to a specific CPU (0).
Yes, I fixed this in v3.
>
>>
>> These tests aim to test Xen has configured the GIC correctly to use 
>> SGIs.
>> Thus, the tests invoke specific APIs of GIC driver.
>>
>> Also, introduce a config CONFIG_BOOT_SELFTEST which enables these tests.
>> The option defaults to N; it should be disabled for production builds 
>> and
>> is intended for the validation pipeline and coverage measurement. The
>> tests run during Xen boot and validate internal interfaces such as Xen's
>> interface with hardware, firmware and the bootloader.
>>
>> Also, introduce an integer command line parameter "gic-test". By 
>> default, it
>> is set to 0 which means no tests are enabled.
>> For running SGI tests, "gic-test" should be set to 1. In future if we 
>> add
>> tests for distributer, ITS, LPI, etc, then we can use different numbers.
>> Thus, each number denotes a functionality of GICv3 which can be tested
>> independently and within a single boot of Xen.
>>
>> In this way, we ensure that the tests to validate SGIs do not impact 
>> any other
>> tests.
>>
>> In order to keep all the boot-time self-tests together in the binary, we
>> have introduced a separate section "initcallboottest". All the tests are
>> registered using __initcallboottest. During the bootup of each core, Xen
>> invokes do_init_boottests() to run the these tests. All these tests are
>> invoked before Xen creates the domains (in case of primary core) or runs
>> the idle loop (in case of secondary core).
>>
>> Note: it was suggested that, once the boot self-tests have run, Xen
>> should call machine_halt() rather than continue booting (since this
>> build is only intended for validation). This is not wired in here
>> because the SGIs are sent from the primary and secondary CPUs and
>> received asynchronously on the target CPUs. There is no definite point
>> in the boot flow at which Xen can know that every send has been
>> observed by its receiver, so "after the tests have completed" has no
>> well-defined moment at which to insert machine_halt().
>>
>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
>> ---
>> Link to v1 (RFC):
>> https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00956.html 
>>
>>
>> Upstream CI run (xen-project/people/ayankuma/xen fork, one commit on
>> top of xen-project/xen staging — all Linux builds + tests including
>> qemu-smoke-boot-selftest-arm64-gcc-debug passed; only the macos jobs
>> sit pending because the personal fork has no macos runner):
>> https://gitlab.com/xen-project/people/ayankuma/xen/-/pipelines/2561806695 
>>
>>
>> Changes in v2:
>>   - Renamed the patch from "xen/arm: Introduce GICV3 Self Tests" to
>>     "Add GICv3 SGI boot/self tests in Xen", and rewrote the commit
>>     message to explain the intent of boot self-tests (debug /
>>     validation builds only, Xen not expected to remain functional
>>     afterwards).
>>   - Moved the selftest code out of gic-v3.c into a dedicated file
>>     xen/arch/arm/gic-test.c, gated by CONFIG_BOOT_SELFTEST
>>     (Stefano, Grygorii).
>>   - Introduced a generic boot-self-test framework: new section
>>     "initcallboottest", registration macro __initcallboottest, and
>>     do_init_boottests() invoked once per CPU after
>>     local_irq_enable(), so the test runs on every CPU (boot +
>>     secondaries) and no longer collides with the IRQ-enable timing
>>     in gicv3_init() (Julien #1, Julien #3).
>>   - Added Kconfig option CONFIG_BOOT_SELFTEST in
>>     xen/arch/arm/Kconfig (arm-only for now; arch-specific because
>>     the only registered test is GICv3-specific).
>>   - Reserved a dedicated SGI value GIC_SGI_TEST in enum gic_sgi
>>     (xen/arch/arm/include/asm/gic.h), so the selftest never
>>     reuses a functional SGI (Grygorii #3).
>>   - Added a runtime integer command-line parameter "gic-test" so
>>     the selftest binary can be shipped but its execution selected
>>     at boot (gic-test=0 -> no-op; gic-test=1 -> SGI tests). Future
>>     GICv3 features (distributor, ITS, LPI, ...) can claim further
>>     values (Grygorii #2, partial).
>>   - Documented why machine_halt() is not invoked after the tests:
>>     SGI delivery is asynchronous, so there is no well-defined
>>     point after which every send has been observed by its
>>     receiver (Julien #2).
>>   - Wired the tests into upstream GitLab CI: new build job
>>     alpine-3.18-gcc-debug-arm64-boot-selftest, new test job
>>     qemu-smoke-boot-selftest-arm64-gcc-debug, and the runner
>>     script automation/scripts/qemu-boot-selftest-arm64.sh that
>>     dumps the QEMU virt DTB, injects
>>     "gic-test=1 console=dtuart sync_console" into
>>     /chosen/xen,xen-bootargs via fdtput, boots Xen, and checks
>>     for each "Sending GIC_SGI_TEST ..." followed by the matching
>>     "CPU%u: GIC_SGI_TEST received".
>>
>>   automation/gitlab-ci/build.yaml               |  8 ++
>>   automation/gitlab-ci/test.yaml                |  8 ++
>>   .../scripts/qemu-boot-selftest-arm64.sh       | 81 +++++++++++++++++++
>>   xen/arch/arm/Kconfig                          | 15 ++++
>>   xen/arch/arm/Makefile                         |  1 +
>>   xen/arch/arm/gic-test.c                       | 52 ++++++++++++
>>   xen/arch/arm/gic.c                            |  5 ++
>>   xen/arch/arm/include/asm/gic.h                |  3 +
>>   xen/arch/arm/setup.c                          |  2 +
>>   xen/arch/arm/smpboot.c                        |  2 +
>>   xen/arch/arm/xen.lds.S                        |  4 +
>>   xen/common/kernel.c                           | 11 +++
>>   xen/include/xen/init.h                        |  3 +
>>   13 files changed, 195 insertions(+)
>>   create mode 100755 automation/scripts/qemu-boot-selftest-arm64.sh
>>   create mode 100644 xen/arch/arm/gic-test.c
>>
>> diff --git a/automation/gitlab-ci/build.yaml 
>> b/automation/gitlab-ci/build.yaml
>> index 7f5b5938e8..8df45caa86 100644
>> --- a/automation/gitlab-ci/build.yaml
>> +++ b/automation/gitlab-ci/build.yaml
>> @@ -439,6 +439,14 @@ alpine-3.18-gcc-debug-arm64:
>>         CONFIG_UBSAN=y
>>         CONFIG_UBSAN_FATAL=y
>>   +alpine-3.18-gcc-debug-arm64-boot-selftest:
>> +  extends: .gcc-arm64-build-debug
>> +  <<: *build-test
>> +  variables:
>> +    CONTAINER: alpine:3.18-arm64v8
>> +    EXTRA_XEN_CONFIG: |
>> +      CONFIG_BOOT_SELFTEST=y
>> +
>>   alpine-3.18-gcc-arm64-randconfig:
>>     extends: .gcc-arm64-build
>>     variables:
>> diff --git a/automation/gitlab-ci/test.yaml 
>> b/automation/gitlab-ci/test.yaml
>> index 8770c523e2..2398c6299a 100644
>> --- a/automation/gitlab-ci/test.yaml
>> +++ b/automation/gitlab-ci/test.yaml
>> @@ -524,6 +524,14 @@ qemu-smoke-dom0less-arm64-gcc-debug-gicv3:
>>       - *arm64-test-needs
>>       - alpine-3.18-gcc-debug-arm64
>>   +qemu-smoke-boot-selftest-arm64-gcc-debug:
>> +  extends: .qemu-arm64
>> +  script:
>> +    - ./automation/scripts/qemu-boot-selftest-arm64.sh 2>&1 | tee 
>> ${LOGFILE}
>> +  needs:
>> +    - *arm64-test-needs
>> +    - alpine-3.18-gcc-debug-arm64-boot-selftest
>> +
>>   qemu-smoke-dom0less-arm64-gcc-debug-staticmem:
>>     extends: .qemu-arm64
>>     script:
>> diff --git a/automation/scripts/qemu-boot-selftest-arm64.sh 
>> b/automation/scripts/qemu-boot-selftest-arm64.sh
>> new file mode 100755
>> index 0000000000..a37dba3e07
>> --- /dev/null
>> +++ b/automation/scripts/qemu-boot-selftest-arm64.sh
>> @@ -0,0 +1,81 @@
>> +#!/bin/bash
>> +
>> +set -ex -o pipefail
>> +
>> +# Boot the prebuilt Xen binary under QEMU with 
>> CONFIG_BOOT_SELFTEST=y enabled
>> +# and gic-test=1 in xen,xen-bootargs, then verify the four GICv3 SGI 
>> self-tests
>> +# pass by inspecting the serial log.
>> +
>> +XEN=binaries/xen
>> +QEMU=./binaries/qemu-system-aarch64
>> +DTB_RAW=binaries/virt.dtb
>> +DTB=binaries/virt-bootselftest.dtb
>> +LOG=smoke.serial
>> +
>> +test -x ${QEMU}
>> +test -f ${XEN}
>> +
>> +# Dump the auto-generated DT from the QEMU virt machine, then inject
>> +# /chosen/xen,xen-bootargs.  The selftest infrastructure invokes
>> +# do_init_boottests() during early boot; gic-test=1 selects the 
>> GICv3 SGI
>> +# tests.
>> +# -net none avoids QEMU's default virtio-net-pci, whose efi-virtio.rom
>> +# is not shipped with the qemu-system-aarch64 artifact used in CI.
>> +${QEMU} \
>> +    -machine 
>> virt,virtualization=true,gic-version=3,dumpdtb=${DTB_RAW} \
>> +    -cpu cortex-a57 -m 1024 -smp 2 -display none -net none
>> +
>> +cp ${DTB_RAW} ${DTB}
>> +fdtput -t s ${DTB} /chosen xen,xen-bootargs \
>> +    "gic-test=1 console=dtuart sync_console"
>> +
>> +rm -f ${LOG}
>> +timeout 60 ${QEMU} \
>> +    -machine virt,virtualization=true,gic-version=3 \
>> +    -cpu cortex-a57 -m 1024 -smp 2 \
>
> This means that there is no much difference between "send an SGI to a 
> specific CPU" and "send an SGI to others CPU". I think it would be 
> more meaningful to use 3 or more pCPUs.
Yes, now I use 4 pCPUs.
>
>> +    -serial file:${LOG} \
>> +    -monitor none -display none -no-reboot -net none \
>> +    -dtb ${DTB} \
>> +    -kernel ${XEN} || true
>> +
>> +# Each "Sending GIC_SGI_TEST ..." line must be followed by the matching
>> +# "CPU%u: GIC_SGI_TEST received".
>> +fail=0
>> +check_pair() {
>> +    local send_pat=$1
>> +    local recv_pat=$2
>> +    local send_line recv_line
>> +
>> +    send_line=$(grep -n -- "${send_pat}" ${LOG} | head -n1 | cut -d: 
>> -f1)
>> +    if [ -z "${send_line}" ]; then
>> +        echo "MISSING: ${send_pat}"
>> +        fail=1
>> +        return
>> +    fi
>> +
>> +    recv_line=$(grep -n -- "${recv_pat}" ${LOG} \
>> +        | awk -v bl="${send_line}" -F: '$1 > bl {print $1; exit}')
>> +    if [ -z "${recv_line}" ]; then
>> +        echo "MISSING (after line ${send_line}): ${recv_pat}"
>> +        fail=1
>> +        return
>> +    fi
>> +
>> +    echo "OK: '${send_pat}' -> '${recv_pat}' (lines ${send_line} -> 
>> ${recv_line})"
>> +}
>> +
>> +# Boot CPU sends SGI to itself
>> +check_pair "Sending GIC_SGI_TEST to self CPU0" "CPU0: GIC_SGI_TEST 
>> received"
>> +# Secondary CPU sends SGI to itself
>> +check_pair "Sending GIC_SGI_TEST to self CPU1" "CPU1: GIC_SGI_TEST 
>> received"
>> +# Secondary CPU sends SGI to primary
>> +check_pair "Sending GIC_SGI_TEST to CPU0 from CPU1" "CPU0: 
>> GIC_SGI_TEST received"
>> +# Send to all-but-self
>> +check_pair "Sending GIC_SGI_TEST to all except CPU1" "CPU0: 
>> GIC_SGI_TEST received"
>> +
>> +if [ ${fail} -ne 0 ]; then
>> +    echo "FAILED"
>> +    exit 1
>> +fi
>> +
>> +echo "PASSED"
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 79622b46a1..0e23bbf20b 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -476,6 +476,21 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
>>   config ARM32_HARDEN_BRANCH_PREDICTOR
>>       def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
>>   +config BOOT_SELFTEST
>> +    bool "Enable boot-time self-tests"
>> +    default n
>
> Above you said, this is not meant for production. So I was expecting 
> to see a dependency on CONFIG_DEBUG.
yes, I have added this
>
> If the intention is to use it in release build, given the current 
> behavior (e.g. breaking test), I think this should depend on 
> UNSUPPORTED so we don't get security report because Xen is broken 
> after the boot tests.
No, it is disabled in release build.
>
> > +    help> +      This option enables boot-time self-tests that 
> validate Xen's internal
>> +      interfaces with hardware, firmware and the bootloader. The 
>> tests are
>> +      registered with __initcallboottest and executed by 
>> do_init_boottests()
>> +      during early boot, before domains are created.
>> +
>> +      These tests are intended for validation and coverage 
>> measurement, not
>> +      for production builds. With this option enabled, Xen may not be
>> +      functional after the tests have run.
>
> If we know a test break, I think it is best that Xen doesn't continue. 
> Otherwise, it is quite confusing for the user to know what's going on.
>
> My preference is the bootest would act like other self tests and Xen 
> can continue booting normally. So the tests could also be meaningful 
> in non-test setups.
Yes, now Xen is functional even after running the self tests.
>
>> +
>> +      If unsure, say N.
>> +
>>   source "arch/arm/platforms/Kconfig"
>>     source "common/Kconfig"
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index 84c4062b30..0090761682 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -24,6 +24,7 @@ obj-y += domctl.o
>>   obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
>>   obj-y += efi/
>>   obj-y += gic.o
>> +obj-$(CONFIG_BOOT_SELFTEST) += gic-test.init.o
>>   obj-$(CONFIG_GICV2) += gic-v2.o
>>   obj-$(CONFIG_GICV3) += gic-v3.o
>>   obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
>> diff --git a/xen/arch/arm/gic-test.c b/xen/arch/arm/gic-test.c
>> new file mode 100644
>> index 0000000000..ca922e5d2a
>> --- /dev/null
>> +++ b/xen/arch/arm/gic-test.c
>> @@ -0,0 +1,52 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#include <xen/delay.h>
>> +#include <xen/init.h>
>> +#include <xen/param.h>
>> +#include <xen/shutdown.h>
>
> Can you clarify why you need this header?
I have dropped this.
>
>> +#include <asm/gic.h>
>> +
>> +/*
>> + * gic_test: Specifies the gic test to be executed.
>> + * 0 = no tests are executed
>> + * 1 = SGI tests are executed
>> + */
>> +static unsigned int __initdata gic_test = 0;
>> +integer_param("gic-test", gic_test);
>
> Given this is mean to be 0 or 1, why not using "boolean_param"?
Yes, I have this as a boolean param
>
> Also, new command line option should be documented in the docs. That 
> said, I am not really sure about
I have documented it.
>
>> +
>> +/*
>> + * CPU0: GIC_SGI_DUMP_STATE to self
>> + * CPU{0-N}: GIC_SGI_TEST to self
>> + * CPU{1-N}: GIC_SGI_TEST to CPU0
>> + * CPU{N}: GIC_SGI_TEST to all but self
>> + */
>> +static int __init gic_self_sgi_test(void)
>> +{
>> +    if ( !gic_test )
>> +        return 0;
>> +
>> +    printk("Sending GIC_SGI_TEST to self CPU%u\n", smp_processor_id());
>> +    send_SGI_self(GIC_SGI_TEST);
>> +
>> +    if ( smp_processor_id() == 0 )
>> +    {
>> +        printk("Sending GIC_SGI_DUMP_STATE to CPU0\n");
>> +        smp_send_state_dump(0);
>
> OOI, why is this only called for CPU0? You also don't seem to check 
> that smp_send_state_dump() in the CI test.
Ah, I have dropped it.
>> +
>> +        return 0;
>> +    }
>> +
>> +    printk("Sending GIC_SGI_TEST to CPU0 from CPU%u\n", 
>> smp_processor_id());
>> +    send_SGI_one(0, GIC_SGI_TEST);
>> +
>> +    /* Execute this test only from the last core */
>> +    if ( smp_processor_id() == (smp_get_max_cpus() - 1) )
>
> This is relying on how Xen is boot CPUs. Would it be better to check 
> the number of online CPUs at the time of the check? (You might need to 
> re-order some code for that)
yes, I have changed the code. I now check the number of online CPUs.
>
>> +    {
>> +        printk("Sending GIC_SGI_TEST to all except CPU%u\n", 
>> smp_processor_id());
>> +        send_SGI_allbutself(GIC_SGI_TEST);
>> +    }
>> +
>> +    return 0;
>> +
>> +}
>> +__initcallboottest(gic_self_sgi_test);
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index ee75258fc3..9736b0c7df 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -324,6 +324,11 @@ static void do_static_sgi(struct cpu_user_regs 
>> *regs, enum gic_sgi sgi)
>>       case GIC_SGI_CALL_FUNCTION:
>>           smp_call_function_interrupt();
>>           break;
>> +#ifdef CONFIG_BOOT_SELFTEST
>> +    case GIC_SGI_TEST:
>> +        printk("CPU%u: GIC_SGI_TEST received\n", smp_processor_id());
>
> To confirm, we will solely rely on logging? IOW, there is no plan to 
> have Xen self-sufficient (e.g. using a global variable).
yes, I know use a per cpu variable.
>
>
>> +        break;
>> +#endif
>>       default:
>>           panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
>>           break;
>> diff --git a/xen/arch/arm/include/asm/gic.h 
>> b/xen/arch/arm/include/asm/gic.h
>> index ff22dea40d..74bdd4ff63 100644
>> --- a/xen/arch/arm/include/asm/gic.h
>> +++ b/xen/arch/arm/include/asm/gic.h
>> @@ -306,6 +306,9 @@ enum gic_sgi {
>>       GIC_SGI_EVENT_CHECK,
>>       GIC_SGI_DUMP_STATE,
>>       GIC_SGI_CALL_FUNCTION,
>> +#ifdef CONFIG_BOOT_SELFTEST
>> +    GIC_SGI_TEST,
>> +#endif
>>       GIC_SGI_STATIC_MAX,
>>   };
>>   diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 6310a47d68..4e5db93027 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -470,6 +470,8 @@ void asmlinkage __init noreturn 
>> start_xen(unsigned long fdt_paddr)
>>       enable_errata_workarounds();
>>       enable_cpu_features();
>>   +    do_init_boottests();
>> +
>>       /* Create initial domain 0. */
>>       if ( !is_dom0less_mode() )
>>           create_dom0();
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index 7f3cfa812e..a016ff00f5 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -405,6 +405,8 @@ void asmlinkage noreturn start_secondary(void)
>>         printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
>>   +    do_init_boottests();
>> +
>>       startup_cpu_idle_loop();
>>   }
>>   diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
>> index 2d5f1c516d..14f64a856c 100644
>> --- a/xen/arch/arm/xen.lds.S
>> +++ b/xen/arch/arm/xen.lds.S
>> @@ -146,6 +146,10 @@ SECTIONS
>>          *(.initcall1.init)
>>          __initcall_end = .;
>>   +       __initcall_boot_test_start = .;
>> +       *(.initcallboottest.init)
>> +       __initcall_boot_test_end = .;
>> +
>>          . = ALIGN(4);
>>          __alt_instructions = .;
>>          *(.altinstructions)
>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>> index fb45f81399..2047fe2a3f 100644
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -412,6 +412,7 @@ void add_taint(unsigned int taint)
>>     extern const initcall_t __initcall_start[], __presmp_initcall_end[],
>>       __initcall_end[];
>> +extern const initcall_t __initcall_boot_test_start[], 
>> __initcall_boot_test_end[];
>>     void __init do_presmp_initcalls(void)
>>   {
>> @@ -427,6 +428,16 @@ void __init do_initcalls(void)
>>           (*call)();
>>   }
>>   +void __init do_init_boottests(void)
>> +{
>> +#ifdef CONFIG_BOOT_SELFTEST
>
> I think it would be worth printing before and after to indicate the 
> begin/end of the selftest.
yes, I have added the prints in v3.
>
>> +    const initcall_t *call;
>> +    for ( call = __initcall_boot_test_start; call < 
>> __initcall_boot_test_end;
>> +          call++ )
>> +        (*call)();
>> +#endif
>> +}
>> +
>>   #ifdef CONFIG_HYPFS
>>   static unsigned int __read_mostly major_version;
>>   static unsigned int __read_mostly minor_version;
>> diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
>> index 0c921672c1..bd518bcea9 100644
>> --- a/xen/include/xen/init.h
>> +++ b/xen/include/xen/init.h
>> @@ -66,11 +66,14 @@ typedef void (*exitcall_t)(void);
>>       static const initcall_t __initcall_##fn __init_call("presmp") = 
>> (fn)
>>   #define __initcall(fn) \
>>       static const initcall_t __initcall_##fn __init_call("1") = (fn)
>> +#define __initcallboottest(fn) \
>> +    static const initcall_t __initcall_##fn __init_call("boottest") 
>> = (fn)
>>   #define __exitcall(fn) \
>>       static exitcall_t __exitcall_##fn __exit_call = fn
>>     void do_presmp_initcalls(void);
>>   void do_initcalls(void);
>> +void do_init_boottests(void);
>>     #endif /* __ASSEMBLER__ */
>
> Cheers,

Thanks

- Ayan

>
>


From xen-devel-bounces@lists.xenproject.org Thu Aug 27 21:59:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Aug 2026 21:59:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401458.1637097 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzi8E-0008Kn-VT; Thu, 27 Aug 2026 21:59:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401458.1637097; Thu, 27 Aug 2026 21:59:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzi8E-0008Kg-SS; Thu, 27 Aug 2026 21:59:34 +0000
Received: by outflank-mailman (input) for mailman id 1401458;
 Thu, 27 Aug 2026 21:59:33 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Volodymyr_Babchuk@epam.com>) id 1wzi8C-0008KZ-Pk
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 21:59:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzi8A-0006rH-He
 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 23:59:30 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a90b29c-bab6-0a2a0a5309dd-0a2a4504e33a-34
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 23:59:30 +0200
Received: from [52.101.65.78]
 (helo=DU2PR03CU002.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Volodymyr_Babchuk@epam.com>)
 id 6a90b341-b57f-0a2a45040019-3465414e11f4-3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 23:59:30 +0200
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29)
 by GV2PR03MB10952.eurprd03.prod.outlook.com (2603:10a6:150:279::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 27 Aug
 2026 21:59:26 +0000
Received: from VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com
 ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0360.006; Thu, 27 Aug 2026
 21:59:25 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xHcygqwWKbfkf9JLAeB34gpGGkTovtuR+28iDYVTyR6q27Ksu+Ph/Am6RYew0UhvjqmhD8Iczp7PhjXcQQrt9eh0+v4B3y0SXp32ZwAvNV0Yl+VGqQvgFDaFjGuS9loA3GOkuo0rrNbMp3oVzuIruiQYAMyOfEp8zXjmeXDen09g1iyuiu11SzlfDvUIA9NzTSx08dH7mnegf4aKxvEvfVsHARZyCIYjrw4HsL6LkChYwELpVfOdZROJj76MiJv9Vmr1owISWPlnYKZynHRWFl8n4FFpLXkWqrW4pS0W0ANEyHi4Zi/UV7kErFHKf3eFzEW/tjmhH9V2ptob/MdLHg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ooVH48yqk1bzMn6RH+KuMySCBqlnQ+Fj7jfI64jYRU0=;
 b=LEIBnHQk+FFFv1lyFoLkqV0qtKs2YG0oCIlTrTHG/PfbKpLJDsqs/+k6G1Ira5C5HHvUVAynjmTasSGMraihS88r4Y/2Hv49Z93G6/K/98kCejwYrdGQgwMF6lbRNDgPDEW9DRIf6765uxMuynmeFzXIkdRnkQtluMXDiBy3oMynvNNyP600+Gv4eRhHQs+OwNPJBDaor9L0It/pG26Gw0Z67TW/1/aQolH4FBBXXo4q6ywlMgR2njpp4AYiFeLE9/wPUSUAvM/t7gnXp7EDCqqMYy3of8h0YFVSuZ3A8Gn/jTIcyPWUC/TVrKQqdsSJ/2uowgPVLXrWx5/HSW4/7Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ooVH48yqk1bzMn6RH+KuMySCBqlnQ+Fj7jfI64jYRU0=;
 b=f/0P00PMeEI3kcOh7lJ314gnjrgPaYFpPP0B3yF7SAAtcC27lCwRn1CwpsxZM5MAmVzOoRhYyMsZrkwAFZdb1kJOgb5GrZ2JXXZytw5Xz8ldcygIVFWZ4E7vu+B4Bh6yvXlvFnlfCeOLABp3bvHyEjtPnmXynd12ZVaIlFTyY01n7zTeHqiA3BoWnPeTuV6BM0uYlrLK1STLfP7QkIlIxj5i+ZxOYVtXssdrv4F7e0F03wLxGZdCnJ1dW+cAlk35sOWo7/vhezR8GNvSD44oO/CfEfyLbXL5J+JavCVsbYi9iBOpRPF+z4vhjcALwwFlyU61O0tiajLMhisKB8AL5g==
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Mykola Kvach <Mykola_Kvach@epam.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v12 13/13] xen/arm: Add host system suspend backend
Thread-Topic: [PATCH v12 13/13] xen/arm: Add host system suspend backend
Thread-Index: AQHdNjDpN5STlrpYfEyx41qjOa3h6Q==
Date: Thu, 27 Aug 2026 21:59:25 +0000
Message-ID: <87mru7w7gk.fsf@epam.com>
References: <cover.1787838455.git.mykola_kvach@epam.com>
	<9d3cf11530edf478ae7a597f1c0934f4b7b1a270.1787838455.git.mykola_kvach@epam.com>
In-Reply-To:
 <9d3cf11530edf478ae7a597f1c0934f4b7b1a270.1787838455.git.mykola_kvach@epam.com>
	(Mykola Kvach's message of "Thu, 27 Aug 2026 17:32:01 +0300")
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: mu4e 1.14.3; emacs 30.2
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|GV2PR03MB10952:EE_
x-ms-office365-filtering-correlation-id: de190417-e6c2-4abb-ca4b-08df0486759e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|23010399003|376014|42112799006|366016|38070700021|3023799007|56012099006|10067099003|6133799003|5023799004|11063799006|4143699003|18002099003|22082099003;
x-microsoft-antispam-message-info:
 31Ulm/vpYSIi6G4tXW/NDQ7zroXa9lb/H3lfSOdWtMevYCVqbonoYJoMUgE7DiSAjHn3H04/HEghzu9RYHfBVDzBCf42s1UP2Xv8XNSVu0utMxv202yk2L4C3JdNXsq7ATocncVG57/3PNhYf50ek4ck+YV10SvDzfJq3gT+3cFpZRIQZ7ogymQ7REp9tqFKwh1i8nxl50N4I5k/zzy5zYZBepWpuNZqOgv934nzWJv3lHMqpktxG9v/SabZS/d8IdniUAc1T39QEsl17SGAHesi0MTEdbGtyWJtcouIVFw+RqSH3JGyfdExRE6bWlJwnlybVcU69NtFQ9Ayb1g+kU/TeWUNnaPFiHJPMisPFymyo4JYqG+fmfLYcJ32QVvR9vhpC6x65DEug9hsB8jcRCK/trT4IHQgP7AQD3GHXDzgbREA5t9cztUC14EUk61gy7qJ797kJCUIvCGBowwd0c7//sdp0/DONSww1bC1pYZ1FmwOF46X2avwgckealNKCmgMDIBSCFKSnTWdeHzvTBFm/GZN1AVZgOZV19nniVx54cEvwLJU+khIiIzc+MXb7ASk3W2UmmDEbY2dKZiwlzwZsUqOUgVgbmEsU9YDr1XYR0aeGix+/jIOybCDfoxvTew28dmB0yRHpXUp623NIYtN6/sAuYTF4xt29vBmxA06cwoUb5AbeygZVXiHErA+kKUg4+gs4kJxGyiTmdD27W0BEZZW8DJ6odh2KSlZRwA=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(42112799006)(366016)(38070700021)(3023799007)(56012099006)(10067099003)(6133799003)(5023799004)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?R29SL0tLUzNxM0RzZzZIM1NXbUhWSDUvZFdQN21mc2kvaUxNNkxaSW1CS0Ry?=
 =?utf-8?B?K0ZvUTROcnZjS2NVN25xakJ6UDNrY3MzQjRzb1Z3UFlZdnd2cmVPb21ORzA1?=
 =?utf-8?B?Q2RJNm9jdTc0VndWSjJlSlhGa3JjV1gxaVUzdVRYRCticEVuWW1qK3U4OVJv?=
 =?utf-8?B?YkllQmx5cGY0QXFCTXhPaXgvOUN6dU9xa0ZXRE95dmN1RlZ6UXFzR1R1RlR4?=
 =?utf-8?B?ZzdDR3RVem9UdXUrdXA5QVhaWjVQSU5Cb29KUlVqSTR6NjNwdDVqT283WVBC?=
 =?utf-8?B?UVlldkpOV3A5dHV2RHNrUyt5Qm1wazYzZWI5T3JrbHlEZG9tK1RqVk5CcUlw?=
 =?utf-8?B?VkpRZGdvRWhRTW9FRU16ZDZpejUrSUkyZHk5cVluWGVBVmUwMkNJMXRERytm?=
 =?utf-8?B?MVlTWlpSbjNCNzNPeGU2OFk3WFpudUowOGhGQ1BzRmZmUnNKRS9OVzlGVk51?=
 =?utf-8?B?VC9vV2dlS2w3UmZReEtWZjBzUGQrYklhbEFadWJ0RnJBRFJnK0ZudVBRc2p6?=
 =?utf-8?B?UkhySGRWejZmMGxXRStjQzkyNWVHdTBGa2RyVzRTTGEwdUIvMytwNUROMnpI?=
 =?utf-8?B?bHkwbGdPOUNnRzd5NVB5bVVqUko5WVZvYkxycWtoUkVDVGJhNE5qclRHRWc4?=
 =?utf-8?B?S3pBQWNKUnB6WVBvcGxBb2V0YUpHQ3ovdjU1Z0RPR3Z4bUROQjdRZCtDTUZm?=
 =?utf-8?B?R1liS3dwNTZhS0RDb0NYMmhtT2cwSGo3WFFWajQvUy8vMWw0dlRtSUJNNGtm?=
 =?utf-8?B?cGI2ZnBCNFBxUldpVFZSTTdwRkVpYjVRTGc4TTNwRjl0eHE2T0JRd3lzR09B?=
 =?utf-8?B?cHp2eW0yU2IwMWJyVVFoQmh0WEprVlVXTEFjN2QxWUNSNTBBeG5aL3lDRVpI?=
 =?utf-8?B?VWlQRlJhcFY3WEV0RDc4anhHZEs1U0VjU25xLzV0OGdMbURNbDVZeVBQdEkw?=
 =?utf-8?B?MDFHUFhRNEUrbTB6cW9RakpBc0M0Mno0ZktKUFprdTd2YjJZaC9iZTJmenhk?=
 =?utf-8?B?a0VBZE11dTZVRVd2TUM0bkdKVXhHek1SR1l6b250cmtLaStIOEhQZUtkVC9m?=
 =?utf-8?B?SStwOUYvWFFvb1RyNXJWdStRcW1EYWt5dGtraFQzcEtRUkprdCs1ajZBenZw?=
 =?utf-8?B?ZVR2YkJWL0QyS0YyZGFPTmF5SThHSFBTNnJCUEc5Yy9TRFhTaVlBUmkvUCtV?=
 =?utf-8?B?UktHUFI2S2t1REV1cG1GWjBkQ2c3SUtoSGxBN2tpa1JmU1Z6WEd3RG5uR242?=
 =?utf-8?B?OFJRMjhNVGlVdWsvV2FFSVBkUE0yMkIrWWJ1VVc4aUthQzVhSzltOFFiSnlK?=
 =?utf-8?B?Vkw2aDAxS3ZPazJSai9XeENTNFQ0UEcvU2lFOVVlS1BFWEdnNHV4cWtSK1c2?=
 =?utf-8?B?NmFzVVB4UmdEQXl4WE93TmN6bm8xRU5wSkpSOFlzelRMNzBWR3RPVnc1cnVa?=
 =?utf-8?B?aDQyRGZLLzlidDlBUHZXZ1hBYXN1ZXFQRjRRNnEra25iRGFtaWpPQkw5MDUr?=
 =?utf-8?B?OWY3bVJTV2U4WnBrMTZRZW9WNGhpcjVObnpsamovZDRlVGtzYWdPVXgwV25q?=
 =?utf-8?B?dVdjMDc5S1E5MGNGaThxQUYydDdvd25qMElEUTNsUlJEMUF2bVNrazNUT052?=
 =?utf-8?B?b0xld3hHc1VLckZ3OTRRMFl6bFNrYTFMVnliTXdwNElta2hTRk9jTmVReE5R?=
 =?utf-8?B?MDdUQXBrRkZ1TXdwNmFCS0dVb2ppRDB5dnFJd1M4R2RJRnJkcEZPMnY2REVW?=
 =?utf-8?B?VDEvZWZZaEpSeTExd1JlOXBvdWsySWJoR003TEdIMnNsRkI4a0JCMmd2R2Zq?=
 =?utf-8?B?K3FzS1hncDVmSGg1Y09PVFVNQVlUcHllNDBSeUkwdGFaMmtwY3Y4Znozbkxs?=
 =?utf-8?B?bzVkdFpmT2tPQTdHMGN6eHNOcUNXc0YzdkRIY1ovR2pYODBBMk4zb3A0QWkv?=
 =?utf-8?B?b1hyYWJ1Q29UOE95b3pKWEZWcjd6RmlzdW5Ja210bng5N0RIWC9TazZVWWpW?=
 =?utf-8?B?RjlmaGE4T0RKOVpRMld2VnJONUIvb2pyaGF6UnhsSHBXQU9pT0JsUGlPUUE3?=
 =?utf-8?B?RzFPVm1zSFZyMWhTaHljM0ZXTEhJMGNwQ0RHRDBYeGh1TGNnR0FKNHBGdjJF?=
 =?utf-8?B?bUR6andzbmpyeEUwRDhHUjVDSU1tczFTOXFYcUtDVDhjSUM1cUtpd3h3dmV6?=
 =?utf-8?B?bzVWOEFPdlhTNCtJUXhXa2xYUTlhSFR2Nm1yUzdUczZybUdsUVJ3WVkvRzhy?=
 =?utf-8?B?SURuVUNqb0tsNnVDUHFLSVZVRW9DVTRFd0FOb0NPMVB5dXUvak5vVzhzY1d2?=
 =?utf-8?B?aFNvdWtIcy9MVU1VSy9jNWd6V2pCK0l0RzZsdUlNZkRWQXJmSmhEMkZFM1pt?=
 =?utf-8?Q?jVlMu9YEN+459OjA=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: de190417-e6c2-4abb-ca4b-08df0486759e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2026 21:59:25.5178
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mZ3F2sFp2qaseNjJFmUmGQoH0212BaaErxky5KUe/vF1OnEeZny+Fjt/mz4ZK0r7q0ZfMRc5qiajlPzODlyC9vksu8bAjiEXU/1RvsB0LzA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB10952
X-purgate-ID: tlsNG-ebf023/1787867970-C1AD0B50-48355DB1/0/0
X-purgate-type: clean
X-purgate-size: 20318

SGkgTXlrb2xhLA0KDQpNeWtvbGEgS3ZhY2ggPG15a29sYV9rdmFjaEBlcGFtLmNvbT4gd3JpdGVz
Og0KDQo+IEZyb206IE1pcmVsYSBTaW1vbm92aWMgPG1pcmVsYS5zaW1vbm92aWNAYWdnaW9zLmNv
bT4NCj4NCj4gQWRkIHRoZSBYZW4td2lkZSBzdXNwZW5kL3Jlc3VtZSBiYWNrZW5kIHVzZWQgYWZ0
ZXIgYSBjb250cm9sLWRvbWFpbg0KPiB2UFNDSSBTWVNURU1fU1VTUEVORCByZXF1ZXN0IGhhcyBi
ZWVuIGFjY2VwdGVkLiBUaGUgdlBTQ0kgcG9saWN5LA0KPiBydW50aW1lIGRyaXZlciBibG9ja2Vy
cyBhbmQgY29udHJvbC1kb21haW4gc2VxdWVuY2luZyBjaGVja3MgYXJlIGhhbmRsZWQNCj4gYnkg
dGhlIHByZWNlZGluZyBjb21taXQ7IHRoaXMgY2hhbmdlIGFkZHMgdGhlIGNvZGUgdGhhdCBhY3R1
YWxseSBkcml2ZXMNCj4gdGhlIGhvc3Qgc3VzcGVuZCBhdHRlbXB0Lg0KPg0KPiBUaGUgYmFja2Vu
ZCBydW5zIGZyb20gYSB0YXNrbGV0IHNjaGVkdWxlZCBvbiBwQ1BVMCwgYmVjYXVzZSBub24tYm9v
dCBDUFVzDQo+IGFyZSBkaXNhYmxlZCBkdXJpbmcgc3VzcGVuZC4gSXQgZnJlZXplcyBkb21haW5z
LCBkaXNhYmxlcyB0aGUgc2NoZWR1bGVyDQo+IGFuZCB0aGVuIGRpc2FibGVzIG5vbi1ib290IENQ
VXMuDQo+DQo+IEhvc3Qtc2lkZSBzdXNwZW5kIHBhcnRpY2lwYW50cyBhcmUgaGFuZGxlZCBpbiBw
aGFzZXMuIElPTU1VIGFuZCBjb25zb2xlDQo+IHN0YXRlIGFyZSBzdXNwZW5kZWQgZmlyc3QuIExv
Y2FsIElSUXMgYXJlIHRoZW4gZGlzYWJsZWQgYmVmb3JlIHN1c3BlbmRpbmcNCj4gdGltZXIgYW5k
IEdJQyBzdGF0ZS4gT24gcmVzdW1lIG9yIGZhaWx1cmUsIHRoZSBjb21wbGV0ZWQgc3VzcGVuZCBw
aGFzZXMNCj4gYXJlIHVud291bmQgaW4gcmV2ZXJzZTogR0lDIGFuZCB0aW1lciBzdGF0ZSBhcmUg
cmVzdG9yZWQgd2hpbGUgSVJRcyBhcmUNCj4gc3RpbGwgZGlzYWJsZWQsIGxvY2FsIElSUXMgYXJl
IHJlc3RvcmVkLCBhbmQgdGhlbiBjb25zb2xlIGFuZCBJT01NVSBzdGF0ZQ0KPiBhcmUgcmVzdG9y
ZWQuDQo+DQo+IE9uIGJvb3QsIGluaXRfdHRiciBpcyBub3JtYWxseSBpbml0aWFsaXplZCBkdXJp
bmcgc2Vjb25kYXJ5IENQVSBob3RwbHVnLg0KPiBPbiB1bmlwcm9jZXNzb3Igc3lzdGVtcyB0aGlz
IGNhbiBsZWF2ZSBpbml0X3R0YnIgdW5pbml0aWFsaXplZCwgc28gc2V0IGl0DQo+IGZyb20gdGhl
IGJvb3QgQ1BVIGJlZm9yZSBlbnRlcmluZyBzdXNwZW5kLg0KPg0KPiBOb3RlOiB0aGUgY29kZSBp
cyBiZWhpbmQgQ09ORklHX0hBU19TWVNURU1fU1VTUEVORCwgd2hpY2ggaXMgY3VycmVudGx5DQo+
IG9ubHkgc2VsZWN0ZWQgd2hlbiBVTlNVUFBPUlRFRCBpcyBzZXQgYW5kIE1QVSBpcyBub3Qgc2V0
Lg0KPg0KPiBTaWduZWQtb2ZmLWJ5OiBNaXJlbGEgU2ltb25vdmljIDxtaXJlbGEuc2ltb25vdmlj
QGFnZ2lvcy5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IFNhZWVkIE5vd3NoYWRpIDxzYWVlZC5ub3dz
aGFkaUB4aWxpbnguY29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRh
X3BvdHVyYWlAZXBhbS5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IE15a29sYSBLdmFjaCA8bXlrb2xh
X2t2YWNoQGVwYW0uY29tPg0KDQpSZXZpZXdlZC1ieTogVm9sb2R5bXlyIEJhYmNodWsgPHZvbG9k
eW15cl9iYWJjaHVrQGVwYW0uY29tPg0KDQo+IC0tLQ0KPiBDaGFuZ2VzIGluIFYxMDoNCj4gLSBS
ZS1hcHBseSBib290IENQVSBsb2NhbCBlcnJhdGEvd29ya2Fyb3VuZCBoYW5kbGluZyBhZnRlciBT
WVNURU1fU1VTUEVORCwNCj4gICBiZWZvcmUgcmVzdW1pbmcgdGhlIHJlc3Qgb2YgdGhlIGhvc3Qg
c3VzcGVuZCBwYXRoLg0KPiAtIE1vdmUgc2V0X2luaXRfdHRicigpIGRlY2xhcmF0aW9uIHRvIGFz
bS9tbXUvbW0uaCwgc2luY2UgaXQgaXMNCj4gICBNTVUtc3BlY2lmaWMuDQo+DQo+IENoYW5nZXMg
aW4gVjk6DQo+IC0gU3BsaXQgdlBTQ0kgYXZhaWxhYmlsaXR5IHBvbGljeSwgcnVudGltZSBob3N0
LXN1c3BlbmQgYmxvY2tlcnMgYW5kIHRoZQ0KPiAgIGRvbWFpbi1yZWFkaW5lc3MgcHJlY2hlY2sg
aW50byB0aGUgcHJlY2VkaW5nIGNvbW1pdC4NCj4gLSBUcmlnZ2VyIHRoZSBob3N0IHN1c3BlbmQg
YmFja2VuZCBmcm9tIHRoZSBjb250cm9sLWRvbWFpbiBTWVNURU1fU1VTUEVORA0KPiAgIHBhdGgu
DQo+IC0gUmVvcmRlciB0aGUgaG9zdCBzdXNwZW5kL3Jlc3VtZSBwaGFzZXMgc28gdGhlIHRpbWVy
IGlzIHN1c3BlbmRlZCB3aXRoDQo+ICAgbG9jYWwgSVJRcyBkaXNhYmxlZCBhbmQgbG9jYWwgSVJR
cyBhcmUgcmVzdG9yZWQgYWZ0ZXIgdGhlIEdJQyBhbmQgdGltZXINCj4gICByZXN1bWUgcGF0aHMs
IGJlZm9yZSB0aGUgY29uc29sZSBhbmQgSU9NTVUgcmVzdW1lIHBhdGhzLg0KPiAtIE1vdmUgSEFT
X0hXRE9NX1NZU1RFTV9TVVNQRU5EIGFuZCByZWxhdGVkIGxvZ2ljIHRvIHBvbGljeSBwYXRjaC4N
Cj4NCj4gQ2hhbmdlcyBpbiBWODoNCj4gLSBBZGQgYSBwcmUtc3VzcGVuZCBjaGVjayBpbiBzeXN0
ZW1fc3VzcGVuZCgpIGFmdGVyIHNjaGVkdWxlcl9kaXNhYmxlKCkgdG8NCj4gICByZXF1aXJlIGFs
bCBkb21haW5zIHRvIGJlIGluIHRoZSBzaHV0IGRvd24gc3RhdGUgd2l0aCBTSFVURE9XTl9zdXNw
ZW5kDQo+ICAgYmVmb3JlIHByb2NlZWRpbmcgd2l0aCB0aGUgZ2xvYmFsIHN1c3BlbmQgZmxvdy4N
Cj4gLSBEcm9wIHRoZSBjb21tb24tbGV2ZWwgZGVwZW5kcyBvbiAhQVJNXzY0IHx8ICFTWVNURU1f
U1VTUEVORCBmcm9tDQo+ICAgQ09ORklHX0hBU19IV0RPTV9TSFVURE9XTl9PTl9TVVNQRU5EIGFu
ZCBtb2RlbCB0aGUgQVJNNjQgc3VzcGVuZCBjYXNlDQo+ICAgd2l0aCBhbiBhcmNoLXNlbGVjdGVk
IGNhcGFiaWxpdHkgaW5zdGVhZC4NCj4gLSBSZW5hbWUgQ09ORklHX0hBU19IV0RPTV9TSFVURE9X
Tl9PTl9TVVNQRU5EIHRvDQo+ICAgQ09ORklHX0hBU19IV0RPTV9TWVNURU1fU1VTUEVORC4NCj4g
LSBSZW5hbWUgbmVlZF9od2RvbV9zaHV0ZG93bigpIHRvIHdhbnRfaHdkb21fc2h1dGRvd24oKS4N
Cj4NCj4gQ2hhbmdlcyBpbiBWNzoNCj4gLSBDb250cm9sIGRvbWFpbiBpcyByZXNwb25zaWJsZSBm
b3IgaG9zdCBzdXNwZW5kLg0KPiAtIEFkZCBhbiBlbXB0eSBpbmxpbmUgaG9zdF9zeXN0ZW1fc3Vz
cGVuZCgpIGZ1bmN0aW9uIHdoZW4gU1lTVEVNX1NVU1BFTkQNCj4gICBjb25maWcgaXMgZGlzYWJs
ZWQuDQo+IC0gVXNlIElTX0VOQUJMRUQoKSBmb3IgY29uZmlnIGNoZWNraW5nIGluc3RlYWQgb2Yg
I2lmZGVmLg0KPiAtIFJlcGxhY2UgI2lmZGVmIGNoZWNrcyBpbiBkb21haW5fc2h1dGRvd24oKSB3
aXRoIElTX0VOQUJMRUQoKSB0byBzaW1wbGlmeQ0KPiAgIGNvbnRyb2wgZmxvdy4NCj4gLSBGYWN0
b3IgaGFyZHdhcmUgZG9tYWluIHNodXRkb3duIGNvbmRpdGlvbiBpbnRvIGEgaGVscGVyDQo+ICAg
KG5lZWRfaHdkb21fc2h1dGRvd24oKSkgdG8gYXZvaWQgcHJlcHJvY2Vzc29yIGRpcmVjdGl2ZXMg
aW5zaWRlIHRoZQ0KPiAgIGZ1bmN0aW9uLg0KPiAtIFNxdWFzaCB3aXRoIGlvbW11IHN1c3BlbmQv
cmVzdW1lIGNvbW1pdC4NCj4gLS0tDQo+ICB4ZW4vYXJjaC9hcm0vS2NvbmZpZyAgICAgICAgICAg
ICAgICAgfCAgIDEgKw0KPiAgeGVuL2FyY2gvYXJtL2NwdWVycmF0YS5jICAgICAgICAgICAgIHwg
ICA3ICstDQo+ICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vY3B1ZXJyYXRhLmggfCAgIDEgKw0K
PiAgeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21tdS9tbS5oICAgIHwgICAyICsNCj4gIHhlbi9h
cmNoL2FybS9pbmNsdWRlL2FzbS9zdXNwZW5kLmggICB8ICAgMiArDQo+ICB4ZW4vYXJjaC9hcm0v
bW11L3NtcGJvb3QuYyAgICAgICAgICAgfCAgIDIgKy0NCj4gIHhlbi9hcmNoL2FybS9zdXNwZW5k
LmMgICAgICAgICAgICAgICB8IDE1NiArKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gIHhl
bi9hcmNoL2FybS92cHNjaS5jICAgICAgICAgICAgICAgICB8ICAxMCArLQ0KPiAgOCBmaWxlcyBj
aGFuZ2VkLCAxNzcgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkNCj4NCj4gZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL2FybS9LY29uZmlnIGIveGVuL2FyY2gvYXJtL0tjb25maWcNCj4gaW5kZXgg
OTAyN2FhMTdlYi4uZGExNTg1ZWM1MCAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gvYXJtL0tjb25m
aWcNCj4gKysrIGIveGVuL2FyY2gvYXJtL0tjb25maWcNCj4gQEAgLTksNiArOSw3IEBAIGNvbmZp
ZyBBUk1fNjQNCj4gIAlzZWxlY3QgNjRCSVQNCj4gIAlzZWxlY3QgSEFTX0RPTUFJTl9UWVBFDQo+
ICAJc2VsZWN0IEhBU19GQVNUX01VTFRJUExZDQo+ICsJc2VsZWN0IEhBU19TWVNURU1fU1VTUEVO
RCBpZiAhTVBVICYmIFVOU1VQUE9SVEVEDQo+ICAJc2VsZWN0IEhBU19WUENJX0dVRVNUX1NVUFBP
UlQgaWYgUENJX1BBU1NUSFJPVUdIDQo+ICANCj4gIGNvbmZpZyBBUk0NCj4gZGlmZiAtLWdpdCBh
L3hlbi9hcmNoL2FybS9jcHVlcnJhdGEuYyBiL3hlbi9hcmNoL2FybS9jcHVlcnJhdGEuYw0KPiBp
bmRleCAzYTMyMTgzNjE4Li5lNjQ5OWFhYWIzIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0v
Y3B1ZXJyYXRhLmMNCj4gKysrIGIveGVuL2FyY2gvYXJtL2NwdWVycmF0YS5jDQo+IEBAIC03ODIs
NiArNzgyLDExIEBAIHZvaWQgY2hlY2tfbG9jYWxfY3B1X2VycmF0YSh2b2lkKQ0KPiAgICAgIHVw
ZGF0ZV9jcHVfY2FwYWJpbGl0aWVzKGFybV9lcnJhdGEsICJlbmFibGVkIHdvcmthcm91bmQgZm9y
Iik7DQo+ICB9DQo+ICANCj4gK2ludCBlbmFibGVfbG9jYWxfY3B1X2VycmF0YV93b3JrYXJvdW5k
cyh2b2lkKQ0KPiArew0KPiArICAgIHJldHVybiBlbmFibGVfbm9uYm9vdF9jcHVfY2Fwcyhhcm1f
ZXJyYXRhKTsNCj4gK30NCj4gKw0KPiAgdm9pZCBfX2luaXQgZW5hYmxlX2VycmF0YV93b3JrYXJv
dW5kcyh2b2lkKQ0KPiAgew0KPiAgICAgIGVuYWJsZV9jcHVfY2FwYWJpbGl0aWVzKGFybV9lcnJh
dGEpOw0KPiBAQCAtODE4LDcgKzgyMyw3IEBAIHN0YXRpYyBpbnQgY3B1X2VycmF0YV9jYWxsYmFj
ayhzdHJ1Y3Qgbm90aWZpZXJfYmxvY2sgKm5mYiwNCj4gICAgICAgICAgICogZml4ZWQgdG8gZXhw
ZWN0IGFuIGVycm9yIGF0IENQVV9TVEFSVElORyBwaGFzZS4NCj4gICAgICAgICAgICovDQo+ICAg
ICAgICAgIEFTU0VSVChzeXN0ZW1fc3RhdGUgIT0gU1lTX1NUQVRFX2Jvb3QpOw0KPiAtICAgICAg
ICByYyA9IGVuYWJsZV9ub25ib290X2NwdV9jYXBzKGFybV9lcnJhdGEpOw0KPiArICAgICAgICBy
YyA9IGVuYWJsZV9sb2NhbF9jcHVfZXJyYXRhX3dvcmthcm91bmRzKCk7DQo+ICAgICAgICAgIGJy
ZWFrOw0KPiAgICAgIGRlZmF1bHQ6DQo+ICAgICAgICAgIGJyZWFrOw0KPiBkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2NwdWVycmF0YS5oIGIveGVuL2FyY2gvYXJtL2luY2x1
ZGUvYXNtL2NwdWVycmF0YS5oDQo+IGluZGV4IDE3OTlhMTZkN2UuLmI5MzUyMTMyNmYgMTAwNjQ0
DQo+IC0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9jcHVlcnJhdGEuaA0KPiArKysgYi94
ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vY3B1ZXJyYXRhLmgNCj4gQEAgLTUsNiArNSw3IEBADQo+
ICAjaW5jbHVkZSA8YXNtL2FsdGVybmF0aXZlLmg+DQo+ICANCj4gIHZvaWQgY2hlY2tfbG9jYWxf
Y3B1X2VycmF0YSh2b2lkKTsNCj4gK2ludCBlbmFibGVfbG9jYWxfY3B1X2VycmF0YV93b3JrYXJv
dW5kcyh2b2lkKTsNCj4gIHZvaWQgZW5hYmxlX2VycmF0YV93b3JrYXJvdW5kcyh2b2lkKTsNCj4g
IA0KPiAgI2RlZmluZSBDSEVDS19XT1JLQVJPVU5EX0hFTFBFUihlcnJhdHVtLCBmZWF0dXJlLCBh
cmNoKSAgICAgICAgIFwNCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9t
bXUvbW0uaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9tbXUvbW0uaA0KPiBpbmRleCA3ZjRk
NTkxMzdkLi5lZTczYTc3Nzc3IDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h
c20vbW11L21tLmgNCj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL21tdS9tbS5oDQo+
IEBAIC0xMTAsNiArMTEwLDggQEAgdm9pZCBkdW1wX3B0X3dhbGsocGFkZHJfdCB0dGJyLCBwYWRk
cl90IGFkZHIsDQo+ICBleHRlcm4gdm9pZCBzd2l0Y2hfdHRicih1aW50NjRfdCB0dGJyKTsNCj4g
IGV4dGVybiB2b2lkIHJlbG9jYXRlX2FuZF9zd2l0Y2hfdHRicih1aW50NjRfdCB0dGJyKTsNCj4g
IA0KPiArdm9pZCBzZXRfaW5pdF90dGJyKGxwYWVfdCAqcm9vdCk7DQo+ICsNCj4gICNlbmRpZiAv
KiBfX0FSTV9NTVVfTU1fSF9fICovDQo+ICANCj4gIC8qDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJj
aC9hcm0vaW5jbHVkZS9hc20vc3VzcGVuZC5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL3N1
c3BlbmQuaA0KPiBpbmRleCA1MGRjNmU5ZmRmLi44ODlhNjUwOWQ5IDEwMDY0NA0KPiAtLS0gYS94
ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vc3VzcGVuZC5oDQo+ICsrKyBiL3hlbi9hcmNoL2FybS9p
bmNsdWRlL2FzbS9zdXNwZW5kLmgNCj4gQEAgLTQxLDExICs0MSwxMyBAQCBpbnQgcHJlcGFyZV9y
ZXN1bWVfY3R4KHZvaWQpOw0KPiAgdm9pZCBoeXBfcmVzdW1lKHZvaWQpOw0KPiAgYm9vbCBob3N0
X3N5c3RlbV9zdXNwZW5kX2FsbG93ZWQodm9pZCk7DQo+ICB2b2lkIGhvc3Rfc3lzdGVtX3N1c3Bl
bmRfZGlzYWJsZShjb25zdCBjaGFyICpyZWFzb24pOw0KPiArdm9pZCBob3N0X3N5c3RlbV9zdXNw
ZW5kKHN0cnVjdCBkb21haW4gKmQpOw0KPiAgDQo+ICAjZWxzZSAvKiAhQ09ORklHX1NZU1RFTV9T
VVNQRU5EICovDQo+ICANCj4gIHN0YXRpYyBpbmxpbmUgYm9vbCBob3N0X3N5c3RlbV9zdXNwZW5k
X2FsbG93ZWQodm9pZCkgeyByZXR1cm4gZmFsc2U7IH0NCj4gIHN0YXRpYyBpbmxpbmUgdm9pZCBo
b3N0X3N5c3RlbV9zdXNwZW5kX2Rpc2FibGUoY29uc3QgY2hhciAqcmVhc29uKSB7fQ0KPiArc3Rh
dGljIGlubGluZSB2b2lkIGhvc3Rfc3lzdGVtX3N1c3BlbmQoc3RydWN0IGRvbWFpbiAqZCkge30N
Cj4gIA0KPiAgI2VuZGlmDQo+ICANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9tbXUvc21w
Ym9vdC5jIGIveGVuL2FyY2gvYXJtL21tdS9zbXBib290LmMNCj4gaW5kZXggMzdlOTFkNzJiNy4u
ZmY1MDhlY2Y0MCAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gvYXJtL21tdS9zbXBib290LmMNCj4g
KysrIGIveGVuL2FyY2gvYXJtL21tdS9zbXBib290LmMNCj4gQEAgLTcyLDcgKzcyLDcgQEAgc3Rh
dGljIHZvaWQgY2xlYXJfYm9vdF9wYWdldGFibGVzKHZvaWQpDQo+ICAgICAgY2xlYXJfdGFibGUo
Ym9vdF90aGlyZCk7DQo+ICB9DQo+ICANCj4gLXN0YXRpYyB2b2lkIHNldF9pbml0X3R0YnIobHBh
ZV90ICpyb290KQ0KPiArdm9pZCBzZXRfaW5pdF90dGJyKGxwYWVfdCAqcm9vdCkNCj4gIHsNCj4g
ICAgICAvKg0KPiAgICAgICAqIGluaXRfdHRiciBpcyBwYXJ0IG9mIHRoZSBpZGVudGl0eSBtYXBw
aW5nIHdoaWNoIGlzIHJlYWQtb25seS4gU28NCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9z
dXNwZW5kLmMgYi94ZW4vYXJjaC9hcm0vc3VzcGVuZC5jDQo+IGluZGV4IGM3YzI2YmNmMDMuLjNm
ZTJmZmE0ZmIgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL2FybS9zdXNwZW5kLmMNCj4gKysrIGIv
eGVuL2FyY2gvYXJtL3N1c3BlbmQuYw0KPiBAQCAtMSwxMCArMSwxOCBAQA0KPiAgLyogU1BEWC1M
aWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPiAgDQo+ICsjaW5jbHVkZSA8YXNt
L2NwdWVycmF0YS5oPg0KPiArI2luY2x1ZGUgPGFzbS9jcHVmZWF0dXJlLmg+DQo+ICsjaW5jbHVk
ZSA8YXNtL2dpYy5oPg0KPiAgI2luY2x1ZGUgPGFzbS9wc2NpLmg+DQo+ICAjaW5jbHVkZSA8YXNt
L3N1c3BlbmQuaD4NCj4gIA0KPiArI2luY2x1ZGUgPHhlbi9jb25zb2xlLmg+DQo+ICsjaW5jbHVk
ZSA8eGVuL2NwdS5oPg0KPiArI2luY2x1ZGUgPHhlbi9pb21tdS5oPg0KPiAgI2luY2x1ZGUgPHhl
bi9saWIuaD4NCj4gKyNpbmNsdWRlIDx4ZW4vc2NoZWQuaD4NCj4gICNpbmNsdWRlIDx4ZW4vc2Vy
aWFsLmg+DQo+ICsjaW5jbHVkZSA8eGVuL3Rhc2tsZXQuaD4NCj4gIA0KPiAgc3RydWN0IHJlc3Vt
ZV9jcHVfY29udGV4dCByZXN1bWVfY3B1X2NvbnRleHQ7DQo+ICANCj4gQEAgLTQ0LDYgKzUyLDE1
NCBAQCB2b2lkIGhvc3Rfc3lzdGVtX3N1c3BlbmRfZGlzYWJsZShjb25zdCBjaGFyICpyZWFzb24p
DQo+ICAgICAgICAgICAgIHJlYXNvbiA/IHJlYXNvbiA6ICJ1bnN1cHBvcnRlZCBzdXNwZW5kL3Jl
c3VtZSBwYXRoIik7DQo+ICB9DQo+ICANCj4gKy8qIFhlbiBzdXNwZW5kLiBkYXRhIGlkZW50aWZp
ZXMgdGhlIGRvbWFpbiB0aGF0IGluaXRpYXRlZCBzdXNwZW5kLiAqLw0KPiArc3RhdGljIHZvaWQg
c3lzdGVtX3N1c3BlbmQodm9pZCAqZGF0YSkNCj4gK3sNCj4gKyAgICBpbnQgc3RhdHVzOw0KPiAr
ICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQo+ICsgICAgc3RydWN0IGRvbWFpbiAqZCA9IChzdHJ1
Y3QgZG9tYWluICopZGF0YTsNCj4gKw0KPiArICAgIEJVR19PTihzeXN0ZW1fc3RhdGUgIT0gU1lT
X1NUQVRFX2FjdGl2ZSk7DQo+ICsNCj4gKyAgICBzeXN0ZW1fc3RhdGUgPSBTWVNfU1RBVEVfc3Vz
cGVuZDsNCj4gKw0KPiArICAgIHByaW50aygiWGVuIHN1c3BlbmRpbmcuLi5cbiIpOw0KPiArDQo+
ICsgICAgZnJlZXplX2RvbWFpbnMoKTsNCj4gKyAgICBzY2hlZHVsZXJfZGlzYWJsZSgpOw0KPiAr
DQo+ICsgICAgLyoNCj4gKyAgICAgKiBOb24tYm9vdCBDUFVzIGhhdmUgdG8gYmUgZGlzYWJsZWQg
b24gc3VzcGVuZCBhbmQgZW5hYmxlZCBvbiByZXN1bWUNCj4gKyAgICAgKiAoaG90cGx1Zy1iYXNl
ZCBtZWNoYW5pc20pLiBEaXNhYmxpbmcgbm9uLWJvb3QgQ1BVcyB3aWxsIGxlYWQgdG8gUFNDSQ0K
PiArICAgICAqIENQVV9PRkYgdG8gYmUgY2FsbGVkIGJ5IGVhY2ggbm9uLWJvb3QgQ1BVLiBEZXBl
bmRpbmcgb24gdGhlIHVuZGVybHlpbmcNCj4gKyAgICAgKiBwbGF0Zm9ybSBjYXBhYmlsaXRpZXMs
IHRoaXMgbWF5IGxlYWQgdG8gdGhlIHBoeXNpY2FsIHBvd2VyaW5nIGRvd24gb2YNCj4gKyAgICAg
KiBDUFVzLg0KPiArICAgICAqLw0KPiArICAgIHN0YXR1cyA9IGRpc2FibGVfbm9uYm9vdF9jcHVz
KCk7DQo+ICsgICAgaWYgKCBzdGF0dXMgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgc3lzdGVtX3N0
YXRlID0gU1lTX1NUQVRFX3Jlc3VtZTsNCj4gKyAgICAgICAgZ290byByZXN1bWVfbm9uYm9vdF9j
cHVzOw0KPiArICAgIH0NCj4gKw0KPiArICAgIGNvbnNvbGVfc3RhcnRfc3luYygpOw0KPiArICAg
IHN0YXR1cyA9IGlvbW11X3N1c3BlbmQoKTsNCj4gKyAgICBpZiAoIHN0YXR1cyApDQo+ICsgICAg
ew0KPiArICAgICAgICBzeXN0ZW1fc3RhdGUgPSBTWVNfU1RBVEVfcmVzdW1lOw0KPiArICAgICAg
ICBnb3RvIHJlc3VtZV9lbmRfc3luYzsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBzdGF0dXMgPSBj
b25zb2xlX3N1c3BlbmQoKTsNCj4gKyAgICBpZiAoIHN0YXR1cyApDQo+ICsgICAgew0KPiArICAg
ICAgICBkcHJpbnRrKFhFTkxPR19FUlIsICJGYWlsZWQgdG8gc3VzcGVuZCB0aGUgY29uc29sZSwg
ZXJyPSVkXG4iLCBzdGF0dXMpOw0KPiArICAgICAgICBzeXN0ZW1fc3RhdGUgPSBTWVNfU1RBVEVf
cmVzdW1lOw0KPiArICAgICAgICBnb3RvIHJlc3VtZV9pb21tdTsNCj4gKyAgICB9DQo+ICsNCj4g
KyAgICBsb2NhbF9pcnFfc2F2ZShmbGFncyk7DQo+ICsNCj4gKyAgICB0aW1lX3N1c3BlbmQoKTsN
Cj4gKw0KPiArICAgIHN0YXR1cyA9IGdpY19zdXNwZW5kKCk7DQo+ICsgICAgaWYgKCBzdGF0dXMg
KQ0KPiArICAgIHsNCj4gKyAgICAgICAgc3lzdGVtX3N0YXRlID0gU1lTX1NUQVRFX3Jlc3VtZTsN
Cj4gKyAgICAgICAgZ290byByZXN1bWVfdGltZTsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBzZXRf
aW5pdF90dGJyKHhlbl9wZ3RhYmxlKTsNCj4gKw0KPiArICAgIC8qDQo+ICsgICAgICogRW5hYmxl
IGlkZW50aXR5IG1hcHBpbmcgYmVmb3JlIGVudGVyaW5nIHN1c3BlbmQgdG8gc2ltcGxpZnkNCj4g
KyAgICAgKiB0aGUgcmVzdW1lIHBhdGgNCj4gKyAgICAgKi8NCj4gKyAgICB1cGRhdGVfYm9vdF9t
YXBwaW5nKHRydWUpOw0KPiArDQo+ICsgICAgaWYgKCBwcmVwYXJlX3Jlc3VtZV9jdHgoKSApDQo+
ICsgICAgew0KPiArICAgICAgICBzdGF0dXMgPSBjYWxsX3BzY2lfc3lzdGVtX3N1c3BlbmQoKTsN
Cj4gKyAgICAgICAgLyoNCj4gKyAgICAgICAgICogSWYgc3VzcGVuZCBpcyBmaW5hbGl6ZWQgcHJv
cGVybHkgYnkgYWJvdmUgc3lzdGVtIHN1c3BlbmQgUFNDSSBjYWxsLA0KPiArICAgICAgICAgKiB0
aGUgY29kZSBiZWxvdyBpbiB0aGlzICdpZicgYnJhbmNoIHdpbGwgbmV2ZXIgZXhlY3V0ZS4gRXhl
Y3V0aW9uDQo+ICsgICAgICAgICAqIHdpbGwgY29udGludWUgZnJvbSBoeXBfcmVzdW1lIHdoaWNo
IGlzIHRoZSBoeXBlcnZpc29yJ3MgcmVzdW1lIHBvaW50Lg0KPiArICAgICAgICAgKiBJbiBoeXBf
cmVzdW1lIENQVSBjb250ZXh0IHdpbGwgYmUgcmVzdG9yZWQgYW5kIHNpbmNlIGxpbmstcmVnaXN0
ZXIgaXMNCj4gKyAgICAgICAgICogcmVzdG9yZWQgYXMgd2VsbCwgaXQgd2lsbCBhcHBlYXIgdG8g
cmV0dXJuIGZyb20gcHJlcGFyZV9yZXN1bWVfY3R4Lg0KPiArICAgICAgICAgKiBUaGUgZGlmZmVy
ZW5jZSBpbiByZXR1cm5pbmcgZnJvbSBwcmVwYXJlX3Jlc3VtZV9jdHggb24gc3lzdGVtIHN1c3Bl
bmQNCj4gKyAgICAgICAgICogdmVyc3VzIHJlc3VtZSBpcyBpbiBmdW5jdGlvbidzIHJldHVybiB2
YWx1ZTogb24gc3VzcGVuZCwgdGhlIHJldHVybg0KPiArICAgICAgICAgKiB2YWx1ZSBpcyBhIG5v
bi16ZXJvIHZhbHVlLCBvbiByZXN1bWUgaXQgaXMgemVyby4gVGhhdCBpcyB3aHkgdGhlDQo+ICsg
ICAgICAgICAqIGNvbnRyb2wgZmxvdyB3aWxsIG5vdCByZS1lbnRlciB0aGlzICdpZicgYnJhbmNo
IG9uIHJlc3VtZS4NCj4gKyAgICAgICAgICovDQo+ICsgICAgICAgIGlmICggc3RhdHVzICkNCj4g
KyAgICAgICAgICAgIGRwcmludGsoWEVOTE9HX1dBUk5JTkcsICJQU0NJIHN5c3RlbSBzdXNwZW5k
IGZhaWxlZCwgZXJyPSVkXG4iLA0KPiArICAgICAgICAgICAgICAgICAgICBzdGF0dXMpOw0KPiAr
DQo+ICsgICAgICAgIHN5c3RlbV9zdGF0ZSA9IFNZU19TVEFURV9yZXN1bWU7DQo+ICsgICAgfQ0K
PiArICAgIGVsc2UNCj4gKyAgICB7DQo+ICsgICAgICAgIHN5c3RlbV9zdGF0ZSA9IFNZU19TVEFU
RV9yZXN1bWU7DQo+ICsNCj4gKyAgICAgICAgLyoNCj4gKyAgICAgICAgICogQ1BVMCByZXN1bWVz
IGRpcmVjdGx5IGZyb20gaHlwX3Jlc3VtZSgpLCBieXBhc3NpbmcgdGhlIENQVSBob3RwbHVnDQo+
ICsgICAgICAgICAqIHBhdGggdGhhdCByZS1jaGVja3MgYW5kIHJlLWVuYWJsZXMgZXJyYXRhIHdv
cmthcm91bmRzIGZvciBzZWNvbmRhcnkNCj4gKyAgICAgICAgICogQ1BVcy4NCj4gKyAgICAgICAg
ICovDQo+ICsgICAgICAgIGNoZWNrX2xvY2FsX2NwdV9lcnJhdGEoKTsNCj4gKyAgICAgICAgY2hl
Y2tfbG9jYWxfY3B1X2ZlYXR1cmVzKCk7DQo+ICsgICAgICAgIEJVR19PTihlbmFibGVfbG9jYWxf
Y3B1X2VycmF0YV93b3JrYXJvdW5kcygpKTsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICB1cGRhdGVf
Ym9vdF9tYXBwaW5nKGZhbHNlKTsNCj4gKw0KPiArICAgIGdpY19yZXN1bWUoKTsNCj4gKw0KPiAr
IHJlc3VtZV90aW1lOg0KPiArICAgIHRpbWVfcmVzdW1lKCk7DQo+ICsNCj4gKyAgICBsb2NhbF9p
cnFfcmVzdG9yZShmbGFncyk7DQo+ICsNCj4gKyAgICBjb25zb2xlX3Jlc3VtZSgpOw0KPiArDQo+
ICsgcmVzdW1lX2lvbW11Og0KPiArICAgIGlvbW11X3Jlc3VtZSgpOw0KPiArDQo+ICsgcmVzdW1l
X2VuZF9zeW5jOg0KPiArICAgIGNvbnNvbGVfZW5kX3N5bmMoKTsNCj4gKw0KPiArIHJlc3VtZV9u
b25ib290X2NwdXM6DQo+ICsgICAgLyoNCj4gKyAgICAgKiBUaGUgcmN1X2JhcnJpZXIoKSBoYXMg
dG8gYmUgYWRkZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHBlciBjcHUgYXJlYSBpcw0KPiArICAgICAq
IGZyZWVkIGJlZm9yZSBhIG5vbi1ib290IENQVSB0cmllcyB0byBpbml0aWFsaXplIGl0IChfZnJl
ZV9wZXJjcHVfYXJlYSgpDQo+ICsgICAgICogaGFzIHRvIGJlIGNhbGxlZCBiZWZvcmUgdGhlIGlu
aXRfcGVyY3B1X2FyZWEoKSkuIFRoaXMgc2NlbmFyaW8gb2NjdXJzDQo+ICsgICAgICogd2hlbiBu
b24tYm9vdCBDUFVzIGFyZSBob3QtdW5wbHVnZ2VkIG9uIHN1c3BlbmQgYW5kIGhvdHBsdWdnZWQg
b24gcmVzdW1lLg0KPiArICAgICAqLw0KPiArICAgIHJjdV9iYXJyaWVyKCk7DQo+ICsgICAgZW5h
YmxlX25vbmJvb3RfY3B1cygpOw0KPiArDQo+ICsgICAgc2NoZWR1bGVyX2VuYWJsZSgpOw0KPiAr
ICAgIHRoYXdfZG9tYWlucygpOw0KPiArDQo+ICsgICAgc3lzdGVtX3N0YXRlID0gU1lTX1NUQVRF
X2FjdGl2ZTsNCj4gKw0KPiArICAgIHByaW50aygiUmVzdW1lIChzdGF0dXMgJWQpXG4iLCBzdGF0
dXMpOw0KPiArDQo+ICsgICAgZG9tYWluX3Jlc3VtZShkKTsNCj4gK30NCj4gKw0KPiArc3RhdGlj
IERFQ0xBUkVfVEFTS0xFVChzeXN0ZW1fc3VzcGVuZF90YXNrbGV0LCBzeXN0ZW1fc3VzcGVuZCwg
TlVMTCk7DQo+ICsNCj4gK3ZvaWQgaG9zdF9zeXN0ZW1fc3VzcGVuZChzdHJ1Y3QgZG9tYWluICpk
KQ0KPiArew0KPiArICAgIHN5c3RlbV9zdXNwZW5kX3Rhc2tsZXQuZGF0YSA9ICh2b2lkICopZDsN
Cj4gKyAgICAvKg0KPiArICAgICAqIFRoZSBzdXNwZW5kIHByb2NlZHVyZSBoYXMgdG8gYmUgZmlu
YWxpemVkIGJ5IHRoZSBwQ1BVIzAgKG5vbi1ib290IHBDUFVzDQo+ICsgICAgICogd2lsbCBiZSBk
aXNhYmxlZCBkdXJpbmcgdGhlIHN1c3BlbmQpLg0KPiArICAgICAqLw0KPiArICAgIHRhc2tsZXRf
c2NoZWR1bGVfb25fY3B1KCZzeXN0ZW1fc3VzcGVuZF90YXNrbGV0LCAwKTsNCj4gK30NCj4gKw0K
PiAgLyoNCj4gICAqIExvY2FsIHZhcmlhYmxlczoNCj4gICAqIG1vZGU6IEMNCj4gZGlmZiAtLWdp
dCBhL3hlbi9hcmNoL2FybS92cHNjaS5jIGIveGVuL2FyY2gvYXJtL3Zwc2NpLmMNCj4gaW5kZXgg
YTQxMzU1ZDc1ZC4uNTEzNGU3NWMyNCAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gvYXJtL3Zwc2Np
LmMNCj4gKysrIGIveGVuL2FyY2gvYXJtL3Zwc2NpLmMNCj4gQEAgLTIzNyw3ICsyMzcsOCBAQCBz
dGF0aWMgYm9vbCBkb21haW5faW5fc3VzcGVuZF9zdGF0ZShzdHJ1Y3QgZG9tYWluICpkKQ0KPiAg
ICAgIHJldHVybiBzdXNwZW5kZWQ7DQo+ICB9DQo+ICANCj4gLXN0YXRpYyBpbnQzMl90IGRvbWFp
bl9wc2NpX3N5c3RlbV9zdXNwZW5kX3BvbGljeShzdHJ1Y3QgZG9tYWluICpkKQ0KPiArc3RhdGlj
IGludDMyX3QgZG9tYWluX3BzY2lfc3lzdGVtX3N1c3BlbmRfcG9saWN5KHN0cnVjdCBkb21haW4g
KmQsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Ym9vbCAqaG9zdF9zdXNwZW5kKQ0KPiAgew0KPiAgICAgIHN0cnVjdCBkb21haW4gKm90aGVyOw0K
PiAgICAgIGJvb2wgbGFzdF9hd2FrZV9jb250cm9sX2RvbWFpbiA9IHRydWU7DQo+IEBAIC0zMDAs
NiArMzAxLDcgQEAgc3RhdGljIGludDMyX3QgZG9tYWluX3BzY2lfc3lzdGVtX3N1c3BlbmRfcG9s
aWN5KHN0cnVjdCBkb21haW4gKmQpDQo+ICAgICAgaWYgKCAhaG9zdF9zeXN0ZW1fc3VzcGVuZF9h
bGxvd2VkKCkgKQ0KPiAgICAgICAgICByZXR1cm4gUFNDSV9ERU5JRUQ7DQo+ICANCj4gKyAgICAq
aG9zdF9zdXNwZW5kID0gdHJ1ZTsNCj4gICAgICByZXR1cm4gMDsNCj4gIH0NCj4gIA0KPiBAQCAt
MzEwLDYgKzMxMiw3IEBAIHN0YXRpYyBpbnQzMl90IGRvX3BzY2lfMV8wX3N5c3RlbV9zdXNwZW5k
KHJlZ2lzdGVyX3QgZXBvaW50LCByZWdpc3Rlcl90IGNpZCkNCj4gICAgICBzdHJ1Y3QgdmNwdSAq
djsNCj4gICAgICBzdHJ1Y3QgZG9tYWluICpkID0gY3VycmVudC0+ZG9tYWluOw0KPiAgICAgIGJv
b2wgaXNfdGh1bWIgPSBlcG9pbnQgJiAxOw0KPiArICAgIGJvb2wgaG9zdF9zdXNwZW5kID0gZmFs
c2U7DQo+ICAgICAgc3RydWN0IHJlc3VtZV9pbmZvICpyY3R4ID0gJmQtPmFyY2gucmVzdW1lX2N0
eDsNCj4gIA0KPiAgICAgIC8qIFRIVU1CIHNldCBpcyBub3QgYWxsb3dlZCB3aXRoIDY0LWJpdCBk
b21haW4gKi8NCj4gQEAgLTMzNCw3ICszMzcsNyBAQCBzdGF0aWMgaW50MzJfdCBkb19wc2NpXzFf
MF9zeXN0ZW1fc3VzcGVuZChyZWdpc3Rlcl90IGVwb2ludCwgcmVnaXN0ZXJfdCBjaWQpDQo+ICAN
Cj4gICAgICBzcGluX2xvY2soJnZwc2NpX3N5c3RlbV9zdXNwZW5kX2xvY2spOw0KPiAgDQo+IC0g
ICAgcmMgPSBkb21haW5fcHNjaV9zeXN0ZW1fc3VzcGVuZF9wb2xpY3koZCk7DQo+ICsgICAgcmMg
PSBkb21haW5fcHNjaV9zeXN0ZW1fc3VzcGVuZF9wb2xpY3koZCwgJmhvc3Rfc3VzcGVuZCk7DQo+
ICAgICAgaWYgKCAhcmMgKQ0KPiAgICAgIHsNCj4gICAgICAgICAgcmMgPSBkb21haW5fc2h1dGRv
d24oZCwgU0hVVERPV05fc3VzcGVuZCk7DQo+IEBAIC0zNTksNiArMzYyLDkgQEAgc3RhdGljIGlu
dDMyX3QgZG9fcHNjaV8xXzBfc3lzdGVtX3N1c3BlbmQocmVnaXN0ZXJfdCBlcG9pbnQsIHJlZ2lz
dGVyX3QgY2lkKQ0KPiAgICAgICAgICAgICAgIlNZU1RFTV9TVVNQRU5EIHJlcXVlc3RlZCwgZXBv
aW50PSUjIlBSSXJlZ2lzdGVyIiwgY2lkPSUjIlBSSXJlZ2lzdGVyIlxuIiwNCj4gICAgICAgICAg
ICAgIGVwb2ludCwgY2lkKTsNCj4gIA0KPiArICAgIGlmICggaG9zdF9zdXNwZW5kICkNCj4gKyAg
ICAgICAgaG9zdF9zeXN0ZW1fc3VzcGVuZChkKTsNCj4gKw0KPiAgICAgIHJldHVybiByYzsNCj4g
IH0NCg0KLS0gDQpXQlIsIFZvbG9keW15cg==


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 06:41:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 06:41:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401572.1637106 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqGr-0004fT-97; Fri, 28 Aug 2026 06:41:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401572.1637106; Fri, 28 Aug 2026 06:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqGr-0004fI-4J; Fri, 28 Aug 2026 06:41:01 +0000
Received: by outflank-mailman (input) for mailman id 1401572;
 Fri, 28 Aug 2026 06:41:00 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqGq-0004fC-K3
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 06:41:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqGp-00DTmp-AU
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:40:59 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a912d68-e002-0a2a0a5209dd-0a2a4508e600-32
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:40:58 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a912d7a-f659-0a2a45080019-d155dd31bd85-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:40:58 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-4798bea72f9so402299f8f.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 23:40:58 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbb34ae6sm1840867f8f.37.2026.08.27.23.40.57
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 23:40:57 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787899258; x=1788504058; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=PiaibNZfVIdPxinq1hhQJhOEXV92eSht5gWkix02knk=;
        b=LjbHgesBMSNT1jAUfeozUbWifbwgpBisOGOjFAW/4fNfeE3oZ9j0Kd7Tbb1gskIco/
         VpZ/4QyxA2RvRaH1hKemVIrXnpWhmS9/R6iqmG70JOWcYw1QSVNsCxK5w1pqdNinIrQi
         NONSSKUV1JJURbykKY5L9agnfk3Se/l32K9MmhH5qSYtiFMv1bHwLByiMTQqMefoinPL
         JllF713odY2+QekdEkWybCJG62bN0AyOJy/uEtGIfHMwcy6Ru6z78bEU1nayFeeZSZJf
         nQN7hOl4/rKstxNDz9O8Z7Y9HCwAfSIQbJdTJjqWC1ouV3Y2Y2i9l0fiIyWRyAtxTX6y
         JcQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787899258; x=1788504058;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=PiaibNZfVIdPxinq1hhQJhOEXV92eSht5gWkix02knk=;
        b=Tt/DNwXSdiYb0xk/uI/WS4/BXzupHphJMoQD7Mmhdb46t0YZGZ7RUnjp6bVOrnkepc
         hRLyM+jUD7XUOo0d3tN6YEs8S+hxnbFL630A1FdSfKZIV8b3gSCzQWVh07gEFLwNREkv
         oBixr/Hl1+5ACFKe4XMEwsQEFIixT983naBwL65PkXNoJ34kCdqxGdTmGtLsXYFlJ9pW
         vruUn3Bc+SgjBldqCGKEcwidddRvq1SHAeBOoqYC/hAydxW9GcnnuHOCKB49ffT4NKnk
         yv7ysgIB/UqRm0Kd6gtEkVQNQkwas6svQbabavkESbvLsim2MUKrofhnBZ76AJXD0wtf
         WDRQ==
X-Gm-Message-State: AFuF++mhtHqfnxldPsc4H4lmNATEYrTozwKFzB+Q9pLUWSD3qgo7pxEs
	1uRTt690KmAOQPeqgovVrNIzV6xzmt8Is0HuJeyNzj3s/mybR5+0sBumSuwDVSyJ3Q==
X-Gm-Gg: AR+sD11HB+pyprgqB3evv1fhNQalaAb5EgPVVNUcB2QQDo7jzAGhlahXuqnCPDyupQd
	AvYhiXL0kpGbbdAC+b7jl6FDkfTr0C4IHXgU/PhVZBqX7Kvq9erNUXO0WgkfR1IOlUKJgy6Mvx5
	43zGqlxauf7Spq7TbitECV2iU/ZOLLFEd2q0UyGYh/uhiPOD/t4jQPM7A+9FKq0LI9IOfHrVs5d
	nJNau1FAiqySSXuNYaew0sB7LJbHpaqKzoCDfwD6Qa8jYVr4ZFGF26MCJWD0Xnew+dTaMfRbOM3
	0FVKSlawoZwIfhgT6TwmbBP+ewz1uLT3PS6YPl/0PcbT3Fx3nwaquUFYelsqE1NhgE7SQynNYgY
	ZXer1zbbvpW0UaB4/QINprPvVAHUoyTuJV/ha99Ux2L7iPRqdQSw0feENlHoo7TU/ydIuExD9/+
	Va34hURZ1Ad2eA2gMDZRee7TamVfDzVsP7nKJNqVYFAeVaPvRls5KN9ms1HMotXBvc6AQbNZgor
	pWnWk6+rdvZsA12sf8BQRYjUtJTFq+oNOb8zgn+PC1p6d37s5npB2YL/DIhN974
X-Received: by 2002:a05:6000:24c6:b0:47f:4919:d5b2 with SMTP id ffacd0b85a97d-482f79870bemr5400345f8f.1.1787899258186;
        Thu, 27 Aug 2026 23:40:58 -0700 (PDT)
Message-ID: <1b680cd1-c086-4aa1-9a8c-f89d9743918e@suse.com>
Date: Fri, 28 Aug 2026 08:40:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/2] flask: add const qualifier to
 security_context_to_sid()
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
 <ee0ce49467ac1ee1cdd017323e70c8a865269f39.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <ee0ce49467ac1ee1cdd017323e70c8a865269f39.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787899258-D735D87B-973723B4/0/0
X-purgate-type: clean
X-purgate-size: 829

On 27.08.2026 11:38, Sergiy Kibrik wrote:
> --- a/xen/xsm/flask/include/security.h
> +++ b/xen/xsm/flask/include/security.h
> @@ -76,7 +76,7 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid);
>  
>  int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
>  
> -int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
> +int security_context_to_sid(const char *scontext, u32 scontext_len, u32 *out_sid);

I see Daniel has ack-ed this, but:
- The line is too long now.
- The last parameter name here doesn't match that of the definition.
- While touching code anyway, it would be nice if u<N> was converted to
  uint<N>_t (or else we'll never complete that conversion).
I think I'll take the liberty of addressing all of these while committing.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 06:58:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 06:58:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401581.1637116 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqY6-0007a5-KL; Fri, 28 Aug 2026 06:58:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401581.1637116; Fri, 28 Aug 2026 06:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqY6-0007Zy-Fa; Fri, 28 Aug 2026 06:58:50 +0000
Received: by outflank-mailman (input) for mailman id 1401581;
 Fri, 28 Aug 2026 06:58:49 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqY5-0007Yn-9B
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 06:58:49 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqY3-00BR6P-TM
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:58:47 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91319a-e002-0a2a0a5209dd-0a2a450ad35c-28
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:58:47 +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 <jbeulich@suse.com>)
 id 6a9131a7-f2d2-0a2a450a0019-d155802bf1e6-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:58:47 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-49800c6a846so6386665e9.3
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 23:58:47 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49c5a8e0657sm2780435e9.13.2026.08.27.23.58.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 23:58:46 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900327; x=1788505127; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=Rt9tGRQMZU5d8zduV7r8lgiwa0hofvFlHCeU+g0PSdo=;
        b=MxkdW5Oor1AnpNcu2yerWSFYwDG0YazLKuvKt0RGMlnFvWQW5l042XQKTKjcO1R41/
         veUk2/AGw/+BV3pPxeyB3I9OheAjcrjN9hqnyynHQqJNoJ9UN/JpJIcOQsImIUbL+Her
         kGmIrK2t62iTRL/x1LZU09VMXcPBYbvn8Ch2NnNWT7zwlD70CX7xyHycwaue6D8gQ/7i
         FZPAQxfZ2JqWzwRpdgWheiW9VBRgOBkPJl56Zo/3VyGLX3u6uUEQlXABsSxO12FzU5Ob
         ZwvrosQNzL7XeH+fpxSqVU2o/g0qBxnS+3r/fIdQdiHgkRk07uno9TQ94GGnfXccpbb5
         Xqmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900327; x=1788505127;
        h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to
         :content-language:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=Rt9tGRQMZU5d8zduV7r8lgiwa0hofvFlHCeU+g0PSdo=;
        b=PjdYFb1+Wvio0wIc5Sxk0+GacvZVU5jUnqonSxsZXMh/AO3vhiNH69qzKh1nObsv4b
         o6Wu+6aCJoV1Fdp1adLEJYn8izlOkDfHoltakLf8HqLSoL4sFj3YIFWyRfz6FYFSXGls
         7QzkQ7KgJw916uLhgIC+uHvmgtWONIpEEFtSsKClmmbQ+H7XTIyCNG+eKDvIUvjrlZ/D
         tfMa1iYVvGjaEeoteiMNcVE1G0oHJJQXOMDGgQ2Gsz+a/cx6AAFjwKX1D8L/wnnmwVI+
         7AvVlSErXcDPF7XqCBDiKhWAlvG6EM0jWt5QbNXWh53m5TCBEWBx2DqVVmYRSQmyoa3R
         G5BQ==
X-Gm-Message-State: AFuF++lf9pn3/TXtDPLx6d+Un8VU4jwifPZIDZH3KFakCyeyBVCFA8It
	E1sTkzGIZ4lMPPnbwIphyEy+UrDb303yREhm0Dd7Iz2IZolVJ27VvUaH7B2aSbFlr6GzdTcq8C3
	cMT/b3g==
X-Gm-Gg: AR+sD11eN8lUe8tez7jGhWDKlx2dzJA5qgbozuhux6bbjlmoINBSJNlUhg+sGxKV+Ax
	DocjZovB7FXA9MjISW5ncZmIf8veIcE8YqsdEx7detLiafLpDVt+XBso7Y3KixN1PTAY6QVJuhh
	tvhXeGYBNC98G2rCRd8VpkPmGzJTObCGGJL9YwIORJEpiQkSCMZO4wP9eoawSyIZTXSVFe3OahT
	REfbQ4zSGFJSi/96HuqJYBb2l5hmiRh9grAFOxu2opHPQsO9wgguSffNtnY1JxCX7WMwouFXVYf
	A2hjdfj0vFmgtlOPmA8R6NKW2tM+KqNYAt1WPEQclYPnntOA0ROs7pkoG8ShkeDIs7i/0e/eQaB
	cNjpqisIKw3FIKnQo1J61+egau0lsiYEZkRY8yMX3teNOn9ZfCdWEhLUBfuq8GTLo2afReyeBb9
	/8Nc0lehLJ2E4nSQD2YO6Q7/NSS5oJTGTQBzSixwOuZo+V073lw4S/v5QVDBsnxzOGxio+Bmzu2
	e/eYxIyYqL4pfZ1LsQnyv2d4oEwM2sjE4HJ9mB7IYC0MX5oC/4W
X-Received: by 2002:a05:600c:4445:b0:499:900c:9c69 with SMTP id 5b1f17b1804b1-49b91c44fbfmr56794195e9.9.1787900327010;
        Thu, 27 Aug 2026 23:58:47 -0700 (PDT)
Message-ID: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Date: Fri, 28 Aug 2026 08:58:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>
From: Jan Beulich <jbeulich@suse.com>
Subject: [PATCH 00/12] address most remaining Misra rule 2.1 violations
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-4011c0/1787900327-587CACFC-D317F703/0/0
X-purgate-type: clean
X-purgate-size: 1160

Let's try to get the unreachable code rule almost clean: With this series
in place, as per [1] x86_64-allcode has one violation left, x86_64-amd has
two; ARM64-* are clean. But see also "gnttab: unreachable code when
GNTTAB_MAX_VERSION < 2" [2].

The first two thirds of this series are hopefully largely uncontroversial,
whereas the last third may be.

01: x86/IO-APIC: address Misra 2.1 rule violations
02: x86/mm: pagetable_dying() is HVM+SHADOW_PAGING only
03: x86/shadow: eliminate unused forms of sh_map_and_validate_gl<N>e()
04: x86: add noreturn in a few more places
05: x86/crash: address Misra 2.1 rule violation
06: kexec: machine_reboot_kexec() doesn't return
07: altp2m: address Misra 2.1 rule violation
08: Arm/GIC: add noreturn in a few more places
09: Eclair: deviate BUILD_ERROR() wrt rule 2.1 and introduce variants
10: PCI/physdev: address Misra 2.1 rule violation
11: x86/HVM: address Misra 2.1 rule violations
12: x86/nSVM: address Misra 2.1 rule violation

Jan

[1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2796557177
[2] https://lists.xen.org/archives/html/xen-devel/2026-07/msg01293.html


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 06:59:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 06:59:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401587.1637125 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqZ0-0008EL-S4; Fri, 28 Aug 2026 06:59:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401587.1637125; Fri, 28 Aug 2026 06:59:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqZ0-0008EE-Nq; Fri, 28 Aug 2026 06:59:46 +0000
Received: by outflank-mailman (input) for mailman id 1401587;
 Fri, 28 Aug 2026 06:59:45 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqYz-0008Dy-HH
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 06:59:45 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqYx-00Dl7l-7j
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:59:43 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9131c7-2eae-0a2a0a5409dd-0a2a4505c7c2-42
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:59:43 +0200
Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9131df-4cb1-0a2a45050019-d155802bdd90-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:59:43 +0200
Received: by mail-wm1-f43.google.com with SMTP id
 5b1f17b1804b1-499ac87c92bso5231945e9.1
 for <xen-devel@lists.xenproject.org>; Thu, 27 Aug 2026 23:59:43 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b95013d06sm37120195e9.12.2026.08.27.23.59.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 27 Aug 2026 23:59:42 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900382; x=1788505182; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=oqu+Q0osoQJYn18e0xy/OsR8FRgD25zg2JGzP482jGc=;
        b=FORPWQkvISF9BysPN5UyXtabUu2tHizdVeYmS7cJDsu43rNCTnJ0PSik6pdLgHGkO4
         pbXNHi9J9i3aEyfdC+h/OL50GoHIe0Hob/v7v1A08jZJxzGfpf2ob6orSMrbnfVvnxfd
         CvpY/BRPoQSrRI6RNbf/L9jp8CzLtIZQs/tYuJQE8U8rrTwmXwMV30p4btBh2/Tih/PK
         DC66XrKlPqyBfgjxY7Om+a7i0JM3YGEnpf50Zo10OHY9+5HHJYF/LvxI2NX4FAtt8wXF
         hjmySKLDtZM7y3TLYJx0PjcbwlTD+lhl2BRWcZNrmLI1vEzwLLlKDAODf5jQqf9ehNy7
         Pb+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900382; x=1788505182;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=oqu+Q0osoQJYn18e0xy/OsR8FRgD25zg2JGzP482jGc=;
        b=k2WIWYOkhe59DOQukh9fFXuy0APJKmD4gCdsTSKPgmh7UvqpeCJDYdE4jXoxEv2/Ro
         V5CPQngSNPBYIwM4Ab2PNJpUS8O67vUTJOdDruyRG5HI8/p7xm76F9oUHj6sP5odmclx
         hkXOUBscuMHxGJjriGbp3E85xgmRPEoeTU+0IbfTULxfAkrCTMU9/KL/Jg9DadymZzdX
         tONvegNaMBv4ixYLzVU5Ts8jQhrqNZioZ1JYh7KQCyk+ALLDakbhZJaPqA37ck+X8j4e
         qIql36bO/i9eCb/+k4ykgr443xK6qJ0IVp0eQK/hPeFiIT33gptelr0P8aRFI8wxXydQ
         ua4w==
X-Gm-Message-State: AFuF++kR9QZergkf3MQRNlacGc/1mg9sLaKtZJXfB8ZnX/+JPozJP6xg
	Y0Fqp5iCgeKzOx//enfEpqiTkP3gb2Wb2o5idEeaOxXqqCMYmVhuG+kLoEMkfrghebYw9qn1DLb
	eXpuPfw==
X-Gm-Gg: AR+sD10U/HS/EpDyWv/IbbdZU0Iyag09wEJtNwHmRxE2Ruxi43/QgG1L/zK3vlR+q29
	Rxywe2faI14lBYLTJ6U1TsE8w2NGx8EsWMkr5deqCvcsPMlc+GkZimer0J3OxY9q2gPxha791Zb
	rgtCajHkQ/kxZWC745rSFnLQEDSysQ8k0OuEIZdcx3YTYH6vqJxfe/1k+MJnFw8Y4DSE3b1it0I
	pMW7zC7vx3Yz/m8b+Od5DOzxynQ+z4xTB7/ihtixWnXu3NEcV7nXe1a8g+Gb3/9OYACX9WcW0/e
	7vRQ5ek6YVXZxfADkmN/2L33VAZPoJzfvQWtk7Drt58p9wOgwktymtZdQzHMWT2FOJcsFU53ub7
	AHqspssff4eiUp1CwS/bBm5DWXKwgUgQ65mbcRYcZ+8AIU3z5y98o5931FirvzP5tVz9xohp6EM
	dhFTJtJz11lMZNCl75Td4HV/77+jrHkpHbu5VWDaCInvC3ryZfh2GZIVZEqQ4MukxJ6qx8c0CqB
	JqAAqrrBNPXUEtftovla/fmhk1YwuvRiKHHn6JKIOo82i6w9req
X-Received: by 2002:a05:600c:83c3:b0:499:b01e:911c with SMTP id 5b1f17b1804b1-49b91c26535mr61714235e9.2.1787900382668;
        Thu, 27 Aug 2026 23:59:42 -0700 (PDT)
Message-ID: <85c111a5-105c-4b8f-8b81-d7ec1d0f9436@suse.com>
Date: Fri, 28 Aug 2026 08:59:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 01/12] x86/IO-APIC: address Misra 2.1 rule violations
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787900383-247132A1-121F5018/0/0
X-purgate-type: clean
X-purgate-size: 3800

In both functions cases 0..3 are handled, and a 2-bit mask is applied to
the switch() expression. Therefore the default: cases are reported
unreachable by Eclair. Subsume the "case 2" blocks each into the
corresponding default ones.

While there also drop all the pointless figure braces inside the various
case blocks, inserting blank lines instead between them.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -804,66 +804,48 @@ static int __init MPBIOS_polarity(int id
     switch (mp_irqs[idx].mpc_irqflag & 3)
     {
     case 0: /* conforms, ie. bus-type dependent polarity */
-    {
         switch (mp_bus_id_to_type[bus])
         {
         case MP_BUS_ISA: /* ISA pin */
-        {
             polarity = default_ISA_polarity(idx);
             break;
-        }
+
         case MP_BUS_EISA: /* EISA pin */
-        {
             polarity = default_EISA_polarity(idx);
             break;
-        }
+
         case MP_BUS_PCI: /* PCI pin */
-        {
             polarity = default_PCI_polarity(idx);
             break;
-        }
+
         case MP_BUS_MCA: /* MCA pin */
-        {
             polarity = default_MCA_polarity(idx);
             break;
-        }
+
         case MP_BUS_NEC98: /* NEC 98 pin */
-        {
             polarity = default_NEC98_polarity(idx);
             break;
-        }
+
         default:
-        {
             printk(KERN_WARNING "broken BIOS!!\n");
             polarity = 1;
             break;
         }
-        }
         break;
-    }
+
     case 1: /* high active */
-    {
         polarity = 0;
         break;
-    }
-    case 2: /* reserved */
-    {
-        printk(KERN_WARNING "broken BIOS!!\n");
-        polarity = 1;
-        break;
-    }
+
     case 3: /* low active */
-    {
         polarity = 1;
         break;
-    }
-    default: /* invalid */
-    {
+
+    default: /* reserved */
         printk(KERN_WARNING "broken BIOS!!\n");
         polarity = 1;
         break;
     }
-    }
     return polarity;
 }
 
@@ -878,66 +860,48 @@ static int MPBIOS_trigger(int idx)
     switch ((mp_irqs[idx].mpc_irqflag>>2) & 3)
     {
     case 0: /* conforms, ie. bus-type dependent */
-    {
         switch (mp_bus_id_to_type[bus])
         {
         case MP_BUS_ISA: /* ISA pin */
-        {
             trigger = default_ISA_trigger(idx);
             break;
-        }
+
         case MP_BUS_EISA: /* EISA pin */
-        {
             trigger = default_EISA_trigger(idx);
             break;
-        }
+
         case MP_BUS_PCI: /* PCI pin */
-        {
             trigger = default_PCI_trigger(idx);
             break;
-        }
+
         case MP_BUS_MCA: /* MCA pin */
-        {
             trigger = default_MCA_trigger(idx);
             break;
-        }
+
         case MP_BUS_NEC98: /* NEC 98 pin */
-        {
             trigger = default_NEC98_trigger(idx);
             break;
-        }
+
         default:
-        {
             printk(KERN_WARNING "broken BIOS!!\n");
             trigger = 1;
             break;
         }
-        }
         break;
-    }
+
     case 1: /* edge */
-    {
         trigger = 0;
         break;
-    }
-    case 2: /* reserved */
-    {
-        printk(KERN_WARNING "broken BIOS!!\n");
-        trigger = 1;
-        break;
-    }
+
     case 3: /* level */
-    {
         trigger = 1;
         break;
-    }
-    default: /* invalid */
-    {
+
+    default: /* reserved */
         printk(KERN_WARNING "broken BIOS!!\n");
         trigger = 0;
         break;
     }
-    }
     return trigger;
 }
 



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:00:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:00:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401589.1637133 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqZN-0001JZ-28; Fri, 28 Aug 2026 07:00:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401589.1637133; Fri, 28 Aug 2026 07:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqZM-0001JP-VG; Fri, 28 Aug 2026 07:00:08 +0000
Received: by outflank-mailman (input) for mailman id 1401589;
 Fri, 28 Aug 2026 07:00:07 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqZL-0001D7-Li
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:00:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqZL-002GzA-2A
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:00:07 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9131f4-bab6-0a2a0a5309dd-0a2a450180c6-28
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:00:06 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9131f6-5984-0a2a45010019-d155802cd5b9-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:00:06 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so5494255e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:00:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b94dd2517sm26945855e9.7.2026.08.28.00.00.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:00:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900406; x=1788505206; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=glK8r2X1HDZrfZbkA9pEuF32dcf5dlBYeyJpXiQwXoQ=;
        b=XVyogzra0xEzrNKpQSj4tzdlahWELG75zxU+xCE/aeIiStWTF1x3sfjQFvnqJ12WP8
         KOX+VeP5KC+WgWJtawBpYDNce2TGgR7g+mDD0nLokPMj69qMfp4GtQLpHOHRdF5MtsBs
         /18O/P+C/6Neel2D/kGRjLR08r1TaTlyx5EwQApj4o92chBzpNfDDWiYgAIHB28uVp45
         XtaItEY0rREYakSjihiksr0UPwoOEK0v1ofJpSTSDK4vXaObjq1ERNPd0h8xpc5CAv06
         ebsWYZEPMOX65cDeZ1MkEauYqVMYosAV6SLsiRp2KOJ0AHsqDSeqEGIq+wZLJ8O9wh5z
         S8FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900406; x=1788505206;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=glK8r2X1HDZrfZbkA9pEuF32dcf5dlBYeyJpXiQwXoQ=;
        b=OfKMeCDfn8FKto8U0Sn8mayQagTD3ZQW7vx7VYUsVBQ2V8snNFB9VBiyNVgXvd4gRW
         um2KzN+x8qa9rIxBfZf2hmvKzy1WC2Yh+Nji3UmBL7/tBFa9S8MiP0INMaj4gsEr+QAD
         ohL9FtMsxQYPvKZx9qS29sh10efB3t9+SeAlLu47izGfXUsf3VkVGlxSibVVo6UQYDYe
         A7CIoFRVqgy4dBBC0Db+j20cbQmVPw1WBy0aYb3vLrHdqjDz1kLRj+t1OklBl9blye+Q
         ZMkIp4U07qvO6XNWmH4v+SWxT9oa+bWPQQD8yNad5fh7k0FcFHK4lM0qDa53flJIFkuQ
         9rhQ==
X-Gm-Message-State: AFuF++nih3Yj7K9gPriljc6wEN32kP5U3CiAZr2lTZVz7Cg9UfpmAFaO
	veFWE0Iq//6UFLvufC/7SlSH45HD9DCKL/dVQ6xsbdTQd2yFlHwTbXJKeSbGiTctDimFWg+Syab
	UB/Etxw==
X-Gm-Gg: AR+sD12xaw9owJjOSJ9NLQnE/8je/0FGdDt6fwCcwTgzKzhsRHOgfXQWGhQbtgcOIY2
	g+PinZsLSYINnow3/C01bU5RO+y7YV7dGX3cdXuSKEpcBhY/dk/mhDi4XpFd01cjlntdkcloooz
	BUE2lncYG0cHH9JLqBLrNE1xb4ktT/b51Rs8hZ/Rz6aUiyKr23TeNUC4GX8AX+P1L6bgi7osp/I
	0jn4oIQDxFTuneq4G0TC9XjzY2KvAH4/5jmB1HKTBxTAdNulzSoLf/4u+9sweI746v8IXfyAaM6
	2xnIMTXYPB4WtAXCk1jvSHsjIPrrnMQ+jC+jN58hh9rslWapxZ2p2FnJ/45zGZ0YTlorEo7c3VG
	933+SRZRIdfjqRgTFffw4mQi/YiaAqPwMBZtLih9mEgyNB5mfmqTAMuCbJ87KDQef79VeO2K75R
	WJMshuVcB2X7He0/UCnMdLXKro76WhyLc6NwkzqyqljEcT+AnZ462YCu7ViCgvTS73zb9thb1KR
	N0SgNo+1Q4r0bvINMy3342n22WX8KTU/Sh8+qemowmsDaR8pZ+z3my0iXKTI04=
X-Received: by 2002:a05:600c:698c:b0:499:adb5:e7b2 with SMTP id 5b1f17b1804b1-49b91c3ddc7mr81316065e9.11.1787900406113;
        Fri, 28 Aug 2026 00:00:06 -0700 (PDT)
Message-ID: <12b3dd09-7249-47cd-8c66-e0efc1611b14@suse.com>
Date: Fri, 28 Aug 2026 09:00:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 02/12] x86/mm: pagetable_dying() is HVM+SHADOW_PAGING only
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787900406-BF66C757-ECD8ED89/0/0
X-purgate-type: clean
X-purgate-size: 1249

The referenced commit didn't go far enough, leaving a Misra rule 2.1
(unreachable code) violation: The function lacks "noreturn" in this
configuration. Since with SHADOW_PAGING=n paging_mode_shadow() is compile-
time-constant false, the compiler can DCE the call site. Hence we can
avoid building the function itself altogether.

No functional change.

Fixes: 2fb2dee1ac62 ("x86/mm: pagetable_dying() is HVM-only")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -872,22 +872,18 @@ int paging_enable(struct domain *d, u32
 }
 #endif
 
-#ifdef CONFIG_HVM
+#if defined(CONFIG_HVM) && defined(CONFIG_SHADOW_PAGING)
 /* Called from the guest to indicate that a process is being torn down
  * and therefore its pagetables will soon be discarded */
 void pagetable_dying(paddr_t gpa)
 {
-#ifdef CONFIG_SHADOW_PAGING
     struct vcpu *curr = current;
 
     ASSERT(paging_mode_shadow(curr->domain));
 
     curr->arch.paging.mode->shadow.pagetable_dying(gpa);
-#else
-    BUG();
-#endif
 }
-#endif /* CONFIG_HVM */
+#endif /* HVM && SHADOW_PAGING */
 
 /* Print paging-assistance info to the console */
 void paging_dump_domain_info(struct domain *d)



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:01:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:01:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401600.1637143 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqaE-00028V-Dz; Fri, 28 Aug 2026 07:01:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401600.1637143; Fri, 28 Aug 2026 07:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqaE-00028O-AG; Fri, 28 Aug 2026 07:01:02 +0000
Received: by outflank-mailman (input) for mailman id 1401600;
 Fri, 28 Aug 2026 07:01:00 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqaC-00026e-F8
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:01:00 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqaB-0015sL-S0
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:00:59 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913227-e002-0a2a0a5209dd-0a2a450686f0-34
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:00:59 +0200
Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91322b-195a-0a2a45060019-d155dd2ebd88-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:00:59 +0200
Received: by mail-wr1-f46.google.com with SMTP id
 ffacd0b85a97d-4798bea72f9so413302f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:00:59 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbb20784sm1813269f8f.18.2026.08.28.00.00.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:00:58 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900459; x=1788505259; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=+m1CwKzFOQuLY7Ed6bVSIiSUHeYqUHSn/bbUY8FHCIs=;
        b=G1c9/lU0+9C43z1fyx3cUGQTa9gsBJm6gYWUxnsieSvnrGPvJ6icb2F1itf0TpGOMS
         JswKz/gtz6WDFn3/sH2pfH+/3VwTvCd5nkiiY/ihz4CZBam6NBe3jL67Yjwxq6c8c9W5
         S/hgs/gq6tU8BEwESP7vI4y/ywWwdJgiNrEQNYoz6cCENr6q33I+NkU7/417vNBPFHhX
         vv4JaCG+s04rEqogfY2pmRaIjn3ah650FSFYm7hmnebMXzQlLYNeFbImEA3nE1oswH/f
         e6ImMbcCZ4s4YIs1EPsdXD1CGfZom1WRLo/CuOzOPxT5KMbxf7K+SniuYHFrfJ+64/VE
         RKzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900459; x=1788505259;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=+m1CwKzFOQuLY7Ed6bVSIiSUHeYqUHSn/bbUY8FHCIs=;
        b=RlExf13EF0TXjpL8RUsc6g3ob3H47naB8r/gHt0Ct5IhT4KM0nfBsISuqh2HBYKeOK
         +FA4pUZC/OZDlS+xbJfnFdjZsVpJfi0xVAR9FcFDpSQeEATd1tfgLteoSqGDT+TaNq2l
         Zv5XIZr5Wmqrh2wPK3HBRxkUBG/A4M8ET+VDqmLYso2UBZW35leE9MLeZKFeJH6elICJ
         oSbMngG9U9mMnPgSVYcNUMvuSSytm42sJIKyYf8b/9AH3EDI1obEbvCsucJyXwWcye2v
         EYtf/fA0HkDNQtG5y5XIr/uLR26KcKTPaPcPvbW/6Zu3+xRvVVlf11j9dvQacxXWe82r
         Zg0g==
X-Gm-Message-State: AFuF++nH7ETiOW67yM3GjQDlX2Ox+V4qtgF66Bn3REVlrZ8GYDKrhDAd
	o93B5r0aNxYsgmV932ga1lPSChnJMQX6YxulQg+abMLlOXRBZihV/ubd+viyXvL9Q478fQSHi7J
	MT6M26A==
X-Gm-Gg: AR+sD10JtYtwbGIu5yR+dtD8zcO7U9khy+q0aUbA85uiKwFWiWtpRybImJF811q0GfP
	jMew1NNGXrvaQyVkj1uu/uwljPIZ/l2Nji68UYjP4PSUJZmLmJGwwfavd/Gq7GpReUWZ+6p54ph
	tDZTkjGVS1TbMklL2EEKsWuuxT+BAhMIemdcQFWM0ZhsBCDxz6sAFbNWqfJkqfavTD2KPYCh3T/
	csI86xyU6hHBkLdZAjE4aHxFemz2B6Qb67wFkepQ3WvqLdXiq38QOG1Tp2JKlBndgEq3Q7SffyM
	Zd6y8K85pyPNG8uS7n1zXWEyvT41gU1q1+AdjZdxKlLkLgSWz+dGq5S2gVvDZ4IEncDobmxnPTA
	i9V5ivGTt9RA9uid78BTytjTYFNUDO4LVX/lYGl9DybppIEGGFg6kkByca0yFTZHkDDwT0PCfZB
	NShRFFkN1w0nle42aPWRt3CEo6rBIIb/ptb6hgfpnvk8Yte2cslrB96nw4ulqkSvBVkQykBlV5E
	jyHKGULvPMlllqSTjybz1wQrRxPxov/l7b9/8DWyE3ftz2BomPkBeA5YFgs7cE=
X-Received: by 2002:a05:600c:3b21:b0:498:952:e276 with SMTP id 5b1f17b1804b1-49b91c3f643mr61587435e9.8.1787900459184;
        Fri, 28 Aug 2026 00:00:59 -0700 (PDT)
Message-ID: <9c4e5674-e79e-4623-b87c-ada690778ffa@suse.com>
Date: Fri, 28 Aug 2026 09:00:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 03/12] x86/shadow: eliminate unused forms of
 sh_map_and_validate_gl<N>e()
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Tim Deegan <tim@xen.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1787900459-F6C7777B-5CA53083/0/0
X-purgate-type: clean
X-purgate-size: 2390

The L2H, L3, and L4 forms only have GUEST_PAGING_LEVELS=4 call sites, i.e.
their 2- and 3-level forms are unreachable, violating Misra rule 2.1. The
L2H form additionally is unused (call site DCE-d) with PV32=n.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1789,35 +1789,30 @@ sh_map_and_validate(struct vcpu *v, mfn_
     return result;
 }
 
+#if GUEST_PAGING_LEVELS >= 4
 
 int
 sh_map_and_validate_gl4e(struct vcpu *v, mfn_t gl4mfn,
                           void *new_gl4p, u32 size)
 {
-#if GUEST_PAGING_LEVELS >= 4
     return sh_map_and_validate(v, gl4mfn, new_gl4p, size,
                                 SH_type_l4_shadow,
                                 shadow_l4_index,
                                 validate_gl4e);
-#else // ! GUEST_PAGING_LEVELS >= 4
-    BUG(); /* Called in wrong paging mode! */
-#endif
 }
 
 int
 sh_map_and_validate_gl3e(struct vcpu *v, mfn_t gl3mfn,
                           void *new_gl3p, u32 size)
 {
-#if GUEST_PAGING_LEVELS >= 4
     return sh_map_and_validate(v, gl3mfn, new_gl3p, size,
                                 SH_type_l3_shadow,
                                 shadow_l3_index,
                                 validate_gl3e);
-#else // ! GUEST_PAGING_LEVELS >= 4
-    BUG(); /* Called in wrong paging mode! */
-#endif
 }
 
+#endif /* GUEST_PAGING_LEVELS >= 4 */
+
 int
 sh_map_and_validate_gl2e(struct vcpu *v, mfn_t gl2mfn,
                           void *new_gl2p, u32 size)
@@ -1828,19 +1823,17 @@ sh_map_and_validate_gl2e(struct vcpu *v,
                                 validate_gl2e);
 }
 
+#if defined(CONFIG_PV32) && GUEST_PAGING_LEVELS >= 4
 int
 sh_map_and_validate_gl2he(struct vcpu *v, mfn_t gl2mfn,
                            void *new_gl2p, u32 size)
 {
-#if GUEST_PAGING_LEVELS >= 4 && defined(CONFIG_PV32)
     return sh_map_and_validate(v, gl2mfn, new_gl2p, size,
                                 SH_type_l2h_shadow,
                                 shadow_l2_index,
                                 validate_gl2e);
-#else /* Non-PAE guests don't have different kinds of l2 table */
-    BUG(); /* Called in wrong paging mode! */
-#endif
 }
+#endif /* CONFIG_PV32 && GUEST_PAGING_LEVELS >= 4 */
 
 int
 sh_map_and_validate_gl1e(struct vcpu *v, mfn_t gl1mfn,



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:01:52 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:01:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401607.1637151 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqb1-0002iP-MU; Fri, 28 Aug 2026 07:01:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401607.1637151; Fri, 28 Aug 2026 07:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqb1-0002iI-Ic; Fri, 28 Aug 2026 07:01:51 +0000
Received: by outflank-mailman (input) for mailman id 1401607;
 Fri, 28 Aug 2026 07:01:51 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqb1-0002hv-23
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:01:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqb0-00BS6p-Eq
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:01:50 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91324f-e002-0a2a0a5209dd-0a2a4504a508-40
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:01:50 +0200
Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91325e-b57f-0a2a45040019-d155dd2bb479-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:01:50 +0200
Received: by mail-wr1-f43.google.com with SMTP id
 ffacd0b85a97d-482c58a8683so494707f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:01:50 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbb27936sm1770875f8f.28.2026.08.28.00.01.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:01:49 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900510; x=1788505310; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=PK9zMBufoVGWq6x8z32e+ws1C3h4VMgJkNucIWcX4mE=;
        b=FjJle4PiBWVqSV0EfiSFSwxt9px+/XgF6MhLqMF1/v3AaJZf0qbzJsGBw0FeBNJOLH
         7PyB4ZhprIlO8lHtjS7QervrjvK6xkeuC/RTqdN/N7N2JzAvcpFwSFbDyRo05ItY7303
         sGVlIhq2Hv35BPZM9sp4noJeVFwusZe4FNDkgqSDo7rYDfyVb6vNx+pkHU9DSSwW6wB3
         RbzSumN4mh7LiVtNY5sXb6P2FhyqlHNP7FhfVWRy3LBNv6FM9M7ChFiP5nhY4Uc5Em4+
         nikBvAeQIkq51GIq/y6908k/doo21NAiqg8U8v0bngJ7B8k9HTD+8arXjEvnf/4wKAPh
         FFwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900510; x=1788505310;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=PK9zMBufoVGWq6x8z32e+ws1C3h4VMgJkNucIWcX4mE=;
        b=N3lEeQPXczeMAG1pTJjEpPBBh0nlbsEFYF8gzDEqHO6zzDa3hu3Pv6Cl0MpFnyvIlz
         v5FDpuA2UQQcaQGgzr0h+rr96ApjfU1tubza+2ICjvdVcpZL4XokRb3D5hbpoBZLHzM3
         3axR4Eha8ZMZ1qQoZCHR+bKlKkrTjFM3LQ4u6t94vTwqDOjLu1IzzrJuWQhykPtkQ05g
         d9+45NYWrfN6zyfAkoPVtaw8h60to1hVMm6pttBxeLOlgtzGgqF+au8P9SL11kDPTAB2
         aD818ZhhJE0LTbRbZlPIWb+mbFhXOLgROX1TuRL2t7dK1K6rn7NtWDhR/RAxoANN6EUB
         1IGg==
X-Gm-Message-State: AFuF++lEcSQ4wz36ar9Uc6bzbboqbxrX/Whtb24BShM5I/gopXcIylDG
	dfAGQgaGpRcHJD0iyvhxQbvx8eKpHePaU8KbB6EEs4jhnoThcpO9xn5xciFFbdEK0GdQ9EgoJBk
	FbOu/cA==
X-Gm-Gg: AR+sD108FDDm1h41feWvyHZ9giD0qjG7PrO/aq1DOBGXq4vJO/0ozjidQRZ65orh5T5
	HWwPnJMQAd+wjhZyJPO8Ptek9UVCrPQvSN4tJJpl35FJEQHExugk18rKlqJO1eEyHuDyhp2Xjef
	ZH6DX22q6rhVq4pgiJceiAGIH0XSco4LiNTvB2ApADYBfcvufantlXdh78gOADR5WJIEfuIyYi7
	9BRYsHkOphjUHlL+oewcHUAIKBx3qACc4ZbR3DgTceSZfKp5noM6ssatO0RzeqPhZda2ddrUFsW
	HZnSknvBtG4IOfFemTy9zolyCuEbpqX+2Xoq9J8LBE0vQSznWier4xOn5Bnx0kUPJ+643e2JB10
	Cus/gcpgt/KzYacN6ap3fOVYqabDsFbopUVdQuf418Z/EhCOM7YUHvndtPQ4xMWK62OdB5+MLfT
	B3kmxgoGMnVI1G1+aiNOgc3+7ksHq7pyaP6F8D+/VQjqW5SJw/c/e20etIslg7qzA/e6ZNDW+86
	WRwgzppBvh3JkYkew8tP/vArFWFGIxk0lTa2E43i+q8aEIpd+4nrVl6ajWJIwc=
X-Received: by 2002:a05:6000:2904:b0:482:ea9b:962c with SMTP id ffacd0b85a97d-482f79c91e1mr7402311f8f.22.1787900509801;
        Fri, 28 Aug 2026 00:01:49 -0700 (PDT)
Message-ID: <d0f991de-db67-4f49-aef0-25c590b3889e@suse.com>
Date: Fri, 28 Aug 2026 09:01:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 04/12] x86: add noreturn in a few more places
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787900510-502E4B50-9F64A953/0/0
X-purgate-type: clean
X-purgate-size: 4001

start_secondary(), do_double_fault(), play_dead(), and tboot_s3_error()
never return, so would better be annotated anyway. The do_double_fault()
change needs accompanying by adjustments to entry_from_{pv,xen}(), as
Eclair then deems the "return" there as unreachable.

context_switch() and continue_running() are odd: We can't
(unconditionally) add noreturn to their declarations, as Arm's variants do
return. Put the attribute on x86'es definitions instead (the use of
unreachable() in reset_stack_and_call_ind() allows the compiler to figure
that out itself, but Eclair wants the annotation in addition).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
entry_from_pv() wants the annotation only when PV=n, yet once added gcc
then warns about "return" being used in a "noreturn" function. Is there
any other approach to address this besides adding #ifdef inside the
function (i.e. replacing the !IS_ENABLED(CONFIG_PV) check that's there)?

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2163,7 +2163,7 @@ static void __context_switch(void)
     per_cpu(curr_vcpu, cpu) = n;
 }
 
-void context_switch(struct vcpu *prev, struct vcpu *next)
+void noreturn context_switch(struct vcpu *prev, struct vcpu *next)
 {
     unsigned int cpu = smp_processor_id();
     struct cpu_info *info = get_cpu_info();
@@ -2240,7 +2240,7 @@ void context_switch(struct vcpu *prev, s
     reset_stack_and_call_ind(nextd->arch.ctxt_switch->tail);
 }
 
-void continue_running(struct vcpu *same)
+void noreturn continue_running(struct vcpu *same)
 {
     reset_stack_and_call_ind(same->domain->arch.ctxt_switch->tail);
 }
--- a/xen/arch/x86/include/asm/cpuidle.h
+++ b/xen/arch/x86/include/asm/cpuidle.h
@@ -26,7 +26,7 @@ static inline int mwait_idle_init(struct
 int cpuidle_init_cpu(unsigned int cpu);
 void cf_check default_dead_idle(void);
 void cf_check acpi_dead_idle(void);
-void play_dead(void);
+void noreturn play_dead(void);
 void trace_exit_reason(u32 *irq_traced);
 void update_idle_stats(struct acpi_processor_power *power,
                        struct acpi_processor_cx *cx,
--- a/xen/arch/x86/include/asm/tboot.h
+++ b/xen/arch/x86/include/asm/tboot.h
@@ -126,7 +126,7 @@ int tboot_in_measured_env(void);
 int tboot_protect_mem_regions(void);
 int cf_check tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
-void tboot_s3_error(int error);
+void noreturn tboot_s3_error(int error);
 int tboot_wake_ap(int apicid, unsigned long sipi_vec);
 #else
 static inline void tboot_probe(void) {}
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -326,7 +326,7 @@ static void set_cpu_sibling_map(unsigned
     }
 }
 
-void asmlinkage start_secondary(void)
+void asmlinkage noreturn start_secondary(void)
 {
     struct cpu_info *info = get_cpu_info();
     unsigned int cpu = smp_processor_id();
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1080,7 +1080,7 @@ const char *vector_name(unsigned int vec
     return (vec < ARRAY_SIZE(names) && names[vec][0]) ? names[vec] : "???";
 }
 
-void asmlinkage do_double_fault(struct cpu_user_regs *regs)
+void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
 {
     unsigned int cpu;
     struct extra_state state;
@@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu
     case X86_ET_HW_EXC:
         switch ( vec )
         {
-        case X86_EXC_DF: return do_double_fault(regs);
+        case X86_EXC_DF: do_double_fault(regs); /* noreturn */
         case X86_EXC_MC: return do_machine_check(regs);
         }
         break;
@@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp
     case X86_ET_HW_EXC:
         switch ( regs->fred_ss.vector )
         {
-        case X86_EXC_DF: return do_double_fault(regs);
+        case X86_EXC_DF: do_double_fault(regs); /* noreturn */
         case X86_EXC_MC: return do_machine_check(regs);
         }
         break;



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:02:22 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:02:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401612.1637159 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqbV-0003H0-Td; Fri, 28 Aug 2026 07:02:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401612.1637159; Fri, 28 Aug 2026 07:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqbV-0003Gs-QU; Fri, 28 Aug 2026 07:02:21 +0000
Received: by outflank-mailman (input) for mailman id 1401612;
 Fri, 28 Aug 2026 07:02:20 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqbU-0003FW-Rb
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:02:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqbU-009FjH-7t
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:02:20 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913275-8faa-0a2a0a5109dd-0a2a4505ae48-40
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:02:20 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91327c-4cb1-0a2a45050019-d155802eb505-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:02:20 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49557167508so5866045e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:02:20 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b94dcb3d9sm28839595e9.5.2026.08.28.00.02.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:02:19 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900540; x=1788505340; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=I1byslbOG0CeFzmY2s3/l4wrq9b0PgsYDl6emmZmMS4=;
        b=LY/nj0veQReLQo8MGqj+h2PwS4e/15ZjgRJyHiiL/tOVc/R99bMLaIePRh70YQsd6u
         qqVZyV7hZB8Nw6EgkywFNh2eL8VRcTBbwTCCJUW2TCQxciW5CO7Hj6vOAf+YgbDqWPNj
         4SQ/Qmycjq551RmCW/kR2DtN6VJwM/8/0UzJdOC1PhFh2uKIUV2R0wDrlcDpBQi9QzUH
         IkQ+AKnzQxuNU6xw30sLUXFMJa/frLZ+zD5AWycE4giEk5H1rw+B7a4kqAIQvYfy7ltA
         QQ8uOEmn8jTKEJhWOgM5wZrKf98W7Bh17eVErEtSTuJfT9PdMeF0J5J4+jyo6mS1Sn5I
         w3QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900540; x=1788505340;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=I1byslbOG0CeFzmY2s3/l4wrq9b0PgsYDl6emmZmMS4=;
        b=Ij3Mit3I+ivCAbuusmjB6zH4zcjSF0HaLsWZJ0b5ZANksEeI2wWctsKDwRHuyv5MhH
         088uzCjPngiHFayAdiolM2tGXw+E/4HhPwZY0pyvD/eEAzsW3f4mqm0vBukhyEbiAqPN
         NQWj8nhXu/DUlmVyzP52GwkNJNA/fDR30V0RWyEZc7rw/xVFwJgMjDnL0dQt3zE1Er/n
         HyIsSzk6alLt+mVpTn1ky96dFTmQhhrJX01djQ6xl/5yov9oBNgwI46264DnZMcg+Pfk
         CemctUz5w6ZxY9fMaT1cMsn37eutv4Jx+cQob9njiZ4Q7ecuHz/wbk5DkdRoNgN7/V+H
         N1tw==
X-Gm-Message-State: AFuF++kY1X1ZsJf2pkOmyxx39dDMil1pYJERdVCp+MgHWkiBt5AF1/Rc
	J0l3X7tQ98OCP2HCZPVnkFWVTo4vIuvmNnVU3To+NGuCN5ICLkF5d09HzHuH483tG8thWyI8u1+
	s3W7mDg==
X-Gm-Gg: AR+sD1042K9HyDPTVpyotoKACXogAT95s0rt3fcPkCq2Tk/eNBEgcVnMnfb6HgrAreu
	b/AQq/BDQAjscEomfB/kxzh4dW0iXAHtvSGQxZCCFgepT/0XY0YQpBXGdvJ3P9beo+xVH+eOTTO
	xLzx7IKfeDpzZ0Xv/bHzQLP6VxV+NhXEdf8v3qo3Mg+sxrUx/yvEspYEjPLyarSTpNku40xhUJ2
	v/ZPmNZ5Dzv2ST86NeS41Ig+uJ2kPOlLwTv6r2GYtM80Vzz1ZzFPsiaW1CijEYteFVRz1hWYvYr
	VxMetsW6jCPJPNElsP95eAMhcfKt6/R+gXZ2ALoDufZDg8TjgszNnoI/yBoVphc2izBbnlG/F4H
	INi3ebMqBEzIUiMD0A75Kl8ale6EiwMhJf2BlzGTTJUa+PrXhhEdjwUlFU3Dr7CAIo5x/bCeAZI
	ufpWh7CRh7l9TFpV1x83HFmgHhovMvtt7QPkxuuqJwiLBUkUPMEuTodNF47SDOfeAZ54YZTzWNd
	FstgQffYfkpkz/IEOUqpF5gZvlNwnL7hvtPE22HQuwhSmQuS4X3ar8/7M4OzsE=
X-Received: by 2002:a05:600c:8486:b0:499:dbba:9859 with SMTP id 5b1f17b1804b1-49b91c27436mr64024755e9.5.1787900539660;
        Fri, 28 Aug 2026 00:02:19 -0700 (PDT)
Message-ID: <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com>
Date: Fri, 28 Aug 2026 09:02:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c201ff/1787900540-72AB72A1-FF57D71F/0/0
X-purgate-type: clean
X-purgate-size: 438

The use of unreachable(), when unreachability is visible to Eclair (and
compilers), is deemed a violation. Drop the redundant statement.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -118,8 +118,6 @@ static int cf_check do_nmi_crash(
 
     for ( ; ; )
         halt();
-
-    unreachable();
 }
 
 static void nmi_shootdown_cpus(void)



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:02:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:02:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401618.1637169 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqc5-0003nJ-5q; Fri, 28 Aug 2026 07:02:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401618.1637169; Fri, 28 Aug 2026 07:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqc5-0003nC-2k; Fri, 28 Aug 2026 07:02:57 +0000
Received: by outflank-mailman (input) for mailman id 1401618;
 Fri, 28 Aug 2026 07:02:56 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqc4-0003n4-CX
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:02:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqc3-002Hwb-PV
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:02:55 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91329c-bab6-0a2a0a5309dd-0a2a4503db8a-12
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:02:55 +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 <jbeulich@suse.com>)
 id 6a91329f-fae8-0a2a45030019-d1558035b502-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:02:55 +0200
Received: by mail-wm1-f53.google.com with SMTP id
 5b1f17b1804b1-49557167508so5870635e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:02:55 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b91c5790csm36127975e9.0.2026.08.28.00.02.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:02:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900575; x=1788505375; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=AAGR8QqK5GSSuw5IrkPcVKUO4dAwD5cpH9pk+9rg2/s=;
        b=an0avKRxzuQ0vOD8sA/X6TH89s8aa3G4HE5TjDltZ1X+gdmuhE4SNL2Y3OCMq9Drlb
         99+bGxY9lTYKanEa68ASq1yYZZtfSG0mEvCLrWLfDxKqUXEVZRjgeghAgc6M1z0VIGjU
         9U2S5yTW297KO9PucED/QSqcVD1ZTYCeDYX/bfVvw/MC++0wfvoYKkd+gj4gngxU+ht+
         li5A8Jk2LzhNwFCuEERniI44chuOZL1qUa2LRipilQk3RhCpwnU+XiaWCJCL8bGHfyBd
         KNa2epiuY6Jy3Mfo3H/9YkoSey+WFnQP47Ocf9q7qmCdbNSnRN/S2p3l1/XVzM5snMiK
         LLOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900575; x=1788505375;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=AAGR8QqK5GSSuw5IrkPcVKUO4dAwD5cpH9pk+9rg2/s=;
        b=pHzleCSsEJ76a2t0Gwk1I/ZKZtWLFAtG9Vik1AgbV700yPdWlw549inLhxoF37zbEF
         q50PzqErbgzIinFs3FrHZVQmn7JyjHsi9b5A7rWhcsr0X1T0P7y9ealPn/7XW1r05e3G
         I5UrbZwAJ7nrhq+ApCVM/kfXA3BZs1G6UaiF40vbpf9V+zep5BCdRiRMOn6SNlCTW2/Z
         dVHXVfe++5XGmjI+aLd7AzQGK7AZNVBeqBzfUAD1WASyZgayKQICrrYzwHnBwU7EK8if
         LzOzHGEXfqZUXSi/TiundxNcRZi9eNcp/LMTfALJqOuCB+QIYW/Cusur7i5nVajHsWJZ
         58OA==
X-Gm-Message-State: AFuF++nupJ4cL2TgkP9E7DR1qt+b0XHPeA/p3IN1iUt9nYZ1VgkDaCOz
	bteGBvBllqzWt5N8qIJgSqxacj1xNBMfMmedOxtFV0ZBdLLHdzb4pvnokN+LGSfX882/5OFoo3K
	rA9EpNA==
X-Gm-Gg: AR+sD10JP1KLNCoDJYhj5ReVxUJl8uNJYkR8KeF6WciI4ZGjHC1A6ABdznvLST2IIwY
	yi99xpo1LA7nYZAYIgiKtwhVGMoTnrormFxhvoeKFE8qtqFT147yIuc1wxGz1YXbkKDJ4Tvhr0Y
	ECh32+rrqeWMG6Iii7jbyEJKdI53Y+bzpAex6oSHPDy/nte0Dq3PBLxF2QNUWBJ3kX9VcDdxKMH
	lHlO/m9l6bBVuxLYkgc1gT6gIMvzi+cdoiFibEc+qM0u2hZnbbpEYaao/RIBb7bOsFzq27Ku/LL
	xw8DWqG/uZo9g1jgDUYsLO3eBbl4O3LiqxHJvHViMhWLT+2RpnVnevxtF7gW1S1QK1eLH0E5xub
	cyv7K9tTfCvjAA9NXw+PBBlgkzgw+siZx0a3gK7RQU4q9r7Q6YkVuu3MytR694gmJK8yPmHih+H
	OfW5dt9T40FpCEzH7Q6MRGTcAK1xnH26x8ObI0TTHwJnWcxqXPoYQlPvTGM1h3DsAsfLy2b5Vu9
	1QqVKjHz1IvBrDI5h2HdrndRSgT0sKmgxEfBjRtW0gBQFqXafzCogpZFeuKfEg=
X-Received: by 2002:a05:600c:4452:b0:493:f140:c3fb with SMTP id 5b1f17b1804b1-49b91c2e42bmr63460935e9.7.1787900575240;
        Fri, 28 Aug 2026 00:02:55 -0700 (PDT)
Message-ID: <26fe76ce-db8f-4641-aeea-667fb6ee3932@suse.com>
Date: Fri, 28 Aug 2026 09:02:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 06/12] kexec: machine_reboot_kexec() doesn't return
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-33051d/1787900575-6E8CD4E9-D9DE6AAF/0/0
X-purgate-type: clean
X-purgate-size: 1278

Mark it as such, and then remove the code following at its sole call site,
for Eclair flagging that as a Misra rule 2.1 (unreachable code) violation.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -401,7 +401,7 @@ void kexec_crash(enum crash_reason reaso
     BUG();
 }
 
-static long cf_check kexec_reboot(void *_image)
+static long noreturn cf_check kexec_reboot(void *_image)
 {
     struct kexec_image *image = _image;
 
@@ -409,9 +409,6 @@ static long cf_check kexec_reboot(void *
 
     kexec_common_shutdown();
     machine_reboot_kexec(image);
-
-    BUG();
-    return 0;
 }
 
 static void cf_check do_crashdump_trigger(unsigned char key)
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -48,7 +48,7 @@ int machine_kexec_add_page(struct kexec_
 int machine_kexec_load(struct kexec_image *image);
 void machine_kexec_unload(struct kexec_image *image);
 void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
-void machine_reboot_kexec(struct kexec_image *image);
+void noreturn machine_reboot_kexec(struct kexec_image *image);
 void machine_kexec(struct kexec_image *image);
 void kexec_crash(enum crash_reason reason);
 void kexec_crash_save_cpu(void);



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:03:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:03:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401626.1637178 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqcf-0004Qn-FX; Fri, 28 Aug 2026 07:03:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401626.1637178; Fri, 28 Aug 2026 07:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqcf-0004Qg-Cj; Fri, 28 Aug 2026 07:03:33 +0000
Received: by outflank-mailman (input) for mailman id 1401626;
 Fri, 28 Aug 2026 07:03:32 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqce-0004QO-0k
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:03:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqcd-00BSfo-Dk
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:03:31 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9132bd-e002-0a2a0a5209dd-0a2a4508880e-16
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:03:31 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9132be-f659-0a2a45080019-d155dd35e805-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:03:26 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-482e4998d28so416562f8f.2
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:03:26 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b92679be5sm33489005e9.3.2026.08.28.00.03.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:03:25 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900606; x=1788505406; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=xgIaJ540DVn9gMAwDjHqVBhyS2+4Ub8sOGYDzk1OFhQ=;
        b=HLZF3tFGyAn4piaLpUP+9hkBHKaGqAwZCwSYzqi/Q93BFK63tkssEpYz4leYsm/KCF
         7C3CkHVEV/iYP6aw9OWs2gR6HTxT/k2R6tIV/KFwYKczAiy1K6rJsNg+Jv66/rG1IJpy
         VWmBiruVxCrimUb9ShvbSgcyzPiTheROUxh/s26OU+Dg6ebj4HdGq6F4uSMd61N4bbms
         JYcIfWUboBJqFjkg12wl3s0Qc9IYWbPnZz+ocfUd8z2zg6odGjTZJMyABBOAriPfWciH
         ZGMDX+lIXy+kCFfQJBH0zZKzkNLlxXVn1arLvAqRp5xrc04RTkLXdT1/Qk7JjuddYre0
         eUnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900606; x=1788505406;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=xgIaJ540DVn9gMAwDjHqVBhyS2+4Ub8sOGYDzk1OFhQ=;
        b=U6bNBpgDXfoVhx9U8s+NET4bI1HPwbVfek36PaMAn1IWfablO6xheHyubEwm5xWw2v
         09B1I87PL05c04KPlKq/DZfASaMwHoW9gVkqzqp5798Bvk9qaTV3frzvEwv0cULJgGEi
         VMwd+Ke+Y09b4jMPkMwTMVsKgj59RG7+Pe+d1K+Qwio9clB+iJnwcytC5K66VpdJRq9x
         CIC0HjIKq88eck2ZCRw4MXg3EC1PkMIprAyk0CvNAbQQ0Gcrj5jEyeyvIqKquAGwStDm
         l06//+fA6XylvjKwgk7DdnHt7fZCC0AZ3y0YdCkczbbmGSMSxZ/7LEt+LemDg3qs009M
         FcaQ==
X-Gm-Message-State: AFuF++mfvtEi6XJkWiqvOkHqQRpYxwDij/EZ4Qy4ocWZ2XpqSrCm1nCD
	eTq4jYKvNGAdeuRAbShCDobh+oMZLdT/pgw/ZK/imZCRwnsdBL2giIwHg9ty2jj0296x5J8zd6a
	Xg6Fajg==
X-Gm-Gg: AR+sD10OHhOMUeT+6ljKKtzhj6xD4zcO6v/EM4epidVi1SncI5hr38BvMUg7FSUMHdA
	9EFlmVagR4VHorRYLbkhGxHDGMVzj9ln33oWNL3K1KWuQ8i5/t9MSk++eB8Dh9I6mD6X7nK45Aq
	B+43hMiBC+o+XKkRNGUDNy697vMkaDsXBf6Y01ye96jCrXSWsQDqli96X9q9IPXq7VLsfeyKHwZ
	GWyWOfGjmAjDQNgv1CLj6rvOZ19YGTuy5YJFvQurVci8mKJ9Y1QJ0i0pUAnH1uglBlxuSvaW+pv
	h57Qo6eno40EF7+pAcMkp5eB6JFx8CITarKxEqnPnPWyz1OgW36FSm6uMOOl1c0e5P1+J38eSeS
	DT4j4aTJ4XYFK4ylR5s6HO0ehRevI1Xt8WDT+LyGolhrWxKRBqDyicsfjItpm9za85He0Q8DjKy
	Mvvg4ihe/BZ0EFtu0ROQ6ia0yHaQS6nhq6n5XybJlKCAlvk4kNwF9BYo3xCl1FNLwOdUlcHfVZc
	fwFWuw/bJfEvoW0jjqDh/CU8xuXLmAPgz0MIz3omw7spgv7oMLd
X-Received: by 2002:a05:600c:870c:b0:499:dc34:bdc with SMTP id 5b1f17b1804b1-49b91c1c401mr75871115e9.1.1787900606073;
        Fri, 28 Aug 2026 00:03:26 -0700 (PDT)
Message-ID: <6e98181c-459c-4c45-b8c0-c427e3c0bbc8@suse.com>
Date: Fri, 28 Aug 2026 09:03:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 07/12] altp2m: address Misra 2.1 rule violation
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787900606-D6D4087B-D3067CFC/0/0
X-purgate-type: clean
X-purgate-size: 937

The stub altp2m_vcpu_idx() is recognized as "noreturn" function lacking
respective annotation (or having a return statement), which hence is deemed
unreachable code by Misra / Eclair. All call sites are guarded by
altp2m_active() checks, hence an inline function isn't needed. A
declaration will suffice, with call sites then getting DCE-d.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-generic/altp2m.h
+++ b/xen/include/asm-generic/altp2m.h
@@ -14,13 +14,8 @@ static inline bool altp2m_active(const s
     return false;
 }
 
-/* Alternate p2m VCPU */
-static inline unsigned int altp2m_vcpu_idx(const struct vcpu *v)
-{
-    /* Not implemented on GENERIC, should not be reached. */
-    BUG();
-    return 0;
-}
+/* Alternate p2m VCPU - placeholder on GENERIC */
+unsigned int altp2m_vcpu_idx(const struct vcpu *v);
 
 #endif /* __ASM_GENERIC_ALTP2M_H */
 



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:04:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:04:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401631.1637186 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqdC-0004yV-NH; Fri, 28 Aug 2026 07:04:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401631.1637186; Fri, 28 Aug 2026 07:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqdC-0004yO-KJ; Fri, 28 Aug 2026 07:04:06 +0000
Received: by outflank-mailman (input) for mailman id 1401631;
 Fri, 28 Aug 2026 07:04:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqdA-0004xw-KA
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:04:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqdA-00DmW4-0z
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:04:04 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9132df-2eae-0a2a0a5409dd-0a2a4508af0a-26
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:04:04 +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 <jbeulich@suse.com>)
 id 6a9132e3-f659-0a2a45080019-d155802ab58a-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:04:03 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-49557167508so5879625e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:04:03 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b497fa9c5sm103143025e9.4.2026.08.28.00.04.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:04:03 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900643; x=1788505443; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=DmF1sxJKk6keuGbs+Ea+dEobCZFX5puzwyTbL1N5ULM=;
        b=IUttZ1QqG7XhlILV0P+E3X+ePLpWRMh+3k6CuLDiJk1G7P/JryDnlSbPm3gaOWGWWT
         H53R5dVGpZUrVdEky9h/nywr+xNZUUTAby75qPeQIKezsezuWwVs2Dl7AKVRQazqqQbr
         By6/S0RNnG+p9tDslib6hqQi7baYfVsLD4gP2f7sBOyv65awszGN9MWqtXZzD4PX+E5j
         OeH4csFyxzvUWbpHAzFBZNxtKWQ9BN9yK74tB4vbx+sdL7AAKTkJ8CjkL671J4ujsRYQ
         wd31Mb0WAUnUAul7YYdUfD7RbPy44UUXA5mSfgSbEWQj9JBokmL6OS8huFmYFiEh1ox6
         W1pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900643; x=1788505443;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=DmF1sxJKk6keuGbs+Ea+dEobCZFX5puzwyTbL1N5ULM=;
        b=UB83/OZIbifbYR1fNmiibIw7oyszRC50SnHbNehdERGit4lC3Lic+4S0Do11Viy6vB
         8jC7GbO/e+ibNn0F574ksFJCvEuq0KsDc7dOdv2jUZ3qlaa+tONWhD8ojUFjwSkBZNMJ
         w26zS3xs6sw6M+uTaPHlh7k0Y2u24gKDIc0UUfYC02eSKOf5iUpNtVU5hb0WETQhp/RY
         FsUZ1WOxDI0nTM+EvxArmKsnJB8oaCJUxxwa5k5fob32Z3w4Hz40cvxEqAl1WqgD/I48
         /EnZYuTr4p8kD+wAr5AnCefjFk6Q7sniVnXYizViT+13QIKOWQafGxOg5BP2sztkUOo1
         1U9g==
X-Gm-Message-State: AFuF++nj27CF05/xzphsi3WrB+JEBoD6rtNZZiVWaZQ98ThqYx5EWMMO
	Fh4r6tNL7fekmHWfiktGA62hkMd90NIdlf3Wcr7m4vaxg/o04RkAwJUBMh2wA0KI+oLXxhrYbmp
	9B163oA==
X-Gm-Gg: AR+sD11m4AQIaOvBP6N65FjFek1mxSvLjI4A2xJRWozTWWS34qDDsQA+g1eoTnUGIVN
	am0/e00B4Pox2kM9D98zxVekLAAsImO0iPcqpuCC/TqTQTM2COT/9NTvCr8w92wfWe0TUFEfroR
	ub5Vz0+nG8bnhYcPARQkEX+ZAXK3Ss94JJ70YJ0a8Pt3c1t62sAigtIDOroalMUU43Z3SM8jj4E
	wz9Ve9EN14JUoHJ0dAHFNUdol97o3XUAyfdwRnvHXynZClq62hQUimLFm6ZSOJoSCB1Ocl1lsYi
	wm/0MkY6DxJpClmQOGVA2RjvO7yE3U4nD4kzGSz6Lor8Qj/bMGSfZ5Vm/CaaSCZNm02l+tazQ6U
	9y8FaT05mkHvduvgvskGkBtDOq4kgKOheNjXOJbCs5hejoFMcnvzmozX5TnXxU2XcB52zSuiqNu
	BJX/XPJyrczlnOxUXzHaJvLSAjkM9UcDnM6kVDLGguNKuFupQo4HUCJuB6xBtwj0PiB0dzhblvb
	YTVGj8NHMh3aGkO8FVI/RUz/WymnO9KDlCJSWTbce8Y+0RPESUGZoHF6LjSfKU=
X-Received: by 2002:a05:600c:4594:b0:49b:4d64:bbc4 with SMTP id 5b1f17b1804b1-49b91c2f990mr57810185e9.8.1787900643344;
        Fri, 28 Aug 2026 00:04:03 -0700 (PDT)
Message-ID: <afa5c348-744a-4a4b-8b00-2971ca3376cd@suse.com>
Date: Fri, 28 Aug 2026 09:04:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 08/12] Arm/GIC: add noreturn in a few more places
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>, Julien Grall
 <julien@xen.org>, Stefano Stabellini <sstabellini@kernel.org>,
 Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1787900643-D735D87B-83B1FCEB/0/0
X-purgate-type: clean
X-purgate-size: 2030

LPI related functions having just BUG() in them are disliked by Misra /
Eclair, as long as they don't also have a noreturn attribute.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
>From its description "Unreachability caused by calls to the following
functions or macros is deliberate and there is no risk of code being
unexpectedly left out." I would have expected the respective entry in
deviations.ecl to cover all of these cases, but clearly that isn't the
case.

Of course having noreturn on functions returning non-void is somewhat odd.

--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1315,7 +1315,7 @@ static int __init gicv2_init(void)
     return 0;
 }
 
-static void gicv2_do_LPI(unsigned int lpi)
+static void noreturn gicv2_do_LPI(unsigned int lpi)
 {
     /* No LPIs in a GICv2 */
     BUG();
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -229,7 +229,7 @@ static inline unsigned int vgic_v3_its_c
     return 0;
 }
 
-static inline void gicv3_do_LPI(unsigned int lpi)
+static inline void noreturn gicv3_do_LPI(unsigned int lpi)
 {
     /* We don't enable LPIs without an ITS. */
     BUG();
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -718,14 +718,15 @@ static void vgic_v2_domain_free(struct d
     /* Nothing to be cleanup for this driver */
 }
 
-static struct pending_irq *vgic_v2_lpi_to_pending(struct domain *d,
-                                                  unsigned int vlpi)
+static struct pending_irq *noreturn vgic_v2_lpi_to_pending(struct domain *d,
+                                                           unsigned int vlpi)
 {
     /* Dummy function, no LPIs on a VGICv2. */
     BUG();
 }
 
-static int vgic_v2_lpi_get_priority(struct domain *d, unsigned int vlpi)
+static int noreturn vgic_v2_lpi_get_priority(struct domain *d,
+                                             unsigned int vlpi)
 {
     /* Dummy function, no LPIs on a VGICv2. */
     BUG();



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:04:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:04:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401637.1637195 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqdW-0005RD-VX; Fri, 28 Aug 2026 07:04:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401637.1637195; Fri, 28 Aug 2026 07:04:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqdW-0005Qw-Ru; Fri, 28 Aug 2026 07:04:26 +0000
Received: by outflank-mailman (input) for mailman id 1401637;
 Fri, 28 Aug 2026 07:04:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1wzqdV-0005Ok-QL
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:04:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqdV-0016ik-7A
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:04:25 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a9132ef-2eae-0a2a0a5409dd-0a2a450c8c2a-40
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:04:24 +0200
Received: from [52.101.62.56]
 (helo=DM5PR21CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a9132f7-f479-0a2a450c0019-34653e38936a-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:04:24 +0200
Received: from MW4PR03CA0152.namprd03.prod.outlook.com (2603:10b6:303:8d::7)
 by SA1PR12MB5672.namprd12.prod.outlook.com (2603:10b6:806:23c::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.9; Fri, 28 Aug
 2026 07:04:16 +0000
Received: from MWH0EPF000C618B.namprd02.prod.outlook.com
 (2603:10b6:303:8d:cafe::3a) by MW4PR03CA0152.outlook.office365.com
 (2603:10b6:303:8d::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.10 via Frontend Transport; Fri,
 28 Aug 2026 07:04:16 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 MWH0EPF000C618B.mail.protection.outlook.com (10.167.249.123) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.382.8 via Frontend Transport; Fri, 28 Aug 2026 07:04:16 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 28 Aug
 2026 02:04:15 -0500
Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Fri, 28 Aug 2026 02:04:14 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EkEiSA4DoeE90mFj5DYvji+OTi7HA/WQbjpQzDH1Y6/Z7QTcQ1pw9V+rF2XHfg3Yna38MKmlRiyqzcHIMRu1xiXcGdgcg7pZMBJi4f7PHlYps6OWDrsvWjYPhcahKSrn99rHzQYg3V2xbV4L54K1KDNng+9tO/9uAZ7W3z2AYFT9QFosrjUv0eBie+7WIHUtAIbcg3GUQyfliKc/GwX0PQnQwy42NTn4jLJXUMjI1Tbr1o1tKbj7hFewtjNU7aOsp+BVh28SugbM6yn4ARsC5r1pz8FWXU4NxqrP1ORiMOJkqv7PqsQF3lhdooLXHi33MG0IeMQTfbPhProrRaGC+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=v0bpya8ogYaEdMCGp4/9wWyRij88nIkK5lXO2xMacDo=;
 b=HjQVfrOWYjNzR7eXWnPv+FM4r+Qgw8UtRsNbQhPkysk76OJ5/oVUDFCOZVu8sN14PoIqxCcFQg+ZRm9kqyOhGmXEwUos8XyuQnJl3kgRLrZd4KjtYVQWcKmRZUc+bDUjZWaL2bj/RdSkpeJmPlPKxc5B4RhBEbFH+qhDmK0sDoNv8c4cISSFJyWT3oFB/b6hR9+JIPCDmQGRr6vRvlqJ0goIqqNjK17JgdkeHypc7sMk6vgJDlB6gBmmcdMmPBnT+ixXI90Dt56xC6sU+il9iQdsqzwjtkOe9LUdmqPEx9VF7SzrRD/XuTOM+/KTyWl+ruyy6fDe2nRm57rK3Ot70g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=v0bpya8ogYaEdMCGp4/9wWyRij88nIkK5lXO2xMacDo=;
 b=0admj/owgCXekgLoKr2ze6Lhj8X8Aq2hidVuw3xNicxZheUWUFOx7RnHYueNTJXqfSN8B4OHxCupyWMN768+6OY6AztL3as7FLNYAvUcP4R0rihextIDUwDQfLkDog5W68nMUeXRJSPOmrW9zsS+MXVX7fsSMQu19pPFjx/P65E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Michal Orzel <michal.orzel@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Andrew Cooper <andrew.cooper3@citrix.com>, Stefano Stabellini
	<sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand Marquis
	<bertrand.marquis@arm.com>, Michal Orzel <michal.orzel@amd.com>, "Volodymyr
 Babchuk" <Volodymyr_Babchuk@epam.com>
Subject: [PATCH v2] ARM/vgic: Clean up vgic_v{2,3}_setup_hw()
Date: Fri, 28 Aug 2026 09:04:09 +0200
Message-ID: <20260828070409.106935-1-michal.orzel@amd.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000C618B:EE_|SA1PR12MB5672:EE_
X-MS-Office365-Filtering-Correlation-Id: c4ba58b3-8ec3-4724-879f-08df04d292f4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700016|376014|1800799024|23010399003|56012099006|10067099003|11063799006|18002099003;
X-Microsoft-Antispam-Message-Info:
	GOtF4EQie1H6NYsOCgKuLhCQOccxOXUqPM4j7oL7V483apNYdNPgMONZjghGMzLWHPmIJedVKGPR0mAVCKeaVV0jX+I0ZrjMiN+vEDu3r2qymPFHDNg+XVh0kXRMfKm+UFixsKxpb42+LjSq0op8sIyoK/Cd9uPm3jovUgXNVjBHQ5HjnOtZWWdJsRW3wyc1iZOzaw2zocekmCU3PEh9D9KbQusAOxRHmsBEsezlRvvvqeEYwVuKQe4YBw0qTsFEEcvKdgn56nseGGPvzWAOM1PE5PzNayU/3UZrczh7eR4Y5ltiFPLHEWFRXkaXecqgic5xaec3ORktX2Qg+C4hiTNDy7RIEOeryJZWSTWsXff6FktuTWCQCimLWbwkMDnKUPMi3FVxdvh8qoDplBNHgpMzNgoVtl8/jJW39jh9aeVeXbjoFjsDMHfIf3KdObPAOSyvmiR5NbcRYDm87CZpbyxVTwHybKHdprY81rMTpTKLRUzhg1axDk6Vpx04vK3EB0MThgkdpYmfMQU7ltsOrHlUIWuf+FSGJ5C04nF1T2jvoqmR0i/vZVrXagrgC3UPo622dZpwTvxcWGr9u8LSwzK6XKxWiauRemT0fkaHHw5GmaijY3gx9PWbkJQRucl66IT7MKoeLklFaQAAkMgX++pI1Q5P/mDhrxoC+CBQGO5OFWVZfJc82jQXn00pWi2sL+GXJ/WbRHQyGJpyZfAY/A==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(376014)(1800799024)(23010399003)(56012099006)(10067099003)(11063799006)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	eYgwgacmIKLNHs9NFPS/U9V+Qie2+olemviKv9TfeerUsqe0eU8olEqhjpHFb8mFhWpqDTy4qLIRobNRBhi3Oj1UuW4Pi/Htv1gw4qSWTA3kOJsyy9B5F97z2v0WZTKauzpO5J9EgBIvXoAZIKiv9PR9O4bEOutVjDr2Rfzxoa/vnZpHV2tDqFEp5ZSZTEiR7a//JFzUg/IYce33c3LaiD8URWbxVF4kU2b4azuwha0yTSdDKiMw89rzXkizWNPaPyAxQTNWKPjy02ouOhY8leE7WlLk0M3LglNhuaOkj29S5zQSTpQXM/UwN0NorA/abk6oj1VyBXJfr2UMQTa64w2Shr/ne1mUk5lz8hc8sCuNqnRGjRkAwQidU21reM7ak/N+zlwHzfHhiDYlMpcBnc74WnCd2IMvIKLqwdTSXyiF1K5f7MWdFlek3BgKfTUJ
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 07:04:16.3613
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c4ba58b3-8ec3-4724-879f-08df04d292f4
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000C618B.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB5672
X-purgate-ID: tlsNG-d25034/1787900664-77ED2A5B-9AB31B0E/0/0
X-purgate-type: clean
X-purgate-size: 4662

From: Andrew Cooper <andrew.cooper3@citrix.com>

vgic_v{2,3}_setup_hw()'s callers are __init, so they should be too.
vgic_v{2,3}_hw and gic_v2_hw_data are written once during init and
unmodified thereafter, so make them __ro_after_init.  Reposition
'bool enabled' in these structures to fit in the tail padding, removing
8 bytes from their size when paddr_t is 8B.

While at it, drop dead vgic_v3_setup_hw() dummy implementation
from vgic/vgic.c. GICV3 depends on !NEW_VGIC.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v2 (Michal):
 - take Andrew's v1 patch and extend the changes to vGICv3 and new vGICv2
---
 xen/arch/arm/vgic-v2.c      |  8 ++++----
 xen/arch/arm/vgic-v3.c      | 11 +++++------
 xen/arch/arm/vgic/vgic-v2.c |  8 ++++----
 xen/arch/arm/vgic/vgic.c    | 11 -----------
 4 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 642407fd5b05..3fa8cdeeab14 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -25,7 +25,6 @@
 #include <asm/vreg.h>
 
 static struct {
-    bool enabled;
     /* Distributor interface address */
     paddr_t dbase;
     /* CPU interface address & size */
@@ -36,10 +35,11 @@ static struct {
 
     /* Offset to add to get an 8kB contiguous region if GIC is aliased */
     uint32_t aliased_offset;
-} vgic_v2_hw;
+    bool enabled;
+} vgic_v2_hw __ro_after_init;
 
-void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
-                      paddr_t vbase, uint32_t aliased_offset)
+void __init vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
+                             paddr_t vbase, uint32_t aliased_offset)
 {
     vgic_v2_hw.enabled = true;
     vgic_v2_hw.dbase = dbase;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c01cc596d593..16e9d0cbad03 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -44,19 +44,18 @@
 #define VGICD_CTLR_DEFAULT  (GICD_CTLR_ARE_NS)
 
 static struct {
-    bool enabled;
     /* Distributor interface address */
     paddr_t dbase;
     /* Re-distributor regions */
     unsigned int nr_rdist_regions;
     const struct rdist_region *regions;
     unsigned int intid_bits;  /* Number of interrupt ID bits */
-} vgic_v3_hw;
+    bool enabled;
+} vgic_v3_hw __ro_after_init;
 
-void vgic_v3_setup_hw(paddr_t dbase,
-                      unsigned int nr_rdist_regions,
-                      const struct rdist_region *regions,
-                      unsigned int intid_bits)
+void __init vgic_v3_setup_hw(paddr_t dbase, unsigned int nr_rdist_regions,
+                             const struct rdist_region *regions,
+                             unsigned int intid_bits)
 {
     vgic_v3_hw.enabled = true;
     vgic_v3_hw.dbase = dbase;
diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index 6a558089c522..06fa36545355 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -24,7 +24,6 @@
 #include "vgic.h"
 
 static struct {
-    bool enabled;
     paddr_t dbase;          /* Distributor interface address */
     paddr_t cbase;          /* CPU interface address & size */
     paddr_t csize;
@@ -32,10 +31,11 @@ static struct {
 
     /* Offset to add to get an 8kB contiguous region if GIC is aliased */
     uint32_t aliased_offset;
-} gic_v2_hw_data;
+    bool enabled;
+} gic_v2_hw_data __ro_after_init;
 
-void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
-                      paddr_t vbase, uint32_t aliased_offset)
+void __init vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
+                             paddr_t vbase, uint32_t aliased_offset)
 {
     gic_v2_hw_data.enabled = true;
     gic_v2_hw_data.dbase = dbase;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index b2c0e1873ace..ba029b8a3bbf 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -964,17 +964,6 @@ unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version)
     }
 }
 
-#ifdef CONFIG_GICV3
-/* Dummy implementation to allow building without actual vGICv3 support. */
-void vgic_v3_setup_hw(paddr_t dbase,
-                      unsigned int nr_rdist_regions,
-                      const struct rdist_region *regions,
-                      unsigned int intid_bits)
-{
-    panic("New VGIC implementation does not yet support GICv3\n");
-}
-#endif
-
 /*
  * Local variables:
  * mode: C
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:04:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:04:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401640.1637205 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqdj-0005qD-9v; Fri, 28 Aug 2026 07:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401640.1637205; Fri, 28 Aug 2026 07:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqdj-0005q6-6X; Fri, 28 Aug 2026 07:04:39 +0000
Received: by outflank-mailman (input) for mailman id 1401640;
 Fri, 28 Aug 2026 07:04:38 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqdh-0005o5-Rj
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:04:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqdh-00DmdV-8H
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:04:37 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a9132f4-8faa-0a2a0a5109dd-0a2a4501e002-44
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:04:37 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913305-5984-0a2a45010019-d155802de834-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:04:37 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49b8be0409fso2935395e9.2
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:04:37 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49c44feb966sm4170955e9.6.2026.08.28.00.04.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:04:36 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900677; x=1788505477; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=m/fuBmCCJ5a1zaL+2kWjQQLEuHgPrkNDDGBZHEQWcC0=;
        b=ENPJ3ZH5ZEz8gzJ8U0LVuJfR9/0Zz5UJLfsK9x7sBR4pteT+SQ9q7pYjQTVi9nAVnp
         EiYQfRivPyeDg/31vMlYU9SyBqO6EOaqbtipvgr/KEFxANJAVksGwMAZR7Wm2x4O4T8D
         qBzvnR/o8rDx+6eWAvFlYyWiqHJDBElb1SGL8BT8Je4efZWRJknHx+VIWIIc76DFqLw+
         tOqsRKKHBPSit85QaQK9imM7WpHk+fJt3d/w6KK5J7cDBLnhRn2E9K0Prie8aiWu5VmU
         aBxsz332LUw/fLq1LCbdCfEdZbdI2t4OoWd6J6sEK3E/EHa0V0e+fUfVn05+YQygdXCc
         89mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900677; x=1788505477;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=m/fuBmCCJ5a1zaL+2kWjQQLEuHgPrkNDDGBZHEQWcC0=;
        b=UAA+vUSCnzkTsJZ+DQLz/t/3dQrtAT4h75Opv79C2HnUMel3PnDYK77XX+9k1Wd+wF
         CUHPQz50pSznQyTPt9DRiNm4RcwOIqLpTf4CGL/Y8hhMS3gRh04w7hyPIhKiCJnKdQTS
         glLEChsc4J3tmfoj6dmhx50WQOW8GJpCUfDuZ14DU7IvFPbDSnFa/ni4koW1Vh0i630s
         bV2SUxZmj/6POvapwOaQD/mKjuyhRbdzCOPRXU39ioj7oftKxFfhFEJ0gy+XUIdHFaGC
         IrkCofPl9NmQyGdJqAgynGAmAaGFBBYF8UXQQNbdysNDi1fLf50OuGVeyxp4X9DcBlHh
         Mdow==
X-Gm-Message-State: AFuF++mq26poplI5WwwQymMBeN9Mbf9oNIU1pKYU5kUMjlPYrxQ5mUIs
	lkXmzeqSo3nh9K621PpDqwQ2yjApMEo3sMs0spEwV2iRLy9qS3272JzKSvqDQfznUVc27JGvRZS
	n/OS6gQ==
X-Gm-Gg: AR+sD121KTJHVRaZ1+ZJgEr4hr3As463Q2EgkKTdvDXp6HRZyWTX3J4uZF+FtSiPzHw
	PBsYXmK2v1VKcZHIqG+000I4cQgRH4eUG0SyE1VWZt7GB7qYTz4iMRoqrDH6NBvo64zltTPlce3
	K5MgydcUQDO27DtxvZRKF8t0ibFXZVykCIJNaUmZ3nOMKdbFOWqm8e4NzVToFkGTBMJBW43EVUs
	C/xXRL+tH3kkLc6ai5YwYv2xc+yEbRna9tauuJpOhwYmz2HsaBOExGjdtkAsK3o9G8ANy4Ihbl7
	zhhVkuRT4xBwhDLxn0PiVHIfn6sEF1zVSJ+pi089zVwxbz6AEgyJ000Xr8VYPxoxEzsnIe5V1NX
	8vpGQ2MhYshb7Vxg+oq0BqQglcAan4V1xTQ0iZj7UM3sCx7Vy8Z9Wy+CW4MsMhdZrx2Ul4NiX0f
	8A/1jRO27b2q+kDP2+fWp+wmkghVoxBe/NvnXgMiU6x4jkvDr0SOcM5AEZ2UZS6UwoMI9UV9U9I
	d5tR832Q0lPpt9pnORJWaGvfj0tucJcTVHd3nMYqlrLfRt6GFpWhP0fTPKyh/w=
X-Received: by 2002:a05:600c:6215:b0:499:5a50:b022 with SMTP id 5b1f17b1804b1-49b91c1bb18mr67259705e9.3.1787900676675;
        Fri, 28 Aug 2026 00:04:36 -0700 (PDT)
Message-ID: <06c5efc0-e130-417f-8333-b8eacd1c6d77@suse.com>
Date: Fri, 28 Aug 2026 09:04:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 09/12] Eclair: deviate BUILD_ERROR() wrt rule 2.1 and
 introduce variants
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1787900677-1F86F757-E8D1E3E7/0/0
X-purgate-type: clean
X-purgate-size: 2567

BUILD_ERROR() is even stronger a guard than assertions in general, and
ASSERT_UNREACHABLE() (or BUG()) in particular. Deviate it just like those
to allow use for marking unreachable portions of code.

In some cases code being unreachable is dependent upon configuration.
Introduce two variants, as constructs like

    if ( IS_ENABLED(CONFIG_...) )
        BUILD_ERROR("...");

results in the if() still being reported as unreachable. Sadly these two
new macros introduce a new 20.12 violation each, which hence also needs
deviating.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -19,6 +19,7 @@ Constant expressions and unreachable bra
 
 -doc_begin="Unreachability inside an ASSERT_UNREACHABLE() and analogous macro calls is deliberate and safe."
 -config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"}
+-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(^BUILD_ERROR(|_IF(|_NOT))$))))"}
 -doc_end
 
 -doc_begin="The asm-offset files are not linked deliberately, since they are used to generate definitions for asm modules."
@@ -667,6 +668,7 @@ deliberate."
 to the # or ## operators within the following macros are deliberate, to provide
 useful diagnostic messages to the user."
 -config=MC3A2.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"}
+-config=MC3A2.R20.12,macros+={deliberate, "^BUILD_ERROR(|_IF(|_NOT))$"}
 -doc_end
 
 -doc_begin="The helper macro GENERATE_CASE may use a macro parameter for ordinary
--- a/xen/include/xen/macros.h
+++ b/xen/include/xen/macros.h
@@ -64,6 +64,21 @@
  */
 #define BUILD_ERROR(msg) asm ( ".error \"" msg "\"" )
 
+/*
+ * Like above, but conditional upon @cfg (not) being enabled.  @cfg must be
+ * suitable to pass to IS_ENABLED().
+ */
+#define BUILD_ERROR_IF(cfg)                               \
+    (IS_ENABLED(cfg)                                      \
+     ? ({ BUILD_ERROR( #cfg " unexpectedly enabled"); })  \
+     : (void)0)
+
+#define BUILD_ERROR_IF_NOT(cfg)                           \
+    (!IS_ENABLED(cfg)                                     \
+     ? ({ BUILD_ERROR( #cfg " unexpectedly disabled"); }) \
+     : (void)0)
+
+
 /* Hide a value from the optimiser. */
 #define HIDE(x)                                 \
     ({                                          \



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:05:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:05:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401652.1637214 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqeJ-0006ch-HD; Fri, 28 Aug 2026 07:05:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401652.1637214; Fri, 28 Aug 2026 07:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqeJ-0006ca-ER; Fri, 28 Aug 2026 07:05:15 +0000
Received: by outflank-mailman (input) for mailman id 1401652;
 Fri, 28 Aug 2026 07:05:13 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqeH-0006bD-RX
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:05:13 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqeH-006Opq-8D
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:05:13 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913324-8faa-0a2a0a5109dd-0a2a450bc0ba-20
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:05:13 +0200
Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913329-b7e8-0a2a450b0019-d1558029f05f-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:05:13 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so5924255e9.2
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:05:13 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b4942298fsm106061005e9.1.2026.08.28.00.05.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:05:12 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900713; x=1788505513; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=TWfdIfEKkF0sERNM/mSdQ9IUQZ7pPCDfv2hRzvZW3AU=;
        b=O/6PatNDn6O5s2IuJZaIzuY2bwpgNcSPxSZCEeNClu/19wkqaR8r757nZkgznBSYrn
         mtJVtUiAHgZ9AHOiVIZ/1oN0iTVBZT0nN0x+nwVIcGOvdvk+9SFfLkwxZfDBDbE9ee5a
         J/Cql7JKs1rtMysvBpuTJPo3SQNpRiLfgkX/ZBoTcCs+KP6Yj8Kzcu1nqo3hxamCC2pG
         srQlgH5w64mlsbfpG8P1waN3jr4eefdJnyvfQ26+doEsluSbECW1TPo1Tw/Ha/4yQxse
         qACnPd3dAVBOYUbZesoF0JNKgXZV/nppSn4LZ+6hvAWK/6blkLNAHuetrD9jpScm93qE
         bn1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900713; x=1788505513;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=TWfdIfEKkF0sERNM/mSdQ9IUQZ7pPCDfv2hRzvZW3AU=;
        b=Bjli/3XIeyMk3Zhmbz6Z/vPRQjDVaNULC6vSGSCS7WVN3XAjfBwK8fLLCDK7VnNkca
         ul+Dvu4onJaIahuuRu0DGb0iecLXdCk1tFq0m2pu28krbcAcSy2H/GNJyr5OhwwpoHUh
         HfkF5aRth3Uq5MxGmeSMQx7EUwdGJ/AVRVWhXc0FtlezfA/ZzYV4xDacmMvN1X6VYxPu
         vDUcCpAJc73x9mwBh4ziNwJ9CsMlI32feOdNpqfTB3EYu14mHjFdVJuvE3IZM+RLGGP+
         /ktk8tjBKnj2yKsFNpWuOnQ21V7sE6Sq97/U7mpIsfX/DxVF3/7HApDo/WMsHD/g95gG
         UNjg==
X-Gm-Message-State: AFuF++nrC3PozNFkfVh+Q6D9sC+jX1M+ODOI/jSSOoDrgK/RVy2ZFuKL
	uxo3TFyH8euL9WHoD/2ZKhEtFbDaSygi9yKJ//zpxz1NS/Xpv4TKflDq57xUwuPlwcMVE7kY8hU
	rI1xElQ==
X-Gm-Gg: AR+sD10F1FIHF+7jc9mdIksi6ABrWxUyWnyE/SwL3FqYX1FYDuGkDlqQqIQDQj7MtFc
	OjC9hrhQssVSXobdmmLRs1iFGxLGaWKMKqsL5om5mIZ+T7318/RYcKlkyDLlmJRPjq1RX62WTcO
	VWBbCJ+vQWU3YYUkHGnAker7nkzJdI6N3Va/0wBKq2xx8a1VmGE/VIPx0WzoYwvpRizFq1cdD4O
	oVDkWszJe1/QGsEuqE2dCWmGr934kU2mZrM2MZTglLPHm6M1BRMfRuEGrRIxkPvo1+uzp9Sh5h8
	RBCrCXFpVgrja7iYyKHz7UliRVaqlSwLErY09O3SmD/0fFjosPZ1KAPF5RD/B2UaIp6DXE1tH7U
	1Spf3SbZPWdKy6GaMe8hot4cvQHsgGLuj8f+juIPhQVI4DaJGDdE2sq6Znuv5tMFZZFarvfLwN0
	OwkPXVLYLeMGrLiFYCxhE0mdlJbEnFEdWYUIF9g9fPz11irFYDshxKV4vnCjS25G1wDhjp54TyM
	m1lPBgC9UmVMFluauaeaZz9FjxYFxm2yf8QbVwksqKXxddrb+dghg==
X-Received: by 2002:a05:600c:a55:b0:499:60bf:c6f7 with SMTP id 5b1f17b1804b1-49b91c4cc2cmr63870935e9.13.1787900712683;
        Fri, 28 Aug 2026 00:05:12 -0700 (PDT)
Message-ID: <de8eb6ec-b830-47c2-95e7-e0b689f05cad@suse.com>
Date: Fri, 28 Aug 2026 09:05:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 10/12] PCI/physdev: address Misra 2.1 rule violation
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787900713-ABAD09EA-59BF5E21/0/0
X-purgate-type: clean
X-purgate-size: 620

Cases 0..3 are handled, and a 2-bit mask is applied to the switch()
expression. Therefore the default: case is reported unreachable by Eclair.
Insert BUILD_ERROR() to annotate this for Eclair.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/pci/physdev.c
+++ b/xen/drivers/pci/physdev.c
@@ -114,7 +114,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_
             break;
 
         default:
-            ret = -EINVAL;
+            BUILD_ERROR("PCI_DEVICE_RESET_* inconsistency");
             break;
         }
         write_unlock(&pdev->domain->pci_lock);



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:05:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:05:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401662.1637223 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqep-0007CG-PU; Fri, 28 Aug 2026 07:05:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401662.1637223; Fri, 28 Aug 2026 07:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqep-0007C5-M0; Fri, 28 Aug 2026 07:05:47 +0000
Received: by outflank-mailman (input) for mailman id 1401662;
 Fri, 28 Aug 2026 07:05:46 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqeo-0007Af-4e
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:05:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqen-006PDC-Hf
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:05:45 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913343-bab6-0a2a0a5309dd-0a2a4504da3e-32
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:05:45 +0200
Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913349-b57f-0a2a45040019-d155802cad37-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:05:45 +0200
Received: by mail-wm1-f44.google.com with SMTP id
 5b1f17b1804b1-49b0dd3c9a0so4100305e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:05:45 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b94dd2517sm27274095e9.7.2026.08.28.00.05.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:05:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900745; x=1788505545; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=xeBcqU4ONhlQiamT59WM+Tt5fXRzCZEnMYHTumLui88=;
        b=e5HbokPhDqYiFyMWxgW5GjIiHOt0T4Nu8qx4WEzVJhXFJWiJ3dQB/uR9kCo820PR4H
         KCcC3sDIl06ro3YqW/lZZSpxlEtAeRgdNKmcxa7WWFMyM+Ed+RF5H3I2kFVg4q2vqrQ7
         leNFl51pv2krAbPY/GqzBm5N5Dh/x7kNs4w+fFCxTkJ+hiiG75DqqTzu9e88YObxg0dq
         tMcbDm+J4Q3+OB6e0Axu6Iu60Twzav04/8Lnp2Uu9hgfZLd/7dmFO1b6hutT2ErjVQpO
         PdmnJ4eCojO820qGlPKLaSSJJTOUNVE5/ciDOgF9KdgONH56hmCGk/6RQHceofeMwZty
         neJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900745; x=1788505545;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=xeBcqU4ONhlQiamT59WM+Tt5fXRzCZEnMYHTumLui88=;
        b=MfHHNoXHtviE+sua24BJhunkmcY3aILTNWs3hacd5tgDHpwZGlH1t0A/FQ/6I/aHie
         CcZDMYkaD2CcUzO0j29phzEPqvTrqPStaHifMA4aqcCE3P6u9fUdpRhzqat6m69ViVNy
         JEZDMD6VoDipGMjrfjjTdWetLRtm1xcrKyLFoyKfiZzbPPzWjJgO77wMyP7KFPecI13z
         5wpsYKqNkeZk+hdoT3s/gxlOfH48qbjl6K5BGzw5uX0pXEi0N2C1Cb+CAX5+NkK4gzon
         IXNFkR1/aly16u0zHIcu+IkAzNbpIOSFgSeZmHWszY20q8SoIeupk1zLcgupWQMfn4yM
         1PbQ==
X-Gm-Message-State: AFuF++ne9CgUWzT3cAoyHHbo3anyM4l+6qoIT8TgxpahbWoG2Qr40Es3
	fIV6otpxJ2FKJdiN6qECo1faVwSxJmt4s9iR6qZTHkp0DIx51+DRCa2U7qzq7W1nm32KUG0JZ8w
	Ax1TTPg==
X-Gm-Gg: AR+sD12JxFLyzGBFgx4rzGyAKocS17Pp1xEey4V8FM4hJSx9oBPLgLfBcsQpsI17eka
	W21Lad8VtEC/FgDzXLEDGTmPpQyE1Dl7y3GP4v5iiXAi5+7791m8YB8YiU6kwl2BBA2EA5p8taJ
	tciqE5g22Owen5yzBIw1eWRPt6kuXrysJF2CHc29Mh9LhVBcnDEL1toNbhMXVkVl9AQ/4rXmJlo
	6SXbBIOnbnO6xBiURrpvFwNPMuaKT6qhpmWSd8RwPmf0PN91IiyzToXbgwxsVCAJFlWmOihw7/E
	ZGEwHSTNw31Dc1Rm+z8ODu0xtsdTi7T38274OOWsta46fZqcf2SrT4ze8iHEVTIPC0aU+iZTnAg
	LS15lSpf4oVh6jMBjuZMpC5MMj81B3NHqPCq+zuG3XInRrGCSd5rAT45TOywQJLoFd0wuVtVfrD
	BWr/2y/HdMTkjJhpFDfHIHZj6Y5ygX8HsO08sTAfgvF141KuhXlYx7l4PpXrWIANRsKyzFWt5jz
	8bAKEmfV6Jce6Z6wJxxJxbO4GUh11Gja4Kg8vpNYlF+wsL+nZ+F
X-Received: by 2002:a05:600c:1f8f:b0:499:b65d:1250 with SMTP id 5b1f17b1804b1-49b91c1fc4bmr44557995e9.2.1787900744936;
        Fri, 28 Aug 2026 00:05:44 -0700 (PDT)
Message-ID: <65330fe2-0a0d-4b70-a647-27290d0041e0@suse.com>
Date: Fri, 28 Aug 2026 09:05:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 11/12] x86/HVM: address Misra 2.1 rule violations
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787900745-52AC8B50-FBE8B311/0/0
X-purgate-type: clean
X-purgate-size: 884

In hvm_set_cr3() the "bad_cr3" label is reachable only with
SHADOW_PAGING=y; the code being there is therefore a Misra rule 2.1
(unreachable code) violation when SHADOW_PAGING=n.

Similarly code past the initial switch() in hvm_debug_op() is reachable
only when CONFIG_INTEL_VMX=y.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2455,6 +2455,7 @@ int hvm_set_cr3(unsigned long value, boo
     return X86EMUL_OKAY;
 
  bad_cr3:
+    BUILD_ERROR_IF_NOT(CONFIG_SHADOW_PAGING);
     gdprintk(XENLOG_ERR, "Invalid CR3\n");
     domain_crash(currd);
     return X86EMUL_UNHANDLEABLE;
@@ -5201,6 +5202,8 @@ int hvm_debug_op(struct vcpu *v, int32_t
             return -ENOSYS;
     }
 
+    BUILD_ERROR_IF_NOT(CONFIG_INTEL_VMX);
+
     vcpu_pause(v);
 
     switch ( op )



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:06:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:06:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401668.1637231 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqfQ-0007lf-1E; Fri, 28 Aug 2026 07:06:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401668.1637231; Fri, 28 Aug 2026 07:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqfP-0007lY-Um; Fri, 28 Aug 2026 07:06:23 +0000
Received: by outflank-mailman (input) for mailman id 1401668;
 Fri, 28 Aug 2026 07:06:22 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqfO-0007kD-Iw
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:06:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqfN-00BTdK-Vn
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:06:21 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91336b-e002-0a2a0a5209dd-0a2a4502a99c-14
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:06:21 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91336d-6ca4-0a2a45020019-d155dd31d490-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:06:21 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-47f93b2fe4cso231934f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:06:21 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbab3fdbsm1690444f8f.6.2026.08.28.00.06.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:06:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787900781; x=1788505581; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:from:to:cc:subject:date:message-id
         :reply-to:content-type;
        bh=fQitUjUUG5fOaprIaKXCQa+mw1Of9Q5sRiQtWfrJUBc=;
        b=OVnbCOgdY3+MxVxinoEy1+MMYEA7B2eXRPgXg4iw92hIf4sfT/YtzjhxsMZpkRtSHi
         8rIigWonQqiuHBhUTr4Ro2tq5nDfadyWMigtgXJ/CsQIcq20kBDfHmp/lr7Xryjgftzs
         aLmpQVQKhM0TMIpBFFRaJK/gRX0Hj+3sorORaKAGNnOzOVtriogMTrhvbb3pogim3+YH
         LybBsk3Yw0ypYOTi75NRUBACSPdBSoDXa+NU3OKsny4n2qJ4NOdbSeN28pSZJ3y/T0qr
         VF4IGLDZ0/oqPOVpF4d/HvYnDMl18nNV9c6sKFWZ5Na4WFNQvKa4F6nPZHMkI2qA/PO8
         +8OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787900781; x=1788505581;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt
         :content-language:references:cc:to:from:subject:user-agent
         :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=fQitUjUUG5fOaprIaKXCQa+mw1Of9Q5sRiQtWfrJUBc=;
        b=ffSBGlvhmKWjNojzpp/pMKi1dZ/UqCPT4gyuXcUUnHP5haQ2hiQ0huZN65toOYRI3t
         nm5Jp6QdSD7VP77R7septdNWui8IqKSVQIWPOCyc0CzdVZIxEiYBc7THM1JyhNHlyUc1
         6cdKNnCoYmbgNlfuY2Ai++B68/SU8Uexe1rGUVWK34GnKc0Vv8Dit7lYhsvRruPhThQu
         XM35HzTQyOSh+BmieXQUfpKxR2BhvX6uqPl0MMJme0vNsoB3H3W0KyKCwPQ+ORqbQ83F
         1Wpk8MKb2jVLtxaAp7wXz/vTTmNm5kv+MT8Mx83Ts4ROFoEDmXi+oOKDUiM++XEg/sr1
         vBZQ==
X-Gm-Message-State: AFuF++kjKU2I4wAa9HCkctXAcu6Lkkf9UVYkspMtqWKu+MdUr9Du90md
	RHR3Z8hq+sdj7BHpy/+ikqsHkr3QTbxCR0vkiptIxp/UIMkzF3+ivoNm8LgU2u2DwjqWVrD0FgS
	RqqbGrg==
X-Gm-Gg: AR+sD1049PmyhEicXgDdRGHJDAkOmgSC2c5kftl6OkylQ/f7QW1y/2qzHtYFvLGX7Ml
	2SRxlsDLL0FjcC6WIVF4xoLu4CTv42hRk3j0doLt//KIB/63d1MdlKQ8sMgtC08GFyWQ3IUdeyh
	I8oA49bhDKgUcQdBXzXBa66XGcn3B2vIy9IQuJakl02GFXzqx9j3VsqDF4sIOkLNPK0KzuzfVuN
	yEc/C7BY5KeAWccFrF3IAOXyl7tI111z1VYO+t/yIMFxAZg0u31sWuuxsxmscfzQm/mSTTclOYY
	ttdfFkkFJuMDgZuc6Qd55bP8Iy/Vps0XV0To0yNuLUBqwivZ38logTr08O+hxOOLKvJ9cHh26JD
	tpoY/jPYuDDPqhbzA+aEMnIuAUYJdG3sp0idH1AhtqaqdLakuUyzBzMyT1R7AME/EUSqL9q82YH
	t1c9sY3c/KYZfYukAwjjUutVE3hbMCsGFcaMR71ScD//X1L5aTVQpLhoDKoX571LcfRqVPj22qy
	uAfuoGl+6GNzQBpLNIypaDJ8w69UenD719/Q7NYMiNIrI2aj/hw
X-Received: by 2002:a5d:64c5:0:b0:47f:f3d4:26da with SMTP id ffacd0b85a97d-482f79c1888mr5437392f8f.11.1787900781432;
        Fri, 28 Aug 2026 00:06:21 -0700 (PDT)
Message-ID: <b5601922-1f8b-46ff-ac3d-0e4310773f85@suse.com>
Date: Fri, 28 Aug 2026 09:06:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH 12/12] x86/nSVM: address Misra 2.1 rule violation
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Language: en-US
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-720697/1787900781-F04A62AC-AE6828D4/0/0
X-purgate-type: clean
X-purgate-size: 550

The 16-bit range of "port" is fully handled by the switch(). Therefore the
default: case is reported unreachable by Eclair. Insert BUILD_ERROR() to
annotate this for Eclair.

No functional change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -845,7 +845,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t
         ++gfn;
         break;
     default:
-        BUG();
+        BUILD_ERROR("I/O port range not fully covered");
         break;
     }
 



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:13:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:13:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401685.1637241 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqmK-00025S-Sx; Fri, 28 Aug 2026 07:13:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401685.1637241; Fri, 28 Aug 2026 07:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzqmK-00025L-Or; Fri, 28 Aug 2026 07:13:32 +0000
Received: by outflank-mailman (input) for mailman id 1401685;
 Fri, 28 Aug 2026 07:13:31 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzqmJ-00025A-QE
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:13:31 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzqmJ-00DobK-6n
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:13:31 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a913511-2eae-0a2a0a5409dd-0a2a4503ec74-16
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:13:31 +0200
Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91351a-fae8-0a2a45030019-d155dd2cf0ee-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:13:30 +0200
Received: by mail-wr1-f44.google.com with SMTP id
 ffacd0b85a97d-482fc2b44a7so157817f8f.2
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 00:13:30 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbb28492sm1750896f8f.31.2026.08.28.00.13.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 00:13:30 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787901210; x=1788506010; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=wpHw8IMnaBLNoz9390A7GY/gC7Cs3eCSqbJYhYSa+/g=;
        b=JZVPl1rhhYfX8M/8m6T2wYoCpcMcPCsmmstaYjG8PGxfa0xSEiCTy14oe1zB69qLcv
         ox1WbS4tcClJCSz6eZNJhLwm4Q0BVDJfyfCYnxB3NyoJZ37KTvMy+EIAJLcU2eW/b6eR
         IK+Nnd5+TQUV0KrkH5mRtTLR/Xxbgi/9Ecq+QlTrxl6XpiZbd2u03uH7XO/PyE5Xumd9
         4C2zc1SzUkLEj6tIH1eBc4dSj74qG0k6VSmPvyAsTgga216QggN07siVYqvu1IhwDECu
         Pdc+HvgjCixlqEJBWNuuJppJPKgq+4+E6OKx1SA09obXFm9PqqQAAmYGvwfyp3d312Dd
         v6Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787901210; x=1788506010;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=wpHw8IMnaBLNoz9390A7GY/gC7Cs3eCSqbJYhYSa+/g=;
        b=kKfejoZtgB9oMmIrh1HRfkfr5evlJzXXiFJjyZZ+wJz42+YFcsyJftK4GBFFq+mNX1
         gS0GTSJvOL/nxIFpFZP++Q0ppiJ28Gfr5xks5wpU8xfO/uoofRTbuf/40QmyQs61F/8U
         j/p/K7cxCB4VHK3E662atQadg5LVoioobK/L0yuiYRwsa2yApzk7kt/en5MpXpeGoB3U
         gwdWFTk3CsAzkqeTKwThVhu8VEZ7+RVA+4EeIxAM4ym/XW+0Zr5qwX893tCcDD9obY8c
         zT4LIWFuAGWSn40osDbzLxWS/IQK8s/MDUccVgNzwVYbB1CbFulgf2fiuY6ZlfCL6sKl
         TP5A==
X-Forwarded-Encrypted: i=1; AHgh+Rr5tTZiQNpzC/3RDaZeR1qFyqdQxvab2TmtSpu55sNtYT+FnEZkpDJaYPDfnhtVvADYfAqg28k8YZ8=@lists.xenproject.org
X-Gm-Message-State: AFuF++mKBpwYIeZp3Jb+ILXUO7Yt25n+PO4cciqf074WBvUIMtbMjaYA
	C9c7+fgXwIPR4gf2pSrbyA7YJ4YpGzxEM2MyWXkfiNEwaQwbMR9f8FgF4m6GwcZl2A==
X-Gm-Gg: AR+sD11HG/LHea9hQq2hK/42IR1byabj8ZmmYQ22yviy+MN5LpAPL0XqVjYbxM7tirp
	4X0avCVHWsgf6Lbo4fZ4NaIZNm7d8+Ehr9Ki1jIXx4ajETT6jSYNw3m/55GgeTohF9M1ms5y3xc
	7klqDbbj+LTMBEWbuifp3k/1yQDl0Y4HZWjlOdmKNEDo8sIiqD3siGHVNYW6idt2CYy9jy9D2QD
	GGtOR2Ffu47G7aCaHu4X5kSQkzbk2ju4Zc9UbXbHbR+80wYL7U+YO8I4c+YBG3E7JHD+nFqOlm6
	kApiBTHvIxLnfaDv2mtDdZqA8gvl0gBPx+Q9y3+ZC29Zhi/TvnAHD9q/unHuHFsR8Q1UBo9Kh9g
	W2Yy7kyhGBaBb12QFDFT1YaZ7/Un1Z/fxrdpjcRY9KlUmHozbDRCj2UGqZ0kuNjy98NRQEK1u8S
	rTwm00CNNUMCazYMmaZzJelgguSRkN91+CQAT7d5nZVBpXlyRiiecetXdm4/FHS43TAKGimVQk/
	WlGUeWiZ/HyDsn5/xmLNTHL+FUJWBY7vIHKsySCIFym5uTFoqBe
X-Received: by 2002:a05:6000:656:b0:482:f0dc:e571 with SMTP id ffacd0b85a97d-482f79b1ec7mr6491972f8f.14.1787901210498;
        Fri, 28 Aug 2026 00:13:30 -0700 (PDT)
Message-ID: <86ea652a-69ab-4920-bed7-3e28ce64fb1d@suse.com>
Date: Fri, 28 Aug 2026 09:13:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
 <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787901210-6C6DE4E9-67E5088B/0/0
X-purgate-type: clean
X-purgate-size: 1287

On 27.08.2026 18:53, Oleksii Kurochko wrote:
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
>> --- a/xen/arch/riscv/riscv64/head.S
>> +++ b/xen/arch/riscv/riscv64/head.S
>> @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
>>           srli    t1, t1, PAGE_SHIFT
>>           or      t1, t1, t0
>>           csrw    CSR_SATP, t1
> 
> ... ASID isn't used as we are in Bare mode.
> 
> What am I missing?
> 
>> +        sfence.vma
> 
> The one thing which possibly matters here, and could explain why 
> sfence.vma is needed, is:
> ```
> Implementations with virtual memory are permitted to perform address 
> translations speculatively and earlier than required by an explicit 
> memory access, and are permitted to cache them in address translation 
> cache structures—including possibly caching the identity mappings from 
> effective address to physical address used in Bare translation modes and 
> M-mode.
> ```
> 
> So the TLB could potentially be populated with identity mappings, and I 
> agree that it would be better to flush those.

First: Does (or at least may) the TLB come into play in Bare mode? If not,
there's nothing to invalidate. If so, the next question would be whether
it's indeed ASID 0 which is (or again may be) used in such TLB entries.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 07:54:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 07:54:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401711.1637250 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzrPl-00068u-MC; Fri, 28 Aug 2026 07:54:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401711.1637250; Fri, 28 Aug 2026 07:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzrPl-00068n-JZ; Fri, 28 Aug 2026 07:54:17 +0000
Received: by outflank-mailman (input) for mailman id 1401711;
 Fri, 28 Aug 2026 07:54:16 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <julien@xen.org>) id 1wzrPk-00067c-Mj
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 07:54:16 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <julien@xen.org>) id 1wzrPk-009wzi-0F;
 Fri, 28 Aug 2026 07:54:15 +0000
Received: from [2a02:8012:3a1:0:b46d:19b9:3369:f1e1]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from <julien@xen.org>) id 1wzrPi-00E9tF-22;
 Fri, 28 Aug 2026 07:54:14 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org;
	s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:
	References:Cc:To:Subject:MIME-Version:Date:Message-ID;
	bh=JC5p0cqmy/OnXdsqCXkhOxXjsvNcK3X48yKMSC/PPns=; b=2/AKofr97zj1rMIaFrI4R1w9mt
	jRsatedY5emEIqbEbpCJgsDuVG4vGlv3YruXAuLPwZGndLbm3gABsgeN3HbRZZwsM+qM7WoPRgTMb
	BgCkleM7pPsWoXP6KXmuEmHlVBoHuwKvnNKZjEyWPh1X6Ze0epgfWEnUxM/grHKWnYiw=;
Message-ID: <0c8ebd80-9e73-4db0-a5b9-7b58b87874c0@xen.org>
Date: Fri, 28 Aug 2026 08:54:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] ARM/vgic: Clean up vgic_v{2,3}_setup_hw()
To: Michal Orzel <michal.orzel@amd.com>, xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
References: <20260828070409.106935-1-michal.orzel@amd.com>
Content-Language: en-GB
From: Julien Grall <julien@xen.org>
In-Reply-To: <20260828070409.106935-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 28/08/2026 08:04, Michal Orzel wrote:
> From: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> vgic_v{2,3}_setup_hw()'s callers are __init, so they should be too.
> vgic_v{2,3}_hw and gic_v2_hw_data are written once during init and
> unmodified thereafter, so make them __ro_after_init.  Reposition
> 'bool enabled' in these structures to fit in the tail padding, removing
> 8 bytes from their size when paddr_t is 8B.
> 
> While at it, drop dead vgic_v3_setup_hw() dummy implementation
> from vgic/vgic.c. GICV3 depends on !NEW_VGIC.

I am not sure about this one. There are logics in the new vGIC which are 
GICv3 specific so technically not reachable. However, I would argue they 
should not be remove as the eventual goal as always been to move to a 
different GIC (our current vGIC is not spec compliant). For this 
specific change, it is easy to re-add so ...

> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Julien Grall <julien@xen.org>

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:03:41 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:03:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401732.1637260 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzrYm-0001kz-Sq; Fri, 28 Aug 2026 08:03:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401732.1637260; Fri, 28 Aug 2026 08:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzrYm-0001ks-PL; Fri, 28 Aug 2026 08:03:36 +0000
Received: by outflank-mailman (input) for mailman id 1401732;
 Fri, 28 Aug 2026 08:03:35 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzrYl-0001kl-Er
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:03:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzrYj-00DkPf-SJ
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:03:33 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9140ce-e002-0a2a0a5209dd-0a2a450ac80a-36
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:03:33 +0200
Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9140d4-f2d2-0a2a450a0019-d1558036e4be-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:03:32 +0200
Received: by mail-wm1-f54.google.com with SMTP id
 5b1f17b1804b1-4953de5be0aso4808975e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 01:03:32 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b94dc103dsm30117025e9.1.2026.08.28.01.03.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 01:03:31 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787904212; x=1788509012; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cJF/HoN1wOCB58ermvleAmL+gdV99qSTk4qZnLTG4jQ=;
        b=RtIbAWBgUb8tBifYAc/ysU7nUxo65lTAqOLpN5ZhpLjK/Ey0T21fANXlNQXORGSsiR
         +rzX/2gWnoXgI5viHx4g9kMSGqcdg2Z0CnmbtNU4dyJeAmyCkwNeb9iDTV4/DO2vOxaJ
         nKwam+pmBQTxcb5EXCSPDrIr5Gs5Dvo8N474RtonXAC4xYRUPj6tNeDmx+0GKYrc62jD
         6cliKLqQcUBACCkYiz+elIgsnx3pNrbW+GEVE15z/bjydcWozNCAwHKDJNP+9J8kGyog
         86hKoEtyfBwVYhR4bj4iJhSa4SeIfY1RLEJS7KfbAzmA4jgIo/1+2/aYNZBTy10ubSU4
         zPYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787904212; x=1788509012;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=cJF/HoN1wOCB58ermvleAmL+gdV99qSTk4qZnLTG4jQ=;
        b=FjE3QeIK6/ZTJ3Yw4u2eVMNDhMIIBBmfAgwQkt1jTZTGcDtnv9vuf3cQZX/syHpYWe
         0cXYOW3Fh5UdwfS0jI3KNI9ezP8XZe3gY3LkD66jeADVeehCORrGVwiix377Zy8vkXAK
         WEcCygYy3SHkI/uAUSXmU0JAmHnMsQIThD0ERqJS3AB00PomtqfMkdxTrqOtzHzP03cb
         qYo3fAFx/x8jIXDXl3nbUL7z24tZZ9jbqBHpg/liUGX5e5UGtCtJn/yIw1gzpjMb9H9+
         va2b45jIaeSYfT2x45mtTHtePz6IzfU+E4dSSUiAVBdKoitXfEDJ4URBdetnKJQK1DMD
         tPTA==
X-Forwarded-Encrypted: i=1; AHgh+Rqyal1iW3+Nxbk6WAV1D7XNHPNTOBl+0Ysz2dTScYF2fxf+KncAd6WtYqrjL2jf8DcJjUJ+fvqKL74=@lists.xenproject.org
X-Gm-Message-State: AFuF++nTytTx6OYA/uoSaVEPRuasvk1OdJ9dns6UkEKvQ0CRFRjCTwNr
	INNWwpJdW+UtXxEX8QwDT/kEjETxfK9Fe3xj/z2fBim1Y6k07T5lLc2g
X-Gm-Gg: AR+sD13s3CgEe5oV5ROqHymF7/PU5994GVvyyDFONfu7GxjKDZdM5EfuAcjR0T4aBtv
	LkfUw04ZCXcqtkJWaoXMQLXuRPupVgTq/tq0q7OB5QpgR2IdsjglzV+sLLVSX6C5QeJe8GTIwdE
	GSY+BPGJclQYKEJ9uvcRnvxOqfieiWg7V6lVv5H/+N00fBCvbOdFvy+FdFLLN7t1t/nFN9Ja7o4
	GnJvArTqt1zQvNdcpNLvtawAVxk/DZTXkgDxLpIScJbqvzsXp5geWFvoDlfN6mGgHkHlyyRE+ph
	R9f3CQuA8DhYoe8SxktLpLs2j8HLV/I5i+7P7xBQabTDvesspfJaOWOXY6WgeFFGRxsK9uJnSJs
	tAyKeyCy45SPdTjZBU766/yVqTxKE69bOdn9E9+d0NFghd6EAjTLhgw2GbOJYtXNo0ngjs+GlTg
	unp0WcpxmqyNF4FtXCcLTK88wK9Wfwp0/GPHolBchbHg58EUU9TN+UxTa0WsXUwFaextLKo2gLm
	DbN0LLuwfnnVUo0eFGPm0AIPRG94c7JUdxqS7phUg==
X-Received: by 2002:a05:600c:1d15:b0:499:d366:f572 with SMTP id 5b1f17b1804b1-49b91c4338cmr57738155e9.10.1787904211730;
        Fri, 28 Aug 2026 01:03:31 -0700 (PDT)
Message-ID: <8c135fde-2e50-463f-91f9-e70007ecd725@gmail.com>
Date: Fri, 28 Aug 2026 10:03:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
To: Jan Beulich <jbeulich@suse.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>, xen-devel@lists.xenproject.org
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
 <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
 <86ea652a-69ab-4920-bed7-3e28ce64fb1d@suse.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <86ea652a-69ab-4920-bed7-3e28ce64fb1d@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1787904212-59DDFCFC-60DA45DF/10/73395122804
X-purgate-type: spam
X-purgate-size: 1930



On 8/28/26 9:13 AM, Jan Beulich wrote:
> On 27.08.2026 18:53, Oleksii Kurochko wrote:
>> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
>>> --- a/xen/arch/riscv/riscv64/head.S
>>> +++ b/xen/arch/riscv/riscv64/head.S
>>> @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
>>>            srli    t1, t1, PAGE_SHIFT
>>>            or      t1, t1, t0
>>>            csrw    CSR_SATP, t1
>>
>> ... ASID isn't used as we are in Bare mode.
>>
>> What am I missing?
>>
>>> +        sfence.vma
>>
>> The one thing which possibly matters here, and could explain why
>> sfence.vma is needed, is:
>> ```
>> Implementations with virtual memory are permitted to perform address
>> translations speculatively and earlier than required by an explicit
>> memory access, and are permitted to cache them in address translation
>> cache structures—including possibly caching the identity mappings from
>> effective address to physical address used in Bare translation modes and
>> M-mode.
>> ```
>>
>> So the TLB could potentially be populated with identity mappings, and I
>> agree that it would be better to flush those.
> 
> First: Does (or at least may) the TLB come into play in Bare mode? If not,
> there's nothing to invalidate.

In the quote from the spec I mentioned above it is written the answer is 
yes, the TLB (address-translation cache) absolutely can come into play 
in Bare mode.

> If so, the next question would be whether
> it's indeed ASID 0 which is (or again may be) used in such TLB entries.

I re-read the spec and ASID 0 will be really used even in Bare mode as 
to select MODE=Bare, software must write zero to the remaining fields of 
satp (bits 30–0 when SXLEN=32, or bits 59–0 when SXLEN=64) what 
automatically includes field ASID (so it will be zero).

And considering that idendentity mapping could be cached in TLB even in 
Bare mode they will taged with ASID = 0.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:11:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:11:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401738.1637268 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzrgN-0004hu-K3; Fri, 28 Aug 2026 08:11:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401738.1637268; Fri, 28 Aug 2026 08:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzrgN-0004hn-H1; Fri, 28 Aug 2026 08:11:27 +0000
Received: by outflank-mailman (input) for mailman id 1401738;
 Fri, 28 Aug 2026 08:11:26 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzrgL-0004gc-Tq
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:11:26 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzrgK-001JEX-KM
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:11:24 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9142a2-8faa-0a2a0a5109dd-0a2a4507d532-24
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:11:24 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9142ac-b4ea-0a2a45070019-d155802da4a3-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:11:24 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49b0eab380eso6127365e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 01:11:24 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b9266d45esm25000875e9.2.2026.08.28.01.11.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 01:11:23 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787904684; x=1788509484; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=vsu0dQntEYrc++cEclLDRAjDXydDbaGRch5cVS6DJ+I=;
        b=BBDLr0QvCjshlZmEkmKJOAaWpHOQr4A2THSubn5EwORB571exMmPVcrfiXwW/PTENU
         tw6GerID3VsauCkZZtfeSgdv5XiFB6EPmVvtBX0nqk57mQ/yX3W9iUKK8fI2eoE06Gmw
         KKqJAcp8nNFBr2aSpN2voAXvjs8z1vLqRD3tgJrOniG8QjSfgt+HiAe66p95clmAHOTI
         dLhMwtoLIsRN8ufLCwlpZcHVtEXk35N3mY42n45LSnfome5LRPIvwCZ/TaQGYbfCIlGV
         1OpbrMgIYWTnin9Hvr8Mci5LywptgzF507zdmW1Dyh1+at6cOjRHpb1Iz9iP/AFqd9Ey
         Olqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787904684; x=1788509484;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=vsu0dQntEYrc++cEclLDRAjDXydDbaGRch5cVS6DJ+I=;
        b=lxdkpX4W9swb1SqILmr2ueyrxDSen11qB3oLP5t/NlJM3kaTlHg89BPPbe0yyy7Tv6
         64frpuWLnjHaYPhywiBEzgt00o1SY7Je0ATMfsMjTjH63yak4CqagRWIMbfpD3DvUpzX
         Wf4dpXXHGzLZFm5Q4ZcKXb7HQC5zPclPEbF1m9eCM3A2X++w69+/Tvv/0Zf5tgrsZhWW
         VSQH5ptLt0CAyoNSE8EUbJ0+NDDExrRp8sCC88hQjx9dVIVDvJTPuja2b6pFfRSbYorO
         Exy9W4WQpFyaQf1gQpcWCcn9q1EhvL8ocO8ww2T7/6s5NjSTOAlkpvtRCb5E4l9xD1Q3
         G8oQ==
X-Forwarded-Encrypted: i=1; AHgh+RoY5UWg30Icqq30ohgpbNl63S/MyJuLMs+r8EWIk59rKO61O+lkqV1ov79y7VlVECKHnOi8QmcpP1I=@lists.xenproject.org
X-Gm-Message-State: AFuF++mDv+Vowj0Cn24vqN4ZD6ftmbzltLp+z/1KS0tu7XkHjnklJCnC
	1HwvxO+lVbAK9VLzI6MjJL2ebkjngtxCuJT0DhScRlLe3GBFlGb1+jul
X-Gm-Gg: AR+sD12SWNuY3Te4Ki4pBJzWGBd6Vv/TVq1AKhkD048iPlelzwM4Kezk1PKZnVi9udj
	MwY5gQUcdCeqfa/+YijfJ62PhYLE9LhTlmVJQVXVgVvmIqric1JbdN7awMKY0aba501w+01U86E
	JCq5rWJ/2tdyokfP/Q6T0NiNR2ldIz4t6UwbPyWU8xlxiT0M3+xr+gJXfi5eN8XyrLv5d5igwh0
	MpTHDmKB6WEqeFbvdphAwIH0fiBQAN3hFxKYLUgEsDW0CidhTzhxnck80wYVbRbGCWvGf3ra1NJ
	Ev8bTfDgaMBmuk3/PdqI8D+RVa2lF+LUrRO/vN7i4+ppXToocLA+2hldNwRkKrDYDht35palS1p
	7bKiCqjsXJRAVjD+XdCbCT4yDiNXGYBB5iwtWbNDdyn+ykALl95e/RyXK8oQaL/PMyhCpzeIwUL
	S+34COkmA1XaUWyWsyKRDLYtZGkQkiKOh9wc5xT+5WOliKPs9yf0dmQDA95YRRgCORSK0v1Fi/Y
	RhEIbx+bo+8vJrpveIF0dLdnkitm0GketgYkisq9w==
X-Received: by 2002:a05:600c:1f8b:b0:49c:a2f3:fe9a with SMTP id 5b1f17b1804b1-49ca2f3ff43mr543115e9.7.1787904683881;
        Fri, 28 Aug 2026 01:11:23 -0700 (PDT)
Message-ID: <f22db381-40c1-4928-85a4-5019da6a9c07@gmail.com>
Date: Fri, 28 Aug 2026 10:11:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
 <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Content-Language: en-US
In-Reply-To: <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1787904684-36AD8AE4-20620A47/10/73395122804
X-purgate-type: spam
X-purgate-size: 4317



On 8/27/26 6:53 PM, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
>> turn_on_mmu() writes satp to switch on Sv39 paging but never fences
>> afterwards.
>>
>> Xen never allocates a non-zero ASID, so per the Privileged spec, sec.
>> 12.2.1 "Supervisor Memory-Management Fence Instruction":
>>
>>    "If the implementation does not provide ASIDs, or software chooses
>>    to always use ASID 0, then after every satp write, software should
>>    execute SFENCE.VMA with rs1=x0."
>>
>> The spec text around this rule hedges with "may be necessary", but
>> RISC-V spec co-author Andrew Waterman confirmed on the ISA manual
>> issue tracker that the fence after a satp write is not optional in
>> this case: "The SFENCE after the SATP write is definitely necessary
>> ... In general, you need to SFENCE after you've recycled an ASID.
>> Since we don't use ASIDs in the Linux kernel yet, every context
>> switch is effectively an ASID reuse, hence the full TLB flush." [1]
>> The same reasoning applies to Xen: with ASID always 0, this satp
>> write is indistinguishable from an ASID reuse to the hart, so the
>> fence is required for correctness.
> 
> But at the moment of execution of turn_on_mmu() we don't use any ASID, 
> do we? It was used in check_pgtbl_mode_support() but at the end it is done:
> 
>      csr_write(CSR_SATP, 0);
> 
>      sfence_vma();
> 
> So basically Bare mode + flush all TLBs presented before and then up to
> 
> ...
> 
>>
>> Add the missing SFENCE.VMA to order those page-table stores before
>> the hart's first translation under the new mapping.
>>
>> [1] https://github.com/riscv/riscv-isa-manual/issues/226
>>
>> Fixes: f5035d480f7a ("xen: add files needed for minimal riscv build")
>> Assisted-by: Claude:claude-opus-5
>> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
>> ---
>>   xen/arch/riscv/riscv64/head.S | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/ 
>> head.S
>> index 9c40512e61..7f6edc972f 100644
>> --- a/xen/arch/riscv/riscv64/head.S
>> +++ b/xen/arch/riscv/riscv64/head.S
>> @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
>>           srli    t1, t1, PAGE_SHIFT
>>           or      t1, t1, t0
>>           csrw    CSR_SATP, t1
> 
> ... ASID isn't used as we are in Bare mode.
> 
> What am I missing?

After the conversation with Jan B. in the separate thread I re-read 
documentaion and found that ASID=0 will be used here too as after 
check_pgtbl_mode_support() we set Bare mode and ASID 0 will be really 
used even in Bare mode as to select MODE=Bare as software must write 
zero to the remaining fields of satp (bits 30–0 when SXLEN=32, or bits 
59–0 when SXLEN=64) what automatically includes field ASID (so it will 
be zero).

But still the full reason why we need sfence.vma here is that TLB could 
be polluted with identity mapping (even in Bare mode) and which will be 
tagged by ASID=0.

So what about to update commit message with:
```
xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()

The existing SFENCE.VMA before the satp write only orders the page table
stores from setup_initial_pagetables() against subsequent implicit reads.
It does not prevent the CPU from speculatively caching translations 
after the fence retires.

According to the RISC-V Privileged specification, implementations are
permitted to speculatively cache Bare-mode identity mappings. Furthermore,
selecting MODE=Bare (which happens during check_pgtbl_mode_support())
requires zeroing the remaining fields of satp, causing ASID=0 to be
actively used in Bare mode. Consequently, the TLB can be polluted with Bare
identity mappings tagged with ASID=0.

Once satp is written to enable Sv39 translation, these cached identity
mappings (tagged with ASID=0) can shadow the true Sv39 translations.
This would lead to translation failures since turn_on_mmu() jumps to
a non-identity-mapped linker address.

Fix this by adding a post-satp-write SFENCE.VMA to invalidate any stale
translations (including Bare-mode identity mappings under ASID=0) before
jumping to the virtual address space.
```

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:20:17 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401751.1637277 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzroq-00088w-HY; Fri, 28 Aug 2026 08:20:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401751.1637277; Fri, 28 Aug 2026 08:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzroq-00088p-Ef; Fri, 28 Aug 2026 08:20:12 +0000
Received: by outflank-mailman (input) for mailman id 1401751;
 Fri, 28 Aug 2026 08:20:11 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wzrop-00088j-JK
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:20:11 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzroo-009V4K-VG
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:20:11 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a9144ba-bab6-0a2a0a5309dd-0a2a45069d96-0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:20:10 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a9144ba-195a-0a2a45060019-c387df83cc5a-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:20:10 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 862161F88E;
 Fri, 28 Aug 2026 08:20:00 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 3A3A61352D;
 Fri, 28 Aug 2026 08:20:00 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id koTlDLBEkWprNAAAD6G6ig
 (envelope-from <jgross@suse.com>); Fri, 28 Aug 2026 08:20:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787905204; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xsF40T8zcJSuxk6fMBaVXRSg34z1eVTIFOKGUgNMUYY=;
	b=JV/mIGv/j0VLIShAXemhACLFqTkx7KVuJzJ6nKqauWagBMdCXSX4eBULaFnikxvB4F41HO
	ymeWNPm6+EGee4h0VBGJdAo20unCWdlApnJW1MfTpVSOurzTxRpojJ8uaHRkyen9tmhyEN
	aOzOEwtWOuHvN4UjGBreiJDOBVa5fa4=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=CK7vUa4M
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787905200; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=xsF40T8zcJSuxk6fMBaVXRSg34z1eVTIFOKGUgNMUYY=;
	b=CK7vUa4MToI/Q+8dnK4XQ5wPgu4xGEEPGvGDvFlihZUU1uQkIVvsalik88Bto68UjHZABl
	jWOc9GPz4GErMw+Rsydh0B703nSR8BrAHmcojDITeQHwtJVgI7tzSInB9AeWCaieugKxjN
	PNiQ/PxKXM/zQRvd6L3LsIIzqfpP468=
Message-ID: <2ddbd454-6220-4e8e-bcb4-b02fb7132563@suse.com>
Date: Fri, 28 Aug 2026 10:19:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/blkback: Prevent missed completion when draining I/O
To: Gui-Dong Han <hanguidong02@gmail.com>, roger@xenproject.org,
 xen-devel@lists.xenproject.org
Cc: axboe@kernel.dk, linux-block@vger.kernel.org, konrad.wilk@oracle.com,
 linux-kernel@vger.kernel.org, baijiaju1990@gmail.com
References: <20260730084000.3305702-1-hanguidong02@gmail.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260730084000.3305702-1-hanguidong02@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Y0iH2961D4ewxizp8ll6S523"
X-Spam-Level: 
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Queue-Id: 862161F88E
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FREEMAIL_TO(0.00)[gmail.com,xenproject.org,lists.xenproject.org];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[kernel.dk,vger.kernel.org,oracle.com,gmail.com];
	MID_RHS_MATCH_FROM(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	RCPT_COUNT_SEVEN(0.00)[8];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]
X-Spam-Flag: NO
X-Spam-Score: -5.41
X-purgate-ID: tlsNG-16d1c6/1787905210-FC60277B-D9F6DAAC/0/0
X-purgate-type: clean
X-purgate-size: 7245

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Y0iH2961D4ewxizp8ll6S523
Content-Type: multipart/mixed; boundary="------------ME7gGn3e8QmhdSpqG0F00Dun";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Gui-Dong Han <hanguidong02@gmail.com>, roger@xenproject.org,
 xen-devel@lists.xenproject.org
Cc: axboe@kernel.dk, linux-block@vger.kernel.org, konrad.wilk@oracle.com,
 linux-kernel@vger.kernel.org, baijiaju1990@gmail.com
Message-ID: <2ddbd454-6220-4e8e-bcb4-b02fb7132563@suse.com>
Subject: Re: [PATCH] xen/blkback: Prevent missed completion when draining I/O
References: <20260730084000.3305702-1-hanguidong02@gmail.com>
In-Reply-To: <20260730084000.3305702-1-hanguidong02@gmail.com>

--------------ME7gGn3e8QmhdSpqG0F00Dun
Content-Type: multipart/mixed; boundary="------------pJPF7iITLpKznzdBk0K82qLl"

--------------pJPF7iITLpKznzdBk0K82qLl
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMzAuMDcuMjYgMTA6NDAsIEd1aS1Eb25nIEhhbiB3cm90ZToNCj4geGVuX2Jsa19kcmFp
bl9pbygpIHNldHMgZHJhaW4gYmVmb3JlIGNoZWNraW5nIGluZmxpZ2h0Lg0KPiB4ZW5fYmxr
YmtfdW5tYXBfYW5kX3Jlc3BvbmRfY2FsbGJhY2soKSBkZWNyZW1lbnRzIGluZmxpZ2h0IHdp
dGgNCj4gYXRvbWljX2RlY19hbmRfdGVzdCgpIGJlZm9yZSBjaGVja2luZyBkcmFpbi4NCj4g
DQo+IFRoZSBwcmUtd2FpdCBjb25kaXRpb24gY2hlY2sgd2FzIGFkZGVkIHRvIGF2b2lkIG1p
c3NpbmcgYSBjb21wbGV0aW9uLCBidXQNCj4gYXRvbWljX3NldCgpIGlzIHVub3JkZXJlZC4g
V2l0aCBvbmUgSS9PIGluIGZsaWdodCwgdGhlIGRyYWluIHBhdGggY2FuIHNldA0KPiBkcmFp
biB0byAxIGFuZCByZWFkIGluZmxpZ2h0IGFzIDEgYmVmb3JlIHRoZSBjb21wbGV0aW9uIGRl
Y3JlbWVudC4gVGhlDQo+IGNvbXBsZXRpb24gcGF0aCB0aGVuIGRlY3JlbWVudHMgaW5mbGln
aHQgdG8gMCBidXQgY2FuIHN0aWxsIHJlYWQgZHJhaW4gYXMNCj4gMC4gSXQgc2tpcHMgY29t
cGxldGUoKSwgc28gdGhlIGRyYWluIHBhdGggd2FpdHMgdW50aWwgdGhlIHRpbWVvdXQgZGVz
cGl0ZQ0KPiBubyBJL08gcmVtYWluaW5nLg0KPiANCj4gQWRkIGEgZnVsbCBiYXJyaWVyIGJl
dHdlZW4gc2V0dGluZyBkcmFpbiBhbmQgcmVhZGluZyBpbmZsaWdodC4NCj4gYXRvbWljX2Rl
Y19hbmRfdGVzdCgpIGFscmVhZHkgcHJvdmlkZXMgZnVsbCBvcmRlcmluZyBvbiB0aGUgY29t
cGxldGlvbg0KPiBzaWRlLg0KPiANCj4gRml4ZXM6IDY5MjdkOTIwOTFkZiAoInhlbi9ibGti
YWNrOiBGaXggdHdvIHJhY2VzIGluIHRoZSBoYW5kbGluZyBvZiBiYXJyaWVyIHJlcXVlc3Rz
LiIpDQo+IFNpZ25lZC1vZmYtYnk6IEd1aS1Eb25nIEhhbiA8aGFuZ3VpZG9uZzAyQGdtYWls
LmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4N
Cg0KDQpKdWVyZ2VuDQo=
--------------pJPF7iITLpKznzdBk0K82qLl
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------pJPF7iITLpKznzdBk0K82qLl--

--------------ME7gGn3e8QmhdSpqG0F00Dun--

--------------Y0iH2961D4ewxizp8ll6S523
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqRRK8FAwAAAAAACgkQsN6d1ii/Ey+m
Cwf/R7c9EGTk1BTIYLTqe0a35SXab3bjoKxGUsD5N6kIVyvBMKcQyVgUhKMrzop+Cq9/cTw5iGWg
HcTXkSLszgc6GNSFSy6N9GjIaN+Lame1x/NY7xaWSfVinkneDgc0jJGe+9xg3RCLOcWF1YK+tje8
wdjAvOjNQamD1rJGCBWp5yDoD7M6oRHUT5sIpgzofn4WZAm04/QI+oAx+2NyHzNe0L7yDa9C9a09
KOIgqJZYFeVu6OVkd9hkgTeBbyLxLs29dqb3vm4i1mPe2KGKtBsLhjSWwvLfs3J61a3GltLgCBBg
913IqySpl0Zb+4BDouzQRXRUxB3HbVkareVULk1mqg==
=8DCy
-----END PGP SIGNATURE-----

--------------Y0iH2961D4ewxizp8ll6S523--


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:29:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:29:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401759.1637285 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzryC-0001op-C8; Fri, 28 Aug 2026 08:29:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401759.1637285; Fri, 28 Aug 2026 08:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzryC-0001oi-9E; Fri, 28 Aug 2026 08:29:52 +0000
Received: by outflank-mailman (input) for mailman id 1401759;
 Fri, 28 Aug 2026 08:29:51 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0477d3954000c4f3@swg.vates.tech>)
 id 1wzryA-0001oc-EG
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:29:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzry8-00E43E-Pe
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:29:48 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0477d3954000c4f3@swg.vates.tech>)
 id 6a9146f4-2eae-0a2a0a5409dd-0a2a4506ec42-18
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:29:48 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0477d3954000c4f3@swg.vates.tech>)
 id 6a9146fb-195a-0a2a45060019-b9ff1c2395c7-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:29:48 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0477d3954000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 28 Aug 2026 08:29:44 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 443A681F21;
 Fri, 28 Aug 2026 10:29:43 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=/DizAnrA4pBdfKkD8PpABLQia3/tP+9xpDqqE9BnX/4=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=IVVhjJ6b83W0JGfZzDK/zavQcdu1ayPYfK16u5oEzoM20wPkJx0cBE8aV1ZkFmUILp18nPm1F
 kcRJ86IDOSMiao0vkW1tHzdVdPutTUKDl7PH+lrURxK9JcocFimcw4E9q1GmK7WIwf+npjbGGlC
 ZFWubADjGa2NIihIkiR8Cu21bVwY8KNQpRR7ZM5MSmFUqAbZvSLSYFOqYFT42M0kKWA+1JY7Bvm
 VWMMi+nkyV/HcxnAWz8gtD5tJzhbTWMlR+A08QIcUasi9kRX3plKwnSuYLV1ThelOFrRyCzrCVS
 ZTeIc6Ivhlg2jE7AhDwH7PBeS27aDCr1k/hAEL47/h8A==
X-Zone-Loop: 8b2d2254ef00eb337c067ae4ed8f0e1e13fa5aeced00
x-campaign-type: default
x-transaction-id: b0feec2c-0e20-46be-9675-393d20f6a89f
x-swg-uid: 01-49215b67-0565-46e4-80ed-1c517a94a648
X-Mailer: Sweego
Message-ID:
 <1787905784.8631fc262581453bbf619ec5b2062170.1a0477d3954000c4f3@vates.tech>
x-swg-bid: 1787905784.8631fc262581453bbf619ec5b2062170.1a0477d3954000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH 5/5] xen/riscv: add SFENCE.VMA after enabling paging
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <f22db381-40c1-4928-85a4-5019da6a9c07@gmail.com>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844810.8631fc262581453bbf619ec5b2062170.1a043dad5be000c4f3@vates.tech>
 <9e4778fa-3164-49bc-a921-ce6b251b5db5@gmail.com>
 <f22db381-40c1-4928-85a4-5019da6a9c07@gmail.com>
Date: Fri, 28 Aug 2026 10:29:37 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1787905783; l=4650;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=M08mTRxVE0D5+bHJkCBbCH5IQ0DXFvcTqRRnUEa63Hk=;
 b=oEioOmSgKOcnob6ZYJGxvyyaJZLR4btxB33Xte7w1dMWI9dsaoAGfFmY5+wUgvCGN1Rohh2X9
 TcATHegIzMxDrVm9iqIowu2d5QsUJzB+yfflB4RkSrIPs8cuQfkX2tg
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787905783486
X-purgate-ID: tlsNG-16d1c6/1787905788-FD20877B-234B41DE/0/0
X-purgate-type: clean
X-purgate-size: 4654

On 2026-08-28 10:11 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 6:53 PM, Oleksii Kurochko wrote:
> > 
> > 
> > On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> >> turn_on_mmu() writes satp to switch on Sv39 paging but never fences
> >> afterwards.
> >>
> >> Xen never allocates a non-zero ASID, so per the Privileged spec, sec.
> >> 12.2.1 "Supervisor Memory-Management Fence Instruction":
> >>
> >>    "If the implementation does not provide ASIDs, or software chooses
> >>    to always use ASID 0, then after every satp write, software should
> >>    execute SFENCE.VMA with rs1=x0."
> >>
> >> The spec text around this rule hedges with "may be necessary", but
> >> RISC-V spec co-author Andrew Waterman confirmed on the ISA manual
> >> issue tracker that the fence after a satp write is not optional in
> >> this case: "The SFENCE after the SATP write is definitely necessary
> >> ... In general, you need to SFENCE after you've recycled an ASID.
> >> Since we don't use ASIDs in the Linux kernel yet, every context
> >> switch is effectively an ASID reuse, hence the full TLB flush." [1]
> >> The same reasoning applies to Xen: with ASID always 0, this satp
> >> write is indistinguishable from an ASID reuse to the hart, so the
> >> fence is required for correctness.
> > 
> > But at the moment of execution of turn_on_mmu() we don't use any ASID, 
> > do we? It was used in check_pgtbl_mode_support() but at the end it is done:
> > 
> >      csr_write(CSR_SATP, 0);
> > 
> >      sfence_vma();
> > 
> > So basically Bare mode + flush all TLBs presented before and then up to
> > 
> > ...
> > 
> >>
> >> Add the missing SFENCE.VMA to order those page-table stores before
> >> the hart's first translation under the new mapping.
> >>
> >> [1] https://github.com/riscv/riscv-isa-manual/issues/226
> >>
> >> Fixes: f5035d480f7a ("xen: add files needed for minimal riscv build")
> >> Assisted-by: Claude:claude-opus-5
> >> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> >> ---
> >>   xen/arch/riscv/riscv64/head.S | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/ 
> >> head.S
> >> index 9c40512e61..7f6edc972f 100644
> >> --- a/xen/arch/riscv/riscv64/head.S
> >> +++ b/xen/arch/riscv/riscv64/head.S
> >> @@ -98,6 +98,7 @@ FUNC(turn_on_mmu)
> >>           srli    t1, t1, PAGE_SHIFT
> >>           or      t1, t1, t0
> >>           csrw    CSR_SATP, t1
> > 
> > ... ASID isn't used as we are in Bare mode.
> > 
> > What am I missing?
> 
> After the conversation with Jan B. in the separate thread I re-read 
> documentaion and found that ASID=0 will be used here too as after 
> check_pgtbl_mode_support() we set Bare mode and ASID 0 will be really 
> used even in Bare mode as to select MODE=Bare as software must write 
> zero to the remaining fields of satp (bits 30–0 when SXLEN=32, or bits 
> 59–0 when SXLEN=64) what automatically includes field ASID (so it will 
> be zero).
> 
> But still the full reason why we need sfence.vma here is that TLB could 
> be polluted with identity mapping (even in Bare mode) and which will be 
> tagged by ASID=0.
> 
> So what about to update commit message with:
> ```
> xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu()
> 
> The existing SFENCE.VMA before the satp write only orders the page table
> stores from setup_initial_pagetables() against subsequent implicit reads.
> It does not prevent the CPU from speculatively caching translations 
> after the fence retires.
> 
> According to the RISC-V Privileged specification, implementations are
> permitted to speculatively cache Bare-mode identity mappings. Furthermore,
> selecting MODE=Bare (which happens during check_pgtbl_mode_support())
> requires zeroing the remaining fields of satp, causing ASID=0 to be
> actively used in Bare mode. Consequently, the TLB can be polluted with Bare
> identity mappings tagged with ASID=0.
> 
> Once satp is written to enable Sv39 translation, these cached identity
> mappings (tagged with ASID=0) can shadow the true Sv39 translations.
> This would lead to translation failures since turn_on_mmu() jumps to
> a non-identity-mapped linker address.
> 
> Fix this by adding a post-satp-write SFENCE.VMA to invalidate any stale
> translations (including Bare-mode identity mappings under ASID=0) before
> jumping to the virtual address space.
> ```
> 
> ~ Oleksii
> 
I read the thread and I'm ok with this suggestion.
Thanks.
> 
> 




From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:32:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:32:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401766.1637296 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzs0L-0003oU-PN; Fri, 28 Aug 2026 08:32:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401766.1637296; Fri, 28 Aug 2026 08:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzs0L-0003oN-Km; Fri, 28 Aug 2026 08:32:05 +0000
Received: by outflank-mailman (input) for mailman id 1401766;
 Fri, 28 Aug 2026 08:32:04 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <nicola.vetrini@bugseng.com>) id 1wzs0K-0003oF-08
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:32:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzs0I-0002J3-Tk
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:32:02 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a91476e-bab6-0a2a0a5309dd-0a2a450ba012-44
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:32:02 +0200
Received: from [162.55.131.47] (helo=support.bugseng.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a914782-b7e8-0a2a450b0019-a237832f8dee-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:32:02 +0200
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 321FB4EE004E;
 Fri, 28 Aug 2026 10:31:56 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1787905922;
	b=Dk+q15xrGrlwRMYp5SNXXhihQnNczemPIxp5TL2ZTn7t/idml8t2kJXK6fYgdNuLhJ53
	 aDli3KjDKywWNbXT7uq1hoRoBuoGSH2gmCK9pKs0BZAtCf6yvjR6XKfAn9krqj6liAaYQ
	 boj8RIidyKbCce9UkJ+nG7lRnceDWZcmNMaF8v7UEpe5hiDLNvyeNbxu6/QhfGWrxQFaR
	 wltG0lYLsg2GMxFGrTwpApFpgD43ZYjWWoFbmzIcN05vijfdFJZXpxnPIfDFiJMInSEbx
	 QZz3jDxlCAlU/CHK8oC8uVLjSevglGIYycJXYAgndAeKVm+L9FZiEP5IuxidPCZugJ234
	 Ra0xU2x0PG9hS8ZfrsTA0dHigpTlJRq9K8XM6rF7TS+YbOKJzAiMldNmtY0kU/pWm4kl+
	 2PxwLWmar8N02MnRXfIwWkGzlGhpXg10PWGPz33j2+NNIvVcNF83RlSh7/Tuh+IY6IqtK
	 EYn1Aefhg3pif3k05AmXTodcEb7BaSHK3pjQk+uD5NwuUwBPYrs3ZC0mM5CJR/FIa2Ahv
	 KKQZwFnpyfhSclnJhyUQXgzznlYO+4ATotG/35lcPVNYxRhUy2R/Goi5Y5eGTuFpustU+
	 YLfsskyYRohkbWMEbywVpy/gXzL40eywRGulB9uMzZhsFxZLlVnJm5w/oBdO/Cs=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1787905922;
	h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=57DpeOM4ZZyK6S8+j5v/LJFABgPU7k0ijq2diC/4+3A=;
	b=y7D7ISArE0UrhGwH9X9qwWFoIMXQumh/pWhngjhhWtm28yJjR1i4IxxYSIo7pcdRVl0E
	 dWLyl7zrpS07237dHp9A9w5h7p4BFEQIH8U+MIBEV8FwLpGZtggBZ5JNd2DZ52OO14a+4
	 x7uwiaVlKxJxtCb6MtYpnYTOYUgpk3ogivLRvdgZZINH3lw7bkYqj0wY58/Vx/u/6NvNo
	 OHhIYzMv6aQakEtPiQpR8iko4tWpKZ9xf/yFlJ6uPH27q3pQBF9xxRNSRJQkSNFM0A6Jj
	 9xz2aWuC1I9+66UNS/9O/8zcQ7N49O3duaIYyDle5zI3oLTzNjE4pKtjxndRk8Q6BWNrR
	 0D1WryDysWZmI5PjUctG8Xq7MvYoYDPfQXnYq70tLOHwRRuLPjqbmfsm84vCz6t8camQG
	 t5RaAsoNxfHsqsXYdjeLP8Kr5IzSZAq8h49fOG2o/HOLUIogDNiIsCz5/BtaMxLJkYtbP
	 ANPJlPYd26TVnTSSYPLcoLb8pVDjcBrjl5+LqldlepBwrYi2+v2kmsPea06eQZB6FT70C
	 0YENudEYm/6uvihY2tvy/wFYVCV+YI+GgOXcWOF+/u5aJe6FDXTTqBDQCOUYFjva2dWUd
	 dd/1sn5px2AqLnQNjh1Xwf7hq0V2QH4Vq7XP+3Cgqpde+ZTmeyrDC07zwV7mdVs=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
MIME-Version: 1.0
Date: Fri, 28 Aug 2026 10:31:56 +0200
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, Teddy Astie <teddy.astie@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Subject: Re: [PATCH 01/12] x86/IO-APIC: address Misra 2.1 rule violations
In-Reply-To: <85c111a5-105c-4b8f-8b81-d7ec1d0f9436@suse.com>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
 <85c111a5-105c-4b8f-8b81-d7ec1d0f9436@suse.com>
Message-ID: <32044eb1dfef2d0281e11534a6d1d938@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787905922-A88C99EA-DF8F90DF/0/0
X-purgate-type: clean
X-purgate-size: 4379

On 2026-08-28 08:59, Jan Beulich wrote:
> In both functions cases 0..3 are handled, and a 2-bit mask is applied 
> to
> the switch() expression. Therefore the default: cases are reported
> unreachable by Eclair. Subsume the "case 2" blocks each into the
> corresponding default ones.
> 
> While there also drop all the pointless figure braces inside the 
> various
> case blocks, inserting blank lines instead between them.
> 
> No functional change.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -804,66 +804,48 @@ static int __init MPBIOS_polarity(int id
>      switch (mp_irqs[idx].mpc_irqflag & 3)
>      {
>      case 0: /* conforms, ie. bus-type dependent polarity */
> -    {
>          switch (mp_bus_id_to_type[bus])
>          {
>          case MP_BUS_ISA: /* ISA pin */
> -        {
>              polarity = default_ISA_polarity(idx);
>              break;
> -        }
> +
>          case MP_BUS_EISA: /* EISA pin */
> -        {
>              polarity = default_EISA_polarity(idx);
>              break;
> -        }
> +
>          case MP_BUS_PCI: /* PCI pin */
> -        {
>              polarity = default_PCI_polarity(idx);
>              break;
> -        }
> +
>          case MP_BUS_MCA: /* MCA pin */
> -        {
>              polarity = default_MCA_polarity(idx);
>              break;
> -        }
> +
>          case MP_BUS_NEC98: /* NEC 98 pin */
> -        {
>              polarity = default_NEC98_polarity(idx);
>              break;
> -        }
> +
>          default:
> -        {
>              printk(KERN_WARNING "broken BIOS!!\n");
>              polarity = 1;
>              break;
>          }
> -        }
>          break;
> -    }
> +
>      case 1: /* high active */
> -    {
>          polarity = 0;
>          break;
> -    }
> -    case 2: /* reserved */
> -    {
> -        printk(KERN_WARNING "broken BIOS!!\n");
> -        polarity = 1;
> -        break;
> -    }
> +
>      case 3: /* low active */
> -    {
>          polarity = 1;
>          break;
> -    }
> -    default: /* invalid */
> -    {
> +
> +    default: /* reserved */
>          printk(KERN_WARNING "broken BIOS!!\n");
>          polarity = 1;
>          break;
>      }
> -    }
>      return polarity;
>  }
> 
> @@ -878,66 +860,48 @@ static int MPBIOS_trigger(int idx)
>      switch ((mp_irqs[idx].mpc_irqflag>>2) & 3)
>      {
>      case 0: /* conforms, ie. bus-type dependent */
> -    {
>          switch (mp_bus_id_to_type[bus])
>          {
>          case MP_BUS_ISA: /* ISA pin */
> -        {
>              trigger = default_ISA_trigger(idx);
>              break;
> -        }
> +
>          case MP_BUS_EISA: /* EISA pin */
> -        {
>              trigger = default_EISA_trigger(idx);
>              break;
> -        }
> +
>          case MP_BUS_PCI: /* PCI pin */
> -        {
>              trigger = default_PCI_trigger(idx);
>              break;
> -        }
> +
>          case MP_BUS_MCA: /* MCA pin */
> -        {
>              trigger = default_MCA_trigger(idx);
>              break;
> -        }
> +
>          case MP_BUS_NEC98: /* NEC 98 pin */
> -        {
>              trigger = default_NEC98_trigger(idx);
>              break;
> -        }
> +
>          default:
> -        {
>              printk(KERN_WARNING "broken BIOS!!\n");
>              trigger = 1;
>              break;
>          }
> -        }
>          break;
> -    }
> +
>      case 1: /* edge */
> -    {
>          trigger = 0;
>          break;
> -    }
> -    case 2: /* reserved */
> -    {
> -        printk(KERN_WARNING "broken BIOS!!\n");
> -        trigger = 1;
> -        break;
> -    }
> +
>      case 3: /* level */
> -    {
>          trigger = 1;
>          break;
> -    }
> -    default: /* invalid */
> -    {
> +
> +    default: /* reserved */
>          printk(KERN_WARNING "broken BIOS!!\n");
>          trigger = 0;
>          break;
>      }
> -    }
>      return trigger;
>  }

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:52:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:52:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401779.1637304 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzsJv-0002Bi-CR; Fri, 28 Aug 2026 08:52:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401779.1637304; Fri, 28 Aug 2026 08:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzsJv-0002Ba-9X; Fri, 28 Aug 2026 08:52:19 +0000
Received: by outflank-mailman (input) for mailman id 1401779;
 Fri, 28 Aug 2026 08:52:17 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3@swg.vates.tech>)
 id 1wzsJt-0002BA-Kj
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:52:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzsJs-00BpWI-U7
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:52:16 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3@swg.vates.tech>)
 id 6a914c3b-bab6-0a2a0a5309dd-0a2a45058e36-14
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:52:16 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3@swg.vates.tech>)
 id 6a914c40-4cb1-0a2a45050019-b9ff1c1298b1-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:52:16 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a04791cd47000c4f3.006 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 28 Aug 2026 08:52:12 +0000
Received: from [192.168.1.97] (82-67-211-29.subs.proxad.net [82.67.211.29])
 (Authenticated sender: julian.vetter)
 by mail2.vates.fr (Postfix) with ESMTPSA id D4EAE81F88;
 Fri, 28 Aug 2026 10:52:11 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=WG05nOY/WBj9LoaLnrpdbudf0fRc6mLlCln1H7xPj5M=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=AVCbyeYeM5jFLpv9f3vjxbFycGgK2gCGDcXpBPYeMc78YtbsdOWqmkLZhDbrvYSCkXyiCoFgJ
 mLS8kpRu1n70Q5QVS0aqV0byGb3YL/3UhSRERXF6nm5xRbQstA3/miizKsZ8FGiOK4Go+jccAdj
 NH1uqPb7g82edNRW7gAjv5WK819W6U8hCyOd2pZuViXeZB65m2qXsIr7T7mLnpsCS21Q2sdVMJV
 O0g1PlMbENdJjZ66ZC9A2PYSJ2JAs/KqSeJtSD0J2niUNVOyFlGRCseI4e0gxmY+WjErmh0nbJv
 2yozQ6PbFHZ+syBVilqDbM8wbUyxZtftjYCH3NtQ/Q5A==
X-Zone-Loop: aa142bd06864d34e793039b54c03efb1df2657447d04
x-campaign-type: default
x-transaction-id: 4c918e87-1738-41de-ac79-fd8ca76d4860
x-swg-uid: 01-2e3ed1fa-a2f9-4dbe-bf91-d139b63930e1
X-Mailer: Sweego
Message-ID:
 <1787907132.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3@vates.tech>
x-swg-bid: 1787907132.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Fri, 28 Aug 2026 10:52:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 8/9] hvm/ioreq: Negotiate extended destination ID
 support per ioreq server
To: Jan Beulich <jbeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298081.8631fc262581453bbf619ec5b2062170.19dcf3886cc000f373@vates.tech>
 <a9510f21-b7a8-4323-a64d-0f33e44cd8b0@suse.com>
Content-Language: en-US
From: Julian Vetter <julian.vetter@vates.tech>
In-Reply-To: <a9510f21-b7a8-4323-a64d-0f33e44cd8b0@suse.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2e0b.a407e214bb689b6.1a04791cb12.2ded673d79bf949=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787907132178
X-purgate-ID: tlsNG-c201ff/1787907136-F62AB2A1-63EB85A8/0/0
X-purgate-type: clean
X-purgate-size: 15171

---=Part.2e0b.a407e214bb689b6.1a04791cb12.2ded673d79bf949=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 8/19/26 16:38, Jan Beulich wrote:
> On 27=2E04=2E2026 15:54, Julian Vetter wrote:
>> ---
>> Changes in v4:
>> - As suggested by Roger, replaced XEN_DMOP_enable_ext_dest_id (v3 patch
>>    6), a separate DM op the device model had to call before starting
>>    vCPUs, with a flags byte repurposed from the existing pad[3] field o=
f
>>    xen_dm_op_create_ioreq_server
>=20
> IOW the presence of XEN_DMOP_enable_ext_dest_id in the earlier patch is
> entirely stale?
>=20
>> - New XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID flag (bit 0) lets each ioreq
>>    server signal support at registration time
>> - As suggested by Roger level the feature across all ioreq servers=2E
>>    XEN_HVM_CPUID_EXT_DEST_ID is only advertised when every server
>>    registered before arch_domain_creation_finished() sets the flag=2E A
>>    single server without the flag suppresses the feature for the whole
>>    domain!
>> - Lock the levelled result at domain creation time and enforce it for
>>    servers registered afterwards, preventing a late opt-out from breaki=
ng
>>    guests that already see the feature in CPUID
>> - Persist the locked flag via HVM_SAVE_TYPE(EXT_DEST_ID) so that live
>>    migration preserves the guest-visible CPUID bit independently of whe=
n
>>    the device model registers its ioreq servers on the destination host
>=20
> So a new save record for a single bit=2E That doesn't look very efficien=
t
> to me=2E
>=20
>> @@ -1106,7 +1107,16 @@ int arch_domain_soft_reset(struct domain *d)
>>   void arch_domain_creation_finished(struct domain *d)
>>   {
>>       if ( is_hvm_domain(d) )
>> +    {
>> +        /*
>> +         * Lock the extended destination ID state=2E OR preserves any =
value
>> +         * already restored from an HVM save record (migration path)=
=2E For a
>> +         * fresh domain, ext_dest_id starts false and the dynamic chec=
k
>> +         * supplies the levelled result across all registered ioreq se=
rvers=2E
>> +         */
>> +        d->arch=2Ehvm=2Eext_dest_id |=3D hvm_ext_dest_id_enabled(d);
>=20
> For an unaware guest, after migration it'll suddenly get the flag set
> if all servers are capable=2E That can't be right=2E It looks pretty muc=
h
> unavoidable for the field to become tristate (unset / false / true)=2E

Thank you Jan=2E You're right true/false is not enough, but there's one=20
migration case left where even a tristate doesn't give a clear answer, I=
=20
believe and I'd like your opinion on that=2E

Scenario: a domain is migrated (or saved/restored) from a Xen that=20
predates this series, onto a new Xen where every registered ioreq server=
=20
has XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID set=2E

So, the incoming stream would not carry a EXT_DEST_ID record, so=20
ext_dest_id_load() never runs and the field would still be=20
EXT_DEST_ID_UNSET when arch_domain_creation_finished() runs on the=20
destination=2E The latch then takes the "fresh domain" path and recomputes=
=20
the levelled value, which here comes out ENABLED=2E

 From that point Xen would interpret the extended destination ID bits=20
for this guest=2E But before the guest ran under a Xen that never=20
advertised XEN_HVM_CPUID_EXT_DEST_ID, so it never used those reserved=20
bits deliberately, but might have written garbage into them accidentaly=2E

I see two ways to handle this:

1=2E Accept it=2E Document that migrating in from a pre-feature Xen onto a=
n=20
all-opted-in host may turn the feature on, and might now treat non-zero=20
reserved bits as extended destionation ID bits=2E
2=2E Distinguish "fresh domain" from "restored without the record" and=20
force the latter to DISABLED=2E A feature-aware guest then picks the=20
feature up on its next reboot on the new host, which matches how every=20
other creation-time-levelled property behaves=2E

The stream is parsed by Xen (the toolstack hands the HVM-context blob to=
=20
XEN_DOMCTL_sethvmcontext -> hvm_load()), so this stays entirely in the=20
hypervisor: add a 'bool context_loaded' to 'struct hvm_domain', set it=20
in the hvm_load(), and in the latch do

if ( d->arch=2Ehvm=2Eext_dest_id =3D=3D EXT_DEST_ID_UNSET )
      d->arch=2Ehvm=2Eext_dest_id =3D
         (!d->arch=2Ehvm=2Econtext_loaded && hvm_ext_dest_id_enabled(d))
         ? EXT_DEST_ID_ENABLED : EXT_DEST_ID_DISABLED;

This would mean one new bool in 'struct hvm_domain' which covers both=20
live migration and xl restore of an old image=2E What do you think? Would=
=20
this be acceptable?

>=20
>>           hvm_domain_creation_finished(d);
>=20
> Blank line please between what you add and what was already there=2E
>=20
>> @@ -325,6 +326,42 @@ void arch_ioreq_domain_init(struct domain *d)
>>       register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
>>   }
>>  =20
>> +int arch_ioreq_server_create_check(const struct domain *d, uint8_t fla=
gs)
>=20
> Bogus use of a fixed-width type again=2E
>=20
>> +{
>> +    if ( !is_hvm_domain(d) || !d->creation_finished )
>> +        return 0;
>=20
> Why the HVM check? ioreq_server_dm_op(), the sole caller, will only ever
> be called for HVM domains (as per the check near the top of dm_op())=2E
>=20
>> +    if ( d->arch=2Ehvm=2Eext_dest_id &&
>> +         !(flags & XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID) )
>> +        return -EPERM;
>> +
>> +    return 0;
>> +}
>> +
>> +static int cf_check ext_dest_id_save(struct vcpu *v, hvm_domain_contex=
t_t *h)
>> +{
>> +    struct hvm_hw_ext_dest_id s =3D {
>> +        =2Eenabled =3D v->domain->arch=2Ehvm=2Eext_dest_id,
>> +    };
>> +
>> +    return hvm_save_entry(EXT_DEST_ID, 0, h, &s);
>> +}
>> +
>> +static int cf_check ext_dest_id_load(struct domain *d, hvm_domain_cont=
ext_t *h)
>> +{
>> +    struct hvm_hw_ext_dest_id s;
>> +
>> +    if ( hvm_load_entry(EXT_DEST_ID, h, &s) )
>> +        return -EINVAL;
>> +
>> +    d->arch=2Ehvm=2Eext_dest_id =3D s=2Eenabled;
>=20
> Afaict this can load arbitrary values other than 0 or 1=2E In fact =2E=
=2E=2E
>=20
>> +    return 0;
>> +}
>> +
>> +HVM_REGISTER_SAVE_RESTORE(EXT_DEST_ID, ext_dest_id_save, NULL,
>> +                          ext_dest_id_load, 1, HVMSR_PER_DOM);
>=20
> =2E=2E=2E I think there's ext_dest_id_check() missing=2E
>=20
>> --- a/xen/arch/x86/hvm/vioapic=2Ec
>> +++ b/xen/arch/x86/hvm/vioapic=2Ec
>> @@ -24,6 +24,7 @@
>>    *  Ported to xen by using virtual IRQ line=2E
>>    */
>>  =20
>> +#include <xen/ioreq=2Eh>
>>   #include <xen/types=2Eh>
>>   #include <xen/mm=2Eh>
>>   #include <xen/xmalloc=2Eh>
>=20
> Is this hunk stale?
>=20
>> @@ -597,6 +598,7 @@ int vioapic_get_trigger_mode(const struct domain *d=
, unsigned int gsi)
>>   static int cf_check ioapic_check(const struct domain *d, hvm_domain_c=
ontext_t *h)
>>   {
>>       const HVM_SAVE_TYPE(IOAPIC) *s;
>> +    unsigned int i;
>=20
> Better =2E=2E=2E
>=20
>> @@ -617,6 +619,24 @@ static int cf_check ioapic_check(const struct doma=
in *d, hvm_domain_context_t *h
>>       if ( s->ioregsel > VIOAPIC_REG_RTE0 + (ARRAY_SIZE(s->redirtbl) - =
1) * 2 + 1 )
>>           return -EINVAL;
>>  =20
>> +    /*
>> +     * If any RTE uses extended destination ID bits, the EXT_DEST_ID s=
ave
>> +     * record must have been loaded first (restoring d->arch=2Ehvm=2Ee=
xt_dest_id)=2E
>> +     * The ioreq server re-registration by the DM happens later, so us=
e the
>> +     * domain-level locked flag rather than the per-server dynamic che=
ck=2E
>> +     */
>> +    for ( i =3D 0; i < ARRAY_SIZE(s->redirtbl); i++ )
>=20
> =2E=2E=2E
>=20
>      for ( unsigned int i =3D 0; i < ARRAY_SIZE(s->redirtbl); i++ )
>=20
>> +    {
>> +        if ( s->redirtbl[i]=2Efields=2Eext_dest_id && !d->arch=2Ehvm=
=2Eext_dest_id )
>> +        {
>> +            printk(XENLOG_G_ERR "HVM restore: %pd IO-APIC RTE %u has "
>> +                                "extended destination ID bits set but =
"
>> +                                "EXT_DEST_ID is not enabled\n",
>> +                                d, i);
>=20
> No, this is the wrong way round=2E As long as we permit guests to put
> non-zero in these bits, we can't demand the bits to be zero here=2E You
> need to avoid interpreting them as extended-ID when the feature isn't
> enabled for a guest=2E
>=20
>> --- a/xen/common/ioreq=2Ec
>> +++ b/xen/common/ioreq=2Ec
>> @@ -641,7 +641,7 @@ static void ioreq_server_deinit(struct ioreq_server=
 *s)
>>   }
>>  =20
>>   static int ioreq_server_create(struct domain *d, int bufioreq_handlin=
g,
>> -                               ioservid_t *id)
>> +                               uint8_t flags, ioservid_t *id)
>=20
> Inappropriate use of a fixed-width type again=2E
>=20
>> @@ -1350,11 +1352,16 @@ int ioreq_server_dm_op(struct xen_dm_op *op, st=
ruct domain *d, bool *const_op)
>>           *const_op =3D false;
>>  =20
>>           rc =3D -EINVAL;
>> -        if ( data->pad[0] || data->pad[1] || data->pad[2] )
>> +        if ( data->flags & ~XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID ||
>=20
> Parentheses please around bitwise logic being operands to boolean logic=
=2E
>=20
>> +             data->pad[0] || data->pad[1] )
>> +            break;
>> +
>> +        rc =3D arch_ioreq_server_create_check(d, data->flags);
>=20
> It's a little odd to have an arch hook here, yet at the same time an
> x86-specific check a few lines up (XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID
> really is meaningless on non-x86, and should hence either be constrained
> to x86 [with the bit position reusable for something else on other
> architectures], or be properly rejected on non-x86)=2E
>=20
>> @@ -455,6 +456,18 @@ int pt_irq_create_bind(
>>           uint64_t msi_addr;
>>           uint32_t msi_data;
>>  =20
>> +        /*
>> +         * Refuse the old MSI bind path when extended destination IDs =
are
>> +         * in use=2E The caller must use XEN_DMOP_bind_pt_msi_irq inst=
ead,
>> +         * which passes the raw MSI address so Xen can decode the exte=
nded
>> +         * bits=2E This old path only carries an 8-bit destination ID =
and
>> +         * would silently misroute interrupts to vCPUs with APIC IDs >=
 255=2E
>=20
> "to" looks ambiguous to me here=2E Maybe better "targeted at"? It's also=
 >=3D 255,
> I think=2E
>=20
>> +         */
>> +        if ( hvm_ext_dest_id_enabled(d) )
>> +        {
>> +            return -EPERM;
>> +        }
>=20
> No need for curly braces here=2E Further I think -EPERM isn't a good cho=
ice, as
> that's what xsm_default_action() returns=2E -EOPNOTSUPP may be an option=
, or
> some other, more "exotic" indicator=2E
>=20
>> --- a/xen/include/public/arch-x86/hvm/save=2Eh
>> +++ b/xen/include/public/arch-x86/hvm/save=2Eh
>> @@ -627,12 +627,27 @@ struct hvm_msr {
>>  =20
>>   #define CPU_MSR_CODE  20
>>  =20
>> +/*
>> + * HVM_SAVE_TYPE(EXT_DEST_ID): domain-level extended MSI destination I=
D state=2E
>=20
> Why MSI when the vIO-APIC uses it as well?
>=20
>> + * Records whether the extended destination ID feature was enabled for=
 this
>> + * domain at the time guest vCPUs were started=2E This allows migratio=
n to
>> + * preserve the setting across hosts without relying on the device mod=
el to
>> + * re-register its ioreq servers before the guest's first CPUID query=
=2E
>> + */
>=20
> The guest's first CPUID query surely is going to happen after at least o=
ne DM
> has registered a server? (For HVM, that is=2E No server may ever be regi=
stered
> for PVH, aiui=2E) It's not quite clear to me why this connection to CPUI=
D
> queries is being made here=2E The flag is necessary at server registrati=
on time,
> as ones not supporting the feature need to be rejected=2E
>=20
>> --- a/xen/include/public/hvm/dm_op=2Eh
>> +++ b/xen/include/public/hvm/dm_op=2Eh
>> @@ -39,18 +39,28 @@ typedef uint16_t ioservid_t;
>>    * XEN_DMOP_create_ioreq_server: Instantiate a new IOREQ Server for a
>>    *                               secondary emulator=2E
>>    *
>> - * The <id> handed back is unique for target domain=2E The valur of
>> + * The <id> handed back is unique for target domain=2E The value of
>>    * <handle_bufioreq> should be one of HVM_IOREQSRV_BUFIOREQ_* defined=
 in
>> - * hvm_op=2Eh=2E If the value is HVM_IOREQSRV_BUFIOREQ_OFF then  the b=
uffered
>> + * hvm_op=2Eh=2E If the value is HVM_IOREQSRV_BUFIOREQ_OFF then the bu=
ffered
>>    * ioreq ring will not be allocated and hence all emulation requests =
to
>>    * this server will be synchronous=2E
>> + *
>> + * If <flags> contains XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID, the server w=
ill
>> + * use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings, pass=
ing
>> + * raw MSI address/data fields so Xen can decode extended destination =
ID
>> + * bits=2E Once any server sets this flag, Xen will advertise
>> + * XEN_HVM_CPUID_EXT_DEST_ID to the guest=2E Must be set before the gu=
est
>> + * vCPUs are started=2E
>=20
> I don't understand the last sentence=2E Is it perhaps stale from how thi=
ngs
> were earlier? There's nothing to "set" here=2E
>=20
>> --- a/xen/include/xen/ioreq=2Eh
>> +++ b/xen/include/xen/ioreq=2Eh
>> @@ -54,9 +54,35 @@ struct ioreq_server {
>>       evtchn_port_t          bufioreq_evtchn;
>>       struct rangeset        *range[NR_IO_RANGE_TYPES];
>>       bool                   enabled;
>> +    bool                   ext_dest_id;
>>       uint8_t                bufioreq_handling;
>>   };
>>  =20
>> +/*
>> + * Return true if every registered ioreq server has opted in to extend=
ed
>> + * destination IDs (XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID) and at least on=
e
>> + * server exists=2E
>=20
> Why is one server existing relevant?
>=20
>> A single server without the flag is enough to suppress
>> + * XEN_HVM_CPUID_EXT_DEST_ID, preventing misrouted interrupts=2E
>> + */
>> +static inline bool hvm_ext_dest_id_enabled(const struct domain *d)
>> +{
>> +    unsigned int i;
>> +    bool found =3D false;
>> +
>> +    for ( i =3D 0; i < MAX_NR_IOREQ_SERVERS; i++ )
>=20
> Please use ARRAY_SIZE() in such cases=2E
>=20
>> +    {
>> +        const struct ioreq_server *s =3D d->ioreq_server=2Eserver[i];
>> +
>> +        if ( !s )
>> +            continue;
>> +        if ( !s->ext_dest_id )
>=20
> As there's no locking here, and as the comment ahead of the function als=
o
> doesn't mention any locking requirements: What guarantees s to still be
> valid to deref here? Furthermore, what guarantees the result of this
> function to not be stale by the time the caller looks at it? (Some of
> this may be easier if this wasn't an inline function in a globally
> visible header=2E)
>=20
> Jan
>=20



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orch=
estra - Vates solutions

web: https://vates=2Etech
---=Part.2e0b.a407e214bb689b6.1a04791cb12.2ded673d79bf949=---


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 08:59:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 08:59:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401788.1637313 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzsQv-0004J9-1K; Fri, 28 Aug 2026 08:59:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401788.1637313; Fri, 28 Aug 2026 08:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzsQu-0004J2-UU; Fri, 28 Aug 2026 08:59:32 +0000
Received: by outflank-mailman (input) for mailman id 1401788;
 Fri, 28 Aug 2026 08:59:30 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzsQs-0004Hq-R3
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 08:59:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzsQs-00Bqnn-3x
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:59:30 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a914de8-e002-0a2a0a5209dd-0a2a450bccca-18
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:59:30 +0200
Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a914df0-b7e8-0a2a450b0019-d1558031d50c-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:59:28 +0200
Received: by mail-wm1-f49.google.com with SMTP id
 5b1f17b1804b1-490cf322ed0so6866795e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 01:59:28 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b4c321184sm145250985e9.11.2026.08.28.01.59.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 01:59:27 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787907568; x=1788512368; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qqp1RaaIjNS9UokBVkvy6Ld1z6fOigYRhXOIVNTxHZQ=;
        b=qoCMo5w7DVa4SQWK3x6M+D2OBZuhAX20a/9StvMbTrEUu9BNdmNdBrjU+OeHkpN/Rn
         3SKzz4jvDbWNOapCTP3A0BNt40X6A/eEoibwV4T7poKj9rtMxeLmZMi+1976EPSmfKOk
         w/z1NUZ8Cevp3ztZzhHCehXtw1n/VMAQfJn2iiZOhgHoAkFvbApPCS10PP1hd0JB89wE
         3LnPJmory4Uetcn/7FLmpATZIXVBSE5ts3BMOMdtEMbYlKEMP09fQjTW76CIYQmovw1j
         cDPG40DJJa6oM8H/V7dWSqSOHX6fXF2yYwEne1JRarc02TKjBTZBay0OForm2Y/ftm+O
         M34Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787907568; x=1788512368;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=qqp1RaaIjNS9UokBVkvy6Ld1z6fOigYRhXOIVNTxHZQ=;
        b=bX7Ix7chpQ+kFm0XdybQnk2Ou+nAEbo2OKKmY4DpWEuJMWnWij46OJrMwleGmtqC+H
         Zk4M+ifrqzkaLiZaVeFvU/WRMGR3eSLZTdO5wSvxiNMbaigXdzLC6HTMjPHqHkm+tmWE
         4TCA68+kMLlAbXgpuFpa6tX5IPmk2vEjCFk5pIz5dex3wZ1gaTEODJI5mjKx2/W4EWo7
         z0Ty12hokYVgbumzXII8fP6xpaHTg3xOJJGi1qcMdpQ4YwKsL45duvnXbo4Xquh5NhZs
         FRc+kCl/8ObAvATifX99iKP5RRg6wjwMeZS2TDl6F1aq81Ytw9RHQVcg4MsuOp6X9HYD
         7ENw==
X-Forwarded-Encrypted: i=1; AHgh+RqDKxML0Jp+OcHFD6W2rsHzAQ9fIkIaKs2C41Y65vCWTZEe3M+nQfUSh3xaWZeeFb2oUZu4tzoMK6Y=@lists.xenproject.org
X-Gm-Message-State: AFuF++mHpgR9pG8FLm/pNBx8eLSKdLKf5MXvcfO+dHfoIlZJesdxhvIk
	qz5eZvo5VpMfCgEDKGVao9mCiqOo0kZ7EmBeHd+o0ZjA8lTJpRBEt7uT
X-Gm-Gg: AR+sD10huN+cKQM19z2Jy7W0B0s9uXHMsVs91w0uB7gp7jZUlxsbdNtd7W+uX8917mC
	SmrfIfr5R4sF3F6cfeiMHuUtJ78k5OdmFxx2QcNIhYquLBtZ0ffYCKlC0unJoZE8qZRF6KOCUqM
	0TJ1HxI72+Q3eTdO7Bu/phSmd5t7JUk1rIldxYoqkhICPTDBMIiXeHc/boNRE2L4/JD2l7uHhMb
	IgqBAPqnYZN2oz9DB2ZMRigLv03NJ0piLAroZPtI57mbttbGCuqWaLktc7IchAtdRZ2rOCRlk+b
	c9QVngWpKxb+ssiptS3d3EMYXkylH9Ml+ukTVJohc0VgGsnofhcHMH3VVjfWgO51Lxzz/zUo+jv
	oAOIbCCvh0vTIIuX2uZ23ZxBKc6ijkv8/ckG47DrrbJx1qSbEG4QmLD44rnDVM6h1019CkGweez
	NQVwF5V4x4c11hGW/Xv9BAhEsGt19H6bD24VNmcXr0rfaSviRftf0RkTkxZhPPm738ldcUl3xFS
	+kHjDSeaKijj1O49AKS9gBCCVk9H4BwSvgoT6Wtk/JKtletn/nH
X-Received: by 2002:a05:600c:698c:b0:499:adb5:e7b2 with SMTP id 5b1f17b1804b1-49b91c3ddc7mr96584255e9.11.1787907567940;
        Fri, 28 Aug 2026 01:59:27 -0700 (PDT)
Message-ID: <92b8d7f1-6a29-4345-9a77-71741a9f34e9@gmail.com>
Date: Fri, 28 Aug 2026 10:59:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/5] xen/riscv: make Zihintpause no longer a required
 extension
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787907568-2C39B9EA-5BA1DBA2/10/73395122804
X-purgate-type: spam
X-purgate-size: 4535



On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> required_extensions[] panics at boot if Zihintpause is missing, but Xen
> never actually depends on it: cpu_relax() only emits the "pause" when the
> extension is implemented and otherwise falls back to the, which is a legal no-op on any hart regardless of Zihintpause
> support.

You raise a very valid point. Strictly speaking, stating that it "falls 
back to a legal no-op" can be slightly misleading because it implies the 
instruction is decoded as a literal NOP (addi x0, x0, 0).

In reality, the fallback is a fully valid FENCE instruction 
(specifically encoded as `0x0100000F`, which represents `FENCE W, 0`).

Here is why this distinction matters and why it is safe:
1. Since the FENCE instruction is a mandatory part of the RISC-V Base 
Integer Instruction Set (RV32I/RV64I), it is guaranteed to be present on 
any compliant hart. Thus, it will never trigger an "illegal instruction" 
trap.
2. When the Zihintpause extension is not implemented, the hart decodes 
and executes this instruction as a standard FENCE with a predecessor set 
of 'W' (writes) and an empty (null) successor set of '0'.
3. Because the successor set is empty, it imposes zero memory-ordering 
constraints on subsequent instructions.

Thereby I think this part of commit message will be better to re-word in 
the following way:
```
The fallback encoding `0x0100000F` is a legally valid FENCE instruction 
(`FENCE W, 0`) rather than a native NOP. Since FENCE is guaranteed by 
the RISC-V Base ISA, it will never raise an illegal instruction fault. 
In the absence of Zihintpause, it executes with an empty successor set, 
enforcing zero memory-ordering constraints and thus architecturally 
behaving as a NOP.
```


> 
> Drop it from required_extensions so hardware without Zihintpause
> still boots.
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> ---
>   xen/arch/riscv/cpufeature.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
> index 900cb9d772..661babc0a6 100644
> --- a/xen/arch/riscv/cpufeature.c
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -155,7 +155,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
>       RISCV_ISA_EXT_DATA(h),
>       RISCV_ISA_EXT_DATA(zicsr),
>       RISCV_ISA_EXT_DATA(zifencei),
> -    RISCV_ISA_EXT_DATA(zihintpause),
>       RISCV_ISA_EXT_DATA(zbb),
>   };
>   

It is also needed then to update docs/misc/riscv/booting.txt.

Generally, I agree that zihintpause should be dropped from 
required_extensions[]. One thing I would like to point out is that, once 
we do that, cpu_relax() may no longer provide a pause hint on hardware 
that doesn't implement zihintpause, even if the hardware provides its 
own pause instruction with different semantics from a fence which does 
nothing.

For example, the MIPS P8700 provides its own pause instruction with a 
different encoding from:

__asm__ __volatile__ ( ".insn r MISC_MEM, 0, 0, x0, x0, x16" );

Using fence in this case would not be power-efficient, as it behaves as 
a no-op.

For the MIPS P8700, for example:

#define MIPS_PAUSE    ASM_INSN_I("0x00501013\n\t")
#define MIPS_EHB      ASM_INSN_I("0x00301013\n\t")
#define MIPS_IHB      ASM_INSN_I("0x00101013\n\t")


I believe there are other implementations that don't use zihintpause but 
provide their own pause instruction as well.

Therefore, I suggest adding the following to riscv_fill_hw_cap():

/*
  * Zihintpause isn't mandatory: the encoding used by cpu_relax() is a
  * HINT which executes as a no-op on hardware without the extension.
  * Report it, as a platform may provide its own way to hint a spin-wait
  * loop, which then has to be wired up in cpu_relax().
  */
if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_zihintpause) )
     printk(XENLOG_WARNING
            "Zihintpause unavailable: cpu_relax() gives the CPU no hint; "
            "wire up this platform's pause equivalent in cpu_relax()\n");


Without such a check, we could easily miss updating cpu_relax() for 
platforms with their own pause mechanism. While having zihintpause as a 
required extension implicitly forces us to consider this, once it is no 
longer required, I think we should keep an explicit indication that the 
platform-specific pause mechanism may need to be wired up.

Thanks.

~ Oleksii



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 09:16:37 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 09:16:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401804.1637322 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzshL-0001y6-D4; Fri, 28 Aug 2026 09:16:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401804.1637322; Fri, 28 Aug 2026 09:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzshL-0001xz-9u; Fri, 28 Aug 2026 09:16:31 +0000
Received: by outflank-mailman (input) for mailman id 1401804;
 Fri, 28 Aug 2026 09:16:30 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a047a7f351000c4f3@swg.vates.tech>)
 id 1wzshJ-0001xt-VC
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:16:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzshJ-000AXW-Bs
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 11:16:29 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a047a7f351000c4f3@swg.vates.tech>)
 id 6a9151e3-8faa-0a2a0a5109dd-0a2a450c8cb6-14
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 11:16:29 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a047a7f351000c4f3@swg.vates.tech>)
 id 6a9151ec-f479-0a2a450c0019-b9ff1c23a0c5-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 11:16:29 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a047a7f351000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 28 Aug 2026 09:16:24 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 8D39083B3C;
 Fri, 28 Aug 2026 11:16:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=bpLWXRcoAXBYkPhXEckK5N+1EASBF3iYMH32h1CXgFM=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=YcDA5HDo/alGROeI2hUqIf+YHWBhEGq60SZammnAUARjmOU32+i8jlCd9IURAjiem0UfQqvAP
 OAmoAcC4iVy6Y7suf9Bj5opzue1V+OfxbOT9eRFowbuhekofYuRhzVm630x627knPTrnFW1UvjU
 XBH3F1fDW9FDIxZvR6YBYF6ppDtfhXWMAWNToP5Q5x/v1kl3TdfMpP6PloFQaHUXBxFM/H9Wfjj
 bZpjW3sUQWLwdXK+tHqxTq2WDDFzYkuYMVJ6y56S2icvg3bDR0QzTxyXHdphkV0HfS92GqrXQHP
 9totW7qHwStNoAz4mN3YwjP3ymPknxsnrk8jTJNhA2TQ==
X-Zone-Loop: b1707fee90aa32bd2371c9c5f38919d308ee4482c985
x-campaign-type: default
x-transaction-id: 393f0f08-e9b6-4d14-a8e2-b798757af45b
x-swg-uid: 01-5be2e115-a207-41b1-992e-e108e9d02fce
X-Mailer: Sweego
Message-ID:
 <1787908584.8631fc262581453bbf619ec5b2062170.1a047a7f351000c4f3@vates.tech>
x-swg-bid: 1787908584.8631fc262581453bbf619ec5b2062170.1a047a7f351000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH 4/5] xen/riscv: make Zihintpause no longer a required
 extension
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <92b8d7f1-6a29-4345-9a77-71741a9f34e9@gmail.com>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad47c000c4f3@vates.tech>
 <92b8d7f1-6a29-4345-9a77-71741a9f34e9@gmail.com>
Date: Fri, 28 Aug 2026 11:16:18 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1787908583; l=5027;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=xJ2yEegfsnrPmaZ/jjZowAWrHDD+/f2kJyPr7Yk7iSw=;
 b=v57mcyUnSeaENwSm+RguKg+gLtjrKkaMboEbUwMDppLuD4Y9b0CLIV4Eamvxfqa2rLXgMV02d
 tiaA6/4GcL5Do5LejT8Ol+bJqXdYKccRa7d0OQTanBS5IrsnfQJJTp9
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787908583770
X-purgate-ID: tlsNG-d25034/1787908589-76CDBA5B-9A7768CE/0/0
X-purgate-type: clean
X-purgate-size: 5031

On 2026-08-28 10:59 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> > required_extensions[] panics at boot if Zihintpause is missing, but Xen
> > never actually depends on it: cpu_relax() only emits the "pause" when the
> > extension is implemented and otherwise falls back to the, which is a legal no-op on any hart regardless of Zihintpause
> > support.
> 
> You raise a very valid point. Strictly speaking, stating that it "falls 
> back to a legal no-op" can be slightly misleading because it implies the 
> instruction is decoded as a literal NOP (addi x0, x0, 0).
> 
> In reality, the fallback is a fully valid FENCE instruction 
> (specifically encoded as `0x0100000F`, which represents `FENCE W, 0`).
> 
> Here is why this distinction matters and why it is safe:
> 1. Since the FENCE instruction is a mandatory part of the RISC-V Base 
> Integer Instruction Set (RV32I/RV64I), it is guaranteed to be present on 
> any compliant hart. Thus, it will never trigger an "illegal instruction" 
> trap.
> 2. When the Zihintpause extension is not implemented, the hart decodes 
> and executes this instruction as a standard FENCE with a predecessor set 
> of 'W' (writes) and an empty (null) successor set of '0'.
> 3. Because the successor set is empty, it imposes zero memory-ordering 
> constraints on subsequent instructions.
> 
> Thereby I think this part of commit message will be better to re-word in 
> the following way:
> ```
> The fallback encoding `0x0100000F` is a legally valid FENCE instruction 
> (`FENCE W, 0`) rather than a native NOP. Since FENCE is guaranteed by 
> the RISC-V Base ISA, it will never raise an illegal instruction fault. 
> In the absence of Zihintpause, it executes with an empty successor set, 
> enforcing zero memory-ordering constraints and thus architecturally 
> behaving as a NOP.
> ```
I agree with this suggestion, thanks.
> 
> 
> > 
> > Drop it from required_extensions so hardware without Zihintpause
> > still boots.
> > 
> > Assisted-by: Claude:claude-opus-5
> > Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> > ---
> >   xen/arch/riscv/cpufeature.c | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
> > index 900cb9d772..661babc0a6 100644
> > --- a/xen/arch/riscv/cpufeature.c
> > +++ b/xen/arch/riscv/cpufeature.c
> > @@ -155,7 +155,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
> >       RISCV_ISA_EXT_DATA(h),
> >       RISCV_ISA_EXT_DATA(zicsr),
> >       RISCV_ISA_EXT_DATA(zifencei),
> > -    RISCV_ISA_EXT_DATA(zihintpause),
> >       RISCV_ISA_EXT_DATA(zbb),
> >   };
> >   
> 
> It is also needed then to update docs/misc/riscv/booting.txt.
> 
> Generally, I agree that zihintpause should be dropped from 
> required_extensions[]. One thing I would like to point out is that, once 
> we do that, cpu_relax() may no longer provide a pause hint on hardware 
> that doesn't implement zihintpause, even if the hardware provides its 
> own pause instruction with different semantics from a fence which does 
> nothing.
> 
> For example, the MIPS P8700 provides its own pause instruction with a 
> different encoding from:
> 
> __asm__ __volatile__ ( ".insn r MISC_MEM, 0, 0, x0, x0, x16" );
> 
> Using fence in this case would not be power-efficient, as it behaves as 
> a no-op.
> 
> For the MIPS P8700, for example:
> 
> #define MIPS_PAUSE    ASM_INSN_I("0x00501013\n\t")
> #define MIPS_EHB      ASM_INSN_I("0x00301013\n\t")
> #define MIPS_IHB      ASM_INSN_I("0x00101013\n\t")
> 
> 
> I believe there are other implementations that don't use zihintpause but 
> provide their own pause instruction as well.
> 
> Therefore, I suggest adding the following to riscv_fill_hw_cap():
> 
> /*
>   * Zihintpause isn't mandatory: the encoding used by cpu_relax() is a
>   * HINT which executes as a no-op on hardware without the extension.
>   * Report it, as a platform may provide its own way to hint a spin-wait
>   * loop, which then has to be wired up in cpu_relax().
>   */
> if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_zihintpause) )
>      printk(XENLOG_WARNING
>             "Zihintpause unavailable: cpu_relax() gives the CPU no hint; "
>             "wire up this platform's pause equivalent in cpu_relax()\n");
> 
> 
> Without such a check, we could easily miss updating cpu_relax() for 
> platforms with their own pause mechanism. While having zihintpause as a 
> required extension implicitly forces us to consider this, once it is no 
> longer required, I think we should keep an explicit indication that the 
> platform-specific pause mechanism may need to be wired up.
> 
> Thanks.
Good catch, thanks for that. I agree with what you said to not forget
platforms that use their own pause mechanism. I will add what you
suggested in v2.
> 
> ~ Oleksii
> 
> 
Thanks.
> 
> 




From xen-devel-bounces@lists.xenproject.org Fri Aug 28 09:22:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 09:22:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401816.1637331 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzsmp-0004ce-32; Fri, 28 Aug 2026 09:22:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401816.1637331; Fri, 28 Aug 2026 09: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1wzsmo-0004cX-VP; Fri, 28 Aug 2026 09:22:10 +0000
Received: by outflank-mailman (input) for mailman id 1401816;
 Fri, 28 Aug 2026 09:22:10 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jbeulich@suse.com>) id 1wzsmo-0004aH-4t
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:22:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzsmm-001WyR-Vc
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 11:22:08 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91533c-2eae-0a2a0a5409dd-0a2a4504893e-18
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 11:22:08 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jbeulich@suse.com>)
 id 6a91533e-b57f-0a2a45040019-d155dd2fb4f7-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 11:22:06 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-482c58a8683so595198f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 02:22:06 -0700 (PDT)
Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de.
 [37.24.206.209]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbb2005esm2531975f8f.24.2026.08.28.02.22.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 02:22:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787908926; x=1788513726; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=J8x0DPP9PsuPB3T5rQ9y6Mu33wB98PnoVbClKkkZ+C0=;
        b=InfXA/c3m9fzVmh1SLGR1wJkKIU1rurYL18XbQNEjKWq+3WDET1UI1nCPaL+PxWzta
         8S5DPEAeuK0YjXXdmoEsUcfWwjhhmuKoazD3k4smG+Trc/6sDt9+FAOFgc7on8FoEG7N
         qwUYMDwWQp2EvVZISyzoe6u3fsW6Fi+NsdPECVVlIMtJw4tj433BkmyPZY7kFzoo3HUL
         l9oJaBSIVVCxeq1gK/ZhtrXeHatA//BYiIcJtRJSfS6EoVsVrBoSSmWJBY9CJ5f9Tdyd
         lfsc/II11L1k+If9L5Agoz9LJpJKtz8IDUX+SaxS5flAyQJH47T61RO70jE7pyyo2f8A
         2wIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787908926; x=1788513726;
        h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=J8x0DPP9PsuPB3T5rQ9y6Mu33wB98PnoVbClKkkZ+C0=;
        b=dFcP4afOL3Afi/0e9XKwsZ0WkrwCTnIxg1fu4E2/H5AhCK3OsLxaGj1TMQ0EJsSBqK
         kaSIXUXdSZfzEK/XZVx3PgNL2m1X+7QalLTtzOXaZ3bW1t/lILcBrmJ/1L4U4PpINQrn
         7hfq1zvokoaeWEeOmf53jYuQkNWQ0Yqj3pmgy6MagvL7MJu3DZ9N0qbI6neNArgUBu2X
         469fu6mH3PLIV97D5x8wKFIRa9HYdcOyOnGOH/NGEvKjL1Xeqo6K+TPjrpLghENrTwzo
         3QqXvzUPPwMrjPyztvPEXefUHTmCOd+/B7+PGe9g9bwphYWj0I8ntNIKs4eyvnaRC5GI
         CkqA==
X-Forwarded-Encrypted: i=1; AHgh+Rq9gIWNHjY2ESPNo7Zi96yM11K/hFc7mykpqyxm3VXwwhrVKtisXr3rwhyRmWTTjd86RF7fBQcMVU4=@lists.xenproject.org
X-Gm-Message-State: AFuF++lqSWJoeY0iceiK3x/wvJhBzNiU0X3T8D15qLT354VX3CV26kV8
	DclEYP0NMDy49A9Yvr3eTOaaeMnOA3p1rQrOwfLjqa9oOEL5lkJmFEvWFaniCI9+dA==
X-Gm-Gg: AR+sD11VdR6OjbirBmxPEyOALnc7p0u/zdtHpMGn01nFbVVNdhaQKy7PVJG6/bTkU7k
	fzUm/mFx37n8oN4c0MhKi4NGpHRGPjAq2qApk11OrjiPWqDZCaAk0UKoQYbwSRjTadi4doy56W+
	CmTASyClEIED1AfMD37QL2VMyWTm5IyF0dDb7qF5X9PbFqHYnZzCie4HVdrC8163+INcXYc+Rgs
	GcGsUVmVsxm9gBoz9nt/H0a2NQdDjxCBcWQLNvCdXOqEUoCMG2AO6hcwFjjcwUOXFk7gMT5Bisi
	Y6+hQfS3xMss7Dl7HUs9ULdfFvf8NS1hv8eGwmVErjWcZdzGAR8kA8AzCBw2ylS4Xgkmhq2lQUy
	Mlxl9VYFFXR6E+SXy7watw0k/xXSMOaF5k30e7Du6pGUo0iCWRGWk76UHbAxm1M9kM54YP8rorg
	eTubr/8UeY5dqqT+sWv1b8+A0B03QfIUOxq+jdeXHuhnoMrlYwGSVIDdvn0fm1Uh8NJjr7wom2u
	6jxCS3YppfTVx3WuHS9vOeaII58mEJiZuQmA0VuRanIt9dIEcBu/jSbWQN2PhY=
X-Received: by 2002:a05:6000:4701:b0:482:f930:9524 with SMTP id ffacd0b85a97d-482f9309980mr5744841f8f.10.1787908926230;
        Fri, 28 Aug 2026 02:22:06 -0700 (PDT)
Message-ID: <17c4ad74-6108-452d-923b-755fd37e4381@suse.com>
Date: Fri, 28 Aug 2026 11:22:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 8/9] hvm/ioreq: Negotiate extended destination ID
 support per ioreq server
To: Julian Vetter <julian.vetter@vates.tech>
Cc: Anthony PERARD <anthony.perard@vates.tech>,
 Juergen Gross <jgross@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
 Michal Orzel <michal.orzel@amd.com>, Julien Grall <julien@xen.org>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Stefano Stabellini <sstabellini@kernel.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Teddy Astie <teddy.astie@vates.tech>, xen-devel@lists.xenproject.org
References: <20260427135406.1281424-1-julian.vetter@vates.tech>
 <1777298081.8631fc262581453bbf619ec5b2062170.19dcf3886cc000f373@vates.tech>
 <a9510f21-b7a8-4323-a64d-0f33e44cd8b0@suse.com>
 <1787907132.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3@vates.tech>
Content-Language: en-US
From: Jan Beulich <jbeulich@suse.com>
Autocrypt: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee
 e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF
 hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l
 IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS
 FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj
 t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8
 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3
 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9
 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V
 m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM
 EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr
 wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A
 nAuWpQkjM1ASeQwSHEeAWPgskBQL
In-Reply-To: <1787907132.8631fc262581453bbf619ec5b2062170.1a04791cd47000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ebf023/1787908926-538C1B50-F8CD378D/0/0
X-purgate-type: clean
X-purgate-size: 3757

On 28.08.2026 10:52, Julian Vetter wrote:
> On 8/19/26 16:38, Jan Beulich wrote:
>> On 27.04.2026 15:54, Julian Vetter wrote:
>>> @@ -1106,7 +1107,16 @@ int arch_domain_soft_reset(struct domain *d)
>>>   void arch_domain_creation_finished(struct domain *d)
>>>   {
>>>       if ( is_hvm_domain(d) )
>>> +    {
>>> +        /*
>>> +         * Lock the extended destination ID state. OR preserves any value
>>> +         * already restored from an HVM save record (migration path). For a
>>> +         * fresh domain, ext_dest_id starts false and the dynamic check
>>> +         * supplies the levelled result across all registered ioreq servers.
>>> +         */
>>> +        d->arch.hvm.ext_dest_id |= hvm_ext_dest_id_enabled(d);
>>
>> For an unaware guest, after migration it'll suddenly get the flag set
>> if all servers are capable. That can't be right. It looks pretty much
>> unavoidable for the field to become tristate (unset / false / true).
> 
> Thank you Jan. You're right true/false is not enough, but there's one 
> migration case left where even a tristate doesn't give a clear answer, I 
> believe and I'd like your opinion on that.
> 
> Scenario: a domain is migrated (or saved/restored) from a Xen that 
> predates this series, onto a new Xen where every registered ioreq server 
> has XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID set.
> 
> So, the incoming stream would not carry a EXT_DEST_ID record, so 
> ext_dest_id_load() never runs and the field would still be 
> EXT_DEST_ID_UNSET when arch_domain_creation_finished() runs on the 
> destination. The latch then takes the "fresh domain" path and recomputes 
> the levelled value, which here comes out ENABLED.

Well - I thought it was clear that by the time the domain is actually
launched, the 3rd ("unset") value would need resolving.

>  From that point Xen would interpret the extended destination ID bits 
> for this guest. But before the guest ran under a Xen that never 
> advertised XEN_HVM_CPUID_EXT_DEST_ID, so it never used those reserved 
> bits deliberately, but might have written garbage into them accidentaly.
> 
> I see two ways to handle this:
> 
> 1. Accept it. Document that migrating in from a pre-feature Xen onto an 
> all-opted-in host may turn the feature on, and might now treat non-zero 
> reserved bits as extended destionation ID bits.
> 2. Distinguish "fresh domain" from "restored without the record" and 
> force the latter to DISABLED. A feature-aware guest then picks the 
> feature up on its next reboot on the new host, which matches how every 
> other creation-time-levelled property behaves.

Imo 2 is the only viable option.

> The stream is parsed by Xen (the toolstack hands the HVM-context blob to 
> XEN_DOMCTL_sethvmcontext -> hvm_load()), so this stays entirely in the 
> hypervisor: add a 'bool context_loaded' to 'struct hvm_domain', set it 
> in the hvm_load(), and in the latch do
> 
> if ( d->arch.hvm.ext_dest_id == EXT_DEST_ID_UNSET )
>       d->arch.hvm.ext_dest_id =
>          (!d->arch.hvm.context_loaded && hvm_ext_dest_id_enabled(d))
>          ? EXT_DEST_ID_ENABLED : EXT_DEST_ID_DISABLED;
> 
> This would mean one new bool in 'struct hvm_domain' which covers both 
> live migration and xl restore of an old image. What do you think? Would 
> this be acceptable?

I don't quite get why that's better than converting the boolean to a
tristate.

Also may I please remind you again to trim your replies? Below here,
for example, there was only reply quoting. That serves no purpose in
your reply. Yet I still needed to scroll through all of it to see
whether there was some other comment of yours. And every other reader
likely will also end up doing so.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 09:38:09 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 09:38:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401829.1637339 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzt28-0000Pc-9l; Fri, 28 Aug 2026 09:38:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401829.1637339; Fri, 28 Aug 2026 09:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzt28-0000PU-6r; Fri, 28 Aug 2026 09:38:00 +0000
Received: by outflank-mailman (input) for mailman id 1401829;
 Fri, 28 Aug 2026 09:37:58 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wzt26-0000PN-Mf
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:37:58 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wzt26-009zoV-1B;
 Fri, 28 Aug 2026 09:37:58 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wzt25-00G23P-2Y;
 Fri, 28 Aug 2026 09:37:58 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=V42N1s76PU9hlOX8CkrzYvjBpNAXKMnOiAvs6hvwk5Y=; b=2stE97ZpSlB1WB16qSo8yN4U12
	Y3m9II9uWSkUWkiZ2AoapVAxY3yjz2Y1gFnsBntmfroafVuK45ien498c+y3YPIAiQvue9Odm963b
	AZV9jXAUuNbvB5PfGnRWzkEZdlkzt/0mfC4bVhC4ecfryUoQtPPKAO07pYaVnEN16s8c=;
Date: Fri, 28 Aug 2026 11:37:48 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Gui-Dong Han <hanguidong02@gmail.com>
Cc: xen-devel@lists.xenproject.org, axboe@kernel.dk,
	linux-block@vger.kernel.org, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, baijiaju1990@gmail.com
Subject: Re: [PATCH] xen/blkback: Prevent missed completion when draining I/O
Message-ID: <apFW7CH1aZasMKiV@macbook.local>
References: <20260730084000.3305702-1-hanguidong02@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260730084000.3305702-1-hanguidong02@gmail.com>

On Thu, Jul 30, 2026 at 04:40:00PM +0800, Gui-Dong Han wrote:
> xen_blk_drain_io() sets drain before checking inflight.
> xen_blkbk_unmap_and_respond_callback() decrements inflight with
> atomic_dec_and_test() before checking drain.
> 
> The pre-wait condition check was added to avoid missing a completion, but
> atomic_set() is unordered. With one I/O in flight, the drain path can set
> drain to 1 and read inflight as 1 before the completion decrement. The
> completion path then decrements inflight to 0 but can still read drain as
> 0. It skips complete(), so the drain path waits until the timeout despite
> no I/O remaining.
> 
> Add a full barrier between setting drain and reading inflight.
> atomic_dec_and_test() already provides full ordering on the completion
> side.
> 
> Fixes: 6927d92091df ("xen/blkback: Fix two races in the handling of barrier requests.")
> Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>

Sorry for the delay, this slipped through the cracks:

Acked-by: Roger Pau Monné <roger@xenproject.org>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 09:41:32 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 09:41:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401839.1637348 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzt5W-0002R5-O2; Fri, 28 Aug 2026 09:41:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401839.1637348; Fri, 28 Aug 2026 09:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzt5W-0002Qy-Kw; Fri, 28 Aug 2026 09:41:30 +0000
Received: by outflank-mailman (input) for mailman id 1401839;
 Fri, 28 Aug 2026 09:41:29 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <roger@xenproject.org>) id 1wzt5V-0002Qs-Jm
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:41:29 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wzt5V-009zth-0d;
 Fri, 28 Aug 2026 09:41:28 +0000
Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224]
 helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from <roger@xenproject.org>) id 1wzt5U-00Gh0O-22;
 Fri, 28 Aug 2026 09:41:28 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:
	Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=U2BG25GqoxZT7zM9nFPfTYkm+YCYfTMQeu4PuwjB3iI=; b=MajoEN+WX4hX9tnyngwM2tV3hc
	4TUHxO+Lh2O/pSYgCET3po020lJNRF7rIWaWWZsHzmTOUjTXtHu3DH/dUKH6MGOeP1co5yoJAxh2S
	OS7lgVfumI0igoWSIAIwFxu7Y+oa9hTXMaVBW3CVwx8i1+8krstnlOruSxp/alKSX/+0=;
Date: Fri, 28 Aug 2026 11:41:16 +0200
From: Roger Pau =?utf-8?B?TW9ubsOp?= <roger@xenproject.org>
To: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
Cc: xen-devel@lists.xenproject.org, Teddy Astie <teddy.astie@vates.tech>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] x86/cpuid: gate the hypervisor PV-only leaf on
 is_pv_domain()
Message-ID: <apFXvKqbWiaopd8X@macbook.local>
References: <20260826072526.767424-1-Zhao.Jiaqing@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260826072526.767424-1-Zhao.Jiaqing@amd.com>

On Wed, Aug 26, 2026 at 03:25:26PM +0800, Jiaqing Zhao wrote:
> Hypervisor leaf 5 is PV-specific, but is gated with !is_hvm_domain(),

I would maybe write "..., but is gated using is_hvm_domain()".

> which stays a runtime test in a build without PV support. Test for a
> PV domain directly so the compiler can discard the leaf when
> CONFIG_PV is disabled.
> 
> Suggested-by: Roger Pau Monné <roger@xenproject.org>
> Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@amd.com>

Acked-by: Roger Pau Monné <roger@xenproject.org>

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 09:55:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 09:55:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401852.1637358 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wztIc-00062v-QK; Fri, 28 Aug 2026 09:55:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401852.1637358; Fri, 28 Aug 2026 09:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wztIc-00062o-Mb; Fri, 28 Aug 2026 09:55:02 +0000
Received: by outflank-mailman (input) for mailman id 1401852;
 Fri, 28 Aug 2026 09:55:01 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <nicola.vetrini@bugseng.com>) id 1wztIb-00062i-FA
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 09:55:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wztIa-000Iww-SQ
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 11:55:00 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a915ae7-2eae-0a2a0a5409dd-0a2a450be12e-18
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 11:55:00 +0200
Received: from [162.55.131.47] (helo=support.bugseng.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a915af4-b7e8-0a2a450b0019-a237832fc55a-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 11:55:00 +0200
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 4C2784EE0050;
 Fri, 28 Aug 2026 11:55:00 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1787910900;
	b=ikMy5bMPghpfJVk38GCkStPTsvdsPJrjp51BXgm6h90AmcM/6JdadIO1MOryeFvV9a1y
	 sQaIF4EnzDm3DJvunPQvikxV0NJ7TY7iCCdPDeb8/ogNhWO41qwTEsS96IgFvm8yl9gvn
	 NRQevjdaSgDp4+WaNCPubEoFa2HEWCcilywEHW/W4cnESzEVFUnzsxPERDtpoUFfpOiJK
	 C1VcyDmTqcuzb4Lhy1dzd7zclaGTZMiSmtvm3rvTly8WA42zOHPetN0DmERIU7pFRI/xw
	 nL4sb4PKGIoixCoYFB/HlEyhK4kWaE102uPeTqTyAXEWzhq3xnxv8NABusJAyc/HFOV53
	 m5x6e/Y/FNnEwnFe15g1Ywi50eRTZahfw8pikuolsQ3oYWSs3NmVTu1RhAtPwvQ9A9nHp
	 IR9Ow/tfF0N5+tsreY4Ja7Q7F9SvGpqUpk3yCY6e5qz4Gv/MQouybNPUXdPTQzYX+bx1e
	 s8Qu5R0msTm5r9tX2WYAgV5+jHEJVahc8FtLbPne9ayJ5J425v0MLBk9xTRiONwfi8rsx
	 CkuwtGbE1VQp5mPaS1gDfP+eZAXN3FQdlIxLWsmEnfH1dD/Kt3HLwP/XPOBAIRr8AmTdk
	 HV1P7T3zJ00UvnjDNFNaS9KsHAvKc59893Ul4rWUiv/w3+dAYFShjmz8whXw2DE=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1787910900;
	h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=iCyUO/jVJ1XT4h9kGqdidMW3hXotDizvbYQalvOgQTE=;
	b=UPeuUEMe2MKJQqBGzhRmT3XsMYTrevD5MVb6Mxpzwp592gybluxwY4XpLDkmRUIJXcQX
	 yKQkk7Vfr0O3W467DXRHeFbtp8epvPh5ot45r1MHM8qGpF3nbRRURswIf43JqW7YMplqo
	 2aeSn3UypEZLi/8y5DnwIPTrc395z/6cZicfGMhHE8bJY2Px95qRa0RjZkrSGhPEOnffm
	 /+CWvDs2kIQnlt4sjPHEQi44d/REsElVnkVheaXdEGhyCAIdQ4j57SX8e74tbQNfLoEL/
	 Ha/xCkZzzKyKJ7IQ1owroc/NUrdJ5RLC8mBkpoDfRmLAgqCHjif9HTTCQDVDL8YXcjlmq
	 IOxUDn1H0Elon7+HtTlUYTcsSUxCKJxzREDU7eSKCnamKFgVsUjXV3J0VcbsqTnGh6ZyA
	 hEPTR0f/TD7ougDJDBlF68Cwc8vHUjORS3NBkZq7PlKaweNZDE3tVdThoNb7i0V825mSe
	 t7hv6hlc1GIH4IQCw8/zrXAPfPn0IhbkU/rdt7ybGpWu/E4i8NMceY8z+Wf0VG1gIVLmw
	 pjovNFdCORTlu+UYJ/a7wCqZoSmr+FPN56x/tGdG7c3tNHoiOLgrcEIGCVYrEiSzGE0xI
	 4QdZGfUe2LSmoS3MtGthVdSzljZkTJ0mb78ry/pFYqKpjPYnhasviTYlR5hsh14=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
MIME-Version: 1.0
Date: Fri, 28 Aug 2026 11:55:00 +0200
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 06/12] kexec: machine_reboot_kexec() doesn't return
In-Reply-To: <26fe76ce-db8f-4641-aeea-667fb6ee3932@suse.com>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
 <26fe76ce-db8f-4641-aeea-667fb6ee3932@suse.com>
Message-ID: <d7bb3db821a0018d7b0dc5c8a6729df9@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-42698a/1787910900-1BED69EA-368658A3/0/0
X-purgate-type: clean
X-purgate-size: 1601

On 2026-08-28 09:02, Jan Beulich wrote:
> Mark it as such, and then remove the code following at its sole call 
> site,
> for Eclair flagging that as a Misra rule 2.1 (unreachable code) 
> violation.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -401,7 +401,7 @@ void kexec_crash(enum crash_reason reaso
>      BUG();
>  }
> 
> -static long cf_check kexec_reboot(void *_image)
> +static long noreturn cf_check kexec_reboot(void *_image)
>  {
>      struct kexec_image *image = _image;
> 
> @@ -409,9 +409,6 @@ static long cf_check kexec_reboot(void *
> 
>      kexec_common_shutdown();
>      machine_reboot_kexec(image);
> -
> -    BUG();
> -    return 0;
>  }
> 
>  static void cf_check do_crashdump_trigger(unsigned char key)
> --- a/xen/include/xen/kexec.h
> +++ b/xen/include/xen/kexec.h
> @@ -48,7 +48,7 @@ int machine_kexec_add_page(struct kexec_
>  int machine_kexec_load(struct kexec_image *image);
>  void machine_kexec_unload(struct kexec_image *image);
>  void machine_kexec_reserved(xen_kexec_reserve_t *reservation);
> -void machine_reboot_kexec(struct kexec_image *image);
> +void noreturn machine_reboot_kexec(struct kexec_image *image);
>  void machine_kexec(struct kexec_image *image);
>  void kexec_crash(enum crash_reason reason);
>  void kexec_crash_save_cpu(void);

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 10:19:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 10:19:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401880.1637367 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wztgO-0003q4-Ln; Fri, 28 Aug 2026 10:19:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401880.1637367; Fri, 28 Aug 2026 10:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wztgO-0003px-Is; Fri, 28 Aug 2026 10:19:36 +0000
Received: by outflank-mailman (input) for mailman id 1401880;
 Fri, 28 Aug 2026 10:19:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <philmd@oss.qualcomm.com>) id 1wztgO-0003pr-1o
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:19:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wztgM-0070rC-NW
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:19:34 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a9160ad-e002-0a2a0a5209dd-0a2a4506d0c0-22
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 12:19:34 +0200
Received: from [205.220.168.131] (helo=mx0a-0031df01.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <philmd@oss.qualcomm.com>)
 id 6a9160b4-195a-0a2a45060019-cddca883b838-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 12:19:34 +0200
Received: from pps.filterd (m0279865.ppops.net [127.0.0.1])
 by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67SA7jXK3306358
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:19:32 GMT
Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com
 [209.85.160.200])
 by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4gb42p94fh-1
 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT)
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 10:19:31 +0000 (GMT)
Received: by mail-qt1-f200.google.com with SMTP id
 d75a77b69052e-52fb8f67601so10054211cf.3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 03:19:31 -0700 (PDT)
Received: from [192.168.69.226] (pmd666.hd.free.fr. [88.187.86.199])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b94dc1076sm39706795e9.3.2026.08.28.03.19.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 03:19:29 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:Cc:To:Content-Language:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h=
	cc:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=
	pLeDyIe24xlxelqivhxFI+C08k7EOIn3h4F7ph1yYvc=; b=bWXYocUR7lIQ3ijM
	MkRbBFMz9EUllcmW4xu06IRmgdGKC5WPDsG74Yfsle7hshzSrGIbru6eG/c2bdOa
	k7GiR59KOF19ty/CgkFYqcjtViq7c80KU1mptISveF51cvHLmMyj37kmwu41TcdB
	0bcvMj11qfFQIWNt5vCUpxmsLC+vZ4ZrQKPxq5ZGy74RtJ9NN/0t7nmwVZSyooXn
	Xsnt+m3X69kkVPuxQtlxJ+tyVcVWaNZEZhZdsfIX/kItHCav395xbk9sH+yJ43Bu
	sHZgvy+EPERUNxJ9XrVgIuFQ3fdHHSxuovxrDAoe4kvrflA5BOB6W0fwi3uc40ja
	scE5yQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=oss.qualcomm.com; s=google; t=1787912371; x=1788517171; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=pLeDyIe24xlxelqivhxFI+C08k7EOIn3h4F7ph1yYvc=;
        b=c/yzG8GkAXu5NFdnUXnj/kSTlGR+YbxTHZoUiVK1xgb5ZUK5Vhf6ggtBJqfr7AToTf
         8IkdoVmgQcp7/h92m96/UUQeY5lC2JHdkvwULo68UoGWkxhJctJ7YcyjUAc7RoBxY07N
         bM/nFNRPRJCkU4DvgAuMQw83ihvkxKqCsQb38Mj6EpuyoKsKe47LFVYe7Kp40joat8uf
         8ewATHEH67VhnsEIs2Ru/tqBc9WSBL1H/c9Z+46Fe3i0vU2RmY5nqVtRbl8Qb9lTJBsn
         tBSCmpyCUigLQrjmpQ/oAHpwYESgaclWlxYx0qyJVvEy+YMq/pzMbBUSMVYeGh6kc7Cx
         Ez2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787912371; x=1788517171;
        h=content-transfer-encoding:content-type:in-reply-to:from:references
         :cc:to:content-language:subject:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=pLeDyIe24xlxelqivhxFI+C08k7EOIn3h4F7ph1yYvc=;
        b=XiYAKMYcNRbxj/xA09ABzrZvdyh5BGvpEotshuiYUdH4zZOf18vpng2WIUjcwQHuJY
         k6B2PUC1Ff4DF2n5WM06pQAh6ry+LaNToN9/Tqqcqw2LuaOQ+4RCtViQF+HHBx6WSYa/
         PkH8agYaVdbo/geftNFD+7aWgTdBZNKWhvfgLz105ABBE6Vv/c9kYz446G8m6K745W+n
         kHg/U5q6mGWPy8rtdh/Voz5LLLkOJGSXWz8ReVBqx93v0TOMqzhY1WzFZiuouRS7jPbg
         bIxTbBBhIvD6xyuvx9CAuWyAFoPNVC2N1AmQqScg9VbWAVu1lWfw2KwItPa+YJRrj2JI
         swzA==
X-Forwarded-Encrypted: i=1; AHgh+Rp6PJ/zwb8xsENfHblGYFGLibP9kXo+SAA1SnWieTC/AnxGBiMB7v0/lyEsoGGPvxtXh9D8pXt0UU4=@lists.xenproject.org
X-Gm-Message-State: AFuF++lWDsCp+1zxCj0agUbTb9dmgkH33KzTmPVUiVEzNA9e+48lGbxX
	X/eH35RrneHIWBCK+7kzFxp6hyAV0ieL+wuLnRr6YGaJOPSQCYgnBHZVfMLm1kl0olJzxqDflT+
	Fyq+sb9EIJREpZPPFUYXrYnGZv08hFRUv9D6/1Q7V4d230eLa2gqQoC3VQWnmyQVTQyECyw==
X-Gm-Gg: AR+sD13cqqA4AW6yaBcobr7jo3ZZQa4/R8rIyNDAb5nVcCKKggd5yLhUiAkFpEpFpEc
	yYh3QXfqgKXnOTGz9CVA2bRWIUafJBkSMchpZ9cMjsNbKW8KNb+XR7KN73oHuSFLIK4I5Z7sO2o
	52NV/zzZassHcSQA7GUmh5JAT77EngVkMmJhNpK6l7Q92dhgQLmHnXqVN7iGMi8etLXAxZwrO62
	1HvVAco2hjnhQEDU/CiGISwOHbayVco8v3cRTNnD5VB4X5QP54URjkqGW/JgQFGukfjGned0lap
	K4enEn54BDT2OzPEUcP7Xhy9eMsS0BBqi5I7cxjWeynLyyhNqtC3h+nLZpGv21NnATF1A0gEGxj
	1UlOW1dIKmFzvr0hyjPQu9CoVZlXAvySB1g==
X-Received: by 2002:ac8:5d13:0:b0:52e:2d4e:8eef with SMTP id d75a77b69052e-52fb93d6dcbmr61126741cf.4.1787912370579;
        Fri, 28 Aug 2026 03:19:30 -0700 (PDT)
X-Received: by 2002:ac8:5d13:0:b0:52e:2d4e:8eef with SMTP id d75a77b69052e-52fb93d6dcbmr61125891cf.4.1787912369979;
        Fri, 28 Aug 2026 03:19:29 -0700 (PDT)
Message-ID: <deabd371-a764-4556-8f2e-15f0e50649b2@oss.qualcomm.com>
Date: Fri, 28 Aug 2026 12:19:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 36/49] monitor: tighten monitor_printf*()
Content-Language: en-US
To: =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>,
        qemu-devel@nongnu.org
Cc: dave@treblig.org,
        =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?=
 <philmd@mailo.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?=
 <berrange@redhat.com>,
        Markus Armbruster <armbru@redhat.com>,
        Gerd Hoffmann <kraxel@redhat.com>,
        "Gonglei (Arei)"
 <arei.gonglei@huawei.com>,
        zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>,
        Hanna Reitz <hreitz@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
        =?UTF-8?Q?Alex_Benn=C3=A9e?=
 <alex.bennee@linaro.org>,
        Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>,
        Ani Sinha <anisinha@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>,
        Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>,
        Brian Cain <brian.cain@oss.qualcomm.com>,
        David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>,
        Richard Henderson <richard.henderson@linaro.org>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
        Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>,
        Halil Pasic <pasic@linux.ibm.com>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Jason Herne <jjherne@linux.ibm.com>,
        Eric Farman <farman@linux.ibm.com>,
        Matthew Rosato <mjrosato@linux.ibm.com>,
        Ilya Leoshkevich
 <iii@linux.ibm.com>,
        David Hildenbrand <david@kernel.org>,
        Cornelia Huck <cohuck@redhat.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Anthony PERARD <anthony@xenproject.org>,
        "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
        Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>,
        Fabiano Rosas <farosas@suse.de>,
        Samuel Thibault <samuel.thibault@ens-lyon.org>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        Zhao Liu <zhao1.liu@intel.com>, Nicholas Piggin <npiggin@gmail.com>,
        Chinmay Rath <rathc@linux.ibm.com>, Glenn Miles <milesg@linux.ibm.com>,
        Harsh Prateek Bora <harshpb@linux.ibm.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        Weiwei Li
 <liwei1518@gmail.com>,
        Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
        Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
        Chao Liu <chao.liu@processmission.com>,
        Yoshinori Sato <yoshinori.sato@nifty.com>,
        Artyom Tarasenko <atar4qemu@gmail.com>,
        Max Filippov <jcmvbkbc@gmail.com>,
        Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org,
        kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org,
        xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com>
 <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com>
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>
In-Reply-To: <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Proofpoint-ORIG-GUID: V3zke2dEH4-KwpvWaoesF2dsDzGdmpeN
X-Authority-Analysis: v=2.4 cv=ToDWQjXh c=1 sm=1 tr=0 ts=6a9160b3 cx=c_pps
 a=JbAStetqSzwMeJznSMzCyw==:117 a=4s3hRJSeHn4rkQlkrse1kQ==:17
 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10
 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22
 a=20KFwNOVAAAA:8 a=EUspDBNiAAAA:8 a=_7nI1AEwapyDFsg1MK8A:9 a=3ZKOabzyN94A:10
 a=QEXdDO2ut3YA:10 a=uxP6HrT_eTzRwkO_Te1X:22
X-Proofpoint-GUID: V3zke2dEH4-KwpvWaoesF2dsDzGdmpeN
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI4MDA4OCBTYWx0ZWRfX8fUywqXZp/ig
 sbrG9lBHbD8VszCXTPo3pu3xRcOckgkD+6VEsaoArNFGsG66EO290xnosSPfQwlW1aa5Wv4DDMW
 ah8hx7m/crCeJi9gmfHlP6WKF7xVZ3E=
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI4MDA4OCBTYWx0ZWRfX8Kk2uFMWOxmf
 evq19QIilGkJw5LdD4f+lZ+RMoH8yXZiAZsvYJQX3A9ar3aBXQhVxYbZEpVaW3HsBNtZqPShWOD
 guIxjQehurgdLZdcKpEqortG82c8REwscbgkpoCP+/m+D0Zgl94rh8uLoFdnQAyUCKKI78BxXkf
 RrIZuBDS6nyAoprxpL3cpDW4B6R6NIiN5S5Sc9aXwS+d2eGzz0vjQu7zf7yd4fQDMTU95OOh8dc
 jeZnuYqZueyMLLnWqw5uHtH6YR0GR5+KRU4+AbADgwznUP7Wv2njzzHsAB6ZVOja4PxTOFqOC+y
 WEICowxNKRwUqpSAI9VpCp6SmJL+ZPOl06tCIS495c+R1VDiM0G/eAYmtMW+AVMLWpqVypCHZYO
 qOIS60jhVWV4ao8ABC4g6apaMtFVZOmJ+EdhxK0WfL7mRKJVSJn1mm2dm3DiTUdreXR5EaBOARy
 1rtFJMvNoKCkQSyD3RQ==
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-28_03,2026-08-27_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 clxscore=1015 priorityscore=1501 adultscore=0 impostorscore=0 bulkscore=0
 lowpriorityscore=0 suspectscore=0 phishscore=0 spamscore=0 malwarescore=0
 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0
 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608280088
X-purgate-ID: tlsNG-16d1c6/1787912374-1ECC577B-D7168C4E/0/0
X-purgate-type: clean
X-purgate-size: 4375

On 25/8/26 21:09, Marc-André Lureau wrote:
> Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
> monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
> the first parameter from Monitor * to MonitorHMP * to enforce type
> safety. The implementation is also simplified: monitor_hmp_vprintf now
> directly calls g_strdup_vprintf + monitor_puts, removing the virtual
> dispatch via moncls->vprintf.
> 
> The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
> cast, they are fixed in the following commits.
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>   audio/audio-hmp-cmds.c                  |   6 +-
>   backends/cryptodev-hmp-cmds.c           |   9 +-
>   block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
>   chardev/char-hmp-cmds.c                 |  12 +-
>   disas/disas-mon.c                       |  10 +-
>   docs/devel/style.rst                    |   2 +-
>   docs/devel/writing-monitor-commands.rst |   8 +-
>   dump/dump-hmp-cmds.c                    |   5 +-
>   hw/char/virtio-serial-bus.c             |  10 +-
>   hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
>   hw/core/sysbus.c                        |   5 +-
>   hw/hexagon/hexagon_tlb.c                |  44 ++---
>   hw/i386/kvm/xen-stubs.c                 |   6 +-
>   hw/i386/kvm/xen_evtchn.c                |  21 +--
>   hw/i386/sgx-hmp-stub.c                  |   3 +-
>   hw/i386/sgx.c                           |  29 ++-
>   hw/misc/auxbus.c                        |   9 +-
>   hw/misc/mos6522-stub.c                  |   3 +-
>   hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
>   hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
>   hw/pci/pci-stub.c                       |   3 +-
>   hw/s390x/s390-skeys.c                   |   9 +-
>   hw/s390x/s390-stattrib.c                |  20 +--
>   hw/uefi/ovmf-log.c                      |   5 +-
>   hw/usb/bus.c                            |  11 +-
>   hw/usb/host-libusb.c                    |  21 ++-
>   hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++---------------
>   hw/xen/xen-bus.c                        |   5 +-
>   include/disas/disas.h                   |   4 +-
>   include/monitor/hmp.h                   |  12 +-
>   migration/dirtyrate.c                   |  46 +++--
>   migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----------------
>   monitor/hmp-cmds.c                      | 141 +++++++--------
>   monitor/hmp.c                           | 143 +++++++--------
>   monitor/monitor-internal.h              |   6 -
>   monitor/monitor.c                       |  33 ++--
>   net/net-hmp-cmds.c                      |  31 ++--
>   net/slirp.c                             |  31 ++--
>   qom/qom-hmp-cmds.c                      |  27 ++-
>   replay/replay-debugging.c               |   5 +-
>   stats/stats-hmp-cmds.c                  |  57 +++---
>   stubs/hmp-cmd-info_sev.c                |   3 +-
>   stubs/monitor-core.c                    |   2 +-
>   system/dirtylimit-hmp-cmds.c            |  10 +-
>   system/qdev-monitor.c                   |  19 +-
>   system/runstate-hmp-cmds.c              |  16 +-
>   system/tpm-hmp-cmds.c                   |  29 ++-
>   target/i386/cpu-apic.c                  |   3 +-
>   target/i386/monitor.c                   | 152 ++++++++--------
>   target/i386/sev.c                       |  35 ++--
>   target/m68k/monitor.c                   |   3 +-
>   target/ppc/monitor.c                    |   3 +-
>   target/riscv/monitor.c                  |  55 +++---
>   target/sh4/monitor.c                    |  29 ++-
>   target/sparc/monitor.c                  |   3 +-
>   target/xtensa/monitor.c                 |   3 +-
>   tests/unit/test-util-sockets.c          |   2 +-
>   tools/qemu-vnc/clipboard.c              |   4 +-
>   tools/qemu-vnc/stubs.c                  |   2 +-
>   trace/trace-hmp-cmds.c                  |  12 +-
>   ui/ui-hmp-cmds.c                        | 115 ++++++------
>   util/error-report.c                     |   2 +-
>   util/qemu-print.c                       |  11 +-
>   63 files changed, 1219 insertions(+), 1327 deletions(-)

Painful.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 10:30:01 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 10:30:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401891.1637377 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wztqO-0006pK-Mz; Fri, 28 Aug 2026 10:29:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401891.1637377; Fri, 28 Aug 2026 10:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wztqO-0006pD-Ih; Fri, 28 Aug 2026 10:29:56 +0000
Received: by outflank-mailman (input) for mailman id 1401891;
 Fri, 28 Aug 2026 10:29:56 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ayan.kumar.halder@amd.com>) id 1wztqN-0006p7-MQ
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:29:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wztqM-005fxq-N2
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:29:54 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ayan.kumar.halder@amd.com>)
 id 6a916320-8faa-0a2a0a5109dd-0a2a450cceec-6
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 12:29:54 +0200
Received: from [40.107.209.58]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ayan.kumar.halder@amd.com>)
 id 6a916320-f479-0a2a450c0019-286bd13ae80b-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 12:29:53 +0200
Received: from BN0PR03CA0053.namprd03.prod.outlook.com (2603:10b6:408:e7::28)
 by PH7PR12MB7236.namprd12.prod.outlook.com (2603:10b6:510:207::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Fri, 28 Aug
 2026 10:29:45 +0000
Received: from BN1PEPF0001806F.namprd04.prod.outlook.com
 (2603:10b6:408:e7:cafe::a8) by BN0PR03CA0053.outlook.office365.com
 (2603:10b6:408:e7::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.11 via Frontend Transport; Fri,
 28 Aug 2026 10:29:45 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 BN1PEPF0001806F.mail.protection.outlook.com (10.167.245.197) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.382.8 via Frontend Transport; Fri, 28 Aug 2026 10:29:45 +0000
Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 28 Aug
 2026 05:29:45 -0500
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com
 (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Fri, 28 Aug
 2026 05:29:44 -0500
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.45 via
 Frontend Transport; Fri, 28 Aug 2026 05:29:43 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KFq95oFmgfruM4He2yXs8Q0we4QMsX/dG2cFb7JcXHi42aNaalNdFYDkRCyWR7VkXgfJbU+Q7lwI74JIrm/Y64y2WqbzbBBbEV3KQJtpjNn3cnYVJGHTcq6If2Ho+qur8QDDp8ssURcPPZv2C2BL9HOXHGroFY7XT9ccDw1Iula8lqunmItxVmTDkGMQlQ9gKX7YKcRYlSNZoyYJCS1WnBN3ovJovElL+y96OqBI3Fu8leWtUcebgXRlbo1tgJfE34EXJLEzsidXPIpo0B0joSQGuTgfKS0Q+jTVMVjtbY+8U6JNaC9lUQ4nQCTfD2ym5Iy5rkTHi0dpFq7tUZ+u4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Rxor3PoWIi+9ZpnWGWRHjUc1xefCvkyn8RzJdpJ7jNE=;
 b=DVfYI4lda+7lTalQc+LWm5oqCnSJUACQJduTRgAWdAGH4GL3AagdI0/jpaNeTeb8tqwkEJ0TjqYlZtniGymQjkJqcipAHrQoqyt2f46vxV5Zs8s/EpWh5CJBY3gVxm5TN63psJd0nky77e7ywXE6/O3zfks0jncV3o9J9S+LpJSsQ1Sb+iXIPvZ2/nyWHKIhYhd0117+e4aaUviuR87sW5u5tGrrUlp5dPxZRcpNvdcKI2iQcuJkCJzyoSmz2ZAGogv1Fq9vtI2MFTwcUrUZswMJGw0IyIGaCTNq/cj62mDHghmajp2egRLrjcI2OMYrtNED7RBvsYza3nsXTsTKog==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Rxor3PoWIi+9ZpnWGWRHjUc1xefCvkyn8RzJdpJ7jNE=;
 b=HCJAH+ZsG4dU+w4UHfCBtIKbS+GwcIdgTjczvdsadZPawG5tlBRxu8/+yIhR8Ogg5oyPrejcNjW7VIfBaxbFgvF8WgOFoKy1frlf/646NQepTC4dCFoGXP38WGCM/diH3xp5QUcuiq89Axn4w0W00k74zspkFF71+JD9x5S638k=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Bertrand Marquis <bertrand.marquis@arm.com>, Michal Orzel
	<michal.orzel@amd.com>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Anthony PERARD
	<anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>, Roger Pau Monne
	<roger@xenproject.org>, Doug Goldstein <cardoe@cardoe.com>
Subject: [PATCH v3 for 4.23] Add GIC SGI boot/self tests in Xen
Date: Fri, 28 Aug 2026 11:29:33 +0100
Message-ID: <20260828102933.2853627-1-ayan.kumar.halder@amd.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20260529170956.49797-1-ayan.kumar.halder@amd.com>
References: <20260529170956.49797-1-ayan.kumar.halder@amd.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0001806F:EE_|PH7PR12MB7236:EE_
X-MS-Office365-Filtering-Correlation-Id: 689cb2d5-8b93-4633-00f6-08df04ef4790
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|7416014|376014|82310400026|1800799024|36860700016|10067099003|6133799003|3023799007|18002099003|22082099003|11063799006|5023799004|56012099006|13003099007;
X-Microsoft-Antispam-Message-Info:
	ABL1Gv6BsajNCUqY2Lkgz37OSGDVuvoMsrFLYQFBV7N3XcIDtSqs7ubpih0EzJGYUiNW42vT0cTrtim/j8vsqXmlkM5vBPAmcS+2Bf2JVIU0GMZMXIGJfGXowtwGSjqWUt5fPN6lF89HrOk0T6El7IvoJfpdjGr4swnJOMle/dpT8ZosBMICbrjUFnVJfOPbUXHi0Ox67RRXXEgRot6JP/ITsH8vETn1XOBQe1YI+Sd1VR7884CARvB6JkLNGx/LQh0ufh2v00/oBbGCWJWP9WCzfIQOeEWrOFeQlblwp9fZ8Vj5ma2W3jMPh6qMBs04sNyMTscA5vAtG6SEqXpA3wPb+tYIMmun/ebDwJs8Wkl4AcfzK2mFeZh4SngQbq4QtOtRw1E71p08N2M4ssPpndtgYGvdHymczIt3u5pVFQ90udFUlPyw+2sC/eFDagGJIQ7mws94DhRo5sg/7/yj5A/Mk5m35xxnlDTbaz6vUlWCvQDBoGUMo1PaP3c+Kazut1ftBTVTDrnftPNGGav2F6tJe5e6/4zg/ke+AY5TO9ZDORbgztW7dtMzIuTJu/Kds/pZwqBGFDrHnNMG+6VNRULCK4w3Z6TXAgQSwpSrfqk0qWMREHiEaRdbXgD6UdRb6TCQhgRudgyvkmeAzcUG5eMjwA4SjTszj1osHYPl9ca7raJ70+tgexm4ypN/zboOXXPna4rFHbNQHIWedn1gWQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(376014)(82310400026)(1800799024)(36860700016)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(11063799006)(5023799004)(56012099006)(13003099007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	UXywtoMlyyTu8VDr7KncWEkI0vqIsIAlmYZ56dmv+iH6bGUd3rlPX6gRZw6x/HlmaSthzFkmQ4rxvsR9d/qQAdrHYT6LDisSCSzehwd4Eg5pBPfFyw7WGYS9GEM0YjX+sFPRtvRSBWTmsvqZ+JUbcqFqQduH4HHkLfyM3wx/4NKDMPsGQG+JeGWRoz5OHzX4NYsV7b4fwgdjQCJUDexXQ0SwpOotwwhfZEH4ngo5jGNk/6/tNpGsqKMiLjXwoHlb2NGZhrNzqtCmtsEyrYaXKSWi33DhsjqD3Kpqt7AYaz/BcpRjD9XjX8VyaB42YeXOlDTWsvQt6UgfS7S9/vN/cqeHq7cc0lU8WLcoBbhI/4SRxPPabUyuCwvGDt7LAXJpmaB1vRnvf7G3ZTbKAmP82kk9Q+rPYOJ483uqzGWPV0w5TNxl0PIpS4eb1scV3IW/
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 10:29:45.3794
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 689cb2d5-8b93-4633-00f6-08df04ef4790
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0001806F.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7236
X-purgate-ID: tlsNG-d25034/1787912994-02EDAA5B-3FD90508/0/0
X-purgate-type: clean
X-purgate-size: 20211

Boot self-tests (also referred to as boot-time tests or power-on
self-tests) are intended to check that Xen has configured the hardware
correctly before bringing up any domains.

Introduce tests to confirm that, using a dedicated SGI (GIC_SGI_TEST):
1. A cpu can send the SGI to itself
2. A cpu can send the SGI to another specific CPU (CPU0)
3. A cpu can send the SGI to all the other CPUs

Each CPU counts the test SGIs it takes. A sender samples those counters
before sending and then waits for the count of every CPU it targeted to
change, which is how it tells that the SGI was really delivered. The
counters are never reset, so comparing against a sample rather than an
absolute value keeps concurrent senders from disturbing each other.

A test reports a failure by panic(), so Xen never continues on a
platform where SGI delivery is broken. When the tests pass, Xen carries
on booting normally.

Also introduce a config CONFIG_BOOT_SELFTEST which enables these
tests. It depends on DEBUG and is off unless explicitly enabled.

Also introduce a boolean command line parameter "gic-test", so that a
build with CONFIG_BOOT_SELFTEST enabled can be shipped but the tests
selected at boot. It is documented in
docs/misc/xen-command-line.pandoc.

In order to keep all the boot self-tests together in the binary, a
separate section "initcallboottest" is introduced. Tests are registered
using __initcallboottest() and run once on every CPU by
do_init_boottests(), bracketed by begin/end messages. They run before
any domain is created on the primary core, and before the idle loop is
entered on a secondary core.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
Upstream CI run:
https://gitlab.com/xen-project/people/ayankuma/xen/-/pipelines/2799278627

Changes in v3:
 - Rewrote the commit message: dropped the claim that Xen is not
   functional after the tests (it is), and the misleading "SGI 0 / SGI 1"
   numbering - only one SGI, GIC_SGI_TEST, is used (Julien).
 - Retitled from "GICv3 SGI" to "GIC SGI": the tests only use
   send_SGI_{self,one,allbutself}(), which GICv2 implements too. Verified
   by running them on arm32/GICv2.
 - The tests are now self-checking instead of log-scraping: each CPU
   counts the GIC_SGI_TEST interrupts it takes and the sender waits for
   that count, panicking after 100ms. Xen no longer continues on a
   platform where SGI delivery is broken, and is otherwise unaffected,
   so the option is meaningful on an ordinary debug build (Julien).
 - CONFIG_BOOT_SELFTEST now depends on DEBUG (Julien).
 - "gic-test" is a boolean_param() and is documented in
   docs/misc/xen-command-line.pandoc (Julien).
 - Dropped the unnecessary <xen/delay.h> and <xen/shutdown.h> includes,
   and the unchecked smp_send_state_dump() call (Julien).
 - The "all but self" test is run by whichever CPU observes it is the
   last to arrive, comparing against num_online_cpus(), and targets
   cpu_online_map minus itself, rather than keying off
   smp_get_max_cpus() - 1 (Julien).
 - do_init_boottests() prints a begin/end marker (Julien).
 - Removed the spurious blank line before the closing brace (Julien).
 - The CI test now boots 4 CPUs, so that "send to CPU0" and "send to all
   but self" cover different sets of CPUs (Julien).
 - The registration macro and do_init_boottests() moved to arch/arm, so
   that xen/include/xen/init.h and xen/common/kernel.c are untouched: the
   .initcallboottest.init section only exists in arch/arm/xen.lds.S, and a
   test registered elsewhere would land in an orphan section.
 - do_init_boottests() is no longer __init: it is called from
   start_secondary(), which lives in .text.
 - The static counter used to spot the last CPU is __initdata, so it no
   longer occupies .bss for the life of the hypervisor.
 - Kconfig: use tabs to match the rest of arch/arm/Kconfig, and drop the
   redundant "default n".
 - gic-test.c is SPDX GPL-2.0-or-later, to match the neighbouring GIC
   files.
 - The CI test script takes qemu-system-aarch64 from the test container's
   PATH, the same way the other qemu-smoke-*-arm64 scripts do, rather
   than expecting it in binaries/.
 - Rebased onto current staging: the CI jobs are named after alpine 3.24
   rather than 3.18.

Changes in v2:
 - Renamed the patch from "xen/arm: Introduce GICV3 Self Tests" to
   "Add GICv3 SGI boot/self tests in Xen", and rewrote the commit
   message to explain the intent of boot self-tests (debug /
   validation builds only, Xen not expected to remain functional
   afterwards).
 - Moved the selftest code out of gic-v3.c into a dedicated file
   xen/arch/arm/gic-test.c, gated by CONFIG_BOOT_SELFTEST
   (Stefano, Grygorii).
 - Introduced a generic boot-self-test framework: new section
   "initcallboottest", registration macro __initcallboottest, and
   do_init_boottests() invoked once per CPU after
   local_irq_enable(), so the test runs on every CPU (boot +
   secondaries) and no longer collides with the IRQ-enable timing
   in gicv3_init() (Julien #1, Julien #3).
 - Added Kconfig option CONFIG_BOOT_SELFTEST in
   xen/arch/arm/Kconfig (arm-only for now; arch-specific because
   the only registered test is GICv3-specific).
 - Reserved a dedicated SGI value GIC_SGI_TEST in enum gic_sgi
   (xen/arch/arm/include/asm/gic.h), so the selftest never
   reuses a functional SGI (Grygorii #3).
 - Added a runtime integer command-line parameter "gic-test" so
   the selftest binary can be shipped but its execution selected
   at boot (gic-test=0 -> no-op; gic-test=1 -> SGI tests). Future
   GICv3 features (distributor, ITS, LPI, ...) can claim further
   values (Grygorii #2, partial).
 - Documented why machine_halt() is not invoked after the tests:
   SGI delivery is asynchronous, so there is no well-defined
   point after which every send has been observed by its
   receiver (Julien #2).
 - Wired the tests into upstream GitLab CI: new build job
   alpine-3.18-gcc-debug-arm64-boot-selftest, new test job
   qemu-smoke-boot-selftest-arm64-gcc-debug, and the runner
   script automation/scripts/qemu-boot-selftest-arm64.sh that
   dumps the QEMU virt DTB, injects
   "gic-test=1 console=dtuart sync_console" into
   /chosen/xen,xen-bootargs via fdtput, boots Xen, and checks
   for each "Sending GIC_SGI_TEST ..." followed by the matching
   "CPU%u: GIC_SGI_TEST received".

 automation/gitlab-ci/build.yaml               |   8 ++
 automation/gitlab-ci/test.yaml                |   8 ++
 .../scripts/qemu-boot-selftest-arm64.sh       |  72 +++++++++++++
 docs/misc/xen-command-line.pandoc             |  10 ++
 xen/arch/arm/Kconfig                          |  13 +++
 xen/arch/arm/Makefile                         |   1 +
 xen/arch/arm/gic-test.c                       | 102 ++++++++++++++++++
 xen/arch/arm/gic.c                            |   5 +
 xen/arch/arm/include/asm/gic.h                |   8 ++
 xen/arch/arm/include/asm/setup.h              |   9 ++
 xen/arch/arm/setup.c                          |  20 ++++
 xen/arch/arm/smpboot.c                        |   3 +
 xen/arch/arm/xen.lds.S                        |   4 +
 13 files changed, 263 insertions(+)
 create mode 100755 automation/scripts/qemu-boot-selftest-arm64.sh
 create mode 100644 xen/arch/arm/gic-test.c

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 27eefec5f9..3d37e0b572 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -420,6 +420,14 @@ alpine-3.24-arm64-gcc-debug:
       CONFIG_UBSAN=y
       CONFIG_UBSAN_FATAL=y
 
+alpine-3.24-arm64-gcc-debug-boot-selftest:
+  extends: .gcc-arm64-build-debug
+  <<: *build-test
+  variables:
+    CONTAINER: alpine:3.24-arm64v8
+    EXTRA_XEN_CONFIG: |
+      CONFIG_BOOT_SELFTEST=y
+
 alpine-3.24-arm64-gcc-randconfig:
   extends: .gcc-arm64-build
   variables:
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 61adc1baff..96127995d7 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -605,6 +605,14 @@ qemu-smoke-dom0less-arm64-gcc-debug-gicv3:
     - *arm64-test-needs
     - alpine-3.24-arm64-gcc-debug
 
+qemu-smoke-boot-selftest-arm64-gcc-debug:
+  extends: .qemu-arm64
+  script:
+    - ./automation/scripts/qemu-boot-selftest-arm64.sh 2>&1 | tee ${LOGFILE}
+  needs:
+    - *arm64-test-needs
+    - alpine-3.24-arm64-gcc-debug-boot-selftest
+
 qemu-smoke-dom0less-arm64-gcc-debug-staticmem:
   extends: .qemu-arm64
   script:
diff --git a/automation/scripts/qemu-boot-selftest-arm64.sh b/automation/scripts/qemu-boot-selftest-arm64.sh
new file mode 100755
index 0000000000..e36bd8d94a
--- /dev/null
+++ b/automation/scripts/qemu-boot-selftest-arm64.sh
@@ -0,0 +1,72 @@
+#!/bin/bash
+
+set -ex -o pipefail
+
+# Boot Xen under QEMU with gic-test in xen,xen-bootargs and check that every
+# self-test reported OK and that Xen carried on booting.
+
+XEN=binaries/xen
+# qemu-system-aarch64 comes from the debian:13-arm64v8 test container, the
+# same way the other qemu-smoke-*-arm64 scripts get it.
+QEMU=qemu-system-aarch64
+DTB_RAW=binaries/virt.dtb
+DTB=binaries/virt-bootselftest.dtb
+LOG=smoke.serial
+
+NR_CPUS=4
+
+test -f ${XEN}
+
+${QEMU} \
+    -machine virt,virtualization=true,gic-version=3,dumpdtb=${DTB_RAW} \
+    -cpu cortex-a57 -m 1024 -smp ${NR_CPUS} -display none -net none
+
+cp ${DTB_RAW} ${DTB}
+fdtput -t s ${DTB} /chosen xen,xen-bootargs \
+    "gic-test console=dtuart sync_console"
+
+rm -f ${LOG}
+timeout 60 ${QEMU} \
+    -machine virt,virtualization=true,gic-version=3 \
+    -cpu cortex-a57 -m 1024 -smp ${NR_CPUS} \
+    -serial file:${LOG} \
+    -monitor none -display none -no-reboot -net none \
+    -dtb ${DTB} \
+    -kernel ${XEN} || true
+
+fail=0
+
+check() {
+    local what=$1
+    local expected=$2
+    local got
+
+    got=$(grep -c -- "${what}" ${LOG} || true)
+    if [ "${got}" -ne "${expected}" ]; then
+        echo "FAIL: '${what}': expected ${expected}, got ${got}"
+        fail=1
+        return
+    fi
+
+    echo "OK: '${what}' x${expected}"
+}
+
+# Every CPU sends an SGI to itself...
+check "GIC selftest: CPU[0-9]*: SGI to self: OK" ${NR_CPUS}
+# ...every secondary CPU sends one to CPU0...
+check "GIC selftest: CPU[0-9]*: SGI to CPU0: OK" $((NR_CPUS - 1))
+# ...and whichever CPU runs last sends one to all the others.
+check "GIC selftest: CPU[0-9]*: SGI to all but self: OK" 1
+
+check "boot self-tests done" ${NR_CPUS}
+check "GIC selftest: .*did not receive" 0
+
+# A passing self-test must leave Xen booting normally.
+check "LOADING DOMAIN 0\|Xen dom0less mode detected" 1
+
+if [ ${fail} -ne 0 ]; then
+    echo "FAILED"
+    exit 1
+fi
+
+echo "PASSED"
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 1c711fa980..6d7277ae1b 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1267,6 +1267,16 @@ available on Intel Panther Lake and Diamond Rapids CPUs, and AMD Zen6 CPUs.
 FRED is fully supported on AMD hardware.  On Intel hardware it is still tech
 preview, and in particular not security supported.
 
+### gic-test (arm)
+> `= <boolean>`
+
+> Default: `false`
+
+Only available when `CONFIG_BOOT_SELFTEST` is enabled.
+
+Run the GIC SGI boot self-tests while each CPU is brought up.  Xen panics if
+an SGI is not delivered; otherwise it carries on booting normally.
+
 ### gnttab
 > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]`
 
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 843a43897e..92a1788854 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -498,6 +498,19 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
 config ARM32_HARDEN_BRANCH_PREDICTOR
     def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
 
+config BOOT_SELFTEST
+	bool "Enable boot self-tests"
+	depends on DEBUG
+	help
+	  This option enables boot self-tests. They are intended to check that
+	  Xen has configured the hardware correctly before bringing up any
+	  domains. A failure is reported by panic(); when the tests pass, Xen
+	  boots normally.
+
+	  Selected at boot with the "gic-test" command line option.
+
+	  If unsure, say N.
+
 source "arch/arm/platforms/Kconfig"
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b7afd3e58c..71f177824b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -24,6 +24,7 @@ obj-y += domctl.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += efi/
 obj-y += gic.o
+obj-$(CONFIG_BOOT_SELFTEST) += gic-test.o
 obj-$(CONFIG_GICV2) += gic-v2.o
 obj-$(CONFIG_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
diff --git a/xen/arch/arm/gic-test.c b/xen/arch/arm/gic-test.c
new file mode 100644
index 0000000000..9ddd47cad2
--- /dev/null
+++ b/xen/arch/arm/gic-test.c
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include <xen/atomic.h>
+#include <xen/cpumask.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/param.h>
+#include <xen/percpu.h>
+#include <xen/smp.h>
+#include <xen/time.h>
+#include <asm/gic.h>
+#include <asm/processor.h>
+#include <asm/setup.h>
+
+static bool __initdata opt_gic_test;
+boolean_param("gic-test", opt_gic_test);
+
+static DEFINE_PER_CPU(unsigned int, sgi_test_count);
+
+void gic_sgi_test_interrupt(void)
+{
+    this_cpu(sgi_test_count)++;
+}
+
+static unsigned int __init sgi_count(unsigned int cpu)
+{
+    return ACCESS_ONCE(per_cpu(sgi_test_count, cpu));
+}
+
+static void __init snapshot_sgi(unsigned int *before)
+{
+    unsigned int cpu;
+
+    for_each_online_cpu ( cpu )
+        before[cpu] = sgi_count(cpu);
+}
+
+/*
+ * Wait for every CPU in @mask to take one more GIC_SGI_TEST than the count
+ * recorded in @before.
+ */
+static void __init expect_sgi(const cpumask_t *mask,
+                              const unsigned int *before, const char *what)
+{
+    s_time_t deadline = NOW() + MILLISECS(100);
+    unsigned int cpu;
+
+    for_each_cpu ( cpu, mask )
+    {
+        while ( sgi_count(cpu) == before[cpu] )
+        {
+            if ( NOW() > deadline )
+                panic("GIC selftest: %s: CPU%u did not receive GIC_SGI_TEST\n",
+                      what, cpu);
+            cpu_relax();
+        }
+    }
+
+    printk("GIC selftest: CPU%u: %s: OK\n", smp_processor_id(), what);
+}
+
+/*
+ * "All but self" is only meaningful once every CPU can take an SGI, so it is
+ * run by whichever CPU observes that it is the last one to get here.
+ */
+static int __init gic_sgi_selftest(void)
+{
+    static atomic_t __initdata seen = ATOMIC_INIT(0);
+    unsigned int before[NR_CPUS] = { };
+    unsigned int cpu = smp_processor_id();
+
+    if ( !opt_gic_test )
+        return 0;
+
+    snapshot_sgi(before);
+    send_SGI_self(GIC_SGI_TEST);
+    expect_sgi(cpumask_of(cpu), before, "SGI to self");
+
+    if ( cpu != 0 )
+    {
+        snapshot_sgi(before);
+        send_SGI_one(0, GIC_SGI_TEST);
+        expect_sgi(cpumask_of(0), before, "SGI to CPU0");
+    }
+
+    if ( atomic_add_return(1, &seen) == num_online_cpus() )
+    {
+        cpumask_t target;
+
+        cpumask_andnot(&target, &cpu_online_map, cpumask_of(cpu));
+
+        if ( !cpumask_empty(&target) )
+        {
+            snapshot_sgi(before);
+            send_SGI_allbutself(GIC_SGI_TEST);
+            expect_sgi(&target, before, "SGI to all but self");
+        }
+    }
+
+    return 0;
+}
+__initcallboottest(gic_sgi_selftest);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 078049e741..6a132c64e1 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -330,6 +330,11 @@ static void do_static_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi)
     case GIC_SGI_CALL_FUNCTION:
         smp_call_function_interrupt();
         break;
+#ifdef CONFIG_BOOT_SELFTEST
+    case GIC_SGI_TEST:
+        gic_sgi_test_interrupt();
+        break;
+#endif
     default:
         panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id());
         break;
diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h
index ee2c26adb4..40635a9d32 100644
--- a/xen/arch/arm/include/asm/gic.h
+++ b/xen/arch/arm/include/asm/gic.h
@@ -306,6 +306,9 @@ enum gic_sgi {
     GIC_SGI_EVENT_CHECK,
     GIC_SGI_DUMP_STATE,
     GIC_SGI_CALL_FUNCTION,
+#ifdef CONFIG_BOOT_SELFTEST
+    GIC_SGI_TEST,
+#endif
     GIC_SGI_STATIC_MAX,
 };
 
@@ -321,6 +324,11 @@ extern void send_SGI_one(unsigned int cpu, enum gic_sgi sgi);
 extern void send_SGI_self(enum gic_sgi sgi);
 extern void send_SGI_allbutself(enum gic_sgi sgi);
 
+#ifdef CONFIG_BOOT_SELFTEST
+/* Record a GIC_SGI_TEST delivered to this CPU (see arch/arm/gic-test.c). */
+void gic_sgi_test_interrupt(void);
+#endif
+
 /* print useful debug info */
 extern void gic_dump_info(struct vcpu *v);
 extern void gic_dump_vgic_info(struct vcpu *v);
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 0adfa4993a..2fdf5da526 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -50,6 +50,15 @@ void setup_mm(void);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
+#ifdef CONFIG_BOOT_SELFTEST
+#define __initcallboottest(fn) \
+    static const initcall_t __initcall_##fn __init_call("boottest") = (fn)
+
+void do_init_boottests(void);
+#else
+static inline void do_init_boottests(void) {}
+#endif
+
 int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt,
                   struct rangeset *iomem_ranges, struct rangeset *irq_ranges);
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6310a47d68..c7abbdb04e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -83,6 +83,24 @@ static void __init init_idle_domain(void)
     /* TODO: setup_idle_pagetable(); */
 }
 
+#ifdef CONFIG_BOOT_SELFTEST
+extern const initcall_t __initcall_boot_test_start[],
+    __initcall_boot_test_end[];
+
+void do_init_boottests(void)
+{
+    const initcall_t *call;
+
+    printk("CPU%u: boot self-tests start\n", smp_processor_id());
+
+    for ( call = __initcall_boot_test_start; call < __initcall_boot_test_end;
+          call++ )
+        (*call)();
+
+    printk("CPU%u: boot self-tests done\n", smp_processor_id());
+}
+#endif /* CONFIG_BOOT_SELFTEST */
+
 static const char * __initdata processor_implementers[] = {
     ['A'] = "ARM Limited",
     ['B'] = "Broadcom Corporation",
@@ -470,6 +488,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr)
     enable_errata_workarounds();
     enable_cpu_features();
 
+    do_init_boottests();
+
     /* Create initial domain 0. */
     if ( !is_dom0less_mode() )
         create_dom0();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1806c47a08..97d8b19cf4 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -28,6 +28,7 @@
 #include <asm/gic.h>
 #include <asm/procinfo.h>
 #include <asm/psci.h>
+#include <asm/setup.h>
 #include <asm/acpi.h>
 #include <asm/tee/tee.h>
 
@@ -413,6 +414,8 @@ void asmlinkage noreturn start_secondary(void)
 
     printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
 
+    do_init_boottests();
+
     startup_cpu_idle_loop();
 }
 
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2d5f1c516d..14f64a856c 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -146,6 +146,10 @@ SECTIONS
        *(.initcall1.init)
        __initcall_end = .;
 
+       __initcall_boot_test_start = .;
+       *(.initcallboottest.init)
+       __initcall_boot_test_end = .;
+
        . = ALIGN(4);
        __alt_instructions = .;
        *(.altinstructions)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 10:59:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 10:59:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401913.1637385 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzuIe-0006rX-SY; Fri, 28 Aug 2026 10:59:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401913.1637385; Fri, 28 Aug 2026 10:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzuIe-0006qL-OY; Fri, 28 Aug 2026 10:59:08 +0000
Received: by outflank-mailman (input) for mailman id 1401913;
 Fri, 28 Aug 2026 10:59:07 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzuId-0006qF-Fc
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 10:59:07 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzuIc-00EJyt-Sa
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:59:06 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9169d4-2eae-0a2a0a5409dd-0a2a4504ce66-46
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 12:59:06 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9169fa-b57f-0a2a45040019-d155802ad1d1-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 12:59:06 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-4995b0343c1so7292895e9.3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 03:59:06 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b9266be71sm109242725e9.2.2026.08.28.03.59.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 03:59:05 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787914746; x=1788519546; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=ZRVlkhCv6l9DDyUTo6EL5BoaJ+aNHhPjPh6yq9TdpJM=;
        b=ePWaR1RiDfpuxx5Kf2aRJ2jB3Dwn00IyIFfbVTLGEyLSQYfNziDdC9+yhSvMcTLg27
         MR1I390ZH/lhBZ9W6glnlDb8GyKZDatT78doNFIlHuLfbMEANAjS6Mka10uv48UFE5QK
         dCdXEznuVExHoAsf5NkK9yMi2JPynU049tnHgl3LTwp0F9+UwlgehTfbYBKqwg8hg19G
         +tq/myaalW12OD5zsIi32dWW7YKfrFwbdGTQkYUmKio4uJGwimBcqh2jej+hEYOj9ZJ3
         NqXImrfgLzrdoOIaemZ4MWBg/pmtP8OEWCZF//gZIhOj8x9xxRm5WKOy+93PnHvd8xtQ
         aKMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787914746; x=1788519546;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=ZRVlkhCv6l9DDyUTo6EL5BoaJ+aNHhPjPh6yq9TdpJM=;
        b=q/ZJlQXLA3f/q+qp2kFdyNgrOQYhbUdWJtOd/ozrei0l34bETlDeKxeE0w/S3iHtAI
         F8GZHtWQCHwOlb9avkY9mCbV5cXCLtSNuCI0BOW8CY+JXR7furo1GCXB9LrAqbGWosPh
         FeZsfJfnG+M3d5CmEgUvVzN/dLbfbXq5WrFEhZqdRqLAW+ZQun/X/DtTj1FXnTKXFxAY
         FA6Zo/s9lGbMa8K6uDcBdNyZqjIAIgyIetn+SRvHkvK6o8qM1+5sKREBnzBmzjp5dedp
         NtP79aaGSv4UFG5ol3V89FK9wgP3FnIM8FjtIKiA5FJcHq6NqQpmTZCyI51rLc7iug9T
         9/bg==
X-Forwarded-Encrypted: i=1; AHgh+RotzFiys03oHuCP4ugF57h6JGWyxpefhHRSPsu8oWQq6GC3NmLPUjCva8v19qF+kRXpp3aWkLXrHJ0=@lists.xenproject.org
X-Gm-Message-State: AFuF++nD8emj7B6RGD8MJN3jiHlFB36Zf/AhVz2F2djeb56EIosFHQLp
	Rl3Fxda60Qx9Tb/2eZIGy290OJCv14QXG992FHbEMBNOPd5PO+wrFvbf
X-Gm-Gg: AR+sD10xPejyhV8NoaKoZV4pUNxNuL32LopSb1MFlYuKP6Ctsbi3TroKcPnXyItinPx
	rx/drxGHiR1OLJI2rYHoIZJQR4S/rytiv2/uFHlrk/oTHpSZp1V8chHmFV03GlD9nKHFBVPZgXV
	mOa7xD5HE1XVvvRihKMSv19lQfG8O3yJwSINayC92w0N9Vy7yMS2qceyZZArFUykysd8+YXzEwJ
	Iwa1nUhill1h3+vkg5ZbzJxIIAMMyKwGboZg/7pfwrtExOyvyERnRhutodJQLygtN5cLsO+9//v
	TmkWCxuxbJTFA/YPW8et15k8Csq5UEPyNxfTxyroqu3I9qAWj/GUAb/gF4GYLtkmIIQ1+dUYnba
	cOXWJprAIxV5UvfyIKTry1X/cvU405mhkTfYQ7LgmCTh/rUAjeCMAiAf76csagOtiu8NvjqNyuo
	k7US5JKikNY+sBUf1eyg0YeZB0QQQEqByunMip5Sc77es89glljOTNxXXENk9vRmkXH1bMYthPg
	ipzrdrzCsJqvyZjAD+aryqEr74QgyxMtTBaisGx2RwJjB1IhBR5
X-Received: by 2002:a05:600c:1d11:b0:496:c1f3:e8f8 with SMTP id 5b1f17b1804b1-49b91c25414mr81356125e9.7.1787914746051;
        Fri, 28 Aug 2026 03:59:06 -0700 (PDT)
Message-ID: <3adf6ef7-8024-420f-935b-17b142c73256@gmail.com>
Date: Fri, 28 Aug 2026 12:59:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/5] xen/riscv: always set A/D bits at boot time
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787914746-516D2B50-DD389F38/10/73395122804
X-purgate-type: spam
X-purgate-size: 11657



On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> Always set the PTE A/D bits at boot time to avoid an unhandled page fault
> on platforms that implement neither Svade nor Svadu, and on platforms that
> declare both in the device tree.
> 
> Rewrite the comment to enumerate the four possible Svade/Svadu combinations
> (inspired by [1]) and set A/D unconditionally, which is correct in all four
> cases until Svadu is fully supported (full support requires the SBI FWFT
> call to enable hardware updating of A/D bits).
> 
> [1] https://lwn.net/Articles/980016/
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> ---
>   xen/arch/riscv/p2m.c | 70 ++++++++++++++++++++++++++------------------
>   1 file changed, 42 insertions(+), 28 deletions(-)
> 
> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
> index 1cea86512c..11dc289f0f 100644
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -591,38 +591,52 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
>       e->pte |= PTE_USER;
>   
>       /*
> -     * Two schemes to manage the A and D bits are defined:
> -     *   • The Svade extension: when a virtual page is accessed and the A bit
> -     *     is clear, or is written and the D bit is clear, a page-fault
> -     *     exception is raised.
> -     *   • When the Svade extension is not implemented, the following scheme
> -     *     applies.
> -     *     When a virtual page is accessed and the A bit is clear, the PTE is
> -     *     updated to set the A bit. When the virtual page is written and the
> -     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
> -     *     address translation is in use and is not Bare, the G-stage virtual
> -     *     pages may be accessed or written by implicit accesses to VS-level
> -     *     memory management data structures, such as page tables.
> -     * Thereby to avoid a page-fault in case of Svade is available, it is
> -     * necessary to set A and D bits.
> +     * Svade and Svadu extensions represent two schemes for managing the PTE
> +     * A/D bits. When the PTE A/D bits need to be set, the Svade extension
> +     * indicates that a page fault will be raised. In contrast, the Svadu
> +     * extension supports hardware updating of the PTE A/D bits.
>        *
> -     * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI
> -     *       delegates page faults to a lower privilege mode and so OpenSBI
> -     *       isn't expect to handle page-faults occured in lower modes.
> -     *       By setting the A/D bits here, page faults that would otherwise
> -     *       be generated due to unset A/D bits will not occur in Xen.
> +     * There are 4 possible combinations of these extensions in the device
> +     * tree. The default hardware behavior for each is:
>        *
> -     *       Currently, Xen on RISC-V does not make use of the information
> -     *       that could be obtained from handling such page faults, which
> -     *       could otherwise be useful for several use cases such as demand
> -     *       paging, cache-flushing optimizations, memory access tracking,etc.
> +     * 1) Neither Svade nor Svadu present in DT => It is technically unknown
> +     *    whether the platform uses Svade or Svadu. Xen should be prepared to
> +     *    handle either hardware updating of the PTE A/D bits or page faults
> +     *    when they need updating. To support both, Xen always sets the 'A' and
> +     *    'D' PTE bits at boot time.
>        *
> -     *       To support the more general case and the optimizations mentioned
> -     *       above, it would be better to stop setting the A/D bits here and
> -     *       instead handle page faults that occur due to unset A/D bits.
> +     * 2) Only Svade present in DT => Xen must assume Svade to be always
> +     *    enabled.
> +     *
> +     * 3) Only Svadu present in DT => Xen must assume Svadu to be always
> +     *    enabled.
> +     *
> +     * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
> +     *    off at boot time by setting A/D bits. To use Svadu, the supervisor
> +     *    must explicitly enable it using the SBI FWFT extension.
> +     *
> +     * The Svade extension is mandatory and the Svadu extension is optional in
> +     * the RVA23 profile. Platforms wanting to take advantage of Svadu can
> +     * choose option 3. Platforms aware of the profile can choose option 4, and
> +     * Linux won't get the benefit of Svadu until the SBI FWFT extension is
> +     * available.

I have a feeling that the DT-binding-related comment should not be 
present here, as it explains when Svadu or Svade should be considered 
enabled or disabled. We should perform this kind of detection in 
riscv_fill_hwcap() [cpufeature.c]. Then, in p2m_set_permission(), we 
should use riscv_isa_extension_available() to determine which extension 
is available and, based on that, set the A and D bits.

At this point, I think the original comment was better, as it simply 
explained what Svade and Svadu are and, therefore, provided a better 
explanation of why the A and D bits should or should not be set.

So, my suggestion is the following:

+/*
+ * Svade and Svadu extensions represent two schemes for managing the PTE
+ * A/D bits. When the PTE A/D bits need to be set, the Svade extension
+ * indicates that a page fault will be raised. In contrast, the Svadu
+ * extension supports hardware updating of the PTE A/D bits.
+ *
+ * There are 4 possible combinations of these extensions in the device 
tree.
+ * The default hardware behavior for each is:
+ *
+ * 1) Neither Svade nor Svadu present in DT => It is technically unknown
+ *    whether the platform uses Svade or Svadu. Xen should be prepared to
+ *    handle either hardware updating of the PTE A/D bits or page 
faults when
+ *    they need updating. To support both, Xen always sets the 'A' and 
'D' PTE
+ *    bits at boot time.
+ *
+ * 2) Only Svade present in DT => Xen must assume Svade to be always 
enabled.
+ *
+ * 3) Only Svadu present in DT => Xen must assume Svadu to be always 
enabled.
+ *
+ * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
+ *    off at boot time by setting A/D bits. To use Svadu, the 
supervisor must
+ *    explicitly enable it using the SBI FWFT extension.
+ *
+ * The Svade extension is mandatory and the Svadu extension is optional 
in the
+ * RVA23 profile. Platforms wanting to take advantage of Svadu can choose
+ * option 3. Platforms aware of the profile can choose option 4, and 
Xen won't
+ * get the benefit of Svadu until the SBI FWFT extension is available.
+ *
+ * In other words, hardware manages the A/D bits on its own only in case 3;
+ * in all the other cases software has to preset them. Instead of open 
coding
+ * this in every A/D bits user, RISCV_ISA_EXT_svade is used to mean 
"software
+ * is responsible for the A/D bits" and is set here for the cases 1, 2 
and 4.
+ */
+static void __init riscv_resolve_ad_scheme(void)
+{
+    bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade);
+    bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu);
+
+    /* Case 3: leave the A/D bits management to hardware. */
+    if ( svadu && !svade )
+        return;
+
+    /* Cases 1, 2 and 4: Xen has to preset the A/D bits. */
+    __set_bit(RISCV_ISA_EXT_svade, riscv_isa);
+}
+
  void __init riscv_fill_hwcap(void)
  {
      unsigned int i;
@@ -513,6 +560,8 @@ void __init riscv_fill_hwcap(void)
          __set_bit(RISCV_ISA_EXT_sstc, riscv_isa);
      }

+    riscv_resolve_ad_scheme();
+

And then ...


> +     *
> +     * Currently, Xen on RISC-V does not make use of the information that could
> +     * be obtained from handling such page faults, which could otherwise be
> +     * useful for several use cases such as demand paging, cache-flushing
> +     * optimizations, memory access tracking, etc.
> +     *
> +     * To support the more general case and the optimizations mentioned above,
> +     * it would be better to stop setting the A/D bits here and instead handle
> +     * page faults that occur due to unset A/D bits.
> +     */
> +
> +    /*
> +     * Preset unconditionally for all 4 cases above, harmless when Svadu
> +     * manages the bits (case 3). Skipping it for case 3 requires SBI FWFT
> +     * which is not yet supported.
>        */
> -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
> -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
> +    e->pte |= PTE_ACCESSED | PTE_DIRTY;

... we could restore the check and the comment we originally had in 
p2m_set_permission(), but probably with some updates, something along 
the following lines:

/*
  * Xen has to preset the A/D bits unless the hardware is known to update
  * them on its own. riscv_fill_hwcap() folds all the Svade/Svadu device
  * tree combinations into RISCV_ISA_EXT_svade, which then means that
  * software is responsible for the A/D bits" (see
  * riscv_resolve_ad_scheme()).
  */

I have another comment regarding:

 > +    /*
 > +     * Preset unconditionally for all 4 cases above, harmless when Svadu
 > +     * manages the bits (case 3). Skipping it for case 3 requires 
SBI FWFT
 > +     * which is not yet supported.
 >        */
 > -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
 > -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
 > +    e->pte |= PTE_ACCESSED | PTE_DIRTY;

I am not sure that this comment is correct. In case 3, we should not 
need to use the SBI FWFT extension. Case 3 means that Xen must assume 
that Svadu is enabled. Therefore, it is the responsibility of OpenSBI, 
or the pre-bootloader that loads OpenSBI, to enable it. If it fails to 
do so, then OpenSBI or the pre-bootloader is not complying with the DT 
binding documentation and it should be fixed in first place.

As further evidence, this is what OpenSBI already does [1]:
/*
  * Assume only Svadu is supported when it is the only extension
  * present in the ISA string. Svade is assumed when neither are
  * present. When both are present we must default to Svade (see
  * the zero reset value of FWFT.PTE_AD_HW_UPDATING).
  */
if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE))
     __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE);

Therefore, in case 3, the original check is still valid, and there is no 
need for Xen to support the SBI FWFT extension for this case. I think 
the original check should therefore be kept as it was:

if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
     e->pte |= PTE_ACCESSED | PTE_DIRTY;

The SBI FWFT extension is only required for case 4. If both Svade and 
Svadu are present in the DT, Svade is selected by default. To use Svadu 
instead, SBI FWFT is required to set the ADUE bit in menvcfg, which is 
only accessible from M-mode.

Since SBI FWFT is relatively new and may not be supported by older 
OpenSBI versions, another option is to have OpenSBI hard-code ADUE=1. 
Alternatively, the DTS could specify only one of Svade or Svadu in the 
riscv,isa property. In that case, upstream OpenSBI can handle the 
configuration automatically. So specifically for our case (Svadu and 
Svade things) we don't need SBI FWFT at all.

[1] 
https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_hart.c#L171

~ Oleksii




From xen-devel-bounces@lists.xenproject.org Fri Aug 28 12:07:14 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 12:07:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401955.1637395 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvMM-00067y-Mx; Fri, 28 Aug 2026 12:07:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401955.1637395; Fri, 28 Aug 2026 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvMM-00067q-JD; Fri, 28 Aug 2026 12:07:02 +0000
Received: by outflank-mailman (input) for mailman id 1401955;
 Fri, 28 Aug 2026 12:07:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wzvML-00067k-7e
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:07:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzvMJ-0020xm-VS
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:07:00 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a9179c5-2eae-0a2a0a5409dd-0a2a4509e49e-36
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:06:59 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a9179e2-be1a-0a2a45090019-aa0a817c9563-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:06:59 +0200
Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-641-psgM2I-bM7GU71t1G24AKA-1; Fri,
 28 Aug 2026 08:06:55 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 76A101953984; Fri, 28 Aug 2026 12:06:53 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id EF6A91803A44; Fri, 28 Aug 2026 12:06:51 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787918818;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ONIJNZGy8Vp4rvH9aG4YnmO9S58iMfbY3N0MtThAE9I=;
	b=iVxuvd5qeFJ5tKEVCZwBKLDrxxMEEPbhjBeNRg1KPuiIIWz8wQ19w3fkL+gN9IcVbS5RM5
	6XN7Gt0zEJxz8AmwFC4bvAWqbv1NqgVkbitgkufCTbWS8vhbT8/OdznyOft0ygp9oIPQGy
	NINAB/oqb5Wc+fytZjWDQEmYE0pn4Lo=
X-MC-Unique: psgM2I-bM7GU71t1G24AKA-1
X-Mimecast-MFC-AGG-ID: psgM2I-bM7GU71t1G24AKA_1787918813
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Fri, 28 Aug 2026 16:04:27 +0400
Subject: [PATCH v5 30/50] monitor: isolate HMP declarations in hmp.h
MIME-Version: 1.0
Message-Id: <20260828-qemu-no-hmp-v5-30-9227de146347@redhat.com>
References: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
In-Reply-To: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
 "Michael S. Tsirkin" <mst@redhat.com>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Jason Wang <jasowangio@gmail.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=15880;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=ED7BcHvOtevt0A+0hTZ6huQ110MQWdHvMRRIRkDFviA=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkXk5jpqSCtWaYeQpkSH/ahLz7niYUU+OqCOr6
 d6N2MwjCh6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapF5OQAKCRDa6OEJdZac
 5S+ND/47nZI3HLHEF0Yd7B0BByIJhatVazXkXaDTEUxKpeKrMlH05poY37bkzcSy+lgS2CR0GGa
 m3yN7xfFMuwzbNwjunI32N8y0wPIhiuDN+CF6it7K9rJhBYCAORrc/OTITynQTVW17Z/iYqXvMW
 d58TM1G+8NbLycskApve0QRfOzrs7kdZ0kLpPeWbFbdc/0tw6oxnaNbJhX6n9rqt/u+4GnfxyeT
 onY7SynAI2/7as0TedZCXa8kMFow5ttAvkAIpgP57rlCdeEd5M1PklwAN1AX1SMwLR498zARdRv
 j96x94seBNNH26Gbh6y9hTTq65EvsN0yJXHstmgZHwoJjfsRpSAqgQ+WO1r8Lrvty+4yWHvzynM
 6jhhCSKiG/AlABvOo2I9fyWCG+XySwEOlIDu3j/LZ2NeImLXApMpf+59TGwBNGjSnq1M2EBz35o
 VyBjd84PrwBuuQfpcaHlkBevfYc3PEVQO5W/gqoqQrcJt3E8UnH8Vp/a+o6s7y8nrXEpUzYs/sZ
 zyKSPNLjD8O69enIDH5kvGmENKUQjwyW0cUK9VQan+6pXw/yqNATxSuzOf/1TtswHwU560vyK4Q
 2ITd1kzdeetDASqvqjpUhWbbo2cEgq3tyAgZjKELDG4fYzg2J8Zg4Ax0gWahWiDKYtb1teleFen
 jW4/t8LlDmnwqYg==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: W4u95x5KreaLsypeERGPE9zjjeIE7GZBHjdSPuWqIV0_1787918813
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787918819-FC817034-BCF553EA/0/0
X-purgate-type: clean
X-purgate-size: 15882

Also rename password & commands with hmp in the name, while at it.
Other functions need larger changes which we will take care of next.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 accel/accel-system.c           |  1 +
 accel/tcg/monitor.c            |  1 +
 chardev/char.c                 |  2 +-
 disas/disas-mon.c              |  1 +
 gdbstub/system.c               |  2 +-
 hw/char/virtio-serial-bus.c    |  1 +
 hw/core/machine-hmp-cmds.c     |  1 -
 hw/core/sysbus.c               |  1 +
 hw/hexagon/hexagon_tlb.c       |  1 +
 hw/misc/auxbus.c               |  1 +
 hw/usb/bus.c                   |  1 +
 hw/usb/host-libusb.c           |  1 +
 hw/xen/xen-bus.c               |  1 +
 include/monitor/hmp.h          | 21 +++++++++++++++++++++
 include/monitor/monitor.h      | 18 ------------------
 monitor/hmp.c                  |  8 ++++----
 monitor/monitor-internal.h     |  1 +
 net/slirp.c                    |  1 +
 stubs/monitor-core.c           |  1 +
 stubs/monitor-internal.c       |  2 +-
 target/rx/disas.c              |  1 +
 tests/unit/test-util-sockets.c |  1 +
 tools/qemu-vnc/stubs.c         |  1 +
 trace/trace-hmp-cmds.c         |  1 -
 ui/ui-hmp-cmds.c               |  4 ++--
 util/error-report.c            |  2 +-
 util/qemu-print.c              |  1 +
 27 files changed, 48 insertions(+), 30 deletions(-)

diff --git a/accel/accel-system.c b/accel/accel-system.c
index 9176665202d2..977804c4048a 100644
--- a/accel/accel-system.c
+++ b/accel/accel-system.c
@@ -28,6 +28,7 @@
 #include "qom/compat-properties.h"
 #include "qapi/qapi-commands-accelerator.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "hw/core/boards.h"
 #include "hw/core/cpu.h"
 #include "accel/accel-ops.h"
diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
index be5c1950177c..74170ddef708 100644
--- a/accel/tcg/monitor.c
+++ b/accel/tcg/monitor.c
@@ -11,6 +11,7 @@
 #include "qapi/type-helpers.h"
 #include "qapi/qapi-commands-machine.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/tcg.h"
 #include "tcg/tcg.h"
 #include "internal-common.h"
diff --git a/chardev/char.c b/chardev/char.c
index c6c8133f5c1d..9da0911e503c 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -24,7 +24,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "monitor/qmp-helpers.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index 9c693618c277..bc9dec3a7761 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -10,6 +10,7 @@
 #include "system/memory.h"
 #include "hw/core/cpu.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 /*
  * Get LENGTH bytes from info's buffer, at target address memaddr.
diff --git a/gdbstub/system.c b/gdbstub/system.c
index 070bc26f416c..8a1cdb11db36 100644
--- a/gdbstub/system.c
+++ b/gdbstub/system.c
@@ -29,7 +29,7 @@
 #include "hw/core/boards.h"
 #include "chardev/char.h"
 #include "chardev/char-fe.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "internals.h"
 
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index c1973f0248fc..02604740f86a 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -25,6 +25,7 @@
 #include "qemu/module.h"
 #include "migration/qemu-file-types.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/queue.h"
 #include "hw/core/qdev-properties.h"
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 686304bafab5..1c700aad3587 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -15,7 +15,6 @@
 
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-builtin-visit.h"
 #include "qapi/qapi-commands-accelerator.h"
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 3e1160ee921d..13df7cbafe10 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -21,6 +21,7 @@
 #include "qapi/error.h"
 #include "hw/core/sysbus.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index b6d4aff389e5..2d878cee736d 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -12,6 +12,7 @@
 #include "hw/core/resettable.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 877f34560626..ac2525b90fec 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -33,6 +33,7 @@
 #include "hw/misc/auxbus.h"
 #include "hw/i2c/i2c.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 
 #ifndef DEBUG_AUX
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 3b6fbd46ac3f..9b9b2e7c2f8f 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -9,6 +9,7 @@
 #include "system/system.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "qemu/cutils.h"
 
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index b9f3ad3f66dd..af67d5dfeb10 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -48,6 +48,7 @@
 #include "qapi/error.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "qemu/module.h"
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index dfad2bc5085f..a563f6066bb4 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -17,6 +17,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/xen/xen-bus-helper.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "qobject/qdict.h"
 #include "system/system.h"
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 9258a049bffb..166cd4100c63 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -18,6 +18,9 @@
 #include "qapi/qapi-types-common.h"
 #include "monitor/monitor.h"
 
+#define TYPE_MONITOR_HMP "monitor-hmp"
+OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
+
 #define HMP_STUB(cmd) \
     void hmp_##cmd(Monitor *mon, const QDict *qdict) \
     { \
@@ -30,6 +33,24 @@ struct MonitorDef {
     int64_t (*get_value)(Monitor *mon, const MonitorDef *md, int offset);
 };
 
+void monitor_new_hmp(const char *id, const char *chardev_id,
+                     bool use_readline, Error **errp);
+
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+    G_GNUC_PRINTF(2, 0);
+int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_printc(Monitor *mon, int ch);
+
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque);
+
+void monitor_register_hmp(const char *name, bool info,
+                          void (*cmd)(Monitor *mon, const QDict *qdict));
+void monitor_register_hmp_info_hrt(const char *name,
+                                   HumanReadableText *(*handler)(Error **errp));
+
+
 CPUArchState *mon_get_cpu_env(Monitor *mon);
 CPUState *mon_get_cpu(Monitor *mon);
 
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 9f048ba103b5..72a8f6ea5b4f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -10,9 +10,6 @@
 #define TYPE_MONITOR "monitor"
 OBJECT_DECLARE_TYPE(Monitor, MonitorClass, MONITOR);
 
-#define TYPE_MONITOR_HMP "monitor-hmp"
-OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
-
 #define TYPE_MONITOR_QMP "monitor-qmp"
 OBJECT_DECLARE_TYPE(MonitorQMP, MonitorQMPClass, MONITOR_QMP);
 
@@ -30,8 +27,6 @@ void monitor_init_globals_core(void);
 char *monitor_compat_id(void);
 void monitor_new_qmp(const char *id, const char *chardev_id,
                      bool pretty, Error **errp);
-void monitor_new_hmp(const char *id, const char *chardev_id,
-                     bool use_readline, Error **errp);
 int monitor_new(MonitorOptions *opts, bool allow_hmp, Error **errp);
 int monitor_new_opts(QemuOpts *opts, Error **errp);
 void monitor_cleanup(void);
@@ -43,28 +38,15 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp);
 int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp);
 
 int monitor_puts(Monitor *mon, const char *str);
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
 void monitor_flush(Monitor *mon);
 int monitor_get_cpu_index(Monitor *mon);
 
 int monitor_puts_locked(Monitor *mon, const char *str);
 void monitor_flush_locked(Monitor *mon);
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt);
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque);
-
 AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
                                 const char *opaque, Error **errp);
 int monitor_fdset_dup_fd_add(int64_t fdset_id, int flags, Error **errp);
 void monitor_fdset_dup_fd_remove(int dup_fd);
 
-void monitor_register_hmp(const char *name, bool info,
-                          void (*cmd)(Monitor *mon, const QDict *qdict));
-void monitor_register_hmp_info_hrt(const char *name,
-                                   HumanReadableText *(*handler)(Error **errp));
-
 #endif /* MONITOR_H */
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 8134dfaad4bb..b4d05d47c4bf 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -136,7 +136,7 @@ static void monitor_command_cb(void *opaque, const char *cmdline,
     monitor_resume(&hmp->parent_obj);
 }
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt)
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt)
 {
     if (!hmp->rs) {
         return;
@@ -148,8 +148,8 @@ void monitor_read_command(MonitorHMP *hmp, int show_prompt)
     }
 }
 
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque)
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque)
 {
     if (hmp->rs) {
         readline_start(hmp->rs, "Password: ", 1, readline_func, opaque);
@@ -1647,7 +1647,7 @@ static void monitor_hmp_complete(UserCreatable *uc, Error **errp)
                                     monitor_readline_flush,
                                     hmp,
                                     monitor_find_completion);
-            monitor_read_command(hmp, 0);
+            monitor_hmp_read_command(hmp, 0);
         }
 
         qemu_chr_fe_set_handlers(&hmp->parent_obj.chr,
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index fdeeeb853636..ee9ba0c8231e 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -27,6 +27,7 @@
 
 #include "chardev/char-fe.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 #include "qapi/qapi-types-control.h"
 #include "qapi/qapi-types-qom.h"
diff --git a/net/slirp.c b/net/slirp.c
index 517dd23be14b..9bf09a2c8bc9 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -36,6 +36,7 @@
 #include "clients.h"
 #include "hub.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/sockets.h"
 #include <libslirp.h>
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index a7c32297c90a..b0c7002bd406 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 
 Monitor *monitor_cur(void)
diff --git a/stubs/monitor-internal.c b/stubs/monitor-internal.c
index 731fad221ecc..6f69f1f14ae4 100644
--- a/stubs/monitor-internal.c
+++ b/stubs/monitor-internal.c
@@ -1,6 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
 {
diff --git a/target/rx/disas.c b/target/rx/disas.c
index 67b932882914..0eb2ee6f4507 100644
--- a/target/rx/disas.c
+++ b/target/rx/disas.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 #include "disas/dis-asm.h"
 #include "qemu/bitops.h"
+#include "monitor/hmp.h"
 #include "cpu.h"
 
 typedef struct DisasContext {
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index ab3f39c3efb5..b2a884529598 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -24,6 +24,7 @@
 #include "qapi/error.h"
 #include "socket-helpers.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 static void test_fd_is_socket_bad(void)
 {
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 1c82d8cff430..26597fefaa99 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -9,6 +9,7 @@
 #include "system/runstate.h"
 #include "hw/core/qdev.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "migration/vmstate.h"
 
 bool runstate_is_running(void)
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 390173095cff..c8f0133abecf 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -25,7 +25,6 @@
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
 #include "monitor/hmp-completion.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-trace.h"
 #include "qobject/qdict.h"
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 806a7bece7cb..4ef459490ba2 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -327,7 +327,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
                                 void *readline_opaque)
 {
     qmp_change_vnc_password(password, NULL);
-    monitor_read_command(opaque, 1);
+    monitor_hmp_read_command(opaque, 1);
 }
 
 void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
@@ -344,7 +344,7 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
     }
     if (!arg) {
         MonitorHMP *hmp = MONITOR_HMP(mon);
-        monitor_read_password(hmp, hmp_change_read_arg, NULL);
+        monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
     }
diff --git a/util/error-report.c b/util/error-report.c
index f333af9249b9..aaa15bc79827 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -11,7 +11,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 
 /*
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 7b9591035e57..a2d1f0244168 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -12,6 +12,7 @@
 
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/qemu-print.h"
 
 /*

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 12:08:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 12:08:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401962.1637403 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvNe-0006zq-1v; Fri, 28 Aug 2026 12:08:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401962.1637403; Fri, 28 Aug 2026 12:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvNd-0006zf-UI; Fri, 28 Aug 2026 12:08:21 +0000
Received: by outflank-mailman (input) for mailman id 1401962;
 Fri, 28 Aug 2026 12:08:20 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wzvNb-0006z9-QI
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:08:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzvNb-003BMA-6z
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:08:19 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a917a27-bab6-0a2a0a5309dd-0a2a4505edd2-18
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:08:14 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a917a2c-4cb1-0a2a45050019-aa0a857cba9d-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:08:13 +0200
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-194-KbfTN2ihM62S20v7pXtShg-1; Fri,
 28 Aug 2026 08:08:08 -0400
Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 6A60D18512FD; Fri, 28 Aug 2026 12:08:01 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 5D51E3001D39; Fri, 28 Aug 2026 12:07:39 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787918892;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=JRllbUFb3rtiLSPmcLBmO735jcqSr2/B0b4evWVRL9o=;
	b=aX1Iu64rXE9Inf6Q1FnT97qE4MtcFJXi9/AivkYcJf4JAj6YkWg2oZq+HyRi4kbkvHbfu2
	kVUUk+OpcNSUj6zGXTSRyUBCAeXw8PiDqH2Xs8SC6AoOkoSlxplODvVhiWTIwwqeoI0Tni
	Z3olu3Lb34CSgr+Uo1EKkNq/KIcNAZo=
X-MC-Unique: KbfTN2ihM62S20v7pXtShg-1
X-Mimecast-MFC-AGG-ID: KbfTN2ihM62S20v7pXtShg_1787918882
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Fri, 28 Aug 2026 16:04:34 +0400
Subject: [PATCH v5 37/50] monitor: tighten monitor_printf*()
MIME-Version: 1.0
Message-Id: <20260828-qemu-no-hmp-v5-37-9227de146347@redhat.com>
References: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
In-Reply-To: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>, 
 Gerd Hoffmann <kraxel@redhat.com>, 
 "Gonglei (Arei)" <arei.gonglei@huawei.com>, 
 zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>, 
 Hanna Reitz <hreitz@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Ani Sinha <anisinha@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, 
 Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>, 
 Richard Henderson <richard.henderson@linaro.org>, 
 Marcelo Tosatti <mtosatti@redhat.com>, 
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, 
 Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>, 
 Halil Pasic <pasic@linux.ibm.com>, 
 Christian Borntraeger <borntraeger@linux.ibm.com>, 
 Jason Herne <jjherne@linux.ibm.com>, Eric Farman <farman@linux.ibm.com>, 
 Matthew Rosato <mjrosato@linux.ibm.com>, 
 Ilya Leoshkevich <iii@linux.ibm.com>, David Hildenbrand <david@kernel.org>, 
 Cornelia Huck <cohuck@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>, 
 Fabiano Rosas <farosas@suse.de>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Stefan Berger <stefanb@linux.vnet.ibm.com>, Zhao Liu <zhao1.liu@intel.com>, 
 Nicholas Piggin <npiggin@gmail.com>, Chinmay Rath <rathc@linux.ibm.com>, 
 Glenn Miles <milesg@linux.ibm.com>, 
 Harsh Prateek Bora <harshpb@linux.ibm.com>, 
 Palmer Dabbelt <palmer@dabbelt.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Weiwei Li <liwei1518@gmail.com>, 
 Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, 
 Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
 Chao Liu <chao.liu@processmission.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, 
 kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, 
 xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=268565;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=F7nTduyvi7gYOY2fforu+PhKr1+NrZycvr7NnVCFLpc=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkXk5a85jNipHd4G5ah0WQNk2GU2horKj1Yp4S
 JFCBgQDv+6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapF5OQAKCRDa6OEJdZac
 5UsAEACXx1nYe4Y152rid1azBQeopwZOg+zt6XeZeLzGur+szN4bEUU9+o+KyyK4kF3lXU2S5up
 dlLnG5m0UZZZu//hI0dOLdzH65gWTyDja7EzMNQlI1viUC12gyfSPMNC3o4eFMIMdcDxq/QnUbA
 ybjm+gBqtcD92zOjYu4VKhHpM5NNC4/CnKuZ0F+v9DqRYy/yDK31pzTvUJeTg2/EVv0dLbcz7BO
 GaAEAD5Nav5Hp7GOgVyfonxa7d5WxdrlQQEr38L5LqY2OtdwvEjYBcv+jgVt25zILZR59vKnrqk
 IsT023FMkeRvdz24dT0zM27d0ZSTrGW1Vj0gO425dw0+iP1NwEZEkFx7wouio98J1maC6kr0IG2
 gg3An/OaeNQsR5ISrOG1O08PfGxtIdQXrSY2qDgfBvJzZmjXNN7gw5+dx7r+cW7T4MbUCgEFKQu
 ApzeByaQy7CN/j1FHSFpaOCoVt5B7GmwQlr+siCFRHXESj33Aed3SG3h0pORTdfoCa/+adFp4pS
 jxXqLWDhDHpr1Mj7G17aDlo1ChFf+7bR5j0kL1axRR93CKqlIlIY+7EAnu3aVMrwV+qllMhcneC
 w8mnbD3GcHKs+Uk/70bD0qaZo9rcEKnyPJjmKd6EDKca36Kf3s/gnLFeWf0i8ZkiIkERc8gntBL
 HdD6fmlmdI1ia3A==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4
X-Mimecast-MFC-PROC-ID: JDC8cqmBCI7jotG5m1dIuo48QBKmzJcrCh335Kk54tI_1787918882
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787918894-736BD101-A4BC7856/0/0
X-purgate-type: clean
X-purgate-size: 268567

Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
the first parameter from Monitor * to MonitorHMP * to enforce type
safety. The implementation is also simplified: monitor_hmp_vprintf now
directly calls g_strdup_vprintf + monitor_puts, removing the virtual
dispatch via moncls->vprintf.

The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
cast, they are fixed in the following commits.

Early return in qemu_vprintf() if "hmp" is NULL, relying on
monitor_hmp_vprintf() handling NULL case is a bit uncommon.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 audio/audio-hmp-cmds.c                  |   6 +-
 backends/cryptodev-hmp-cmds.c           |   9 +-
 block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
 chardev/char-hmp-cmds.c                 |  12 +-
 disas/disas-mon.c                       |  10 +-
 docs/devel/style.rst                    |   2 +-
 docs/devel/writing-monitor-commands.rst |   8 +-
 dump/dump-hmp-cmds.c                    |   5 +-
 hw/char/virtio-serial-bus.c             |  10 +-
 hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
 hw/core/sysbus.c                        |   5 +-
 hw/hexagon/hexagon_tlb.c                |  44 ++---
 hw/i386/kvm/xen-stubs.c                 |   6 +-
 hw/i386/kvm/xen_evtchn.c                |  21 +--
 hw/i386/sgx-hmp-stub.c                  |   3 +-
 hw/i386/sgx.c                           |  29 ++-
 hw/misc/auxbus.c                        |   9 +-
 hw/misc/mos6522-stub.c                  |   3 +-
 hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
 hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
 hw/pci/pci-stub.c                       |   3 +-
 hw/s390x/s390-skeys.c                   |   9 +-
 hw/s390x/s390-stattrib.c                |  20 +--
 hw/uefi/ovmf-log.c                      |   5 +-
 hw/usb/bus.c                            |  11 +-
 hw/usb/host-libusb.c                    |  21 ++-
 hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++---------------
 hw/xen/xen-bus.c                        |   5 +-
 include/disas/disas.h                   |   4 +-
 include/monitor/hmp.h                   |  12 +-
 migration/dirtyrate.c                   |  46 +++--
 migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----------------
 monitor/hmp-cmds.c                      | 141 +++++++--------
 monitor/hmp.c                           | 143 +++++++--------
 monitor/monitor-internal.h              |   6 -
 monitor/monitor.c                       |  33 ++--
 net/net-hmp-cmds.c                      |  31 ++--
 net/slirp.c                             |  31 ++--
 qom/qom-hmp-cmds.c                      |  27 ++-
 replay/replay-debugging.c               |   5 +-
 stats/stats-hmp-cmds.c                  |  57 +++---
 stubs/hmp-cmd-info_sev.c                |   3 +-
 stubs/monitor-core.c                    |   2 +-
 system/dirtylimit-hmp-cmds.c            |  10 +-
 system/qdev-monitor.c                   |  19 +-
 system/runstate-hmp-cmds.c              |  16 +-
 system/tpm-hmp-cmds.c                   |  29 ++-
 target/i386/cpu-apic.c                  |   3 +-
 target/i386/monitor.c                   | 152 ++++++++--------
 target/i386/sev.c                       |  35 ++--
 target/m68k/monitor.c                   |   3 +-
 target/ppc/monitor.c                    |   3 +-
 target/riscv/monitor.c                  |  55 +++---
 target/sh4/monitor.c                    |  29 ++-
 target/sparc/monitor.c                  |   3 +-
 target/xtensa/monitor.c                 |   3 +-
 tests/unit/test-util-sockets.c          |   2 +-
 tools/qemu-vnc/clipboard.c              |   4 +-
 tools/qemu-vnc/stubs.c                  |   2 +-
 trace/trace-hmp-cmds.c                  |  12 +-
 ui/ui-hmp-cmds.c                        | 115 ++++++------
 util/error-report.c                     |   2 +-
 util/qemu-print.c                       |  17 +-
 63 files changed, 1225 insertions(+), 1327 deletions(-)

diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
index 4d326ec99fdf..94182fe1d71f 100644
--- a/audio/audio-hmp-cmds.c
+++ b/audio/audio-hmp-cmds.c
@@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
 
 void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     CaptureState *s;
 
     warn_report_once("'info capture' is deprecated since v10.2, to be removed");
 
     for (s = capture_head.lh_first, i = 0; s; s = s->entries.le_next, ++i) {
-        monitor_printf(mon, "[%d]: ", i);
+        monitor_hmp_printf(hmp, "[%d]: ", i);
         s->ops.info (s->opaque);
     }
 }
@@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     int freq = qdict_get_try_int(qdict, "freq", 44100);
     int bits = qdict_get_try_int(qdict, "bits", 16);
@@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
     s = g_malloc0 (sizeof (*s));
 
     if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
-        monitor_printf(mon, "Failed to add wave capture\n");
+        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
         g_free (s);
         return;
     }
diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
index fb62428d795a..aafa4b970d24 100644
--- a/backends/cryptodev-hmp-cmds.c
+++ b/backends/cryptodev-hmp-cmds.c
@@ -19,7 +19,6 @@
 
 void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     QCryptodevInfoList *il;
     QCryptodevBackendServiceTypeList *sl;
     QCryptodevBackendClientList *cl;
@@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
                 services = tmp_services;
             }
         }
-        monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
+        monitor_hmp_printf(hmp, "%s: service=[%s]\n", info->id, services);
 
         for (cl = info->client; cl; cl = cl->next) {
             QCryptodevBackendClient *client = cl->value;
-            monitor_printf(mon, "    queue %" PRIu32 ": type=%s\n",
-                           client->queue,
-                           QCryptodevBackendType_str(client->type));
+            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=%s\n",
+                               client->queue,
+                               QCryptodevBackendType_str(client->type));
         }
     }
 
diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-cmds.c
index a2666e2f1b9b..7bae4d425c6d 100644
--- a/block/monitor/block-hmp-cmds.c
+++ b/block/monitor/block-hmp-cmds.c
@@ -89,7 +89,6 @@ out:
 
 void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     DriveInfo *dinfo;
     QemuOpts *opts;
@@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 
     switch (dinfo->type) {
     case IF_NONE:
-        monitor_printf(mon, "OK\n");
+        monitor_hmp_printf(hmp, "OK\n");
         break;
     default:
         error_setg(&err, "Can't hot-add drive to type %d", dinfo->type);
@@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdict)
     hmp_handle_error(hmp, err);
 }
 
-static void print_block_info(Monitor *mon, BlockInfo *info,
+static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
                              BlockDeviceInfo *inserted, bool verbose)
 {
+    Monitor *mon = MONITOR(hmp);
     ImageInfo *image_info;
 
     assert(!info || !info->inserted || info->inserted == inserted);
@@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     if (info && *info->device) {
         monitor_puts(mon, info->device);
         if (inserted && inserted->node_name) {
-            monitor_printf(mon, " (%s)", inserted->node_name);
+            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
         }
     } else {
         assert(info || inserted);
@@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (inserted) {
-        monitor_printf(mon, ": %s (%s%s%s%s)\n",
-                       inserted->file,
-                       inserted->drv,
-                       inserted->ro ? ", read-only" : "",
-                       inserted->encrypted ? ", encrypted" : "",
-                       inserted->active ? "" : ", inactive");
+        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
+                           inserted->file,
+                           inserted->drv,
+                           inserted->ro ? ", read-only" : "",
+                           inserted->encrypted ? ", encrypted" : "",
+                           inserted->active ? "" : ", inactive");
     } else {
-        monitor_printf(mon, ": [not inserted]\n");
+        monitor_hmp_printf(hmp, ": [not inserted]\n");
     }
 
     if (info) {
         if (info->qdev) {
-            monitor_printf(mon, "    Attached to:      %s\n", info->qdev);
+            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info->qdev);
         }
         if (info->has_io_status && info->io_status != BLOCK_DEVICE_IO_STATUS_OK) {
-            monitor_printf(mon, "    I/O status:       %s\n",
-                           BlockDeviceIoStatus_str(info->io_status));
+            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
+                               BlockDeviceIoStatus_str(info->io_status));
         }
 
         if (info->removable) {
-            monitor_printf(mon, "    Removable device: %slocked, tray %s\n",
-                           info->locked ? "" : "not ",
-                           info->tray_open ? "open" : "closed");
+            monitor_hmp_printf(hmp, "    Removable device: %slocked, tray %s\n",
+                               info->locked ? "" : "not ",
+                               info->tray_open ? "open" : "closed");
         }
     }
 
@@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
         return;
     }
 
-    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
-                   inserted->cache->writeback ? "writeback" : "writethrough",
-                   inserted->cache->direct ? ", direct" : "",
-                   inserted->cache->no_flush ? ", ignore flushes" : "");
+    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
+                       inserted->cache->writeback ? "writeback" : "writethrough",
+                       inserted->cache->direct ? ", direct" : "",
+                       inserted->cache->no_flush ? ", ignore flushes" : "");
 
     if (inserted->backing_file) {
-        monitor_printf(mon,
-                       "    Backing file:     %s "
-                       "(chain depth: %" PRId64 ")\n",
-                       inserted->backing_file,
-                       inserted->backing_file_depth);
+        monitor_hmp_printf(hmp,
+                           "    Backing file:     %s "
+                           "(chain depth: %" PRId64 ")\n",
+                           inserted->backing_file,
+                           inserted->backing_file_depth);
     }
 
     if (inserted->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF) {
-        monitor_printf(mon, "    Detect zeroes:    %s\n",
+        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
                 BlockdevDetectZeroesOptions_str(inserted->detect_zeroes));
     }
 
     if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
         inserted->iops || inserted->iops_rd || inserted->iops_wr)
     {
-        monitor_printf(mon, "    I/O throttling:   bps=%" PRId64
+        monitor_hmp_printf(hmp, "    I/O throttling:   bps=%" PRId64
                         " bps_rd=%" PRId64  " bps_wr=%" PRId64
                         " bps_max=%" PRId64
                         " bps_rd_max=%" PRId64
@@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (verbose) {
-        monitor_printf(mon, "\nImages:\n");
+        monitor_hmp_printf(hmp, "\nImages:\n");
         image_info = inserted->image;
         while (1) {
             bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, false);
@@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
 
 void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockInfoList *block_list, *info;
     BlockDeviceInfoList *blockdev_list, *blockdev;
     const char *device = qdict_get_try_str(qdict, "device");
@@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (info != block_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, info->value, info->value->inserted,
+        print_block_info(hmp, info->value, info->value->inserted,
                          verbose);
         printed = true;
     }
@@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (blockdev != blockdev_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, NULL, blockdev->value, verbose);
+        print_block_info(hmp, NULL, blockdev->value, verbose);
     }
     qapi_free_BlockDeviceInfoList(blockdev_list);
 }
 
 void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockStatsList *stats_list, *stats;
 
     stats_list = qmp_query_blockstats(false, false, NULL);
@@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
 
-        monitor_printf(mon, "%s%s: idle_time_ns=%" PRId64 "\n",
-                       stats != stats_list ? "\n" : "",
-                       stats->value->device,
-                       stats->value->stats->idle_time_ns);
-        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
-                       "operations", "total_time_ns", "merged");
-        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->rd_bytes,
-                       stats->value->stats->rd_operations,
-                       stats->value->stats->rd_total_time_ns,
-                       stats->value->stats->rd_merged);
-        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->wr_bytes,
-                       stats->value->stats->wr_operations,
-                       stats->value->stats->wr_total_time_ns,
-                       stats->value->stats->wr_merged);
-        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
-                       "",
-                       stats->value->stats->flush_operations,
-                       stats->value->stats->flush_total_time_ns);
+        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=%" PRId64 "\n",
+                           stats != stats_list ? "\n" : "",
+                           stats->value->device,
+                           stats->value->stats->idle_time_ns);
+        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes",
+                           "operations", "total_time_ns", "merged");
+        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->rd_bytes,
+                           stats->value->stats->rd_operations,
+                           stats->value->stats->rd_total_time_ns,
+                           stats->value->stats->rd_merged);
+        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->wr_bytes,
+                           stats->value->stats->wr_operations,
+                           stats->value->stats->wr_total_time_ns,
+                           stats->value->stats->wr_merged);
+        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
+                           "",
+                           stats->value->stats->flush_operations,
+                           stats->value->stats->flush_total_time_ns);
     }
 
     qapi_free_BlockStatsList(stats_list);
@@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockJobInfoList *list;
 
     list = qmp_query_block_jobs(&error_abort);
 
     if (!list) {
-        monitor_printf(mon, "No active jobs\n");
+        monitor_hmp_printf(hmp, "No active jobs\n");
         return;
     }
 
     while (list) {
         if (list->value->type == JOB_TYPE_STREAM) {
-            monitor_printf(mon, "Streaming device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Streaming device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         } else {
-            monitor_printf(mon, "Type %s, device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           JobType_str(list->value->type),
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               JobType_str(list->value->type),
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         }
         list = list->next;
     }
@@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockDriverState *bs, *bs1;
     BdrvNextIterator it1;
     QEMUSnapshotInfo *sn_tab, *sn;
@@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     nb_sns = bdrv_snapshot_list(bs, &sn_tab);
 
     if (nb_sns < 0) {
-        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
+        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_sns);
         return;
     }
 
@@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (no_snapshot) {
-        monitor_printf(mon, "There is no snapshot available.\n");
+        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
         return;
     }
 
@@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
             }
         }
     }
-    monitor_printf(mon, "List of snapshots present on all disks:\n");
+    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n");
 
     if (total > 0) {
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         for (i = 0; i < total; i++) {
             sn = &sn_tab[global_snapshots[i]];
             /*
@@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
              */
             pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
             bdrv_snapshot_dump(sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     } else {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
     }
 
     QTAILQ_FOREACH(image_entry, &image_list, next) {
         if (QTAILQ_EMPTY(&image_entry->snapshots)) {
             continue;
         }
-        monitor_printf(mon,
-                       "\nList of partial (non-loadable) snapshots on '%s':\n",
-                       image_entry->imagename);
+        monitor_hmp_printf(hmp,
+                           "\nList of partial (non-loadable) snapshots on '%s':\n",
+                           image_entry->imagename);
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) {
             bdrv_snapshot_dump(&snapshot_entry->sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
@@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     g_free(global_snapshots);
 }
 
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp)
 {
diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
index 71017fd2d19e..fb0560054b7b 100644
--- a/chardev/char-hmp-cmds.c
+++ b/chardev/char-hmp-cmds.c
@@ -26,12 +26,11 @@
 
 void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     ChardevInfoList *char_info, *info;
 
     char_info = qmp_query_chardev(NULL);
     for (info = char_info; info; info = info->next) {
-        monitor_printf(mon, "%s: filename=%s\n", info->value->label,
+        monitor_hmp_printf(hmp, "%s: filename=%s\n", info->value->label,
                                                  info->value->filename);
     }
 
@@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *chardev = qdict_get_str(qdict, "device");
     char *data;
@@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
         unsigned char ch = data[i];
 
         if (ch == '\\') {
-            monitor_printf(mon, "\\\\");
+            monitor_hmp_printf(hmp, "\\\\");
         } else if ((ch < 0x20 && ch != '\n' && ch != '\t') || ch == 0x7F) {
-            monitor_printf(mon, "\\u%04X", ch);
+            monitor_hmp_printf(hmp, "\\u%04X", ch);
         } else {
-            monitor_printf(mon, "%c", ch);
+            monitor_hmp_printf(hmp, "%c", ch);
         }
 
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     g_free(data);
 }
 
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index bc9dec3a7761..32e4220181a8 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
 }
 
 /* Disassembler for the monitor.  */
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical)
 {
     int count, i;
@@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
     s.info.buffer_vma = pc;
 
     if (s.info.cap_arch >= 0 && cap_disas_monitor(&s.info, pc, nb_insn)) {
-        monitor_puts(mon, ds->str);
+        monitor_puts(MONITOR(hmp), ds->str);
         return;
     }
 
     if (!s.info.print_insn) {
-        monitor_printf(mon, "0x%08" PRIx64
-                       ": Asm output not supported on this arch\n", pc);
+        monitor_hmp_printf(hmp, "0x%08" PRIx64
+                           ": Asm output not supported on this arch\n", pc);
         return;
     }
 
@@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
         pc += count;
     }
 
-    monitor_puts(mon, ds->str);
+    monitor_puts(MONITOR(hmp), ds->str);
 }
diff --git a/docs/devel/style.rst b/docs/devel/style.rst
index 6c5f94cc5098..6876d3a59ec7 100644
--- a/docs/devel/style.rst
+++ b/docs/devel/style.rst
@@ -754,7 +754,7 @@ Error handling and reporting
 Reporting errors to the human user
 ----------------------------------
 
-Do not use printf(), fprintf() or monitor_printf().  Instead, use
+Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
 error_report() or error_vreport() from error-report.h.  This ensures the
 error is reported in the right place (current monitor or stderr), and in
 a uniform format.
diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
index 7ae7efe32759..baf94cbdefab 100644
--- a/docs/devel/writing-monitor-commands.rst
+++ b/docs/devel/writing-monitor-commands.rst
@@ -479,7 +479,7 @@ The HMP command
 
 Here's the HMP counterpart of the query-option-roms command::
 
- void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
+ void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
  {
      Error *err = NULL;
      OptionRomInfoList *info_list, *tail;
@@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-roms command::
 
      for (tail = info_list; tail; tail = tail->next) {
          info = tail->value;
-         monitor_printf(mon, "%s", info->filename);
+         monitor_hmp_printf(mon, "%s", info->filename);
          if (info->has_bootindex) {
-             monitor_printf(mon, " %" PRId64, info->bootindex);
+             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
          }
-         monitor_printf(mon, "\n");
+         monitor_hmp_printf(mon, "\n");
      }
 
      qapi_free_OptionRomInfoList(info_list);
diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
index 104ab5d2a53a..c7045c2d7314 100644
--- a/dump/dump-hmp-cmds.c
+++ b/dump/dump-hmp-cmds.c
@@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DumpQueryResult *result = qmp_query_dump(NULL);
 
     assert(result && result->status < DUMP_STATUS__MAX);
-    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status));
+    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->status));
 
     if (result->status == DUMP_STATUS_ACTIVE) {
         float percent = 0;
         assert(result->total != 0);
         percent = 100.0 * result->completed / result->total;
-        monitor_printf(mon, "Finished: %.2f %%\n", percent);
+        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
     }
 
     qapi_free_DumpQueryResult(result);
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 02604740f86a..33fdc0846ac3 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
-                   indent, "", port->id,
-                   port->guest_connected ? "on" : "off",
-                   port->host_connected ? "on" : "off",
-                   port->throttled ? "on" : "off");
+    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+                       indent, "", port->id,
+                       port->guest_connected ? "on" : "off",
+                       port->host_connected ? "on" : "off",
+                       port->throttled ? "on" : "off");
 }
 
 /* This function is only used if a port id is not provided by the user */
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 702c798ccc56..10a633af0780 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -27,7 +27,6 @@
 
 void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CpuInfoFastList *cpu_list, *cpu;
 
     cpu_list = qmp_query_cpus_fast(NULL);
@@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
             active = '*';
         }
 
-        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
-                       cpu->value->cpu_index);
-        monitor_printf(mon, " thread_id=%" PRId64 " model=%s\n",
-                       cpu->value->thread_id, cpu_model);
+        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
+                           cpu->value->cpu_index);
+        monitor_hmp_printf(hmp, " thread_id=%" PRId64 " model=%s\n",
+                           cpu->value->thread_id, cpu_model);
     }
 
     qapi_free_CpuInfoFastList(cpu_list);
@@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     HotpluggableCPUList *l = qmp_query_hotpluggable_cpus(&err);
     HotpluggableCPUList *saved = l;
@@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Hotpluggable CPUs:\n");
+    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
     while (l) {
-        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
-        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
-                       l->value->vcpus_count);
+        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
+        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
+                           l->value->vcpus_count);
         if (l->value->qom_path) {
-            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_path);
+            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->qom_path);
         }
 
         c = l->value->props;
-        monitor_printf(mon, "  CPUInstance Properties:\n");
+        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
         if (c->has_node_id) {
-            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
+            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
         }
         if (c->has_drawer_id) {
-            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
+            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
         }
         if (c->has_book_id) {
-            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
+            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
         }
         if (c->has_socket_id) {
-            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
+            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
         }
         if (c->has_die_id) {
-            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
+            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
         }
         if (c->has_cluster_id) {
-            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
-                           c->cluster_id);
+            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n",
+                               c->cluster_id);
         }
         if (c->has_module_id) {
-            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
-                           c->module_id);
+            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n",
+                               c->module_id);
         }
         if (c->has_core_id) {
-            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
+            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
         }
         if (c->has_thread_id) {
-            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
+            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
         }
 
         l = l->next;
@@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemdevList *memdev_list = qmp_query_memdev(&err);
     MemdevList *m = memdev_list;
@@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
     while (m) {
         v = string_output_visitor_new(false, &str);
         visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_abort);
-        monitor_printf(mon, "memory backend: %s\n", m->value->id);
-        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
-        monitor_printf(mon, "  merge: %s\n",
-                       m->value->merge ? "true" : "false");
-        monitor_printf(mon, "  dump: %s\n",
-                       m->value->dump ? "true" : "false");
-        monitor_printf(mon, "  prealloc: %s\n",
-                       m->value->prealloc ? "true" : "false");
-        monitor_printf(mon, "  share: %s\n",
-                       m->value->share ? "true" : "false");
+        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
+        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->size);
+        monitor_hmp_printf(hmp, "  merge: %s\n",
+                           m->value->merge ? "true" : "false");
+        monitor_hmp_printf(hmp, "  dump: %s\n",
+                           m->value->dump ? "true" : "false");
+        monitor_hmp_printf(hmp, "  prealloc: %s\n",
+                           m->value->prealloc ? "true" : "false");
+        monitor_hmp_printf(hmp, "  share: %s\n",
+                           m->value->share ? "true" : "false");
         if (m->value->has_reserve) {
-            monitor_printf(mon, "  reserve: %s\n",
-                           m->value->reserve ? "true" : "false");
+            monitor_hmp_printf(hmp, "  reserve: %s\n",
+                               m->value->reserve ? "true" : "false");
         }
-        monitor_printf(mon, "  policy: %s\n",
-                       HostMemPolicy_str(m->value->policy));
+        monitor_hmp_printf(hmp, "  policy: %s\n",
+                           HostMemPolicy_str(m->value->policy));
         visit_complete(v, &str);
-        monitor_printf(mon, "  host nodes: %s\n", str);
+        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
 
         g_free(str);
         visit_free(v);
         m = m->next;
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_MemdevList(memdev_list);
     hmp_handle_error(hmp, err);
@@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     KvmInfo *info;
 
     info = qmp_query_kvm(NULL);
-    monitor_printf(mon, "kvm support: ");
+    monitor_hmp_printf(hmp, "kvm support: ");
     if (info->present) {
-        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disabled");
+        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "disabled");
     } else {
-        monitor_printf(mon, "not compiled\n");
+        monitor_hmp_printf(hmp, "not compiled\n");
     }
 
     qapi_free_KvmInfo(info);
@@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     AcceleratorInfo *info;
     AcceleratorList *accel;
 
@@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
     for (accel = info->present; accel; accel = accel->next) {
         char trail = accel->next ? ' ' : '\n';
         if (info->enabled == accel->value) {
-            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->value), trail);
         } else {
-            monitor_printf(mon, "%s%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->value), trail);
         }
     }
 
@@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     UuidInfo *info;
 
     info = qmp_query_uuid(NULL);
-    monitor_printf(mon, "%s\n", info->UUID);
+    monitor_hmp_printf(hmp, "%s\n", info->UUID);
     qapi_free_UuidInfo(info);
 }
 
 void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BalloonInfo *info;
     Error *err = NULL;
 
@@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
+    monitor_hmp_printf(hmp, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
 
     qapi_free_BalloonInfo(info);
 }
@@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *filename = qdict_get_str(qdict, "filename");
     uint64_t addr = qdict_get_int(qdict, "val");
@@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
     int cpu_index = monitor_hmp_get_cpu_index(hmp);
 
     if (cpu_index < 0) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
@@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryDeviceInfoList *info_list = qmp_query_memory_devices(&err);
     MemoryDeviceInfoList *info;
@@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
             case MEMORY_DEVICE_INFO_KIND_NVDIMM:
                 di = value->type == MEMORY_DEVICE_INFO_KIND_DIMM ?
                      value->u.dimm.data : value->u.nvdimm.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               di->id ? di->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->addr);
-                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot);
-                monitor_printf(mon, "  node: %" PRId64 "\n", di->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size);
-                monitor_printf(mon, "  memdev: %s\n", di->memdev);
-                monitor_printf(mon, "  hotplugged: %s\n",
-                               di->hotplugged ? "true" : "false");
-                monitor_printf(mon, "  hotpluggable: %s\n",
-                               di->hotpluggable ? "true" : "false");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   di->id ? di->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di->addr);
+                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->slot);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
+                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
+                                   di->hotplugged ? "true" : "false");
+                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
+                                   di->hotpluggable ? "true" : "false");
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
                 vpi = value->u.virtio_pmem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vpi->id ? vpi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size);
-                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vpi->id ? vpi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
                 vmi = value->u.virtio_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vmi->id ? vmi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node);
-                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
-                               vmi->requested_size);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size);
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->max_size);
-                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
-                               vmi->block_size);
-                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vmi->id ? vmi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->node);
+                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "\n",
+                                   vmi->requested_size);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", vmi->max_size);
+                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
+                                   vmi->block_size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
                 se = value->u.sgx_epc.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               se->id ? se->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size);
-                monitor_printf(mon, "  node: %" PRId64 "\n", se->node);
-                monitor_printf(mon, "  memdev: %s\n", se->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   se->id ? se->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->size);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->node);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
                 hi = value->u.hv_balloon.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               hi->id ? hi->id : "");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   hi->id ? hi->id : "");
                 if (hi->has_memaddr) {
-                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
-                                   hi->memaddr);
+                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n",
+                                       hi->memaddr);
                 }
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->max_size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", hi->max_size);
                 if (hi->memdev) {
-                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
+                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memdev);
                 }
                 break;
             case MEMORY_DEVICE_INFO_KIND_SP_MEM:
                 spmi = value->u.sp_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               spmi->id ? spmi->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->addr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->size);
-                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   spmi->id ? spmi->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spmi->addr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev);
                 break;
             default:
                 g_assert_not_reached();
@@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     GuidInfo *info = qmp_query_vm_generation_id(&err);
     if (info) {
-        monitor_printf(mon, "%s\n", info->guid);
+        monitor_hmp_printf(hmp, "%s\n", info->guid);
     }
     hmp_handle_error(hmp, err);
     qapi_free_GuidInfo(info);
@@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryInfo *info = qmp_query_memory_size_summary(&err);
     if (info) {
-        monitor_printf(mon, "base memory: %" PRIu64 "\n",
-                       info->base_memory);
+        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
+                           info->base_memory);
 
         if (info->has_plugged_memory) {
-            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
-                           info->plugged_memory);
+            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
+                               info->plugged_memory);
         }
 
         qapi_free_MemoryInfo(info);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 13df7cbafe10..82130ba04698 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
     for (i = 0; i < s->num_mmio; i++) {
         size = memory_region_size(s->mmio[i].memory);
-        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                       indent, "", s->mmio[i].addr, size);
+        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                           indent, "", s->mmio[i].addr, size);
     }
 }
 
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index 2d878cee736d..576929ff224b 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t entry)
 
 bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
+
     if (GET_PTE_V(entry)) {
         uint64_t PA = hex_tlb_phys_addr(entry);
         uint64_t VA = hex_tlb_virt_addr(entry);
-        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
-        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
-                       " A1:%" PRId64 " A0:%" PRId64,
-                       GET_PTE_V(entry),
-                       GET_PTE_G(entry),
-                       GET_PTE_ATR1(entry),
-                       GET_PTE_ATR0(entry));
-        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
-                       GET_PTE_ASID(entry), VA);
-        monitor_printf(mon,
-                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
-                       " U:%" PRId64 " C:%" PRId64,
-                       GET_PTE_X(entry),
-                       GET_PTE_W(entry),
-                       GET_PTE_R(entry),
-                       GET_PTE_U(entry),
-                       GET_PTE_C(entry));
-        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
-                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
-                       hex_tlb_page_size_bytes(entry));
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
+        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
+                           " A1:%" PRId64 " A0:%" PRId64,
+                           GET_PTE_V(entry),
+                           GET_PTE_G(entry),
+                           GET_PTE_ATR1(entry),
+                           GET_PTE_ATR0(entry));
+        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
+                           GET_PTE_ASID(entry), VA);
+        monitor_hmp_printf(hmp,
+                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
+                           " U:%" PRId64 " C:%" PRId64,
+                           GET_PTE_X(entry),
+                           GET_PTE_W(entry),
+                           GET_PTE_R(entry),
+                           GET_PTE_U(entry),
+                           GET_PTE_C(entry));
+        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
+                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
+                           hex_tlb_page_size_bytes(entry));
+        monitor_hmp_printf(hmp, "\n");
         return true;
     }
 
diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
index ab1eb14f99e0..5ed71583281a 100644
--- a/hw/i386/kvm/xen-stubs.c
+++ b/hw/i386/kvm/xen-stubs.c
@@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 00dff6ee8760..b2135020f27f 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **errp)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     EvtchnInfoList *iter, *info_list;
     Error *err = NULL;
 
@@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
     for (iter = info_list; iter; iter = iter->next) {
         EvtchnInfo *info = iter->value;
 
-        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info->vcpu,
-                       EvtchnPortType_str(info->type));
+        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, info->vcpu,
+                           EvtchnPortType_str(info->type));
         if (info->type != EVTCHN_PORT_TYPE_IPI) {
-            monitor_printf(mon,  "(");
+            monitor_hmp_printf(hmp,  "(");
             if (info->remote_domain) {
-                monitor_printf(mon, "%s:", info->remote_domain);
+                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
             }
-            monitor_printf(mon, "%d)", info->target);
+            monitor_hmp_printf(hmp, "%d)", info->target);
         }
         if (info->pending) {
-            monitor_printf(mon, " PENDING");
+            monitor_hmp_printf(hmp, " PENDING");
         }
         if (info->masked) {
-            monitor_printf(mon, " MASKED");
+            monitor_hmp_printf(hmp, " MASKED");
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_EvtchnInfoList(info_list);
@@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int port = qdict_get_int(qdict, "port");
     Error *err = NULL;
 
@@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
     if (err) {
         hmp_handle_error(hmp, err);
     } else {
-        monitor_printf(mon, "Delivered port %d\n", port);
+        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
     }
 }
-
diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
index a4848ae1d1a7..b7afb26886a8 100644
--- a/hw/i386/sgx-hmp-stub.c
+++ b/hw/i386/sgx-hmp-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SGX is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
 }
diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
index 77b41d234c9f..634e33e819ce 100644
--- a/hw/i386/sgx.c
+++ b/hw/i386/sgx.c
@@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     SgxEpcSectionList *section_list, *section;
     g_autoptr(SgxInfo) info = qmp_query_sgx(&err);
@@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
         error_report_err(err);
         return;
     }
-    monitor_printf(mon, "SGX support: %s\n",
-                   info->sgx ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX1 support: %s\n",
-                   info->sgx1 ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX2 support: %s\n",
-                   info->sgx2 ? "enabled" : "disabled");
-    monitor_printf(mon, "FLC support: %s\n",
-                   info->flc ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX support: %s\n",
+                       info->sgx ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
+                       info->sgx1 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
+                       info->sgx2 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "FLC support: %s\n",
+                       info->flc ? "enabled" : "disabled");
 
     section_list = info->sections;
     for (section = section_list; section; section = section->next) {
-        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
-                       section->value->node);
-        monitor_printf(mon, "size=%" PRIu64 "\n",
-                       section->value->size);
+        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
+                           section->value->node);
+        monitor_hmp_printf(hmp, "size=%" PRIu64 "\n",
+                           section->value->size);
         size += section->value->size;
     }
-    monitor_printf(mon, "total size=%" PRIu64 "\n",
-                   size);
+    monitor_hmp_printf(hmp, "total size=%" PRIu64 "\n",
+                       size);
 }
 
 bool check_sgx_support(void)
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ac2525b90fec..ffa76f83016b 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                   indent, "",
-                   object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
-                   memory_region_size(s->mmio));
+    monitor_hmp_printf(MONITOR_HMP(mon),
+                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                       indent, "",
+                       object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
+                       memory_region_size(s->mmio));
 }
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
index 6a7d76292f00..154cd32ed88b 100644
--- a/hw/misc/mos6522-stub.c
+++ b/hw/misc/mos6522-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU\n");
 }
diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp-cmds.c
index 6405ce26dd65..5099d59cc620 100644
--- a/hw/net/rocker/rocker-hmp-cmds.c
+++ b/hw/net/rocker/rocker-hmp-cmds.c
@@ -22,7 +22,6 @@
 
 void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_str(qdict, "name");
     RockerSwitch *rocker;
     Error *err = NULL;
@@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "name: %s\n", rocker->name);
-    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
-    monitor_printf(mon, "ports: %d\n", rocker->ports);
+    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
+    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
+    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
 
     qapi_free_RockerSwitch(rocker);
 }
 
 void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerPortList *list, *port;
     const char *name = qdict_get_str(qdict, "name");
     Error *err = NULL;
@@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "            ena/    speed/ auto\n");
-    monitor_printf(mon, "      port  link    duplex neg?\n");
+    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
+    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
 
     for (port = list; port; port = port->next) {
-        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
-                       port->value->name,
-                       port->value->enabled ? port->value->link_up ?
-                       "up" : "down" : "!ena",
-                       port->value->speed == 10000 ? "10G" : "??",
-                       port->value->duplex ? "FD" : "HD",
-                       port->value->autoneg ? "Yes" : "No");
+        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
+                           port->value->name,
+                           port->value->enabled ? port->value->link_up ?
+                           "up" : "down" : "!ena",
+                           port->value->speed == 10000 ? "10G" : "??",
+                           port->value->duplex ? "FD" : "HD",
+                           port->value->autoneg ? "Yes" : "No");
     }
 
     qapi_free_RockerPortList(list);
@@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaFlowList *list, *info;
     const char *name = qdict_get_str(qdict, "name");
     uint32_t tbl_id = qdict_get_try_int(qdict, "tbl_id", -1);
@@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
+    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
 
     for (info = list; info; info = info->next) {
         RockerOfDpaFlow *flow = info->value;
@@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         RockerOfDpaFlowAction *action = flow->action;
 
         if (flow->hits) {
-            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
-                           key->priority, key->tbl_id, flow->hits);
+            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
+                               key->priority, key->tbl_id, flow->hits);
         } else {
-            monitor_printf(mon, "%-4d %-3d     ",
-                           key->priority, key->tbl_id);
+            monitor_hmp_printf(hmp, "%-4d %-3d     ",
+                               key->priority, key->tbl_id);
         }
 
         if (key->has_in_pport) {
-            monitor_printf(mon, " pport %d", key->in_pport);
+            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
             if (mask->has_in_pport) {
-                monitor_printf(mon, "(0x%x)", mask->in_pport);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
             }
         }
 
         if (key->has_vlan_id) {
-            monitor_printf(mon, " vlan %d",
-                           key->vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " vlan %d",
+                               key->vlan_id & VLAN_VID_MASK);
             if (mask->has_vlan_id) {
-                monitor_printf(mon, "(0x%x)", mask->vlan_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
             }
         }
 
         if (key->has_tunnel_id) {
-            monitor_printf(mon, " tunnel %d", key->tunnel_id);
+            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
             if (mask->has_tunnel_id) {
-                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
             }
         }
 
         if (key->has_eth_type) {
             switch (key->eth_type) {
             case 0x0806:
-                monitor_printf(mon, " ARP");
+                monitor_hmp_printf(hmp, " ARP");
                 break;
             case 0x0800:
-                monitor_printf(mon, " IP");
+                monitor_hmp_printf(hmp, " IP");
                 break;
             case 0x86dd:
-                monitor_printf(mon, " IPv6");
+                monitor_hmp_printf(hmp, " IPv6");
                 break;
             case 0x8809:
-                monitor_printf(mon, " LACP");
+                monitor_hmp_printf(hmp, " LACP");
                 break;
             case 0x88cc:
-                monitor_printf(mon, " LLDP");
+                monitor_hmp_printf(hmp, " LLDP");
                 break;
             default:
-                monitor_printf(mon, " eth type 0x%04x", key->eth_type);
+                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_type);
                 break;
             }
         }
@@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_src, "01:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
             } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any ucast>");
+                monitor_hmp_printf(hmp, " src <any ucast>");
             } else {
-                monitor_printf(mon, " src %s", key->eth_src);
+                monitor_hmp_printf(hmp, " src %s", key->eth_src);
                 if (mask->eth_src) {
-                    monitor_printf(mon, "(%s)", mask->eth_src);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
                 }
             }
         }
@@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_dst, "01:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
             } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any ucast>");
+                monitor_hmp_printf(hmp, " dst <any ucast>");
             } else {
-                monitor_printf(mon, " dst %s", key->eth_dst);
+                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
                 if (mask->eth_dst) {
-                    monitor_printf(mon, "(%s)", mask->eth_dst);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
                 }
             }
         }
 
         if (key->has_ip_proto) {
-            monitor_printf(mon, " proto %d", key->ip_proto);
+            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
             if (mask->has_ip_proto) {
-                monitor_printf(mon, "(0x%x)", mask->ip_proto);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
             }
         }
 
         if (key->has_ip_tos) {
-            monitor_printf(mon, " TOS %d", key->ip_tos);
+            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
             if (mask->has_ip_tos) {
-                monitor_printf(mon, "(0x%x)", mask->ip_tos);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
             }
         }
 
         if (key->ip_dst) {
-            monitor_printf(mon, " dst %s", key->ip_dst);
+            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
         }
 
         if (action->has_goto_tbl || action->has_group_id ||
             action->has_new_vlan_id) {
-            monitor_printf(mon, " -->");
+            monitor_hmp_printf(hmp, " -->");
         }
 
         if (action->has_new_vlan_id) {
-            monitor_printf(mon, " apply new vlan %d",
-                           ntohs(action->new_vlan_id));
+            monitor_hmp_printf(hmp, " apply new vlan %d",
+                               ntohs(action->new_vlan_id));
         }
 
         if (action->has_group_id) {
-            monitor_printf(mon, " write group 0x%08x", action->group_id);
+            monitor_hmp_printf(hmp, " write group 0x%08x", action->group_id);
         }
 
         if (action->has_goto_tbl) {
-            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
+            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaFlowList(list);
@@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaGroupList *list, *g;
     const char *name = qdict_get_str(qdict, "name");
     uint8_t type = qdict_get_try_int(qdict, "type", 9);
@@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "id (decode) --> buckets\n");
+    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
 
     for (g = list; g; g = g->next) {
         RockerOfDpaGroup *group = g->value;
         bool set = false;
 
-        monitor_printf(mon, "0x%08x", group->id);
+        monitor_hmp_printf(hmp, "0x%08x", group->id);
 
-        monitor_printf(mon, " (type %s", group->type == 0 ? "L2 interface" :
+        monitor_hmp_printf(hmp, " (type %s", group->type == 0 ? "L2 interface" :
                                          group->type == 1 ? "L2 rewrite" :
                                          group->type == 2 ? "L3 unicast" :
                                          group->type == 3 ? "L2 multicast" :
@@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
                                          "unknown");
 
         if (group->has_vlan_id) {
-            monitor_printf(mon, " vlan %d", group->vlan_id);
+            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
         }
 
         if (group->has_pport) {
-            monitor_printf(mon, " pport %d", group->pport);
+            monitor_hmp_printf(hmp, " pport %d", group->pport);
         }
 
         if (group->has_index) {
-            monitor_printf(mon, " index %d", group->index);
+            monitor_hmp_printf(hmp, " index %d", group->index);
         }
 
-        monitor_printf(mon, ") -->");
+        monitor_hmp_printf(hmp, ") -->");
 
         if (group->has_set_vlan_id && group->set_vlan_id) {
             set = true;
-            monitor_printf(mon, " set vlan %d",
-                           group->set_vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " set vlan %d",
+                               group->set_vlan_id & VLAN_VID_MASK);
         }
 
         if (group->set_eth_src) {
             if (!set) {
                 set = true;
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " src %s", group->set_eth_src);
+            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
         }
 
         if (group->set_eth_dst) {
             if (!set) {
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " dst %s", group->set_eth_dst);
+            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
         }
 
         if (group->has_ttl_check && group->ttl_check) {
-            monitor_printf(mon, " check TTL");
+            monitor_hmp_printf(hmp, " check TTL");
         }
 
         if (group->has_group_id && group->group_id) {
-            monitor_printf(mon, " group id 0x%08x", group->group_id);
+            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_id);
         }
 
         if (group->has_pop_vlan && group->pop_vlan) {
-            monitor_printf(mon, " pop vlan");
+            monitor_hmp_printf(hmp, " pop vlan");
         }
 
         if (group->has_out_pport) {
-            monitor_printf(mon, " out pport %d", group->out_pport);
+            monitor_hmp_printf(hmp, " out pport %d", group->out_pport);
         }
 
         if (group->has_group_ids) {
             struct uint32List *id;
 
-            monitor_printf(mon, " groups [");
+            monitor_hmp_printf(hmp, " groups [");
             for (id = group->group_ids; id; id = id->next) {
-                monitor_printf(mon, "0x%08x", id->value);
+                monitor_hmp_printf(hmp, "0x%08x", id->value);
                 if (id->next) {
-                    monitor_printf(mon, ",");
+                    monitor_hmp_printf(hmp, ",");
                 }
             }
-            monitor_printf(mon, "]");
+            monitor_hmp_printf(hmp, "]");
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaGroupList(list);
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 51d95d76620e..500f821246a9 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -24,54 +24,55 @@
 #include "qapi/qapi-commands-pci.h"
 #include "qemu/cutils.h"
 
-static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
+static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *dev)
 {
+    Monitor *mon = MONITOR(hmp);
     PciMemoryRegionList *region;
 
-    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
-    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n",
-                   dev->slot, dev->function);
-    monitor_printf(mon, "    ");
+    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
+    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 ":\n",
+                       dev->slot, dev->function);
+    monitor_hmp_printf(hmp, "    ");
 
     if (dev->class_info->desc) {
         monitor_puts(mon, dev->class_info->desc);
     } else {
-        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_class);
+        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q_class);
     }
 
-    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
-                   dev->id->vendor, dev->id->device);
+    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
+                       dev->id->vendor, dev->id->device);
     if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
-        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
-                       dev->id->subsystem_vendor, dev->id->subsystem);
+        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
+                           dev->id->subsystem_vendor, dev->id->subsystem);
     }
 
     if (dev->has_irq) {
-        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
-                       dev->irq, (char)('A' + dev->irq_pin - 1));
+        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
+                           dev->irq, (char)('A' + dev->irq_pin - 1));
     }
 
     if (dev->pci_bridge) {
-        monitor_printf(mon, "      BUS %" PRId64 ".\n",
-                       dev->pci_bridge->bus->number);
-        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->secondary);
-        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->subordinate);
+        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
+                           dev->pci_bridge->bus->number);
+        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->secondary);
+        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->subordinate);
 
-        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
-                       dev->pci_bridge->bus->io_range->base,
-                       dev->pci_bridge->bus->io_range->limit);
+        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
+                           dev->pci_bridge->bus->io_range->base,
+                           dev->pci_bridge->bus->io_range->limit);
 
-        monitor_printf(mon,
-                       "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->memory_range->base,
-                       dev->pci_bridge->bus->memory_range->limit);
+        monitor_hmp_printf(hmp,
+                           "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->memory_range->base,
+                           dev->pci_bridge->bus->memory_range->limit);
 
-        monitor_printf(mon, "      prefetchable memory range "
-                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->prefetchable_range->base,
-                       dev->pci_bridge->bus->prefetchable_range->limit);
+        monitor_hmp_printf(hmp, "      prefetchable memory range "
+                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->prefetchable_range->base,
+                           dev->pci_bridge->bus->prefetchable_range->limit);
     }
 
     for (region = dev->regions; region; region = region->next) {
@@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
         addr = region->value->address;
         size = region->value->size;
 
-        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->bar);
+        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->value->bar);
 
         if (!strcmp(region->value->type, "io")) {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "I/O at 0x%04" PRIx64
+                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
                                     " [0x%04" PRIx64 "]\n",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "I/O (not mapped)\n");
+                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
             }
         } else {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
+                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRIx64
                                    " [0x%08" PRIx64 "]\n",
                                region->value->mem_type_64 ? 64 : 32,
                                region->value->prefetch ? " prefetchable" : "",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
-                               region->value->mem_type_64 ? 64 : 32,
-                               region->value->prefetch ? " prefetchable" : "");
+                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\n",
+                                   region->value->mem_type_64 ? 64 : 32,
+                                   region->value->prefetch ? " prefetchable" : "");
             }
         }
     }
 
-    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
+    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
 
     if (dev->pci_bridge) {
         if (dev->pci_bridge->has_devices) {
             PciDeviceInfoList *cdev;
             for (cdev = dev->pci_bridge->devices; cdev; cdev = cdev->next) {
-                hmp_info_pci_device(mon, cdev->value);
+                hmp_info_pci_device(hmp, cdev->value);
             }
         }
     }
@@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
 
 void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     PciInfoList *info_list, *info;
 
     info_list = qmp_query_pci(&error_abort);
@@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
         PciDeviceInfoList *dev;
 
         for (dev = info->value->devices; dev; dev = dev->next) {
-            hmp_info_pci_device(mon, dev->value);
+            hmp_info_pci_device(hmp, dev->value);
         }
     }
 
@@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
@@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
         snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
     }
 
-    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
-                   "pci id %04x:%04x (sub %04x:%04x)\n",
-                   indent, "", ctxt, pci_dev_bus_num(d),
-                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                   pci_get_word(d->config + PCI_VENDOR_ID),
-                   pci_get_word(d->config + PCI_DEVICE_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
+    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
+                       "pci id %04x:%04x (sub %04x:%04x)\n",
+                       indent, "", ctxt, pci_dev_bus_num(d),
+                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+                       pci_get_word(d->config + PCI_VENDOR_ID),
+                       pci_get_word(d->config + PCI_DEVICE_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
         if (!r->size) {
             continue;
         }
-        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
-                       " [0x%"FMT_PCIBUS"]\n",
-                       indent, "",
-                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
-                       r->addr, r->addr + r->size - 1);
+        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
+                           " [0x%"FMT_PCIBUS"]\n",
+                           indent, "",
+                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
+                           r->addr, r->addr + r->size - 1);
     }
 }
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *id = qdict_get_str(qdict, "id");
     const char *error_name;
@@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
     }
 
 
-    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
-                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
-                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
+                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
+                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
 
 out:
     hmp_handle_error(hmp, err);
diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
index a80e34175462..7e2797300ba0 100644
--- a/hw/pci/pci-stub.c
+++ b/hw/pci/pci-stub.c
@@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "PCI devices not supported\n");
+    monitor_hmp_printf(hmp, "PCI devices not supported\n");
 }
 
 /* kvm-all wants this */
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index d8afaf730639..b5e56a16cce1 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
 
 void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390SKeysState *ss = s390_get_skeys_device();
     S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 
     /* Quick check to see if guest is using storage keys*/
     if (!skeyclass->skeys_are_enabled(ss)) {
-        monitor_printf(mon, "Error: This guest is not using storage keys\n");
+        monitor_hmp_printf(hmp, "Error: This guest is not using storage keys\n");
         return;
     }
 
     if (!address_space_access_valid(&address_space_memory,
                                     addr & TARGET_PAGE_MASK, TARGET_PAGE_SIZE,
                                     false, MEMTXATTRS_UNSPECIFIED)) {
-        monitor_printf(mon, "Error: The given address is not valid\n");
+        monitor_hmp_printf(hmp, "Error: The given address is not valid\n");
         return;
     }
 
     r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s\n", strerror(-r));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
         return;
     }
 
-    monitor_printf(mon, "  key: 0x%X\n", key);
+    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
 }
 
 void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index b4a405455901..644298f7f0b2 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -61,7 +61,6 @@ void s390_stattrib_init(void)
 
 void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t what = qdict_get_int(qdict, "mode");
@@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 
     r = sac->set_migrationmode(sas, what, &local_err);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
+        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_err));
         error_free(local_err);
     }
 }
 
 void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 
     vals = g_try_malloc(buflen);
     if (!vals) {
-        monitor_printf(mon, "Error: %s\n", strerror(errno));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
         return;
     }
 
     len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
     if (len < 0) {
-        monitor_printf(mon, "Error: %s", strerror(-len));
+        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
         goto out;
     }
 
-    monitor_printf(mon, "  CMMA attributes, "
-                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
-                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
+    monitor_hmp_printf(hmp, "  CMMA attributes, "
+                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
+                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
     for (cx = 0; cx < len; cx++) {
         if (cx % 8 == 7) {
-            monitor_printf(mon, "%02x\n", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
         } else {
-            monitor_printf(mon, "%02x", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x", vals[cx]);
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
 out:
     g_free(vals);
diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
index 0d59a74ad60e..0249eea2cfe9 100644
--- a/hw/uefi/ovmf-log.c
+++ b/hw/uefi/ovmf-log.c
@@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_size, uint64_t max_size,
 
 void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autofree gchar *log_esc = NULL;
     g_autofree guchar *log_out = NULL;
     Error *err = NULL;
@@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 
     if (log->version) {
         g_autofree gchar *esc = g_strescape(log->version, NULL);
-        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
+        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
     }
 
     log_out = g_base64_decode(log->log, &log_len);
     log_esc = g_strescape((gchar *)log_out, "\r\n");
-    monitor_printf(mon, "%s\n", log_esc);
+    monitor_hmp_printf(hmp, "%s\n", log_esc);
 }
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 9b9b2e7c2f8f..fe3dbfa2227c 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
 
 static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
-    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
-                   indent, "", bus->busnr, dev->addr,
-                   dev->port ? dev->port->path : "-",
-                   usb_speed(dev->speed), dev->product_desc,
-                   dev->attached ? ", attached" : "");
+    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
+                       indent, "", bus->busnr, dev->addr,
+                       dev->port ? dev->port->path : "-",
+                       usb_speed(dev->speed), dev->product_desc,
+                       dev->attached ? ", attached" : "");
 }
 
 static char *usb_get_dev_path(DeviceState *qdev)
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index c02343d3a655..9b9f26a1078e 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
 
 void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     libusb_device **devs = NULL;
     struct libusb_device_descriptor ddesc;
     char port[16];
@@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
         usb_host_get_port(devs[i], port, sizeof(port));
-        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
-                       libusb_get_bus_number(devs[i]),
-                       libusb_get_device_address(devs[i]),
-                       port,
-                       speed_name[libusb_get_device_speed(devs[i])]);
-        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
-        monitor_printf(mon, " USB device %04x:%04x",
-                       ddesc.idVendor, ddesc.idProduct);
+        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
+                           libusb_get_bus_number(devs[i]),
+                           libusb_get_device_address(devs[i]),
+                           port,
+                           speed_name[libusb_get_device_speed(devs[i])]);
+        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass);
+        monitor_hmp_printf(hmp, " USB device %04x:%04x",
+                           ddesc.idVendor, ddesc.idProduct);
         if (ddesc.iProduct) {
             libusb_device_handle *handle;
             if (libusb_open(devs[i], &handle) == 0) {
@@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
                                                    ddesc.iProduct,
                                                    name, sizeof(name));
                 libusb_close(handle);
-                monitor_printf(mon, ", %s", name);
+                monitor_hmp_printf(hmp, ", %s", name);
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
     libusb_free_device_list(devs, 1);
 }
diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
index fb36c8b9274c..e5da6f00699d 100644
--- a/hw/virtio/virtio-hmp-cmds.c
+++ b/hw/virtio/virtio-hmp-cmds.c
@@ -12,77 +12,76 @@
 #include "qobject/qdict.h"
 
 
-static void hmp_virtio_dump_protocols(Monitor *mon,
+static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
                                       VhostDeviceProtocols *pcol)
 {
     strList *pcol_list = pcol->protocols;
     while (pcol_list) {
-        monitor_printf(mon, "\t%s", pcol_list->value);
+        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
         pcol_list = pcol_list->next;
         if (pcol_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (pcol->has_unknown_protocols) {
-        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
-                       pcol->unknown_protocols);
+        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n",
+                           pcol->unknown_protocols);
     }
 }
 
-static void hmp_virtio_dump_status(Monitor *mon,
+static void hmp_virtio_dump_status(MonitorHMP *hmp,
                                    VirtioDeviceStatus *status)
 {
     strList *status_list = status->statuses;
     while (status_list) {
-        monitor_printf(mon, "\t%s", status_list->value);
+        monitor_hmp_printf(hmp, "\t%s", status_list->value);
         status_list = status_list->next;
         if (status_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (status->has_unknown_statuses) {
-        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
-                       status->unknown_statuses);
+        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n",
+                           status->unknown_statuses);
     }
 }
 
-static void hmp_virtio_dump_features(Monitor *mon,
+static void hmp_virtio_dump_features(MonitorHMP *hmp,
                                      VirtioDeviceFeatures *features)
 {
     strList *transport_list = features->transports;
     while (transport_list) {
-        monitor_printf(mon, "\t%s", transport_list->value);
+        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
         transport_list = transport_list->next;
         if (transport_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     strList *list = features->dev_features;
     if (list) {
         while (list) {
-            monitor_printf(mon, "\t%s", list->value);
+            monitor_hmp_printf(hmp, "\t%s", list->value);
             list = list->next;
             if (list != NULL) {
-                monitor_printf(mon, ",\n");
+                monitor_hmp_printf(hmp, ",\n");
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (features->has_unknown_dev_features) {
-        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
-                       features->unknown_dev_features2,
-                       features->unknown_dev_features);
+        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
+                           features->unknown_dev_features2,
+                           features->unknown_dev_features);
     }
 }
 
 void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     VirtioInfoList *list = qmp_x_query_virtio(&err);
     VirtioInfoList *node;
@@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (list == NULL) {
-        monitor_printf(mon, "No VirtIO devices\n");
+        monitor_hmp_printf(hmp, "No VirtIO devices\n");
         return;
     }
 
     node = list;
     while (node) {
-        monitor_printf(mon, "%s [%s]\n", node->value->path,
-                       node->value->name);
+        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
+                           node->value->name);
         node = node->next;
     }
     qapi_free_VirtioInfoList(list);
@@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     VirtioStatus *s = qmp_x_query_virtio_status(path, &err);
@@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:             %s %s\n",
-                   s->name, s->vhost_dev ? "(vhost)" : "");
-    monitor_printf(mon, "  device_id:               %d\n", s->device_id);
-    monitor_printf(mon, "  vhost_started:           %s\n",
-                   s->vhost_started ? "true" : "false");
-    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name);
-    monitor_printf(mon, "  broken:                  %s\n",
-                   s->broken ? "true" : "false");
-    monitor_printf(mon, "  disabled:                %s\n",
-                   s->disabled ? "true" : "false");
-    monitor_printf(mon, "  disable_legacy_check:    %s\n",
-                   s->disable_legacy_check ? "true" : "false");
-    monitor_printf(mon, "  started:                 %s\n",
-                   s->started ? "true" : "false");
-    monitor_printf(mon, "  use_started:             %s\n",
-                   s->use_started ? "true" : "false");
-    monitor_printf(mon, "  start_on_kick:           %s\n",
-                   s->start_on_kick ? "true" : "false");
-    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
-                   s->use_guest_notifier_mask ? "true" : "false");
-    monitor_printf(mon, "  vm_running:              %s\n",
-                   s->vm_running ? "true" : "false");
-    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
-    monitor_printf(mon, "  queue_sel:               %d\n",
-                   s->queue_sel);
-    monitor_printf(mon, "  isr:                     %d\n", s->isr);
-    monitor_printf(mon, "  endianness:              %s\n",
-                   s->device_endian);
-    monitor_printf(mon, "  status:\n");
-    hmp_virtio_dump_status(mon, s->status);
-    monitor_printf(mon, "  Guest features:\n");
-    hmp_virtio_dump_features(mon, s->guest_features);
-    monitor_printf(mon, "  Host features:\n");
-    hmp_virtio_dump_features(mon, s->host_features);
-    monitor_printf(mon, "  Backend features:\n");
-    hmp_virtio_dump_features(mon, s->backend_features);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
+                       s->name, s->vhost_dev ? "(vhost)" : "");
+    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->device_id);
+    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
+                       s->vhost_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_name);
+    monitor_hmp_printf(hmp, "  broken:                  %s\n",
+                       s->broken ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disabled:                %s\n",
+                       s->disabled ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
+                       s->disable_legacy_check ? "true" : "false");
+    monitor_hmp_printf(hmp, "  started:                 %s\n",
+                       s->started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_started:             %s\n",
+                       s->use_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
+                       s->start_on_kick ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
+                       s->use_guest_notifier_mask ? "true" : "false");
+    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
+                       s->vm_running ? "true" : "false");
+    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
+    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
+                       s->queue_sel);
+    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr);
+    monitor_hmp_printf(hmp, "  endianness:              %s\n",
+                       s->device_endian);
+    monitor_hmp_printf(hmp, "  status:\n");
+    hmp_virtio_dump_status(hmp, s->status);
+    monitor_hmp_printf(hmp, "  Guest features:\n");
+    hmp_virtio_dump_features(hmp, s->guest_features);
+    monitor_hmp_printf(hmp, "  Host features:\n");
+    hmp_virtio_dump_features(hmp, s->host_features);
+    monitor_hmp_printf(hmp, "  Backend features:\n");
+    hmp_virtio_dump_features(hmp, s->backend_features);
 
     if (s->vhost_dev) {
-        monitor_printf(mon, "  VHost:\n");
-        monitor_printf(mon, "    nvqs:           %d\n",
-                       s->vhost_dev->nvqs);
-        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
-                       s->vhost_dev->vq_index);
-        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
-                       s->vhost_dev->max_queues);
-        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
-                       s->vhost_dev->n_mem_sections);
-        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
-                       s->vhost_dev->n_tmp_sections);
-        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
-                       s->vhost_dev->backend_cap);
-        monitor_printf(mon, "    log_enabled:    %s\n",
-                       s->vhost_dev->log_enabled ? "true" : "false");
-        monitor_printf(mon, "    log_size:       %"PRId64"\n",
-                       s->vhost_dev->log_size);
-        monitor_printf(mon, "    Features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->features);
-        monitor_printf(mon, "    Acked features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
-        monitor_printf(mon, "    Protocol features:\n");
-        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features);
+        monitor_hmp_printf(hmp, "  VHost:\n");
+        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
+                           s->vhost_dev->nvqs);
+        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
+                           s->vhost_dev->vq_index);
+        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
+                           s->vhost_dev->max_queues);
+        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
+                           s->vhost_dev->n_mem_sections);
+        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
+                           s->vhost_dev->n_tmp_sections);
+        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
+                           s->vhost_dev->backend_cap);
+        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
+                           s->vhost_dev->log_enabled ? "true" : "false");
+        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
+                           s->vhost_dev->log_size);
+        monitor_hmp_printf(hmp, "    Features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
+        monitor_hmp_printf(hmp, "    Acked features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
+        monitor_hmp_printf(hmp, "    Protocol features:\n");
+        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features);
     }
 
     qapi_free_VirtioStatus(s);
@@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s (vhost)\n",
-                   s->name);
-    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick);
-    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call);
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
-    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
-                   s->desc_phys);
-    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
-    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
-                   s->avail_phys);
-    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size);
-    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
-                   s->used_phys);
-    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
+                       s->name);
+    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->kick);
+    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->call);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
+    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
+                       s->desc_phys);
+    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_size);
+    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
+                       s->avail_phys);
+    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_size);
+    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
+                       s->used_phys);
+    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_size);
 
     qapi_free_VirtVhostQueueStatus(s);
 }
 
 void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s\n", s->name);
-    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index);
-    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
-    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
-    monitor_printf(mon, "  signalled_used:       %d\n",
-                   s->signalled_used);
-    monitor_printf(mon, "  signalled_used_valid: %s\n",
-                   s->signalled_used_valid ? "true" : "false");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
+    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_index);
+    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
+    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_idx);
+    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
+                       s->signalled_used);
+    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
+                       s->signalled_used_valid ? "true" : "false");
     if (s->has_last_avail_idx) {
-        monitor_printf(mon, "  last_avail_idx:       %d\n",
-                       s->last_avail_idx);
+        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
+                           s->last_avail_idx);
     }
     if (s->has_shadow_avail_idx) {
-        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
-                       s->shadow_avail_idx);
+        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
+                           s->shadow_avail_idx);
     }
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num);
-    monitor_printf(mon, "    num_default:  %"PRId32"\n",
-                   s->vring_num_default);
-    monitor_printf(mon, "    align:        %"PRId32"\n",
-                   s->vring_align);
-    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
-                   s->vring_desc);
-    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
-                   s->vring_avail);
-    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
-                   s->vring_used);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_num);
+    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
+                       s->vring_num_default);
+    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
+                       s->vring_align);
+    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
+                       s->vring_desc);
+    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
+                       s->vring_avail);
+    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
+                       s->vring_used);
 
     qapi_free_VirtQueueStatus(s);
 }
 
 void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name: %s\n", e->name);
-    monitor_printf(mon, "  index:   %d\n", e->index);
-    monitor_printf(mon, "  desc:\n");
-    monitor_printf(mon, "    descs:\n");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
+    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
+    monitor_hmp_printf(hmp, "  desc:\n");
+    monitor_hmp_printf(hmp, "    descs:\n");
 
     list = e->descs;
     while (list) {
-        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
-                       list->value->addr, list->value->len);
+        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
+                           list->value->addr, list->value->len);
         if (list->value->flags) {
             strList *flag = list->value->flags;
-            monitor_printf(mon, " (");
+            monitor_hmp_printf(hmp, " (");
             while (flag) {
-                monitor_printf(mon, "%s", flag->value);
+                monitor_hmp_printf(hmp, "%s", flag->value);
                 flag = flag->next;
                 if (flag) {
-                    monitor_printf(mon, ", ");
+                    monitor_hmp_printf(hmp, ", ");
                 }
             }
-            monitor_printf(mon, ")");
+            monitor_hmp_printf(hmp, ")");
         }
         list = list->next;
         if (list) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
-    monitor_printf(mon, "  avail:\n");
-    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
-    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
-    monitor_printf(mon, "  used:\n");
-    monitor_printf(mon, "    flags: %d\n", e->used->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
+    monitor_hmp_printf(hmp, "\n");
+    monitor_hmp_printf(hmp, "  avail:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
+    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
+    monitor_hmp_printf(hmp, "  used:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
 
     qapi_free_VirtioQueueElement(e);
 }
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index a563f6066bb4..4075b5b001ae 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -103,10 +103,11 @@ abort:
 
 static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
-    monitor_printf(mon, "%*sname = '%s' frontend_id = %u\n",
-                   indent, "", xendev->name, xendev->frontend_id);
+    monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
+                       indent, "", xendev->name, xendev->frontend_id);
 }
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
diff --git a/include/disas/disas.h b/include/disas/disas.h
index c702b1effc1c..47daa9b4d2df 100644
--- a/include/disas/disas.h
+++ b/include/disas/disas.h
@@ -1,13 +1,15 @@
 #ifndef QEMU_DISAS_H
 #define QEMU_DISAS_H
 
+#include "monitor/hmp.h"
+
 /* Disassemble this for me please... (debugging). */
 #ifdef CONFIG_TCG
 void disas(FILE *out, const void *code, size_t size);
 void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db);
 #endif
 
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical);
 
 #ifdef CONFIG_PLUGIN
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 3fd17048b319..f10bf83df86d 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *chardev_id,
 
 MonitorHMP *monitor_cur_hmp(void);
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
     G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_hmp_printc(MonitorHMP *mon, int ch);
 
 void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
 int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
@@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
 int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
 
 bool hmp_handle_error(MonitorHMP *hmp, Error *err);
-void hmp_help_cmd(Monitor *mon, const char *name);
+void hmp_help_cmd(MonitorHMP *hmp, const char *name);
 strList *hmp_split_at_comma(const char *str);
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
@@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_change(MonitorHMP *hmp, const QDict *qdict);
 #ifdef CONFIG_VNC
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp);
 #endif
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp);
 void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 3c0931796ce2..bdbb2aaa99db 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool has_calc_time_unit,
 
 void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyRateInfo *info = query_dirty_rate_info(TIME_UNIT_SECOND);
 
-    monitor_printf(mon, "Status: %s\n",
-                   DirtyRateStatus_str(info->status));
-    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
-                   info->start_time);
+    monitor_hmp_printf(hmp, "Status: %s\n",
+                       DirtyRateStatus_str(info->status));
+    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
+                       info->start_time);
     if (info->mode == DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
-        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
-                       info->sample_pages);
+        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
+                           info->sample_pages);
     }
-    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
-                   info->calc_time);
-    monitor_printf(mon, "Mode: %s\n",
-                   DirtyRateMeasureMode_str(info->mode));
-    monitor_printf(mon, "Dirty rate: ");
+    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
+                       info->calc_time);
+    monitor_hmp_printf(hmp, "Mode: %s\n",
+                       DirtyRateMeasureMode_str(info->mode));
+    monitor_hmp_printf(hmp, "Dirty rate: ");
     if (info->has_dirty_rate) {
-        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
+        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate);
         if (info->has_vcpu_dirty_rate) {
             DirtyRateVcpuList *rate, *head = info->vcpu_dirty_rate;
             for (rate = head; rate != NULL; rate = rate->next) {
-                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
-                               " (MB/s)\n", rate->value->id,
-                               rate->value->dirty_rate);
+                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
+                                   " (MB/s)\n", rate->value->id,
+                                   rate->value->dirty_rate);
             }
         }
     } else {
-        monitor_printf(mon, "(not ready)\n");
+        monitor_hmp_printf(hmp, "(not ready)\n");
     }
 
     qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
@@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t sec = qdict_get_try_int(qdict, "second", 0);
     int64_t sample_pages = qdict_get_try_int(qdict, "sample_pages_per_GB", -1);
     bool has_sample_pages = (sample_pages != -1);
@@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
     Error *err = NULL;
 
     if (!sec) {
-        monitor_printf(mon, "Incorrect period length specified!\n");
+        monitor_hmp_printf(hmp, "Incorrect period length specified!\n");
         return;
     }
 
     if (dirty_ring && dirty_bitmap) {
-        monitor_printf(mon, "Either dirty ring or dirty bitmap "
-                       "can be specified!\n");
+        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
+                           "can be specified!\n");
         return;
     }
 
@@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Starting dirty rate measurement with period %"PRIi64
-                   " seconds\n", sec);
-    monitor_printf(mon, "[Please use 'info dirty_rate' to check results]\n");
+    monitor_hmp_printf(hmp, "Starting dirty rate measurement with period %"PRIi64
+                       " seconds\n", sec);
+    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check results]\n");
 }
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index a164a59080c5..6fe189471899 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -36,23 +36,23 @@
 #include "options.h"
 #include "migration.h"
 
-static void migration_global_dump(Monitor *mon)
+static void migration_global_dump(MonitorHMP *hmp)
 {
     MigrationState *ms = migrate_get_current();
 
-    monitor_printf(mon, "Globals:\n");
-    monitor_printf(mon, "  store-global-state: %s\n",
-                   ms->store_global_state ? "on" : "off");
-    monitor_printf(mon, "  only-migratable: %s\n",
-                   only_migratable ? "on" : "off");
-    monitor_printf(mon, "  send-configuration: %s\n",
-                   ms->send_configuration ? "on" : "off");
-    monitor_printf(mon, "  send-section-footer: %s\n",
-                   ms->send_section_footer ? "on" : "off");
-    monitor_printf(mon, "  send-switchover-start: %s\n",
-                   ms->send_switchover_start ? "on" : "off");
-    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
-                   ms->clear_bitmap_shift);
+    monitor_hmp_printf(hmp, "Globals:\n");
+    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
+                       ms->store_global_state ? "on" : "off");
+    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
+                       only_migratable ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
+                       ms->send_configuration ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
+                       ms->send_section_footer ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
+                       ms->send_switchover_start ? "on" : "off");
+    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
+                       ms->clear_bitmap_shift);
 }
 
 static const gchar *format_time_str(uint64_t us)
@@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
     return g_strdup_printf("%"PRIu64" %s", us, units[index]);
 }
 
-static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
+static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *info)
 {
     if (info->has_postcopy_blocktime) {
-        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
-                       info->postcopy_blocktime);
+        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\n",
+                           info->postcopy_blocktime);
     }
 
     if (info->has_postcopy_vcpu_blocktime) {
@@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency) {
-        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_latency);
+        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_latency);
     }
 
     if (info->has_postcopy_non_vcpu_latency) {
-        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_non_vcpu_latency);
+        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_non_vcpu_latency);
     }
 
     if (info->has_postcopy_vcpu_latency) {
@@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency_dist) {
         uint64List *item = info->postcopy_latency_dist;
         int count = 0;
 
-        monitor_printf(mon, "Postcopy Latency Distribution:\n");
+        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
 
         while (item) {
             g_autofree const gchar *from = format_time_str(1UL << count);
             g_autofree const gchar *to = format_time_str(1UL << (count + 1));
 
-            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
-                           from, to, item->value);
+            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
+                               from, to, item->value);
             item = item->next;
             count++;
         }
@@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
 
 void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool show_all = qdict_get_try_bool(qdict, "all", false);
     MigrationInfo *info;
 
@@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 
     if (info->blocked_reasons) {
         strList *reasons = info->blocked_reasons;
-        monitor_printf(mon, "Outgoing migration blocked:\n");
+        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
         while (reasons) {
-            monitor_printf(mon, "  %s\n", reasons->value);
+            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
             reasons = reasons->next;
         }
     }
 
     if (info->has_status) {
-        monitor_printf(mon, "Status: \t\t%s",
-                       MigrationStatus_str(info->status));
+        monitor_hmp_printf(hmp, "Status: \t\t%s",
+                           MigrationStatus_str(info->status));
         if ((info->status == MIGRATION_STATUS_FAILED ||
              info->status == MIGRATION_STATUS_POSTCOPY_PAUSED) &&
             info->error_desc) {
-            monitor_printf(mon, " (%s)\n", info->error_desc);
+            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
         } else {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
         if (info->total_time) {
-            monitor_printf(mon, "Time (ms): \t\ttotal=%" PRIu64,
-                           info->total_time);
+            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=%" PRIu64,
+                               info->total_time);
             if (info->has_setup_time) {
-                monitor_printf(mon, ", setup=%" PRIu64,
-                               info->setup_time);
+                monitor_hmp_printf(hmp, ", setup=%" PRIu64,
+                                   info->setup_time);
             }
             if (info->has_expected_downtime) {
-                monitor_printf(mon, ", exp_down=%" PRIu64,
-                               info->expected_downtime);
+                monitor_hmp_printf(hmp, ", exp_down=%" PRIu64,
+                                   info->expected_downtime);
             }
             if (info->has_downtime) {
-                monitor_printf(mon, ", down=%" PRIu64,
-                               info->downtime);
+                monitor_hmp_printf(hmp, ", down=%" PRIu64,
+                                   info->downtime);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
     if (info->has_remaining) {
         g_autofree char *remaining = size_to_str(info->remaining);
-        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
+        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
     }
 
     if (info->has_socket_address) {
         SocketAddressList *addr;
 
-        monitor_printf(mon, "Sockets: [\n");
+        monitor_hmp_printf(hmp, "Sockets: [\n");
 
         for (addr = info->socket_address; addr; addr = addr->next) {
             char *s = socket_uri(addr->value);
-            monitor_printf(mon, "\t%s\n", s);
+            monitor_hmp_printf(hmp, "\t%s\n", s);
             g_free(s);
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->ram) {
@@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
         g_autofree char *str_multifd = size_to_str(info->ram->multifd_bytes);
         g_autofree char *str_postcopy = size_to_str(info->ram->postcopy_bytes);
 
-        monitor_printf(mon, "RAM info:\n");
-        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
-                       info->ram->mbps);
-        monitor_printf(mon, "  Sizes: \t\tpagesize=%s, total=%s\n",
-                       str_psize, str_total);
-        monitor_printf(mon, "  Transfers: \t\ttransferred=%s, remain=%s\n",
-                       str_transferred, str_remaining);
-        monitor_printf(mon, "    Channels: \t\tprecopy=%s, "
-                       "multifd=%s, postcopy=%s",
-                       str_precopy, str_multifd, str_postcopy);
+        monitor_hmp_printf(hmp, "RAM info:\n");
+        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
+                           info->ram->mbps);
+        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=%s, total=%s\n",
+                           str_psize, str_total);
+        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=%s, remain=%s\n",
+                           str_transferred, str_remaining);
+        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=%s, "
+                           "multifd=%s, postcopy=%s",
+                           str_precopy, str_multifd, str_postcopy);
 
         if (info->vfio) {
             g_autofree char *str_vfio = size_to_str(info->vfio->transferred);
 
-            monitor_printf(mon, ", vfio=%s", str_vfio);
+            monitor_hmp_printf(hmp, ", vfio=%s", str_vfio);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "    Page Types: \tnormal=%" PRIu64
-                       ", zero=%" PRIu64 "\n",
-                       info->ram->normal, info->ram->duplicate);
-        monitor_printf(mon, "  Page Rates (pps): \ttransfer=%" PRIu64,
-                       info->ram->pages_per_second);
+        monitor_hmp_printf(hmp, "    Page Types: \tnormal=%" PRIu64
+                           ", zero=%" PRIu64 "\n",
+                           info->ram->normal, info->ram->duplicate);
+        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=%" PRIu64,
+                           info->ram->pages_per_second);
         if (info->ram->dirty_pages_rate) {
-            monitor_printf(mon, ", dirty=%" PRIu64,
-                           info->ram->dirty_pages_rate);
+            monitor_hmp_printf(hmp, ", dirty=%" PRIu64,
+                               info->ram->dirty_pages_rate);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "  Others: \t\tdirty_syncs=%" PRIu64,
-                       info->ram->dirty_sync_count);
+        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=%" PRIu64,
+                           info->ram->dirty_sync_count);
         if (info->ram->postcopy_requests) {
-            monitor_printf(mon, ", postcopy_req=%" PRIu64,
-                           info->ram->postcopy_requests);
+            monitor_hmp_printf(hmp, ", postcopy_req=%" PRIu64,
+                               info->ram->postcopy_requests);
         }
         if (info->ram->downtime_bytes) {
-            monitor_printf(mon, ", downtime_bytes=%" PRIu64,
-                           info->ram->downtime_bytes);
+            monitor_hmp_printf(hmp, ", downtime_bytes=%" PRIu64,
+                               info->ram->downtime_bytes);
         }
         if (info->ram->dirty_sync_missed_zero_copy) {
-            monitor_printf(mon, ", zerocopy_fallbacks=%" PRIu64,
-                           info->ram->dirty_sync_missed_zero_copy);
+            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=%" PRIu64,
+                               info->ram->dirty_sync_missed_zero_copy);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (!show_all) {
         goto out;
     }
 
-    migration_global_dump(mon);
+    migration_global_dump(hmp);
 
     if (info->xbzrle_cache) {
-        monitor_printf(mon, "XBZRLE: size=%" PRIu64
-                       ", transferred=%" PRIu64
-                       ", pages=%" PRIu64
-                       ", miss=%" PRIu64 "\n"
-                       "  miss_rate=%0.2f"
-                       ", encode_rate=%0.2f"
-                       ", overflow=%" PRIu64 "\n",
-                       info->xbzrle_cache->cache_size,
-                       info->xbzrle_cache->bytes,
-                       info->xbzrle_cache->pages,
-                       info->xbzrle_cache->cache_miss,
-                       info->xbzrle_cache->cache_miss_rate,
-                       info->xbzrle_cache->encoding_rate,
-                       info->xbzrle_cache->overflow);
+        monitor_hmp_printf(hmp, "XBZRLE: size=%" PRIu64
+                           ", transferred=%" PRIu64
+                           ", pages=%" PRIu64
+                           ", miss=%" PRIu64 "\n"
+                           "  miss_rate=%0.2f"
+                           ", encode_rate=%0.2f"
+                           ", overflow=%" PRIu64 "\n",
+                           info->xbzrle_cache->cache_size,
+                           info->xbzrle_cache->bytes,
+                           info->xbzrle_cache->pages,
+                           info->xbzrle_cache->cache_miss,
+                           info->xbzrle_cache->cache_miss_rate,
+                           info->xbzrle_cache->encoding_rate,
+                           info->xbzrle_cache->overflow);
     }
 
     if (info->has_cpu_throttle_percentage) {
-        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
-                       info->cpu_throttle_percentage);
+        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
+                           info->cpu_throttle_percentage);
     }
 
     if (info->has_dirty_limit_throttle_time_per_round) {
-        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n",
-                       info->dirty_limit_throttle_time_per_round);
+        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 "\n",
+                           info->dirty_limit_throttle_time_per_round);
     }
 
     if (info->has_dirty_limit_ring_full_time) {
-        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
-                       info->dirty_limit_ring_full_time);
+        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
+                           info->dirty_limit_ring_full_time);
     }
 
-    migration_dump_blocktime(mon, info);
+    migration_dump_blocktime(hmp, info);
 out:
     qapi_free_MigrationInfo(info);
 }
 
 void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationCapabilityStatusList *caps, *cap;
 
     caps = qmp_query_migrate_capabilities(NULL);
 
     if (caps) {
         for (cap = caps; cap; cap = cap->next) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationCapability_str(cap->value->capability),
-                           cap->value->state ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationCapability_str(cap->value->capability),
+                               cap->value->state ? "on" : "off");
         }
     }
 
     qapi_free_MigrationCapabilityStatusList(caps);
 }
 
-static void monitor_print_cpr_exec_command(Monitor *mon, strList *args)
+static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *args)
 {
-    monitor_printf(mon, "%s:",
+    monitor_hmp_printf(hmp, "%s:",
         MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
 
     while (args) {
-        monitor_printf(mon, " %s", args->value);
+        monitor_hmp_printf(hmp, " %s", args->value);
         args = args->next;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationParameters *params;
     MigrationState *s = migrate_get_current();
 
     params = qmp_query_migrate_parameters(NULL);
 
     if (params) {
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIAL),
             params->announce_initial);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
             params->announce_max);
-        monitor_printf(mon, "%s: %" PRIu64 "\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS),
             params->announce_rounds);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
             params->announce_step);
         assert(params->has_throttle_trigger_threshold);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD),
             params->throttle_trigger_threshold);
         assert(params->has_cpu_throttle_initial);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
             params->cpu_throttle_initial);
         assert(params->has_cpu_throttle_increment);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
             params->cpu_throttle_increment);
         assert(params->has_cpu_throttle_tailslow);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW),
             params->cpu_throttle_tailslow ? "on" : "off");
         assert(params->has_max_cpu_throttle);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTLE),
             params->max_cpu_throttle);
         assert(params->tls_creds);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
                        params->tls_creds->u.s);
         assert(params->tls_hostname);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
                        params->tls_hostname->u.s);
         assert(params->tls_authz);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
                        params->tls_authz->u.s);
         assert(params->has_max_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
             params->max_bandwidth);
         assert(params->has_avail_switchover_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVER_BANDWIDTH),
             params->avail_switchover_bandwidth);
         assert(params->has_max_postcopy_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH),
             params->max_postcopy_bandwidth);
         assert(params->has_downtime_limit);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
             params->downtime_limit);
         assert(params->has_x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u ms\n",
+        monitor_hmp_printf(hmp, "%s: %u ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
             params->x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
             params->multifd_channels);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRESSION),
             MultiFDCompression_str(params->multifd_compression));
         assert(params->has_zero_page_detection);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETECTION),
             qapi_enum_lookup(&ZeroPageDetection_lookup,
                 params->zero_page_detection));
-        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
             MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
             params->xbzrle_cache_size);
 
         if (s->has_block_bitmap_mapping) {
             const BitmapMigrationNodeAliasList *bmnal;
 
-            monitor_printf(mon, "%s:\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
+            monitor_hmp_printf(hmp, "%s:\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
 
             for (bmnal = params->block_bitmap_mapping;
                  bmnal;
@@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
                 const BitmapMigrationNodeAlias *bmna = bmnal->value;
                 const BitmapMigrationBitmapAliasList *bmbal;
 
-                monitor_printf(mon, "  '%s' -> '%s'\n",
-                               bmna->node_name, bmna->alias);
+                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
+                                   bmna->node_name, bmna->alias);
 
                 for (bmbal = bmna->bitmaps; bmbal; bmbal = bmbal->next) {
                     const BitmapMigrationBitmapAlias *bmba = bmbal->value;
 
-                    monitor_printf(mon, "    '%s' -> '%s'\n",
-                                   bmba->name, bmba->alias);
+                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
+                                       bmba->name, bmba->alias);
                 }
             }
         }
 
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
         MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD),
         params->x_vcpu_dirty_limit_period);
 
-        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT),
             params->vcpu_dirty_limit);
 
         assert(params->has_mode);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MODE),
             qapi_enum_lookup(&MigMode_lookup, params->mode));
 
         if (params->has_direct_io) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_DIRECT_IO),
-                           params->direct_io ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_DIRECT_IO),
+                               params->direct_io ? "on" : "off");
         }
 
         if (params->has_x_rdma_chunk_size) {
-            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
-                           params->x_rdma_chunk_size);
+            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
+                               params->x_rdma_chunk_size);
         }
 
         assert(params->has_cpr_exec_command);
-        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
+        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
     }
 
     qapi_free_MigrationParameters(params);
@@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
         HMPMigrationStatus *status;
 
         if (!hmp->use_readline) {
-            monitor_printf(mon, "terminal does not allow synchronous "
-                           "migration, continuing detached\n");
+            monitor_hmp_printf(hmp, "terminal does not allow synchronous "
+                               "migration, continuing detached\n");
             return;
         }
         monitor_suspend(mon);
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 89cc19c2431d..1834e3c1f697 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     NameInfo *info;
 
     info = qmp_query_name(NULL);
     if (info->name) {
-        monitor_printf(mon, "%s\n", info->name);
+        monitor_hmp_printf(hmp, "%s\n", info->name);
     }
     qapi_free_NameInfo(info);
 }
 
 void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VersionInfo *info;
 
     info = qmp_query_version(NULL);
 
-    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
-                   info->qemu->major, info->qemu->minor, info->qemu->micro,
-                   info->package);
+    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+                       info->qemu->major, info->qemu->minor, info->qemu->micro,
+                       info->package);
 
     qapi_free_VersionInfo(info);
 }
@@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
 
     if (op == NULL) {
         bool on = qsp_is_enabled();
 
-        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off");
+        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "off");
         return;
     }
     if (!strcmp(op, "on")) {
@@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index;
 
     /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands that
             use it are converted to the QAPI */
     cpu_index = qdict_get_int(qdict, "index");
     if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
-        monitor_printf(mon, "invalid CPU index\n");
+        monitor_hmp_printf(hmp, "invalid CPU index\n");
     }
 }
 
@@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *device = qdict_get_str(qdict, "device");
     const char *target = qdict_get_str(qdict, "target");
     const char *arg = qdict_get_try_str(qdict, "arg");
@@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
     if (strcmp(device, "vnc") == 0) {
-        hmp_change_vnc(mon, device, target, arg, read_only, force, &err);
+        hmp_change_vnc(hmp, device, target, arg, read_only, force, &err);
     } else
 #endif
     {
-        hmp_change_medium(mon, device, target, arg, read_only, force, &err);
+        hmp_change_medium(hmp, device, target, arg, read_only, force, &err);
     }
 
     hmp_handle_error(hmp, err);
@@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
     IOThreadInfoList *info;
     IOThreadInfo *value;
 
     for (info = info_list; info; info = info->next) {
         value = info->value;
-        monitor_printf(mon, "%s:\n", value->id);
-        monitor_printf(mon, "  thread_id=%" PRId64 "\n", value->thread_id);
-        monitor_printf(mon, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
-        monitor_printf(mon, "  poll-grow=%" PRId64 "\n", value->poll_grow);
-        monitor_printf(mon, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
-        monitor_printf(mon, "  poll-weight=%" PRId64 "\n", value->poll_weight);
-        monitor_printf(mon, "  aio-max-batch=%" PRId64 "\n",
-                       value->aio_max_batch);
+        monitor_hmp_printf(hmp, "%s:\n", value->id);
+        monitor_hmp_printf(hmp, "  thread_id=%" PRId64 "\n", value->thread_id);
+        monitor_hmp_printf(hmp, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
+        monitor_hmp_printf(hmp, "  poll-grow=%" PRId64 "\n", value->poll_grow);
+        monitor_hmp_printf(hmp, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
+        monitor_hmp_printf(hmp, "  poll-weight=%" PRId64 "\n", value->poll_weight);
+        monitor_hmp_printf(hmp, "  aio-max-batch=%" PRId64 "\n",
+                           value->aio_max_batch);
     }
 
     qapi_free_IOThreadInfoList(info_list);
@@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
+    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
 }
 
 void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /*
      * Send an ANSI escape sequence:
      * "\x1b[H" - move cursor to top-left
      * "\x1b[2J" - clear visible screen
      * "\x1b[3J" - clear scrollback
      */
-    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
+    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
 }
 
 void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, "info");
+    hmp_help_cmd(hmp, "info");
 }
 
 void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
@@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     const char *str;
 
@@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
         if (!str) {
             break;
         }
-        monitor_printf(mon, "%d: '%s'\n", i, str);
+        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
         i++;
     }
 }
@@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int mask;
     const char *items = qdict_get_str(qdict, "items");
     Error *err = NULL;
@@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
     } else {
         mask = qemu_str_to_log_mask(items);
         if (!mask) {
-            hmp_help_cmd(mon, "log");
+            hmp_help_cmd(hmp, "log");
             return;
         }
     }
@@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *device = qdict_get_try_str(qdict, "device");
 
@@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
     if (!gdbserver_start(device, &err)) {
         error_report_err(err);
     } else if (strcmp(device, "none") == 0) {
-        monitor_printf(mon, "Disabled gdbserver\n");
+        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
     } else {
-        monitor_printf(mon, "Waiting for gdb connection on device '%s'\n",
-                       device);
+        monitor_hmp_printf(hmp, "Waiting for gdb connection on device '%s'\n",
+                           device);
     }
 }
 
 void hmp_print(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int format = qdict_get_int(qdict, "format");
     hwaddr val = qdict_get_int(qdict, "val");
 
     switch(format) {
     case 'o':
-        monitor_printf(mon, "%#" HWADDR_PRIo, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
         break;
     case 'x':
-        monitor_printf(mon, "%#" HWADDR_PRIx, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
         break;
     case 'u':
-        monitor_printf(mon, "%" HWADDR_PRIu, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
         break;
     default:
     case 'd':
-        monitor_printf(mon, "%" HWADDR_PRId, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
         break;
     case 'c':
-        monitor_printc(mon, val);
+        monitor_hmp_printc(hmp, val);
         break;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t addr;
     uint16_t sum;
     uint32_t start = qdict_get_int(qdict, "start");
@@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
         sum = (sum >> 1) | (sum << 15);
         sum += val;
     }
-    monitor_printf(mon, "%05d\n", sum);
+    monitor_hmp_printf(hmp, "%05d\n", sum);
 }
 
 void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int size = qdict_get_int(qdict, "size");
     int addr = qdict_get_int(qdict, "addr");
     int has_index = qdict_haskey(qdict, "index");
@@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
         suffix = 'l';
         break;
     }
-    monitor_printf(mon, "port%c[0x%04x] = 0x%0*x\n",
-                   suffix, addr, size * 2, val);
+    monitor_hmp_printf(hmp, "port%c[0x%04x] = 0x%0*x\n",
+                       suffix, addr, size * 2, val);
 }
 
 void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
@@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *local_err = NULL;
     const char *bootdevice = qdict_get_str(qdict, "bootdevice");
 
@@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "boot device list now set to %s\n", bootdevice);
+        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bootdevice);
     }
 }
 
@@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
+    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
 }
 #endif
 
@@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
 
 void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
     int vcpu = qdict_get_try_int(qdict, "vcpu", -1);
     CPUState *cs;
 
     if (all_cpus) {
         CPU_FOREACH(cs) {
-            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
             cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
         }
     } else {
@@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 
         if (!cs) {
             if (vcpu >= 0) {
-                monitor_printf(mon, "CPU#%d not available\n", vcpu);
+                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu);
             } else {
-                monitor_printf(mon, "No CPU available\n");
+                monitor_hmp_printf(hmp, "No CPU available\n");
             }
             return;
         }
 
-        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
         cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
     }
 }
@@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                         uint64_t addr, bool is_physical)
 {
-    Monitor *mon = MONITOR(hmp);
     int l, line_size, i, max_digits, len;
     uint8_t buf[16];
     uint64_t v;
@@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     const bool big_endian = target_big_endian();
 
     if (!cs && (format == 'i' || !is_physical)) {
-        monitor_printf(mon, "Can not dump without CPU\n");
+        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
         return;
     }
 
     if (format == 'i') {
-        monitor_disas(mon, cs, addr, count, is_physical);
+        monitor_disas(hmp, cs, addr, count, is_physical);
         return;
     }
 
@@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     }
 
     while (len > 0) {
-        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
+        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
         l = len;
         if (l > line_size) {
             l = line_size;
@@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
             MemTxResult r = address_space_read(as, addr,
                                                MEMTXATTRS_UNSPECIFIED, buf, l);
             if (r != MEMTX_OK) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         } else {
             if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         }
@@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                 v = (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
                 break;
             }
-            monitor_printf(mon, " ");
+            monitor_hmp_printf(hmp, " ");
             switch (format) {
             case 'o':
-                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
+                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
                 break;
             case 'x':
-                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
+                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v);
                 break;
             case 'u':
-                monitor_printf(mon, "%*" PRIu64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
                 break;
             case 'd':
-                monitor_printf(mon, "%*" PRId64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
                 break;
             case 'c':
-                monitor_printc(mon, v);
+                monitor_hmp_printc(hmp, v);
                 break;
             }
             i += wsize;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         addr += l;
         len -= l;
     }
@@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
-                   " (%s) is %p\n",
-                   addr, mr->name, ptr);
+    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
+                       " (%s) is %p\n",
+                       addr, mr->name, ptr);
 
     memory_region_unref(mr);
 }
 
 void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     vaddr addr = qdict_get_int(qdict, "addr");
     CPUState *cs = monitor_hmp_get_cpu(hmp);
     TranslateForDebugResult tres;
 
     if (!cs) {
-        monitor_printf(mon, "No cpu\n");
+        monitor_hmp_printf(hmp, "No cpu\n");
         return;
     }
 
     if (!cpu_translate_for_debug(cs, addr, &tres)) {
-        monitor_printf(mon, "Unmapped\n");
+        monitor_hmp_printf(hmp, "Unmapped\n");
     } else {
-        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
+        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
     }
 }
 
@@ -806,7 +786,6 @@ out:
 
 void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRIx
-                       " (%s) is 0x%" PRIx64 "\n",
-                       addr, mr->name, (uint64_t) physaddr);
+        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR_PRIx
+                           " (%s) is 0x%" PRIx64 "\n",
+                           addr, mr->name, (uint64_t) physaddr);
     }
 
     memory_region_unref(mr);
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 2484a2310dff..e5f8b9c576e0 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, bool val, Error **errp)
     hmp->use_readline = val;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
 static void monitor_hmp_accept_input(Monitor *mon);
 static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
 static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp);
@@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, const void *data)
                                    monitor_hmp_get_readline,
                                    monitor_hmp_set_readline);
 
-    moncls->vprintf = monitor_hmp_vprintf;
     moncls->accept_input = monitor_hmp_accept_input;
 
     ucc->complete = monitor_hmp_complete;
@@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
     hmp->use_readline = true;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-{
-    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
-    return monitor_puts(mon, buf);
-}
-
 static void monitor_hmp_accept_input(Monitor *mon)
 {
     qemu_mutex_lock(&mon->mon_lock);
@@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
         /* prompt is printed on return from the command handler */
         return 0;
     } else {
-        monitor_printf(&hmp->parent_obj,
-                       "terminal does not support password prompting\n");
+        monitor_hmp_printf(hmp, "terminal does not support password prompting\n");
         return -ENOTTY;
     }
 }
@@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
     return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
 }
 
-static void help_cmd_dump_one(Monitor *mon,
+static void help_cmd_dump_one(MonitorHMP *mon,
                               const HMPCommand *cmd,
                               char **prefix_args,
                               int prefix_args_nb)
@@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
     }
 
     for (i = 0; i < prefix_args_nb; i++) {
-        monitor_printf(mon, "%s ", prefix_args[i]);
+        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
     }
-    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
+    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
 }
 
 /* @args[@arg_index] is the valid command need to find in @cmds */
-static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
+static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
                           char **args, int nb_args, int arg_index)
 {
     const HMPCommand *cmd;
@@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
     }
 
     /* Command not found */
-    monitor_printf(mon, "unknown command: '");
+    monitor_hmp_printf(mon, "unknown command: '");
     for (i = 0; i <= arg_index; i++) {
-        monitor_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
+        monitor_hmp_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
     }
 }
 
-void hmp_help_cmd(Monitor *mon, const char *name)
+void hmp_help_cmd(MonitorHMP *mon, const char *name)
 {
     char *args[MAX_ARGS];
     int nb_args = 0;
@@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
         /* special case for log, directly dump and return */
         if (!strcmp(name, "log")) {
             const QEMULogItem *item;
-            monitor_printf(mon, "Log items (comma separated):\n");
-            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs");
+            monitor_hmp_printf(mon, "Log items (comma separated):\n");
+            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all logs");
             for (item = qemu_log_items; item->mask != 0; item++) {
-                monitor_printf(mon, "%-15s %s\n", item->name, item->help);
+                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item->help);
             }
 #ifdef CONFIG_TRACE_LOG
-            monitor_printf(mon, "trace:PATTERN   enable trace events\n");
-            monitor_printf(mon, "\nUse \"log trace:help\" to get a list of "
-                           "trace events.\n\n");
+            monitor_hmp_printf(mon, "trace:PATTERN   enable trace events\n");
+            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a list of "
+                               "trace events.\n\n");
 #endif
             return;
         }
@@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
 static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char *name);
 
 static G_NORETURN G_GNUC_PRINTF(2, 3)
-void expr_error(Monitor *mon, const char *fmt, ...)
+void expr_error(MonitorHMP *mon, const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(mon, fmt, ap);
-    monitor_printf(mon, "\n");
+    monitor_hmp_vprintf(mon, fmt, ap);
+    monitor_hmp_printf(mon, "\n");
     va_end(ap);
     siglongjmp(expr_env, 1);
 }
@@ -475,9 +465,9 @@ static void next(void)
     }
 }
 
-static int64_t expr_sum(Monitor *mon);
+static int64_t expr_sum(MonitorHMP *mon);
 
-static int64_t expr_unary(Monitor *mon)
+static int64_t expr_unary(MonitorHMP *mon)
 {
     int64_t n;
     char *p;
@@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
                 pch++;
             }
             *q = 0;
-            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
-                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
+            if (!gdb_get_register(mon, &reg, buf)
+                && get_monitor_def(mon, &reg, buf) < 0) {
                 expr_error(mon, "unknown register");
             }
             n = reg;
@@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
     return n;
 }
 
-static int64_t expr_prod(Monitor *mon)
+static int64_t expr_prod(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
     return val;
 }
 
-static int64_t expr_logic(Monitor *mon)
+static int64_t expr_logic(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
     return val;
 }
 
-static int64_t expr_sum(Monitor *mon)
+static int64_t expr_sum(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
     return val;
 }
 
-static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
+static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
 {
     pch = *pp;
     if (sigsetjmp(expr_env, 0)) {
@@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
     return 0;
 }
 
-static int get_double(Monitor *mon, double *pval, const char **pp)
+static int get_double(MonitorHMP *mon, double *pval, const char **pp)
 {
     const char *p = *pp;
     char *tailp;
@@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval, const char **pp)
 
     d = strtod(p, &tailp);
     if (tailp == p) {
-        monitor_printf(mon, "Number expected\n");
+        monitor_hmp_printf(mon, "Number expected\n");
         return -1;
     }
     if (d != d || d - d != 0) {
         /* NaN or infinity */
-        monitor_printf(mon, "Bad number\n");
+        monitor_hmp_printf(mon, "Bad number\n");
         return -1;
     }
     *pval = d;
@@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
                                                const char **cmdp,
                                                HMPCommand *table)
 {
-    Monitor *mon = &hmp->parent_obj;
     const char *p;
     const HMPCommand *cmd;
     char cmdname[256];
@@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
 
     cmd = search_dispatch_table(table, cmdname);
     if (!cmd) {
-        monitor_printf(mon, "unknown command: '%.*s'\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
     if (!cmd_available(cmd)) {
-        monitor_printf(mon, "Command '%.*s' not available "
-                            "until machine initialization has completed.\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "Command '%.*s' not available "
+                           "until machine initialization has completed.\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
 
@@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
  * Else, insert command arguments into a QDict, and return it.
  * Note: On success, caller has to free the QDict structure.
  */
-static QDict *monitor_parse_arguments(Monitor *mon,
+static QDict *monitor_parse_arguments(MonitorHMP *mon,
                                       const char **endp,
                                       const HMPCommand *cmd)
 {
@@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 if (ret < 0) {
                     switch (c) {
                     case 'F':
-                        monitor_printf(mon, "%s: filename expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: filename expected\n",
+                                           cmd->name);
                         break;
                     case 'B':
-                        monitor_printf(mon, "%s: block device name expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: block device name expected\n",
+                                           cmd->name);
                         break;
                     default:
-                        monitor_printf(mon, "%s: string expected\n", cmd->name);
+                        monitor_hmp_printf(mon, "%s: string expected\n", cmd->name);
                         break;
                     }
                     goto fail;
@@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 next:
                     if (*p != '\0' && !qemu_isspace(*p)) {
-                        monitor_printf(mon, "invalid char in format: '%c'\n",
-                                       *p);
+                        monitor_hmp_printf(mon, "invalid char in format: '%c'\n",
+                                           *p);
                         goto fail;
                     }
                     if (format < 0) {
@@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 /* Check if 'i' is greater than 32-bit */
                 if ((c == 'i') && ((val >> 32) & 0xffffffff)) {
-                    monitor_printf(mon, "\'%s\' has failed: ", cmd->name);
-                    monitor_printf(mon, "integer is for 32-bit values\n");
+                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd->name);
+                    monitor_hmp_printf(mon, "integer is for 32-bit values\n");
                     goto fail;
                 } else if (c == 'M') {
                     if (val < 0) {
-                        monitor_printf(mon, "enter a positive value\n");
+                        monitor_hmp_printf(mon, "enter a positive value\n");
                         goto fail;
                     }
                     val *= MiB;
@@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 ret = qemu_strtosz_MiB(p, &end, &val);
                 if (ret < 0 || val > INT64_MAX) {
-                    monitor_printf(mon, "invalid size\n");
+                    monitor_hmp_printf(mon, "invalid size\n");
                     goto fail;
                 }
                 qdict_put_int(qdict, key, val);
@@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 }
                 if (*p && !qemu_isspace(*p)) {
-                    monitor_printf(mon, "Unknown unit suffix\n");
+                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
                     goto fail;
                 }
                 qdict_put(qdict, key, qnum_from_double(val));
@@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 } else if (p - beg == 3 && !memcmp(beg, "off", p - beg)) {
                     val = false;
                 } else {
-                    monitor_printf(mon, "Expected 'on' or 'off'\n");
+                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n");
                     goto fail;
                 }
                 qdict_put_bool(qdict, key, val);
@@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     p++;
                     if (c != *p) {
                         if (!is_valid_option(p, typestr)) {
-                            monitor_printf(mon, "%s: unsupported option -%c\n",
-                                           cmd->name, *p);
+                            monitor_hmp_printf(mon, "%s: unsupported option -%c\n",
+                                               cmd->name, *p);
                             goto fail;
                         } else {
                             skip_key = 1;
@@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                         }
                         ret = get_str(buf, sizeof(buf), &p);
                         if (ret < 0) {
-                            monitor_printf(mon, "%s: value expected for -%c\n",
-                                           cmd->name, *tmp);
+                            monitor_hmp_printf(mon, "%s: value expected for -%c\n",
+                                               cmd->name, *tmp);
                             goto fail;
                         }
                         qdict_put_str(qdict, key, buf);
@@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 len = strlen(p);
                 if (len <= 0) {
-                    monitor_printf(mon, "%s: string expected\n",
-                                   cmd->name);
+                    monitor_hmp_printf(mon, "%s: string expected\n",
+                                       cmd->name);
                     goto fail;
                 }
                 qdict_put_str(qdict, key, p);
@@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
             break;
         default:
         bad_type:
-            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
+            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
             goto fail;
         }
         g_free(key);
@@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
         p++;
     }
     if (*p != '\0') {
-        monitor_printf(mon, "%s: extraneous characters at the end of line\n",
-                       cmd->name);
+        monitor_hmp_printf(mon, "%s: extraneous characters at the end of line\n",
+                           cmd->name);
         goto fail;
     }
 
@@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const char *cmdline)
 
     if (!cmd->cmd && !cmd->cmd_info_hrt) {
         /* FIXME: is it useful to try autoload modules here ??? */
-        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not available.\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
-    qdict = monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd);
+    qdict = monitor_parse_arguments(hmp, &cmdline, cmd);
     if (!qdict) {
         while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
             cmdline--;
         }
-        monitor_printf(&hmp->parent_obj,
-                       "Try \"help %.*s\" for more information\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp,
+                           "Try \"help %.*s\" for more information\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
@@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint8_t *buf, int size)
         }
     } else {
         if (size == 0 || buf[size - 1] != 0) {
-            monitor_printf(&hmp->parent_obj, "corrupted command\n");
+            monitor_hmp_printf(hmp, "corrupted command\n");
         } else {
             handle_hmp_command(hmp, (char *)buf);
         }
@@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEvent event)
         break;
 
     case CHR_EVENT_OPENED:
-        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
-                       "information\n", QEMU_VERSION);
+        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for more "
+                           "information\n", QEMU_VERSION);
         qemu_mutex_lock(&mon->mon_lock);
         hmp->reset_seen = 1;
         if (!mon->mux_out && hmp->use_readline) {
@@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_printf(void *opaque,
     MonitorHMP *hmp = opaque;
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(&hmp->parent_obj, fmt, ap);
+    monitor_hmp_vprintf(hmp, fmt, ap);
     va_end(ap);
 }
 
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index afdda1386080..c198c12eaa00 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -108,12 +108,6 @@ typedef struct HMPCommand {
 struct MonitorClass {
     ObjectClass parent_class;
 
-    /*
-     * If non-NULL, the monitor is able to print messages
-     * for attention of the client user
-     */
-    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
-        G_GNUC_PRINTF(2, 0);
     /*
      * If non-NULL, the monitor is able to send event
      * notifications back to the client
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 8528af6f79b8..da76e6e4ac19 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
     return monitor_puts_locked(mon, str);
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
-    MonitorClass *moncls;
+    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
 
     if (!mon) {
         return -1;
     }
 
-    moncls = MONITOR_GET_CLASS(mon);
-    if (!moncls->vprintf) {
-        return -1;
-    }
-
-    return moncls->vprintf(mon, fmt, ap);
+    return monitor_puts(MONITOR(mon), buf);
 }
 
-int monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
 {
     int ret;
 
     va_list ap;
     va_start(ap, fmt);
-    ret = monitor_vprintf(mon, fmt, ap);
+    ret = monitor_hmp_vprintf(mon, fmt, ap);
     va_end(ap);
     return ret;
 }
 
-void monitor_printc(Monitor *mon, int c)
+void monitor_hmp_printc(MonitorHMP *mon, int c)
 {
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
     switch(c) {
     case '\'':
-        monitor_printf(mon, "\\'");
+        monitor_hmp_printf(mon, "\\'");
         break;
     case '\\':
-        monitor_printf(mon, "\\\\");
+        monitor_hmp_printf(mon, "\\\\");
         break;
     case '\n':
-        monitor_printf(mon, "\\n");
+        monitor_hmp_printf(mon, "\\n");
         break;
     case '\r':
-        monitor_printf(mon, "\\r");
+        monitor_hmp_printf(mon, "\\r");
         break;
     default:
         if (c >= 32 && c <= 126) {
-            monitor_printf(mon, "%c", c);
+            monitor_hmp_printf(mon, "%c", c);
         } else {
-            monitor_printf(mon, "\\x%02x", c);
+            monitor_hmp_printf(mon, "\\x%02x", c);
         }
         break;
     }
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
 }
 
 static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
index 5b1c678f5d89..0d718d78aef9 100644
--- a/net/net-hmp-cmds.c
+++ b/net/net-hmp-cmds.c
@@ -28,26 +28,25 @@
 #include "qemu/help_option.h"
 #include "qemu/option.h"
 
-static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
+static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *ci)
 {
     NetFilterInfoList *f;
 
-    monitor_printf(mon, "%s: index=%" PRIu32 ",type=%s,%s\n",
-                   ci->name, ci->queue_index,
-                   NetClientDriver_str(ci->type), ci->info_str);
+    monitor_hmp_printf(hmp, "%s: index=%" PRIu32 ",type=%s,%s\n",
+                       ci->name, ci->queue_index,
+                       NetClientDriver_str(ci->type), ci->info_str);
     if (ci->filters) {
-        monitor_printf(mon, "filters:\n");
+        monitor_hmp_printf(hmp, "filters:\n");
         for (f = ci->filters; f; f = f->next) {
-            monitor_printf(mon, "  - %s: type=%s%s%s\n",
-                           f->value->name, f->value->type,
-                           f->value->info[0] ? "," : "", f->value->info);
+            monitor_hmp_printf(hmp, "  - %s: type=%s%s%s\n",
+                               f->value->name, f->value->type,
+                               f->value->info[0] ? "," : "", f->value->info);
         }
     }
 }
 
 void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     g_autoptr(NetworkInfo) info = qmp_x_query_network(&err);
     NetHubInfoList *h;
@@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
     for (h = info->hubs; h; h = h->next) {
         NetHubPortInfoList *p;
 
-        monitor_printf(mon, "hub %d\n", (int)h->value->id);
+        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
         for (p = h->value->ports; p; p = p->next) {
             if (p->value->peer) {
-                monitor_printf(mon, " \\ %s: ", p->value->name);
-                hmp_print_client_info(mon, p->value->peer);
+                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
+                hmp_print_client_info(hmp, p->value->peer);
             } else {
-                monitor_printf(mon, " \\ %s\n", p->value->name);
+                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
             }
         }
     }
@@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
         NetworkClientInfo *ci = entry->value;
 
         if (!ci->peer || ci->type == NET_CLIENT_DRIVER_NIC) {
-            hmp_print_client_info(mon, ci);
+            hmp_print_client_info(hmp, ci);
         } /* else it's a netdev connected to a NIC, printed with the NIC */
         if (ci->peer && ci->type == NET_CLIENT_DRIVER_NIC) {
-            monitor_printf(mon, " \\ ");
-            hmp_print_client_info(mon, ci->peer);
+            monitor_hmp_printf(hmp, " \\ ");
+            hmp_print_client_info(hmp, ci->peer);
         }
     }
 }
diff --git a/net/slirp.c b/net/slirp.c
index d5c190b48b76..6fbefa9ed1d7 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -711,22 +711,22 @@ error:
     return -1;
 }
 
-static SlirpState *slirp_lookup(Monitor *mon, const char *id)
+static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
 {
     if (id) {
         NetClientState *nc = qemu_find_netdev(id);
         if (!nc) {
-            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
+            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", id);
             return NULL;
         }
         if (strcmp(nc->model, "user")) {
-            monitor_printf(mon, "invalid device specified\n");
+            monitor_hmp_printf(hmp, "invalid device specified\n");
             return NULL;
         }
         return DO_UPCAST(SlirpState, nc, nc);
     } else {
         if (QTAILQ_EMPTY(&slirp_stacks)) {
-            monitor_printf(mon, "user mode network stack not in use\n");
+            monitor_hmp_printf(hmp, "user mode network stack not in use\n");
             return NULL;
         }
         return QTAILQ_FIRST(&slirp_stacks);
@@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const char *id)
 
 void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /* TODO: support removing unix fwd */
     struct sockaddr_in host_addr = {
         .sin_family = AF_INET,
@@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         src_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         src_str = arg1;
     }
     if (!s) {
@@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     err = slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr, host_port);
 #endif
 
-    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
-                   err ? "not found" : "removed");
+    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_str,
+                       err ? "not found" : "removed");
     return;
 
  fail_syntax:
-    monitor_printf(mon, "invalid format\n");
+    monitor_hmp_printf(hmp, "invalid format\n");
 }
 
 static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
@@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
 
 void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *redir_str;
     SlirpState *s;
     const char *arg1 = qdict_get_str(qdict, "arg1");
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         redir_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         redir_str = arg1;
     }
     if (s) {
@@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **errp)
 
 void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autoptr(UsernetInfoList) list = NULL;
     UsernetInfoList *entry;
 
     list = qmp_x_query_usernet(&error_abort);
     for (entry = list; entry; entry = entry->next) {
         UsernetInfo *ui = entry->value;
-        monitor_printf(mon, "Hub %d (%s):\n%s",
-                       ui->has_hub_id ? (int)ui->hub_id : -1,
-                       ui->hub_name, ui->info);
+        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
+                           ui->has_hub_id ? (int)ui->hub_id : -1,
+                           ui->hub_name, ui->info);
     }
 }
 
diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
index 2e2eb33371e2..bbf5980332a4 100644
--- a/qom/qom-hmp-cmds.c
+++ b/qom/qom-hmp-cmds.c
@@ -20,13 +20,12 @@
 
 void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(qdict, "path");
     ObjectPropertyInfoList *list;
     Error *err = NULL;
 
     if (path == NULL) {
-        monitor_printf(mon, "/\n");
+        monitor_hmp_printf(hmp, "/\n");
         return;
     }
 
@@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
         while (list != NULL) {
             ObjectPropertyInfo *value = list->value;
 
-            monitor_printf(mon, "%s (%s)\n",
-                           value->name, value->type);
+            monitor_hmp_printf(hmp, "%s (%s)\n",
+                               value->name, value->type);
             list = list->next;
         }
         qapi_free_ObjectPropertyInfoList(start);
@@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     const char *property = qdict_get_str(qdict, "property");
     Error *err = NULL;
@@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 
     if (err == NULL) {
         GString *str = qobject_to_json_pretty(obj, true);
-        monitor_printf(mon, "%s\n", str->str);
+        monitor_hmp_printf(hmp, "%s\n", str->str);
         g_string_free(str, true);
     }
 
@@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
     int indent;
 } QOMCompositionState;
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent);
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent);
 
 static int qom_composition_compare(const void *a, const void *b)
 {
@@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj, void *opaque)
     return 0;
 }
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent)
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent)
 {
     GArray *children = g_array_new(false, false, sizeof(Object *));
     const char *name;
@@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
     } else {
         name = object_get_canonical_path_component(obj);
     }
-    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
-                   object_get_typename(obj));
+    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
+                       object_get_typename(obj));
 
     object_child_foreach(obj, insert_qom_composition_child, children);
     g_array_sort(children, qom_composition_compare);
 
     for (i = 0; i < children->len; i++) {
-        print_qom_composition(mon, g_array_index(children, Object *, i),
+        print_qom_composition(hmp, g_array_index(children, Object *, i),
                               indent + 2);
     }
     g_array_free(children, TRUE);
@@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
 
 void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(dict, "path");
     Object *obj;
     bool ambiguous = false;
@@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
     if (path) {
         obj = object_resolve_path(path, &ambiguous);
         if (!obj) {
-            monitor_printf(mon, "Path '%s' could not be resolved.\n", path);
+            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\n", path);
             return;
         }
         if (ambiguous) {
-            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", path);
+            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\n", path);
             return;
         }
     } else {
         obj = qdev_get_machine();
     }
-    print_qom_composition(mon, obj, 0);
+    print_qom_composition(hmp, obj, 0);
 }
 
 void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index ef69d23ff507..965565715ef2 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -33,11 +33,10 @@ bool replay_running_debug(void)
 
 void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     if (replay_mode == REPLAY_MODE_NONE) {
-        monitor_printf(mon, "Record/replay is not active\n");
+        monitor_hmp_printf(hmp, "Record/replay is not active\n");
     } else {
-        monitor_printf(mon,
+        monitor_hmp_printf(hmp,
             "%s execution '%s': instruction count = %"PRId64"\n",
             replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
             replay_get_filename(), replay_get_current_icount());
diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
index cd1f1deb58bc..3d556c745d61 100644
--- a/stats/stats-hmp-cmds.c
+++ b/stats/stats-hmp-cmds.c
@@ -14,11 +14,11 @@
 #include "qobject/qdict.h"
 #include "qapi/error.h"
 
-static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
+static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue *value)
 {
     const char *unit = NULL;
-    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(value->type),
-                   value->has_unit || value->exponent ? ", " : "");
+    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str(value->type),
+                       value->has_unit || value->exponent ? ", " : "");
 
     if (value->has_unit) {
         if (value->unit == STATS_UNIT_SECONDS) {
@@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
     if (unit && value->base == 10 &&
         value->exponent >= -18 && value->exponent <= 18 &&
         value->exponent % 3 == 0) {
-        monitor_puts(mon, si_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
     } else if (unit && value->base == 2 &&
                value->exponent >= 0 && value->exponent <= 60 &&
                value->exponent % 10 == 0) {
 
-        monitor_puts(mon, iec_binary_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent));
     } else if (value->exponent) {
         /* Use exponential notation and write the unit's English name */
-        monitor_printf(mon, "* %d^%d%s",
-                       value->base, value->exponent,
-                       value->has_unit ? " " : "");
+        monitor_hmp_printf(hmp, "* %d^%d%s",
+                           value->base, value->exponent,
+                           value->has_unit ? " " : "");
         unit = NULL;
     }
 
     if (value->has_unit) {
-        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
+        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->unit));
     }
 
     /* Print bucket size for linear histograms */
     if (value->type == STATS_TYPE_LINEAR_HISTOGRAM && value->has_bucket_size) {
-        monitor_printf(mon, ", bucket size=%d", value->bucket_size);
+        monitor_hmp_printf(hmp, ", bucket size=%d", value->bucket_size);
     }
-    monitor_printf(mon, ")");
+    monitor_hmp_printf(hmp, ")");
 }
 
 static StatsSchemaValueList *find_schema_value_list(
@@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
     return NULL;
 }
 
-static void print_stats_results(Monitor *mon, StatsTarget target,
+static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
                                 bool show_provider,
                                 StatsResult *result,
                                 StatsSchemaList *schema)
@@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
     StatsList *stats_list;
 
     if (!schema_value_list) {
-        monitor_printf(mon, "failed to find schema list for %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
+                           StatsProvider_str(result->provider));
         return;
     }
 
     if (show_provider) {
-        monitor_printf(mon, "provider: %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "provider: %s\n",
+                           StatsProvider_str(result->provider));
     }
 
     for (stats_list = result->stats; stats_list;
@@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
         /* Find schema entry */
         while (!g_str_equal(stats->name, schema_value->name)) {
             if (!schema_value_list->next) {
-                monitor_printf(mon, "failed to find schema entry for %s\n",
-                               stats->name);
+                monitor_hmp_printf(hmp, "failed to find schema entry for %s\n",
+                                   stats->name);
                 return;
             }
             schema_value_list = schema_value_list->next;
             schema_value = schema_value_list->value;
         }
 
-        print_stats_schema_value(mon, schema_value);
+        print_stats_schema_value(hmp, schema_value);
 
         if (stats_value->type == QTYPE_QNUM) {
-            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scalar);
+            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.scalar);
         } else if (stats_value->type == QTYPE_QBOOL) {
-            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "yes" : "no");
+            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ? "yes" : "no");
         } else if (stats_value->type == QTYPE_QLIST) {
             uint64List *list;
             int i;
 
-            monitor_printf(mon, ": ");
+            monitor_hmp_printf(hmp, ": ");
             for (list = stats_value->u.list, i = 1;
                  list;
                  list = list->next, i++) {
-                monitor_printf(mon, "[%d]=%" PRId64 " ", i, list->value);
+                monitor_hmp_printf(hmp, "[%d]=%" PRId64 " ", i, list->value);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 }
@@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target, const char *names,
 
 void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *target_str = qdict_get_str(qdict, "target");
     const char *provider_str = qdict_get_try_str(qdict, "provider");
     const char *names = qdict_get_try_str(qdict, "names");
@@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 
     target = qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &err);
     if (err) {
-        monitor_printf(mon, "invalid stats target %s\n", target_str);
+        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_str);
         goto exit_no_print;
     }
     if (provider_str) {
         provider = qapi_enum_parse(&StatsProvider_lookup, provider_str, -1, &err);
         if (err) {
-            monitor_printf(mon, "invalid stats provider %s\n", provider_str);
+            monitor_hmp_printf(hmp, "invalid stats provider %s\n", provider_str);
             goto exit_no_print;
         }
     }
@@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
         goto exit;
     }
     for (entry = stats; entry; entry = entry->next) {
-        print_stats_results(mon, target, provider_str == NULL, entry->value, schema);
+        print_stats_results(hmp, target, provider_str == NULL, entry->value, schema);
     }
 
 exit:
     if (err) {
-        monitor_printf(mon, "%s\n", error_get_pretty(err));
+        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
     }
 exit_no_print:
     error_free(err);
diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
index 6f2b87d1ad10..c9c1d10c165c 100644
--- a/stubs/hmp-cmd-info_sev.c
+++ b/stubs/hmp-cmd-info_sev.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SEV is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
 }
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index b0c7002bd406..094b80721003 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
 {
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     /*
      * Pretend 'g_test_message' is our monitor console to
diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.c
index 75194add7931..fb9338e9aef6 100644
--- a/system/dirtylimit-hmp-cmds.c
+++ b/system/dirtylimit-hmp-cmds.c
@@ -17,7 +17,6 @@
 
 void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index = qdict_get_try_int(qdict, "cpu_index", -1);
     Error *err = NULL;
 
@@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query "
-                   "dirty limit for virtual CPU]\n");
+    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to query "
+                       "dirty limit for virtual CPU]\n");
 }
 
 void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
@@ -50,13 +49,12 @@ out:
 
 void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyLimitInfoList *info;
     g_autoptr(DirtyLimitInfoList) head = NULL;
     Error *err = NULL;
 
     if (!dirtylimit_in_service()) {
-        monitor_printf(mon, "Dirty page limit not enabled!\n");
+        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
         return;
     }
 
@@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (info = head; info != NULL; info = info->next) {
-        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
+        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
                             " current rate %"PRIi64 " (MB/s)\n",
                             info->value->cpu_index,
                             info->value->limit_rate,
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 5c2de2f53cc9..3860ada2a237 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
     return ret;
 }
 
-#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ## __VA_ARGS__)
+#define qdev_printf(fmt, ...) \
+    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
 
-static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
+static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
                              int indent)
 {
     for (int i = 0, n = dc->props_count_; i < n; ++i) {
@@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int ind
     }
 }
 
-static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
+static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
+    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
     }
     class = object_get_class(OBJECT(dev));
     do {
-        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
+        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
     bus_print_dev(dev->parent_bus, mon, dev, indent);
 }
 
-static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
+static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)
 {
     BusChild *kid;
 
@@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
         qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
                     dev->id ? dev->id : "");
         if (details) {
-            qdev_print(mon, dev, indent + 2);
+            qdev_print(hmp, dev, indent + 2);
         }
         QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
-            qbus_print(mon, child_bus, indent + 2, details);
+            qbus_print(hmp, child_bus, indent + 2, details);
         }
     }
 }
@@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
 
 void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool details = !qdict_get_try_bool(qdict, "brief", false);
 
     if (sysbus_get_default()) {
-        qbus_print(mon, sysbus_get_default(), 0, details);
+        qbus_print(hmp, sysbus_get_default(), 0, details);
     }
 }
 
diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
index 051ee45ee74c..ad70b53f8abf 100644
--- a/system/runstate-hmp-cmds.c
+++ b/system/runstate-hmp-cmds.c
@@ -25,33 +25,31 @@
 
 void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     StatusInfo *info;
 
     info = qmp_query_status(NULL);
 
-    monitor_printf(mon, "VM status: %s",
-                   info->running ? "running" : "paused");
+    monitor_hmp_printf(hmp, "VM status: %s",
+                       info->running ? "running" : "paused");
 
     if (!info->running && info->status != RUN_STATE_PAUSED) {
-        monitor_printf(mon, " (%s)", RunState_str(info->status));
+        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_StatusInfo(info);
 }
 
 void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *option = qdict_get_try_str(qdict, "option");
     AccelState *accel = current_accel();
     bool newval;
 
     if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
-        monitor_printf(mon,
-                       "This accelerator does not support setting one-insn-per-tb\n");
+        monitor_hmp_printf(hmp,
+                           "This accelerator does not support setting one-insn-per-tb\n");
         return;
     }
 
@@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
     } else if (!strcmp(option, "off")) {
         newval = false;
     } else {
-        monitor_printf(mon, "unexpected option %s\n", option);
+        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
         return;
     }
     /* If the property exists then setting it can never fail */
diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
index 094c3f16cf50..35406e24d2c3 100644
--- a/system/tpm-hmp-cmds.c
+++ b/system/tpm-hmp-cmds.c
@@ -13,7 +13,6 @@
 
 void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
 #ifdef CONFIG_TPM
     TPMInfoList *info_list, *info;
     Error *err = NULL;
@@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 
     info_list = qmp_query_tpm(&err);
     if (err) {
-        monitor_printf(mon, "TPM device not supported\n");
+        monitor_hmp_printf(hmp, "TPM device not supported\n");
         error_free(err);
         return;
     }
 
     if (info_list) {
-        monitor_printf(mon, "TPM device:\n");
+        monitor_hmp_printf(hmp, "TPM device:\n");
     }
 
     for (info = info_list; info; info = info->next) {
         TPMInfo *ti = info->value;
-        monitor_printf(mon, " tpm%d: model=%s\n",
-                       c, TpmModel_str(ti->model));
+        monitor_hmp_printf(hmp, " tpm%d: model=%s\n",
+                           c, TpmModel_str(ti->model));
 
-        monitor_printf(mon, "  \\ %s: type=%s",
-                       ti->id, TpmType_str(ti->options->type));
+        monitor_hmp_printf(hmp, "  \\ %s: type=%s",
+                           ti->id, TpmType_str(ti->options->type));
 
         switch (ti->options->type) {
         case TPM_TYPE_PASSTHROUGH:
             tpo = ti->options->u.passthrough.data;
-            monitor_printf(mon, "%s%s%s%s",
-                           tpo->path ? ",path=" : "",
-                           tpo->path ?: "",
-                           tpo->cancel_path ? ",cancel-path=" : "",
-                           tpo->cancel_path ?: "");
+            monitor_hmp_printf(hmp, "%s%s%s%s",
+                               tpo->path ? ",path=" : "",
+                               tpo->path ?: "",
+                               tpo->cancel_path ? ",cancel-path=" : "",
+                               tpo->cancel_path ?: "");
             break;
         case TPM_TYPE_EMULATOR:
             teo = ti->options->u.emulator.data;
-            monitor_printf(mon, ",chardev=%s", teo->chardev);
+            monitor_hmp_printf(hmp, ",chardev=%s", teo->chardev);
             break;
         case TPM_TYPE__MAX:
             break;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         c++;
     }
     qapi_free_TPMInfoList(info_list);
 #else
-    monitor_printf(mon, "TPM device not supported\n");
+    monitor_hmp_printf(hmp, "TPM device not supported\n");
 #endif /* CONFIG_TPM */
 }
diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
index af67f00dad32..96d6ad897275 100644
--- a/target/i386/cpu-apic.c
+++ b/target/i386/cpu-apic.c
@@ -85,7 +85,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
 
 void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUState *cs;
 
     if (qdict_haskey(qdict, "apic-id")) {
@@ -101,7 +100,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 
 
     if (!cs) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 72bcab131f77..46762540ba65 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
     return addr;
 }
 
-static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
+static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
                       hwaddr pte, hwaddr mask)
 {
     addr = addr_canonical(env, addr);
 
-    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
-                   " %c%c%c%c%c%c%c%c%c\n",
-                   addr,
-                   pte & mask,
-                   pte & PG_NX_MASK ? 'X' : '-',
-                   pte & PG_GLOBAL_MASK ? 'G' : '-',
-                   pte & PG_PSE_MASK ? 'P' : '-',
-                   pte & PG_DIRTY_MASK ? 'D' : '-',
-                   pte & PG_ACCESSED_MASK ? 'A' : '-',
-                   pte & PG_PCD_MASK ? 'C' : '-',
-                   pte & PG_PWT_MASK ? 'T' : '-',
-                   pte & PG_USER_MASK ? 'U' : '-',
-                   pte & PG_RW_MASK ? 'W' : '-');
+    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
+                       " %c%c%c%c%c%c%c%c%c\n",
+                       addr,
+                       pte & mask,
+                       pte & PG_NX_MASK ? 'X' : '-',
+                       pte & PG_GLOBAL_MASK ? 'G' : '-',
+                       pte & PG_PSE_MASK ? 'P' : '-',
+                       pte & PG_DIRTY_MASK ? 'D' : '-',
+                       pte & PG_ACCESSED_MASK ? 'A' : '-',
+                       pte & PG_PCD_MASK ? 'C' : '-',
+                       pte & PG_PWT_MASK ? 'T' : '-',
+                       pte & PG_USER_MASK ? 'U' : '-',
+                       pte & PG_RW_MASK ? 'W' : '-');
 }
 
-static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 /* 4M pages */
-                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
+                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1));
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
+                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
                                   pte & ~PG_PSE_MASK,
                                   ~0xfff);
                     }
@@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
     }
 }
 
-static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 if (pde & PG_PRESENT_MASK) {
                     if (pde & PG_PSE_MASK) {
                         /* 2M pages with PAE, CR4.PSE is ignored */
-                        print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
+                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), pde,
                                   ~((hwaddr)(1 << 20) - 1));
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
@@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             pte = address_space_ldq_le(as, pt_addr + l3 * 8,
                                                        attrs, NULL);
                             if (pte & PG_PRESENT_MASK) {
-                                print_pte(mon, env, (l1 << 30) + (l2 << 21)
+                                print_pte(hmp, env, (l1 << 30) + (l2 << 21)
                                           + (l3 << 12),
                                           pte & ~PG_PSE_MASK,
                                           ~(hwaddr)0xfff);
@@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
 }
 
 #ifdef TARGET_X86_64
-static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
+static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as,
         uint64_t l0, uint64_t pml4_addr)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
@@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
             if (pdpe & PG_PSE_MASK) {
                 /* 1G pages, CR4.PSE is ignored */
-                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
+                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
                         pdpe, 0x3ffffc0000000ULL);
                 continue;
             }
@@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
                 if (pde & PG_PSE_MASK) {
                     /* 2M pages, CR4.PSE is ignored */
-                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
+                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
                             (l3 << 21), pde, 0x3ffffffe00000ULL);
                     continue;
                 }
@@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
                     pte = address_space_ldq_le(as, pt_addr + l4 * 8,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
+                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
                                 (l2 << 30) + (l3 << 21) + (l4 << 12),
                                 pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
                     }
@@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
     }
 }
 
-static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     uint64_t l0;
@@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
     for (l0 = 0; l0 < 512; l0++) {
         pml5e = address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, NULL);
         if (pml5e & PG_PRESENT_MASK) {
-            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL);
+            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL);
         }
     }
 }
@@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                tlb_info_la57(mon, env, as);
+                tlb_info_la57(hmp, env, as);
             } else {
-                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
+                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
             }
         } else
 #endif
         {
-            tlb_info_pae32(mon, env, as);
+            tlb_info_pae32(hmp, env, as);
         }
     } else {
-        tlb_info_32(mon, env, as);
+        tlb_info_32(hmp, env, as);
     }
 }
 
-static void mem_print(Monitor *mon, CPUArchState *env,
+static void mem_print(MonitorHMP *hmp, CPUArchState *env,
                       hwaddr *pstart, int *plast_prot,
                       hwaddr end, int prot)
 {
@@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     prot1 = *plast_prot;
     if (prot != prot1) {
         if (*pstart != -1) {
-            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
-                           HWADDR_FMT_plx " %c%c%c\n",
-                           addr_canonical(env, *pstart),
-                           addr_canonical(env, end),
-                           addr_canonical(env, end - *pstart),
-                           prot1 & PG_USER_MASK ? 'u' : '-',
-                           'r',
-                           prot1 & PG_RW_MASK ? 'w' : '-');
+            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
+                               HWADDR_FMT_plx " %c%c%c\n",
+                               addr_canonical(env, *pstart),
+                               addr_canonical(env, end),
+                               addr_canonical(env, end - *pstart),
+                               prot1 & PG_USER_MASK ? 'u' : '-',
+                               'r',
+                               prot1 & PG_RW_MASK ? 'w' : '-');
         }
         if (prot != 0)
             *pstart = end;
@@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     }
 }
 
-static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 prot = pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
@@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     } else {
                         prot = 0;
                     }
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
-static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     if (pde & PG_PSE_MASK) {
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                       PG_PRESENT_MASK);
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             } else {
                                 prot = 0;
                             }
-                            mem_print(mon, env, &start, &last_prot, end, prot);
+                            mem_print(hmp, env, &start, &last_prot, end, prot);
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
 
 #ifdef TARGET_X86_64
-static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                                        PG_PRESENT_MASK);
                         prot &= pml4e;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pd_addr = pdpe & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                     prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                                   PG_PRESENT_MASK);
                                     prot &= pml4e & pdpe;
-                                    mem_print(mon, env, &start,
+                                    mem_print(hmp, env, &start,
                                               &last_prot, end, prot);
                                 } else {
                                     pt_addr = pde & 0x3fffffffff000ULL;
@@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                         } else {
                                             prot = 0;
                                         }
-                                        mem_print(mon, env, &start,
+                                        mem_print(hmp, env, &start,
                                                   &last_prot, end, prot);
                                     }
                                 }
                             } else {
                                 prot = 0;
-                                mem_print(mon, env, &start,
+                                mem_print(hmp, env, &start,
                                           &last_prot, end, prot);
                             }
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
 }
 
-static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
         end = l0 << 48;
         if (!(pml5e & PG_PRESENT_MASK)) {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
             continue;
         }
 
@@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
             end = (l0 << 48) + (l1 << 39);
             if (!(pml4e & PG_PRESENT_MASK)) {
                 prot = 0;
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
                 continue;
             }
 
@@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 end = (l0 << 48) + (l1 << 39) + (l2 << 30);
                 if (pdpe & PG_PRESENT_MASK) {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                             PG_PRESENT_MASK);
                     prot &= pml5e & pml4e;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
                     if (pde & PG_PRESENT_MASK) {
                         prot = 0;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                 PG_PRESENT_MASK);
                         prot &= pml5e & pml4e & pdpe;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         } else {
                             prot = 0;
                         }
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     }
                 }
             }
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
 }
 #endif /* TARGET_X86_64 */
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                mem_info_la57(mon, env, as);
+                mem_info_la57(hmp, env, as);
             } else {
-                mem_info_la48(mon, env, as);
+                mem_info_la48(hmp, env, as);
             }
         } else
 #endif
         {
-            mem_info_pae32(mon, env, as);
+            mem_info_pae32(hmp, env, as);
         }
     } else {
-        mem_info_32(mon, env, as);
+        mem_info_32(hmp, env, as);
     }
 }
 
diff --git a/target/i386/sev.c b/target/i386/sev.c
index a3f6ee95aaed..7b2eb75fd480 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -786,33 +786,32 @@ SevInfo *qmp_query_sev(Error **errp)
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SevInfo *info = sev_get_info();
 
     if (!info || !info->enabled) {
-        monitor_printf(mon, "SEV is not enabled\n");
+        monitor_hmp_printf(hmp, "SEV is not enabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
-    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
-    monitor_printf(mon, "build: %d\n", info->build_id);
-    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
-                   info->api_minor);
+    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->sev_type));
+    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
+    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
+    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
+                       info->api_minor);
 
     if (sev_snp_enabled()) {
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
-                                                                       : "off");
-        monitor_printf(mon, "SMT allowed: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
-                                                                       : "off");
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
+                                                                           : "off");
+        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
+                                                                           : "off");
     } else {
-        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
-        monitor_printf(mon, "key-sharing: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
+        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
+        monitor_hmp_printf(hmp, "key-sharing: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
     }
 
 out:
diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
index 5645a5d4d4f5..23c25283b27a 100644
--- a/target/m68k/monitor.c
+++ b/target/m68k/monitor.c
@@ -12,11 +12,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
index 5769829bdd7e..6e8a075f5a41 100644
--- a/target/ppc/monitor.c
+++ b/target/ppc/monitor.c
@@ -13,11 +13,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
index 4c9c0c793b36..59cc04b3d0fb 100644
--- a/target/riscv/monitor.c
+++ b/target/riscv/monitor.c
@@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, target_ulong addr)
     return addr;
 }
 
-static void print_pte_header(Monitor *mon)
+static void print_pte_header(MonitorHMP *hmp)
 {
-    monitor_printf(mon, PTE_HEADER_FIELDS);
-    monitor_printf(mon, PTE_HEADER_DELIMITER);
+    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
+    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
 }
 
-static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
+static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr,
                       hwaddr paddr, target_ulong size, int attr)
 {
     /* sanity check on vaddr */
@@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
         return;
     }
 
-    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
-                   " %c%c%c%c%c%c%c\n",
-                   addr_canonical(va_bits, vaddr),
-                   paddr, size,
-                   attr & PTE_R ? 'r' : '-',
-                   attr & PTE_W ? 'w' : '-',
-                   attr & PTE_X ? 'x' : '-',
-                   attr & PTE_U ? 'u' : '-',
-                   attr & PTE_G ? 'g' : '-',
-                   attr & PTE_A ? 'a' : '-',
-                   attr & PTE_D ? 'd' : '-');
+    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
+                       " %c%c%c%c%c%c%c\n",
+                       addr_canonical(va_bits, vaddr),
+                       paddr, size,
+                       attr & PTE_R ? 'r' : '-',
+                       attr & PTE_W ? 'w' : '-',
+                       attr & PTE_X ? 'x' : '-',
+                       attr & PTE_U ? 'u' : '-',
+                       attr & PTE_G ? 'g' : '-',
+                       attr & PTE_A ? 'a' : '-',
+                       attr & PTE_D ? 'd' : '-');
 }
 
-static void walk_pte(Monitor *mon, AddressSpace *as,
+static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
                      hwaddr base, target_ulong start,
                      int level, int ptidxbits, int ptesize, int va_bits,
                      target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
@@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 if ((*last_attr != attr) ||
                     (*last_paddr + *last_size != paddr) ||
                     (last_start + *last_size != start)) {
-                    print_pte(mon, va_bits, *vbase, *pbase,
+                    print_pte(hmp, va_bits, *vbase, *pbase,
                               *last_paddr + *last_size - *pbase, *last_attr);
 
                     *vbase = start;
@@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 *last_size = pgsize;
             } else {
                 /* pointer to the next level of the page table */
-                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, ptesize,
+                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, ptesize,
                          va_bits, vbase, pbase, last_paddr,
                          last_size, last_attr);
             }
@@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
 
 }
 
-static void mem_info_svxx(Monitor *mon, CPUArchState *env)
+static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
 {
     AddressSpace *as = env_cpu(env)->as;
     int levels, ptidxbits, ptesize, vm, va_bits;
@@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     va_bits = PGSHIFT + levels * ptidxbits;
 
     /* print header */
-    print_pte_header(mon);
+    print_pte_header(hmp);
 
     vbase = -1;
     pbase = -1;
@@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     last_attr = 0;
 
     /* walk page tables, starting from address 0 */
-    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
+    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
              &vbase, &pbase, &last_paddr, &last_size, &last_attr);
 
     /* don't forget the last one */
-    print_pte(mon, va_bits, vbase, pbase,
+    print_pte(hmp, va_bits, vbase, pbase,
               last_paddr + last_size - pbase, last_attr);
 }
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!riscv_cpu_cfg(env)->mmu) {
-        monitor_printf(mon, "S-mode MMU unavailable\n");
+        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
         return;
     }
 
     if (riscv_cpu_mxl(env) == MXL_RV32) {
         if (!(env->satp & SATP32_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     } else {
         if (!(env->satp & SATP64_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     }
 
-    mem_info_svxx(mon, env);
+    mem_info_svxx(hmp, env);
 }
 
 #ifdef CONFIG_TCG
diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
index 4e443152bf56..62998a9a57cb 100644
--- a/target/sh4/monitor.c
+++ b/target/sh4/monitor.c
@@ -26,33 +26,32 @@
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
 
-static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
+static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
 {
-    monitor_printf(mon, " tlb%i:\t"
-                   "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
-                   "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
-                   "dirty=%hhu writethrough=%hhu\n",
-                   idx,
-                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
-                   tlb->v, tlb->sh, tlb->c, tlb->pr,
-                   tlb->d, tlb->wt);
+    monitor_hmp_printf(hmp, " tlb%i:\t"
+                       "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
+                       "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
+                       "dirty=%hhu writethrough=%hhu\n",
+                       idx,
+                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
+                       tlb->v, tlb->sh, tlb->c, tlb->pr,
+                       tlb->d, tlb->wt);
 }
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env = monitor_hmp_get_cpu_env(hmp);
     int i;
 
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
-    monitor_printf (mon, "ITLB:\n");
+    monitor_hmp_printf(hmp, "ITLB:\n");
     for (i = 0 ; i < ITLB_SIZE ; i++)
-        print_tlb (mon, i, &env->itlb[i]);
-    monitor_printf (mon, "UTLB:\n");
+        print_tlb(hmp, i, &env->itlb[i]);
+    monitor_hmp_printf(hmp, "UTLB:\n");
     for (i = 0 ; i < UTLB_SIZE ; i++)
-        print_tlb (mon, i, &env->utlb[i]);
+        print_tlb(hmp, i, &env->utlb[i]);
 }
diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
index e826e584a918..36f109cbb568 100644
--- a/target/sparc/monitor.c
+++ b/target/sparc/monitor.c
@@ -29,11 +29,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
index b7b7387706f3..b9c4089b0fb1 100644
--- a/target/xtensa/monitor.c
+++ b/target/xtensa/monitor.c
@@ -28,11 +28,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index b2a884529598..530a3fee3c13 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
  */
 Monitor *monitor_cur(void) { return cur_mon; }
 Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort(); }
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) { abort(); }
 
 #ifndef _WIN32
 static void test_socket_fd_pass_name_good(void)
diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
index f62b2f294952..81a09ec5adfa 100644
--- a/tools/qemu-vnc/clipboard.c
+++ b/tools/qemu-vnc/clipboard.c
@@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboardRequest *req)
         "Cancelled clipboard request");
 
     g_clear_object(&req->invocation);
-    g_clear_handle_id(&req->timeout_id, g_source_remove);;
+    g_clear_handle_id(&req->timeout_id, g_source_remove);
 }
 
 static gboolean
@@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *info)
         vnc_dbus_clipboard_complete_request(
             req->invocation, info, req->type);
         g_clear_object(&req->invocation);
-        g_clear_handle_id(&req->timeout_id, g_source_remove);;
+        g_clear_handle_id(&req->timeout_id, g_source_remove);
         return;
     }
 
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 26597fefaa99..0aa50a901d37 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
     return NULL;
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     return -1;
 }
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 5a8158f4f4b6..a68f5b900d7c 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_TRACE_SIMPLE
 void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
     const char *arg = qdict_get_try_str(qdict, "arg");
 
@@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
             st_set_trace_file(arg);
         }
     } else {
-        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
-        hmp_help_cmd(mon, "trace-file");
+        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
+        hmp_help_cmd(hmp, "trace-file");
     }
 }
 #endif
 
 void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_try_str(qdict, "name");
     TraceEventInfoList *events;
     TraceEventInfoList *elem;
@@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (elem = events; elem != NULL; elem = elem->next) {
-        monitor_printf(mon, "%s : state %u\n",
-                       elem->value->name,
-                       elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
+        monitor_hmp_printf(hmp, "%s : state %u\n",
+                           elem->value->name,
+                           elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
     }
     qapi_free_TraceEventInfoList(events);
 }
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 186209fd0234..f611dd7ee457 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MouseInfoList *mice_list, *mouse;
 
     mice_list = qmp_query_mice(NULL);
     if (!mice_list) {
-        monitor_printf(mon, "No mouse devices connected\n");
+        monitor_hmp_printf(hmp, "No mouse devices connected\n");
         return;
     }
 
     for (mouse = mice_list; mouse; mouse = mouse->next) {
-        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
-                       mouse->value->current ? '*' : ' ',
-                       mouse->value->index, mouse->value->name,
-                       mouse->value->absolute ? " (absolute)" : "");
+        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
+                           mouse->value->current ? '*' : ' ',
+                           mouse->value->index, mouse->value->name,
+                           mouse->value->absolute ? " (absolute)" : "");
     }
 
     qapi_free_MouseInfoList(mice_list);
@@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
 /* Helper for hmp_info_vnc_clients, _servers */
-static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
+static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
                                   const char *name)
 {
-    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
-                   name,
-                   info->host,
-                   info->service,
-                   NetworkAddressFamily_str(info->family),
-                   info->websocket ? " (Websocket)" : "");
+    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
+                       name,
+                       info->host,
+                       info->service,
+                       NetworkAddressFamily_str(info->family),
+                       info->websocket ? " (Websocket)" : "");
 }
 
 /* Helper displaying and auth and crypt info */
-static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
+static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent,
                                    VncPrimaryAuth auth,
                                    VncVencryptSubAuth *vencrypt)
 {
-    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
-                   VncPrimaryAuth_str(auth),
-                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
+    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
+                       VncPrimaryAuth_str(auth),
+                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
 }
 
-static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *client)
+static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *client)
 {
     while (client) {
         VncClientInfo *cinfo = client->value;
 
-        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Client");
-        monitor_printf(mon, "    x509_dname: %s\n",
-                       cinfo->x509_dname ?: "none");
-        monitor_printf(mon, "    sasl_username: %s\n",
-                       cinfo->sasl_username ?: "none");
+        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Client");
+        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
+                           cinfo->x509_dname ?: "none");
+        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
+                           cinfo->sasl_username ?: "none");
 
         client = client->next;
     }
 }
 
-static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
+static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *server)
 {
     while (server) {
         VncServerInfo2 *sinfo = server->value;
-        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "Server");
-        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
+        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "Server");
+        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
                                sinfo->has_vencrypt ? &sinfo->vencrypt : NULL);
         server = server->next;
     }
@@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
 
 void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VncInfo2List *info2l, *info2l_head;
     Error *err = NULL;
 
@@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
     if (!info2l) {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
         return;
     }
 
     while (info2l) {
         VncInfo2 *info = info2l->value;
-        monitor_printf(mon, "%s:\n", info->id);
-        hmp_info_vnc_servers(mon, info->server);
-        hmp_info_vnc_clients(mon, info->clients);
+        monitor_hmp_printf(hmp, "%s:\n", info->id);
+        hmp_info_vnc_servers(hmp, info->server);
+        hmp_info_vnc_clients(hmp, info->clients);
         if (!info->server) {
             /*
              * The server entry displays its auth, we only need to
              * display in the case of 'reverse' connections where
              * there's no server.
              */
-            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
+            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
                                info->has_vencrypt ? &info->vencrypt : NULL);
         }
         if (info->display) {
-            monitor_printf(mon, "  Display: %s\n", info->display);
+            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
         }
         info2l = info2l->next;
     }
@@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_SPICE
 void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SpiceChannelList *chan;
     SpiceInfo *info;
     const char *channel_name;
@@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
     info = qmp_query_spice(NULL);
 
     if (!info->enabled) {
-        monitor_printf(mon, "Server: disabled\n");
+        monitor_hmp_printf(hmp, "Server: disabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "Server:\n");
+    monitor_hmp_printf(hmp, "Server:\n");
     if (info->has_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
-                       info->host, info->port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
+                           info->host, info->port);
     }
     if (info->has_tls_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
-                       info->host, info->tls_port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n",
+                           info->host, info->tls_port);
     }
-    monitor_printf(mon, "    migrated: %s\n",
-                   info->migrated ? "true" : "false");
-    monitor_printf(mon, "        auth: %s\n", info->auth);
-    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
-    monitor_printf(mon, "  mouse-mode: %s\n",
-                   SpiceQueryMouseMode_str(info->mouse_mode));
+    monitor_hmp_printf(hmp, "    migrated: %s\n",
+                       info->migrated ? "true" : "false");
+    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
+    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_version);
+    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
+                       SpiceQueryMouseMode_str(info->mouse_mode));
 
     if (!info->has_channels || info->channels == NULL) {
-        monitor_printf(mon, "Channels: none\n");
+        monitor_hmp_printf(hmp, "Channels: none\n");
     } else {
         for (chan = info->channels; chan; chan = chan->next) {
-            monitor_printf(mon, "Channel:\n");
-            monitor_printf(mon, "     address: %s:%s%s\n",
-                           chan->value->host, chan->value->port,
-                           chan->value->tls ? " [tls]" : "");
-            monitor_printf(mon, "     session: %" PRId64 "\n",
-                           chan->value->connection_id);
-            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "\n",
-                           chan->value->channel_type, chan->value->channel_id);
+            monitor_hmp_printf(hmp, "Channel:\n");
+            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
+                               chan->value->host, chan->value->port,
+                               chan->value->tls ? " [tls]" : "");
+            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
+                               chan->value->connection_id);
+            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId64 "\n",
+                               chan->value->channel_type, chan->value->channel_id);
 
             channel_name = "unknown";
             if (chan->value->channel_type > 0 &&
@@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
                 channel_name = channel_names[chan->value->channel_type];
             }
 
-            monitor_printf(mon, "     channel name: %s\n", channel_name);
+            monitor_hmp_printf(hmp, "     channel name: %s\n", channel_name);
         }
     }
 
@@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
     monitor_hmp_read_command(opaque, 1);
 }
 
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp)
 {
@@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
         return;
     }
     if (!arg) {
-        MonitorHMP *hmp = MONITOR_HMP(mon);
         monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
@@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t key_length)
 
 void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *keys = qdict_get_str(qdict, "keys");
     KeyValue *v = NULL;
     KeyValueList *head = NULL, **tail = &head;
@@ -432,7 +427,7 @@ out:
     return;
 
 err_out:
-    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
+    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, keys);
     goto out;
 }
 
diff --git a/util/error-report.c b/util/error-report.c
index 41694d61cf2d..0e3aaa539e78 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -36,7 +36,7 @@ static int G_GNUC_PRINTF(2, 0)
 error_vprintf_hmp(MonitorHMP *hmp, const char *fmt, va_list ap)
 {
     if (hmp) {
-        return monitor_vprintf(MONITOR(hmp), fmt, ap);
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
 
     return vfprintf(stderr, fmt, ap);
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 5d4143d425a1..01ed43b5a588 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -13,6 +13,7 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
+#include "qom/object.h"
 #include "qemu/qemu-print.h"
 
 /*
@@ -23,8 +24,16 @@
 int qemu_vprintf(const char *fmt, va_list ap)
 {
     Monitor *cur_mon = monitor_cur();
+
+    /* for all monitors: QMP & HMP */
     if (cur_mon) {
-        return monitor_vprintf(cur_mon, fmt, ap);
+        /* don't use monitor_cur_hmp(), to avoid a second lookup */
+        MonitorHMP *hmp = (MonitorHMP *)
+            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP);
+        if (!hmp) {
+            return -1;
+        }
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vprintf(fmt, ap);
 }
@@ -55,7 +64,11 @@ int qemu_printf(const char *fmt, ...)
 int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
 {
     if (!stream) {
-        return monitor_vprintf(monitor_cur(), fmt, ap);
+        MonitorHMP *hmp = monitor_cur_hmp();
+        if (!hmp) {
+            return -1;
+        }
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vfprintf(stream, fmt, ap);
 }

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 12:08:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 12:08:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401963.1637412 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvNf-0007Cq-I9; Fri, 28 Aug 2026 12:08:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401963.1637412; Fri, 28 Aug 2026 12:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvNf-0007Cj-F1; Fri, 28 Aug 2026 12:08:23 +0000
Received: by outflank-mailman (input) for mailman id 1401963;
 Fri, 28 Aug 2026 12:08:22 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wzvNd-0006zc-RW
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:08:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzvNc-007Hm7-TW
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:08:20 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a917a30-e002-0a2a0a5209dd-0a2a4509b928-12
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:08:20 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a917a33-be1a-0a2a45090019-aa0a857cb6d7-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:08:20 +0200
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-418-nuiyXrIAOtatGRwkdtsFNA-1; Fri,
 28 Aug 2026 08:08:12 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id F29831944A90; Fri, 28 Aug 2026 12:08:10 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id BE16B1803A40; Fri, 28 Aug 2026 12:08:09 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787918899;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=57QfcTR5j/zJ5KMJTDu3qOnAc1zj+QlnuAt4vX2DJrQ=;
	b=Cjit+gdpFHznG0w2sOL7qf/Z1/PVPQ8jnSl0bmwcb0STvg4mbbDqm71U7S+xZXCWNAWbRo
	fQqecPGbFRRcBqDN8G16BiVUxAV+gwAdYYCXr80WuMdPM9OjE298RpS71R+BPDD11AOdd8
	PpQPixRPe0uAkclIWPnTb1s4G/TjK4k=
X-MC-Unique: nuiyXrIAOtatGRwkdtsFNA-1
X-Mimecast-MFC-AGG-ID: nuiyXrIAOtatGRwkdtsFNA_1787918891
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Fri, 28 Aug 2026 16:04:36 +0400
Subject: [PATCH v5 39/50] qdev-monitor: make print_dev() callback take
 MonitorHMP
MIME-Version: 1.0
Message-Id: <20260828-qemu-no-hmp-v5-39-9227de146347@redhat.com>
References: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
In-Reply-To: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@oss.qualcomm.com>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=8798;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=TnV/ecEwZ8dNWntwBJ1/B+qLywO2KqD7Jgy5xW81cUE=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkXk5fHeHQ9PTovKBIiL1Kj9SHgf5KAk6qr63Q
 3PpwqXd9+CJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapF5OQAKCRDa6OEJdZac
 5UDzEACpKe/RFuJkrXeGmiMqmDdPidlsbDLE5uaT2lZrttbGJ+MUV2FeoDVAf1fP5Y4kTbmfCtS
 5Rq1MLSAMmXvxKOZwiITLkaOuzQd/ZCdZwZJy88QPCJ1Luto+HJ37bAWiXzv8X/gZ8FfWGu+M32
 auXj05YKgOlRfFWAX9K9S4jpY9/XZJKyVG+14iYOXSFJ/WeLzUB52sxd+SM35HL2t5TL6H01DTU
 TpclN6oo3xZjTjt652QbDKJuUlCADoybrcxrnFU/siZji9+AjJUm3d0IIkmp3Lz9zA50LhyEy0a
 nPBZgc1aIHoV5zEytbSp/GagafveGW5DvAYcJ/zd7g7oVWWu6w0w7sT4qlGO05IDt8SzkUI9TxH
 9UxCc2ttH/hRAniD2f9vpge8m/ckcOuabZmraX7rgM6RcWnSfOAx+azfc8Mj3wD9CVgil7lOtOu
 uNPRdDowuu+rK446vzGGqggJjoribK81BZXz2qPqunZoufwevPd+FMvImMA19AXW4JgrA5Tea+q
 yLOo/AZEMBqD2b5BGXvOK6jyfx51p+SP2pP2QivYmo1hBR3Cm4kYPCGE7uMe+PPVl29PEvAak6+
 B7DzGsxr/A3siRggDsJYcrwnNBYAjZrna8A13SC2G87Cb3GHQ/XwRMJlLZyklRpYFedVgkTKu0E
 n8hsu/YQ4octDuQ==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: EE9Z-M5WCbqPagtt_4M54i18nzuEx2VfcRn3NTrBczc_1787918891
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787918900-BE2C4034-F26B420C/0/0
X-purgate-type: clean
X-purgate-size: 8800

The callback is specific to HMP context, avoid unsafe MONITOR_HMP()
cast.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/char/virtio-serial-bus.c | 6 +++---
 hw/core/sysbus.c            | 5 ++---
 hw/misc/auxbus.c            | 7 +++----
 hw/pci/pci-hmp-cmds.c       | 3 +--
 hw/pci/pci-internal.h       | 2 +-
 hw/usb/bus.c                | 5 ++---
 hw/xen/xen-bus.c            | 3 +--
 include/hw/core/qdev.h      | 3 ++-
 system/qdev-monitor.c       | 7 +++----
 9 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 33fdc0846ac3..4dcc4516e45e 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -834,11 +834,11 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+    monitor_hmp_printf(hmp, "%*sport %d, guest %s, host %s, throttle %s\n",
                        indent, "", port->id,
                        port->guest_connected ? "on" : "off",
                        port->host_connected ? "on" : "off",
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 82130ba04698..31c4fdf79d48 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,7 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -249,10 +249,9 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ffa76f83016b..0bb89c5a60ab 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,7 +47,7 @@
 } while (0)
 
 
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
@@ -288,7 +288,7 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
     AUXSlave *s;
@@ -300,8 +300,7 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon),
-                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+    monitor_hmp_printf(hmp, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
                        indent, "",
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 500f821246a9..bcccfaf07f4d 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,9 +135,8 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
diff --git a/hw/pci/pci-internal.h b/hw/pci/pci-internal.h
index a7d6d8a7324e..b7231fab5dc9 100644
--- a/hw/pci/pci-internal.h
+++ b/hw/pci/pci-internal.h
@@ -16,7 +16,7 @@ extern PCIHostStateList pci_host_bridges;
 
 const pci_class_desc *get_class_desc(int class);
 PCIBus *pci_find_bus_nr(PCIBus *bus, int bus_num);
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+void pcibus_dev_print(MonitorHMP *mon, DeviceState *dev, int indent);
 
 int pcie_aer_parse_error_string(const char *error_name,
                                 uint32_t *status, bool *correctable);
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index fe3dbfa2227c..8bd25a9d872a 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,7 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -544,9 +544,8 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 4075b5b001ae..b81a067e7753 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,9 +101,8 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
-static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
+static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 37f7d3355193..1391dc060caf 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -10,6 +10,7 @@
 #include "qom/object.h"
 #include "hw/core/hotplug.h"
 #include "hw/core/resettable.h"
+#include "monitor/hmp.h"
 
 /**
  * DOC: The QEMU Device API
@@ -323,7 +324,7 @@ struct BusClass {
     ObjectClass parent_class;
 
     /* FIXME first arg should be BusState */
-    void (*print_dev)(Monitor *mon, DeviceState *dev, int indent);
+    void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 3860ada2a237..13ac9f8f3be1 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -790,18 +790,17 @@ static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
     }
 }
 
-static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int indent)
+static void bus_print_dev(BusState *bus, MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     BusClass *bc = BUS_GET_CLASS(bus);
 
     if (bc->print_dev) {
-        bc->print_dev(mon, dev, indent);
+        bc->print_dev(hmp, dev, indent);
     }
 }
 
 static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -828,7 +827,7 @@ static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
         qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
-    bus_print_dev(dev->parent_bus, mon, dev, indent);
+    bus_print_dev(dev->parent_bus, hmp, dev, indent);
 }
 
 static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 12:08:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 12:08:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401966.1637422 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvNu-0007bX-SU; Fri, 28 Aug 2026 12:08:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401966.1637422; Fri, 28 Aug 2026 12:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvNu-0007bN-Mp; Fri, 28 Aug 2026 12:08:38 +0000
Received: by outflank-mailman (input) for mailman id 1401966;
 Fri, 28 Aug 2026 12:08:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1wzvNt-0007Xy-29
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:08:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzvNr-00EXIr-Or
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:08:35 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a917a32-bab6-0a2a0a5309dd-0a2a45018ebc-44
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:08:35 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a917a42-5984-0a2a45010019-aa0a857cc3f9-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:08:35 +0200
Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-112-FjPGu21KPEGueILqlWBtQw-1; Fri,
 28 Aug 2026 08:08:30 -0400
Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 69B50195C271; Fri, 28 Aug 2026 12:08:28 +0000 (UTC)
Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.117])
 by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 5B8671955F70; Fri, 28 Aug 2026 12:08:26 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787918914;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=25R6K0h4VasC6c0/fb56834UAhmdGWxK3yF98UwXa74=;
	b=X+KJQP6pxlhTkY0qp7WozASj1yBppivhf7jiMcsMrnz75xegMGF9XYYmA8NrWIRgNAeMhX
	tBZLjv/MzUO/h0Vb0EJDtLeGaMwibDLHEvf4+BMseMQYbQYAvbawkiM6ETduAWx5wDx9dL
	ueZtyhpaqTPiku3JEPl0aafyKqrebkY=
X-MC-Unique: FjPGu21KPEGueILqlWBtQw-1
X-Mimecast-MFC-AGG-ID: FjPGu21KPEGueILqlWBtQw_1787918908
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Fri, 28 Aug 2026 16:04:40 +0400
Subject: [PATCH v5 43/50] hw: guard BusClass::print_dev with CONFIG_HMP
MIME-Version: 1.0
Message-Id: <20260828-qemu-no-hmp-v5-43-9227de146347@redhat.com>
References: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
In-Reply-To: <20260828-qemu-no-hmp-v5-0-9227de146347@redhat.com>
To: qemu-devel@nongnu.org
Cc: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 dave@treblig.org, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, Paolo Bonzini <pbonzini@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=9504;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=XnF4d30mGYZ8u8fB9M/5LPD7J1YmexQm02x6u9jiDrs=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkXk5gZiAAiEhj3djzZX7HxGWpWFaKCob/DEbb
 zcqXW2xm/CJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapF5OQAKCRDa6OEJdZac
 5W5qD/0dC3Ql0bbtl5G9EqXtaBbdksLOB6k5kDr15oE3N59BmFfZx2IuRbJJeenppsanCtXTGuB
 nINLutbXOlqIpKSjanyMMAgPMHGYqVvdIDXLTURUgAoHZ/QYRnrBFsxR6XUwwViXHgoM9R8DGNF
 cKnsFWMPl6b+Of5Mz+udx6E3Jowk83aWwdJGWk+iSCRE3Asjf4j0MFc9tZQ2YMfyJbd7zhFy8lN
 17SMPNaGa8W3RU+fzSDYiwhHg5Z8Py/7m20LWisTFZS3UUyHMQ0OgKMSfhQNsoP1F+ldn/KxQ40
 3Q2JjUCCjgPWvF9jgyiI7x4M63DZ0OM7QCBwOT35UjrZhSSFbQT9ysUzkA/BrhBMp/EIdENnm4Q
 cICGKOc9Z2yD2FPBS9oXZe6tyhtDsPrFqhpZwNgL3ZkVWiW0Qv/8RpJngJC4k39nzwfEX2SyfcY
 tTiIzm4vH2nDf7/BCLjtPQUoisl5rV7fUYHpcCHO5xoxq3WDThNxp+T4y9HwKscZ/VtpSdSPiEj
 K4k+dx/ZFmP+TNE24XiC1zNaXKE+zvkwax0fyCBgjhoWzMnLsDaxJPhZjZJlRe8X+pGE4/Fezxc
 2QP52G6Cx/QNuTm3sJrNJuhtkrTIfew7H3yjqr/JumUIcTs3ggTHcy/N2V1npwCsVQlWV80K9EA
 MXzpzvViz6L318A==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17
X-Mimecast-MFC-PROC-ID: fPKhoIC7ZXtOkUg70V-ypT6SgO6ZjScqjlUUI2ZJdxM_1787918908
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1787918915-C5146757-30353459/0/0
X-purgate-type: clean
X-purgate-size: 9506

The print_dev callback is only used by HMP 'info qtree'. Guard the field
in BusClass, all implementations, and the caller with CONFIG_HMP.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 hw/char/virtio-serial-bus.c |  6 ++++++
 hw/core/sysbus.c            |  6 ++++++
 hw/misc/auxbus.c            | 16 +++++++++++-----
 hw/pci/pci-hmp-cmds.c       |  2 ++
 hw/pci/pci.c                |  2 ++
 hw/usb/bus.c                |  6 ++++++
 hw/xen/xen-bus.c            |  4 ++++
 include/hw/core/qdev.h      |  2 ++
 8 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 4dcc4516e45e..83a033ce8555 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,9 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -823,8 +825,10 @@ static const Property virtser_props[] = {
 
 static void virtser_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
     k->print_dev = virtser_bus_dev_print;
+#endif
 }
 
 static const TypeInfo virtser_bus_info = {
@@ -834,6 +838,7 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
@@ -844,6 +849,7 @@ static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent
                        port->host_connected ? "on" : "off",
                        port->throttled ? "on" : "off");
 }
+#endif
 
 /* This function is only used if a port id is not provided by the user */
 static uint32_t find_free_port_id(VirtIOSerial *vser)
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 31c4fdf79d48..fe8f867a8d9c 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,9 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -76,7 +78,9 @@ static void system_bus_class_init(ObjectClass *klass, const void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = sysbus_dev_print;
+#endif
     k->get_fw_dev_path = sysbus_get_fw_dev_path;
 }
 
@@ -249,6 +253,7 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
@@ -261,6 +266,7 @@ static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            indent, "", s->mmio[i].addr, size);
     }
 }
+#endif
 
 static char *sysbus_get_fw_dev_path(DeviceState *dev)
 {
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 0bb89c5a60ab..3f17784d9b8a 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,18 +47,22 @@
 } while (0)
 
 
+#ifdef CONFIG_HMP
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
 static void aux_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
 
     /* AUXSlave has an MMIO so we need to change the way we print information
      * in monitor.
      */
     k->print_dev = aux_slave_dev_print;
+#endif
 }
 
 AUXBus *aux_bus_init(DeviceState *parent, const char *name)
@@ -91,11 +95,6 @@ void aux_map_slave(AUXSlave *aux_dev, hwaddr addr)
     memory_region_add_subregion(bus->aux_io, addr, aux_dev->mmio);
 }
 
-static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
-{
-    return (dev == DEVICE(bus->bridge));
-}
-
 I2CBus *aux_get_i2c_bus(AUXBus *bus)
 {
     return aux_bridge_get_i2c_bus(bus->bridge);
@@ -288,6 +287,12 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
+#ifdef CONFIG_HMP
+static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
+{
+    return (dev == DEVICE(bus->bridge));
+}
+
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
@@ -305,6 +310,7 @@ static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
 }
+#endif
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
 {
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index bcccfaf07f4d..879011da1384 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,6 +135,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
+#ifdef CONFIG_HMP
 void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     PCIDevice *d = (PCIDevice *)dev;
@@ -170,6 +171,7 @@ void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            r->addr, r->addr + r->size - 1);
     }
 }
+#endif
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index e8e8a3b76714..c15f2b9f084a 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -293,7 +293,9 @@ static void pci_bus_class_init(ObjectClass *klass, const void *data)
     ResettableClass *rc = RESETTABLE_CLASS(klass);
     FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = pcibus_dev_print;
+#endif
     k->get_dev_path = pcibus_get_dev_path;
     k->get_fw_dev_path = pcibus_get_fw_dev_path;
     k->realize = pci_bus_realize;
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 8bd25a9d872a..5cc5ffec33a1 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,9 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -32,7 +34,9 @@ static void usb_bus_class_init(ObjectClass *klass, const void *data)
     BusClass *k = BUS_CLASS(klass);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = usb_bus_dev_print;
+#endif
     k->get_dev_path = usb_get_dev_path;
     k->get_fw_dev_path = usb_get_fw_dev_path;
     hc->unplug = qdev_simple_device_unplug_cb;
@@ -544,6 +548,7 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     USBDevice *dev = USB_DEVICE(qdev);
@@ -555,6 +560,7 @@ static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
                        usb_speed(dev->speed), dev->product_desc,
                        dev->attached ? ", attached" : "");
 }
+#endif
 
 static char *usb_get_dev_path(DeviceState *qdev)
 {
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index b81a067e7753..1762816bf469 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,6 +101,7 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
+#ifdef CONFIG_HMP
 static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     XenDevice *xendev = XEN_DEVICE(dev);
@@ -108,6 +109,7 @@ static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
                        indent, "", xendev->name, xendev->frontend_id);
 }
+#endif
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
 {
@@ -386,7 +388,9 @@ static void xen_bus_class_init(ObjectClass *class, const void *data)
     BusClass *bus_class = BUS_CLASS(class);
     HotplugHandlerClass *hotplug_class = HOTPLUG_HANDLER_CLASS(class);
 
+#ifdef CONFIG_HMP
     bus_class->print_dev = xen_bus_print_dev;
+#endif
     bus_class->get_dev_path = xen_bus_get_dev_path;
     bus_class->realize = xen_bus_realize;
     bus_class->unrealize = xen_bus_unrealize;
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 1391dc060caf..f054a214fc6a 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -323,8 +323,10 @@ DECLARE_OBJ_CHECKERS(BusState, BusClass,
 struct BusClass {
     ObjectClass parent_class;
 
+#ifdef CONFIG_HMP
     /* FIXME first arg should be BusState */
     void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
+#endif
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 12:46:03 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 12:46:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1401999.1637431 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvy1-0001IN-FT; Fri, 28 Aug 2026 12:45:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1401999.1637431; Fri, 28 Aug 2026 12:45:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzvy1-0001IG-Bv; Fri, 28 Aug 2026 12:45:57 +0000
Received: by outflank-mailman (input) for mailman id 1401999;
 Fri, 28 Aug 2026 12:45:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wzvxz-0001H5-Je
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 12:45:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzvxy-00CURd-NS
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:45:54 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a9182eb-8faa-0a2a0a5109dd-0a2a4509dac2-46
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:45:54 +0200
Received: from [195.135.223.131] (helo=smtp-out2.suse.de)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a918302-be1a-0a2a45090019-c387df8399d6-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 14:45:54 +0200
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org
 [IPv6:2a07:de40:b281:104:10:150:64:97])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by smtp-out2.suse.de (Postfix) with ESMTPS id 59ED51FE7D;
 Fri, 28 Aug 2026 12:45:40 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 112BF13515;
 Fri, 28 Aug 2026 12:45:40 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id kAvUAvSCkWoIQwAAD6G6ig
 (envelope-from <jgross@suse.com>); Fri, 28 Aug 2026 12:45:40 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787921144; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=y0NhCw6np7quVyS+gVMMtYEVUwNDso7OKTq4DlmC3R4=;
	b=dv5Luscpe++rus5mF4MWpg5KECGJZoaPyu6OWKm/L+fIuGSVgNq12HTDzPb+Ga3FgZh2sV
	/hAVscJivPHOVzJv/Kb5tc0nqdLzymgOi71g527A6yM6EPKpm8teVLJzNt6z4AS7oaGpBp
	2Ns+7oCAm0OlSf/Jd25PkDMuBtXdHt0=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="C/Zla2mv"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1787921140; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=y0NhCw6np7quVyS+gVMMtYEVUwNDso7OKTq4DlmC3R4=;
	b=C/Zla2mvNOrB8lNyE72cZEkX0aCN4ayWHver6Gc1Ytg50oFf/u1uVQVH3vzIJi8LmJ4m+5
	vgHzyO8maVR4L516EghP5dAYnObMbVuyF8t+m9IN9z7u1IdxwnLQoZNhif20Z5cIkvlHZc
	tlrolmGa3pIFFU8T5FrNUxCX4C37ZRo=
Message-ID: <0c4e9bb8-f2f1-4a33-8050-1ebc311f46dc@suse.com>
Date: Fri, 28 Aug 2026 14:45:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-2-frn1furkan10@gmail.com>
Content-Language: en-US
From: Juergen Gross <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260819051532.9197-2-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------GQliKWGOTNcjML0o29NTqMFk"
X-Spam-Score: -5.41
X-Rspamd-Queue-Id: 59ED51FE7D
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Level: 
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Spam-Flag: NO
X-purgate-ID: tlsNG-bad1c0/1787921154-FD668034-D84554D0/0/0
X-purgate-type: clean
X-purgate-size: 11019

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------GQliKWGOTNcjML0o29NTqMFk
Content-Type: multipart/mixed; boundary="------------9lfENoGpuQ4900kHH8gLgJeU";
 protected-headers="v1"
From: Juergen Gross <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
Message-ID: <0c4e9bb8-f2f1-4a33-8050-1ebc311f46dc@suse.com>
Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-2-frn1furkan10@gmail.com>
In-Reply-To: <20260819051532.9197-2-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------9lfENoGpuQ4900kHH8gLgJeU
Content-Type: multipart/mixed; boundary="------------4c8rhPho3rtxE5Q5Iyn5Gydy"

--------------4c8rhPho3rtxE5Q5Iyn5Gydy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTkuMDguMjYgMDc6MTUsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gc2NoZWRfbW92
ZV9kb21haW4oKSBkZXJpdmVzIHRoZSBudW1iZXIgb2YgdW5pdHMgdG8gcmVidWlsZCBmcm9t
DQo+IGQtPm1heF92Y3B1cywgd2hpY2ggaXMgZml4ZWQgYXQgZG9tYWluIGNyZWF0aW9uIGFu
ZCBuZXZlciByb2xsZWQNCj4gYmFjayBpZiB2Y3B1X2NyZWF0ZSgpIGZhaWxzIHBhcnR3YXkg
dGhyb3VnaCBidWlsZGluZyBhIGRvbWFpbi4gU28NCj4gZC0+dmNwdVtpXSBjYW4gYmUgTlVM
TCBmb3Igc29tZSBpIGV2ZW4gdGhvdWdoIG1heF92Y3B1cyBzdGlsbA0KPiBjb3VudHMgaXQg
LSB0aGlzIGhhcHBlbnMgaWYgc2NoZWRfYWxsb2NfdWRhdGEoKSByZXR1cm5zIE5VTEwuDQo+
IA0KPiBUaGUgcGVyLXVuaXQgbG9vcCBkb2Vzbid0IGNoZWNrIGZvciB0aGlzOiBpdCBzZXRz
DQo+IHVuaXQtPnZjcHVfbGlzdCA9IGQtPnZjcHVbdW5pdF9pZF0gKE5VTEwpIGFuZCBoYW5k
cyB0aGF0IGJyb2tlbg0KPiB1bml0IHN0cmFpZ2h0IHRvIHRoZSBkZXN0aW5hdGlvbiBzY2hl
ZHVsZXIncyBhbGxvY191ZGF0YSgpLA0KPiB3aGljaCBhc3N1bWVzIHZjcHVfbGlzdCBpcyBh
bHdheXMgdmFsaWQgYW5kIGNyYXNoZXMgWGVuIHdoZW4NCj4gaXQgaXMgbm90Lg0KPiANCj4g
UmVwcm9kdWNlZCBieSBidWlsZGluZyBhIGRvbWFpbiBpbiBhIG5vbi1kZWZhdWx0IGNwdXBv
b2wgd2hlcmUNCj4gdmNwdSBjcmVhdGlvbiBmYWlscyBwYXJ0d2F5IHRocm91Z2gsIHRoZW4g
ZGVzdHJveWluZyBpdC4NCj4gZG9tYWluX2tpbGwoKSBtb3ZlcyB0aGUgZG9tYWluIGJhY2sg
dG8gdGhlIGRlZmF1bHQgY3B1cG9vbCB2aWENCj4gc2NoZWRfbW92ZV9kb21haW4oKSBiZWZv
cmUgYWN0dWFsbHkgZGVzdHJveWluZyBpdCwgY3Jhc2hpbmcNCj4gaW5zaWRlIHRoZSBkZXN0
aW5hdGlvbiBzY2hlZHVsZXIncyBhbGxvY191ZGF0YSgpIChzZWVuIGluDQo+IENyZWRpdDIn
cyBjc2NoZWQyX2FsbG9jX3VkYXRhKCkgLT4gaXNfaWRsZV91bml0KCkgLT4gTlVMTCBkZXJl
ZikuDQo+IA0KPiBCZWZvcmUgYnVpbGRpbmcgYSB1bml0IGluIHNjaGVkX21vdmVfZG9tYWlu
KCksIGNoZWNrIHdoZXRoZXIgYWxsDQo+IHZwY3Ugc2xvdHMgYmVsb25naW5nIHRvIHRoYXQg
dW5pdCBhcmUgcG9wdWxhdGVkLiBJZiBhbnkgb2YgaXRzDQo+IHZwY3VzIGlzIG1pc3Npbmc6
DQo+ICAgLSBGb3IgYSBkeWluZyBkb21haW4sIHNraXAgdGhlIHVuaXQgYWxsb2NhdGlvbi4N
Cj4gICAtIEZvciBhbiBhY3RpdmUgZG9tYWluLCBhYm9ydCB0aGUgbW92ZSBhbmQgcmV0dXJu
IC1FSU5WQUwgdG8NCj4gICAgIHByZXZlbnQgcnVubmluZyB3aXRoIGRyb3BwZWQgdkNQVXMu
DQo+IA0KPiBGaXhlczogNzBmYWRjNDE2MzViICgieGVuL2NwdXBvb2w6IHN1cHBvcnQgbW92
aW5nIGRvbWFpbiBiZXR3ZWVuIGNwdXBvb2xzIHdpdGggZGlmZmVyZW50IGdyYW51bGFyaXR5
IikNCj4gU2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21h
aWwuY29tPg0KDQpTb3JyeSBmb3IgcmVhbGl6aW5nIHRoaXMgb25seSBub3csIGJ1dCBJIHRo
aW5rIHRoaXMgcHJvYmxlbSBzaG91bGQgYmUNCnNvbHZlZCBjb21wbGV0ZWx5IGRpZmZlcmVu
dGx5Lg0KDQpUb2RheSB0aGVyZSBhcmUgbXVsdGlwbGUgcGxhY2VzIGluIHRoZSBoeXBlcnZp
c29yIHdoZXJlIHZjcHVzIGFyZSBiZWluZw0Kc2V0dXAgdmlhIHZjcHVfY3JlYXRlKCkuIEZv
ciB2Y3B1LWlkcyBvdGhlciB0aGFuIDAgdGhpcyBpcyBhbHdheXMgZG9uZQ0KaW4gYSBsb29w
IHdpdGggYXNjZW5kaW5nIGlkcywgdXAgdG8gZC0+bWF4X3ZjcHVzLiBXaGVuZXZlciB2Y3B1
X2NyZWF0ZSgpDQppcyBmYWlsaW5nLCB0aGUgbG9vcCBpcyB0ZXJtaW5hdGVkLiBUaGUgb25s
eSBzcGVjaWFsIGNhc2UgaXMgdGhlIGlkbGUtZG9tYWluLA0Kd2hpY2ggd2lsbCBuZXZlciBo
YXZlIHlvdXIgcHJvYmxlbS4NCg0KU28gdGhlIGVhc3kgZml4IHdvdWxkIGJlIHRvOg0KDQot
IGhhdmUgb25seSBvbmUgZnVuY3Rpb24gdmNwdXNfY3JlYXRlKCkgY3JlYXRpbmcgYWxsIHRo
ZSB2Y3B1cyBmb3IgYSBkb21haW4NCiAgIGFuZCB1c2UgdGhpcyBmdW5jdGlvbiBldmVyeXdo
ZXJlIGluc3RlYWQgb2Ygc2FpZCBsb29wDQoNCi0gaW4gY2FzZSBhIHNpbmdsZSB2Y3B1IGNh
bid0IGJlIGNyZWF0ZWQgYnkgdmNwdXNfY3JlYXRlKCksIGQtPm1heF92Y3B1cw0KICAgc2hv
dWxkIGJlIHJlc2V0IHRvIHRoZSBpZCBvZiB0aGUgdmNwdSB3aGljaCBjb3VsZG4ndCBiZSBj
cmVhdGVkDQoNClRoaXMgd2lsbCBhdm9pZCBhbnkgcG90ZW50aWFsIE5VTEwgZGVyZWZzIGVs
c2V3aGVyZSwgYXMgdmNwdSBsb29wcyB3aWxsDQpqdXN0IGJlIGVuZGluZyBiZWZvcmUgaGl0
dGluZyBhIE5VTEwgcG9pbnRlci4NCg0KSW4gY2FzZSB5b3UgYXJlIG5vdCBmZWVsaW5nIGNv
bWZvcnRhYmxlIHdyaXRpbmcgdGhpcyBwYXRjaCwganVzdCBzcGVhayB1cA0KYW5kIEkgd2ls
bCBkbyBpdC4NCg0KDQpKdWVyZ2VuDQo=
--------------4c8rhPho3rtxE5Q5Iyn5Gydy
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------4c8rhPho3rtxE5Q5Iyn5Gydy--

--------------9lfENoGpuQ4900kHH8gLgJeU--

--------------GQliKWGOTNcjML0o29NTqMFk
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqRgvMFAwAAAAAACgkQsN6d1ii/Ey8X
FQf/U0/ussTD7PYg8BxOlEksaV1+Z/CgRRog6ItVu8Rw5/FTYEInbtLpOZZ9FMQVZ4G15MYG7gvF
I9X4OARBPIPw81zSO7tAUnthS7plxGsy+mnE+7EA8yOPVJ0DNHG/XgoRlgsXBNHM6JoQQfINXCP8
txM9GbHlKtBuBM8TqIFOvqUyDp/MNhWfAeE0qqVNuttYvSBC1DUprwhk3nDB4pkZQ5gmAX089HBb
kdYQoCkfyVU2i02FTQcf0pU9OYrRUwafVmSmPsLW9hxp6FyunSoeAaePMElX+hTw4zLBEHFXKoqH
SlOhI1utiseuPxgOkKnZItMnuBzDFfiK48tEKf7iAg==
=upuY
-----END PGP SIGNATURE-----

--------------GQliKWGOTNcjML0o29NTqMFk--


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 13:12:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 13:12:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402026.1637447 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwNK-0000tC-NJ; Fri, 28 Aug 2026 13:12:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402026.1637447; Fri, 28 Aug 2026 13:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwNK-0000t0-KS; Fri, 28 Aug 2026 13:12:06 +0000
Received: by outflank-mailman (input) for mailman id 1402026;
 Fri, 28 Aug 2026 13:12:05 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wzwNJ-0000sU-GX
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 13:12:05 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzwNI-007SEb-TQ
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:12:04 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a918920-e002-0a2a0a5209dd-0a2a450b9d9e-2
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:12:04 +0200
Received: from [40.107.209.53]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a91891c-b7e8-0a2a450b0019-286bd1353d50-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:11:58 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by LV3PR03MB7586.namprd03.prod.outlook.com (2603:10b6:408:286::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Fri, 28 Aug
 2026 13:11:54 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0360.008; Fri, 28 Aug 2026
 13:11:54 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VQnD3oB06ogLrb+GpEDJD4cQ1eb3Mzy5JsqTnlqVe0i5J6rUUtAP5sjR/Hl43ZLaLi8CYNQdUG7tp5smLl/AZETUJ5IZRnW/y8jtSKAAheRWSvE46pn5Dc7Y9U6IdJ0dAfSkKYzxU4/Qc/UBZNyC79HEpvzzGXW25EbuLaBPTNnvdlOs9tzOSuLIJopYhYWRItXphRzkk++/UGfsAuwhIy2Nd0M5rzYbnF9XV1eoLWaMTbCvWOUKVTR14sLJk6IWFOgIW++qpmj1vZs4IQBjCct4m2NugSEFJi18ij5FXUOHqSTn1vWnalRl124dpWMw0M8ovbct+y2+vkYzZfFV4g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hxvuCWrZRUBjgBVuR44jM6nAu6HqPQeFkqd4ySn6LHQ=;
 b=sY/w7tip3XAoeWZ1Ugyi5yEcT9qK2sgA/qC5yodvsmEDG5zJfK/4Usu5lpaUjh8Q1D26Y5ecVyNRi5OXGN/q7QVvdE3WwclvUaqsAD0OwbxkraoanN1bbArT5mYlLOKga89v558NeuMtHzHM1yfL/Hi1TQik944r2SmxtPl9vGrobAh9g9/FjvuAJi0gebbmDhU2NHTL/F5A3ASnvB9HUwnAuiiWNx9VqJAv9043HYyL+li0ZQovr4rvMSQ0t/DtLsPQySQvzW6nzkjbXlVffmmySaEKFnE+DUg577jB4T9CNc26W1EWld+wNAvyZCNJ/r9lNAVB8KzjOCV2wSZIyg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hxvuCWrZRUBjgBVuR44jM6nAu6HqPQeFkqd4ySn6LHQ=;
 b=A2LXLUpRSINgoNyhKE4015E3xbONxVgEEWkIvtx2b8pGE/47craWB8AOq2BfzN4P1kg7/WkexJCuUXdiRqvkW+QMimjkT37IhYocDghpeyKrMkfxAEitMl1PMXWapx5lOxSJELvxTjZKGkZpW4OX/5r0onzOG8b8uj76Fjzu8/c=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
	Paul Durrant <paul@xen.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v1 1/2] x86/viridian: Workaround Hyper-V GP fault writing to MSR
Date: Fri, 28 Aug 2026 14:11:41 +0100
Message-ID: <20260828131142.3986110-2-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
References: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: LO4P265CA0158.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2c7::17) To CH8PR03MB8274.namprd03.prod.outlook.com
 (2603:10b6:610:2ba::5)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|LV3PR03MB7586:EE_
X-MS-Office365-Filtering-Correlation-Id: f1643572-247b-40d7-69cb-08df0505ee73
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	kVzqBETv0H2daggXAn+Er8MZEO2GDO0k73/Hoed2S03th09dpoFJmD1HR6x7Cx7RDUnaqFqsFSeNlG1By7gs+xnC/OkC1yAxsLQHZu0azbPWvDePzgneQ5FV9+a33VgfMx+XKpyaPdJBQvTEpEm+wafJi1SU6xkzZqRNAUowbuK+Ls34RL8VGhJ1digZ36EfAgyYiLqBKgyckqdZ4UJTr5P5jq7IXJ8qXTGtkKQUHk4EmiGvBcYS+TGtk11dZca77uGJn2+WEZO0oC0R6Ify65fYvQOFAVmHD2QKHSi36Abn0b2QSHP3ewNzfWgsBpAjLn6PHYkA0udFhn9aSzvdzV3ypnaLnvhrt0cCXDsEgL7eA4yLl08qkxN+EjLm0r9m5ybQoY5T6qMN28IFzxzNVdsHBmRypi8ydVdCOFpi3RzByBEYbG1RAX/Xkz+jlXfN/hXZgmTbsuXdx/xcJivGIzNfKCkb/meIxUF2VVws876tlj1fbbdDjFNgXNmGSnvYXV8v4N5N/lrZs4sILicsRMkYLBmGcrjtF2cFl39wRtFDO8oYYlmiGSeriWrVX3Ra3AmPdGIkTyvgiyF9+/35o3/Cd++iSun8gk0kd4OrXE4YgmXyr7KLeUMtIUW1fPAG5rfBBOgwvfFaSJmRGwyt+VVAtPzXGj/3xufu8xTaW7Y=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?WLdUOdljQheyJ7mucw1d7rnoOztpfBAbxIcT/qI9tWRVWmOUXYZfkbgKis5P?=
 =?us-ascii?Q?cIm1LJBX9pIv49CsADSjyX7ggZx6np5nk0oZHbyLXyZXwWirFKVRIJNUeDB9?=
 =?us-ascii?Q?ZEA/NNkntvVhMBfzPmG2LRFFtcCA0PPgZrnKtjSBM2r9kAqOnTlaIyxzCXMJ?=
 =?us-ascii?Q?eV8xqt4H2SEp297MalGDQ84fIVRJdeT7C7pu/Hlnp+AQEX4PSG3GQS9ID6AY?=
 =?us-ascii?Q?rvmoBNCihDZ4uTDhAAl3zuu6O7mR93MiBmiVI2A7Q2MpUoakOg1pofrHpzOc?=
 =?us-ascii?Q?GJ1FranRTNn40cF935Q8KDb/Pov6PsHs6MoGK1qWuwdig0A7Hg1pcJ7lhlu+?=
 =?us-ascii?Q?FfO3q2fBXsMoG5AT2yUOKUyNXGZGIAqcF6I545N61UteCAtBBAgkhe19RFBs?=
 =?us-ascii?Q?oX4eFgkrzLpB77i7b+mpPfzcS/pPBDwVe6mEiKr7nZvoyjcygW4QLRcHaiIQ?=
 =?us-ascii?Q?OvXGKjK1V8eUvTJFsjZgh329k8pr4YPPTh5lPICvMAPXBkW3NPi15OTIpB0K?=
 =?us-ascii?Q?LHKfk84m9QeDNFvOuSnVvF8JxKHKTJqlGtL/gPkTrWlhtw/PjVlEnBgNrRZ4?=
 =?us-ascii?Q?aP8aeAviJMc87+288tA7IsSUXL0eUcA84d5S8M8QTGJUzrfavGi3dRr/e3RC?=
 =?us-ascii?Q?SWtUiwOBafSTcMPqddYcAXxWS0Th7NTBgliXIykMETEqYWCdAZhGDrJdTckX?=
 =?us-ascii?Q?WSLu3ienusEJmj0+7JltKBpug7ws9VQucP0woKxzrnlF2SmJuns5fypnKuZT?=
 =?us-ascii?Q?eD0FQd09wZMDGRUZNzzv22J6HvKPsohJYicenaNgM3QydktVujbc1GH0j3n6?=
 =?us-ascii?Q?aD3OFcRDG39ImNki44cdOTu8BRy5kEAMkS/1SdmlbUhXBRm3G4lMxH4SX/0j?=
 =?us-ascii?Q?jdxsNHrCCWJ53o2Q7jSiszsrWC7vfQOO99Qrf/fMx6Jih10dXmdyiIPzdN4H?=
 =?us-ascii?Q?bzlq4J0BLWzScLrXJVzurmujIFSiTofptMexJl77JOLuWeytqyKTUHMb6Zao?=
 =?us-ascii?Q?F7bQHs8Bu/lAY8ddRZahgMFWdT5/LsbjLIvVUlIzZpuJ6lXeI8vtp3cF3kro?=
 =?us-ascii?Q?KznusSRw337ch3TgYLDGV8+wurSiQ/SMzX0t0d8MeI1oklduBiZbFl2r156O?=
 =?us-ascii?Q?RTiOA6ZiThClAa1J4AU0/zAHQ1ZAlqgA2Dvl3T4wFPW6cNvR2roCa6Qx7c8i?=
 =?us-ascii?Q?i6aTy9rCwfoUj4j3057H7A8LHY3JKDDJuEo8a2ZtvVqhjOg4e+hod6gnTGJZ?=
 =?us-ascii?Q?Y8bSmzYqkU9agXLrHMK7mRE+imisImlraarnU0htFfvU7Z2Jq5kwjrnp2YvU?=
 =?us-ascii?Q?QwN5iurhwcLmT67N824NVeNYpkBp9S/q0CrkuvTeUJCK7XZh1oEGut2ptNcs?=
 =?us-ascii?Q?IAub71yoxnknmf3w6AVh3icjTJT+4wRTEWiOYFgQe7NCRwK6gIFQvQdZRPeJ?=
 =?us-ascii?Q?yfZPGPysb+obRX5MWRhKm25uKNKPxdkD40fslWi7qHLRwNKrsejdJCwibPrn?=
 =?us-ascii?Q?yY0YXZLY/ux2n/4KA6HJNrf0UgceITqeRKefzyhYCyvKrTWopGlWTLFxWBFI?=
 =?us-ascii?Q?WQbmm97LyqmZgL2Lory8QfPXzRX8nZiOgfATlCFZs/UgS5/BeD5qM/1H6M7J?=
 =?us-ascii?Q?jXx1GR4hTF3L0hivKFkRc++J6kKrPDGtUh8ok7TrUkq+i6c+Y4Hfs6xjt4cQ?=
 =?us-ascii?Q?haH3C+TNx2b5kIoq+sjIfXdGLsT6lFOwUlPETuHW30jMvaSlGZEK5Pub+h7Z?=
 =?us-ascii?Q?D4kdCA259sd1zgMRIe1XyOa+vNHaagc=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f1643572-247b-40d7-69cb-08df0505ee73
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 13:11:54.4048
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: u6x4EmKxGdQ2gL9gqxjvSoxMW3X0kLwZ0Ktp2zvgwIqtV4q+zMPyoazg6KSol1nspMrdMo/uFd01MsayJvkfbfF4j28DdDgJt/g9+boH5o4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7586
X-purgate-ID: tlsNG-42698a/1787922720-AAEDE9EA-8BAF39D0/0/0
X-purgate-type: clean
X-purgate-size: 1167

The Viridian spec requires the vector to be >= 0x10 when writing to the
SINTx MSR, otherwise it should #GP fault.
The spec-defined initial value is 0x0000000000010000, i.e. the vector is
0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to
the spec-defined initial value and since the vector is 0, it GP faults.
To workaround this, treat the write as a no-op if the value is
unchanged.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
 xen/arch/x86/hvm/viridian/synic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/viridian/synic.c b/xen/arch/x86/hvm/viridian/synic.c
index e6cba7548f1b..37ddff201a6b 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -157,6 +157,9 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
         if ( !(viridian_feature_mask(d) & HVMPV_synic) )
             return X86EMUL_EXCEPTION;
 
+        if ( val == vs->as_uint64 )
+            break;
+
         /* Vectors must be in the range 0x10-0xff inclusive */
         new.as_uint64 = val;
         if ( new.vector < 0x10 )
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 13:12:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 13:12:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402027.1637458 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwNL-00016F-Va; Fri, 28 Aug 2026 13:12:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402027.1637458; Fri, 28 Aug 2026 13:12:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwNL-000168-RH; Fri, 28 Aug 2026 13:12:07 +0000
Received: by outflank-mailman (input) for mailman id 1402027;
 Fri, 28 Aug 2026 13:12:06 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wzwNK-0000sl-Bp
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 13:12:06 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzwNJ-007SEb-Oz
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:12:05 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a918920-e002-0a2a0a5209dd-0a2a450b9d9e-4
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:12:05 +0200
Received: from [40.107.209.53]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a91891c-b7e8-0a2a450b0019-286bd1353d50-4
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:12:05 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by LV3PR03MB7586.namprd03.prod.outlook.com (2603:10b6:408:286::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Fri, 28 Aug
 2026 13:12:00 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0360.008; Fri, 28 Aug 2026
 13:12:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iZETvm/BFKnB7vl0GuLFXOPlc9hBSYYhJnQXuuj6dPd+WBxWwA8alYr55mV5VgsTxasA6GfH1OFDTYxWLwwZR9TSBwlkvdH9YVDDrVzjDRZKiSAQ1hqTkGbtTqKjpp3KESHc3pdY31DmZME7MBttQMtq4skir3FXF9hsnYy6k0hXWdqrk2KdyQhjBC5Re/R0jPGaJSZ63T3tvHUn4shRgCnnQ8dbfC/Lb//fvK3iAfnMIolEwT39Pj7cujH/+iqlIAVC3WneJwAoVJNrX61Ajx9YBkBj7bG2pzKqtN/SDnCMTztx5pv5HeTM9Z0ic1Wa14XmsH4WMHn3myhKmPIt+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wIOSf/E6k+EC/gSCvgtt7hSK82bz+cU6/Y4zPAZilFI=;
 b=FJ/cJUXDSoPeU2rADEA/MyLFSIjKHIb9AcK+gMVeokLJQde4favFNHXCCFZZyL6ea70CJ05cZYS3PqOvL3OF7GX1PcbUtGpOEnEwuVsXQlYthui6PDWE0btqTgF9hTh0Hden7w6gi7V5oHDRFjefAVCAO/RK0k8bUEx/Q3SNlNx1BLh7+99m+ACTKDORGrLlLLVsgbxONxQMo2ulkfxnrRkjUK9Xa6lvdfsR41QECfAumuZTmaBjwv1A3Z/YSZT2ZJf02Adl8tUhW1dYunuziCSZNq0CuKZzzfKMHcello+3S4fJqvUbV30wPYo1OJg1X9JjtSq3AUSkgL95GTvmIw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wIOSf/E6k+EC/gSCvgtt7hSK82bz+cU6/Y4zPAZilFI=;
 b=DfG6rukU+eFmDlHjWVEH3XT4ojFbkhi2+6RRdXrNwM4neKlFvxCMqsAUP9D/nN6YkatLKKYysM8ZLcOD7gVzgNZ0edUuFWrFIYQfKOn+ly7/NNNQHbtzAiwB+rNIhkjVXAA1JU5qAnS24CKONDfVdud8bYNGJz4Mikbyk7sOLio=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
	Paul Durrant <paul@xen.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v1 2/2] x86/viridian: Implement synthetic timer direct mode
Date: Fri, 28 Aug 2026 14:11:42 +0100
Message-ID: <20260828131142.3986110-3-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
References: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: LO0P265CA0001.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:355::9) To CH8PR03MB8274.namprd03.prod.outlook.com
 (2603:10b6:610:2ba::5)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|LV3PR03MB7586:EE_
X-MS-Office365-Filtering-Correlation-Id: bb9bcad0-4a30-4f0e-4f3e-08df0505f1eb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|22082099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	riVnkfaehZ6s1HWbWgQFdHZQ3wu9MxpjY7g5zggsnH1Z+tPWbUPTde56KlDWr8QIaT/vknSf5VBPcjo5WRuqYLJJ9eRlvDSINlcVHx17kjocr+Dn/EFuMQSCYETJ1r3uoVMUQg63es/gXzBy63ZDH/JObTSKceIZ7Dmraz7NK05Eh1lUL+fkjUB056ScCKmmahzMEAz5FkD4wUNMnp0SOuhHRshC4M97EsKKxzhLVUKzA1xteFK9SmMxDFq8BHN7c6q5CMmxnJ0OgqRtGORhVcMHuPgo3Jm3HO9K5BWkw6T36+a9UqNyzsRaAl55xtcIEMDdNbKEvtFyHz8EuT5ujCJC5aibPB/1pNelMNSMNdMY55iLF1MeHxWBiX4VxAdbL8waFQpiyYueOAnrn+OBVk+qXI5Orz4AqMRm6vUYBhykDqIvxKylaAODKZpR5k5HgQBFbQcCr1w72BNEcDFTKF7yciL48D3hTrO++cc3zfQdL9EniZUgRh3RiE2IiSZU7dxaPbQJflyqjEVMwVOumCZd2P4yC+Pbllr3Rby9FXtM7WqRjIjQlhz2rvOa0ME7Enai0F2NDpAzjL+VQGSnd4TF3EyMVy9/CKYnWGhEKuOY4KEpxFzW5JjAuNJF88nr3+0Ft8l0kVVoAsJnPKbX0YGTjwvI6lh1ZLIvjxxk1DM=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?cNXhiw5AlqOkv/lI8+aQq4KI+fh9KW3/JeaPhgP9EOBFUOrc+Kevocj0s3Uv?=
 =?us-ascii?Q?kJo6Mdeqkx9GZMb5UuWJGZBF6AQQpqYpumzO++XDLs1Y7T7lOtGDsVkz9dwZ?=
 =?us-ascii?Q?lAP3iPGMq/mck+uVmfJ4OfE3BK7Q6UsJlKub3T4jCPfa8qF3dqcXEgp9rk9Y?=
 =?us-ascii?Q?qBN7tzKPm24sDLmcyc0Aj2SlZT5u9ZlOPDkHDAbUdpwZWkT7esxxC1CMsePS?=
 =?us-ascii?Q?QSFWvZP49GWRY4sep9JAiLuyB7JmcgsQQlWUzmrnBsHYkxoZdlDYRJ2HhV/W?=
 =?us-ascii?Q?2roFKFCChuv9TYZVeIa5oSobfImGGEPbZ7ulJY2jSTAMczVw3Ip+gHOh9NyP?=
 =?us-ascii?Q?aanBzyeSxh5KM8joHVGlUOK5VLikbByURu+ZPaMPKqn597QWPuh2JdaqSk2I?=
 =?us-ascii?Q?2y+0d9vbaLL+DrFlR6amLLgk3e6Gcl/ueJugp6+eofxgnjy1NzzdFmLb93QN?=
 =?us-ascii?Q?rVponLgbdvqtBCGkJUBrG1K9g4kKXQ/AxXHfcatT9RI1K8rnuZ0P51b6kIDt?=
 =?us-ascii?Q?PUD72RlbN+7YlqRnIqWzjWRffFTkz+10a/1llK62hy68ZLzNffgqIdYGuKvs?=
 =?us-ascii?Q?UitD50ETXq4TQ/kA8TP4l15PjF3TGOLsrfvgLMg9BWX3MCnaTtPQ5wncpn04?=
 =?us-ascii?Q?QMpo5VaxxpVBilG1+3mNZlIm9NwO6TbuD9MqNI4HNEfg2AuXaA2AjgVRX/Do?=
 =?us-ascii?Q?iNBIcBJLvSOlP0k/FIJ75ZXfqCinFtnpQ3Gjc+rV4tloSB/8ke02Sq3dHO2h?=
 =?us-ascii?Q?AwthzvmISiG9uti3mIXLuMl7YP71DB2xfpLHN/Mr8hAfcyvJYu8IZ5u8unfs?=
 =?us-ascii?Q?9L5EwmsdVcl39quYdHxsHhYHFMkz31IQJKKhZymbW/VP038GYs0gygWPl2tF?=
 =?us-ascii?Q?I2QMrk/6CF8H8g7rPcEEqybGHj2kE7TRw3b++d/QRGqa3k9+2pOOEUqVVYT4?=
 =?us-ascii?Q?7qy/HMAgTVjYeR/ZgjQpqvxVXBe2buRG5UdnWcVC8kbt3gVnxYxkHE1TDrnX?=
 =?us-ascii?Q?PHrq2nVDFERmOoqR1PiQ4b9HX1F/vq5T0E3FZV93FRV1bjTXa1RafDhSFXyg?=
 =?us-ascii?Q?cUx87O70rY79vA9EKlT8gibzgKkuN1hWe64fGcyEf/+pTw7cqURuGCIZaPwj?=
 =?us-ascii?Q?Jz3YJArVu3AdsS2MxB+T4X+Kufme1mskzedrzLc/6kAAPnVFWTG+pPUx3xwy?=
 =?us-ascii?Q?9cY1qIG2Yc/+QcPGNzcojuyt8lCml9Pj2/SeYXk7ue5nwHKJO6nkiOfdwmRP?=
 =?us-ascii?Q?6zIr73fxdqhO2usT8TUO9iGFzzTqJgHCJCR8Qkg2Q9dZCKt8bcEfbvum+6PG?=
 =?us-ascii?Q?dWJVsmYjrm4t/u5USJF+pOUIxMWScpOYv27XaIAj7ZYWdeBo4PBDlVmL4vI4?=
 =?us-ascii?Q?hvqjSIz3kd4BE9MiWSkniWwgQQpZo0rH7Ulg6WrN/r4qg2d2y+QJboJJcmnw?=
 =?us-ascii?Q?AncCN8sPO6UYrxmTYS+1D6xZAadvN5HVtu23efHCgFeJ4+VAfXcJkHsnOVVU?=
 =?us-ascii?Q?wkqVBwIwOSNPs/tZh/yx3TrvqoEZzGBpKGMXyQB67t6fWgw46DrV7ru6XopF?=
 =?us-ascii?Q?pVXbngvn/Z4SYWsVR09CmmpA/D3h7x92wPPzTgQnFFzBQSarGQag5rmJhGMQ?=
 =?us-ascii?Q?+wg46aw2wMSwhhNGsvj+flXU2daACPacSPAeIkPMTJPRSboTEm1kGoiUDChf?=
 =?us-ascii?Q?OPW6THt2yxFKTkgoJ6H0zF7uicUmKsVOLPROiVOngt/ISkULxJjkiWahYv3S?=
 =?us-ascii?Q?YUW7J7oulPBC0gMj9+lwC59DA4eefHY=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bb9bcad0-4a30-4f0e-4f3e-08df0505f1eb
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 13:12:00.2233
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KqQ3IZQyT0mmvl8Rwo1vQe/Iwl3cYgjZUvA/lEChDgk1xfCjhWKlTp+9aOxCdS7AKKU6uNeRY5Ib8aJNFDbX9xLcNc9opPPqRaLDp334k3w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7586
X-purgate-ID: tlsNG-42698a/1787922725-194C39EA-6744AD1F/0/0
X-purgate-type: clean
X-purgate-size: 3830

In direct mode, the timer asserts an interrupt on expiration rather than
using a SynIC message. It is useful to implement this since Windows 11's
Hyper-V can only use synthetic timers in direct mode.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---

Should this use a new Viridian feature bit or is it OK to use the
existing stimer bit?

 xen/arch/x86/hvm/viridian/time.c     | 25 +++++++++++++++++++------
 xen/arch/x86/hvm/viridian/viridian.c |  3 +++
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 082528dc9416..2b0ac3eac963 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs)
     set_timer(&vs->timer, timeout + NOW());
 }
 
+static void stimer_deliver_direct(struct vcpu *v, struct viridian_stimer *vs)
+{
+    struct vlapic *vlapic = vcpu_vlapic(v);
+
+    if ( vlapic_enabled(vlapic) )
+        vlapic_set_irq(vcpu_vlapic(v), vs->config.apic_vector, 0);
+}
+
 static void poll_stimer(struct vcpu *v, unsigned int stimerx)
 {
     struct viridian_vcpu *vv = v->arch.hvm.viridian;
@@ -242,9 +250,11 @@ static void poll_stimer(struct vcpu *v, unsigned int stimerx)
     if ( !test_bit(stimerx, &vv->stimer_pending) )
         return;
 
-    if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx,
-                                           stimerx, vs->expiration,
-                                           time_ref_count(v->domain)) )
+    if ( vs->config.direct_mode )
+        stimer_deliver_direct(v, vs);
+    else if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx,
+                                                stimerx, vs->expiration,
+                                                time_ref_count(v->domain)) )
         return;
 
     clear_bit(stimerx, &vv->stimer_pending);
@@ -372,7 +382,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
 
         vs->config.as_uint64 = val;
 
-        if ( !vs->config.sintx || !vs->count )
+        if ( (!vs->config.direct_mode && !vs->config.sintx) || !vs->count )
             vs->config.enable = 0;
 
         if ( vs->config.enable )
@@ -583,8 +593,11 @@ void viridian_time_load_vcpu_ctxt(
 
         vs->config.as_uint64 = ctxt->stimer_config_msr[i];
         vs->count = ctxt->stimer_count_msr[i];
-        if ( !vs->config.sintx || !vs->count )
-            /* Reject enabling with a zero sintx or count fields. */
+        if ( (!vs->config.direct_mode && !vs->config.sintx) || !vs->count )
+            /*
+             * Reject enabling with a zero sintx (if not using direct mode) or
+             * zero count field.
+             */
             vs->config.enable = 0;
     }
 }
diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c
index 90e749ceb581..99192e8d077d 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -78,6 +78,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS
 #define CPUID3D_CPU_DYNAMIC_PARTITIONING (1 << 3)
 #define CPUID3D_CRASH_MSRS (1 << 10)
 #define CPUID3D_SINT_POLLING (1 << 17)
+#define CPUID3D_STIMER_DIRECT_MODE (1 << 19)
 
 /* Viridian CPUID leaf 4: Implementation Recommendations. */
 #define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2)
@@ -185,6 +186,8 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t leaf,
             res->d |= CPUID3D_CRASH_MSRS;
         if ( viridian_feature_mask(d) & HVMPV_synic )
             res->d |= CPUID3D_SINT_POLLING;
+        if ( viridian_feature_mask(d) & HVMPV_stimer )
+            res->d |= CPUID3D_STIMER_DIRECT_MODE;
 
         break;
     }
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 13:12:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 13:12:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402024.1637440 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwN8-0000dD-HQ; Fri, 28 Aug 2026 13:11:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402024.1637440; Fri, 28 Aug 2026 13:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwN8-0000d6-Dh; Fri, 28 Aug 2026 13:11:54 +0000
Received: by outflank-mailman (input) for mailman id 1402024;
 Fri, 28 Aug 2026 13:11:53 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wzwN6-0000d0-Vw
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 13:11:53 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzwN6-000rFV-Al
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:11:52 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a9188f7-2eae-0a2a0a5409dd-0a2a45038b1e-42
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:11:52 +0200
Received: from [40.107.209.9]
 (helo=PH8PR06CU001.outbound.protection.outlook.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a918916-fae8-0a2a45030019-286bd1092167-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:11:52 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by LV3PR03MB7586.namprd03.prod.outlook.com (2603:10b6:408:286::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Fri, 28 Aug
 2026 13:11:49 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0360.008; Fri, 28 Aug 2026
 13:11:49 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zShWBNj2jIDMcg8vUJ/huLUS1IJ7prZrRmWOAaIboEpdkNxCigd+Q7e4dyAoENBLf42n98DKGGe2gp2fxOhhtfE9WGchn2hI0yYiI8moS0CWi7RgXUvzbQH1Fpbgn9DmOSbs33RkWiK2EhPbCiBmDYaMkmFzfL5XTSzM1P0fMs04OiV0tx3PDi6PSY44V71NvPkZCiHh2YyDBx7y2zoGIwjdV9+6dcDc+sA202nzhb+uu6x6UZfD8ZArUdNAnTWDw/kRcd5x0HQ6y2aw8GaRv7Lla/WxWJEGL5x9ZapecH+fh5opkEQZ16Kwz4nutedqqRkF3+bUm9/z5ngN45EVBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=m618uZvrNNW+v72teHEjrdAKqzSLZK/Etee0z95QFx4=;
 b=O1Zds4Vv3c3XTt4LGhCrS9jv4G4/Kend6UewnwEOy3sG75OdaT9S22Wq7JjFnIuwOq/31s6Dfu3hKv0jw1tB+iKGGuumHjHknGzBJW2RPA24v8b6TYqrXD5ogMbGRVUmgWdDWSaeMnM7zsJbAnYct31vzLMhnCzn6Sjl7GZBF/d1bLraYmfpjOoC96JQReqg318RctAHMDcPe/cKdYOnvrHmEwtm23iC6VkOG/wzm5EN0/68kz/B2uyVE8QaZEfHITjLdqlo66tRLC5jDmlrf7cFP/jl7GoDQjgJAiKWVk12SGek1Ms3jbbUSYEmoRTWJN9Ry5/wQntQHKGnm4oljA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=m618uZvrNNW+v72teHEjrdAKqzSLZK/Etee0z95QFx4=;
 b=bfkWfyPRn35FOlVWT4aaca1+HUR90OE0jHDxjvlzjSp4o9VyJ5r1R7p93EjFv7fC5V1gD0pRNXNqvQogScezFqUb/l9gtIGUe7K/X7qjpRakzlHZDUAUynaXJFmRJLXcjKut3H5vAm1ZBCVW092dWk30gZn+0U1rtLiu3b/hEu0=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
	Paul Durrant <paul@xen.org>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v1 0/2] Viridian changes for Hyper-V as a guest
Date: Fri, 28 Aug 2026 14:11:40 +0100
Message-ID: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.53.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: LO4P265CA0151.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2c7::6) To CH8PR03MB8274.namprd03.prod.outlook.com
 (2603:10b6:610:2ba::5)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|LV3PR03MB7586:EE_
X-MS-Office365-Filtering-Correlation-Id: 0d16f6c7-8e87-4b45-116f-08df0505eb4f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|18002099003|11063799006|56012099006;
X-Microsoft-Antispam-Message-Info:
	4Bov6t2UlxWIbxm3A25YvQFWrWCoyJp9rICs4Zo7jVvxrq/Z9VmQt+U/JGifsJvyuWSJHMHK2ZYVFpIDrb3qzXLuOFjSDe3+eLGvinOMsQ5orX3aWEqxWc3jSTQSdR9aIVizSKIZf5wpxzshaGnUGz9vBHu59vQmIelfNSgUJ9s9yNxYCCBhvHbJHfSdHLpXH/j7m7vCSv5/u1/XV1cUlncoilXHs3Mz8OmAg19TaoxMVvmU2isOtvC5Ll0C6jXIBtfSdh4kKH6Ok5WXJqBWGxZ+PZXmJWHS30XaFjxa5Qh1KY4J7k7YXlhkv9oGkd6ASp6VsdxG3Mc8RkWyoV5+ybz3QhGSVcagV2ioSy4eugIkr3qz7eRFcHugs3Thf+5bsGcIk8UVYwyoLM9ur2bSuqp6b1iZTmkGQI1jIVwQemQheNHsywHz+/45Seihelv7RptdyEedXtPrAyb/HfPi60+J+qojIWpB23V1r9d9tByWTBXe/H6Mzpa9lmp4CjdvLgna4Mj17xXOEwSslu4NMy/ak8zSKKmxc5A2kSUj9qXPsh1PXib4raf8i2bX5P1hBimzaIWbqDml9moxnDdY2tjbrwESaSKhQApEL8tYTR+TeOaY96+G5dimXnMnoIRFG1g7U47M8RA63j3b0saIsLO02YvjRr673g2+3HzMx2o=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ie6AZZYPzCEjGg1YbZvlQN6KQTZFi68QaikTg8nkDf5ryc+YnbrZrzhknuIQ?=
 =?us-ascii?Q?x7SMlAmJOX+cpgfUHrX//Tegc0W+9ZV9RVlaLrt5zzwgyTjXnyMCJ/vFfgMo?=
 =?us-ascii?Q?HGLCzzlkleZHFskGNKQDdRJWCe8LQN/goviHDlG9XHqma/tps1Yx0z4/xPk+?=
 =?us-ascii?Q?fu6YeSjPG32q5jQqN2M93caFuYfsfLVJ9mf+tP+RyjvPAC07hrdlrN+KC6Cw?=
 =?us-ascii?Q?ZLRtt5i0NP1Ota7c/WUo56VkjdlMaPwf+qdYyEqzaNS+Z89xb22Qh3pzm7fv?=
 =?us-ascii?Q?5QXsiI0vNCkfZJqSMou1czPVmJJyQ4Q6/RNaPuxabnTLo5jzloh1V12qxKRV?=
 =?us-ascii?Q?9bsLvpKDux//kyboS07EA45rs89YwBvnDXkSbnZtNN3N+BT5vLxYr3VHzzfr?=
 =?us-ascii?Q?3NtBj3PbBYVBIYw26+DtFhlbqLMjhgvfbW5kiVCF1fbZoWXp9f6PIJK+tV7p?=
 =?us-ascii?Q?zRcR5TjagUVCEy5rvSeJ5X6EFnhcLNpIl7kGnSyzg/yVTWTgcUUqiOM68rXC?=
 =?us-ascii?Q?8YYfU/bQiAYj/zbbebrDrrf7lGl+5Cc1Re8JryzEjfALDpeqR3V68Qsyk0X+?=
 =?us-ascii?Q?vLytza3vy+ToiMxHM2FJiwhgT/UcPiYLzhPgCzN5DFxArc29hKGXYZ2z3lH7?=
 =?us-ascii?Q?Cz7IprWzYoqA7ccSFYXYnHkKU6g//E65XFSE8CH5n+w1/eP11r0I041nrUHB?=
 =?us-ascii?Q?OxoZT6MtkWHfYqs/7KokrrABlqd1sElbidzNObAudM3OupL8rpV3YUic1sTC?=
 =?us-ascii?Q?Cl4BWcUbK5Hyi9I9/+WeO6rSifpzC2WAwUhqdCFIAqMcuWrFLeiHYLBHK2OJ?=
 =?us-ascii?Q?1rGSqEYsHByL/brX7amseb+Y9mmRXsibG1FrMntALGdu8Fsnlf+RE3eC6SnR?=
 =?us-ascii?Q?nmZuYDjazNX3BllPRSeR0+ORmG8kYx2pX7JHeHgavGb05dlgBjItOEGMSIZx?=
 =?us-ascii?Q?ZDk3xl/1XOt55vdAC+djCkXYyAykwlIzdEvIKtTpZY6w+rVNZnBuezBEwjHE?=
 =?us-ascii?Q?wT7UkevAW5bFXudDyYlywZosOn/TEp8rPzNXiF9uz0KWEB+7mq/edCq4BOmR?=
 =?us-ascii?Q?HjYoX0qBvYrnRgPe4JDy228oXLcISHYQzAG5UzwznH4kjBnSY2wqSH2KlG5I?=
 =?us-ascii?Q?Y2xPVgeTSnIfu69Gnq6jAhV+wqMhH2oFu4nwnAaNKcc6kbwTEn1jrCOGulwq?=
 =?us-ascii?Q?gHCiG4aZORGX7/NKaBijRLhUWHmG9PinkQ+TJA2BjFTnJw/AUdLasn1gswUj?=
 =?us-ascii?Q?8gFd44noI8ucxTd3cJnw6JYVbxKXAbkuAgFP1eC1d7D0PjsCcTfpLQn7kU3e?=
 =?us-ascii?Q?Ok+RHo30rPCY1JsBZBScbLiZniVjMI8LhjrZhwsI6Yb+2PPznBqryx1ISzzz?=
 =?us-ascii?Q?RIUcCIfKDgGuOLjdR/JuAbFDarpcUzAL358SwgM+nfxQjlxaXJ6/DjzQ5/JE?=
 =?us-ascii?Q?4ROjO5yqHewYs7n8pzlEu6C5qA4KsyjLcKNn1EhpxMoz1EmkQTkWe3/lyVQn?=
 =?us-ascii?Q?235+YK2GFt/H0OCyuudxap6GMyejRNzzEpl5zegSMrmGJgcWEQNkBF7pyxpk?=
 =?us-ascii?Q?QvYLhteXouaStAUdnsjO7SbnJELM/p09qT2IECvV1hWXKlrwGuexx2Y+u9XR?=
 =?us-ascii?Q?czYnwEit0kWq7v4Na3edajBLC4SlGzAM3n5YwULpz66rz6rQl7MvzznHCG3+?=
 =?us-ascii?Q?1gXC1/TTvzVLGDqC8VtModi0zt+jiZtt6TMKJ4j3Q4GzKUxt+eRbedJnnVM0?=
 =?us-ascii?Q?bgYRGEN0ICwdnoZfEPo2jw/UJRI6ZDo=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d16f6c7-8e87-4b45-116f-08df0505eb4f
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 13:11:49.1500
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uXBEJZH0ASGc5vQcin1slyxvzC8m8NCfNNLpyIL1VM4hfg6WdVqupO3fqssfFk+mh55rQp0WlfmrPB83P+XGZ/tK0TkpfPBrrjq4tdt8XjU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7586
X-purgate-ID: tlsNG-33051d/1787922712-6D8D54E9-C1BA1F13/0/0
X-purgate-type: clean
X-purgate-size: 638

Hi,

Here are two changes to get the existing Virdian enlightenments working
when running a Windows 11 guest with Hyper-V enabled

Hyper-V also depends on some unimplemented MSRs to boot, but that will
be addressed in a separate series.

Thanks,
Ross


Ross Lagerwall (2):
  x86/viridian: Workaround Hyper-V GP fault writing to MSR
  x86/viridian: Implement synthetic timer direct mode

 xen/arch/x86/hvm/viridian/synic.c    |  3 +++
 xen/arch/x86/hvm/viridian/time.c     | 25 +++++++++++++++++++------
 xen/arch/x86/hvm/viridian/viridian.c |  3 +++
 3 files changed, 25 insertions(+), 6 deletions(-)

-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 13:15:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 13:15:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402045.1637465 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwQQ-0002Yd-FK; Fri, 28 Aug 2026 13:15:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402045.1637465; Fri, 28 Aug 2026 13:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwQQ-0002YW-Ca; Fri, 28 Aug 2026 13:15:18 +0000
Received: by outflank-mailman (input) for mailman id 1402045;
 Fri, 28 Aug 2026 13:15:17 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1wzwQO-0002YQ-Uo
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 13:15:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzwQO-00CZQL-BS
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:15:16 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a9189dd-bab6-0a2a0a5309dd-0a2a4502a092-28
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:15:16 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a9189e4-6ca4-0a2a45020019-d155dd33cd10-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:15:16 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47c2b362ee2so680904f8f.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 06:15:16 -0700 (PDT)
Received: from [192.168.1.109] ([85.107.101.249])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbac4f9esm3360865f8f.11.2026.08.28.06.15.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 06:15:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787922916; x=1788527716; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=qI9BZMPJnWaO6QznJlQwezpkXYEWqejYHEfwRS0f2jI=;
        b=BivZe6F2Der9YxjH4JYknm3TVXkdOekmrIqEGgcRQhbKdtOiNgNQTMdIo8TK5FyLJ4
         jtPqBQN7irD1hs1eKQA4i9xPiJkwZmHYSh5XjIzYOYWYxkrkfIiQyelj9Rgf3sZlnx2R
         cWzvzzMtvhMZvLJgoL4pzYcx+HpxO9aV2H5R6xcqpthJNyvKyJAw2mBww1v7raMaCO0G
         SOt6IdJ8jJ34BChaNIfmzuHpQYyUq/xyE1sTbrrXIIwReaBliXOIb5TekNFnG+LhXdmt
         wcxqB1WF9r5v1o20MVPXpLLTlbD/bfOtmIBoRKpzmp3sP38gBagupelBE4QgLTJz5u23
         zqCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787922916; x=1788527716;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=qI9BZMPJnWaO6QznJlQwezpkXYEWqejYHEfwRS0f2jI=;
        b=MiAbqffAexhIEq63SgAnc9iOsuAHCxSomYzDB/8Rg8GM89988sf7xYHEMFXde8sRs6
         BBfTqGLnFKK49MAGO0Qe7UNe60YmXYN08fR9zodH8jqWagtnAo0LNbJABELh23upZ/8s
         yhSNIC7Y2/kpGEKJHqPudyO9O0zNnZvD15GIyQ1CMIwGbTZVTFiieuVGRJFb19ETBRsS
         G0aRVvhUrXXsJ8UrClHSDzO9flsQAqiJeDPxCgYzufRxBuuaj+3Q8dDvM9XInMpyWIE6
         tConXdIZoLEgTEA2zGlD2vgjaeADny4aTHmaB8cuTcqr+A/sUkZ7IrZunXb78Glqa8Fl
         Wn7A==
X-Forwarded-Encrypted: i=1; AHgh+RqiTyrzFymuae10iUuyenAGUSYs0xZugyaCac7H4cJCWfBRmDkjETw3thm2nHT+WtBFYZlnCgHvAcQ=@lists.xenproject.org
X-Gm-Message-State: AFuF++kNcsTBj6noF/62/bl+Oz7pTJVNLv6tqNvhDUWDAiLpjpQGyQBu
	FXz2VcvhVbG0cM63MXUTjV1Rn+JFkt+xOTLItqcvx3jkzRNd84Dxp8ao
X-Gm-Gg: AR+sD11QA2/TTSYAlooWZkYlR6wclcAZoFAmhOz6UbouJ5Jba1Wp9GVpfeg4XFq4Uwu
	/Xm5wufyTnM20YfRQDmOoukzn8EDmK8SELNtVLfW4G6/XC5AgoLukBM9Tjsrkq3n8fh6WBZIZS0
	89OL3pPQFCmMW998ewPao1CemqvFyr5j7d2hBBKEjqzT82Anl6l4BhFoUUkjQVBoJBNFb9hiTSC
	iwnYzQ+SyxuIXSglgwuOiD2BuSuvBHBOnSoQG6FqPDkVLb9L0zXRLs0MPSSi9xtrNc4qDElGM7k
	u6Eh24KV2uxSDasxZiiV0Wsq1ZRse+G4sM2s9zPWLEjR7h94Xsu1yrc0rP7rI3UJn5joZ0VQI/9
	1en1i8BXxGQ6Fo2AmvJa/VlGqxR7Dk5lQyEXFoMdHahXe7bb7yDSpsxY7JBG6jJU7dvuQtbAFYS
	PzsmMQoshV8iBjBGVAdPESbq4wkFs5Nud4OqVXPbAdOBypH2f3M3y56vZf7MnpzMJbFCfo
X-Received: by 2002:a05:6000:2f8a:b0:481:5021:33cd with SMTP id ffacd0b85a97d-482f799da69mr9775018f8f.3.1787922915557;
        Fri, 28 Aug 2026 06:15:15 -0700 (PDT)
Message-ID: <7e146962-b030-4d61-ae6c-21b9af1274e0@gmail.com>
Date: Fri, 28 Aug 2026 16:15:11 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in
 sched_move_domain()
To: Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-2-frn1furkan10@gmail.com>
 <0c4e9bb8-f2f1-4a33-8050-1ebc311f46dc@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <0c4e9bb8-f2f1-4a33-8050-1ebc311f46dc@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787922916-F24B62AC-42AEA770/0/0
X-purgate-type: clean
X-purgate-size: 2723


On 8/28/26 15:45, Juergen Gross wrote:
> On 19.08.26 07:15, Furkan Caliskan wrote:
>> sched_move_domain() derives the number of units to rebuild from
>> d->max_vcpus, which is fixed at domain creation and never rolled
>> back if vcpu_create() fails partway through building a domain. So
>> d->vcpu[i] can be NULL for some i even though max_vcpus still
>> counts it - this happens if sched_alloc_udata() returns NULL.
>>
>> The per-unit loop doesn't check for this: it sets
>> unit->vcpu_list = d->vcpu[unit_id] (NULL) and hands that broken
>> unit straight to the destination scheduler's alloc_udata(),
>> which assumes vcpu_list is always valid and crashes Xen when
>> it is not.
>>
>> Reproduced by building a domain in a non-default cpupool where
>> vcpu creation fails partway through, then destroying it.
>> domain_kill() moves the domain back to the default cpupool via
>> sched_move_domain() before actually destroying it, crashing
>> inside the destination scheduler's alloc_udata() (seen in
>> Credit2's csched2_alloc_udata() -> is_idle_unit() -> NULL deref).
>>
>> Before building a unit in sched_move_domain(), check whether all
>> vpcu slots belonging to that unit are populated. If any of its
>> vpcus is missing:
>>   - For a dying domain, skip the unit allocation.
>>   - For an active domain, abort the move and return -EINVAL to
>>     prevent running with dropped vCPUs.
>>
>> Fixes: 70fadc41635b ("xen/cpupool: support moving domain between cpupools with different granularity")
>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
> 
> Sorry for realizing this only now, but I think this problem should be
> solved completely differently.
> 
> Today there are multiple places in the hypervisor where vcpus are being
> setup via vcpu_create(). For vcpu-ids other than 0 this is always done
> in a loop with ascending ids, up to d->max_vcpus. Whenever vcpu_create()
> is failing, the loop is terminated. The only special case is the idle-domain,
> which will never have your problem.
> 
> So the easy fix would be to:
> 
> - have only one function vcpus_create() creating all the vcpus for a domain
>   and use this function everywhere instead of said loop
> 
> - in case a single vcpu can't be created by vcpus_create(), d->max_vcpus
>   should be reset to the id of the vcpu which couldn't be created
> 
> This will avoid any potential NULL derefs elsewhere, as vcpu loops will
> just be ending before hitting a NULL pointer.
> 
> In case you are not feeling comfortable writing this patch, just speak up
> and I will do it.
> 
> 
> Juergen

Agreed, that's the better approach. I'll take it on and send a new version.

Furkan



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 13:34:59 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 13:34:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402062.1637475 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwjM-0008Cp-WA; Fri, 28 Aug 2026 13:34:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402062.1637475; Fri, 28 Aug 2026 13:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzwjM-0008Ci-Sz; Fri, 28 Aug 2026 13:34:52 +0000
Received: by outflank-mailman (input) for mailman id 1402062;
 Fri, 28 Aug 2026 13:34:52 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzwjL-0008Cc-Tb
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 13:34:52 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzwjL-00EmIT-2U
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:34:51 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a918e79-2eae-0a2a0a5409dd-0a2a4507d586-6
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:34:51 +0200
Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a918e7a-b4ea-0a2a45070019-d155dd31e449-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:34:51 +0200
Received: by mail-wr1-f49.google.com with SMTP id
 ffacd0b85a97d-482ea739de2so701431f8f.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 06:34:50 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbac7c01sm4087340f8f.14.2026.08.28.06.34.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 06:34:48 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787924090; x=1788528890; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=mOYOwqqbnUUvC64wDruE8UCb6JVklIemNUSnXaPcJDA=;
        b=a22/YHfVhHXI/nsLA5av4q7LeIfFOSA4n+FSVhPHiCONwj4pWUGpzldzJjpm/CZZMa
         uU5ZySDfqq38Vpe5OT6R4FGZeQ1YqVISPOcaiSH1mk+vdlZmN6LhUEVFVb/pPMrNgrfs
         PQkqqVsyKgTUe+lUnb+p4sNLFRCj7Oe34johrsVqlG4Pge80kBLi/AD4inCMVXehcbN/
         QTnTzMPEsQx7MPmiDVApgNPXJ8WUsmRAXK523K88GotyBUBdhlfdCpRv7m4CF8WAYTSr
         02dAC3L0PoqivEk/tlU2UsoUc6WFLXZbrDxwLPhEG2UxWP5ud+N8EEiBajApfwoU+xW3
         s0xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787924090; x=1788528890;
        h=content-transfer-encoding:content-type:in-reply-to:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=mOYOwqqbnUUvC64wDruE8UCb6JVklIemNUSnXaPcJDA=;
        b=Kz9DWkTSb0jgch6AikWgDptk0yckkG/lR6Ies3Q9Q6Frabg72ieBMJfQEGAlOdtpQz
         TpvSrMyg58kEKHGbz+DtB0SBC47PdqOFQqn9P8waCrZtdHeELMKf25wKZ6Y67RHwx4lA
         fNJlKnhOMNM74BFMsXTZj5k7Ty3jRzP15mbBLhvD3Xwz8dsv5kqN1ZrEL7rtsbMpjGni
         n2r1aZXGnnx+qAbWk73vauEDwDLv0NN+G+0dPwkc3sGxPqNdFZnVgU5L/710FRRIB0/k
         rlzL21vgG8/x3K/rIaqrnBLdoNiRifoP1vCci4MEplDIBj+Toq9TOmDC7Rf3xdEgBjOV
         MGvg==
X-Forwarded-Encrypted: i=1; AHgh+RqUaSolGjeKRP7Hecvxy2esWWtxqblegNxebnRekP098v7FbHbsLc1bUQb6B9uHH6/ningm7T23e9A=@lists.xenproject.org
X-Gm-Message-State: AFuF++lotOq4MbXWXoyMoXzNAAOIu1qTCx2FHYfY0ttWLYizF3YLrlYL
	Lvpbcgyl48W3htrfpGIHuqHP05RfMjEM/8+H5pXoBR+7ZQ99yhZRDj1y
X-Gm-Gg: AR+sD13IFH4I4eoK6PeSA3JPlrdTbWJqi1JEKt0q83GL58GRHZhJFhUMaaOg9rceleO
	8AFKWJ2IshK3qtDwl+Y5bN9vUuzMl7vXeAetOVTJ2Me0Ud2AY4rCLG3ANZf0a9OgwvIR/4WOvXV
	gfBLBQXBvkVFMivWKkwMPk3QFFQCXvZsqP+MT1jh3nhgLWMMWeEzYIPQxmLGbBHgt/sBpoT/9Nv
	jna28FFf+Ar/GCB8iWjUVcppD7sFIjgl/Rn6AEP1jR1T1+NfgzSDvM2uUR61Jyt5fzyre00Fnpf
	1yBqflCRxaSeHDugiFcLibnq6yVyJcN1d70TbMOtAOWJ589LlKOPdQQD+IVFUUGpOEJzGXTtR6g
	VRPW9HKemkomRDhm4xg6nMdyC432H43ZERxr0V9BHmMLXfBu8RPeIsqQCD+dREDuAgS56Fd5hsX
	7kSUw/ZROQyjibCNKJ3Ueqr+GxELpCjEtvahVXu1Vc2H7R43EUBo0Ds+9GHVJlRfEPxALj+1RyO
	M8kUZWCrGr2l3GyqIUz5pT8uCr4MQGYj9XG+sizdw==
X-Received: by 2002:a05:6000:4810:b0:482:e451:681f with SMTP id ffacd0b85a97d-482f79c9430mr9907281f8f.10.1787924090247;
        Fri, 28 Aug 2026 06:34:50 -0700 (PDT)
Message-ID: <ec69b941-2648-4c3f-bbee-95d4d56fb543@gmail.com>
Date: Fri, 28 Aug 2026 15:34:46 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH 2/5] xen/riscv: preset A/D bits in Xen's own page-table
 mappings
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@vates.tech>
Content-Language: en-US
In-Reply-To: <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-ef75cf/1787924091-374D3AE4-6A9EAA8C/10/73395122804
X-purgate-type: spam
X-purgate-size: 6326



On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> The previous patch made p2m_set_permission() always set the PTE A/D bits to
> map pages in G-stage, to avoid a page fault on platforms that implement
> neither Svade nor Svadu, or that declare both in the device tree. Xen's own
> page tables, built by setup_initial_mapping(), never go through
> p2m_set_permission() and need the same fix.
> 
> Add PTE_ACCESSED to PTE_LEAF_DEFAULT and make it the minimal common leaf
> permission set by dropping PTE_WRITABLE. Rebuild PAGE_HYPERVISOR_RO,
> PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX from that common base, with
> PAGE_HYPERVISOR_RW also adding PTE_DIRTY. Switch setup_initial_mapping() to
> use these macros for its default, text, and rodata permissions instead of
> the equivalent raw bit lists.
> 
> A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so
> update pte_is_table() accordingly.
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> ---
>   xen/arch/riscv/include/asm/page.h | 14 ++++++++------
>   xen/arch/riscv/mm.c               |  7 +++----
>   2 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
> index b465a90325..5c02f64a17 100644
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -46,12 +46,12 @@
>   #define PTE_PBMT_NOCACHE            BIT(61, UL)
>   #define PTE_PBMT_IO                 BIT(62, UL)
>   
> -#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
> +#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_ACCESSED)

Dropping PTE_WRITABLE here silently changes the permissions of an 
existing user of this macro that the patch doesn't touch.

check_pgtbl_mode_support() in mm.c still builds its temporary root entry as:
  index = pt_index(page_table_level, aligned_load_start);
  stage1_pgtbl_root[index] = paddr_to_pte(aligned_load_start,
                                      PTE_LEAF_DEFAULT | PTE_EXECUTABLE);

Before this patch that evaluated to V|R|W|X (RWX); afterwards it is 
V|R|A|X (RX). So the mapping loses write permission.

I believe that is harmless in practice: the entry is only alive between 
the csr_write(CSR_SATP, ...) that turns the MMU on and the 
csr_write(CSR_SATP, 0) a few lines below, it only has to make the 
current instruction stream fetchable so that the SATP mode probe can 
complete, and nothing writes through it. Arguably RX is the better 
permission set for it anyway. But it is still a behavioural change 
rather than a cosmetic one, and the commit message doesn't mention it(it 
only talks about setup_initial_mapping()).
Please call it out explicitly there.

While at it, this site should be converted too:

     stage1_pgtbl_root[index] = paddr_to_pte(aligned_load_start,
                                             PAGE_HYPERVISOR_RX);

Otherwise the patch converts three sites in setup_initial_mapping() to 
the new PAGE_HYPERVISOR_* macros while leaving a fourth one open-coding 
the redefined PTE_LEAF_DEFAULT, which is exactly the kind of asymmetry 
that makes the redefinition easy to miss on the next change.

After that conversion PTE_LEAF_DEFAULT has no users left
outside page.h itself, so it could either be dropped entirely in favour 
of PAGE_HYPERVISOR_{RO,RW,RX}, or renamed to something that reflects its 
new meaning (PTE_LEAF_COMMON or similar). "DEFAULT" now names a set that 
is not a usable permission on its own, which is misleading.

>   #define PTE_TABLE                   (PTE_VALID)
>   
> -#define PAGE_HYPERVISOR_RO          (PTE_VALID | PTE_READABLE)
> -#define PAGE_HYPERVISOR_RW          (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
> -#define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
> +#define PAGE_HYPERVISOR_RO          (PTE_LEAF_DEFAULT)
> +#define PAGE_HYPERVISOR_RW          (PTE_LEAF_DEFAULT | PTE_WRITABLE | PTE_DIRTY)
> +#define PAGE_HYPERVISOR_RX          (PTE_LEAF_DEFAULT | PTE_EXECUTABLE)

Adding A/D to PAGE_HYPERVISOR_RW fixes a second site beyond the ones the
commit message mentions, and I think it deserves to be spelled out.

arch_pmap_map() in asm/pmap.h writes the fixmap leaf entry directly:
     pte = pte_from_mfn(mfn, PAGE_HYPERVISOR_RW);
     write_pte(entry, pte);
i.e. it bypasses pt_update_entry(), which is the place that ORs in
PTE_ACCESSED | PTE_DIRTY for everything going through map_pages_to_xen().
So before this patch every pmap mapping was installed with A=D=0 and 
would fault on first access under Svade, in exactly the same way the 
boot page tables did.

The commit message currently frames the problem as "Xen's own page 
tables, built by setup_initial_mapping()", which undersells the fix. 
Please extend it to say that arch_pmap_map() is affected as well, and 
that it is fixed by the PAGE_HYPERVISOR_RW change rather than by the 
mm.c conversion.

FWIW I checked the remaining leaf-PTE construction sites (paddr_to_pte() 
/pte_from_mfn() callers) and with these two the series covers all of 
them: everything else either builds table entries (PTE_TABLE) or goes 
through pt_update_entry() / p2m_set_permission(), both of which set A/D 
themselves.

>   
>   #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
>   /*
> @@ -177,7 +177,8 @@ static inline bool pte_is_table(pte_t p)
>        *
>        * PAGE_HYPERVISOR_RW contains PTE_VALID too.
>        */
> -    ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE)));
> +    ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=
> +           (PTE_VALID | PTE_WRITABLE));

Please drop the last line of the comment above it:

      * PAGE_HYPERVISOR_RW contains PTE_VALID too.

That sentence existed only to explain why the old mask was written as
PAGE_HYPERVISOR_RW, i.e. that the macro is not just R|W but carries
PTE_VALID as well, which is what made the comparison against V|W work.
With the mask now written out literally, the macro is no longer 
referenced anywhere in the function, so the line dangles. It is also 
inaccurate now, since PAGE_HYPERVISOR_RW carries A and D in addition to V.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 13:58:26 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 13:58:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402072.1637483 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzx64-0004E0-NZ; Fri, 28 Aug 2026 13:58:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402072.1637483; Fri, 28 Aug 2026 13:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzx64-0004Dt-Kh; Fri, 28 Aug 2026 13:58:20 +0000
Received: by outflank-mailman (input) for mailman id 1402072;
 Fri, 28 Aug 2026 13:58:19 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@swg.vates.tech>)
 id 1wzx62-0004Ci-Kx
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 13:58:19 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzx61-00CgJc-TK
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:58:17 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@swg.vates.tech>)
 id 6a9193f9-2eae-0a2a0a5409dd-0a2a4507deda-0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:58:17 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@swg.vates.tech>)
 id 6a9193f9-b4ea-0a2a45070019-b9ff1c23a587-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 15:58:17 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a048a9fec2000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 28 Aug 2026 13:58:15 +0000
Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr
 [90.112.87.96]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id A38C48216A;
 Fri, 28 Aug 2026 15:58:14 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=lRZdUg3G4u3tOKN0hs/abdthoKU5+oYADq84b7LHbvs=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=M7THchgEr3UUxKeBfWqveVWP2BAH2Wx8Zxogql4cOusfuMbQPRqbYsgpRXgGASvycdxBYYn6k
 Zg8gNvblk4aa8gXtanpASupTbA/l9KwALSu4V3HcN0FQOnZT2kjhAKNPsxvPRKhdObz85RAHYgI
 pv+gRbOcb+gQtkR6l4ue81tJYCKzVNRYXCespGs5wmxuMXYcv++CugGp2UWtn+5m9qKr2B0Nej5
 vyT6qfLW5dTnu0+AnRX48iNRBD3i5ZN8R2XNVUCwtTxLZvTTOs61SsSEBewSPDPLwNgNUmLBOWq
 ylnX4syXJY9o/odqYb8qMaz0TuEkr5/Dm2N2s4lqb8nA==
X-Zone-Loop: 91b9e9ee1b2035c5a8ff0c272e1a2b7ecfab6a91a2ad
x-campaign-type: default
x-transaction-id: 0feef986-6fac-4331-adfd-800c12f1252f
x-swg-uid: 01-08ec6ed2-5f6e-4a13-ad52-461238059692
X-Mailer: Sweego
Message-ID:
 <1787925495.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@vates.tech>
x-swg-bid: 1787925495.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH 1/5] xen/riscv: always set A/D bits at boot time
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <3adf6ef7-8024-420f-935b-17b142c73256@gmail.com>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@vates.tech>
 <3adf6ef7-8024-420f-935b-17b142c73256@gmail.com>
Date: Fri, 28 Aug 2026 15:58:09 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1787925494; l=12681;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=KJtNMT9z4ZVN6G6B4G6Cm5dg5mycncawDT60NCOuopw=;
 b=qGhKc4GJofFN6KHp/Jb6OXJJVcy4mtfgEbHPom1+GTAabEsizs63Xl3rj0q7XlEm7JKEl8ssZ
 JUb++g5tuSpBJFrw678rAmSeKlfzzam2kEeDoKx+b74+OaGGnROTHGO
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787925494864
X-purgate-ID: tlsNG-ef75cf/1787925497-358C1AE4-4D2230DA/0/0
X-purgate-type: clean
X-purgate-size: 12685

On 2026-08-28 12:59 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> > Always set the PTE A/D bits at boot time to avoid an unhandled page fault
> > on platforms that implement neither Svade nor Svadu, and on platforms that
> > declare both in the device tree.
> > 
> > Rewrite the comment to enumerate the four possible Svade/Svadu combinations
> > (inspired by [1]) and set A/D unconditionally, which is correct in all four
> > cases until Svadu is fully supported (full support requires the SBI FWFT
> > call to enable hardware updating of A/D bits).
> > 
> > [1] https://lwn.net/Articles/980016/
> > 
> > Assisted-by: Claude:claude-opus-5
> > Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> > ---
> >   xen/arch/riscv/p2m.c | 70 ++++++++++++++++++++++++++------------------
> >   1 file changed, 42 insertions(+), 28 deletions(-)
> > 
> > diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
> > index 1cea86512c..11dc289f0f 100644
> > --- a/xen/arch/riscv/p2m.c
> > +++ b/xen/arch/riscv/p2m.c
> > @@ -591,38 +591,52 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
> >       e->pte |= PTE_USER;
> >   
> >       /*
> > -     * Two schemes to manage the A and D bits are defined:
> > -     *   • The Svade extension: when a virtual page is accessed and the A bit
> > -     *     is clear, or is written and the D bit is clear, a page-fault
> > -     *     exception is raised.
> > -     *   • When the Svade extension is not implemented, the following scheme
> > -     *     applies.
> > -     *     When a virtual page is accessed and the A bit is clear, the PTE is
> > -     *     updated to set the A bit. When the virtual page is written and the
> > -     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
> > -     *     address translation is in use and is not Bare, the G-stage virtual
> > -     *     pages may be accessed or written by implicit accesses to VS-level
> > -     *     memory management data structures, such as page tables.
> > -     * Thereby to avoid a page-fault in case of Svade is available, it is
> > -     * necessary to set A and D bits.
> > +     * Svade and Svadu extensions represent two schemes for managing the PTE
> > +     * A/D bits. When the PTE A/D bits need to be set, the Svade extension
> > +     * indicates that a page fault will be raised. In contrast, the Svadu
> > +     * extension supports hardware updating of the PTE A/D bits.
> >        *
> > -     * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI
> > -     *       delegates page faults to a lower privilege mode and so OpenSBI
> > -     *       isn't expect to handle page-faults occured in lower modes.
> > -     *       By setting the A/D bits here, page faults that would otherwise
> > -     *       be generated due to unset A/D bits will not occur in Xen.
> > +     * There are 4 possible combinations of these extensions in the device
> > +     * tree. The default hardware behavior for each is:
> >        *
> > -     *       Currently, Xen on RISC-V does not make use of the information
> > -     *       that could be obtained from handling such page faults, which
> > -     *       could otherwise be useful for several use cases such as demand
> > -     *       paging, cache-flushing optimizations, memory access tracking,etc.
> > +     * 1) Neither Svade nor Svadu present in DT => It is technically unknown
> > +     *    whether the platform uses Svade or Svadu. Xen should be prepared to
> > +     *    handle either hardware updating of the PTE A/D bits or page faults
> > +     *    when they need updating. To support both, Xen always sets the 'A' and
> > +     *    'D' PTE bits at boot time.
> >        *
> > -     *       To support the more general case and the optimizations mentioned
> > -     *       above, it would be better to stop setting the A/D bits here and
> > -     *       instead handle page faults that occur due to unset A/D bits.
> > +     * 2) Only Svade present in DT => Xen must assume Svade to be always
> > +     *    enabled.
> > +     *
> > +     * 3) Only Svadu present in DT => Xen must assume Svadu to be always
> > +     *    enabled.
> > +     *
> > +     * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
> > +     *    off at boot time by setting A/D bits. To use Svadu, the supervisor
> > +     *    must explicitly enable it using the SBI FWFT extension.
> > +     *
> > +     * The Svade extension is mandatory and the Svadu extension is optional in
> > +     * the RVA23 profile. Platforms wanting to take advantage of Svadu can
> > +     * choose option 3. Platforms aware of the profile can choose option 4, and
> > +     * Linux won't get the benefit of Svadu until the SBI FWFT extension is
> > +     * available.
> 
> I have a feeling that the DT-binding-related comment should not be 
> present here, as it explains when Svadu or Svade should be considered 
> enabled or disabled. We should perform this kind of detection in 
> riscv_fill_hwcap() [cpufeature.c]. Then, in p2m_set_permission(), we 
> should use riscv_isa_extension_available() to determine which extension 
> is available and, based on that, set the A and D bits.
> 
> At this point, I think the original comment was better, as it simply 
> explained what Svade and Svadu are and, therefore, provided a better 
> explanation of why the A and D bits should or should not be set.
> 
> So, my suggestion is the following:
> 
> +/*
> + * Svade and Svadu extensions represent two schemes for managing the PTE
> + * A/D bits. When the PTE A/D bits need to be set, the Svade extension
> + * indicates that a page fault will be raised. In contrast, the Svadu
> + * extension supports hardware updating of the PTE A/D bits.
> + *
> + * There are 4 possible combinations of these extensions in the device 
> tree.
> + * The default hardware behavior for each is:
> + *
> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown
> + *    whether the platform uses Svade or Svadu. Xen should be prepared to
> + *    handle either hardware updating of the PTE A/D bits or page 
> faults when
> + *    they need updating. To support both, Xen always sets the 'A' and 
> 'D' PTE
> + *    bits at boot time.
> + *
> + * 2) Only Svade present in DT => Xen must assume Svade to be always 
> enabled.
> + *
> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always 
> enabled.
> + *
> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
> + *    off at boot time by setting A/D bits. To use Svadu, the 
> supervisor must
> + *    explicitly enable it using the SBI FWFT extension.
> + *
> + * The Svade extension is mandatory and the Svadu extension is optional 
> in the
> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose
> + * option 3. Platforms aware of the profile can choose option 4, and 
> Xen won't
> + * get the benefit of Svadu until the SBI FWFT extension is available.
> + *
> + * In other words, hardware manages the A/D bits on its own only in case 3;
> + * in all the other cases software has to preset them. Instead of open 
> coding
> + * this in every A/D bits user, RISCV_ISA_EXT_svade is used to mean 
> "software
> + * is responsible for the A/D bits" and is set here for the cases 1, 2 
> and 4.
> + */
> +static void __init riscv_resolve_ad_scheme(void)
> +{
> +    bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade);
> +    bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu);
> +
> +    /* Case 3: leave the A/D bits management to hardware. */
> +    if ( svadu && !svade )
> +        return;
> +
> +    /* Cases 1, 2 and 4: Xen has to preset the A/D bits. */
> +    __set_bit(RISCV_ISA_EXT_svade, riscv_isa);
> +}
> +
>   void __init riscv_fill_hwcap(void)
>   {
>       unsigned int i;
> @@ -513,6 +560,8 @@ void __init riscv_fill_hwcap(void)
>           __set_bit(RISCV_ISA_EXT_sstc, riscv_isa);
>       }
> 
> +    riscv_resolve_ad_scheme();
> +
> 
> And then ...
> 
> 
> > +     *
> > +     * Currently, Xen on RISC-V does not make use of the information that could
> > +     * be obtained from handling such page faults, which could otherwise be
> > +     * useful for several use cases such as demand paging, cache-flushing
> > +     * optimizations, memory access tracking, etc.
> > +     *
> > +     * To support the more general case and the optimizations mentioned above,
> > +     * it would be better to stop setting the A/D bits here and instead handle
> > +     * page faults that occur due to unset A/D bits.
> > +     */
> > +
> > +    /*
> > +     * Preset unconditionally for all 4 cases above, harmless when Svadu
> > +     * manages the bits (case 3). Skipping it for case 3 requires SBI FWFT
> > +     * which is not yet supported.
> >        */
> > -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
> > -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
> > +    e->pte |= PTE_ACCESSED | PTE_DIRTY;
> 
> ... we could restore the check and the comment we originally had in 

Yes it makes sense as we now manually force the svade extension in 1, 2
and 4 cases.

> p2m_set_permission(), but probably with some updates, something along 
> the following lines:
> 
> /*
>   * Xen has to preset the A/D bits unless the hardware is known to update
>   * them on its own. riscv_fill_hwcap() folds all the Svade/Svadu device
>   * tree combinations into RISCV_ISA_EXT_svade, which then means that
>   * software is responsible for the A/D bits" (see
>   * riscv_resolve_ad_scheme()).
>   */
> 
> I have another comment regarding:
> 
>  > +    /*
>  > +     * Preset unconditionally for all 4 cases above, harmless when Svadu
>  > +     * manages the bits (case 3). Skipping it for case 3 requires 
> SBI FWFT
>  > +     * which is not yet supported.
>  >        */
>  > -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
>  > -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
>  > +    e->pte |= PTE_ACCESSED | PTE_DIRTY;
> 
> I am not sure that this comment is correct. In case 3, we should not 
> need to use the SBI FWFT extension. Case 3 means that Xen must assume 
> that Svadu is enabled. Therefore, it is the responsibility of OpenSBI, 
> or the pre-bootloader that loads OpenSBI, to enable it. If it fails to 
> do so, then OpenSBI or the pre-bootloader is not complying with the DT 
> binding documentation and it should be fixed in first place.

You right, thanks
> 
> As further evidence, this is what OpenSBI already does [1]:
> /*
>   * Assume only Svadu is supported when it is the only extension
>   * present in the ISA string. Svade is assumed when neither are
>   * present. When both are present we must default to Svade (see
>   * the zero reset value of FWFT.PTE_AD_HW_UPDATING).
>   */
> if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE))
>      __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE);
> 
> Therefore, in case 3, the original check is still valid, and there is no 
> need for Xen to support the SBI FWFT extension for this case. I think 
> the original check should therefore be kept as it was:

Yes agree, I'll change that in v2.

> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
>      e->pte |= PTE_ACCESSED | PTE_DIRTY;
> 
> The SBI FWFT extension is only required for case 4. If both Svade and 
> Svadu are present in the DT, Svade is selected by default. To use Svadu 
> instead, SBI FWFT is required to set the ADUE bit in menvcfg, which is 
> only accessible from M-mode.
> 
> Since SBI FWFT is relatively new and may not be supported by older 
> OpenSBI versions, another option is to have OpenSBI hard-code ADUE=1. 
> Alternatively, the DTS could specify only one of Svade or Svadu in the 
> riscv,isa property. In that case, upstream OpenSBI can handle the 
> configuration automatically. So specifically for our case (Svadu and 
> Svade things) we don't need SBI FWFT at all.

So if I understood correclty, you want to not let the option to change
ADUE bits in case 4 right? Therefore, I think we should document that
somewhere to clearly indicates that if someone want to use Svadu, he
should remove `svade` in the riscv,isa DT property.
> 
> [1] 
> https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_hart.c#L171
> 
Thanks for this very clear review.

> ~ Oleksii
> 
> 
> 
> 
> 




From xen-devel-bounces@lists.xenproject.org Fri Aug 28 14:11:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 14:11:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402083.1637492 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzxIw-0007nz-QX; Fri, 28 Aug 2026 14:11:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402083.1637492; Fri, 28 Aug 2026 14:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzxIw-0007ns-Np; Fri, 28 Aug 2026 14:11:38 +0000
Received: by outflank-mailman (input) for mailman id 1402083;
 Fri, 28 Aug 2026 14:11:37 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3@swg.vates.tech>)
 id 1wzxIv-0007nk-Of
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:11:37 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzxIu-00Es1L-Oi
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 16:11:36 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3@swg.vates.tech>)
 id 6a9196fe-8faa-0a2a0a5109dd-0a2a4506b868-42
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 16:11:35 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3@swg.vates.tech>)
 id 6a919717-195a-0a2a45060019-b9ff1c128785-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 16:11:35 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a048b62786000c4f3.003 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 28 Aug 2026 14:11:32 +0000
Received: from [192.168.1.61] (155.223.66.37.rev.sfr.net [37.66.223.155])
 (Authenticated sender: ngoc-tu.dinh@vates.tech)
 by mail2.vates.fr (Postfix) with ESMTPSA id 860F68216A;
 Fri, 28 Aug 2026 16:11:31 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=VxmWDfJtlB0dkwWyCQO3L8MJsVB8b2LRUg0zU+QIpR0=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id;
 b=op9YyOcLbW0TWE5efNR2VbjnxNz3q4981VTx93FGx2CazkjMuXUrSJqF3orc5hLEWHy8kGQye
 jLy30kBet7ZkpGO9zFsxjEfNm4BCG/xg6ojWh4f/oFeJcKng/QI4iZNjAZaedO2LG/c0Hl3Fa5h
 2VN0ZjIJPP79nsXthb7agz71ncGlk7iPaV5zs3Tpg9v7fSQdMbD/9f7o/Ih0bRAtSUQoU8z9MiF
 AXyyyxEVrw4G7RWFT4TBremZQK+P6ElWD5tME4hvaLcETMlrQnCAn5zSBBgBkrg7kgsL83woOtE
 BDthZtJSfhK6ohsxhonPzOsUS71Acc29Rz1ddhnis87A==
X-Zone-Loop: 857b3988dfb4258490c3879eb8e7ee6805148c592df6
x-campaign-type: default
x-transaction-id: 2b57d0b7-c462-4ecc-86e1-2e270c973c9e
x-swg-uid: 01-dfaa2133-006a-45e2-b04f-e1b413a77928
X-Mailer: Sweego
Message-ID:
 <1787926292.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3@vates.tech>
x-swg-bid: 1787926292.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
Date: Fri, 28 Aug 2026 16:11:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] x86/viridian: Implement synthetic timer direct
 mode
To: Ross Lagerwall <ross.lagerwall@citrix.com>, xen-devel@lists.xenproject.org
Cc: Paul Durrant <paul@xen.org>, Jan Beulich <jbeulich@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
References: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
 <20260828131142.3986110-3-ross.lagerwall@citrix.com>
Content-Language: en-US
From: Tu Dinh <ngoc-tu.dinh@vates.tech>
In-Reply-To: <20260828131142.3986110-3-ross.lagerwall@citrix.com>
X-BM-Disclaimer: Yes
Content-Type: multipart/alternative; boundary="-=Part.2ebd.7f5d65a1bc14b01c.1a048b624d1.6e8dfc61ff02ff0b=-"
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1787926291665
X-purgate-ID: tlsNG-16d1c6/1787926295-FD00977B-F04FB893/0/0
X-purgate-type: clean
X-purgate-size: 4732

---=Part.2ebd.7f5d65a1bc14b01c.1a048b624d1.6e8dfc61ff02ff0b=-
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 28/08/2026 15:14, Ross Lagerwall wrote:
> In direct mode, the timer asserts an interrupt on expiration rather than
> using a SynIC message=2E It is useful to implement this since Windows 11=
's
> Hyper-V can only use synthetic timers in direct mode=2E

Hello, is this new behavior compared to Server 2025? What happens if=20
direct mode is not available, does it fall back to disabling stimer?

>=20
> Signed-off-by: Ross Lagerwall <ross=2Elagerwall@citrix=2Ecom>
> ---
>=20
> Should this use a new Viridian feature bit or is it OK to use the
> existing stimer bit?
>=20
>   xen/arch/x86/hvm/viridian/time=2Ec     | 25 +++++++++++++++++++------
>   xen/arch/x86/hvm/viridian/viridian=2Ec |  3 +++
>   2 files changed, 22 insertions(+), 6 deletions(-)
>=20
> diff --git a/xen/arch/x86/hvm/viridian/time=2Ec b/xen/arch/x86/hvm/virid=
ian/time=2Ec
> index 082528dc9416=2E=2E2b0ac3eac963 100644
> --- a/xen/arch/x86/hvm/viridian/time=2Ec
> +++ b/xen/arch/x86/hvm/viridian/time=2Ec
> @@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs=
)
>       set_timer(&vs->timer, timeout + NOW());
>   }
>  =20
> +static void stimer_deliver_direct(struct vcpu *v, struct viridian_stime=
r *vs)
> +{
> +    struct vlapic *vlapic =3D vcpu_vlapic(v);
> +
> +    if ( vlapic_enabled(vlapic) )
> +        vlapic_set_irq(vcpu_vlapic(v), vs->config=2Eapic_vector, 0);
> +}
> +
>   static void poll_stimer(struct vcpu *v, unsigned int stimerx)
>   {
>       struct viridian_vcpu *vv =3D v->arch=2Ehvm=2Eviridian;
> @@ -242,9 +250,11 @@ static void poll_stimer(struct vcpu *v, unsigned in=
t stimerx)
>       if ( !test_bit(stimerx, &vv->stimer_pending) )
>           return;
>  =20
> -    if ( !viridian_synic_deliver_timer_msg(v, vs->config=2Esintx,
> -                                           stimerx, vs->expiration,
> -                                           time_ref_count(v->domain)) )
> +    if ( vs->config=2Edirect_mode )
> +        stimer_deliver_direct(v, vs);
> +    else if ( !viridian_synic_deliver_timer_msg(v, vs->config=2Esintx,
> +                                                stimerx, vs->expiration=
,
> +                                                time_ref_count(v->domai=
n)) )
>           return;
>  =20
>       clear_bit(stimerx, &vv->stimer_pending);
> @@ -372,7 +382,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx=
, uint64_t val)
>  =20
>           vs->config=2Eas_uint64 =3D val;
>  =20
> -        if ( !vs->config=2Esintx || !vs->count )
> +        if ( (!vs->config=2Edirect_mode && !vs->config=2Esintx) || !vs-=
>count )
>               vs->config=2Eenable =3D 0;
>  =20
>           if ( vs->config=2Eenable )
> @@ -583,8 +593,11 @@ void viridian_time_load_vcpu_ctxt(
>  =20
>           vs->config=2Eas_uint64 =3D ctxt->stimer_config_msr[i];
>           vs->count =3D ctxt->stimer_count_msr[i];
> -        if ( !vs->config=2Esintx || !vs->count )
> -            /* Reject enabling with a zero sintx or count fields=2E */
> +        if ( (!vs->config=2Edirect_mode && !vs->config=2Esintx) || !vs-=
>count )
> +            /*
> +             * Reject enabling with a zero sintx (if not using direct m=
ode) or
> +             * zero count field=2E
> +             */
>               vs->config=2Eenable =3D 0;
>       }
>   }
> diff --git a/xen/arch/x86/hvm/viridian/viridian=2Ec b/xen/arch/x86/hvm/v=
iridian/viridian=2Ec
> index 90e749ceb581=2E=2E99192e8d077d 100644
> --- a/xen/arch/x86/hvm/viridian/viridian=2Ec
> +++ b/xen/arch/x86/hvm/viridian/viridian=2Ec
> @@ -78,6 +78,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS
>   #define CPUID3D_CPU_DYNAMIC_PARTITIONING (1 << 3)
>   #define CPUID3D_CRASH_MSRS (1 << 10)
>   #define CPUID3D_SINT_POLLING (1 << 17)
> +#define CPUID3D_STIMER_DIRECT_MODE (1 << 19)
>  =20
>   /* Viridian CPUID leaf 4: Implementation Recommendations=2E */
>   #define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2)
> @@ -185,6 +186,8 @@ void cpuid_viridian_leaves(const struct vcpu *v, uin=
t32_t leaf,
>               res->d |=3D CPUID3D_CRASH_MSRS;
>           if ( viridian_feature_mask(d) & HVMPV_synic )
>               res->d |=3D CPUID3D_SINT_POLLING;
> +        if ( viridian_feature_mask(d) & HVMPV_stimer )
> +            res->d |=3D CPUID3D_STIMER_DIRECT_MODE;
>  =20
>           break;
>       }



-- 
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates =
solutions

web: https://vates=2Etech
---=Part.2ebd.7f5d65a1bc14b01c.1a048b624d1.6e8dfc61ff02ff0b=---


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 14:18:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 14:18:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402092.1637502 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzxP2-0000Rw-DJ; Fri, 28 Aug 2026 14:17:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402092.1637502; Fri, 28 Aug 2026 14:17:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzxP2-0000Rp-AX; Fri, 28 Aug 2026 14:17:56 +0000
Received: by outflank-mailman (input) for mailman id 1402092;
 Fri, 28 Aug 2026 14:17:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wzxP1-0000Ri-4L
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:17:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzxP0-00Ck75-HH
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 16:17:54 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a91986f-e002-0a2a0a5209dd-0a2a4504db00-46
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 16:17:54 +0200
Received: from [52.101.52.13]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a919890-b57f-0a2a45040019-3465340dbcbe-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 16:17:54 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by PH0PR03MB5912.namprd03.prod.outlook.com (2603:10b6:510:40::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Fri, 28 Aug
 2026 14:17:50 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0360.008; Fri, 28 Aug 2026
 14:17:50 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=E4BWIYNkWkCbONWB9Cy/GD2s48fUN9iGNhJthzcFB1fFNjEheJSmmQWuYRawscc56FeoKvZZNpll44Oj6UTa8pt7IQ6NI5H7lRGXfLM/Rh4BAt6sikihVeaJJwL8CXvGlTa9oRpOm2dicdnhV13QEimE4+NuqFIhwid6x8gK7P6TdTJmSyphxYkDncROwzBnWeFUd3GBEsKngF09w8wL2wtg5dWpMbXJp8/wc/k/9Do8mPF+hVnvTmhiAGuwSRrL4YAMdLYTwX8VWby0nQyQi8/m/9xDcVgdAfl4uymIfxb4Da5/2SC8KaPBDb0rw5Bd8qd85r/2WOpIfUnVGKSEhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NNldBmkROthhhik+2AfVSo80QSOw0nX3PLZ+fPYZ1Ek=;
 b=mTEejXKZ9nA6uHo2q4k8hO6rq+26yGYlTpcKzdFyRdVWV6MK0AuT+Gj+wIuE8py7tdGzA6Qx24+ijjxWvMsdQLL5rlTxJBtYcZLbfq6dVyBKjH0cJizxwmmvD+K7x/aL2DcA1kONpHtINZ2udJOksWTgeGBvYzNyZLw3XrV2POgo0qFFowqQZZJ7aByXMkyZW1Iocl7gULSpT+yc6VyAdS6BAA/kLWqQYWPkB/nLTQTWbYtcDJp7gSrV+HsKF64jU/SbuY5TLQqp+2OdYjj94o2oqFff7X44SvSwXbWKrr1EXQ6+xmQ89KGf8jHUr6WDVbHkrlVjwq5yT0c1tmYk+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NNldBmkROthhhik+2AfVSo80QSOw0nX3PLZ+fPYZ1Ek=;
 b=c0ua/9zAXkSxbxYwRTuOw9y6rARCjziTUk9AE72iv/J/3jYHzuIWjjtERhpP2PaBxuAfYOGYl6TgREipXhVa/GO2CovRjbg9Cyf3TQ/Zgu0U+J/5E+InVE2Jd8J3Uh0D/4a+ZyD1lL2nOk6c/wsQO6hFc85AOOg8K5Wicf9ja0s=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <dbfca751-4bd0-46f1-824b-43a9856031b0@citrix.com>
Date: Fri, 28 Aug 2026 15:17:46 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 2/2] x86/viridian: Implement synthetic timer direct
 mode
To: Tu Dinh <ngoc-tu.dinh@vates.tech>, xen-devel@lists.xenproject.org
Cc: Paul Durrant <paul@xen.org>, Jan Beulich <jbeulich@suse.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>,
 Teddy Astie <teddy.astie@vates.tech>
References: <20260828131142.3986110-1-ross.lagerwall@citrix.com>
 <20260828131142.3986110-3-ross.lagerwall@citrix.com>
 <1787926292.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3@vates.tech>
Content-Language: en-US
From: Ross Lagerwall <ross.lagerwall@citrix.com>
In-Reply-To: <1787926292.8631fc262581453bbf619ec5b2062170.1a048b62786000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0633.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:294::20) To CH8PR03MB8274.namprd03.prod.outlook.com
 (2603:10b6:610:2ba::5)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|PH0PR03MB5912:EE_
X-MS-Office365-Filtering-Correlation-Id: 3f51433f-7bdc-4203-800d-08df050f2417
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|4143699003|56012099006|11063799006|10067099003;
X-Microsoft-Antispam-Message-Info:
	Ri3mXN46eY3cZuqzU6sktO8V8sYvGWvFx/5F6RZGjri7WYL4lvjQCuiWZ03SgQfXh8nY1OciOljJzmI72mRY5x1uCyeLEEUm0WUFUmyJU+mOhu8oHJEVmqnc/+6aj4XqQfImjwOIsKFtIWh5WPrV9r7/ZxL0CQS51+oDxWNEC13ldCNc/lOCh9Kz5lFGp1uQhtw8VmMiPm/kphWI9WBp+r+kSIeKo7dvLnzS0uGhKu+KoCKOjrcWm3OyOfSBc/ly0kgmfOGyxOiOq5zbQH94U5Ql0Pz9QknhchCvqAgAjKwVFnx4EuaaXkjCgfh0hYn2MlXPnsgd95peiwM8UT9VFlljv61O3jl8M0XXCZtgvSgYUrHu9T2fqYOi+08YBJ1Rp8UGGebHubvFGZS9iosB12NgsVY09/mpCyeJ2DEegCcLY7O0Y9TTtm4OJkaKqVNXgt+hRPr2lbAuEfphP5OBHCyxk9JCYCOlWvO81jUvV60BtEMPyyQPpdWjTHzI5KrtP1KY2reZ5TGehctthLjEC8o+2YtHrAED8J0RgivXOioZrHhFzIICFchUjYFDT3W3Gu+UAFMUhVkvyqkZGoTGhE55xaq+PmDbPZZGzg0O8lnxPHAySdplBYu4ZMD8mZURzM2yr8qcpYCGbwnx46OMFWEougph/YSKrEd9yZst8F4=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(4143699003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?NElBMStMUEM1NXN4M29rSzc2ZS9xQ05LTnhWNXlDVUwzcmdJU0E3NzJ0TTdR?=
 =?utf-8?B?OXh3U2lSaDloUVFoakV2bHZyMXdYSURDci9JZ0xEY00ramhkaExSMFVRMS9O?=
 =?utf-8?B?b2JNZ3dySlFYaXlZcFhsMzVSVEw0MGJicHRMaDV2b3hYS0NUYXdMTWZPaWc5?=
 =?utf-8?B?Q0FIVm9zcU90Nlp5Y3dVT1pURGlxWUkrZjJHM2FNTjA3Ti9uZUdiMmFrdW9v?=
 =?utf-8?B?ZFlENGJnblBYZVQrQXRFc05jQXNDQVo1UldZa3NmdUllNjFsM1lJMFBJOTRF?=
 =?utf-8?B?dlp2YmdqZ2JBWXJJKzdhWndLVUsyM0syT2FDQ2hIMExGVmhsN2ZRdHFaRmxC?=
 =?utf-8?B?eEF4Z3BScEhBK3JyVlo2MTZ6ZnMvSzkvYkZEME5CTmJqVXM5eXRROTJOcmlS?=
 =?utf-8?B?cnNQaEF0Y1p3dGhlb2FsSFpVR05WYkdWQ3JHc1NPU0JPZHdzb0FlcUZiN2Za?=
 =?utf-8?B?N0o4Z3BQQzRyV2NIWTd0YjdQdFdlbUYwUGU5OEJ5Y2ZpcDA2R3VSSVI4dHFu?=
 =?utf-8?B?dXZsVmFqQVk2SWlZb2dSOEp3YkQyUkw4OUFNakR1ODRlYmpSL2I5ZE1COUF0?=
 =?utf-8?B?MElKOURlVXhFRExTbmcyeVVpUGZzOXpoWkQzYlNycnhzS3pJYVgvdU8rZFhF?=
 =?utf-8?B?SUZPU0w4ME9WNTZuZW4xMk1LRWNBN2trOEtZL1o3MFk2bjJONHA5V2NRQXM0?=
 =?utf-8?B?RmdtOHhZZ000K3lpR2NSQmlkUjlwZ3NnSWpHVWdXOEl5UWR0S1l1eHgvTGwv?=
 =?utf-8?B?WDhMbU5rWjRBVitWaEgzeVIrYno0Y1FMaGs5blJ1NnVVQmNnVDU5ckMrZk1M?=
 =?utf-8?B?Wnp5b1pjOVl0b0cxNndnUnd5OExCZHE3WXR6V3pETTl2a3UvdVlaWXlYYUo1?=
 =?utf-8?B?NTE4a2R2VTdYUTdjMGF0OE56amoydDYvY2RqR1pKNGtwOVArZTBjK0VweG9H?=
 =?utf-8?B?SDlMRDRmMTMzdm9OejZOendDZjVzRVFibmM2TXVQalN5cXZCL3dGMkVBUjl4?=
 =?utf-8?B?L2t1WVJ3QU5pTHpPRTVGTUVhVkJHbXN2Si8vNGNRYUpqNEw4dlpGMUlNeEpi?=
 =?utf-8?B?V3ZxakZDcmlIcjhrdk83WHc5MkdBQ1cwNWpFZXoxY3cyd2dLRGZMdHNBbTRa?=
 =?utf-8?B?eSt1ZGlnYURqRmN1U3puQUc4dXhBUEl5bTdjWm14V2hVYzJSSVJtRURaVktn?=
 =?utf-8?B?Zm9oV0pjM3dIdFpDZkhrRUZVSkFhQWl6UUpsZzF0bFUwY3ZianI3Y2M4ei9j?=
 =?utf-8?B?ZEtyaEU4QmYzMGIvSWZHR2x5RElhZWd1VkYybXpCd3llOUR0NTE3MWVndVpH?=
 =?utf-8?B?elhaSEIvUzhyT0RNS0xRSGVqWDYzTzRsNmpRbHpieWRaajVTelpndnprZy80?=
 =?utf-8?B?N29JWlBWK3UvcktIM294VzI5SE40b1h4bytsdFdpVjNIbW1hZFhucmtndzI0?=
 =?utf-8?B?YnhsTEprL2hjeVFRR2tCZjhpU3BsTHVKU0UrSXF3WFd0T1N1cVA0dXNwT2VZ?=
 =?utf-8?B?RTZUdlB3Z0w3aGNZVFBrZmVmNEgvR3VjWXJSMjArWlR1dUhiNStNN2ZYKytQ?=
 =?utf-8?B?VzBjblBpb0ZVcnVVdEdZYlpWeHJwY3o3MTN2Z3l0aVZiUkdPN08rcUtuTmQ5?=
 =?utf-8?B?OU5CQTJPSDcrelB2RTh1THJ2UTVpZzFWYmkwbnpXQ0dScnBRdCtzcktHQjNI?=
 =?utf-8?B?WkVPS1FEWTI0NFRiR3kvTGdrc1NkS2ZUSGcxY2lCUzJTTExQcklDcnVrYTJ5?=
 =?utf-8?B?TTlITWtRZ2hjeWZoQkxtQjFUU21lTG1nMTVYTERyWE54RUx1Y25PbEJjZU9R?=
 =?utf-8?B?VzV4eGpmZUprRzlPbTZENWUrMnFmRGozY09hUWpEQnZtUmN5b0pTbDdXOVUv?=
 =?utf-8?B?MnV0NzBpb0xwL3hYYU9BN1p6QXZ6WVhDRGtHMWJHUllJNXJsWTFBbXMzbGo3?=
 =?utf-8?B?bTlOSmQvOCtvNW5QenpyMkJ1bFp2Z2d4VHJnb25WbnlUdkFaY0R4b2w2MjJi?=
 =?utf-8?B?a1NjQzVtSVRqZGJRL1lNY056bUc2UmxEcFdxTzRBamNpY2I1K0Z4VTBDbTh6?=
 =?utf-8?B?VkxFK2VLbGUrOGhRbUdOL2o0dmZjOXJZcmFKWkg1SUJINWpJdWRaZmVKcmho?=
 =?utf-8?B?N1VYOXJkKzVMYWQ4WUkvYkRVMzAyVldYWndiNS9EWWttWmloTmxuN1JHTzRW?=
 =?utf-8?B?Yit1bXpEV0UxT2U2V0pyeFJtMXhDcG9qd1BMemhCRnlOWWJ1NkR5cTg2VTR1?=
 =?utf-8?B?WDdrbWp0YUVwKzMxQ3JDSlhjMklvcXFRTmxZY1ZqR2FCTERzVUpWZDgzMXlj?=
 =?utf-8?B?SDRjUmt5SkUzbnVsV0NpTWZqLzZjYlVZSUgwWlJ6a0hEbnNkNXkyMzlzVVV2?=
 =?utf-8?Q?vTrcR5nrzVGiswqg=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f51433f-7bdc-4203-800d-08df050f2417
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 14:17:49.9787
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uNVVUiMcWI3m1ew9n+8aCoKertMRbZATlNHBSusKV0BMrUA6ZNkPdqlbYviVCYZ4c/oU5BXNgtZdphICPfQ0wy32yS5EXdLeGCusv7eDubM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5912
X-purgate-ID: tlsNG-ebf023/1787926674-51ED6B50-F8073EDF/0/0
X-purgate-type: clean
X-purgate-size: 643

On 8/28/26 3:11 PM, Tu Dinh wrote:
> On 28/08/2026 15:14, Ross Lagerwall wrote:
>> In direct mode, the timer asserts an interrupt on expiration rather than
>> using a SynIC message. It is useful to implement this since Windows 11's
>> Hyper-V can only use synthetic timers in direct mode.
> 
> Hello, is this new behavior compared to Server 2025? What happens if
> direct mode is not available, does it fall back to disabling stimer?

No, it's not new behaviour. According to Linux commit 8644f771e07c it
has been this way since 2016. If direct mode is not available, the VM
still works but without using synthetic timers.

Ross


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 14:20:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 14:20:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402098.1637511 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzxRO-000235-PL; Fri, 28 Aug 2026 14:20:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402098.1637511; Fri, 28 Aug 2026 14:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzxRO-00022y-M4; Fri, 28 Aug 2026 14:20:22 +0000
Received: by outflank-mailman (input) for mailman id 1402098;
 Fri, 28 Aug 2026 14:20:20 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ross.lagerwall@citrix.com>) id 1wzxRM-00022T-R3
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 14:20:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzxRM-006G3d-7s
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 16:20:20 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a91990e-e002-0a2a0a5209dd-0a2a4508d768-28
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 16:20:20 +0200
Received: from [52.101.57.38]
 (helo=BN8PR05CU002.outbound.protection.outlook.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ross.lagerwall@citrix.com>)
 id 6a919923-f659-0a2a45080019-346539263179-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 16:20:20 +0200
Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5)
 by DM4PR03MB6997.namprd03.prod.outlook.com (2603:10b6:8:42::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Fri, 28 Aug
 2026 14:20:17 +0000
Received: from CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com
 ([fe80::ebe2:32c1:d2be:a096%7]) with mapi id 15.21.0360.008; Fri, 28 Aug 2026
 14:20:17 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=jsQRpxPBxrYNBqAmHr6i1pN++h2z1DbPRlS/nUZVNKa5eNwdhCe2YQyXUpqobiuwBBeZkcz/pvB3QnE2gsL1GNOk7gkXAzdTV+VeQB6K2wdnMJO/wp/a4D7SaUJ6Qy8TrlwBVNXkjGyxFdJHovhlVzQnbeR63gpUqVIMQP83HF83/ZmHg4HyxUp6XeKiSRandiBbwsPIB2rCS2ksKowNGrxWF0FPZhhqls+phkh69Nn3XhRBoXoOHuScAZO5jmPSIJUcKd4YHPfQCncs1kDF6XUdJLDIqwVEPNYFQn70jK026QRIJ4Tdl4+dTsg5o3C+p6IGNj2JMczSKq2wjVk4EQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ny6wV03mQa0avSNSUM5XqRuUeG/cMLeVPOylNxwJFQk=;
 b=rWFWOaBB4aIfnsP9oi6gyvISpNQz+ZTqEmfwj6qppE+HfUW8SdiSQOGZHRzlQAWhj6GUK0UuvaOMXDlRbmgCGGruphAVMiEWSVl/GGNHJc0UfeEwcGEWiN790yPFnbS/Op2n09b9fLokHZNa6YMTnq7YslQrz5HUYPHYM+/paPcm/kBwMeHm3b+ilOhqqbG+VzdyQA6sSiw4+UHWjsUzw52uIuFXC2EqOPGgvaSuXthahaUttlMkaY9Yy9KD1BKFEvzu7DYYInjhKtNlYKoiGVWjPkBTg0YpCN2Ftz9oK0k+sfwKxhHkQZ79vGiY4aw+AK/WdbDp9l7rYx5M3HpfBA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ny6wV03mQa0avSNSUM5XqRuUeG/cMLeVPOylNxwJFQk=;
 b=TCEzjrK7Rl/3+QIlmCYcge451yk3qqjt+o2yirC3RfzBNYdFtz0fWQBuMnwXpPYwp066QN2GQ4LuhZavbU0YziYTfA8TcqTh5t5lwoOn1Ph2XJGH1PM0p1BI21/22GWNgmWS4a8bqGTmlqmkHYlf96V/OVU5+0SKxO6WtgeUqeA=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
From: Ross Lagerwall <ross.lagerwall@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
	Jason Andryuk <jason.andryuk@amd.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: [PATCH v1] x86/svm: Intercept CR0 writes selectively
Date: Fri, 28 Aug 2026 15:19:55 +0100
Message-ID: <20260828141955.4009939-1-ross.lagerwall@citrix.com>
X-Mailer: git-send-email 2.53.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: LO4P123CA0112.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:192::9) To CH8PR03MB8274.namprd03.prod.outlook.com
 (2603:10b6:610:2ba::5)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|DM4PR03MB6997:EE_
X-MS-Office365-Filtering-Correlation-Id: 02979082-3239-4a1a-b861-08df050f7bf7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|11063799006|56012099006|10067099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	J5KYsVbgbHFuJgmsWIGAJE1TIkYl3LpOE2RyzofuMu8SrpVXtjF5vm46cMbo6KmllUoQMVwVvydeKUnNQrwaH8FLtFxaXxvH8yQFyKOBTz6jOigac3/vXEtZO/xQuVdvyizPmI16NrZdKAFT4J83AXPIdHMNRYny5K+SeHMcK2cS3B9byCdkHjQxGMl4Ex4kTLvyaAAe7iX1keD29p69g+D4sJN2jlQBeVwxknOhNQ6EHPxrNP9QG9mwYgToIGaxZBK5EwsIEAuxKm3AbrQ9gSZCDu7a70f+qQNKKDUZ5d2wamA7CgLjKSv8PFnQsQdzVCA4HzcAzqEIRpdSsdyo7Q6sCStJ3mIeyzRGblCqggijrcaYHOGkEUF/o03NtdsV0is51LDp3J6gfFHuwudDGXFlqzVMcI8j/5iwkNw3Dqk7szhogaHc8j20LgoAU/5n3zUEDaL/WmrhbLfr3DFX2CZaC3zHOaPiZNBdkDtP2XxbP/yq/AzA6WGnGeS+tONITBEwZ4biPaQtelNQDBe4dH0pGFhkOBxUUN71NeHuCqE5cats1iwE4aEblQCnF15TS72qnOfgprKPnZIV5cagvuqPBxksPOPek0pAbJwfPzLdCUdh+nSMoGb70cRZft2DQTP+RmLi9NcwIDvYtbxojre+WwNJ8OO019t/t1qpqhw=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?5aMgLPvutbD9uJoqlFO+qtU/yLu8NXOVRDJeHOtcvfVgxB5JtEL+a06X9P3k?=
 =?us-ascii?Q?q57RfP/FaMqN1vYFfkg4OZAVM3NmDi2xiNQ6oGmOnSiO1wF32fJOh3+gwlnr?=
 =?us-ascii?Q?u1WjKhdy0tvDRSafOaPVbszDnou+dhujt++K5yihLTx5WqDroQXyoAMSedXx?=
 =?us-ascii?Q?Y77zPVg7FXib0rnWcJxmHG4q1cKFoEwC7z/7k17ovggQk5ki/wYfnaiEpro8?=
 =?us-ascii?Q?Io9gLv5roVa69XMjtXyr5rpVWC82yUW/GuG5WnQtRc7WT8W8aM5X3w3U/GBy?=
 =?us-ascii?Q?iAs8aczEVIHKI2h8zixiePhOGGWotQLlS+M96xwseMw4JfgNsqHRNFgdOYRY?=
 =?us-ascii?Q?gpEwa4ZD3Twam21FO1GwfMSEnzokQdYn2mlbADTyKJfIp8YIuRYJF2YYIDhq?=
 =?us-ascii?Q?DyqCXBDdAZv50kMtBrFnH+PwefPdfimxGKOXiZfb044+Mp3+kY2Tt+JRvlvY?=
 =?us-ascii?Q?c4uiEw/sLHHNBNcbj36B6Qsrty3uX77v5SCIusqDEycQAMvOLKVqvG9urZF1?=
 =?us-ascii?Q?KlOnA+RQWrAqKWG9rn2djGEZXRMiogBNuUZM2AysWh21djSWvXLqJ3EvGh1M?=
 =?us-ascii?Q?t5Sw/TUMqKhCFhED+VFkksErz55QBtUm04pTmrzg9xD7wGSY1MSDcLQv64nv?=
 =?us-ascii?Q?afTozaMtM8HqTxG7tNCuy5RhmcMdyJ93DeWMRo9tDflmFQsyMoxMe8x9wLa2?=
 =?us-ascii?Q?jbdy3pkVFbwyz2TNRSISseueyGOOTGfTysk/uoVkuuQxF30qZEu4yRyCX87E?=
 =?us-ascii?Q?lWPj4LGU2OcgmfX/yEllgWTpT1EexJga+BLQmKxjnlJkTReQ1fB3KRcsayS7?=
 =?us-ascii?Q?aN/UuQaPO4aJ9eL7t6HYj97Ang+lnxVzypNtDTJg3xPBqU6m4p1apkta3omn?=
 =?us-ascii?Q?ZFMg2YKy0hTnujLuCn/PZOvoaFWw2GqjkSO/HugcWDyJ/GBHY4TpTX8qIN79?=
 =?us-ascii?Q?pwwKm+M23xxNzFr02Sm/1+/biLDbTzYNoZ2GS3G2DqPdZnI4jGtWhpjWEy5R?=
 =?us-ascii?Q?F5rv2pvWYMccI420OUZk/IcaNws5s9c7CmYvH747aqHgkBoaiP0RRQs5uk1W?=
 =?us-ascii?Q?mxZFVLD9AraRp1LGIO3U834AK6Kr20SQKddH4427sN048XHVKZrXrqXWAvuy?=
 =?us-ascii?Q?viqZ6RemhxIOJoYbiPoQpKSNTupD49/QMGirSzSj2EqylHmVFIxhN/yBO9WG?=
 =?us-ascii?Q?gO/uEP3no0AWU4iUWa/1kpQiGLq7/D6xCkzIw5HyUVjPjVIRCrEKzrxdc3P+?=
 =?us-ascii?Q?LMZ0pllZR+ZvJij/89tP1JQr/VAfW6cKaWRT8JJCcS5FtRRLbAOsiSkSp/dZ?=
 =?us-ascii?Q?slJYztM0cWe4gzpMdj+Tr808gqv5Sx24dqlMa3+8nD4+J1xdGmArbNH3RGhZ?=
 =?us-ascii?Q?mDpcSnoNpW7893yFqok9lmIUMhgBLSOIPCGcYudh8vcQxT9okD1zVexQJ8Gi?=
 =?us-ascii?Q?M0eMqbB36/t792AyyjXdFdb84ukOWXEERUvpEVMotFoN8UF62b3qgSKsIrHK?=
 =?us-ascii?Q?C9I4KV84pCz6UjmM/nkDvvvl6T5ACXELHrgsRxWA2mrFdmhBhVYufeRk0J+B?=
 =?us-ascii?Q?Uq3ZpYbeM/0zO1OG/ubeNeipByZxcNDhVQVZIKLqUpC9Zrnthwr4UQAqEaed?=
 =?us-ascii?Q?VlsRncPuj4UQP1nOOxTHifg8FYfAESVGhWQV+dbLa5DnWZpgs/549UtwMAhb?=
 =?us-ascii?Q?K4uX1DdAyxGq2jFrKz8PiI15mXlb3vhRsaPcFe2P7jS3vYVlGsxD4z/2nkFF?=
 =?us-ascii?Q?uAC9rNeXymwRfgZ0nc027C1w7Iyr1xE=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 02979082-3239-4a1a-b861-08df050f7bf7
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2026 14:20:17.3122
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pIrY9hicbeEPDw86wnlgQYfF7B8vvLRJlPjYeOIvYJebuesKg451mK4JSrIz5dmeVk/67DAnn85e8TS/nfy7+MgY1rNumGk3yrXM726vR54=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6997
X-purgate-ID: tlsNG-c1860d/1787926820-D5B4987B-91DF2DF6/0/0
X-purgate-type: clean
X-purgate-size: 3508

Xen does not need to track when the TS or MP bits change so opt to
intercept CR0 writes selectively. Aside from potentially reducing a few
VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE
and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so
L1 never sees any CR0 writes.

Since CR0 may now change behind Xen's back, sync it on VMEXIT so that
the emulator sees the correct value.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
 xen/arch/x86/hvm/svm/svm.c  | 7 +++++--
 xen/arch/x86/hvm/svm/vmcb.c | 8 +++++---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 5f5d903d872d..8da879a5af67 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1640,7 +1640,8 @@ static void svm_vmexit_do_cr_access(
 {
     int gp, cr, dir, rc;
 
-    cr = vmcb->exitcode - VMEXIT_CR0_READ;
+    cr = (vmcb->exitcode == VMEXIT_CR0_SEL_WRITE)
+         ? 16 : (vmcb->exitcode - VMEXIT_CR0_READ);
     dir = (cr > 15);
     cr &= 0xf;
     gp = vmcb->ei.mov_cr.gpr;
@@ -2517,6 +2518,7 @@ void asmlinkage svm_vmexit_handler(void)
     hvm_sanitize_regs_fields(
         regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l));
 
+    v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb);
     v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb);
     if ( paging_mode_hap(v->domain) )
         v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb);
@@ -2882,7 +2884,8 @@ void asmlinkage svm_vmexit_handler(void)
         break;
 
     case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
-    case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
+    case VMEXIT_CR1_WRITE ... VMEXIT_CR15_WRITE:
+    case VMEXIT_CR0_SEL_WRITE:
         if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn )
             svm_vmexit_do_cr_access(vmcb, regs);
         else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") )
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 975a1eaef806..7ee91937b10c 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -56,7 +56,7 @@ static int construct_vmcb(struct vcpu *v)
         GENERAL1_INTERCEPT_HLT         | GENERAL1_INTERCEPT_INVLPG      |
         GENERAL1_INTERCEPT_INVLPGA     | GENERAL1_INTERCEPT_IOIO_PROT   |
         GENERAL1_INTERCEPT_MSR_PROT    | GENERAL1_INTERCEPT_SHUTDOWN_EVT|
-        GENERAL1_INTERCEPT_TASK_SWITCH;
+        GENERAL1_INTERCEPT_TASK_SWITCH | GENERAL1_INTERCEPT_CR0_SEL_WRITE;
     vmcb->_general2_intercepts =
         GENERAL2_INTERCEPT_VMRUN       | GENERAL2_INTERCEPT_VMMCALL     |
         GENERAL2_INTERCEPT_VMLOAD      | GENERAL2_INTERCEPT_VMSAVE      |
@@ -76,11 +76,13 @@ static int construct_vmcb(struct vcpu *v)
     /* Intercept all debug-register writes. */
     vmcb->_dr_intercepts = ~0u;
 
-    /* Intercept all control-register accesses except for CR2 and CR8. */
+    /* Intercept all control-register accesses except for CR2, CR8 and
+     * CR0 (covered by selective write). */
     vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ |
                              CR_INTERCEPT_CR2_WRITE |
                              CR_INTERCEPT_CR8_READ |
-                             CR_INTERCEPT_CR8_WRITE);
+                             CR_INTERCEPT_CR8_WRITE |
+                             CR_INTERCEPT_CR0_WRITE);
 
     svm->vmcb_sync_state = vmcb_needs_vmload;
 
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 15:15:02 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 15:15:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402147.1637520 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzyI8-0003VD-Ls; Fri, 28 Aug 2026 15:14:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402147.1637520; Fri, 28 Aug 2026 15:14:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzyI8-0003V6-JG; Fri, 28 Aug 2026 15:14:52 +0000
Received: by outflank-mailman (input) for mailman id 1402147;
 Fri, 28 Aug 2026 15:14:51 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1wzyI7-0003V0-62
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:14:51 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzyI6-00F0n8-Iz
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 17:14:50 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a91a5de-8faa-0a2a0a5109dd-0a2a4507abb0-2
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 17:14:45 +0200
Received: from [209.85.208.49] (helo=mail-ed1-f49.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a91a5e5-b4ea-0a2a45070019-d155d031b9b5-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 17:14:45 +0200
Received: by mail-ed1-f49.google.com with SMTP id
 4fb4d7f45d1cf-6a082b3671fso1409303a12.3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:14:45 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a611c7773asm698728a12.31.2026.08.28.08.14.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 08:14:44 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1787930085; x=1788534885; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=7Chw7Z0YDubxS/jUiv6/zEGR1NZfWXVa7KNTPT8Aydg=;
        b=d9ak4dLRoZyP9fXLIjRawJ43Bx9JNMct1aDO07foCAR2CjrqPViNSTj0CpQcf0eM9D
         TKnDHUWGnWbFD0IkGU+qZU7zoD9uV+r7gxXF+mruU/zcsqDCEG8v5Vlw0abxZorYIouc
         sgayNm57bj/C7Vk1Ynrr6i8RNx9vosU+aO/SfuAsWo9uWxsxmJOVESMIhORLDKoO7pWL
         T8qNntsHM4vdpKTC+7h8WaLe/vgAJ4bm6B7KmFXgbv0wFypH53BGmdEb7+7wGnpTe5Zx
         FRqXLImEqWE9Kh0cutN5sAn7gePSUHVTDqqI3kjcKC1v5MQ6Hj6PciG9nvLztVttH6q1
         ZxOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787930085; x=1788534885;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=7Chw7Z0YDubxS/jUiv6/zEGR1NZfWXVa7KNTPT8Aydg=;
        b=gT+fh8JM9B9tZpawzDu5yf4VeTRQSiD4lXQoyMxyMtWXKmFvt6hbywG9In6yuxZEVT
         FgXqcj/Yiw64l8yL64wiurzuZy0Wi7vdlJr2kawBkDH6zVlkBgx7bSxy9tl+EW4V3suZ
         eARL18kUQ1KyKa4VRfQaqLBfXJOn+ddm2sXJ5pGYMZgwP2GEtAIKpcxcXn/bmFBsduZP
         DE+NkrBlia2XW81RUSbm4lES29Jgbc27LHvDSUFEWUDl8GyLQgo/Gh04Rb/trepfa5j1
         WGRGI3+kHitriblU7UkPxa/Pgdp3xhuxfMqSI7ef/VOt6XSk925hmVgjKYhP54I19PU7
         D8Lw==
X-Forwarded-Encrypted: i=1; AHgh+Rqwm6DKYQYGKh+WGete0IN5VcsnBv1V9RmLJ2JCysS3WBtB5xCSCik0e/zLLRULHzAh30dYtvm+1P0=@lists.xenproject.org
X-Gm-Message-State: AFuF++llXE+3Lafc2/zVZaPOgu9DHoCZCArhu55NfqRfD8C6xTyCr+e3
	2cSXaxApAmF36pXQJuqs01VhZLuXaD2PxrJ9GQUA0HCq/HPekB8qLAHsBkG0WHedLRpKwIKEnb9
	x0F5R+iw=
X-Gm-Gg: AR+sD10sY4qKAndiXN5KNJ19AUXi4pMC+qooGBPrUpInDE6rs8xIBmJFO0FjzajsbMJ
	VwGeMGeth40xKwyvj2N48ouQJ+80VfkT/1S+Mwv/smyFTY+2Vlxh5Tha9zst2xQCQIrE0ii9iF3
	zADgmJvadb6wEpqoZNgci7F1yFgglWfWDPKGlwHlYnUsehadxoP53QlzazvqpBl83vDcUFVk0Fq
	OvYVrslw0DgKn3niKEpBfFyzfADBy0cFUm9yhQ9Qxz8UFR7XISm+djtKlZ9mAPThI1v0sBt0DHc
	GdYnLLd0KscbqqqXh5fHdE4iiOrMHRauwCd+g3uydhLJlVD+9sJvBBgr0hYp6ac4WCG9yqp29BP
	YXe7UUGegR1+3aeOqjjTyILlc6QQ9XeW5A7hz+B36xezDpCUBsp/fPtbX+Mby2ZPodCfGZY5qbz
	NhAgF1WPaj0PmKZyIp93l3VfqScblHebMVgnrLfTuRl1N4s7zPPp3lnEUCwwCXH8rRgEgyzhe3C
	F/lUaUTwRuSeRtrJojVb5xx6dxCkAdd9dKqhN+1VG/FOjq3uG/x13FuQHRJMStMbuTsMDHrakjt
	N3xKgnlGbD0yscoSIC5dJn7k
X-Received: by 2002:a05:6402:354a:b0:698:af31:5a9b with SMTP id 4fb4d7f45d1cf-6a60d3bbaefmr5062966a12.9.1787930084790;
        Fri, 28 Aug 2026 08:14:44 -0700 (PDT)
Message-ID: <d27b5ef4-65b5-4c59-8128-5be8a0eaa15e@suse.com>
Date: Fri, 28 Aug 2026 17:14:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Jan Beulich <jbeulich@suse.com>, =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?=
 <frn1furkan10@gmail.com>
Cc: andrew.cooper3@citrix.com, dfaggioli@suse.com, gwd@xenproject.org,
 xen-devel@lists.xenproject.org
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
 <e0f91d0e-0b08-4d69-bf94-243bd26f67df@gmail.com>
 <f687da3b-a9f7-4df3-a113-3cdd0b817e3d@suse.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <f687da3b-a9f7-4df3-a113-3cdd0b817e3d@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------0jGiln0RDKSyqUe4kRIHgRBN"
X-purgate-ID: tlsNG-ef75cf/1787930085-358C1AE4-5EE96BB7/0/0
X-purgate-type: clean
X-purgate-size: 10513

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------0jGiln0RDKSyqUe4kRIHgRBN
Content-Type: multipart/mixed; boundary="------------fFracx2fzOYQEeIfk5WirJaB";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>, =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?=
 <frn1furkan10@gmail.com>
Cc: andrew.cooper3@citrix.com, dfaggioli@suse.com, gwd@xenproject.org,
 xen-devel@lists.xenproject.org
Message-ID: <d27b5ef4-65b5-4c59-8128-5be8a0eaa15e@suse.com>
Subject: Re: [PATCH v2 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
References: <20260819051532.9197-1-frn1furkan10@gmail.com>
 <20260819051532.9197-3-frn1furkan10@gmail.com>
 <f9471a2b-6306-41fb-af52-2336af77dfc9@suse.com>
 <e0f91d0e-0b08-4d69-bf94-243bd26f67df@gmail.com>
 <f687da3b-a9f7-4df3-a113-3cdd0b817e3d@suse.com>
In-Reply-To: <f687da3b-a9f7-4df3-a113-3cdd0b817e3d@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------fFracx2fzOYQEeIfk5WirJaB
Content-Type: multipart/mixed; boundary="------------NI1zbHGiYvPMsrRAiqhMPkky"

--------------NI1zbHGiYvPMsrRAiqhMPkky
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTkuMDguMjYgMTI6NDMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOS4wOC4yMDI2
IDEyOjM5LCBGdXJrYW4gw4dhbMSxxZ9rYW4gd3JvdGU6DQo+PiBPbiA4LzE5LzI2IDEwOjIy
LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAxOS4wOC4yMDI2IDA3OjE1LCBGdXJrYW4g
Q2FsaXNrYW4gd3JvdGU6DQo+Pj4+IC0tLSBhL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+
Pj4+ICsrKyBiL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+Pj4+IEBAIC01ODksNiArNTg5
LDkgQEAgaW50IHNjaGVkX2luaXRfdmNwdShzdHJ1Y3QgdmNwdSAqdikNCj4+Pj4gICAgICAg
dW5pdC0+cHJpdiA9IHNjaGVkX2FsbG9jX3VkYXRhKGRvbV9zY2hlZHVsZXIoZCksIHVuaXQs
IGQtPnNjaGVkX3ByaXYpOw0KPj4+PiAgICAgICBpZiAoIHVuaXQtPnByaXYgPT0gTlVMTCAp
DQo+Pj4+ICAgICAgIHsNCj4+Pj4gKyAgICAgICAga2lsbF90aW1lcigmdi0+cGVyaW9kaWNf
dGltZXIpOw0KPj4+PiArICAgICAgICBraWxsX3RpbWVyKCZ2LT5zaW5nbGVzaG90X3RpbWVy
KTsNCj4+Pj4gKyAgICAgICAga2lsbF90aW1lcigmdi0+cG9sbF90aW1lcik7DQo+Pj4+ICAg
ICAgICAgICBzY2hlZF9mcmVlX3VuaXQodW5pdCwgdik7DQo+Pj4+ICAgICAgICAgICByY3Vf
cmVhZF91bmxvY2soJnNjaGVkX3Jlc19yY3Vsb2NrKTsNCj4+Pj4gICAgICAgICAgIHJldHVy
biAxOw0KPj4+DQo+Pj4gVGhpcyBhbG1vc3QsIGJ1dCBub3QgcXVpdGUgb3Blbi1jb2RlcyBz
Y2hlZF9kZXN0cm95X3ZjcHUoKS4gV291bGQgYmUgbmljZQ0KPj4+IGlmIHRoZSBjbGVhbnVw
IGxvZ2ljIHdhcyBzaGFyZWQuIFRoZSBzY2hlZF9mcmVlX3VuaXQoKSBjYWxsIHRoZXJlIGNv
dWxkIGJlDQo+Pj4gbGV2ZXJhZ2VkIGhlcmUgYXMgd2VsbDsgd2hhdCB3b3VsZCBuZWVkIHNr
aXBwaW5nIGFyZSB0aGUgc2NoZWRfZnJlZV91ZGF0YSgpDQo+Pj4gYW5kIHNjaGVkX3JlbW92
ZV91bml0KCkuIEFuZCBvZiBjb3Vyc2UgdGhlIFJDVS1sb2NraW5nIHdvdWxkIG5lZWQgc29y
dGluZy4NCj4+DQo+PiBXb3VsZCBzb21ldGhpbmcgbGlrZSBiZWxvdyBiZSBva2F5Pw0KPiAN
Cj4gTWF5YmUsIGJ1dCB5b3UgbmVlZCB0byBhc2sgdGhlIG1haW50YWluZXJzIG9mIHRoaXMg
Y29kZSwgd2hpY2ggSSdtIG5vdCBhIHBhcnQNCj4gb2YuIFdoYXQgSSBpbiBwYXJ0aWN1bGFy
IGNhbid0IGVhc2lseSBqdWRnZSBpcyB3aGV0aGVyIC4uLg0KPiANCj4+IC0tLSBhL3hlbi9j
b21tb24vc2NoZWQvY29yZS5jDQo+PiArKysgYi94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYw0K
Pj4gQEAgLTU4OSw4ICs1ODksOCBAQCBpbnQgc2NoZWRfaW5pdF92Y3B1KHN0cnVjdCB2Y3B1
ICp2KQ0KPj4gICAgICAgdW5pdC0+cHJpdiA9IHNjaGVkX2FsbG9jX3VkYXRhKGRvbV9zY2hl
ZHVsZXIoZCksIHVuaXQsIGQtPnNjaGVkX3ByaXYpOw0KPj4gICAgICAgaWYgKCB1bml0LT5w
cml2ID09IE5VTEwgKQ0KPj4gICAgICAgew0KPj4gLSAgICAgICAgc2NoZWRfZnJlZV91bml0
KHVuaXQsIHYpOw0KPj4gICAgICAgICAgIHJjdV9yZWFkX3VubG9jaygmc2NoZWRfcmVzX3Jj
dWxvY2spOw0KPj4gKyAgICAgICAgc2NoZWRfZGVzdHJveV92Y3B1KHYpOw0KPj4gICAgICAg
ICAgIHJldHVybiAxOw0KPj4gICAgICAgfQ0KPiANCj4gLi4uIHRoaXMgaW50ZXJtZWRpYXRl
IGRyb3BwaW5nIG9mIHRoZSBsb2NrIGlzIGVudGlyZWx5IG9rYXkgKGl0IGxvb2tzIHRvIGJl
DQo+IGF0IHRoZSBmaXJzdCBnbGFuY2UpLg0KDQpXaHkgZG9uJ3QgeW91IGp1c3QgcmVwbGFj
ZSBzY2hlZF9mcmVlX3VuaXQoKSB3aXRoIHNjaGVkX2Rlc3Ryb3lfdmNwdSgpPw0KDQpyY3Vf
cmVhZF9sb2NrKCkgY2FsbHMgY2FuIGJlIG5lc3RlZCwgZXZlbiBmb3IgdGhlIHNhbWUgbG9j
ay4gVGhpcyB3b3JrcyBiZWNhdXNlDQp0aGVyZSBpcyBubyByY3Vfd3JpdGVfbG9jaygpIChz
ZWUgY29tbWVudCBpbiByY3VwZGF0ZS5oKS4NCg0KDQpKdWVyZ2VuDQo=
--------------NI1zbHGiYvPMsrRAiqhMPkky
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------NI1zbHGiYvPMsrRAiqhMPkky--

--------------fFracx2fzOYQEeIfk5WirJaB--

--------------0jGiln0RDKSyqUe4kRIHgRBN
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqRpeQFAwAAAAAACgkQsN6d1ii/Ey/k
7gf/Wl1ZDUjmQANv023an/uTlykmIoOlalvAL03P/rTYsazXnOeVZ1Td1yKGHtYsJHv0aRezPlG2
Bdbw4LFLAty1N1f8KqppLOi6kVQh/Q3Oj+rxhLcfa1+CqdBS+hogCwiT/Yfy+kA+QU44qt0tqytN
1BtjSQ0EJjwxbAAsOHcBWcsqDPrOdJkzx0MduKAu2PNeXXoJsmAIhHUQBRh18vc78fzCOcbpkHDK
dXw7jzf1u12gkR3rv0Tv2+oCD6BOBMnTbgbi44+HyRm1umjfJRbPrAfMM3AWbOAmPnTchbXkwKB3
pqIdkjqGU6VQrQtXYC/5lXRp4GNFZ0MsXOL1efptpw==
=PVtq
-----END PGP SIGNATURE-----

--------------0jGiln0RDKSyqUe4kRIHgRBN--


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 15:58:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 15:58:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402203.1637528 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzyyA-00069O-Qe; Fri, 28 Aug 2026 15:58:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402203.1637528; Fri, 28 Aug 2026 15:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzyyA-00069H-O1; Fri, 28 Aug 2026 15:58:18 +0000
Received: by outflank-mailman (input) for mailman id 1402203;
 Fri, 28 Aug 2026 15:58:17 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzyy9-000686-98
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 15:58:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzyy8-007oM7-M3
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 17:58:16 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a91b00e-2eae-0a2a0a5409dd-0a2a4503b0d4-6
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 17:58:16 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a91b018-fae8-0a2a45030019-d155802ee45e-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 17:58:16 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49cca4ffdcfso687965e9.0
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 08:58:16 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b468009f8sm137344905e9.0.2026.08.28.08.58.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 08:58:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787932696; x=1788537496; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=L8gBF7uQwy8abryU7XLAGNsW8Qs7n9iHctdipMKdDew=;
        b=m6LiT0vIX0YfSiY5Ltlk2CUOeWlRRBl/ZX13BIafuY+sQd0kKhOR5Y1JKqzzHdNmNH
         nNzInEm/dKpz/QJBdcHydHcE5KypNqQJ3aWS+4iKqtDxgNufUV9Dy5NPb+6F2n9ma26V
         BxHpT7eFGXRpofnJChTzDkrDLQ0rnvKBpKxISzMscf/ys0AiDna/KibQ9dMX/zeR3jUp
         m3IUv5qYa/SPIIiuxHH3cGtxyP7tQrVf0pssM2Cqvx+HKjk51o7Q/BE/VltlgjWLUQq3
         x49G2fqNh16JRVpRuEQnaCqpKvJ+fOge6RR8y0Jm3uxO9/pgwn9HGxQ9juXVFvIrjLZy
         Xg6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787932696; x=1788537496;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=L8gBF7uQwy8abryU7XLAGNsW8Qs7n9iHctdipMKdDew=;
        b=iTzjO84arppu6t5Ry7myajiXMtE+Gc+Wmhhs74T2vvdZvbWMrZSOKbCg9ymG84TK7x
         62T70r/1MYBYm/CS6b3RLNgTGwun0BzIqnJGTspLBLSZ/YjMQBEhy2CYfLSR7EdIegdm
         vkYl0Xpb5jOHdIjkZ5MQauG07k2hUpChwQNXwRgA8sJ+ykXWGzQQ2aFwtKEAAeWY2LtG
         XookEXOB5SnPR5yBzJHdSbaJ0N4JJ/j8r5hk6SmzFgm3hJ+FFeuPpt6szVCsrUo3HhHP
         yvusWCwqXISXkRIkOeZR6OUPg7i9hl1L2x4k9bv2sWCQIumMX38fl5vy3TuO90pgHH4L
         BCsg==
X-Forwarded-Encrypted: i=1; AHgh+Rp2wliJTr0W6ZJNvnsVJ78gcj+I/CJIfw6PNKbFhldOswKSa3SGETgfShasm3pk8JSK118EOqmocsc=@lists.xenproject.org
X-Gm-Message-State: AFuF++nYMa42SbmzRG+EyfV4K3dy+tza307UnwalintjLjLwVWOhkhzI
	1JnmsDMm1D2ZwVRMNZiVVDZnzvWk5OBIKrcKIQIjnCVQXAzsi5HE6T0S
X-Gm-Gg: AR+sD11ZF33mp+guSUxCYHeT/O3sZTyfFluV+8vtnXMSuRIq0vh/QPoisAR6Dhx/4Se
	1yeNU1NYY4fGbOn+Dbb3n695GD8JcOKGBAUba91ymNTUoPKbF8lDrRA0aVRsadjIqHYbuw9omfV
	ZSVOEWqOVz6pDTHX9O/xoxu3zJ/ke/S3tLsVRiHsAkmBSLtKGru+PpsT8g/jGUcKvz8SP5PZxLJ
	peYWtdx2ukSWKeJ6vi1siaMKFt0WWQR7HdHk0OqkUnUAq880MY/3cjs0EW5VQwjXf4TaPtewsiO
	Ru6U7+JehLX4UQdy6K235sxNzXGx74yYLK+w5HBZBcFtHM7pJwv5gbGLM/OATBZ5b6w9HMsyE0k
	SEblVtufgGvPPdamavLa5mXiC14jMc5T1GQyKLuiKpYTFJuMq2pNGPTrfvGMaCX9Uz4QqdxeW6R
	AqTcfysBXuADBXDjNNhEVLPZF6B4VoG2QqLevDzqGLvWYOC/LacvoHucJBZcx3nEvSwlUUxlNgx
	QZZE41adsqFyuMOio9UTnH/dZ9GZIosNRuZegVWkA==
X-Received: by 2002:a05:600c:a02:b0:499:da8b:1476 with SMTP id 5b1f17b1804b1-49b91c52579mr101887535e9.14.1787932695547;
        Fri, 28 Aug 2026 08:58:15 -0700 (PDT)
Message-ID: <59555237-425d-47f0-80b6-b7273cc8d6ec@gmail.com>
Date: Fri, 28 Aug 2026 17:58:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/5] xen/riscv: make Svpbmt no longer a required extension
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 xen-devel@lists.xenproject.org
Cc: zhangzheng@iscas.ac.cn, Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1787932696-6CCDB4E9-BA72E400/10/73395122804
X-purgate-type: spam
X-purgate-size: 7590



On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> required_extensions[] panics at boot if Svpbmt is missing, which is a
> problem on hardware that doesn't implement it.

Based only on this sentence it isn't clear why it is safe to have SvPBMT 
= n and what guarantees that if some memory for a device dma for example 
should be non-cachable and strongly ordered what will guarantee that.

So basically something like that should be added to the commit message:
```
Without the Svpbmt extension, memory attributes (such as cacheability 
and ordering) are strictly tied to physical address ranges and enforced 
by the hardware's Physical Memory Attributes (PMA) checker.

In this configuration, supervisor software relies on the platform's 
memory map: peripheral device registers (MMIO) are physically mapped 
into hardware-defined I/O regions (which are implicitly non-cacheable 
and strongly-ordered), while regular RAM is mapped as cacheable main 
memory.

S-mode paging can safely map these physical ranges without specifying 
page-based memory types in the PTEs, as the hardware MMU and PMA 
pipeline will correctly bypass caches for MMIO accesses based on the 
target physical address. Furthermore, on platforms that either feature 
fully hardware-coherent DMA or do not expose non-coherent DMA agents to 
the OS, page-level programmatic cache control via Svpbmt is not 
required, making it safe to boot and run when Svpbmt is absent.
```

  Xen already checks Svpbmt at
> runtime in some places (vcpu_csr_init()), but not everywhere:

This part sounds like there are additional places where you think the 
Svpbmt related bits should be set but I don’t see in this patch (or in 
others in this patch series_ where you are adding Svpbmt related bits to 
places where they weren’t added before. Am I missing something or did I 
misunderstand your message? If the latter then could you please re-word 
this part of the sentence.

> p2m_pte_from_mfn() and the PAGE_HYPERVISOR_NOCACHE/WC macros still set the
> raw PTE_PBMT* encoding unconditionally.
> 
> Drop Svpbmt from required_extensions, and introduce pte_pbmt(), which masks
> the requested PBMT encoding down to 0 when Svpbmt is unavailable, using it
> in both remaining unguarded spots.
> 
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> ---
>   xen/arch/riscv/cpufeature.c       | 1 -
>   xen/arch/riscv/include/asm/page.h | 8 ++++++--
>   xen/arch/riscv/p2m.c              | 2 +-
>   3 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
> index 92235fdfd5..900cb9d772 100644
> --- a/xen/arch/riscv/cpufeature.c
> +++ b/xen/arch/riscv/cpufeature.c
> @@ -157,7 +157,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
>       RISCV_ISA_EXT_DATA(zifencei),
>       RISCV_ISA_EXT_DATA(zihintpause),
>       RISCV_ISA_EXT_DATA(zbb),
> -    RISCV_ISA_EXT_DATA(svpbmt),
>   };

Also, please update docs/misc/riscv/booting.txt.

>   
>   static bool __init is_lowercase_extension_name(const char *str)
> diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
> index 5c02f64a17..6a3749526d 100644
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -11,6 +11,7 @@
>   #include <xen/types.h>
>   
>   #include <asm/atomic.h>
> +#include <asm/cpufeature.h>
>   #include <asm/page-bits.h>
>   
>   #define VPN_MASK                    (PAGETABLE_ENTRIES - 1UL)
> @@ -54,6 +55,9 @@
>   #define PAGE_HYPERVISOR_RX          (PTE_LEAF_DEFAULT | PTE_EXECUTABLE)
>   
>   #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
> +
> +#define pte_pbmt(pbmt) \
> +    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? (pbmt) : 0UL)

Checking the ISA string alone isn't sufficient.

Svpbmt in HS-mode is gated by menvcfg.PBMTE. If M-mode firmware hasn't 
set it, the hardware behaves as though Svpbmt were not implemented: bits 
[62:61] become reserved again, and a non-zero encoding raises a page 
fault (even though the DT ISA string advertises svpbmt). The same 
applies to the G-stage mappings built by p2m_pte_from_mfn() below.

menvcfg isn't readable from S-mode, but the spec gives an indirect 
probe: when menvcfg.PBMTE is 0, henvcfg.PBMTE is read-only zero. Xen 
already relies on exactly this in vcpu_csr_init() (ENVCFG_PBMTE & 
csr_masks.henvcfg). So it would be more robust to compute a single flag 
in init_csr_masks():

pbmt_enabled = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) 
&& (csr_masks.henvcfg & ENVCFG_PBMTE);

and have pte_pbmt() test that instead. This makes the check reflect what 
the hardware will actually honour rather than what the DT claims, and it 
also collapses the condition in vcpu_csr_init() to a single test.

 > +
 > +#define pte_pbmt(pbmt) \
 > +    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? 
(pbmt) : 0UL)

PAGE_HYPERVISOR_NOCACHE / PAGE_HYPERVISOR_WC are no longer constant 
expressions, they are now evaluated at each use site. riscv_fill_hwcap() 
runs fairly late in start_xen(), after setup_fixmap_mappings(), 
early_fdt_map() and setup_mm(). All current ioremap() callers (aplic.c, 
kernel.c) run after it, so the code is correct today, but this is an 
implicit dependency: any ioremap introduced earlier in boot would 
silently get PBMT=0 with no diagnostic. I don't know honestly speaking 
if it is a real issue.

Worth either documenting this with a comment next to pte_pbmt(), or 
adding an ASSERT() on the initialisation state. Switching to the 
__ro_after_init flag suggested above makes the dependency explicit, 
since the flag can be set alongside csr_masks, which is also populated 
after riscv_fill_hwcap().

 > +
 > +#define pte_pbmt(pbmt) \
 > +    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? 
(pbmt) : 0UL)

pte_pbmt(pbmt) reads like a PTE accessor, i.e. something with the 
signature pte_pbmt(pte) -> enum pbmt_type, especially given that enum 
pbmt_type is declared just below in the same header. What it actually 
does is convert a requested PBMT encoding into the encoding that may 
safely be written to a PTE on this hardware.

Something like PTE_PBMT() (matching the PTE_* naming of the values it 
takes) or pbmt_encoding() would convey that better.

~ Oleksii

>   /*
>    * PAGE_HYPERVISOR_NOCACHE is used for ioremap().
>    *
> @@ -61,8 +65,8 @@
>    * is that IO is non-idempotent and strongly ordered, which makes it a good
>    * candidate for mapping IOMEM.
>    */
> -#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PBMT_IO)
> -#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE)
> +#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_IO))
> +#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_NOCACHE))
>   
>   /*
>    * The PTE format does not contain the following bits within itself;
> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
> index 11dc289f0f..f6e635ec1d 100644
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -683,7 +683,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t,
>           switch ( t )
>           {
>           case p2m_mmio_direct_io:
> -            e.pte |= PTE_PBMT_IO;
> +            e.pte |= pte_pbmt(PTE_PBMT_IO);
>               break;
>   
>           default:



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 16:12:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 16:12:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402226.1637538 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzzC8-0002Zi-4E; Fri, 28 Aug 2026 16:12:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402226.1637538; Fri, 28 Aug 2026 16:12:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1wzzC8-0002ZX-0Z; Fri, 28 Aug 2026 16:12:44 +0000
Received: by outflank-mailman (input) for mailman id 1402226;
 Fri, 28 Aug 2026 16:12:43 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1wzzC6-0002ZR-UQ
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 16:12:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1wzzC6-007qgC-BS
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 18:12:42 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a91b367-e002-0a2a0a5209dd-0a2a4504a4ea-38
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 18:12:42 +0200
Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a91b37a-b57f-0a2a45040019-d155802acd80-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 18:12:42 +0200
Received: by mail-wm1-f42.google.com with SMTP id
 5b1f17b1804b1-498028b3d5eso12030395e9.1
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 09:12:42 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49b92671c0esm47837215e9.2.2026.08.28.09.12.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Aug 2026 09:12:40 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1787933562; x=1788538362; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=cFFnLgEu/Pj3/zEntHheW6P0KjkDstF9mmmhddEwrR0=;
        b=WK/RMlCP0lquUwi8R3nNxaFzskNfYPiC5uoy/QZSi7VGEA2lfqTio2VIBJIaZYpWh4
         6NWiilynwtR/eSmqDc0GNHDY6PicfbE4fXm8hC9jxaV/Px3/XFCM1AhBgVRZh0E5VaAA
         De+Nw9mm5NSAlgnLVKTYRaHdT5fQVOw+qw+pxtON140LXTbTT0nz1RQGEjXPtDmCrcMv
         qh7AFhrputg56xhMkW1/MVt7dLppUkb1XPAWo62kNcHp2HKyHUzS4ScqTyiliZVk8lai
         v2fsIzZk/ULyICV17cdEPFaSogBuF4r8ehDymNWJKmEWEacR78VWmgM3NSRdRqXCrvD7
         GRWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1787933562; x=1788538362;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=cFFnLgEu/Pj3/zEntHheW6P0KjkDstF9mmmhddEwrR0=;
        b=AvSebrmboGx0j6TbnR4vGITSNBzbisNliXIbBHZXlQbqTwLP7SZlyeGrNNU+3jYEEn
         olZR6LGTK5HAyK6w4qhFhbSHY3tiS8O+v5yfsfc8eZHDu3JKhYFU7ThS7C6OviQXHQLV
         mh2aeBe77z61sDbJhR//aXWmbqla0Rsbk5jCrRn1x6l5qZJxFjWX9yJcpIdQ5W0V3MsO
         75BIvh6O8UCaueb/nxSPlSjbyI9Z+oPD0AvL2A4XnLbv7/IVfuQuJHKqkYdkkuJyqsx7
         Lt7jOGAN74flSbdDKlG5Vb6/ey4dV+JO4yfz2Uz84PKjeAqUWj5gkIoOBL9K/LHekGNj
         dWyw==
X-Gm-Message-State: AFuF++k90YvautKtf3Hl7nGSw/qQ5orwuNpg+E3wjYDiWwn0EUi2B50f
	mxlTLdJkbze2DlMaWnQ6zoj7WevOjFbWnONbpU7QlBLVPvymp/dnZ4mS
X-Gm-Gg: AR+sD10rDW3NXS9A4mWWNUwa+s5LYkUdCQw6eGQsQqzJ866X7qgtLju/KVWrMcJisD6
	KzNRyER0aSxmDN7dzzPQuLpRdMNap9KyY1ipHTafqJ0kTTd80RYLbKOC34qmI4MjR5vVgRjH+cO
	KKc9JISZGqaef8qhzknnSoFZUFiQHY55dUqgZ4+XZR9zPwPr6UoS7gmZjy05wvxOaYhL9U/lGiW
	jLE91ZY3kvpvY1vODozZYpcWTav72fOQiWTxH8cFtWiaFHF5nNoXlSYZFT2KDfLo2LmP6HNIcZB
	RI2tbKuPOUODSz4Uy7SLTUZXZUk5xjd9CZ4JBTI4aRDRZyv1Ca2/GyPYOsXXXXzkPrTbG6go9hR
	t/0BC6/9GIiLiVgpbGkxEs4uJY6h+OSJkVj6zjNk/7SDuF9xcNjj7IJjzuN4bVJte0LqLWzgAvP
	1Xg//GIyd8uVka2Hsha3XK5YxFC0OirNw+RdIyi10TFQ0l6Chd9JTuZIlKDSvfPYy9gxcWV36EE
	sdpr0UYMUsybnfKqBdp7Z6LLSND3kddK+3TsVj4dw==
X-Received: by 2002:a05:600c:4f8b:b0:49a:2c4b:403f with SMTP id 5b1f17b1804b1-49b91c46494mr103032445e9.13.1787933561390;
        Fri, 28 Aug 2026 09:12:41 -0700 (PDT)
Message-ID: <caeaf406-6280-4b72-ae94-05da70408ea4@gmail.com>
Date: Fri, 28 Aug 2026 18:12:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/5] xen/riscv: always set A/D bits at boot time
To: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Cc: xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Andrew Cooper <andrew.cooper3@citrix.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@vates.tech>
 <3adf6ef7-8024-420f-935b-17b142c73256@gmail.com>
 <1787925495.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@vates.tech>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <1787925495.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@vates.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787933562-C14D3B50-A3052D16/10/73395122804
X-purgate-type: spam
X-purgate-size: 14033



On 8/28/26 3:58 PM, Baptiste Le Duc wrote:
> On 2026-08-28 12:59 +0200, Oleksii Kurochko wrote:
>>
>>
>> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
>>> Always set the PTE A/D bits at boot time to avoid an unhandled page fault
>>> on platforms that implement neither Svade nor Svadu, and on platforms that
>>> declare both in the device tree.
>>>
>>> Rewrite the comment to enumerate the four possible Svade/Svadu combinations
>>> (inspired by [1]) and set A/D unconditionally, which is correct in all four
>>> cases until Svadu is fully supported (full support requires the SBI FWFT
>>> call to enable hardware updating of A/D bits).
>>>
>>> [1] https://lwn.net/Articles/980016/
>>>
>>> Assisted-by: Claude:claude-opus-5
>>> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
>>> ---
>>>    xen/arch/riscv/p2m.c | 70 ++++++++++++++++++++++++++------------------
>>>    1 file changed, 42 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
>>> index 1cea86512c..11dc289f0f 100644
>>> --- a/xen/arch/riscv/p2m.c
>>> +++ b/xen/arch/riscv/p2m.c
>>> @@ -591,38 +591,52 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
>>>        e->pte |= PTE_USER;
>>>    
>>>        /*
>>> -     * Two schemes to manage the A and D bits are defined:
>>> -     *   • The Svade extension: when a virtual page is accessed and the A bit
>>> -     *     is clear, or is written and the D bit is clear, a page-fault
>>> -     *     exception is raised.
>>> -     *   • When the Svade extension is not implemented, the following scheme
>>> -     *     applies.
>>> -     *     When a virtual page is accessed and the A bit is clear, the PTE is
>>> -     *     updated to set the A bit. When the virtual page is written and the
>>> -     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
>>> -     *     address translation is in use and is not Bare, the G-stage virtual
>>> -     *     pages may be accessed or written by implicit accesses to VS-level
>>> -     *     memory management data structures, such as page tables.
>>> -     * Thereby to avoid a page-fault in case of Svade is available, it is
>>> -     * necessary to set A and D bits.
>>> +     * Svade and Svadu extensions represent two schemes for managing the PTE
>>> +     * A/D bits. When the PTE A/D bits need to be set, the Svade extension
>>> +     * indicates that a page fault will be raised. In contrast, the Svadu
>>> +     * extension supports hardware updating of the PTE A/D bits.
>>>         *
>>> -     * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI
>>> -     *       delegates page faults to a lower privilege mode and so OpenSBI
>>> -     *       isn't expect to handle page-faults occured in lower modes.
>>> -     *       By setting the A/D bits here, page faults that would otherwise
>>> -     *       be generated due to unset A/D bits will not occur in Xen.
>>> +     * There are 4 possible combinations of these extensions in the device
>>> +     * tree. The default hardware behavior for each is:
>>>         *
>>> -     *       Currently, Xen on RISC-V does not make use of the information
>>> -     *       that could be obtained from handling such page faults, which
>>> -     *       could otherwise be useful for several use cases such as demand
>>> -     *       paging, cache-flushing optimizations, memory access tracking,etc.
>>> +     * 1) Neither Svade nor Svadu present in DT => It is technically unknown
>>> +     *    whether the platform uses Svade or Svadu. Xen should be prepared to
>>> +     *    handle either hardware updating of the PTE A/D bits or page faults
>>> +     *    when they need updating. To support both, Xen always sets the 'A' and
>>> +     *    'D' PTE bits at boot time.
>>>         *
>>> -     *       To support the more general case and the optimizations mentioned
>>> -     *       above, it would be better to stop setting the A/D bits here and
>>> -     *       instead handle page faults that occur due to unset A/D bits.
>>> +     * 2) Only Svade present in DT => Xen must assume Svade to be always
>>> +     *    enabled.
>>> +     *
>>> +     * 3) Only Svadu present in DT => Xen must assume Svadu to be always
>>> +     *    enabled.
>>> +     *
>>> +     * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
>>> +     *    off at boot time by setting A/D bits. To use Svadu, the supervisor
>>> +     *    must explicitly enable it using the SBI FWFT extension.
>>> +     *
>>> +     * The Svade extension is mandatory and the Svadu extension is optional in
>>> +     * the RVA23 profile. Platforms wanting to take advantage of Svadu can
>>> +     * choose option 3. Platforms aware of the profile can choose option 4, and
>>> +     * Linux won't get the benefit of Svadu until the SBI FWFT extension is
>>> +     * available.
>>
>> I have a feeling that the DT-binding-related comment should not be
>> present here, as it explains when Svadu or Svade should be considered
>> enabled or disabled. We should perform this kind of detection in
>> riscv_fill_hwcap() [cpufeature.c]. Then, in p2m_set_permission(), we
>> should use riscv_isa_extension_available() to determine which extension
>> is available and, based on that, set the A and D bits.
>>
>> At this point, I think the original comment was better, as it simply
>> explained what Svade and Svadu are and, therefore, provided a better
>> explanation of why the A and D bits should or should not be set.
>>
>> So, my suggestion is the following:
>>
>> +/*
>> + * Svade and Svadu extensions represent two schemes for managing the PTE
>> + * A/D bits. When the PTE A/D bits need to be set, the Svade extension
>> + * indicates that a page fault will be raised. In contrast, the Svadu
>> + * extension supports hardware updating of the PTE A/D bits.
>> + *
>> + * There are 4 possible combinations of these extensions in the device
>> tree.
>> + * The default hardware behavior for each is:
>> + *
>> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown
>> + *    whether the platform uses Svade or Svadu. Xen should be prepared to
>> + *    handle either hardware updating of the PTE A/D bits or page
>> faults when
>> + *    they need updating. To support both, Xen always sets the 'A' and
>> 'D' PTE
>> + *    bits at boot time.
>> + *
>> + * 2) Only Svade present in DT => Xen must assume Svade to be always
>> enabled.
>> + *
>> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always
>> enabled.
>> + *
>> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
>> + *    off at boot time by setting A/D bits. To use Svadu, the
>> supervisor must
>> + *    explicitly enable it using the SBI FWFT extension.
>> + *
>> + * The Svade extension is mandatory and the Svadu extension is optional
>> in the
>> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose
>> + * option 3. Platforms aware of the profile can choose option 4, and
>> Xen won't
>> + * get the benefit of Svadu until the SBI FWFT extension is available.
>> + *
>> + * In other words, hardware manages the A/D bits on its own only in case 3;
>> + * in all the other cases software has to preset them. Instead of open
>> coding
>> + * this in every A/D bits user, RISCV_ISA_EXT_svade is used to mean
>> "software
>> + * is responsible for the A/D bits" and is set here for the cases 1, 2
>> and 4.
>> + */
>> +static void __init riscv_resolve_ad_scheme(void)
>> +{
>> +    bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade);
>> +    bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu);
>> +
>> +    /* Case 3: leave the A/D bits management to hardware. */
>> +    if ( svadu && !svade )
>> +        return;
>> +
>> +    /* Cases 1, 2 and 4: Xen has to preset the A/D bits. */
>> +    __set_bit(RISCV_ISA_EXT_svade, riscv_isa);
>> +}
>> +
>>    void __init riscv_fill_hwcap(void)
>>    {
>>        unsigned int i;
>> @@ -513,6 +560,8 @@ void __init riscv_fill_hwcap(void)
>>            __set_bit(RISCV_ISA_EXT_sstc, riscv_isa);
>>        }
>>
>> +    riscv_resolve_ad_scheme();
>> +
>>
>> And then ...
>>
>>
>>> +     *
>>> +     * Currently, Xen on RISC-V does not make use of the information that could
>>> +     * be obtained from handling such page faults, which could otherwise be
>>> +     * useful for several use cases such as demand paging, cache-flushing
>>> +     * optimizations, memory access tracking, etc.
>>> +     *
>>> +     * To support the more general case and the optimizations mentioned above,
>>> +     * it would be better to stop setting the A/D bits here and instead handle
>>> +     * page faults that occur due to unset A/D bits.
>>> +     */
>>> +
>>> +    /*
>>> +     * Preset unconditionally for all 4 cases above, harmless when Svadu
>>> +     * manages the bits (case 3). Skipping it for case 3 requires SBI FWFT
>>> +     * which is not yet supported.
>>>         */
>>> -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
>>> -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
>>> +    e->pte |= PTE_ACCESSED | PTE_DIRTY;
>>
>> ... we could restore the check and the comment we originally had in
> 
> Yes it makes sense as we now manually force the svade extension in 1, 2
> and 4 cases.
> 
>> p2m_set_permission(), but probably with some updates, something along
>> the following lines:
>>
>> /*
>>    * Xen has to preset the A/D bits unless the hardware is known to update
>>    * them on its own. riscv_fill_hwcap() folds all the Svade/Svadu device
>>    * tree combinations into RISCV_ISA_EXT_svade, which then means that
>>    * software is responsible for the A/D bits" (see
>>    * riscv_resolve_ad_scheme()).
>>    */
>>
>> I have another comment regarding:
>>
>>   > +    /*
>>   > +     * Preset unconditionally for all 4 cases above, harmless when Svadu
>>   > +     * manages the bits (case 3). Skipping it for case 3 requires
>> SBI FWFT
>>   > +     * which is not yet supported.
>>   >        */
>>   > -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
>>   > -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
>>   > +    e->pte |= PTE_ACCESSED | PTE_DIRTY;
>>
>> I am not sure that this comment is correct. In case 3, we should not
>> need to use the SBI FWFT extension. Case 3 means that Xen must assume
>> that Svadu is enabled. Therefore, it is the responsibility of OpenSBI,
>> or the pre-bootloader that loads OpenSBI, to enable it. If it fails to
>> do so, then OpenSBI or the pre-bootloader is not complying with the DT
>> binding documentation and it should be fixed in first place.
> 
> You right, thanks
>>
>> As further evidence, this is what OpenSBI already does [1]:
>> /*
>>    * Assume only Svadu is supported when it is the only extension
>>    * present in the ISA string. Svade is assumed when neither are
>>    * present. When both are present we must default to Svade (see
>>    * the zero reset value of FWFT.PTE_AD_HW_UPDATING).
>>    */
>> if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE))
>>       __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE);
>>
>> Therefore, in case 3, the original check is still valid, and there is no
>> need for Xen to support the SBI FWFT extension for this case. I think
>> the original check should therefore be kept as it was:
> 
> Yes agree, I'll change that in v2.
> 
>> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
>>       e->pte |= PTE_ACCESSED | PTE_DIRTY;
>>
>> The SBI FWFT extension is only required for case 4. If both Svade and
>> Svadu are present in the DT, Svade is selected by default. To use Svadu
>> instead, SBI FWFT is required to set the ADUE bit in menvcfg, which is
>> only accessible from M-mode.
>>
>> Since SBI FWFT is relatively new and may not be supported by older
>> OpenSBI versions, another option is to have OpenSBI hard-code ADUE=1.
>> Alternatively, the DTS could specify only one of Svade or Svadu in the
>> riscv,isa property. In that case, upstream OpenSBI can handle the
>> configuration automatically. So specifically for our case (Svadu and
>> Svade things) we don't need SBI FWFT at all.
> 
> So if I understood correclty, you want to not let the option to change
> ADUE bits in case 4 right? Therefore, I think we should document that
> somewhere to clearly indicates that if someone want to use Svadu, he
> should remove `svade` in the riscv,isa DT property.

Yes, that is exactly correct. Without SBI FWFT support, Xen cannot 
toggle menvcfg.ADUE in Case 4. Thus, the only viable workaround to use 
Svadu is to remove 'svade' from the riscv,isa DT property (Case 3), 
which prompts OpenSBI to enable ADUE=1 at boot time.

I agree document that somewhere will make this behavior/intention clear!

Not insisting on that:
I also think it would be a good idea to add an early printk() warning in 
the detection logic when both Svade and Svadu are present but SBI FWFT 
is missing, guiding users to drop 'svade' from their DT if they want to 
leverage Svadu. Something like:

if ( svade && svadu )
{
     /* Assuming sbi_fwft_is_supported() or similar probe is available */
     if ( !sbi_probe_extension(SBI_EXT_FWFT) )
     {
         printk(XENLOG_WARNING
                "RISC-V: Both Svade and Svadu detected, but SBI FWFT is 
missing.\n"
                "RISC-V: Defaulting to software A/D updates (Svade).\n"
                "RISC-V: To force hardware A/D updates (Svadu), remove 
'svade' from DT.\n");
     }
}

somewhere in the function (riscv_resolve_ad_scheme) I suggested above.

>>
>> [1]
>> https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_hart.c#L171
>>
> Thanks for this very clear review.

Welcome.

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Fri Aug 28 20:44:16 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 20:44:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402455.1637548 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03Qb-0003FG-9b; Fri, 28 Aug 2026 20:43:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402455.1637548; Fri, 28 Aug 2026 20:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03Qb-0003Eu-4C; Fri, 28 Aug 2026 20:43:57 +0000
Received: by outflank-mailman (input) for mailman id 1402455;
 Fri, 28 Aug 2026 20:43:55 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1x03QZ-0003Eo-Ki
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 20:43:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x03QY-00DUag-TC
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 22:43:54 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f2cc-bab6-0a2a0a5309dd-0a2a4502bce6-14
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:43:54 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f309-6ca4-0a2a45020019-aa0a857c50f7-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:43:54 +0200
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-678-0Ob0tm8COMqsk2YHk8nb0w-1; Fri,
 28 Aug 2026 16:43:49 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 3ADE51944CE7; Fri, 28 Aug 2026 20:43:47 +0000 (UTC)
Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.116])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id B91FF18001CF; Fri, 28 Aug 2026 20:43:45 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787949833;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=eoW7o2w3JwJ3/PKM3kaLrXOjzHuADU29Xw8e0B2gWQc=;
	b=BTj7b+9xJNLeF0Eb1hpzw3bJNirBaH9S3rHcQEM4aVz5vZBXoVctpGPbMqoemyhtogu3XM
	v9dJcjDgoFz/UJUDVFe8RAbvkmTu/69piB3m/jjhRoTawzj3EovnwU+VwyBNDvWKFQ9Ozl
	22dLtKUu3+KEqAVpY9t6r0C0vftoDII=
X-MC-Unique: 0Ob0tm8COMqsk2YHk8nb0w-1
X-Mimecast-MFC-AGG-ID: 0Ob0tm8COMqsk2YHk8nb0w_1787949827
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sat, 29 Aug 2026 00:42:09 +0400
Subject: [GIT PULL 30/50] monitor: isolate HMP declarations in hmp.h
MIME-Version: 1.0
Message-Id: <20260829-nohmp-v1-30-4dcc2b4b0055@redhat.com>
References: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
In-Reply-To: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
To: qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 "Michael S. Tsirkin" <mst@redhat.com>, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 "Dr. David Alan Gilbert" <dave@treblig.org>, 
 Markus Armbruster <armbru@redhat.com>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Jason Wang <jasowangio@gmail.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=15946;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=ZxP2zuDU77QuYSgeDP8Q6OgGS3abQd+ghG/LNZ1fqlc=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkfKV+TiBXIR4jlgcsWZeWMBsAT4CApvmu2jsA
 ftWJcS3GnCJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapHylQAKCRDa6OEJdZac
 5Rk/D/455eZoCiTR9S9WIn0xamX12ONzpRLrbFXzA5SfJEe542d5yawTFv1VjjY/ehGgKjTgefl
 q2Tpr3RpgG1TLjcOMVxnk7rcX6ATgKk97EI5qhrnwSz+7mVoh4yyvo5f8ZMv+UWzvrwyllAdm3r
 jK8Lm5QXVtkInMNJLinALKrL+aNyxQR8kt41NWu3BKclNOMkWpYrZUt1BFY8rWYQkNT8XKjUJY7
 bLqQzTsEjHeZZOrwACSqHyM/Niw8kF0pRPvS0z1e2gdxJcnnNn3E5pzW1E5Scw9/+Ad9fAAU9ES
 KF/SNdkBmNzgQrirb8VMfT4N9enbLoiY+kmHI4rPOzT920czgfU8oZ/A7X0Vp9DrEPSDuQYcdBO
 KWkSz7APd8gAIg4PEQ1qGuzWDwtNRPuynUUk6XkJgpxiL8nnh3wYN7Qy/CE5W537rvH+qqrYW73
 RBbRDQMuGuLWtp6JglPTbuzrCigYHto5n5OK/nfDBgvR8lgugyQKTqAxZdkX7X/moL9rt3DOPBU
 4YOAK0EJe4OSw57zmZF9K4OtBo7gPYpZ7K6kwLhB9pZ/bEAVDTz1OnGMh+mYPh6NEMpGr0ZpBZ4
 bVnYj/6Q0v8NIsq7zWdXhjrXW9kIFtEHOU2jevBQ1IWD7v7fYwJ5EtmHW590/WEw+fnAwkOdNKd
 JiEeBQ7dbCPsp3Q==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: m6mhDeTe4-mu7yklbX6OVMeNxDet2eO2aeCffyIqKPQ_1787949827
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1787949834-307C22AC-76BC27A9/0/0
X-purgate-type: clean
X-purgate-size: 15948

Also rename password & commands with hmp in the name, while at it.
Other functions need larger changes which we will take care of next.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-30-9227de146347@redhat.com>
---
 accel/accel-system.c           |  1 +
 accel/tcg/monitor.c            |  1 +
 chardev/char.c                 |  2 +-
 disas/disas-mon.c              |  1 +
 gdbstub/system.c               |  2 +-
 hw/char/virtio-serial-bus.c    |  1 +
 hw/core/machine-hmp-cmds.c     |  1 -
 hw/core/sysbus.c               |  1 +
 hw/hexagon/hexagon_tlb.c       |  1 +
 hw/misc/auxbus.c               |  1 +
 hw/usb/bus.c                   |  1 +
 hw/usb/host-libusb.c           |  1 +
 hw/xen/xen-bus.c               |  1 +
 include/monitor/hmp.h          | 21 +++++++++++++++++++++
 include/monitor/monitor.h      | 18 ------------------
 monitor/hmp.c                  |  8 ++++----
 monitor/monitor-internal.h     |  1 +
 net/slirp.c                    |  1 +
 stubs/monitor-core.c           |  1 +
 stubs/monitor-internal.c       |  2 +-
 target/rx/disas.c              |  1 +
 tests/unit/test-util-sockets.c |  1 +
 tools/qemu-vnc/stubs.c         |  1 +
 trace/trace-hmp-cmds.c         |  1 -
 ui/ui-hmp-cmds.c               |  4 ++--
 util/error-report.c            |  2 +-
 util/qemu-print.c              |  1 +
 27 files changed, 48 insertions(+), 30 deletions(-)

diff --git a/accel/accel-system.c b/accel/accel-system.c
index 9176665202d2..977804c4048a 100644
--- a/accel/accel-system.c
+++ b/accel/accel-system.c
@@ -28,6 +28,7 @@
 #include "qom/compat-properties.h"
 #include "qapi/qapi-commands-accelerator.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "hw/core/boards.h"
 #include "hw/core/cpu.h"
 #include "accel/accel-ops.h"
diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c
index be5c1950177c..74170ddef708 100644
--- a/accel/tcg/monitor.c
+++ b/accel/tcg/monitor.c
@@ -11,6 +11,7 @@
 #include "qapi/type-helpers.h"
 #include "qapi/qapi-commands-machine.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/tcg.h"
 #include "tcg/tcg.h"
 #include "internal-common.h"
diff --git a/chardev/char.c b/chardev/char.c
index c6c8133f5c1d..9da0911e503c 100644
--- a/chardev/char.c
+++ b/chardev/char.c
@@ -24,7 +24,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "monitor/qmp-helpers.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index 9c693618c277..bc9dec3a7761 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -10,6 +10,7 @@
 #include "system/memory.h"
 #include "hw/core/cpu.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 /*
  * Get LENGTH bytes from info's buffer, at target address memaddr.
diff --git a/gdbstub/system.c b/gdbstub/system.c
index 070bc26f416c..8a1cdb11db36 100644
--- a/gdbstub/system.c
+++ b/gdbstub/system.c
@@ -29,7 +29,7 @@
 #include "hw/core/boards.h"
 #include "chardev/char.h"
 #include "chardev/char-fe.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "internals.h"
 
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index c1973f0248fc..02604740f86a 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -25,6 +25,7 @@
 #include "qemu/module.h"
 #include "migration/qemu-file-types.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/queue.h"
 #include "hw/core/qdev-properties.h"
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 686304bafab5..1c700aad3587 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -15,7 +15,6 @@
 
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-builtin-visit.h"
 #include "qapi/qapi-commands-accelerator.h"
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 3e1160ee921d..13df7cbafe10 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -21,6 +21,7 @@
 #include "qapi/error.h"
 #include "hw/core/sysbus.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index b6d4aff389e5..2d878cee736d 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -12,6 +12,7 @@
 #include "hw/core/resettable.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "exec/page-protection.h"
 #include "exec/target_page.h"
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 877f34560626..ac2525b90fec 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -33,6 +33,7 @@
 #include "hw/misc/auxbus.h"
 #include "hw/i2c/i2c.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 
 #ifndef DEBUG_AUX
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 3b6fbd46ac3f..9b9b2e7c2f8f 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -9,6 +9,7 @@
 #include "system/system.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "trace.h"
 #include "qemu/cutils.h"
 
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index b9f3ad3f66dd..af67d5dfeb10 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -48,6 +48,7 @@
 #include "qapi/error.h"
 #include "migration/vmstate.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "qemu/module.h"
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index dfad2bc5085f..a563f6066bb4 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -17,6 +17,7 @@
 #include "hw/xen/xen-bus.h"
 #include "hw/xen/xen-bus-helper.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/error.h"
 #include "qobject/qdict.h"
 #include "system/system.h"
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 9258a049bffb..166cd4100c63 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -18,6 +18,9 @@
 #include "qapi/qapi-types-common.h"
 #include "monitor/monitor.h"
 
+#define TYPE_MONITOR_HMP "monitor-hmp"
+OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
+
 #define HMP_STUB(cmd) \
     void hmp_##cmd(Monitor *mon, const QDict *qdict) \
     { \
@@ -30,6 +33,24 @@ struct MonitorDef {
     int64_t (*get_value)(Monitor *mon, const MonitorDef *md, int offset);
 };
 
+void monitor_new_hmp(const char *id, const char *chardev_id,
+                     bool use_readline, Error **errp);
+
+int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+    G_GNUC_PRINTF(2, 0);
+int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_printc(Monitor *mon, int ch);
+
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque);
+
+void monitor_register_hmp(const char *name, bool info,
+                          void (*cmd)(Monitor *mon, const QDict *qdict));
+void monitor_register_hmp_info_hrt(const char *name,
+                                   HumanReadableText *(*handler)(Error **errp));
+
+
 CPUArchState *mon_get_cpu_env(Monitor *mon);
 CPUState *mon_get_cpu(Monitor *mon);
 
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 9f048ba103b5..72a8f6ea5b4f 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -10,9 +10,6 @@
 #define TYPE_MONITOR "monitor"
 OBJECT_DECLARE_TYPE(Monitor, MonitorClass, MONITOR);
 
-#define TYPE_MONITOR_HMP "monitor-hmp"
-OBJECT_DECLARE_TYPE(MonitorHMP, MonitorHMPClass, MONITOR_HMP);
-
 #define TYPE_MONITOR_QMP "monitor-qmp"
 OBJECT_DECLARE_TYPE(MonitorQMP, MonitorQMPClass, MONITOR_QMP);
 
@@ -30,8 +27,6 @@ void monitor_init_globals_core(void);
 char *monitor_compat_id(void);
 void monitor_new_qmp(const char *id, const char *chardev_id,
                      bool pretty, Error **errp);
-void monitor_new_hmp(const char *id, const char *chardev_id,
-                     bool use_readline, Error **errp);
 int monitor_new(MonitorOptions *opts, bool allow_hmp, Error **errp);
 int monitor_new_opts(QemuOpts *opts, Error **errp);
 void monitor_cleanup(void);
@@ -43,28 +38,15 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp);
 int monitor_fd_param(Monitor *mon, const char *fdname, Error **errp);
 
 int monitor_puts(Monitor *mon, const char *str);
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
 void monitor_flush(Monitor *mon);
 int monitor_get_cpu_index(Monitor *mon);
 
 int monitor_puts_locked(Monitor *mon, const char *str);
 void monitor_flush_locked(Monitor *mon);
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt);
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque);
-
 AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, int64_t fdset_id,
                                 const char *opaque, Error **errp);
 int monitor_fdset_dup_fd_add(int64_t fdset_id, int flags, Error **errp);
 void monitor_fdset_dup_fd_remove(int dup_fd);
 
-void monitor_register_hmp(const char *name, bool info,
-                          void (*cmd)(Monitor *mon, const QDict *qdict));
-void monitor_register_hmp_info_hrt(const char *name,
-                                   HumanReadableText *(*handler)(Error **errp));
-
 #endif /* MONITOR_H */
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 8134dfaad4bb..b4d05d47c4bf 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -136,7 +136,7 @@ static void monitor_command_cb(void *opaque, const char *cmdline,
     monitor_resume(&hmp->parent_obj);
 }
 
-void monitor_read_command(MonitorHMP *hmp, int show_prompt)
+void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt)
 {
     if (!hmp->rs) {
         return;
@@ -148,8 +148,8 @@ void monitor_read_command(MonitorHMP *hmp, int show_prompt)
     }
 }
 
-int monitor_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
-                          void *opaque)
+int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
+                              void *opaque)
 {
     if (hmp->rs) {
         readline_start(hmp->rs, "Password: ", 1, readline_func, opaque);
@@ -1647,7 +1647,7 @@ static void monitor_hmp_complete(UserCreatable *uc, Error **errp)
                                     monitor_readline_flush,
                                     hmp,
                                     monitor_find_completion);
-            monitor_read_command(hmp, 0);
+            monitor_hmp_read_command(hmp, 0);
         }
 
         qemu_chr_fe_set_handlers(&hmp->parent_obj.chr,
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index fdeeeb853636..ee9ba0c8231e 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -27,6 +27,7 @@
 
 #include "chardev/char-fe.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 #include "qapi/qapi-types-control.h"
 #include "qapi/qapi-types-qom.h"
diff --git a/net/slirp.c b/net/slirp.c
index 517dd23be14b..9bf09a2c8bc9 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -36,6 +36,7 @@
 #include "clients.h"
 #include "hub.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 #include "qemu/sockets.h"
 #include <libslirp.h>
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index a7c32297c90a..b0c7002bd406 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qapi/qapi-emit-events.h"
 
 Monitor *monitor_cur(void)
diff --git a/stubs/monitor-internal.c b/stubs/monitor-internal.c
index 731fad221ecc..6f69f1f14ae4 100644
--- a/stubs/monitor-internal.c
+++ b/stubs/monitor-internal.c
@@ -1,6 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
 {
diff --git a/target/rx/disas.c b/target/rx/disas.c
index 67b932882914..0eb2ee6f4507 100644
--- a/target/rx/disas.c
+++ b/target/rx/disas.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 #include "disas/dis-asm.h"
 #include "qemu/bitops.h"
+#include "monitor/hmp.h"
 #include "cpu.h"
 
 typedef struct DisasContext {
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index ab3f39c3efb5..b2a884529598 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -24,6 +24,7 @@
 #include "qapi/error.h"
 #include "socket-helpers.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 
 static void test_fd_is_socket_bad(void)
 {
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 1c82d8cff430..26597fefaa99 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -9,6 +9,7 @@
 #include "system/runstate.h"
 #include "hw/core/qdev.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "migration/vmstate.h"
 
 bool runstate_is_running(void)
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 390173095cff..c8f0133abecf 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -25,7 +25,6 @@
 #include "qemu/osdep.h"
 #include "monitor/hmp.h"
 #include "monitor/hmp-completion.h"
-#include "monitor/monitor.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-trace.h"
 #include "qobject/qdict.h"
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 806a7bece7cb..4ef459490ba2 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -327,7 +327,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
                                 void *readline_opaque)
 {
     qmp_change_vnc_password(password, NULL);
-    monitor_read_command(opaque, 1);
+    monitor_hmp_read_command(opaque, 1);
 }
 
 void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
@@ -344,7 +344,7 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
     }
     if (!arg) {
         MonitorHMP *hmp = MONITOR_HMP(mon);
-        monitor_read_password(hmp, hmp_change_read_arg, NULL);
+        monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
     }
diff --git a/util/error-report.c b/util/error-report.c
index f333af9249b9..aaa15bc79827 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -11,7 +11,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/error-report.h"
 
 /*
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 7b9591035e57..a2d1f0244168 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -12,6 +12,7 @@
 
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
+#include "monitor/hmp.h"
 #include "qemu/qemu-print.h"
 
 /*

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 20:44:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 20:44:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402458.1637556 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03RC-0003gB-Iq; Fri, 28 Aug 2026 20:44:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402458.1637556; Fri, 28 Aug 2026 20:44:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03RC-0003g4-Fx; Fri, 28 Aug 2026 20:44:34 +0000
Received: by outflank-mailman (input) for mailman id 1402458;
 Fri, 28 Aug 2026 20:44:32 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1x03RA-0003fa-By
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 20:44:32 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x03R9-004EBF-PI
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 22:44:31 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f30d-2eae-0a2a0a5409dd-0a2a4509db90-24
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:44:31 +0200
Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f32e-be1a-0a2a45090019-aa0a817c8243-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:44:31 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-351-G-B1MgVaN6aAdqTWAoTJ1g-1; Fri,
 28 Aug 2026 16:44:26 -0400
Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 6F4FA180AEBE; Fri, 28 Aug 2026 20:44:25 +0000 (UTC)
Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.116])
 by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 7BDAE7D9; Fri, 28 Aug 2026 20:44:23 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787949870;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=3tt1Li1Xgl8ddzlGr2B8S7+Mrjv2YOxklMy5kdNutVQ=;
	b=UX6hmHZZknY2GIjDI9G7HYl7Ip9Hka2I1ivTaII4xyv1o5H35sqcUXCqwlgJjDr+edYLaa
	oPozOLfbVJGfTtN/zdVBsSgrdOxnJMmz4CAdC/V69xc2YMUjtmbBLKXkGbqrzkOLTMRo5d
	dJDLfBuy48jF4u/v+tPItSmWZTOerP8=
X-MC-Unique: G-B1MgVaN6aAdqTWAoTJ1g-1
X-Mimecast-MFC-AGG-ID: G-B1MgVaN6aAdqTWAoTJ1g_1787949865
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sat, 29 Aug 2026 00:42:18 +0400
Subject: [GIT PULL 39/50] qdev-monitor: make print_dev() callback take
 MonitorHMP
MIME-Version: 1.0
Message-Id: <20260829-nohmp-v1-39-4dcc2b4b0055@redhat.com>
References: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
In-Reply-To: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
To: qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, 
 =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=8864;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=yhdT14CCjQBH3XB2MAJuktkFy3BQqu+3tvJiv7NtYD0=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkfKVBF+dcyUO8acre9UTIyRuoRk5B+6NoKVbf
 7ZzLN0hGDWJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapHylQAKCRDa6OEJdZac
 5UaaD/9PPDFeyFi0aR/4kzKPGwlgkCol/O9YralbhXK29ecxzlJ+wH091XOW6kXWjWElEC8yTFA
 buzgJKN5PjmbRZujJ9d3fal8WRUFzKZXVTCSog09Qx6oEh152mndo+Cy4OCwzzYuz9X72x2w/ZB
 mWZyqBQm5eTqZSkHlLMoMaJkBswcZfbtbxhl/R0DQKZCMfrPrKxy9kdScAWKI8ieSLlGExbHlJS
 TXbyWOtNmNj866rjZbFUq7182tz3TxNIRbVjf+ySp1eTqt1/Ea44Raigg8H76MXyr32qL+evKEd
 3NJNhd8mmQ4akyy/rERBnfbXd/kv0GqPYDMa/3K5f95zmoZzGSiLz+3meD5hTVLN/SS6LUKnRtZ
 Kod+sawsBvlO4EkUtOSFeU7Sl2XE7/ac7joV8YJTtcqOn2jDkjl1pccM0aCHX2YVWkN71rdlVlN
 qSMIfP/m6zHBAgkqQl5hk0VjkfAgHwpK5V3fLt+8bY/9Bl6goLi+ZynO29rL2IxUhCinwN6ooxe
 y6sIwxCMellb7FgfyR2hYjV6a7GVdXCl3PitikvNK9UcoCZVBCVcz9v3ZcZxZgdLh1ShnusKb1J
 RE3uzD7M/nN4A5lVnoGxzI4iTlqezeuapZ6B7BExz1xFvjjA3Wlt9VAMQueIBVm+/NEp64A0TSk
 jYfAc+kD9ts/r6w==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95
X-Mimecast-MFC-PROC-ID: 0ufPQ28szVWy1dpHBGvB80qMnnlSNoahloSybO1NPQk_1787949865
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1787949871-BD6C2034-FC4386C8/0/0
X-purgate-type: clean
X-purgate-size: 8866

The callback is specific to HMP context, avoid unsafe MONITOR_HMP()
cast.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-39-9227de146347@redhat.com>
---
 hw/char/virtio-serial-bus.c | 6 +++---
 hw/core/sysbus.c            | 5 ++---
 hw/misc/auxbus.c            | 7 +++----
 hw/pci/pci-hmp-cmds.c       | 3 +--
 hw/pci/pci-internal.h       | 2 +-
 hw/usb/bus.c                | 5 ++---
 hw/xen/xen-bus.c            | 3 +--
 include/hw/core/qdev.h      | 3 ++-
 system/qdev-monitor.c       | 7 +++----
 9 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 33fdc0846ac3..4dcc4516e45e 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -834,11 +834,11 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
-static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+    monitor_hmp_printf(hmp, "%*sport %d, guest %s, host %s, throttle %s\n",
                        indent, "", port->id,
                        port->guest_connected ? "on" : "off",
                        port->host_connected ? "on" : "off",
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 82130ba04698..31c4fdf79d48 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,7 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -249,10 +249,9 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
-static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ffa76f83016b..0bb89c5a60ab 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,7 +47,7 @@
 } while (0)
 
 
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
@@ -288,7 +288,7 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
-static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
+static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
     AUXSlave *s;
@@ -300,8 +300,7 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_hmp_printf(MONITOR_HMP(mon),
-                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+    monitor_hmp_printf(hmp, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
                        indent, "",
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 500f821246a9..bcccfaf07f4d 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,9 +135,8 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
+void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
diff --git a/hw/pci/pci-internal.h b/hw/pci/pci-internal.h
index a7d6d8a7324e..b7231fab5dc9 100644
--- a/hw/pci/pci-internal.h
+++ b/hw/pci/pci-internal.h
@@ -16,7 +16,7 @@ extern PCIHostStateList pci_host_bridges;
 
 const pci_class_desc *get_class_desc(int class);
 PCIBus *pci_find_bus_nr(PCIBus *bus, int bus_num);
-void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+void pcibus_dev_print(MonitorHMP *mon, DeviceState *dev, int indent);
 
 int pcie_aer_parse_error_string(const char *error_name,
                                 uint32_t *status, bool *correctable);
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index fe3dbfa2227c..8bd25a9d872a 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,7 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -544,9 +544,8 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
-static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
+static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 4075b5b001ae..b81a067e7753 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,9 +101,8 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
-static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
+static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 37f7d3355193..1391dc060caf 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -10,6 +10,7 @@
 #include "qom/object.h"
 #include "hw/core/hotplug.h"
 #include "hw/core/resettable.h"
+#include "monitor/hmp.h"
 
 /**
  * DOC: The QEMU Device API
@@ -323,7 +324,7 @@ struct BusClass {
     ObjectClass parent_class;
 
     /* FIXME first arg should be BusState */
-    void (*print_dev)(Monitor *mon, DeviceState *dev, int indent);
+    void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 3860ada2a237..13ac9f8f3be1 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -790,18 +790,17 @@ static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
     }
 }
 
-static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int indent)
+static void bus_print_dev(BusState *bus, MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     BusClass *bc = BUS_GET_CLASS(bus);
 
     if (bc->print_dev) {
-        bc->print_dev(mon, dev, indent);
+        bc->print_dev(hmp, dev, indent);
     }
 }
 
 static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
-    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -828,7 +827,7 @@ static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
         qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
-    bus_print_dev(dev->parent_bus, mon, dev, indent);
+    bus_print_dev(dev->parent_bus, hmp, dev, indent);
 }
 
 static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 20:44:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 20:44:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402459.1637563 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03RD-0003k4-16; Fri, 28 Aug 2026 20:44:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402459.1637563; Fri, 28 Aug 2026 20:44:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03RC-0003if-PW; Fri, 28 Aug 2026 20:44:34 +0000
Received: by outflank-mailman (input) for mailman id 1402459;
 Fri, 28 Aug 2026 20:44:33 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1x03RA-0003fb-Fg
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 20:44:33 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x03R9-006xgO-Sz
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 22:44:31 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f30b-8faa-0a2a0a5109dd-0a2a4505ed72-12
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:44:31 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f32e-4cb1-0a2a45050019-aa0a857c6a95-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:44:31 +0200
Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-278-poRlay46OteKBs3Hmh4_Ew-1; Fri,
 28 Aug 2026 16:44:25 -0400
Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id 9082118A3C12; Fri, 28 Aug 2026 20:44:18 +0000 (UTC)
Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.116])
 by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id 252111955F0A; Fri, 28 Aug 2026 20:44:15 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787949869;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=gJWaIUQ+Rh5ZZTSNCUYk7XQu3SgPv11Eaab7cvEsj6k=;
	b=RsxDCikU+JITzveDp65SwMQ/xyMQuNFGNUW5ECh5lBqv4RFK+zAH/gXXfZb455SrRKuqRz
	E9DTdsS62dcdJJYkRqEbMDCc7iVRA0DDxH4KLj4kRMkSXzeHhki2WyUWQ6FF252mzStBfN
	aSTflP4OYSBH8V0NuvG6gVx3cVEAr4g=
X-MC-Unique: poRlay46OteKBs3Hmh4_Ew-1
X-Mimecast-MFC-AGG-ID: poRlay46OteKBs3Hmh4_Ew_1787949859
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sat, 29 Aug 2026 00:42:16 +0400
Subject: [GIT PULL 37/50] monitor: tighten monitor_printf*()
MIME-Version: 1.0
Message-Id: <20260829-nohmp-v1-37-4dcc2b4b0055@redhat.com>
References: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
In-Reply-To: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
To: qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, Gerd Hoffmann <kraxel@redhat.com>, 
 =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 "Gonglei (Arei)" <arei.gonglei@huawei.com>, 
 zhenwei pi <zhenwei.pi@linux.dev>, Kevin Wolf <kwolf@redhat.com>, 
 Hanna Reitz <hreitz@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Alex_Benn=C3=A9e?= <alex.bennee@linaro.org>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Markus Armbruster <armbru@redhat.com>, 
 =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@mailo.com>, 
 Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, 
 Ani Sinha <anisinha@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, 
 Laurent Vivier <lvivier@redhat.com>, Amit Shah <amit@kernel.org>, 
 Brian Cain <brian.cain@oss.qualcomm.com>, 
 David Woodhouse <dwmw2@infradead.org>, Paul Durrant <paul@xen.org>, 
 Marcelo Tosatti <mtosatti@redhat.com>, 
 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, 
 Jiri Pirko <jiri@resnulli.us>, Jason Wang <jasowangio@gmail.com>, 
 Halil Pasic <pasic@linux.ibm.com>, 
 Christian Borntraeger <borntraeger@linux.ibm.com>, 
 Jason Herne <jjherne@linux.ibm.com>, Ilya Leoshkevich <iii@linux.ibm.com>, 
 David Hildenbrand <david@kernel.org>, Cornelia Huck <cohuck@redhat.com>, 
 Eric Farman <farman@linux.ibm.com>, Matthew Rosato <mjrosato@linux.ibm.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 "Dr. David Alan Gilbert" <dave@treblig.org>, 
 Hyman Huang <infra.ai.cloud@bitdeer.com>, Peter Xu <peterx@redhat.com>, 
 Fabiano Rosas <farosas@suse.de>, 
 Samuel Thibault <samuel.thibault@ens-lyon.org>, 
 Stefan Berger <stefanb@linux.vnet.ibm.com>, Zhao Liu <zhao1.liu@intel.com>, 
 Nicholas Piggin <npiggin@gmail.com>, Chinmay Rath <rathc@linux.ibm.com>, 
 Glenn Miles <milesg@linux.ibm.com>, 
 Harsh Prateek Bora <harshpb@linux.ibm.com>, 
 Palmer Dabbelt <palmer@dabbelt.com>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Weiwei Li <liwei1518@gmail.com>, 
 Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>, 
 Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, 
 Chao Liu <chao.liu@processmission.com>, 
 Yoshinori Sato <yoshinori.sato@nifty.com>, 
 Artyom Tarasenko <atar4qemu@gmail.com>, Max Filippov <jcmvbkbc@gmail.com>, 
 Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org, 
 kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, 
 xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=268631;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=eStCm3fDwloFYBzXb7O0tH4I8RXs2cYA6hH2qNxTmDU=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkfKVg+H990hVGQYLaJ4pfqR9chrH4/IREn7DW
 AZZDNmE5B6JAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapHylQAKCRDa6OEJdZac
 5TzdD/9gZsNG65LADBCmCuI+ESb5rnO6R6WBBueixdHT5DQRCZFDKvWjfSc8sLBejdfUcLE07BD
 D2wQGAbp9wUVhG/nq7gTCzk8SkphbMNh/4FR0UstydeIN8WQPVi0dM7iicxPsYiWnEqjhGvUulU
 3g3FtozKEf8uTZIEmQQoJjVo9L/oDZP2bYJGRw4hvkkcpdxWakmZ04mOsKvp/2YZBJdR7sEEDM7
 IeOms1k82vKisEhbvw1WPRnwArsQUYT6tStEGrWIV34vqe7/Gn56P8cuKIcSRwidIj/ZQQdrPS4
 x4hhCEjlMS69vCU7zeIkZackcHSuIO0+9hgOksGHUvdhd6asEe37IW8bd0UxLM2LeX53Ev10o3o
 TxdDk6NQ48zZZypegCUaxpSe6Jba9Ox7VRCSJSOpI/hwO5/z7CJB/uDbONU4IIHeou03ykRc4TH
 7HvPi7vbLALGtbsg+uRWvQGliEi3gsJ/UH61sJqxz0CD7j3mnLmIwyKGrZzqbE3vChC9AG/hR0q
 KD1GGmyCdjsv6xWIgA81X7TpmgLR1Du+5dSF8LoT+xZJequv81aWOpXOODWsonU7tjBrPeplVS6
 uVjIwbJACsVQ3qoESmsFplNlEafuWbv39kESRH+S4bVKnO6ebfxmEvCXL97ygU5YJQEeRO8RToN
 MkKypNcwv/5/wwA==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12
X-Mimecast-MFC-PROC-ID: xqx46AHDYFZhiQmk0mzsWt5BAYeOLUg_L8RrmumB_tk_1787949859
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1787949871-F44A4101-A3DFB07B/0/0
X-purgate-type: clean
X-purgate-size: 268633

Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
the first parameter from Monitor * to MonitorHMP * to enforce type
safety. The implementation is also simplified: monitor_hmp_vprintf now
directly calls g_strdup_vprintf + monitor_puts, removing the virtual
dispatch via moncls->vprintf.

The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
cast, they are fixed in the following commits.

Early return in qemu_vprintf() if "hmp" is NULL, relying on
monitor_hmp_vprintf() handling NULL case is a bit uncommon.

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-37-9227de146347@redhat.com>
---
 audio/audio-hmp-cmds.c                  |   6 +-
 backends/cryptodev-hmp-cmds.c           |   9 +-
 block/monitor/block-hmp-cmds.c          | 170 +++++++++---------
 chardev/char-hmp-cmds.c                 |  12 +-
 disas/disas-mon.c                       |  10 +-
 docs/devel/style.rst                    |   2 +-
 docs/devel/writing-monitor-commands.rst |   8 +-
 dump/dump-hmp-cmds.c                    |   5 +-
 hw/char/virtio-serial-bus.c             |  10 +-
 hw/core/machine-hmp-cmds.c              | 213 +++++++++++-----------
 hw/core/sysbus.c                        |   5 +-
 hw/hexagon/hexagon_tlb.c                |  44 ++---
 hw/i386/kvm/xen-stubs.c                 |   6 +-
 hw/i386/kvm/xen_evtchn.c                |  21 +--
 hw/i386/sgx-hmp-stub.c                  |   3 +-
 hw/i386/sgx.c                           |  29 ++-
 hw/misc/auxbus.c                        |   9 +-
 hw/misc/mos6522-stub.c                  |   3 +-
 hw/net/rocker/rocker-hmp-cmds.c         | 146 ++++++++--------
 hw/pci/pci-hmp-cmds.c                   | 114 ++++++------
 hw/pci/pci-stub.c                       |   3 +-
 hw/s390x/s390-skeys.c                   |   9 +-
 hw/s390x/s390-stattrib.c                |  20 +--
 hw/uefi/ovmf-log.c                      |   5 +-
 hw/usb/bus.c                            |  11 +-
 hw/usb/host-libusb.c                    |  21 ++-
 hw/virtio/virtio-hmp-cmds.c             | 297 ++++++++++++++++---------------
 hw/xen/xen-bus.c                        |   5 +-
 include/disas/disas.h                   |   4 +-
 include/monitor/hmp.h                   |  12 +-
 migration/dirtyrate.c                   |  46 +++--
 migration/migration-hmp-cmds.c          | 301 ++++++++++++++++----------------
 monitor/hmp-cmds.c                      | 141 +++++++--------
 monitor/hmp.c                           | 143 +++++++--------
 monitor/monitor-internal.h              |   6 -
 monitor/monitor.c                       |  33 ++--
 net/net-hmp-cmds.c                      |  31 ++--
 net/slirp.c                             |  31 ++--
 qom/qom-hmp-cmds.c                      |  27 ++-
 replay/replay-debugging.c               |   5 +-
 stats/stats-hmp-cmds.c                  |  57 +++---
 stubs/hmp-cmd-info_sev.c                |   3 +-
 stubs/monitor-core.c                    |   2 +-
 system/dirtylimit-hmp-cmds.c            |  10 +-
 system/qdev-monitor.c                   |  19 +-
 system/runstate-hmp-cmds.c              |  16 +-
 system/tpm-hmp-cmds.c                   |  29 ++-
 target/i386/cpu-apic.c                  |   3 +-
 target/i386/monitor.c                   | 152 ++++++++--------
 target/i386/sev.c                       |  35 ++--
 target/m68k/monitor.c                   |   3 +-
 target/ppc/monitor.c                    |   3 +-
 target/riscv/monitor.c                  |  55 +++---
 target/sh4/monitor.c                    |  29 ++-
 target/sparc/monitor.c                  |   3 +-
 target/xtensa/monitor.c                 |   3 +-
 tests/unit/test-util-sockets.c          |   2 +-
 tools/qemu-vnc/clipboard.c              |   4 +-
 tools/qemu-vnc/stubs.c                  |   2 +-
 trace/trace-hmp-cmds.c                  |  12 +-
 ui/ui-hmp-cmds.c                        | 115 ++++++------
 util/error-report.c                     |   2 +-
 util/qemu-print.c                       |  17 +-
 63 files changed, 1225 insertions(+), 1327 deletions(-)

diff --git a/audio/audio-hmp-cmds.c b/audio/audio-hmp-cmds.c
index 4d326ec99fdf..94182fe1d71f 100644
--- a/audio/audio-hmp-cmds.c
+++ b/audio/audio-hmp-cmds.c
@@ -34,14 +34,13 @@ static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
 
 void hmp_info_capture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     CaptureState *s;
 
     warn_report_once("'info capture' is deprecated since v10.2, to be removed");
 
     for (s = capture_head.lh_first, i = 0; s; s = s->entries.le_next, ++i) {
-        monitor_printf(mon, "[%d]: ", i);
+        monitor_hmp_printf(hmp, "[%d]: ", i);
         s->ops.info (s->opaque);
     }
 }
@@ -66,7 +65,6 @@ void hmp_stopcapture(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     int freq = qdict_get_try_int(qdict, "freq", 44100);
     int bits = qdict_get_try_int(qdict, "bits", 16);
@@ -86,7 +84,7 @@ void hmp_wavcapture(MonitorHMP *hmp, const QDict *qdict)
     s = g_malloc0 (sizeof (*s));
 
     if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
-        monitor_printf(mon, "Failed to add wave capture\n");
+        monitor_hmp_printf(hmp, "Failed to add wave capture\n");
         g_free (s);
         return;
     }
diff --git a/backends/cryptodev-hmp-cmds.c b/backends/cryptodev-hmp-cmds.c
index fb62428d795a..aafa4b970d24 100644
--- a/backends/cryptodev-hmp-cmds.c
+++ b/backends/cryptodev-hmp-cmds.c
@@ -19,7 +19,6 @@
 
 void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     QCryptodevInfoList *il;
     QCryptodevBackendServiceTypeList *sl;
     QCryptodevBackendClientList *cl;
@@ -41,13 +40,13 @@ void hmp_info_cryptodev(MonitorHMP *hmp, const QDict *qdict)
                 services = tmp_services;
             }
         }
-        monitor_printf(mon, "%s: service=[%s]\n", info->id, services);
+        monitor_hmp_printf(hmp, "%s: service=[%s]\n", info->id, services);
 
         for (cl = info->client; cl; cl = cl->next) {
             QCryptodevBackendClient *client = cl->value;
-            monitor_printf(mon, "    queue %" PRIu32 ": type=%s\n",
-                           client->queue,
-                           QCryptodevBackendType_str(client->type));
+            monitor_hmp_printf(hmp, "    queue %" PRIu32 ": type=%s\n",
+                               client->queue,
+                               QCryptodevBackendType_str(client->type));
         }
     }
 
diff --git a/block/monitor/block-hmp-cmds.c b/block/monitor/block-hmp-cmds.c
index a2666e2f1b9b..7bae4d425c6d 100644
--- a/block/monitor/block-hmp-cmds.c
+++ b/block/monitor/block-hmp-cmds.c
@@ -89,7 +89,6 @@ out:
 
 void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     DriveInfo *dinfo;
     QemuOpts *opts;
@@ -119,7 +118,7 @@ void hmp_drive_add(MonitorHMP *hmp, const QDict *qdict)
 
     switch (dinfo->type) {
     case IF_NONE:
-        monitor_printf(mon, "OK\n");
+        monitor_hmp_printf(hmp, "OK\n");
         break;
     default:
         error_setg(&err, "Can't hot-add drive to type %d", dinfo->type);
@@ -552,9 +551,10 @@ void hmp_qemu_io(MonitorHMP *hmp, const QDict *qdict)
     hmp_handle_error(hmp, err);
 }
 
-static void print_block_info(Monitor *mon, BlockInfo *info,
+static void print_block_info(MonitorHMP *hmp, BlockInfo *info,
                              BlockDeviceInfo *inserted, bool verbose)
 {
+    Monitor *mon = MONITOR(hmp);
     ImageInfo *image_info;
 
     assert(!info || !info->inserted || info->inserted == inserted);
@@ -562,7 +562,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     if (info && *info->device) {
         monitor_puts(mon, info->device);
         if (inserted && inserted->node_name) {
-            monitor_printf(mon, " (%s)", inserted->node_name);
+            monitor_hmp_printf(hmp, " (%s)", inserted->node_name);
         }
     } else {
         assert(info || inserted);
@@ -573,29 +573,29 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (inserted) {
-        monitor_printf(mon, ": %s (%s%s%s%s)\n",
-                       inserted->file,
-                       inserted->drv,
-                       inserted->ro ? ", read-only" : "",
-                       inserted->encrypted ? ", encrypted" : "",
-                       inserted->active ? "" : ", inactive");
+        monitor_hmp_printf(hmp, ": %s (%s%s%s%s)\n",
+                           inserted->file,
+                           inserted->drv,
+                           inserted->ro ? ", read-only" : "",
+                           inserted->encrypted ? ", encrypted" : "",
+                           inserted->active ? "" : ", inactive");
     } else {
-        monitor_printf(mon, ": [not inserted]\n");
+        monitor_hmp_printf(hmp, ": [not inserted]\n");
     }
 
     if (info) {
         if (info->qdev) {
-            monitor_printf(mon, "    Attached to:      %s\n", info->qdev);
+            monitor_hmp_printf(hmp, "    Attached to:      %s\n", info->qdev);
         }
         if (info->has_io_status && info->io_status != BLOCK_DEVICE_IO_STATUS_OK) {
-            monitor_printf(mon, "    I/O status:       %s\n",
-                           BlockDeviceIoStatus_str(info->io_status));
+            monitor_hmp_printf(hmp, "    I/O status:       %s\n",
+                               BlockDeviceIoStatus_str(info->io_status));
         }
 
         if (info->removable) {
-            monitor_printf(mon, "    Removable device: %slocked, tray %s\n",
-                           info->locked ? "" : "not ",
-                           info->tray_open ? "open" : "closed");
+            monitor_hmp_printf(hmp, "    Removable device: %slocked, tray %s\n",
+                               info->locked ? "" : "not ",
+                               info->tray_open ? "open" : "closed");
         }
     }
 
@@ -604,28 +604,28 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
         return;
     }
 
-    monitor_printf(mon, "    Cache mode:       %s%s%s\n",
-                   inserted->cache->writeback ? "writeback" : "writethrough",
-                   inserted->cache->direct ? ", direct" : "",
-                   inserted->cache->no_flush ? ", ignore flushes" : "");
+    monitor_hmp_printf(hmp, "    Cache mode:       %s%s%s\n",
+                       inserted->cache->writeback ? "writeback" : "writethrough",
+                       inserted->cache->direct ? ", direct" : "",
+                       inserted->cache->no_flush ? ", ignore flushes" : "");
 
     if (inserted->backing_file) {
-        monitor_printf(mon,
-                       "    Backing file:     %s "
-                       "(chain depth: %" PRId64 ")\n",
-                       inserted->backing_file,
-                       inserted->backing_file_depth);
+        monitor_hmp_printf(hmp,
+                           "    Backing file:     %s "
+                           "(chain depth: %" PRId64 ")\n",
+                           inserted->backing_file,
+                           inserted->backing_file_depth);
     }
 
     if (inserted->detect_zeroes != BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF) {
-        monitor_printf(mon, "    Detect zeroes:    %s\n",
+        monitor_hmp_printf(hmp, "    Detect zeroes:    %s\n",
                 BlockdevDetectZeroesOptions_str(inserted->detect_zeroes));
     }
 
     if (inserted->bps  || inserted->bps_rd  || inserted->bps_wr  ||
         inserted->iops || inserted->iops_rd || inserted->iops_wr)
     {
-        monitor_printf(mon, "    I/O throttling:   bps=%" PRId64
+        monitor_hmp_printf(hmp, "    I/O throttling:   bps=%" PRId64
                         " bps_rd=%" PRId64  " bps_wr=%" PRId64
                         " bps_max=%" PRId64
                         " bps_rd_max=%" PRId64
@@ -654,7 +654,7 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
     }
 
     if (verbose) {
-        monitor_printf(mon, "\nImages:\n");
+        monitor_hmp_printf(hmp, "\nImages:\n");
         image_info = inserted->image;
         while (1) {
             bdrv_node_info_dump(qapi_ImageInfo_base(image_info), 0, false);
@@ -669,7 +669,6 @@ static void print_block_info(Monitor *mon, BlockInfo *info,
 
 void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockInfoList *block_list, *info;
     BlockDeviceInfoList *blockdev_list, *blockdev;
     const char *device = qdict_get_try_str(qdict, "device");
@@ -690,10 +689,10 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (info != block_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, info->value, info->value->inserted,
+        print_block_info(hmp, info->value, info->value->inserted,
                          verbose);
         printed = true;
     }
@@ -713,17 +712,16 @@ void hmp_info_block(MonitorHMP *hmp, const QDict *qdict)
         }
 
         if (blockdev != blockdev_list) {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
-        print_block_info(mon, NULL, blockdev->value, verbose);
+        print_block_info(hmp, NULL, blockdev->value, verbose);
     }
     qapi_free_BlockDeviceInfoList(blockdev_list);
 }
 
 void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockStatsList *stats_list, *stats;
 
     stats_list = qmp_query_blockstats(false, false, NULL);
@@ -733,28 +731,28 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
 
-        monitor_printf(mon, "%s%s: idle_time_ns=%" PRId64 "\n",
-                       stats != stats_list ? "\n" : "",
-                       stats->value->device,
-                       stats->value->stats->idle_time_ns);
-        monitor_printf(mon, "       %24s %16s %24s %10s\n", "bytes",
-                       "operations", "total_time_ns", "merged");
-        monitor_printf(mon, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->rd_bytes,
-                       stats->value->stats->rd_operations,
-                       stats->value->stats->rd_total_time_ns,
-                       stats->value->stats->rd_merged);
-        monitor_printf(mon, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
-                       " %10" PRId64 "\n",
-                       stats->value->stats->wr_bytes,
-                       stats->value->stats->wr_operations,
-                       stats->value->stats->wr_total_time_ns,
-                       stats->value->stats->wr_merged);
-        monitor_printf(mon, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
-                       "",
-                       stats->value->stats->flush_operations,
-                       stats->value->stats->flush_total_time_ns);
+        monitor_hmp_printf(hmp, "%s%s: idle_time_ns=%" PRId64 "\n",
+                           stats != stats_list ? "\n" : "",
+                           stats->value->device,
+                           stats->value->stats->idle_time_ns);
+        monitor_hmp_printf(hmp, "       %24s %16s %24s %10s\n", "bytes",
+                           "operations", "total_time_ns", "merged");
+        monitor_hmp_printf(hmp, "Read:  %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->rd_bytes,
+                           stats->value->stats->rd_operations,
+                           stats->value->stats->rd_total_time_ns,
+                           stats->value->stats->rd_merged);
+        monitor_hmp_printf(hmp, "Write: %24" PRId64 " %16" PRId64 " %24" PRId64
+                           " %10" PRId64 "\n",
+                           stats->value->stats->wr_bytes,
+                           stats->value->stats->wr_operations,
+                           stats->value->stats->wr_total_time_ns,
+                           stats->value->stats->wr_merged);
+        monitor_hmp_printf(hmp, "Flush: %24s %16" PRId64 " %24" PRId64 "\n",
+                           "",
+                           stats->value->stats->flush_operations,
+                           stats->value->stats->flush_total_time_ns);
     }
 
     qapi_free_BlockStatsList(stats_list);
@@ -762,34 +760,33 @@ void hmp_info_blockstats(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockJobInfoList *list;
 
     list = qmp_query_block_jobs(&error_abort);
 
     if (!list) {
-        monitor_printf(mon, "No active jobs\n");
+        monitor_hmp_printf(hmp, "No active jobs\n");
         return;
     }
 
     while (list) {
         if (list->value->type == JOB_TYPE_STREAM) {
-            monitor_printf(mon, "Streaming device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Streaming device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         } else {
-            monitor_printf(mon, "Type %s, device %s: Completed %" PRId64
-                           " of %" PRId64 " bytes, speed limit %" PRId64
-                           " bytes/s\n",
-                           JobType_str(list->value->type),
-                           list->value->device,
-                           list->value->offset,
-                           list->value->len,
-                           list->value->speed);
+            monitor_hmp_printf(hmp, "Type %s, device %s: Completed %" PRId64
+                               " of %" PRId64 " bytes, speed limit %" PRId64
+                               " bytes/s\n",
+                               JobType_str(list->value->type),
+                               list->value->device,
+                               list->value->offset,
+                               list->value->len,
+                               list->value->speed);
         }
         list = list->next;
     }
@@ -799,7 +796,6 @@ void hmp_info_block_jobs(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BlockDriverState *bs, *bs1;
     BdrvNextIterator it1;
     QEMUSnapshotInfo *sn_tab, *sn;
@@ -837,7 +833,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     nb_sns = bdrv_snapshot_list(bs, &sn_tab);
 
     if (nb_sns < 0) {
-        monitor_printf(mon, "bdrv_snapshot_list: error %d\n", nb_sns);
+        monitor_hmp_printf(hmp, "bdrv_snapshot_list: error %d\n", nb_sns);
         return;
     }
 
@@ -866,7 +862,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (no_snapshot) {
-        monitor_printf(mon, "There is no snapshot available.\n");
+        monitor_hmp_printf(hmp, "There is no snapshot available.\n");
         return;
     }
 
@@ -889,11 +885,11 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
             }
         }
     }
-    monitor_printf(mon, "List of snapshots present on all disks:\n");
+    monitor_hmp_printf(hmp, "List of snapshots present on all disks:\n");
 
     if (total > 0) {
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         for (i = 0; i < total; i++) {
             sn = &sn_tab[global_snapshots[i]];
             /*
@@ -902,24 +898,24 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
              */
             pstrcpy(sn->id_str, sizeof(sn->id_str), "--");
             bdrv_snapshot_dump(sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     } else {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
     }
 
     QTAILQ_FOREACH(image_entry, &image_list, next) {
         if (QTAILQ_EMPTY(&image_entry->snapshots)) {
             continue;
         }
-        monitor_printf(mon,
-                       "\nList of partial (non-loadable) snapshots on '%s':\n",
-                       image_entry->imagename);
+        monitor_hmp_printf(hmp,
+                           "\nList of partial (non-loadable) snapshots on '%s':\n",
+                           image_entry->imagename);
         bdrv_snapshot_dump(NULL);
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         QTAILQ_FOREACH(snapshot_entry, &image_entry->snapshots, next) {
             bdrv_snapshot_dump(&snapshot_entry->sn);
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
@@ -935,7 +931,7 @@ void hmp_info_snapshots(MonitorHMP *hmp, const QDict *qdict)
     g_free(global_snapshots);
 }
 
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp)
 {
diff --git a/chardev/char-hmp-cmds.c b/chardev/char-hmp-cmds.c
index 71017fd2d19e..fb0560054b7b 100644
--- a/chardev/char-hmp-cmds.c
+++ b/chardev/char-hmp-cmds.c
@@ -26,12 +26,11 @@
 
 void hmp_info_chardev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     ChardevInfoList *char_info, *info;
 
     char_info = qmp_query_chardev(NULL);
     for (info = char_info; info; info = info->next) {
-        monitor_printf(mon, "%s: filename=%s\n", info->value->label,
+        monitor_hmp_printf(hmp, "%s: filename=%s\n", info->value->label,
                                                  info->value->filename);
     }
 
@@ -51,7 +50,6 @@ void hmp_ringbuf_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *chardev = qdict_get_str(qdict, "device");
     char *data;
@@ -67,15 +65,15 @@ void hmp_ringbuf_read(MonitorHMP *hmp, const QDict *qdict)
         unsigned char ch = data[i];
 
         if (ch == '\\') {
-            monitor_printf(mon, "\\\\");
+            monitor_hmp_printf(hmp, "\\\\");
         } else if ((ch < 0x20 && ch != '\n' && ch != '\t') || ch == 0x7F) {
-            monitor_printf(mon, "\\u%04X", ch);
+            monitor_hmp_printf(hmp, "\\u%04X", ch);
         } else {
-            monitor_printf(mon, "%c", ch);
+            monitor_hmp_printf(hmp, "%c", ch);
         }
 
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     g_free(data);
 }
 
diff --git a/disas/disas-mon.c b/disas/disas-mon.c
index bc9dec3a7761..32e4220181a8 100644
--- a/disas/disas-mon.c
+++ b/disas/disas-mon.c
@@ -38,7 +38,7 @@ physical_read_memory(bfd_vma memaddr, bfd_byte *myaddr, int length,
 }
 
 /* Disassembler for the monitor.  */
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical)
 {
     int count, i;
@@ -58,13 +58,13 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
     s.info.buffer_vma = pc;
 
     if (s.info.cap_arch >= 0 && cap_disas_monitor(&s.info, pc, nb_insn)) {
-        monitor_puts(mon, ds->str);
+        monitor_puts(MONITOR(hmp), ds->str);
         return;
     }
 
     if (!s.info.print_insn) {
-        monitor_printf(mon, "0x%08" PRIx64
-                       ": Asm output not supported on this arch\n", pc);
+        monitor_hmp_printf(hmp, "0x%08" PRIx64
+                           ": Asm output not supported on this arch\n", pc);
         return;
     }
 
@@ -78,5 +78,5 @@ void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
         pc += count;
     }
 
-    monitor_puts(mon, ds->str);
+    monitor_puts(MONITOR(hmp), ds->str);
 }
diff --git a/docs/devel/style.rst b/docs/devel/style.rst
index 6c5f94cc5098..6876d3a59ec7 100644
--- a/docs/devel/style.rst
+++ b/docs/devel/style.rst
@@ -754,7 +754,7 @@ Error handling and reporting
 Reporting errors to the human user
 ----------------------------------
 
-Do not use printf(), fprintf() or monitor_printf().  Instead, use
+Do not use printf(), fprintf() or monitor_hmp_printf().  Instead, use
 error_report() or error_vreport() from error-report.h.  This ensures the
 error is reported in the right place (current monitor or stderr), and in
 a uniform format.
diff --git a/docs/devel/writing-monitor-commands.rst b/docs/devel/writing-monitor-commands.rst
index 7ae7efe32759..baf94cbdefab 100644
--- a/docs/devel/writing-monitor-commands.rst
+++ b/docs/devel/writing-monitor-commands.rst
@@ -479,7 +479,7 @@ The HMP command
 
 Here's the HMP counterpart of the query-option-roms command::
 
- void hmp_info_option_roms(Monitor *mon, const QDict *qdict)
+ void hmp_info_option_roms(MonitorHMP *mon, const QDict *qdict)
  {
      Error *err = NULL;
      OptionRomInfoList *info_list, *tail;
@@ -492,11 +492,11 @@ Here's the HMP counterpart of the query-option-roms command::
 
      for (tail = info_list; tail; tail = tail->next) {
          info = tail->value;
-         monitor_printf(mon, "%s", info->filename);
+         monitor_hmp_printf(mon, "%s", info->filename);
          if (info->has_bootindex) {
-             monitor_printf(mon, " %" PRId64, info->bootindex);
+             monitor_hmp_printf(mon, " %" PRId64, info->bootindex);
          }
-         monitor_printf(mon, "\n");
+         monitor_hmp_printf(mon, "\n");
      }
 
      qapi_free_OptionRomInfoList(info_list);
diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
index 104ab5d2a53a..c7045c2d7314 100644
--- a/dump/dump-hmp-cmds.c
+++ b/dump/dump-hmp-cmds.c
@@ -85,17 +85,16 @@ void hmp_dump_guest_memory(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_dump(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DumpQueryResult *result = qmp_query_dump(NULL);
 
     assert(result && result->status < DUMP_STATUS__MAX);
-    monitor_printf(mon, "Status: %s\n", DumpStatus_str(result->status));
+    monitor_hmp_printf(hmp, "Status: %s\n", DumpStatus_str(result->status));
 
     if (result->status == DUMP_STATUS_ACTIVE) {
         float percent = 0;
         assert(result->total != 0);
         percent = 100.0 * result->completed / result->total;
-        monitor_printf(mon, "Finished: %.2f %%\n", percent);
+        monitor_hmp_printf(hmp, "Finished: %.2f %%\n", percent);
     }
 
     qapi_free_DumpQueryResult(result);
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 02604740f86a..33fdc0846ac3 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -838,11 +838,11 @@ static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
 
-    monitor_printf(mon, "%*sport %d, guest %s, host %s, throttle %s\n",
-                   indent, "", port->id,
-                   port->guest_connected ? "on" : "off",
-                   port->host_connected ? "on" : "off",
-                   port->throttled ? "on" : "off");
+    monitor_hmp_printf(MONITOR_HMP(mon), "%*sport %d, guest %s, host %s, throttle %s\n",
+                       indent, "", port->id,
+                       port->guest_connected ? "on" : "off",
+                       port->host_connected ? "on" : "off",
+                       port->throttled ? "on" : "off");
 }
 
 /* This function is only used if a port id is not provided by the user */
diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c
index 702c798ccc56..10a633af0780 100644
--- a/hw/core/machine-hmp-cmds.c
+++ b/hw/core/machine-hmp-cmds.c
@@ -27,7 +27,6 @@
 
 void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CpuInfoFastList *cpu_list, *cpu;
 
     cpu_list = qmp_query_cpus_fast(NULL);
@@ -40,10 +39,10 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
             active = '*';
         }
 
-        monitor_printf(mon, "%c CPU #%" PRId64 ":", active,
-                       cpu->value->cpu_index);
-        monitor_printf(mon, " thread_id=%" PRId64 " model=%s\n",
-                       cpu->value->thread_id, cpu_model);
+        monitor_hmp_printf(hmp, "%c CPU #%" PRId64 ":", active,
+                           cpu->value->cpu_index);
+        monitor_hmp_printf(hmp, " thread_id=%" PRId64 " model=%s\n",
+                           cpu->value->thread_id, cpu_model);
     }
 
     qapi_free_CpuInfoFastList(cpu_list);
@@ -51,7 +50,6 @@ void hmp_info_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     HotpluggableCPUList *l = qmp_query_hotpluggable_cpus(&err);
     HotpluggableCPUList *saved = l;
@@ -61,45 +59,45 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Hotpluggable CPUs:\n");
+    monitor_hmp_printf(hmp, "Hotpluggable CPUs:\n");
     while (l) {
-        monitor_printf(mon, "  type: \"%s\"\n", l->value->type);
-        monitor_printf(mon, "  vcpus_count: \"%" PRIu64 "\"\n",
-                       l->value->vcpus_count);
+        monitor_hmp_printf(hmp, "  type: \"%s\"\n", l->value->type);
+        monitor_hmp_printf(hmp, "  vcpus_count: \"%" PRIu64 "\"\n",
+                           l->value->vcpus_count);
         if (l->value->qom_path) {
-            monitor_printf(mon, "  qom_path: \"%s\"\n", l->value->qom_path);
+            monitor_hmp_printf(hmp, "  qom_path: \"%s\"\n", l->value->qom_path);
         }
 
         c = l->value->props;
-        monitor_printf(mon, "  CPUInstance Properties:\n");
+        monitor_hmp_printf(hmp, "  CPUInstance Properties:\n");
         if (c->has_node_id) {
-            monitor_printf(mon, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
+            monitor_hmp_printf(hmp, "    node-id: \"%" PRIu64 "\"\n", c->node_id);
         }
         if (c->has_drawer_id) {
-            monitor_printf(mon, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
+            monitor_hmp_printf(hmp, "    drawer-id: \"%" PRIu64 "\"\n", c->drawer_id);
         }
         if (c->has_book_id) {
-            monitor_printf(mon, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
+            monitor_hmp_printf(hmp, "    book-id: \"%" PRIu64 "\"\n", c->book_id);
         }
         if (c->has_socket_id) {
-            monitor_printf(mon, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
+            monitor_hmp_printf(hmp, "    socket-id: \"%" PRIu64 "\"\n", c->socket_id);
         }
         if (c->has_die_id) {
-            monitor_printf(mon, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
+            monitor_hmp_printf(hmp, "    die-id: \"%" PRIu64 "\"\n", c->die_id);
         }
         if (c->has_cluster_id) {
-            monitor_printf(mon, "    cluster-id: \"%" PRIu64 "\"\n",
-                           c->cluster_id);
+            monitor_hmp_printf(hmp, "    cluster-id: \"%" PRIu64 "\"\n",
+                               c->cluster_id);
         }
         if (c->has_module_id) {
-            monitor_printf(mon, "    module-id: \"%" PRIu64 "\"\n",
-                           c->module_id);
+            monitor_hmp_printf(hmp, "    module-id: \"%" PRIu64 "\"\n",
+                               c->module_id);
         }
         if (c->has_core_id) {
-            monitor_printf(mon, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
+            monitor_hmp_printf(hmp, "    core-id: \"%" PRIu64 "\"\n", c->core_id);
         }
         if (c->has_thread_id) {
-            monitor_printf(mon, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
+            monitor_hmp_printf(hmp, "    thread-id: \"%" PRIu64 "\"\n", c->thread_id);
         }
 
         l = l->next;
@@ -110,7 +108,6 @@ void hmp_hotpluggable_cpus(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemdevList *memdev_list = qmp_query_memdev(&err);
     MemdevList *m = memdev_list;
@@ -120,31 +117,31 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
     while (m) {
         v = string_output_visitor_new(false, &str);
         visit_type_uint16List(v, NULL, &m->value->host_nodes, &error_abort);
-        monitor_printf(mon, "memory backend: %s\n", m->value->id);
-        monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
-        monitor_printf(mon, "  merge: %s\n",
-                       m->value->merge ? "true" : "false");
-        monitor_printf(mon, "  dump: %s\n",
-                       m->value->dump ? "true" : "false");
-        monitor_printf(mon, "  prealloc: %s\n",
-                       m->value->prealloc ? "true" : "false");
-        monitor_printf(mon, "  share: %s\n",
-                       m->value->share ? "true" : "false");
+        monitor_hmp_printf(hmp, "memory backend: %s\n", m->value->id);
+        monitor_hmp_printf(hmp, "  size:  %" PRId64 "\n", m->value->size);
+        monitor_hmp_printf(hmp, "  merge: %s\n",
+                           m->value->merge ? "true" : "false");
+        monitor_hmp_printf(hmp, "  dump: %s\n",
+                           m->value->dump ? "true" : "false");
+        monitor_hmp_printf(hmp, "  prealloc: %s\n",
+                           m->value->prealloc ? "true" : "false");
+        monitor_hmp_printf(hmp, "  share: %s\n",
+                           m->value->share ? "true" : "false");
         if (m->value->has_reserve) {
-            monitor_printf(mon, "  reserve: %s\n",
-                           m->value->reserve ? "true" : "false");
+            monitor_hmp_printf(hmp, "  reserve: %s\n",
+                               m->value->reserve ? "true" : "false");
         }
-        monitor_printf(mon, "  policy: %s\n",
-                       HostMemPolicy_str(m->value->policy));
+        monitor_hmp_printf(hmp, "  policy: %s\n",
+                           HostMemPolicy_str(m->value->policy));
         visit_complete(v, &str);
-        monitor_printf(mon, "  host nodes: %s\n", str);
+        monitor_hmp_printf(hmp, "  host nodes: %s\n", str);
 
         g_free(str);
         visit_free(v);
         m = m->next;
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_MemdevList(memdev_list);
     hmp_handle_error(hmp, err);
@@ -152,15 +149,14 @@ void hmp_info_memdev(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     KvmInfo *info;
 
     info = qmp_query_kvm(NULL);
-    monitor_printf(mon, "kvm support: ");
+    monitor_hmp_printf(hmp, "kvm support: ");
     if (info->present) {
-        monitor_printf(mon, "%s\n", info->enabled ? "enabled" : "disabled");
+        monitor_hmp_printf(hmp, "%s\n", info->enabled ? "enabled" : "disabled");
     } else {
-        monitor_printf(mon, "not compiled\n");
+        monitor_hmp_printf(hmp, "not compiled\n");
     }
 
     qapi_free_KvmInfo(info);
@@ -168,7 +164,6 @@ void hmp_info_kvm(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     AcceleratorInfo *info;
     AcceleratorList *accel;
 
@@ -176,9 +171,9 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
     for (accel = info->present; accel; accel = accel->next) {
         char trail = accel->next ? ' ' : '\n';
         if (info->enabled == accel->value) {
-            monitor_printf(mon, "[%s]%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "[%s]%c", Accelerator_str(accel->value), trail);
         } else {
-            monitor_printf(mon, "%s%c", Accelerator_str(accel->value), trail);
+            monitor_hmp_printf(hmp, "%s%c", Accelerator_str(accel->value), trail);
         }
     }
 
@@ -187,17 +182,15 @@ void hmp_info_accelerators(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_uuid(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     UuidInfo *info;
 
     info = qmp_query_uuid(NULL);
-    monitor_printf(mon, "%s\n", info->UUID);
+    monitor_hmp_printf(hmp, "%s\n", info->UUID);
     qapi_free_UuidInfo(info);
 }
 
 void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     BalloonInfo *info;
     Error *err = NULL;
 
@@ -206,7 +199,7 @@ void hmp_info_balloon(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
+    monitor_hmp_printf(hmp, "balloon: actual=%" PRId64 "\n", info->actual >> 20);
 
     qapi_free_BalloonInfo(info);
 }
@@ -223,7 +216,6 @@ void hmp_system_powerdown(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t size = qdict_get_int(qdict, "size");
     const char *filename = qdict_get_str(qdict, "filename");
     uint64_t addr = qdict_get_int(qdict, "val");
@@ -231,7 +223,7 @@ void hmp_memsave(MonitorHMP *hmp, const QDict *qdict)
     int cpu_index = monitor_hmp_get_cpu_index(hmp);
 
     if (cpu_index < 0) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
@@ -277,7 +269,6 @@ void hmp_balloon(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryDeviceInfoList *info_list = qmp_query_memory_devices(&err);
     MemoryDeviceInfoList *info;
@@ -298,76 +289,76 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
             case MEMORY_DEVICE_INFO_KIND_NVDIMM:
                 di = value->type == MEMORY_DEVICE_INFO_KIND_DIMM ?
                      value->u.dimm.data : value->u.nvdimm.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               di->id ? di->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", di->addr);
-                monitor_printf(mon, "  slot: %" PRId64 "\n", di->slot);
-                monitor_printf(mon, "  node: %" PRId64 "\n", di->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", di->size);
-                monitor_printf(mon, "  memdev: %s\n", di->memdev);
-                monitor_printf(mon, "  hotplugged: %s\n",
-                               di->hotplugged ? "true" : "false");
-                monitor_printf(mon, "  hotpluggable: %s\n",
-                               di->hotpluggable ? "true" : "false");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   di->id ? di->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", di->addr);
+                monitor_hmp_printf(hmp, "  slot: %" PRId64 "\n", di->slot);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", di->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", di->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", di->memdev);
+                monitor_hmp_printf(hmp, "  hotplugged: %s\n",
+                                   di->hotplugged ? "true" : "false");
+                monitor_hmp_printf(hmp, "  hotpluggable: %s\n",
+                                   di->hotpluggable ? "true" : "false");
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_PMEM:
                 vpi = value->u.virtio_pmem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vpi->id ? vpi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vpi->size);
-                monitor_printf(mon, "  memdev: %s\n", vpi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vpi->id ? vpi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vpi->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vpi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vpi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_VIRTIO_MEM:
                 vmi = value->u.virtio_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               vmi->id ? vmi->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", vmi->node);
-                monitor_printf(mon, "  requested-size: %" PRIu64 "\n",
-                               vmi->requested_size);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", vmi->size);
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", vmi->max_size);
-                monitor_printf(mon, "  block-size: %" PRIu64 "\n",
-                               vmi->block_size);
-                monitor_printf(mon, "  memdev: %s\n", vmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   vmi->id ? vmi->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", vmi->memaddr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", vmi->node);
+                monitor_hmp_printf(hmp, "  requested-size: %" PRIu64 "\n",
+                                   vmi->requested_size);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", vmi->size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", vmi->max_size);
+                monitor_hmp_printf(hmp, "  block-size: %" PRIu64 "\n",
+                                   vmi->block_size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", vmi->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_SGX_EPC:
                 se = value->u.sgx_epc.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               se->id ? se->id : "");
-                monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", se->size);
-                monitor_printf(mon, "  node: %" PRId64 "\n", se->node);
-                monitor_printf(mon, "  memdev: %s\n", se->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   se->id ? se->id : "");
+                monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n", se->memaddr);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", se->size);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", se->node);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", se->memdev);
                 break;
             case MEMORY_DEVICE_INFO_KIND_HV_BALLOON:
                 hi = value->u.hv_balloon.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               hi->id ? hi->id : "");
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   hi->id ? hi->id : "");
                 if (hi->has_memaddr) {
-                    monitor_printf(mon, "  memaddr: 0x%" PRIx64 "\n",
-                                   hi->memaddr);
+                    monitor_hmp_printf(hmp, "  memaddr: 0x%" PRIx64 "\n",
+                                       hi->memaddr);
                 }
-                monitor_printf(mon, "  max-size: %" PRIu64 "\n", hi->max_size);
+                monitor_hmp_printf(hmp, "  max-size: %" PRIu64 "\n", hi->max_size);
                 if (hi->memdev) {
-                    monitor_printf(mon, "  memdev: %s\n", hi->memdev);
+                    monitor_hmp_printf(hmp, "  memdev: %s\n", hi->memdev);
                 }
                 break;
             case MEMORY_DEVICE_INFO_KIND_SP_MEM:
                 spmi = value->u.sp_mem.data;
-                monitor_printf(mon, "Memory device [%s]: \"%s\"\n",
-                               MemoryDeviceInfoKind_str(value->type),
-                               spmi->id ? spmi->id : "");
-                monitor_printf(mon, "  addr: 0x%" PRIx64 "\n", spmi->addr);
-                monitor_printf(mon, "  node: %" PRId64 "\n", spmi->node);
-                monitor_printf(mon, "  size: %" PRIu64 "\n", spmi->size);
-                monitor_printf(mon, "  memdev: %s\n", spmi->memdev);
+                monitor_hmp_printf(hmp, "Memory device [%s]: \"%s\"\n",
+                                   MemoryDeviceInfoKind_str(value->type),
+                                   spmi->id ? spmi->id : "");
+                monitor_hmp_printf(hmp, "  addr: 0x%" PRIx64 "\n", spmi->addr);
+                monitor_hmp_printf(hmp, "  node: %" PRId64 "\n", spmi->node);
+                monitor_hmp_printf(hmp, "  size: %" PRIu64 "\n", spmi->size);
+                monitor_hmp_printf(hmp, "  memdev: %s\n", spmi->memdev);
                 break;
             default:
                 g_assert_not_reached();
@@ -381,11 +372,10 @@ void hmp_info_memory_devices(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     GuidInfo *info = qmp_query_vm_generation_id(&err);
     if (info) {
-        monitor_printf(mon, "%s\n", info->guid);
+        monitor_hmp_printf(hmp, "%s\n", info->guid);
     }
     hmp_handle_error(hmp, err);
     qapi_free_GuidInfo(info);
@@ -393,16 +383,15 @@ void hmp_info_vm_generation_id(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_memory_size_summary(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     MemoryInfo *info = qmp_query_memory_size_summary(&err);
     if (info) {
-        monitor_printf(mon, "base memory: %" PRIu64 "\n",
-                       info->base_memory);
+        monitor_hmp_printf(hmp, "base memory: %" PRIu64 "\n",
+                           info->base_memory);
 
         if (info->has_plugged_memory) {
-            monitor_printf(mon, "plugged memory: %" PRIu64 "\n",
-                           info->plugged_memory);
+            monitor_hmp_printf(hmp, "plugged memory: %" PRIu64 "\n",
+                               info->plugged_memory);
         }
 
         qapi_free_MemoryInfo(info);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 13df7cbafe10..82130ba04698 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -252,13 +252,14 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
 static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     hwaddr size;
     int i;
 
     for (i = 0; i < s->num_mmio; i++) {
         size = memory_region_size(s->mmio[i].memory);
-        monitor_printf(mon, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                       indent, "", s->mmio[i].addr, size);
+        monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                           indent, "", s->mmio[i].addr, size);
     }
 }
 
diff --git a/hw/hexagon/hexagon_tlb.c b/hw/hexagon/hexagon_tlb.c
index 2d878cee736d..576929ff224b 100644
--- a/hw/hexagon/hexagon_tlb.c
+++ b/hw/hexagon/hexagon_tlb.c
@@ -124,30 +124,32 @@ static inline uint64_t hex_tlb_virt_addr(uint64_t entry)
 
 bool hexagon_tlb_dump_entry(Monitor *mon, uint64_t entry)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
+
     if (GET_PTE_V(entry)) {
         uint64_t PA = hex_tlb_phys_addr(entry);
         uint64_t VA = hex_tlb_virt_addr(entry);
-        monitor_printf(mon, "0x%016" PRIx64 ": ", entry);
-        monitor_printf(mon, "V:%" PRId64 " G:%" PRId64
-                       " A1:%" PRId64 " A0:%" PRId64,
-                       GET_PTE_V(entry),
-                       GET_PTE_G(entry),
-                       GET_PTE_ATR1(entry),
-                       GET_PTE_ATR0(entry));
-        monitor_printf(mon, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
-                       GET_PTE_ASID(entry), VA);
-        monitor_printf(mon,
-                       " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
-                       " U:%" PRId64 " C:%" PRId64,
-                       GET_PTE_X(entry),
-                       GET_PTE_W(entry),
-                       GET_PTE_R(entry),
-                       GET_PTE_U(entry),
-                       GET_PTE_C(entry));
-        monitor_printf(mon, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
-                       PA, pgsize_str[hex_tlb_pgsize_type(entry)],
-                       hex_tlb_page_size_bytes(entry));
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "0x%016" PRIx64 ": ", entry);
+        monitor_hmp_printf(hmp, "V:%" PRId64 " G:%" PRId64
+                           " A1:%" PRId64 " A0:%" PRId64,
+                           GET_PTE_V(entry),
+                           GET_PTE_G(entry),
+                           GET_PTE_ATR1(entry),
+                           GET_PTE_ATR0(entry));
+        monitor_hmp_printf(hmp, " ASID:0x%02" PRIx64 " VA:0x%08" PRIx64,
+                           GET_PTE_ASID(entry), VA);
+        monitor_hmp_printf(hmp,
+                           " X:%" PRId64 " W:%" PRId64 " R:%" PRId64
+                           " U:%" PRId64 " C:%" PRId64,
+                           GET_PTE_X(entry),
+                           GET_PTE_W(entry),
+                           GET_PTE_R(entry),
+                           GET_PTE_U(entry),
+                           GET_PTE_C(entry));
+        monitor_hmp_printf(hmp, " PA:0x%09" PRIx64 " SZ:%s (0x%" PRIx64 ")",
+                           PA, pgsize_str[hex_tlb_pgsize_type(entry)],
+                           hex_tlb_page_size_bytes(entry));
+        monitor_hmp_printf(hmp, "\n");
         return true;
     }
 
diff --git a/hw/i386/kvm/xen-stubs.c b/hw/i386/kvm/xen-stubs.c
index ab1eb14f99e0..5ed71583281a 100644
--- a/hw/i386/kvm/xen-stubs.c
+++ b/hw/i386/kvm/xen-stubs.c
@@ -42,12 +42,10 @@ void xen_primary_console_set_be_port(uint16_t port)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "XEN emulation is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "XEN emulation is not available in this QEMU\n");
 }
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 00dff6ee8760..b2135020f27f 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -2346,7 +2346,6 @@ void qmp_xen_event_inject(uint32_t port, Error **errp)
 
 void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     EvtchnInfoList *iter, *info_list;
     Error *err = NULL;
 
@@ -2359,22 +2358,22 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
     for (iter = info_list; iter; iter = iter->next) {
         EvtchnInfo *info = iter->value;
 
-        monitor_printf(mon, "port %4u: vcpu: %d %s", info->port, info->vcpu,
-                       EvtchnPortType_str(info->type));
+        monitor_hmp_printf(hmp, "port %4u: vcpu: %d %s", info->port, info->vcpu,
+                           EvtchnPortType_str(info->type));
         if (info->type != EVTCHN_PORT_TYPE_IPI) {
-            monitor_printf(mon,  "(");
+            monitor_hmp_printf(hmp,  "(");
             if (info->remote_domain) {
-                monitor_printf(mon, "%s:", info->remote_domain);
+                monitor_hmp_printf(hmp, "%s:", info->remote_domain);
             }
-            monitor_printf(mon, "%d)", info->target);
+            monitor_hmp_printf(hmp, "%d)", info->target);
         }
         if (info->pending) {
-            monitor_printf(mon, " PENDING");
+            monitor_hmp_printf(hmp, " PENDING");
         }
         if (info->masked) {
-            monitor_printf(mon, " MASKED");
+            monitor_hmp_printf(hmp, " MASKED");
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_EvtchnInfoList(info_list);
@@ -2382,7 +2381,6 @@ void hmp_xen_event_list(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int port = qdict_get_int(qdict, "port");
     Error *err = NULL;
 
@@ -2390,7 +2388,6 @@ void hmp_xen_event_inject(MonitorHMP *hmp, const QDict *qdict)
     if (err) {
         hmp_handle_error(hmp, err);
     } else {
-        monitor_printf(mon, "Delivered port %d\n", port);
+        monitor_hmp_printf(hmp, "Delivered port %d\n", port);
     }
 }
-
diff --git a/hw/i386/sgx-hmp-stub.c b/hw/i386/sgx-hmp-stub.c
index a4848ae1d1a7..b7afb26886a8 100644
--- a/hw/i386/sgx-hmp-stub.c
+++ b/hw/i386/sgx-hmp-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SGX is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SGX is not available in this QEMU\n");
 }
diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
index 77b41d234c9f..634e33e819ce 100644
--- a/hw/i386/sgx.c
+++ b/hw/i386/sgx.c
@@ -236,7 +236,6 @@ SgxInfo *qmp_query_sgx(Error **errp)
 
 void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     SgxEpcSectionList *section_list, *section;
     g_autoptr(SgxInfo) info = qmp_query_sgx(&err);
@@ -246,25 +245,25 @@ void hmp_info_sgx(MonitorHMP *hmp, const QDict *qdict)
         error_report_err(err);
         return;
     }
-    monitor_printf(mon, "SGX support: %s\n",
-                   info->sgx ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX1 support: %s\n",
-                   info->sgx1 ? "enabled" : "disabled");
-    monitor_printf(mon, "SGX2 support: %s\n",
-                   info->sgx2 ? "enabled" : "disabled");
-    monitor_printf(mon, "FLC support: %s\n",
-                   info->flc ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX support: %s\n",
+                       info->sgx ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX1 support: %s\n",
+                       info->sgx1 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "SGX2 support: %s\n",
+                       info->sgx2 ? "enabled" : "disabled");
+    monitor_hmp_printf(hmp, "FLC support: %s\n",
+                       info->flc ? "enabled" : "disabled");
 
     section_list = info->sections;
     for (section = section_list; section; section = section->next) {
-        monitor_printf(mon, "NUMA node #%" PRId64 ": ",
-                       section->value->node);
-        monitor_printf(mon, "size=%" PRIu64 "\n",
-                       section->value->size);
+        monitor_hmp_printf(hmp, "NUMA node #%" PRId64 ": ",
+                           section->value->node);
+        monitor_hmp_printf(hmp, "size=%" PRIu64 "\n",
+                           section->value->size);
         size += section->value->size;
     }
-    monitor_printf(mon, "total size=%" PRIu64 "\n",
-                   size);
+    monitor_hmp_printf(hmp, "total size=%" PRIu64 "\n",
+                       size);
 }
 
 bool check_sgx_support(void)
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index ac2525b90fec..ffa76f83016b 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -300,10 +300,11 @@ static void aux_slave_dev_print(Monitor *mon, DeviceState *dev, int indent)
 
     s = AUX_SLAVE(dev);
 
-    monitor_printf(mon, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
-                   indent, "",
-                   object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
-                   memory_region_size(s->mmio));
+    monitor_hmp_printf(MONITOR_HMP(mon),
+                       "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n",
+                       indent, "",
+                       object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
+                       memory_region_size(s->mmio));
 }
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
diff --git a/hw/misc/mos6522-stub.c b/hw/misc/mos6522-stub.c
index 6a7d76292f00..154cd32ed88b 100644
--- a/hw/misc/mos6522-stub.c
+++ b/hw/misc/mos6522-stub.c
@@ -12,6 +12,5 @@
 
 void hmp_info_via(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "MOS6522 VIA is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "MOS6522 VIA is not available in this QEMU\n");
 }
diff --git a/hw/net/rocker/rocker-hmp-cmds.c b/hw/net/rocker/rocker-hmp-cmds.c
index 6405ce26dd65..5099d59cc620 100644
--- a/hw/net/rocker/rocker-hmp-cmds.c
+++ b/hw/net/rocker/rocker-hmp-cmds.c
@@ -22,7 +22,6 @@
 
 void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_str(qdict, "name");
     RockerSwitch *rocker;
     Error *err = NULL;
@@ -32,16 +31,15 @@ void hmp_rocker(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "name: %s\n", rocker->name);
-    monitor_printf(mon, "id: 0x%" PRIx64 "\n", rocker->id);
-    monitor_printf(mon, "ports: %d\n", rocker->ports);
+    monitor_hmp_printf(hmp, "name: %s\n", rocker->name);
+    monitor_hmp_printf(hmp, "id: 0x%" PRIx64 "\n", rocker->id);
+    monitor_hmp_printf(hmp, "ports: %d\n", rocker->ports);
 
     qapi_free_RockerSwitch(rocker);
 }
 
 void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerPortList *list, *port;
     const char *name = qdict_get_str(qdict, "name");
     Error *err = NULL;
@@ -51,17 +49,17 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "            ena/    speed/ auto\n");
-    monitor_printf(mon, "      port  link    duplex neg?\n");
+    monitor_hmp_printf(hmp, "            ena/    speed/ auto\n");
+    monitor_hmp_printf(hmp, "      port  link    duplex neg?\n");
 
     for (port = list; port; port = port->next) {
-        monitor_printf(mon, "%10s  %-4s   %-3s  %2s  %s\n",
-                       port->value->name,
-                       port->value->enabled ? port->value->link_up ?
-                       "up" : "down" : "!ena",
-                       port->value->speed == 10000 ? "10G" : "??",
-                       port->value->duplex ? "FD" : "HD",
-                       port->value->autoneg ? "Yes" : "No");
+        monitor_hmp_printf(hmp, "%10s  %-4s   %-3s  %2s  %s\n",
+                           port->value->name,
+                           port->value->enabled ? port->value->link_up ?
+                           "up" : "down" : "!ena",
+                           port->value->speed == 10000 ? "10G" : "??",
+                           port->value->duplex ? "FD" : "HD",
+                           port->value->autoneg ? "Yes" : "No");
     }
 
     qapi_free_RockerPortList(list);
@@ -69,7 +67,6 @@ void hmp_rocker_ports(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaFlowList *list, *info;
     const char *name = qdict_get_str(qdict, "name");
     uint32_t tbl_id = qdict_get_try_int(qdict, "tbl_id", -1);
@@ -80,7 +77,7 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "prio tbl hits key(mask) --> actions\n");
+    monitor_hmp_printf(hmp, "prio tbl hits key(mask) --> actions\n");
 
     for (info = list; info; info = info->next) {
         RockerOfDpaFlow *flow = info->value;
@@ -89,54 +86,54 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
         RockerOfDpaFlowAction *action = flow->action;
 
         if (flow->hits) {
-            monitor_printf(mon, "%-4d %-3d %-4" PRIu64,
-                           key->priority, key->tbl_id, flow->hits);
+            monitor_hmp_printf(hmp, "%-4d %-3d %-4" PRIu64,
+                               key->priority, key->tbl_id, flow->hits);
         } else {
-            monitor_printf(mon, "%-4d %-3d     ",
-                           key->priority, key->tbl_id);
+            monitor_hmp_printf(hmp, "%-4d %-3d     ",
+                               key->priority, key->tbl_id);
         }
 
         if (key->has_in_pport) {
-            monitor_printf(mon, " pport %d", key->in_pport);
+            monitor_hmp_printf(hmp, " pport %d", key->in_pport);
             if (mask->has_in_pport) {
-                monitor_printf(mon, "(0x%x)", mask->in_pport);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->in_pport);
             }
         }
 
         if (key->has_vlan_id) {
-            monitor_printf(mon, " vlan %d",
-                           key->vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " vlan %d",
+                               key->vlan_id & VLAN_VID_MASK);
             if (mask->has_vlan_id) {
-                monitor_printf(mon, "(0x%x)", mask->vlan_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->vlan_id);
             }
         }
 
         if (key->has_tunnel_id) {
-            monitor_printf(mon, " tunnel %d", key->tunnel_id);
+            monitor_hmp_printf(hmp, " tunnel %d", key->tunnel_id);
             if (mask->has_tunnel_id) {
-                monitor_printf(mon, "(0x%x)", mask->tunnel_id);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->tunnel_id);
             }
         }
 
         if (key->has_eth_type) {
             switch (key->eth_type) {
             case 0x0806:
-                monitor_printf(mon, " ARP");
+                monitor_hmp_printf(hmp, " ARP");
                 break;
             case 0x0800:
-                monitor_printf(mon, " IP");
+                monitor_hmp_printf(hmp, " IP");
                 break;
             case 0x86dd:
-                monitor_printf(mon, " IPv6");
+                monitor_hmp_printf(hmp, " IPv6");
                 break;
             case 0x8809:
-                monitor_printf(mon, " LACP");
+                monitor_hmp_printf(hmp, " LACP");
                 break;
             case 0x88cc:
-                monitor_printf(mon, " LLDP");
+                monitor_hmp_printf(hmp, " LLDP");
                 break;
             default:
-                monitor_printf(mon, " eth type 0x%04x", key->eth_type);
+                monitor_hmp_printf(hmp, " eth type 0x%04x", key->eth_type);
                 break;
             }
         }
@@ -145,15 +142,15 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_src, "01:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " src <any mcast/bcast>");
             } else if ((strcmp(key->eth_src, "00:00:00:00:00:00") == 0) &&
                 mask->eth_src &&
                 (strcmp(mask->eth_src, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " src <any ucast>");
+                monitor_hmp_printf(hmp, " src <any ucast>");
             } else {
-                monitor_printf(mon, " src %s", key->eth_src);
+                monitor_hmp_printf(hmp, " src %s", key->eth_src);
                 if (mask->eth_src) {
-                    monitor_printf(mon, "(%s)", mask->eth_src);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_src);
                 }
             }
         }
@@ -162,56 +159,56 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
             if ((strcmp(key->eth_dst, "01:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any mcast/bcast>");
+                monitor_hmp_printf(hmp, " dst <any mcast/bcast>");
             } else if ((strcmp(key->eth_dst, "00:00:00:00:00:00") == 0) &&
                 mask->eth_dst &&
                 (strcmp(mask->eth_dst, "01:00:00:00:00:00") == 0)) {
-                monitor_printf(mon, " dst <any ucast>");
+                monitor_hmp_printf(hmp, " dst <any ucast>");
             } else {
-                monitor_printf(mon, " dst %s", key->eth_dst);
+                monitor_hmp_printf(hmp, " dst %s", key->eth_dst);
                 if (mask->eth_dst) {
-                    monitor_printf(mon, "(%s)", mask->eth_dst);
+                    monitor_hmp_printf(hmp, "(%s)", mask->eth_dst);
                 }
             }
         }
 
         if (key->has_ip_proto) {
-            monitor_printf(mon, " proto %d", key->ip_proto);
+            monitor_hmp_printf(hmp, " proto %d", key->ip_proto);
             if (mask->has_ip_proto) {
-                monitor_printf(mon, "(0x%x)", mask->ip_proto);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_proto);
             }
         }
 
         if (key->has_ip_tos) {
-            monitor_printf(mon, " TOS %d", key->ip_tos);
+            monitor_hmp_printf(hmp, " TOS %d", key->ip_tos);
             if (mask->has_ip_tos) {
-                monitor_printf(mon, "(0x%x)", mask->ip_tos);
+                monitor_hmp_printf(hmp, "(0x%x)", mask->ip_tos);
             }
         }
 
         if (key->ip_dst) {
-            monitor_printf(mon, " dst %s", key->ip_dst);
+            monitor_hmp_printf(hmp, " dst %s", key->ip_dst);
         }
 
         if (action->has_goto_tbl || action->has_group_id ||
             action->has_new_vlan_id) {
-            monitor_printf(mon, " -->");
+            monitor_hmp_printf(hmp, " -->");
         }
 
         if (action->has_new_vlan_id) {
-            monitor_printf(mon, " apply new vlan %d",
-                           ntohs(action->new_vlan_id));
+            monitor_hmp_printf(hmp, " apply new vlan %d",
+                               ntohs(action->new_vlan_id));
         }
 
         if (action->has_group_id) {
-            monitor_printf(mon, " write group 0x%08x", action->group_id);
+            monitor_hmp_printf(hmp, " write group 0x%08x", action->group_id);
         }
 
         if (action->has_goto_tbl) {
-            monitor_printf(mon, " goto tbl %d", action->goto_tbl);
+            monitor_hmp_printf(hmp, " goto tbl %d", action->goto_tbl);
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaFlowList(list);
@@ -219,7 +216,6 @@ void hmp_rocker_of_dpa_flows(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     RockerOfDpaGroupList *list, *g;
     const char *name = qdict_get_str(qdict, "name");
     uint8_t type = qdict_get_try_int(qdict, "type", 9);
@@ -230,15 +226,15 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "id (decode) --> buckets\n");
+    monitor_hmp_printf(hmp, "id (decode) --> buckets\n");
 
     for (g = list; g; g = g->next) {
         RockerOfDpaGroup *group = g->value;
         bool set = false;
 
-        monitor_printf(mon, "0x%08x", group->id);
+        monitor_hmp_printf(hmp, "0x%08x", group->id);
 
-        monitor_printf(mon, " (type %s", group->type == 0 ? "L2 interface" :
+        monitor_hmp_printf(hmp, " (type %s", group->type == 0 ? "L2 interface" :
                                          group->type == 1 ? "L2 rewrite" :
                                          group->type == 2 ? "L3 unicast" :
                                          group->type == 3 ? "L2 multicast" :
@@ -250,70 +246,70 @@ void hmp_rocker_of_dpa_groups(MonitorHMP *hmp, const QDict *qdict)
                                          "unknown");
 
         if (group->has_vlan_id) {
-            monitor_printf(mon, " vlan %d", group->vlan_id);
+            monitor_hmp_printf(hmp, " vlan %d", group->vlan_id);
         }
 
         if (group->has_pport) {
-            monitor_printf(mon, " pport %d", group->pport);
+            monitor_hmp_printf(hmp, " pport %d", group->pport);
         }
 
         if (group->has_index) {
-            monitor_printf(mon, " index %d", group->index);
+            monitor_hmp_printf(hmp, " index %d", group->index);
         }
 
-        monitor_printf(mon, ") -->");
+        monitor_hmp_printf(hmp, ") -->");
 
         if (group->has_set_vlan_id && group->set_vlan_id) {
             set = true;
-            monitor_printf(mon, " set vlan %d",
-                           group->set_vlan_id & VLAN_VID_MASK);
+            monitor_hmp_printf(hmp, " set vlan %d",
+                               group->set_vlan_id & VLAN_VID_MASK);
         }
 
         if (group->set_eth_src) {
             if (!set) {
                 set = true;
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " src %s", group->set_eth_src);
+            monitor_hmp_printf(hmp, " src %s", group->set_eth_src);
         }
 
         if (group->set_eth_dst) {
             if (!set) {
-                monitor_printf(mon, " set");
+                monitor_hmp_printf(hmp, " set");
             }
-            monitor_printf(mon, " dst %s", group->set_eth_dst);
+            monitor_hmp_printf(hmp, " dst %s", group->set_eth_dst);
         }
 
         if (group->has_ttl_check && group->ttl_check) {
-            monitor_printf(mon, " check TTL");
+            monitor_hmp_printf(hmp, " check TTL");
         }
 
         if (group->has_group_id && group->group_id) {
-            monitor_printf(mon, " group id 0x%08x", group->group_id);
+            monitor_hmp_printf(hmp, " group id 0x%08x", group->group_id);
         }
 
         if (group->has_pop_vlan && group->pop_vlan) {
-            monitor_printf(mon, " pop vlan");
+            monitor_hmp_printf(hmp, " pop vlan");
         }
 
         if (group->has_out_pport) {
-            monitor_printf(mon, " out pport %d", group->out_pport);
+            monitor_hmp_printf(hmp, " out pport %d", group->out_pport);
         }
 
         if (group->has_group_ids) {
             struct uint32List *id;
 
-            monitor_printf(mon, " groups [");
+            monitor_hmp_printf(hmp, " groups [");
             for (id = group->group_ids; id; id = id->next) {
-                monitor_printf(mon, "0x%08x", id->value);
+                monitor_hmp_printf(hmp, "0x%08x", id->value);
                 if (id->next) {
-                    monitor_printf(mon, ",");
+                    monitor_hmp_printf(hmp, ",");
                 }
             }
-            monitor_printf(mon, "]");
+            monitor_hmp_printf(hmp, "]");
         }
 
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     qapi_free_RockerOfDpaGroupList(list);
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index 51d95d76620e..500f821246a9 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -24,54 +24,55 @@
 #include "qapi/qapi-commands-pci.h"
 #include "qemu/cutils.h"
 
-static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
+static void hmp_info_pci_device(MonitorHMP *hmp, const PciDeviceInfo *dev)
 {
+    Monitor *mon = MONITOR(hmp);
     PciMemoryRegionList *region;
 
-    monitor_printf(mon, "  Bus %2" PRId64 ", ", dev->bus);
-    monitor_printf(mon, "device %3" PRId64 ", function %" PRId64 ":\n",
-                   dev->slot, dev->function);
-    monitor_printf(mon, "    ");
+    monitor_hmp_printf(hmp, "  Bus %2" PRId64 ", ", dev->bus);
+    monitor_hmp_printf(hmp, "device %3" PRId64 ", function %" PRId64 ":\n",
+                       dev->slot, dev->function);
+    monitor_hmp_printf(hmp, "    ");
 
     if (dev->class_info->desc) {
         monitor_puts(mon, dev->class_info->desc);
     } else {
-        monitor_printf(mon, "Class %04" PRId64, dev->class_info->q_class);
+        monitor_hmp_printf(hmp, "Class %04" PRId64, dev->class_info->q_class);
     }
 
-    monitor_printf(mon, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
-                   dev->id->vendor, dev->id->device);
+    monitor_hmp_printf(hmp, ": PCI device %04" PRIx64 ":%04" PRIx64 "\n",
+                       dev->id->vendor, dev->id->device);
     if (dev->id->has_subsystem_vendor && dev->id->has_subsystem) {
-        monitor_printf(mon, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
-                       dev->id->subsystem_vendor, dev->id->subsystem);
+        monitor_hmp_printf(hmp, "      PCI subsystem %04" PRIx64 ":%04" PRIx64 "\n",
+                           dev->id->subsystem_vendor, dev->id->subsystem);
     }
 
     if (dev->has_irq) {
-        monitor_printf(mon, "      IRQ %" PRId64 ", pin %c\n",
-                       dev->irq, (char)('A' + dev->irq_pin - 1));
+        monitor_hmp_printf(hmp, "      IRQ %" PRId64 ", pin %c\n",
+                           dev->irq, (char)('A' + dev->irq_pin - 1));
     }
 
     if (dev->pci_bridge) {
-        monitor_printf(mon, "      BUS %" PRId64 ".\n",
-                       dev->pci_bridge->bus->number);
-        monitor_printf(mon, "      secondary bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->secondary);
-        monitor_printf(mon, "      subordinate bus %" PRId64 ".\n",
-                       dev->pci_bridge->bus->subordinate);
+        monitor_hmp_printf(hmp, "      BUS %" PRId64 ".\n",
+                           dev->pci_bridge->bus->number);
+        monitor_hmp_printf(hmp, "      secondary bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->secondary);
+        monitor_hmp_printf(hmp, "      subordinate bus %" PRId64 ".\n",
+                           dev->pci_bridge->bus->subordinate);
 
-        monitor_printf(mon, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
-                       dev->pci_bridge->bus->io_range->base,
-                       dev->pci_bridge->bus->io_range->limit);
+        monitor_hmp_printf(hmp, "      IO range [0x%04"PRIx64", 0x%04"PRIx64"]\n",
+                           dev->pci_bridge->bus->io_range->base,
+                           dev->pci_bridge->bus->io_range->limit);
 
-        monitor_printf(mon,
-                       "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->memory_range->base,
-                       dev->pci_bridge->bus->memory_range->limit);
+        monitor_hmp_printf(hmp,
+                           "      memory range [0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->memory_range->base,
+                           dev->pci_bridge->bus->memory_range->limit);
 
-        monitor_printf(mon, "      prefetchable memory range "
-                       "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
-                       dev->pci_bridge->bus->prefetchable_range->base,
-                       dev->pci_bridge->bus->prefetchable_range->limit);
+        monitor_hmp_printf(hmp, "      prefetchable memory range "
+                           "[0x%08"PRIx64", 0x%08"PRIx64"]\n",
+                           dev->pci_bridge->bus->prefetchable_range->base,
+                           dev->pci_bridge->bus->prefetchable_range->limit);
     }
 
     for (region = dev->regions; region; region = region->next) {
@@ -80,38 +81,38 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
         addr = region->value->address;
         size = region->value->size;
 
-        monitor_printf(mon, "      BAR%" PRId64 ": ", region->value->bar);
+        monitor_hmp_printf(hmp, "      BAR%" PRId64 ": ", region->value->bar);
 
         if (!strcmp(region->value->type, "io")) {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "I/O at 0x%04" PRIx64
+                monitor_hmp_printf(hmp, "I/O at 0x%04" PRIx64
                                     " [0x%04" PRIx64 "]\n",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "I/O (not mapped)\n");
+                monitor_hmp_printf(hmp, "I/O (not mapped)\n");
             }
         } else {
             if (addr != PCI_BAR_UNMAPPED) {
-                monitor_printf(mon, "%d bit%s memory at 0x%08" PRIx64
+                monitor_hmp_printf(hmp, "%d bit%s memory at 0x%08" PRIx64
                                    " [0x%08" PRIx64 "]\n",
                                region->value->mem_type_64 ? 64 : 32,
                                region->value->prefetch ? " prefetchable" : "",
                                addr, addr + size - 1);
             } else {
-                monitor_printf(mon, "%d bit%s memory (not mapped)\n",
-                               region->value->mem_type_64 ? 64 : 32,
-                               region->value->prefetch ? " prefetchable" : "");
+                monitor_hmp_printf(hmp, "%d bit%s memory (not mapped)\n",
+                                   region->value->mem_type_64 ? 64 : 32,
+                                   region->value->prefetch ? " prefetchable" : "");
             }
         }
     }
 
-    monitor_printf(mon, "      id \"%s\"\n", dev->qdev_id);
+    monitor_hmp_printf(hmp, "      id \"%s\"\n", dev->qdev_id);
 
     if (dev->pci_bridge) {
         if (dev->pci_bridge->has_devices) {
             PciDeviceInfoList *cdev;
             for (cdev = dev->pci_bridge->devices; cdev; cdev = cdev->next) {
-                hmp_info_pci_device(mon, cdev->value);
+                hmp_info_pci_device(hmp, cdev->value);
             }
         }
     }
@@ -119,7 +120,6 @@ static void hmp_info_pci_device(Monitor *mon, const PciDeviceInfo *dev)
 
 void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     PciInfoList *info_list, *info;
 
     info_list = qmp_query_pci(&error_abort);
@@ -128,7 +128,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
         PciDeviceInfoList *dev;
 
         for (dev = info->value->devices; dev; dev = dev->next) {
-            hmp_info_pci_device(mon, dev->value);
+            hmp_info_pci_device(hmp, dev->value);
         }
     }
 
@@ -137,6 +137,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     PCIDevice *d = (PCIDevice *)dev;
     int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
     const pci_class_desc *desc = get_class_desc(class);
@@ -150,30 +151,29 @@ void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
         snprintf(ctxt, sizeof(ctxt), "Class %04x", class);
     }
 
-    monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, "
-                   "pci id %04x:%04x (sub %04x:%04x)\n",
-                   indent, "", ctxt, pci_dev_bus_num(d),
-                   PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                   pci_get_word(d->config + PCI_VENDOR_ID),
-                   pci_get_word(d->config + PCI_DEVICE_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
-                   pci_get_word(d->config + PCI_SUBSYSTEM_ID));
+    monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, "
+                       "pci id %04x:%04x (sub %04x:%04x)\n",
+                       indent, "", ctxt, pci_dev_bus_num(d),
+                       PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+                       pci_get_word(d->config + PCI_VENDOR_ID),
+                       pci_get_word(d->config + PCI_DEVICE_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID),
+                       pci_get_word(d->config + PCI_SUBSYSTEM_ID));
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
         if (!r->size) {
             continue;
         }
-        monitor_printf(mon, "%*sbar %d: %s at 0x%"FMT_PCIBUS
-                       " [0x%"FMT_PCIBUS"]\n",
-                       indent, "",
-                       i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
-                       r->addr, r->addr + r->size - 1);
+        monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS
+                           " [0x%"FMT_PCIBUS"]\n",
+                           indent, "",
+                           i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem",
+                           r->addr, r->addr + r->size - 1);
     }
 }
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *id = qdict_get_str(qdict, "id");
     const char *error_name;
@@ -242,9 +242,9 @@ void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
     }
 
 
-    monitor_printf(mon, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
-                   id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
-                   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+    monitor_hmp_printf(hmp, "OK id: %s root bus: %s, bus: %x devfn: %x.%x\n",
+                       id, pci_root_bus_path(dev), pci_dev_bus_num(dev),
+                       PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
 
 out:
     hmp_handle_error(hmp, err);
diff --git a/hw/pci/pci-stub.c b/hw/pci/pci-stub.c
index a80e34175462..7e2797300ba0 100644
--- a/hw/pci/pci-stub.c
+++ b/hw/pci/pci-stub.c
@@ -40,8 +40,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "PCI devices not supported\n");
+    monitor_hmp_printf(hmp, "PCI devices not supported\n");
 }
 
 /* kvm-all wants this */
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index d8afaf730639..b5e56a16cce1 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -106,7 +106,6 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
 
 void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390SKeysState *ss = s390_get_skeys_device();
     S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -115,24 +114,24 @@ void hmp_info_skeys(MonitorHMP *hmp, const QDict *qdict)
 
     /* Quick check to see if guest is using storage keys*/
     if (!skeyclass->skeys_are_enabled(ss)) {
-        monitor_printf(mon, "Error: This guest is not using storage keys\n");
+        monitor_hmp_printf(hmp, "Error: This guest is not using storage keys\n");
         return;
     }
 
     if (!address_space_access_valid(&address_space_memory,
                                     addr & TARGET_PAGE_MASK, TARGET_PAGE_SIZE,
                                     false, MEMTXATTRS_UNSPECIFIED)) {
-        monitor_printf(mon, "Error: The given address is not valid\n");
+        monitor_hmp_printf(hmp, "Error: The given address is not valid\n");
         return;
     }
 
     r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s\n", strerror(-r));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(-r));
         return;
     }
 
-    monitor_printf(mon, "  key: 0x%X\n", key);
+    monitor_hmp_printf(hmp, "  key: 0x%X\n", key);
 }
 
 void hmp_dump_skeys(MonitorHMP *hmp, const QDict *qdict)
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index b4a405455901..644298f7f0b2 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -61,7 +61,6 @@ void s390_stattrib_init(void)
 
 void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t what = qdict_get_int(qdict, "mode");
@@ -70,14 +69,13 @@ void hmp_migrationmode(MonitorHMP *hmp, const QDict *qdict)
 
     r = sac->set_migrationmode(sas, what, &local_err);
     if (r < 0) {
-        monitor_printf(mon, "Error: %s", error_get_pretty(local_err));
+        monitor_hmp_printf(hmp, "Error: %s", error_get_pretty(local_err));
         error_free(local_err);
     }
 }
 
 void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     S390StAttribState *sas = s390_get_stattrib_device();
     S390StAttribClass *sac = S390_STATTRIB_GET_CLASS(sas);
     uint64_t addr = qdict_get_int(qdict, "addr");
@@ -87,27 +85,27 @@ void hmp_info_cmma(MonitorHMP *hmp, const QDict *qdict)
 
     vals = g_try_malloc(buflen);
     if (!vals) {
-        monitor_printf(mon, "Error: %s\n", strerror(errno));
+        monitor_hmp_printf(hmp, "Error: %s\n", strerror(errno));
         return;
     }
 
     len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
     if (len < 0) {
-        monitor_printf(mon, "Error: %s", strerror(-len));
+        monitor_hmp_printf(hmp, "Error: %s", strerror(-len));
         goto out;
     }
 
-    monitor_printf(mon, "  CMMA attributes, "
-                   "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
-                   addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
+    monitor_hmp_printf(hmp, "  CMMA attributes, "
+                       "pages %" PRIu64 "+%d (0x%" PRIx64 "):\n",
+                       addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
     for (cx = 0; cx < len; cx++) {
         if (cx % 8 == 7) {
-            monitor_printf(mon, "%02x\n", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x\n", vals[cx]);
         } else {
-            monitor_printf(mon, "%02x", vals[cx]);
+            monitor_hmp_printf(hmp, "%02x", vals[cx]);
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
 out:
     g_free(vals);
diff --git a/hw/uefi/ovmf-log.c b/hw/uefi/ovmf-log.c
index 0d59a74ad60e..0249eea2cfe9 100644
--- a/hw/uefi/ovmf-log.c
+++ b/hw/uefi/ovmf-log.c
@@ -258,7 +258,6 @@ FirmwareLog *qmp_query_firmware_log(bool have_max_size, uint64_t max_size,
 
 void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autofree gchar *log_esc = NULL;
     g_autofree guchar *log_out = NULL;
     Error *err = NULL;
@@ -278,10 +277,10 @@ void hmp_info_firmware_log(MonitorHMP *hmp, const QDict *qdict)
 
     if (log->version) {
         g_autofree gchar *esc = g_strescape(log->version, NULL);
-        monitor_printf(mon, "[ firmware version: %s ]\n", esc);
+        monitor_hmp_printf(hmp, "[ firmware version: %s ]\n", esc);
     }
 
     log_out = g_base64_decode(log->log, &log_len);
     log_esc = g_strescape((gchar *)log_out, "\r\n");
-    monitor_printf(mon, "%s\n", log_esc);
+    monitor_hmp_printf(hmp, "%s\n", log_esc);
 }
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 9b9b2e7c2f8f..fe3dbfa2227c 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -546,14 +546,15 @@ static const char *usb_speed(unsigned int speed)
 
 static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     USBDevice *dev = USB_DEVICE(qdev);
     USBBus *bus = usb_bus_from_device(dev);
 
-    monitor_printf(mon, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
-                   indent, "", bus->busnr, dev->addr,
-                   dev->port ? dev->port->path : "-",
-                   usb_speed(dev->speed), dev->product_desc,
-                   dev->attached ? ", attached" : "");
+    monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n",
+                       indent, "", bus->busnr, dev->addr,
+                       dev->port ? dev->port->path : "-",
+                       usb_speed(dev->speed), dev->product_desc,
+                       dev->attached ? ", attached" : "");
 }
 
 static char *usb_get_dev_path(DeviceState *qdev)
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index c02343d3a655..9b9f26a1078e 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -1922,7 +1922,6 @@ static void usb_host_auto_check(void *unused)
 
 void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     libusb_device **devs = NULL;
     struct libusb_device_descriptor ddesc;
     char port[16];
@@ -1941,14 +1940,14 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
             continue;
         }
         usb_host_get_port(devs[i], port, sizeof(port));
-        monitor_printf(mon, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
-                       libusb_get_bus_number(devs[i]),
-                       libusb_get_device_address(devs[i]),
-                       port,
-                       speed_name[libusb_get_device_speed(devs[i])]);
-        monitor_printf(mon, "    Class %02x:", ddesc.bDeviceClass);
-        monitor_printf(mon, " USB device %04x:%04x",
-                       ddesc.idVendor, ddesc.idProduct);
+        monitor_hmp_printf(hmp, "  Bus %d, Addr %d, Port %s, Speed %s Mb/s\n",
+                           libusb_get_bus_number(devs[i]),
+                           libusb_get_device_address(devs[i]),
+                           port,
+                           speed_name[libusb_get_device_speed(devs[i])]);
+        monitor_hmp_printf(hmp, "    Class %02x:", ddesc.bDeviceClass);
+        monitor_hmp_printf(hmp, " USB device %04x:%04x",
+                           ddesc.idVendor, ddesc.idProduct);
         if (ddesc.iProduct) {
             libusb_device_handle *handle;
             if (libusb_open(devs[i], &handle) == 0) {
@@ -1957,10 +1956,10 @@ void hmp_info_usbhost(MonitorHMP *hmp, const QDict *qdict)
                                                    ddesc.iProduct,
                                                    name, sizeof(name));
                 libusb_close(handle);
-                monitor_printf(mon, ", %s", name);
+                monitor_hmp_printf(hmp, ", %s", name);
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
     libusb_free_device_list(devs, 1);
 }
diff --git a/hw/virtio/virtio-hmp-cmds.c b/hw/virtio/virtio-hmp-cmds.c
index fb36c8b9274c..e5da6f00699d 100644
--- a/hw/virtio/virtio-hmp-cmds.c
+++ b/hw/virtio/virtio-hmp-cmds.c
@@ -12,77 +12,76 @@
 #include "qobject/qdict.h"
 
 
-static void hmp_virtio_dump_protocols(Monitor *mon,
+static void hmp_virtio_dump_protocols(MonitorHMP *hmp,
                                       VhostDeviceProtocols *pcol)
 {
     strList *pcol_list = pcol->protocols;
     while (pcol_list) {
-        monitor_printf(mon, "\t%s", pcol_list->value);
+        monitor_hmp_printf(hmp, "\t%s", pcol_list->value);
         pcol_list = pcol_list->next;
         if (pcol_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (pcol->has_unknown_protocols) {
-        monitor_printf(mon, "  unknown-protocols(0x%016"PRIx64")\n",
-                       pcol->unknown_protocols);
+        monitor_hmp_printf(hmp, "  unknown-protocols(0x%016"PRIx64")\n",
+                           pcol->unknown_protocols);
     }
 }
 
-static void hmp_virtio_dump_status(Monitor *mon,
+static void hmp_virtio_dump_status(MonitorHMP *hmp,
                                    VirtioDeviceStatus *status)
 {
     strList *status_list = status->statuses;
     while (status_list) {
-        monitor_printf(mon, "\t%s", status_list->value);
+        monitor_hmp_printf(hmp, "\t%s", status_list->value);
         status_list = status_list->next;
         if (status_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     if (status->has_unknown_statuses) {
-        monitor_printf(mon, "  unknown-statuses(0x%016"PRIx32")\n",
-                       status->unknown_statuses);
+        monitor_hmp_printf(hmp, "  unknown-statuses(0x%016"PRIx32")\n",
+                           status->unknown_statuses);
     }
 }
 
-static void hmp_virtio_dump_features(Monitor *mon,
+static void hmp_virtio_dump_features(MonitorHMP *hmp,
                                      VirtioDeviceFeatures *features)
 {
     strList *transport_list = features->transports;
     while (transport_list) {
-        monitor_printf(mon, "\t%s", transport_list->value);
+        monitor_hmp_printf(hmp, "\t%s", transport_list->value);
         transport_list = transport_list->next;
         if (transport_list != NULL) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
     strList *list = features->dev_features;
     if (list) {
         while (list) {
-            monitor_printf(mon, "\t%s", list->value);
+            monitor_hmp_printf(hmp, "\t%s", list->value);
             list = list->next;
             if (list != NULL) {
-                monitor_printf(mon, ",\n");
+                monitor_hmp_printf(hmp, ",\n");
             }
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (features->has_unknown_dev_features) {
-        monitor_printf(mon, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
-                       features->unknown_dev_features2,
-                       features->unknown_dev_features);
+        monitor_hmp_printf(hmp, "  unknown-features(0x%016"PRIx64"%016"PRIx64")\n",
+                           features->unknown_dev_features2,
+                           features->unknown_dev_features);
     }
 }
 
 void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     VirtioInfoList *list = qmp_x_query_virtio(&err);
     VirtioInfoList *node;
@@ -93,14 +92,14 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
     }
 
     if (list == NULL) {
-        monitor_printf(mon, "No VirtIO devices\n");
+        monitor_hmp_printf(hmp, "No VirtIO devices\n");
         return;
     }
 
     node = list;
     while (node) {
-        monitor_printf(mon, "%s [%s]\n", node->value->path,
-                       node->value->name);
+        monitor_hmp_printf(hmp, "%s [%s]\n", node->value->path,
+                           node->value->name);
         node = node->next;
     }
     qapi_free_VirtioInfoList(list);
@@ -108,7 +107,6 @@ void hmp_virtio_query(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     VirtioStatus *s = qmp_x_query_virtio_status(path, &err);
@@ -118,68 +116,68 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:             %s %s\n",
-                   s->name, s->vhost_dev ? "(vhost)" : "");
-    monitor_printf(mon, "  device_id:               %d\n", s->device_id);
-    monitor_printf(mon, "  vhost_started:           %s\n",
-                   s->vhost_started ? "true" : "false");
-    monitor_printf(mon, "  bus_name:                %s\n", s->bus_name);
-    monitor_printf(mon, "  broken:                  %s\n",
-                   s->broken ? "true" : "false");
-    monitor_printf(mon, "  disabled:                %s\n",
-                   s->disabled ? "true" : "false");
-    monitor_printf(mon, "  disable_legacy_check:    %s\n",
-                   s->disable_legacy_check ? "true" : "false");
-    monitor_printf(mon, "  started:                 %s\n",
-                   s->started ? "true" : "false");
-    monitor_printf(mon, "  use_started:             %s\n",
-                   s->use_started ? "true" : "false");
-    monitor_printf(mon, "  start_on_kick:           %s\n",
-                   s->start_on_kick ? "true" : "false");
-    monitor_printf(mon, "  use_guest_notifier_mask: %s\n",
-                   s->use_guest_notifier_mask ? "true" : "false");
-    monitor_printf(mon, "  vm_running:              %s\n",
-                   s->vm_running ? "true" : "false");
-    monitor_printf(mon, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
-    monitor_printf(mon, "  queue_sel:               %d\n",
-                   s->queue_sel);
-    monitor_printf(mon, "  isr:                     %d\n", s->isr);
-    monitor_printf(mon, "  endianness:              %s\n",
-                   s->device_endian);
-    monitor_printf(mon, "  status:\n");
-    hmp_virtio_dump_status(mon, s->status);
-    monitor_printf(mon, "  Guest features:\n");
-    hmp_virtio_dump_features(mon, s->guest_features);
-    monitor_printf(mon, "  Host features:\n");
-    hmp_virtio_dump_features(mon, s->host_features);
-    monitor_printf(mon, "  Backend features:\n");
-    hmp_virtio_dump_features(mon, s->backend_features);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:             %s %s\n",
+                       s->name, s->vhost_dev ? "(vhost)" : "");
+    monitor_hmp_printf(hmp, "  device_id:               %d\n", s->device_id);
+    monitor_hmp_printf(hmp, "  vhost_started:           %s\n",
+                       s->vhost_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  bus_name:                %s\n", s->bus_name);
+    monitor_hmp_printf(hmp, "  broken:                  %s\n",
+                       s->broken ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disabled:                %s\n",
+                       s->disabled ? "true" : "false");
+    monitor_hmp_printf(hmp, "  disable_legacy_check:    %s\n",
+                       s->disable_legacy_check ? "true" : "false");
+    monitor_hmp_printf(hmp, "  started:                 %s\n",
+                       s->started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_started:             %s\n",
+                       s->use_started ? "true" : "false");
+    monitor_hmp_printf(hmp, "  start_on_kick:           %s\n",
+                       s->start_on_kick ? "true" : "false");
+    monitor_hmp_printf(hmp, "  use_guest_notifier_mask: %s\n",
+                       s->use_guest_notifier_mask ? "true" : "false");
+    monitor_hmp_printf(hmp, "  vm_running:              %s\n",
+                       s->vm_running ? "true" : "false");
+    monitor_hmp_printf(hmp, "  num_vqs:                 %"PRId64"\n", s->num_vqs);
+    monitor_hmp_printf(hmp, "  queue_sel:               %d\n",
+                       s->queue_sel);
+    monitor_hmp_printf(hmp, "  isr:                     %d\n", s->isr);
+    monitor_hmp_printf(hmp, "  endianness:              %s\n",
+                       s->device_endian);
+    monitor_hmp_printf(hmp, "  status:\n");
+    hmp_virtio_dump_status(hmp, s->status);
+    monitor_hmp_printf(hmp, "  Guest features:\n");
+    hmp_virtio_dump_features(hmp, s->guest_features);
+    monitor_hmp_printf(hmp, "  Host features:\n");
+    hmp_virtio_dump_features(hmp, s->host_features);
+    monitor_hmp_printf(hmp, "  Backend features:\n");
+    hmp_virtio_dump_features(hmp, s->backend_features);
 
     if (s->vhost_dev) {
-        monitor_printf(mon, "  VHost:\n");
-        monitor_printf(mon, "    nvqs:           %d\n",
-                       s->vhost_dev->nvqs);
-        monitor_printf(mon, "    vq_index:       %"PRId64"\n",
-                       s->vhost_dev->vq_index);
-        monitor_printf(mon, "    max_queues:     %"PRId64"\n",
-                       s->vhost_dev->max_queues);
-        monitor_printf(mon, "    n_mem_sections: %"PRId64"\n",
-                       s->vhost_dev->n_mem_sections);
-        monitor_printf(mon, "    n_tmp_sections: %"PRId64"\n",
-                       s->vhost_dev->n_tmp_sections);
-        monitor_printf(mon, "    backend_cap:    %"PRId64"\n",
-                       s->vhost_dev->backend_cap);
-        monitor_printf(mon, "    log_enabled:    %s\n",
-                       s->vhost_dev->log_enabled ? "true" : "false");
-        monitor_printf(mon, "    log_size:       %"PRId64"\n",
-                       s->vhost_dev->log_size);
-        monitor_printf(mon, "    Features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->features);
-        monitor_printf(mon, "    Acked features:\n");
-        hmp_virtio_dump_features(mon, s->vhost_dev->acked_features);
-        monitor_printf(mon, "    Protocol features:\n");
-        hmp_virtio_dump_protocols(mon, s->vhost_dev->protocol_features);
+        monitor_hmp_printf(hmp, "  VHost:\n");
+        monitor_hmp_printf(hmp, "    nvqs:           %d\n",
+                           s->vhost_dev->nvqs);
+        monitor_hmp_printf(hmp, "    vq_index:       %"PRId64"\n",
+                           s->vhost_dev->vq_index);
+        monitor_hmp_printf(hmp, "    max_queues:     %"PRId64"\n",
+                           s->vhost_dev->max_queues);
+        monitor_hmp_printf(hmp, "    n_mem_sections: %"PRId64"\n",
+                           s->vhost_dev->n_mem_sections);
+        monitor_hmp_printf(hmp, "    n_tmp_sections: %"PRId64"\n",
+                           s->vhost_dev->n_tmp_sections);
+        monitor_hmp_printf(hmp, "    backend_cap:    %"PRId64"\n",
+                           s->vhost_dev->backend_cap);
+        monitor_hmp_printf(hmp, "    log_enabled:    %s\n",
+                           s->vhost_dev->log_enabled ? "true" : "false");
+        monitor_hmp_printf(hmp, "    log_size:       %"PRId64"\n",
+                           s->vhost_dev->log_size);
+        monitor_hmp_printf(hmp, "    Features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->features);
+        monitor_hmp_printf(hmp, "    Acked features:\n");
+        hmp_virtio_dump_features(hmp, s->vhost_dev->acked_features);
+        monitor_hmp_printf(hmp, "    Protocol features:\n");
+        hmp_virtio_dump_protocols(hmp, s->vhost_dev->protocol_features);
     }
 
     qapi_free_VirtioStatus(s);
@@ -187,7 +185,6 @@ void hmp_virtio_status(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -199,29 +196,28 @@ void hmp_vhost_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s (vhost)\n",
-                   s->name);
-    monitor_printf(mon, "  kick:                 %"PRId64"\n", s->kick);
-    monitor_printf(mon, "  call:                 %"PRId64"\n", s->call);
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:         %"PRId64"\n", s->num);
-    monitor_printf(mon, "    desc_phys:   0x%016"PRIx64"\n",
-                   s->desc_phys);
-    monitor_printf(mon, "    desc_size:   %"PRId32"\n", s->desc_size);
-    monitor_printf(mon, "    avail_phys:  0x%016"PRIx64"\n",
-                   s->avail_phys);
-    monitor_printf(mon, "    avail_size:  %"PRId32"\n", s->avail_size);
-    monitor_printf(mon, "    used_phys:   0x%016"PRIx64"\n",
-                   s->used_phys);
-    monitor_printf(mon, "    used_size:   %"PRId32"\n", s->used_size);
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s (vhost)\n",
+                       s->name);
+    monitor_hmp_printf(hmp, "  kick:                 %"PRId64"\n", s->kick);
+    monitor_hmp_printf(hmp, "  call:                 %"PRId64"\n", s->call);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:         %"PRId64"\n", s->num);
+    monitor_hmp_printf(hmp, "    desc_phys:   0x%016"PRIx64"\n",
+                       s->desc_phys);
+    monitor_hmp_printf(hmp, "    desc_size:   %"PRId32"\n", s->desc_size);
+    monitor_hmp_printf(hmp, "    avail_phys:  0x%016"PRIx64"\n",
+                       s->avail_phys);
+    monitor_hmp_printf(hmp, "    avail_size:  %"PRId32"\n", s->avail_size);
+    monitor_hmp_printf(hmp, "    used_phys:   0x%016"PRIx64"\n",
+                       s->used_phys);
+    monitor_hmp_printf(hmp, "    used_size:   %"PRId32"\n", s->used_size);
 
     qapi_free_VirtVhostQueueStatus(s);
 }
 
 void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -232,42 +228,41 @@ void hmp_virtio_queue_status(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name:          %s\n", s->name);
-    monitor_printf(mon, "  queue_index:          %d\n", s->queue_index);
-    monitor_printf(mon, "  inuse:                %d\n", s->inuse);
-    monitor_printf(mon, "  used_idx:             %d\n", s->used_idx);
-    monitor_printf(mon, "  signalled_used:       %d\n",
-                   s->signalled_used);
-    monitor_printf(mon, "  signalled_used_valid: %s\n",
-                   s->signalled_used_valid ? "true" : "false");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name:          %s\n", s->name);
+    monitor_hmp_printf(hmp, "  queue_index:          %d\n", s->queue_index);
+    monitor_hmp_printf(hmp, "  inuse:                %d\n", s->inuse);
+    monitor_hmp_printf(hmp, "  used_idx:             %d\n", s->used_idx);
+    monitor_hmp_printf(hmp, "  signalled_used:       %d\n",
+                       s->signalled_used);
+    monitor_hmp_printf(hmp, "  signalled_used_valid: %s\n",
+                       s->signalled_used_valid ? "true" : "false");
     if (s->has_last_avail_idx) {
-        monitor_printf(mon, "  last_avail_idx:       %d\n",
-                       s->last_avail_idx);
+        monitor_hmp_printf(hmp, "  last_avail_idx:       %d\n",
+                           s->last_avail_idx);
     }
     if (s->has_shadow_avail_idx) {
-        monitor_printf(mon, "  shadow_avail_idx:     %d\n",
-                       s->shadow_avail_idx);
+        monitor_hmp_printf(hmp, "  shadow_avail_idx:     %d\n",
+                           s->shadow_avail_idx);
     }
-    monitor_printf(mon, "  VRing:\n");
-    monitor_printf(mon, "    num:          %"PRId32"\n", s->vring_num);
-    monitor_printf(mon, "    num_default:  %"PRId32"\n",
-                   s->vring_num_default);
-    monitor_printf(mon, "    align:        %"PRId32"\n",
-                   s->vring_align);
-    monitor_printf(mon, "    desc:         0x%016"PRIx64"\n",
-                   s->vring_desc);
-    monitor_printf(mon, "    avail:        0x%016"PRIx64"\n",
-                   s->vring_avail);
-    monitor_printf(mon, "    used:         0x%016"PRIx64"\n",
-                   s->vring_used);
+    monitor_hmp_printf(hmp, "  VRing:\n");
+    monitor_hmp_printf(hmp, "    num:          %"PRId32"\n", s->vring_num);
+    monitor_hmp_printf(hmp, "    num_default:  %"PRId32"\n",
+                       s->vring_num_default);
+    monitor_hmp_printf(hmp, "    align:        %"PRId32"\n",
+                       s->vring_align);
+    monitor_hmp_printf(hmp, "    desc:         0x%016"PRIx64"\n",
+                       s->vring_desc);
+    monitor_hmp_printf(hmp, "    avail:        0x%016"PRIx64"\n",
+                       s->vring_avail);
+    monitor_hmp_printf(hmp, "    used:         0x%016"PRIx64"\n",
+                       s->vring_used);
 
     qapi_free_VirtQueueStatus(s);
 }
 
 void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *path = qdict_get_try_str(qdict, "path");
     int queue = qdict_get_int(qdict, "queue");
@@ -282,41 +277,41 @@ void hmp_virtio_queue_element(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "%s:\n", path);
-    monitor_printf(mon, "  device_name: %s\n", e->name);
-    monitor_printf(mon, "  index:   %d\n", e->index);
-    monitor_printf(mon, "  desc:\n");
-    monitor_printf(mon, "    descs:\n");
+    monitor_hmp_printf(hmp, "%s:\n", path);
+    monitor_hmp_printf(hmp, "  device_name: %s\n", e->name);
+    monitor_hmp_printf(hmp, "  index:   %d\n", e->index);
+    monitor_hmp_printf(hmp, "  desc:\n");
+    monitor_hmp_printf(hmp, "    descs:\n");
 
     list = e->descs;
     while (list) {
-        monitor_printf(mon, "        addr 0x%"PRIx64" len %d",
-                       list->value->addr, list->value->len);
+        monitor_hmp_printf(hmp, "        addr 0x%"PRIx64" len %d",
+                           list->value->addr, list->value->len);
         if (list->value->flags) {
             strList *flag = list->value->flags;
-            monitor_printf(mon, " (");
+            monitor_hmp_printf(hmp, " (");
             while (flag) {
-                monitor_printf(mon, "%s", flag->value);
+                monitor_hmp_printf(hmp, "%s", flag->value);
                 flag = flag->next;
                 if (flag) {
-                    monitor_printf(mon, ", ");
+                    monitor_hmp_printf(hmp, ", ");
                 }
             }
-            monitor_printf(mon, ")");
+            monitor_hmp_printf(hmp, ")");
         }
         list = list->next;
         if (list) {
-            monitor_printf(mon, ",\n");
+            monitor_hmp_printf(hmp, ",\n");
         }
     }
-    monitor_printf(mon, "\n");
-    monitor_printf(mon, "  avail:\n");
-    monitor_printf(mon, "    flags: %d\n", e->avail->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->avail->idx);
-    monitor_printf(mon, "    ring:  %d\n", e->avail->ring);
-    monitor_printf(mon, "  used:\n");
-    monitor_printf(mon, "    flags: %d\n", e->used->flags);
-    monitor_printf(mon, "    idx:   %d\n", e->used->idx);
+    monitor_hmp_printf(hmp, "\n");
+    monitor_hmp_printf(hmp, "  avail:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->avail->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->avail->idx);
+    monitor_hmp_printf(hmp, "    ring:  %d\n", e->avail->ring);
+    monitor_hmp_printf(hmp, "  used:\n");
+    monitor_hmp_printf(hmp, "    flags: %d\n", e->used->flags);
+    monitor_hmp_printf(hmp, "    idx:   %d\n", e->used->idx);
 
     qapi_free_VirtioQueueElement(e);
 }
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index a563f6066bb4..4075b5b001ae 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -103,10 +103,11 @@ abort:
 
 static void xen_bus_print_dev(Monitor *mon, DeviceState *dev, int indent)
 {
+    MonitorHMP *hmp = MONITOR_HMP(mon);
     XenDevice *xendev = XEN_DEVICE(dev);
 
-    monitor_printf(mon, "%*sname = '%s' frontend_id = %u\n",
-                   indent, "", xendev->name, xendev->frontend_id);
+    monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
+                       indent, "", xendev->name, xendev->frontend_id);
 }
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
diff --git a/include/disas/disas.h b/include/disas/disas.h
index c702b1effc1c..47daa9b4d2df 100644
--- a/include/disas/disas.h
+++ b/include/disas/disas.h
@@ -1,13 +1,15 @@
 #ifndef QEMU_DISAS_H
 #define QEMU_DISAS_H
 
+#include "monitor/hmp.h"
+
 /* Disassemble this for me please... (debugging). */
 #ifdef CONFIG_TCG
 void disas(FILE *out, const void *code, size_t size);
 void target_disas(FILE *out, CPUState *cpu, const DisasContextBase *db);
 #endif
 
-void monitor_disas(Monitor *mon, CPUState *cpu, uint64_t pc,
+void monitor_disas(MonitorHMP *hmp, CPUState *cpu, uint64_t pc,
                    int nb_insn, bool is_physical);
 
 #ifdef CONFIG_PLUGIN
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index 3fd17048b319..f10bf83df86d 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -38,10 +38,10 @@ void monitor_new_hmp(const char *id, const char *chardev_id,
 
 MonitorHMP *monitor_cur_hmp(void);
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
     G_GNUC_PRINTF(2, 0);
-int monitor_printf(Monitor *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
-void monitor_printc(Monitor *mon, int ch);
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...) G_GNUC_PRINTF(2, 3);
+void monitor_hmp_printc(MonitorHMP *mon, int ch);
 
 void monitor_hmp_read_command(MonitorHMP *hmp, int show_prompt);
 int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
@@ -58,7 +58,7 @@ CPUState *monitor_hmp_get_cpu(MonitorHMP *hmp);
 int monitor_hmp_get_cpu_index(MonitorHMP *hmp);
 
 bool hmp_handle_error(MonitorHMP *hmp, Error *err);
-void hmp_help_cmd(Monitor *mon, const char *name);
+void hmp_help_cmd(MonitorHMP *hmp, const char *name);
 strList *hmp_split_at_comma(const char *str);
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict);
@@ -114,11 +114,11 @@ void hmp_set_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_expire_password(MonitorHMP *hmp, const QDict *qdict);
 void hmp_change(MonitorHMP *hmp, const QDict *qdict);
 #ifdef CONFIG_VNC
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp);
 #endif
-void hmp_change_medium(Monitor *mon, const char *device, const char *target,
+void hmp_change_medium(MonitorHMP *hmp, const char *device, const char *target,
                        const char *arg, const char *read_only, bool force,
                        Error **errp);
 void hmp_migrate(MonitorHMP *hmp, const QDict *qdict);
diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 3c0931796ce2..bdbb2aaa99db 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -858,34 +858,33 @@ struct DirtyRateInfo *qmp_query_dirty_rate(bool has_calc_time_unit,
 
 void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyRateInfo *info = query_dirty_rate_info(TIME_UNIT_SECOND);
 
-    monitor_printf(mon, "Status: %s\n",
-                   DirtyRateStatus_str(info->status));
-    monitor_printf(mon, "Start Time: %"PRIi64" (ms)\n",
-                   info->start_time);
+    monitor_hmp_printf(hmp, "Status: %s\n",
+                       DirtyRateStatus_str(info->status));
+    monitor_hmp_printf(hmp, "Start Time: %"PRIi64" (ms)\n",
+                       info->start_time);
     if (info->mode == DIRTY_RATE_MEASURE_MODE_PAGE_SAMPLING) {
-        monitor_printf(mon, "Sample Pages: %"PRIu64" (per GB)\n",
-                       info->sample_pages);
+        monitor_hmp_printf(hmp, "Sample Pages: %"PRIu64" (per GB)\n",
+                           info->sample_pages);
     }
-    monitor_printf(mon, "Period: %"PRIi64" (sec)\n",
-                   info->calc_time);
-    monitor_printf(mon, "Mode: %s\n",
-                   DirtyRateMeasureMode_str(info->mode));
-    monitor_printf(mon, "Dirty rate: ");
+    monitor_hmp_printf(hmp, "Period: %"PRIi64" (sec)\n",
+                       info->calc_time);
+    monitor_hmp_printf(hmp, "Mode: %s\n",
+                       DirtyRateMeasureMode_str(info->mode));
+    monitor_hmp_printf(hmp, "Dirty rate: ");
     if (info->has_dirty_rate) {
-        monitor_printf(mon, "%"PRIi64" (MB/s)\n", info->dirty_rate);
+        monitor_hmp_printf(hmp, "%"PRIi64" (MB/s)\n", info->dirty_rate);
         if (info->has_vcpu_dirty_rate) {
             DirtyRateVcpuList *rate, *head = info->vcpu_dirty_rate;
             for (rate = head; rate != NULL; rate = rate->next) {
-                monitor_printf(mon, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
-                               " (MB/s)\n", rate->value->id,
-                               rate->value->dirty_rate);
+                monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], Dirty rate: %"PRIi64
+                                   " (MB/s)\n", rate->value->id,
+                                   rate->value->dirty_rate);
             }
         }
     } else {
-        monitor_printf(mon, "(not ready)\n");
+        monitor_hmp_printf(hmp, "(not ready)\n");
     }
 
     qapi_free_DirtyRateVcpuList(info->vcpu_dirty_rate);
@@ -894,7 +893,6 @@ void hmp_info_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t sec = qdict_get_try_int(qdict, "second", 0);
     int64_t sample_pages = qdict_get_try_int(qdict, "sample_pages_per_GB", -1);
     bool has_sample_pages = (sample_pages != -1);
@@ -904,13 +902,13 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
     Error *err = NULL;
 
     if (!sec) {
-        monitor_printf(mon, "Incorrect period length specified!\n");
+        monitor_hmp_printf(hmp, "Incorrect period length specified!\n");
         return;
     }
 
     if (dirty_ring && dirty_bitmap) {
-        monitor_printf(mon, "Either dirty ring or dirty bitmap "
-                       "can be specified!\n");
+        monitor_hmp_printf(hmp, "Either dirty ring or dirty bitmap "
+                           "can be specified!\n");
         return;
     }
 
@@ -930,7 +928,7 @@ void hmp_calc_dirty_rate(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Starting dirty rate measurement with period %"PRIi64
-                   " seconds\n", sec);
-    monitor_printf(mon, "[Please use 'info dirty_rate' to check results]\n");
+    monitor_hmp_printf(hmp, "Starting dirty rate measurement with period %"PRIi64
+                       " seconds\n", sec);
+    monitor_hmp_printf(hmp, "[Please use 'info dirty_rate' to check results]\n");
 }
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index a164a59080c5..6fe189471899 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -36,23 +36,23 @@
 #include "options.h"
 #include "migration.h"
 
-static void migration_global_dump(Monitor *mon)
+static void migration_global_dump(MonitorHMP *hmp)
 {
     MigrationState *ms = migrate_get_current();
 
-    monitor_printf(mon, "Globals:\n");
-    monitor_printf(mon, "  store-global-state: %s\n",
-                   ms->store_global_state ? "on" : "off");
-    monitor_printf(mon, "  only-migratable: %s\n",
-                   only_migratable ? "on" : "off");
-    monitor_printf(mon, "  send-configuration: %s\n",
-                   ms->send_configuration ? "on" : "off");
-    monitor_printf(mon, "  send-section-footer: %s\n",
-                   ms->send_section_footer ? "on" : "off");
-    monitor_printf(mon, "  send-switchover-start: %s\n",
-                   ms->send_switchover_start ? "on" : "off");
-    monitor_printf(mon, "  clear-bitmap-shift: %u\n",
-                   ms->clear_bitmap_shift);
+    monitor_hmp_printf(hmp, "Globals:\n");
+    monitor_hmp_printf(hmp, "  store-global-state: %s\n",
+                       ms->store_global_state ? "on" : "off");
+    monitor_hmp_printf(hmp, "  only-migratable: %s\n",
+                       only_migratable ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-configuration: %s\n",
+                       ms->send_configuration ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-section-footer: %s\n",
+                       ms->send_section_footer ? "on" : "off");
+    monitor_hmp_printf(hmp, "  send-switchover-start: %s\n",
+                       ms->send_switchover_start ? "on" : "off");
+    monitor_hmp_printf(hmp, "  clear-bitmap-shift: %u\n",
+                       ms->clear_bitmap_shift);
 }
 
 static const gchar *format_time_str(uint64_t us)
@@ -68,11 +68,11 @@ static const gchar *format_time_str(uint64_t us)
     return g_strdup_printf("%"PRIu64" %s", us, units[index]);
 }
 
-static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
+static void migration_dump_blocktime(MonitorHMP *hmp, MigrationInfo *info)
 {
     if (info->has_postcopy_blocktime) {
-        monitor_printf(mon, "Postcopy Blocktime (ms): %" PRIu32 "\n",
-                       info->postcopy_blocktime);
+        monitor_hmp_printf(hmp, "Postcopy Blocktime (ms): %" PRIu32 "\n",
+                           info->postcopy_blocktime);
     }
 
     if (info->has_postcopy_vcpu_blocktime) {
@@ -80,25 +80,25 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Blocktime (ms):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Blocktime (ms):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu32, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu32, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency) {
-        monitor_printf(mon, "Postcopy Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_latency);
+        monitor_hmp_printf(hmp, "Postcopy Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_latency);
     }
 
     if (info->has_postcopy_non_vcpu_latency) {
-        monitor_printf(mon, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
-                       info->postcopy_non_vcpu_latency);
+        monitor_hmp_printf(hmp, "Postcopy non-vCPU Latency (ns): %" PRIu64 "\n",
+                           info->postcopy_non_vcpu_latency);
     }
 
     if (info->has_postcopy_vcpu_latency) {
@@ -106,29 +106,29 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
         const char *sep = "";
         int count = 0;
 
-        monitor_printf(mon, "Postcopy vCPU Latencies (ns):\n [");
+        monitor_hmp_printf(hmp, "Postcopy vCPU Latencies (ns):\n [");
 
         while (item) {
-            monitor_printf(mon, "%s%"PRIu64, sep, item->value);
+            monitor_hmp_printf(hmp, "%s%"PRIu64, sep, item->value);
             item = item->next;
             /* Each line 10 vcpu results, newline if there's more */
             sep = ((++count % 10 == 0) && item) ? ",\n  " : ", ";
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->has_postcopy_latency_dist) {
         uint64List *item = info->postcopy_latency_dist;
         int count = 0;
 
-        monitor_printf(mon, "Postcopy Latency Distribution:\n");
+        monitor_hmp_printf(hmp, "Postcopy Latency Distribution:\n");
 
         while (item) {
             g_autofree const gchar *from = format_time_str(1UL << count);
             g_autofree const gchar *to = format_time_str(1UL << (count + 1));
 
-            monitor_printf(mon, "  [ %8s - %8s ]: %10"PRIu64"\n",
-                           from, to, item->value);
+            monitor_hmp_printf(hmp, "  [ %8s - %8s ]: %10"PRIu64"\n",
+                               from, to, item->value);
             item = item->next;
             count++;
         }
@@ -137,7 +137,6 @@ static void migration_dump_blocktime(Monitor *mon, MigrationInfo *info)
 
 void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool show_all = qdict_get_try_bool(qdict, "all", false);
     MigrationInfo *info;
 
@@ -145,59 +144,59 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
 
     if (info->blocked_reasons) {
         strList *reasons = info->blocked_reasons;
-        monitor_printf(mon, "Outgoing migration blocked:\n");
+        monitor_hmp_printf(hmp, "Outgoing migration blocked:\n");
         while (reasons) {
-            monitor_printf(mon, "  %s\n", reasons->value);
+            monitor_hmp_printf(hmp, "  %s\n", reasons->value);
             reasons = reasons->next;
         }
     }
 
     if (info->has_status) {
-        monitor_printf(mon, "Status: \t\t%s",
-                       MigrationStatus_str(info->status));
+        monitor_hmp_printf(hmp, "Status: \t\t%s",
+                           MigrationStatus_str(info->status));
         if ((info->status == MIGRATION_STATUS_FAILED ||
              info->status == MIGRATION_STATUS_POSTCOPY_PAUSED) &&
             info->error_desc) {
-            monitor_printf(mon, " (%s)\n", info->error_desc);
+            monitor_hmp_printf(hmp, " (%s)\n", info->error_desc);
         } else {
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
 
         if (info->total_time) {
-            monitor_printf(mon, "Time (ms): \t\ttotal=%" PRIu64,
-                           info->total_time);
+            monitor_hmp_printf(hmp, "Time (ms): \t\ttotal=%" PRIu64,
+                               info->total_time);
             if (info->has_setup_time) {
-                monitor_printf(mon, ", setup=%" PRIu64,
-                               info->setup_time);
+                monitor_hmp_printf(hmp, ", setup=%" PRIu64,
+                                   info->setup_time);
             }
             if (info->has_expected_downtime) {
-                monitor_printf(mon, ", exp_down=%" PRIu64,
-                               info->expected_downtime);
+                monitor_hmp_printf(hmp, ", exp_down=%" PRIu64,
+                                   info->expected_downtime);
             }
             if (info->has_downtime) {
-                monitor_printf(mon, ", down=%" PRIu64,
-                               info->downtime);
+                monitor_hmp_printf(hmp, ", down=%" PRIu64,
+                                   info->downtime);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 
     if (info->has_remaining) {
         g_autofree char *remaining = size_to_str(info->remaining);
-        monitor_printf(mon, "Remaining: \t\t%s\n", remaining);
+        monitor_hmp_printf(hmp, "Remaining: \t\t%s\n", remaining);
     }
 
     if (info->has_socket_address) {
         SocketAddressList *addr;
 
-        monitor_printf(mon, "Sockets: [\n");
+        monitor_hmp_printf(hmp, "Sockets: [\n");
 
         for (addr = info->socket_address; addr; addr = addr->next) {
             char *s = socket_uri(addr->value);
-            monitor_printf(mon, "\t%s\n", s);
+            monitor_hmp_printf(hmp, "\t%s\n", s);
             g_free(s);
         }
-        monitor_printf(mon, "]\n");
+        monitor_hmp_printf(hmp, "]\n");
     }
 
     if (info->ram) {
@@ -209,219 +208,217 @@ void hmp_info_migrate(MonitorHMP *hmp, const QDict *qdict)
         g_autofree char *str_multifd = size_to_str(info->ram->multifd_bytes);
         g_autofree char *str_postcopy = size_to_str(info->ram->postcopy_bytes);
 
-        monitor_printf(mon, "RAM info:\n");
-        monitor_printf(mon, "  Throughput (Mbps): \t%0.2f\n",
-                       info->ram->mbps);
-        monitor_printf(mon, "  Sizes: \t\tpagesize=%s, total=%s\n",
-                       str_psize, str_total);
-        monitor_printf(mon, "  Transfers: \t\ttransferred=%s, remain=%s\n",
-                       str_transferred, str_remaining);
-        monitor_printf(mon, "    Channels: \t\tprecopy=%s, "
-                       "multifd=%s, postcopy=%s",
-                       str_precopy, str_multifd, str_postcopy);
+        monitor_hmp_printf(hmp, "RAM info:\n");
+        monitor_hmp_printf(hmp, "  Throughput (Mbps): \t%0.2f\n",
+                           info->ram->mbps);
+        monitor_hmp_printf(hmp, "  Sizes: \t\tpagesize=%s, total=%s\n",
+                           str_psize, str_total);
+        monitor_hmp_printf(hmp, "  Transfers: \t\ttransferred=%s, remain=%s\n",
+                           str_transferred, str_remaining);
+        monitor_hmp_printf(hmp, "    Channels: \t\tprecopy=%s, "
+                           "multifd=%s, postcopy=%s",
+                           str_precopy, str_multifd, str_postcopy);
 
         if (info->vfio) {
             g_autofree char *str_vfio = size_to_str(info->vfio->transferred);
 
-            monitor_printf(mon, ", vfio=%s", str_vfio);
+            monitor_hmp_printf(hmp, ", vfio=%s", str_vfio);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "    Page Types: \tnormal=%" PRIu64
-                       ", zero=%" PRIu64 "\n",
-                       info->ram->normal, info->ram->duplicate);
-        monitor_printf(mon, "  Page Rates (pps): \ttransfer=%" PRIu64,
-                       info->ram->pages_per_second);
+        monitor_hmp_printf(hmp, "    Page Types: \tnormal=%" PRIu64
+                           ", zero=%" PRIu64 "\n",
+                           info->ram->normal, info->ram->duplicate);
+        monitor_hmp_printf(hmp, "  Page Rates (pps): \ttransfer=%" PRIu64,
+                           info->ram->pages_per_second);
         if (info->ram->dirty_pages_rate) {
-            monitor_printf(mon, ", dirty=%" PRIu64,
-                           info->ram->dirty_pages_rate);
+            monitor_hmp_printf(hmp, ", dirty=%" PRIu64,
+                               info->ram->dirty_pages_rate);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
 
-        monitor_printf(mon, "  Others: \t\tdirty_syncs=%" PRIu64,
-                       info->ram->dirty_sync_count);
+        monitor_hmp_printf(hmp, "  Others: \t\tdirty_syncs=%" PRIu64,
+                           info->ram->dirty_sync_count);
         if (info->ram->postcopy_requests) {
-            monitor_printf(mon, ", postcopy_req=%" PRIu64,
-                           info->ram->postcopy_requests);
+            monitor_hmp_printf(hmp, ", postcopy_req=%" PRIu64,
+                               info->ram->postcopy_requests);
         }
         if (info->ram->downtime_bytes) {
-            monitor_printf(mon, ", downtime_bytes=%" PRIu64,
-                           info->ram->downtime_bytes);
+            monitor_hmp_printf(hmp, ", downtime_bytes=%" PRIu64,
+                               info->ram->downtime_bytes);
         }
         if (info->ram->dirty_sync_missed_zero_copy) {
-            monitor_printf(mon, ", zerocopy_fallbacks=%" PRIu64,
-                           info->ram->dirty_sync_missed_zero_copy);
+            monitor_hmp_printf(hmp, ", zerocopy_fallbacks=%" PRIu64,
+                               info->ram->dirty_sync_missed_zero_copy);
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
     }
 
     if (!show_all) {
         goto out;
     }
 
-    migration_global_dump(mon);
+    migration_global_dump(hmp);
 
     if (info->xbzrle_cache) {
-        monitor_printf(mon, "XBZRLE: size=%" PRIu64
-                       ", transferred=%" PRIu64
-                       ", pages=%" PRIu64
-                       ", miss=%" PRIu64 "\n"
-                       "  miss_rate=%0.2f"
-                       ", encode_rate=%0.2f"
-                       ", overflow=%" PRIu64 "\n",
-                       info->xbzrle_cache->cache_size,
-                       info->xbzrle_cache->bytes,
-                       info->xbzrle_cache->pages,
-                       info->xbzrle_cache->cache_miss,
-                       info->xbzrle_cache->cache_miss_rate,
-                       info->xbzrle_cache->encoding_rate,
-                       info->xbzrle_cache->overflow);
+        monitor_hmp_printf(hmp, "XBZRLE: size=%" PRIu64
+                           ", transferred=%" PRIu64
+                           ", pages=%" PRIu64
+                           ", miss=%" PRIu64 "\n"
+                           "  miss_rate=%0.2f"
+                           ", encode_rate=%0.2f"
+                           ", overflow=%" PRIu64 "\n",
+                           info->xbzrle_cache->cache_size,
+                           info->xbzrle_cache->bytes,
+                           info->xbzrle_cache->pages,
+                           info->xbzrle_cache->cache_miss,
+                           info->xbzrle_cache->cache_miss_rate,
+                           info->xbzrle_cache->encoding_rate,
+                           info->xbzrle_cache->overflow);
     }
 
     if (info->has_cpu_throttle_percentage) {
-        monitor_printf(mon, "CPU Throttle (%%): %" PRIu64 "\n",
-                       info->cpu_throttle_percentage);
+        monitor_hmp_printf(hmp, "CPU Throttle (%%): %" PRIu64 "\n",
+                           info->cpu_throttle_percentage);
     }
 
     if (info->has_dirty_limit_throttle_time_per_round) {
-        monitor_printf(mon, "Dirty-limit Throttle (us): %" PRIu64 "\n",
-                       info->dirty_limit_throttle_time_per_round);
+        monitor_hmp_printf(hmp, "Dirty-limit Throttle (us): %" PRIu64 "\n",
+                           info->dirty_limit_throttle_time_per_round);
     }
 
     if (info->has_dirty_limit_ring_full_time) {
-        monitor_printf(mon, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
-                       info->dirty_limit_ring_full_time);
+        monitor_hmp_printf(hmp, "Dirty-limit Ring Full (us): %" PRIu64 "\n",
+                           info->dirty_limit_ring_full_time);
     }
 
-    migration_dump_blocktime(mon, info);
+    migration_dump_blocktime(hmp, info);
 out:
     qapi_free_MigrationInfo(info);
 }
 
 void hmp_info_migrate_capabilities(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationCapabilityStatusList *caps, *cap;
 
     caps = qmp_query_migrate_capabilities(NULL);
 
     if (caps) {
         for (cap = caps; cap; cap = cap->next) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationCapability_str(cap->value->capability),
-                           cap->value->state ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationCapability_str(cap->value->capability),
+                               cap->value->state ? "on" : "off");
         }
     }
 
     qapi_free_MigrationCapabilityStatusList(caps);
 }
 
-static void monitor_print_cpr_exec_command(Monitor *mon, strList *args)
+static void monitor_print_cpr_exec_command(MonitorHMP *hmp, strList *args)
 {
-    monitor_printf(mon, "%s:",
+    monitor_hmp_printf(hmp, "%s:",
         MigrationParameter_str(MIGRATION_PARAMETER_CPR_EXEC_COMMAND));
 
     while (args) {
-        monitor_printf(mon, " %s", args->value);
+        monitor_hmp_printf(hmp, " %s", args->value);
         args = args->next;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MigrationParameters *params;
     MigrationState *s = migrate_get_current();
 
     params = qmp_query_migrate_parameters(NULL);
 
     if (params) {
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_INITIAL),
             params->announce_initial);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_MAX),
             params->announce_max);
-        monitor_printf(mon, "%s: %" PRIu64 "\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 "\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_ROUNDS),
             params->announce_rounds);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ANNOUNCE_STEP),
             params->announce_step);
         assert(params->has_throttle_trigger_threshold);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_THROTTLE_TRIGGER_THRESHOLD),
             params->throttle_trigger_threshold);
         assert(params->has_cpu_throttle_initial);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INITIAL),
             params->cpu_throttle_initial);
         assert(params->has_cpu_throttle_increment);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_INCREMENT),
             params->cpu_throttle_increment);
         assert(params->has_cpu_throttle_tailslow);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_CPU_THROTTLE_TAILSLOW),
             params->cpu_throttle_tailslow ? "on" : "off");
         assert(params->has_max_cpu_throttle);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_CPU_THROTTLE),
             params->max_cpu_throttle);
         assert(params->tls_creds);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_CREDS),
                        params->tls_creds->u.s);
         assert(params->tls_hostname);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_HOSTNAME),
                        params->tls_hostname->u.s);
         assert(params->tls_authz);
-        monitor_printf(mon, "%s: '%s'\n",
+        monitor_hmp_printf(hmp, "%s: '%s'\n",
             MigrationParameter_str(MIGRATION_PARAMETER_TLS_AUTHZ),
                        params->tls_authz->u.s);
         assert(params->has_max_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_BANDWIDTH),
             params->max_bandwidth);
         assert(params->has_avail_switchover_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_AVAIL_SWITCHOVER_BANDWIDTH),
             params->avail_switchover_bandwidth);
         assert(params->has_max_postcopy_bandwidth);
-        monitor_printf(mon, "%s: %" PRIu64 " bytes/second\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes/second\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MAX_POSTCOPY_BANDWIDTH),
             params->max_postcopy_bandwidth);
         assert(params->has_downtime_limit);
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_DOWNTIME_LIMIT),
             params->downtime_limit);
         assert(params->has_x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u ms\n",
+        monitor_hmp_printf(hmp, "%s: %u ms\n",
             MigrationParameter_str(MIGRATION_PARAMETER_X_CHECKPOINT_DELAY),
             params->x_checkpoint_delay);
-        monitor_printf(mon, "%s: %u\n",
+        monitor_hmp_printf(hmp, "%s: %u\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_CHANNELS),
             params->multifd_channels);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MULTIFD_COMPRESSION),
             MultiFDCompression_str(params->multifd_compression));
         assert(params->has_zero_page_detection);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_ZERO_PAGE_DETECTION),
             qapi_enum_lookup(&ZeroPageDetection_lookup,
                 params->zero_page_detection));
-        monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
             MigrationParameter_str(MIGRATION_PARAMETER_XBZRLE_CACHE_SIZE),
             params->xbzrle_cache_size);
 
         if (s->has_block_bitmap_mapping) {
             const BitmapMigrationNodeAliasList *bmnal;
 
-            monitor_printf(mon, "%s:\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
+            monitor_hmp_printf(hmp, "%s:\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_BLOCK_BITMAP_MAPPING));
 
             for (bmnal = params->block_bitmap_mapping;
                  bmnal;
@@ -430,47 +427,47 @@ void hmp_info_migrate_parameters(MonitorHMP *hmp, const QDict *qdict)
                 const BitmapMigrationNodeAlias *bmna = bmnal->value;
                 const BitmapMigrationBitmapAliasList *bmbal;
 
-                monitor_printf(mon, "  '%s' -> '%s'\n",
-                               bmna->node_name, bmna->alias);
+                monitor_hmp_printf(hmp, "  '%s' -> '%s'\n",
+                                   bmna->node_name, bmna->alias);
 
                 for (bmbal = bmna->bitmaps; bmbal; bmbal = bmbal->next) {
                     const BitmapMigrationBitmapAlias *bmba = bmbal->value;
 
-                    monitor_printf(mon, "    '%s' -> '%s'\n",
-                                   bmba->name, bmba->alias);
+                    monitor_hmp_printf(hmp, "    '%s' -> '%s'\n",
+                                       bmba->name, bmba->alias);
                 }
             }
         }
 
-        monitor_printf(mon, "%s: %" PRIu64 " ms\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " ms\n",
         MigrationParameter_str(MIGRATION_PARAMETER_X_VCPU_DIRTY_LIMIT_PERIOD),
         params->x_vcpu_dirty_limit_period);
 
-        monitor_printf(mon, "%s: %" PRIu64 " MB/s\n",
+        monitor_hmp_printf(hmp, "%s: %" PRIu64 " MB/s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_VCPU_DIRTY_LIMIT),
             params->vcpu_dirty_limit);
 
         assert(params->has_mode);
-        monitor_printf(mon, "%s: %s\n",
+        monitor_hmp_printf(hmp, "%s: %s\n",
             MigrationParameter_str(MIGRATION_PARAMETER_MODE),
             qapi_enum_lookup(&MigMode_lookup, params->mode));
 
         if (params->has_direct_io) {
-            monitor_printf(mon, "%s: %s\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_DIRECT_IO),
-                           params->direct_io ? "on" : "off");
+            monitor_hmp_printf(hmp, "%s: %s\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_DIRECT_IO),
+                               params->direct_io ? "on" : "off");
         }
 
         if (params->has_x_rdma_chunk_size) {
-            monitor_printf(mon, "%s: %" PRIu64 " bytes\n",
-                           MigrationParameter_str(
-                               MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
-                           params->x_rdma_chunk_size);
+            monitor_hmp_printf(hmp, "%s: %" PRIu64 " bytes\n",
+                               MigrationParameter_str(
+                                   MIGRATION_PARAMETER_X_RDMA_CHUNK_SIZE),
+                               params->x_rdma_chunk_size);
         }
 
         assert(params->has_cpr_exec_command);
-        monitor_print_cpr_exec_command(mon, params->cpr_exec_command);
+        monitor_print_cpr_exec_command(hmp, params->cpr_exec_command);
     }
 
     qapi_free_MigrationParameters(params);
@@ -879,8 +876,8 @@ void hmp_migrate(MonitorHMP *hmp, const QDict *qdict)
         HMPMigrationStatus *status;
 
         if (!hmp->use_readline) {
-            monitor_printf(mon, "terminal does not allow synchronous "
-                           "migration, continuing detached\n");
+            monitor_hmp_printf(hmp, "terminal does not allow synchronous "
+                               "migration, continuing detached\n");
             return;
         }
         monitor_suspend(mon);
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 89cc19c2431d..1834e3c1f697 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -105,26 +105,24 @@ strList *hmp_split_at_comma(const char *str)
 
 void hmp_info_name(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     NameInfo *info;
 
     info = qmp_query_name(NULL);
     if (info->name) {
-        monitor_printf(mon, "%s\n", info->name);
+        monitor_hmp_printf(hmp, "%s\n", info->name);
     }
     qapi_free_NameInfo(info);
 }
 
 void hmp_info_version(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VersionInfo *info;
 
     info = qmp_query_version(NULL);
 
-    monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
-                   info->qemu->major, info->qemu->minor, info->qemu->micro,
-                   info->package);
+    monitor_hmp_printf(hmp, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+                       info->qemu->major, info->qemu->minor, info->qemu->micro,
+                       info->package);
 
     qapi_free_VersionInfo(info);
 }
@@ -145,13 +143,12 @@ void hmp_stop(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
 
     if (op == NULL) {
         bool on = qsp_is_enabled();
 
-        monitor_printf(mon, "sync-profile is %s\n", on ? "on" : "off");
+        monitor_hmp_printf(hmp, "sync-profile is %s\n", on ? "on" : "off");
         return;
     }
     if (!strcmp(op, "on")) {
@@ -179,14 +176,13 @@ void hmp_exit_preconfig(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_cpu(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index;
 
     /* XXX: drop the monitor_hmp_set_cpu() usage when all HMP commands that
             use it are converted to the QAPI */
     cpu_index = qdict_get_int(qdict, "index");
     if (monitor_hmp_set_cpu(hmp, cpu_index) < 0) {
-        monitor_printf(mon, "invalid CPU index\n");
+        monitor_hmp_printf(hmp, "invalid CPU index\n");
     }
 }
 
@@ -200,7 +196,6 @@ void hmp_cont(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *device = qdict_get_str(qdict, "device");
     const char *target = qdict_get_str(qdict, "target");
     const char *arg = qdict_get_try_str(qdict, "arg");
@@ -210,11 +205,11 @@ void hmp_change(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
     if (strcmp(device, "vnc") == 0) {
-        hmp_change_vnc(mon, device, target, arg, read_only, force, &err);
+        hmp_change_vnc(hmp, device, target, arg, read_only, force, &err);
     } else
 #endif
     {
-        hmp_change_medium(mon, device, target, arg, read_only, force, &err);
+        hmp_change_medium(hmp, device, target, arg, read_only, force, &err);
     }
 
     hmp_handle_error(hmp, err);
@@ -242,21 +237,20 @@ void hmp_closefd(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     IOThreadInfoList *info_list = qmp_query_iothreads(NULL);
     IOThreadInfoList *info;
     IOThreadInfo *value;
 
     for (info = info_list; info; info = info->next) {
         value = info->value;
-        monitor_printf(mon, "%s:\n", value->id);
-        monitor_printf(mon, "  thread_id=%" PRId64 "\n", value->thread_id);
-        monitor_printf(mon, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
-        monitor_printf(mon, "  poll-grow=%" PRId64 "\n", value->poll_grow);
-        monitor_printf(mon, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
-        monitor_printf(mon, "  poll-weight=%" PRId64 "\n", value->poll_weight);
-        monitor_printf(mon, "  aio-max-batch=%" PRId64 "\n",
-                       value->aio_max_batch);
+        monitor_hmp_printf(hmp, "%s:\n", value->id);
+        monitor_hmp_printf(hmp, "  thread_id=%" PRId64 "\n", value->thread_id);
+        monitor_hmp_printf(hmp, "  poll-max-ns=%" PRId64 "\n", value->poll_max_ns);
+        monitor_hmp_printf(hmp, "  poll-grow=%" PRId64 "\n", value->poll_grow);
+        monitor_hmp_printf(hmp, "  poll-shrink=%" PRId64 "\n", value->poll_shrink);
+        monitor_hmp_printf(hmp, "  poll-weight=%" PRId64 "\n", value->poll_weight);
+        monitor_hmp_printf(hmp, "  aio-max-batch=%" PRId64 "\n",
+                           value->aio_max_batch);
     }
 
     qapi_free_IOThreadInfoList(info_list);
@@ -264,26 +258,23 @@ void hmp_info_iothreads(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, qdict_get_try_str(qdict, "name"));
+    hmp_help_cmd(hmp, qdict_get_try_str(qdict, "name"));
 }
 
 void hmp_clear(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /*
      * Send an ANSI escape sequence:
      * "\x1b[H" - move cursor to top-left
      * "\x1b[2J" - clear visible screen
      * "\x1b[3J" - clear scrollback
      */
-    monitor_printf(mon, "\x1b[H\x1b[2J\x1b[3J");
+    monitor_hmp_printf(hmp, "\x1b[H\x1b[2J\x1b[3J");
 }
 
 void hmp_info_help(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    hmp_help_cmd(mon, "info");
+    hmp_help_cmd(hmp, "info");
 }
 
 void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
@@ -299,7 +290,6 @@ void hmp_info_sync_profile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int i;
     const char *str;
 
@@ -312,7 +302,7 @@ void hmp_info_history(MonitorHMP *hmp, const QDict *qdict)
         if (!str) {
             break;
         }
-        monitor_printf(mon, "%d: '%s'\n", i, str);
+        monitor_hmp_printf(hmp, "%d: '%s'\n", i, str);
         i++;
     }
 }
@@ -328,7 +318,6 @@ void hmp_logfile(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int mask;
     const char *items = qdict_get_str(qdict, "items");
     Error *err = NULL;
@@ -338,7 +327,7 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
     } else {
         mask = qemu_str_to_log_mask(items);
         if (!mask) {
-            hmp_help_cmd(mon, "log");
+            hmp_help_cmd(hmp, "log");
             return;
         }
     }
@@ -350,7 +339,6 @@ void hmp_log(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     const char *device = qdict_get_try_str(qdict, "device");
 
@@ -361,43 +349,41 @@ void hmp_gdbserver(MonitorHMP *hmp, const QDict *qdict)
     if (!gdbserver_start(device, &err)) {
         error_report_err(err);
     } else if (strcmp(device, "none") == 0) {
-        monitor_printf(mon, "Disabled gdbserver\n");
+        monitor_hmp_printf(hmp, "Disabled gdbserver\n");
     } else {
-        monitor_printf(mon, "Waiting for gdb connection on device '%s'\n",
-                       device);
+        monitor_hmp_printf(hmp, "Waiting for gdb connection on device '%s'\n",
+                           device);
     }
 }
 
 void hmp_print(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int format = qdict_get_int(qdict, "format");
     hwaddr val = qdict_get_int(qdict, "val");
 
     switch(format) {
     case 'o':
-        monitor_printf(mon, "%#" HWADDR_PRIo, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIo, val);
         break;
     case 'x':
-        monitor_printf(mon, "%#" HWADDR_PRIx, val);
+        monitor_hmp_printf(hmp, "0x%" HWADDR_PRIx, val);
         break;
     case 'u':
-        monitor_printf(mon, "%" HWADDR_PRIu, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRIu, val);
         break;
     default:
     case 'd':
-        monitor_printf(mon, "%" HWADDR_PRId, val);
+        monitor_hmp_printf(hmp, "%" HWADDR_PRId, val);
         break;
     case 'c':
-        monitor_printc(mon, val);
+        monitor_hmp_printc(hmp, val);
         break;
     }
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 }
 
 void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     uint32_t addr;
     uint16_t sum;
     uint32_t start = qdict_get_int(qdict, "start");
@@ -411,12 +397,11 @@ void hmp_sum(MonitorHMP *hmp, const QDict *qdict)
         sum = (sum >> 1) | (sum << 15);
         sum += val;
     }
-    monitor_printf(mon, "%05d\n", sum);
+    monitor_hmp_printf(hmp, "%05d\n", sum);
 }
 
 void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int size = qdict_get_int(qdict, "size");
     int addr = qdict_get_int(qdict, "addr");
     int has_index = qdict_haskey(qdict, "index");
@@ -445,8 +430,8 @@ void hmp_ioport_read(MonitorHMP *hmp, const QDict *qdict)
         suffix = 'l';
         break;
     }
-    monitor_printf(mon, "port%c[0x%04x] = 0x%0*x\n",
-                   suffix, addr, size * 2, val);
+    monitor_hmp_printf(hmp, "port%c[0x%04x] = 0x%0*x\n",
+                       suffix, addr, size * 2, val);
 }
 
 void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
@@ -473,7 +458,6 @@ void hmp_ioport_write(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *local_err = NULL;
     const char *bootdevice = qdict_get_str(qdict, "bootdevice");
 
@@ -481,7 +465,7 @@ void hmp_boot_set(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "boot device list now set to %s\n", bootdevice);
+        monitor_hmp_printf(hmp, "boot device list now set to %s\n", bootdevice);
     }
 }
 
@@ -507,7 +491,7 @@ void hmp_dumpdtb(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(MONITOR(hmp), "DTB dumped to '%s'\n", filename);
+    monitor_hmp_printf(hmp, "DTB dumped to '%s'\n", filename);
 }
 #endif
 
@@ -573,14 +557,13 @@ int monitor_hmp_get_cpu_index(MonitorHMP *hmp)
 
 void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool all_cpus = qdict_get_try_bool(qdict, "cpustate_all", false);
     int vcpu = qdict_get_try_int(qdict, "vcpu", -1);
     CPUState *cs;
 
     if (all_cpus) {
         CPU_FOREACH(cs) {
-            monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+            monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
             cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
         }
     } else {
@@ -588,14 +571,14 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 
         if (!cs) {
             if (vcpu >= 0) {
-                monitor_printf(mon, "CPU#%d not available\n", vcpu);
+                monitor_hmp_printf(hmp, "CPU#%d not available\n", vcpu);
             } else {
-                monitor_printf(mon, "No CPU available\n");
+                monitor_hmp_printf(hmp, "No CPU available\n");
             }
             return;
         }
 
-        monitor_printf(mon, "\nCPU#%d\n", cs->cpu_index);
+        monitor_hmp_printf(hmp, "\nCPU#%d\n", cs->cpu_index);
         cpu_dump_state(cs, NULL, CPU_DUMP_FPU | CPU_DUMP_VPU);
     }
 }
@@ -603,7 +586,6 @@ void hmp_info_registers(MonitorHMP *hmp, const QDict *qdict)
 static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                         uint64_t addr, bool is_physical)
 {
-    Monitor *mon = MONITOR(hmp);
     int l, line_size, i, max_digits, len;
     uint8_t buf[16];
     uint64_t v;
@@ -612,12 +594,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     const bool big_endian = target_big_endian();
 
     if (!cs && (format == 'i' || !is_physical)) {
-        monitor_printf(mon, "Can not dump without CPU\n");
+        monitor_hmp_printf(hmp, "Can not dump without CPU\n");
         return;
     }
 
     if (format == 'i') {
-        monitor_disas(mon, cs, addr, count, is_physical);
+        monitor_disas(hmp, cs, addr, count, is_physical);
         return;
     }
 
@@ -647,7 +629,7 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
     }
 
     while (len > 0) {
-        monitor_printf(mon, "%0*" PRIx64 ":", addr_width, addr);
+        monitor_hmp_printf(hmp, "%0*" PRIx64 ":", addr_width, addr);
         l = len;
         if (l > line_size) {
             l = line_size;
@@ -657,12 +639,12 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
             MemTxResult r = address_space_read(as, addr,
                                                MEMTXATTRS_UNSPECIFIED, buf, l);
             if (r != MEMTX_OK) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         } else {
             if (cpu_memory_rw_debug(cs, addr, buf, l, 0) < 0) {
-                monitor_printf(mon, " Cannot access memory\n");
+                monitor_hmp_printf(hmp, " Cannot access memory\n");
                 break;
             }
         }
@@ -683,27 +665,27 @@ static void memory_dump(MonitorHMP *hmp, int count, int format, int wsize,
                 v = (big_endian ? ldq_be_p : ldq_le_p)(buf + i);
                 break;
             }
-            monitor_printf(mon, " ");
+            monitor_hmp_printf(hmp, " ");
             switch (format) {
             case 'o':
-                monitor_printf(mon, "0%*" PRIo64, max_digits, v);
+                monitor_hmp_printf(hmp, "0%*" PRIo64, max_digits, v);
                 break;
             case 'x':
-                monitor_printf(mon, "0x%0*" PRIx64, max_digits, v);
+                monitor_hmp_printf(hmp, "0x%0*" PRIx64, max_digits, v);
                 break;
             case 'u':
-                monitor_printf(mon, "%*" PRIu64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRIu64, max_digits, v);
                 break;
             case 'd':
-                monitor_printf(mon, "%*" PRId64, max_digits, v);
+                monitor_hmp_printf(hmp, "%*" PRId64, max_digits, v);
                 break;
             case 'c':
-                monitor_printc(mon, v);
+                monitor_hmp_printc(hmp, v);
                 break;
             }
             i += wsize;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         addr += l;
         len -= l;
     }
@@ -731,7 +713,6 @@ void hmp_physical_memory_dump(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -743,29 +724,28 @@ void hmp_gpa2hva(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "Host virtual address for 0x%" HWADDR_PRIx
-                   " (%s) is %p\n",
-                   addr, mr->name, ptr);
+    monitor_hmp_printf(hmp, "Host virtual address for 0x%" HWADDR_PRIx
+                       " (%s) is %p\n",
+                       addr, mr->name, ptr);
 
     memory_region_unref(mr);
 }
 
 void hmp_gva2gpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     vaddr addr = qdict_get_int(qdict, "addr");
     CPUState *cs = monitor_hmp_get_cpu(hmp);
     TranslateForDebugResult tres;
 
     if (!cs) {
-        monitor_printf(mon, "No cpu\n");
+        monitor_hmp_printf(hmp, "No cpu\n");
         return;
     }
 
     if (!cpu_translate_for_debug(cs, addr, &tres)) {
-        monitor_printf(mon, "Unmapped\n");
+        monitor_hmp_printf(hmp, "Unmapped\n");
     } else {
-        monitor_printf(mon, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
+        monitor_hmp_printf(hmp, "gpa: 0x%" HWADDR_PRIx "\n", tres.physaddr);
     }
 }
 
@@ -806,7 +786,6 @@ out:
 
 void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     hwaddr addr = qdict_get_int(qdict, "addr");
     Error *local_err = NULL;
     MemoryRegion *mr = NULL;
@@ -823,9 +802,9 @@ void hmp_gpa2hpa(MonitorHMP *hmp, const QDict *qdict)
     if (local_err) {
         error_report_err(local_err);
     } else {
-        monitor_printf(mon, "Host physical address for 0x%" HWADDR_PRIx
-                       " (%s) is 0x%" PRIx64 "\n",
-                       addr, mr->name, (uint64_t) physaddr);
+        monitor_hmp_printf(hmp, "Host physical address for 0x%" HWADDR_PRIx
+                           " (%s) is 0x%" PRIx64 "\n",
+                           addr, mr->name, (uint64_t) physaddr);
     }
 
     memory_region_unref(mr);
diff --git a/monitor/hmp.c b/monitor/hmp.c
index 2484a2310dff..e5f8b9c576e0 100644
--- a/monitor/hmp.c
+++ b/monitor/hmp.c
@@ -80,8 +80,6 @@ static void monitor_hmp_set_readline(Object *obj, bool val, Error **errp)
     hmp->use_readline = val;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-    G_GNUC_PRINTF(2, 0);
 static void monitor_hmp_accept_input(Monitor *mon);
 static void monitor_hmp_complete(UserCreatable *uc, Error **errp);
 static bool monitor_hmp_prepare_delete(UserCreatable *uc, Error **errp);
@@ -95,7 +93,6 @@ static void monitor_hmp_class_init(ObjectClass *cls, const void *data)
                                    monitor_hmp_get_readline,
                                    monitor_hmp_set_readline);
 
-    moncls->vprintf = monitor_hmp_vprintf;
     moncls->accept_input = monitor_hmp_accept_input;
 
     ucc->complete = monitor_hmp_complete;
@@ -114,12 +111,6 @@ static void monitor_hmp_init(Object *obj)
     hmp->use_readline = true;
 }
 
-int monitor_hmp_vprintf(Monitor *mon, const char *fmt, va_list ap)
-{
-    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
-    return monitor_puts(mon, buf);
-}
-
 static void monitor_hmp_accept_input(Monitor *mon)
 {
     qemu_mutex_lock(&mon->mon_lock);
@@ -166,8 +157,7 @@ int monitor_hmp_read_password(MonitorHMP *hmp, ReadLineFunc *readline_func,
         /* prompt is printed on return from the command handler */
         return 0;
     } else {
-        monitor_printf(&hmp->parent_obj,
-                       "terminal does not support password prompting\n");
+        monitor_hmp_printf(hmp, "terminal does not support password prompting\n");
         return -ENOTTY;
     }
 }
@@ -319,7 +309,7 @@ static bool cmd_available(const HMPCommand *cmd)
     return phase_check(PHASE_MACHINE_READY) || cmd_can_preconfig(cmd);
 }
 
-static void help_cmd_dump_one(Monitor *mon,
+static void help_cmd_dump_one(MonitorHMP *mon,
                               const HMPCommand *cmd,
                               char **prefix_args,
                               int prefix_args_nb)
@@ -331,13 +321,13 @@ static void help_cmd_dump_one(Monitor *mon,
     }
 
     for (i = 0; i < prefix_args_nb; i++) {
-        monitor_printf(mon, "%s ", prefix_args[i]);
+        monitor_hmp_printf(mon, "%s ", prefix_args[i]);
     }
-    monitor_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
+    monitor_hmp_printf(mon, "%s %s -- %s\n", cmd->name, cmd->params, cmd->help);
 }
 
 /* @args[@arg_index] is the valid command need to find in @cmds */
-static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
+static void help_cmd_dump(MonitorHMP *mon, const HMPCommand *cmds,
                           char **args, int nb_args, int arg_index)
 {
     const HMPCommand *cmd;
@@ -367,13 +357,13 @@ static void help_cmd_dump(Monitor *mon, const HMPCommand *cmds,
     }
 
     /* Command not found */
-    monitor_printf(mon, "unknown command: '");
+    monitor_hmp_printf(mon, "unknown command: '");
     for (i = 0; i <= arg_index; i++) {
-        monitor_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
+        monitor_hmp_printf(mon, "%s%s", args[i], i == arg_index ? "'\n" : " ");
     }
 }
 
-void hmp_help_cmd(Monitor *mon, const char *name)
+void hmp_help_cmd(MonitorHMP *mon, const char *name)
 {
     char *args[MAX_ARGS];
     int nb_args = 0;
@@ -383,15 +373,15 @@ void hmp_help_cmd(Monitor *mon, const char *name)
         /* special case for log, directly dump and return */
         if (!strcmp(name, "log")) {
             const QEMULogItem *item;
-            monitor_printf(mon, "Log items (comma separated):\n");
-            monitor_printf(mon, "%-15s %s\n", "none", "remove all logs");
+            monitor_hmp_printf(mon, "Log items (comma separated):\n");
+            monitor_hmp_printf(mon, "%-15s %s\n", "none", "remove all logs");
             for (item = qemu_log_items; item->mask != 0; item++) {
-                monitor_printf(mon, "%-15s %s\n", item->name, item->help);
+                monitor_hmp_printf(mon, "%-15s %s\n", item->name, item->help);
             }
 #ifdef CONFIG_TRACE_LOG
-            monitor_printf(mon, "trace:PATTERN   enable trace events\n");
-            monitor_printf(mon, "\nUse \"log trace:help\" to get a list of "
-                           "trace events.\n\n");
+            monitor_hmp_printf(mon, "trace:PATTERN   enable trace events\n");
+            monitor_hmp_printf(mon, "\nUse \"log trace:help\" to get a list of "
+                               "trace events.\n\n");
 #endif
             return;
         }
@@ -455,12 +445,12 @@ static sigjmp_buf expr_env;
 static int get_monitor_def(MonitorHMP *mon, int64_t *pval, const char *name);
 
 static G_NORETURN G_GNUC_PRINTF(2, 3)
-void expr_error(Monitor *mon, const char *fmt, ...)
+void expr_error(MonitorHMP *mon, const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(mon, fmt, ap);
-    monitor_printf(mon, "\n");
+    monitor_hmp_vprintf(mon, fmt, ap);
+    monitor_hmp_printf(mon, "\n");
     va_end(ap);
     siglongjmp(expr_env, 1);
 }
@@ -475,9 +465,9 @@ static void next(void)
     }
 }
 
-static int64_t expr_sum(Monitor *mon);
+static int64_t expr_sum(MonitorHMP *mon);
 
-static int64_t expr_unary(Monitor *mon)
+static int64_t expr_unary(MonitorHMP *mon)
 {
     int64_t n;
     char *p;
@@ -535,8 +525,8 @@ static int64_t expr_unary(Monitor *mon)
                 pch++;
             }
             *q = 0;
-            if (!gdb_get_register(MONITOR_HMP(mon), &reg, buf)
-                && get_monitor_def(MONITOR_HMP(mon), &reg, buf) < 0) {
+            if (!gdb_get_register(mon, &reg, buf)
+                && get_monitor_def(mon, &reg, buf) < 0) {
                 expr_error(mon, "unknown register");
             }
             n = reg;
@@ -564,7 +554,7 @@ static int64_t expr_unary(Monitor *mon)
     return n;
 }
 
-static int64_t expr_prod(Monitor *mon)
+static int64_t expr_prod(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -598,7 +588,7 @@ static int64_t expr_prod(Monitor *mon)
     return val;
 }
 
-static int64_t expr_logic(Monitor *mon)
+static int64_t expr_logic(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -627,7 +617,7 @@ static int64_t expr_logic(Monitor *mon)
     return val;
 }
 
-static int64_t expr_sum(Monitor *mon)
+static int64_t expr_sum(MonitorHMP *mon)
 {
     int64_t val, val2;
     int op;
@@ -649,7 +639,7 @@ static int64_t expr_sum(Monitor *mon)
     return val;
 }
 
-static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
+static int get_expr(MonitorHMP *mon, int64_t *pval, const char **pp)
 {
     pch = *pp;
     if (sigsetjmp(expr_env, 0)) {
@@ -664,7 +654,7 @@ static int get_expr(Monitor *mon, int64_t *pval, const char **pp)
     return 0;
 }
 
-static int get_double(Monitor *mon, double *pval, const char **pp)
+static int get_double(MonitorHMP *mon, double *pval, const char **pp)
 {
     const char *p = *pp;
     char *tailp;
@@ -672,12 +662,12 @@ static int get_double(Monitor *mon, double *pval, const char **pp)
 
     d = strtod(p, &tailp);
     if (tailp == p) {
-        monitor_printf(mon, "Number expected\n");
+        monitor_hmp_printf(mon, "Number expected\n");
         return -1;
     }
     if (d != d || d - d != 0) {
         /* NaN or infinity */
-        monitor_printf(mon, "Bad number\n");
+        monitor_hmp_printf(mon, "Bad number\n");
         return -1;
     }
     *pval = d;
@@ -788,7 +778,6 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
                                                const char **cmdp,
                                                HMPCommand *table)
 {
-    Monitor *mon = &hmp->parent_obj;
     const char *p;
     const HMPCommand *cmd;
     char cmdname[256];
@@ -801,14 +790,14 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
 
     cmd = search_dispatch_table(table, cmdname);
     if (!cmd) {
-        monitor_printf(mon, "unknown command: '%.*s'\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "unknown command: '%.*s'\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
     if (!cmd_available(cmd)) {
-        monitor_printf(mon, "Command '%.*s' not available "
-                            "until machine initialization has completed.\n",
-                       (int)(p - cmdp_start), cmdp_start);
+        monitor_hmp_printf(hmp, "Command '%.*s' not available "
+                           "until machine initialization has completed.\n",
+                           (int)(p - cmdp_start), cmdp_start);
         return NULL;
     }
 
@@ -832,7 +821,7 @@ static const HMPCommand *monitor_parse_command(MonitorHMP *hmp,
  * Else, insert command arguments into a QDict, and return it.
  * Note: On success, caller has to free the QDict structure.
  */
-static QDict *monitor_parse_arguments(Monitor *mon,
+static QDict *monitor_parse_arguments(MonitorHMP *mon,
                                       const char **endp,
                                       const HMPCommand *cmd)
 {
@@ -873,15 +862,15 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 if (ret < 0) {
                     switch (c) {
                     case 'F':
-                        monitor_printf(mon, "%s: filename expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: filename expected\n",
+                                           cmd->name);
                         break;
                     case 'B':
-                        monitor_printf(mon, "%s: block device name expected\n",
-                                       cmd->name);
+                        monitor_hmp_printf(mon, "%s: block device name expected\n",
+                                           cmd->name);
                         break;
                     default:
-                        monitor_printf(mon, "%s: string expected\n", cmd->name);
+                        monitor_hmp_printf(mon, "%s: string expected\n", cmd->name);
                         break;
                     }
                     goto fail;
@@ -968,8 +957,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 next:
                     if (*p != '\0' && !qemu_isspace(*p)) {
-                        monitor_printf(mon, "invalid char in format: '%c'\n",
-                                       *p);
+                        monitor_hmp_printf(mon, "invalid char in format: '%c'\n",
+                                           *p);
                         goto fail;
                     }
                     if (format < 0) {
@@ -1030,12 +1019,12 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 /* Check if 'i' is greater than 32-bit */
                 if ((c == 'i') && ((val >> 32) & 0xffffffff)) {
-                    monitor_printf(mon, "\'%s\' has failed: ", cmd->name);
-                    monitor_printf(mon, "integer is for 32-bit values\n");
+                    monitor_hmp_printf(mon, "\'%s\' has failed: ", cmd->name);
+                    monitor_hmp_printf(mon, "integer is for 32-bit values\n");
                     goto fail;
                 } else if (c == 'M') {
                     if (val < 0) {
-                        monitor_printf(mon, "enter a positive value\n");
+                        monitor_hmp_printf(mon, "enter a positive value\n");
                         goto fail;
                     }
                     val *= MiB;
@@ -1060,7 +1049,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 ret = qemu_strtosz_MiB(p, &end, &val);
                 if (ret < 0 || val > INT64_MAX) {
-                    monitor_printf(mon, "invalid size\n");
+                    monitor_hmp_printf(mon, "invalid size\n");
                     goto fail;
                 }
                 qdict_put_int(qdict, key, val);
@@ -1094,7 +1083,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     }
                 }
                 if (*p && !qemu_isspace(*p)) {
-                    monitor_printf(mon, "Unknown unit suffix\n");
+                    monitor_hmp_printf(mon, "Unknown unit suffix\n");
                     goto fail;
                 }
                 qdict_put(qdict, key, qnum_from_double(val));
@@ -1117,7 +1106,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 } else if (p - beg == 3 && !memcmp(beg, "off", p - beg)) {
                     val = false;
                 } else {
-                    monitor_printf(mon, "Expected 'on' or 'off'\n");
+                    monitor_hmp_printf(mon, "Expected 'on' or 'off'\n");
                     goto fail;
                 }
                 qdict_put_bool(qdict, key, val);
@@ -1141,8 +1130,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                     p++;
                     if (c != *p) {
                         if (!is_valid_option(p, typestr)) {
-                            monitor_printf(mon, "%s: unsupported option -%c\n",
-                                           cmd->name, *p);
+                            monitor_hmp_printf(mon, "%s: unsupported option -%c\n",
+                                               cmd->name, *p);
                             goto fail;
                         } else {
                             skip_key = 1;
@@ -1159,8 +1148,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                         }
                         ret = get_str(buf, sizeof(buf), &p);
                         if (ret < 0) {
-                            monitor_printf(mon, "%s: value expected for -%c\n",
-                                           cmd->name, *tmp);
+                            monitor_hmp_printf(mon, "%s: value expected for -%c\n",
+                                               cmd->name, *tmp);
                             goto fail;
                         }
                         qdict_put_str(qdict, key, buf);
@@ -1191,8 +1180,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
                 }
                 len = strlen(p);
                 if (len <= 0) {
-                    monitor_printf(mon, "%s: string expected\n",
-                                   cmd->name);
+                    monitor_hmp_printf(mon, "%s: string expected\n",
+                                       cmd->name);
                     goto fail;
                 }
                 qdict_put_str(qdict, key, p);
@@ -1201,7 +1190,7 @@ static QDict *monitor_parse_arguments(Monitor *mon,
             break;
         default:
         bad_type:
-            monitor_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
+            monitor_hmp_printf(mon, "%s: unknown type '%c'\n", cmd->name, c);
             goto fail;
         }
         g_free(key);
@@ -1212,8 +1201,8 @@ static QDict *monitor_parse_arguments(Monitor *mon,
         p++;
     }
     if (*p != '\0') {
-        monitor_printf(mon, "%s: extraneous characters at the end of line\n",
-                       cmd->name);
+        monitor_hmp_printf(mon, "%s: extraneous characters at the end of line\n",
+                           cmd->name);
         goto fail;
     }
 
@@ -1281,19 +1270,19 @@ void handle_hmp_command(MonitorHMP *hmp, const char *cmdline)
 
     if (!cmd->cmd && !cmd->cmd_info_hrt) {
         /* FIXME: is it useful to try autoload modules here ??? */
-        monitor_printf(&hmp->parent_obj, "Command \"%.*s\" is not available.\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp, "Command \"%.*s\" is not available.\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
-    qdict = monitor_parse_arguments(&hmp->parent_obj, &cmdline, cmd);
+    qdict = monitor_parse_arguments(hmp, &cmdline, cmd);
     if (!qdict) {
         while (cmdline > cmd_start && qemu_isspace(cmdline[-1])) {
             cmdline--;
         }
-        monitor_printf(&hmp->parent_obj,
-                       "Try \"help %.*s\" for more information\n",
-                       (int)(cmdline - cmd_start), cmd_start);
+        monitor_hmp_printf(hmp,
+                           "Try \"help %.*s\" for more information\n",
+                           (int)(cmdline - cmd_start), cmd_start);
         return;
     }
 
@@ -1539,7 +1528,7 @@ static void monitor_read(void *opaque, const uint8_t *buf, int size)
         }
     } else {
         if (size == 0 || buf[size - 1] != 0) {
-            monitor_printf(&hmp->parent_obj, "corrupted command\n");
+            monitor_hmp_printf(hmp, "corrupted command\n");
         } else {
             handle_hmp_command(hmp, (char *)buf);
         }
@@ -1580,8 +1569,8 @@ static void monitor_event(void *opaque, QEMUChrEvent event)
         break;
 
     case CHR_EVENT_OPENED:
-        monitor_printf(mon, "QEMU %s monitor - type 'help' for more "
-                       "information\n", QEMU_VERSION);
+        monitor_hmp_printf(hmp, "QEMU %s monitor - type 'help' for more "
+                           "information\n", QEMU_VERSION);
         qemu_mutex_lock(&mon->mon_lock);
         hmp->reset_seen = 1;
         if (!mon->mux_out && hmp->use_readline) {
@@ -1613,7 +1602,7 @@ static void G_GNUC_PRINTF(2, 3) monitor_readline_printf(void *opaque,
     MonitorHMP *hmp = opaque;
     va_list ap;
     va_start(ap, fmt);
-    monitor_vprintf(&hmp->parent_obj, fmt, ap);
+    monitor_hmp_vprintf(hmp, fmt, ap);
     va_end(ap);
 }
 
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index afdda1386080..c198c12eaa00 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -108,12 +108,6 @@ typedef struct HMPCommand {
 struct MonitorClass {
     ObjectClass parent_class;
 
-    /*
-     * If non-NULL, the monitor is able to print messages
-     * for attention of the client user
-     */
-    int (*vprintf)(Monitor *mon, const char *fmt, va_list ap)
-        G_GNUC_PRINTF(2, 0);
     /*
      * If non-NULL, the monitor is able to send event
      * notifications back to the client
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 8528af6f79b8..da76e6e4ac19 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -272,58 +272,53 @@ int monitor_puts(Monitor *mon, const char *str)
     return monitor_puts_locked(mon, str);
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
-    MonitorClass *moncls;
+    g_autofree char *buf = g_strdup_vprintf(fmt, ap);
 
     if (!mon) {
         return -1;
     }
 
-    moncls = MONITOR_GET_CLASS(mon);
-    if (!moncls->vprintf) {
-        return -1;
-    }
-
-    return moncls->vprintf(mon, fmt, ap);
+    return monitor_puts(MONITOR(mon), buf);
 }
 
-int monitor_printf(Monitor *mon, const char *fmt, ...)
+int monitor_hmp_printf(MonitorHMP *mon, const char *fmt, ...)
 {
     int ret;
 
     va_list ap;
     va_start(ap, fmt);
-    ret = monitor_vprintf(mon, fmt, ap);
+    ret = monitor_hmp_vprintf(mon, fmt, ap);
     va_end(ap);
     return ret;
 }
 
-void monitor_printc(Monitor *mon, int c)
+void monitor_hmp_printc(MonitorHMP *mon, int c)
 {
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
     switch(c) {
     case '\'':
-        monitor_printf(mon, "\\'");
+        monitor_hmp_printf(mon, "\\'");
         break;
     case '\\':
-        monitor_printf(mon, "\\\\");
+        monitor_hmp_printf(mon, "\\\\");
         break;
     case '\n':
-        monitor_printf(mon, "\\n");
+        monitor_hmp_printf(mon, "\\n");
         break;
     case '\r':
-        monitor_printf(mon, "\\r");
+        monitor_hmp_printf(mon, "\\r");
         break;
     default:
         if (c >= 32 && c <= 126) {
-            monitor_printf(mon, "%c", c);
+            monitor_hmp_printf(mon, "%c", c);
         } else {
-            monitor_printf(mon, "\\x%02x", c);
+            monitor_hmp_printf(mon, "\\x%02x", c);
         }
         break;
     }
-    monitor_printf(mon, "'");
+    monitor_hmp_printf(mon, "'");
 }
 
 static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
diff --git a/net/net-hmp-cmds.c b/net/net-hmp-cmds.c
index 5b1c678f5d89..0d718d78aef9 100644
--- a/net/net-hmp-cmds.c
+++ b/net/net-hmp-cmds.c
@@ -28,26 +28,25 @@
 #include "qemu/help_option.h"
 #include "qemu/option.h"
 
-static void hmp_print_client_info(Monitor *mon, NetworkClientInfo *ci)
+static void hmp_print_client_info(MonitorHMP *hmp, NetworkClientInfo *ci)
 {
     NetFilterInfoList *f;
 
-    monitor_printf(mon, "%s: index=%" PRIu32 ",type=%s,%s\n",
-                   ci->name, ci->queue_index,
-                   NetClientDriver_str(ci->type), ci->info_str);
+    monitor_hmp_printf(hmp, "%s: index=%" PRIu32 ",type=%s,%s\n",
+                       ci->name, ci->queue_index,
+                       NetClientDriver_str(ci->type), ci->info_str);
     if (ci->filters) {
-        monitor_printf(mon, "filters:\n");
+        monitor_hmp_printf(hmp, "filters:\n");
         for (f = ci->filters; f; f = f->next) {
-            monitor_printf(mon, "  - %s: type=%s%s%s\n",
-                           f->value->name, f->value->type,
-                           f->value->info[0] ? "," : "", f->value->info);
+            monitor_hmp_printf(hmp, "  - %s: type=%s%s%s\n",
+                               f->value->name, f->value->type,
+                               f->value->info[0] ? "," : "", f->value->info);
         }
     }
 }
 
 void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     Error *err = NULL;
     g_autoptr(NetworkInfo) info = qmp_x_query_network(&err);
     NetHubInfoList *h;
@@ -60,13 +59,13 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
     for (h = info->hubs; h; h = h->next) {
         NetHubPortInfoList *p;
 
-        monitor_printf(mon, "hub %d\n", (int)h->value->id);
+        monitor_hmp_printf(hmp, "hub %d\n", (int)h->value->id);
         for (p = h->value->ports; p; p = p->next) {
             if (p->value->peer) {
-                monitor_printf(mon, " \\ %s: ", p->value->name);
-                hmp_print_client_info(mon, p->value->peer);
+                monitor_hmp_printf(hmp, " \\ %s: ", p->value->name);
+                hmp_print_client_info(hmp, p->value->peer);
             } else {
-                monitor_printf(mon, " \\ %s\n", p->value->name);
+                monitor_hmp_printf(hmp, " \\ %s\n", p->value->name);
             }
         }
     }
@@ -75,11 +74,11 @@ void hmp_info_network(MonitorHMP *hmp, const QDict *qdict)
         NetworkClientInfo *ci = entry->value;
 
         if (!ci->peer || ci->type == NET_CLIENT_DRIVER_NIC) {
-            hmp_print_client_info(mon, ci);
+            hmp_print_client_info(hmp, ci);
         } /* else it's a netdev connected to a NIC, printed with the NIC */
         if (ci->peer && ci->type == NET_CLIENT_DRIVER_NIC) {
-            monitor_printf(mon, " \\ ");
-            hmp_print_client_info(mon, ci->peer);
+            monitor_hmp_printf(hmp, " \\ ");
+            hmp_print_client_info(hmp, ci->peer);
         }
     }
 }
diff --git a/net/slirp.c b/net/slirp.c
index d5c190b48b76..6fbefa9ed1d7 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -711,22 +711,22 @@ error:
     return -1;
 }
 
-static SlirpState *slirp_lookup(Monitor *mon, const char *id)
+static SlirpState *slirp_lookup(MonitorHMP *hmp, const char *id)
 {
     if (id) {
         NetClientState *nc = qemu_find_netdev(id);
         if (!nc) {
-            monitor_printf(mon, "unrecognized netdev id '%s'\n", id);
+            monitor_hmp_printf(hmp, "unrecognized netdev id '%s'\n", id);
             return NULL;
         }
         if (strcmp(nc->model, "user")) {
-            monitor_printf(mon, "invalid device specified\n");
+            monitor_hmp_printf(hmp, "invalid device specified\n");
             return NULL;
         }
         return DO_UPCAST(SlirpState, nc, nc);
     } else {
         if (QTAILQ_EMPTY(&slirp_stacks)) {
-            monitor_printf(mon, "user mode network stack not in use\n");
+            monitor_hmp_printf(hmp, "user mode network stack not in use\n");
             return NULL;
         }
         return QTAILQ_FIRST(&slirp_stacks);
@@ -735,7 +735,6 @@ static SlirpState *slirp_lookup(Monitor *mon, const char *id)
 
 void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     /* TODO: support removing unix fwd */
     struct sockaddr_in host_addr = {
         .sin_family = AF_INET,
@@ -753,10 +752,10 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         src_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         src_str = arg1;
     }
     if (!s) {
@@ -795,12 +794,12 @@ void hmp_hostfwd_remove(MonitorHMP *hmp, const QDict *qdict)
     err = slirp_remove_hostfwd(s->slirp, is_udp, host_addr.sin_addr, host_port);
 #endif
 
-    monitor_printf(mon, "host forwarding rule for %s %s\n", src_str,
-                   err ? "not found" : "removed");
+    monitor_hmp_printf(hmp, "host forwarding rule for %s %s\n", src_str,
+                       err ? "not found" : "removed");
     return;
 
  fail_syntax:
-    monitor_printf(mon, "invalid format\n");
+    monitor_hmp_printf(hmp, "invalid format\n");
 }
 
 static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
@@ -960,17 +959,16 @@ static int slirp_hostfwd(SlirpState *s, const char *redir_str, Error **errp)
 
 void hmp_hostfwd_add(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *redir_str;
     SlirpState *s;
     const char *arg1 = qdict_get_str(qdict, "arg1");
     const char *arg2 = qdict_get_try_str(qdict, "arg2");
 
     if (arg2) {
-        s = slirp_lookup(mon, arg1);
+        s = slirp_lookup(hmp, arg1);
         redir_str = arg2;
     } else {
-        s = slirp_lookup(mon, NULL);
+        s = slirp_lookup(hmp, NULL);
         redir_str = arg1;
     }
     if (s) {
@@ -1228,16 +1226,15 @@ UsernetInfoList *qmp_x_query_usernet(Error **errp)
 
 void hmp_info_usernet(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     g_autoptr(UsernetInfoList) list = NULL;
     UsernetInfoList *entry;
 
     list = qmp_x_query_usernet(&error_abort);
     for (entry = list; entry; entry = entry->next) {
         UsernetInfo *ui = entry->value;
-        monitor_printf(mon, "Hub %d (%s):\n%s",
-                       ui->has_hub_id ? (int)ui->hub_id : -1,
-                       ui->hub_name, ui->info);
+        monitor_hmp_printf(hmp, "Hub %d (%s):\n%s",
+                           ui->has_hub_id ? (int)ui->hub_id : -1,
+                           ui->hub_name, ui->info);
     }
 }
 
diff --git a/qom/qom-hmp-cmds.c b/qom/qom-hmp-cmds.c
index 2e2eb33371e2..bbf5980332a4 100644
--- a/qom/qom-hmp-cmds.c
+++ b/qom/qom-hmp-cmds.c
@@ -20,13 +20,12 @@
 
 void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(qdict, "path");
     ObjectPropertyInfoList *list;
     Error *err = NULL;
 
     if (path == NULL) {
-        monitor_printf(mon, "/\n");
+        monitor_hmp_printf(hmp, "/\n");
         return;
     }
 
@@ -36,8 +35,8 @@ void hmp_qom_list(MonitorHMP *hmp, const QDict *qdict)
         while (list != NULL) {
             ObjectPropertyInfo *value = list->value;
 
-            monitor_printf(mon, "%s (%s)\n",
-                           value->name, value->type);
+            monitor_hmp_printf(hmp, "%s (%s)\n",
+                               value->name, value->type);
             list = list->next;
         }
         qapi_free_ObjectPropertyInfoList(start);
@@ -75,7 +74,6 @@ void hmp_qom_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_str(qdict, "path");
     const char *property = qdict_get_str(qdict, "property");
     Error *err = NULL;
@@ -83,7 +81,7 @@ void hmp_qom_get(MonitorHMP *hmp, const QDict *qdict)
 
     if (err == NULL) {
         GString *str = qobject_to_json_pretty(obj, true);
-        monitor_printf(mon, "%s\n", str->str);
+        monitor_hmp_printf(hmp, "%s\n", str->str);
         g_string_free(str, true);
     }
 
@@ -96,7 +94,7 @@ typedef struct QOMCompositionState {
     int indent;
 } QOMCompositionState;
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent);
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent);
 
 static int qom_composition_compare(const void *a, const void *b)
 {
@@ -110,7 +108,7 @@ static int insert_qom_composition_child(Object *obj, void *opaque)
     return 0;
 }
 
-static void print_qom_composition(Monitor *mon, Object *obj, int indent)
+static void print_qom_composition(MonitorHMP *hmp, Object *obj, int indent)
 {
     GArray *children = g_array_new(false, false, sizeof(Object *));
     const char *name;
@@ -121,14 +119,14 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
     } else {
         name = object_get_canonical_path_component(obj);
     }
-    monitor_printf(mon, "%*s/%s (%s)\n", indent, "", name,
-                   object_get_typename(obj));
+    monitor_hmp_printf(hmp, "%*s/%s (%s)\n", indent, "", name,
+                       object_get_typename(obj));
 
     object_child_foreach(obj, insert_qom_composition_child, children);
     g_array_sort(children, qom_composition_compare);
 
     for (i = 0; i < children->len; i++) {
-        print_qom_composition(mon, g_array_index(children, Object *, i),
+        print_qom_composition(hmp, g_array_index(children, Object *, i),
                               indent + 2);
     }
     g_array_free(children, TRUE);
@@ -136,7 +134,6 @@ static void print_qom_composition(Monitor *mon, Object *obj, int indent)
 
 void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *path = qdict_get_try_str(dict, "path");
     Object *obj;
     bool ambiguous = false;
@@ -144,17 +141,17 @@ void hmp_info_qom_tree(MonitorHMP *hmp, const QDict *dict)
     if (path) {
         obj = object_resolve_path(path, &ambiguous);
         if (!obj) {
-            monitor_printf(mon, "Path '%s' could not be resolved.\n", path);
+            monitor_hmp_printf(hmp, "Path '%s' could not be resolved.\n", path);
             return;
         }
         if (ambiguous) {
-            monitor_printf(mon, "Warning: Path '%s' is ambiguous.\n", path);
+            monitor_hmp_printf(hmp, "Warning: Path '%s' is ambiguous.\n", path);
             return;
         }
     } else {
         obj = qdev_get_machine();
     }
-    print_qom_composition(mon, obj, 0);
+    print_qom_composition(hmp, obj, 0);
 }
 
 void hmp_object_add(MonitorHMP *hmp, const QDict *qdict)
diff --git a/replay/replay-debugging.c b/replay/replay-debugging.c
index ef69d23ff507..965565715ef2 100644
--- a/replay/replay-debugging.c
+++ b/replay/replay-debugging.c
@@ -33,11 +33,10 @@ bool replay_running_debug(void)
 
 void hmp_info_replay(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     if (replay_mode == REPLAY_MODE_NONE) {
-        monitor_printf(mon, "Record/replay is not active\n");
+        monitor_hmp_printf(hmp, "Record/replay is not active\n");
     } else {
-        monitor_printf(mon,
+        monitor_hmp_printf(hmp,
             "%s execution '%s': instruction count = %"PRId64"\n",
             replay_mode == REPLAY_MODE_RECORD ? "Recording" : "Replaying",
             replay_get_filename(), replay_get_current_icount());
diff --git a/stats/stats-hmp-cmds.c b/stats/stats-hmp-cmds.c
index cd1f1deb58bc..3d556c745d61 100644
--- a/stats/stats-hmp-cmds.c
+++ b/stats/stats-hmp-cmds.c
@@ -14,11 +14,11 @@
 #include "qobject/qdict.h"
 #include "qapi/error.h"
 
-static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
+static void print_stats_schema_value(MonitorHMP *hmp, StatsSchemaValue *value)
 {
     const char *unit = NULL;
-    monitor_printf(mon, "    %s (%s%s", value->name, StatsType_str(value->type),
-                   value->has_unit || value->exponent ? ", " : "");
+    monitor_hmp_printf(hmp, "    %s (%s%s", value->name, StatsType_str(value->type),
+                       value->has_unit || value->exponent ? ", " : "");
 
     if (value->has_unit) {
         if (value->unit == STATS_UNIT_SECONDS) {
@@ -31,29 +31,29 @@ static void print_stats_schema_value(Monitor *mon, StatsSchemaValue *value)
     if (unit && value->base == 10 &&
         value->exponent >= -18 && value->exponent <= 18 &&
         value->exponent % 3 == 0) {
-        monitor_puts(mon, si_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), si_prefix(value->exponent));
     } else if (unit && value->base == 2 &&
                value->exponent >= 0 && value->exponent <= 60 &&
                value->exponent % 10 == 0) {
 
-        monitor_puts(mon, iec_binary_prefix(value->exponent));
+        monitor_puts(MONITOR(hmp), iec_binary_prefix(value->exponent));
     } else if (value->exponent) {
         /* Use exponential notation and write the unit's English name */
-        monitor_printf(mon, "* %d^%d%s",
-                       value->base, value->exponent,
-                       value->has_unit ? " " : "");
+        monitor_hmp_printf(hmp, "* %d^%d%s",
+                           value->base, value->exponent,
+                           value->has_unit ? " " : "");
         unit = NULL;
     }
 
     if (value->has_unit) {
-        monitor_puts(mon, unit ? unit : StatsUnit_str(value->unit));
+        monitor_puts(MONITOR(hmp), unit ? unit : StatsUnit_str(value->unit));
     }
 
     /* Print bucket size for linear histograms */
     if (value->type == STATS_TYPE_LINEAR_HISTOGRAM && value->has_bucket_size) {
-        monitor_printf(mon, ", bucket size=%d", value->bucket_size);
+        monitor_hmp_printf(hmp, ", bucket size=%d", value->bucket_size);
     }
-    monitor_printf(mon, ")");
+    monitor_hmp_printf(hmp, ")");
 }
 
 static StatsSchemaValueList *find_schema_value_list(
@@ -71,7 +71,7 @@ static StatsSchemaValueList *find_schema_value_list(
     return NULL;
 }
 
-static void print_stats_results(Monitor *mon, StatsTarget target,
+static void print_stats_results(MonitorHMP *hmp, StatsTarget target,
                                 bool show_provider,
                                 StatsResult *result,
                                 StatsSchemaList *schema)
@@ -82,14 +82,14 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
     StatsList *stats_list;
 
     if (!schema_value_list) {
-        monitor_printf(mon, "failed to find schema list for %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "failed to find schema list for %s\n",
+                           StatsProvider_str(result->provider));
         return;
     }
 
     if (show_provider) {
-        monitor_printf(mon, "provider: %s\n",
-                       StatsProvider_str(result->provider));
+        monitor_hmp_printf(hmp, "provider: %s\n",
+                           StatsProvider_str(result->provider));
     }
 
     for (stats_list = result->stats; stats_list;
@@ -103,31 +103,31 @@ static void print_stats_results(Monitor *mon, StatsTarget target,
         /* Find schema entry */
         while (!g_str_equal(stats->name, schema_value->name)) {
             if (!schema_value_list->next) {
-                monitor_printf(mon, "failed to find schema entry for %s\n",
-                               stats->name);
+                monitor_hmp_printf(hmp, "failed to find schema entry for %s\n",
+                                   stats->name);
                 return;
             }
             schema_value_list = schema_value_list->next;
             schema_value = schema_value_list->value;
         }
 
-        print_stats_schema_value(mon, schema_value);
+        print_stats_schema_value(hmp, schema_value);
 
         if (stats_value->type == QTYPE_QNUM) {
-            monitor_printf(mon, ": %" PRId64 "\n", stats_value->u.scalar);
+            monitor_hmp_printf(hmp, ": %" PRId64 "\n", stats_value->u.scalar);
         } else if (stats_value->type == QTYPE_QBOOL) {
-            monitor_printf(mon, ": %s\n", stats_value->u.boolean ? "yes" : "no");
+            monitor_hmp_printf(hmp, ": %s\n", stats_value->u.boolean ? "yes" : "no");
         } else if (stats_value->type == QTYPE_QLIST) {
             uint64List *list;
             int i;
 
-            monitor_printf(mon, ": ");
+            monitor_hmp_printf(hmp, ": ");
             for (list = stats_value->u.list, i = 1;
                  list;
                  list = list->next, i++) {
-                monitor_printf(mon, "[%d]=%" PRId64 " ", i, list->value);
+                monitor_hmp_printf(hmp, "[%d]=%" PRId64 " ", i, list->value);
             }
-            monitor_printf(mon, "\n");
+            monitor_hmp_printf(hmp, "\n");
         }
     }
 }
@@ -189,7 +189,6 @@ static StatsFilter *stats_filter(StatsTarget target, const char *names,
 
 void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *target_str = qdict_get_str(qdict, "target");
     const char *provider_str = qdict_get_try_str(qdict, "provider");
     const char *names = qdict_get_try_str(qdict, "names");
@@ -204,13 +203,13 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
 
     target = qapi_enum_parse(&StatsTarget_lookup, target_str, -1, &err);
     if (err) {
-        monitor_printf(mon, "invalid stats target %s\n", target_str);
+        monitor_hmp_printf(hmp, "invalid stats target %s\n", target_str);
         goto exit_no_print;
     }
     if (provider_str) {
         provider = qapi_enum_parse(&StatsProvider_lookup, provider_str, -1, &err);
         if (err) {
-            monitor_printf(mon, "invalid stats provider %s\n", provider_str);
+            monitor_hmp_printf(hmp, "invalid stats provider %s\n", provider_str);
             goto exit_no_print;
         }
     }
@@ -241,12 +240,12 @@ void hmp_info_stats(MonitorHMP *hmp, const QDict *qdict)
         goto exit;
     }
     for (entry = stats; entry; entry = entry->next) {
-        print_stats_results(mon, target, provider_str == NULL, entry->value, schema);
+        print_stats_results(hmp, target, provider_str == NULL, entry->value, schema);
     }
 
 exit:
     if (err) {
-        monitor_printf(mon, "%s\n", error_get_pretty(err));
+        monitor_hmp_printf(hmp, "%s\n", error_get_pretty(err));
     }
 exit_no_print:
     error_free(err);
diff --git a/stubs/hmp-cmd-info_sev.c b/stubs/hmp-cmd-info_sev.c
index 6f2b87d1ad10..c9c1d10c165c 100644
--- a/stubs/hmp-cmd-info_sev.c
+++ b/stubs/hmp-cmd-info_sev.c
@@ -12,6 +12,5 @@
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
-    monitor_printf(mon, "SEV is not available in this QEMU\n");
+    monitor_hmp_printf(hmp, "SEV is not available in this QEMU\n");
 }
diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c
index b0c7002bd406..094b80721003 100644
--- a/stubs/monitor-core.c
+++ b/stubs/monitor-core.c
@@ -17,7 +17,7 @@ void qapi_event_emit(QAPIEvent event, QDict *qdict)
 {
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     /*
      * Pretend 'g_test_message' is our monitor console to
diff --git a/system/dirtylimit-hmp-cmds.c b/system/dirtylimit-hmp-cmds.c
index 75194add7931..fb9338e9aef6 100644
--- a/system/dirtylimit-hmp-cmds.c
+++ b/system/dirtylimit-hmp-cmds.c
@@ -17,7 +17,6 @@
 
 void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     int64_t cpu_index = qdict_get_try_int(qdict, "cpu_index", -1);
     Error *err = NULL;
 
@@ -27,8 +26,8 @@ void hmp_cancel_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
 
-    monitor_printf(mon, "[Please use 'info vcpu_dirty_limit' to query "
-                   "dirty limit for virtual CPU]\n");
+    monitor_hmp_printf(hmp, "[Please use 'info vcpu_dirty_limit' to query "
+                       "dirty limit for virtual CPU]\n");
 }
 
 void hmp_set_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
@@ -50,13 +49,12 @@ out:
 
 void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     DirtyLimitInfoList *info;
     g_autoptr(DirtyLimitInfoList) head = NULL;
     Error *err = NULL;
 
     if (!dirtylimit_in_service()) {
-        monitor_printf(mon, "Dirty page limit not enabled!\n");
+        monitor_hmp_printf(hmp, "Dirty page limit not enabled!\n");
         return;
     }
 
@@ -67,7 +65,7 @@ void hmp_info_vcpu_dirty_limit(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (info = head; info != NULL; info = info->next) {
-        monitor_printf(mon, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
+        monitor_hmp_printf(hmp, "vcpu[%"PRIi64"], limit rate %"PRIi64 " (MB/s),"
                             " current rate %"PRIi64 " (MB/s)\n",
                             info->value->cpu_index,
                             info->value->limit_rate,
diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c
index 5c2de2f53cc9..3860ada2a237 100644
--- a/system/qdev-monitor.c
+++ b/system/qdev-monitor.c
@@ -763,9 +763,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
     return ret;
 }
 
-#define qdev_printf(fmt, ...) monitor_printf(mon, "%*s" fmt, indent, "", ## __VA_ARGS__)
+#define qdev_printf(fmt, ...) \
+    monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__)
 
-static void qdev_print_props(Monitor *mon, DeviceState *dev, DeviceClass *dc,
+static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc,
                              int indent)
 {
     for (int i = 0, n = dc->props_count_; i < n; ++i) {
@@ -798,8 +799,9 @@ static void bus_print_dev(BusState *bus, Monitor *mon, DeviceState *dev, int ind
     }
 }
 
-static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
+static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
+    Monitor *mon = MONITOR(hmp);
     ObjectClass *class;
     NamedGPIOList *ngl;
     NamedClockList *ncl;
@@ -823,13 +825,13 @@ static void qdev_print(Monitor *mon, DeviceState *dev, int indent)
     }
     class = object_get_class(OBJECT(dev));
     do {
-        qdev_print_props(mon, dev, DEVICE_CLASS(class), indent);
+        qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent);
         class = object_class_get_parent(class);
     } while (class != object_class_by_name(TYPE_DEVICE));
     bus_print_dev(dev->parent_bus, mon, dev, indent);
 }
 
-static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
+static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details)
 {
     BusChild *kid;
 
@@ -842,10 +844,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
         qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)),
                     dev->id ? dev->id : "");
         if (details) {
-            qdev_print(mon, dev, indent + 2);
+            qdev_print(hmp, dev, indent + 2);
         }
         QLIST_FOREACH(child_bus, &dev->child_bus, sibling) {
-            qbus_print(mon, child_bus, indent + 2, details);
+            qbus_print(hmp, child_bus, indent + 2, details);
         }
     }
 }
@@ -853,11 +855,10 @@ static void qbus_print(Monitor *mon, BusState *bus, int indent, bool details)
 
 void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     bool details = !qdict_get_try_bool(qdict, "brief", false);
 
     if (sysbus_get_default()) {
-        qbus_print(mon, sysbus_get_default(), 0, details);
+        qbus_print(hmp, sysbus_get_default(), 0, details);
     }
 }
 
diff --git a/system/runstate-hmp-cmds.c b/system/runstate-hmp-cmds.c
index 051ee45ee74c..ad70b53f8abf 100644
--- a/system/runstate-hmp-cmds.c
+++ b/system/runstate-hmp-cmds.c
@@ -25,33 +25,31 @@
 
 void hmp_info_status(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     StatusInfo *info;
 
     info = qmp_query_status(NULL);
 
-    monitor_printf(mon, "VM status: %s",
-                   info->running ? "running" : "paused");
+    monitor_hmp_printf(hmp, "VM status: %s",
+                       info->running ? "running" : "paused");
 
     if (!info->running && info->status != RUN_STATE_PAUSED) {
-        monitor_printf(mon, " (%s)", RunState_str(info->status));
+        monitor_hmp_printf(hmp, " (%s)", RunState_str(info->status));
     }
 
-    monitor_printf(mon, "\n");
+    monitor_hmp_printf(hmp, "\n");
 
     qapi_free_StatusInfo(info);
 }
 
 void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *option = qdict_get_try_str(qdict, "option");
     AccelState *accel = current_accel();
     bool newval;
 
     if (!object_property_find(OBJECT(accel), "one-insn-per-tb")) {
-        monitor_printf(mon,
-                       "This accelerator does not support setting one-insn-per-tb\n");
+        monitor_hmp_printf(hmp,
+                           "This accelerator does not support setting one-insn-per-tb\n");
         return;
     }
 
@@ -60,7 +58,7 @@ void hmp_one_insn_per_tb(MonitorHMP *hmp, const QDict *qdict)
     } else if (!strcmp(option, "off")) {
         newval = false;
     } else {
-        monitor_printf(mon, "unexpected option %s\n", option);
+        monitor_hmp_printf(hmp, "unexpected option %s\n", option);
         return;
     }
     /* If the property exists then setting it can never fail */
diff --git a/system/tpm-hmp-cmds.c b/system/tpm-hmp-cmds.c
index 094c3f16cf50..35406e24d2c3 100644
--- a/system/tpm-hmp-cmds.c
+++ b/system/tpm-hmp-cmds.c
@@ -13,7 +13,6 @@
 
 void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
 #ifdef CONFIG_TPM
     TPMInfoList *info_list, *info;
     Error *err = NULL;
@@ -23,44 +22,44 @@ void hmp_info_tpm(MonitorHMP *hmp, const QDict *qdict)
 
     info_list = qmp_query_tpm(&err);
     if (err) {
-        monitor_printf(mon, "TPM device not supported\n");
+        monitor_hmp_printf(hmp, "TPM device not supported\n");
         error_free(err);
         return;
     }
 
     if (info_list) {
-        monitor_printf(mon, "TPM device:\n");
+        monitor_hmp_printf(hmp, "TPM device:\n");
     }
 
     for (info = info_list; info; info = info->next) {
         TPMInfo *ti = info->value;
-        monitor_printf(mon, " tpm%d: model=%s\n",
-                       c, TpmModel_str(ti->model));
+        monitor_hmp_printf(hmp, " tpm%d: model=%s\n",
+                           c, TpmModel_str(ti->model));
 
-        monitor_printf(mon, "  \\ %s: type=%s",
-                       ti->id, TpmType_str(ti->options->type));
+        monitor_hmp_printf(hmp, "  \\ %s: type=%s",
+                           ti->id, TpmType_str(ti->options->type));
 
         switch (ti->options->type) {
         case TPM_TYPE_PASSTHROUGH:
             tpo = ti->options->u.passthrough.data;
-            monitor_printf(mon, "%s%s%s%s",
-                           tpo->path ? ",path=" : "",
-                           tpo->path ?: "",
-                           tpo->cancel_path ? ",cancel-path=" : "",
-                           tpo->cancel_path ?: "");
+            monitor_hmp_printf(hmp, "%s%s%s%s",
+                               tpo->path ? ",path=" : "",
+                               tpo->path ?: "",
+                               tpo->cancel_path ? ",cancel-path=" : "",
+                               tpo->cancel_path ?: "");
             break;
         case TPM_TYPE_EMULATOR:
             teo = ti->options->u.emulator.data;
-            monitor_printf(mon, ",chardev=%s", teo->chardev);
+            monitor_hmp_printf(hmp, ",chardev=%s", teo->chardev);
             break;
         case TPM_TYPE__MAX:
             break;
         }
-        monitor_printf(mon, "\n");
+        monitor_hmp_printf(hmp, "\n");
         c++;
     }
     qapi_free_TPMInfoList(info_list);
 #else
-    monitor_printf(mon, "TPM device not supported\n");
+    monitor_hmp_printf(hmp, "TPM device not supported\n");
 #endif /* CONFIG_TPM */
 }
diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
index af67f00dad32..96d6ad897275 100644
--- a/target/i386/cpu-apic.c
+++ b/target/i386/cpu-apic.c
@@ -85,7 +85,6 @@ void x86_cpu_apic_realize(X86CPU *cpu, Error **errp)
 
 void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUState *cs;
 
     if (qdict_haskey(qdict, "apic-id")) {
@@ -101,7 +100,7 @@ void hmp_info_local_apic(MonitorHMP *hmp, const QDict *qdict)
 
 
     if (!cs) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     x86_cpu_dump_local_apic_state(cs, CPU_DUMP_FPU);
diff --git a/target/i386/monitor.c b/target/i386/monitor.c
index 72bcab131f77..46762540ba65 100644
--- a/target/i386/monitor.c
+++ b/target/i386/monitor.c
@@ -48,27 +48,27 @@ static hwaddr addr_canonical(CPUArchState *env, hwaddr addr)
     return addr;
 }
 
-static void print_pte(Monitor *mon, CPUArchState *env, hwaddr addr,
+static void print_pte(MonitorHMP *hmp, CPUArchState *env, hwaddr addr,
                       hwaddr pte, hwaddr mask)
 {
     addr = addr_canonical(env, addr);
 
-    monitor_printf(mon, HWADDR_FMT_plx ": " HWADDR_FMT_plx
-                   " %c%c%c%c%c%c%c%c%c\n",
-                   addr,
-                   pte & mask,
-                   pte & PG_NX_MASK ? 'X' : '-',
-                   pte & PG_GLOBAL_MASK ? 'G' : '-',
-                   pte & PG_PSE_MASK ? 'P' : '-',
-                   pte & PG_DIRTY_MASK ? 'D' : '-',
-                   pte & PG_ACCESSED_MASK ? 'A' : '-',
-                   pte & PG_PCD_MASK ? 'C' : '-',
-                   pte & PG_PWT_MASK ? 'T' : '-',
-                   pte & PG_USER_MASK ? 'U' : '-',
-                   pte & PG_RW_MASK ? 'W' : '-');
+    monitor_hmp_printf(hmp, HWADDR_FMT_plx ": " HWADDR_FMT_plx
+                       " %c%c%c%c%c%c%c%c%c\n",
+                       addr,
+                       pte & mask,
+                       pte & PG_NX_MASK ? 'X' : '-',
+                       pte & PG_GLOBAL_MASK ? 'G' : '-',
+                       pte & PG_PSE_MASK ? 'P' : '-',
+                       pte & PG_DIRTY_MASK ? 'D' : '-',
+                       pte & PG_ACCESSED_MASK ? 'A' : '-',
+                       pte & PG_PCD_MASK ? 'C' : '-',
+                       pte & PG_PWT_MASK ? 'T' : '-',
+                       pte & PG_USER_MASK ? 'U' : '-',
+                       pte & PG_RW_MASK ? 'W' : '-');
 }
 
-static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -80,13 +80,13 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 /* 4M pages */
-                print_pte(mon, env, (l1 << 22), pde, ~((1 << 21) - 1));
+                print_pte(hmp, env, (l1 << 22), pde, ~((1 << 21) - 1));
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l1 << 22) + (l2 << 12),
+                        print_pte(hmp, env, (l1 << 22) + (l2 << 12),
                                   pte & ~PG_PSE_MASK,
                                   ~0xfff);
                     }
@@ -96,7 +96,7 @@ static void tlb_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
     }
 }
 
-static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -113,7 +113,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 if (pde & PG_PRESENT_MASK) {
                     if (pde & PG_PSE_MASK) {
                         /* 2M pages with PAE, CR4.PSE is ignored */
-                        print_pte(mon, env, (l1 << 30) + (l2 << 21), pde,
+                        print_pte(hmp, env, (l1 << 30) + (l2 << 21), pde,
                                   ~((hwaddr)(1 << 20) - 1));
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
@@ -121,7 +121,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             pte = address_space_ldq_le(as, pt_addr + l3 * 8,
                                                        attrs, NULL);
                             if (pte & PG_PRESENT_MASK) {
-                                print_pte(mon, env, (l1 << 30) + (l2 << 21)
+                                print_pte(hmp, env, (l1 << 30) + (l2 << 21)
                                           + (l3 << 12),
                                           pte & ~PG_PSE_MASK,
                                           ~(hwaddr)0xfff);
@@ -135,7 +135,7 @@ static void tlb_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
 }
 
 #ifdef TARGET_X86_64
-static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
+static void tlb_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as,
         uint64_t l0, uint64_t pml4_addr)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
@@ -158,7 +158,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
             if (pdpe & PG_PSE_MASK) {
                 /* 1G pages, CR4.PSE is ignored */
-                print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
+                print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30),
                         pdpe, 0x3ffffc0000000ULL);
                 continue;
             }
@@ -172,7 +172,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
 
                 if (pde & PG_PSE_MASK) {
                     /* 2M pages, CR4.PSE is ignored */
-                    print_pte(mon, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
+                    print_pte(hmp, env, (l0 << 48) + (l1 << 39) + (l2 << 30) +
                             (l3 << 21), pde, 0x3ffffffe00000ULL);
                     continue;
                 }
@@ -182,7 +182,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
                     pte = address_space_ldq_le(as, pt_addr + l4 * 8,
                                                attrs, NULL);
                     if (pte & PG_PRESENT_MASK) {
-                        print_pte(mon, env, (l0 << 48) + (l1 << 39) +
+                        print_pte(hmp, env, (l0 << 48) + (l1 << 39) +
                                 (l2 << 30) + (l3 << 21) + (l4 << 12),
                                 pte & ~PG_PSE_MASK, 0x3fffffffff000ULL);
                     }
@@ -192,7 +192,7 @@ static void tlb_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as,
     }
 }
 
-static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void tlb_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     uint64_t l0;
@@ -203,7 +203,7 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
     for (l0 = 0; l0 < 512; l0++) {
         pml5e = address_space_ldq_le(as, pml5_addr + l0 * 8, attrs, NULL);
         if (pml5e & PG_PRESENT_MASK) {
-            tlb_info_la48(mon, env, as, l0, pml5e & 0x3fffffffff000ULL);
+            tlb_info_la48(hmp, env, as, l0, pml5e & 0x3fffffffff000ULL);
         }
     }
 }
@@ -211,18 +211,17 @@ static void tlb_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -230,21 +229,21 @@ void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                tlb_info_la57(mon, env, as);
+                tlb_info_la57(hmp, env, as);
             } else {
-                tlb_info_la48(mon, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
+                tlb_info_la48(hmp, env, as, 0, env->cr[3] & 0x3fffffffff000ULL);
             }
         } else
 #endif
         {
-            tlb_info_pae32(mon, env, as);
+            tlb_info_pae32(hmp, env, as);
         }
     } else {
-        tlb_info_32(mon, env, as);
+        tlb_info_32(hmp, env, as);
     }
 }
 
-static void mem_print(Monitor *mon, CPUArchState *env,
+static void mem_print(MonitorHMP *hmp, CPUArchState *env,
                       hwaddr *pstart, int *plast_prot,
                       hwaddr end, int prot)
 {
@@ -252,14 +251,14 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     prot1 = *plast_prot;
     if (prot != prot1) {
         if (*pstart != -1) {
-            monitor_printf(mon, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
-                           HWADDR_FMT_plx " %c%c%c\n",
-                           addr_canonical(env, *pstart),
-                           addr_canonical(env, end),
-                           addr_canonical(env, end - *pstart),
-                           prot1 & PG_USER_MASK ? 'u' : '-',
-                           'r',
-                           prot1 & PG_RW_MASK ? 'w' : '-');
+            monitor_hmp_printf(hmp, HWADDR_FMT_plx "-" HWADDR_FMT_plx " "
+                               HWADDR_FMT_plx " %c%c%c\n",
+                               addr_canonical(env, *pstart),
+                               addr_canonical(env, end),
+                               addr_canonical(env, end - *pstart),
+                               prot1 & PG_USER_MASK ? 'u' : '-',
+                               'r',
+                               prot1 & PG_RW_MASK ? 'w' : '-');
         }
         if (prot != 0)
             *pstart = end;
@@ -269,7 +268,7 @@ static void mem_print(Monitor *mon, CPUArchState *env,
     }
 }
 
-static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2;
@@ -286,7 +285,7 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
         if (pde & PG_PRESENT_MASK) {
             if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
                 prot = pde & (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
             } else {
                 for(l2 = 0; l2 < 1024; l2++) {
                     pte = address_space_ldl_le(as, (pde & ~0xfff) + l2 * 4,
@@ -298,19 +297,19 @@ static void mem_info_32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     } else {
                         prot = 0;
                     }
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
-static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_pae32(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     unsigned int l1, l2, l3;
@@ -334,7 +333,7 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     if (pde & PG_PSE_MASK) {
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                       PG_PRESENT_MASK);
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pt_addr = pde & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -347,26 +346,26 @@ static void mem_info_pae32(Monitor *mon, CPUArchState *env, AddressSpace *as)
                             } else {
                                 prot = 0;
                             }
-                            mem_print(mon, env, &start, &last_prot, end, prot);
+                            mem_print(hmp, env, &start, &last_prot, end, prot);
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 32, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 32, 0);
 }
 
 
 #ifdef TARGET_X86_64
-static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la48(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -390,7 +389,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                                        PG_PRESENT_MASK);
                         prot &= pml4e;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     } else {
                         pd_addr = pdpe & 0x3fffffffff000ULL;
                         for (l3 = 0; l3 < 512; l3++) {
@@ -402,7 +401,7 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                     prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                                   PG_PRESENT_MASK);
                                     prot &= pml4e & pdpe;
-                                    mem_print(mon, env, &start,
+                                    mem_print(hmp, env, &start,
                                               &last_prot, end, prot);
                                 } else {
                                     pt_addr = pde & 0x3fffffffff000ULL;
@@ -420,32 +419,32 @@ static void mem_info_la48(Monitor *mon, CPUArchState *env, AddressSpace *as)
                                         } else {
                                             prot = 0;
                                         }
-                                        mem_print(mon, env, &start,
+                                        mem_print(hmp, env, &start,
                                                   &last_prot, end, prot);
                                     }
                                 }
                             } else {
                                 prot = 0;
-                                mem_print(mon, env, &start,
+                                mem_print(hmp, env, &start,
                                           &last_prot, end, prot);
                             }
                         }
                     }
                 } else {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                 }
             }
         } else {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 48, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 48, 0);
 }
 
-static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
+static void mem_info_la57(MonitorHMP *hmp, CPUArchState *env, AddressSpace *as)
 {
     const MemTxAttrs attrs = MEMTXATTRS_UNSPECIFIED;
     int prot, last_prot;
@@ -461,7 +460,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
         end = l0 << 48;
         if (!(pml5e & PG_PRESENT_MASK)) {
             prot = 0;
-            mem_print(mon, env, &start, &last_prot, end, prot);
+            mem_print(hmp, env, &start, &last_prot, end, prot);
             continue;
         }
 
@@ -471,7 +470,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
             end = (l0 << 48) + (l1 << 39);
             if (!(pml4e & PG_PRESENT_MASK)) {
                 prot = 0;
-                mem_print(mon, env, &start, &last_prot, end, prot);
+                mem_print(hmp, env, &start, &last_prot, end, prot);
                 continue;
             }
 
@@ -481,7 +480,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                 end = (l0 << 48) + (l1 << 39) + (l2 << 30);
                 if (pdpe & PG_PRESENT_MASK) {
                     prot = 0;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -489,7 +488,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     prot = pdpe & (PG_USER_MASK | PG_RW_MASK |
                             PG_PRESENT_MASK);
                     prot &= pml5e & pml4e;
-                    mem_print(mon, env, &start, &last_prot, end, prot);
+                    mem_print(hmp, env, &start, &last_prot, end, prot);
                     continue;
                 }
 
@@ -500,7 +499,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                     end = (l0 << 48) + (l1 << 39) + (l2 << 30) + (l3 << 21);
                     if (pde & PG_PRESENT_MASK) {
                         prot = 0;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -508,7 +507,7 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         prot = pde & (PG_USER_MASK | PG_RW_MASK |
                                 PG_PRESENT_MASK);
                         prot &= pml5e & pml4e & pdpe;
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                         continue;
                     }
 
@@ -525,31 +524,30 @@ static void mem_info_la57(Monitor *mon, CPUArchState *env, AddressSpace *as)
                         } else {
                             prot = 0;
                         }
-                        mem_print(mon, env, &start, &last_prot, end, prot);
+                        mem_print(hmp, env, &start, &last_prot, end, prot);
                     }
                 }
             }
         }
     }
     /* Flush last range */
-    mem_print(mon, env, &start, &last_prot, (hwaddr)1 << 57, 0);
+    mem_print(hmp, env, &start, &last_prot, (hwaddr)1 << 57, 0);
 }
 #endif /* TARGET_X86_64 */
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
     AddressSpace *as;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!(env->cr[0] & CR0_PG_MASK)) {
-        monitor_printf(mon, "PG disabled\n");
+        monitor_hmp_printf(hmp, "PG disabled\n");
         return;
     }
     as = cpu_get_address_space(env_cpu(env), X86ASIdx_MEM);
@@ -557,17 +555,17 @@ void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 #ifdef TARGET_X86_64
         if (env->hflags & HF_LMA_MASK) {
             if (env->cr[4] & CR4_LA57_MASK) {
-                mem_info_la57(mon, env, as);
+                mem_info_la57(hmp, env, as);
             } else {
-                mem_info_la48(mon, env, as);
+                mem_info_la48(hmp, env, as);
             }
         } else
 #endif
         {
-            mem_info_pae32(mon, env, as);
+            mem_info_pae32(hmp, env, as);
         }
     } else {
-        mem_info_32(mon, env, as);
+        mem_info_32(hmp, env, as);
     }
 }
 
diff --git a/target/i386/sev.c b/target/i386/sev.c
index a3f6ee95aaed..7b2eb75fd480 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -786,33 +786,32 @@ SevInfo *qmp_query_sev(Error **errp)
 
 void hmp_info_sev(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SevInfo *info = sev_get_info();
 
     if (!info || !info->enabled) {
-        monitor_printf(mon, "SEV is not enabled\n");
+        monitor_hmp_printf(hmp, "SEV is not enabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "SEV type: %s\n", SevGuestType_str(info->sev_type));
-    monitor_printf(mon, "state: %s\n", SevState_str(info->state));
-    monitor_printf(mon, "build: %d\n", info->build_id);
-    monitor_printf(mon, "api version: %d.%d\n", info->api_major,
-                   info->api_minor);
+    monitor_hmp_printf(hmp, "SEV type: %s\n", SevGuestType_str(info->sev_type));
+    monitor_hmp_printf(hmp, "state: %s\n", SevState_str(info->state));
+    monitor_hmp_printf(hmp, "build: %d\n", info->build_id);
+    monitor_hmp_printf(hmp, "api version: %d.%d\n", info->api_major,
+                       info->api_minor);
 
     if (sev_snp_enabled()) {
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
-                                                                       : "off");
-        monitor_printf(mon, "SMT allowed: %s\n",
-                       info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
-                                                                       : "off");
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_DBG ? "on"
+                                                                           : "off");
+        monitor_hmp_printf(hmp, "SMT allowed: %s\n",
+                           info->u.sev_snp.snp_policy & SEV_SNP_POLICY_SMT ? "on"
+                                                                           : "off");
     } else {
-        monitor_printf(mon, "handle: %d\n", info->u.sev.handle);
-        monitor_printf(mon, "debug: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
-        monitor_printf(mon, "key-sharing: %s\n",
-                       info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
+        monitor_hmp_printf(hmp, "handle: %d\n", info->u.sev.handle);
+        monitor_hmp_printf(hmp, "debug: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NODBG ? "off" : "on");
+        monitor_hmp_printf(hmp, "key-sharing: %s\n",
+                           info->u.sev.policy & SEV_POLICY_NOKS ? "off" : "on");
     }
 
 out:
diff --git a/target/m68k/monitor.c b/target/m68k/monitor.c
index 5645a5d4d4f5..23c25283b27a 100644
--- a/target/m68k/monitor.c
+++ b/target/m68k/monitor.c
@@ -12,11 +12,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
diff --git a/target/ppc/monitor.c b/target/ppc/monitor.c
index 5769829bdd7e..6e8a075f5a41 100644
--- a/target/ppc/monitor.c
+++ b/target/ppc/monitor.c
@@ -13,11 +13,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
index 4c9c0c793b36..59cc04b3d0fb 100644
--- a/target/riscv/monitor.c
+++ b/target/riscv/monitor.c
@@ -51,13 +51,13 @@ static target_ulong addr_canonical(int va_bits, target_ulong addr)
     return addr;
 }
 
-static void print_pte_header(Monitor *mon)
+static void print_pte_header(MonitorHMP *hmp)
 {
-    monitor_printf(mon, PTE_HEADER_FIELDS);
-    monitor_printf(mon, PTE_HEADER_DELIMITER);
+    monitor_hmp_printf(hmp, PTE_HEADER_FIELDS);
+    monitor_hmp_printf(hmp, PTE_HEADER_DELIMITER);
 }
 
-static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
+static void print_pte(MonitorHMP *hmp, int va_bits, target_ulong vaddr,
                       hwaddr paddr, target_ulong size, int attr)
 {
     /* sanity check on vaddr */
@@ -69,20 +69,20 @@ static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
         return;
     }
 
-    monitor_printf(mon, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
-                   " %c%c%c%c%c%c%c\n",
-                   addr_canonical(va_bits, vaddr),
-                   paddr, size,
-                   attr & PTE_R ? 'r' : '-',
-                   attr & PTE_W ? 'w' : '-',
-                   attr & PTE_X ? 'x' : '-',
-                   attr & PTE_U ? 'u' : '-',
-                   attr & PTE_G ? 'g' : '-',
-                   attr & PTE_A ? 'a' : '-',
-                   attr & PTE_D ? 'd' : '-');
+    monitor_hmp_printf(hmp, TARGET_FMT_lx " " HWADDR_FMT_plx " " TARGET_FMT_lx
+                       " %c%c%c%c%c%c%c\n",
+                       addr_canonical(va_bits, vaddr),
+                       paddr, size,
+                       attr & PTE_R ? 'r' : '-',
+                       attr & PTE_W ? 'w' : '-',
+                       attr & PTE_X ? 'x' : '-',
+                       attr & PTE_U ? 'u' : '-',
+                       attr & PTE_G ? 'g' : '-',
+                       attr & PTE_A ? 'a' : '-',
+                       attr & PTE_D ? 'd' : '-');
 }
 
-static void walk_pte(Monitor *mon, AddressSpace *as,
+static void walk_pte(MonitorHMP *hmp, AddressSpace *as,
                      hwaddr base, target_ulong start,
                      int level, int ptidxbits, int ptesize, int va_bits,
                      target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
@@ -126,7 +126,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 if ((*last_attr != attr) ||
                     (*last_paddr + *last_size != paddr) ||
                     (last_start + *last_size != start)) {
-                    print_pte(mon, va_bits, *vbase, *pbase,
+                    print_pte(hmp, va_bits, *vbase, *pbase,
                               *last_paddr + *last_size - *pbase, *last_attr);
 
                     *vbase = start;
@@ -139,7 +139,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
                 *last_size = pgsize;
             } else {
                 /* pointer to the next level of the page table */
-                walk_pte(mon, as, paddr, start, level - 1, ptidxbits, ptesize,
+                walk_pte(hmp, as, paddr, start, level - 1, ptidxbits, ptesize,
                          va_bits, vbase, pbase, last_paddr,
                          last_size, last_attr);
             }
@@ -150,7 +150,7 @@ static void walk_pte(Monitor *mon, AddressSpace *as,
 
 }
 
-static void mem_info_svxx(Monitor *mon, CPUArchState *env)
+static void mem_info_svxx(MonitorHMP *hmp, CPUArchState *env)
 {
     AddressSpace *as = env_cpu(env)->as;
     int levels, ptidxbits, ptesize, vm, va_bits;
@@ -198,7 +198,7 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     va_bits = PGSHIFT + levels * ptidxbits;
 
     /* print header */
-    print_pte_header(mon);
+    print_pte_header(hmp);
 
     vbase = -1;
     pbase = -1;
@@ -207,43 +207,42 @@ static void mem_info_svxx(Monitor *mon, CPUArchState *env)
     last_attr = 0;
 
     /* walk page tables, starting from address 0 */
-    walk_pte(mon, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
+    walk_pte(hmp, as, base, 0, levels - 1, ptidxbits, ptesize, va_bits,
              &vbase, &pbase, &last_paddr, &last_size, &last_attr);
 
     /* don't forget the last one */
-    print_pte(mon, va_bits, vbase, pbase,
+    print_pte(hmp, va_bits, vbase, pbase,
               last_paddr + last_size - pbase, last_attr);
 }
 
 void hmp_info_mem(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env;
 
     env = monitor_hmp_get_cpu_env(hmp);
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
     if (!riscv_cpu_cfg(env)->mmu) {
-        monitor_printf(mon, "S-mode MMU unavailable\n");
+        monitor_hmp_printf(hmp, "S-mode MMU unavailable\n");
         return;
     }
 
     if (riscv_cpu_mxl(env) == MXL_RV32) {
         if (!(env->satp & SATP32_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     } else {
         if (!(env->satp & SATP64_MODE)) {
-            monitor_printf(mon, "No translation or protection\n");
+            monitor_hmp_printf(hmp, "No translation or protection\n");
             return;
         }
     }
 
-    mem_info_svxx(mon, env);
+    mem_info_svxx(hmp, env);
 }
 
 #ifdef CONFIG_TCG
diff --git a/target/sh4/monitor.c b/target/sh4/monitor.c
index 4e443152bf56..62998a9a57cb 100644
--- a/target/sh4/monitor.c
+++ b/target/sh4/monitor.c
@@ -26,33 +26,32 @@
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
 
-static void print_tlb(Monitor *mon, int idx, tlb_t *tlb)
+static void print_tlb(MonitorHMP *hmp, int idx, tlb_t *tlb)
 {
-    monitor_printf(mon, " tlb%i:\t"
-                   "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
-                   "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
-                   "dirty=%hhu writethrough=%hhu\n",
-                   idx,
-                   tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
-                   tlb->v, tlb->sh, tlb->c, tlb->pr,
-                   tlb->d, tlb->wt);
+    monitor_hmp_printf(hmp, " tlb%i:\t"
+                       "asid=%hhu vpn=%x\tppn=%x\tsz=%hhu size=%u\t"
+                       "v=%hhu shared=%hhu cached=%hhu prot=%hhu "
+                       "dirty=%hhu writethrough=%hhu\n",
+                       idx,
+                       tlb->asid, tlb->vpn, tlb->ppn, tlb->sz, tlb->size,
+                       tlb->v, tlb->sh, tlb->c, tlb->pr,
+                       tlb->d, tlb->wt);
 }
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env = monitor_hmp_get_cpu_env(hmp);
     int i;
 
     if (!env) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
 
-    monitor_printf (mon, "ITLB:\n");
+    monitor_hmp_printf(hmp, "ITLB:\n");
     for (i = 0 ; i < ITLB_SIZE ; i++)
-        print_tlb (mon, i, &env->itlb[i]);
-    monitor_printf (mon, "UTLB:\n");
+        print_tlb(hmp, i, &env->itlb[i]);
+    monitor_hmp_printf(hmp, "UTLB:\n");
     for (i = 0 ; i < UTLB_SIZE ; i++)
-        print_tlb (mon, i, &env->utlb[i]);
+        print_tlb(hmp, i, &env->utlb[i]);
 }
diff --git a/target/sparc/monitor.c b/target/sparc/monitor.c
index e826e584a918..36f109cbb568 100644
--- a/target/sparc/monitor.c
+++ b/target/sparc/monitor.c
@@ -29,11 +29,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/target/xtensa/monitor.c b/target/xtensa/monitor.c
index b7b7387706f3..b9c4089b0fb1 100644
--- a/target/xtensa/monitor.c
+++ b/target/xtensa/monitor.c
@@ -28,11 +28,10 @@
 
 void hmp_info_tlb(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     CPUArchState *env1 = monitor_hmp_get_cpu_env(hmp);
 
     if (!env1) {
-        monitor_printf(mon, "No CPU available\n");
+        monitor_hmp_printf(hmp, "No CPU available\n");
         return;
     }
     dump_mmu(env1);
diff --git a/tests/unit/test-util-sockets.c b/tests/unit/test-util-sockets.c
index b2a884529598..530a3fee3c13 100644
--- a/tests/unit/test-util-sockets.c
+++ b/tests/unit/test-util-sockets.c
@@ -75,7 +75,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error **errp)
  */
 Monitor *monitor_cur(void) { return cur_mon; }
 Monitor *monitor_set_cur(Coroutine *co, Monitor *mon) { abort(); }
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap) { abort(); }
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap) { abort(); }
 
 #ifndef _WIN32
 static void test_socket_fd_pass_name_good(void)
diff --git a/tools/qemu-vnc/clipboard.c b/tools/qemu-vnc/clipboard.c
index f62b2f294952..81a09ec5adfa 100644
--- a/tools/qemu-vnc/clipboard.c
+++ b/tools/qemu-vnc/clipboard.c
@@ -62,7 +62,7 @@ vnc_dbus_clipboard_request_cancelled(VncDBusClipboardRequest *req)
         "Cancelled clipboard request");
 
     g_clear_object(&req->invocation);
-    g_clear_handle_id(&req->timeout_id, g_source_remove);;
+    g_clear_handle_id(&req->timeout_id, g_source_remove);
 }
 
 static gboolean
@@ -137,7 +137,7 @@ vnc_dbus_clipboard_update_info(QemuClipboardInfo *info)
         vnc_dbus_clipboard_complete_request(
             req->invocation, info, req->type);
         g_clear_object(&req->invocation);
-        g_clear_handle_id(&req->timeout_id, g_source_remove);;
+        g_clear_handle_id(&req->timeout_id, g_source_remove);
         return;
     }
 
diff --git a/tools/qemu-vnc/stubs.c b/tools/qemu-vnc/stubs.c
index 26597fefaa99..0aa50a901d37 100644
--- a/tools/qemu-vnc/stubs.c
+++ b/tools/qemu-vnc/stubs.c
@@ -42,7 +42,7 @@ Monitor *monitor_set_cur(Coroutine *co, Monitor *mon)
     return NULL;
 }
 
-int monitor_vprintf(Monitor *mon, const char *fmt, va_list ap)
+int monitor_hmp_vprintf(MonitorHMP *mon, const char *fmt, va_list ap)
 {
     return -1;
 }
diff --git a/trace/trace-hmp-cmds.c b/trace/trace-hmp-cmds.c
index 5a8158f4f4b6..a68f5b900d7c 100644
--- a/trace/trace-hmp-cmds.c
+++ b/trace/trace-hmp-cmds.c
@@ -49,7 +49,6 @@ void hmp_trace_event(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_TRACE_SIMPLE
 void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *op = qdict_get_try_str(qdict, "op");
     const char *arg = qdict_get_try_str(qdict, "arg");
 
@@ -66,15 +65,14 @@ void hmp_trace_file(MonitorHMP *hmp, const QDict *qdict)
             st_set_trace_file(arg);
         }
     } else {
-        monitor_printf(mon, "unexpected argument \"%s\"\n", op);
-        hmp_help_cmd(mon, "trace-file");
+        monitor_hmp_printf(hmp, "unexpected argument \"%s\"\n", op);
+        hmp_help_cmd(hmp, "trace-file");
     }
 }
 #endif
 
 void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *name = qdict_get_try_str(qdict, "name");
     TraceEventInfoList *events;
     TraceEventInfoList *elem;
@@ -91,9 +89,9 @@ void hmp_info_trace_events(MonitorHMP *hmp, const QDict *qdict)
     }
 
     for (elem = events; elem != NULL; elem = elem->next) {
-        monitor_printf(mon, "%s : state %u\n",
-                       elem->value->name,
-                       elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
+        monitor_hmp_printf(hmp, "%s : state %u\n",
+                           elem->value->name,
+                           elem->value->state == TRACE_EVENT_STATE_ENABLED ? 1 : 0);
     }
     qapi_free_TraceEventInfoList(events);
 }
diff --git a/ui/ui-hmp-cmds.c b/ui/ui-hmp-cmds.c
index 186209fd0234..f611dd7ee457 100644
--- a/ui/ui-hmp-cmds.c
+++ b/ui/ui-hmp-cmds.c
@@ -81,20 +81,19 @@ void hmp_mouse_set(MonitorHMP *hmp, const QDict *qdict)
 
 void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     MouseInfoList *mice_list, *mouse;
 
     mice_list = qmp_query_mice(NULL);
     if (!mice_list) {
-        monitor_printf(mon, "No mouse devices connected\n");
+        monitor_hmp_printf(hmp, "No mouse devices connected\n");
         return;
     }
 
     for (mouse = mice_list; mouse; mouse = mouse->next) {
-        monitor_printf(mon, "%c Mouse #%" PRId64 ": %s%s\n",
-                       mouse->value->current ? '*' : ' ',
-                       mouse->value->index, mouse->value->name,
-                       mouse->value->absolute ? " (absolute)" : "");
+        monitor_hmp_printf(hmp, "%c Mouse #%" PRId64 ": %s%s\n",
+                           mouse->value->current ? '*' : ' ',
+                           mouse->value->index, mouse->value->name,
+                           mouse->value->absolute ? " (absolute)" : "");
     }
 
     qapi_free_MouseInfoList(mice_list);
@@ -102,48 +101,48 @@ void hmp_info_mice(MonitorHMP *hmp, const QDict *qdict)
 
 #ifdef CONFIG_VNC
 /* Helper for hmp_info_vnc_clients, _servers */
-static void hmp_info_VncBasicInfo(Monitor *mon, VncBasicInfo *info,
+static void hmp_info_VncBasicInfo(MonitorHMP *hmp, VncBasicInfo *info,
                                   const char *name)
 {
-    monitor_printf(mon, "  %s: %s:%s (%s%s)\n",
-                   name,
-                   info->host,
-                   info->service,
-                   NetworkAddressFamily_str(info->family),
-                   info->websocket ? " (Websocket)" : "");
+    monitor_hmp_printf(hmp, "  %s: %s:%s (%s%s)\n",
+                       name,
+                       info->host,
+                       info->service,
+                       NetworkAddressFamily_str(info->family),
+                       info->websocket ? " (Websocket)" : "");
 }
 
 /* Helper displaying and auth and crypt info */
-static void hmp_info_vnc_authcrypt(Monitor *mon, const char *indent,
+static void hmp_info_vnc_authcrypt(MonitorHMP *hmp, const char *indent,
                                    VncPrimaryAuth auth,
                                    VncVencryptSubAuth *vencrypt)
 {
-    monitor_printf(mon, "%sAuth: %s (Sub: %s)\n", indent,
-                   VncPrimaryAuth_str(auth),
-                   vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
+    monitor_hmp_printf(hmp, "%sAuth: %s (Sub: %s)\n", indent,
+                       VncPrimaryAuth_str(auth),
+                       vencrypt ? VncVencryptSubAuth_str(*vencrypt) : "none");
 }
 
-static void hmp_info_vnc_clients(Monitor *mon, VncClientInfoList *client)
+static void hmp_info_vnc_clients(MonitorHMP *hmp, VncClientInfoList *client)
 {
     while (client) {
         VncClientInfo *cinfo = client->value;
 
-        hmp_info_VncBasicInfo(mon, qapi_VncClientInfo_base(cinfo), "Client");
-        monitor_printf(mon, "    x509_dname: %s\n",
-                       cinfo->x509_dname ?: "none");
-        monitor_printf(mon, "    sasl_username: %s\n",
-                       cinfo->sasl_username ?: "none");
+        hmp_info_VncBasicInfo(hmp, qapi_VncClientInfo_base(cinfo), "Client");
+        monitor_hmp_printf(hmp, "    x509_dname: %s\n",
+                           cinfo->x509_dname ?: "none");
+        monitor_hmp_printf(hmp, "    sasl_username: %s\n",
+                           cinfo->sasl_username ?: "none");
 
         client = client->next;
     }
 }
 
-static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
+static void hmp_info_vnc_servers(MonitorHMP *hmp, VncServerInfo2List *server)
 {
     while (server) {
         VncServerInfo2 *sinfo = server->value;
-        hmp_info_VncBasicInfo(mon, qapi_VncServerInfo2_base(sinfo), "Server");
-        hmp_info_vnc_authcrypt(mon, "    ", sinfo->auth,
+        hmp_info_VncBasicInfo(hmp, qapi_VncServerInfo2_base(sinfo), "Server");
+        hmp_info_vnc_authcrypt(hmp, "    ", sinfo->auth,
                                sinfo->has_vencrypt ? &sinfo->vencrypt : NULL);
         server = server->next;
     }
@@ -151,7 +150,6 @@ static void hmp_info_vnc_servers(Monitor *mon, VncServerInfo2List *server)
 
 void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     VncInfo2List *info2l, *info2l_head;
     Error *err = NULL;
 
@@ -161,26 +159,26 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
         return;
     }
     if (!info2l) {
-        monitor_printf(mon, "None\n");
+        monitor_hmp_printf(hmp, "None\n");
         return;
     }
 
     while (info2l) {
         VncInfo2 *info = info2l->value;
-        monitor_printf(mon, "%s:\n", info->id);
-        hmp_info_vnc_servers(mon, info->server);
-        hmp_info_vnc_clients(mon, info->clients);
+        monitor_hmp_printf(hmp, "%s:\n", info->id);
+        hmp_info_vnc_servers(hmp, info->server);
+        hmp_info_vnc_clients(hmp, info->clients);
         if (!info->server) {
             /*
              * The server entry displays its auth, we only need to
              * display in the case of 'reverse' connections where
              * there's no server.
              */
-            hmp_info_vnc_authcrypt(mon, "  ", info->auth,
+            hmp_info_vnc_authcrypt(hmp, "  ", info->auth,
                                info->has_vencrypt ? &info->vencrypt : NULL);
         }
         if (info->display) {
-            monitor_printf(mon, "  Display: %s\n", info->display);
+            monitor_hmp_printf(hmp, "  Display: %s\n", info->display);
         }
         info2l = info2l->next;
     }
@@ -193,7 +191,6 @@ void hmp_info_vnc(MonitorHMP *hmp, const QDict *qdict)
 #ifdef CONFIG_SPICE
 void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     SpiceChannelList *chan;
     SpiceInfo *info;
     const char *channel_name;
@@ -214,38 +211,38 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
     info = qmp_query_spice(NULL);
 
     if (!info->enabled) {
-        monitor_printf(mon, "Server: disabled\n");
+        monitor_hmp_printf(hmp, "Server: disabled\n");
         goto out;
     }
 
-    monitor_printf(mon, "Server:\n");
+    monitor_hmp_printf(hmp, "Server:\n");
     if (info->has_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 "\n",
-                       info->host, info->port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 "\n",
+                           info->host, info->port);
     }
     if (info->has_tls_port) {
-        monitor_printf(mon, "     address: %s:%" PRId64 " [tls]\n",
-                       info->host, info->tls_port);
+        monitor_hmp_printf(hmp, "     address: %s:%" PRId64 " [tls]\n",
+                           info->host, info->tls_port);
     }
-    monitor_printf(mon, "    migrated: %s\n",
-                   info->migrated ? "true" : "false");
-    monitor_printf(mon, "        auth: %s\n", info->auth);
-    monitor_printf(mon, "    compiled: %s\n", info->compiled_version);
-    monitor_printf(mon, "  mouse-mode: %s\n",
-                   SpiceQueryMouseMode_str(info->mouse_mode));
+    monitor_hmp_printf(hmp, "    migrated: %s\n",
+                       info->migrated ? "true" : "false");
+    monitor_hmp_printf(hmp, "        auth: %s\n", info->auth);
+    monitor_hmp_printf(hmp, "    compiled: %s\n", info->compiled_version);
+    monitor_hmp_printf(hmp, "  mouse-mode: %s\n",
+                       SpiceQueryMouseMode_str(info->mouse_mode));
 
     if (!info->has_channels || info->channels == NULL) {
-        monitor_printf(mon, "Channels: none\n");
+        monitor_hmp_printf(hmp, "Channels: none\n");
     } else {
         for (chan = info->channels; chan; chan = chan->next) {
-            monitor_printf(mon, "Channel:\n");
-            monitor_printf(mon, "     address: %s:%s%s\n",
-                           chan->value->host, chan->value->port,
-                           chan->value->tls ? " [tls]" : "");
-            monitor_printf(mon, "     session: %" PRId64 "\n",
-                           chan->value->connection_id);
-            monitor_printf(mon, "     channel: %" PRId64 ":%" PRId64 "\n",
-                           chan->value->channel_type, chan->value->channel_id);
+            monitor_hmp_printf(hmp, "Channel:\n");
+            monitor_hmp_printf(hmp, "     address: %s:%s%s\n",
+                               chan->value->host, chan->value->port,
+                               chan->value->tls ? " [tls]" : "");
+            monitor_hmp_printf(hmp, "     session: %" PRId64 "\n",
+                               chan->value->connection_id);
+            monitor_hmp_printf(hmp, "     channel: %" PRId64 ":%" PRId64 "\n",
+                               chan->value->channel_type, chan->value->channel_id);
 
             channel_name = "unknown";
             if (chan->value->channel_type > 0 &&
@@ -254,7 +251,7 @@ void hmp_info_spice(MonitorHMP *hmp, const QDict *qdict)
                 channel_name = channel_names[chan->value->channel_type];
             }
 
-            monitor_printf(mon, "     channel name: %s\n", channel_name);
+            monitor_hmp_printf(hmp, "     channel name: %s\n", channel_name);
         }
     }
 
@@ -333,7 +330,7 @@ static void hmp_change_read_arg(void *opaque, const char *password,
     monitor_hmp_read_command(opaque, 1);
 }
 
-void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
+void hmp_change_vnc(MonitorHMP *hmp, const char *device, const char *target,
                     const char *arg, const char *read_only, bool force,
                     Error **errp)
 {
@@ -346,7 +343,6 @@ void hmp_change_vnc(Monitor *mon, const char *device, const char *target,
         return;
     }
     if (!arg) {
-        MonitorHMP *hmp = MONITOR_HMP(mon);
         monitor_hmp_read_password(hmp, hmp_change_read_arg, NULL);
     } else {
         qmp_change_vnc_password(arg, errp);
@@ -371,7 +367,6 @@ static int index_from_key(const char *key, size_t key_length)
 
 void hmp_sendkey(MonitorHMP *hmp, const QDict *qdict)
 {
-    Monitor *mon = MONITOR(hmp);
     const char *keys = qdict_get_str(qdict, "keys");
     KeyValue *v = NULL;
     KeyValueList *head = NULL, **tail = &head;
@@ -432,7 +427,7 @@ out:
     return;
 
 err_out:
-    monitor_printf(mon, "invalid parameter: %.*s\n", keyname_len, keys);
+    monitor_hmp_printf(hmp, "invalid parameter: %.*s\n", keyname_len, keys);
     goto out;
 }
 
diff --git a/util/error-report.c b/util/error-report.c
index 41694d61cf2d..0e3aaa539e78 100644
--- a/util/error-report.c
+++ b/util/error-report.c
@@ -36,7 +36,7 @@ static int G_GNUC_PRINTF(2, 0)
 error_vprintf_hmp(MonitorHMP *hmp, const char *fmt, va_list ap)
 {
     if (hmp) {
-        return monitor_vprintf(MONITOR(hmp), fmt, ap);
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
 
     return vfprintf(stderr, fmt, ap);
diff --git a/util/qemu-print.c b/util/qemu-print.c
index 5d4143d425a1..01ed43b5a588 100644
--- a/util/qemu-print.c
+++ b/util/qemu-print.c
@@ -13,6 +13,7 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
 #include "monitor/hmp.h"
+#include "qom/object.h"
 #include "qemu/qemu-print.h"
 
 /*
@@ -23,8 +24,16 @@
 int qemu_vprintf(const char *fmt, va_list ap)
 {
     Monitor *cur_mon = monitor_cur();
+
+    /* for all monitors: QMP & HMP */
     if (cur_mon) {
-        return monitor_vprintf(cur_mon, fmt, ap);
+        /* don't use monitor_cur_hmp(), to avoid a second lookup */
+        MonitorHMP *hmp = (MonitorHMP *)
+            object_dynamic_cast(OBJECT(cur_mon), TYPE_MONITOR_HMP);
+        if (!hmp) {
+            return -1;
+        }
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vprintf(fmt, ap);
 }
@@ -55,7 +64,11 @@ int qemu_printf(const char *fmt, ...)
 int qemu_vfprintf(FILE *stream, const char *fmt, va_list ap)
 {
     if (!stream) {
-        return monitor_vprintf(monitor_cur(), fmt, ap);
+        MonitorHMP *hmp = monitor_cur_hmp();
+        if (!hmp) {
+            return -1;
+        }
+        return monitor_hmp_vprintf(hmp, fmt, ap);
     }
     return vfprintf(stream, fmt, ap);
 }

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 20:44:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 20:44:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402465.1637574 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03RQ-0004KF-Ic; Fri, 28 Aug 2026 20:44:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402465.1637574; Fri, 28 Aug 2026 20:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x03RQ-0004K8-Fm; Fri, 28 Aug 2026 20:44:48 +0000
Received: by outflank-mailman (input) for mailman id 1402465;
 Fri, 28 Aug 2026 20:44:46 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <marcandre.lureau@redhat.com>) id 1x03RO-0004HR-NP
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 20:44:46 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x03RO-00DUlk-4V
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 22:44:46 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f30e-bab6-0a2a0a5309dd-0a2a4504afd6-48
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:44:46 +0200
Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <marcandre.lureau@redhat.com>)
 id 6a91f33c-b57f-0a2a45040019-aa0a857c5eed-3
 for <xen-devel@lists.xenproject.org>; Fri, 28 Aug 2026 22:44:45 +0200
Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com
 (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by
 relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
 cipher=TLS_AES_256_GCM_SHA384) id us-mta-670-TeuMH2ZtO3ew8EvnX0HPYw-1; Fri,
 28 Aug 2026 16:44:41 -0400
Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com
 (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
 id B60611944F2C; Fri, 28 Aug 2026 20:44:39 +0000 (UTC)
Received: from localhost (headnet04.pony-001.prod.iad2.dc.redhat.com
 [10.2.32.116])
 by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP
 id E99AA1803A40; Fri, 28 Aug 2026 20:44:38 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1787949884;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=O0gilCMcTw5GY6oy+YVwRqReRSTX/SrtxwLMRYrDZVs=;
	b=MCqZVWxZ1sHR0oXJkM+7A/0AzB8ivXw+qBqO9IJe8puQVf3KDLcXWodwsPCDUDO6sN7/NP
	JyqgFUWhg2+iOdTX0Snv+sYv++Kti8kPlMJiEu59KpwAB+O1fVXmIvJ0NnwaUUKJJ9lS3H
	1AGycCoHZjKZ4Q4113tMgu+5Ul2busg=
X-MC-Unique: TeuMH2ZtO3ew8EvnX0HPYw-1
X-Mimecast-MFC-AGG-ID: TeuMH2ZtO3ew8EvnX0HPYw_1787949879
From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>
Date: Sat, 29 Aug 2026 00:42:22 +0400
Subject: [GIT PULL 43/50] hw: guard BusClass::print_dev with CONFIG_HMP
MIME-Version: 1.0
Message-Id: <20260829-nohmp-v1-43-4dcc2b4b0055@redhat.com>
References: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
In-Reply-To: <20260829-nohmp-v1-0-4dcc2b4b0055@redhat.com>
To: qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, Laurent Vivier <lvivier@redhat.com>, 
 Amit Shah <amit@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, 
 =?utf-8?q?Marc-Andr=C3=A9_Lureau?= <marcandre.lureau@redhat.com>, 
 Paolo Bonzini <pbonzini@redhat.com>, 
 =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Anthony PERARD <anthony@xenproject.org>, 
 "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, 
 xen-devel@lists.xenproject.org
X-Developer-Signature: v=1; a=openpgp-sha256; l=9570;
 i=marcandre.lureau@redhat.com; h=from:subject:message-id;
 bh=L3Loi/onUFTsM2fjxBfrKJdXskJwqRvtiYRcMlKMo2w=;
 b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqkfKVd+m32mJrZbVhGLpXFwMRIXrxLaCIEMZQD
 Zj5VnNgz7CJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapHylQAKCRDa6OEJdZac
 5Z2UD/4lT/YcsQpKiBSeaW34Rt6KLiZToHdewe53DXktQz/zLhMbXg0ro/ciVu3giu55hxebadE
 ZUadjNPI6eyfqmjNFIrvT4yC4B31liBIV0uXJvfV9g61SROBkq0uuCs/zdzbQEBJL0RtpQWJCCk
 IJUAf3ISbhmEYdm5sQAODfhQo4504YCsYMGR3ztVgSwmxTziDojBp6asRhq+ti9xRnQ3GHrHLkk
 iMycfc1cbtRG32JK8Lz0BhEiRiDTBnMhuBptseXC8vEItQG3/Mc6YioQqlRCqhvNfLN0TTSRvoj
 XJUB9BL41FrXym+uAAc7Lv5MWW8WIoJ1vUBYaaMHRmxzAIvG4grZ0mcnX3pUN24rdPMn8oSAwWC
 yl/FsCK+ktURtE1ZbeXVn0pj/9srsv+2tds8IAKUoyqRyK+bqhM0XuVPV2ic/kZ1GOF1GCdZJbF
 bElR3nAqEMOR5tEx1UBhdnDjVhglfp6OgO6z8y1T07Xq+sWWmqg3x8OGCmjsYrQhqyl8HW0l+Yr
 oQ6G0zugSfElA60YbY2EFkEtG+IbkRlE11WUcHri8GJOXJyBRY32m01a1cvRqxTI2yF1nZVPJMe
 Ey2nt/p1rD6i9pgAcwmJUIOpKJOyK9Sq1So6n8BZ/CIOsyp+B5/Qnfgv8D90PoeEWQvi1qMbcxM
 smThkRrXYJZPxOQ==
X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp;
 fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111
X-Mimecast-MFC-PROC-ID: GfSW3ag1GCYT3_AYK_iNdIyFLR0yKwC01UsE-F2UI8w_1787949879
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ebf023/1787949886-512DCB50-30E7627E/0/0
X-purgate-type: clean
X-purgate-size: 9572

The print_dev callback is only used by HMP 'info qtree'. Guard the field
in BusClass, all implementations, and the caller with CONFIG_HMP.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-43-9227de146347@redhat.com>
---
 hw/char/virtio-serial-bus.c |  6 ++++++
 hw/core/sysbus.c            |  6 ++++++
 hw/misc/auxbus.c            | 16 +++++++++++-----
 hw/pci/pci-hmp-cmds.c       |  2 ++
 hw/pci/pci.c                |  2 ++
 hw/usb/bus.c                |  6 ++++++
 hw/xen/xen-bus.c            |  4 ++++
 include/hw/core/qdev.h      |  2 ++
 8 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 4dcc4516e45e..83a033ce8555 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -814,7 +814,9 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
@@ -823,8 +825,10 @@ static const Property virtser_props[] = {
 
 static void virtser_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
     k->print_dev = virtser_bus_dev_print;
+#endif
 }
 
 static const TypeInfo virtser_bus_info = {
@@ -834,6 +838,7 @@ static const TypeInfo virtser_bus_info = {
     .class_init = virtser_bus_class_init,
 };
 
+#ifdef CONFIG_HMP
 static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev);
@@ -844,6 +849,7 @@ static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent
                        port->host_connected ? "on" : "off",
                        port->throttled ? "on" : "off");
 }
+#endif
 
 /* This function is only used if a port id is not provided by the user */
 static uint32_t find_free_port_id(VirtIOSerial *vser)
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 31c4fdf79d48..fe8f867a8d9c 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -24,7 +24,9 @@
 #include "monitor/hmp.h"
 #include "system/address-spaces.h"
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static char *sysbus_get_fw_dev_path(DeviceState *dev);
 
 typedef struct SysBusFind {
@@ -76,7 +78,9 @@ static void system_bus_class_init(ObjectClass *klass, const void *data)
 {
     BusClass *k = BUS_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = sysbus_dev_print;
+#endif
     k->get_fw_dev_path = sysbus_get_fw_dev_path;
 }
 
@@ -249,6 +253,7 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp)
     return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp);
 }
 
+#ifdef CONFIG_HMP
 static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     SysBusDevice *s = SYS_BUS_DEVICE(dev);
@@ -261,6 +266,7 @@ static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            indent, "", s->mmio[i].addr, size);
     }
 }
+#endif
 
 static char *sysbus_get_fw_dev_path(DeviceState *dev)
 {
diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c
index 0bb89c5a60ab..3f17784d9b8a 100644
--- a/hw/misc/auxbus.c
+++ b/hw/misc/auxbus.c
@@ -47,18 +47,22 @@
 } while (0)
 
 
+#ifdef CONFIG_HMP
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent);
+#endif
 static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge);
 
 /* aux-bus implementation (internal not public) */
 static void aux_bus_class_init(ObjectClass *klass, const void *data)
 {
+#ifdef CONFIG_HMP
     BusClass *k = BUS_CLASS(klass);
 
     /* AUXSlave has an MMIO so we need to change the way we print information
      * in monitor.
      */
     k->print_dev = aux_slave_dev_print;
+#endif
 }
 
 AUXBus *aux_bus_init(DeviceState *parent, const char *name)
@@ -91,11 +95,6 @@ void aux_map_slave(AUXSlave *aux_dev, hwaddr addr)
     memory_region_add_subregion(bus->aux_io, addr, aux_dev->mmio);
 }
 
-static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
-{
-    return (dev == DEVICE(bus->bridge));
-}
-
 I2CBus *aux_get_i2c_bus(AUXBus *bus)
 {
     return aux_bridge_get_i2c_bus(bus->bridge);
@@ -288,6 +287,12 @@ static const TypeInfo aux_to_i2c_type_info = {
 };
 
 /* aux-slave implementation */
+#ifdef CONFIG_HMP
+static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev)
+{
+    return (dev == DEVICE(bus->bridge));
+}
+
 static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev));
@@ -305,6 +310,7 @@ static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                        object_property_get_uint(OBJECT(s->mmio), "addr", NULL),
                        memory_region_size(s->mmio));
 }
+#endif
 
 void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio)
 {
diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c
index bcccfaf07f4d..879011da1384 100644
--- a/hw/pci/pci-hmp-cmds.c
+++ b/hw/pci/pci-hmp-cmds.c
@@ -135,6 +135,7 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict)
     qapi_free_PciInfoList(info_list);
 }
 
+#ifdef CONFIG_HMP
 void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     PCIDevice *d = (PCIDevice *)dev;
@@ -170,6 +171,7 @@ void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent)
                            r->addr, r->addr + r->size - 1);
     }
 }
+#endif
 
 void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict)
 {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index e8e8a3b76714..c15f2b9f084a 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -293,7 +293,9 @@ static void pci_bus_class_init(ObjectClass *klass, const void *data)
     ResettableClass *rc = RESETTABLE_CLASS(klass);
     FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = pcibus_dev_print;
+#endif
     k->get_dev_path = pcibus_get_dev_path;
     k->get_fw_dev_path = pcibus_get_fw_dev_path;
     k->realize = pci_bus_realize;
diff --git a/hw/usb/bus.c b/hw/usb/bus.c
index 8bd25a9d872a..5cc5ffec33a1 100644
--- a/hw/usb/bus.c
+++ b/hw/usb/bus.c
@@ -13,7 +13,9 @@
 #include "trace.h"
 #include "qemu/cutils.h"
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent);
+#endif
 
 static char *usb_get_dev_path(DeviceState *dev);
 static char *usb_get_fw_dev_path(DeviceState *qdev);
@@ -32,7 +34,9 @@ static void usb_bus_class_init(ObjectClass *klass, const void *data)
     BusClass *k = BUS_CLASS(klass);
     HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
 
+#ifdef CONFIG_HMP
     k->print_dev = usb_bus_dev_print;
+#endif
     k->get_dev_path = usb_get_dev_path;
     k->get_fw_dev_path = usb_get_fw_dev_path;
     hc->unplug = qdev_simple_device_unplug_cb;
@@ -544,6 +548,7 @@ static const char *usb_speed(unsigned int speed)
     return txt[speed];
 }
 
+#ifdef CONFIG_HMP
 static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
 {
     USBDevice *dev = USB_DEVICE(qdev);
@@ -555,6 +560,7 @@ static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent)
                        usb_speed(dev->speed), dev->product_desc,
                        dev->attached ? ", attached" : "");
 }
+#endif
 
 static char *usb_get_dev_path(DeviceState *qdev)
 {
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index b81a067e7753..1762816bf469 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -101,6 +101,7 @@ abort:
     qemu_xen_xs_transaction_end(xenbus->xsh, tid, true);
 }
 
+#ifdef CONFIG_HMP
 static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
 {
     XenDevice *xendev = XEN_DEVICE(dev);
@@ -108,6 +109,7 @@ static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent)
     monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n",
                        indent, "", xendev->name, xendev->frontend_id);
 }
+#endif
 
 static char *xen_bus_get_dev_path(DeviceState *dev)
 {
@@ -386,7 +388,9 @@ static void xen_bus_class_init(ObjectClass *class, const void *data)
     BusClass *bus_class = BUS_CLASS(class);
     HotplugHandlerClass *hotplug_class = HOTPLUG_HANDLER_CLASS(class);
 
+#ifdef CONFIG_HMP
     bus_class->print_dev = xen_bus_print_dev;
+#endif
     bus_class->get_dev_path = xen_bus_get_dev_path;
     bus_class->realize = xen_bus_realize;
     bus_class->unrealize = xen_bus_unrealize;
diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h
index 1391dc060caf..f054a214fc6a 100644
--- a/include/hw/core/qdev.h
+++ b/include/hw/core/qdev.h
@@ -323,8 +323,10 @@ DECLARE_OBJ_CHECKERS(BusState, BusClass,
 struct BusClass {
     ObjectClass parent_class;
 
+#ifdef CONFIG_HMP
     /* FIXME first arg should be BusState */
     void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent);
+#endif
     /*
      * Return a newly allocated string containing the path of the
      * device on this bus.

-- 
2.55.0.543.g5ebe2ebe4ea8



From xen-devel-bounces@lists.xenproject.org Fri Aug 28 23:27:20 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Aug 2026 23:27:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402529.1637582 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x05yT-0000eU-Hr; Fri, 28 Aug 2026 23:27:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402529.1637582; Fri, 28 Aug 2026 23:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x05yT-0000eN-Ee; Fri, 28 Aug 2026 23:27:05 +0000
Received: by outflank-mailman (input) for mailman id 1402529;
 Fri, 28 Aug 2026 23:27:04 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+de67a59a32f6d1ab6349+8405+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 1x05yQ-0000eH-Vv
 for xen-devel@lists.xenproject.org; Fri, 28 Aug 2026 23:27:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x05yO-004VmE-OR; Sat, 29 Aug 2026 01:27:00 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+de67a59a32f6d1ab6349+8405+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a921936-bab6-0a2a0a5309dd-0a2a45068626-8
 for <multiple-recipients>; Sat, 29 Aug 2026 01:27:00 +0200
Received: from [90.155.50.34] (helo=casper.infradead.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+de67a59a32f6d1ab6349+8405+infradead.org+dwmw2@casper.srs.infradead.org>)
 id 6a921943-195a-0a2a45060019-5a9b32229b60-3
 for <multiple-recipients>; Sat, 29 Aug 2026 01:27:00 +0200
Received: from [2001:8b0:10b:5:d89b:13dc:754b:b035]
 (helo=u09cd745991455d.ant.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux))
 id 1x05y6-0000000FbWS-0Tpk; Fri, 28 Aug 2026 23:26:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=0tgNniJFKgy7c4X6zhz8g5nDoCwIew+VzfMrf/A7zv8=; b=Y1ztMb5fee8HrackV7cB8wzPnZ
	3IK5avP+Fq/dyxz7E9egQaZ9iFJ196cBxbBKz5qLBYKYpXdHmhYF9ib5EP8qVU4QNpq9iLaXC255a
	1H9BgcGO2/Yo0I1V+eEsp5XOpmmC3/4I2Fi8mLcq4ZLYkelqHm9NAXrxX5l4MGuxlpkq2MGBDCwDa
	oonR+aOV7TIms7Rxo7kC9t1IRFXK1ZXsRgPppIHAjmYpLFo3qBiqAi/jtZ5K62yBNhICUw8NgXt0k
	BGTb6WowKoJSl3G5GDTdNWTdulkNLtRuSTZfOQO/3j/QiSYXDUHbaywxeoLTVVB+0wgqEiUzoSPCo
	3onFVizw==;
Message-ID: <e93c9edb54af426397ca6282e2f75dbfb0facab4.camel@infradead.org>
Subject: Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for
 accurate KVM clock migration
From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>, 
 Shuah Khan <skhan@linuxfoundation.org>, Thomas Gleixner <tglx@kernel.org>,
 Ingo Molnar <mingo@redhat.com>,  Borislav Petkov	 <bp@alien8.de>, Dave
 Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin"	
 <hpa@zytor.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Juergen Gross	
 <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Paul
 Durrant	 <paul@xen.org>, Jonathan Cameron <jic23@kernel.org>, Sascha
 Bischoff	 <Sascha.Bischoff@arm.com>, Marc Zyngier <maz@kernel.org>, Joey
 Gouly	 <joey.gouly@arm.com>, Jack Allister <jalliste@amazon.com>, Dongli
 Zhang	 <dongli.zhang@oracle.com>, joe.jin@oracle.com, kvm@vger.kernel.org, 
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org
Date: Sat, 29 Aug 2026 00:26:28 +0100
In-Reply-To: <4420099fedce20021d6cc5aeb1aa270c7951c552.camel@infradead.org>
References: <20260728144954.355376-1-dwmw2@infradead.org>
		 <20260728144954.355376-32-dwmw2@infradead.org>
		 <anuy6QxUVLcSSVCn@google.com>
	 <4420099fedce20021d6cc5aeb1aa270c7951c552.camel@infradead.org>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-gZIQ/HFPHjw8QZC7Itn1"
User-Agent: Evolution 3.60.3-0ubuntu1~ppa9~24.04 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by casper.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-16d1c6/1787959620-F70C777B-3E7B3968/0/0
X-purgate-type: clean
X-purgate-size: 9469


--=-gZIQ/HFPHjw8QZC7Itn1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2026-08-14 at 08:27 +0100, David Woodhouse wrote:
>=20
> Fixup below (not amending commits while you're co-opting the tree, as
> we'd both go insane). I'll push it to the top of=20
> https://git.infradead.org/?p=3Dusers/dwmw2/linux.git;a=3Dshortlog;h=3Dref=
s/heads/kvmclock9-part2
> on top of with the offset test which is already there.

Since it looks like you are concentrating on part1, I have actually
folded that in now, and rebased on top of your v10 of part1:

https://git.infradead.org/?p=3Dusers/dwmw2/linux.git;a=3Dshortlog;h=3Drefs/=
heads/kvmclock10-part2

A relatively boring rebase, apart from having to bump a CAP number.

Testing now...

--=-gZIQ/HFPHjw8QZC7Itn1
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew
ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz
MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE
AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv
q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z
S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb
Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK
72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA
CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W
mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs
h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a
CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI
GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg
v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG
CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS
b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA
A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU
vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9
0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o
jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks
FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx
HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs
IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg
MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213
MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX
sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD
tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa
EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm
6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo
ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6
bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX
Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO
02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB
sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw
ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT
JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91
LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ
hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT
SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j
c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B
AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr
EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN
ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8
+3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs
+icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT
McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1
LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F
nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s
gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL
Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg
QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa
Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe
YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z
kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG
pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va
v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c
vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW
PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt
REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr
lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq
aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0
D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3
bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC
MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB
oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J
TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv
bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF
BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH
MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB
NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV
BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc
Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv
Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2
JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k
0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w
bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6
ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74
vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o
9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB
c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g
MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0yNjA4MjgyMzI2MjhaMC8GCSqGSIb3DQEJBDEiBCA6bs41Ib/mbbJBP5EayfXWqBaW+crU
NnLV0oB7dvUrDjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln
aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT
SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz
c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw
DQYJKoZIhvcNAQEBBQAEggIAqceJaO9Bl1i3IFKWlyLf/Dxq3JkoOh9XTfEb+1TNEFAAl86bswDH
+7de4Tgxp6YgTkhxgstpc01sxinwrHshr2Ss8XFD9L807BvL1JR6FJ311GmWsmVp1kJ4T7+5a63s
7K2pHEHZPkk3vGo+2RgDY+VgF18E7Za1u5hR2R9SzTzoIBn1pct0PmTvGG/USpkpGC+sQ1zbW+9C
8833ZKxhAHd3lFfmPu3KanvO+VgFbtY8fRxeSBLzlrRQaDHLDftD7mzkBdgkxzckNUym3aZkkREm
wN+vX0tjIqQne8Ae+k2tcDs68c0BBiosJSW0LE+ktn3jgiYRXhMT9Ww6FDuNs9sB7UGO32H1/B3Q
A/tFhq8TBKLmRVfgY4NVd/r4TJTRAQnrS39PAUUp7CImQpNXyfQOzgf9wblQk+ihqf2+CQHCfPRV
O3PYaZzlGh6A6FvXg/+y/2uOtyhluAj2kxCGe6ovKeN696DMMVwQ4H8SgLAU0dOVukRJl4XvKpoc
2srGhwIuwere9X7Y1ltM6NuNsMEIghMKKtHJ9TxuCayw43xEkBDlHfun4GT9gsKRbIuQQOsuE2bB
r+aCzk2H+BJYDP6rQ2Xec3qimm1x2GGmAf2lgH1Z+SYEk3E5hoLqfFLJx221WYOpOpbAVxThqj0B
/Ri50dTqZ1yRvjmEyxjPdqMAAAAAAAA=


--=-gZIQ/HFPHjw8QZC7Itn1--


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 02:13:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 02:13:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402570.1637592 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x08ZH-00031i-Qa; Sat, 29 Aug 2026 02:13:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402570.1637592; Sat, 29 Aug 2026 02:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x08ZH-00031S-LP; Sat, 29 Aug 2026 02:13:15 +0000
Received: by outflank-mailman (input) for mailman id 1402570;
 Sat, 29 Aug 2026 02:13:14 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jan.SetjeEilers@oracle.com>) id 1x08ZG-00031M-9m
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 02:13:14 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x08ZF-00G622-53
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 04:13:13 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a924007-e002-0a2a0a5209dd-0a2a4503b782-20
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 04:13:13 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a924037-fae8-0a2a45030019-cddca5208f62-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 04:13:12 +0200
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67T25XFQ382123; Sat, 29 Aug 2026 02:13:02 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4gbpbar02n-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 02:13:01 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67T22JAZ028134; Sat, 29 Aug 2026 02:13:00 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4gbnvmgggs-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 02:13:00 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67T2D0Ev013633;
 Sat, 29 Aug 2026 02:13:00 GMT
Received: from setje-aarch64-ol9-builds.osdevelopmeniad.oraclevcn.com
 (setje-aarch64-ol9-builds.allregionaliads.osdevelopmeniad.oraclevcn.com
 [100.100.248.24])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4gbnvmgggn-1; Sat, 29 Aug 2026 02:12:59 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=corp-2025-04-25; bh=qF+3gXGiekZSYkCx8LstiKWoFra3C
	VghXhf5TxrLnQ8=; b=HYTRbUtMPT4MQgTn8a3xhWfNUtOMMc0h9pZlMSwx3ezna
	OU5OsTTXowck1jJKKdNdJPhDLe/e9G3MdZ13fPL3gJdR93dQe20zxgCr7NiWgnk5
	sPdPdLCzJVMEssnKPIwdkxdSvbqMsiQ+dPauuGJkTUCLpxOMV5fOW3FmOuA9MD9/
	dt2uGdbhWk4K5Jd5VyMkMbYutHa6bwfuSLGXzmljdP7AH7miA2sDr3+Mvhuhix5e
	IAlG4k3m2AeWhUOqF++RSYYxJndPCf1HeGIpkhhmqiQVw7kyap3bKc2/irSgIKCF
	Wt5+4kepwZiYDP1Yu/B7fH1KJV/SF3e4kz/yavLqA==
From: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Julien Grall <julien@xen.org>,
        Bertrand Marquis <bertrand.marquis@arm.com>,
        Michal Orzel <michal.orzel@amd.com>,
        Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
        Jan Beulich <jbeulich@suse.com>,
        Joao Martins <joao.m.martins@oracle.com>,
        Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [RFC PATCH 0/1] xen/arm: smccc: preserve arguments before register setup
Date: Sat, 29 Aug 2026 02:12:55 +0000
Message-ID: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-29_01,2026-08-27_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 suspectscore=0 malwarescore=0
 spamscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2606160000 definitions=main-2608290015
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI5MDAxNyBTYWx0ZWRfXwkESnBJuJQly
 ZdUm4zPcviLLN5D5pM/CdFZXmKn8Q2YbCaPyReOwhJ3LuH5XXpGCoNrRZ5V153M+sJMWpHMcGwd
 6JE6mKWdU0UmMzhh4XUt/d4Ss01jir8V7lYKf8pbZs9msUDYAQH6
X-Proofpoint-ORIG-GUID: UR_JyuotfNkodCLBPwsVSg6P3WVQa3j6
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI5MDAxNyBTYWx0ZWRfX29h5qklK9cXF
 7JrF1H7t2r07J7PNCjxvTpS6IDF40xSRcBiQdqvqCB7BZohLwDAQb9tY7TJa9+v9XGGDFeBfs4f
 2PwH/B+/DQRT3WmTRETDK8EYEb3k5LeIXyvLW4llKTaddTeD2667pbODXnax/ROqaFN01SVzE8P
 rGsZR0NEz86NDO9wj64Q6XL1foPFoUok/Hqig9GIlrUXgLAv2PLgpF1DJKmPBtMnHi6HvBdSSoa
 WD/50NND+WXtjA2jUqj4uLT9YAV77nSd8HDkd4qrrgwJ8c4BGE+xl0kmifRlw5dm7gEDohtBMwF
 gzGl3XRXzyCqXqUtLAe+Gc86+9WAQZUPmXqaNOksMDWdbcdauOd4sMCNWdP07B1ZKjkfC1TCWbG
 9leGCDAKzqPKPOZp1wv/FfrMgfUvFb9Lcw8jgMhRnoBkfaxUTXiGA+koNHX8x+JpwKlzSeVaTjs
 OKuemaVPW9C7O5sG+0B5XHAEMYgVoSHkYv754p1Y=
X-Authority-Analysis: v=2.4 cv=DMi/JSNb c=1 sm=1 tr=0 ts=6a92402d b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=x0eKOSpe3m1H3M0S9YoZ:22 a=tqg_bQgt9-K5weYeX30A:9 a=5yU3S35YU4bGjq-dph-N:22
 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-GUID: UR_JyuotfNkodCLBPwsVSg6P3WVQa3j6
X-purgate-ID: tlsNG-33051d/1787969592-770F64E9-AD0BBA13/0/0
X-purgate-type: clean
X-purgate-size: 1892

Hi Andrew,

While investigating an SMC forwarding failure after updating to Xen 4.22,
I found that firmware could receive different values from those passed to
arm_smccc_1_1_smc().

Several public Xen callers pass get_user_reg() calls directly to this
helper.  This includes the SCMI, ZynqMP EEMI, and i.MX forwarding paths.
The helper puts each value into its SMC argument register as the
expression is evaluated.  A later get_user_reg() call can then overwrite a
register prepared for an earlier argument.

The change in generated code appears after:

67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations")

I am not sure which behavior the helper is intended to provide. Should
arm_smccc_1_1_smc() continue to accept arguments such as get_user_reg()
calls, or should callers save those values in local variables first?

The attached patch is a candidate for the first option. It restores
temporary variables inside the helper, allowing all calls to finish before
x0-x7 are prepared for the SMC instruction. I am not able to validate the
public SCMI and ZynqMP paths on hardware, but their generated code now
finishes every get_user_reg() call before the final register setup and
smc. With this change, SMCs also work as intended on the device I'm
using.

If the intent is not to accept function calls as arguments, we should
probably fix the SCMI, ZynqMP EEMI, and i.MX callers.

Given the existing use cases, this seems like a bug, but your patch looks
intentional. It's very possible I'm missing the intended design. I would
appreciate your view on the intended contract.

Thanks for any advice or help with this.

Jan Setje-Eilers (1):
  xen/arm: smccc: preserve arguments before register setup

 xen/arch/arm/include/asm/smccc.h | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

-- 
2.47.3


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 02:13:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 02:13:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402571.1637600 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x08ZP-0003Ew-2u; Sat, 29 Aug 2026 02:13:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402571.1637600; Sat, 29 Aug 2026 02:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x08ZP-0003Ep-0A; Sat, 29 Aug 2026 02:13:23 +0000
Received: by outflank-mailman (input) for mailman id 1402571;
 Sat, 29 Aug 2026 02:13:21 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jan.SetjeEilers@oracle.com>) id 1x08ZN-0003ES-KH
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 02:13:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x08ZM-00BlBR-Gc
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 04:13:20 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a923fd5-2eae-0a2a0a5409dd-0a2a450ca416-36
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 04:13:20 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a92403e-f479-0a2a450c0019-cddca520b78a-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 04:13:20 +0200
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67T2A1mf389496; Sat, 29 Aug 2026 02:13:06 GMT
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.appoci.oracle.com [147.154.18.20])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4gbpbar02q-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 02:13:05 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67T22JER028154; Sat, 29 Aug 2026 02:13:04 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4gbnvmgghk-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 02:13:04 +0000 (GMT)
Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67T2D0Ex013633;
 Sat, 29 Aug 2026 02:13:04 GMT
Received: from setje-aarch64-ol9-builds.osdevelopmeniad.oraclevcn.com
 (setje-aarch64-ol9-builds.allregionaliads.osdevelopmeniad.oraclevcn.com
 [100.100.248.24])
 by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id
 4gbnvmgggn-2; Sat, 29 Aug 2026 02:13:04 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=rb5Ul
	RZBuyNBkOiWOQDXJQblEyMkdYvtbNX049BzWC0=; b=HcZ9Dj7ypmEJzO6fWJkpW
	JiSyqdg8CGoVmqiX/QtyTr+JDDJWaBkNtjkhfwlug/G6WAJC0kNR1OsZwcyP5aDt
	PcmWLSWxekPuISBUovUUF6TdT+O3ZhAn/ynnEgHIA4JQiFYDQOYkqlN/ooA/q7Wj
	76hvaFZ9H8eXNK9JoVfsEimepcVnOHWqFX14HfFsNmSQN7Y5xWPa4cs/sM4WR6+7
	dPU/UhBPN8AcG1RZCajaQ4r4kCUp/Wd79o99gSoqDXapptVEl1sTJ6PT6C0BpggZ
	EXbAQ7VLnbbNJX7+1P0B54Ok5vXN2K9cmI1jTOJ5GyAYJr4786Fix5YSliypJYA5
	Q==
From: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Julien Grall <julien@xen.org>,
        Bertrand Marquis <bertrand.marquis@arm.com>,
        Michal Orzel <michal.orzel@amd.com>,
        Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
        Jan Beulich <jbeulich@suse.com>,
        Joao Martins <joao.m.martins@oracle.com>,
        Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [RFC PATCH 1/1] xen/arm: smccc: preserve arguments before register setup
Date: Sat, 29 Aug 2026 02:12:56 +0000
Message-ID: <20260829021257.3310112-2-Jan.SetjeEilers@oracle.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
References: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-29_01,2026-08-27_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0
 bulkscore=0 mlxlogscore=978 lowpriorityscore=0 suspectscore=0 malwarescore=0
 spamscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2606160000 definitions=main-2608290015
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI5MDAxNyBTYWx0ZWRfX3KW6cElt9A6K
 xUDLhI9SFwekAgpUmCCfSj0m7vdVeCOf0ZtQMKELMGSTvEHPCiw6sun5s9ER4Ibo7AcvAWAmftt
 lGzXfki8GTdCeph9ufnuyAuIeq8uvYEVDSg7vLdO/7coK8oWD1SK
X-Proofpoint-ORIG-GUID: FGMoogbrzpaAlnsrNqh5FY-3d9YN49Gi
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI5MDAxNyBTYWx0ZWRfX0xNJ2krWRnt6
 /OEgD4exTlkJumvdRgLsAmxYJomH/UnDHLAbjmTL5Fzctp+ANKop4rW1fbkBDhds5MpOz1eXaxo
 a+stN1MD/ZscSyL4M65HgGJkCWFlZGcTpJMG1TPBibe9FSfwfzDsMyVN94QVXip4U9Sn5aUkYed
 EeqlipHWK4WbDjy0PbPNyrJJ8giTsgSOqA5CDsUdoDigu1x9YHAkVVVcopTMkcA3s3SdulbThqd
 yPHhXwSR/hyKTHxinmaaHuA/ssKvsJ+sUiBkZZqpOsRXMRyY3S21/mHiTE8PkVXEO87zBcs0YiE
 lp/Gi4XviLdAQnGUOJU5fFq5jvnk81J0dVoQd2MuJPW/vEcsxxZ3axHx/0ESt2/S38fPj/qsefi
 Xk+lbHh2a9B+fr9zoXfVmoNoZMFzCCJtqsfWw2iFnnnyBYVTCgQhgR4rk0sRoTy3TuVEvflzcw6
 8IPJFlPnsTcf3BDX3XmTQyZWof+kKVddNyICQkaA=
X-Authority-Analysis: v=2.4 cv=DMi/JSNb c=1 sm=1 tr=0 ts=6a924032 b=1 cx=c_pps
 a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=x0eKOSpe3m1H3M0S9YoZ:22 a=yPCof4ZbAAAA:8 a=wusNpQs0DAacjZ9UpgIA:9
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:13521
X-Proofpoint-GUID: FGMoogbrzpaAlnsrNqh5FY-3d9YN49Gi
X-purgate-ID: tlsNG-d25034/1787969600-010C9A5B-15A0C065/0/0
X-purgate-type: clean
X-purgate-size: 3908

Some callers of arm_smccc_1_1_smc() pass get_user_reg() calls as
arguments. These include the SCMI, ZynqMP EEMI, and i.MX forwarding
paths.

The argument macros currently put each value into its SMC register as
the expression is evaluated. A later function call can overwrite a
register prepared for an earlier argument. Firmware then receives the
wrong values.

Restore temporary variables for a1-a7. Because the macros are nested,
this lets every function call finish before x0-x7 are prepared for the
SMC instruction. It also keeps the inferred type of each argument.

Fixes: 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations")
Backport: 4.22+
Assisted-by: Codex:GPT-5
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
---
 xen/arch/arm/include/asm/smccc.h | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index 62c6985e73..a153042cc5 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -108,37 +108,49 @@ struct arm_smccc_res {
 #define __constraint_read_6 __constraint_read_5, "r" (arg6)
 #define __constraint_read_7 __constraint_read_6, "r" (arg7)
 
+/*
+ * Save a1-a7 in temporary variables before assigning the SMC argument
+ * registers.  A later argument may call a function and overwrite a register
+ * assigned earlier.
+ */
 #define __declare_arg_0(a0, res)                            \
     struct arm_smccc_res    *___res = (res);                \
     register unsigned long  arg0 ASM_REG(0) = (uint32_t)(a0)
 
 #define __declare_arg_1(a0, a1, res)                        \
+    auto __a1 = (a1);                                       \
     __declare_arg_0(a0, res);                               \
-    register auto           arg1 ASM_REG(1) = (a1)
+    register auto           arg1 ASM_REG(1) = __a1
 
 #define __declare_arg_2(a0, a1, a2, res)                    \
+    auto __a2 = (a2);                                       \
     __declare_arg_1(a0, a1, res);                           \
-    register auto           arg2 ASM_REG(2) = (a2)
+    register auto           arg2 ASM_REG(2) = __a2
 
 #define __declare_arg_3(a0, a1, a2, a3, res)                \
+    auto __a3 = (a3);                                       \
     __declare_arg_2(a0, a1, a2, res);                       \
-    register auto           arg3 ASM_REG(3) = (a3)
+    register auto           arg3 ASM_REG(3) = __a3
 
 #define __declare_arg_4(a0, a1, a2, a3, a4, res)        \
+    auto __a4 = (a4);                                   \
     __declare_arg_3(a0, a1, a2, a3, res);               \
-    register auto           arg4 ASM_REG(4) = (a4)
+    register auto           arg4 ASM_REG(4) = __a4
 
 #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)    \
+    auto __a5 = (a5);                                   \
     __declare_arg_4(a0, a1, a2, a3, a4, res);           \
-    register auto           arg5 ASM_REG(5) = (a5)
+    register auto           arg5 ASM_REG(5) = __a5
 
 #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)    \
+    auto __a6 = (a6);                                        \
     __declare_arg_5(a0, a1, a2, a3, a4, a5, res);           \
-    register auto           arg6 ASM_REG(6) = (a6)
+    register auto           arg6 ASM_REG(6) = __a6
 
 #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)    \
+    auto __a7 = (a7);                                            \
     __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);           \
-    register auto           arg7 ASM_REG(7) = (a7)
+    register auto           arg7 ASM_REG(7) = __a7
 
 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
 #define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sat Aug 29 05:06:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 05:06:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402609.1637611 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0BGx-0006Yz-SS; Sat, 29 Aug 2026 05:06:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402609.1637611; Sat, 29 Aug 2026 05:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0BGx-0006Ys-Oe; Sat, 29 Aug 2026 05:06:31 +0000
Received: by outflank-mailman (input) for mailman id 1402609;
 Sat, 29 Aug 2026 05:06:30 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jan.SetjeEilers@oracle.com>) id 1x0BGw-0006Ym-CI
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 05:06:30 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0BGv-003pTI-Pb
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 07:06:29 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a92688f-8faa-0a2a0a5109dd-0a2a450a82a0-40
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 07:06:29 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a9268d3-f2d2-0a2a450a0019-cddca520b722-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 07:06:29 +0200
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67T4neTt645119; Sat, 29 Aug 2026 05:06:16 GMT
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.appoci.oracle.com [147.154.114.232])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4gbpbar28g-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 05:06:16 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67T540CG035601; Sat, 29 Aug 2026 05:06:15 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 4gbnvbaw2p-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 05:06:15 +0000 (GMT)
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67T56Fs9001517;
 Sat, 29 Aug 2026 05:06:15 GMT
Received: from setje-aarch64-ol9-builds.osdevelopmeniad.oraclevcn.com
 (setje-aarch64-ol9-builds.allregionaliads.osdevelopmeniad.oraclevcn.com
 [100.100.248.24])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id
 4gbnvbaw2h-1; Sat, 29 Aug 2026 05:06:15 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:Message-ID:MIME-Version:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:message-id:mime-version
	:subject:to; s=corp-2025-04-25; bh=NKXDRSaJyv0PFAxOBaUHOSBkU6qh2
	+RSMwCCKcwoUUE=; b=gMiqcuuRaHDU8Gk6kx3Ef2mNGwQK2/r7+3lvRdVPvz4z4
	2ijDR5KoJC/3Blsa6YmQxTm0sU86kw4DtZOkP8kMahTQh8+ef3lVcLQXaK05hUrx
	fGk4T1xzMgeAKvpKiLQvl6WKvmx3slZnJSHkgPQA12XhAG7Ze3efStokSCoIq1Jz
	d3vCA+MwRoHIbeVaw18b4mdxfniIFOrsRm72p6m4LveQYMeEF5Qy3gxo/BZuxpvK
	twAGkLQfoMWr56x9QJNp06Nfshvzm1jy911oa1Zyc+4yYMv+d8SCWu/6JLSkHnfr
	+JUkZM5GruNnYfwx+I1isLDvUlwxTAqzGw7hg7yUQ==
From: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
To: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>,
        xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
        Anthony PERARD <anthony.perard@vates.tech>,
        Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
        Julien Grall <julien@xen.org>,
        =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Bertrand Marquis <bertrand.marquis@arm.com>,
        Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [RFC PATCH 0/1] static-memory: allow skipping the cache flush
Date: Sat, 29 Aug 2026 05:06:10 +0000
Message-ID: <20260829050611.3353566-1-Jan.SetjeEilers@oracle.com>
X-Mailer: git-send-email 2.47.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-29_01,2026-08-27_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999
 mlxscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 bulkscore=0
 malwarescore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2606160000 definitions=main-2608290041
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI5MDA0MSBTYWx0ZWRfX6cuRJJuzM/DA
 vXj5+3tWskOizMvKbhKxCt1Q6nnukXFtPQLxUjHznYSYd197vtpIvDp/Nd7uBhU2k253fbnr7//
 Cm489OTgUxEvsVAIW3gJ0Vm0BNYd3JXoWj/BavbHZ692svmVYQNY
X-Proofpoint-ORIG-GUID: IAyx5194Bpxqyo55PCMi5aJkJzMhsBw-
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI5MDA0MSBTYWx0ZWRfX8zTWQmgIXn1Q
 PxRXav8onDUPMq8W15Hg5LS0GB5N7VliC1E0UTTBU+P4N6X0dN73/dHWEAGXNLjjV3bHxcIwwUc
 Qd3hTzMYgxbul1NLq85CyhrlGmKnR/p6KDU+gyIN4sj34npYNwbTst8YtuBRSYfceg20HeGepWr
 VppMGbxGxzIVK/GZ+apTeZkTSUJxYbdkY51VJj6iqSOo6FvwJb4cLZS2fvpUbO8Dc1MTqTwSSl6
 Yepp+VlsSZtSswtMKMn4fQNqPwk79rnvppaJH0Z2QqKQ0jBumZs6P5u+BcKeT71UR7xttaV7OqH
 wWB5+uvqwy/zsOlP9f+ET8k3Q5sfoOg3mh0hUseliAemzPJCYDud0JfC5g30d/ofHU+IJW+XDEY
 8fvmeLdUhrclxNhJe+8+v3N1IHb7q0gMjSeeMEXbwgqKpJ9U25gsR1ndBNgbn5Vk7sBF3hagjJa
 rCU3TBW8ebbkTpfW+5g==
X-Authority-Analysis: v=2.4 cv=DMi/JSNb c=1 sm=1 tr=0 ts=6a9268c8 cx=c_pps
 a=OOZaFjgC48PWsiFpTAqLcw==:117 a=OOZaFjgC48PWsiFpTAqLcw==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=x0eKOSpe3m1H3M0S9YoZ:22 a=wMlaycGzNReg4xrbBi8A:9
X-Proofpoint-GUID: IAyx5194Bpxqyo55PCMi5aJkJzMhsBw-
X-purgate-ID: tlsNG-4011c0/1787979989-5A9D9CFC-30881EB8/0/0
X-purgate-type: clean
X-purgate-size: 2445

Hi all,

I would like feedback on whether Xen needs to flush every page in a
dom0less xen,static-mem bank before assigning it to a guest.

Static-memory support is currently enabled only on Arm, where I am using
and testing this change. Its implementation and acquisition path are in
common code, so this RFC is about the generic static-memory path.

The current code cleans and invalidates every page in the bank. This is a
safe default, but walking a large bank can add several seconds to boot even
though Xen only writes the pages used for the guest kernel, initrd, and
device tree.

Here, cleaning refers to cache maintenance, not boot scrubbing. With
bootscrub=1 or the default bootscrub=idle, Xen assigns dom0less static
banks before boot scrubbing starts. The pages are no longer free, so boot
scrubbing does not clear them.

My starting point is that if a platform permits the untouched pages to be
cleared before guest start, the guest cannot depend on their initial
contents. This is a platform policy assumption, not something Xen's boot
scrubbing establishes. Xen already cleans each page it writes during
domain construction.

Would it therefore be reasonable to let a platform skip the full-bank
flush, provided it can also guarantee that the untouched pages are absent
from all caches and that firmware, DMA, EL3 services, and other CPUs do not
write them before guest start?

The attached patch adds a default-on staticmem-cache-flush option.
Specifying no-staticmem-cache-flush opts into the faster path. The normal
flush remains the default, and static shared memory is unaffected.

Are these conditions enough to make the opt-out valid, or is there another
reason the full-bank flush is required?

I am using no-staticmem-cache-flush with bootscrub=0 on a 64-bit Arm
system with two dom0less guests. Both guests boot normally. Skipping the
flush reduced Xen startup from about five seconds to about one second.

Thanks for any advice or help with this.

Jan Setje-Eilers (1):
  static-memory: allow skipping the cache flush

 docs/misc/xen-command-line.pandoc      | 26 ++++++++++++++++++++++++++
 xen/common/device-tree/static-memory.c |  9 ++++++++-
 xen/common/page_alloc.c                |  6 ++++--
 xen/include/xen/mm.h                   |  2 ++
 4 files changed, 40 insertions(+), 3 deletions(-)


base-commit: 79225a0c77e13b693b4d2b903a88289704b79db6
-- 
2.47.3


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 05:08:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 05:08:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402615.1637620 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0BIM-0007H6-7e; Sat, 29 Aug 2026 05:07:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402615.1637620; Sat, 29 Aug 2026 05:07:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0BIM-0007Gy-3H; Sat, 29 Aug 2026 05:07:58 +0000
Received: by outflank-mailman (input) for mailman id 1402615;
 Sat, 29 Aug 2026 05:07:56 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Jan.SetjeEilers@oracle.com>) id 1x0BIK-0007Gc-DD
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 05:07:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0BIJ-00GNLT-Ab
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 07:07:55 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a926906-8faa-0a2a0a5109dd-0a2a4509e760-34
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 07:07:55 +0200
Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Jan.SetjeEilers@oracle.com>)
 id 6a926929-be1a-0a2a45090019-cddca5200b40-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 07:07:54 +0200
Received: from pps.filterd (m0246617.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67T4j77Y024032; Sat, 29 Aug 2026 05:07:43 GMT
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.appoci.oracle.com [147.154.114.232])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4gbqyrr0t3-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 05:07:42 +0000 (GMT)
Received: from pps.filterd
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67T53x0n035474; Sat, 29 Aug 2026 05:07:41 GMT
Received: from pps.reinject (localhost [127.0.0.1])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id
 4gbnvbawh6-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 05:07:41 +0000 (GMT)
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com
 (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
 by pps.reinject (8.18.1.12/8.18.1.12) with ESMTP id 67T56FsB001517;
 Sat, 29 Aug 2026 05:07:41 GMT
Received: from setje-aarch64-ol9-builds.osdevelopmeniad.oraclevcn.com
 (setje-aarch64-ol9-builds.allregionaliads.osdevelopmeniad.oraclevcn.com
 [100.100.248.24])
 by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id
 4gbnvbaw2h-2; Sat, 29 Aug 2026 05:07:41 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:date:from:in-reply-to:message-id
	:mime-version:references:subject:to; s=corp-2025-04-25; bh=oW5UF
	RBVvmLX6waJJvDC7VRRMFdstu+Xd77ISLIKXY0=; b=MA/NCrF+vyWp+yHEkrcWa
	GomxF8CvVRgE10apE1Ze3cNUOPakmhN1r+cbQaZTUK4SP4NpcF3ijeuAW+qZ8TXq
	Na1pUxxP8Jug95OEo3U2rKjXUJayk/4Pt2Hgfm+0stcZOj9x6JO0G5N2ruFibLk7
	gKh0ZwrWzWP/uoyn7eZ5qSTfgRTvvbP1KP7gzlWnZtK2D6DpfxeT/0Tt/8JKx3tN
	9nBXpdqTOXS1ECowyDygIWyAeJ8miINgDecFbAbrsu/026/DkqVuor6pqjvGS30X
	dUPYxUQEe3IF0JamFKyyuT6R8PQCiPvFNgFKE1OabqLC/g2ZRBKocHDQXd4tHqCT
	g==
From: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
To: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>,
        xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
        Anthony PERARD <anthony.perard@vates.tech>,
        Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
        Julien Grall <julien@xen.org>,
        =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= <roger@xenproject.org>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Bertrand Marquis <bertrand.marquis@arm.com>,
        Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [RFC PATCH 1/1] static-memory: allow skipping the cache flush
Date: Sat, 29 Aug 2026 05:06:11 +0000
Message-ID: <20260829050611.3353566-2-Jan.SetjeEilers@oracle.com>
X-Mailer: git-send-email 2.47.3
In-Reply-To: <20260829050611.3353566-1-Jan.SetjeEilers@oracle.com>
References: <20260829050611.3353566-1-Jan.SetjeEilers@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-29_01,2026-08-27_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999
 mlxscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 bulkscore=0
 malwarescore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.19.0-2606160000 definitions=main-2608290041
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI5MDA0MiBTYWx0ZWRfX7kH/mzWCzH/7
 PB9bV8u8p+USg+Nv8wdvNtKt6rxJDTUlXsktgYL3DsaweNV+H5yoveemIbaao8E1+S3Ed0cZ8Dn
 VRjALdWOPE6gHHHmAjfWezLPm9Mj9Orw1JAt1aCaMODJ/mwUq+xalokSMYnIVn/jdyewri3MFgq
 q9V/Zcfn7D1B8ZRznB31XiwbjfF8zAsM2AR4CmBTJnCL3EneUT0O0CPdhqvTGA3JWvf1HCYOJw4
 QHJgRmz3eL2muPJoDMSc8vtmo/2qKXjFc/WTAkruDf/o8NTXfE4CvBRVabN3IUI0HwZiNiO7RXi
 BvwWO45Ekrn4wGJe3TbdYu9vpNdgL+6uCenUAWLOJaho87rKiKbCLYagLKLx8GTx98Dvqg6HCV6
 5a5UejfzKBysNC6nPm0DYuiDO/VoHGACCEE9gvrKfHkhzPAstnoo4nI+Pbx8LwPtLUfl+e1piJZ
 Y2cSHVQDQ2Sji9OvS/A==
X-Proofpoint-ORIG-GUID: JgDE75mghZLD7eF-8FUP-Rt00u3MJRls
X-Authority-Analysis: v=2.4 cv=fbCdDUQF c=1 sm=1 tr=0 ts=6a92691e cx=c_pps
 a=OOZaFjgC48PWsiFpTAqLcw==:117 a=OOZaFjgC48PWsiFpTAqLcw==:17
 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22
 a=7Gl3-_t3PgB9XO-mQDs3:22 a=yPCof4ZbAAAA:8 a=TQ28Xt2rEOyNch8bdtYA:9
X-Proofpoint-GUID: JgDE75mghZLD7eF-8FUP-Rt00u3MJRls
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI5MDA0MiBTYWx0ZWRfXw7lxSff8ipoI
 QuPrCIgOO5eUV7YTLWe6D1uvBha1OEopTfSl6AI7VRfEXC4WYsJlEuT/JBdwaX24obdNM9GqlpC
 4ShqNCidQRu3RuEy/eo/lM946h/JOI5IZ9zPUv8HsL/U6lHpvCw5
X-purgate-ID: tlsNG-bad1c0/1787980075-FC817034-F07CCC95/0/0
X-purgate-type: clean
X-purgate-size: 6323

Static memory acquisition follows the same cache-coherency policy as
ordinary heap allocation. Xen therefore cleans and invalidates every page
in each xen,static-mem bank before assigning it to a domain.

Static-memory support is currently enabled only on Arm, but its
implementation and this acquisition path are in common code.

This cache maintenance is independent of boot scrubbing, which clears
memory. With bootscrub=1 or the default bootscrub=idle, create_domUs()
acquires static banks before heap_init_late() starts boot scrubbing. The
pages are in-use by then, while boot scrubbing processes only free pages.
Neither mode therefore clears an assigned static bank.

Walking a large static bank can add several seconds to boot, including time
spent flushing pages Xen does not touch during domain construction.

If a platform permits those untouched pages to be cleared before guest
start, the guest cannot depend on their incoming contents. This is a
platform policy assumption, not a property established by Xen's boot
scrubbing. Xen need not make that initial data coherent with RAM. Xen still
cleans every page it writes while loading the guest kernel, initrd, and
device tree.

Add the default-on staticmem-cache-flush option. Specifying
no-staticmem-cache-flush passes MEMF_no_cache_flush when acquiring a
xen,static-mem bank. The existing behavior remains the default, and static
shared memory is unaffected.

Skipping the flush is safe only if the platform also guarantees that the
untouched pages are absent from all caches and no other agent writes them
before guest start. Such agents include firmware, non-coherent DMA, and
EL3 runtime services.

Assisted-by: Codex:GPT-5
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
---
 docs/misc/xen-command-line.pandoc      | 26 ++++++++++++++++++++++++++
 xen/common/device-tree/static-memory.c |  9 ++++++++-
 xen/common/page_alloc.c                |  6 ++++--
 xen/include/xen/mm.h                   |  2 ++
 4 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 1c711fa980..3f5c27858c 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2647,6 +2647,32 @@ On Sappire and Emerald Rapids CPUs with May 2025 microcode or later, the
 `ibpb-alt=` option can be used to switch to the alternative mitigation for
 Intel SA-00982.  Intel suggest that some workloads will benefit from this.
 
+### staticmem-cache-flush (arm)
+> `= <boolean>`
+
+> Default: `true`
+
+Control the up-front per-page cache flush over dom0less `xen,static-mem`
+banks. Specify `no-staticmem-cache-flush` to skip it. Xen still cleans the
+guest kernel, initrd, and device tree pages it writes to guest RAM.
+
+Static-memory support is currently available only on Arm. Its implementation
+and this option live in common code.
+
+Here, cleaning means cache maintenance, not boot scrubbing. With
+`bootscrub=1` or the default `bootscrub=idle`, Xen assigns dom0less static
+banks before boot scrubbing starts. Assigned pages are no longer free, so
+boot scrubbing does not clear them. This option is therefore independent of
+`bootscrub`.
+
+Only disable this flush when the guest does not depend on the initial contents
+of pages Xen leaves untouched. For example, this may be true when the platform
+permits those pages to be cleared before guest start.
+
+The platform must also ensure that those pages are absent from all caches and
+rule out other writers before guest start. Such writers may include
+non-coherent DMA or EL3 runtime services active during domain construction.
+
 ### sync_console
 > `= <boolean>`
 
diff --git a/xen/common/device-tree/static-memory.c b/xen/common/device-tree/static-memory.c
index ffbc12aa24..ed155d162d 100644
--- a/xen/common/device-tree/static-memory.c
+++ b/xen/common/device-tree/static-memory.c
@@ -1,10 +1,15 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include <xen/init.h>
+#include <xen/param.h>
 #include <xen/sched.h>
 #include <xen/static-memory.h>
 
 #include <asm/setup.h>
 
+static bool __initdata opt_staticmem_cache_flush = true;
+boolean_param("staticmem-cache-flush", opt_staticmem_cache_flush);
+
 static bool __init append_static_memory_to_bank(struct domain *d,
                                                 struct membank *bank,
                                                 mfn_t smfn,
@@ -54,7 +59,9 @@ static mfn_t __init acquire_static_memory_bank(struct domain *d,
     }
 
     smfn = maddr_to_mfn(*pbase);
-    res = acquire_domstatic_pages(d, smfn, PFN_DOWN(*psize), 0);
+    res = acquire_domstatic_pages(d, smfn, PFN_DOWN(*psize),
+                                  opt_staticmem_cache_flush ? 0 :
+                                  MEMF_no_cache_flush);
     if ( res )
     {
         printk(XENLOG_ERR
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1e47f38721..b2ede17bd2 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -3094,8 +3094,10 @@ static struct page_info * __init acquire_staticmem_pages(mfn_t smfn,
      * Ensure cache and RAM are consistent for platforms where the guest
      * can control its own visibility of/through the cache.
      */
-    for ( i = 0; i < nr_mfns; i++ )
-        flush_page_to_ram(mfn_x(smfn) + i, !(memflags & MEMF_no_icache_flush));
+    if ( !(memflags & MEMF_no_cache_flush) )
+        for ( i = 0; i < nr_mfns; i++ )
+            flush_page_to_ram(mfn_x(smfn) + i,
+                              !(memflags & MEMF_no_icache_flush));
 
     return pg;
 }
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index fd8b0ba3f5..511bbc56e0 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -228,6 +228,8 @@ struct npfec {
 #define  MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush)
 #define _MEMF_no_scrub    8
 #define  MEMF_no_scrub    (1U<<_MEMF_no_scrub)
+#define _MEMF_no_cache_flush 9
+#define  MEMF_no_cache_flush (1U<<_MEMF_no_cache_flush)
 #define _MEMF_node        16
 #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
 #define  MEMF_node(n)     ((((n) + 1) & MEMF_node_mask) << _MEMF_node)
-- 
2.47.3



From xen-devel-bounces@lists.xenproject.org Sat Aug 29 05:25:43 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 05:25:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402625.1637628 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0BZP-0002D5-LE; Sat, 29 Aug 2026 05:25:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402625.1637628; Sat, 29 Aug 2026 05:25:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0BZP-0002Cy-I4; Sat, 29 Aug 2026 05:25:35 +0000
Received: by outflank-mailman (input) for mailman id 1402625;
 Sat, 29 Aug 2026 05:25:34 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Sergiy_Kibrik@epam.com>) id 1x0BZO-0002Cs-Jt
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 05:25:34 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0BZN-00C3Vx-AH
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 07:25:33 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a926d04-8faa-0a2a0a5109dd-0a2a450ca2ac-22
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 07:25:33 +0200
Received: from [40.107.159.86]
 (helo=OSPPR02CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a926d4c-f479-0a2a450c0019-286b9f56e4e0-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 07:25:33 +0200
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AS8PR03MB9141.eurprd03.prod.outlook.com (2603:10a6:20b:5b4::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Sat, 29 Aug
 2026 05:25:29 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0360.008; Sat, 29 Aug 2026
 05:25:29 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=URMwO7PZ6lnRT77zMgrf7E94O0mLZ33vyk8hyCn+2KzLhrarUTa6xnhXCZ4wQiUSC+s+9+hFnRClpE/dkvL/uRplk+wnDXYfjqt7dilv/E3yPcIJtJiCBCODrRel5VM9OIRAuj5oEPgmXsftne+f1MW3mI5AZhv+uaZGaQ8kifeHyzU+K1ib8hI62pO8zGVim1/Ham3ophpImlpdpRDBKkIl0Wt1DUvGId0s8RWSwlLHa7ze2aW3vkAdpb/odTjijGibKeHNKDc7Qb4Djs2gpQkXvI+CeNO+PqDPqhzt+ZNn2VuEIBsgV1lKKm74aEMzgGF05M5hHPvnwHNQlLbQqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SHySOglTQQblm+/wqUboCywaasdOcIjCnXEuaaSMMXI=;
 b=VOzio4b4vUj3CltBt/225EOWpXFB9HQphYrlJrAnRVzxCYDax6mdqE2ONmGwQVuVYcJlTOLvfmBnYyCDI56ctfJ/1/fPqynTi75tyCTmjczclTErfeJ2XUMNfGcI+YVWBiHiYB+QeocwJnCJEPjffo+06I2BdAKDobvPFSwQqZmcVewBu/OZYxSSValsAMRKRHy1tJ0GS4qcI6PTiBifht7erWh6h5KDh69AkWcaounSHXtMnVbRTnBD1MhB+z43oS4C9zOrbJxY+T0y2/hBL7aRsObGivgqQ+CTFL/rORucQUYgVCphDW7BzMq1iMRev0zKdIt0N/xp5FAiG8mWbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SHySOglTQQblm+/wqUboCywaasdOcIjCnXEuaaSMMXI=;
 b=Aze7H5Ta9cjI2roRjtX/5akOsyQMpYM22VFnVEN4pKxomQJeWN7A/DkO4etqXSGA9OFefln+2QCcBVMW+eo4flqSI2vIxDbdMaxt2kCYu95t1kffqWXJcHRP87A1Ge/zY6hqTyi7L2eNWBqJZEOXOX3Ep3DqYxd595x0pyHhTns+vyfG9UY6Cd5TcCeRpnTOPH1KbhVHGMV3Bvcro9P3u+B7wDr9T/pcnyimbLFGXztl7xXM3ys8Iaqg/VNUQJvpceeT8dZis9++war74imfCO5Hx6DJ00U+svNAQx4DDV+K7rW0JsXjy3IY5akoBAtCdCTdatqSMaLj+ZNSSo5K8A==
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
CC: Sergiy Kibrik <Sergiy_Kibrik@epam.com>, "Daniel P. Smith"
	<dpsmith@apertussolutions.com>
Subject: [PATCH v1] xen/xsm: flask: restore sidtab state on policy load
 failure
Thread-Topic: [PATCH v1] xen/xsm: flask: restore sidtab state on policy load
 failure
Thread-Index: AQHdN3bNfFShEBvmK0m4+E/2G7r3aQ==
Date: Sat, 29 Aug 2026 05:25:28 +0000
Message-ID: <20260829052527.678306-1-Sergiy_Kibrik@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|AS8PR03MB9141:EE_
x-ms-office365-filtering-correlation-id: 3a004a85-3f9b-48c3-713b-08df058df04c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|18002099003|56012099006|38070700021|11063799006|10067099003;
x-microsoft-antispam-message-info:
 bJ69mvn5oXk20ee2aN/+FDSa9zP+0VU6zEWhJyiiKUPGJbtT5l6+P+ky7pHvQM5T1efLmzUFW8aAAm4WagWkkMQrCTN54kt8huLs6Ol4GzLasRVQamr1EpCsLpL0+6fdV3ORMM+v1n+A/tLZCrJofESCr1fZ0cNLOvoJDNeyOX/V3u9yy4wbnayKg/RO/ofgcYkz4cqH0K+dQyDy5isTPxM4CdmtOcqeSFOepSiPUXstP6RQ+/8iCbMq0t4jbBMEJJEza2+IOdnS/kwyTTERAKTGPslDZMjguWOs8qXZNs1Tl2hDatWSiW+JGVjbVSaREw/4yPoveReveTtCMyE7lj4Z4JZaowzN83DzpLOyUkMaFu6m1zgRDubG3aP1pA8nMlt5Dn1o9Bp5+y3p3LWobKvHOkZyeUV1tzqP+L8X//hqGGVOm9a/DeFX1btG+o1esem2fJN1eanhRpjkeCIOExo4TGH58fJYAgq6IyvEKA3XUIynmomlcD0kLQfDBOmQ9214n3SIe0vTO7hIkTLgDvZL/BhWo6a5CTk7f+Q/W6hmkT/5iawio1d3xusifYfHWB1C1v9iEJvfKsxLzMxFiUNbGNEp+9spTbQFmCMCetUpvvP3MwI3ayG5H69/Xhv5n7v7YD13RDYi1CY1zh+IVVlDgudbowu2BhhKxu9x+jICy+jnLl2Mzg+H2QRougOpJGnXEJ5k9/lSD8ieXViMmfGPNxoAiMju4O0NSaFfFsg=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(18002099003)(56012099006)(38070700021)(11063799006)(10067099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Z1qU6kruMtp2u3TvM4wxOBFPxr+IMD72HiH5SGjmgSa6nKDgxkwcM+9Xe1?=
 =?iso-8859-1?Q?DXSeTSkn1fQkQIE7n7gct5ktcZXbBixcZomCtvnvV/k84MNvM4+QAAfmn6?=
 =?iso-8859-1?Q?SOKnmdW0S1Ne085RM4uth0NvV1fsnAhZwgPAewTnTFOBDSTIGH9jY4gIHE?=
 =?iso-8859-1?Q?TF0inQvcJntMEKe9BcxFG4fTDuhlID4N2mOEbRwFGB2MPVeBPGP+isPZsO?=
 =?iso-8859-1?Q?0N3a4TR/mV0oz4/yzinB/uXLaM6vzsLFtQaDLN19Q8b6bmaC+S6U+V2Z7t?=
 =?iso-8859-1?Q?keQpG6Fj8DVH1OKvviHbYTTpnZ4MZQDVAA4KvwCXsQwiAzn1VcfcJee2FZ?=
 =?iso-8859-1?Q?Znax7zyu9OdKuRaIulKgnLm7fiDgiKc/0r+GH3a7KCJn2rE2Mg2w5RSvmb?=
 =?iso-8859-1?Q?KpDTY5G4iDn0V+N1fDmlnM0Ah0b6onr/4uhwXRvuG0KUAopu/19ryFU58T?=
 =?iso-8859-1?Q?U6K82Z291i0egMZYOcBB6ow1+/DvYwpXd1JfFi/GT1kDVeHZq/rJ98ZjZw?=
 =?iso-8859-1?Q?V2ZxYKP11IAda+MXz+ARKklg2QNbJmNNXhLJTlU2EGzX1aupfO97spiQmn?=
 =?iso-8859-1?Q?D2sLiElLubRRUvyqjd5iEHIxhvvPZ8Ch6WiG/OqHxbhM3rpd/8d83lYMdp?=
 =?iso-8859-1?Q?huUbuXGgv+Jk6hSV35Q31hnM+Mf0cwd5/6v+LPDnZ0qY6F33eWr6aFGle3?=
 =?iso-8859-1?Q?zixW8MZaSfzqfgZxZwtq2Bz/dcT8KlXB+5ugR+SYtcXSuyfcNc4ehcV8Mk?=
 =?iso-8859-1?Q?TFN9GvxKUAOKltwrWTUG+Rm/6MoV84IAYoFBSx+77ZDLlR2aGI/eZIsXLv?=
 =?iso-8859-1?Q?bzicP6aI7abnMvpMEoSN03TVDPtuwYcL8h9mQMkPjy8aaxlkFyprf9MoOW?=
 =?iso-8859-1?Q?DePyXf2xK/MwPSi2NOUt99Mi1zwBFkiIsJcPcLf2wGyZfPcbEe8p0pqECl?=
 =?iso-8859-1?Q?cU2tKuDpMVCGPKwVmSeZTRGn9hx39SBoxlMG3wqicJ+uzTya1p4p/9Wqqi?=
 =?iso-8859-1?Q?Y3yhMCtRYTYU6M9QkIDd5ozi9KCJLomeJ4t2en41CtiIpFkv9GglAemPko?=
 =?iso-8859-1?Q?SWbWNmf8jCQzaw+XUZhx3IyqOVjadpKaLo3wpkiIhTdca21RjtYCqwCsJj?=
 =?iso-8859-1?Q?5xpAcaHZMj1NsRNSYTqvBuCadSRZPaoKZSSkRa3ea+Bc6GC1NUblKwGrup?=
 =?iso-8859-1?Q?NyYP7hQUArQ7etCA7UA+cNimEphKOlUhpzpussU8IZjAeIlzdHzZ7C5gkR?=
 =?iso-8859-1?Q?9WSLYUyYfRgFlUSAHiFsxc3LYK4XsmzeT22khOdl0G17FzcXfd6xyaER/U?=
 =?iso-8859-1?Q?dUQ5O06NhEc1GTDZG9Q7C2F0cp3eFj9jsRl+qURH7IB/FNQQWhOmbY6DJq?=
 =?iso-8859-1?Q?joaIneCrS44nFkL4XRUPPs0LuU6WEZIPn629vVRXb7t1X5I1wbbNiI3C5S?=
 =?iso-8859-1?Q?XlpJZUYbpx2xjuy9+SCZEfRz7YLH+W+dH3KnOSD+dy5WjfwslK+LsNMB7n?=
 =?iso-8859-1?Q?DPNgo9h5LYGSkMUsp6mA4YQafNL7SoDBoiVs20FwUw26JUveTBqsQBx1xo?=
 =?iso-8859-1?Q?9iw6VY8UILLzdMsIdkG01x4h4Qjdb7jRXN6bDOwUb1AoQF8dO/Hj5kxswB?=
 =?iso-8859-1?Q?PVdhaRUPX9aupD9jAcA3apj5kAxzx5EumWEB5evvJBRGxt6azrhw7iHbw1?=
 =?iso-8859-1?Q?lvTp8i3bIkie6PrrnnxWZvbKhl9DVzkpgBfSnifl+0Bx30KJO/1flud7iu?=
 =?iso-8859-1?Q?ihZPXCZGiAQ9cTHxeJmDkk9NjqnfilOPOftymIw4fVYI4DnNmH0S+jcpAT?=
 =?iso-8859-1?Q?0P1kQIXasjyWtpAe89atPa4yDlREbb4=3D?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a004a85-3f9b-48c3-713b-08df058df04c
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2026 05:25:28.9901
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ku0cnWMr/KZJx4qT/++t3h0MY0b1s076V9Ys13MzTj/s68nCkIsfLhCpIbdXAGgu6McBEkkrJ5qmJLeTypCChw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9141
X-purgate-ID: tlsNG-d25034/1787981133-018C5A5B-B34EA14B/0/0
X-purgate-type: clean
X-purgate-size: 2145

Error path of failed sidtab_map() leaves global sidtab in shutdown state an=
d
system unable to allocate new SIDs in sidtab_context_to_sid().
To restore sidtab state new function sidtab_activate() is introduced, it on=
ly
resets shutdown flag, rewinding effect of sidtab_shutdown().

Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
---
New function is not strictly required, this also can be achieved just by
doing sidtab_set(&sidtab, &sidtab), but this way we would rely on its
undocumented internal behaviour.
---
 xen/xsm/flask/ss/services.c | 1 +
 xen/xsm/flask/ss/sidtab.c   | 7 +++++++
 xen/xsm/flask/ss/sidtab.h   | 1 +
 3 files changed, 9 insertions(+)

diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 35ad1034ca..f5cee1e0b0 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1427,6 +1427,7 @@ int security_load_policy(const void *data, size_t len=
)
     if ( sidtab_map(&sidtab, clone_sid, &newsidtab) )
     {
         rc =3D -ENOMEM;
+        sidtab_activate(&sidtab);
         goto err;
     }
=20
diff --git a/xen/xsm/flask/ss/sidtab.c b/xen/xsm/flask/ss/sidtab.c
index 69fc3389b3..5d1653cd02 100644
--- a/xen/xsm/flask/ss/sidtab.c
+++ b/xen/xsm/flask/ss/sidtab.c
@@ -314,6 +314,13 @@ void sidtab_set(struct sidtab *dst, struct sidtab *src=
)
     SIDTAB_UNLOCK(src);
 }
=20
+void sidtab_activate(struct sidtab *s)
+{
+    SIDTAB_LOCK(s);
+    s->shutdown =3D 0;
+    SIDTAB_UNLOCK(s);
+}
+
 void sidtab_shutdown(struct sidtab *s)
 {
     SIDTAB_LOCK(s);
diff --git a/xen/xsm/flask/ss/sidtab.h b/xen/xsm/flask/ss/sidtab.h
index 0e48ec6eae..5d2dc9c7e1 100644
--- a/xen/xsm/flask/ss/sidtab.h
+++ b/xen/xsm/flask/ss/sidtab.h
@@ -48,6 +48,7 @@ int sidtab_context_to_sid(struct sidtab *s, struct contex=
t *context, u32 *sid);
 void sidtab_hash_eval(struct sidtab *h, char *tag);
 void sidtab_destroy(struct sidtab *s);
 void sidtab_set(struct sidtab *dst, struct sidtab *src);
+void sidtab_activate(struct sidtab *s);
 void sidtab_shutdown(struct sidtab *s);
=20
 #endif    /* _SS_SIDTAB_H_ */
--=20
2.43.0


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 13:22:29 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 13:22:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402826.1637637 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0J0c-00072r-Ru; Sat, 29 Aug 2026 13:22:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402826.1637637; Sat, 29 Aug 2026 13: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1x0J0c-00072j-Mv; Sat, 29 Aug 2026 13:22:10 +0000
Received: by outflank-mailman (input) for mailman id 1402826;
 Sat, 29 Aug 2026 13:22:09 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <nicola.vetrini@bugseng.com>) id 1x0J0b-00072d-EN
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 13:22:09 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0J0a-00HGZI-Rf
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 15:22:08 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a92dca6-2eae-0a2a0a5409dd-0a2a4501d5fc-44
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 15:22:08 +0200
Received: from [162.55.131.47] (helo=support.bugseng.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a92dd00-5984-0a2a45010019-a237832fba20-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 15:22:08 +0200
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id 1EE1F4EE0184;
 Sat, 29 Aug 2026 15:21:57 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1788009727;
	b=TlD1X+b569XEEKufkEihilRCtQtJ6CtiFkxM0qovcXyjfJlwHALBXgPgYJObtHBVpYDm
	 ZHkPct9l8dHWubpkuog75njZvaorl406aRXPIDR1tQLI85B6XqhnXfZ93DoUf8mo2HRcn
	 hV0YIlDuImAkMKYojUS/6PP2czFnLASc/uwSPCLeQZauE67aq8an31AV6r+tEKVBlbarw
	 vuDJsE1j6bxSYFwdwsem5ze6BVKR1YZZnlnQHUq6XBRkBrlcPeVdNX4c7xTb9GEbyy+DZ
	 oDOkzp1coq2YdP8F+RT+GZjTuX3t84G6gVLMm+KUM8ZvedoMDDxLAwhzNO8Sl1g/X7vC+
	 86nno0BotaUDSAkJRte6qrVdXTttEHYrEVIt8+DdWPMSY/pFWjSKDErJrprDERhyaOGg1
	 Y0RCDwfFdRypHBLkxdJcnVXZnVa9O2Gi60VjCgCmEP1tghO4YitSzLbBIi/h8H6zuUyvd
	 u11XEdSgaWNPES1CB9uxR43VMNoRiLuZmoLm8wQzLBQq4/cmtgaJsH4mBY/MvIi+U6omK
	 BYcmieXnALX+C8N6IqEk9wypLyG0bhIQ5yB0JmYvtalEVBYxwzqWHj2e5PaWt3f1fma6u
	 Czq80cTax9lhM8Hmt4bJqt8seVyv4fXzMUHUPZ9Hk0HAleXk3INxY1XYQjh445E=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1788009727;
	h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=/pEy/Zm4j9Av9iFeAsk+kZ4vGnZ9eb5eKV48lVGJeZY=;
	b=uZZ8mX1jXHy1I2uwAag5KZicQa/LCxjzqtCiZzfsextJacIcrcfpW5jPe1C0Udk/1Zr4
	 0ACGpdJVpyPLaIYoGvTu921BcRnsbQyPrgSOqyjunwC30q74Vcs9UErIxAzX9sCsCc5Af
	 l8Qu13MBn4G3wy7azUa42/VRfythrc9E+/5IgXqIrHkv9f09yV5kKnxm9jJHZvJEl+dax
	 OQRDxDUTKxTw8HOYyiQc7NZb7QFInGom4sdHrndm9TgWrLqk1fdd52VajZcnK6b7+2wwp
	 GZ3ZY1/vvRPViONETAnxgJ9tAD82D8Z2Fbk6SfW4sMeltlktRDF7ECkCiQIoOVSURvlkU
	 Qg1Mk9aNQer7sZMox8Xf0L8oLXMPJfszbARY2hsp2Fy+Xd6uDhZkBKevB/xGic+r3z0Xj
	 g0TQXtKXQWcC7Hlue/DycLNEasCIiM1r4ERfqtZhnsI4rkIsb71f1oCXs2CD5yq1z5IRC
	 2pEytHJ+642qIosrh+srz5aV4yu08NqTh8ZbVoBaKmX8wohpjQlQjCyHJgtBgH/PaL2UK
	 sqSxb5ACYQwBydhd/gF9TkG2WfpfSFZ7glsNVD4ecJx5WCgeZ5FLRWhzc5Sm3bKI3Q7tV
	 s0YgsM1BE37EVXOCHWVojhU33ptyi18a2MUGCt8yXN6Jl9HjkEhZNH/ii0gWXeE=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
MIME-Version: 1.0
Date: Sat, 29 Aug 2026 15:21:57 +0200
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, Teddy Astie <teddy.astie@vates.tech>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places
In-Reply-To: <d0f991de-db67-4f49-aef0-25c590b3889e@suse.com>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
 <d0f991de-db67-4f49-aef0-25c590b3889e@suse.com>
Message-ID: <fceca3b7cf0ccc067f89212a30aa3a6e@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-d62444/1788009728-BFA6E757-BEF4F805/0/0
X-purgate-type: clean
X-purgate-size: 5143

On 2026-08-28 09:01, Jan Beulich wrote:
> start_secondary(), do_double_fault(), play_dead(), and tboot_s3_error()
> never return, so would better be annotated anyway. The 
> do_double_fault()
> change needs accompanying by adjustments to entry_from_{pv,xen}(), as
> Eclair then deems the "return" there as unreachable.
> 
> context_switch() and continue_running() are odd: We can't
> (unconditionally) add noreturn to their declarations, as Arm's variants 
> do
> return. Put the attribute on x86'es definitions instead (the use of
> unreachable() in reset_stack_and_call_ind() allows the compiler to 
> figure
> that out itself, but Eclair wants the annotation in addition).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

> ---
> entry_from_pv() wants the annotation only when PV=n, yet once added gcc
> then warns about "return" being used in a "noreturn" function. Is there
> any other approach to address this besides adding #ifdef inside the
> function (i.e. replacing the !IS_ENABLED(CONFIG_PV) check that's 
> there)?
> 

Besides GCC's warning, this would violate MISRA C's Rule 17.9 ("A 
function declared with a _Noreturn function specifier shall not return 
to its caller")
which is not (yet) adopted by Xen, as it comes with MISRA C:2012 
Amendment 3, whereas as you know Xen is based on MISRA C:2012 Amendment 
2 rules.
Besides this, perhaps an alternative could be something like this 
(untested):

#define __noreturn_0
#define __noreturn_1 __attribute__((noreturn))

#define __noreturn_select(x) __noreturn_select_(x)
#define __noreturn_select_(x) __noreturn_ ## x

#define noreturn(cond) __noreturn_select(cond)

assuming use sites such as noreturn(IS_ENABLED(CONFIG_FOO))

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2163,7 +2163,7 @@ static void __context_switch(void)
>      per_cpu(curr_vcpu, cpu) = n;
>  }
> 
> -void context_switch(struct vcpu *prev, struct vcpu *next)
> +void noreturn context_switch(struct vcpu *prev, struct vcpu *next)
>  {
>      unsigned int cpu = smp_processor_id();
>      struct cpu_info *info = get_cpu_info();
> @@ -2240,7 +2240,7 @@ void context_switch(struct vcpu *prev, s
>      reset_stack_and_call_ind(nextd->arch.ctxt_switch->tail);
>  }
> 
> -void continue_running(struct vcpu *same)
> +void noreturn continue_running(struct vcpu *same)
>  {
>      reset_stack_and_call_ind(same->domain->arch.ctxt_switch->tail);
>  }
> --- a/xen/arch/x86/include/asm/cpuidle.h
> +++ b/xen/arch/x86/include/asm/cpuidle.h
> @@ -26,7 +26,7 @@ static inline int mwait_idle_init(struct
>  int cpuidle_init_cpu(unsigned int cpu);
>  void cf_check default_dead_idle(void);
>  void cf_check acpi_dead_idle(void);
> -void play_dead(void);
> +void noreturn play_dead(void);
>  void trace_exit_reason(u32 *irq_traced);
>  void update_idle_stats(struct acpi_processor_power *power,
>                         struct acpi_processor_cx *cx,
> --- a/xen/arch/x86/include/asm/tboot.h
> +++ b/xen/arch/x86/include/asm/tboot.h
> @@ -126,7 +126,7 @@ int tboot_in_measured_env(void);
>  int tboot_protect_mem_regions(void);
>  int cf_check tboot_parse_dmar_table(acpi_table_handler dmar_handler);
>  int tboot_s3_resume(void);
> -void tboot_s3_error(int error);
> +void noreturn tboot_s3_error(int error);
>  int tboot_wake_ap(int apicid, unsigned long sipi_vec);
>  #else
>  static inline void tboot_probe(void) {}
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -326,7 +326,7 @@ static void set_cpu_sibling_map(unsigned
>      }
>  }
> 
> -void asmlinkage start_secondary(void)
> +void asmlinkage noreturn start_secondary(void)
>  {
>      struct cpu_info *info = get_cpu_info();
>      unsigned int cpu = smp_processor_id();
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1080,7 +1080,7 @@ const char *vector_name(unsigned int vec
>      return (vec < ARRAY_SIZE(names) && names[vec][0]) ? names[vec] : 
> "???";
>  }
> 
> -void asmlinkage do_double_fault(struct cpu_user_regs *regs)
> +void asmlinkage noreturn do_double_fault(struct cpu_user_regs *regs)
>  {
>      unsigned int cpu;
>      struct extra_state state;
> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu
>      case X86_ET_HW_EXC:
>          switch ( vec )
>          {
> -        case X86_EXC_DF: return do_double_fault(regs);
> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */
>          case X86_EXC_MC: return do_machine_check(regs);
>          }
>          break;
> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp
>      case X86_ET_HW_EXC:
>          switch ( regs->fred_ss.vector )
>          {
> -        case X86_EXC_DF: return do_double_fault(regs);
> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */
>          case X86_EXC_MC: return do_machine_check(regs);
>          }
>          break;

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 14:04:51 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 14:04:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402852.1637645 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0Jfp-0006Yx-RP; Sat, 29 Aug 2026 14:04:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402852.1637645; Sat, 29 Aug 2026 14:04:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0Jfp-0006Yq-OM; Sat, 29 Aug 2026 14:04:45 +0000
Received: by outflank-mailman (input) for mailman id 1402852;
 Sat, 29 Aug 2026 14:04:44 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <nicola.vetrini@bugseng.com>) id 1x0Jfo-0006Yk-6c
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 14:04:44 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0Jfn-00HHO4-Ey
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 16:04:43 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a92e6f1-2eae-0a2a0a5409dd-0a2a4508909c-2
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 16:04:43 +0200
Received: from [162.55.131.47] (helo=support.bugseng.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <nicola.vetrini@bugseng.com>)
 id 6a92e6fb-f659-0a2a45080019-a237832fc068-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 16:04:43 +0200
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 (Authenticated sender: nicola)
 by support.bugseng.com (Postfix) with ESMTPA id C71EE4EE0060;
 Sat, 29 Aug 2026 16:04:42 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; none
Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1788012283;
	b=McTwEUebFObeKEVigMbKpOIXwZRDo29CsdbGhfQrGTyGxdalmyUXpADoQPg5Dj6bTab9
	 9v19MeivsBsq343sLyLIjk/kPxtzpEVxdotFmeQmtzdrz9p/6ev9iLTEgMt5fQpEf1M59
	 iQihR777jb2A534M6T8sWmHBYDpShNOC08LhrPsnoXK6m9aSsrh/xMPdzaXGJ2ztxDO5Y
	 6KtgzEMsvav8ZMtkh6fAdsIGaFuvT+9XlpIsGBFkqCB4tKZv0qdEkIJKeVHC1jxQECfzg
	 WghW9yDUxnTa7dVy/H4BkdQgMT+Yk7Y0RNSNnsMjSg67EKABRuyKioxJxJIZHSogo/QsE
	 6uo1doGUJu8d+5cEKuODUahA80UIR5wpwt/tIej5L8V52K4fYfK+lB4KDUA+TDxWAdvRv
	 7WSNiUeDCGzdVTAYlQlifwsjXWMNy864y4q0RC7vlyNfIWxbXoqM2Zvlrz1wjfANUHsOx
	 U8NvJLa/iEQGiC2zOwJMBqrNKyD0k8h5GJPz55uX9BNi51hIxGrAn866UZCuA6/FrTo2Q
	 +iDc1F5tBD8a3Bo7tKzm+nMkigjOlfyx1lBdipsdfnZwTuPyR0X2+etPI4/Nt1TnM6kx/
	 vM5s6z+p7dIp75IW16IZUHIxpsH3ZS8qn4/WsX3DUOacuq6aC3IO+q8rO0L76xg=
ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256;
	c=relaxed/relaxed; t=1788012283;
	h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Message-ID:X-Sender:Organization:Content-Type:
	 Content-Transfer-Encoding;
	bh=YPq55LcariTfRIgkToCnifE9romNqBh34Zbm15cX+N8=;
	b=Bgtu9QbAuanLWeUc+YiMedoRGpq0TLTfiisknIbjDXOIwcnU/XAqc2EP6E2mhXEzdjZu
	 WbFrzlFgxjJiXA+g3H8l3H/VsOZBZyeWZV1fPqLtnupWJD0I4D2urz7qNbD9XP65NcdA0
	 4uPA6TzMwSJi26woKcJ4wqqKBg7n6LilmsoyPeS6dH2DSenjqwbkurmEg3yirVEbW04n9
	 RuLdQt8JooEvBvTvmm0xsYHr2h8nh+GNRdmzjGGMLb1v95FqEhndPFWz//XRZfODi5YdT
	 rrTF9FZIa6MJr6SE1xpjucmfzmoZ9XrbgIV2AZAsBM/BJ9xPhawF7166HfTa3BAYOXOJS
	 xiBWwmhO5xHkuSMIf+2LCI2CNsAsEwMTwYyxg4jleJXvWJR5gDXWRRmDQNBYeQY8U8KAb
	 RbqVhsFCnrfBFNIaiFXW0Ywo0OhYNGf380QK3BLnnYEwUAG3k155n3XFH/X2PGMPJCn+u
	 XUUVEjfLeL3CXUXmJabuq+KlF5QEBscNXGDCHVwNV95jFxOkH5jEaTzKUKuiWLGbFCWO2
	 cBitMp22B/SCHMQAdnOUm3Jc/7fWoZ/09V0t3iyUxNH8IKNJf0RO5V0jV3fxfP9Qlan4Q
	 LKqX1CAOK7dX4M9Dt/vlp52MPPiGgdtv7QuwVgQeEZTFbwkAJr9ux9CTK0izIo0=
ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
MIME-Version: 1.0
Date: Sat, 29 Aug 2026 16:04:42 +0200
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, Stefano
 Stabellini <sstabellini@kernel.org>, Anthony PERARD
 <anthony.perard@vates.tech>, Michal Orzel <michal.orzel@amd.com>,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Subject: Re: [PATCH 09/12] Eclair: deviate BUILD_ERROR() wrt rule 2.1 and
 introduce variants
In-Reply-To: <06c5efc0-e130-417f-8333-b8eacd1c6d77@suse.com>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
 <06c5efc0-e130-417f-8333-b8eacd1c6d77@suse.com>
Message-ID: <99c8a63920c37dafdfeb2a2a4333df72@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-c1860d/1788012283-D4B7187B-86E94913/0/0
X-purgate-type: clean
X-purgate-size: 3112

On 2026-08-28 09:04, Jan Beulich wrote:
> BUILD_ERROR() is even stronger a guard than assertions in general, and
> ASSERT_UNREACHABLE() (or BUG()) in particular. Deviate it just like 
> those
> to allow use for marking unreachable portions of code.
> 
> In some cases code being unreachable is dependent upon configuration.
> Introduce two variants, as constructs like
> 
>     if ( IS_ENABLED(CONFIG_...) )
>         BUILD_ERROR("...");
> 
> results in the if() still being reported as unreachable. Sadly these 
> two
> new macros introduce a new 20.12 violation each, which hence also needs
> deviating.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Presumably you did not fold at least one of the following patches where 
the construct is actually used into this one to separate concerns?

> 
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -19,6 +19,7 @@ Constant expressions and unreachable bra
> 
>  -doc_begin="Unreachability inside an ASSERT_UNREACHABLE() and 
> analogous macro calls is deliberate and safe."
>  -config=MC3A2.R2.1,reports+={deliberate, 
> "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"}
> +-config=MC3A2.R2.1,reports+={deliberate, 
> "any_area(any_loc(any_exp(macro(^BUILD_ERROR(|_IF(|_NOT))$))))"}
>  -doc_end
> 
>  -doc_begin="The asm-offset files are not linked deliberately, since 
> they are used to generate definitions for asm modules."
> @@ -667,6 +668,7 @@ deliberate."
>  to the # or ## operators within the following macros are deliberate, 
> to provide
>  useful diagnostic messages to the user."
>  -config=MC3A2.R20.12,macros+={deliberate, 
> "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"}
> +-config=MC3A2.R20.12,macros+={deliberate, 
> "^BUILD_ERROR(|_IF(|_NOT))$"}
>  -doc_end
> 
>  -doc_begin="The helper macro GENERATE_CASE may use a macro parameter 
> for ordinary
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -64,6 +64,21 @@
>   */
>  #define BUILD_ERROR(msg) asm ( ".error \"" msg "\"" )
> 
> +/*
> + * Like above, but conditional upon @cfg (not) being enabled.  @cfg 
> must be
> + * suitable to pass to IS_ENABLED().
> + */
> +#define BUILD_ERROR_IF(cfg)                               \
> +    (IS_ENABLED(cfg)                                      \
> +     ? ({ BUILD_ERROR( #cfg " unexpectedly enabled"); })  \
> +     : (void)0)
> +
> +#define BUILD_ERROR_IF_NOT(cfg)                           \
> +    (!IS_ENABLED(cfg)                                     \
> +     ? ({ BUILD_ERROR( #cfg " unexpectedly disabled"); }) \
> +     : (void)0)
> +
> +
>  /* Hide a value from the optimiser. */
>  #define HIDE(x)                                 \
>      ({                                          \

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 16:54:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 16:54:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1402981.1637655 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0MJQ-0001dq-6c; Sat, 29 Aug 2026 16:53:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1402981.1637655; Sat, 29 Aug 2026 16:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0MJQ-0001di-1j; Sat, 29 Aug 2026 16:53:48 +0000
Received: by outflank-mailman (input) for mailman id 1402981;
 Sat, 29 Aug 2026 16:53:47 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1x0MJP-0001dc-Cj
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 16:53:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0MJO-00HYCD-Q0
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 18:53:46 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a930e76-bab6-0a2a0a5309dd-0a2a450aa40c-14
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 18:53:46 +0200
Received: from [52.101.48.25]
 (helo=MW6PR02CU001.outbound.protection.outlook.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a930e98-f2d2-0a2a450a0019-34653019563a-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 18:53:46 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by PH0PR03MB989335.namprd03.prod.outlook.com (2603:10b6:510:110::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.12; Sat, 29 Aug
 2026 16:53:42 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Sat, 29 Aug 2026
 16:53:42 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=w3bKBD/z39t1ZoCl1nNPuIRWxgQdhyLzsxPyE6uiSfEzOaH6fBz0HcsdJqv884tERWpAVswYgCJ8AzqRu/LSufLYn2j28JL1Eatrfsw339FYo+Di4O79MtnxEhl3hb/F7cfhUAlmlhcD+eTIY96oy8tjoogKw0ODo4Rp75GNx2xtS8OdzXC5wItJlBTf9Ysk1iQcdugjSaWrRH1OfZxSsntcundBAjGFfJcfCKwLKLbw3MpfiQ7wREyXdvzf58eIrq4T1jBQpFfT1BBv7bBlkADwkyMfln++qbNvgETaYUutg9QE106o9LacYHnxkvwI6FERFVG6yMd+H7OaHbVDEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=F/YsbSyZiaIImEk9fvBmsrVjrlUZNcyYpOUUdgH6vmE=;
 b=rmMdBKaaQIfEBBJ73/UkhZjIDZz2CZ6rhkaEdMogDuE5LwM6D6bnpyLZtw+LTbxcLsJiMqIvUFM4yTJOdCfbEg0BA60huzOivdCviF9imO8OkT3wGCcdxnCBhOdrhYTLSxHxVjJiWaDRFFeQ4HSM9cY5x4D2PCJQfcKwvP8FpSqaXWIBc/QCMLCEEI5YhWjxuzsM20xanzT+HT8StjJxwRWhj42Q55fREnQ2NI3k/l0kDSDn2QziaAwtGtPSvHbjYdtdXZJkrAFipGUHgsUQqMAOXHEv+rCMe6irgvFegsEGCIFkUMOamFWNsoRfW6YBMJZoe1fsYrgcyXSGkjRbsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=F/YsbSyZiaIImEk9fvBmsrVjrlUZNcyYpOUUdgH6vmE=;
 b=qefjEAvjnRZIlARFVLuGbuIRaqhTr10Al93zOvhiHSdwoPSCGn+j5IxouBDtl0AOgvWjd7/EuhPXND732uEN+zrpdqWBgF5Qu45K5q0Rhqa96C6Lcn8Clw2i6DA5v+PHz5xk5mFhxfNXxXzF1Eh+4DS2d9+a0ypIlbyHNAUKi4c=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <5286d0ad-5068-43dc-b23d-e18f05ae4b64@citrix.com>
Date: Sat, 29 Aug 2026 17:53:38 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Jan Beulich <jbeulich@suse.com>, Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [RFC PATCH 0/1] xen/arm: smccc: preserve arguments before
 register setup
To: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>,
 xen-devel@lists.xenproject.org
References: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0229.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:315::18) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB989335:EE_
X-MS-Office365-Filtering-Correlation-Id: 765d1029-0cf9-4ef2-9444-08df05ee14c2
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|18002099003|56012099006|3023799007|10067099003|11063799006;
X-Microsoft-Antispam-Message-Info:
	Sw+f9WJPF4jTQ+q6aB6Fp4NLvTOwjkEbV4E/hJsxrmCbmjpmmjTBRAIQkKpZPyj/C7kWpMlJ1L5Q16AggMpSBfwEKPyNgbT4PclckFBrqo9m4Z8+W9qxU89cEJ5IwbHjdAJYbfS7eoSq7ibbkG0SkmQGPdvdbYPP6YymTUMAbp2PM6mWwaZjqictjBtlLCE/Qd0T00CrluIQn3pFlZAiEqmbBPFu/cqASecarbZpXYcvuAZr006pyakRfsvsMebueFJibfsUcH9Jjtc8MxXMmqeEnPc0Uh5fzUe/uR7ECZ36K7ZOohzRUSgiEYDDy0u7s50OYPa3CDvD4+zqgXScG5qcFfERWV8QZfSPK37EjzBJyV1gqSseWfdOwOsGUnAiyWBhMfd53qdmm0yT8O+mui7blKjEyvkzDs0qYwNXaPslTSBEgHUqOt8ykmaUVnD6LgqqhwiLPios9IIUvlvkpFdqo+lbpcfNl1TeTMj2ZKEVb+B3nnDNNo8RdI4ioLtj1t+ybIG66C28N/6Iih+rvHeAotySxhLmDDN9/mzCL+Dl72TqGwT3mv65IE+lqCQcdu0lnXm1n7xrw+H5LQVEPQQtpbbW+76EcQGamj7tM5xc7gsM4VQg8S+Z/DUZaS3r9WK3we63RmzdH+Uf2O9tFEjbuANf0L2PXrqFh1wgwfI=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(18002099003)(56012099006)(3023799007)(10067099003)(11063799006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?V3JmNUN1WlpNalE3Qm1BMGZtUG82S3pFUWUzeU10d3h4NnJwZzlPV3JNMzh3?=
 =?utf-8?B?SmRPTi9rQWk1RFdwcDlrRFQ2QmkzL2pUU21DcjJHN2pOU3d4dmROZHNlK1hP?=
 =?utf-8?B?bVR2bGVGSjJaVlFuWi9FTXlndC9kMmdSUWQySzZVKyt5ZnhGdkhtUEZCVVRm?=
 =?utf-8?B?ekVqd1lNckJwd1NNd04yV2JUcE9mbEY3Y1FodGVKby82cjBwZEprS0pKamNx?=
 =?utf-8?B?dFBGU2Q0RHVzVUY5THBpZzBVb3dkU1RyMzNNMzJXV0pxTkhnQ2JJblBLNzFI?=
 =?utf-8?B?Z0l2aUFYaDJGY29qaDZ2VHJRc1owUHRiYlBvVmYydmRqSWE4SndwTktBTmhC?=
 =?utf-8?B?ZzhYcGZ1djFaTEJ6c3M3ajZqaWdLY0xpYUVzWml4ZDI2WXFRT09ZbEF6Q2pt?=
 =?utf-8?B?YmFCVXU4K1FKTnZBT0VoSyszc1YzU2Vxd3c5OGZRcnV0blJSUjFDdUtiZFN6?=
 =?utf-8?B?QWJDU1NHek1WUFNodXh1R3llcWlGQmZTN2RpNmhtUkkrdUI0Z282RkpnWk4y?=
 =?utf-8?B?aDdNRmJJNWtNQy93aTZxQlI2V0Z2NUNDaDNQODd0cjBiOTVycWZPVHhOdW41?=
 =?utf-8?B?ZkdEUVBRdlNaeCs3UkpJS2dSWVNiNTVlYm9NUUp3SzNyMlhlYmxuS1l3Zy9t?=
 =?utf-8?B?VTgwVi9XZmJOcThEWlRza0s5VjVPQ05GTndIRDNZdDBFUzVzQUo5UkNUcHJz?=
 =?utf-8?B?c3BweW5vaXkxMjNGNHg4Z1NmT0l1WkdRK2FLdWlseXpHYUp0MjZjZ0VZYnpX?=
 =?utf-8?B?cS8yTitxaUQyUFFNNDdaRUFZVWtrL1ZtdWozZmdIcEZFRm1XVU1Xdm5zcmFk?=
 =?utf-8?B?c1lCOHVkNW5tWVN1RzM5SDgvQVZWNW5nUXVFUXZrNFZEQ2lGRnltNlF5VTFM?=
 =?utf-8?B?UUREUENVRUxNY3drY2RhTEdUUVVva3VnYXNoakhOTUFRazNQVEJiUlhjMS9m?=
 =?utf-8?B?eHJ5MUJQeVVsMFFFeThxbXV5YmJSeUsvc3NZOVhrZHphWU9oRTMwSVQ1US95?=
 =?utf-8?B?Z3diNDM2ZzloRDY3QkZwSXFNVXNIejhYOEtOUmVRaGh6NjU3Sk9TTmVHWTJE?=
 =?utf-8?B?Uy9wejRveXVMb2lwbm5TMjBuNlArRVZRUnRhQVFFdzN6dllHNE1qNDRFQW1D?=
 =?utf-8?B?Z1lpWm53Y0pyeUhhdDNvUWlxTGdUc0paVlJIMFlJdFE0UkdSMG9TNDZxZkJN?=
 =?utf-8?B?cmRmSEJwTTN6Z1lidkZ4bWQyQ2t3NVcyejZTYzBqOUp6QzZYVzJ4czRYZC8y?=
 =?utf-8?B?QkZSaTNiVXVTT2NINExzeUo3RjZ2czMzNzd5bXRmUzNDeTF3dWZIQnZOSnlp?=
 =?utf-8?B?Y0lwRWpwajNucWhBTmFJVXd2ZHh6NXJINHdLdERjUEdwSmNuRWV4Z2pjd2FM?=
 =?utf-8?B?SmhxdFhnTHRkM0JZZU9rU1l4cG9XcU92aXBRWlZRUzlxT3NNbVp1cW1WR0My?=
 =?utf-8?B?ZmlpYjJKUTVWWWhOVlE1K2pCNXlMN1pUcndjMGN4Rk5SQ2ZSZGY0YVQzNmph?=
 =?utf-8?B?cmdXeDFBN0pLN3ZkRUpNNURHNXJuSVR6Z2cwb25PcVZWWVJVNUxHdzU5VFpN?=
 =?utf-8?B?NkhYSHhDMEZjNkc4OHNyU2J6eHFLbU5hVlN1VVJvUjR5ekZXWTJaQ3VlUkJN?=
 =?utf-8?B?b0IwVjBzZ3BJdC9iYWdsUExPeUhPaVZSODVDMGNKcUIyUml0SzArZnFhM3BB?=
 =?utf-8?B?MVg4NVNVY1hwY0l3d3NQQllhZm1MMmdOa3VjY3dqZGRxQkhoTU9ESmNaNG9E?=
 =?utf-8?B?YmVidDE5d093RjR2WGRSd3lrRTczNHhrQjVoWVZlelZ3S3FIOEJ0eko5T1Bm?=
 =?utf-8?B?S3lDREM0QnFjUTBHaXNTNWJUSEtHZ21zUlBzb3ZPL283VHpnYnNoOThDdFRw?=
 =?utf-8?B?ODF2WWxEaFhHMlp6K1VxaDVOak5xVmEvdUUvUXVXNUg3UVJHdCtBQTNSTmgx?=
 =?utf-8?B?anE0ZXZxdkFROStpTjc2Y0dyK3FrZ090elRKRkN2OUwya3NwQldFMWZQUU9n?=
 =?utf-8?B?QjRiTlplTkZuZmJjVk9PSU1yb2hGblZucVNuWjF2c0RyMjRMTE5YZGNpRGZ4?=
 =?utf-8?B?bmpUMEw2cEF0dEs1MFI5U0psaTlFWDdnZkVZOWlxV3dVV3BoN3c2UW9UenBM?=
 =?utf-8?B?TWFpNEZWQ1ZqdDZ1bWVBTzh5ZWphaTF4Ly9heFZqUmNHb3pJMVlFdFdSRklY?=
 =?utf-8?B?aU05NXg4VmNoQ092alFvL0d1Y05BMU5Mb1NJZUppb1RyRTR3WGlza1p3cjk2?=
 =?utf-8?B?bWw1eENNRC9RWUVFRnMyM3UwRGltMkc1S1pOREp5c2Y5U0NlM1FNNTR2bWox?=
 =?utf-8?B?cGtTWFJjbTdJWHVqK2N6d2RwbkNCRnFsSjQ4QjdKajFqbGNMcGNMQT09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 765d1029-0cf9-4ef2-9444-08df05ee14c2
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2026 16:53:41.9343
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3rjNsRGflok9CIuooNvN0yhQMEgojtSufV7ZzpYihKQnIqKnNqSEw9Wqb6Tmon2evTQV70prIruwmOuqQxOBRKvIgUZUP/4TZOGOdah1OoI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB989335
X-purgate-ID: tlsNG-4011c0/1788022426-528DDCFC-3CA515F1/0/0
X-purgate-type: clean
X-purgate-size: 2081

On 29/08/2026 3:12 am, Jan Setje-Eilers wrote:
> Hi Andrew,
>
> While investigating an SMC forwarding failure after updating to Xen 4.22,
> I found that firmware could receive different values from those passed to
> arm_smccc_1_1_smc().
>
> Several public Xen callers pass get_user_reg() calls directly to this
> helper.  This includes the SCMI, ZynqMP EEMI, and i.MX forwarding paths.
> The helper puts each value into its SMC argument register as the
> expression is evaluated.  A later get_user_reg() call can then overwrite a
> register prepared for an earlier argument.
>
> The change in generated code appears after:
>
> 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations")
>
> I am not sure which behavior the helper is intended to provide. Should
> arm_smccc_1_1_smc() continue to accept arguments such as get_user_reg()
> calls, or should callers save those values in local variables first?
>
> The attached patch is a candidate for the first option. It restores
> temporary variables inside the helper, allowing all calls to finish before
> x0-x7 are prepared for the SMC instruction. I am not able to validate the
> public SCMI and ZynqMP paths on hardware, but their generated code now
> finishes every get_user_reg() call before the final register setup and
> smc. With this change, SMCs also work as intended on the device I'm
> using.
>
> If the intent is not to accept function calls as arguments, we should
> probably fix the SCMI, ZynqMP EEMI, and i.MX callers.
>
> Given the existing use cases, this seems like a bug, but your patch looks
> intentional. It's very possible I'm missing the intended design. I would
> appreciate your view on the intended contract.
>
> Thanks for any advice or help with this.

Yes you're right.  My change was buggy.   It was actually part of a
mutli-stage cleanup across several patches.

I'll submit my own patch.  I'm afraid your AI has put in whitespace
errors where a straight revert would have gotten it correct, and left
the 0 case still buggy.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 18:19:34 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 18:19:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403068.1637663 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0NeB-0001ym-2c; Sat, 29 Aug 2026 18:19:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403068.1637663; Sat, 29 Aug 2026 18:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0NeA-0001yf-W3; Sat, 29 Aug 2026 18:19:18 +0000
Received: by outflank-mailman (input) for mailman id 1403068;
 Sat, 29 Aug 2026 18:19:18 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1x0Ne9-0001yZ-Qm
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 18:19:17 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0Ne9-00FbMh-7Y
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 20:19:17 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a932176-bab6-0a2a0a5309dd-0a2a4505ccae-42
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 20:19:17 +0200
Received: from [52.101.61.7]
 (helo=DM1PR04CU001.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a9322a3-4cb1-0a2a45050019-34653d07a500-3
 for <xen-devel@lists.xenproject.org>; Sat, 29 Aug 2026 20:19:16 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by LV9PR03MB8392.namprd03.prod.outlook.com (2603:10b6:408:366::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.11; Sat, 29 Aug
 2026 18:19:13 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Sat, 29 Aug 2026
 18:19:12 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=VIJ+N10bWUKP5Utpit4GdwIA4YA5Y6bdX/CCzeYjC/M351w417v6CEua3h7q7hQLIWa4DuCnJ4UweZThL1U2LOdfrTnd64YXFMv2mZlgo1og41wD6DtUPI7s/iqH9QFOIZrNlQUhCCcWxNq2qz8VUI68riV4KqspErcMKcKwjYTGTRTD8mR2kyNeYBBh4t5l8DOkuhAE1it5peS+Uaz19geQ8qZrReHBIRXquScqVI+eacX+saHCIQxcXjKTjDazi6IzjLrmUGKNrSEHBjhArh0BpkI+kZ0owemJhxbWxvglUiCW1bk2iemNu8MyachffaqzIdJ81rB+zxzDpgAUag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/FIHydVNpAcIW+o4XUBaZpAnTpDmfptdhgr0/6ayVjQ=;
 b=WW60+Kq8xmYggJO8WM26JWuYuzSw6z5kagK+ZXt/IVCtoZsQ6p1jikrwaYsmfpzJz3h3FN8XiOilCoxmZi1Ink/bRyesHYv20llHFID/QAmU3ed+foKJi0KN+cc2Pd56JjTK7lGpXMBU6Ipy9YNnwuIJVhIPc7qvpSmHl+++T/rMKUD6KhnafSlW+df5IYmZyAf22iA+vzAoxPxJw3xrVoR0XG2cfhaPcsUWrzbVSyqgZcj87uziRSk3X9m2jqosaaN/4CavnuA2GjCgE3eT9sdSj5Psq+hCqfF9vbuxg577iFIvNjp8UX7I45HLPsC9jTUt++AD0oSW2kbsVAsHGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/FIHydVNpAcIW+o4XUBaZpAnTpDmfptdhgr0/6ayVjQ=;
 b=VrRun/xJg9Zyx7qFrrhBvKWDUv6vqPFfz8syHlnO8Ur2CZ++BeV2ELcwRDC9fUM3foDbdhmlaEcS/ZPLct5uyIvvRv0WF6HTwy3Y02mmFQRY8s+YMmxMlCvUoaTv5dZok4VQc00yniNLxZezdVMT2fs7sr58BQFFbuvwaGBOx44=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <31e8bcf2-480c-4f32-8096-877a0fbd327e@citrix.com>
Date: Sat, 29 Aug 2026 19:19:09 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 Jan Beulich <jbeulich@suse.com>, Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [RFC PATCH 0/1] xen/arm: smccc: preserve arguments before
 register setup
To: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>,
 xen-devel@lists.xenproject.org
References: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
 <5286d0ad-5068-43dc-b23d-e18f05ae4b64@citrix.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <5286d0ad-5068-43dc-b23d-e18f05ae4b64@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0139.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:193::18) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV9PR03MB8392:EE_
X-MS-Office365-Filtering-Correlation-Id: 86237a32-2d26-43cc-6127-08df05fa06e4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|10067099003|3023799007|4143699003|11063799006|56012099006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	99Upn7RmXhOOBRxmH95F1YuvOU50UtoHsj8/rwMRACUfvGghuqcFQzVpyPFW1FfHgI3hgmcTn6Wt3bMpfVgXEYemvQVlmfTETtjO94uLQlDG0I95wnAbyct8GTHbbGJcbpeRK/6wXW/XowCKyhaPprlE7K9/9p0uBqQFjSNX9vOAA1n/YmvqahkWwtqvLFGA2+J5qAyqMQlDCdnqpm08IN7RGoFQvrQBD21cTa06szJf0oDAhjusMNv7GFbtC3B5Jwf3j1anfFJrxBsesntM+iqjhM1HkBxbfiStMnmZn+CvO0Yz4SUfxPPtq27HFA39/C++aj+m0p7+2Gzp6KAJbktkprRYow6uaAn1iWwT40JjI7ixtDL8Oa618NS/rZlM3P4zhQJGFgTLCYvM9FOHi8S7+eQXgV5cmK3SNFx3BgqWe3AFtT9ItI7O/hNUhvfWfQPlHjF1kSe5vcm97Tq1DhfxyCJRZaoyVHykaju8oHdbAjV78QMDGVtk/lKKvZDjKj7SX0Wu2IdugTeeQYvPO8WdZq73/tYHPmtBiW/M0qeIUJw4pFV5rIWJT+UjL42Vj4yLztycpYjyxTGItSbpX+oMQ+hrm7xVG8jz0MvAKUV0fi1sJbwsSviLuDlNTMkwLvDKDXZ0fXrD7gO196QYbF7/pXfdhEfPenX3OGRKbcs=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(10067099003)(3023799007)(4143699003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?d0hSNytzek5pN0NwMmh2NEVoOEw1KzY4Vk95MDRFay81cDFuSUlNci84SjVk?=
 =?utf-8?B?eU5hNUpDK1UrMGF5eTRVTGNPS3ZheDU2MTIyeDBaTXBSeFMySDhaUWJEcVVh?=
 =?utf-8?B?TUwxcTVoQkFpTGFtRGFRWFMxczhETnJ2TzNoRjFhbVVYbDJUZE5QOXBPd3U4?=
 =?utf-8?B?VXpNOW1EL00wOEpBQW44WmFzaWl0VmJ0WTdsR0lFMU05K0RZaEk2Qm5wZVlt?=
 =?utf-8?B?MkJDelNNVkRhTWlYNVh6ck5XNlJVekJUTXBGN0pRWk9LVGIzd1ROcjZtbENL?=
 =?utf-8?B?OVBCcnkwTHBJRUZnYkN3eUJSR1IwQnUyZml0eEZrUElDOXN0WDNIN3NlTk5n?=
 =?utf-8?B?NFBvSExhMWp6UWpZMXlyN2hoZm0yQ2ZoU3ZjQVY2N1hac3NzQVhLMzBDQ0lM?=
 =?utf-8?B?SEpyY3BNUDd0SktFRkc3OVgrbjQvRGxkc202dEJHejJlSWlSVWRNUWZWaHll?=
 =?utf-8?B?Y0ovMjNKY3JjRiszK2FGYzk2T1oxbmZoS1g1c3JVQXovN0MrcDBvVmpmNy83?=
 =?utf-8?B?M0Jxd2VLQmJGQUcwT3FldHhXQ2o0dUdtVC9mZlVDK3FJVlFoajZ4d2VZMVZv?=
 =?utf-8?B?dmFmNDBRKzFFRVJsVmlGUDhDdUxLN3d6b2piNnBDUUdxeEM0eGJUNXIyMVBs?=
 =?utf-8?B?N3JzbDF2T3o5eGp1YzJaVlpyWmRHYzNIazZncFMxSDRaNjAvMFpnR3E0bHdS?=
 =?utf-8?B?M1YzMFRkcGRQcElyWHMwKzVtYTFyUEc1aUZxK0o4TEJpa1ZVbWFRVm15QU1i?=
 =?utf-8?B?aVhUMitEekRWd0FiemwyV0NKdEcvRjhRbTZlT1NBbGVZaVYzZEh3dlRPL1Zu?=
 =?utf-8?B?RWhxdlpLUVArZTFMTmQ0TTJhMFEvY0N1THFLN2NDTW1UQ0lZR0h4RW1BYjJw?=
 =?utf-8?B?cE4vNFdRTE12KzNyN2U4aXpURUtCczVQRGt0Ym5uTHlvUHUyaVFIb2xOa3J2?=
 =?utf-8?B?OXVXT1ZOQVVCSGpZZXorOFRtL0pRN3Mvb2xMVWRTZitUdVdxa2RYR0g5WFBr?=
 =?utf-8?B?Qjg2WnVlZ1NTdUVBNlljQmFvc2NodFN4aFNhOGFGYjBtK3lmMk1CYjAxQmRi?=
 =?utf-8?B?cTdac3ZKZk5DUDUzcHVQQ3FURU9DcmJFY295TFJDUVhPUnZzRDBleFptNVlU?=
 =?utf-8?B?bC9lOHZIcnFIQllUbEhFRW80YUxkSUNPN0JKTnFRT0ttVjNLbmlPeWs2aTlN?=
 =?utf-8?B?NUlwT2thdE16S2VOVGVWZFpONjNIdXRTNVpMSTREd2F2REluNk4xOUtmaDJ1?=
 =?utf-8?B?d2N0Z3VRVWE2bjJUOTEzKzlKejlrWXVYbVZsc3MwdERKUGhxZ3ZxTGd1cWxj?=
 =?utf-8?B?YWNmM2FvZUhLM3hQYjljMUJoT0tZcWZSS2J6TmlXaVh2YmplQkY4NCtDVGo5?=
 =?utf-8?B?RDhlWVZnd2U5WCthb2p2Z05QbmtuejhaeC9RWllEMXVSVHRiWVhySGt4VDNI?=
 =?utf-8?B?TzVuSEprKzlpa0FoS3gxcGUvVHdzNStMbS95Q0hLeWV3UnZJejlNNlUvRHBy?=
 =?utf-8?B?ZHl3d1JmNjVYWjZwZ2dSVkVUNllrdEVlZWpTREtuRmZDUHJOQVdKZks5SlhO?=
 =?utf-8?B?bDlzM01PQmg1dEkvMkhNc0hrTFIwK0FQczIzYm1PWjFqYWpRVDNwZ3VEa1lw?=
 =?utf-8?B?M3d5ZUk3bDUwOEhJc1JOelJ1VFV1SkVXZGJndnl5ZktUL1pTQkZXQVlkRWJw?=
 =?utf-8?B?RDJIWDdxLy80WW1RWnRLengwZi9SMk05SG1PZkdnSFAxYTNlZm1iRFk1S05H?=
 =?utf-8?B?UndVdUQ0OEo5aktCUUVqWWhnYXRZeGNzTTJld0ttSnFza0s1TDFNOThueWVI?=
 =?utf-8?B?Zmc3SWdsSTJXclJFNUNjemVrbWFLcUtmcEE3cG9SRlRhYytucXNyQXFtUlAy?=
 =?utf-8?B?V3JZSnFlT25wbTJZdEtrWSt6bC82b0prZTdRR1BtcTlOWnhQbjAvNW5GcHBE?=
 =?utf-8?B?cHk3TFdrU01LSDJNRHo1Kzd6bnhETDFYM0IyY0hEeExXZEdvVlBNcDUrMkts?=
 =?utf-8?B?WFVxVkMvRkpERFdjNDFaWXExUlU2dmR6Ny9LVGhiTHkvd0NXRkJDTzFDbktq?=
 =?utf-8?B?am5OTDZxTllTVFZ1RXp5VnJKM1IvUVUvR0V2VzJCQ3JZY0lQRUgwaHFabUpP?=
 =?utf-8?B?QTZPVUZFM2dGOGd1OE82azk2enVoT21KK3BVQ01NVTA0cEgvMFJVTElmSWhm?=
 =?utf-8?B?VGFrOE1FZ1FEd1BRVlhjbG5zZGxiTDNIczlrRE1DSGMxR1lnMVFLZ0FpVVR0?=
 =?utf-8?B?QWV6cndBQnJTNlJUYm1Cd0V5U2ozNk5JNDB1TndoM2l6SEZOUE1WYlB2ekJi?=
 =?utf-8?B?WVUxcnYwWDlXSGEvRlBlY2VHaUlqd3g2blhORUVYd216ZkhCQ2lPVkEycHhj?=
 =?utf-8?Q?X1FFRd5tK0iPLSlk=3D?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 86237a32-2d26-43cc-6127-08df05fa06e4
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2026 18:19:12.6305
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /BvFZY9P7LXe2KWvPp6MeNvBNl5VwZ0FoZZFyOFWPNuHoOV4t0xUk/HfrHvKNIBbvEgUfnIO/oJrznqpubn8bCm+dlh+ujqwuGduoMDsZg4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR03MB8392
X-purgate-ID: tlsNG-c201ff/1788027557-728B62A1-FFD14896/0/0
X-purgate-type: clean
X-purgate-size: 2491

On 29/08/2026 5:53 pm, Andrew Cooper wrote:
> On 29/08/2026 3:12 am, Jan Setje-Eilers wrote:
>> Hi Andrew,
>>
>> While investigating an SMC forwarding failure after updating to Xen 4.22,
>> I found that firmware could receive different values from those passed to
>> arm_smccc_1_1_smc().
>>
>> Several public Xen callers pass get_user_reg() calls directly to this
>> helper.  This includes the SCMI, ZynqMP EEMI, and i.MX forwarding paths.
>> The helper puts each value into its SMC argument register as the
>> expression is evaluated.  A later get_user_reg() call can then overwrite a
>> register prepared for an earlier argument.
>>
>> The change in generated code appears after:
>>
>> 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations")
>>
>> I am not sure which behavior the helper is intended to provide. Should
>> arm_smccc_1_1_smc() continue to accept arguments such as get_user_reg()
>> calls, or should callers save those values in local variables first?
>>
>> The attached patch is a candidate for the first option. It restores
>> temporary variables inside the helper, allowing all calls to finish before
>> x0-x7 are prepared for the SMC instruction. I am not able to validate the
>> public SCMI and ZynqMP paths on hardware, but their generated code now
>> finishes every get_user_reg() call before the final register setup and
>> smc. With this change, SMCs also work as intended on the device I'm
>> using.
>>
>> If the intent is not to accept function calls as arguments, we should
>> probably fix the SCMI, ZynqMP EEMI, and i.MX callers.
>>
>> Given the existing use cases, this seems like a bug, but your patch looks
>> intentional. It's very possible I'm missing the intended design. I would
>> appreciate your view on the intended contract.
>>
>> Thanks for any advice or help with this.
> Yes you're right.  My change was buggy.   It was actually part of a
> mutli-stage cleanup across several patches.
>
> I'll submit my own patch.  I'm afraid your AI has put in whitespace
> errors where a straight revert would have gotten it correct, and left
> the 0 case still buggy.

In fact there's another bug.  The SMCCC ABI states that certain
registers are clobbered, yet these are missing from asm().

It's also sad that this macro maze goes to the effort of making a
function-like-call which can return 4 registers by value, just to then
force it all to be spilled to the stack anyway.

~Andrew


From xen-devel-bounces@lists.xenproject.org Sat Aug 29 22:01:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Aug 2026 22:01:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403188.1637673 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0R78-0005TF-0Z; Sat, 29 Aug 2026 22:01:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403188.1637673; Sat, 29 Aug 2026 22:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0R77-0005T7-T9; Sat, 29 Aug 2026 22:01:25 +0000
Received: by outflank-mailman (input) for mailman id 1403188;
 Sat, 29 Aug 2026 22:01:24 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jan.setjeeilers@oracle.com>) id 1x0R76-0005T1-EG
 for xen-devel@lists.xenproject.org; Sat, 29 Aug 2026 22:01:24 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0R75-00AduD-RK
 for xen-devel@lists.xenproject.org; Sun, 30 Aug 2026 00:01:23 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jan.setjeeilers@oracle.com>)
 id 6a935695-8faa-0a2a0a5109dd-0a2a4506c442-34
 for <xen-devel@lists.xenproject.org>; Sun, 30 Aug 2026 00:01:23 +0200
Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jan.setjeeilers@oracle.com>)
 id 6a9356b0-195a-0a2a45060019-cddcb12099ac-3
 for <xen-devel@lists.xenproject.org>; Sun, 30 Aug 2026 00:01:23 +0200
Received: from pps.filterd (m0246632.ppops.net [127.0.0.1])
 by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id
 67TLskUj1791660; Sat, 29 Aug 2026 22:01:08 GMT
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com
 (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
 by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4gbq1sgn0p-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 29 Aug 2026 22:01:07 +0000 (GMT)
Received: from pps.filterd
 (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7)
 with ESMTP id 67TM0Xh4000847; Sat, 29 Aug 2026 22:01:07 GMT
Received: from co1pr03cu002.outbound.protection.outlook.com
 (mail-westus2azon11010047.outbound.protection.outlook.com [52.101.46.47])
 by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id
 4gbnvmycjk-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
 Sat, 29 Aug 2026 22:01:07 +0000 (GMT)
Received: from SA3PR10MB7041.namprd10.prod.outlook.com (2603:10b6:806:320::18)
 by DS4PPFE2271E76C.namprd10.prod.outlook.com (2603:10b6:f:fc00::d51)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.9; Sat, 29 Aug
 2026 22:01:03 +0000
Received: from SA3PR10MB7041.namprd10.prod.outlook.com
 ([fe80::e593:4c8b:434c:76d6]) by SA3PR10MB7041.namprd10.prod.outlook.com
 ([fe80::e593:4c8b:434c:76d6%3]) with mapi id 15.21.0382.007; Sat, 29 Aug 2026
 22:01:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=fail header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
	:content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to; s=
	corp-2025-04-25; bh=PopbFllhoJ4sOxgTXbb/ZI/SaV6B4cYpNQriYBMhY8k=; b=
	TViyIZYLPZc22sWJSym8ubavfiAPHyfQVpN28BI5elDBuVAeRG46AglVDrO4SGn3
	gJlthJMB71aFue/MhGBK/BpG6GeOJTyxAV6syEQp+bfOyTi3dcMGpwqyehS9qYaf
	tEN6+9SpmY/EKjEIEwyTLv99OcV2iJeiiEDc8lZJ4tWhZ5T9qWpvdhHZwWrirTaz
	WnEorQycjTJLuqxnwAqOOOVi7obbkT3ScAyEdfXN2uC023LTEuSFZoxpQHGUeVOi
	H7LUEw73bxbUwe8TXvh0XOd5/F7RU9/4HiLwYxBq8/raAVtRGrWLEOhQk9x0bUzo
	y7mHgDDSsNLLMMrkh6HQxA==
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SrKzsBrk7IP1nh/ozNuSsMmg8HR3xPnXTcosFKzVYkCg2+6aGUOwP9tWdnGzJsRAwOey0UsK9zE3cQAjdFW5sRwsLD06FklCJdIii/6JbnnsYvix1nVyOm7h2NB+Q81YJlB9wPKU8hSYd+V17JfDBnatfOznIXXbJGRRNWaeNuxK2ZMP31aIPOIbtjIFsQHQoKb6F3/SzKi3XeKNtU+JLISAnvgbC+no8bQCObVkXRadF++KaVRVkA3qBCw4lvBspDjD6qweOk0J7omJ5y+OPUbBPUuDaGuNX989LwcvtStqYX7etdqoTmhmes3cmNMATUKJvtC8nQ7vRi54CXAFIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=U1kG4myDpqbheIIqGkuoL+on0QP1GBAL358gjZKTDyo=;
 b=I7n+kALAc821Taxn3LQBcOBC5YQEOnY2RPPlaIrTsGIQ3G3616/i95nj1bZxZWOaVFli8NCx8VGADRLG+6u+2K2xB33yOqCpaKfhFlARFk4cQj4v/z7Z2Lmw5m27Gwtp9JNVzVxK/Gg/nFUx5V4VSyv3hkamu5BDKbc90DwZf+Ymp2SxqvJQozojDgDvEu8QgnjahY2orD1pLesD3mNinnkUvb4fcbSVI+EKDTyIXsi0DZu8o7oyGOUkuYnnrOARljOQ/sb2TFBLEBwm1KmjRPEIvnYMmOY+uzsGX0pxVhC+rTFpcyzXc/2wqOZghcVhqmWwjeqwvxJqbzIEDMf9fw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
 dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=U1kG4myDpqbheIIqGkuoL+on0QP1GBAL358gjZKTDyo=;
 b=LQdRaTdMeN4eq5OpeHlKMU11HpHtyYqYkcnSp1f2NTL8oYg0XldCV/BgZAdl4fOexxsvSUqo3Sa3EbbDae3ddI4Wf1oGyNk+7WYWKtK3hWFk+bLOgvQZ1lxt1E1q8zjpEQSFFetZrjsJDjcWLQqD2uTzzGXPkuD3w5DSQa01swc=
Message-ID: <e85a139e-ea5e-4630-9006-f50877533f71@oracle.com>
Date: Sat, 29 Aug 2026 15:00:48 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 0/1] xen/arm: smccc: preserve arguments before
 register setup
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
        Julien Grall
 <julien@xen.org>,
        Bertrand Marquis <bertrand.marquis@arm.com>,
        Michal Orzel <michal.orzel@amd.com>,
        Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
        Jan Beulich <jbeulich@suse.com>,
        Joao Martins <joao.m.martins@oracle.com>
References: <20260829021257.3310112-1-Jan.SetjeEilers@oracle.com>
 <5286d0ad-5068-43dc-b23d-e18f05ae4b64@citrix.com>
 <31e8bcf2-480c-4f32-8096-877a0fbd327e@citrix.com>
Content-Language: en-US
From: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Autocrypt: addr=Jan.SetjeEilers@oracle.com; keydata=
 xsDNBGetHhIBDACa4fBRw0+D/y8p0kzZyJ+K5pisnqCKCFVKtAhVYFJjzEoUvVtqKJpjZaWp
 JtlNQ05u3GZKofFptGJmXJZtttujfE6iWqjFVcm1SUo8kSRSLQ+AxtfAot319Do73k/uhfQM
 71+cX5pO6EybCrr962npOEfe6yNbZ3UmszrbmRORw3aI9g/VHmC1SwFj3Gq0KHBQvEB89J6F
 iDgrHGnQVyQDmCBF6n6mqSJFV/fWK6XeGSj/T/R+8osU0FpXcsZ4OCY9eyJ23zY1M2f2VEV4
 B61+UW8orqgXe3mADI0yLP0onViD2UHqV6EDjLWN1ukUkJUoPWzv65LyU1sAw0rKPELvcl4/
 rzJPiO8FNMjTp4jibe46Spyh5BKYxN54m8zAF9D9uHA1IX9pJpNRS2uKEnZWHJx1Ew2GZINv
 8VDhpPxJP4p4ArZMSzAsNKYSqyuXyQ8Fcn7DCwI8E4tl6tRNacBkf1ByF30oYFYFg1pbMIQm
 4z9BY01cBMB59/50dy3QF3MAEQEAAc0tSmFuIFNldGplLUVpbGVycyA8SmFuLlNldGplRWls
 ZXJzQG9yYWNsZS5jb20+wsENBBMBCAA3FiEEvrH8dyNhbaVzmqUqqJoDwbaIAmsFAmetHhIF
 CQWjmoACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRComgPBtogCa8z7C/9cotiLsRfmhl4NV+bo
 40hXUXFNqgr63P7/KekI2TnDfV5Ilsy9UcXWFZC8hGGLVPTvZB0Mrf9jsTPvqm8gykr7E5Ig
 Hqu4U2RP2/aBu943Nhf+bf+s0MluJu6zZoI0G3WvoX5SzSdBJM6MPyyYnC9v9f7AFL3iGRaM
 2/XY1to7hhxMX0Y+iRYi30GMvaZtZk8zLn7CEj91kwAUDM8a+5oUPLgV7UsKJrZ+dPSzkavQ
 4jND6CY6Ln4EALdwyheNHkcgUNe/784jrnmFS+7uPX0uO80d9P1XBGv/7sgDssvGTpNAxO6K
 zdns59r+oCIeb1DrfuqPGPEa12IKkSjlbaf67WMr14yQv6kfgzvYfNOjTktKpQvjyZCfC+5k
 Hi+LYfh9AItZTTcDl0D7neTfD6gkFyNKG7c11usFnb3ge7EiV+a+/HKQh+pUeYdL1DOJc0K4
 YuvPyQZQuHIRp89EDlsxZA3sNelO7qGe7BtezD9CEbl33W4DcITMjfrFoJUPaoPOwM0EZ60e
 EgEMAL8iSzF7Xf1zSD/RovAnH6iVjVwsDyd6oKU/2t4DdupE1vrcYBj1D/rUPKLI/O5xgT0t
 I1uWLp2+45uN/CQDDiyE5+Wcp9cbhV9eyTfFJ1PrGB7EDthKhvZb89f7tG9wI60QPBTmVIRl
 Fn1QtBGxij6YR+Su/054SW0g5O1ywT6HZy9ebdNfx/jSTM1FTSvP6JNSJoHVwLeHgaZHOTqe
 hJHalwGQJIxU7jSmMgvIF/c6SrJyQhjlH+th0hev83DhoK1JEUZWwEuz3yrALwr20DV8f81D
 qUqiGPalGsi46h6hj+M8QEyHS3sFeDA//ZvDU5sOecPgmRm6QyRRFXyuHV/b3jBYJJcc4tdI
 wJ7de8Np2/yctt9OlvvNP/KQdz7HbdVMdCXWtxgjMcalzseE3w2IH6SIxQ2Fwwzr6BZUYx92
 ePxU6EJfveCpizfZBKRnjYdl/gLJJEW322QDnZFpI6FPaLnGgPjMhFuz1qQAPYmRByC4W029
 jE+4cS93yyFScwARAQABwsD8BBgBCAAmFiEEvrH8dyNhbaVzmqUqqJoDwbaIAmsFAmetHhIF
 CQWjmoACGwwACgkQqJoDwbaIAmvmZgv8DAZ8XQnunSonH0N5HMa9qaQafl07cfd8jVk4IFH9
 UPIH0463s/0oVJV1hlcqqqk0nZKwobflIrehB/TSSaLnAoy9b2raOKNbj0ppZdoGCm+S3z67
 O1c7cx8vQ+nnSe4E+Ko/J/8e4FOYhFUOc4lmIn4ByK+SBKitAkOYI64ugunvGZLj1TV+b1Wf
 wiWaJUGmzZkjIU2T6J8W1riYn1KW2uNheJQU4/sVtBc6j/hIqccTKBpx0qTszeZnFa28aGkg
 t2BXv2TqaA7yzbLymTRG4JHRlc9LQ2tHjIjkRBGXpiOG26S7JoeHz+QCqSK2XPp+LP5/XhTk
 Vvb8FjeyBuJ+Q5RK2vYk6Ws5ua4G1p2AUs0w5SpRxpLUTuTVlntyXQfp7Pa42oX364UOGNrY
 c+ddxSb+KW13sbIRslW8+LWdvNH/VgPKC3SkblSG5H/e3sfLsA3DAmu886allZ82imnPRlYH
 /epCCdHbjMyPhatWd4WT2RFakWMvkwGDSJUd50h8
In-Reply-To: <31e8bcf2-480c-4f32-8096-877a0fbd327e@citrix.com>
X-ClientProxiedBy: SJ0PR05CA0199.namprd05.prod.outlook.com
 (2603:10b6:a03:330::24) To SA3PR10MB7041.namprd10.prod.outlook.com
 (2603:10b6:806:320::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA3PR10MB7041:EE_|DS4PPFE2271E76C:EE_
X-MS-Office365-Filtering-Correlation-Id: cb53058f-f59c-40d6-2bd0-08df06190465
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|4133799003|18002099003|22082099003|56012099006|3023799007|4143699003|10067099003;
X-Microsoft-Antispam-Message-Info:
	sIMU8AzTjUdNQP5XBbuXtT4GEDPsWLiToYCgHKsslsSRNSMNTUsDoYZRrNtG6w5zqdnjqnUM5dHJiUzo/jwTOMQj3Rln7P2NeDzQukE/PT5f15PtidvJmjtX2BzUZAylvk9EpXYcfEEEZ23nvGIkDcvUamTar9HI3uV2rHxZJZLwcdzVDmj+aQRbcJQvFxGEufBdGxM12U6IXTJcWm2NPbHSIi7h25OTJEyl2QqYr4ZjjUZw/c03wipwcwYmDLkSBTTDWEVAepJ79YfnHxgbYMaVR3ZRzi2PhZedPC/CtW4Fcul33SKfYR5Ji6oQ6tE1QnAtiB80s/J0FBKM6w4lY6MbO23TcAzaa2b1lqTNv9qPyDlKDoMV7RHt4Xxn9VMfuLrWD2+DVk+K4N2SS4ILAdUjILlu7jBFTW+gnNiG2D4ufAYB5bXdgnHmBse5ik/75Ls17LWf3QPCpdHf/84H3UO1Jrgpg5i093n09cUErnVUC0CLURbEkdxO9F07jc+oWWvkRS50DjGXObGxVCJ6nTb4GqyCDxpWffv6FUIJ7VHE9Gi/r2PsWGc6AsPKw7JvD+V4+srP4+SKTnKqLG6wiA6N3YwTnI2+aP12NVoUcut9WgLD4NKuTaQ1o/Sp9BIfUId9hczHI7rhgnLOHDv9XufrcnSZgwbuRz8Kux8JsiQ=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR10MB7041.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(4133799003)(18002099003)(22082099003)(56012099006)(3023799007)(4143699003)(10067099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Y01yMlBsSE5oNUlrWXh0UmZwY25IS1BMTW11Zjh4aFBsc0VlMlYrSlpMUHhj?=
 =?utf-8?B?bXRwOTVXc2RnanNPWGRtdmpnTXhwR2FQQWhCQjVjQSsyQm5yOVJaS0RiQzBG?=
 =?utf-8?B?enNlNkYyUnpyZDU0Sk9kcElCWW5HMFZDejhuREJYY0FkbGRRcWdlTEpVU2Rj?=
 =?utf-8?B?MEJ1NUdJRFowcVdXK3ZSU1Fyb2IyMFN1L3hwdEtwbXdRVitZMkpLYWVFdjJk?=
 =?utf-8?B?Z0l1OU9DQlU4SmJmUHMvdCtTYy8vRXJOVEhXaDZHOFZHN2Z6V3pCdXBSSE9F?=
 =?utf-8?B?c2x1bU5wWUZUNCtmZ0NlWDZ0bTZwY1ltOGVYT3BQcStCQ2xSRVBsU3JXZXBx?=
 =?utf-8?B?anBlOVl5VnlZZVdzQ0RScGVISWt6VWdDSytFbTQxM00wM1gwSytsV3RuZVBz?=
 =?utf-8?B?bTI2ZDhiKzNHVWJZMDc3eE5KSUl2Q0VLQlZURHo4a2lWanRDQXE4TkN4a2VO?=
 =?utf-8?B?OFRTM3Y1TWtsellRYlp1SFFjQmpEV1hZWGdmNFA2ZGlvSzJNZFNGV2cyU0Nm?=
 =?utf-8?B?S1dnZ25PUzR4VHlEa1hrc2JkVkt3UVRaM0g4bm45cVBKWllSeGRZaE9aMDBo?=
 =?utf-8?B?b1R5QjNaSjhXVDNpQnNpcisybDZ3Q1piV3BHM0ZvUTQ3Nm02aW1aUTd5YWp2?=
 =?utf-8?B?QU5ja2w4OEZUYUZ5THo5R0IrN2huSkpwdklFTzBWMDNFTjBJL3UyVHRTdGU0?=
 =?utf-8?B?dGFGbHBFZm1qVUp1WU1VeWRwYWw0V0ZaQis2dUl2MWFoaHM0eTVwVEdhSkdr?=
 =?utf-8?B?bG5sNUhvYnZ6QVloanQ4RnE3aGJmWnJ1Sm9RYStPRlREa0F0VnJtSkxhZTIw?=
 =?utf-8?B?SElHVDNFZXVWV2ZSSXJ6UjRlUUdPeXlrRWQ0M2J3S1dsT3RvMndXWW1RY0Jq?=
 =?utf-8?B?MDg5bTBVWTFaMW1ubGphaUxRZklWZXB3OUk5dGwzd0NWQWhERERqdGhsUlRD?=
 =?utf-8?B?SWJIdEphOHZHMUQ0SWhxeFo5OGNSaGxBMGR6a0szQ1EzNlRFTk1IT2ZDV0JM?=
 =?utf-8?B?b1BiWTdZYXNMSW5uMnBiMTRFcHV0SXJyVWpEaStVQkRMbFhtZ3RUa0czM2sz?=
 =?utf-8?B?djJxbW5JUmR1dExwblFZaGNIaHhuZ0NBMVp0YWxFUGNlSmwrMzFuNmUvbDB6?=
 =?utf-8?B?Uy9XNmM5dVYyTk51NGh6SU5NSTdmN09YVlExQmIrTUt2T0tVRDdKRjdkaCt0?=
 =?utf-8?B?UTF3UnBINmNjbXNGTXk4YmlHNGcwdzJFQjBkUXVQSkFUQlg4UVhmYkJkYkgw?=
 =?utf-8?B?MjFCTWhMMm1jbjhIbGVzMndmTmYzdlhiclVaY2Fadm8yeXdKZ0RDUTFoSm5r?=
 =?utf-8?B?RlBVL1RDdE1SY3J4WEFFdTNlSUlKSjduTDJuNWdYdDFPK2krT1dYRHFVeU5t?=
 =?utf-8?B?RkUzOGY4Tm1MTkhWa3Y2R1JNaWhHTlRleHRma0VNT0pnMGdqcXI1MU5WMHYy?=
 =?utf-8?B?SElCWTlnWW1tc3AvMHpKd252N2EydjdON0FvSmpZbFc5aWsvT1RBVEt3cnZO?=
 =?utf-8?B?d3dRTjE3VkFSZmo1eFhzTE0zMXZvYi8zQW11SDMvc2UxUHROSno2MjNTb3Qx?=
 =?utf-8?B?M0Zxd21SbDl4NGFsbFJOTE85eElDTkcrOVlEQ2xobWxETkgrcktEK0ZhL29a?=
 =?utf-8?B?RlZWQkE5S0VxZWRJZlJXUGpjd2RwTUFKVzdEdXNERnU1TTlqYng4WHhWSjhB?=
 =?utf-8?B?SVVBc2ZRY0ptV2JPQS9weC9HSU0vTXZYQjNzMXFqZEpiSGM1andDbUxCYTZR?=
 =?utf-8?B?R0lZK2tDRThJcDhvSm1PaVc4WUV2dk5Uck5FeWk1d1ppN1RTZHpVNkVmTEhL?=
 =?utf-8?B?VE8zTERQQmdMZGg3T1orcDFmVnY3akhEY2I5a3dQMHIxNUhSb2VRb2o4L21z?=
 =?utf-8?B?cUQ5bzFDU3VZZDh3QzJCb1N1YXo4RDVIaXVHRDF4Mmp3OWxVc3ZwOG9oNjVh?=
 =?utf-8?B?NEZaQkRTekVWRGRCcFduKzBaNCtGWUZyOGlLbGdKYnFRNzZqT0hhM0JidEhh?=
 =?utf-8?B?VENNUnV6elhyaW45ZUZqNlozUE5OR3I3KzhnamErTWwrOXU4Q3hLd1pwOVds?=
 =?utf-8?B?SE1yTFVsWW94d2FVUHVJNXBKWTcydy9iek51cHpCeklUUEpmd3dGeTlrN24x?=
 =?utf-8?B?QzZyT1dBRUQ4eUVqMFNEeVZMdi9jSjBLVHppb3J1RjZuZnRlWjh6WVlLbkFj?=
 =?utf-8?B?MWZTSk1sVXZ3T2tqREIxTE5NdTdQeitNNVNEa2hsSWdwbHVlSVkzci8zTkUv?=
 =?utf-8?B?SU1ZblhpdC9hdk9LSkpvTmtLSG5oU2J1d2JSdGx2bThoUk43YnQzMTF3TFB3?=
 =?utf-8?B?eXdsY2dUSlF4S1ZZUFd3ejlTLzQyNFlicUpiZ3RMcDlLSnNQTzNzVWhjK3g4?=
 =?utf-8?Q?rlDcmkTNl7j+Rgr0=3D?=
X-Exchange-RoutingPolicyChecked:
	g3nK+EaPQN1WxNVFDpTVx2miV6paWvmlHvfBwqMg9ZzAjnFHCW6n8BqTCNapMX/lhp3avQmwnIQcYPJ05p8E4RrCAofMJzKp0dNABWt94eWegJXY3VIznBY09YwQzB2GFvca6rUHBuU8BL6Xz+7WHU5M0Smze1n+3thTHUV1095xQNmULSFGIWOVX3qDs8hUszfXl3ZsTSTyNNiw78S63zAg5JLt1B6P2YUxC4QllTxk+A1z9I0vScOMRePnBG/DpjPOs2XMAlPjGVHusyT+LHIgKEtm9veHJ6zGhRuJl/nuDjZCWvek6eKDuEZJIBsmr+wtDAQ0fFbSp2F8EQ3kig==
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	vrXQUbg0yVMLk3BcSvXaVen/0F7Z0RCIcjPTZOpb8euMGv5jN2lK97gP/YPCVCxPWzqyGvcOg4co2FYNZdaUlFTVubxBlR3et66vVjmhGwxx/VP/QRQh1jqWzKS1fRRSGDOVX70O76sAi+8vXW12G1EkZcFwoec2OahPE6+Tlqh+NAXBcmIYkU4RSoCJEPbzJlDlGTXZm3T4RoLn5TL3b6x/xlnyn5afXGImgy0amyNJIU+7Xb9Hkp3OfqS3luLPMoagj0upooCRpkHNUOT2haWeQMpI8tqh7xA1cOwr8fhZ4Z6LOx71ggY4QGzOIJPF0qxRSu0m2WvY32xlhoMbsYO6EeQnGa+S6dHM35uEY1RBN6+XT6u3qxrxgcYL2462/Nr4ogEwYQ+N3dIe9Gugcp67GL91BIG1OUP5Bg8OyLiFQXRTdAvtg6Awzf+GQMQXYpioZpUKWAJILsiBE2LddcRk/P8FRNCn04QwpNOYPaTDysZr4NvVC8VEMkaA53DozCxE/MOSFj+Ysz3sDt/GstuTbS1Mm/4uvnzmRwwi617DXQuwcv29WG408T2OrOx/2CgrExOx2JrYOkl6FYOLddHbE7wiVhlzhLPq1nCrIkQ=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb53058f-f59c-40d6-2bd0-08df06190465
X-MS-Exchange-CrossTenant-AuthSource: SA3PR10MB7041.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2026 22:01:02.8953
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: fPDTF7z1vlbUMZHXUminyQlEH/84e+9qVvCd0Y2PsfhUIpqRf/f5L/VNFUaZrWhDHy66s8FrWP12xbiJEv7CorOYZzyRio6ejjMU6FY6TBg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PPFE2271E76C
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49
 definitions=2026-08-29_06,2026-08-27_02,2025-10-01_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 adultscore=0
 lowpriorityscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2608290191
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Authority-Analysis: v=2.4 cv=Vp0Txe2n c=1 sm=1 tr=0 ts=6a9356a3 b=1 cx=c_pps
 a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17
 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19
 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10
 a=Sv0fKeRqtYgA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22
 a=jiCTI4zE5U7BLdzWsZGv:22 a=3I1J8UUJPc9JN9BFgKH3:22 a=RpNjiQI2AAAA:8
 a=dEnvS2v33luOMeR2ZAMA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10
 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:12102
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI5MDE5MSBTYWx0ZWRfX/s2IhNxXR8qC
 WumnzWlwCysFPjDxBU6FgwVUH1CWaJlibk9NJXwVvy6ZfOI+X+MTPrLwbEAMZ60RZSN++VILQhw
 7z2I8fmsoM9wMOUj+7lVt/RC7K5//E33DBKw1yzr3lYNbPrf3kHRqFn95YqSMBRVGCdKLCT9ltm
 ac4YuNkitz6gauh8o7lsVmhpYDSCXT9rBp7y+4Y9mlEt2iWAwS9/onObb78+VDFqttFS4p3NmBv
 E5k84sHV43Np01TMDfL4hyM8TEmJ7YZfyNVosAsHrOSx6HnII+JD5DvQX/a/Zwq+AQjTlL/c9yQ
 Z8kjXUXZ20n4RCOH70LwCdcltF5CYkBauL5vc2L0cRCBRjfiXs5UDky6qRuxxkRk3jQWQlmm9GC
 yG4ZWhn2bi3fBnkcrf/MU16GE281MQfir6RieKVP6nbdeJRS3Ty86mOLkFp6E2tUGSjLsqxqQYS
 YFoM3nalDDA9oA4WmyFt3zLklqgfbsH35vHDo3t8=
X-Proofpoint-Spam-Info: AW1haW4tMjYwODI5MDE5MSBTYWx0ZWRfX3dkeurIBLYuK
 +ZGV+k0v7giKzOY5gKvm2RO0t0L4OVjbjPDsP0pSvIAG0ClmvwkTJq4uovnqXQDyxeVqWNvtMBS
 F5MNbadJ6jKQdyW9FsjB7QabevFX5NoGOalJYAIMrf1/gsIGzNU8
X-Proofpoint-ORIG-GUID: XMP9tEUjQO1GAxvGiOMgWO-X9ioP4KXh
X-Proofpoint-GUID: XMP9tEUjQO1GAxvGiOMgWO-X9ioP4KXh
X-purgate-ID: tlsNG-16d1c6/1788040883-FDA0C77B-A3B96EAF/0/0
X-purgate-type: clean
X-purgate-size: 3374

On 8/29/26 11:19, Andrew Cooper wrote:
> On 29/08/2026 5:=E2=80=8A53 pm, Andrew Cooper wrote: > On 29/08/2026 3:=
=E2=80=8A12 am,
> Jan Setje-Eilers wrote: >> Hi Andrew, >> >> While investigating an SMC
> forwarding failure after updating to Xen 4.=E2=80=8A22, >> I found that f=
irmware
> could
>=20
>=20
> On 29/08/2026 5:53 pm, Andrew Cooper wrote:
>> On 29/08/2026 3:12 am, Jan Setje-Eilers wrote:
>>> Hi Andrew,
>>>
>>> While investigating an SMC forwarding failure after updating to Xen 4.2=
2,
>>> I found that firmware could receive different values from those passed =
to
>>> arm_smccc_1_1_smc().
>>>
>>> Several public Xen callers pass get_user_reg() calls directly to this
>>> helper.  This includes the SCMI, ZynqMP EEMI, and i.MX forwarding paths.
>>> The helper puts each value into its SMC argument register as the
>>> expression is evaluated.  A later get_user_reg() call can then overwrit=
e a
>>> register prepared for an earlier argument.
>>>
>>> The change in generated code appears after:
>>>
>>> 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations")
>>>
>>> I am not sure which behavior the helper is intended to provide. Should
>>> arm_smccc_1_1_smc() continue to accept arguments such as get_user_reg()
>>> calls, or should callers save those values in local variables first?
>>>
>>> The attached patch is a candidate for the first option. It restores
>>> temporary variables inside the helper, allowing all calls to finish bef=
ore
>>> x0-x7 are prepared for the SMC instruction. I am not able to validate t=
he
>>> public SCMI and ZynqMP paths on hardware, but their generated code now
>>> finishes every get_user_reg() call before the final register setup and
>>> smc. With this change, SMCs also work as intended on the device I'm
>>> using.
>>>
>>> If the intent is not to accept function calls as arguments, we should
>>> probably fix the SCMI, ZynqMP EEMI, and i.MX callers.
>>>
>>> Given the existing use cases, this seems like a bug, but your patch loo=
ks
>>> intentional. It's very possible I'm missing the intended design. I would
>>> appreciate your view on the intended contract.
>>>
>>> Thanks for any advice or help with this.
>> Yes you're right.=C2=A0 My change was buggy.=C2=A0 =C2=A0It was actually=
 part of a
>> mutli-stage cleanup across several patches.
>>
>> I'll submit my own patch.=C2=A0 I'm afraid your AI has put in whitespace
>> errors where a straight revert would have gotten it correct, and left
>> the 0 case still buggy.

 Thank you!! Yes, a revert also makes sense.

 Heh, the bulk of my AI usage was actually to try to make sure I hit all
the project rules and formatting since I'm much less used to some of the
style here. Sigh. :)

> In fact there's another bug.=C2=A0 The SMCCC ABI states that certain
> registers are clobbered, yet these are missing from asm().
>=20
> It's also sad that this macro maze goes to the effort of making a
> function-like-call which can return 4 registers by value, just to then
> force it all to be spilled to the stack anyway.

 The other way to do this, if we're actually trying to minimize
instructions,
would actually be to create another interface that does something like
get_user_reg() as part of the invocation. Then that could be a single
assembly implementation.

-jan


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 01:15:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 01:15:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403703.1637682 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qbj-0000Rx-Vm; Mon, 31 Aug 2026 01:14:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403703.1637682; Mon, 31 Aug 2026 01:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qbj-0000Rg-Qi; Mon, 31 Aug 2026 01:14:43 +0000
Received: by outflank-mailman (input) for mailman id 1403703;
 Mon, 31 Aug 2026 01:14:42 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1x0qbi-0000RW-87
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 01:14:42 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0qbh-0010Am-35
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 03:14:41 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d566-8faa-0a2a0a5109dd-0a2a4505b096-6
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:14:41 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d57f-4cb1-0a2a45050019-ac6904fea29a-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:14:40 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id E4FBE60120;
 Mon, 31 Aug 2026 01:14:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E8D51F000E9;
 Mon, 31 Aug 2026 01:14:36 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1788138878;
	bh=MZSVCQ3Ufblu/TkCyjD4ASm3zUat//7t6XAPFIhWzqo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=FNQn2lOP18icOOBGspsLVDQUJfh9jlpYcKiQFGr5kEGwBb/okpm1nKqXxEjtQjDJA
	 ZPNTPVssFAwJ1x4JD8N4Uj2/UxQpqVJZiyBG26OXjXxCzLu7XaVfOVIE0ko6n1zI4v
	 +laE/UzPkO1UympUy1DJ5zCGH7OLMle/KY6YEEo38YQryn4DbT0RRmUd5GwEgc5hr5
	 pinbQo1KcMOuRBS8ZnP5ZH6uo7S5iDZqnn2F+cTmWBpLMvFIxk4CD7iA8Z93XB45BD
	 TANsKTDmd2DllPizTIswGjCfHRqMQkpRFWnrhDP2qbV6fL3ifsWZ/Ba43u4mpc3FpH
	 EIsE2fP2eKl3w==
Date: Sun, 30 Aug 2026 18:14:31 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Nicola Vetrini <nicola.vetrini@bugseng.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Subject: Re: [PATCH 07/12] altp2m: address Misra 2.1 rule violation
In-Reply-To: <6e98181c-459c-4c45-b8c0-c427e3c0bbc8@suse.com>
Message-ID: <6c8b33f6-4c84-6440-0347-b3a3e1ba639e@kernel.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <6e98181c-459c-4c45-b8c0-c427e3c0bbc8@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-c201ff/1788138881-730B22A1-CB8BF681/0/0
X-purgate-type: clean
X-purgate-size: 1096

On Fri, 28 Aug 2026, Jan Beulich wrote:
> The stub altp2m_vcpu_idx() is recognized as "noreturn" function lacking
> respective annotation (or having a return statement), which hence is deemed
> unreachable code by Misra / Eclair. All call sites are guarded by
> altp2m_active() checks, hence an inline function isn't needed. A
> declaration will suffice, with call sites then getting DCE-d.
> 
> No functional change.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> --- a/xen/include/asm-generic/altp2m.h
> +++ b/xen/include/asm-generic/altp2m.h
> @@ -14,13 +14,8 @@ static inline bool altp2m_active(const s
>      return false;
>  }
>  
> -/* Alternate p2m VCPU */
> -static inline unsigned int altp2m_vcpu_idx(const struct vcpu *v)
> -{
> -    /* Not implemented on GENERIC, should not be reached. */
> -    BUG();
> -    return 0;
> -}
> +/* Alternate p2m VCPU - placeholder on GENERIC */
> +unsigned int altp2m_vcpu_idx(const struct vcpu *v);
>  
>  #endif /* __ASM_GENERIC_ALTP2M_H */
>  
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 01:22:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 01:22:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403710.1637690 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qip-0002AZ-JJ; Mon, 31 Aug 2026 01:22:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403710.1637690; Mon, 31 Aug 2026 01: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 <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qip-0002AS-Gk; Mon, 31 Aug 2026 01:22:03 +0000
Received: by outflank-mailman (input) for mailman id 1403710;
 Mon, 31 Aug 2026 01:22:02 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1x0qio-0002AM-8i
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 01:22:02 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0qin-00DBK1-2l
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 03:22:01 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d713-e002-0a2a0a5209dd-0a2a45079058-20
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:22:01 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d737-b4ea-0a2a45070019-ac6904fe97b2-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:22:00 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 473D360120;
 Mon, 31 Aug 2026 01:21:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B39751F000E9;
 Mon, 31 Aug 2026 01:21:57 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1788139319;
	bh=LM28nnXh2PAYfx3Qel8y5yFZ3jkgPhXYl/GMsr+C1zc=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=Fm3kddWYYmsjo5qWDk7GvvBhikST23fOJ8mVzpM2xZcUufPILGGb5FnZdigfhbgjp
	 jLrMm+hsdcKxFa84qHM+8CqGddN/3PBlyZpNATxI32R70VbDdpoySpgzcfPIz+ghRy
	 6u+S1BkXcF0Ep0Lvc3xAaNlHfRfomegxHFYLg++MyVgi8f7VEthroZa6qVm92VAMWy
	 LfDrBs6tcNysEaWQEV1XI9QTOtER3E6DqCjgJ0gQY8exTlFPn9AAzN1teGcpOibdwG
	 cCLlciEXtqVe8wctrfh0Zgw2GZurZX2OhVvr8vwASUaiixSoEqyPb+3e3hcyIWI9y2
	 sIuTCIiv1Y9XQ==
Date: Sun, 30 Aug 2026 18:21:56 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Nicola Vetrini <nicola.vetrini@bugseng.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Volodymyr Babchuk <volodymyr_babchuk@epam.com>, 
    Bertrand Marquis <bertrand.marquis@arm.com>, 
    Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH 08/12] Arm/GIC: add noreturn in a few more places
In-Reply-To: <afa5c348-744a-4a4b-8b00-2971ca3376cd@suse.com>
Message-ID: <73d783b8-81ef-43b5-e58f-394acf3d9183@kernel.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <afa5c348-744a-4a4b-8b00-2971ca3376cd@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-ef75cf/1788139320-350CDAE4-8EE5B7A6/0/0
X-purgate-type: clean
X-purgate-size: 2250

On Fri, 28 Aug 2026, Jan Beulich wrote:
> LPI related functions having just BUG() in them are disliked by Misra /
> Eclair, as long as they don't also have a noreturn attribute.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> >From its description "Unreachability caused by calls to the following
> functions or macros is deliberate and there is no risk of code being
> unexpectedly left out." I would have expected the respective entry in
> deviations.ecl to cover all of these cases, but clearly that isn't the
> case.
> 
> Of course having noreturn on functions returning non-void is somewhat odd.
> 
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1315,7 +1315,7 @@ static int __init gicv2_init(void)
>      return 0;
>  }
>  
> -static void gicv2_do_LPI(unsigned int lpi)
> +static void noreturn gicv2_do_LPI(unsigned int lpi)
>  {
>      /* No LPIs in a GICv2 */
>      BUG();
> --- a/xen/arch/arm/include/asm/gic_v3_its.h
> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
> @@ -229,7 +229,7 @@ static inline unsigned int vgic_v3_its_c
>      return 0;
>  }
>  
> -static inline void gicv3_do_LPI(unsigned int lpi)
> +static inline void noreturn gicv3_do_LPI(unsigned int lpi)
>  {
>      /* We don't enable LPIs without an ITS. */
>      BUG();
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -718,14 +718,15 @@ static void vgic_v2_domain_free(struct d
>      /* Nothing to be cleanup for this driver */
>  }
>  
> -static struct pending_irq *vgic_v2_lpi_to_pending(struct domain *d,
> -                                                  unsigned int vlpi)
> +static struct pending_irq *noreturn vgic_v2_lpi_to_pending(struct domain *d,
> +                                                           unsigned int vlpi)
>  {
>      /* Dummy function, no LPIs on a VGICv2. */
>      BUG();
>  }
>  
> -static int vgic_v2_lpi_get_priority(struct domain *d, unsigned int vlpi)
> +static int noreturn vgic_v2_lpi_get_priority(struct domain *d,
> +                                             unsigned int vlpi)
>  {
>      /* Dummy function, no LPIs on a VGICv2. */
>      BUG();
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 01:30:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 01:30:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403717.1637700 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qqp-0003wM-CY; Mon, 31 Aug 2026 01:30:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403717.1637700; Mon, 31 Aug 2026 01:30:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qqp-0003wF-9F; Mon, 31 Aug 2026 01:30:19 +0000
Received: by outflank-mailman (input) for mailman id 1403717;
 Mon, 31 Aug 2026 01:30:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1x0qqo-0003w9-8t
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 01:30:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0qqk-0082bO-Sd
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 03:30:14 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d8b4-e002-0a2a0a5209dd-0a2a4507e2c8-36
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:30:14 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d925-b4ea-0a2a45070019-aceafc1fa8be-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:30:14 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id 7DF64432CA;
 Mon, 31 Aug 2026 01:30:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED6C91F000E9;
 Mon, 31 Aug 2026 01:30:10 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1788139812;
	bh=gYGfnGFJTXbEfakCk51c5TR3KJNtqIiI6ujZwN+xW6I=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=ZJ+pCqUiD4a/m4yvv8rzEP5BGRoxWi0TR4GIV7j0bo929AfV/5psDDhv3GPmf3gMt
	 j4J+JDS88F2G86e2Z5RXlLKHSk0b74q/9VxZaX6tKRlRrNMKjargzoj6e3d5Zu8h0E
	 Tw5PeMSMhtMFILJBCuGAVekv4n97tUdaMrlcb4Dok6uxJMBZ3eVm82e8SVgv7gR5/C
	 DRajpcwtkHeD6P6MnlqoBbXf94bqH7DQW7qXI/YgCwoalA15FU9kGAJQLib5b6fTPg
	 119QmCFFs4jBod4pDwMuyNbVB+HWssiPKqnh3Z5WrCf4FI3ZSfWB98y7Ah0U7iOyg/
	 J12EBAifWObUg==
Date: Sun, 30 Aug 2026 18:30:09 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Nicola Vetrini <nicola.vetrini@bugseng.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Subject: Re: [PATCH 10/12] PCI/physdev: address Misra 2.1 rule violation
In-Reply-To: <de8eb6ec-b830-47c2-95e7-e0b689f05cad@suse.com>
Message-ID: <b338dc69-d94f-415c-07c2-4b4b7731dab1@kernel.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <de8eb6ec-b830-47c2-95e7-e0b689f05cad@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-ef75cf/1788139814-364DBAE4-319494C6/0/0
X-purgate-type: clean
X-purgate-size: 759

On Fri, 28 Aug 2026, Jan Beulich wrote:
> Cases 0..3 are handled, and a 2-bit mask is applied to the switch()
> expression. Therefore the default: case is reported unreachable by Eclair.
> Insert BUILD_ERROR() to annotate this for Eclair.
> 
> No functional change.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> --- a/xen/drivers/pci/physdev.c
> +++ b/xen/drivers/pci/physdev.c
> @@ -114,7 +114,7 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_
>              break;
>  
>          default:
> -            ret = -EINVAL;
> +            BUILD_ERROR("PCI_DEVICE_RESET_* inconsistency");
>              break;
>          }
>          write_unlock(&pdev->domain->pci_lock);
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 01:30:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 01:30:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403722.1637709 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qrR-0004MU-JO; Mon, 31 Aug 2026 01:30:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403722.1637709; Mon, 31 Aug 2026 01:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0qrR-0004MN-GG; Mon, 31 Aug 2026 01:30:57 +0000
Received: by outflank-mailman (input) for mailman id 1403722;
 Mon, 31 Aug 2026 01:30:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sstabellini@kernel.org>) id 1x0qrQ-0004MD-Ou
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 01:30:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0qrQ-0082jR-64
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 03:30:56 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d93c-bab6-0a2a0a5309dd-0a2a4506d214-20
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:30:56 +0200
Received: from [172.234.252.31] (helo=sea.source.kernel.org)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sstabellini@kernel.org>)
 id 6a94d94e-195a-0a2a45060019-aceafc1f8246-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 03:30:55 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by sea.source.kernel.org (Postfix) with ESMTP id E877A4079D;
 Mon, 31 Aug 2026 01:30:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F6111F000E9;
 Mon, 31 Aug 2026 01:30:52 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1788139853;
	bh=DnLEnchd2VaOyhF8/tkpJeYRmI7T17gPbSEznKwQNno=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=Fz8OycsB4/fNcaiiZ4bTyAG4hrAPtn+vbUWvESl6NOgK1jglH3g/eywC+pEi9SNsd
	 T4Q0FOybtJ8MVFkquDXecGbBulsf9LjkSVqWDyhO5yvRWBV4fAAjGaEWDvVrZ1kTLb
	 JFiWvSzXTOVJEMm8WyO6ZFBDLIb5Wl9i/naoy/22VV1brqQjOC3ZZXTSNzMQcyxIJH
	 BCUQcKMSf6UoV70u7TpRzX0jKZfBxNktqj14S33ItDHZ+Vk3kSV6Vc+XZt4MIICUzQ
	 iCbSiYZIzsz8Kngv9uu30k18MjRxOvtEHj5JoDtn2MmXF6lyhh0tfgXqi29t4kIkB3
	 7VaAeqYmvH0Dw==
Date: Sun, 30 Aug 2026 18:30:51 -0700 (PDT)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, 
    Nicola Vetrini <nicola.vetrini@bugseng.com>, 
    Andrew Cooper <andrew.cooper3@citrix.com>, Julien Grall <julien@xen.org>, 
    Stefano Stabellini <sstabellini@kernel.org>, 
    Anthony PERARD <anthony.perard@vates.tech>, 
    Michal Orzel <michal.orzel@amd.com>, 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>
Subject: Re: [PATCH 09/12] Eclair: deviate BUILD_ERROR() wrt rule 2.1 and
 introduce variants
In-Reply-To: <06c5efc0-e130-417f-8333-b8eacd1c6d77@suse.com>
Message-ID: <6a118f4d-4bd0-ea3c-8322-18edfb682e58@kernel.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <06c5efc0-e130-417f-8333-b8eacd1c6d77@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-purgate-ID: tlsNG-16d1c6/1788139856-F420077B-20216E5B/0/0
X-purgate-type: clean
X-purgate-size: 2786

On Fri, 28 Aug 2026, Jan Beulich wrote:
> BUILD_ERROR() is even stronger a guard than assertions in general, and
> ASSERT_UNREACHABLE() (or BUG()) in particular. Deviate it just like those
> to allow use for marking unreachable portions of code.
> 
> In some cases code being unreachable is dependent upon configuration.
> Introduce two variants, as constructs like
> 
>     if ( IS_ENABLED(CONFIG_...) )
>         BUILD_ERROR("...");
> 
> results in the if() still being reported as unreachable. Sadly these two
> new macros introduce a new 20.12 violation each, which hence also needs
> deviating.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -19,6 +19,7 @@ Constant expressions and unreachable bra
>  
>  -doc_begin="Unreachability inside an ASSERT_UNREACHABLE() and analogous macro calls is deliberate and safe."
>  -config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"}
> +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(^BUILD_ERROR(|_IF(|_NOT))$))))"}
>  -doc_end
>  
>  -doc_begin="The asm-offset files are not linked deliberately, since they are used to generate definitions for asm modules."
> @@ -667,6 +668,7 @@ deliberate."
>  to the # or ## operators within the following macros are deliberate, to provide
>  useful diagnostic messages to the user."
>  -config=MC3A2.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"}
> +-config=MC3A2.R20.12,macros+={deliberate, "^BUILD_ERROR(|_IF(|_NOT))$"}
>  -doc_end
>  
>  -doc_begin="The helper macro GENERATE_CASE may use a macro parameter for ordinary
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -64,6 +64,21 @@
>   */
>  #define BUILD_ERROR(msg) asm ( ".error \"" msg "\"" )
>  
> +/*
> + * Like above, but conditional upon @cfg (not) being enabled.  @cfg must be
> + * suitable to pass to IS_ENABLED().
> + */
> +#define BUILD_ERROR_IF(cfg)                               \
> +    (IS_ENABLED(cfg)                                      \
> +     ? ({ BUILD_ERROR( #cfg " unexpectedly enabled"); })  \
> +     : (void)0)
> +
> +#define BUILD_ERROR_IF_NOT(cfg)                           \
> +    (!IS_ENABLED(cfg)                                     \
> +     ? ({ BUILD_ERROR( #cfg " unexpectedly disabled"); }) \
> +     : (void)0)
> +
> +
>  /* Hide a value from the optimiser. */
>  #define HIDE(x)                                 \
>      ({                                          \
> 


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 05:17:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 05:17:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403747.1637718 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0uOL-0005U1-Rj; Mon, 31 Aug 2026 05:17:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403747.1637718; Mon, 31 Aug 2026 05:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0uOL-0005Tt-OS; Mon, 31 Aug 2026 05:17:09 +0000
Received: by outflank-mailman (input) for mailman id 1403747;
 Mon, 31 Aug 2026 05:17:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1x0uOK-0005Tn-5k
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 05:17:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0uOJ-003TCC-F7
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 07:17:07 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a950e4f-e002-0a2a0a5209dd-0a2a4503adac-12
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:17:07 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a950e53-fae8-0a2a45030019-d155dd35b171-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:17:07 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-484374f54d0so507419f8f.3
 for <xen-devel@lists.xenproject.org>; Sun, 30 Aug 2026 22:17:07 -0700 (PDT)
Received: from notebook.. ([88.230.40.90]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-484322ce2a6sm14228449f8f.19.2026.08.30.22.17.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 30 Aug 2026 22:17:06 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1788153427; x=1788758227; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=ufDtI6dGBJzLaCrYz83r0Iy0PyHxGLIGdHKX89PGQi0=;
        b=o2EUgq9J/YqB779nblohXEg7ps+d8VwccvFASAdJNwnY1tVcrI9rsCe+vkmIYPXlVk
         Fio8LQ7w1jt6H3ob6gqE+YjU7iGL3yQ+ocQwDfK+8iRpghDwO54vh8CcwXXkWL6iXAKQ
         ognxvlqUTfSmvJI1wFdylDxEPTnUsLSpWgZIj1j7S8swLcVC/xUxrVthWDfp6uIz8WP0
         y5j3/pV/FKXKx94i8D6+33tlObrkjBa58YCVDMZM4IgzPW/3aqR9UBqYqdZNY3zvC799
         3UKqISsWj9bggYstKt8cOiKZxtXqsAZ7W3L+YoGyiYwSbLd1djhJaJyXImjd7ImQH7yO
         MFBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788153427; x=1788758227;
        h=content-transfer-encoding:mime-version: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=ufDtI6dGBJzLaCrYz83r0Iy0PyHxGLIGdHKX89PGQi0=;
        b=PgVbZv0HtqWAwzTRfCh22ml4T5Jzt2Wx3bDKBQb34GYDJDtF6/Lf+ulZA0rRmH5zgJ
         SnA85SpAIwCNCOZz5l8uFlzDv03yUOR5ZWRkeJOrFBh4Y4arqysJFLfTSW8dnP2rj0iB
         Ee5jMZn4I5/CIm5d0mHXqofMcR88wgRIqn6CJSn6q9Bz6uIrgJ89nldLVrUhzG1rsm4W
         9khQPFnO29f1Cj7dhRWDxh+gBRq4G5ykF2MIXv1LpXaqsnxq+lM+MF/lN2GSqYMLQlse
         BeIgqcmbQyBDqOIZc3tsGNlI8eHUfaeWpBDaJCmREnzJxF2+pnAHQrKpMioeR5beCmwT
         xDag==
X-Gm-Message-State: AFuF++no89nVtEQB+IhV1NZzpZUiCkpS5tKt7q/C31QRMWE73+oAS4l5
	mwpv3Dma0B8HVcGA0vBX70SlcOZOsdGv1umVAi/m5oDxYKw49eKaQDyejsKEzw==
X-Gm-Gg: AYBFou0gCP7q9nlbE9aFYnOvI3W8RqoVcVYMGTJBVx52Qsrptt/xqDAaOwuoA0s7sde
	vQJI+/hemVf/OxyAXH0tJ4BqWEE6MheDxwFovx5y4y49+UUhnAntib8piwWD9Q2lwFmmlGeNWc5
	tqnRABA8K3GTN/9hHBJ+NdN314QJWjZJPsh7r+s/wf4/TCgnp8GhnIuOMeir9bBEbAWysPzrniL
	OzdvBWyYyVZRi3TecqG0QRraeaEfBOXV5hX/nd1Z6j1I6/Q9+EP9qH5zGHwHjBlbXmVlxXA/I50
	SLerPB5+Y91UHrPE8P/BPWyxe+ThGAifKwpdOnmzXo1BE4Ybg0PECRrQxekbuNIfVHAzZ2u8tKi
	SUmomyJgVZ/Wuzvot3AnImSPY6H239hZS3uu+QqmdPxupMmJuwfOPUrn4AooNHqqwN8i79iIQHn
	7k9OmZkdfecydcNM4RJmveW9rNYuYcFvRXQs6LvtXi1A34lKMdDrD/sjFGyj16qeiIsh62eg==
X-Received: by 2002:a05:6000:4a17:b0:484:3200:b7a1 with SMTP id ffacd0b85a97d-4843efdcc6bmr657400f8f.13.1788153426692;
        Sun, 30 Aug 2026 22:17:06 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v3 0/2] xen/sched: fix crashes when vcpu creation fails
Date: Mon, 31 Aug 2026 08:16:35 +0300
Message-Id: <20260831051637.5029-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-33051d/1788153427-768FA4E9-B7E0CEA7/0/0
X-purgate-type: clean
X-purgate-size: 538

Furkan Caliskan (2):
  xen/common: add vcpus_create() and keep max_vcpus in sync
  xen/sched: core: kill unarmed timers on sched_init_vcpu() failure

 xen/arch/arm/domain_build.c   | 15 +++++++--------
 xen/arch/x86/mm/mem_sharing.c | 11 ++---------
 xen/common/domain.c           | 24 ++++++++++++++++++++++++
 xen/common/domctl.c           | 19 ++++---------------
 xen/common/sched/core.c       | 16 +++++++++-------
 xen/include/xen/domain.h      |  1 +
 6 files changed, 47 insertions(+), 39 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 05:17:23 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 05:17:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403748.1637727 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0uOV-0005hr-20; Mon, 31 Aug 2026 05:17:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403748.1637727; Mon, 31 Aug 2026 05:17:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0uOU-0005hk-V5; Mon, 31 Aug 2026 05:17:18 +0000
Received: by outflank-mailman (input) for mailman id 1403748;
 Mon, 31 Aug 2026 05:17:18 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1x0uOU-0005hD-6T
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 05:17:18 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0uOT-008Rw3-JZ
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 07:17:17 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a950e47-2eae-0a2a0a5409dd-0a2a4502d648-18
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:17:17 +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 <frn1furkan10@gmail.com>)
 id 6a950e5c-6ca4-0a2a45020019-d1558029f075-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:17:17 +0200
Received: by mail-wm1-f41.google.com with SMTP id
 5b1f17b1804b1-4953e04ef16so29839285e9.2
 for <xen-devel@lists.xenproject.org>; Sun, 30 Aug 2026 22:17:17 -0700 (PDT)
Received: from notebook.. ([88.230.40.90]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-484322ce2a6sm14228449f8f.19.2026.08.30.22.17.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 30 Aug 2026 22:17:15 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1788153436; x=1788758236; 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=Dq3cmO5PPtgnp19HJEhOTKdP7pA/ai2rBau78tRnt3E=;
        b=Qtq6nrH3mWa8+mqXC5yaLidJ1KcQthNpFy19yjufBxXwRABflYpUe/onOgFIRxE6bV
         gC15V6GunYsCuGhdfIFcCwfkqm+hUl2lzCoxzeIJXHdBVQ0DRyAGRAsIUlZjtZAe71Ny
         WTBXXEf+z4U76tsAMmVCJVy4LPLVpQDvecL2yk01xukAPc+tfHCtHPqgv6v4C146JJ4L
         rWHll3hyUMqfheH6m4RakFbndDzNtsr5Wjp3ojGreEdow44om1zKkPYn8po8ZwDU/PRL
         rcdFIMJ3tzypRC9J22MrbOxzJI72y7OQdmIJY7odF+/xwkmC0N5a5GMzXcmrWx8wELuq
         cYfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788153436; x=1788758236;
        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=Dq3cmO5PPtgnp19HJEhOTKdP7pA/ai2rBau78tRnt3E=;
        b=B1r3BtiTdJejRV7uiPDuY8sfrn9uR/mH0Rj3gSCXfPEv5kRLIZQPhxIHKp8tSZz0qT
         fuJMjthZ72NzF+pUWyHursjIqI8883bfnK7B3rJFkOEkE4oM/utTyG9cf6hlULGKpFk3
         d0HTOjCLVVpwDcaEGvQ4FMO/vyRfQMzFd/p+f/liEfg5RnMnwIHCwQ4OCWW1PMCOhgsc
         y9aKlGrFymqEwS0W7vYnvKw8NJcJA8ukKE5MVvB2wvHDbajd6RSRnrdGlZLi+krX3aiN
         TbvdTTfhjL58HNP/Cvs6nRDX4UQm6RGSpWH9cNvxKRAGm5voiPUMe4m1NI5TbYkcWSeB
         i47w==
X-Gm-Message-State: AFuF++mk9leksHeWaNIVdOe2KiI6TvrsjDUPHilX2P9MB54mDYB5kOY/
	91ExMd17KA+jS3m7uI6+PxPyk6RU9zRK6bGQ6GXR5UPPWE5eNERC7Uw2ntp2WQ==
X-Gm-Gg: AR+sD13Og291u3WZet0nS131aqwOIZP0T50hYwctSwDvn/3f0evmevM18jeAR2nPAkI
	dBoU6N2X2/lXWFvBBWcp5dn2OfFzvtU0nWpC6Rx2DLWnButlsEUQBfVTxcZxSLPw6/gSb+ObxSg
	V3BxjPwgMi40NN/OeOWhOTelbsW3TnDLMHFCGwYbuez0obN7/ymoO3GxzB+7m5DNe44e7O5Fjz4
	pRXq6DHJ9wY4URlIcnfSJ+aWJ6SaOQBSWi7lwt2ozKjaVoo8miT4O5lCJdWhepHI1nsNyPC2WZT
	a5gaQp6k25xyY4c+8wg4CgdEtPObT9IAQ6kTCk0MIJobajSIzOP0LtXVe7Ed2sWzxM+3grP+zvh
	DXTf1+fKv7PjMd0giz02jJaDafF186FjmU431njPFrOiM5EtrRuRB8CjJhPjCCJWdKYpjj6uo1m
	Bn9yrM81QZ+P5fc9nWp3UE90dFC6e3132QjKpVbM4df0wI/ihQPb1Iznv0FzVt
X-Received: by 2002:a05:600c:3546:b0:499:dbc0:370d with SMTP id 5b1f17b1804b1-49b91c1dad9mr343878835e9.2.1788153436475;
        Sun, 30 Aug 2026 22:17:16 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync
Date: Mon, 31 Aug 2026 08:16:36 +0300
Message-Id: <20260831051637.5029-2-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260831051637.5029-1-frn1furkan10@gmail.com>
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1788153437-317CA2AC-46E00338/0/0
X-purgate-type: clean
X-purgate-size: 7015

Every vcpu_create() call site that builds more than one vcpu loops
over ids up to d->max_vcpus and stops on the first failure, but none
of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL
for ids below max_vcpus, which anything walking d->vcpu[] can then
dereference. This is what caused the crash: sched_move_domain()
walks every vcpu slot up to max_vcpus without checking for empty
ones, so when a domain built in a non-default cpupool had vcpu
creation fail partway through, domain_kill() later moving it back
to the default cpupool handed one of its empty slots straight to
the new cpupool's scheduler, causing a NULL-pointer dereference
inside sched_alloc_udata().

Add vcpus_create(d): creates every vcpu of d up to max_vcpus and
rolls max_vcpus back to the failed id on error. This keeps
d->vcpu[i] is non-NULL for all i < d->max_vcpus, instead of guarding
every reader of d->vcpu[] agains holes individually.

Convert every site that builds vcpus in a loop to call this function
instead.

Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()")
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
v3:
 - Reworked per Juergen's suggestion: instead of guarding
   sched_move_domain() against a missing vcpu slot, keep d->max_vcpus
   in sync with the vcpus actually created. Added vcpus_create() and
   converted every vcpu_create() loop to use it.
 - Reverted the sched_move_domain() check from v2, now unneeded.
---
 xen/arch/arm/domain_build.c   | 15 +++++++--------
 xen/arch/x86/mm/mem_sharing.c | 11 ++---------
 xen/common/domain.c           | 24 ++++++++++++++++++++++++
 xen/common/domctl.c           | 19 ++++---------------
 xen/common/sched/core.c       |  7 +++----
 xen/include/xen/domain.h      |  1 +
 6 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72d5316180..e08ee21ee5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1774,6 +1774,7 @@ static void __init find_gnttab_region(struct domain *d,
 int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 {
     unsigned int i;
+    int rc;
     struct vcpu *v = d->vcpu[0];
     struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
@@ -1842,17 +1843,15 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
     }
 #endif
 
-    for ( i = 1; i < d->max_vcpus; i++ )
+    if ( (rc = vcpus_create(d)) )
     {
-        if ( vcpu_create(d, i) == NULL )
-        {
-            printk("Failed to allocate d%dv%d\n", d->domain_id, i);
-            return -ENOMEM;
-        }
+        printk("Failed to allocate d%dv%d\n", d->domain_id, d->max_vcpus);
+        return rc;
+    }
 
-        if ( is_64bit_domain(d) )
+    if ( is_64bit_domain(d) )
+        for ( i = 1; i < d->max_vcpus; i++ )
             vcpu_switch_to_aarch64_mode(d->vcpu[i]);
-    }
 
     domain_update_node_affinity(d);
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5c7a0ff30e..cd7f747c80 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1612,21 +1612,14 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
 
 static int bring_up_vcpus(struct domain *cd, struct domain *d)
 {
-    unsigned int i;
     int ret = -EINVAL;
 
     if ( d->max_vcpus != cd->max_vcpus ||
         (ret = cpupool_move_domain(cd, d->cpupool)) )
         return ret;
 
-    for ( i = 0; i < cd->max_vcpus; i++ )
-    {
-        if ( !d->vcpu[i] || cd->vcpu[i] )
-            continue;
-
-        if ( !vcpu_create(cd, i) )
-            return -EINVAL;
-    }
+    if ( (ret = vcpus_create(cd)) )
+        return ret;
 
     domain_update_node_affinity(cd);
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e16f1ac383..a0a3e51b15 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -539,6 +539,30 @@ struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id)
     return NULL;
 }
 
+/*
+ * Create every not yet existing vcpu of d, up to d->max_vcpus. On failure,
+ * d->max_vcpus is rolled back to the id that failed, keeping d->vcpu[i]
+ * non-NULL for all i < d->max_vcpus.
+ */
+int vcpus_create(struct domain *d)
+{
+    unsigned int i;
+
+    for ( i = 0; i < d->max_vcpus; i++ )
+    {
+        if ( d->vcpu[i] )
+            continue;
+
+        if ( vcpu_create(d, i) == NULL )
+        {
+            d->max_vcpus = i;
+            return -EINVAL;
+        }
+    }
+
+    return 0;
+}
+
 static int late_hwdom_init(struct domain *d)
 {
 #ifdef CONFIG_LATE_HWDOM
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a6210db4fb..39f3f219ca 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -698,7 +698,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 
     case XEN_DOMCTL_max_vcpus:
     {
-        unsigned int i, max = op->u.max_vcpus.max;
+        unsigned int max = op->u.max_vcpus.max;
 
         ret = -EINVAL;
         if ( (d == current->domain) || /* no domain_pause() */
@@ -708,21 +708,10 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
-        ret = -ENOMEM;
-
-        for ( i = 0; i < max; i++ )
-        {
-            if ( d->vcpu[i] != NULL )
-                continue;
-
-            if ( vcpu_create(d, i) == NULL )
-                goto maxvcpu_out;
-        }
-
-        domain_update_node_affinity(d);
-        ret = 0;
+        ret = vcpus_create(d);
+        if ( !ret )
+            domain_update_node_affinity(d);
 
-    maxvcpu_out:
         domain_unpause(d);
         break;
     }
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d3a0a97e1d..14069eed03 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3497,10 +3497,9 @@ void wait(void)
 #ifdef CONFIG_X86
 void __init sched_setup_dom0_vcpus(struct domain *d)
 {
-    unsigned int i;
-
-    for ( i = 1; i < d->max_vcpus; i++ )
-        vcpu_create(d, i);
+    if ( vcpus_create(d) )
+        printk("Failed to create all vcpus of dom0 (max_vcpus now %u)\n",
+               d->max_vcpus);
 
     domain_update_node_affinity(d);
 }
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index aeb8b36ad1..eaf406a814 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -34,6 +34,7 @@ typedef union {
 } vcpu_guest_context_u __attribute__((__transparent_union__));
 
 struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id);
+int vcpus_create(struct domain *d);
 
 unsigned int dom0_max_vcpus(void);
 int parse_arch_dom0_param(const char *s, const char *e);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 05:17:24 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 05:17:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403749.1637735 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0uOa-0005xr-Ab; Mon, 31 Aug 2026 05:17:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403749.1637735; Mon, 31 Aug 2026 05:17:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0uOa-0005xk-7l; Mon, 31 Aug 2026 05:17:24 +0000
Received: by outflank-mailman (input) for mailman id 1403749;
 Mon, 31 Aug 2026 05:17:22 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1x0uOY-0005wK-P5
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 05:17:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0uOY-008Rzn-62
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 07:17:22 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a950e2c-2eae-0a2a0a5409dd-0a2a45018648-46
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:17:22 +0200
Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a950e61-5984-0a2a45010019-d155dd33c118-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:17:22 +0200
Received: by mail-wr1-f51.google.com with SMTP id
 ffacd0b85a97d-47fe89fb333so1704339f8f.3
 for <xen-devel@lists.xenproject.org>; Sun, 30 Aug 2026 22:17:22 -0700 (PDT)
Received: from notebook.. ([88.230.40.90]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-484322ce2a6sm14228449f8f.19.2026.08.30.22.17.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 30 Aug 2026 22:17:21 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1788153441; x=1788758241; 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=RF/yfWgOJ/13R8udz3oVi9BzjnDTji2oCBYfoMLlR+k=;
        b=fx7/rgYC+OUiXWPO75j5SeZvTAEobcN8OBrq94xjVAptUgETWSjSBldufgVmc+OXK6
         8/f6npE2ZtITnBSY2SvN/A0dlffoLqMM36u6dLYJkIzs8A+hoOXgNc4VdwBuMoif4HW0
         bYrm0hzz1nOjUcvjH1AjWmU5Uer+81XHaUldQx0v2hlc+ieIlswca1h/mjj7wbPRMh8x
         /bIB2AHlHsyOgR7LmbX+oOMkSnJl7oMfuF9frmBGJ01cpXc1pMSDoKvbmQ+mWErS+0nL
         wwXtRQHtniVSwilOZyNuQDxl1XeyS06vjB5rqgmZd9shmWoDHolGtlHZpE0i/nHq5pf8
         WMAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788153441; x=1788758241;
        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=RF/yfWgOJ/13R8udz3oVi9BzjnDTji2oCBYfoMLlR+k=;
        b=h/9SIOjFhZHOlxLGh9UUI3E341gmMHZ8vY9EAIbDt8Iz+KP4jcFYHIfT+myAfB8xOD
         rhZvTQXcJDi3n2GujRdG2lslHlDZbLXJ2SXbyEmE0m+AXo7fZTWzs0x5mkZJlVbzfnOX
         GZNSse4A0+y5KPgYpWJPbPtrpidttrLa51tOTRquVpun/fd6b/Pfqk87wpBHAMCStzm/
         qcYWGflcOTEoMwHF244w7zP2iwBwEtUXmo+6bj9khYfomsWfFICNlHtu2MUe5pMg+Onk
         7D+9nWJ8gVoxWpxQ6vL/MAl2BeG3Z4TCE/fsBIbEJ8M1yozs8SWgvDEXKl2VHoQNDchf
         vClg==
X-Gm-Message-State: AFuF++kAnJEjZzHlf3BNHwoAqx3T42luqkYtnj7838T7OpjP8SU3GSdp
	1n8Uh86BpiOaCLZvTrt5jn+CVPtk8plXcmejPkqooz1XkLNyGLeG3pL0vNod5g==
X-Gm-Gg: AYBFou0/PkaI5T6j15IGpdPX9p5jbiCodq8iUqLYRbaQkY0LRo8VLOBYk/hgNMRcPzF
	I6hLJ1PAVkiFy3J6ezca3p0n6L0pdrS5+xGvvcCwlUrbam/wE7F/2OuRPHoMu5Nujvm1ICEbVOt
	jlGE4nB4ymsnxSl8wJd0QXRXLbevstGCoVG3zXbL7K6Vylc4qnfJiDsAlmw79N9+S535gCOOCfG
	xn+D89JGZGN/x29kYzcAdrnw6oCKDJzH0PJAOWUA96sGpKGSGDkWsy6txpcRTa5+Nbm9rnmbryo
	ZXId9QUtyB3qHD6Bi+0Y1CsVk5MZVZBtn5L8zFf5nRtzd58P/LbdMEw+tllkVzB0Iv2p3TnTjaD
	RAqzuKM7B2Gup6DeEPpt2JWgKlhWgJd+7wQMlHl2NBMa8M8JvuXwc8MfgO2GJOEZEYasB+6K3fD
	VOmJU57VyjPNHJDwWPieLEmvdempnRAVf7eP0udzKFl6E/7UFvlGATseTV/rI=
X-Received: by 2002:a5d:5f03:0:b0:484:3cbf:f254 with SMTP id ffacd0b85a97d-4843cbff31cmr4195953f8f.21.1788153441502;
        Sun, 30 Aug 2026 22:17:21 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	dfaggioli@suse.com,
	gwd@xenproject.org,
	roger@xenproject.org,
	anthony.perard@vates.tech,
	julien@xen.org,
	bertrand.marquis@arm.com,
	michal.orzel@amd.com,
	Volodymyr_Babchuk@epam.com,
	teddy.astie@vates.tech,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v3 2/2] xen/sched: core: kill unarmed timers on sched_init_vcpu() failure
Date: Mon, 31 Aug 2026 08:16:37 +0300
Message-Id: <20260831051637.5029-3-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260831051637.5029-1-frn1furkan10@gmail.com>
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-d62444/1788153442-1F66C757-2DF32A77/0/0
X-purgate-type: clean
X-purgate-size: 2696

sched_init_vcpu() calls init_timer() for a vcpu's periodic_timer,
singleshot_timer and poll_timer before it can fail -- these
become live, linked into their target pCPU's per-cpu timer list
regardless of what happens next. If the sched_alloc_udata() call
further down then fails, the function frees the sched_unit via
sched_free_unit() and returns 1, but never unlinks these three
timers.

The caller, vcpu_create(), makes this worse: on sched_init_vcpu()
returning nonzero it jumps to fail_wq, skipping fail_sched and
thus sched_destroy_vcpu() -- the only function on this path that
calls kill_timer() on them. vcpu_destroy() then frees the vcpu,
and the three timers embedded in it, while they are still linked
into that shared list.

This silently corrupts that list. It only shows up later, when
something else touches a neighboring timer: sched_move_domain()
crashed with "Assertion 'entry->prev->next == entry' failed" on a
completely unrelated, valid vcpu's timer.

Call sched_destroy_vcpu() in sched_init_vcpu()'s own failure
branch instead of sched_free_unit(), so it doesn't depend
on the caller reaching sched_destroy_vcpu() to undo what it set
up itself. sched_destroy_vcpu() assumes unit->priv is set, which
is not the case here, so make it only free the udata and remove
the unit if unit->priv in non-NULL.

Fixes: d884b1077817 ("Domain creation/destruction cleanups.")
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
v3:
 - Call sched_destroy_vcpu() from sched_init_vcpu()'s failure
   branch.
 - Made sched_destroy_vcpu() tolerate unit->priv == NULL.
---
 xen/common/sched/core.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 14069eed03..b65f728e77 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -589,7 +589,7 @@ int sched_init_vcpu(struct vcpu *v)
     unit->priv = sched_alloc_udata(dom_scheduler(d), unit, d->sched_priv);
     if ( unit->priv == NULL )
     {
-        sched_free_unit(unit, v);
+        sched_destroy_vcpu(v);
         rcu_read_unlock(&sched_res_rculock);
         return 1;
     }
@@ -869,8 +869,11 @@ void sched_destroy_vcpu(struct vcpu *v)
     {
         rcu_read_lock(&sched_res_rculock);
 
-        sched_remove_unit(vcpu_scheduler(v), unit);
-        sched_free_udata(vcpu_scheduler(v), unit->priv);
+        if ( unit->priv )
+        {
+            sched_remove_unit(vcpu_scheduler(v), unit);
+            sched_free_udata(vcpu_scheduler(v), unit->priv);
+        }
         sched_free_unit(unit, v);
 
         rcu_read_unlock(&sched_res_rculock);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 06:00:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 06:00:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403773.1637746 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0v3o-00044v-CJ; Mon, 31 Aug 2026 06:00:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403773.1637746; Mon, 31 Aug 2026 06:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0v3o-00044o-7i; Mon, 31 Aug 2026 06:00:00 +0000
Received: by outflank-mailman (input) for mailman id 1403773;
 Mon, 31 Aug 2026 05:59:58 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1x0v3m-00044h-Kz
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 05:59:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0v3l-003Yxj-Fs
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 07:59:57 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a95185c-8faa-0a2a0a5109dd-0a2a4506ad90-4
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:59:57 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a95185d-195a-0a2a45060019-d155dd32e4ce-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 07:59:57 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-482ea739de2so1787438f8f.0
 for <xen-devel@lists.xenproject.org>; Sun, 30 Aug 2026 22:59:57 -0700 (PDT)
Received: from [192.168.1.109] ([88.230.40.90])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-4843ce8b015sm3251163f8f.13.2026.08.30.22.59.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 30 Aug 2026 22:59:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1788155997; x=1788760797; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=XfxbA2i+f23qwNxWpVJUWwp2eUr44EFO/Ti3rWFq6J8=;
        b=ezDiRyhvnAhZud/zdIIopqZQ84yfCHXkwnaQLzTmFHLK4HdllAp2NzSu+NqNqQEwzl
         zrrgmkGVSAYZiI2yE/fLgMZKq4ZeBvAk8/zY7qhaGdu2DZyJDJu6wQeeWxTFKSg1VsIM
         LfWAiQAfoykDroul6TPyhk+ORs1MM/BfdMBUGdb1igXb8MAcV9h+3m3QJeLzlj2BGbIy
         dF8UPoaR0XFFOH4kaJLJrPHv91hE7gRysnKxA3I95ZMIHckbJ9/+IhtM2mlDrBEXRiT0
         pdySVivvCjOk/aIUB0zXTE34OXw2jh9V3+DeTf4oyEmJ/BlBcaY1MtKX4Ox3xlcuM/Z0
         saGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788155997; x=1788760797;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=XfxbA2i+f23qwNxWpVJUWwp2eUr44EFO/Ti3rWFq6J8=;
        b=QNa3//V2gjx+XMhh1AUhkS4PLp0ucZeomSTNSa18Xc7U1jaj9JmUosu6/QtbB/ZUJq
         3CNvv6hVNppaWkS3sPFrFf7N4qNphNh2uSQbWU81cP1pMdICueHIGSbczMow2ew27Q/T
         57+3sEUCUlzZAz0SESRd+DOtmHlmXEx5/+qbNwQuHdDGtqHb42QwCwSVMTfU9iG2UHmt
         WCyQIM0+rcOHSX26Jkbg6tpqMrBDl8DtXXo7hRmFKf3+SIVRBx2XeBfX7C6I4AqHsMe1
         ysg+Jor4Fn134qphFAD/cvQbCrOmmewN+tNl19t09B9WXk70vGHcrlTSjDZbVygWl68w
         2OLg==
X-Forwarded-Encrypted: i=1; AKwUvBwNwfWVoawrApNA2QdSBXRgvL9mPy12jsky1uhyDobBIxZaJk10x8JlsYtTAUwjRosGOskX2w9zF0c=@lists.xenproject.org
X-Gm-Message-State: AFuF++lGQFiNIVZ8swPWUlROkJYHVt57/8T8N+V5DKrgHeltgCNi04eI
	rgSoA6245WDv5m7pXjQgEDxISZq+dQ8rJ6DTEn+Gf79f7HhdY84Hx/Dt
X-Gm-Gg: AYBFou3rgYtyq3ezKYropbN7/4wUE9c4WAylfkprI+HlHPc16wUHIjf7wRQJcH623uq
	jegUwhUMq4uT/NgwTWnopg3b/OTlWBGgnVx5na9ZtkBzWMVOTli+Mld4AjgCIfN1KpeAMgpv2xQ
	Xm+9la/3MAC/1AtOIVUmA69xbhI3hVZXLrT4RE2jHjpCcWLcf//FwByivtgvJ4vrDA8B/Fpk+Nv
	3HjUjyC9R40XlSB/+lfZCwCmD5yy+B2qXJ6DO8tiAbhUNzNo4ExX1DWMo8+wTF4u9Zu4cEieF8E
	1nJvsUyfmXoIvu3M4QY55XnWKrjmwUYCR+ehgeKgGyEnSN5UwL23x8num8JxVyM1/lepFE21BNa
	u74srD02/YiY64kDfxxgxBYBFApKIh6izmFcxhMRiPfCqdXHNa4Yv0FVwhV7iVm4NPx8ZPezONi
	fTHzfE8BuvQ3XMgdYj4fSc4O8yLymiFvUgnW8nxDO0K1SAZSms0TYRluXiG7Cc4DgExw==
X-Received: by 2002:a5d:5f8d:0:b0:482:ee81:f0ca with SMTP id ffacd0b85a97d-482f79c94eemr36614562f8f.12.1788155996487;
        Sun, 30 Aug 2026 22:59:56 -0700 (PDT)
Message-ID: <85c66385-7a28-4779-96d4-6b34f53b5994@gmail.com>
Date: Mon, 31 Aug 2026 08:59:50 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] KVM: x86/xen: Convert evtchn_ports from IDR to XArray
To: David Woodhouse <dwmw2@infradead.org>, linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org, x86@kernel.org, seanjc@google.com,
 pbonzini@redhat.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
 dave.hansen@linux.intel.com, hpa@zytor.com, paul@xen.org,
 xen-devel@lists.xenproject.org
References: <20260706081311.13633-1-frn1furkan10@gmail.com>
 <efe39d24a2621ce23f9d53471b3b587feaaa8526.camel@infradead.org>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <efe39d24a2621ce23f9d53471b3b587feaaa8526.camel@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-purgate-ID: tlsNG-16d1c6/1788155997-1FECC77B-B6CDEC05/0/0
X-purgate-type: clean
X-purgate-size: 837



On 7/7/26 12:16, David Woodhouse wrote:
> On Mon, 2026-07-06 at 11:13 +0300, Furkan Caliskan wrote:
>> IDR is deprecated in favor of XArray: see
>> Documentation/core-api/idr.rst. Convert evtchn_ports accordingly.
>>
>> kvm_xen_eventfd_assign()'s single-slot idr_alloc() becomes
>> xa_insert(), since it was really an insert-at-index, not an
>> allocation: -EBUSY replaces -ENOSPC, still mapped to -EEXIST.
>>
>> kvm_xen_hcall_evtchn_send() drops its explicit rcu_read_lock(),
>> since xa_load() takes its own RCU read-side section internally.
>> evtchnfd's lifetime is still guaranteed by kvm->srcu.
>>
>> xen_lock is left in place: it protects state beyond the map itself.
>>
>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
> 
> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> 
> Thanks.

Ping?


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 08:13:44 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 08:13:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403802.1637761 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0x8z-0006tS-UQ; Mon, 31 Aug 2026 08:13:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403802.1637761; Mon, 31 Aug 2026 08:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0x8z-0006tL-Rh; Mon, 31 Aug 2026 08:13:29 +0000
Received: by outflank-mailman (input) for mailman id 1403802;
 Mon, 31 Aug 2026 08:13:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1x0x8y-0006tF-Oc
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 08:13:28 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0x8w-008zmE-T8
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 10:13:26 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a953780-e002-0a2a0a5209dd-0a2a450cd370-46
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:13:26 +0200
Received: from [209.85.218.49] (helo=mail-ej1-f49.google.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a9537a1-f479-0a2a450c0019-d155da31c9a4-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:13:21 +0200
Received: by mail-ej1-f49.google.com with SMTP id
 a640c23a62f3a-c2020421077so473355766b.3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 01:13:21 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-c255f1b2917sm393150766b.30.2026.08.31.01.13.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2026 01:13:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1788164001; x=1788768801; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=0+SeBKhG3TJqxssUaee07ETrfab+C+rs+vTSL4kGhq4=;
        b=OhEpaFzEFsxSY2DeHzYAUmTgALb+kqFg40EHGWM9A9rlpEGHMK0sAuP7PM6IEsGH/F
         HnxtkhSOQcZYMvsluLoGWm8D25vBVYMsPa1UhnL7i+VjJ7sx7NoFuDGJFq1yklWhSAJV
         tyyKco3BHPWBUJ7U/MWdTZUCeubsu3ylXyUNdaBZm0Y9fsOJ99oyNwXJZ6Lbr1LCsGGj
         m9n/b8N/GV1rKeHrVMhJA+rTTUJhWKiQTKXyiFEDwo0dmxM+qM9eWcEunFkDempncvRK
         e2Jk7kwOwPwMn6PoVEbj2jVI1JluolUlsSojvAVmZu+DQqCgUKuROOFmtit7lrpMGoaY
         dwbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788164001; x=1788768801;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=0+SeBKhG3TJqxssUaee07ETrfab+C+rs+vTSL4kGhq4=;
        b=bNs+QTADtZjJv7gfzSzMLHgfSd82wkCM5b3BELxgZZa3CQIKQcRA0FourjgOcNAPII
         WkW+LL7OpFb7z4w/2mqKPsKBtfSK2O9zTjbOTSHHcNIBUkOCTH0dCPjptq9Zp8oVNCR+
         K3FSGi+uskGXMO5WR1hGSr1n528asZUfHEwfEzob+FNCn1RWIKmi8vbCops+fNK7u9B8
         Th+setUowBN5h16KfgoVgmSZyb50nFBHvDSALYuEHBk3AawAykBuTor3v26ClEi9PvWs
         Lxu12hDQdpi1ETI5Ljn3df+EpTVzuMqg3tnscX0JZk7rWp827mEbvLmWaR6vrUknjcLQ
         oJ3g==
X-Forwarded-Encrypted: i=1; AHgh+RqZtoQIEFp4ctRVviHnRL7xffVGT7OqMMACTl/vJgdpDNaFKXXuaRr8NyxlOJ7RFbLXQmirgAjybB8=@lists.xenproject.org
X-Gm-Message-State: AFuF++kFU/BlRvBhQB3mceC6wwCkFoynrNotYxko548CCCBLTst6un8F
	QI19UGMMSAoC8ByFwnsKL22jhTQ0Q/8f6Mj8lrnkgIyBHFC3J9Yg9xskIa0V+0SNrKk=
X-Gm-Gg: AR+sD13vuwvjQ8MpXpaFqR3v4A8yVgNT0CR1bNCILJJxxUjwlwocoeNKesnsN3M1SmF
	eehncPC72JZw5NsK9DSnx/NtRHew6MOpckM4EuDgOkUfRexQ2h8NF+odrRSxilYYnfNvNyjuVwr
	Tnd0jzeIDBoEWBP2r9XlkHuA6NaqQ6izlsZkv0sy9rySUjBH7YQKM7eFM1yn2pEOjbwcChDFRmk
	TxCulc4XgUMXd8kICTdlqLKz7yb0tSdK/ho2B8gOyhzUF5KhaPUB/V41JemzI4V/9F6qyGJP0is
	HtD8OYGvYTZcwoSHLupAWR8zdFpIfA4Fu3ss5HxWlpmnItp7XaZ/WvgYWjSHZnBoPSRHjTiTYK2
	bhL2FZCKeWnSmzQLWrG3xct1k5sF2m88lq2Bo4RMwkRZVD5roCSgRML83+DVO64qjyBA4XudOPX
	5xw5Fvi18NC2OLtsuFmtOve5F6qNatd/yE+FSW0gjrH+l22t/SXbe+xFshOy2aPM2V8O7zCufcW
	bdnFAXlnobLs1De06tmamyVtJwx12SGlMlXqaHHGx44GeF9vOpwsMDYcLc1KuVJ8Gat6URgUsbA
	VUlTxouCFYY2rQ==
X-Received: by 2002:a17:907:c48c:b0:c24:4128:c19f with SMTP id a640c23a62f3a-c2557165b0emr1455118566b.11.1788164001071;
        Mon, 31 Aug 2026 01:13:21 -0700 (PDT)
Message-ID: <33c1d613-054e-4940-a14d-9e47e673286b@suse.com>
Date: Mon, 31 Aug 2026 10:13:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus
 in sync
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech,
 julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-2-frn1furkan10@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260831051637.5029-2-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------uaE5xMQWO0Hf6fnqZ8tv8RRJ"
X-purgate-ID: tlsNG-d25034/1788164006-51B35A5B-84BF1DAC/0/0
X-purgate-type: clean
X-purgate-size: 14733

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------uaE5xMQWO0Hf6fnqZ8tv8RRJ
Content-Type: multipart/mixed; boundary="------------Cb3stSVCUVxYNMwVt50x0yGh";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech,
 julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech
Message-ID: <33c1d613-054e-4940-a14d-9e47e673286b@suse.com>
Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus
 in sync
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-2-frn1furkan10@gmail.com>
In-Reply-To: <20260831051637.5029-2-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------Cb3stSVCUVxYNMwVt50x0yGh
Content-Type: multipart/mixed; boundary="------------NIXbEHS5jN10LtGkWyyMVSCu"

--------------NIXbEHS5jN10LtGkWyyMVSCu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMzEuMDguMjYgMDc6MTYsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gRXZlcnkgdmNw
dV9jcmVhdGUoKSBjYWxsIHNpdGUgdGhhdCBidWlsZHMgbW9yZSB0aGFuIG9uZSB2Y3B1IGxv
b3BzDQo+IG92ZXIgaWRzIHVwIHRvIGQtPm1heF92Y3B1cyBhbmQgc3RvcHMgb24gdGhlIGZp
cnN0IGZhaWx1cmUsIGJ1dCBub25lDQo+IG9mIHRoZW0gcm9sbCBtYXhfdmNwdXMgYmFjayB0
byBtYXRjaC4gVGhpcyBsZWF2ZXMgZC0+dmNwdVtpXSA9PSBOVUxMDQo+IGZvciBpZHMgYmVs
b3cgbWF4X3ZjcHVzLCB3aGljaCBhbnl0aGluZyB3YWxraW5nIGQtPnZjcHVbXSBjYW4gdGhl
bg0KPiBkZXJlZmVyZW5jZS4gVGhpcyBpcyB3aGF0IGNhdXNlZCB0aGUgY3Jhc2g6IHNjaGVk
X21vdmVfZG9tYWluKCkNCj4gd2Fsa3MgZXZlcnkgdmNwdSBzbG90IHVwIHRvIG1heF92Y3B1
cyB3aXRob3V0IGNoZWNraW5nIGZvciBlbXB0eQ0KPiBvbmVzLCBzbyB3aGVuIGEgZG9tYWlu
IGJ1aWx0IGluIGEgbm9uLWRlZmF1bHQgY3B1cG9vbCBoYWQgdmNwdQ0KPiBjcmVhdGlvbiBm
YWlsIHBhcnR3YXkgdGhyb3VnaCwgZG9tYWluX2tpbGwoKSBsYXRlciBtb3ZpbmcgaXQgYmFj
aw0KPiB0byB0aGUgZGVmYXVsdCBjcHVwb29sIGhhbmRlZCBvbmUgb2YgaXRzIGVtcHR5IHNs
b3RzIHN0cmFpZ2h0IHRvDQo+IHRoZSBuZXcgY3B1cG9vbCdzIHNjaGVkdWxlciwgY2F1c2lu
ZyBhIE5VTEwtcG9pbnRlciBkZXJlZmVyZW5jZQ0KPiBpbnNpZGUgc2NoZWRfYWxsb2NfdWRh
dGEoKS4NCj4gDQo+IEFkZCB2Y3B1c19jcmVhdGUoZCk6IGNyZWF0ZXMgZXZlcnkgdmNwdSBv
ZiBkIHVwIHRvIG1heF92Y3B1cyBhbmQNCj4gcm9sbHMgbWF4X3ZjcHVzIGJhY2sgdG8gdGhl
IGZhaWxlZCBpZCBvbiBlcnJvci4gVGhpcyBrZWVwcw0KPiBkLT52Y3B1W2ldIGlzIG5vbi1O
VUxMIGZvciBhbGwgaSA8IGQtPm1heF92Y3B1cywgaW5zdGVhZCBvZiBndWFyZGluZw0KPiBl
dmVyeSByZWFkZXIgb2YgZC0+dmNwdVtdIGFnYWlucyBob2xlcyBpbmRpdmlkdWFsbHkuDQo+
IA0KPiBDb252ZXJ0IGV2ZXJ5IHNpdGUgdGhhdCBidWlsZHMgdmNwdXMgaW4gYSBsb29wIHRv
IGNhbGwgdGhpcyBmdW5jdGlvbg0KPiBpbnN0ZWFkLg0KPiANCj4gRml4ZXM6IDYxNjQ5NzA5
NDIxYSAoInhlbi9kb21haW46IEFsbG9jYXRlIGQtPnZjcHVbXSBpbiBkb21haW5fY3JlYXRl
KCkiKQ0KPiBTdWdnZXN0ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4N
Cj4gU2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwu
Y29tPg0KPiAtLS0NCj4gdjM6DQo+ICAgLSBSZXdvcmtlZCBwZXIgSnVlcmdlbidzIHN1Z2dl
c3Rpb246IGluc3RlYWQgb2YgZ3VhcmRpbmcNCj4gICAgIHNjaGVkX21vdmVfZG9tYWluKCkg
YWdhaW5zdCBhIG1pc3NpbmcgdmNwdSBzbG90LCBrZWVwIGQtPm1heF92Y3B1cw0KPiAgICAg
aW4gc3luYyB3aXRoIHRoZSB2Y3B1cyBhY3R1YWxseSBjcmVhdGVkLiBBZGRlZCB2Y3B1c19j
cmVhdGUoKSBhbmQNCj4gICAgIGNvbnZlcnRlZCBldmVyeSB2Y3B1X2NyZWF0ZSgpIGxvb3Ag
dG8gdXNlIGl0Lg0KPiAgIC0gUmV2ZXJ0ZWQgdGhlIHNjaGVkX21vdmVfZG9tYWluKCkgY2hl
Y2sgZnJvbSB2Miwgbm93IHVubmVlZGVkLg0KPiAtLS0NCj4gICB4ZW4vYXJjaC9hcm0vZG9t
YWluX2J1aWxkLmMgICB8IDE1ICsrKysrKystLS0tLS0tLQ0KPiAgIHhlbi9hcmNoL3g4Ni9t
bS9tZW1fc2hhcmluZy5jIHwgMTEgKystLS0tLS0tLS0NCj4gICB4ZW4vY29tbW9uL2RvbWFp
bi5jICAgICAgICAgICB8IDI0ICsrKysrKysrKysrKysrKysrKysrKysrKw0KPiAgIHhlbi9j
b21tb24vZG9tY3RsLmMgICAgICAgICAgIHwgMTkgKysrKy0tLS0tLS0tLS0tLS0tLQ0KPiAg
IHhlbi9jb21tb24vc2NoZWQvY29yZS5jICAgICAgIHwgIDcgKysrLS0tLQ0KPiAgIHhlbi9p
bmNsdWRlL3hlbi9kb21haW4uaCAgICAgIHwgIDEgKw0KPiAgIDYgZmlsZXMgY2hhbmdlZCwg
NDEgaW5zZXJ0aW9ucygrKSwgMzYgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEv
eGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWls
ZC5jDQo+IGluZGV4IDcyZDUzMTYxODAuLmUwOGVlMjFlZTUgMTAwNjQ0DQo+IC0tLSBhL3hl
bi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPiArKysgYi94ZW4vYXJjaC9hcm0vZG9tYWlu
X2J1aWxkLmMNCj4gQEAgLTE3NzQsNiArMTc3NCw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBm
aW5kX2dudHRhYl9yZWdpb24oc3RydWN0IGRvbWFpbiAqZCwNCj4gICBpbnQgX19pbml0IGNv
bnN0cnVjdF9kb21haW4oc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGtlcm5lbF9pbmZvICpr
aW5mbykNCj4gICB7DQo+ICAgICAgIHVuc2lnbmVkIGludCBpOw0KPiArICAgIGludCByYzsN
Cj4gICAgICAgc3RydWN0IHZjcHUgKnYgPSBkLT52Y3B1WzBdOw0KPiAgICAgICBzdHJ1Y3Qg
Y3B1X3VzZXJfcmVncyAqcmVncyA9ICZ2LT5hcmNoLmNwdV9pbmZvLT5ndWVzdF9jcHVfdXNl
cl9yZWdzOw0KPiAgIA0KPiBAQCAtMTg0MiwxNyArMTg0MywxNSBAQCBpbnQgX19pbml0IGNv
bnN0cnVjdF9kb21haW4oc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGtlcm5lbF9pbmZvICpr
aW5mbykNCj4gICAgICAgfQ0KPiAgICNlbmRpZg0KPiAgIA0KPiAtICAgIGZvciAoIGkgPSAx
OyBpIDwgZC0+bWF4X3ZjcHVzOyBpKysgKQ0KPiArICAgIGlmICggKHJjID0gdmNwdXNfY3Jl
YXRlKGQpKSApDQo+ICAgICAgIHsNCj4gLSAgICAgICAgaWYgKCB2Y3B1X2NyZWF0ZShkLCBp
KSA9PSBOVUxMICkNCj4gLSAgICAgICAgew0KPiAtICAgICAgICAgICAgcHJpbnRrKCJGYWls
ZWQgdG8gYWxsb2NhdGUgZCVkdiVkXG4iLCBkLT5kb21haW5faWQsIGkpOw0KPiAtICAgICAg
ICAgICAgcmV0dXJuIC1FTk9NRU07DQo+IC0gICAgICAgIH0NCj4gKyAgICAgICAgcHJpbnRr
KCJGYWlsZWQgdG8gYWxsb2NhdGUgZCVkdiVkXG4iLCBkLT5kb21haW5faWQsIGQtPm1heF92
Y3B1cyk7DQo+ICsgICAgICAgIHJldHVybiByYzsNCj4gKyAgICB9DQo+ICAgDQo+IC0gICAg
ICAgIGlmICggaXNfNjRiaXRfZG9tYWluKGQpICkNCj4gKyAgICBpZiAoIGlzXzY0Yml0X2Rv
bWFpbihkKSApDQo+ICsgICAgICAgIGZvciAoIGkgPSAxOyBpIDwgZC0+bWF4X3ZjcHVzOyBp
KysgKQ0KPiAgICAgICAgICAgICAgIHZjcHVfc3dpdGNoX3RvX2FhcmNoNjRfbW9kZShkLT52
Y3B1W2ldKTsNCj4gLSAgICB9DQo+ICAgDQo+ICAgICAgIGRvbWFpbl91cGRhdGVfbm9kZV9h
ZmZpbml0eShkKTsNCj4gICANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9tZW1f
c2hhcmluZy5jIGIveGVuL2FyY2gveDg2L21tL21lbV9zaGFyaW5nLmMNCj4gaW5kZXggNWM3
YTBmZjMwZS4uY2Q3Zjc0N2M4MCAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L21tL21l
bV9zaGFyaW5nLmMNCj4gKysrIGIveGVuL2FyY2gveDg2L21tL21lbV9zaGFyaW5nLmMNCj4g
QEAgLTE2MTIsMjEgKzE2MTIsMTQgQEAgaW50IG1lbV9zaGFyaW5nX2ZvcmtfcGFnZShzdHJ1
Y3QgZG9tYWluICpkLCBnZm5fdCBnZm4sIGJvb2wgdW5zaGFyaW5nKQ0KPiAgIA0KPiAgIHN0
YXRpYyBpbnQgYnJpbmdfdXBfdmNwdXMoc3RydWN0IGRvbWFpbiAqY2QsIHN0cnVjdCBkb21h
aW4gKmQpDQo+ICAgew0KPiAtICAgIHVuc2lnbmVkIGludCBpOw0KPiAgICAgICBpbnQgcmV0
ID0gLUVJTlZBTDsNCj4gICANCj4gICAgICAgaWYgKCBkLT5tYXhfdmNwdXMgIT0gY2QtPm1h
eF92Y3B1cyB8fA0KPiAgICAgICAgICAgKHJldCA9IGNwdXBvb2xfbW92ZV9kb21haW4oY2Qs
IGQtPmNwdXBvb2wpKSApDQo+ICAgICAgICAgICByZXR1cm4gcmV0Ow0KPiAgIA0KPiAtICAg
IGZvciAoIGkgPSAwOyBpIDwgY2QtPm1heF92Y3B1czsgaSsrICkNCj4gLSAgICB7DQo+IC0g
ICAgICAgIGlmICggIWQtPnZjcHVbaV0gfHwgY2QtPnZjcHVbaV0gKQ0KPiAtICAgICAgICAg
ICAgY29udGludWU7DQo+IC0NCj4gLSAgICAgICAgaWYgKCAhdmNwdV9jcmVhdGUoY2QsIGkp
ICkNCj4gLSAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiAtICAgIH0NCj4gKyAgICBp
ZiAoIChyZXQgPSB2Y3B1c19jcmVhdGUoY2QpKSApDQo+ICsgICAgICAgIHJldHVybiByZXQ7
DQo+ICAgDQo+ICAgICAgIGRvbWFpbl91cGRhdGVfbm9kZV9hZmZpbml0eShjZCk7DQo+ICAg
ICAgIHJldHVybiAwOw0KPiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9kb21haW4uYyBiL3hl
bi9jb21tb24vZG9tYWluLmMNCj4gaW5kZXggZTE2ZjFhYzM4My4uYTBhM2U1MWIxNSAxMDA2
NDQNCj4gLS0tIGEveGVuL2NvbW1vbi9kb21haW4uYw0KPiArKysgYi94ZW4vY29tbW9uL2Rv
bWFpbi5jDQo+IEBAIC01MzksNiArNTM5LDMwIEBAIHN0cnVjdCB2Y3B1ICp2Y3B1X2NyZWF0
ZShzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBpbnQgdmNwdV9pZCkNCj4gICAgICAgcmV0
dXJuIE5VTEw7DQo+ICAgfQ0KPiAgIA0KPiArLyoNCj4gKyAqIENyZWF0ZSBldmVyeSBub3Qg
eWV0IGV4aXN0aW5nIHZjcHUgb2YgZCwgdXAgdG8gZC0+bWF4X3ZjcHVzLiBPbiBmYWlsdXJl
LA0KPiArICogZC0+bWF4X3ZjcHVzIGlzIHJvbGxlZCBiYWNrIHRvIHRoZSBpZCB0aGF0IGZh
aWxlZCwga2VlcGluZyBkLT52Y3B1W2ldDQo+ICsgKiBub24tTlVMTCBmb3IgYWxsIGkgPCBk
LT5tYXhfdmNwdXMuDQo+ICsgKi8NCj4gK2ludCB2Y3B1c19jcmVhdGUoc3RydWN0IGRvbWFp
biAqZCkNCj4gK3sNCj4gKyAgICB1bnNpZ25lZCBpbnQgaTsNCj4gKw0KPiArICAgIGZvciAo
IGkgPSAwOyBpIDwgZC0+bWF4X3ZjcHVzOyBpKysgKQ0KPiArICAgIHsNCj4gKyAgICAgICAg
aWYgKCBkLT52Y3B1W2ldICkNCj4gKyAgICAgICAgICAgIGNvbnRpbnVlOw0KPiArDQo+ICsg
ICAgICAgIGlmICggdmNwdV9jcmVhdGUoZCwgaSkgPT0gTlVMTCApDQo+ICsgICAgICAgIHsN
Cj4gKyAgICAgICAgICAgIGQtPm1heF92Y3B1cyA9IGk7DQo+ICsgICAgICAgICAgICByZXR1
cm4gLUVJTlZBTDsNCg0KSSB0aGluayB0aGlzIHNob3VsZCBiZSAtRU5PTUVNLg0KDQoNCkp1
ZXJnZW4NCg==
--------------NIXbEHS5jN10LtGkWyyMVSCu
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------NIXbEHS5jN10LtGkWyyMVSCu--

--------------Cb3stSVCUVxYNMwVt50x0yGh--

--------------uaE5xMQWO0Hf6fnqZ8tv8RRJ
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqVN6AFAwAAAAAACgkQsN6d1ii/Ey8X
QQgAlTH553EV8jyIlSfK2bSDz+kbZdEi1UnhF4JKCk/KS8xF04+XUmNTtbrJ7ha3iGpRTeQTsf4N
gslWUG++oWAhMBZidPzGJ4D+583s+SQebgSJP22oe3RUfNsquivOFrff9bKbSzKNY8IQtqOxJX/E
V6vSsfOA5ayd3+BPK1l911yqkWdRZWSj8Su5FRJjVGf8hIFjAsVbm0drKihz8PTZFG9qNUqWx9kF
9B32LNgKYGJI0JDPRdjomGfGGcItwvnZ3QDbMCeBV5EFqFJGnuVPYOhwCZO5g+cPikUK5IfOd/rK
Z8tTbwGHvyCeOdlJDHqROqjIwehah5DGV2zF6xVl3w==
=aWX+
-----END PGP SIGNATURE-----

--------------uaE5xMQWO0Hf6fnqZ8tv8RRJ--


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 08:15:08 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 08:15:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403809.1637772 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xAY-0007R5-CV; Mon, 31 Aug 2026 08:15:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403809.1637772; Mon, 31 Aug 2026 08:15:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xAY-0007Qy-8j; Mon, 31 Aug 2026 08:15:06 +0000
Received: by outflank-mailman (input) for mailman id 1403809;
 Mon, 31 Aug 2026 08:15:04 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1x0xAW-0007QY-JL
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 08:15:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0xAW-00E6Ut-0A
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 10:15:04 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a953801-bab6-0a2a0a5309dd-0a2a4509e86e-34
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:15:03 +0200
Received: from [209.85.208.51] (helo=mail-ed1-f51.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a953807-be1a-0a2a45090019-d155d033e0f5-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:15:03 +0200
Received: by mail-ed1-f51.google.com with SMTP id
 4fb4d7f45d1cf-6a20319d030so3977349a12.2
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 01:15:03 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a63fad67easm1362246a12.25.2026.08.31.01.15.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2026 01:15:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1788164103; x=1788768903; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=urlhzVV6xHDy3mje2cdEjOIhxoZL6GLfdgnoLSM7BH0=;
        b=gf8YhMZhLtWMqh+9ryKb5OrSwhYaQQV1v11wNyL5BhbLsQ4umJLCtph6LhocOT0ZHq
         E/6ViRB/BSaSRN4Rn14dxXi5HK1JCvbiUaJHNfyOUGwm3f1X+A/NEQ/Ihk4zZF5rZUKI
         TezAzY6aJH305eJWeH6pFcMBQy9AfNVi1FjF1MxMEPAYk0PT0fNAMgde0CaAJlnsHavJ
         uubIlEDKjscejLHdfQBLY4bqPHjgRMsk5KzeYZ1oTKcdn9tu99fINWfCauzCLy8Pddbc
         2SXLz1WvX4FCib/BBRzsFqdKLhGsQxgYWBBtiDCun4AdRsdbqP8g1AwQ0ACpAsaPI1WV
         N2zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788164103; x=1788768903;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=urlhzVV6xHDy3mje2cdEjOIhxoZL6GLfdgnoLSM7BH0=;
        b=XDpAFyHFUKYN1U6B64nQvPgrsUdGicZlr9XSa78f3sVTKhnQ7P0y7BnxE8GAwJo06O
         mVRDsZXTS+7Oc7r5vhqE1xDw+nHjbqe4xAWQVPwHiIHumDtV1gvR/gi556slsV0l3ysT
         hwClBcWTZikWDIA0ecLWknyfMDyg9LIp6Aaz+jNKB4qG7vmsM1Q/czBD9F5RAldyY+0d
         r78V2xUzlKjAWDYyhRM9pqq0YTS5s6U6YWcYxGyzdFRxXWh2rT0wzNmMQramZSHOybPW
         nqdgBQ/SO4797vhmnrPPjM7vZA4zDUQh/l73HkhgJb/cPSZwwn/W5OxxyUVsr7VotCMm
         FzmQ==
X-Forwarded-Encrypted: i=1; AKwUvBx3lQ0QAUGpsIPVuXmnQATJGsVskeBpvZE796AEwuCrYJTSyHM1O/nxPBiO4K42ZtK/jcti6XThNtw=@lists.xenproject.org
X-Gm-Message-State: AFuF++kWodrlyF+zev4yj5BR3MfuR2QmcC7H8tHvMeycHgBSJgcqgCmh
	DhsbHIZ/4wSw6hh+t47mpKBy7AXeE0s1Y+fhpYqBzTB8st9H12YypavxggyIfJESQnc=
X-Gm-Gg: AYBFou2UUigJ+eK9Ls2WagEybZg4h+vZoKdDDdkqvd/KW6tfjTl/d0wTk4N6Cw37lBN
	omkwh5rb97RM9pvat7OMH0QrRXqMcqAwzbAaT9yH4wiGYxmVKxRGIsPsSIuONvsDckqY0YNXfvf
	GjggcPqqMC/nQyWi8AIs+rLSFK7JLfbAtF0HlexVp7YTe+uRpwdiXD/hCr2qOfKyCC9HW0c0MFa
	ZLF+Mm+FoliVeW/Vj5nvI/AFVh0h3oNPnkTWc51fUCvFts8dh85/Agz5ExR69eXkiJJjdL2wYBb
	gW4hW8stu9lZP2k/+Yb12xRK/UNfHF8GboJOglTx/u9CIYLPbfrg/GmaGkO7X56VgV5+RnVE4RH
	Ub6BuJWMBb/++a7kC8PWj+Bllkm6Mek2qEf7Z/l9w1Luz/8zcF8LTqARN8fuGO6kolO4zIPjEPf
	EBXNUCv/mUx2syRo6y3QuLj6bVWgVgQcMpEKoZISM7vTNeufLK6rf8WTPe6W6Pyd6uoBeLqkkuZ
	KSf62XKGdCZAmJ0gZd8FSqUKYRBriwPix/ttoWeg3L9ajqznRe0OlLzm1a+ziBdMlApevoc4sYW
	SL3ArUOVRLL0Ug==
X-Received: by 2002:a05:6402:11c7:b0:6a6:32fa:1e99 with SMTP id 4fb4d7f45d1cf-6a632fa1f41mr6814150a12.17.1788164103229;
        Mon, 31 Aug 2026 01:15:03 -0700 (PDT)
Message-ID: <dc4dbc44-db87-4de3-9246-e91f50a50c9c@suse.com>
Date: Mon, 31 Aug 2026 10:15:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech,
 julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-3-frn1furkan10@gmail.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <20260831051637.5029-3-frn1furkan10@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------DWM0289lF4t9Wvzmxn75QdGO"
X-purgate-ID: tlsNG-bad1c0/1788164103-3B6D2034-DEC4EAEF/0/0
X-purgate-type: clean
X-purgate-size: 10009

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------DWM0289lF4t9Wvzmxn75QdGO
Content-Type: multipart/mixed; boundary="------------2q1Kb8RhwnZp9ay7kIyrojY0";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech,
 julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech
Message-ID: <dc4dbc44-db87-4de3-9246-e91f50a50c9c@suse.com>
Subject: Re: [PATCH v3 2/2] xen/sched: core: kill unarmed timers on
 sched_init_vcpu() failure
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-3-frn1furkan10@gmail.com>
In-Reply-To: <20260831051637.5029-3-frn1furkan10@gmail.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------2q1Kb8RhwnZp9ay7kIyrojY0
Content-Type: multipart/mixed; boundary="------------YNB0V2PxAtL0o0IQAKoC2VX2"

--------------YNB0V2PxAtL0o0IQAKoC2VX2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMzEuMDguMjYgMDc6MTYsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gc2NoZWRfaW5p
dF92Y3B1KCkgY2FsbHMgaW5pdF90aW1lcigpIGZvciBhIHZjcHUncyBwZXJpb2RpY190aW1l
ciwNCj4gc2luZ2xlc2hvdF90aW1lciBhbmQgcG9sbF90aW1lciBiZWZvcmUgaXQgY2FuIGZh
aWwgLS0gdGhlc2UNCj4gYmVjb21lIGxpdmUsIGxpbmtlZCBpbnRvIHRoZWlyIHRhcmdldCBw
Q1BVJ3MgcGVyLWNwdSB0aW1lciBsaXN0DQo+IHJlZ2FyZGxlc3Mgb2Ygd2hhdCBoYXBwZW5z
IG5leHQuIElmIHRoZSBzY2hlZF9hbGxvY191ZGF0YSgpIGNhbGwNCj4gZnVydGhlciBkb3du
IHRoZW4gZmFpbHMsIHRoZSBmdW5jdGlvbiBmcmVlcyB0aGUgc2NoZWRfdW5pdCB2aWENCj4g
c2NoZWRfZnJlZV91bml0KCkgYW5kIHJldHVybnMgMSwgYnV0IG5ldmVyIHVubGlua3MgdGhl
c2UgdGhyZWUNCj4gdGltZXJzLg0KPiANCj4gVGhlIGNhbGxlciwgdmNwdV9jcmVhdGUoKSwg
bWFrZXMgdGhpcyB3b3JzZTogb24gc2NoZWRfaW5pdF92Y3B1KCkNCj4gcmV0dXJuaW5nIG5v
bnplcm8gaXQganVtcHMgdG8gZmFpbF93cSwgc2tpcHBpbmcgZmFpbF9zY2hlZCBhbmQNCj4g
dGh1cyBzY2hlZF9kZXN0cm95X3ZjcHUoKSAtLSB0aGUgb25seSBmdW5jdGlvbiBvbiB0aGlz
IHBhdGggdGhhdA0KPiBjYWxscyBraWxsX3RpbWVyKCkgb24gdGhlbS4gdmNwdV9kZXN0cm95
KCkgdGhlbiBmcmVlcyB0aGUgdmNwdSwNCj4gYW5kIHRoZSB0aHJlZSB0aW1lcnMgZW1iZWRk
ZWQgaW4gaXQsIHdoaWxlIHRoZXkgYXJlIHN0aWxsIGxpbmtlZA0KPiBpbnRvIHRoYXQgc2hh
cmVkIGxpc3QuDQo+IA0KPiBUaGlzIHNpbGVudGx5IGNvcnJ1cHRzIHRoYXQgbGlzdC4gSXQg
b25seSBzaG93cyB1cCBsYXRlciwgd2hlbg0KPiBzb21ldGhpbmcgZWxzZSB0b3VjaGVzIGEg
bmVpZ2hib3JpbmcgdGltZXI6IHNjaGVkX21vdmVfZG9tYWluKCkNCj4gY3Jhc2hlZCB3aXRo
ICJBc3NlcnRpb24gJ2VudHJ5LT5wcmV2LT5uZXh0ID09IGVudHJ5JyBmYWlsZWQiIG9uIGEN
Cj4gY29tcGxldGVseSB1bnJlbGF0ZWQsIHZhbGlkIHZjcHUncyB0aW1lci4NCj4gDQo+IENh
bGwgc2NoZWRfZGVzdHJveV92Y3B1KCkgaW4gc2NoZWRfaW5pdF92Y3B1KCkncyBvd24gZmFp
bHVyZQ0KPiBicmFuY2ggaW5zdGVhZCBvZiBzY2hlZF9mcmVlX3VuaXQoKSwgc28gaXQgZG9l
c24ndCBkZXBlbmQNCj4gb24gdGhlIGNhbGxlciByZWFjaGluZyBzY2hlZF9kZXN0cm95X3Zj
cHUoKSB0byB1bmRvIHdoYXQgaXQgc2V0DQo+IHVwIGl0c2VsZi4gc2NoZWRfZGVzdHJveV92
Y3B1KCkgYXNzdW1lcyB1bml0LT5wcml2IGlzIHNldCwgd2hpY2gNCj4gaXMgbm90IHRoZSBj
YXNlIGhlcmUsIHNvIG1ha2UgaXQgb25seSBmcmVlIHRoZSB1ZGF0YSBhbmQgcmVtb3ZlDQo+
IHRoZSB1bml0IGlmIHVuaXQtPnByaXYgaW4gbm9uLU5VTEwuDQo+IA0KPiBGaXhlczogZDg4
NGIxMDc3ODE3ICgiRG9tYWluIGNyZWF0aW9uL2Rlc3RydWN0aW9uIGNsZWFudXBzLiIpDQo+
IFNpZ25lZC1vZmYtYnk6IEZ1cmthbiBDYWxpc2thbiA8ZnJuMWZ1cmthbjEwQGdtYWlsLmNv
bT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0K
DQpKdWVyZ2VuDQo=
--------------YNB0V2PxAtL0o0IQAKoC2VX2
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------YNB0V2PxAtL0o0IQAKoC2VX2--

--------------2q1Kb8RhwnZp9ay7kIyrojY0--

--------------DWM0289lF4t9Wvzmxn75QdGO
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqVOAYFAwAAAAAACgkQsN6d1ii/Ey8r
SQf/cCUar0krTO+rYSJt4LhQW6FY9yAfyV/A2sa9EFRRbWxVsZgRwke4bF20+jBxO7hbT+rW9sp3
kEjx5+J9KerKVZuCtQtmchkHdb6JwP0UT2Hx5uAHYG27p/733R0gzJmxTb/r0GmX/IPKF6iOwzSK
fHwN5S76Bfb4io6d/tPq/v/0LmKQFEWIt9SHlY/qc04/iFZ747kyhznav8T8TU47ePQJj097wtgP
JLFBKrRoe/WWL8PwszYAS03NpxNWzsU21EkAgAL2saW91Q5lvubIdx5ZOHt+ntNp2q4QHD71DcdX
4DuC6oihOVmi4ok0wfyfyGouXCpYcCa82p7XVhBeIg==
=QCRr
-----END PGP SIGNATURE-----

--------------DWM0289lF4t9Wvzmxn75QdGO--


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 08:18:04 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 08:18:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403819.1637780 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xDO-0008D9-Ov; Mon, 31 Aug 2026 08:18:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403819.1637780; Mon, 31 Aug 2026 08:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xDO-0008D2-ML; Mon, 31 Aug 2026 08:18:02 +0000
Received: by outflank-mailman (input) for mailman id 1403819;
 Mon, 31 Aug 2026 08:18:01 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a056e571ab000c4f3@swg.vates.tech>)
 id 1x0xDM-0008Ci-C0
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 08:18:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0xDL-00HILx-97
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 10:17:59 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a056e571ab000c4f3@swg.vates.tech>)
 id 6a9538a0-8faa-0a2a0a5109dd-0a2a4508bc68-38
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:17:59 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a056e571ab000c4f3@swg.vates.tech>)
 id 6a9538b6-f659-0a2a45080019-b9ff1c12a955-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:17:58 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a056e571ab000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 08:17:52 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id B186E83C6B;
 Mon, 31 Aug 2026 10:17:51 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=xCIrsy0vk5HdgDHKC9uXE82dHwG+Q4rrwcNwSyd1Z9s=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=Ew76q4lZr4FgXNESdI9frQcUd5/tumyLZmdDKkIa+1V/KUGl5R2/TgI/BHQcGyOPl0EoafacH
 L6/kykHEJ7PoYQVBgx9ueUb3c2UuDP5eUB2aV22cowCrwAwhRQ1zk3c3R1a+ilUT4b8qd+iKE1S
 mFGr+7fzJVGqH5GGUnje/IetaExb3222xpjdb0eAtSP4NthHXCbU0pZ0f+33Wo0Yz5cZDIeCocs
 CI9WzO+gda1YoOeetwCRcykDUxkQ18AInWL1Nt175WN9eakM5p8uTa43/JSskNxwHc6l5oiaX2X
 +q/clXXcVwQ37wlGgXWFRv3lAmwwZULiTMUv7sBG+3nA==
X-Zone-Loop: 84ae25ab472b01e7921323f5f3eb26a8bfb44e5fa3c9
x-campaign-type: default
x-transaction-id: 8153bae4-2d92-4a7f-aa83-b213f61506fe
x-swg-uid: 01-26a1e598-47bd-44a5-b1d6-fd4e3740218a
X-Mailer: Sweego
Message-ID:
 <1788164272.8631fc262581453bbf619ec5b2062170.1a056e571ab000c4f3@vates.tech>
x-swg-bid: 1788164272.8631fc262581453bbf619ec5b2062170.1a056e571ab000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH 1/5] xen/riscv: always set A/D bits at boot time
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <caeaf406-6280-4b72-ae94-05da70408ea4@gmail.com>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844808.8631fc262581453bbf619ec5b2062170.1a043dad0d3000c4f3@vates.tech>
 <3adf6ef7-8024-420f-935b-17b142c73256@gmail.com>
 <1787925495.8631fc262581453bbf619ec5b2062170.1a048a9fec2000c4f3@vates.tech>
 <caeaf406-6280-4b72-ae94-05da70408ea4@gmail.com>
Date: Mon, 31 Aug 2026 10:17:46 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788164271; l=14758;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=vZLlpkmw7/XH6TvrzQHUULj3rLxHCAqYO56qlISD9Dc=;
 b=sye+EESJzt9vjXOggQA235oK8GG52zOmxhp1rAgaCLT3iUMNKbUZCTsbAxri62NdqDTcqs36u
 fVUfuPFDNjdCZOjQM6mRJ1kjubwjKQUkS1dVuqrMP6xiKVyN4DCIzJT
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788164271934
X-purgate-ID: tlsNG-c1860d/1788164279-CD74B87B-1B2BD176/0/0
X-purgate-type: clean
X-purgate-size: 14762

On 2026-08-28 18:12 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/28/26 3:58 PM, Baptiste Le Duc wrote:
> > On 2026-08-28 12:59 +0200, Oleksii Kurochko wrote:
> >>
> >>
> >> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> >>> Always set the PTE A/D bits at boot time to avoid an unhandled page fault
> >>> on platforms that implement neither Svade nor Svadu, and on platforms that
> >>> declare both in the device tree.
> >>>
> >>> Rewrite the comment to enumerate the four possible Svade/Svadu combinations
> >>> (inspired by [1]) and set A/D unconditionally, which is correct in all four
> >>> cases until Svadu is fully supported (full support requires the SBI FWFT
> >>> call to enable hardware updating of A/D bits).
> >>>
> >>> [1] https://lwn.net/Articles/980016/
> >>>
> >>> Assisted-by: Claude:claude-opus-5
> >>> Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> >>> ---
> >>>    xen/arch/riscv/p2m.c | 70 ++++++++++++++++++++++++++------------------
> >>>    1 file changed, 42 insertions(+), 28 deletions(-)
> >>>
> >>> diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
> >>> index 1cea86512c..11dc289f0f 100644
> >>> --- a/xen/arch/riscv/p2m.c
> >>> +++ b/xen/arch/riscv/p2m.c
> >>> @@ -591,38 +591,52 @@ static void p2m_set_permission(pte_t *e, p2m_type_t t)
> >>>        e->pte |= PTE_USER;
> >>>    
> >>>        /*
> >>> -     * Two schemes to manage the A and D bits are defined:
> >>> -     *   • The Svade extension: when a virtual page is accessed and the A bit
> >>> -     *     is clear, or is written and the D bit is clear, a page-fault
> >>> -     *     exception is raised.
> >>> -     *   • When the Svade extension is not implemented, the following scheme
> >>> -     *     applies.
> >>> -     *     When a virtual page is accessed and the A bit is clear, the PTE is
> >>> -     *     updated to set the A bit. When the virtual page is written and the
> >>> -     *     D bit is clear, the PTE is updated to set the D bit. When G-stage
> >>> -     *     address translation is in use and is not Bare, the G-stage virtual
> >>> -     *     pages may be accessed or written by implicit accesses to VS-level
> >>> -     *     memory management data structures, such as page tables.
> >>> -     * Thereby to avoid a page-fault in case of Svade is available, it is
> >>> -     * necessary to set A and D bits.
> >>> +     * Svade and Svadu extensions represent two schemes for managing the PTE
> >>> +     * A/D bits. When the PTE A/D bits need to be set, the Svade extension
> >>> +     * indicates that a page fault will be raised. In contrast, the Svadu
> >>> +     * extension supports hardware updating of the PTE A/D bits.
> >>>         *
> >>> -     * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI
> >>> -     *       delegates page faults to a lower privilege mode and so OpenSBI
> >>> -     *       isn't expect to handle page-faults occured in lower modes.
> >>> -     *       By setting the A/D bits here, page faults that would otherwise
> >>> -     *       be generated due to unset A/D bits will not occur in Xen.
> >>> +     * There are 4 possible combinations of these extensions in the device
> >>> +     * tree. The default hardware behavior for each is:
> >>>         *
> >>> -     *       Currently, Xen on RISC-V does not make use of the information
> >>> -     *       that could be obtained from handling such page faults, which
> >>> -     *       could otherwise be useful for several use cases such as demand
> >>> -     *       paging, cache-flushing optimizations, memory access tracking,etc.
> >>> +     * 1) Neither Svade nor Svadu present in DT => It is technically unknown
> >>> +     *    whether the platform uses Svade or Svadu. Xen should be prepared to
> >>> +     *    handle either hardware updating of the PTE A/D bits or page faults
> >>> +     *    when they need updating. To support both, Xen always sets the 'A' and
> >>> +     *    'D' PTE bits at boot time.
> >>>         *
> >>> -     *       To support the more general case and the optimizations mentioned
> >>> -     *       above, it would be better to stop setting the A/D bits here and
> >>> -     *       instead handle page faults that occur due to unset A/D bits.
> >>> +     * 2) Only Svade present in DT => Xen must assume Svade to be always
> >>> +     *    enabled.
> >>> +     *
> >>> +     * 3) Only Svadu present in DT => Xen must assume Svadu to be always
> >>> +     *    enabled.
> >>> +     *
> >>> +     * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
> >>> +     *    off at boot time by setting A/D bits. To use Svadu, the supervisor
> >>> +     *    must explicitly enable it using the SBI FWFT extension.
> >>> +     *
> >>> +     * The Svade extension is mandatory and the Svadu extension is optional in
> >>> +     * the RVA23 profile. Platforms wanting to take advantage of Svadu can
> >>> +     * choose option 3. Platforms aware of the profile can choose option 4, and
> >>> +     * Linux won't get the benefit of Svadu until the SBI FWFT extension is
> >>> +     * available.
> >>
> >> I have a feeling that the DT-binding-related comment should not be
> >> present here, as it explains when Svadu or Svade should be considered
> >> enabled or disabled. We should perform this kind of detection in
> >> riscv_fill_hwcap() [cpufeature.c]. Then, in p2m_set_permission(), we
> >> should use riscv_isa_extension_available() to determine which extension
> >> is available and, based on that, set the A and D bits.
> >>
> >> At this point, I think the original comment was better, as it simply
> >> explained what Svade and Svadu are and, therefore, provided a better
> >> explanation of why the A and D bits should or should not be set.
> >>
> >> So, my suggestion is the following:
> >>
> >> +/*
> >> + * Svade and Svadu extensions represent two schemes for managing the PTE
> >> + * A/D bits. When the PTE A/D bits need to be set, the Svade extension
> >> + * indicates that a page fault will be raised. In contrast, the Svadu
> >> + * extension supports hardware updating of the PTE A/D bits.
> >> + *
> >> + * There are 4 possible combinations of these extensions in the device
> >> tree.
> >> + * The default hardware behavior for each is:
> >> + *
> >> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown
> >> + *    whether the platform uses Svade or Svadu. Xen should be prepared to
> >> + *    handle either hardware updating of the PTE A/D bits or page
> >> faults when
> >> + *    they need updating. To support both, Xen always sets the 'A' and
> >> 'D' PTE
> >> + *    bits at boot time.
> >> + *
> >> + * 2) Only Svade present in DT => Xen must assume Svade to be always
> >> enabled.
> >> + *
> >> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always
> >> enabled.
> >> + *
> >> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned
> >> + *    off at boot time by setting A/D bits. To use Svadu, the
> >> supervisor must
> >> + *    explicitly enable it using the SBI FWFT extension.
> >> + *
> >> + * The Svade extension is mandatory and the Svadu extension is optional
> >> in the
> >> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose
> >> + * option 3. Platforms aware of the profile can choose option 4, and
> >> Xen won't
> >> + * get the benefit of Svadu until the SBI FWFT extension is available.
> >> + *
> >> + * In other words, hardware manages the A/D bits on its own only in case 3;
> >> + * in all the other cases software has to preset them. Instead of open
> >> coding
> >> + * this in every A/D bits user, RISCV_ISA_EXT_svade is used to mean
> >> "software
> >> + * is responsible for the A/D bits" and is set here for the cases 1, 2
> >> and 4.
> >> + */
> >> +static void __init riscv_resolve_ad_scheme(void)
> >> +{
> >> +    bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade);
> >> +    bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu);
> >> +
> >> +    /* Case 3: leave the A/D bits management to hardware. */
> >> +    if ( svadu && !svade )
> >> +        return;
> >> +
> >> +    /* Cases 1, 2 and 4: Xen has to preset the A/D bits. */
> >> +    __set_bit(RISCV_ISA_EXT_svade, riscv_isa);
> >> +}
> >> +
> >>    void __init riscv_fill_hwcap(void)
> >>    {
> >>        unsigned int i;
> >> @@ -513,6 +560,8 @@ void __init riscv_fill_hwcap(void)
> >>            __set_bit(RISCV_ISA_EXT_sstc, riscv_isa);
> >>        }
> >>
> >> +    riscv_resolve_ad_scheme();
> >> +
> >>
> >> And then ...
> >>
> >>
> >>> +     *
> >>> +     * Currently, Xen on RISC-V does not make use of the information that could
> >>> +     * be obtained from handling such page faults, which could otherwise be
> >>> +     * useful for several use cases such as demand paging, cache-flushing
> >>> +     * optimizations, memory access tracking, etc.
> >>> +     *
> >>> +     * To support the more general case and the optimizations mentioned above,
> >>> +     * it would be better to stop setting the A/D bits here and instead handle
> >>> +     * page faults that occur due to unset A/D bits.
> >>> +     */
> >>> +
> >>> +    /*
> >>> +     * Preset unconditionally for all 4 cases above, harmless when Svadu
> >>> +     * manages the bits (case 3). Skipping it for case 3 requires SBI FWFT
> >>> +     * which is not yet supported.
> >>>         */
> >>> -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
> >>> -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
> >>> +    e->pte |= PTE_ACCESSED | PTE_DIRTY;
> >>
> >> ... we could restore the check and the comment we originally had in
> > 
> > Yes it makes sense as we now manually force the svade extension in 1, 2
> > and 4 cases.
> > 
> >> p2m_set_permission(), but probably with some updates, something along
> >> the following lines:
> >>
> >> /*
> >>    * Xen has to preset the A/D bits unless the hardware is known to update
> >>    * them on its own. riscv_fill_hwcap() folds all the Svade/Svadu device
> >>    * tree combinations into RISCV_ISA_EXT_svade, which then means that
> >>    * software is responsible for the A/D bits" (see
> >>    * riscv_resolve_ad_scheme()).
> >>    */
> >>
> >> I have another comment regarding:
> >>
> >>   > +    /*
> >>   > +     * Preset unconditionally for all 4 cases above, harmless when Svadu
> >>   > +     * manages the bits (case 3). Skipping it for case 3 requires
> >> SBI FWFT
> >>   > +     * which is not yet supported.
> >>   >        */
> >>   > -    if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
> >>   > -        e->pte |= PTE_ACCESSED | PTE_DIRTY;
> >>   > +    e->pte |= PTE_ACCESSED | PTE_DIRTY;
> >>
> >> I am not sure that this comment is correct. In case 3, we should not
> >> need to use the SBI FWFT extension. Case 3 means that Xen must assume
> >> that Svadu is enabled. Therefore, it is the responsibility of OpenSBI,
> >> or the pre-bootloader that loads OpenSBI, to enable it. If it fails to
> >> do so, then OpenSBI or the pre-bootloader is not complying with the DT
> >> binding documentation and it should be fixed in first place.
> > 
> > You right, thanks
> >>
> >> As further evidence, this is what OpenSBI already does [1]:
> >> /*
> >>    * Assume only Svadu is supported when it is the only extension
> >>    * present in the ISA string. Svade is assumed when neither are
> >>    * present. When both are present we must default to Svade (see
> >>    * the zero reset value of FWFT.PTE_AD_HW_UPDATING).
> >>    */
> >> if (!sbi_hart_has_extension(scratch, SBI_HART_EXT_SVADE))
> >>       __set_menvcfg_ext(SBI_HART_EXT_SVADU, ENVCFG_ADUE);
> >>
> >> Therefore, in case 3, the original check is still valid, and there is no
> >> need for Xen to support the SBI FWFT extension for this case. I think
> >> the original check should therefore be kept as it was:
> > 
> > Yes agree, I'll change that in v2.
> > 
> >> if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) )
> >>       e->pte |= PTE_ACCESSED | PTE_DIRTY;
> >>
> >> The SBI FWFT extension is only required for case 4. If both Svade and
> >> Svadu are present in the DT, Svade is selected by default. To use Svadu
> >> instead, SBI FWFT is required to set the ADUE bit in menvcfg, which is
> >> only accessible from M-mode.
> >>
> >> Since SBI FWFT is relatively new and may not be supported by older
> >> OpenSBI versions, another option is to have OpenSBI hard-code ADUE=1.
> >> Alternatively, the DTS could specify only one of Svade or Svadu in the
> >> riscv,isa property. In that case, upstream OpenSBI can handle the
> >> configuration automatically. So specifically for our case (Svadu and
> >> Svade things) we don't need SBI FWFT at all.
> > 
> > So if I understood correclty, you want to not let the option to change
> > ADUE bits in case 4 right? Therefore, I think we should document that
> > somewhere to clearly indicates that if someone want to use Svadu, he
> > should remove `svade` in the riscv,isa DT property.
> 
> Yes, that is exactly correct. Without SBI FWFT support, Xen cannot 
> toggle menvcfg.ADUE in Case 4. Thus, the only viable workaround to use 
> Svadu is to remove 'svade' from the riscv,isa DT property (Case 3), 
> which prompts OpenSBI to enable ADUE=1 at boot time.
> 
> I agree document that somewhere will make this behavior/intention clear!
> 
> Not insisting on that:
> I also think it would be a good idea to add an early printk() warning in 
> the detection logic when both Svade and Svadu are present but SBI FWFT 
> is missing, guiding users to drop 'svade' from their DT if they want to 
> leverage Svadu. Something like:
> 
> if ( svade && svadu )
> {
>      /* Assuming sbi_fwft_is_supported() or similar probe is available */
>      if ( !sbi_probe_extension(SBI_EXT_FWFT) )
>      {
>          printk(XENLOG_WARNING
>                 "RISC-V: Both Svade and Svadu detected, but SBI FWFT is 
> missing.\n"
>                 "RISC-V: Defaulting to software A/D updates (Svade).\n"
>                 "RISC-V: To force hardware A/D updates (Svadu), remove 
> 'svade' from DT.\n");
>      }
> }
> 
> somewhere in the function (riscv_resolve_ad_scheme) I suggested above.

Agree, it'll be better. I'm going to apply that in v2
> 
> >>
> >> [1]
> >> https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_hart.c#L171
> >>
> > Thanks for this very clear review.
> 
> Welcome.
> 
> ~ Oleksii
> 
> 
> 




From xen-devel-bounces@lists.xenproject.org Mon Aug 31 08:34:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 08:34:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403827.1637788 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xT1-00038E-5p; Mon, 31 Aug 2026 08:34:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403827.1637788; Mon, 31 Aug 2026 08:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xT1-000387-31; Mon, 31 Aug 2026 08:34:11 +0000
Received: by outflank-mailman (input) for mailman id 1403827;
 Mon, 31 Aug 2026 08:34:10 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <BATV+f7a82f6f9b31f2816fe4+8408+infradead.org+dwmw2@desiato.srs.infradead.org>)
 id 1x0xSz-00037z-5z
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 08:34:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0xSv-00EAuR-25; Mon, 31 Aug 2026 10:34:06 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <BATV+f7a82f6f9b31f2816fe4+8408+infradead.org+dwmw2@desiato.srs.infradead.org>)
 id 6a953c72-8faa-0a2a0a5109dd-0a2a450885c6-38
 for <multiple-recipients>; Mon, 31 Aug 2026 10:34:04 +0200
Received: from [90.155.92.199] (helo=desiato.infradead.org)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <BATV+f7a82f6f9b31f2816fe4+8408+infradead.org+dwmw2@desiato.srs.infradead.org>)
 id 6a953c7b-f659-0a2a45080019-5a9b5cc7e4d2-3
 for <multiple-recipients>; Mon, 31 Aug 2026 10:34:03 +0200
Received: from [172.31.31.139] (helo=ehlo.thunderbird.net)
 by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux))
 id 1x0xSh-00000009fo0-2qMu; Mon, 31 Aug 2026 08:33:52 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=desiato.20200630 header.d=infradead.org header.i="@infradead.org" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:References:In-Reply-To:Subject:CC:To:From:Date"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type
	:MIME-Version:Message-ID:References:In-Reply-To:Subject:CC:To:From:Date:
	Sender:Reply-To:Content-ID:Content-Description;
	bh=fwFFIqVPng0FWB2Lx9Y4U6/a8WISTMZbjmkj3/3M/bo=; b=D/LoRkGMPMWcvC1tfmgmSsxHUl
	7+eV1p2HvRNRdog29xhoCX7RSM0cYJ5dF6PraNmaZLyZMdgd4smlIoIL/E6YzjQ3J39wCCZOvyiGT
	pRHdlI8nCo09EGRj1Gty75vHN+hi3KlZ1dx3HTH/foJ6VhuobFEDTCM+dC/1+YHrVCCPGxou8rArY
	MqQ2Ue1bcIFA9JVdYN8XbUQHdxSBP/IGneOOOG8g9wLBg12IT5/WABmh8QEZiN4cJNY5niz3jnIdV
	VbB8NtU70JEm6auQoiI4RI7f6zcjlvW6f89YBpox+mKTaaUc8Cw5P3yL5RVOFUCJFY+yZz8x732Px
	VGcWnh5g==;
Date: Mon, 31 Aug 2026 09:33:52 +0100
From: David Woodhouse <dwmw2@infradead.org>
To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>,
 linux-kernel@vger.kernel.org
CC: kvm@vger.kernel.org, x86@kernel.org, seanjc@google.com, pbonzini@redhat.com,
 tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
 hpa@zytor.com, paul@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH] KVM: x86/xen: Convert evtchn_ports from IDR to XArray
User-Agent: K-9 Mail for Android
In-Reply-To: <85c66385-7a28-4779-96d4-6b34f53b5994@gmail.com>
References: <20260706081311.13633-1-frn1furkan10@gmail.com> <efe39d24a2621ce23f9d53471b3b587feaaa8526.camel@infradead.org> <85c66385-7a28-4779-96d4-6b34f53b5994@gmail.com>
Message-ID: <B9710C21-8127-4DC1-8DFF-D6551EE09AE5@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SRS-Rewrite: SMTP reverse-path rewritten from <dwmw2@infradead.org> by desiato.infradead.org. See http://www.infradead.org/rpr.html
X-purgate-ID: tlsNG-c1860d/1788165244-DFCD387B-3BB7CFB6/0/0
X-purgate-type: clean
X-purgate-size: 1119

On 31 August 2026 06:59:50 BST, "Furkan =C3=87al=C4=B1=C5=9Fkan" <frn1furka=
n10@gmail=2Ecom> wrote:
>
>
>On 7/7/26 12:16, David Woodhouse wrote:
>> On Mon, 2026-07-06 at 11:13 +0300, Furkan Caliskan wrote:
>>> IDR is deprecated in favor of XArray: see
>>> Documentation/core-api/idr=2Erst=2E Convert evtchn_ports accordingly=
=2E
>>>
>>> kvm_xen_eventfd_assign()'s single-slot idr_alloc() becomes
>>> xa_insert(), since it was really an insert-at-index, not an
>>> allocation: -EBUSY replaces -ENOSPC, still mapped to -EEXIST=2E
>>>
>>> kvm_xen_hcall_evtchn_send() drops its explicit rcu_read_lock(),
>>> since xa_load() takes its own RCU read-side section internally=2E
>>> evtchnfd's lifetime is still guaranteed by kvm->srcu=2E
>>>
>>> xen_lock is left in place: it protects state beyond the map itself=2E
>>>
>>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail=2Ecom>
>>=20
>> Reviewed-by: David Woodhouse <dwmw@amazon=2Eco=2Euk>
>>=20
>> Thanks=2E
>
>Ping?

I have a pile of Xen cleanups outstanding; I'll tack it on the end of that=
 series so it doesn't get lost=2E Thanks=2E



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 08:52:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 08:52:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403842.1637797 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xkp-0006kZ-Je; Mon, 31 Aug 2026 08:52:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403842.1637797; Mon, 31 Aug 2026 08:52:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0xkp-0006kS-H5; Mon, 31 Aug 2026 08:52:35 +0000
Received: by outflank-mailman (input) for mailman id 1403842;
 Mon, 31 Aug 2026 08:52:35 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057052c8f000c4f3@swg.vates.tech>)
 id 1x0xko-0006kM-UG
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 08:52:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0xko-00HOg5-0I
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 10:52:34 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057052c8f000c4f3@swg.vates.tech>)
 id 6a9540c8-2eae-0a2a0a5409dd-0a2a45018490-38
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:52:33 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057052c8f000c4f3@swg.vates.tech>)
 id 6a9540d1-5984-0a2a45010019-b9ff1c22b5cf-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 10:52:33 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a057052c8f000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 08:52:32 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 591BF81C20;
 Mon, 31 Aug 2026 10:52:31 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=wN4oI1pqSSmZevyRRnWvcJyhDznAEdGSpuUaffv3wmw=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=Pd2bliEne2MqW9XHs9TeWLHhJkwZvkXoDfQ8gWuKY4yWGevQ6Voro+IST7zUNadMbSPe6+Cxk
 aQxNFDt3YX9qqUEF/ezJqljP6jLyVHOual4A8EsX6HhRafzm3D7gfzR3Ozad+ygDI1plQdu48ES
 bk1ndkjFz8tpvUeW2NVTqii6UcioPvKqF/ZdL3uQIMxw//odFn/3itc98/TRHu4rIaelDtu8Un2
 bX7C1huC734ZWu5yjfjZeAhEn4PXc36mJ38FELmukz97la2brFv4SaDdgaidqBkpSXCGDs3uzvU
 38Hvh3We0XYlwtbaIO0lEDFIdhSghZMcReTsconnQI+g==
X-Zone-Loop: 77bef7a25afbb8c1c271140f68a267aa421f1c1cd451
x-campaign-type: default
x-transaction-id: 759c395a-9d1a-4f8f-b2d7-4eea986510c0
x-swg-uid: 01-8e5f51f7-83f5-42e7-b83c-eab78d885aef
X-Mailer: Sweego
Message-ID:
 <1788166352.8631fc262581453bbf619ec5b2062170.1a057052c8f000c4f3@vates.tech>
x-swg-bid: 1788166352.8631fc262581453bbf619ec5b2062170.1a057052c8f000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH 2/5] xen/riscv: preset A/D bits in Xen's own page-table
 mappings
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <ec69b941-2648-4c3f-bbee-95d4d56fb543@gmail.com>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad225000c4f3@vates.tech>
 <ec69b941-2648-4c3f-bbee-95d4d56fb543@gmail.com>
Date: Mon, 31 Aug 2026 10:52:25 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788166351; l=6991;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=hRP6UFdLtn4+d3XHYIuVBgH7BQrTA6/VZs1SM9O2+RE=;
 b=SJOS/PMIUSgyDIsw4RVcN/0dn0eNDunjh7/G2N79YTKpO89HqOk4uP69MGLV/vh6tPfiqlFaU
 a5ZVauZdA/xA4qWu5iqpXclnHEtLxWdrQebOzcJzAgBea0NptSepSqv
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788166351555
X-purgate-ID: tlsNG-d62444/1788166353-BF86F757-24F670EE/0/0
X-purgate-type: clean
X-purgate-size: 6995

On 2026-08-28 15:34 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> > The previous patch made p2m_set_permission() always set the PTE A/D bits to
> > map pages in G-stage, to avoid a page fault on platforms that implement
> > neither Svade nor Svadu, or that declare both in the device tree. Xen's own
> > page tables, built by setup_initial_mapping(), never go through
> > p2m_set_permission() and need the same fix.
> > 
> > Add PTE_ACCESSED to PTE_LEAF_DEFAULT and make it the minimal common leaf
> > permission set by dropping PTE_WRITABLE. Rebuild PAGE_HYPERVISOR_RO,
> > PAGE_HYPERVISOR_RW and PAGE_HYPERVISOR_RX from that common base, with
> > PAGE_HYPERVISOR_RW also adding PTE_DIRTY. Switch setup_initial_mapping() to
> > use these macros for its default, text, and rodata permissions instead of
> > the equivalent raw bit lists.
> > 
> > A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so
> > update pte_is_table() accordingly.
> > 
> > Assisted-by: Claude:claude-opus-5
> > Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> > ---
> >   xen/arch/riscv/include/asm/page.h | 14 ++++++++------
> >   xen/arch/riscv/mm.c               |  7 +++----
> >   2 files changed, 11 insertions(+), 10 deletions(-)
> > 
> > diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
> > index b465a90325..5c02f64a17 100644
> > --- a/xen/arch/riscv/include/asm/page.h
> > +++ b/xen/arch/riscv/include/asm/page.h
> > @@ -46,12 +46,12 @@
> >   #define PTE_PBMT_NOCACHE            BIT(61, UL)
> >   #define PTE_PBMT_IO                 BIT(62, UL)
> >   
> > -#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
> > +#define PTE_LEAF_DEFAULT            (PTE_VALID | PTE_READABLE | PTE_ACCESSED)
> 
> Dropping PTE_WRITABLE here silently changes the permissions of an 
> existing user of this macro that the patch doesn't touch.
> 
> check_pgtbl_mode_support() in mm.c still builds its temporary root entry as:
>   index = pt_index(page_table_level, aligned_load_start);
>   stage1_pgtbl_root[index] = paddr_to_pte(aligned_load_start,
>                                       PTE_LEAF_DEFAULT | PTE_EXECUTABLE);
> 
> Before this patch that evaluated to V|R|W|X (RWX); afterwards it is 
> V|R|A|X (RX). So the mapping loses write permission.
> 
> I believe that is harmless in practice: the entry is only alive between 
> the csr_write(CSR_SATP, ...) that turns the MMU on and the 
> csr_write(CSR_SATP, 0) a few lines below, it only has to make the 
> current instruction stream fetchable so that the SATP mode probe can 
> complete, and nothing writes through it. Arguably RX is the better 
> permission set for it anyway. But it is still a behavioural change 
> rather than a cosmetic one, and the commit message doesn't mention it(it 
> only talks about setup_initial_mapping()).
> Please call it out explicitly there.
> 
> While at it, this site should be converted too:
> 
>      stage1_pgtbl_root[index] = paddr_to_pte(aligned_load_start,
>                                              PAGE_HYPERVISOR_RX);
> 
>
Sorry I didn't see this call site, you're right, it'll be better.
I will also explain why it goes from RWX to RX in the commit message.

> Otherwise the patch converts three sites in setup_initial_mapping() to 
> the new PAGE_HYPERVISOR_* macros while leaving a fourth one open-coding 
> the redefined PTE_LEAF_DEFAULT, which is exactly the kind of asymmetry 
> that makes the redefinition easy to miss on the next change.
> 
> After that conversion PTE_LEAF_DEFAULT has no users left
> outside page.h itself, so it could either be dropped entirely in favour 
> of PAGE_HYPERVISOR_{RO,RW,RX}, or renamed to something that reflects its 
> new meaning (PTE_LEAF_COMMON or similar). "DEFAULT" now names a set that 

I think, as every leaf pages could be read, it makes sense to rename it
to PTE_LEAF_COMMON, to make it clear it provides the minimal set of access.

> is not a usable permission on its own, which is misleading.
> 
> >   #define PTE_TABLE                   (PTE_VALID)
> >   
> > -#define PAGE_HYPERVISOR_RO          (PTE_VALID | PTE_READABLE)
> > -#define PAGE_HYPERVISOR_RW          (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
> > -#define PAGE_HYPERVISOR_RX          (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE)
> > +#define PAGE_HYPERVISOR_RO          (PTE_LEAF_DEFAULT)
> > +#define PAGE_HYPERVISOR_RW          (PTE_LEAF_DEFAULT | PTE_WRITABLE | PTE_DIRTY)
> > +#define PAGE_HYPERVISOR_RX          (PTE_LEAF_DEFAULT | PTE_EXECUTABLE)
> 
> Adding A/D to PAGE_HYPERVISOR_RW fixes a second site beyond the ones the
> commit message mentions, and I think it deserves to be spelled out.
> 
> arch_pmap_map() in asm/pmap.h writes the fixmap leaf entry directly:
>      pte = pte_from_mfn(mfn, PAGE_HYPERVISOR_RW);
>      write_pte(entry, pte);
> i.e. it bypasses pt_update_entry(), which is the place that ORs in
> PTE_ACCESSED | PTE_DIRTY for everything going through map_pages_to_xen().
> So before this patch every pmap mapping was installed with A=D=0 and 
> would fault on first access under Svade, in exactly the same way the 
> boot page tables did.
> 
> The commit message currently frames the problem as "Xen's own page 
> tables, built by setup_initial_mapping()", which undersells the fix. 
> Please extend it to say that arch_pmap_map() is affected as well, and 
> that it is fixed by the PAGE_HYPERVISOR_RW change rather than by the 
> mm.c conversion.
Right, I will do that in v2.
> 
> FWIW I checked the remaining leaf-PTE construction sites (paddr_to_pte() 
> /pte_from_mfn() callers) and with these two the series covers all of 
> them: everything else either builds table entries (PTE_TABLE) or goes 
> through pt_update_entry() / p2m_set_permission(), both of which set A/D 
> themselves.
> 
> >   
> >   #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
> >   /*
> > @@ -177,7 +177,8 @@ static inline bool pte_is_table(pte_t p)
> >        *
> >        * PAGE_HYPERVISOR_RW contains PTE_VALID too.
> >        */
> > -    ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE)));
> > +    ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) !=
> > +           (PTE_VALID | PTE_WRITABLE));
> 
> Please drop the last line of the comment above it:
Ok I'll do that.
> 
>       * PAGE_HYPERVISOR_RW contains PTE_VALID too.
> 
> That sentence existed only to explain why the old mask was written as
> PAGE_HYPERVISOR_RW, i.e. that the macro is not just R|W but carries
> PTE_VALID as well, which is what made the comparison against V|W work.
> With the mask now written out literally, the macro is no longer 
> referenced anywhere in the function, so the line dangles. It is also 
> inaccurate now, since PAGE_HYPERVISOR_RW carries A and D in addition to V.
> 
> ~ Oleksii
> 
> 




From xen-devel-bounces@lists.xenproject.org Mon Aug 31 09:13:31 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 09:13:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403853.1637808 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0y4y-00024M-61; Mon, 31 Aug 2026 09:13:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403853.1637808; Mon, 31 Aug 2026 09:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0y4y-00024F-24; Mon, 31 Aug 2026 09:13:24 +0000
Received: by outflank-mailman (input) for mailman id 1403853;
 Mon, 31 Aug 2026 09:13:22 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1x0y4w-000249-LA
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 09:13:22 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0y4v-00EI6R-K5
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 11:13:21 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a9545a1-2eae-0a2a0a5409dd-0a2a4502b3b0-46
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:13:21 +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 <frn1furkan10@gmail.com>)
 id 6a9545b1-6ca4-0a2a45020019-d155dd2fd8ab-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:13:21 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-484392e3d33so578231f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 02:13:21 -0700 (PDT)
Received: from [192.168.1.109] ([88.230.40.90])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbb20122sm21314885f8f.20.2026.08.31.02.13.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2026 02:13:20 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1788167601; x=1788772401; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=bSin6Js2gCPHZZGDWSi0U8VJbZpW2FdB8ozBQJ9foqw=;
        b=LBgfeuOuAPifYlFfmie6ah3XC0Ffkq8Nxt6YjHIQuOVExKztcL/ynVEDH1ntvwj5EW
         5ze/zgLGOd/22zKO5mj2MJpR0X32jBOb+RHgKxWz1d572zntvYRP7QwBxG63SFQjtfF3
         9XVWiypnPTd3wg8ckQsityxB8YYmSvn9OfaQ6gzq6r/jfgC8RQDRJa/eidryW4KgE0AN
         rr9IxHXbqeOyuoKss7LsYoSnFpeoxDaqxkSD1qrWw184hKnC+jHZxraqo3FCWrFcngLU
         RELg6tfydY1Fu2r2I6ArC9/Snbc75J3wNmkngr4aC5zxbonl+W9xmXOeApu/+lngRo67
         hHQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788167601; x=1788772401;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=bSin6Js2gCPHZZGDWSi0U8VJbZpW2FdB8ozBQJ9foqw=;
        b=avMMRuigYZxTlNbqUNqxAfEL0DM7zsJcvpxTSMcikuaZcUeT2Cb5H6IQCM4VSX2w17
         KhPMjuK/q/jO+9o8f9Iypv3jYCq66jOoli1z7Z3wn2UtV6ITWqEzuftqTq1S52YNuJ3j
         bHU6BV0ERIiKIgMdnlmt7fg60dUDvkIQ3yWf6+YnYgx5XzH1mIHnnc+PPSYPrkfVSM0x
         dFe4R+/z1T9VtGijA9YJsgem7zpjb+hnjtKCQGo0NCnkBOsH6CqpDPV3hPi4GD4eHxRZ
         JWAHPofaO1vysF76N3jk2oxXusKJ8jVyWgMJ/ojsYRMB0DZSWDNEqhoNj2liUaCqaWlm
         50Wg==
X-Forwarded-Encrypted: i=1; AKwUvBwioVN/hM74b4rKZqV/J8CIe42kpfoQRWcGa9NKZmmVpLf8/4LCww0gatdLjxfZcPxDxTVfXyVbXRI=@lists.xenproject.org
X-Gm-Message-State: AFuF++nyJ/e4lcK5QLM10X82wemBFaXcxDYBZCFS9XClyhD1QR/92aul
	vSjAV44ricHXkN3Jy+p0CFFg7tDx+sjdXbK8nt5lAmZUn50g3Lzfn2WP
X-Gm-Gg: AYBFou1QVxghKh6WGj+o+o4b7/VTEaV/lidkzy6ymA12k773sCGq0exNLVFryKSmktK
	RQl0huocfBvT3Ho8jAUfJ0YK7KaReBSynVAHwFmNiJZj9C6qPxZoopAnvE7jDnHBWvaHcfcEPH0
	zlct2J9BWEe6IIpOAwQvAKlLqfMA5Vna7yBuiJuoRDgyqAuYxmOd8CuGIC1bysNWGlZ1pi8ut+V
	ygw6zDOxv7iNUONvbvmKBnM1mJs7FahqqIiwxsd35O8mPyT3mplBJ86wJZftmOBEk0ddnPy5bq8
	QR7mMD/TfOxN/h8pzUB57UzPxsG/ExvRScYuU3Auv0dYrA/2XHQe4X3WY7V0FU44MNT1lcA24Pw
	5YFiQNupHYYjVVs41yRhpPU4PoQPkStf1RGhD5uUFNyR4CH4R8tMS2oH1ho7tvMjgmfrQQYSMM7
	xHJiAcS34NLD4E51+1pSrDFJzgROB/zCcx+uy44WJUHaWLnBHF7uuX1dNOaseYHkyyg3k=
X-Received: by 2002:a05:6000:70f:b0:484:3328:4a5c with SMTP id ffacd0b85a97d-48433284c41mr21916625f8f.28.1788167600773;
        Mon, 31 Aug 2026 02:13:20 -0700 (PDT)
Message-ID: <1d656813-176f-49a7-8a92-a156c5dc3821@gmail.com>
Date: Mon, 31 Aug 2026 12:13:17 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus
 in sync
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>,
 xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com,
 gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech,
 julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com,
 Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-2-frn1furkan10@gmail.com>
 <33c1d613-054e-4940-a14d-9e47e673286b@suse.com>
Content-Language: en-US
From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= <frn1furkan10@gmail.com>
In-Reply-To: <33c1d613-054e-4940-a14d-9e47e673286b@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1788167601-F3CBA2AC-1F7670CD/0/0
X-purgate-type: clean
X-purgate-size: 5954


On 8/31/26 11:13, Jürgen Groß wrote:
> On 31.08.26 07:16, Furkan Caliskan wrote:
>> Every vcpu_create() call site that builds more than one vcpu loops
>> over ids up to d->max_vcpus and stops on the first failure, but none
>> of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL
>> for ids below max_vcpus, which anything walking d->vcpu[] can then
>> dereference. This is what caused the crash: sched_move_domain()
>> walks every vcpu slot up to max_vcpus without checking for empty
>> ones, so when a domain built in a non-default cpupool had vcpu
>> creation fail partway through, domain_kill() later moving it back
>> to the default cpupool handed one of its empty slots straight to
>> the new cpupool's scheduler, causing a NULL-pointer dereference
>> inside sched_alloc_udata().
>>
>> Add vcpus_create(d): creates every vcpu of d up to max_vcpus and
>> rolls max_vcpus back to the failed id on error. This keeps
>> d->vcpu[i] is non-NULL for all i < d->max_vcpus, instead of guarding
>> every reader of d->vcpu[] agains holes individually.
>>
>> Convert every site that builds vcpus in a loop to call this function
>> instead.
>>
>> Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()")
>> Suggested-by: Juergen Gross <jgross@suse.com>
>> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
>> ---
>> v3:
>>   - Reworked per Juergen's suggestion: instead of guarding
>>     sched_move_domain() against a missing vcpu slot, keep d->max_vcpus
>>     in sync with the vcpus actually created. Added vcpus_create() and
>>     converted every vcpu_create() loop to use it.
>>   - Reverted the sched_move_domain() check from v2, now unneeded.
>> ---
>>   xen/arch/arm/domain_build.c   | 15 +++++++--------
>>   xen/arch/x86/mm/mem_sharing.c | 11 ++---------
>>   xen/common/domain.c           | 24 ++++++++++++++++++++++++
>>   xen/common/domctl.c           | 19 ++++---------------
>>   xen/common/sched/core.c       |  7 +++----
>>   xen/include/xen/domain.h      |  1 +
>>   6 files changed, 41 insertions(+), 36 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 72d5316180..e08ee21ee5 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1774,6 +1774,7 @@ static void __init find_gnttab_region(struct domain *d,
>>   int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>>   {
>>       unsigned int i;
>> +    int rc;
>>       struct vcpu *v = d->vcpu[0];
>>       struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
>>   @@ -1842,17 +1843,15 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
>>       }
>>   #endif
>>   -    for ( i = 1; i < d->max_vcpus; i++ )
>> +    if ( (rc = vcpus_create(d)) )
>>       {
>> -        if ( vcpu_create(d, i) == NULL )
>> -        {
>> -            printk("Failed to allocate d%dv%d\n", d->domain_id, i);
>> -            return -ENOMEM;
>> -        }
>> +        printk("Failed to allocate d%dv%d\n", d->domain_id, d->max_vcpus);
>> +        return rc;
>> +    }
>>   -        if ( is_64bit_domain(d) )
>> +    if ( is_64bit_domain(d) )
>> +        for ( i = 1; i < d->max_vcpus; i++ )
>>               vcpu_switch_to_aarch64_mode(d->vcpu[i]);
>> -    }
>>         domain_update_node_affinity(d);
>>   diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
>> index 5c7a0ff30e..cd7f747c80 100644
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1612,21 +1612,14 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
>>     static int bring_up_vcpus(struct domain *cd, struct domain *d)
>>   {
>> -    unsigned int i;
>>       int ret = -EINVAL;
>>         if ( d->max_vcpus != cd->max_vcpus ||
>>           (ret = cpupool_move_domain(cd, d->cpupool)) )
>>           return ret;
>>   -    for ( i = 0; i < cd->max_vcpus; i++ )
>> -    {
>> -        if ( !d->vcpu[i] || cd->vcpu[i] )
>> -            continue;
>> -
>> -        if ( !vcpu_create(cd, i) )
>> -            return -EINVAL;
>> -    }
>> +    if ( (ret = vcpus_create(cd)) )
>> +        return ret;
>>         domain_update_node_affinity(cd);
>>       return 0;
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index e16f1ac383..a0a3e51b15 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -539,6 +539,30 @@ struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id)
>>       return NULL;
>>   }
>>   +/*
>> + * Create every not yet existing vcpu of d, up to d->max_vcpus. On failure,
>> + * d->max_vcpus is rolled back to the id that failed, keeping d->vcpu[i]
>> + * non-NULL for all i < d->max_vcpus.
>> + */
>> +int vcpus_create(struct domain *d)
>> +{
>> +    unsigned int i;
>> +
>> +    for ( i = 0; i < d->max_vcpus; i++ )
>> +    {
>> +        if ( d->vcpu[i] )
>> +            continue;
>> +
>> +        if ( vcpu_create(d, i) == NULL )
>> +        {
>> +            d->max_vcpus = i;
>> +            return -EINVAL;
> 
> I think this should be -ENOMEM.
> 
> 
> Juergen

Currently vcpu_create() can only fail because of memory errors, so
-ENOMEM would be correct today. But I've sent a patch series that
adds RTDS admission control, which would make vcpu_create() also
fail for a capacity issue, so I went with -EINVAL here to not only
tie it to the memory failure.

If you'd rather keep it as -ENOMEM, I'm happy to update it.

Furkan



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 09:33:19 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 09:33:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403864.1637816 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0yO1-0005Le-Mx; Mon, 31 Aug 2026 09:33:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403864.1637816; Mon, 31 Aug 2026 09:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0yO1-0005LX-Jh; Mon, 31 Aug 2026 09:33:05 +0000
Received: by outflank-mailman (input) for mailman id 1403864;
 Mon, 31 Aug 2026 09:33:04 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <frn1furkan10@gmail.com>) id 1x0yO0-0005LO-Kp
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 09:33:04 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0yNz-004FyN-SZ
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 11:33:03 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a954a3d-8faa-0a2a0a5109dd-0a2a450ad042-26
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:33:03 +0200
Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <frn1furkan10@gmail.com>)
 id 6a954a4f-f2d2-0a2a450a0019-d155802ec183-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:33:03 +0200
Received: by mail-wm1-f46.google.com with SMTP id
 5b1f17b1804b1-49b8687630fso23011295e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 02:33:03 -0700 (PDT)
Received: from notebook.. ([88.230.40.90]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbab5a2csm19211268f8f.4.2026.08.31.02.33.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 02:33:02 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
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=1788168783; x=1788773583; 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=Ew5tNWjshpkIdmi3bl3fAmKE4835tm4KGljhRmFiYHo=;
        b=maym6Q8If5XAkogFJ23PxVHtCsfiKXw8NCmH7O5d7fvPqF16XZhXD71S1NQw4+M2tm
         PZTzpCcId+/1gh/zOm0SKTNuSRGcZqzJgaiqmcsaHQCbFEBVMHqbqvsWr4UIwlk6tc6i
         Lm1hgrezZ66QmsY7S+m/7doUFcs1e7OS/48LSgP8E+T++F7WLOoPcX6ziRngSmsN9WHZ
         tZEQ9AXgsCvZcf5WBGDDLQlqBpzyEwA8Rl2br75jb6IHQPM2qgaHUkUrlYBio8Vti4+I
         iTJJ780UNNx9h/APwPCWSBYGzuIIzyMcBxI25v+OcusxtWlj28uC00iJZHNQNvivDECO
         4+Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788168783; x=1788773583;
        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=Ew5tNWjshpkIdmi3bl3fAmKE4835tm4KGljhRmFiYHo=;
        b=bJ08PxtaJxebOgXvNt7u5lfk/QWYWzikkfrckwKbClKoeQLFQPHnu2+v/+tcjEFHmO
         psjcQhYlPp+BjgQGs+nl0a4C1THE+7dnwNTEvQj2JS/H/gI/AdujpTrCWF7ZJOEPMyiL
         E3zmlebyEe8wgFkwPDsOyCdkwkYzQ4HArQti31buifyrsIzZ9ocl6hEKzASfvtwaV3g1
         WJXZtra0vI2624igqdLMT6K2SuedYU2226pI1zKb7zsCGvRZy6KPJGMpr0qhbuBmnDLL
         vKYjObtXd2cGSHZU32yzj/nbwy8Ud1N5ok/SYYkW28Ak4ffiKsG58EjGikkAxjBWX4s5
         nhcg==
X-Gm-Message-State: AFuF++lsWq+tuaqx0Xpv5Ru6PRBvYp/B2hG88K6YkWsYwmakBuAsq/KV
	CF7sOrylZ8FCZjZ00fTHLGqpIzseFe11EyBG9QmpPCaCqyNmRXGv6DlgLWj0xQ==
X-Gm-Gg: AR+sD11dOc0ifx7kgLfMxhzGh9U2ltKmV59oLGYW2Y1/NBBjHbGVkNUmQmtpVAQF6dH
	+GwM0uEww8axeWXlrQXDAomCnF/ZObu6BnJ2cVy4en+eouFOMDERweJ/eAXGpSLrIcf7K5BncLg
	CBhW+6+3H0KqY27Vc+7RYp2XS0Pd985gQgUUAKL0sJWaPfh0ypQmFO+Jf+YcNxrSsazQDpqP5/u
	+pK3V7DEf3N7c+WR53lt05J+mK2XQG3b08Txrr272psrd9ORHZ7KQ56einvqJjhO0AyVVxb2GTq
	puAHXqON+J6EfvPpLsT4OLDqMYPYUW8q/szJu0w2CiREXOPtx7qYGoUoCRopbEG9nv4mp8juYl8
	1Z1Cfw3H4bAEZgko8rEeQV3fRga2Cdu7pKRT947tPNb/xGMFrmWlBGVHhrPUiI0riB5JWvTnu/z
	Y+Jh42bM6CfMFUK4KuTIB7XfnbvJ32/Rij/h4BeUVdSPZRrT06lNMHwSM6pq0=
X-Received: by 2002:a05:600c:3b21:b0:498:952:e276 with SMTP id 5b1f17b1804b1-49b91c3f643mr353135395e9.8.1788168782736;
        Mon, 31 Aug 2026 02:33:02 -0700 (PDT)
From: Furkan Caliskan <frn1furkan10@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com,
	jbeulich@suse.com,
	andrew.cooper3@citrix.com,
	Furkan Caliskan <frn1furkan10@gmail.com>
Subject: [PATCH v4] xen/common: add vcpus_create() and keep max_vcpus in sync
Date: Mon, 31 Aug 2026 12:32:19 +0300
Message-Id: <20260831093219.9815-1-frn1furkan10@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20260831051637.5029-2-frn1furkan10@gmail.com>
References: <20260831051637.5029-2-frn1furkan10@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-4011c0/1788168783-510C9CFC-B3FF9457/0/0
X-purgate-type: clean
X-purgate-size: 6769

Every vcpu_create() call site that builds more than one vcpu loops
over ids up to d->max_vcpus and stops on the first failure, but none
of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL
for ids below max_vcpus, which anything walking d->vcpu[] can then
dereference. This is what caused the crash: sched_move_domain()
walks every vcpu slot up to max_vcpus without checking for empty
ones, so when a domain built in a non-default cpupool had vcpu
creation fail partway through, domain_kill() later moving it back
to the default cpupool handed one of its empty slots straight to
the new cpupool's scheduler, causing a NULL-pointer dereference
inside sched_alloc_udata().

Add vcpus_create(d): creates every vcpu of d up to max_vcpus and
rolls max_vcpus back to the failed id on error. This keeps
d->vcpu[i] is non-NULL for all i < d->max_vcpus, instead of guarding
every reader of d->vcpu[] agains holes individually.

Convert every site that builds vcpus in a loop to call this function
instead.

Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()")
Suggested-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
---
v4:
 - Return -ENOMEM instead of -EINVAL from vcpus_create() on failure.
---
 xen/arch/arm/domain_build.c   | 15 +++++++--------
 xen/arch/x86/mm/mem_sharing.c | 11 ++---------
 xen/common/domain.c           | 24 ++++++++++++++++++++++++
 xen/common/domctl.c           | 19 ++++---------------
 xen/common/sched/core.c       |  7 +++----
 xen/include/xen/domain.h      |  1 +
 6 files changed, 41 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72d5316180..e08ee21ee5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1774,6 +1774,7 @@ static void __init find_gnttab_region(struct domain *d,
 int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
 {
     unsigned int i;
+    int rc;
     struct vcpu *v = d->vcpu[0];
     struct cpu_user_regs *regs = &v->arch.cpu_info->guest_cpu_user_regs;
 
@@ -1842,17 +1843,15 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
     }
 #endif
 
-    for ( i = 1; i < d->max_vcpus; i++ )
+    if ( (rc = vcpus_create(d)) )
     {
-        if ( vcpu_create(d, i) == NULL )
-        {
-            printk("Failed to allocate d%dv%d\n", d->domain_id, i);
-            return -ENOMEM;
-        }
+        printk("Failed to allocate d%dv%d\n", d->domain_id, d->max_vcpus);
+        return rc;
+    }
 
-        if ( is_64bit_domain(d) )
+    if ( is_64bit_domain(d) )
+        for ( i = 1; i < d->max_vcpus; i++ )
             vcpu_switch_to_aarch64_mode(d->vcpu[i]);
-    }
 
     domain_update_node_affinity(d);
 
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5c7a0ff30e..cd7f747c80 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1612,21 +1612,14 @@ int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
 
 static int bring_up_vcpus(struct domain *cd, struct domain *d)
 {
-    unsigned int i;
     int ret = -EINVAL;
 
     if ( d->max_vcpus != cd->max_vcpus ||
         (ret = cpupool_move_domain(cd, d->cpupool)) )
         return ret;
 
-    for ( i = 0; i < cd->max_vcpus; i++ )
-    {
-        if ( !d->vcpu[i] || cd->vcpu[i] )
-            continue;
-
-        if ( !vcpu_create(cd, i) )
-            return -EINVAL;
-    }
+    if ( (ret = vcpus_create(cd)) )
+        return ret;
 
     domain_update_node_affinity(cd);
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e16f1ac383..32b7fa34d1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -539,6 +539,30 @@ struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id)
     return NULL;
 }
 
+/*
+ * Create every not yet existing vcpu of d, up to d->max_vcpus. On failure,
+ * d->max_vcpus is rolled back to the id that failed, keeping d->vcpu[i]
+ * non-NULL for all i < d->max_vcpus.
+ */
+int vcpus_create(struct domain *d)
+{
+    unsigned int i;
+
+    for ( i = 0; i < d->max_vcpus; i++ )
+    {
+        if ( d->vcpu[i] )
+            continue;
+
+        if ( vcpu_create(d, i) == NULL )
+        {
+            d->max_vcpus = i;
+            return -ENOMEM;
+        }
+    }
+
+    return 0;
+}
+
 static int late_hwdom_init(struct domain *d)
 {
 #ifdef CONFIG_LATE_HWDOM
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a6210db4fb..39f3f219ca 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -698,7 +698,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 
     case XEN_DOMCTL_max_vcpus:
     {
-        unsigned int i, max = op->u.max_vcpus.max;
+        unsigned int max = op->u.max_vcpus.max;
 
         ret = -EINVAL;
         if ( (d == current->domain) || /* no domain_pause() */
@@ -708,21 +708,10 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
-        ret = -ENOMEM;
-
-        for ( i = 0; i < max; i++ )
-        {
-            if ( d->vcpu[i] != NULL )
-                continue;
-
-            if ( vcpu_create(d, i) == NULL )
-                goto maxvcpu_out;
-        }
-
-        domain_update_node_affinity(d);
-        ret = 0;
+        ret = vcpus_create(d);
+        if ( !ret )
+            domain_update_node_affinity(d);
 
-    maxvcpu_out:
         domain_unpause(d);
         break;
     }
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index d3a0a97e1d..14069eed03 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -3497,10 +3497,9 @@ void wait(void)
 #ifdef CONFIG_X86
 void __init sched_setup_dom0_vcpus(struct domain *d)
 {
-    unsigned int i;
-
-    for ( i = 1; i < d->max_vcpus; i++ )
-        vcpu_create(d, i);
+    if ( vcpus_create(d) )
+        printk("Failed to create all vcpus of dom0 (max_vcpus now %u)\n",
+               d->max_vcpus);
 
     domain_update_node_affinity(d);
 }
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index aeb8b36ad1..eaf406a814 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -34,6 +34,7 @@ typedef union {
 } vcpu_guest_context_u __attribute__((__transparent_union__));
 
 struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id);
+int vcpus_create(struct domain *d);
 
 unsigned int dom0_max_vcpus(void);
 int parse_arch_dom0_param(const char *s, const char *e);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 09:36:39 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 09:36:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403874.1637824 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0yRS-0005vN-7U; Mon, 31 Aug 2026 09:36:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403874.1637824; Mon, 31 Aug 2026 09:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0yRS-0005vG-4p; Mon, 31 Aug 2026 09:36:38 +0000
Received: by outflank-mailman (input) for mailman id 1403874;
 Mon, 31 Aug 2026 09:36:36 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3@swg.vates.tech>)
 id 1x0yRQ-0005vA-LQ
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 09:36:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0yRP-007mac-UU
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 11:36:35 +0200
Received: from [10.42.69.4] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3@swg.vates.tech>)
 id 6a954b15-bab6-0a2a0a5309dd-0a2a4504b14c-38
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:36:35 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3@swg.vates.tech>)
 id 6a954b23-b57f-0a2a45040019-b9ff1c23ac5d-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:36:35 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a0572d6c8c000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 09:36:29 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 0017C81EAC;
 Mon, 31 Aug 2026 11:36:28 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=V72sOzyfnl3IHLjnqMmWoRQ7+O2JNIDOHwfWGiGLkKQ=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=X0PYdx1YshDqkdeXbHWj2QwVfkzrd5vcodAkYvbxH9qS5a90bL+JIgZFiaKnZKHCtskMHYOgi
 puY+j/ze9Oz/dV941RhbREMyXi0eP2QqxHobqHWOmiYupqAEBRPAjjUrwtGD63zOXj5vrvirtNQ
 AzgyV7G+vLZaSCla6ZSVVOxCtIQLWyPx6tMtlg7qKBfdSJh5HQF5KKyizDBa5a6B25XSCPtM77U
 manwaDtjKF/EFJAFamNOs4trp9KfNOfi+/irRsQ6gZDAIa0OGyYHbt7boR7L7iYj1/xllzeEooH
 NmNC10lUGHKRiJbXYKfUwaDfSP5XjTslj1hwS7q0jgXQ==
X-Zone-Loop: a571ece7896f0d778c25f48f5cffbb25c85490630e6e
x-campaign-type: default
x-transaction-id: df7a2b66-4ff3-481d-bf54-4b2155641ceb
x-swg-uid: 01-3716f76d-3745-43c4-a2b4-9e4a048df7eb
X-Mailer: Sweego
Message-ID:
 <1788168989.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3@vates.tech>
x-swg-bid: 1788168989.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH 3/5] xen/riscv: make Svpbmt no longer a required
 extension
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <59555237-425d-47f0-80b6-b7273cc8d6ec@gmail.com>
References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech>
 <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@vates.tech>
 <59555237-425d-47f0-80b6-b7273cc8d6ec@gmail.com>
Date: Mon, 31 Aug 2026 11:36:23 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788168988; l=9013;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=h3mzsBv6JC+6kUlZ1aQ07VMYT+56kdwcMGAvEw+Kios=;
 b=ivuWgvmD65CZZIdtwALGI3l34PgxghbltLLRejBCm9J5v7uDmgBUvGg+m2fcW9l0UtpLyyYLY
 zEt/tyHZ92wC/8U9oYGSM2RSKgeayOTOnP/rqCKgYEzg3vLdLmlM3Ua
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788168989190
X-purgate-ID: tlsNG-ebf023/1788168995-51AD0B50-E3EE8268/0/0
X-purgate-type: clean
X-purgate-size: 9017

On 2026-08-28 17:58 +0200, Oleksii Kurochko wrote:
> 
> 
> On 8/27/26 5:33 PM, Baptiste Le Duc wrote:
> > required_extensions[] panics at boot if Svpbmt is missing, which is a
> > problem on hardware that doesn't implement it.
> 
> Based only on this sentence it isn't clear why it is safe to have SvPBMT 
> = n and what guarantees that if some memory for a device dma for example 

Sorry I'm not used to this kind of terminology, does Svpbmt = n means that MT
bits ([62:61]) are equal to 0 = PMA?

> should be non-cachable and strongly ordered what will guarantee that.
> 
> So basically something like that should be added to the commit message:
> ```
> Without the Svpbmt extension, memory attributes (such as cacheability 
> and ordering) are strictly tied to physical address ranges and enforced 
> by the hardware's Physical Memory Attributes (PMA) checker.
> 
> In this configuration, supervisor software relies on the platform's 
> memory map: peripheral device registers (MMIO) are physically mapped 
> into hardware-defined I/O regions (which are implicitly non-cacheable 
> and strongly-ordered), while regular RAM is mapped as cacheable main 
> memory.
> 
> S-mode paging can safely map these physical ranges without specifying 
> page-based memory types in the PTEs, as the hardware MMU and PMA 
> pipeline will correctly bypass caches for MMIO accesses based on the 
> target physical address. 
I think this could go in the previous paragraph as it only concerns
of the configuration you mentionned.

> Furthermore, on platforms that either feature 
> fully hardware-coherent DMA or do not expose non-coherent DMA agents to 
> the OS, page-level programmatic cache control via Svpbmt is not 
> required, making it safe to boot and run when Svpbmt is absent.
If we have a platforms that doesn't have both of these feature, what
would happen? Do we need to add a check in Xen code?
> ```
>
> 
>   Xen already checks Svpbmt at
> > runtime in some places (vcpu_csr_init()), but not everywhere:
> 
> This part sounds like there are additional places where you think the 
> Svpbmt related bits should be set but I don’t see in this patch (or in 
> others in this patch series_ where you are adding Svpbmt related bits to 
> places where they weren’t added before. Am I missing something or did I 
> misunderstand your message? If the latter then could you please re-word 
> this part of the sentence.

No I was saying that before this patch, there were some places that
missed to have a Svpbmt availibility check, this patch fix them.
> 
> > p2m_pte_from_mfn() and the PAGE_HYPERVISOR_NOCACHE/WC macros still set the
> > raw PTE_PBMT* encoding unconditionally.
> > 
> > Drop Svpbmt from required_extensions, and introduce pte_pbmt(), which masks
> > the requested PBMT encoding down to 0 when Svpbmt is unavailable, using it
> > in both remaining unguarded spots.
> > 
> > Assisted-by: Claude:claude-opus-5
> > Signed-off-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
> > ---
> >   xen/arch/riscv/cpufeature.c       | 1 -
> >   xen/arch/riscv/include/asm/page.h | 8 ++++++--
> >   xen/arch/riscv/p2m.c              | 2 +-
> >   3 files changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
> > index 92235fdfd5..900cb9d772 100644
> > --- a/xen/arch/riscv/cpufeature.c
> > +++ b/xen/arch/riscv/cpufeature.c
> > @@ -157,7 +157,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = {
> >       RISCV_ISA_EXT_DATA(zifencei),
> >       RISCV_ISA_EXT_DATA(zihintpause),
> >       RISCV_ISA_EXT_DATA(zbb),
> > -    RISCV_ISA_EXT_DATA(svpbmt),
> >   };
> 
> Also, please update docs/misc/riscv/booting.txt.
> 
Right, I will do that in v2.
> >   
> >   static bool __init is_lowercase_extension_name(const char *str)
> > diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
> > index 5c02f64a17..6a3749526d 100644
> > --- a/xen/arch/riscv/include/asm/page.h
> > +++ b/xen/arch/riscv/include/asm/page.h
> > @@ -11,6 +11,7 @@
> >   #include <xen/types.h>
> >   
> >   #include <asm/atomic.h>
> > +#include <asm/cpufeature.h>
> >   #include <asm/page-bits.h>
> >   
> >   #define VPN_MASK                    (PAGETABLE_ENTRIES - 1UL)
> > @@ -54,6 +55,9 @@
> >   #define PAGE_HYPERVISOR_RX          (PTE_LEAF_DEFAULT | PTE_EXECUTABLE)
> >   
> >   #define PAGE_HYPERVISOR             PAGE_HYPERVISOR_RW
> > +
> > +#define pte_pbmt(pbmt) \
> > +    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? (pbmt) : 0UL)
> 
> Checking the ISA string alone isn't sufficient.
> 
> Svpbmt in HS-mode is gated by menvcfg.PBMTE. If M-mode firmware hasn't 
> set it, the hardware behaves as though Svpbmt were not implemented: bits 
> [62:61] become reserved again, and a non-zero encoding raises a page 
> fault (even though the DT ISA string advertises svpbmt). The same 
> applies to the G-stage mappings built by p2m_pte_from_mfn() below.
> 
> menvcfg isn't readable from S-mode, but the spec gives an indirect 
> probe: when menvcfg.PBMTE is 0, henvcfg.PBMTE is read-only zero. Xen 
> already relies on exactly this in vcpu_csr_init() (ENVCFG_PBMTE & 
> csr_masks.henvcfg). So it would be more robust to compute a single flag 
> in init_csr_masks():
yes right, thanks.
> pbmt_enabled = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) 
> && (csr_masks.henvcfg & ENVCFG_PBMTE);
> 
> and have pte_pbmt() test that instead. This makes the check reflect what 
> the hardware will actually honour rather than what the DT claims, and it 
> also collapses the condition in vcpu_csr_init() to a single test.
> 
>  > +
>  > +#define pte_pbmt(pbmt) \
>  > +    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? 
> (pbmt) : 0UL)
> 
> PAGE_HYPERVISOR_NOCACHE / PAGE_HYPERVISOR_WC are no longer constant 
> expressions, they are now evaluated at each use site. riscv_fill_hwcap() 
> runs fairly late in start_xen(), after setup_fixmap_mappings(), 
> early_fdt_map() and setup_mm(). All current ioremap() callers (aplic.c, 
> kernel.c) run after it, so the code is correct today, but this is an 
> implicit dependency: any ioremap introduced earlier in boot would 
> silently get PBMT=0 with no diagnostic. I don't know honestly speaking 
> if it is a real issue.
> 
> Worth either documenting this with a comment next to pte_pbmt(), or 
> adding an ASSERT() on the initialisation state. Switching to the 
> __ro_after_init flag suggested above makes the dependency explicit, 
> since the flag can be set alongside csr_masks, which is also populated 
> after riscv_fill_hwcap().

Agreed, but let's do both, not either/or.

The __ro_after_init flag helps, I agree, but it doesn't guard against calling too early and, so a premature call (e.g. ioremap() before init_csr_masks()) would still
silently read "unavailable" and PBMT=0, same as today.

So I'd keep the flag and add an ASSERT() where it's read, checking init has actually run, so premature use trips a debug build instead of silently
defaulting to PBMT=0.
> 
>  > +
>  > +#define pte_pbmt(pbmt) \
>  > +    (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? 
> (pbmt) : 0UL)
> 
> pte_pbmt(pbmt) reads like a PTE accessor, i.e. something with the 
> signature pte_pbmt(pte) -> enum pbmt_type, especially given that enum 
> pbmt_type is declared just below in the same header. What it actually 
> does is convert a requested PBMT encoding into the encoding that may 
> safely be written to a PTE on this hardware.
> 
> Something like PTE_PBMT() (matching the PTE_* naming of the values it 
> takes) or pbmt_encoding() would convey that better.
Ok I'll do that in v2.
> 
> ~ Oleksii
> 
> >   /*
> >    * PAGE_HYPERVISOR_NOCACHE is used for ioremap().
> >    *
> > @@ -61,8 +65,8 @@
> >    * is that IO is non-idempotent and strongly ordered, which makes it a good
> >    * candidate for mapping IOMEM.
> >    */
> > -#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | PTE_PBMT_IO)
> > -#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE)
> > +#define PAGE_HYPERVISOR_NOCACHE     (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_IO))
> > +#define PAGE_HYPERVISOR_WC          (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_NOCACHE))
> >   
> >   /*
> >    * The PTE format does not contain the following bits within itself;
> > diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c
> > index 11dc289f0f..f6e635ec1d 100644
> > --- a/xen/arch/riscv/p2m.c
> > +++ b/xen/arch/riscv/p2m.c
> > @@ -683,7 +683,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t,
> >           switch ( t )
> >           {
> >           case p2m_mmio_direct_io:
> > -            e.pte |= PTE_PBMT_IO;
> > +            e.pte |= pte_pbmt(PTE_PBMT_IO);
> >               break;
> >   
> >           default:
> 
> 
> 




From xen-devel-bounces@lists.xenproject.org Mon Aug 31 09:46:28 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 09:46:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403883.1637834 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0yau-0007lX-2r; Mon, 31 Aug 2026 09:46:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403883.1637834; Mon, 31 Aug 2026 09:46:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0yat-0007lQ-Vh; Mon, 31 Aug 2026 09:46:23 +0000
Received: by outflank-mailman (input) for mailman id 1403883;
 Mon, 31 Aug 2026 09:46:21 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1x0yar-0007lK-Ni
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 09:46:21 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0yaq-007oX6-0z
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 11:46:20 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a954d5b-2eae-0a2a0a5409dd-0a2a4505ae24-32
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:46:20 +0200
Received: from [52.101.46.11]
 (helo=CO1PR03CU002.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a954d6a-4cb1-0a2a45050019-34652e0be16b-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:46:19 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CO1PR03MB5842.namprd03.prod.outlook.com (2603:10b6:303:91::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Mon, 31 Aug
 2026 09:46:16 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Mon, 31 Aug 2026
 09:46:00 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ut1Ga3Ljy7g4HimLluYOjnLG2XXXUrwKCrnFvuxBU6UGlBt+GgmrcvX3ZpgR/hPXN8YGT+RRTfRHB9DTyIGvOzCxFJh21QORexzr3bBYosF3GpCEi8sbedpgSLKK8qIKvULlhzPOSVORWA3kb+UP0iB29hULm9LkZPmfMCycVTaPpU2YO7NtoM4H2yrimZaaO7eUkfCYFXVBKdj/WbzQbbgiZ1mCerC4RnGaDIneSHFxoN9TR72v8cKbUDkfL36+dPbPAJGVWzh0RT+JcluAFncdo/8H+hRtXmgJx/DritbmiSNoRPELRNarkTX7rpqdgNUNCpjjkwWinXKseoZYkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xXh059E/wOuwuhAEW/KDaqB2oroQ8+rBHNykMN/ovBw=;
 b=g2no6gy8NdAoPUUMkPXP/huJQidf1rGb2QQMcRo6OylbOIVSzX5AJKVW2hwTQjwoN8cc/VNX6oSSbbsJWNFB+fCkFQUtjkPEEFSfEMO6cNHi0iMsHZCNZFjvQhAjH0s5ATDCQwgMjwTy59wf1JF++8IvAFdJLKbH4quR3VGnkCoP4/ZhHZN7Kr3s5azWWvqtgHUSj5AR2W8lPoV7F7BbzzZJBBWEjJgb3g2q13hsildF/JsDN8XLLUjGGsfDTreWZG1fFGgRfg9HPC3yuf0o66FbiEjrhnNFXehixbLY6CcWLfI8jWpH2lgmsJ2RCMcxawyDkkqegIWHgIM3xSB31g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xXh059E/wOuwuhAEW/KDaqB2oroQ8+rBHNykMN/ovBw=;
 b=fIB9l2Mb/dtPFrwWMHUVdAfmA+l3OcdLWQj9/zwKD1cxhF1n5MNie3pJMhchtc/ZGOXC5jU06CcyF5x/mRWq7dLNhKk1CFSx3A3pc6xIpK7uIslRkBxEzPFqyNDpDVYKyb/sFtotl4KR7ESFGArI90ORqPfGWLIMjVzvo5hDI3g=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <cb7418ef-4d3e-4a86-9c86-f7b0f296c013@citrix.com>
Date: Mon, 31 Aug 2026 10:45:56 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, jgross@suse.com,
 jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org,
 roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org,
 bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech
Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus
 in sync
To: Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-2-frn1furkan10@gmail.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20260831051637.5029-2-frn1furkan10@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0525.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:2c5::8) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5842:EE_
X-MS-Office365-Filtering-Correlation-Id: 4bad9f60-d6fe-4999-3e5a-08df0744aa54
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|7416014|4143699003|10067099003|11063799006|22082099003|18002099003|56012099006;
X-Microsoft-Antispam-Message-Info:
	CgFORFYpPu7281w5Sp/idNNCjOJkmI6TpwVXvfiYUP5/v6J2gjex3A3EYgxVj7swBkQ5IuwtSaiwUPH863UqkqXw7qCSZcnCYogsfWj0mMhP1P0Viyc0BQh4pnpfGnVdm+yPzPFPDILL+OqHIHBfX7MHYrYz8h0xdQu0pvcbrVPpnda7YDkEPRpUeBhJM0XZpg1Ti/NEMKnP6QXadVC7x/2KptXDcfcvWnn2bbYnc+SwmZUHcbybqv7PppsC/Ik66jWAiEoXUzQxBq0ySqrcD4jUvCsa0Jn5bXxBBjI/iG/o/C6+jr709k23oFVx+XSMrabDGV+rbLngAYq4UPlrnNkmR5EcqRSanYdmnXRpDN7Y36qIXMAr4JaY05m/Y80fMS2n/PFvin/gqxH+dTFE4RAUQkbMDVVZ3+o1nAM9+gC+uGeq6xd0mcCXBXHBZefvpX8T30ZujZPoggxsYaHVA62Ys/VU96yinM+O4wXCe65m0ZozU7KfDChSNBmaMpXRMh86ZJOpHRjI1ckNmCV3MYA7EPpMFq4Dv1ehqD3bHdGRAnhhi2DPg32g/TrJbag5cEKdHa6OMdrJok2TbO3c/MEdIXPbIv0Tb/4ueWhrgu+U4Fwqt/5pr/ud3RtBR3I3dyUQfFciXg01Fj//Wy0l4QUzPbASenUufFVJsMC0voA=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(7416014)(4143699003)(10067099003)(11063799006)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VVA1d0hqcUE5WHJ6QWhFeW5uSzdNQVRPZ2NDWlg4WnY0OENDM1FwM0t2cFdK?=
 =?utf-8?B?T3FBZ1FFWkRsaGc2VDJKaHdUNjhwaVVGdVBtNG5ISW5LaUlHamExWVMyMi9H?=
 =?utf-8?B?bmdjVVZTMnk4WkVmQmxVQ3hNcWZTV0hYVjl4UDIxdVVDeVFadHlBSHUzNnpO?=
 =?utf-8?B?QXArTDh1K3FIVElLK1NESy83SVZmVDBnYmEycjRGSGFwaXBzbXVuenZsSjFV?=
 =?utf-8?B?Z2RsMlovRFBZT005MGZ0ZEtxZVRtbGpFLzU1VmpGYmVoS3ljVE4vTCtranJO?=
 =?utf-8?B?d3Z0VndrdDRYNUlnRWQxd1NYbmRyZEt6VHJINDRVZXBseDVBKzFGc2dUMy9v?=
 =?utf-8?B?ajVDWTJNRnZlNExQakNDNmpvSHVTOTh0QnpTeE9INFRON0Z1L0hoTnFmaDJv?=
 =?utf-8?B?TW1rU1JCbmdMYU43WFZiOTBNOUxEcU5CRW5LRG1lbzdhek95VDhFQUo2V3Vi?=
 =?utf-8?B?czduU0FldG9lYTJXQll4MEh0VDMwVU1iRFVoSTRGSkRUam1SN2owd1NRaEhw?=
 =?utf-8?B?NHlCNmMvNU0xWDNCd1BheFVreUJ3ZFptMHpyc08zNWsxc041WlAzelc3TFJ6?=
 =?utf-8?B?UFBmeVM2aXkzM0tMS2Vqb0Q0ajhScjVWZHA2MkZUbWRDYVljNEtjaDJWSWwv?=
 =?utf-8?B?eFpSUUhNcXUrZ1BpbWs2ZWhUdUZvYXREZldFSm5oS2JYWWJCZFMxTE55YUtC?=
 =?utf-8?B?WVZibDczM1REbmZNZmxrNVg5cm43VW1raHBkU0t1aVkvNXVKdWg2QlN2R1p3?=
 =?utf-8?B?NTNlOVU5ZklNcXZFV3B1YW1RMFVQNFdlQnpIME8wM2RHbEp6VVRUaVljeDRX?=
 =?utf-8?B?S1dTK1JQbjdxR2o4aVJhWmN6NCtTdTBHWENNK3Z4ZXJLVW5WUWRzbFluMXpG?=
 =?utf-8?B?eFhjMFpUbFU0dkdQU09Vb0l2OEhuUHBuS3pFWEkxcjZyQmZ3WjJxd205TDcr?=
 =?utf-8?B?RlIzZ0p5RGw5cEtLanhGWTNYcnpPTWZvZEZFaXBHWDZTNFMzS3NIMGQwWmhV?=
 =?utf-8?B?eWExU0tOa21wTmZjeVBqTzZLRHorWDluNHB3bE9lenRZL3lUQzgwZUlvRURn?=
 =?utf-8?B?MGt5cWxvemxXVXg0VXgwSkEzK1hTdHZzYXljelpnRTlWaE81N1dEM3VCTVVQ?=
 =?utf-8?B?RjFqRGNDV3ZOQ2pqU0RZRzkrVXoyZHRKWDZ2NkdvaWkwSkxKNEw5d09nR3hS?=
 =?utf-8?B?dlo1cWVSV2VOWGlsbU1PWWFHRGpNVlZkb3dZWXJEeFRiMFlLNm03RmRGUXlt?=
 =?utf-8?B?TkJ6UUpTTzh3WUw4N2lSYW1tRk5qMys5M1FHZEh3RTFMVytkckRuc0dxYUI0?=
 =?utf-8?B?QU5GU3hEbFozR3RQUlhqcnJzd3ovRmdkM0pzbzNUNHhSc3YvblA4U0dIT0U2?=
 =?utf-8?B?eUFxd0dHRmd2ZC80NkVvSFBBMEYxbUl5NVhsQVJFdTJKSktIbEQ4SEJvbWc1?=
 =?utf-8?B?RDczaTVNTmZDWFBHN09zRkxZajdJaG5LR1V4dVA0S0dxTUJqQmxUcC84ZWJ5?=
 =?utf-8?B?cy9EZzYxUy9VRFFHdG11Q1V2ZUMzMVpFNThscmVQRVhZR0hJdGJuTGNkMDFI?=
 =?utf-8?B?a3dROElMTlNEb1N6WVFjZGlRRzEyT1dYM2Uva2dPanBQWkphR1hoUzFRekNM?=
 =?utf-8?B?M0k1TUtmRm1hSC9ObkwzM2dQVVRzUHFQMjN0VERFU004Q1pjV0dCS1VVc1Js?=
 =?utf-8?B?NTlqVTgxdU9za0I1dnY0dHRsNE5VcWFMWkRpMDVTamtDbEN3Q2c1bmp3dGNC?=
 =?utf-8?B?WHdUNFRmL1RLMDBlTVJYayszb3ZlcVNWcWZVeTYzSW1JVXlvVWZoSGZueUZ6?=
 =?utf-8?B?L2NJdjVxeC8rMVl2enAwdzR5ZGVqNlNsU0JWRnZnbGVzeUdacmJzS3FvTTF6?=
 =?utf-8?B?c2ZTWG8vcWZJQVUxQzZ6ZWhFV2l2L0VjMllrd0hURGFmMVlkYVpSYWNFUGhr?=
 =?utf-8?B?ZVlYR0djby9LUVJwNWZQQTU5VUpzdm9tckNDV0JQZ0EwNldhNFhldmJsRHg1?=
 =?utf-8?B?WjErdGhaSVBOdzJxdjJabVljWTBGUXQwcnVRUGQrT3EvWkhxZ1JaWXVtZEdq?=
 =?utf-8?B?Q0dDZUErWnhDZ1lQNkNlU0ErVFJIRzE0NzlHTU5hSVdZaU5HakJhUmhjakhv?=
 =?utf-8?B?alhIeEpwckxiVFVTTUJVVG1tS0VvclRBV0JFMi95eTQvZzhhdjVQdGJuOGZx?=
 =?utf-8?B?UlJqMDhhbm5xSDVvWG5uVEtjMFZMUlFrdElacE5NaFJLS251dmV0YkdOYUV4?=
 =?utf-8?B?VDJ4VUp3V3RQc01BWnVJaEFkcTUwTlJIQlVLQzVkcFVoUDAyY2kzRWp0MHVz?=
 =?utf-8?B?YjhLRnJWbUdLblZvZGhVNmhpbjdiQVQ2dks4ZW1NWTNEejkwUGtDZz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bad9f60-d6fe-4999-3e5a-08df0744aa54
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 09:46:00.7575
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: YRszXbmMFqJU1Nuxh7Vjw5ZZ2JIUgnHn0rujQCBU/fOBztqLxAQQa+sjCUrxiPvQpZmnN2ve7E2V1duLDpQrZcGHTyy0Jp03XfnrqruX1vI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5842
X-purgate-ID: tlsNG-c201ff/1788169579-73EB92A1-38D5513B/0/0
X-purgate-type: clean
X-purgate-size: 2114

On 31/08/2026 6:16 am, Furkan Caliskan wrote:
> Every vcpu_create() call site that builds more than one vcpu loops
> over ids up to d->max_vcpus and stops on the first failure, but none
> of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL
> for ids below max_vcpus

As I told you before, you must cope with this property in non-error
scenarios.

> , which anything walking d->vcpu[] can then
> dereference. This is what caused the crash: sched_move_domain()
> walks every vcpu slot up to max_vcpus without checking for empty
> ones, so when a domain built in a non-default cpupool had vcpu
> creation fail partway through, domain_kill() later moving it back
> to the default cpupool handed one of its empty slots straight to
> the new cpupool's scheduler, causing a NULL-pointer dereference
> inside sched_alloc_udata().
>
> Add vcpus_create(d): creates every vcpu of d up to max_vcpus and
> rolls max_vcpus back to the failed id on error. This keeps
> d->vcpu[i] is non-NULL for all i < d->max_vcpus

No, it really doesn't.

> , instead of guarding
> every reader of d->vcpu[] agains holes individually.
>
> Convert every site that builds vcpus in a loop to call this function
> instead.
>
> Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()")
> Suggested-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>

For the avoidance of a long drawn-out argument, nack.  Under no
circumstances are you editing d->max_cpus after it's put into the domain
list.

You've chosen to do so at a point where the domain object is live,
visible in the system and able to be the target of other hypercalls.

Furthermore you have not fixed what your commit message claims. 
d->vcpu[...] is still NULL for an arbitrary period of time, including
being able to be the target of hypercalls, before vCPUs are created.

All code MUST be able to cope with d->vcpu[...] being NULL.  It's how
the object lifecycles must work, because creating vCPUs is not atomic
with respect to creating domains.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 09:56:46 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 09:56:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403892.1637842 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0ykp-00016s-Tp; Mon, 31 Aug 2026 09:56:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403892.1637842; Mon, 31 Aug 2026 09:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0ykp-00016l-RD; Mon, 31 Aug 2026 09:56:39 +0000
Received: by outflank-mailman (input) for mailman id 1403892;
 Mon, 31 Aug 2026 09:56:38 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x0yko-00016f-Kw
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 09:56:38 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0ykn-00D95L-MH
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 11:56:37 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a954fc0-8faa-0a2a0a5109dd-0a2a4509b7bc-48
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:56:37 +0200
Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a954fd5-be1a-0a2a45090019-d155dd32f03e-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 11:56:37 +0200
Received: by mail-wr1-f50.google.com with SMTP id
 ffacd0b85a97d-482fc2b44a7so2725194f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 02:56:37 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-482fbab3f16sm24073137f8f.1.2026.08.31.02.56.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 02:56:35 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1788170197; x=1788774997; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=5ELtqgP7ZNftqP2ekav0bCa49aPYTtF6QVeOSuARgtg=;
        b=nIzF47K/XqmHa6yUTHYwjuyepG3akQ/bLj/aN8Wl7i36GzvJQirk9GCwIYOqg9OvDJ
         +TQOLRhQpzLL/AVDqb/4rwK0IXoPN2+cZqzS9ye98fY9aGdcR5GtmGXakr2jp2JnRcaa
         8jempBJCYZE6slXB0gZ9SVaZC02SXjtx8HqIY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788170197; x=1788774997;
        h=content-transfer-encoding:mime-version: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=5ELtqgP7ZNftqP2ekav0bCa49aPYTtF6QVeOSuARgtg=;
        b=jaw5fEdpPyuwVma8bP9FyEg06vZpju8EY6Oc6DojGeFnvmsTFRPO300AF5CvSQQ/aI
         u6GuGC7kCpd9Y7eLS5j1MSdkyN8jKzfEOMIgEqEQf3os/QGy8QLN9x0tZpka08zYNrp6
         mtK1QAnoto73e0/HcUiTdKlN+YHGkt7GgzLcMLSOEUSraIyMzsxlqC7+MhKCjV1PKI6f
         scpE9z9j3r3svbssZF85R0cu+oSpYKuBZfLFmqfzDHZpd8yWExGfbGWlblJQJl0ibcbg
         UUpIVk/IzYS3Bt4uzwOdNf3QpfVL7QzP/DwKimimTwMbqu5eEyksaPla+lvZ4ngVoA9u
         ehKw==
X-Gm-Message-State: AFuF++lHTvQ5Pei83CbAta1wn7YU5cuWRAbjyjMSAD3tm695uABcwbya
	FJMEPfK2IJiDk2MlEFlXvMvU67Q6KHv22k5etLPjoLsE3FZk6eSAa8OVhn2zSuZ3BPsw0a2a7cq
	f5cs9
X-Gm-Gg: AYBFou3DXFA8rXV0zxux76vU6wdtTKNm/XfPwUnx/CFcYrwcoIWkMECOop2dVjrDPIq
	gflsdBo0/jAPEkgTy04lBnjEP8YMW3lkMY26EaAVF9WzATZFmAoSqOtiPhMSIp1mh5hv+KA9uh4
	3p/65d5h4OU9+t+e7cnqvYmG0z2/Lj+WJ7xQvpeDdQVlun11SKHVjjpSL/s8wsqzklSAvLVAajW
	w5mRNaqP/cceN3C+DFakL7mWw0diJiC8d2QqWh/NvEkiOAUFCOAoeTF4USQ3B/yJhqwms3AJiYX
	YSwcNJvoFfxxTMf3Rev1Liy9gAoMuMqhuzThxhePe8mm1gUmZpx7J7Mv7ehwHdnAyJkFFegZu9C
	mjHk6i8N1rE7V0VXTsIXxXW1alAAmzavP5lp148gRb8Pl6EAxlFDvV6mBOoJWpft/mEOVS5Pb+T
	nv0mWVSPnLjHMx+6gkYIjKMvtKnZy13KsQfiyTkFXh70q/rn4r3jGs/CSgTn7jMjddMEd8LPpHM
	jAFpguS0LT0OICx46u60JypJevJW58Bri8fRL4=
X-Received: by 2002:a05:6000:25f2:b0:484:3fcf:2f9a with SMTP id ffacd0b85a97d-4843fcf2fb3mr1314504f8f.9.1788170196499;
        Mon, 31 Aug 2026 02:56:36 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: [PATCH] xen/arm: Don't pad between function with x86 nops
Date: Mon, 31 Aug 2026 10:56:33 +0100
Message-Id: <20260831095633.2834187-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1788170197-BE4DB034-09C6C2C9/0/0
X-purgate-type: clean
X-purgate-size: 1146

This was copy&paste from x86.  It causes the padding between functions to be:

  a000026dd64:   90909090        adrp    x16, 9ff2147d000 <start-0xded83000>

rather than:

  a000026dd64:   00000000        udf     #0

No functional change.

Fixes: 5da0d3123c0a ("arm: entry.S and head.S")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>

Has no-one looked at disassembly and wondered why there are junk instructions
between functions?
---
 xen/arch/arm/xen.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2d5f1c516d03..d4d959403307 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -47,7 +47,7 @@ SECTIONS
 
        *(.gnu.warning)
        _etext = .;             /* End of text section */
-  } :text = 0x9090
+  } :text
 
   . = ALIGN(PAGE_SIZE);
   .rodata : {
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 10:01:10 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 10:01:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403904.1637852 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0ypB-0002yn-HZ; Mon, 31 Aug 2026 10:01:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403904.1637852; Mon, 31 Aug 2026 10:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0ypB-0002yg-Ej; Mon, 31 Aug 2026 10:01:09 +0000
Received: by outflank-mailman (input) for mailman id 1403904;
 Mon, 31 Aug 2026 10:01:08 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Sergiy_Kibrik@epam.com>) id 1x0ypA-0002ya-7T
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 10:01:08 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0yp9-004MMi-Jb
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:01:07 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a9550da-e002-0a2a0a5209dd-0a2a4505bbe6-32
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 12:01:07 +0200
Received: from [52.101.72.128]
 (helo=AM0PR02CU008.outbound.protection.outlook.com)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Sergiy_Kibrik@epam.com>)
 id 6a9550e3-4cb1-0a2a45050019-346548808b6d-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 12:01:07 +0200
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AS8PR03MB7173.eurprd03.prod.outlook.com (2603:10a6:20b:2e4::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.9; Mon, 31 Aug
 2026 10:01:05 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0360.008; Mon, 31 Aug 2026
 10:01:04 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zRIW9v0BqbGlLqUv2YVvyH5Rknrmwk90Aurhm5Y8QvZdrssTYH2wdhHZGa1OyRgsmeS0UgzAmVV+EmRC3VboG3O+IGsSedUFudlcxR/Pl8VFmHwdA7wstVcD2WbOKZa19OBF6wxIWZ32qlcwRYRNltYmYoID3DRV39w3AuvZbFWiSoG4t6vRt5o9T8ZIX2yPsXfLNT/bKpDIZefEUxQXDOQK5zLyaTS3ecLaeTaevhJjRDvbEsDtNt8Ty22SJJzavg50NDVEoYl2dS5QTmfrcySAJ+h53IjwLUY1F0N36di1U8p2xnzQ7CGhPSBkAMg8Bliv10ASuG2p+j5yKp/N+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=HykNjhIBYfJ6PHoZUXrRkvO9KXiMlB3MOWM3eIiVK3g=;
 b=h5efXjVAgEEry9NYyNBPOmjrz95O1Dl1xJVMVDsdq9aGpBZMB7nWXPKYbqYr79dBS9l0So+0yHjL5w+TJeJLLlA4V6bJdfiHRj1u9M4Z4qZWn2hyW9XqYKFvv/EiroNN0eEbzN+clN/XPf0Xccu8C2/9CNQ/tV6FHZRnhM7zKXMJXjSJ31khC/MooAhwVE+TQ1qG4FKKcHyh5WKgoZOJZgjVAk9wEIE6nxj/aWCS2x3mfk/E9Pw5HcevGbWYlQUJDHrH26U3+Vz7ArWaVVQy/wEu/yCcoCgpwWYxpnOz/AB3dU/gJJc0kkDGDi/mjs57sxX4DV0CVeCucVC5e2CaqA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com;
 dkim=pass header.d=epam.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=HykNjhIBYfJ6PHoZUXrRkvO9KXiMlB3MOWM3eIiVK3g=;
 b=DqogpB9go3kvtoziAG2ODZyS8xTmzE/K84TNs1fGFYXCeFrSWktJz469sOLx0g4omaVDM0pCNIZhmLPPCA6ONjRB2EGsMS3uGTRCCtlDoleKimBhCvt2KQJvOz8BRnrBpLA0EeMgJXqFoeaayDzMhbpcCxA7PUZiJzepmeG/pa2BKHIDzlXHjh9hxMRYkmjt3TRCt6gtEEbp7H059nSRBY3c/WE4TwI6ketyN7iMHLN0SKzFkcCX4KKiKHgYz/6/V/Rn5eS49vDLlWtc9G2/h8kjT7MYsX4Wuccn+uRd9SXE5LvC6OfvLU/qMM38URFQku85fzXS57emj2gZTsz9nw==
From: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
To: Jan Beulich <jbeulich@suse.com>
CC: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "Daniel
 P. Smith" <dpsmith@apertussolutions.com>
Subject: Re: [PATCH v1 1/2] flask: add const qualifier to
 security_context_to_sid()
Thread-Topic: [PATCH v1 1/2] flask: add const qualifier to
 security_context_to_sid()
Thread-Index: AQHdNgfAVxs877kedUqP8J7OTWLOvLazBE2AgATu5oA=
Date: Mon, 31 Aug 2026 10:01:04 +0000
Message-ID: <5564a32f-31fa-4629-beb4-d87d19c2944d@epam.com>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
 <ee0ce49467ac1ee1cdd017323e70c8a865269f39.1787821757.git.Sergiy_Kibrik@epam.com>
 <1b680cd1-c086-4aa1-9a8c-f89d9743918e@suse.com>
In-Reply-To: <1b680cd1-c086-4aa1-9a8c-f89d9743918e@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|AS8PR03MB7173:EE_
x-ms-office365-filtering-correlation-id: 6c04c730-0610-427d-d30f-08df0746c520
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|38070700021|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003;
x-microsoft-antispam-message-info:
 GFPp1DAAjU0WSm9sY/Sn9rkQkj0J1joOhIeJrzyiS5RNG43I5fKFBXJGVPIDXTD4tdx9LTU4QkN9H5/lKIimgFKNMs9jarO4coG23BXgMVpoRT/jOX8jQeihwyB28mdjgW64fiuMRzlfIYpxSU1LqKJJRuJZeJB+8zDJPB6RGSEG/bN9gn5WCy0QeZNlKxc4UWvHXQKjz9IykXeL/IVrnGX6c5pm80KViswcxG68mxL4CdlzSR8bpLKE+BfpLxK6fkXtuUGEFA3x5x2xgrZznD6SDTqIBgHBgynzEvkcg7s4+ZeSoHns3hr9yhKp/Xy2cT6gQjiwkS9fWlEZ3Et75cjJ/l8+OGwTDuSPXo2q3OKZxUg4Q8ZC6fRctt5wNNiLYCXz78PKV3fNoP0eoG+VmK8fFD0+hgDeK1og0KoyofpjtW/UELDpat1zuzaF/Vdgnxytm6/seCHRjdMzc32R/QsqDdDHywBEASZAl/eweohe6cK3nvwTLMSvU5gmYfqKKnxZIt0gMTirginZjunk4VzKZtVHoy3mwjo78GuSxrf/GrePLC4fiHxPnOosxls8MsiTTKZ6psfdWP87UIpjSPizxoLzf1s7AWEan13rrWTUuXTwV4QMs88frN4EvXv+HWbGn0hs/RQwfq695XZvfNM8vmm7gjE/i0xWjaB/vXPlLtBEdunKBJ1rb133NYBcb3gv6YDpmQ2R9meHmpg2RVAJ6DkpsvrAAV6uH8wI+Ak=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(38070700021)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?blVKZU4xbG93OCtpaUd6Z2RjK3ZTWXBXU0Npd3dsS2RQdGpNblIxQXRIcEMx?=
 =?utf-8?B?RGpiVTJxdmR4eWFrS3o5VUtyTktoWXVTVlJJSjIrMHBWVEZkcnJIa01aTHJX?=
 =?utf-8?B?LzZGZkpqbTJSOEZ0M2FyVytYVzZsbkNIUmtyUXQ4WWhIYkErb3BnSTQyVitv?=
 =?utf-8?B?R3piYUVpYWU2dExCS09rcmNYMEN2SEt6Ylg0bWw5dEgvZ2p1bzRiaGdTTndk?=
 =?utf-8?B?d2IyNVEzOXc2Q1J6alpoS0RHVm9nVkdjOEZwS1AzdHVDVE8wMnhpQXZud3Qr?=
 =?utf-8?B?aHR4aW5KbUdZZmhlS1hIWlJ5VWp5UmUzemllZU5MRDMwdWJvZWZUMGxDbjlm?=
 =?utf-8?B?Z2oycFc4SzVOakFDSmdHamlreTRJYjFrbHBxYllKLzIrSDI2VjVsNHl1T2R3?=
 =?utf-8?B?cU01c0ZmK3VVeHZpZU9LWWU1RTk0Y3RjS1FrN3NjcklnRGREZ3BnbDk3ck9i?=
 =?utf-8?B?SlZFNlRSbXNpNnpJcDVYWmVjaTR0dWxJZ1pvNmx5SXkvTjlFdjFDZkR3QVc4?=
 =?utf-8?B?T3hDNGdCYXJOTXlJOTU1bXlpNmpNb0ZRTTRlaGE2dGlyRHRlcks2eXN2NjZw?=
 =?utf-8?B?MWpialJCekpiWC9LOUhsTU5paURobUxIQUpHZkE5eVR0Vkt5ektkanA2WWE4?=
 =?utf-8?B?RHFyWldzdVZDdWQ4OFBjU1RheXN3TThsSSthQnRnc0kwMnk3NjA2RlZRMHFW?=
 =?utf-8?B?bVhYNWN6M0VnMzNOQVZZZWthVXgzaDFETC8zU3I5bEUvQytoY3ozT083MW80?=
 =?utf-8?B?VVM3Y2pUbXNPQnFDZkViMWtxY2oxZkNzMGhSNkNNQjZsN0R5clIrclJrK2po?=
 =?utf-8?B?V2o1WExveE1uUzZ0Z1Z2eDV3MXR1MmVWbncrejNwV0dodjhNa280SGZ1WDB6?=
 =?utf-8?B?SEhncnJZZTYzMW1pTXlIT1pyWEhzUktnSTlXaWpoWmdmdUdoMGVwekdoU3FR?=
 =?utf-8?B?TWJwUjdCQlhiU3BLOTlYU2ZzMTk5STJFN2dZVVB0M0dleGNQNDdSZEN6RGZy?=
 =?utf-8?B?S1BsM3NmcHRTL2JDM09oa3l1Rk4xMGNIb2pRRjl4bFA4QTVqV1dxOGV2b0Qv?=
 =?utf-8?B?ZEtFSE5vbXZab0NMUTZTUUM4N0pxMTlIcDk0UkV3djhqWWZzNEJHRVdXaTZG?=
 =?utf-8?B?VmlIazZwdDQ3M05tYit5QnlzVTA3M0VJekRGQVNMTGFacE1wTDlBTXlTYXVz?=
 =?utf-8?B?RFA4YVpnczRrR1BWcUFHWmgwSEZ2QUwvSHZRL0xCTkM4YmhaSTFURFp1eU1J?=
 =?utf-8?B?RVNST0YvbkFkbUowMjI5QThZcGFUQ0xFNmMwcHNYOHppdS9ybnY1emF6c1pt?=
 =?utf-8?B?ZStWdkN3UTVCSVJjVXVZcTFkOUR2SWNYU2tWUXdUOXZudTJ0S0xTb0tnVFRN?=
 =?utf-8?B?OWsySFRnWVM3eEZIRjZyTXJtRjhlSFFOVzJuRFJTVXNLVTlZUU5MUHNXOG1z?=
 =?utf-8?B?OUJ6c21KRVFQSG9MME9jS0I4c1hVQnlhSjR6RW1lRWt6UVlNSk91VVBrNnpk?=
 =?utf-8?B?MXBYTXdNcFFoUlptaEhDc1R1UWh2ZlQvVnRnSGNCNm83WWtUQndTckg1NGJ3?=
 =?utf-8?B?SkhIbFhBQ3djVFVPZHlvR25CZUNmeXpLMWMxZVpkNnhPZmY2K0UvT243RGN2?=
 =?utf-8?B?RWlldkF0Q1l1VkNQcU9JS1M3bmY3MnJmYVBONDhHMVdPOEN0MmZtVVBJa3Y2?=
 =?utf-8?B?cS94MWFKYlN3NW1xUStmQXdrUVh6MXAwbWVyWVV5Wmw5NFhkWU9TdTl3R0NF?=
 =?utf-8?B?SEpHUEM4WnlFbzJUU1ZVcTRnd0V5RGkrYW1JWEN2cTJaUytoVjV4RFJyeTlx?=
 =?utf-8?B?VDUwVExvRUJxYUdlNjlSQVdmUTBHeithZWtrYmJEbzlxYWhrVjBXTlhEajB6?=
 =?utf-8?B?OWRkVmJoM2xzR1pUSjc2KzEyMUpCcS9nMEc0cUhLaTRjamVncktJTC9aVmNs?=
 =?utf-8?B?alNEMFhMRUlqU2JqWWJJbHEyeSttWXM5ZnUzWUZTVjMxaFVtL3AvUTZXNHlh?=
 =?utf-8?B?TVpoYjZGYU0wRUp4RnBKd0QxUXRPVEcvOU1sMEVmak9SVzZ5WmdNUzNTaHdr?=
 =?utf-8?B?a0lKSGVJYkZFeEtmS1pxRnRwV2tsKzNiMStlMDFqcFpIUWtwZFdESnNXSW5K?=
 =?utf-8?B?WjV2SmRxOFAxUzRoT1VBcXNYV25UWm01WWJ1bTg5KzdwbGxvd3NRcmJUa0ty?=
 =?utf-8?B?ZFJpa2x3ZFJUdmJ4Q01lazB1Y0pZbHJsUTk5d0NuYTc0d1dYd2ZNZkIrQkJ2?=
 =?utf-8?B?eitvUW1odWZ5TFQ2L0hiS04zU0hkMDQ1Z2k3QmkyVnJJdEtVWmlicG91bFFB?=
 =?utf-8?B?SlF4L1F5U1N0WmhYdlRnU29TOEFMeWhyems3eDNvZU9odDkrdUJGeWhTbkcw?=
 =?utf-8?Q?4/0WS2kXbqtUqELY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <34E82F80C1155948877E64734AF4DA29@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c04c730-0610-427d-d30f-08df0746c520
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2026 10:01:04.6008
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: y0QEMYE8CheQ44MpkJY+Oq2JA1Lgt54aTBE40EjsgM0gYz7W3Z7jaXUbFP6cexHkjgXfgOBdTuakzFaYPAPy/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7173
X-purgate-ID: tlsNG-c201ff/1788170467-F72B32A1-A3140AB9/0/0
X-purgate-type: clean
X-purgate-size: 502

T24gOC8yOC8yNiAwOTo0MCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IC0gV2hpbGUgdG91Y2hpbmcg
Y29kZSBhbnl3YXksIGl0IHdvdWxkIGJlIG5pY2UgaWYgdTxOPiB3YXMgY29udmVydGVkIHRvDQo+
ICAgIHVpbnQ8Tj5fdCAob3IgZWxzZSB3ZSdsbCBuZXZlciBjb21wbGV0ZSB0aGF0IGNvbnZlcnNp
b24pLg0KPiBJIHRoaW5rIEknbGwgdGFrZSB0aGUgbGliZXJ0eSBvZiBhZGRyZXNzaW5nIGFsbCBv
ZiB0aGVzZSB3aGlsZSBjb21taXR0aW5nLg0KDQp0aGFuayB5b3UsIEphbi4gQlRXLCB3aGF0J3Mg
dXAgd2l0aCB1PE4+PyBBcmUgdGhleSBleHBlY3RlZCB0byBiZSANCmRyb3BwZWQvY29udmVydGVk
IGluIFhlbj8NCg0KICAgLVNlcmdpeQ==


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 10:19:33 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 10:19:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403913.1637861 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0z6q-0005Ra-Vf; Mon, 31 Aug 2026 10:19:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403913.1637861; Mon, 31 Aug 2026 10:19:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x0z6q-0005RT-SM; Mon, 31 Aug 2026 10:19:24 +0000
Received: by outflank-mailman (input) for mailman id 1403913;
 Mon, 31 Aug 2026 10:19:23 +0000
Received: from mx.expurgate.net ([194.145.224.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1x0z6p-0005RN-B2
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 10:19:23 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x0z6o-00EWQ2-7O
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:22 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a955515-2eae-0a2a0a5409dd-0a2a450cdb48-26
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 12:19:14 +0200
Received: from [40.93.198.8]
 (helo=CY7PR03CU001.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a955520-f479-0a2a450c0019-285dc6087598-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 12:19:13 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by DS7PR03MB5527.namprd03.prod.outlook.com (2603:10b6:5:2cd::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Mon, 31 Aug
 2026 10:19:10 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Mon, 31 Aug 2026
 10:19:10 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q9merhmBY9PAuC0D3ms8IyjCRlF/JYBBeaJrfSSxOBV1u2o2Q7sFHIV0eaznSikylxal8C3hbET2jdMQ1TIAXd4qSm7ge3fICu+/xHK0zNQ64Fllx/sD0a2Y8RJoja1xajCKj0jxvmxqXwowu2K2mxC4G7QPdw9fDoGKI37X5ceQHmasI2hMtq3Ct+PRRrdHQHIVaFKUC42ZMUGJplrmIZfCxJgEjvYvAsN1WhFHq+F8z6LRSnQMYf4/bn7SH2z245nsIfanvIhv2xWN04cS5bpiG8q0cS+TzzGt5WCJHordytVq9ca2ZotembdFJ7wwKMMFXJMb7gS+wDvG+Hrduw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=N8Ypo8Pij5uMv8SuVvXLIhAv+uICPjOUVBIl87hxIp8=;
 b=jL+/WH6+MrN/PI/4CjocbBBDnKEObC79PE9jIdOf8LFXLnLRDySI/Dq0mJ/9UGrdcq048dyzSPLcX636nfkvM02QBdlluKd5Q0tSBoMdj76r5+2FHVKXgVHMk3ssM+arYD6qZKXfICO9xzzJLXMFyqTicJC1wp768X/SJzv0Nc2VPCfBnxPe2XkbWOyDrImXO5SoHPDnp94dM6e27sX3u+XQ2tKuMaSft/EMPCnrEoVMYhwrhPdqd4EtWNjn4X8d4G10KCbm+5bnKNBRCI/AYeeplHvPEfx8GqK44OWjChRIBSBzuBoS1Dmq0tas14Wb1FpMxOx29MQXJtMp0vdNBA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=N8Ypo8Pij5uMv8SuVvXLIhAv+uICPjOUVBIl87hxIp8=;
 b=pjEYVVeH6+H9Izb4p6I8syxtE0P6VgSxkIwg5aTMXXH0NvoH0/P9NevQS5R/9WMYsy6PlvSGYxxzyzQPbozSeiXVyv/81f5taUXHSWWzv/PImlKT86IXqqlw9OErSSG/5GJk5YmP7lCcxqwDzLD0qEJBD08Bi0+KpoA+10hQ/aw=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <d98bff6b-c32c-4c52-bbc9-cf88e4be6c3f@citrix.com>
Date: Mon, 31 Aug 2026 11:19:05 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Stefano Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>,
 Bertrand Marquis <bertrand.marquis@arm.com>,
 Michal Orzel <michal.orzel@amd.com>,
 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
 "Daniel P. Smith" <dpsmith@apertussolutions.com>
Subject: Re: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels
To: Sergiy Kibrik <Sergiy_Kibrik@epam.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <cover.1787821757.git.Sergiy_Kibrik@epam.com>
 <e97ab666be0d667dc823c3d881ac9ed76267a7a5.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <e97ab666be0d667dc823c3d881ac9ed76267a7a5.1787821757.git.Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0604.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:314::13) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5527:EE_
X-MS-Office365-Filtering-Correlation-Id: 357b064f-27bc-41b9-31ce-08df07494c1d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|4143699003|10067099003|56012099006|11063799006|22082099003|18002099003;
X-Microsoft-Antispam-Message-Info:
	+zeOt38puFPY2bUKVYpvw9uHngMV3Lae2YyuHxzM5Sh0MEirdzVPs3uOTOmibZqCXpSkUe0T1k0KOAMjPFin0tEqEWwLyxNt89i2+n185PwB91zAi0lTSZzqmL4FmrlM6Qxix42zIAkWm4mOEI7g0TmSGgSWU+jrw5iElEVuRWTkZRHmgpejv4fqPfNrJqtkP69d+w43mpSVFJc3mWQuMCdhfmXBd7RwI/F0XUNGA28KyZ9EaDey3onUP272M238DZR6dyT7kwtF8QwqJuwkd989uNMQtoBfmFp/9ofjVcxTnOrxqSxuCaxPl+KDBMyvthItQPgGpHLRul5WAyY+ZyzRkSwpfZI1XPI1tR+PhPriw7oSS+BX9rvhu9pNqnAtmFtsANUBq05gAh8Y0qJ2ugO4nC3OFDNWgDvfig92rWF9P+e9p06tmzNCFY4Mwnw8U9qIeNqKeA3SQO7poW5shjmwYM9Pro1dAM1lH0m/tTFKyBIZ+h7T9rlKGlBWVA/lb5puhLe2BBy+eYRO7UD8zo4xns15odJqtURJc7EMb3r6afNbV+ODjqrkTkUginGCwqImExF8ucnKunasS+6hnuMTmxwSVMY6+ZGTA2xmo9Gw7hsQfPBa0im9WpetQppSGuxXSJ7KA8N3HvyYm0J8z2R/6pvjzDLO68Dtd3sEyUs=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(4143699003)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?a0gyb1EvU2pUb0xRM3Z6dVVET1pDS1hBYnkxQ2g5OW5ob2RtbUNEZFFwOXo0?=
 =?utf-8?B?S0xUd0dybCtMTmFUMk1GcGNZaDZCVUlheEExWlBWcjM1cFZLd3Irc3kzRmdO?=
 =?utf-8?B?dWRiV0pXZVBvdDBiQ0plS05qWlpIUll1c203bXdMcXc5TUVMUkpvcmdGd2or?=
 =?utf-8?B?VHJ2QzNIdWN0U2JGSEhPMGNRV2VOMFlmTG9yenJDQW83MmExY3pMK3dIQ2xk?=
 =?utf-8?B?VzRlS1BBTENxbFM5R3B4SmplR2FtTWgwL1dsWkJ1Ulh1T2Vhc0N4QkdRTnNO?=
 =?utf-8?B?ay9BQU16MmtvNFVLOGVNSnMxOWhQRExpVEp0TkF5UElPWG9YL3NtVFhXczBj?=
 =?utf-8?B?b2ExWjFabENSaDlva0N4MmpvUG1zazUwNWZRK2hjMFRZbHEvbFNkSVFReHUr?=
 =?utf-8?B?ekZ3MEdnKzZCaTl4M3M1blRXaENyZkVUTFpSVk13VmdYbXlobG5vUnJEQ3l6?=
 =?utf-8?B?WHM3Wkt5aUxHQnNzc2pCc1g4YlZGK3hZZTVWQ0U2RkRsZUxPdUJjWFJWL3My?=
 =?utf-8?B?Z2lPbnZjYlBIL1JtcVJqUFZPSytXblFESDdTVlB5M3ByQklWdTdRMFJaZVVE?=
 =?utf-8?B?OFVyd1ZzeW01bVVPc3Z1dUJvNXJqVTFvWWFZeHV2SXlrd1dSNnNMTFlvQzd1?=
 =?utf-8?B?bVJjbm9CVXBLNWV4OGZpL2ZMMmdiaGJqT1d1QVBYSmZWZ0E2amFuUTBPUm1M?=
 =?utf-8?B?cmcvTHlxSmhreXNuNVZheDVTaFhncDlCNjBBcXliazRTb1hmY0thM1AxNkhM?=
 =?utf-8?B?WFFlUWFUM1dIZFhsMU5mcXFGT3J4QUpEdlNWWkJZNXFrNmg1dDg1VVRzSHdk?=
 =?utf-8?B?TTloZUNpTVRJWXdRejlrZEVzUHczanNwbGllTzZlbVFIZ2VXZXFWS3dSanlP?=
 =?utf-8?B?c1AwS0ZUZnk3QU1nOUxNUzZXRmdMYVZCM0w1RnZPM3ZEb01ZaFowODdpajVD?=
 =?utf-8?B?S1I4L0U4am40bEhYZlRsQ3pqZjkxTkUwcG4rTlVZbFZ2SldJUldFaGU2b1VH?=
 =?utf-8?B?WWI2eENXaUFSNmVxZE5oZTY2M1pxWGowVmNVcmljb2V2YXpHMUx5QXFQOWhZ?=
 =?utf-8?B?cTdVQmRPcTRsM3p6aUpGa3NMSm4yb0VOMVlBd2NKMDYvenVISERIYkhGVDhL?=
 =?utf-8?B?dXVIVjd0S2ZoNlNLZVoxTTZFdWo3b0JIeWdZcG1sNDBkSjZlQWRVVG9IUVo3?=
 =?utf-8?B?YmgxYjNMK3R5cHJhS2hpa2xTbXhQVlZ6OHhtWVdqblY3ekovSnhTUkZ2QmhP?=
 =?utf-8?B?Smlma0tVRzJ5U1puZ0dOYklwNE93TFNCWEpYMWk5bjBhVlU2UU1Fcm8wQmxW?=
 =?utf-8?B?QkF0TmdBa0ZZMUp4SUFKOHozbGVIZWdMNDVlc2tYZTRPRTFZUTlDSFFqU1M4?=
 =?utf-8?B?THJxLzl6Vjdnd251OTd4QmQwalhzYWZVMnl4aWNtUnhRQkVERDdxbTBRSDV5?=
 =?utf-8?B?eGRsbGw0ZThiUEFZYWlyaEN6aXBMeHFyRERsQThXc1VvSkoxNVk2Vk1YTUlY?=
 =?utf-8?B?ODZRVVp1K0JuU281czlkaGljY29Pem5kRzN0MkxjcXRPWHpuL2JrMnl3THlZ?=
 =?utf-8?B?OCtzc3NTUGVsMjR2SDkwL1EzQm1pR2VFQU1kU2ZvRHA2Z2h6cGZTeUE4S2s5?=
 =?utf-8?B?UjBxZ3dmUmtmRjBXMzlCR2t2ZzV4czBjYkpmanAwa3JaektuZ09obVVHTE1X?=
 =?utf-8?B?QWUzU3IxOGFLcmpnSWJ5bUE2eXpnTGlQWi9JakMxaGkzUVlLemhrakJxb2hp?=
 =?utf-8?B?QVYxdG95ZitQQld0Y0JhcU1jRjUzZXlEUlI1bE5jQ0ttTUFVamhzejVUQkdo?=
 =?utf-8?B?dnU1ZUpIVXdyZEEzZ3VpQ0IyWWQvdWQ1UW1TOTdBS1R2SEJPZ1B3WktKTWVN?=
 =?utf-8?B?Tm53T3JUNTRrK0RSZWM0TzZyak9uQmplZmd3ZGVKYWpLSVVOQWhzMEhNVDR2?=
 =?utf-8?B?N3EyeWQ5Wmg3YW5hQlFVQjJjTlpmSUx4SVVQZ25rS2UzeXV2aTBhTnJ5V1Ja?=
 =?utf-8?B?cjJSdUErWjluWWF3L0hmSnBiWDlyUC80cWhJTVVyekdHU2NuejRaVlBLYms5?=
 =?utf-8?B?aktCTW5hMENueExQbE5ieFR1VjdianVVV2Q4aC9PcU9IK1V5L0YxS0xhQ1pT?=
 =?utf-8?B?ODdmQjU0RlFrSmMvWVBvRHNud2RoZ3d5VWJoSEpCTlpYcXhiM1ljZzNGRlpC?=
 =?utf-8?B?QlpEeTZpcitJMU9uUkpMbzVwSW1JWXBMZ1JXcnBmTDgrYU5mNVdMWVpPQ1Jk?=
 =?utf-8?B?U2Z4Nkc3czNWbVA1ZlZGQ25rK2lheXo2aEhhQkd5VFQ5cVA2TjlVTitGOHc4?=
 =?utf-8?B?bDYvQ1JyVVdkNjBDdVVBR2lzd1hEQW9vZlVzS09sUXQ0OFQ1NWd0Zz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 357b064f-27bc-41b9-31ce-08df07494c1d
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 10:19:10.2464
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: wRZTcwFQejmof/rYjJotN0Z2B/4LKm45LnWWcW6Sf+8Y7XJWcVZaoLlYYNIDYPioo4wzECxxuJOtCDOTwRYiiB0miAxcuouKrQFnzO7CKac=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5527
X-purgate-ID: tlsNG-d25034/1788171554-76EDAA5B-189DD076/0/0
X-purgate-type: clean
X-purgate-size: 1376

On 27/08/2026 10:38 am, Sergiy Kibrik wrote:
> diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
> index 9036e455d6..e4de292533 100644
> --- a/xen/common/device-tree/Makefile
> +++ b/xen/common/device-tree/Makefile
> @@ -11,3 +11,5 @@ obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += kernel.o
>  obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
>  obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
>  obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
> +
> +CFLAGS-y += -I$(srctree)/xsm/flask/include
> diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c
> index 41d72d0d58..bffd2ec65d 100644
> --- a/xen/common/device-tree/dom0less-bindings.c
> +++ b/xen/common/device-tree/dom0less-bindings.c
> @@ -11,6 +11,8 @@
>  #include <public/bootfdt.h>
>  #include <public/domctl.h>
>  
> +#include <security.h>
> +

security.h is a private header for internals of flask.  Requiring the
CFLAGS += -I should have been a hint.

If a suitable public function doesn't exist, then make one rather than
inserting a layering violation.

To this specifically, I'm not sure security_context_to_sid() handing out
SECINITSID_XEN if you happen to call it too early is the wisest
behaviour.  It's current call-chain has an earlier check which I think
excludes this from occurring.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 11:51:15 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 11:51:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403934.1637870 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10XU-0002oW-81; Mon, 31 Aug 2026 11:51:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403934.1637870; Mon, 31 Aug 2026 11:51:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10XU-0002oP-4J; Mon, 31 Aug 2026 11:51:00 +0000
Received: by outflank-mailman (input) for mailman id 1403934;
 Mon, 31 Aug 2026 11:50:58 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <Michal.Orzel@amd.com>) id 1x10XS-0002nE-I4
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 11:50:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10XR-00AxJ1-EO
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 13:50:57 +0200
Received: from [10.42.69.6] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a956a97-e002-0a2a0a5209dd-0a2a4506d724-34
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 13:50:56 +0200
Received: from [40.93.195.43]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a956a9f-195a-0a2a45060019-285dc32b42c3-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 13:50:56 +0200
Received: from MW4PR04CA0270.namprd04.prod.outlook.com (2603:10b6:303:88::35)
 by CYXPR12MB9280.namprd12.prod.outlook.com (2603:10b6:930:e4::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Mon, 31 Aug
 2026 11:50:50 +0000
Received: from MWH0EPF000C618E.namprd02.prod.outlook.com
 (2603:10b6:303:88:cafe::ae) by MW4PR04CA0270.outlook.office365.com
 (2603:10b6:303:88::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.13 via Frontend Transport; Mon,
 31 Aug 2026 11:50:50 +0000
Received: from satlexmb08.amd.com (165.204.84.17) by
 MWH0EPF000C618E.mail.protection.outlook.com (10.167.249.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.382.8 via Frontend Transport; Mon, 31 Aug 2026 11:50:50 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 31 Aug
 2026 06:50:49 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend
 Transport; Mon, 31 Aug 2026 06:50:48 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qiTBVenv9iqz317eTf+0DUVd3Jziv0MKO/Z45bK5RNiXsnRPD4BsfEv30bWRKf4M6tnk6Yct8ayIEdmgV9anWlIKya4QsYiphA7aJ08Bzkd1Fs/4vIpZDTXwApUXEOFs6abkqzIogZPt+R+oYaKNu1lIksCWpcd1ZyVNrXpszvoVSuWOmnouLiepTQZ5jhX4y22+QCcGK3nMDizdqU8Bbj9EMBmgGsJf3ynz80tdhmD9x8crFgQzDrHFo112TlI1VC4nbUNmB8O+1Ow+BbWFyIgphIYqNqhVmWgQOTt8B2NFHsx3qV7/2YAZo8AovFjhuxd6ge5XAQXbGRrt8LXiIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IujtkwXMHfDFXdqwQftrHetytD5NgiSmrmc2PNl8NC0=;
 b=Q9vmasT4uUjzl7+Xh2D4dq2iz79qT2OGuDAE+3gcgEapJ0f2vzJpKdtM0O0y7pGH+f3sRDHQNovYjIqj78iCtTCDWr1JZAr38FJNvmEjrp7EgvdpGbX7SaDboS6cpgkVxtl0npMzBws0VNV2RG44NMbIFzOcmSxrMGe1K08YX2grIYCMhXcqMHptT2sgoKmZpdZdZ4uSPt5ohuxRs9EV44uQWgl1eW1yW5PNBo0cA/4tCo66RWzjmRyvhf2+4VQNAqbS3KKeqjkVW76SXKrGorWGyz4Y6Bfmyzn3ZGgpZTUaqN5uZttuO+rLfc/0GfWPLsU13P+X2AuW3u8Lz0negA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IujtkwXMHfDFXdqwQftrHetytD5NgiSmrmc2PNl8NC0=;
 b=lNXgPyW2uMkbBa+woWoyJwsWbMGgetKzzNZDldkAr760xWPlkBJCqB1Dr0kQ9VLpusgySnRqZAMactcQSMIToDKcjJTpezEo2XCX+eITeZjP2bAUYE+Gr4hPIhLJSe5jlLKXo8nPvF4bZvEPgXkV3r+hSr2EaG4a/JpvK/JB9hQ=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C
Message-ID: <38fdf553-ae94-4b04-b9c3-f3ebe68a10cb@amd.com>
Date: Mon, 31 Aug 2026 13:50:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Don't pad between function with x86 nops
To: Andrew Cooper <andrew.cooper3@citrix.com>, Xen-devel
	<xen-devel@lists.xenproject.org>
CC: Stefano Stabellini <sstabellini@kernel.org>, Julien Grall
	<julien@xen.org>, Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>, Bertrand
 Marquis <bertrand.marquis@arm.com>
References: <20260831095633.2834187-1-andrew.cooper3@citrix.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <20260831095633.2834187-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000C618E:EE_|CYXPR12MB9280:EE_
X-MS-Office365-Filtering-Correlation-Id: c63f6e35-6702-4f5d-5e15-08df07561ab1
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700016|23010399003|82310400026|10067099003|56012099006|11063799006|6133799003|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	fuTtfhwG85cSybVgNNURSnswFWPGmwDgEiGV5lkToyH6tSfQVwLzpIAGrMlaqHUG2jrMGXgL1puPsNj9VHoaUiAPXZUI60dn2fLefqJB5VdecdBANXn4Hv9DYuMC//oUjnmlN3f9YNwd1FGFCtd5U9UlWwevf3vjFngoUqXxKOS2eymma8GzFLQf4Da2bPNDTxDbH+TnbqJPHFnkbrd5BbtieCuTh8FjqrYFRD5U24rbAjprKRgcoA9UcTStKOawjymDIqJabsmHB2VEnDy4eNU59DNEEt3qlggDsWK6jlm1+dD6oH6ye0DmdZ+4S5NKCB66nXPztb2mj+ouzfpNvqqIeJXqJr0TCxus5fNx5jaHrqspW0L+FLNJPIoVXc+3n9yne8U0HjJ0vXkuj4+u6bdEqVLTFN2Wpp0SlRqYmbkgS90WCZBYWNfMMOhtzxyQ+9S+IzFS0MvoT/qUqxzqhLQw5vWqsTFFaWo4bJRbstuNrK6azIXued/GRaWYimpxtc48M/f+gfeVb9mh2LCv1+74EyXrO3qH5S8FAPDUW64WfPC7ZHnH2ldK9ujBDeseYSBnNmB8knOJjfGyXLHlKbDb36A9QvN+wX0eVsTef8Gn/TrZbfXdny3ZNbWIuzjNRBAwaTpNy9FyO7D0grUiVWgDj568SDlrbo58pkoZQX+bCdE9KubMrYkswQt+RjaFO4JOUnmyyNVQ5dlSUmYw5A==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700016)(23010399003)(82310400026)(10067099003)(56012099006)(11063799006)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	sDAdBx3aFWwZQGDLZ5V0yHtO4kP13Zq6L9J0bhhLAFTjjqX/nQHOz1FMPxXBqb/Dc83EGnS2Zz1pnhv5xfuMjI8BTCAdAD3JfJ8BJ7O1ENAZaTKNky4A1S1vT9uImWXynUfDPpJ1c+1S4XYI5aCeLorTiMs/17X21l+PafkjhbNB+IKA9bdmXgZn9J/4gmiMRhPeDr3wHlLpmXCZ822s64kjIlsg8yVtfAmxRWsQYJBRwe3wgiISpwvSwcQkGOBLK8Z+BUcS1ccJkPfWDByU+Sw2BUsJqjqvX0tvCGUzV3KdTbNCOHKeBTL020GY7uAEccwFh91Lfdw5r3adgeDnHrpKt8Mfs57Rj7bGSo3cfCtT9ie+zSHBry0XruK/DYl9N6I/5ggkfrGCGOyA8Tvl9K952ZIL/y1aqM4C7Hem63X4lBMQBwOVFviXO8amMQSW
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 11:50:50.4971
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c63f6e35-6702-4f5d-5e15-08df07561ab1
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000C618E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9280
X-purgate-ID: tlsNG-16d1c6/1788177056-F627077B-92F972D3/0/0
X-purgate-type: clean
X-purgate-size: 489



On 31-Aug-26 11:56, Andrew Cooper wrote:
> This was copy&paste from x86.  It causes the padding between functions to be:
> 
>   a000026dd64:   90909090        adrp    x16, 9ff2147d000 <start-0xded83000>
> 
> rather than:
> 
>   a000026dd64:   00000000        udf     #0
> 
> No functional change.
> 
> Fixes: 5da0d3123c0a ("arm: entry.S and head.S")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:19:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:19:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403955.1637880 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zP-0006nX-J3; Mon, 31 Aug 2026 12:19:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403955.1637880; Mon, 31 Aug 2026 12:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zP-0006nQ-EC; Mon, 31 Aug 2026 12:19:51 +0000
Received: by outflank-mailman (input) for mailman id 1403955;
 Mon, 31 Aug 2026 12:19:50 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x10zO-0006nK-OY
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:50 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10zN-00Dc7p-MC
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:19:49 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a957164-8faa-0a2a0a5109dd-0a2a4507b388-8
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:49 +0200
Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a957165-b4ea-0a2a45070019-d155dd2fcdb2-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:49 +0200
Received: by mail-wr1-f47.google.com with SMTP id
 ffacd0b85a97d-47c2b362ee2so2964333f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:19:49 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48440e094d0sm847709f8f.23.2026.08.31.05.19.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 05:19:47 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1788178789; x=1788783589; darn=lists.xenproject.org;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
        bh=NG648HPaf7qwInbMqQdYHDK/TmVROUa07Mg3m1YSEg0=;
        b=rnNBHg/FmUCHjG2dBRodLD7EBgQYyIMXwONrDKO2rzIEa9iVfpuqJaCISxS+kVcYWS
         RS+7EoXqcy/4s4Fgfb5ArmTHODTNyNgSOhp6B++620qqSCbSCesDuC112X3l5acokIv3
         48EJijBgVKwtT8vp/tAa2+YhZ2kjrDPl9rglo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788178789; x=1788783589;
        h=content-transfer-encoding:mime-version: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=NG648HPaf7qwInbMqQdYHDK/TmVROUa07Mg3m1YSEg0=;
        b=UEQ4QgE06qyJ4aInjSvjsBOl7guX50VZ+DxpTMhZsMJBf9z4P2bR3qu6CnRuARmjXV
         gOZmupV+A2fb/Exahem1JMJvSm2l51PiWDNg5c9d8Tpq2Iz8C7l8GkUqanPxQsn7O9hS
         m4cT/0yQ6TrnMeOnKNKVvbq4Rwo/4ZdPXqTiYXjXhSMgp+LqpKCAMfv8srNWU7cIy+Ty
         kBiRFfRUS44O3NUKC3fSfYwwYnx0yYbV0Wc/7fxH1QpXWctr3KEjHwnFSGj4wr1uF3k2
         Iez+IrBzGOKbSwIAc1kk7J7ZlV92p/Qpmql4OPkOlAP4wdaL5PDJlETeJfvud8LFSS+s
         IjOw==
X-Gm-Message-State: AFuF++mZ8Pno8np0BRlItOYkGQZr/unr1Agm8hQRLAId3mwYwfu/Pnxv
	J3kM0oDpzJFNO2ax7pkcZ4I6Ewfv3sZx8g3la34qCpRUxi7vr7cjBlILxeKIgB7V51Ub1jycdYO
	MN7Exqdg=
X-Gm-Gg: AYBFou0GEN1fHWp/k54W/GzjpzRB7FF0nUQiTjM2nKXt7cqxOJMpkPIdjXhIhEmZPDo
	KF6EoF2pZfn7iOLmzBP9ipw9tRjv9Vm9Ir1vQhImHSQ3iRLHaS+/HoCXDr0IBcqNNudVL/nb2u4
	OK8dzNHr5EJpISP1XB+qTfoddw5nX8aeFTE4/7VTjxmXdaGiSSJxdH9v7Up1ayeZcjOhnblsPE+
	j2Rh43QjfuagVwD9JR1XBDj1x9vu60kR7+RM22ysaF1tKx0cexJEWhnKHemQnhYsmVGs8yOpUQi
	LzS+wlgWwj33DdF0VeN3UoYCjGDrsNYhu4vh9KWbaL9TC0HW4Ijqz9USGAFCIb2++UnAQmfAc9V
	QFm0ajeSSMTLQ5/KN3ewZY0Tm6tdn8MbdzbeZA5QN1qQ78jA9w3sOKwggwrmyJ2vcFdvGbOow7F
	SEghsDe52QBSete43/TnljIW5FIlYXB5gO+/4f7n9ERP5bcBPXcqyFqZqTpLxlX6ntatSuy2ivp
	axd+lHDkomsRA6EPjeyHGVJVRA4tdI/2HQBLPUd
X-Received: by 2002:a05:6000:4a1b:b0:484:3311:3702 with SMTP id ffacd0b85a97d-4843fce530bmr2884410f8f.25.1788178788537;
        Mon, 31 Aug 2026 05:19:48 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [PATCH 0/5] xen/arm: Fixes and improvements to SMCCC
Date: Mon, 31 Aug 2026 13:19:39 +0100
Message-Id: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1788178789-A4ECEAE4-4526886B/0/0
X-purgate-type: clean
X-purgate-size: 1243

Patch 1 is a bugfix for the issue reported by Jan Setje-Eilers.  It needs
backporting to Xen 4.22.

Everything else is because I couldn't bear to leave the code generation in
such a bad state.

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2805409790

Andrew Cooper (5):
  xen/arm: Fix evaluation of parameters for SMCCC calls
  xen/arm: Introduce arm_smccc_guest_smc()
  xen/arm: Clean up 32bit arm_smccc_1_1_smc()
  xen/arm: Rewrite arm_smccc_smc() for arm64
  xen/arm: Rewrite arm_smccc_*() to return by value

 xen/arch/arm/arm64/smc.S                    |  16 --
 xen/arch/arm/cpuerrata.c                    |  18 +-
 xen/arch/arm/firmware/scmi-smc.c            |  16 +-
 xen/arch/arm/include/asm/smccc.h            | 241 +++++++++++---------
 xen/arch/arm/platforms/exynos5.c            |   2 +-
 xen/arch/arm/platforms/imx8m.c              |  16 +-
 xen/arch/arm/platforms/imx8qm.c             |  16 +-
 xen/arch/arm/platforms/seattle.c            |   4 +-
 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c |  17 +-
 xen/arch/arm/psci.c                         |  17 +-
 xen/arch/arm/traps.c                        |   4 +-
 11 files changed, 165 insertions(+), 202 deletions(-)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:19:56 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:19:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403956.1637888 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zT-00070f-Nz; Mon, 31 Aug 2026 12:19:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403956.1637888; Mon, 31 Aug 2026 12:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zT-00070R-Kh; Mon, 31 Aug 2026 12:19:55 +0000
Received: by outflank-mailman (input) for mailman id 1403956;
 Mon, 31 Aug 2026 12:19:54 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x10zS-000703-HP
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:54 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10zR-00Dc7p-Tq
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:19:53 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a957157-8faa-0a2a0a5109dd-0a2a450bb102-34
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:53 +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 <andrew.cooper3@citrix.com>)
 id 6a957169-b7e8-0a2a450b0019-d155802ff195-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:53 +0200
Received: by mail-wm1-f47.google.com with SMTP id
 5b1f17b1804b1-49ccfae359fso12001145e9.3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:19:53 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48440e094d0sm847709f8f.23.2026.08.31.05.19.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 05:19:52 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.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=citrix.com; s=google; t=1788178793; x=1788783593; 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=ErWLaEnj10uj3lU2o4qVnGamxA9UVeFuuO35JsiTkDA=;
        b=gwUuILzhgdQwlH1vs8jcPGWvHW0NXiUqe0GjTpKNWXabscKTnfitj7iVD/qeR0mNQM
         TqMBvc3sG8ZpV9vaUXBpZPkT7Se0VRuGJ7VGi3FhiVogC11UIyCsIv8yMRdUtrAsb5Zt
         nQpF2tNS5Ysr79OxHzw0iJCaa7ieKVBhsZrDM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788178793; x=1788783593;
        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=ErWLaEnj10uj3lU2o4qVnGamxA9UVeFuuO35JsiTkDA=;
        b=EojxHvLpoQVsx6Jcn1KkRID6jQV1DvBVLxivb58bSOUu0EzyRP/jywqpuoOirlCvG+
         OdBCfsyG5KKhjs80qcKLz2EDAfSZo74g/uPHV909Sq7H/ipHs3HfDPexp8NSHwomid6L
         VOEnPWx8ISHPWmbyK+N75WIgJlnx4SYCixSoLJS0Qe+1BY+xDULqNkEvlvyVLTfH7Qxn
         SfINRi398Nw+qX5pEUkTxGBi/79IY5g5eIl2AWEWmR+SDXy/Mp1lLGTyMSLJcYRO9/yO
         uWFeAAODaIadVUlHBVMmlBKZpGUay+ura7ETgkZI+lsw6FM4mIrmYCFiojoBNX1yMtyw
         U4jQ==
X-Gm-Message-State: AFuF++nAbUSMtFz6n4hGk0Y4ETZZ7aKvGRmMGKVAzZnMiJEdgOp5yVoo
	Oq9yBxt84RI5OBQXFoa+JrDWCy21fSaXbCZ4SpWQUBHvT0Z2NJbcWOp/HA2S1M6RxT9ry83xIK8
	/nWgVJn0=
X-Gm-Gg: AR+sD13CvRpoD2WY2o5aRa29mc7Z/SFMgH+evrlZJCgrwKJ/fBvG47EBfNkss6Cf2bD
	UfPHkHzCv5UkVhy9vGJ1OwegH+jHS7Fb9cmYWXrW9w0+5ctFyevjOYlo/42/N44DthY1msMUfXO
	fE0gzTYrhHrIqoLuxv514CDLdbaPyZeO3CY/e0Oux/E5Q0iMsP28MebSKWQ4CmI1VXd/Lv0bl3E
	+jVhFrBPtTUTMAFL1KAXPpsfjVL6CjR0COpE6+JBDmz4hi2NSWME0GnXnICE/EmjNJ0b3PiFY+O
	Mh+MD2GD7MiINO9YTrC4cMOMD+eRMRcJrA6OhRA6cU76OWjLHcON5KERj1BHDCNx4o0SaOZd2JF
	44qStXpnFaX/HdQA4RlWi5zcTPbi5K3R7qPEUwuF/Zz4GCbXKq6VPzZOGvTjI9ETaxLuTYoMwiY
	JBz7FDPIdgt6DdVy+1XdrYO6EpfSti5hW3QKxdFufBzxM0mmrUBfURb55E61ZTzhfQel424GS2E
	n0rGLFWkvrZvHVMUZ/IPlE9wz8IUSYVLsriKwU=
X-Received: by 2002:a05:600c:4744:b0:499:8b13:3a98 with SMTP id 5b1f17b1804b1-49b91c2479amr389264755e9.4.1788178792772;
        Mon, 31 Aug 2026 05:19:52 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>
Subject: [PATCH 1/6] xen/arm: Fix evaluation of parameters for SMCCC calls
Date: Mon, 31 Aug 2026 13:19:40 +0100
Message-Id: <20260831121944.2908139-2-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
References: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-42698a/1788178793-AAEDE9EA-3C1B024F/0/0
X-purgate-type: clean
X-purgate-size: 4638

Contrary to what was claimed in commit 67bcf5eae709 ("xen/arm: Simplify type
handling for SMCCC declarations"), there is an important reason to retain the
intermediate variable.  It is unsafe to have any logic between the assignment
of the register variabes and the asm() block they're used in.

This logically reverts commit 67bcf5eae709 ("xen/arm: Simplify type handling
for SMCCC declarations") while retaining the conversions from commit
7f15d5d13221 ("xen/treewide: More typeof() -> auto conversions").

Adjust __declare_arg_0() to match.  It happens to be safe because it's the
first register expression once all macros are expanded, but it really should
be consistent with the others.

Leave a comment explaining why they must be written like this.

Fixes: 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations")
Reported-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
---
 xen/arch/arm/include/asm/smccc.h | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index 62c6985e7315..53cdddb690b7 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -108,37 +108,52 @@ struct arm_smccc_res {
 #define __constraint_read_6 __constraint_read_5, "r" (arg6)
 #define __constraint_read_7 __constraint_read_6, "r" (arg7)
 
+/*
+ * Macro arguments MUST be evaluated before being assigned to a register
+ * variable.
+ *
+ * This is manual register scheduling for the asm() statement, and any other
+ * logic to evaluate may clobber the already-scheduled registers.
+ */
 #define __declare_arg_0(a0, res)                            \
+    auto __a0 = (uint32_t)(a0);                             \
     struct arm_smccc_res    *___res = (res);                \
-    register unsigned long  arg0 ASM_REG(0) = (uint32_t)(a0)
+    register unsigned long  arg0 ASM_REG(0) = __a0
 
 #define __declare_arg_1(a0, a1, res)                        \
+    auto __a1 = (a1);                                       \
     __declare_arg_0(a0, res);                               \
-    register auto           arg1 ASM_REG(1) = (a1)
+    register auto           arg1 ASM_REG(1) = __a1
 
 #define __declare_arg_2(a0, a1, a2, res)                    \
+    auto __a2 = (a2);                                       \
     __declare_arg_1(a0, a1, res);                           \
-    register auto           arg2 ASM_REG(2) = (a2)
+    register auto           arg2 ASM_REG(2) = __a2
 
 #define __declare_arg_3(a0, a1, a2, a3, res)                \
+    auto __a3 = (a3);                                       \
     __declare_arg_2(a0, a1, a2, res);                       \
-    register auto           arg3 ASM_REG(3) = (a3)
+    register auto           arg3 ASM_REG(3) = __a3
 
 #define __declare_arg_4(a0, a1, a2, a3, a4, res)        \
+    auto __a4 = (a4);                                   \
     __declare_arg_3(a0, a1, a2, a3, res);               \
-    register auto           arg4 ASM_REG(4) = (a4)
+    register auto           arg4 ASM_REG(4) = __a4
 
 #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)    \
+    auto __a5 = (a5);                                   \
     __declare_arg_4(a0, a1, a2, a3, a4, res);           \
-    register auto           arg5 ASM_REG(5) = (a5)
+    register auto           arg5 ASM_REG(5) = __a5
 
 #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)    \
+    auto __a6 = (a6);                                       \
     __declare_arg_5(a0, a1, a2, a3, a4, a5, res);           \
-    register auto           arg6 ASM_REG(6) = (a6)
+    register auto           arg6 ASM_REG(6) = __a6
 
 #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)    \
+    auto __a7 = (a7);                                           \
     __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);           \
-    register auto           arg7 ASM_REG(7) = (a7)
+    register auto           arg7 ASM_REG(7) = __a7
 
 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
 #define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)

base-commit: 79225a0c77e13b693b4d2b903a88289704b79db6
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:19:57 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:19:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403957.1637898 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zV-0007DZ-0Q; Mon, 31 Aug 2026 12:19:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403957.1637898; Mon, 31 Aug 2026 12:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zU-0007DR-Rr; Mon, 31 Aug 2026 12:19:56 +0000
Received: by outflank-mailman (input) for mailman id 1403957;
 Mon, 31 Aug 2026 12:19:55 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x10zT-00070O-Gl
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:55 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10zS-004lvp-Tm
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:19:54 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a957163-e002-0a2a0a5209dd-0a2a4509a31c-20
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:54 +0200
Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a95716a-be1a-0a2a45090019-d1558030b01d-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:54 +0200
Received: by mail-wm1-f48.google.com with SMTP id
 5b1f17b1804b1-49b0dbfbf7bso24301855e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:19:54 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48440e094d0sm847709f8f.23.2026.08.31.05.19.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 05:19:53 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.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=citrix.com; s=google; t=1788178794; x=1788783594; 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=MVv38LcWR6swmevPdVRrJrsniqIiQEzhS6N0zpQmzY8=;
        b=dIHg9EM3i3uShTC9Y48KQmQXv8PiVCrVPxu0q0OGpuYFAUIfgXFx5c2BZg6f+jDFvK
         Z3FIGYRzlUTjziWRQQ+GPJpIl4wodz34DJsvl0HQhUwmd+uS9ERM/+6Am+qYtRyGo6EK
         NdGPxGa+J093ujxy0r22ygy/Rq3U8QzPJdkmM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788178794; x=1788783594;
        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=MVv38LcWR6swmevPdVRrJrsniqIiQEzhS6N0zpQmzY8=;
        b=gb1UanIix2qrIfesedjJbNHIJ3xVzrAGhXFiC1CWGcqeCf7QOWewIzUDYRuycGBVyS
         JwFCVsNt70FpA6U3DkzfdUmeCPCsFDNUB/L6l48jrrj1ND0O5TcAMycK4q3Ik6raTcsz
         E2pT4BB1JwchU4HAg9CqpFWQmw8QKQDZI0D+KHiw/lGl6cyHBlPCRF9uzUL0tPl+tTTe
         4zvxgEuj2qcUgoFmjB/aCKNJ5znjdAdZx5Gnew1caQcK1+46jzBuQrNUIHivr92D741l
         cHVyPBECrVXrUTWQaCL+vg+8g1SooLRGZKLTVgCgNQj6/0tzgumJodRWkyTAd/XhD8US
         +c9Q==
X-Gm-Message-State: AFuF++nS27tyAykEhzOZnptHIFxycdYkJmlfmud9CGR+iEWLlUQU22Sl
	CURlXWUSxYqWBWQY4qhN5rsAOMXzfK6KwPrbXFNzTmjJAzFcNuQK8Xkf5QAwhiWmcXrqAP2HUC+
	t62x7umw=
X-Gm-Gg: AR+sD13cuDfw7j6LZKp5+N4FPqHhpHnDyY+vcnZwS/47KYopynglYqposoBltOCkZEv
	QG6hOfP35FjV0RMcy9jw6b2As1YGlwII8EYWigT9g1whGAoMnHGrJzJCP10K+vHRv3bBnGn+tbt
	eJXoOJcEVEFFm2dNMvS3Y3jTlO53PEgAQGE98V6lpGAo4TkPccJVxyJR+uYZjTYwFp16rAqHcgG
	L81HKmnzo1yWr7nMRk4eeWoLhzT8x2EaZVkIELR+xb59rSRm/JwI4eFQiyZFR3Rgx5+6yTmxdK/
	BNIuqqXf1sAvotbz2Y116J4++vGFx2klP7+9Vc5x9DAH+XLwN/T+M4xnSciqIuEBnFqzPDDHZug
	O5eqAztSRtsEblw69hKCPDM0qbhu8gKsHoMLNN/eQlQYZh349AclvdqlmyhA5I/uTWZlgy9O+vc
	fTA/3vKhuSKhHrBI32ggK1xmXIfOxczZxcCtI/mVpDcQIKjyP3cIcnHdb8Qt2lp14nrkrdT1biV
	aPgQxwlZxi7uo1bx2gsUyP71uy3QtntYOXm5uw=
X-Received: by 2002:a05:600c:3492:b0:49b:909e:922e with SMTP id 5b1f17b1804b1-49cdc4523d5mr2030625e9.10.1788178793786;
        Mon, 31 Aug 2026 05:19:53 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [PATCH 2/6] xen/arm: Introduce arm_smccc_guest_smc()
Date: Mon, 31 Aug 2026 13:19:41 +0100
Message-Id: <20260831121944.2908139-3-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
References: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1788178794-FCC15034-9B0C6FF7/0/0
X-purgate-type: clean
X-purgate-size: 8290

Both {get,set}_user_reg() are out-of-line functions, leading to awful code
generation.

Introduce arm_smccc_guest_smc() to operate directly on guest registers.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>

For arm64:

  add/remove: 0/0 grow/shrink: 2/4 up/down: 27/-864 (-837)
  Function                                     old     new   delta
  symbols_addresses                          35096   35120     +24
  symbols_names                              42958   42961      +3
  imx8qm_smc                                   544     348    -196
  scmi_handle_smc                              372     152    -220
  imx8m_smc                                    576     356    -220
  zynqmp_eemi                                  864     636    -228

For arm32:

  add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-160 (-160)
  Function                                     old     new   delta
  scmi_handle_smc                              392     232    -160
---
 xen/arch/arm/firmware/scmi-smc.c            | 16 +-----------
 xen/arch/arm/include/asm/smccc.h            | 29 +++++++++++++++++++++
 xen/arch/arm/platforms/imx8m.c              | 16 +-----------
 xen/arch/arm/platforms/imx8qm.c             | 16 +-----------
 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 17 ++----------
 5 files changed, 34 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
index 0835ddeeeccc..a0cc6c6192f8 100644
--- a/xen/arch/arm/firmware/scmi-smc.c
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -50,7 +50,6 @@ static bool scmi_is_valid_smc_id(uint32_t fid)
 static bool scmi_handle_smc(struct cpu_user_regs *regs)
 {
     uint32_t fid = (uint32_t)get_user_reg(regs, 0);
-    struct arm_smccc_res res;
 
     if ( !scmi_is_valid_smc_id(fid) )
         return false;
@@ -63,20 +62,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs)
     }
 
     /* For the moment, forward the SCMI Request to FW running at EL3 */
-    arm_smccc_1_1_smc(fid,
-                      get_user_reg(regs, 1),
-                      get_user_reg(regs, 2),
-                      get_user_reg(regs, 3),
-                      get_user_reg(regs, 4),
-                      get_user_reg(regs, 5),
-                      get_user_reg(regs, 6),
-                      get_user_reg(regs, 7),
-                      &res);
-
-    set_user_reg(regs, 0, res.a0);
-    set_user_reg(regs, 1, res.a1);
-    set_user_reg(regs, 2, res.a2);
-    set_user_reg(regs, 3, res.a3);
+    arm_smccc_guest_smc(regs);
 
     return true;
 }
diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index 53cdddb690b7..832157f43734 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -202,6 +202,21 @@ struct arm_smccc_res {
 #ifdef CONFIG_ARM_32
 #define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
 #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
+
+/* Make an SMCCC v1.1 compliant SMC call with guest register state. */
+static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
+{
+    struct arm_smccc_res res;
+
+    arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3,
+                      regs->r4, regs->r5, regs->r6, regs->r7, &res);
+
+    regs->r0 = res.a0;
+    regs->r1 = res.a1;
+    regs->r2 = res.a2;
+    regs->r3 = res.a3;
+}
+
 #else
 
 void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
@@ -251,6 +266,20 @@ void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
             arm_smccc_1_0_smc(__VA_ARGS__);                     \
     } while ( 0 )
 
+/* Make an SMCCC v1.1 compliant SMC call with guest register state. */
+static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
+{
+    struct arm_smccc_res res;
+
+    arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3,
+                      regs->x4, regs->x5, regs->x6, regs->x7, &res);
+
+    regs->x0 = res.a0;
+    regs->x1 = res.a1;
+    regs->x2 = res.a2;
+    regs->x3 = res.a3;
+}
+
 /*
  * struct arm_smccc_1_2_regs - Arguments for or Results from SMC call
  * @a0-a17 argument values from registers 0 to 17
diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c
index 669dd517e057..efb0ad20d6e8 100644
--- a/xen/arch/arm/platforms/imx8m.c
+++ b/xen/arch/arm/platforms/imx8m.c
@@ -50,7 +50,6 @@ static bool imx8m_smc(struct cpu_user_regs *regs)
 {
     uint32_t function_id = get_user_reg(regs, 0);
     uint32_t subfunction_id = get_user_reg(regs, 1);
-    struct arm_smccc_res res;
 
     if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
     {
@@ -122,20 +121,7 @@ static bool imx8m_smc(struct cpu_user_regs *regs)
         return false;
     }
 
-    arm_smccc_1_1_smc(function_id,
-                      subfunction_id,
-                      get_user_reg(regs, 2),
-                      get_user_reg(regs, 3),
-                      get_user_reg(regs, 4),
-                      get_user_reg(regs, 5),
-                      get_user_reg(regs, 6),
-                      get_user_reg(regs, 7),
-                      &res);
-
-    set_user_reg(regs, 0, res.a0);
-    set_user_reg(regs, 1, res.a1);
-    set_user_reg(regs, 2, res.a2);
-    set_user_reg(regs, 3, res.a3);
+    arm_smccc_guest_smc(regs);
 
     return true;
 }
diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c
index 3600a073e8ba..7249e14ab640 100644
--- a/xen/arch/arm/platforms/imx8qm.c
+++ b/xen/arch/arm/platforms/imx8qm.c
@@ -67,7 +67,6 @@ static bool imx8qm_smc(struct cpu_user_regs *regs)
 {
     uint32_t function_id = get_user_reg(regs, 0);
     uint32_t subfunction_id = get_user_reg(regs, 1);
-    struct arm_smccc_res res;
 
     if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
     {
@@ -106,20 +105,7 @@ static bool imx8qm_smc(struct cpu_user_regs *regs)
     }
 
  allow_call:
-    arm_smccc_1_1_smc(function_id,
-                      subfunction_id,
-                      get_user_reg(regs, 2),
-                      get_user_reg(regs, 3),
-                      get_user_reg(regs, 4),
-                      get_user_reg(regs, 5),
-                      get_user_reg(regs, 6),
-                      get_user_reg(regs, 7),
-                      &res);
-
-    set_user_reg(regs, 0, res.a0);
-    set_user_reg(regs, 1, res.a1);
-    set_user_reg(regs, 2, res.a2);
-    set_user_reg(regs, 3, res.a3);
+    arm_smccc_guest_smc(regs);
 
     return true;
 }
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
index 2053ed7ac5f6..326c8a1ba6e5 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -51,7 +51,6 @@ static inline bool domain_has_reset_access(struct domain *d, uint32_t rst)
 
 bool zynqmp_eemi(struct cpu_user_regs *regs)
 {
-    struct arm_smccc_res res;
     uint32_t fid = get_user_reg(regs, 0);
     uint32_t nodeid = get_user_reg(regs, 1);
     unsigned int pm_fn = fid & 0xFFFF;
@@ -187,20 +186,8 @@ bool zynqmp_eemi(struct cpu_user_regs *regs)
      * can forward the whole command to firmware without additional
      * parameters checks.
      */
-    arm_smccc_1_1_smc(get_user_reg(regs, 0),
-                      get_user_reg(regs, 1),
-                      get_user_reg(regs, 2),
-                      get_user_reg(regs, 3),
-                      get_user_reg(regs, 4),
-                      get_user_reg(regs, 5),
-                      get_user_reg(regs, 6),
-                      get_user_reg(regs, 7),
-                      &res);
-
-    set_user_reg(regs, 0, res.a0);
-    set_user_reg(regs, 1, res.a1);
-    set_user_reg(regs, 2, res.a2);
-    set_user_reg(regs, 3, res.a3);
+    arm_smccc_guest_smc(regs);
+
     return true;
 
 done:
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:19:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:19:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403958.1637906 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zW-0007RX-6d; Mon, 31 Aug 2026 12:19:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403958.1637906; Mon, 31 Aug 2026 12:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zW-0007RO-2n; Mon, 31 Aug 2026 12:19:58 +0000
Received: by outflank-mailman (input) for mailman id 1403958;
 Mon, 31 Aug 2026 12:19:56 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x10zU-000777-K5
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:56 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10zT-000RzD-NZ
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:19:55 +0200
Received: from [10.42.69.8] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a95715e-2eae-0a2a0a5409dd-0a2a4508e5ea-28
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:55 +0200
Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com)
 by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a95716b-f659-0a2a45080019-d155dd35d850-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:55 +0200
Received: by mail-wr1-f53.google.com with SMTP id
 ffacd0b85a97d-484392e3d33so700947f8f.2
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:19:55 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48440e094d0sm847709f8f.23.2026.08.31.05.19.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 05:19:54 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.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=citrix.com; s=google; t=1788178795; x=1788783595; 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=keXqSb8JkKc0s5NgPnbFMK+OAKHx91OAcyhTg8jXG0o=;
        b=jC84KEjSs5cKROcpyGtPky3HO4v966WbzNtAdamqFDwpu273B2J91Mg2+DhUbibO2C
         SSIa8gHXZvJf2a5CwGGR4KgWWXgJkqimx1i4CYcht5PtFGJsfxgGk8G1H81H9XUTa3FY
         GD0QW42shM4PAbOL0CEEuSNak4+Ba/c4kSd7o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788178795; x=1788783595;
        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=keXqSb8JkKc0s5NgPnbFMK+OAKHx91OAcyhTg8jXG0o=;
        b=k3sK0kySVMOEB9I+rIE/uD+h9d4sII53XZEWry6Xzh2ciSY8DowrgKU3i5UANWPEfj
         Ax7z5Lz88wNq84drtxeIrD+poY5+4CZBf9UbWQlcNsJK3HJ3vXQuI8yd35InIBYoYGXI
         RXbShFef86PMzxPcBaBfpZ21AwAmt/g1i6Eq/XXut1a5YWs8uhbpB/OhLj+SYWZt5pVp
         yulf2/xfK3YNjaHmal7c7cluEDqGByjqAQsNG48AD9pf9vY08NNFp+xU3y3CRNOBuEdP
         rGM9H+O3ahQycWDvu32Qsj6C2Hh97mTiKykO9xLcS3XJeA9cz4/a4Nw+GgEd66kdfAdW
         8Xpw==
X-Gm-Message-State: AFuF++kHIa+RwXd97EhWoTnVb2C9F/MWg1bJ/yLzKhWQLii3Pq3tHsQt
	58S6OkFJNsd5fDgJbJWHC9/67vz3kvbFKZe8qUXWPGMWJrz8SYHEQYfVQZcBP+E34Mi4KHVbEZr
	XYm3fZVA=
X-Gm-Gg: AYBFou0GhnlNTNLpwDYF25v7c3KM5/gPrNkpAIuBe8gojNsp624iL4l010Kr+9Lk8cP
	lNSX/RkVFyirH2bMKWSHbjCQcI4C+T3N6elkZObXPXpWAjwLO7fJCS/bSr4qZuDFX000jgW9lf4
	93daHdtIe3FFbVeybojB2kGEzTl1ytIUx+oBKFK0bsG5ag0S/Oz87EWO4QK6d6/ZL33aXI10FqT
	ctq/IEaj8C8cIqlD8S81xq0e5cw4v+YUfHSJPmeF3/jXUWlpzN2hJpZYmkL1u9FzQUrnuXyTv4q
	ia5eIV7O/DtoJssRWPBJypDMOr2ZtCeFZGCc0VChRBkDIfUeQaJKZeIrNsigUcsRbxfW9Y2hgpE
	JYLYc2WO+PvBRhars6dlG7Xw/uDuuOJA5PBGVS4Zk43TlIf8WsVYG3atCBwoF/xS64HRJ4fVpwD
	RH8hmRsUfStxRE6YSTXl8mNjmFpTjTwrNljNzBYUflFuOIi4LaaqjzbT/sGiVY/kWm9lUu34Dyi
	QvhSEJliwcpOqbqi70SRCmq142Y2SCJU3IzXjM=
X-Received: by 2002:a05:6000:38f:b0:484:3317:a17 with SMTP id ffacd0b85a97d-48433170b89mr27778382f8f.24.1788178794558;
        Mon, 31 Aug 2026 05:19:54 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [PATCH 3/6] xen/arm: Clean up 32bit arm_smccc_1_1_smc()
Date: Mon, 31 Aug 2026 13:19:42 +0100
Message-Id: <20260831121944.2908139-4-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
References: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c1860d/1788178795-D5F4787B-8DF8300B/0/0
X-purgate-type: clean
X-purgate-size: 5449

... before making a related copy of it.

 * Drop __constraints() so the output parameters are visible in the same block
   as they're defined.  Use PASTE() rather than opencoding it.
 * Adust the indentation of trailing \'s for consistency.
 * Drop the newline at the end of the instruction.
 * Indent the if condition correctly.  ___res is always of type
   arm_smccc_res (declared in __declare_arg_0()), so drop the typeof().
 * Drop arm_smccc_1_0_smc() as it has no users.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
---
 xen/arch/arm/include/asm/smccc.h | 45 ++++++++++++++++----------------
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index 832157f43734..5fe54013ac83 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -56,6 +56,8 @@
 
 #ifndef __ASSEMBLER__
 
+#include <xen/macros.h>
+
 extern uint32_t smccc_ver;
 
 /* Check if this is fast call. */
@@ -115,24 +117,24 @@ struct arm_smccc_res {
  * This is manual register scheduling for the asm() statement, and any other
  * logic to evaluate may clobber the already-scheduled registers.
  */
-#define __declare_arg_0(a0, res)                            \
-    auto __a0 = (uint32_t)(a0);                             \
-    struct arm_smccc_res    *___res = (res);                \
+#define __declare_arg_0(a0, res)                        \
+    auto __a0 = (uint32_t)(a0);                         \
+    struct arm_smccc_res    *___res = (res);            \
     register unsigned long  arg0 ASM_REG(0) = __a0
 
-#define __declare_arg_1(a0, a1, res)                        \
-    auto __a1 = (a1);                                       \
-    __declare_arg_0(a0, res);                               \
+#define __declare_arg_1(a0, a1, res)                    \
+    auto __a1 = (a1);                                   \
+    __declare_arg_0(a0, res);                           \
     register auto           arg1 ASM_REG(1) = __a1
 
-#define __declare_arg_2(a0, a1, a2, res)                    \
-    auto __a2 = (a2);                                       \
-    __declare_arg_1(a0, a1, res);                           \
+#define __declare_arg_2(a0, a1, a2, res)                \
+    auto __a2 = (a2);                                   \
+    __declare_arg_1(a0, a1, res);                       \
     register auto           arg2 ASM_REG(2) = __a2
 
-#define __declare_arg_3(a0, a1, a2, a3, res)                \
-    auto __a3 = (a3);                                       \
-    __declare_arg_2(a0, a1, a2, res);                       \
+#define __declare_arg_3(a0, a1, a2, a3, res)            \
+    auto __a3 = (a3);                                   \
+    __declare_arg_2(a0, a1, a2, res);                   \
     register auto           arg3 ASM_REG(3) = __a3
 
 #define __declare_arg_4(a0, a1, a2, a3, a4, res)        \
@@ -158,12 +160,6 @@ struct arm_smccc_res {
 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
 #define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)
 
-#define ___constraints(count)                       \
-    : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)     \
-    : __constraint_read_ ## count                   \
-    : "memory"
-#define __constraints(count)    ___constraints(count)
-
 /*
  * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call
  *
@@ -189,10 +185,14 @@ struct arm_smccc_res {
         register unsigned long r2 ASM_REG(2);                   \
         register unsigned long r3 ASM_REG(3);                   \
         __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \
-        asm volatile("smc #0\n"                                 \
-                     __constraints(__count_args(__VA_ARGS__))); \
+        asm volatile (                                          \
+            "smc #0"                                            \
+            : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)        \
+            : PASTE(__constraint_read_,                         \
+                    __count_args(__VA_ARGS__))                  \
+            : "memory" );                                       \
         if ( ___res )                                           \
-        *___res = (typeof(*___res)){r0, r1, r2, r3};            \
+            *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \
     } while ( 0 )
 
 /*
@@ -200,7 +200,6 @@ struct arm_smccc_res {
  * v1.1.
  */
 #ifdef CONFIG_ARM_32
-#define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
 #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
 
 /* Make an SMCCC v1.1 compliant SMC call with guest register state. */
@@ -217,7 +216,7 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
     regs->r3 = res.a3;
 }
 
-#else
+#else /* CONFIG_ARM_64 */
 
 void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
                          register_t a3, register_t a4, register_t a5,
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:19:58 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:19:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403959.1637911 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zW-0007Xt-MC; Mon, 31 Aug 2026 12:19:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403959.1637911; Mon, 31 Aug 2026 12:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zW-0007Wl-HK; Mon, 31 Aug 2026 12:19:58 +0000
Received: by outflank-mailman (input) for mailman id 1403959;
 Mon, 31 Aug 2026 12:19:57 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x10zV-0007LP-KG
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10zV-004lvp-0h
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:19:57 +0200
Received: from [10.42.69.9] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a957163-e002-0a2a0a5209dd-0a2a4509a31c-32
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:57 +0200
Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com)
 by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a95716c-be1a-0a2a45090019-d155dd34cd8c-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:56 +0200
Received: by mail-wr1-f52.google.com with SMTP id
 ffacd0b85a97d-47c2b362ee2so2964444f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:19:56 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48440e094d0sm847709f8f.23.2026.08.31.05.19.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 05:19:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.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=citrix.com; s=google; t=1788178796; x=1788783596; 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=PmiQSMZPixZ6AjqLdv2qezZIur3EMHWcw7A7AXRMY8E=;
        b=julaYGgfxZvL1vSMT3Zztt5xs75D1qWygTk37pJvgjnbvwCV3ghHQBpTc9CA9vnfth
         j/zuwFTWOkR1VS+y09VsaxsIZgPEWVWLape0Cs62YVnMcNoTnc/HcwDNCzl76cmNrXkZ
         1M56mSG7a/2mYQr5sStM+fRj6hTnEStKE4ETg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788178796; x=1788783596;
        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=PmiQSMZPixZ6AjqLdv2qezZIur3EMHWcw7A7AXRMY8E=;
        b=R95OfJvAd5Q9EXumA15aMgA3I8p6z6HnQdzKNpO1VQB8Lb5HxW7Hq91OKadl9Lgwh9
         RSjvRME9orIP//cFdRHIP3kReN7gAmu4hCoSr3TeYKEN6JcHwpwhfiQQr/5bxm1oMeP3
         ptGrIcG90tQmDgwaQj24270RrZnmEC/wWzD0VRW51sy8kkIte0KzyAAeF9Vsa3TfTLN3
         +cCKCqW4l2ejLlzE+yJK4QJY5UB3qoHvlz7YgdQxNvTpi7PSC7vJoiJ7S7SQnwCUWe1S
         8K96Kpc2NIKtOju9AHnWTxU5wJ7p2jj1aUiIxOcm1ZwCtjh1qIHgnM1m4jd0JIi3feRj
         tGzA==
X-Gm-Message-State: AFuF++m/gusRMwts54mVA4d61LqhYA/PkHOJfOLX/cfM0dWU/ve0cMCG
	FZh+f78QpKnUXKlC/738dK/XYIabSm7XDPo18NeCS4/FQbfEZMaIO1vweKHL7X4E7qo3mdJAMHO
	Ub5Tg
X-Gm-Gg: AYBFou3DrYm+wHN0CF1cbTM+cX9WKZdZpXpzidTek62fNW/e8Rn3SLL0ta0prLzhs32
	8bUMPvPI3ZJO+GT0mud6IP2TnoRZ2IrWY2AzdMgmexkneZCoe3kSqoCe08fXrtJJXmTol5uV+Z5
	xI95DDeE+YiCK79PdYZix3Mr8njZr1esfX2QCR8IJb8W6+ZjeXB8F767odXt1yretXPRYvzxWo+
	7r8HQgP8kGiQjv56lOQmHmX/CoCZlZj+5ThQF6uCTY4omvpnAETBEjM7khRdub4BkIooqsc9Yyw
	+Dk0QgsYD2uKeGxanXNA2UZLF2/djHSC0pvZFm5bCGZfhFDCSDD2Q0YwhWjyFknthWPGTldwuit
	q4E5vJ7CSLb5+hL1aesmaLA6s05DDTq8VGXJUR7er2OWZT7C7f48qMxNf/NmzoM2Mp1pPcmI4Pe
	F9NJ1ZUYq3uq5zvHxU/7r8p3nYceQL7S0TN0iZRt/FY1qfbSlidQvEL3066DBkZ/l7VXsOjvZ5f
	wyqWkXM76sgZ/83IgbNiAIUUWacr86UOn7aB+A=
X-Received: by 2002:a05:6000:38f:b0:484:3315:1a38 with SMTP id ffacd0b85a97d-48433152785mr26443741f8f.28.1788178795509;
        Mon, 31 Aug 2026 05:19:55 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [PATCH 4/6] xen/arm: Rewrite arm_smccc_smc() for arm64
Date: Mon, 31 Aug 2026 13:19:43 +0100
Message-Id: <20260831121944.2908139-5-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
References: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-bad1c0/1788178796-BC4CB034-8DBD56A9/0/0
X-purgate-type: clean
X-purgate-size: 9682

PSCI v1.0 says that x4 thru x17 may be clobbered.  PSCI v1.1 says they are
strictly preserved unless they contain return values.

Xen deals with this by having __arm_smccc_1_0_smc() as an out-of-line
function, but this causes awful code generation in arm_smccc_smc().
cpus_have_const_cap() is opaque to the optimiser, so we end up with one basic
block doing the reasonably-ok arm_smccc_1_1_smc() code generation and a second
basic block setting up all 8 input registers even when they're not needed,
spilling or discarding x8 thru x17, and calling an out-of-line function.

Remove __arm_smccc_1_0_smc() entirely, and rewrite arm_smccc_smc() to declare
x4 thru x17 as clobbered.

This fully inlines the SMC, is a single basic block which instructs the
compiler to spill or discard the potentially clobbered registers, and only
sets up the necessary number of arguments for the call.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>

Bloat-o-meter reports:

  add/remove: 0/1 grow/shrink: 0/10 up/down: 0/-795 (-795)
  Function                                     old     new   delta
  symbols_sorted_offsets                     23832   23824      -8
  symbols_names                              42962   42943     -19
  symbols_addresses                          35128   35104     -24
  __arm_smccc_1_0_smc                           32       -     -32
  call_psci_cpu_off                            144      76     -68
  seattle_system_reset                          92      16     -76
  seattle_system_off                            92      16     -76
  call_psci_system_reset                       112      32     -80
  call_psci_system_off                         112      32     -80
  call_psci_cpu_on                             252     124    -128
  psci_init                                    628     424    -204

An alternative way to do this would be to have x8 thru x17 in the clobber list
rather than the output list which would reduce the source size, but this form
is more amenable to having PSCI v1.2 worked into it too.
---
 xen/arch/arm/arm64/smc.S         | 16 ------
 xen/arch/arm/include/asm/smccc.h | 95 ++++++++++++++++----------------
 2 files changed, 48 insertions(+), 63 deletions(-)

diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
index 68b05e8ddd12..65b4eabe4f87 100644
--- a/xen/arch/arm/arm64/smc.S
+++ b/xen/arch/arm/arm64/smc.S
@@ -13,22 +13,6 @@
  * GNU General Public License for more details.
  */
 
-/*
- * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
- *                          register_t a3, register_t a4, register_t a5,
- *                          register_t a6, register_t a7,
- *                          struct arm_smccc_res *res)
- */
-FUNC(__arm_smccc_1_0_smc)
-        smc     #0
-        ldr     x4, [sp]
-        cbz     x4, 1f          /* No need to store the result */
-        stp     x0, x1, [x4, #SMCCC_RES_a0]
-        stp     x2, x3, [x4, #SMCCC_RES_a2]
-1:
-        ret
-END(__arm_smccc_1_0_smc)
-
 /*
  * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
  *                        struct arm_smccc_1_2_regs *res)
diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index 5fe54013ac83..8920c54b09a6 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -16,9 +16,6 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
-#include <asm/alternative.h>
-#include <asm/cpufeature.h>
-
 #define SMCCC_VERSION_MAJOR_SHIFT            16
 #define SMCCC_VERSION_MINOR_MASK             \
         ((1U << SMCCC_VERSION_MAJOR_SHIFT) - 1)
@@ -57,6 +54,9 @@
 #ifndef __ASSEMBLER__
 
 #include <xen/macros.h>
+#include <xen/types.h>
+
+#include <asm/asm_defns.h>
 
 extern uint32_t smccc_ver;
 
@@ -160,6 +160,8 @@ struct arm_smccc_res {
 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
 #define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)
 
+#ifdef CONFIG_ARM_32
+
 /*
  * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call
  *
@@ -199,7 +201,6 @@ struct arm_smccc_res {
  * The calling convention for arm32 is the same for both SMCCC v1.0 and
  * v1.1.
  */
-#ifdef CONFIG_ARM_32
 #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
 
 /* Make an SMCCC v1.1 compliant SMC call with guest register state. */
@@ -218,53 +219,53 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
 
 #else /* CONFIG_ARM_64 */
 
-void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
-                         register_t a3, register_t a4, register_t a5,
-                         register_t a6, register_t a7,
-                         struct arm_smccc_res *res);
-
-/* Macros to handle variadic parameter for SMCCC v1.0 helper */
-#define __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, a7, res)  \
-    __arm_smccc_1_0_smc(a0, a1, a2, a3, a4, a5, a6, a7, res)
-
-#define __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, a6, res)  \
-    __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, 0, res)
-
-#define __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, a5, res)  \
-    __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, 0, res)
-
-#define __arm_smccc_1_0_smc_4(a0, a1, a2, a3, a4, res)  \
-    __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, 0, res)
-
-#define __arm_smccc_1_0_smc_3(a0, a1, a2, a3, res)  \
-    __arm_smccc_1_0_smc_4(a0, a1, a2, a3, 0, res)
-
-#define __arm_smccc_1_0_smc_2(a0, a1, a2, res)  \
-    __arm_smccc_1_0_smc_3(a0, a1, a2, 0, res)
-
-#define __arm_smccc_1_0_smc_1(a0, a1, res)  \
-    __arm_smccc_1_0_smc_2(a0, a1, 0, res)
-
-#define __arm_smccc_1_0_smc_0(a0, res)  \
-    __arm_smccc_1_0_smc_1(a0, 0, res)
-
-#define ___arm_smccc_1_0_smc_count(count, ...)    \
-    __arm_smccc_1_0_smc_ ## count(__VA_ARGS__)
-
-#define __arm_smccc_1_0_smc_count(count, ...)   \
-    ___arm_smccc_1_0_smc_count(count, __VA_ARGS__)
-
-#define arm_smccc_1_0_smc(...)                                              \
-        __arm_smccc_1_0_smc_count(__count_args(__VA_ARGS__), __VA_ARGS__)
-
+/*
+ * Make an SMCCC call compatible with both PSCI v1.1 and v1.0.
+ *
+ * PSCI v1.1 says that x4 through x17 are strictly preserved unless they
+ * contain return data.  PSCI v1.0 says they clobbered.
+ *
+ * Xen doesn't make PSCI v1.1 calls which expect more than 4 return registers,
+ * so imply list x4 through x17 as clobbered.
+ */
 #define arm_smccc_smc(...)                                      \
     do {                                                        \
-        if ( cpus_have_const_cap(ARM_SMCCC_1_1) )               \
-            arm_smccc_1_1_smc(__VA_ARGS__);                     \
-        else                                                    \
-            arm_smccc_1_0_smc(__VA_ARGS__);                     \
+        register unsigned long r0  ASM_REG(0);                  \
+        register unsigned long r1  ASM_REG(1);                  \
+        register unsigned long r2  ASM_REG(2);                  \
+        register unsigned long r3  ASM_REG(3);                  \
+        /* Potentially clobbered in PSCI 1.0 */                 \
+        register unsigned long c4  ASM_REG(4);                  \
+        register unsigned long c5  ASM_REG(5);                  \
+        register unsigned long c6  ASM_REG(6);                  \
+        register unsigned long c7  ASM_REG(7);                  \
+        register unsigned long c8  ASM_REG(8);                  \
+        register unsigned long c9  ASM_REG(9);                  \
+        register unsigned long c10 ASM_REG(10);                 \
+        register unsigned long c11 ASM_REG(11);                 \
+        register unsigned long c12 ASM_REG(12);                 \
+        register unsigned long c13 ASM_REG(13);                 \
+        register unsigned long c14 ASM_REG(14);                 \
+        register unsigned long c15 ASM_REG(15);                 \
+        register unsigned long c16 ASM_REG(16);                 \
+        register unsigned long c17 ASM_REG(17);                 \
+        __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \
+        asm volatile (                                          \
+            "smc #0"                                            \
+            : "=r" (r0),  "=r" (r1),  "=r" (r2),  "=r" (r3),    \
+              "=r" (c4),  "=r" (c5),  "=r" (c6),  "=r" (c7),    \
+              "=r" (c8),  "=r" (c9),  "=r" (c10), "=r" (c11),   \
+              "=r" (c12), "=r" (c13), "=r" (c14), "=r" (c15),   \
+              "=r" (c16), "=r" (c17)                            \
+            : PASTE(__constraint_read_,                         \
+                    __count_args(__VA_ARGS__))                  \
+            : "memory" );                                       \
+        if ( ___res )                                           \
+            *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \
     } while ( 0 )
 
+#define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__)
+
 /* Make an SMCCC v1.1 compliant SMC call with guest register state. */
 static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
 {
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:20:00 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:20:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1403961.1637925 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zY-0007su-09; Mon, 31 Aug 2026 12:20:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1403961.1637925; Mon, 31 Aug 2026 12:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x10zX-0007rs-PW; Mon, 31 Aug 2026 12:19:59 +0000
Received: by outflank-mailman (input) for mailman id 1403961;
 Mon, 31 Aug 2026 12:19:58 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper3@citrix.com>) id 1x10zW-0007Rc-Cb
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:19:58 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x10zV-00Dc7p-PE
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:19:57 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a957164-8faa-0a2a0a5109dd-0a2a4507b388-36
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:57 +0200
Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper3@citrix.com>)
 id 6a95716d-b4ea-0a2a45070019-d155dd29c59d-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:19:57 +0200
Received: by mail-wr1-f41.google.com with SMTP id
 ffacd0b85a97d-4843f205a5bso280105f8f.1
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:19:57 -0700 (PDT)
Received: from localhost.localdomain (host-78-146-248-75.as13285.net.
 [78.146.248.75]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-48440e094d0sm847709f8f.23.2026.08.31.05.19.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2026 05:19:55 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.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=citrix.com; s=google; t=1788178797; x=1788783597; 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=sWHVN1KYguuCvFJ0vjo0Hfd/94qGB/JA1/otXXv1BOY=;
        b=GSJfM7hUQYWphHpC9rV673wP2ODDBdewaOui6yWsD0CQMYI354BoBKNYzMdt0JPpVP
         vTlbCrTdN2abFBIuBAE2cZFC1mIULKeHTYqL3pvqvCAYIieW2c2hlQT74MTxxNel2JOt
         0x5SDXO6e3HdpBpXg/8MnIZqMb51+lK83Uqxs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788178797; x=1788783597;
        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=sWHVN1KYguuCvFJ0vjo0Hfd/94qGB/JA1/otXXv1BOY=;
        b=MaB49NmTwHZuiXVrMXRYveCiVnI/dj7WWkYOc1wIrfOh9iBfiTHhFSj9HytevOQNfB
         v1t9k8fGtUw7rS5ckxpjkGnZKNlJKuQt9a5CRRiJt3rOTnnrvhq88I72o/BhNSu6s2E9
         uYaiMq8pRWx7BN7UezwVS5QyJcjpZocg6M3EblA4EM144i/LWr+plVgUm6qRKHdjPK1M
         8bSScCy6MDE0O4ZCtGjF5x7c6egKQGYC/upam2iyodroYhl2kRYSV2nznXrp2IS7JgbU
         oHrljD8Pb5rYDg0cwfH5/pFK+6YukQRfF5T/+SD5yz4M9lolR+wbMtlhgQdZTUScC02P
         MvtQ==
X-Gm-Message-State: AFuF++kI1jK/0t7kJNbp9h5czEswmRWb3ziirUxuXN57JFM9DYBI9EEG
	obJZnFBirwd6MnmzHIIu4veUfja0G/rhog5geM/gAqWrXIxXYsUF5mA85ozMYKtbWuOawzaJMBp
	qzv29
X-Gm-Gg: AYBFou1WtDVtnsZEymZpHeY7VDo70hqiTasoH2/Tf8zl4Dal+4Xextx7E9ij3vfpSok
	6CPd/ZvXwz+dtGEgXdkPjb2O4B/R0Cv50/eHfi0WfWJWEg2QVy+Btu8Bv5zni7zmNtD17Pl2sdt
	i50X8WmzqXmSUUcdBAAzZyfZN+Ajd3xDUMZi5X9gqC+lFRuWhofwWoFwT2BUr2tKcjdsyQM6yYn
	yhzldFT+kT48f/myptmO2RKpUTuSSqqAxPnSScuQdxX39v1b2KWOMbtEVl6wUAg2HvLW6UcGDdF
	E8Mkb9lqsWskrlL7EP2bwqHfJ8AEIVRZy+b6u2P1bAWxSQf4Orxx+kS1kTjmfc0uHS/YTqaLVq9
	xHKltD63ESThHuEkx/ku7lOnUA71kQPC/IYH+fnTKDtFrMsUsfpE/bAx+FA/8BL2ZLSh1jTbGQ2
	m4LfGceDBsRwtD2a+uTIltRJE/zQSUpbzbrS3Eytv9aOrwTPfQ4+ZLZV499wVSItUGWcw55jW9L
	gyzf1UTT0ngaZTWlcc5jrWRJ4Mu5tSzkLWTmH2DMaSlxw9H6YE=
X-Received: by 2002:a05:6000:4a1e:b0:45e:e1a4:c4c3 with SMTP id ffacd0b85a97d-482f79b94f2mr42492389f8f.15.1788178796463;
        Mon, 31 Aug 2026 05:19:56 -0700 (PDT)
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
Subject: [PATCH 5/6] xen/arm: Rewrite arm_smccc_*() to return by value
Date: Mon, 31 Aug 2026 13:19:44 +0100
Message-Id: <20260831121944.2908139-6-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
References: <20260831121944.2908139-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-ef75cf/1788178797-A5EC6AE4-E27D34CC/0/0
X-purgate-type: clean
X-purgate-size: 23654

Use statement expressions to return struct arm_smccc_res which makes the code
read a lot more normally, and avoids needing to pass in NULL in order to skip
return information.

More importantly, it removes the local implementation of __count_args() which
is off by two and deeply confusing to try and follow.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>

Xen compiles identically before and after this change, for both arm32 and arm64.
---
 xen/arch/arm/cpuerrata.c         | 18 +++----
 xen/arch/arm/include/asm/smccc.h | 87 ++++++++++++++------------------
 xen/arch/arm/platforms/exynos5.c |  2 +-
 xen/arch/arm/platforms/seattle.c |  4 +-
 xen/arch/arm/psci.c              | 17 +++----
 xen/arch/arm/tee/optee.c         | 47 +++++++++--------
 xen/arch/arm/traps.c             |  4 +-
 7 files changed, 84 insertions(+), 95 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 3a32183618dc..35ad98d29d14 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -179,8 +179,8 @@ static int enable_smccc_arch_workaround_1(void *data)
     if ( smccc_ver < SMCCC_VERSION(1, 1) )
         goto warn;
 
-    arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
-                      ARM_SMCCC_ARCH_WORKAROUND_1_FID, &res);
+    res = arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+                            ARM_SMCCC_ARCH_WORKAROUND_1_FID);
     /* The return value is in the lower 32-bits. */
     if ( (int)res.a0 < 0 )
         goto warn;
@@ -256,8 +256,8 @@ static int enable_spectre_bhb_workaround(void *data)
         if ( smccc_ver < SMCCC_VERSION(1, 1) )
             goto warn;
 
-        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
-                          ARM_SMCCC_ARCH_WORKAROUND_3_FID, &res);
+        res = arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+                                ARM_SMCCC_ARCH_WORKAROUND_3_FID);
         /* The return value is in the lower 32-bits. */
         if ( (int)res.a0 < 0 )
         {
@@ -398,8 +398,8 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
     if ( smccc_ver < SMCCC_VERSION(1, 1) )
         return false;
 
-    arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
-                      ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
+    res = arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+                            ARM_SMCCC_ARCH_WORKAROUND_2_FID);
 
     switch ( (int)res.a0 )
     {
@@ -429,7 +429,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
     case ARM_SSBD_FORCE_DISABLE:
         printk_once("%s disabled from command-line\n", entry->desc);
 
-        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0);
         required = false;
         break;
 
@@ -437,7 +437,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
         if ( required )
         {
             this_cpu(ssbd_callback_required) = 1;
-            arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+            arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1);
         }
 
         break;
@@ -445,7 +445,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
     case ARM_SSBD_FORCE_ENABLE:
         printk_once("%s forced from command-line\n", entry->desc);
 
-        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1);
         required = true;
         break;
 
diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h
index 8920c54b09a6..ebed2ff7c7d2 100644
--- a/xen/arch/arm/include/asm/smccc.h
+++ b/xen/arch/arm/include/asm/smccc.h
@@ -95,20 +95,14 @@ struct arm_smccc_res {
     unsigned long a3;
 };
 
-/* SMCCC v1.1 implementation madness follows */
-#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x
-
-#define __count_args(...)                               \
-    ___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0)
-
-#define __constraint_read_0 "r" (arg0)
-#define __constraint_read_1 __constraint_read_0, "r" (arg1)
-#define __constraint_read_2 __constraint_read_1, "r" (arg2)
-#define __constraint_read_3 __constraint_read_2, "r" (arg3)
-#define __constraint_read_4 __constraint_read_3, "r" (arg4)
-#define __constraint_read_5 __constraint_read_4, "r" (arg5)
-#define __constraint_read_6 __constraint_read_5, "r" (arg6)
-#define __constraint_read_7 __constraint_read_6, "r" (arg7)
+#define __constraint_read_1 "r" (arg0)
+#define __constraint_read_2 __constraint_read_1, "r" (arg1)
+#define __constraint_read_3 __constraint_read_2, "r" (arg2)
+#define __constraint_read_4 __constraint_read_3, "r" (arg3)
+#define __constraint_read_5 __constraint_read_4, "r" (arg4)
+#define __constraint_read_6 __constraint_read_5, "r" (arg5)
+#define __constraint_read_7 __constraint_read_6, "r" (arg6)
+#define __constraint_read_8 __constraint_read_7, "r" (arg7)
 
 /*
  * Macro arguments MUST be evaluated before being assigned to a register
@@ -117,44 +111,43 @@ struct arm_smccc_res {
  * This is manual register scheduling for the asm() statement, and any other
  * logic to evaluate may clobber the already-scheduled registers.
  */
-#define __declare_arg_0(a0, res)                        \
+#define __declare_arg_1(a0)                             \
     auto __a0 = (uint32_t)(a0);                         \
-    struct arm_smccc_res    *___res = (res);            \
     register unsigned long  arg0 ASM_REG(0) = __a0
 
-#define __declare_arg_1(a0, a1, res)                    \
+#define __declare_arg_2(a0, a1)                         \
     auto __a1 = (a1);                                   \
-    __declare_arg_0(a0, res);                           \
+    __declare_arg_1(a0);                                \
     register auto           arg1 ASM_REG(1) = __a1
 
-#define __declare_arg_2(a0, a1, a2, res)                \
+#define __declare_arg_3(a0, a1, a2)                     \
     auto __a2 = (a2);                                   \
-    __declare_arg_1(a0, a1, res);                       \
+    __declare_arg_2(a0, a1);                            \
     register auto           arg2 ASM_REG(2) = __a2
 
-#define __declare_arg_3(a0, a1, a2, a3, res)            \
+#define __declare_arg_4(a0, a1, a2, a3)                 \
     auto __a3 = (a3);                                   \
-    __declare_arg_2(a0, a1, a2, res);                   \
+    __declare_arg_3(a0, a1, a2);                        \
     register auto           arg3 ASM_REG(3) = __a3
 
-#define __declare_arg_4(a0, a1, a2, a3, a4, res)        \
+#define __declare_arg_5(a0, a1, a2, a3, a4)             \
     auto __a4 = (a4);                                   \
-    __declare_arg_3(a0, a1, a2, a3, res);               \
+    __declare_arg_4(a0, a1, a2, a3);                    \
     register auto           arg4 ASM_REG(4) = __a4
 
-#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)    \
+#define __declare_arg_6(a0, a1, a2, a3, a4, a5)         \
     auto __a5 = (a5);                                   \
-    __declare_arg_4(a0, a1, a2, a3, a4, res);           \
+    __declare_arg_5(a0, a1, a2, a3, a4);                \
     register auto           arg5 ASM_REG(5) = __a5
 
-#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)    \
-    auto __a6 = (a6);                                       \
-    __declare_arg_5(a0, a1, a2, a3, a4, a5, res);           \
+#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6)     \
+    auto __a6 = (a6);                                   \
+    __declare_arg_6(a0, a1, a2, a3, a4, a5);            \
     register auto           arg6 ASM_REG(6) = __a6
 
-#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)    \
-    auto __a7 = (a7);                                           \
-    __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);           \
+#define __declare_arg_8(a0, a1, a2, a3, a4, a5, a6, a7) \
+    auto __a7 = (a7);                                   \
+    __declare_arg_7(a0, a1, a2, a3, a4, a5, a6);        \
     register auto           arg7 ASM_REG(7) = __a7
 
 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
@@ -181,21 +174,20 @@ struct arm_smccc_res {
  * makes it stick.
  */
 #define arm_smccc_1_1_smc(...)                                  \
-    do {                                                        \
+    ({                                                          \
         register unsigned long r0 ASM_REG(0);                   \
         register unsigned long r1 ASM_REG(1);                   \
         register unsigned long r2 ASM_REG(2);                   \
         register unsigned long r3 ASM_REG(3);                   \
-        __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \
+        __declare_args(count_args(__VA_ARGS__), __VA_ARGS__);   \
         asm volatile (                                          \
             "smc #0"                                            \
             : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)        \
             : PASTE(__constraint_read_,                         \
-                    __count_args(__VA_ARGS__))                  \
+                    count_args(__VA_ARGS__))                    \
             : "memory" );                                       \
-        if ( ___res )                                           \
-            *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \
-    } while ( 0 )
+        (struct arm_smccc_res){ r0, r1, r2, r3 };               \
+    })
 
 /*
  * The calling convention for arm32 is the same for both SMCCC v1.0 and
@@ -208,8 +200,8 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
 {
     struct arm_smccc_res res;
 
-    arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3,
-                      regs->r4, regs->r5, regs->r6, regs->r7, &res);
+    res = arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3,
+                            regs->r4, regs->r5, regs->r6, regs->r7);
 
     regs->r0 = res.a0;
     regs->r1 = res.a1;
@@ -229,7 +221,7 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
  * so imply list x4 through x17 as clobbered.
  */
 #define arm_smccc_smc(...)                                      \
-    do {                                                        \
+    ({                                                          \
         register unsigned long r0  ASM_REG(0);                  \
         register unsigned long r1  ASM_REG(1);                  \
         register unsigned long r2  ASM_REG(2);                  \
@@ -249,7 +241,7 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
         register unsigned long c15 ASM_REG(15);                 \
         register unsigned long c16 ASM_REG(16);                 \
         register unsigned long c17 ASM_REG(17);                 \
-        __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \
+        __declare_args(count_args(__VA_ARGS__), __VA_ARGS__);   \
         asm volatile (                                          \
             "smc #0"                                            \
             : "=r" (r0),  "=r" (r1),  "=r" (r2),  "=r" (r3),    \
@@ -258,11 +250,10 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
               "=r" (c12), "=r" (c13), "=r" (c14), "=r" (c15),   \
               "=r" (c16), "=r" (c17)                            \
             : PASTE(__constraint_read_,                         \
-                    __count_args(__VA_ARGS__))                  \
+                    count_args(__VA_ARGS__))                    \
             : "memory" );                                       \
-        if ( ___res )                                           \
-            *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \
-    } while ( 0 )
+        (struct arm_smccc_res){ r0, r1, r2, r3 };               \
+    })
 
 #define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__)
 
@@ -271,8 +262,8 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs)
 {
     struct arm_smccc_res res;
 
-    arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3,
-                      regs->x4, regs->x5, regs->x6, regs->x7, &res);
+    res = arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3,
+                            regs->x4, regs->x5, regs->x6, regs->x7);
 
     regs->x0 = res.a0;
     regs->x1 = res.a1;
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index f7c09520675e..f08d50c1fe38 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -249,7 +249,7 @@ static int exynos5_cpu_up(int cpu)
     iounmap(power);
 
     if ( secure_firmware )
-        arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu, NULL);
+        arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu);
 
     return cpu_up_send_sgi(cpu);
 }
diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c
index 64cc1868c24b..dfa5cf4265c0 100644
--- a/xen/arch/arm/platforms/seattle.c
+++ b/xen/arch/arm/platforms/seattle.c
@@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst =
  */
 static void seattle_system_reset(void)
 {
-    arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL);
+    arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET);
 }
 
 static void seattle_system_off(void)
 {
-    arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL);
+    arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF);
 }
 
 PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index b6860a776031..634d0d7467cf 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -41,8 +41,8 @@ int call_psci_cpu_on(int cpu)
 {
     struct arm_smccc_res res;
 
-    arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_secondary),
-                  &res);
+    res = arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
+                        __pa(init_secondary));
 
     return PSCI_RET(res);
 }
@@ -54,7 +54,7 @@ void call_psci_cpu_off(void)
         struct arm_smccc_res res;
 
         /* If successfull the PSCI cpu_off call doesn't return */
-        arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF, &res);
+        res = arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF);
         panic("PSCI cpu off failed for CPU%d err=%d\n", smp_processor_id(),
               PSCI_RET(res));
     }
@@ -63,13 +63,13 @@ void call_psci_cpu_off(void)
 void call_psci_system_off(void)
 {
     if ( psci_ver > PSCI_VERSION(0, 1) )
-        arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL);
+        arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF);
 }
 
 void call_psci_system_reset(void)
 {
     if ( psci_ver > PSCI_VERSION(0, 1) )
-        arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL);
+        arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET);
 }
 
 static int __init psci_features(uint32_t psci_func_id)
@@ -79,7 +79,7 @@ static int __init psci_features(uint32_t psci_func_id)
     if ( psci_ver < PSCI_VERSION(1, 0) )
         return PSCI_NOT_SUPPORTED;
 
-    arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, &res);
+    res = arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id);
 
     return PSCI_RET(res);
 }
@@ -116,9 +116,8 @@ static void __init psci_init_smccc(void)
 
     if ( psci_features(ARM_SMCCC_VERSION_FID) != PSCI_NOT_SUPPORTED )
     {
-        struct arm_smccc_res res;
+        struct arm_smccc_res res = arm_smccc_smc(ARM_SMCCC_VERSION_FID);
 
-        arm_smccc_smc(ARM_SMCCC_VERSION_FID, &res);
         if ( PSCI_RET(res) != ARM_SMCCC_NOT_SUPPORTED )
             smccc_ver = PSCI_RET(res);
     }
@@ -191,7 +190,7 @@ static int __init psci_init_0_2(void)
         }
     }
 
-    arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION, &res);
+    res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION);
     psci_ver = PSCI_RET(res);
 
     /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 3d2633237074..e38223d49801 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -178,7 +178,7 @@ static bool optee_probe(void)
         return false;
 
     /* Check UID */
-    arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), &resp);
+    resp = arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END));
 
     if ( (uint32_t)resp.a0 != OPTEE_MSG_UID_0 ||
          (uint32_t)resp.a1 != OPTEE_MSG_UID_1 ||
@@ -209,7 +209,7 @@ static bool optee_probe(void)
      * call. It will return OPTEE_SMC_RETURN_UNKNOWN_FUNCTION if
      * OP-TEE have no virtualization support enabled.
      */
-    arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0, &resp);
+    resp = arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0);
     if ( resp.a0 == OPTEE_SMC_RETURN_UNKNOWN_FUNCTION )
         return false;
 
@@ -243,8 +243,8 @@ static int optee_domain_init(struct domain *d)
      *
      * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_smc()
      */
-    arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0,
-                  &resp);
+    resp = arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d),
+                         0, 0, 0, 0, 0, 0);
     if ( resp.a0 != OPTEE_SMC_RETURN_OK )
     {
         printk(XENLOG_WARNING "%pd: Unable to create OPTEE client: rc = 0x%X\n",
@@ -681,8 +681,8 @@ static int optee_relinquish_resources(struct domain *d)
      *
      * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_smc()
      */
-    arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0,
-                  &resp);
+    resp = arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d),
+                         0, 0, 0, 0, 0, 0);
 
     ASSERT(!spin_is_locked(&ctx->lock));
     ASSERT(!atomic_read(&ctx->call_count));
@@ -1171,15 +1171,14 @@ static void do_call_with_arg(struct optee_domain *ctx,
 {
     struct arm_smccc_res res;
 
-    arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, OPTEE_CLIENT_ID(current->domain),
-                  &res);
+    res = arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, OPTEE_CLIENT_ID(current->domain));
 
     if ( OPTEE_SMC_RETURN_IS_RPC(res.a0) )
     {
         while ( handle_rpc_return(ctx, &res, regs, call)  == -ERESTART )
         {
-            arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, 0,
-                          OPTEE_CLIENT_ID(current->domain), &res);
+            res = arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, 0,
+                                OPTEE_CLIENT_ID(current->domain));
 
             if ( !OPTEE_SMC_RETURN_IS_RPC(res.a0) )
                 break;
@@ -1619,8 +1618,8 @@ static void handle_exchange_capabilities(struct cpu_user_regs *regs)
     caps = get_user_reg(regs, 1);
     caps &= OPTEE_KNOWN_NSEC_CAPS;
 
-    arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, 0, 0, 0,
-                  OPTEE_CLIENT_ID(current->domain), &resp);
+    resp = arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, 0, 0, 0,
+                         OPTEE_CLIENT_ID(current->domain));
     if ( resp.a0 != OPTEE_SMC_RETURN_OK ) {
         set_user_reg(regs, 0, resp.a0);
         return;
@@ -1664,8 +1663,8 @@ static bool optee_handle_call(struct cpu_user_regs *regs)
         return true;
 
     case OPTEE_SMC_CALLS_UID:
-        arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0,
-                      OPTEE_CLIENT_ID(current->domain), &resp);
+        resp = arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0,
+                             OPTEE_CLIENT_ID(current->domain));
         set_user_reg(regs, 0, resp.a0);
         set_user_reg(regs, 1, resp.a1);
         set_user_reg(regs, 2, resp.a2);
@@ -1673,15 +1672,15 @@ static bool optee_handle_call(struct cpu_user_regs *regs)
         return true;
 
     case OPTEE_SMC_CALLS_REVISION:
-        arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0,
-                      OPTEE_CLIENT_ID(current->domain), &resp);
+        resp = arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0,
+                             OPTEE_CLIENT_ID(current->domain));
         set_user_reg(regs, 0, resp.a0);
         set_user_reg(regs, 1, resp.a1);
         return true;
 
     case OPTEE_SMC_CALL_GET_OS_UUID:
-        arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0, 0,
-                      OPTEE_CLIENT_ID(current->domain),&resp);
+        resp = arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0, 0,
+                             OPTEE_CLIENT_ID(current->domain));
         set_user_reg(regs, 0, resp.a0);
         set_user_reg(regs, 1, resp.a1);
         set_user_reg(regs, 2, resp.a2);
@@ -1689,21 +1688,21 @@ static bool optee_handle_call(struct cpu_user_regs *regs)
         return true;
 
     case OPTEE_SMC_CALL_GET_OS_REVISION:
-        arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, 0, 0, 0,
-                      OPTEE_CLIENT_ID(current->domain), &resp);
+        resp = arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, 0, 0, 0,
+                             OPTEE_CLIENT_ID(current->domain));
         set_user_reg(regs, 0, resp.a0);
         set_user_reg(regs, 1, resp.a1);
         return true;
 
     case OPTEE_SMC_ENABLE_SHM_CACHE:
-        arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
-                      OPTEE_CLIENT_ID(current->domain), &resp);
+        resp = arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+                             OPTEE_CLIENT_ID(current->domain));
         set_user_reg(regs, 0, resp.a0);
         return true;
 
     case OPTEE_SMC_DISABLE_SHM_CACHE:
-        arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
-                      OPTEE_CLIENT_ID(current->domain), &resp);
+        resp = arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+                             OPTEE_CLIENT_ID(current->domain));
         set_user_reg(regs, 0, resp.a0);
         if ( resp.a0 == OPTEE_SMC_RETURN_OK ) {
             free_shm_rpc(ctx,  regpair_to_uint64(resp.a1, resp.a2));
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 625d229396bb..6a5dcef2aa87 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1991,7 +1991,7 @@ void asmlinkage enter_hypervisor_from_guest_preirq(void)
 
     /* If the guest has disabled the workaround, bring it back on. */
     if ( needs_ssbd_flip(v) )
-        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1);
 }
 
 /*
@@ -2334,7 +2334,7 @@ void asmlinkage leave_hypervisor_to_guest(void)
      * If the guest wants it disabled, so be it...
      */
     if ( needs_ssbd_flip(current) )
-        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+        arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0);
 }
 
 /*
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:42:42 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:42:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404008.1637933 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11LQ-0005W6-Px; Mon, 31 Aug 2026 12:42:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404008.1637933; Mon, 31 Aug 2026 12:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11LQ-0005Vz-Ms; Mon, 31 Aug 2026 12:42:36 +0000
Received: by outflank-mailman (input) for mailman id 1404008;
 Mon, 31 Aug 2026 12:42:35 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1x11LP-0005Vt-87
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:42:35 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11LO-00B6s1-L0
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:42:34 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9576b6-bab6-0a2a0a5309dd-0a2a4502a344-8
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:42:34 +0200
Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <oleksii.kurochko@gmail.com>)
 id 6a9576ba-6ca4-0a2a45020019-d155802dd862-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:42:34 +0200
Received: by mail-wm1-f45.google.com with SMTP id
 5b1f17b1804b1-49b0d78a801so26437595e9.2
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:42:34 -0700 (PDT)
Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl.
 [109.243.144.234]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-49cd2e9d9fcsm210772965e9.1.2026.08.31.05.42.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2026 05:42:33 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20251104; t=1788180154; x=1788784954; darn=lists.xenproject.org;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=JX4wfgIZoKCCoWRsq2wssTRFX2998HO8fvEa99luS08=;
        b=W1Y0rB1wuhXZOu+df/8AgURrVwkkq8D8VmXXoas1IeFeGmpOnQgiHRE5E16JmJe2Ao
         okylrTOYe5ZV82mobIToPJCdD3TODdZYatF/aq3ozmfdBQuLPuG7wwaUQK+e1RAkgtk8
         tyoMunG0d2gjqlgBxBL9UCDrEVkyE7mkBSzFnDWbeAXFIUrd5KZDuYR8uGK3Wv0hncpo
         00dzDNcJoSKFr36sLjEQWeopDn8VQyc7L5phbhdmT7kHVrbaS0uybBwmlY21eOa23eaZ
         23Z3GX5LrSho61nBKezK79RSzhVDiPmoma1jT33uc00ShwtLJc8JuEmq+rWQ5dThNjH3
         3/OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788180154; x=1788784954;
        h=content-transfer-encoding:content-type:in-reply-to:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to:content-type;
        bh=JX4wfgIZoKCCoWRsq2wssTRFX2998HO8fvEa99luS08=;
        b=m9mWPhzGeyKkJK2klmUcg8HAP4S1LLtyWT/N8BlMHykzeFvf6l+BY0ze0db+hvyA00
         /981y+GZvBknJxyRKNwCF7c4RMg0iMoWS6uEW+pYsFuZ15N9yHckSiwAuGgYrPdFE1th
         8LSrkveIfd1mnqj2wBJTE82LL6RjKVpObZxES7a6bGcQK0GuK/0AOCtnOxEd3O98/Q/G
         ElNwN9oy0NL31ZMMp6rokflvBRGLrqBCTMLEOkRQI34EkVUdnP2OzRgcoswspYV4VUmO
         VXkjY+QjTZ+cmPg+HIwHXj3oEWyWqwFjkZe9iwmVCZ+gmiBqpjZc1GBPuaTk3JFowmeq
         P/0g==
X-Forwarded-Encrypted: i=1; AHgh+RrgKFevVKCSS9cZa+HBZI6V/WrIRTQr80mNxLGtSEMEBSG2bOGBVV1M70SOGeJl8qgwFFnE/W8uqhE=@lists.xenproject.org
X-Gm-Message-State: AFuF++nF7GUwtMH9OBTR+Ck2oYarI4R0VLPCmUSshAXkw8vlq7O0Jdwk
	yGiFVzYE1IJi3I4sVNUefMgbR/nwKyUAEVARtSgv7tZxJKOmp6IyMtWA
X-Gm-Gg: AR+sD11zW5gk5jeS5yAxj/rA9zH2k65GeuY2uKfTYrKVd06xXBoc2iF1bKBWKTMuaaW
	tn3kP24fQk7S/+VfYzGA/d35skJWqZdnks8rj3HlWmSJpbTAya1wd7OzfVyWsrbWnEZngdKYoqA
	ai95Yzyei0PyELYL49866SmhG1WVqodaW41b1Z4h5D9scz2AL/rIFPID2Mo8Dp8jeZ6be3GMEjh
	EnEiVpmbzvkaGDvvzLEHTG1i1zlri7I1I/cQNorePMvcc6do95iXWnNbm4fvT9MlccLL4JG2sSc
	a+bVIMsLosVjonF9L7xpltWNbmlbRXQbBWHHTFmgH8PaHPFIcWyx0aVFkdnyh2WqgcADM/h3g3O
	YtDfJkibCXCnYsYCM4MFakrS41bml9pcZWIIhXpApLxDjJq/08rZSQbYIla4B7X+F6juG8PFPXs
	GEMh5Z+knqfxMhyfdCVH0xYRFNlgcRvkBV94ks2Gw2B/dHZnWEGNO0BWpv6Q5mlpzU4KkLk40ZZ
	TlDludQUgA1k65dlmzQwEyx67L/5C9uh+gneHLUxQ==
X-Received: by 2002:a05:600c:8581:b0:499:a760:722f with SMTP id 5b1f17b1804b1-49b91c47bf8mr326368655e9.13.1788180153954;
        Mon, 31 Aug 2026 05:42:33 -0700 (PDT)
Message-ID: <91ffbf33-0b54-406f-b91f-1a96afc616d7@gmail.com>
Date: Mon, 31 Aug 2026 14:42:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 04/39] xen/riscv: introduce csr_read64()
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xenproject.org
Cc: Romain Caritey <Romain.Caritey@microchip.com>,
 Baptiste Le Duc <baptiste.le-duc@vates.tech>,
 Zheng Zhang <zhangzheng@iscas.ac.cn>,
 Alistair Francis <alistair.francis@wdc.com>,
 Connor Davis <connojdavis@gmail.com>,
 Anthony PERARD <anthony.perard@vates.tech>,
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>,
 Julien Grall <julien@xen.org>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>, Stefano Stabellini <sstabellini@kernel.org>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <0f7080ea4dc86a8bb3dae39d94e5b03e95d010c0.1787838835.git.oleksii.kurochko@gmail.com>
 <aded3bc6-6d5c-4c3f-879a-be428a8ad36a@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In-Reply-To: <aded3bc6-6d5c-4c3f-879a-be428a8ad36a@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-720697/1788180154-F24B62AC-3867FA3F/10/73395122804
X-purgate-type: spam
X-purgate-size: 2287



On 8/27/26 5:36 PM, Andrew Cooper wrote:
> On 27/08/2026 4:20 pm, Oleksii Kurochko wrote:
>> 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 hardware
>> + * 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_ = csr_read(csr ## H);               \
>> +        lo_ = csr_read(csr);                    \
>> +    } while ( hi_ != csr_read(csr ## H) );      \
>> +                                                \
>> +    ((uint64_t)hi_ << 32) | lo_;                \
>> +})
> 
> This double reads H in the looping case.  You want something more like:
> 
> hi = csr_read();
> do {
>      old = hi;
>      lo = csr_read();
> } while ( (hi = csr_read()) != old );

Good point. I'll apply that.

> 
> 
> Still, this only matters for volatile CSRs, and is unnecessary in the
> general case.  I'd suggest naming it csr_volatile_read64(). 

Yes, that makes sense. I will rename it to csr_volatile_read64().

> Most CSRs
> can use a simple split access.

I may have misunderstood you here, but wouldn't it still make sense to 
have a macro covering the case where a register is 64-bit on RV32 yet 
accessed through two CSRs? VSIE and VSIEH, for example.

My plan was to use a single csr_read64() (but while loop then really 
isn't needed in this case) call to abstract the access to VSIE, so that 
the code looks the same on RV32 and RV64.

Does that make sense, or would it be better to have separate vsie and 
vsieh fields instead?

~ Oleksii


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:48:35 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404015.1637942 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11R9-0006Lj-Cm; Mon, 31 Aug 2026 12:48:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404015.1637942; Mon, 31 Aug 2026 12:48:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11R9-0006Lc-9Y; Mon, 31 Aug 2026 12:48:31 +0000
Received: by outflank-mailman (input) for mailman id 1404015;
 Mon, 31 Aug 2026 12:48:29 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1x11R6-0006LW-Te
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:48:29 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11R5-000Y54-M4
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:48:27 +0200
Received: from [10.42.69.1] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1d04000c4f3@swg.vates.tech>)
 id 6a957800-bab6-0a2a0a5309dd-0a2a4501e774-40
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:27 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1d04000c4f3@swg.vates.tech>)
 id 6a95781b-5984-0a2a45010019-b9ff1c22a201-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:27 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a057dd1d04000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 12:48:23 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 1879483CFC;
 Mon, 31 Aug 2026 14:48:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=V5Za1xWUf0cdkSxUkliHIR0yyS8TVB5Whrd6KoNKmks=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=Q7auUekvl/kZVW0MzCtV4m/XMa/KHC3Nja76vEQYlR0DispAYHqyhZs6LqCcsfdFoY+WTguzD
 prwQJjppFn9qIsfwbdY42J+KcvIRavFOfAxzinrEdqseP6mgJJSKRqdQgMj4DGkQdnU5ZXFO9Ab
 1R60pryildNSiAyYMNExNGBswFSB7y8I6N5/6QzcIgasqRL9XmS6deTY//vvHddfjJIv7wf3ePA
 iKmtCdMq2qSYpesmc0c5wd7I9BMZswILhGGKKuxOFNpFsPZ/bE78AEneU/Ma3b86c0BUTM+rlCl
 C1nf7ZPCwEzn+66XDPvpSnkZXEwx2+Z8I7N0OTk09Pxg==
X-Zone-Loop: 5a8287f85aa438c60bd38cbe7cdfa01743963bad75c8
x-campaign-type: default
x-transaction-id: b4e6dea1-4e34-4ff4-a5ba-5a56d5bc14e8
x-swg-uid: 01-337b4cb0-7e91-482d-8693-744fdb3432b3
X-Mailer: Sweego
Message-ID:
 <1788180503.8631fc262581453bbf619ec5b2062170.1a057dd1d04000c4f3@vates.tech>
x-swg-bid: 1788180503.8631fc262581453bbf619ec5b2062170.1a057dd1d04000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v2 01/39] xen/riscv: drop pregs from struct
 cpu_user_regs
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Zheng Zhang <zhangzheng@iscas.ac.cn>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <0dc967fc4bba2dfd97a9c9ea6e60e4d5be3538ff.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <0dc967fc4bba2dfd97a9c9ea6e60e4d5be3538ff.1787838835.git.oleksii.kurochko@gmail.com>
Date: Mon, 31 Aug 2026 14:48:15 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788180503; l=363;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=ubqMEZth2wl+G+/1uOQKmwEsmIs0qRITxz91xImt5co=;
 b=oWjiZmfOwrtpNkviXFGKB6QddxwJ65MjPKdKCUwID/WTLAQeI6ElBBCXP++A4C9XyF0ZDlJP0
 a+Fo6NqDFc2DCrhkbaPGnmkfvINYeycg+G7JkSwNDL/C3OHHPntw3mR
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788180503307
X-purgate-ID: tlsNG-d62444/1788180507-BE27A757-7FAE865E/10/73395122804
X-purgate-type: spam
X-purgate-size: 363

On Thu, 27 Aug 2026 17:20:45 +0200, Oleksii Kurochko <oleksii.kurochko@gmail.com> wrote:
> 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.

Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:48:38 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:48:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404016.1637951 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RG-0006Zk-IK; Mon, 31 Aug 2026 12:48:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404016.1637951; Mon, 31 Aug 2026 12:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RG-0006Zd-FK; Mon, 31 Aug 2026 12:48:38 +0000
Received: by outflank-mailman (input) for mailman id 1404016;
 Mon, 31 Aug 2026 12:48:36 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1x11RE-0006Yy-H2
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:48:36 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11RD-00Dh0a-Fi
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:48:35 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1e4c000c4f3@swg.vates.tech>)
 id 6a957805-8faa-0a2a0a5109dd-0a2a450be97e-34
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:35 +0200
Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1e4c000c4f3@swg.vates.tech>)
 id 6a957822-b7e8-0a2a450b0019-b9ff1c129c53-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:34 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a057dd1e4c000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 12:48:24 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 7E5B683D11;
 Mon, 31 Aug 2026 14:48:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=EOuLCnnMzdC6UbIsBnrHPPyIqp1u/156zXfrES2mmZs=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=obYodD+Hql/B6ziGAVpsbrTo3BpLxpHEx/XuJph81K0WKaHfooZe4FgFV+Zz6tuQcX0bMiCKQ
 oE2Uoo8Cgmvula9XwdlNORyrx7d8uUaUQBJe05slILIzMG9R8kXds0QMWkcX87oZrGGAuodYJ3d
 rv9XwEhdjcSEz4b19JXbh0QIuRLfow2SNnKAvjf5TPYnirLau1c+eKBAedd4sd5gflMLLJLZ8eo
 /Fp0Box29TL1DthOKLqXESd5dxQIoQMpFJ0dEhq0ZIl5mo01dzbvMCV4mtTX2UVMnee36fjJpzc
 Zd1XB/f+clWRabBbfPdIH7vVslQDN87MgSgcITuGVDsQ==
X-Zone-Loop: 278a4888d7b17e3db4140b556059505f75116c88308d
x-campaign-type: default
x-transaction-id: e49872d1-2edb-445c-8fc5-6ef3f90d3db5
x-swg-uid: 01-74358d06-6299-455c-bbf9-ca3dac17eb5f
X-Mailer: Sweego
Message-ID:
 <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1e4c000c4f3@vates.tech>
x-swg-bid: 1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1e4c000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction
 length helpers
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Zheng Zhang <zhangzheng@iscas.ac.cn>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com>
Date: Mon, 31 Aug 2026 14:48:15 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788180503; l=470;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=vt7iWQzfVTqTPvlN2lvgu7IvQBV8ot4bkuc1bMzCk6w=;
 b=zQgLOqefNz0XV0VS8LYzeo28vp2+a4po0aagsNNnWaIHU3aZPEyFOyIrEHxkib1qSWi6ossAU
 YEiyJ2HLfwBBILzsa7+H9Yj4HVOJxFnXlhYvifP6ft4ytulUXAr/LtO
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788180503712
X-purgate-ID: tlsNG-42698a/1788180514-ABAD09EA-977A812C/10/73395122804
X-purgate-type: spam
X-purgate-size: 470

On Thu, 27 Aug 2026 17:20:46 +0200, Oleksii Kurochko <oleksii.kurochko@gmail.com> wrote:
> 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.
> 
> 
> [...]

Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:48:40 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:48:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404017.1637960 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RI-0006o5-QW; Mon, 31 Aug 2026 12:48:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404017.1637960; Mon, 31 Aug 2026 12:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RI-0006ny-Nb; Mon, 31 Aug 2026 12:48:40 +0000
Received: by outflank-mailman (input) for mailman id 1404017;
 Mon, 31 Aug 2026 12:48:40 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@swg.vates.tech>)
 id 1x11RI-0006n0-0L
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:48:40 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11RH-004rdd-D3
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:48:39 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@swg.vates.tech>)
 id 6a95780b-8faa-0a2a0a5109dd-0a2a45038ce0-48
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:39 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@swg.vates.tech>)
 id 6a957827-fae8-0a2a45030019-b9ff1c22b055-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:39 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a057dd1f6a000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 12:48:24 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id C7F4783D12;
 Mon, 31 Aug 2026 14:48:23 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=iTP7ioyiuATUIOtbT9vPJpbBDNJoX+0JSHEIbgOw2Hw=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=JaswFGLLToKfd0RSNrpGUlco8cE66FfSTneenwBeaNsPVUWPHamB7WCR/7fD/ilor66V1smP8
 eqO6JGEqImq9AdrhN6MI4h7xMk6T44MEVB06WGOcHkbcOUE3nttgavIsfngZFgSPVDS61YR2tgZ
 sB4mFPs3JH/P1x3HJ43jtYXmEaYL+7wLMWzGYyMrP+FyBCNOEv4q82oL6qom0a9rDiSN+orL3gs
 eAP5INk4sqpPiA3Tur8YIrlIDVgivm9KwlfC0BQUPk55OmDQos5OWg3MFirUfXZwxXT6A5qw09T
 vIq9JSRbEnSz3PemSd77zyX/omdc3GS9+eHMkh2DWyOQ==
X-Zone-Loop: 2a7af4e8af5dc6d3bb48e3ff4db57c1a9dc2e93edd2b
x-campaign-type: default
x-transaction-id: d09dcaa4-28bb-4801-8fbf-5e912842dbe1
x-swg-uid: 01-600da7e0-382e-4434-863b-7efce76a03f4
X-Mailer: Sweego
Message-ID:
 <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech>
x-swg-bid: 1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in
 hstatus.VSXL
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Zheng Zhang <zhangzheng@iscas.ac.cn>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <a3ae79823e24f2e18cef2fac8ffffe7caa608f32.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <a3ae79823e24f2e18cef2fac8ffffe7caa608f32.1787838835.git.oleksii.kurochko@gmail.com>
Date: Mon, 31 Aug 2026 14:48:15 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788180503; l=980;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=KqinoC4UhW8MbyNZhyMxvV8DmBrnVN090FPgL6BPSgw=;
 b=FIYkApEwUxHaH64nkW+C7dK5ibTPmXX7IMQM83uSasteyTPXdsAS2Myc830ASA57CAw5wlQ0k
 1KayuXfqDabBOtxaGededP6bb4wLp3Cn0Xe+D/kaUkv+EgJOCSECUpK
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788180504018
X-purgate-ID: tlsNG-33051d/1788180519-764FC4E9-2842D15E/0/0
X-purgate-type: clean
X-purgate-size: 980

> 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=64 only must not be recognized for a 32-bit one.
>
It's not clear which instruction "decoding a trapped instruction" refers
to without more context. I assume you mean decode_ldst_insn() in
emulate.c, but the patch introducing that function comes later in the
series, so this isn't obvious on a first read.

Please reorder the series so this patch follows the one introducing
decode_ldst_insn(), or reference it explicitly in the commit message
(e.g. "load/store trap emulation, introduced later in this series in
emulate.c, needs...").

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:48:45 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:48:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404018.1637969 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RN-000753-1a; Mon, 31 Aug 2026 12:48:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404018.1637969; Mon, 31 Aug 2026 12:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RM-00074s-UK; Mon, 31 Aug 2026 12:48:44 +0000
Received: by outflank-mailman (input) for mailman id 1404018;
 Mon, 31 Aug 2026 12:48:43 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1x11RL-00073N-Ke
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:48:43 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11RK-002pbO-Tq
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:48:42 +0200
Received: from [10.42.69.3] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd2094000c4f3@swg.vates.tech>)
 id 6a957827-e002-0a2a0a5209dd-0a2a4503ab1a-16
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:42 +0200
Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net)
 by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd2094000c4f3@swg.vates.tech>)
 id 6a957827-fae8-0a2a45030019-b9ff1c22b055-4
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:42 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a057dd2094000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 12:48:24 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 1EEA783CFC;
 Mon, 31 Aug 2026 14:48:24 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=BYL8kIpKDarsUrP0O12A/cc5cfoGbL2BvOxhdgwIPHY=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=HArNsmhHWDtqFNYvEgojbXnd0ZCo2ItZstC6LXMN8pWHFm6MLbgrdFDL6Yg/kuRos94zvlWjy
 kpLD3LcHKx2fa5Pe08iCAWOdltndc5/y58+ew9Axxh0/TRWprFR8dpbdVN0INWJcVViiBjV+Zrm
 YfiG7tWsYA1mry+573bYS+MKYzEO/L0I5p8A8WWCBOzPeQncCUtWZ0DDlxcXT1/HHv6fELsUYMS
 0rlm6UgyP4Am4aC90PG4038sL43X3rx0cRxtRr7VL/DkErSAQ+QPmFuuekL7+Okb6T3qHQ8foae
 H5nni6Dt05voi8yYGia03KUhen7f5NZUWNTIUpJSU9sg==
X-Zone-Loop: 9778d859340bd3b39004e0146d07adec767a7d1a60cc
x-campaign-type: default
x-transaction-id: 803cc469-1aab-4f1b-940b-64f44c70507e
x-swg-uid: 01-8b81e159-94e6-4b98-ac2e-0bc0346994ca
X-Mailer: Sweego
Message-ID:
 <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd2094000c4f3@vates.tech>
x-swg-bid: 1788180504.8631fc262581453bbf619ec5b2062170.1a057dd2094000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v2 05/39] xen/riscv: request a G-stage flush on vmenter
 when VMIDs are disabled
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Zheng Zhang <zhangzheng@iscas.ac.cn>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <4274740481062ef92a76debd9c3f1e8371858735.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <4274740481062ef92a76debd9c3f1e8371858735.1787838835.git.oleksii.kurochko@gmail.com>
Date: Mon, 31 Aug 2026 14:48:15 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788180503; l=1107;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=9F8n7O5utMtWiH5dWpQxZFCNADn2iY1DmbySFqvUTmQ=;
 b=hZOuO7rMToOUdW8iXgG3DjCdhzEcPc7E+zxAMRhY9fXKtK/ppXu5QTacg920Ple5WLOna/+fS
 OP+BAAwtYegCOzTyXnumqtsTfYk5uBMDMRTGbNbVS2LM13HCVdCJSfz
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788180504313
X-purgate-ID: tlsNG-33051d/1788180522-76EF74E9-F34D6F47/10/73395122804
X-purgate-type: spam
X-purgate-size: 1107

> vmid_handle_vmenter() reports that no flush is needed when VMIDs are
> unavailable (vmid=off, 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 <oleksii.kurochko@gmail.com>
>

FWIW this comment and p2m_handle_vmenter() itself get dropped a few
patches later in "implement vCPU context switching", which folds the
VMID claim into p2m_ctxt_switch_to(). The fix survives there via the
need_flush check. Is this patch really needed?

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:48:48 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:48:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404021.1637978 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RQ-0007NS-C9; Mon, 31 Aug 2026 12:48:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404021.1637978; Mon, 31 Aug 2026 12:48:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11RQ-0007NJ-8G; Mon, 31 Aug 2026 12:48:48 +0000
Received: by outflank-mailman (input) for mailman id 1404021;
 Mon, 31 Aug 2026 12:48:47 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1x11RP-0007KJ-Ap
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:48:47 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11RO-004rdd-No
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:48:46 +0200
Received: from [10.42.69.2] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd21b7000c4f3@swg.vates.tech>)
 id 6a957829-8faa-0a2a0a5109dd-0a2a4502a580-20
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:46 +0200
Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net)
 by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from
 <prod-mta-13.8631fc262581453bbf619ec5b2062170.1a057dd21b7000c4f3@swg.vates.tech>)
 id 6a95782e-6ca4-0a2a45020019-b9ff1c239983-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:48:46 +0200
Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr)
 (Authenticated sender:
 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e)
 by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id
 1a057dd21b7000c4f3.007 for <xen-devel@lists.xenproject.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 31 Aug 2026 12:48:25 +0000
Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr
 [90.18.187.194]) (Authenticated sender: baptiste.le-duc)
 by mail2.vates.fr (Postfix) with ESMTPSA id 6709983D11;
 Mon, 31 Aug 2026 14:48:24 +0200 (CEST)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech;
 q=dns/txt; s=selector1; bh=EU58JJLCvXVx1GxdwebNIYsQ3lWzkYuYQLbcX+qLxPo=;
 h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id;
 b=TddoKn17PjxGSBKGfZgypCNYEIH+KriQdoDIYHjPDJPkhOLqR1k3/n/xrbI2TSydHdG2EwzXN
 /Gvvriq+08faKZSJKHnvSQgxj+GpT+beYfRF35oY6O0sysrHTuchRXAaRVKJ8gYGzUea4Erh7U2
 2r2ONFqtxGgo5LVwwCw4+3fgqEsKqGp8nuVqsbNHyuCgjCNkgY+q5dTCzDBC5CtDWjZtm21L0bU
 q/KR2PlnDANVRVEh5A3qR1VU2DytPyh50RG+s6Q/YtWaF4sa9eXywv3BgQRpHynVmCeJA+w+lnl
 H4dW/JgMDW72D1+2nNE7n29lWCl+G47etoubaDP5LuSA==
X-Zone-Loop: e6c0e597627ac26b4ff3206d1dab75f405f52a06e8a2
x-campaign-type: default
x-transaction-id: 20d82833-b03d-45e5-b417-d56228534914
x-swg-uid: 01-513c35e3-3827-44d3-a7a4-e788e1936b75
X-Mailer: Sweego
Message-ID:
 <1788180505.8631fc262581453bbf619ec5b2062170.1a057dd21b7000c4f3@vates.tech>
x-swg-bid: 1788180505.8631fc262581453bbf619ec5b2062170.1a057dd21b7000c4f3
Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego
x-campaign-id: default
x-client-id: 8631fc262581453bbf619ec5b2062170
X-Originating-IP: [37.26.189.201]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v2 06/39] xen/riscv: use UINT64_MAX to disable the
 VS-timer
From: Baptiste Le Duc <baptiste.le-duc@vates.tech>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: xen-devel@lists.xenproject.org, 
 Romain Caritey <Romain.Caritey@microchip.com>, 
 Baptiste Le Duc <baptiste.le-duc@vates.tech>, 
 Zheng Zhang <zhangzheng@iscas.ac.cn>, 
 Alistair Francis <alistair.francis@wdc.com>, 
 Connor Davis <connojdavis@gmail.com>, 
 Andrew Cooper <andrew.cooper3@citrix.com>, 
 Anthony PERARD <anthony.perard@vates.tech>, 
 Michal Orzel <michal.orzel@amd.com>, Jan Beulich <jbeulich@suse.com>, 
 Julien Grall <julien@xen.org>, 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, 
 Stefano Stabellini <sstabellini@kernel.org>
In-Reply-To: <93829c39b080d288ea342c7375d5307f93ee9a29.1787838835.git.oleksii.kurochko@gmail.com>
References: <cover.1787838835.git.oleksii.kurochko@gmail.com>
 <93829c39b080d288ea342c7375d5307f93ee9a29.1787838835.git.oleksii.kurochko@gmail.com>
Date: Mon, 31 Aug 2026 14:48:15 +0200
X-Developer-Signature: v=1; a=ed25519-sha256; t=1788180503; l=708;
 i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id;
 bh=Jwfnu6razQ4bDNZSR29qomKftwxGzGfH1a367r1gOQU=;
 b=7pU8NJnOOoo/qWl7N7HNQEL2ds1yjg1c/wiPlipBDNgHZWlPyCGldthSiJZHpZUwvdhoA0XxX
 zm7/JPXzG0FD0K63kfz2fOWf/nBzXa3sGXmQhOohdj1wUptKhB25CIy
X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519;
 pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1788180504609
X-purgate-ID: tlsNG-720697/1788180526-323D42AC-24D9B30D/10/73395122804
X-purgate-type: spam
X-purgate-size: 708

On Thu, 27 Aug 2026 17:20:50 +0200, Oleksii Kurochko <oleksii.kurochko@gmail.com> wrote:
> 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.
> 
> [...]

Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>

-- 
Baptiste Le Duc <baptiste.le-duc@vates.tech>


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 12:59:55 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 12:59:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404046.1637987 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11bz-0001uv-9C; Mon, 31 Aug 2026 12:59:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404046.1637987; Mon, 31 Aug 2026 12:59:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x11bz-0001uo-5u; Mon, 31 Aug 2026 12:59:43 +0000
Received: by outflank-mailman (input) for mailman id 1404046;
 Mon, 31 Aug 2026 12:59:41 +0000
Received: from mx.expurgate.net ([194.145.224.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <jgross@suse.com>) id 1x11bx-0001ue-Oq
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 12:59:41 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x11bw-002rZq-PQ
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 14:59:40 +0200
Received: from [10.42.69.10] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <jgross@suse.com>)
 id 6a957abc-8faa-0a2a0a5109dd-0a2a450adc44-0
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:59:40 +0200
Received: from [209.85.208.42] (helo=mail-ed1-f42.google.com)
 by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <jgross@suse.com>)
 id 6a957abc-f2d2-0a2a450a0019-d155d02aa5b7-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 14:59:40 +0200
Received: by mail-ed1-f42.google.com with SMTP id
 4fb4d7f45d1cf-6a5ebf75d62so5666754a12.1
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 05:59:40 -0700 (PDT)
Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112?
 (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de.
 [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-6a611b675d1sm3735822a12.9.2026.08.31.05.59.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2026 05:59:39 -0700 (PDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1788181180; x=1788785980; darn=lists.xenproject.org;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc
         :subject:date:message-id:reply-to:content-type;
        bh=rmbwc7pbIyZmSLHU25g8L0LQHx9DUCsFZZGV1gqiF8o=;
        b=OGW5AbL0bDBF2lefDinjsITaOuPJgoeK/wiPzL5S5/24dm1/5SVUCCWIGTuQg8wZUt
         HjMqLuGdkOPZoN+S1HQu/Py1AWDBbdaW54xuzRrc9Jv9dx466nGCaL0uvKr5WOReEt3o
         sdR10gTmZ9K/Au//8RrvJJN8yPAxQVrxYuxju7tioz0A8o/R5wnU5aNeJ3dJyE/MNYna
         eIbIJTddSJO0ArtIy95nHXi5stiD9yGQ65YWlKU5Kstx2GHu5QiE4vYW6ZrpTlMNHK/Q
         TUPTuM77xjdSh2jTE/2Ozq9H+TytLPJkhTvNO9bsV2gK7/17388XP5rpEx19IL6N0XBt
         XLzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20251104; t=1788181180; x=1788785980;
        h=content-type:in-reply-to:autocrypt:from:content-language:references
         :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
         :content-type;
        bh=rmbwc7pbIyZmSLHU25g8L0LQHx9DUCsFZZGV1gqiF8o=;
        b=lCOHzB7m/B64xeTZ9ajc+Oo9fu6orCKPbfHCn/9yhWP8pqh4zIGbBuo4JRtYvXxrzQ
         0p9tzVVRGx7kUghONVW7/uaoDhBnyZAINKo0WiutSSPMQRsMLLhBeCa0G6oAIojTw5cm
         Wf3UNiERDvRlOTLob3B96cccb5gxLptMO0q3sUK0exJjyzJWyDUD6jzg2wht/Vn5Z6Cl
         IoeMaUK151gybmCkJ0SANNGKBoikIyDcJ4f2K/wdFS1Sb610q0dpH+Gj/PmC+KhlYDjz
         3li3GjIlMpamuSfHdJ79O5Qpwd+gq1jvSPOX/htjRETb5y2Arpum0Ve6gk5ZvN0Yima+
         75FQ==
X-Forwarded-Encrypted: i=1; AKwUvBwA5/E/grWOhoilfEKoKDrwBtnD2LarDyaoCFKIZjnOuFTHqKLmgQwfWyPAnM/XyCZ+wVbyX7nsetA=@lists.xenproject.org
X-Gm-Message-State: AFuF++khMpnxykNQSAy3KqeN7DjWeuMhvxxoSMFTDpgggnGvaA967ggp
	yiHQW2M7RqBAzKL54E3Wgshg/vRsl1xEwl7hvMkrk1EFVAOqkfw3bBqZvYYoMPCD8DE=
X-Gm-Gg: AYBFou3hTC5EXEDK1ebRtv1i7XKkNH3IlzdYLk+5dbhs0WPMsCtSUkzqSvGej5SY+9V
	vDK8BcAjDPHJqym+cAH5s5N6l0ssz9kIejgX0HYqd2eXxGhMaElx6tT10tFUyz39TCReyDo7xLu
	H4LDJTH7vZCtVqkaxLmoUw9R+jBR3hba9Av98uB7+cQjzLm/k+4k/O8TaJcL16ybvhWAKO/Ah6w
	gksvAXteDYZERgK+N+ia2Cp5ntZ00jiGN54LKAf/gbGbAF0jHtFHV1Zr2cgDhVQ+kG+nYtRgQh9
	d0hc5njFAahgFr1R1kPzfk0FpD3vBsTb45uogbsRVcrsgMTC/AN0FcVQwUF/1FNaNgurJ25LRAH
	h5VUa/U70X4cACQHnja6viYe+ltgUSZiqruzQnTok1ahn1Oeou2dyHy1hVETfI4R4TXTY/Jfi1G
	nB5k56Tr37X6yun34IyMIURmw3w1A2FcIcb4vuJ5WOTo73GwLxcI8Zgf72NeCJCUXvWr+3GyKVi
	d+5KoZIYMgX9EgfEwjl0+v8aOY9CKX6YsdzS8mAx0feJDI0bhwWZyXO+d7bdh7UFlruHGdyupbo
	VSojdQbUpYm9uQ==
X-Received: by 2002:aa7:d7ce:0:b0:6a5:d284:1134 with SMTP id 4fb4d7f45d1cf-6a6476996b7mr3283736a12.2.1788181180092;
        Mon, 31 Aug 2026 05:59:40 -0700 (PDT)
Message-ID: <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com>
Date: Mon, 31 Aug 2026 14:59:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus
 in sync
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org,
 roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org,
 bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-2-frn1furkan10@gmail.com>
 <cb7418ef-4d3e-4a86-9c86-f7b0f296c013@citrix.com>
Content-Language: en-US
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
Autocrypt: addr=jgross@suse.com; keydata=
 xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB
 ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve
 dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ
 NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx
 XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB
 AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh
 mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0
 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH
 kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc
 Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO
 RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy
 vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn
 sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa
 aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg
 w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS
 auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d
 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn
 fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g
 HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk
 QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6
 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
In-Reply-To: <cb7418ef-4d3e-4a86-9c86-f7b0f296c013@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------hH0nFQZmGGVK10bZd6Gxav8h"
X-purgate-ID: tlsNG-4011c0/1788181180-508CDCFC-867E2FBD/0/0
X-purgate-type: clean
X-purgate-size: 11188

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------hH0nFQZmGGVK10bZd6Gxav8h
Content-Type: multipart/mixed; boundary="------------WmhsvkZAmVDqlQG7zk2Ptfaz";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
 Furkan Caliskan <frn1furkan10@gmail.com>, xen-devel@lists.xenproject.org
Cc: jbeulich@suse.com, dfaggioli@suse.com, gwd@xenproject.org,
 roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org,
 bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com,
 teddy.astie@vates.tech
Message-ID: <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com>
Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus
 in sync
References: <20260831051637.5029-1-frn1furkan10@gmail.com>
 <20260831051637.5029-2-frn1furkan10@gmail.com>
 <cb7418ef-4d3e-4a86-9c86-f7b0f296c013@citrix.com>
In-Reply-To: <cb7418ef-4d3e-4a86-9c86-f7b0f296c013@citrix.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------WmhsvkZAmVDqlQG7zk2Ptfaz
Content-Type: multipart/mixed; boundary="------------z004N67swzAtFwgqQfqxsmPV"

--------------z004N67swzAtFwgqQfqxsmPV
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMzEuMDguMjYgMTE6NDUsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IE9uIDMxLzA4LzIw
MjYgNjoxNiBhbSwgRnVya2FuIENhbGlza2FuIHdyb3RlOg0KPj4gRXZlcnkgdmNwdV9jcmVh
dGUoKSBjYWxsIHNpdGUgdGhhdCBidWlsZHMgbW9yZSB0aGFuIG9uZSB2Y3B1IGxvb3BzDQo+
PiBvdmVyIGlkcyB1cCB0byBkLT5tYXhfdmNwdXMgYW5kIHN0b3BzIG9uIHRoZSBmaXJzdCBm
YWlsdXJlLCBidXQgbm9uZQ0KPj4gb2YgdGhlbSByb2xsIG1heF92Y3B1cyBiYWNrIHRvIG1h
dGNoLiBUaGlzIGxlYXZlcyBkLT52Y3B1W2ldID09IE5VTEwNCj4+IGZvciBpZHMgYmVsb3cg
bWF4X3ZjcHVzDQo+IA0KPiBBcyBJIHRvbGQgeW91IGJlZm9yZSwgeW91IG11c3QgY29wZSB3
aXRoIHRoaXMgcHJvcGVydHkgaW4gbm9uLWVycm9yDQo+IHNjZW5hcmlvcy4NCj4gDQo+PiAs
IHdoaWNoIGFueXRoaW5nIHdhbGtpbmcgZC0+dmNwdVtdIGNhbiB0aGVuDQo+PiBkZXJlZmVy
ZW5jZS4gVGhpcyBpcyB3aGF0IGNhdXNlZCB0aGUgY3Jhc2g6IHNjaGVkX21vdmVfZG9tYWlu
KCkNCj4+IHdhbGtzIGV2ZXJ5IHZjcHUgc2xvdCB1cCB0byBtYXhfdmNwdXMgd2l0aG91dCBj
aGVja2luZyBmb3IgZW1wdHkNCj4+IG9uZXMsIHNvIHdoZW4gYSBkb21haW4gYnVpbHQgaW4g
YSBub24tZGVmYXVsdCBjcHVwb29sIGhhZCB2Y3B1DQo+PiBjcmVhdGlvbiBmYWlsIHBhcnR3
YXkgdGhyb3VnaCwgZG9tYWluX2tpbGwoKSBsYXRlciBtb3ZpbmcgaXQgYmFjaw0KPj4gdG8g
dGhlIGRlZmF1bHQgY3B1cG9vbCBoYW5kZWQgb25lIG9mIGl0cyBlbXB0eSBzbG90cyBzdHJh
aWdodCB0bw0KPj4gdGhlIG5ldyBjcHVwb29sJ3Mgc2NoZWR1bGVyLCBjYXVzaW5nIGEgTlVM
TC1wb2ludGVyIGRlcmVmZXJlbmNlDQo+PiBpbnNpZGUgc2NoZWRfYWxsb2NfdWRhdGEoKS4N
Cj4+DQo+PiBBZGQgdmNwdXNfY3JlYXRlKGQpOiBjcmVhdGVzIGV2ZXJ5IHZjcHUgb2YgZCB1
cCB0byBtYXhfdmNwdXMgYW5kDQo+PiByb2xscyBtYXhfdmNwdXMgYmFjayB0byB0aGUgZmFp
bGVkIGlkIG9uIGVycm9yLiBUaGlzIGtlZXBzDQo+PiBkLT52Y3B1W2ldIGlzIG5vbi1OVUxM
IGZvciBhbGwgaSA8IGQtPm1heF92Y3B1cw0KPiANCj4gTm8sIGl0IHJlYWxseSBkb2Vzbid0
Lg0KPiANCj4+ICwgaW5zdGVhZCBvZiBndWFyZGluZw0KPj4gZXZlcnkgcmVhZGVyIG9mIGQt
PnZjcHVbXSBhZ2FpbnMgaG9sZXMgaW5kaXZpZHVhbGx5Lg0KPj4NCj4+IENvbnZlcnQgZXZl
cnkgc2l0ZSB0aGF0IGJ1aWxkcyB2Y3B1cyBpbiBhIGxvb3AgdG8gY2FsbCB0aGlzIGZ1bmN0
aW9uDQo+PiBpbnN0ZWFkLg0KPj4NCj4+IEZpeGVzOiA2MTY0OTcwOTQyMWEgKCJ4ZW4vZG9t
YWluOiBBbGxvY2F0ZSBkLT52Y3B1W10gaW4gZG9tYWluX2NyZWF0ZSgpIikNCj4+IFN1Z2dl
c3RlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPj4gU2lnbmVkLW9m
Zi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPiANCj4g
Rm9yIHRoZSBhdm9pZGFuY2Ugb2YgYSBsb25nIGRyYXduLW91dCBhcmd1bWVudCwgbmFjay7C
oCBVbmRlciBubw0KPiBjaXJjdW1zdGFuY2VzIGFyZSB5b3UgZWRpdGluZyBkLT5tYXhfY3B1
cyBhZnRlciBpdCdzIHB1dCBpbnRvIHRoZSBkb21haW4NCj4gbGlzdC4NCj4gDQo+IFlvdSd2
ZSBjaG9zZW4gdG8gZG8gc28gYXQgYSBwb2ludCB3aGVyZSB0aGUgZG9tYWluIG9iamVjdCBp
cyBsaXZlLA0KPiB2aXNpYmxlIGluIHRoZSBzeXN0ZW0gYW5kIGFibGUgdG8gYmUgdGhlIHRh
cmdldCBvZiBvdGhlciBoeXBlcmNhbGxzLg0KPiANCj4gRnVydGhlcm1vcmUgeW91IGhhdmUg
bm90IGZpeGVkIHdoYXQgeW91ciBjb21taXQgbWVzc2FnZSBjbGFpbXMuDQo+IGQtPnZjcHVb
Li4uXSBpcyBzdGlsbCBOVUxMIGZvciBhbiBhcmJpdHJhcnkgcGVyaW9kIG9mIHRpbWUsIGlu
Y2x1ZGluZw0KPiBiZWluZyBhYmxlIHRvIGJlIHRoZSB0YXJnZXQgb2YgaHlwZXJjYWxscywg
YmVmb3JlIHZDUFVzIGFyZSBjcmVhdGVkLg0KPiANCj4gQWxsIGNvZGUgTVVTVCBiZSBhYmxl
IHRvIGNvcGUgd2l0aCBkLT52Y3B1Wy4uLl0gYmVpbmcgTlVMTC7CoCBJdCdzIGhvdw0KPiB0
aGUgb2JqZWN0IGxpZmVjeWNsZXMgbXVzdCB3b3JrLCBiZWNhdXNlIGNyZWF0aW5nIHZDUFVz
IGlzIG5vdCBhdG9taWMNCj4gd2l0aCByZXNwZWN0IHRvIGNyZWF0aW5nIGRvbWFpbnMuDQoN
CldvdWxkIHlvdSBiZSBmaW5lIHdpdGggbWUgY3JlYXRpbmcgYSBwYXRjaCBzZXJpZXMgbW92
aW5nIHZjcHUgY3JlYXRpb24gaW50bw0KZG9tYWluX2NyZWF0ZSgpPw0KDQpUaGlzIHdvdWxk
IGF0IG9uY2Ugc29sdmUgYWxsIHRob3NlIHByb2JsZW1zLCB3aGlsZSBldmVuIHJlbW92aW5n
IHRoZSBuZWVkIGZvcg0KaGF2aW5nIHRoZSBYRU5fRE9NQ1RMX21heF92Y3B1cyBkb21jdGwu
DQoNCg0KSnVlcmdlbg0K
--------------z004N67swzAtFwgqQfqxsmPV
Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri
oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2
kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i
1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B
BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK
N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg
PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE
FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F
UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye
vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u
+6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq
qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP
tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy
Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ
CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4
RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7
8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T
BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ
SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK
7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM
nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB
AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/
Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN
hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi
w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf
VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP
OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK
/1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1
c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4
k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ
wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu
5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB
TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io
N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6
AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr
0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x
Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF
LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm
we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I
v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv
Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD
534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH
b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT
yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc
suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B
jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W
KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge
gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422
bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN
aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay
7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF
RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn
g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib
4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX
kt+z4drzFUyEjLM1vVvIMjkUoJs=3D
=3DeeAB
-----END PGP PUBLIC KEY BLOCK-----

--------------z004N67swzAtFwgqQfqxsmPV--

--------------WmhsvkZAmVDqlQG7zk2Ptfaz--

--------------hH0nFQZmGGVK10bZd6Gxav8h
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqVersFAwAAAAAACgkQsN6d1ii/Ey8w
QggAmUK9waKIAAMunEV3tcEBNrbx7TVOgUtkMVPBXeZTPo6XyJL+62iBtGfhJBJxgaFZd8yrIVRx
X6F5Xn+6XGtsZtP9S8NS0j6ku34ppso1p+mGaQTRobYVRwfHYSd81b4oTTEC2oNCErFP7n+jxK5s
m/nML0m/6GqiYQi325kseRzvQ0Gj4eQGTK9XuXgcHEJOHZDN+hJ/ZU+CDtN4hJ/aDY7hWRpU97tA
yjSJPoS1guKV0LCTg26BRrrex/KX1MChWF3nBl1NddtaEXSeLOWM9rfHDaufVEb29/UrxHJZU5Pk
oCTluNP8wCJxhH2OCfqN0BwaV6/8tbilA8jQuYXWKQ==
=SqJp
-----END PGP SIGNATURE-----

--------------hH0nFQZmGGVK10bZd6Gxav8h--


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 13:36:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 13:36:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404059.1637996 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x12B5-0008F9-QN; Mon, 31 Aug 2026 13:35:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404059.1637996; Mon, 31 Aug 2026 13:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x12B5-0008F1-N6; Mon, 31 Aug 2026 13:35:59 +0000
Received: by outflank-mailman (input) for mailman id 1404059;
 Mon, 31 Aug 2026 13:35:57 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sashal@kernel.org>) id 1x12B3-0008Ev-Av
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 13:35:57 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x12B2-00A0l0-Ji
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 15:35:56 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sashal@kernel.org>)
 id 6a95833c-bab6-0a2a0a5309dd-0a2a4505b4be-0
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 15:35:56 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sashal@kernel.org>)
 id 6a95833b-4cb1-0a2a45050019-ac6904feae9c-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 15:35:56 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 9F13C60215;
 Mon, 31 Aug 2026 13:35:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F0F41F00A3F;
 Mon, 31 Aug 2026 13:35:53 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1788183354;
	bh=HSkhL9GEPh+pjRNfJc8hLKIsYQDXSRpdkikCUwYosQc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=OrhEoctWOCtSw/GE1uNv1080RfJV4OHV2RZ849wX1Ci21F+GX5gbIXe0i7VURno4w
	 qpcgCCOcD12jrbU+bUdiTR+WfbfGK8UeD9R8w69X05ceL10VRaJRwhhGRmDZ1X4ION
	 DU1JnyOjOEA+ZN/rSlniF6a4mT3IE3n4d/f6zhEPM22dB793to495yq2u8vCmHDJVc
	 BgryyxGypF44z3datQstHbxD/Fzke1NI5ctiubMzCE+awUJzLJIX06fNKJ0mt5UGPN
	 KVsG8KfVGc3DAtbyns2y4wqg+XPNQamRmDjIJfwj/mLMlguNaVm7kLDAvlnwtLie7U
	 BCcoxpA1g9xmg==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Yousef Alhouseen <alhouseenyousef@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Sasha Levin <sashal@kernel.org>,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-5.10] xen/front-pgdir-shbuf: free grant reference head on errors
Date: Mon, 31 Aug 2026 09:22:06 -0400
Message-ID: <20260831133314.4125787-98-sashal@kernel.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org>
References: <20260831133314.4125787-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.18.48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1788183356-F70B22A1-81D04592/0/0
X-purgate-type: clean
X-purgate-size: 16057

From: Yousef Alhouseen <alhouseenyousef@gmail.com>

[ Upstream commit 678d59219ce0ae883f04c96936222c6168ef1164 ]

grant_references() allocates a private grant-reference head before
claiming references for the page directory and, for guest-owned buffers,
the data pages. The success path frees the remaining head, but claim
failures and grant_refs_for_buffer() errors return immediately.

Unwind through a common exit path so the private grant-reference head is
released even when granting fails part-way through setup. The caller
still tears down any references already stored in buf->grefs.

Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260629160517.29340-1-alhouseenyousef@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `xen/front-pgdir-shbuf: free grant reference
head on errors`

**Local tree:** Linux 6.18.44 (`v6.18.44-1-g2736c32da98b9`)
**Fix commit (mainline):** `678d59219ce0a` — not an ancestor of this
tree; buggy code is still present.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[xen/front-pgdir-shbuf]` `[free]` — fix missing cleanup of
a private grant-reference head on error paths in `grant_references()`.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Signed-off-by:** Yousef Alhouseen `<alhouseenyousef@gmail.com>`
  (author)
- **Reviewed-by:** Stefano Stabellini `<sstabellini@kernel.org>` (Xen
  maintainer)
- **Signed-off-by:** Juergen Gross `<jgross@suse.com>` (Xen maintainer,
  committer)
- **Message-ID:** `<20260629160517.29340-1-alhouseenyousef@gmail.com>`
- No Fixes:, Reported-by:, Tested-by:, Link:, or Cc: stable tags
- Notable: Reviewed by a Xen subsystem maintainer; committed by Xen tree
  maintainer

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** `grant_references()` allocates a private grant-reference list
  (`priv_gref_head`) via `gnttab_alloc_grant_references()`. On success,
  unclaimed entries are returned via `gnttab_free_grant_references()`.
  On two error paths (`gnttab_claim_grant_reference()` failure and
  `grant_refs_for_buffer()` failure), the function returned immediately
  without freeing `priv_gref_head`.
- **Symptom:** Unclaimed grant references remain off the global free
  list — a resource leak in the Xen grant table.
- **Root cause:** Missing common error-exit cleanup; caller
  `xen_front_pgdir_shbuf_free()` only tears down refs already stored in
  `buf->grefs`, not the private head list.
- **Version info:** None in the message.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised — this is an explicit error-path resource-leak
fix, though described without a crash report.

---

## PHASE 2: DIFF ANALYSIS — LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **File:** `drivers/xen/xen-front-pgdir-shbuf.c` (+8 / −4 lines)
- **Function modified:** `grant_references()` only
- **Scope:** Single-file surgical fix

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
- **Hunk 1 (claim failure in directory loop):** Before: `return cur_ref`
  leaked `priv_gref_head`. After: `ret = cur_ref; goto out_free_refs`.
- **Hunk 2 (`grant_refs_for_buffer` failure):** Before: `return ret`
  leaked head. After: `goto out_free_refs`.
- **Hunk 3 (success path restructured):** Before: free head, `return 0`.
  After: `ret = 0; out_free_refs:
  gnttab_free_grant_references(priv_gref_head); return ret` — same
  success behavior, unified cleanup on all paths after allocation.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Category:** Error-path resource leak (grant reference leak)
- **Mechanism:** `gnttab_alloc_grant_references()` removes entries from
  the global grant free pool into a private linked list. Claimed refs
  are removed from that list and stored in `buf->grefs`. Unclaimed refs
  remain in `priv_gref_head` and must be returned via
  `gnttab_free_grant_references()`. Early returns skipped that free,
  permanently shrinking the grant table pool.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- **Quality:** Obviously correct; mirrors the established pattern in
  `gntdev-dmabuf.c` (`out:` label + `gnttab_free_grant_references()`).
- **Regression risk:** Very low. `gnttab_free_grant_references()` only
  frees refs still linked in `priv_gref_head`; already-claimed refs in
  `buf->grefs` are untouched and still cleaned up by the caller on
  failure.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:** `grant_references()` introduced in `b3383974fee27`
(Oleksandr Andrushchenko, 2018-11-30) — "xen: Introduce shared buffer
helpers for page directory based frontends." The missing error-path
cleanup has existed since introduction (~kernel 5.0 era).

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No Fixes: tag present — N/A.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:** Related prior fix `53f131c284e83` (2021): "don't record
wrong grant handle upon error" — different issue (invalid handle on
error), already in this tree. No prerequisite commits needed; standalone
single-patch series (v1 only per b4).

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Yousef Alhouseen is a contributor; this is their Xen front-
pgdir-shbuf fix. Reviewed/committed by Xen maintainers (Stabellini,
Gross).

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No dependencies. `git apply --check` on the fix diff
succeeds cleanly against this tree's file. Standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:** `b4 dig -c 678d59219ce0a` → https://patch.msgid.link/2026062
9160517.29340-1-alhouseenyousef@gmail.com
Single v1 submission (2026-06-29). Lore page fetch blocked by bot
protection; thread content not directly readable.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** `b4 dig -w`: To/Cc included Juergen Gross, Stefano
Stabellini, xen-devel@lists.xenproject.org, linux-
kernel@vger.kernel.org. Stefano Stabellini Reviewed-by on committed
version.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No Reported-by or bug-report Link tags. Bug identified via
code-path analysis (missing cleanup), not a syzbot/fuzzer report.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Standalone 1/1 patch; no series dependencies.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** Not searched (no stable-list nomination found in commit;
lore stable search not performed due to limited external access).
Absence of Cc: stable is expected per review instructions.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `grant_references()` (modified);
`guest_grant_refs_for_buffer()` (error source via ops callback,
unchanged).

### Step 5.2: TRACE CALLERS
**Record:** `grant_references()` is called only from
`xen_front_pgdir_shbuf_alloc()` (line 534). Callers of
`xen_front_pgdir_shbuf_alloc()`:
- `drivers/gpu/drm/xen/xen_drm_front.c` — Xen PV DRM frontend
- `sound/xen/xen_snd_front_alsa.c` — Xen PV sound frontend
Both run during device/buffer setup on Xen PV guests.

### Step 5.3: TRACE CALLEES
**Record:** `gnttab_alloc_grant_references()`,
`gnttab_claim_grant_reference()`, `gnttab_grant_foreign_access_ref()`,
`buf->ops->grant_refs_for_buffer()` (guest:
`guest_grant_refs_for_buffer()`), `gnttab_free_grant_references()`.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Xen guest driver probe → buffer alloc → `grant_references()`
→ on failure, `xen_front_pgdir_shbuf_free()` cleans `buf->grefs` but not
`priv_gref_head`. Reachable during normal Xen PV driver initialization;
not a syscall path, but triggered by guest driver operations
(potentially from userspace opening DRM/audio devices).

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Correct pattern already used in `drivers/xen/gntdev-
dmabuf.c` lines 509–511 (`out:
gnttab_free_grant_references(priv_gref_head)`). `drivers/usb/host/xen-
hcd.c` and `drivers/net/xen-netfront.c` also use alloc/free pairs. This
file was the outlier missing error-path free.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **Yes.** `drivers/xen/xen-front-pgdir-shbuf.c` lines 449–451
and 461–462 still have bare `return` on error without freeing
`priv_gref_head`. Bug present since 2018 introduction (`b3383974fee27`).

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected.** `git apply --check` on commit
`678d59219ce0a` diff passes with no conflicts on this tree.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** Fix `678d59219ce0a` is **not** in this tree (`git merge-base
--is-ancestor` returns 1). Prior related fix `53f131c284e83` is present.
No duplicate fix applied.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **Subsystem:** Xen grant-table / shared-buffer
infrastructure (`drivers/xen/`). **Criticality:** IMPORTANT — grant
references are a finite global resource shared by all Xen PV drivers
(net, block, USB, DRM, sound, etc.). Leaks affect the whole guest.

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** Moderate activity; file last touched in-tree by
`50e865a56876b` (2023, kernel-doc cleanup). Core logic stable since
2018.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** Xen PV guests with `CONFIG_XEN_FRONT_PGDIR_SHBUF` (selected
by `CONFIG_DRM_XEN` and Xen sound). Affects DRM and audio buffer setup
on Xen; grant-table exhaustion can impact all Xen drivers in the guest.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** Triggered when `grant_references()` fails after
`gnttab_alloc_grant_references()` succeeds — specifically
`gnttab_claim_grant_reference()` returning negative, or
`guest_grant_refs_for_buffer()` failing. Uncommon in steady state
(allocation size matches claim count), but possible under resource
pressure, accounting edge cases, or repeated alloc/free retry loops. Not
unprivileged-direct, but reachable through Xen frontend driver usage.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:** **Failure mode:** Grant reference leak → progressive
depletion of global grant free pool → `-ENOSPC` on subsequent grant
operations across the guest (network, block, console, etc.).
**Severity:** HIGH (resource exhaustion degrading entire Xen guest; not
an immediate oops, but can render the guest unusable over time or after
repeated failures).

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Prevents grant-table leaks on error paths; protects all
  Xen PV functionality
- **Risk:** Very low — 8-line surgical change, maintainer-reviewed,
  matches existing codebase pattern
- **Ratio:** Strong benefit, minimal risk

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Real resource leak on error paths (grant references never returned to
  free pool)
- Bug present in this 6.18.y tree since 2018
- Fix is small, obviously correct, maintainer-reviewed
- Applies cleanly to this tree
- Grant-table exhaustion is a serious Xen guest-wide failure mode
- Matches established cleanup pattern in sibling Xen code (`gntdev-
  dmabuf.c`)

**AGAINST backporting:**
- No user crash report or syzbot reproduction
- Error path may be rarely exercised in production
- Affects only Xen PV guests with specific drivers enabled

**Unresolved:** Exact production trigger frequency; lore thread
discussion content (bot-blocked).

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — standard goto cleanup;
   Reviewed-by Xen maintainer
2. Fixes a real bug? **PASS** — grant ref leak on error paths
3. Important issue? **PASS** — grant table exhaustion (HIGH severity for
   Xen guests)
4. Small and contained? **PASS** — 1 file, ~12 lines
5. No new features or APIs? **PASS** — error-path cleanup only
6. Can apply to local tree? **PASS** — `git apply --check` succeeds

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**Record:** None (not device ID, quirk, DT, build, or docs). Standard
bug-fix category.

### Step 9.4: DECISION RATIONALE
This fix closes a long-standing error-path leak in Xen grant-reference
management. While the trigger may be uncommon, leaked grant references
are a finite, guest-wide resource — exhaustion can break networking,
storage, and other PV devices. The patch is minimal, reviewed by Xen
maintainers, applies cleanly to Linux 6.18.44, and introduces no new
behavior on success paths.

---

## Verification

- **[Phase 1]** Parsed commit `678d59219ce0a` message and tags:
  Reviewed-by Stefano Stabellini; Signed-off-by Juergen Gross
- **[Phase 2]** Diff analysis: 3 error-path changes in
  `grant_references()`, adds `out_free_refs` unified cleanup
- **[Phase 3]** `git blame`: buggy code from `b3383974fee27`
  (2018-11-30), present in tree
- **[Phase 3]** `git log -20 -- drivers/xen/xen-front-pgdir-shbuf.c`:
  related fix `53f131c284e83` present; this fix absent
- **[Phase 3]** `git merge-base --is-ancestor 678d59219ce0a HEAD`: exit
  1 — fix not in tree
- **[Phase 3]** `git apply --check` on fix diff: passes cleanly
- **[Phase 4]** `b4 dig -c 678d59219ce0a`: lore URL found
- **[Phase 4]** `b4 dig -a`: single v1 patch, no series
- **[Phase 4]** `b4 dig -w`: Juergen Gross, Stefano Stabellini, xen-
  devel CC'd
- **[Phase 4]** WebFetch lore thread: blocked (bot protection) — review
  discussion unverified
- **[Phase 5]** `grep grant_references`: single caller
  `xen_front_pgdir_shbuf_alloc()`
- **[Phase 5]** `grep xen_front_pgdir_shbuf_alloc`: callers in
  `xen_drm_front.c`, `xen_snd_front_alsa.c`
- **[Phase 5]** Read `gntdev-dmabuf.c` 509–511: confirms correct error-
  path pattern
- **[Phase 5]** Read `grant-table.c` 619–658, 685–692: confirmed
  alloc/claim/free semantics
- **[Phase 6]** `git describe HEAD`: v6.18.44; `Makefile`: 6.18.44
- **[Phase 6]** Read `xen-front-pgdir-shbuf.c` 430–467: confirmed buggy
  early returns present
- **[Phase 6]** Read `xen_front_pgdir_shbuf_free()` 131–142: caller
  cleans `buf->grefs` only, not `priv_gref_head`
- **[Phase 8]** Grant ref leak → pool exhaustion → `-ENOSPC` for all Xen
  grant users: severity HIGH

**YES**

 drivers/xen/xen-front-pgdir-shbuf.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-front-pgdir-shbuf.c b/drivers/xen/xen-front-pgdir-shbuf.c
index 223870a0111b2..e7fb06f607711 100644
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -447,8 +447,10 @@ static int grant_references(struct xen_front_pgdir_shbuf *buf)
 		unsigned long frame;
 
 		cur_ref = gnttab_claim_grant_reference(&priv_gref_head);
-		if (cur_ref < 0)
-			return cur_ref;
+		if (cur_ref < 0) {
+			ret = cur_ref;
+			goto out_free_refs;
+		}
 
 		frame = xen_page_to_gfn(virt_to_page(buf->directory +
 						     PAGE_SIZE * i));
@@ -459,11 +461,13 @@ static int grant_references(struct xen_front_pgdir_shbuf *buf)
 	if (buf->ops->grant_refs_for_buffer) {
 		ret = buf->ops->grant_refs_for_buffer(buf, &priv_gref_head, j);
 		if (ret)
-			return ret;
+			goto out_free_refs;
 	}
 
+	ret = 0;
+out_free_refs:
 	gnttab_free_grant_references(priv_gref_head);
-	return 0;
+	return ret;
 }
 
 /*
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 13:46:25 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 13:46:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404069.1638005 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x12L6-0001ii-QT; Mon, 31 Aug 2026 13:46:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404069.1638005; Mon, 31 Aug 2026 13:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x12L6-0001ib-NY; Mon, 31 Aug 2026 13:46:20 +0000
Received: by outflank-mailman (input) for mailman id 1404069;
 Mon, 31 Aug 2026 13:46:20 +0000
Received: from mx.expurgate.net ([195.190.135.10])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <sashal@kernel.org>) id 1x12L6-0001iV-1F
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 13:46:20 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x12L4-000k2h-4b
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 15:46:18 +0200
Received: from [10.42.69.5] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <sashal@kernel.org>)
 id 6a95859a-2eae-0a2a0a5409dd-0a2a45059c0a-44
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 15:46:18 +0200
Received: from [172.105.4.254] (helo=tor.source.kernel.org)
 by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <sashal@kernel.org>)
 id 6a9585a8-4cb1-0a2a45050019-ac6904feb42e-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 15:46:17 +0200
Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18])
 by tor.source.kernel.org (Postfix) with ESMTP id 7FABB60207;
 Mon, 31 Aug 2026 13:46:15 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CE281F00A3E;
 Mon, 31 Aug 2026 13:46:14 +0000 (UTC)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="From:To:Cc:Subject:Date:In-Reply-To:References"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1788183975;
	bh=VuuTfQsSlsnIRKrUr/mDOL2bAkwlXnRRMmPO/GFFYPA=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=iuQOydXpKQt7a1jrYnXvxz7aQoIBCAIFNAv8EO+fBl9su81MHY8w4LofBu/My120O
	 HfxrnjWbBjI9EIMnOnAbhove+XB7itONKmPObfJ8BBqywYenmcucJkIlYPVTh/0z0A
	 ps1dPvhLbgt3Owl/Pc24DurbtbBTtexTy9LRjri94Iw+AGgVCCxauPZA0qOLCCTw5p
	 20KwhhSloo5K6hqhVASUKB35Mb4EJl9l/olv96/HlXBA4Qr8cFmkozXPAezRsJqnw4
	 w5rg67QthsQRBYGHGuYJL5oF3jZtmzLZPd/iHKocBv6uL5OJjV7cCUos1poqzORyKs
	 10sUmsRrufMyw==
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev,
	stable@vger.kernel.org
Cc: Yousef Alhouseen <alhouseenyousef@gmail.com>,
	Juergen Gross <jgross@suse.com>,
	Sasha Levin <sashal@kernel.org>,
	sstabellini@kernel.org,
	xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-5.10] xen/gntalloc: validate grant count before allocation
Date: Mon, 31 Aug 2026 09:27:23 -0400
Message-ID: <20260831133314.4125787-415-sashal@kernel.org>
X-Mailer: git-send-email 2.53.0
In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org>
References: <20260831133314.4125787-1-sashal@kernel.org>
MIME-Version: 1.0
X-stable: review
X-Patchwork-Hint: Ignore
X-stable-base: Linux 6.18.48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-purgate-ID: tlsNG-c201ff/1788183977-734BC2A1-36D7AF9E/0/0
X-purgate-type: clean
X-purgate-size: 15461

From: Yousef Alhouseen <alhouseenyousef@gmail.com>

[ Upstream commit 2299822f3f466b5dcad2377bf63986199f881a6b ]

gntalloc_ioctl_alloc() allocates the grant-id array before checking
whether the requested count fits within the global grant limit. Counts
above that limit cannot succeed, so reject them before the
user-controlled allocation reaches kcalloc().

Use a subtraction-based check while holding gref_mutex so adding the
requested count cannot wrap. Also cast the count before advancing the
per-file index so the page-size multiplication is performed in 64-bit
arithmetic.

Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**
Record: `[xen/gntalloc] [validate] validate grant count before
allocation` — ioctl input validation and overflow-safety fix in the Xen
grant allocator.

**Step 1.2 — Tags**
Record:
- `Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>` (author)
- `Reviewed-by: Juergen Gross <jgross@suse.com>` (Xen maintainer —
  strong quality signal)
- `Signed-off-by: Juergen Gross <jgross@suse.com>`
- `Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com>`
  (patch 2/2 of v2 series)
- No `Fixes:`, `Reported-by:`, `Link:`, `Cc: stable@vger.kernel.org`, or
  `Tested-by:` tags

**Step 1.3 — Body analysis**
Record:
- **Bug:** `gntalloc_ioctl_alloc()` calls `kcalloc(op.count, ...)`
  before verifying `op.count` against the global grant limit.
- **Symptom:** User-controlled counts above the limit still reach kernel
  allocation; limit enforcement uses addition with mixed signed/unsigned
  types that can wrap; `priv->index` advance uses 32-bit multiply.
- **Failure modes:** Unnecessary kernel allocations (memory
  pressure/DoS), potential limit-check bypass via wrap, corrupted per-
  file mmap index.
- **Root cause:** Validation ordering and unsafe arithmetic on user-
  supplied `op.count` (`__u32`).

**Step 1.4 — Hidden bug fix?**
Record: **Yes.** Although the subject says "validate," this is a real
bug fix: premature allocation, integer-overflow-prone limit check, and
32-bit multiply before 64-bit assignment.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
Record:
- 1 file: `drivers/xen/gntalloc.c` (+11 / -2 net)
- Function modified: `gntalloc_ioctl_alloc()`
- Scope: single-file, surgical ioctl-path fix

**Step 2.2 — Code flow per hunk**

| Hunk | Before | After |
|------|--------|-------|
| Early check | `kcalloc()` immediately after `copy_from_user()` |
Snapshot `limit` with `READ_ONCE()`, reject `op.count > limit` with
`-ENOSPC` before any allocation |
| Locked limit check | `gref_size + op.count > limit` | Subtraction:
`gref_size > limit_snapshot \|\| op.count > limit_snapshot - gref_size`
under `gref_mutex` |
| Index advance | `priv->index += op.count * PAGE_SIZE` (32-bit
multiply) | `priv->index += (uint64_t)op.count * PAGE_SIZE` |

Record: Normal ioctl path and error paths affected; early rejection
avoids `kcalloc`/`kfree` on doomed requests.

**Step 2.3 — Bug mechanism**
Record:
- **Category:** Input validation + integer overflow / type-safety
- **Mechanism 1:** User `count` drives `kcalloc()` before limit
  enforcement → kmem pressure DoS on `/dev/xen/gntalloc`
- **Mechanism 2:** `gref_size + op.count > limit` mixes `int` counters
  with `uint32_t` count; addition can wrap, potentially bypassing limit
  and reaching `add_grefs()`'s `for (i = 0; i < op->count; i++)` loop
- **Mechanism 3:** `op.count * PAGE_SIZE` computed in 32-bit arithmetic
  before widening to `uint64_t priv->index`

**Step 2.4 — Fix quality**
Record: Minimal, obviously correct, no API changes. Early check is
cheap. Subtraction check is standard overflow-safe idiom.
`READ_ONCE(limit)` snapshots admin-tunable limit. Regression risk:
**low** — only tightens validation; legitimate allocations within limit
unchanged.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
Record: Buggy lines in `gntalloc_ioctl_alloc()` trace to `5d324e5159d9e`
in this shallow checkout (file unchanged since tree root). The ioctl
allocation pattern is long-standing driver code, not a recent
regression.

**Step 3.2 — Fixes: tag**
Record: Not applicable — no `Fixes:` tag present.

**Step 3.3 — Related file history**
Record: Shallow tree shows only merge commit touching
`drivers/xen/gntalloc.c`. IOCTL path with `kcalloc`-before-limit pattern
is present at HEAD.

**Step 3.4 — Author context**
Record: Yousef Alhouseen submitted the v2 series. Juergen Gross (active
Xen maintainer; recent xen commits in tree include `xen/privcmd`
security fixes) reviewed and signed off.

**Step 3.5 — Dependencies**
Record: **Series dependency identified.** Cover letter ([openwall v2
0/2](https://lists.openwall.net/linux-kernel/2026/06/26/2112)) states
patch 1/2 (`xen/gntalloc: make grant counters unsigned`) is a
prerequisite for overflow-safe unsigned arithmetic. **This commit (2/2)
applies cleanly standalone** to the current tree (`git apply --check`
succeeded). Patch 1/2 is a 3-line companion change (`int` → `unsigned
int` for `limit`/`gref_size`, `module_param(limit, uint, ...)`). Not a
hard blocker for backporting this patch, but both should ideally ship
together for a complete fix.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**
Record: `b4 dig -c <sha>` unavailable (commit not in local tree). Found
via openwall:
- Cover: https://lists.openwall.net/linux-kernel/2026/06/26/2112
- Patch 1/2: https://lists.openwall.net/linux-kernel/2026/06/26/2113
- Patch 2/2 (this commit): https://lists.openwall.net/linux-
  kernel/2026/06/26/2114
- v2 split unsigned-type changes into prerequisite per maintainer
  feedback

**Step 4.2 — Reviewers**
Record: To: Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko; Cc:
xen-devel, linux-kernel. Juergen Gross reviewed.

**Step 4.3 — Bug report**
Record: No external bug report or syzbot link. Issue identified by code
review / proactive hardening.

**Step 4.4 — Series context**
Record: 2-patch v2 series, same file. Patch 1 prepares unsigned
counters; patch 2 adds validation. Both are small and complementary.

**Step 4.5 — Stable list**
Record: No stable-list discussion found. lore.kernel.org returned 403
(bot protection); openwall used instead.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
Record: `gntalloc_ioctl_alloc()` (modified); related: `add_grefs()`,
`do_cleanup()`.

**Step 5.2 — Callers**
Record: `gntalloc_ioctl()` → `case IOCTL_GNTALLOC_ALLOC_GREF` →
`gntalloc_ioctl_alloc()`. Reachable from userspace via `ioctl()` on
`/dev/xen/gntalloc` (`miscdevice`, name `"xen/gntalloc"`).

**Step 5.3 — Callees**
Record: `copy_from_user`, `kcalloc`, `mutex_lock/unlock`, `do_cleanup`,
`add_grefs` (allocates pages, grants foreign access in a loop over
`op->count`), `copy_to_user`, `kfree`.

**Step 5.4 — Reachability**
Record: Userspace ioctl on Xen systems with
`CONFIG_XEN_GRANT_DEV_ALLOC`. Kconfig: "Allows userspace processes to
create pages with access granted to other domains." Impact surface: Xen
dom0 / Xen PV frontends using grant allocation — not universal, but
ioctl is explicitly user-facing.

**Step 5.5 — Similar patterns**
Record: No other instances of this exact bug pattern in `gntalloc.c`.
The `add_grefs()` loop makes a bypassed limit check especially dangerous
(unbounded iteration + per-page allocations).

---

## Phase 6: Cross-Reference Against Local Tree (6.18.44)

**Step 6.1 — Buggy code present?**
Record: **Yes.** Local tree is `v6.18.44-1-g2736c32da98b9` / `6.18.44`.
At HEAD, `gntalloc_ioctl_alloc()` still does `kcalloc()` before limit
check, uses `gref_size + op.count > limit`, and `priv->index += op.count
* PAGE_SIZE`. `limit`/`gref_size` are `static int`.

**Step 6.2 — Backport complications**
Record: **Clean apply** — `git apply --check` on the provided diff
succeeded with no conflicts.

**Step 6.3 — Related fixes already present?**
Record: No — `git log --grep="gntalloc"` and `--grep="validate grant
count"` returned nothing. Fix not yet in this tree.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem**
Record: `drivers/xen/` — Xen grant-table userspace interface.
Criticality: **IMPORTANT** for Xen deployments (dom0, paravirt
frontends); **PERIPHERAL** relative to all Linux users.

**Step 7.2 — Activity**
Record: Xen subsystem actively maintained; recent security fixes in
related xen drivers (`privcmd`, `sys-hypervisor`) in this tree.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**
Record: Xen systems with `CONFIG_XEN_GRANT_DEV_ALLOC` (default `m`),
users/processes that can open `/dev/xen/gntalloc` and issue
`IOCTL_GNTALLOC_ALLOC_GREF`.

**Step 8.2 — Trigger conditions**
Record:
- **Common:** `op.count > limit` (default 1024) → unnecessary `kcalloc`
  before `-ENOSPC`; repeatable for memory pressure
- **Less common:** Large `limit` module parameter + crafted counts →
  addition wrap bypassing limit → massive `add_grefs()` loop
- **Less common:** Large `op.count` with raised limit → 32-bit `op.count
  * PAGE_SIZE` wrap corrupting `priv->index`
- Unprivileged users need device access; still a valid hardening for any
  caller with ioctl access

**Step 8.3 — Failure severity**
Record:
- Memory pressure / DoS from premature allocations: **MEDIUM-HIGH**
- Limit bypass → huge grant allocation loop: **CRITICAL** (hang/OOM) if
  triggerable
- Index corruption: **HIGH** (broken mmap offsets / grant bookkeeping)
- Overall: **HIGH** for affected Xen configurations

**Step 8.4 — Risk vs benefit**
Record:
- **Benefit:** HIGH for Xen users — closes validation gap on user-facing
  ioctl
- **Risk:** LOW — 11 lines, no behavior change for valid requests within
  limit
- **Ratio:** Strong benefit, low risk

---

## Phase 9: Final Synthesis

**Step 9.1 — Evidence summary**

**FOR backport:**
- Fixes real bugs (premature user-sized allocation, overflow-prone limit
  check, 32-bit multiply)
- Small, surgical, maintainer-reviewed
- Applies cleanly to 6.18.44
- Buggy code confirmed present in this tree
- User-facing ioctl path on Xen systems
- Companion patch 1/2 is tiny and should accompany for complete
  unsigned-counter hardening

**AGAINST backport:**
- Xen-specific; not all stable users run Xen
- No syzbot/user crash report (proactive fix)
- Ideally paired with patch 1/2 for full unsigned arithmetic story
  (minor concern, not a blocker)

**Unresolved:** Whether reviewers explicitly nominated for stable (no
thread replies fetched beyond cover/patch text).

**Step 9.2 — Stable rules checklist**
1. Obviously correct and tested? **PASS** — logic is straightforward;
   reviewed by Juergen Gross; no `Tested-by`
2. Fixes real bug affecting users? **PASS** — ioctl validation /
   overflow issues on Xen grant allocator
3. Important issue? **PASS** — DoS, potential limit bypass, index
   corruption (HIGH severity on Xen)
4. Small and contained? **PASS** — 1 file, ~13 lines changed
5. No new features/APIs? **PASS** — validation only
6. Can apply to local tree? **PASS** — verified clean apply

**Step 9.3 — Exception category**
Record: None (standard bug fix, not device ID/quirk/docs/build).

**Step 9.4 — Decision rationale**
This commit should be backported to the local **6.18.44** stable tree.
The buggy ioctl ordering and arithmetic are present, the fix is minimal
and maintainer-reviewed, and the failure modes (kmem pressure, limit
bypass, index corruption) are meaningful on Xen systems. Backport patch
1/2 (`make grant counters unsigned`) alongside this commit for the
complete v2 series.

---

## Verification

- [Phase 1] Parsed subject, tags, body from provided commit message
- [Phase 1] Identified patch as 2/2 via Message-ID `43781-3`
- [Phase 2] Read current `gntalloc_ioctl_alloc()` at HEAD — confirmed
  buggy ordering
- [Phase 2] Verified `limit`/`gref_size` are `static int`, `op.count` is
  `__u32`, `priv->index` is `uint64_t`
- [Phase 2] Verified `kcalloc` uses `check_mul_overflow` in
  `include/linux/slab.h`
- [Phase 3] `git blame -L 283,302 drivers/xen/gntalloc.c` — lines from
  `5d324e5159d9e`
- [Phase 3] `git log --oneline -20 -- drivers/xen/gntalloc.c` — shallow
  history
- [Phase 3] `git log --grep` for gntalloc/validate — no existing fix in
  tree
- [Phase 4] `b4 dig -c 3218686be45b8` — no result (commit not in tree)
- [Phase 4] Fetched openwall cover + patches 1/2 and 2/2 — confirmed v2
  series and prerequisite note
- [Phase 4] lore.kernel.org — 403 Forbidden (unverified for reviewer
  stable nominations)
- [Phase 5] Traced call chain: `gntalloc_ioctl` → `gntalloc_ioctl_alloc`
- [Phase 5] Confirmed miscdevice `"xen/gntalloc"` registration
- [Phase 5] Read `add_grefs()` — loops `op->count` times with page alloc
  + grant setup
- [Phase 6] `git describe HEAD` → `v6.18.44-1-g2736c32da98b9`; `make
  kernelversion` → `6.18.44`
- [Phase 6] `git apply --check` on provided diff — **clean apply**
- [Phase 6] Confirmed pre-fix code via `git show
  HEAD:drivers/xen/gntalloc.c`
- [Phase 7] Read `drivers/xen/Kconfig` `XEN_GRANT_DEV_ALLOC` —
  userspace-facing, default `m`
- [Phase 8] Assessed severity from code paths (not from unverified crash
  reports)

**YES**

 drivers/xen/gntalloc.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index f93f73ecefeee..462f67dc32751 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -272,6 +272,7 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_private_data *priv,
 	int rc = 0;
 	struct ioctl_gntalloc_alloc_gref op;
 	uint32_t *gref_ids;
+	unsigned int limit_snapshot;
 
 	pr_debug("%s: priv %p\n", __func__, priv);
 
@@ -280,6 +281,12 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_private_data *priv,
 		goto out;
 	}
 
+	limit_snapshot = READ_ONCE(limit);
+	if (op.count > limit_snapshot) {
+		rc = -ENOSPC;
+		goto out;
+	}
+
 	gref_ids = kcalloc(op.count, sizeof(gref_ids[0]), GFP_KERNEL);
 	if (!gref_ids) {
 		rc = -ENOMEM;
@@ -292,14 +299,16 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_private_data *priv,
 	 * are about to enforce, removing them here is a good idea.
 	 */
 	do_cleanup();
-	if (gref_size + op.count > limit) {
+	limit_snapshot = READ_ONCE(limit);
+	if (gref_size > limit_snapshot ||
+	    op.count > limit_snapshot - gref_size) {
 		mutex_unlock(&gref_mutex);
 		rc = -ENOSPC;
 		goto out_free;
 	}
 	gref_size += op.count;
 	op.index = priv->index;
-	priv->index += op.count * PAGE_SIZE;
+	priv->index += (uint64_t)op.count * PAGE_SIZE;
 	mutex_unlock(&gref_mutex);
 
 	rc = add_grefs(&op, gref_ids, priv);
-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 15:49:18 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 15:49:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404222.1638046 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x14Fq-0004Us-Rc; Mon, 31 Aug 2026 15:49:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404222.1638046; Mon, 31 Aug 2026 15:49:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x14Fq-0004Uj-NY; Mon, 31 Aug 2026 15:49:02 +0000
Received: by outflank-mailman (input) for mailman id 1404222;
 Mon, 31 Aug 2026 15:49:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92) id 1x14Fo-0004UV-MX
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 15:49:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x14Fn-005Nvf-HQ
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 17:48:59 +0200
Received: from [10.42.69.11] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a95a244-2eae-0a2a0a5409dd-0a2a450be100-40
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 17:48:59 +0200
Received: from [40.93.195.60]
 (helo=SN4PR2101CU001.outbound.protection.outlook.com)
 by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <Michal.Orzel@amd.com>)
 id 6a95a269-b7e8-0a2a450b0019-285dc33ce0a3-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 17:48:58 +0200
Received: from PH7P220CA0123.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:327::26)
 by IA1PR12MB7664.namprd12.prod.outlook.com (2603:10b6:208:423::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Mon, 31 Aug
 2026 15:48:51 +0000
Received: from CY4PEPF0000E9D3.namprd03.prod.outlook.com
 (2603:10b6:510:327:cafe::9) by PH7P220CA0123.outlook.office365.com
 (2603:10b6:510:327::26) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.13 via Frontend Transport; Mon,
 31 Aug 2026 15:48:48 +0000
Received: from satlexmb07.amd.com (165.204.84.17) by
 CY4PEPF0000E9D3.mail.protection.outlook.com (10.167.241.138) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.21.382.8 via Frontend Transport; Mon, 31 Aug 2026 15:48:48 +0000
Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com
 (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 31 Aug
 2026 10:48:47 -0500
Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com
 (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend
 Transport; Mon, 31 Aug 2026 10:48:44 -0500
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MhAWVU6yo/zBMNQbT1vhx4FQ5Y3AI5fggDjQxmOvWhaunV0nQyVM6cm74rwnHxb3JOnIBzrwyQWIdzQjWc78voDBqKY6UcHe3W5JagLNCMx49+4GjnRSVaYJ4EM5U7Y5W9R+3K3MbmZugNmY+jIYbT+nYC/nuONtlByMMX8NKFfZhC2GeXgSAPzbJ68hm7rbKXABKOIgjInnv1jcFaVDtl4pm94/KDI06zx5tJGEuau3Us5QQkqcziDAgiNlHZ0B6s1pE3PZkUGeB0AplFxYQh96XpsUDvUX6lgL+1KgMtTRR579hdsGp4homI3RbVxWVQgXp3+2yI7ywOtOoQ5ZAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=osTvsVhTWtmBmIq3KzqWnv9M3d8c/+5re+vhRnScSg0=;
 b=SN85irWuHS3uZRMRIQLj9PgoBP6qjVUa/FU37poO97+mC+dVS9zOL5TuC2umgZm0KuxJWh45xIDq4KgN3Fsy+E6e6cy/39Gz8IMjREkQNPsjn7TSZ5B+eftsOIC3sjW8e0wpDgNvylJqC4HRwtq1F3wkAPgFL7uXRwN3msZ89xajBowAgSiGoh7MUYwresj/8y28Ob2i3nbgmIzDf6ZwgGOnaYmkKcw2/GfenXiMjW/06BigW+d88bkXvbsdRVRIfOiHu4sSl7zTEas/q0SbKndYXOGB4SXM+ZAAuqs6PjEKiK+EtyDB0VdbOj39lWWx+bbIhCNwGV6Wv6qtE/A/bg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=osTvsVhTWtmBmIq3KzqWnv9M3d8c/+5re+vhRnScSg0=;
 b=JD8aqiICj/+aDCgkM2aqWd6AX0OssNXra4HqgVZMwFL9Yx47/k3LmHjk7oRxMRBi6lyXAG7M2jkw3CUC1XqYagRHITZlucZfwdaCO8Uz4Ng3D5oA3GuvI35UTXrZmyRuQTr+E+MghrRqClLiKdJcBUGQlnXd59+C3VdevjRgVsI=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
 smtp.mailfrom=amd.com; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C
Message-ID: <b65fcc50-b249-4505-a212-b2f60c55f86d@amd.com>
Date: Mon, 31 Aug 2026 17:48:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 02/20] xen/dom0less: turn max_init_domid into a common
 variable
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	<xen-devel@lists.xenproject.org>
CC: Romain Caritey <Romain.Caritey@microchip.com>, Baptiste Le Duc
	<baptiste.le-duc@vates.tech>, Zheng Zhang <zhangzheng@iscas.ac.cn>, Stefano
 Stabellini <sstabellini@kernel.org>, Julien Grall <julien@xen.org>, Bertrand
 Marquis <bertrand.marquis@arm.com>, Volodymyr Babchuk
	<Volodymyr_Babchuk@epam.com>, Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>, Jan Beulich <jbeulich@suse.com>,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger@xenproject.org>, Timothy Pearson
	<tpearson@raptorengineering.com>, Alistair Francis
	<alistair.francis@wdc.com>, Connor Davis <connojdavis@gmail.com>, Teddy Astie
	<teddy.astie@vates.tech>
References: <cover.1787836900.git.oleksii.kurochko@gmail.com>
 <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.com>
From: "Orzel, Michal" <michal.orzel@amd.com>
Content-Language: en-US
In-Reply-To: <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D3:EE_|IA1PR12MB7664:EE_
X-MS-Office365-Filtering-Correlation-Id: 4ee5365e-1273-4b33-0b1c-08df077758eb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|36860700016|82310400026|7416014|376014|1800799024|56012099006|10067099003|4143699003|5023799004|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	VxDpg6SA175mFY2YlvzT33HX8cf2FqT9U0rG3JCgeVXUoSrqHsu9kH5++t6kj7/DCRU8XktpqpHZpwZ7x1hZfHYcNNn4D2sBGpBlcTZAeTlGdXgcvfGxzUhCMbZc4tm9USlQFMIfAKoY17heDUESRYPBFJvxZXI83werSOV4w0/YPtd9sG41RAeu4e3Zs7/CIdKZwYj80L6HDx0JYwa+bIcvrzNRP0+I6b8XoZ6v9wEUEhw5SIQH3ERVlbxMSTJF6xBD4dGSeigq4DYJLGAAlyFEsOv7Fx2em/9keg7Sr3pODGF8AOvlvUIEAlzm0S+P7bO2Hl5352E/ykXZpLmQerIASM7aS62WTy2moogYrtYgQ2tAzvpe8vnrWaj+y5/5gF09WgD8S+r3lS32cnZ11DzvbY/dxGcY3b/jbO1t6Yb1eQcL5UGxSC9vDNEntSmgJmQs8faAJlVGUf8rNpz9PjxllXEC3w9Y+Yg7lwJt0fXEdNQBGJ2KRJjGyiKcAz+Gtzh3NRxRng4okGxOAOxsw+ZzDCd48shz8JBQo8l6Lx11q9VOiUDmco2LcyOpm3u2ipQiApUWq4KrMKe4MjRAFEEFIpg/hM1yhPf66S2rs0dAcomyN0vU7QftxnT4M9Fexut4QkqLTX+IkiWpW8MCABvVEOA5F1eanYpzN96pwY0G5koW85oDYxhfgnWf498PbPS2AIRurH49vhAJTt6ecQ==
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(82310400026)(7416014)(376014)(1800799024)(56012099006)(10067099003)(4143699003)(5023799004)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	bf+0R0MeWt1R0Mps3pWXBuVzvgc4hqj4VLa2bqK6w5KaabZMJjidr1hpUXaIohng3GGv4hjdGtEIuJllKoi+QY5tK3trNxAby05C11LJTXhOSf67Csww9DnyZZYwGO4dMStjGdLJBRiMjRShWGgqVAKqdijkiGiqZQ1oCTvDOkZtZHWs2DVOioiEsv1QWHeSKHBLv98uHgftRXoYNoraSCciMN0Z5qx5djqPm1DGDp5iD1eU/FNA/AdfwTI6O8qJKhUSqvnqNrq9I0CrXjHmMSzekNqxXl+GwuafVjUu7KEgbPO5C45jXrTkXbgs1eeXKZadlpp5mPAEfQFkQW1AP8b7LIk58vRZ+ae1gHtlQ3e2RviRPri5tb3AgBDjFGJugr/TORlO9DNFr0lWBVfdUjxs4Nkaxu4U8/Wow/SPP8UDr3UN24+MEKw4qlf4OP0r
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 15:48:48.3336
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee5365e-1273-4b33-0b1c-08df077758eb
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D3.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7664
X-purgate-ID: tlsNG-42698a/1788191339-A8AC89EA-B7A3D020/10/73395122804
X-purgate-type: spam
X-purgate-size: 5453



On 27-Aug-26 17:18, Oleksii Kurochko wrote:
> Until now every architecture carried its own notion of max_init_domid:
> Arm defined a real variable (declared in asm/setup.h, defined in
> setup.c), while ppc, riscv and x86 each provided a "#define
> max_init_domid (0)" stub in their asm/setup.h. This duplicated the same
> declaration across all arches and placed a purely dom0less concept in
> arch setup headers.
> 
> Now that the dom0less build code lives in common (xen/common/
> device-tree/dom0less-build.c sets max_init_domid, and the console
> serial-input switcher reads it), there is no reason for the symbol to be
> per-arch. Provide a single declaration in <xen/dom0less-build.h>, with
> the !CONFIG_DOM0LESS_BOOT stub kept there as well, so there is one source
> of truth and the arch headers no longer need to mention it. Update
> console.c to include <xen/dom0less-build.h> for the declaration instead
> of relying on asm/setup.h.
> 
> Place the definition in xen/common/domid.c rather than in dom0less-
> build.c. The latter is built as dom0less-build.init.o, i.e. the whole
> object is relocated into the .init.* sections and freed after boot,
> whereas max_init_domid must outlive boot because it is read at runtime
> by the console serial-input switcher. domid.c is always linked (obj-y)
> and resides in regular (non-init) sections, so it is a correct home for
> the variable. It is marked __ro_after_init since it is only updated
> while creating boot-time domains and read-only afterwards, and guarded
> by CONFIG_DOM0LESS_BOOT as domid.c itself is unconditional.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> ---
> Changes in v6-8:
>  - Nothing changed. Only rebase.
> ---
> Changes in v5:
>  - Add Reviewed-by: Jan Beulich <jbeulich@suse.com>
> ---
> Changes in v4:
>  - New patch.
> ---
> ---
>  xen/arch/arm/include/asm/setup.h   | 2 --
>  xen/arch/arm/setup.c               | 2 --
>  xen/arch/ppc/include/asm/setup.h   | 2 --
>  xen/arch/riscv/include/asm/setup.h | 2 --
>  xen/arch/x86/include/asm/setup.h   | 2 --
>  xen/common/domid.c                 | 5 +++++
>  xen/drivers/char/console.c         | 1 +
>  xen/include/xen/dom0less-build.h   | 7 +++++++
>  8 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 0adfa4993a8f..2af780512540 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -25,8 +25,6 @@ struct map_range_data
>      struct rangeset *irq_ranges;
>  };
>  
> -extern domid_t max_init_domid;
> -
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>  
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 6310a47d68b6..86532d0a35b6 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -62,8 +62,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
>  bool __read_mostly acpi_disabled;
>  #endif
>  
> -domid_t __read_mostly max_init_domid;
> -
>  static __used void noreturn init_done(void)
>  {
>      /* Must be done past setting system_state. */
> diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
> index e4f64879b68c..956fa6985adb 100644
> --- a/xen/arch/ppc/include/asm/setup.h
> +++ b/xen/arch/ppc/include/asm/setup.h
> @@ -1,6 +1,4 @@
>  #ifndef __ASM_PPC_SETUP_H__
>  #define __ASM_PPC_SETUP_H__
>  
> -#define max_init_domid (0)
> -
>  #endif /* __ASM_PPC_SETUP_H__ */
> diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
> index 2215894cfbb1..73ce2f293348 100644
> --- a/xen/arch/riscv/include/asm/setup.h
> +++ b/xen/arch/riscv/include/asm/setup.h
> @@ -5,8 +5,6 @@
>  
>  #include <xen/types.h>
>  
> -#define max_init_domid (0)
> -
>  void setup_mm(void);
>  
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
> index b01e83a8ed9f..5925c5f39cff 100644
> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -68,6 +68,4 @@ extern bool opt_dom0_verbose;
>  extern bool opt_dom0_cpuid_faulting;
>  extern bool opt_dom0_msr_relaxed;
>  
> -#define max_init_domid (0)
> -
>  #endif
> diff --git a/xen/common/domid.c b/xen/common/domid.c
> index b0258e477c1a..cd46cf952be6 100644
> --- a/xen/common/domid.c
> +++ b/xen/common/domid.c
> @@ -9,6 +9,11 @@
>   */
>  
>  #include <xen/domain.h>
> +#include <xen/dom0less-build.h>
NIT: "dom0less" comes before "domain" when it comes to alphabetical order I think.

> +
> +#ifdef CONFIG_DOM0LESS_BOOT
> +domid_t __ro_after_init max_init_domid;
> +#endif
>  
>  static DEFINE_SPINLOCK(domid_lock);
>  static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index fcacf37c52f0..61e92491e40a 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -31,6 +31,7 @@
>  #include <xen/warning.h>
>  #include <xen/pv_console.h>
>  #include <asm/setup.h>
NIT: This can be dropped - I don't see anything relying on it in this file.

Other than that:
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 19:14:27 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 19:14:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404354.1638074 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x17SO-000317-5W; Mon, 31 Aug 2026 19:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404354.1638074; Mon, 31 Aug 2026 19:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x17SO-00030z-28; Mon, 31 Aug 2026 19:14:12 +0000
Received: by outflank-mailman (input) for mailman id 1404354;
 Mon, 31 Aug 2026 19:14:10 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <andrew.cooper@citrix.com>) id 1x17SL-00030t-Sr
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 19:14:10 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x17SK-005m3j-HI
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 21:14:08 +0200
Received: from [10.42.69.12] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a95d263-2eae-0a2a0a5409dd-0a2a450cb254-28
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 21:14:08 +0200
Received: from [52.101.53.31]
 (helo=BL0PR03CU003.outbound.protection.outlook.com)
 by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <andrew.cooper@citrix.com>)
 id 6a95d27e-f479-0a2a450c0019-3465351f733a-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 21:14:07 +0200
Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7)
 by CH0PR03MB6163.namprd03.prod.outlook.com (2603:10b6:610:d2::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Mon, 31 Aug
 2026 19:14:03 +0000
Received: from CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com
 ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Mon, 31 Aug 2026
 19:14:03 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=v+QmqeSmU+OI1Wg4DF1x9V0ifJBQh9d1qiZka8LVMditbyO39+zhnVGFpvhtCZeaxDx4kuxaFyv3yYb+ffOHsdoo7EPWmNh5/i2QN7OlL7FlVtnPBn00ADraICD0/3DnphQW4cS2RL/PS5xpEXvwZclMbuF+yVjLIHCkkfkeqqiMpUldI7xPDmMK19WKPzcRZGI8Z3/FzCTKtJEIXbgmW1yPgyJcEuKLhSKILRmo4+sQfzlJ6wWaACPhBkM94QDW3GRJRedJFxWxpnpPzGdaMv/rKI5Zx3Mi5kfsM/vJMan2R43oqj2NeA9GBApf/KBwfvcy8906xNOPwcM5RmvLeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hasiMGvSWOnhhlezsOC8sWqiCwztqsJ9genIk9j2i/k=;
 b=bpIGIS442Rhk3rbp81bQ9t8NtiPTH2w2/myEZj3Z3JNUAaBukyK2sV90mGAh9YBec7kSpYz8PB10psuL2NuteD3acgY3kD4NsZe3N1tDJ/VCPNVeIYt84BytpxI+kUi+uJ89ZgNKWvPV3IMwda+gZxGIeB0ARJT+2VUK3TRE+KXghSGFMntS8MP7xhK+Buc7e0sRNKs2SyaPsTyLCb7e7UYGb9ty42bg8mcGmVAqyz9Z9IvJeMfiYWT+cdC3PVl4XKnOjDIEOyQLcHONsyREG0fuyqx4bYnYs10QYaqmeio+E0bVI/QJzXIhhplhXGQXxWth7ztH+Mqm64JZzvE2Ow==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com;
 dkim=pass header.d=citrix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=hasiMGvSWOnhhlezsOC8sWqiCwztqsJ9genIk9j2i/k=;
 b=AOfY7Kwedp4NdZcmq54XkocjKIyvvZKRX4l9MfDCUXMh0z0sm5MqEnEwpiPMgAEDpzOPmQjE2cBDLGo85Mhw79K3ASZCW0ubcg+7gPLJZG1Km+CToZVFKu+nQyp21MfLVh6u62tM2msFXgC0bAMp3mr15ID5Y98oMA+C77WS4Bo=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=citrix.com;
Message-ID: <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com>
Date: Mon, 31 Aug 2026 20:13:59 +0100
User-Agent: Mozilla Thunderbird
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
 Nicola Vetrini <nicola.vetrini@bugseng.com>,
 Teddy Astie <teddy.astie@vates.tech>, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 <roger@xenproject.org>
Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places
To: Jan Beulich <jbeulich@suse.com>,
 "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com>
 <d0f991de-db67-4f49-aef0-25c590b3889e@suse.com>
Content-Language: en-GB
From: Andrew Cooper <andrew.cooper3@citrix.com>
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <d0f991de-db67-4f49-aef0-25c590b3889e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0045.GBRP265.PROD.OUTLOOK.COM
 (2603:10a6:600:2ac::21) To CH8PR03MB8275.namprd03.prod.outlook.com
 (2603:10b6:610:2b9::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH0PR03MB6163:EE_
X-MS-Office365-Filtering-Correlation-Id: a78bae3c-0a7d-4a9f-b833-08df079404fc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|6133799003|56012099006|10067099003|4143699003|5023799004|11063799006|18002099003|22082099003;
X-Microsoft-Antispam-Message-Info:
	DnTWbh4urRLZQeqqyhK1GDJXMb9pzLyFv52HbFSuHlJLZycD3ub+aVo8o9oqZPpusXCMfJDkdcpvqy9mly+t/DMiMKiL8nxBh74c15utIiFUgVfCEWG59ZBEFI5qrx+DCuwcIOwkfduv4Efl4XyWrMB6g9q9JtcNbwYbwIXB/b7fWnLH0DPlXFa0G2yFhc4tG+AXYZhUZEndonEjhp7pPP4ltNVWQiDNUpwSS/PIm4ZHifLToL7PNdjgx3tui0wMyotYcVdAkkHCT8zoSVR0olO1jtqKRqR9Tmjm1omPOPl95FT99qm+v3btH/Vsu4k3vykq87smLKpj9LA0dKY4BOIa4x+QKx2DA0b+Gp4gj3SzfeAL+4yHvknwEH5OTuKumZu6OG0df033bNWf0v3xGUgB0L4tH2BmWDv6W9ogK6Dh7ogi4ElqcEiw1sOESnyEobKK5+XCe0YbFlFPCPFUc36v7R7d8UMGwwQb/n8y7mmG0cTAEdNVNPuy6BAf2RR3cd+UVV/lOfNi1HrxuySsDcwKbD6LpPxn4CHl34CnW4Jesx6H+EOxu3ozb1lg7bcZBfMKljITzzYIy2anVpc6chukJMOtPYHD8a/P+Pg0Ov+WMbq9yM6AbHJIKFIrABTfnY0tTeG5o15DQRjBnmLRgnzVO+I5/JX9/hpaBxMaEaw=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(6133799003)(56012099006)(10067099003)(4143699003)(5023799004)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?S3pVWTgzcHRJYktNZW5pMHIwVmZrdU4rVEthNzZKTWVvUDRrWDI1cFgzR0RJ?=
 =?utf-8?B?YmMxM010bUhIN2RXNlhacjlUZ1ZHWlhUcXY0ZjhvN2gyOEwxUzFYSWtoUjhJ?=
 =?utf-8?B?T0RBT01yYnhFSkpMZDZZVkdxUE1CUGlNekRlUnh1bXQyNVo0M1YwVXU1M0pL?=
 =?utf-8?B?aDlzQ1BEdTZocjJKQXJnR3FOVzZlNmgyVk90aGs5U0orMWNIY3dtREo0bnQz?=
 =?utf-8?B?TTU3eTJNb04rWWpFeXN1K3JUakxRR3VPVmw0d0pvcUNLWHhuRllQbnFLVmNH?=
 =?utf-8?B?bjNORFo2R0xPVmExTWRPbEJVT0h3N0hTWnhjK3R1U1F6bHBHSzhlOE14UGZ2?=
 =?utf-8?B?Zk4zSUNVWVNpSG8xanBXbFJNdHkvN1BOTys0WTVtZG0rVFlqU0h1c1pMck93?=
 =?utf-8?B?VFBkZ3AzMHpxeC9ZbGFyamhseXhaK3dKL2c1amVQMEdzc3BtVmowMW9POTVm?=
 =?utf-8?B?bUJiaE1SL1pIS25JbG9vMUFHZkVrT0trYnVOQ1JFbHZ2SXlidjdlV0drZFAw?=
 =?utf-8?B?MTdaaG5JM1lpOGtUQitJcXVzOENDbFN5dUZwZGFvTFlESzBMenVmQXN6UXJG?=
 =?utf-8?B?MTVGajFNMjdyWUdFR3BVVkFTYklZb3duVGV0TnJ5ZU1ySmxhNFJkVkxLZUY3?=
 =?utf-8?B?Tm9hSlY4SUQ2UG4yRUt1RmkrT1RJc24rUXBwWUZkcVdwNkpWWTJVVFByVC9z?=
 =?utf-8?B?TkhKOG42L3FlTXlEc3EzajlMNXA5U3owZkdaTzZ5UERqbldyTUhmVE1SSUc1?=
 =?utf-8?B?QnJuWjJ5c1B3UXVBVmE3TVZ4UmRhOHdFY3dlYXEvOVBHRUphSm4yUm82Wlpz?=
 =?utf-8?B?VDBsUWlrZUZ5aVhLeHZyRCtoQTBnU2xaOGFIb3RXcXhpT1BMa2J3VzVTSHJF?=
 =?utf-8?B?ZG5KMHZJRE9mT1RWQ1RDZWc3d2dpbEM4bVJCR201MWJVaG1RTVlXVS9JZ0tl?=
 =?utf-8?B?ZnIxZHVHUFQyRmJybnRNTUtHeDZNSnl4a1ZOQktWVFRjeC9DU2Uyc3RrcGJP?=
 =?utf-8?B?UEk4TStsV01TWFJKV0dWa3F6cmNpeDRqZldQUHUwTXVXSzdZNFVRdytJNGVN?=
 =?utf-8?B?dXNqL2FrSVFKcGorN3laQlR3MTdjN3dDL0h6elkvUCs0WWJWS1lwWm1wcmN4?=
 =?utf-8?B?NFNYTFczTDVNeHNhM3hIdTdtRlpmWWNoejUyOXQ2ZloyRlhKQm8rYkhGS0Ji?=
 =?utf-8?B?QVNQR2pTd1IzOWFFSVZXbWgxbmRmR0tma1RQRVBvQ1ZKV3loUjJCL2dzSito?=
 =?utf-8?B?K1ZKR3lPMUtxVFp3TUYxOTJRS2FjWnNsU3hyUDZUTlV5UEkrRFkwUnZQRmFB?=
 =?utf-8?B?SmlQZC9HeWxqdzRqZmdPcEFLT1hpSThXTFJHcDlaWFdVTGIwalQraExKQVBl?=
 =?utf-8?B?NGQwamphdk9udXlJYjFpTks4NzJLNzRHRVd4MVo4Mmd0Y0JLSnBaaGRNZ1Q4?=
 =?utf-8?B?eHdud3J1YjVhNDdTUXg3b2RZOWR5anRDQ3p3Zk9vSUl2MVQ3WVBZY3pYeERj?=
 =?utf-8?B?N2FRN1o1bEVscDQwSmREcnZHeE5rTUpPcHF5N1hHcmJucHljdnBWNzlkRThj?=
 =?utf-8?B?VU53enJseU9kUTNEaFAvVUxpT053TVY1c0g3OHhHL1FQazZWVWtDT1FoN0NR?=
 =?utf-8?B?eTN1WFdwU0g1VjMwSnEwYnNna1E3VG14dlRzSTdIZlVyaGREaVloamFaZnIr?=
 =?utf-8?B?cXlRWERhZnNQZ1I3TTVtcHI3U0ZyUllocEpSL2FvTlNNNDl4MVl0cWwzNk9l?=
 =?utf-8?B?aDNnN3FXdnlCSDYyeXN0MGxqT3BHbHB1NzltZXQrMjRqc21PY3c3NFlwZm1i?=
 =?utf-8?B?Umx2U2pmbkh5Mmp6Y0d2TjVNQXYxUEVZQzNQOEp6YTdxbnNreHh0K3pQemJu?=
 =?utf-8?B?K3FFY3o0anJkR3cwVWxPdkd1czNyUE40TmlDVnEvaERMNXdVWk03L0JMQ2g2?=
 =?utf-8?B?dWxyNk1LQ1FIbHFSZ2hFM0JkdUNwRDJUZkRKN3lpVlpWUHRvNUJ5em9qamRK?=
 =?utf-8?B?N1Q5T3dqYjBFcE82dURtTHpHRUdrQ3Q5WURnbmVra0xISTF6b0oxYUJLNDhO?=
 =?utf-8?B?ZXN4dVY0Y2RTN2VHMElpbXVhekVCWXM2SFdEakpnc2ZGdGJyOW4zUE8wK01D?=
 =?utf-8?B?dWRxUzB1Q3JHY3lkeDllSGE4N0VONlM0V2o2N1ZEZWlEWmVQT0daN1VHa3hX?=
 =?utf-8?B?Y3QyUjlPV1ZtMGFsUHZvSDlyc3JwcU5SbkZ5T2VyTUJhM0IzQ3lHaGJRaU0x?=
 =?utf-8?B?U3E3bUVDeDZ0Y3VucGpEY1ZESXZsUDhWTEVjZmtGZGh0cVRLZE4vTGIydFFw?=
 =?utf-8?B?a1VDUlFBcDB6T0lGYTRwRWtZZGJtYjdRalkrNXpXRW5IMlpvNXJidz09?=
X-OriginatorOrg: citrix.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a78bae3c-0a7d-4a9f-b833-08df079404fc
X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 19:14:03.2403
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: +hk4sPfFufHYnM6ihriOzPNHIYaB3YHC3hpp+aFYSYec7CGfrtPvP25lT5dvO+ccs8yJN/QF7x0ZBrCPgiWH5OSrIfmpPSlx0+vpgfBZLxI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR03MB6163
X-purgate-ID: tlsNG-d25034/1788203648-50321A5B-B7C56ABE/0/0
X-purgate-type: clean
X-purgate-size: 1582

On 28/08/2026 8:01 am, Jan Beulich wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu
>      case X86_ET_HW_EXC:
>          switch ( vec )
>          {
> -        case X86_EXC_DF: return do_double_fault(regs);
> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */
>          case X86_EXC_MC: return do_machine_check(regs);
>          }
>          break;
> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp
>      case X86_ET_HW_EXC:
>          switch ( regs->fred_ss.vector )
>          {
> -        case X86_EXC_DF: return do_double_fault(regs);
> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */
>          case X86_EXC_MC: return do_machine_check(regs);
>          }
>          break;
>

For starters you're missing a break, and the only reason this isn't a
compile error is the trailing comment.  Second, it's a tailcall anyway. 
There really is nothing unreachable anywhere in this construct.

But by far the most important, it the singular noreturn attribute on
do_double_fault() (elsewhere, and not visible when reading these two
functions) which is preventing #DF falling into #MC.   This introduces
fragility which did not exist previously.

do_double_fault() would conditionally return if we ever got around to
fixing espfix64.

So no - I'm going to insist that Eclair is taught to accept "return
some_noreturn_fn();" as intentional.  It is objectively less fragile
than the MISRA-preferred option.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Aug 31 19:26:06 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 19:26:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404362.1638083 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x17dq-0004qM-4a; Mon, 31 Aug 2026 19:26:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404362.1638083; Mon, 31 Aug 2026 19:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x17dq-0004qF-1m; Mon, 31 Aug 2026 19:26:02 +0000
Received: by outflank-mailman (input) for mailman id 1404362;
 Mon, 31 Aug 2026 19:26:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ziy@nvidia.com>) id 1x17dp-0004q3-C4
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 19:26:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x17dm-005nZD-W0
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 21:25:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a95d540-bab6-0a2a0a5309dd-0a2a450799d2-8
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 21:25:58 +0200
Received: from [52.101.52.3]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a95d545-b4ea-0a2a45070019-34653403f478-3
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 21:25:58 +0200
Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7)
 by SA1PR12MB8742.namprd12.prod.outlook.com (2603:10b6:806:373::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.7; Mon, 31 Aug
 2026 19:25:43 +0000
Received: from IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0360.008; Mon, 31 Aug 2026
 19:25:43 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qopNvCqwyjtINHg9KbusDN8tI+0areZ/p2iMXRGmfQddrtJNvqMjVgiQgY0bx5vzi4mwxMSMTb2b7TOl4/ezw2+k3v/CeC/EesAdXZEPhlAV1PsSgEEetHjQi4i/xT3Wf7S+V7jhEsb/YjVYRDwTbJlu1m5FyApQ7fMijSgoai8pPBxIrP3vq3xEjW7YhnAwKM/A/82CRYU8I4k0PDos+/+Mh6jxLwcZL8r8en16Kzkhi6+utMXGNPUFtbTF2mSzqEbvmCbfUPxUYjhwuXqHGOA4mvUC2Qva01U6tVHBcHG+7ySHt5WzrXHr+vr0dcjRjXsekd7wOkrpnIClHHG5TQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vgf8AR8nU41qGg9Ak0WHclMBa3GGy6njR91QTF4tAYc=;
 b=f2LXQUURhP00OpgtDmhaFE9YQ7KsUu1XBNpnFhT+bSa7mRif/K2BNMzxGW31t2+S8Od5hmQyZkEf4Mip8OUDXZjzcQl1RjbGd2qPv9kru/0Js2onb0tw5lH9JFY5/tWRPxb11iptCszJWqINkV4vYuBBxMMdqWfr3o8kLx8m7M3YoXhxmr4J3GhaereTASG7YSp0932dA4+AYNYTVsk0cx3lHaVRyMrRc3Nq6aC5jmt7lvQIEYivI3PBW2E8IuPSv1dfTUaEnPM9CsAfbP2KuzNBYdLWT0YFMxxlbORZM8vq1GqFUWhZa9MXd24UwbhxpoF4KsLNc3jSoHMdRC8bmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vgf8AR8nU41qGg9Ak0WHclMBa3GGy6njR91QTF4tAYc=;
 b=AnLySJ8xNyZ97ebPFNXZN29IGldk9Fty9paw9T41KDk9rwXaeBRhSKaGvoF7a/hKJiZHRNC30iSqBVI0bmNdrhXb4ZRqVbVDjISFRj2xzZxjm6E7TpMAAZoeaFLA0iYdYPkF3Y9Ocp08qJmXl7QuuSHZjYak2hTPKcBAHd2jH5wgDRiL/Jo04dT5/FjY1JHPxjOLE3BjHDyifdFKQkwh9jzlTUuijhbdN22fbgUEHTUvZUGobM8HA02NmmBB/uvxmLQ+1EPCRO0UVkCmEHdbP8HXGgnynfxTm2wuStx3ADPjR53oLYgncObo4D2HoNEc5i/AQzQ/iA8A/HqzHltkfA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
From: Zi Yan <ziy@nvidia.com>
Date: Mon, 31 Aug 2026 15:25:26 -0400
Subject: [PATCH v2 03/14] xen/grant-table: stop setting PG_private on pages
 for grant mapping
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20260831-remove-pg_private-v2-3-3668159cd9e8@nvidia.com>
References: <20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com>
In-Reply-To: <20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com>
To: David Hildenbrand <david@kernel.org>, 
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, 
 Andrew Morton <akpm@linux-foundation.org>, 
 Muchun Song <muchun.song@linux.dev>, Lorenzo Stoakes <ljs@kernel.org>, 
 "Liam R. Howlett" <liam@infradead.org>, Vlastimil Babka <vbabka@kernel.org>, 
 Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan <surenb@google.com>, 
 Michal Hocko <mhocko@suse.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, 
 Nico Pache <nico.pache@linux.dev>, Ryan Roberts <ryan.roberts@arm.com>, 
 Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>, 
 Lance Yang <lance.yang@linux.dev>, Usama Arif <usama.arif@linux.dev>, 
 Gregory Price <gourry@gourry.net>, 
 Ying Huang <ying.huang@linux.alibaba.com>, 
 Alistair Popple <apopple@nvidia.com>, Johannes Weiner <hannes@cmpxchg.org>, 
 Qi Zheng <qi.zheng@linux.dev>, Shakeel Butt <shakeel.butt@linux.dev>, 
 Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
 Zi Yan <ziy@nvidia.com>, Juergen Gross <jgross@suse.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>, 
 xen-devel@lists.xenproject.org
X-Mailer: b4 0.15.2
X-ClientProxiedBy: YQBPR0101CA0103.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c01:5::6) To IA0PR12MB8374.namprd12.prod.outlook.com
 (2603:10b6:208:40e::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|SA1PR12MB8742:EE_
X-MS-Office365-Filtering-Correlation-Id: 1f3a1d50-becc-4928-7fbb-08df0795a654
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|56012099006|10067099003|11063799006|22082099003|18002099003|921020;
X-Microsoft-Antispam-Message-Info:
	mWERXMMjK9kQc2LiNejUQRK8WVGOshRURzBVv5kubt6tg59eMCzbkoP4OWtVgPlHNRKGTtgg2dD4ekqzgQWaknj1rjm1eMjomysCajReh4A9zyl+yzoN091myPm88eBRn+gpD7sNnRMc36CdAcJbTF44jPAB+sWJOQ8eXRbzRLbOo78ZqYO3S1v3IF9Fv8RVPXLPusaXoO168g8iYjd9MRPt/WlIpUj82NRMNe3qewpA2hRCXjTGtEjrUhhDc7LSRSNjaa58PxyzAJOv2NFJYAhk8sx4sl87hUY/OA4Y2MLTrqkZYvtmttkrw4xgmLx9i/Bk56iW+MJhzYhc+RpVUus3m4WgtLHIM8IVYO6ElxcpEI9c95ZLePJdgvb5LjAsdILL6fw+4h4aeFKE6IT9m1bxK35AfIXdc6uXEKnGsooKZqrzuB0szfn5iaXXT+EG8ZtJkeoBsPIl5EmiwZGYN2qL+BYNGkgioNrrLClo04Y+ESsFM7h+26ebpa6JYAuYYsZbu5bz9KkVVeUeSTUqx3hGnszsjyJ2cQFAvqD5RieMpTswT/0WlMCSW5oAstG3mO/yRav2o6i+CzZ9CVZVlxubZs35uRp7oQyLltTbuODYIEqSA5zK5tNuVm4U/2s4y82e31iJSSBhfcQUY01lUM1AMKjgVO9+0TEEmX3hk03gm7D4CM45Zm1E3st1cFNEafO9O+nDof747nTgD2ZtGA==
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(56012099006)(10067099003)(11063799006)(22082099003)(18002099003)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Unkycy9obmpOTkpvN1ZWd3JLeU5rS2VmditaUFNJOVRMZGh1VllXbzNlWm9R?=
 =?utf-8?B?Smp1bkRkeXdTZTdYeFBlWWpsSVp2TFJHbURaVU9IcWIzRk5qYlVJS2lhaVZK?=
 =?utf-8?B?SnZOdFB6dE45cjJ2MllPZFNkamsvVmVRdDIwWC94UVpiU3JWUzNHMEpnSUJV?=
 =?utf-8?B?S0ltRmk5RzI2aUMrTHM5dTZpZVBMNTBMRmI3TEt2WUVoUjRLK1p0RjBaVFYy?=
 =?utf-8?B?NVhKRHYzcU13K0c4ZlJiWEN6aEdEaWFOVXpZNUJLVlJaRG9xZ0ZyeXVQVFlt?=
 =?utf-8?B?S3lxV1F2WjlzYnB3SkhsMWlSVWoxcnZYNjlyMnpZRVFWemI4T1FkUkY4NGN6?=
 =?utf-8?B?bjQyamwyajdXbWRMamhlRlFMdUsrWFdsdTJrVlZJT3RJcUJpNnZWSWJWT3dt?=
 =?utf-8?B?N05kaEdscG9GamNoa2lwc0Z0T0NlTkxKVzg4b2ZSR0VvVDVEU01qUTZVTGp6?=
 =?utf-8?B?NWdqbXcxSHpaZUVlVFErWU5yT3FtdGRoSkZ4bSt5M3Bjd28xSG1tT2VFRk80?=
 =?utf-8?B?Z3poRlhTS0pIN2E3eFhTNFlTdWNWNjV0VDBwSGJpUDRHTmhVdGZyKzZpMTJw?=
 =?utf-8?B?dm13QTdiSmlYVzBpWlE2VEt0THczNXdNNW90SDM0bXpzNytWL3FGWHhBYXNG?=
 =?utf-8?B?dm1NNjZ2cDl3ajZDKzVjY05aZTFGZ1AwN3VQUkRHNzBxWGlUVXV5Rkt2bWRE?=
 =?utf-8?B?TERqWTd4OTlhcDNmS0I2dmc4b1hxRGQ4a0RnNytIbmhGK1BaSnh1YkQ2bWNq?=
 =?utf-8?B?N3VPQ0QyMm1DbjBBNGUxdGZlMW14NVg3bVoyL0s2TFpQN3ZqU1lIRU5ucDNK?=
 =?utf-8?B?QlR3a05GSGRLU3pzOGRnYTdxVk5xWWE0NFdnQTE0NUMzYUNMcE1UdVROTlJ1?=
 =?utf-8?B?WWxOc25VcnZ5WG1CWXNNQmVtZVExMmdPVjQyQzljV2lsRmVudW5TYUt5OHVp?=
 =?utf-8?B?d2tGZmVtMytaYjRTZE9vN25vSDFreU1kek5FMTVsYXZWUGh6ejJ0NzNzZ0VX?=
 =?utf-8?B?SU5lNjhGQnBFakRwejh0UHgxOGQrN015WVgvaGVENXZLWExvaGhaU3FubVFK?=
 =?utf-8?B?MXU4Vms4aFdYNVM1akp1Wmh2dmxhaXJDUEJWVzdFWGpuSE9sMFBkT3pxV005?=
 =?utf-8?B?d3JSWTdYTDBMdjFKanlRZkh5T20rcjhTUjBmU3B4ajFkRlBjMUJRWmNaRU5K?=
 =?utf-8?B?OC8vQ0dJc01leVl6d3FMdktERUVVWGh0TnllcGRSK1BJaU1vTGdPVTNLNkwr?=
 =?utf-8?B?T0NuUzhwcUVnZlhqazZyTnFlbm9kbk1uZk9ib0hBbEw3SVBSODlKUmp0Z0Ez?=
 =?utf-8?B?SEJ2cTRqZW5YcHppUEpjOFFIK2llVWdydTFqT3VBYW9RSU5Oa3VXeW1DUUZ4?=
 =?utf-8?B?TGxYVlM2SFkwSDdMVnl2eGVwQzIrR2toMWI4MTRQVXJaNjJ6d1RtVXcrenAv?=
 =?utf-8?B?Rm5PU3ErWHBPRnVtS1RlLzllRlVhdnprNXprZVpCbTRhUmY0dktHZWxNM2Nq?=
 =?utf-8?B?cnIzaWYvSDU2YU5RZDBNRlRKQmI0bGdrSm1DQW8zV3JsbkdjU0RNMGgxd1N6?=
 =?utf-8?B?WFlPMTVzb2lwc2IzdkhJbEIwbHJIbGYwVkJQS1dQWk9IT3RNYlFONjBJOHls?=
 =?utf-8?B?QnJleHQxdlJkU2ZJdlMzdlk2VXFiaFlJYkZVUGdTRksyK1ZrV2VubFRxTWVG?=
 =?utf-8?B?eWxYMkEyKzBQYWVXZDhqWGRsbTVRQWpaeUxOR3p5c3J2MUh4encveVhCaW1a?=
 =?utf-8?B?RURMNnNiWXpzQzZVV0RLR2JiM2dIS214QkRHbi9UbUdENzVYUzZ2RFRYcW9p?=
 =?utf-8?B?SU0xdGUvTGIvbk9lLzFJNVdWc0kwbUplVFAyV1p4R0xmRmlyOU00VWIvWVNC?=
 =?utf-8?B?aWdvQitDZXU3L3JxY3phOEVzc29QdCt6UHFQM0k0Vm5FQjkxdlRUWWpXT1R4?=
 =?utf-8?B?c09zbWZVWTNMWVA3bU5NNkQxZHF4US9YYVhPRVRMZ3VERWMvTEpoT3dOcHBj?=
 =?utf-8?B?cUFJTU1oditJL3cvZHFwd241SXpweXc5cml1dE4zSFRqQm5QKzZxN2plaGtZ?=
 =?utf-8?B?bGJVMHNkRk01NHV0dlJwVWdjekZWWGpjQ3Q2YWdFd21HYzVoOEhsNFJEUFdK?=
 =?utf-8?B?a3lWN2dldW5zNHlYZkFDVmlJRWl2YWFhOXNzMCtVbkFrS3RrVTRUSnNFWjI5?=
 =?utf-8?B?QnJ3QlFKY3E1TkFzSTRpaFlKRS9HVnhyMWd4TmsyRGJ1TzdZWUc0RHFvT0lT?=
 =?utf-8?B?VHdZdGhIdW9FK3JTNVlDQmNrS2VrVVlQbWcvTk5DdDBBR2JmRU5sSysvVWVG?=
 =?utf-8?Q?AKlLLk6vDlpkxTZPiY?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f3a1d50-becc-4928-7fbb-08df0795a654
X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 19:25:43.4026
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: heh0HNNMPmEJNhwU8XKnYC1gTFrgaH3kmSa5bDYXRk9YZqvFD+ymQxvIlCBaZrzc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8742
X-purgate-ID: tlsNG-ef75cf/1788204358-A5EC6AE4-01633C64/0/0
X-purgate-type: clean
X-purgate-size: 2610

gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a
pointer to an allocated xen_page_foreign is stored; on 64-bit,
xen_page_foreign is stored inline. Checking page->private != NULL is enough
to tell whether a xen_page_foreign needs to be freed on 32-bit and
page->private is zeroed unconditionally on 64-bit.

It prepares for a future commit that remove PG_private.

No functional change intended.

Assisted-by: Claude:claude-opus-4-8
Assisted-by: Codex:gpt-5
Signed-off-by: Zi Yan <ziy@nvidia.com>
To: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/xen/balloon.c     |  5 +++++
 drivers/xen/grant-table.c | 11 +++++------
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e7f74ea7cd5eb..fdb18348cfdfe 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_lowmem)
 
 	__ClearPageOffline(page);
 	dec_node_page_state(page, NR_BALLOON_PAGES);
+	/*
+	 * clear page->private before giving it out, since it might be used to
+	 * store xen_page_foreign info.
+	 */
+	set_page_private(page, 0);
 
 	return page;
 }
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 69922be28b54c..993f89f048e21 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -863,10 +863,10 @@ EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
 
 int gnttab_pages_set_private(int nr_pages, struct page **pages)
 {
+#if BITS_PER_LONG < 64
 	int i;
 
 	for (i = 0; i < nr_pages; i++) {
-#if BITS_PER_LONG < 64
 		struct xen_page_foreign *foreign;
 
 		foreign = kzalloc_obj(*foreign);
@@ -874,9 +874,9 @@ int gnttab_pages_set_private(int nr_pages, struct page **pages)
 			return -ENOMEM;
 
 		set_page_private(pages[i], (unsigned long)foreign);
-#endif
-		SetPagePrivate(pages[i]);
 	}
+#endif
+	/* Data is stored in page->private on 64-bit */
 
 	return 0;
 }
@@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, struct page **pages)
 	int i;
 
 	for (i = 0; i < nr_pages; i++) {
-		if (PagePrivate(pages[i])) {
 #if BITS_PER_LONG < 64
+		if (page_private(pages[i]))
 			kfree((void *)page_private(pages[i]));
 #endif
-			ClearPagePrivate(pages[i]);
-		}
+		set_page_private(pages[i], 0);
 	}
 }
 EXPORT_SYMBOL_GPL(gnttab_pages_clear_private);

-- 
2.53.0



From xen-devel-bounces@lists.xenproject.org Mon Aug 31 19:26:07 2026
Return-path: <xen-devel-bounces@lists.xenproject.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 31 Aug 2026 19:26:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.1404363.1638088 (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x17dq-0004su-D1; Mon, 31 Aug 2026 19:26:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 1404363.1638088; Mon, 31 Aug 2026 19:26:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from <xen-devel-bounces@lists.xenproject.org>)
	id 1x17dq-0004sl-8P; Mon, 31 Aug 2026 19:26:02 +0000
Received: by outflank-mailman (input) for mailman id 1404363;
 Mon, 31 Aug 2026 19:26:01 +0000
Received: from mx.expurgate.net ([195.190.135.20])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from <ziy@nvidia.com>) id 1x17dp-0004q4-CG
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 19:26:01 +0000
Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp
 id 1x17dn-005nZD-R8
 for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 21:25:59 +0200
Received: from [10.42.69.7] (helo=localhost)
 by localhost with ESMTP (eXpurgate MTA 0.9.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a95d540-bab6-0a2a0a5309dd-0a2a450799d2-12
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 21:25:59 +0200
Received: from [52.101.52.3]
 (helo=BL2PR02CU003.outbound.protection.outlook.com)
 by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1)
 (envelope-from <ziy@nvidia.com>)
 id 6a95d545-b4ea-0a2a45070019-34653403f478-4
 for <xen-devel@lists.xenproject.org>; Mon, 31 Aug 2026 21:25:59 +0200
Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7)
 by SA1PR12MB8742.namprd12.prod.outlook.com (2603:10b6:806:373::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.7; Mon, 31 Aug
 2026 19:25:38 +0000
Received: from IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com
 ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0360.008; Mon, 31 Aug 2026
 19:25:38 +0000
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion <xen-devel.lists.xenproject.org>
List-Unsubscribe: <https://lists.xenproject.org/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xenproject.org>
List-Help: <mailto:xen-devel-request@lists.xenproject.org?subject=help>
List-Subscribe: <https://lists.xenproject.org/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xenproject.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" <xen-devel-bounces@lists.xenproject.org>
Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Izag6lOTbk0TC+BKQj5TpYJeX6iV3e5A2yIbAJ+p/egYWEdYGNXsZwZrUvqggEh2hwiX9diiOfbBd884vFz8J5CvP1j4oCa1ae3C5NDjMO0tF/m36mJRIfTOhk2gjkwB9uvEVPFCyMSFCAK7nNA0AyiaulPQoKL1/zgJmjxPrz3dj/wSANoxAIvO9vxRgQGVsywRSH2eVr9aKXS1BNa6vyix0ixu38gweI9ioRfdA5/1H/LmFUTAVwCWW7QAHaf2YsBRvcIgz1Tj/xCniHi3OCjUgLIHcK53JTA3jmRTz5ua3XHTjGNQcsizM65kWx3BLjV3ZhjPpeHX9YL61Nl/dA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1M7t11bVlX5NiEt6HPea3pXuobyxilLjoOBo2kqy1z0=;
 b=ukjJ2fN7T+DluBFHtGO5rHNfOeojWk/xaeHJTLQxVg6RuVo3Y9ZRDrOTQEwLX7nlCmC7ekRG9fn8MGBinHFPbdVHlKoaBgZ5tPFXal7tC0PDSGvyjfEnDuxP55Pp6Fzh9/3pxC5BiESPjggBE3YKBn4XU9fjLu7153NHT1/zWofcKJYvVSJMgpAG2rvl+nNxCY3KxDjQZwXgHYz9ENO2mwxQAeUU6kDtc3GwX2iCb8PAodBhPoKJNN/I8uclDYkudIPUf1jGsGsMMH0NztbwVjmqW7SOuLfn9xrysIZcynND+y2Ol7mMtpUpuJvpDOk9xs9jMcKzuFyjOp1rlgLWlQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com;
 dkim=pass header.d=nvidia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1M7t11bVlX5NiEt6HPea3pXuobyxilLjoOBo2kqy1z0=;
 b=d+UgtiZGPj2sblyxOpIcXM7SJktNxDWdOozEjOnkAkye8n7UtMZyN/jOyZM/AeG99DHQ4GIRrAOAz+xOclj925+H0fjxv7k+I4CHW+/6RDwp8cc9deRQ9umdQEpBWBAKZRb0qk5XzOOZEnYW+84/lMlvZMlv5dgUq/3NfITDXJ3lOu/FuUYdp8hHEd+Ho9xG3EfRNRS66dum9BPwBejbuzcQ9NntBMBp6rBCIL8QstpH4GgNV0xiFn1+1cQS1PJvy945hxKSRjuO++Gjoq1uxKWk+ukM84JUWEn7AMWAQJKHcpJ1sm+TLDibqURugxJsSBonc5u71dd8jqTi6fGyBw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=nvidia.com;
From: Zi Yan <ziy@nvidia.com>
Subject: [PATCH v2 00/14] Remove PG_private by using page/folio->private
 checks instead
Date: Mon, 31 Aug 2026 15:25:23 -0400
Message-Id: <20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-B4-Tracking: v=1; b=H4sIAAAAAAAC/22Nyw6CMBBFf4XM2ho6aHms/A9DTC0DzALatKTRk
 P67lbh0eU5yz90hkGcK0BU7eIoc2K4Z8FSAmfU6keAhM2CJqqyxEZ4WG0m46eE8R72RMCO1qEw
 9NpWBvHOeRn4dzXufeeawWf8+LqL82l+tkn9qUYpSyAuatn7q6qrwtkYeWJ+NXaBPKX0AdZkNU
 bMAAAA=
X-Change-ID: 20260728-remove-pg_private-cfe926c7f83c
To: David Hildenbrand <david@kernel.org>, 
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, 
 Andrew Morton <akpm@linux-foundation.org>, 
 Muchun Song <muchun.song@linux.dev>, Lorenzo Stoakes <ljs@kernel.org>, 
 "Liam R. Howlett" <liam@infradead.org>, Vlastimil Babka <vbabka@kernel.org>, 
 Mike Rapoport <rppt@kernel.org>, Suren Baghdasaryan <surenb@google.com>, 
 Michal Hocko <mhocko@suse.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, 
 Nico Pache <nico.pache@linux.dev>, Ryan Roberts <ryan.roberts@arm.com>, 
 Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>, 
 Lance Yang <lance.yang@linux.dev>, Usama Arif <usama.arif@linux.dev>, 
 Gregory Price <gourry@gourry.net>, 
 Ying Huang <ying.huang@linux.alibaba.com>, 
 Alistair Popple <apopple@nvidia.com>, Johannes Weiner <hannes@cmpxchg.org>, 
 Qi Zheng <qi.zheng@linux.dev>, Shakeel Butt <shakeel.butt@linux.dev>, 
 Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
 Zi Yan <ziy@nvidia.com>, Minchan Kim <minchan@kernel.org>, 
 Sergey Senozhatsky <senozhatsky@chromium.org>, 
 Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, 
 Arnaldo Carvalho de Melo <acme@kernel.org>, 
 Namhyung Kim <namhyung@kernel.org>, Thomas Gleixner <tglx@kernel.org>, 
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, 
 x86@kernel.org, Mark Rutland <mark.rutland@arm.com>, 
 Alexander Shishkin <alexander.shishkin@linux.intel.com>, 
 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>, 
 Adrian Hunter <adrian.hunter@intel.com>, 
 James Clark <james.clark@linaro.org>, "H. Peter Anvin" <hpa@zytor.com>, 
 linux-perf-users@vger.kernel.org, Juergen Gross <jgross@suse.com>, 
 Stefano Stabellini <sstabellini@kernel.org>, 
 Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>, 
 xen-devel@lists.xenproject.org, Eric Biggers <ebiggers@kernel.org>, 
 "Theodore Y. Ts'o" <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>, 
 linux-fscrypt@vger.kernel.org, Oscar Salvador <osalvador@suse.de>, 
 Chao Yu <chao@kernel.org>, linux-f2fs-devel@lists.sourceforge.net, 
 Gao Xiang <xiang@kernel.org>, Jan Kara <jack@suse.cz>, 
 Yue Hu <zbestahu@gmail.com>, Jeffle Xu <jefflexu@linux.alibaba.com>, 
 Sandeep Dhavale <dhavale@google.com>, Hongbo Li <hongbohbli@tencent.com>, 
 Chunhai Guo <guochunhai@vivo.com>, linux-erofs@lists.ozlabs.org, 
 linux-fsdevel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, 
 Masami Hiramatsu <mhiramat@kernel.org>, 
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, 
 Matthew Brost <matthew.brost@intel.com>, 
 Joshua Hahn <joshua.hahnjy@gmail.com>, Rakie Kim <rakie.kim@sk.com>, 
 Byungchul Park <byungchul@sk.com>, 
 Axel Rasmussen <axelrasmussen@google.com>, Yuanchu Xie <yuanchu@google.com>, 
 Wei Xu <weixugc@google.com>, linux-trace-kernel@vger.kernel.org, 
 Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>, 
 linux-nfs@vger.kernel.org, Song Liu <song@kernel.org>, 
 Yu Kuai <yukuai@fygo.io>, Ilya Dryomov <idryomov@gmail.com>, 
 Alex Markuze <amarkuze@redhat.com>, Viacheslav Dubeyko <slava@dubeyko.com>, 
 Li Nan <magiclinan@didiglobal.com>, Xiao Ni <xiao@kernel.org>, 
 linux-raid@vger.kernel.org, ceph-devel@vger.kernel.org, 
 Richard Weinberger <richard@nod.at>, Zhihao Cheng <chengzhihao1@huawei.com>, 
 linux-mtd@lists.infradead.org, Baoquan He <baoquan.he@linux.dev>, 
 Pasha Tatashin <pasha.tatashin@soleen.com>, 
 Pratyush Yadav <pratyush@kernel.org>, Jonathan Corbet <corbet@lwn.net>, 
 Dave Young <ruirui.yang@linux.dev>, Shuah Khan <skhan@linuxfoundation.org>, 
 kexec@lists.infradead.org, linux-doc@vger.kernel.org
X-Mailer: b4 0.15.2
X-ClientProxiedBy: YQBP288CA0014.CANP288.PROD.OUTLOOK.COM
 (2603:10b6:c01:6a::27) To IA0PR12MB8374.namprd12.prod.outlook.com
 (2603:10b6:208:40e::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|SA1PR12MB8742:EE_
X-MS-Office365-Filtering-Correlation-Id: 41106e9b-83b1-4289-148e-08df0795a348
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|56012099006|10067099003|5023799004|11063799006|18002099003|3023799007|6133799003|921020;
X-Microsoft-Antispam-Message-Info:
	htBZZ7Vb0eSvRuQ6i6qCoafiHji3CmdV5q+gWWn3j5SvAJqLVVvyzr7grLrG1sgQn/Bm4NsXVwcpqWuNsYuZSEmYz8wBonsejxrvXRxhgaBiU380txw+dm6fJ6scn8Ya5yOfX5tfwcX9KopytlqfBOVOlbskj1efRgAVY9t1aK/8/nw6ga3RzmTgvdBEjdffhLOJvQOGImpxzMeWnrDjOC+WSQuEU6YwXNa9m23T4iaqk18laKGiTbLXNcUTS1jfWtB8bGkVFvyw5VIosMU3c2N4zUw/PwfzO7DMFK7ym/E4g3JG4N8DxBkkW4K0CAHy0LvCrG1RghbJxVDMCa9CLvk9zpCJzIRoiWtOkjt2S3uDAozEea+p7+YXq133RvaHZXq9ZMqk4Q9a/jdEut7x6VZDz9zgTyAyRitZmmtfUj0IPo6RUIiKKlmxY6brx0yRsJ8IMtBqpWK8XvAspquCK2YpzVcpkZIaKEcN+Dj9CtlKJMrDzf77KLesP4zpGJFJduRBQ9FrOcNHvGGTueB8NPWC59MUIDc4uw6mf1Naa35YScoP/TB6m2jf9NWxq3Zda9+uJ5qXI5Zo0LHl2g/bxA0UtkZAukAQyxh45SaiUn5UjQmZNvVfap3X0UiXa1gKZ40QqNL3VyFBltaZFJCSE92FJQpdbh/p/ybZaVlN5lWMdMWl0n+CCs7YuBljKU8TU5Tgt8PFmUsLS1V5HC7m/A==
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(56012099006)(10067099003)(5023799004)(11063799006)(18002099003)(3023799007)(6133799003)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aldNM29LWVhMQWN4WGlpSkJRWkxtZFRZNlFYRFNPMERWbkZyb211NWZRR25K?=
 =?utf-8?B?N2ZrOElmcTcxdXZybjBwLy84WUlRUlh0QjZDdGgzM0JqdEp2YXEyNTJZWUpI?=
 =?utf-8?B?cC80TEo3SzNNcDYwMitaNTdvQUgyck9UUlJkVUhtTVdhRDVjYUNINnRlOWVu?=
 =?utf-8?B?amxwRlN0UC9DTHdaMzlKYWtzVEpucU5zWjgrcUl2VkxjTVZDUUlUUGpub0Jj?=
 =?utf-8?B?RTFDR3VDdXN5T1llNGJMK01xVnNNYTgvTUlBL1VvMklwcFMwVERpTjBhcWll?=
 =?utf-8?B?UENNOUxuYlVIWVhkckhtS3pVQ3dqUnhBVUlIUjc0UmZxZnJkZnJBdWwvWm1E?=
 =?utf-8?B?ZjZrbjIrY21zSTYzYVVlY0d4M3BJb1lxa1ZmWTJBbUZRbUNlNFFuZGdrdDhu?=
 =?utf-8?B?bHlxNG85MnhvZVlVQjM3WlJhMWt1VXprV21jek1sVUdxR3RFTG1iWFNSYkxZ?=
 =?utf-8?B?TjR3eEhqQ3k1bnFubGs1eEZaOHM4WmRKamtPa24xZTFnbFZzQjFiQTBFUmwr?=
 =?utf-8?B?RnRKRkNWT00vRjUvTVBWVVBSRW0xTHQvLzI0T3VLR0VLRGpjR2RCOGYwclUz?=
 =?utf-8?B?dmFNaXlUVElXaWV3QXoxODh1OFFtMmcyM2dHMlU5ZDNCeVZMSFFCaXJzQStm?=
 =?utf-8?B?SFVtZ2c5enlDM3pVMmhEMTBweGFkTDFqZlRQN2tXSWhJZnRpODBzVW5BdW5D?=
 =?utf-8?B?L25CVWdDWG9JaTI0cXR1V2pqSnhRQ09vUTgrakk5OUhpclZra0VSZ2dOTmk2?=
 =?utf-8?B?L25XWEp4b1JPTUxGV0JUQ2ZpM21OOFlJMGZDMmJvQ2FxRUZBRTI5RjBrTGth?=
 =?utf-8?B?VVlOQktYenJ2emJFM2llazU1SUlIRkdEWG9QNldTQW1QWTFpT0tIYkpSdk1a?=
 =?utf-8?B?VzRQb1hYZys3R0lEaHA5Rkp4UEdkbzB3N3JYbElURGpZZWZ3MGttRVFLLzc4?=
 =?utf-8?B?amhBc3gvd21nK0dXb0FUQ2ZENkNKZHh3bFZiR0VBcGdiMTJIcHNkZ21nVHdl?=
 =?utf-8?B?bmZRY3Y1MWhlS2FEUU5UV0JKYmZiT0NWano5dFUyWFJpN0w1aWZENTVvSVNo?=
 =?utf-8?B?dHVHQjIzMmZRN0FDRXJqbGRHTkZEdXRHc3dxNUN0bXpSVVpOeXVJZmNyT3RM?=
 =?utf-8?B?cTA3SGNsdUFoc2QrMWxSNkZJNnFGQjkvQ3pYSDZJQ3NNQnJqRjlBY1pZUFJn?=
 =?utf-8?B?R0VpdndVbFlCa05SNG0rckgyZ0NiZ1dhMlIrSlpmcHBPQXNQMm1USitlaU4y?=
 =?utf-8?B?U0p1WC80UHU4VzJrZDZ5SnhGUm9URUFPajd2MlVWdkRiQTRrN05Jb0xHU1E3?=
 =?utf-8?B?cjBxZTFhWWtVamJHdzBua0Y0Q0JQOTBJYnN5eDJtdnl5YUtEUGc4MUdvWTdu?=
 =?utf-8?B?ZVRtclY2dFZaaFBtSy83aFN5QWdLNXlycUpTNisyNkE1YmZCOFRQQzA1bDdx?=
 =?utf-8?B?SkZDcm5zcEgyWHlYVEQvODliYXN6VTVrcDRTTGJOUVF0VmVRZStDV1dCT2Uw?=
 =?utf-8?B?UVVvYSsxMkpBMkpYeHBJSlM3TWZIeHZqM25LaWJMTG5yaFAxSHFNMlExSlpW?=
 =?utf-8?B?SU01YUk5TlZ6Zm9IZURRelFLNkMxaEZZRGJSa2ZaSTBoNXNRWU52bFd3NzJk?=
 =?utf-8?B?V091Q1RjdWVCMnRmRnh6RGZObmZ1WVhDNWdlUWRzSlBJR3Q2QVo1Szc4L2dB?=
 =?utf-8?B?WFhuN1ZBZjhwOFdFZG85bFNjRDQyYWtsQ1ZsZzZCNXBNU2Y2R21taUZTTlFj?=
 =?utf-8?B?emJPTnBNYUxicGw5cnNwVmlTYzJSMGZIeWh3dG9kcDdYWUJYZFQ4bm5ObG94?=
 =?utf-8?B?VTJCN1cvYy9rZEZDS2xIZjROMnpSMVB1VmVVRDEybEkxU1QveWE5bW5VVnls?=
 =?utf-8?B?RVd0N3VOdmlZb3lTYnpUb3lwckZMbHY1RFJCa05MY05PT090YTErME9BT0Zh?=
 =?utf-8?B?bHpIbTVNb2ZFaU1BQnQyQ1ZtamxuSE1YSFRza2FtaTU4UFN5Q1RDVXY2Y2NS?=
 =?utf-8?B?WmRlQThFNFZ6S043cWpuaWNVQUsyUU5lNGtDYVQzWGhraytqT2ZHakVQc1NE?=
 =?utf-8?B?VU9weW1ONjNrWVVZc2xBSVZKNG85ekg5eE9HQURBaVBxUDNvVUdENDdiR0xI?=
 =?utf-8?B?S1NrcytDZmNEMldBbVRXNnJNMnlEenM4Qml1ZVdJb1k4VXJkMmdHWW9WRFUw?=
 =?utf-8?B?SFNNWXM4UkpXSHl0ZzRXTnRHUThUeHhITmdDTG5la21FVmU1MzhtODAzWkI2?=
 =?utf-8?B?QzZvMkNjNlpVaEp5b0xIaGRuUFl6N3lHYmkxNjBkeUpCNVJoRzRWZUFvcWJI?=
 =?utf-8?Q?QUyE3mqIbnBvqUtxPa?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 41106e9b-83b1-4289-148e-08df0795a348
X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2026 19:25:38.2564
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: n843s1whvSfgneW2wvMilxUPWuaDS8ZfBLBStLsy0PfIZUOOEULUw1e08PmJRM8m
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8742
X-purgate-ID: tlsNG-ef75cf/1788204359-366DAAE4-5BE31701/0/0
X-purgate-type: clean
X-purgate-size: 9693

Hi all,

This patchset removes PG_private to make space for upcoming PG_folio
(reserved as __PG_folio) for identifying pages from a folio (more details
in Note below). Instead of checking PG_private, all code is changed to
check page/folio->private != NULL instead.

MM people are cc'd on all patches and subsystem people are cc'd on the
cover letter and corresponding patches.

Overview
===
Most code uses folio_attach/detach/change_private() functions, so folio
refcount is increased and decreased when folio->private is set and reset,
respectively. There is no need to change them.

Changes are needed for exceptional users:
1. zsmalloc uses PG_private to indicate first component zpdesc page and
   page->private is used to store zspage in zpdesc. To remove PG_private,
   is_first_zpdesc() is replaced by pointer comparison.

2. kernel/events/ring_buffer.c stores page order in page->private.
   Replacing PG_private with page->private != NULL works.

3. drivers/xen/grant-table.c stores xen_page_foreign in page->private,
   where on 32-bit, a pointer to xen_page_foreign is stored; on 64-bit,
   page->private is used as xen_page_foreign. PG_private check is replaced
   by page->private != NULL on 32-bit for xen_page_foreign deallocation.
   On 64-bit, page->private is cleared unconditionally since {domid=0,
   gref=0} (xen_page_foreign can be 0) is valid.

4. fs/crypto/crypto.c stores a folio pointer in page->private, PG_private
   checks are replaced by page->private != NULL.

5. fs/erofs has two different uses:

    5a. folio->private is used to form a reversed list of
    the outputs of readahead_folio(). readahead_folio_last() is added to
    output folios in reversed order, so that ->private is no longer needed.

    5b. folio->private is used as an in-flight I/O counter. Convert the
    code to use folio_attach/detach/get_private() and add bias==1 to the
    counter to avoid folio->private being zero.

6. fs/nfs/write.c: folio refcount maintenance is in a bigger scope than
   folio->private. So folio_attach/detach/get_private() is not used.
   Nothing to change.

7. fs/f2fs uses attach_page_private() to first reset folio->private then
   immediately sets PAGE_PRIVATE_NOT_POINTER bit on it. Change it to use
   attach_page_private() to set PAGE_PRIVATE_NOT_POINTER bit directly to
   avoid folio->private == NULL gap inside set_page_private_##name().

8. hugetlb uses folio_change_private(folio, NULL) without folio refcount
   maintenance. Change it to folio->private = NULL.

After the above changes, PG_private ops are converted to
page/folio->private ops.

folio_test_fs_private() is added to check filesystem-only private data by
excluding swapcache and hugetlb folios, because swapcache folios overlap
swp_entry_t swap with ->private and hugetlb sets its own flags in
->private.

Note
===
1. KPF_PRIVATE is removed after PG_private is removed.

2. Documentation/mm/hugetlbfs_reserv.rst is outdated, so I did not remove
   PG_private related text. It should be rewritten.

3. PG_folio is planned to be set on every page from a folio in
   page_rmappable_folio(), so folios with any order (currently
   PG_large_rmappable is used to identify >0 order folios) can be
   identified, vm_insert_*() can correctly reject all folios, and rmap code
   can accept only folios. Eventually, page_folio() will return NULL for
   non-folio pages by checking PG_folio, but before that all existing users
   that treat compound pages as folios will be converted. 

Tests
===
1. allmodconfig build passed.

2. zsmalloc is tested using ext4 on a 1GB lz4 zram:
    2a. zram load + zsmalloc compaction;
    2b. concurrent zspage migration via memory compaction;
    2c. confirmed that multi-page zspages actually formed.

    Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_zsmalloc.md

3. erofs is tested on images created with -C4096 and lz4hc, lzma,
   deflate, and zstd algorithms:
   3a. cold read of all files, verify checksums match source;
   3b. readahead + reclaim/migration race.

   Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_erofs.md

4. fscrypt is tested on software-encrypted ext4 with writes to exercise
   bounce pages.

   Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_fscrypt.md

5. f2fs is tested on an image with inline_data,compress_algorithm=lz4:
    5a. INLINE_INODE — lots of tiny files;
    5b. REF_RESOURCE + general writeback — buffered write churn with fsync;
    5c. ONGOING_MIGRATION — force GC / page migration;
    5d. ATOMIC_WRITE — atomic-write ioctl path.

    Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_f2fs.md
    (I did not run xfstests)

6. MM selftests passed.

LLM use
===
Claude was used to form a concrete plan on what code needs to be changed
and how to change them. The plan was reviewed by Codex until no issue was
spotted.

Plan is at: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/plan.md

I then followed the plan to make code changes. I did bounce ideas with
Claude how to change fs/erofs, since I did not like the original idea.
After each change, I asked Claude to review my code and git commit message.
I also asked Claude to give me test plans (see above).

At last, Codex was used to review all patches.

Comments and suggestions are welcome. Thanks.

Assisted-by: Claude:claude-opus-4-8
Assisted-by: Codex:gpt-5
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
Changes in v2:
1. removed is_first_zpdesc() in patch 1 and open coded the checks.
2. fixed wording in patch 2's commit message and clarified page_private()
   also works when ring buffer's AUX page order is 0.
3. removed the empty loop in 64-bit gnttab_pages_set_private().
4. clarified folio->private will be reset to NULL by
   fscrypt_free_bounce_page() in the commit message.
5. clarified why hugetlb needs to restore hugetlb_vmemmap_optimized.
6. renamed readahead_folio_reverse() readahead_folio_last() and
   reimplemented readahead_folio_last() by adding a new readahead_control
   private member, _forward, and a new helper __readahead_advance().
7. added a bias, 1, to erofs I/O counter, so that folio->private stays non
   NULL between folio_attach_private() and folio_detach_private().
8. converted more call sites to use folio_test_fs_private().
- Link to v1: https://lore.kernel.org/r/20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com

---
Zi Yan (14):
      mm/zsmalloc: replace PG_private with pointer comparison
      perf/ring_buffer: stop using PG_private as AUX page high-order marker
      xen/grant-table: stop setting PG_private on pages for grant mapping
      fscrypt: stop setting PG_private on bounce page
      mm/hugetlb: use direct assignment instead of folio_change_private()
      f2fs: stop using PG_private
      erofs: mm/pagemap: add readahead_folio_last() to avoid folio->private
      erofs: use folio_attach/detach_private() instead of direct assignment
      mm/page-flags: check page/folio->private instead of PG_private
      mm/page-flags: introduce folio_test_fs_private()
      treewide: remove folio_set/clear_private()
      treewide: replace PagePrivate() with page_private()
      treewide: adjust comments on PagePrivate and PG_private
      mm/page-flags: remove PG_private

 Documentation/admin-guide/kdump/vmcoreinfo.rst |  2 +-
 Documentation/filesystems/vfs.rst              |  6 +--
 arch/x86/events/intel/bts.c                    |  3 --
 arch/x86/events/intel/pt.c                     |  6 +--
 drivers/md/md-bitmap.c                         |  6 +--
 drivers/xen/balloon.c                          |  5 +++
 drivers/xen/grant-table.c                      | 11 +++--
 fs/ceph/addr.c                                 |  8 ++--
 fs/crypto/crypto.c                             |  2 -
 fs/erofs/data.c                                | 16 ++++---
 fs/erofs/zdata.c                               | 13 ++----
 fs/f2fs/f2fs.h                                 |  8 ++--
 fs/nfs/file.c                                  |  4 +-
 fs/nfs/write.c                                 |  2 -
 fs/proc/page.c                                 |  1 -
 fs/ubifs/file.c                                |  8 ++--
 include/linux/buffer_head.h                    |  6 ---
 include/linux/kernel-page-flags.h              |  1 -
 include/linux/mm.h                             | 35 +++++++++------
 include/linux/mm_types.h                       |  4 +-
 include/linux/page-flags.h                     | 38 +++++++++++-----
 include/linux/pagemap.h                        | 60 +++++++++++++++++++++-----
 include/trace/events/mmflags.h                 |  2 +-
 include/trace/events/pagemap.h                 |  2 +-
 kernel/events/ring_buffer.c                    |  7 ++-
 kernel/vmcore_info.c                           |  1 -
 mm/huge_memory.c                               |  2 +-
 mm/hugetlb.c                                   |  6 +--
 mm/migrate.c                                   |  3 +-
 mm/page-writeback.c                            |  2 +-
 mm/vmscan.c                                    |  2 +-
 mm/zpdesc.h                                    |  2 +-
 mm/zsmalloc.c                                  | 24 +++--------
 tools/mm/page-types.c                          |  2 -
 34 files changed, 163 insertions(+), 137 deletions(-)
---
base-commit: 443451c85ca8d6389d34b1299decada62128f1fe
change-id: 20260728-remove-pg_private-cfe926c7f83c

Best regards,
--  
Yan, Zi